CN115514691A - Blockchain-based SDN inter-domain cooperative forwarding control architecture and method - Google Patents

Abstract

The invention belongs to the technical field of internet, and particularly relates to a cooperative forwarding control architecture and method between SDN domains based on a block chain, wherein a block chain function node and an SDN controller of each SDN domain are deployed in an SDN domain local server, the block chain function node forms a block chain network in a P2P mode, a block chain global account book is stored in each SDN domain, and a local application program interface is utilized to realize interaction between a block chain-based policy forwarding control application and the controller and the block chain, wherein the policy forwarding control application comprises: the system comprises a domain information manager used for registering and dynamically updating domain information, generating domain information transaction and uploading the domain information transaction to a block chain, a policy manager used for formulating an inter-domain forwarding control policy, generating a policy transaction and uploading the policy transaction to the block chain, and a policy coordination engine used for executing attribute mapping, policy matching and path synthesis by inquiring a local cache and acquiring a global coordination policy. The invention controls the forwarding path of the SDN cross-domain data flow through a strategy facing to the data flow and the path attribute, and realizes the high-efficiency and safe forwarding control between SDN domains by using a block chain.

Description

Blockchain-based SDN inter-domain collaborative forwarding control architecture and method

technical field

The invention belongs to the technical field of the Internet, and in particular relates to a blockchain-based SDN inter-domain coordinated forwarding control framework and method.

Background technique

With the continuous enrichment and development of Internet services and applications, user needs are gradually changing from simple accessibility to security, service quality, traffic engineering and other aspects, which puts higher demands on network expression ability and network management and control ability. Require. As a new network architecture, SDN has the characteristics of separation of forwarding control, centralized logic, and open programmability, which provides a good foundation for flexible and efficient network forwarding control. As SDN is widely used in cloud, data center, mobile communication network, Internet of Things, industrial Internet and other fields, how to realize SDN cross-domain forwarding control has become an urgent problem to be solved.

At present, most of the SDN forwarding control schemes are concentrated in the SDN domain, and there are very few schemes about the forwarding control between SDN domains. In existing solutions, the policy-based SDN security architecture PbSA has the function of cross-domain forwarding control. PbSA defines a data flow and path-oriented security policy paradigm, and transmits policies through policy tokens on the SDN data plane. The policy tokens are transmitted together with the data packets. Every time a transport domain is reached, the policy tokens are uploaded to the SDN controller, and The strategy of the joint transport domain jointly determines the next forwarding domain of the data packet. However, this solution faces the following two shortcomings: on the one hand, when there is a policy conflict between the source domain and the transmission domain, it will cause data transmission interruption; Transmission faces security risks.

Blockchain technology has been widely used in data sharing and access control, however, there is no research on using blockchain technology for SDN cross-domain forwarding control. Since the research purposes and objects of forwarding control and access control are different, and more importantly, compared with access control, forwarding control is more sensitive to delay and computing overhead. Therefore, how to reasonably apply blockchain to SDN Inter-domain policy forwarding control needs to be further studied, that is, on the basis of providing security and building trusted services, keep the impact on data forwarding within a reasonable range, and minimize the impact on data forwarding.

In the research on the combination of blockchain and SDN, its architecture is different due to different research objectives. In the first category, the blockchain and SDN are independently deployed and communicate remotely through the REST API. However, due to the independent deployment of the two, the remote communication overhead is relatively high. At the same time, in order to ensure the security of remote communication between SDN and blockchain nodes, a security mechanism needs to be introduced, which will further increase the calculation and delay overhead, so it is not suitable for delay sensitivity. application. In the second category, blockchain nodes communicate through the SDN network infrastructure, that is, data forwarding between blockchain nodes is centrally controlled by the SDN controller. The disadvantage of this type of scheme is that the blockchain nodes are controlled by the SDN controller, which loses the essential attribute of blockchain decentralization. Once the SDN controller is successfully attacked, the attacker can control the communication of the entire blockchain network, thereby Seriously threaten the security and credibility of the blockchain business. The third category is to deploy the blockchain to the SDN control plane. This method is suitable for SDN cross-domain management, but no research has yet proposed a solution for SDN inter-domain forwarding control. To sum up, there is no good solution to the challenges faced by SDN inter-domain forwarding control and the deficiencies of existing technologies.

Contents of the invention

For this reason, the present invention provides a block chain-based SDN inter-domain cooperative forwarding control architecture and method. From the perspective of security, the forwarding path of SDN cross-domain data flow is controlled through policies to realize the physical isolation of the data flow forwarding path. And channelized management, using blockchain to realize efficient and safe forwarding control between SDN domains, which is convenient for actual scene applications.

According to the design scheme provided by the present invention, a block chain-based SDN inter-domain cooperative forwarding control architecture is provided, including: block chain-based policy forwarding control applications, block chain function nodes and SDN controllers in each SDN domain Deployed in the local server of the SDN domain, and the blockchain functional nodes form a blockchain network through P2P, each SDN domain stores the global account book of the blockchain, and uses the local application program interface to realize the policy forwarding control application and the controller and the block Interaction between chains. Among them, the policy forwarding control application includes: a domain information manager for registering and dynamically updating domain information and generating domain information transactions to upload to the blockchain; A policy manager, and a policy coordination engine for performing attribute mapping, policy matching, and path composition by querying the local cache of the SDN controller to obtain a global coordination policy.

As the block chain-based SDN inter-domain collaborative forwarding control architecture of the present invention, further, block chain function nodes use domain information to manage smart contracts to execute domain information release or update, use policy management smart contracts to execute policy release or update, use consensus The mechanism confirms the released or updated domain information or policy information on the chain and writes the confirmed domain information and policies into the ledger database of each SDN domain blockchain node, and then dynamically updates the domain information and policy information in the smart contract account in real time Synchronize to the local cache of the SDN controller, and finally realize safe and trusted regional information and policy sharing in the distributed SDN inter-domain environment.

Further, based on the above-mentioned architecture, the present invention also provides a blockchain-based SDN inter-domain collaborative forwarding control method, including the following content:

The domain information and cross-domain forwarding strategy of each SDN domain are uploaded to the blockchain, and the domain information and cross-domain forwarding strategy are released or updated by the smart contract in the blockchain, and the functional nodes of the blockchain will be used to publish or update Synchronize the domain information and forwarding control policy to the local cache;

For the new data flow received by the ingress switch, by querying the flow table, if there is a matching flow entry, it will be forwarded according to the matching flow entry; if there is no matching flow entry, the first packet of the data flow will be uploaded through the pack-in message To the SDN controller, the SDN baseline controller interacts with the policy coordination engine to obtain the global coordination strategy;

Based on the obtained global collaboration policy, the SDN baseline controller combines the global domain-level network view and obtains the domain-level forwarding path that meets the constraints of the global policy through inter-domain path calculation; uses the east-west interface between SDN controllers to control the forwarding domain The controller distributes path segments, and each SDN controller issues flow entries according to the path segments to realize cross-domain forwarding control.

As the block chain-based SDN inter-domain cooperative forwarding control method of the present invention, further, when the block chain releases or updates domain information and cross-domain forwarding strategies, the domain information of each SDN domain is generated into a domain information transaction, through The signature is uploaded to the blockchain; the cross-domain forwarding strategy of each domain is encapsulated into a policy transaction, and uploaded to the blockchain through the signature; Or release and update the forwarding control strategy, and use the blockchain function node to dynamically synchronize the domain information in the smart contract and the forwarding control strategy in the policy management contract to the local cache in real time.

As the blockchain-based SDN inter-domain collaborative forwarding control method of the present invention, further, the domain information uploaded to each SDN domain on the blockchain at least includes: entity attribute information and identification mapping relationship, wherein the entity attribute information includes: The domain, user, and device information in the domain, and the identification mapping relationship include: the mapping relationship between the IP address, the user identification, and the equipment identification.

As the blockchain-based SDN inter-domain cooperative forwarding control method of the present invention, further, the cross-domain forwarding policy of each SDN domain uploaded to the blockchain is represented by a tuple, and the specific paradigm is expressed as: policy=<domID, policyID, policyType, SrcAP, DstAP, ServAP, Path, action>, among them, domID indicates the domain ID of the policy formulation, policyID indicates the identification of the policy in this domain, and policyType indicates the policy type, and the policy type is divided into constraining the domain source Source policy for sending data streams and bearer policies for filtering data streams from other domains. SrcAP represents the source attribute constraints on data streams, DstAP represents the destination attribute constraints on data streams, and ServAP represents network service attributes on data streams Constraint, Path represents the path constraint on the data flow, and action represents the forwarding action on the policy-constrained path for the data flow that satisfies the policy constraint.

As the block chain-based SDN inter-domain cooperative forwarding control method of the present invention, further, in the interaction between the SDN baseline controller and the policy coordination engine to obtain the global coordination strategy, firstly, the data packet header key is obtained by parsing the flow policy request field, by querying the domain information in the local cache of the SDN controller to map the data flow network identifier with the business attribute; then, according to the data flow attribute, read the policy set in the local cache of the SDN controller, and obtain the match through policy matching strategy set; finally, a global collaborative strategy with global path constraints is obtained by performing path composition on the matched strategy set.

As the block chain-based SDN inter-domain cooperative forwarding control method of the present invention, further, when mapping the data flow network identifier and business attributes, read the source IP, destination IP and port number or Protocol type; obtain the set of attribute name-value pairs of the source domain, source user, and source device according to the source IP to form the source attribute of the data flow; obtain the set of attribute name-value pairs of the destination domain, destination user, and destination device according to the destination IP to form data The destination attribute of the flow; obtain the network service attribute according to the port number or protocol type; combine the source attribute, destination attribute and network service attribute to form the business attribute set of the data flow, and generate the corresponding flow identifier according to the key field of the data flow; through the joint flow identifier and business attribute sets to complete the mapping between data flow network identifiers and business attributes.

As the block chain-based SDN inter-domain cooperative forwarding control method of the present invention, further, when obtaining the matching policy set through policy matching, firstly, obtain the originating policy of the source domain according to the source domain identifier of the data stream and obtain each The bearing policy of the domain, the source policy and the bearer policy constitute a related policy set; then, for each policy in the related policy set, if the attribute set of the data flow satisfies all the attribute predicate constraints in the policy, the corresponding policy is used as the matching policy , otherwise, traverse the next policy until all the policies in the relevant policy set are traversed, and then the matching policy set is obtained.

As the blockchain-based SDN inter-domain collaborative forwarding control method of the present invention, further, when performing path synthesis, the global collaborative policy with global path constraints is obtained by matching the policy type, path constraints, and actions in the policy set, wherein , obtain the global collaborative policy from the policy type, path constraint and action in the matching policy set, specifically including the following situations: for each source policy in the matching policy set, if the action is forward, write its path constraint into the flow path constraint, If its action is drop, its path constraint will be reversed and written into the stream path constraint; for each bearer policy in the matching policy set, if its path constraint is not empty, the contract will be violated and an error will be reported. If its path constraint If it is empty and the action is drop, the corresponding domain identifier will be reversed and written into the flow path constraint. If the path constraint is empty and the action is forward, data forwarding will not be affected until all bearer policies are traversed; finally, the combined flow Identifier, flow path constraints and action forward constitute a global collaborative strategy with global path constraints.

Beneficial effects of the present invention:

The present invention utilizes the data flow and path attribute-oriented policy paradigm defined from the service level to ensure the friendliness of cross-domain policy management and control, avoiding unnecessary interference caused by IP address ambiguity and dynamics to policy management and control; using SDN inter-domain Policy sharing and policy coordination solve the problems of cross-domain policy agnosticity and policy conflict; blockchain technology provides security and credibility services for SDN inter-domain policy forwarding control, which has a good application prospect.

Description of drawings:

FIG. 1 is a schematic diagram of an SDN inter-domain coordinated forwarding control architecture in an embodiment;

FIG. 2 is a schematic diagram of the working principle of the SDN inter-domain coordinated forwarding control framework in the embodiment;

FIG. 3 is a schematic diagram of an SDN inter-domain coordinated forwarding control process in an embodiment;

Fig. 4 is a schematic diagram of the transaction message format in the embodiment.

detailed description:

In order to make the purpose, technical solution and advantages of the present invention more clear and understandable, the present invention will be further described in detail below in conjunction with the accompanying drawings and technical solutions.

As early as in Ethane, the prototype of SDN, data forwarding was controlled based on custom policies. At present, a consensus has been reached on implementing SDN forwarding control based on policies. However, in the policy-based SDN inter-domain forwarding control, the following challenges are faced: (1) what kind of inter-domain policy paradigm is defined; (2) how to solve the problem of cross-domain policy agnostic and policy conflict; (3) how to Realize safe and reliable policy forwarding control in a distributed untrusted environment. (4) How to deal with the delay sensitivity of forwarding control. The embodiment of the present invention, as shown in Figure 1, provides a block chain-based SDN inter-domain cooperative forwarding control architecture, including: block chain-based policy forwarding control applications, block chain function nodes of each SDN domain and SDN The controller is deployed on the local server in the SDN domain, and the blockchain functional nodes form a blockchain network through P2P. Each SDN domain stores the blockchain global ledger, and uses the local application program interface to realize the policy forwarding control application and the controller and Interaction between blockchains, where the policy forwarding control application includes: a domain information manager for registering and dynamically updating domain information and generating domain information transactions to upload to the blockchain, for formulating inter-domain forwarding control strategies and generating A policy manager that uploads policy transactions to the blockchain, and a policy collaboration engine that performs attribute mapping, policy matching, and path synthesis by querying local caches and obtains global collaborative policies.

In the architecture shown in Figure 1, the blockchain node functions of each domain and the SDN controller are deployed on the local server in the SDN domain, and the blockchain-based policy forwarding control application communicates with the controller and the blockchain through the local application program interface. interact. The block chain function nodes of each domain are used as the bookkeeping nodes of the block chain, and form a block chain network through P2P. Therefore, each SDN domain stores a block chain global ledger. By synchronizing the blockchain ledger data to the local cache of the SDN controller, the blockchain-based policy forwarding control application locally extended by the SDN controller can quickly read trusted global shared data. Since forwarding control requires network topology information, the East-West bridge WE-bridge located at the network system layer in each domain uses a fullmesh connection, based on the SSL protocol, to exchange inter-domain network views safely and quickly through Json files, thereby providing global information for each domain. Domain-level network view. Each domain controller can obtain the SDN inter-domain global network view dynamically and in real time through the WE-bridge. The control function of each SDN domain is safe and credible, that is, the SDN network operating system related to SDN control, the policy forwarding control application based on blockchain, and the WE-Bridge components of the east-west bridge are safe and credible.

BPCF-SDNs ensures the authenticity and integrity of domain information and policy information uploaded by each SDN domain based on the transaction signature mechanism; realizes automatic and transparent domain information and policy release and update through smart contract technology; guarantees the current block based on the account status mechanism It stores the latest state of global domain information and policies, avoids traversing the entire blockchain in UTXO mode to obtain the latest state, and improves the data retrieval rate; based on the consensus mechanism of PBFT (Practical Byzantine Fault Tolerance, Practical Byzantine Fault Tolerance Algorithm), It can more efficiently guarantee the credibility of cross-domain shared data; finally, based on block chain storage, domain information and policies are guaranteed to be tamper-resistant and traceable, and finally realize safe and credible SDN domain information and policy sharing.

In the embodiment of this case, as shown in FIG. 2 , the policy-based SDN inter-domain forwarding control is divided into three layers of logic—policy, routing, and forwarding. First, strategy, as a high-level logic, should be management-friendly. That is, the network manager focuses on a certain type of data flow at the service level, rather than a certain data flow at the network level. On the other hand, considering that the IP address cannot intuitively express the business logic, it also has dynamic changes. If the policy uses IP addresses to identify data flows, it will inevitably affect the friendliness of policy management and control, and the application layer policy needs to be dynamically configured with the IP address, which will increase the complexity and error rate of policy configuration. Therefore, a policy paradigm oriented to data flow and path attributes will be designed from the service level to ensure the friendliness of cross-domain policy control and avoid unnecessary interference to policy control caused by IP address ambiguity and dynamics. Second, since each management domain independently formulates forwarding control policies, the transmission domain does not know the policy constraints of the source domain during data stream transmission, so it cannot forward data streams according to the policy constraints of the source domain. Therefore, in the embodiment of this case, the cross-domain policy agnostic problem is solved through policy sharing. Similarly, since the originating domain does not know the filtering rules of the transport domain for service flows, data transmission may be interrupted due to the conflict between the bearer policy and the originating policy. Therefore, in the embodiment of this case, the policy conflict is resolved through policy coordination. That is, the premise of implementing cross-domain policy control in the embodiment of this case is to implement SDN inter-domain policy sharing and policy coordination. Third, due to the lack of security and credibility in the inter-domain communication environment, how to ensure the security and credibility of SDN inter-domain policy sharing and coordination is a difficult problem. As a distributed ledger technology that deeply integrates P2P network, cryptography, smart contract, consensus mechanism and other technologies, blockchain technology can provide automatic, transparent, safe and credible data sharing in a distributed untrusted environment Serve. Therefore, in the embodiment of this case, blockchain technology is applied to provide security and credibility services for SDN inter-domain policy forwarding control. Fourth, forwarding control is time-delay sensitive, and the use of blockchain technology will introduce a large amount of computing and time-delay overhead. Therefore, in the implementation example of this case, a physically centralized and logically isolated The chain node function is deployed on the local controller, so that SDN can safely and efficiently exchange data with the blockchain, and at the same time separate the forwarding control function from the data sharing function based on the blockchain, and execute the forwarding control based on policy coordination locally on the controller , to avoid introducing too much delay while ensuring security.

