业务链研究进展及技术展望

黄灿灿++陈华南++伍佑明++朱永庆++龚霞

【摘 要】业务链是SDN/NFV创新业务模式，已成为业界的研究热点，为了探讨如何更好地推进业务链技术的发展，在分析运营商业务承载痛点的基础上，对业务链关键技术及研究进展进行了分析与探讨，并指出业务链未来研究方向，希望能为后续技术研究及应用提供指引。

【关键词】业务链 流分类器 NSH

1 引言

网络能力升级换代的迫切需求给运营商网络带来了极大的挑战。近20年，互联网在业务承载方面基本采用“拓扑敏感型”模式，即通过增强网元功能以支持新业务的功能要求，但大量中间件（MiddleBox）的串接直接导致了网络功能的臃肿，专用设备陷入困境，运营商核心竞争力严重下降，被逐步排挤到产业链边缘。随着移动互联网、云业务及IoT等新型业务的发展，用户有了即时交互式体验需求，要求可按需灵活制定个性化网络，这对网络基础设施提出了很高要求。

SFC（Service Function Chaining，业务链）是面向用户、应用的新型业务模式[1]，是SDN、NFV及云等技术的深度融合解决方案。业务链借助虚拟化技术，将传统网元功能的处理流程进行动态灵活编排，以虚拟形态构建可变的业务处理流，解决了由网络中间件所导致的服务功能无法复用、底层网络拓扑依赖、流量绕转等问题。

业务链架构涉及业务编排器、业务链控制器、流量分类器/转发器及业务链标识等多方面的关键技术，这些技术正处于研究及实验室原型验证阶段，暂无成熟商用可规模应用的解决方案。各大标准及开源组织陆续开展了业务链核心技术研究，各自研究进度不一致，暂无专门组织对各组织的研究成果进行集成和推进。因此，为更好地推进业务链技术的发展，本文拟从标准及开源项目着手，梳理业务链技术研究进展，并研判各技术发展趋势，为后续研究工作提供技术参考及指引。

2 SFC关键技术

SFC技术包括底层虚拟化资源分配、网络业务处理功能定义以及用户业务处理链定义等功能，用于实现网络服务的自动化部署及提供，聚焦基于特定场景的业务链实现，包括基于多租户的业务链、基于城域边缘的业务链以及基于Gi-LAN的业务链等。随着技术的研究深入，业界在业务链架构及业务流程方面已达成一致，具体如图1所示。

业务链主要包括以下关键部件：

SFC编排器：通过intent-based的北向接口将定义SFC需求的能力开放给用户。在收到用户请求后，将用户特征抽象成流分类条目，并将用户的需求翻译成一系列有序的网络功能。另外编排器会通过SF（Service Function，业务功能）instance管理器收集SF type和SF group（用于SF instance负载均衡）的状态并维护相应的目录，选择网络功能（SF group）进行链接，实现SFC的编排。

SFC网络控制器：接受SFC编排器下发的某用户SFC，通过SF Instance管理器收集SF instance状态信息。SFC网络控制器负责选择最优SF instance，形成SFP（Service Function Path，业务链路径），以转发表的形式通过南向接口下发给SFF（Service Function Forwarder，业务功能转发器），指导其进行报文转发，并将流分类条目以及所对应的SFC下发给分流器。

SF Instance管理器：负责SF实例的生命周期的管理。它负责实时跟踪SF类型、SF group的状态及位置并在SFC编排器上进行注册，同时将SF instance的状态和位置在SFC网络控制器上进行注册。

分流器：基于某种策略（例如五元组）对用户的流量进行分类，并根据该分类找到其对应的SFC，将SFC报文头插入到报文中。分流器可以是一个单独的物理实体，也可以集成在SFF中。一条SFC上可以有多个分流器。

策略平台：为SFC编排器提供运营商策略规则。

SFF：负责将数据报文转发至指定的SF实例。通过查看数据报文的SF报文头中的路径ID和服务ID，并结合网络控制器下发的转发表来做转发决策。SFF会维护基于SF专用报文头（例如NSH）的转发表，也会维护普通的L2～L3层转发表（在性能允许的情况下会维护L4～L7层转发表），以满足对不携带SF专用报文头数据报文的转发。

SF：对收到的数据包进行特殊处理的功能模塊。一个SF可以是虚拟网元，也可以是物理网元；多个SF可以在同一管理域存在。多个SF可以共存于同一个物理设备。SF可以是SFC封装感知的，也可以是SFC封装不感知的，如果是封装不感知的，需要经过SF代理网元进行翻译。

