CN105430051A - An SDN-oriented service function chain construction method - Google Patents

Abstract

The invention discloses a method for constructing an SDN-oriented service function chain, which can realize the deployment of network service function block instances on network nodes according to network service requests. The node information creates a service function instance chain, the service function chain is composed of service functions, and the service function embodiment chain is composed of service function blocks. The service function is implemented by the support of the service function block. The main task of the classification service function block is to classify the data packets according to the metadata; the main task of the scheduling service function block is to schedule and process the data packets. When it is necessary to go out from the same port, then arrange the sending order and rhythm of these streams. This classification greatly simplifies the existing service function block class and ensures the simplicity of the service function block class.

Description

An SDN-oriented service function chain construction method

technical field

The present invention relates to the field of SDN (Software Defined Network, software-defined network) and service function chain, in particular to a division of service function block classes and a service function block (ServiceFunctionBlock) description method based on the division.

Background technique

New data center networks and network cloud architectures require more flexible deployment models to support a wide variety of applications and related network services. This includes traditional network services such as firewalls, service load balancers, and applications that operate on network data. Also, since each individual tenant is an isolated client organization connected to the data center, in a multi-tenant context, these services must be delivered to meet the needs of all tenants, while each tenant may also need Unique capabilities, or tailored service features.

In the past, there was also the concept of service function chain, but the service function chain of the traditional network is closely coupled with the network topology, and the deployment is complicated. When the service function chain is changed or expanded, it is necessary to change the network topology and reconfigure the network equipment. The cloud computing environment widely uses virtualization technology, which has the characteristics of dynamics, high fluidity, variable scale, and multi-tenancy. The service function chain of the traditional network cannot meet these requirements. The emergence of SDN makes the service function chain full of vitality. Therefore, when talking about the service function chain, the default refers to the SDN service function chain. At present, there are many researches on the service function chain, the more mainstream one is based on the implementation of source routing, that is, at the data source, it is determined which service nodes need to pass through, and then the identifiers of these service nodes are encapsulated in the message to form MPLS-like overlay tunnel encapsulation. The intermediate network node performs forwarding processing according to the specified identifier of the message. This function needs to add a service processing identifier in the route. After receiving the message, the service node checks that it has its own service identifier and then performs service processing.

Today's web service deployment models are relatively static and limited to topology for insertion and policy selection. Moreover, in the virtualized environment, they are not yet adapted to the flexible policy environment. At the same time, the deployment of some traditional network devices, such as traffic limitation and load balancer, is closely related to the network topology and needs to be placed according to the packet path, which obviously runs counter to the separation of the virtual network from the physical network.

Under such a premise, new types of middleware such as virtual speed limiter and load balancer are produced. These middleware are deployed at the edge of the network, usually implemented by standard servers. We call these service processing functions such as virtual firewall/speed limiter/load balancer/gateway ServiceFunction, that is, service function. The traffic is processed by a series of ServiceFunctions to form a ServiceFunctionChaining, that is, a service function chain.

From the perspective of the overall implementation method, the current research on service function chain can be divided into three implementation methods: enhanced gateway, static ServiceChaining deployment, and dynamic ServiceChaining deployment. The enhanced gateway mainly considers that all user data needs to be aggregated to the packet domain gateway before it can be routed to the Internet, and deploys complex data flow processing functions and value-added services to the gateway. The SBR (Service Based Routing, service-based routing) proposed by Huawei belongs to this category. Static ServiceChaining is to deploy value-added service servers and complex stream processing middleware behind the gateway, and use serial methods for processing. SFCviaNSH discusses a method of using network service headers to build a complete static ServiceChaining deployment service platform. Dynamic ServiceChaining extracts MiddleBox from the routing topology in an Overlay way, so that the deployment of MiddleBox no longer depends on the topology and can be moved, inserted or deleted freely. At the same time, the use of virtualization technology enables MiddleBox to flexibly expand and shrink according to traffic Content, while SDN technology combines policy control to arrange different ServiceChaining and ServiceChaining paths according to different dimensions and different granularity requirements. There are many researches in this area. "Formal Methods for Service Composition" introduces several service composition methods when generating service function chains, points out their drawbacks, and proposes its own formal method. Cloud-based provides a framework for building a dynamic service function chain on a cloud virtual platform, and proposes a performance optimization solution at the flow length level for the dynamic service function chain. Steering introduces a centralized control controller to deliver dynamic Policies are used to control users and flow types to dynamically generate service function chains. Equipment manufacturers have made examples of service function chains so far, such as the aforementioned SBR and a dynamic service function chain under the ODL controller based on SDN introduced by Ericsson.

In the current network, network applications such as firewalls, filters, conflict detection systems, deep packet inspection, network address translation, content caching, load balancing, etc., now use some middleware or internal services - because they are the end users transparent. Middleware is indispensable in high-bandwidth networks (fixed or mobile), such as in enterprise networks, and more recently in data centers and cloud environments. Although this topic has been very hot in recent years, there is still no good solution for the placement and management of middleware. In the existing research, from a functional point of view, OpenFlow with flow tables and ForCES using LFB for forwarding are both one of the implementation methods of service function chains. In OpenFlow, the data packets are matched to each flow table and finally perform corresponding actions. In ForCES, the data packets are finally determined to be redirected, forwarded or discarded after passing through the LFB topology that constitutes a specific function. Flow table and LFB are both types of service functions, among which OpenFlow flow table is widely used, while ForCES LFB is more flexible.

Contents of the invention

In order to overcome the deficiencies of the prior art, the present invention provides an SDN-oriented service function chain construction method. The present invention proposes a new concept SFB (ServiceFunctionBlock, service function block), and proposes a method for constructing a service function chain by using a classified service function block and a scheduling service function block, and modeling of the above two service function blocks. Compared with the OpenFlow flow table, the service function block has a higher description ability, and compared with the LFB of ForCES, it also has better generalization, which greatly simplifies the types of service functions.

The technical solution is as follows.

A method for constructing an SDN-oriented service function chain, specifically, in an SDN network structure, deploying a network service function block instance at a network node in response to a network service request, comprising the following steps:

1-1) The controller creates a service function chain according to the network service requirements proposed by the user, and the service function chain is composed of several service functions connected end to end;

1-2) The service function is realized by the support of the service function block, which is divided into two categories, namely the classification service function block and the scheduling service function block;

