[White Paper ] Ch 01 [1.5 Cloud Native for Telcos

[ASawwaf]

Add some content in "1.5 Cloud Native for Telcos "
and move " 1.4 Cloud Native Network Functions" To be under "1.5 Cloud Native for Telcos " as 1.5.x

[ASawwaf]

Late 2012 European Telecommunication Standards Institute ( ETSI ) Industry Specification Group ( ISG ) for Network Functions Virtualization NFV is founded by world's leading telecoms network operators
CSP’s’ networks are populated with a large and increasing variety of proprietary hardware appliances. To launch a new network service its required more variety of hardware appliances , which requires more space and power to accommodate these boxes and its increase by introducing multivendor and more Services ; compounded by the increasing costs of energy, capital investment challenges and the rarity of skills necessary to design, integrate and operate increasingly complex hardware-based appliances. Moreover, hardware based appliances now have shorter life cycle to accommodate move innovated services making the return of investment lower and lower when deploying new services, and slower time to market to introduce a new services with high OPEX and CAPEX investment
The Target of ETSI ISG NFV to address these problems by leveraging standard IT virtualization technology by decoupling between software ( Network Function ) and hardware , so this software can run on a range of industry standard hardware –Commodity on the Self - server , switches and Storage
In this case the CSP’s can convert many Network function as Mobile and Fixed network ( EPC , IMS , BNG ,..) form PNF to VNF which able to carry Data and control plan
To complement and automation the deployment of NFV , Software Defined Networking (SDN ) come into the picture to be a key enabler technology for NFV to provides the means of dynamically control the network and the provisioning of networks as a service
ETSI NFV is not only piece of software and hardware , it is complete reference architecture with reference interfaces , information modeling and Solution / detailed specification that support the complete life cycle management of VNF’s Resources requirements form compute , Storage and Networking ( NFVI) by VIM , and automated and orchestrated way of VNF’s onboarding based on standard VNF packages and descriptors ( NFVO) , finally manage VNF’s life cycle management ( VNFM)

https://www.etsi.org/technologies/689-network-functions-virtualisation

ETSI NFV publish 3 Release till the date , By time of this white paper , ETSI started working on NFV Release 4 specification focus on but limited to :

1. NFVI evolution, focusing on enhancements to support lightweight virtualization technologies, optimizing NFV Infrastructure (NFVI) abstraction for reducing the coupling of VNFs to infrastructure, and optimizing networking integration into the infrastructure fabric to ease the connectivity for Virtualized Network Functions (VNFs) and Network Services (NSes)
2. Enhancing NFV automation and capabilities, covering aspects such as: improving life-cycle management and orchestration, the simplification of VNF and NS management aspects leveraging virtualization, and handling advances in autonomous networking
3. Evolving the NFV-MANO (Management and Orchestration) framework, focusing primarily on optimizing internal NFV-MANO capability exposure and usage
4. Accompanying operationalization aspects which include: the simplification of NFV to ease development and deployment of sustainable NFV based solutions, verification (and certification) procedures and mechanisms, and operationalization, integration and use of NFV with other management and network frameworks
   Which it is related to CNCF TUG white paper :
   • As example For 1st point , focus on “focusing on enhancements to support lightweight virtualization technologies, optimizing NFV Infrastructure (NFVI) abstraction for reducing the coupling of VNFs to infrastructure, and optimizing networking integration into the infrastructure fabric to ease the connectivity for Virtualized Network Functions (VNFs) and Network Services (NSes)” by other word it focuses on container infrastructure

During last period starting from NFV , there is a lot of challenges that CSP suffer which lead the slowly NFV adoption as but not limited to :

• First and most important factors is the VNF architecture itself in terms of :
  o Monolithic Architecture ( Elephant architecture )
  o Stat-full VNF , which all VNF state reside in VNF itself
  o Scalability & elasticity problems in terms of scaling up/down and in/out
• Telco-grade KPIs ( five 9s’) and resiliency
• High throughput and performance required of some VNF which required some special acceleration technologies which against of Cloud concept
• Long cycle for VNF to certified/onboarded on the targeted NFVi

This was the same pattern followed during server virtualisation, when initial efforts focused on replicating physical servers as virtual entities. Cloud native however, requires a more fundamental redesign and rethink of how telco and backbone/core network systems function. In that sense, as well, cloud native for telco is actually not dissimilar from forklifting over monolithic legacy applications into virtual environments and then decoupling the tightly bundled functions and processes to create a more resilient, manageable, and performant infrastructure that derives immutability precisely from its ephemerality. In reality, CNFs will be introduced alongside VNFs and PNFs (physical network functions) and will need to fit into operational models that govern those earlier types of network functions. Additionally, CNFs will require the capability to be orchestrated by management systems already present in the service providers' networks.

[ASawwaf]

@taylor @tomkivlin @CsatariGergely @jeffsaelens

Your comments here

[ASalkever]

@ASawwaf - This is a bit more detailed than what we intend for this Prologue, which is designed to be very readable even for non-technical people. In the interest of getting the Prologue out for KC EU, I think we should revisit this in the next white paper or in one that is more focused on this specific area. We can keep this issue open and comeback to it if you want.

[ASawwaf]

@ASalkever Thx , Iagreed with you but at least we need to build the storyline, to make the readers get the target of the paper , i am very conservative in using some terminologies if you check some titles IMHO it did not go with smooth flow as @CsatariGergely mentions in #45 , "Software Defined Networking And The Emergence of VNFs" there is nothing related to SDN ,

So it is important to build this storyline no need to go deep but the target and consistency of the paper should be solid

thx