前言：本人的所有技术分享仅以传播IT行业的通用网络技术知识为目的, 不包含任何厂家特定的软硬件功能/特性的实现细节以及roadmap等厂家私密信息.
本次分享借用了JUNIPER公司的PPT的一些模板和设备图标, 在此表示感谢. 如果大伙儿对JUNIPER公司的产品和解决方案感兴趣, 请与JUNIPER公司的销售经理和系统工程师联系.另: 如对PPT版权有问题和意见, 请联系作者修改.
本次的技术分享是SPRING/SR技术介绍, 全称是Segmented Routing(确实不知道中文怎么翻译, 谅解一下哈)
SR = Segmented Routing
SPRING = Source Packet Routing in Networking
要充分理解本次分享的技术内容, 最好对MPLS流量工程/快速重路由和IGP/BGP路由协议的概念比较熟悉.
个别技术术语或词语翻译成中文的话, 整句话或段落的意思会变得扭曲, 这部分内容就不做翻译.
本次分享分4个部分, 最开始进行一下主要概念的介绍和对现有网络协议如何与SR互动做了一些探讨, 对特定的用户案例也说了说明, 并在最后阐明了实现和应用SR技术所面临的挑战.
主要概念的介绍
SPRING包括两个大块的内容, 首先, 控制平面, 通过IGP来advertise标签label. 在这里, IGP域内的所有router都对其邻居创建单一跳数的LSP, 并且通过flooding的方式advertise标签label.
第二部分就是转发平面的内容, 基本上是ingress router使用label stack(标签堆栈)来转发数据包. Label stack就是相当于TE里的ERO对象, 在不需要网络核心维持状态信息的情况下, 完成数据包按指定路径转发的工作.
这张图里, 我们要探讨一下SPRING技术特别是area 0的advertisement, 这个例子中的网络有7个路由器(R1,R2,R3….R7). 黑色线代表物理链路, 每条链路都有关联的cost值, 如果一个数据包要从R1转发到R7并且必须是最短路径转发, 那么R1是源, R7是目的, 可以通过R1-R2-R3-R7这样的路径, 因为这条路径总cost数值最小, 为3.
SPRING技术允许每台router不仅仅拥有到其邻居的单跳ERO, 而且可以把相应的标签信息放到IGP里面去. 通过flooding的方式, R1作为源路由器对所有路由器有一个认知, 同时也知道如何通过单跳链路去往所有路径和所有路由器的信息. 在这个例子里, 如果观察右侧, 你会看到一个label stack(标签堆栈), 它可以追踪数据包在本网络的所有路径. 或者从R2到R7的IP数据包使用label stack来完成MPLS TE ERO的功能, 而不是按照最短路径进行转发。
Advertise信息类型: Node Segment
SPRING的第二种advertisement就是基于node segment的, 一台router就是一个node, 也可以称为Node SID. 在本例里, IGP域里每台router都有本域其他router的关联MPLS label信息. 基本上可以说一个label映射到一台router.
R1 advertise一个label叫Y, 是与R3关联的, 所以当R1收到一个数据包的top label(栈顶标签)为Y的时候, 会直接把数据包转发到R3. 这种advertisement在SPRING里就叫作Node Segment advertisement
Advertisement信息类型: Multi-Hop Segment
第三类advertisement信息类型叫multi-hop segment, 如果R1是LSP的ingress router, 然后这条LSP是通过RSVP-TE signaled, 或者是多条adjacency segment串接起来的, 然后R1把LSP A advertise进IGP里, 并关联到一个label Z(标签). 然后针对label A或者LSP A也advertise一个ERO. 如果R1收到一个MPLS数据包, 并且top label是Z的话, 数据包就会通过LSP A被转发到目的地.
这个multi-hop segment实际上就是起到网络中出现多链路的情况时来追踪数据包的路径信息的作用.
如何使用SPRING? 是不是现有所有网络协议的代替品? 是否为工具箱的其中一种工具? 是否增强了现有协议的功能? 是否解决了特定的用户问题? 具体怎么定位SPRING这种技术呢?
在我们看来, SPRING只是工具箱里的一种工具, 实际上是作为一种补充作用的工具. 比如我们有多种标签分发协议, 如RSVP/LDP/BGP等, 并对特定的应用使用特定的协议. SPRING就可以作为这种组合的有效补充, 可以在特定用户场景解决特定的问题. 今日的网络是在不断发展的, 最有可能出现的情况就是如果使用了SPRING, 它会与现有的网络的各种协议结合起来解决不同的问题.
我们来看一下各种既有协议的特性. 从LDP开始.
LDP就像一个锤子, 锤子很容易钉钉子进木头并且很容易从木头上拔出钉子. 同样的, 单跳FULL-MESH LSP的情况下的自动部署是非常方便的(只要启用LDP即可, 不需要指定LSP具体路径). 从另一个方面来看, LDP并不适合指定路径LSP. 所以, LDP这个协议, 有优势也有劣势.
螺丝刀很容易把螺丝拧紧和拧松, 但是对钉子就无能为力了. 本例中, 借用类似的比喻, 如果人们需要预定义路径的LSP, 有些特性只有RSVP(的TE扩展)才能实现, 如带宽预留, 预留抢占, 呼叫控制等, 并且基本上对于数据包进入LSP的控制和数据平面能有比较完整的关联.
RSVP不大擅长的是自动发现远端的隧道(LSP). 如果网络中LSP和router数量很多, 那么使用full-mesh的RSVP LSP就会有很大的挑战.
IGP就像扳手, 自动发现拓扑和远程隧道的信息非常厉害. 对于在大规模网络中分发必要的标签信息是非常有效的. 然而, IGP对于service label是不太好的, 不能追踪网络中间节点的状态信息, 并且对于P2MP的LSP建立不是非常有效.
BGP
BGP就像链锯, BGP对于处理service和AS之间以及transport LSP的能力是有目共睹的, 然而对于需要手工指定路径的LSP以及P2MP的树型拓扑的建立, BGP不是最好的选择.
结论: 只有把所有的工具都放在工具箱里, 并有效的使用, 才能够解决业务网络中的流量问题, service问题, LSP问题, 带宽问题, 等等.
接下来我们探讨一下几个SPRING相关的案例.
Use Case: Spring & Local Path Selection
第一个案例主要是创建流量工程路径. 从前面内容可以看出, 使用adjacency label stack可以完成这个目的. 然而问题是: stack是怎么决定的? 原则上ingress router可以通过使用CSPF来确定stack, 与其CSPF将计算结果发送给RSVP, 与路径直接关联的stack早就被CSPF计算完毕并直接装载到设备的硬件板卡的ASIC上了. 图中可以看出这样的例子: R1要计算到R9的路径. 算出的路径是R1-R4-R7-R9, 通过IGP adjacency label advertisement关联的label stack存在于IGP database里, 然后这就决定了如果要达到R9, 需要走的路径是407, 然后是709, 接下来就把这些label 通过push的操作送到packet里.
说了这么多, SPRING并没有预留带宽, SPRING LSP只存在于ingress router R1上; 路径上的其他路由器对R1使用这条路径并无感知. 这就意味着, 我们在路径计算的时候并不能使用带宽作为限制条件. 在SPRING的解决方案里, 并没有 “计算一条路径 & 预留50M带宽”的这种说法, 因为控制平面上并没有做这个预留带宽的动作. 基于这个原因, 你无法对ingress router的CSPF使用SPRING
Use Case: Spring & TE Controller
基于SPRING在网络层无法预留带宽的事实, SPRING相关的流量工程的工作将会主要在TE控制器上完成. 这个控制会追踪每一条LSP的带宽预留是怎么完成的, 从而得知需要多少带宽, 可分配多少带宽这些信息.
参见图中需要建立R1到R8的LSP并且分配带宽为50Mbps. 假设R4和R7之间的链路并无足够的带宽, 控制器知道这个事实, 因为控制器一直在追踪经过这条物理链路上的所有LSP已使用带宽, 然后控制器接下来的工作是计算出合适的路径, 绕过这条物理链路, 使用比如R1-R4-R6-R7-R8的路径. 然后它通过PCEP协议发送路径信息以及关联的label stack信息给R1. 要完成这个工作, 需要对PCEP协议做相应的修订, 这项工作IETF已经有人在做了. 另外, 对BGP LS的修订也是必要的, 因为控制器需要知道分配给每条物理链路的adjacency label value.
BGP LS的标准参见https://tools.ietf.org/html/rfc7752
Use Case: Shortest Path Tree (LDP Alike) LSPs
我们来看另一种IGP的label advertisement, 叫作Node Segment或者叫 SID. 每台路由器通过IGP来advertise的loopback地址和其他信息, 使得任何路由器能通过最短路径并且以标签交换法的方式来达到网络的任意目的, 从某种角度来说, 这其实是LDP的一种替代协议. RFC草案的一种有争议的说法是是否可以使用全局标签(global label). 举例来说, R7通过IGP把自己的loopback地址做了分发, 并分配label为1001, 然后网络内任何一台其他路由器都可以使用1001来通过最短路径树来达到R7. 现在问题在于, 当前的MPLS实现一直是使用本地而不是全局的标签分配, 如果1001与之前给其他应用所分配的标签值冲突的话怎么办? 有可能是一个L3***情景里R2分配给自己的标签呢….有的人就建议使用可配置的地址空间或者映射的方式来解决这个问题. 但是在许多避免label冲突的解决方案里, 完全避免global label冲突的一种方法叫label blocks, 我们来看一下怎么解决这个问题.
每台路由器把自己的loopback通告到IGP里, 并携带一个特定的ID(全网唯一)以及一个label范围. 图中蓝色方块中显示了每台路由器通告进IGP的信息, 然后被flood到整个路由域, 然后所有的路由器对所有的通告都是可以看得到的.
例子中可以看到, R7通告了自己的loopback地址和label ID 7, 这个信息是网络中唯一的, 也就是说, 没有其他任何设备会在同样的域内通告label ID 7. Label范围与label ID是怎么协调工作的呢? 还是举例来说, R2通告了label范围为400-409(包括400和409这两个label), 如果R2要转发流量到R7, 那么R2期待流向它自己的数据包携带什么label数值, 才可以正确的转发数据包到R7呢? 这个数值是400加7, R2的label block起始数值为400, 7作为一个index是由R7来通告到网络的, 这样的话, 如果R2接收到一个携带label数值为407的数据包, 就会把这个数据包通过最短路径发给R7. 查看本图的IGP metric数值可以看出, R2到R7的最短路径需要经过R3, 那么R2通过label swapping的方式将数据包发给R3, 而这个新的label数值则是R3期待接收到的, 根据图中所示, R3通告了自己的label block范围是100-109, 这个数值也需要加7才能达到R7, 所以这个数值是100+7=107. 所以在这里如果你查看R2的转发表, 也就是R2旁边的橙色方块, 你可以看到incoming label是407, 然后label swapping以后转换成label数值是107, 然后直接发送到与R3的直连接口. R3也对label 107做一个操作也就是标签弹出(pop), 然后发送到去往R7的链路. 通过这种方式, 网络中任何路由器都能知道去往R7所需要的label数值, 从而正确的发送数据报文.
我刚提到过, 其实这是可以代替LDP的一种协议. 虽然这么说, 但很多人仍然需要多点LDP(mLDP)这样一个东西, 因为SR/SPRING并无多点的解决方案. 另外 一种应用我们待会儿会提到, 那就是提高远程LFA, 而node advertisement(节点通告)是非常有效的增加remote LFA工作的方式.
Label-Stack “Compression” Hybrid of Node and Link Labels
本图展现的是一种混合的情况, 结合了adjacency label和node label的方式, 目的是创建转发数据包所需要的label stack. 假设R1想发送数据到R7, 但路径并不与IGP最短路径完全一致. 比如按图中所示IGP metric, 最短路径是R1-R2-R3-R7, 但我们现在想要走的路径是R1-R2-R3-R6-R7. 红色箭头所标识的是对IGP最短路径的偏移, 绿色箭头的部分是与IGP最短路径重合的部分.
原则上来说, R1可以直接创建adjacency label的stack, 每跳一个stack, 但我们要使用另外的方法: 对于与IGP最短路径重合的部分, 我们使用node label. 接下来我们就可以看到, R1建立了一个label stack(本图右下角). 第一个label是403, 这是R2发送数据包到R3使用最短路径树所需要的label. 如果你需要红色的label 306, 这是R3希望收到的数据包里所包含的label数值, 只有收到了label为306的数据包, R3才会把数据包发给R6. 最后, 标签堆栈的栈底是label 337, 也就是R6所期望收到的数据包里包含的label value, 只有收到了label 337的数据包, R6才会正确的转发数据到R7. 通过创建label stack(标签堆栈)的方式, 我们才能建立基于source generating label的转发路径.
Function: FRR – Scheme #1 – IGP R-LFA
现在看一下基于IGP路由的FRR(快速重路由, fast re-route). 在本图中, 每条链路的metric数值都是1. 先假设这是基于LDP的网络, 并且假设R1对经过R2这个节点的流量(灰色虚线所示)进行保护, 也就是说这个例子与FRR的节点保护功能直接关联, 同时也对链路保护功能直接关联. 从拓扑中可以看出, R1并无合适的LFA邻居, 路由器不得不将流量倒换回R0以便于流量从另一个方向走. 但是从R0角度来看, 到R7有两条ECMP等价路径, 所以这就有问题了, 要解决这个问题, 建议的方法是远程LFA方式. 这个例子里, R1使用R4为远程LFA邻居. 术语上R4也叫PQ node(PQ节点). 接下来R1把被保护流量封装到隧道(LDP LSP)里, 然后这条隧道(LDP LSP)是终结到R4上的, 这就是解决问题的关键, 这使得流量能够经过R0, 但是并不会被R0做IGP ECMP方式处理.
要达到这个目的, R1需要知道R4所期待的数据包里包含的label数值, 也就是说R4收到了包含正确label数值的数据包才会发给R7. 如何确认这个label数值呢? R1需要和R4建立一个targeted LDP session. R1从R4处借用了R4通告的label, 并将此label推送到被保护流量的IP报文里. 这个方案是可行的, 但是在大网里, 被许多PLR选作PQ节点的路由器最后可能有很多targeted LDP session, 唯一可能出现的控制平面的担忧. 如果我们在网络里做了node segmented 通告(如蓝色方块所示), R1从这些通告中就可以得知R4所需要的label数值, 我们这样就不需要targeted LDP session了. 这个例子里, R4通告了自己的label range是100-109, R7通告的index是7, 我们就知道从R4角度来说, 它期待的数据包所包含的label数值是100+7=107, R1也知道此信息. 然后R1将label 107 push到IP报文里, 然后再push需要到达PQ节点的外层label. 要达到R4也就是PQ节点的label, 可以是LDP分发的label也可以node SID label. 类似的情形也可以用来保护node SID流量
链路保护和节点保护的细节在RFC 4090里有详细叙述…….当年读了5遍……为了这次分(Zhuang)享(Bi), 又过了一遍
有些拓扑里, 即使使用远程LFA的方式也不能做到全方位的保护. 本图中, R4-R5的链路是高metric的, 所以实际上并没有可以作为远程LFA邻居的PQ节点来保护途经R1-R2的流量或者做R2的节点保护. 这怎么办呢?
要解决这个情况, 可以使用source rated bypass tunnel(我就不翻译了, 真不知道合适的中文翻译是啥), 通过RSVP-TE来做信令, 图中红色的就是, 或者可以使用adjacency label stack(图中蓝色箭头所示). 如果我们要保护LDP流量, 为避免在R1-R5之间建立targeted LDP session, R1可以使用IGP node label, 发给R5, 因为R5期待收到这样的label数值(307). 这样, R1 push标签307到IP报文里, 然后再push外层标签到bypass tunnel(如果是RSVP-TE的话), 或者SR adjacency label.
Use Case: Tail-End Protection – Two Issues To Be Addressed
我们来看另一个案例, PE保护, 也叫作尾端保护. 我们来温习一下尾端保护的原则, 下一张图我们看一下IGP中的label通告. 在这一张图上, 路由更新的流动是从左到右, 而数据报文的流动是从右到左. 用MUC44这台设备举例, 当发送数据包给PAR3的时候, 通常是使用FRA21作为出口, 我们想在FRA21整机失效时启用保护措施. 我们使用FRA22作为protector PE, 这个例子的应用是MPLS L3***. FRA22通告context label, 这是用来标识原先预定去往FRA21的流量被PLR半路拦截的. 在我们原先的实现里, context label是通过LDP送达的. 但这意味着这个功能能够实现的程度是基于IGP metric的, 就类似LDP LFA一样. 这样的话实际上是欺骗了PLR, 让PLR完成LFA的功能, 但是PLR自身并不是很明确的知道实际对于被保护的流量做了拦截并重路由到另外的出口.
考虑另一种情况, 如果PLR和P2之间的metric非常高的话, 流量就会被送回PLI, 这就使得我们原本的保护措施失效了.
上面只是做了简单解释, 实际上最详细的技术细节在RFC 7490有详细的叙述, 特别是伪代码那一块.
USE CASE: Tail-End Protection IGP Signals “Alternative” Connection To Primary Node
可以解决问题的方法就是把context label通过IGP而不是LDP进行通告. 通过严格通告的方式, 修复路径的行为变成了PLR对incoming LDP label进行swap, 换成IGP context label, 本例子里就是label 47, 然后把LDP value 18再push上去, 这个就是P2要转发流量到FRA22所需要的LDP label
Use Case: Egress Peering Engineering (EPE) – A Route-Resolution Example
另一个案例. 这个解决方案是Juniper的Shawn最喜欢的解决方案, Egress Peering Engineering(EPE, 还是不会翻译). 图中我们有AS1, 然后AS1有ASBR1与ASBR2做IBGP peer, 然后ASBR1还与AS2的两台ASBR(ASBR3, ASBR4)做EBGP peer. 通常情况下, 如果你考虑从S路由器始发并去往ASBR1的流量, S自己对自己发出的流量走哪个出口并没有控制的方法, 而这其实是由流量到达ASBR1后才能决定的. 如果我们想要S有这样的控制, 需要做的是IGP label通告的方式. 具体流程是: ASBR1在IGP域里通告与ASBR3直连链路的label, 在本例里,就是label 103. 与此同时也类似的通过IGP通告与ASBR4的直连链路的label(本例里是104). 这就意味着, S发送流量去往AS2的时候, S实际上可以控制使用哪条egress链路. 使用的方法就是建立特定的label stack(标签堆栈). 假设800是R1要向ASBR1发送流量所需要的LDP label数值, 那么S就push label 800, 但是在这个label 800下面再push label 104(这是ASBR1和ASBR4的直连链路的关联label数值). 当数据包到达ASBR1的时候 数第二条弹出的规则, label 104被露出来了, 然后ASBR1转发数据报文到ASBR4, 这就完成了路径的控制.
Challenges in SPRING
这是最后一张slide, 我们一起来看一下SPRING/SR所面临的挑战, C公司(嘿嘿 ^_^)在推SPRING/SR的时候说了很多的好处, 但是并没有对部署SR所面临的挑战进行详细的分析.
到目前为止目前SPRING的一些草案和RFC并没有提供对组播的支持, Segment Routing Architecture这一份主draft上原话是 “Segment Routing is defined for unicast. The application of the source-route concept to Multicast is not in the scope of this document.” 然而实际应用中, 肯定要考虑到组播流量的应用. 所以如果你的客户需要组播业务, 并打算使用SR/SPRING, 那么就要考虑SPRING对组播的支持. 目前来说, 很遗憾没有解决方案.
第二点, 大家都知道, SR/SPRING的一大好处就是网络的核心部分不需要维护软状态信息, 这句话是没错的, 但是, 也是有代价的, 代价就是软状态所关联的一些业务属性也没有了(而这时好的东西), 比如auto-bandwidth(MPLS LSP预留动态带宽调整). 另一个方面就是, 对于映射到MPLS LSP中的流量, 再也无法将实际的数据转发平面与控制平面进行关联了, 这是一个很不好的地方.
第三点, SR/SPRING对于网络中的LSR路由器来说, 引入了一些新的难题, 具体来说, 牵扯到路由器对于特定IP包头和MPLS包头的数值的查找结果并结合hash算法进行负载均衡的问题. 最后一点: entropy label确实需要MPLS LSR路由器进行特殊的处理. Juniper和Level 3合作编写了RFC6790并要求网络中所有路由器都能处理BGP entropy label, 对于不能处理的设备需要移除entropy label属性. 但是令人遗憾和郁闷的是, 由于各家厂商实现起来有实际的困难, 所以RFC7447彻底免除了需要对entropy label的支持.
所以, 目前从SR/SPRING角度来看, entropy label是一个很麻烦的事情
谢谢大伙儿听我的分享, 再次感谢.