Hybrid-Function-Chain (HFC) Framework

Introduction In the context of cloud native, applications are often no longer provided in the form of monolithic services, but are decomposed into a series of cloud native services deployed in distributed clusters, with inter-connections and joint provision to the outer side. Traffic lanes, for instance, have emerged and been commonly used for environmental isolation and traffic control of the entire request chain of services for grayscale publishing scenarios, would be reckoned as a typical example for Hybrid-Function-Chain (HFC). In fact, the creation of traffic lanes is still executed by various existing network API configurations of the cluster. The service routes are always configured in the cluster and identified endpoints under a service name to implement various scheduling strategies and perform load balancing schemes among multiple optional instances. Edge computing, as a distributed computing paradigm, the core idea is to make computing, storage and service processing as close to the clients and customers as possible to reduce latency, improve response speed and enhance data security. When applications are further deconstructed into atomic services as analyzed previously, service inter-connections MAY not only exist in adjacent clusters deployed in a same edge, but also happen with network paths connecting remote edge data centers. Thus, incremental requirements would be raised correspondingly. Relevant use cases and requirements are discussed in . Correspondingly, this draft proposes a Hybrid Function Chain (HFC) architecture aimed at providing end-to-end and consistent service provisioning capabilities which includes multiple service endpoints and corresponding connected network paths. Compared to conventional schemes and patterns, HFC is granted with multiple features and connotations. ( ( ) ) Request ( -- ) -------- \ +---+ \ ( ) \ Step 2 Step 3 +-- + \ ---- ( ) \ ( -- ) ( -- -- ) V ( ( ) ) ( ( )( ) ) ( -- )<------->( -- -- ... ) / -------- ( ) / +------------+ / Step 4 / ---- / ( -- ) / <----------- ( ( ) )V ( -- ) -------- Edge Clusters/Clouds Figure 1: HFC across Multi-edges ]]>

Hybrid service types and distributed forms: Considering the deployment phase, services and application functions can be deployed in one or multiple clusters in the form of containers, or deployed based on virtual machines. Service instances can be deployed with multiple instances with dynamic implementation and released based on a Serverless framework. Based on the run-time state, microservices and atomic functions form a diverse set of external services, and correspondingly, often raise various requirements for the resources and network capabilities. Compared to conventional Service Function Chain (SFC), the service functions targeted and discussed in HFC contains functions from both underlay network and application (L7) services.
Hybrid inter-connections between service instances: The inter- connection, interaction, and collaboration schemes between upstream and downstream functions are always allocated and implemented within various forms. For instance, upstream functions MAY propose unidirectional notifications. Bidirectional requests and responses MAY also be observed between upstream function and single or multiple downstream functions. Multiple inter-connection forms MAY be implemented simultaneously in an overall HFC.
Hybrid stacks and techniques: For conventional SFC in which Firewalls and Accelerators MAY be included, service functions are not tended and deployed to terminate data packets. However, for HFC functions, packets and payloads are always terminated at endpoints and payloads would be reorganized and regenerated. The provisioning of HFC process requires collaboration among multiple techniques and extends across TCP/IP stacks.

Based on the concepts of HFC proposed here, this draft further analyzes HFC framework and deconstructs it into several planes with incremental functions and features based on conventional network and service mesh techniques.

Conventions Used in This Document

Abbreviations

HFC: Hybrid Function Chain.
SFC: Service Function Chain.
QoE: Quality of Experience.
SLA: Service Level Agreement.
SRv6: Segment Routing over IPv6.
OAM: Operation, Administration and Maintenance.
APM: Application Performance Management.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Problem Statement

Problem 1: Dynamically Service Instances Management In cloud-native architectures, atomic service capabilities are typically deployed as virtualized applications across distributed cloud nodes, managed via container orchestration systems. Service Mesh has emerged as a predominant framework for distributed service management. In standard deployments, the Service Mesh control plane maintains visibility of service instances across multi-domain environments by storing and managing stateful records of Endpoint IP addresses. However, in cloud-native and edge computing scenarios, service instances representing atomic capabilities are dynamically instantiated and terminated across a vast number of edge nodes. This volatile behavior imposes significant overhead on the management plane. Every lifecycle event of a service instance (registration or deregistration) necessitates frequent updates to the centralized or distributed service registry. Furthermore, for the execution of Service Chaining at the application layer, if atomic services are concatenated solely based on IP identifiers, the Service Mesh infrastructure must guarantee continuous accuracy of these dynamic Endpoints. Given the potential for millions of concurrent, short-lived microservice events across the network, the resource requirements for maintaining such a high-frequency update state become a critical bottleneck for server-side management entities.

Problem 2: Service Routing Determination without Network State Awaring/Limitations of Current Service Scheduling Current microservice scheduling mechanisms, particularly in cross- cluster scenarios (e.g., Service Mesh architectures), primarily rely on the Control Plane to determine service routing for endpoints. These routing decisions are typically enforced through static configurations of target services across clusters via network APIs. However, a significant gap exists because the Service Mesh Control Plane lacks real-time visibility into the underlying network connectivity states between distributed services. In environments with redundant service instances, the originating endpoint remains unaware of potential differentiated service chains that may exist in the data plane. Consequently, the system cannot leverage optimized scheduling heuristics to select the most efficient path. This lack of dynamic, network-aware path selection prevents the infrastructure from providing deterministic end-to-end Service Level Agreement (SLA) guarantees.

Problem 3: Consistent End-to-end SLA Guarantee In traditional Layer 3 (L3) Service Function Chaining (SFC), packets traversing various Service Function (SF) endpoints are processed without terminating the underlying transport protocol. Consequently, the essential attributes and metadata of the packet are preserved across the chain, allowing for the consistent enforcement of the original steering and scheduling policies. Conversely, in Layer 7 (L7) service chain processing, the application-layer proxy or service instance terminates the incoming packet entirely upon reception. Following the execution of local service logic, a new packet is generated and encapsulated for transmission to the subsequent service node. This termination results in the loss of original flow context and scheduling metadata. As a result, the initial scheduling policy cannot be transparently reapplied to the newly instantiated packet, leading to a fragmentation of the control logic. This architectural limitation manifests as a lack of cohesive, end-to-end scheduling consistency across the entire service path.

Hybrid-Function-Chain Use Cases

Case 1: Traffic lane used in RAG service chain over multiple clusters In an enterprise-grade global intelligent Q&A platform, the core RAG service is decomposed into three sequentially executed microservices deployed across geographically distributed data centers: Service A (Retrieval Service), Service B (Prompt Synthesis Service), and Service C (LLM Generation Service). These three services form a complete service chain A -> B -> C. User query requests have differentiated requirements for the end-to-end performance of this entire chain based on business type: real-time conversations demand ultra-low latency, while in-depth analysis tolerates higher latency but requires guaranteed bandwidth for large-volume data transfer. Scenario Description: To meet these differentiated requirements, the operations team utilizes the HFC framework to define two global, end-to-end traffic lane strategies. Each strategy specifies a unified resource and network SLA preference for the entire three-node service chain A->B->C: 1) Low-Latency Chain Lane (low-latency-chain): Designed for real-time conversations. Policy Requirement: The end-to-end processing latency of the service chain A->B->C must be under 300 milliseconds. Therefore, this lane policy mandates: a) Service Instance Selection: Priority scheduling to lightweight instances of Services A, B, and C deployed in edge clusters closest to the user. b) Network Path Requirement: All inter-node network connections between Service A and Service B, and between Service B and Service C (whether cross-cluster or not), must use low-latency dedicated network links. 2) High-Throughput Chain Lane (high-throughput-chain): Designed for in-depth analysis. Policy Requirement: The service chain needs to process and transmit large volumes of retrieved context and generated content. Therefore, this lane policy mandates: End-to-End Orchestration Flow under the HFC Framework: 1) Traffic Identification and Tagging: The API Gateway in City-A identifies the service type based on request characteristics (e.g., path or headers) and marks the request with the corresponding HFC lane identifier, e.g., x-hfc-chain-sla: low-latency. 2) Unified Path Calculation: The HFC Control Plane, upon receiving the tagged request, treats it as an integral chain requiring sequential execution of A->B->C. Based on the lane policy and real-time resource status, the control plane calculates a complete path covering all three service nodes and the network segments between them in one go. Every hop of this path (A instance, A-B network link, B instance, B-C network link, C instance) adheres to the SLA requirements of that lane. 3) Chained Path Encapsulation and Execution: The HFC Control Plane delivers the calculated complete path (likely encoded as an SRv6 Segment List containing multiple service SIDs and network SIDs) to the HFC Gateway in City-A. The gateway encapsulates this path into the outbound packet.