Further, based on the above-mentioned architecture, the embodiment of this case also provides a blockchain-based SDN inter-domain collaborative forwarding control method, including the following content:

The domain information and cross-domain forwarding strategy of each SDN domain are uploaded to the blockchain, and the domain information and cross-domain forwarding strategy are released or updated by the smart contract in the blockchain, and the functional nodes of the blockchain will be used to publish or update Synchronize the domain information and forwarding control policy to the local cache;

For the new data flow received by the ingress switch, by querying the flow table, if there is a matching flow entry, it will be forwarded according to the matching flow entry; if there is no matching flow entry, the first packet of the data flow will be uploaded to the SDN controller. The SDN baseline controller interacts with the policy coordination engine in the policy forwarding control application extended by the controller to obtain the global coordination strategy;

Based on the obtained global coordination policy, the SDN baseline controller combines the network view at the global domain level, and obtains the domain-level forwarding path that satisfies the constraints of the global policy through inter-domain path calculation; uses the east-west interface between SDN controllers to control the forwarding domain The controller distributes inter-domain path segments, and each domain SDN controller issues flow entries according to the inter-domain path segments, and finally realizes cross-domain forwarding control.

Referring to Figure 3, the cooperative forwarding control process can be divided into the following three stages:

(1) Information sharing stage: the domain information manager of each domain generates domain information transactions and signs the attribute information of entities such as domains, users, and devices in the domain, and the mapping relationship between IP addresses, user IDs, and device IDs, and uploads them to the domain. Block chain: block chain checks and signs transactions and implements domain information release or update by calling domain information management smart contracts. The policy manager of each domain formulates a cross-domain forwarding control strategy, encapsulates it into a policy transaction and signs it, uploads it to the blockchain, and the blockchain verifies the transaction, and implements policy release or update by calling the policy management smart contract. Each domain block chain function node dynamically synchronizes the domain information in the domain information management contract account and the policy in the policy management contract account to the local cache of the SDN controller. So far, the information sharing stage has realized safe and credible SDN domain information and policy sharing.

(2) Policy coordination stage: When the new flow arrives at the ingress switch, the ingress switch queries the flow table, and if there is a matching flow entry, it will be forwarded according to the matching flow entry; if not, the first packet of the data flow will be uploaded through the pack-in message controller. The SDN baseline controller uploads the flow policy request containing the first packet of the cross-domain data flow to the policy coordination engine of the policy forwarding control application through the flow policy requester. The strategy coordination engine obtains the global coordination strategy by querying the local cache data and performing "attribute mapping", "policy matching" and "path synthesis". The policy coordination engine sends the global coordination policy of the data flow to the SDN baseline controller.

(3) Path generation stage: the controller receives the global collaborative policy and hands it over to the inter-domain path calculation component. The inter-domain path calculation component combines the global domain-level network view provided by the east-west bridge WE-bridge component to calculate the domain-level forwarding path that meets the constraints of the global coordination policy, and distributes it to the controllers in the forwarding domain through the east-west interface between the controllers Each SDN domain controller issues flow entries according to the path segment, so as to realize cross-domain policy-oriented forwarding control.

Further, the domain information of each SDN domain uploaded to the blockchain includes at least: entity attribute information and identification mapping relationship, wherein the entity attribute information includes: domain, user and device information in the domain, and the identification mapping relationship includes: IP The mapping relationship between addresses and user IDs and device IDs.

In the process of formulating the forwarding policy in the embodiment of this case, the following content is used to obtain the policy paradigm representation:

Attribute is described as a variable with a certain data type and value range, which can be abstracted as <attr, Value>, where attr represents the attribute name, Value represents the value range of the attribute, Value={value ₁ ,value ₂ ,.. .,value _x }, that is, each attribute has its own attribute name and corresponding value range. The attributes in this example are used to describe the data flow and path. Attribute categories include domain, user, device, and business. in,

Domain attributes: including domain identifier, network address, domain entry gateway or exit gateway identifier, domain type (such as commercial domain, government domain) or social legal name of the domain, domain security level, domain trust level, etc.;

User attributes: user identifier, user unit, department, level, etc.;

Device attributes: including device identifier, MAC address, device location, department, confidentiality level, etc.;

Business attributes: business identifier, protocol, port number, business type, etc., specify the packet type or business type targeted by this policy through the protocol, port number or user-defined business category.

The attribute name-value pair avp is used to represent the specific value of an attribute, which can be abstracted into a tuple <attr, value>, which means attr=value. A set of attribute name value pairs can be represented by AVP. The embodiment of this case uses a set of attribute name-value pairs to describe the attributes of domains, users, devices, and services. See Table 1 for details.

Table 1 Property name value pair comparison table

For example, domAVP={<domID,001>,<dom_net,202.20.2.0/24>,<dom_type,EDU>,<dom_sl,3>,<dom_tl=2>} indicates that the subnet address of domain 001 is 202.20.2.0 /24, which belongs to the education type organization, the security level of this domain is 3, and the trust level is 2.

userAVP={<userID,00001>,<user_org,organizationA>,<user_depart,depatmentB>,<user_type,manager>,<user_tl,2>} indicates that the user whose user ID is "00001" comes from "departmentB" of "organizationA" ", its role is "manager", and its trust level is "2".

devAVP＝{<devID,00001>,<dev_mac,4f:3e:32:62:53:3f>,<dev_loc,locationA>,<dev_org,organizationA>,<dev_depart,departmentC>,<dev_sl,2>} means The MAC address of the device with the identifier "00001" is "4f:3e:32:62:53:3f", the geographical location is located in "loacationA", belongs to the department "departmentB" of the organization "organizationA", and the security level of the device is "2" class.

servAVP={<servID,0001>,<serv_type,vedioconferencing><ser_protocol,SIP>,<ser_dport,5060>} indicates that the type of network service with the service identifier "0001" is "vedioconferencing", and the protocol used is "SIP" , and the corresponding port number is "5060".

servAVP＝{<servID,0002>,<serv_type,Double 11>,<ser_protocol,https>,<ser_dport,443>} indicates that the network service with service ID "0002" is "Double 11" and the protocol used is "https ", the corresponding port number is "443".

In the embodiment of this case, from the business level, the data flow (dataflow) can be abstracted into a seven-tuple <SrcDom, SrcUser, SrcDev, DestDom, DestUser, DestDev, Serv>, that is, the source domain, source user, and source device of the data flow , destination domain, destination user, destination device, and network service attribute set to represent a data flow.

The source attribute of a data flow can be composed of a set of attribute name-value pairs of its source domain, source user, and source device, which can be expressed formally as: srcAVP={srcdomAVP, srcuserAVP, srcdevAVP}.

The destination attribute of a data stream may be composed of a set of attribute name-value pairs of its destination domain, destination user, and destination device, which is formally expressed as: dstAVP={dstdomAVP, dstuserAVP, dstdevAVP}.

Therefore, a data flow can be expressed as dataflow=srcAVPUdstAVPUservAVP.

The attribute predicate ap is used to limit the value range of the attribute. ap can be abstracted as a triplet <attr,∝,value>, where ∝∈{=,≠,<,≤,>,≥,in,not in,between} . In this embodiment, attribute predicates are used as attribute constraints in the policy paradigm.

Attribute predicate evaluation refers to a given attribute name-value pair avp and attribute predicate ap, and the evaluation result of ap to avp is true if and only if the attribute names of the two are the same and the attribute value in avp belongs to the value range limited by ap, which can be in the form is defined as:

The forwarding control strategy paradigm for data flow and path attributes can be designed as follows:

policy=<domID, policyID, policyType, SrcAP, DstAP, ServAP, Path, action>

DstAP：表示对数据流的目的属性约束，由目的域属性谓词、目的用户属性谓词、目的设备属性谓词通过逻辑合取构成，即

ServAP：表示对数据流的业务属性约束，通过协议、端口号或自定义业务类型等属性谓词的逻辑合取构成，即ServAP＝servap₁∧servap₂,...∧servap_g；Path：表示对数据流的路径约束，通过传输域的安全级别、信任等级或者域标识等属性谓词的逻辑合取构成，即Path＝pathap₁∧pathap₂∧...∧pathap_p，可用于源域限定传输该源发数据流的域的安全等级、信任等级，或限定该数据流必须经过或不能经过的域；action表示对满足策略约束的数据流在策略约束路径上的转发动作，包括丢弃drop、转发forward。Among them, domID: indicates the domain ID that formulates the policy; policyID: indicates the ID of this policy in this domain, and the combination of domID and policyID can uniquely specify a policy in a multi-domain environment; policyType: indicates the policy type, and the policy is divided into two types, policyType=SOURCE means the origination policy, which is used to restrict the data flow originating from this domain; policyType=TRANSFER means the bearer policy, which is used to filter the data flow from other domains; Domain attribute predicates, source user predicate constraints, and source device attribute predicates are formed by logical conjunction, namely

DstAP: Represents the constraint on the destination attribute of the data stream, which is composed of the destination domain attribute predicate, destination user attribute predicate, and destination device attribute predicate through logical conjunction, that is,

ServAP: Indicates the business attribute constraints on the data flow, formed by the logical conjunction of attribute predicates such as protocol, port number or custom service type, that is, ServAP=servap ₁ ∧servap ₂ ,...∧servap _g ; Path: indicates the The path constraint of the data flow is formed by the logical conjunction of attribute predicates such as the security level, trust level, or domain identifier of the transmission domain, that is, Path=pathap ₁ ∧pathap ₂ ∧...∧pathap _p , which can be used to limit the transmission of the data in the source domain. The security level and trust level of the domain that sends the data flow, or the domain that limits the data flow must or cannot pass through; action indicates the forwarding action on the policy-constrained path of the data flow that meets the policy constraints, including discarding drop and forwarding forward .

The combination of policy type, path constraint and action can determine the forwarding path decision of a data flow, as shown in Table 2. In the embodiment of this case, the source domain of the agreed data flow can limit the forwarding path of the original data flow, and the transmission domain cannot limit the forwarding path of the data flow originating from other domains, but has the right to decide whether to carry the data flow, that is, the right to decide to receive And forward the data flow or discard the data flow.

Table 2 The forwarding control meaning of the policy

A data flow matches a policy if and only if, for each attribute predicate in the policy, the value of the attribute name-value pair corresponding to the data flow belongs to the value range of the attribute predicate, which can be formally expressed as:

The embodiment of this case includes domain information transactions and policy transactions. The transaction format is shown in Figure 4. In the general transaction format (a), ID represents the transaction identifier; PK represents the blockchain account public key of the domain, and the policy forwarding control of each SDN domain The application has its own public-private key pair, the public key is used as the unique identifier of the external account on the blockchain, and the private key is used to sign the transaction uploaded by the external account to the blockchain; TxType: transaction type; TxData: transaction data; tp represents the timestamp of the transaction release; sign is the signature of the transaction originating account; the domain information transaction format is shown in (b), and its transaction data is DomInf, which is stored in the form of key-value pairs, including the domain identifier, the SDN The set of mapping relations between IP addresses in the domain and user IDs and device IDs, and the set of attribute name-value pairs of domains, users, and devices. Its formal representation is shown in (d); the policy transaction format is shown in (c), and its The transaction data is PolicySet, which is stored in the form of key-value pairs, including the domain identifier and the source policy set and bearer policy set formulated by the SDN domain. The formal representation is shown in (e).

The domain information management smart contract DIM Contract implements domain information publishing or updating through the domain information publishing DomInfPublish interface, which can be designed as shown in Algorithm 1. The domain information transaction DomInfTx writes the mapping relationship between the IP address and the entity in DomInf and the attribute information of the entity into the DIMContract account with domID as the index by calling the DomInfPublish interface. The blockchain functional nodes of each domain synchronize the data in the DIM Contract account to the local cache of the SDN controller, which is recorded as DomInfDB.

The policy management contract PM Contract implements policy publishing and updating through the PolicyPublish interface, which can be designed as shown in Algorithm 2. Policy transaction PolicyTx writes the policies in the PolicySet into the PM Contract account according to the domain identifier and policy type by calling the PolicyPublish interface. The blockchain function nodes of each domain synchronize the data in the PM Contract account to the local cache of the SDN controller, which is recorded as PolicyDB.

Further, in the embodiment of this case, when the SDN baseline controller interacts with the policy coordination engine to obtain the global coordination policy, firstly, the key field of the data packet header is obtained by parsing the flow policy request, and by querying the local cache of the SDN controller DomInfDB maps the data flow network identifier and business attributes; then, according to the data flow attributes, executes policy matching on the PolicyDB in the local cache of the SDN controller to obtain the matching policy set; finally, obtains the global path by performing path synthesis on the matching policy set Constrained global collaborative strategy.

When a new flow arrives, the policy coordination engine is triggered to execute the policy coordination algorithm, which can be designed as shown in Algorithm 3. The policy collaboration algorithm PolicyCollaborate() is implemented by three functional steps: attribute mapping AttributeMap(), policy matching PolicyMatch() and path synthesis PathSynthesize():

(1) Obtain the header of the first packet of the data flow by parsing the flowPolicyRequest, and AttributeMap() maps the attributes corresponding to the data flow according to the network identification field in the header, that is, mapAttrSet(lines 1-2);

(2) PolicyMatch() performs policy matching according to the data flow attributes, and obtains all policies that constrain the data flow, that is, the matching policy set matchPolicySet (line 3);

(3) PathSynthesize() performs path synthesis on the matching strategy set, and returns the global path constraints of the data flow (lines 4-5).

Further, when mapping the data stream network identifier and business attributes, read the source IP, destination IP, port number or protocol type according to the key fields of the data packet header; obtain the source domain, source user, and source device information according to the source IP A collection of attribute name-value pairs, and form the source attribute of the data flow; obtain the set of attribute name-value pairs of the destination domain, destination user, and destination device according to the destination IP, and form the destination attribute of the data flow; use the port number or protocol type as the service identifier , obtain the network service attribute according to the port number or protocol type; combine the source attribute, destination attribute and network service attribute to form the business attribute set of the data flow, and generate the corresponding flow identifier according to the key field of the data flow; through the combination of the flow identifier and the business attribute Set to complete the mapping between data flow network identifiers and business attributes.

The attribute mapping function AttributeMap() maps the data stream attributes according to the key fields of the first packet of the data stream. The method is to query DomInfDB, first map the corresponding identifier according to the key field of the data packet header, then map the corresponding attribute according to the identifier, and finally combine these attributes to form the data flow attribute. AttributeMap() can be designed as shown in Algorithm 4:

(1) Read the source ip, and obtain the set of attribute name-value pairs of the source domain, source user, and source device from DomInfDB according to the source ip to form the source attribute of the data stream (lines 2-4);

(2) Read the destination ip, and obtain the attribute name-value pair set of the destination domain, destination user, and destination device from the DomInfDB according to the destination IP, to form the destination attribute of the data stream (lines 5-7);

(3) Read the port number or protocol type as the business identifier, read the port number with the port number, read the protocol type without the port number, and obtain the set of attribute name-value pairs of the network service from DomInfDB according to the port number or protocol type (lines8 -9);

(4) Combining source attributes, destination attributes, and network service attributes to form an attribute set FlowAttrSet (line 10) corresponding to the data flow;

(5) Generate a corresponding flow identifier FlowSN (line 11) according to the key field of the data flow packet header;

(6) Combine the flow identifier and the flow attribute set, and return it as the result of the attribute mapping function (lines 12-13).

Furthermore, in the embodiment of this case, when obtaining the matching policy set through policy matching, firstly, the source policy is obtained according to the source domain identifier of the data flow, and the bearer policy of each domain is obtained according to the policy type, and the source policy and the bearer policy are related policy set; then, for each policy in the relevant policy set, if the attribute set of the data flow satisfies all the attribute predicate constraints in the policy, the corresponding policy will be used as the matching policy; otherwise, the next policy will be traversed until the relevant policy set is traversed All policies, and then get the matching policy set.

Policy matching performs policy matching according to data flow attributes, and obtains a policy set that constrains the forwarding path of the data flow. It can be designed as shown in Algorithm 5. The PolicyMatch() algorithm flow is as follows:

(1) Initialize the data flow attribute set flowAVP as the attribute set of the flow requested to be forwarded, the attribute matching mark is 0, the source policy set srcPolicySet, the bearer policy set transferPolicySet, the relevant policy set relevantPolicySet, and the matching policy set matchPolicySet are all empty (line 1);

