Notes On Chapter 31 -- Software Defined Networking (SDN)

• 31.1 Introduction
  
  
  • Presentation of an exciting new technology for network management
  • Motivation, general approach, and underlying technology
  
  
• 31.2 Marketing Hype And Reality
  
  
  • Many preposterous claims have been made regarding SDN.
  • One must always consider pros and cons carefully.
  
  
• 31.3 Motivation For A New Approach
  
  
  • 31.3.1 Generalization of Element Management
    • Currently managers have to deal pretty much with one element at a time.
    • There seems to be a need for higher-level control that works on sets of elements.
    
    
  • 31.3.2 Moving from Proprietary to Open Standards
    • It should be possible to devise a management system that coordinates all operations of multiple devices if all vendors agree to implement an open management standard.
    • Currently vendors commonly add proprietary extensions, even if implementing SNMP.
    
    
  • 31.3.3 Automation and Unification of Configuration
    • Human error is a hazard to managers who are responsible to configure elements.
    • One problem is that there may be slight differences in the ways that devices are supposed to be configured, depending on the ways they are supposed to be used.
    • An idea for automation is to specify a policy for configuration, which would be implemented automatically.
    
    
  • 31.3.4 Change to Cross-Layer Control
    • Critics of existing network management paradigms argue that more effective results could be obtained by coordinating the management of separate layers, which are currently managed separately and independently.
    
    
  • 31.3.5 Accommodating Data Center Visualization
    • Often nowadays computers in networks consist of multiple virtualized hosts, each running its own operating system, and requiring its own IP address, or set of IP addresses. Such virtual hosts can migrate from one physical computer to another.
    • The possibility of such migration occurring at very short time scales calls for the ability to keep up with other functions related to network management, such as routing changes.
    
    
  
  
• 31.4 Conceptual Organization Of A Network Element
  
  
  • The control plane is the part of a network device that provides the functionality for management of the device - usually implemented in software.
  • The data plane is the part of a network system that processes packets - usually implemented in hardware.
  • Part of the job of the control plane is to load configuration information into the data plane.
    
    
    
    
  
  
• 31.5 Control Plane Modules And The Hardware Interface
  
  
  • It is common to have access to the control plane through a command line interface (CLI), GUI accessed with a web browser, or an SNMP agent application.
  • Vendors may make proprietary CLI commands available that allow management of multiple devices of the type sold by that vendor.
  
  
  
  
• 31.6 A New Paradigm: Software Defined Networking
  
  
  • In the paradigm of Software Defined Networking, most of the control plane functionality is external to the devices, for instance in a Linux workstation called a controller.
  • The external controller manipulates a low-level SDN module, which must be installed in the device, and be configured to function suitably as an intermediary between the external controller and interface to the data plane of the device.
  
  
  
  
• 31.7 Unanswered Questions
  
  
  • What is the nature of the physical connection between an external controller and the network element it controls?
  • What protocol is used for communication between the controller and the network element?
  • What kind of software does the controller run?
  • Is a separate controller needed for each element?
  • What is the additional cost of utilizing the SDN paradigm?
  
  
• 31.8 Shared Controllers And Network Connections
  
  
  • One physical controller can handle multiple network elements. Per-device loads on the controller are not usually high.
  • Designers envision multiple sets of network elements called SDN domains, with a physical controller assigned to each domain, and the controllers communicating and coordinating with one another to maintain overall compliance to management policy.
    
    
    
    
  
  
• 31.9 SDN Communication
  
  
  • Given the design paradigm described above, protocols will be needed for controller-to-element communication, and also for controller-to-controller communication.
  • The assumption is that SDN should use the production network and TCP/IP protocol software stacks for all communication.
  • Although there are ideas for mitigation, SDN is viewed as vulnerable to failures that might occur on the production network.
  
  
• 31.10 OpenFlow: A Controller-To-Element Protocol
  
  
  • OpenFlow is a protocol for controller-to-element communication that has received wide acceptance.
  • The OpenFlow communication paradigm is connection-oriented - typically utilizing TCP.
  • Where a secure connection is desired SSL is recommended.
  • OpenFlow concentrates on a flow table model for packet forwarding, and does not define a large MIB like SNMP
  • OpenFlow specifies the format of all messages, and their meanings.
  
  
• 31.11 Classification Engines In Switches
  
  
  • Using OpenFlow, controllers can change the classifications that are used as patterns by Ethernet switches to regulate their packet forwarding decisions.
  
  
  
  
• 31.12 TCAM And High-Speed Classification
  
  
  • High-speed classification using pattern-matching in switches is performed through the use of content-addressable memory.
  
  
• 31.13 Classification Across Multiple Protocol Layers
  
  
  • A single classification pattern can check items from multiple layers of the protocol stack at the same time.
  • Thus patterns installed by OpenFlow SDN controllers can cause sophisticated flow changes, like identifying all web traffic and sending it out a certain port. (Web traffic if, layer 2 frame type is IP, layer 3 IP protocol field is TCP, and layer 4 TCP destination port is 80)
  
  
• 31.14 TCAM Size And The Need For Multiple Patterns
  
  
  • TCAM hardware is expensive, consumes a lot of power, and generates a lot of heat.
  • It will require matching on a large number of patterns to accomplish the kinds of classifications designers have in mind.
  • Thus the cost and power consumption associated with SDN is a potential problem.
  
  
• 31.15 Items OpenFlow Can Specify
  
  
  • Figure 31.6 shows the header fields that OpenFlow can use in classification patterns.
  
  
  
  
• 31.16 Traditional And Extended IP Forwarding
  
  
  • Because of its ability to match on numerous fields in packets, SDN has the potential to perform 'new' kinds of routing - like routing based on source, destination port number, type of service, and so forth.
  
  
• 31.17 End-to-End Path With MPLS Using Layer 2
  
  
  • Using SDN and OpenFlow technology, it is possible to configure layer 2 VLANs and layer 2 paths that cross multiple switches and widely separated geographic locations.
  • There are fewer features in a layer 2 network upon which to launch a security attack, so there are possible security advantages to using such networks.
  
  
• 31.18 Dynamic Rule Creation and Control Of Flows
  
  
  • Network switches can be programmed with rules that cause them to send 'oddball' packets to their controller.
  • Then the controller can decide how the packet should be routed, send rules to the switch that implement the routing rule, and finally send the packet back to the switch to be sent on, by use of the newly installed rule.
  • Load balancing could be implemented with the paradigm described above, if the first packet in a new TCP connection is passed to the controller.
  
  
• 31.19 A Pipeline Model For Flow Tables
  
  
  • Later versions of OpenFlow can control a software-based classification mechanism.
  • This allows the possibility of a series of classification mechanisms called flow tables.
  • This allows for more complex packet processing.
    
    
    
    
  
  
• 31.20 SDN's Potential Effect On Network Vendors
  
  
  • Adoption of SDN would mean vendors would have to stop selling the current devices with proprietary management software.
  • There may be other opportunities for profits - e.g. building and selling vendor-independent network management software.
  
  
• 31.21 Summary