前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >SRv6开启网络服务化变革之旅

SRv6开启网络服务化变革之旅

作者头像
SDNLAB
发布2021-01-25 11:53:41
1.6K0
发布2021-01-25 11:53:41
举报
文章被收录于专栏:SDNLAB

作者简介:李和松,长期从事数据通信、SDN、NFV产品架构和市场推广工作

近年来,段路由技术(Segment Routing,以下简称SR)作为IP领域最重要的技术突破之一,已成为运营商5G数据传输网的主流选择。SR起初被认为是下一代的MPLS技术,即所谓的SR-MPLS。随着云网融合的逐步推进以及IPv6的广泛部署,SRv6技术异军突起成为新的网络研究热点,被普遍认为是智能云网时代最具潜力的新技术。本文以SRv6技术为切入点,分享个人对SRv6技术原理和应用前景的阶段性思考。

从SR-MPLS到SRv6,用IP解决IP本身的需求

SR技术的核心在于引入源路由的思想,并通过一系列控制面协议扩展以及与SDN的结合让该思想得以顺利落地。在技术设计之初,SR已经考虑在MPLS和IPv6双转发平面的支持。具体而言,在不改变MPLS基本转发行为的前提下,通过MPLS标签标识Segment,这种方式称为SR-MPLS;或者充分利用IPv6扩展头的机制,通过SRH头部中的IPv6地址标识Segment,这种方式称为SRv6。

笔者认为,从SR-MPLS到SRv6,并非简单的转发平面的切换,其更深层次的变化是回到了IP Native的框架内,用IP解决IP本身的需求,真正意义上体现了技术的架构之美。

回顾MPLS技术发展的历史,其本质上是将IP和ATM技术结合,通过在报文二层头和IP头之间插入MPLS标签栈,将传统的IP转发行为旁路为MPLS标签转发,并通过赋予MPLS标签不同的含义形成了L2VPN、L3VPN等一系列新的网络服务模型。MPLS技术这种向下插入标签栈旁路IP转发的方式所带来的直接后果是它丧失了IP技术的普适性,需要网络设备逐跳支持标签转发,这某种程度上将其限定为运营商网络的专属技术,一般只在运营商IP骨干网或者新建的城域网内采用,在数据中心和企业网中基本没有部署。因此,SR-MPLS受困于MPLS本身,最终也只能被定义为MPLS技术的下一代演进而已。

再反观SRv6,它充分利用IPv6原生的扩展头机制,使用IPv6地址本身作为Segment标识,通过在IPv6报文头和净荷之间插入SRH的方式实现源路由路径信息的编码,在报文的整个转发过程中,普通的中间节点仅支持IPv6转发即可,无需支持特殊的转发逻辑,从而将Underlay网络的范围从MPLS的标签分发域扩展到了IPv6联通域,极大地增强了SRv6技术的扩展性和部署的灵活性,这也赋予了SRv6技术未来丰富的想象空间。

SRv6的技术价值在于继承并发展了SR-MPLS

笔者认为,SRv6的核心技术价值在于继承了SR-MPLS几乎所有的新特性,同时引入了网络可编程的思想,从而极大地发展并丰富了传统SR技术的内涵,具体分析如下。

1.关于继承

在很长一段时间,业界关于SR技术的探讨都集中在SR-MPLS体系内,且相关工作已经率先完成标准化。如前所述,SR大部分的技术特性从一开始就考虑了MPLS和IPv6两种转发平面,因此,无论是对IGP/BGP协议的扩展,还是流量工程框架的设计,只需将MPLS标签栈转换成具有同等意义的SRH,大部分的技术特性都可以得以延续。以笔者多年的协议研发经历来看,只要协议框架设计合理,这种改动几乎不会造成过大的工作量。以拓扑无关LFA(业界称为TiLFA)技术为例,如图所示,同样的倒换算法,同样的倒换机制,只不过路径编码从MPLS标签栈变为SRH,依然可以实现拓扑无关的50ms级快速保护机制。

因此,从SR-MPLS技术演进到SRv6,并不会造成核心功能的缺失。

2.关于发展

除了继承,SRv6还极大地发展了传统SR技术的内涵,其中最核心的当数网络可编程理念的引入。