(2) According to the source domain identifier of the data flow, read the source policy of the domain from PolicyDB (line 2);

(3) According to the policy type TRANSFER, read the bearer policy of each domain from PolicyDB (line 3);

(4) The source policy and the bearer policy constitute a related policy set (line 4);

(5) For each policy in the relevant policy set, if the data flow attribute set satisfies all the attribute predicate constraints of the policy, the policy is a matching policy; otherwise, traverse the next policy until all policies are traversed. (lines 5-11)

(6) Return the matching strategy set (line 12).

Furthermore, in the embodiment of this case, path synthesis is performed, and the global collaborative strategy of global path constraints is obtained by matching the policy types, path constraints, and actions in the policy set, wherein the global collaborative policy is obtained by matching the policy types, path constraints, and actions in the policy set. Collaborative strategy, specifically includes the following situations: for each source strategy in the matching strategy set, if the action is forward, write its path constraint into the flow path constraint; if its action is drop, then reverse its path constraint, Write stream path constraints; for each bearer policy in the matching policy set, if the path constraint is not empty, the contract will be violated and an error will be reported; if the path constraint is empty and the action is drop, the corresponding domain ID will be reversed and Write flow path constraints. If the path constraints are empty and the action is forward, data forwarding will not be affected until all bearer policies are traversed; finally, the joint flow identifier, flow path constraints and action forward form a global path constraint with global collaborative strategy.

The path synthesis algorithm performs path constraint synthesis on the matching policy set of the flow to obtain the global path constraints. It can be designed as shown in Algorithm 6. The PathSynthesize() algorithm flow is as follows:

(1) Initialize the path constraint flowPath of the flow to be the complete set, the path variable path and the action variable action to be null, and the global collaborative policy collaborativePolicy to be empty (line 1);

(2) For each source policy in the matching policy set, if the action is forward, write its path constraint into the stream path constraint; if its action is drop, reverse its path constraint and write it into the stream path constraint (lines2-4, lines5-13);

(3) For each bearer policy in the matching policy set, if its constraint is not empty, the agreement will be violated and an error will be reported; if its path constraint is empty and the action is drop, the domain identifier will be reversed and written into the flow path Constraint; if the path constraint is empty and the action is forward, it will not affect data forwarding (line2-4, lines 14-25);

(4) Combine flow identifier, flow path constraint and forward action as a global collaborative strategy, and return (lines31~32).

In the embodiment of this case, the forwarding control strategy paradigm based on attributes instead of IP can carry out fine-grained control on the data flow forwarding path from the perspective of service management; while the attribute-based method provides a unified and flexible expression for SDN cross-domain forwarding strategies capabilities; and achieve blockchain-based domain information and policy sharing, which solves the problem of unknowable cross-domain policies, ensures the security and credibility of policy delivery in a distributed trustless environment, and innovatively implements global-based The cross-domain forwarding control of collaborative policies eliminates the problem of cross-domain policy conflicts; realizes a physically centralized and logically isolated architecture, and deploys blockchain node functions on local controllers, enabling SDN to safely and efficiently communicate with blockchain Chain exchange data; through the combination of chain and off-chain functional models, the forwarding control is separated from the blockchain, and policy coordination is executed on the local controller to achieve policy coordination based on trusted data, avoiding the risk of execution of policy coordination on the chain. Data flow forwarding brings excessive delay and complex calculation, which is convenient for deployment and implementation.

Relative steps, numerical expressions and numerical values of components and steps set forth in these embodiments do not limit the scope of the present invention unless specifically stated otherwise.

Finally, it should be noted that: the above-described embodiments are only specific implementations of the present invention, to illustrate the technical solutions of the present invention, rather than to limit it, and the scope of protection of the present invention is not limited thereto, although referring to the foregoing The embodiment has described the present invention in detail, and those of ordinary skill in the art should understand that any person familiar with the technical field can still modify the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention Changes can be easily thought of, or equivalent replacements are made to some of the technical features; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be covered by the scope of the present invention. within the scope of protection. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims (10)

1. An inter-SDN domain cooperative forwarding control architecture based on a blockchain, comprising: the strategy forwarding control application based on the block chain is characterized in that the block chain function nodes of each SDN domain and an SDN controller are deployed in a local server of the SDN domain, the block chain function nodes form a block chain network in a P2P mode, a block chain global account book is stored in each SDN domain, and the interaction between the strategy forwarding control application and the controller and the block chain is realized by utilizing a local application program interface, wherein the strategy forwarding control application comprises the following steps: the system comprises a domain information manager used for registering and dynamically updating domain information, generating domain information transaction and uploading the domain information transaction to a block chain, a policy manager used for formulating an inter-domain forwarding control policy, generating a policy transaction and uploading the policy transaction to the block chain, and a policy cooperation engine used for executing attribute mapping, policy matching and path synthesis by inquiring a local cache and acquiring a global cooperation policy.

2. The inter-domain collaborative forwarding control architecture for SDNs based on blockchains according to claim 1, wherein the blockchain function nodes utilize a consensus mechanism to perform uplink acknowledgement on published or updated domain information or policy information, write the uplink acknowledgement into an account book database of each SDN domain blockchain node, and dynamically synchronize the domain information and policy information of an intelligent contract account in the consensus mechanism to a local cache of the SDN controller in real time.

3. An SDN inter-domain cooperative forwarding control method based on a block chain, characterized in that, based on the architecture implementation of claim 1, the method comprises the following steps:

uploading domain information and a cross-domain forwarding strategy of each SDN domain to a block chain, issuing or updating the domain information and the cross-domain forwarding strategy by an intelligent contract in the block chain, and synchronizing the issued or updated domain information and the forwarding control strategy to a local cache of an SDN controller by using a block chain function node;