3 SFC研究进展

SFC技术自提出以来就成为产业链各方关注重点，成为运营商、云服务提供商、硬件/软件提供商及客户共同努力的目标，寄望于与SDN/NFV及云共同发展。国际各大标准组织配合开源组织对SFC进行了理论体系的构建和产品原型的开发，两者的高效协作促进了SFC标准的快速成型和落地，如表1所示。

3.1 标准组织研究进展

IETF、BBF等标准组织则从SFC场景、部署、运维和管理等方面重点提出需求，并结合开源组织产品进行SFC各场景的POC试验。在理论研究方面IETF是领导者，它定义了SFC的框架、流程、协议以及包格式等，并针对流量优化和运维管理等细节进行了深入研讨。

（1）IETF

IETF是SFC技术的大本营，对SFC的原理、架构、实现机制、优化与运维管理进行了全面而深入的梳理和探讨，为SFC原型化、产品化以及进一步在现网部署提供了理论依据，具有极高的参考价值。但IETF较为关注细节技术问题的解决方案，而对SFC在现网中端到端部署与实施缺少多维度的、宏观到微观的探讨，亟需相关文档的输入。

IETF SFC组已正式发布2个RFC（Request For Commets），对SFC的架构、组件、协议机制、功能、管理、诊断、设计分析以及安全模型等进行了深入研究。在研Draft文稿聚焦在数据中心、移动网、宽带网络、vCPE以及大流量场景的SFC解决方案。IETF主要研究内容聚焦在以下方面：endprint

1）业务链架构研究：层次化SFC架构，其中跨域及层次化转发机制成为研究热点。

2）控制平面技术研究[2]：SFC对控制协议的选择存在较多的争议，暂无统一的解决方案。是使用传统协议的扩展，还是使用全新构建的协议（例如SF instance资源发现协议OSP（Off-path Signaling Protocol，偏离路径签名协议）），需根据SFC部署场景、规模以及产品成熟度来区分斟酌。

3）数据平面技术研究：工作组创新性地提出了NSH（Network Service Header，网络业务头封装）[3]，通过携带SPID（Service Path ID）和SID（Service ID）给SFF提供报文匹配信息。工作组对NSH进行了深入细致的研究，包括NSH TLV、NSH服务转发流程、NSH radius属性定义、NSH的DHCP属性、基于UDP的NSH、基于IPv6扩展的NSH等，已成为SFC转发面协议的主流事实标准。在应用中，分类器维护NSH映射表，通过匹配SPID和SID，大大提高了SFF的效率，解决了传统的SF需要匹配五元组或者其他参数来识别特征流量、在参数组合繁多的情况下SF的映射表庞大等问题。另外NSH还可通过携带metadata，灵活地传递更加个性化的报文处理指令以及运行维护参数。同时，工作组还关注通过LISP/PCEP/BGP LS/IPv6等扩展报文头来携带SFC信息的补充方案，为现有网络升级提供技术参考。

4）流量/路径优化场景研究：SFC各组件的多种部署方式使得它存在流量绕转和路径繁杂等潜在问题。SFC流量存在从SFF转发至SF再返回SFF的迂回过程，直接导致了带宽的浪费和时延抖动的增加。针对该问题，工作组提出SF旁路和SF流量卸载两种解决方案。SFC流量卸载将SF不感兴趣的流量通过指令的方式卸载到SFF进行处理，该方案的讨论在群组中较为活跃。另外较为受关注的还有基于策略的路径优化、负载均衡问题分析、SFC动态路径选择等，这些优化方案着重于方法论和流程的阐述，但缺少基于具体网络业务场景的应用介绍。

（2）BBF

BBF是运营商主导的标准组织，较为关注应用场景和案例，对运营出现的问题一般聚焦于需求以及解决方案框架，而具体技术多数会通过通告的方式引用IETF的成果，也因此受制于IETF SFC组的进度。BBF从运营商的角度出发，针对不同的应用场景以及相应的不同解决方案，全方位地给出对比与选择建议，为指导运营商部署SFC给出了可行的建议。

研究项目SD326[4]针对FSC（Flexible Service Chaining，柔性业务链）的市场需求及应用场景进行研究，并构建了“灵活业务链网络架构”。TR-178所定义的层次化BNG被SD326视为SFC在城域网边缘的业务链应用场景，并在此基础上扩展出了6种应用模式，包括CGNAT以及Web Filtering、接入以及父母控制、DPI和Lawful Intercept、DPI和URL过滤、主机安全以及严格SLA、物理以及虚拟网络下的业务链弹性冗余等场景。针对运营商部署需求，BBF重点关注以下3个方面的研究内容：

