SDN实战团分享（三十一）：Segment Routing meet SDN
本文系SDN实战团技术分享系列，我们希望通过SDNLAB提供的平台传播知识，传递价值，欢迎加入我们的行列。...
编者按：本文系SDN实战团技术分享系列，我们希望通过SDNLAB提供的平台传播知识，传递价值，欢迎加入我们的行列。
----------------------------------------------------------------------------------
分享嘉宾：马绍文，Juniper亚太区产品总监。领导亚太区产品经理团队管理Routing/Switching/Security/Cloud 产品线。跟欧美亚太主流OTT/SP架构师团队共同工作多年，积极参与业界SDN/NFV的发展，多次Apricot和其他亚太盛会上分享SDN/NFV等的主题演讲。最近的关注重点包括：Telco Cloud, MSDC, Automation和OTT 网络架构。对最新热门技术，EVPN/VXLAN，Segment Routing，Contrail/NorthStar SDN控制器, Appformix云运营优化软件均有独到见解
----------------------------------------------------------------------------------
一、介绍
为什么我们需要一个新的IETF协议来指挥MPLS转发呢? 下面会介绍一下这个名叫『春天』的IETF工作组。Source Packet Routing in Networking 简称为SPRING，也有叫做Segment Routing(段式路由)，我们下文一般称为SR。
2008年左右提出的Openflow促进了第一代SDN的热潮，大家都想用Openflow(ACL)去控制网络中的应用流量。Openflow在数据中心领域取得了一定的成功。 扩展到广域网和运营商网络时有了一些Hyberid SDN的部署，也遇到了重重的困难。
其中一个重要问题是Openflow对网络抽象不够，网络核心设备中网络状态信息随着应用数目的成指数增长。无法在广域网中得到大规模的部署。并且Openflow控制的网络，往往需要控制器控制路径中的多个关键设备，网络中的Touch Point增多，导致运维困难，信令压力增大。
采用SR来作为传输协议的时候，SDN控制器仅仅需要跟Ingress PE通讯，在Source路由器上已经通过携带多个标签，定义好了完整的路径信息。网络中的Touch Point仅有一个，就能影响到这个应用APP流量的转发。同时网络核心设备中网络状态信息完全跟承载的应用业务无关。采用SR
的运营商可以轻松的为百万级别的应用在头端（source）路由器选用不同的路径，同时保持核心设备没有任何应用状态。（Edge Intelligence, Stateless Core）。
二、SR协议介绍
◆ 邻接段（Adj-SID），连接另一个路由器邻居，local有效。
◆ 节点段（Node SID），指示如何到达另一个本地/远端（local/Remote） 路由器
◆ 网段（Prefix SID），指示如何到达一个IP prefix.
在头节点（Ingress Router）就用这不同的组件来组织一个完整的LSP Path。为了避免各个厂家设备采用不同的标签块，SR借鉴了传统的K.Kompella提出的BGP VPLS的基本概念。每个路由器宣告一个SRGB（SR Global Block全局块），在同一个区域（Domain AS/Area）中的每个路由器有个唯一的Index。
以ISIS扩展的SR为例，每个路由器都可能会宣告这三种基本的SID（还有一些其他类型的SID，比如Anycast SID等）。
每个路由器会计算SPF路径树，来构建节点段（Node SID）的一个完整路由器互联的拓扑（跟传统ISIS一样）。
SR路由器继承了MPLS的转发平面，仅仅是优化了控制平面。采用IGP/BGP来分发标签，取消了之前的LDP/RSVP-TE。
在一个支持SR的路由器里面，MPLS转发表会包含Node SID，Adj-SID 等（Prefix SID没有在图中显示）
Node SID表：如果路由器都采用相同的SRGB，对于任何一个远端路由器在转发表中会有一个独特的In/Out label 完全相同，也就是说Label SWAP操作之后还是相同的标签。每个标签代表唯一的一个节点。如果是相邻节点的Node，会有POP操作。
Adj SID表: 这个转发表也只有POP操作，所有收到的Adj label最后都被POP出来。
总结一下，SR的转发表，如果是相邻的Node/Adj会被POP弹出标签栈。所有的Node/Adj/Anycast/Prefix SID 都是IGP扩展来宣告给其他的路由器。每个路由器收到Node SID进行SPF计算，计算出一个树型MPLS转发表（跟正常OSPF/ISIS计算出来的拓扑一样），路由器收到Adj SID信息直接产生Adj POP操作。
上述过程可以想象为一个行李标签，比如我定了个机票：新加坡到洛杉矶，我买了个复杂的机票：11（新加坡）-1（香港）-7（北京）-4（旧金山）-14（洛杉矶）在新加坡时候我checkin行李，会拿到香港-北京-旧金山-洛杉矶行李Tag，行李托运之后，在中转的每个城市取下一个行李Tag，最后行李安全到达洛杉矶。在每个城市，仅仅根据最外层的Tag转发到下个城市。在头结点（source）行李的路径已经确定。
2.1 采用Anycast进行节点保护
接下来介绍一个非常好用的功能，Anycast节点保护。
传统的MC-LAG和Virtual Chassis功能作为节电保护，总是存在各种问题，多厂家无法互通，两个设备同样版本，设备间交换私有信息无法进行ISSU，无法多个设备备份，上下行流量保护问题等等。
SR推出了一个全新的功能Anycast SID能有效的解决这个问题。你可以选用一组设备2+，每个路由器在发布正常的Node SID的同时，还发布相同的Anycast SID。这样在R1节点收到5100的标签时，R1就会发送给4个路由器中的任意一个（outlabel 8100）。假设A1收到8100，会Pop出来8100，A3看到8070。A3就转发给R2（keep8070）。R2收到8070之后会POP，剩下Payload转发。假设A1节点失效，R1会发送给A2/A3然后发送8070到R2。
Anycast SID适用于任何拓扑，环形/Hub&Spoke etc.也适用于ABR/ASBR保护,同时适用于Seamless MPLS（后续会继续讲解）。
2.2 100% TI-LFA节点/Link保护
SR的另一大优点是可以提供针对任何拓扑100%的FRR保护。
大家知道LFA和Remote LFA都只能覆盖80-90%的拓扑，针对复杂的环形网络无法提供100%的拓扑情景的支持。
针对这种场景，Juniper最早提出了TI-FRR的解决方案。采用Target LDP和RSVP-TE结合的方式，可以做到100%拓扑的50ms快速重路由。
解决的思路是计算PQ节点集合。P节点集合：从E1出发，可以达到的节点集合，不需要经过中断路径。比如{E2,E3}是P节点集合。从E1出发到E4就可能经过中断路径。
Q节点集合：到达C1的节点中，不需要经过终端路径的节点，以C1为根计算的反向生成树，{E4，C2}是Q节点集合。
如果采用普通的R-LFA，PQ集合没有交集，也就是说R-LFA就不能保护这个拓扑。采用TI-FRR需要直接在E1到Q节点创建一个RSVP-TE Tunnel，这样被保护的流量就没有microloop回来，到达E4之后采用Target LDP session来确保流量流向C1。从而TI-LFA可以做到100%的拓扑保护。
采用SR的保护机制不太一样，在disjoint PQ集合里面，首先利用Node SID选择P（E3）节点，然后压上Adj标签（E3-E4），也就是告诉流量首先发送到E3，正常情况下有可能会回流到E1-C1链路。这时候SR要求流量到了E3之后，继续转发给E4。也就是两个label，两个动作确保了100% FRR.
2.3 利用Binding SID扩展网络规模
采用SR的一个很重要的顾虑是硬件能压几个标签？比如B厂商的商业芯片一次只能压三个标签，可能通过recircle来压多个标签但是会带来性能的损耗，同时带来其他问题。
为了让SR可以在各种场合适用（比如运营商汇聚），SR开发了Binding SID。 通过IGP/BGP来发布一条SR-LSP（从R22到R30，标签栈为{332|331|330}）的标签，假设这条SR-LSP的标签为510.在R21处只需压入两个标签{22|510},当R22收到22时pop标签22，露出来510，R22会把510去掉，同时压入3个标签{332|331|330}，这样报文最后会抵达R30。
通过Binding SID也可以实现RSVP-TE/LDP和SR的互通。还有LDP mapping Server等具体的办法就不详细介绍了。
2.4 基于PCEP/BGP-LS的SDN控制器
最早利用SR来支持SDN的想法来自于PCEP/RSVP-TE类似的做法。在控制器端计算完整的流量工程路径，然后把路径列表通过PCE带给路由器上的Client端（类似RSVP-TE ERO）。非常类似RSVP-TE，好处也明显，不需要沿途的路由器发任何信令去建立LSP（RSVP需要发送 Path/Reserve message）。
非常类似RSVP-TE的PCEP LSP建立过程。控制器的PCEP会通知路由器上的PCC来协调能力，同时采用类似SR-ERO的方式来携带Label Stack，PE收到PCCreate LSP消息之后，不需要像RSVP-TE那样在多个路由器之间传递PATH/Reserve信令消息，仅仅需要下发label 堆栈信息。同时LSP创建的状态汇报通过SR-RRO来传递回去控制器。
采用BGP-LS来传递TEDB，并携带SR label信息送回控制器。
对于VPN业务的映射，可以采用PE-CE之间的Openflow/PBR/QPPB/BGP Flowspec 等。
2.5 SR和传统LDP/RSVP-TE的对比
简单的对比一下SR和LDP/RSVP-TE。
首先网络中间节点只需保留很少的网络状态，SR甚至不需要理解网络中的远端状态信息。比如节点3，不需要任何关于link 11-1, 6-7的Non-adj转发信息（而这些信息在LDP里面是存在的）。SR的基础转发表甚至比LDP更简洁。当然比RSVP-TE状态少很多。同时不需要LDP/RSVP信令来建立LSP， ingress node上出现不同的Label Stack组合，马上代表不同的路径选择。
三、SDN的应用场景
先看传统的Underlay网络，由路由器，交换机，防火墙等组成，连接方式很固定，一旦配置了之后大概半年/一年都不会进行更改。 采用Ansible/Puppet进行配置管理之后，可能需要进行一系列的检测和排错。总之网络比较稳定，运维简单。
但是新的云运营模式，需要全网转去DevOps模式才能适应云计算。
DevOps能帮助客户在物理网络之上创建一个虚拟化的网络。APP/Dockers/VM能够更快的部署在全球网络上，并采用Scale Out的方式实现海量客户的接入，更灵活的做网络的变更。Overlay网络管理的不再是物理的设备，需要管理海量的虚拟路由器（vRouter），OVS，VNF （LB/FW/DPI）等。怎么去维护管理这个虚拟化的网络，需要一个SDN控制器帮忙。
越来越多的客户采用SDN控制器来进行DC内部Service Chaining和跨DCI的选路。
如果在underlay网络中部署SR，云服务就可以通过BGP-LU/PCEP/Netconf等协议来对Source节点进行编程，可以选择DC里面的Leaf/Spine路径，也可以选择DCI的SR-TE LSP来进行跨DCI的流量工程调度。
SR标签可以包含：{APP|Docker|VM|Server }映射关系，还可以包含NFV label进行Service Chaining，还可以包含VPN Label，进行VPN隔离，同时还可以包含Label Stack穿越广域网。采用不同的label组合，在增加任何影响underlay核心路由器转发表的情况下，可以支持百万级别的应用。
数据中心，拓扑比较简单，EBGP来作为IGP协议，同时采用同一厂商的设备，统一的SRGB来管理大规模数据中心。
广域网在核心/边缘路由器上部署SR， FRR特性，同时减少Core Router的状态，采用BGP-LS来上送Controller网络的标签状态。采用BGP-LU，FlowSpec来控制流量 承载在不同的SR LSP。
城域网在汇聚路由器，移动回传的网络中，采用环形网络，利用SR的100%拓扑，采用Binding SID来跨越多个Area/AS，并且采用PW来进行业务的承载，简化Cell Site设备协议，取代传统的Seamless MPLS。
下面详细介绍一下各个Use Cases：
3.1 SR在超大规模数据中心的应用
在介绍数据中心应用场景之前，先介绍一种新型的BGP控制器来建立SR-TE LSP的解决方案。
BGP-LU(RFC3107)在业界有多年成功部署应用，大部分厂商设备都支持BGP-LU，包括Metro里面的很多小型Cell Site路由器。
传统的BGP-LU仅仅能够携带一个标签，Juniper的设备扩展了RFC3107，可以在控制器和设备之间传递多个标签栈。
这里我们采用了非常简化的ExaBGP（Github免费BGP，https://github.com/Exa-Networks/exabgp）安装在笔记本电脑上，并且跟路由器建立简单的BGP-LU session。ExaBGP Controller来发送一个BGP 消息给PE1，这个BGP-LU消息携带四个标签栈。可以指导PE1创建不同的SR LSP转发表项。
同时如果采用QPPB/BGP FlowSpec 来映射PE-CE之间的流量到BGP-LU创建的SR LSP上，就只需一个BGP协议，SDN控制器和路由器就能协商业务流的控制。
1.越来越多的Overlay采用MPLS，比如Contrail采用MPLSoGRE，MPLSoUDP， EVPN+MPLS等协议。在广域网和DC采用相同的MPLS协议，带来的运维好处显而易见。比如DC GW不需要在VXLAN和MPLS之间进行协议转换（避免性能可能下降）
2.同时由于Telco Cloud，越来越多的NFV采用MPLS VPN协议隔离。
3.可以更好的指导Elephant Flow转发，避免ECMP Hash时候Elephant Flow和Mice Flow竞争同样的资源。
4.可以更好的进行故障隔离，传统TCP Flowlet把网络变为黑盒，拥塞之后就会调低传送速率。如果能够理解网络中拥塞，不需要降低传送速率，仅仅需要重路由到非拥塞链路，会极大的提高App的传送质量。
经典的超大规模DC设计，取消IGP（避免网络链路震荡，路由重算）构建基于BGP 的数据中心。请参考Juniper 白皮书, EVPN IP CLOS for Next Gen DC
在超大规模数据中心里引入SR，是一个比较热门的话题。draft-ietf-spring-segment-routing-msdc在持续讨。草案里面定义的是基础Leaf/Spine架构如何用BGP-LU+SR来构建。我们这里来介绍一下端到端的VM/Docker是如何通讯的。
◆ Leaf 跟控制器建立BGP-LU（3107）session，传递vRouter Prefix SID的标签信息
◆ Leaf/Spine建立BGP-LU session，传递Leaf labels， Spine不需要跟控制器建立session。
◆ 控制器创建VM/Dockers时，在vRouter上给分配标签，通过BGP/XMPP上送到控制器
◆ 在Ingress vRouter上压入三层标签栈，就可以找到egress (TOR，vRouter, VM)
◆ SR可以很容易的利用Node SID来实现ECMP，可以利用Adj SID去精确指导选用哪条Link。
◆ 可以利用SR的Anycast SID去保护DC GW和广域网路由器
◆ 在图中例子可见在Ingress vRouter标签栈依次为：{ DC1 | DCI A-B-C | DC2 | DC2 vRouter | DC2 VM}, 需要说明的是，即便可能压入8-10+个标签，报文头还是比VXLAN（60-70 bytes）小。
3.2 基于SR 的Cloud Peering应用
传统的流量工程仅仅 关注在IGP域部分，越来越多的企业迁移到云服务。如何找到没有拥塞的BGP Peering提高网络云接入能力？基于SR的BGP EPE能提供一个更好的解决方案。
◆ ASBR通过BGP-LU（3107）跟控制器建立BGP邻居，并且给每个Peer分配一个标签。
◆ ASBR通过BGP-LS, Netflow, Telemtry把流量信息上送到控制器。
◆ 控制器计算最优路径（latency/bandwidth/optical SRLG etc）
◆ 控制器在头结点压上多个标签，外层SR标签找到ASBR，内层BGP-LU标签找到Peering,外层隧道也可以采用GRE/LDP等。
在BGP EPE转发路径上有个比较特殊的属性，从AS内部到peer的转发，不需要查询路由表，仅仅需要MPLS转发。利用这个特性可以采用新型态的LSR /Lean Core设备做Internet Peering。
3.3 基于SR 的下一代接入网
对于运营商来讲如何降低接入网的成本，是一个首要问题。对于采用SR的cell site 路由器，可以实现最小的协议支持，同时承载各种VPN业务。网络的传输部分简化为ISIS协议，网络的业务部分采用BGP承载VPN，甚至采用BGP FlowSpec来映射客户流量。减少Cell Site Router的协议复杂度，就会增加网络可靠性，可维护性。
如果采用SR，可以利用协议简化机制，利用100% FRR保护，利用Anycast SID保护汇聚节点，利用Binding SID在汇聚设备扩展SR LSP跳数。
SDN最早起始于数据中心，就是因为要管理很多TOR和Server。很多客户有上千台Cell Site路由器的规模，引入SDN控制器，并且采用ZTP自动部署SR。越来越被主流运营商接受，成为运营商采用SR的一大驱动力。
3.4 基于SR的Telco Cloud
传统运营商建网思路是以连接性为目的，买路由器，传输设备，提供管道，连通性。网络架构基本不具备智能。
随着5G，虚拟现实，IOT，HealthCare等业务越来越多的业务承载在运营商的网络上。低延时，大带宽，大规模业务，需要运营商建设更多的Micro Data Center，更加靠近客户和应用。驱动运营商的网络从传统的连通（PIPE）导向的建设思路，转型到建设运营商云服务平台（Telco Cloud） 上来。
为了应对新业务的出现，很多业界运营商转变思路借鉴了许多OTT的建网思路实现以超小（Micro），Ultra Low Latency数据中心为网络建设的重点。比如为应对VR/Health Care/自动驾驶等业务的低延时，大数据量应用（自动驾驶汽车需要视频识别，可能每秒钟产生1Gbps的流量），必须要建设全分布式，超小型数据中心更加靠近终端用户 。
典型的Telco Cloud在SP汇聚层会采用BGP-SR添加很多小型数据中心。在SP数据中心中Leaf节点有不同的工作职责：
◆ A-Leaf用来接入用户，比如ONU，Wifi，BNG客户等
◆ C-Leaf用来接服务器，用来虚拟化vEPC，vFW，vDPI, vOLT, vBNG 等
◆ P-Leaf用长距光模块做互联。
采用BGP-SR在SP Fabric，Metro利用OSPF SR，提供端到端的SR LSP，业务采用EVPN承载。
3.5 基于SR的网络虚拟化NFV Service Chaining
网络虚拟化也是运营商最热门的话题。网络分块（Network Slicing）和业务链（Service Chaining）也越来越重要。Service chaining表现出新的趋势：
◆ 不光局限于骨干网DC，往往分布在Front Haul的Micro DC（小微），在城域网BNG附近的中型 DC，和国家骨干网DC分别处理不同的虚拟化业务。
◆ Service Chaining可能无法在一个数据中心处理完毕，需要在城域范围内跨越多个DC。
业界有厂商引入特定的NSH（network service header）头来支持业务链，但是采用专用报文头可能会带来两个问题，很多VNF(比如vFW, vEPC etc)不支持NSH，大部分硬件交换机无法支持NSH。
由于SR可以指定访问网络中的任何节点（通过多层标签栈），同时大部分的虚拟设备和物理设备都可以支持MPLS转发平面，所以很多客户想要采用SR来支持Service Chaining。
四、总结
最早美国的很多Web/OTT公司Google, Microsoft非常感兴趣SR。还有一些欧洲美国的TOP SP，ATT/Comcast等，最近在亚太区，中国的OTT，日本Softbank/NTT/KDDI,加上澳洲的Telstra都很感兴趣，SR在2017会有更多的客户采用，部署。
最早SDN起源于数据中心的Openflow，目标是通过动态配置管理上千台TOR/Server，建立连通性。数据中心基于简单拓扑，物理冗余性，交换机功能简单，网络超配， SDN Controller不大需要关心网络资源，流量状况。Automation（自动化）称为SDN控制器的最主要特性。
随着SDN影响越来越大，SDWAN, WAN SDN, Cloud SDN需要 SDN/NFV控制器来更好的理解流量和资源分配状况,这时候需要通过Openconfig/gRPC 搜集Telemetry 信息，上送控制器。原始的信息很难被控制器理解，越来越多厂家在SDN控制器之上加入机器学习，人工智能部分，更好的指导控制器进行网络自动化。
举个例子，Juniper最新Appformix解决方案，用来优化Openstack云部署环境，采用了机器学习，当部署新的VM/Docker时，Appformix注意到，尽管某个Server的CPU负载很低（只有20%）但是那些L3 Cache资源已经不足，Appformix会进行迁移把现有的VM移到L3 Cache充足的Server。当有个新的VM/Docker部署要求时，最简单的就是给他分配一个新的Server，但是新的VM/Docker也许和现有的一个VM有很多交互，share相同的资源，如果把新的VM/Docker部署在现有的Server上，而不是每次都分配新的server，可能整个应用更流畅。
从上面的例子可以看出来，现有的SDN控制器仅仅是算是机械手，引入人工智能，引入Telemetry更好的理解网络。形成一个闭环的SDN自愈合控制系统。
前面讲到的各种SR的网络优点，可以看出来采用了SR的智能边缘，无状态核心设备的网络基础架构，不但理解Underlay网络架构，同时理解Overlay云端应用，促进云网融合，会成为今后SDN/NFV发展的坚实基础。
Juniper的网络远景是打造『自驱动的网络架构』-“Self-Driving Network”
更多Q&A内容，请点击阅读原文
关注 SDNLAB
微信扫一扫关注公众号