Traffic is first directed to the lane-specified Service A instance.
After Service A completes processing, its HFC proxy, following the path information in the packet, steers the traffic via the specified low-latency or high-bandwidth link to the Service B instance.
After Service B completes processing, its HFC proxy similarly guides the traffic to the Service C instance via the specified next-hop link based on the path information.

4) Full-Chain Observability and Assurance: HFC's observability system tracks the request's entire journey through A ->(A-B network) - B -> (B-C network) -> C, collecting metrics at each stage to verify whether the entire chain meets the preset end-to-end SLA objectives. In this manner, the HFC framework ensures that the complete path from the first service node to the last conforms to the network transmission quality required by the business, achieving fine-grained, SLA-aware global traffic governance for chained microservice architectures.

Case 2: Adaptive Link Scheduling Pipeline for Intelligent Video Enhancement Based on Agent Mesh and HFC In a cloud-edge collaborative video content enhancement platform driven by an Agent Mesh (intelligent agent collaboration network), the core processing workflow is designed as a fixed-sequence serial service chain, collaboratively executed by multiple intelligent agents, consisting of three processing nodes:

Node A: Video Preprocessing Agent (Responsible for decoding, denoising, basic quality analysis).
Node B: Intelligent Enhancement Agent (Responsible for core algorithm processing, e.g., super-resolution, HDR).
Node C: Post-processing and Packaging Agent (Responsible for composition, encoding, and output packaging).

These three nodes, deployed as independent agents in geographically distributed data centers (e.g., Node A at the edge, Node B in the regional cloud, Node C in the central cloud), are coordinated by the Agent Mesh to form a cross-cluster end-to-end processing chain A -> B -> C. Core of the Scenario: The video stream must sequentially pass through agent nodes A, B, and C. However, for the two network transmission links - from Node A to Node B and from Node B to Node C - there are two options available for each: a High-Throughput link and a Low-Latency link. The system's intelligence lies in the Agent Mesh comprehensively analyzing the real-time processing status reported by each agent, making link selection decisions, which are then accurately executed by the HFC framework. This enables dynamic scheduling of the most suitable network link for each "node-to-node" transmission segment. Dynamic Scheduling Example: 1) Agent Sensing and Decision: The video stream enters Node A (Video Preprocessing Agent) for processing. This agent reports its analysis results (e.g., {frame _complexity: high, data_volume: large}) in real-time to the Agent Mesh. The Agent Mesh makes a comprehensive judgment and decides: the transmission from Node A to Node B needs to prioritize the stable transfer of large data volumes, with less emphasis on ultra-low latency. Therefore, the Agent Mesh issues an instruction via the HFC Administration Plane: "For segment A to B, use the High-Throughput link." 2) HFC Policy Execution: The HFC Control Plane receives this instruction. At the egress of Node A, it steers the traffic onto the High-Throughput backbone network instead of the low-latency private line, ensuring efficient delivery of massive intermediate data to Node B. 3) In-Chain Continuous Optimization: After Node B (Intelligent Enhancement Agent) completes processing, it reports its new status (e.g., {data_volume: medium, realtime_requirement: high}) to the system. Based on this, the Agent Mesh performs a new round of judgment: the transmission from Node B to Node C becomes critically dependent on low latency to guarantee the real-time nature of the final output. Consequently, the Agent Mesh issues a new instruction: "For segment B to C, switch to the Low-Latency link." 4) HFC Dynamic Reconfiguration: The HFC Control Plane responds to the instruction. At the egress of Node B, it dynamically switches the traffic path from the default link to the Low-Latency private line, ensuring rapid data arrival at Node C for final packaging. Summary: In this scenario, the topology of the service chain (A->B->C) is fixed. However, the "road quality" (network SLA) on the links is intelligently decided by the Agent Mesh based on real-time sensing and dynamically scheduled by the HFC. Their collaboration implements a fine-grained management model of "static nodes, dynamic links", ensuring the end-to-end performance of the entire processing chain is always optimal.

Hybrid-Function-Chain (HFC) Framework Hybrid-Function-Chain (HFC) framework generally includes administration plane, control plane and forwarding plane. Based on conventional framework of network and cloud native practices, several incremental functions and features are added and deployed.

Administration Plane Service Analysis and Operation: The increasingly complex and diverse applications and services display different characteristics and features for outer users. In terms of orchestration for distributed micro-services, Service Analysis and Operation interprets the external and internal forms of overall applications and services as corresponding deconstruction patterns.

Deep learning: The overall deep learning process would be decomposed into several successive or related phases and steps, data pre-processing, model training, prediction and estimation, model evaluation based on rewards functions, data storage and API interactions for instance.
Live Broadcast: Relevant micro-services MAY include user authentication, live stream administration, live recording, online payment and data migration.

The above deconstructed microservices have serial, parallel, unidirectional, and bidirectional relationships, and their interconnection and collaboration are comprehensively presented as user and outer oriented applications. Service Evaluation and Modeling: There are different and various resource requirements raised by multiple microservices, including but not limited to:

Computing resources and network capabilities: Computing-related services MAY be sensitive to computing resources, related indicators include CPU cores, available memories, floating number calculation. On the other hand, large amount of data transmission MAY be implemented between upstream and downstream services. Thus, the network connecting them would have to reserve sufficient bandwidth and provide abilities of low packet loss rate.
Constraints for inter-connection patterns: the inter-connection patterns between upstream and downstream services and functions MAY be classified as unidirectional, bidirectional, one-to-one and one-to-many. Furthermore, due to security concerns for instance, relevant services MAY be deployed at adjacent endpoints or a same edge center geographically.

( ( ) ) ( -- ) ( -- ) -------- -------- Notification ---- ---- ( -- ) ( -- ) ( ( ) )<------------->( ( ) ) ( -- ) ( -- ) -------- -------- Request and Response ---- ---- ( -- ) ( -- ) ( ( ) )-------------> ( ( ) ) ( -- ) \ ( -- ) -------- \ -------- \ \ ---- \ ( -- ) --->( ( ) ) ( -- ) -------- One-to-Many +---+ ( ) +-- + ( ) ( -- -- ) ( ( )-->( )--)-------> ( -- -- ) ( ) +------------+ Successive Services at same Location Figure 3: Inter-Connection between Services and Functions ]]> Service Orchestration and Scheduling: Service administration would customize strategies or specific algorithms depending on circumstances of infrastructure and required proposals. Providing low-latency experiences or achieving load balance among available instances and resources SHOULD be selected as specific inclinations for further scheduling.

Control Plane Service Registration and Administration: Based on the results and conclusions analyzed by Service Analysis and Operation, the overall service and included micro-services MAY be represented and administered by corresponding identifications. In this draft, Service IDs for micro-services and HFC IDs for HFC processes and services are generally defined. Therefore, HFCs and corresponding micro-services would be displayed and labeled in the control plane. Appropriate identifications would facilitate indicating the service traffic of the workflow. ( ( ) ) ( -- ) HFC ID, -------- \ Service 1(Pre) Service 1 \ Service 2(Next) \ \ ---- ---- \ ( -- ) ( -- ) v ( ( ) ) ( ( ) ) ( -- )<--------->( -- ) / -------- -------- / Service 2 Service 3 / / ---- / HFC ID, ( -- ) / Service 2(Pre) <----------- ( ( ) )v Service 4(Next) ( -- ) -------- Service 4 Figure 4: Service Administration by Identification ]]> Service Discovery and Publication: Depending existing and mature control plane protocols and interfaces, distributed services and capabilities of infrastructures SHOULD be able to be collected. Relevant schemes include extended IGP, BGP, BGP-LS, RESTful, Telemetry. The information learned in the control plane MAY include:

Computing resources related to services of specific instances.
Deployment of service instances or possible and scheduled resources utilization.
Network topology and corresponding TE capabilities.

Service Routes Calculation and Generation: Based on the information collected in Service Discovery and Publication, service routes would be calculated to determine appropriate instances and forwarding paths. Service Routes Calculation and Generation SHOULD follow the intentions identified in Service Orchestration and Scheduling. According to Service Registration and Administration, service routes could be distributed and indexed by HFC and service identifications. Service Inter-connection Configuration: Within conventional schemes for services inter-connection, configurations would be disposed for endpoints distributed in multiple clusters. Istio, for instance, replys APIs including ServiceEntry, VirtualService and DestinationRules to describe inter-connections and relevant principles. Considering the framework of HFC proposed in this draft, service routes would be translated into corresponding configurations issued to clusters for revising API files.

Forwarding Plane Service Identification Administration: Traffic would be able to be steered according to identifications distributed from the control plane. Also, the service identifications would inherit and re- generate from the previous ones in the workflow. Proxies, sidecars or gateways SHOULD be able to administer the inheritance and renewal relationship. Suppose an HFC application includes Service ID 1, ID 2 and ID 3, an identifier of {HFC, Service ID 2} implies that the successive function is expected to be Service ID 3. Correspondingly, the identifier would be modified as {HFC, Service ID 3}. Service Aware Forwarding: Service routes entries would be distributed from the control plane and involved entities and devices would perform traffic forwarding accordingly. Relevant entries include:

Service aware forwarding entries for edges routers in which forwarding paths are indexed by HFC IDs and Service IDs.
Service identification administration entries for sidecars, proxies and gateways in which inheritance and correlations would be specified.

Service provisioning and observability: By implementing and performing OAM or APM schemes, forwarding plane would monitor the circumstances and performance of traffic flows. With detections of failures and possible degradations, forwarding plane would be able to support recovering, enhancing and provisioning for traffic flows.

SRv6-based HFC Implementation Based on SRv6, forwarding paths orchestrated for an end-to-end HFC service including specific implementations would be able to be encoded in an SRH, in order to achieve consistent service provisioning across multiple endpoints deployed in distributed clusters and even edge clouds. The overall paths would be explicitly indicated in the Segment List or be generally displayed. Correspondingly, a strict mode and a loose mode are proposed in this draft.

When a service request accesses a corresponding application gateway, the service is identified as an HFC service agreed and dealed in a previous contract. Suppose the HFC service is decomposed into micro-services A, B and C. The HFC service is named with an identification, HFC ID. To process and fulfill the HFC service, the traffic would be steered to an access HFC gateway with packets carrying HFC ID and Service ID list. The endpoint for this HFC service would be configured as an SRv6 SID at the access gateway.
The access gateway identifies the HFC ID and Service ID list carried in the packet according to the SID filled in the destination field. Indexed by HFC ID and next Service ID (Initial Service ID), an HFC policy would be determined. Segment List of the HFC policy would be encoded to the packet with an Insert or Encapsulation pattern. Under a strict HFC mode for instance, Service SIDs for each HFC gateway and binding SIDs for interconnected forwarding paths would be included in the Segment List. Afterwards, the traffic would be steered to next HFC gateway.
With above displayed, HFC GW A is the first passing stand. HFC GW A would identify the next Service ID in the packet and implement a local lookup according to a Service SID. Therefore, the traffic would be steered into a local or adjacent edge cluster. Furthermore, HFC GW A MAY remove the SRHs and record the segment list and segment left in a local cache.
When a flow aiming to a target service instance, a service pod for instance, it would be intercepted by a proxy or sidecar. The proxy or sidecar records the HFC ID and next Service ID in the packets and identifies returning traffic accordingly. Based on the HFC service lists, next service would be determined and its Service ID would overwrite the original one.
Since the traffic flow returns to HFC GW A, an original segment list and relevant information would be re-attatched according to the records in the local cache. Afterwards, the traffic would be steered to next HFC GW similarly.

In the above SRv6 based HFC implementation, several SRv6 SIDs MAY be generally defined in this draft:

HFC Service SID: correlates with an HFC service forwarding table indexed by HFC ID and next Service ID, aiming to determine a forwarding path indicated by segment lists.
HFC Cache SID: correlates with an HFC local forwarding table and local cache table, aiming to record the forwarding information in the cache and forward the traffic to a local endpoint.
HFC Inherit SID: correlated with an HFC local cache table, aiming to determine and re-attach a matched original forwarding path.

Furthermore, SRv6 based HFC SHOULD support other features. For instance, backup paths would be orchestrated and accordingly configured at HFC GWs. End-to-end service observability would be achieved by distributed tracing and relevant schemes. More detailed implementation designs would be discussed in future works.

Agent Task Chain Collaboration Architecture based on Agent Mesh and HFC

Introduction and Background With the advancement of Artificial Intelligence (AI) technologies, enterprise applications are evolving from single-agent pilot projects to large-scale deployment of multi-agent systems. Complex business processes now require the collaboration of numerous heterogeneous agents, which may be built on different Large Language Models (LLMs), deployed across cloud and edge environments, and serve distinct business domains. Efficiently organizing these agents into a dynamic, reliable, and orchestratable "Agent Task Chain" presents a fundamental challenge for next-generation infrastructure. Agent Mesh has emerged as a novel "cognitive collaboration layer" , excelling in semantic-level tasks such as intent understanding, capability matching, collaborative workflow orchestration, and governance of token costs and hallucination risks among agents. However, Agent Mesh inherently lacks awareness and control over the underlying network and computing resources. In complex network environments spanning multiple data centers and edge nodes, it struggles to guarantee the end-to-end performance and reliability of a task chain. The Hybrid Function Chain (HFC) framework, with its proven ability to orchestrate "computing and network integration," fills this gap. The administration, control, and forwarding planes of HFC provide deterministic, high-performance, end-to-end path assurance for microservices. This section explores how to deeply integrate the "cognitive decision-making" of Agent Mesh with the "computing- network assurance" of HFC to construct a novel collaborative architecture for Agent Task Chains, enabling seamless transition from "intent understanding" to "path execution."

Core Collaborative Paradigm: "Cognition-Decision" and "Compute-Network-Execution" The core concept of this architecture is to treat Agent Mesh and HFC as two decoupled yet synergistic layers:

Agent Mesh (Cognitive Decision Layer): Acts as the "business brain." It is responsible for understanding high-level user or system intents, decomposing complex tasks into an ordered sequence of logical agent sub-tasks. It manages the agent capability graph, collaboration workflows, Service Level Agreement (SLA) policies (e.g., prioritizing cost, latency, or accuracy), and semantic-level affairs like token consumption.
HFC (Compute-Network Execution Layer): Acts as the "infrastructure backbone." It is responsible for mapping the logical "Agent Task Chain" received from Agent Mesh into a concrete, executable "Service Chain." Leveraging real-time awareness of compute resources (CPU/GPU load) and network states (bandwidth, latency, link quality), HFC selects the optimal compute instances and network paths for each hop within the task chain (from Agent to Agent), providing end-to-end deterministic assurance.

