Credible customized cross-domain routing method based on crowdsourcing

Abstract

The invention discloses a crowdsourcing-based credible customized cross-domain routing method, which comprises the following steps of: a routing preparation stage: constructing a global credible network topology based on credible path routing, a credible insurance mechanism and a block chain; in the crowdsourcing routing stage, in response to the customized cross-domain routing request, the boundary routers in the network domains compete for the cross-domain routing undertaking right in an auction participation mode, and bid information is transmitted back to the source domain; the router in the source domain determines an auction result to determine a global optimal routing path, so that the source domain user transmits the data packet to the target domain by using the global optimal routing path; in the routing settlement stage, routing settlement is carried out according to the transmission performance committed by the border router participating in data packet transmission, the expected service charge and the actual transmission performance. According to the method, continuous and credible cross-domain routing with fine-grained customization, resource optimization and trust guarantee can be realized in an Intete-HetNet complex and changeable network environment.

Description

Technical Field

[0001] The present invention belongs to the technical field of cross-domain routing, and in particular relates to a crowdsourcing-based trusted customized cross-domain routing method. Background Art

[0002] In the grand blueprint of future networks, seamless integration of traditional networks, 4G, 5G and even non-terrestrial networks to build a complex and efficient heterogeneous converged network (Inte-HetNet) has become a core vision. As a frontier of technological innovation, Inte-HetNet integrates a variety of technical support network domains, laying a solid foundation for the free flow of information across domains. However, on the broad stage of Inte-HetNet, the problem of cross-domain routing is like a river that stretches in front of it. Its depth and breadth are self-evident challenges to technology, especially how to achieve routing across multiple network domains and ensure trusted routing that meets specific needs, which are key issues that need to be solved urgently.

[0003] With the explosive development of emerging applications and diversified services such as video conferencing, remote VR experience, high-definition live broadcast, autonomous driving, and the Metaverse, the requirements for 5G and even future 6G communication technologies have risen to unprecedented heights, posing a severe test for Inte-HetNet. Different user groups and network applications have put forward highly personalized and stringent requirements for performance indicators such as bandwidth, latency, packet loss rate, path trust, and jitter. For example, live broadcasting pursues the dual extremes of immediacy and high-definition image quality, while video conferencing requires near-perfect communication quality, and any slight delay or jitter may affect the user experience. Unfortunately, the "best effort" forwarding mechanism adopted by the traditional Internet seems to be unable to cope with these diverse requirements. What is particularly critical is that different network domains in the Inte-HetNet often belong to different operators, and the weak trust foundation between them makes it difficult for users to obtain a routing path that is both in line with expectations and fully trustworthy when seeking cross-domain services. This "expectation" is not only about precise matching at the technical level, but also involves full trust assurance and dynamic maintenance from the source to the destination.

[0004] In response to the problems of cross-domain routing being difficult to implement and trusted routing with specific requirements being difficult to ensure, although academia and industry have proposed a variety of cross-domain routing solutions, none of them have been able to fully overcome the existing limitations.

[0005] The primary problem is that it is difficult to maintain the continuous credibility of the route. Many existing solutions rely on the trust evaluation mechanism of the node to screen the trusted routes, but this method can only guarantee trust at the moment of evaluation, but it is difficult to cope with the dynamic changes of trust over time and environmental factors, resulting in the difficulty of long-term guarantee of the credibility of the route, and therefore the credibility of the entire data transmission process is difficult to guarantee.

[0006] Secondly, existing solutions often adopt a "one-size-fits-all" approach when processing service requests, ignoring the diversity and personalization of user needs. This crude processing method without differentiation limits the customization of routing and cannot flexibly adapt to the specific requirements of different users or applications for bandwidth, latency, packet loss rate and other indicators, thus affecting the overall quality of network services and user experience.

[0007] Furthermore, the widespread use of passive routing strategies in existing solutions has hindered the optimal configuration and maximization of network resources. Passive routing, which is a method of transmitting data based on established routing tables, flow tables, and administrator configurations, has obvious disadvantages: it cannot actively respond to users' specific needs for paths, nor can it dynamically adjust resource allocation according to demand, which limits the optimal configuration of network resources and hinders the optimal configuration and maximization of network resources, resulting in resource waste and inefficient utilization. What is particularly critical is that when network operators try to obtain higher profits by giving priority to high-value communications, the limitations of passive routing are particularly prominent because it cannot perceive and adapt to this business strategy, and thus cannot reserve enough resources for high-value communications, limiting the operator's profit growth potential.

[0008] In summary, a new cross-domain routing solution is urgently needed to solve the problems existing in the above existing solutions. Summary of the invention

[0009] In order to solve the above problems existing in the prior art, the present invention provides a trusted customized cross-domain routing method based on crowdsourcing.

[0010] The technical problem to be solved by the present invention is achieved through the following technical solutions:

[0011] A crowdsourcing-based trusted customized cross-domain routing method, comprising: a routing preparation phase, a crowdsourcing routing phase and a routing settlement phase;

[0012] In the routing preparation phase, a global trusted network topology is constructed based on trusted path routing technology, trust insurance mechanism and blockchain technology;

[0013] In the crowdsourcing routing stage, in response to a customized cross-domain routing request initiated by a source domain user, the border routers in each network domain compete for the right to undertake cross-domain routing by participating in an auction according to the global trusted network topology, and transmit the bidding information back to the source domain; the routers in the source domain determine the auction result according to the bidding information to determine the global optimal routing path, so that the source domain user uses the global optimal routing path to transmit the data packet to the target domain; wherein the bidding information includes the transmission link and transmission performance promised by the border router, and also includes the service fee expected by the border router;

[0014] In the routing settlement phase, routing settlement is performed based on the transmission performance promised by the border routers participating in the data packet transmission, the expected service fee and their actual transmission performance.

[0015] The crowdsourcing-based trusted customized cross-domain routing method provided by the present invention has the following beneficial effects:

[0016] (1) The present invention constructs a global trusted network topology based on trusted path routing technology, trust insurance mechanism and blockchain technology, which can effectively ensure the continuous credibility of routing and guarantee the integrity and security of routing information, thus laying a solid trust foundation for cross-domain routing.

[0017] (2) In the present invention, users can make customized cross-domain routing requests and achieve precise control and optimization of routing paths based on the crowdsourcing auction technology. This highly flexible customization capability will greatly improve user experience and meet the diverse needs of future network services.

[0018] (3) The present invention introduces a routing settlement phase and performs routing settlement based on the transmission performance promised by the border routers participating in data packet transmission, the expected service fee and their actual transmission performance, thereby encouraging network domains to actively participate in routing and optimize routing decisions, thereby achieving optimal configuration and efficient utilization of network resources. This not only helps to improve the overall network performance, but also promotes healthy competition and cooperation among operators to achieve a win-win situation.

[0019] The present invention will be further described in detail below with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 It is a system architecture diagram based on which the crowdsourcing-based trusted customized cross-domain routing method provided by an embodiment of the present invention is based;

[0021] Figure 2 It is a flowchart of a crowdsourcing-based trusted customized cross-domain routing method provided by an embodiment of the present invention;

[0022] Figure 3 yes Figure 1 An interaction diagram of the system shown when implementing the crowdsourcing-based trusted customized cross-domain routing method provided in an embodiment of the present invention;

[0023] Figure 4 The figure shows the benefits of NO and UE in the game in the embodiment of the present invention;

[0024] Figure 5(a) to Figure 5(f) This is a specific example of implementing trusted customized cross-domain routing using the crowdsourcing-based trusted customized cross-domain routing method provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0025] The present invention is further described in detail below with reference to specific embodiments, but the embodiments of the present invention are not limited thereto.

[0026] In the complex and ever-changing network environment of Inte-HetNet, cross-domain routing solutions must have at least the following key features: first, it must be able to ensure the continuous credibility of routing throughout the entire data transmission process; second, it must support fine-grained user customization to meet diverse needs; and third, it must be able to actively optimize resource allocation to achieve efficient use of network resources and maximize operator profits. However, achieving the above goals faces multiple severe challenges in the complex environment of Inte-HetNet.

[0027] First, given the heterogeneity and large-scale characteristics of Inte-HetNet, it is particularly difficult to build a persistent and trusted cross-domain routing method that can cross different technical architectures and scale boundaries. This heterogeneity is not only reflected in the diversity of network technologies, but also involves the trust gap between different network domains, which adds many obstacles to establishing a stable and trusted routing path.

[0028] Secondly, the complexity of routing decisions further increases the difficulty of implementing fine-grained customized routing. In Inte-HetNet, each routing decision must take into account a variety of current and future needs to ensure that it can meet the user's immediate needs while also being able to adapt to future changes in demand. This requirement for comprehensiveness and foresight makes the design and implementation of fine-grained customized routing particularly complex and challenging.

[0029] In addition, the dynamic changes in user demand for network resources and the complexity of the Inte-HetNet itself have put forward higher requirements for motivating network domains to actively participate in cross-domain routing. How to design an effective incentive mechanism to encourage each network domain to reasonably allocate and optimize network resources while pursuing its own interests to support the smooth implementation of cross-domain routing is a major problem currently faced.

[0030] As can be seen from the above, the difficulty of implementing cross-domain routing in Inte-HetNet is significantly higher than intra-domain routing across different trusted domains. This is because cross-domain routing not only needs to cross the boundaries of technology and trust, but also needs to face more complex and changeable network environments and user needs.

[0031] In order to overcome the above challenges and realize cross-domain routing with continuous trust, fine-grained customization, resource optimization and trust assurance, the embodiment of the present invention provides a crowdsourcing-based trusted customized cross-domain routing method. First, the system architecture based on which the method is based is described. Figure 1 As shown, there are mainly four types of entities:

[0032] User Equipment (UE): As the final user of network services, UE accesses the network domain through an access point (such as an entry router or base station) and initiates a cross-domain routing request on this basis. UE is not only the initiator of routing requests, but also the receiver of routing results. It plays a vital role in cross-domain communication. As the final beneficiary of the service, UE aims to pursue a trusted and personalized network experience, so UE can be regarded as a trusted entity.

[0033] Network Operator (NO): As a service provider in the Inte-HetNet, it provides various network services to UEs. NOs are responsible for maintaining routing-related information (such as traffic matrix and network topology) within their network domains and controlling the operation of all routers within the domain. Cooperation and competition between NOs coexist to jointly promote the optimization and development of cross-domain routing services. NOs are trustworthy within their network domains, but different NOs do not trust each other. There is also a competitive relationship between different NOs, and they may attract UEs by providing incorrect topology or network communication capabilities in order to gain more profits.

[0034] Router: Routers are the cornerstone of data transmission. According to their functions, they can be divided into border routers (BRs) and internal routers (IRs). BRs are located at the boundaries of domains and serve as a bridge for inter-domain communication. They are responsible for transmitting data packets between different domains. IRs are located within domains and focus on forwarding data packets within the domain. IRs are responsible for receiving and forwarding cross-domain requests from UEs or other IRs to BRs. IRs in the source domain are also responsible for notifying UEs of the final routing results. BRs are responsible for building cross-domain routing paths to assist UEs in transmitting data packets across domains. In order to enhance the security and credibility of the routing process, each BR is equipped with an asymmetric key and a trusted platform module (TPM). The former is used to ensure the integrity and non-repudiation of relevant information during the routing process, and the latter is used to verify the trust status of the router during the routing preparation process. In addition, all routers are under the strict management of NO and have established a solid trust relationship with each other. At the same time, UEs also have reasonable trust expectations for IRs in the network domains they access. As for BRs in different network domains, they initially do not trust each other. However, through the remote authentication of blockchain and the embedding of trust conditions, these BRs can gradually establish a trust relationship, which can then be extended to trust the IRs in their domains.

[0035] Blockchain network: It is composed of blockchain nodes scattered in multiple network domains. These nodes implement the established functions of the blockchain by executing smart contracts. BRs in each network domain can complete information exchange by connecting to the blockchain. In the embodiment of the present invention, the blockchain has two functions: 1) verify the legitimacy of the BR status in each domain, and record and store routing related information to support trusted cross-domain routing; 2) perform routing settlement fairly for network domains participating in cross-domain routing.

[0036] In the complex and heterogeneous network environment of Inte-HetNet, the lack of trust between different network domains becomes a major obstacle to cross-domain routing, especially when these network domains are managed by independent network operators (NOs). In view of the wide distribution, large-scale characteristics and multi-domain heterogeneity of Inte-HetNet, it is particularly impractical and challenging to rely on traditional centralized trusted third parties to manage cross-domain routing information. In order to overcome these difficulties, the embodiment of the present invention creatively introduces blockchain technology to build a decentralized, high-trust cross-domain routing solution. Blockchain is not only the guardian of trust between network domains, but also bears the heavy responsibility of managing and storing routing-related information. Through its distributed ledger characteristics and tamper-proof data recording method, blockchain ensures the transparency and security of routing information. In addition, blockchain also realizes reliable authentication of routing devices and fair reward calculation of cross-domain routing participants through the automatic execution of smart contracts. Under the protection of blockchain technology, the embodiment of the present invention assumes that as long as the number of malicious nodes does not exceed its fault tolerance, the system can maintain a high degree of security.

[0037] Combination Figure 1 It can be seen that the complex and ever-changing integrated heterogeneous network (Inte-HetNet) environment forms a system containing multiple independently managed network domains. These network domains form a huge topology graph G = (V, E) through interconnected router nodes and links, where V represents the set of all router nodes in G, and E represents the set of links connecting these nodes. For routing in Inte-HetNet, users have diverse routing preferences and requirements for different transmission tasks. How to effectively meet these requirements has become the core issue of the embodiments of the present invention. In order to clearly represent the user's routing requirements, the embodiments of the present invention introduce a numerical scheme to formalize the routing preferences by combining different attributes of the routing path.

[0038] Specifically, the routing path contains various attributes, which can be mainly divided into two categories: numerical attributes and non-numerical attributes. The former represents attributes that can be represented by a single numerical value, such as bandwidth, delay, packet loss rate, and routing trust (i.e., QoT). The latter represents attributes that cannot be described by a single numerical value, such as device model, distribution area, etc. Each attribute has its corresponding unit. For example, the unit of bandwidth is megabits per second (Mbps), and the unit of delay is milliseconds (ms). In order to fully describe routing attributes, an embodiment of the present invention defines a flexible routing attribute set Attr:

[0039] Attr={At1,At2,…,At n};

[0040] Among them, At i(i=1,2,…,n) represents the i-th routing attribute, which can be bandwidth, delay or packet loss, etc.

[0041] Based on the above routing attribute set, the embodiment of the present invention adopts a customized routing preference vector Pref to describe the user's requirements for different routing attributes. The Pref is expressed as:

[0042] Pref={(At1,th1,wt1),…,(At n ,th n ,wt n )};

[0043] Among them, i (i=1,2,…,n) represents the user's attribute At i The minimum requirement or acceptable range of wt i (i=1,2,…,n) represents the attribute At i The weight of the attribute At i The proportion of all attributes, In practice, wt i The value can be set dynamically according to specific application scenarios and user needs.

[0044] Based on the above settings, the purpose of the embodiment of the present invention is: given an Inte-HetNet topology graph G, the user UE initiates a cross-domain routing request from the source address Src to the destination address Dest in G, and the customized routing requirement of the UE is Pref. The goal of solving the problem is: in the topology graph G, find a path Path from the source address Src to the destination address Dest for the user UE, and the path should meet all the following conditions:

[0045] (1) Path existence: The path Path must exist in the graph G, that is, it is reachable from Src to Dest.

[0046] (2) Satisfy the customized routing requirements of the UE: The path Path should meet the customized requirements Pref of the user UE in all considered routing attributes. This usually means that the path Path has a certain number of attributes in each attribute At i The performance on (i=1,2,…,n) at least meets the minimum requirement set by UE i , and according to the attribute weight wt i When conducting a comprehensive evaluation, the path Path is optimal.

[0047] (3) Continuous routing trust: In the process of path selection, it is necessary to ensure that each routing decision is based on reliable information to prevent interference or tampering by malicious nodes. Specifically, technologies such as blockchain can be used to verify, record and maintain routing trust information.

[0048] (4) Reasonable resource allocation: When selecting a path, we should consider how to motivate network domains to actively participate in cross-domain routing to promote the rational use of network resources and avoid excessive concentration of certain resources or resource bottlenecks.

[0049] Based on the above system architecture and settings, see Figure 2 and Figure 3 As shown, the crowdsourcing-based trusted customized cross-domain routing method provided by the embodiment of the present invention includes: a routing preparation stage, a crowdsourcing routing stage, and a routing settlement stage.

[0050] Among them, in the routing preparation stage, a global trusted network topology is built based on trusted path routing technology, trust insurance mechanism and blockchain technology.

[0051] Regarding the trusted path routing technology, this is a technology for establishing a trusted topology. A trusted topology is a network topology built by trusted verified devices. The paths in this topology are considered trustworthy. Trusted path routing uses mutual authentication between network devices configured with a TPM trusted platform module to establish a trust relationship between devices. Specifically, the network device first authenticates itself through the TPM to generate a Stamped Passport. Stamped Passport is a data structure used to transmit verification information and establish a trust relationship between network devices. Among them, each Stamped Passport includes the latest authentication result provided by the verifier and the latest TPM Quote of the authenticator. TPM Quote is a data structure generated by TPM to prove the identity and status of the device, including public keys, certificates, and device status summary information. During mutual authentication, devices can establish a trust relationship by exchanging TPM Quotes to prove their identity and status. Then, network devices exchange Stamped Passports with each other by applying link layer protocols such as 802.1x and MACsec to establish and maintain a trust relationship between them. Due to the transferable trust relationship between them, all mutually trusted devices can build a trusted topology. By sending and receiving packets within a trusted topology, users can gain trusted transmission.

[0052] As for the Trust Assurance Mechanism (TIM), as an innovative trust assurance mechanism based on the principle of trusted computing, it is tailored for the network function virtualization (NFV) infrastructure and aims to provide it with an indestructible security barrier. The mechanism cleverly integrates the root trust module (RTM) of TPM into the NFV platform, making it the core engine of trust verification. Through the platform configuration query function, the NFV platform can easily verify the trust status of other platforms (such as platform Y) and establish a trust foundation between the two parties. In the early stage of establishing a trust relationship, the NFV platform will embed its customized trust conditions into the RTM of platform Y. These conditions specify under what circumstances to trust platform Y and how to respond when the trust conditions change. Once the trust conditions change, the RTM of platform Y will immediately issue an alert to the NFV platform, prompting the NFV platform to re-evaluate the trust status of platform Y and update the trust conditions. At the same time, platform Y also has the same right to embed its own trust conditions for the NFV platform into its RTM to achieve a two-way, continuous and reliable trust relationship. The introduction of this mechanism not only greatly improves the security and reliability of NFV infrastructure, but also promotes the flexible adjustment and dynamic management of trust relationships between platforms, laying a solid foundation for building a more secure, efficient and reliable network environment.

[0053] Specifically, based on trusted path routing technology, trust insurance mechanism and blockchain technology, a global trusted network topology is constructed, including: within the same network domain, the border router and the internal router use trusted path routing technology to mutually verify the identity and status to establish a trusted topology within the domain; the border router is configured with a trusted platform module TPM, and the consensus trust conditions are embedded into the root trust module RTM of the TPM through the blockchain, so as to use the trust insurance mechanism to establish a continuous trust relationship between the blockchain and the border router, so that the border routers that establish a continuous trust relationship with the blockchain trust each other, and realize the establishment of a trusted topology between domains. In this way, a global trusted network topology can be constructed.

[0054] The routing preparation phase aims to verify the trust status of each network domain BR through the blockchain to ensure the credibility of cross-domain routing. Then, the verified trusted BR sends its recorded domain-related information (for example, the topology of the current domain and domain connection information with other domains) to the blockchain. The blockchain integrates this information to generate global network information. After that, the BR of each network domain retrieves the latest global routing information from the blockchain and notifies the IR within the respective network domain to prepare for future cross-domain routing. The main steps include: establishment of a trusted topology within the domain, persistent construction of cross-domain trust relationships, uploading domain-related information to the blockchain, blockchain integration to generate global network information, and BR retrieving and distributing global routing information from the blockchain to the IR within the respective network domain. The specific implementation process is as follows:

[0055] (1) Establishing a trusted topology within the domain: In the same network domain, BRs and internal routers (IRs) use trusted path routing technology to mutually verify their identities and states to ensure the establishment of a trusted topology within the domain. This process ensures that the flow of information and routing decisions within the domain are based on a solid and trusted foundation.

[0056] (2) Building a persistent cross-domain trust relationship: In the face of complex and ever-changing trust challenges between border routers (BRs) between different network domains, the embodiment of the present invention configures a trusted platform module (TPM) for each BR, and uses its unparalleled measurement capabilities to ensure that each BR has a legitimate and authentic identity at the initial stage. This means that any verifier can perform remote and efficient verification based on the known state of the BR to confirm its validity. However, the dynamic nature of the network environment requires that it cannot stop at the initial verification. Once the state of the BR changes, the previous verification cannot guarantee the continuous maintenance of the established trust relationship. Therefore, in order to establish a persistent trust relationship between cross-domain BRs, the embodiment of the present invention introduces TIM (Trust Insurance Mechanism) and realizes the persistent construction and maintenance of BR trust relationships through blockchain technology. Through the blockchain, persistent trust is established with each BR, and based on the transitivity of trust, this trust relationship is extended to every BR in the entire cross-domain network.

[0057] Specifically, the blockchain stores various trust conditions for BRs, which is a consensus between all routers and network domains. In order to establish continuous trust between the blockchain and each BR, the blockchain first needs to evaluate these BRs to establish an initial trust relationship. Then, the blockchain embeds the consensus trust conditions into the RTM of the BR. Once the trust conditions change, the RTM of the BR will notify the blockchain to declare that the BR is untrustworthy. If the BR wants to rebuild trust, the blockchain needs to re-verify it and embed new trust conditions. Based on the above ideas, the blockchain can verify all BRs and establish a lasting trust relationship with them. Due to the trustworthiness of the blockchain, all BRs that have established a continuous trust relationship with the blockchain also trust each other. These blockchain-verified BRs are considered trustworthy by users.

[0058] In addition, the verified BR can establish trust with the IR in the same domain through the trusted path routing technology. Therefore, the cross-domain routing path composed of these verified trusted BRs and IRs (which are trusted by the verified BRs) is considered to be trustworthy. Through a series of operations such as the above verification, the continuous credibility of cross-domain routing can be effectively ensured.

[0059] (3) Upload domain-related information to the blockchain: Each BR that is verified as trustworthy by the blockchain will send its recorded domain-related information Dom and SIG(Dom) to the blockchain. Here, SIG(Dom) is the BR's signature on Dom. Dom and SIG(Dom) are considered as a transaction. Among them, Dom can be constructed as:

[0060]

[0061] Among them, expT represents the timestamp of domain information expiration; ID BR An identifier representing a BR; is the public key of the BR; DID is the unique ID of the network domain where the BR is located; DAddrs indicates the address of the domain to which the BR belongs; linkInf indicates the link information between the BR and BRs in other domains. Each linkInf includes the starting router address srcAddr and the ending router address desAddr of the link, as well as the ID of the starting domain and the ID of the destination domain of the link (expressed as DID des ), linkInf is expressed as:

[0062] linkinf={(srcAddr,desAddr,DID src ,DID des ),…,(),…};

[0063] Here, DID src The ID of the starting domain of the link, DID des The ID of the destination domain of the link.

[0064] (4) Generate global network information: The blockchain generates global trusted network topology information based on all received Doms and updates it dynamically.

[0065] (5) Retrieve and distribute global routing information: The BR in each network domain retrieves the latest global topology information from the blockchain and distributes it to the IR in its own network domain. As a result, each router in the Inte-HetNet (including BR and IR) can obtain the global trusted network topology.

[0066] In the routing preparation stage, relying on the immutability and decentralization of blockchain technology, the border routers (BRs) of each network domain are strictly verified for credibility, and by embedding custom trust conditions into the verified BRs, a persistent trust framework for these key routing devices is built, laying a solid foundation for the full credibility of cross-domain routing. Subsequently, the verified trusted BRs upload detailed routing information in their respective domains to the blockchain, which plays the role of an information integrator, aggregating this information to form global network information, and providing data support for subsequent cross-domain routing decisions.

[0067] In the embodiments of the present invention, a global trusted network topology is constructed based on trusted path routing technology, trust insurance mechanism and blockchain technology, which can effectively ensure the continuous credibility of routing and guarantee the integrity and security of routing information, thereby laying a solid trust foundation for cross-domain routing.

[0068] In the crowdsourcing routing stage, in response to a customized cross-domain routing request initiated by a source domain user, the border routers in each network domain compete for the right to undertake cross-domain routing by participating in an auction according to the global trusted network topology, and transmit the bidding information back to the source domain; the routers in the source domain determine the auction result according to the bidding information to determine the global optimal routing path, so that the source domain user uses the global optimal routing path to transmit the data packet to the target domain; wherein the bidding information includes the transmission link and transmission performance promised by the border router, and also includes the service fee expected by the border router.

[0069] The crowdsourcing routing stage aims to select a route for the user that meets its customized routing requirements. In the process of building a cross-domain routing that meets the highly customized needs of users, the embodiment of the present invention innovatively introduces a crowdsourcing auction mechanism to ensure the flexibility and efficiency of routing selection. Since customized cross-domain routing is based on crowdsourcing routing tasks to multiple network domains, these network domains collaborate to complete cross-domain routing, so the routing solution in the embodiment of the present invention is called crowdsourcing routing. The specific implementation process is as follows:

[0070] First, the UE generates a cross-domain routing request containing its customized requirements based on the network application scenario and its preferences, that is, generates a customized cross-domain routing request RR. The RR contains the information required for cross-domain routing, which is expressed as:

[0071] RR={Src,Dest,Pref,Dura,Load};

[0072] Where Src represents the source address of the customized cross-domain routing request; Dest represents the destination address of the customized cross-domain routing request; Pref = {(At1, th1, wt1),…, (At n ,th n ,wt n )} is the routing preference vector of the source domain user, which describes the customized requirements of the UE for cross-domain routing, including some routing attributes and their corresponding weights; At i (i=1,2,…,n) represents the i-th routing attribute that the customized cross-domain routing request wants to customize. i (i=1,2,…,n) represents the user's i The minimum requirement or acceptable range of wt i (i=1,2,…,n) represents At iThe corresponding weight; Duration indicates the duration for which the customized cross-domain routing request remains valid, which means that the RR will expire after Duration; Load indicates the payload of the customized cross-domain routing request.

[0073] After generating the RR, the source domain user initiates a customized cross-domain routing request to the router in the source domain, that is, the UE sends the RR to the IR near it.

[0074] Then, in response to the source domain user initiating a customized cross-domain routing request to a router in the source domain, the router broadcasts the customized cross-domain routing request to all adjacent border routers in the source domain.

[0075] Specifically, after receiving the RR, the IR parses the RR and obtains the destination address Dest of the UE cross-domain routing. Based on the domain information shared from each border router, it can query the destination network domain where Dest is located. Based on the network domain obtained by the query, referring to the domain-level network topology stored locally, in order to achieve the purpose of spreading the auction in a smaller range, it selects suitable adjacent BRs in the same domain and sends RRs to them. These suitable BRs refer to those BRs that are closer to the destination domain at the domain-level topology level. These BRs serve as connection points between network domains and are responsible for further distributing routing requests to other network domains to prepare for subsequent routing auctions.

[0076] Then, the border router in the source domain that receives the customized cross-domain routing request initiates an auction based on the global trusted network topology and sends the auction message to the outside domain. In this process, each network domain actively participates in the competition through bidding and tendering based on its own routing resources and performance advantages. The auction process is transparent and open, aiming to ensure the fair distribution of routing rights.

[0077] Specifically, the BR in the source domain receives the RR from the IR, which means that the IR notifies these BRs to start a customized cross-domain routing auction in response to the cross-domain routing request initiated by the UE. These BRs initiate the "cross-domain routing auction" by generating some information. Specifically, the BR in the source domain generates an auction message Auc and sets a timer to record the life cycle of the auction. Then, it sends the Auc to the BR in the next network domain. The Auc is represented as follows:

[0078] Auc={aucID,ID,ET,Idil,RR,SIG(aucID,ID,ET,Idil,RR),BRL};

[0079] Among them, aucID is the auction identifier, which is a unique identifier to distinguish different auctions. ID is the unique identifier of the border router that initiates the auction, and ET is the expiration time of the auction message, which means that the auction needs to be completed within the acceptable time indicated by ET. Idil is a list of network domains allowed to participate in the auction. The ID list contains the IDs of network domains that are selected by BR based on the domain information of each network domain and are responsible for future cross-domain data packet transmission. RR represents the customized cross-domain routing request, SIG(·) is a signature function, so SIG(aucID, ID, ET, Idil, RR) represents the signature of the above five items, which is completed by the BR that constructs Auc, in order to ensure the integrity and non-repudiation of RR during transmission. BRL is a list of the addresses of each border router in the transmission path through which the auction message passes. The list initially contains two elements, namely the address of the BR that constructs the Auc and the address of the next BR to which the Auc will be sent.

[0080] From then on, Auc leaves the source domain and spreads to other networks. For any network domain, the link used by Auc when entering the network domain is defined as the entry link, and the border router responsible for receiving the Auc when entering the network domain is defined as the entry border router. Similarly, the link used by Auc when leaving the network domain is defined as the exit link, and the border router responsible for sending the auction message to the outside of the domain when the auction message leaves the network domain is defined as the exit border router.

[0081] In the embodiment of the present invention, for all BRs that receive Auc, if they are ingress BRs, they need to decide whether to participate in the cross-domain routing auction. That is, the ingress border router that receives the auction message first decides whether to participate in the auction. If it decides not to participate in the auction, it discards the auction message; if it decides to participate in the auction, it regenerates the auction message based on the auction message and the global trusted network topology, sends the auction message to the border router it is connected to, and transmits the bidding information back along the original route to the border router that initiated the auction in the source domain.

[0082] Specifically, for any BR outside the source domain, if the Auc received by the BR comes from the previous domain, it means that the BR is an entry BR. Then, it needs to perform the following operations: first parse the Auc, and decide whether to participate in the route auction based on the policy and network status of its network domain. If not, it will discard the Auc. Otherwise, it will save the aucID, ID, ET, Idil and RR, and then perform the following operations:

[0083] First, it is necessary to determine whether the destination address Dest of the customized cross-domain routing request is in the current network domain. If the destination address Dest is not in the current network domain, it means that the Auc needs to continue to propagate to the next network domain. To this end, the entry BR needs to select some inter-domain links as outbound links, and add the addresses of the starting routers and the ending routers of these outbound links to the BRL to form a new BRL (represented by BRL'), and finally obtain a new Auc (i.e. Auc'). Then, the entry BR continues to forward Auc' to the next BR in the current domain. Auc' is expressed as follows:

[0084] Auc'={aucID,ID,ET,Idil,RR,SIG(aucID,ID,ET,Idil,RR),BRL'};

[0085] If the ingress BR determines that the destination address Dest is already in the current network domain, it means that the auction message has reached the target domain. At this time, the ingress BR only needs to add two empty addresses at the end of BRL to prove that there is no outbound link.

[0086] When the auction message sent by the ingress BR reaches the destination domain, it will generate a bid message Bid, and then send the Bid to the BR that initiated the route auction in the opposite direction of the Auc transmission for subsequent bidding. Specifically, when the auction message reaches the destination domain, the ingress BR in the destination domain first bids, generates a Bid, and transmits the Bid to the previous network domain. After that, the ingress BR in the previous network domain bids again, generates a Bid, and transmits the Bid and the received Bid to the previous domain, and so on, until all the Bids of this auction are transmitted to the BR that initiated the route auction.

[0087] When generating Bid, the entry BR participating in the auction needs to add the link it promises to the BRL, and it promises that the link can provide the UE with performance guarantee (expressed as Properf) that meets Pref. Bid also includes the service fee (expressed as Price) that the entry BR expects to obtain when these promised links are selected as cross-domain routing paths. Therefore, the bidding information can be expressed as:

[0088]

[0089] Where aucID is the auction ID corresponding to the bid information, BID is the unique ID of the border router that generates the bid information. Price is the expected service fee, and Properf is the transmission performance promised by the border router that generates the bid information. Here, each item in Properf Each of them corresponds to the items in Pref, indicating that the entry BR has a corresponding i The promised performance should be better than the threshold of the corresponding attribute in Pref, that is, Otherwise, the link promised by the entry BR may be discarded because it cannot meet the requirements of the UE. BBRL is an address list that records the address CsAddr of the starting router and the address CdAddr of the ending router in the link that the auction message received by the border router passes through before entering the current network domain. It also records the address NsAddr of the starting router and the address NdAddr of the ending router in the link that the auction message regenerated by the border router needs to pass through to leave the current network domain. If the destination address Dest of the customized cross-domain routing request is already in the current network domain, NsAddr and NdAddr are both empty addresses. SIG(·) is a signature function, so SIG(aucID, BID, Price, Properf, BBRL) represents the signature of the above five items, which is completed by the entry BR that constructs the Bid. The purpose is to ensure the integrity and non-repudiation of the Bid during transmission.

[0090] It is understandable that, in order to conduct subsequent bidding, the entry BRs that decide to participate in the auction need to provide performance guarantees for some links, which refer to the domain entry links entering the entry BR and the links between the entry BR and the domain exit BR. Therefore, when the entry BR generates the bidding information, it needs to add the link information and the performance guarantee for these links to the generated Bid.

[0091] During the process of Bid being transmitted back in the opposite direction of Auc transmission, if the BR receiving the Bid is an egress BR and the auction time has not expired, the egress BR only needs to forward the received Bid to the previous BR that sent Auc to it before without bidding. If the BR receiving the Bid is an ingress BR, it also needs to bid. Specifically, the ingress BR will check whether the auction corresponding to the Bid is initiated by itself. If so, and the auction time has not expired, it will store the Bid for subsequent routing selection. Otherwise, it checks whether it has decided to participate in the auction corresponding to the Bid. If so, it generates its own Bid. Then, it forwards its own Bid together with the received Bid to the previous BR that sent the auction message to it before, so that all Bids issued by the ingress BRs will be gathered to the BR that initiated the auction in the source domain.

[0092] For any BR outside the source domain, if the Auc received by the BR comes from the current domain, it means that the BR is an egress BR, and the egress BR only needs to forward the auction message to the border router it is connected to without bidding. That is, the egress border router that receives the auction message only needs to forward the auction message to the border router it is connected to.

[0093] When the auction expires, it marks the end of the auction. With the end of the auction, the router in the source domain determines the auction result based on the collected bid information to determine the global optimal routing path, so that the source domain user uses the global optimal routing path to transmit the data packet to the target domain. The specific implementation process is as follows:

[0094] First, the border router initiating the auction in the source domain deletes the bid information that does not meet the transmission performance requirements in the customized cross-domain routing request; determines multiple cross-domain paths that can lead from the source domain to the target domain based on the remaining bid information; calculates the path performance value of each cross-domain path based on the bid information corresponding to the cross-domain path; selects the cross-domain path with the largest path performance value as the candidate routing path; generates an auction result based on the candidate routing path, and sends the auction result to the router in the source domain that responds to the customized cross-domain routing request. It can be understood that the path performance value calculated here is actually the path performance commitment value calculated based on the transmission performance promised by the BR on the cross-domain path.

[0095] Specifically, the BR that initiates the auction will try to form some cross-domain paths based on all the Bids received. Then, the BR calculates the transmission performance of these paths to select a better path that can meet the UE requirements. Among them, the BR that initiates the auction first needs to check whether the promised performance of all received Bids meets the UE requirements, and delete those Bids that do not meet the requirements. Then, it selects those Bids that can be connected back and forth to form a cross-domain routing path, and forms these Bids into a list bidList, and uses the bidList to form multiple cross-domain paths that can lead from the source domain to the target domain. For each cross-domain path, the BR calculates the transmission performance of these paths. Since each segment of a cross-domain path is composed of different Bids, and the links promised in each Bid contain different promised performance, the transmission performance of the cross-domain path can be calculated by combining the promised performance corresponding to all Bids that constitute the cross-domain path.

[0096] The formula for calculating transmission performance can be constructed as the actual weighted sum of routing attributes. For example, assuming that routing attributes include QoT (quality of trust), Bw (bandwidth), De (delay) and PL (packet loss rate), the formula for calculating transmission performance can be expressed as:

[0097]

[0098] Where PPVal path represents the transmission performance, wt1, wt2, wt3 and wt4 represent the weights of QoT, Bw, De and PL respectively. * ,De * ,Bw * and PL * They are the normalized values ​​of QoT, Bw, De and PL of the cross-domain path, all between 0 and 1. Since the units of these routing attributes are different, the purpose of normalization is to facilitate calculation, and many existing methods can be used for normalization.

[0099] Among them, for the cross-domain path Path composed of j Bids, the delay of Path (expressed as De Path ) is equal to the total delay corresponding to all j Bids, that is, Indicates the Bid on the path Path j The packet loss rate of the path (expressed as PL Path ) is equal to the total packet loss corresponding to all j Bids, that is, Indicates the Bid on the path Path j The packet loss rate corresponding to the segment link. The bandwidth of the path (expressed as Bw Path ) is equal to the minimum bandwidth corresponding to all j Bids, that is, Indicates the Bid on the path Path j The bandwidth corresponding to the link segment. The QoT of the path (expressed as QoT Path ) is equal to the corresponding minimum QoT among all j Bids, that is, Indicates the Bid on the path Path j The QoT corresponding to the segment link. It should be noted that the QoT of a segment link is equal to the minimum value of the QoT of all nodes on the link. The number of hops of a path is equal to the number of Bids that constitute the path.

[0100] It should be noted that the user's customization of routing is not limited to attributes such as bandwidth, delay, packet loss and routing trust quality, but also includes many other different attributes, depending on user needs and network application scenarios. Therefore, the above formula for calculating transmission performance is only an example and does not constitute a limitation on the embodiments of the present invention.

[0101] Then, BR selects PPVal pathThe largest cross-domain path is used as a candidate routing path, and an auction result AuR is generated based on the path, and the AuR is sent to the IR in the source domain that responds to the customized cross-domain routing request. The AuR contains the auction message Auc, a set of Bids that constitute the candidate routing path (expressed as sBid), and the PPVal corresponding to the candidate routing path. path (denoted as maxPPval), so AuR is expressed as:

[0102] AuR={Auc,sBid,maxPPVal,SIG(Auc,sBid,maxPPVal)}.

[0103] Then, the router in the source domain that responds to the customized cross-domain routing request performs signature verification on the received auction result; selects a candidate routing path from the candidate routing paths corresponding to the verified auction results as the global optimal routing path; and notifies the border routers in the global optimal routing path to prepare to transmit data packets. Among them, selecting a candidate routing path from the candidate routing paths corresponding to the verified auction results as the global optimal routing path can be selecting a candidate routing path with the maximum path performance value, or selecting a candidate routing path with a larger path performance value and composed of more trusted BRs, which is both possible.

[0104] Specifically, when the IR in the source domain receives AuRs from all BRs that initiate the auction, it first performs signature verification on each AuR. If the signature verification fails, the corresponding AuR is discarded. Otherwise, the IR parses these AuRs and selects the AuR with the largest maxPPval (denoted as maxAuR) as the global optimal auction result (i.e., the global optimal routing path). Among them, the signature verification of AuR includes double verification of AuR.SIG and AuR.Auc.SIG. Then, the IR in the source domain sends maxAuR to the first BR on the selected global optimal routing path, notifying the BR that the routing result it submitted has been selected, and that its own committed routing path has been selected, and that subsequent data packets need to be transmitted according to the committed path and performance. After receiving maxAuR, the first BR in the global optimal routing path performs signature verification on maxAuR. If the signature verification fails, it is discarded. Otherwise, the BR parses the maxAuR and forwards it to the next BR in the global optimal routing path according to the path selected in the maxAuR until the maxAuR is forwarded to the destination domain. The purpose of doing so is to inform the BRs on the path that their own committed routing paths have been selected and that they will subsequently need to transmit data packets for the UE. These BRs will arrange corresponding network resources for cross-domain routing according to their commitments in the Bid to assist the UE in transmitting data packets in the future.

[0105] It can be understood that the IR in the source domain that responds to the customized cross-domain routing request acts as the center of information aggregation and decision-making, comprehensively evaluates the best paths submitted by each auction initiator, and selects the one with the best comprehensive performance from many candidate routing paths as the final routing path recommended to the user. Subsequently, the IR feeds back the result to the UE in a timely manner so that the UE can understand and confirm the selected path.

[0106] When the border routers in the global best routing path are ready to transmit data packets, the source domain user can use the global best routing path to transmit the data packet to the target domain. During the transmission process, the border routers in the global best routing path upload their credentials for participating in the data packet transmission to the blockchain, so that in the subsequent routing settlement phase, the actual transmission performance of the border routers participating in the data packet transmission can be determined through the credentials, so as to perform routing settlement. At this point, the true value of crowdsourcing routing is reflected: IR works closely with BRs participating in cross-domain routing in each domain to jointly provide strong guarantees for the safe and efficient transmission of data packets. They use their respective routing resources and advantages to collaboratively complete cross-domain routing tasks to ensure that data packets can reach their destinations accurately and quickly.

[0107] Specifically, after the source domain user receives the packet transmission notification from the IR, the UE sends a data packet (denoted as Packet) to the IR. After receiving the Packet, the IR forwards it to the first BR on the selected path. After receiving the Packet, the first BR packs the Packet into a "packaged packet" (denoted as WP) by adding some additional information. The purpose of this is to facilitate the calculation of the actual transmission performance of each domain in the subsequent routing settlement stage. Then, it sends the WP to the next BR on the selected path. The WP is as follows:

[0108] WP={aucID,PID,PLen,SIG(aucID,PID,PLen),Packet};

[0109] Among them, Packet is the data packet sent by UE; PID is the identifier of Packet, which is used to distinguish different data packets; PLen is the payload length of Packet recorded by BR. Here, PID and PLen are additional data added to WP to ensure that the first BR transmits the data packet with the promised path and performance. Each BR participating in data transmission must record these additional data, which is represented by PIf. It can be said that PIf is the evidence that the Packet is forwarded on the underlying router. For example, the PIf recorded by the first BR is as follows:

[0110] PIf={PID,PLen,PTS,SIG(PID,PLen,PTS)};

[0111] Among them, PTS indicates the timestamp corresponding to when the Packet is forwarded to the first BR. In addition, in order to protect the relevant information added to the original data packet (such as PID, PLen, PTS), the BR that constructs the WP can also sign the relevant information, that is, add SIG (PID, PLen, PTS) in PIf.

[0112] Since the actual performance of the paths promised by BRs in data transmission may be different from the performance they promised, it is necessary to measure the actual transmission performance of these promised paths. PIf contains parameters that can be used to calculate the actual transmission performance. Therefore, in addition to storing PIf as evidence of their participation in data transmission, BRs participating in data packet transmission will also construct a credential (expressed as Ticket) for participating in cross-domain routing by combining PIf and AuR. BRs participating in data packet transmission will upload the generated Ticket and its signature SIG(Ticket) to the blockchain for subsequent routing settlement. In the blockchain, each (Ticket, SIG(Ticket)) is considered a transaction. As long as the Ticket.AuR.SIG signature verification passes, it is considered a legal transaction.

[0113] The ticket is represented as:

[0114] Ticket = {AuR, PIf};

[0115] Where, AuR = {Auc, sBid, maxPPVal, SIG (Auc, sBid, maxPPVal)}, PIf = {PID, PLen, PTS, SIG (PID, PLen, PTS)}; AuR represents the auction result, PIf is the information recorded by the border router when participating in the data packet transmission, Auc represents the auction message, sBid is the set of bidding information of all border routers in the global optimal routing path; maxPPVal represents the path performance value of the global optimal routing path, SIG (·) is the signature function; PID is the unique identifier of the data packet, PLen is the payload length of the data packet, and PTS is the timestamp when the border router in the global optimal routing path receives the data packet.

[0116] Similarly, when the next BR receives WP, it first verifies the signature of WP. If the signature verification fails, it discards the WP. Otherwise, it parses WP, records PIf′ and generates WP' and the certificate. Then, it forwards WP' to the next BR until WP' is forwarded to the destination domain and the certificate is uploaded to the blockchain. WP' and PIf' are represented as follows:

