e-guide defining sdn and the purchase questions that...

E-Guide

DEFINING SDNAND THE PURCHASE QUESTIONS THATCOME ALONGWITH IT

▲

SearchSDN

PA G E 2 O F 2 1 S P O N S O R E D B Y

Home

What is SDN? The answer now includes automation and virtualization

14 questions to ask SDN vendors before investing

Cisco SDN strategy helps lift revenue, profits

DEFINING SDN AND THE PURCHASE QUESTIONS THAT COME ALONG WITH IT

hat software-defined networking really means has evolved dramatically and now includes automation and virtualization. If you are considering SDN technology, this

expert eGuide breaks down 14 questions to pose to a vendor before investing. Also read on to learn about how Cisco’s SDN strategy is increasing the number of ACI customers.

W


Home





WHAT IS SDN? THE ANSWER NOW INCLUDES AUTOMATION AND VIRTUALIZATIONJohn Burke

What is SDN? The term doesn't mean what it used to. The magic of market-ing and the very real need to focus more on ends than means have forced software-defined networking (SDN) to stretch to cover more concepts than it did originally.

When everyone began to get excited about SDN a few years ago, we thought of it as only one thing: the separation of network control from network data packet handling. Traditional networks had already started down this path, with the addition of controller cards to manage line cards in scalable chassis-based switches, and with various data center fabric technologies. SDN took the idea to its logical end, removing the need for the controller and the packet handlers to be on the same backplane or even from the same vendor. In a software-defined network, the data plane handles packets under the direction of a control plane, but the controllers are just applications that can run on standard x86 hardware. SDN controllers use a standard protocol (OpenFlow) to communicate with


Home





data plane devices. Other specialized network appliances -- like firewalls and load balancers -- that get recast as SDN applications also run on standard x86 hardware using the SDN controller to get the data plane devices to do what they need to do.


Home





The "SDN Classic" model, as illustrated by this graphic from the Open Net-working Foundation, offers many potential benefits:

�� Increased agility by making it possible to reconfigure the network from a central point.�� Increased flexibility by making it possible to deliver any network func-tion on any network port; a node's location in the network no longer determines what services can be delivered to it.��Reduced vendor lock in by separating controllers from data plan devices.�� Reduced capital costs by making data plane switches generic commodity items and allowing controller and applications to run on standard server hardware.��Reduced maintenance costs.

As SDN excitement grew, the term software-defined was adopted by mar-keters and applied liberally to all kinds of products and technologies: software-defined storage, software-defined security, software-defined data center. The SDN definition was itself stretched to accommodate several kinds of technol-ogy that support the primary goals of SDN Classic -- to make the network agile


Home





and flexible and less dependent on specific arrangements of specialized physi-cal devices -- without embracing the primary means (applications, control plane, OpenFlow, data plane).

AUTOMATION, VIRTUALIZATION NOW UNDER SDN UMBRELLA

If SDN Classic was fundamentally about separation of functions, SDN now embraces not just separation but also automation and virtualization as a means to these ends.

This aspect of SDN focuses on the creation of a network automation hub, with APIs over which network orchestration and cloud management systems can request changes in the network (provisioning, deprovisioning, reprovision-ing). Whether it is a classic SDN controller speaking OpenFlow, or a standalone tool that can dynamically reprogram existing, conventional switches using their command line interfaces (CLIs), or some other technology, these are all now recognized as living under the SDN umbrella.

As a concept, virtualization is about separating the logical, functional ver-sion of something from the physical infrastructure underlying it, such as virtual servers and desktops separated from x86 hardware, virtual storage separated from the disk arrays, and so on. The network has been slower to virtualize than


Home





other parts of the data center, a choke point in data center operations: Where virtual servers and storage might be spun up in a few minutes, the correct net-work setup might take days or weeks. Classic SDN virtualized the network: Logical function resided in the software layer only, and the software was not tied to specific devices. Other approaches are now part of SDN and include the following:

�� Running multiple versions of a logical appliance on the same physical hardware (e.g., multiple virtual firewalls on a single physical one).�� The virtualization of network appliances into applications or virtual machines running on commodity server hardware (the core of NFV, network functions virtualization).��The creation of an overlay network.

Overlay networks use the physical network already in place for transport, and appliances and switches under the control of the overlay network use tunneling protocols, primarily VXLAN, to communicate with each other. The physical network passes packets along, but the overlay network determines who can talk to whom.


Home





SDN's boundaries have shifted from an emphasis on the means used to the ends accomplished. Thanks to that shift in focus, the answer to the question "What is SDN?" has changed. The term has now come to broadly embrace not just OpenFlow-based separation of control from packet-handling, but also automation technologies that help make the network fully programmable, and virtualization technologies that free function from the constraints of cabling and topology.


Home





14 QUESTIONS TO ASK SDN VENDORS BEFORE INVESTINGEthan Banks

SDN is a new technology with an array of offerings and possible use cases, so shopping for an SDN product suite is a challenging task.

Buyers must start by assessing what each SDN vendor offers -- and this can vary radically. Some SDN vendors offer a traditional approach to SDN that separates data and control planes from the physical network and uses a central-ized controller to direct forwarding paths. Others offer software overlays with hypervisors or virtual switches that control the virtual network. Still, others are not proposing SDN at all, but are touting virtual appliances that could play a role in network programmability.

While all of these technologies can help move your network into the soft-ware-defined realm, it is key that the vendor describes its SDN vision in detail and that users understand how these strategies fit into their existing architec-tures, as well as whether they meet their organization's business needs.

Here are 14 questions to ask an SDN vendor before investing in their technology.

PA G E 1 0 O F 2 1 S P O N S O R E D B Y

Home





1. Which vendors do you partner with? Creating a holistic SDN product suite that covers Layers 1 through 7 is a mammoth task. Many SDN vendors of-fer only one or two key elements of an SDN stack for this reason. To understand how the product offering will fit into your environment, you need to understand the partnerships the vendor has developed around its product. This is key when evaluating controller products.

2. What SDN applications run on your platform? Some vendors are offering turnkey SDN products that include robust applications to enable you to inte-grate the network with your business processes or to tackle a specific problem. Others are offering toolsets that allow you to build whatever specific logic you might require. The two approaches are aimed at different customers. If you're looking for a vendor-supplied and -supported SDN application that solves a specific problem, make sure you understand exactly what applications run to-day, as well as what is on the vendor's roadmap. If you're looking for an arbiter that brings your network into your orchestration or DevOps world, make sure the vendor explains how it will work with you to develop your applications. It's not unreasonable to ask for face time with the vendor's product engineering team if you're in this situation.

3. What are some use cases your product has been deployed for? SDN is not


Home





a "tried and true" mature networking technology. The space is saturated with startups, fresh ideas and emerging paradigms. To understand how the product you're evaluating fits your needs, you should ask the vendor to supply white pa-pers and customer references that demonstrate how its technology addresses specific challenges. Unless you're the test case helping to develop the vendor's product, you don't want to be patient zero.

4. If my network hardware is not programmable, how can your product help my organization? While programming the network centrally is one of SDN's big ideas, not all network hardware is OpenFlow-compatible or offers an ap-plication programming interface (API). Your vendor should be able to explain how its product can interface with your hardware in that case. This shouldn't be a big deal for most vendors, as remote configuration methods like SNMP and the ubiquitous command line interface (CLI) have been around for a long time, but make sure you get specifics, as much SDN technology presumes the use of OpenFlow.

5. How will your product integrate into my existing network? Your ven-dor should have a reference architecture illustrating how to bring up its SDN product alongside the network you already own. Hybrid switching and "SDN islands" that pass through an SDN gateway acting as a bridge to and from your


Home





legacy infrastructure are common approaches.6. What is your licensing model? While SDN is all about the technology,

the reality of a purchase is that vendors use a variety of techniques to price the product. Depending on your use case, how the vendor licenses its technology could impact your budget severely. Get intimately familiar with exactly how the vendor licenses its technology and what that means for the design you have in mind. Does it license by capability? Per device? By traffic or transac-tion volume? This is especially key to grasp when comparing Capex vs. Opex. A licensing model that doesn't seem too arduous during the acquisition phase could become quite costly as the years roll by.

7. Do you recommend in-band or out-of-band (OOB) management be-tween controller and network hardware? When building a software-defined network, southbound communications between network devices and the controller -- as well as northbound communications between applications and the controller -- is a crucial network function. Different vendors have differ-ent recommendations regarding in-band vs. out-of-band, along with logic to justify their positions. In-band is touted for the ability to detect a path failure in the network mesh between the device and the controller, revealing network link failures that might otherwise go undetected. OOB is touted as a means of


Home





guaranteeing control-plan communication latency and potentially improving network security.

8. Which OpenFlow operations can your switch perform in hardware (silicon)? OpenFlow is the darling of the SDN movement, providing a vendor-agnostic means of describing how a network switch should treat a given traffic flow. Many vendors have announced OpenFlow compatibility on one or more of their hardware switch product lines. While you'd think OpenFlow would become a great switch equalizer in this role, the reality is that vendors are struggling to map OpenFlow operations into their existing silicon. Many switch vendors have designed custom application-specific integrated circuits (ASICs) for their switches, designed to do several kinds of forwarding, prioritization and encapsulation operations rapidly. This speed allows for network scale. ASICs have long development cycles; however, most were designed well before OpenFlow gained the notoriety it currently enjoys.Therefore, if OpenFlow at scale is a critical part of your evaluation process, you need the vendor to state very specifically which OpenFlow operations it can do in hardware and at how many flows per second. Also plan to go through a critical evaluation to prove that the product will meet your needs.

9. Are you publishing your APIs? Network devices have APIs. Controllers


Home





have APIs. Are the APIs public and documented? If not, will the vendor share them with you? If you are planning on developing your own applications built on the vendor's platform, this is an important discussion to have.

10. What programming languages do your APIs support? Vendors have to choose what languages they will support. Java and Python are popular, others less so. The key is to understand what languages are supported and then map that capability back to your talent pool. Ideally, the product you're considering will not pose an undue burden on your development team.

11. What skills will my operators need to learn to run your product? Tra-ditional network engineers and operators have honed their networking skills, configuring individual devices at the Common Language Infrastructure. SDN eschews the Common Language Infrastructure, offering a programmatic means of network configuration. Your vendor needs to explain how its specific product will impact your existing operational policies. It's likely that your staff will need to learn new skills or update their processes to find success with in-coming SDN.

12. How will you support this product? SDN puts vendors in an awkward position when it comes to supporting their customers' networks. While cus-tomers have been accustomed to leveraging vendor support to work through


Home





bugs and problems, SDN gives the customer enough rope to proverbially hang themselves in ways the vendor has no control over. Customers need to under-stand exactly how a vendor will support them when it comes to the bits of code they have created themselves.

13. How does your product avoid vendor lock-in? While some IT shops are comfortable with a single vendor based on the philosophy of "one throat to choke," most shops prefer to keep their choice of vendor options open. In net-working this is especially true, and this corner of the industry has gone to great effort to develop and adhere to interoperable standards. This interoperability has allowed customers to keep their options open when it comes to equipment vendors, knowing they wouldn't necessarily be tied down if a chosen product fell from favor.SDN is so new that it does not have a group of interoperable stan-dards right now, and while vendors are often taking similar approaches with their respective products, many anticipate an integrated stack of equipment. In other words, a controller from vendor X is going to work best with switches from vendor X. It's incumbent on the buyer to understand the dependencies in what's being sold to keep vendor lock-in at bay.

14. What is your roadmap for support of the Linux Foundation's Open-Daylight project? As OpenDaylight (ODL) develops, it could form a baseline of


Home





interoperability referenced by all SDN products in the industry. While ODL is in its infancy as of this writing, it is conceivable that vendors will look at ODL as the right foundation for their own SDN offerings. If this turns out to be the case, the ideal position to be in as a customer will be to own SDN products that are ODL-compliant. This would pave the way for third-party, innovative products that give a network options to enhance its SDN capabilities without relying exclusively on the primary controller or switch vendor as time goes on. That said, it's early to insist on such a feature, as "OpenDaylight-compliant" doesn't mean anything just yet. But it's something to keep an eye on.


Home





CISCO SDN STRATEGY HELPS LIFT REVENUE, PROFITSAntone Gonsalves

Cisco reported higher sales in its software-defined networking products, as outgoing CEO John Chambers declared critics "entirely wrong" about the company's ability to adapt to the market shift away from hardware.

Cisco reported May 13 that orders for the Nexus 9000 product line in-creased 27% from the second to the third fiscal quarter that ended April 25. The number of Nexus 9000 customers increased by 974 to 2,655.

"We expect that sequential growth to accelerate in Q4," Chambers said.Nexus 9000 switches are the native platform for Cisco's software-defined

networking architecture called Application Centric Infrastructure (ACI). The number of ACI customers increased by 231 in the quarter to 585. Cisco started shipping ACI technology last year.

ACI is Cisco's answer to companies like VMware that provide a software-centric approach to networking. Cisco's architecture ties software to its hard-ware, while VMware's rival NSX technology runs on any hardware.

Overall sales of switches grew 6% year over year. Chambers bristled at an


Home





analyst's comment that much of the revenue increase was due to Cisco's poor showing last year, when overall sales fell for the first time in five years.

"All this garbage about new players coming in and software coming in and white label [hardware] killing our approach was entirely wrong," Chambers said during a conference call.

CISCO RETURNS TO STABILITY

Overall revenue for the last quarter increased 5.1% year over year to $12.1 bil-lion. Net income rose 11.7% to $2.4 billion. Analysts had expected revenue of $12.07 billion, according to a Thomson Reuters poll.

The increase in revenue and profit was an indication that Chambers had brought back stability from last year. The resurgence is expected to help incom-ing CEO Chuck Robbins, who takes over July 26. Robbins led global sales for Cisco.

The company reported progress in sales of its unified computing systems, a data center server that integrates computing, networking and storage re-sources in the same hardware. Cisco reported that the number of repeat UCS customers increased 34% in the quarter. More than 43,800 organizations use UCS servers, according to Cisco.


Home





In 2014, Cisco revenue in the server market rose nearly 30%, higher than all its major competitors, according to IDC. The overall market grew 2.3%.

Revenue from wireless networking technology increased 9% in the quarter and security sales grew by 14%. "Security is the ideal market for us," Chambers said. "It's made up of hundreds of fragmented players [and] we're the largest volume player."

CISCO STRUGGLES IN SERVICE PROVIDER MARKET

Cisco continued to struggle in selling to cable companies and carriers. Orders from service providers fell by 17% in the U.S. and 7% globally.

Over the last 18 months, Cisco changed its high-end product portfolio to be in "architectural alignment" with the needs of service providers, said Robbins who joined Chambers in the conference call. As a result, the company expected sales to return to positive growth in a couple of quarters.

Chambers will remain with Cisco as executive chairman after Robbins be-comes chief executive. Chambers plans to work with Robbins only as an adviser. "Chuck is the CEO -- period," Chambers said. "He will make the decisions."

Robbins, a 17-year Cisco veteran, has said he plans to stick with the compa-ny's current strategy. However, he would "accelerate" efforts in certain markets,


Home





such as security. He also planned to impose greater "operational rigor."


Home





FREE RESOURCES FOR TECHNOLOGY PROFESSIONALSTechTarget publishes targeted technology media that address your need for information and resources for researching prod-ucts, developing strategy and making cost-effective purchase decisions. Our network of technology-specific Web sites gives you access to industry experts, independent content and analy-sis and the Web’s largest library of vendor-provided white pa-pers, webcasts, podcasts, videos, virtual trade shows, research

reports and more —drawing on the rich R&D resources of technology providers to address market trends, challenges and solutions. Our live events and virtual seminars give you ac-cess to vendor neutral, expert commentary and advice on the issues and challenges you face daily. Our social community IT Knowledge Exchange allows you to share real world information in real time with peers and experts.

WHAT MAKES TECHTARGET UNIQUE?TechTarget is squarely focused on the enterprise IT space. Our team of editors and net-work of industry experts provide the richest, most relevant content to IT professionals and management. We leverage the immediacy of the Web, the networking and face-to-face op-portunities of events and virtual events, and the ability to interact with peers—all to create compelling and actionable information for enterprise IT professionals across all industries and markets.

e-guide defining sdn and the purchase questions that...

Documents