Home BLOG

BLOG

SmartNICs Give EPC/5G Services a Turbo Boost of Speed

by Harsha Kalkoti Harsha Kalkoti No Comments

5G has a need for speed, and just down the road are a host of new 5G services that will demand higher network performance, from augmented/virtual reality applications to connected cars. Where will that extra performance come from? There are two paths that mobile operators can take to boost network performance: they can upgrade and/or add more CPU horsepower to their servers—a costly option—or they can free up server CPU capacity using a SmartNIC.

What’s a SmartNIC?

SmartNICs (also called intelligent NICs) are something that everyone is talking about, however, at this point, there is not a complete understanding of its capabilities. As its name implies, SmartNIC is a network interface card (NIC) that has built-in intelligence that allows it to process the data passing through it. SmartNICs are considered smarter than your average NIC.

A standard NIC functions as an Ethernet network interface between a server and the network. NICs process basic TCP/IP information such as the source and destination IP address, port number and the protocol being used (what we refer to in the industry as 5-tuple information).  Because  SmartNICs, have built-in intelligence, they in effect performing those tasks reserved for the server CPU, such TCP checksum, load balancing, accelerating cryptography for IPsec and TLS and other CPU-intensive tasks.

Okay, so maybe that definition of a SmartNIC doesn’t get your motor running. Let’s take a look under the hood for a particular load balancing use case and see how SmartNICs can really speed up EPC/5G services. The Evolved Packet Core (EPC) service—which is a software application—is used to implement special engines that create a virtual mesh of line cards inside of applications. For a given user session, traffic should be handled by a specific line card. If data was received by a different line card, it has to resend to that specified line card where the user session resides. This traffic approach is very expensive, as a large amount of east-west traffic can be generated.

This problem can be solved in multiple ways, depending on the deployed solution:

  • Specialized load balancers can be used, which will be specific to a particular application.
  • Standard Routers with ECMP could be used, but they have to be deployed very intelligently. Also, this approach doesn’t scale.
  • Operators can limit the number of servers acting as line cards by managing the server group using a Load Balancer as a Service (LBaaS) feature. This approach, however, wastes resources.
  • SmartNICs can be used for load balancing. This is the most effective and efficient option.

Typically, we would have assigned a specific number of cores to perform these functions to do a  GTP-U lookup (load balancer) on a standard NIC configuration. Because the SmartNIC is EPC aware, it can do the GTP-U header lookup automatically. But with a SmartNIC, the load balancer effectively goes away. We can shift CPU-intensive tasks such as GTP-U header lookups from the core to the SmartNIC, freeing up our server CPUs to perform other useful tasks. That means all cores can now focus on processing value-added services for EPC/5G applications: deep packet inspection, endpoint detection and response, adaptive bitrate streaming and so on.

It’s also important to note that SmartNICs aren’t just smarter than regular NICs; they’re faster too. Standard NICs support up to 40 Gbps, but SmartNICs typically support speeds of 100 Gbps and 200 Gbps.

SmartNICs Outlook for Mobile Operators

If you imagine that servers are the engines of your network, then using SmartNICs is like having an extra turbo-boost button on your network. And as EPC/5G services are right around the corner, the ability to accelerate network performance is exactly the kind of competitive advantage that mobile operators need.

Think You’ve Got 5G Security Issues Protected? Think Again.

by Ron Parker Ron Parker No Comments

As interest in 5G continues to heat up, you’re likely to hear a lot more about 5G security. You may not, however, be hearing the whole story. Most conversations around 5G security centers on the standards put forward by 3GPP last year. Those standards are a good starting point, don’t get me wrong, but they’re not the last word on 5G security issues by a longshot. Why? Because they completely leave container security out of the conversation.

5G Security and Containers

There are a lot of new network elements to consider in a 5G architecture, but the biggest change in 5G is the fact that almost everything is now running on containerized software. In terms of 5g security threats, containers are prime targets for cybercriminals because they contain sensitive data such as passwords and private keys. Understanding how to protect containers from security threats is just as important as protecting the transport layers and gateways in a 5G network. Building on what 3GPP has proposed, we believe that 5G security protection has four main objectives, only two of which are currently addressed by the 3GPP’s recommendations.

A Four-point Approach to 5G Security

Let’s start with what 3GPP has already proposed for 5g security standards:

1. A trust model with two distinct, onion-layered approaches for roaming and non-roaming networks. In the non-roaming network, this model features an Access Management Function (AMF) and Unified Data Management (UDM) in the core, wrapped by the Authentication Server Function (AUSF). For roaming networks, 3GPP introduces the Security Protection Proxy (SEPP) for secure connectivity between the home and roaming networks, and the Network Exposure Function (NEF) to protect core services from inappropriate enterprise requests.

2. Encryption and authentication via Transport Layer Security (TLS), certificate management and OAuth2.

But what about security for the 5G services themselves? As the network shifts from hardware to software, telco operators need to have software security provisions in place to protect their data and their customers. At Affirmed, we see this as involving two distinct but complementary initiatives:

3. Secure software development. App developers need to ensure they’re writing secure code, validating it securely (i.e., using static code analysis), drawing from secure repositories and building everything on a secure base layer foundation (e.g., Fedora).

4. Secure containers. Containers represent attractive attack vectors for cybercriminals. 5G operators need to protect these containers by securing the orchestration engine (Kubernetes) with proper role-based access controls, guarding containers in use (through runtime container security) and managing access permissions between the containers via automated policy-driven networking and service mesh controls.

The need for container security isn’t unique to telcos, and that’s actually a good thing because they can now leverage existing security tools that have already been developed for other cloud-native applications. Unfortunately, a lot of telco vendors aren’t familiar with open-source tools like Aqua (for container security) and Falco (for orchestration engine security). Instead, these vendors leave software out of the security discussion, and that leaves telco operators with some big security holes to fill.

The Bottom Line on 5G Security

If telco operators expect to dominate the 5G landscape, they’ll need to stand on the shoulders of some pretty big cloud companies, particularly where containerization and security are concerned. 3GPP’s security recommendations are a good introduction to 5G security needs, but software security is half of the 5G story. If your vendor is telling you only about that part of the story, talk to Affirmed.

 

It’s Time to Come Clean About Cloud-Washing

by Sean O’Donoghue Sean O’Donoghue No Comments

They did it again. Another company has taken their old software, cleaned it up a little for deployment in the cloud, and called it cloud-native.

We call it cloud-washing. Like the “green-washing” of old, where companies would make claims of environmentally friendly products and practices when, in fact, little had changed from the past, cloud-washing is simply the rebranding and repackaging of monolithic, sub-optimal, on-premise software to appear innovative. Creative, maybe. Innovative, never.

True cloud-native software is built specifically to leverage the inherent benefits of a cloud architecture: hyper-scale, high resiliency, service velocity, and hybrid cloud flexibility, for example. Unfortunately, some companies have discovered their own shortcut to the cloud: port their old software onto virtual machines, repackage it as “virtualized” software and stuff it into a container. That isn’t cloud-native, it’s cloud deceptive.

At the core of the deception is a desire for innovation. Communications service providers (CSPs) are facing unprecedented challenges as they look to support an ever-expanding digital economy. Services revenues are flat or declining, while data and video traffic are exploding. As a result, the business model for CSPs is currently inverted, as revenue per bit converges with cost per bit, leaving little room for profit.

Hyper cloud providers such as Amazon, Google, and Microsoft, on the other hand, are turning in record profits by delivering innovation at a very low cost using cloud-native models, open-source services, machine learning, and self-service models. To survive and thrive in the new digital economy, service providers will need to follow suit, embracing the same models, processes, and technologies used by the leading hyper cloud providers. It’s a new world for CSPs, which is why it’s critical for them to have truly cloud-native solutions.

What does a real cloud-native solution look like? Basically, there are five main design principles that determine whether an application is truly cloud-native:

1. Multi-Cloud Support

By its very definition, cloud-native software is designed to be hosted in a multi-cloud environment. Software that cannot be deployed in a public, private, and hybrid cloud environment is not cloud-native, period. Simply connecting to a cloud isn’t the same as being built to run in any cloud.

