Communications of the ACM

Figure 2b outlines one possible intra-domain path through the magnified AS.

Data plane. While the control plane is responsible for providing end-to-end paths, the data plane ensures packet forwarding using the provided paths. A SCION packet minimally contains a path; source and destination addresses are optional in case the packet’s context is unambiguous without addresses. Consequently, SCION border routers forward packets to the next AS based on the AS-level path in the packet header (augmented with ingress and egress interface identifiers for each AS) without having to inspect the destination address and also without consulting a routing table. Only the border router at the destination AS needs to inspect the destination address or packet purpose to be able to forward it to the appropriate local host(s).

An interesting aspect of forwarding is enabled by the split of “locator” (the path toward the destination AS) and “identifier” (the destination address); 13 since only the destination AS needs to consider the local identifier, the identifier can have any format the destination can interpret. A domain can thus select an arbitrary addressing format for its hosts (such as a 4B IPv4, 6B medium access control, 16B IPv6, 20B accountable IP, and AIP3). A nice consequence is that an IPv4 host can communicate with an IPv6 host directly through SCION.

Routers forward packets efficiently in the SCION architecture. In particular, absence of inter-domain routing tables and absence of complex longest-prefix matching performed by current routers enable construction of faster, more-energy-efficient routers. During forwarding, a border router first verifies that the packet entered through the correct ingress interface. If the packet has not yet reached the destination AS, the egress interface maps out the next hop.

Path combination. End-to-end communication in SCION is enabled by a combination of up to three path segments that form a SCION forwarding path. After path lookup, and depending on the returned segments, a forwarding path can be created as follows:

˲ Immediate combination of path
segments (such as B → D in Figure 2a).
the last AS on the up-segment (ending
“Policy compliance” refers to the re-
quirement that the path adheres to the
AS’s routing policy. Based on past PCBs
that were sent, a beacon server scores
the current set of candidate path seg-
ments and sends the k best segments as
the next PCB. SCION intra-ISD beacon-
ing can scale to networks of arbitrary
size because each inter-AS link carries
the same number of PCBs regardless of
the number of PCBs received by the AS.

Inter-ISD beaconing is similar to intra-ISD beaconing, except inter-ISD PCBs traverse only ISD core ASes. The same path-selection metrics apply in which an AS attempts to forward the set of most-desirable paths to its neighbors. Like BGP, the process is inherently not scalable, but, as the number of ISDs and the corresponding number of core ASes is small, the approach is viable for SCION.

Link failures. Unlike the current Internet, link failures are not resolved automatically by the network but require active handling by end hosts. Since SCION forwarding paths are static, they break when a link fails. Link failure is handled by a three-pronged approach that typically masks the failure without any outage to the application and rapidly re-es-tablishes fresh working paths like this: Beaconing occurs every few seconds, constantly establishing new working paths; the SCION control message protocol (SCMP), a SCION equivalent of ICMP, is used for link revocation; and SCION end hosts use multipath communication by default, masking link failures to an application with another working path. As multipath communication can increase availability (even in environments with a limited number of paths4), SCION beacon servers actively attempt to create disjoint paths and select and announce disjoint paths, and end hosts compose path segments to achieve maximum resilience to path failure. We thus expect most link failures in SCION to go unnoticed by the application, unlike with the numerous short outages in the current Internet. 16, 18

Intra-AS communication. Communication within ASes is handled through existing intra-domain communication protocols (such as IP, Open Shortest Path First, Multiprotocol Label Switching, and Software-Defined Networking).