A cross-domain intelligent agent service discovery method based on a BGP protocol

Abstract

The application provides a cross-domain intelligent agent service discovery method based on BGP multi-protocol extension, which comprises the following steps: a service discovery gateway of a first autonomous system (AS) generates a detailed route containing instance information according to a registration request of an intelligent agent instance; a route reflector of the first AS aggregates a plurality of detailed routes to generate an aggregated route; the aggregated route contains a gateway address of the service discovery gateway of the first AS; the route reflector of the first AS sends the aggregated route to other ASs, so that the other ASs send an instance information query request to the service discovery gateway of the first AS according to the intelligent agent service information; and the first AS returns instance information of the plurality of intelligent agent instances to the second AS according to the query request, so that a service consumer in the second AS calls the intelligent agent instance in the first AS according to the instance information. The application realizes cross-domain intelligent agent service discovery by extending the BGP protocol to propagate route information containing intelligent agent service information between different autonomous systems.

Description

Technical Field

[0001] This invention relates to the field of computer network technology, and in particular to a cross-domain intelligent agent service discovery method based on the BGP protocol. Background Technology

[0002] Agent service discovery refers to the process by which agents autonomously locate, identify, connect to, and invoke services of other agents in a complex and ever-changing network environment. Its goal is to enable agents to autonomously find suitable partners and establish effective communication. Agent service discovery is a key infrastructure for realizing collaborative work among agents.

[0003] Existing methods for agent service discovery mainly include:

[0004] 1. Service discovery based on standard URI (Uniform Resource Identifier): The metadata and service endpoint information of the agent are obtained directly by accessing the fixed path of the agent server. However, this method is only applicable to services with known addresses, and the coverage of service discovery is narrow, making it difficult to achieve large-scale agent collaboration.

[0005] 2. Service discovery based on service registry: Build an agent directory or marketplace (i.e., service registry) in the enterprise intranet or application market. This directory summarizes multiple registered agents. Agent service discovery can be completed by querying this directory.

[0006] Service discovery based on service registries is a widely used approach, with software vendors publishing and managing services through their own "agent marketplaces." While this model can promote collaboration among agent services locally, it presents significant challenges for cross-platform and cross-vendor collaboration. Due to the lack of unified service discovery and interaction standards, agent services in different autonomous communities exist like "digital islands," struggling to establish effective communication and collaboration mechanisms. When complex tasks require collaboration from multiple agents from different marketplaces, system integration faces immense difficulties—not only dealing with diverse data formats and communication protocols but also overcoming significant differences in authentication, security policies, and quality of service assurance. This situation severely restricts the overall effectiveness of agent services, hindering the realization of network effects and collaborative intelligence, and limiting the large-scale development and application value release of the entire agent service ecosystem.

[0007] Therefore, there is a need for a method for discovering intelligent agent services across domains and organizational structures, which can serve as the basis for cross-domain intelligent agent service collaboration and promote the overall improvement of intelligent agent service efficiency. Summary of the Invention

[0008] To address the aforementioned issues and enable service discovery of intelligent agent services in wide area networks, this invention provides a cross-domain intelligent agent service discovery scheme based on the BGP protocol.

[0009] According to a first aspect, the present invention provides a cross-domain intelligent agent service discovery method based on the BGP protocol, the method being executed by a service discovery gateway and a route reflector of a first autonomous community (AS), comprising:

[0010] The service discovery gateway of the first AS receives registration requests and / or heartbeat indicators from agent instances in the first AS.

[0011] The service discovery gateway of the first AS generates a detailed route containing instance information based on the registration request and / or heartbeat indicators, and sends it to the route reflector of the first AS; the instance information includes the service type and service port of the agent instance.

[0012] The route reflector of the first AS aggregates multiple detailed routes with the same service type to generate an aggregated route; the aggregated route contains the agent service information of the first AS, which includes the gateway address of the service discovery gateway of the first AS, and the aggregated information obtained by aggregating the instance information from multiple detailed routes.

[0013] The route reflector of the first AS sends the aggregated route to other ASs, enabling other ASs to obtain the agent service information and send an instance information query request to the service discovery gateway of the first AS based on the gateway address in the agent service information.

[0014] The service discovery gateway of the first AS returns instance information to the second AS based on the instance information query request sent by the second AS, enabling the service consumer in the second AS to call the agent instance in the first AS based on the service port in the instance information.

[0015] In some embodiments, the registration request includes the service type, service port, self-describing protocol type, and security policy of the agent instance; the heartbeat metric includes the real-time health and current load of the agent instance.

[0016] In some embodiments, the instance information further includes: the agent instance's self-describing protocol type, security policy, instance number, real-time health status, and current load; the detailed route includes NLRI and extended community attributes, the NLRI of the detailed route includes the agent instance's service type and IP address prefix, and the extended community attributes of the detailed route include the agent instance's service port, self-describing protocol type, security policy, instance number, real-time health status, and current load.

[0017] In some more specific embodiments, the aggregated information includes: the public service type, public service port, public self-describing protocol type, public security policy of multiple agent instances, and the number of instances and average health of the instances;

[0018] The aggregated route includes Network Layer Reachability Information (NLRI) and extended community attributes. The NLRI of the aggregated route includes the public service type of the multiple agent instances. The extended community attributes of the aggregated route include the public service port, public self-describing protocol type, public security policy, the number of instances of the multiple agent instances, the average health of the instances, and the gateway address of the first AS service discovery gateway.

[0019] In some more specific embodiments, generating a detailed route containing instance information based on the registration request and / or heartbeat metrics specifically includes: encoding the instance information according to a preset encoding rule to obtain the NLRI and extended community attributes of the detailed route.

[0020] In some more specific embodiments, multiple detailed routes with the same service type are aggregated to generate an aggregated route, specifically including:

[0021] The IP address prefixes of the multiple detailed routes are aggregated based on Classless Inter-Domain Routes (CIDR) to obtain the IP address prefixes in the aggregated route NLRI;

[0022] The public service type of the multiple detailed routes is used as the service type in the aggregated route NLRI;

[0023] The number of the multiple detailed routes is used as the number of instances in the aggregated route extended community attribute;

[0024] The real-time health scores of the multiple detailed routes are weighted and averaged, and the weighted average result is used as the average health score in the extended community attribute of the aggregated route.

[0025] In some embodiments, the instance information includes the security policy of the agent instance, and the service consumer in the second AS calls the agent instance in the first AS according to the service port in the instance information, specifically including:

[0026] The service consumer sends a self-describing interface query request that conforms to the security policy to the service port of the agent instance based on the service port and security policy in the instance information;

