wiki:tsc:tscpolicydraftjan2016
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
wiki:tsc:tscpolicydraftjan2016 [2016/01/29 13:26] Christopher Price created |
wiki:tsc:tscpolicydraftjan2016 [2016/02/09 17:22] (current) Ray Paik [OPNFV TSC Policy] |
||
|---|---|---|---|
| Line 12: | Line 12: | ||
| * **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. | * **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. | * **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. | 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. | * **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. | The following relate to the operation of the TSC. | ||
| Line 26: | Line 22: | ||
| * **Openness**: The TSC should ensure that all technical decisions are made in an open and transparent 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: | ||
| - | OPNFV will support projects focused on the following: | + | [insert block diagram] |
| - | + | ||
| - | Code development | + | Functional blocks of interest include (but are not limited to): |
| - | Requirements | + | * Virtualised Infrastructure Manager (VIM) |
| - | + | * Network Functions Virtualisation Infrastructure (NFVI) | |
| - | Platform Integration & Testing | + | * Virtual Network Function Managers (VNFM) |
| - | Documentation | + | * Orchestrators |
| - | Collaboration with external projects | + | * Virtual Network Functions (VNF) and associated Element Management Systems (EM) |
| - | Other projects that the TSC determines will improve OPNFV | + | * Service, VNF, and Infrastructure Description |
| - | + | * Operations Support System (OSS) / Business Support System (BSS) | |
| - | 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]: | + | * Service Assurance Systems |
| - | + | The associated reference points are: | |
| - | Functional Blocks | + | * 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) | |
| - | Virtualised Infrastructure Manager (VIM) | + | * Or-Vnfm: The reference point between the Orchestrator and a VNFM |
| - | Network Functions Virtualisation Infrastructure (NFVI) | + | * Vi-Vnfm: The reference point between a VNFM and the VIM |
| - | + | * Or-Vi: The reference point between the Orchestrator and the VIM | |
| - | Reference Points | + | * 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 | |
| - | Or-Vi: The reference point in between the Orchestrator and the VIM | + | * Ve-Vnfm: The reference point between the VNF/EMS and a VNFM |
| - | 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 | + | 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. |
| - | 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) | + | [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 |
| - | + | ||
| - | 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: | Related Documents: | ||
| Line 68: | Line 56: | ||
| OPNFV Project Lifecycle | OPNFV Project Lifecycle | ||
| - | |||
wiki/tsc/tscpolicydraftjan2016.1454073991.txt.gz · Last modified: 2016/01/29 13:26 by Christopher Price
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
