Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clarify router checks #61

Merged
merged 2 commits into from
Sep 3, 2024
Merged

clarify router checks #61

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
fa1eddf
clarify router check - rough version
nicorusti Aug 30, 2024
84fd2f7
checks: small language change
nicorusti Sep 3, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 9 additions & 3 deletions draft-dekater-scion-dataplane.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -258,7 +258,7 @@ Segments cannot be combined arbitrarily. To construct a valid forwarding path, t
- If there are two path segments (one up and one down segment) that share a common ancestor AS (in the direction of beaconing), then a shortcut via this common ancestor AS is possible.
- Additionally, all segments without any peering possibility MUST consist of at least two Hop Fields.

**Note:** The type of segment is known to the endpoint but is not visible in the path header of data packets. Therefore, a SCION router needs to explicitly verify that these rules were followed correctly.
Note that the type of segment is known to the endpoint but it is not explicitly visible in the path header of data packets. Therefore, a SCION router needs to explicitly verify that these rules were followed correctly by performing checks described in [](#process-router-ingress).

Besides enabling the enforcement of path policies, the above rules also protect the economic interest of ASes as they prevent building "valley paths". A valley path contains ASes that do not profit economically from traffic on this route, with the name coming from the fact that such paths go "down" (following parent-child links) before going "up" (following child-parent links).

Expand Down Expand Up @@ -1242,12 +1242,18 @@ direction
{: #figure-19 title="A simplified representation of the processing at routers in both directions."}


#### Steps at Ingress Border Router
#### Steps at Ingress Border Router {#process-router-ingress}

A SCION ingress border router MUST perform the following steps when it receives a SCION packet:

1. Check that the interface through which the packet was received is equal to the ingress interface in the current Hop Field. If not, the router MUST drop the packet.
2. Check if the current Hop Field is expired or originated in the future, i.e. the current Info Field MUST NOT have a timestamp in the future, as defined in [](#inffield). If either is true, the router MUST drop the packet.
2. If there is a segment switch at the current router, check that the ingress and egress interface links are either:

- Both core
- Parent-Child or viceversa
- Peering
Such link types are further defined in {{I-D.dekater-scion-controlplane}} section "Paths and Links". This check avoids valley-use of peering-links or hair-pin segments.
3. Check if the current Hop Field is expired or originated in the future, i.e. the current Info Field MUST NOT have a timestamp in the future, as defined in [](#inffield). If either is true, the router MUST drop the packet.

The next steps depend on the direction of travel and whether this segment includes a peering Hop Field. Both features are indicated by the settings of the Construction Direction flag `C` and the Peering flag `P` in the current Info Field, so the settings of both flags MUST be checked. The following combinations are possible:

Expand Down
Loading