Use Cases and Requirements of Communication Protocol for Troubleshooting Agents on Network Devices

3.1. Use Case 1: Data Center Network

In a large-scale data center network, multiple troubleshooting agents on network devices, such as switches and routers, need to collaboratively identify and diagnose a transient latency issue affecting application performance. The troubleshooting workflow begins when an application performance monitoring agent detects elevated response times and assign a diagnosis task to troubleshooting agents on network devices. The application performance monitoring agent also can reports this issue to the agent on the network controller, which then notifies troubleshooting agents on network devices to root the cause of this performance issue. The ways by which troubleshooting agents on network devices receive tasks is beyond the scope of this draft.¶

For this use case, a high-performance, low-cost communication protocol is required. In existing works, gRPC provides significant advantages for this scenario. This part takes gRPC as an example.¶

When a troubleshooting agent on the network device receives a task to identify, diagnose, and recover from network failures, the communication flow may same as this figure.¶

+--------------------+  1. establishes connection  +-----------------+
| +----------------+ +----------------------------->  +-----------+  |
| |                | | 2. request for related data |  |           |  |
| |Initiating Agent| +----------------------------->  |   Agent   |  |
| |                | |        3. response          |  |           |  |
| +----------------+ <-----------------------------+  +-----------+  |
|                    | 4. share analysis results   |    Relevant     |
|   Network Device   +-----------------------------> Network Devices |
+--------------------+                             +-----------------+

Figure: Data Center Networks¶

The communication flow includes these steps as follows. This document provides message examples for each step.¶

Step 1, the initiating agent establishes connections with relevant network device agents. This step may include some security-related steps and description about failure.¶

{
        "Sender": "Agent-I",
        "Failure":
        {
                "Location": "Host 1",
                "Type": "Packet loss rate greater than threshold",
                "Description": "...",
        },
        "Solution":
        {
        },
        "Analysis":
        {
        },
        ...
}

Step 2, through bidirectional connection, the initiator requests real-time telemetry data including interface statistics, queue depths, and latency measurements.¶

The request message of initiator could be as following.¶

{
        "Sender": "Agent-I",
        "Failure":
        {
                "Location": "Host 1",
                "Type": "Packet loss rate greater than threshold",
                "Description": "...",
        },
        "Solution":
        {
                "RelatedNetDevice1":
                {
                        "Type": "Request",
                        "Resource": "Data",
                        "Description": "Traffic patterns of the device's ingress and egress over a certain period of time.",
                        "TransMehtods": ["gRPC", "QUIC"]
                },
                "RelatedHost2":
                {
                        "Type": "Request",
                        "Resource": "Method",
                        "Description": "The device needs to send colored packets to collect path data."
                },
                ....
        },
        "Analysis":
        {
        },
        ...
}

Step 3, network agents respond with telemetry data in real-time. The related network device would send this message as response.¶

{
        "Sender": "Agent-D",
        "Response":
        {
                "Resource": "Data",
                "Data":
                {
                        "Description": "Traffic patterns of this device's ingress and egress over a certain period of time.",
                        "TransMethods": "gRPC",
                        ...
                }
                ....
        },
        ...
}

Step 4, optionally, the initiating agent share analysis results through the same channels, enabling collaborative root cause identification.¶

Step 5, once the root casue of the failure is identified, agents negotiate and implement traffic engineering adjustments.¶

3.2. Use Case 2: Campus Network

A network segmentation issue in an enterprise campus requires verification of consistent policy application across multiple security domains. Agents residing in firewalls, switches, and wireless controllers must collaboratively audit their configurations against intended policies to identify discrepancies causing the segmentation failure.¶

For this use case, a configuration-oriented troubleshooting scenario, HTTP-based RESTCONF offers several benefits. This part takes RESTCONF as an example. The RESTful architecture provides familiar, standardized operations (GET, PATCH, DELETE) for configuration manipulation. YANG data modeling ensures semantic consistency across multi-vendor environments, crucial for accurate policy verification. HTTP/2's header compression and request multiplexing improve efficiency when interacting with numerous agents simultaneously. The protocol's stateless nature simplifies error recovery, while standardized status codes and error responses enable predictable failure handling. Rich authentication mechanisms integrate seamlessly with existing enterprise security infrastructures. However, RESTCONF lacks streaming capabilities for real-time telemetry exchange.¶

In this use case, the agent who is informed to complete this task is named coordinator agent.¶

                     +-----------------------+
                     | +-------------------+ |
                     | |                   | |
                     | | Coordinator Agent | |4. process data
                     | |                   | |
                     | +-------------------+ |
                     |                       |
                     |     Network Device    |
                     +---^------+------------+
                         |      |1. establishes connections
                         |      |2. queries configuration data
         +---------------+------++------------------------+
         |               |       |5. pushes configuration adjustments
         |  3. response  +-------+---------------+        |
         |        +------+       |               |        |
+--------v--------+     ++-------v--------+     ++--------v-------+
|   +---------+   |     |   +---------+   |     |   +---------+   |
|   |  Agent  |   |     |   |  Agent  |   |     |   |  Agent  |   |
|   +---------+   |     |   +---------+   |     |   +---------+   |
|                 |     |                 |     |                 |
| Network Device  |     | Network Device  |     | Network Device  |
+-----------------+     +-----------------+     +-----------------+

Figure: Campus Networks¶

The communication flow includes these steps:¶

1. A coordinator agent establishes connections with relevant network agents.¶

2. The coordinator queries configuration data from multiple device agents using standardized YANG data models.¶

3. Each agent responds with structured configuration data representing its current operational state.¶

4. The coordinator analyzes the collective configuration data, identifies inconsistencies in access control lists and routing policies, and generates remediation instructions.¶

5. Using RESTCONF PATCH operations or other network management operations, the coordinator pushes configuration adjustments to specific agents.¶

6. Agents respond with structured error messages if operations fail, enabling precise fault localization.¶

3.3. Use Case 3: IoT Edge Network

In an IoT edge network, multiple constrained devices experience intermittent connectivity issues. Lightweight agents on these devices must efficiently share fault information and coordinate recovery actions while conserving bandwidth and battery resources.¶

In IoT network, MQTT protocol is used widely. This part takes MQTT as an example. MQTT's publish-subscribe model offers distinct advantages for distributed troubleshooting scenarios. The decoupled communication pattern allows agents to exchange information without direct connections, reducing coordination overhead. Configurable QoS levels enable reliability matching for different message. For example, types—QoS 0 for non-critical telemetry, QoS 1 for important fault notifications, and QoS 2 for critical configuration changes. The minimal protocol overhead conserves bandwidth and battery life on constrained devices. Last Will and Testament features ensure other agents are notified when a device becomes unreachable, enabling rapid detection of network partitions. The topic-based routing simplifies message filtering and delivery to interested parties only.¶

                                                       +----------------+
                                                       |    +-------+   |
                                                       |    | Agent |   |
                                                      ++    +-------+   |
                                                      || Network Device |
2. Identify faiulres  3.publish a failure report      |+----------------+
     +----------------+    +---------------+    1. Subscribe------------+
     |    +-------+   <----++-------------+<----------+|    +-------+   |
     |    | Agent |   |    || MQTT Broker ||          ++    | Agent |   |
     |    +-------+   |    |+-------------+|          ||    +-------+   |
     | Network Device |    | Network Edge  +---------->| Network Device |
     +-------------^--+    +---------------+4. Notification-------------+
                   |                                  |+----------------+
                   +----------------------------------++    +-------+   |
                 5. Offer related data and resources  ||    | Agent |   |
                                                      ++    +-------+   |
                                                       | Network Device |
                                                       +----------------+

Figure: IoT Edge Networks¶

The communication flow includes these steps:¶

1. Agents subscribe to relevant fault notification topics on an MQTT broker deployed at the network edge.¶

2. The agent on the network device which happened a network failure identifies the network failure.¶

3. Agent publishes a structured failure report to appropriate topics.¶

4. Subscribed agents receive the notification and contribute additional context from their perspectives.¶

5. The subscribed agents may offer some data and resources to diagnose or recover FROM this failure.¶

6. The agent on the network device that caused this failure recovers the failure or reports it.¶

4.1. Data Transport Requirement

{
        "Sender": "Agent",
        "Failure":
        {
                "Location": "..",
                "Type": "...",
                "Description": "...",
        },
        "Solution":
        {
        },
        "Analysis":
        {
        },
        ...
}

4.2. Protocol Implementation Requirements

4.3. Operational Requirements