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.

OPNFV will support projects focused on the following:

  Code development     
  Requirements

  Platform Integration & Testing
  Documentation
  Collaboration with external projects
  Other projects that the TSC determines will improve OPNFV

The scope of projects chosen by the TSC will focus on the following NFV architecture functional blocks, reference points and tools or infrastructure to support the scope. Additional details about these architecture functional blocks and reference points can be found in the ETSI NFV E2E Architectural Framework [1]:

Functional Blocks

  Virtualised Infrastructure Manager (VIM)
  Network Functions Virtualisation Infrastructure (NFVI)

Reference Points

  Or-Vi: The reference point in between the Orchestrator and the VIM
  Vi-Vnfm: The reference point in between a VNF Manager (VNFM) and the VIM
  Nf-Vi: The reference point in between the VIM and the NFVI
  Vi-Ha: The reference point in between hardware resources i.e. Computing Hardware, Storage Hardware and Networking Hardware, and the Virtualisation Layer
  Vn-Nf: The reference point in between NFVI and a Virtualised Network Function (VNF)

OPNFV does not mandate specific hardware resources as long as the Vi-Ha reference point is supported. OPNFV does not exclude “bare metal,” but will not invest to enhance bare metal implementations.

For the implementation of items in scope listed above, TSC projects will use existing NFV Documents as reference. Implementation items will be prioritized in order to provide focus and enable faster delivery. OPNFV will fill in gaps in existing standard specifications, contribute improvements to upstream Open Source Software (OSS) relevant to the items in scope listed above and if necessary, create new projects to contribute to the standardization process that help the industry achieve the goals of standard NFV architecture.

OPNFV should not be considered as an alternative to formal standardization process. OPNFV and standardization are complementary. Therefore, a stronger coordination of documentation project and standardization development is required.

Reference:

[1] ETSI GS NFV002, V1.1.1; NFV End to End Architecture Framework, http://docbox.etsi.org/ISG/NFV/Open/Published/gs_NFV002v010201p%20-%20Architectural%20Framework.pdf

Related Documents:

TSC Charter

OPNFV Project Lifecycle