1）复杂业务链相关问题包括开环和闭环业务链、动态业务链部署、路径动态变更、对称和非对称转发、跨CO/POP/DC的业务链、跨运营商业务链以及虚拟迁移场景下的接口地址移动等。

2）运营级业务链相关问题包括基于session/用户业务链的QoS部署与保障、基于带宽/时延/OAM等因素的业务链SLA制定。

3）跨域场景下的自动配置包括用户感知的session认证和计费、动态负载均衡和高可靠性、按需的灵活带宽配给。

（3）ETSI

ETSI（欧洲电联）是欧洲运营商和设备商主导的标准组织，是NFV的制定者及主导者，提出采用NFVFG方式实现NFV环境下的业务链，且组织产业链进行相应场景试点，为运营商部署提供技术参考。NFVFG架构如图2所示：

ETSI对业务链研究比较零散，分布在各个研究文档中。其中GS NFV 001提出NFVFG的应用案例[5]，如图2所示，重点关注NFVFG框架及实现方式、虚拟化功能与物理实体之间映射、虚拟化功能与专用設备之间的协同等方面，运营商可按照全网络业务功能处理性能情况灵活在网络任意位置进行业务功能部署。GS NFV-EVE 005关注SFC、SDN及NFV之间的实现关系[6]，基于IETF SFC架构探讨SDN控制器引入方式，以及在NFVI环境下SDN控制器及SFC实现场景，提出运营商多租户实现方案及跨NFVI实现模型。GS NFV-MAN 001对NFVFG的信息单元进行规范[7]，制定vnffgd和vnffgr的元数据内容（metadata），为NFVFG应用提供基础信息模型。

（4）ITU-T

ITU-T（国际电信联盟-电信标准局）是国际电信联盟管理下专门制定电信标准的分支机构，主要关注业务链在网络中的部署模型、各个实体之间的协议交互以及端到端测试方法论。其中，ITU-T Y-series Recommendations–Supplement 41研究了业务链部署架构及功能要求[8]，并提出线性、递归和分支等3种业务链部署模式，同时深入研究直接和间接互联场景下业务路径选择策略。ITU-T Y.3512[9]从云计算NaaS角度切入，提出实现业务链的必要条件，包括业务链应用的要求、NaaS对多租户业务链的安全隔离要求等。在研项目Q.SCO聚焦在端局场景下业务链实现的信令需求，追求更加容易地实现多个系统间的交互，提升部署灵活性。

3.2 开源组织研究进展

开源组织通过原型开发直接对理论进行验证，为新技术产品化落地提供共享的第一手材料，近年来得到了极大的发展。Opendaylight主要聚焦于SFC控制面和转发面的协同和实践；Openstack主要关注SFC对底层虚拟化资源分配；而OPNFV则关注自顶向下地构建端到端SFC开发平台。endprint

（1）Opendaylight

Opendaylight从Helium版本开始支持SFC，其SFC部署架构如图3所示，通过嵌入SFC数据库并结合南向接口进行SFC业务的下发与部署。基于不同的应用场景采用不同的南向接口：

REST Plug-in接口用于从SFC数据库下发配置（包括ACL、分类器、SF及其群组、SFST（Service Function Schedule Type，服务功能调度类型）、SFF以及RSP（Rendered Service Path，提供服务的路径））到支持REST API的网络设备上。

OVSDB接口用于在支持OVSDB的OVS（Open Virtual Switch）上创建SFC组件。控制器部署SFC-OVS功能，将SFC数据库信息映射成OVS（支持OVSDB接口）可识别的组件信息（例如：Bridge/Termination port等），并通过OVSDB MD-SAL接口下发，从而实现OVS的SFC组件功能创建。

Openflow南向接口用于将控制器SFC数据库中的ACL映射成Openflow规则，并通过Openflow南向接口下发到OVS，使其可以通过Openflow规则来对SFC路径进行选择和转发。

ODL SFC架构如图3所示：

为提升业务链集成的便利性，ODL加大对SFC研究投入，主要研究内容如下：

1）整合ODL GBP（Group Based Policy，基于组的策略）的研究成果，利用GBP意向性语言、统一映射模型以及统一的接口自动化地将用户意图映射到底层网络，解决了理解应用需求的开发者和基础设施团队之间的脱节问题。

2）增强SFC分类器对NSH封装的支持能力，通过Openflow扩展支持NSH，实现基于MAC地址、端口、协议（TCP、UDP和SCTP）以及IPv4/IPv6的流量分类。

3）深入研究业务路径选择算法，未来将支持随机（Random）、轮询（Round Robin）、负载均衡（Load Balancing）与最短路径（Shortest Path）4种算法。同时通过SF group实现SF负载均衡，使用YANG模型描述SF以及LISP等功能。

4）研究OVS转发插件（SFC Openflow Renderer）监听与控制SFC转发流程，对SFC路径所对应的SFF进行编程，通过Pipeline模式将报文牵引至相应的SFC路径。

（2）ONF

ONF（Open Networking Foundation，开放网络基金会）致力于SDN的发展和标准化，在业务链方面的工作主要聚焦于业务链场景下Openflow协议的扩展和开发。ONF TS-027[10]基于IETF理论基础，提出了ONF SFC架构，重点研究SFC信息模型以及各个模块之间的接口；基于Openflow协议探讨L2-L7流量分类扩展，提出Openflow对NSH的扩展实现，包括Match字段新增OXM_OF_SFCH_PATH_ID和OXM_OF_SFCH_PATH_INDEX支持，并在分类器、转发器及业务功能对新字段支持及动作实现方面进行了详细的深入研究。同时，ONF TS-027提供SDN实现L2传输层业务链的案例和代码，关注并分析了L5～L7层的业务链实现所面临的问题，为业务链部署提供了技术参考。

（3）OpenStack

OpenStack是一个开源的云计算管理平台项目，项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。OpenStack已被业界认可为VIM的代表，SFC方面的研究成果在OPNFV的POC项目中得以应用。

OpenStack从网络编排和配置部署两个方面针对SFC进行了相关功能的支持和升级：在网络编排方面，OpenStack通过在TAKCER中内置SFC API，并与NFVO/VNFM联动来完成SFC的编排与SF生命周期的管理；在配置部署方面，Neutron项目设置业务嵌入及建链研究组（Service Insertion And Chaining）负责研究SFC底层驱动，以先实现自动化配置下发。现阶段Neutron已實现了与ODL GBP的整合，并计划在下一个研究周期引入NFP（Network Function Plug-in，网络功能插件）能力。

（4）OPNFV

OPNFV在基于自身架构的基础上，结合Openday-light、Openstack以及OVS所推出的开源组件构建自顶向下的端到端SFC开发平台，目前已经发布了Brahmaputra[11]和Colorado版本，但其版本更新较大程度上取决于其他组织版本的更新速度。

OPNFV SFC业务部署架构如图4所示，研究工作聚焦在网络编排、VNF管理以及业务下发等方面。网络编排和VNF管理在Brahmaputra版本中使用TACKER，可集成任何第三方的开源VNF Manager管理工具，并支持三种业务配置下发模式，以满足不同部署场景下的需求：

1）在TAKCER中集成ODL SFC驱动，直接实现SFC下发。ODL SFC驱动通过ODL控制器中的OVSDB向OVS下发配置，通过netconfig/yang向VNF下发配置。

2）在TAKER中集成Neutron SFC驱动，并在Neutron中集成OVS驱动，直接实现SFC下发。

3）在TAKER中集成Neutron SFC驱动，并在Neutron中集成ODL SFC驱动，间接实现SFC下发。

除了支持以上开源组织发布版本外，OPNFV还从运营商的角度考虑SFC端到端部署和维护等方面，包括SF生命周期管理、分类器设置（如匹配颗粒度、隧道起点、服务路径起点、Metadata使用方式）和服务路径转发等方向。在下一个研究周期，OPNFV将开展与OPEN-O和OpenStack Gluon的合作。endprint

4 业务链技术展望

业务链被誉为SDN/NFV的一颗明珠，自提出而来，成为产业界研究的热点。虽然标准组织及开源组织开展了一系列的技术研究及原型系统开发，但整体整合能力较弱，各自实现中嵌入了很多替代技术，成熟通用可推广的产品暂未面市，未来还需继续深化以下方面的研究：

（1）SFC体系架构的深化

SFC编排器、网络控制器、SF管理等功能界定并没有标准化，各个功能實体之间的协议制定和实现也仅仅停留在需求阶段。开源组织更多的是按照各自的思路进行实践，力图在短时间内勘定事实标准，但实际上并不利于运营商SFC体系架构的实现、功能实体的互通以及统一部署。

