hesy summary

FRR (fast rerouting
reverse path forwarding (RPF)
光看related work其实还是不是很明白别人做的是什么

abstract

在大型网络中，故障是常见的，而不是例外。为了向上层应用提供高质量的服务，期望在发生故障时能够快速启动融合备份路径。在本文中，我们设计了一种基于IP的快速重路由(IP based Fast ReRouting)方案，该方案称为Metro，它可以解决任意单个链路/节点故障且后备路径扩展性低的情况下的流量重路由收敛问题。
当网络中发生故障时，Metro首先指示将受到故障影响的所有网络区域，然后查找一些网桥链接以将受影响的网络区域中的流量排放到不受故障影响的网络区域。这样，Metro无需配置隧道，封装或修改数据包，因此易于在当前网络中部署。大量的仿真表明，Metro可以解决备用路径比最新解决方案短的任意单链路/节点故障，并且Metro中约98％的备份路径延伸与最佳隧道方案相同。

1 introduction

ISP网络或数据中心网络的网络都遭受无法预测的故障。发生故障时，一个或多个网络组件（例如节点和链接）将无法传递流量，从而导致大量流量损失[1]，[2]。此外，这种流量丢失可能给网络顶部运行的应用程序带来较大的响应延迟。由于当前网络中的许多应用程序都对延迟敏感，因此较大的响应延迟可能会大大降低应用程序性能和用户体验。因此，在网络故障发生后，需要快速重路由（FRR）方案来快速恢复流量传递。为了使恢复时间最短，在这项工作中，我们集中于预先计算重新路由路径以应对网络故障的方案。 FRR机制的主要关注点在于如何在效率和有效性这两个重要方面之间做出明智的权衡。一方面，FRR机制应该简单有效，以至于它几乎没有增加数据平面的开销。另一方面，它应该达到理想的保护范围。传统的基于纯IP的FRR机制，例如无环路替代（LFA）[3]和Uturn [4]注重效率，而许多基于隧道的机制则注重有效性。基于IP的FRR的目标是通过使用预先计算的备用IP下一跳将故障反应时间减少到10毫秒。在基于隧道的FRR机制中，有一些是通过多协议标签交换（MPLS）隧道实现的，例如RSPV-TE [5]，[6]，而另一些则是通过IP-in-IP隧道，数据包封装或数据包实现的。标记[7] – [9]。与FRR本身的实现相比，其相应平台的部署要复杂得多，更不用说由其他操作引起的其他问题了，例如数据包分段和封装。
为了兼顾效率和有效性，在本文中，我们提出了Metro，一种用于处理网络故障的高效流量快速重路由方案。就我们所知，Metro是第一个无需隧道的FRR机制，可以处理任意单个链路/节点故障而无需修改任何数据包。与Uturn [4]相似，Metro中的交换机进行反向路径转发（RPF）检查以发出故障信息。但是，Metro对网络拓扑进行了透彻的分析，以便在Uturn相同情况下提供全面的保护。

为了勾勒出Metro的核心概念和方法，我们看一下华盛顿特区真正的Metro（图1）的面料特征。在华盛顿特区的地铁网络中，有许多线路通向中央枢纽站。还可以找到许多秘密通道，这些通道主要由维护人员用于在线路之间快速行驶。如果有人沿着其中一条线路步行到枢纽，并且发现地铁隧道被阻塞，则他/她可以通过这些秘密通道到达其他线路，而其他线路的通向枢纽的路径将绕过阻塞的线路。
Metro遵循地铁架构的相同理念，以实现基于IP的纯FRR。对于网络中的任何目标，Metro通过分析路由树并在分支之间找到桥梁，Metro将受故障影响的分支上的流重定向到其相邻分支。

贡献
我们从理论上证明Metro可以处理任意单链路故障（SLF）和单节点故障（SNF），而无需修改重新路由的数据包。评估真实世界和人工网络拓扑的方法也证实了这一点。
评估还表明，Metro通常会找到比其他FRR机制更短的备份路径来重定向受影响的流。
本文的其余部分安排如下。第二节介绍FRR的背景。第三部分简要介绍了Metro设计。第四，第五和第六部分介绍了设计细节。第七节对Metro进行了实际和人工拓扑评估。最终，第八节总结了本文。

2 Background and relatede works

A. Fast Rerouting

当组件故障(链路故障或节点故障)发生在网络中，重新计算恢复方案，刷新路由表并等待路由信息收敛需要几秒钟到几分钟。在这样的恢复期间，某些数据包可能会由于传递路径不完整或由于将流量转移到绕过故障的链路而导致的临时网络拥塞而丢失。在高速网络中，即使恢复时间很短，也可能导致巨大的数据包丢失[10]，[11]。为了减少网络恢复期间的流量损失，FRR旨在将受故障影响的数据包定向到预先计算的备份路径，这些路径在新路由最终收敛之前便已到达目的地[12]，[13]。
反应时间对于FRR至关重要，因此在发生故障时查找备用路径是不切实际的。转发引擎需要基于预先计算的信息在本地立即对故障做出反应[14]。对于任何FRR机制，全面保护单个故障非常重要，这包括两个方面：

•对SLF的全面保护：对于网络中的任何SLF，如果故障链路的两端仍然连接，则应始终确定一条备份路径从其中一个转移到另一个。
•对SNF的全面保护：对于网络中的任何SNF，如果故障节点没有将整个网络分成多个部分，则应始终为通过该故障节点的每条路径找到备份路径。