1-3) The network node reports the resource status of the network node to the controller, including the optional secondary functional elements, metadata and scheduling algorithms;

1-4) The controller designs the service function instance chain according to the resource status of the network nodes and the service function chain information, and the service function instance chain is composed of service function blocks connected end to end;

1-5) For network nodes that support service function blocks, the controller sends the description of the service function instance chain directly to the relevant network nodes and requests to reserve resources. For network nodes that support OpenFlow, the controller sends the service function instance chain The description is converted into a flow table and then issued;

1-6) Network node deployment service function instance chain.

The service functions described in step 1-2) are realized by the support of service function blocks, which are divided into two categories, namely classification service function blocks and scheduling service function blocks:

2-1) The service function block class contains the main functional elements shared by the service function blocks in this class;

2-2) In addition to the main function element value, there are input and output ports, input and output data packets, input and output metadata, and secondary function element values in the service function block;

2-3) The main task of the classification service function block class is to classify data packets according to metadata;

2-4) The main task of the scheduling service function block is to schedule and process data packets. If there are multiple data streams that need to go out from the same port, then arrange the sending order and rhythm of these streams.

Description of drawings

Fig. 1 is the real network topology of H college in one embodiment of the present invention;

Fig. 2 is a service function chain constructed according to the business requirements of H College in one embodiment of the present invention;

Fig. 3 is an example chain of service functions constructed according to the business requirements of H College in one embodiment of the present invention.

detailed description

The present invention will be further described below through the drawings and specific embodiments.

College H shown in Figure 1 needs to establish an SDN-oriented service function chain. Therefore, it is necessary to deploy network service function block instances on network nodes for network service requests. The specific steps are as follows:

1-1) The controller creates a service function chain according to the network service requirements proposed by the user, and the service function chain is composed of several service functions connected end to end;

1-2) The service function is realized by the support of the service function block, which is divided into two categories, namely the classification service function block and the scheduling service function block;

1-3) The network node reports the resource status of the network node to the controller, including the optional secondary functional elements, metadata and scheduling algorithms;

1-4) The controller designs the service function instance chain according to the resource status of the network nodes and the service function chain information, and the service function instance chain is composed of service function blocks connected end to end;

1-5) For network nodes that support service function blocks, the controller sends the description of the service function instance chain directly to the relevant network nodes and requests to reserve resources. For network nodes that support OpenFlow, the controller sends the service function instance chain The description is converted into a flow table and then issued;

1-6) Network node deployment service function instance chain.

Figure 2 and Figure 3 are the service function chains and service function instance chains that need to be constructed, they are composed of service functions and service function blocks respectively, and the service functions are realized by the support of service function blocks. The service function blocks are divided into two categories, which are classified service function blocks and scheduling service function blocks:

2-1) The service function block class contains the main functional elements shared by the service function blocks in this class;

2-2) In addition to the main function element value, there are input and output ports, input and output data packets, input and output metadata, and secondary function element values in the service function block;

2-3) The main task of the classification service function block class is to classify data packets according to metadata;

2-4) The main task of the scheduling service function block is to schedule and process data packets. If there are multiple data streams that need to go out from the same port, then arrange the sending order and rhythm of these streams.

Example

The process of forwarding policy conversion method is described below by taking the deployment of load balancing data center and the configuration of network traffic monitoring service in College H of University A as an example.

As shown in FIG. 1 , the network topology of this embodiment consists of one core switch, two SDN switches S1 and S2, five servers, and several hosts/terminal devices. The whole network is divided into six network segments, network segment 1: network research institute (10.20.4.0/24); network segment 2: graduate laboratory (10.20.5.0/24); network segment 3: cloud laboratory (10.20.6.0 /24); network segment 4: cloud lab server group (10.20.7.0/24). The 4 servers in network segment 4 are used to run the cloud lab operating system. Network segment 5: audit server (10.20.8.0/24), which can selectively back up data packets according to the administrator's needs for post-event auditing. Network segment 6: data server (10.20.9.0/24), this data server is responsible for the data storage of the entire college. The cloud laboratory server network segment is connected to the backbone network of the college through an SDN switch, which can realize the balanced distribution of cloud laboratory traffic. Network segments 1-3 are interconnected through an SDN switch, and all six network segments are connected to the backbone network of the college through the college core switch.

In the first step, the controller creates a service function chain according to the network service requirements proposed by the user, and the service function chain is composed of several service functions connected end to end. The business requirement of this embodiment is to improve the service quality of the cloud platform. Based on this business requirement, the controller will establish a chain of service functions. The service function chain contains three service functions: "authentication", "traffic management" and "load balancing".

The descriptions of the three service functions included in the service function chain are as follows:

(1) The "authentication" service function is used to manage and authorize Internet users, and only traffic coming in through authorized physical ports can access network information. The H College network implements user authentication on network segment 1, network segment 2, and network segment 3, backs up the traffic of the access data server (10.20.9.1) and sends it to the audit server (10.20.8.1) for auditing, and this service function can reduce "Illegal" traffic, while facilitating the management of user permissions;

(2) The "traffic management" service function manages network segment 1 and network segment 2 when the traffic accessing the data server (10.20.9.1) exceeds a certain range. When the traffic is too high, it is forbidden to connect to the data server, so as to ensure To run the security and efficiency of cloud platform operation;

(3) The "load balancing" service function connects the cloud lab terminal to the server with the smallest delay according to the delay of the cloud lab server.

The service function chain structure established according to business requirements is shown in Figure 2.

In the second step, the service function is realized by the support of the service function block. The service function block is divided into two categories, namely, the classification service function block and the scheduling service function block. The specific method is:

1. The service function block class contains the main functional elements shared by the service function blocks in this class;

A template describing a service function block class:

<SFBClassDefSFBClassID="…">

<!--The number of the service function block class-->

<name>…</name>

<!--The name of the service function block class-->

<synopsis>…</synopsis>

<!--Introduction to the service function block class-->

<components>

<componentaccess="..."componentID="...">

<!—The number of the main function element and the operation authority provided by the main function element: readable and writable, read-only, clear read operation, etc. -->

<name>…</name>

<!--Main function element name-->

<synopsis>…</synopsis>

<!--Introduction to the main functional element-->

<typeRef>…</typeRef>

<!--The format of the main function element-->

</component>

</components>

</SFBClassDef>

