It’s been a few years since the promising new future technology called SD-WAN came on the scene, so is this related to SDN or a new concept?
SD-WAN stands for Software-defined Networking in a Wide Area Network. It shares key pillar concepts of SDN like separating the control plane from the data plane and the centralized control of the network via the SDN controller. They both allow the enablement of automation and orchestration of network devices. So, what’s the difference then? It’s like a forest from the trees expression as SDN has multiple use cases: Application Delivery Networks, Central Policy Control, Terminal Access Point Aggregation (TAP), Data Center Optimization, Virtual Core and Aggregation, SD-WAN, etc.
SD-WAN is an application (one of the many applications) of SDN technology with a focus on Wide Area Networks, allowing companies to build higher performance WANs using lower-cost internet access technologies.
The Benefits of SD-WAN
SD-WAN was designed with the idea of solving challenges like optimizing network connectivity between conventional branch offices and data centers and MPLS (Multi-Protocol Label Switching), deploying or modifying existing services in a much faster and efficient way, network congestion, packet loss, jitter, latency, etc. The reality is that “old traffic flows” are not designed for the explosion of traffic and bandwidth due to the success of cloud computing and on demand multimedia applications (think of live music, video streaming, etc.). The other major issue is not a technical one but about Operational Cost (OPEX). T1 or MPLS circuits are expensive, the former may have better point to point performance, but it is static, while the latter is highly configurable. SD-WAN technologies are aiming to bring the cost per Mbyte down by at least 60%, according to latest estimates.
Another added benefit of SD-WAN is that will work over a variety of media (for example you can also use a wireless connection), allowing service chaining, policy based centralized control, application intelligence, automation, flexibility and elasticity, etc. The reason why Internet connections weren’t used for enterprise WAN services was that the internet was always a conglomerate of different technologies best effort networks. Simply put: It wasn’t reliable or secure enough for most corporate needs. SD-WAN was designed to change all of that.
Some of you may be thinking, yes, all of that sounds fantastic Javier, but like with other implementations of SDN, you will need to make a huge investment as most solutions consist on both a central controller (often hosted in the cloud) and access nodes on-premises that support the technology, meaning you will have to throw away a lot of old equipment and make a big investment in new premises equipment, right? And how about what you mentioned at the beginning about SD-WAN being mainstream already, aren’t we really years from that?
Yes and no.
Leaders in the SD-WAN Space
Remember the blogs we wrote about the three different kinds of SDN (Open, APIs and Overlays)? While Open SDN would require a higher CAPEX investment but will bring additional innovations and advantages, SDN over overlays and SDN over APIs will be ideal for brown field development and reuse of legacy equipment. To help make SD-WAN a reality for companies, two of the leaders in this area: Cisco and VMware have made some bold moves.
Cisco bought Viptela for $610 Million and it is going to make its SD-WAN technology available not only on all ISR and ASR routers but will also on ENCS 5000 routers that are around 4 years old. That will mean in practical terms, that Cisco will push SD-WAN in over 1,000,000 routers in a question of weeks, the most massive mainstream implementation of this technology. This is great, right? Not if you’re a customer that has spent years trying to uncouple themselves from vendor lock in. One of the key benefits for SDN implementation was to avoid closed systems, utilize inexpensive white boxes instead, avoiding vendor hegemony and lock-in again.
Cisco, like most networking manufacturers, want to keep their hardware hegemony as long as possible, for obvious reasons, and they are not shy about touting the advantages of one end-to-end Cisco SD-WAN solution.
The other leader in this space, VMware, also recently purchased (November 2017) a leader in SD-WAN technology: VeloCloud, for an estimated $449 million (according to Futuriom). Although VeloCloud offers multiple x86 appliances options with the software preloaded, it was designed to run on any x86 multi core hardware and offer some additional features like active network performance measurement (BFD), Forward error control and comes on several flavors (Premises or Cloud for Viptela and Internet, Hybrid SD-WAN or Premises for VeloCloud). Both Viptela and VeloCloud work as an overlay, support zero touch provisioning, have North bound REST and support Policy provisioning via the controller.
Although VMWare has a full SDN-NFV ecosystem with its NFV3.0 (including VIM, SDN Controller NSX, vRO for Orchestration, etc.), it is not trying to force customers into a monolithic approach. In fact, VMware is even allowing a closer integration with Openstack thanks to VIO (VMware Integrated Openstack) and VeloCloud also works with a non-VMware ecosystem as well.
Customers will have to weigh the pros and cons of a closed system versus a vendor independent approach. If Cisco’s bet on the closed system pays off, they will be bringing back the vendor lock-in approach of the 90s, having an all end to-end-Silo from the hardware at the bottom, to the NFVI, VNFs and Orchestration.
SD-WAN is becoming completely mainstream but the old discussion of having open multivendor systems where the customer chooses the best for their needs versus a single vendor silo seem to be making a comeback. In total fairness, every option has pros and cons, one silo of a company could theoretically provide better end-to-end support and seamless integration between different components. On the other hand, open multivendor systems will increase innovation speed, customer freedom and speed of adoption.
Part of the SDN Blog Series
|Update your feed preferences|
In-Band Network Telemetry: Next Frontier in Network Visualization with Analytics and Why Enterprise Customer Care
By: Gautam Chanda, Global Product Line Manager DC Networking Analytics, HPE
Let’s first answer the important question: Why do we need Network Visualization and Analytics?
Data Center networks have become cloud scale and deployment of hyper-converged networks is increasing. Telecom networks will enable faster connectivity everywhere with higher bandwidth delivering 5G wireless services. All of these next-generation networks not only require much higher bandwidth, but they also require real-time telemetry to deliver services with good Quality of Experience (QoE).
A network with detailed real-time visibility enables better reliability and real-time control. Here are key reasons customers need Network Visualization and Analytics now even more than before:
- Ability to Pinpoint Traffic Patterns for Dynamic Applications: Data centers now have increasingly complex network deployments with Network Virtualization & Overlay / Tunnel technologies; SDN/NFV; Silicon Programmability; Multi-tenancy; increased Applications volume; mobility; Hybrid cloud; Bare metal & Virtualized servers (VMs/Containers); Vswitch; NIC virtualization; Orchestration and the list goes on. This gives rise to increasingly complicated traffic patterns in the data center in which network operators would like to have greater visibility into those complex patterns to understand if their DC network infrastructure is performing optimally.
- Security Challenges: More security concerns can arise in complicated IT scenarios, more strict regulatory compliances, and more cybersecurity attacks from both inside and outside data center are threats. Defense against Security Attacks and complex traffic patterns from both inside and outside of the data center are critical.
- Intent-Based Network
- Network Analytics (Visibility, Validation, Optimization & Upgrade, Troubleshooting, Policy Enforcement) is increasingly important for modern DC and Cloud deployments.
Old Network Management Tools such as SNMP is not up to the task in this very high speed networks as we move from 10G to 25G to 100G and beyond in a short order.
The figure below demonstrates very well the need for Network Visualization and Analytics:
This bring us to In-Band Network Telemetry (INT).
Let’s pause for a minute:
- Let’s assume you’re interested in the behaviour of your live user-data traffic.
- What is the best source of information?
- Well… probably the live user-data traffic itself.
- Let’s add meta-data to all interesting live user-data traffic.
This is the essence of In-Band Network Telemetry.
The figure below contrasts traditional ways where in traditional network monitoring, an application polls the host CPU to gather aggregated telemetry every few seconds or minutes, which doesn’t scale well in next generation networks. In-Band Network Telemetry, however, enables packet level telemetry by having key details related to packet processing added to the data plane packets without consuming any host CPU resources:
Figure 2: Traditional vs New Way
In-Band Network Telemetry (INT) is a sophisticated and flexible telemetry feature supported usually within the Network devices in HW. As explained above INT allows for the collection and reporting by the data plane on detailed latency, congestion, and network state information, without requiring intervention or work by the control plane. The INT enabled devices inserts this valuable metadata, which can then be extracted and interpreted later by a collector/Sink/Network Management SW such as HPE IMC, in-band without affecting network performance.
The INT will enable a number of very useful Customer Use Cases such as:
- Network troubleshooting
- When packets enter/exit networks
- Which path was taken by individual flows associated with Specific Applications
- How long packets spend at each hop
- How long packets spend on each link
- Which switches are seeing congestion?
- Microburst detection
- Real-time control or feedback loops:
- Collector might use the INT data plane information to feed back control information to traffic sources, which could in turn use this information to make changes to traffic engineering or packet forwarding. (Explicit congestion notification schemes are an example of these types of feedback loops).
- Network Event Detection:
- If the collected path state indicates a condition that requires immediate attention or resolution (such as severe congestion or violation of certain dataplane invariances), the Collector could generate immediate actions to respond to the network events, forming a feedback control loop either in a centralized or a fully decentralized fashion (a la TCP).
- List Goes On…..
The Figure below shows end to end INT Customer Use Case in a Data Center:
Figure 3: End To End INT
In Figure 3 above shows how In-Band Network Telemetry is used to “Track in Real Time Path and Latency of Packets and Flows Associated with Specific Applications”:
- Collect the physical path and hop latencies hop-by-hop for every packet.
- Can be initiated /Transited / terminated by either a switch or a NIC (Network Interface Card) in a Host such as a Server.
- INT metadata is encapsulated and exported to the collector (e.g. HPE IMC).
- Case 1a: Real-time fault detection and isolation or alert: Congested/oversubscribed links and devices, imbalanced links (LAG, ECMP), loop.
- Case 1b: Interactive analysis & troubleshooting: On-demand path visualization; Traffic matrix generation; Triage incidents of congestion.
- Case 1c: Path Verification of bridging/routing, SLA, and configuration effects.
- Enhanced visibility for all your Network traffic
- Network provided telemetry data gathered and added to live data
- Complement out-of-band OAM tools like SNMP, ping, and traceroute
- Path / Service chain verification
- Record the packet’s trip as meta-data within the packet
- Record path and node (i/f, time, app-data) specific data hop-by-hop and end to end
- Export telemetry data via Netflow/IPFIX/Kafka to Controller/Apps
- In-band Network Telemetry can be implemented without forwarding performance degradation
- Network ASIC vendors have started to add INT as a built in functions within their newest ASICs
HPE FlexFabric Network Analytics solution is leading the way towards this next frontier in Network Visualization and Analytics.
In part IV of this SDN/NFV blog series, I talked about how we arrived to the present situation of SDN, a bit of its history, as well as future plans. In addition, I cited the key implementation of Google’s SDN as an example.
Deployment Example #2
Another company that is making use of SDN is Gap Inc. – yes, it’s not a technology company but the American fashion icon and parent company of Old Navy, Banana Republic and Intermix. They’re using an application of SDN to connect its Internet stores to one another in the corporate network. In the words of the Mr. Patel, Senior Network Architect and CTO of the SD-WAN-SDN project at GAP, “This software approach is about 50% less expensive than the conventional method of connecting stores together in a wide area network. Companies with many stores or branch offices are beginning to look at SDN networking to connect their stores together, but Gap is one of the first to implement this technology at scale and make public its efforts.”
Deployment Example #3
Microsoft Azure is my third example. The Redmond giant is actively implementing SDN for its Azure Public Cloud. In the words of Albert Greenberg, Microsoft lead technologist: “One of the key principles behind Azure’s SDN is its ‘Virtual Layer 2 Architecture,’ a Layer 3 Cross-Fabric that spans the entire data center.” He continues, “Automation is key to managing a massive, high-bandwidth network built with commodity components. The network state service that Azure uses as its control plane abstracts away the individual networks.”
To be able to mix and match the best network element hardware, Microsoft followed a very similar approach to Facebook, using the open source Switch Abstraction Interface (SAI) API to program the ASICs of the switches.
We also have major carriers like AT&T with its Domain 2.0 initiative and Telefonica with Unica. AT&T had a data traffic increase of 100,000% on its wireless network (not a typo) since 2009 to present day. That’s why they needed SDN and NFV implemented across their network because it’s the only technology that allows adding capacity faster with automated deployment and pushes out fast upgrades at the speed of the Internet. AT&T is still planning to have 75% of their network virtualized by 2020.
So What’s the Conclusion?
SDN and NFV are both a bit of hype and disruptive reality. I concur on the view that if SDN and NFV were just bubbles, they would have burst by now. It’s because there’s a real need for both of these technologies that the industry has kept investing in them.
If we think about it, we have been using CLI to configure L2-L3 Network elements for the last 35+ years without many major changes. It is true that we have new protocols, the bandwidth, processing power, and capacity has skyrocketed, as well as the complexity of the networks, but the job of network engineers didn’t change much until we started pushing for SDN/NFV. The paradigm changed – centralized control, separation of planes, abstraction, generic hardware, open source, etc. It is also worth noting that part of the difficulty of its implementation is not just technical, but cultural: In most organizations, networking is typically siloed from the rest of the IT organization. The new approach to networking, SDN and DevOps, requires a different mindset and it takes convincing, training, effort and time.
According to a report from BCC research, the estimation for SDN global revenues will jump to over $56 billion in 2020, plus, in the near future, 100G will be the norm and manual control won’t be enough. We will need to have automation all across the network from the top to the bottom. The agility that SDN and NFV technologies provide will be key soon.
I believe these technologies have spearheaded the biggest leap in networking technology over the last 20 years, it’s just taking a bit longer to completely take over. Once we have the problematic interoperability and standardization figured out, we’ll have massive implementations across the board.
We have many initiatives, like ONAP and OPNFV, just around the corner. ONAP (a project combining AT&T’s ECOMP and Open-O) provides for automatic, policy-driven interaction of these functions and services in a dynamic, real-time cloud environment. It’s not just a run-time platform; it includes graphical design tools for function/service creation, delivering capabilities for the design, creation, orchestration, monitoring, and lifecycle management of VNFs, SDNs and high level services. OPNFV is focusing on the higher layers with quality open source software for the virtualization layer, specifically on the ETSI NFV interfaces VI-Ha, Vn-Nf, Nf-Vi, Vi-Vnfm, and Or-Vi in the diagram above (from ETSI architecture).
As a closing thought, I’d say 2020 will be the date for the massive implementation of SDN/NFV. We’ve come a long way in just 10 years but work needs to be done on the higher layers in particular; on orchestration and consolidation of the platforms we have in place, and improving the interoperability on automation features.
Part of the Blog Series
The post Demystifying Software-Defined Networks: A Decade Later, Where Are We Now (Part II)? appeared first on InFocus Blog | Dell EMC Services.
|Update your feed preferences|
The joke goes around that the true meaning of Software Defined Networking (SDN) is “Still Don’t Know.” SDN is a technology that allows network administrators to no longer be reliant on static architecture of traditional hardware/networks, but freed to centrally and dynamically manage the network via open, programmatic interfaces. This is accomplished by separating the control plane (the system that decides where the network traffic will go) from the data plane (the systems that forward the traffic onto their destination).
Introduction – The Journey
Although we can trace the origins of SDN to the early 2000s, we’ve just reached the decade mark when the creator of the controllers (Ethane) first released Openflow. In 2008, we saw the birth of NOX and the first Openflow Switches. Later on, we saw the entry of Nicira (acquired by VMware in 2012, now part of Dell Technologies), the creation of Google’s B4 project, and the Open Network Foundation (2011) and the development of ONOS.
He Said, She Said
Looking to the present, we see that with SDN, similar to many new emerging technologies of the past, seems to have developed two well-defined perspectives at opposite extremes. On one side, you have people who focus on the negative aspect and believe that SDN hasn’t lived up to the hype over the last decade. On the other side, you have folks who believe SDN will continue to grow and will explode in the 2020s, making bold predictions on market share and expansion rates.
But where is SDN really, now that a decade has gone by?
We all know that SDN is complicated, but is it an acronym for ‘Still Don’t Know?’
I believe we are somewhere in the middle of these two extreme perspectives. It’s true that we still have many experts claiming that NFV is not going to be good enough for high performance applications, that you will always have better performance on dedicated HW/SW. But then again, not everything that is going to be virtualized requires the absolute best performance and the priority is how easy it is to deploy, automate, reuse and its resulting CAPEX/OPEX savings.
On the SDN side, there were plenty of controllers five years ago and all efforts were being centered on Open Daylight (there are many commercial controllers based on this architecture, such as Floodlight, ONOS and NSX). The consolidation is good, but has it lived up to the hype that started in 2012-2013? Has it been massively adopted and implemented everywhere?
In the words of Diego Lopez, chair of ETSI NFV ISG and a senior technology expert at Telefonica, “Perhaps we rushed to commercialize NFV (and SDN) before we laid down the proper foundations and principles for the technology. We can all agree that the initial timeframes given six years ago were too optimistic and will need to be more realistic in the future, and there are still numerous problems left to be solved.”
The main issue customers face with technology adoption is the lack of standardization, especially on the higher layers and interoperability. We’ve come a long way from just having SDN in research centers and academia at top tech universities, to several practical massive implementations in the “real world.”
#1 Deployment Example
The key deployment was spearheaded by Google, which manages one of the largest (if not the largest, with the permission of AWS) enterprise and cloud deployment in the world. It is no secret that Google has been a strong supporter of Open Daylight and Openflow, while continuing to encourage other controllers like ONOS. According to Amin Vahdat “the fundamental design philosophy was that the network should be treated as a large-scale distributed system, leveraging the same control infrastructure we developed.”
The company strategy is based on four pillars:
Espresso improves user experience on two fronts: Firstly, it automatically selects the best data center location to server a specific tenant/user, based on real time statistics and formulas. Secondly, it separates the logic and traffic control from the individual routers, following the tenant of SDN of the separation of planes. A single distributed system with an aggregated vision of the overall network will always perform and make better decisions than an individual hardware router.
There is no clear agreement in the question ‘did SDN live up to the hype a decade later?’ Its adoption has been growing steadily but hasn’t replaced “traditional” networking yet. Once consolidation/ standardization and interoperability within the higher layers is achieved, its adoption may be unstoppable and major implementations like Google’s may become the norm.
Our team of expert Dell EMC Services consultants and advisers, as always, are here to answer your questions and advise a solution that best fits your needs.
The post Demystifying Software-Defined Networks: A Decade Later, Where Are We Now (Part I)? appeared first on InFocus Blog | Dell EMC Services.
|Update your feed preferences|
As discussed in my previous blog, Silos Never Die: A Case Study in NFV Deployment, despite considerable investment and effort, Communications Service Providers (CSPs) have been slow to realize the advantages of Network Functions Virtualization (NFV) and Software Defined Networking (SDN). A recently published white paper, Bridging the IT/Network Operations Gap to Accelerate NFV Deployment and Achieve Operational Excellence, identifies major stumbling blocks keeping operators from fully leveraging the agility, dynamic scaling, and efficiency advantages of network virtualization.
In this third CSP NFV and final deployment case study, we look at the role of C-level leadership in NFV program success and how to gain CXO commitment.
Case Study #3: Skepticism at the Top
The IT and Network Operations groups at a large Tier 1 CSP agreed on one thing: a major competitor was close to capitalizing on NFV/SDN and it would take quick, bold action to keep pace.
At the C-level, however, executives were skeptical. They detected a high degree of hype—and risk—in NFV/SDN. Some even predicted that public failure and big cost overruns would be the outcome of their competitor’s ambitious transformation program.
Cautious Tactical Trials
Fearing that problems with a large-scale NFV/SDN deployment had the potential to knock out half of their services, senior executives took a conservative, tactical approach.
Rather than moving forward with a holistic, enterprise transformation strategy, architecture and operating model, they limited NFV to one-node trials, with each virtualized network function thoroughly unit-, module-, regression-, performance- and scale-tested before proceeding to the next.
Focused on the cost savings to be had from separating network function from underlying hardware, the CXOs failed to recognize the need for a new operational model and skill sets to reap the benefits; and slow to fund hiring, training, and/or external consultants.
The IT and Network department teams, working together on the NFV trials, did what they could to manage. IT shared their experience managing virtualized environments with the network group while Linux teams were encouraged to advance trials of open source solutions and increased participation in industry standards groups.
Playing Catch Up
It was only when faced with the very public success of their competitor—including incremental revenue, agility and cost-savings—that CSP senior management changed their approach, approving an aggressive SD-WAN roll-out, funding a formal training program, and moving forward with an initiative to manage distributed virtualized edge network nodes and functions through a common platform.
However, even today, the CSP remains a year or two behind its competitor and has yet to launch a single, strategic program for enterprise-wide conversion to the NFV/SDN model.
Getting CXOs On-board
In our experience, the most difficult and typically unforeseen obstacles to NFV/SDN are operational and organizational—not technical. In this case, IT and Network Operations were on the same page, but the C-level was not. A fundamental transformation of network architecture and operation is not possible without the informed, sustained support (if not leadership) of senior management.
Building the Business Case
Indeed, even with an enthusiastic C-Suite, the first step in developing the right NFV/SDN transformation strategy is building the business case—including ROI and financial modeling in the context of the CSP’s business and objectives. Initially, high-level, single-VNF analysis can be used to justify more detailed, multiple-scenario modeling and sensitivity analyses to more precisely quantify the benefits to be accrued from NFV/SDN deployment.
Because people and process are integral to the successful deployment and operationalization of NFV/SDN, the business case should include an objective assessment of the current organization/operation—compared to the organizational structure, operating model, processes required for NFVi management.
In addition, C-level executives (and, often, Network Operations teams) may require presentations that show how a well-architected and orchestrated NFV/SDN infrastructure can deliver reliability and resiliency that is equal-or-better-than the existing physical network.
First Step on the Roadmap
As the chart below shows, a solid business case provides the foundation for defining next steps in a phased, multi-dimensional roadmap for planning and executing NFV/SDN across people, process and technology.
As our blog series of CSP Case Studies shows, every situation is different. There is no “right” model for deploying NFV/SDN technology—all decisions and options involve trade-offs.
To delve deeper into successful NFV deployments, download the new Dell EMC white paper Bridging the IT/Network Operations Gap to Accelerate NFV Deployment and Achieve Operational Excellence. Based on research with MST Consulting and Dell EMC experience with than 2,000 successful cloud implementations, the paper describes approaches and methodologies that can help mitigate risk and provide CSPs with a new perspective on the right next step for their company.
The post Skepticism at the Top: A Case Study in NFV Deployment appeared first on InFocus Blog | Dell EMC Services.
|Update your feed preferences|
As discussed in Failure to Migrate: A Case Study in NFV Deployment, despite considerable investment, Communications Service Providers (CSPs) have been slow to realize the advantages of Network Functions Virtualization (NFV) and Software Defined Networking (SDN) are critical to remaining competitive—especially with new over-the-top (OTT) players entering the market.
A recently published white paper, Bridging the IT/Network Operations Gap to Accelerate NFV Deployment and Achieve Operational Excellence, identifies cultural and practical differences between IT and network operations as a major stumbling block keeping operators from fully leveraging the agility, dynamic scaling, and efficiency advantages of network virtualization.
In this, the second in a series of CSP case studies, we look at yet another operator’s experience with NFV deployment and how an architectural approach integrating IT virtualization from the start could have accelerated return investment while keeping future options open.
Case Study #2: From Old Silos to New Silos
This national mobile operator, determined to move forward with NFV, had strong internal core network competencies, but lacked virtualization expertise and experience.
While staff were adept at meeting network service level agreements (SLAs), maintaining network facilities and managing network traffic, they were unfamiliar with:
– Technologies in the virtualization stack
– Designing flow architecture for software-defined networks
– Managing software-defined networks
– Orchestrating workloads across network domains
– DevOps service delivery models
Limited Choice: Niche or Proprietary?
To supplement its in-house expertise, the CSP planned to leverage services and solutions in the “ecosystem” of software-defined network solution and service vendors touted in NFV lab trials, by ETSI, and others.
In practice, however, it discovered its choice of partners was starkly limited to:
Fear of the Unknown
Given network operations reservations about the reliability of software-defined networks, the CSP decided against working with untested smaller companies and opted to partner instead with its existing large network suppliers.
To avoid vendor lock-in, it asked both of its radio access network (RAN) suppliers to virtualize their Evolved Packet Core (vEPC) platform using NFV/SDN. It also directed them to incorporate open system technology into their vEPC solutions to optimize interoperability.
Battle of the New Silos
Unfortunately, what ensued was a battle between vendors and two new silos.
While both suppliers succeeded in delivering vEPC functions that ran on commercial off-the-shelf (COTS) servers, each had virtualized EPC and related applications in a unique way. As a result, each required their own unique orchestrator to manage the virtual network.
Neither vendor could develop an orchestration solution for both platforms.
Recognizing that multiple orchestrators would negate many of the agility and efficiency advantages of NFV, the CSP eventually turned to a third-party provider of a multivendor orchestrator built on open source technology. The CSP also hired and invested in training in its staff to be able to implement and manage the open source virtualization stack.
Bottom line, the CSP is now working to consolidate its vEPC silos into a single platform. The cost savings and automated agility it had expected to gain from its investment in NFV/SDN has not been realized and critical 5G and IoT initiatives have been delayed.
New Ways of Thinking
How might this mobile operator have avoided the complicated and interim step of replacing old hardware platform silos with new virtual platform silos?
The CSP’s initial strategy—to leverage outside expertise to kick start its NFV initiative—was sound, as was its commitment to open source technologies to optimize interoperability.
To turn to two different traditional network partners who were unable or unwilling to provide vendor independent network choices.
Traditional network vendors will naturally want to deploy virtualized applications and infrastructure based on their own products, but if asked by the customer to provide vendor independent aspects to the implementation, many could accommodate this request. CSPs now have the option to pair their traditional network vendors with open, non-proprietary infrastructure. By doing so, they can now take advantage of a virtual infrastructure that will dynamically and automatically adapt to changing workload demands and unpredictable and varying traffic patterns.
In short, by building upon proven and open infrastructure solutions, they can take a holistic view and architectural approach across physical, virtual and application layers.
Based on our experience working with CSPs on some of the largest NFV deployments in the world, including the largest OpenStack Infrastructure as a Service (IaaS) deployment, we recommend an application-driven strategy. Applications, not infrastructure, drive revenue. However, choosing the wrong infrastructure can hamper revenue and increase OpEx.
A composable architecture, with Management and Orchestration layers that mediate between different application requirements, for example, should guide the selection of the right partners to help onboard required VNFs, test and certify the underlying infrastructure, integrate VNFs into OSS/BSS functions, and deploy proof of concept.
By stepping back from the traditional closed and proprietary network viewpoint and implementation to leverage consultative and architectural expertise integrating both legacy network and IT virtualization from the start, this operator could have avoided replacing old silos with new silos—and considerable time and cost delays.
As CSPs work toward envisioning and executing NFV-based capabilities in their networks to help them conduct business in smarter and more agile ways, look for solutions that bring:
|Update your feed preferences|
It’s accepted knowledge across industries that companies that don’t undergo a digital transformation will find it difficult to survive in the coming decade. Legacy technology simply can’t support the performance and virtualization that businesses need to operate efficiently and provide modern products and services to their customers.
But demand for modern infrastructure really begins upstream, with the Communications Service Providers (CoSPs) that own the networks powering business connectivity. The problem is that many large CoSPs are still operating on a wide range of proprietary, legacy technologies themselves. These technologies require a large number of people to maintain and operate them. In addition, these technologies deliver network speeds and responsiveness that are less-than-optimal for the businesses downstream.
To start the transformation process based on this starting point, CoSPs have the seemingly insurmountable task of becoming virtualization experts, sorting through hundreds of vendors and products to architect the ideal infrastructure, and implementing the new technology in an optimal way, all without disrupting existing services.
More realistically, CoSPs need a reliable, knowledgeable partner to help them set a digital transformation strategy, prioritize and select technologies, and undergo digital transformation in a way that sets them up for success.
5 Key Focus Areas
CoSPs’ most pressing need (and opportunity) is to infuse infrastructure with more cloud technology to make it faster, more responsive and more automated. To do so, they need to adopt a significant amount of compute and virtualization technology across nearly every aspect of their infrastructure, starting with the following five areas:
The Partner CoSPs Need
Dell EMC makes digital transformation much easier for CoSPs. Not only are we a worldwide leader in compute and cloud-enabled IT infrastructure, we have the partnership framework in place to strategically and holistically guide CoSPs through the process of modernization across all five key areas.
Our experts give CoSPs the technology and tools to assemble the right combination of infrastructure and service capabilities to serve their business customers and remain competitive for years to come. Dell EMC’s focus on open-standards-based, disaggregated architecture means CoSPs won’t relive the mistakes of the past, trading proprietary solutions and vendor lock-in for a flexible, future-ready, scalable architecture.
The harsh reality is that most CoSPs won’t achieve the levels of virtualization and optimization they need without the right partner on their side. Dell EMC is poised to play a pro-active role in reshaping the future for service providers as they achieve digital transformation and provide the modern technology that will power the coming evolution of business.
|Update your feed preferences|
As discussed in part one of this blog series, Bridging the Operational Gap to Accelerate NFV Deployment, and despite considerable investment, Communications Service Providers (CSPs) have been slow to realize the advantages of Network Functions Virtualization (NFV) and Software Defined Networking (SDN). NFV and SDN are critical drivers to remaining competitive—especially with new over-the-top (OTT) players entering the market.
A recently published white paper, Bridging the IT/Network Operations Gap to Accelerate NFV Deployment and Achieve Operational Excellence, identifies cultural and practical differences between IT and network operations as a major stumbling block keeping operators from fully leveraging the agility, dynamic scaling and efficiency advantages of network virtualization.
In this blog, we take a look at one carrier’s experience and how an agile operational approach can serve to bridge the IT/Network Operations gap and accelerate return on NFV/SDN investment.
NFV Deployment Case Study #1: Failure to Migrate
This European-based Tier 1 multinational CSP, with operations in 20+ countries, set out to be an early adopter of NFV.
The CTO began by creating an overlay organization of IT and network experts to develop an enterprise NFV strategy. The integrated team lab-tested NFV and management and network orchestration (MANO) solutions from multiple suppliers and selected a single IT services partner to help them implement a common environment in regional data centers and deploy their selected NFV infrastructure (NFVi) and MANO solutions across all of its operating companies.
Within the regional data centers (where virtualization concepts were understood) the transition to NFVi went smoothly. Network engineers in the operating companies, however, struggled with separating network functions from the underlying physical hardware—as evidenced by questions such as: “If a function experiences a fault, how do we know which server or storage device to check?”
Faced with network engineering mistrust in the virtual ability to automatically shift capacity to whichever functions need it, the CTO permitted each operating company to opt for either the fully virtualized solution or a “hybrid” model, in which the IMS application platform was virtualized, but physical capacity was dedicated to specific functions.
With each operating company essentially dictating the configuration it wanted, including custom software, the CSP was unable to realize the benefits of automation across the enterprise. Not only did the fragmented solution take more than two years to deploy, project costs were much higher, due to both extensive vendor customization services and dedicated hardware capacity.
Today, with resources continuing to focus on non-critical elements rather than close-to-the-customer applications, the CSP is still pursuing full NFV transformation and currently implementing industry standard operating models with sufficient assurance measures to satisfy the network side.
How Might All of This Have Gone Differently?
In our experience, many of the open standards and “service-centric” lessons learned through maturation of IT virtualization and IT-as-a-Service (ITaaS) enablement over the past decade can be leveraged to help CSPs drive the people, process and technology transformation needed to succeed with NFV/SDN.
For example, the CSP could have avoided bifurcation of its NFV deployment by applying the ETSI NFV framework to architecturally separate each network vendor’s “appliance” into:
Another recommendation would have been to build on the CSPs existing IT-side as-a-service capabilities and the consumer-centric organizational structure, processes and closed feedback loops of today’s mature IT Service Centers to create an agile NFV Service Center as illustrated below.
Additionally, this CSP could have looked to build upon a pre-validated NFV infrastructure platform, such as the Dell EMC NFV Ready Bundles for VMware and/or Red Hat. These bundles are designed to simplify deployments by removing the complexities of NFV frameworks. Ultimately, they will reduce the overall cost of production and accelerate time to revenue.
By combining the strengths of both its Network and IT organizations in a new service-oriented organization, the CSP could drive people and process changes that shift focus from infrastructure to services and applications, as well as to put a structure in place to manage the ongoing modification/build of services and operations to meet business and consumer needs.
To read more about this and other case studies—as well as about Dell EMC NFV consulting services that can help drive the holistic people, process and technology transformation necessary for NFV/SDN success, read the whitepaper, Bridging the IT/Network Operations Gap to Accelerate NFV Deployment and Achieve Operational Excellence.
Next Time: Silos Never Die: A Case Study in NFV Deployment
Today’s Travel Tip
Know how to reach your airline regarding complaints!
With so many travel challenges and service failures these days by travel providers (particularly airlines), I have found it helpful to be quite vocal to their respective customer service organizations via email. In addition, airlines and other travel providers generally monitor twitter and other social media to respond to customer issues.
Some helpful hints in raising issues:
Most major airlines have forms on their website you can complete. In addition, many such as United and Lufthansa provide additional direct email addresses (e.g., email@example.com, firstname.lastname@example.org) which can prove fruitful in getting results. Good luck!
The post Failure to Migrate: A Case Study in NFV Deployment appeared first on InFocus Blog | Dell EMC Services.
|Update your feed preferences|
New case study-based white paper offers valuable insights for CSPs on accelerating NFV deployment and achieving operational excellence.
Welcome to the first of a 4-part blog series on NFV deployments.The blogs will provide additional perspective on our newly released white paper, which brings the operational challenges of NFV deployments to life through three real-world examples – detailing both where they went awry and how applying a new agile methodology would have mitigated it. I encourage you to check it out.
In 2016, AT&T Labs predicted that adopting Network Functions Virtualization (NFV) and Software Defined Networking (SDN) would save the company a whopping 40-50% in OPEX in coming years.
One year into its 3-year journey to virtualize 75% of its network by 2020, the company reports significant cost savings – and that’s not all. Some 1,700 businesses are using new AT&T FlexWare NFV/SDN devices and services to set up multiple Virtual Network Functions (VNFs), such as bandwidth management, virtual routers, firewalls, and other security applications on AT&T’s managed network.
Not Just a Business Opportunity—Business Survival
Like AT&T, mobile and fixed-line Communications Service Providers (CSPs) are investing in NFV/SDN to reduce CAPEX and OPEX and enable new kinds of revenue-producing services. In fact, SNS Research estimates that CSP NFV/SDN investments will rise to nearly $22 Billion by the end of 2020.
But the business case of NFV/SDN goes beyond top- and bottom-line improvements. As the following chart illustrates, CSP business survival depends on quick migration to a new business and cost models capable of delivering new kinds of added-value, on-demand services at web scale. In short, CSPs must emulate cloud service provider models to be able to compete against them and other emerging market entrants.
With NFV/SDN, CSPs can leverage agility, dynamic scaling, and efficiency advantages similar to those that have been realized in IT through infrastructure virtualization and software-defined technologies.
Operators gain the flexibility to efficiently shift network capacity to where it is most needed, in order to deliver the new kinds of services that customers are demanding. It enables CSPs to keep pace with rapidly evolving technologies, by allowing changes to underlying infrastructure without impacting customer experience.
Despite the compelling business case and investments in NFV/SDN to-date, CSPs have been slow to reap expected benefits. Often the trouble is in moving from proof-of-concept and lab evaluations into field trials and commercial deployments.
Research outlined in a new white paper on accelerating NFV deployment finds that a major obstacle to the successful deployment of dynamic, software-controlled network functions has been operational – specifically, legacy domain- and node-based silos of IT and network management that lack the service-oriented processes, skillsets and organizational structures and metrics to successfully deploy and operate NFV/SDN.
Bridging the IT/Network Operations Gap
Having personally, in my past professional life, led both Network Operations responsible for core network functions – and IT Operations responsible for the IT systems that network organizations depend on – I can attest that:
Read All About It
To delve deeper into these issues – and learn about agile approaches to operating model transformation critical to NFV/SDN success – I invite you to download our new Dell EMC white paper Bridging the IT/Network Operations Gap to Accelerate NFV Deployment and Achieve Operational Excellence
Based on research with MST Consulting and Dell EMC experience with than 2,000 successful cloud implementations, the paper describes methodologies that can mitigate CSP challenges and includes NFV case studies that can help CSPs avoid missteps and gain a new perspective on the right next step for their company.
Next time: Failure to Migrate: A Case Study in NFV Deployment
Join Us At Mobile World Congress in Barcelona Feb 26 – March 1
Visit us in Hall 3, Booth 3K10 for a more in-depth discussion of NFV/SDN and other topics important to you. Or contact Larry Rouse (email@example.com) to set up a meeting ahead of time.
Today’s Travel Tip
For those headed to Barcelona, here are my top 4 must-see sights:
The post Bridging the Operational Gap to Accelerate NFV Deployment appeared first on InFocus Blog | Dell EMC Services.
|Update your feed preferences|