Cloud Native Computing Foundation CNCF Webinars, 10 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes in the Context of On-premises Edge and Network Edge Computing

Description

For cloud native edge computing applications there is a need for facilitating data processing at the edge of the network to stay at proximity to the source of events with characteristics of ultra-low latency and high bandwidth connectivity, enabling innovative and cutting-edge applications such as video analytics, virtual reality, the Internet of Things (IoT) and self-driving cars.

This webinar will introduce you to the Open Network Edge Services Software (OpenNESS), an open source, reference cloud-native architecture that enables the Cloud Services Providers (CSPs) and Communication Services Providers (CoSPs) to deploy end-to-end on-premises and network edge services leveraging various CNCF ingredients with Kubernetes at its core - an implementation that delivers recipes for generating new network edge capabilities such as:

- Abstracted platform & network complexity
- Enhanced dataplane
- Hardware accelerators management
- Dynamic discovery & optimal apps/services placement
- Open integration with Cloud Native Functions (CNFs)

A

Hello, everyone I'd like to thank everyone. Who's joining us welcome to today's cncf webinar kubernetes in the context of on-premises and get edge and network edge computing with intel, I'm libby schultz and I'll be moderating. Today's webinar we'd like to welcome our presenters, ahmer mokhtar network software engineer at intel and prakash kartha segment director at intel a few housekeeping items before we get started during the webinar. You are not able to talk as an attendee. There is a q, a box at the bottom of your screen.

A

Please feel free to drop your questions in there and we'll get to as many as we can. At the end. This is an official webinar of the cncf and, as such is subject to the cncf code of conduct. Please do not add anything to the chat or questions that would be in violation of that code of conduct. Basically, please be respectful of all your fellow participants and presenters.

A

Please also note that the recording and slides will be posted later today to the cncf webinar page at www, dot, cncf, dot, io, slash webinars. With that I'll go ahead and hand it over to amar and prakash to kick off today's presentation.

B

Thank you, libby hello. My name is prakash kartha, like let me mention we are going to be talking to today about openness, our open network edge services, software enabling high performance edge for telco and enterprise.

B

I am with intel's network platforms group, where I'm a segment director for edge and with me is amer hello.

C

Everyone, so my name is zamar mukhtar and I'm a software engineer with the with intel. I'm currently an active contributor to the openness project, and I previously worked in other projects such as dvdk and flex, ran.

B

Okay, so let's talk to the agenda, we'll first start with some of the opportunities and challenges uh that we believe will exist as you deploy edge in a telco environment, uh we'll introduce you to the project, called openness and then walk through the architecture, various deployment scenarios and how we can get started and then we'll have some wrap-up thoughts and then we'll go into q. A.

B

Okay, so first, let's talk about uh our vision for the edge and we see the edge um as a distributed. uh You know across different locations so from a distribution perspective. There's what we call the on-premise edge, which typically sits you know in an enterprise, could be private.

B

Wireless uh could be in an iot type scenario, and then we have what's known as the network edge or what we call the network edge, which we distribute along the axis, which would be like a base station or the near edge, which would be where you know a a 5g user plane might reside or a regional data center, where you may have different types of applications.

B

Now, one of the opportunities that we see here is that as a telco, if you're looking at edge across these different locations, whether it's on premise or the network edge, there is a tremendous opportunity to reduce your total cost of ownership and and build a consistent environment for the edge in this consistent environment based on cloud native platform, approaches across all these edge locations.

B

And uh it's it's uh it's quite you know easy to imagine why. That would be the case because, if you try to you know, build uh edge cloud native platforms for different edge locations, you're gonna start to drive up your cost, your not just to build a platform, but also to manage an ecosystem deliver services. So, as a telco, you know, telcos are always looking for ways to uh you know: build cost efficient.

B

You know reusable scalable type platforms, so this we believe, is a huge opportunity to you know to enable consistent cloud native platform approaches for all of these different edge locations.

B

So, as we move to the next slide, we'll will understand what are some of the challenges with addressing these this particular opportunity to reduce tco. So, as you can imagine here, each of these locations are going to look quite different from an edge perspective. uh The platforms are going to look very different. For instance, if you are, you know, building a platform for an on-premise type deployment.

B

Let's say a private wireless type deployment. You are out in the field, your you know, your your cons, your your environment is going to be extremely constrained, whereas if you move to a access edge, you're going to have a little bit more flexibility, but you're still pretty much, you know constrained by what you can do and as you're going deeper into the network, it's going to start looking more and more like a data center.

B

So um so the first challenge you're going to have, is: how do you deliver platform, consistency and scalability across all of these diverse edge locations which have different requirements? That's your number one challenge.

B

The next thing you would come across is you know, assuming this is going to be a fully cloud native framework that you're using across the board. We still see that cloud native pr cloud native is still quiet, uh not quite ready for the edge right, a lot of stringent kpis that need to be supported for the edge, whether it's a latency or whether it's determinism and the ability to deal with a lot of the underlying network complexity around multi-axis right.

B

So, in a lot of these scenarios, um you know you you may have 5g or lte, or you may have wi-fi. The access networks are going to be quite diverse, and your networking topologies may be quite diverse. For all these reasons, you know these cloud native frameworks that we all know still need to be optimized. Quite a bit. That's going to be our second challenge.

B

The third challenge is going to be that the standards haven't quite caught up, but they're they're, almost there right from a 3gpp perspective, we're really starting to see more edge, specific standards getting developed. So, as you are kind of in this brown field, type environment, where you already have a network and you're bringing on new capabilities you're going to have to figure out how as a telco, how to bring on some of these standards-based deployments.

B

So with that going into the next slide, we will talk about uh how we are trying to address some of these challenges with this project called openness. So openness stands for open network edge services, software. It is a cncf certified, kubernetes solution.

B

Openness is a edge computing software toolkit that enables highly optimized, secure and performant edge platforms to onboard and manage applications and network functions with cloud-like agility across any type of network. So each of these each of these statements is quite important, so the first point is extremely optimized for some of these network workloads, it's secure and it's performant.

B

So this the solution is extremely modular. So it's it's built on a concept of building blocks and these building blocks are built on top of a uh cloud native foundation. So all the key cloud native projects form the basic framework for openness so including kubernetes service mesh, uh the telemetry projects, helm uh operator framework. These are all the foundational elements and then openness builds on top specific capabilities like multi-access, networking, multi-cluster, orchestration, uh edge of air service, mesh confidential computing ban overlay and so on and so forth.

B

Now there are a few use cases that we target as the top use cases, starting with uh a 5g access edge, including a 5g, ran virtualized ram. uh You know enabled on a cloud native environment that is one of the key use cases, so you can run basically a 5g base station. On top of this platform, we have support for a 5g, distributed user plane, function, support for a sd van and various mech applications or multi-edge computing multi-access computing applications such as ai, inferencing and media.

B

So these are all the top use cases that are enabled on this platform from a key feature standpoint. uh The number one capability that we address is you know ensuring that the edge kpis are met, including throughput determinism, quality of service, latency and so on. This solution is intended to run in different environments, including different cloud environments, different access environments, so as multi-access as multi-cloud, and it's delivered via different types of reference architecture.

B

So these reference architectures, are, you know, different different combinations of these building blocks, put together to service certain use cases, and this is quite uh interesting because you know you can choose a reference architecture depending on what type of platform you're trying to build, whether you're trying to build a a base station versus a new rich platform versus an on-premise platform.

B

And of course we we address all the industry standards like 3dpp, um oran, sc and some of the you know more of the you know, de facto standards that cncf has been uh has been addressing um with that. I'm going to pass this to amer who's, going to go over the architecture in a lot more.

C

Detail thanks for hash. um So uh now, let's take a closer look at the open network, edge services, software architecture and its building blocks.

C

um As we look ahead towards a cloud-like 5g network, we are delivering the open network edge services software. We call it openness. For short, the openness is an open and cloud native architecture um as prakash introduced that is, transforming the telco network edge and thereby promoting it to uh to be managed and provisioned in a cloud-like agility.

C

It also enables building highly optimized and performant platforms that orchestrates workloads network functions and hardware resources, while preserving the separation of the control and data plane.

C

So, following the kubernetes nature of doing things, the openness builds uh edge clusters that are composed of one or more.

A

C

High availability, nodes that belong to the control, plane and multiple worker nodes, which we call them edge nodes, so these edge nodes are the ones that are actually positioned at remote sites and close to the source of events.

C

The controller manages and onboards uh energy applications uh and services um and network functions uh efficiently uh according to the edge nodes features and their uh platform capabilities.

C