2. In addition to the main function element value, there are input and output ports, input and output data packets, input and output metadata, and secondary function element values in the service function block;

A template describing a service function block:

<SFBInstanceDefInstanceID="…"><!--The number of the service function block-->

<name>…</name>

<!--The name of the service function block-->

<synopsis>…</synopsis>

<!--Introduction to the service function block-->

<version>…</version>

<!--The version of the service function block-->

<ClassID>…</ClassID>

<!--The number of the class to which the service function block belongs-->

<inputPorts>

<inputPort>

<name>…</name>

<!--Enter port name-->

<ID>…</ID>

<!--Enter port ID-->

<synopsis>…</synopsis>

<!--Introduction to input port-->

<expectation>

<frameExpected>

<ref>…</ref>

<!--Reference format of input package-->

</frameExpected>

<metadataExpected>

<ref>…</ref>

<!--Reference format for input metadata-->

</metadataExpected>

</expectation>

</inputPort>

</inputPorts>

<outputPorts>

<outputPort>

<name>…</name>

<!--Output port name-->

<ID>…</ID>

<!--Output port number-->

<synopsis>…</synopsis>

<!--Output port introduction-->

<product>

<nextInstanceID>…</nextInstanceID>

<!--Next instance ID-->

<nextPortID>…</nextPortID>

<!--Next physical port ID-->

<frame Produced>

<ref>…</ref>

<!--Reference format of the output package-->

</frame Produced>

<metadata Produced>

<ref>…</ref>

<!--Reference format of output metadata-->

</metadataProduced>

</product>

<nextInstanceID>..</nextInstanceID>

<!--Number of the next service function block-->

</outputPort>

</outputPorts>

<componentValues>

<componentValuecomponentID="…">…</componentValue>

<!--The value of the service function block element-->

</componentValues>

</SFBInstanceDef>

3. The main task of the classification service functional block class is to classify data packets according to metadata, specifically described as:

<SFBClassDefSFBClassID="1">

<components>

<componentaccess="read-write"componentID="1">

<name>adminStatus</name>

<!--Operation status of service function block-->

<synopsis>TheSFBstatusadministrativelyrequested.</synopsis>

<typeRef>SFBStatusType</typeRef>

<defaultValue>2</defaultValue>

</component>

<componentaccess="read-only"componentID="2">

<name>operStatus</name>

<!--The actual state of the service function block-->

<synopsis>TheSFBactualoperationalstatus.</synopsis>

<typeRef>SFBStatusType</typeRef>

<defaultValue>2</defaultValue>

</component>

<componentaccess="read-write"componentID="3">

<name>metadataDispatchTable</name>

<!--Classification table-->

<synopsis>

ThemetadataDispatchTablecomponent, whichcontainsentriesofametadatavalue, acomparator,thresholdValueandanoutputindex, specifyingthatapacketwiththemetadatavaluemustgooutfromtheinstancewiththeoutputindexoftheSFBgroupoutputport.

</synopsis>

<typeRef>metadataDispatchTableType</typeRef>

</component>

</components>

</SFBClassDef>

4. The main task of the scheduling service function block is to schedule and process data packets. If there are multiple data streams that need to go out from the same port, then arrange the sending order and rhythm of these streams. The specific description is as follows:

<SFBClassDefSFBClassID="2">

<components>

<componentaccess="read-write"componentID="1">

<name>adminStatus</name>

<synopsis>TheSFBstatusadministrativelyrequested.</synopsis>

<typeRef>SFBStatusType</typeRef>

<defaultValue>2</defaultValue>

</component>

<componentaccess="read-only"componentID="2">

<name>operStatus</name>

<synopsis>TheSFBactualoperationalstatus.</synopsis>

<typeRef>SFBStatusType</typeRef>

<defaultValue>2</defaultValue>

</component>

<componentaccess="read-write"componentID="3">

<name>currentSchedulingDiscipline</name>

<!--Scheduling strategy-->

<synopsis>

The current Scheduling Discipline component, which is for the

controller to specify ascheduling discipline to the SFB.

</synopsis>

<typeRef>schdDisciplineEntryType</typeRef>

</component>

</components>

</SFBClassDef>

The data formats used in the above class description are listed as follows:

<dataTypeDef>

<name>SFBStatusType</name>

<!--Service Function Block Status Type-->

<synopsis>

Type for SFB status, used for both administrative and operative status.

</synopsis>

<atomic>

<baseType>uint32</baseType>

<specialValues>

<specialValuevalue="0">

<name>Disabled</name>

<synopsis>Port disabled.</synopsis>

</specialValue>

<specialValuevalue="1">

<name>Up</name>

<synopsis>Portup.</synopsis>

</specialValue>

<specialValuevalue="2">

<name>Down</name>

<synopsis>Portdown.</synopsis>

</specialValue>

</specialValues>

</atomic>

</dataTypeDef>

<dataTypeDef>

<name>metadataDispatchTableType</name>

<!--Classification table type-->

<synopsis>Datatypeformetadatadispatchtable.</synopsis>

<arraytype="variable-size">

<typeRef>metadataDispatchEntryType</typeRef>

</array>

</dataTypeDef>

<dataTypeDef>

<name>metadataDispatchEntryType</name>

<!--Classification entry type-->

<synopsis>DatatypeformetadatadispatchtableusedinBasicMetadataDispatchSFB.Metadatavalueofthetableisalsodefinedasacontentkeyfield.</synopsis>

<struct>

<componentcomponentID="1">

<name>condition</name>

<!--Conditions-->

<synopsis>The condition which the metadata must follow.</synopsis>

<typeRef>metadataTableType</typeRef>

</component>

<componentcomponentID="2">

<name>action</name>

<!--action-->

<synopsis>Indexofagroupoutputportforoutgoingpackets.</synopsis>

<typeRef>portGroupType</typeRef>

</component>

</struct>

</dataTypeDef>

<dataTypeDef>

<name>metadataTableType</name>

<!--Metadata table type-->

<synopsis>TypeofthemetadataTable.</synopsis>

<arraytype="variable-size">

<typeRef>metadataEntryType</typeRef>

</array>

</dataTypeDef>

<dataTypeDef>

<name>portGroupType</name>

<!--Port Action Type-->

<synopsis>Type of the portgroups.</synopsis>

<arraytype="variable-size">

<typeRef>portType</typeRef>

</array>

</dataTypeDef>

<dataTypeDef>

<name>metadataEntryType</name>

