浅谈SR-TE两种实现方式的对比
source link: https://www.sdnlab.com/24082.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
作者简介：熊学涛，北京世纪互联宽带数据中心有限公司网络运维中心，网络运维总监。近二十年运营商、互联网公司工作经验。在超大规模数据中心组网、运营商级广域网领域有着丰富的项目经验，毕业于西安电子科技大学通信工程学院，华南理工大学工程硕士。
1.背景技术简述
关于IP转发技术经历的几个阶段，凭个人的浅显理解简单梳理如下。
最初IP数据包根据路由协议构建的转发表来转发。路由协议对目的地址寻址，通过对全网拓扑和链路状态的学习来建立RIB表，同时优选到达目的路由Metric值最小的路径的下一跳写入FIB表（Metric值相同的下一跳负载均衡）。依靠路由协议转发，路径中间每一跳路由器都会查找本地FIB表进行转发，网络中业务流量的转发路径只能按最优路径（Metric值最小的路径）转发，不能预先编程设定和精确控制路经。
在原有转发技术的基础上，MPLS技术作为一种2.5层技术，通过LDP协议来为网段分配标签，建立标签转发表，以标签转发替代三层路由转发，提升了转发效率。
为了解决传统IP路由器协议只能最优路径（Metric值最小的路径）转发，无法精确规划转发路径的问题，基于MPLS发展出了RSVP-TE隧道技术。RSVP-TE确实在一定的时期内代表了先进生产力的发展方向，并在一定范围和场景下得到了大量应用。RSVP-TE可以进行显式路径规划，可以实现带宽资源预留，但是RSVP-TE控制面复杂、配置也复杂，状态维护消耗性能还不支持ECMP。概括一下，RSVP-TE太重量化，太复杂了，不能完全适应在大型广域网内的大规模应用。
SR-TE依然保留和利用了MPLS标签（SRv6不在本文讨论范围内），扩展路由协议支持SR标签的分发，省去了LDP协议，报文头中的Segment List直接包含了路径信息，在头节点就可以控制路径，也不需要像RSVP-TE一样进行大量的状态维护。概括一下，SR更加适应大型广域网的大规模流量工程场景，也更加适应SDN对网络业务流量转发路径集中控制的要求。
本文就浅谈一下SR-TE路径建立及控制的两种实现方式Tunnel Interface和SR Policy的对比，看看在那些方面SR Policy方式比Tunnel Interface方式有较大的优势和提升。
2.SR Policy 对比Tunnel Interface的优势与提升
SR-TE分为SR Tunnel Interface和SR Policy两种实现方式，或者说两个体系，先说结论，SR Policy确实是后起之秀，最早由思科提出这个概念和相关技术标准，较短时间内，目前主流厂家路由器均开始支持SR Policy。
Tunnel Interface是隧道接口，是两个网元之间的一个虚拟连接，所以Tunnel Interface的SR-TE类似于传统LSP技术，以虚拟接口的方式实现对业务流量的导入。Tunnel Interface的路径下发与更改，其来源可以是CLI，也可以是SDN的南向接口PCEP / Netconf，最终要映射为在头节点路由器上的一条实际的隧道和隧道路径的配置。
SR Policy定义的是网络的一种策略，只是这种策略包含了一个业务流量的承载诉求和转发路径。SR Policy由（head-end、color、end-point）三元组描述决定。SR Policy的来源可以是CLI，也可以是SDN的南向接口BGP / PCEP / Netconf。
目前BGP for SR Policy是业内发展比较快应用比较广泛的一种SDN南向接口，相关的标准大家可以参阅draft-ietf-idr-segment-routing-te-policy-08（Advertising Segment Routing Policies in BGP）。详细介绍SR Policy不是本文的重点，本文将简单的去总结一下SR Policy对比Tunnel Interface的优势与提升。
2.1.SR Policy更灵活实现业务流量引流
Tunnel Interface方式的SR-TE本质上还是一个网络层面的隧道接口，相关的业务流量的导入和引流需要借助于传统PBR的方式来实现。MPLS-VPN场景可以直接将VPN流量over在Tunnel Interface的SR-TE上，此时Tunnel Interface的隧道替代了LDP转发隧道。
BGP for SR Policy则可以实现基于业务流量的自动引流。如图1中所示，End-point基于BGP路由1.1.1.0/24的Community值来设定Color为Red，Head-end通过BGP协议学习到设定了Color值的NLRI。对head-end设备下发SR Policy，此SR Policy的BSID为4001，对于Color为Red的流量，设定优选Candidate path为SID-LIST。根据此SR Policy，head-end设备对Color为Red相关的去往1.1.1.0/24的流量，按照BGP路由转发遵从BSID为4001的SR Policy，数据头部压入相应的SID标签栈。中间路由器根据head-end的压入的SID标签栈路径完成转发。所以SR Policy的SR-TE引流自动完成，不需要配置PBR。
2.2.SR Policy更灵活实现差异化服务
使用QOS策略进行差异化服务和保障是传统方式，但是受限于DSCP的8个等级的限制，而且差异化服务的实现是逐跳转发设备的QOS保障来实现的，无法将业务流量和承载路径相绑定，通过优化路径来实现差异化服务。
2.2.1.SR Policy设定Color值将业务承载诉求映射为隧道能力
Tunnel Interface场景进行差异化服务的实现，依靠两点间不同的业务流量承载需求建立不同的Tunnel Interface隧道（低时延隧道、高保障隧道等），再在头节点通过PBR将业务流量引入相应的SR-TE内。 需要对业务流量进行调优时，可以通过变更隧道路径或者变更流量所承载隧道来实现。
SR Policy中，通过Color来表征不同的承载诉求，Color不代表某条实际的隧道，而代表一类承载能力的隧道的集合，如RED为低时延类的业务诉求，Green为时延不优选但高带宽保障类的业务诉求。Color值没有DSCP 8个等级的限制，可以实现更多的保障等级。Color在某种程度上成为了业务承载诉求和实际隧道之间的中介，业务流量不直接定义和具体隧道的映射关系，只表达自己的承载诉求并和相应Color的SR Policy进行关联。
SR Policy的差异化服务保障场景，目的地址表征了业务流量，相同的业务承载诉求标识为相同的Color，SR Policy通过目的地址+Color将业务承载需求和隧道保障等级相绑定，在业务承载需求有变化时直接变更SR Policy内的Color值就可以。或者换句话说，因为在一个SR Policy中即定义了Color又包含实际的Segment List路径，所以由于定义了Color值，SR Policy对差异化服务和流量路径调优的实现是一致的。
2.2.2.SR Policy可以实现基于VPN内部业务路由的差异化服务
Tunnel Interface在MPLS-VPN承载场景，对VPN内部不同的业务路由，很难区分出来并承载到不同的SR-TE隧道上。
SR Policy在MPLS-VPN承载场景，可以对VPN内的不同路由着色为不同的Color，从而实现对同一个VPN内不同业务流量的差异化承载需求。或者说SR Policy技术本身的特性决定了SR Policy根本就不区分裸IP场景和MPLS-VPN场景，都可以根据不同的业务路由来进行差异化承载，不管这个路由是公网路由还是VPN内的私网路由。
随着5G商用的推进，必然会带来相应网络业务的大发展，面对更加复杂的业务承载需求，有着更加精细化承载能力的SR Policy，无疑更有用武之地。
2.3.SR Policy支持ECMP/WECMP
2.3.1.SR Policy更灵活支持主备路径
Tunnel Interface能实现主备路径，主路径承载流量，备路径在主路径故障时接管流量。主路径和备路径单独建立，单独维护。
SR Policy如2所示，一个SR Policy内可以有多个候选路径Candidate Path，不同的Candidate Path设定不同的Perference值来表征不同的优先级。SR Policy主备路径通过不同的Candidate Path实现，高优先级的为主用路径，低优先级的为备用路径。所以SR Policy不仅能否实现一主一备，而且实现一主多备。SR Policy所有的主备路径的控制都在一个Policy里实现，简化了管理，提升了效率。
2.3.2.SR Policy支持ECMP/WECMP
Tunnel Interface方式不支持ECMP/WECMP，这对Tunnel Interface的扩展能力是很大的限制。
SR Policy的定义非常灵活，如图2所示，在一个Candidate Path内，还可以有多个Segment List路径。每个Segment List都有自己的权重weight值，如果Weight值相同，则不同Segment-List路径之间负载均衡ECMP转发；如果Weight值不同，则不同Segment List路径之间按照权重负载均衡WECMP转发。ECMP和WECMP能力的实现，极大的提升了承载效率和承载能力。
2.4.SR Policy更灵活实现路径编程更贴合SDN发展
Tunnel Interface实现方式，网络SDN的南向接口以PCEP为主，不管是PCC-initiated建立Tunnel Interface隧道，再托管到控制器，还是控制器PCE-initiated建立隧道直接下发路径，转发路径下发后，最终在设备上的实现都要转化为实际的隧道和隧道路径的配置。
SR Policy的实现方式，SDN的南向接口可以是PCEP，也可以BGP for SR Policy，对于SDN控制器来说接口更加灵活；隧道路径直接在SR Policy内携带，下发到设备后，head-end设备直接根据Policy内的Segment List封装数据包，压入相应顺序的标签，不用转化为设备上实际隧道和隧道路径的配置，对于设备来说也更轻量化，更易实现。
在SR Policy的SDN控制场景，控制器根据不同的业务承载需求计算相应的承载路径，并以end-point+Color做为关键值去绑定一个BSID（Binding SID），再下发到head-end路由器，head-end路由器根据BSID将业务流量自动引流入BSID对应的SR Policy的相应Canditate Path进而进行转发。一个SR Policy的BSID就是被优选的Canditate Path的BSID。
总之，SR Policy可以实现控制面和SR转发面的完全分离，更便于实现业务转发路径编程和控制器集中控制。
3.总结
Tunnel Interface实质上还是一种隧道技术，而SR Policy则完全超越了隧道技术，将所有网络功能都封装在SR Policy里面，比如转发路径、负载分担、承载等级，并可以抽象成一个BSID，供APP或者控制器调用。
Recommend
-
12
通常在开发中，后端接口未完成，未不影响项目进度，前后端会先行定义好协议规范，各自开发，最后联调。而前端模拟后端数据，通常采用mockjs，拦截ajax请求，返回mock数据，这篇文章一起看看拦截ajax请求的实现方式。以下是采用mockJs的优点...
-
10
支付宝 Wap 支付的两种实现方式 作者:小柒 发表于 2020-12-04 | 分类于 支付
-
16
Android两种方式实现横向滚动图标+指示器 ...
-
7
Golang 定时器的两种实现方式及区别朋也的博客 » 首页 » 文章 Golang 定时器的两种实现方式及区别 作者：朋也日期：2021-02-25 版权声明：自由转载-非商用-非...
-
7
实现动态代理的两种方式介绍+例子demo(JDK、CGlib) ...
-
7
我们知道浏览器页面上的文字正常情况下我们是可以双击选中、或者单击鼠标横向拖动也能选中的，选中以后可以右击出现面板然后去复制什么的。但是有的时候，这种效果我们并不想要的，比如用户点快了的时候，所以我们需要禁用这种效果，本文记录一下禁用选中效果的...
-
9
爱码爱生活 java定时任务Spring Boot提供了@EnableSch...
-
4
小宅作为一个Java程序员，在日常的工作中，经常需要修改代码，然后重启服务，在验证代码是否生效。如果是小项目还好，重启速度比较快，等待时间比较短。但是随着项目逐渐变大，并且被拆分成多个服务时，改动一些代码，可能需要重启多个服务才能生效。这样下来...
-
10
页面截图功能在前端开发中，特别是营销场景相关的需求中, 是比较常见的。比如截屏分享，相对于普通的链接分享，截屏分享具有更丰富的展示、更多的信息承载等优势。最近在需求开发中遇到了相关的功能，所以调研...
-
9
当把开发好的 WebApi 接口，部署到 Windows 服务器 IIS 后，postman 可以直接访问到接口并正确返回，这并不意味着任务完成，毕竟接口嘛是要有交互的，最常见的问题莫过于跨域了。 若前端文件是在当前接口文件下的 wwwroot 文件夹下，那么接口的访问就...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK