A.1 NFV ISG PoC Proposal

Transcription

1 A.1 NFV ISG PoC Proposal A.1.1 PoC Team Members PoC Project Name: E2E Orchestration of Virtualized LTE Core-Network Functions & SDN-based Dynamic Service Chaining of VNFs using VNF-FG Network Operators/ Service Providers: SK Telecom Contact: Bryan Kim DK Lee Jong Han Park Manufacturer A: Hewlett Packard (HP) Contact: SeonJin Jeon Woochan Cho Jongsik Woo Wonho Chun Marie-Paule Odini Manufacturer B: Samsung Contact: SangKyu Lee JeongSoo Kim JeeHye Cha EunHa Chang Manufacturer C: Telcoware Contact: Jonghyoun Lee Sungsuk Cho Jongsik Jung Jongbeom Kim A.1.2 PoC Project Goals This PoC project is divided into a number of phases. In our 1 st phase, we have the following 5 goals. PoC Project Goal #1: The PoC will verify the correctness of the E2E lifecycle management and orchestration of virtualized LTE core network functions (e.g., vepc, vims, value-add services) which are managed by VNF Managers from multiple vendors, as described in GS NFV-002 v1.1.1 Section PoC Project Goal #2: The PoC will verify the correctness of the virtualized LTE core network function behaviors such as vmme, vs/p-gw, and vims that are implemented as VNFs on top of the

2 NFVI as described in GS NFV-002 v1.1.1 Section 7.2 (Figure 4: NFV reference architectural framework). PoC Project Goal #3: The PoC will examine the performance of the implemented VNFs. More specifically, the goal is to examine whether or not the performance of the VNFs is comparable to the physical function (i.e., PF) counterparts when optimized and fine-tuned. This is yet to be published by ETSI NFV PER export group (in ETSI GS NFV-PER documents). PoC Project Goal #4: The PoC will examine the feasibility and correctness of elastic features (e.g., scale in/out and scale up/down) and their performance. Some of these orchestrator based elasticity details are to be addressed by the ETSI NFV MAN working group (in ETSI GS NFV-MAN documents). PoC Project Goal #5: The PoC will examine the feasibility of the SDN-driven VNF-FG graph construction and its performance, as specified in GS NFV-002 v1.1.1 Section 6.2 (Figure 2: graph representation of an end-to-end network service). The latter phases of our PoC project is still being developed and will later be announced in the future when clearly defined. A.1.3 PoC Demonstration Venue for the demonstration of the PoC: The PoC network environment will be hosted and presented at SK Telecom R&D Lab (Bundang, Korea). There currently is a webinar as well as other venues being planned (e.g., NFV#8 Meeting, HP OpenNFV Lab, etc) to publically present our demo. A.1.4 (optional) Publication Currently, publication is not planned. A.1.5 PoC Project Timeline What is the PoC start date? May 23, 2014 (already underway) (First) Demonstration target date: October 1 st, 2014 (@ SK Telecom s R&D Lab) PoC Report target date: November 1 st, 2014 When is the PoC considered completed? Our PoC (1 st phase which is described in this proposal) will be considered completed when all of the five design goals described in A.1.2 PoC Project Goals are explored and finally when the ETSI NFV ISG PoC report is completed and published.

