ONAP模型委员会召集北京版本模型讨论,六大标准组织参会(附资料下载)

ONAP 模型委员会在2017年12月ONAP Beijing Release Forum召开期间组织了一个ONAP Modeling Workshop,邀请了六个标准组织,和30几家公司一起参加,并得到华为公司的赞助。这次workshop就很多关键问题都达成了一致,比如模型规范制定的社区流程和方法,模型设计的工具,信息模型和标准保持一致,数据模型和OASIS TOSCA的一致性,模型的命名规则和版本的管理等,为ONAP R2版本的模型按时完成做出了重要贡献,确保了版本的顺利发布. 并且进一步的促进标准和开源在CIM(共同的信息模型上)前进一大步,促进了NFV社区的繁荣,并在ONAP保证支持厂商的商用解决方案做出贡献.

ONAP Modeling Workshop Highlights


模型委员会主席,华为公司邓辉致开幕词,介绍了ONAP模型的背景,现状,及挑战。ONAP R1版本由于版本交付时间的压力,把ECOMP的模型和基于ETSI的OPENO的模型做了映射,分别在设计态和运行态进行了实现,到了R2+版本阶段,社区期待能够模型合并和统一,并且能兼顾ETSI NFV的IFA信息模型和基于OASIS TOSCA Simple profile的数据模型,同时在业务的设计上,TM Forum,MEF和ONF都有过自己的业务模型设计经验,希望能推动ONAP能接受自己的模型设计技术。这次Workshop的目的是就ONAP R2+的模型规范的讨论方法,采用的工具,资源和业务的信息,数据模型设计方法的细节进行讨论和决策,一旦达成了共识,就能保证ONAP R2的顺利发布.

ONAP模型组, AT&T 的Kevin Scaggs 介绍了当前讨论中的ONAP信息模型的整体情况,建模对象包括service、VNF、element group、monitoring parameter等,并给出了相应的class diagram。此外,Kevin也对当前建模中的一些疑问进行了介绍,比如scaling的范围是应用还是VDU,这些问题需要后续设计中进行讨论解决。

MEF Co Chair, Intent Working Group, 华为公司John Strassner, 根据MEF的模型工作经验对讨论中的信息模型class diagram提出了建议:1)ONAP中不需要对product进行建模;2)events不应该直接与service连接,而应该在KPI或者SLA模型中体现;3)license、entitlement等不应该作为resource,建议单独建模;4)建议管理实体和被管理对象分开建模。

John Wilmes, Director, IoT Projects at TM Forum, 介绍了TMF在模型方面的工作,表示ONAP可以参考TMF的工作实现BSS与ONAP系统之间的自动化交互。其中,TMF在模型驱动方面的做法值得ONAP借鉴,通过使用polymorphism pattern等方式,TMF的API可以支持与任何payload模型结合定义接口

ETSI ISG NFV 的Andrei Kojukhov(Amdocs)和ShitaoLi (Huawei) 介绍了ETSI NFV数据模型的工作,包括SOL004(VNF package)和SOL001(VNFD/NSD)。SOL004方面强调了VNF package安全性方面的定义,这部分ONAP可以参考;SOL001当前还处于draft阶段,Deployment Flavor方案还没有完成,当前SOL001中的TOSCA type定义主要引用的tosca-nfv-profile的定义,所以同TOSCA的分歧并不大,SOL001只包含VNFD TOSCA模型的定义,不包含PNF的定义,ETSI NFV当前也没有计划对PNF stage 3做标准化工作。

ONF 的Nigel Davis(Ciena)介绍了ONF在模型方面的工作。ONF的模型采用了嵌套的方式进行定义,优点是便于扩展,如果使用composite pattern,则可能出现当前建模为(不可分解的)atomic的资源在未来变成(可以分解的)composite资源的情况。ONF模型的另外一个特点是将物理资源和抽象功能统一建模,对于ONAP的PNF/VNF建模具有参考意义。最后,Nigel提出未来的建模方向是将resource和service统一用capabilities来表达,不再进行区分。

Micheal Brenner(Cloudify)讲述了OASIS TOSCA报告,强调TOSCA是一个辅助建模的工具,并且IPR是opensource friendly的。 当前针对NFV Deployment Flavor,ETSI NFV有4个方案,TOSCA还在评估,暂无结论。针对Tosca-nfv-profile会使用的tosca-simple-profile的版本进行了较多讨论,最后结论是是否采用最新的tosca-simple-profile版本还是需要从需求和use case出发,建议ONAP R2版本基于tosca-simple-profile v1.1进行实现。
Andy Mayer (AT&T) 和Lingli Deng (China Mobile) 代表ONAP模型工作组对R2的信息模型设计进行了总结。R2版本的信息模型整体采用类似TMF SID的概念,使用类似ONF的嵌套方式建模,分为service、service component、resource、resource component四层,分别用于描述customer facing service、resource facing service(NS、WAN等)、VNF/PNF、VNFC等对象,service和service component可以嵌套。

在Resource模型讨论方面,AT&T 公司的David Shadmi介绍了R2版本SDC对数据模型的实现思路:整体分为service和resource两层,分别对service/service component和resource/resource component建模。Service和resource都可以通过substitution mapping的方式支持多层嵌套,便于扩展。

华为公司杨旭介绍了当前VNFD的模型讨论情况,经过现场讨论,确认了r2版本的class diagram方案,以最新版本的ETSI VNFD模型为基础,对external CP的表达方式进行简化,将其作为ONAP VNFD的基础模型。后续将审视element group等属性定义的内容。另外,介绍了运行态模型的讨论情况,明确需要统一命名规范,并根据需求对AAI现有实现进行优化。

MultiVIM项目PTL Xinhui(Vmware公司)介绍了MultiVIM项目对资源层FCAPS建模的需求。MultiVIM需要采集资源层的事件和性能信息提供给DCAE等组件进行分析和处理,因此希望对事件、告警、性能指标等进行统一建模,在ONAP中实现标准化。讨论建议先对现有标准(如ITU-T X.733,SID等)进行调研,后续考虑如何制定相关模型标准。

爱立信的Michella和Peter对模型工作组的工作方法进行了建议:1)确定Papyrus版本,便于社区对模型文件进行贡献;2)创建backlog,对待办事项进行记录;3)使用Jira等工具进行任务管理,推动模型工作。CLAMP项目的Ron介绍了CLAMP项目及闭环自动化的相关信息,并对建立control loop模型提出了需求。

最后,模型委员会主席邓辉对workshop进行了总结,各个标准组的经验和建议对ONAP的模型定义很具参考意义。后续会根据建议,利用Jira等工具组织模型的定义工作。计划在近期针对R2、R3版本计划,讨论未来的模型定义内容和各项目实现节奏。邓辉表示,此次workshop,给模型小组及标准组织一个非常难得的面对面沟通讨论机会,促进很多关键议题达成共识,对于R2版本的模型部分做出了重要贡献,模型小组期待下一次的模型workshop能在2018年三月份召开。

Workshop 材料下载:https://wiki.onap.org/display/DW/ONAP+Modeling+Workshop+Program


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/20373.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于17-12-23
1