[0027] The agent instance performs security verification on the query request of the self-describing interface according to the security policy. After the verification is successful, the instance returns complete metadata to the service consumer through the self-describing interface. The complete metadata includes the security requirements of the business interface.

[0028] Based on the complete metadata, the service consumer sends a business function call request that meets the security requirements of the business interface to the service port of the intelligent agent instance;

[0029] The agent instance performs business-level security verification on the call request. After successful verification, it executes the business logic and returns business data to the consumer.

[0030] In some more specific embodiments, the complete metadata also includes a list of capabilities, interfaces and protocols, and communication paths of the agent instance.

[0031] According to a second aspect, the present invention provides a cross-domain intelligent agent service discovery method based on the BGP protocol, the method being executed by a service discovery gateway of a first autonomous system (AS), comprising:

[0032] Receive the registration request and / or heartbeat indicator of the first AS agent instance;

[0033] Based on the registration request and / or heartbeat metrics, a detailed route containing instance information is generated and sent to the route reflector of the first AS. This causes the route reflector to aggregate multiple detailed routes with the same service type into an aggregated route, which is then sent to other ASs. These other ASs then obtain the agent service information and, based on the gateway address in the agent service information, send an instance information query request to the service discovery gateway of the first AS. The instance information includes the service type and service port of the agent instance. The aggregated route contains the agent service information of the first AS, including the gateway address of the first AS's service discovery gateway and aggregated information obtained by aggregating instance information from multiple detailed routes.

[0034] The instance information is returned to the second AS based on the instance information query request sent by the second AS, so that the service consumer in the second AS can call the agent instance in the first AS according to the service port in the instance information.

[0035] According to a third aspect, the present invention provides a cross-domain intelligent agent service discovery method based on the BGP protocol, the method being executed by a route reflector of a first autonomous community (AS), comprising:

[0036] Receive multiple detailed routes sent by the first AS service discovery gateway; each detailed route contains instance information of an agent instance;

[0037] Multiple detailed routes are aggregated to generate an aggregated route containing the service information of the first AS agent; the service information of the agent includes the gateway address of the first AS service discovery gateway, and the aggregated information obtained by aggregating the instance information from multiple detailed routes.

[0038] The aggregated route is sent to other ASs, causing the second AS to send an instance information query request to the service discovery gateway of the first AS based on the aggregated route; the service discovery gateway of the first AS returns the instance information of the multiple agent instances to the second AS based on the query request, so that the service consumer in the second AS can call the agent instance in the first AS based on the instance information.

[0039] According to a fourth aspect, the present invention provides a cross-domain intelligent agent service discovery method based on the BGP protocol, the method being executed by a service discovery gateway of a second autonomous community (AS), comprising:

[0040] Receive aggregated routes containing first AS agent service information; the agent service information includes the gateway address of the first AS service discovery gateway, and aggregated information obtained by aggregating multiple instance information;

[0041] Obtain the agent service information from the aggregated route;

[0042] Based on the gateway address in the intelligent agent service information, an instance information query request is sent to the service discovery gateway of the first AS.

[0043] Receive instance information returned by the first AS, and construct a service catalog based on the instance information;

[0044] The system receives a service request from a service consumer, searches for the optimal agent instance in the service directory based on the service request, and sends the instance information of the optimal agent instance to the service consumer, enabling the service consumer to invoke the optimal agent instance based on the instance information.

[0045] The cross-domain agent service discovery method provided by this invention successfully integrates distributed service discovery capabilities into the network infrastructure. Through BGP routing, a unified agent service discovery system is built across different communities, enabling agent instances from different communities to work collaboratively and achieving deep integration of the network and services. This method fully leverages the inherent advantages of the Internet system, providing a network-native discovery mechanism for agent services while maintaining global scalability and distributed autonomy. Attached Figure Description

[0046] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0047] Figure 1A multi-terminal interaction diagram of the intelligent agent service discovery method provided by this invention;

[0048] Figure 2 The authentication process of the layered security strategy provided by this invention is illustrated. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be described below with reference to the accompanying drawings.

[0050] Border Gateway Protocol (BGP) is a core routing protocol of the Internet, primarily used to exchange route reachability information between different Autonomous Systems (AS), ensuring efficient and accurate transmission of data packets across a wide area network. This invention proposes an extended BGP protocol to propagate agent service information between different ASes. By abstracting "agent service" into a reachability object, BGP adds "service reachability" semantics to its original "route reachability," thereby achieving cross-domain and cross-organizational agent service discovery. Specifically, the agent service discovery method provided by this invention routes agent service information generated by the AS where the agent service provider resides to other ASes via BGP, enabling service consumers in other ASes to establish contact with the agent service provider based on this information, thus achieving agent service discovery.

[0051] The following is combined with Figure 1 This invention provides a detailed description of the agent service discovery method. For example... Figure 1 As shown in the embodiments, this specification uses the agent service discovery process between the agent service provider located in the first autonomous system AS64500 and the service consumer located in the second autonomous system AS64501 as an example to introduce the agent service discovery method provided by the present invention.

[0052] The roles in the agent service discovery method provided in the embodiments of this specification include: agent service instance, service discovery infrastructure, and service consumer. The agent service discovery method provided in the embodiments of this specification is mainly executed by the service discovery infrastructure of each autonomous system. The service discovery infrastructure includes a service discovery gateway and a route reflector (RR), where the service discovery gateway is the core component of agent service discovery, including a service registry, service catalog, and BGP speaker.

[0053] The agent service discovery method provided in the embodiments of this specification includes four stages. Stage 1: Service registration and route distribution within the autonomous system.

[0054] S1, the service discovery gateway of AS64500, receives registration requests and / or heartbeat indicators from agent instances in AS64500.

[0055] The registration request includes the service type of the agent instance, endpoint information, and some metadata (such as self-describing protocol type, security policy, etc.).

[0056] For example, the registration request includes:

[0057] Service type: LLM inference;

[0058] Endpoint information: 203.0.113.25:8080

[0059] Self-describing protocol type: A2A

[0060] The service discovery gateway, acting as the agent service registrar for AS64500, contains detailed service entries for agents within AS64500. These service entries include instance information for all registered agent instances in AS64500, such as the instance's detailed address, real-time health status, current load, and security policies.

[0061] Upon receiving a registration request from a smart agent service instance in this community, the service discovery gateway will add the instance information of the newly registered smart agent instance to the service entry according to the registration request, complete the update of the service entry, and assign an instance number (instance ID) to the smart agent instance.

[0062] The service discovery gateway can manage agent service instances in this AS based on service entries, and can provide instance information to service discovery gateways in other communities through the agent instance information query request interface.