<!--Metadata entry type-->

<synopsis>TypeofthemetadataEntry.</synopsis>

<struct>

<componentcomponentID="1">

<name>metadataID</name>

<synopsis>TheID which represents a dispatchmetadata.</synopsis>

<typeRef>uint32</typeRef>

</component>

<componentcomponentID="2">

<name>comparator</name>

<synopsis>The comparator can be chosen and can use astherelation of metadata and threshold value.</synopsis>

<typeRef>comparatorEnum</typeRef>

</component>

<componentcomponentID="3">

<name>thresholdValue</name>

<synopsis>The threshold value that the metadata must compare with.</synopsis>

<typeRef>arbitrary</typeRef>

</component>

</struct>

</dataTypeDef>

<dataTypeDef>

<name>comparatorEnum</name>

<!--Comparator type-->

<synopsis>The comparatorkinds.</synopsis>

<atomic>

<baseType>uint32</baseType>

<rangeRestriction>

<allowedRangemin="0"max="5"/>

</rangeRestriction>

<specifiedValues>

<specifiedValuevalue="0">

<name>equal</name>

<!--equal to -->

<synopsis>aequalsb.</synopsis>

</specifiedValue>

<specifiedValuevalue="1">

<name>greater</name>

<!--greater than-->

<synopsis>ais greater than b.</synopsis>

</specifiedValue>

<specifiedValuevalue="2">

<name>less</name>

<!--less than-->

<synopsis>aislessthanb.</synopsis>

</specifiedValue>

<specifiedValuevalue="3">

<name>equalOrGreater</name>

<!--greater than or equal to-->

<synopsis>aequalsorggreaterthanb.</synopsis>

</specifiedValue>

<specifiedValuevalue="4">

<name>equalOrLess</name>

<!--less than or equal to -->

<synopsis>aequalsorlessthanb.</synopsis>

</specifiedValue>

<specifiedValuevalue="5">

<name>notEqual</name>

<!--not equal to -->

<synopsis>aisnotequalwithb.</synopsis>

</specifiedValue>

</specifiedValues>

</atomic>

</dataTypeDef>

<dataTypeDef>

<name>portType</name>

<!--Port Action Type-->

<synopsis>Type of the portactions.</synopsis>

<atomic>

<baseType>int32</baseType>

<rangeRestriction>

<allowedRangemin="-1"max="32"/>

</rangeRestriction>

<specialValues>

<specialValuevalue="-1">

<name>drop</name>

<!--Packet loss-->

<synopsis>Packets dropped.</synopsis>

</specialValue>

<specialValuevalue="0">

<name>redirect</name>

<!--Redirection-->

<synopsis>Packets redirect to controllers.</synopsis>

</specialValue>

</specialValues>

</atomic>

</dataTypeDef>

<dataTypeDef>

<name>schdDisciplineEntryType</name>

<!--Scheduling policy entry type -->

<synopsis>TypeofschedulingdisciplineEntry.</synopsis>

<struct>

<componentcomponentID="1">

<name>schdDisciplineID</name>

<!--Scheduling strategy type-->

<synopsis>TheschedulingDisciplinecategory.</synopsis>

<typeRef>int32</typeRef>

</component>

<componentcomponentID="2">

<name>schdParamValue</name>

<!--Parameter value-->

<synopsis>Parametervalueseachschedulingdiscipline.</synopsis>

<typeRef>schdParamValueType</typeRef>

</component>

<componentcomponentID="3">

<name>flowWeight</name>

<!--The weight of each flow in the scheduling algorithm-->

<synopsis>Weightofeachflow.</synopsis>

<typeRef>flowWeightType</typeRef>

</component>

</struct>

</dataTypeDef>

<dataTypeDef>

<name>schdParamValueType</name>

<!--Parameter value type-->

<synopsis>

schdParamValue[0]:ThepointerofRoundRobinschedulingdiscipline.<!--The head pointer of RoundRobinschedulingdiscipline-->

schdParamValue[1]:TheschedulegaptimeofRoundRobinschedulingdiscipline.<!--The interval time of the round-robin scheduling algorithm-->

</synopsis>

<arraytype="variable-size">

<typeRef>arbitrary</typeRef>

</array>

</dataTypeDef>

<dataTypeDef>

<name>flowWeightType</name>

<!--The weight of the flow-->

<synopsis>

flowWeight[1~n]:theweightoffflow1toflown,flow1meanstheflowcomesfromport1.

</synopsis>

<arraytype="variable-size">

<typeRef>float16</typeRef>

</array>

</dataTypeDef>

In the third step, the network node reports the resource status of the network node to the controller, including the optional secondary functional elements, metadata and scheduling algorithm. In this embodiment, network nodes S1 and S2 report the same secondary function element library, namely:

<SFBComponentLib>

<dataTypeDef>

<name>rateStatsTableType</name>

<!--Traffic statistics table type-->

<synopsis>

</synopsis>

<arraytype="variable-size">

<typeRef>rateStatsEntryType</typeRef>

</array>

</dataTypeDef>

<dataTypeDef>

<name>rateStatsEntryType</name>

<!--Traffic statistics entry type-->

<synopsis>

</synopsis>

<struct>

<componentcomponentID="1">

<name>metadataID</name>

<!--Metadata value-->

<synopsis>

</synopsis>

<typeRef>uint32</typeRef>

</component>

<componentcomponentID="2">

<name>comparator</name>

<!--Comparator-->

<synopsis>

</synopsis>

<typeRef>comparatorEnum</typeRef>

</component>

<componentcomponentID="3">

<name>thresholdValue</name>

<!--threshold-->

<synopsis>

</synopsis>

<typeRef>arbitrary</typeRef>

</component>

<componentcomponentID="4">

<name>rateNum</name>

<!--speed value-->

<synopsis>

</synopsis>

<typeRef>float16</typeRef>

</component>

</struct>

</dataTypeDef>

<dataTypeDef>

<name>queueStatsTableType</name>

<!--Queuing status table type-->

<synopsis>Datatypeforqueuestatisticstable.</synopsis>

<arraytype="variable-size">

<typeRef>queueStatsType</typeRef>

</array>

</dataTypeDef>

<dataTypeDef>

<name>queueStatsType</name>

<!--queuing status type-->

<synopsis>DatatypeforentryofqueuestatisticstableinSFB.</synopsis>

<struct>

<componentcomponentID="1">

<name>queueID</name>

<!--Queue ID-->

<synopsis>TheinputqueueID.</synopsis>

<typeRef>uint32</typeRef>

</component>

<componentcomponentID="2">

<name>queueDepthInPackets</name>

<!--Queue length (in packets)-->

<synopsis>Currentqueue depthinpackets.</synopsis>

<typeRef>uint32</typeRef>

</component>

<componentcomponentID="3">

<name>queueDepthInBytes</name>

<!--Queue length (in byte packets)-->

<synopsis>Currentqueue depthinbytes.</synopsis>

<typeRef>uint32</typeRef>

</component>

</struct>

</dataTypeDef>

<SFBComponentsClassID="1">

<componentaccess="read-only"componentID="4">

<name>rateStats</name>

<!--Rate status query-->

<synopsis>TherateStatscomponent, which is defined to allow the controller to query every rate statistics in the scheduler.</synopsis>

<typeRef>rateStatsTableType</typeRef>

</component>

<componentaccess="read-only"componentID="5">

<name>rateLimit</name>

<!--Rate limit-->

<synopsis>TherateLimitcomponent, which specifies the maximum rate of each flow in a fixed time.</synopsis>

<typeRef>uint32</typeRef>

</component>

<componentaccess="read-write"componentID="6">

<name>redirection</name>

<!--Redirect action-->

<synopsis>There redirection component, which can redirect the overloaded flow to other free servers.</synopsis>

<typeRef>uint32</typeRef>

<componentaccess="read-only"componentID="7">

<name>infoStats</name>

<!--Information Statistics-->

<synopsis>The statistical information of the network.</synopsis>

<typeRef>rateStatsTableType</typeRef>

</SFBComponents>

<SFBComponentsClassID="2">

<componentaccess="read-only"componentID="4">

<name>queueStats</name>

<!--queuing status-->

<synopsis>The queueStats component, which is defined to allow the controller to query every queue statistics in the scheduler.</synopsis>

<!--The queuing status identifies the length of each input queue, and the controller determines which scheduling strategy to use by querying the queuing status-->

<typeRef>queueStatsTableType</typeRef>

</component>

<componentaccess="read-write"componentID="5">

<name>queueLenLimit</name>

<!--Captain limit-->

<synopsis>ThequeueLenLimitcomponent, which specifies maximumlengthofeachqueue.Thelengthunitisinpackets.</synopsis>

<!--The controller can decide to start the scheduling strategy according to whether the captain limit is exceeded-->

<typeRef>uint32</typeRef>

</component>

</SFBComponents>

</SFBComponentLib>

Network node S1 reports metadata:

<metadataLib>

<componentcomponentID="1">

<name>ingressPort</name>

<!--Input port-->

<synopsis>The input port of the packets.</synopsis>

</component>

<componentcomponentID="2">

<name>EtherSrcAddress</name>

<!--Source Ethernet address-->

<synopsis>TheEthernetsourceaddress.</synopsis>

</component>

<componentcomponentID="3">

<name>EtherDstAddress</name>

<!--Destination Ethernet address-->

<synopsis>TheEthernetdestinationaddress.</synopsis>

</component>

<componentcomponentID="4">

<name>EtherType</name>

<!--Ethernet packet type-->

<synopsis>ThetypeofanEthernetpacketheader.</synopsis>

</component>

<componentcomponentID="5">

<name>VlanID</name>

<!--Vlan Number-->

<synopsis>The identification of a Vlan.</synopsis>

</component>

<componentcomponentID="6">

<name>VlanPriority</name>

<!--Vlan Priority-->

<synopsis>The priority of avlan.</synopsis>

</component>

<componentcomponentID="7">

<name>IPSrcAddress</name>

<!--Source IP address-->

<synopsis>TheIPsourceaddress.</synopsis>

</component>

<componentcomponentID="8">

<name>IPDstAddress</name>

<!--Destination IP address-->

<synopsis>The IP destination address.</synopsis>

</component>

<componentcomponentID="9">

<name>IPProto</name>

<!--IP protocol type-->

<synopsis>The identification of an IP protocol.</synopsis>

</component>

<componentcomponentID="10">

<name>IPTos</name>

<!--IP QoS type-->

<synopsis>The type of service bit.</synopsis>

</component>

<componentcomponentID="11">

<name>TCP/UDPSrcPort</name>

<!--TCP/UDP source port-->

<synopsis>The source port of TCP/UDP.</synopsis>

</component>

<componentcomponentID="12">

<name>TCP/UDPDstPort</name>

<!--TCP/UDP destination port-->

<synopsis>The destination port of TCP/UDP.</synopsis>

</component>

</metadataLib>

Scheduling algorithm reported by network node S1:

<schdDisciplineLib>

<componentcomponentID="1">

<name>FCFS</name>

<!--First come first serve algorithm-->

<synopsis>First Come First Served scheduling discipline.</synopsis>

</component>

<componentcomponentID="2">

<name>RR</name>

<!--Circular Scheduling Algorithm-->

<synopsis>Round Robins scheduling discipline.</synopsis>

</component>

<componentcomponentID="3">

<name>WRR</name>

<!--Weighted round-robin scheduling algorithm-->

<synopsis>WeightedRoundRobinschedulingdiscipline.</synopsis>

</component>

<componentcomponentID="4">

<name>SP</name>

<!--Strict priority algorithm-->

<synopsis>StrictPriorityschedulingdiscipline.</synopsis>

</component>

</schdDisciplineLib>

Network node S2 reports metadata:

<metadataLib>

<componentcomponentID="1">

<name>ingressPort</name>

<synopsis>The input port of the packets.</synopsis>

</component>

<componentcomponentID="2">

<name>EtherSrcAddress</name>

<synopsis>TheEthernetsourceaddress.</synopsis>

</component>

<componentcomponentID="3">

<name>EtherDstAddress</name>

<synopsis>TheEthernetdestinationaddress.</synopsis>

</component>

<componentcomponentID="4">

<name>EtherType</name>

<synopsis>ThetypeofanEthernetpacketheader.</synopsis>

</component>

<componentcomponentID="5">

<name>VlanID</name>

<synopsis>The identification of a Vlan.</synopsis>

</component>

<componentcomponentID="6">

<name>VlanPriority</name>

<synopsis>The priority of avlan.</synopsis>

</component>

<componentcomponentID="7">