[0117] WP'={aucID,PID,PLen',SIG(aucID,PID,PLen'),Packet};

[0118] PIf′={PID,PLen′,PTS′,SIG(PID,PLen′,PTS′)};

[0119] Here, PIf′ is the PIf re-recorded by the current BR, WP′ is the WP re-generated by the current BR, PTS′ is the timestamp when the current BR receives the Packet, and PLen′ is the payload length of the Packet recorded by the current BR.

[0120] Thus, the Packet is transmitted to the destination domain in the form of WP. When the BR in the destination domain receives the WP, it obtains the original data packet Packet from it and sends the Packet to the destination address in the destination domain. At this point, the transmission process of a data packet is completed. The transmission method of other data packets is the same as this, so it will not be repeated here.

[0121] In the embodiment of the present invention, the crowdsourcing routing stage closely inherits the achievements of the routing preparation stage, adopts an innovative crowdsourcing auction mechanism, and uses the unique advantages of distributed collaboration and task decomposition. By breaking down complex cross-domain routing tasks into multiple manageable subtasks, each network domain is invited to bid based on the routing performance (such as bandwidth, delay, packet loss rate, etc.) that it can provide, in order to respond to the specific customized needs of users. This can not only effectively reduce the burden of a single network domain, but also stimulate the potential for cooperation between networks, and realize the efficient construction and deployment of user-customized cross-domain routing. This process not only promotes deep cooperation and healthy competition between network domains, but also ensures that the final selected routing path can accurately meet user expectations through the natural screening of the market mechanism, achieving unprecedented routing customization accuracy, demonstrating the unique advantages of the crowdsourcing auction mechanism in routing selection, and providing new ideas and directions for the innovation and development of network technology.

[0122] In the embodiment of the present invention, users can make customized cross-domain routing requests during the crowdsourcing routing stage, and based on the self-created crowdsourcing auction technology, accurate control and optimization of routing paths can be achieved. This highly flexible customization capability will greatly improve user experience and meet the diverse needs of future network services.

[0123] When the data packet transmission of the source domain user is completed, the routing settlement phase can be entered. In the routing settlement phase, routing settlement is performed based on the transmission performance promised by the border routers participating in the data packet transmission, the expected service fee and their actual transmission performance.

[0124] Here, routing settlement is performed based on the transmission performance promised by the border routers participating in the data packet transmission, the expected service fee and their actual transmission performance, including: calculating the routing settlement factor based on the transmission performance promised by the border routers participating in the data packet transmission and the actual transmission performance; multiplying the routing settlement factor by the expected service fee to obtain the actual service fee payable. When the transmission performance promised by the border router is worse than the actual transmission performance, the routing settlement factor is less than 1, and when the transmission performance promised by the border router is better than the actual transmission performance, the routing settlement factor is greater than 1.

[0125] Specifically, based on the Tickets uploaded to the blockchain by all border routers participating in data packet transmission, the smart contract pre-deployed on the blockchain is run to perform routing settlement for each BR participating in data packet transmission. The specific settlement amount is affected by both the actual performance and the promised performance of the BR's promised path. For the actual performance of the BR's promised path, its actual delay, actual packet loss, and actual bandwidth can all be calculated based on the Ticket. The specific calculation process is as follows:

[0126] Select all PIfs with the same PID from Ticket s and sort them according to the order of BRs in the corresponding routing path in AuR to obtain {PIf1,PIf2,…,PIf l ,…}; For each Packet, select two neighbor BRs in the global optimal routing path (such as R l-1 and R l ) respectively extract two PIf (such as PIf l-1 and PIf l );Then use these two to calculate the transmission performance of the path between the two neighbor BRs. Among them, R l-1 YesR l The previous BR.

[0127] Specifically, PIf l .PTS-PIf l-1 .PTS is the data packet from R l-1 to R l The actual delay of this path; That is, the data packet from R l-1 to R l The actual bandwidth of this path; That is, the data packet from R l-1 to R lThen, using the calculation method of the path performance value given above, we can calculate the actual path performance value APPV of the global optimal routing path to transmit a data packet, and then calculate the path performance commitment value PPPV by combining the transmission performance promised by each BR in the global optimal routing path. For all data packets in a data packet transmission task, we can further calculate the average value AvaAPPV of APPV, then for R l For example, the domain in which it is located should be compensated for:

[0128]

[0129] in, Represents R l The expected service fee in the bid information. is the settlement factor. It can be seen from the calculation formula that when R l When the actual performance provided exceeds the promised performance, the routing settlement factor is greater than 1, and its network domain can obtain more benefits. l When the promised transmission performance is inferior to the actual transmission performance, the routing settlement factor is less than 1, R l The network domain receives a lower reward than it expected, which means it is punished. Since network domains want to pursue high profits, this reward design can motivate network domains to actively participate in cross-domain routing and provide good service quality.

[0130] In addition, for R l For example, it is related to R l-1 The actual performance of this path between l Therefore, in practice, there may be some l-1 The network scenario is poor, resulting in R l Therefore, after each routing settlement is completed, R l Trust evaluation based on domain behavior can be performed, so that for auctions in which network domains participate and cause losses to their own revenue, R l You can decide not to participate or increase the compensation for the statement to reduce the loss of being affected by it again in the future.

[0131] In the embodiment of the present invention, by introducing the routing settlement stage and performing routing settlement according to the transmission performance promised by the border routers participating in the data packet transmission, the expected service fee and the actual transmission performance, the network domain can be encouraged to actively participate in routing and optimize routing decisions, thereby achieving optimal configuration and efficient utilization of network resources. This not only helps to improve the overall network performance, but also promotes healthy competition and cooperation among operators to achieve a win-win situation.

[0132] In addition, in order to reduce network overhead, the embodiment of the present invention also supplements the design of a random sampling scheme for PIf. Specifically, when constructing WP, BR adds a flag bit (represented as Flag) in WP to mark whether the previously transmitted WP is used as a reference for the actual preference performance value in the routing settlement phase, that is, to identify whether the PIf corresponding to the WP needs to be added to the Ticket for calculating the remuneration in the settlement phase. Flag determines whether the previous WP participates in the settlement phase instead of the current WP, which can ensure the fairness of routing settlement. Flag is set to true or false by the BR that constructs the WP. Only when Flag is true, the PIf corresponding to the WP is added to the Ticket for calculating the remuneration in the settlement phase. This method can greatly reduce the number of PIfs, thereby reducing storage and network overhead. Specifically, the WP after adding Flag is as follows:

[0133] WP={aucID,PID,Flag,PLen,SIG(aucID,PID,Flag,PLen),Packet}.

[0134] In practice, there is a fierce competition between network operators (NOs). Existing cross-domain routing solutions generally ignore the potential malicious behavior of network operators, which poses a serious threat to the fairness of cross-domain routing and user experience. In the fierce market competition environment, operators may provide misleading information in the cross-domain routing process for their own interests, which may not only cause the routing to be maliciously tampered or destroyed, damage the overall quality of the routing and the trust of users, but also trigger a chain reaction, causing serious negative impacts on the entire network ecosystem. The trustless environment of Inte-HetNet has exacerbated the distrust between network domains, making it possible for operators to take improper means for their own interests. Therefore, it is necessary to strengthen the monitoring and prevention of malicious operator behavior and establish a sound response mechanism to maintain the security and stability of routing.

[0135] In the above scheme, some NOs may take unfair measures for their own selfish interests, such as deliberately spreading false topology or network routing information, in an attempt to mislead UEs and obtain improper benefits. According to the established routing settlement mechanism, UEs need to pay corresponding fees for each network domain involved in the cross-domain routing process. However, the actual situation is that if the information provided by the NO is false, the routing attempt will fail, making it impossible for these malicious NOs to collect the promised service fees from the UE. Unfortunately, in order to attract more UEs and grab additional profits, malicious NOs may adopt deceptive strategies, claiming to provide high-quality services at prices far below market standards, as bait to induce UEs to choose their services. Once the UE is deceived, these NOs can easily obtain improper benefits, but this move is likely to cause a complete collapse of cross-domain routing, seriously damaging the stability and reliability of the entire system.

[0136] In view of the above potential risks, certain measures can be taken in the embodiments of the present invention to prevent malicious behavior of NO. Specifically, by setting a supervisory party in the Inte-HetNet, the supervisory party requests services from any network domain at a price lower than the service fee reference standard; if a network domain accepts the request, it is determined that the network domain has untrustworthy behavior, that is, the network domain lures the supervisory party to initiate a request to it at a low price, so NO can be punished at this time. Among them, the service fee reference standard can refer to the service fee setting settled in the historical cross-domain routing; in practice, the supervisory party can be a specially designed simulated user or an arbitrary user. It is understandable that users can report malicious participants with unreliability without compensation, so the supervisory party can be an ordinary user.

[0137] The above measures are actually designed to be a game to prevent NO from providing false network routing information to lure UE. The principle of the game is described as follows:

[0138] There are two behaviors for NO: a. Honesty, that is, NO provides real network resource information and honestly follows the protocol; b. Inducing UE, that is, NO induces users to obtain better services from itself at a low price to obtain more benefits.

[0139] For UE, there are also two behaviors: a. Being honest, that is, not accepting any inducement from OA; b. Being tempted by NO, that is, accepting NO's so-called services that can be enjoyed at a low cost.

[0140] Assume that β represents the probability that NO encounters the supervisory party when receiving the low-cost routing request from UE (i.e., luring UE). When NO does not lure UE, the conditional probability of encountering the supervisory party is 0. Value represents the value brought to UE by implementing the routing request, and Reward represents the fee that UE should pay to NO for honestly participating in cross-domain routing. Reward *(<Reward) indicates that the user is tempted to pay a low price to the malicious NO. P represents the punishment for the malicious behavior of NO. The payoff situations of NO and UE in the game are as Figure 4 shown, and there are specifically the following four situations:

[0141] Situation 1: When NO is honest, which means it does not deceive UE, at this time P = 0. If UE is also honest, the payoffs of NO and UE are Reward and Value - Reward respectively.

[0142] Situation 2: When NO is honest and UE is dishonest, UE may be the supervisor or a routing requester who is easily deceived by NO. Due to the honesty of NO, it refuses to accept the low - price routing request from UE. Therefore, in this case, they can only execute according to the protocol. Thus, the payoff of NO is βReward+(1 - β)Reward = Reward; the payoff of UE is β(Value - Reward)+(1 - β)(Value - Reward)=Value - Reward. The payoffs in this situation are the same as those in Situation 1.

[0143] Situation 3: When NO is malicious and it tries to provide false information to lure UE at a low price. At this time, if UE is the supervisor, NO will be punished. In this case, the payoffs of NO and UE are -P and 0 respectively.

[0144] Situation 4: When NO is malicious and UE is also malicious and hopes to obtain good services at a low price. At this time, the payoff of NO is β(-P)+(1 - β)Reward * =-βP + Reward * -βReward * , and the payoff of UE is (1 - β)(-Reward * ) = βReward * -Reward * .

[0145] Based on the above four situations, it can be seen that when Reward > -βP + Reward * -βReward * , that is , no matter whether UE is honest or not, NO is willing to choose honesty. At this time, for NO, honesty is a dominant strategy. At this time, there are two Nash equilibrium points, namely (honest; honest) and (honest; low - price request). When Reward < -βP + Reward * -βReward * , that is When , we can find that (honesty; honesty) and (inducement; low-price request) are also two Nash equilibrium points. In summary, no matter what the situation is, (honesty, honesty) is a Nash equilibrium point.

[0146] In order to analyze the role of the supervisor, we further analyzed To facilitate analysis, set the function And assume that P = kReward (k ≥ 1), where k represents the penalty coefficient. Then, after substituting P, Take F(Reward * ,k) relative to Reward * The partial derivatives of are as follows:

[0147]

[0148] Here, we can observe that F(Reward * ,k) With Reward * This indicates that the function F is an increasing function, argmax(F(Reward * ,k))=F(Reward,k). According to the above expression, we can know that when , honesty is a strategy that favors NO. To keep NO honest, we only need β>argmax(F(Reward * ,k)), that is:

[0149]

[0150] It can be observed that only when β>0, whether the UE wants to be tempted by NO or intends to enjoy the so-called high service at a very low price, NO will refuse to provide false routing information to the UE. This also means that as long as there is no less than one supervisor or the punishment is increased, (temptation; low-price request) will not occur, that is, NO will not choose malicious behavior.

[0151] In the embodiments of the present invention, on the basis of ensuring the continuous reliability, fine-grained customization and reasonable allocation of resources of cross-domain routing, great importance is attached to the prevention and containment of malicious behaviors of operators. By designing a game between users and network operators, an effective mechanism is constructed to prevent and suppress malicious behaviors of network operators, ensure the fairness of cross-domain routing and user experience, effectively contain potential malicious behaviors, ensure the purity and security of the network environment, and ensure that network operators involved in routing decisions follow the principles of honesty and fairness and do not take malicious behaviors that harm user interests or system stability.

[0152] The following is a more detailed description of the embodiment of the present invention by using a specific example. Figure 5(a) to Figure 5(f)As shown, user UE1 is connected to an internal router (ie, R1) in network domain A, and UE1 wants to communicate with user UE2 in network domain C. The specific steps are as follows:

[0153] Step 1: As shown in Figure 5(a), the source domain user generates a cross-domain routing request and forwards the request:

[0154] 1) UE1 generates a customized cross-domain routing request RR1 according to its network application scenario and its routing preference:

[0155] RR1={Src,Dest,Pref,Dura,Load}1

[0156] Pref1={(At1,th1,wt1),…,(At n ,th n ,wt n )}1;

[0157] 2) After generating RR1, UE1 sends RR1 to the internal router R1.

[0158] 3) Then, R1 selects a suitable BR in the same domain (e.g. Figure 3 R2, R3, R4) in the packet and forward RR1 to them.

[0159] Next, the subsequent steps are described in detail by taking the auction initiated by the border router R4 as an example. The processes of R2 and R3 are similar.

[0160] Step 2: As shown in Figure 5(b), the border router starts the route auction and forwards the auction information;

[0161] 1) When R4 receives RR1 from R1, it means that R1 notifies R4 to start a customized cross-domain routing auction.

[0162] 2) R4 initiates a "cross-domain routing auction" in response to UE1's routing request. Specifically, R4 first generates an auction message And set a timer to record the life cycle of the auction, and then Will Sent to the BR of the next domain (ie R5). as follows:

[0163]

[0164] in, Indicates the ID corresponding to the auction initiated by R4; Representation structure The ID corresponding to R4; express The expiry time of Represents a list of network domain IDs that are allowed to participate in the auction. The list of IDs contains the IDs of network domains that are selected by R4 based on the domain information of each network domain and that are responsible for future cross-domain data packet transmission; RR1 represents the cross-domain routing request proposed by UE1; The signature of the above five items is completed by R4 to ensure the integrity and non-repudiation of RR1 during transmission; Refers to a list containing BR addresses, which contains The path traversed (at the border router level). The list initially contains two elements, namely The address of the BR (ie R4) and the The address to be sent to the next BR (i.e. R5), so

[0165] 3) Received at R5 After that, R5 is the entrance BR. After that, it first parses It will decide whether to participate in the route auction based on the policy of its network domain. If it does not participate, it will discard Otherwise, it will save RR1, and perform the following operations:

[0166] Since RR1.Dest is not in the current network domain, this means that the current network domain needs to Continue forwarding to the next domain. To this end, R5 needs to select some inter-domain links as outbound links and add the start router address (i.e., R7) and end router address (i.e., R8) of these outbound links to to form a new BRL (i.e. ), and finally obtain the new Auc (i.e. ). Then, R5 continues to Forward to the next BR in the current domain (ie, R7). for:

[0167]

[0168] After R5 decides to participate in the auction, in order to make subsequent bids, it needs to provide the domain entry link into R5 and the link between R5 and the domain exit BR (i.e., R7) (i.e., ) to provide performance guarantee. Then, R5 will The corresponding router address information and the performance guarantee for the link are added to the Bid generated in step 3.

[0169] When received from R5 Since R7 is the export BR, it only needs to In Will Forward to the next BR (i.e. R8 in the destination domain). As can be seen from Figure 5(b), RR1.Dest is located in the current network domain, and R8 does not need to select an outbound link. Just add two empty addresses at the end to prove that there is no outbound link.

[0170] Step 3: See Figure 5(c), BR generates and forwards Bid:

[0171] 1) When all Aucs (i.e. and ) are forwarded to R8 in the destination domain, all the ingress BRs participating in the auction begin to generate their bid information one after another, and forward their generated Bids to the BR that initiated the corresponding auction in the opposite direction of Auc transmission. When it is forwarded to R8 in the destination domain, R8 generates its bid information about the auction initiated by R4 (i.e. ), and Sent to R7. Specifically, This means that R8 will be a committed link (i.e. ) added to middle. It is expressed as follows:

[0172]

[0173] in, It is the ID corresponding to this auction; It is a structure The ID of R8; is the service fee expected by R8 for participating in cross-domain data transfer; Indicates the link performance promised by R8. Here, Each item in corresponds to each item in UE1 preference requirement Pref1 one by one. Represents R8 for each attribute At i The promised performance should be better than the threshold of the corresponding attribute in Pref1, that is, In addition, all ingress BRs participating in the auction must meet the threshold requirements of UE1 for related attributes. Otherwise, the links they promise may be discarded because they cannot meet UE1's requirements. Because RR1.Dest belongs to the current domain, is a list containing only the first two addresses, i.e. Represents the signature of the above five items, which is completed by R8 to ensure Integrity and non-repudiation during transmission.

[0174] 2) When R7 receives Since R7 is an egress BR, it only needs to forward No bid is required. Then, R7 will Forwarded to the BR (ie R5) to which the auction message was previously sent.

[0175] 3) When R5 receives , since R5 is an entry BR, it needs to bid. Specifically, R5 first checks Whether the corresponding auction was initiated by itself. If so, and the auction has not expired, storage for future path selection. Otherwise, it checks whether it has already decided to participate in Corresponding routing auction. If participating, R5 generates its own bidding information Then, R5 sends its bid information With received The auction message is forwarded to the previous BR (ie R4) to which the auction message was sent. This means that R5 will be a committed link (i.e. ) added to middle. It is expressed as follows:

[0176]

[0177] Among them, because RR1.Dest does not belong to the current domain, is a list of four addresses, namely

[0178] 4) All BRs participating in the auction forward the Bid in the opposite direction of the Auc transmission to the BR that initiated the auction. In this way, the auction initiator R4 can eventually receive all the Bids sent by the BRs participating in the auction, and R2 and R3 can also obtain all the Bids in their respective auctions in this way.

[0179] Step 4: See Figure 5(d) to obtain the auction results

[0180] 1) When the auction expires, the initiators of the auction (i.e., R2, R3, and R4) try to form some cross-domain paths based on all the received Bids messages. They first need to determine whether the promised performance of all received Bids meets the requirements of UE1, and delete those Bids that do not meet the requirements. Then, they select those Bids that can be connected forward and backward to form a cross-domain routing path, and form these Bids into a list bidList. For R4,

[0181] 2) Based on the AuR generation method, R2, R3, and R4 can generate their own auction results and send them to R1. For R4, only one path is shown in the figure (i.e., R4→R5→R7→R8), so the result of the routing auction initiated by R4 is For R3, there are two paths in the graph (i.e., R3→R 15 →R8 and R3→R8). Assume that R3 calculates the path with the maximum PPVal as R3→R 15 →R8. Therefore, the result of the route auction initiated by R3 is Still taking the auction initiated by R4 as an example, It is expressed as follows:

[0182]

[0183] Here, since the routing auction initiated by R4 has only one auction result, sBid is are the same, both

[0184] Step 5: See Figure 5(e), auction result confirmation

[0185] 1) After receiving all AuRs from R2, R3, and R4, R1 first verifies the signature of each AuR. If the signature verification fails, the corresponding AuR is discarded. Otherwise, R1 parses these AuRs and selects the path corresponding to the AuR with the largest PPVal as the global optimal path. Assume that the AuR corresponding to the global optimal path finally selected by R1 is

[0186] 2) R1 sends R4 is notified of the auction result it submitted. R1 also notifies UE1 to start data packet transmission.

[0187] 3) Receive R4 pair Perform signature verification. If the signature fails, discard it. Otherwise, R4 parses And follow The selected path forwards it to R5.

[0188] 4) Receive R5 Pair Perform signature verification. If the signature verification fails, discard it. Otherwise, R5 parses And follow The selected path forwards it to R7.

[0189] 5) R7 continues to verify the signature and forwards it until is forwarded to R8.

[0190] At this point, all BRs on the path (such as R4, R5, R7, and R8) know that they have been selected as the next hop for inter-domain routing. They will arrange corresponding network resources for inter-domain routing according to the paths and performances promised in their Bids to assist UE1 in transmitting data packets.

[0191] Step 6: See Figure 5(f), user data packet transmission

[0192] 1) After receiving the notification from R1, UE1 starts to send data packets (denoted as Packet1) to R1.

[0193] 2) After receiving Packet1 from UE1, R1 forwards Packet1 to R4.

[0194] 3) After receiving Packet1 from R1, R4 adds PID and Package it into a "package" (denoted as ), the purpose of which is to facilitate the calculation of the actual transmission performance of each domain in the subsequent routing settlement phase. Then, it will Send to R5. It is expressed as follows:

[0195]

[0196] Packet1 is the original data packet sent by UE1; PID and is added to Additional data to ensure that R4 transmits the data packet with the promised path and performance. PID represents the identifier of Packet1 sent by UE1, which is used to distinguish different data packets; Indicates the payload length of Packet 1 recorded by R4; for each Packet, each BR participating in data transmission must record this additional data, and define this record as PIf. PIf is the evidence that the Packet is forwarded on the underlying router. For example, R4 records as follows:

[0197]

[0198] in, Indicates the timestamp corresponding to when Packet1 is forwarded to R4. In order to protect the relevant information added to the original data packet (such as PID, ),structure R4 needs to sign the relevant information of the data packet.

[0199] 4) Receive After that, R5 first Perform signature verification. If the signature fails, it will be discarded. Otherwise, it parses Record and generate Then, it will Forward to R7. and It is expressed as:

[0200]

[0201] 5) Receive After that, R7 first Perform signature verification. If the signature fails, it will be discarded. Otherwise, it parses Record and generate Then, it will Forwarded to R8.

[0202] 6) R8 received After that, it will Unpack it into Packet1 and pass it through R 11 Send Packet1 to destination UE2.

[0203] 7) Following the above steps, the transmission process of Packet1 is completed. The transmission method of other data packets is the same.

[0204] In summary, the embodiment of the present invention innovatively proposes the first trusted customized cross-domain routing solution that integrates the concept of crowdsourcing. This solution profoundly reshapes the boundaries of the traditional routing mechanism and achieves the wide distribution and efficient coordination of routing responsibility through the clever use of crowdsourcing technology. The core concept of the embodiment of the present invention is to disperse the decision-making power and execution power of cross-domain routing to multiple network domains, and use auction and competition mechanisms to accurately match and build the cross-domain routing path that best meets user expectations.

[0205] Compared with the prior art, the embodiments of the present invention at least solve the following major problems existing in the existing cross-domain routing solutions:

[0206] Question 1: How to build and consolidate the continuous credibility of cross-domain routing in heterogeneous converged networks?

[0207] The embodiments of the present invention use blockchain to remotely authenticate routing devices, embed trust conditions in routing devices, and introduce encrypted transmission in the routing process to build a routing path that is trusted by users from the source to the end point. This can effectively ensure the continuous credibility of routing and the integrity and security of routing information, thereby laying a solid trust foundation for cross-domain routing, ensuring that in a heterogeneous converged network, each link of cross-domain routing can maintain a high degree of reliability and credibility, thereby safeguarding the data security of users.

[0208] Question 2: How to achieve fine-grained customized routing to accurately match users’ diverse needs?

[0209] In response to users' growing diversified routing needs in terms of different key network indicators such as bandwidth, latency, and packet loss rate, the present invention innovatively proposes a fine-grained customized routing strategy and provides a highly customized routing solution. Through in-depth analysis of user preferences, QoS (quality of service) requirements, and network status, a customized cross-domain routing solution is proposed based on crowdsourcing auction technology to achieve precise control and optimization of routing paths. This highly flexible customization capability ensures that every cross-domain communication can meet the high-quality network service standards expected by users, which will greatly improve the user experience and meet the diverse needs of future network services.

[0210] Question 3: How to stimulate the vitality of network domains and promote cross-domain collaboration and rational allocation of resources?

[0211] In order to motivate network domains to actively participate in cross-domain routing collaboration, the embodiment of the present invention designs a scientific incentive mechanism. This mechanism encourages network domains to actively participate in routing and optimize routing decisions by introducing crowdsourcing incentives, routing settlement incentives and other means, thereby achieving optimal configuration and efficient utilization of network resources. This can not only effectively integrate and allocate network resources to accurately match the diverse needs of users, help improve overall network performance, but also promote healthy competition and cooperation among operators, promote the rational flow and efficient use of resources, achieve a win-win situation, and open up a new way for network operators to increase revenue.

[0212] Question 4: How to build a comprehensive defense system to effectively curb malicious behavior of operators?

[0213] On the basis of ensuring the continuous trustworthiness, fine-grained customization and reasonable allocation of resources for cross-domain routing, the embodiments of the present invention also attach great importance to the prevention and containment of malicious behaviors of operators. By introducing a supervisory party and designing a game between users and network operators, potential malicious behaviors can be effectively contained, and operators are encouraged to maintain trustworthy behaviors in the cross-domain routing process, share real and accurate routing information, enhance the self-purification ability of the entire network, ensure the purity and security of the network environment, and thus provide users with stable and reliable services.

[0214] The trusted customized cross-domain routing solution proposed in the embodiment of the present invention has a wide range of application scenarios and can significantly improve the flexibility, security and efficiency of network routing. The following are several specific application cases or examples:

[0215] 1. Multinational corporate network interconnection

[0216] Application example: A multinational company has branches in multiple regions around the world and needs to achieve global network interconnection efficiently and securely. Using the method of the embodiment of the present invention, the company can customize the selection of the optimal cross-domain routing path based on the network conditions, policy restrictions and cost considerations in different regions. Through the crowdsourcing auction mechanism, multiple network service providers are encouraged to participate in the bidding and provide diversified routing options. At the same time, blockchain technology ensures the continuous credibility of the path and protects the security of enterprise data transmission.

[0217] 2. Cloud computing and data center interconnection

