SPAN - Secure Private Access Network. A managed service that connected multiple user-facing service access points (aka Service Endpoints) to a set of destination endpoints that can be user-facing or can be a backhaul into a datacenter. For FLM (First-look Milestone) two types of SPANs will be supported:
- Point to point
- Inverted Tree (inverted tree with the root service as the KDR desitnation.)

A SPAN service has various functional entities that are typically implemented as a docker-compose service. See here for a pseudo-formal definition

KAR - Karousels Access Router. This is the ‘initiator’ endpoint of networking service. A SPAN starts at a KAR and ends at a KDR (Karousels Delivery Router - see below). A KAR may be point to point (one KAR/KDR pair) or multipoint (one KAR - terminating at mulitple possible KDR). It’s also possible to have multiple KARS terminating into one KDR

KDR - Karousels Delivery Router - the matching functional pair of KAR. The KAR to KDR path requires at least one intermediate router, HOPR (see below). The KAR to KDR communications happen over TCP using secure websockets. The wrapper between KAR and KDR is called an ‘Envelope’ (Karousels internal term) and the protocol of routing these envelopes are referred to as ‘Envelope Routing’.

HOPR - Hop-by-Hop Router. An intermediate router that serves as flow router for envelopes.

K9 - A watchdog service implemented as a docker container. In the architectural hierarchy - the K9 is in the category of a Component Application. A K9 is present in (almost) every self-standing SPAN service points and serve as the control/provisioning/fleet management point for SPAN and NESTs. The K9 customization sequence is as follows:

 1. A base K9 - this is container released in the flm.registry.karousels (for example)  
 2. A customized K9 - produced by Gitlab CI running on the customer repo (e.g. CustomerOne) and resides in the container registry of THAT customer  
 3. Runtime-K9-Config -  Is maintained in Hasura and specifies the config of a K9 for a specific applictation. (a diagram showing an example is coming)  

spanHead - For every SPAN there is a service entitey that represents an aggregation of certain provisioning and configuration information for that SPAN. There is at least one SpanHead per SPAN. THis is also the first SPAN endpoint that gets deployed, typically in the cloud. Deploying the SpanHead changes the operational state of the SPAN from ‘CREATED’ to ‘ANCHORED’, for example.

Ledger, SPAN-Ledger - Service that runs the SPAN ledger and controls deployment and operations at a ‘customer’-level

Service-side - aka User-side, client-side

Ledger-side - aka cloud-side

Envelope-Routing - coming

LANDING_SERVICE - Front-end service on api.ledger… endpoint

ZTR - Zero-trust Rider. A payload service that deploys customer’s payload (container) to may endpoints and then connects them together with a secure Layer-4 SPAN. Offered as a service. See the functional diagram of the Service endpoint HERE

NEST - Where SPAN end points are run. See the NESTS section else where on this site.

Service Function Containers