现有的传统标准组织在业务链场景与具体端到端解决方案的映射方面存在缺口，开源组织存在业务链具体实现的联合协同问题。由于NSH报文头格式的引入，新旧业务功能实体之间出现互通问题。Metadata在各个不同业务中的使用和携带方式没有统一的标准，阻碍业务端到端实现以及OAM的实时监测。SFC多种组合和部署模式导致流量优化的复杂性，对SF/SFP负载均衡、路径优化、低时延节能等方面需求更多，需要得到重点关注。

（2）SFC运维管理有待完善

SFC运维管理研究刚提上议程，包括SFC时延、抖动、丢包测量方法、性能测试架构、NSH KPI、OAM机制、多层OAM协同机制、NSH时间戳、trace问题、OAM的YANG模型、SFC可靠性、故障管理、冗余机制等方面的解决方案，目前还需持续加大研究力度。

（3）SFC产业链有待重塑

以软件为核心的SFC发展促进传统产业链的重新洗牌，但目前缺乏丰富的SF市场，市面上已有的VNF产品都是各提供商的私有产品，发展速度落后于市场需求，产业界应推动公共服务模块的开源，加速技术发展。此外，运营商急迫需要SFC实现面向用户的业务灵活提供，但受限于业务模式拓展，当前可应用范围有限。

5 结束语

本文介绍了业务链基本架构和功能组件，同时对业界各标准和开源组织的业务链技术研究进展进行了总结和分析，在此基础上，探讨了业务链技术演进趋势及后续重点研究方向。综合来看，业务链将带来互联网产业的新爆发点，已得到各方的认可及投入，市场前景潜力巨大。随着SDN/NFV技术的发展和引入，如果按照传统的运营模式对虚拟化系统进行技术要求，在很大程度上将限制新技术的应用与推广，在新IP领域，DevOps将会成为智慧运营的核心。运营商应结合自身业务发展，对业务流程进行重构，以实现逐个攻破的模式，开展嵌入式研发，快速推动业务链各项技术的研发与应用，在实现业务增长的同时带动整个产业链的发展。

参考文献：

[1] E J Halpern， E C Pignataro. Service Function Chaining （SFC） Architecture[EB/OL]. [2017-04-14]. https：//www.rfc-editor.org/rfc/pdfrfc/rfc7665.txt.

[2] M Boucadair. Service Function Chaining （SFC） Control Plane Components & Requirements[EB/OL]. [2017-04-14]. https：//datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/.

[3] P Quinn， U Elzur. Network Service Header[EB/OL]. [2017-04-14]. https：//datatracker.ietf.org/doc/draft-ietf-sfc-nsh/？include_text=1.

[4] Broadband Forum SD326. Flexible Service Chaining[EB/OL]. [2017-04-14]. http：//www.broadband-forum.org/.

[5] GS NFV 001. Network Functions Virtualisation Use Case[EB/OL]. [2017-04-14]. http：//www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf.

[6] GS NFV-EVE 005. Report on SDN Usage in NFV Architectural Framework[EB/OL]. [2017-04-14]. http：//cn.bing.com/search？q=GS+NFV-EVE+005&go=%E6%90%9C%E7%B4%A2&qs=n&form=QBRE&sp=-1&pq=gs+nfv-eve+005&sc=0-14&sk=&cvid=A46015047C674DA5B8A3502F50ADB3C5.

[7] GS NFV-MAN 001. Network Functions Virtualisation Mana-gement and Orchestration[EB/OL]. [2017-04-14]. http：//www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/

01.01.01_60/gs_NFV-MAN001v010101p.pdf.

[8] ITU-T Y-series Recommendations–Supplement 41. Deployment models of service function chaining[EB/OL]. [2017-04-14]. http：//www.itu.int/dms_pubrec/itu-t/rec/y/T-REC-Y.Sup41-201607-I！！SUM-HTM-E.htm.

[9] ITU-T Y 3512. Cloud computing–Functional requirements of Network as a Service[EB/OL]. [2017-04-14]. http：//www.itu.int/rec/T-REC-Y.3512/en.

[10] ONF TS-027. L4-L7 Service Function Chaining Solution Architecture[EB/OL]. [2017-04-14]. https：//www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/L4-L7_Service_Function_Chaining_Solution_Architecture.pdf.

[11] Brady Johnson. OPNFV SFC Brahmaputra Release Planning[EB/OL]. [2017-04-14]. https：//wiki.opnfv.org/display/SWREL/Releases+Brahmaputra+Release+Plan. ★endprint