D7.6 Preliminary Report into Proposed Standardization ... · D 7.6 – Preliminary Report into...

D7.6 – Preliminary Report into Proposed

Standardization Activities

Document Number D 7.6

Status Draft

Work Package WP 7

Deliverable Type Report

Date of Delivery 31/December/2015

Responsible Unit TID

Contributors TID: Diego R. López

IRT: Domenico Gallico

Fraunhofer: Marius Corici

Orange: Imen Grida Ben Yahia

Keywords Standardization, SDO, Open source, IETF,

ETSI, ONF, 3GPP. OpenStack, OpenDayLight,

OPNFV

D 7.6 – Preliminary Report into Proposed Standardization Activities

CogNet Version 0.1 of 29

Dissemination level PU



Change History

Version Date Status Author (Unit) Description

0.1 25/11/2015 Draft Diego López (TID) ToC. definition and template

for SDO sections based on the

IETF description

0.2 22/12/2015 Draft Diego López (TID),

Domenico Gallico (IRT)

Further sections added

0.3 4/01/2016 draft Imen Grida Ben Yahia

(Orange)

Adding TMF section



Acronyms and Definitions

Acronym Defined as

ETSI European Telecommunications Standards Institute

IAB Internet Architecture Board

IANA Internet Assigned Numbers Authority

IESG Internet Engineering Steering Group

IETF Internet Engineering Task Force

IRTF Internet Research Task Force

3GPP 3rd Generation Partnership Project

ONF Open Networking Foundation

OPNFV Open Platform for NFV



Executive Summary

This document provides the initial plans of the CogNet project for standardization activities, as

one of the key ways to achieve the industrial impact the project has among its main objectives.

The document starts with an introduction describing how the project has identified the targets

for standardization, both among SDOs and open-source projects, and how the results of the

analysis performed for each one are included in the following sections.

The rest of sections of the document correspond to the relevant SDOs and open-source projects,

describing their processes and the committees where the results of CogNet can be contributed

with the maximum impact. These targets are:

o Among the SDOs: IETF/IRTF, ETSI, ONF, 3GPP and TM Forum

o Among the open-source projects: OpenStack, OpenDaylight, OPNFV, OpenBaton and

OpenMANO

.



Table of Contents

1. Introduction....................................................................................................................... 7

2. IETF/IRTF ............................................................................................................................ 8

2.1. ANIMA ................................................................................................................................................................ 9

2.2. I2NSF ................................................................................................................................................................... 9

2.3. NFVRG .............................................................................................................................................................. 10

2.4. NMLRG ............................................................................................................................................................. 10

2.5. SUPA ................................................................................................................................................................. 10

3. ETSI ................................................................................................................................... 12

3.1. EVE ..................................................................................................................................................................... 13

3.2. IFA ...................................................................................................................................................................... 13

3.3. REL ..................................................................................................................................................................... 13

3.4. SEC ..................................................................................................................................................................... 14

3.5. TST ..................................................................................................................................................................... 14

4. ONF ................................................................................................................................... 15

5. 3GPP ................................................................................................................................. 17

6. TM Forum ........................................................................................................................ 19

7. Open-Source Projects ..................................................................................................... 21

7.1. OpenStack ....................................................................................................................................................... 21

7.2. OpenDaylight................................................................................................................................................. 23

7.3. OPNFV .............................................................................................................................................................. 24

7.4. OpenBaton ...................................................................................................................................................... 25

7.5. OpenMANO ................................................................................................................................................... 26

7.6. Apache Hadoop ............................................................................................................................................ 27

8. References ....................................................................................................................... 29



1. Introduction

Standardization activities constitute one of the key ways of achieving a high impact of the results

and of demonstrating the technical progress of the project, especially now that the application of

Machine Learning techniques to network infrastructures is beginning to be considered a realistic

approach for actual network operation, beyond the initial steps of exploratory research within

industry and academia. The coming sections describe the initial targets of CogNet

standardization activities.

The standardisation of CogNet results will be focused on the most promising standardization

committees in the relevant standards development organizations (SDOs) already considering the

application of Machine Learning techniques and/or addressing innovative aspects connected with

the application environments considered by CogNet, especially in what relates to network

management, software networks, security, and their application to emerging 5G architectures.

The CogNet team has performed an initial analysis of the most promising of these SDOs and the

relevant committees, the results of which is presented in this document. The goals and processes

of each SDO are introduced, together with an analysis of the committees and working groups

where CogNet results can be contributed and become part of the produced standards. Since the

CogNet partners acknowledge that the complete standardization process may well take longer

than the project lifetime we want to express our commitment to continue the effort required to

achieve full standardization of the fruitful contributions beyond the end of the project, as part of

the further exploitation of CogNet results.

Furthermore, we are aware of the new standardization mechanisms offered by open source

projects, beyond the use of open source software as the base for project development and the

further distribution of project results under an open source license to maximize impact. Some

current open source projects support a different mechanism for standardization, equally or even

more effective than documented specifications. This mechanism consists of the definition of open

APIs and the availability of a reference implementation distributed as open source. To achieve

this standardization effect, open source projects need to have a wide industrial support and

governance mechanisms in place that make them in practice similar to SDOs and their processes.

CogNet has considered this additional way for achieving a high impact in industrial practice, and

the team has therefore identified those open source projects widely accepted by the industry

where the results of the project can be contributed as part of the standardization effort.

In addition, the CogNet team is committed to a continuous observation and evaluation of further

standardization opportunities that can appear during the project execution.



2. IETF/IRTF The Internet Engineering Task Force (IETF) is a large open international organization, which is the

gathering point for network designers, operators, vendors, and researchers focusing on the

evolution of the Internet architecture and the smooth operation of the Internet. It is open to any

interested individual. The IRTF (Internet Research Task Force) is a parallel organization1 focusing

on longer term research issues. In the rest of this section, the term “IETF” will refer to both

parallel organizations unless otherwise explicitly said.

The IETF Mission Statement is documented in RFC 3935 and the Tao of the IETF is also available

as RFC 4677. The detailed IRTF guidelines and procedures are described in RFC 2014, and RFC

4440 provides further details on the role of the IRTF, provided by the Internet Architecture Board

(IAB).

The standardization process is based on the following elements:

o IETF meetings - Much of the work is done through IETF meetings, which are held three times

per year, as well as via mailing lists. IETF contributions and decisions are considered made

and decided by individuals. Any individual can attend an IETF meeting. Both registration and

payment of a registration fee are essential in order to attend an IETF meeting.

o Working Groups - Working Groups are structured around a charter describing there

objectives and plans, with at least tow co-chairs responsible to foster the completion of the

WG charter, moderate discussions, and evaluate and declare WG consensus. There are seven

functional areas, each grouping several WGs, with at least two Area Directors per area. The

current IETF areas are Applications and Real-time, Internet, Operations and Management,

Routing, Security, Transport, and a General area focused on the coordination with IANA.

The IRTF has a similar structure, but the equivalent to WGs are called Research Groups (RG)

and there are no areas.

o BOFs – Whenever there are some individuals who are interested on the same topic in a

particular area that is not covered by an existing WG, then a face-to-face meeting needs to

be held to discuss the opportunity of starting a new WG. Such meetings are called Birds of a

Feather meetings (BOFs) and have to be approved by the Area Director in the relevant area

before it can be scheduled. Moreover, a mailing list could also be set up, where all

participants could start discussing and working on the topic.

o RFCs and Internet Drafts – Every IETF standard is published as a Request for Comments (RFC)

and every RFC starts out as an Internet Draft (I-D). The procedure in order to publish a

standard is the following:

o Publish the document as an Internet Draft.

o Receive comments on the draft and edit the draft based on the comments.

o Repeat the steps above, until the draft is efficiently discussed. Then it is submitted to the

IESG.

1 The IRTF can be practically considered the “research branch” of the IETF



If the IESG approves the draft to become an Internet standard, then it is published as a

Proposed standard and after six months it can become a Draft standard. A few years after a

document has been a Draft standard, it can become an Internet standard.

The IRTF follows a similar process, though the final result becomes an experimental RFC and

the body in charge of approving it is termed IRSG.

The following sections discuss the main standardization opportunities for CogNet results within

the current IETF WGs and IRTF RGs, with special emphasis on those groups that due to their

being in their initial evolution stage are more suitable for direct influence from the project results.

It is worth noting that the order does not imply relevance or priority, as it is just alphabetical, and

that the project team will keep monitoring and contributing to the evolution of the IETF groups

to identify and foster new opportunities.

2.1. ANIMA

The general objective of this working group is to enable the progressive introduction of

autonomic functions into operational networks, as well as reusable autonomic network

infrastructure, in order to reduce the OpEx. The WG aims to develop a system of autonomic

functions that carry out the intentions of the network operator without the need for detailed low-

level management of individual devices, by means of a control paradigm where network

processes coordinate their decisions and automatically translate them into local actions, based on

various sources of information including operator-supplied configuration information or from the

existing protocols.

This WG can be essentially impacted by results from WP4 and WP5, especially in what relates to

the inclusion of mechanisms derived from machine learning in the control loops. Some outcomes

from WP3, in terms of direct requirements of machine learning techniques to make their

inclusion feasible or more productive, can be applicable here as well.

2.2. I2NSF

The goal of I2NSF is to define a set of software interfaces and data models for controlling and

