Cloud Native Computing Foundation Magma Day EU 2021, 14 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Magma a Cloud Native Converged Core, Use Cases and Architecture - Amar Padmanabhan, Facebook Conn...

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Magma a Cloud Native Converged Core, Use Cases and Architecture - Amar Padmanabhan, Facebook Connectivity

Magma is an open-source, enhanced packet core solution that connects people to a faster internet using LTE, 5G, Wi-Fi, and beyond. Magma brings learnings from the hyper cloud networks to deliver flexibility and openness for the next generation of service providers including MNOs, ISPs, MSOs, and satellite providers. In this talk, we will cover some of these architectural principles and highlight the main use cases for Magma.

A

Hi everybody, my name is amar padmanabhan, I'm one of the maintainers on the magma project. Today, I'm here to talk about magma, a cloud native converge core, with a specific emphasis on the use cases that we're seeing market traction on and its cloud native architecture.

A

First, a brief introduction to what is magma magma is an open source packet. Core that's licensed under a permissive bsd v3 license is 3gpp generation agnostic in the sense that it can support both 4g and 5g architectures and its access network agnostic, in the sense that it can support wi-fi deployments as well. This can be conceived as something similar to a mobile data offload or a tv type architecture, where a triple a and a pcrf and a pcef uh integration exists within the magma framework.

A

The distributed epc itself has a very small footprint. What this allows us to do is we can run the entire epc all the way at the cell site or in slightly more centralized locations like edge pops or even in public clouds.

A

The entire deployment is managed through a single orchestrator. This gives a single pane of glass that sort of abstracts away the distributed nature of magma. This is what we call as moving the network from a device-centric way of managing things to a network-centric way of managing things.

A

The interfaces that magma implements our standard interfaces, for example, s1 for the 4g infrastructure, n1n2 n3 for 5g infrastructure and standard radius and gre termination for wi-fi infrastructure. This allows the magma core to interoperate with any ram that is based on standards.

A

Most importantly, for this talk at least is that magma is a scale out sort of a packet core, as opposed to a scale up uh packet core, and this is fundamental to what makes it cloud native for brownfield deployments. Magma also exposes rest apis.

A

These rest apis allow integration into existing oss infrastructure, as well as a federation gateway which supports standard diameter interfaces that allows operators to integrate into existing pcrf ocs hss type, traditional core elements, so switching gears a little here are the following: use cases that we've been seeing magma market traction on so primarily uh magma is a really good fit for fixed wireless access. This is where we've been seeing commercial deployment over the last 12 to 18 months. The big advantage with uh with magma and fixed wireless is because of its small form factor.

A

uh You can actually deploy the access gateway at the sales site by doing local, breakout and network policy application at the edge, uh we're sort of making um the lte deployments uh transport network agnostic. So you know gtpc, which is s1c, is very sensitive to jitter and a lot of isp and rural deployments end up using microwave or in or unlicensed spectrum for backhaul or even satellite.

A

In some cases, the local breakout aspect of fixed wireless allows us to terminate all of the s1 signaling and then use ip as the main transport over a unreliable backhoe.

A

The second use case where we are seeing some traction is the wi-fi access use case. This is similar to a mobile data offload model. So what this gives you? uh That is slightly that's better than you know, traditional t-bag type architectures. Is that because magma contains a pcef as well, the wi-fi or mobile data offload traffic does not hit your expensive traditional p gateway, also by using local breakout operators, have the ability to transit of the existing infrastructure as early as possible.

A

The use case that we're seeing more traction recently is the private lte use case. This is mostly driven by the cbrs sort of deployments that are happening in the u.s. I have a specific slide around private lt, so I'll skip the deep dive for now. The two use cases that we're looking to prioritize uh in age, two uh for which we're doing a few lab trials as well.

A

As you know, hopefully, a field trial in the july or august time frame are around network expansion and 5g, so network expansion allows operators to use magma as a way to augment their traditional or the high high high value core networks by using magma to extend it into more remote and rural areas.

A

Further, the insulation that magma provides uh to the traditional mmep gateway and s gateway allows the operator to introduce new rams radio elements and iterate on on their evolution, independent of their mainstay core on the 5g essay side, we're looking to leverage magma's, distributed architecture to pilot 5g, fixed wireless use cases.

A

We also support nsa in in alpha form at this point, uh a quick, deep dive into magma the private solution. So the big driver for why magma is a great fit for a private solution is its distributed form factor the local breakout at the edge allows enterprises to deploy their own workloads, and this is ideal for iot, and you know, internet 4.0 type, workloads magma also allows interconnect to existing infrastructure or service provider networks, and this allows these sort of private networks to also double up as neutral host networks.

A

The support for multi-tenancy allows a single service provider or an si to offer service offer uh services to multiple enterprises using the same centralized cloud managed infrastructure.

A

