Skip to content

Latest commit

 

History

History
143 lines (125 loc) · 5.93 KB

Concepts.org

File metadata and controls

143 lines (125 loc) · 5.93 KB
Raw

Listeners

  • abstraction for an “ingress port”:
    • name: unique id
    • spec: a listening address specification (protocol + specific params)
    • rules: match-action rules to apply to connections
    • stats
  • emits sessions dynamically (when request arrives), applies the rule(s) successively until the first one matches, and applies the corresponding route settings:
    • singleton: emits a single session only
    • server: can emit multiple sessions
  • meta-listener: a “module” consisting of a listener plus one or more transforms that together behave as a single listener for, e.g., a complex protocol: UDP + RTP parser = RTP/UDP listener

Clusters

  • abstraction for an “egress port”:
    • name: unique id
    • spec: protocol and protocol-specific parameters valid for each endpoint
    • endpoints: possibly multiple endpoints (fan-out)
    • stats
  • a “drop” cluster can be defined for /dev/null
  • cluster-endpoint associations/descriptors are exposed to the control plane (rw):
    • endpoints: e.g., cluster is a k8s “service” and endpoint is the set of pods running the service
    • health-check: protocol-specific, supposedly in-band (TUN/TAP: BFD, WS: ping, TCP: keepalive, etc.)
    • circuit breaking (timeouts)
    • retries: configurable number of trials for ack’ed protocols
    • load-balancing: round-robin + deterministic (first endpoint always) + multicast (to a set of endpoints) + broadcast (all endpoints)
  • meta-cluster: a “module” consisting of one or more transforms plus a cluster that together behave as a single cluster for, e.g., a complex protocol: RTP deparser + UDP = RTP/UDP cluster

Sessions

  • abstraction for a single dataplane “flow”, the unit of routing and monitoring:
    • name: a unique protocol specific ID (e.g., IP 5-tuple for a TCP session)
    • metadata: user-defined metadata (set of transformers)
    • route: describes the sequence of transforms to be applied to the session, manipulated using rules
    • status: CONNECT/ESTABLISHED/DISCONNECT
    • stats:
  • the metadata and the route can be matched/rewritten using rules and session transforms
  • the session payload can be transformed using dgram/stream transforms, separately in the uplink/downlink direction
  • session ID may be communicated through a local/remote transformer in-band (HTTP/WebSocket headers) using an “json encap/decap” transformer
  • the data-plane maintains a complete inventory of sessions and the control plane can query and remove sessions (but it cannot create them directly, only indirectly via creating listeners that will themselves emit sessions asynchronously) and modify attributes (e.g., modifying the route should immediately re-route the session)

Rules

  • abstraction of dataplane “match-action” rules:
    • name: unique rule id, optional (set automatically) if rule occurs is inline (inside a listener), otherwise required
    • match: match-conditions on session id and metadata (optional, if missing then rule matches all sessions)
    • route: rewrite the session’s route list if the conditions match
    • action: modifications to the metadata and the route
  • semantics: matches on session IDs (and possibly other user defined per-session metadata) and rewrites metadata and/or assigns/modifies routes

Route

  • abstraction for the “forwarding policy” for a session (a session can have only one active route):
    • cluster: the endpoint of the route (starting point is the listener)
    • session: list of session transforms to apply during session setup/disconnect
    • ingress: list of stream/dgram transformers to be applied in the listener->cluster direction
    • egress: list of stream/dgram transformers to be applied in the cluster->listener direction
  • the route is exposed to the control plane and it can be modified dynamically: in that case the session should be rerouted immediately (but update model is “eventually consistent”)

Transform(er)s

  • abstraction for an “action”: transform a session metadata or payload:
    • name: unique id; if name matches the name of a cluster then a transform over that cluster is automatically created (if it has not already been created), otherwise name is mandatory
    • type: type of transform (some types are built-in)
    • params: parameters for the transform (optional)
  • may transform session metadata (called only during session setup/disconnect) or payload (stream/datagram)
  • can work either inline or remotely using a transform protocol cluster
    • local transform: runs inside the proxy
      • INLINE/stream: rewrite stream
      • INLINE/datagram: rewrite datagram stream
    • remote transformer: run the transformer in a remote pod in a “bump-in-the-wire” fashion, sending/receiving session descriptors via a transformer
  • meta-transform: a “module” consisting of one or more transforms that together behave as a single transform (example)

Modules

  • TODO

Control/Monitoring

  • static config read from a file on init
  • controller: a HTTP listener routed to the predefined “controller” cluster that accepts queries/updates from the control plane
  • monitor: a HTTP listener routed to the predefined “monitor_responder” cluster that accepts queries from Prometheus and outputs formatted stats

Status

Framework: clusters, listeners, routes, sessions, rules, object hierarchy

static config

UDP, WebSocket, and UDS stream/dgram protocols (c/l/t)

full wildcard match

session transforms

QUIC/HTTP3