[0063] After registration, the service discovery gateway needs to receive the heartbeat metrics reported in real time by the agent instance of this AS. The heartbeat metrics include the real-time health and current load of the agent instance. The service discovery gateway updates the agent service entries in real time according to the heartbeat metrics, monitors the real-time status of each agent instance in AS64500, and promptly publishes detailed route announcements to the route reflector of this AS after the heartbeat metrics of the instance change.

[0064] The above describes the process of agent instance registration in AS64500. The following describes the specific implementation of service registration in BGP.

[0065] The service discovery gateway relies on the BGP speaker to establish iBGP neighbors with the route providers (RRs) in the same AS. The discovery gateway publishes and listens for BGP service routes through gRPC (Google Remote Procedure Call) calls and the BGP speaker; the discovery gateway itself does not need to concern itself with the specific implementation of the BGP protocol. A BGP speaker is a routing device specifically designed to run the BGP protocol and send BGP messages. It is responsible for receiving or generating new routing information and publishing this information to other BGP speakers. gRPC is a remote procedure call framework developed and open-sourced by Google. It allows applications on different machines and in different languages ​​to communicate remotely as if calling local methods, and is widely used in distributed systems and microservice architectures.

[0066] The gateway registrar needs to implement the following gRPC / Unix-socket stub to perform route announcement and revocation:

[0067] service AgentAnnouncer {

[0068] rpc Publish(PrefixRequest) returns (Empty);

[0069] rpc Withdraw(PrefixRequest) returns (Empty);

[0070] }

[0071] The PrefixRequest message summary is as follows:

[0072] message PrefixRequest {

[0073] / / --- Core identity information (mapped to BGP Agent-service NLRI) ---

[0074] CoreNlriData nlri_data = 1;

[0075] / / --- Real-time status information (mapped to BGP non-transitive attributes) ---

[0076] AgentDynamicState dynamic_state = 2;

[0077] / / --- Strategy and Metadata (Mapping to BGP community and other passed attributes) ---

[0078] AgentPolicyMetadata policy_metadata = 3;

[0079] }

[0080] When the gateway detects that it has received a registration request for the agent service of this AS, it constructs a PrefixRequest based on the registration request to call the gRPC interface mentioned above. After the BGP speaker receives the call request through the gRPC interface, it installs the Prefix into the local routing table information base, and then sends a BGP UPDATE message (i.e., detailed route) to the RR.

[0081] The S2 and AS64500 service discovery gateways generate detailed routes based on the registration request or heartbeat indicators.

[0082] In the "service reachability" semantics of this invention, BGP is responsible for informing the consumer: "There is an agent service of type X running on address ABCD:Port P. It is healthy, supports self-describing protocol type Z, and the security requirements for accessing the self-describing interface include:..." To achieve the above service reachability semantics, this invention extends the design of BGP UPDATE messages (including detailed routes and aggregate routes), integrating instance information into detailed routes and agent service information into aggregate routes. The design of BGP UPDATE messages for detailed routes is described in detail below.

[0083] In this embodiment of the invention, the address family for the BGP protocol extension design uses the existing address family identifier, i.e., AFI=1 (IPv4) or AFI=2 (IPv6). To implement the BGP protocol extension design of this invention, a new sub-address family identifier SAFI (e.g., SAFI=75) specifically for agent services needs to be applied for from the Internet Assigned Numbers Authority (IANA) to identify that the BGP session supports the agent service discovery method described in this invention. The protocol layer uses an independent NLRI space parallel to IPv4 / IPv6 routing, without interfering with existing routing.

[0084] BGP UPDATE messages include Network Layer Reachability Information (NLRI) and extended community attributes.

[0085] The NLRI field information includes the service type of the agent instance and the IPv4 / IPv6 address prefix of the agent service, as shown in Table 1.

[0086] Table 1 NLRI Field Information

[0087]

[0088] The extended community attributes in the detailed routes are shown in Table 2, including the service port, self-describing protocol type, security policy, instance number, real-time health status, and current load of the agent instance. Among these, the instance number, real-time health status, and current load are non-aggregable attributes and are only transmitted within this AS. All of the above extended community attributes can be obtained by the service discovery gateway based on the agent instance's registration request and heartbeat metrics.

[0089] Adding extended community attributes to BGP UPDATE messages can reflect the real-time operational status of agent services and enhance routing decision-making capabilities to achieve fine-grained scheduling of service traffic.

[0090] Table 2 Detailed Routes Extended Community Attributes

[0091]

[0092] The attribute code value of real-time health can be calculated from the original value of real-time health according to the health attribute code mapping rules shown in Table 3.

[0093] Table 3 Health Attribute Coding

[0094]

[0095] The instance's load metric code corresponds to the instance's current load. Table 4 shows the instance's load metric attribute code and the corresponding load status level and scheduling policy.

[0096] Table 4 Load Metric Attribute Codes

[0097]

[0098] For example, the attribute encoding rules for security policies are shown in Table 5.

[0099] Table 5 Security Policy Coding

[0100]

[0101] For example, a BGP UPDATE message for a detailed route could be:

[0102] BGP UPDATE (Detailed Route):

[0103] - WITHDRAWN: empty

[0104] - PATH ATTRIBUTES:

[0105] ORIGIN: IGP

[0106] AS_PATH: (64500); Original AS path,

[0107] NEXT_HOP: 203.0.113.25; Instance exact address

[0108] EXTENDED_COMMUNITIES:

[0109] 0x4301:1F90 ; Service port (required)

[0110] 0x4302:0100 ; Self-describing protocol type (required)

[0111] 0x4303:0012; Security Policy (Required)

[0112] 0x43FF:FB9400000001 ; Instance ID (Aggregation disabled)

[0113] 0x43FE:00E6 ; Real-time health status (aggregation disabled)

[0114] 0x43FD:0064 ; Current load (aggregation disabled)

[0115] - NLRI (SAFI=75):

[0116] Service type: 0x0001 (LLM)

[0117] IP prefix: 203.0.113.25 / 32; accurate to a single instance.

[0118] The S3 and AS64500 service discovery gateways send the detailed routes to the AS64500 route reflector.

[0119] After the service discovery gateway's registrar generates detailed routes, it sends BGP UPDATE messages of the detailed routes to the route reflector (RR) through the service discovery gateway's BGP speaker.

[0120] The BGP speaker of the service discovery gateway is used to establish BGP neighbor relationships with the route reflector (RR) of this AS. After receiving the detailed route sending request from the service registrar, it sends the detailed routes generated by the service registrar of this AS to the RR of this AS. The BGP speaker is also used to receive service routes from other ASs from the RR of this AS.

[0121] S4. The route reflector aggregates multiple detailed routes from the service discovery gateway to generate aggregated routes.

