Home BLOG Page 15

BLOG

Join Affirmed at OPNFV Summit in Beijing for CNCF Day

by Angela Whiteford Angela Whiteford No Comments

The promise of NFV is to be able to manage core telco applications with the agility and scale of the cloud. But how do we convert a legacy application into a “Cloud Native” application? On June 13 at the Open Platform to Accelerate NFV (OPNFV) conference in Beijing, China, a one-day Cloud Native VNF development workshop will take us on a journey from traditional monolithic VNF to OpenStack cloud native container VNF, with practical advice from experts who have walked this path.

The comprehensive session list covers automation, monitoring, componentizing, telemetry fault management, container orchestration, and much more, led by speakers from Red Hat, Dynatrace, NEC, China Mobile, and others.

Dejan Leskaroski, Sr. Product Manager at Affirmed Networks will cover the “state and storage” topic, including how to “fix” apps that use filesystem storage, considerations for managing database as a service, a comparison of shared filesystems vs. object storage, and issues around handling sessions.

Affirmed Networks delivers the world’s only fully virtualized, cloud native, 5G-ready mobile core solution. The Affirmed Mobile Content Cloud (vEPC) provides a breadth of VNFs with integrated Virtual Probe and Tap providing real time network visibility and reducing probe and monitoring costs by more than 50%.

Don’t miss this fascinating day-long workshop.

Unpacking What’s Next in Network Composability at the Big Communications Event

by Angela Whiteford Angela Whiteford No Comments

The “composable core” is all about creating new services quickly and easily. As a leader in virtualization, Affirmed Networks has been working with operators such as AT&T, Vodafone, Etisalat and more. Affirmed CEO, Hassan Ahmed, shared his insights on the current state of network composability with open-integration mechanisms at the Virtualization Track at the Big Communications Event held in Austin, TX in May.

The ability to dynamically compose microservices independent of the VNF’s original structure opens up a world of possibilities for service providers:

  • They can enhance existing services. For example, a service provider might wish to add network monitoring capabilities to each of its core network elements. Instead of deploying a physical or virtual probe to monitor each gateway or element independently, a service provider could move the probing function into a container and re-create those network elements with the probing function built in to the service.
     Affirmed CEO, Hassan Ahmed, on the Virtualization Track panel at the Big Communications Event

    Affirmed CEO, Hassan Ahmed, on the Virtualization Track panel at the Big Communications Event

  • They can adapt to IoT opportunities. The Internet of Things (IoT) will place unique demands on service provider networks—and present exciting new opportunities for revenue-generating services. A cloud-native architecture has an inherent advantage here because it allows service providers to move functions closer to the network edge (to reduce latency for applications such as healthcare device monitoring), use external storage to reduce costs (versus stateful VM-based storage) and deliver multi-tiered load balancing at exceptional scale.
  • They can create new network elements. The arrival of 5G and IoT will create the need for new network elements such as the Cellular IoT Serving Gateway Node (C-SGN). By assembling the right microservices and functions in a cloud-native architecture, service providers can dynamically create VNFs to serve as the C-SGN or other needed roles in the network.

Creating a cloud-native network is a journey. It is one that can be accomplished faster and with fewer risks when the right architectural foundations are in place. If your network vendor doesn’t have a clear path to cloud-native capabilities in the products they sell today, then you don’t have a clear path to the cloud either.

At Affirmed, the cloud has been an integral part of our vision from the very beginning. The solutions that we sell today, such as our evolved packet core, have been designed to accommodate cloud-native transformations simply and easily. More importantly, these solutions allow service providers to deploy a proven NFV platform today that can address current network needs—more capacity, lower cost, higher performance—while providing a seamless migration path to micro-services and cloud-based delivery models.

Don’t Miss This Red Hat Summit Session on Containers, Microservices and the Cloud-native Telco

by Angela Whiteford Angela Whiteford No Comments

Will you be at the Red Hat Summit in Boston? If so, be sure to attend our session on how Telco and NFV Cloud Service Providers can move from monolithic software architectures to cloud-native microservices.

Affirmed Networks’ James Logan, Director of Cloud Infrastructure Software and Technology will join Red Hat’s Anita Tragler and Marc Curry to shed light on this evolution, ranging from what a Cloud Native architecture consists of, to how CSP networks benefit from moving the virtualized VM based deployments to a mix of VMs, Containers in VMs and Containers on bare metal.

To meet the needs of 4G-LTE/5G, IoT and never-ending appetite of mobile applications, Telco 3GPP standards and Virtual Network Function vendors are driving “cloud native” deployments that are lightweight, scalable, and resilient. Moving NFV clouds to containers requires high performance container networking, multi-tenancy, container security, orchestration and integration.

Gaps in the Container ecosystem will have to be addressed for VNFs, including orchestration limitation, managed multi-tenancy, multi-interface, network security, high performance datapath, performance tuning.The session with Red Hat and Affirmed Networks will cover customer requirements for vEPC, vCPE, 5G NG-Core, vIMS, vGiLAN services, and , potentially, a demonstration of the vEPC on Red Hat OpenStack in Containers.

Please join Jim at the Boston Convention and Exhibition Center on Thursday, May 4, at 4:30 PM in Room 153A for session S103944 – “Are you being served? Containers, microservices and the cloud-native telco.

Talking Points Around Standards, Open Source, and the Implementation of End-to-End Orchestration

by Angela Whiteford Angela Whiteford No Comments

In this final blog post about the TM Forum report on Orchestration, we look at the role of standards and open source in end-to-end orchestration, as well as implementation strategies.

Standards and Open Source: the Rise of Three Camps.

Among standards bodies and open source groups, TM Forum is relied upon by a large majority of service providers for help with orchestration, with ETSI, MEF, and OASIS also cooperating to develop the Hybrid Network Management Platform.1

Almost two-thirds of service providers view open source as either extremely or very important for NFV and SDN deployment. Strong alignment is needed in a digital ecosystem of partners where it is important that everyone understand the requirements in the same way and work together on a common source code.

AT&T, China Mobile and Telefónica have are vying for open source leadership. By contributing ECOMP to open source, AT&T is clearly pushing for its platform to become the de facto industry standard for NFV orchestration. The company is planning to contribute the core orchestration code from ECOMP, not policy or analytics which it considers proprietary. China Mobile, which supports the OPEN-Orchestrator Project (OPEN-O), is unlikely to adopt AT&T’s ECOMP, although AT&T has said that the ECOMP code itself is vendor-neutral and the company will consider other integrators. Telefónica has contributed its virtual infrastructure manager and orchestrator to Open Source MANO (OSM), an ETSI-sponsored group. Ultimately, all the players need to realize that change will come faster if everyone works together and agree on how to federate disparate approaches.

Strategies for Implementing Orchestration

Service providers can move toward becoming platform providers by taking an enlightened strategy toward adopting orchestration. Key elements include:

Understand what end-to-end orchestration means. Orchestration goes beyond network functions virtualization (NFV). It is about automation. The NFV Orchestrator role specified in ETSI’s NFV MANO isn’t enough. To manage hybrid networks and give customers the ability to control their own services end-to-end automation is required, and that includes operational and business support systems (OSS/BSS).

Adopt a platform approach. Platform providers like Airbnb, Amazon, Google, Netflix and Uber have achieved success by providing an interface between customers and sellers. Telecom companies like BT, Orange and Vodafone see orchestration as a strategic step toward becoming platform providers for third parties, building their businesses by curating ecosystems that link end customers or users with producers of goods and/or services. Network operators need a similar model to offer the network platform as a service.

Determine where orchestration has to happen. Orchestration happens everywhere, and systems must communicate with each other and with many other physical and virtual elements to deliver a service request that the customer initiates through the customer portal. This spans the technology layer, which includes physical and virtual functions, the resource layer where functions are modeled as logical resources, the services layer where provisioning, configuration and assurance happen, and the customer layer.

Use common information models, open APIs and intent-based management. A service provider’s master service orchestrator will never have complete visibility into other providers’ networks and operational and business support systems. Service providers will automate service provisioning and management end to end by agreeing to use the same information, data models, and APIs so that orchestrators in different domains can communicate. Intent-based management abstracts the complexity of the network and uses customer intent and policy to manage it. The answer lies less in the orchestrator and more in standardizing the things that are being orchestrated.

Implement closed control loops, policy and analytics. Closing the loop means collecting and analyzing performance data to figure out how the network can be optimized and then applying policy, usually through orchestration, to make the changes in an automated way.

Design in security. Trying to bolt security features on afterwards doesn’t work. Detecting configuration-related vulnerabilities requires an orchestrator that can call on internal or external security functions and apply security policies to users or systems accessing NFV components.

Chart the migration paths. For service providers, success will depend greatly on how well they plan the transition, setting a clear migration strategy both technologically and culturally. This really comes down to learning to think like a software company.

Work toward a common goal in open source groups. Aligning around a single approach would certainly make end-to-end orchestration easier, but short of that ideal, ways must be found to federate the approaches through collaborative work on common information and data models and APIs. Developing the technology and business models needed in the world of 5G and the Internet of Everything can only happen if everyone works together.

This is the final blog in our series on the TM Forum report on Orchestration. The report confirms that orchestrating services end-to-end across virtualized and physical infrastructure is indeed a huge challenge—but not an insurmountable one.

Important Steps & Requirements for E2E Network Orchestration

by Angela Whiteford Angela Whiteford No Comments

In this fourth blog post about the TM Forum report on Orchestration, we look at key steps and architectural requirements service providers must consider as they move toward the Operations Center of the Future (OpCF).

Participants in workshops and Catalyst projects (including CIOs and VPs in networking and operations, network and systems architects, IT managers, OSS/BSS directors, and software developers) have responded to ranked seven orchestration components in order of importance.

1

 

 

 

 

 

 

 

 

 

Here are some takeaways from the report.

Standardized Patterns.

Close to forty percent of participants ranked common information models and APIs as their number one concern, while two-thirds put standardized patterns in their top-three. According to Shahar Steiff, Assistant Vice President, New Technology, PCCW Global, end-to-end service orchestration is a lot like playing with Lego blocks and Meccano parts—it’s easy until you try to combine them. Network operators must partner to deliver the services customers are demanding, but some partners don’t speak the same language. The joint MEF and TM Forum Network-as-a-service Catalyst is developing the common language, definitions, information models and APIs needed to help service providers automatically order, provision, manage and assure virtualized services across partners’ boundaries. Using Catalyst, time-to-service-delivery can be reduced from as long as three months to fewer than ten minutes, with the potential to get that down to milliseconds in future phases. Time-to-market is faster because there is no physical equipment to install. Service providers will have to agree to use the same information and data models along with APIs so that orchestrators in different domains can communicate. This, combined with intent-based management (which abstracts the complexity of the network and uses a customer’s intent and policy to manage it), allows service providers to automate provisioning and management, end to end.

While it is unlikely that the industry will coalesce around a single data model, service providers and suppliers will probably adopt a few and map them to one another. TM Forum’s high-level information model provides standard definitions for information that flows between communications service providers and their business partners, and defines a common vocabulary for implementing business processes. This reduces complexity by providing an off-the-shelf model that can be easily and quickly adopted by all parties.

2

 

 

 

 

 

 

 

API wave of the future. Dynamic APIs are the wave of the future. They can mediate connections between diverse systems, allowing the payload to vary depending on the product or service that’s being ordered, procured or managed. In the case of the Catalyst, the Open Digital API acted as a bridge between an orchestration system and the OSS/BSS, allowing suppliers to invest in a single set of APIs and use them to supply multiple products to many buyers. Conversely, buyers could also use a single API investment to integrate with many suppliers, which allows a true marketplace to form.

Dynamic APIs will likely be certified against core components. As long as any extensible parts follow the pattern as defined by the API, they will be certified. If a set of APIs are extended in the same way by multiple service providers the extension may be integrated into the core.

APIs are so important that nine of the world’s largest operators have officially adopted TM Forum’s suite of Open APIs for digital service management, committing to adopt TM Forum Open APIs as a foundational component of their IT architectures. More service providers are expected to announce their endorsement of them shortly.

Control Loops and Assurance

Close to half of TM Forum respondents ranked autonomic control loops and service assurance high in their requirements for orchestration. By collecting and analyzing performance data, figuring out how the3 network can be optimized and then applying policy in an automated way, service providers can achieve zero-touch provisioning and management. Orchestration allows operators to activate services on any vendor’s device in a standardized way.

Intent-Based Management

Close to half of respondents put intent-based management in their top three architectural requirements for orchestration. Customers access a self-service portal to specify the service they want to use and the desired end state. An abstraction describes what the service is supposed to do and the agreed terms for QoS, then the orchestration system provisions and manages the required service automatically. The goal is to build a Hybrid Network Management Platform that provides for modularity, flexibility and adaptability.

4

 

Orchestrating a way forward.

Service providers must set a clear migration strategy—both technologically and culturally—in order to transition to end-to-end orchestration and a platform approach. Thirty-eight percent of respondents said setting a clear technology path was a top-three consideration for orchestration, while twenty-four percent ranked setting a clear cultural migration path as important. Orchestration may seem to be mainly a technology challenge, but it won’t happen without learning to think like a software company. That means focusing on services more than functions and learning to allow for failure – something that is in complete opposition to the way network operators have done business since their inception.

Still, a majority of service providers agree they need to become much more software-savvy. Setting a clear cultural migration strategy should be a top priority for all.