www.linuxfoundation.org

Linux Foundation Networking and Orchestration White Paper:

Harmonizing Open Source and Standards in the Telecom World

A Publication of The Linux FoundationMay 2017

Harmonization White Paper2

Executive SummaryStandards have played a major role in telecommunications technology adoption for many years, validating the commercial viability of new technologies, facilitating multi-vendor interoperability, improving product quality, and expediting the introduction of technologies that would otherwise proliferate in a sea of proprietary alternatives.

Cloud-driven operational models have set the stage for a major paradigm shift for software to supersede hardware to offer agility, flexibility, and openness. Software Defined Networking and Network Functions Virtualization are the catalysts for digital transformation that is disrupting the entire industry.

In this white paper, we recast a key question under debate. Instead of ‘Standards vs. Open Source?’, we submit the question ‘How can open source complement standardization to improve market adoption?’ Our goal is to exploit the operational knowledge and use cases innate to Standards Development Organizations (SDOs), with collaborative innovation and openness offered by open source.

First, we will examine the benefits of standards and open source, and assess the challenges in evolving the technology adoption methodology. Next, we assess how standards and open source may be harmonized. Finally, we examine The Linux Foundation’s efforts to forge an integrated Networking and Orchestration architecture vision for the future.

Harmonization White Paper3

IntroductionFor decades, standardization has been an essential element for telecommunications/networking technology adoption, helping commercialize the industry’s most pervasive innovations, including the Internet and mobility, IP Telephony, among many others.

Standards have been used to motivate industry cooperation towards achieving multi-vendor interoperability, broad market adoption, and establishment of an open ecosystem that allows end-users and vendors alike to benefit.

Standards in this context encompass a number of qualities, including:

•Broad agreement over a well-defined scope•Well-accepted policy and intellectual property guidelines•Commands authority from technology contributors and consumers alike, typically

accredited by government and or industry associations•Specifications and artifacts available typically under non-discriminatory terms, but

sometimes membership is required, or there is a cost to obtain the specifications

Emergence of the industry’s most recent and disruptive breakthrough, Software Defined Networking (SDN) combined with Network Functions Virtualization (NFV) fueled by the ascent of the Cloud, is transforming telecommunications technology, operations, business models, and organizations. Industry standards processes and bodies have not been immune from this sea change. SDN and NFV have necessitated a rethinking of the standards process influenced by the factors below:

•The Rise of the Operator- Operators are engaging in the process like never before.

•Software IS Eating the World- Traditional standardization was developed for purpose- built hardware and embedded software that changed infrequently (especially silicon). SDN/NFV is ushering in a software era that requires a more flexible, rapid, and iterative standardization model to accommodate a broad range of use cases.

•Waterfall is giving way to Agile- Development is migrating from Waterfall to Agile, while static releases are giving way to more fluid deployment processes that merge development, test, and operations. Similarly, the ‘Analyze-Specify-Standardize-Build’ methodology is yielding to a more iterative approach, exploiting the benefits of open source development. Of course this shift will not happen overnight.

• Internet Time is giving way to Cloud Time- SDN/NFV require everything to work faster, whether new services development, service deployment, troubleshooting, modifications, upgrades, or standards development.

Harmonization White Paper4

Open source is a critical driver for change and the catalyst for digital transformation underway at many operators. It offers compelling (and well-known) benefits to both operators and vendors, perhaps most importantly the collaborative innovation that only a diverse community can provide.

Open source is also helping reshape technology adoption (see Figure 1). In fact, many of the key open source projects have evolved from the standardization effort, as the SDN/ NFV community recognized the need to streamline and enhance the standardization process to accelerate overall adoption. For instance, the Open Networking Foundation’s (ONF) efforts to define a general SDN architecture resulted in a series of open source SDN controllers. Early implementations in turn helped iterate early SDN De facto standards including OpenFlow, Intent-based Northbound Interfaces, and Transport SDN architecture.

Implementations Requirements Use Cases

Architecture

Architecture

Standards OSSComponents

OSSReferencePlatforms

Figure 1a Traditional Methodology Figure 1b Evolved Methodology

[Output: Standards and Specifications] [Output: Software and Architecture]

Similarly, the European Telecommunications Standards Institute (ETSI) NFV Industry Specification Group (ISG), the organization that defined NFV, recognized the need for open source to validate NFV activities. After completing the initial phase of the NFV definition, many of the organizations behind the ETSI NFV ISG spawned the Open Platform for NFV (OPNFV) to refocus on the integration and operational issues in recognition of the growing complexity of large scale software systems. MEF also defined an open source reference platform OpenLSO from the MEF LifeCycle Services Orchestration (LSO) Reference Architecture to address on-demand, inter-provider use cases, building upon MEF Ethernet connectivity services.

Beginning with the introduction of the OpenDaylight Project back in 2013, The Linux Foundation embarked on a journey that has resulted in an industry-leading portfolio of Open Source Networking and Orchestration (OS-N&O) projects that span the entire value chain, including OPNFV, FD.io, OPEN-O, PNDA among others.

Harmonization White Paper5

Widespread support for these open source projects (and many others) has augmented industry convergence and market adoption by helping to:

•Accelerate the entire process by renewing focus on implementation and not just specification

•Validate requirements and use cases using real-world implementations and operational insights

•Refine integration specifications for increasingly complex interactions in large-scale systems

•Assess performance considerations•Conduct PlugFests to address interoperability issues early in the lifecycle•Create/automate test plans•Demonstrate Proof of Concepts (PoCs) to effectively highlight the benefits

In addition, open source has also served to refocus standardization on the operationally important use cases and real-world interoperability issues.

While blending implementation into the standardization process is not new—the IETF has long required rough consensus and running code prior to ratifying new standards—open source moves one step further by motivating even more organizations to cooperate in the standards process. This in turn fosters a highly collaborative environment, which diminishes individual organization’s incentives to dominate the process.

In an era of digital transformation, both standards and open source will converge to drive new architecture and technology initiatives that will reshape the networks and services offerings of the future. Operators and solution providers will be able to choose from a number of different open source building blocks that can be tailored to address the needs for individual service providers, environments, and deployments.

At this relatively early stage, however, leading open source projects have progressed as standalone developments, albeit influenced by other projects and cross-fertilized by informal interactions. Each project operates with a distinct governance model, development infrastructure, release planning map, and priorities, in spite of the fact that many leading operators and vendors participate in multiple projects.

Now that the world’s leading operators are proceeding with large-scale re-architecture plans based on SDN/NFV, such as AT&T Domain 2.0, China Mobile NovoNet, China Telecom CTNet2025, NTT Enterprise Cloud, Orange EasyGo, Verizon SDN/NFV Reference Architecture, along with many others, open source communities have to become much better aligned with end users that maintain common technology stacks.

Harmonization White Paper6

The need for harmonization intensifies, as PoCs and trials pave the way towards deployment. Standardization and open source activities will play a major role in this process, leading to a more integrated architecture that that spans the entire communications stack. In addition, standalone efforts will yield to projects that may be readily integrated with the umbrella architecture, which will make it much easier to consume.

More and more Standards Development Organizations (SDOs) are already blending open source into the standardization process. This white paper examines why standards and open source are converging to address the changing needs of operator constituents, and achieve the overall goals of agility, quality, and faster (everything).

Harmonization White Paper7

ChallengesThe telecommunications industry is at a crossroads, with unprecedented competition and opportunity.

Operators and over-the-top innovators are fighting for position with users, while a new breed of cloud operators encroaches upon operators’ well-established businesses. Vendors are compelled to open up hardware architectures, and increasingly their proprietary software platforms as well. The result is a fundamental downward shift in margins that motivates the need for innovation like never before.

Conventional standards are consensus based, which are time consuming, and frequently skewed by proprietary implementations to enable vendors to compete. Traditional standards processes employ a waterfall methodology that places far greater emphasis on specification than implementation and testing. One reason for the relative long technology lifecycles is the tremendous investment required by vendors and operators to realize a sustainable RoI. In addition, SDOs and specifications development committees have traditionally been difficult for new entrants and cross-industry participants to maintain sustained participation through long waterfall development.

In addition, standards are becoming more complex relative to the low-level protocols standards of the past. SDN/NFV standards are built upon reference architectures, such as the ONF SDN Architecture, NFV Architectural Framework, and MEF Lifecycle Services Orchestration, with the 5G specifications on the horizon. Each includes numerous functional components, and open source building blocks that must be sufficiently flexible to address the needs of a broad range of diverse operators.

The fundamental goal of standardization—openness—is also evolving. Traditional standards have been driven by the need for multi-vendor interoperability, which offers operators choice and innovations from multiple vendors. But more often than not, multi-vendor management platforms shift the boundary from highly proprietary hardware platforms and their EMS’ to highly proprietary control, management, and orchestration platforms. Openness must evolve from ‘multi-vendor’ to ‘vendor neutral’ (i.e., not dominated by any one organization) to realize the vision of SDN and NFV.

SDOs are increasingly turning to the open source community to address these challenges, and enhance the standardization process. By leveraging the vast operational expertise of the SDO membership base, and collaborating with open source projects focused on implementation, markets may be served much more effectively. Forward-looking SDOs such as the ETSI NFV, ONF, IETF, and MEF are forging the reference architectures for NFV, SDN, and LSO, respectively. These groups envisioned an important role for open source up front, and actively engaged in a number of open source projects.

Harmonization White Paper8

Open source, however, does not serve as a panacea. First and foremost, appropriate incentives must exist to motivate participation throughout the community. Operators must demonstrate their commitment, by investing in the process. Vendors, which typically contribute the majority of developers who drive progress, must determine the appropriate level of investment in major projects, with the expectation of an adequate return over the long run. Profit motivations must existing up and down the value chain or open source projects and specification development committees fade away.

Harmonization White Paper9

Legal ImplicationsOpen source can enable innovation in a very fast, iterative model that is often seen at odds with traditional standards development—but it doesn’t have to be and in most cases works well without much difficulty.

Standards can produce valuable contributions to data models, formats, and interfaces that can accelerate open source software development within a community. Conversely, open source development can accelerate standards development with real-time development and testing on usable implementations that can provide immediate feedback into the standards development process. The open source tools, SDKs, and interfaces can bring a standard into production implementations at a very rapid pace.

This rapid pace can cause consternation regarding how to align IP models where you have a fast, iterative software development model, and a carefully calibrated and deliberate standard development model. Open source projects tend to have IP policies that promote rapid contribution, iterative evolution through small modifications, and open technical discussions. Traditional standards development models focus on ensuring adopters of the standard have the appropriate IP rights locked in.

Both models rely on their community of contributors for licensing rights. In an open source project, it’s very typical that contributors give everyone who receives the code rights based on their contribution. In a standards model, it’s typical that every member of the SDO pledges to make certain rights available to other members. The open source IP model often focuses on open contribution and rights for anyone who receives the code, whereas the standard is often focused on protecting everyone in the SDO membership implementing the standard.

Some open source projects have ‘membership’ in a foundation or body supporting the project financially, but membership never grants the member the ability to vote on a patch or force a contribution to be accepted—code decisions are always based on technical merit of the code contributed. A governing board of a project is likewise not involved in technical decisions, though any member of a board is able to contribute code for review just like anyone else.

The code contributions made to an open source project will be contributed under the terms of an open source license. Open source licenses vary significantly in terms and conditions with most falling into categories of copyleft and permissive licenses. Copyleft licenses generally require the distributor of binaries to also make the source code available to the recipient. Permissive licenses (e.g., BSD, MIT, or Apache) generally contain minimal requirements for distributing binaries, with most requiring just a simple notice, making it

Harmonization White Paper10

simple to offer a commercial binary. The other variance between licenses is usually based on whether the license includes a patent grant to make, use or sell and commercially exploit an invention embodied in a code contribution. Licenses generally treat patents embodied in code in three ways: 1) silent on patents, 2) imply patent terms in their language, and 3) incorporate explicit patent grants. For example, many open source projects have converged on using the Apache License, Version 2.0 which contains explicit patent grants.

In the vast majority of open source projects, the IP terms are embodied entirely within the open source license. Some projects may require additional terms in a Contributor License Agreement (CLA). The CLA is often used to bind a corporate entity to patent terms in the license or to grant the project steward the ability to relicense the code later if necessary. Regardless of the license and its patent treatment, one behavioral pattern that is easily observed is participation in a project often makes it commercially unreasonable to assert IP. A company participating in a project would likely find it very difficult to continue participating if it began asserting IP claims against other contributors. For this reason even projects using permissive licenses without any reference to patents have only in rare instances become the subject of patent issues.

Standards also approach IP differently. In a standards effort, the focus is most often on patents and sometimes references to copyright terms on reference implementations The focus on patents is also embodied in the structure of decision making, review and technical development where IP rights are commonly licensed under Reasonable and Non-Discriminatory (RAND) terms. In this structure, members of the standards project will know exactly what IP rights they need to license from the other members under the RAND licensing model. Some challenges may arise from the delay in IP disclosures which can often take a couple years and also from not knowing the RAND license terms up front. A member implementing a standard can often rely on the ability to obtain a license from other members when developing a solution implementing the standard though the exact terms and who the license is from will typically come later after the standard is finalized.

Sometimes a standards effort will also create a reference implementation or snippets of code demonstrating an implementation. This is a contrast to open source software which is most often expected to be the implementation of the software everyone in the community uses collaborates on developing together.

What seems to work in many cases is a model where the open source project focuses on building the best technical software and pairing that development activity with an architecture input process and a documentation effort at the end to document the appropriate interfaces that are expected to be standardized and leveraged for interoperability. Whether the standard and source are developed within the same project or in different organizations, there are usually many means to enable close collaboration and alignment. Aligning the open source IP policy with the analogous standards development effort is key to a strong alignment and feedback loop. An example of this would be Open Container Initiative, which was started by Docker and an ecosystem of contributors looking to evolve a cloud container runtime and image specification standard in parallel.

Harmonization White Paper11

Emergence of Open SourceThe Linux Foundation considers open source software as the currency to enable the greatest shared technology investment in history.

Growing an ecosystem around a project takes more than just a license. Building a project that scales requires careful consideration of governance model, leadership, and barriers to collaboration. The benefits to operators and vendors are many, including a means of sharing the investment in non-differentiating functionality, especially when the community will benefit from a common approach. By exposing software issues to a diverse community, open source development achieves solutions faster, with higher quality and security, and greater buy-in than any single contributor can attain. Community supported open source software also provides an escrow function that enables code to be maintained even when individual contributors are no longer able to sustain the work.

Open source projects take many forms:

•Components- Projects that address a narrowly defined problem whose output may be consumed as an atomic entity. Examples: OpenvSwitch (OVS, virtual switch), a platform plug-in to integrate new hardware or software.

•Platforms- Projects whose scope encompasses multiple components to yield a framework that can be adapted to meet a range of different user needs. Examples: OpenDaylight (SDN Controller Framework; Open Network Automation Platform (ONAP) open orchestration framework); and OpenStack (NFV Virtualized Infrastructure Manager).

•Open Reference Platforms- Projects that focus on the integration of platforms and components, and are primarily used to test, demonstrate, and validate broader solutions. Examples: OPNFV NFV reference platform and MEF OpenLSO reference platform.

The International Telecommunications Union Telecommunications Standardization sector (ITUI-T) mission statement is representative of the primary goals for many SDOs:

“…to foster the development and use of interoperable, non-discriminatory and demand-driven international standards that are based on openness and take into account the needs of users, in order to create an environment where users can access affordable services worldwide regardless of underlying technology, …”

Harmonization White Paper12

Open source development shares many overlapping benefits: multi-vendor interoperability up and down the communications stack, a collaborative decision-making process, and innovation in a vendor-neutral environment. By blending end-user use cases, reference architectures, testing and certification programs, and rigor traditionally provided by SDOs, a new model for standardization will be forged.

Operators are also seeking to leverage open source for additional business advantages. First and foremost is agility, the key benefit of SDN/NFV. In addition, operators are seeking to influence the outcomes and priorities, through contributing use cases, functional requirements, and feedback on development plans. Through closer engagement, operators may be able to tip the balance from vendors, reducing lock-in, which in turn allows greater differentiation.

Another challenge confronting operators is increased up front investments to sustain open source momentum. Typical fees to become a member in prominent open source projects exceeds the fees for SDOs, because of the significant expenses required to support the development infrastructure, community building, promotion, and management of the project.

In addition, in order to attain a sustainable open source community, operators must invest in the vendors who contribute the majority of developers for large-scale projects. While operators stand to benefit tremendously from open source, all in the community must benefit to fuel a sustainable advantage. That necessitates that greater investment in the innovators come from established vendors and startups alike. Without economic motivation, it becomes increasingly difficult to justify vendor investment in open source projects. All must benefit for the open ecosystem to thrive.

Finally, open source paves the way for operators to elevate their internal transformation efforts to evolve their processes, people, and organization from ops-driven to software-driven. Operations tasks become more analogous to software systems administration with programming of VNF configurations, service and policy configurations, CI/CD test configurations, and virtualization of traditional BSS/OSS (as microservices). This will require a rethinking of the organizational structure from the top down, definition of new job descriptions, significant overhauling of operational processes leveraging automation, and training. Deutsche Telekom proclaimed their goal is to become a ‘Software Defined Operator.’

Harmonization White Paper13

HarmonizationAndrew Tannenbaum, author of the classic Computer Networks text, was credited with the quote: “The nice thing about standards is that you have so many to choose from.” It has never been more relevant than today.

With dozens of networking and telecommunications SDOs supporting hundreds of projects, and thousands of standards, and an exponential increase in open source projects (see Figure 2), it is not a mystery why operators and vendors find it so difficult to participate.

Mill

ions

60

50

40

30

20

10

02008 2010 2012 2014 2016 2017

Figure 2- Projects hosted by GitHub since its formation. Source: GitHub 2016

The open movement in telecommunications and networking has created the need for an umbrella architecture harmonizes the multitude of standards and open source projects. The primary goal is to facilitate development of solutions that incorporate multiple open source components and platforms that must conform to a range of standards. Another is to only standardize when necessary. Adoption of common code better ensures interoperability, and further reduces the risk of vendor lock-in.

Harmonization encompasses a number of aspects that affect both standardization and open source:

•Ease of integration through well-defined information models, APIs, and interfaces• Common development environment to make it easier to integrate and test the

components in a highly automated manner• Close coordination among the activities, to align based on use cases, functional

requirements, schedules, etc.• Facilitate participation in the activities

Harmonization White Paper14

•Coordination to streamline exchange of information including IPR, governance, licensing, etc.•Overall simplification

The Linux Foundation, which maintains numerous open source projects, has been cooperating with operators, vendors, SDOs and open source projects, among others to forge a unified open architecture for Networking and Orchestration project, as indicated below. The architecture is intended to clarify how the many OS-N&O projects and standards relate to one another, and offer a starting point for much broader harmonization.

Figure 3 below introduces a high-level OS-N&O architecture, which maps standards, open source projects, and open reference architectures.

Figure 3- Unified Open Networking & Orchestration Architecture

Unified Open Networking & Orchestration Architecture three communications layers, the reference architectures that define high-level functionality: open source reference platforms that are used to integrate, validate, test, and demonstrate open source building blocks, and the standards that specify functional requirements to achieve multi-vendor interoperability, testing methods, and integration points.

Table I describes the architecture elements in additional detail, including the mapping of standards and open source into the communications layers.

Harmonization White Paper15

Layer Description Standard(s) Open Source Projects

Orchestration & Service

Enable end-to-end composite services

MEF LSO

TMForum ZOOM

ITU-T

ONAP (Open Orchestrator)

PNDA (Network Analytics Platform)

ARIA (TOSCA enablement)

Control and Management

Provide network control and management (NFV, SDN, and legacy networks)

NFV MANO

IETF Routing

IETF (many)

ONF (OpenFlow)

OpenDaylight (SDN Controller);

OpenSwitch (Whitebox NOS)

JuJu (NFV G-VNFM)

OpenStack (NFV VIM)

Infrastructure Provide Network Data Plane and NFV Infrastructure

ETSI NFV-I

IEEE 802

3GPP

OIF

OpenvSwitch (virtual switch)

FD.io (data plane acceleration);

DPDK (fast packet processing)

KVM (Hypervisor)

Table I- Unified Open Networking & Orchestration Architecture Description

The unified architecture sets the stage for an industry-wide dialogue on harmonization to achieve the benefits stated in a previous section. Figure 4 depicts the high-level goals for harmonization that are already under consideration by The Linux Foundation, among many other SDOs and open source communities.

Unified vision/terminology

Adopt commonprocesses

Phase II

Platform/componentintegration

Phase IIIPhase I

Figure 4- Harmonization Goals

Harmonization is predicated upon a new degree of collaboration and introspection to thoroughly assimilate open source into the standards process and SDOs. Such an ambitious goal will not be attained overnight, but there are steps that have already been taken to encourage progress:

1. Communications, communications, communications to resolve the cultural differences between standards and open source, with a focus on convergence

2. Multi-SDO/open source activities, such as the Information Modeling initiative involving TMForum, ONF, ETSI NFV, OPNFV, OSM and OPNFV, among others

3. Less formality and renewed attention on definitive outcomes

4. Cooperation on a revised technology adoption methodology that blends standards, open source, operator-contributed use cases, and vendor-technical contributions

Harmonization White Paper16

While there appears to be growing support in the SDN/NFV standards/open source community, along with traditional SDOs, the path to harmonization must address a particularly important set of business factors, including resolving the legal, IPR, licensing, and governance.

The Linux Foundation advocates an open model that encourages collaboration, discourages any individual organization from dominating the process, and is as inclusive as possible. This requires both SDOs and open source projects to recognize the value that each brings to the end-users that have the most to gain from a new model for open standards. In order to achieve the ultimate goal of adoption and market validation, we recommend an end-user oriented approach, where the focus is on satisfying a range of end-user needs, and establishment of an open ecosystem where many in the value chain benefit.

When technology consumers are offered certified products and solutions, it does not matter whether the certification was achieved through rigorous specifications, open source platforms, certification testing or a combination. In addition, converged, vendor-neutral open components and platforms shift the focus on value delivery from frameworks to proprietary VNFs and applications where vendors may innovate to deliver significant value.

We envision a model where end-users articulate their needs early in the process, through use case definition and high-level priorities. These in turn enable creation of open reference architectures to scope the functionality required to address the requirements. Reference architectures will spawn a series of open source projects and platforms, and channel critical mass to avoid unnecessary proliferation of solutions. And of course iteration based on real-world data and experience is essential towards realizing this vision.

Harmonization White Paper17

SummarySDN and NFV represents one of the most significant shifts in networking in decades, accompanied by an unprecedented shift from hardware-centric to software-driven architectures. Such a change not only results in new technologies, but automated operations, dynamic business models, and software-driven organizations.

The debate over whether Standards or Open Source will prevail, is replaced with how open source can evolve networking technology adoption. As Agile replaces Waterfall in Development, the industry is on a trajectory towards automating today’s manual centric operations, with an ultimate target of DevOps. Embedded software in the lower layers, and monolithic solutions for the Operational Support Systems (OSS), are already being replaced by highly agile and programmable platforms that embrace open source and collaborative development.

SDOs are leveraging their extensive operational expertise to evolve their role, developing use cases and reference architectures, while already forging closer links to open source communities, and when appropriate creating new ones. In addition to creating new standards, SDOs are developing use cases and reference architectures that open source projects are aligning their plans with to validate end-user requirements and priorities.

Harmonizing open source and standards paves the way to the long-anticipated convergence. Such melding will not happen overnight, as many issues must be addressed. A phased approach is a prudent plan, starting with the vision, and then unifying processes on the road to an integrated architecture.

The Linux Foundation is actively engaged in aligning its rapidly growing portfolio of Networking and Orchestration projects, which span the entire stack, in collaboration with leading SDOs. Our goal is to engage more closely with key operators and SDOs to ensure our projects are directed towards the greater good. Along the way, we intend to resolve the major differences, including the legal/IPR discrepancies necessary to realize our vision of collaborative innovation to enable the entire industry to benefit from the greatest shared technology investment that is transforming one of society’s most important industries.

Acknowledgements

The Linux Foundation gratefully acknowledges review comments from:Steven Wright, former Chair, ETSI NFV ISG and Chair, OPNFV Advisor’s Group (AT&T)Thomas Li, Director, Standardization and Industry Development (Huawei)Pascal Menezes, MEF CTODavid Marr, Vice President, Legal (Qualcomm)

Any comments from the community should be directed to:Marc Cohn, Editor | The Linux Foundation | mcohn@linuxfoundation.org

Harmonization White Paper18

Appendix I

Acroynms

BSS- Business Support Systems

CI/CD- Continuous Integration / Continuous Deployment

DPDK- Data Plane Developer Kit

ETSI- European Telecommunications Standards Institute

G-VNFM- (NFV) Generic VNF Manager

IETF- Internet Engineering Task Force

ITU-T- International Telecommunications Union Standardization Section

LF- Linux Foundation

LSO- (MEF) LifeCycle Services Orchestration

MANO- (NFV) Management and Orchestration

NFV- (NFV) Network Functions Virtualization

ONAP- Open Networking Automation Platform

ONF- Open Networking Foundation

ONOS- (ON.LAB) Open Network Operating System

OPEN-O- (LF) Open Orchestrator Project

OPNFV- (LF) Open Platform for NFV Project

OS N&O- (LF) Open Source Network and Orchestration

OSS- Operational Support System

SDN- Software Defined Networking

SDO- Standards Development Organization

VIM- (NFV) Virtualization Infrastructure Manager

VNF- (NFV) Virtualized Network Function

Harmonization White Paper19

Appendix II

SDN/NFV SDOs & Open Source Projects

SDOs

3GPP- SDO devoted to telecommunications mobile services/platforms

ETSI NFV ISG- European Telecommunications Standards Institute Network Functions Virtualization Industry Specification Group (ISG)

IETF- Internet Engineering Task Force

ITU-T- International Telecommunications Union Standardization Section

MEF- Telecommunications SDO focused on Carrier Ethernet and Orchestration

TOSCA- (OASIS) Topology and Orchestration Specification for Cloud Applications

ONF- SDN SDO & Industry Group

TMForum- Telecommunications SDO focused on services

Open Source Projects

ARIA- TOSCA enablement

DPDK- Packet Processing acceleration

ECOMP- Enhanced Control, Orchestration, Management, and Policy

FD.IO- (LF) Fast Data I/O

JuJu- Open VNFM

ONAP- (LF) Open Networking Automation Platform

ONOS- (ON.LAB) Open Network Operating System SDN Controller

OpenDaylight- (LF) SDN Controller Framework

OPEN-O- (LF) Open Orchestrator

OpenLSO- (MEF) SDN open source reference platform aligned with LSO

OpenStack- Cloud Management

OpenSwitch- (LF) Open Network Operating System for Whitebox Switches

OPNFV (LF) Open Reference Platform for NFV

OSM- (ETSI) Open Source MANO

PNDA- (LF) Platform for Data Network Analytics

The Linux Foundation promotes, protects and standardizes Linux by providing unified resources and services needed for open source to successfully compete with closed platforms.

To learn more about The Linux Foundation or our other initiatives please visit us at www.linuxfoundation.org