Gap Analysis for the Cross-device Communication Protocol for AI Agents in Network Devices

Currently, network devices are able to exchange message with each other by some routing protocols (e.g. BGP, IS-IS, OSPF), or some signaling protocol (e.g. GRASP). In addition, they can interact with network controller by NETCONF, RESTCONF and gRPC. In AI Agent area, there are some popular protocols, such as A2A for interaction between agents and MCP for the interaction between agents and outer systems.

[Gap A01] The content of tasks in A2A protocol is typically described in natural language, and Message and Part objects of the text type in A2A protocol usually carry natural language text. That may require the deployment of large language models on network devices to parse the content of A2A request messages. However, deploying large models requires substantial AI computing capability, which current network devices cannot provide. This suggests that a structured or semi-structured message format or data model may need to be designed. [Gap A02] The asynchronous notification mechanism of A2A, which can be used by a server to notify a client that a long-running task has been completed, requires the client to provide a separate listening port or service path as a webhook. This extends the exposure surface of network devices and raises security risks. [Gap A03] The first method for A2A service discovery requires an agent to provide a well-known URL to enable other agents to obtain its Agent Card. This increases the exposure surface of network devices and raises security risks. In addition, A2A does not require the retrieval requests for Agent Card to be authenticated, which means that the information of network devices could be accessed by unauthorized users. This suggests that new security mechanisms or service discovery methods may need to be designed to address these security risks. [Gap A04] The second method for A2A service discovery requires deploying a registry in the network to store the Agent Cards of all network devices. This means that some network devices need to be selected or newly deployed, and configured to function as registries, similar to the BGP RR. This would lead to significant storage pressure on the device and increase deployment costs. Alternatively, this would require upgrading the network controller to function as a registry, which would cause frequent requests for Agent Cards from devices to the controller, putting additional load on the controller. If the Agent Cards are cached on the devices, there would also be issues of out-of-date cached data and increased storage pressure on the devices. [Gap A05] The third method for A2A service discovery requires configuring the Agent Cards of all other devices that will be accessed on the device itself. This would significantly increase the amount of configuration data and the maintenance workload of the network, and also greatly increase the storage pressure on network devices. [Gap A06] A2A currently does not mandate a common transport protocol, which allows any of HTTPS-JSON-RPC 2.0, gRPC, or HTTPS-JSON (restful API) to be used. This could actually lead to a situation where the agents in different network devices cannot communicate with each other because of using different transport protocols. This suggests that a standardized transport protocol that must be implemented may need to be specified, with other transport protocols being optional. [Gap A07] A2A requires that all messages be transmitted over HTTPS (citation: MUST be HTTPS). This means that each message needs to be encrypted or decrypted in network devices, which imposes additional performance overhead on the devices.

[Gap M01] MCP is typically used by agents to call external systems and is architecturally a north-south interface. However, the relationship among device agents is more like a "peer", similar to BGP peer and IS-IS peer. Their interaction may require an east-west interface. Nevertheless, from the perspective of information transfer and function calling, MCP is also worth considering in the scenario of the interaction of device agents. [Gap M02] MCP only supports JSON text as the data encoding format, which is less efficient in terms of information transmission and parsing compared to binary data encoding formats. This will consume more CPU time on devices for data serialization and deserialization, and occupy more bandwidth to exchange messages. [Gap M03] MCP allows the use of HTTP protocol stacks that support server-sent events (SSE) and streaming. The protocol stacks of network devices may need to be upgraded accordingly. If devices only support traditional request-response communication, some future functionalities may be limited or impossible to implement. [Gap M04] The names and descriptions of MCP tools are in natural language, which may require deploying large language models on network devices to understand the functions of each tool. Currently, the processing capabilities of network devices may be insufficient to meet this requirement. It may be necessary to define a standardized, structured description format or define a standardized tool ID.

TBD