Archive

Archive for the ‘NFV’ Category

Network as a Service (NaaS) in the cloud

August 17, 2014 Leave a comment

Network as a Service

First there was IT as a service (IaaS), then Software as a Service (SaaS), then Platform as a Service (PaaS) and now Network as a Service (NaaS)?   A startup called CloudFlare is offering a next-gen Content Delivery Network (CDN) which accelerates 235,000 websites  but more specifically offers networking-as-a-service in the cloud using open source networking hardware and software from startup Pluribus Networks which replaced existing Juniper EX-series switches.  Pluribus offers its own network switch running a distributed network hypervisor on its own hardware (featuring Intel Xeon processors and Broadcom switch chips) or on a Supermicro MicroBlade platform.  Pluribus aims for the Top of Rack (ToR) use-case where many servers need to be networked together in a corporate datacenter.    However with Facebook open-sourcing “Wedge” (Linux based software stack in a ToR switch comprising 16 x 40GbE ports, merchant 40 Gb switching ASIC in a 1U rack space – and with no proprietary software) there is bound to be a move towards white-box switches from large datacenters like that of Facebook or Google down to smaller corporate datacenters.  The fact that Cisco and Juniper vehemently claim that Wedge is no threat to them reminds me of the quote from Shakespeare’s Hamlet: “The lady doth protest too much, methinks”.shakespeare JPEG

It is difficult to pigeonhole CloudFlare into any one bucket – as they offer a next gen CDN, handle 5% of the internet’s traffic using equipment located in 25 data centers worldwide, offer routing, switching, load balancing, firewall services, DDOS mitigation, performance acceleration – all as a cloud service.  Just as Amazon Web Services (AWS) made compute services in the cloud a concept we accept unquestioningly today, I think the time is right for Network as a Service.  Customers of CloudFlare include Reddit (which is sometimes described as a market-place of ideas impervious to marketers), eHarmony,  Franklin Mint and the site metallica.com.

Why do I think startups like CloudFlare will make a lasting impression on the internet?  For one it fascinated me to learn that CloudFlare got its datacenter in Seoul up and running without a single employee setting foot in Seoul.  A 6 page how-to-guide walked the equipment suppliers into what they needed to do to get the datacenter up and running to support the CDN and security services that CloudFlare offers its customer.  This gives new meaning to the term “remote controlled datacenter”.  The future is all about plug-and-play, low-touch and remote control.  The old world of buying high end hardware routers & switches, deploying them in a corporate data center, worrying about heat, floor-space and cooling  will all seem archaic some years from now.  CloudFlare will be one of the many innovators in this emerging area of Network as a Service and enterprise IT budgets will reap the resulting gains.

Advertisements
Categories: NFV, SDN, Shakespeare

OpenFlow for SDN – still relevant in 2014?

January 10, 2014 1 comment

Metaphor for OpenFlow

Metaphor for OpenFlow

When I read the prediction “OpenFlow is dead by 2014” it got me thinking…  What is it about OpenFlow that inflated expectations and drove things to a fever pitch only to end up in a “trough of disappointment” (to borrow overused analyst terminology) in 2014?  If Software Defined Networking (SDN) is a way to program network operations to serve a business need and involves separating the data plane in the hardware switches from a centralized control plane residing outside the switch, then OpenFlow is a forwarding protocol for SDN.  Once the control plane decides how to forward packets, OpenFlow enables the programing of switches to actually make this happen.  Use-cases for OpenFlow are compelling:

  • Google talked about how they improved WAN utilization from 30-40% which was the norm across the industry to a staggering ~100% using OpenFlow and home-grown switches.  These switches were build by Google using merchant silicon and open source routing stacks for BGP and IS-IS
  •  IPv6 address tracking could be handled by an OpenFlow v1.2 controller and OpenFlow 1.2 enabled switches
  • Data centers can reduce CAPEX by not buying hardware based network taps and instead using OpenFlow to program the functional equivalent of a network tap on a OpenFlow enabled layer 2 switch
  • OpenFlow controllers and OpenFlow enabled switches can help data-centers migrate from old firewalls to new ones in a seamless manner.

So what changed to bring on the naysayers?  All of the above still holds true.  While HP, Dell, Brocade, Arista Networks, Fujitsu, NEC, Big Switch Networks and others embraced OpenFlow, holdouts like Cisco & Juniper supported it grudgingly if at all.   Seeing switch upstart Arista Networks eroding Cisco revenue from Top of Rack (ToR)  switches, Cisco released the Nexus 3100 as one of its few switches to support OpenFlow 1.0 and even VMware NSX.  Juniper de-emphasized work on the OpenDayLight project and OpenFlow and decided to reinvent SDN by acquiring Contrail leading to disastrous results.  Despite all this, those who believe in OpenFlow and are against vendor lock-in march on:  OpenFlow is being evaluated by CenturyLink (3rd largest telecom provider in the USA) and by Verizon, deployed by providers like Sakura Internet, Rackspace, NTT Communications. SDN start-up Pica8 is promoting OpenFlow and switch programmability by offering white box switches, an open-source routing stack, the Ryu OpenFlow controller and an Open vSwitch (OVS) implementation.  Pica8 has won prominent customers like NTT and Baidu with this approach.  Storage start-up Coho Data offers a storage solution that converges networking and storage using OpenFlow & SDN.  If OpenFlow were a sentient being and could speak it would paraphrase Mark Twain and proclaim: “The reports of my death have been greatly exaggerated!”

Categories: NFV, SDN Tags: , ,

Network overlay SDN solution used by PEER1

December 27, 2013 Leave a comment

Embrane powering PEER1 Hosting

SDN enabled cloud hosting

As I enjoy my employer mandated shut-down and gaze sleepily at the phone on my desk, my mind begins to wander… Today we use services from companies like Vonage and make international calls over high speed IP networks.  Vonage in turn operates a global network using the services of cloud hosting companies like PEER1 Hosting.  PEER1 claims to have 20,000 servers worldwide, own 13,000 miles of fiber optic cable, 21 Points of Presence (POP) in 2 continents, 16 data centers in 13 cities around the world.  Like any large hosting provider they use networking gear from vendors like Juniper and Cisco.  Their primary data-center in the UK is said to deploy Juniper gear: EX-series Ethernet switches with virtual chassis technology,  MX-series 3D edge routers,  and SRX series services gateways.   However when they wanted to offer customers an automated way to spin up firewalls, site-to-site VPNs and load balancers in a matter of minutes they ended up using technology from Embrane a 40-person start-up in the crowded area of SDN start-ups.

Why did they not use SDN solutions from Juniper their vendor of choice for routers and switches?    Juniper initially partnered with VMware to support NSX for SDN overlays and Juniper was a platinum member of the OpenDaylight project.  Then Juniper did an about-turn and acquired Contrail a technology that competes with VMware.   Juniper claimed that despite not supporting OpenFlow, the Contrail SDN controller will offer greater visibility into layer 2 switches due to the bridging of BGP and MPLS.  Unlike the Cisco SDN solution which prefers Cisco hardware, Juniper claimed that Contrail would work with non-Juniper gear like that from Cisco.  To generate interest from the open source community in Contrail, Juniper open sourced OpenContrail – though most of the contributors to OpenContrail on GitHub are from Juniper.

It is interesting to note that customers like Peer1 may rely on Juniper or Cisco for their hardware but when it comes to finding an automated way to deploy networking services as an overlay they go with start-ups like Embrane.  Embrane has an interesting concept: Their technology allows a hosting provider to overlay firewalls and load balancers using vLinks which are point-to-point layer3 overlays capable of running over any vendor hardware (not just Cisco or Juniper).  Many such vLinks are part of a single administrative domain called vTopology.    Embrane allows you to make a single API call to bring up or bring down an entire vTopology.  An example of how this makes life easier for a hosting provider: When an application is decommissioned all associated firewall rules are also decommissioned unlike other methods where you end up with firewall rules living past their time.

I will watch with interest to see if companies like Embrane and PlumGrid end up turning the SDN world on its head and pumping some adrenalin into the dull world created by hardware vendor monopolies and their interpretation of SDN.

Categories: NFV, SDN

Software Defined Networking – What’s in it for the customer?

December 23, 2013 Leave a comment

What's in it for me the customer?

What’s in it for me the customer?

While the terms Software Defined Networking (SDN) and Network Functions Virtualization (NFV) are often used in the same breath, they are complementary technologies offering greater promise when used together.  NFV has to do with virtualizing switches and routers, while SDN separates the control plane and data plane of your network, leading to a programmable network which in turn facilitates easier deployment of business applications over that network.  Rather than get bogged down into what the  router/switch vendors are saying about SDN or NFV, let us step back and hear the perspective of the customer.  What is motivating a telecom provider or an enterprise data center to consider SDN or NFV?

AT&T views NFV as a tool to reduce cycle time for rolling out new services and removing old services.  AT&T seeks a common API (not necessarily an open API) between the SDN controller and the physical network devices.  It recognizes that you can put some network software on Commercial off-the-shelf (COTS) devices but may end up retaining custom network hardware with proprietary ASICs to get the acceleration and higher throughput that COTS devices may not deliver.

Deutsche Telecom makes a fine distinction – They see in SDN a way to program “network services” (not network products) from a centralized location for a multi-vendor network partly located in-house and partly in the cloud.

NTT Communications states 3 goals: Reduce CapEx and OpEx, differentiate based on services, faster time-to-market.   NTT was an early adopter of Nicira NVP, Nicira SDN controllers, VMware vCloud Director.  It virtualizes network connectivity using NEC ProgrammableFlow solutions – NEC SDN controllers for an OpenFlow network.  NTT Communications also collaborate with NTT Labs on Ryu (Open source OpenFlow controller).

If you ask the Hyperscale data centers like Facebook, Google, Rackspace they have a slightly different goal.

Facebook has a goal of gaining greater control of their networking hardware and taking away “secret ASIC commands” issued by router/switch vendors to equipment in the Facebook data center.

Google has as its goal a single view of the network, better utilization of network links and hit-less software upgrades.

A trading firm if asked for their expectations from SDN might say that they want to offer their customers big pipes with very low latency during trading hours and after-hours would like to pay less to their carrier for the same big pipe but with a higher latency to enable less latency sensitive applications like on-line backup.

The common thread here is services, the ability to roll-out services more effectively and create differentiation in a crowded price-sensitive market.   In the follow-on articles we’ll look at what each of the major vendors has to offer and pros/cons of each SDN solution.

Categories: NFV, SDN Tags: