Gliffy Diagram | ||||
---|---|---|---|---|
|
Gliffy Diagram | ||||
---|---|---|---|---|
|
Table of Contents |
---|
The ETSI-based CNF support is conforming to IFA 011, IFA029 and IFA040. Based on the ETSI specification progresses, we plan to apply necessary changes.
Mission Statement
- TBD
Benefits
- TBD
ETSI NFV Team's Modeling Challenges
- Mapping VNF-Descriptor to SDC AID DM?
- How to identify Pods in AAI?
- Package multiple NFs into a single CNF and manage them independent from each other. (Deployment flavors, aspects, …)
- Building an NF which spans multiple CNFs. The single CNF would not necessarily be a self-sufficient entity anymore. (Network Services)
- CI/CD based upgrades of microservices within a CNF. (ChangeVnfPackage)
ONAP ETSI-Alignment Overall Architecture (Various Options)
Gliffy Diagram macroId 51fb53a3-23cd-4be3-b8f2-f536ec8752ae name ONAP ETSI SDO for VNF-CNF pagePin 12
Configuration Sequence
20
Model-Driven Orchestration (various options)
- SO supports dual CNF support: one is the CNF direct leveraging K8S Adapter, K8S Plugin (in MultiCloud) path and one is the ETSI-Alignment path, leveraging SOL005 Adatper, NFVO, SOL003 Adapter and VNFM.
- SDC supports a common onboarding mechanism for both CNF paths
Gliffy Diagram name ONAP ETSI CNF Orchestration - Model Driven - Honolulu pagePin 2
Possible O-RAN connection Architecture (Stretch goal for Honolulu)
Gliffy Diagram macroId 818d4c33-f30e-4ef5-9369-feb7a4edbf2f name ONAP ETSI-ORAN CNF Orchestration - Honolulu pagePin 22
Generic CNF Adapter Architecture (Future Consideration)
Gliffy Diagram macroId a0ae48ef-6549-4356-ba20-7afaa80a17f3 name ONAP ETSI GCNFM Architecture pagePin 8
Pipeline Diagram
Gliffy Diagram | ||||
---|---|---|---|---|
|
Configuration Sequence
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant Service_Designer
participant SDC
participant ETSI_Catalog_Manager
participant MultiCloud
participant CDS
participant OSS_BSS
participant SO
participant SO_NFVO
participant CI
participant SDNC
participant VNFM
participant VNF
participant CNF
autonumber
group Design Time
Service_Designer -> CDS : Design CBA
Service_Designer -> SDC : Attach CBA to SDC Service CSAR
SDC -> ETSI_Catalog_Manager : Distribute ETSI packages
SDC -> SDNC : Distribute SDC Catalog
SDC -> MultiCloud : Distribute SDC Catalog
end
group Run Time - Instantiation
OSS_BSS -> SO : Request Instantiate
SO -> SDNC : Get Resource Assignment
SDNC -> CDS: Get resource assignment
SO | ||
PlantUML Macro | ||
| ||
@startuml participant OSS_BSS participant SO participant SO_NFVO participant Service_Designer participant CDS participant SDC participant ETSI_Catalog_Manager participant CIR participant SDNC participant MultiCloud participant VNFM participant VNF participant CNF autonumber group Design Time Service_Designer -> CDS : Design CBA Service_Designer -> SDC : Attach CBA to SDC Service CSAR SDC -> ETSI_Catalog_Manager : Distribute ETSI packages SDC -> SDNC : Distribute SDC Catalog SDC -> MultiCloud : Distribute SDC Catalog end group Run Time OSS_BSS -> SO : Configuration Request SO -> SO_NFVO : Configuration Request thru SOL005 SO_NFVO -> SDNC : Get Controller LCM / Blueprint opt Configuration A SDNC -> VNF : Configuration Request thru NetConf SDNC -> CNF : Configuration Request thru NetConf SDNC -> SO_NFVO : Configuration Response end opt Configuration B SO_NFVO -> VNFM : Request thru SOL003 VNFM -> VNF : Configuration Request\nthru Ve-Vnfm VNFM -> CNF : Configuration Request\nthru Ve-Vnfm VNFM -> SO_NFVO : Configuration Response end Request thru SOL005 (with instantiation parameter values) SO_NFVO -> SOVNFM : Configuration Response SO Request thru SOL003 (with instantiation parameter values) VNFM -> SO_NFVO : Request Grant CNF/VNF Resources SO_NFVO -> OSS_BSSVNFM : Grant ConfigurationCNF/VNF ResponseResources end @enduml |
PoC Configuration Sequence
PlantUML Macro | ||
---|---|---|
| ||
@startuml participant OSS_BSS participant SO participant Service_Designer participant CDS participant SDC participant ETSI_Catalog_Manager participant CIR participant SDNC participant VNF participant CNF autonumber group Design Time Service_Designer -> CDS : Design CBA Service_Designer -> SDC : Attach CBA to SDC Service CSAR SDC -> ETSI_Catalog_Manager : Distribute ETSI packages SDC -> SDNC : Distribute SDC Catalog end group Run Time Instantiation alt CNF VNFM -> CISM : CNF instantiation request else VNF VNFM -> VIM : VNF instantiation request end VNFM -> SO_NFVO : Instantiate Successful SO_NFVO -> SO : Instantiate Successful SO -> OSS_BSS : Instantiation Successful end group Run Time - Post Instantiation opt Configuration A OSS_BSS -> SO : Instantiation Request SO -> SDNC : Configuration Request SDNC Configure SO->SO_NFVO : Request ModifyVNFInfo thru SOL005 SO_NFVO -> CDS_SS : Get resource assignment and stores it to its MDSALConfig-Assign action\n for saving CNF/VNF day-1 config SO_NFVO -> SOL003CDS_AdapterBP : Invoke SOL003 Adapter\nfor InstantiationConfig-Deploy action\n for CNF/VNF config SOL003CDS_AdapterBP --> VNFMCDS_BP : InvokeRead VNFM\nfor Instantiation end group Run Time Post-Instantiationconfig from DB OSSCDS_BSSBP -> SOSDNC : Invoke Post-InstantiationSDNC RequestODL SO -> CDS : Config-Assign Request SO -> CDS : Config-Deploy Request end @enduml |
Simplified Option (TBD)
Gliffy Diagram macroId 1504608b-3a13-44c6-82b0-8dc4cb105d57 name ONAP ETSI SDO for VNF-CNF simplified pagePin 5
macroId | 1504608b-3a13-44c6-82b0-8dc4cb105d57 |
---|---|
name | ONAP ETSI SDO for VNF-CNF simplified |
pagePin | 5 |
ETSI-Based CNF Orchestration Architecture
- Hybrid orchestration templates – TOSCA VNFD and Helm Charts (MCIO)
- TOSCA VNFD drives the interaction between NFVO and VNFM and NS/VNF LCMs
- Helm Charts are included as a binary archive in the VNF package, and are consumed by VNFM
- Container images are either included in the VNF package or referenced in the descriptors (URL to CIR)
- If the VNF package includes Container images, NFVO/ETSI Catalog Manager uploads them to the CIR
- Otherwise, operators store Container images to the CIR
- Parameter mapping from Or-Vnfm (SOL003) incoming information to Helm input parameters
- Resource Mapping between resources in TOSCA VNFD and K8S resources described in Helm chart (for granting between VNFM and NFVO)
- Mapping the LCM operations to HELM commands (VNFM behavior triggered on Or-Vnfm), etc.
- VNFM-K8S communication prefers Helm APIs to lower level K8S APIs
- K8S-VIM communication uses de facto open source standards (Nova/Cinder/Neutron/Keystone/Octavia)
- CISM-CIS communication uses de facto open source standards
- It leverages the ONAP ETSI-Alignment Architecture.
The following diagram depicts ETSI-based CNF orchestration architecture.
alt CNF
SDNC -> CNF: push config
else VNF
SDNC -> VNF: push config
end
SO_NFVO -> SO : Configuration Successful
SO -> OSS_BSS : Configuration Successful
end
opt Configuration B
OSS_BSS -> SO : Request Configure
SO->SO_NFVO : Request ModifyVNFInfo\nthru SOL005
SO_NFVO -> VNFM : Request ModifyVNFInfo\nthru SOL003
alt VNF
VNFM -> VNF : Configuration Request\nthru Ve-Vnfm
else CNF
VNFM -> CNF : Configuration Request\nthru Ve-Vnfm
end
VNFM -> SO_NFVO : Configuration Response
SO_NFVO -> SO : Configuration Successful
SO -> OSS_BSS : Configuration Successful
end
opt Configuration C
OSS_BSS -> SO : Request Configure
SO -> CDS_SS : Config-Assign action\n for saving CNF/VNF day-1 config
SO -> CDS_BP : Config-Deploy action\n for CNF config
CDS_BP --> CDS_BP : Read config from DB
CDS_BP -> SDNC : Invoke SDNC ODL
alt CNF
SDNC -> CNF: push config
else VNF
SDNC -> VNF: push config
end
SO -> OSS_BSS : Configuration Successful
end
end
@enduml |
PoC Configuration Sequence
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant OSS_BSS
participant SO
participant Service_Designer
participant CDS_SS
participant CDS_BP
participant SDC
participant ETSI_Catalog_Manager
participant CIR
participant SDNC
participant VNF
participant CNF
autonumber
group Design Time
Service_Designer -> CDS : Design CBA
Service_Designer -> SDC : Attach CBA to SDC Service CSAR
SDC -> ETSI_Catalog_Manager : Distribute ETSI packages
SDC -> SDNC : Distribute SDC Catalog
end
group Run Time Instantiation
OSS_BSS -> SO : Instantiation Request
SO -> SDNC : Instantiation Request
SDNC -> CDS : request resource resolution
CDS -> SDNC : response resource resolution
SDNC -> SO : response resource resolution
SO -> SOL003_Adapter : Invoke SOL003 Adapter\nfor Instantiation
SOL003_Adapter -> VNFM : Invoke VNFM\nfor Instantiation
end
group Run Time Post-Instantiation
OSS_BSS -> SO : Post-Instantiation Request
SO -> CDS_SS : Config-Assign action\n for saving CNF day-1 config
CDS_SS -> SO : response for Config-Assign\n action
SO -> CDS_BP : Config-Deploy action\n for CNF config
CDS_BP --> CDS_BP : Read config from DB
CDS_BP -> SDNC : Invoke SDNC ODL
SDNC -> CNF: push config
end
@enduml |
Simplified Option (TBD)
Gliffy Diagram macroId 1504608b-3a13-44c6-82b0-8dc4cb105d57 name ONAP ETSI SDO for VNF-CNF simplified pagePin 6
macroId | 1504608b-3a13-44c6-82b0-8dc4cb105d57 |
---|---|
name | ONAP ETSI SDO for VNF-CNF simplified |
pagePin | 6 |
ETSI-Based CNF Orchestration Architecture
- Hybrid orchestration templates – TOSCA VNFD and Helm Charts (MCIO)
- TOSCA VNFD drives the interaction between NFVO and VNFM and NS/VNF LCMs
- Helm Charts are included as a binary archive in the VNF package, and are consumed by VNFM
- Container images are either included in the VNF package or referenced in the descriptors (URL to CIR)
- If the VNF package includes Container images, NFVO/ETSI Catalog Manager uploads them to the CIR
- Otherwise, operators store Container images to the CIR
- Parameter mapping from Or-Vnfm (SOL003) incoming information to Helm input parameters
- Resource Mapping between resources in TOSCA VNFD and K8S resources described in Helm chart (for granting between VNFM and NFVO)
- Mapping the LCM operations to HELM commands (VNFM behavior triggered on Or-Vnfm), etc.
- VNFM-K8S communication prefers Helm APIs to lower level K8S APIs
- K8S-VIM communication uses de facto open source standards (Nova/Cinder/Neutron/Keystone/Octavia)
- CISM-CIS communication uses de facto open source standards
- It leverages the ONAP ETSI-Alignment Architecture.
The following diagram depicts ETSI-based CNF orchestration architecture.
Gliffy Diagram | ||||
---|---|---|---|---|
|
ETSI-Based Network Slicing
The following diagram depicts how Network Slicing components interact with ETSI-realized components.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
ONAP-based Slice Management Overall Architecture Choices
Gliffy Diagram macroId 67b91b9b-8a86-4a11-92d7-cfd5b09fe8b1 name ONAP Slice Management Architecture Choices pagePin 3
Core NSSMF in ONAP
Gliffy Diagram macroId 958daf77-8d9f-496d-9f85-3cd79dd8f5b0 name ETSI Network Slicing Support pagePin 6
TSCi DM Use in ONAP
Gliffy Diagram macroId 9c51fadf-b8e7-46c1-9485-1305071fee4c name ETSI TSCi Data Model pagePin 1 Gliffy Diagram
CNF Package Onboarding and Distribution
The following diagram depicts CNF package onboarding and distribution.
...
- SDC preserves the SOL004 VNF Packages in the Onboarded_Package directory of SDC Resource CSAR
- SDC Service CSAR including SDC Resource CSAR(s) is distributed to ONAP Runtime components: SO, AAI, VID and others
- ETSI Catalog Manager extracts the SOL004 VNF Packages from SDC CSAR and stores in its Database
- In Guilin, ETSI Catalog Manager will subscribe to the SDC notification topic and receives SDC CSARs.
- If VNF Package contains Container Images, ETSI Catalog Manager pushes the images to Container Image Repository
- According to IFA011, NFVO extracts the OS container images and the MCIOPs and store them in respective repositories.
- In ONAP, ETSI Catalog Manager will pushes the images to CIR, on behalf of NFVO.
- <note: it is under discussion that ETSI Catalog Manager pushes the helm charts from the CSAR to a MANO local helm charts repository if we use the helm charts repository>
- SOL003 Adapter gets SOL004 VNF packages from ETSI Catalog Manager
- SOL003 Adapter sends SOL004 VNF packages to sVNFMs
- Optionally, if operators use local CIRs, VNFM can push the Container Images to the local CIRs.
- SVNFMs invokes K8S CISM for CNF operations
- K8S CISM pulls Container Images from the CIR
CNF Orchestration Sequences
The following depicts the CNF Orchestration sequences.
...
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant OSS_BSS
participant SO
participant SO_NFVO
participant ETSI_Catalog_Mgr
participant SOL003_Adapter
participant VNFM
participant CISM
participant CIR
participant CIS
autonumber
hnote over VNFM, CISM : CNF Orchestration
OSS_BSS -> SO : E2E Service requests, including CNF
SO -> SO_NFVO : Network Service requests, including CNF
SO_NFVO -> ETSI_Catalog_Mgr : retrieve NS Descriptor
SO_NFVO -> SOL003_Adapter : VNF/CNF requests
SOL003_Adapter -> ETSI_Catalog_Mgr : retrieve VNF packages, including Helm Charts
SOL003_Adapter -> VNFM : VNF / CNF requests
VNFM -> CISM : CNF requests
CISM -> CIR : pull Container Images
CISM -> CIS : CNF resource management
@enduml |
CNF Models
- Conforms to ETSI IFA 011, 029 and 040.
- Those specifications would be available by end of June / July 2020, but their SOL specifications plan to be available by end of 2020 or Q1, 2021.
- Until then, ONAP designs CNF models and packages, based on the current IFA 029 and 040 (it is an assumption).
- A Managed Container Infrastructure Object (MCIO) is an abstract NFV object for OS Container management and orchestration.
- The declarative MCIO descriptor is used as descriptor object interpreted by the CISM.
- A MCIO is created by the CISM by allocating its requested infrastructure resources on Container Infrastructure Service (CIS) instances
- Depending on its type, the creation of a MCIO may include the deployment of an OS Container Image.
- MCIO’s are lifecycle managed via change requests on their desired state, utilizing a modified declarative descriptor sent to the CISM, which adapts the
- infrastructure resource allocations according to the changed infrastructure resource requests.
- MCIO’s requesting compute and/or storage infrastructure resources are modeled as a VNF Component (VNFC).
- Properties of an MCIO described in declarative descriptors and relevant being exposed to NFV-MANO are mirrored in attributes of the descriptors of the corresponding objects of the existing NFV-MANO information model.
<Source: IFA 040>
- SDC enhancements to understand and parse new IFA 011 VNFD
- AAI enhancements to represent VNF instance inventories, based on IFA 011
- NFVO/VNFM enhancements to handle new NS/VNF models and packages
ETSI VNFD and VDU Changes for CNF
- Conforms to new ETSI IFA 011.
- ETSI NFV Team Discussions and Resolutions:
- VNFD enables the modelling of MCIOs (e.g., Kubernetes Pods) as VDU and introduces a new IE OsContainerDesc.
- A VNF could consist of VM-based and/or container-based components (hybrid VNF) – at least one of them
- The relationship between the NFV abstract objects and their relationship have been described in IFA 040 (clause 5.3)
- Changes due to differences between networking in VM-s and in pods shall be investigated
- The properties of MCIOs specifying networking resource requests can be modeled as CPs or derived classes and their properties are specified in CPDs or derived types in the VNFD
- Each reference of an identifier of an OsContainerDesc is unique; each OsContainerDesc is only referenced once in a VDU. This is in alignment with the Kubernetes PodSpec
- No hybrid VNFCs shall be allowed
- intCpd attribute of the VDU information element is changed from 1..N to 0..N.
- VNFD Note 6: Either the virtualComputeDesc or the osContainerDesc shall contain at lease one element
- VDU Note 5: Only one of virtualComputeDesc or osContainerDesc shall be part of a Vdu. If the Vdu includes osContainerDesc, then bootOrder, swImageDesc, monitoringParameter and bootData shall not be present in the Vdu.
- The following tables depicts the changes in the VNFD and VDU attributes:
MCIOP Profile Changes
- Reason for change:
- An important object which is to be included in the VNF package is the MCIOP. The MCIOP needs to be identified in the VNF package, but also additional properties of the MCIOP are required to be specified.
- This information related to the MCIOP needs to be provided via a dedicated profile information element for the MCIOP.
- Change:
- Add a descriptor information element for a MCIOP profile to the VnfDf.
- Enhance the scope attribute of the AffinityOrAntiAffinityGroup information element with a new scope type “container-namespace”.
- The “container-namespace” scope is used to express the affinity or anti-affinity relationship between containerized workloads which are deployed based on a MCIOP.
- A Managed Container Infrastructure Object Package (MCIOP) is a hierarchical aggregate of information objects for OS container management and orchestration.
- Multiple MCIOPs can be included in a VNF Package.
- The MciopProfile information element provides properties of the MCIOP which are used during deployment of containerized workloads based on a MCIOP, associated to a VNF deployment flavor.
OsContainerDesc
- The OsContainerDesc information element describes the members properties of a set of co-located container compute resources when these are realizing a VDU.
- OsContainerDesc Attributes are defined
VDU Deployment View
The following diagram depicts a VDU deployment view.
SwImageDesc Attributes
- It describes the software image for a “particular” VM-based VDU, OS Container or a virtual storage resource
- The diskFormat and minDisk are optional for the case that the software images are referenced by non VM-based VDU (i.e., container-based VDU)
VirtualStorageDesc Attributes
- Reason for change:
- The current solution for persistent virtual storage resources in the VNFD is that they are:
- Referenced in the VDU
- Instantiated per VNFC instance, i.e. for each VNFC instance created based on the VDU, a dedicated virtual storage instance is created and attached to the VNFC instance. Such storage instance also has a lifetime coupled to the VNFC lifetime.
- The current solution does not allow to have persistent virtual storage instances that are not per VNFC and have their own lifetime.
- Change:
- Enhance the VirtualStorageDesc with an attribute to indicate if the block/file/object storage resource templates shall be used as template for all VNFC instances (current semantic), or if they shall be created only once (new semantic).
VNF Lifecycle Operation Granting
- VNF Lifecycle Operation Granting interface produced by the NFVO on the Or-Vnfm reference point shall support granting lifecycle operations
- Changes for CNF: the VNF Lifecycle Operation Granting interface produced by the NFVO on the Or-Vnfm reference point shall enable the VNFM
- to indicate the virtualized resources or namespace quota (when the VDUs of the VNF are realized by a set of OS containers) impacted by the VNF lifecycle operation (e.g., allocated or release)
- obtaining information about the identification and configuration information to access the VIM or CISM
- The Namespace is via the VNF LCM Granting and to include the value of the namespace in the GrantInfo information element as part of the GrantVnfLifecycleOperationResponse.
- Enhance the GrantInfo information element with an additional attribute for a container namespace
CNF Resource Definition for Granting
- The VNFD introduces a new resource template OsContainerDesc for OS containers.
- The ResourceDefinition information element used in the grant request message needs to be enabled to reference resource templates for OS containers, the same way as the other resource template
- Enhance the ResourceDefinition information element attributes with references to OS container resource definition types and resource templates.
- OsContainer Type is added
- Reference to OsContainerDesc is added
IFA 011 411 Draft Proposal addition to VipCpd
- VipCpd in SOL001 2.7.1 describes the mapping of a “virtual IP” address to connection points in a VNF.
- Either HA (Active/Standby) or Load Balancing.
Proposed for 4.1.1
- Use VipCp to model K8S service connectivity (under discussion)
- AdditionalVipData – Expose information about a port and service data
- Name of the VIP (uService)
- L4 Protocol exposed (TCP, UDP, SCTP, )
- Port exposed
- intCpd attribute is optional (changes from 1..N to 0..N)
- Service Data
- L7 info (unspecified in VNF-D)
SOL001 VNFD Mapping to SDC AID DM
- TBD
ONAP Component Requirements
SDC
- TBD
SO
- TBD
SO NFVO
- TBD
SOL003 Adapter
- TBD
ETSI Catalog Manager
- TBD
AAI
Data Modeling
VNFC
VNFC has the 1:1 relationship with MCIO requesting compute/storage resources
- TBD
CP
- CP has the 1:1 relationship with MCIO requesting networking resources
- TBD
VID
- TBD
UUI
- TBD
OOF
- TBD
CIR
resource management
@enduml |
CNF Models
- Conforms to ETSI IFA 011, 029 and 040.
- Those specifications would be available by end of June / July 2020, but their SOL specifications plan to be available by end of 2020 or Q1, 2021.
- Until then, ONAP designs CNF models and packages, based on the current IFA 029 and 040 (it is an assumption).
- A Managed Container Infrastructure Object (MCIO) is an abstract NFV object for OS Container management and orchestration.
- The declarative MCIO descriptor is used as descriptor object interpreted by the CISM.
- A MCIO is created by the CISM by allocating its requested infrastructure resources on Container Infrastructure Service (CIS) instances
- Depending on its type, the creation of a MCIO may include the deployment of an OS Container Image.
- MCIO’s are lifecycle managed via change requests on their desired state, utilizing a modified declarative descriptor sent to the CISM, which adapts the
- infrastructure resource allocations according to the changed infrastructure resource requests.
- MCIO’s requesting compute and/or storage infrastructure resources are modeled as a VNF Component (VNFC).
- Properties of an MCIO described in declarative descriptors and relevant being exposed to NFV-MANO are mirrored in attributes of the descriptors of the corresponding objects of the existing NFV-MANO information model.
<Source: IFA 040>
- SDC enhancements to understand and parse new IFA 011 VNFD
- AAI enhancements to represent VNF instance inventories, based on IFA 011
- NFVO/VNFM enhancements to handle new NS/VNF models and packages
ETSI VNFD and VDU Changes for CNF
- Conforms to new ETSI IFA 011.
- ETSI NFV Team Discussions and Resolutions:
- VNFD enables the modelling of MCIOs (e.g., Kubernetes Pods) as VDU and introduces a new IE OsContainerDesc.
- A VNF could consist of VM-based and/or container-based components (hybrid VNF) – at least one of them
- The relationship between the NFV abstract objects and their relationship have been described in IFA 040 (clause 5.3)
- Changes due to differences between networking in VM-s and in pods shall be investigated
- The properties of MCIOs specifying networking resource requests can be modeled as CPs or derived classes and their properties are specified in CPDs or derived types in the VNFD
- Each reference of an identifier of an OsContainerDesc is unique; each OsContainerDesc is only referenced once in a VDU. This is in alignment with the Kubernetes PodSpec
- No hybrid VNFCs shall be allowed
- intCpd attribute of the VDU information element is changed from 1..N to 0..N.
- VNFD Note 6: Either the virtualComputeDesc or the osContainerDesc shall contain at lease one element
- VDU Note 5: Only one of virtualComputeDesc or osContainerDesc shall be part of a Vdu. If the Vdu includes osContainerDesc, then bootOrder, swImageDesc, monitoringParameter and bootData shall not be present in the Vdu.
- The following tables depicts the changes in the VNFD and VDU attributes:
MCIOP Profile Changes
- Reason for change:
- An important object which is to be included in the VNF package is the MCIOP. The MCIOP needs to be identified in the VNF package, but also additional properties of the MCIOP are required to be specified.
- This information related to the MCIOP needs to be provided via a dedicated profile information element for the MCIOP.
- Change:
- Add a descriptor information element for a MCIOP profile to the VnfDf.
- Enhance the scope attribute of the AffinityOrAntiAffinityGroup information element with a new scope type “container-namespace”.
- The “container-namespace” scope is used to express the affinity or anti-affinity relationship between containerized workloads which are deployed based on a MCIOP.
- A Managed Container Infrastructure Object Package (MCIOP) is a hierarchical aggregate of information objects for OS container management and orchestration.
- Multiple MCIOPs can be included in a VNF Package.
- The MciopProfile information element provides properties of the MCIOP which are used during deployment of containerized workloads based on a MCIOP, associated to a VNF deployment flavor.
OsContainerDesc
- The OsContainerDesc information element describes the members properties of a set of co-located container compute resources when these are realizing a VDU.
- OsContainerDesc Attributes are defined
VDU Deployment View
The following diagram depicts a VDU deployment view.
SwImageDesc Attributes
- It describes the software image for a “particular” VM-based VDU, OS Container or a virtual storage resource
- The diskFormat and minDisk are optional for the case that the software images are referenced by non VM-based VDU (i.e., container-based VDU)
VirtualStorageDesc Attributes
- Reason for change:
- The current solution for persistent virtual storage resources in the VNFD is that they are:
- Referenced in the VDU
- Instantiated per VNFC instance, i.e. for each VNFC instance created based on the VDU, a dedicated virtual storage instance is created and attached to the VNFC instance. Such storage instance also has a lifetime coupled to the VNFC lifetime.
- The current solution does not allow to have persistent virtual storage instances that are not per VNFC and have their own lifetime.
- Change:
- Enhance the VirtualStorageDesc with an attribute to indicate if the block/file/object storage resource templates shall be used as template for all VNFC instances (current semantic), or if they shall be created only once (new semantic).
VNF Lifecycle Operation Granting
- VNF Lifecycle Operation Granting interface produced by the NFVO on the Or-Vnfm reference point shall support granting lifecycle operations
- Changes for CNF: the VNF Lifecycle Operation Granting interface produced by the NFVO on the Or-Vnfm reference point shall enable the VNFM
- to indicate the virtualized resources or namespace quota (when the VDUs of the VNF are realized by a set of OS containers) impacted by the VNF lifecycle operation (e.g., allocated or release)
- obtaining information about the identification and configuration information to access the VIM or CISM
- The Namespace is via the VNF LCM Granting and to include the value of the namespace in the GrantInfo information element as part of the GrantVnfLifecycleOperationResponse.
- Enhance the GrantInfo information element with an additional attribute for a container namespace
CNF Resource Definition for Granting
- The VNFD introduces a new resource template OsContainerDesc for OS containers.
- The ResourceDefinition information element used in the grant request message needs to be enabled to reference resource templates for OS containers, the same way as the other resource template
- Enhance the ResourceDefinition information element attributes with references to OS container resource definition types and resource templates.
- OsContainer Type is added
- Reference to OsContainerDesc is added
IFA 011 411 Draft Proposal addition to VipCpd
- VipCpd in SOL001 2.7.1 describes the mapping of a “virtual IP” address to connection points in a VNF.
- Either HA (Active/Standby) or Load Balancing.
Proposed for 4.1.1
- Use VipCp to model K8S service connectivity (under discussion)
- AdditionalVipData – Expose information about a port and service data
- Name of the VIP (uService)
- L4 Protocol exposed (TCP, UDP, SCTP, )
- Port exposed
- intCpd attribute is optional (changes from 1..N to 0..N)
- Service Data
- L7 info (unspecified in VNF-D)
SOL001 VNFD Mapping to SDC AID DM
- TBD
ONAP Component Requirements
SDC
- TBD
SO
- TBD
SO NFVO
- TBD
SOL003 Adapter
- TBD
ETSI Catalog Manager
- TBD
AAI
Data Modeling
VNFC
VNFC has the 1:1 relationship with MCIO requesting compute/storage resources
- TBD
CP
- CP has the 1:1 relationship with MCIO requesting networking resources
- TBD
VID
- TBD
UUI
- TBD
OOF
- TBD
CIR
- TBD
To be analyzed.
CISM | Kubernetes Manager/master |
CIS | Kubernetes worker node |
MCIO | Pods, Services, Deployments, ReplicaSets, StatefulSets? |
MCIOP | Helm chart? |
container workload management service | Control Plane, workload resources |
containerized workloads | Docker container? |
Compute management service | ? |
compute infrastructure resource | ? Availability Zone |
storage management service | ? |
storage infrastructure resource | PV PVC |
network management service | ? node network |
network infrastructure resource | ? LB? |
configuration management service | ? Config Map |
MCIO configurations | ? |
...