[0122] Multiple detailed routes correspond to multiple agent instances. During aggregation, multiple routes with the same service type are aggregated to generate aggregate routes.

[0123] The BGP UPDATE message for aggregated routes also includes NLRI and extended community attributes.

[0124] The NLRI field information of the aggregated route includes the service type and the IPv4 / IPv6 address prefix. Aggregation combines agent instances with the same service type, and the service type of the aggregated route is the public service type of these instances. The IPv4 / IPv6 address prefix of the aggregated route is the aggregated IP prefix of multiple agent instances, which can be obtained by aggregating the IPv4 / IPv6 address prefixes of the aggregated instances based on Classless Inter-Domain Routing (CIDR).

[0125] The extended community attributes and aggregation rules of the aggregated route are shown in Table 6. The extended community attributes of the aggregated route include the service port, self-describing protocol type, security policy, number of aggregated instances, average health of the instances, and the service discovery gateway address of this AS.

[0126] Table 6. Community Attributes for Aggregated Routes

[0127]

[0128] In this case, the service port, self-describing protocol type, and security policy of the aggregated route are common values ​​taken from multiple agent instances.

[0129] For example, the average health of an instance can be calculated using a weighted average algorithm. When calculating the average health using the weighted average algorithm, a weight value needs to be assigned to each instance. Then, the health of each instance is multiplied by its weight value. The results of multiplying all instances by their respective weights are then summed. Finally, the summation is divided by the sum of the weight values ​​of all instances to obtain the average health. Finally, the average health is converted into a health attribute code according to the health attribute coding mapping rules shown in Table 3.

[0130] Specifically, if the aggregated instances include instance 1 and instance 2, their health scores and weights are as follows:

[0131] Example 1: Health 90%, weight 1; Example 2: Health 80%, weight 2;

[0132] Therefore, the average health score = (90 * 1 + 80 * 2) / (1 + 2) = 83.3;

[0133] According to the health coding mapping rule of "code value = average health × 2.55", the average health is linearly mapped to the hexadecimal health attribute code, and the aggregated average health attribute code is 0xD5.

[0134] This invention designs the BGP UPDATE message to set appropriate flooding ranges for each BGP route attribute. Route attributes that change frequently in detailed routes (such as health and load metrics) or are difficult to aggregate (such as the detailed ID of an instance) are only propagated within the current Action Server (AS). Simultaneously, an average health score is set in the aggregated route, which reflects the overall health changes of the aggregated instances without causing frequent changes in the aggregated route due to changes in detailed routes.

[0135] The aggregated route needs to include the gateway address of the service discovery gateway of this AS, that is, the discovery gateway address of AS64500, so that other ASs can request instance information from the service discovery gateway of this AS based on this gateway address.

[0136] The attribute encoding of the gateway address can be implemented as shown in Table 7.

[0137] Table 7 shows the gateway address attribute encoding.

[0138]

[0139] The type field identifies the private scope of the service discovery gateway, which is dedicated to the agent service. 0xFFFF is just an example, and a specific type field encoding needs to be requested from IANA.

[0140] For example, the attribute encoding format of the discovered gateway address is: 0xFFFF:ASN:IP:Port;

[0141] The following are two specific examples of gateway address attribute encoding discovery:

[0142] The attribute code 0xFFFF0000FB94C0A80101F90 represents the gateway 192.168.1.1:8080 of the Autonomous System AS64500; the attribute code 0xFFFF0000FB95C0A80102F90 represents the gateway 192.168.1.2:8080 of the Autonomous System AS64501.

[0143] For example, a BGP UPDATE message for an aggregated route could be:

[0144] BGP UPDATE (Aggregated Route):

[0145] - WITHDRAWN: empty

[0146] - PATH ATTRIBUTES:

[0147] ORIGIN: IGP

[0148] AS_PATH: (64500 64500);

[0149] AGGREGATOR: AS64500 192.0.2.1

[0150] NEXT_HOP: 198.51.100.254

[0151] EXTENDED_COMMUNITIES:

[0152] 0x4301:1F90 ; Inherited common port

[0153] 0x4302:0100; Inherited from public version

[0154] 0x4303:0001; Unified Security Policy

[0155] 0x4304:0003 ; Aggregate instance count (new)

[0156] 0x4305:00C8; Average Health (New)

[0157] 0x4306:FFFFFB94C0A80101F90 ; Gateway address (added)

[0158] COMMUNITY:

[0159] 64500:2000; Aggregation tag

[0160] - NLRI (SAFI=75):

[0161] Service type: 0x0001 (LLM)

[0162] IP prefix: 203.0.113.0 / 24; CIDR aggregation

[0163] The above describes the service registration and route distribution process within the AS64500, and specifically details the BGP UPDATE message design of the BGP protocol extension in this invention. This embodiment's BGP protocol extension design can reflect the real-time operational status of agent services, enhancing routing decision-making capabilities. Furthermore, by selecting effective aggregation dimensions, the routing table contains only core routing information, avoiding excessive expansion of the routing table and preventing frequent updates to aggregated routes due to changes in detailed routes.

[0164] Phase 2: Routing Propagation Across AS

[0165] The route reflector of S5 and AS64500 sends the aggregated route to the route reflector of other autonomous systems (AS64501).

[0166] Aggregated routes are passed between different ASs via route reflectors.

[0167] The route reflector RR of S6 and AS64501 sends the aggregated route to the service discovery gateway of AS64501.

[0168] The BGP speaker of the AS64501 service discovery gateway receives aggregated routes reflected from AS64500 at the RR of AS64501, maintaining route reflector attributes (such as anti-loop attributes Originator_ID and Cluster_List) during the process.

[0169] The AS64501 service discovery gateway's service catalog listens in real time to reflected routes received by the BGP speaker through pre-initiated subscription requests (gRPC requests), and receives aggregated routes from the AS64500.

[0170] The above describes the specific process of route propagation across AS.

[0171] In the specific implementation of route propagation, hierarchical routing policies can be configured at the corresponding routing nodes to ensure that each level of the WAN can receive the routing information it needs, and will not receive routing information that is unnecessary for that level of role. This invention sets frequently changing dynamic states (such as health and load) as optional non-transitive attributes in detailed routes, which actively and intelligently prevents aggregation, allowing this real-time information to propagate completely within the AS for fine-grained traffic scheduling. The hierarchical routing policy specifically includes: aggregating routes and filtering non-transitive attributes at AS boundaries and the Internet backbone; and disabling aggregation within the AS to retain all state information.

