CN111262724B - Method and device for confirming trust relationship between domains - Google Patents
Method and device for confirming trust relationship between domains Download PDFInfo
- Publication number
- CN111262724B CN111262724B CN202010014989.7A CN202010014989A CN111262724B CN 111262724 B CN111262724 B CN 111262724B CN 202010014989 A CN202010014989 A CN 202010014989A CN 111262724 B CN111262724 B CN 111262724B
- Authority
- CN
- China
- Prior art keywords
- node
- domain
- trust
- trust value
- management node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0893—Assignment of logical groups to network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/28—Restricting access to network management systems or functions, e.g. using authorisation function to access network configuration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/04—Interdomain routing, e.g. hierarchical routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The embodiment of the invention provides a method and a device for confirming inter-domain trust relationship, relates to the technical field of block chains, and solves the problem that quantitative inter-domain trust evaluation cannot be carried out during cross-domain communication. The method comprises the following steps: the first node determines a first service to be deployed. The first node determines at least two trust domains for the first service. The first node inquires and acquires a trust value between any two trust domains of the at least two trust domains in the management node. And the first node determines the trust value meeting the first preset condition according to all the obtained trust values. The first node deploys a first service on a domain corresponding to the trust value meeting a first preset condition. The embodiment of the application is applied to confirming the inter-domain trust relationship.
Description
Technical Field
The embodiment of the invention relates to the technical field of block chains, in particular to a method and a device for confirming trust relationship between domains.
Background
A Software Defined Network (SDN) separates a control plane and a data plane of a network device, thereby implementing flexible control of network traffic. Great flexibility is provided for network management and control. The SDN network domain includes an SDN controller and a plurality of forwarding devices. A domain (domain) is an independently operating unit in a network, and a trust relationship needs to be established when domains access each other. After the trust relationship is established between the two domains, the two domains can be managed mutually according to requirements. For example, file resources are allocated across domains between two domains, printer device resources are allocated across domains, and so on. Therefore, establishing trust relationships between domains is a necessary condition for domain-to-domain interworking.
Currently, domains of a multi-domain SDN (MD-SDN) can communicate with each other by enabling inter-domain routing, or domain controllers across multiple domains. However, when a service needs to be deployed across multiple domains, it is difficult to achieve quantitative inter-domain trust evaluation because different SDN network domains have network heterogeneity.
Disclosure of Invention
Embodiments of the present invention provide a method and an apparatus for confirming an inter-domain trust relationship, which solve the problem that quantitative inter-domain trust evaluation cannot be performed during cross-domain communication.
In a first aspect, the present application provides a method for confirming trust relationships between domains, including: the first node determines that a first service needs to be deployed across domains, and then determines at least two trust domains according to the first service. The first node inquires and acquires a trust value between any two trust domains of the at least two trust domains in the management node. Wherein the first node and the management node belong to the same alliance chain. The management node stores the trust value of the domain represented by each node except the management node in the federation chain to any other domain. Specifically, for each node other than the management node, any other domain is a domain represented by any other node other than the management node and the node. The first node determines that all the obtained trust values meet the trust value of the first preset condition, and then deploys a first service on the domain corresponding to the trust value meeting the first preset condition.
In a second aspect, the present application provides a method for confirming trust relationships between domains, including: and the management node acquires the trust value of each node except the management node in the alliance chain. And then storing all the acquired trust values. And the trust value is generated by the interaction of every two nodes except the management node in the alliance chain. Each node in the federation chain, except for the management node, represents a domain.
In the above scheme, first, the present application determines a trust domain according to a service to be deployed. The management node is then queried for trust values between the trust domains. And performing service deployment on the trust domain corresponding to the trust value meeting the condition. The method can timely acquire the trust relationship between any two domains corresponding to the nodes in the alliance chain, and realizes the batch acquisition of the trust relationship between the domains. Secondly, the management node and all the nodes in the management domain of the management node form a federation chain. Except for the management node, other nodes in the alliance chain store trust values from the domain represented by the node to other domains. The management node stores trust values in all nodes. Therefore, all trust values are stored in the nodes of the federation chain, so that the trust values of all domains are not tampered, and the occurrence of pseudo trust domains can be further prevented. And a distributed management method for inter-domain trust evaluation is also provided.
In a third aspect, the present application provides an apparatus for confirming trust relationship between domains, where the apparatus is used for a first node or a chip on the first node, and includes: the determining module determines a first service to be deployed. Thereafter, at least two trust domains are determined based on the first service. And the query module queries and acquires the trust value between any two trust domains in the at least two trust domains determined by the determination module in the management node. The first node and the management node belong to the same alliance chain, and the management node stores trust values from the domain represented by each node except the management node to any other domain in the alliance chain. For each node other than the management node, any other domain is a domain represented by any other node other than the management node and the node. The determining module determines the trust value meeting the first preset condition according to all the trust values acquired by the query module. The processing module deploys a first service on a domain corresponding to the trust value meeting the first preset condition and determined by the determination module.
In a fourth aspect, the present application provides an apparatus for confirming trust relationship between domains, where the apparatus is used for a management node or a chip on the management node, and the apparatus includes: the obtaining module obtains the trust value of each node except the management node in the alliance chain. And the trust value is generated by the interaction of every two nodes except the management node in the alliance chain. Each node in the federation chain, except for the management node, represents a domain. And the storage module stores all the trust values acquired by the acquisition module.
In a fifth aspect, a device for confirming inter-domain trust relationship is provided, which is used for a first node or a chip on the first node, and includes a processor, where when the device for confirming inter-domain trust relationship is running, the processor executes computer execution instructions to make the device for confirming inter-domain trust relationship execute the method for confirming inter-domain trust relationship according to the third aspect.
A sixth aspect provides a device for confirming inter-domain trust relationship, which is used for a management node or a chip on the management node, and includes a processor, where when the device for confirming inter-domain trust relationship operates, the processor executes a computer to execute an instruction, so that the device for confirming inter-domain trust relationship performs the method for confirming inter-domain trust relationship according to the fourth aspect.
In a seventh aspect, a computer-readable storage medium is provided, which includes instructions that, when executed on a computer, cause the computer to perform the method for confirming an inter-domain trust relationship as described above.
In an eighth aspect, a computer program product is provided, which includes instruction codes for executing the method for confirming an inter-domain trust relationship as described above.
It should be understood that any one of the above-provided apparatuses for confirming an inter-domain trust relationship, computer-readable storage media, or computer program products is used to execute the method corresponding to the first aspect or the second aspect, and therefore, the beneficial effects achieved by the apparatuses may refer to the methods of the first aspect and the second aspect and the beneficial effects of the solutions corresponding to the following embodiments, which are not described herein again.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without creative efforts.
Fig. 1 is a schematic diagram of an SDN architecture provided by an embodiment of the present invention;
fig. 2 is a schematic diagram of a multi-domain network structure according to an embodiment of the present invention;
fig. 3 is a schematic diagram of a protocol architecture of a blockchain system according to an embodiment of the present invention;
FIG. 4 is a block chain system according to an embodiment of the present invention;
FIG. 5 is a schematic structural diagram of a multi-domain system according to an embodiment of the present invention;
fig. 6 is a schematic hardware structure diagram of an apparatus for confirming an inter-domain trust relationship according to an embodiment of the present invention;
fig. 7 is a flowchart illustrating a method for confirming trust relationships between domains according to an embodiment of the present invention;
fig. 8 is a flowchart illustrating a method for storing an inter-domain trust value according to an embodiment of the present invention;
fig. 9 is a schematic structural diagram of a trust map according to an embodiment of the present invention;
fig. 10 is a schematic structural diagram of an apparatus for confirming an inter-domain trust relationship between first nodes according to an embodiment of the present invention;
fig. 11 is a schematic structural diagram of an apparatus for confirming an inter-domain trust relationship between management nodes according to an embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
In the embodiments of the present application, words such as "exemplary" or "for example" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "e.g.," is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, use of the word "exemplary" or "such as" is intended to present concepts related in a concrete fashion.
In the following, the terms "first", "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the embodiments of the present application, the meaning of "a plurality" is two or more unless otherwise specified.
The SDN overcomes the defects of the traditional network architecture as a novel network architecture, and has the core idea that a control plane is decoupled from a data plane of a network, so that the control plane is completely separated from the data plane.
Referring to fig. 1, the SDN architecture defined by the Open Network Foundation (ONF) includes a control layer (also called control plane), a service layer (also called application plane), and a forwarding layer (also called forwarding plane).
The application plane is formed by service applications of the SDN, and the service applications of the SDN can submit network behaviors needing to be requested to the SDN controller in a programmable mode.
The control plane includes an SDN controller (controller), and the SDN controller is mainly responsible for two tasks, one is to convert an SDN service layer request to an SDN Data link (SDN Data path), and the other is to provide an abstract model of an underlying network for the SDN service layer. The network service established by the SDN controller of the control plane interacts with the service application of the service layer through an Application Programming Interface (API), and generates a control signaling for configuring an forwarding table on the network device.
The forwarding plane consists of several network devices, each of which may contain one or more SDN Data paths. Each SDN Data path is a logical network device that is used solely to forward and process Data, and logically represents all or part of the physical resources.
With the continuous development and improvement of the SDN, a scene of interconnection of a plurality of SDN networks is generated, and a multi-domain SDN is formed. For example, referring to fig. 2, a multi-domain SDN network includes a first domain 21, a second domain 22, and a third domain 23. Three network devices 212 and an SDN controller 211 are included in the first domain 21. Wherein the SDN controller 211 is connected to all network devices 212 in the first domain 21, and the three network devices 212 are interconnected two by two. Two network devices 222, and an SDN controller 221 are included in the second domain 22. Similarly, the SDN controller 221 is connected to all network devices 222 in the second domain 22, and two network devices 222 are connected. The third domain 23 includes two network devices 232 and an SDN controller 231. Similarly, the SDN controller 231 is connected to all network devices 232 in the third domain 23, and two network devices 232 are connected. One of the network devices 212 in the first domain 21, one of the network devices 222 in the second domain 22, and one of the network devices 232 in the third domain 23 are connected two by two. Meanwhile, in a multi-domain SDN network, SDN controllers of each SDN domain are connected.
Specifically, a network service established by the SDN controller of each domain interacts with a service application of the service layer through an API, and generates a control signaling for configuring an forwarding table on a network device of each domain. Under the application scene of a single SDN management domain, the SDN can conveniently provide a forwarding path for a service without performing inter-domain evaluation. However, when a service needs to span multiple administrative domains, a trust relationship needs to be established between domains for mutual access. When a service needs to be deployed across multiple domains, since different SDN networks have network heterogeneity, it is difficult to achieve quantitative inter-domain trust evaluation. In addition, because a complete management system is not provided for inter-domain trust evaluation in the prior art, the appearance of a pseudo trust domain cannot be distinguished during inter-domain evaluation. Therefore, an emergence of a method that can quantify, and prevent inter-domain trust evaluation of pseudo domains is a corollary to the subsequent development of SDN.
In order to solve the above problems, the present application provides a method and an apparatus for confirming a trust relationship between domains, which are applicable to a multi-domain SDN network. In a multi-domain SDN network, a first node determines that a first service needs cross-domain deployment, and then determines at least two trust domains according to the first service. The first node inquires and acquires a trust value between any two trust domains of the at least two trust domains in the management node. Wherein the first node and the management node belong to the same alliance chain. The management node stores the trust value of the domain represented by each node except the management node in the federation chain to any other domain. Specifically, for each node other than the management node, any other domain is a domain represented by any other node other than the management node and the node. The first node determines that all the obtained trust values meet the trust value of the first preset condition, and then deploys a first service on the domain corresponding to the trust value meeting the first preset condition. The trust relationship between any two global domains can be acquired in time, and the batch acquisition of the trust relationship between the domains is realized. Secondly, the management node obtains the trust value of each node except the management node in the alliance chain. And then storing all the obtained trust values. And the trust value is generated by the interaction of every two nodes except the management node in the alliance chain. Each node in the federation chain, except for the management node, represents a domain. The trust value of each domain is guaranteed not to be tampered, and further the occurrence of a pseudo trust domain can be prevented.
It should be noted that, in the present application, a management node is added in a multi-domain SDN network, and is used for managing SDN controllers in the multi-domain network and issuing a certificate and a public and private key to each SDN controller. And using the management node and the SDN controller of each domain in the multi-domain SDN network as a block link node in a federation chain. Each SDN controller represents a block chain node capable of storing trust values from the domain to other domains. Wherein an SDN controller with credentials is admitted by the federation chain. Optionally, the block chain node can store the trust value into an account book of the block chain node. Optionally, the SDN controller in this application is based on an Openflow protocol, which allows the SDN controller to inform the network device where to send the data packet.
The blockchain system is essentially a peer-to-peer (P2P) network system. Each blockchain node both receives information and generates information. Communication is maintained between blockchain nodes by maintaining a common blockchain. In the blockchain system, a blockchain node can create a new block in its corresponding account, after the new block is created, other nodes are notified in a broadcast manner, other blockchain nodes verify the block, and after all blockchain nodes in the blockchain system achieve consensus, the new block can be added to the blockchain.
Referring to fig. 3, the protocol architecture of the blockchain system includes a protocol layer, an extension layer, and an application layer. The protocol layer can be divided into a storage layer and a network layer.
Specifically, the protocol layer constructs a network environment of the block chain system, establishes a transaction channel and establishes a block chain link point consensus mechanism. The storage layer describes a storage form of block chain data, and may include a chain storage technology of the block data. The network layer is used for realizing information exchange among the blockchain nodes in the blockchain network. For the present application, the protocol layer of the blockchain system corresponds to the network protocol of the SDN network. The storage layer and the network layer correspond to a blockchain node, i.e. an SDN controller of each domain in the multi-domain SDN network.
Above the protocol layer is an extension layer that provides a functional implementation of the blockchain system based on the protocol layer. Through the basic capability provided by the protocol layer, the extension layer can realize various script codes, algorithm mechanisms and application mechanisms. For example, an intelligent contract is a typical application of an extension layer, and a block link point automatically executes a contract after a certain condition is met through a deployed intelligent contract. For another example, in the present application, by deploying an intelligent contract, the management node periodically reads the ledger of each domain to obtain the trust value.
Above the extension layer is an application layer, which encapsulates various application scenarios and cases of the blockchain. The block chain function of the application layer, which realizes direct interaction with the user, is mostly realized in the form of a client. In the present application, the application layer of the blockchain system corresponds to an application of a client using the SDN network.
The implementation of each layer of the blockchain system may vary in different blockchain systems, and fig. 3 is a schematic diagram of a protocol architecture of the blockchain system, and is not limited to the protocol architecture of the blockchain system.
Referring to fig. 4 in conjunction with fig. 3, a blockchain system can provide data storage services for each domain in a multi-domain SDN network, as well as data query services. It is understood that the blockchain system shown in fig. 4 is only an example and is not a limitation of the blockchain system provided in the embodiments of the present application.
The blockchain node 41 can store the acquired data in a form of blockchain.
The inter-domain trust relationship confirming method provided by the embodiment of the application is suitable for a multi-domain SDN network system. The multi-domain SDN network system comprises at least two SDN network domains, and an SDN controller and a management node of each domain are used as block chain nodes to form a federation chain. The management node can acquire the trust value stored in each SDN controller in the SDN network system and store all the acquired trust values. In addition, each SDN controller has the right to write and read the trust value stored by itself, and has the right to read the trust value stored by the management node. The management node has the right to write and read the trust value stored by the management node and has the right to read the trust value stored by the SDN controller.
Exemplarily, when the multi-domain SDN network is the multi-domain SDN network in fig. 2 (including only three domains), fig. 5 illustrates a structure of the multi-domain system provided by the embodiment of the present application. As shown in fig. 5, the multi-domain system includes a management domain 50 of a management node 54, the management node 54, a block link point 511 of a first domain 51, a block link point 521 of a second domain 52, and a block link point 531 of a third domain 53. The management domain 50 of the management node 54 includes a first domain 51, a second domain 52, and a third domain 53. The first domain 51, the second domain 52 and the third domain 53 can interact with each other to transmit information. The management node 54 can access the block link point 511 of the first domain 51, the block link point 521 of the second domain 52, and the block link point 531 of the third domain 53, and acquire the trust values in the nodes. The block chain node 511 of the first domain 51, the block chain node 521 of the second domain 52, and the block chain node 531 of the third domain 53 can access the management node 54 to obtain the trust value in the management node 54.
In a specific implementation, the device for confirming the inter-domain trust relationship has the components shown in fig. 6. Fig. 6 is a device for confirming an inter-domain trust relationship according to an embodiment of the present application, and the device may include a processor 602, where the processor 602 is configured to execute application code, so as to implement a method for confirming an inter-domain trust relationship in the present application.
The processor 602 may be a general-purpose Central Processing Unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more ics for controlling the execution of programs in accordance with the present disclosure.
As shown in fig. 6, the apparatus for confirming the inter-domain trust relationship may further include a memory 603. The memory 603 is used for storing application program codes for executing the scheme of the application, and the processor 602 controls the execution.
The memory 603 may be, but is not limited to, a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a Random Access Memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only memory (EEPROM), a compact disk read-only memory (CD-ROM) or other optical disk storage, optical disk storage (including compact disk, laser disk, optical disk, digital versatile disk, blu-ray disk, etc.), magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. The memory may be self-contained and coupled to the processor via a bus. The memory may also be integral to the processor.
As shown in fig. 6, the apparatus for confirming an inter-domain trust relationship may further comprise a communication interface 601, wherein the communication interface 601, the processor 602 and the memory 603 may be coupled to each other, for example, via a bus 604. The communication interface 601 is used for performing information interaction with other devices, for example, information interaction between the confirmation apparatus supporting inter-domain trust relationship and other devices, such as acquiring data from other devices or sending data to other devices.
It is noted that the device structure shown in fig. 6 does not constitute a definition of the means for confirming an inter-domain trust relationship, which may comprise more or less components than those shown in fig. 6, or some components in combination, or a different arrangement of components, in addition to the components shown in fig. 6.
The following describes, with reference to the multi-domain system shown in fig. 5, a method for confirming an inter-domain trust relationship provided in the embodiment of the present application by using the inter-domain trust relationship confirming device shown in fig. 6. Each device mentioned in the following method embodiments may have a component shown in fig. 6, and is not described in detail below.
Fig. 7 is a flowchart illustrating a method for confirming an inter-domain trust relationship according to an embodiment of the present application. Referring to fig. 7, the method for confirming the inter-domain trust relationship includes the following steps.
701. The first node determines a first service to be deployed.
Specifically, the first node acquires a service request of the first service when determining that the first service needs to be deployed. The service request includes a requirement of the application on a domain corresponding to the service. For example, the service request specifies that the first service is to be carried out between a first domain represented by the first node to a third domain represented by the third node.
702. The first node determines at least two trust domains for the first service.
Specifically, at least two trust domains of the first service are determined according to the service request of the first service, for example, the service parameter specifies that the first service is developed among a first domain represented by the first node, a second domain represented by the second node, and a third domain represented by the third node, so that the trust domain of the first service includes the first domain, the second domain, and the third domain.
703. The first node inquires and obtains a trust value between any two trust domains in at least two trust domains in the management node.
The first node and the management node belong to the same alliance chain, and the management node stores trust values from a domain represented by each node except the management node to any other domain in the alliance chain. For each node other than the management node, any other domain is a domain represented by any other node other than the management node and the node.
Optionally, the present application further provides a method for storing a trust value by using block chain nodes, where in the following description, the first node and the second node are any two different block chain nodes except for a management node in a federation chain, as shown in fig. 8, including the following steps S1 to S4:
s1, the first node determines that trust evaluation is needed, and the first node sends an interaction request to the second node.
Specifically, the first node may determine that trust evaluation is required according to a trust evaluation instruction given by an administrator. At this time, when the trust evaluation indication includes the identifier of the second domain, the first node directly sends the interaction request to the second node of the second domain. And when the trust evaluation indication does not comprise the identification of the second domain, the first node takes all nodes connected with the first node as the second nodes and sends interaction requests to all the second nodes.
Optionally, the first node may also determine that a trust evaluation is required, and determine a second domain that needs to perform a trust evaluation in the following manner.
Specifically, the first node obtains a target service parameter of a target service that needs to be performed in the first domain and the third domain. Specifically, the first node receives a target service request of an application, and obtains a target service parameter of a target service according to the target service request.
The first node determines at least one third domain according to the target service parameters. The target service parameters comprise the requirements of the application on the domain corresponding to the service. For example, if the target service parameter specifies that the target service is to be performed between the first domain and any one of the fourth domain to the ninth domain, it is determined that the target service corresponds to six third domains.
The first node queries and obtains a second trust value from the first domain to each third domain in the management node. For example, the first node determines that there are six third domains according to the target service parameter, and then the first node queries and obtains the trust values of the first domain to the six third domains in the management node to obtain six trust values, which are all referred to as second trust values.
And if the first node determines that the second trust value has the target trust value, determining a third domain corresponding to the target trust value as a second domain, and determining a node of the second domain as a second node, wherein the target trust value is the second trust value which is greater than a preset threshold and is the maximum. The predetermined threshold is pre-configured, for example, the predetermined threshold may be a default value, pre-stored, or obtained by a manager in a manner of rewriting according to the service quality of the target service. For another example, the predetermined threshold is 0.5, and the first node queries and acquires six second trust values, which are 0.3, 0.2, 0.8, 0.5, 0.7, and 0.4, respectively, in the management node. Then the second confidence value greater than 0.5 is 0.7, 0.8, at which time 0.8 is determined as the target confidence value. And determines a third domain corresponding to 0.8 as the second domain.
After determining a second domain needing trust evaluation, the first node sends an interaction request to a second node of the second domain.
S2, the first node receives the data message sent by the second node, and counts the interaction times and interaction success times in a preset time period.
Wherein, the data message is a domain information message (domain information message) data message. The data message includes service parameters of the second domain. Specifically, the service parameters are further divided into Qos service configuration and SDN deployment device resource related parameters. The nodes of each domain assign different service parameters to different services. For example, qos service configurations required for services such as video transmission, virtual network, service chain, etc. are different. As another example, SDN deploys device resource related parameters including traffic flow through devices, ports, and the like.
After the first node sends the interaction request to the second node, the first node exchanges data messages with the second node. Optionally, the first node, the second node and the management node belong to the same federation chain. Thus, the management node may issue a certificate and a public and private key for the first node and the second node. Therefore, the authenticity of the identities of the two message delivery parties can be ensured through the identity certificate verification in the blockchain mechanism.
And the first node receives the data message sent by the second node once, and determines the interaction times as the sum of the stored interaction times, wherein the initial value of the interaction times is 0.
And the first node receives the data message sent by the second node, and if the service parameter is determined to meet a second preset condition of the first node, the interaction success frequency is determined to be the stored interaction success frequency plus one, wherein the initial value of the interaction success frequency is 0. Specifically, the second preset condition is preconfigured, for example, the second preset condition may be a default value, pre-stored, or obtained by a manager in a manner of rewriting according to the service parameter of the service of the first domain. For another example, when a first percentage of the service parameters in the service parameters of the second domain satisfy the condition corresponding to the corresponding service in the first domain, the number of interaction success times is determined to be the number of interaction success times that has been stored plus one.
And counting the interaction times and the interaction success times of the first domain and the second domain in a preset time period.
And S3, the first node calculates the trust value and stores the trust value.
Specifically, a first trust value from a first domain represented by a first node to a second domain represented by a second node satisfies a formula
Wherein, T 12 Representing the trust value from the first domain to the second domain, m representing the number of successful interactions, and n representing the number of interactions.
Further, the first node stores the calculated first trust value. Optionally, the first node stores the first trust value in an account book of the first node.
Optionally, after the nodes of each domain interact with all the nodes connected to the domain, the trust is stored.
Optionally, the nodes of each domain may save storage trust values through the first intelligence.
Further optionally, the present application further provides a method for storing a trust value by a management node, as shown in fig. 8, including the following step S4:
and S4, the management node reads the trust value of each node except the management node in the alliance chain and stores the trust value.
And the trust value is generated by the interaction of every two nodes except the management node in the alliance chain. Each node in the federation chain, except for the management node, represents a domain.
Optionally, the management node reads the trust value of each node except the management node in the federation chain at the first time, and generates the trust map from the trust value according to a preset rule. In particular, a trust graph includes a relationship of domains and trust values within a management domain of a management node. For example, referring to fig. 9, four domains represented by four nodes in the federation chain are respectively a first domain, a second domain, a third domain, and a fourth domain, where a trust value of the first domain to the second domain is R12, a trust value of the first domain to the third domain is R13, and a trust value of the first domain to the fourth domain is R14. Similarly, the trust value of the second domain to the first domain is R21, the trust value of the second domain to the third domain is R23, and the trust value of the second domain to the fourth domain is R24. The trust value of the third domain to the second domain is R32, the trust value of the third domain to the first domain is R31, and the trust value of the third domain to the fourth domain is R34. The trust value of the fourth domain to the second domain is R42, the trust value of the fourth domain to the third domain is R43, and the trust value of the fourth domain to the first domain is R41. Optionally, the management node may read the trust value in each node except the management node in the federation chain by using the second intelligent contract.
The management node stores a trust map. Optionally, the management node stores the trust map in an account book of the management node. Further optionally, the management node stores the trust map by a third intelligent contract.
Optionally, the trust map includes a third trust value, and the third trust value is a trust value from the first domain to the second domain at the first time. And the management node acquires a fourth trust value at the second moment and updates the third trust value into the fourth trust value. Wherein the second time is later than the first time. Specifically, the management node periodically reads the trust value of each node except the management node in the federation chain, and updates the trust value stored in the management node.
704. And the first node determines the trust value meeting the first preset condition according to all the obtained trust values.
Specifically, the first preset condition is preconfigured, for example, the first preset condition may be a default value, pre-stored, or obtained by a manager in a manner of rewriting according to the service parameter of the service of the first domain. For another example, when the trust value obtained by the first node is greater than a certain threshold, it is determined that the first service can be deployed between two domains corresponding to the trust value.
705. The first node deploys a first service on a domain corresponding to the trust value meeting a first preset condition.
In the above scheme, first, the present application determines a trust domain according to a service to be deployed. The management node is then queried for trust values between the trust domains. And performing service deployment on the trust domain corresponding to the trust value meeting the condition. The trust relationship between any two domains corresponding to the nodes in the alliance chain can be obtained in time, and batch obtaining of the trust relationship between the domains is achieved.
Secondly, the management node and all the nodes in the management domain of the management node form a federation chain. Besides the management node, other nodes in the federation chain store trust values from the domain represented by the node to other domains. The management node stores trust values in all nodes. Therefore, all trust values are stored in the nodes of the federation chain, so that the trust values of all domains are not tampered, and the occurrence of pseudo trust domains can be further prevented. And a distributed management method for inter-domain trust evaluation is also provided.
Thirdly, in the application, the first node can acquire the interaction times and the interaction success times of the first node and the second node in a preset time period. And calculating the trust value from the first domain represented by the first node to the second domain represented by the second node according to the interaction times and the interaction success times. Therefore, the method realizes the quantitative calculation method of the inter-domain trust evaluation, and can digitally represent the result of the inter-domain trust evaluation so as to facilitate the subsequent processing.
The embodiment of the present invention may perform the division of the function modules for the device for determining the inter-domain trust relationship according to the method embodiment, for example, each function module may be divided corresponding to each function, or two or more functions may be integrated into one processing module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. It should be noted that, the division of the modules in the embodiment of the present invention is schematic, and is only a logic function division, and there may be another division manner in actual implementation.
Referring to fig. 10, the present application provides an apparatus for confirming trust relationship between domains, which is used for a first node or a chip on the first node, and includes: a determining module 1001, configured to determine a first service to be deployed; the determining module 1001 is further configured to determine at least two trust domains of the first service; a query module 1002, configured to query and obtain, in a management node, a trust value between any two trust domains of the at least two trust domains determined by the determination module 1001; the first node and the management node belong to the same alliance chain, and the management node stores trust values from a domain represented by each node except the management node in the alliance chain to any other domain; for each node except the management node, any other domain is represented by any other node except the management node and the node; the determining module 1001 is further configured to determine, according to all the trust values obtained by the querying module 1002, a trust value that meets a first preset condition; a processing module 1003, configured to deploy the first service on the domain corresponding to the trust value that meets the first preset condition and is determined by the determining module 1001.
Optionally, the obtaining module 1004 is configured to obtain the number of interactions between the first node and a second node in a predetermined time period and the number of successful interactions, where the second node is any node in the federation chain other than the management node and different from the first node; the processing module 1003 is further configured to calculate a first trust value from a first domain represented by the first node to a second domain represented by the second node according to the number of interactions and the number of successful interactions; a storage module 1005, configured to store the calculated first trust value.
Optionally, the obtaining module 1004 is specifically configured to receive, by a first node, a data packet sent by the second node, where the data packet includes a service parameter in a second domain represented by the second node; the obtaining module 1004 is specifically configured to determine that the interaction success frequency is the stored interaction success frequency plus one if it is determined that the service parameter meets a second preset condition, where an initial value of the interaction success frequency is 0.
Optionally, a first trust value from a first domain represented by the first node to a second domain represented by the second node satisfies a formula
Wherein, T 12 Representing a trust value from the first domain to the second domain, m representing the number of successful interactions, and n representing the number of interactions.
Optionally, the obtaining module 1004 is further configured to obtain a target service parameter of a target service, where the target service is a service performed in a first domain and a third domain; the determining module 1001 is further configured to determine at least one third domain according to the target service parameter; the query module 1002 is further configured to query and obtain a second trust value from the first domain to each third domain in a management node; the processing module 1003 is further configured to determine that a target trust value exists in the second trust value, determine a third domain corresponding to the target trust value as a second domain, and determine a node of the second domain as a second node, where the target trust value is a second trust value that is greater than a predetermined threshold and is the largest.
Referring to fig. 11, the present application provides an apparatus for confirming trust relationship between domains, where the apparatus is used for a management node or a chip on the management node, and includes: an obtaining module 1111, configured to obtain a trust value in each node except a management node in a federation chain, where the trust value is generated by interaction between every two nodes except the management node in the federation chain; each node in the federation chain, except the management node, represents a domain; a storage module 1112, configured to store all the trust values obtained by the obtaining module 1111.
Optionally, the storage module 1112 is specifically configured to generate a trust map from the trust value according to a preset rule, where the trust map includes a relationship between each node in the federation chain and the trust value except for a management node; the storage module 1112 is specifically configured to store the trust map.
Further, the present application also provides a computer-readable storage medium (or media) comprising instructions that, when executed, perform the operations of the method for confirming inter-domain trust relationship in the above embodiments. Additionally, a computer program product is also provided, comprising the above-described computer-readable storage medium (or media).
All relevant contents of each step related to the above method embodiment may be referred to the functional description of the corresponding functional module, and the function thereof is not described herein again.
It should be understood that, in various embodiments of the present invention, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.
Those of ordinary skill in the art will appreciate that the various illustrative modules, elements, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other ways. For example, the device embodiments described above are merely illustrative, e.g., multiple units or components may be combined or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.
The functions may be stored in a computer-readable storage medium if they are implemented in the form of software functional units and sold or used as separate products. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.
The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present invention, and all the changes or substitutions should be covered within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.
Claims (10)
1. A method for confirming trust relationship between domains is characterized by comprising the following steps:
a first node determines a first service to be deployed;
the first node determines at least two trust domains for the first service;
the first node inquires and acquires a trust value between any two trust domains in the at least two trust domains in a management node; the first node and the management node belong to the same alliance chain, and the management node stores trust values from a domain represented by each node except the management node in the alliance chain to any other domain; for each node except the management node, any other domain is represented by any other node except the management node and the node;
the first node determines a trust value meeting a first preset condition according to all the obtained trust values;
the first node deploys a first service on a domain corresponding to a trust value meeting a first preset condition;
the first node acquires the interaction times and the interaction success times of the first node and a second node in a preset time period, wherein the second node is any node in the alliance chain except the management node and different from the first node;
the first node calculates a first trust value from a first domain represented by the first node to a second domain represented by the second node according to the interaction times and the interaction success times;
the first node stores the calculated first trust value;
before the first node obtains the number of interactions between the first node and the second node within a predetermined time period and the number of successful interactions, the method further includes:
the first node acquires a target service parameter of a target service, wherein the target service is a service performed in a first domain and a third domain;
the first node determines at least one third domain according to the target service parameters;
the first node inquires and acquires a second trust value from the first domain to each third domain in a management node;
and if the first node determines that the second trust value has the target trust value, determining a third domain corresponding to the target trust value as a second domain, and determining a node of the second domain as a second node, wherein the target trust value is the second trust value which is greater than a preset threshold value and is the largest.
2. The method according to claim 1, wherein the acquiring, by the first node, the number of successful times of interaction between the first node and the second node within a predetermined time period comprises:
the first node receives a data message sent by the second node, wherein the data message comprises service parameters in a second domain represented by the second node;
and if the first node determines that the service parameter meets a second preset condition, determining that the interaction success frequency is the stored interaction success frequency plus one, wherein the initial value of the interaction success frequency is 0.
3. The validation method of claim 1, wherein the first node calculates a first trust value from a first domain represented by the first node to a second domain represented by the second node according to the number of interactions and the number of successful interactions, comprising:
a first trust value of a first domain represented by the first node to a second domain represented by the second node satisfies a formula
Wherein, in the step (A),
representing a trust value of the first domain to the second domain,
the number of times the interaction was successful is indicated,
representing the number of interactions.
4. A method for confirming trust relationship between domains is characterized in that,
the management node acquires a trust value in each node except the management node in the alliance chain, wherein the trust value is generated by interaction of every two nodes except the management node in the alliance chain; each node in the federation chain except the management node represents a domain, the trust value of one node comprises the trust value of the domain represented by the one node to any other domain, and the any domain is represented by any other node except the management node and the one node;
the management node stores all acquired trust values, wherein the all trust values comprise a second trust value from a first domain to each third domain, the first domain is a domain corresponding to the first node, the first node and the management node belong to the same alliance chain, and the third domain is a domain determined by the first node according to target service parameters;
the management node stores all the obtained trust values, including:
the management node generates a trust map from the trust value according to a preset rule, wherein the trust map comprises the relationship between each node and the trust value except the management node in the alliance chain;
the management node stores the trust map.
5. An apparatus for confirming trust relationship between domains, which is used for a first node or a chip on the first node, and is characterized in that the apparatus comprises:
the determining module is used for determining a first service to be deployed;
the determining module is further configured to determine at least two trust domains of the first service;
the query module is used for querying and acquiring the trust value between any two trust domains in the at least two trust domains determined by the determination module in the management node; the first node and the management node belong to the same alliance chain, and the management node stores trust values from a domain represented by each node except the management node in the alliance chain to any other domain; for each node except the management node, any other domain is represented by any other node except the management node and the node;
the determining module is further configured to determine, according to all the trust values obtained by the querying module, a trust value meeting a first preset condition;
the processing module is used for deploying a first service on a domain corresponding to the trust value which is determined by the determining module and meets a first preset condition;
an obtaining module, configured to obtain interaction times and interaction success times of the first node and a second node in a predetermined time period, where the second node is any node in the federation chain other than the management node and different from the first node;
the processing module is further configured to calculate a first trust value from a first domain represented by the first node to a second domain represented by the second node according to the number of interactions and the number of successful interactions;
the storage module is used for storing the calculated first trust value;
the acquiring module is further configured to acquire a target service parameter of a target service, where the target service is a service performed in a first domain and a third domain;
the determining module is further configured to determine at least one third domain according to the target service parameter;
the query module is further configured to query and acquire, in a management node, a second trust value from the first domain to each of the third domains;
the processing module is further configured to determine that a target trust value exists in the second trust value, determine a third domain corresponding to the target trust value as a second domain, and determine a node of the second domain as a second node, where the target trust value is a second trust value that is greater than a predetermined threshold and is the largest.
6. The confirmation apparatus according to claim 5,
the obtaining module is specifically configured to receive, by a first node, a data packet sent by a second node, where the data packet includes a service parameter in a second domain represented by the second node;
the obtaining module is specifically configured to determine that the interaction success frequency is the stored interaction success frequency plus one if it is determined that the service parameter meets a second preset condition, where an initial value of the interaction success frequency is 0.
7. The confirmation apparatus according to claim 5,
a first trust value of a first domain represented by the first node to a second domain represented by the second node satisfies a formula
Wherein, in the step (A),
representing a trust value of the first domain to the second domain,
the number of times the interaction was successful is indicated,
representing the number of interactions.
8. An apparatus for confirming trust relationship between domains, which is used for a management node or a chip on the management node, and is characterized in that the apparatus comprises:
the system comprises an acquisition module, a processing module and a processing module, wherein the acquisition module is used for acquiring a trust value in each node except a management node in a alliance chain, and the trust value is generated by interaction of every two nodes except the management node in the alliance chain; each node in the federation chain except the management node represents a domain, the trust value of one node comprises the trust value of the domain represented by the one node to any other domain, and the any domain is represented by any other node except the management node and the one node;
a storage module, configured to store all trust values obtained by the obtaining module, where the all trust values include a second trust value from a first domain to each third domain, the first domain is a domain corresponding to a first node, the first node and the management node belong to the same federation chain, and the third domain is a domain determined by the first node according to a target service parameter;
the storage module is specifically configured to generate a trust map from the trust value according to a preset rule, where the trust map includes a relationship between each node and the trust value except for a management node in the federation chain;
the storage module is specifically used for storing the trust map.
9. An inter-domain trust relationship validation apparatus comprising a processor that executes computer-executable instructions to cause the inter-domain trust relationship validation apparatus to perform the inter-domain trust relationship validation method as recited in any one of claims 1 to 4 when the inter-domain trust relationship validation apparatus is operating.
10. A computer-readable storage medium comprising instructions that, when executed on a computer, cause the computer to perform a method of validating an inter-domain trust relationship according to any one of claims 1-4.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010014989.7A CN111262724B (en) | 2020-01-07 | 2020-01-07 | Method and device for confirming trust relationship between domains |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010014989.7A CN111262724B (en) | 2020-01-07 | 2020-01-07 | Method and device for confirming trust relationship between domains |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111262724A CN111262724A (en) | 2020-06-09 |
| CN111262724B true CN111262724B (en) | 2023-03-24 |
Family
ID=70945065
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010014989.7A Active CN111262724B (en) | 2020-01-07 | 2020-01-07 | Method and device for confirming trust relationship between domains |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111262724B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112235360B (en) * | 2020-09-26 | 2022-09-06 | 建信金融科技有限责任公司 | Data sharing method, device and system based on alliance chain, electronic equipment and computer readable storage medium |
| CN112351019B (en) * | 2020-10-29 | 2021-08-13 | 北京邮电大学 | Identity authentication system and method |
| CN115543924B (en) * | 2022-11-29 | 2023-08-15 | 粤港澳大湾区数字经济研究院(福田) | Task processing method and related device based on trusted management platform |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101753565A (en) * | 2009-12-08 | 2010-06-23 | 东南大学 | Construction method crossing trust domain and trust relationship in computer network |
| CN101902459A (en) * | 2010-03-18 | 2010-12-01 | 中国科学院计算技术研究所 | Trust selection method and system for nodes in P2P network by applying P4P |
| CN102404232A (en) * | 2011-12-20 | 2012-04-04 | 上海电机学院 | System and method for multi-domain access control |
| CN105631714A (en) * | 2016-01-05 | 2016-06-01 | 浙江工商大学 | SDN resource transaction method based on credibility mechanism |
| CN107995197A (en) * | 2017-12-04 | 2018-05-04 | 中国电子科技集团公司第三十研究所 | A kind of method for realizing across management domain identity and authority information is shared |
| WO2019102191A1 (en) * | 2017-11-24 | 2019-05-31 | Zeetta Networks Limited | A system for providing an end-to-end network |
| EP3391609B1 (en) * | 2015-12-19 | 2019-06-05 | Telefonaktiebolaget LM Ericsson (publ) | A method and apparatus for trust based authentication in sdn clustering |
-
2020
- 2020-01-07 CN CN202010014989.7A patent/CN111262724B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101753565A (en) * | 2009-12-08 | 2010-06-23 | 东南大学 | Construction method crossing trust domain and trust relationship in computer network |
| CN101902459A (en) * | 2010-03-18 | 2010-12-01 | 中国科学院计算技术研究所 | Trust selection method and system for nodes in P2P network by applying P4P |
| CN102404232A (en) * | 2011-12-20 | 2012-04-04 | 上海电机学院 | System and method for multi-domain access control |
| EP3391609B1 (en) * | 2015-12-19 | 2019-06-05 | Telefonaktiebolaget LM Ericsson (publ) | A method and apparatus for trust based authentication in sdn clustering |
| CN105631714A (en) * | 2016-01-05 | 2016-06-01 | 浙江工商大学 | SDN resource transaction method based on credibility mechanism |
| WO2019102191A1 (en) * | 2017-11-24 | 2019-05-31 | Zeetta Networks Limited | A system for providing an end-to-end network |
| CN107995197A (en) * | 2017-12-04 | 2018-05-04 | 中国电子科技集团公司第三十研究所 | A kind of method for realizing across management domain identity and authority information is shared |
Non-Patent Citations (1)
| Title |
|---|
| P2P网络信任数据存储机制综述;方群;《计算机科学》;20181125;第35卷(第11期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111262724A (en) | 2020-06-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111262724B (en) | Method and device for confirming trust relationship between domains | |
| CN112003703B (en) | Method and device for transmitting authenticatable message across chains | |
| Bhat et al. | Edge computing and its convergence with blockchain in 5G and beyond: Security, challenges, and opportunities | |
| CN103168445B (en) | The controlling mechanism that reliabilty and availability in for virtual network sets | |
| CN109845303A (en) | The management method and administrative unit of network slice | |
| CN112491707B (en) | Method and device for determining forwarding path | |
| EP3392784B1 (en) | Method and system for managing resource objects | |
| CN113661683B (en) | Method for storing transactions representing asset transfer in distributed network and program therefor | |
| US20210027260A1 (en) | A system for providing an end-to-end network | |
| US11425028B2 (en) | Priority based automated network selection for micro-services in service mesh | |
| CN111654399B (en) | Networking method, device, equipment and storage medium based on SD-WAN | |
| JP2017143452A (en) | Management device, and network service management method | |
| JP6838760B2 (en) | Traffic engineering service mapping | |
| CN113055190B (en) | Access control method for client | |
| CN112003822A (en) | Quality detection method and device for route origin authorization | |
| CN113326290B (en) | Cross-network query control method | |
| CN104158736B (en) | A kind of method and apparatus for determining next-hop, issuing routing iinformation | |
| CN113259117B (en) | Method for synchronizing node information lists | |
| CN113259120B (en) | Method for synchronizing node information lists | |
| CN105656778B (en) | The method and SDN controller and SDN-OAF of calling routing algorithm | |
| CN112329058B (en) | Access control method, device and medium for multi-organization user information | |
| CN113596168A (en) | Block chain alliance chain-based verification method and device | |
| CN117675355A (en) | Multi-layer network data exchange method and system based on node identification matching | |
| US11231920B2 (en) | Electronic device management | |
| Yao et al. | Slice-based network transit service: Inter-domain l2 networking on exogeni |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |