text:
\subsection{Fair sharing of steady down-paths}
\label{appendix:sharing-down-paths}

\noindent Recall from \autoref{sec:corepaths} that core ASes negotiate core
contracts to set up core paths among each other (the double continuous lines in
\autoref{fig:topology}). The reserved bandwidth for those core paths is
negotiated based on aggregated traffic volumes as observed in the past. The
question we consider in the following is how the reserved bandwidth is split
among the customers of the core ASes. More precisely, we describe a sharing
mechanism that assigns each leaf AS $E$ a fair amount of bandwidth for $E$'s
traffic traversing the core paths. Intuitively, \emph{fair} in this context
means proportional to the amount of bandwidth that $E$ has purchased for its
steady up-paths to the core AS.
In contrast to the fair sharing mechanism for ephemeral paths
(Section~\ref{sec:ephemeral}), the equations we introduce here do not require
the additional weighting factor $\bwrat=\frac{\bweph}{\bwstd}$ given by the
ratio of ephemeral and steady bandwidth.

\paragraph{Steady bandwidth on core links}
The steady bandwidth of a core path $\mathbf{C}=\langle AS_{C1}, \ldots,
AS_{Cn}\rangle$ between core $AS_{C1}$ and a destination core $AS_{Cn}$ is
split between all customer ASes of $AS_{C1}$, weighted with the bandwidth of
the steady up-path each customer AS uses.

Let $sBW_{u*}$ be the total amount of steady bandwidth sold by a core $AS_{C1}$
for \emph{all} its steady paths. Let $sBW_u$ be the reserved bandwidth sold by
$AS_{C1}$ for a \emph{particular} steady up-path $S_u$. Let further
$sBW_\mathbf{C}$ be the steady bandwidth of core path $\mathbf{C}$. Then the
steady traffic on $\mathbf{C}$ launched via $S_u$ can be up to:

\begin{equation}
  \label{eq:std:core}
  sBW_{uC} = \frac{sBW_u}{sBW_{u*}} \cdot sBW_\mathbf{C}
\end{equation}

\paragraph{Steady bandwidth in the destination ISD}
In the destination ISD, the weighted fair sharing follows the same intuition,
this time consisting first of a fair sharing mechanism between different ISDs,
then between the ASes in the same ISD.

More precisely, steady traffic launched over steady up-path $S_u$ and steady
down-path $S_d$, with core path $\mathbf{C}$ in between, obtains a throughput:
\begin{equation}
  \label{eq:std:destination}
  sBW_{uCd} = \frac{C_{C1\to Cn}}{C_{*\to Cn}} \cdot \frac{sBW_u}{sBW_{u*}} \cdot sBW_{d}
\end{equation}
where $C_{C1\to Cn}$ is the bandwidth negotiated in $\mathbf{C}$'s core
contract between core $AS_{C1}$ (source ISD) and core $AS_{Cn}$ (destination
ISD), $C_{*\to Cn}$ is the total amount of bandwidth negotiated in the core
contracts between \emph{any} core AS\xspace and the destination ISD's core $AS_{Cn}$,
and $sBW_d$ is the reserved bandwidth sold by core $AS_{Cn}$ for steady down-path
$d$.

The second case is that of local steady traffic in the destination ISD,
which does not traverse any core path. In fact, this happens only when the
steady up- and down-paths cross at the same core AS\xspace, otherwise traffic would
traverse a core path between the core ASes\xspace of the destination ISD (see
\autoref{fig:topology}).

This case introduces a \emph{preference} $\rho \in(0,1)$ that splits the
bandwidth of the steady down-path between traffic that traverses core paths,
and traffic that does not.

Let $sBW_{u*}$ be the total bandwidth of all steady up-paths to a given core AS
in the destination ISD. Then, a particular steady up-path among them, say with
bandwidth $sBW_{u}$, obtains steady bandwidth on the down-path $d$ of
\begin{equation}
  \label{eq:std:onlyd}
  sBW_{ud}^\rho = \frac{sBW_{u}}{sBW_{u*}} \cdot \rho \cdot sBW_{d}
\end{equation}

Traffic from external ISDs is weighted accordingly, extending
\autoref{eq:std:destination}:
\begin{equation}
  sBW_{uCd}^\rho = (1-\rho) \cdot sBW_{uCd}
\end{equation}

\paragraph{Authentication of bandwidth values} To compute $sBW_{uC}$ and
$sBW_{uCd}$, ASes\xspace use the bandwidth values for steady up-paths and core paths
included in the SIBRA\xspace packet headers. In order to prevent a malicious AS from
increasing its fair share by tampering with the bandwidth values, SIBRA\xspace
requires the core ASes of each ISD to sign the bandwidth of steady up-paths
inside the ISD, as well as the bandwidth of core paths starting at the ISD core.

Signing can take place when the steady paths are registered at the ISD core.
Each AS first verifies the signatures, and then computes the fair shares. Fast
signing and verification can be implemented using the public-key high-speed
signature scheme \texttt{ed25519}. The private key used for signing by an ISD
core can be shared among the core ASes\xspace in each ISD. For signature verification,
the corresponding public key of an ISD core is distributed to all other ISDs,
which disseminate the key to all ASes\xspace inside the ISD. In practice, on the order
of only 100 public keys need to be distributed. Since ISD cores are typically
stable, key change and re-distribution should be infrequent. A detailed
description is out of scope for this paper.

\paragraph{Dynamic fair sharing}
A pertinent question is whether the computed fair share is large enough to be
useful.  On core links, whose capacity exceeds hundreds of Gbps (recall the
example of Australia in Section~\ref{sec:discussion}), even a ratio of only 1\%
steady bandwidth is on the order of a few Gbps, which would give each AS
outside Australia tens of Mbps of steady traffic.

However, in the destination ISD, given that steady down-paths' capacity is
merely a few Mbps of bandwidth, the fair share obtained for each leaf AS is
less than 1~kbps --- too small to be useful. Of course, a popular destination
AS\xspace could register several steady down-paths to increase the steady fair share,
but the increase factor is still small compared to the number of possible
source ASes\xspace.

The key observation is that SIBRA\xspace enforces the fair share on steady traffic
\textit{dynamically}, i.e., only when a steady down-path becomes congested. The
fair share is computed between the ASes\xspace that \textit{actively use} the steady
down-path, as opposed to all possible ASes\xspace in the Internet. The fair share is
reserved for 1 second, which allows the AS\xspace two retry attempts if an ephemeral
reservation fails (considering an RTT of 300 ms -- a conservative value,
according to measurements performed by CAIDA\footnote{\url{https://www.caida.
org/research/performance/rtt/walrus0202/}}).

\subsection{SCION Internet Architecture}\label{subsec:SCION}
We first review the related primitives from a clean-slate Internet
architecture called SCION.

\paragraph{Trust Domains} SCION divides Internet into \textit{Trust Domains}
(TDs). TD is a set of ASes\xspace which share legislative and judicial frameworks,
contracts, or physical locality.  Each TD has \textit{TD Core} (TDC) which is
formed by Tier-1 ASes\xspace from this trust domain. TDC is responsible for TD
management that encompasses routing, adding/removing TD's members, establishing
trust relationships and Inter-TD forwarding. Every AS\xspace within TD should be able
to reach a core following customer-provider relationship upstream. Division
Internet into trust domains provides accountability of TDs' ASes\xspace and isolation
between different TDs.

\paragraph{Path Construction} In SCION, an end-to-end path is divided into two
half paths: an \textit{up-path} (from the source AS\xspace to the TD Core) and a
\textit{down-path} (from the TD Core to the destination AS\xspace).  In each TD, half
paths are discovered via \textit{Path Construction Beacons} (PCBs), that are
sent periodically from a TD Core to endpoint ASes\xspace, in a top-down route discovery
fashion. Each AS\xspace on the path appends to PCB authenticated routing information
called \textit{opaque field}, which describes ingress and egress interface and
expiration time of the path.  End-host ASes\xspace publish some of its half paths to
the \textit{Path Server} in the TD Core, such that the rest of the network can
download them.

\paragraph{Path Control}
A source wishing to connect to a remote destination, contacts local path server,
which returns locally stored up-path and downloaded from TDC destination's
down-path.  Then source combines these paths into full-path, that is a list of
opaque fields, and can send packets using the full-path to the destination.
Every router on the path verifies authenticity of a corresponding opaque field
and forwards packet. Such forwarding is stateless, as packets contain opaque
fields (\textit{packet-carried forwarding state}).

\subsection{STRIDE}\label{subsec:STRIDE}
Despite an elevated default level of availability, SCION is still
vulnerable to link-flooding attacks. Designed to securely establish
bandwidth guaranteed channels, STRIDE is the first DDoS protection
architecture built on the top of SCION. In the following we highlight the
STRIDE's core concepts that provide inspiration in SIBRA\xspace's design. We point out
the limitation and shortcomings of STRIDE system in Section~\ref{sec:related}.

\paragraph{Bandwidth Spectrum} STRIDE differentiates three bandwidth
types---best effort, static, and dynamic---according to various guarantees. By
default all paths are best effort, i.e. without any guarantee.  Best-effort
paths can be converted into static or dynamic via explicit requests.  A static
path is a long-term half path with low-capacity dedicated for control planes,
while a dynamic path is a short-term end-to-end path with high-capacity.
Dynamic channel between end hosts can be established with static (guaranteed) or
best effort path (without guarantee).  However, in both cases it is assumed that
TD Core is congestion free.

\paragraph{Traffic Management}
STRIDE employs weighted fair sharing. Available static bandwidth is shared
proportional to the ASes\xspace' static allocations. Similarly, STRIDE limits the
dynamic bandwidth to be proportional to the ASes\xspace' static-class bandwidth
allocation on the congested link.  Furthermore, traffic priority is enforced on
the down-paths to distinguish intra-TD and inter-TD requests in the case of
congestion. By dropping low priority (inter-TD) traffic, STRIDE is intended to
protect the communication inside a TD.

Taken together, inside one trust domain, STRIDE provides AS-based guarantees
(i.e., bandwidth guarantees to endpoint ASes\xspace). Assuming the TD Core is
congestion-free, the combination of two static half paths in the same TD results
in a low-capacity, bandwidth-guaranteed channel that can be used to securely
deliver dynamic channel establishment requests from the source to the
destination.

\subsection{SIBRA overview}
\label{sec:overview}

\noindent A key insight of SIBRA\xspace is its hierarchical decomposition of the
bandwidth allocation problem to make management and configuration scale to the
size of the Internet. More specifically, SIBRA\xspace makes use of
(1)~\textbf{core} contracts:
\emph{long-term} contracts amongst the core ASes of large-scale isolation domains (ISDs),
(2)~\textbf{steady} contracts:
\emph{intermediate-term} contracts amongst ASes\xspace within an ISD, and
(3)~\textbf{ephemeral} contracts:
\emph{short-term} contracts for end-to-end communication that leverage the long-term
and inter\-mediate-term contracts.

Thanks to this three-layer decomposition, on the order of 100 large-scale ISDs (e.g.,
composed by sets of countries or groups of companies) can scalably establish
long-term \textbf{core~paths} with guaranteed bandwidth between each other (the
double continuous lines in \autoref{fig:topology}). Within each ISD, providers
sell bandwidth to their customers, and customers can establish
inter\-mediate-term reservations for specific \emph{intra}-ISD paths, which we
call \textbf{steady paths} (the dashed lines in \autoref{fig:topology}). Steady
paths are mostly used for connection setup traffic, but can also be used for
low-bandwidth data traffic.
Finally, core and steady paths in conjunction enable the creation of short-term
end-to-end reservations \emph{across} ISDs, which we call
\textbf{ephemeral paths} (the solid green lines in
\autoref{fig:topology}). Ephemeral paths, in contrast to steady paths,
are used for the transmission of high-throughput data traffic.

\begin{figure}[t]
  \begin{center}
    \includegraphics[width=0.9\linewidth]{SIBRA-paths.pdf}
  \end{center}
  \vspace{-5mm}
  \caption{Exemplary SIBRA\xspace topology with 4 isolation domains and their ASes
  (the core ASes are filled). The ephemeral path (green) from end host $S$ to
  end host $D$ is created along a steady up-path, a core path, and a steady
  down-path. The attack traffic (red) does not diminish the reserved bandwidth
  on ephemeral paths.}
  \label{fig:topology}
  \vspace{-7mm}
\end{figure}

SIBRA\xspace paths are established over SIBRA\xspace links whose anatomy
is depicted in \autoref{fig:anatomy}: \bweph\% of
the bandwidth of each SIBRA\xspace link is allocated for ephemeral traffic, \bwstd\% for
steady traffic, and the remaining \bwbst\% for best-effort traffic.
These proportions are flexible system parameters; we discuss the current choice
in \autoref{sec:parameters}. Note that the proportion for steady and ephemeral
traffic constitutes an upper bound: in case the ephemeral bandwidth is not
fully utilized, it is allocated to best-effort traffic
(Section~\ref{sec:ephemeral}).

An important feature of SIBRA\xspace is that steady paths, besides carrying the
\bwstd\% control traffic of links inside an ISD, also limit the bandwidth for ephemeral
paths: An ephemeral path is created by launching a request through existing
steady paths whose amounts of bandwidth determine -- up to a fixed scaling factor
-- the bandwidth of the requested ephemeral path. More precisely, an ephemeral
path is created through the combination of (i) a steady up-path in the source
ISD, (ii) the steady part of a core path, and (iii) a steady down-path in the
destination ISD.\footnote{For instance, \autoref{fig:topology} shows an
ephemeral path from host $S$ in $AS_E$ to host $D$ in $AS_H$. If the source and
destination are in the same ISD, then the core path may not be necessary, e.g.,
the ephemeral path inside the US ISD.} The ephemeral path \emph{request} uses
only the steady portion of a link (the blue part in \autoref{fig:anatomy}); the
actual ephemeral path \emph{traffic} uses only the ephemeral portion of a link
(the orange part in \autoref{fig:anatomy}). In other words, the more steady
bandwidth a customer purchases locally within her ISD, the larger the fraction
of ephemeral bandwidth she obtains to any other ISD in the Internet.

\begin{figure}[t]
  \begin{center}
    \includegraphics[width=0.7\linewidth]{SIBRA-paths-anatomy.pdf}
  \end{center}
  \vspace{-3mm}
  \caption{The anatomy of SIBRA\xspace links: \bweph\% of the link bandwidth is used
  for ephemeral traffic, \bwstd\% for steady traffic, and \bwbst\% for
  best-effort traffic. The core path from $AS_{D1}$ to $AS_{B2}$ comprises
  steady and ephemeral traffic, but excludes best-effort traffic.}
  \vspace{-7mm}
  \label{fig:anatomy}
\end{figure}

Based on these ideas, it becomes intuitively clear how botnet-size independence
is achieved and how the \tragedy is resolved: Each pair of domains can obtain a
minimum bandwidth allocation, based on their respective steady paths and based
on the core contract. Thus, a botnet cannot influence the minimum allocation,
no matter its size and distribution. A bot can only use up the bandwidth
allocated to the AS it resides in, but not lower the minimum allocation of any
other AS. It is thus in the responsibility of an AS to manage its allocations,
and thereby to prevent bots from obtaining resources of others within that AS.

In case an AS\xspace is dissatisfied with its minimum allocation, it can purchase
more bandwidth for its steady paths, as well as request its core AS\xspace to
purchase a larger allocation for the core contract, which the AS\xspace would likely
need to pay for. An important point of these contracts is that, in order to
scale, core contracts are purely neighbor-based: only neighboring ASes\xspace perform
negotiations.

SIBRA\xspace's scalability is additionally based on a relatively low number of
ephemeral paths, compared to \emph{all possible} end-to-end paths in today's
Internet, considered for instance by IntServ~\cite{intserv}. As mentioned
above, an ephemeral path in SIBRA\xspace is fully determined by choosing two steady
paths and a core path. The number of steady up-/down-paths an AS\xspace can
simultaneously have is upper-bounded by a small SIBRA\xspace system parameter (e.g.,
$5$ to $7$), and the number of core paths is naturally upper-bounded by the
number of ISDs.

To make SIBRA\xspace viable for practical applications, we need to ensure that all
aspects of the system are scalable and efficient, which holds in particular for
the frequent operations such as flow admission, reservation renewal, and
monitoring and policing.
For instance, all fastpath operations are per-flow stateless to avoid
state-exhaustion attacks and to simplify the router architecture.

\subsection{Core paths}
\label{sec:corepaths}

\noindent
Directly-connected core ASes\xspace (i.e., Tier-1 ISPs) are expected to agree on a
guaranteed amount of bandwidth for traffic traversing their connecting links.
We envision that ASes\xspace ratify such \emph{core contracts} on mutual business
advantages for their customers, on top of currently negotiated
customer-to-provider or peering relations. Similar to SLAs, core contracts are
long term (e.g., on the order of months) and can have an up-time associated
(e.g., the bandwidth is guaranteed 99.99\% of the time). Core contracts
comprise steady and ephemeral traffic, as illustrated in the shaded part of
\autoref{fig:anatomy}.
If one of the ASes\xspace sends more traffic than agreed on, the AS\xspace is held
accountable, according to the established contract.

Core contracts are initiated by \textit{receiver core ASes\xspace}: each core AS\xspace
observes the historical traffic values \textit{received} on its neighboring
links, and proposes in the core contracts similar values for the traffic the
AS\xspace is willing to absorb. For instance, in \autoref{fig:corecontracts},
$AS_{B2}$ proposes to absorb 5~Tbps of steady and ephemeral traffic from
$AS_{B1}$ (Step~\ding{172}), and $AS_{B1}$ accepts. The contract is followed as long as $AS_{B1}$
sends at most 5~Tbps to $AS_{B2}$, regardless of whether $AS_{B1}$ is the
actual origin of the traffic, or $AS_{B1}$ only forwards someone else's traffic
to $AS_{B2}$. For instance, $AS_{B1}$ could forward traffic from $AS_{D1}$ and
$AS_{D1a}$ to $AS_{B2}$. In the example, $AS_{B1}$ offers to forward 1~Tbps
from $AS_{D1}$ (Step~\ding{173}), and 3~Tbps from $AS_{D1a}$
(Step~\ding{174}). $AS_{D1a}$ extends the latter contract by proposing to
$AS_{D1}$ to absorb 2~Tbps towards $AS_{B2}$ (Step~\ding{175}). After
completion of the negotiation, $AS_{D1}$ obtains guaranteed bandwidth to
$AS_{B2}$ along two \textbf{core paths}.

\label{sec:contracts}
\begin{figure}[t]
  \begin{center}
    \includegraphics[width=0.95\linewidth, trim=0 30 0 0]{SIBRA-core_contracts.pdf}
  \end{center}
  \caption{Core contracts between core ASes\xspace ($AS_{D1}$, $AS_{D1a}$, $AS_{B1}$,
    $AS_{B2}$).}
  \vspace{-3mm}
  \label{fig:corecontracts}
\end{figure}

\autoref{tab:core} illustrates a local \emph{guaranteed-bandwidth} table that
stores such core paths for $AS_{D1}$. The table resembles a forwarding table
and may contain multiple entries for each destination core AS\xspace, one entry for
each core path. It results from the contract proposals and the received
acknowledgments for a specific destination, $AS_{B2}$ in this case. For
brevity's sake, \autoref{tab:core} shows only the entries for destination
$AS_{B2}$.

\begin{figure}[tp]
\small
\renewcommand{\arraystretch}{1.0}
\centering
 \begin{tabular}{lll}
 \hline
 Destination & \centering Path & Bandwidth \\ [0.5ex]
 \hline\hline
 $AS_{B2}$& $AS_{B1} \rightarrow AS_{B2}$ & 1 Tbps\\
 $AS_{B2}$& $AS_{D1a} \rightarrow AS_{B1}\rightarrow AS_{B2}$ & 2 Tbps \\ [-1ex]
 ~ $\vdots$ & ~ $\vdots$ & ~ $\vdots$ \\
 \hline
 \end{tabular}
\caption{Core contracts table at $AS_{D1}$. Two core paths lead to $AS_{B2}$.}
\vspace{-5mm}
\label{tab:core}
\end{figure}

The bandwidth of a core path reflects the overall traffic volume exchanged
between the source and the destination ASes. To bootstrap the process, each
participating AS observes aggregate traffic volumes on its neighboring links,
and initiates contracts with a bandwidth of 85\% of the observed aggregate
volume (5\% steady + 80\% ephemeral). The initially estimated contracts are
refined as dictated by the customer requirements and payments (explained below).

\paragraph{Scalability} The core contract proposals traverse only one link
before being accepted or denied. For instance, in \autoref{fig:corecontracts},
$AS_{B1}$ first accepts $AS_{B2}$'s proposal (Step~\ding{172}), and only
afterwards, it submits its offers (Steps~\ding{173} and \ding{174}). Achieving
global consensus through immediate agreements is possible due to the
\textit{destination-initiated} process of establishing core contracts, in which
the supported amount of traffic is already specified and can thus be decided
based on \textit{local knowledge}. In contrast, source-initiated requests would
require a distributed consensus algorithm that would traverse all ASes whose
agreement is required. SIBRA\xspace's design decision sacrifices such costly
interactions for better scalability, achieving a core contract design that is
scalable with the number of core ASes\xspace.

\paragraph{Payment} Core paths not only guarantee bandwidth between
ISDs, they also regulate the traffic-related money flow between core
ASes\xspace according to existing provider-to-customer (p2c) or peering (p2p)
relationships (e.g., c2p between $AS_{B2}$ and $AS_{B1}$, and p2p
between $AS_{D1}$ and $AS_{B1}$).

Similar to today's state of affairs, we believe that market forces create a
convergence of allocations and prices when ASes balance the bandwidth between
their peers and adjust the contracts such that the direct core AS\xspace neighbors
are satisfied. The neighbors, in turn, recursively adapt their contracts to
satisfy the bandwidth requirements of their customers. Paying customers thus
indirectly dictate to core ASes\xspace the destination ISDs of core paths and the
specified bandwidth in the contracts.

\subsection{Steady paths}

\noindent Steady paths are intermediate-term, low-bandwidth
reservations that are established by ASes for guaranteed
communication availability within an ISD. We envision that the
default validity of steady paths is on the order of minutes, but it
can periodically be extended. An endpoint AS\xspace can voluntarily tear
down its steady path before expiration and set up a new steady path.
For example, in \autoref{fig:topology}, $AS_E$ sets up a steady path
to $AS_{A2}$, and $AS_H$ requests bandwidth guarantees from
$AS_{B2}$. As mentioned earlier, SIBRA\xspace uses steady paths for two
purposes: (1)~as communication guarantees for low-bandwidth
traffic, and (2)~as building block for ephemeral paths: to
guarantee availability during connection setup and to perform
weighted bandwidth reservations (Section~\ref{sec:ephemeral}).

\begin{figure}[t]
  \begin{center}
  \includegraphics[width=0.95\linewidth, trim=0 25 0 0]{res-request-processing.pdf}
  \end{center}
  \caption{Transit $AS_F$ processing reservation requests for sources $S_1$, $S_2$, $S_3$ and
  destination $D$.\footref{fnt:destination}}
  \vspace{-5mm}
  \label{fig:reservation}
\end{figure}

\footnoteblind{fnt:destination}{We use the term \emph{destination} in the following (and also in
\autoref{fig:reservation}) to stay as general as possible. For steady-path
reservation requests, the destination is the ISD core; for ephemeral-path
reservation requests, the destination will be another end host
(\autoref{sec:ephemeral}).}

\paragraph{Reservation request}
SIBRA\xspace leverages so-called SCION \emph{routing beacons}~\cite{scion2015} that
disseminate top-down from the ISD core to the ASes\xspace. On their journey down, they
collect AS-level path information as well as information about the current
amount of available bandwidth (both steady and ephemeral) for each link.
\ifFullVersion
Given this information, each half-path can become a steady
path, and each end-to-end path can become an ephemeral path,
through the mechanism we describe next.

\fi
When a leaf AS\xspace receives such a routing beacon with information about
a path segment, the AS\xspace can decide to submit a reservation request
that promotes the path segment to a steady path. In this case, the
leaf AS\xspace (e.g., $AS_E$ in \autoref{fig:topology}, or $S_3$ in
\autoref{fig:reservation}) computes a new flow ID, chooses the amount
of bandwidth and the expiration time, and sends a \emph{steady path
reservation message} up the path to the core.
The requested amount of bandwidth can be chosen from a number of predefined
bandwidth classes, introduced for monitoring optimization purposes
(Section~\ref{sec:mon}).

Each intermediate AS on the path to the core performs \textit{admission
control} by verifying the availability of steady bandwidth to its
neighbors on the path (Step~I in \autoref{fig:reservation}). Given
the fact that inbound traffic from multiple ingress routers may
converge at a single egress router, admission control is performed at
both ingress and egress routers. Specifically, the ingress router of
$AS_i$ checks the availability of steady bandwidth on the link
$AS_{i-1}\rightarrow\,AS_i$, and the egress router of $AS_i$ on the
link $AS_i\rightarrow\,AS_{i+1}$.
If enough bandwidth is available at both the ingress and the egress
router (Case~\ding{202} in \autoref{fig:reservation}), both routers
\textit{temporarily} reserve the requested bandwidth (Step~II).
Subsequently, the egress router of $AS_i$ issues a cryptographically
authenticated \textit{reservation token} (RT) encoding the positive
admission decision (Step III).

An RT generated by $AS_i$ is authenticated using a cryptographic key
$K_i$ known only to $AS_i$, by which $AS_i$ can later verify if an RT
embedded in the data packet is authentic.
More specifically, the RT contains the authenticated ingress and the
egress interfaces of $AS_i$, and the reservation request information.
RTs are onion-authenticated to prevent an attacker from crafting a
steady path from RT chunks:

\vspace{-12pt}
\begin{equation*}
\begin{aligned}
\quad & \mathit{RT}_\mathit{AS_i} =
  \mathit{ingress_{AS_i}} \,\parallel\, \mathit{egress_{AS_i}} \,\parallel \\
\quad & \quad
  MAC_{K_i}\big( \mathit{ingress_{AS_i}} \parallel \mathit{egress_{AS_i}} \parallel \mathit{Request} \parallel RT_\mathit{AS_{i-1}}\big)
\end{aligned}
\label{eq:RT}
\end{equation*}
where $\mathit{Request}$ is defined as
$\mathit{Bw_{req}}\parallel\mathit{ExpTime}\parallel\mathit{flowID}$.
We emphasize that steady path reservation flow identifiers are independent of
TCP flow identifiers: A steady path can carry packets from \emph{multiple} TCP
flows, as long as these packets contain the RTs corresponding to the steady
path in their header.

If at least one of the routers of $AS_i$ cannot meet the request
(Case \ding{203}), it suggests an amount of bandwidth that could be
offered instead, and adds this suggestion to the packet header.
Although already failed, the request is still forwarded to the
destination (i.e., to the ISD core in case of steady paths) to collect
suggested amounts of bandwidth from subsequent
ASes\xspace. This information helps the source make an informed and direct
decision in a potential bandwidth re-negotiation.

As steady paths are only infrequently updated, scalability and
efficiency of steady path updates are of secondary importance.
However, $AS_i$ can still perform an efficient admission decision by
simply considering the current utilization of its directly adjacent
AS\xspace neighbors.
Such an efficient mechanism is necessary for reservation requests (and
renewals) to be fastpath operations, avoiding to access per-path state.
In case of a positive admission decision, $AS_i$ needs to account for
the steady path individually per leaf AS\xspace where the reservation
originates from. Only slowpath operations, such as policing of
misbehaving steady paths, need to access this per-path information
about individual steady paths.

\paragraph{Confirmation and usage} When the reservation request reaches the
destination~$D$, the destination replies to the requesting source (e.g., $S_3$)
either by a \textit{confirmation message} (Case \ding{204} in
\autoref{fig:reservation}) containing the RTs accumulated in the request packet
header, or by a \textit{rejection message} (Case \ding{205}) containing the
suggested bandwidth information collected before.\footref{fnt:destination} As
the confirmation message travels back to the source, every ingress and egress
router accepts the reservation request and switches the reservation status from
temporary to active (Step IV).

In order to use the reserved bandwidth for actual data traffic, the
source includes the RTs in the packet header.

\subsection{Ephemeral paths}
\label{sec:ephemeral}

\noindent Ephemeral paths are used for communication with guaranteed high
bandwidth. Ephemeral paths are short-lived, only valid on the order of tens of
seconds, and thus require continuous renewals through the life of the connection.
The source, the destination, and any on-path AS\xspace can rapidly renegotiate the
allocations. \autoref{fig:topology} shows two ephemeral paths, one inside an
ISD, one across three ISDs.

We emphasize that the amount of ephemeral bandwidth that is proportional to
steady bandwidth may constitute a lower bound: If more ephemeral bandwidth is
available (for instance since not everybody might be using his fair share of
ephemeral bandwidth), requesters can choose a bandwidth class \emph{above} the
proportional ratio. In the spirit of fair allocation of joint resources, the
lifetime of ephemeral paths is limited to 16 seconds in order to curtail the
time of resource over-allocation. The details of the over-allocation, however,
are out of scope and left for future work.

\paragraph{Ephemeral paths from steady paths} Ephemeral path requests bear many
similarities with steady path requests, yet bootstrapping is different: An
ephemeral path reservation is launched by an end host, as opposed to a steady
path reservation that is launched by a leaf AS\xspace. The end host (e.g., host $S$ in
\autoref{fig:topology}) first obtains a steady up-path starting at its AS\xspace
(e.g., $AS_E$) to the ISD core, and a steady down-path starting at the
destination ISD core (e.g., $AS_{B2}$) to the destination leaf AS\xspace (e.g.,
$AS_H$).  Joining these steady paths with an inter-ISD core path (e.g., from
$AS_{A2}$ to $AS_{B2}$) results in an end-to-end path $P$, which is used to
send the ephemeral path request from the source end host $S$ to the destination
end host $D$ using allocated steady bandwidth.

More specifically, $S$ first generates a new flow ID, chooses an amount of
bandwidth to request from SIBRA\xspace's predefined ephemeral bandwidth classes, and
sends the ephemeral path request along path $P$.\footnote{Similarly to the
steady path case, although an ephemeral path is identified by a flow ID, this
flow ID is orthogonal to TCP flow IDs. A single ephemeral path can transport any
data packets regardless of their layer-4 protocol.} Recall that the path is
composed of a steady up-path of $S$, a core path, and a steady down-path of
$D$.  The leaf AS\xspace where the source end host resides (e.g., $AS_E$) may decide
to block the request in some cases, for instance if the bandwidth purchased by
the leaf AS\xspace is insufficient. Each intermediate AS\xspace on path $P$ performs admission
control through a weighted fair sharing mechanism that ensures the ephemeral
bandwidth is directly proportional with its steady path bandwidth, as described
next. The bandwidth reservation continues similarly to the steady path case.

If bots infest source and destination leaf ASes\xspace, these bots may try to exceed
their fair share by requesting, respectively approving, excessively large
amounts of bandwidth. To thwart this attack, each leaf AS\xspace is responsible for
splitting its purchased bandwidth among its end hosts according to its local
policy, and for subsequently monitoring the usage.

\paragraph{Efficient weighted bandwidth fair sharing} The intuition behind
SIBRA\xspace's weighted fair sharing for ephemeral bandwidth is that purchasing steady
bandwidth (or generally spoken: bandwidth for control traffic) on a link $L$
guarantees a proportional amount of ephemeral bandwidth on $L$. In
\autoref{fig:topology}, the ephemeral bandwidth on the ephemeral path from end
host $S$ to $D$ is proportional to the steady bandwidth on the steady up-path
from $AS_E$ to core $AS_{A2}$, and also proportional to the steady bandwidth on
the steady down-path from core $AS_{B2}$ down to $AS_H$.
We explain the details of the three cases of intra-source-ISD links, core
links, and intra-destination-ISD links in the following.

\emph{(1) Ephemeral bandwidth in the source ISD.}
For instance, a steady up-path of $500$ kbps traversing intra-ISD
link $L$ guarantees $\frac{\bweph}{\bwstd}\cdot500$ kbps of ephemeral
bandwidth on $L$. Note that $\frac{\bweph}{\bwstd}=\bwrat$ is the
ratio between ephemeral and steady bandwidth
(\autoref{sec:overview}). Generally speaking, a steady up-path
$S_u$ with steady bandwidth $sBW_u$ traversing $L$ can request
ephemeral bandwidth of
\begin{equation}
  \label{eq:eph:source}
  eBW_u = \bwrat \cdot sBW_u
\end{equation}
Consequently, an AS\xspace that purchases a steady up-path $S_u$ can
guarantee its customers a fixed amount of ephemeral bandwidth for
customers' ephemeral path requests launched via $S_u$, regardless of
the ephemeral path requests from other ASes\xspace on $L$.

To provide bandwidth guarantees on \emph{every} link to a destination,
SIBRA\xspace extends the influence of the purchased steady up-path
bandwidth along the path to the destination AS. In fact, SIBRA\xspace's
weighted fair sharing for ephemeral bandwidth on core paths includes
the purchased steady up-path bandwidth, as explained in the following.

\emph{(2) Ephemeral bandwidth on core links.} Let $sBW_{S}$ be the
total amount of steady bandwidth sold by a core $AS_S$ for \emph{all}
steady paths in $AS_S$'s ISD. Let $sBW_u$ be the reserved bandwidth
sold for a \emph{particular} steady up-path $S_u$ in this ISD. Let
further $sBW_C$ be the control traffic bandwidth of a core path $C$
between the core ASes of the steady paths for $S$ and $D$. Then,
ephemeral reservations on $C$ launched via $S_u$ can be up to
\begin{equation}
  \label{eq:eph:core}
  eBW_{uC} = \frac{sBW_u}{sBW_S} \cdot \bwrat \cdot sBW_C
\end{equation}
In other words, the ephemeral bandwidth reservable on $C$ launched via steady
path $S_u$ depends not only on the amount of total ephemeral
bandwidth on $C$, but also on $S_u$'s steady up-path bandwidth in
relation to the total amount of steady up-path bandwidth purchased in
$S_u$'s ISD.

\emph{(3) Ephemeral bandwidth in the destination ISD.} In the
destination ISD, the weighted fair sharing is slightly more complex,
but follows the ideas of the previous cases: the weighting includes
the steady bandwidth of all steady up-paths and all steady
down-paths, as well as the ratios of the bandwidth of the core
contracts. Before explaining the details, we note that the reason for
including also the steady down-paths is to give the destination AS\xspace
control over the minimum amount of traffic it receives along
ephemeral paths.

More precisely, an ephemeral path launched over steady up-path $S_u$
and steady down-path $S_d$ with core path $C$ in between obtains
ephemeral bandwidth
\begin{equation}
  \label{eq:eph:destination}
  eBW_{ud} = \frac{C_{S\to D}}{C_{*\to D}} \cdot \frac{sBW_u}{sBW_S} \cdot \bwrat \cdot sBW_{d}
\end{equation}
where $C_{S\to D}$ is the bandwidth negotiated in the core contract
for $C$ between the core ASes of $S$ and $D$, and $C_{*\to D}$ is the total
amount of bandwidth negotiated in all core contracts between any core
AS and $D$'s core AS.

\autoref{eq:eph:destination} looks similar to
\autoref{eq:eph:core}, with an additional factor in the weighting
that reflects the ratio of incoming traffic from other core ASes.
Intuitively, this factor assures that traffic from every other core
AS obtains its fair share based on the bandwidth negotiated in the
individual bilateral contracts.

Finally, the overall bandwidth for an ephemeral path
between end hosts $S$ and $D$ launched over
steady up-path $S_u$ reads
\begin{equation}
  eBW_{uCd} = min(eBW_u, eBW_{uC}, eBW_{ud})
\end{equation}

These equations compute the guaranteed bandwidth using the envisioned long-term
ratio of 5\% steady traffic, 80\% ephemeral traffic, and 15\% best-effort
traffic. Ideally, the ratio should be adjustable by each AS, initially with an
imbalance in favor of best-effort during incremental deployment of SIBRA\xspace, until the
number of SIBRA\xspace subscribers increases. The overall bandwidth $eBW_{uCd}$ that
can be obtained during early deployment is the minimum of the individual ratios
for each AS and their link bandwidth. We discuss the choice of the ratio in
Section~\ref{sec:parameters} and its adaption in terms of an incremental
deployment strategy in Section~\ref{sec:deployment}.

\paragraph{Fair sharing of steady paths} A challenging question is whether a
fair sharing mechanism is necessary for steady bandwidth. A steady up-path is
used solely by the AS\xspace that requested it, and its use is monitored by the AS\xspace,
which splits the steady up-path bandwidth between its end hosts. In contrast,
steady down-paths need to be revealed to several potential source ASes\xspace, either
as \emph{private} steady down-paths (e.g., for a company's internal services),
or as \emph{public} steady down-paths (e.g., for public services). To
prevent a botnet residing in malicious source ASes\xspace from flooding steady
down-paths, SIBRA\xspace uses a weighted fair sharing scheme similar to ephemeral
paths: each AS\xspace using a steady down-path obtains a fair share proportional to
its steady up-path, and its ISD's core path. We give the details of the scheme
in Appendix~\ref{appendix:sharing-down-paths}.

\paragraph{Efficient bandwidth usage via statistical multiplexing}
Internet traffic often exhibits a cyclical pattern, with alternating levels of
utilized bandwidth.
In situations of low utilization, fixed
allocations of bandwidth for steady and ephemeral paths that are
unused would result in a waste of bandwidth. SIBRA\xspace reduces such
bandwidth waste through statistical multiplexing,
i.e., unused steady and ephemeral bandwidth is temporarily given to
best-effort flows. A small slack of unallocated steady and ephemeral
bandwidth still remains to accommodate new steady and ephemeral
bandwidth requests. As more and more entities demand steady paths and
their fair share of ephemeral paths, SIBRA\xspace gradually squeezes
best-effort flows and releases the borrowed steady and ephemeral
bandwidth up to the default allocations.

\paragraph{Renewal} End hosts can launch ephemeral path renewals to increase
the reserved bandwidth and extend the expiration time of the ephemeral path.
Since ephemeral reservations have a short lifetime, they are frequently
renewed. Renewals are launched using the old reservation which contains the
bandwidth class of the reservation; therefore routers can rapidly decide on the
fastpath how much bandwidth they should allocate for the renewal, for instance
if the bandwidth increased, decreased, or remained the same. Reservations are
given a $\mathit{reservation}\ \mathit{index}$, incremented for each renewal of a specific
ephemeral path. Reservations can be renewed anytime before they expire, and the
end host is allowed to switch to the newer reservation at any time. However,
the end host is not allowed to use both the old and the renewed reservation at
the same time; \autoref{sec:mon_renew} shows a mechanism to detect such
misbehavior.

\subsection{Priority traffic monitoring and policing}
\label{sec:mon}

\noindent Flows that violate their reservations may undermine the
guarantees of other legitimate flows. An ideal monitoring algorithm
should immediately catch \emph{every} such malicious flow. This,
however, would be too expensive for line-rate traffic in the Internet
core.

Instead, as the first line of defense, SIBRA\xspace relies on edge ASes\xspace to perform fine-grained traffic
monitoring.  Edge ASes\xspace rely on flow IDs to check each flow's bandwidth usage
and compare it against the reserved bandwidth for that flow ID, which is stored
by each AS\xspace locally during the reservation request.  Previous research has
shown that per-flow slowpath operations are feasible at the edge of the
network~\cite{Stoica2003}.

Monitoring on transit ASes\xspace, however, needs to be processed on the fastpath.  To
detect misbehaving ASes\xspace that purposely fail to regulate their own traffic,
SIBRA\xspace deploys a lightweight monitoring mechanism in transit ASes\xspace. First, each
AS\xspace monitors the bandwidth usage of incoming traffic from each neighbor AS\xspace and
compares it against the \emph{total} bandwidth reserved for that neighbor. Such
coarse-grained monitoring timely detects a misbehaving neighbor that
failed to correctly police its traffic.

\begin{figure}[t]
  \begin{center}
    \includegraphics[width=0.9\linewidth]{monitoring.pdf}
  \end{center}
  \vspace{-3mm}
  \caption{Per-neighbor monitoring may label benign $AS_1$ malicious.}
  \vspace{-7mm}
  \label{fig:monitoring}
\end{figure}

\paragraph{Why per-neighbor monitoring is insufficient} There are cases,
though, when per-neighbor monitoring in transit ASes\xspace is insufficient.
\autoref{fig:monitoring} depicts two flows originating in $AS_0$, each having
reserved $5$ Mbps. Flow 1 is malicious and sends traffic with $8$ Mbps, while
flow 2 underuses its reservation. $AS_0$ hence does not properly monitor its
flows.  When $AS_1$ performs per-neighbor monitoring, it can only notice that,
in the aggregate, it receives $10$ Mbps from $AS_0$ and sends $10$ Mbps to $AS_2$.
However, when the two flows diverge, $AS_2$ detects flow 1 as malicious and
holds $AS_1$ responsible, although $AS_1$ properly performed per-neighbor
monitoring.

For this reason, SIBRA\xspace additionally utilizes \textit{fine-grained} probabilistic
monitoring of individual flows at the transit ASes\xspace, using a a recently proposed
technique~\cite{hao}. Each transit AS\xspace monitors, per given time interval, all
the flows in a number of randomly chosen bandwidth classes.  Recall that the
bandwidth class of a flow is authenticated by the RTs in the packet header.  In
case the average bandwidth utilization of a flow during that time interval
exceeds the flow's bandwidth class, the flow is classified as malicious and
added to a blacklist, preventing its renewal.

We emphasize that transit ASes\xspace perform monitoring on the fastpath.  Only in
case of suspicion of misbehavior, these ASes\xspace perform out-of-band slowpath
monitoring to police misbehaving neighbors and flows.

To localize the origin AS\xspace of the malicious flow, an AS\xspace informs the previous
AS\xspace of the misbehaving flow. In response, the previous AS\xspace can simply monitor
that specific flow explicitly.  If the violation persists, the suspicious
previous-hop neighbor is likely to be malicious. Then, the AS\xspace can punish it,
for instance, by terminating their contract.

\subsection{Flow renewal monitoring and policing}\label{sec:monitoring-policing}
\label{sec:mon_renew}

\noindent
A successful ephemeral path renewal replaces the old
reservation, therefore the renewal receives the same flow ID as the old
reservation.  However, SIBRA\xspace paths allow for RTs with
overlapping validity periods. Therefore, if multiple renewals occur before the
ephemeral path expires, the source would be in possession of multiple sets of
valid RTs: Some corresponding to the ephemeral path with the previous bandwidth class
and old expiration time, and the others corresponding to the new values for
bandwidth class and expiration time, along the same path.  Since all sets of
RTs are associated with the same flow ID, routers would overwrite their
per-flow entries with the new bandwidth class.

A malicious end host could thus exploit renewals by using both sets of RTs, old
and new, during the overlap time of the RTs, thus using more bandwidth than the
amount reserved. To prevent such misuse, end hosts are not allowed to use old
RTs after having used the renewed RTs. When renewals use the same bandwidth
class as the old reservation, simultaneous use of old and new RTs is detected
by the per-class monitoring mechanism (as described above) since the usage is
jointly accounted under the same flow ID.

We now consider the case when the renewed bandwidth class is different from the
old one. The edge AS performs per-flow stateful inspection and is supposed to
filter out traffic that violates the sending rule. Therefore, the edge AS\xspace can
be held accountable by other ASes\xspace for improperly filtering traffic. In transit
ASes\xspace, however, we propose a probabilistic approach for catching this type of
misbehavior. ASes\xspace maintain one Bloom filter~\cite{bloom} per currently active
expiration time and per bandwidth class. Since an RT is maximally valid for 16
seconds and the time granularity is 4 seconds, 4 Bloom filters are needed per
bandwidth class, to record flow IDs that use the bandwidth class within that
time period. We will discuss the details about time discretization in SIBRA\xspace in
\autoref{subsec:request}. For an incoming packet with a reservation in a
monitored class $C$, ASes\xspace simply store the tuple $\langle \mathit{flow\ ID},
\mathit{reservation\ index}\rangle$ in the Bloom filter of class $C$. By
probabilistically inspecting some of these Bloom filters, each AS\xspace notices
whether a flow ID uses two different bandwidth classes during a time period.

We further optimize the monitoring algorithm as follows. SIBRA\xspace selects a small
number of classes to monitor at a given moment in time, therefore ASes\xspace store
Bloom filters only for the few monitored traffic classes. In addition, SIBRA\xspace
does not investigate all Bloom filters: We observe that, when the renewed
bandwidth is much higher or much lower than the previous bandwidth, using both
the old and new reservations would incur an insignificant bandwidth overuse.
Therefore, if a certain reservation index is used in class $C$, SIBRA\xspace
investigates only the Bloom filters of the classes whose bandwidth values are
comparable to $C$'s bandwidth (the comparability of classes is discussed in
\autoref{subsec:request}).  SIBRA\xspace investigates whether in these Bloom filters
an index $\mathit{reservation\ index} + i$ is present, where $i \in \{0, 1, \ldots,
15\}$ chosen randomly ($i=0$ detects whether the end host maliciously reuses
the same reservation index).  If found, ASes\xspace increment a violation counter for
the source of that flow ID.  The violation counter allows for Bloom filter
false positives. When the violation counter exceeds a threshold, an alarm is
raised for that sender.  Therefore, the more packets an attacker sends, the
higher the probability of detection.  The policing push back technique can then
localize the source AS\xspace of the misbehaving flow.

\subsection{Dealing with failures}

\noindent
While bandwidth guarantees along fixed network paths allow for a
scalable design, link failures can still disrupt these paths and thus render
the reservations futile. In fact, leaf ASes\xspace and end hosts are rather
interested in obtaining a bandwidth guarantee than
obtaining a specific network path for their traffic.

SIBRA\xspace deals with link failures using two mechanisms: (1)
a failure \emph{detection} technique to remove reservations along
faulty paths, and (2) a failure \emph{tolerance} technique to provide
guarantees in the presence of failures. For (1), SIBRA\xspace uses short
expiration times for reservations and keep-alive mechanisms. Steady
paths expire within 3 minutes of creation, but leaf ASes\xspace can extend
the steady paths' lifetime using keep-alive messages. Ephemeral paths
have a default lifetime of 16 seconds, which can be extended by
source end hosts through renewals. Unless keep-alive messages or
renewals are used, reservations are removed from the system within
their default expiration time. By construction, a new reservation
cannot be created on top of faulty paths. For (2), SIBRA\xspace allows
leaf ASes\xspace to register multiple disjoint steady paths. We also
envision source end hosts being able to choose a bandwidth
reservation service with high reliability, which would use a
small number of disjoint ephemeral paths to the same destination.

\subsection{Dynamic Interdomain Leased Lines}

\noindent Businesses use \emph{leased lines} to achieve highly reliable
communication links. ISPs implement leased lines virtually through reserved
resources on existing networks, or physically through dedicated network links.
Leased lines are very costly, can require weeks to be set up, and are
challenging to establish across several ISPs.

A natural desire is to achieve properties similar to traditional leased lines,
but more efficiently. GEANT offers a service called ``Bandwidth-On-Demand''
(BoD), which is implemented through the InterDomain Controller
Protocol~\cite{idcp} to perform resource allocations across the participating
providers~\cite{geant:bod}.  Although BoD is a promising step, the allocations
are still heavy-weight and require per-flow state.

With SIBRA\xspace's properties, ISPs can offer light\-weight Dynamic Interdomain
Leased Lines (DILLs). A DILL can be composed by two longer-lived steady paths,
connected through a core path, or dynamically set up with an ephemeral path
that is constantly renewed. Thanks to the light\-weight operation of SIBRA\xspace,
DILLs can be set up with an RTT setup message and are immediately usable. Our
discussions with operators of availability-critical services have shown that
the DILL model has sparked high interest among operators.

To enable long-term DILLs, valid on the order of weeks, the concept of
ephemeral paths in SIBRA\xspace could be reframed: long-term DILLs could use the same
techniques for monitoring and policing as ephemeral paths, however, they would
also introduce new challenges.  To enable long-term DILLs, ISPs need to ensure
bandwidth availability even when DILLs are not actively used, as opposed to
ephemeral bandwidth, which can be temporarily used by best-effort flows.  For
this purpose, ISPs could allocate a percentage of their link bandwidth for
DILLs, besides steady, ephemeral, and best-effort paths. Additionally, for
availability in the face of link failures, ISPs would need to consider active
failover mechanisms. For instance, in architectures that provide path choice,
ISPs could leverage disjoint multipath reservations concentrated in a highly
available DILL.  A detailed design though is out of scope for this paper.

\subsection{On the choice of bandwidth proportions for SIBRA\xspace links}
\label{sec:parameters}

\noindent
Recall that in \autoref{sec:overview}, we assigned 80\%, 15\%, and 5\% of a
link's bandwidth to ephemeral, best-effort, and steady paths, respectively.
This parameter choice is justified through an analysis of today's actual
Internet traffic.

\begin{compactitem}

  \item First to notice is that the majority of traffic constitutes persistent
  high-bandwidth connections: for example in Australia, we see that Netflix's
  video connections contribute to more than 50\% of the entire Internet traffic
  \cite{netflix-au}. Given an additional amount of traffic from other large
  video providers such as Youtube and Facebook, we estimate ephemeral paths to
  require roughly 70--90\% of a link's bandwidth.

  \item Best-effort is still important for some types of low-bandwidth
  connections:
  email, news, and SSH traffic could continue as best-effort traffic, totaling
  3.69\% of the Internet traffic~\cite{labovitz2010};
  similar the case for DNS traffic totaling 0.17\% of the Internet
  traffic~\cite{labovitz2010}.
  In addition, very short-lived flows (that is flows with a lifetime less than
  256~ms) with very few packets (the median flow contains 37
  packets~\cite{trammell2012}) are unlikely to establish SIBRA\xspace reservations,
  simply to avoid the round-trip time of the reservation setup. Such flows sum
  up to 5.6\% of the Internet traffic~\cite{trammell2012} and can thus also be
  categorized under best-effort.

  \item Finally, regarding the amount of bandwidth for steady paths and
  connection-establishment traffic, we conducted an experiment using the
  inter-AS\xspace traffic summary by a DDoS detection system at one of the largest
  \mbox{tier-1} ISPs. With a 10-day recording of this data, we found that only
  $0.5\%$ of the $1.724\times 10^{13}$ packets were connection establishment
  packets. To enable communication guarantees for low-bandwidth traffic,
  including bandwidth reservation request packets, we designed SIBRA\xspace to
  allocate ten-fold of the amount measured.

\end{compactitem}

Since it is hard to specify the actual bandwidth proportions precisely, we use
80\%, 15\%, and 5\% as initial values and note that these values can be
re-adjusted at any point in the future.

We recall from \autoref{sec:ephemeral} that, in addition to the parameter
choice, SIBRA\xspace's statistical multiplexing between the traffic classes helps to
dynamically balance the traffic. We expect that in particular the long-lived
reservations are not always fully utilized, in which case best-effort traffic
can be transmitted instead.

\subsection{Per-flow stateless operations are necessary}
\label{sec:stateless}

\noindent To understand the amount of per-flow storage state required on the
fastpath, we investigate the number of active flows per second as seen by a
core router in today's Internet. We used anonymized one-hour Internet traces
from CAIDA, collected in July 2014. The traces contain all the packets that
traversed a 10~Gbps Internet core link of a Tier-1 ISP in the United States,
between San Jose and Los Angeles.

\autoref{fig:1second} depicts our findings as the number of active flows on the
core link at a granularity of one second, for a total duration of 412 seconds.
We observe that the number of flows varies around 220\,000, with a
boundary effect at the beginning of the data set. These flows sum into a
throughput between 3 and 4~Gbps --- a link load of 30\% to 40\%. A large core
router switching 1~Tbps (with 100 such 10~Gbps links) would thus observe
22$\times10^6$ flows per second \textit{in the normal case}, considering a link
load of only 40\%. \textit{In an attack case}, adversaries could greatly
inflate the number of flows by launching connections between bots, as in
Coremelt~\cite{studer2009coremelt}. Schuchard et al.\ already analyzed attacks
that can exhaust the router memory~\cite{schuchard2010losing}. All these
results suggest storing per-flow state in the fastpath, on the line card, becomes
prohibitively expensive, even more so when the core link load increases.

\begin{figure}[tb]
   \centering
   \includegraphics[width=.8\columnwidth]{1second.pdf}
   \caption{The number of active flows every second and their throughput,
	observed on a 10~Gbps Internet core link.}
\vspace{-6mm}
\label{fig:1second}
\end{figure}

\if0
\subsection{Adoption Incentives}
Currently, within a single provider's network, by using data communication
infrastructure isolated from the Internet, Telecommunication Service Providers
(TSPs) can provide network service with security and quality-of-service control
for their corporate customers who need guaranteed service for their site-to-site
or site-to-datacenter communication. However, they are facing difficulties when
extending their services to global scale. Building own global infrastructure is
not an effective way for a service provider. Collaborating with foreign
providers seems more realistic approach, but lack of appropriate security
mechanism makes such collaboration difficult. In SIBRA\xspace, packets can only
traverse confirmed path and their capabilities can be cryptographically
verified. These properties make the collaboration much easier for providers.
Also, by utilizing existing data communication infrastructure of each provider,
it is expected that leaf providers can offer guaranteed global network service
to their direct corporate customers with lower price and the collaborating
providers can sell transit bandwidth to the leaf providers from their surplus
capacity. Such business opportunity gives providers proper incentive to invest
money to expand their network capacity, whereas the current flat rate pricing
model of the Internet makes it harder to justify such investments. With help of
emerging technologies like SDN, data communication infrastructure in a single
provider is getting more and more flexible and capable of providing better QoS
control. SIBRA\xspace gives the providers a practical option to extend their enriched
infrastructure to global scale just by adding SIBRA\xspace routers on the edges to
their customers and neighboring providers.
\fi

\subsection{Case study: achievable ephemeral bandwidth on core links}
\label{sec:case}

\noindent A central point of SIBRA\xspace is to guarantee a sufficient amount of
bandwidth using today's infrastructure, even for reservations that span
multiple ISDs. A central question is how much bandwidth an end-domain could
minimally obtain if globally all domains attempt to obtain their maximum fair
share. To investigate this point, we considered a scenario with Australia as
destination, and all non-Australian leaf ASes in the world reserving ephemeral
bandwidth to Australia. We picked Australia because with its 24 million
inhabitants, it represents a major economy, and it already experienced
infrastructure congestion in today's Internet~\cite{netflix-au}. While its
geographical location hinders laying new cables, Australia is well-suited for
our study aiming to determine a lower bound on the amount of bandwidth SIBRA\xspace
core links can expect. Other countries, especially those situated on larger
continents, typically feature higher-bandwidth connectivity, as laying cables
on land is easier than in the ocean.

\begin{figure}[tb]
   \centering
   \includegraphics[width=.8\columnwidth]{AU_links_pie.pdf}
   \caption{Australia submarine link map, including link capacities.}
\vspace{-6mm}
\label{fig:mapAU}
\end{figure}

