There's very little argument when discussing the need for change in traditional data center networking to support private cloud--most all agree it's required. The real discussion typically focuses around how to implement that change. Concepts such as open APIs, SDN, OpenFlow, VXLAN and fabrics are all discussed as the solution. In some cases they may all be right, as they each have merit.
The main problem with traditional networking is its static configuration. Quality of service is a prime example: QoS provides traffic prioritization for frames on the network. In order to do this, frames must be classified, tagged and prioritized. In current implementations, this is done on a switch-by-switch basis and must be maintained consistently across the network in order to provide the desired effect.
This cumbersome, error-prone management system isn't conducive to cloud scale. Cloud systems provide rapid deployability for new services; this will be crippled by manual network configuration. The network will need to provide adaptability that matches or exceeds the rest of the infrastructure. Additionally, the network must provide the tools for multitenancy, allowing disparate services, groups and customers to coexist on the same physical infrastructure.
Switch and router APIs aren't necessarily a new thing but are gaining prominence as customers look to add automation and orchestration to their data centers. APIs provide a common set of programmable tools for the underlying functionality of the device. This allows for simpler integration into upper-level tools than other methods.
APIs will only be as good as the upper-layer system utilizing them. An additional weakness of APIs is that they maintain the single device view of the network. While they can assist in automation, they do nothing to provide a more holistic view of the network and services running on it. Additionally, APIs do not provide additional network visibility or programmability to the applications.
VXLAN focuses on the virtual network layer providing Layer 2 functionality above the physical infrastructure. VXLAN also acts as a network platform deployable by the hypervisor management system, which currently available with VMware and will most likely be embedded in Open vSwitch in the future. VXLAN itself is also a virtual-only technology, leaving physical servers and appliances segregated without a VXLAN gateway, which currently only Brocade has available.
SDN offerings come in many flavors and will continue to expand. There is currently no de facto standard for the model. Even within SDN systems like OpenFlow, there's no one controller standard. Overall, SDN is intended to provide network programmability and forwarding management of frames/packets dynamically at scale. This is typically done as a separation of the control plane, which manages flows from the data plane which forwards frames. This provides the additional benefit of a centralized view of the data center.
The last topic that's typically discussed when talking about the network pipes of private cloud is fabric. The concept of fabric isn't new--it traditionally described Fibre Channel-based storage networks. The term is now more often used to refer to Ethernet fabrics, which may carry storage traffic along with data center LAN traffic. The key concept of fabric is loop-free usage of all available links. This is contrary to Ethernet's traditional use of Spanning Tree Protocol (STP) to prevent loops by blocking the use of redundant ports. The most common method of fabric building is using TRILL, which basically uses ISIS routing on MAC address to provide a loop-free topology capable of multiple network paths. These fabrics provide a more simplistic network topology focused on maximum use of available links.
Typically, these tools aren't mutually exclusive and can provide complementary benefits. Quite commonly, fabric is discussed as a building block for SDN architectures. In this scenario, the fabric below provides an easily managed flat network of loop-free paths. Additional links can be added seamlessly as bandwidth is required; the same can be said for additional switches as more nodes are added.
The alternative to fabric below SDN is using a routed network built on commodity switches as a foundation. In this scenario, the routing provides a loop-free network and the SDN used provides programmable flow control and Layer 2 adjacency as needed. There are pros and cons to both approaches, and administrative overhead will be a major factor when deciding between the two.
Regardless of the method you choose, private cloud will push your network to new limits. The days of the CLI jockey will fade as our networks are required to do more, and adapt to change faster. Like the rest of IT, the network will move more and more into a management model governed by software overlays.
Disclaimer: This post is not intended as an endorsement for any vendors, services or products.
With many enterprises new to NaaS, service providers can differentiate themselves from competitors by prioritizing superior customer service and experiences.
Unlocking the full potential of telecom in the SaaS era relies on comprehensive strategies and a constant commitment to evolving security practices.
Eliminating complexity by standardizing with a platform approach is the way to put the brakes on the complexity cycle.