3 A.2 NFV PoC Technical Details A.2.1 PoC Overview In order to maintain a high quality of the PoC Projects and provide meaningful feedback to the various NFV ISG Work Items, it is desirable for the NFV ISG PoC Proposal to identify, in detail, the NFV aspects that are being demonstrated. PoC team members are encouraged to focus on NFV ISG documents such as the Architectural Framework [4], Use Cases [2], Requirements [3], as well as other NFV ISG documents. A The overall PoC architecture The following figure shows the overall architecture of our PoC, which is built primarily upon the NFV reference architecture framework [4]. The PoC includes VNFs from multiple vendors (with the vendor names and their respective VNFs highlighted in red fonts in Figure 1(b)), each potentially with its own VNF Manager and VI Manager. Please note that some functional blocks (e.g., EMS) are not shown in the figure for simplicity. Figure 1. Side-by-side view of (a) the NFV reference architecture framework by ETSI NFV ISG on the left and (b) SKT PoC test-bed architecture on the right The NFV Portal on the right side figure provides the overall graphical interface to the operators, exposing the functionalities of the orchestrator. Some of the functions that the portal exposes include the lifecycle management of a given network service such as vepc and monitoring of the instantiated network services. Upon receiving requests from the NFV Portal, Orchestrator interacts with VNF Managers (through standardized APIs across multiple vendors) to validate (e.g., syntax, resource management, etc.) and finally executes the requests. When needed, Orchestrator (or the VNF Manager depending on the policy) elastically scales up/down or in/out a given VNF. The VNFs described in Figure 1 above are likely to be interworking with some of the existing PNFs. details on the complete list of VNFs, the SDN controller (e.g., vendor, version, models, etc.), and whether or not the test-bed environment includes both VNFs and PNFs shall be described in the final PoC report. More

4 A.2.2 PoC Scenarios Describe the high level scenario(s) that will be demonstrated. Where applicable, provide a network diagram(s): Scenario 1 Lifecycle management of VNFs via VNFMs from multiple vendors. e.g., instantiation, updates, scale in/out, scale up/down, and termination of the virtualized LTE core network functions (vepc, vims) as VNFs managed by VNFMs from multiple vendors, through the use of standardized GUI interface provided by the NFV portal Figure 2. Scenario 1: VNF lifecycle management through a centralized orchestrator This scenario explores the feasibility of lifecycle management of virtualized LTE functions in the central data centers as well as the micro data centers remotely located at the (enterprise) customer premise. Scenario 2 Verifying the correctness of the E2E behavior of VNFs. e.g., originating/receiving calls from the originating UEs with vepc/vims/vvas to terminating UEs attached to vepc/physical EPC, elasticity (scale in/out, up/down) and performance (e.g., transactions per second, supported throughput, etc.) of the instantiated LTE core network functions. This scenario explores the feasibility of utilizing/implementing dynamically virtualized LTE core functions to provide LTE as a service, where a given customer may choose (potentially via a GUI web interface) a set of services (network functions, monitoring, etc.) for the LTE, and by a click of a button, an enterprise (or private) LTE service is deployed for the requesting user. Scenario 3 Dynamic service chaining via SDN-driven VNF-FG using the call flow criteria (such as user, time, location, destination application, etc.)

5 Figure 3. Dynamic service chaining via SDN-driven VNF-FG Figure 3 above depicts the dynamic service chaining at a high level. Figure 3 shows vepc in the front, along with vvas functions (QoE management, TCP acceleration, Video Optimization, etc.) that are located in the SGi LAN (after P-GW and before the Internet) in LTE core network. Today, these functions are connected sequentially and statically, and every packet that goes out to the Internet (or comes in from the Internet) must traverse each of these nodes sequentially regardless of whether or not the packet uses the given vvas function in the sequence. This static packet forwarding potentially wastes both the processing (at each node) as well as bandwidth between the functions. With SDN (and the VNF-FG), the packets may be optimally forwarded to the VAS functions dynamically as needed. For example in Figure 3, John s packets visit EPC, TCP acceleration, and video optimization functions whereas Jack s packet s traverse EPC, QoE management, and video optimization. This scenario explores the feasibility of dynamically changing the network path of a given flow to selectively apply a dynamic and differentiated value-add service in the SGi LAN at the granularity of a flow. In the future when we have all the LTE core network functions in a virtualized form and have ability to serve them as a service (i.e., LTE as a service environment), we will also be able to direct packets to different private LTE network, given a set of criteria. A.2.3 Mapping to NFV ISG Work Describe how this PoC relates to the NFV ISG work: 1) Specify below the most relevant NFV ISG end-to-end concept from the NFV Use Cases [2], Requirements [3], and Architectural Framework functional blocks or reference points [4] addressed by the different PoC scenarios: Use Case Requirement E2E Arch Comments Scenario 1 UC#5 [Gen.1], [OaM.1], [OaM.2], [OaM.5], [OaM.6], [OaM.8], [OaM.9], [OaM.10], [OaM.11], [OaM.14], [Maint.1], [Maint.2], Incremental virtualization of LTE core functions and end-to-end orchestration

6 [Maint.5], [Maint.10], [Maint.11], [Maint.12] Scenario 2 UC#5 [Gen.1], [Perf.1], [Perf.2], [Perf.3], [Perf.4], [Elas.1], [Elas.2], [Elas.3], [Elas.4], [Mig.3] VNF behavior correctness, elasticity, and performance Scenario 3 UC#4 [Gen.4], [Mig.1], Dynamic service chaining based on a number of user flow criteria using SDN & VNF-FGs 2) (Optional) If this PoC intends to solve or validate any challenge or ongoing work in NFV ISG working groups, complete the table below: Scenario 1 Scenario 2 Scenario 3 INF SWA MAN REL PER Comments VNF Lifecycle & state, VNF composition, Faster VNF/VNFC, SWA-5 VNF Lifecycle & state, VNF composition VNF and SDN architecture, SWA-5, SWA- 1 A.2.4 PoC Success Criteria The 5 goals of our PoC project phase #1 can be further organized into the following 2 tasks: (1) Verifying the correct behavior of NFV/SDN orchestration, individual VNFs, and VNF-FG (2) VNF performance measurements and comparison against the PNFs For the former (i.e., correctness verification), we plan to use a set of conventional and well-defined test cases that we currently use on the non-nfv/nfvi infrastructure. If VNFs and the overall virtualized infrastructure supporting them are run through these tests, we declare that our goals on verifying the correctness of the VNFs and NFV/SDN orchestration are met. For the latter (i.e., performance measurement and comparison), we plan to also reuse the existing methodology which we use for PNFs in measuring the performance and use the outcome for the comparison. When we have the measurement outcome which we can compare against the PNFs and have the comparison results, we declare that the goals on performance verification and comparison are met.

7 A.2.5 Expected PoC Contribution One of the intended goals of the NFV PoC activity is to support the various groups within the NFV ISG. The PoC Team is therefore expected to submit contributions relevant to the NFV ISG work as a result of their PoC Project. List of contributions towards specific NFV ISG Groups expected to result from the PoC Project: PoC Project Contribution #1: VNF composition across multiple SWA interfaces, VNF and SDN interworking architecture NFV Group: NFV SWA working group PoC Project Contribution #2: Feasibility and correctness verification of multi-vendor VNF lifecycle management from a central orchestrator NFV Group: NFV MAN working group PoC Project Contribution #3: Examination of VNFs performance against PNFs in LTE core network NFV Group: NFV PER expert group

8 Annex B (normative): NFV ISG PoC Report Template The following normative disclaimer shall be included on the front page of a PoC report: Submission of this NFV ISG PoC Report as a contribution to the NFV ISG does not imply any endorsement by the NFV ISG of the contents of this report, or of any aspect of the PoC activity to which it refers. B.1 NFV ISG PoC Report B.1.1 PoC Project Completion Status Indicate the PoC Project Status. Can the PoC be considered completed? If this is a multi-stage PoC project, indicate the Reported Stage status and plans for future Project Stages. Overall PoC Project Completion Status: Completed PoC Stage Completion Status (Optional - for Multi Stage projects only): B.1.2 NFV PoC Project Participants Specify PoC Team; indicate any changes from the NFV ISG PoC Proposal: PoC Project Name: E2E Orchestration of Virtualized LTE Core-Network Functions & SDN-based Dynamic Service Chaining of VNFs using VNF-FG Network Operators/ Service Providers: SK Telecom Contact: Bryan Kim (bryan.kim@sk.com) DK Lee (dongkee.lee@sk.com) Jong Han Park (jonghan.park@sk.com) Manufacturer A: Hewlett Packard (HP) Contact: SeonJin Jeon (Seon-jin.jeon@hp.com) Woochan Cho (Woo-chan.cho@hp.com) Jongsik Woo (Jong-sik.woo@hp.com) Wonho Chun (Won-ho.chun@hp.com) Marie-Paule Odini (marie-paule.odini@hp.com) Manufacturer B: Samsung Contact: SangKyu Lee (ss7.lee@samsung.com) JeongSoo Kim (James007.kim@samsung.com) JeeHye Cha (jeehye.cha@samsung.com) EunHa Chang (ehchang@samsung.com)

9 Manufacturer C: Telcoware Contact: Jonghyoun Lee Sungsuk Cho Jongsik Jung Jongbeom Kim B.1.3 Confirmation of PoC Event Occurrence To be considered complete, the PoC should have been physically demonstrated with evidence provided that the demonstration has taken place. Provide details on venue and content of PoC demonstration event. Provide pictures and supporting literature where available. Please identify who was present at the demonstration event (optional). PoC Demonstration Event Details: ETSI NFV PoC Zone, SDN & OpenFlow World Congress, October 2014, Germany. The demonstration was performed at the HP booth, located inside the showroom. Included below are the pictures taken at the HP booth as the representatives from SK Telecom (Dr. DK Lee and Dr. JongHan Park) were explaining to the audiences about the PoC.

10 Figure 4. Various photos taken at the PoC #23 booth Additionally, Dr. DK Lee had an interview with Telecom TV, explaining the high level concept and implementation of the PoC. A link to the interview is included below. SK Telecom produces the most complex PoC by TelecomTV Figure 5. The Interview with Telecom TV The PoC will also be presented by Dr. DK Lee during Carrier Network Virtualization (CNV) 2014 at Palo Alto, USA on December 9 th, 2014 as shown below.

11 Figure 6. Addition Presentation of the CNV 2014 B.1.4 PoC Goals Status Report Specify PoC Goals from NFV ISG PoC Proposal (clause A.1.2). Identify any changes from the original NFV ISG PoC Proposal with an explanation as to why the changes were made. Indicate the extent that each goal was met. Provide sufficient information for those not familiar with the PoC goals to understand what has been achieved and/or learned. The main goals of our PoC were to verify the feasibility and correctness of the E2E lifecycle management of VNFs at the level of network service, through the use of NFV MANO. The 5 goals which we stated in the original NFV ISG PoC Proposal are the followings: PoC Project Goal #1: The PoC will verify the correctness of the E2E lifecycle management and orchestration of virtualized LTE core network functions (e.g., vepc, vims, value-add services) which are managed by VNF Managers from multiple vendors, as described in GS NFV-002 v1.1.1 Section PoC Project Goal #2: The PoC will verify the correctness of the virtualized LTE core network function behaviors such as vmme, vs/p-gw, and vims that are implemented as VNFs on top of the NFVI as described in GS NFV-002 v1.1.1 Section 7.2 (Figure 4: NFV reference architectural framework). PoC Project Goal #3: The PoC will examine the performance of the implemented VNFs. More specifically, the goal is to examine whether or not the performance of the VNFs is comparable to the physical function (i.e., PF) counterparts when optimized and fine-tuned. This is yet to be published by ETSI NFV PER export group (in ETSI GS NFV-PER documents). PoC Project Goal #4: The PoC will examine the feasibility and correctness of elastic features (e.g., scale in/out and scale up/down) and their performance. Some of these orchestrator based elasticity details are to be addressed by the ETSI NFV MAN working group (in ETSI GS NFV-MAN documents). PoC Project Goal #5: The PoC will examine the feasibility of the SDN-driven VNF-FG graph construction and its performance, as specified in GS NFV-002 v1.1.1 Section 6.2 (Figure 2: graph representation of an end-to-end network service). As we proceeded with the PoC design and implementation, the project participants (SK Telecom, HP, Samsung, and Telcoware) had an in-depth discussion internally and concluded that Goal#3. Although Goal#3 was studied internally, the results may contain sensitive information and therefore shall not be publicized. Rather, it was concluded internally that Goal#3 should be studied separately (and more in-depth) in another project. The same conclusion applies to Goal#5, where the performance was mentioned.