<name>IPSrcAddress</name>

<synopsis>TheIPsourceaddress.</synopsis>

</component>

<componentcomponentID="8">

<name>IPDstAddress</name>

<synopsis>The IP destination address.</synopsis>

</component>

<componentcomponentID="9">

<name>IPProto</name>

<synopsis>The identification of an IP protocol.</synopsis>

</component>

<componentcomponentID="10">

<name>IPTos</name>

<synopsis>The type of service bit.</synopsis>

</component>

<componentcomponentID="11">

<name>TCP/UDPSrcPort</name>

<synopsis>The source port of TCP/UDP.</synopsis>

</component>

<componentcomponentID="12">

<name>TCP/UDPDstPort</name>

<synopsis>The destination port of TCP/UDP.</synopsis>

</component>

<componentcomponentID="13">

<name>serverLatency</name>

<synopsis>Thelatencyofeachserver.</synopsis>

</component>

</metadataLib>

In the fourth step, the controller designs a service function instance chain according to the resource status of the network nodes and the service function chain information, and the service function instance chain is formed by connecting the first bits of the service function blocks. As shown in FIG. 3 , the service function instance chain in this embodiment includes the authentication service function block on the network node S1 , the flow management service function block and the load balancing service function block on the network node S2 .

Step 5: For network nodes that support service function blocks, the controller sends the description of the service function instance chain directly to the relevant network nodes and requests to reserve resources. For network nodes that support OpenFlow, the controller sends the service function instance chain The description is converted into a flow table and then issued. In this embodiment, both the network nodes S1 and S2 support the service function block, so the description of the service function instance chain can be delivered directly.

The description of the authentication service functional block on the network node S1 is as follows:

<SFBInstanceDefs>

<SFBInstanceDefSFBInstanceID="1">

<name>Authentication</name>

<!--Authentication-->

<synopsis>aSFBto divide the authenticated flow and non-authenticated flow.</synopsis>

<version>1.0</version>

<classID>1</classID>

<inputPorts>

<inputPort>

<name>pktsIn</name>

<ID>1</ID>

<synopsis>

Inputportofpackets.EachinputporthasanuniqueID.

</synopsis>

<expectation>

<frameExpected>

<ref>IPv4</ref>

</frameExpected>

<metadataExpected>

<ref>PHYPortID</ref>

</metadataExpected>

</expectation>

</inputPort>

</inputPorts>

<outputPorts>

<outputPort>

<name>normalPort1</name>

<ID>2</ID>

<synopsis>

The normal port in which the flow will be sent to the following network devices.

</synopsis>

<product>

<frame Produced>

<ref>IPv4</ref>

</frame Produced>

</product>

<nextInstanceID>2</nextInstanceID>

<nextPortID>1</nextPortID>

<!--Connect to port 1 of the service function block numbered 2-->

</outputPort>

<outputPort>

<name>normalPort2</name>

<ID>3</ID>

<synopsis>

The normal port in which the flow will be sent to the following network devices.

</synopsis>

<product>

<frame Produced>

<ref>IPv4</ref>

</frame Produced>

</product>

<nextInstanceID>2</nextInstanceID>

<nextPortID>2</nextPortID>

<!--Indicates that it is connected to the 2 port of the service function block numbered 2-->

</outputPort>

<outputPort>

<name>auditPort</name>

<ID>4</ID>

<synopsis>An audit port in which the flow will be sent for auditing.</synopsis>

<product>

<frame Produced>

<ref>IPv4</ref>

</frame Produced>

</product>

<nextInstanceID>-1</nextInstanceID>

<nextPortID>5</nextPortID>

<!--5 indicates that it is connected to the physical port numbered 5, and -1 indicates that it is not connected to the service function block -->

</outputPort>

</outputPorts>

<componentValues>

<componentValuecomponentID="1">

<value>1</value>

<!--Indicates that this service function block has been set to work by the controller-->

</componentValue>

<componentValuecomponentID="2">

<value>1</value>

<!--Indicates that the service function block is in normal working state-->

</componentValue>

<componentValuecomponentID="3">

<metadataDispatchEntryType>

<!--This entry indicates that the source IP address is 10.20.4.0/24 network segment, the destination address is not 10.20.4.0/24 network segment, and the data packet with the destination IP address 10.20.9.1 and input port 4 is sent to this service normalPort and auditPort of the function block -->

<condition>

<metadataEntryType>

<metadataID>7</metadataID>

<!--Indicates that the IP source address is used as metadata -->

<comparator>0</comparator>

<!--Indicates that the comparator is equal to -->

<thresholdValue>10.20.4.0/24</thresholdValue>

<!--The comparison threshold is 10.20.4.0/24-->

</metadataEntryType>

<metadataEntryType>

<metadataID>8</metadataID>

<!--Indicates that the IP destination address is used as metadata -->

<comparator>5</comparator>

<!--Indicates that the comparator is not equal to -->

<thresholdValue>10.20.4.0/24</thresholdValue>

</metadataEntryType>

<metadataEntryType>

<metadataID>1</metadataID>

<!--Indicates that the input port is used as metadata -->

<comparator>0</comparator>

<!--Indicates that the comparator is equal to -->

<thresholdValue>4</thresholdValue>

</metadataEntryType>

<metadataEntryType>

<metadataID>7</metadataID>

<comparator>0</comparator>

<thresholdValue>10.20.9.1</thresholdValue>

</metadataEntryType>

</condition>

<action>

<portType>2</portType>

<portType>3</portType>

<!--Indicates that the action is forwarded to ports numbered 2 and 3 in this service function block-->

</action>

</metadataDispatchEntryType>

<metadataDispatchEntryType>

<!--This entry indicates that the source IP address is 10.20.4.0/24 network segment, the destination address is not 10.20.4.0/24 network segment and the data packet with input port 4 is sent to the normalPort of the service function block-->

<condition>

<metadataEntryType>

<metadataID>7</metadataID>

<comparator>0</comparator>

<thresholdValue>10.20.4.0/24</thresholdValue>

</metadataEntryType>

<metadataEntryType>

<metadataID>8</metadataID>

<comparator>5</comparator>

<thresholdValue>10.20.4.0/24</thresholdValue>

</metadataEntryType>

<metadataEntryType>

<metadataID>1</metadataID>

<comparator>0</comparator>

<thresholdValue>4</thresholdValue>

</metadataEntryType>