[0172] The hierarchical routing strategy, as shown in Table 8, divides roles in the WAN into the backbone layer, regional layer, access layer, and switching point layer. The backbone layer serves as the global service routing exchange backbone, performing full service routing table exchange and receiving all aggregated routes. Within this layer, only "service reachability" information is propagated through aggregated routes, filtering out all non-transitive dynamic attributes, as the global network does not need to be aware of the load on individual instances. The regional layer is responsible for service route distribution within its region. Route aggregation is prohibited within a region, meaning that service routes transmitted within a region are detailed routes to ensure that route reflectors and gateways can see the complete state of all instances, thereby making optimal local routing decisions. The access layer is responsible for service route consumption and publication; each consumer and agent service provider subscribes to and obtains specific service routes on demand. The switching point layer acts as the peer hub for service routes, with routes centrally exchanged through a server model.

[0173] Table 8 Hierarchical Routing Strategies

[0174]

[0175] Phase 3: Service Catalog Synchronization

[0176] The service discovery gateways of S7 and AS64501 send instance information query requests to the service discovery gateway of AS64500 based on the aggregated routes from AS64500.

[0177] After receiving the aggregated route from AS64500, the service directory of the AS64501 service discovery gateway parses the aggregated route to obtain the agent service information contained in the aggregated route. The agent service information includes the number of aggregated instances, average health, service type, self-describing protocol type, security policy, and the discovery gateway address of AS64500.

[0178] At this point, the service discovery gateway of AS64501 can determine whether it is necessary to continue requesting instance information based on the instance aggregation information. For example, if the service type of the aggregated route is a large language model, which is not a service type required by AS64501, then it is not necessary to continue requesting instance information. This embodiment simplifies the routing table by setting appropriate extended community attributes for the aggregated route, while ensuring that the routing attributes transmitted in all ASs are necessary for all ASs. Each AS can request instance information as needed based on its actual situation.

[0179] When requesting instance information, the AS64501 service directory will send an instance information query request to the AS64500 service discovery gateway registrar based on the AS64500 discovery gateway address in the aggregated route and the number (origin_as) in the as-path attribute of the aggregated route.

[0180] For example, the discovery gateway interface specification in the instance information query request is: GET https: / / discoverygatewayIP:port / v1 / services / {service_type}?origin_as=64500.

[0181] In response to the query request, the S8 and AS64500 registrars send instance information to the service directory of the AS64501 service discovery gateway.

[0182] After receiving the query request, the AS64500 registrar generates instance information corresponding to the query request based on the query request and the detailed service entries of the AS64500 agent instance built into the registrar. The instance information is then fed back to the AS64501 service discovery gateway through the instance information query request interface.

[0183] The instance information includes the service type, service port, self-describing protocol type, security policy, instance number, real-time health status, and current load of all instances in the aggregated route.

[0184] The service discovery gateway S9 and AS64501 receive the returned instance information and construct a service catalog based on the instance information.

[0185] The AS64501 service discovery gateway can access the self-describing interface of the instance service endpoint through the instance endpoint information in the instance information, obtain the complete metadata of the agent instance, and build a service catalog based on the complete metadata of the instance.

[0186] The self-describing interface provides complete metadata of an instance to consumers or other service discovery gateways of an agent instance. The specific content and format of this complete metadata follow the self-describing protocol of the agent instance. For example, the complete metadata includes the agent instance's capability list, interfaces and protocols, business interface security requirements, and communication paths. The capability list includes the task types supported by the agent instance, inputs and outputs, API schema, etc.; the interfaces and protocols include the endpoints (e.g., OpenAPI / REST / gRPC / WebRTC), versions, methods, etc., of the agent service; business interface security requirements can be public keys, OAuth2.1, API keys, JWT requirements, etc.; and the communication path can be the standard well-known / agent-descriptions path. The self-describing API interface can return arbitrarily complex data structures, providing consumers with rich and flexible metadata, supporting different self-describing formats for different types of agents, and supporting real-time updates without waiting for BGP propagation.

[0187] The service catalog includes endpoint information, health status, load metrics, authentication mechanisms, and metadata of agent instances from other ASs.

[0188] After building the service catalog, the AS64501 service discovery gateway can also perform periodic network measurements on instance service endpoints, obtain instance service endpoint network metrics, and thus perform health checks on instances to update the service catalog.

[0189] The above describes the process by which the AS64501 on the service application side obtains service instance information of the AS64500 on the service provider side based on the aggregated route, and builds a service directory within the service discovery gateway of the AS64501. The service invocation process is described below.

[0190] Phase 4: Service Discovery and Invocation.

[0191] The S10 and AS64501 service discovery gateways receive service requests from service consumers.

[0192] The service request includes service type, service quality requirements, service health status, load requirements, etc.

[0193] S11 and AS64501's service discovery gateways search for the optimal agent instance in the service directory based on the service request, and send the detailed information of the optimal agent instance to the service consumer.

[0194] The service discovery gateway's service catalog provides a query interface for service instances based on multi-factor selection, allowing consumers to query by service type, health, and load status, and returning detailed information on the optimal agent instance that meets the criteria.

[0195] S12. The service consumer invokes the optimal agent instance based on the detailed information of the optimal agent instance.

[0196] The service consumer requests complete instance metadata from the self-describing API interface of the agent instance based on the service endpoint information in the detailed information, sends a business call request to the agent instance based on the complete metadata, and receives the business data returned by the agent instance to complete the business call.

[0197] For example, a consumer requests metadata from a self-describing API by sending the following information:

[0198] http

[0199] GET / .well-known / agent-service-descriptor

[0200] Accept: application / json”

[0201] For example, the complete metadata that an intelligent agent service instance sends back to the service consumer is as follows:

[0202] json

[0203] {

[0204] "service_id": "0x5a1f39e8c42b7a13", / / Instance ID

[0205] "name": "llm-inference-service", / / Instance name

[0206] "version": "2.1.0", / / Instance version number

[0207] "description": "Multimodal Large Language Model Inference Service", / / Instance Description

[0208] "api_endpoints": [ / / Instance business interface API information and business-level security policies]

[0209] {

[0210] "path": " / v1 / chat / completions",

[0211] "method": "POST",

[0212] "protocol": "grpc",

[0213] "request_schema": "llm_chat_schema.v1.proto",

[0214] "response_schema": "llm_response_schema.v1.proto"

[0215] },

[0216] {

[0217] "path": " / v1 / embeddings",

[0218] "method": "POST",

[0219] "protocol": "rest",

[0220] "content_type": "application / json"

[0221] }

[0222] ],

[0223] "capabilities": ["streaming", "batch_processing", "file_upload"], / / Capabilities description

[0224] "rate_limit": 1000, / / Rate limit

[0225] "updated_at": "2025-07-08T10:30:00Z" / / Update time

[0226] This invention employs a layered security mechanism to control access to service interfaces, ensuring the security of the agent service discovery process. This mechanism divides security into a community layer and a business layer, controlling access permissions through "self-describing interfaces" and "business interfaces" respectively to guarantee access security. Community layer security constraints are set during the BGP route propagation across AS phases, controlling access permissions to the "self-describing interfaces" through security policies carried in the community attributes of BGP aggregated routes, defining who has the right to query the complete metadata of the service instance. Business layer security constraints are set during the service invocation phase, controlling access permissions to the "business interfaces" through the service instance's own security mechanisms, defining who has the right to invoke the service's core functions.

[0227] The specific authentication process of the layered security mechanism is as follows: Figure 2 As shown, firstly (corresponding to step S10), the service directory receives a service request from the service consumer, which does not contain a specific security context. Next (corresponding to step S11), the service directory searches for the optimal agent instance based on the service request, and simultaneously checks whether the consumer's identity matches the security policy in the extended community corresponding to that instance. If the security policies match, the instance service endpoint information is sent to the consumer. Then (corresponding to step S12), the consumer accesses the instance service endpoint carrying the security token required by the extended community security policy, and sends a self-describing interface query request to the instance service endpoint. The agent service provider verifies whether the policy ID in the security token is consistent with the BGP aggregated route declaration. After successful verification, the agent service provider provides the consumer with complete metadata of the instance. Finally, the service consumer sends a business function call request that meets the service provider's business security requirements based on the metadata configuration to the service provider. The service provider performs business-level security verification on the call request. After successful verification, it executes the business logic and returns business data to the consumer, completing the call. If the service provider's security policy changes, a re-announcement of the aggregated route is triggered, and the service directory reminds the consumer to re-perform security verification according to the new aggregated route.

[0228] In practice, to enable BGP to address accurately, the "self-description interface" and "business interface" of the agent instance should run on the same address port as much as possible. If the server's native architecture is not on the same address, a proxy can be used to access the business interface on other addresses during actual deployment.

[0229] The aforementioned layered security mechanism maximizes the security of the business layer. BGP routing itself does not expose sensitive API structure information; even if an attacker sees the service's existence through BGP, they cannot directly obtain its API schema or invoke business functions. Furthermore, the security mechanisms for the "self-describing interface" and the "business interface" in the layered security mechanism are independent and do not affect each other. They can be independently formulated, modified, and maintained. In practice, the network team can be responsible for managing the extended community attribute security policy IDs, while the application team can be responsible for managing the security mechanisms of the business interfaces. In practice, complex discovery and authorization policies (such as attribute-based access control ABAC) can be defined as needed.

[0230] The above describes the specific process and security strategy of business invocation in the cross-domain intelligent agent service discovery provided by this invention. The following describes the fault handling and state synchronization process of intelligent agent service instances in the intelligent agent service discovery method provided by this invention.

[0231] When an agent service instance in AS64500 becomes unable to provide services due to a failure or other reasons, the agent instance needs to send a service offline notification to the service discovery gateway registrar of AS64500. After receiving the service offline notification, the service discovery gateway registrar sends a BGP WITHDRAW message to the BGP Speaker. The BGP Speaker then sends a route revocation request to the route reflector RR based on the message. The RR revoks the detailed route of the failed instance based on the route revocation request, recalculates the aggregate route, and announces the new aggregate route to other ASs. After receiving the new aggregate route, the RR of AS64501 reflects it to the service discovery gateway of AS64501. The service discovery gateway of AS64501 updates its service catalog based on the new aggregate route and stops recommending the failed instance to consumers.

[0232] The above describes the cross-domain agent service discovery method provided by this invention. This method successfully integrates distributed service discovery capabilities into the network infrastructure. Based on the existing self-built "agent markets" of different communities, a unified agent service discovery system is constructed between different communities (AS) through BGP routing. This enables agent instances from different communities to work collaboratively, achieving deep integration of network and services. This method fully leverages the inherent advantages of the Internet system, providing a network-native discovery mechanism for agent services while maintaining global scalability and distributed autonomy.

[0233] To implement the aforementioned agent service discovery method, the BGP protocol entity needs to support the addition of a new sub-address family identifier SAFI (e.g., SAFI=75) specifically for agent services and implement the corresponding community aggregation routing. This requires extensions at multiple levels of the protocol stack. The core aspects of extending the routing protocol stack are described below.

[0234] The BGP routing protocol stack involved in this invention includes FRRouting (FRR) and gobgod. The core components of the routing protocol stack extension include BGP protocol capability negotiation extension, NLRI data structure extension, extended community attribute definition, aggregated routing engine extension, route selection process modification, and route reflector support extension. These core components of the aforementioned protocol stack extensions are described below.

[0235] 1. BGP Protocol Capability Negotiation (i.e., BGP OPEN message) Extension: This part follows the constraints of the BGP Multiprotocol Extension Standard (MP-BGP, RFC 4760). The BGP OPEN message extension requires modifying the BGP OPEN message construction logic. This is achieved by setting a capability advertisement in the BGP OPEN message, declaring support for AFI=1 / 2 and SAFI=75, and negotiating the capability during session establishment to confirm that the peer supports SAFI=75.

[0236] For example, the format of a BGP capability announcement is as follows:

[0237] Capability Code: 1 (Multiprotocol Extensions)

[0238] Length: 4 octets

[0239] Value: AFI(2 octets) + SAFI(1 octet) + Reserved(1 octet) ”

[0240] The following is an example of modifying the BGP OPEN message code:

[0241] / / Add SAFI support to the BGP capability announcement structure

[0242] struct bgp_capability_mp {

[0243] uint16_t afi;

[0244] uint8_t safi;

[0245] uint8_t reserved;

[0246] };

[0247] / / Add SAFI=75 constant definition

[0248] #define BGP_SAFI_AGENT_SERVICE 75

[0249] / / Modify the ability negotiation logic

[0250] if (peer->afc[AFI_IP][SAFI_AGENT_SERVICE]) {

[0251] bgp_capability_mp_send(peer, AFI_IP, SAFI_AGENT_SERVICE);

[0252] 2. NLRI Data Structure Extension: This part complies with the constraints of RFC 4760. The NLRI data structure extension requires the construction of a new NLRI encoder / decoder, the implementation of new prefix verification logic (compatible with IPv4 / IPv6), and the implementation of service type validity checks.

[0253] For example, the NLRI format for an agent service is as follows:

[0254] Length (1 octet); # Total length of NLRI

[0255] Service Type (2 octets); # Service type identifier

[0256] Prefix Length (1 octet); # IP prefix length

[0257] Prefix (variable); # IP address prefix

[0258] 3. Extend the definition of community attributes. This part follows the constraints of RFC4360 and needs to implement the definition, parsing and processing of extended community attributes in the aforementioned agent service discovery method.

[0259] For example, the definition and parsing of extended community attributes can be implemented using the following code:

[0260] / / Add extended community type definition

[0261] #define EXT_COMMUNITY_AGENT_SERVICE 0x4300

[0262] #define EXT_COMMUNITY_SERVICE_PORT 0x4301

[0263] #define EXT_COMMUNITY_PROTOCOL_VERSION 0x4302

[0264] #define EXT_COMMUNITY_SECURITY_POLICY 0x4303

[0265] #define EXT_COMMUNITY_INSTANCE_COUNT 0x4304

[0266] #define EXT_COMMUNITY_HEALTH_LEVEL 0x4305

[0267] #define EXT_COMMUNITY_GATEWAY_ADDRESS 0x4306

[0268] / / Non-aggregatable properties (passed within AS)

[0269] #define EXT_COMMUNITY_INSTANCE_ID 0x43FF

[0270] #define EXT_COMMUNITY_CURRENT_HEALTH 0x43FE

[0271] #define EXT_COMMUNITY_LOAD_LEVEL 0x43FD

[0272] For example, the extended community attribute processing logic can be implemented using the following code:

[0273] / / Extended Community Property Encoder

[0274] int bgp_attr_agent_service_encode(struct bgp_attr_encoder *encoder,

[0275] struct bgp_route *route) {

[0276] / / Encode aggregateable attributes (0x4301-0x4306)

[0277] if (route->is_aggregated) {

[0278] encode_aggregatable_attrs(encoder, route);

[0279] } else {

[0280] / / Detailed routes contain all attributes

[0281] encode_all_attrs(encoder, route);

[0282] }

[0283] }

[0284] 4. Extension of the aggregation routing engine. This part follows the constraints of RFC4360 and needs to implement the routing aggregation strategy in the aforementioned agent service discovery method.

[0285] For example, the aggregated route mapping policy configuration can be implemented using the following code:

[0286] route-map AGENT-SERVICE-AGGREGATE permit 10

[0287] match safi 75

[0288] match extcommunity SERVICE-TYPE-LLM

[0289] set aggregate as-set

[0290] set extcommunity instance-count sum

[0291] set extcommunity health-level weighted-average

[0292] suppress-map DETAILED-ROUTES

[0293] For example, the aggregation algorithm can be implemented using the following code:

[0294] / / Aggregation core logic

[0295] struct bgp_route *aggregate_agent_service_routes(struct list *routes){

[0296] struct bgp_route *aggregate = bgp_route_new();

[0297] / / 1. Verify aggregability (same service type)

[0298] if (!can_aggregate_routes(routes)) {

[0299] return NULL;

[0300] }

[0301] / / 2. CIDR prefix aggregation

[0302] aggregate->nlri = cidr_aggregate(routes);

[0303] / / 3. Expand community attribute aggregation

[0304] aggregate->ecommunity = aggregate_ext_communities(routes);

[0305] / / 4. Remove non-aggregable properties

[0306] remove_non_aggregatable_attrs(aggregate);

[0307] / / 5. Add the AGGREGATOR attribute

[0308] bgp_attr_aggregator_set(aggregate, local_as, router_id);

[0309] return aggregate;

[0310] }

[0311] 5. The routing process has been modified. This part follows the constraints of RFC4271 and requires an extension to the original optimal path selection logic. Specific routing criteria for the agent service have been added to select routes based on the agent instance's health, load, and number of instances. This can be implemented using the following code:

[0312] int bgp_best_path_select(struct bgp_node *node) {

[0313] / / Existing selection criteria...

[0314] compare_as_path_length();

[0315] compare_origin();

[0316] compare_med();

[0317] / / Added SAFI=75 specific standard

[0318] if (node->safi == SAFI_AGENT_SERVICE) {

[0319] compare_service_health(); / / Compares the health status (0x4305)

[0320] compare_instance_count(); / / Compares the number of instances (0x4304)

[0321] compare_load_level(); / / Compares the load (0x43FD)

[0322] }

[0323] compare_router_id();

[0324] }

[0325] 6. The route reflector supports extensions. This part complies with RFC4456 constraints, requiring the route reflector to support SAFI=75 and have the ability to generate aggregated routes. This can be achieved through the following code:

[0326] / / Router reflector support for SAFI=75

[0327] int bgp_rr_reflect_agent_service(struct bgp *bgp, struct bgp_route *route,struct peer *from) {

[0328] / / 1. Check the cluster list to avoid loops

[0329] if (bgp_cluster_list_loop(route->attr->cluster_list)) {

[0330] return -1;

[0331] }

[0332] / / 2. Aggregation processing (if an aggregation strategy is configured)

[0333] if (should_aggregate(route)) {

[0334] struct bgp_route *aggregate = aggregate_routes(route);

[0335] bgp_rr_reflect_route(bgp, aggregate, from);

[0336] } else {

[0337] / / 3. Reflect the original route

[0338] bgp_rr_reflect_route(bgp, route, from);

[0339] }

[0340] }

[0341] Based on the above-described inventive concept and specific configuration method code examples, it is possible to extend the BGP protocol entity. Based on the extended BGP protocol, the intelligent agent service discovery method provided by this invention can be implemented. It should be understood that the specific implementation methods of the above-described BGP protocol stack extension are merely examples and are not intended to limit the scope of protection of this invention.

[0342] Compared with existing technologies, the agent service discovery method provided by this invention has the following advantages:

[0343] 1. The BGP routing table of this invention is very concise, containing only core routing information and minimal BGP messages. It can batch advertise multiple intelligent agent services, maximizing the efficiency of BGP routing. Furthermore, BGP routes do not include service metadata, so changes in service metadata will not cause BGP route changes.

[0344] 2. This invention successfully integrates distributed service discovery capabilities into the network infrastructure. Based on the existing "agent markets" built by different communities, a unified agent service discovery system is constructed between different communities (AS) through BGP routing, enabling agent instances in different communities to work together and achieving deep integration of network and services.

[0345] 3. Under the service discovery method architecture provided by this invention, intelligent agent service instances can independently evolve their APIs without affecting the BGP infrastructure. Different service types can use different self-describing protocols to provide consumers with rich and flexible metadata, supporting versioning and multi-protocol coexistence.

[0346] 4. The security of the business call process is ensured through a layered security mechanism. In this invention, the BGP routing itself does not expose sensitive API structure information. Instead, it controls access to self-describing API interfaces and business interfaces based on network policies during the service call process, effectively enhancing the security and reliability of service communication.

[0347] In the description of the embodiments of this application, the words "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the words "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a specific manner.

[0348] In the description of the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, B existing alone, and A and B existing simultaneously. Furthermore, unless otherwise stated, the term "multiple" means two or more.

[0349] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and their variations all mean "including but not limited to," unless otherwise specifically emphasized.

[0350] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for discovering cross-domain intelligent agent services, characterized in that, The method is implemented based on the BGP protocol and is executed by the service discovery gateway and route reflector of the First Autonomous Community (AS), including: The service discovery gateway of the first AS receives registration requests and / or heartbeat metrics from agent instances in the first AS; the heartbeat metrics include the real-time health and current load of the agent instance. The service discovery gateway of the first AS generates a detailed route containing instance information based on the registration request and / or heartbeat indicators, and sends it to the route reflector of the first AS; the instance information includes the service type and service port of the agent instance. The route reflector of the first AS aggregates multiple detailed routes with the same service type to generate an aggregated route; the aggregated route contains the agent service information of the first AS, which includes the gateway address of the service discovery gateway of the first AS, and the aggregated information obtained by aggregating the instance information from multiple detailed routes. The route reflector of the first AS sends the aggregated route to other ASs, enabling other ASs to obtain the agent service information and send an instance information query request to the service discovery gateway of the first AS based on the gateway address in the agent service information. The service discovery gateway of the first AS returns instance information to the second AS based on the instance information query request sent by the second AS, enabling the service consumer in the second AS to call the agent instance in the first AS based on the service port in the instance information.

2. The method according to claim 1, characterized in that, The registration request includes the service type, service port, self-describing protocol type, and security policy of the agent instance.

3. The method according to claim 1, characterized in that, The instance information also includes: the agent instance's self-describing protocol type, security policy, instance number, real-time health status, and current load; the detailed route includes NLRI and extended community attributes. The NLRI of the detailed route includes the agent instance's service type and IP address prefix, and the extended community attributes of the detailed route include the agent instance's service port, self-describing protocol type, security policy, instance number, real-time health status, and current load.

4. The method according to claim 3, characterized in that, The aggregated information includes: the public service type, public service port, public self-describing protocol type, public security policy of multiple agent instances, as well as the number of instances and the average health of the instances. The aggregated route includes Network Layer Reachability Information (NLRI) and extended community attributes. The NLRI of the aggregated route includes the public service type of the multiple agent instances. The extended community attributes of the aggregated route include the public service port, public self-describing protocol type, public security policy, the number of instances of the multiple agent instances, the average health of the instances, and the gateway address of the first AS service discovery gateway.

5. The method according to claim 1, characterized in that, Generate a detailed route containing instance information based on the registration request and / or heartbeat indicator, specifically including: encoding the instance information according to a preset encoding rule to obtain the detailed route.

6. The method according to claim 4, characterized in that, Multiple detailed routes with the same service type are aggregated to generate an aggregated route, specifically including: The IP address prefixes of the multiple detailed routes are aggregated based on Classless Inter-Domain Routes (CIDR) to obtain the IP address prefixes in the aggregated route NLRI; The public service type of the multiple detailed routes is used as the service type in the aggregated route NLRI; The number of the multiple detailed routes is used as the number of instances in the aggregated route extended community attribute; The real-time health scores of the multiple detailed routes are weighted and averaged, and the weighted average result is used as the average health score in the extended community attribute of the aggregated route.

7. The method according to claim 1, characterized in that, The instance information includes the security policy of the agent instance. The service consumer in the second AS calls the agent instance in the first AS according to the service port in the instance information, specifically including: The service consumer sends a self-describing interface query request that conforms to the security policy to the service port of the agent instance based on the service port and security policy in the instance information; The agent instance performs security verification on the query request of the self-describing interface according to the security policy. After the verification is successful, the instance returns complete metadata to the service consumer through the self-describing interface. The complete metadata includes the security requirements of the business interface. Based on the complete metadata, the service consumer sends a business function call request that meets the security requirements of the business interface to the service port of the intelligent agent instance; The agent instance performs business-level security verification on the call request. After successful verification, it executes the business logic and returns business data to the consumer.

8. A method for discovering cross-domain intelligent agent services, characterized in that, The method is implemented based on the BGP protocol and is executed by the service discovery gateway of the first autonomous system (AS), including: Receive the registration request and / or heartbeat metrics of the first AS agent instance; the heartbeat metrics include the real-time health and current load of the agent instance; Based on the registration request and / or heartbeat metrics, a detailed route containing instance information is generated and sent to the route reflector of the first AS. This causes the route reflector to aggregate multiple detailed routes with the same service type into an aggregated route, which is then sent to other ASs. These other ASs then obtain the agent service information and, based on the gateway address in the agent service information, send an instance information query request to the service discovery gateway of the first AS. The instance information includes the service type and service port of the agent instance. The aggregated route contains the agent service information of the first AS, including the gateway address of the first AS's service discovery gateway and aggregated information obtained by aggregating instance information from multiple detailed routes. The instance information is returned to the second AS based on the instance information query request sent by the second AS, so that the service consumer in the second AS can call the agent instance in the first AS according to the service port in the instance information.

9. A method for discovering cross-domain intelligent agent services, characterized in that, The method is implemented based on the BGP protocol and is executed by the route reflector of the first autonomous system (AS), including: Receive multiple detailed routes sent by the first AS service discovery gateway; each detailed route contains instance information of an agent instance; Multiple detailed routes are aggregated to generate an aggregated route containing the service information of the first AS agent; the service information of the agent includes the gateway address of the first AS service discovery gateway, and the aggregated information obtained by aggregating the instance information from multiple detailed routes. The aggregated route is sent to other ASs, causing the second AS to send an instance information query request to the service discovery gateway of the first AS based on the aggregated route; the service discovery gateway of the first AS returns instance information of multiple agent instances to the second AS based on the query request, and the service consumer in the second AS calls the agent instance in the first AS based on the instance information.

10. A method for discovering cross-domain intelligent agent services, characterized in that, The method is implemented based on the BGP protocol and is executed by the service discovery gateway of the second autonomous community (AS), including: Receive aggregated routes containing first AS agent service information; the agent service information includes the gateway address of the first AS service discovery gateway; Based on the gateway address in the intelligent agent service information, an instance information query request is sent to the service discovery gateway of the first AS. Receive instance information returned by the first AS, and construct a service catalog based on the instance information; The system receives a service request from a service consumer, the service request including service type, service quality requirements, service health, and load requirements; based on the service request, it queries the service directory according to service type, health, and load, and determines the agent instance that meets the service type, service health, and load requirements in the service request as the optimal agent instance, and sends the instance information of the optimal agent instance to the service consumer, so that the service consumer can invoke the optimal agent instance based on the instance information of the optimal agent instance.

Images