12 Goal Status (Demonstrated/Met?): - Goal#1: Met and Demonstrated - Goal#2: Met and Demonstrated - Goal#3: Met - Goal#4: Met and Demonstrated - Goal#5: Met and Demonstrated The following figure shows a snapshot of T-OVEN, (T represents SK Telecom, and OVEN stands for the Orchestration for the Virtualized End-to-end Network services ), which is one of the main outcomes of this project. Through T-OVEN, we verified internally and showed publically the feasibility and correctness of the end-to-end network service lifecycle management through NFV MANO. Figure 7. T-OVEN (SK Telecom s Orchestrator for the Virtualized End-to-end Network services) Specific details regarding each of these individual tests (descriptions, procedure, etc.) are found in the PoC Scenario Report section of this document. B.1.5 PoC Feedback Received from Third Parties (Optional) Where applicable, provide in a free text, feedback received from potential customers, Ecosystem partners, event audience and/or general public. Major global mobile network operators, equipment vendors, and NFV NOC members visited the booth during our SDN and OpenFlow World Congress The followings are example feedbacks which we received during the demo: - The PoC intuitively shows how beneficial and interesting NFV and orchestration may be in the Telco business and O&M domain - This PoC is one of the most complex NFV PoCs as of now, and it is amazing to see that the orchestrator actually works very well and seamlessly in a real operational environment with multivendor VMFs, VNFMs, and VIMs The demonstration and presentation of our tool and its capabilities (e.g., the LTE-as-a-service use case) were very well received and there were considerate amount of traffic visiting the booth. All the visitors agreed that the demonstration showed very well the full benefits and potential of network functions virtualization and the end-to-end network service orchestration.

13 B.2 NFV PoC Technical Report (Optional) PoC Teams are encouraged to provide technical details on the results of their PoC using the PoC Scenario Report template below. B.2.1 PoC Scenario Report Use the table structure below and refer back to the Scenarios in the NFV ISG PoC Proposal (clause A.2.2) and provide information for each of them. Feel free to include additional Scenarios developed during the implementation of the PoC. Do not eliminate Scenarios that were not performed, instead provide a brief status for each with a reason why the scenario was not performed. Do not hesitate to fill multiple instances of the table if several objectives have been demonstrated for each scenario. Objective Id: Description: Pre-conditions UC1, 2 & 4: End-to-End Orchestration of Virtualized LTE Core Network Functions Demonstrate the feasibility of orchestrating virtualized LTE core network functions considering a real world (& practical) setting. In other words, the virtualized LTE functions consist of multi-vendor VNFs/VNFMs/VIMs. Furthermore, consider incremental evolution where the LTE network consists of both VNFs and PNFs. 1. Multi-vendor VNFs and PNFs: VNF1: Samsung vmme VNF2 & 3: Samsung vs/p-gw VNF4: Samsung vcscf (labelled as MSS in the following figure) VNF5: Telcoware vcscf (labelled as MSS in the following figure) PNF1: SK Telecom s VAS IT servers PNF2: SK Telecom s SDG (a specialized network device for service chaining) PNF3: VOMs (Video Optimization Functions) PNF4: wtcp (TCP accelerator) The following figure illustrates the prepared test-bed configuration. 2. Every VNF is life-cycle managed by its own VNFM. In the case where a VNF does not have its own VNFM, the VNF must be able to lifecycle managed by the default VNFM (HP VNFM in this figure). Each VNFMs support the Or-Vnfm interface specified in ETSI NFV specification. 3. The virtualized infrastructure (NFVI/VIMs) is heterogeneous. In other words, the infrastructure consists of different flavours of OpenStack and VMWare. Procedure: 1 On-boarding of VIMs/VNFs/VNFMs 2 End-to-end LTE Network Service Lifecycle Management

