NFV

The TM Forum OLM (onboarding and lifecycle management) team under the ZOOM project has been working on Virtual Function (VF) onboarding automation issue for quite some time.  For the new year, we would like to kick off a few discussion threads to make you aware of the work that we have been doing and to get your engagement and inputs as well.

While many standards and open source projects have contributed to the VF onboarding/Lifecycle Management space, the focus of those efforts have been primarily on how to onboard the functional aspects of the VF onto infrastructure environment (compute, storage, network).

Equally important is the operational information of the VF that needs to be provided by vendors to onboard/integrate VFs onto SP operational environment, such as for license/asset management, managing and calculating SLA, how to collect fault management and performance management data of the VF, etc.  These are the type of information that the TM Forum has been focusing on and highlighted in the following picture; we call them non-functional metadata:

• Package ID  (for catalog, asset, and usage right management)
• VF Package Type  (determine its <g class="gr_ gr_208 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="208" data-gr-id="208">orchestratability</g> and level of infrastructure dependencies)
• VF Functional Category (e.g., IMS, firewall, this will help determine associated operations support)
• License information (to support asset management,  vendor/SP revenue scheme, customer billing)
• SLAs (of several different types, e.g., package support for customers, supplier support for updates, etc.)
• Metrics information (mandatory and optional metrics supported by the package)
• Testing information  (test cases, test script, test results including security test results and checksums)

We will follow up with more posts on each of the category in coming weeks.  You can read about this general concept in the IG1141 document (currently available to the TM Forum members only).

We are interested in your view/feedback and if you think of any additional metadata categories that might need to be defined to help facilitate the onboarding automation and lifecycle management for SP operations.

The TM Forum OLM (onboarding and lifecycle management) team under the ZOOM project has been working on Virtual Function (VF) onboarding automation issue for quite some time.  For the new year, we would like to kick off a few discussion threads to make you aware of the work that we have been doing and to get your engagement and inputs as well.

While many standards and open source projects have contributed to the VF onboarding/Lifecycle Management space, the focus of those efforts have been primarily on how to onboard the functional aspects of the VF onto infrastructure environment (compute, storage, network).

Equally important is the operational information of the VF that needs to be provided by vendors to onboard/integrate VFs onto SP operational environment, such as for license/asset management, managing and calculating SLA, how to collect fault management and performance management data of the VF, etc.  These are the type of information that the TM Forum has been focusing on and highlighted in the following picture; we call them non-functional metadata:

• Package ID  (for catalog, asset, and usage right management)
• VF Package Type  (determine its <g class="gr_ gr_208 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="208" data-gr-id="208">orchestratability</g> and level of infrastructure dependencies)
• VF Functional Category (e.g., IMS, firewall, this will help determine associated operations support)
• License information (to support asset management,  vendor/SP revenue scheme, customer billing)
• SLAs (of several different types, e.g., package support for customers, supplier support for updates, etc.)
• Metrics information (mandatory and optional metrics supported by the package)
• Testing information  (test cases, test script, test results including security test results and checksums)

We will follow up with more posts on each of the category in coming weeks.  You can read about this general concept in the IG1141 document (currently available to the TM Forum members only).

We are interested in your view/feedback and if you think of any additional metadata categories that might need to be defined to help facilitate the onboarding automation and lifecycle management for SP operations.

Hi Angelo,

At this stage,  the OLM team has a closer tie to the ONAP project than OSM, simply because several contributing member companies are also ONAP members.   

I was at the ONAP Beijing developer forum a few weeks ago,  they are indeed looking for inputs from the TM Forum in this area. The OLM work is not fully mature yet for contribution hence we are reaching out to the broader TM Forum community.

Btw, the current official activity between TM Forum and ONAP is around the introduction of  TM Forum APIs, we made the presentation to ONAP SDO committee here TMF-ONAP Dec.12 SDO V4.pptx and the API work is being done in ONAP ExtAPI project.   We also have weekly TM Forum ONAP Interest Group calls to coordinate the activities. The call is on every Tuesday and you can see the calendar here: https://projects.tmforum.org/wiki/display/ZOOM/Calendar

Regards,

The TM Forum OLM (onboarding and lifecycle management) team under the ZOOM project has been working on Virtual Function (VF) onboarding automation issue for quite some time.  For the new year, we would like to kick off a few discussion threads to make you aware of the work that we have been doing and to get your engagement and inputs as well.

While many standards and open source projects have contributed to the VF onboarding/Lifecycle Management space, the focus of those efforts have been primarily on how to onboard the functional aspects of the VF onto infrastructure environment (compute, storage, network).

Equally important is the operational information of the VF that needs to be provided by vendors to onboard/integrate VFs onto SP operational environment, such as for license/asset management, managing and calculating SLA, how to collect fault management and performance management data of the VF, etc.  These are the type of information that the TM Forum has been focusing on and highlighted in the following picture; we call them non-functional metadata:

• Package ID  (for catalog, asset, and usage right management)
• VF Package Type  (determine its <g class="gr_ gr_208 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="208" data-gr-id="208">orchestratability</g> and level of infrastructure dependencies)
• VF Functional Category (e.g., IMS, firewall, this will help determine associated operations support)
• License information (to support asset management,  vendor/SP revenue scheme, customer billing)
• SLAs (of several different types, e.g., package support for customers, supplier support for updates, etc.)
• Metrics information (mandatory and optional metrics supported by the package)
• Testing information  (test cases, test script, test results including security test results and checksums)

We will follow up with more posts on each of the category in coming weeks.  You can read about this general concept in the IG1141 document (currently available to the TM Forum members only).

We are interested in your view/feedback and if you think of any additional metadata categories that might need to be defined to help facilitate the onboarding automation and lifecycle management for SP operations.

The TM Forum OLM (onboarding and lifecycle management) team under the ZOOM project has been working on Virtual Function (VF) onboarding automation issue for quite some time.  For the new year, we would like to kick off a few discussion threads to make you aware of the work that we have been doing and to get your engagement and inputs as well.

While many standards and open source projects have contributed to the VF onboarding/Lifecycle Management space, the focus of those efforts have been primarily on how to onboard the functional aspects of the VF onto infrastructure environment (compute, storage, network).

Equally important is the operational information of the VF that needs to be provided by vendors to onboard/integrate VFs onto SP operational environment, such as for license/asset management, managing and calculating SLA, how to collect fault management and performance management data of the VF, etc.  These are the type of information that the TM Forum has been focusing on and highlighted in the following picture; we call them non-functional metadata:

• Package ID  (for catalog, asset, and usage right management)
• VF Package Type  (determine its <g class="gr_ gr_208 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="208" data-gr-id="208">orchestratability</g> and level of infrastructure dependencies)
• VF Functional Category (e.g., IMS, firewall, this will help determine associated operations support)
• License information (to support asset management,  vendor/SP revenue scheme, customer billing)
• SLAs (of several different types, e.g., package support for customers, supplier support for updates, etc.)
• Metrics information (mandatory and optional metrics supported by the package)
• Testing information  (test cases, test script, test results including security test results and checksums)

We will follow up with more posts on each of the category in coming weeks.  You can read about this general concept in the IG1141 document (currently available to the TM Forum members only).

We are interested in your view/feedback and if you think of any additional metadata categories that might need to be defined to help facilitate the onboarding automation and lifecycle management for SP operations.

The TM Forum OLM (onboarding and lifecycle management) team under the ZOOM project has been working on Virtual Function (VF) onboarding automation issue for quite some time.  For the new year, we would like to kick off a few discussion threads to make you aware of the work that we have been doing and to get your engagement and inputs as well.

While many standards and open source projects have contributed to the VF onboarding/Lifecycle Management space, the focus of those efforts have been primarily on how to onboard the functional aspects of the VF onto infrastructure environment (compute, storage, network).

Equally important is the operational information of the VF that needs to be provided by vendors to onboard/integrate VFs onto SP operational environment, such as for license/asset management, managing and calculating SLA, how to collect fault management and performance management data of the VF, etc.  These are the type of information that the TM Forum has been focusing on and highlighted in the following picture; we call them non-functional metadata:

• Package ID  (for catalog, asset, and usage right management)
• VF Package Type  (determine its <g class="gr_ gr_208 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="208" data-gr-id="208">orchestratability</g> and level of infrastructure dependencies)
• VF Functional Category (e.g., IMS, firewall, this will help determine associated operations support)
• License information (to support asset management,  vendor/SP revenue scheme, customer billing)
• SLAs (of several different types, e.g., package support for customers, supplier support for updates, etc.)
• Metrics information (mandatory and optional metrics supported by the package)
• Testing information  (test cases, test script, test results including security test results and checksums)

We will follow up with more posts on each of the category in coming weeks.  You can read about this general concept in the IG1141 document (currently available to the TM Forum members only).

We are interested in your view/feedback and if you think of any additional metadata categories that might need to be defined to help facilitate the onboarding automation and lifecycle management for SP operations.

​Thanks Milind, this brings up another important point about the modeling aspects of the metadata.

The challenges that we are facing and the modeling/tool chain debates in the industry e.g. TOSCA, YANG, HEAT etc. IMHO, is that no two VFs, or even of the same 'VF type', will be designed the same way or have the same requirements in operations.

This means everything in concern has to be modeled (partial model does not compute!), this is far from practical. The ideal approach is to have an intent based model to allow business to select the options at run time to achieve deep optimization.

The cube of the package symbol actually has some significance, based on team member inputs it represents a 3-dimensional VF Modeling (a Metamodel)

• Business Semantic: describe both functional and nonfunctional aspects, such as licensing, testing, SLA etc. with rich metadata (this is the metadata that I kicked off this thread)
• Technical Details: describe the syntactical data format to be exchanged and protocols. (HEAT, NETCONF etc.)
• Behaviors: additional information that would modify the behaviors of its exposed function (policies, management APIs etc.)

We are leaning towards using TOSCA to properly represent all these information, the important thing is to figure out the content and their relationships.  Will be interested to hear more feedback on the direction that we are going and which organizations that we need to work with besides a few obvious ones.

The TM Forum OLM (onboarding and lifecycle management) team under the ZOOM project has been working on Virtual Function (VF) onboarding automation issue for quite some time.  For the new year, we would like to kick off a few discussion threads to make you aware of the work that we have been doing and to get your engagement and inputs as well.

While many standards and open source projects have contributed to the VF onboarding/Lifecycle Management space, the focus of those efforts have been primarily on how to onboard the functional aspects of the VF onto infrastructure environment (compute, storage, network).

Equally important is the operational information of the VF that needs to be provided by vendors to onboard/integrate VFs onto SP operational environment, such as for license/asset management, managing and calculating SLA, how to collect fault management and performance management data of the VF, etc.  These are the type of information that the TM Forum has been focusing on and highlighted in the following picture; we call them non-functional metadata:

• Package ID  (for catalog, asset, and usage right management)
• VF Package Type  (determine its <g class="gr_ gr_208 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="208" data-gr-id="208">orchestratability</g> and level of infrastructure dependencies)
• VF Functional Category (e.g., IMS, firewall, this will help determine associated operations support)
• License information (to support asset management,  vendor/SP revenue scheme, customer billing)
• SLAs (of several different types, e.g., package support for customers, supplier support for updates, etc.)
• Metrics information (mandatory and optional metrics supported by the package)
• Testing information  (test cases, test script, test results including security test results and checksums)

We will follow up with more posts on each of the category in coming weeks.  You can read about this general concept in the IG1141 document (currently available to the TM Forum members only).

We are interested in your view/feedback and if you think of any additional metadata categories that might need to be defined to help facilitate the onboarding automation and lifecycle management for SP operations.

The TM Forum OLM (onboarding and lifecycle management) team under the ZOOM project has been working on Virtual Function (VF) onboarding automation issue for quite some time.  For the new year, we would like to kick off a few discussion threads to make you aware of the work that we have been doing and to get your engagement and inputs as well.

While many standards and open source projects have contributed to the VF onboarding/Lifecycle Management space, the focus of those efforts have been primarily on how to onboard the functional aspects of the VF onto infrastructure environment (compute, storage, network).

Equally important is the operational information of the VF that needs to be provided by vendors to onboard/integrate VFs onto SP operational environment, such as for license/asset management, managing and calculating SLA, how to collect fault management and performance management data of the VF, etc.  These are the type of information that the TM Forum has been focusing on and highlighted in the following picture; we call them non-functional metadata:

• Package ID  (for catalog, asset, and usage right management)
• VF Package Type  (determine its <g class="gr_ gr_208 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="208" data-gr-id="208">orchestratability</g> and level of infrastructure dependencies)
• VF Functional Category (e.g., IMS, firewall, this will help determine associated operations support)
• License information (to support asset management,  vendor/SP revenue scheme, customer billing)
• SLAs (of several different types, e.g., package support for customers, supplier support for updates, etc.)
• Metrics information (mandatory and optional metrics supported by the package)
• Testing information  (test cases, test script, test results including security test results and checksums)

We will follow up with more posts on each of the category in coming weeks.  You can read about this general concept in the IG1141 document (currently available to the TM Forum members only).

We are interested in your view/feedback and if you think of any additional metadata categories that might need to be defined to help facilitate the onboarding automation and lifecycle management for SP operations.

The TM Forum OLM (onboarding and lifecycle management) team under the ZOOM project has been working on Virtual Function (VF) onboarding automation issue for quite some time.  For the new year, we would like to kick off a few discussion threads to make you aware of the work that we have been doing and to get your engagement and inputs as well.

While many standards and open source projects have contributed to the VF onboarding/Lifecycle Management space, the focus of those efforts have been primarily on how to onboard the functional aspects of the VF onto infrastructure environment (compute, storage, network).

Equally important is the operational information of the VF that needs to be provided by vendors to onboard/integrate VFs onto SP operational environment, such as for license/asset management, managing and calculating SLA, how to collect fault management and performance management data of the VF, etc.  These are the type of information that the TM Forum has been focusing on and highlighted in the following picture; we call them non-functional metadata:

• Package ID  (for catalog, asset, and usage right management)
• VF Package Type  (determine its <g class="gr_ gr_208 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="208" data-gr-id="208">orchestratability</g> and level of infrastructure dependencies)
• VF Functional Category (e.g., IMS, firewall, this will help determine associated operations support)
• License information (to support asset management,  vendor/SP revenue scheme, customer billing)
• SLAs (of several different types, e.g., package support for customers, supplier support for updates, etc.)
• Metrics information (mandatory and optional metrics supported by the package)
• Testing information  (test cases, test script, test results including security test results and checksums)

We will follow up with more posts on each of the category in coming weeks.  You can read about this general concept in the IG1141 document (currently available to the TM Forum members only).

We are interested in your view/feedback and if you think of any additional metadata categories that might need to be defined to help facilitate the onboarding automation and lifecycle management for SP operations.

The TM Forum OLM (onboarding and lifecycle management) team under the ZOOM project has been working on Virtual Function (VF) onboarding automation issue for quite some time.  For the new year, we would like to kick off a few discussion threads to make you aware of the work that we have been doing and to get your engagement and inputs as well.

While many standards and open source projects have contributed to the VF onboarding/Lifecycle Management space, the focus of those efforts have been primarily on how to onboard the functional aspects of the VF onto infrastructure environment (compute, storage, network).

Equally important is the operational information of the VF that needs to be provided by vendors to onboard/integrate VFs onto SP operational environment, such as for license/asset management, managing and calculating SLA, how to collect fault management and performance management data of the VF, etc.  These are the type of information that the TM Forum has been focusing on and highlighted in the following picture; we call them non-functional metadata:

• Package ID  (for catalog, asset, and usage right management)
• VF Package Type  (determine its <g class="gr_ gr_208 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="208" data-gr-id="208">orchestratability</g> and level of infrastructure dependencies)
• VF Functional Category (e.g., IMS, firewall, this will help determine associated operations support)
• License information (to support asset management,  vendor/SP revenue scheme, customer billing)
• SLAs (of several different types, e.g., package support for customers, supplier support for updates, etc.)
• Metrics information (mandatory and optional metrics supported by the package)
• Testing information  (test cases, test script, test results including security test results and checksums)

We will follow up with more posts on each of the category in coming weeks.  You can read about this general concept in the IG1141 document (currently available to the TM Forum members only).

We are interested in your view/feedback and if you think of any additional metadata categories that might need to be defined to help facilitate the onboarding automation and lifecycle management for SP operations.