2. Container Packaged

Software packaging and delivery have evolved from single, monolithic software packages to virtual machines and, more recently, containers. Container and orchestration platforms such as Docker and Kubernetes bring clear advantages to a cloud-native architecture by making applications more lightweight, open, portable, and easier to deploy, orchestrate, operate, upgrade, and manage. Some vendors use the right buzzwords (e.g., containers, pods, Docker, Kubernetes) but have the wrong ideas about cloud-native characteristics, and instead, they package their software as a big, complicated blob.

3. Dynamically Managed

Cloud-native software should be elastic. It should be scaled once for the initial load and then automatically scale up or down using cloud-native tools such as Kubernetes or Helm as demands increase or decrease. We call this dynamic management, and it’s a monumental mind shift for CSPs that are accustomed to dimensioning network solutions based on peak traffic scenarios with very limited agility.

4. Microservices Oriented

IT teams have already successfully implemented a microservices-based architecture for front-end channel applications as well as for back-end customer management and order management applications. CSPs can now invoke and re-use these microservices components in different combinations to simplify software upgrades or create new services. If software claims to be microservices oriented but shows little evidence of delivering autonomous, changeable, replaceable services, you’re probably looking at a cloud-washed product.

5. Externalized State

One of the limiting factors in scaling an application is statefulness, particularly its session state. Applications in which the application and session state have not been externalized to a high-availability store will have a hard time functioning in the cloud.

The Last Word about Cloud-Washing

The promise of 5G as a catalyst for nonstop reliability, new service innovation, and increased revenue is well documented. Re-architecting the network around the aforementioned architectural principles is the foundation for the promise of 5G. At Affirmed, we call that a platform for innovation.

The race to digital services is already underway, and competition will come from all sides. CSPs need a web-scale, cloud-native network architecture that can deliver next-gen digital services. These networks will have to deliver ultra-high performance and advanced features such as network slicing, service automation, and real-time analytics to radically accelerate service creation and drive down network costs.

More than ever, service providers will need to roll up their sleeves and fully evaluate each architectural element, principle, and capability of their 5G platform. This means challenging vendors on their cloud credentials, their roadmaps, and their commitment to open-source technology. In short, insist that your vendors come clean about whether or not they’re selling true cloud-native technology or simply cloud-washing their old products. A high-performance, cloud-native architecture using open-source technology can open your 5G future to more agility, flexibility, and opportunity. Don’t settle for anything less.

The Traditional Telecom Vendor Is Dead. Long Live the Continuous Innovation Partner!

by Seshadri Sathyanarayan Seshadri Sathyanarayan No Comments

For years, the traditional telecom vendor has been the leviathan on the landscape, generating billions of dollars in revenue through hardware, software, and network-related services. But those vendors are going the way of the dinosaur—that is, toward extinction. Telecom operators (i.e. Communication Service Providers, or CSPs) are looking for a new kind of partner, one that can help them innovate and evolve to compete in a cloud-based world that they didn’t create and can’t easily control. It’s a frightening world for many CSPs, one teeming with exotically named inhabitants like Kubernetes, Jaeger, Docker, Elastic and Istio. And it’s the reason why the role of telecom vendors, more than ever, is to help CSPs tame this new world.

What has become increasingly apparent in my conversations with customers around 5G and the future is that CSPs aren’t looking for network vendors. They’re looking for Continuous Innovation Partners (CIPs). In other words, they’re seeking partners who can help them effectively leverage cloud-native, microservices-based technology to drive innovation and service creation.  Telecom operators understand that the fast-fail, webscale development mode popularized by Amazon, Google and others is the future, but they also realize that they don’t have the skill sets and expertise to seamlessly shift to a service creation environment based on containers, microservices, NoSQL databases, and other advanced technologies. That’s where CIPs enter the picture.

The CIP effectively splits the DevOps process by focusing on the development side of the equation, allowing CSPs to focus on the more familiar operational side of managing networks and subscribers. In an environment where services are constantly being created and updated, this looks like a Continuous Innovation/Continuous Development (CI/CD) process. In the CI/CD framework, the CIP is responsible for:

  • Synching code between developers (a/k/a “checking in” code) and building it out
  • Testing the individual service/microservice components
  • Performing quality control
  • Deploying new code to a test environment
  • Fetching the latest builds
  • Service integration and regression testing
  • Packaging and archiving

