承载网保护技术frr

《承载网保护技术frr》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、承载网保护技术-FRR(一)摘要：FRR是一项旨在解决高可靠性网络中，故障发生后信令协议收敛相对较慢的问题，保证流量较少的丢失。FRR技术包括IPFRR、LDPFRR、TEFRR、VPNFRR，分别应用于不同的场景，以保证业务端到端的快速收敛。本文介绍了部分FRR(IPFRR、LDPFRR)技术的实现原理，描述了其部署上的局限性，并给出了一些简单的部署建议。关键词：FRR、IPFRR、LDPFRR、面向连接、无状态、有状态一、背景介绍电信网络发展至今，几网合一、简化网络模型的需求日益迫切。融合后的广义NGN，将形成“承载”和“业务”分离的网络模型，

2、基于“一个核心”承载各种不同的业务。利用MPLS/MBGP技术，基于业务部署的VPN，彻底改变了传统IP网络“尽力而为”的服务模型，提供不同等级的服务承诺，真正实现了对多业务的承载，使得IP作为NGN的承载部分成为趋势。但同时，承载网的角色对IP网络提出了新的需求。电信级高可靠性严格Qos保证网络安全电信级管理本文将针对“电信级高可靠性”相关技术进行讨论。二、高可靠性需求业务需求：语音、视频等业务对延迟和抖动的敏感，对承载网的可靠性要求更高技术层面：IP网络本身用以转发流量的拓扑，以及用来驱动建立MPLSLSP的拓扑，都是靠IP信令协议来建立的。另

3、外，信令协议产生的初衷，便是对拓扑变化的自动感知、重新收敛。到目前为止，IP信令协议在技术上的成熟度，已基本可以让我们信赖其正确性和容错能力。现在，需要解决的，就是速度的问题，对变化的响应速度。收敛，是网络行为。需要在感知环境变化或故障后，作出响应。但是，无论对于何种形式的流量转发，都是本机的操作行为。所以从目前来看，收敛是要滞后于流量转发操作的，两者时间上相差一个数量级。那么，故障发生后，在收敛之前这段存在拓扑黑洞的时间内，如何正确的指导转发，尽量的减少流量的丢失？现在提出一种解决方案——FRR。FRR技术快速重路由——是在故障发生后，依靠之前建

4、立的备用方案，快速的将流量进行重新路由。所以，FRR的重点在于如何在信令层面建立备用方案，即如何进行FRR的方法。而重路由(或重转发)操作本身，只是在设备上实现的简单动作。三、IPFRRIP转发的讨论对于IP转发，根本上来说，其信令协议建立和维护的只是某个节点本身的转发信息，转发也是逐跳进行的单机行为。对于一个节点，只要按照自己的转发信息将流量送往自己的下一跳节点，就已是“尽力而为”了。信令的建立是非面向连接的，或者说是“无状态”的；转发同样也是“无状态”的。IPFRR的实现IP转发所依据的转发信息，主要包括两个部分：区分流量的依据(例如：目的地址

5、)和流量的去向(即下一跳节点)。网络出现故障后，原本的下一跳变得不可达，通过协议的能力一段时间后将重新找到一个可用的下一跳。但是，为了在一个新的可用下一跳被找到之前，使流量不丢失或很少量丢失(依据产品实现性能)，我们可以人为地为原本的下一跳指定一个备用的下一跳。在检测到原本主用下一跳不可用时，直接将流量倒换到备用下一跳节点，同时等待协议收敛将转发信息刷新。IPFRR在信令层面建立备用转发方案时，是针对转发条目信息(或者说其中的“目的地址”元素)，为其人为指定备用下一跳。因为是纯粹的本机行为，所以只要相应的转发条目存在，便可在本地成功的实现。并在故障

6、发生后迅速切换，临时指导转发，将流量倒换至人为指定的备用下一跳。IPFRR局限性IPFRR备用方案的建立，不会对协议建立的原有拓扑和流量转发有所影响。即本机的动作，包括备用方案的建立和流量的转发，都不会影响其下一跳节点以及其备用下一跳节点。然而，临时状态中，流量在被倒换至备用下一跳之后的去向和状态，我们便不得而知。请考虑如下拓扑：LRNRBNRLR=LocalRouterNR=NexthopRouterBNR=BackupNexthopRouter例一：假如链路cost如图分布时，将形成如下流量模型1010105010100LRNRBNR当LR和N

7、R之间的链路故障，或者NR故障时，IPFRR形成的备用转发方案不可用。例二：假如链路cost如图分布时，将形成如下流量模型1010010105050LRNRBNR当NR发生故障时，IPFRR形成的备用转发方案不可用。此时，需要为备用方案再提供备用方案，同时导致故障发生后的状态不可控。IPFRR是完全的单机行为，备用下一跳路由器的下一跳，不能是自己本身或自己的主用下一跳。总之，必须在网络方案的设计上来规避IPFRR的局限性，必要时全网实施，以保证其部署后的可用。IP的FRR可以称之为FRR，因为信令建立和流量转发都是单机行为。对于本机而言所需要知道的

8、仅仅是下一跳在哪而已；所需要做得仅仅是独立的完成自身这一跳的转发，而IPFRR已完成了自己的这种职责。IPFRR部署建议组