A method and system for secure announcement of cross-domain computing power routing information based on BGP

Abstract

The application is a kind of method and system for BGP-based cross-domain computing power routing information security notification, relating to the technical field of communication network and network security. A source domain controller generates an interval configuration and performs intra-domain issuance and cross-domain distribution. When a signature device receives a continuous computing power index value CMetric, it determines whether to update TT and its signature by judging the interval identifier BucketID corresponding to CMetric. TT and the signature are encapsulated as a new path attribute of BGP UPDATE and sent to the entry device of the destination domain; the entry device analyzes the path attribute and further determines in combination with the local cache, and when the determination is passed, the computing power notification is used for routing strategy, computing power scheduling or service selection decision. The application reduces the frequency of repeated signature verification / re-signing, relieves computing pressure and improves scalability.

Description

Technical Field

[0001] This invention relates to the fields of communication networks and network security technology, and particularly to source authentication and integrity protection technology for computing power / resource information in the inter-domain routing control plane of the Internet. Specifically, it relates to a method and system for carrying continuous resource indicators and their interval identifiers in the path attributes of the UPDATE message of the Border Gateway Protocol (BGP), and combining digital signatures and trust stamps to realize interval-level verifiable announcements. Background Technology

[0002] In the IETF CATS working group's documents on computing networks, it is necessary to make decisions based on network metrics and computing power in order to select the appropriate service access point among multiple service sites / instances; therefore, collecting and distributing computing power and service status information in the relevant control plane becomes one of the basic capabilities of the above mechanism.

[0003] In this context, to provide cryptographic-level source authentication and integrity protection for cross-domain computing power route announcements, a direct implementation is to sign each BGP UPDATE carrying computing power information and verify them one by one on the receiving side. However, in route refresh scenarios triggered by route policy adjustments (RFC 2918, RFC 7313), BGP has a mechanism that prompts peers to resend their previously announced route updates through route refresh. When the route scale is large or the updates are frequent, verifying each message individually can significantly increase the control plane processing load and adversely affect the processing latency of critical protocol events. At the same time, the computational overhead of signing / verifying each message is usually linearly related to the number of UPDATEs. To control peak overhead, engineering implementations may need to limit the update frequency by extending the announcement interval, reducing the index resolution, or introducing stronger suppression strategies, which to some extent affects the real-time performance and granularity of computing power scheduling.

[0004] While existing inter-domain routing security mechanisms can improve security in some dimensions, they still have adaptability issues for scalable protection of high-frequency dynamic computing power metrics in the routing control plane. For example, the RPKI mechanism is mainly used to verify the authorization relationship of IP address holders initiating prefix route advertisements to a certain Autonomous System (AS). Its focus is biased towards the relatively static prefix-origin AS authorization, rather than resource metrics that change rapidly over time.

[0005] BGPsec (RFC 8205) provides cryptographic verifiability for AS paths during updates by carrying digital signatures generated by each AS in optional path attributes. However, its standard objectives primarily revolve around path authorization and path integrity. For new extended attributes such as computing power information, the scope of protection and overhead control methods typically still require design considerations based on the specific bearer and signature object. Furthermore, there are design ideas in industry and research that externalize / offload signature generation and verification to dedicated verifiers (such as xBGPsec). However, in per-update verification mode, the coupling of verification requests and update events can still lead to concentrated processing pressure during burst windows.

[0006] Therefore, how to reduce the coupling between integrity protection overhead and announcement triggering frequency while satisfying cross-domain verifiability, and maintain control plane availability in scenarios of route update oscillations or sudden traffic caused by route refresh, policy adjustment, etc., has become a key technical problem that computing power route announcement security mechanism needs to solve. Summary of the Invention