This process typically takes place in an isolated part of the network, away from production, so as not to impact existing network services. In this way, telecom partners can quickly decide whether to shelf the service or move it into their production network and scale it. By accelerating the service creation process, the CIP allows the telecom operator to adopt a fail-fast mode of deployment and more quickly monetize services that look profitable.

Of course, not every telecom equipment vendor is ready to take on the role of a CIP. At Affirmed, we had a significant head start with our cloud-native UnityCloud platform. To create UnityCloud, we analyzed hundreds of different cloud developer tools to find the best few dozen, then packaged and integrated them with our cloud-native, microservices-based architecture. Doing this required a deep understanding of cloud developer tools and concepts, something that lies outside the core competency of most CSPs and even most telecom vendors.

It’s not unusual for CSPs to register apprehension the first time they see UnityCloud up close, because many of the components are unfamiliar to them. But this apprehension soon becomes comprehension as CSPs realize that we’ve already done the heavy lifting for them by selecting and packaging these cloud-native tools together. By working with a continuous innovation partner like Affirmed, CSPs can leverage the cloud for a competitive advantage without retraining themselves or investing millions to update their software development skills.

The road to 5G is a journey, but it’s a journey that telecom vendors must be able to take with their customers. With a continuous innovation partner (CIP), telecom operators (CSPs) can reach their goals sooner and continue on a path of innovation and monetization for years to come.

Affirmed Networks Awarded Leaders Board Partner Twice in a Row as Part of Intel® Network Builders Program

by Amit Tiwari Amit Tiwari No Comments

Good leaders understand the value of teamwork. They know that good ideas can come from individuals, but good solutions come from people. That’s why it means a lot to us to be recognized again for this year’s Intel® Network Builders Winners’ Circle Awards: it validates everything we believe at Affirmed about the importance of leadership.

Intel Network Builders represents a broad ecosystem of solutions vendors, equipment manufacturers, systems integrators, and communications service providers that have come together to build better solutions using Intel’s industry-leading technology. This year, only a few dozen partners were selected for the Intel Network Builders Winners’ Circle, representing an elite corps of Intel partners. Those companies selected for the Winners’ Circle are awarded the status of Partners, Solution Partners, and at the highest level, the Leaders Board.

This year marks Affirmed’s second year in the Leaders’ Board, and it is representative of the collaboration between Affirmed and Intel to bring together the best of both technologies.  Affirmed’s solution runs on Open NFVI environment which uses Intel® Architecture powered by Intel® Xeon® Scalable processors, accelerating time to deployment with deterministic behavior and transforming network technology with value-propositions for Communication Service Providers, including top-of-the-line performance, lower cost per bit, better ROI, and as a future proof platform for 5G services.

This year’s award comes at a critical time in our industry, as telco operators and enterprises prepare for the commercial arrival of 5G services. Together with our partners, we’ve helped advance the adoption of Network Functions Virtualization infrastructure (NFVi), move network services to the edge for greater efficiency, and deploy 5G services to real customers. The opportunities for growth and innovation are just beginning, and we’re determined, along with our partners, to build the next generation of solutions that drive growth and innovation.

Being named a member of the Leaders Board means that, together with Intel, Affirmed Networks is making meaningful contributions to the acceleration of network transformations around the world—contributions like building the world’s fastest 5G cloud-native platform. We’ll continue to work with technology visionaries such as Intel, Red Hat, and VMware to ensure that the advances being made in cloud and virtualized architectures can benefit telco operators too.

This is what leadership looks like. It’s about putting your customers first and leaving your ego at the door. Accolades like the Leaders Board validate that what we’re doing is important, but the real validation comes from knowing that we’re not just giving our customers the best that Affirmed has to offer, but the best that Intel, Dell, HPE, Red Hat, VMware, and other leaders have to offer as well. Together, we can do more than transform networks; we can change the world.