IP网络从1982年TCP/IP 成为互联网前身的ARPANET标配以来，随着互联网的发展而迅猛扩展。在数据网络方面基本已经一统天下，做到了 everything over IP。IP网络作为承载互联网，物联网，云计算以及VR，AI等未来各种无限可能的数据服务的底层网络，其灵活性，扩展性以及对业务的支持可编程需求要求网络更快的完成自身演进。

SDN网络与传统网络对比分析

从IP网络的整体发展看，从网络的基本可以清晰的分为三个阶段，当然这三个阶段的网络在现实世界是并存的。

纯IP网络 (IP战胜了其他网络层协议，成为数据网络的主流)

1.MPLS based 网络

2.SDN 网络

3.纯IP网络

回退到几十年前，IP网刚诞生时，IP协议和IP网络还是有很多竞争对手的，比如IPX，Appletalk，Netbios，这些现在听着很久远的协议当时还是很流行的。比如IPX在企业网就远比IP流行。当年的网络和网络设备复杂性很大程度体现于支持多种网络层协议，支持从E1到OC-12，OC-48的多种网络速率和接口类型。IP以及Ethernet仅是众多选择中的一种。

APPANET 选择TCP/IP组合后，IP的简单易用，Ethernet的低成本，再加上互联网的病毒式传播，短短的20年。这三者的强力组合就像 Intel + 微软一样，横扫数据网络。 可以认为应用层发轫的Everything Over IP 水到渠成，到了2000年左右，语音网络，视频网络和数据网络，已经可以说是 Everything Over IP了。

纯IP网络主要在统一网络层协议和简化传输介质上贡献显著。

纯IP网络的转发

1.从本质上说是逐跳基于目的IP地址转发

2.完成这个动作的方式是通过 IGP + BGP 路由协议来实现

3.附加的网络调控手段：PBR，ACL， IP-Based QoS

这个阶段的网络主要实现连通的目的，通过IGP和BGP路由协议，获取AS域内和域间路由。构成网络的路由器或交换机根据路由表，形成转发表。当IP报文到达接口，入方向的芯片提取IP报文头，根据目的IP查找转发表，找到出端口。

多年来，大多数企业网，园区网以及相当多运营商的公众网都采用这种方式。优点是简单，大多数设备都支持。随着路由协议的大规模使用和设备的大规模部署，作为整体系统的健壮性，可扩展性和稳定性以及建网成本都有了很大的优化。相应的网络设备芯片体系也日趋完备。

但从服务的角度则看起来乏善可陈。当业务对网络有连通以外的要求时，比如要基于源地址进行选路时，设备可以通过PBR(Policy-based routing)实现。但这并不是一种普世的服务，对于少量，临时，非做不可的需求，可以用CLI在某些节点配置，但没有人会疯狂到在全网通过PBR去做路由。网络工程师通常称PBR这样的实现叫做“Feature”。

在那些年里，厂商们各自都有很多Feature。用于炫技，用于投标，用于教育客户。用于不那么完美的解决某些实际问题。

Feature 有两个隐含的意思：

1.不是随便的阿猫阿狗就能实现的，是一种能力

2.起了这个Feature是对网络和设备而言都有代价有条件的

另一个现象是当某些需求用Feature无法满足，或者是设备的性能瓶颈，或者是功能瓶颈时，网络工程师又设计出各种appliance，叠加了特殊功能的各种大box和小Box，最著名的就是防火墙，还有4-7层交换，广域网优化等。这些设备说到底，还是在对IP报文的处理上，解决了“基于目的地址寻址”以外的问题。

总结来说，在纯IP网络时代，是靠路由协议+feature+appliance满足基本需求的。

MPLS based网络

在IP协议和IP网络PK掉ATM时，尽管ATM协议的复杂和设备昂贵等诸多原因导致了市场的失败。 IP网也由衷的羡慕ATM实现的虚电路的优势，对于无连接的IP来说，如果能形成一个按需的虚电路，能够根据用户的特点提供不同的服务质量和转发路径，是非常有吸引力的事情，再加上当时转发性能的一些瓶颈，综合因素促成了MPLS的诞生和流行。

当MPLS开始规划化使用和部署时，两个基本概念是代表了运营商期盼已久的事情。

FEC转发等效类

FEC(Forwarding equivalence class) ，对于相同分类的一组数据报文，提供相同的转发处理方式。 这里所说的相同分类，相同的目的地址仅是其中的一种，基于不同的标准进行自由的网络转发一直是网络工程师的愿景之一。

LSP：Label-switched path

LSP 基于FEC对报文的分类，实现了端到端的对IP报文封装，在每跳基于Label进行转发的单向虚电路，正如IP网络向Frame Rely,ATM, SONET/SDH 学习的初衷，MPLS把网络分为Core 和Edge两个部分，其基本想法是Edge设备封装各种需求，Core部分仅完成标签转发。

在全网通过Label的分发机制，从Edge节点通过Label替代目的IP地址，在网络的提供了转发平面的抽象。

MPLS的强大之处在于基于标签交换，开发了一系列服务。

1.VPN服务：L3VPN，L2VPN，VPLS

2.TE：Traffic Engineering 服务

3.Multicast 服务

其中最成功的要算部署相当广泛的L3VPN服务。其背后原因可能是三层网络隔离而出现的巨大市场需求。即使在没有L3VPN的互联网，IPsec，SSL VPN等技术也发展起来。

其他的VPN如VPLS，尽管有一定的使用。但由于其市场需求有限，且有一些MPLS网络共性的缺点和自身弱点，始终没有大规模实施。

MPLS 当年雄心勃勃，在IETF有多个WG，无数RFC在同时演进。但复杂套着复杂，最后很多内容变成曲高和寡的纸上文章。至少在能接触到的中国运营商和企业网层面无法大规模落地。

MPLS服务的共性弱点

多层协议累加带来的复杂度和协议之间的配合问题

以实现VPLS的网络为例，至少需要如下协议：

1.IGP - 最底层的PE的/32 路由

2.LDP - 用于外层标签，PE的寻址

3.BGP - 用于Internet服务，尽管不是VPLS必须的，但IP服务的BGP，其实也是运营商的标配。

4.MP-BGP - 用于topology发现和提供内层标签

当多层协议并存时，网络服务的脆弱性来自每台设备上的每个协议是否能正常工作。同时，不同协议之间的配合存在问题时，也可能导致问题，比如经典的LDP和IGP之间的同步问题。

另外VPLS自身也存在一些弱点，比如：

1.需要Full-Mesh

2.在转发平面实现MAC地址 learning

3.不支持CE的Multihoming

MPLS-TE

TE最希望解决的问题是IGP路由协议相同的最短路径视角造成的流量过于集中在少量路径上，需要提高整个网络的利用率。因此TE需要建立和维护大量的端到端tunnel。维护这些tunnel的代价可谓不菲。而在分布式的网络架构下，TE始终没有解决好tunnel计算/维护/排障的问题，TE也局限在部分运营商网络内使用。

当然我们经过了多年之后，我们也知道理想中的FEC不过是存在想象中的美好，现实中99.9%的报文仍然是按照目的地址进行转发。受限于芯片，设备，协议/标准化，设备，操作等诸多因素制约。

通过对MPLS服务的简单分析，我们很容易看出，MPLS用Label较好的解决了转发平面的抽象，但并没有解决控制平面抽象。正是其控制平面的复杂性给网络带来的影响削弱了其部署范围。 控制平面的复杂性究其本质，还是每个协议各管一段，各满足一种需求造成的。要做VPN，需要L3VPN 或VPLS，要做流量工程，需要TE，要做QoS，需要IP or MPLS Qos 等等。 如果这些都要，你的设备是否都同时支持?你是否敢都部署?你是否愿意运维这张网络?相信大多数网工无论是运营商，集成商还是厂商背景的面对这些问题都一脸苦笑。

所以很多技术很多年后，还是被称为Advanced Technology，而非普世应用。很多时候，泛泛的说，能否实现某个功能?能，但能的前提条件太多：网络设计考虑，大量配置的复杂度，设备硬件性能支持，多厂家互通时不同设备对相同feature的配置方法和缺省行为，互操作性和兼容性，排障的可操作性。

久而久之，能就成了个理论上的，理想化的说法。 而非实打实可以简单落地的能力。

Segment Routing 是否是白衣骑士?

这两年，SR横空出世，让人眼前一亮，很有些传统网络救世主的样子，SR有两个显著的优点超越了前一阶段的MPLS 相关协议。

1.确实是非常精巧的运用了MPLS和IGP协议，大幅度省略了对标签分发协议的需求。简化了协议和网络设计。

2.SR不负责路径的计算，只负责转发。中间node真正做到了仅基于Label转发，通过在头端设备的多层压栈把路径地图内嵌在数据包头。好似带着几个锦囊出发，每到一个关键节点，再打开一个锦囊，查看下一关键节点名字和路径。 SR因此超越了最短路径算法对报文的转发限制又无需维护繁琐的无数tunnel。SR更像一个航海大师，只要有明确的航线(路径)就能按照要求去航行。

但很明确的是，SR虽好，仍然需要有人去计算和设计路转发路径。谁更合适来做?显然是SDN。

SDN网络

控制平面和具体的网络设备解耦，是SDN最重要的特点。控制平面只有在解耦后才能形成强大的大脑，对千变万化的业务层需求进行适配和编排后，再用不同方式下发成设备的转发。毋庸置疑，控制平面是否集中，集中后又如何保持HA和对全网拓扑变化的快速收敛都是问题。

从这个层面看，控制平面集中与其说是SDN的特点，不如说是这个阶段SDN为了实现而付出的必然而且必要的代价。

从某个角度说：路由需要完成的内容主要是以下三项:

1.建立拓扑，相当于网络地图

2.传递不同Node的路由信息，相当于不同村庄的居民

3.根据不同需求，计算出的从甲地到乙地的路径

从这3点看，SDN天然比路由协议有优势。因为天然就有全网视图，因为天然就已知各Node的信息。因为对接业务编排，能够综合各种需求，进行全局的选路计算。但从落地情况看也不完全如此，主要是第1点，在拓扑变化时，SDN的收敛能力在现阶段不如传统路由协议快速有效。

网络服务 vs. 网络为你而服务

简单梳理完网络的三个发展阶段，我们可以比较清楚的看到网络的变化是从最初提供可达性的IP网络，到有基本网络分割服务的MPLS 网络，到以需求为中心，能够按需提供服务的SDN网络。

事实证明为每一种需求单独创造协议是行不通的，既增加控制平面的复杂性又不具有快速演进的能力。

网络一直被应用所诟病和抱怨的是，部署速度和同时满足多种需求的灵活性。网络越大就越趋近于简单，基础的可达服务，而非能为某个application，某个临时连接，或者某个重要用户提供的即时定制服务。提供这样服务的代价在设计层面是不可规模化的，在运维层面是全手工打造的，在排障层面是灾难性的。

如何让网络在更多维度，更细颗粒度上为上层工作，除了有统一的北向接口，能够用一个大脑理解拓扑，管理设备，设计路径是一切成为的可能的基础。

思科服务部门对网络生命周期有个定义，首字母连起来是PPDIOO 分别代表P(Prepare)，P(Plan)，D(Design)，I(Implement)，O(Operate)，O(Optimize)。其中的前2个步骤Prepare和Plan主要从需求入手，依次明确战略，资源，关键任务，概念设计及里程碑等内容。从技术角度看可以归并到设计里。

ITIL 服务周期定义分为5个阶段，分别是

1.Service Strategy 战略

2.Service Design 设计

3.Service Transition 跃迁

4.Service Operation 运营

5.Continual Service Improvement 持续改进

同样从具体技术层面，可以把战略和设计合并为设计。