monitoring aspects of physical and virtual Network Security Functions (NSFs), enabling clients to

specify rulesets. I2NSF will focus on flow-based NSFs that provide treatment to packets/flows,

such as Intrusion Protection/Detection System (IPS/IDS), web filtering, flow filtering, deep packet

inspection, or pattern matching and remediation. Controlling and monitoring aspects of NSFs

include the ability to specify rules, query, and monitor NSFs by one or more management

entities. Standard interfaces for monitoring and controlling the behavior of NSFs are essential

building blocks for providers of security service to automate the use of different NSFs from

multiple vendors.

This WG is a clear target for the results of WP5, with a special emphasis on providing

requirements and eventually solutions to go beyond the current approaches that require a full

human mediation to apply security measures on network infrastructures.



2.3. NFVRG

The Network Function Virtualization Research Group (NFVRG) brings together researchers from

both academia and industry to explore the research problems related to NFV. These problems

address not just pure networking issues but also computing and storage aspects in the

environments providing support to network functions. It is hoped that the outcome of the

research will benefit research efforts in other groups within the IRTF and standardization activities

of IETF WGs. The NFVRG has identified three main challenges to focus initially its efforts on,

related to policy-based resource management, analytics for visibility and orchestration, and

service verification with regards to security and resiliency.

The challenges listed above are directly connected to many of the goals of WP4 and WP5, and

therefore they are relevant targets for starting the standardization of results from these WPs.

Beyond these potential contributions, the outcomes of WP6 can be provided as experimental

reports or additional evidence for ongoing activities.

2.4. NMLRG

NMLRG is a proposed RG within the IRTF, with the purpose of providing a forum for researchers

to explore the potential of machine learning technologies for networks. In particular, the NMLRG

is intended to work on potential approaches that apply machine learning technologies in network

control, network management, and supplying network data for upper-layer applications. The

initial focus of the NMLRG will be on higher-layer concepts where the machine learning

mechanism could be applied in order to enhance the network establishing, controlling,

managing, network applications and customer services. The NMLRG is expected to identify and

document requirements, to survey possible approaches, to provide specifications for proposed

solutions, and to prove concepts with prototype implementations that can be tested in real-world

environments.

An IRTF RG focused on machine learning will become one of the main standardization targets for

CogNet, especially for the architectural concepts to be produced by WP2, the requirements for

supporting technologies to be analysed by WP3, and the general principles associated with the

results of WP4 and WP5. Beyond this, WP6 can be used to report demonstrations of the

suitability of machine learning approaches.

2.5. SUPA

The SUPA (Simplified Use of Policy Abstractions) Working Group is chartered to define a data

model to be used to represent high-level, possibly network-wide policies, which can be input to a

network management function. Processing that input most probably results in network

configuration changes. SUPA however does not deal with the definition of the specific network

configuration changes but with how the configuration changes are applied (e.g. who is allowed

to set policies, when and how the policies are activated, changed or de-activated). Practically,

SUPA is focused on defining base YANG data models to encode policy, which will point to

device-, technology-, and service-specific YANG models developed in other working groups.



The SUPA focus on policy representation and manipulation will have direct interaction with the

inputs to be used by the modules considered by WP4/WP5, and to some extent with how WP3

will have to adapt machine learning procedures. This implies these WPs will be in the position of

contributing additional requirements for the SUPA policy data model.



3. ETSI ETSI is the European Telecommunication Institute, a European Standards Organization

recognized by the European Union, and focused on producing global standards for Information

and Communications Technologies (ICT), including fixed, mobile, radio, converged, broadcast and

Internet technologies. ETSI has more than 800 member organizations in 64 countries all over the

world, and among the most salient standards produced by ETSI we can cite the ones around

GSM, DECT, or smart cards. ETSI acts as the rooting organization for other global industry

standardization partnerships like 3GPP and OneM2M.

ETSI standardization work is organised around:

o Most of the standardization work is carried out by committees. The members of these

committees are technical experts from member organizations. These committees meet

typically between two and six times a year, either on ETSI premises or elsewhere. There is a

range of different types of committees for different tasks:

o Technical Committees (TC) and ETSI Projects (EP). Both activities address a number of

standardization activities defined in their terms of reference. TCs work in a specific

technology area, while EPs are established to meet particular market sector needs

rather than centred around a basic technology, and last for a fixed period of time.

o ETSI Partnership Projects, established when there is a need to co-operate with other

organizations to achieve a standardization goal. There are currently two Partnership

Projects: the Third Generation Partnership Project (3GPP) and oneM2M.

o Industry Specification Groups (ISG), operating alongside the traditional standards-

making mechanisms and focusing on a very specific activity. ISGs are self-contained,

decide their own work programme and approve their own specifications.

o The ETSI Directives define the legal status, purpose, scope, and functions of ETSI and covers

the entire lifecycle of our standards.

o ETSI committees are co-ordinated by the Operational Co-ordination Group (OCG), which

includes the chairmen of all our technical committees. Ultimately the committees are

accountable to the ETSI Board and the General Assembly.

o ETSI members decide what work to be done, by each committee establishing and maintaining

a work programme which is made up of individual items of work. Collectively, the work

programmes of all the committees constitute the ETSI Work Programme. Each work item

describes a specific standardization task and normally results in a single standard, report or

other document.

o ETSI follows an open approach to standardization, and operates by direct participation (ETSI

members are not represented by a national delegation or other body), and any member may

bring as many contributions and voice as many opinions as desired. Decisions are taken by

consensus, declared by the committee plenary.

ETSI encourages the introduction of standardization as early as possible in the development of a

new technology, as it would provide a solid foundation for its future exploitation. CogNet intends

to begin early standardization and pre-standardization activities in the ETSI, specifically in the

committee of highest relevance to the project, the ISG on Network Functions Virtualization. The



following sections describe the different working groups in which the ETSI NFV ISG is organized

and describes the main contributions CogNet can make to each of them.

3.1. EVE

The Evolution and Ecosystem WG is focused on exploring new use cases, evaluating new

technologies, and acting as the central point for the interaction with other standardization

activities related to NFV. Some of the most salient recent results are related to the elaboration of

the relationship between the NFV and SDN concepts and architectures, done in collaboration

with the Architecture WG of the ONF, and the elaboration of a roadmap for information models

applicable to network functions and services.

The EVE WG constitutes the main target for CogNet results within the ETSI NFV ISG, and a report

on the application of Machine Learning to the NFV architecture and orchestration practices

would be a natural contribution by WP2 and WP4, while WP3 could provide inputs on the

applicability of particular techniques to future NFV use cases, as the ones being discussed in the

project.

3.2. IFA

The IFA (Interfaces and Architecture) WG activity includes NFV architectural aspects, requirements

to support interoperability at reference points, the information models and information flows

applicable to the deployment requirements and lifecycle management of NFV abstractions, and

the definition of interface protocols and data models. It aims at delivering a consistent

consolidated set of models and flows to support interoperability at reference points, and the

refinement of the NFV architecture and interfaces, with the main goal of producing and

maintaining a set of detailed specifications focused on interoperability.

Being IFA the WG more oriented towards normative aspects in the ETSI NFV ISG the possibility of

contribution from CogNet will be limited, but the project team will be likely in the position of

progressing some of the use cases and architectural recommendations mentioned for the EVE

WG into normative status through IFA.

3.3. REL

REL stands for Reliability, and this WG is dedicated to the analysis of the reliability and availability

of the elements of NFV systems, the techniques and mechanisms to ensure reliability, availability

and assurance in an operational virtual environment. It intends to produce specifications in areas

of reliability and availability in the practical context of an operational virtual environment,

investigating enhancements in the context of a NFV environment to ensure reliable and highly

available NFV-based network services, and providing guidance on mechanisms for validation,

assurance and SLAs.



CogNet does not only contemplate reliability and assurance among its main use cases for WP2

and WP4, but intends to provide a better integration of SLA and other policy requirements in

NFV management, suitable to be contributed to the work of the REL WG.

3.4. SEC

The Security (SEC) WG considers aspects related to information, network and communications

security (including resilience, availability and performance isolation of NFV systems), the security

of individual machines/processes, the security of large systems, and networks, security tools,

controls and techniques. It addresses security at design-time, deployment-time and run-time,

and the appropriate measures for operational efficiency and features to support regulatory

requirements, e.g. Lawful Intercept, Privacy and Data Protection.

Security applications of Machine Learning is the main objective of WP5, so contributions to the

SEC WG can be foreseen, both in terms of securing the NFV infrastructures and services

themselves, and in the provisioning of enhanced NFV-based security services.

3.5. TST

The TST WG is focused on testing and implementation issues, especially focused on

interoperability. This WG is the home of the NFV PoC (proof-of-concept) framework, oriented

towards demonstrating the feasibility of the NFV proposals and providing initial experimental

evidence of new proposals. The WG is working in making this framework evolving into a

complete interoperability assessment one, as well as in the applicability of open-source

approaches to build reference implementations able to support these interoperability

evaluations. Some recent proposals include the organization of public events to demonstrate

achievements related to the interoperability framework.

CogNet can take advantage of these opportunities for technology assessment and exploration to

contribute their results, and in particular the demonstration to be provided within WP6, as part of

the PoC framework and even beyond, as part of future NFV interoperability demonstration

events.



4. ONF

The Open Networking Foundation (ONF) is a user-driven organization dedicated to the

promotion and adoption of Software-Defined Networking (SDN) through open standards

development. The ONF emphasizes an open development process that is driven from the end-

user perspective, and nowadays continues to analyse SDN requirements, evolve the OpenFlow

Standard to address the needs of commercial deployments, and research new standards to

expand SDN benefits.

ONF standardization activities are driven by its member organizations, that support it and

contribute and decide on the standards developed by the Foundation. The ONF has more than

150 industrial members, participating through a process governed by the following structure:

o The work is structured by means of technical communities, organized into Areas, Councils and

Groups

o Areas handle specific issues related to Software-Defined Networking (SDN), and

collaborate with the world’s leading experts on SDN and the OpenFlow Standard

regarding SDN concepts, frameworks, architecture, software, standards and

certifications.

o Councils provide overall leadership with respect to strategy, operational execution

and technical direction of the organization.

o Groups provide guidance and advise ONF on activities to help accomplish the

organization’s goals.

o The Operator Area works to gather and validate network operator requirements, priorities,

trade-offs, and vision. Current projects in this area are related to carrier-grade SDN and

migration procedures.

o The Services Area works on technical projects to enable applications and network operator

services with SDN technologies. These projects are focused on architecture, information

modelling, the SDN northbound interfaces, and security.

o The Specifications Area is responsible for publishing all ONF technical specifications. This

includes the core OpenFlow switch protocol for SDN based packet forwarding, as well as OF-

Config and Negotiable Datapath. In addition, the area publishes extensions to OpenFlow for

Optical Transport, wireless mobile, backhaul and enterprise WiFi. Finally, the Testing &

Interoperability sub-group provides specifications for OpenFlow compliance, testing and

interoperability.

o There is a Market Area acting as the outbound facing arm of the ONF. Its primary goals are to

educate the SDN community on the value proposition of software-defined networks based

on ONF Standards and promoting adoption for open SDN.

The obvious target for CogNet contributions is the Services Area, and especially in what relates of

the application of the Machine Learning mechanisms CogNet is exploring to enhance the SDN

northbound interfaces, so network programmability can directly integrate the CogNet learning

flow. Furthermore, CogNet will likely take advantage of the reference information model being

defined by ONF [2], and in that respect the project will be in the position of contributing to it



from the point of view of the application of machine learning techniques and their interfacing

with other elements in the SDN architecture. Beyond these two main aspects, other contributions

may be possible in what relates to architectural aspects and security.



5. 3GPP

The 3rd

Generation Partnership Project (3GPP) [3] is the main standardization partnership

between a significant number of operators and equipment providers, which aims at fostering the

development of cellular telecommunication network technologies including radio access network,

the core network and the service capabilities as well as the interoperability with legacy and non-

3GPP access networks.

The role of 3GPP is to provide complete system specifications including the description of the

service requirements, the system architecture and protocols, functionality description and service

capabilities such as codecs, security and quality of service.

Starting from 1998, 3GPP has already standardized 3G and the only available 4G technologies as

well as their integration with non-3GPP technologies such as WiFi and regulatory items about

mobile terminals. Currently, 3GPP enters into the initial stages of the 5G technology

standardization.

From the perspective of the CogNet, the only part of 3GPP, which influences and can be

influenced directly is the Services and System Aspects Technical Specification Group (TSG-SA) [4].

TSG-SA is responsible for the definition of the overall architecture and the service capabilities of

the system based on the 3GPP specifications. TSG-SA includes the development of the service

capabilities (definition of services and feature requirements, development of service capabilities

and a service architecture for cellular and fixed applications, etc.), the description of the system

architecture as well as charging and accounting, network management, codec and security

aspects.

The obvious target for CogNet contributions is the SA5 Working Group (SA5 WG) [5], which

handles the work items related to the network management, currently still for the 4G networks,

however with a direct influence on the next 5G architecture. Specifically, SA5 has in each of the

3GPP Releases a specific set of feature or study items in the area of Operations, Administration,

Maintenance and Provisioning (OAM&P) handling the specifics of the network management for

the functions developed into the specific release [6].

For 3GPP Release 13, the specific work item concentrated on the energy efficiency related

performance measurements while for the newly started Release 14, it will concentrate on the

management of mobile networks that include virtualized network functions. This work item will

concentrate on a new management concept, architecture and requirements addressing

specifically systems that include virtualized network functions. Specific functionality will be

developed for the configuration management, fault management, performance management and

the overall lifecycle management of the networks that include VNFs, representing a bridge to the

ETSI NFV proposed architecture as well as the complete specification of the system for the

mobile networks.

Thus, a high priority within the work item will be given towards the efficient functioning of the

basic system and of the graceful integration of existing mechanisms for physical functions with

new ones designed for the virtualized network functions especially the orchestration



functionality. Less attention will be given towards the integration of “added value” functions such

as the ones related to decision mechanisms where usually 3GPP gives the liberty to the different

vendors to implement their own solutions.

CogNet aims at developing a new set of Machine Learning mechanisms for fault management

and for performance management of the various network functions, resulting in changes of the

system configuration through the configuration management (work from WP5). Based on this, a

careful attention will be given to the practical applicability of the developed solutions within the

3GPP architecture, similarly to the different equipment and software providers that will aim at

similar value-added differentiation.



6. TM Forum

TM Forum is a global industry association for digital business transformation. TM Forum

encompasses 900+ market-leading organizations. Its main goal is to provide framework, tool,

report, use cases and demonstrations, to ease the digital transformation and ensure consensus

around it. The three TMF pillars are the following

o Agile and Virtualized: to capture the transformation of the IT and operations that are

accelerating research and development, ensuring the improvement of the business agility for

the industry of ICT while reducing costs and risks

o Open & Partner effectively: to capture the smooth delivery, integration and management

with partners

o Customer Centric: to capture the engagement of improving the experience of customers.

The TM Forum develops and maintains up to date a framework, namely FRAMEWORX.

FRAMEWORX is a set of frameworks dedicated to different areas:

1. The Business Process Framework (a.k.a. eTOM)

2. The Information Framework (a.k.a. SID)

3. The Application Framework (a.k.a. TAM)

4. The integration Framework

Several running projects aim to ensure the progress of these set of frameworks. In the following,

we cite only the two projects related to CogNet areas of work.

Data Analytics Project

This project has the aim to introduce the use of Big Data and Big Data Analytics within the

business of the service provider. In [7], a standard architecture reference model for Big Data

Analytics was proposed. The CogNet under-construction architecture may use this reference

model by extending and adapting it to the SDN and NFV analytics. The same document also

presented an initial set of use-cases to help with the deployment of Big Data Analytics in

Telecoms projects.

Zoom (Zero-touch Orchestration, Operations and Management) Project

This project targets to define agile and flexible management operations to enable the delivery

and management of physical and virtual resources and services while ensuring lower capital and

operational expenditures [8]. The link with CogNet is with respect to the management operations

like configuration management and performance management that need to be agile flexible with

autonomic and machine learning principles. Furthermore, the Information Model under

development within the Zoom project (i.e. extending the TMF SID with SDN and NFV concepts)

will be an input to the CogNet information model and vice versa.

CogNet results could be presented as a TMF catalyst project if the information model from TMF

were used and extended for example. Catalyst projects are collective industrial efforts to extend,

adapt or challenge TM Forum frameworks.



7. Open-Source Projects

In the era of continuous improvement for business solutions, the open source approach to

software development is gaining an always-increasing importance among IT companies and

computer industry in general. The essence of this approach relies on the sharing of source code

or hardware design, with the permission to reuse, redistribute, modify and improve at no cost.

Open-source projects provide a certain number of benefits to industry and to end-users, which

can be summarized in the following main key topics:

o Security. Based on the fact that a typical community for big open-source projects is based on

thousands of developer working with full visibility on software code, it is more likely that

code flaws are discovered and patched very quickly

o Quality. Based on large communities, with experts coming from industry and academia, for

very big projects superior quality of the project is expected.

o Customizability/Flexibility. Due to the inherent openness of the open-source project,

superior capability to customize the source-code adding needed features is expected

o Freedom. Open-source projects break the vendor lock-in rule

o Interoperability. Open-source projects provide for great interoperability capabilities, due via

full APIs description and implementation

o Auditability. The visibility of the code behind open source software means that the

consumer can dive deep in the source code and ensure that the project fully adheres to its

requirements

o Support Options. Open-source projects eliminate the need for a paid support proved by

software supplier and provides for a full support orchestrated by thousands of

users/developers

In this section, we will present five different open source products that stand out for code quality

and maturity, adoption and above all for their bond to the topics addressed by the CogNet

project.

7.1. OpenStack

OpenStack [9] is a free and open-source software platform for cloud-computing, mostly

deployed as an infrastructure-as-a-service (IaaS) OpenStack began in 2010 as a joint project

of Rackspace Hosting and of NASA. As of 2015 it is managed by the OpenStack Foundation, a

non-profit corporate entity established in September 2014 to promote OpenStack software and

its community.

More than 500 companies have joined the project, being the most notably ones. These

companies are organized in the following tiers:

o Platinum members (which provide a significant portion of the funding to achieve the

Foundation's mission of protecting, empowering and promoting the OpenStack community

and software)

https://en.wikipedia.org/wiki/Rackspace

https://en.wikipedia.org/wiki/NASA



o Gold Members (which provide funding and pledge strategic alignment to the OpenStack

mission)

o Infrastructure donors (companies running OpenStack clouds, donating cloud resources to the

OpenStack project infrastructure)

o Corporate Sponsors (provide additional funding to support the Foundation's mission of

protecting, empowering and promoting OpenStack)

o Supporting Organizations

The OpenStack community collaborates around a six-month, time-based release cycle with

frequent development milestones. Each six months a new major release (gathering new

functionalities and patches) is produced. During the planning phase of each release, the

community gathers for an OpenStack Design Summit to facilitate developer working sessions and

to assemble plans.

Actual OpenStack release (Liberty) consists of the following sub-projects:

o Compute (Nova)

o Image Service (Glance)

o Object Storage (Swift)

o Dashboard (Horizon)

o Identity Service (Keystone)

o Networking (Neutron)

o Block Storage (Cinder)

o Orchestration (Heat)

o Telemetry (Ceilometer)

o Database (Trove)

o Elastic Map Reduce (Sahara)

o Bare Metal Provisioning (Ironic)

o Multiple Tenant Cloud Messaging (Zaqar)

o hared File System Service (Manila)

o DNSaaS (Designate)

o Security API (Barbican)

https://en.wikipedia.org/wiki/Release_early,_release_often



Figure 7-1 Openstack high level architecture

7.2. OpenDaylight

OpenDaylight [10] is an open platform for network programmability to enable SDN and NFV for

networks at any size and scale. OpenDaylight Project is a collaborative open source project that

aims to accelerate adoption of SDN and NFV for a more transparent approach that fosters

innovation and reduces deployment and operational risks.

The project started in 2013, under the Linux Foundation with the support of an increasing

number of companies from the industry.

The membership to the project is organized in hierarchical tiers as follows:

o Platinum members

o Gold Members

o Silver Members

Over the years the following main releases have been produced:

o April 2013 (first announcement)

o February 2014 (hydrogen release)

o September 2014 (Helium release)

o November 2014 (Helium SR1 release)

o June 2015 (Lithium release)



Figure 7-2 OpenDaylight Helium release high level architecture

7.3. OPNFV

OPNFV [11] is a carrier-grade, integrated, open source platform to accelerate the introduction of

new NFV products and services. As an open source project, OPNFV is uniquely positioned to

bring together the work of standards bodies, open source communities and commercial suppliers

to deliver a de facto standard open source NFV platform for the industry.

The scope of OPNFV’s initial release is focused on building NFV Infrastructure (NFVI) and

Virtualized Infrastructure Management (VIM) by integrating components from upstream projects

such as OpenDaylight, OpenStack, Ceph Storage, KVM, Open vSwitch, and Linx.

The project is a Linux Foundation Collaborative Project and implements many open source best

practices familiar to other leading projects

The membership to the project is organized in hierarchical tiers as follows:

o Platinum members

o Silver members

o Associate members

The first release, called ARNO is available now, providing an initial build of the NFV Infrastructure

(NFVI) and Virtual Infrastructure Manager (VIM) components of the ETSI NFV architecture.



Figure 7-3 OPNFV high level architecture

7.4. OpenBaton

OpenBaton [12] is an ETSI NFV compliant Network Function Virtualization Orchestrator (NFVO).

OpenBaton was part of the OpenSDNCore project started almost three years ago with the

objective of providing a compliant implementation of the ETSI NFV specification. OpenBaton is

mainly developed by Fraunhofer FOKUS Institute. It represents an open source contribution

towards the developer community, fostering the development of independent third party

projects and products.

OpenBaton provides, in its current first stable release (4th

minor release) [13], the following

components:

o A Network Function Virtualisation Orchestrator (NFVO) completely designed and

implemented following the ETSI MANO specification

o A generic Virtual Network Function Manager (VNFM) able to manage the lifecycle of VNFs

based on their descriptors

o A set of libraries which could be used for building your own VNFM



Figure 7-4 OpenBaton high level architecture

7.5. OpenMANO

OpenMANO [14] is an open source project that provides a practical implementation of the

reference architecture for Management & Orchestration under standardization at ETSI’s NFV ISG

(NFV MANO). OpenMANO is mainly sponsored by Telefonica.

The OpenMANO software distribution, currently in its stable release v03 consists of three main

software components:

o openvim: reference implementation of an NFV VIM (Virtualised Infrastructure Manager). It

interfaces with the compute nodes in the NFV Infrastructure and an OpenFlow controller in

order to provide computing and networking capabilities and to deploy virtual machines. It

offers a northbound interface, based on REST (openvim API), where enhanced cloud services

are offered including the creation, deletion and management of images, flavors, instances

and networks. The implementation follows the recommendations in ETSI NFV ISG Best

Practices on Performance [15].

o openmano: reference implementation of an NFV-O (Network Functions Virtualisation

Orchestrator). It interfaces with an NFV VIM through its API and offers a northbound

interface, based on REST (OpenMANO API), where NFV services are offered including the

creation and deletion of VNF templates, VNF instances, network service templates and

network service instances.

o openmano-gui: web GUI to interact with OpenMANO server, through its northbound API, in

a friendly way.

http://github.com/nfvlabs/openmano/raw/master/docs/openvim-api-0.6.pdf



Figure 7-5 OpenMANO high level architecture

7.6. Apache Hadoop

Apache Hadoop is an open-source software framework written in Java for distributed storage and

distributed processing of very large data sets on computer clusters built from commodity

hardware.

Contributors to Apache Hadoop code are represented by the volunteers contributing time, code,

documentation, or resources to the Hadoop Project. A contributor that makes sustained,

welcome contributions to the project may be invited to become a committer, who are

responsible for the project technical management.

Apache Hadoop Roadmap includes the following release types:

o Major releases (which implies significant API changes) are made as needed, perhaps

annually or even further apart.

o Minor Releases are made regularly, every few months.

o Point releases which contains fix to blocker bugs from an operational perspective.

Current Hadoop release is 2.7.2 with no announcement for next major release (3.x) at the time of

writing.

The Apache Hadoop project includes these modules:

o Hadoop Common: The common utilities that support the other Hadoop modules.

o Hadoop Distributed File System (HDFS™): A distributed file system that provides high-

throughput access to application data.

o Hadoop YARN: A framework for job scheduling and cluster resource management.

o Hadoop MapReduce: A YARN-based system for parallel processing of large data sets.



Figure 7-6 Apache Hadoop high level architecture



8. References

[1] Internet Research Task Force Website, https://www.ietf.org/

[2] Open Networking Foundation. Core Information Model (CoreModel),

https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-

reports/Core_Information_Model_V1.0.pdf

[3] 3rd

Generation Partnership Project Website, http://www.3gpp.org/

[4] 3GPP System Aspects Technical Specification Group, http://www.3gpp.org/specifications-

groups/25-sa,

[5] 3GPP Telecom Management (SA5 WG) http://www.3gpp.org/Specifications-groups/sa-

plenary/56-sa5-telecom-management,

[6] 3GPP 3GPP Work Items per TSG/WG, Active 3GPP Work Items for group: s5,

http://www.3gpp.org/DynaReport/TSG-WG--s5--wis.htm,

[7] GB979 Big Data Analytics Guidebook R15.5.0

[8] https://www.tmforum.org/wp-content/uploads/2014/10/ZoomDownload.pdf

[9] Openstack, https://www.openstack.org

[10] OpenDaylight, https://www.opendaylight.org

[11] OPNFV, https://www.opnfv.org

[12] OpenBaton project, http://openbaton.github.io/,

[13] OpenBaton source code, https://github.com/openbaton,

[14] OpenMANO project, http://www.tid.es/long-term-innovation/network-innovation/telefonica-

nfv-reference-lab/openmano

[15] ETSI NFV ISG. Network Functions Virtualisation (NFV); NFV Performance & Portability Best

Practises, http://www.etsi.org/deliver/etsi_gs/NFV-PER/001_099/001/01.01.02_60/gs_NFV-

PER001v010102p.pdf

https://www.ietf.org/

https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/Core_Information_Model_V1.0.pdf

https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/Core_Information_Model_V1.0.pdf

http://www.3gpp.org/

http://www.3gpp.org/specifications-groups/25-sa

http://www.3gpp.org/specifications-groups/25-sa

http://www.3gpp.org/Specifications-groups/sa-plenary/56-sa5-telecom-management

http://www.3gpp.org/Specifications-groups/sa-plenary/56-sa5-telecom-management

http://www.3gpp.org/DynaReport/TSG-WG--s5--wis.htm

https://www.openstack.org/

https://www.opendaylight.org/

https://www.opnfv.org/

http://openbaton.github.io/

https://github.com/openbaton

http://www.tid.es/long-term-innovation/network-innovation/telefonica-nfv-reference-lab/openmano

http://www.tid.es/long-term-innovation/network-innovation/telefonica-nfv-reference-lab/openmano

http://www.etsi.org/deliver/etsi_gs/NFV-PER/001_099/001/01.01.02_60/gs_NFV-PER001v010102p.pdf

http://www.etsi.org/deliver/etsi_gs/NFV-PER/001_099/001/01.01.02_60/gs_NFV-PER001v010102p.pdf

D7.6 Preliminary Report into Proposed Standardization ... · D 7.6 – Preliminary Report into...

Documents

Transcript of D7.6 Preliminary Report into Proposed Standardization ... · D 7.6 – Preliminary Report into...