Javier Guillermo – InFocus Blog | Dell EMC Services https://infocus.dellemc.com DELL EMC Global Services Blog Thu, 18 Apr 2019 17:47:36 +0000 en-US hourly 1 https://wordpress.org/?v=4.9.7 How 5G Relates to SDN and NFV Technologies – Part III: Architecture (Continued) https://infocus.dellemc.com/javier_guillermo/how-5g-relates-to-sdn-and-nfv-technologies-part-iii-architecture-continued/ https://infocus.dellemc.com/javier_guillermo/how-5g-relates-to-sdn-and-nfv-technologies-part-iii-architecture-continued/#respond Thu, 11 Apr 2019 09:00:12 +0000 https://infocus.dellemc.com/?p=37993 In the previous blog, we talked about how SDN and NFV will speed up the roll out of 5G and introduced the concept of network slicing. So, let’s get back to this revolutionary subject and especially the supporting use cases, for what we discussed in Part II would amount to only theory without them. 5G […]

The post How 5G Relates to SDN and NFV Technologies – Part III: Architecture (Continued) appeared first on InFocus Blog | Dell EMC Services.

]]>
In the previous blog, we talked about how SDN and NFV will speed up the roll out of 5G and introduced the concept of network slicing. So, let’s get back to this revolutionary subject and especially the supporting use cases, for what we discussed in Part II would amount to only theory without them.

5G Use Cases

According to most industry experts and stakeholders, all 5G use cases that will be enabled through network slicing and network virtualization, will be based on the three primary use case categories:

  1. Enhanced Mobile Broadband (eMBB): eMBB provides higher bandwidth and higher speeds for everything from streaming in 4K definition to handheld devices and infotainment systems to critical real time platforms, smart cities and to fleet management telematics for safety and diagnostics.
  2. Ultra-Reliable Low-Latency Communication (uRLLC): uRLLC supports real-time, mission-critical communications such as autonomous driving, industrial robotics and emergency disaster response and location services. We are talking response times smaller than 1 millisecond! Think of what kind disasters could occur with self-driving vehicles driving over 60 miles an hour.
  3. Massive Internet of Things (mIoT): InFocus has many great posts that cover IoT in detail so I won’t cover the subject here. When we talk about MIoT, we are talking about the massive implementation of IoT. MIoT serves billions of low-cost, long-range, ultra-energy efficient connected devices across remote locations, as well as cloud applications not requiring frequent or real time communication.

Source: Qorvo ITU-R IMT 2020 Requirements

5G NR: Faster, More Responsive

Another important section we need to cover for the architecture is the 5G New Radio (NR).

Why am I bringing it up?

Because we have been focused solely on the network core components but we can’t have a fully 5G functioning system without the radio part, which also brings plenty of innovations.

New Radio is the global standard for a unified, more capable 5G wireless air interface. It will deliver significantly faster and more responsive mobile broadband experiences and extend mobile technology to connect and redefine a multitude of new industries.

What are the key cornerstones of the New Radio?

  • New radio spectrum: The introduction of 5G will accelerate this trend with many more applications being accommodated by the technology. Whilst improvements in spectrum efficiency will be made, these will not be able to accommodate the huge increases in usage, so more spectrum is needed on new frequencies.

5G Spectrum: Strategies to Maximize All Bands (Source: Ericsson)

  • Unified design across frequencies: With the 5G New Radio utilizing a wide variety of frequencies, possibly 3.4 to 3.6 GHz below 6GHz and then 24.25 to 27.5 GHz, 27.5 to 29.5 GHz, 37 GHz, 39 GHz and 57 to 71 GHz range as possibilities for the mmWave radio. It is important to have a common interface across these frequencies. OFDM is used in Wi-Fi, DSL internet access, 4G wireless communications, and digital television and radio broadcast services.
  • Optimized OFDM: Orthogonal frequency-division multiplexing (OFDM) is a method of digital signal modulation in which a single data stream is split across several separate narrowband channels at different frequencies to reduce interference and crosstalk.

Sample Source OFDM Source 3GPP

  • Beamforming: Beamforming is a technology that has become a reality in recent years and it offers to provide some significant advantages to 5G. Beamforming enables the beam from the base station to be directed towards the mobile. In this way the optimum signal can be transmitted to the mobile and received from it, whilst also cutting interference to other mobiles. The move to higher frequencies allows for much smaller antennas and the possibility of programmable high directivity levels.
  • MIMO: MIMO, multiple input multiple output, has been employed in many wireless systems from Wi-Fi to the current 4G cellular system and it provides some significant improvements.
  • MU-MIMO: The downlink significantly improves the capacity of the gNB antennas. It scales with the minimum of the number of gNB antennas and the sum of the number of user devices multiplied by the number of antennas per UE device. This means that using 5G MU-MIMO the system can achieve capacity gains using gNB antenna arrays and much simpler UE devices.
  • Spectrum sharing techniques: Much of the radio spectrum, although allocated, is not used in an efficient manner. One of the techniques being proposed is for spectrum sharing.
  • Small cell: A small cell network is a group of low power transmitting base stations which uses millimeter waves to enhance the overall network capacity. The 5G small cell network operates by coordinating a group of small cells to share the load and reduce the difficulties of physical obstructions which become more important at millimeter waves.

Summary

I hope this 3-part blog series helped you understand the main architecture concepts and technologies that enable 5G and how they are tied to SDN and NFV. Within a few years, 5G is going to change the lives of pretty much everyone on this earth.

In case you missed Parts I and II of the series, you can find them here:

How 5G Relates to SDN and NFV Technologies – Part I: Introduction and History

How 5G Relates to SDN and NFV Technologies – Part II: Architecture


Are You Going to Dell Technologies World?

Join myself and Mahesh Seshadri on Tuesday, April 30th at 12:00 p.m. in Realizing the Promise of 5G, Are You ‘Foundation-ready for the Future?'” where we’ll discuss the new era of 5G computing which brings together several key industry trends including software-defined everything, Cloud Native, DevOps, Artificial Intelligence, etc. 5G has the promise to completely transform industries with a new wave of services including mobile broadband services, connecting cars, drones, smart retail, industrial robots and much more. Come and learn how to design your infrastructure to build the foundations of your 5G future.

Sources

Nokia

Techtarget

Blog YTD2525

The post How 5G Relates to SDN and NFV Technologies – Part III: Architecture (Continued) appeared first on InFocus Blog | Dell EMC Services.

]]>
https://infocus.dellemc.com/javier_guillermo/how-5g-relates-to-sdn-and-nfv-technologies-part-iii-architecture-continued/feed/ 0
How 5G Relates to SDN and NFV Technologies – Part II: Architecture https://infocus.dellemc.com/javier_guillermo/how-5g-relates-to-sdn-and-nfv-technologies-part-ii-architecture/ https://infocus.dellemc.com/javier_guillermo/how-5g-relates-to-sdn-and-nfv-technologies-part-ii-architecture/#comments Wed, 20 Mar 2019 09:00:15 +0000 https://infocus.dellemc.com/?p=37804 In Part I of this series, How 5G Relates to SDN and NFV Technologies – Introduction and History, I explained why I believe 2019 is going to be the year of 5G, reviewed the history of wireless communications, and depicted how we got from 1G to 5G. In this blog, I’m going to take a […]

The post How 5G Relates to SDN and NFV Technologies – Part II: Architecture appeared first on InFocus Blog | Dell EMC Services.

]]>
In Part I of this series, How 5G Relates to SDN and NFV Technologies – Introduction and History, I explained why I believe 2019 is going to be the year of 5G, reviewed the history of wireless communications, and depicted how we got from 1G to 5G. In this blog, I’m going to take a deeper dive and explain 5G architecture and how it relates to SDN and NFV technologies.

5G and its Future Impact

5G is the new generation of radio systems and network architecture that will deliver extreme broadband, ultra-robust low latency connectivity, and massive networking for human beings and the Internet of Things. In a few years, 5G will not only touch technology and applications, but dramatically change the economy, our society and individual lives.

5G will be far more than just a new radio technology: It will combine existing Radio Access Technologies (RATs) in both currently licensed and unlicensed bands, add novel RATs optimized for specific bands and deployments, and scenarios and use cases (some of these use cases have yet to be imagined). It will also demand a different new network architecture based on Network Function Virtualization (NFV) and Software Defined Networking (SDN) technologies. (I covered these technologies in detail in previous blogs so I won’t extend myself here).

5G and the New Concept of Programmability

Programmability will be central to achieving the super-flexibility that network providers and operators will need to support the new communications demands that will come to them from a wide array of devices, users, and companies across many different industries, as well as from other organizations such as government agencies (think: cities/municipalities, army, etc.). To sufficiently manage all these demands, 5G networks will have to be programmable, flexible, modular, software-driven and managed in a holistic fashion in order to enable a diverse and profitable range of services.

But let’s leave the 30,000-foot view and dive deep down into technical architecture whereby I’ll explain (1) what is behind the definition of 5G architecture (3GPP) and (2) compare the 5G Mobile network architecture to a model well-known by computer and networking engineers worldwide.

The OSI Model

The 3GPP stands for the Third Generation Partnership Project and it consists of many standard documents that cover all aspects of the 5G technology (Radio, Access, Core, Security, etc.). These documents are developed by the 3GPP Technical Specifications Groups (TSGs) and Working Groups (WGs) on the main releases. The latest Releases (15 and 16) are the main targets of the 5G architecture, consisting of 5G core and the New Generation radio network (NG-RAN). After these two, yeah, you guessed it, we’ll have release 17 and beyond (in the works) which will add more features and enhancements. There are also other organizations and consortiums of companies working on developing the standards of the 5G including: IETF, ITU, etc.

Now let’s look at the OSI model:

  • Starting from the bottom, we see that Layers 1 and 2 of the OSI are replaced by the OWA (Open Wireless Architecture Layer).
  • One level up, we have the Network Layer which is divided in two subsections (Upper for the mobile terminal and Lower for each interface). The Network Layer is used to route data from the source IP device to the destination IP device/system.
  • On the higher level, we have the OTP (Open Transport Layer) which combines functionality of both the transport layer and session layer.
  • Finally, we have the Application Layer which marks the data the proper format required and facilitates encryption and decryption. It also selects the best wireless connection for the given service and takes care of providing the Quality of Service (QoS).

Network Slicing

This key new concept in 5G will enable tenants to get different levels of connectivity from their service provider to accommodate use cases. So yes, QoS is built in on the design of 5G.

But why?

To better utilize resources—streaming a video in 4K with HDR will be a reality with the bandwidth of 5G and require minimal latency. If you were to use Voice over IP (VoIP) or send an email, however, you wouldn’t need that much. With slicing, we divide the network into ‘virtual slices’ of the underlaying physical network and each one of them supports specific performance guarantees.

You are probably seeing the link between 5G and the SDN and NFV technologies we have been covering. To achieve this network slicing, 5G will be an all-cloud architecture. The specifications provided by 3GPP dictate that the network will be based on a central cloud that’s connected via a backhaul network to many edge computing clouds that are kilometers away from the user and move many services from the core to the Edge. If services can be executed in the network edge, it will take traffic away from the Cloud RAN.

Source: Ericsson

Summary

5G architecture will boast cloud-native access, transport, and core networks. Network slicing will be enabled through all of them (edge to edge), allowing diversified 5G services and different QoS. As we can see, the virtualization technology of NFV and the centralized control of SDN are embedded in the DNA of a 5G system. Also, whereas 4G-LTE networks tend to integrate both the user and control planes, 5G architecture will separate these planes, improve flexibility, facilitate centralized control, and ensure easy network slicing.

And do you remember what was one of the tenants for SDN architecture from the previous SDN posts?

Yes, that one, Centralized Network Management!

…To be continued soon in Part III.


Are You Going to Dell Technologies World?

Join myself and Mahesh Seshadri on Tuesday, April 30th at 12:00 p.m. in Realizing the Promise of 5G, Are You ‘Foundation-ready for the Future?'” where we’ll discuss the new era of 5G computing which brings together several key industry trends including software-defined everything, Cloud Native, DevOps, Artificial Intelligence, etc. 5G has the promise to completely transform industries with a new wave of services including mobile broadband services, connecting cars, drones, smart retail, industrial robots and much more. Come and learn how to design your infrastructure to build the foundations of your 5G future.

 

Sources

Qorvo
Nokia
Ericsson
Techtarget
Blog YTD2525: 5G Availability Around the World

The post How 5G Relates to SDN and NFV Technologies – Part II: Architecture appeared first on InFocus Blog | Dell EMC Services.

]]>
https://infocus.dellemc.com/javier_guillermo/how-5g-relates-to-sdn-and-nfv-technologies-part-ii-architecture/feed/ 2
How 5G Relates to SDN and NFV Technologies – Part I: Introduction and History https://infocus.dellemc.com/javier_guillermo/how-5g-relates-to-sdn-and-nfv-technologies-part-i-introduction-and-history/ https://infocus.dellemc.com/javier_guillermo/how-5g-relates-to-sdn-and-nfv-technologies-part-i-introduction-and-history/#respond Tue, 05 Feb 2019 10:00:32 +0000 https://infocus.dellemc.com/?p=37419 Will 2019 be the year when 5G takes off? We are just a few weeks away from the Mobile World Congress (MWC), where I have absolutely no doubt that 5G will be everywhere, including at the Dell EMC and VMware booth. But what is 5G exactly? And what does 5G have to do with the […]

The post How 5G Relates to SDN and NFV Technologies – Part I: Introduction and History appeared first on InFocus Blog | Dell EMC Services.

]]>
Will 2019 be the year when 5G takes off?

We are just a few weeks away from the Mobile World Congress (MWC), where I have absolutely no doubt that 5G will be everywhere, including at the Dell EMC and VMware booth. But what is 5G exactly? And what does 5G have to do with the NFV and SDN technologies we covered in previous blog posts?

There is a lot of confusion surrounding 5G. For example, if you use AT&T and, like me, live in Dallas, Houston, Oklahoma, Indianapolis, New Orleans or Charlotte, your phone might display something like this:

So does this mean that 5G is up and running in U.S.? Well, yes and no.

5G Availability

There is a live 5G network in the cities I mentioned but you need to use a 5G hotspot to access it, even if you have the latest iPhone Xs, Samsung Galaxy or latest LG. None of these devices have a modem or antennas that will work on a 5G network.

So is having “5G” on your phone display misleading?

Not altogether.

It is true that they have been upgrading cell towers with TLE-advanced features across the nation over the last year, including things like LTE (Long Term Evolution), advanced features like 256 QAM (Quadrature Amplitude Modulation), 4X4 Multiple-input and Multiple-output (MIMO), 3-way Carrier Aggregation, etc. A more accurate display on our phones, therefore, would read “4G-LTE for Long Term Evolution,” not “5G” (those marketing folks, again! 😃).

To be fair, other companies like T-Mobile did something similar back in the day with 3G-4G, but it misled some customers. Verizon already has 5G working on several test cities (e.g., Sacramento, L.A. and Houston) and like AT&T, the only way to really access it is through a hot spot or with prototype cellphones since we don’t have 5G compatible phones yet.

Why Do I Think this Will Be the Year of 5G?

All major U.S. operators are working against the clock to have 5G coverage in most metropolitan areas by year’s end. In addition, we’ll see the launch of the first commercial cellphones in the 3Q-4Q 2019, which I am sure we will preview at the MWC 19 in Barcelona. We are also reaching a point where both NFV and SDN technologies are reaching maturity and we can even see a consolidation of the number of SDN controllers as well as NFVI components, while the number of available VNFs are exploding.

We will see in part two of this blog series how 5G and NFV go together like peanut butter and jelly, when I’ll explain the concept of network slicing, a network technology that enables network operators to provide networks on an “as-service-basis,” allowing a single physical network to be portioned into multiple virtual networks and multiple types of customer services.

A Brief History of Mobile Cellular Communications

Okay, Javier, all of that is great, but can you get into more details on what exactly 5G is and the differences compared with 4G?

5G is the fifth generation of cellular mobile communications. The first generation (1G) of analog telecommunications standards were first launched in Japan’s NTT in 1979 and later introduced in the 1980s around the world (MNT system). Some of us may remember the Motorola DynaTAC 8000x introduced in 1984 (see below and its comparison of technologies).

The second generation (2G) started in 1991 and exploded worldwide at the end of 1990. Four years later, manufacturers formed the GSM Association. Third generation (3G) was the first mobile focused on data, not just voice and texts, and started at the beginning of 2001. The fourth generation (4G) started in 2007 and became popular worldwide after 2010.

First and Second Phases of 5G

So back to the present and 5G. The first phase of real 5G started in May 2018 with the Release-15 of whitepaper specifications by the ITU (International Telecommunication Union). ITU is made of 193 countries and has more than 800 board members, which gives rise to the reason why it takes a bit of time for them to collectively agree on a standard. The positive? It eliminates the issues we had in the past with GSM/TDMA – the dual competing technologies.

The second phase of 5G and latest global standard is Release-16 due to be completed by April 2020 as a candidate for the IMT-2020 technology. This second standard will increase speed and bandwidth exponentially, compared to the previous generation, demanding speeds of up to 20 Gb/s and frequencies of at least 15 Ghz or higher. The Third Generation Partnership Project (3GPP) is going to submit 5G New Radio (NR) as standard that will include the possibility to use lower frequencies (600 Mhz to 6Ghz versus the 15 Ghz explained before). Lower frequencies can enable telecom companies to reuse existing frequencies licenses without having to buy additional ones, reuse some of the old hardware, and get better coverage. However this 5G NR software on 4G hardware is only between 20-50% faster than traditional 4G. Regardless, if this new software is loaded on new Enhanced Mobile Broadband (eMBB) hardware, the speed bump can go up to 150% on lower frequencies and up to 12-20 times on the higher than 6Ghz frequencies.

A Final Comment on Frequencies

When I explained that lower frequencies increase coverage I was speaking to having better penetration, and by that I mean getting the signal from a tower to your cellphone though a wall, building, etc… It’s rare you’ll have an open and unstructured line of sight with a tower if you live in an urban area, and it’s one of the biggest challenges of 5G. The second biggest challenge is the operator’s need to balance performance and CAPEX costs to achieve profitability and sustainability as the cost per GB of data keeps decreasing.

Now Available: How 5G Relates to SDN and NFV Technologies – Part II: Architecture.


Are You Going to Dell Technologies World?

Join myself and Mahesh Seshadri on Tuesday, April 30th at 12:00 p.m. in Realizing the Promise of 5G, Are You ‘Foundation-ready for the Future?'” where we’ll discuss the new era of 5G computing which brings together several key industry trends including software-defined everything, Cloud Native, DevOps, Artificial Intelligence, etc. 5G has the promise to completely transform industries with a new wave of services including mobile broadband services, connecting cars, drones, smart retail, industrial robots and much more. Come and learn how to design your infrastructure to build the foundations of your 5G future.

 

Sources

nokia.com

visualcapitalists.com

The post How 5G Relates to SDN and NFV Technologies – Part I: Introduction and History appeared first on InFocus Blog | Dell EMC Services.

]]>
https://infocus.dellemc.com/javier_guillermo/how-5g-relates-to-sdn-and-nfv-technologies-part-i-introduction-and-history/feed/ 0
Demystifying Software-defined Networks Part VI: SD-WAN Adoption Accelerates as Platforms Mature https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networks-part-vi-sd-wan-adoption-accelerates-as-platforms-mature/ https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networks-part-vi-sd-wan-adoption-accelerates-as-platforms-mature/#respond Wed, 19 Sep 2018 18:30:12 +0000 https://infocus.dellemc.com/?p=36230 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 […]

The post Demystifying Software-defined Networks Part VI: SD-WAN Adoption Accelerates as Platforms Mature appeared first on InFocus Blog | Dell EMC Services.

]]>
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.

SDN

Figure 1: SDN Use Cases.

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.

Figure 2: Why Cisco SD-Branch is Better than a ‘White Box.’

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.

Figure 3 – Vendor hegemony Trojan Horse? (Source: Martin Kozlowski)

Summary

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

Demystifying Software-defined Networks Part V: A Decade Later, Where Are We Now? (Part II)

Demystifying Software-defined Networks Part IV: A Decade Later, Where Are We Now?

Demystifying Software-defined Networks Part III: SDN via Overlays

Demystifying Software-defined Networks Part II: SDN via APIs

Demystifying Software-defined Networks Part I: Open SDN Approach

Sources

Why Cisco SD-Branch is better than a ‘white box’

www.futuriom

www.sdxcentral.com

 

The post Demystifying Software-defined Networks Part VI: SD-WAN Adoption Accelerates as Platforms Mature appeared first on InFocus Blog | Dell EMC Services.

]]>
https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networks-part-vi-sd-wan-adoption-accelerates-as-platforms-mature/feed/ 0
Demystifying Software-defined Networks: A Decade Later, Where Are We Now (Part II)? https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networks-a-decade-later-where-are-we-now-part-ii/ https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networks-a-decade-later-where-are-we-now-part-ii/#comments Mon, 09 Jul 2018 09:00:22 +0000 https://infocus.dellemc.com/?p=35646 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 […]

The post Demystifying Software-defined Networks: A Decade Later, Where Are We Now (Part II)? appeared first on InFocus Blog | Dell EMC Services.

]]>
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[1]. 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.

SDN Forecasts

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.

Initial focus of OPNFV was in between 2008-2015; present and future focus is 21016-onward.

We have many initiatives, like ONAP and OPNFV, just around the corner. ONAP (a project combining AT&T’s ECOMP and Open-O[2]) 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)[3].

Summary

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

Demystifying Software-Defined Networks Part IV: A Decade Later, Where Are We Now?

Demystifying Software Defined Networks Part III: SDN via Overlays

Demystifying Software-Defined Networks Part II: SDN via APIs

Demystifying Software-Defined Networks Part I: Open SDN Approach

Sources

[1] SDN | sdx central

[2] How ONAP Will Merge Millions of Lines of Code from ECOMP and Open-O

[3] ETSI Standards

 

The post Demystifying Software-defined Networks: A Decade Later, Where Are We Now (Part II)? appeared first on InFocus Blog | Dell EMC Services.

]]>
https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networks-a-decade-later-where-are-we-now-part-ii/feed/ 1
Demystifying Software-defined Networks: A Decade Later, Where Are We Now (Part I)? https://infocus.dellemc.com/javier_guillermo/demystifying-sdn-a-decade-later-where-are-we-now/ https://infocus.dellemc.com/javier_guillermo/demystifying-sdn-a-decade-later-where-are-we-now/#comments Wed, 27 Jun 2018 09:00:15 +0000 https://infocus.dellemc.com/?p=35594 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 […]

The post Demystifying Software-defined Networks: A Decade Later, Where Are We Now (Part I)? appeared first on InFocus Blog | Dell EMC Services.

]]>
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[1].

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?

Not quite.

In the words of Diego Lopez, chair of ETSI NFV ISG[2] 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[3], 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:

  1. Jupiter is a data center interconnect capable of supporting more than 100,000 servers and 1Pb/s of bandwidth.
  2. B4 WAN interconnect is Google’s implementation of SD-WAN[4] which constructs B4 to connect its data centers to one another and replicate data in real-time between individual campuses. “It’s built on white boxes with our software controlling it,” said Vahdat.
  3. Andromeda is a network functions virtualization (NFV) stack that delivers the same capabilities available to its native applications all the way to containers and virtual machines running on the Google Cloud Platform.
  4. Espresso, not the coffee (!), is the fourth and perhaps more challenging piece of the strategy. It extends SDN to the peering edge of Google’s network where it connects to other networks across the planet (Google exchanges data with ISPs at 70 metros and takes up to 25% of all internet traffic). The Espresso technology allows Google to dynamically choose from where to serve individual users based on measurements of how network connections are performing in real time. Espresso allows us to maintain performance and availability in a way that is not possible with existing router-centric Internet protocols, separating the logic and control of traffic management from the confines of individual network boxes. This translates to higher availability and better performance through Google Cloud than is available through the Internet at large.

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.

Summary

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.

Sources

[1] Software Defined Networking: Technology and Global Markets

[2] ETSI Standards

[3] Espresso makes Google cloud faster, more available and cost effective by extending SDN to the public internet

[4] SDxInsights on SD-WAN

Blog Series

Demystifying Software Defined Networking Part III: SDN via Overlays

Demystifying Software-Defined Networks Part II: SDN via APIs

Demystifying Software-Defined Networks Part I: Open SDN Approach

 

The post Demystifying Software-defined Networks: A Decade Later, Where Are We Now (Part I)? appeared first on InFocus Blog | Dell EMC Services.

]]>
https://infocus.dellemc.com/javier_guillermo/demystifying-sdn-a-decade-later-where-are-we-now/feed/ 2
Demystifying Software-defined Networks Part III: SDN via Overlays https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networking-part-iii-sdn-via-overlays/ https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networking-part-iii-sdn-via-overlays/#comments Mon, 26 Mar 2018 09:00:46 +0000 https://infocus.dellemc.com/?p=34457 SDN is no longer ‘the next big thing’ on the networking horizon, but a reality and inevitability for enterprises and service providers. IDC estimates the SDN market has grown from a $406 million industry in 2013 to more than a $6.6 billion market in 2017, and predicts it will continue to grow at a 25.4% […]

The post Demystifying Software-defined Networks Part III: SDN via Overlays appeared first on InFocus Blog | Dell EMC Services.

]]>
SDN is no longer ‘the next big thing’ on the networking horizon, but a reality and inevitability for enterprises and service providers. IDC estimates the SDN market has grown from a $406 million industry in 2013 to more than a $6.6 billion market in 2017, and predicts it will continue to grow at a 25.4% compound annual growth rate to $13.8 billion by 2021[1].

This proliferating nature of SDN deployments is the catalyst for my writing a blog series to ‘demystify’ its architectural approach to making network technology agile and flexible as the virtualized server and storage infrastructure of the modern data center.

In Demystifying Software Defined Networking Part I and Part II, I reviewed:

  • The basics of SDN and how networking is evolving
  • The separation between the control plane and the data plane
  • The three main types of SDN: Open SDN, SDN by APIs and SDN via Overlays
  • The principles of the first approach, Open SDN, as well as the principles of the second approach, SDN by APIs

In this post I’ll describe the principles of the technology by overlays, a method used by software and networking giants like VMware, Cisco and Juniper Networks. I will also discuss the pros and cons of SDN via Overlay deployments.

Figure 1: A typical multi-layer network: the physical layer, the optical layer (fiber cables, optical attenuators, filters, etc.), the SONET/SDH layer (multiplexer, digital cross connects, etc.) and the IP layer (L2-L3 equipment, mainly switches, routers and gateways).

 

So, what’s in an overlay network?

A simple definition is a network built on top of another network, as shown in Figure 1. This concept of overlays is not something new. We have been universally using overlay networks prior to the creation of the Internet.

What makes the overlay networks concept unique, compared to the other two approaches I’ve discussed, is that the current physical network is left untouched with networking devices and their configurations unchanged. On top of that network, SDN hypervisor-based networks are created; an ideal scenario for an enterprise/carrier that doesn’t want to incur major hardware expenses.

Note: a network hypervisor is a piece of software that provides an abstraction layer for network hardware, allowing network engineers to create virtual networks that are completely decoupled and independent from the underlying physical network (see Figures 2 and 3).

Figure 2: Overlay Networks and Physical Network

The beauty of this SDN technology is that the virtual network traffic runs above the physical network infrastructure, hypervisors inject traffic into the overlay network, and receive traffic from it. The network traffic of the overlay networks is passed through physical devices, at the end points, but the endpoints are completely unaware of the details of the physical topology, as well as the routing thought process or any other kind of advanced or basic network functions.

What mechanism makes all of this possible, you ask?

Network encapsulation – the inclusion of one data structure within another structure where the first data structure is hidden for the time being.

Figure 3: Network Encapsulation

Virtual Tunnel Endpoint (VTEP)

When a packet enters the edge of the virtual network at the source, the networking device (usually the hypervisor) will take the packet in its entirety and encapsulate it within another frame. This edge of the virtual network is called a virtual tunnel endpoint or VTEP. The Network hypervisor then takes this encapsulated packet and based on information programmed by the controller, sends it to the destination’s VTEP. This VTEP decapsulates the packet and forwards it to the destination host and then the encapsulated packet is sent across the physical infrastructure. The IP addresses are those of the source and destination VTEP.

This process is also known as MAC in IP tunneling because the entire MAC frame is encapsulated.

Different vendors have developed different technologies to archive this process with different pros and cons, but the underlaying idea is the same. (VMware and Cisco use VXLAN, but Microsoft prefers NVGRE.)

Examples of SDN via Overlays:

There are two major products for this type of SDN implementation.

Juniper Networks

Juniper launched the SDN controller Contrail using NETCONF and XMPP protocols instead of OpenFlow. Confusing for some is that Contrail released the code of Contrail and Open Contrail with varying technical Support levels provided by the company.

But let’s not confuse Open Source with Open SDN as defined in Demystifying Software Defined Networking I. Keep in mind that the southbound API of Contrail is XMPP and indeed a standards-based approach. Since the control plane still resides on those virtual switches and XMPP is not directly programming the data plane, I would not consider it Open SDN, but an SDN via hypervisor-based overlays approach.

VMware Network Virtualization Platform (NVP) and Network Security (NSX)

Prior to Nicira’s acquisition by VMware in 2012, Nicira’s Network Virtualization Platform (NVP) was a very popular SDN via hypervisor-based overlays offering in the market.

Since the acquisition, NVP is now bundled with VMware’s vCloud Network and Security (vCNS) and is marketed as VMware NSX where it continues to enjoy considerable market success, according to Gartner market data (2016) [2]. VMware’s NSX also includes an open source virtual switch called Open vSwitch (OVS) that works with the hypervisors in the NVP architecture. Open vSwitch has become the most popular Open Source virtual switch implementation, even outside of NVP implementations. Interestingly, NVP uses OpenFlow as the southbound interface from its controller to the OVS switches that form its overlay network. Thus, technically speaking, this solution is both an SDN via hypervisor-based overlays and an Open SDN implementation.

What are the Pros and Cons of Deploying NVP and NSX?

The Pros:

  • It’s great for data centers as any modern data center would already have some kind of virtualization running for compute and storage, and perhaps a hyperconverged solution.
  • It minimizes the amount of CAPEX required to bring some of the benefits of SDN to your data center as well as reduce the impact to changes on the running configuration.
  • It addresses, efficiently and cheaply, issues like the MAC address explosion for cloud and data centers, as in all these devices MACs are hidden within the encapsulated frames
  • It allows implementation of centralized automation and agility to deploy new networks, taking a fraction of time compared to deploying an entirely new physical network over existing physical ones.
  • It addresses VLAN limitations, tunneling all the traffic and not needing VLANs for supporting multiple tenants isolated from one another.
  • Using a solution like VMware NSX is coupled with a robust software product and its technical support provides a distinct advantage.

The cons:

  • SDN via Overlays does not “open” the devices as with Open SDN (see Demystifying Software Defined Networking I).
  • Leaving the physical infrastructure unchanged, you will still be required to do some manual or script-based configuration and maintenance of the physical network.
  • You won’t be able to handle traffic prioritization on the physical network.

Summary

SDN is emerging out of the early adopter and into the early mainstream stage of its development and will play a role in shaping the next-generation of networks for use cases such as SD-WAN, microsegmentation and IoT.

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.

As an additional resource, feel free to reference Laddie Suk’s blog Failure to Migrate: A Case Study in NFV Deployment and his newly published whitepaper “Bridging the Operational Gap to Accelerate NFV Deployment.”

Sources

[1] Network World: What SDN is and where it’s going

[2] Here’s Who Made Gartner’s 2016 Magic Quadrant For Data Center Networking

 

The post Demystifying Software-defined Networks Part III: SDN via Overlays appeared first on InFocus Blog | Dell EMC Services.

]]>
https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networking-part-iii-sdn-via-overlays/feed/ 2
Demystifying Software-defined Networks Part II: SDN via APIs https://infocus.dellemc.com/javier_guillermo/demystifying-sdn-sdn-via-apis/ https://infocus.dellemc.com/javier_guillermo/demystifying-sdn-sdn-via-apis/#respond Mon, 16 Oct 2017 09:00:52 +0000 https://infocus.dellemc.com/?p=32850 in my previous blog, I explained the basics of Software Defined Networking (SDN), how SDN has evolved to this point, the separation between the control plane and data plane, plus we named the three main flavors of SDN: Open SDN, SDN by APIs and SDN via overlays. We also covered the principles of the first […]

The post Demystifying Software-defined Networks Part II: SDN via APIs appeared first on InFocus Blog | Dell EMC Services.

]]>
in my previous blog, I explained the basics of Software Defined Networking (SDN), how SDN has evolved to this point, the separation between the control plane and data plane, plus we named the three main flavors of SDN: Open SDN, SDN by APIs and SDN via overlays. We also covered the principles of the first approach, Open SDN.

In this blog, I will cover the implementation of this technology via APIs, a preferred method used by traditional networking hardware companies.

SDN implementation via APIs refers to southbound APIs that configure and program the control plane active on the device. There are a number of legacy network device APIs in use that offer different degrees of control (SNMP, CLO, TL1, RADIUS, TR-069, etc.) and a number of newer ones (NETCONF/YANG, REST, XMPP, BGP-LS, etc.) that offer different degrees of control over the network devices, data plane, topology, etc., each having different advantages and disadvantages. I won’t cover them in depth in this blog post but I want to make sure we all understand one key difference between them and the Open SDN approach: OpenFlow is used to directly control the data plane, not just the configuration of the devices and the control plane.

SDN by APIs Overview

REST-API-LEGACY-API

 

Let’s start with some understanding on how network configuration and management is traditionally done. In the networking world of today, we still configure most devices though a Command Line Interface (CLI) by either connecting to the console of a device or through telnet/ssh of the device. Each device is then configured individually. That has been networking configuration 101 for more than 25 years.

The new SDN approach I covered in my previous blog has many technological and operational advantages, but it requires a company, institution or operator to replace old hardware for new hardware that supports the technology, and in some cases, new protocols like OpenFlow.

Obviously, no company is going to replace all of their hardware overnight, as it would require considerable expense, implementation and architecture challenges that, until resolved, could impact company operations. In addition, there would be plenty of non- technical issues, like employees knowing device X and networkOSY like the palm of their hands and not looking forward to the time it might take to learn new technology and processes.

When a company decides to transform to a software defined networking infrastructure, they may not get support from their existing Network hardware vendor, which may have been enjoying hefty margins in network hardware sales and not thrilled to push a technology that will make their expensive boxes replaceable for cheap vendor agnostic white boxes.

Architectural views of SDN by API

Architectural views of SDN by API

The left image shows an architecture view of a traditional network device (router, switch, etc.) with the software components and applications (Upper Rectangle) and hardware components (Lower Rectangle) such as ASIC (application specific integrated circuit for packet processing) and memory.

By adding a RESTful API interface we add an additional abstraction layer and upgrade legacy devices allowing to be controlled by an SDN controller using non OpenFlow standards.

SDN by API Vendors

Juniper Networks
We can argue that Juniper was one of the SDN pioneers in this area, through JunOS SDK, providing a rich set of tools for programmability and automation for all JunOS compatible devices. Some of the options available would allow you to control data plane packet processing, plus a wide variety of device functions. This SDK was created before SDN was popular, but as academia was already working on the SDN idea though Ethane back in 2007, perhaps Juniper was already looking to the SDN future back then. In present day, Juniper launched the SDN controller contrail, using NETCONF and XMPP protocls instead of OpenFlow.

Cisco Networks
We can’t talk about networking without talking about Cisco Networks. Cisco originally had its own proprietary program called Cisco onePK, consisting of a broad set of APIs that were proprietary for Cisco devices. Cisco now has two SDN-via-API controllers: the APIC-EM (Application Policy Infrastructure Controller-Enterprise Module) and the the APIC-DC (focused on Data center). Cisco is also implementing a new policy based protocol called OpFlex.

Arista
Arista Software Driven Cloud Networking (SDCN), combines the principles that made cloud computing the unstoppable force that it is: automation, self service provisioning, and linear scaling. Arista’s SDCN Is based around its API-centric definition of SDN and about the scaling of the existing control plane with different APIs.

OpenDaylight
Opendaylight is a bit of a hybrid, on one site it uses OpenFlow so we may be tempted to think it is purely an OpenSDN approach.. However the ODL controller also supports southbound APIs that program the legacy control plane on network devices, using plugins such as NETCONF and BGP-LS/PCE-P. There are different companies, for example, Fujitsu, that is developing its SDN Controller (Virtuora) based on OpenDaylight and no longer being Open Source.

Summary

SDN via APIs is a hybrid approach that will make the transition to the controller-based networking technology model more gradual and easier, especially for companies with a lot of legacy equipment or with close ties to specific proprietary networking vendors. Another plus is not having the centralized point of failure you may face in a pure OpenSDN. Compared to the other two approaches Tt ranks in-between for scale and performance..

On the negative side you won’t have support for Stateful Flow awareness or Deep packet Inspection plus it won’t escalate easily to mega data centers.

For additional information, please check part I of this series; Demystifying SDN: Open SDN Approach and view information on our just released Dell EMC NFV Ready Bundle for VMware.

The post Demystifying Software-defined Networks Part II: SDN via APIs appeared first on InFocus Blog | Dell EMC Services.

]]>
https://infocus.dellemc.com/javier_guillermo/demystifying-sdn-sdn-via-apis/feed/ 0
Demystifying Software-defined Networks Part I: Open SDN Approach https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networking-open-sdn-approach/ https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networking-open-sdn-approach/#comments Tue, 05 Sep 2017 09:00:17 +0000 https://infocus.dellemc.com/?p=32257 The joke goes around that the true meaning of Software Defined Networking (SDN) is “Still Don’t Know”.  In short, 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 […]

The post Demystifying Software-defined Networks Part I: Open SDN Approach appeared first on InFocus Blog | Dell EMC Services.

]]>
The joke goes around that the true meaning of Software Defined Networking (SDN) is “Still Don’t Know”.  In short, 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).

Software Defined Networking (SDN): Business Drivers

What’s driving the need to change from the transitional method of managing networks and move towards a SDN approach?  There are three key catalysts in the industry driving the need for network change as show in the graphic below.

SDN Business Drivers

Mobility, cloud, and IoT are three very real ways in which business is being digitally transformed and I will cover them in more detail in future blogs.

SDN, along with Network Function Virtualization (NFV) and other network virtualization technologies, are key to successfully transitioning to a data center that can adopt and deliver cloud solutions.  In this series of short blogs, I hope to give you some insights on topics important to better understanding SDN.

There are also three main ways to approach Software Defined Networking (SDN):

1. Open SDN

2. SDN by APIs

3. SDN by overlays

In this blog, I will be focusing on the Open SDN approach.  What is meant by Open SDN?  Both SDN and NFV technologies have a large open source community, committed to contributing to projects that promote open standards. As you see in the image below, separating the control and forwarding planes removes the controlling software from the device and onto a controller.  The device then handles the forwarding and data plane functions, while the controller handles the control plane functions.

Software Defined Networking_2

This approach tends to be focused around OpenFlow (OF), which is considered to be one of the first SDN standards, and allows a SDN controller to directly interact with network devices (routers, switches, etc.) as you see in the image below.  OF is just the protocol, so you could have Open SDN with other protocols if you choose.

This approach you see in the image below provides:

  • Simplified devices
  • A centralized controller
  • Enforcement of rules implemented by devices
  • Open environment for research and innovation
  • Interoperability
  • True network operating system
  • OF as the southbound standard protocol

Software Defined Networking_3

 

Check back for the next blog in the series where I will cover the SDN Approach by API.

Looking for more information on SDN and NFV? Check out NFV Operating Models – How to Mix Oil and Water (also known as IT Operations and Network Operations)

The post Demystifying Software-defined Networks Part I: Open SDN Approach appeared first on InFocus Blog | Dell EMC Services.

]]>
https://infocus.dellemc.com/javier_guillermo/demystifying-software-defined-networking-open-sdn-approach/feed/ 2