[0007] This invention addresses the scalability issue arising from the introduction of interval-level integrity protection when announcing cross-domain computing power information in the inter-domain routing control plane. It proposes a method and system for securely announcing cross-domain computing power routing information based on BGP. Under the premise of satisfying cross-domain verifiability, it reduces the coupling relationship between the overhead of computing power information integrity protection and the announcement triggering frequency, and improves the availability and scalability of the control plane under dense update windows.

[0008] The method for security announcement of cross-domain computing power routing information based on BGP includes the following specific steps:

[0009] 1. Interval configuration and distribution.

[0010] The destination AS domain acquires or maintains the grid profile of the source AS domain for mapping continuous computing power metrics to intervals, and generates a configuration summary identifier for referencing this grid profile in the control plane. The grid profile can be obtained through pre-configuration, distribution via management / control channels, or other predefined configuration synchronization mechanisms. The {ProviderAS, GridProfileID, ProfileVersion} triple is used for indexing on the receiving side.

[0011] II. Computing Power Routing Information Security Notification Process

[0012] Step 1: Generation and signing of continuous indicator interval verification objects:

[0013] The Metric Agent deployed on the computing power nodes / service instances within the source domain periodically acquires continuous computing power metric values ​​(CMetric). Based on the interval configuration GridProfile, CMetric is interval-based to obtain the interval identifier (BucketID) corresponding to CMetric. A trust token (TT) is generated based on the BucketID and context such as time, sequence, and prefix, and a digital signature is generated for the trust token. The signature update trigger condition is related to changes in the BucketID. Specifically: when the BucketID does not change, it is not necessary to regenerate a new signature object; when a cross-interval event causes a change in the BucketID, the sequence / time related fields are updated and a new TT and signature are generated.

[0014] Step 2, BGP path attribute encapsulation and announcement: The service / instance identity, continuous value CMetric, TT, and signature are encapsulated into new path attributes of BGP UPDATE and sent to the destination AS through the egress device of the source AS for announcement.

[0015] Step 3, Destination Domain Verification and Interval Consistency Check: After parsing the path attributes, the receiving side verifies the TT and signature. If the TT digest and signature hit the cache, signature verification is unnecessary. Based on the corresponding GridProfile, the BucketID is restored to the set interval range [L-HysteresisExit, H+HysteresisEnter] that the continuous value should fall into, where L and H represent the upper and lower limits of the interval, respectively, and HysteresisExit and HysteresisEnter represent the elastic threshold for interval switching. Then, an interval consistency check is performed on the continuous value CMetric. If the TT digest and signature do not hit the cache, digital signature verification is performed on the TT digest and signature. If the signature verification fails, the receiving is rejected or marked as unverifiable and the process ends. If the signature verification is successful, the result is written to the signature verification cache, and the cache validity period does not exceed Texp.

[0016] Perform interval consistency checks on continuous values ​​CMetric: verify whether CMetric satisfies CMetric∈[L-HysteresisExit, H+HysteresisEnter]. If not, determine that the announcement is inconsistent, reject the announcement, or downgrade it according to the policy. After successful verification, use the computing power announcement for routing policies, computing power scheduling, or service selection decisions.

[0017] Compared with the per-update integrity protection method, the beneficial effects of the present invention include:

[0018] (1) By associating signature updates with cross-interval events, the frequency of repeated signature verification / re-signing can be reduced in the update-intensive window caused by route refresh or network fluctuations, thereby helping to alleviate the peak computational pressure on the control plane and improve scalability.

[0019] (2) The continuous resource metric CMetric can still be propagated with the announcement. The recipient can realize verifiable announcements through signature-protected interval constraints and continuous value interval checks. While satisfying verifiability, it helps to retain a certain continuous value expression capability within the interval and decouples it from high-frequency UPDATE. This can reduce the overhead of repeatedly carrying static configuration content in the announcement, so as to support the consistency management of configuration versions. Attached Figure Description

[0020] Figure 1 This is a cross-domain overall flowchart of the cross-domain computing power routing information security announcement method based on BGP of the present invention;

[0021] Figure 2 This is a schematic diagram of the structure of the cross-domain computing power routing information security notification system based on BGP of the present invention;

[0022] Figure 3 This is a flowchart of the trust stamp generation and signature process in this invention;

[0023] Figure 4 This is a schematic diagram of the interval switching logic of the present invention;

[0024] Figure 5 This is a flowchart of the destination domain signature verification and interval consistency check in this invention. Detailed Implementation

[0025] The system and method embodiments of the present invention will be described below with reference to the accompanying drawings.

[0026] The IETF CATS framework draft documents indicate that computation metrics may change frequently. Meanwhile, BGP can trigger peers to resend previously announced route updates through route refreshes in scenarios such as route policy adjustments, potentially leading to a surge in update arrivals. If a digital signature is generated and verified for each UPDATE carrying computing power information, the signature / verification computation overhead is strongly correlated with the number of UPDATEs. This can cause concentrated control plane processing load during burst windows, forcing engineering implementations to control peak overhead by reducing the announcement frequency or coarsening the metric granularity, thus affecting the real-time performance and granularity of computing power scheduling. Therefore, the technical problem of this invention is to reduce the coupling between computing power information integrity protection overhead and announcement trigger frequency while satisfying cross-domain verifiability, and to improve the availability and scalability of the control plane during periods of dense updates.

[0027] The overall cross-domain process is as follows: Figure 1 As shown, the system structure is as follows: Figure 2 As shown.

[0028] like Figure 2 As shown, the cross-domain computing power routing information security notification system of the present invention includes at least a source domain controller, a signature device, and an egress BGP speaker on the source AS (Provider AS) side, and a destination domain controller, an ingress gateway / ingress device, and a local cache on the destination AS (Consumer AS) side. Each module can be implemented by software, firmware, or hardware, and can be deployed centrally or in a distributed manner.

[0029] 1) Source Domain Controller: Includes a range configuration management module, a version / digest generation module, and a configuration distribution module. The range configuration management module is used to generate / maintain GridProfile; the version / digest generation module is used to generate the configuration version ProfileVersion and configuration digest ProfileDigest; the configuration distribution module is used to configure / distribute GridProfile and its identification information to the signing device and the egress BGP Speaker via the management / control channel.

[0030] 2) Signature Device: This includes an indicator receiving module, an interval mapping module, a state maintenance module, a TT generation module, and a signature module. The indicator receiving module receives continuous indicators (CMetric) reported by the Metric Agent; the interval mapping module maps CMetric to BucketID based on the GridProfile and performs hysteresis and minimum dwell time determination; the state maintenance module maintains the previous interval identifier (BucketID_prev), the previous sequence number (Seq_prev), and the most recent switch time; the TT generation module generates a trust stamp (TT); and the signature module digitally signs the TT digest to generate a signature (Sig).

[0031] 3) Outbound BGP Speaker: Includes an attribute encapsulation module and an announcement policy module. The attribute encapsulation module is used to encapsulate service / instance identity, continuous values ​​CMetric, TT, and Sig into SEC-METRIC-INFO path attributes; the announcement policy module is used to trigger UPDATE according to policies and can perform filtering / stripping based on the allowed autonomous system scope.

[0032] 4) Destination Domain Controller: Includes a range configuration receiving / distribution module, used to obtain the source domain GridProfile and its identification information, write it to the local cache and distribute it to the ingress gateway.

[0033] 5) Entry Gateway / Entry Device: Includes an attribute parsing module, a signature verification caching module, a signature verification module, an anti-rollback and binding check module, and a range consistency check module. These modules are respectively used to parse attributes, cache signature verification results, verify signatures, check timestamps (TS), expiration times (Texp), sequence numbers (Seq), and binding consistency, and perform range consistency checks based on the GridProfile.

[0034] 6) Local Cache: Used to store the mapping from Cache[(ProviderAS, GridProfileID, ProfileVersion)] to GridProfile, enabling the ingress gateway to quickly look up and verify consistency.

[0035] Correspondence between modules and method steps:

[0036] (1) Range configuration distribution: The range configuration management / version summary generation / configuration distribution module of the source domain controller performs configuration generation and distribution; the range configuration receiving / distribution module of the destination domain controller imports the configuration and writes it to the local cache; the ingress gateway queries the corresponding GridProfile from the local cache by indexing {ProviderAS, GridProfileID, ProfileVersion}.

[0037] (2) Continuous Metric Collection and Reporting: The continuous metric CMetric is collected by the Metric Agent on each instance / service node and reported to the metric receiving module of the signature device through the domain security channel.

[0038] (3) Interval mapping, trust stamp generation and signing: The interval mapping module of the signing device calculates the BucketID, and the state maintenance module maintains BucketID_prev / Seq_prev, etc.; the TT generation module generates the trust stamp TT; the signing module signs the TT digest to generate Sig. The signature update is triggered in association with the BucketID cross-interval event.

[0039] (4) Attribute encapsulation and BGP announcement: The attribute encapsulation module of the outgoing BGP Speaker encapsulates CMetric, TT and Sig into SEC-METRIC-INFO and announces them with UPDATE; the announcement strategy module is responsible for filtering / stripping and triggering updates according to policies such as Scope.

[0040] (5) Parsing, signature verification and interval consistency check: CMetric / TT / Sig is extracted by the attribute parsing module of the ingress gateway; cache hit judgment is performed by the signature verification cache module; signature verification is performed by the signature verification module; TS / Texp and Seq anti-rollback and binding consistency check are performed by the anti-rollback and binding check module; BucketID to interval mapping is performed by the interval consistency check module and CMetric∈[L-HysteresisExit, H+HysteresisEnter].

[0041] Based on the above system, the method and process for implementing cross-domain computing power routing information security notification is as follows:

[0042] 1. Interval configuration and distribution.

[0043] like Figure 2 As shown, GridProfiles can be distributed within an Autonomous System (AS) via a control / management plane channel. Intra-AS controllers can configure / distribute GridProfiles to boundary signature devices and egress BGP Speakers via configuration and management protocols (such as NETCONF, gNMI, or other configuration management mechanisms). Source ASs and destination ASs can establish inter-regional configuration distribution channels via the management plane to synchronize the complete GridProfile definition using push or pull methods.

[0044] Upon receiving the data, the destination AS controller can distribute it to the ingress gateway and establish a local cache table `Cache[(ProviderAS, GridProfileID, ProfileVersion)] = {GridProfile, ProfileDigest,InstallTime}`, where `InstallTime` represents the reception time. When the source AS updates the GridProfile, `ProfileVersion` increases, and `ProfileDigest` changes accordingly. After importing the new version, the destination AS can retain the old version in parallel to handle the propagation delay and replay window of route updates. In some embodiments, the retention period of the old version can be determined based on the maximum propagation delay, TT validity period, etc. To improve robustness, the ConsumerAS ingress gateway can periodically perform a consistency check on the cache: recalculate the digest of the local GridProfile and compare it with the local cache; if they are inconsistent, the relevant routes are marked as unverifiable or a degradation strategy is implemented.

[0045] In addition, the GridProfile configuration fields are as follows:

[0046] GridProfileID is a 32-bit integer that identifies a unique range configuration within the same ProviderAS.

[0047] ProfileVersion is a 32-bit integer, a range of version numbers configured for rolling upgrades and conflict detection.

[0048] MetricList is a list that identifies the set of metrics (such as CPU, GPU, prediction latency, etc.) participating in interval quantization. Each item in the list contains six fields: Type, identifying the metric type; RangeMin, the minimum acceptable value for the metric, used to construct the interval start point; RangeMax, the maximum acceptable value for the metric, used to construct the interval end point; Step, the interval width, which, along with the start and end points, divides the metric value into multiple discrete intervals; HysteresisEnter, the entry threshold offset when crossing from the current interval to an adjacent interval, used to determine the trigger condition for crossing into a new interval; and HysteresisExit, the exit threshold offset when returning from a new interval to the original interval, used to determine the trigger condition for crossing into an old interval.

[0049] MinDwellTime, a time parameter, is a globally defined minimum dwell time, indicating the minimum time a new interval must remain before the next interval switch is allowed.

[0050] In a preferred embodiment, the interval configuration further includes extended parameter fields: BucketEncodingScheme, which identifies the encoding method of BucketID in a multidimensional grid (e.g., linear combination encoding, bit concatenation, etc.). PriorityMetric identifies the main metric used for cross-interval determination in a multidimensional scenario, which supports the strategy module in making priority decisions based on a certain dimension (e.g., latency).

[0051] II. Computing Power Routing Information Security Notification Process

[0052] Step 1: Generation and Signing of Continuous Indicator Interval Validation Objects

[0053] Once the GridProfile distribution is complete, the computing nodes / service instances begin to continuously generate metrics. The Metric Agent deployed on each instance periodically collects continuous values ​​(collecting corresponding computing power information at a preset sampling period (e.g., 1 second or 5 seconds) and reports them to the signing device via a secure intra-domain channel, such as... Figure 3 As shown, the signature device maintains a running status for each instance, including the current interval identifier BucketID_curr, the previous interval identifier BucketID_prev, the current sequence number Seq_curr, the previous sequence number Seq_pre, and the time of the most recent interval switch.

[0054] After the signing device receives a new sample, the signing process is as follows: Figure 3 As shown, the signature device determines whether to switch intervals based on the boundary definition of the current interval. The interval switching logic is as follows: Figure 4 As shown, even if the interval switching conditions are met, the signature device will still check the minimum dwell time. For multi-dimensional indicators, the signature device can apply the same logic to each dimension and decide whether to trigger the overall interval switching according to the preset strategy.

[0055] Compare the current interval identifier BucketID_curr with the previous interval identifier BucketID_prev: When BucketID_curr equals BucketID_prev, it indicates that although the continuous value CMetric has changed, it still falls within the same interval range. In this case, the existing TT and signature can be reused, and only the cached continuous values ​​are updated for subsequent announcements, thus avoiding duplicate signatures triggered by small fluctuations while updating continuous values. When BucketID_curr is not equal to BucketID_prev, it indicates that a cross-interval event has occurred; the increment of the sequence number Seq is associated with the cross-interval event (rather than with the number of samples), and a new trust stamp TT and its signature are generated accordingly, thereby updating the verifiable status of the external announcement to a new (BucketID_curr, TT, Sig) combination.

[0056] TT contains the following fields:

[0057] ProviderAS specifies the issuer autonomous system, representing which AS is responsible for the information in this range, and is used to select the signature verification public key and range configuration.

[0058] ServiceID, the service identifier, corresponds to the service prefix in BGP NLRI, ensuring that TT is used only for a specific service.

[0059] InstanceID: A service instance or node / site identifier that distinguishes different resource objects under the same ServiceID.

[0060] GridProfileID, together with ProviderAS and ProfileVersion, specifies the range configuration to be used.

[0061] ProfileVersion range configures the version number.

[0062] BucketID is the number of the interval corresponding to the current instance's computing power metric, actually representing a set of numerical intervals [L,H]; for multi-dimensional metrics, it can be encoded as a combination of interval numbers from multiple dimensions.

[0063] Scope describes the autonomous system scope that TT is allowed to apply to. It can represent "a certain set of alliances" or "the entire network" and is used to limit the scope of attribute propagation and verification.

[0064] TS, timestamp, identifies the issuance time of TT and is used to limit the validity period and prevent long-term replay.

[0065] Texp indicates the expiration time of TT; TT becomes invalid after this time.

[0066] Seq is a sequence number maintained for each ServiceID / InstanceID, which increments only when the BucketID changes, to prevent the old range from rolling back to the new state.

[0067] Step 2: BGP path attribute encapsulation and announcement

[0068] ProviderAS's outbound BGP Speakers will generate / update external BGP route advertisements according to certain policies.

[0069] The egress routing device uses Service Route NLRI to identify services / instances and carries a custom SEC-METRIC-INFO extended attribute in the PathAttributes of UPDATE.

[0070] In some embodiments, the SEC-METRIC-INFO attribute is configured as an optional transitive attribute to support incremental deployment. It can also carry a Scope field, and the policy module of the participating domain can perform sending-side filtering / stripping based on the Scope, thereby reducing the possibility of cross-scope propagation. It should be noted that when an intermediate AS does not understand this attribute, it may still be transparently forwarded according to BGP's processing rules for optional transitive attributes; therefore, the constraints of the Scope are mainly enforced by the policy module of the participating domain.

[0071] Step 3: Target domain verification and interval consistency check

[0072] The process for destination domain validation and interval consistency check is as follows: Figure 5 As shown, after the destination domain ingress gateway / ingress device receives the BGP UPDATE carrying the SEC-METRIC-INFO attribute, the attribute parsing module first parses the NLRI and SEC-METRIC-INFO, extracts the service / instance identity, continuous value CMetric, trust stamp TT, and signature Sig, and locates {ProviderAS, GridProfileID, ProfileVersion} indicated in TT for subsequent configuration lookup.

[0073] Subsequently, the signature verification cache module queries the local signature verification cache using (TT digest, Sig) as the key. If the cache is hit, the signature verification step can be skipped and the plaintext constraint check can be directly performed to reduce the overhead of repeated signature verification. If the cache is not hit, the signature verification module selects the corresponding public key based on ProviderAS to perform digital signature verification on TT digest and Sig. If the signature verification fails, it will be rejected or marked as unverifiable and the process will end. If the signature verification is successful, the result will be written to the signature verification cache, and the cache validity period will not exceed Texp.

[0074] After signature verification passes or the cache is hit, the anti-rollback and binding check module performs constraint checks on the TT plaintext field, including but not limited to: TS / Texp validity (the current time should be within [TS, Texp]), Seq rollback prevention (Seq should not be less than the latest Seq in the local record of the ServiceID / InstanceID), and TT binding consistency check with NLRI / ServiceID / InstanceID; in some embodiments, the Scope field can also be used to restrict this attribute to participate in verification and decision-making only within the allowed autonomous system. If any of the above checks fails, the application will be rejected or a downgrade process will be performed, and the process will end.

[0075] After the plaintext constraint check passes, the interval consistency check module looks up the corresponding GridProfile in the local cache by index {ProviderAS, GridProfileID, ProfileVersion}, and restores the BucketID in TT to the interval range [L, H] it represents (multiple interval ranges for multi-dimensional metrics). Then, a consistency check is performed on the continuous value CMetric: preferably, it checks whether CMetric satisfies CMetric∈[L-HysteresisExit, H+HysteresisEnter]; if it does not satisfy, it is determined that the announcement is inconsistent, and it is rejected or downgraded according to the policy; if it satisfies, it is determined that the announcement is verifiable, and the computing power is input into the subsequent routing policy, computing power scheduling or service selection decision module.

Claims

1. A method for security announcement of cross-domain computing power routing information based on BGP, characterized in that, The specific process is as follows: (a) The source AS performs intra-domain and cross-domain configuration distribution; The source domain controller generates the interval configuration and its identification information, and distributes it to the signing device and the egress device within the domain. An interval configuration distribution channel is established between the source domain and the destination domain. The destination domain distributes the received interval configuration to the ingress gateway and establishes a local cache table. (ii) Security Notice Regarding Cross-Domain Computing Power Routing Information; Step 1: Generation and signing of continuous indicator interval verification objects: The Metric Agent deployed on the computing power nodes / service instances within the source domain periodically obtains the continuous computing power metric value CMetric, performs interval processing on CMetric according to the interval configuration GridProfile, and obtains the interval identifier BucketID corresponding to CMetric; generates a trust stamp TT based on BucketID and its context, generates a digital signature for the trust stamp, and determines the update of TT and its signature by performing hysteresis and minimum dwell time determination on BucketID; Step 2, BGP path attribute encapsulation and announcement: The service / instance identity, continuous value CMetric, TT, and signature are encapsulated into a new path attribute of BGP UPDATE and sent to the destination AS through the source AS for announcement; Step 3, Destination Domain Verification and Interval Consistency Check: After parsing the path attributes, the receiving side performs a hit verification on TT and signature based on the local cache, and then performs an interval consistency check on CMetric. If both checks pass, the cross-domain computing power routing announcement is used for routing policy, computing power scheduling, or service selection decisions; if either fails, the announcement is determined to be inconsistent, and the service is rejected or downgraded according to the policy. The process of verifying the hit between TT and signature based on local cache is as follows: If the TT digest and signature hit the local cache, there is no need to verify the signature. Based on the corresponding GridProfile, the BucketID is restored to the set range [L-HysteresisExit, H+HysteresisEnter] that the continuous value should fall into, where L and H represent the upper and lower limits of the range, respectively, and HysteresisExit and HysteresisEnter represent the elastic threshold for range switching. Then, the range consistency check is performed on the continuous value CMetric. If the TT digest and signature do not hit the local cache, digital signature verification is performed on the TT digest and signature. If the signature verification fails, the application is rejected or marked as unverifiable and the process ends. If the signature verification succeeds, the result is written to the signature verification cache, and the cache validity period does not exceed Texp.

2. The method for security announcement of cross-domain computing power routing information based on BGP according to claim 1, characterized in that, The specific process for determining hysteresis and minimum dwell time for BucketID is as follows: Compare the current interval identifier BucketID_curr with the previous interval identifier BucketID_prev: When BucketID_curr equals BucketID_prev, it means that although the continuous value CMetric has changed, it still falls within the same interval range. At this time, the existing TT and signature are reused, and only the cached continuous values ​​are updated for subsequent announcements, thereby avoiding the triggering of duplicate signatures due to small fluctuations while updating the continuous values. When BucketID_curr is not equal to BucketID_prev, it indicates that a cross-range event has occurred. The increment of the sequence number Seq is associated with the cross-range event, and a new trust stamp TT and its signature are generated accordingly, thereby updating the externally announced verifiable status to the new combination of (BucketID_curr, TT, Sig).

3. The method for security announcement of cross-domain computing power routing information based on BGP according to claim 1, characterized in that, Perform interval consistency checks on continuous values ​​CMetric, specifically checking whether CMetric satisfies CMetric∈[L-HysteresisExit, H+HysteresisEnter].

4. A BGP-based cross-domain computing power routing information security notification system, implementing the method of any one of claims 1 to 3, characterized in that, The source AS side includes the source domain controller, signature device, and egress device BGP Speaker; the destination AS side includes the destination domain controller, ingress device, and local cache. The source domain controller generates the interval configuration and its identification information, and distributes it to the signature device and the egress device. The signature device receives the continuous metric CMetric reported by the Metric Agent, maps CMetric to BucketID according to the GridProfile, and performs hysteresis and minimum dwell time determination to determine whether TT and its signature need to be updated. The egress device encapsulates the service / instance identity, continuous value CMetric, TT and Sig into path attributes, and triggers UPDATE according to the policy. The destination domain controller obtains the source domain GridProfile and its identification information, writes it to the local cache, and distributes it to the entry device. The entry device parses and verifies the path attributes based on the local cache.

Images