https://nfvwiki.etsi.org/api.php?action=feedcontributions&user=Nakamurate&feedformat=atomNFVwiki - User contributions [en]2024-03-28T18:58:30ZUser contributionsMediaWiki 1.39.3https://nfvwiki.etsi.org/index.php?title=NFV_FAQ&diff=3343NFV FAQ2017-12-20T18:17:40Z<p>Nakamurate: </p>
<hr />
<div>__TOC__<br />
<br />
== What's the role of SDN with NFV? ==<br />
<br />
The terms NFV and SDN have very often been used jointly and that might give the impression that SDN is a basic element in the NFV Architecture. SDN is an important concept and derived technology that greatly improves the control and management of the NFV infrastructure network. . Conversely, the functional blocks of an SDN architecture can be deployed in the form of virtualised network functions hosted in an NFV infrastructure. However, SDN is not a mandatory technology to fulfill NFV.<br />
<br />
: [https://portal.etsi.org/nfv/nfv_white_paper.pdf Clause from First NFV White Paper, Oct 2012] <br />
<br />
: '' “NFV is highly complementary to Software Defined Networking (SDN), but not dependent on it (or vice-versa). NFV can be implemented without an SDN being required, although the two concepts and solutions can be combined and potentially greater value accrued.” ''<br />
<br />
<br />
== What is the difference between NFVO Vs VNFM? ==<br />
<br />
NFVO and VNFM are both functional blocks of the NFV-MANO, Management and Orchestration Architectural Framework.<br />
<br />
The VNFM is responsible for the Life Cycle Management (LCM) of VNF(s). This includes supporting interface operations and execution of workflows for:<br />
<br />
* Instantiate VNF (create a VNF using the VNF on-boarding artefacts).<br />
* Scale VNF (increase or reduce the capacity of the VNF).<br />
* Heal VNF (corrective actions to repair a faulty VNF, and/or its VNFC instances and internal VNF Virtual Link(s))<br />
* Change VNF flavour (changing the flavour, i.e., the deployment options, of a already deployed VNF)<br />
* Operate VNF (changing the state of a VNF instance)<br />
* Modify VNF information (support VNF configuration and information changes).<br />
* Change external VNF connectivity (changing the external connectivity of a VNF instance)<br />
* Terminate VNF (release VNF-associated NFVI resources and return it to the NFVI resource pool).<br />
<br />
The VNFM is also responsible of VNF performance, fault and configuration management.<br />
<br />
On the other hand, the NFVO is responsible for managing the Network Service (NS) lifecycle, in conjunction with VNF lifecycle (supported by the VNFM), and orchestrating NFVI resources (supported by the VIM) to ensure an optimized allocation of the necessary resources and connectivity. As a result, NFVO functions can be classified into two main categories: End-to-end resource orchestration, and Network Service orchestration. NFVO is also responsible of NS performance and fault management as well as VNF package management. Similarly as with VNF LCM, NS lifecycle is related to a number of supported operations and execution of workflows, such as those used to instantiate, scale, heal and terminate an NS, as well as diverse type of updates, e.g., adding/removing VNF instances to/from an NS, etc.<br />
<br />
<br />
== What is the best practice for VNF deployment? Is it VM based or Container based? ==<br />
<br />
Most of the current Telco NFV deployments are based on VMs, and that suits most of the VNF implementations currently provided in the market. <br />
<br />
However, more recent implementations are starting to introduce VNFs based on containers. The use of container-based virtualisation is getting more considered, due to the industry momentum introduced by the requests for cloud-native VNFs.<br />
<br />
<br />
== What is the difference between VNFM and EM? ==<br />
<br />
On the one hand, the VNFM is responsible for the lifecycle management of the VNF from a resource viewpoint, like instantiation, scaling, etc. (refer also to Q2). On the other hand, the EM is responsible of FCAPS (fault, configuration, accounting, performance, and security) management of the actual network application residing in the VNF.<br />
<br />
<br />
== What is the difference between horizontal and vertical scaling? ==<br />
<br />
Scaling can be categorized into two classes: horizontal scaling and vertical scaling. In turn, scaling, as it relates to the capacity of a managed entity, is used to increase or decrease such a capacity.<br />
<br />
Taking the example of a VNF, horizontal scaling can be classified into two types<br />
* Scale out: relates to increasing capacity, and it refers to a process where one or more VNFC instances are added to an existing application.<br />
* Scale in: relates to decreasing capacity, and it refers to a process where one or more VNFC instances are removed from an existing application.<br />
<br />
Following the example of a VNF, vertical scaling can be classified into two types<br />
* Scale up: relates to increasing capacity, and it refers to a process where resources (e.g., CPU/Memory) are added to an existing VNFC instance.<br />
* Scale down: relates to decreasing capacity, and it refers to a process where resources (e.g., CPU/Memory) are released from an existing VNFC instance.<br />
<br />
Scaling can be triggered automatically whenever a certain pre-configured policy (e.g. regarding to CPU utilization) is activated, or by an explicit request, e.g., by an operator.<br />
<br />
For example, an auto scale policy in the NFV ecosystem may imply that the system should scale out if CPU utilization exceeds 70% and scale in if CPU utilization goes below 20%.<br />
<br />
VNF scaling can be triggered from several sources:<br />
* NFVO<br />
* VNFM<br />
* VNF/EM (Element Manager)<br />
* OSS/BSS<br />
* Manually by an operator<br />
<br />
<br />
== A lot of packet processing solutions such as DPDK features work in specialized HW. How can VNF implementers assure the performance on commodity HW but not on proprietary? ==<br />
<br />
DPDK requires compatible HW, namely compatible Network Interface Cards (NIC) and CPU models. However, unlike some other acceleration technologies, DPDK does not require specialized processors. In the latter case, specialized processors can be added to a commodity server (e.g. SmartNIC with embedded processor) to enable off-loading part of the traffic processing from the main general-purpose processor to these specialized processors.<br />
<br />
Moreover, although initially designed for the x86 ecosystem, DPDK is not a vendor-specific feature and recent versions are not related much to a specific hardware. Nowadays, DPDK is an open source community-driven software solution (software libraries) for enhancing packet processing. DPDK has evolved into a large ecosystem, with lots of different NIC cards and processors being supported, thus not tied to a certain HW or vendor solution.<br />
Despite the availability of DPDK for a variety of platforms, guaranteeing the performance requires joint lab/testing work between the VNF implementers and infrastructure providers along with the vertical NFV stack. <br />
<br />
<br />
== Can we have EM and VNFM in a single entity? ==<br />
<br />
EM and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume into one single entity both functionalities.<br />
<br />
<br />
== How do you evaluate the operators’ contributions in NFV and in open-source initiatives? ==<br />
<br />
The first NFV White paper published in Oct 2012 was a result of a cooperation of Tier-1 Operators (ref. [https://portal.etsi.org/nfv/nfv_white_paper.pdf Network Functions Virtualisation – Introductory White Paper]).<br />
<br />
Since that time, the ecosystem has expanded to reach more than 300 companies/organizations, including 39 network operators, in the ETSI NFV ISG.<br />
NFV ISG was spun as an operator-led industry initiative to raise awareness and foster all industry stakeholders to provide interoperable solutions following the NFV vision. Operators’ contribution has extended to participate directly in upstream communities like OpenStack and mid-stream communities such as OPNFV. Operators have also spun other market-leading open-source initiatives such as OSM, and ONAP, in addition to the standardization efforts done by all in ETSI NFV and other SDOs.<br />
<br />
<br />
== What is the exact role of hypervisors in NFV? ==<br />
<br />
A hypervisor is a piece of software that partitions the underlying HW physical resources (CPU, memory, storage, networking cards), generates virtual machines, and allocates the portioned resources to them.<br />
<br />
A virtual machine, on the other hand, behaves typically as a physical server that has all the ingredients needed for a physical server (CPU, memory, storage, NIC).<br />
<br />
The role of the hypervisor in NFV is of the “virtualisation layer” enabler of the NFVI for the case when virtualised compute resources are delivered in the form of a VM.<br />
<br />
<br />
== Can operator reuse existing hardware/infrastructure that is near end of life to be part of NFVI, e.g. 2G infrastructure if the operator is decommissioning it? ==<br />
<br />
Most of the old telco platforms are special-purpose hardware that can’t be used decoupled from their application software, which is actually one of the main concepts and drivers behind NFV.<br />
<br />
Whether specific hardware can be reused may depend on a case-by-case basis, upon analysis by the operator and equipment suppliers.<br />
<br />
<br />
== Why is NFV for the Mobile Core only now being introduced (e.g. LTE/EPC) and not earlier, particularly for the CDMA PS Core (PDSNs) and other Network Functions such as BSC/RAN? ==<br />
<br />
The selection of the network functions that are to be virtualised is subject to many criteria, either from the operator side or the vendor side. Factors that can influence what network functions are delivered as virtualised include: the network function software readiness to be run on a virtualised platform, market demand, end of life of existing hardware, and others. One of the other factors is the network function goal itself. For example, if it is a heavy transcoding workload, the virtualisation of such function could impact the performance of the network function, and its virtualisation thus be delayed until the virtualised infrastructure is capable to deliver the needed performance.<br />
<br />
<br />
== In the standard, there are two reference points, one between VNFM and VNF, and another one between VNFM and the EM for VNF. Are both reference points carrying the same type of functionality? ==<br />
<br />
[[File:NFV-framework.png | 500px]]<br />
<br />
The Ve-Vnfm-em reference point is used for exchanges between EM and VNF Manager. The Ve-Vnfm-vnf reference point is used for exchanges between VNF and VNF Manager. They share some common functionalities, for example, the VNF Indicator interface which is the information supplied by the VNF or the EM to provide some indication of the VNF behavior. VNFM can use these indicators in conjunction with virtualised resource data to perform auto-scaling decisions. Also, both reference points share most of the operations of the VNF Lifecycle Management interface produced by the VNFM and consumed by the EM and/or VNF.<br />
<br />
One of the differences is the VNF Configuration interface which is available only on the Ve-Vnfm-vnf. The VNF Configuration interface on the Ve-Vnfm-vnf reference point supports setting or updating virtualisation-related configuration parameters for a VNF/VNFC instance.<br />
<br />
<br />
== Can we have independent and multi-vendor VIM, VNF Manager and NFV Orchestrator in a real deployment? ==<br />
<br />
Yes, such a multi-vendor setup is possible. In this case, system integration efforts need to consider all three reference points between VIM, VNFM and NFVO. The REST APIs that ETSI NFV is specifying are intended to enable multi-vendor solutions. See: http://www.etsi.org/blog-subscription-information/entry/one-more-step-towards-nfv-mano-interoperability.<br />
<br />
<br />
== Is the VNF Manager a kind of cloud management platform? ==<br />
<br />
VNF Manager is the entity responsible mainly for the VNF lifecycle management, as well as for some configuration management functionality.<br />
<br />
In the context of NFV, the cloud management platform is represented by the VIM (Virtualised Infrastructure Management).<br />
<br />
<br />
== NFVO & VNFM can be combined in a same entity? ==<br />
<br />
NFVO and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume into one single entity both functionalities.<br />
<br />
<br />
== Does NFV focus only on virtualising the telecom network functions? ==<br />
<br />
Any enterprise or environment that share the same characteristics and the requirements of NFV (for example, carrier-grade performance, high availability, telco-like workloads) can leverage the potentials of NFV and the framework defined by ETSI NFV.<br />
<br />
<br />
== Why do we need to use SDN, if NFVO can perform its function? ==<br />
<br />
This is not correct. The two entities have different roles. NFVO is mainly responsible for resource orchestration and Network Service orchestration while the SDN in an NFVI PoP (a.k.a. DC SDN) is typically responsible for DC networking.<br />
<br />
When it comes to the networking part of the network service; the inter-VNF paths or links are defined as part of Network Service Descriptor and are processed by the NFVO. This information is used to derive the contents of the requests sent to VIM, which in turn can delegate the configuration of the infrastructure routers and switches to SDN.<br />
<br />
So, we may say the definition comes from NFVO and configuring the agents/hosts is being done by VIM/SDN.<br />
<br />
<br />
== From a performance point of view, is it enough to monitor the application layer KPIs or is it a must to monitor cloud layer performance as well? ==<br />
<br />
From a FM/PM perspective, an operator needs to perform E2E monitoring for the whole vertical stack for NFV. Therefore, getting the application counters and alarms from an EM is not enough. SW/HW Faults and counters need to be monitored by introducing the relevant infrastructure monitoring tools. <br />
<br />
Having the right set of tools at hand will allow operators to have an efficient root-cause analysis (RCA) engine for the network services and VNFs. Faults and performance reports related to virtualised resources should be sent by the NFVI to the VIM and propagated/correlated by the VNFM and NFVO up to the OSS and/or the EM or the VNF itself. The NFVO and the VNFM may also take some immediate actions on some events.<br />
<br />
<br />
== Is it true that NFV-MANO does not take into account physical network functions? ==<br />
<br />
No. The NFVO can manage hybrid network services combining VNFs and PNFs. However, NFV-MANO does not manage the lifecycle of PNF resources. From an NFVO viewpoint, PNFs are black-box entities exposing a number of connection points.<br />
<br />
<br />
== Is it true that NSs can be nested but only one level of nesting is permitted? ==<br />
<br />
No. There is no theoretical limit to the number of nesting levels. Although in practice this number is expected to be low.<br />
<br />
<br />
== ETSI specifies REST APIs enabling multi-vendor interoperability at some of the reference points of the NFV Architectural Framework. Can I use these APIs if my architecture differs from the NFV architectural framework? ==<br />
<br />
It all depends on how significant are the differences. For example, the APIs specified in [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.03.01_60/gs_NFV-SOL003v020301p.pdf ETSI NFV-SOL 003] for the or-Vnfm reference point can hardly be used if the functional split between the NFVO and the VNFM does not comply with ETSI standardization or if the two functional blocks are subsumed into a single entity. However, this does not prevent using the APIs specified in [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.03.01_60/gs_NFV-SOL002v020301p.pdf ETSI GS NFV-SOL 002] for the Ve-Vnfm reference point. Moreover, the APIs specified in an ETSI GS are independent from each other’s. For example, different APIs specified in [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL005_Os-Ma-nfvo_APIs ETSI GS NFV-SOL 005] can be consumed by different OSS components.<br />
<br />
<br />
== Does PNF dependability differ from VNF resiliency? ==<br />
<br />
The two terms cover the same concept, which is the ability to limit disruption and return to normal or at a minimum acceptable service delivery level in the face of a fault, failure, or an event that disrupts the normal operation.<br />
<br />
<br />
----<br />
'' Acknowledgement: The Q&A (No.1-18) were originally contributed by STC(Saudi Telecom Company). ''<br />
----<br />
''' Link '''<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Go to NFV Solutions page]<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=Main_Page Go to NFV wiki main page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Go to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=NFV_FAQ&diff=3342NFV FAQ2017-12-19T16:40:11Z<p>Nakamurate: </p>
<hr />
<div>__TOC__<br />
<br />
== What's the role of SDN with NFV? ==<br />
<br />
The terms NFV and SDN have very often been used jointly and that might give the impression that SDN is a basic element in the NFV Architecture. SDN is an important concept and derived technology that greatly improves the control and management of the NFV infrastructure network. . Conversely, the functional blocks of an SDN architecture can be deployed in the form of virtualized network functions hosted in an NFV infrastructure. However, SDN is not a mandatory technology to fulfill NFV.<br />
<br />
: [https://portal.etsi.org/nfv/nfv_white_paper.pdf Clause from First NFV White Paper, Oct 2012] <br />
<br />
: '' “NFV is highly complementary to Software Defined Networking (SDN), but not dependent on it (or vice-versa). NFV can be implemented without an SDN being required, although the two concepts and solutions can be combined and potentially greater value accrued.” ''<br />
<br />
<br />
== What is the difference between NFVO Vs VNFM? ==<br />
<br />
NFVO and VNFM are both functional blocks of the NFV-MANO, Management and Orchestration Architectural Framework.<br />
<br />
The VNFM is responsible for the Life Cycle Management (LCM) of VNF(s). This includes supporting interface operations and execution of workflows for:<br />
<br />
* Instantiate VNF (create a VNF using the VNF on-boarding artefacts).<br />
* Scale VNF (increase or reduce the capacity of the VNF).<br />
* Heal VNF (corrective actions to repair a faulty VNF, and/or its VNFC instances and internal VNF Virtual Link(s))<br />
* Change VNF flavour (changing the flavour, i.e., the deployment options, of a already deployed VNF)<br />
* Operate VNF (changing the state of a VNF instance)<br />
* Modify VNF information (support VNF configuration and information changes).<br />
* Change external VNF connectivity (changing the external connectivity of a VNF instance)<br />
* Terminate VNF (release VNF-associated NFVI resources and return it to the NFVI resource pool).<br />
<br />
The VNFM is also responsible of VNF performance, fault and configuration management.<br />
<br />
On the other hand, the NFVO is responsible for managing the Network Service (NS) lifecycle, in conjunction with VNF lifecycle (supported by the VNFM), and orchestrating NFVI resources (supported by the VIM) to ensure an optimized allocation of the necessary resources and connectivity. As a result, NFVO functions can be classified into two main categories: End-to-end resource orchestration, and Network Service orchestration. NFVO is also responsible of NS performance and fault management as well as VNF package management. Similarly as with VNF LCM, NS lifecycle is related to a number of supported operations and execution of workflows, such as those used to instantiate, scale, heal and terminate an NS, as well as diverse type of updates, e.g., adding/removing VNF instances to/from an NS, etc.<br />
<br />
<br />
== What is the best practice for VNF deployment? Is VM based or Container based? ==<br />
<br />
Most of the current Telco NFV deployments are based on VMs, and that currently suits most of the VNF implementations currently provided in the market. <br />
<br />
However, more recent implementations are starting to introduce VNFs based on containers. The use of container-based virtualization is getting more considered, due to the industry momentum introduced by the requests for cloud-native VNFs.<br />
<br />
<br />
== What is the difference between VNFM and EM? ==<br />
<br />
On the one hand, the VNFM is responsible for the lifecycle management of the VNF from a resource viewpoint, like instantiation, scaling, etc. (refer also to Q2). On the other hand, the EM is responsible of FCAPS (fault, configuration, accounting, performance, and security) management of the actual network application residing in the VNF.<br />
<br />
<br />
== What is the difference between horizontal and vertical scaling? ==<br />
<br />
Scaling can be categorized into two classes: horizontal scaling and vertical scaling. In turn, scaling, as it relates to capacity of a managed entity, is used to increase or decrease such a capacity.<br />
<br />
Taking the example of a VNF, horizontal scaling can be classified into two types<br />
* Scale out: relates to increasing capacity, and it refers to a process where one or more VNFC instances are added to an existing application.<br />
* Scale in: relates to decreasing capacity, and it refers to a process where one or more VNFC instances are removed from an existing application.<br />
<br />
Following the example of a VNF, vertical scaling can be classified into two types<br />
* Scale up: relates to increasing capacity, and it refers to a process where resources (e.g., CPU/Memory) are added to an existing VNFC instance.<br />
* Scale down: relates to decreasing capacity, and it refers to a process where resources (e.g., CPU/Memory) are released from an existing VNFC instance.<br />
<br />
Scaling can be triggered automatically whenever a certain pre-configured policy (e.g. regarding to CPU utilization) is activated, or by an explicit request, e.g., by an operator.<br />
<br />
For example, an auto scale policy in NFV ecosystem may imply that system should scale out if CPU utilization exceeds 70% and scale in if CPU Utilization goes below 20%.<br />
<br />
VNF scaling can be triggered from several sources:<br />
* NFVO<br />
* VNFM<br />
* VNF/EM (Element Manager)<br />
* OSS/BSS<br />
* Manually by an operator<br />
<br />
<br />
== A lot of packet processing solutions such as DPDK features work in specialized HW. How can VNF implementers assure the performance on commodity HW but not on proprietary? ==<br />
<br />
DPDK requires compatible HW, namely compatible Network Interface Cards (NIC) and CPU models. However, unlike some other acceleration technologies, DPDK does not require specialized processors. In the latter case, specialized processors can be added to a commodity server (e.g. SmartNIC with embedded processor) to enable off-loading part of the traffic processing from the main general-purpose processor to these specialized processors.<br />
<br />
Moreover, although initially designed for the x86 ecosystem, DPDK is not a vendor-specific feature and recent versions are not related much to a specific hardware. Nowadays, DPDK is an open source community-driven software solution (software libraries) for enhancing packet processing. DPDK has evolved into a large ecosystem, with lots of different NIC cards and processors being supported, thus not tied to a certain HW or vendor solution.<br />
Despite the availability of DPDK to a variety of platforms, guaranteeing the performance requires joint lab/testing work between the VNF implementers and infrastructure providers along with the vertical NFV stack. <br />
<br />
<br />
== Can we have EM and VNFM in a single entity? ==<br />
<br />
EM and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume into one single entity both functionalities.<br />
<br />
<br />
== How do you evaluate the operators’ contributions in NFV and in open-source initiatives? ==<br />
<br />
The first NFV White paper published in Oct 2012 was a result of a cooperation of Tier-1 Operators (ref. [https://portal.etsi.org/nfv/nfv_white_paper.pdf Network Functions Virtualisation – Introductory White Paper]).<br />
<br />
Since that time, the ecosystem has expanded to reach more than 300 companies/organizations, including 39 network operators, in the ETSI NFV ISG.<br />
NFV ISG was spun as an operator-led industry initiative to raise awareness and foster all industry stakeholders to provide interoperable solutions following NFV vision. Operators’ contribution has extended to participate directly in upstream communities like OpenStack and mid-stream communities such as OPNFV. Operators have also spun other market-leading open-source initiatives such as OSM, and ONAP, in addition to the standardization efforts done by all in ETSI NFV and other SDOs.<br />
<br />
<br />
== What is the exact role of hypervisors in NFV? ==<br />
<br />
A hypervisor is a piece of software that partitions the underlying HW physical resources (CPU, memory, storage, networking cards), generates virtual machines, and allocates the portioned resources to them.<br />
<br />
A virtual machine, on the other hand, behaves typically as a physical server that has all the ingredients needed for a physical server (CPU, memory, storage, NIC).<br />
<br />
The role of the hypervisor in NFV is of the “virtualization layer” enabler of the NFVI for the case when virtualized compute resources are delivered in the form of a VM.<br />
<br />
<br />
== Can operator reuse existing hardware/infrastructure that is near end of life to be part of NFVI, e.g. 2G infrastructure if the operator is decommissioning it? ==<br />
<br />
Most of the old telco platforms are special-purpose hardware that can’t be used decoupled from their application software, which is actually one of the main concepts and drivers behind NFV.<br />
<br />
Whether specific hardware can be reused may depend on a case-by-case basis, upon analysis by the operator and equipment suppliers.<br />
<br />
<br />
== Why NFV for Mobile Core is now introduced (LTE/EPC) and not before particularly in CDMA PS Core (PDSNs) and other NFs like BSC/RAN? ==<br />
<br />
The selection of the network functions that are to be virtualized is subject to many criteria, either from the operator side or the vendor side. Factors that can influence what network functions are delivered as virtualized include: the network function software readiness to be run on a virtualized platform, market demand, end of life of existing hardware, and others. One of the other factors is the network function goal itself. For example, if it is a heavy transcoding workload, the virtualization of such function could impact the performance of the network function, and its virtualization thus be delayed until the virtualized infrastructure is capable to deliver the needed performance.<br />
<br />
<br />
== In the standard, there are two reference points, one between VNFM and VNF, and another one between VNFM and the EM for VNF. Are both reference points carrying the same type of functionality? ==<br />
<br />
[[File:NFV-framework.png | 500px]]<br />
<br />
The Ve-Vnfm-em reference point is used for exchanges between EM and VNF Manager. The Ve-Vnfm-vnf reference point is used for exchanges between VNF and VNF Manager. They share some common functionalities, for example, the VNF Indicator interface which is the information supplied by the VNF or the EM to provide some indication of the VNF behavior. VNFM can use these indicators in conjunction with virtualized resource data to perform auto-scaling decisions. Also, both reference points share most of the operations of the VNF Lifecycle Management interface produced by the VNFM and consumed by the EM and/or VNF.<br />
<br />
One of the differences is the VNF Configuration interface which is available only on the Ve-Vnfm-vnf. The VNF Configuration interface on the Ve-Vnfm-vnf reference point supports setting or updating virtualization-related configuration parameters for a VNF/VNFC instance.<br />
<br />
<br />
== Can we have independent and multi-vendor VIM, VNF Manager and NFV Orchestrator in a real deployment? ==<br />
<br />
Yes, such a multi-vendor setup is possible. In this case, system integration efforts need to consider all three reference points between VIM, VNFM and NFVO. The REST APIs that ETSI NFV is specifying are intended to enable multi-vendor solutions. See: http://www.etsi.org/blog-subscription-information/entry/one-more-step-towards-nfv-mano-interoperability.<br />
<br />
<br />
== Is the VNF Manager a kind of cloud management platform? ==<br />
<br />
VNF Manager is the entity responsible mainly for the VNF lifecycle management, as well as for some configuration management functionality.<br />
<br />
In the context of NFV, the cloud management platform is represented by the VIM (Virtualized Infrastructure Management).<br />
<br />
<br />
== NFVO & VNFM can be on combined in the same entity? ==<br />
<br />
NFVO and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume into one single entity both functionalities.<br />
<br />
<br />
== Does NFV focus only on virtualizing the telecom network functions? ==<br />
<br />
Any enterprise or environment that share the same characteristics and the requirements of NFV (for example, carrier-grade performance, high availability, telco-like workloads) can leverage the potentials of NFV and the framework defined by ETSI NFV.<br />
<br />
<br />
== Why we need to use SDN, if NFVO can perform its function? ==<br />
<br />
This is not correct. The two entities have different roles. NFVO is mainly responsible for resource orchestration and Network Service orchestration while the SDN in an NFVI PoP (a.k.a. DC SDN) is typically responsible for DC networking.<br />
<br />
When it comes to the networking part of the network service; the inter-VNF paths or links are defined as part of Network Service Descriptor and are processed by the NFVO. This information is used to derive the contents of the requests sent to VIM, which in turn can delegate the configuration of the infrastructure routers and switches to SDN.<br />
<br />
So, we may say the definition comes from NFVO and configuring the agents/hosts is being done by VIM/SDN.<br />
<br />
<br />
== From a performance point of view, is it enough to monitor the application layer KPIs or is it a must to monitor cloud layer performance as well? ==<br />
<br />
From FM/PM perspective, an operator needs to perform E2E monitoring for the whole vertical stack for NFV. Therefore, getting the application counters and alarms from an EM is not enough. SW/HW Faults and counters need to be monitored by introducing the relevant infrastructure monitoring tools. <br />
<br />
Having the right set of tools at hand will allow operators to have an efficient root-cause analysis (RCA) engine for the network services and VNFs. Faults and performance reports related to virtualized resources should be reported by the NFVI to the VIM and propagated/correlated by the VNFM and NFVO up to the OSS and/or the EM or the VNF itself. The NFVO and the VNFM may also take some immediate actions on some events.<br />
<br />
<br />
== Is it true that NFV-MANO does not take into account physical network functions? ==<br />
<br />
No. The NFVO can manage hybrid network services combining VNFs and PNFs. However, NFV-MANO does not manage the lifecycle of PNF resources. From an NFVO viewpoint, PNFs are black-box entities exposing a number of connection points.<br />
<br />
<br />
== Is it true that NSs can be nested but only one level of nesting is permitted? ==<br />
<br />
No. There is no theoretical limit to the number of nesting levels. Although in practice this number is expected to be low.<br />
<br />
<br />
== ETSI specifies REST APIs enabling multi-vendor interoperability at some of the reference points of the NFV Architectural Framework. Can I use these APIs if my architecture differs from the NFV architectural framework? ==<br />
<br />
It all depends on how significant are the differences. For example, the APIs specified in [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.03.01_60/gs_NFV-SOL003v020301p.pdf ETSI NFV-SOL 003] for the or-Vnfm reference point can hardly be used if the functional split between the NFVO and the VNFM does not comply with ETSI standardization or if the two functional blocks are subsumed into a single entity. However, this does not prevent using the APIs specified in [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.03.01_60/gs_NFV-SOL002v020301p.pdf ETSI GS NFV-SOL 002] for the Ve-Vnfm reference point. Moreover, the APIs specified in an ETSI GS are independent from each other’s. For example, different APIs specified in [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL005_Os-Ma-nfvo_APIs ETSI GS NFV-SOL 005] can be consumed by different OSS components.<br />
<br />
<br />
== Does PNF dependability differ from VNF resiliency? ==<br />
<br />
The two terms cover the same concept, which is the ability to limit disruption and return to normal or at a minimum acceptable service delivery level in the face of a fault, failure, or an event that disrupts the normal operation.<br />
<br />
<br />
----<br />
'' Acknowledgement: The Q&A (No.1-18) were originally contributed by STC(Saudi Telecom Company). ''<br />
----<br />
''' Link '''<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Go to NFV Solutions page]<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=Main_Page Go to NFV wiki main page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Go to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=NFV_FAQ&diff=3338NFV FAQ2017-12-19T03:03:08Z<p>Nakamurate: </p>
<hr />
<div>__TOC__<br />
<br />
== What's the role of SDN with NFV? ==<br />
<br />
The terms NFV and SDN have very often been used jointly and that might give the impression that SDN is a basic element in the NFV Architecture. SDN is an important concept and derived technology that greatly improves the control and management of the NFV infrastructure network. . Conversely, the functional blocks of an SDN architecture can be deployed in the form of virtualized network functions hosted in an NFV infrastructure. However, SDN is not a mandatory technology to fulfill NFV.<br />
<br />
: [https://portal.etsi.org/nfv/nfv_white_paper.pdf Clause from First NFV White Paper, Oct 2012] <br />
<br />
: '' “NFV is highly complementary to Software Defined Networking (SDN), but not dependent on it (or vice-versa). NFV can be implemented without an SDN being required, although the two concepts and solutions can be combined and potentially greater value accrued.” ''<br />
<br />
<br />
== What is the difference between NFVO Vs VNFM? ==<br />
<br />
NFVO and VNFM are both functional blocks of the NFV-MANO, Management and Orchestration Architectural Framework.<br />
<br />
The VNFM is responsible for the Life Cycle Management (LCM) of VNF(s). This includes supporting interface operations and execution of workflows for:<br />
<br />
* Instantiate VNF (create a VNF using the VNF on-boarding artefacts).<br />
* Scale VNF (increase or reduce the capacity of the VNF).<br />
* Heal VNF (corrective actions to repair a faulty VNF, and/or its VNFC instances and internal VNF Virtual Link(s))<br />
* Change VNF flavour (changing the flavour, i.e., the deployment options, of a already deployed VNF)<br />
* Operate VNF (changing the state of a VNF instance)<br />
* Modify VNF information (support VNF configuration and information changes).<br />
* Change external VNF connectivity (changing the external connectivity of a VNF instance)<br />
* Terminate VNF (release VNF-associated NFVI resources and return it to the NFVI resource pool).<br />
<br />
The VNFM is also responsible of VNF performance, fault and configuration management.<br />
<br />
On the other hand, the NFVO is responsible for managing the Network Service (NS) lifecycle, in conjunction with VNF lifecycle (supported by the VNFM), and orchestrating NFVI resources (supported by the VIM) to ensure an optimized allocation of the necessary resources and connectivity. As a result, NFVO functions can be classified into two main categories: End-to-end resource orchestration, and Network Service orchestration. NFVO is also responsible of NS performance and fault management as well as VNF package management. Similarly as with VNF LCM, NS lifecycle is related to a number of supported operations and execution of workflows, such as those used to instantiate, scale, heal and terminate an NS, as well as diverse type of updates, e.g., adding/removing VNF instances to/from an NS, etc.<br />
<br />
<br />
== What is the best practice for VNF deployment? Is VM based or Container based? ==<br />
<br />
Most of the current Telco NFV deployments are based on VMs, and that currently suits most of the VNF implementations currently provided in the market. <br />
<br />
However, more recent implementations are starting to introduce VNFs based on containers. The use of container-based virtualization is getting more considered, due to the industry momentum introduced by the requests for cloud-native VNFs.<br />
<br />
<br />
== What is the difference between VNFM and EM? ==<br />
<br />
On the one hand, the VNFM is responsible for the lifecycle management of the VNF from a resource viewpoint, like instantiation, scaling, etc. (refer also to Q2). On the other hand, the EM is responsible of FCAPS (fault, configuration, accounting, performance, and security) management of the actual network application residing in the VNF.<br />
<br />
<br />
== What is the difference between horizontal and vertical scaling? ==<br />
<br />
Scaling can be categorized into two classes: horizontal scaling and vertical scaling. In turn, scaling, as it relates to capacity of a managed entity, is used to increase or decrease such a capacity.<br />
<br />
Taking the example of a VNF, horizontal scaling can be classified into two types<br />
* Scale out: relates to increasing capacity, and it refers to a process where one or more VNFC instances are added to an existing application.<br />
* Scale in: relates to decreasing capacity, and it refers to a process where one or more VNFC instances are removed from an existing application.<br />
<br />
Following the example of a VNF, vertical scaling can be classified into two types<br />
* Scale up: relates to increasing capacity, and it refers to a process where resources (e.g., CPU/Memory) are added to an existing VNFC instance.<br />
* Scale down: relates to decreasing capacity, and it refers to a process where resources (e.g., CPU/Memory) are released from an existing VNFC instance.<br />
<br />
Scaling can be triggered automatically whenever a certain pre-configured policy (e.g. regarding to CPU utilization) is activated, or by an explicit request, e.g., by an operator.<br />
<br />
For example, an auto scale policy in NFV ecosystem may imply that system should scale out if CPU utilization exceeds 70% and scale in if CPU Utilization goes below 20%.<br />
<br />
VNF scaling can be triggered from several sources:<br />
* NFVO<br />
* VNFM<br />
* VNF/EM (Element Manager)<br />
* OSS/BSS<br />
* Manually by an operator<br />
<br />
<br />
== A lot of packet processing solutions such as DPDK features work in specialized HW. How can VNF implementers assure the performance on commodity HW but not on proprietary? ==<br />
<br />
DPDK requires compatible HW, namely compatible Network Interface Cards (NIC) and CPU models. However, unlike some other acceleration technologies, DPDK does not require specialized processors. In the latter case, specialized processors can be added to a commodity server (e.g. SmartNIC with embedded processor) to enable off-loading part of the traffic processing from the main general-purpose processor to these specialized processors.<br />
<br />
Moreover, although initially designed for the x86 ecosystem, DPDK is not a vendor-specific feature and recent versions are not related much to a specific hardware. Nowadays, DPDK is an open source community-driven software solution (software libraries) for enhancing packet processing. DPDK has evolved into a large ecosystem, with lots of different NIC cards and processors being supported, thus not tied to a certain HW or vendor solution.<br />
Despite the availability of DPDK to a variety of platforms, guaranteeing the performance requires joint lab/testing work between the VNF implementers and infrastructure providers along with the vertical NFV stack. <br />
<br />
<br />
== Can we have EM and VNFM in a single entity? ==<br />
<br />
EM and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume into one single entity both functionalities.<br />
<br />
<br />
== How do you evaluate the operators’ contributions in NFV and in open-source initiatives? ==<br />
<br />
The first NFV White paper published in Oct 2012 was a result of a cooperation of Tier-1 Operators (ref. [https://portal.etsi.org/nfv/nfv_white_paper.pdf Network Functions Virtualisation – Introductory White Paper]).<br />
<br />
Since that time, the ecosystem has expanded to reach more than 300 companies/organizations, including 39 network operators, in the ETSI NFV ISG.<br />
NFV ISG was spun as an operator-led industry initiative to raise awareness and foster all industry stakeholders to provide interoperable solutions following NFV vision. Operators’ contribution has extended to participate directly in upstream communities like OpenStack and mid-stream communities such as OPNFV. Operators have also spun other market-leading open-source initiatives such as OSM, and ONAP, in addition to the standardization efforts done by all in ETSI NFV and other SDOs.<br />
<br />
<br />
== What is the exact role of hypervisors in NFV? ==<br />
<br />
A hypervisor is a piece of software that partitions the underlying HW physical resources (CPU, memory, storage, networking cards), generates virtual machines, and allocates the portioned resources to them.<br />
<br />
A virtual machine, on the other hand, behaves typically as a physical server that has all the ingredients needed for a physical server (CPU, memory, storage, NIC).<br />
<br />
The role of the hypervisor in NFV is of the “virtualization layer” enabler of the NFVI for the case when virtualized compute resources are delivered in the form of a VM.<br />
<br />
<br />
== Can operator reuse existing hardware/infrastructure that is near end of life to be part of NFVI, e.g. 2G infrastructure if the operator is decommissioning it? ==<br />
<br />
Most of the old telco platforms are special-purpose hardware that can’t be used decoupled from their application software, which is actually one of the main concepts and drivers behind NFV.<br />
<br />
Whether specific hardware can be reused may depend on a case-by-case basis, upon analysis by the operator and equipment suppliers.<br />
<br />
<br />
== Why NFV for Mobile Core is now introduced (LTE/EPC) and not before particularly in CDMA PS Core (PDSNs) and other NFs like BSC/RAN? ==<br />
<br />
The selection of the network functions that are to be virtualized is subject to many criteria, either from the operator side or the vendor side. Factors that can influence what network functions are delivered as virtualized include: the network function software readiness to be run on a virtualized platform, market demand, end of life of existing hardware, and others. One of the other factors is the network function goal itself. For example, if it is a heavy transcoding workload, the virtualization of such function could impact the performance of the network function, and its virtualization thus be delayed until the virtualized infrastructure is capable to deliver the needed performance.<br />
<br />
<br />
== In the standard, there are two reference points, one between VNFM and VNF, and another one between VNFM and the EM for VNF. Are both reference points carrying the same type of functionality? ==<br />
<br />
[[File:NFV-framework.png | 500px]]<br />
<br />
The Ve-Vnfm-em reference point is used for exchanges between EM and VNF Manager. The Ve-Vnfm-vnf reference point is used for exchanges between VNF and VNF Manager. They share some common functionalities, for example, the VNF Indicator interface which is the information supplied by the VNF or the EM to provide some indication of the VNF behavior. VNFM can use these indicators in conjunction with virtualized resource data to perform auto-scaling decisions. Also, both reference points share most of the operations of the VNF Lifecycle Management interface produced by the VNFM and consumed by the EM and/or VNF.<br />
<br />
One of the differences is the VNF Configuration interface which is available only on the Ve-Vnfm-vnf. The VNF Configuration interface on the Ve-Vnfm-vnf reference point supports setting or updating virtualization-related configuration parameters for a VNF/VNFC instance.<br />
<br />
<br />
== Can we have independent and multi-vendor VIM, VNF Manager and NFV Orchestrator in a real deployment? ==<br />
<br />
Yes, such a multi-vendor setup is possible. In this case, system integration efforts need to consider all three reference points between VIM, VNFM and NFVO. The REST APIs that ETSI NFV is specifying are intended to enable multi-vendor solutions. See: http://www.etsi.org/blog-subscription-information/entry/one-more-step-towards-nfv-mano-interoperability.<br />
<br />
<br />
== Is the VNF Manager a kind of cloud management platform? ==<br />
<br />
VNF Manager is the entity responsible mainly for the VNF lifecycle management, as well as for some configuration management functionality.<br />
<br />
In the context of NFV, the cloud management platform is represented by the VIM (Virtualized Infrastructure Management).<br />
<br />
<br />
== NFVO & VNFM can be on combined in the same entity? ==<br />
<br />
NFVO and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume into one single entity both functionalities.<br />
<br />
<br />
== Does NFV focus only on virtualizing the telecom network functions? ==<br />
<br />
Any enterprise or environment that share the same characteristics and the requirements of NFV (for example, carrier-grade performance, high availability, telco-like workloads) can leverage the potentials of NFV and the framework defined by ETSI NFV.<br />
<br />
<br />
== Why we need to use SDN, if NFVO can perform its function? ==<br />
<br />
This is not correct. The two entities have different roles. NFVO is mainly responsible for resource orchestration and Network Service orchestration while the SDN in an NFVI PoP (a.k.a. DC SDN) is typically responsible for DC networking.<br />
<br />
When it comes to the networking part of the network service; the inter-VNF paths or links are defined as part of Network Service Descriptor and are processed by the NFVO. This information is used to derive the contents of the requests sent to VIM, which in turn can delegate the configuration of the infrastructure routers and switches to SDN.<br />
<br />
So, we may say the definition comes from NFVO and configuring the agents/hosts is being done by VIM/SDN.<br />
<br />
<br />
== From a performance point of view, is it enough to monitor the application layer KPIs or is it a must to monitor cloud layer performance as well? ==<br />
<br />
From FM/PM perspective, an operator needs to perform E2E monitoring for the whole vertical stack for NFV. Therefore, getting the application counters and alarms from an EM is not enough. SW/HW Faults and counters need to be monitored by introducing the relevant infrastructure monitoring tools. <br />
<br />
Having the right set of tools at hand will allow operators to have an efficient root-cause analysis (RCA) engine for the network services and VNFs. Faults and performance reports related to virtualized resources should be reported by the NFVI to the VIM and propagated/correlated by the VNFM and NFVO up to the OSS and/or the EM or the VNF itself. The NFVO and the VNFM may also take some immediate actions on some events.<br />
<br />
<br />
== Is it true that NFV-MANO does not take into account physical network functions? ==<br />
<br />
No. The NFVO can manage hybrid network services combining VNFs and PNFs. However, NFV-MANO does not manage the lifecycle of PNF resources. From an NFVO viewpoint, PNFs are black-box entities exposing a number of connection points.<br />
<br />
<br />
== Is it true that NSs can be nested but only one level of nesting is permitted? ==<br />
<br />
No. There is no theoretical limit to the number of nesting levels. Although in practice this number is expected to be low.<br />
<br />
<br />
== ETSI specifies REST APIs enabling multi-vendor interoperability at some of the reference points of the NFV Architectural Framework. Can I use these APIs if my architecture differs from the NFV architectural framework? ==<br />
<br />
It all depends on how significant are the differences. For example, the APIs specified in [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.03.01_60/gs_NFV-SOL003v020301p.pdf ETSI NFV-SOL 003] for the or-Vnfm reference point can hardly be used if the functional split between the NFVO and the VNFM does not comply with ETSI standardization or if the two functional blocks are subsumed into a single entity. However, this does not prevent using the APIs specified in [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.03.01_60/gs_NFV-SOL002v020301p.pdf ETSI GS NFV-SOL 002] for the Ve-Vnfm reference point. Moreover, the APIs specified in an ETSI GS are independent from each other’s. For example, different APIs specified in [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL005_Os-Ma-nfvo_APIs ETSI GS NFV-SOL 005] can be consumed by different OSS components.<br />
<br />
<br />
== Does PNF dependability differ from VNF resiliency? ==<br />
<br />
The two terms cover the same concept, which is the ability to limit disruption and return to normal or at a minimum acceptable service delivery level in the face of a fault, failure, or an event that disrupts the normal operation.<br />
<br />
<br />
----<br />
''' Link '''<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Go to NFV Solutions page]<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=Main_Page Go to NFV wiki main page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Go to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=NFV_FAQ&diff=3337NFV FAQ2017-12-19T02:24:38Z<p>Nakamurate: </p>
<hr />
<div>__TOC__<br />
<br />
== What's the role of SDN with NFV? ==<br />
<br />
The terms NFV and SDN have very often been used jointly and that might give the impression that SDN is a basic element in the NFV Architecture. SDN is an important concept and derived technology that greatly improves the control and management of the NFV infrastructure network. . Conversely, the functional blocks of an SDN architecture can be deployed in the form of virtualized network functions hosted in an NFV infrastructure. However, SDN is not a mandatory technology to fulfill NFV.<br />
<br />
: [https://portal.etsi.org/nfv/nfv_white_paper.pdf Clause from First NFV White Paper, Oct 2012] <br />
<br />
: '' “NFV is highly complementary to Software Defined Networking (SDN), but not dependent on it (or vice-versa). NFV can be implemented without an SDN being required, although the two concepts and solutions can be combined and potentially greater value accrued.” ''<br />
<br />
<br />
== What is the difference between NFVO Vs VNFM? ==<br />
<br />
NFVO and VNFM are both functional blocks of the NFV-MANO, Management and Orchestration Architectural Framework.<br />
<br />
The VNFM is responsible for the Life Cycle Management (LCM) of VNF(s). This includes supporting interface operations and execution of workflows for:<br />
<br />
* Instantiate VNF (create a VNF using the VNF on-boarding artefacts).<br />
* Scale VNF (increase or reduce the capacity of the VNF).<br />
* Heal VNF (corrective actions to repair a faulty VNF, and/or its VNFC instances and internal VNF Virtual Link(s))<br />
* Change VNF flavour (changing the flavour, i.e., the deployment options, of a already deployed VNF)<br />
* Operate VNF (changing the state of a VNF instance)<br />
* Modify VNF information (support VNF configuration and information changes).<br />
* Change external VNF connectivity (changing the external connectivity of a VNF instance)<br />
* Terminate VNF (release VNF-associated NFVI resources and return it to the NFVI resource pool).<br />
<br />
The VNFM is also responsible of VNF performance, fault and configuration management.<br />
<br />
On the other hand, the NFVO is responsible for managing the Network Service (NS) lifecycle, in conjunction with VNF lifecycle (supported by the VNFM), and orchestrating NFVI resources (supported by the VIM) to ensure an optimized allocation of the necessary resources and connectivity. As a result, NFVO functions can be classified into two main categories: End-to-end resource orchestration, and Network Service orchestration. NFVO is also responsible of NS performance and fault management as well as VNF package management. Similarly as with VNF LCM, NS lifecycle is related to a number of supported operations and execution of workflows, such as those used to instantiate, scale, heal and terminate an NS, as well as diverse type of updates, e.g., adding/removing VNF instances to/from an NS, etc.<br />
<br />
<br />
== What is the best practice for VNF deployment? Is VM based or Container based? ==<br />
<br />
Most of the current Telco NFV deployments are based on VMs, and that currently suits most of the VNF implementations currently provided in the market. <br />
<br />
However, more recent implementations are starting to introduce VNFs based on containers. The use of container-based virtualization is getting more considered, due to the industry momentum introduced by the requests for cloud-native VNFs.<br />
<br />
<br />
== What is the difference between VNFM and EM? ==<br />
<br />
On the one hand, the VNFM is responsible for the lifecycle management of the VNF from a resource viewpoint, like instantiation, scaling, etc. (refer also to Q2). On the other hand, the EM is responsible of FCAPS (fault, configuration, accounting, performance, and security) management of the actual network application residing in the VNF.<br />
<br />
<br />
== What is the difference between horizontal and vertical scaling? ==<br />
<br />
Scaling can be categorized into two classes: horizontal scaling and vertical scaling. In turn, scaling, as it relates to capacity of a managed entity, is used to increase or decrease such a capacity.<br />
<br />
Taking the example of a VNF, horizontal scaling can be classified into two types<br />
* Scale out: relates to increasing capacity, and it refers to a process where one or more VNFC instances are added to an existing application.<br />
* Scale in: relates to decreasing capacity, and it refers to a process where one or more VNFC instances are removed from an existing application.<br />
<br />
Following the example of a VNF, vertical scaling can be classified into two types<br />
* Scale up: relates to increasing capacity, and it refers to a process where resources (e.g., CPU/Memory) are added to an existing VNFC instance.<br />
* Scale down: relates to decreasing capacity, and it refers to a process where resources (e.g., CPU/Memory) are released from an existing VNFC instance.<br />
<br />
Scaling can be triggered automatically whenever a certain pre-configured policy (e.g. regarding to CPU utilization) is activated, or by an explicit request, e.g., by an operator.<br />
<br />
For example, an auto scale policy in NFV ecosystem may imply that system should scale out if CPU utilization exceeds 70% and scale in if CPU Utilization goes below 20%.<br />
<br />
VNF scaling can be triggered from several sources:<br />
* NFVO<br />
* VNFM<br />
* VNF/EM (Element Manager)<br />
* OSS/BSS<br />
* Manually by an operator<br />
<br />
<br />
== A lot of packet processing solutions such as DPDK features work in specialized HW. How can VNF implementers assure the performance on commodity HW but not on proprietary? ==<br />
<br />
DPDK requires compatible HW, namely compatible Network Interface Cards (NIC) and CPU models. However, unlike some other acceleration technologies, DPDK does not require specialized processors. In the latter case, specialized processors can be added to a commodity server (e.g. SmartNIC with embedded processor) to enable off-loading part of the traffic processing from the main general-purpose processor to these specialized processors.<br />
<br />
Moreover, although initially designed for the x86 ecosystem, DPDK is not a vendor-specific feature and recent versions are not related much to a specific hardware. Nowadays, DPDK is an open source community-driven software solution (software libraries) for enhancing packet processing. DPDK has evolved into a large ecosystem, with lots of different NIC cards and processors being supported, thus not tied to a certain HW or vendor solution.<br />
Despite the availability of DPDK to a variety of platforms, guaranteeing the performance requires joint lab/testing work between the VNF implementers and infrastructure providers along with the vertical NFV stack. <br />
<br />
<br />
== Can we have EM and VNFM in a single entity? ==<br />
<br />
EM and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume into one single entity both functionalities.<br />
<br />
<br />
== How do you evaluate the operators’ contributions in NFV and in open-source initiatives? ==<br />
<br />
The first NFV White paper published in Oct 2012 was a result of a cooperation of Tier-1 Operators (ref. [https://portal.etsi.org/nfv/nfv_white_paper.pdf Network Functions Virtualisation – Introductory White Paper]).<br />
<br />
Since that time, the ecosystem has expanded to reach more than 300 companies/organizations, including 39 network operators, in the ETSI NFV ISG.<br />
NFV ISG was spun as an operator-led industry initiative to raise awareness and foster all industry stakeholders to provide interoperable solutions following NFV vision. Operators’ contribution has extended to participate directly in upstream communities like OpenStack and mid-stream communities such as OPNFV. Operators have also spun other market-leading open-source initiatives such as OSM, and ONAP, in addition to the standardization efforts done by all in ETSI NFV and other SDOs.<br />
<br />
<br />
== What is the exact role of hypervisors in NFV? ==<br />
<br />
A hypervisor is a piece of software that partitions the underlying HW physical resources (CPU, memory, storage, networking cards), generates virtual machines, and allocates the portioned resources to them.<br />
<br />
A virtual machine, on the other hand, behaves typically as a physical server that has all the ingredients needed for a physical server (CPU, memory, storage, NIC).<br />
<br />
The role of the hypervisor in NFV is of the “virtualization layer” enabler of the NFVI for the case when virtualized compute resources are delivered in the form of a VM.<br />
<br />
<br />
== Can operator reuse existing hardware/infrastructure that is near end of life to be part of NFVI, e.g. 2G infrastructure if the operator is decommissioning it? ==<br />
<br />
Most of the old telco platforms are special-purpose hardware that can’t be used decoupled from their application software, which is actually one of the main concepts and drivers behind NFV.<br />
<br />
Whether specific hardware can be reused may depend on a case-by-case basis, upon analysis by the operator and equipment suppliers.<br />
<br />
<br />
== Why NFV for Mobile Core is now introduced (LTE/EPC) and not before particularly in CDMA PS Core (PDSNs) and other NFs like BSC/RAN? ==<br />
<br />
The selection of the network functions that are to be virtualized is subject to many criteria, either from the operator side or the vendor side. Factors that can influence what network functions are delivered as virtualized include: the network function software readiness to be run on a virtualized platform, market demand, end of life of existing hardware, and others. One of the other factors is the network function goal itself. For example, if it is a heavy transcoding workload, the virtualization of such function could impact the performance of the network function, and its virtualization thus be delayed until the virtualized infrastructure is capable to deliver the needed performance.<br />
<br />
<br />
== In the standard, there are two reference points, one between VNFM and VNF, and another one between VNFM and the EM for VNF. Are both reference points carrying the same type of functionality? ==<br />
<br />
[[File:NFV-framework.png | 500px]]<br />
<br />
The Ve-Vnfm-em reference point is used for exchanges between EM and VNF Manager. The Ve-Vnfm-vnf reference point is used for exchanges between VNF and VNF Manager. They share some common functionalities, for example, the VNF Indicator interface which is the information supplied by the VNF or the EM to provide some indication of the VNF behavior. VNFM can use these indicators in conjunction with virtualized resource data to perform auto-scaling decisions. Also, both reference points share most of the operations of the VNF Lifecycle Management interface produced by the VNFM and consumed by the EM and/or VNF.<br />
<br />
One of the differences is the VNF Configuration interface which is available only on the Ve-Vnfm-vnf. The VNF Configuration interface on the Ve-Vnfm-vnf reference point supports setting or updating virtualization-related configuration parameters for a VNF/VNFC instance.<br />
<br />
<br />
== Can we have independent and multi-vendor VIM, VNF Manager and NFV Orchestrator in a real deployment? ==<br />
<br />
Yes, such a multi-vendor setup is possible. In this case, system integration efforts need to consider all three reference points between VIM, VNFM and NFVO. The REST APIs that ETSI NFV is specifying are intended to enable multi-vendor solutions. See: http://www.etsi.org/blog-subscription-information/entry/one-more-step-towards-nfv-mano-interoperability.<br />
<br />
<br />
== Is the VNF Manager a kind of cloud management platform? ==<br />
<br />
VNF Manager is the entity responsible mainly for the VNF lifecycle management, as well as for some configuration management functionality.<br />
<br />
In the context of NFV, the cloud management platform is represented by the VIM (Virtualized Infrastructure Management).<br />
<br />
<br />
== NFVO & VNFM can be on combined in the same entity? ==<br />
<br />
NFVO and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume into one single entity both functionalities.<br />
<br />
<br />
== Does NFV focus only on virtualizing the telecom network functions? ==<br />
<br />
Any enterprise or environment that share the same characteristics and the requirements of NFV (for example, carrier-grade performance, high availability, telco-like workloads) can leverage the potentials of NFV and the framework defined by ETSI NFV.<br />
<br />
<br />
== Why we need to use SDN, if NFVO can perform its function? ==<br />
<br />
This is not correct. The two entities have different roles. NFVO is mainly responsible for resource orchestration and Network Service orchestration while the SDN in an NFVI PoP (a.k.a. DC SDN) is typically responsible for DC networking.<br />
<br />
When it comes to the networking part of the network service; the inter-VNF paths or links are defined as part of Network Service Descriptor and are processed by the NFVO. This information is used to derive the contents of the requests sent to VIM, which in turn can delegate the configuration of the infrastructure routers and switches to SDN.<br />
<br />
So, we may say the definition comes from NFVO and configuring the agents/hosts is being done by VIM/SDN.<br />
<br />
<br />
== From a performance point of view, is it enough to monitor the application layer KPIs or is it a must to monitor cloud layer performance as well? ==<br />
<br />
From FM/PM perspective, an operator needs to perform E2E monitoring for the whole vertical stack for NFV. Therefore, getting the application counters and alarms from an EM is not enough. SW/HW Faults and counters need to be monitored by introducing the relevant infrastructure monitoring tools. <br />
<br />
Having the right set of tools at hand will allow operators to have an efficient root-cause analysis (RCA) engine for the network services and VNFs. Faults and performance reports related to virtualized resources should be reported by the NFVI to the VIM and propagated/correlated by the VNFM and NFVO up to the OSS and/or the EM or the VNF itself. The NFVO and the VNFM may also take some immediate actions on some events.<br />
<br />
<br />
== Is it true that NFV-MANO does not take into account physical network functions? ==<br />
<br />
No. The NFVO can manage hybrid network services combining VNFs and PNFs. However, NFV-MANO does not manage the lifecycle of PNF resources. From an NFVO viewpoint, PNFs are black-box entities exposing a number of connection points.<br />
<br />
<br />
== Is it true that NSs can be nested but only one level of nesting is permitted? ==<br />
<br />
No. There is no theoretical limit to the number of nesting levels. Although in practice this number is expected to be low.<br />
<br />
<br />
== ETSI specifies REST APIs enabling multi-vendor interoperability at some of the reference points of the NFV Architectural Framework. Can I use these APIs if my architecture differs from the NFV architectural framework? ==<br />
<br />
It all depends on how significant are the differences. For example, the APIs specified in [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.03.01_60/gs_NFV-SOL003v020301p.pdf ETSI NFV-SOL 003] for the or-Vnfm reference point can hardly be used if the functional split between the NFVO and the VNFM does not comply with ETSI standardization or if the two functional blocks are subsumed into a single entity. However, this does not prevent using the APIs specified in [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.03.01_60/gs_NFV-SOL002v020301p.pdf ETSI GS NFV-SOL 002] for the Ve-Vnfm reference point. Moreover, the APIs specified in an ETSI GS are independent from each other’s. For example, different APIs specified in [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL005_Os-Ma-nfvo_APIs ETSI GS NFV-SOL 005] can be consumed by different OSS components.<br />
<br />
<br />
== Does PNF dependability differ from VNF resiliency? ==<br />
<br />
The two terms cover the same concept, which is the ability to limit disruption and return to normal or at a minimum acceptable service delivery level in the face of a fault, failure, or an event that disrupts the normal operation.</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=NFV_FAQ&diff=3336NFV FAQ2017-12-19T02:23:10Z<p>Nakamurate: /* In the standard, there are two reference points, one between VNFM and VNF, and another one between VNFM and the EM for VNF. Are both reference points carrying the same type of functionality? */</p>
<hr />
<div>__TOC__<br />
<br />
== What's the role of SDN with NFV? ==<br />
<br />
The terms NFV and SDN have very often been used jointly and that might give the impression that SDN is a basic element in the NFV Architecture. SDN is an important concept and derived technology that greatly improves the control and management of the NFV infrastructure network. . Conversely, the functional blocks of an SDN architecture can be deployed in the form of virtualized network functions hosted in an NFV infrastructure. However, SDN is not a mandatory technology to fulfill NFV.<br />
<br />
: [https://portal.etsi.org/nfv/nfv_white_paper.pdf Clause from First NFV White Paper, Oct 2012] <br />
<br />
: '' “NFV is highly complementary to Software Defined Networking (SDN), but not dependent on it (or vice-versa). NFV can be implemented without an SDN being required, although the two concepts and solutions can be combined and potentially greater value accrued.” ''<br />
<br />
<br />
== What is the difference between NFVO Vs VNFM? ==<br />
<br />
NFVO and VNFM are both functional blocks of the NFV-MANO, Management and Orchestration Architectural Framework.<br />
<br />
The VNFM is responsible for the Life Cycle Management (LCM) of VNF(s). This includes supporting interface operations and execution of workflows for:<br />
<br />
* Instantiate VNF (create a VNF using the VNF on-boarding artefacts).<br />
* Scale VNF (increase or reduce the capacity of the VNF).<br />
* Heal VNF (corrective actions to repair a faulty VNF, and/or its VNFC instances and internal VNF Virtual Link(s))<br />
* Change VNF flavour (changing the flavour, i.e., the deployment options, of a already deployed VNF)<br />
* Operate VNF (changing the state of a VNF instance)<br />
* Modify VNF information (support VNF configuration and information changes).<br />
* Change external VNF connectivity (changing the external connectivity of a VNF instance)<br />
* Terminate VNF (release VNF-associated NFVI resources and return it to the NFVI resource pool).<br />
<br />
The VNFM is also responsible of VNF performance, fault and configuration management.<br />
<br />
On the other hand, the NFVO is responsible for managing the Network Service (NS) lifecycle, in conjunction with VNF lifecycle (supported by the VNFM), and orchestrating NFVI resources (supported by the VIM) to ensure an optimized allocation of the necessary resources and connectivity. As a result, NFVO functions can be classified into two main categories: End-to-end resource orchestration, and Network Service orchestration. NFVO is also responsible of NS performance and fault management as well as VNF package management. Similarly as with VNF LCM, NS lifecycle is related to a number of supported operations and execution of workflows, such as those used to instantiate, scale, heal and terminate an NS, as well as diverse type of updates, e.g., adding/removing VNF instances to/from an NS, etc.<br />
<br />
<br />
== What is the best practice for VNF deployment? Is VM based or Container based? ==<br />
<br />
Most of the current Telco NFV deployments are based on VMs, and that currently suits most of the VNF implementations currently provided in the market. <br />
<br />
However, more recent implementations are starting to introduce VNFs based on containers. The use of container-based virtualization is getting more considered, due to the industry momentum introduced by the requests for cloud-native VNFs.<br />
<br />
<br />
== What is the difference between VNFM and EM? ==<br />
<br />
On the one hand, the VNFM is responsible for the lifecycle management of the VNF from a resource viewpoint, like instantiation, scaling, etc. (refer also to Q2). On the other hand, the EM is responsible of FCAPS (fault, configuration, accounting, performance, and security) management of the actual network application residing in the VNF.<br />
<br />
<br />
== What is the difference between horizontal and vertical scaling? ==<br />
<br />
Scaling can be categorized into two classes: horizontal scaling and vertical scaling. In turn, scaling, as it relates to capacity of a managed entity, is used to increase or decrease such a capacity.<br />
<br />
Taking the example of a VNF, horizontal scaling can be classified into two types<br />
* Scale out: relates to increasing capacity, and it refers to a process where one or more VNFC instances are added to an existing application.<br />
* Scale in: relates to decreasing capacity, and it refers to a process where one or more VNFC instances are removed from an existing application.<br />
<br />
Following the example of a VNF, vertical scaling can be classified into two types<br />
* Scale up: relates to increasing capacity, and it refers to a process where resources (e.g., CPU/Memory) are added to an existing VNFC instance.<br />
* Scale down: relates to decreasing capacity, and it refers to a process where resources (e.g., CPU/Memory) are released from an existing VNFC instance.<br />
<br />
Scaling can be triggered automatically whenever a certain pre-configured policy (e.g. regarding to CPU utilization) is activated, or by an explicit request, e.g., by an operator.<br />
<br />
For example, an auto scale policy in NFV ecosystem may imply that system should scale out if CPU utilization exceeds 70% and scale in if CPU Utilization goes below 20%.<br />
<br />
VNF scaling can be triggered from several sources:<br />
* NFVO<br />
* VNFM<br />
* VNF/EM (Element Manager)<br />
* OSS/BSS<br />
* Manually by an operator<br />
<br />
<br />
== A lot of packet processing solutions such as DPDK features work in specialized HW. How can VNF implementers assure the performance on commodity HW but not on proprietary? ==<br />
<br />
DPDK requires compatible HW, namely compatible Network Interface Cards (NIC) and CPU models. However, unlike some other acceleration technologies, DPDK does not require specialized processors. In the latter case, specialized processors can be added to a commodity server (e.g. SmartNIC with embedded processor) to enable off-loading part of the traffic processing from the main general-purpose processor to these specialized processors.<br />
<br />
Moreover, although initially designed for the x86 ecosystem, DPDK is not a vendor-specific feature and recent versions are not related much to a specific hardware. Nowadays, DPDK is an open source community-driven software solution (software libraries) for enhancing packet processing. DPDK has evolved into a large ecosystem, with lots of different NIC cards and processors being supported, thus not tied to a certain HW or vendor solution.<br />
Despite the availability of DPDK to a variety of platforms, guaranteeing the performance requires joint lab/testing work between the VNF implementers and infrastructure providers along with the vertical NFV stack. <br />
<br />
<br />
== Can we have EM and VNFM in a single entity? ==<br />
<br />
EM and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume into one single entity both functionalities.<br />
<br />
<br />
== How do you evaluate the operators’ contributions in NFV and in open-source initiatives? ==<br />
<br />
The first NFV White paper published in Oct 2012 was a result of a cooperation of Tier-1 Operators (ref. [https://portal.etsi.org/nfv/nfv_white_paper.pdf Network Functions Virtualisation – Introductory White Paper]).<br />
<br />
Since that time, the ecosystem has expanded to reach more than 300 companies/organizations, including 39 network operators, in the ETSI NFV ISG.<br />
NFV ISG was spun as an operator-led industry initiative to raise awareness and foster all industry stakeholders to provide interoperable solutions following NFV vision. Operators’ contribution has extended to participate directly in upstream communities like OpenStack and mid-stream communities such as OPNFV. Operators have also spun other market-leading open-source initiatives such as OSM, and ONAP, in addition to the standardization efforts done by all in ETSI NFV and other SDOs.<br />
<br />
<br />
== What is the exact role of hypervisors in NFV? ==<br />
<br />
A hypervisor is a piece of software that partitions the underlying HW physical resources (CPU, memory, storage, networking cards), generates virtual machines, and allocates the portioned resources to them.<br />
<br />
A virtual machine, on the other hand, behaves typically as a physical server that has all the ingredients needed for a physical server (CPU, memory, storage, NIC).<br />
<br />
The role of the hypervisor in NFV is of the “virtualization layer” enabler of the NFVI for the case when virtualized compute resources are delivered in the form of a VM.<br />
<br />
<br />
== Can operator reuse existing hardware/infrastructure that is near end of life to be part of NFVI, e.g. 2G infrastructure if the operator is decommissioning it? ==<br />
<br />
Most of the old telco platforms are special-purpose hardware that can’t be used decoupled from their application software, which is actually one of the main concepts and drivers behind NFV.<br />
<br />
Whether specific hardware can be reused may depend on a case-by-case basis, upon analysis by the operator and equipment suppliers.<br />
<br />
<br />
== Why NFV for Mobile Core is now introduced (LTE/EPC) and not before particularly in CDMA PS Core (PDSNs) and other NFs like BSC/RAN? ==<br />
<br />
The selection of the network functions that are to be virtualized is subject to many criteria, either from the operator side or the vendor side. Factors that can influence what network functions are delivered as virtualized include: the network function software readiness to be run on a virtualized platform, market demand, end of life of existing hardware, and others. One of the other factors is the network function goal itself. For example, if it is a heavy transcoding workload, the virtualization of such function could impact the performance of the network function, and its virtualization thus be delayed until the virtualized infrastructure is capable to deliver the needed performance.<br />
<br />
<br />
== In the standard, there are two reference points, one between VNFM and VNF, and another one between VNFM and the EM for VNF. Are both reference points carrying the same type of functionality? ==<br />
<br />
[[File:NFV-framework.png | 500px]]<br />
<br />
The Ve-Vnfm-em reference point is used for exchanges between EM and VNF Manager. The Ve-Vnfm-vnf reference point is used for exchanges between VNF and VNF Manager. They share some common functionalities, for example, the VNF Indicator interface which is the information supplied by the VNF or the EM to provide some indication of the VNF behavior. VNFM can use these indicators in conjunction with virtualized resource data to perform auto-scaling decisions. Also, both reference points share most of the operations of the VNF Lifecycle Management interface produced by the VNFM and consumed by the EM and/or VNF.<br />
<br />
One of the differences is the VNF Configuration interface which is available only on the Ve-Vnfm-vnf. The VNF Configuration interface on the Ve-Vnfm-vnf reference point supports setting or updating virtualization-related configuration parameters for a VNF/VNFC instance.<br />
<br />
== Can we have independent and multi-vendor VIM, VNF Manager and NFV Orchestrator in a real deployment? ==<br />
<br />
Yes, such a multi-vendor setup is possible. In this case, system integration efforts need to consider all three reference points between VIM, VNFM and NFVO. The REST APIs that ETSI NFV is specifying are intended to enable multi-vendor solutions. See: http://www.etsi.org/blog-subscription-information/entry/one-more-step-towards-nfv-mano-interoperability.<br />
<br />
<br />
== Is the VNF Manager a kind of cloud management platform? ==<br />
<br />
VNF Manager is the entity responsible mainly for the VNF lifecycle management, as well as for some configuration management functionality.<br />
<br />
In the context of NFV, the cloud management platform is represented by the VIM (Virtualized Infrastructure Management).<br />
<br />
<br />
== NFVO & VNFM can be on combined in the same entity? ==<br />
<br />
NFVO and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume into one single entity both functionalities.<br />
<br />
<br />
== Does NFV focus only on virtualizing the telecom network functions? ==<br />
<br />
Any enterprise or environment that share the same characteristics and the requirements of NFV (for example, carrier-grade performance, high availability, telco-like workloads) can leverage the potentials of NFV and the framework defined by ETSI NFV.<br />
<br />
<br />
== Why we need to use SDN, if NFVO can perform its function? ==<br />
<br />
This is not correct. The two entities have different roles. NFVO is mainly responsible for resource orchestration and Network Service orchestration while the SDN in an NFVI PoP (a.k.a. DC SDN) is typically responsible for DC networking.<br />
<br />
When it comes to the networking part of the network service; the inter-VNF paths or links are defined as part of Network Service Descriptor and are processed by the NFVO. This information is used to derive the contents of the requests sent to VIM, which in turn can delegate the configuration of the infrastructure routers and switches to SDN.<br />
<br />
So, we may say the definition comes from NFVO and configuring the agents/hosts is being done by VIM/SDN.<br />
<br />
<br />
== From a performance point of view, is it enough to monitor the application layer KPIs or is it a must to monitor cloud layer performance as well? ==<br />
<br />
From FM/PM perspective, an operator needs to perform E2E monitoring for the whole vertical stack for NFV. Therefore, getting the application counters and alarms from an EM is not enough. SW/HW Faults and counters need to be monitored by introducing the relevant infrastructure monitoring tools. <br />
<br />
Having the right set of tools at hand will allow operators to have an efficient root-cause analysis (RCA) engine for the network services and VNFs. Faults and performance reports related to virtualized resources should be reported by the NFVI to the VIM and propagated/correlated by the VNFM and NFVO up to the OSS and/or the EM or the VNF itself. The NFVO and the VNFM may also take some immediate actions on some events.<br />
<br />
<br />
== Is it true that NFV-MANO does not take into account physical network functions? ==<br />
<br />
No. The NFVO can manage hybrid network services combining VNFs and PNFs. However, NFV-MANO does not manage the lifecycle of PNF resources. From an NFVO viewpoint, PNFs are black-box entities exposing a number of connection points.<br />
<br />
<br />
== Is it true that NSs can be nested but only one level of nesting is permitted? ==<br />
<br />
No. There is no theoretical limit to the number of nesting levels. Although in practice this number is expected to be low.<br />
<br />
<br />
== ETSI specifies REST APIs enabling multi-vendor interoperability at some of the reference points of the NFV Architectural Framework. Can I use these APIs if my architecture differs from the NFV architectural framework? ==<br />
<br />
It all depends on how significant are the differences. For example, the APIs specified in [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.03.01_60/gs_NFV-SOL003v020301p.pdf ETSI NFV-SOL 003] for the or-Vnfm reference point can hardly be used if the functional split between the NFVO and the VNFM does not comply with ETSI standardization or if the two functional blocks are subsumed into a single entity. However, this does not prevent using the APIs specified in [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.03.01_60/gs_NFV-SOL002v020301p.pdf ETSI GS NFV-SOL 002] for the Ve-Vnfm reference point. Moreover, the APIs specified in an ETSI GS are independent from each other’s. For example, different APIs specified in [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL005_Os-Ma-nfvo_APIs ETSI GS NFV-SOL 005] can be consumed by different OSS components.<br />
<br />
<br />
== Does PNF dependability differ from VNF resiliency? ==<br />
<br />
The two terms cover the same concept, which is the ability to limit disruption and return to normal or at a minimum acceptable service delivery level in the face of a fault, failure, or an event that disrupts the normal operation.</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=File:NFV-framework.png&diff=3335File:NFV-framework.png2017-12-19T02:21:21Z<p>Nakamurate: </p>
<hr />
<div></div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=NFV_FAQ&diff=3334NFV FAQ2017-12-19T02:19:21Z<p>Nakamurate: /* In the standard, there are two reference points, one between VNFM and VNF, and another one between VNFM and the EM for VNF. Are both reference points carrying the same type of functionality? */</p>
<hr />
<div>__TOC__<br />
<br />
== What's the role of SDN with NFV? ==<br />
<br />
The terms NFV and SDN have very often been used jointly and that might give the impression that SDN is a basic element in the NFV Architecture. SDN is an important concept and derived technology that greatly improves the control and management of the NFV infrastructure network. . Conversely, the functional blocks of an SDN architecture can be deployed in the form of virtualized network functions hosted in an NFV infrastructure. However, SDN is not a mandatory technology to fulfill NFV.<br />
<br />
: [https://portal.etsi.org/nfv/nfv_white_paper.pdf Clause from First NFV White Paper, Oct 2012] <br />
<br />
: '' “NFV is highly complementary to Software Defined Networking (SDN), but not dependent on it (or vice-versa). NFV can be implemented without an SDN being required, although the two concepts and solutions can be combined and potentially greater value accrued.” ''<br />
<br />
<br />
== What is the difference between NFVO Vs VNFM? ==<br />
<br />
NFVO and VNFM are both functional blocks of the NFV-MANO, Management and Orchestration Architectural Framework.<br />
<br />
The VNFM is responsible for the Life Cycle Management (LCM) of VNF(s). This includes supporting interface operations and execution of workflows for:<br />
<br />
* Instantiate VNF (create a VNF using the VNF on-boarding artefacts).<br />
* Scale VNF (increase or reduce the capacity of the VNF).<br />
* Heal VNF (corrective actions to repair a faulty VNF, and/or its VNFC instances and internal VNF Virtual Link(s))<br />
* Change VNF flavour (changing the flavour, i.e., the deployment options, of a already deployed VNF)<br />
* Operate VNF (changing the state of a VNF instance)<br />
* Modify VNF information (support VNF configuration and information changes).<br />
* Change external VNF connectivity (changing the external connectivity of a VNF instance)<br />
* Terminate VNF (release VNF-associated NFVI resources and return it to the NFVI resource pool).<br />
<br />
The VNFM is also responsible of VNF performance, fault and configuration management.<br />
<br />
On the other hand, the NFVO is responsible for managing the Network Service (NS) lifecycle, in conjunction with VNF lifecycle (supported by the VNFM), and orchestrating NFVI resources (supported by the VIM) to ensure an optimized allocation of the necessary resources and connectivity. As a result, NFVO functions can be classified into two main categories: End-to-end resource orchestration, and Network Service orchestration. NFVO is also responsible of NS performance and fault management as well as VNF package management. Similarly as with VNF LCM, NS lifecycle is related to a number of supported operations and execution of workflows, such as those used to instantiate, scale, heal and terminate an NS, as well as diverse type of updates, e.g., adding/removing VNF instances to/from an NS, etc.<br />
<br />
<br />
== What is the best practice for VNF deployment? Is VM based or Container based? ==<br />
<br />
Most of the current Telco NFV deployments are based on VMs, and that currently suits most of the VNF implementations currently provided in the market. <br />
<br />
However, more recent implementations are starting to introduce VNFs based on containers. The use of container-based virtualization is getting more considered, due to the industry momentum introduced by the requests for cloud-native VNFs.<br />
<br />
<br />
== What is the difference between VNFM and EM? ==<br />
<br />
On the one hand, the VNFM is responsible for the lifecycle management of the VNF from a resource viewpoint, like instantiation, scaling, etc. (refer also to Q2). On the other hand, the EM is responsible of FCAPS (fault, configuration, accounting, performance, and security) management of the actual network application residing in the VNF.<br />
<br />
<br />
== What is the difference between horizontal and vertical scaling? ==<br />
<br />
Scaling can be categorized into two classes: horizontal scaling and vertical scaling. In turn, scaling, as it relates to capacity of a managed entity, is used to increase or decrease such a capacity.<br />
<br />
Taking the example of a VNF, horizontal scaling can be classified into two types<br />
* Scale out: relates to increasing capacity, and it refers to a process where one or more VNFC instances are added to an existing application.<br />
* Scale in: relates to decreasing capacity, and it refers to a process where one or more VNFC instances are removed from an existing application.<br />
<br />
Following the example of a VNF, vertical scaling can be classified into two types<br />
* Scale up: relates to increasing capacity, and it refers to a process where resources (e.g., CPU/Memory) are added to an existing VNFC instance.<br />
* Scale down: relates to decreasing capacity, and it refers to a process where resources (e.g., CPU/Memory) are released from an existing VNFC instance.<br />
<br />
Scaling can be triggered automatically whenever a certain pre-configured policy (e.g. regarding to CPU utilization) is activated, or by an explicit request, e.g., by an operator.<br />
<br />
For example, an auto scale policy in NFV ecosystem may imply that system should scale out if CPU utilization exceeds 70% and scale in if CPU Utilization goes below 20%.<br />
<br />
VNF scaling can be triggered from several sources:<br />
* NFVO<br />
* VNFM<br />
* VNF/EM (Element Manager)<br />
* OSS/BSS<br />
* Manually by an operator<br />
<br />
<br />
== A lot of packet processing solutions such as DPDK features work in specialized HW. How can VNF implementers assure the performance on commodity HW but not on proprietary? ==<br />
<br />
DPDK requires compatible HW, namely compatible Network Interface Cards (NIC) and CPU models. However, unlike some other acceleration technologies, DPDK does not require specialized processors. In the latter case, specialized processors can be added to a commodity server (e.g. SmartNIC with embedded processor) to enable off-loading part of the traffic processing from the main general-purpose processor to these specialized processors.<br />
<br />
Moreover, although initially designed for the x86 ecosystem, DPDK is not a vendor-specific feature and recent versions are not related much to a specific hardware. Nowadays, DPDK is an open source community-driven software solution (software libraries) for enhancing packet processing. DPDK has evolved into a large ecosystem, with lots of different NIC cards and processors being supported, thus not tied to a certain HW or vendor solution.<br />
Despite the availability of DPDK to a variety of platforms, guaranteeing the performance requires joint lab/testing work between the VNF implementers and infrastructure providers along with the vertical NFV stack. <br />
<br />
<br />
== Can we have EM and VNFM in a single entity? ==<br />
<br />
EM and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume into one single entity both functionalities.<br />
<br />
<br />
== How do you evaluate the operators’ contributions in NFV and in open-source initiatives? ==<br />
<br />
The first NFV White paper published in Oct 2012 was a result of a cooperation of Tier-1 Operators (ref. [https://portal.etsi.org/nfv/nfv_white_paper.pdf Network Functions Virtualisation – Introductory White Paper]).<br />
<br />
Since that time, the ecosystem has expanded to reach more than 300 companies/organizations, including 39 network operators, in the ETSI NFV ISG.<br />
NFV ISG was spun as an operator-led industry initiative to raise awareness and foster all industry stakeholders to provide interoperable solutions following NFV vision. Operators’ contribution has extended to participate directly in upstream communities like OpenStack and mid-stream communities such as OPNFV. Operators have also spun other market-leading open-source initiatives such as OSM, and ONAP, in addition to the standardization efforts done by all in ETSI NFV and other SDOs.<br />
<br />
<br />
== What is the exact role of hypervisors in NFV? ==<br />
<br />
A hypervisor is a piece of software that partitions the underlying HW physical resources (CPU, memory, storage, networking cards), generates virtual machines, and allocates the portioned resources to them.<br />
<br />
A virtual machine, on the other hand, behaves typically as a physical server that has all the ingredients needed for a physical server (CPU, memory, storage, NIC).<br />
<br />
The role of the hypervisor in NFV is of the “virtualization layer” enabler of the NFVI for the case when virtualized compute resources are delivered in the form of a VM.<br />
<br />
<br />
== Can operator reuse existing hardware/infrastructure that is near end of life to be part of NFVI, e.g. 2G infrastructure if the operator is decommissioning it? ==<br />
<br />
Most of the old telco platforms are special-purpose hardware that can’t be used decoupled from their application software, which is actually one of the main concepts and drivers behind NFV.<br />
<br />
Whether specific hardware can be reused may depend on a case-by-case basis, upon analysis by the operator and equipment suppliers.<br />
<br />
<br />
== Why NFV for Mobile Core is now introduced (LTE/EPC) and not before particularly in CDMA PS Core (PDSNs) and other NFs like BSC/RAN? ==<br />
<br />
The selection of the network functions that are to be virtualized is subject to many criteria, either from the operator side or the vendor side. Factors that can influence what network functions are delivered as virtualized include: the network function software readiness to be run on a virtualized platform, market demand, end of life of existing hardware, and others. One of the other factors is the network function goal itself. For example, if it is a heavy transcoding workload, the virtualization of such function could impact the performance of the network function, and its virtualization thus be delayed until the virtualized infrastructure is capable to deliver the needed performance.<br />
<br />
<br />
== In the standard, there are two reference points, one between VNFM and VNF, and another one between VNFM and the EM for VNF. Are both reference points carrying the same type of functionality? ==<br />
<br />
[[File:NFV-framework.png]]<br />
<br />
The Ve-Vnfm-em reference point is used for exchanges between EM and VNF Manager. The Ve-Vnfm-vnf reference point is used for exchanges between VNF and VNF Manager. They share some common functionalities, for example, the VNF Indicator interface which is the information supplied by the VNF or the EM to provide some indication of the VNF behavior. VNFM can use these indicators in conjunction with virtualized resource data to perform auto-scaling decisions. Also, both reference points share most of the operations of the VNF Lifecycle Management interface produced by the VNFM and consumed by the EM and/or VNF.<br />
<br />
One of the differences is the VNF Configuration interface which is available only on the Ve-Vnfm-vnf. The VNF Configuration interface on the Ve-Vnfm-vnf reference point supports setting or updating virtualization-related configuration parameters for a VNF/VNFC instance.<br />
<br />
== Can we have independent and multi-vendor VIM, VNF Manager and NFV Orchestrator in a real deployment? ==<br />
<br />
Yes, such a multi-vendor setup is possible. In this case, system integration efforts need to consider all three reference points between VIM, VNFM and NFVO. The REST APIs that ETSI NFV is specifying are intended to enable multi-vendor solutions. See: http://www.etsi.org/blog-subscription-information/entry/one-more-step-towards-nfv-mano-interoperability.<br />
<br />
<br />
== Is the VNF Manager a kind of cloud management platform? ==<br />
<br />
VNF Manager is the entity responsible mainly for the VNF lifecycle management, as well as for some configuration management functionality.<br />
<br />
In the context of NFV, the cloud management platform is represented by the VIM (Virtualized Infrastructure Management).<br />
<br />
<br />
== NFVO & VNFM can be on combined in the same entity? ==<br />
<br />
NFVO and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume into one single entity both functionalities.<br />
<br />
<br />
== Does NFV focus only on virtualizing the telecom network functions? ==<br />
<br />
Any enterprise or environment that share the same characteristics and the requirements of NFV (for example, carrier-grade performance, high availability, telco-like workloads) can leverage the potentials of NFV and the framework defined by ETSI NFV.<br />
<br />
<br />
== Why we need to use SDN, if NFVO can perform its function? ==<br />
<br />
This is not correct. The two entities have different roles. NFVO is mainly responsible for resource orchestration and Network Service orchestration while the SDN in an NFVI PoP (a.k.a. DC SDN) is typically responsible for DC networking.<br />
<br />
When it comes to the networking part of the network service; the inter-VNF paths or links are defined as part of Network Service Descriptor and are processed by the NFVO. This information is used to derive the contents of the requests sent to VIM, which in turn can delegate the configuration of the infrastructure routers and switches to SDN.<br />
<br />
So, we may say the definition comes from NFVO and configuring the agents/hosts is being done by VIM/SDN.<br />
<br />
<br />
== From a performance point of view, is it enough to monitor the application layer KPIs or is it a must to monitor cloud layer performance as well? ==<br />
<br />
From FM/PM perspective, an operator needs to perform E2E monitoring for the whole vertical stack for NFV. Therefore, getting the application counters and alarms from an EM is not enough. SW/HW Faults and counters need to be monitored by introducing the relevant infrastructure monitoring tools. <br />
<br />
Having the right set of tools at hand will allow operators to have an efficient root-cause analysis (RCA) engine for the network services and VNFs. Faults and performance reports related to virtualized resources should be reported by the NFVI to the VIM and propagated/correlated by the VNFM and NFVO up to the OSS and/or the EM or the VNF itself. The NFVO and the VNFM may also take some immediate actions on some events.<br />
<br />
<br />
== Is it true that NFV-MANO does not take into account physical network functions? ==<br />
<br />
No. The NFVO can manage hybrid network services combining VNFs and PNFs. However, NFV-MANO does not manage the lifecycle of PNF resources. From an NFVO viewpoint, PNFs are black-box entities exposing a number of connection points.<br />
<br />
<br />
== Is it true that NSs can be nested but only one level of nesting is permitted? ==<br />
<br />
No. There is no theoretical limit to the number of nesting levels. Although in practice this number is expected to be low.<br />
<br />
<br />
== ETSI specifies REST APIs enabling multi-vendor interoperability at some of the reference points of the NFV Architectural Framework. Can I use these APIs if my architecture differs from the NFV architectural framework? ==<br />
<br />
It all depends on how significant are the differences. For example, the APIs specified in [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.03.01_60/gs_NFV-SOL003v020301p.pdf ETSI NFV-SOL 003] for the or-Vnfm reference point can hardly be used if the functional split between the NFVO and the VNFM does not comply with ETSI standardization or if the two functional blocks are subsumed into a single entity. However, this does not prevent using the APIs specified in [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.03.01_60/gs_NFV-SOL002v020301p.pdf ETSI GS NFV-SOL 002] for the Ve-Vnfm reference point. Moreover, the APIs specified in an ETSI GS are independent from each other’s. For example, different APIs specified in [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL005_Os-Ma-nfvo_APIs ETSI GS NFV-SOL 005] can be consumed by different OSS components.<br />
<br />
<br />
== Does PNF dependability differ from VNF resiliency? ==<br />
<br />
The two terms cover the same concept, which is the ability to limit disruption and return to normal or at a minimum acceptable service delivery level in the face of a fault, failure, or an event that disrupts the normal operation.</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=NFV_FAQ&diff=3333NFV FAQ2017-12-19T02:14:23Z<p>Nakamurate: </p>
<hr />
<div>__TOC__<br />
<br />
== What's the role of SDN with NFV? ==<br />
<br />
The terms NFV and SDN have very often been used jointly and that might give the impression that SDN is a basic element in the NFV Architecture. SDN is an important concept and derived technology that greatly improves the control and management of the NFV infrastructure network. . Conversely, the functional blocks of an SDN architecture can be deployed in the form of virtualized network functions hosted in an NFV infrastructure. However, SDN is not a mandatory technology to fulfill NFV.<br />
<br />
: [https://portal.etsi.org/nfv/nfv_white_paper.pdf Clause from First NFV White Paper, Oct 2012] <br />
<br />
: '' “NFV is highly complementary to Software Defined Networking (SDN), but not dependent on it (or vice-versa). NFV can be implemented without an SDN being required, although the two concepts and solutions can be combined and potentially greater value accrued.” ''<br />
<br />
<br />
== What is the difference between NFVO Vs VNFM? ==<br />
<br />
NFVO and VNFM are both functional blocks of the NFV-MANO, Management and Orchestration Architectural Framework.<br />
<br />
The VNFM is responsible for the Life Cycle Management (LCM) of VNF(s). This includes supporting interface operations and execution of workflows for:<br />
<br />
* Instantiate VNF (create a VNF using the VNF on-boarding artefacts).<br />
* Scale VNF (increase or reduce the capacity of the VNF).<br />
* Heal VNF (corrective actions to repair a faulty VNF, and/or its VNFC instances and internal VNF Virtual Link(s))<br />
* Change VNF flavour (changing the flavour, i.e., the deployment options, of a already deployed VNF)<br />
* Operate VNF (changing the state of a VNF instance)<br />
* Modify VNF information (support VNF configuration and information changes).<br />
* Change external VNF connectivity (changing the external connectivity of a VNF instance)<br />
* Terminate VNF (release VNF-associated NFVI resources and return it to the NFVI resource pool).<br />
<br />
The VNFM is also responsible of VNF performance, fault and configuration management.<br />
<br />
On the other hand, the NFVO is responsible for managing the Network Service (NS) lifecycle, in conjunction with VNF lifecycle (supported by the VNFM), and orchestrating NFVI resources (supported by the VIM) to ensure an optimized allocation of the necessary resources and connectivity. As a result, NFVO functions can be classified into two main categories: End-to-end resource orchestration, and Network Service orchestration. NFVO is also responsible of NS performance and fault management as well as VNF package management. Similarly as with VNF LCM, NS lifecycle is related to a number of supported operations and execution of workflows, such as those used to instantiate, scale, heal and terminate an NS, as well as diverse type of updates, e.g., adding/removing VNF instances to/from an NS, etc.<br />
<br />
<br />
== What is the best practice for VNF deployment? Is VM based or Container based? ==<br />
<br />
Most of the current Telco NFV deployments are based on VMs, and that currently suits most of the VNF implementations currently provided in the market. <br />
<br />
However, more recent implementations are starting to introduce VNFs based on containers. The use of container-based virtualization is getting more considered, due to the industry momentum introduced by the requests for cloud-native VNFs.<br />
<br />
<br />
== What is the difference between VNFM and EM? ==<br />
<br />
On the one hand, the VNFM is responsible for the lifecycle management of the VNF from a resource viewpoint, like instantiation, scaling, etc. (refer also to Q2). On the other hand, the EM is responsible of FCAPS (fault, configuration, accounting, performance, and security) management of the actual network application residing in the VNF.<br />
<br />
<br />
== What is the difference between horizontal and vertical scaling? ==<br />
<br />
Scaling can be categorized into two classes: horizontal scaling and vertical scaling. In turn, scaling, as it relates to capacity of a managed entity, is used to increase or decrease such a capacity.<br />
<br />
Taking the example of a VNF, horizontal scaling can be classified into two types<br />
* Scale out: relates to increasing capacity, and it refers to a process where one or more VNFC instances are added to an existing application.<br />
* Scale in: relates to decreasing capacity, and it refers to a process where one or more VNFC instances are removed from an existing application.<br />
<br />
Following the example of a VNF, vertical scaling can be classified into two types<br />
* Scale up: relates to increasing capacity, and it refers to a process where resources (e.g., CPU/Memory) are added to an existing VNFC instance.<br />
* Scale down: relates to decreasing capacity, and it refers to a process where resources (e.g., CPU/Memory) are released from an existing VNFC instance.<br />
<br />
Scaling can be triggered automatically whenever a certain pre-configured policy (e.g. regarding to CPU utilization) is activated, or by an explicit request, e.g., by an operator.<br />
<br />
For example, an auto scale policy in NFV ecosystem may imply that system should scale out if CPU utilization exceeds 70% and scale in if CPU Utilization goes below 20%.<br />
<br />
VNF scaling can be triggered from several sources:<br />
* NFVO<br />
* VNFM<br />
* VNF/EM (Element Manager)<br />
* OSS/BSS<br />
* Manually by an operator<br />
<br />
<br />
== A lot of packet processing solutions such as DPDK features work in specialized HW. How can VNF implementers assure the performance on commodity HW but not on proprietary? ==<br />
<br />
DPDK requires compatible HW, namely compatible Network Interface Cards (NIC) and CPU models. However, unlike some other acceleration technologies, DPDK does not require specialized processors. In the latter case, specialized processors can be added to a commodity server (e.g. SmartNIC with embedded processor) to enable off-loading part of the traffic processing from the main general-purpose processor to these specialized processors.<br />
<br />
Moreover, although initially designed for the x86 ecosystem, DPDK is not a vendor-specific feature and recent versions are not related much to a specific hardware. Nowadays, DPDK is an open source community-driven software solution (software libraries) for enhancing packet processing. DPDK has evolved into a large ecosystem, with lots of different NIC cards and processors being supported, thus not tied to a certain HW or vendor solution.<br />
Despite the availability of DPDK to a variety of platforms, guaranteeing the performance requires joint lab/testing work between the VNF implementers and infrastructure providers along with the vertical NFV stack. <br />
<br />
<br />
== Can we have EM and VNFM in a single entity? ==<br />
<br />
EM and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume into one single entity both functionalities.<br />
<br />
<br />
== How do you evaluate the operators’ contributions in NFV and in open-source initiatives? ==<br />
<br />
The first NFV White paper published in Oct 2012 was a result of a cooperation of Tier-1 Operators (ref. [https://portal.etsi.org/nfv/nfv_white_paper.pdf Network Functions Virtualisation – Introductory White Paper]).<br />
<br />
Since that time, the ecosystem has expanded to reach more than 300 companies/organizations, including 39 network operators, in the ETSI NFV ISG.<br />
NFV ISG was spun as an operator-led industry initiative to raise awareness and foster all industry stakeholders to provide interoperable solutions following NFV vision. Operators’ contribution has extended to participate directly in upstream communities like OpenStack and mid-stream communities such as OPNFV. Operators have also spun other market-leading open-source initiatives such as OSM, and ONAP, in addition to the standardization efforts done by all in ETSI NFV and other SDOs.<br />
<br />
<br />
== What is the exact role of hypervisors in NFV? ==<br />
<br />
A hypervisor is a piece of software that partitions the underlying HW physical resources (CPU, memory, storage, networking cards), generates virtual machines, and allocates the portioned resources to them.<br />
<br />
A virtual machine, on the other hand, behaves typically as a physical server that has all the ingredients needed for a physical server (CPU, memory, storage, NIC).<br />
<br />
The role of the hypervisor in NFV is of the “virtualization layer” enabler of the NFVI for the case when virtualized compute resources are delivered in the form of a VM.<br />
<br />
<br />
== Can operator reuse existing hardware/infrastructure that is near end of life to be part of NFVI, e.g. 2G infrastructure if the operator is decommissioning it? ==<br />
<br />
Most of the old telco platforms are special-purpose hardware that can’t be used decoupled from their application software, which is actually one of the main concepts and drivers behind NFV.<br />
<br />
Whether specific hardware can be reused may depend on a case-by-case basis, upon analysis by the operator and equipment suppliers.<br />
<br />
<br />
== Why NFV for Mobile Core is now introduced (LTE/EPC) and not before particularly in CDMA PS Core (PDSNs) and other NFs like BSC/RAN? ==<br />
<br />
The selection of the network functions that are to be virtualized is subject to many criteria, either from the operator side or the vendor side. Factors that can influence what network functions are delivered as virtualized include: the network function software readiness to be run on a virtualized platform, market demand, end of life of existing hardware, and others. One of the other factors is the network function goal itself. For example, if it is a heavy transcoding workload, the virtualization of such function could impact the performance of the network function, and its virtualization thus be delayed until the virtualized infrastructure is capable to deliver the needed performance.<br />
<br />
<br />
== In the standard, there are two reference points, one between VNFM and VNF, and another one between VNFM and the EM for VNF. Are both reference points carrying the same type of functionality? ==<br />
<br />
The Ve-Vnfm-em reference point is used for exchanges between EM and VNF Manager. The Ve-Vnfm-vnf reference point is used for exchanges between VNF and VNF Manager. They share some common functionalities, for example, the VNF Indicator interface which is the information supplied by the VNF or the EM to provide some indication of the VNF behavior. VNFM can use these indicators in conjunction with virtualized resource data to perform auto-scaling decisions. Also, both reference points share most of the operations of the VNF Lifecycle Management interface produced by the VNFM and consumed by the EM and/or VNF.<br />
<br />
One of the differences is the VNF Configuration interface which is available only on the Ve-Vnfm-vnf. The VNF Configuration interface on the Ve-Vnfm-vnf reference point supports setting or updating virtualization-related configuration parameters for a VNF/VNFC instance. <br />
<br />
<br />
== Can we have independent and multi-vendor VIM, VNF Manager and NFV Orchestrator in a real deployment? ==<br />
<br />
Yes, such a multi-vendor setup is possible. In this case, system integration efforts need to consider all three reference points between VIM, VNFM and NFVO. The REST APIs that ETSI NFV is specifying are intended to enable multi-vendor solutions. See: http://www.etsi.org/blog-subscription-information/entry/one-more-step-towards-nfv-mano-interoperability.<br />
<br />
<br />
== Is the VNF Manager a kind of cloud management platform? ==<br />
<br />
VNF Manager is the entity responsible mainly for the VNF lifecycle management, as well as for some configuration management functionality.<br />
<br />
In the context of NFV, the cloud management platform is represented by the VIM (Virtualized Infrastructure Management).<br />
<br />
<br />
== NFVO & VNFM can be on combined in the same entity? ==<br />
<br />
NFVO and VNFM are functional blocks providing different functionalities as specified in the NFV Architectural Framework. However, actual implementations can, as with many functional architectures, subsume into one single entity both functionalities.<br />
<br />
<br />
== Does NFV focus only on virtualizing the telecom network functions? ==<br />
<br />
Any enterprise or environment that share the same characteristics and the requirements of NFV (for example, carrier-grade performance, high availability, telco-like workloads) can leverage the potentials of NFV and the framework defined by ETSI NFV.<br />
<br />
<br />
== Why we need to use SDN, if NFVO can perform its function? ==<br />
<br />
This is not correct. The two entities have different roles. NFVO is mainly responsible for resource orchestration and Network Service orchestration while the SDN in an NFVI PoP (a.k.a. DC SDN) is typically responsible for DC networking.<br />
<br />
When it comes to the networking part of the network service; the inter-VNF paths or links are defined as part of Network Service Descriptor and are processed by the NFVO. This information is used to derive the contents of the requests sent to VIM, which in turn can delegate the configuration of the infrastructure routers and switches to SDN.<br />
<br />
So, we may say the definition comes from NFVO and configuring the agents/hosts is being done by VIM/SDN.<br />
<br />
<br />
== From a performance point of view, is it enough to monitor the application layer KPIs or is it a must to monitor cloud layer performance as well? ==<br />
<br />
From FM/PM perspective, an operator needs to perform E2E monitoring for the whole vertical stack for NFV. Therefore, getting the application counters and alarms from an EM is not enough. SW/HW Faults and counters need to be monitored by introducing the relevant infrastructure monitoring tools. <br />
<br />
Having the right set of tools at hand will allow operators to have an efficient root-cause analysis (RCA) engine for the network services and VNFs. Faults and performance reports related to virtualized resources should be reported by the NFVI to the VIM and propagated/correlated by the VNFM and NFVO up to the OSS and/or the EM or the VNF itself. The NFVO and the VNFM may also take some immediate actions on some events.<br />
<br />
<br />
== Is it true that NFV-MANO does not take into account physical network functions? ==<br />
<br />
No. The NFVO can manage hybrid network services combining VNFs and PNFs. However, NFV-MANO does not manage the lifecycle of PNF resources. From an NFVO viewpoint, PNFs are black-box entities exposing a number of connection points.<br />
<br />
<br />
== Is it true that NSs can be nested but only one level of nesting is permitted? ==<br />
<br />
No. There is no theoretical limit to the number of nesting levels. Although in practice this number is expected to be low.<br />
<br />
<br />
== ETSI specifies REST APIs enabling multi-vendor interoperability at some of the reference points of the NFV Architectural Framework. Can I use these APIs if my architecture differs from the NFV architectural framework? ==<br />
<br />
It all depends on how significant are the differences. For example, the APIs specified in [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.03.01_60/gs_NFV-SOL003v020301p.pdf ETSI NFV-SOL 003] for the or-Vnfm reference point can hardly be used if the functional split between the NFVO and the VNFM does not comply with ETSI standardization or if the two functional blocks are subsumed into a single entity. However, this does not prevent using the APIs specified in [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.03.01_60/gs_NFV-SOL002v020301p.pdf ETSI GS NFV-SOL 002] for the Ve-Vnfm reference point. Moreover, the APIs specified in an ETSI GS are independent from each other’s. For example, different APIs specified in [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL005_Os-Ma-nfvo_APIs ETSI GS NFV-SOL 005] can be consumed by different OSS components.<br />
<br />
<br />
== Does PNF dependability differ from VNF resiliency? ==<br />
<br />
The two terms cover the same concept, which is the ability to limit disruption and return to normal or at a minimum acceptable service delivery level in the face of a fault, failure, or an event that disrupts the normal operation.</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=NFV_FAQ&diff=3329NFV FAQ2017-12-12T18:50:34Z<p>Nakamurate: Created page with "__TOC__ == I would like to submit a NFV ISG POC proposal where can I find a Word version of the template? == You can find a link to the word version of the PoC Framework (..."</p>
<hr />
<div>__TOC__<br />
<br />
== I would like to submit a NFV ISG POC proposal where can I find a Word version of the template? ==<br />
<br />
You can find a link to the word version of the PoC Framework (including the templates) at:<br />
[http://webapp.etsi.org/exchangefolder/gs_NFV-PER002v010101p.zip NFV-PER002-PoC Framework - Word version] <br />
<br />
<br />
== Do all of the PoC team members have to be NFV ISG participants? ==<br />
<br />
No, it is only required that (at least) one of the supporting Network Operators or Service Providers <br />
is member of the NFV ISG. See Section 4.5 of the PoC Framework:<br />
<br />
''“4.5 NFV ISG PoC Proposal Acceptance Criteria ''<br />
''The criteria for acceptance of NFV ISG PoC Proposals are: ''<br />
[...]<br />
''2) The organizations participating in an PoC Project shall include at least two Manufacturers and at''<br />
''least one Network Operator or one Service Provider, where at least the one Network Operator or the one ''<br />
''Service Provider shall be a member of the NFV ISG (refer clause A.1.1). “''<br />
<br />
== Where do I send the completed NFV ISG PoC proposal? ==<br />
<br />
Once your proposal completed, you need to:<br />
1) upload it to the ETSI portal as a regular contribution<br />
2) send an email to NFV_POC@LIST.ETSI.ORG with [NFV ISG PoC Proposal] in the subject line and a link to <br />
the uploaded contribution included in the body. To be able to post your email, you will need to subscribe<br />
to that list if not already done. See section 4.3 of the PoC Framework:<br />
<br />
''“4.3 NFV ISG PoC Proposal Submission <br />
''PoC Team formation is beyond the scope of the NFV ISG. The PoC Team shall prepare an NFV ISG PoC Proposal ''<br />
''according to the NFV ISG PoC Proposal template in clause A.1. The PoC Proposal shall be submitted to the'' <br />
''ISG as a contribution uploaded on the ETSI Portal and a link to the contribution shall be sent to the ''<br />
''dedicated e-mail distribution list ‘NFV_POC@LIST.ETSI.ORG' with [NFV ISG PoC Proposal] in the subject ''<br />
''line.”''</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3322ETSI NFV Tutorial2017-10-18T22:37:24Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm(U.S. Mountain Time)), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
* Remote participation via GoToMeeting will be possible.<br />
<br />
== Registration==<br />
#To access to [https://portal.etsi.org/webapp/MeetingCalendar/MeetingDetails.asp?m_id=33257 NFV#19 - Tutorial & Specfest] and register. Or,<br />
#To send an e-mail to:<br />
#*Tetsuya Nakamura, CableLabs<br />
#*t.nakamura[at]cablelabs.com<br />
<br />
== Agenda ==<br />
*Date<br />
**September 11th, 2017, Monday 2:00-6:00pm(U.S. Mountain time)<br />
*Location<br />
**[http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], 7007 S Clinton St, Greenwood Village, CO 80112<br />
**[https://gotomeet.me/ETSINFVWebroom1 On-line via GoToMeeting]<br />
*Time table<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
! scope="col" style="width: 100px;"| Time<br />
! scope="col" | Topic<br />
! scope="col" | Details<br />
! scope="col" | Presentation<br />
|-<br />
! scope="row" | 2:00 - 2:15pm<br />
| align = "left" | <br />
Welcome<br />
<br />
| align = "left" |<br />
Perspective from the Cable Industry ''(by CableLabs)''<br />
<br />
| align = "left" |<br />
[https://nfvwiki.etsi.org/images/0.CableLabs_Intro_v8.pdf Material]<br />
<br />
|-<br />
! scope="row" | 2:15 - 3:45pm<br />
| align = "left" | <br />
Tutorial Session<br />
| align = "left" |<br />
#ETSI NFV Work Program ''(by ETSI NFV TSC)''<br />
#*Overview<br />
#**Key milestones<br />
#**Release highlights<br />
#*NFV Release 2 maintenance update<br />
#*NFV Release 3 ongoing work<br />
#ETSI NFV Concepts and MANO Details ''(by ETSI NFV IFA WG)''<br />
## ETSI NFV Concepts<br />
##*Main Management and Orchestration concepts<br />
##*VNF overview<br />
##*VNF Package and VNF Descriptor<br />
##Virtual Network Function (VNF) Lifecycle Management (LCM)<br />
##*Managing the VNF lifecycle<br />
##Network Service (NS) LCM<br />
##*NS overview<br />
##*NS LCM interface<br />
##NS Descriptor (NSD) and VNF Package interfaces<br />
##*NSD overview<br />
##*NSD and VNF Package interfaces<br />
#Key point<br />
| align = "left" |<br />
[https://nfvwiki.etsi.org/images/1.NFV%2817%29000244_ETSI_NFV_Release_program_presentation_at_NFV_19_Tutorials.pdf 1. Material]<br />
<br />
[https://nfvwiki.etsi.org/images/2.NFV%2817%29000251r1_ETSI_NFV_Concepts_and_MANO_details_-_NFV_19_Tutorial_Present.pdf 2. Material]<br />
<br />
[https://nfvwiki.etsi.org/images/3.NFV%2817%29000253_ETSI_NFV_19_Tutorial_Key_points.pdf 3. Material]<br />
<br />
|-<br />
! scope="row" | 3:45 - 4:00pm<br />
| align = "left" | <br />
Break<br />
| align = "left" |<br />
| align = "left" |<br />
|-<br />
! scope="row" | 4:00 - 6:00pm<br />
| align = "left" | <br />
NFV APIs Specfest Session<br />
<br />
| align = "left" |<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] overview ''(by ETSI NFV SOL WG)''<br />
#*VNF Management towards NFV Orchestrator<br />
#*VNF Management towards EM/VNF<br />
#*Network Service Management and VNF onboarding towards OSS/BSS<br />
#OpenAPI language and tools overview ''(by ETSI CTI)''<br />
#Hands-on on the ETSI forge, how to collaborate on OpenAPIs ''(by ETSI CTI)''<br />
#*Contribute an OpenAPI description of SOL specs to the Forge<br />
#*Learn how to use the online editor<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] in practice ''(by Nokia)''<br />
#*VNF Life Cycle Management testing based on OpenAPI files: a live demo<br />
#Future steps ''(by ETSI NFV SOL WG)''<br />
| align = "left" |<br />
[https://nfvwiki.etsi.org/images/4.NFV%2817%29000259_Overview_of_ETSI_NFV_REST_APIs_-_NFV_19_SpecFest.pdf 1. Material]<br />
<br />
[https://nfvwiki.etsi.org/images/5.NFV%2817%29000260r1_NFV_19_SPECFEST_CTI_presentation.pdf 2&3. Material] / [https://youtu.be/YXO0R61Dcg8 Webinar(youtube)]<br />
<br />
[https://nfvwiki.etsi.org/images/6.NFV%2817%29000263_NFV_19_SpecFest_demo_Nokia.pdf 4. Material] / [https://www.youtube.com/watch?v=6Q0Qcy9KiDc Webinar(youtube)]<br />
<br />
[https://nfvwiki.etsi.org/images/7.NFV%2817%29000254r2_ETSI_NFV_19_SpecFest_Looking_Forward.pdf 5. Material]<br />
|}<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3284ETSI NFV Tutorial2017-09-20T21:46:23Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm(U.S. Mountain Time)), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
* Remote participation via GoToMeeting will be possible.<br />
<br />
== Registration==<br />
#To access to [https://portal.etsi.org/webapp/MeetingCalendar/MeetingDetails.asp?m_id=33257 NFV#19 - Tutorial & Specfest] and register. Or,<br />
#To send an e-mail to:<br />
#*Tetsuya Nakamura, CableLabs<br />
#*t.nakamura[at]cablelabs.com<br />
<br />
== Agenda ==<br />
*Date<br />
**September 11th, 2017, Monday 2:00-6:00pm(U.S. Mountain time)<br />
*Location<br />
**[http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], 7007 S Clinton St, Greenwood Village, CO 80112<br />
**[https://gotomeet.me/ETSINFVWebroom1 On-line via GoToMeeting]<br />
*Time table<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
! scope="col" style="width: 100px;"| Time<br />
! scope="col" | Topic<br />
! scope="col" | Details<br />
! scope="col" | Presentation<br />
|-<br />
! scope="row" | 2:00 - 2:15pm<br />
| align = "left" | <br />
Welcome<br />
<br />
| align = "left" |<br />
Perspective from the Cable Industry ''(by CableLabs)''<br />
<br />
| align = "left" |<br />
[https://nfvwiki.etsi.org/images/0.CableLabs_Intro_v8.pdf Material]<br />
<br />
|-<br />
! scope="row" | 2:15 - 3:45pm<br />
| align = "left" | <br />
Tutorial Session<br />
| align = "left" |<br />
#ETSI NFV Work Program ''(by ETSI NFV TSC)''<br />
#*Overview<br />
#**Key milestones<br />
#**Release highlights<br />
#*NFV Release 2 maintenance update<br />
#*NFV Release 3 ongoing work<br />
#ETSI NFV Concepts and MANO Details ''(by ETSI NFV IFA WG)''<br />
## ETSI NFV Concepts<br />
##*Main Management and Orchestration concepts<br />
##*VNF overview<br />
##*VNF Package and VNF Descriptor<br />
##Virtual Network Function (VNF) Lifecycle Management (LCM)<br />
##*Managing the VNF lifecycle<br />
##Network Service (NS) LCM<br />
##*NS overview<br />
##*NS LCM interface<br />
##NS Descriptor (NSD) and VNF Package interfaces<br />
##*NSD overview<br />
##*NSD and VNF Package interfaces<br />
#Key point<br />
| align = "left" |<br />
[https://nfvwiki.etsi.org/images/1.NFV%2817%29000244_ETSI_NFV_Release_program_presentation_at_NFV_19_Tutorials.pdf 1. Material]<br />
<br />
[https://nfvwiki.etsi.org/images/2.NFV%2817%29000251r1_ETSI_NFV_Concepts_and_MANO_details_-_NFV_19_Tutorial_Present.pdf 2. Material]<br />
<br />
[https://nfvwiki.etsi.org/images/3.NFV%2817%29000253_ETSI_NFV_19_Tutorial_Key_points.pdf 3. Material]<br />
<br />
|-<br />
! scope="row" | 3:45 - 4:00pm<br />
| align = "left" | <br />
Break<br />
| align = "left" |<br />
| align = "left" |<br />
|-<br />
! scope="row" | 4:00 - 6:00pm<br />
| align = "left" | <br />
NFV APIs Specfest Session<br />
<br />
| align = "left" |<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] overview ''(by ETSI NFV SOL WG)''<br />
#*VNF Management towards NFV Orchestrator<br />
#*VNF Management towards EM/VNF<br />
#*Network Service Management and VNF onboarding towards OSS/BSS<br />
#OpenAPI language and tools overview ''(by ETSI CTI)''<br />
#Hands-on on the ETSI forge, how to collaborate on OpenAPIs ''(by ETSI CTI)''<br />
#*Contribute an OpenAPI description of SOL specs to the Forge<br />
#*Learn how to use the online editor<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] in practice ''(by Nokia)''<br />
#*VNF Life Cycle Management testing based on OpenAPI files: a live demo<br />
#Future steps ''(by ETSI NFV SOL WG)''<br />
| align = "left" |<br />
[https://nfvwiki.etsi.org/images/4.NFV%2817%29000259_Overview_of_ETSI_NFV_REST_APIs_-_NFV_19_SpecFest.pdf 1. Material]<br />
<br />
[https://nfvwiki.etsi.org/images/5.NFV%2817%29000260r1_NFV_19_SPECFEST_CTI_presentation.pdf 2&3. Material] / [https://youtu.be/YXO0R61Dcg8 Webinar(youtube)]<br />
<br />
[https://nfvwiki.etsi.org/images/6.NFV%2817%29000263_NFV_19_SpecFest_demo_Nokia.pdf 4. Material]<br />
<br />
[https://nfvwiki.etsi.org/images/7.NFV%2817%29000254r2_ETSI_NFV_19_SpecFest_Looking_Forward.pdf 5. Material]<br />
|}<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3254ETSI NFV Tutorial2017-09-12T17:10:48Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm(U.S. Mountain Time)), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
* Remote participation via GoToMeeting will be possible.<br />
<br />
== Registration==<br />
#To access to [https://portal.etsi.org/webapp/MeetingCalendar/MeetingDetails.asp?m_id=33257 NFV#19 - Tutorial & Specfest] and register. Or,<br />
#To send an e-mail to:<br />
#*Tetsuya Nakamura, CableLabs<br />
#*t.nakamura[at]cablelabs.com<br />
<br />
== Agenda ==<br />
*Date<br />
**September 11th, 2017, Monday 2:00-6:00pm(U.S. Mountain time)<br />
*Location<br />
**[http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], 7007 S Clinton St, Greenwood Village, CO 80112<br />
**[https://gotomeet.me/ETSINFVWebroom1 On-line via GoToMeeting]<br />
*Time table<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
! scope="col" style="width: 100px;"| Time<br />
! scope="col" | Topic<br />
! scope="col" | Details<br />
! scope="col" | Presentation<br />
|-<br />
! scope="row" | 2:00 - 2:15pm<br />
| align = "left" | <br />
Welcome<br />
<br />
| align = "left" |<br />
Perspective from the Cable Industry ''(by CableLabs)''<br />
<br />
| align = "left" |<br />
[https://nfvwiki.etsi.org/images/0.CableLabs_Intro_v8.pdf Material]<br />
<br />
|-<br />
! scope="row" | 2:15 - 3:45pm<br />
| align = "left" | <br />
Tutorial Session<br />
| align = "left" |<br />
#ETSI NFV Work Program ''(by ETSI NFV TSC)''<br />
#*Overview<br />
#**Key milestones<br />
#**Release highlights<br />
#*NFV Release 2 maintenance update<br />
#*NFV Release 3 ongoing work<br />
#ETSI NFV Concepts and MANO Details ''(by ETSI NFV IFA WG)''<br />
## ETSI NFV Concepts<br />
##*Main Management and Orchestration concepts<br />
##*VNF overview<br />
##*VNF Package and VNF Descriptor<br />
##Virtual Network Function (VNF) Lifecycle Management (LCM)<br />
##*Managing the VNF lifecycle<br />
##Network Service (NS) LCM<br />
##*NS overview<br />
##*NS LCM interface<br />
##NS Descriptor (NSD) and VNF Package interfaces<br />
##*NSD overview<br />
##*NSD and VNF Package interfaces<br />
#Key point<br />
| align = "left" |<br />
[https://nfvwiki.etsi.org/images/1.NFV%2817%29000244_ETSI_NFV_Release_program_presentation_at_NFV_19_Tutorials.pdf 1. Material]<br />
<br />
[https://nfvwiki.etsi.org/images/2.NFV%2817%29000251r1_ETSI_NFV_Concepts_and_MANO_details_-_NFV_19_Tutorial_Present.pdf 2. Material]<br />
<br />
[https://nfvwiki.etsi.org/images/3.NFV%2817%29000253_ETSI_NFV_19_Tutorial_Key_points.pdf 3. Material]<br />
<br />
|-<br />
! scope="row" | 3:45 - 4:00pm<br />
| align = "left" | <br />
Break<br />
| align = "left" |<br />
| align = "left" |<br />
|-<br />
! scope="row" | 4:00 - 6:00pm<br />
| align = "left" | <br />
NFV APIs Specfest Session<br />
<br />
| align = "left" |<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] overview ''(by ETSI NFV SOL WG)''<br />
#*VNF Management towards NFV Orchestrator<br />
#*VNF Management towards EM/VNF<br />
#*Network Service Management and VNF onboarding towards OSS/BSS<br />
#OpenAPI language and tools overview ''(by ETSI CTI)''<br />
#Hands-on on the ETSI forge, how to collaborate on OpenAPIs ''(by ETSI CTI)''<br />
#*Contribute an OpenAPI description of SOL specs to the Forge<br />
#*Learn how to use the online editor<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] in practice ''(by Nokia)''<br />
#*VNF Life Cycle Management testing based on OpenAPI files: a live demo<br />
#Future steps ''(by ETSI NFV SOL WG)''<br />
| align = "left" |<br />
[https://nfvwiki.etsi.org/images/4.NFV%2817%29000259_Overview_of_ETSI_NFV_REST_APIs_-_NFV_19_SpecFest.pdf 1. Material]<br />
<br />
[https://nfvwiki.etsi.org/images/5.NFV%2817%29000260r1_NFV_19_SPECFEST_CTI_presentation.pdf 2&3. Material]<br />
<br />
[https://nfvwiki.etsi.org/images/6.NFV%2817%29000263_NFV_19_SpecFest_demo_Nokia.pdf 4. Material]<br />
<br />
[https://nfvwiki.etsi.org/images/7.NFV%2817%29000254r2_ETSI_NFV_19_SpecFest_Looking_Forward.pdf 5. Material]<br />
|}<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=File:5.NFV(17)000260r1_NFV_19_SPECFEST_CTI_presentation.pdf&diff=3253File:5.NFV(17)000260r1 NFV 19 SPECFEST CTI presentation.pdf2017-09-12T17:07:16Z<p>Nakamurate: </p>
<hr />
<div></div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3252ETSI NFV Tutorial2017-09-12T14:59:46Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm(U.S. Mountain Time)), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
* Remote participation via GoToMeeting will be possible.<br />
<br />
== Registration==<br />
#To access to [https://portal.etsi.org/webapp/MeetingCalendar/MeetingDetails.asp?m_id=33257 NFV#19 - Tutorial & Specfest] and register. Or,<br />
#To send an e-mail to:<br />
#*Tetsuya Nakamura, CableLabs<br />
#*t.nakamura[at]cablelabs.com<br />
<br />
== Agenda ==<br />
*Date<br />
**September 11th, 2017, Monday 2:00-6:00pm(U.S. Mountain time)<br />
*Location<br />
**[http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], 7007 S Clinton St, Greenwood Village, CO 80112<br />
**[https://gotomeet.me/ETSINFVWebroom1 On-line via GoToMeeting]<br />
*Time table<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
! scope="col" style="width: 100px;"| Time<br />
! scope="col" | Topic<br />
! scope="col" | Details<br />
! scope="col" | Presentation<br />
|-<br />
! scope="row" | 2:00 - 2:15pm<br />
| align = "left" | <br />
Welcome<br />
<br />
| align = "left" |<br />
Perspective from the Cable Industry ''(by CableLabs)''<br />
<br />
| align = "left" |<br />
[https://nfvwiki.etsi.org/images/0.CableLabs_Intro_v8.pdf Material]<br />
<br />
Audio<br />
<br />
|-<br />
! scope="row" | 2:15 - 3:45pm<br />
| align = "left" | <br />
Tutorial Session<br />
| align = "left" |<br />
#ETSI NFV Work Program ''(by ETSI NFV TSC)''<br />
#*Overview<br />
#**Key milestones<br />
#**Release highlights<br />
#*NFV Release 2 maintenance update<br />
#*NFV Release 3 ongoing work<br />
#ETSI NFV Concepts and MANO Details ''(by ETSI NFV IFA WG)''<br />
## ETSI NFV Concepts<br />
##*Main Management and Orchestration concepts<br />
##*VNF overview<br />
##*VNF Package and VNF Descriptor<br />
##Virtual Network Function (VNF) Lifecycle Management (LCM)<br />
##*Managing the VNF lifecycle<br />
##Network Service (NS) LCM<br />
##*NS overview<br />
##*NS LCM interface<br />
##NS Descriptor (NSD) and VNF Package interfaces<br />
##*NSD overview<br />
##*NSD and VNF Package interfaces<br />
#Key point<br />
| align = "left" |<br />
[https://nfvwiki.etsi.org/images/1.NFV%2817%29000244_ETSI_NFV_Release_program_presentation_at_NFV_19_Tutorials.pdf 1.Material]<br />
<br />
1. Audio<br />
<br />
[https://nfvwiki.etsi.org/images/2.NFV%2817%29000251r1_ETSI_NFV_Concepts_and_MANO_details_-_NFV_19_Tutorial_Present.pdf 2. Material]<br />
<br />
2. Audio<br />
<br />
[https://nfvwiki.etsi.org/images/3.NFV%2817%29000253_ETSI_NFV_19_Tutorial_Key_points.pdf 3. Material]<br />
<br />
3. Audio<br />
<br />
|-<br />
! scope="row" | 3:45 - 4:00pm<br />
| align = "left" | <br />
Break<br />
| align = "left" |<br />
| align = "left" |<br />
|-<br />
! scope="row" | 4:00 - 6:00pm<br />
| align = "left" | <br />
NFV APIs Specfest Session<br />
<br />
| align = "left" |<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] overview ''(by ETSI NFV SOL WG)''<br />
#*VNF Management towards NFV Orchestrator<br />
#*VNF Management towards EM/VNF<br />
#*Network Service Management and VNF onboarding towards OSS/BSS<br />
#OpenAPI language and tools overview ''(by ETSI CTI)''<br />
#Hands-on on the ETSI forge, how to collaborate on OpenAPIs ''(by ETSI CTI)''<br />
#*Contribute an OpenAPI description of SOL specs to the Forge<br />
#*Learn how to use the online editor<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] in practice ''(by Nokia)''<br />
#*VNF Life Cycle Management testing based on OpenAPI files: a live demo<br />
#Future steps ''(by ETSI NFV SOL WG)''<br />
| align = "left" |<br />
[https://nfvwiki.etsi.org/images/4.NFV%2817%29000259_Overview_of_ETSI_NFV_REST_APIs_-_NFV_19_SpecFest.pdf 1. Material]<br />
<br />
1. Audio<br />
<br />
2&3. Material<br />
<br />
2&3. Audio<br />
<br />
[https://nfvwiki.etsi.org/images/6.NFV%2817%29000263_NFV_19_SpecFest_demo_Nokia.pdf 4. Material]<br />
<br />
4. Audio<br />
<br />
[https://nfvwiki.etsi.org/images/7.NFV%2817%29000254r2_ETSI_NFV_19_SpecFest_Looking_Forward.pdf 5. Material]<br />
<br />
5. Audio<br />
|}<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=File:7.NFV(17)000254r2_ETSI_NFV_19_SpecFest_Looking_Forward.pdf&diff=3251File:7.NFV(17)000254r2 ETSI NFV 19 SpecFest Looking Forward.pdf2017-09-12T14:58:45Z<p>Nakamurate: </p>
<hr />
<div></div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=File:6.NFV(17)000263_NFV_19_SpecFest_demo_Nokia.pdf&diff=3250File:6.NFV(17)000263 NFV 19 SpecFest demo Nokia.pdf2017-09-12T14:57:49Z<p>Nakamurate: </p>
<hr />
<div></div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=File:4.NFV(17)000259_Overview_of_ETSI_NFV_REST_APIs_-_NFV_19_SpecFest.pdf&diff=3249File:4.NFV(17)000259 Overview of ETSI NFV REST APIs - NFV 19 SpecFest.pdf2017-09-12T14:56:01Z<p>Nakamurate: </p>
<hr />
<div></div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=File:3.NFV(17)000253_ETSI_NFV_19_Tutorial_Key_points.pdf&diff=3248File:3.NFV(17)000253 ETSI NFV 19 Tutorial Key points.pdf2017-09-12T14:54:43Z<p>Nakamurate: </p>
<hr />
<div></div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=File:2.NFV(17)000251r1_ETSI_NFV_Concepts_and_MANO_details_-_NFV_19_Tutorial_Present.pdf&diff=3247File:2.NFV(17)000251r1 ETSI NFV Concepts and MANO details - NFV 19 Tutorial Present.pdf2017-09-12T14:51:53Z<p>Nakamurate: </p>
<hr />
<div></div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=File:1.NFV(17)000244_ETSI_NFV_Release_program_presentation_at_NFV_19_Tutorials.pdf&diff=3246File:1.NFV(17)000244 ETSI NFV Release program presentation at NFV 19 Tutorials.pdf2017-09-12T14:49:33Z<p>Nakamurate: </p>
<hr />
<div></div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=File:0.CableLabs_Intro_v8.pdf&diff=3245File:0.CableLabs Intro v8.pdf2017-09-12T14:47:21Z<p>Nakamurate: </p>
<hr />
<div></div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3244ETSI NFV Tutorial2017-09-12T06:15:07Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm(U.S. Mountain Time)), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
* Remote participation via GoToMeeting will be possible.<br />
<br />
== Registration==<br />
#To access to [https://portal.etsi.org/webapp/MeetingCalendar/MeetingDetails.asp?m_id=33257 NFV#19 - Tutorial & Specfest] and register. Or,<br />
#To send an e-mail to:<br />
#*Tetsuya Nakamura, CableLabs<br />
#*t.nakamura[at]cablelabs.com<br />
<br />
== Agenda ==<br />
*Date<br />
**September 11th, 2017, Monday 2:00-6:00pm(U.S. Mountain time)<br />
*Location<br />
**[http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], 7007 S Clinton St, Greenwood Village, CO 80112<br />
**[https://gotomeet.me/ETSINFVWebroom1 On-line via GoToMeeting]<br />
*Time table<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
! scope="col" style="width: 100px;"| Time<br />
! scope="col" | Topic<br />
! scope="col" | Details<br />
! scope="col" | Presentation<br />
|-<br />
! scope="row" | 2:00 - 2:15pm<br />
| align = "left" | <br />
Welcome<br />
<br />
| align = "left" |<br />
Perspective from the Cable Industry ''(by CableLabs)''<br />
<br />
| align = "left" |<br />
Material<br />
<br />
Audio<br />
<br />
|-<br />
! scope="row" | 2:15 - 3:45pm<br />
| align = "left" | <br />
Tutorial Session<br />
| align = "left" |<br />
#ETSI NFV Work Program ''(by ETSI NFV TSC)''<br />
#*Overview<br />
#**Key milestones<br />
#**Release highlights<br />
#*NFV Release 2 maintenance update<br />
#*NFV Release 3 ongoing work<br />
#ETSI NFV Concepts and MANO Details ''(by ETSI NFV IFA WG)''<br />
## ETSI NFV Concepts<br />
##*Main Management and Orchestration concepts<br />
##*VNF overview<br />
##*VNF Package and VNF Descriptor<br />
##Virtual Network Function (VNF) Lifecycle Management (LCM)<br />
##*Managing the VNF lifecycle<br />
##Network Service (NS) LCM<br />
##*NS overview<br />
##*NS LCM interface<br />
##NS Descriptor (NSD) and VNF Package interfaces<br />
##*NSD overview<br />
##*NSD and VNF Package interfaces<br />
#Key point<br />
| align = "left" |<br />
1. Material<br />
<br />
1. Audio<br />
<br />
2. Material<br />
<br />
2. Audio<br />
<br />
3. Material<br />
<br />
3. Audio<br />
<br />
|-<br />
! scope="row" | 3:45 - 4:00pm<br />
| align = "left" | <br />
Break<br />
| align = "left" |<br />
| align = "left" |<br />
|-<br />
! scope="row" | 4:00 - 6:00pm<br />
| align = "left" | <br />
NFV APIs Specfest Session<br />
<br />
| align = "left" |<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] overview ''(by ETSI NFV SOL WG)''<br />
#*VNF Management towards NFV Orchestrator<br />
#*VNF Management towards EM/VNF<br />
#*Network Service Management and VNF onboarding towards OSS/BSS<br />
#OpenAPI language and tools overview ''(by ETSI CTI)''<br />
#Hands-on on the ETSI forge, how to collaborate on OpenAPIs ''(by ETSI CTI)''<br />
#*Contribute an OpenAPI description of SOL specs to the Forge<br />
#*Learn how to use the online editor<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] in practice ''(by Nokia)''<br />
#*VNF Life Cycle Management testing based on OpenAPI files: a live demo<br />
#Future steps ''(by ETSI NFV SOL WG)''<br />
| align = "left" |<br />
1. Material<br />
<br />
1. Audio<br />
<br />
2&3. Material<br />
<br />
2&3. Audio<br />
<br />
4. Material<br />
<br />
4. Audio<br />
<br />
5. Material<br />
<br />
5. Audio<br />
|}<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3243ETSI NFV Tutorial2017-09-06T13:11:48Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm(U.S. Mountain Time)), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
* Remote participation via GoToMeeting will be possible.<br />
<br />
== Registration==<br />
#To access to [https://portal.etsi.org/webapp/MeetingCalendar/MeetingDetails.asp?m_id=33257 NFV#19 - Tutorial & Specfest] and register. Or,<br />
#To send an e-mail to:<br />
#*Tetsuya Nakamura, CableLabs<br />
#*t.nakamura[at]cablelabs.com<br />
<br />
== Agenda ==<br />
*Date<br />
**September 11th, 2017, Monday 2:00-6:00pm(U.S. Mountain time)<br />
*Location<br />
**[http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], 7007 S Clinton St, Greenwood Village, CO 80112<br />
**[https://gotomeet.me/ETSINFVWebroom1 On-line via GoToMeeting]<br />
*Time table<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
! scope="col" style="width: 100px;"| Time<br />
! scope="col" | Topic<br />
! scope="col" | Details<br />
|-<br />
! scope="row" | 2:00 - 2:15pm<br />
| align = "left" | <br />
Welcome<br />
<br />
| align = "left" |<br />
Perspective from the Cable Industry ''(by CableLabs)''<br />
<br />
|-<br />
! scope="row" | 2:15 - 3:45pm<br />
| align = "left" | <br />
Tutorial Session<br />
<br />
| align = "left" |<br />
#ETSI NFV Work Program ''(by ETSI NFV TSC)''<br />
#*Overview<br />
#**Key milestones<br />
#**Release highlights<br />
#*NFV Release 2 maintenance update<br />
#*NFV Release 3 ongoing work<br />
#ETSI NFV Concepts and MANO Details ''(by ETSI NFV IFA WG)''<br />
## ETSI NFV Concepts<br />
##*Main Management and Orchestration concepts<br />
##*VNF overview<br />
##*VNF Package and VNF Descriptor<br />
##Virtual Network Function (VNF) Lifecycle Management (LCM)<br />
##*Managing the VNF lifecycle<br />
##Network Service (NS) LCM<br />
##*NS overview<br />
##*NS LCM interface<br />
##NS Descriptor (NSD) and VNF Package interfaces<br />
##*NSD overview<br />
##*NSD and VNF Package interfaces<br />
|-<br />
! scope="row" | 3:45 - 4:00pm<br />
| align = "left" | <br />
Break<br />
| align = "left" |<br />
|-<br />
! scope="row" | 4:00 - 6:00pm<br />
| align = "left" | <br />
NFV APIs Specfest Session<br />
<br />
| align = "left" |<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] overview ''(by ETSI NFV SOL WG)''<br />
#*VNF Management towards NFV Orchestrator<br />
#*VNF Management towards EM/VNF<br />
#*Network Service Management and VNF onboarding towards OSS/BSS<br />
#OpenAPI language and tools overview ''(by ETSI CTI)''<br />
#Hands-on on the ETSI forge, how to collaborate on OpenAPIs ''(by ETSI CTI)''<br />
#*Contribute an OpenAPI description of SOL specs to the Forge<br />
#*Learn how to use the online editor<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] in practice ''(by Nokia)''<br />
#*VNF Life Cycle Management testing based on OpenAPI files: a live demo<br />
#Future steps ''(by ETSI NFV SOL WG)''<br />
|}<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3242ETSI NFV Tutorial2017-09-05T14:29:11Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm(U.S. Mountain Time)), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
* Remote participation via GoToMeeting will be possible.<br />
<br />
== Registration==<br />
#To access to [https://portal.etsi.org/webapp/MeetingCalendar/MeetingDetails.asp?m_id=33257 NFV#19 - Tutorial & Specfest] and register. Or,<br />
#To send an e-mail to:<br />
#*Tetsuya Nakamura, CableLabs<br />
#*t.nakamura[at]cablelabs.com<br />
<br />
== Agenda ==<br />
*Date<br />
**September 11th, 2017, Monday 2:00-6:00pm(U.S. Mountain time)<br />
*Location<br />
**[http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], 7007 S Clinton St, Greenwood Village, CO 80112<br />
**[https://gotomeet.me/ETSINFVWebroom1 On-line via GoToMeeting]<br />
*Time table<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
! scope="col" style="width: 100px;"| Time<br />
! scope="col" | Topic<br />
! scope="col" | Details<br />
|-<br />
! scope="row" | 2:00 - 2:15pm<br />
| align = "left" | <br />
Welcome<br />
<br />
|<br />
|-<br />
! scope="row" | 2:15 - 3:45pm<br />
| align = "left" | <br />
Tutorial Session<br />
<br />
| align = "left" |<br />
#ETSI NFV Work Program ''(by ETSI NFV TSC)''<br />
#*Overview<br />
#**Key milestones<br />
#**Release highlights<br />
#*NFV Release 2 maintenance update<br />
#*NFV Release 3 ongoing work<br />
#ETSI NFV Concepts and MANO Details ''(by ETSI NFV IFA WG)''<br />
## ETSI NFV Concepts<br />
##*Main Management and Orchestration concepts<br />
##*VNF overview<br />
##*VNF Package and VNF Descriptor<br />
##Virtual Network Function (VNF) Lifecycle Management (LCM)<br />
##*Managing the VNF lifecycle<br />
##Network Service (NS) LCM<br />
##*NS overview<br />
##*NS LCM interface<br />
##NS Descriptor (NSD) and VNF Package interfaces<br />
##*NSD overview<br />
##*NSD and VNF Package interfaces<br />
|-<br />
! scope="row" | 3:45 - 4:00pm<br />
| align = "left" | <br />
Break<br />
| align = "left" |<br />
|-<br />
! scope="row" | 4:00 - 6:00pm<br />
| align = "left" | <br />
NFV APIs Specfest Session<br />
<br />
| align = "left" |<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] overview ''(by ETSI NFV SOL WG)''<br />
#*VNF Management towards NFV Orchestrator<br />
#*VNF Management towards EM/VNF<br />
#*Network Service Management and VNF onboarding towards OSS/BSS<br />
#OpenAPI language and tools overview ''(by ETSI CTI)''<br />
#Hands-on on the ETSI forge, how to collaborate on OpenAPIs ''(by ETSI CTI)''<br />
#*Contribute an OpenAPI description of SOL specs to the Forge<br />
#*Learn how to use the online editor<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] in practice ''(by Nokia)''<br />
#*VNF Life Cycle Management testing based on OpenAPI files: a live demo<br />
#Future steps ''(by ETSI NFV SOL WG)''<br />
|}<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3241ETSI NFV Tutorial2017-09-04T18:49:54Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm(U.S. Mountain Time)), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
* Remote participation via GoToMeeting will be possible.<br />
<br />
== Registration==<br />
#To access to [https://portal.etsi.org/webapp/MeetingCalendar/MeetingDetails.asp?m_id=33257 NFV#19 - Tutorial & Specfest] and register. Or,<br />
#To send an e-mail to:<br />
#*Tetsuya Nakamura, CableLabs<br />
#*t.nakamura[at]cablelabs.com<br />
<br />
== Agenda ==<br />
*Date<br />
**September 11th, 2017, Monday 2:00-6:00pm(U.S. Mountain time)<br />
*Location<br />
**[http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], 7007 S Clinton St, Greenwood Village, CO 80112<br />
**[https://gotomeet.me/ETSINFVWebroom1 On-line via GoToMeeting]<br />
*Time table<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
! scope="col" style="width: 100px;"| Time<br />
! scope="col" | Topic<br />
! scope="col" | Details<br />
|-<br />
! scope="row" | 2:00 - 2:15pm<br />
| align = "left" | <br />
Welcome<br />
<br />
|<br />
|-<br />
! scope="row" | 2:15 - 3:45pm<br />
| align = "left" | <br />
Tutorial Session<br />
<br />
| align = "left" |<br />
#ETSI NFV Work Program ''(by ETSI NFV TSC)''<br />
#*Overview<br />
#**Key milestones<br />
#**Release highlights<br />
#*NFV Release 2 maintenance update<br />
#*NFV Release 3 ongoing work<br />
#Update on Interfaces and Architecture WIs (stable contents) in Release 3 ''(by ETSI NFV IFA WG)''<br />
#MANO concept & VNF Lifecycle Management ''(by ETSI NFV IFA WG)''<br />
#*An overview view of ETSI NFV MANO concept<br />
#*VNF lifecycle management<br />
#**What a VNF is and how it is described in the VNF descriptor, will introduce the main concepts and operations of VNF lifecycle management.<br />
|-<br />
! scope="row" | 3:45 - 4:00pm<br />
| align = "left" | <br />
Break<br />
| align = "left" |<br />
|-<br />
! scope="row" | 4:00 - 6:00pm<br />
| align = "left" | <br />
NFV APIs Specfest Session<br />
<br />
| align = "left" |<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] overview ''(by ETSI NFV SOL WG)''<br />
#*VNF Management towards NFV Orchestrator<br />
#*VNF Management towards EM/VNF<br />
#*Network Service Management and VNF onboarding towards OSS/BSS<br />
#OpenAPI language and tools overview ''(by ETSI CTI)''<br />
#Hands-on on the ETSI forge, how to collaborate on OpenAPIs ''(by ETSI CTI)''<br />
#*Contribute an OpenAPI description of SOL specs to the Forge<br />
#*Learn how to use the online editor<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] in practice ''(by Nokia)''<br />
#*VNF Life Cycle Management testing based on OpenAPI files: a live demo<br />
#Future steps ''(by ETSI NFV SOL WG)''<br />
|}<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3239ETSI NFV Tutorial2017-08-29T16:09:25Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm(U.S. Mountain Time)), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
* Remote participation via GoToMeeting will be possible.<br />
<br />
== Registration==<br />
#To access to [https://portal.etsi.org/webapp/MeetingCalendar/MeetingDetails.asp?m_id=33257 NFV#19 - Tutorial & Specfest] and register. Or,<br />
#To send an e-mail to:<br />
#*Tetsuya Nakamura, CableLabs<br />
#*t.nakamura[at]cablelabs.com<br />
<br />
== Agenda ==<br />
*Date<br />
**September 11th, 2017, Monday 2:00-6:00pm(U.S. Mountain time)<br />
*Location<br />
**[http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], 7007 S Clinton St, Greenwood Village, CO 80112<br />
**[https://gotomeet.me/ETSINFVWebroom1 On-line via GoToMeeting]<br />
*Time table<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
! scope="col" style="width: 100px;"| Time<br />
! scope="col" | Topic<br />
! scope="col" | Details<br />
|-<br />
! scope="row" | 2:00 - 2:15pm<br />
| align = "left" | <br />
Welcome<br />
<br />
|<br />
|-<br />
! scope="row" | 2:15 - 3:45pm<br />
| align = "left" | <br />
Tutorial Session<br />
<br />
| align = "left" |<br />
#ETSI NFV Work Program ''(by ETSI NFV TSC)''<br />
#*Overview<br />
#**Key milestones<br />
#**Release highlights<br />
#*NFV Release 2 maintenance update<br />
#*NFV Release 3 ongoing work<br />
#Update on Interfaces and Architecture WIs (stable contents) in Release 3 ''(by ETSI NFV IFA WG)''<br />
#MANO concept & VNF Lifecycle Management ''(by ETSI NFV IFA WG)''<br />
#*An overview view of ETSI NFV MANO concept<br />
#*VNF lifecycle management<br />
#**What a VNF is and how it is described in the VNF descriptor, will introduce the main concepts and operations of VNF lifecycle management.<br />
|-<br />
! scope="row" | 3:45 - 4:00pm<br />
| align = "left" | <br />
Break<br />
| align = "left" |<br />
|-<br />
! scope="row" | 4:00 - 6:00pm<br />
| align = "left" | <br />
NFV APIs Specfest Session<br />
<br />
| align = "left" |<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] overview ''(by ETSI NFV SOL WG)''<br />
#*VNF Management towards NFV Orchestrator<br />
#*VNF Management towards EM/VNF<br />
#*Network Service Management and VNF onboarding towards OSS/BSS<br />
#OpenAPI language and tools overview ''(by ETSI CTI)''<br />
#Hands-on on the ETSI forge, how to collaborate on OpenAPIs ''(by ETSI CTI)''<br />
#*Contributing code, triggering and improving CI/CD, bug reporting and fixing<br />
#Hack on [https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] ''(by ETSI CTI)''<br />
#*Generating a client / server stub, playing with test libraries, running them against an implementation<br />
|}<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3238ETSI NFV Tutorial2017-08-29T16:09:05Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm(U.S. Mountain Time), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
* Remote participation via GoToMeeting will be possible.<br />
<br />
== Registration==<br />
#To access to [https://portal.etsi.org/webapp/MeetingCalendar/MeetingDetails.asp?m_id=33257 NFV#19 - Tutorial & Specfest] and register. Or,<br />
#To send an e-mail to:<br />
#*Tetsuya Nakamura, CableLabs<br />
#*t.nakamura[at]cablelabs.com<br />
<br />
== Agenda ==<br />
*Date<br />
**September 11th, 2017, Monday 2:00-6:00pm(U.S. Mountain time)<br />
*Location<br />
**[http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], 7007 S Clinton St, Greenwood Village, CO 80112<br />
**[https://gotomeet.me/ETSINFVWebroom1 On-line via GoToMeeting]<br />
*Time table<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
! scope="col" style="width: 100px;"| Time<br />
! scope="col" | Topic<br />
! scope="col" | Details<br />
|-<br />
! scope="row" | 2:00 - 2:15pm<br />
| align = "left" | <br />
Welcome<br />
<br />
|<br />
|-<br />
! scope="row" | 2:15 - 3:45pm<br />
| align = "left" | <br />
Tutorial Session<br />
<br />
| align = "left" |<br />
#ETSI NFV Work Program ''(by ETSI NFV TSC)''<br />
#*Overview<br />
#**Key milestones<br />
#**Release highlights<br />
#*NFV Release 2 maintenance update<br />
#*NFV Release 3 ongoing work<br />
#Update on Interfaces and Architecture WIs (stable contents) in Release 3 ''(by ETSI NFV IFA WG)''<br />
#MANO concept & VNF Lifecycle Management ''(by ETSI NFV IFA WG)''<br />
#*An overview view of ETSI NFV MANO concept<br />
#*VNF lifecycle management<br />
#**What a VNF is and how it is described in the VNF descriptor, will introduce the main concepts and operations of VNF lifecycle management.<br />
|-<br />
! scope="row" | 3:45 - 4:00pm<br />
| align = "left" | <br />
Break<br />
| align = "left" |<br />
|-<br />
! scope="row" | 4:00 - 6:00pm<br />
| align = "left" | <br />
NFV APIs Specfest Session<br />
<br />
| align = "left" |<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] overview ''(by ETSI NFV SOL WG)''<br />
#*VNF Management towards NFV Orchestrator<br />
#*VNF Management towards EM/VNF<br />
#*Network Service Management and VNF onboarding towards OSS/BSS<br />
#OpenAPI language and tools overview ''(by ETSI CTI)''<br />
#Hands-on on the ETSI forge, how to collaborate on OpenAPIs ''(by ETSI CTI)''<br />
#*Contributing code, triggering and improving CI/CD, bug reporting and fixing<br />
#Hack on [https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] ''(by ETSI CTI)''<br />
#*Generating a client / server stub, playing with test libraries, running them against an implementation<br />
|}<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3237ETSI NFV Tutorial2017-08-29T16:00:45Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
* Remote participation via GoToMeeting will be possible.<br />
<br />
== Registration==<br />
#To access to [https://portal.etsi.org/webapp/MeetingCalendar/MeetingDetails.asp?m_id=33257 NFV#19 - Tutorial & Specfest] and register. Or,<br />
#To send an e-mail to:<br />
#*Tetsuya Nakamura, CableLabs<br />
#*t.nakamura[at]cablelabs.com<br />
<br />
== Agenda ==<br />
*Date<br />
**September 11th, 2017, Monday 2:00-6:00pm(USA Mountain time)<br />
*Location<br />
**[http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], 7007 S Clinton St, Greenwood Village, CO 80112<br />
**[https://gotomeet.me/ETSINFVWebroom1 On-line via GoToMeeting]<br />
*Time table<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
! scope="col" style="width: 100px;"| Time<br />
! scope="col" | Topic<br />
! scope="col" | Details<br />
|-<br />
! scope="row" | 2:00 - 2:15pm<br />
| align = "left" | <br />
Welcome<br />
<br />
|<br />
|-<br />
! scope="row" | 2:15 - 3:45pm<br />
| align = "left" | <br />
Tutorial Session<br />
<br />
| align = "left" |<br />
#ETSI NFV Work Program ''(by ETSI NFV TSC)''<br />
#*Overview<br />
#**Key milestones<br />
#**Release highlights<br />
#*NFV Release 2 maintenance update<br />
#*NFV Release 3 ongoing work<br />
#Update on Interfaces and Architecture WIs (stable contents) in Release 3 ''(by ETSI NFV IFA WG)''<br />
#MANO concept & VNF Lifecycle Management ''(by ETSI NFV IFA WG)''<br />
#*An overview view of ETSI NFV MANO concept<br />
#*VNF lifecycle management<br />
#**What a VNF is and how it is described in the VNF descriptor, will introduce the main concepts and operations of VNF lifecycle management.<br />
|-<br />
! scope="row" | 3:45 - 4:00pm<br />
| align = "left" | <br />
Break<br />
| align = "left" |<br />
|-<br />
! scope="row" | 4:00 - 6:00pm<br />
| align = "left" | <br />
NFV APIs Specfest Session<br />
<br />
| align = "left" |<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] overview ''(by ETSI NFV SOL WG)''<br />
#*VNF Management towards NFV Orchestrator<br />
#*VNF Management towards EM/VNF<br />
#*Network Service Management and VNF onboarding towards OSS/BSS<br />
#OpenAPI language and tools overview ''(by ETSI CTI)''<br />
#Hands-on on the ETSI forge, how to collaborate on OpenAPIs ''(by ETSI CTI)''<br />
#*Contributing code, triggering and improving CI/CD, bug reporting and fixing<br />
#Hack on [https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] ''(by ETSI CTI)''<br />
#*Generating a client / server stub, playing with test libraries, running them against an implementation<br />
|}<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3236ETSI NFV Tutorial2017-08-28T23:17:41Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
* Remote participation via GoToMeeting will be possible.<br />
<br />
== Registration==<br />
#To access to [https://portal.etsi.org/webapp/MeetingCalendar/MeetingDetails.asp?m_id=33257 NFV#19 - Tutorial & Specfest] and register. Or,<br />
#To send an e-mail to:<br />
#*Tetsuya Nakamura, CableLabs<br />
#*t.nakamura[at]cablelabs.com<br />
<br />
== Agenda ==<br />
*Date<br />
**September 11th, 2017, Monday 2:00-6:00pm<br />
*Location<br />
**[http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], 7007 S Clinton St, Greenwood Village, CO 80112<br />
**[https://gotomeet.me/ETSINFVWebroom1 On-line via GoToMeeting]<br />
*Time table<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
! scope="col" style="width: 100px;"| Time<br />
! scope="col" | Topic<br />
! scope="col" | Details<br />
|-<br />
! scope="row" | 2:00 - 2:15pm<br />
| align = "left" | <br />
Welcome<br />
<br />
|<br />
|-<br />
! scope="row" | 2:15 - 3:45pm<br />
| align = "left" | <br />
Tutorial Session<br />
<br />
| align = "left" |<br />
#ETSI NFV Work Program ''(by ETSI NFV TSC)''<br />
#*Overview<br />
#**Key milestones<br />
#**Release highlights<br />
#*NFV Release 2 maintenance update<br />
#*NFV Release 3 ongoing work<br />
#Update on Interfaces and Architecture WIs (stable contents) in Release 3 ''(by ETSI NFV IFA WG)''<br />
#MANO concept & VNF Lifecycle Management ''(by ETSI NFV IFA WG)''<br />
#*An overview view of ETSI NFV MANO concept<br />
#*VNF lifecycle management<br />
#**What a VNF is and how it is described in the VNF descriptor, will introduce the main concepts and operations of VNF lifecycle management.<br />
|-<br />
! scope="row" | 3:45 - 4:00pm<br />
| align = "left" | <br />
Break<br />
| align = "left" |<br />
|-<br />
! scope="row" | 4:00 - 6:00pm<br />
| align = "left" | <br />
NFV APIs Specfest Session<br />
<br />
| align = "left" |<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] overview ''(by ETSI NFV SOL WG)''<br />
#*VNF Management towards NFV Orchestrator<br />
#*VNF Management towards EM/VNF<br />
#*Network Service Management and VNF onboarding towards OSS/BSS<br />
#OpenAPI language and tools overview ''(by ETSI CTI)''<br />
#Hands-on on the ETSI forge, how to collaborate on OpenAPIs ''(by ETSI CTI)''<br />
#*Contributing code, triggering and improving CI/CD, bug reporting and fixing<br />
#Hack on [https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] ''(by ETSI CTI)''<br />
#*Generating a client / server stub, playing with test libraries, running them against an implementation<br />
|}<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=NFV_Solutions&diff=3207NFV Solutions2017-08-08T15:31:03Z<p>Nakamurate: </p>
<hr />
<div>== NFV solutions goal ==<br />
Enable an open ecosystem where VNFs and Network Services are interoperable with independently developed NFV management and orchestration systems and where the components of these systems are themselves interoperable.<br />
<br />
===[[APIspec | API specifications (NFV-SOL 002, 003, 005)]]===<br />
<br />
===[[DeploymentTemplates | Deployment templates and packaging specifications (NFV-SOL 001, 004)]] ===<br />
<br />
[[File:SOLdeliverables.png | upright=3.5 | thumb | left ]]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3206ETSI NFV Tutorial2017-08-02T01:32:08Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
*Please send a message to contact below for registration.<br />
<br />
== Contact==<br />
*Tetsuya Nakamura, CableLabs<br />
*t.nakamura[at]cablelabs.com<br />
<br />
== Agenda ==<br />
*Date<br />
**September 11th, 2017, Monday 2:00-6:00pm<br />
*Location<br />
**[http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel]<br />
**7007 S Clinton St, Greenwood Village, CO 80112<br />
*Time table<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
! scope="col" style="width: 100px;"| Time<br />
! scope="col" | Topic<br />
! scope="col" | Details<br />
|-<br />
! scope="row" | 2:00 - 2:15pm<br />
| align = "left" | <br />
Welcome<br />
<br />
|<br />
|-<br />
! scope="row" | 2:15 - 3:45pm<br />
| align = "left" | <br />
Tutorial Session<br />
<br />
| align = "left" |<br />
#ETSI NFV Work Program ''(by ETSI NFV TSC)''<br />
#*Overview<br />
#**Key milestones<br />
#**Release highlights<br />
#*NFV Release 2 maintenance update<br />
#*NFV Release 3 ongoing work<br />
#Update on Interfaces and Architecture WIs (stable contents) in Release 3 ''(by ETSI NFV IFA WG)''<br />
#MANO concept & VNF Lifecycle Management ''(by ETSI NFV IFA WG)''<br />
#*An overview view of ETSI NFV MANO concept<br />
#*VNF lifecycle management<br />
#**What a VNF is and how it is described in the VNF descriptor, will introduce the main concepts and operations of VNF lifecycle management.<br />
|-<br />
! scope="row" | 3:45 - 4:00pm<br />
| align = "left" | <br />
Break<br />
| align = "left" |<br />
|-<br />
! scope="row" | 4:00 - 6:00pm<br />
| align = "left" | <br />
NFV APIs Specfest Session<br />
<br />
| align = "left" |<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] overview ''(by ETSI NFV SOL WG)''<br />
#*VNF Management towards NFV Orchestrator<br />
#*VNF Management towards EM/VNF<br />
#*Network Service Management and VNF onboarding towards OSS/BSS<br />
#OpenAPI language and tools overview ''(by ETSI CTI)''<br />
#Hands-on on the ETSI forge, how to collaborate on OpenAPIs ''(by ETSI CTI)''<br />
#*Contributing code, triggering and improving CI/CD, bug reporting and fixing<br />
#Hack on [https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] ''(by ETSI CTI)''<br />
#*Generating a client / server stub, playing with test libraries, running them against an implementation<br />
|}<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3205ETSI NFV Tutorial2017-08-02T01:18:33Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
*Please send a message to contact below for registration.<br />
<br />
== Contact==<br />
*Tetsuya Nakamura, CableLabs<br />
*t.nakamura[at]cablelabs.com<br />
<br />
== Agenda ==<br />
*Date<br />
**September 11th, 2017, Monday 2:00-6:00pm<br />
*Location<br />
**[http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel]<br />
**7007 S Clinton St, Greenwood Village, CO 80112<br />
*Time table<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Topic<br />
! scope="col" | Details<br />
|-<br />
! scope="row" | 2:00 - 2:15pm<br />
| align = "left" | <br />
Welcome<br />
<br />
|<br />
|-<br />
! scope="row" | 2:15 - 3:45pm<br />
| align = "left" | <br />
Tutorial Session<br />
<br />
| align = "left" |<br />
#ETSI NFV Work Program ''(by ETSI NFV TSC)''<br />
#*Overview<br />
#**Key milestones<br />
#**Release highlights<br />
#*NFV Release 2 maintenance update<br />
#*NFV Release 3 ongoing work<br />
#Update on Interfaces and Architecture WIs (stable contents) in Release 3 ''(by ETSI NFV IFA WG)''<br />
#MANO concept & VNF Lifecycle Management ''(by ETSI NFV IFA WG)''<br />
#*An overview view of ETSI NFV MANO concept<br />
#*VNF lifecycle management<br />
#**What a VNF is and how it is described in the VNF descriptor, will introduce the main concepts and operations of VNF lifecycle management.<br />
|-<br />
! scope="row" | 3:45 - 4:00pm<br />
| align = "left" | <br />
Break<br />
| align = "left" |<br />
|-<br />
! scope="row" | 4:00 - 6:00pm<br />
| align = "left" | <br />
NFV APIs Specfest Session<br />
<br />
| align = "left" |<br />
#[https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] overview ''(by ETSI NFV SOL WG)''<br />
#*VNF Management towards NFV Orchestrator<br />
#*VNF Management towards EM/VNF<br />
#*Network Service Management and VNF onboarding towards OSS/BSS<br />
#OpenAPI language and tools overview ''(by ETSI CTI)''<br />
#Hands-on on the ETSI forge, how to collaborate on OpenAPIs ''(by ETSI CTI)''<br />
#*Contributing code, triggering and improving CI/CD, bug reporting and fixing<br />
#Hack on [https://nfvwiki.etsi.org/index.php?title=NFVSolutions The NFV REST APIs] ''(by ETSI CTI)''<br />
#*Generating a client / server stub, playing with test libraries, running them against an implementation<br />
|}<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3204ETSI NFV Tutorial2017-08-02T00:53:21Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
*Please send a message to contact below for registration.<br />
<br />
== Contact==<br />
*Tetsuya Nakamura, CableLabs<br />
*t.nakamura[at]cablelabs.com<br />
<br />
<br><br />
<br />
== Agenda ==<br />
*Date<br />
**September 11th, 2017, Monday 2:00-6:00pm<br />
*Location<br />
**[http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel]<br />
**7007 S Clinton St, Greenwood Village, CO 80112<br />
*Time table<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Topic<br />
! scope="col" | Details<br />
|-<br />
! scope="row" | 2:00 - 2:15pm<br />
| align = "left" | <br />
The structure and format of a VNF Package based on OASIS Cloud Service Archive (CSAR)specification<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011]<br />
<br />
| [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/004/02.03.01_60/gs_nfv-sol004v020301p.pdf Published specification]<br />
|}<br />
<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3203ETSI NFV Tutorial2017-08-02T00:42:55Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
*Please send a message to contact below for registration.<br />
<br />
== Contact==<br />
*Tetsuya Nakamura, CableLabs<br />
*t.nakamura[at]cablelabs.com<br />
<br />
<br><br />
<br />
== Agenda ==<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | VNF Package <br> (NFV-SOL 004)<br />
| align = "left" | <br />
The structure and format of a VNF Package based on OASIS Cloud Service Archive (CSAR)specification<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011]<br />
<br />
| [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/004/02.03.01_60/gs_nfv-sol004v020301p.pdf Published specification]<br />
| Work In Progress<br />
|}<br />
<br />
== Deployment templates ==<br />
<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | Deployment templates <br> (NFV-SOL 001)<br />
| align = "left" | <br />
NFV Descriptors including NSD (Network Service Descriptor) and VNFD (VNF Descriptor) based on TOSCA<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011] and [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/014/02.01.01_60/gs_NFV-IFA014v020101p.pdf ETSI GS NFV-IFA 014] <br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL001_TOSCA_desc/NFV-SOL001v002.zip Draft]<br />
| Work In Progress<br />
|}<br />
<br />
== Tutorials ==<br />
Links to tutorials and webinars<br />
<br />
*[https://www.brighttalk.com/webcast/12761/265769 VNF Packaging]<br />
<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3202ETSI NFV Tutorial2017-08-02T00:39:23Z<p>Nakamurate: </p>
<hr />
<div>== Invitation to ETSI NFV Tutorials & Specfest ==<br />
*The 19th plenary meeting of the ETSI NFV-ISG will be held at the [http://www.sheratondenvertech.com Sheraton Denver Tech Center Hotel], Denver-Colorado, September 12- 15, 2017.<br />
*On Monday September 11 (2:00 – 6:00pm), a special tutorial session will be held.<br />
*'''Attendance is free of charge. Both ETSI and non-ETSI member are welcome. No need to register with the ETSI NFV-ISG meeting.'''<br />
*Please send a message to contact below for registration.<br />
<br />
== Contact==<br />
*Tetsuya Nakamura, CableLabs<br />
*t.nakamura[at]cablelabs.com<br />
<br />
== VNF package ==<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | VNF Package <br> (NFV-SOL 004)<br />
| align = "left" | <br />
The structure and format of a VNF Package based on OASIS Cloud Service Archive (CSAR)specification<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011]<br />
<br />
| [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/004/02.03.01_60/gs_nfv-sol004v020301p.pdf Published specification]<br />
| Work In Progress<br />
|}<br />
<br />
== Deployment templates ==<br />
<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | Deployment templates <br> (NFV-SOL 001)<br />
| align = "left" | <br />
NFV Descriptors including NSD (Network Service Descriptor) and VNFD (VNF Descriptor) based on TOSCA<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011] and [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/014/02.01.01_60/gs_NFV-IFA014v020101p.pdf ETSI GS NFV-IFA 014] <br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL001_TOSCA_desc/NFV-SOL001v002.zip Draft]<br />
| Work In Progress<br />
|}<br />
<br />
== Tutorials ==<br />
Links to tutorials and webinars<br />
<br />
*[https://www.brighttalk.com/webcast/12761/265769 VNF Packaging]<br />
<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial&diff=3201ETSI NFV Tutorial2017-08-02T00:20:08Z<p>Nakamurate: Created page with "== Overview == There is a need for a uniform way for VNF providers to deliver VNFs to service providers and making the delivery simple, effective and efficient. == VNF packa..."</p>
<hr />
<div>== Overview ==<br />
There is a need for a uniform way for VNF providers to deliver VNFs to service providers and making the delivery simple, effective and efficient.<br />
<br />
<br />
== VNF package ==<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | VNF Package <br> (NFV-SOL 004)<br />
| align = "left" | <br />
The structure and format of a VNF Package based on OASIS Cloud Service Archive (CSAR)specification<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011]<br />
<br />
| [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/004/02.03.01_60/gs_nfv-sol004v020301p.pdf Published specification]<br />
| Work In Progress<br />
|}<br />
<br />
== Deployment templates ==<br />
<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | Deployment templates <br> (NFV-SOL 001)<br />
| align = "left" | <br />
NFV Descriptors including NSD (Network Service Descriptor) and VNFD (VNF Descriptor) based on TOSCA<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011] and [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/014/02.01.01_60/gs_NFV-IFA014v020101p.pdf ETSI GS NFV-IFA 014] <br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL001_TOSCA_desc/NFV-SOL001v002.zip Draft]<br />
| Work In Progress<br />
|}<br />
<br />
== Tutorials ==<br />
Links to tutorials and webinars<br />
<br />
*[https://www.brighttalk.com/webcast/12761/265769 VNF Packaging]<br />
<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=NFV_Solutions&diff=3200NFV Solutions2017-08-01T21:10:15Z<p>Nakamurate: </p>
<hr />
<div>== NFV solutions goal ==<br />
Enable an open ecosystem where VNFs and Network Services are interoperable with independently developed NFV management and orchestration systems and where the components of these systems are themselves interoperable.<br />
<br />
===[[APIspec | API specifications (SOL002, SOL003, SOL005)]]===<br />
<br />
===[[DeploymentTemplates | Deployment templates and packaging specifications (SOL001, SOL004)]] ===<br />
<br />
[[File:SOLdeliverables.png | upright=3.5 | thumb | left ]]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=NFV_Solutions&diff=3199NFV Solutions2017-08-01T21:07:08Z<p>Nakamurate: </p>
<hr />
<div>== NFV solutions goal ==<br />
Enable an open ecosystem where VNFs and Network Services are interoperable with independently developed NFV management and orchestration systems and where the components of these systems are themselves interoperable.<br />
<br />
===[[APIspec | API specifications]]===<br />
<br />
===[[DeploymentTemplates | Deployment templates and packaging specifications]] ===<br />
<br />
[[File:SOLdeliverables.png | upright=3.5 | thumb | left ]]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=NFV_Solutions&diff=3198NFV Solutions2017-08-01T21:06:20Z<p>Nakamurate: </p>
<hr />
<div>== NFV solutions goal ==<br />
Enable an open ecosystem where VNFs and Network Services are interoperable with independently developed NFV management and orchestration systems and where the components of these systems are themselves interoperable.<br />
<br />
===[[APIspec | API specifications]]===<br />
<br />
===[[DeploymentTemplates | Deployment templates and packaging specifications]] ===<br />
<br />
[[File:SOLdeliverables.png | upright=4 | thumb | left ]]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=Deployment_Templates_and_Packaging_specifications&diff=3197Deployment Templates and Packaging specifications2017-08-01T20:32:39Z<p>Nakamurate: /* VNF package */</p>
<hr />
<div>== Overview ==<br />
There is a need for a uniform way for VNF providers to deliver VNFs to service providers and making the delivery simple, effective and efficient.<br />
<br />
<br />
== VNF package ==<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | VNF Package <br> (NFV-SOL 004)<br />
| align = "left" | <br />
The structure and format of a VNF Package based on OASIS Cloud Service Archive (CSAR)specification<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011]<br />
<br />
| [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/004/02.03.01_60/gs_nfv-sol004v020301p.pdf Published specification]<br />
| Work In Progress<br />
|}<br />
<br />
== Deployment templates ==<br />
<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | Deployment templates <br> (NFV-SOL 001)<br />
| align = "left" | <br />
NFV Descriptors including NSD (Network Service Descriptor) and VNFD (VNF Descriptor) based on TOSCA<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011] and [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/014/02.01.01_60/gs_NFV-IFA014v020101p.pdf ETSI GS NFV-IFA 014] <br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL001_TOSCA_desc/NFV-SOL001v002.zip Draft]<br />
| Work In Progress<br />
|}<br />
<br />
== Tutorials ==<br />
Links to tutorials and webinars<br />
<br />
*[https://www.brighttalk.com/webcast/12761/265769 VNF Packaging]<br />
<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=Deployment_Templates_and_Packaging_specifications&diff=3196Deployment Templates and Packaging specifications2017-08-01T20:31:59Z<p>Nakamurate: </p>
<hr />
<div>== Overview ==<br />
There is a need for a uniform way for VNF providers to deliver VNFs to service providers and making the delivery simple, effective and efficient.<br />
<br />
<br />
== VNF package ==<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | VNF Package <br> (NFV-SOL 004)<br />
| align = "left" | <br />
ETSI GS NFV-SOL 004 specifies the structure and format of a VNF Package based on OASIS Cloud Service Archive (CSAR)specification<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011]<br />
<br />
| [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/004/02.03.01_60/gs_nfv-sol004v020301p.pdf Published specification]<br />
| Work In Progress<br />
|}<br />
<br />
<br />
== Deployment templates ==<br />
<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | Deployment templates <br> (NFV-SOL 001)<br />
| align = "left" | <br />
NFV Descriptors including NSD (Network Service Descriptor) and VNFD (VNF Descriptor) based on TOSCA<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011] and [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/014/02.01.01_60/gs_NFV-IFA014v020101p.pdf ETSI GS NFV-IFA 014] <br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL001_TOSCA_desc/NFV-SOL001v002.zip Draft]<br />
| Work In Progress<br />
|}<br />
<br />
== Tutorials ==<br />
Links to tutorials and webinars<br />
<br />
*[https://www.brighttalk.com/webcast/12761/265769 VNF Packaging]<br />
<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=API_specifications&diff=3195API specifications2017-08-01T20:31:10Z<p>Nakamurate: </p>
<hr />
<div>== API conventions==<br />
<br />
*[https://nfvwiki.etsi.org/images/NFVSOL%2817%29000050r4_ETSI_NFV_SOL_REST_API_Conventions.pdf ETSI NFV SOL API Conventions]<br />
<br />
<br />
<br />
== API specifications ==<br />
<br />
{| class="wikitable alternance center"<br />
|+ APIs exposed on MANO reference points<br />
|-<br />
|<br />
! scope="col" | APIs <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Swagger<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | Ve-Vnfm <br> (NFV-SOL 002)<br />
| align = "left" | <br />
VNF Lifecycle Management interface (as produced by the VNFM towards the EM/VNF)<br />
<br />
VNF Performance Management interface (as produced by the VNFM towards the EM)<br />
<br />
VNF Fault Management interface (as produced by the VNFM towards the EM)<br />
<br />
VNF Indicator interface (as produced by the EM/VNF towards the VNFM)<br />
<br />
VNF Configuration interface (as produced by the VNF towards the VNFM)<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/008/02.01.01_60/gs_NFV-IFA008v020101p.pdf ETSI GS NFV-IFA 008]<br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL002_Ve-Vnfm_protocols Draft]<br />
| Work In Progress<br />
| Work In Progress<br />
|-<br />
! scope="row" | Or-Vnfm <br> (NFV-SOL 003)<br />
| align = "left" | <br />
VNF Lifecycle Management interface (as produced by the VNFM towards the NFVO).<br />
<br />
VNF Performance Management interface (as produced by the VNFM towards the NFVO).<br />
<br />
VNF Fault Management interface (as produced by the VNFM towards the NFVO).<br />
<br />
VNF Indicator interface (as produced by the VNFM towards the NFVO).<br />
<br />
VNF Lifecycle Operation Granting interface (as produced by the NFVO towards the VNFM).<br />
<br />
VNF Package Management interface (as produced by the NFVO towards the VNFM).<br />
<br />
Virtualised Resources Quota Available Notification interface (as produced by the NFVO towards the VNFM).<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/007/02.01.01_60/gs_NFV-IFA007v020101p.pdf ETSI GS NFV-IFA 007]<br />
<br />
| [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.03.01_60/gs_NFV-SOL003v020301p.pdf Published specification]<br />
| Work In Progress<br />
| Work In Progress<br />
|-<br />
! scope="row" | Os-Ma-Nfvo <br> (NFV-SOL 005)<br />
| align = "left" | <br />
NSD Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
NS Lifecycle Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
NS Performance Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
NS Fault Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
VNF Package Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/013/02.01.01_60/gs_NFV-IFA013v020101p.pdf ETSI GS NFV-IFA 013]<br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL005_Os-Ma-nfvo_APIs Draft]<br />
| Work In Progress<br />
| Work In Progress<br />
|}<br />
<br />
== Tutorials ==<br />
<br />
Links to tutorials and webinars<br />
<br />
*[https://www.brighttalk.com/webcast/6985/263719/common-api-for-nfv-interop Webinar on APIs for interoperability]<br />
<br />
<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=API_specifications&diff=3194API specifications2017-08-01T20:00:00Z<p>Nakamurate: </p>
<hr />
<div>== API conventions==<br />
<br />
*[https://nfvwiki.etsi.org/images/NFVSOL%2817%29000050r4_ETSI_NFV_SOL_REST_API_Conventions.pdf ETSI NFV SOL API Conventions]<br />
<br />
<br />
<br />
== API specifications ==<br />
<br />
{| class="wikitable alternance center"<br />
|+ APIs exposed on MANO reference points<br />
|-<br />
|<br />
! scope="col" | APIs <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Swagger<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | Ve-Vnfm (NFV-SOL 002)<br />
| align = "left" | <br />
VNF Lifecycle Management interface (as produced by the VNFM towards the EM/VNF)<br />
<br />
VNF Performance Management interface (as produced by the VNFM towards the EM)<br />
<br />
VNF Fault Management interface (as produced by the VNFM towards the EM)<br />
<br />
VNF Indicator interface (as produced by the EM/VNF towards the VNFM)<br />
<br />
VNF Configuration interface (as produced by the VNF towards the VNFM)<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/008/02.01.01_60/gs_NFV-IFA008v020101p.pdf ETSI GS NFV-IFA 008]<br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL002_Ve-Vnfm_protocols Draft]<br />
| Work In Progress<br />
| Work In Progress<br />
|-<br />
! scope="row" | Or-Vnfm (NFV-SOL 003)<br />
| align = "left" | <br />
VNF Lifecycle Management interface (as produced by the VNFM towards the NFVO).<br />
<br />
VNF Performance Management interface (as produced by the VNFM towards the NFVO).<br />
<br />
VNF Fault Management interface (as produced by the VNFM towards the NFVO).<br />
<br />
VNF Indicator interface (as produced by the VNFM towards the NFVO).<br />
<br />
VNF Lifecycle Operation Granting interface (as produced by the NFVO towards the VNFM).<br />
<br />
VNF Package Management interface (as produced by the NFVO towards the VNFM).<br />
<br />
Virtualised Resources Quota Available Notification interface (as produced by the NFVO towards the VNFM).<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/007/02.01.01_60/gs_NFV-IFA007v020101p.pdf ETSI GS NFV-IFA 007]<br />
<br />
| [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.03.01_60/gs_NFV-SOL003v020301p.pdf Published specification]<br />
| Work In Progress<br />
| Work In Progress<br />
|-<br />
! scope="row" | Os-Ma-Nfvo (NFV-SOL 005)<br />
| align = "left" | <br />
NSD Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
NS Lifecycle Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
NS Performance Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
NS Fault Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
VNF Package Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/013/02.01.01_60/gs_NFV-IFA013v020101p.pdf ETSI GS NFV-IFA 013]<br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL005_Os-Ma-nfvo_APIs Draft]<br />
| Work In Progress<br />
| Work In Progress<br />
|}<br />
<br />
== Tutorials ==<br />
<br />
Links to tutorials and webinars<br />
<br />
*[https://www.brighttalk.com/webcast/6985/263719/common-api-for-nfv-interop Webinar on APIs for interoperability]<br />
<br />
<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=Deployment_Templates_and_Packaging_specifications&diff=3193Deployment Templates and Packaging specifications2017-08-01T19:48:37Z<p>Nakamurate: </p>
<hr />
<div>== Overview ==<br />
There is a need for a uniform way for VNF providers to deliver VNFs to service providers and making the delivery simple, effective and efficient.<br />
<br />
<br />
== VNF package ==<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | VNF Package (NFV-SOL 004)<br />
| align = "left" | <br />
ETSI GS NFV-SOL 004 specifies the structure and format of a VNF Package based on OASIS Cloud Service Archive (CSAR)specification<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011]<br />
<br />
| [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/004/02.03.01_60/gs_nfv-sol004v020301p.pdf Published specification]<br />
| Work In Progress<br />
|}<br />
<br />
<br />
== Deployment templates ==<br />
<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | Deployment templates (NFV-SOL 001)<br />
| align = "left" | <br />
NFV Descriptors including NSD (Network Service Descriptor) and VNFD (VNF Descriptor) based on TOSCA<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011] and [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/014/02.01.01_60/gs_NFV-IFA014v020101p.pdf ETSI GS NFV-IFA 014] <br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL001_TOSCA_desc/NFV-SOL001v002.zip Draft]<br />
| Work In Progress<br />
|}<br />
<br />
== Tutorials ==<br />
Links to tutorials and webinars<br />
<br />
*[https://www.brighttalk.com/webcast/12761/265769 VNF Packaging]<br />
<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=Deployment_Templates_and_Packaging_specifications&diff=3192Deployment Templates and Packaging specifications2017-08-01T19:47:37Z<p>Nakamurate: </p>
<hr />
<div>== Overview ==<br />
There is a need for a uniform way for VNF providers to deliver VNFs to service providers and making the delivery simple, effective and efficient.<br />
<br />
<br />
== VNF package ==<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Swagger<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | VNF Package (NFV-SOL 004)<br />
| align = "left" | <br />
ETSI GS NFV-SOL 004 specifies the structure and format of a VNF Package based on OASIS Cloud Service Archive (CSAR)specification<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011]<br />
<br />
| [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/004/02.03.01_60/gs_nfv-sol004v020301p.pdf Published specification]<br />
| Work In Progress<br />
| Work In Progress<br />
|}<br />
<br />
<br />
== Deployment templates ==<br />
<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Swagger<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | Deployment templates (NFV-SOL 001)<br />
| align = "left" | <br />
NFV Descriptors including NSD (Network Service Descriptor) and VNFD (VNF Descriptor) based on TOSCA<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011] and [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/014/02.01.01_60/gs_NFV-IFA014v020101p.pdf ETSI GS NFV-IFA 014] <br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL001_TOSCA_desc/NFV-SOL001v002.zip Draft]<br />
| Work In Progress<br />
| Work In Progress<br />
|}<br />
<br />
== Tutorials ==<br />
Links to tutorials and webinars<br />
<br />
*[https://www.brighttalk.com/webcast/12761/265769 VNF Packaging]<br />
<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=API_specifications&diff=3191API specifications2017-08-01T19:42:06Z<p>Nakamurate: </p>
<hr />
<div>== API conventions==<br />
<br />
*[https://nfvwiki.etsi.org/images/NFVSOL%2817%29000050r4_ETSI_NFV_SOL_REST_API_Conventions.pdf API Conventions draft (as of July 31, 2017)]<br />
<br />
<br />
<br />
== API specifications ==<br />
<br />
{| class="wikitable alternance center"<br />
|+ APIs exposed on MANO reference points<br />
|-<br />
|<br />
! scope="col" | APIs <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Swagger<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | Ve-Vnfm (NFV-SOL 002)<br />
| align = "left" | <br />
VNF Lifecycle Management interface (as produced by the VNFM towards the EM/VNF)<br />
<br />
VNF Performance Management interface (as produced by the VNFM towards the EM)<br />
<br />
VNF Fault Management interface (as produced by the VNFM towards the EM)<br />
<br />
VNF Indicator interface (as produced by the EM/VNF towards the VNFM)<br />
<br />
VNF Configuration interface (as produced by the VNF towards the VNFM)<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/008/02.01.01_60/gs_NFV-IFA008v020101p.pdf ETSI GS NFV-IFA 008]<br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL002_Ve-Vnfm_protocols Draft]<br />
| Work In Progress<br />
| Work In Progress<br />
|-<br />
! scope="row" | Or-Vnfm (NFV-SOL 003)<br />
| align = "left" | <br />
VNF Lifecycle Management interface (as produced by the VNFM towards the NFVO).<br />
<br />
VNF Performance Management interface (as produced by the VNFM towards the NFVO).<br />
<br />
VNF Fault Management interface (as produced by the VNFM towards the NFVO).<br />
<br />
VNF Indicator interface (as produced by the VNFM towards the NFVO).<br />
<br />
VNF Lifecycle Operation Granting interface (as produced by the NFVO towards the VNFM).<br />
<br />
VNF Package Management interface (as produced by the NFVO towards the VNFM).<br />
<br />
Virtualised Resources Quota Available Notification interface (as produced by the NFVO towards the VNFM).<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/007/02.01.01_60/gs_NFV-IFA007v020101p.pdf ETSI GS NFV-IFA 007]<br />
<br />
| [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.03.01_60/gs_NFV-SOL003v020301p.pdf Published specification]<br />
| Work In Progress<br />
| Work In Progress<br />
|-<br />
! scope="row" | Os-Ma-Nfvo (NFV-SOL 005)<br />
| align = "left" | <br />
NSD Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
NS Lifecycle Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
NS Performance Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
NS Fault Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
VNF Package Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/013/02.01.01_60/gs_NFV-IFA013v020101p.pdf ETSI GS NFV-IFA 013]<br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL005_Os-Ma-nfvo_APIs Draft]<br />
| Work In Progress<br />
| Work In Progress<br />
|}<br />
<br />
== Tutorials ==<br />
<br />
Links to tutorials and webinars<br />
<br />
*[https://www.brighttalk.com/webcast/6985/263719/common-api-for-nfv-interop Webinar on APIs for interoperability]<br />
<br />
<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=API_specifications&diff=3190API specifications2017-08-01T19:13:19Z<p>Nakamurate: </p>
<hr />
<div>== API conventions==<br />
<br />
*[https://nfvwiki.etsi.org/images/NFVSOL%2817%29000050r4_ETSI_NFV_SOL_REST_API_Conventions.pdf API Conventions draft (as of July 31, 2017)]<br />
<br />
<br />
<br />
== API specifications ==<br />
<br />
{| class="wikitable alternance center"<br />
|+ APIs exposed on MANO reference points<br />
|-<br />
|<br />
! scope="col" | APIs <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Swagger<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | Ve-Vnfm<br />
| align = "left" | <br />
VNF Lifecycle Management interface (as produced by the VNFM towards the EM/VNF)<br />
<br />
VNF Performance Management interface (as produced by the VNFM towards the EM)<br />
<br />
VNF Fault Management interface (as produced by the VNFM towards the EM)<br />
<br />
VNF Indicator interface (as produced by the EM/VNF towards the VNFM)<br />
<br />
VNF Configuration interface (as produced by the VNF towards the VNFM)<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/008/02.01.01_60/gs_NFV-IFA008v020101p.pdf ETSI GS NFV-IFA 008]<br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL002_Ve-Vnfm_protocols Draft]<br />
| Work In Progress<br />
| Work In Progress<br />
|-<br />
! scope="row" | Or-Vnfm<br />
| align = "left" | <br />
VNF Lifecycle Management interface (as produced by the VNFM towards the NFVO).<br />
<br />
VNF Performance Management interface (as produced by the VNFM towards the NFVO).<br />
<br />
VNF Fault Management interface (as produced by the VNFM towards the NFVO).<br />
<br />
VNF Indicator interface (as produced by the VNFM towards the NFVO).<br />
<br />
VNF Lifecycle Operation Granting interface (as produced by the NFVO towards the VNFM).<br />
<br />
VNF Package Management interface (as produced by the NFVO towards the VNFM).<br />
<br />
Virtualised Resources Quota Available Notification interface (as produced by the NFVO towards the VNFM).<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/007/02.01.01_60/gs_NFV-IFA007v020101p.pdf ETSI GS NFV-IFA 007]<br />
<br />
| [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.03.01_60/gs_NFV-SOL003v020301p.pdf Published specification]<br />
| Work In Progress<br />
| Work In Progress<br />
|-<br />
! scope="row" | Os-Ma-Nfvo<br />
| align = "left" | <br />
NSD Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
NS Lifecycle Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
NS Performance Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
NS Fault Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
VNF Package Management interface (as produced by the NFVO towards the OSS/BSS)<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/013/02.01.01_60/gs_NFV-IFA013v020101p.pdf ETSI GS NFV-IFA 013]<br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL005_Os-Ma-nfvo_APIs Draft]<br />
| Work In Progress<br />
| Work In Progress<br />
|}<br />
<br />
== Tutorials ==<br />
<br />
Links to tutorials and webinars<br />
<br />
*[https://www.brighttalk.com/webcast/6985/263719/common-api-for-nfv-interop Webinar on APIs for interoperability]<br />
<br />
<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=Deployment_Templates_and_Packaging_specifications&diff=3189Deployment Templates and Packaging specifications2017-08-01T18:54:20Z<p>Nakamurate: </p>
<hr />
<div>== Overview ==<br />
There is a need for a uniform way for VNF providers to deliver VNFs to service providers and making the delivery simple, effective and efficient.<br />
<br />
<br />
== VNF package ==<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Swagger<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | VNF Package<br />
| align = "left" | <br />
ETSI GS NFV-SOL 004 specifies the structure and format of a VNF Package based on OASIS Cloud Service Archive (CSAR)specification<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011]<br />
<br />
| [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/004/02.03.01_60/gs_nfv-sol004v020301p.pdf Published specification]<br />
| Work In Progress<br />
| Work In Progress<br />
|}<br />
<br />
<br />
== Deployment templates ==<br />
<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Swagger<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | Deployment templates<br />
| align = "left" | <br />
NFV Descriptors including NSD (Network Service Descriptor) and VNFD (VNF Descriptor) based on TOSCA<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011] and [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/014/02.01.01_60/gs_NFV-IFA014v020101p.pdf ETSI GS NFV-IFA 014] <br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL001_TOSCA_desc/NFV-SOL001v002.zip Draft]<br />
| Work In Progress<br />
| Work In Progress<br />
|}<br />
<br />
== Tutorials ==<br />
Links to tutorials and webinars<br />
<br />
*[https://www.brighttalk.com/webcast/12761/265769 VNF Packaging]<br />
<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=Deployment_Templates_and_Packaging_specifications&diff=3188Deployment Templates and Packaging specifications2017-08-01T18:19:40Z<p>Nakamurate: </p>
<hr />
<div>== Overview ==<br />
There is a need for a uniform way for VNF providers to deliver VNFs to service providers and making the delivery simple, effective and efficient.<br />
<br />
<br />
== VNF package ==<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Swagger<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | VNF Package<br />
| align = "left" | <br />
ETSI GS NFV-SOL 004 specifies the structure and format of a VNF Package based on OASIS Cloud Service Archive (CSAR)specification<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011]<br />
<br />
| [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/004/02.03.01_60/gs_nfv-sol004v020301p.pdf Published specification]<br />
| Work In Progress<br />
| Work In Progress<br />
|}<br />
<br />
<br />
== Deployment templates ==<br />
<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1/Draft<br />
! scope="col" | Swagger<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | Deployment templates<br />
| align = "left" | <br />
NFV Descriptors including NSD (Network Service Descriptor) and VNFD (VNF Descriptor) based on TOSCA<br />
<br />
| [https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL001_TOSCA_desc/NFV-SOL001v002.zip Draft]<br />
| Work In Progress<br />
| Work In Progress<br />
|}<br />
<br />
== Tutorials ==<br />
Links to tutorials and webinars<br />
<br />
*[https://www.brighttalk.com/webcast/12761/265769 VNF Packaging]<br />
<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamuratehttps://nfvwiki.etsi.org/index.php?title=Deployment_Templates_and_Packaging_specifications&diff=3187Deployment Templates and Packaging specifications2017-08-01T18:06:49Z<p>Nakamurate: </p>
<hr />
<div>== Overview ==<br />
There is a need for a uniform way for VNF providers to deliver VNFs to service providers and making the delivery simple, effective and efficient.<br />
<br />
<br />
== VNF package ==<br />
<br />
<br />
{| class="wikitable alternance center"<br />
|-<br />
|<br />
! scope="col" | Descriptions <br />
! scope="col" | Release v2.3.1<br />
! scope="col" | Swagger<br />
! scope="col" | Bug Tracker<br />
|-<br />
! scope="row" | VNF Package<br />
| align = "left" | <br />
ETSI GS NFV-SOL 004 specifies the structure and format of a VNF Package based on OASIS Cloud Service Archive (CSAR)specification<br />
<br />
This specification fulfills the requirements specified in [http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_nfv-ifa011v020101p.pdf ETSI GS NFV-IFA 011]<br />
<br />
| [http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/004/02.03.01_60/gs_nfv-sol004v020301p.pdf Published specification]<br />
| Work In Progress<br />
| Work In Progress<br />
|}<br />
<br />
== Deployment templates ==<br />
<br />
*Reminder on the role of a VNFD & NSD<br />
*Link to SOL001<br />
*Link to bug tracker entry<br />
*Link to IFA011<br />
*One raw per version<br />
<br />
== Tutorials ==<br />
Links to tutorials and webinars<br />
<br />
*[https://www.brighttalk.com/webcast/12761/265769 VNF Packaging]<br />
<br />
== Link ==<br />
<br />
[https://nfvwiki.etsi.org/index.php?title=NFVSolutions Return to NFV Solutions page]<br />
<br />
[http://www.etsi.org/technologies-clusters/technologies/nfv Return to ETSI ISG NFV page]</div>Nakamurate