Exploring Scion: The future Internet architectecture
These are my notes and excrepts while reading through this article
Notes
- scion meets “successful protocol rfc” factors
- question in path lookup: how do ISD cores (CAS) connect to other AS that are not part of an ISD. Isn’t this important for early adopters
- the path service when searching for a path segment (up-path (already in db) + core-path + down-path) sort of works like a recursive dns resolver.
- wondering how this would compare to bgp in terms of performance
- scion’s built in path awarness helps IXP to advertise their internal connectivity to clients. Clients can use this to select paths based on the application’s needs.
Excerpts
-
SCION's aspiration to improve inter-AS routing and to focus on providing end-to-end connectivity. However, SCION does not solve intra-AS routing issues, nor does it provide end-to-end payload encryption, and identity authentication. These topics, which are equally important for the Internet to perform well, lie outside the scope of SCION
-
SCION organizes existing ASes into groups of independent routing planes, called Isolation Domains (ISD)
-
Links between ISDs and ASes and others
Autonomous System Links inside and between Isolation Domains -
Routing protocol steps
Scion Routing -
path-segment construction beacons (PCBs)
-
the path segment construction process is referred to as beaconing
-
DATA PLANE: Because SCION splits the information about the locator (the path towards the destination AS) and the identifier (the destination address), the identifier can have any format that the destination AS can interpret--only the destination needs to consider that local identifier — details - https://www.rfc-editor.org/rfc/rfc6830
-
inter-AS SCION links are usually deployed in parallel to existing links, in order to preserve its security properties. That is, two SCION border routers from neighbour ASes are directly connected via a layer-2 cross-connection at a common point-of-presence.