The collaborative workflow is illustrated in Figure 7 and described below: B -> C) | | | v | (2) Strategy Translation | & SLA Passing | | | +--------------------------->| (3) Compute-Network Resource Orchestration | v (4) Dynamic Traffic Steering & Execution | |<---------------------------+ (5) Status Feedback & Closed-loop Optimization Figure 7: Agent Mesh and HFC Collaborative Workflow ]]>

Intent Decomposition and Task Chain Generation: Agent Mesh receives a user request and decomposes it into a logical task chain, e.g., Agent_A -> Agent_B -> Agent_C. It defines SLA targets for each segment, such as "end-to-end latency < 200ms" or "throughput > 1Gbps for the A->B segment."
Strategy Translation and Path Calculation: Agent Mesh passes the logical task chain and its associated SLA targets to the HFC Administration Plane via a standardized interface. The HFC Administration Plane translates these business-level intents into network-level policies and triggers the Control Plane for computation.
Compute-Network Resource Orchestration: The HFC Control Plane, leveraging real-time compute and network telemetry, calculates the optimal instances and forwarding paths for each segment of the task chain. For instance, it might schedule the latency- sensitive Agent_A to an edge node and assign a low-latency dedicated link for the A->B transmission.
Dynamic Traffic Steering and Execution: The HFC Forwarding Plane, using technologies like SRv6, encapsulates the computed path information into data packets, precisely steering the inter-agent traffic along the predetermined route.
Status Feedback and Closed-loop Optimization: During execution, HFC feeds real-time network and compute performance metrics back to Agent Mesh. Based on this feedback, Agent Mesh can dynamically adjust the SLA policies for subsequent tasks or trigger task re-scheduling, forming a closed-loop optimization.

Enhanced Requirements for HFC Planes To realize the aforementioned collaborative architecture, the HFC framework requires enhancements in its administration, control, and forwarding planes to accommodate the dynamic and semantic nature of Agent Task Chains.

Administration Plane Enhancements: From "Service Chain Orchestration" to "Agent Task Chain Orchestration" The Administration Plane needs to extend its top-level abstraction from managing static microservices to managing dynamic, semantic- rich agent tasks.

Agent Capability Metadata Modeling and Integration: Current State: The Administration Plane primarily manages microservice identifiers (Service IDs), ports, and health check configurations. Enhancement: Introduce standardized interfaces to receive agent capability metadata from Agent Mesh. This metadata includes skill tags (e.g., "flight-booking", "video-enhancer"), applicable scenarios, required compute specifications (e.g., GPU model, VRAM), supported input/output formats, etc. This metadata serves as crucial input for task chain modeling and subsequent agent instance selection.
End-to-End Task Chain SLA Definition: Current State: SLAs are typically defined for individual services or single links between services (e.g., "latency between A and B < 10ms"). Enhancement: Support defining "end-to-end task chain SLAs," e.g., "total latency for the entire Agent_A->Agent_B->Agent_C chain < 500ms." The Administration Plane must decompose this global SLA into local constraints for each sub-task and network segment, ensuring the decomposed policies are conflict-free.
Cross-Layer Policy Coordination and Conflict Resolution: Current State: Policies are primarily defined by network operators. Enhancement: Establish a policy negotiation mechanism with Agent Mesh. For example, Agent Mesh might define a "token budget," while the HFC Administration Plane defines a "bandwidth cap." If a high-precision agent requires more tokens (and thus more bandwidth) than the budget allows, the Administration Plane must possess conflict detection and arbitration capabilities, or escalate the issue for manual intervention.
Converged Observability Analysis: Current State: Observability focuses on network metrics (latency, packet loss) and some service metrics (request count, error rate). Enhancement: Build cross-layer metric correlation analysis capabilities. Correlate business-level metrics from Agent Mesh (e.g., task completion rate, agent inference confidence, token consumption) with network-level metrics from HFC (e.g., actual latency of a specific link, jitter). This facilitates rapid root cause analysis, distinguishing between an agent's inference error and a network-induced timeout.

Control Plane Enhancements: From "Static Service Routing" to "Dynamic Task-Aware Routing" The Control Plane needs to evolve from passive response to active perception to handle the dynamism and uncertainty of Agent Task Chains.

Adaptation to Dynamic Agent Registration: Current State: Service instance registration is relatively stable with moderate change frequency. Enhancement: Agent instances may have very short lifecycles (e.g., a serverless agent started on-demand), leading to high registration/deregistration frequency. The Control Plane must optimize its service registration module to handle high-volume, high-frequency events while maintaining the consistency and availability of the service discovery table.
Support for Semantic Routing based on Logical Names: Current State: Service discovery relies on a Service Name and a clear list of Endpoint IPs. Enhancement: The target agent in a task chain from Agent Mesh may be a logical name (e.g., "best-video-enhancer"). The Control Plane must resolve this logical name into a list of healthy, qualified agent instances. The resolution criteria should include not only traditional load metrics but also the agent capability metadata obtained from the Administration Plane (e.g., "supports HDR enhancement").
Route Computation for Long-lived Connections and Streaming Traffic: Current State: Route computation is primarily designed for short-lived, request-response HTTP/RPC calls. Enhancement: Inter-agent communication, especially with LLM inference engines, often uses long-lived connections and streaming protocols like SSE and WebSocket. The Control Plane must consider the sustained load-bearing capacity and stability of links when computing routes, avoiding scheduling such traffic to bandwidth-limited or jittery paths. Furthermore, it must support session-based affinity routing to ensure that multi-turn dialogues of the same task traverse the same path, maintaining context consistency.
Dynamic Connection Parameter Injection: Current State: Connection parameters (timeouts, buffer sizes) are usually statically configured. Enhancement: The Control Plane should dynamically inject adapted parameters for agent-to-agent connections. For instance, it can inject longer response timeouts and larger message buffers for LLM inference tasks, or inject necessary JWT tokens or mTLS certificate configurations for agent authentication.

Forwarding Plane Enhancements: From "Best-Effort Forwarding" to "Task-Level Assured Forwarding" The Forwarding Plane needs to provide more granular, task-level assurance while maintaining high-performance forwarding.

Transparent Propagation and Management of Task Identifiers: Current State: The Forwarding Plane primarily handles network and transport layer identifiers (e.g., 5-tuple, VLAN). Enhancement: Support transparent propagation of task-level identifiers (TaskID, SessionID) injected by Agent Mesh within data packets. This allows network-layer performance data (e.g., per-hop latency, packet loss) to be correlated with specific business tasks, providing the foundation for the Administration Plane's cross-layer observability analysis. These identifiers must be correctly inherited and preserved even after protocol termination and reconstruction by L7 proxies.
Forwarding Strategies Adapted to New Traffic Patterns: Current State: Load balancing strategies are based on round- robin, least connections, etc. Enhancement:
- Streaming Data Chunk Forwarding: For SSE streams, support immediate forwarding of data chunks without waiting for the entire response, reducing end-to-end Time to First Byte (TTFB).
- Reliable Large Message Transmission: Optimize buffer management and reassembly strategies to handle potentially multi-megabyte context data passed between agents, preventing truncation due to buffer overflow.
- Session-Based Affinity Load Balancing: Ensure that all requests with the same Session ID are consistently routed to the same backend agent instance to maintain dialogue context.
Enhanced Service Assurance and Observability: Current State: Health checks mainly probe TCP port liveness. Enhancement:
- Long-lived Connection Health Monitoring: For connections like WebSocket, implement capabilities to detect half-open connections and application-layer heartbeats, promptly identifying and isolating stale connections.
- Granular Streaming Metrics Collection: In addition to standard latency and throughput, collect metrics such as TTFB, stream interruption count, and instantaneous rate fluctuations. This provides richer data for evaluating the user experience of Agent Task Chains.
- Task-Level Alert Correlation: When the network layer detects performance degradation for a specific task chain, it can send an alert to Agent Mesh, triggering task re- scheduling or graceful degradation.

Security Considerations To be discussed in future versions of this document.

Acknowledgements TBA.

IANA Considerations TBA.