for a new data flow received by an entrance switch, forwarding according to a flow rule by inquiring a flow table if a matched flow table entry exists, uploading a data flow first packet to an SDN controller if the flow table entry does not exist, and interacting the SDN baseline controller and a strategy coordination engine to acquire a global coordination strategy;

the SDN baseline controller combines a network view of a full-local level according to the obtained global cooperative strategy and obtains a domain-level forwarding path meeting the global strategy constraint through inter-domain path calculation; and distributing the path segments to the forwarding domain controller by utilizing east-west directional interfaces among the SDN controllers, and issuing a flow table entry by each SDN controller according to the path segments to realize cross-domain forwarding control.

4. The inter-domain collaborative forwarding control method for the SDN based on the block chain according to claim 3, wherein in the issuing or updating of the domain information and the cross-domain forwarding policy by the block chain, the domain information of each SDN domain is generated into a domain information transaction, which is signed and then uploaded to the block chain, the block chain verifies the signature of the domain information transaction, if the domain information transaction is verified, a domain information management intelligent contract is invoked to implement the issuing and updating of the domain information, and the domain information in the domain information management intelligent contract account is synchronized to a local cache of the SDN controller by using a function node of the block chain; the cross-domain forwarding strategies of the SDN domains are packaged into strategy transactions, the strategy transactions are uploaded to a block chain after signature, the signature of the strategy transactions is verified by the block chain, the strategy management contract is called to realize the release and the update of the forwarding control strategies when the strategy transactions are verified, and the forwarding control strategies in the intelligent contract account for strategy management are synchronized to the local cache of the SDN controller by using the block chain function nodes.

5. The inter-domain collaborative forwarding control method for SDNs based on a blockchain according to claim 3 or 4, wherein the domain information uploaded to each SDN domain on the blockchain at least includes: entity attribute information and an identifier mapping relationship, wherein the entity attribute information comprises: the mapping relation of the domain, the user and the equipment information in the domain comprises the following steps: and the mapping relation among the IP address, the user identification and the equipment identification.

6. The inter-domain collaborative forwarding control method for SDNs based on a blockchain according to claim 3 or 4, wherein the cross-domain forwarding policy uploaded to each SDN domain on the blockchain is represented by a tuple, and a specific paradigm is represented as:

policy = < domID, policyID, policyType, srcAP, dstAP, servAP, path, action >, wherein domID represents a domain identifier for making a policy, policyID represents an identifier of the policy in the domain, policyType represents a policy type, the policy type is divided into an originating policy for restricting originating data flow of the domain and a bearer policy for filtering data flow from other domains, srcAP represents an originating attribute constraint for data flow, dstAP represents a destination attribute constraint for data flow, servAP represents a network service attribute constraint for data flow, path represents a Path constraint for data flow, and action represents a forwarding action on a policy constraint Path for data flow satisfying the policy constraint.

7. The method of claim 3, wherein in acquiring the global coordination policy by interaction between the SDN baseline controller and the policy coordination engine, a key field of a packet header is acquired by parsing a stream policy request, and a data stream network identifier is mapped with a service attribute by querying locally cached domain information; then, reading a strategy set of the local cache according to the data stream attribute, and obtaining a matching strategy set through strategy matching; and finally, performing path synthesis on the matching strategy set to obtain a global cooperative strategy of global path constraint.

8. The inter-domain collaborative forwarding control method for SDN based on a blockchain according to claim 7, wherein when mapping a data flow network identifier and a service attribute, a source IP, a destination IP, and a port number or a protocol type are read according to a key field of a header of a data packet; acquiring attribute name value pair sets of a source domain, a source user and source equipment according to a source IP (Internet protocol), and forming source attributes of a data stream; acquiring attribute name value pair sets of a destination domain, a destination user and destination equipment according to a destination IP (Internet protocol), and forming a destination attribute of the data stream; acquiring a network service attribute value pair set according to the port number or the protocol type, and using the network service attribute value pair set as the network service attribute of the data stream; combining the source attribute, the destination attribute and the network service attribute to form a service attribute set of the data stream, and generating a corresponding stream identifier according to a key field at the head part of the data stream; and the mapping between the data stream network identifier and the service attribute is completed by combining the stream identifier and the service attribute set.

9. The inter-domain collaborative forwarding control method for SDN based on a block chain according to claim 7, wherein when obtaining the matching policy set through policy matching, first, a source policy of a source domain is obtained according to a source domain identifier of a data stream and a bearer policy of each domain is obtained according to a policy type, and the source policy of the source domain and the bearer policy of each domain form a relevant policy set; then, for each strategy in the relevant strategy set, if the attribute set of the data stream meets all attribute predicate constraints in the strategy, the corresponding strategy is used as a matching strategy, otherwise, the next strategy is traversed until all strategies in the relevant strategy set are traversed, and then a matching strategy set is obtained.

10. The SDN inter-domain cooperative forwarding control method according to claim 7, wherein when performing path synthesis, the global cooperative policy with global path constraints is obtained by matching policy types, path constraints, and actions in the policy set, where obtaining the global cooperative policy from the policy types, path constraints, and actions in the matching policy set specifically includes the following situations: for each source policy in the matching policy set, if the action is forward, writing the path constraint into the flow path constraint, and if the action is drop, writing the flow path constraint after negating the path constraint; for each bearer policy in the matching policy set, if the path constraint is not null, violating the convention, reporting an error, if the path constraint is null and the action is drop, negating the corresponding domain identifier and writing the reversed domain identifier into the flow path constraint, and if the path constraint is null and the action is forward, not affecting data forwarding until all bearer policies are traversed; finally, the joint flow identifier, flow path constraints and action forward constitute a global collaborative policy with global path constraints.

Images