[0218] Application example: In a cloud computing environment, efficient and reliable data transmission is required between multiple data centers to meet users' real-time service needs. The embodiments of the present invention allow cloud service providers to dynamically adjust the routing strategy between data centers based on data traffic, latency requirements and cost budgets. Through the crowdsourcing incentive mechanism, more network operators are encouraged to participate, provide diversified routing solutions, and optimize data transmission paths. At the same time, blockchain technology ensures the security and credibility of data transmission.

[0219] 3. Internet of Things (IoT) device cross-domain communication

[0220] Application example: In smart cities or industrial IoT scenarios, a large number of IoT devices require cross-domain communication to achieve data sharing and transmission of control instructions. The embodiments of the present invention can provide flexible and secure cross-domain routing solutions for these devices, support fine-grained routing customization, and meet the specific needs of different devices. At the same time, by introducing the "supervisory party" strategy, it can effectively prevent potential malicious behaviors of network operators and ensure the safe and stable operation of the IoT network.

[0221] 4. Sharing of scientific research and education network resources

[0222] Application example: In the field of scientific research and education, universities and research institutions need to frequently exchange a large amount of scientific research data and teaching resources. The embodiment of the present invention can be applied to build an efficient and reliable scientific research and education network resource sharing platform. Through the crowdsourcing auction mechanism, the optimal configuration of network resources is achieved and the sharing cost is reduced. Blockchain technology ensures the immutability and traceability of data transmission, and protects the security of intellectual property rights and sensitive data.

[0223] 5. Cross-border e-commerce logistics tracking

[0224] Application example: Cross-border e-commerce business involves cross-border logistics tracking, which requires real-time and accurate knowledge of the transportation status of packages. The embodiments of the present invention can be applied to cross-domain routing optimization of logistics tracking systems, and through customized routing strategies, ensure the rapid and secure transmission of logistics information around the world. At the same time, blockchain technology enhances the reliability and transparency of data transmission, providing merchants and consumers with more reliable logistics tracking services.

[0225] The above application examples demonstrate the wide application potential of the embodiments of the present invention in multiple fields. By integrating crowdsourcing concepts, blockchain technology, crowdsourcing auction mechanisms and incentive mechanisms, they bring unprecedented flexibility and security to cross-domain routing.

[0226] The above contents are further detailed descriptions of the present invention in combination with specific preferred embodiments, and it cannot be determined that the specific implementation of the present invention is limited to these descriptions. For ordinary technicians in the technical field to which the present invention belongs, several simple deductions or substitutions can be made without departing from the concept of the present invention, which should be regarded as falling within the protection scope of the present invention.

Claims

1. A crowdsourcing-based trusted customized cross-domain routing method, characterized in that: include: Routing preparation phase, crowdsourcing routing phase and routing settlement phase; In the routing preparation phase, a global trusted network topology is constructed based on trusted path routing technology, trust insurance mechanism and blockchain technology; In the crowdsourcing routing stage, in response to a customized cross-domain routing request initiated by a source domain user, the border routers in each network domain compete for the right to undertake cross-domain routing by participating in an auction according to the global trusted network topology, and transmit the bidding information back to the source domain; the routers in the source domain determine the auction result according to the bidding information to determine the global optimal routing path, so that the source domain user uses the global optimal routing path to transmit the data packet to the target domain; wherein the bidding information includes the transmission link and transmission performance promised by the border router, and also includes the service fee expected by the border router; In the routing settlement phase, routing settlement is performed based on the transmission performance promised by the border routers participating in the data packet transmission, the expected service fee and their actual transmission performance.

2. The crowdsourcing-based trusted customized cross-domain routing method according to claim 1 is characterized in that: The global trusted network topology is constructed based on the trusted path routing technology, trust insurance mechanism and blockchain technology, including: In the same network domain, border routers and internal routers use trusted path routing technology to verify each other's identity and status to establish a trusted topology within the domain; Configure the trusted platform module TPM for the border router, embed the consensus trust conditions into the root trust module RTM of TPM through the blockchain, and use the trust insurance mechanism to establish a continuous trust relationship between the blockchain and the border router, so that the border routers that establish a continuous trust relationship with the blockchain can trust each other and realize the establishment of a trusted topology between domains.

3. The crowdsourcing-based trusted customized cross-domain routing method according to claim 1 is characterized in that: The customized cross-domain routing request is expressed as: RR={Src,Dest,Pref,Dura,Load}; Wherein, Src represents the source address of the customized cross-domain routing request; Dest represents the destination address of the customized cross-domain routing request; Pref = {(At1, th1, wt1), ..., (At n ,th n ,wt n )} is the routing preference vector of the source domain user; At i (i=1,2,…,n) represents the i-th routing attribute that the customized cross-domain routing request wants to customize. i (i=1,2,…,n) represents the user's i The minimum requirement or acceptable range of wt i (i=1,2,…,n) represents At i The corresponding weight; Duration represents the duration for which the customized cross-domain routing request remains valid; Load represents the effective load of the customized cross-domain routing request.

4. The crowdsourcing-based trusted customized cross-domain routing method according to claim 1, characterized in that: In response to a customized cross-domain routing request initiated by a source domain user, the border routers in each network domain compete for the right to undertake cross-domain routing by participating in an auction according to the global trusted network topology, and transmit the bidding information back to the source domain, including: In response to a source domain user initiating a customized cross-domain routing request to a router in the source domain, the router broadcasts the customized cross-domain routing request to all adjacent border routers in the source domain; The border router in the source domain that receives the customized cross-domain routing request initiates an auction according to the global trusted network topology and sends the auction message to the outside of the domain; The ingress border router that receives the auction message decides whether to participate in the auction; if it decides not to participate in the auction, it discards the auction message; if it decides to participate in the auction, it regenerates the auction message based on the auction message and the global trusted network topology, sends the auction message to the border router to which it is connected, and transmits the bidding information back along the original path to the border router that initiated the auction in the source domain; the egress border router that receives the auction message forwards the auction message to the border router to which it is connected; Among them, for any network domain, the border router responsible for receiving the auction message when the auction message enters the network domain is the entry border router, and the border router responsible for sending the auction message outside the domain when the auction message leaves the network domain is the exit border router.

5. The crowdsourcing-based trusted customized cross-domain routing method according to claim 4 is characterized in that: The auction message is represented as: Auc={aucID,ID,ET,Idil,RR,SIG(aucID,ID,ET,Idil,RR),BRL}; Wherein, aucID is the auction identifier, ID is the unique identifier of the border router initiating the auction, ET is the expiration time of the auction message, Idil is the list of network domains allowed to participate in the auction, RR represents the customized cross-domain routing request, SIG(·) is the signature function, and BRL is a list consisting of the addresses of each border router in the transmission path through which the auction message passes.

6. The crowdsourcing-based trusted customized cross-domain routing method according to claim 4, characterized in that: The bidding information is represented as: Bid={aucID,BID,Price,Properf,BBRL, SIG(aucID,BID,Price,Properf,BBRL)}; Wherein, aucID is the auction identifier corresponding to the bid information, BID is the unique identifier of the border router that generates the bid information; Price is the expected service fee, Properf is the transmission performance promised by the border router that generates the bid information; BBRL is an address list, which records the addresses of the start router and the end router in the link that the auction message received by the border router passes through before entering the current network domain, and also records the addresses of the start router and the end router in the link that the auction message regenerated by the border router needs to pass through before leaving the current network domain; SIG(·) is the signature function.

7. The crowdsourcing-based trusted customized cross-domain routing method according to claim 4, characterized in that: The router in the source domain determines an auction result according to the bidding information to determine a global optimal routing path, so that the source domain user transmits a data packet to the target domain using the global optimal routing path, including: The border router initiating the auction in the source domain deletes the bid information that does not meet the transmission performance requirements in the customized cross-domain routing request; determines multiple cross-domain paths that can lead from the source domain to the target domain based on the remaining bid information; calculates the path performance value of each cross-domain path based on the bid information corresponding to the cross-domain path; selects the cross-domain path with the largest path performance value as a candidate routing path; generates an auction result based on the candidate routing path, and sends the auction result to the router in the source domain that responds to the customized cross-domain routing request; The router in the source domain that responds to the customized cross-domain routing request performs signature verification on the received auction result; selects a candidate routing path from the candidate routing paths corresponding to the verified auction results as the global optimal routing path; and notifies the border routers in the global optimal routing path to prepare to transmit data packets; The source domain user uses the global optimal routing path to transmit the data packet to the target domain. During the transmission process, the border router in the global optimal routing path uploads its certificate of participating in the data packet transmission to the blockchain, so that in the routing stage, the actual transmission performance of the border router participating in the data packet transmission can be determined through the certificate.

8. The crowdsourcing-based trusted customized cross-domain routing method according to claim 7, characterized in that: The credentials are represented by: Ticket = {AuR, PIf}; Wherein, AuR={Auc,sBid,maxPPVal,SIG(Auc,sBid,maxPPVal)}, PIf={PID,PLen,PTS,SIG(PID,PLen,PTS)}; AuR represents the auction result, PIf is the information recorded by the border router in the global optimal routing path when participating in the data packet transmission, Auc represents the auction message, sBid is a set of bidding information of all border routers in the global optimal routing path; maxPPVal represents the path performance value of the global optimal routing path, SIG(·) is a signature function; PID is the unique identifier of the data packet, PLen is the payload length of the data packet, and PTS is the timestamp when the border router in the global optimal routing path receives the data packet.

9. The crowdsourcing-based trusted customized cross-domain routing method according to claim 1, characterized in that: Routing settlement is performed based on the transmission performance promised by the border routers involved in data packet transmission, the expected service fee and their actual transmission performance, including: Calculate the routing settlement factor based on the transmission performance promised by the border routers involved in data packet transmission and the actual transmission performance; multiply the routing settlement factor by the expected service fee to obtain the actual service fee payable; When the transmission performance promised by the border router is worse than the actual transmission performance, the routing settlement factor is less than 1; when the transmission performance promised by the border router is better than the actual transmission performance, the routing settlement factor is greater than 1.

10. The crowdsourcing-based trusted customized cross-domain routing method according to claim 1, characterized in that: The method further comprises: Setting up a supervisory party; Requesting services from any network domain at a price lower than the reference standard of service fees through the supervisory party; if a network domain accepts the request, determining that the network domain has untrustworthy behavior; Among them, the service fee reference standard refers to the service fee setting settled in the historical cross-domain routing; the supervisory party is a specially designed simulated user or an arbitrary user.

Images