The controller also provisions acceleration resources to their workloads and provides highly optimized container networking for their data plane using technologies such as open, v-switching, ebbf and uh pcie surrou vcni.

C

All the kubernetes capabilities are still included in the openness architecture like the node feature, discovery, telemetry and telemetry, our scheduling, container, runtime and virtualization infrastructure and hardware acceleration discovery and provisioning and management.

C

So as we are doing in openness, what we are doing doing in openness is that we are picking up the latest kubernetes releases and other cncf projects. Then we build on top of them various extensions at different levels for the purpose of promoting network edge deployments.

C

So at the platform level, we are integrating the bare metal container components for resource-based deployments, such as node feature discovery and resource management, daemon, pneuma, aware scheduling and cpu manager, and we are also extending the telemetry pipeline that is based on click, d, c advisor, prometheus and graphana, and then topping them, topping them up with dedicated metrics exporters for accelerators that we are enabling for edge deployment edge deployments with openness.

C

We are also enhancing and integrating the hardware acceleration device plug-ins for a pga based forward error, correction and intel movidius vision, processing units.

C

Also, apart from the core dns that is part of the vanilla kubernetes bring up, we are provisioning. What we call the edge dns service.

C

The hd nest service provides the domain name resolution for the external devices that are attempting to discover and consume business to consumer software as a service that are hosted by the edge cluster and an open for public consumption.

C

Some or all of these services could be monetized by the service provider and only allowed for premium users.

C

The the deterministic cloud native is another crucial capability um when deploying cloud native radio access network functions.

C

So the uh the radio access network functions uh have very stringent uh requirements for uh latency and timeliness of their of the messaging at the radio link, and for that we are providing a recipe with the best known platform configurations and real-time characteristics that will achieve optimal performance on the general purpose. Compute.

C

At the application level, we are delivering a video analytics services that are available through a service mesh. These services allow third-party application vendors to quickly build optimized video influencing pipelines without being experts in the media processing domain.

C

We are also defining uh reference edge network functions for native integration, with the public telco cloud infrastructure and the the the mobile network standardization body 3gbp has provided a software-based solution for all its network functions.

C

uh Network functions such as application function and network exposure function in ef are key appliances that are hosted by openness in order to influence and steer the traffic. That's propagating through the core network towards the edge nodes.

C

In a related context, we are providing recipes for deploying reference cloud native radio access networks with the deterministic orchestration.

C

We will explore more about the uh vran deployment scenarios in the in the following slide and at the uh orchestration level, uh openness is shipped with the telemetry aware, scheduling and cube ctl plugins such as cnca, so cncs stands for a core network configuration agent and it is.

C

It is primarily used to set up the core network traffic influencing rules for the core network functions.

C

Another cube, ctl plugin is called fpga remote system update, so the remote system, update plugin, provides a cloud friendly means to automate the rtl image upgrading for fpga based auxiliary accelerators without track rule, which reduces the overall operational costs, and this rsu plugin is also integrated with the operator framework for fully autonomous system upgrading.

C

We will cover more as well on the fpga operator and rsu in further details shortly.

B

uh By the way, if you have any questions, you know go ahead and submit to the chat window, we'll obviously get to it at the end.

C

Yeah absolutely.

C

So now that we had an idea about the openness architecture and its extensions for integrating existing network infrastructure, let's explore some of the reference deployment scenarios.

C

um As you may know, uh rakuten recently announced a fully cloud native 5g end-to-end network, uh including vran core and apps. Openness provides various foundational elements for this deployment in partnership with commercial partners like altiustar and ruben io, and this is a realization of the industry's mission in to advance the the public mobile telco network towards a modern software-based architecture that all its network functions are cloudified and dynamically positioned at various locations.

C

Many of these defined functions occur in virtualized environments at or near the edge of the network.

C

The radio signal processing stack in both lte and 5g nr is a pipeline of functions that are controlled by signaling derived.

A

C

From the core network, as the radioaccess network and the core network decompose, it becomes a necessity to distribute their functions across various locations, as shown in the in this diagram.

C

The the radio axis the original and the the central data center openness enables these functions, visualization and orchestration across these locations.

C

At the radio access openness provisions, cloud native in odb and and gnode b, workloads on deterministic infrastructure because of their time sensitivity needs also. Radio specific applications, such as radio network information and location information services, can be deployed side by side in the same openness edge. Cluster openness also enables media-centric applications such as immersive media content, delivery networks and smart city applications to be deployed at the original data centers and for the core network.

C

Openness provides extensions extension apis to for smooth integration and harmonized control and user plane, separation and traffic, influencing for the lte and 5g core.

C

In a a private wireless tylco setting openness enables hosting edge applications and services at the customer premises. These edge applications are managed and orchestrated by a centralized office that could be sitting in the cloud. The various branch sites are connected over a software defined wide area network sd1. For short, the decentralized office is commonly titled as an sd1 controller, as shown there at the top right corner.

C

Sd1 is a software driven model for the 4d1.

C

That is that, instead of rooting, traffic just based on addresses, it is application aware, meaning that it uses software to more intelligently root or steer traffic across the one based on the business requirements for uh for these applications, sd-wan architecture, logically simulates uh age applications and their management functions from the one transport services like mpls broadband internet or the lte or 5g similar to 3gpp sd1 separates the control management plane from the data plane uh in the in the context of sd-wan uh data.

C

Plane is also known, as the uh data forwarding plane, the the data forwarding plane is, is established over secure tunnels that have been set up between the branch sites, while their control is managed by a centralized data center.

C

Multiple access technologies are natively supported by openness-based deployments, um so, regardless of what access technology, the devices at the branch sites who would be using either private mobile lte or 5g access, wi-fi or even traditional lan.

C

Therefore sd-wan network functions that are underpinned by the openness infrastructure will be able to provide seamless access, seamless access to the on-premise edge applications and services.

C

As we discussed earlier earlier, a key part of the cloud native radio access network functionality is the execution of the lte and 5g physical layer pipeline in a deterministic manner.

C

In in this reference deployment, we are using the uh flickstrand. So flexran is a reference layer uh layer, one pipeline of 4g node b and 5g juno b, that is optimized for until uh architecture.

C

Flextran executes uh baseband uh e unit, um so for short, abu um and and bibu threads are uh at real time and they are given direct access to ethernet issue iv functions to terminate front hall and mid-hall 3gpp traffic.

C

Also, they are giving access to forward error correction acceleration cues that are memory, mapped and passed through as pisa bcie is iov functions. uh These forward error correction cues uh enable accelerating the channel coding actual operations uh using the intel fpga programmable accelerator card.

C

The bbu threads are a group of critical execution routines that must be executed on isolated cpu. Cores isolated here means that these are the cpu cores that the the bbu threads are giving exclusive access to.

C

So when booting, the linux kernel with the correct set of parameters, the linux kernel, scheduler will take care of prohibiting any processes to be scheduled or any interrupts to be serviced on these isolated ones.

C

uh By doing that, then, the pbu threads execution is not impaired by any kernel, interrupts or context. Switching we've used kubernetes cpu manager and the topology manager and did not feature this discovery to fulfill a flex, ran pod isolation and to provide optimal placement.

C

Also using the israeli vcni and srio vga device plugins, the flexrand pods are correctly scheduled and provision provision the hardware resources they need to transceive radio traffic and access the acceleration.

C

So for cloud native radio access network deployment, openness delivers a well-defined recipe for best performance on general purpose. Compute. This recipe defines the optimal real-time kernel, setting the necessary bias, bios configuration and the most efficient cpu frequency and power management settings.

C

The uh intel fbga programmable accelerator card, uh also known as the smart nic, plays a key role in accelerating virtualized network functions that in turn, increases the overall compute and density. The use of apga brings the benefits of programmability, reduce time to market and ease of integration.

C

We use the uh fpga to accelerate the lte and 5g forward error correction operations at layer, one of the protocol communication stack and the, and that that communication is one of the most compute intensive operations that are substantially enhanced when, when hardware acceleration is involved, the fbga smart neck integrates two by 25 gigs of network interface card with uh intel reactant abj in a pcie card form factor.

C

Fpga here is used in the field to accelerate lte and 5g forward air correction. Acceleration.

C

uh These fpga accelerator devices are installed at remote sites. So when an rte fell, rtl firmware update becomes available. We are deploying a process called rsu.

C

Rsu is the shorthand for the remote system update that automates, the fpga flashing using a kubernetes operator, and this process is enabled through a technology known as ope ope is, is as well as short for the open programmable exploration engine openness is delivering kubernetes operators of the fpga smartnik, the device that implement autonomous state machines for managing the israel, v-neck device, the op-e stack and the forward error correction, fpga device.

C

The forward error correction, fpga operator, invokes the fpga device plugin and that deploys a daemon set that is responsible for configuring. The fbga resources and the uh hardware queues then x exposes them as srio virtual functions.

C

This v virtual functions uh map um the forward error, correction, encode and decode the queues so that later on, they are passed through to the varan network functions. uh As shown in this. This drawing uh based on the provided configuration by the user, the flexrand network function, pods, are individually and exclusively associated with the with the vfs and accordingly, a lot allotted access to specific forward error, correction, uh cues um and this this association and the allocation is done uh through uh the as rayov device plugin that is deployed by the operator.

C

So the the whole process of deploying the necessary device, plugins and daemon sets needed by the fpga, the srio v and the q configuration and the remote system program system. Remote system programming are autonomously controlled by the operator that openness is delivering for the for the smart nick.

C

So just uh before, uh leaving this slide, uh I know what I would like to mention about the the two necks there, as shown on the diagram.

C

So these uh could be used for front hull and mid-hall termination, depending on the splitting that's made at the radio signal, processing, stack and um and also based on the geographical positioning of the genodb elements.

C

Okay, so switching gears a little bit and moving on to a different deployment scenario, which is a bit more media-centric. So this one is an essential deployment when developing applications for immersive media and content delivery networks or smart cds. The objective here is to enable onboarding, efficient and scalable media analytics and transcoding workloads at the edge for the purpose of reducing the latencies to the end users and to ease the pressure on the backbone of the network.

C

With this deployment, um a video analytics service mesh is provisioned to the openness edge cluster that enables third-party applications to define and execute open, visual cloud-based uh media analytics and graphic graphics pipelines.

C

These pipelines are optimized for cloud native deployments on a commercial of the of the shelf um x86 platforms.

C

The video analytics service mesh that is currently based on sto and envoy proxy um exposes multiple video analytics serving bundles with built-in ffmpeg and g-streamer media media media frameworks.

C

And if there is a hardware acceleration available such as the intel mobids high density, deep learning card, then they correspond corresponding services are spun up to the mesh and becomes available for proper application control consumption.

C

So as as shown on on this uh diagram, there are four service bundles available on the mesh. One bundle is the video analytics serving with g streamer. Another is with the ffmpeg, and two more are provisioned. If hdd hddl's accelerators are installed in the cluster.

C

With the existence of the service mesh, the video analytics services are scheduled with the invoice proxy site cars that enables the mesh control plane to monitor, load, balance and scale the services according to the platform workload and um and also according to the cpu utilization uh transparently.

C

Even without impacting the third party consumer applications performance or altering their business logic.

C

uh At intel, we've developed the uh the vision processing unit vpu that couples highly parallel programmable compute, with workload specific hardware acceleration in a unique architecture.

C

The vpu technology enables accelerating deep neural network and computer vision based applications on edge serves servers and ai appliances until movidius hddl and the visual cloud accelerator card for analytics are two vision, specific accelerators that we support in openness to inboard, dents and accelerator.

C

Media analytics and transcoding workloads at the telco network edge when a media-centric deployment is needed, openness, the provisions, the kubernetes vpu device plugin and the hddl service demon set on all the nodes where these acceleration devices are installed.

C

The hddl service demon, set load balances and arbitrates multiple open, vino, based applications that are deployed on the edge cluster for efficient vpo resource resource utilization.

C

The visual cloud accelerator card is shaped with an iris pro gpu on board, specifically designed for pipelines that involve not only analytics but also transcoding operations.

C

Okay, so how can you get started in the previous slides? We explored some of the deployment scenarios and their reference applications and network functions.

C

The edge applications are designed to execute a proximity to where the data is being generated. This is for latency or data locality reasons. Example, applications could be video analytics for iot.

C

Content, delivery networks or location location information services: do you have a a brilliant edge application idea? So please join us and contribute your application to the openness ejabs repo that's available on github. If you have a commercial application and you would like to contribute its helm charts. uh So please enroll to the intel network builders builders program and get your application added to the commercial edge applications hub.

C

The the edge repo is welcoming not only applications and services, but also the network functions that that would invigorate the edge of the network and on premises.

C

Deployments so to uh to get in touch with our team. uh Please visit our website www.openness.org for the latest news and useful resources of white papers, trainings and podcasts.

C

