Skip to content

Signaling & Session Routing

Signaling, Session Management & Routing

In OpenMesh, signaling is the bridge between semantic intent and active communication — it is the set of procedures by which agents discover each other, negotiate capabilities, establish sessions, and select optimal routes for message exchange.

Session management maintains the continuity, security, and performance of those exchanges, while routing determines how messages traverse the mesh in a policy-aware and trust-sensitive manner.

Signalling Layer

The signaling layer is used for meta-communication — exchanging information about how to communicate before any actual data is sent.

  • Core Functions:

  • Capability Discovery

    • Agents publish capability descriptors (e.g., supported protocols, transports, QoS modes, schema versions) via signaling topics or directory lookups.

  • Transport Negotiation

    • Agents agree on the optimal transport layer (WebSockets, gRPC, WebRTC, libp2p) based on latency, bandwidth, NAT/firewall constraints, and trust requirements.

  • Security Parameter Exchange

    • Session key agreement (e.g., X25519 or PQC hybrid key exchange).
    • Cipher suite negotiation for encryption and authentication.
    • Optional mutual attestation using trusted execution environment (TEE) proofs.

  • Protocol Version Alignment

    • Agents verify protocol compatibility and trigger schema/protocol negotiation & translation if mismatches are detected.

  • Session Contract Establishment

    • Defines QoS, retry policies, TTL, delivery guarantees, and policy constraints for the upcoming session.

Session Management

Once signaling completes, a session represents a logical communication channel between two or more agents. Sessions can be ephemeral (lasting seconds) or persistent (lasting weeks).

  • Session Lifecycle:

  • Establishment

    • Initiated via signaling topics or direct control messages.
    • May be unicast, multicast, or circle-scoped.

  • Binding to Transports

    • Sessions are transport-agnostic but bound to one or more underlying channels for actual data exchange.

  • State Tracking

    • Each session maintains context: participants, negotiated parameters, active protocols, outstanding requests, and timers.

  • Health Monitoring

    • Keep-alive messages, heartbeats, and path health checks to detect failures.
    • Automatic failover to alternate routes or transports.

  • Policy Enforcement

    • Rate limits, topic Access Control Lists, and trust thresholds applied continuously.
    • Violations may trigger warnings, throttling, or session termination.

  • Termination

    • Graceful closure with message acknowledgments.
    • Forced termination on policy violation, trust revocation, or resource exhaustion.

Routing Layer

Routing in OpenMesh is policy-aware, trust-sensitive, and topology-adaptive. It decides how messages traverse the mesh between agents, balancing performance, security, and compliance.

Routing Strategies:

  • Direct Routing
  • If a direct path exists and is policy-compliant, messages flow without intermediaries.

  • Useful for low-latency interactive sessions.

  • Relay-Based Routing

  • Messages hop through one or more relay nodes when direct paths are unavailable or undesirable.

  • Relays can provide store-and-forward persistence, encryption, or protocol bridging.

  • Multi-Path Routing

  • Critical or high-value messages may be sent simultaneously across multiple disjoint paths to ensure delivery even if one path fails.

  • Trust-Weighted Routing

  • Routes are selected based on trust scores derived from the Social Overlay Plane.

  • Higher-trust paths are favored, especially for sensitive or high-integrity messages.

  • Policy-Constrained Routing

  • Routing decisions must comply with domain-level governance rules.
  • e.g., data residency, jurisdictional restrictions, or contractual SLAs.

Routing Metadata & Path Selection

  • Routing metadata is embedded in the message envelope or maintained in the session context:

  • Preferred path class: low-latency, high-throughput, low-cost.

  • Trust anchors: relays or peers to avoid or prefer.
  • Geo/policy constraints: “must stay within EU,” “no routing through domain X.”

  • Fallback order: priority of alternate routes if primary path fails.

  • Path selection algorithms combine:

  • Network telemetry (latency, packet loss, throughput)

  • Gossip-based topology knowledge from the Control Plane
  • Trust metrics from the Social Overlay
  • Policy filters from domain manifests

Example

  • Market Coordination Protocol

  • Consider an open Multi-Agent System (MAS) for economic coordination — such as a decentralized marketplace where buyers and sellers negotiate contracts. OpenMesh enforces semantic rigor and validation at every interaction stage:

    1. Buyer Initiation
    2. Buyers publish a Request for Proposal (RFP) using the schema:
      • market/rfp@v1.0.0

    3. Schema ensures all RFPs have standardized fields like price range, quantity, delivery terms.

    4. Seller Response

    5. Sellers respond with proposals using:
    6. market/proposal@v1.0.0

    7. Ingress validation ensures the proposal is complete, matches buyer requirements, and complies with protocol rules.

    8. Negotiation Phase

    9. The proposal@v1.0 protocol state machine governs valid transitions: counteroffers, amendments, or withdrawals.

    10. Protocol enforcement prevents illogical moves (e.g., submitting a contract before proposal acceptance).

    11. Final Agreement

    12. Agreements are signed using the schema:
      • market/contract@v2.0.1

    13. This ensures contracts have the proper version, legal signatures, and binding clauses.

    14. Audit & Replay

    15. Every step — RFP, proposal, negotiation, contract — is validated, versioned, and logged.
    16. Enables post-event replay for dispute resolution, compliance checks, or performance audits.

  • Policy-Aware Session Establishment

  • agentA wants to send a high-priority contract proposal to agentB.

  • Signaling exchange determines:

    • Shared transport: QUIC
    • Protocol: proposal@v2.1 (no translation needed)
    • QoS: at-least-once delivery, TTL=10 minutes

  • Social Overlay reveals that one available relay in the shortest path has low trust.

  • Routing layer selects an alternate path via two high-trust relays, even though latency is slightly higher.

  • Session is established with:

    • End-to-end encryption
    • Session key rotation every 5 minutes
    • Jurisdiction-limited routing ("EU only")