通常的网络实践经验来看，也可以总结为设计(含测试) - 部署 - 运维(含排障) - 优化四个阶段。

设计阶段

MPLS网络的设计阶段最终的产出物是做好测试验证的LLD(Low Level Design)。

通常在HLD(High Level Design)中明确基本布点，流量，互通，QoS等需求后要在LLD中进行量化和给出落地方案。

MPLS 网络的设计，简单来说重点就是路由协议+ 设备 = 配置。 因为需要支持多种协议，要做较多考虑。

设备层面：

要测试验证不同厂商设备的协议兼容情况

要考虑设备支持多种协议后的性能情况

协议实现层面

多种协议的并存情况下，各种单独设计之间是否有冲突。如起MPLS以后，不同厂商对QoS模型的缺省影响不同，需要手工配置一致。

SDN网络只需要考虑控制器的部署位置，网元设备的端口数量，一些必要的配套服务存在等几个基本条件即可。简化了网络设计。

部署阶段

部署通常包括：

分配和管理各种虚拟资源：IP地址段，VLAN，AS No. 等

配置模板：基于配置文件分块后大致相同的配置内容通常集中配置好，或者做初始配置后，逐个设备单独登录配置。

MPLS-base网络即使有配置脚本，也需要有基于协议状态的复杂检查过程，才能确定网络部署正确。

相比而言，SDN的网络设备配置简单，通常可轻松的实现自动化，部分设备还可实现启动后自动部署，其本质也是因为网元设备和控制器之间的多对一关系实现的。

很难的一个事情是MPLS网络的设计加部署时间周期，把事情考虑周全了，测试验证做做，写写文档，1-2个月真不算慢的。加上设备到货，安装，没3个月以上是建不起来的。网络的搭建时间过长，这是大家都有体会也很无奈的一件事。从根上说，我理解问题还是协议/配置/设备三者之间的耦合关系过深。

运维阶段

监控，变更和排障是运维阶段的三大任务。

监控

从共性看，拓扑发现及变化，链路延迟，丢包，流量的监控，分析，告警。是两类网络都不可或缺的功能。

从区别看，MPLS网络运维需要监控多种路由协议的状态，因为是全分布式，每个协议在每个接口都可能有Peer，需要对多种状态进行监控或者事后的排障。底层故障对上层协议会造成相关影响，如何管理和屏蔽大量告警事件是挑战。

SDN有一点优势在于能更多的进行白盒监控，即通过对系统内部的性能指标进行监控了解系统的运行状态，因为从南向看，SDN只需要监控少数几种协议，监控相对简单，而面对业务变更更是随时随地API可以满足的。主要复杂度集中在控制平面和业务编排，监控也主要集中在控制平面健壮性，用户业务状况，以及控制和转发的一致性等方面。在大型网络里因底层链路故障导致的大量路径计算和重新优化会需要控制及时反应。面向最终用户的Web接口又会需要对各种请求和配置变更做出实时响应和分析。网络至此更大程度是一个复杂的计算和业务系统。

监控的高级阶段一是关联和联动底层数据，二是对用户数据进行挖掘。从这个层面看，两种网络都还有很长的路要走。

变更

如果说大量的长途故障来自于底层链路，属于推土机挖断光纤惹的祸，那变更产生的人为配置错误是则是故障的另一主要来源。变更的原因很多(软件升级，硬件更换升级，业务部署，结构优化等等)，最终都会落实到调流量，改配置上。

网络部署后随着运维时间推移，各种不同业务需求对网络进行不同的要求后，很难再维护统一的配置模板了。各种临时的，非标的配置需求逐渐在不同设备上 生根发芽，枝繁叶茂。到最后，没有人去敢删除那些可能已经不用的临时配置。那些配置也就半永久的存在不同设备上。传统网络配置长在设备上，各种配置的来龙去脉又只有当事人清楚。时间一长，人，设备，需求的变化会导致配置和实际情况脱节，和现网运维人员脱节。随便说说，哪张网络没有一堆无法说清的Policy，一堆无法删除的ACL。

