Heavy Reading 2014 December

http://contextream.com/media/docs/HR-ConteXtream-Fit-VNF-WP-12-8.pdf

The important Factors Driving NFV deployment is Service Agility & Flexibility

In a virtual environment, where applications are extracted from hardware, VNF de- signers face different challenges and opportunities. If operators are to achieve a step change in service agility, it should be possible to provision VNFs on a quasi-on- demand basis. Fit VNFs can be dedicated to a single function and then connected together using traffic steering (or “chaining”) mechanisms to create services.

VNFs themselves should be designed for the cloud.
The base meaning is to take existing applications and transform (virtualize) them. This is not the wrong thing to do; indeed, it has potential benefits. However, experience from enterprise and Web services has shown that porting legacy functions to the cloud results in less than optimal architectures that are subject to disruption from “cloud native” services.

VNF는 기존 Physical HW에서 동작하던 SW를 VM에서 동작시키는 것이므로, 기존 SW를 단순(?)히 VM에서 동작하도록 할 수도 있다. 그러나 이미 가상화를 먼저 겪은 enterprise나 web service에서 보듯 기존 기능을 포팅하는 것은 “cloud native” 하지 않아 최적화는 한계가 있다(구체적으로 어떤… 한계)

• On-demand provisioning & shorter lifecycle
• 1+N with rapid instantiation of new VNFs in event of failure rather than 1+1 with state replication
• Distributed across infrastruture
• Automated scale out
• Agile

Our research is very clear that operators do not view “quick and dirty” ports of appliance software to a VM environment as satisfactory. They are concerned about the performance of “Frankenstein” applications running in the cloud and about their ability to manage such functions in an automated way.

Operator는 가능한 빨라 가상화 환경에서 앱을 동작시키는 것에 만족하는 것이 아니라 Cloud에서 자동화된 방식으로 앱을 제어하길 원한다.

‘Fit VNF’

The idea is to pare back the VNF to its core function and remove extraneous capabilities no longer needed in the cloud

• Removing redundant software modules. - 샤시 관리는 VNF에서 Cloud management layer로 이동
• Simplifying the VNF networking stack - Legacy app을 포팅한 경우 복잡한 networking stack을 가지고 있을 수 있다. 그런 복잡한 건 network fabric에게 맡기고 VNF는 좀 더 가볍게 본연의 NF 처리에 집중
• Deconstruct multi-function nodes - NE는 기능에 따라 여러 개의 NF로 나눠 SFC로 묶을 수 있게 모듈화 한다.
• Modular Scaling - NF 단위로 scaling in/out

Combination of Smarter NFVI and Slimmer VNF

Extract connectivity and management functions from the VNF and migrate them to the cloud platform
In this way, operator can create a generic NFV cloud that can support services composed of the appropriate “Fit VNFs” In this way, the “Fit VNF” and “Smart Platform” become important enablers of service agility.
Redundant functions are extracted from the application and migrated to the NFV Infrastructure (NFVI) layer, with the result that the VNF becomes “fitter” and the platform becomes “smarter”

Ultimately, VNFs could become library, or “catalog,” items that can be deployed on the NFV cloud platform, via instruction from the NFV service orchestrator, on an on- demand basis.

What is migrated from VNF to NFVI

• Dynamic Virtual Connectivity
• Scalability to run on multiple cores/servers
• Load balancing and health checks
• Internal SFC to connect sub-function instances
• Elasticity to change scale to needs
• Distribution to multiple data centers while maintaining state
• Analytics collection
• Service awareness
• Subscriber awareness
• High availability and redundancy

Open Platform NFV

• Vendor-specific platform -> OPNFV for independency of VNFs
  • Carrier Grade Open Source NFVI reference platform
  • Improve consistency and interoperability between NFV components
  • NFVI, VIM and API to other NFV elements such as management and orchestration(MANO)

Interoperable NFVI

• VNFI should be open platform to support VNFs from different vendors
• The more platform capability is available, VNFs can be simplified accordingly
• Where the NFVI is more capable (“intelligent”), and VNFs simpler, operators can more quickly deploy functions and provision services.
• By over-specifying the platform upfront, operators will lose the agility they desire and place undeliverable requirements on suppliers
  그렇다고 NFVI에 처음부터 과도한 smartness를 요구하면 operator가 원하는 agility를 얻지 못할 수 있다. 그러므로 점진적으로 NFVI의 기능을 추가해야 한다.

This will likely result in a situation where less demanding functions will be the first to surrender their autonomy to the platform.

Mobile Core에서 간단한 기능들(Load balancer, video optimizer, HTTP proxies)는 Gi-LAN에서 지원하는 기능을 사용하는 것이 이 기능들을 포함하도록 EPC를 고치는 것보다 낫다.(?)

Programmable Networking requirements

• Programmable, dynamic connectivity between VNFs is, therefore, valuable. If an NFV service orchestrator can push rules to a platform that can quickly provision the VNFs need to support a service, and the associated service function paths, operators will move a big step closer to the agility they desire from NFV. This capability is a large component of what makes an NFV platform “smart” and is why SDN and network virtualization are important.
• DC의 경우보다 telecom의 경우 다른 점은 distributed VNFs and need to manage “subscriber aware” traffic flows at scale.
• In telecom networks, where there is likely to be distributed VNFs (placed according to performance requirements), the argument for a specialist SDN solution for NFV is stronger because the need to man- age application and subscriber state across locations.

In summary

• Legacy app을 cloud 상황을 고려하지 않고 단순히 가상화 환경으로 porting하는 것은 Operator가 원하는 on-demand provisioning에 맞지 않고 성능 측면에서 최적화된 형태가 아니다
• NFV 환경은 open platform이어야 operator가 원하는 agility를 얻을 수 있다. 다양한 업체의 VNF와 VNFI를 활용
• VNF는 PNF와 달리 networking stack이나 HW 관리 등의 기능을 제거해서 NF 에 집중해야 한다. 이런 기능들을 cloud management platform 으로 옮겨 VNF를 가볍게 해야 한다. “Fit VNF”
• On-demand Provisioning가 SDN을 결합해야 operator가 원하는 service agility를 얻을 수 있다.