Our project space is available in github at github, open hyphen s. You can also join our developers mailing list to initiate discussions, or just uh just raise some questions that you do may have. And finally, you can find the ajap's links at github and and intel network builders at the bottom. There.

C

So thanks, thank you and now I hand it over back to prakash.

B

Thanks summer, just to summarize, uh I know we have a few q, a questions that have come up, we'll, try and answer those, but just to summarize, as you've, seen with openness, what we've really tried to do is address different types of use. Cases you saw use cases around. You know very telco oriented use cases like 5g.

B

uh You know core network base stations uh sd-band, but then also you know, non-telco use cases traditionally, like you know, video analytics and ai, and you know cdn and so on. So uh what we are hoping to do with openness is ensure that you know if you are looking to deploy if the telcos are looking to deploy an edge. Openness should give a good starting point right, because we made sure that openness is optimized for all these use cases for the uh for the specific edge requirements.

B

So it's a very good starting point uh to build product. You know, do you know pathfinding go to market and so on, and also we made sure that this is certified. So it's a certified kubernetes solution as well.

B

Okay, so that's the summary um and libby I'll pass it off to you and I think we're ready for q a if you have anything else to say or we can go to qna directly.

A

Awesome thanks omar and prakash. uh Now we have some time for some questions be sure that you've dropped them into the q, a tab um as opposed to the chat, tab and armor and prakash. If you want to open that up, you can just start from the top and we'll um get to as many as we have time for.

B

Absolutely um there are quite a few and the q a I see quite a few questions and then the chat also a few questions so we'll um we'll try and answer as much as possible, so amor I'll take a few, and if you want to look at the q and a questions, if you want to pick a couple that you want to answer, I'm going to get started so I'll pick the first one, which is a great topic. Could you explain what types of applications benefit from this project?

B

So it came up in my uh summary, uh which was that um the types of applications that we are trying to address really go. You know run the gamut right in in terms of what fronts and different edge locations so clearly we're going to address the 5g use cases right. So it's going to be the 5g. You know virtualized ram, which is the base station, we're going to address a user plane function as the other.

B

You know application we're going to address sd-wan for more of an on-premise, but also we really started to see a lot of you know, non-traditional or non-telco or non-traditional applications like uh video influencing right because we're seeing that a lot video is kind of a killer. App right with some of these iot use cases we're seeing a lot of video inferencing in you know, media analytics uh type type of use cases, so those those type of use cases are or what we are enabling okay.

B

So the next question is: um where does the kubernetes control plane run? Is it at the core data center or is it in the forage itself?

B

uh The answer is, it depends uh you can uh you we have seen uh clusters where you would run the the control plane, uh the kubernetes control plane on the same node, so it is not typical for the control plane to run at a different location, but it is not too far-fetched, especially in an iot type scenario. You might you might see scenarios where the node uh might run in a you know, much more smaller constrained environment, especially if it's like multi-node uh environments and the class, the the control plane might might be.

B

You know farther down in the data center, but we don't see that a whole lot, because that's quite challenging to implement so typically we'll see the we'll see the cluster and the uh the the uh the control plane, as well as the nodes kind of running. You know as as close to each other as possible, okay. So the next question is the okay, the cni's that are being developed as part of openness um will. Will they not have a conflict with regular kubernetes cni deployment using operator framework?

B

um That's a good question, I'll I'll, try and answer that please do chime in so what we are trying to do with openness is ensure we can enable multiple cni's right so we'll have a default cni uh right now. The default cni is a project called cubovm kuboven.

B

uh Primarily because you know obnraven is, um is you know from an sdn perspective? It becomes quite important, but we also support, calico and uh and eventually we'll be supporting celium. We've got a few other cni's that uh that we support as default, because you may have some user space networking functions that require different cni's, so the goal is to ensure they have multiple cni's that are that are supported in this environment. So that's that's kind of a design goal, uh design goal for openness, okay,.

C

um And also for that, for that point also, uh so um we don't. um What we are doing is that we are. We are building on top of uh existing cni's and then we are providing our own en enhancement or pro improvement improvements into the data plane there and this nice. So there is, there is no conflicts as such, so uh when, when building uh operators or even building service meshes, we are building on top of the cni. That is, that was of choice in the deployment when, when openness is being uh uh set up.

B

Ammar, do you want to take any more any other questions.

C

