小编之前从其他网站上转载了一篇《SDN和NFV都已out:现在要讲LSO了》，有小伙伴给我们投稿表示对这个观点有些看法，如果你对LSO也有看法，欢迎向我们投稿。
从SDN诞生伊始围绕它的各种撕B就从来没有停止过，从最初的定义之争到标准之争（南向、北向、东西向）到与NFV争论再到应用场景之争（从接入网、传输网、城域网、核心网、数据中心等再到移动网）本以为该消停一会了。可是2015年初上演的思科和惠普的“泰坦之战”却揭开SDN的撕B大战。
对于这些撕B我一直都是乐见其争，毕竟撕撕更健康，这些撕B大战对于未来网络核心技术的落地还是都大有裨益的。对于个人而言我其实更喜欢安安静静的做个研究网络先进技术的美男子，从来没考虑过自己也会参与到这场撕B大战中，直到“SDNLAB君”转了“网界网”的《SDN和NFV都已out:现在要讲LSO了》。
好了废话不多说开撕吧！
对于LSO（Lifecycle Service Orchestration）我们都不陌生，它是MEF在实施第三张网的愿景中提出的，它的目标是敏捷地部署动态服务，提高新型企业网络服务的交付速度，要从数周或数月时间缩短到数分钟。它所包含的范畴涵盖了电信服务或其他通信服务的所有活动。一个LSO平台能够处理从客户订单到服务交付的控制，从数据采集到确保性能等级，从故障修复到提供使用报告，再到为客户提供各种分析报告等等的一切业务。
首先，我非常同意LSO的愿景是相当吸引人的。随着网络的发展与变革，服务提供商深刻的认识到当前的运营支撑系统的局限性，因此他们迫切需要全新OSS/BSS，并希望它能够集成基于开放和互操作标准的业务流程、实施、控制、性能、保障、使用、分析、安全，以及企业网络服务策略于一身。更重要的是，它能实际解决越来越挑剔的用户对于越来越复杂、越来越难以定义、越来越难以配置、越来越难以交付的网络服务的担忧，这些服务不再只是纯粹的带宽问题或其他连接性问题，如时延、服务保障、收费成本等。
但是，我认为LSO更像是自动化的服务编排系统，它的目标是替代传统的OSS/BSS；它提出了新的网络管理需求，使得以SDN、NFV等为代表的未来网络技术有了更明确的落地方向。我的理由如下：
缺乏技术支撑LSO何以落地？
首先，LSO除了提出了自动的、快速的资源调配以实现网络按需而动的理念，还定义了六个高级别功能：实施、控制、性能、保障、使用和分析。我们可以把这六点理解为六个维度的核心目标，但是缺乏相应的技术规范、技术实现。读者可通过MEF的LSO主页看到这些功能的详尽描述：http://www.metroethernetforum.org/third-network/lifecycle-service-orchestration
其次，第三张网的核心愿景是：利用网络即服务(NaaS)原则，通过研发一种逐个域或逐层的方式来分解复杂的问题。除了LSO它还包含开放API、协议无关的NaaS信息模式以及在物理和虚拟服务端点之间的服务定义等等。要实现这些就一定离开不了SDN、NFV等技术的支持。
NVF、SDN和LSO不是你死我活而是各司其职
首先，任何的技术都不是孤立的，任何的问题域也不是一维的（这就是多维撕B），一般我们从以下三个维度来思考网络问题：
同理，在MEF推行的第三类网络愿景中，最为重要的一个概念就是为网络进行分层，一层一层地去解决复杂的网络问题。而在这个分层理念中SDN、NVF和LSO各司其职。NFV允许为每一个网络功能使用通用的虚拟机，而不是使用厂商特定的网络元素。SDN将网络元素中的控制功能移至中央控制器中。无论是NFV或是SDN，当他们提供第三类网络的基本构建模块时，所关心的是网络元素功能和控制，而不关心企业或个人实际购买的连接服务。这是MEF的标准化服务编排能效力的地方。服务编排管理着连接服务的整个生命周期：履行、控制、性能、保证、使用和分析。它拥有一层或一个域的所有服务的详细清单，为服务提供商和在其他层操作的内部系统之间的信息交换提供必要的API。
其次，业务编排、生命周期管理我们并不陌生。熟悉SDN、NFV、云计算等技术中的任何一个的小伙伴一定知道这些概念早已被提出甚至已经被实现。甚至可以说LSO就是IAAS云平台在网络管理上的概念抽象，其实IAAS云早就开始做类似的事情了，只是人家低调没说而已。
云化=硬件资源池+业务统一编排+功能软件化
SDN、NFV也早在2013年就把Orchestration纳入其版图了，下面就让我们好好来回顾一下SDN、NFV的历史吧：
SDN的历史可以浓缩为几个阶段的撕B大战：
第一阶段：接口/协议标准化之争
争论点在于统一的必要性。目前形成的业界共识：
- ONF强调Driver，对于南向接口不再局限于Openflow
- 北向接口以Restful接口为主，主要从网络资源管理角度进行抽象/封装
- SDN实现上，不同厂商各成体系
第二阶段：抢占制高点，SDN控制器之争
SDN控制器实现方式多样化
SDN控制器出现多元化发展趋势，甚至出现不同功能的细分：
第三阶段：武器比拼，性能之战
现有ASIC芯片架构无法满足SDN对性能的需求，基于SDN的专用芯片架构及实现方案还有待完善。
SDN组网关键指标：流表容量、流表学习速度、流表转发速率、转发延时等。不同厂商的设备差异极大，比如流表学习速度从2秒/千条到20秒/千条。
第四阶段：窃听风云，安全性问题
SDN的集中控制方式及开放性使得控制器的安全性成为潜在风险，需要建立一套隔离、防护、备份机制来确保其安全稳定运行。
- 控制器本身的安全问题
健壮性、单点故障、防攻击、扩展性、冗余性
- 控制器和应用层的安全性问题
1、授权及认证问题：身份角色认证、访问权限控制、安全操作日志
2、安全隔离问题：不同应用之间的安全隔离，虚拟化之后的网络隔离问题
- 控制器和转发设备之间的安全问题
1、数据通道安全问题：加密如SSL等
2、访问上控制一致性问题：多控制器之间的授权、转发设备资源的细粒度划分、访问等级分配等。
第五阶段：地盘抢夺，SDN应用场景之争
传统网络设备厂商感受到危机，向网络软件厂商、网络解决方案提供商转型。结合SDN发展趋势，众厂商纷纷选择云数据中心网络为第一主战场，并以极快的速度向广域网、城域网、接入网、驻地网等方向蔓延。
第六阶段：结盟之战，互操作性
第一阶段集中在协议SDN相关标准还有待完善，各厂商支持程度也有差异，实现互操作有相当难度。
第二阶段集中在方案融合Orchestration浮出水面：迄今为止，运营商和厂商都将关注点放在SDN和NFV上，几乎没有考虑到他们如何被运营这个问题。SDN和NFV具有破坏力的原因很大一部分在于他们挑战了现有的网络管理和系统。他们改变了OSS（运营支撑系统）和网络之间的界限，SDN/NFV提出了全新的网络资源编排要求。
NFV2013年才开始提出它的历史相对而言就没有那么波澜壮阔：
NFV出生：ETSI发布NFV系列文档，提出NFV通用架构
- ETSI NFV ISG于2013年底完成并发布了多个文稿，包括 NFV architecture、Use Case、Virtualization requirement、Terminology以及一些列的PoC文档，并更新发布了NFV白皮书2.0
- ETSI NFV ISG目前在制定的其他文稿，关注的主要问题包括：编排、管理、接口、可移植性、性能、安全、接口及Hypervisor等。
- ETSI提出的通用NFV网络架构
NFV挑战一：可靠性问题
NFV挑战二：数据存储转发性能问题
NFV挑战三：业务部署方式问题
NFV挑战四：虚拟化架构中的标准问题：
NFV进展，设备厂商进度不一
NFV的战火从Vodafone开始。
NFV成为传统网络设备厂商演进的方向，核心网虚拟化是目前NFV的关注点，但不同设备厂商成熟度有差异：
基于以上论断可以看出Orchestration将会变得越来越重要。事实也如此：
ONF开始关注运营商级SDN需求
ONF成立Carrier-grade SDN讨论组，在原有架构基础上新增了运营商级需求。
Orchestration在网络中的关键地位成为共识
- Orchestration/Orchestrator在云化网络中实现了业务的组织、编排、协同、部署等重要功能
- ETSI NFV、IETF、MEF等国际标准组织将Orchestration作为云化网络架构中的关键层次，ONF也在考虑引入Orchestration功能。
- 互联网运营商和电信运营商都充分关注和推进Orchestator的研发；设备厂商（Cisco、IBM）已经开始在设备中提供Orchestration功能。
MEF（城域以太网论坛）将Orchestration纳入其战略发展规划
明确将NaaS作为Vision，并将Service Orchestration作为其战略规划。由此可见LSO的提出除了网络管理需求还有深厚的技术背景。
最后，“软件化”成为广义SDN核心内涵。广义SDN以满足网络服务需求为目标，使用户/应用能够通过软件接口充分享有网络的能力，进而通过软件编程控制网络行为。《SDN和NFV都已out:现在要讲LSO了》咱们还约吗？
- 南向接口不局限于Openflow，众多已有对的成熟协议获得新的发展空间
- 厂商开放硬件网络设备软件编程API，支持网络能力的灵活交付。
- 通过引入软件技术简化网络部署，实现运维自动化，支持网络业务创新。
作者：李蓬波
该篇文章观点不代表本站观点或立场。