Cyber Security for 5G and Cloud World

Cisco Latest report quantifies in 2019 1272 breaches that exposed 163M customer records . In a 5G and Cloud connected world to adress security concerns 5G Security SA5 and community defined some key principles that we must adhere to build dis-aggregated Networks .

1. Use of SUCI (Subscription concealed Identifier) to ensure even during first Latch the subscriber ID is not sent as plain test

2. 5G Auth and Key Agreement uses private/public key something very familiar to Cloud hyperscalers to grant resource access

3. Before device join network the Core will validate device then the device authentication start (This architecture make use of AMF ,UDM and AUSF and SEAF)

4. Use of Network Slicing in NPN and Public NW to ensure only users can reach his service slice only

5. To solve issues that limit operators use of encryption on Iu interface is addressed in 5G with the use of Data validation to ensure even protected streams can have integrity check

6. The New SecGW (Security end point GW) to tunnel the Radio GnB traffic directly at access/metro

7. API and Digest level protection for MEC and Developer system combined with security DDoS ,Malware protection

8. IdM and HSM for Infra security

For details refer to latest info graphics from Samsung

samsung-5g-security-brief_finalDownload

#Cyber #Security #Cloud #Infrastructure

Advertisement

Using Cloud and AI to Differentiate your 5G Investment

Source: Disney

In a recent Webinar about how to build a successful 5G networks a question that took my mind was .

“How successful we can be if we address a fundamentally new Problem using a new Technology if we still use old principles to build our Telecom Networks and with out disrupting the supply chains”

I think the answer for these type of questions in the context of 5G fundamentally will depends on following two key initiatives.

1. How to use Radio spectrum to gain strategic advantage over competitors
2. How to use Cloud to gain advantage for 5G

The Radio Spectrum is a complex topic primarily driven by many factors like regulatory and existing use of Spectrum making real 5G a slight different than what is really possible with Spectrum of today . This alone is not enough as Smart cells vs Wifi6 will be again something that will really depend on Spectrum use of 5G .These details i will leave it for now for future discussion and want to focus on Cloud and how really it will make your 5G successful.

During our recent work with in ETSI NFV Release4 Sol WG , GSMA and LFN CNTT we have discussed and agreed on a number of ways really Cloud can support you to differentiate your 5G network . Knowing this can be a real game changer for Opcos who are investing in 5G and Future Networks

Homogenity

A homogeneous Infrastructure Platform on 5G that can be used by all applications like traditional 5G CNF’s , MEC , Developer applications and any legacy IT /OTT applications that are required to be offered to users . One such example is OpenShift or VMware Edge and Last mile solutions using technologies like CNV or VCF7.0/NSXT3.0 that will build the edge clouds in an automated manners and enable day 2 through standard tools whether use VM or containers or BM’s as a baseline architecture

A uniform IPI that can be deployed using standard Red Fish solutions such as the one from HPE really will make is possible to build 5G using the Clone technology as used in most automotive industry today and that really enabled them to produce with minimum toil

Scalability

Scalability in the last mile is the most important criteria for 5G Success . For example a compute solution that can scale and can provide power to process really all sort of workloads at the Edge is certainly a make or break for 5G . When it comes to Data one such example is storage and Disk , with solutions like RedHat Ceph3.0 that supports compression from Q3 2020 using its blue store offering and can integrate CephFS with NFS support makes the real convergence possible .

Convergence vs Automation

IT SRE and DevOps has gained lot of traction recently and this is not without a reason . It has certainly reduced the CFO bills and that is why the Telco’s want to achieve the same . However the requirements of workloads are really unique and that makes us to understand that real automation with out standard modeling is never possible .

On the Cloud side we can make use of TOSCA models together with solutions like automation hub together with secure catalog and registry means we can do both modeling for varying workload requirements and to automate it in the same fashion . Further we can do some advanced testing like the one we have been doing in PyATS

Registries and Repositories

The concept of 5G factory that we have been rigorously trying to achieve in Middle East Telco projects are really made possible using secure registries like Quay for containers , Dockerhub and its integration with Jenkins and CI/CD tools for Telco.

It is no surprise if i tell you these are most important differentiators as we introduce public clouds for 5G

Operators

The programmability of Immutable infrastructure is the biblical principle for 5G Networks . Both Service Mesh , NSM and Server less are deployed as operators which a practically CNI programs that makes your infra follow software YAML instead of tight and coupled instructions .Further to that the Operator supports full automation of both day0 and day2 Infrastructure tasks .

For K8S it is currently supported while for VM’s it will be available fully in Dec 2020

Openshift service mesh for 5G CP CNF’s is possible today with

• Istio
• Grafana
• Prometheus
• Kiali
• Jaeger

Further to that today we faced a number of issues in Docker to Telco and use of CRI-O and PodMan will certainly support to advance the 5G .

“Podman is more light weight compared to CRI-O so you should expect it better performing on 5G Edge compared to PoDman .

5G Integration

Redhat Fuse online is one of solutions which abstracts Infrastructure and make it possible to integrate developer , integrator and tester using one tool . Except of container it also standardized your VM’s . E.g VM in Openshift running FTP service and that make it possible to run on native containers itself .Fuse Online provides a data mapper to help you do this. In a flow, at each point where you need to map data fields, add a data mapper step. Details for mapping etc

Red Hat^® Fuse is a distributed integration platform with standalone, cloud, and iPaaS deployment options. Using Fuse, integration experts, application developers, and business users can independently develop connected solutions in the environment of their choice. This unified platform lets users collaborate, access self-service capabilities, and enforce governance.

An SDK is definitely helpful for 5G platform specially when it comes to open your networks for the developer who need .NET or JAVA . Quarkus from RedHat is a Kubernetes-Native full-stack Java framework aimed to optimize work with Java virtual machines.

Quarkus provides tools for Quarkus applications developers, helping them reduce the size of Java application and container image footprint, eliminate programming baggage, and reduce the amount of memory required.

Advanced Cluster Management

With huge number of 5G sites and future scnerio of site sharing between operators . It will be a real need to deploy Apps and manage them in a hybrid Cloud scnerio and nothing explains it better than burr sutter demo at the RedHat summit . A cool video from RedHat team is available there if you want to learn it more

In a summary you can mange

• 5K+ poD’s
• Create clusters in hybrid cloud like AWS,GCP,Azure, Bare metal and On prem
• Policy management
• Secure deployment by validating YAML and images using Quay/clair sorted by Labels
• Possibility for developer to create and deploy policy using GUI

Above all RHACM makes is possible to measure SLA of Clusters and Optimize workloads e.g shift to other clusters in an automated manner .Certainly a Cool thing for 5G to serve heavy lift and Content driven applications

Heavy Lifting of Workloads

The proponents of silo vendor solutions often tell us that 5G Base band processing and e-CPRI heavy lifting with parallel processing will make X-86 a non practical choice to adopt classical cloud way .

However the latest Intel atomic series with FPGA’s and NVIDIA GPU’s means we can not only solve the Radio issues such as the ones we are trying to solve in Open-RAN but will enable to introduce latest technologies like AI and ML in 5G era networks . Those who are more interested in this domain can refer to latest work in ITU here

T-FG-ML5G-2019-PDF-EDownload

For ML/AI use cases in 5G there are many made possible in both Telco and vertical industry like Automobiles, warehouse monitoring etc today using GPU operator , Topology manager like shows visibility in to GPU ,NIC,BW,Performance etc.

Open Policy Pipeline can optimize the ML model itself using analytics functions of the Cloud

When it comes to Cloud value to data scientist in 5G using platforms like OCP or HPE Blue Data as follows

• Anaconda tool sets for programming
• Jupyter notebooks
• CUDA and other similar libraries
• Report on both Log and Policy compliance
• Tekton Pipeline in OCP for CI/CD of ML/AI use cases
• Models are made in Jupyter by scientists while it is triggered in the Tektron pipeline

Finally using OCP Open Model Manager we can Register, deploy and monitor open source models in one central environment, uniting data scientists and IT/DevOps.

Summary

The most important takeaway is that if we have to take full advantage from 5G we not only need to follow 3GPP and traditional Telecom SQI’s but also those advantages offered by Cloud . This is only way to not only manage a TCO attractive 5G but also will enable to introduce both Niche players and new services that will be required to build and drive a Post COVID-19 world economy .

The Top 7 Tools for Developers to Move Applications to the Cloud

Source: CNCF

Are you a Software Architect or a Developer who want to model everything a code.

Or may be you are a developer who want to know how best to move my code to the Cloud in a secure and automated manner. Here are the Top 7 Tools and why you should use it

https://www.krminc.com/custom-it-solutions/

1. Kubevirt (To run VM’s in Containers using CNV plug-in)

2. PodMan ( A daemonless tool to run containers using OCI

3. Cri-o (Container run time that makes it possible to integrate multi vendor solutions using OCI compatible interfaces)

PodMan and CRI-O are container engines. They are front-ends to manage local containers. PodMan is designed with system administrators and developers in mind, while CRI-O is designed to satisfy the requirements of Kubernetes alone

4. Buildah ( A tool to build OCI images quickly . Easy to incorporate into scripts and build pipelines, and best of all, it doesn’t require a running container daemon to build its image.

5. Quay (A container registry and Repo holder to stores, builds, and deploys container images

.It analyzes your images for security vulnerabilities, identifying potential issues that can help you mitigate security risks

6. Skopeo( A tool to implement CI for container Images . It can inspecting and transport images,It can also copy container images from one location to another. If you want to copy an image from your laptop’s local docker storage to the local CRI-O container store .it can be done also.

7. Ansible A tool to automate Infra using simple YAML playbooks. it can manage both Linux and Windows above it its support of Python and large Networking libraries makes it a cool choice for both Infra and Software .

Finally never forget you need a CI pipeline for all your Apps also so use of Jenkins and Terraform is important .we need to see tools not merely as Infrastructure automation but also as Infrastructure orchestration

Running Containerized Applications in a Cloud Environment

The use of containers and kubernetes in the industry has made a decent progress since the first time it first made its way back in 2013-2014 . However there is still lot of enigma around its use in a production environment . Recently there is a OpenDev workshop organized by Openstack https://www.openstack.org/events/opendev-2020/ where many domain experts from the industry including Telcos,vendors,system integrators and Enterprise spent a handful of time to clarify many of mis-conceptions and share experiences about how to use in a large scale Enterprise of Telco Environment .

The Purpose of this paper is to share some key insights around this .

How to use containers

There are different industry use cases that need to support different scnerios of deployment . For example some common views are follows

Telco Architects think the containers must be deployed on top of Existing Clouds mainly Openstack or VMware VCF (Through Pacific Project)

Enterprise folks believe containers should run with or without Kubernetes . Mainly wide use support on bare-metal is required

Application or IT guys think everything should run on Kubernetes (A.k.A K8S) . This is same view as the Developers

Build and Test Images

To build images there are different approaches and best approach is to give as many as possible flexibility to the Developer by using base images from where to build . However some best industry recommendations are as follows

• Start from carrier grade images like CentOS . Although it is a little Fat image but it will offset time in troubleshooting and enhancing , a definite value
• Second best aproach is to extract images using Mirror Tags like CoreDNS . This is a favorable direction from IT/Developer view point
• Other approach it to use simple images but with complete support on build utilities , E.g Debian Selenium
• Use of minimum base images like Alpine is also one direction depending on use case

Once the images are built the most important process will be to test and validate them , for this also our best suggestion is to

• Start from base images (So that minimum certification cases already tested)
• First check everything , the deployment approach
• Run tests in isolated environment first following by multi stage CI to separate test from production
• Use Utilities like buildX that can support both X86-64 and AMD Architectures

Registries

Which Registries to use in Cloud again depends on use cases and industry .For example for Telco the customer wants to have something adaptable with open stack so use of Zull registry is common followed by obviously Docker and Goharbor . Zull is specially convenient as it can tag/push images to docker hub with Zull jobs with wide use of image scan support using Clair

Container Runtimes

Docker is still believed to be the native and widely support run time environment specially in its Enterprise offering from Mirantis . The PodMan from RedHat is specially taking popularity however there are still a number of behavior issues in PoDMan specially on bind mounts and that need to be standardized before this move .OCI and CRIO are taking wider community support and i believe by Kubernetes 1.19 they may surpass PodMan .

For Telecom industry due to tenant isolation and security requirements the use of Kata is important , for some workloads like vIMS , vMME it becomes not a matter of software but regulatory to use certain architecture over other .

Deploy Containers in OpenStack

When it comes to deployment of containers on open stack there can be many approaches like in case of Magnum to build a Kubernetes controller or as simple as just a kernel configuration file using a set of utilities like Spyros that ensure complete LCM and fast deployment of containers on VM’s .

Similarly containers can use storage from Openstack in a number of ways including

• Cinder API
• Manila using NFS or Ceph FS
• Open ebs
• etcd

Obviously like in openstack the ephemeral storage has disadvantages like you can not know the implementation of provider and that is why implementation using Ceph3.0/Rook looks like the best direction in a hybrid cloud environment

Using the Containers

Networking and exposing containers outside is still a debatable topic and shall be the subject of separate writeup primary due to reasons that many workloads are still stateful and NIC is not floating instance for many workload specially in Telecom . Having said this still there are some suggestion to access containers in a stanard way like

• Use of Floating IP like in Calico and Flannel
• Ingress
• Customer CRD’s
• Octavia

https://docs.openstack.org/octavia/queens/reference/introduction.html

Again if we are deploying these solution on openstack we may need to use some encapsulation solutions like Kuryr to avoid double encapsulation or disable port security and supplement it using kube router or calico

Cloud Provider SIG

If you are a Telecom provider who already built Telco Cloud in recent years than this will be something really important for you as Cloud Provider supports a way to integrate Kubernetes (K8S) in Openstack using a number of cluster management tools like

• Magnum
• Kubermatic
• Gardener
• KoPs
• Cluster API

HPC and Scientific SIG

HPC use cases are becoming extremely important in Telco’s primarily due to ushering of new Tech wave and use cases around Cloud and 5G .

NVIDIA T-Series GPU is specially popular to run ML/AI workloads in Telecom . It can support high performance on VM’s using efficient resource utilization like 1:4 and for containers 1:8 by exposing GPU’s to VM’s running Kubernetes . In addition for special use cases like GIS and Image profiling can support pass through like the famous SR-IOV use cases of Telecom 5G CNF’s like UPF .

In a nutshell the containers are ready for production . However just like other cloud solution there is no one picture that fits all screens so a careful selection of components and solutions is required to ensure maximum advantage coming from the Cloud .This is why to ensure as community and industry we do not miss the boat like somehow we experience in Openstack VM journey it is very important to define and standardize both the consumption models and deployments scnerios that can support to achieve a real carrier grade evolution to containers .The Cloud iNFrastructure Telco Taskforce (CNTT) has recently launched new initiative to help bring focus on cloud-native network functions (CNF) and Kubernetes based platforms. A working group within Reference architecture 2 ( K8s based ), RA-2 has kicked off a short survey to collect data on Kubernetes adoption in telecom. The link is below , i do expect you will play active part to share your insights to uplift the infrastructure to the Cloud Native era .

https://docs.google.com/forms/d/e/1FAIpQLSfAr_FjOT2ykrEWWqFdc-8OWRv7sC2_vTgXl0hGzwJNYa10sg/viewform

Disrupting Telco Access rollouts through Open and Dis-aggregated RAN Networks

“Open, Intelligent, virtualized and fully interoperable”

O-RAN alliance

Source: O-RAN

During the last decade the Disaggregation movement which was initially started to address only a handful of business requirements have come far and delivered results. This early success has enabled many verticals to build the robust architectures through which we can solve both current and future business requirements to define a new momentum in a global Post COVID-19 economy.

For CSP and TMT industry specially we have seen Cloud movement is taking full momentum and hence it is becoming more prominent that we can only reap the real advantages from this transformation if the technology building block Lego’s are aligned with new principles to build infrastructure and networks. The list of such principles can be big and daunting however an Architect can start by breaking this list to Top important initiatives viz. 

• New Business models (To expand from Traditional B2C to B2B and Future B2B 2X (SaaS) offerings
• NE coding principles towards Cloud Native
• Focus towards Enterprise offerings
• Automation and efficiency
• Any Access
• Converged Transport and Finally
• Dis-aggregated and Open  RAN

All of these initiatives are inter mingled and has to be achieved along the transformation journey however there are some initiatives which have profound impact on CSP’s   investment and CAPEX/OPEX spending portfolio of which RAN comes to be on the top of list.

RAN(Radio Access Network)  networks which directly connects the subscriber to large Telco Infrastructure encompass to cover more than 5 Billion users  and define 1 Trillion $ Annual global revenue is certainly believed to be the most important infrastructure that we need to modernize and cloudify in an efficient manner .RAN has  historically proved to be a big cash cow for the Telco Industry . Infact  as per our analysis this piece is swallowing at least 70% of Operator CAPEX . So the traditional manner to build RAN networks by building a complete Radio/TXN Network using proprietary is neither attractive to the CFO nor is it scalable to deliver future requirements for new services in the 5G world. In this Paper I will try to share my view point how to start and build Dis-aggregated RAN Networks

How to build the Remote and Edge Clouds

We believe that in future every 5G new site will be an Edge Site which makes it necessary to build both Edge and RAN infrastructure on common and share Cloud Infrastructure. When it comes to define characteristics of this shared infrastructure the most important piece will be the operations and manageability of this large and scalable infrastructure.

Next the most important piece will be the networking primarily because we CSP’s traditionally have been doing this stuff for decades which is to ensure to wire and connect all solutions to offer them as a service to our customer. We have already seen some vendors bringing their commercial offerings to address these points, For example Vmware NSX-T 3.0 and Juniper 2.0 with unified SDN and analytics for all Core, Metro, Edge and Public Clouds. RedHat is another such vendor whose massively scaler AMQB based Openstack and Kubevirt based containerized platform support vision of complete automated infrastructure that is provisioned and managed by a central controller.

Future Disaggregated Hardware

Proponents of Closed RAN (at least from RU to DU) often claims the open X-86 hardware can not compete with high processing and performance required for a real time RAN however with the arrival of O-RAN (Open RAN alliance)  open interfaces , advancements in Silicon and collaborative community driven efforts such as in TIP driven Open RAN has really made it possible to open up the entire network and to build it using common principles using EOM offerings from a diverse suppliers .There are many advances in hardware that need to be carefully tailored to make successful Open RAN like ASICS specially for Network, GPU ,FPGA , NPU according to priorities for time-to-market, cost-performance, and reconfigurability, as well as scalability and SW ecosystem in making decision. Parallel processing-based accelerator can easily handle the performance of OFDMA and massive MIMO. In addition, the use of AI in edge computing is fueling the emergence of new AI processors beyond GPU, with TPU or spatial processor.

One of such recent advancements is Intel P-Series Atom Processor that is best suited to build Open RAN solutions , similarly to converge hardware at the sites Intel has announced the C-series Atom processors primarily which are used to deploy Edge and SD-WAN CPE’s , such a convergence is vital for industry to achieve vision of truly open and converged networks at the Edge and last mile networks .

One key point when we view Hardware modernization for Open RAN is to look advantages of Software e.g DPDK itself, For example the DPDK recent release DPDK19.05 only require 1-2 CPU cores per server so value coming from Smart NICs are declining as industry is reaching a new efficiency on the software. Again the latest offerings from intel chip set is a good example where latest Cascade Refresh is adding 30~40% power at the same cost which will make is possible not only to virtualize the RAN but to run AI and Data science processing at the Edge and RAN itself .

Having said this the hardware profile standardization of Open RAN components is already in full momentum with first release Beta coming in 2020 Feb and we expect to have a GA offer ready by end of 2020. So we can expect a commercial ready and GA  solutions of Open RAN to be ready by Q1 2021 .

Cost Efficiency of Open RAN and 5G Transport Networks

Although operators have gained early experience with 5G but obviously the cost to deploy the networks is quite high , it is primarily that still the RAN networks are not fully virtualized making transmission options possible that require a lot of transmission over heads . For example, based on our trials in middle East most vendors are coming with C-RAN delivery models only supporting Option 2-4 which waster more than 20% of transmission sources. Open RAN will make it possible to apply Option-7 to split the resources at RF and Lower Physical layers . The Open RAN lead network trails  will enable Cross-Layer network modeling to assess various scenarios

Understanding O-RAN , Open RAN , 3GPP

In the recent workshops with customers I have seen even a senior engineers sometimes confuse O-RAN , Open RAN and 3GPP itself , one common example is when some RAN teams claim that O-RAN is not 3GPP compliance and vice versa which obviously is  a wrong comparison  so it is important to share some thoughts of  how exactly it works

O-RAN:

As a matter of principle every O-RAN divides the whole RAN architecture in in RT-RIC (Real time  -RAN intelligent controller) , O-CU-CP(Open RAN CU control) , O-CU-IP (Open RAN CU user),O-DU (Open RAN DU) and O-RU (Open RAN RU) , the whole system view interconnected by interfaces is as follows

Source: O-RAN alliance

A1:The interface between RIC elements primary for policy control and implement AI/ML at the RAN side

O1:The O&M and monitoring interface

O2:The interface through which Orchestration layer control and provision the RAN Cloud components

E2 Interface:The interface that connects all the E2 nodes to the RT RIC , these E2 Nodes cane be CU-CP ,CU-UP ,DU or even an 4G O-eNb . As CUs are placed between RIC and DU, the location of CU will be left for decision of RAN vendors – either co-located with RIC or co-located with DU. Such choice will be an important for both telcos and vendors along the choice of open fronthaul. What is your choice?

Open Front Haul Interface:The interface between DU and RU

3GPP and its relation with O-RAN:

Primary body who defined the System Architecture and interfaces for horizontal services integration and specifications. 3GPP also defines a number of interfaces in O-RAN starting from 3GPP Release 15 where a nice description of interfaces can be found in 3GPP TS 31.905

The following interfaces are defined and managed by 3GPP and O-RAN is fully aligned with it as user or consumer of these interfaces these are

1. EI
2. FI
3. NG
4. X2
5. Xn
6. Uu

Open RAN:

Open RAN which is a TIP lead initiative is the complete E2E validation of O-RAN defined RAN architecture that also includes other components like Cloud ,Orchestration , Testing and validation of the full stack  The details can be found here https://telecominfraproject.com/openran/

“Open RAN Project Group is an initiative to define and build RAN solutions using a general purpose vendor neutral hardware and software defined technology “.

The flexibility of multivendor solutions enables a diverse ecosystem for operators to choose best-of-breed options for their 2G/3G/4G and 5G deployments. Solutions can be implemented on bare metal as well as on virtualized or containerized platforms.

One of the most important direction for Open RAN is to cover all 2G ,3G,4G and 5G NR solutions. Seeing Market in middle east as many operators will shutdown 2G by 2022 it is important specially to look for Open RAN solutions for 5G and 4G and in cases with 3G networks. Such pilots and network blue printing will be vital when we need to deploy such solutions in the brown fields.

In addition it will make possible for co-deployment and re-use of scarce spectrum resource’s between all access technologies.

RIC and Deployment Blue Prints for Open RAN Deployments

RAN intelligent controller (RIC) provides an interface between the RAN controller at the 5G core and the access network, enabling policy-driven closed-loop automation. The RIC is the interface piece that concatenates the RU, DU, and CU into the Open RAN (Full Functional Solution) through software programming and agile service delivery.

Introduction of many horizontal as well as vertical interfaces means more complexity to deploy and manage the Open RAN networks which requires a standard blue print manner to deploy such networks as provided by the Linux foundation Akraino Stack by abstracting the Infrastructure as a standard API and to be available Via standard API’s that can be consume d by the upper layers .RIC as depicted below deploy an east and flexible way to MANAGE Open RAN and having following characteristics

• Built from reusable components of the “Telco Appliance” blueprint family
• Automated Continuous Deployment pipeline testing the full software stack (bottom to top, from firmware up to and including application) simultaneously on chassis based extended environmental range servers and commodity datacenter servers
• Integrated with Regional Controller (Akraino Feature Project) for “zero touch” deployment of REC to edge sites

Orchestration of Open RAN

O-RAN Physical NF and O-Cloud represented by O-RAN architecture depicts the future RAN network comprise of many NE’s (As VNF’s or CNF’s) that will be part of standard Cloud -Cloud to be deployed on an X-86 hardware. This hardware will have standard acceleration support as may be required by each f the RAN NF and is responsible to de-couple each layer of the hardware from the software. However such a solution not only require standard deployment like Akraino but complete orchestration for both Day1 and Day 2 as supported by ICN (integrated Cloud Native network) . The standard orchestration is a key as it will not only orchestrate RAN functions but also other Functions like 5G CN along with provision of E2E Network slices and services.As the future Disaggregated networks split network in to layers so from both business perspective and technology view point we need to common set of tools to orchestrate the whole solution thus ensuring we  can provision any 5G and future business cases on the fly ranging from Remote Factory , e-health , video streaming , VGS broadcast etc .The latest Guilin release already consider how ONAP will power the Open RAN networks with future enhancement like REC blueprint automation and validation ,testing , FCAPS and running ML/AI streams based on Radio Network information are the features coming in next Honolulu release .

Summary

In summary O-RAN and related Open RAN solutions offer new architecture solutions for Telco industry that will make the Full disaggregation of networks possible. In addition to its alignment with Cloud and other related SDO’s mean the future networks can be al define, managed and operated suing same principles. For example, disaggregation means real value coming from deployment of singe transport infrastructure like IPV6 SRV+ where we can divide the single physical network in many logical networks that can serve both existing and new verticals. Similarly, Akraino /StarlingX and Airship installers will offer opportunity to deploy all stack using same principle and blue prints. Finally use of common orchestration platforms and futuristic networking slicing capabilities will open new business opportunities for Telco’s that was not possible before.

As we understand the overall mobility market is changing and coexistence of many access technologies including Wifi means dis aggregated , resource sharing and validated design is the need of the hour .It will not only help us unify the RAN but enable to really monetize the data from RAN like through AI and ML processing . It will also be fully beneficial for industry as a whole as fully open interfaces means  we can expand different components independently and validate it using open tools .s

This is therefore an important era to start the Open RAN journey and to take the early mover advantage in Disrupting the Networks  

Source: Linux Foundation

References:

1. https://www.5gtechnologyworld.com/5g-breaks-from-proprietary-systems-embraces-open-source-rans/
2. ONAP Guilin Release
3. Thought leadership recipes from Alex Jing
4. Akraino integrated cloud-native icn blueprint
5. https://docs.o-ran-sc.org/en/latest/architecture/architecture.html
6. Core analysis blogs

Enterprise and 5G Software Application packaging using Helm

Always great to start as a programmer

As most prolific developers consider Kubernetes as the future platform for application development , obviously against odds of Project Pacific https://blogs.vmware.com/vsphere/2019/08/introducing-project-pacific.html) . It is certainly worthy to know a platform that holds the future by learning how to best use it .

An investigation in to Kubernetes platform will reveal that although Kubernetes as platform is a kitchen with Recipe for all sort of applications in any vertical  however things can become very complex as we implement H/A , Load balancers  and other complex scnerio each of which require its own YAML definition and instance creation. In addition, as we apply more and more complex concepts like node affinity and taints it becomes more difficult to remember parameter definitions and to build configurations. Then in addition to this there are so many tools both in community and provided by partner distros followed by Geeks who are always willing to build their own tools so question is how to unify and address the challenges in the most efficient manner.

Can I use a collection of tools like Ansible + Mesos + Vagrant + Helm to use the best of all solve the Infra provisioning and monitoring issues?

 Obviously, no one tool can satisfy all but how to unify the pipeline and packaging and where to start, let us discuss some details to solve these very vital issues of future infrastructure. Most of these tools like HELM are available in community to accelerate development and find and fix bugs. Users of these tools also share deployment playbooks, manifests, recipes, etc  distributing via repos like GitHub and build platforms like Jenkins , mostly community and partners hardened this knowledge and also share it on secure and trusted repos and libraries like Ansible Galaxy  to which reader can refer to following to get more details https://galaxy.ansible.com/

Source: RedHat

All of this require a novel approach to manage the containerized infrastructure , HELM® which is a seed project with in CNCF® is a packaging solution that can address most of the challenges defined above . Just like Kubernetes it also supprots operators through which vendors and ISG can publish their software artefacts and packages to onboard it . This is also a way through which 5G CNF will be onboarded through NFVO (NFV Orchestrator) to the Infrastructure. This is exciting way to manage applications through easy to play charts , template files and easy to manage and control dependencies .

So let us try to understand some key concepts on Helm charts and Helm Operators.

Source: RedHat

Helm Charts:

A Helm chart is a single repository or artefact that contain all objects like deployment , services , policy , routes ,PV’s etc into a single .tgz (ZIP) file that can be instantiated on the fly . Helm also supprots aggregation concept which means you can either deploy each micro service or a collection of them altogether through one deployment process . The later is important specially in Telecom CNF’s . A good collection of helm charts are available at https://github.com/helm/charts which we can customize and also integrate with CI pipeline like Jenkins to do all operations on the fly .

When it comes to telecom and 5G CNF’s it is important to understand following terms before understanding contents of the package

Source: K8S and ETSI NFV Community

Source: Kodecloud and Project experience

Chart: A collection of resources which are packaged as one and will be used to run an application, too or service etc

Repo: A collection like an RPM used to manage and distribute resources as packages. Satellite can be used to integrate both VIM and CIM Repos in a 5G world

Release: A helm supprots to run a Canary release in a Telco environment, each time a chart is instantiated obviously including incremental changes each time will be considered a Release

Helm latest version is 3.0 release in ONS North Americas In Nov 2019 and includes a major change like removal of Tiller (Major security bottleneck) which was major impediment to use helm on more secure clusters.

Just like VNFD and NSD which follows ETSI ® SOL1 and SOL4 which defines VNF packages and its structure using TOSCA in Kubernetes we follow helm chart standard which YAML descriptors and structure that can be instantiates using helm create chart name , further it can be enriched and customized as per need , the mandatory manifests are values.yaml contains details like IP’s ,networks , template.yaml consumes the values ,chart.yaml the master file to manage charts , NOTES.txt  a comment files and Test.yaml to conduct chart testing once deployed . requirements.yaml is a file that list the dependencies

Happy and ready to apply your own helm charts , then try this out https://hub.helm.sh/charts?q=ericsson .  Although helm charts provide an easy way to manage applications however not all the changes are acceptable directly specially for the case of stateful CNF’s which are very relevant to the Telecom use case. In this case we need to use the Helm operator which first version 1.0 is GA now and let us discuss its key points below. Similarly Kubernetes operator need to be installed first via CRD’s , Helm charts behave in the same manner with a difference it is installed using Software developer provided charts .

 Helm Operators:

A helm chart and its packaging can be compared to Functions of Kubernetes operator which makes it easy to deploy and manage application across its life cycle using CRD and customer defined definition .

The helm operator is doing the next step of what Kubernetes is by enabling complete GitOps  for helm .It focused on defining a custom resource for the helm release itself thereby making it simple to manage complete artefacts as it is being deployed and managed .

As of April 2020 following are major features already added in Helm1.0 Operator

• Declaratively installs, upgrades, and deletes Helm releases
• Pull charts from anychart source;
• Public or private Helm repositories over HTTP/S
• Public or private Git repositories over HTTPS or SSH
• Any other public or private chart source using one of the availableHelm downloader plugins
• Allows Helm values to be specified;
• In-line in the HelmRelease resource
• In (external) sources, e.g. ConfigMap and Secret resources, or a (local) URL
• Automated purging on release install failures
• Automated (optional) rollback on upgrade failures
• Automated image upgradesusing Flux
• Automated (configurable) chart dependency updates for Helm charts from Git sources on install or upgrade
• Detection and recovery from Helm storage mutations (e.g. a manual Helm release that was made but conflicts with the declared configuration for the release)
• Parallel and scalable processing of different Helm Release resources using workers

Source: http://www.weave.works

Helm Operator can also work with other Kubernetes operators and address any dependency constraints infact all those can be expressed as part of the Chart itself. This is certainly needed in CNF’s and Telco use cases where there are lot of dependencies between API versions and cluster components for all rolling updates and each of this will require testing and validation. Traditional Helm obviously can not address it and it is almost impossible for user to address all such changes in an ever changing and complex world of network meshes, Helm operator ensures these requirements are fulfilled with in the GitOps frameworks.

Helm basic commands:

Below is a good jump start to some of basic helm commands .

• helm repo add

command to add a helm chart from a repo

• helm create chart-name

command to add a helm chart , a directory with basic files

• helm install –dry-run —debug ./mychart

Run dry run to install and show debug instructuctions

• helm package ./mychart

Will prepare the .tgz package and a user can install the application from this package.

• helm get all UPF -n CNF

Will retrieve the details of application deployed via helm in a give NS

• helm –help

Want to know all just try it out

Conclusion:

Although I have explained the Helm and Kubernetes in a way that one can believe that Helm chart is the replacement of Operator which is not the case. Infact the Helm is mainly aimed to deploy and manage Day1 tasks while still along the LCM of application you rely on CRD’s and Operators with one caveat why I do not like is that each time a new CRD we have to install and manage them. It will definitely change over time as Helm operator will target to resolve for most of day2 issues and that’s why I will encourage to get involved in Kubernetes SIG community.

Finally, as we will standardize the Dev Pipeline for Telco’s as well which is still too much invisible to us it will enable us to build hybrid cloud environment that will certainly solve so many fundamental architecture and business challenges. As an example, in the COVID-19 scnerio so many of the business face challenge to expand their networks to cater for increased load. If Telco’s already have figured out this pipeline it would have been both economical and responsible to share load between Onprem and Public cloud to address the hour need. This is why the journey to Hybrid cloud and software package standardization and delivery is too vital for both growth and sustainability of the Telco industry and national growth.

References:

ETSI NFV IFA29

@Oreily Kubernetes book sponsored by RedHat

https://medium.com/

https://www.weave.works/blog/introducing-helm-operator-1-0

https://www.digitalocean.com/

The comments in this paper do not reflect any views of my employer and sole analysis based on my individual participation in industry, partners and business at large. I hope sharing of this information with the larger community is the only way to share, improve and grow. Author can be reached at snasrullah@swedtel.com

 

Application Aware Infrastructure Architecture of Future Enterprise and Telecom Networks

An architect’s perspective in 2020+ era

The recent global situation and use of Critical Telecom infrastructure and Security solutions in the Cloud has shown to many critics as well the esoteric of  terms like Hybrid Cloud , AI , Analytics and modern applications is so vital to bring society and economy forward .

Seeing the latest development where we have been actively joining the community in both Infrastructure and Application evolution both in the Telco and Enterprise Application world i can safely conclude that days where Infrastructure is engineered or built to serve application requirements are over . On the contrary with the wide range of adoption of application containerization and Kubernetes as platform of choice the future direction is to design or craft the application that can best take advantage from a standard cloud infrastructure.

Understanding this relation is key impetus between business who will flay and those who will crawl to serve the ever-moving parts of the Eco System which are the Applications

Source: Intel public

In this paper let us try to investigate some key innovations on Infrastructure both Physical and Cloud which is changing the industry Pareto share from Applications to Infra thereby enabling the developers to code and innovate faster.

Industry readiness of containerized solutions

The adoption of micro services and application standardization around the 12 factor App by cloud Pioneer Heroku in 2012 gave birth to the entire new industry that has matured far quickly compared to virtualization. A brief description of how it is impacting market and industry can be referenced in Scott Kelly paper in Dynatrace blog . This innovation is based on standardization of Cloud native infrastructure and CNCF principles around Kubernetes platforms aimed at following key points

Scalability

The Covid-19 has proved the fact that if there  a single capability that is necessary for modern era business to survive then this is scalability , in recent weeks we have seen millions of downloads of video conferencing applications like Zoom , Webex , blue Jeans then similarly we have seen surge demand of services in the Cloud . Obviously, it would have been an altogether different story if still we were living in legacy Telco or IT world.  

Source: https://www.linkedin.com/pulse/effect-covid-19-work-from-home-enterprise-traffic-your-amit-sinha/

Immutable but Programmable

On every new deployment across the LCM of applications the services will be deployed on new infrastructure components, however all this should be managed via an automated framework. Although Containers in Telco space do require stateful and somehow mutable infrastructure however the beauty of Infra will keep the state out of its Core and managed on application and 3^rd party level ensuring easy management of the overall stack

Portable with minimum Toil

Portability and ease of migration across infrastructure PoPs is the most important benefit of lifting applications to the containers, infact the evolution of Hybrid clouds is the byproduct business can reap by ensuring applications portability in

Easy Monitoring and Observability of Infra

There is large innovation happening on the Chip set, Network Chips (ASIC), NOS i.e P4 etc however the current state of Infra do not allow the applications and services to fully capitalize on these advantages. This is why there  are many workarounds and complexity both around application assessment and application onboarding in current Network and Enterprise deployments

One goof example of how the Container platforms is changing the business experience on observability is Dynatrace which allows the code level visibility , layers mapping and digital experience across all hybrid clouds .

Source: dynatrace

Composable Infrastructure

Already there looks a link from platform to infrastructure which will support delivery of all workloads with different requirements over a shared infrastructure. The Kubernetes as a platform already architecting to fulfill this promise however it requires further enhancements in Hardware, the first phase of this enhancement is using HCI, our recent study shows in a central DC using of HCI will save CAPEX by 20% annually. The further introduction of open hardware and consolidation of open hardware and open networking as explained in the later section of this paper will mean services will be built, managed and disposed on the fly.

From automated Infrastructure to Orchestrated delivery

Infrastructure and Network automation is no longer a myth and there are many popular frameworks to support it like Ansible , Puppet , Jenkins and Cisco DevNet .

However, all those who work on IT and Telco Applications design and delivery will agree the cumbersomeness of both application assessment/onboarding and application management with little infrastructure visibility. This is because the mapping between application and infrastructure is not automated. The global initiatives of both the OSC and SDO’s like prevalent in TMT industry has primarily focused on Orchestration solutions that is leveraging the advantages of the infrastructure specially on chip sets driven by AI/ML and enabling this relationship to solve business issues by ensuring true de-coupling between the Application and Infrastructure

Although the reader can say the platforms like Kubernetes has played a vital part for this move however without taking advantages of physical infrastructure simply it could not be possible. For example both Orchestration in IT side primarily driven by K8S and on Telco Side primarily driven by initiatives like OSM and ONAP is relying on infra to execute all pass through and accelerations required by the applications to fulfill business requirements  .

Infact the Nirvana state of Automated networks a more cohesive and coordinate interaction between application and infrastructure under the closed loop instructions of Orchestrator to enable delivery of Industry4.0 targets.

Benefiting from the Advantages of the Silicon

Advantages of Silicon were, are and will be the source of innovation in the Cloud and 5G era . When it comes to Hardware infrastructure role in whole Ecosystem, we must look to capitalize on following

The changing role of Silicon Chips and Architectures (X-86 vs ARM)

The Intel and AMD choices are something familiar to many Data center teams, somehow in data centers where performance is a killer still Intel XEON family outperforms AMD whose advantages of lower floor print (7nm) and better Core/Price ratio has not built a rational to select them. Other major direction supporting Intel is their supremacy in 5G , Edge and AI chips for which AMD somehow failed to bring a comparative alternative. The most important drawback as the author views is basically the sourcing issues and global presence which makes big OEM/ODM’s to prefer Intel over AMD.

However the Hi-Tec industry fight to dominate the market with multiple supply options specially during recent US-China trade conflict has put TMT industry in a tough choice to consider non X-86 Architectures something which obviously no one like to have as its Eco system is not mature and the author believes a un-rational selection will mean the future business may not be able to catch advantages coming from disruptors and open industry initiatives like ONF ,  TIP , ORAN etc

Following points should be considered while evaluating

1. Ecosystem support
2. Use cases (The one which support Max should win)
3. Business case analysis to evaluate performance vs high density

            Except Edge and C-RAN obviously Intel beats ARM

4. Aggregate throughput per Server
5. NIC support specially FPGA and Smart NIC

          Obviously, Intel has a preference here

6. Cache and RAM, over years Intel has focused more on RAM and RDIMM innovation so somehow on Cache side its thing ARM has an edge and should be evaluated. However consider fact not all use cases require it makes it a less distinct advantage
7. Storage and Cores , this will be key distinguisher however we find both vendors are not good in both. Secondly their ready configuration means we have to compromise one over other

           This will be the killer point for the future silicon architecture selection

8. Finally, the use of inbuilt switching modules in ARM bypassing totally the TOR/SPINE architecture in Data centers in totally may got proponents of Pre-Data center architecture era however promise of in-built switching in scaled architecture is not tested well. For example, it means it is a good architecture to be used in dense edge deployments but obviously as far as my say is not recommended for large central Data centers.

However only the quantitative judgement is not enough as too much dominance of intel meant they do not deliver the necessary design cadence as expected by business and obviously opened gates for others, it is my humble believe in the 5G and Cloud era at least outside the Data centers both Intel and ARM will have deployments and that they need to prove their success in commercial deployments so you should expect both XEON® and Exynos silicon recently .

FPGA ,SmartNICs and vGPU’s:

Software architecture has recently moved for C/C++/JS/Ruby to more disruptive Python/Go/YAML schemes primarily in a drive of business to adopt the Cloud . Business is addressing these challenges by requiring more and more X-86 compute power however improving the efficiency is equally important as well. As an example, Intel Smart NIC family PAC 3000 we tested for a long time to ensure we validate power and performance requirements for throughput heavy workloads.

Similarly, Video will be vital service in 5G however it will require SP’s to implement AI and ML in the Cloud. The engineered solutions of RedHat OSP and Openshift with NVIDIA vGPU means the data processing that was previously only possible in offline analytics using static data source of CEM and Wirefilters.

Source: https://developer.nvidia.com/gtc/2020/video/s22106

Envisaging the future networks that combines power of all hardware options like Silicon Chips, FPGA, Smart NICs, GPU’s is vital to solve the most vital and business savvy challenges we have been facing in the Cloud and 5G era.

Networking Infrastructure

There is no doubt networking has been the most important piece in Infrastructure and the networking importance has only increased with virtualization and with a further 10-Fold increase with Containers primarily as Data centers fight to deliver best solutions for East-West Traffic. Although there are a number of SDN or automation solutions however there performance has scale has really shifted the balance towards infrastructure where more and more vendors are now vesting on the advantages of ASIC’s and NPC’s to improve both the forward plane performance but also to make the whole stack including fabric and overlay automated and intelligent fulfilling IDN dream by using latest Intel chips that comes with inherent AI and ML capabilities .

The story of how hardware innovation is bringing agility to network and services do not ends here for example use of Smart NICS and FPGA to deploy SRV6 is a successful business reality of today to converge compute and networking infrastructure around shared and common infrastructure.

Central Monitoring

Decoupling, pooling and centralized monitoring is the target to achieve and already we know with so many solutions which are somehow totally different in nature like on networking side between fabric and overlay means to harmonize the solutions through concept of single view visibility. This will mean that when an application demands elasticity hardware does not need to be physically reconfigured. More compute power, for instance, can be pulled from the pool and applied to the application.

 From Hyperscale’s to innovators

The dominance of hyperscale’s in Cloud is well known however recently there had been some further movements that is disrupting the whole chain. For example, now ONF Open EPC can be deployed on OCP platform. Similarly, the TIP Open-RAN initiative is changing the whole landscape to image something which was not even in discussion a few years before.

Since the ONF is too focused on Software and advantage brought forward by NOS and P4 programming so I think it is important just to talk about OCP . The new innovations in rack design and open networking will ensure to define new compute and storage specifications that best meet the requirements for the unique business requirements  .Software for Open Networking in the Cloud (SONiC) was built using the SAI (Switch Abstraction Interface) switch programming API and has been adopted unsurprisingly by Microsoft, Alibaba, LinkedIn, Tencent and more. The speed at which adoption is taking place is phenomenal and new features are being added to the open source project all the time, like integration with Kubernetes and configuration management

Summary review

Finally, I am seeing a new wave of innovation and this time it is coming via harmonizing of architecture around Hardware, thanks to the effort in last few years around Cloud , Open Stack and Kubernetes. However, these types if initiatives will need a more collaborative efforts between OSC and SDO’s i.e TIP and OCP Project harnessing the best of both Worlds

However, with proliferation of so many solutions and offerings the standardization and alignment of common definitions of Specs for the Shared Infrastructure is very important.

Source: Adva

Similarly to ensure innovation delivers the promise the involvement of End user community will be very important , the directions like LFN CNTT , ONAP , ETSI NFV , CNCF and GSMA TEC are some of the streams which require operator community wide support and involvement to come out of clumsy picture of NFV/Cloud of last  decade to replace by true innovative picture of Network and Digital Transformation .A balanced approach from Enterprise and Telco industry will result the business of today to become the hyperscale’s of tomorrow .

I believe this is why after a break this is the topic I selected to write. I am looking forward for any comments and reviews that can benefit community at large

Annex

• Fast Convergence and Network Stability Considerations in Service Provider Network  https://www.youtube.com/watch?v=yG2pwOtiBo4&t=37s

• https://marketrealist.com/2019/08/nvidia-partners-with-vmware-brings-ai-boosting-gpus/
• https://www.nextplatform.com/2020/01/06/the-other-way-to-bring-arm-cpus-to-servers/
• https://www.sdxcentral.com/data-center/composable/definitions/what-is-composable-infrastructure-definition/
• OSC -Open Source community
• LFN- Linux Foundation
• NPC -Network Processing Cards

 The comments in this paper do not reflect any views of my employer and sole analysis based on my individual participation in industry, partners and business at large. I hope sharing of this information with the larger community is the only way to share, improve and grow. Author can be reached at snasrullah@swedtel.com

 

How Open Orchestration enhances Enterprise, 5G , Edge and Containerized applications in Production

Source: ETSI <www.etsi.org>

 

How Open Orchestration (OSM Release-7) enhances  Enterprise, 5G , Edge and Containerized applications in Production

An architect’s perspective from ETSI® the Standards People

 

As highlighted in the Heavy reading latest End-to-End Service Management for SDN & NFV all the major T1 Telco’s are currently refining their Transformation journey to bring standard Orchestration and Service modeling in their networks , one of such standard approach is promised by ETSI OSM a seed project from ETS® the standards people .

Recently in Q4 2019 ETSI OSM release the Release7 which address surmount challenges of brings CNF and Containerized applications to the production ETSI OPEN SOURCE MANO UNVEILS RELEASE SEVEN, ENABLES MORE THAN 20,000 CLOUD-NATIVE APPLICATIONS FOR NFV ENVIRONMENTS

This capability of ETSI® OSM is specifically important considering the ushering of 5G SA architecture and solutions which already find its way to the market thanks to early work from CNCF and specifically CNTT K8S specs . OSM brings value to the picture as it will allow to design, model, deploy and manage CNF’s (As ETSI NFV call is a containerized VNF) without any translation or modeling. It also lets operators experience early commercial use case of integration Helm2.0 in their production environments. On top of it will allow a NS (Network Service) to combine CNF’s with existing VNF’s or legacy PNF’s to deliver complex services in an easy to deploy and manageable manner.

In the following part of this paper I will try to share my understanding on OSM release7 and sum up results from ETSI OSM webinar on this subject held on JAN 16^th 2020 . For details you may need to refer to webinar content itself and can be found https://www.brighttalk.com/webcast/12761/380670  

Why Kubernetes is so important for Telco and Enterprise

Telco industry has experienced lot of pain points the way NFV journey has steered with focus on migrating existing PNF’s to the Cloud. K8S offers opportunity for all Platform providers, application vendors, assurance partners to build something on modern principles of micro services, DevOps and Open API’s driven. This is something that already made its way to Telco’s in OSS and IT systems as an example mycom OSI UPM , OSM and  infact ONAP all are already based on Kubernetes , the arrival of 5G SA and uCPE branches has driven almost all operators adopt networks to use Kubernetes . Further it is principally agreed as CSP’s move to Edge the K8S will be the platform of choice.

Foundation for K8S Clusters

Kubernetes made it simple for the applications and CNF’s to use API’s in a standard fashion using K8S Clusters which are deployed either in an open source manner or via Distros. The early adoption of CNF’s in Telco largely supports the consumption model of vendor Distros like RedHat OpenShift, Vmware PKS, Ericsson CCD to mention the most important ones.

Since containers are like a floating VM’s so networking architecture specially the one promised by L3 CNI plugin and Flannel is important direction to be supported in Platforms as it is supported in OSM .

The reusability of API makes it simple for application to craft unique application in form a build configuration files using artifacts of PoD, services, cluster, config map and persistent volumes which are defined in a very standard manner in K8S by which I mean deploy all artifacts through a single file.

ETSI® OSM can be deployed using both HELM2.0 as well as Juju charmed bundles

Foundation for Helm

Helm gives teams the tools they need to collaborate when creating, installing, and managing applications inside of Kubernetes. With Helm, you can… Find prepackaged software (charts) to install and use Easily create and host your own packages , Install packages into any Kubernetes cluster Query the cluster to see what packages are installed and running Update, delete, rollback, or view the history of installed packages Helm makes it easy to run applications inside Kubernetes. For details please refer to details HELM packages on https://helm.sh/blog/helm-3-released/

In a nut shell all day1 and day2 tasks required for the CNF’s are made possible using Helm and its artifacts known as Helm charts including application primitives, network connectivity and configuration capabilities.

Key Features of OSM Release7

OSM Release 7 is a carrier grade and below are its key features as per wiki

• Improved VNF Configuration interface (One stop shop) for all Day0/1/2 operations
• Improved Grafana dashboard
• VNFD and NSD testing
• Python3 support
• CNF’s support in both options where OSM creates the Cluster or rely on OEM tools to provision it
• Workload placement and optimization (Something very important for Edge and Remote clouds)
• Enhancement in both Multi VIM and Multi SDN support
• Support for Public Clouds

How OSM handles deployment of CNF’s

For most Telco guys this is most important question e.g how VNF package will be standardized with arrival of CNF’s , Will it mean a totally new Package or enhancement of existing.

Fortunately, OSM approach on this is modeling of Application in a standard fashion which means same package can be enhanced to reflect containerized deployment. On a NS level it can flexibly interwork with VNF/PNF as well, the deployment unit used to model CNF specific parameters is called KDU’s (Kubernetes Deployment Unit) other major change is K8S cluster under resources. It is important as it explains most important piece the Networking and related CNI interfaces.

OSM can deploy the K8S cluster using API integration or rely on 3^rd party tools like Openshift® or PKS deploy it on instructions of OSM

Changes to NFVO interfaces

Just like Or-Vi is used for infrastructure integration with Orchestration the Helm2.0 (Will support 3.0 in near future) is used for infrastructure integration with K8S applications. Since the NBI supports mapping of KDU’s in same NSD it means only changes from orchestration point of view is on the south side only.

Workload Placement

As per latest industry standing and experience sharing in Kubecon and Cloud Native  summit Americas  there is a growing consensus that Container is the platform of choice for the Edge primarily due to its robustness , operational model and lighter foot print . As per our experience of containers here in STC a 40% reduction in both CAPEX and Foot print will be realized on DC’s if deployed Edge using Containers.

However, definition of business definition of Edge raise number of queries the most important of it are work load identification, placement and migration specially consider the fact the Edge is a lighter foot print that in future will host carrier mission critical applications.

Optimization of Edge from CSP perspective has to address following  Cost of compute in NFVI PoP’s , Cost of connectivity and VNFDFG something implemented by SFC’s and Constraints on service like SLA, KPI and Slicing

The issues with the Upgrades and How OSM addresses

Compared to early release the OSM ns action primitives allow the CNF to be upgrades to the latest release and execute both dryrun and  Juju tests to ensure the application performance bench mark is same like before  .Although this works best for small applications like LDAP the same is difficult to achieve with more complex CNF’s like 5G SA . Through liaison with LFN OVP program I am sure soon the issue will be addressed. We as operator have a plan to validate it on a 5G SA nodes.

My final thoughts on this that  Container journey for CSP is already a reality and coming very shortly in 2020+ and OSM ecosystem supports the commercialization of CNF’s through early use cases of 5G SA , Enterprise branch uCPE and most important Edge including MEC for which OSM seems to reach maturity  For details and how to participate and use do get involved in upcoming OSM Hackfest IN MARCH OSM-MR8 Hackfest

Many thanks to colleague , mentor and industry collaborator Jose Miguel Guzman , Francisco Javier Ramón Salguero  Gerardo García and Andy Reid for OSM growth in recent years … See you in Madrid

References:

ETSI

Linux Foundation

OVP

Evolving your Network in the Cloud Era the Introduction of SDN in your Network

The Introduction of SDN in your Network

The design of Underlay and the route convergence is key whenever you plan to evolve a legacy NFVI network to SDN.

With Juniper Contrail you must see the community RA to see how OVS VxLAN defines the baseline to avoid all E-W traffic definitions in the Underlay. Below two pictures give you principle on Underlay and principles going forward.

1.  VM1 sends an ARP Request packet to request for VM3’s MAC address.
2. After receiving the ARP Request packet, VTEP1 searches the ARP table for VM3’s MAC address, and sends an ARP Reply packet for VM3 to VM1.
3. After VM1 sends data packets to VM3, VTEP1 searches the local MAC forwarding table. After the packets match the VXLAN tunnel table, VTEP1 encapsulates the packets into VXLAN packets and then finds the mapping Layer 2 VNIs based on the BDs of the packets. VTEP1 then uses the Layer 2 VNIs as the VXLAN VNIs and forwards the packets to VTEP2.
4.  After receiving the data packets, VTEP2 decapsulates them, searches for the destination MAC address in the local MAC forwarding table, and then forwards the packets to VM3.

Firewalls manage and control traffic generated in communication within a VPC, between VPCs and external networks such as the Internet, MPLS VPNs, and private lines, and between public clouds and tenants’ private clouds through IPsec VPN.

During the Lab validation we used the BGP as the routing protocol for both the underlay and overlay

However for Production environment it is very important to refer to scaling side of VTEPS . Although having VTEP inside OVS will have no impact on scale.

It is better to have VTEP as close to the source/destination of traffic as possible as you minimize the number of intermediate forwarding elements. You can see that most SDN solutions opt for having a VTEP inside the hypervisor/OVS even when they can do it on a TOR (Contrail, ACI, Nuage). And there’s no impact on O&M since sw VTEPs are not supposed to be managed by cloud operators but instead are automatically programmed by VIM’s networking driver (e.g. Neutron, NSX). Also the functionality performed by sw VTEPs is quite simple (L2-L4 forwarding) so they are usually thoroughly tested and “just work”. Where I work we have done a couple of relatively big Telco SDN DC networks (~500 compute nodes) with sw VTEPs and didn’t have any problems with that approach. When they do break, however, troubleshooting sw VTEPs is quite complicated and is usually done by SDN vendor’s TAC. The only serious disadvantage of having a sw VTEP is performance.

There are several solutions that we’ve implemented to boost the performance:

1) SRIOV

2) DPDK

3) VXLAN hardware offload

4) hw VTEP on TOR and there’s plenty more that we haven’t tried .