There is an interesting question there about the quality of service, so how is quantitative service supported in the platform? So this is a good question and for that is um so in the case of an lte or 5g deployment. The quality of service has a support there in the and the 3gpp standard, and it's it's being managed and controlled by the network function that is managing this.

C

So in the case of 5g, it's called smf, so system management function and similarly as well, if the deployment there involves is the un, so sd1 controller takes care of ensuring and fulfilling this quality of service uh agreements uh that that were promised for the the types of applications.

C

So uh the short answer for it is the the quality of service is, uh is managed by the network functions that are deployed on the on openness.

C

And there is another one about the fpga, so let me read it out uh regarding fpgas: uh what's the speedup slash, latency improvement um provided by offloading error, corrections codes? um So for that what we are doing um there is uh uh there is a project in dbdk, it's called bbdev uh bisband wireless device, and it's taking. uh This is the one that we are. Actually we are integrating uh in in flix, ran and flex ran, is using this framework to accelerate the um forward error correction through the fpa.

C

That and- um and it is, it- is showing a lot of uh in enhancement and improvement, especially because this operation is, is very compute intensive. So uh and it's quite repetitive, so it's taking a lot of cpu power to to do all this computation.

C

So the uh the fpga there is is a real is easing a lot of this strain on the cpus and is taking care of doing all this.

B

Acceleration there are a couple of questions in the chat window. um I don't know about those first.

C

Ones, yeah another another, similar one, it's about um about vpu, so uh how much density increase is expected if using the movidius gpu? So the same idea as well applies to the mevidius vpu, so we are we're able uh um of running um multiple uh video streams uh and doing all the processing through the vpus and that that, of course, it's a variant depending on the the type of the uh acceleration that you're supporting. So we've we've talked about the hddl and we talked about the pca, um so also um we have support today.

C

The mobilius stick so um this when, when these hardware accelerations uh are are available also we are. We are seeing a lot of uh um of capacity that we are accelerating uh through openness.

C

How how openness components are selected are configured per use case.

C

um We are, we are using um uh ansible uh playbooks to um to do all this uh openness uh uh bring up and installation, and there we have what we call flavors or reference architectures. So there we are providing some. You know, uh pre predefined uh configurations for the typical or the most common use cases.

C

So in the case of a service mesh or a video, a smart city application or a video analytics application, then the key ingredients here that are involved, like would be, maybe the service mesh as an ingredient, the the the the sinai to be used.

C

uh Also, if you would like to uh to use um any type of hardware acceleration, so this type of uh ingredients or components are enabled um turned off or done or turned off in the in these flavors or reference architectures that we're providing and also we provide some guidance in order as well. If you have your own specific use case, and you would like to customize this, these flavors, so you you have the ability to um you, know, pick and choose which components you would like to integrate and deploy in the illustration.

C

There is another question about any plans to support ptp for I or sync sync e, as pods offered.

C

Yeah, I I don't. I don't have straight answer to that. So um if you can send us an email to the developer developers mailing list, we can. We can try to find an answer. So I can ask around and find an answer for it.

C

A

Do you want to take? We have about six minutes left. Do you want to take another question.

C

Yes, there is a new one came up. What is the implementation language?

C

Is there a recommendation on using any particular language or paradigm, so the language that the main language we are using in on openness itself is go, but for the applications uh or the network functions it is really up to the um to the to the application vendor or the network function owner to decide on using their preferred language.

C

So it's uh you can use, go of course, and but any other languages, of course are are okay, so because, like everything will be put in a container and these containers will be deployed through kubernetes, maybe through pods or services or demon sets. So at the end they these are. These applications will be uh packaged or bundled in a container containers, and even you don't you you can you can even like, have your own binaries and put them or ship shipping them inside the containers and deploy them on openness?

C

So it is really up to the um to the vendor or the uh the developer to decide the language they would like to use for the edge applications and.

A

Services: okay, any other questions before we go.

A

All right well, thank you so much amber and prakash for a great presentation and for answering everyone's questions. That's if that's all y'all have we can go ahead and wrap up unless there's any other anything else. You want to add.

B

Nothing more, I think, uh thank you for the opportunity cncf and uh thank you to everybody for attending. uh Please do check out the website openness.org and please do engage. Thank you.

A

Absolutely thanks for joining us today. Everyone, the webinar, recording and slides, will be online later today and we look forward to seeing you at another cncf webinar in the future. Everybody have a great day.

C

Thanks everyone.