</condition>

<action>

<portType>2</portType>

</action>

</metadataDispatchEntryType>

<metadataDispatchEntryType>

<!--This entry indicates that the source IP address is 10.20.5.0/24 network segment, the destination address is not 10.20.5.0/24 network segment, and the data packet with the destination IP address 10.20.9.1 and input port 3 is sent to this service normalPort and auditPort of the function block -->

<condition>

<metadataEntryType>

<metadataID>7</metadataID>

<comparator>0</comparator>

<thresholdValue>10.20.5.0/24</thresholdValue>

</metadataEntryType>

<metadataEntryType>

<metadataID>8</metadataID>

<comparator>5</comparator>

<thresholdValue>10.20.5.0/24</thresholdValue>

</metadataEntryType>

<metadataEntryType>

<metadataID>1</metadataID>

<comparator>0</comparator>

<thresholdValue>3</thresholdValue>

</metadataEntryType>

<metadataEntryType>

<metadataID>7</metadataID>

<comparator>0</comparator>

<thresholdValue>10.20.9.1</thresholdValue>

</metadataEntryType>

</condition>

<action>

<portType>2</portType>

<portType>3</portType>

</action>

</metadataDispatchEntryType>

<metadataDispatchEntryType>

<!--This entry indicates that the source IP address is 10.20.5.0/24 network segment, the destination address is not 10.20.5.0/24 network segment and the data packet with input port 3 is sent to the normalPort of the service function block-->

<condition>

<metadataEntryType>

<metadataID>7</metadataID>

<comparator>0</comparator>

<thresholdValue>10.20.5.0/24</thresholdValue>

</metadataEntryType>

<metadataEntryType>

<metadataID>8</metadataID>

<comparator>5</comparator>

<thresholdValue>10.20.5.0/24</thresholdValue>

</metadataEntryType>

<metadataEntryType>

<metadataID>1</metadataID>

<comparator>0</comparator>

<thresholdValue>3</thresholdValue>

</metadataEntryType>

</condition>

<action>

<portType>2</portType>

</action>

</metadataDispatchEntryType>

<metadataDispatchEntryType>

<!--This entry indicates that the source IP address is 10.20.6.0/24 network segment, the destination address is not 10.20.6.0/24 network segment, and the data packet with the destination IP address 10.20.9.1 and input port 2 is sent to this service normalPort and auditPort of the function block -->

<condition>

<metadataEntryType>

<metadataID>7</metadataID>

<comparator>0</comparator>

<thresholdValue>10.20.6.0/24</thresholdValue>

</metadataEntryType>

<metadataEntryType>

<metadataID>8</metadataID>

<comparator>5</comparator>

<thresholdValue>10.20.6.0/24</thresholdValue>

</metadataEntryType>

<metadataEntryType>

<metadataID>1</metadataID>

<comparator>0</comparator>

<thresholdValue>2</thresholdValue>

</metadataEntryType>

<metadataEntryType>

<metadataID>7</metadataID>

<comparator>0</comparator>

<thresholdValue>10.20.9.1</thresholdValue>

</metadataEntryType>

</condition>

<action>

<portType>2</portType>

<portType>3</portType>

</action>

</metadataDispatchEntryType>

<metadataDispatchEntryType>

<!--This entry indicates that the source IP address is 10.20.6.0/24 network segment, the destination address is not 10.20.6.0/24 network segment and the data packet with input port 2 is sent to the normalPort of the service function block-->

<condition>

<metadataEntryType>

<metadataID>7</metadataID>

<comparator>0</comparator>

<thresholdValue>10.20.6.0/24</thresholdValue>

</metadataEntryType>

<metadataEntryType>

<metadataID>8</metadataID>

<comparator>5</comparator>

<thresholdValue>10.20.6.0/24</thresholdValue>

</metadataEntryType>

<metadataEntryType>

<metadataID>1</metadataID>

<comparator>0</comparator>

<thresholdValue>2</thresholdValue>

</metadataEntryType>

</condition>

<action>

<portType>2</portType>

</action>

</metadataDispatchEntryType>

<metadataDispatchEntryType>

<!--This entry indicates that the data packet with the destination address 10.20.7.0/24 is sent to port 2 of the service function block-->

<condition>

<metadataEntryType>

<metadataID>8</metadataID>

<comparator>0</comparator>

<thresholdValue>10.20.7.0/24</thresholdValue>

</metadataEntryType>

</condition>

<action>

<portType>2</portType>

</action>

</metadataDispatchEntryType>

<metadataDispatchEntryType>

<!--This entry indicates that the data packet with the destination address 10.20.7.0/24 is sent to port 3 of the service function block-->

<condition>

<metadataEntryType>

<metadataID>8</metadataID>

<comparator>0</comparator>

<thresholdValue>10.20.9.1</thresholdValue>

</metadataEntryType>

</condition>

<action>

<portType>3</portType>

</action>

</metadataDispatchEntryType>

</componentValue>

</componentValues>

</SFBInstanceDef>

The flow management service functional block on the network node S1 is described as follows:

<SFBInstanceDefSFBInstanceID="2">

<name>Traffic Management</name>

<!--Traffic management-->

<synopsis>ASFBto manage the traffic.</synopsis>

<version>1.0</version>

<ClassID>2</ClassID>

<inputPorts>

<inputPort>

<name>pktsIn1</name>

<ID>1</ID>

<synopsis>

ThegroupinputportoftheSFB.EachinputporthasanuniqueID.

</synopsis>

<expectation>

<frameExpected>

<ref>IPv4</ref>

</frameExpected>

</expectation>

</inputPort>

<inputPort>

<name>pktsIn2</name>

<ID>2</ID>

<synopsis>

ThegroupinputportoftheSFB.EachinputporthasanuniqueID.

</synopsis>

<expectation>

<frameExpected>

<ref>IPv4</ref>

</frameExpected>

</expectation>

</inputPort>

</inputPorts>

<outputPorts>

<outputPort>

<name>pksOut</name>

<ID>3</ID>

<!--The port number is 2-->

<synopsis>

The output port of the SFB. Scheduled packets are output from the port.

</synopsis>

<product>

<frame Produced>

<ref>IPv4</ref>

</frame Produced>

</product>

<nextInstanceID>-1</nextInstanceID>

<nextPortID>1</nextPortID>

</outputPort>

</outputPorts>

<componentValues>

