Cloud Native Computing Foundation Cloud Native Telco Day EU 2022, 19 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: NSM, Network Service Mesh at Scale for Telco... Giang Tran, Ericsson & Lionel Jouin

Description

Lightning Talk: NSM, Network Service Mesh at Scale for Telco Networking - Giang Tran, Ericsson & Lionel Jouin, Ericsson Software Technology

Network Service Mesh (NSM), a CNCF sandbox project, offers a framework for building network services that addresses current networking challenges for Telco Cloud-native Network Functions (CNFs) deployed on Kubernetes. What does this imply? And how can NSM be brought in for advanced use-cases? This speech will present a framework for network services extensions using NSM as foundation for addressing the networking challenges seen around Telco CNFs. Such CNFs inherently have high demands on networking capabilities such as VPN e2e network separation & isolation, connectivity through acceleration hardware, L3 forwarding and LB of Telco protocols as a Service (aaS). In addition, Telco CNFs require scalability and high availability. The design is realized by the open-source Meridio project published on GitHub. Issues related to NSM found during the implementation; and how they have been addressed by the community will be put forward.

A

B

Hi everyone. I hope you have had a good break. So um it's great to see many of you here physically here today. After the past few years, my name is yang jun, I'm working as a block owner at ericsson.

A

And I'm leonardo, I'm working as a software engineer at ericsson, software technology.

B

So today we're going to talk about network service mesh at scale for telco networking.

B

So, first of all, let's talk about challenges for telco cloud native application network functions, so telco cloud native network functions or cnf in short, require networking, scalability and high availability. In addition to that, cnf also have special demands on networking capabilities such as end-to-end self-traffic, separation and isolation.

B

Also, it is well known that a network address translation is problematic for some of the telco protocols such as sip or sctp. Hence, there is also requirement to support for traffic without net for l3 folding, with load balancing as a service.

B

Another important requirement is to allow for a cluster-wide vip address a source address for outgoing traffic originating from application parts last but not least, to allow for high performance, accelerated user plan traffic handling.

B

So those typical telco requirements are not easy, cannot easily be sold within the constraint of kubernetes primary networking. Hence, like secondary networking, solutions have been developed for to get around some of the limitations of the kubernetes primary networking. However, the problem is that there is no standardized way for cluster-wide connectivity management and those solutions, like known solution, tend to be highly application specific.

B

They are not technically interchangeable non-reusable and not intend to facilitate cross-platform portability.

B

So when there is a problem with energy engineers will look for a solution and, as an answer to the problem that I have just described, network server mesh offer a framework that allowed additional plug-in network services that can handle challenging requirements for telco cnf deployed on kubernetes.

B

So what is network mesh and why network mesh network mesh is a cncf sandbox project and the community very has been very active, extremely accommodating to user needs and very responsive network mesh solves complicated, l2 l3 use cases in kubernetes that are tricky to address within the existing kubernetes network model, inspired by istio network mesh maps, the concept of a solid mesh into l2, l3 payloads.

B

One of the important aspect is that network mesh does not require any changes to the existing kubernetes network and can run alongside any cni such as calico or motors. It supports for additional cluster-wide coordinated connectivity for cnet workloads.

B

Network mesh provides a framework that allows to plug in additional network services that can handle telco requirements and, on top of the framework provided by negotiate mesh, we have been developing a project called radio, so meridio addresses the typical telco requirements, such as no net or vpn separation.

B

The architecture of mario is designed for a variety of network services such as stainless or stateful load, balancing external traffic attraction and firewall.

B

It is also an open source project published on github, so lionel will describe more in detail the design of meridio, as well as the issues related to nsm, that we found during the design and implementation of meridio and as well as like how they have been addressed by the community.

A

Thank you so, first, what is meredith so meridio has the objective to facilitate the attraction and the distribution of external traffic within kubernetes via secondary networks. To achieve this, multiple searches are provided to the users to control the different concepts radio offers the users can modify traffic attraction with configurable external networks, for instance, vlan or host network interface.

A

They can deploy new network services and configure them with traffic classification, which will separate the traffic into multiple different logical groups. Applications can subscribe to in radio everything will be adapted during runtime, so all networks and all virtual wire will be added or removed. Based on how the user is configuring. The system, the last configurable part, is on the application port.

A

A sidecar container is running to provide a jpc apa applications can use to connect or disconnect the network services and, in the same way, based on this request, the networks will be adapted and the virtual wire will be attached or detached from the application code to start or stop receiving traffic to better support. The mergio design extension hand have been proposed and absented by the nsm community has a default use case, or example in nsm.

A

A simple point-to-point connection have been proposed between one single network service, client and one single network service endpoint, but this is not sufficient from a radio. We're then using multiple folders that are providing multiple different capabilities and the first one is for the front end service.

A

A forwarder is required to connect the network services to the external gateways vf, for instance, vlans, and using this specific folder. The network service endpoint will only exist to provide a control instance and will not terminate any virtual wire or provide any traffic.

A

The second one is the point multipoint, the point of multi-point is required to avoid exposing the full mesh connection and also to provide a single network interface per network service to the user pods.

A

The traffic is attracted from external gateways by several instances of of the oven, the same network service.

A

The traffic can then traverse through any of the network service before it reached the user board and therefore the user board has to be connected all to all available network service instance. Forming a full mesh has a default. uh Sorry has a temporary solution. We are using a proxy.

A

The full mesh connection is created between the proxies and the network service instances and a point-to-point connection are creating between the proxies and the user ports, but the long-term solution for us is to use the point-to-multi-point forwarder, since the bases are within place in nsm, and the next step will be to develop it in collaboration with the nsm community.

A

Finally, the last main design extension is about the policy routing.

A

The default routes in a kubernetes pod are pointing toward the primary primary network interface, also user ports. Your supports might want to connect to multiple network services at the same time that are handling the same vip address, but with a different protocol. The outgoing traffic then has to be rooted thanks to the nsm policies.

A

um The policy routes are added based on the network savvy on the network service configuration so as part of the request to nsm the um the sidecar container will specify the routing policies, and if the network service is updated, then the sidecar will update the connection via new request to nsm and nsm will update the connection and policy route inside the pod, with no traffic interruption.

B

So, with nsm being used for cluster-wide connectivity in conjunction with kubernetes, we have practically observed that the limiting aspect of kuwaiti's network can be effectively overcome from us who are working in meridio. We are very open to discussion on best practices, as well as collaboration on the way forward for more information about my radio as well as network mesh. You can find the projects on github on the slides. You can find the link to meridia project where you can find more information about meridio, as well as to reach out to us.

B

A