14 Results Details: 1. The following VNFs/VNFMs/VIMs are successfully on-boarded to the orchestrator. The orchestrator successfully connects to the following 3 VIMs: Samsung s OpenStack environment (i.e., VIM1) Telcoware s OpenStack environment (i.e., VIM2) HP s OpenStack environment (i.e., VIM3) The 3 VIMs connect with the orchestrator based on Or-Vi interface to provide the necessary functionalities for virtualized resource management. The following figure shows the orchestrator portal, where the portal shows the list of VIMs on-boarded & being managed by the orchestrator. Although not shown in the below figure, VMWare which is used internally by SK Telecom for VAS deployment is also on-boarded. The following VNFs/VNFMs are successfully on-boarded as shown below. 2. End-to-end orchestration of virtualized LTE core network functions was successfully demonstrated. Once the VNFs were on-boarded, LTE network service can be designed (i.e., what functions and how the functions are connected) WYSIWYG What You See Is What You Get interface provided by the orchestrator portal. The following figure is the snapshot of the WYSIWYG canvas.

15 On the left side, the list of on-boarded (and usable) VNFs is displayed. Users can simply drag-and-drop the necessary functions from the list to the canvas and draw lines between the functions to design and on-board a network service such as LTE network service. Once the network service is on-boarded, users can also use the portal interface to instantiate the on-boarded network services. In our case, the overall LTE network service instantiation took about 40 minutes in the test-bed that we built in SK Telecom s Testbed (@ Bundang, Kyungki-do, Korea). The following screenshot provides the holistic view of the instantiated LTE network service (e.g., logical topology, performance, logs, etc.). Besides on-boarding and instantiation, other network service lifecycle management events are also tested and performed successfully. The following figure shows the orchestrator s portal visually indicating that the network service is being scaled up/down. More specifically, vcscf and vcdn are being scaled out based on the policy (e.g., scale-out the network service when the CPU utilization goes over 70% and stays there for more than 2 minutes), which was configured at the time of network service design.

16 Lessons Learnt & Recommendation s Although all the necessary components and interfaces are well defined (e.g., MANO, VNFM, VIM, etc. and their interfaces) are quite clearly defined in the ETSI NFV specifications, it was very challenging initially to on-board VIMs and VNFMs, due to the following (and not exhaustive) reasons: - Each vendor s philosophy and interpretation on the ETSI NFV reference architecture (e.g., the functional components and their roles) was very different when we first started the project (early 2014). The views are converging rapidly, but the divergent views may still be the case as of now (Nov. 2014). - Each vendor s interpretation of the interfaces between the functional components was different. For one example, everyone had different interpretation of VNF/NS healing, updates, and upgrades. - The fact that the environment continues changing was a big obstacle in keeping up with them. As both the ETSI NFV and OpenStack specification changes over time, it was very challenging to make different components work together. We believe that the converged views on the NFV reference architecture and the roles of the functional components (by ETSI NFV Phase 2) will hopefully facilitate the NFV evolution. As we delve more into the details of implementation of the orchestrator, there was a need for a self-testing agent at VNF and NS level may significantly reduce the time we spent on debugging. One recommendation which we would like to make is: - Each VNF shall have a self-testing agent w/ explicitly defined specification, which may be invoked by VNFMs or the orchestrator directly to automate the testing of the given VNF.

17 Objective Id: UC5. SDN-based service chaining of VNFs using VNF-FG Description: Demonstrated the feasibility of: - Associating VNF-FGs to a given network service - Managing (i.e., create, update, delete, etc.) the VNF-FGs - Providing the VNF-FGs to the SDN controller for service chaining Pre-conditions Same as UC#1 Procedure: 1 Use the orchestrator portal to create and associate the created VNF-FG (and VNF- FPs) to the network service. The created VNF-FG is pulled by SDN controller and used for service chaining Results Details: The VNF-FGs are successfully created and associated with the LTE network service. SDN controller was able to pull the VNF-FG from the orchestrator through an internally defined interface and use it for its service chaining The following figure shows a screenshot of the orchestrator portal where the user defines VNF-FG and VNF-FPs as he/she designs the network service. The created VNF-FG and VNF-FPs is successfully pulled by the SDN controller. The main purpose of this feature was for the interoperability of our orchestrator with the SDN controller, and therefore, the details of actual service chaining is left out-of-scope in this project. SK Telecom s service chaining has already been demonstrated at Mobile World Congress (MWC), Lessons Learnt & Recommendation s For SK Telecom s purposes, providing VNF-FG and VNF-FPs information to the SDN controller was sufficient for SDN interoperability with NFV at this time. B.2.2 PoC Contribution to NFV ISG Use the table below to list any contributions to the NFV ISG resulting from this PoC Project. The followings were the anticipated contributions (however which are de-scoped as we proceeded) to NFV in the initial stage of the PoC: PoC Project Contribution #1: VNF composition across multiple SWA interfaces, VNF and SDN interworking architecture NFV Group: NFV SWA working group PoC Project Contribution #2: Feasibility and correctness verification of multi-vendor VNF lifecycle management from a central orchestrator NFV Group: NFV MAN working group

18 PoC Project Contribution #3: Examination of VNFs performance against PNFs in LTE core network NFV Group: NFV PER expert group The above anticipated contributions were not made, mainly due to the time and efforts needed to actually implement the scenarios that we initially described within the time given. The implementation part took a lot more time and efforts than what we initially expected, and the team decided to focus mainly on setting up the test-bed and the actual implementation of the scenarios (which were indeed our most important target to meet), leaving the above contributions out of scope. Although there are no explicit work items resulting from this PoC project, we believe that we made many meaningful insights and implicit contributions on verifying the specifications published by ETSI NFV so far. B.2.3 Gaps identified in NFV standardization Use the table below to indicate Gaps in standardization identified by this PoC Team including which forum(s) would be most relevant to work on closing the gap(s).where applicable, outline any action(s) the NFV ISG should take. Gap Identified Forum (NFV ISG, Other) Affected WG/EG WI/Document Ref Gap details and Status There were minor customizations on the interfaces and flows, specifically added for this project. However, we did not find any major gaps in ETSI NFV standardization. B.2.4 PoC Suggested Action Items Provide suggested Action Items and/or further work required from the NFV ISG and/or external forums. As we mentioned in one of the previous sub-sections, we felt that having a standardized VNF self-testing agent would help diagnose and correctness verification of the VNFs. Since VNF manufacturer knows best about their VNF, they probably should include a test agent within the VNF that performs high level correctness of the VNF itself. B.2.5 Any Additional messages the PoC Team wishes to convey to the NFV ISG as a whole? Provide any feedback in a free text format to the NFV ISG. Please indicate whether the team wishes any specific message to be published or publically quoted. None. B.2.6 Any Additional messages the PoC Team wishes to convey to Network Operators and Service Providers? None. Are there any specific requests/messages that the team would like to convey to Network Operators and Service Providers?

19 History V1.0 July 2014 Accepted as PoC #23 Document history V2.0 November 2014 Addition of PoC Report to the Original Proposal