The Board of Directors of OPNFV has set in place the following policies to govern the operation of the Technical Steering Committee (TSC). These policies relate to release processes, technical scope, business goals, etc. The TSC will, to the best of its ability, adhere to these policies. In cases where the TSC makes a judgment that the goals of OPNFV are better served by making exceptions to these policies, it is expected that the TSC will communicate these exceptions and indicate their reasons to the Board at the next Board meeting.

The following relate to the projects initiated by the TSC and the artifacts created therein.

• Singularity: To the extent possible, there should be no overlap between the significant functions of the projects at the integration state.
• Cohesiveness: The artifacts created within each project at the integration state should connect appropriately to other integration state projects to form a cohesive system. It is understood that this will not apply to artifacts that are stand-alone by design.
• Non-interference: The artifacts created should work in any configuration and not create negative interference with each other’s functionality.

The following relate to the choice of projects, assignments of tasks and delivery of code.

• Simultaneous Release: The TSC is responsible for organizing a simultaneous release of appropriate projects at regular intervals.

The following relate to the operation of the TSC.

• Communication: All communication between and within projects will be in a fair, open and consistent fashion.
• Openness: The TSC should ensure that all technical decisions are made in an open and transparent fashion.

The TSC will review projects based on their scope in accordance with the overall purpose of OPNFV as defined in the bylaws (see section 1.4 of the bylaws). Projects may focus on any of the ETSI NFV architecture functional blocks, reference points, supporting tools and infrastructure.

The ETSI Framework is provided here for reference:

[insert block diagram]

Functional blocks of interest include (but are not limited to):

• Virtualised Infrastructure Manager (VIM)
• Network Functions Virtualisation Infrastructure (NFVI)
• Virtual Network Function Managers (VNFM)
• Orchestrators
• Virtual Network Functions (VNF) and associated Element Management Systems (EM)
• Service, VNF, and Infrastructure Description
• Operations Support System (OSS) / Business Support System (BSS)
• Service Assurance Systems

The associated reference points are:

• Vi-Ha: The reference point between the Virtualisation Layer and the hardware resources i.e. Computing Hardware, Storage Hardware and Networking Hardware
• Vn-Nf: The reference point between NFVI and a Virtualised Network Function (VNF)
• Or-Vnfm: The reference point between the Orchestrator and a VNFM
• Vi-Vnfm: The reference point between a VNFM and the VIM
• Or-Vi: The reference point between the Orchestrator and the VIM
• Nf-Vi: The reference point between the VIM and the NFVI
• Os-Ma: The reference point between a consumer-side OSS/BSS and the Management and Orchestration
• Ve-Vnfm: The reference point between the VNF/EMS and a VNFM

Additional details about architecture, functional blocks and reference points can be found in the ETSI NFV Architectural Framework [1]. Note that some of the functional blocks may be further decomposed if required, while still staying within the overall ETSI NFV architectural framework.

[1] ETSI GS NFV 002 v1.2.1, Network Functions Virtualisation; Architectural Framework, https://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.02.01_60/gs_NFV002v010201p.pdf

Related Documents:

TSC Charter

OPNFV Project Lifecycle