Goransson / Black Software Defined Networks

A Comprehensive Approach
1. Auflage 2014
ISBN: 978-0-12-416684-4
Verlag: Elsevier Science & Techn.
Format: EPUB
Kopierschutz: 6 - ePub Watermark

E-Book, Englisch, 352 Seiten

Software Defined Networks discusses the historical networking environment that gave rise to SDN, as well as the latest advances in SDN technology. The book gives you the state of the art knowledge needed for successful deployment of an SDN, including: - How to explain to the non-technical business decision makers in your organization the potential benefits, as well as the risks, in shifting parts of a network to the SDN model - How to make intelligent decisions about when to integrate SDN technologies in a network - How to decide if your organization should be developing its own SDN applications or looking to acquire these from an outside vendor - How to accelerate the ability to develop your own SDN application, be it entirely novel or a more efficient approach to a long-standing problem - Discusses the evolution of the switch platforms that enable SDN - Addresses when to integrate SDN technologies in a network - Provides an overview of sample SDN applications relevant to different industries - Includes practical examples of how to write SDN applications

Paul Goransson is Founder and Chairperson of the Elbrys Networks where he currently leads corporate strategy and directs Elbrys' Intellectual Property portfolio. A serial entrepreneur who has led two boot-strap start-up companies through successful acquisitions by industry giants - Qosnetics by Hewlett Packard (1999) and Meetinghouse by Cisco (2006). Paul held senior management positions with Agilent Technology's Advanced Networks Division and Cisco's Wireless Networking Business UnitPaul co-authored the book 'Roaming Securely in 802.11 Networks” as well as numerous articles in technical journals related to computer networking. He is often an invited speaker at technical conferences.

Autoren/Hrsg.

Goransson, Paul

Black, Chuck

Leseproben

Chapter 2 Why SDN?
Abstract
Chapter 2 describes the technical context that spawned the need for SDN. We continue the discussion on the evolution of switches and control planes begun in Chapter 1, providing additional technical details. The traditional distributed control plane has failed to scale to the size and complexity of many modern deployments. This chapter explains that this failure stems from a number of reasons. The most important are 1) simple technical inability to handle the size of the modern mega-data centers, 2) the elevated costs of networking equipment as compared to other equipment in the data center, and 3) a disconnect between the rate of innovation in the areas of compute and storage virtualization as compared to networking. Since the data center has been the location where these shortcomings have surfaced first and most dramatically, we delve into the innovations in server virtualization that have allowed data centers to reach a scale that is unsustainable for traditional networking technologies. We review specific data center demands that are not being met by legacy networks. This chapter describes how these requirements are nudging networking technology away from traditional methods and protocols towards the more open and innovation-friendly paradigm of SDN. Keywords
Spanning tree protocol (STP); BGP; OSPF; IS-IS; TCAM; Access control list; ASIC; Merchant silicon; Network equipment manufacturers (NEM); OPEX; CAPEX; Hypervisor; VMware; Hyper-V; ToR; Multitenancy Networking devices have been successfully developed and deployed for several decades. Repeaters and bridges, followed by routers and switches, have been used in a plethora of environments, performing their functions of filtering and forwarding packets throughout the network toward their ultimate destinations. Despite the impressive track record of these traditional technologies, the size and complexity of many modern deployments leaves them lacking. The reasons for this fact include the ever-increasing costs of owning and operating networking equipment, the need to accelerate innovation in networking, and, in particular, the increasing demands of the modern data center. This chapter investigates these trends and describes how they are nudging networking technology away from traditional methods and protocols toward the more open and innovation-friendly paradigm of SDN. 2.1 Evolution of Switches and Control Planes
We begin with a brief review of the evolution of switches and control planes that has culminated in a fertile playing field for SDN. This complements the material presented in Sections 1.4 and 1.5. The reader may find it useful to employ Figure 2.1 as a visual guide through the following sections; it provides a graphical summary of this evolution and allows the reader to understand the approximate timeframes when various switching components moved from software to hardware.
Figure 2.1 Networking functionality migrating to hardware. 2.1.1 Simple Forwarding and Routing Using Software
In Chapter 1 we discussed the early days of computer networking, when almost everything other than the physical layer (layer one) was implemented in software. This was true for end-user systems as well as for networking devices. Whether the devices were bridges, switches, or routers, software was used extensively inside the devices in order to perform even the simplest of tasks, such as MAC-level forwarding decisions. This remained true even through the early days of the commercialized Internet in the early 1990s. 2.1.2 Independence and Autonomy in Early Devices
Early network device developers and standards creators wanted each device to perform in an autonomous and independent manner to the greatest extent possible. This was because networks were generally small and fixed, with large shared domains. A goal also was to simplify rudimentary management tasks and make the networks as plug and play as possible. Devices’ relatively static configuration needs were performed manually. Developers went to great lengths to implement this distributed environment with intelligence resident in every device. Whenever coordination between devices was required, collective decisions could be made through the collaborative exchange of information between devices. Interestingly, many of the goals of this distributed model, such as simplicity, ease of use, and automatic recovery, are similar to the goals of SDN, but as the scale and complexity of networks grew, the current distributed model has become increasingly dysfunctional. Examples of this distributed intelligence are the layer two (bridging) and layer three (routing) protocols, which involved negotiation between the devices in order to reach a consensus on the way forwarding and routing would be performed. We introduced these protocols in Chapter 1 and provide more SDN-specific details on them here. • Spanning Tree Protocol.
Basic layer two forwarding, also known as transparent bridging, can be performed independently by each switch in the network. However, certain topologies require an imposition of a hierarchy on the network in order to prevent loops, which would cause broadcast radiation. The Spanning Tree Protocol (STP) is an example of the operation of autonomous devices participating in a distributed decision-making process to create and enforce a hierarchy on the network. The result is the correct operation of transparent bridging throughout the domain at the expense of convergence latency and possibly arbitrary configuration. This solution was a tradeoff between cost and complexity. Multiple paths could have been supported but at greater cost. STP was adequate when networks were of smaller scale, but as networks grew the spanning tree solution became problematic. These problems manifest themselves in a striking fashion when networks reach the scale of the modern data center. For example, IEEE 802.1D specifies the following default timers for STP: 15 seconds for listening, 15 seconds for learning, and 20 seconds for max-age timeout. In older networks, convergence times of 30–50 seconds were common. Such delays are not acceptable in today’s data centers. As the scale of the layer two network grows, the likelihood of greater delays increases. The Rapid Spanning Tree Protocol (RSTP) protocol, specified in IEEE 802.1D-2004 [6], improves this latency significantly but unfortunately is not deployed in many environments. • Shortest-Path Bridging.
STP allowed only one active path to a destination, suffered from relatively slow convergence times and was restricted to small network topologies. Although the newer implementations of STP have improved the convergence times, the single active path shortcoming has been addressed in a new layer two protocol, Shortest-Path Bridging (SPB), introduced in Section 1.5.1. SPB is a mechanism for allowing multiple concurrent paths through a layer two fabric via collaborative and distributed calculation of shortest and most efficient paths, then sharing that information among the participating nodes in the meshed network. This characteristic is called multipath. SPB accomplishes this goal by utilizing IS-ISto construct a graph representing the layer two link-state topology. Once this graph exists, shortest-path calculations are straightforward, though more complex than with spanning tree. To elaborate on what we mean by shortest-path calculations, in Figure 2.2 we depict a simple graph that can be used for calculating shortest paths in a network with five switches. The costs assigned to the various links may be assigned their values according to different criteria. A simple criterion is to make the cost of a network link inversely proportional to its bandwidth. Thus, the cost of transiting a 10 Gbps link is one-tenth that of transiting a 1 Gbps link. When the shortest-path calculation is complete, the node performing the calculation knows the least-cost path to any of the other nodes in the network. The least-cost path is considered the shortest path. For the sake of clarity, we should point out that IS-IS is used in the SPB context strictly for layer two path calculation. This differs from its classical application in calculating layer three routes, as described below. In the trivial example of Figure 2.2, there is a single shortest path from node to every other node. In real-life networks it is common for there to be more than one least-cost path between two nodes. The multipath characteristic of SPB would allow the traffic to be distributed across those multiple paths. • RIP, BGP, OSPF, and IS-IS.
Routing at layer three requires cooperation between devices in order to know which routers are attaching which subnetsto the network. In Chapter 1 we provided background on four routing protocols: RIP,BGP,OSPF,and IS-IS.These routing protocols involve the sharing of local routing information by each device, either at the edge of the network or as an intermediate node. Their collective sharing of information allows the routing state to converge as devices share their information with each other. Each router remains autonomous in terms of its ability to make routing decisions as packets arrive. This process is one of peers sharing and negotiating among themselves, without a centralized entity aiding in the decision.
Figure 2.2 Example graph of a...