<componentValuecomponentID="1">1</componentValue>

<componentValuecomponentID="2">1</componentValue>

<componentValuecomponentID="3">

<!--This entry indicates that the strict priority policy is used, and the pksOut port of the service function block is sent in order according to the weight of the flow, no parameters are required -->

<schdDisciplineEntryType>

<schdDisciplineID>4</schdDisciplineID>

<!--4 indicates the use of strict priority strategy -->

<schdParamValue>

<schdParamValueType>null</schdParamValueType>

<schdParamValueType>null</schdParamValueType>

<!--null means that the strategy does not require parameters -->

</schdParamValue>

<flowWeight>

<flowWeightType>5</flowWeightType>

<flowWeightType>2</flowWeightType>

</flowWeight>

</schdDisciplineEntryType>

</componentValue>

<componentValuecomponentID="5">50</componentValue>

<!--This entry indicates that the scheduling algorithm is started when the queue length exceeds 50 packets-->

</componentValues>

</SFBInstanceDef>

The load balancing service function block on the network node S2 is described as follows:

<SFBInstanceDefSFBInstanceID="3">

<name>Server_LB</name>

<!--Load Balancing-->

<synopsis>ASFB for balancing the load of each server.</synopsis>

<version>1.0</version>

<classID>1</classID>

<inputPorts>

<inputPort>

<name>pktsIn</name>

<ID>1</ID>

<synopsis>

ThegroupinputportoftheSFB.EachinputporthasanuniqueID.

</synopsis>

<expectation>

<frameExpected>

<ref>arbitrary</ref>

</frameExpected>

</expectation>

</inputPort>

</inputPorts>

<outputPorts>

<outputPort>

<name>pktsOut1</name>

<ID>2</ID>

<synopsis>The output port 1 of the SFB. Scheduled packets are output from the physical port 1.</synopsis>

<product>

<nextInstanceID>-1</nextInstanceID>

<nextPortID>1</nextPortID>

<frame Produced>

<ref>arbitrary</ref>

</frame Produced>

</product>

</outputPort>

<outputPort>

<name>pktsOut2</name>

<ID>3</ID>

<synopsis>The output port 2 of the SFB. Scheduled packets are output from the physical port 2.</synopsis>

<product>

<nextInstanceID>-1</nextInstanceID>

<nextPortID>2</nextPortID>

<frame Produced>

<ref>arbitrary</ref>

</frame Produced>

</product>

</outputPort>

<outputPort>

<name>pktsOut3</name>

<ID>4</ID>

<synopsis>The output port 3 of the SFB. Scheduled packets are output from the physical port 3.</synopsis>

<product>

<nextInstanceID>-1</nextInstanceID>

<nextPortID>3</nextPortID>

<frame Produced>

<ref>arbitrary</ref>

</frame Produced>

</product>

</outputPort>

<outputPort>

<name>pktsOut4</name>

<ID>5</ID>

<synopsis>The output port 4 of the SFB. Scheduled packets are output from the physical port 4.</synopsis>

<product>

<nextInstanceID>-1</nextInstanceID>

<nextPortID>4</nextPortID>

<frame Produced>

<ref>arbitrary</ref>

</frame Produced>

</product>

</outputPort>

<outputPort>

<name>pktsOut5</name>

<ID>6</ID>

<synopsis>The output port 5 of the SFB. Scheduled packets are output from the physical port 5.</synopsis>

<product>

<nextInstanceID>-1</nextInstanceID>

<nextPortID>5</nextPortID>

<frame Produced>

<ref>arbitrary</ref>

</frame Produced>

</product>

</outputPort>

</outputPorts>

<componentValues>

<componentValuecomponentID="1">

<value>1</value>

</componentValue>

<componentValuecomponentID="2">

<value>1</value>

</componentValue>

<componentValuecomponentID="3">

<metadataDispatchEntryType>

<!--This entry indicates that according to the current policy, the traffic to access the cloud server should go to pksOut1 with the smallest delay-->

<condition>

<metadataEntryType>

<metadataID>8</metadataID>

<comparator>0</comparator>

<thresholdValue>10.20.7.0/24</thresholdValue>

</metadataEntryType>

</condition>

<action>

<portType>2</portType>

</action>

</metadataDispatchEntryType>

<metadataDispatchEntryType>

<!--This entry indicates that the traffic with the destination address 10.20.9.1 is sent to pksOut5-->

<condition>

<metadataEntryType>

<metadataID>8</metadataID>

<comparator>0</comparator>

<thresholdValue>10.20.9.1</thresholdValue>

</metadataEntryType>

</condition>

<action>

<portType>6</portType>

</action>

</metadataDispatchEntryType>

</componentValue>

</componentValues>

</SFBInstanceDef>

</SFBInstanceDefs>

Finally, network nodes deploy network service function instance chains.

Claims (2)

1. towards a service function chain building method of SDN, it is characterized in that, in SDN structure, realize at network node on-premise network service function block example for network service request, comprise the following steps:

The Network demand that 1-1) controller proposes according to user creates service function chain, and service function chain forms by several service functions are end to end;

1-2) service function is supported by service function block and realizes, and service function block is divided into two large classes, is respectively classified service functional block class and dispatch service functional block class;

1-3) network node is to this network node resource situation of controller report, includes optional secondary function element, metadata and dispatching algorithm;

1-4) controller is according to the resource situation of network node and service functional chain information design service function example chain, and service function example chain forms by service function block is end to end;

1-5) for the network node of Service supportive functional block, the description of service function example chain is directly issued to relevant network node and requires reserved resource by controller, for the network node supporting OpenFlow, the description of service function example chain is converted into stream table and issues by controller;

1-6) network node deployment services function example chain.

2. a kind of service function chain building method towards SDN according to claim 1, it is characterized in that, described step 1-2) service function by service function block support realize, service function block is divided into two large classes, be respectively classified service functional block class and dispatch service functional block class, concrete grammar is:

2-1) contain the function of tonic chord element that the service function block in such is owned together in service function block class;

2-2) in service function block except function of tonic chord element value, also have input/output port, inputoutput data bag, input and output metadata, subfunction element value etc.;

2-3) main task of classified service functional block class is classified according to metadata to packet;

2-4) main task of dispatch service functional block class carries out dispatch deal to packet, if when having multiple data flow all to need to go out from same port, so with regard to sending order and the rhythm of these streams of layout.