Has virtualization become obsolete in 5G?

Hi folks,

Over the past few weeks, I’ve attended webinars and watched videos organized by Intel.
These activities have centred on 5G and examined applications (like “visual cloud” and “gaming”),
as well as segment-oriented aspects (like edge networks, 5G RAN and 5G Core).

I am stunned (no hyperbole) by the emphasis on Kubernetes in particular,
and cloud-native computing in general.
Equally stunning (for me), public telecommunications networks have been portrayed
as having a history that moved from integrated software and hardware,
to virtualization and now to cloud-native computing.
See, for example Alex Quach, here @10:30). I reason that Intel’s implication is that virtualization is becoming obsolete.

Would anyone care to let me know his thoughts on this prediction?

Cheers all,

Etienne

In the early dawn of SDN, where it was cool to have the RP’s in Beirut and the line cards in Lagos, the industry quickly realized that was not entirely feasible. If you are looking at over-the-top services, so-called cloud-native computing makes sense in order to deliver that value accordingly, and with agility. But as it pertains to actual network transport, I’m not yet sure the industry is at the stage where we are confident enough to decompose packet forwarding through a cloud. Network operators are more likely to keep using kit that integrates forwarding hardware as well as a NOS, as no amount of cloud architecting is going to rival a 100Gbps purpose-built port, for example. Suffice it to say, there was a time when folk were considering running their critical infrastructure (such as your route reflectors) in AWS or similar. I’m not quite sure public clouds are at that level of confidence yet. So if some kind of cloud-native infrastructure is to be considered for critical infrastructure, I highly suspect it will be in-house. On the other hand, for any new budding entrepreneurs that want to get into the mobile game with as little cost as possible, there is a huge opportunity to do so by building all that infrastructure in an on-prem cloud-native architecture, and offer packet forwarding using general-purpose hardware provided they don’t exceed their expectations. This way, they wouldn’t have to deal with the high costs traditional vendors (Ericsson, Nokia, Huawei, Siemens, ZTE, e.t.c.) impose. Granted, it would be small scale, but maybe that is the business model. And in an industry where capex is fast out-pacing revenue, it would be the mobile network equivalent of low-cost carrier airlines. I very well could be talking out the side of my neck, but my prediction is mobile operators will be optimistic but cautious. I reckon a healthy mix between cloud-native and tried & tested practices. Mark.

The surprise for me regards Intel’s (and the entire Cloud Native Computing Foundation’s?) readiness to move past network functions run on VMs
and towards network functions run as microservices in containers.

See, for example, Azhar Sayeed’s (Red Hat) contribution here @15:33.

Cheers,

Etienne

The surprise for me regards Intel’s (and the entire Cloud Native Computing Foundation’s?) readiness to move past network functions run on VMs
and towards network functions run as microservices in containers.

See, for example, Azhar Sayeed’s (Red Hat) contribution here @15:33.

Be careful not to confuse vendors pumping stuff with whats actually deployed.

Also, AT&T has been doing virtualization for nearly 10 years now, so perhaps you were just not paying attention

https://www.fiercetelecom.com/telecom/at-t-target-for-virtualizing-75-its-network-by-2020

Not sure it has helped ATT in any meaningful way, their stock price is the same it was in 2015.

Be careful not to confuse vendors pumping stuff with whats actually deployed.

Well yes, there’s always the hype factor to discount. The reason why I’m asking this forum is to separate hype from hope.

Also, AT&T has been doing virtualization for nearly 10 years now, so perhaps you were just not paying attention

But the point is just that: how serious is this progression towards cloud-native, if so much effort was put in to virtualization?

Incidentally, AT&T’s Brian Bearden was present here: just listen to how he defended Intel’s containerization drive @24:56.

Words of wisdom. Mark.

I suspect that if a significant amount of investment has already gone
into classic NFV, and for the most part, it's working reasonably well,
an operation would need to be seriously bored or have tons of cash and
time around to uproot all of that work and change things around without
some compelling technical or commercial reason to do so.

Despite the NFV world being well bedded in, it's still an evolving piece
of tech., and this is one field where operators are prone to spending
multiple times on the same thing, as they realize the previous decision
fell out of favour with the community or their favorite vendor.

I've seen it happen right here in South Africa, when a company built an
"SDN" platform 7 different times in 3 years as the industry kept
oscillating; going through whatever "SDN" platform vendors pushed, what
the open community was putting out, OpenStack, e.t.c.

They eventually closed down that side of the business, this year.