有一种说法是：当有了netconf+Yang后, 传统CLI被替代，也可以自动化。但实际情况是，不论Yang的推广和落地时间，就算所有厂商设备都通过Netconf接口可下发，但复杂配置的一致性，配置检查及检查后的配置删除回滚以及配置管理仍然是有挑战的任务。 所以配置下发的自动化 不= SDN，归根结底的问题是分布式复杂性过多和物理设备紧耦合造成。

SDN则基本摆脱了设备配置的问题。基础架构数据通过自发现和初始定义可以全部在GUI实现。业务数据通过GUI和API实现，软件升级时，控制平面的前端，后端，业务编排，底层控制器各组件既可以分别升级也可以统一升级。对转发没有明显影响。

排障

MPLS网络排障充分体现了网络的复杂性，对协议，厂商设备，具体配置，网络拓扑，排障工具的理解，运用和分析能力。排障时间对运维和生产网业务是有压力的影响。这反过来也影响网络设计时，有可能倾向于更保守的选择技术和设备。期望减少排障的难度。

SDN的排障更多需要和Devops结合，通过软件化手段解决。复杂永远不会消失，只会转移。传统网工面临的挑战之一就是原有在CLI上的排障手段和思路可能不适用在SDN上，是API还是其他软件工具。需要抱着开放心态，在运维过程中逐步的探索。

优化

网络的优化不是必然存在的，有时候，优化的潜台词是现有网络不能满足新的需求，需要设备部分更新换代才能实现新Feature来满足新的需求。

MPLS Base网络在优化时，前面的设计，部署，运维的麻烦还得重来一次。

SDN网络则基本就是两点

1.控制器集群的Scale-out 随网络规模扩大后的横向扩容

2.网元设备的Scale-out 横向扩容

综上所述，网络的运营想要搞好(故障率低，稳定，满足业务速度快，质量高)，在SDN技术产生前，似乎必然需要一个属于精英俱乐部的网络队伍去完成这些内容。

1.复杂的Design和完备的设备测试

2.强悍的运维，7/24 随时Ready处理复杂故障

3.强大的工具支撑

4.严格复杂的变更体制和专业团队

运营商由于网络规模的原因，可以得到厂商或集成商最优先的支持，同时具有相当完备且聚焦网络运维的工程师团队。这也是为什么多年来最有实力的运营商一直是网络运维的翘楚。但反过来想想，这也是网络需要进步的一个证据，网络需要更简单，更灵活，更快的部署和适应业务，更方便和白盒化的监控性能。

SDN网络则基本在软件框架内解决了按业务所需的路径计算，南向接口的全部自动化，当然，SDN作为一种软件化的理念，必然面临更多软件问题直接影响网络的情况出现，网络部署和运维更多变成软件的部署和运维。所有软件会遇到的头痛问题，SDN都会遇到。

结语

啰里啰嗦说了不少，回头看下，很多是正确的废话。其实这么多年感受下来MPLS网络说到底存在很大的一个问题就是路由协议(路由策略)，设备和配置之间的深耦合

路由协议(路由策略)通过本地配置来实现

配置在不同厂商设备上的实现不尽相同

基于本地配置，内容复杂，多协议等原因，自动化和可编程的难度大，不彻底。

SDN到底应该是如何实现和落地，这一两年已经开始很多实践方面的探索，大的愿景已经有了，但具体的落地和途径其实还是有很多争论的。 是沿着MPLS网络继续发展到SDN，还是从本质问题上更进一步做的更彻底些。还有待时间检验。数据网络已成为数据时代的风火水电，不同范围，不同规模，不同运营者的网络其具体发展技术路径和适用技术不尽相同，每一代网络的产生和占领市场都在其当时特定情况下符合逻辑。也许纯IP网络，MPLS-Based 网络和SDN 三者将长期共存，共同发展。

“未来已来，只是分布不那么平均”，我们可以相信发生在云计算上的事情，一定也会发生在网络上。按需，动态，资源池化，API化，高度自动化和灵活的业务抽象必将成为网络的主要特征。