SWIFT is the first BGP fast reroute framework that works upon
remote transit outages. Remote outages are challenging because
they can happen in any network, at any time, and can affect any set of
destinations. Furthermore, the Internet converges slowly upon remote
outages, resulting in downtime for users.
SWIFT has two key ingredients. First, it quickly localizes
the outage and predicts the affected traffic. Second, it reroutes the
affected traffic to unaffected backup paths with just few data-plane rule updates
using precomputed data-plane tags and a 2-stage forwarding table.
Is SWIFT useful if PIC or MPLS Fast Reroute are used already? Yes
Prefix Independent Convergence (PIC) and MPLS fast reroute only work upon local failures
(e.g., on your peering links), not the remote ones (e.g., in your neighbor's network).
SWIFT works both upon local and remote outages.
Is SWIFT deployable on an arbitrary set of nodes? Yes, under reasonable assumptions
We proved that SWIFT rerouting
(i) causes no forwarding loop and (ii) can only be beneficial,
irrespective of the set of SWIFTED routers.
As a result, you can safely deploy SWIFT in one or all your routers,
independantly of whether other ASes also deploy SWIFT or not.
Does SWIFT require to cooperate with other networks to be deployable? No
SWIFT does not require any modification of BGP. In addition, data-plane tags
are not propagated to other routers. They
are added by the SWIFTED router (in the first stage of the forwarding table)
and removed by the SWIFTED router as well at the egress.
For example, if the destination MAC header field is used for the data-plane tags, the
SWIFTED router modifies the destination MAC field in the first stage of
the forwarding table, and simply removes the tags in the second stage of the forwarding table
by setting the destination MAC address of the actual next-hop .
Deploying SWIFT is therefore invisible for the other networks and thus no
cooperation is required.
Does SWIFT update the backup next-hops when it receives a BGP advertisement or withdrawal? Yes
Whenever the SWIFTED router receives an advertisement or a withdrawal for
a prefix, it recomputes the backup next-hops to use for that prefix in
case of a failure, and update the data-plane
tags accordingly. Only one data-plane rule update is required in the
first stage of the forwarding table to update the data-plane tags for a prefix.
Does SWIFT comply with routing policies? Yes
When SWIFT computes the backup next-hops, it can take into account policies
defined by the operators. For example, operators can prevent SWIFT from
using an expensive link with a provider rather than a more convenient one
with a cutsomer.
Does SWIFT lose traffic if it reroutes unaffected prefixes (false positives)? No, under reasonable assumptions
When SWIFT reroutes, it always uses valid backup paths.
Thus, rerouting
the traffic for a unaffected prefix will not result in downtime for that prefix.
However, other metrics such as the delay or the jitter can change during the
rerouting process for that prefix.
SWIFT: Predictive Fast Reroute,
SIGCOMM'17.
Los Angeles, USA. July, 2017.
(paper,
technical report,
bibtex)
by Thomas Holterbach, Stefano Vissicchio,
Alberto Dainotti, Laurent Vanbever
Boosting the BGP convergence in SDXes with SWIFT,
SIGCOMM'17.
Los Angeles, USA. July, 2017. Demo (paper, poster, bibtex)
by Philipp Mao, Rudiger Birkner,
Thomas Holterbach, Laurent Vanbever
We release a Python-based implementation of SWIFT and its algorithms.
You can use our implementation to quickly evaluate
the benefit SWIFT would provide on your BGP data.
The source code is publicly available
on GitHub.
We provide a VM to show SWIFT in action.
Just run one script in the VM and a virtual network
with Quagga routers is built.
Simulate a remote failure
and see the benefit of SWIFT!
You can download the VM here. The
instructions on how to use it are available in the GitHub
repository.