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).
We explicitly
seek high efficiency
such that
packet-forwarding
latency and
throughput
are at least
as fast as current
IP forwarding.