电信运营商NFV未来网络管理体系演进关键问题

2017-05-22 07:03月球肖子玉吴丽华沈蕾
电信科学 2017年4期
关键词:网元网管虚拟化

月球,肖子玉,吴丽华,沈蕾

(中国移动通信集团设计院有限公司,北京 100080)

电信运营商NFV未来网络管理体系演进关键问题

月球,肖子玉,吴丽华,沈蕾

(中国移动通信集团设计院有限公司,北京 100080)

网络功能虚拟化(NFV)是电信级业务云化的核心技术和架构,是未来网络演进的必然趋势。NFV给通信网络带来了新的能力,同时也要求对现有的设备运行、管理、维护和配置模型增加新的管理和编排(MANO)功能。首先对物理网元的网管体系架构及未来演进规划进行总结研究,然后对NFV的引入对现网设备管理方式的变化及新网管架构功能进行总结,深入研究NFV MANO与运营支撑系统(OSS)协同关系、MANO与其他周边网元组网方案等关键问题,最后从电信运营商角度,基于 NFV MANO解耦程度,提出MANO部署及演进策略。

网络功能虚拟化;管理和编排;运营支撑系统;协同;部署及演进策略

1 引言

网络功能虚拟化(network function virtualization,NFV)技术将IT技术运用到CT领域,其诞生解决了电信运营商网络演进的痛点,是未来网络 ICT演进的必然趋势。而管理和编排(management and orchestration,MANO)作为电信网元云化后新增的网管系统,则具有至关重要的作用。

本文从电信运营商视角,全面深入分析了NFV引入后云化网络管理的需求、架构、功能及接口等关键问题,并基于NFV MANO接口解耦程度,分析探讨了MANO部署演进策略,可作为电信运营商在现网NFV部署时的重要参考。

2 现有网元的网管体系架构

为维持通信网络在安全的管控下稳定运行,网络需要有合理的管控手段。NFV已经成为电信运营商网络的演进方向之一,在虚拟化网络完全商用之前,电信网络仍由纯物理网元构成。网管架构逻辑上可分为网络管理层、网元管理层和网元层,如图1所示。根据OSI定义,物理网元的网管从功能上划分为五大功能域(FCAPS):故障管理(fault management)、配置管理(configuration management)、计费管理(accounting management)、性能管理(performance management)和安全管理(security management)。物理网元的网管从架构上按照专业功能划分,分别由话务网管、数据网管、传输网管等网管系统纳管。

图1 网管逻辑架构

电信运营商在从面向网络运营向面向业务运营转变的过程中,网管架构也逐渐由按专业划分、多网管系统并存演进至面向业务和网络管理的“资源管理系统、故障管理系统、性能管理系统、优化管理系统”+面向流程管理的“运维管理系统”的综合网管体系。

现有网元的网管架构体系在演进过程中,由于规划不够细致,导致专业网管向综合网管演进的落地仍然存在诸多问题:一线运维仍然离不开专业网管及EMS、OMC,能力开放不足导致系统封闭、功能重复开发;同时,网络、业务、技术发展趋势也为网管能力带来新的挑战。

3 未来网络网管新需求

NFV是电信级业务云化的核心技术和架构,是未来网络演进的必然趋势。NFV给通信网络带来了新的能力,同时也要求对现有的运行、管理、维护和配置模型增加新的MANO功能。

NFV的到来,带来网络形态的巨大变化,传统网管的FCAPS难以满足需求,主要体现在以下几个方面。

(1)从软/硬件一体化到软件的变化

传统电信网元为软/硬件一体化的设计,运营商主要关注硬件本身的运行情况,对其内部的软件运行情况,由于其为私有软件,难以洞察其内部运行机理。而在软/硬件分离的背景下,软件部署在通用x86服务器上,其运行环境主要为Linux等通用操作系统,运营商必须同时关注其软件运行情况。

(2)由静态到动态变化

传统电信网络主要为静态的规划、建设、运行。设备交维后,网络容量、网络拓扑基本上维持不变,但发生故障的网元必须更换,面对业务低谷高峰,资源被浪费或者必须被扩容;虚拟化让网络具备动态分配、弹性伸缩的功能特性,当网络发生故障时,能够具备自愈功能。同时面对业务低谷高峰,自动从资源池中新增或者减配各类资源。

图2 未来网络网管新增功能

(3)网管与网元逐步一体化演变

传统网元承担承载、控制及业务功能,网管主要行使网元的管理职能,此外,网管与网元之间无其他交互;而网络虚拟化后,网元控制功能与管理功能更加密不可分,实时性要求提升,基于策略的智能分析、控制要求提升。

由此可见,现有网络管理系统已经不能适应未来网络的新变化,因此应建立相应的新网管架构,未来网管应具有新增“设计”“编排”“控制”功能,同时新增系统间的“能力开放”,实现系统自动化管理。未来网络网管新增功能如图2所示。

在此背景下,ETSI定义了NFV体系架构及MANO功能要求,如图3所示。与传统电信核心网管理相比,NFV 云化网络新增云管系统(MANO)增加了对硬件资源、虚拟资源层、虚拟化网元以及完整网络功能的管理和调度。实现核心网云管理的网元功能包括虚拟化基础设施管理(virtual infrastructure management,VIM)、虚拟网元功能管理(virtual network function management,VNFM)和 NFV编排器(NFV orchestrator,NFVO)。其主要功能介绍如下。

· VIM:主要负责基础设施层硬件资源、虚拟化资源的管理、监控和故障上报。

· VNFM:根据OMC的请求,向VIM申请/释放虚拟机资源,并在虚拟机上加载/卸载虚拟功能网元软件。

· NFVO:负责跨VIM的虚拟资源申请、授权、调度,并负责虚拟资源池的状态监控。

其中,运营支撑系统(operation support system,OSS)同时具备物理网络和虚拟网络全网的管理功能,因此需重点关注与 NFVO的协同功能。

4 MANO与OSS的协同工作

图3 NFV 体系架构及MANO功能要求

NFV云化使得其对网元的管理被分为虚拟网元功能管理和云化资源管理两部分,为实现未来对虚拟网络的端到端管理,以实现以下目标:短期内实现对网元/网络服务的配置、故障、性能管理以及对网元/网络服务的生命周期管理;中后期最大化网络虚拟化的业务价值(如业务编排),通过MANO和其他管理系统协作(如 OSS、BSS),以实现敏捷开通、业务智能编排、智能运维等功能。

在NFV MANO功能及架构部署时,尽可能地降低传统网管的改造工作量,网络维护团队分别在两套系统上完成PNF(物理网元)和VNF(虚拟网元)的运维管理。考虑当前NFV MANO与OSS对接标准尚未完全确定,NFV建设时 NFV MANO与OSS应在不同阶段针对性地探讨协同关系,如图4所示。

图4 MANO与OSS协同关系

建议在MANO部署时,采用如下协同方案:现有网管OSS侧重网元FCAPS的管理,NFV的重点在于管理和编排(资源动态管理、VNF的编排)以及VNF生命周期管理;新建网管MANO NFVO+(即新建 NFVO网元,要求其具备部分OSS功能)主要管理NFV网络,传统OSS管理传统PNF网络。

新建虚拟化网元由新增的 vEMS管理,要将PNF和VNF的信息分别送给传统的OSS和新的网络管理系统——NFVO+网元;设备管理(EMS)通过私有接口或者内部接口实现传统PNF的业务层面网管功能,具体包括故障、配置、计费、性能和安全(FCAPS),此功能网元通常由PNF厂商提供。EMS和MANO NFVO+通过开放接口同时接入OSS,以实现业务信息与资源信息的汇聚和映射,并完成传统网络与NFV网络的统一管理运营。

新网管 NFVO+将虚拟网元监控数据上报给传统OSS,由OSS做资源/告警等的统一展示,传统OSS不直接管理NFV网络。考虑未来VNF与PNF混合组pool的需求,vEMS应能对现网同类型、同厂商的PNF和新建的VNF进行统筹管理。

NFVO+和各省的 OSS网管系统中的性能管理系统进行对接,如图5所示。性能数据和资源数据接口均采用SFTP或者FTP,数据采集周期和EMS侧的数据采集周期保持一致。

5 MANO与周边网元的关系

由于方案中 NFVO+和各省的性能管理系统而非话务网管进行对接,同时参考某运营商现网整体性能管理体系,因此新增NFVO+网元还应具备如下与周边网元的接口,如图6所示,以实现对虚拟网元性能管理功能和数据上报。

图5 NFVO+与OSS接口

图6 运营商性能管理系统架构

其中,性能管理系统由NFVO+实现,需具备4类接口。

接口 1−部省接口:总部(一干节点)与省级系统(二干节点)的数据传送方式分两种:第一种方式是通过省级性能管理系统的数据共享服务向总部传送数据;第二种方式是总部通过访问省级性能管理系统的数据共享服务订阅数据。

接口 2−数据采集接口:实现总部性能管理系统从集中统建系统或一干系统中采集获取相关数据。

接口3−数据共享接口:总部性能管理系统需具备向外部系统(如经营分析系统)实现数据共享的能力。

接口4−功能接口:主要包括总部性能管理系统与EOMS系统的工单接口、4A类接口、信息推送接口等。

6 运营商MANO部署演进策略

目前NFV MANO接口仍处在标准化进程中,电信运营商在部署NFV架构时,可根据接口开放程度,按策略引入NFV MANO。

(1)电信运营商NFV部署初期,NFV实现软/硬件接口解耦

电信运营商NFV部署初期,NFV MANO引入策略如图7所示。

图7 NFV MANO引入策略—初期

NFV实现软/硬件解耦的接口打开需求如图8所示。

图8 NFV解耦接口打开需求

Or-Vnfm:实现 NFVO管理不同厂商的VNFM。

Or-Vi:实现NFVO管理不同厂商的资源池。

Nf-Vi(硬件):实现 VIM管理不同厂商的硬件。

软/硬件解耦情况下,运营商 MANO各网元建议按如下策略部署。

· 省公司全省设置一套 NFVO+。省级NFVO+同时连接多厂商VNFM、VIM、虚拟网元vEMS。

· VNFM按厂商设置,省内每厂商一套,管理同厂商多种VNF,VNFM连接同厂商多个VIM;建设虚拟化vEMS管理虚拟化网元。VNF与PNF混合组pool时,由同一套vEMS管理。

· VIM支持管理多厂商硬件,初期单套VIM支持管理100~200台主机,按管理主机的数量设置VIM,VIM所管理的资源仅部署同厂商的VNF。

· 同一DC内,多个VIM所管理的物理服务器、存储资源独立,多个VIM所管理的资源可以共用组网设备。

(2)电信运营商NFV部署中后期,NFV实现三层解耦

电信运营商NFV部署中后期,NFV MANO引入策略如图9所示。

图9 NFV-MANO引入策略—中后期

虚拟网络功能层、虚拟资源层、硬件层三层解耦需要打开的接口如图8所示。Vi-Vnfm:实现不同VNF厂商之间资源共享。厂商集成接口:Os-Ma-nfvo(可根据未来网管架构和具体维护需求进行集成开发)。

NFV部署中后期,NFV实现三层解耦,可对网络进行升级及开放部署。

· NFVO+部署方式维持不变。

· VNFM按厂商设置,运营商省内每厂商一套,管理同厂商多种VNF,同时,VNFM支持连接异厂商VIM。

· VIM支持对多厂商进行硬件管理,VIM所管理的资源支持部署多厂商VNF。

· NFV中后期根据实际需求选择是否跨 DC部署VNF,不受同厂商VIM资源限制。

7 结束语

随着网络形态的改变,电信网管存在向新网管架构演进的需求。从网管架构的演进及新网管的功能架构等相关方面,探讨NFV网管系统及未来网络建设中的关键问题。随着MANO接口的进一步研究及业界对NFV定位的逐渐清晰,人们已经清楚地看到NFV脚步的临近,但具体如何应对未来云化网络后网管需求的变化,仍是电信运营商在NFV大规模部署前需要解决的重要问题。

[1] ETSI. Network functions virtualisation whitepaper#3[EB/OL]. (2014−11−20)[2016−06−29]. http//portal.etsi.org/Portals/0/ TBpages/NFV/Docs/NFV_White_Paper3.pdf.

[2] ETSI. Network functions virtualization (NFV); use cases: ETSI GS NFV 001[S/OL]. (2013−10−01)[2016−06−29]. http://www.etsi. org/deiver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v 010101p.pdf.

[3] ETSI. Network functions virtualisation (NFV); architectural framework: ETSI GS NFV 002[S/OL]. (2013−10−01)[2016−06−29]. http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_ 60/gs_NFV002v010101p.pdf.

[4] ETSI. Network functions virtualisation (NFV); terminology for main concepts in NFV: ETSI GS NFV 003[S/OL]. (2013−10−01) [2016−06−29]. http://www.etsi.org/deliver/etsi_gs/NFV- INF/001_ 099 /003/01.01.01_60gs_NFV-INF003v010101p.pdf.

[5] ETSI. Network functions virtualisation (NFV); management and orchestration: ETSI GS NFV MAN 001[S/OL]. (2014−12−01)[2016−06−29]. http://www.etsi.org/deliver/etsi_gs/ NFV-MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v 010101p.pdf.

[6] ETSI. Network functions virtualisation (NFV); management and orchestration; functional requirement specification: ETSI GS NFV IFA010[S/OL]. (2014−12−01)[2016−06−29]. http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_NFV-MAN 001v010101p.pdf.

[7] 赵慧玲, 史凡. SDN/NFV的发展与挑战[J]. 电信科学, 2014, 30(8): 13-18. ZHAO H L, SHI F. Development and challenge of SDN/NFV[J]. Telecommunications Science, 2014, 30(8): 13-18.

[8] 肖子玉. SDN技术优化的最新研究综述[J]. 电信科学, 2015, 31(Z1): 132-139. XIAO Z Y. A review of the latest research on SDN technology optimization[J]. Telecommunications Science, 2015, 31(Z1): 132-139.

月球(1985−),女,中国移动通信集团设计院有限公司工程师,主要研究方向为移动通信核心网、5G、云计算、NFV。

肖子玉(1969−),女,中国移动通信集团设计院有限公司资深专家、教授级高级工程师,主要研究方向为移动通信核心网、5G、NFV、网络安全。

吴丽华(1982−),女,中国移动通信集团设计院有限公司高级工程师,主要研究方向为移动通信核心网、NFV。

沈蕾(1980−),女,中国移动通信集团设计院有限公司高级工程师,主要研究方向为移动通信核心网、NFV。

Key problems of telecom operators’ NFV future network management system evolution

YUE Qiu, XIAO Ziyu, WU Lihua, SHEN Lei
China Mobile Group Design Institute Co., Ltd., Beijing 100080, China

Network function virtualization (NFV) is the core technology and architecture of telecom-level business to cloud, which is the inevitable trend of future network evolution. NFV brings new capabilities to the communications network, at the same time, it requires new management and orchestration (MANO) capabilities for existing equipment operations, management, maintenance and configuration models. First of all, the network management system architecture and future evolution planning of the physical network element were summarized, and by the coming of NFV technology, the changes of the existing network equipment management method and the new network management architecture and function were concluded. The coordination of NFV MANO and operation support system (OSS), NFV MANO and other peripheral network was deeply researched. Finally, from the perspective of telecom operators, the deployment and evolution strategy of NFV MANO based on decoupling level was suggested.

network function virtualization, management and orchestration, operation support system, coordination, deployment and evolution strategy

TN915.81

A

10.11959/j.issn.1000−0801.2017085

2017−02−20;

2017−03−24

猜你喜欢
网元网管虚拟化
基于OpenStack虚拟化网络管理平台的设计与实现
一种全网时钟同步管理方法
对基于Docker的虚拟化技术的几点探讨
虚拟化技术在计算机技术创造中的应用
存储虚拟化还有优势吗?
“五制配套”加强网管
发射机房网管系统的设计原则及功能
Java EE平台在综合网元管理系统中的应用研究
网管支撑系统运行质量管控的研究与实现
S1字节和SDH网络时钟保护倒换原理