~\autoref{fig:mapAU} illustrates the current submarine link map of Australia,
including the name and capacity of the
links.\footnote{\url{http://www.submarinecablemap.com/} illustrates the
submarine link map. The link capacities were obtained from various resources,
e.g., the Australia-Japan Cable capacity from
\url{http://www.ajcable.com/company-history/}.} The entire traffic traverses these
links.
For simplicity, we assume
guaranteed bandwidth is split equally between leaf ASes.  In practice, however,
the bandwidth is proportional to the size of the steady paths of the leaf ASes
(Section~\ref{sec:path}). We considered two cases: (i) the worst case, i.e.,
when all reservations are squeezed over the same link --- in our case, we chose
the highest-bandwidth cable, namely the Australia-Japan Cable (6~Tbps), and
(ii) the best case, i.e., when the reservations are distributed across all
cables (totaling 15.04~Tbps). In
contrast to other architectures, SIBRA\xspace's underlying architecture, SCION,
enables the use of multi-path
communication for the traffic between a source and a destination, along several
core links.

We have determined the number of leaf ASes in the world, using the AS topology
from CAIDA\footref{CAIDA}, and counted 32\,428 non-Australian leaf ASes using
the AS number and
location\footnote{\url{http://data.caida.org/datasets/as-organizations/}}.
After the analysis, we found that each non-Australian leaf AS obtains a fair
share of (i) 185.02~Mbps (148~Mbps for ephemeral traffic), or (ii) 463.86~Mbps
(371.08~Mbps for ephemeral traffic). We thus conclude that SIBRA\xspace's fair sharing
scheme offers a substantial amount of bandwidth through an efficient use of the
current Internet infrastructure. In case this amount is insufficient, an AS
could purchase additional bandwidth for a specific destination from its core
AS.

The prospects are even brighter: considering the planned undersea physical
infrastructure development, the capacity of the cables connecting Australia
with the rest of the world would increase by 168~Tbps by the beginning of 2018.
With such an increase, the fair share on SIBRA\xspace's core links becomes 5.64~Gbps
per leaf AS in case (ii).

\if0
\subsection{Incremental Deployment}
\KDDI{Deployment Scenario might be better as the title.}
Within an ISP network, it is relatively easy to deploy SIBRA\xspace, because the ISP
can utilize its existing core network infrastructure built with
protocol-independent transport such as MPLS. An ISP can build
''SIBRA\xspace-ready'' network
by adding new customer/provider edge SIBRA\xspace routers and setting up MPLS links among them.
However, global-scale inter-ISP deployment is not easy, because an overlay approach with
IP-tunneling is not suitable for SIBRA\xspace. In order to make the most of SIBRA\xspace features such
as bandwidth reservation, high availability and security, ISPs have to have direct links
for interconnecting their SIBRA\xspace routers. Therefore, in its initial deployment phase,
a SIBRA\xspace network would be operated by a small group of ISPs with mutual connectivity.

Obvious questions one might have are whether such a partially-deployed new network infrastructure
works well in business wise and whether it can attract new ISPs to expand itself.
One business example we can see in the current Internet is a unique WAN optimization solution
provided by a startup company [www.aryaka.com]. Unlike ordinary WAN optimization solutions
that solely rely on WOC (WAN Optimization Controller) equipment placed on the customer premise
and hence affected by packet loss occurred in long distance communication over the Internet,
it has built a new global core network infrastructure dedicated for WAN optimization with
distributed Points of Presence (POPs) that runs proprietary WAN optimization protocols.
If each of an enterprise customer's distributed business sites is located near one of the POPs,
the private WAN optimization core network and the WAN optimization proxies placed on the POPs
give the customer better WAN communication performance among those sites. Also, because it
offers a readily solution for regional ISPs looking for providing global network services
beyond their own regions, it is expanding its infrastructure by gathering ISP partners.

By taking a similar approach, we can expect that SIBRA\xspace is initially deployed by
a small number of global and regional ISPs who seek to provide more advanced network services
beyond their own regions and then gradually expand itself by gathering new collaborators.
Because SIBRA\xspace's design allows ISPs to have their own policies without sacrificing security
nor reliability, it has less difficulty in building inter-ISP collaborations and its expansion
should be easier.
\fi

\subsection{Processing on router}

\noindent
We first evaluated SIBRA\xspace with respect to the \textit{processing overhead on
routers}.  For our evaluation, we used a traffic generator that initiated
bandwidth reservation requests, and sent
traffic within existing reservations.  The traffic generator was connected to a
software router that performed admission control of the request packets, RT
verification, monitoring for the existent reservations, and then forwarded the
packets.
Every experiment was conducted 1\,000 times.
We considered routers placed in both edge and core ASes\xspace, however
processing time only differed for monitoring operations.
All the tests were conducted on a PC with an Intel Intel Xeon E5-2680 2.7 GHz and
16 GB of RAM, running Linux (64-bit).

First, we investigated the time required by a router to process the SIBRA\xspace reservation
request. The average time to process a reservation request was
9.1 $\mu$s, resulting in about 109\,890 that can be processed per second.

Then, we tested the speed of the data packet processing. To this end, we used our
high-performance implementation that deploys Intel's DPDK
framework\footnote{\url{http://dpdk.org/}} for networking operations,
and the AESni extension for cryptographic operations. We set the packet length to 1\,500
bytes.  We measured the time of SIBRA\xspace processing (i.e., packet parsing and RT
verification).  It took 0.040 $\mu$s on average to process a single packet, thus
a router is capable
to process about 25 million data packets per second.
(Note that these times do not include interactions with the NIC).

Next, we investigated the performance of monitoring in the core for two
scenarios: 1 and 100 attackers.  The average processing time was 11.24
$\mu$s for a single attacker, and 9.91 $\mu$s for 100 attackers.
As the results show, the average processing time decreases with an increasing number
of attackers, as blacklisted flows are processed faster.

\begin{figure*}[tb]
   \centering
   \subfigure[]{\label{fig:intradoc}\includegraphics[width=.65\columnwidth]{doc_intraisd_sibra.pdf}}
   \subfigure[]{\label{fig:interdoc}\includegraphics[width=.65\columnwidth]{doc_interisd_sibra.pdf}}
   \subfigure[]{\label{fig:coremelt}\includegraphics[width=.65\columnwidth]{coremelt_sibra.pdf}}
   \vspace{-3mm}
   \caption{Comparative simulation results for TVA, Portcullis, STRIDE, and
   SIBRA\xspace against Intra-ISD\xspace DoC attack~\ref{fig:intradoc}, Inter-ISD\xspace DoC
attack~\ref{fig:interdoc} and Coremelt attack~\ref{fig:coremelt}.}
\vspace{-6mm}
\end{figure*}

\subsection{Bandwidth guarantees under botnet attacks}\label{subsec:com}

\noindent
To show SIBRA\xspace's resilience to Denial of Capability (DoC) and Coremelt attacks,
we run a simulation on an Internet-scale topology. In our simulation, the
attackers attempt to exhaust the bandwidth of the links common with legitimate
flows.  We compare our results with TVA~\cite{yang2005tva},
Portcullis~\cite{Parno2007}, and STRIDE~\cite{hsiao2013stride}, obtained using
the same configuration.

\paragraph{Method} Our Internet-scale topology is based on a CAIDA
dataset \cite{caida} that contains 49\,752 ASes\xspace and the links among them as
observed from
today's Internet. Based on these connections, we grouped the ASes\xspace into five ISDs\xspace,
representing five continent-based regions.  For our simulation we chose the two
biggest ISDs\xspace: $ISD_1$ containing 21\,619, and $ISD_2$ containing 6\,039
ASes\xspace. The core of each ISD\xspace is formed by Tier-1 ISPs.
We set the capacity of the core link between $ISD_1$ and $ISD_2$ to 40 Gbps.
Inside each ISD\xspace, we set the capacity of core links to 10 Gbps, the capacity of
links between a core AS\xspace and a Tier-2 AS\xspace to 2.4 Gbps, and all other links to
640 Mbps.  Steady paths and core paths were established before the experiment.

In both attack scenarios, the attackers (compromised hosts) are distributed
uniformly at random in different ASes\xspace.
Legitimate sources reside in two ASes\xspace (i.e., each AS\xspace contains 100 legitimate
sources).
We further use the same parameters as the related work: a
5\% rate limit for reservation requests, and request packets of 125 bytes.
All the sources (including attackers) send 10 requests per second.  According
to Mirkovic et al.~\cite{mirkovic2009test}, we set 4 seconds as the request
timeout.

\paragraph{DoC Attack} We simulate both intra-ISD\xspace and inter-ISD\xspace DoC attacks.
For the intra-ISD\xspace case, source and destination ASes\xspace are within $ISD_2$, and $ISD_2$
contains 1\,000 contaminated ASes\xspace. All the requests, from benign and
malicious ASes\xspace, traverse the same link in the core.
In the inter-ISD\xspace scenario, the source resides in $ISD_1$ and the destination resides in
$ISD_2$, there are 500 contaminated ASes\xspace in each ISD\xspace, and all
the requests traverse the same links in the core.

Figures~\ref{fig:intradoc} and~\ref{fig:interdoc} show the fraction of
successfully delivered capability requests (\textit{success ratio}) correlated
to the number of active attackers. For both cases (intra- and inter-ISD\xspace DoC
attacks), TVA and Portcullis perform similarly: on core links, legitimate
requests mingle with malicious ones. Afterwards, since the link bandwidth
decreases after traversing the core, there is a rapid increase in the request
packets' queueing time.  Consequently, the success ratio decreases. TVA's
success ratio stabilizes around 40\%.  Portcullis uses computational puzzles,
and the request packets with a higher computational level are forwarded first.
Hence, when more attackers with optimal strategy~\cite{Parno2007} appear, the
time to compute a puzzle increases accordingly, leading to a decrease of the
success ratio to 0 when the computation time exceeds 4 seconds. In STRIDE, the
ISD\xspace core has no protection, but traffic inside $ISD_2$ has a higher priority
than traffic coming from $ISD_1$. Thus, during the intra-ISD\xspace attack, STRIDE's
success ratio stays 100\% until the core becomes congested.  However, in the
inter-ISD\xspace case, STRIDE's performance declines dramatically, since a majority
of requests from $ISD_1$ are dropped if any core link in $ISD_2$ is congested.
SIBRA\xspace successfully delivers all the legitimate requests, in both attack
scenarios, because SIBRA\xspace requests are launched using steady paths, and steady
paths guarantee a fair share of control traffic along core paths.

\paragraph{Coremelt Attack} We simulate a Coremelt attack with the following
settings: $ISD_2$ contains 500 pairs of contaminated ASes\xspace (selected uniformly at
random),
which communicate using ephemeral paths, each with a throughput
of 8~kbps of their 256~kbps reservations.
The source and the destination also communicate
using an ephemeral path, of 800~kbps. All the ephemeral paths in the experiment
traverse the same core link.  We measure the bandwidth obtained when the source
sends to the destination a 1 MB file.

Figure~\ref{fig:coremelt} shows that the congestion on the core link degrades
the file transfer time in STRIDE to over 100 seconds.  TVA, which uses
per-destination queues to forward authorized traffic, performs slightly worse
than Portcullis, simulated using per-source weighted fair sharing based on the
computational level. SIBRA\xspace outperforms the other schemes, because it gives a
lower bound on the bandwidth obtained for the file transfer, due to its
weighted fair sharing based on the steady paths.

\begin{figure}[t]
   \centering
   \includegraphics[width=\columnwidth]{mix2.pdf}
   \vspace{-5mm}
   \caption{Simulation results on SIBRA\xspace's availability. (a) shows
   the existence of the reservable bound for bandwidth requests. Note that the
   bandwidth (green line) in the figure is multiplied by 20 for improved readability.
   (b) presents the resilience of bandwidth reservation against
   packet loss.}
   \vspace{-7mm}
\label{fig:mix}
\end{figure}

\subsection{Lower bound on bandwidth fair share}\label{subsec:bound}

\noindent
We simulate the bandwidth obtained by new ephemeral paths when requests for
ephemeral paths arrive from both benign and malicious sources.  We considered a
scenario where all the requests are forwarded using the same steady down-path
(SIBRA\xspace's worst case for weighted fair sharing).

The legitimate steady up-path from the source AS\xspace carried 5 requests per
second, and has a bandwidth of 362~kbps.  There were approximately 50 attackers
on every malicious up-path, and each attacker sent one request per second. The
attackers' steady up-path bandwidth was randomly selected from our steady
bandwidth classes (16~kbps to 724~kbps).  The bandwidth requested for
ephemeral paths ranged from 256~kbps up to 11.6~Mbps.

The result for this setting is presented in Figure~\ref{fig:mix}(a). The green
line shows the real-time reservable bandwidth, that changes dynamically but
finally stabilizes around 2.5 Mbps. At time interval 100, the number of
attackers and steady up-paths used for requesting ephemeral paths increases.
However, SIBRA\xspace guarantees that reservable bandwidth remains stable despite the
increasing numbers of attackers.  This is due to the fair share, which is not
affected by the number of attackers with steady paths.

\subsection{Reservation request loss tolerance}

\noindent
Next, we simulate the influence of packet loss on ephemeral bandwidth reservation. We
assume that at every second there are 1\,000 reservation requests sent, with the
following parameters: variable path length (5--10), random bandwidth
(50~kbps -- 6.4~Mbps), variable
packet loss rate (0--10\%), and RTT set to 1 second. Similar to
Portcullis~\cite{Parno2007} and TVA~\cite{yang2005tva}, we assume that request
packets are limited to 5\% of the entire link capacity.

In our simulation, we consider packet loss for both reservation request and
reply packets.  This setting introduced unused bandwidth reservation on the
routers that had already processed the packet, until bandwidth reclaim occurs.
We express the bandwidth waste rate $r_{\mathit{waste}}$ as unused reserved
bandwidth divided by the sum of reserved bandwidth.

As shown in Figure~\ref{fig:mix}(b), even at a loss rate of 5\%, the
corresponding $r_{\mathit{waste}}$ is no more than 1.4\%.  Moreover, the diagram
indicates that $r_{\mathit{waste}}$ increases linearly when the loss rate rises,
which shows that SIBRA\xspace tolerates packet loss well, thus providing robust
bandwidth reservation.

\subsection{Bandwidth reservation setup}\label{subsec:request}

\paragraph{Sender implementation}
A reservation request initiator specifies the following configuration
parameters: a flow ID ($128$ bits), a reservation expiration time ($16$ bits),
bandwidth classes for forward and/or reverse directions ($5$ bits each), a path
direction type ($2$ bits), and a reservation index ($4$ bits). SIBRA\xspace considers
time at a granularity of $4$ seconds (which we call \textit{SIBRA\xspace seconds}). By
default, steady paths thus have an initial lifetime of $45$ SIBRA\xspace seconds, and
ephemeral paths of $4$ SIBRA\xspace seconds; nevertheless, these paths can be renewed
at any time. All reservations start at the request time.

We chose SIBRA\xspace's bandwidth classes to cover a meaningful range for steady and
ephemeral traffic: there are $12$ steady bandwidth classes according to the
formula $16\cdot{\sqrt{2^i}}$~kbps, where $i \in \{0,1,\ldots,11\}$, ranging
from 16~kbps to $\sim$724~kbps; and $20$ ephemeral bandwidth classes according
to the formula $256\cdot \sqrt{2^i}$~kbps, where $i \in \{0,1,\ldots,19\}$,
ranging from 256~kbps to $\sim$185~Mbps. The exponential growth allows for a
fine-grained allocation of smaller bandwidth values, but more coarse-grained
allocation of larger bandwidth values. Additionally, it enables efficient
monitoring of flow renewals, with a small number of classes having comparable
bandwidth.

The path direction type is a flag that indicates, for a $\langle
\mathit{requester},\mathit{destination} \rangle$ pair, either a uni-directional
reservation, for traffic either sent or received by the requester; or
bi-directional, for traffic sent and received by the requester. The reservation
index is a number specific to a flow, incremented every time the reservation
corresponding to the flow is renewed.

\paragraph{Bandwidth reservation and accounting} To efficiently
manage and account for bandwidth reservations, SIBRA\xspace routers maintain
the following data structures: (1) a \emph{bandwidth table}, i.e., an
array of size $k$ storing the currently reserved bandwidth for each
of the router's $k$ neighbors; (2) an \emph{accounting table}, i.e.,
a table with tuples containing the flow ID of a reservation, the
expiration time, the bandwidth class, and the neighbor to/from whom the
reservation is specified; (3) a \emph{pending table}, i.e., a table
(of similar structure as the accounting table) that stores pending
reservations. A reservation is said to be \emph{pending} if it has
been requested, but not used for data transmission. A reservation
with flow ID $i$ is said to be \emph{active} when data has been
transmitted using $i$, i.e., the router has seen $i$ in a data
packet. A reservation for $i$ is said to be \emph{expired} if the
router has not seen packets containing $i$ within a time frame of
$\ell$ SIBRA\xspace seconds (details below).

To decide whether a requested amount $\mathit{bw}_r$ can be reserved,
routers perform admission control by comparing $\mathit{bw}_r$ with
the entry in the bandwidth table for the specified
neighbor.\footnote{The reason for considering only the current amount
of available bandwidth when making the admission decision is
justified by the monotonicity of reservations: reservations can never
be set up to start in the future, hence, in the next SIBRA\xspace second,
there cannot be less bandwidth available than in the current SIBRA\xspace
second (unless new reservations are requested).} In case sufficient
bandwidth is available, the request's flow ID, the expiration time, the
request's bandwidth class, and the neighbor are added to the pending
table. The requested amount $\mathit{bw}_r$ is also added to the
respective entry in the bandwidth table. Yet, at this point, the
router does not add information about the request to the accounting
table. The reason is that the request may fail at a later point, in
which case the accounting table update would have to be reverted. In
a periodic background process, the router checks whether there are
entries in the pending table older than $300$ milliseconds
(sufficient to allow for an Internet round trip
time\footnote{http://www.caida.org/research/performance/rtt/walrus0202
 }). Such entries are considered failed reservations, and thus they
are deleted from the pending table and the corresponding reserved
bandwidth is freed and updated in the bandwidth table.

If the router sees a data packet with flow ID $i$ for the first time,
it implies that the reservation for flow ID $i$ was accepted by all
routers on the path. The reservation becomes active and the entry
with flow ID $i$ is then removed from the pending table and added to
the accounting table.

To periodically reclaim unused ephemeral bandwidth of expired
reservations, a router periodically removes the amount of expired
bandwidth from the bandwidth table. The expiration parameter $\ell$
(e.g., $1\le\ell\le 5$) specifies the lifetime (in SIBRA\xspace seconds) of
pending reservations. In order to keep reservations active (even if
no data is transmitted), a source simply sends a keep-alive message
within $\ell$ SIBRA\xspace seconds. In a periodic background process, the
router then iterates over the accounting table's entries that
correspond to the last $\ell$ SIBRA\xspace seconds. More specifically, the
router checks whether the listed flow IDs occur in a Bloom filter
that is filled while forwarding data packets: to enable fastpath
operation, the flow ID of each incoming data packet is stored in a
Bloom filter, not in the accounting table. Bandwidth reclaim is then
processed in the slowpath.

\paragraph{Intermediate AS\xspace implementation}
The MAC operation of RTs are implemented using CBC-MAC based
on AES. Our AES implementation uses AESni~\cite{aesni}, a fast instruction set available on
Intel and AMD CPUs, which requires only 4.15 cycles per byte to encrypt a 1 kB
buffer in CBC mode.  The key necessary for the MAC operation is
expanded once at the AS\xspace and then used for all RTs generated by that AS\xspace.
SIBRA\xspace uses 32 bits for MACs, which constitutes an optimization,
yet provides sufficient security: a forgery will be detected
with probability $1-2^{-32}$.

During a reservation request, the header for the positive admission of a flow
contains the request configuration values set by the sender and the list of RTs
generated so far.  A field \texttt{Hops} is used to locate the correct offset
for a newly generated RT. In addition, a field \texttt{Extension Flag}
indicates the request path type (bi-/uni-directional), the request status
(successful or failed), and whether the packet carries a reservation request or
a reservation confirmation.

When a request does not pass the admission control, then the corresponding
router sets the extension flag to failed, marks its own AS\xspace in the
\texttt{Decline AS*} field, and resets \texttt{Hops} to zero. Starting with
this AS\xspace, every subsequent AS\xspace on the path towards destination\xspace adds a
\texttt{Bandwidth Offer} field with the offered bandwidth.

We implemented SIBRA\xspace on top of a SCION-enabled network, which provides path
control. Our SIBRA\xspace implementation provides end-host support through a
SIBRA\xspace-enabled gateway, which contains modules for reservation requests and
their confirmation, SCION encapsulation, decapsulation, and a \textit{traffic
hijacking} module. The last element is implemented via NetFilter
Queue~\cite{nfqueue}, and it allows to tunnel legacy IP traffic to a remote
host through the SIBRA\xspace-enabled SCION network. Such a design provides SIBRA\xspace's
benefits to legacy software, as well as facilitates SIBRA\xspace's deployment.

The SIBRA\xspace packet header contains SCION-relevant information, such as src/dst
addresses, forwarding path as opaque fields (OFs), the current OF/\textsc{RT}\xspace
indicator, and an optional extension field in which SIBRA\xspace's reservation request
messages are encoded. We implemented SIBRA\xspace in SCION using \textit{extension
headers}.

\section{Introduction}
\label{sec:introduction}\label{sec:intro}
\input{introduction}

\section{Goals, Assumptions, and the Adversary}
\label{sec:probdef}
\input{probdef}

\section{SIBRA\xspace Design}
\label{sec:path}
\input{design3}

\section{Implementation}
\label{sec:imple}\label{sec:implementation}
\input{implementation}

\section{Evaluation}
\label{sec:eval}\label{sec:evaluation}
\input{evaluation}

\section{Incremental Deployment}
\input{deployment}
\label{sec:deployment}

\section{Use Cases}
\input{use-cases}

\section{Discussion}
\label{sec:discussion}\label{sec:discuss}
\input{discussion}

\section{Related Work}
\label{sec:related}
\input{related}

\section{Conclusions}
\label{sec:conclusion}
\input{conclusion}

\section{Acknowledgments}

\noindent
We would like to thank Virgil Gligor, Chris Pappas, Christian Rossow,
Stephen Shirley, and Laurent Vanbever for insightful discussions and their valuable
comments throughout the evolution of this project. We also thank Xiaoyou
Wang, Dominik Roos, and Takayuki Sasaki for their help with the implementation and evaluation of SIBRA\xspace.

The research leading to these results has received funding from the European
Research Council under the European Union's Seventh Framework Programme
(FP7/2007-2013) / ERC grant agreement 617605.  We also gratefully acknowledge
support by ETH Zurich, and NSF under award number CNS-1040801. The research was
also supported by a gift from KDDI.

\bibliographystyle{IEEEtranS}

redpajama_set_name: RedPajamaArXiv


Car Wrecker NZ supplies Quality and Cheap Used Car Batteries. When it comes to batteries, nobody has you covered like Car Wrecker NZ.
If you do require a new one, we'll help you find the right battery for your vehicle and driving habits. We sell battery from $45(Incl. GST) + exchange. Second hand car battery we sell comes with one month warranty.
We always test all our batteries before we give it you. We have batteries available of all size and cars.
We have batteries to suit all sorts of vehicles including Cars, Van, 4WD or Trucks.
If your battery goes flat, or is even showing signs of giving-up, we are here to help you get back on the road safely and swiftly.
Need Batteries for your car? Buy it from our car wrecking yard. Why spend money on new ones when our second-hand batteries are just as good as new batteries.
Our battery prices are the cheapest and lowest in Hamilton.
We will find a right battery for your car. Not only will you have battery that is as good as a new but you will have it at a quarter of the price of a new one.
For the quickest response, please use our online quotation form and do not hesitate to contact our experts for further queries.


text:
Back to customers page
Technology Deployed
Download Full Story
Dental Focus International is a network of dental clinics and professionals that provide variety, diversity and accessibility to dental care throughout Singapore. Its mission is to deliver patient centric dental services in a modern setting using the latest technology, while making dentistry affordable and accessible to all patients. Dental Focus provides a wide range of services, from preventive dentistry and wisdom teeth extraction to root canal and Botox treatments.
Over the years, the company has grown rapidly, expanding to 18 locations within Singapore.
"Axxis Consulting has provided us with a flexible platform for growth and real-time insights that will fuel Dental Focus' expansion for years to come. - Nerissa Leaw, Finance Manager"
Continuous growth and various expansions over the years have resulted in disparate systems and processes. Existing financial processes were also outdated and very time-consuming as financial and customer data was entered and tracked manually through Excel.
The management team needed to find a system that will allow them full visibility into the organisation and overall business operations, giving them real-time data and insight to make timely and accurate business decision. They also needed to a solution that will help them standardize business processes across the organisation and improve overall organisational efficiency by eliminating redundant activities.
In addition, the team also wanted an inventory management system which will help them track and manage inventory throughout its network of clinics.
Working with Axxis Consulting, SAP Business One was identified as the ideal solution for Dental Focus.
Through the SAP Business One system, the management team will be able to get full visibility into the whole organisation from a single platform with real-time data being tracked every second for quick and accurate decision-making. It will also help Dental Focus standardise business processes and remove time-wasting redundant activities, improving overall organisational efficiency and employee productivity.
SAP Business One's finance module complete set of tools will also allow Dental Focus to manage cash flow, view financial statements and streamline financial processes easily. Its inventory and distribution module will also be able to manage and track inbound and outbound shipments, inventory and item location, among other things, satisfying Dental Focus needs for an inventory management system.
Axxis Consulting was able to implement SAP Business One off-site and complete the project with two months, minimising the disruption of Dental Focus' daily operations. With scheduled workshops, users were also sufficiently equipped with the skills to use the system before the system went live.
After the implementation of SAP Business One to its 18 clinics, Dental Focus has seen significant improvements and benefits of the system to its overall organisational efficiency.
The Group plans on integrating Business One with their in-house clinic system in the near future, allowing them to further consolidate information and streamline business processes, simplifying their IT landscape.
Yenom
Jamiyah
Kyoei Denki
Interested to find out more?
We've helped countless customers across Singapore & Malaysia to drive business impact through the usage of leading edge technology. We'd love to see how we can help you.
Drop us your details and questions and we'll contact you shortly.
Get your answers immediately by engaging with us via LiveChat.
Or just give us a call on any of our country numbers.

redpajama_set_name: RedPajamaCommonCrawl


For the first time, all of Lascaux is revealed. A complete new replica retraces the discovery of the famous decorated cave. But that's not the end of the adventure: the entire site inquires into the position that Lascaux occupies in cave art and its relation to contemporary creation. The opening of the International Centre for Cave Art marks the beginning of a new adventure combining the emotion of ancestral art and an important technological achievement.
The complete replica of the original cave is the culmination of three years of work in the Perigord Facsimile Studio. This new space welcomes visitors, inviting them to contemplate the works and experience the authentic emotion felt at the discovery of the cave, to observe, to enquire into the reasons for its existence and to reflect on the environmental and cultural context in which it was decorated.
The architecture of the International Centre forms an integral part of the visitor's experience: a half-buried building at the foot of the Lascaux hill, it is perfectly integrated into the landscape. A gigantic glass front invites the public to visit a universe firmly focused on technological prowess.
Starting with its shape: there are no straight walls, a tangle of rooms with atypical shapes leads the visitor to the heart of a building of 8,000 sq m. A fault running its whole length evokes a gash in the hill or a prehistoric stratum recalling the passage of time.Continuing with its content: the various spaces with their uncluttered style and modern aesthetics contain the latest digital tools (enhanced reality, 3D screens, etc.). They incite the public all through the visit to enjoy an immersive and personalized experience.
Professional guides will accompany the groups from the site's welcome desk (where digital tour companions are distributed) to the exit of the complete reproduction of the cave. Additional guides will be present in all theme rooms to answer questions and impart information to enrich the Lascaux tour.
Accompanied by a guide and a tour companion (interactive digital tablet providing information determined by onsite localisation, in 11 languages, including the major European ones) visitors to the International Centre access the roof of the building by means of a lift.
From the belvedere overlooking the Vézère Valley, listed as a UNESCO world heritage site, visitors are free to take in the view with their tablets. When the landscape is scanned a virtual reality map appears, pinpointing in particular the location of all surrounding major archaeological sites open to the public.
Next, visitors are invited to enter a shelter where they place themselves in front of a screen. The image of the Lascaux hill appears through this canvas as if one was looking out a window. The live image takes the visitor on a virtual trip outside, changing the landscape according to the hour and the season.
Time travel can now begin. The giant screen gives us a view of the Vézère Valley almost 20,000 years ago when the landscape of Lascaux was totally different from today, and looked like a steppe dominated by animals. Another leap and we fast forward to 1940. The landscape changes. A group of four adolescents crosses the screen. They head off on an adventure in the woods of Lascaux and invite the public to follow them.
The replica represents the whole of the original cave accessible to the public, reproduced with the techniques and the art of the Perigord Facsimile Studio (PFS) and the Artistic Concrete Atelier (AAB).
Inside the replica, the atmosphere is like a real cave. It is cool and dark. Sounds are muffled. Visitors can appreciate the splendour of the works in an authentic atmosphere with very few interruptions. This space is dedicated to contemplation.
Groups of no more than 32 visitors accompanied by a guide ensure that each visitor's experience will be as personalised as possible. During the time devoted to contemplation of the walls, the guide will accompany the group and provide information to enrich the visitor's knowledge of the site.
Eight large walls of the cave are reproduced in this space where visitors are free to circulate. All the cave's major works are represented: "Two Crossed Bison", "The Great Black Cow", "The Panel of the Imprint", "The Apse", "The Shaft Scene", "The Axial Gallery", "The Upside-Down Horse" and "The Hall of the Bulls". In enhanced reality, visitors find information on the various representations, techniques and interpretations.
The model : discover the cave in a completely original way with virtual reality! Using the tour companion, visitors can scan the surface of this model to see the works located at various points inside the cave.
The art experience : with the same tools and techniques used by Palaeolithic humans, visitors can create their own works of art virtually. This space shows everything one needs to know for understanding the techniques, tools and choices of these artists.
A fragile balance : how did the cave survive the passage of time? Why was it closed to the public? How can we continue to preserve it on a daily basis? All these questions that you ask yourself are answered in a new immersive experience made possible by the latest technologies.
The Lascaux objects : here you can handle the objects found during archaeological dig sand learn more about them. A number of different objects are assembled on an animated table like an archaeologist's. A video provides information on these finds and the dating techniques used for understanding Lascaux. Two touch-screens placed on the edge of the table present an interactive chronology showing Lascaux's place in the history of humanity.
Visitors enter a modern theatre or rather a series of "small rooms" showing scripted plays organised in three acts.
Act I – 19th century: Renaissance. When the first door opens, the visitors enter a room that takes them back in time. They find themselves in the 19th century at the time of the Universal Exposition of 1878. There they discover the first decorated caves and engage with pre-historians who are asking themselves about these discoveries and their authenticity. Could prehistoric man really have painted such masterpieces ?
Act II – 20th century: Interpretation. Inside this room, a scripted play brings to life the ideas and methods of two famous pre-historians of the 20th century: André Leroi-Gourhan and Abbé Henri Breuil. You are entering the world of the great adventurers and archaeologists of the last century, revolving around the main archaeological discovery of the 20th century: the Lascaux cave.
Act III – 21st century: Research. This act is resolutely looking to the present and to the future. The public witnesses the incredible world of state-of-the-art technology, used by contemporary researchers and archaeologists. In the context of a research laboratory, the play presents the research techniques of today!
Wearing 3D glasses, visitors take seats facing two giant screens. A multi-screen 3D film proposes a unique visit of the Lascaux cave. The first screen shows images made from 3D surveys of the original cave. The second presents scenes of other decorated caves around the world. In this way, the audience can get a close look at the works.
This commented film entitled "Lascaux and the World" takes the audience to the heart of the Hall of the Bulls, the Axial Gallery, the Passage, the Nave, the Apse and the Shaft…and features the world's different decorated caves, with their animal representations and signs…Get ready for a strikingly realistic experience.
This room explores the connections between various art works from cave art to contemporary art. The surrounding wall with 90 screens composed of images of works by well-known artists such as Miró, Tapies or Picasso make up this unusual exhibition. Jean Paul Jouary, philosopher and curator of the exhibition, has selected various works linked to the universe of Lascaux: depending on the techniques, the themes, the types of representation and his artistic inspiration, he explores the connection existing between cave art and contemporary art.
Six interactive displays face the public. Visitors are asked to compose their own exhibition by a choice of images. This selection of images from modern art combined with images from cave art can be assembled into a single exhibition, according to the visitors' wishes, and seen by all.
For the inauguration of the International Centre for Cave Art, beginning 15 December 2016, the exhibition hosts the work of Gérard Gasiorowski (Paris, 1930 – Lyon, 1986).
After training at the École des Arts Appliqués between 1947 and 1951, Gérard Gasiorowski progressively gained a place on the artistic scene between 1964 and 1972. This painter's "precisionist" work features the enhancement of choice images he collected from his time as a librarian at the Delpire publishing house.
The discovery of the cave represented a crucial moment in his life as a man and as a creator. From this encounter stemmed an extraordinary series of works, a selection of which will be presented here.
la grotte ont connues en 1940.
entre l'art pariétal, l'art moderne et contemporain.
exposition, au gré des visiteurs, et visible de tous.