由于SRv6采用IPv6地址作为Segment的标识,与MPLS标签只有20bit不同,IPv6地址多达128bit,这给了SRv6充分的发挥空间。网络可编程的核心思想是将128bit的SRv6 Segment分段划分成标识节点位置的Locator和标识具体操作的Function,再结合SR的源路由机制,可将分布式的网络节点抽象成一台逻辑的计算机,并按需执行预定义的网络指令。

SRv6网络可编程打开了用IT的思想重构网络的潘多拉魔盒,笔者认为,其影响力不亚于当年的SDN和NFV(虽然网络可编程与SDN/NFV技术并不冲突)。具有分布式软件开发经验的人对SRv6网络可编程思想应该不会陌生,像极了分布式系统软件设计中常用的RPC(Remote Procedure Call)机制,只要定义和使用得当,SRv6可以扩展为一种基于网络能力的编程语言,完全具备理论意义上的图灵完备性。

综上所述,SRv6完美地继承并发展了传统SR技术,而网络可编程将成为SRv6最引人注目的新特性。

SRv6应用价值探讨

SRv6技术突破了传统MPLS技术物理网络边界的限制,其应用价值不再囿于运营商的广域网。因此,在思考SRv6应用价值时,笔者选取了运营商和公有云服务提供商两种视角进行分析。

1.运营商视角

从运营商视角分析,SRv6最大的价值在于能最大限度地挖掘网络的变现能力,这集中体现在规模和效率两个方面。

在规模方面,与SR-MPLS技术一样,相较于传统的IP网络而言,SRv6也极大地简化了网络服务的部署,破除了传统协议对于网络规模的限制。与SR-MPLS不同的是,SRv6技术采用IPv6替代MPLS转发,降低了网络节点的能力要求,使物理网络不再局限于标签分发的边界,让大规模扁平化组网成为可能。熟悉运营商MPLS部署现状的人大多都知道,拉通跨域MPLS Overlay服务在技术和管理上都是极其复杂的,而SRv6技术很好地解决这些问题,以更好地支撑运营商中长期的网络规模增长需求。

在效率方面,SRv6可从多维度提升网络服务效率。从网络自身来看,与SR-MPLS技术一样,通过与SDN技术相结合,可在更大的范围内实现流量工程(相比于RSVP),提升全网资源的利用率;从服务角度来看,相比与SR-MPLS技术,SRv6推动了网络能力的进一步开放,将差异化服务进一步向用户侧延伸。

综上所述,SRv6对于运营商的价值在于满足未来网络对于规模和效率发展的需求,至于网络可编程,受软件研发能力、物理网络的复杂性、组织架构以及设备商的掣肘等多方面因素的影响,短期内难以看到明确的实施路径和经济价值。

2.公有云视角

个人认为,除了运营商网络之外,SRv6技术在公有云领域同样具备广阔的应用前景,将协助公有云进一步推进网络服务化,最终实现网络即服务的理想。

公有云发展至今,通过自研和采购相结合,大部分公有云服务提供商已经具备相当完善的网络产品和解决方案,可以为政企客户提供云内、云间以及上云的一站式网络服务。相比传统的运营商网络而言,公有云网络具有如下特点:

  • 网络产品自研占比高,整体自主可控

依靠强大的软件研发实力和巨大的采购量,公有云网络中的软件和硬件自研率占比远高于运营商,基本上实现了网络的自主可控。以某公有云服务商为例,虚拟化网络产品基本全自研,数据中心交换机、路由器甚至光层的DCI设备大量采用白盒化设备与自研软件相结合的模式。

  • 组网规划性强,功能需求相对明确

与运营商网络不同,公有云网络属于强规划型网络,技术异构性不强,虽然网络整体规模也不小,但组网模式固定,且功能需求明确,没有过重的历史包袱,从而在管理运维效率以及成本控制上都更有优势。

  • NetOps极大提升了网络迭代效率

基于大量的IT研发人才储备,从DevOps衍生而来的NetOps已率先在公有云服务商中落地,小步快跑的研发模式使得网络能力可以快速推陈出新。

从公有云网络自身演进的角度分析,SRv6作为重要的候选技术之一,其应用价值将集中体现在如下几个方面:

  • 促进公有云和运营商网络的融合

从连接的角度来看,公有云网络的上云以及云间互联段往往依赖运营商网络,然而,无论是组网模式还是协议部署,公有云云内网络和运营商网络都大相径庭,对接的复杂性和服务交付的灵活性问题也随之而来。从当前的现状来看,MPLS向云内延伸的可能性较低,SRv6基于统一的IPv6转发面,将有望促进公有云和运营商网络的深度融合。

  • 促进公有云Underlay和Overlay的融合

当前公有云网络普遍采用Underlay IP, Overlay VxLAN的技术组合,结合自身技术的特点,可灵活采用软件Overlay(Host Overlay),硬件Overlay(Network Overlay)和 混合型Overlay方案。SRv6技术有望取代VxLAN,通过VNF,PNF以及SDN产品能力的高效整合,实现Underlay和Overlay的进一步融合。

  • 促进公有云计算和网络的融合

SRv6网络可编程使得网络的服务化水平进一步提升,网络讲应用的“语言”,进一步提升网络服务化水平,进而促进计算和网络的高水平融合。

综上所述,SRv6在公有云网络中的价值体现为具有推动网络即服务高水平发展的潜质。背靠强大的研发实力,SRv6将成为公有云网络持续演进过程中的核心技术之一。

关于SRv6的一些个人观点

通过对SRv6技术和标准的长期跟踪,笔者形成了一些个人观点,在这里做仅做简单的

陈述。

  • 对于运营商而言,SRv6技术虽好,但大规模商用尚早

从笔者参与和调研的国内外运营商5G网络建设项目来看,除少数比较激进的小运营商以外,当前主流的技术路线选择依然是SR-MPLS,但大部分运营商都在探索如何从SR-MPLS平滑演进到SRv6,造成这个局面的主要原因有:

(1)标准和产业尚未完全成熟

运营商行业具备标准和产业依赖的惯性,IETF Spring工作组异常活跃,SRv6相关的标准化工作正在紧锣密鼓进行,然而当前真正完成标准化的仅有架构和SRH封装格式,按照IETF标准平均2-3年的成熟周期,SRv6形成完善的标准体系尚需时日。此外,产业界除少数厂家策略较为激进以外,大部分厂家都主推SR-MPLS,这不仅是产品策略的问题,更是一种对待技术的谨慎态度。

(2)SRv6所带来的增量价值目前尚不明显

经过统计,当前大部分部署或者试点SRv6的网络所用到的网络能力都比较单一,绝大部分还是局限于传统MPLS L2VPN/L3VPN服务的技术替代和管理升级,网络可编程等新特性尚未使用,相比SR-MPLS而言,SRv6技术所带来的增量价值并不明显。

(3)SRv6网络服务模式有待探索

当前业界对于后SRv6时代网络的服务模式还处于探索期。最理想的情况是充分利用SRv6的技术优势,让网络回归服务的本质,能为用户提供媲美智能导航系统一样的信息高速驾驶体验,但这里涉及一系列问题需要解决,如智能导航系统是运营商的一种自用能力,还是可以直接对外提供服务开放,如果对外实现能力开放,对哪些用户群开放,开放到什么程度,商业模式如何,开放所带来的安全风险如何防范,这些问题至少在目前尚未有明确的答案。

基于上面的分析,在肯定SRv6价值的前提下,笔者认为运营商网络大规模实施从SR-MPLS向SRv6迁移的时机并未成熟,但小规模试点或者在新建网络中要求设备具备SRv6基础能力是合理的。

  • 公有云网络是SRv6价值孵化的最佳土壤

如前所述,公有云网络具有高度的自主可控性,背靠自身强大的软件研发实力和规模效应,其标准和产业的依赖程度很低,为SRv6提供了最佳的孵化土壤。充分利用SRv6的网络可编程、基于IP Native的SFC以及Underlay和Overlay融合的能力,公有云网络有望彻底服务化,从而更好地支撑万物互联时代泛在的云服务需求。

  • 管理和安全问题会影响SRv6部署的进度和模式