Further. A big advantage of using magma for the private solution is that the upgrade from 4g to 5g is just a software upgrade in fact, going forward. Most magma access gateways will support both the 4g and sa protocols s1, as well as the n interfaces.

A

Lastly, the cloud native scale out micro form factor where you know magma can fit into a box. That's even just 2vcpu.

A

Sort of very lightweight 2vcpu boxes allows magma to be deployed at the extreme edges, and this is particularly useful for you know, iot or like uh fairly remote um sort of use cases where you know there are probably a couple of node b's and you want uh a co-located sort of an epc in that deployment.

A

Just to re-emphasize the point on the form factor, uh this is a sample uh magma fwa bomb from one of our production deployments. As you can see here, uh the uh the uh the magma infrastructure is running on a four core atom box: uh that's running uh a cpu at 2.5 gigahertz and with 4gb uh ram.

A

This box can support up to uh a thousand subscribers as well. As uh you know, 12 e note b's so depending on your need. uh You know such a small form factor can be a great fit for a fixed wireless or a private lte or a 5g use case.

A

Quickly, a high level overview of the road map, so we're almost at release. 1.5 release 1.5 should be available over the next couple of weeks. The key features in 1.5 are inbound roaming, s1 handover and a bunch of stability and usability improvements.

A

1.6, which we're targeting towards and for the end of june, uh is going to add 5g fwa support for sa enough to support lab trials, as well as nsa support, we're looking to extend the 5g sa support in q3 to introduce network slicing as a capability as well as you know, harden the 5g fwa offering so so.

A

For folks who are planning to use uh 5g essay of magma we'd recommend the september release for when you can take it out to field uh it would be lab ready by uh end of june for sure, uh but for all the robustness improvements we are anticipating them to land by the end of september.

A

This is about a six to eight weeks, delay from the road map that we had announced in february as part of the magma developer conference.

A

A couple of things that we've also learned along the way is that the 5g sa ecosystem is also a little bit immature and so having reliable end-to-end testing infrastructure has proven to be a bit of a challenge, and this is sort of slowing down our ability to iterate fast.

A

Cool switching gears again, um so we're going to talk a little bit about magma under the hood and what makes it cloud native so the best definition that I've heard for what makes a workload cloud native or not is the difference between pets and cattle pets are unique, they're hand raised and cared for when they get ill. We nurse them back to health they're all distinct, and this is a clear definition of a workload that is not cloud native. A workload that is cloud native in turn looks a lot more.

A

Like cattle cattle are almost identical to other cattle and when they get ill, you get another one.

A

So the transition that we're trying to affect in the service network a service provider network with a magma converge core is that of a transition from a traditional core to a cloud native core or in other words, the transition from pets to cattle.

A

There are many other definitions of cloud native workloads like you know, stateless. Is it container deployable? All of those are all attributes of a cloud native network. The fundamental thing, though, we'd argue, is the difference between pets and cattle, where, if you have a cloud native network, you're, much more tolerant to failure and almost all your nodes are fairly identical.

A

So with that framing in mind, what are the key attributes that we think are important to create such a cloud native uh sort of core network?

A

So the first principle that we think is important is the need to allow for failure. So a node failing should not have should not impact the overall network. It should be a contained failure. This is pretty similar to what you notice in the data. Centers workloads are fairly distributed, so taking out a router only causes failure on a particular path and the ecmp fabric is comfortable recovering for that for that period of an outage. So it's much more important solving for designing for a system where failure is a given.

A

The second one is given that failures are going to happen. We need to simplify the failure. Semantics failures need to happen in a very well defined way, and these need to map to clean state boundaries. So this makes it easy for us to understand what state actually gets affected by a failure, and the third one is that we need to simplify recovery, so well-defined state and propagation of recovery is important uh to allow for a service to come back up.

A

So this uh goes back to principles like you know, clear demarcation of who owns state and clear propagation principles for the state to be repopulated.

A

So allowing for failure, uh this one is fairly obvious, um so scale-up devices have a large fault domain and they fundamentally need to be treated like pets by distributing the epc or the 5gc. What we're trying to achieve with magma is that the fault domain of each device is pretty small.

A

Further the finer the fault domain, the easier it is for us to upgrade these uh nodes implicitly, this improves agility a great deal. This is one of the key things that we are also learning at facebook in our data center is that by the by pushing network workloads to smaller, distributed form factors, we're able to upgrade them at an incredible incredible velocity and that helps us keep our competitive edge.

A

Before I talk about the state failure domains as well as recovery model, it is worth clarifying the two control planes that are in play in a 3gpp network. The first control plane, as defined by 3gpp, is actually an inband signaling function that allows a user plane channel to be established for a wireless wireless device. This is actually looking at the network from the ue standpoint.

A

But an sdn control plane is the function that makes changes to the data plane to ensure that a desired state is realized based on discovered state, so take, for example, a upf node in a 3gpp sort of control plane view the upf node is purely a user plane element, but from an sdn standpoint the upf is actually has a significant network control plane as well, so magma at the end of the day, implements a hierarchical control plane motivated by sdn principles.

A

Even though the end architecture looks a bit like cups, it is more than cups in the sense that magma implements a control plane at the edge and a control plane at the central location.

A

So to simplify failure- semantics, as I briefly described, we have a two control plane model. There is an edge control plane that encapsulates all edge state. What do we mean by edge state? It is the state associated with the ue that is maintained by the network. This is sort of transient or runtime state that gets generated by the ue signaling and establishing a user plane with the network.

A

There is a central control plane which runs in a public cloud or in a more centralized location that is responsible for maintaining the global state. It is the authoritative owner of this global state. This is cons. This is an always available application and today in magma it is just a pretty standard. Kubernetes application.

A

The advantage of this distinction of the edge control plane and the central control plane is that the edge control plane has a very clearly defined failure, semantics it aggregates the runtime state of the network and and if a edge host machine goes down, you have lost all of the control or the runtime state associated with the ue, as maintained by the network by using standardized distributed systems. Techniques.

A

Like you know, persisting this runtime state to a key value stored like redis, which is what we do in magma and replicating the state to the cloud or or through other uh distributed system um principles to uh to other redis nodes. We have the ability to checkpoint and restore this runtime state. This makes for a cleaner implementation of h.

A

A the role of a central control plane is to communicate with an edge control, plane, understand the discovered state, say a ue came onto a network and then use the desired state as understood by the configuration of the network to push down a realized state model that then gets implemented by the edge control plane through forwarding rules at the upf or the gateway, depending on which generation of 3gpp you're working with.

A

The next principle, um around moving to a more of a cloud native sort of a core network, is to simplify the recovery semantics. So, let's take an example of n4.

A

N4 in in 3gpp uh is defined roughly defined across two planes, the first one, what we call as node level procedures like things like load, reporting and heartbeating, and then the second one is around session level procedures, which is the actual business logic of the um smf and the upf.

A

Our assertion here is by is that to implement a cloud native sort of a a a converged core. We need to remove the node level procedures out of the n4 implementation and delegate it to a service control plane, similar to like kubernetes and model that as kubernetes operators.

A

The advantage of doing this is that say if a node goes down or a node comes back up. Both your 3gpp point point-to-point control interfaces and your kubernetes are not trying to make independent decisions on how state needs to be restored.

A

So what we think we're trying to what we're trying to do with magma is to remove the sort of note to node interface procedures from the standard interfaces like n4, and only focus on the service level procedures uh like the session related procedures, around session establishment, modification and release which go from smf to upf and the session reporting which moves from the upf to smf.

A

So the key takeaway from this principle is to delegate point to point node interfaces to the service control plane where possible. This allows the service control plane to make consistent decisions across all nodes in the network.

A

The second aspect is: how do we propagate this state so taking a step back? The interaction between the smf and the upf is mostly about state synchronization. There is a clear owner for each substate. The upf uh note state is owned by the upf. The session rules are owned by the smf, and the session stats are owned by the upf.

A

The existing uh 3gpp standards are edge interfaces, so they model all of the state synchronization using crud.

A

What we assert is that for better reliability and to simplify recovery semantics, especially given that we know uh state, is uniquely owned by each of these. uh Each of these devices we, we think modeling. All of these all of this state as level interfaces is a much cleaner way of doing this. So what level interfaces are are set based uh interfaces so, at any point in time the upf and the smf interact over uh set interfaces.

A

This is very similar to the transition that has happened from soap to rest. Soap was much more of a crud and stateful model, and rest is now much more of a resource-based model. Where you know we only use, uh puts and gets uh there's a great talk by ullash, that's available on youtube, which talks about the abstractions in magma.

A

That further clarifies this point in in greater detail.

A

So summarizing um magma product focus verticals is currently we are focused around fixed wireless, wi-fi, core and private networks. Magma 5g essay support is in alpha. We hope to be lab ready by the end of june and feel ready by september. Slicing support would be introduced in in the september release of 2021..

A

The magma architecture is cloud native and the reason it is cloud native is it is an implementation that is focused on scaling out versus up similar to the pets versus cattle analogy. Magma adheres to the sdn principles of control plane and thus implements a hierarchical control plane. This is slightly different from a 3gpp cups implementation, which just talks about control and user plane separation.

A

It adds an additional slice in terms of the control plane being edge versus centralized.

A

Thank you. Everybody um here is some additional information uh on how to uh plug into the project. There's a website there's also all of this code is fully open source and all of our development happens in the open, uh github.com magma. There are two talks that give a much more detailed overview of um of the magma principles.

A

uh The first one is by me introduction to a distributed epc and then the second is by ullash on magma abstractions and interfaces, both of which are available in on youtube. Thank you very much.