Cluster¶
A SCION AS consists of one or more appliances that form a cluster to synchronize state. The appliances are the shards of the AS cluster and are referred to with a shard identifier. Each shard is an independent unit of the SCION AS and can function and fail independently of the other shards.
Note that this is an Anapaya-specific extension of how a SCION AS is internally implemented while fully adhering to the specification of the SCION protocol.
Note
An appliance can be configured to take part in several ASes for instance to connect to multiple isolation domains. Hence, an appliance can be a member of several AS clusters. In each of the clusters it is identified by a shard id that is unique within the cluster.
The shard ids of the appliance are configured in the scion.ases
section and
referenced in the peer’s cluster section.
Appliances synchronize two kinds of state:
- SCION control plane data
Consists of path segments and beacons that are used to construct the ASes path database. The synchronization of control data happens only within an AS and is performed by the SCION control service. The control service synchronizes its path segments and beacons with the control services of all peers whose addresses it learns from the topology information. This happens regardless of whether the topology information is statically configured or synchronized.
- Topology information
Consists of addresses of SCION control services, IP-in-SCION tunneling endpoints and information about SCION links to neighbors. The synchronization of topology information is configured in the
cluster
section. Topology information can be automatically synchronized or configured statically. In both cases, each cluster member is configured with a list of all of its peers.
SCION Control Plane Data Synchronization¶
SCION control plane data is synchronized by the control services. The local
control service addresses are configured in the scion.ases
section. Refer to
the documentation of the SCION section
for a detailed description of this section. The addresses of remote control
services are configured or synchronized through topology synchronization and no
additional configuration is required.
Topology Synchronization¶
The topology synchronization is configured in the cluster
section which has the following fields:
synchronization
Configures the synchronization endpoint of the appliance where topology information is served. If all peers in the cluster are configured statically this section does not need to be configured.
address
The
<host>:<port>
TCP address where topology information is served.node_synchronization_interval
Configures the interval between two consecutive topology synchronization attempts to the cluster peers.
peers
For every peer in the cluster, this section either statically configures the topology information or configures the endpoint for automatic synchronization. In case there is only a single appliance in the cluster, the list of peers is empty.
features
Configures features that are announced to the peers.
scion_rss
Configures whether the appliance announces support for SCION RSS to its peers. If the local host supports the SCION RSS feature, per default it will announce this to the peers.
The appliance uses the peer’s scion
and synchronization
fields to
decide whether to initiate topology synchronization with them. The scion
and
scion_tunneling
sections of the peer are mutually exclusive with its
synchronization
section. If the synchronization section is configured then
the topology is dynamically synchronized from the peer. If either the scion
section or the scion_tunneling
section is configured then no topology
synchronization is initiated with this peer.
Note
Even if topology synchronization is disabled the control service will still dynamically synchronize its SCION control plane data (beacons and path segments) with all control services that are configured as peers in the same AS.
Note
The decision to configure topology information statically or to enable synchronization should be the same for all peers.
Static Configuration¶
Note
Statically configuring the topology information is recommended for edge deployments where the configuration overhead is small and the topology does not change frequently.
For each statically configured peer the following fields need to be configured:
cluster.peers.scion.ases
Configures the peer’s ASes. Note, that this object should match the
scion.ases
section in the peer’s appliance configuration. Refer to the SCION section for an explanation of the analogous fields in thescion.ases
section. For each AS, configure the following fields:isd_as
control.address
shard_id
neighbors
neighbor_isd_as
relationship
interfaces
interface_id
next_hop
scion_mtu
cluster.peers.scion_tunneling
Configures how to reach the peer’s IP-in-SCION tunneling endpoint. This section should match the
scion_tunneling
section in the peer’s appliance configuration. Refer to the documentation of the documentation on the IP-in-SCION tunneling section for a description of the corresponding fields in the SCION tunneling section. In the section configure the following fields:ip
data_port
control_port
probe_port
allowed_interfaces
cluster.peers.features
Configures the features of the peer. The following fields can be configured:
scion_rss
Option to statically enable or disable SCION RSS for traffic forwarded to the peer. This must only be set to true if the peer supports the SCION RSS feature.
Static peer configuration
This example shows how to statically configure a peer’s topology information:
{
"cluster": {
"peers": [
{
"name": "peer 1",
"scion": {
"ases": [
{
"control": {
"address": "10.2.0.2:40001"
},
"isd_as": "1-ff00:1:2",
"neighbors": [
{
"interfaces": [
{
"interface_id": 2,
"next_hop": "10.2.0.2:31000",
}
],
"neighbor_isd_as": "1-ff00:1:1"
}
],
"shard_id": 2
}
]
},
"scion_tunneling": {
"endpoint": {
"allowed_interfaces": [
{
"isd_as": "1-ff00:1:2"
}
],
"control_port": 40201,
"data_port": 40200,
"ip": "10.2.0.2",
"probe_port": 40202,
}
},
"features": {
"scion_rss": true
}
}
]
}
}
Automatic Synchronization¶
Note
Automatic topology synchronization is recommended for appliances in core ASes. This way the configuration does not need to be updated when the topology changes for instance if a new SCION link is added.
To configure a peer for topology synchronization only the endpoint needs to be
configured through the synchronization.address
.
This field needs to match the cluster.synchronization.address
configured in
the peer’s appliance configuration.
Automatic topology synchronization
This example shows the configuration for automatic topology synchronization with two peers.
{
"cluster": {
"peers": [
{
"name": "peer 1",
"synchronization": {
"address": "10.1.0.3:42003"
}
},
{
"name": "peer 2",
"synchronization": {
"address": "10.1.0.2:42003"
}
}
],
"synchronization": {
"address": "10.1.0.1:42003",
"node_synchronization_interval": "10m"
}
}
}