如果把SRv6比作一套功能齐全的精美厨具,那么网络建设者就是厨子。最终能做出什么样的菜品,往往是厨子以及酒店管理等多方面因素决定的。笔者认为,管理和安全性的问题会极大地影响SRv6的部署进度以及具体的落地模式,因此,后SRv6时代的网络,即不会是纯技术推演的结果,也不会拘泥于当前的管理和技术现状,所以不必担心网络会变得更加同质化,毕竟适合自己的才是最好的。

  • NetOps将成为SRv6网络的关键能力要求

单纯从SRv6网络可编程的角度来看,新的场景和需求不断涌现,SRv6的操作符也在不断扩展,这一方面使得标准收敛的周期越来越长,另一方面也要求网络软件和硬件具备更快的迭代能力。传统网络的基本模式为标准化成熟→建设→运维,网络能力在建设之前基本已经固化。而SRv6时代,网络能力的更新将贯穿于网络的全生命周期。因此,NetOps将成为未来SRv6网络的关键能力要求。

值得一提的是,从网络软件产品的角度来看,NetOps的经验可从DevOps中复制而来,而网络硬件产品的NetOps能力从中长期来看受制于硬件架构本身。当前运营商领域有一些声音认为只要采用NP可编程架构,硬件产品的平滑演进将不会是问题。有过NP微码开发经验的人都清楚,即使NP相比于ASIC而言有一定的灵活性保证,但这种可编程能力是机其有限的。从这个角度来看,要充分体现SRv6的灵活性,对硬件平台可编程能力要求更高,至少在当前阶段,基于FPGA/P4的硬件方案比NP方案在灵活性上更胜一筹。

关于SRv6技术发展的几点呼吁

为了促进SRv6技术的更好发展,笔者结合当前观察到的问题提出几点粗浅的建议仅供参考。

  • 希望运营商和公有云以SRv6为契机,在网络技术领域强化合作

当前对SRv6技术的探讨更多集中在运营商行业,公有云厂商则发声较少,进行观点碰撞的机会则更少。运营商关注网络本身较多,但对云业务的网络需求思考相对较少,且自研能力薄弱;公有云厂商关注云业务较多,对云业务的网络需求深刻理解,且研发落地能力较强,但对网络前沿技术的跟进力度有限。如果运营商和公有云能强化在SRv6网络领域的合作,在标准化和产业化方面实现能力互补,将更有利于推进“云网融合”的高水平发展。

  • 希望将SRv6作为一种IT基础能力进行人才培养和产业孵化

目前SRv6的开源生态已经初成规模,但其关注度还停留了通信行业的小圈子内,没有转化为数量庞大的IT类人才的基本能力。一个很现实的例子在于Linux内核已经比较早的支持SRv6能力了,相关的编程接口也有提供,但真正能熟练掌握利用SRv6能力进行应用编程的人员却极少,这种现状亟待改变。

  • 希望IETF标准组织聚焦场景,而非无限制的能力扩展

网络的可编程与IT的可编程毕竟有本质的区别,从网络回归服务的本质是网络可编程的最终目标。大开脑洞地无限制强调技术的灵活性,必然带来标准化进程的拖延和低水平发展,对于产业化来讲也并非好事。举个简单的例子,随着新场景和新需求的不断加入,SRv6操作符在不断增多,一旦涉及到具体场景的落地,如何选择能力子集则至关重要。因此个人认为,对SRv6能力的探讨应该更加聚焦于场景,先根据场景需求对网络基础能力进行收敛,将更多的精力放在思考如何通过有限的能力集提供更加灵活的网络服务上。

总结

SRv6技术作为近年来网络技术领域最重要的创新成果,有望引领网络服务化的变革之旅,笔者相信,通过全体热衷于构建更好连接服务的CT和IT人的集体努力,SRv6技术一定能大放异彩,让更多用网之人不再受困于网络本身。

往期推荐:

  1. SRv6技术研究和组网设计
  2. SRv6可编程技术-SRv6 Policy
  3. SRv6技术课堂:SRv6可靠性方案

网络操作系统混战,SONIC能否笑傲江湖?

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-01-19,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 SDNLAB 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
CODING DevOps
CODING DevOps 一站式研发管理平台,包括代码托管、项目管理、测试管理、持续集成、制品库等多款产品和服务,涵盖软件开发从构想到交付的一切所需,使研发团队在云端高效协同,实践敏捷开发与 DevOps,提升软件交付质量与速度。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档