BIGO骨干网设计与实现(一)
在介绍BIGO骨干网设计与实现之前，先来回顾我们2021年初发表的《降本增效｜Aestron自建全球网络基础设施，提供极致音视频技术体验》节选：
全球骨干技术优势
Aestron自有基于物理海缆、专线的全球骨干网络，总容量超过10Tbps，光缆长度累计超过130,000km，可环绕地球3圈。Aestron全球骨干网基于Segment-Routing源路由技术组建，不同类型业务数据严格隔离，优先级严格区分，配合软件定义智能流量调度算法，可按时延、带宽、质量等目标进行自动网络路由调整，选择最优最快传输路径。
依托在全球多个Tb级别的internet接入点，Aestron还构建了一套SD-WAN全球网络系统，为骨干网的物理专线提供1:1备份路由，通过Ti-LFA(无环备份下一跳)和热备份路径技术，网络中任意链路/节点故障在50ms内完全自愈，终端用户无感知，实现99.99%以上的可用率。
Aestron基础网络质量大大超越传统VPN专线，超越传统运营商骨干，超越所有依托internet进行“尽力优化”的“直播实时网络”，能提供延时更低、抖动更小、可靠更高、带宽更大、端到端质量完全可视、路径完全可控的的全球互联网络，是Aestron全球高质量RTC音视频服务的基石。
*欢迎关注“Aestron安思创”公众号
可见，提供高质量的上层服务，离不开坚实的网络底座。BIGO的骨干网络为业务提供了以下特性：
1. 智能流量调度，可按时延、带宽、质量等目标自动调整流量路径；
2. 不同类型业务数据隔离，区分优先级；
3. 基于SD-WAN的1:1物理专线备份路由；
4. 故障在50ms内自愈，提供99.99%以上的可用率。
本篇文章《BIGO骨干网设计与实现(一)》将介绍BIGO骨干网的设计思考与“智能流量调度”的具体落地实现。
一、骨干网络的位置
BIGO网络经过不断的迭代演进，已经形成了模块化的组网架构。
如图1所示，骨干网(BBN，BIGO Backbone Network)在BIGO网络中是最核心部分，负责连通BIGO分布于全球各地的城域网(MAN，Metro Area Network)，连通BIGO全球各地的数据中心。此外，骨干网也用于连通BIGO全球各地的出口网络(BIX，BIGO Internet eXchange)。因此，骨干网的能力与稳定性关系到BIGO所有上层服务的质量。
图1 BIGO骨干网络的位置
二、骨干网与SDN
BIGO 2018年第一代骨干网，用的是Segment-Routing Tunnel方案；2021年BIGO第二代骨干网，用的是SR-Policy加自研SDN控制器方案。
关于BIGO对“SDN控制器”的思考，为什么用SDN，这里简单回顾一下。
首先是传统网络技术与“SDN”之间的碰撞。如图2传统网络模型所示，我们先看传统网络的问题：
1. 每台设备都是独立的“个体”，没有(或仅有有限的)全局视角；
2. 人工配置效率低下，易出错难维护；
3. 依赖传统网络协议的路由控制，只能根据“跳数”“开销”等有限参数选路，难以精确表达用户的意图。
另外，我们也要看到传统网络的优势：正因为每台设备都是独立的“个体”，有独立的控制平面，依靠标准协议互通，传统网络天然实现了分布式高可靠。从网络模型的角度看，不存在单点故障，不存在单一设备影响整个网络的问题。
图2 传统网络模型
我们再看看SDN网络模型，如图3所示。最初的SDN以OpenFlow为代表，网络设备只保留纯粹的转发功能，控制平面(转发表项下发)由控制器统一接管。
好处是网络控制器作为“大脑”有了全局视角，可以实现全局的流量工程，弊端是控制器压力巨大，控制器故障容易导致全网故障。骨干网作为核心网络不可能采用风险这么高的方案。
图3 SDN集中控制模型
然而，技术不一定要非黑即白，传统的分布式网络与SDN的集中控制是可以完美融合的。如图4，网络设备可以保留自身控制平面，控制器通过配置、调整网络协议参数、或下发转发表项等多种方式控制网络流量。
图4 SDN集中控制与分布式网络的结合
这种方案通过恰当的设计，可以允许控制器故障，不会对网络造成致命影响。这里稍作展开：
首先，网络作为一个分布式系统，必定遵循CAP原则。也就是一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)，这三个要素最多只能同时实现两点，不可能三者兼顾。
在分布式网络引入了集中式SDN控制器后，我们更需要根据CAP原则去设计并有所取舍——这里BIGO骨干网的做法是控制面保证C+P，转发面保证A+P。
控制面不保证A，是我们设计时会考虑控制面-数据面不可达，当出现控制面-数据面丢包/时延过大/抖动过大时，网络需要整体可用。
转发面不保证C，是我们要允许转发设备数据不一致。网络协议需要收敛时间、控制器计算需要时间、控制器故障恢复需要时间。这些“收敛”的期间就会出现数据不一致。我们要实现短暂不一致时转发正常，无法确保控制器和转发设备数据一致时可以完全放弃控制器与数据面的一致性，可以“Fallback”。
BIGO第二代骨干网的设计遵循了以上原则。
有了全局视角(控制器)，同时又保证了分布式网络可靠性后，我们就可以做很多有趣又“真香”的事情。例如我们可以实现全局的流量工程，可以可按时延、带宽、质量等目标自动调整流量路径，让网络带宽利用率最大化、业务质量更优、时延更小。又例如，我们可以实现IBN(Intent-Based Networking)，基于意图的网络。
如图5，是我们生活中很常用的场景：从广州到北京，有很多路可走。但不同的人会有不同的想法，例如需要高速优先、成本优先、需要经过杭州、不能经过“高风险”地区等组合需求。
图5 地图导航与基于意图的网络
在BIGO的骨干网中，也有不同的业务，也有“千奇百怪”的需求，通过大脑（控制器），我们都可以将需求一一表达并实现。
三、技术选型
前文介绍了BIGO骨干网的特性、BIGO骨干网选择了SDN控制、能实现自动的全局流量工程、能匹配用户意图。此外，我们研发骨干网2.0还确定了一个明确的目标：兼容多厂家路由器，兼容交换机，大幅降低建网设备成本。
要建设这样一张有成本竞争力的、自主可控的、智能的骨干网，底层技术该如何选择，如何实现？
我们分别看转发面与控制面。
转发面
能实现流量工程的转发面技术无外乎以下几种：
1. MPLS RSVP-TE Tunnel
2. MPLS SR-TE Tunnel
3. MPLS SR Policy
4. SRv6 Policy
对比以上几种技术：
首先我们排除传统的RSVP-TE，RSVP-TE需要所有途经节点都维护隧道状态，扩展能力受限，配置复杂，对中低端设备也不友好。
其次，我们对比SR Policy 与SR-TE Tunnel，可以明确SR-TE Tunnel只是SR初步发展时的阶段过渡性产物，SR Policy在引流、下发、新特性支持上都更有优势。
最后，我们对比MPLS SR Policy和SRv6 Policy。从业界风向来看，SRv6 Policy是底层网络的最终演进方向，但在当下SRv6 Policy面临几个严峻的挑战：
1. ASIC/NPU对SRv6的支持。SRv6的包头相当长，很多稍有年份的网络芯片无法一次读取完整的SRv6包头进行转发决策。要解决这个问题通常要求报文在芯片内部环回，对报文进行二次读取，这会导致吞吐量减半，而且大部分设备厂家都不提供这种操作的接口。这就导致，要用SRv6，厂家、设备、芯片选型将大大受限。
2. 同样是SRv6的包头过长问题，导致SRv6的协议开销远大于MPLS SR。我们以BIGO流量的平均净荷(略小于IMIX平均净荷），平均压入5个标签进行计算，SRv6的承载效率低于80%，而MPLS SR可以达到95%以上。对于昂贵的国际链路，15%的差距难以接受。
3. 继续是SRv6的包头过长问题，业界提出了几种SRv6的头压缩方案，例如uSID、GSID等。这些头压缩方案都相对复杂，且业界至今未形成统一标准，厂商各自为战，更有不少厂家到还未支持头压缩。这也使得厂家、设备、芯片选型大大受限。
综上，由于SRv6 Policy的不成熟，我们选择了MPLS SR Policy 作为我们转发面技术。(我们在2020年进行技术选型，放到今天2022年Q2也基本适用)
控制面
我们选择引入SDN控制器进行全局调度，那就需要一个可以让网络设备和控制器“沟通”的主力协议。对于转发面为MPLS SR Policy，可用协议有3种：
1. BGP SR扩展
2. PCEP
3. CLI/Netconf
PCEP协议支持SR Policy创建、路径下发、状态上报，功能最为齐全，也相对成熟。然而各个设备厂家对于PCEP的支持并不一致，即使是支持也分为PCC Initial和PCE Initial，再考虑到大部分“网工”对于PCEP的熟悉程度都不高，我们放弃了PCEP。
BGP SR。在BGP基础上扩展而来，“网工”们都很熟悉、易于上手，也支持诸如GR、RR、路由过滤等BGP基础特性，厂家们支持得也不错，是很不错的选择。但BGP SR缺少了状态上报，这就要求我们有额外的SR状态上报协议，例如通过BGP-LS扩展，或telemetry方式。
CLI/Netconf，就是模拟静态配置，优点是清晰简单易懂，且静态配置不会因控制器故障而丢失，缺点是下发速度相当慢，同样也需要额外的状态上报协议。
最后，BIGO控制器选择了BGP SR + Netconf方式。BGP SR用于大量且快速的路径控制，Netconf用于下发少量不会变化的全局性策略。而状态上报我们同时实现了BGP-LS扩展和telemetry方式，以提供最好的兼容性。
四、智能流量调度的实现
SDN+SR Policy技术可以擦出什么火花？可以为网络提供什么优势？获得什么收益？
其中之一是可以实现智能流量调度。通过智能流量调度技术，我们可以提升网络利用率、增加成本竞争力、实现网络多维可视、优化业务体验、提供基于意图的网络服务能力等等。
要了解智能流量调度如何实现，可以将网络流量调度类比为“自动驾驶”，看要做到什么：
1. 首先，要有实时的完整的“高精地图”(网络拓扑)，要有上帝视角；
2. 要有实时的流量数据，知道哪里“堵车”(拥塞)，也要知道路有多宽(链路带宽)；
3. 要有“导航”(路径计算)，例如用户要求从广州到北京走最快的路，要能自动规划路线；
4. 要有“自动驾驶”能力，流量要能自动根据导航线路走，导航挂了还能走；
5. “导航”要能自动实时调整路线(调优)——“已自动为您避开拥堵路段”、“前方交通事故封路，已为您重新规划路线”、“您已偏航，已为您重新规划路线”；
6. 要“让救护车/消防车/警车先走”(区分业务优先级)
7. ……
通过上述能力，我们才能做到网络 “自动驾驶”，做到智能流量调度。以下我们逐一介绍里面的实现细节。
实现智能流量调度——“高精地图”
对于网络来说，“地图”其实就是拓扑数据。而网络拓扑都可以简化为Node和Link两种基本元素。链路状态协议OSPF或ISIS的LSDB是天然的拓扑数据库，协议还保证了拓扑数据的最终一致性。
因此，我们需要骨干网所有设备之间运行一个链路状态协议(本篇文章暂不介绍跨域处理)，设备之间通过协议同步拓扑数据(生成并同步LSDB)。通过ISIS/OSPF的TE/SR扩展，同时为前缀/链路分配SR标签，并同步链路带宽等TE属性。
最后我们可以选择一台或多台(冗余)设备，将拓扑数据通过BGP-LS协议上报控制器。这样，控制器就获得了全网的拓扑数据，就能绘制出网络的“高精地图”。
图6 获取网络拓扑数据
实现智能流量调度——“知路况”
有了“地图”后，我们还要知道每条道路的“路况”——要知道哪里“堵车”(拥塞)，要知道路有多宽(链路带宽)，也要知道哪里“路况不好”(丢包/时延/抖动)。有了这些数据，才能做好“路径导航”。
如图7所示，“路况”数据分为流量、带宽、质量3类，流量我们通过telemetry实现秒级上报；带宽数据可以通过BGP-LS实现触发更新(例如捆绑链路的成员接口数量变化)；质量数据可以通过TWAMP-LIGHT采集并通过telemetry或BGP-LS上报。
图7 获取网络流量、质量、带宽数据
实现智能流量调度——“导航”
流量的“导航”，与生活中的“导航”类似。生活中我们可能需要从广州到北京，一条可以在2天内到达的花销最小的导航线路；对于网络业务，也会需要从广州到北京，一条时延在60ms内成本最小的线路。
实现“导航”涉及到两个关键，一是基础路径算法，二是满足业务意图。这里我们列举一些常见的“业务意图”：
1. 总时延(RTT)小于100毫秒
2. 从新加坡到美国洛杉矶，不能经过日本节点
3. 大数据业务的流量，要走指定的专用线路
4. 从香港到荷兰阿姆斯特丹，提供由海缆A+B组成的保护线路
5. 提供一条备选路径，与主路径尽量不共路
以上这些“业务意图”，其实我们都可以转换为两种类型：“计算目标”与“路径约束”。在通过算法进行路径计算时，将包含一个或多个计算目标和全部约束，最终就能得出满足“业务意图”的路径。
了解“意图”后我们再看“算法”。计算网络路径，离不开最短路径算法。在这里，我们既要满足约束，也要考虑计算目标(例如时延和开销)，还要做到快速快速。
满足约束，我们可以通过CSPF算法实现。如图8所示，计算时可以将不符合严格约束的路径“修剪”掉再进行计算，即可得出符合需求的结果。对于非严格约束(例如“尽量”不共路)，我们可以通过计算路径时增加临时开销方式实现。
图8 CSPF算法实现
最短路径算法何为“最短”，就是我们所谓的计算“目标”。通常目标有“开销”(cost)、“时延”、“链路可用度”等，我们只需要将不同的“目标”带入同样的最短路径算法，就能得出最小开销、最小时延、最佳可用度等结果。
但当我们的需求中同时出现多个“目标”，或者出现一些难以“裁剪”的约束时，情况就复杂起来了。例如“要求总时延小于100毫秒的cost最小路径”就是一个例子。由于这在数学上已经属于NPC问题，我们的思路是通过启发式约束最短路径算法，将时延约束吸收到最短路径算法中，使得问题易于求解。
实现智能流量调度——“自动驾驶”
有了“导航”后，我们还需要网络流量能“自动驾驶”，也就是自动根据导航线路走。同时还要注意自动驾驶不能完全依赖导航，就像我们不能确保GPS百分百可用，我们也不能祈求网络的“导航”永远在线。“自动驾驶”还需要有紧急避险能力。遇到了突然的封路、前方出现车祸、路上冲出一个小动物等情况（网络故障），我们的流量都要能以最快速度自动避开。
网络的“自动驾驶”技术，其实就是网络转发面的“流量工程”技术，如前文所述，BIGO选择了MPLS SR Policy。
SR(Segment-Routing)是一种“源路由”技术。在流量进入的设备上，指定流量的转发路径。控制器完成“导航”计算好路径后，通过BGP SR给“源设备”下发SR Policy，实现流量按照“导航转发”。大致流程如图9所示：
1. 在流量进入的设备(头端)上，根据SR-Policy给数据包插入SR标签(SID)
2. SR标签可以标识一条链路(link)或一个节点(node)
3. 设备根据“顶层”SR标签进行转发
4. 转发时同时弹出“顶层”标签
5. 最终将原始报文送达目标设备
图9 SR Policy网络”自动驾驶”
从图9还展示了SR Policy提供多条“候选路径”的能力，这就可以让“导航系统”一次性计算多条分离的可用路径，一条不通走另一条。也能下发“基于最短路径自动驾驶(转发)”的指令(Node-SID)，实现即使导航挂了还能走。
至于“紧急避险”，就是“流量路上走，故障天上来”时如何处理。这时控制器的“导航”还未来得及反应，甚至控制着“自动驾驶”的头端设备都还感知不到遥远的某个地方出现了链路或节点故障。要最快速度“避险”，就要靠“本地保护”技术——Ti-LFA。“本地保护”顾名思义，是通过与故障链路或节点直接相邻的设备本地实现的，因此可以实现50ms内的故障切换。
*故障切换技术有“本地保护”与“端到端保护”，在SR Policy场景中涉及候选路径的切换，在控制器环境下涉及到“导航”路径更新、“导航”路径保持与“导航”路径失效问题。BIGO的骨干网实现任意节点或链路故障50ms自动修复，流量10秒内恢复到最优路径，控制器故障不影响网络可用，极端情况下还有多级兜底机制。其中涉及到的理论体系与设计细节较多，我们在本系列文章后续通过专题介绍。
实现智能流量调度——“实时调整导航路径”
“实时调整导航路径”，也就是流量调优，这是智能流量调度的核心。通过流量路径的实时调整，我们可以避免链路拥塞、可以在满足业务意图的基础上使网络利用率最大化、可以识别链路的质量变化并重新分配跑在上面流量。
这里对其原理做简单的介绍，如图10，以避免拥塞为例：
1. 控制器可以实时感知“路况”，知道哪些链路即将拥塞(例如流量跑到80%了)
2. 控制器也知道有哪些SR-Policy跑在拥塞链路上
3. 控制器还知道网络中每一条路径的可用带宽(例如阈值设置80%，当前流量40%，那还有40%可用)
4. 控制器通过局部调整算法+全图启发式算法，对网络中的SR-Policy路径进行重新计算
5. 将新路径通过BGP下发，调整流量路径，使链路不再拥塞(流量在风险阈值之下)
6. 智能流量调度除了避免局部拥塞，还能使网络利用率最大化，让高优先级业务抢占低优先级业务资源，保证高优先级业务资源最优。
图10 智能流量调度，避免网络拥塞
实现智能流量调度——“让重要业务先走”
网络的容量都是有限的，在多点故障或业务流量微突发时，控制器再智能，调度算法再优秀，也可能面临“带宽资源”不足的问题，正所谓“巧妇难为无米之炊”。
面对这种情况，流量调度已经无法有效工作，更多的是考虑如何保证高优先级的重要业务先走，本质上是传统的QoS问题。这里我们通过控制器，实现了灵活的业务级别标记，也能提供灵活的限速或阻断策略。
如图11所示，控制面使用Flow-Spec特性，给头端设备下发策略，实现对报文的灵活标记、限速、阻断、重定向等动作：
1. 例如1.1.1.1是重要的数据库业务，控制器下发Flow-Spec路由，携带流量策略：匹配目标IP为1.1.1.1，执行重写DSCP=46的动作
2. 头端设备上根据这条Flow-Spec路由，对目标IP=1.1.1.1的流量进行DSCP重写
3. 设备根据DSCP将流量放入高优先级队列(例如Priority Queue)
4. 这就实现了即使网络拥塞，也是高优先级流量先跑，高优先级流量跑光了其他流量才能跑。
图11 Flow-Spec实现灵活策略控制
五、总结
以上，本篇介绍了BIGO骨干网的技术选型与“智能流量调度”的实现方式。
后面我们或将展示BIGO控制器的功能、组件、架构、工作逻辑；或将探讨骨干网络的整体架构，完整的高可用解决方案如何实现；或将聊聊控制器的开放性，南向多厂家和交换机的兼容、北向的灵活API、多维度的业务可视能力。
▼版权声明
转载本网站原创文章需要注明来源出处。因互联网客观情况，原创文章中可能会存在不当使用的情况，如文章部分图片或者部分引用内容未能及时与相关权利人取得联系，非恶意侵犯相关权利人的权益，敬请相关权利人谅解并联系我们及时处理。