So for greenfield sites, maybe. But for existing installations that have
been around a while, I guess the transition to "cloud-native" might be a
bit of an ask, given the industry's history on this.

Mark.

I reason that Intel’s implication is that virtualization is becoming obsolete.
Would anyone care to let me know his thoughts on this prediction?

Virtualization is not becoming obsolete … quite reverse in fact in all types of deployments I can see around.

The point is that VM provides hardware virtualization while kubernetes with containers virtualize OS apps and services are running on in isolation.

Clearly to virtualize operating systems as long as your level of virtualization mainly in terms of security and resource consumption isolation & reservation is satisfactory is a much better and lighter option.

Thx,
R.

Clearly to virtualize operating systems as long as your level of virtualization mainly in terms of security and resource consumption isolation & reservation is satisfactory is a much better and lighter option.

That pretty much sums up Intel’s view.

To quote an Intel executive I was corresponding with:

“The purpose of the paper was to showcase how Communication Service Providers can move to a more nimble and future proof microservices based network architecture with cloud native functions, via container deployment methodologies versus virtual machines. The paper cites many benefits of moving to a microservices architecture beyond whether it is done in a VM environment or cloud native. We believe the 5G networks of the future will benefit greatly by implementing such an approach to deploying new services.”

The paper referred to is this one.

Cheers,

Etienne

An operating system is just a high-level machine. That the M-plane in VM is implemented in software isn’t relevant, as pretty much all hardware CPUs are implemented in software as well, so VM is just virtualizing software already.

Containerization is VM, but using the OS as the M-plane As long as the OS delivers all the functions needed by applications, it’s a perfectly reasonable, and even preferable, plane to virtualize.

-mel

I see cloud-native as NFV++. It requires some adjustment to how classic NFV has been deployed, and that comes down to whether operators (especially those who err on the side of network operations rather than services) see value in upgrading their stack to cloud-native. If you’re a Netflix or an Uber, sure, a cloud-native architecture is probably the only way you can scale. But if you are simple network operators who focus more on pushing packets than over-the-top services, particularly if you already have some NFV, making the move to cloud-native/NFV++ is a whole consideration. Mark.

Containerization and k8s aren't so much a shift away from virtualization
(horizontally), but a shift up from virtualization (vertically). It is a broader
theme than 5G - initially gaining traction with SaaS companies, and recently
appearing in NFV scenarios.

Under the hood, k8s relies on an operating system which in turn typically runs
inside a VM on a physical compute resource. Virtualization, thus, isn't obsolete
- but its implementation specifics lose importance.

The operator describes her desired configuration state once in the form of k8s
objects, and is ready to deploy a service to any k8s platform instance. This can
be an A-list k8s-as-a-service provider such as Amazon EKS, Google GKE, or Azure
AKS. It can also be an in-house VMWare Tanzu or Mirantis Cloud Platform
deployment that runs on the operator's own bare metal in their own data center.

This additional abstraction, however, is only magical when someone else gets
paid to deal with the detail. For an operator's in-house IT team, introducing
k8s can be a net increase in complexity. Now, not only do they have to deal with
all traditional IT challenges up to and including virtualization (life-cycle of
hardware, physical network, storage, virtualization, operating system,
licensing, backups, ...) - but also must map the k8s platform instance to these
underlying elements and ensure the correct functioning of the k8s platform itself.

Solutions are emerging (e.g. Amazon AWS Outposts, which allow an operator to
bring a micro Amazon region in-house), but we'll likely continue to see NFV
vendors supporting both VM-targetted and k8s-targetted deployment scenarios for
some time.

The short answer is that the “Cloud Native Computing” folks need to talk to the Intel Embedded Systems Application engineers to discover that micro services have been running on Intel hardware in (non-standard) containers for years. We call it real time computing, process control,… Current multi Terabit Ethernet interfaces require specialized hardware and interfaces that will connect fiber optics to clouds but cannot be run on clouds.

Some comments on Software Controlled Telecomm (/datacom) networking. When DTMF was invented the telco used in band signaling for call control. Kevin Mitnick et. al. designed red and black boxes to control the telco systems so the telcos moved call control out of band. They created SIgnal Control Points which managed the actual circuit switch hardware to route calls or eventually 64kbps digital paths and this protocol was SS#7. There were six to seven volumes of CLASS services that were enabled by SS#7 which ran on UNIX systems developed by Bell Labs. In the mid seventies, I worked on VM systems from DEC and Apollo of which Apollo had the better virtualization that worked across the network and was the first “cloud” system that I worked on.

In the mid nineties, I had worked on large Gigabit/Terabit routers but again the control plane was part of the data plane until ATM based networks could use out of band control to setup a SVC between input port and output port and switch the IP packets instead of routing them achieving network end to end delays of less than milliseconds. VLAN and MPLS protocols were developed to switch packets in the backbone of the networks and not to route them.

In 2000 we put our first pre-standard cloud together with multi Gigabit routers and Sun workstations at 45 PoPs in the US, 3 in Asia and 6 in Europe and implemented a “cloud” O/S. Our fastest links were 10 Gbps. Now we can have 2-50 Tbps per fiber using Superchannel DWDM technology between PoP, data centers or cell towers. Network control functions can dynamically change by using Dynamic Reprogrammable EPROMs from companies like Xilinx and Intel to repurpose firmware control and device functions.

Embedded systems have implemented “micro services” for years as that is how you handle interrupt driven real time control. We call this a context switch which is still hardware CPU dependent. As far as I know, current standard containers do not handle real time CPU interrupts or do they allow very tight timing reponse loops within the standard containers?

Certain 5G proposals are discussing network slicing et al to virtualize control functions that can work better without virtualization. Current 5G protocol submissions that I have reviewed are way too complex to work out in the real world on real networks, maintained by union labor. (This is not a dig at union labor, as they are some of the best trained techs.) :slight_smile:

Buzzwords have a limited life before the vendors need to make up something else to invoice you for.

In 2000 we put our first pre-standard cloud together with multi
Gigabit routers and Sun workstations at 45 PoPs in the US, 3 in Asia
and 6 in Europe and implemented a "cloud" O/S. Our fastest links were
10 Gbps. Now we can have 2-50 Tbps per fiber using Superchannel DWDM
technology between PoP, data centers or cell towers. Network control
functions can dynamically change by using Dynamic Reprogrammable
EPROMs from companies like Xilinx and Intel to repurpose firmware
control and device functions.

I believe that if a system has a single (and often simple) function, as
in the case of DWDM, you can have an off-site control plane to decide
what the network should transport.

The problem with IP networks is that you get multiple services that they
need to carry at various layers of the stack, that it becomes tricky not
to have some kind of localized control plane to ensure the right
intelligence is onboard to advise the data plane about what to do, in a
changing network environment.

While we can do this with a VM on a server, the server's NIC lets us
down when we need to push 100's of Gbps or 10's of Tbps.

Certain 5G proposals are discussing network slicing et al to
virtualize control functions that can work better without
virtualization. Current 5G protocol submissions that I have reviewed
are way too complex to work out in the real world on real networks,
maintained by union labor. (This is not a dig at union labor, as they
are some of the best trained techs.) :slight_smile:

In a world where user traffic is exceedingly moving away from private
networks and on to the the public Internet, I struggle to understand how
5G's "network slicing" is going to deliver what it promises, when the
network is merely seen as a means to get users to what they want. In
most cases, what they want will not be hosted locally within the mobile
network, making discrete SLR's as prescribed by network slicing,
somewhat useless.

With all the bells & whistles 5G is claiming will change the world, I
just don't see how that will work as more services move into
over-the-top public clouds.

Mark.

Wondering whether the industry will consider containerised data-plane in addition to control-plane (like cRDP).

Having just control-plane and then hacking to kernel for doing the data-plane bit is …well not as straight forward as having a dedicated data-plane VM or potentially container.

adam

Not sure what you mean NFV is NFV,

From NFV perspective cRDP is no different than vMX -it’s just a virtualized router function nothing special…

Also with regards to NFV markets, it’s just CPE or telco-cloud (routing on host, FWs, LBs and other domain specific network devices like SBCs), and then RRs, no one sane would be replacing high throughput aggregation points like PEs or core nodes with NFV ,unless one wants to get into some serious horizontal scaling ;).

adam

Intel definitely is pressing for containerized data plane.

Here, @20:49 (registration required), I placed that very question and it took a bit of humming to obtain a straight answer :slight_smile:

Etienne

Intel definitely is pressing for containerized data plane.

Here, @20:49 (registration required), I placed that very question and it took a bit of humming to obtain a straight answer :slight_smile:

I'm shocked, shocked to discover that a company that sells CPUs thinks
that a dataplane should run on a CPU...

W

Well, there has been some discussion in the past 2 years about whether vendors can open up some of their data planes and allow those with enough energy and clue (that means not me, hehe) to have their take on what they can do with the chips in some kind of form factor, even without their OS. Outside of that, merchant silicon is the next step, before we try to hack it on general-purpose CPU’s, as we’ve been doing for some time. Mark.