In my last post, I have talked about the need for SDNs. I wanted to give my views on how SDN is going to play out in the market place.
Phase 1 - Openflow based Data path implementations (Hybrid implementation)
Device Side: Many L2 and L3 switch vendors are providing Openflow1.0 based implementation in their switches. Almost all these devices continue to support existing L2/L3 switching functionality with local control plane software, with additional configuration option to enable Openflow. That is, openflow is being added by the network device vendors as an option to the existing firmware. I also think that the openflow is only extended to L2 and L3 switch devices for now. It will be a while before market sees Openflow based Network Service Devices.
Controller Side: There are few companies providing Openflow protocol layer in Java, Python and other languages. This is lowest layer of software required on controllers and this communicates with Openflow based network devices. Big switch networks (www.bigswitchnetworks.com) and Nicira (www.nicira.com) are two of the companies I am aware of providing this layer at this time. They also plan to implement applications on top of this layer, but I guess that is phase2 of the SDNs. Some call this layer Network Operating system. . Beacon based Java framework for Openflow is one good library I have found. Please see this link to understand more about BEACON.
Due to limited controller applications, phase1 of the SDN is limited to research community and big network operators who are willing to develop their own controller applications.
Phase 2 : Openflow 1.1 based devices and Virtual instances of Control Plane software
Device Side: I expect that second phase of SDN would have Openflow 1.1 implemented by many network device vendors in their L2 and L3 switch devices. It is also very likely that market will see Openflow-only based network devices. In phase2, I expect that SSL/TLS openflow security would be a common feature. Some of the features that can be expected to see from device vendors implementing Openflow 1.1 are:
Controller Side: Virtual instances of L2 switch and L3 switch control plane protocol stacks would be the next logical step on top of Openflow protocol library. In this phase, one expectation is that there would be one virtual instance for every device it controls. Some of the features that would be seen from controllers in phase2 are:
Phase 3 (Auto Discovery of Network Devices and True Centralization AND Support beyond L2/L3 Switch Devices:
There will two types of protocols that may be required. One is auto-discovery of controllers by devices and second is topology discovery of devices by controllers.
Multiple features would be provided by Controllers and Devices. Some of them are listed below.
Phase 4 - Extending Programmabililty to Network Devices to support Service Planes
As discussed in the previous post, service plane functionality is different from the control plane. Service plane functions normally process certain amount of data before they handover the flows to Data Plane (Fast path). Though the amount of traffic expected to be processed is subset of entire traffic, this could be significant. Due to this, some service plane software may not be implemented in the controller for reasons such as performance and reduce the amount of traffic between devices and controllers.
In addition, there are some services such as IPFIX/NetFlow which are better implemented along with Data Plane.
If these services are expected to be implemented by device vendors, then it beats the SDN purpose. SDN is expected to give flexibility for network operators to develop service plane functionality or customize the service planes or purchase service planes from different vendor than the network device vendor.
I believe phase4 of SDN involves not only controller side flexibility for network operators, but also extending this programmability on the processors in the devices.
How it may work:
I believe there would be standardization on the software architecture in Network devices too. One possible standardization could be a requirement to support Java Virtual Machine in processors used in Network devices. There could be more abstractions on top of JVM by usage of middleware packages such as "Spring framework" or "OSGi' etc.. This standardization allows software vendors to develop the software in Java using one of these frameworks. Since they are java based, these applications need not worry about CPU architecture.
Java SDK also provide several providers for different accelerations - Crypto Provider (JCP) is one example. As long as operating system in device processors provide these providers based on their acceleration devices, then one Java based image would work fine.
Phase 1 - Openflow based Data path implementations (Hybrid implementation)
Device Side: Many L2 and L3 switch vendors are providing Openflow1.0 based implementation in their switches. Almost all these devices continue to support existing L2/L3 switching functionality with local control plane software, with additional configuration option to enable Openflow. That is, openflow is being added by the network device vendors as an option to the existing firmware. I also think that the openflow is only extended to L2 and L3 switch devices for now. It will be a while before market sees Openflow based Network Service Devices.
Controller Side: There are few companies providing Openflow protocol layer in Java, Python and other languages. This is lowest layer of software required on controllers and this communicates with Openflow based network devices. Big switch networks (www.bigswitchnetworks.com) and Nicira (www.nicira.com) are two of the companies I am aware of providing this layer at this time. They also plan to implement applications on top of this layer, but I guess that is phase2 of the SDNs. Some call this layer Network Operating system. . Beacon based Java framework for Openflow is one good library I have found. Please see this link to understand more about BEACON.
Due to limited controller applications, phase1 of the SDN is limited to research community and big network operators who are willing to develop their own controller applications.
Phase 2 : Openflow 1.1 based devices and Virtual instances of Control Plane software
Device Side: I expect that second phase of SDN would have Openflow 1.1 implemented by many network device vendors in their L2 and L3 switch devices. It is also very likely that market will see Openflow-only based network devices. In phase2, I expect that SSL/TLS openflow security would be a common feature. Some of the features that can be expected to see from device vendors implementing Openflow 1.1 are:
- Openflow 1.1 Multi-Table feature.
- Openflow 1.1 action handling
- Apply actions of each matching table entry to packets immediately
- Collect actions across all tables and apply all actions to the packets before packet egress.
- Openflow 1.1 Group actions
- To allow multiple actions on a packet.
- To setup common set of actions for multiple table entries.
- Flexibility of Matching Criteria on Match fields
- Values in ranges
- IP addresses in subnets
- 'NOT' Operator
- Multiple ranges/Subnets for a given match field.
- SSL/TLS Support
Controller Side: Virtual instances of L2 switch and L3 switch control plane protocol stacks would be the next logical step on top of Openflow protocol library. In this phase, one expectation is that there would be one virtual instance for every device it controls. Some of the features that would be seen from controllers in phase2 are:
- Multiple Virtual instances of L2 and L3 Control Plane protocol stacks and Management of flows by these virtual instances on corresponding devices. Due to large number of virtual instance requirement, thin virtualization systems would be used such as Linux containers or Linux processes with Network Name spaces.
- SSL/TLS Support.
- Centralized Management application on top of Virtual instances to provide one portal to the controller system. Even though it is single portal, every virtual instance would need to be configured independently.
Phase 3 (Auto Discovery of Network Devices and True Centralization AND Support beyond L2/L3 Switch Devices:
There will two types of protocols that may be required. One is auto-discovery of controllers by devices and second is topology discovery of devices by controllers.
Multiple features would be provided by Controllers and Devices. Some of them are listed below.
- Auto discovery of Controllers : Devices will discover the controllers and gather information on how to reach them.
- Topology discovery of devices : Devices will provide information to controllers for controller to know following information.
- Device specific information
- Make (vendor and Model) of device.
- Type of functionality supported (L2, L3 switch etc..)
- Capabilities of the device such as Number of ports , Number of tables supported, Size of each table, Size of all tables put together, Type of actions, Capabilities of Group table, Number of flows, SSL/TLS support, QoS capabilities (Number of queues, schedulers, algorithms for shaping, scheduling and queueing).
- Connectivity information- This information is required if controllers are expected to program the device with flows via in-band network. I believe that in future, network operators may not like to create a controller network for controller/device communication. Controllers and network devices are expected to communicate without any special network via same network as data traffic. To enable this communication, all intermediate devices between the device that is being programmed and controller need to allow controller channel flows. Connectivity information is required to be known to the controller to create channel flows in appropriate devices.
- NAT Support: Network Address Translation as required by ADCs, Load Balancers etc.. There may be Openflow 1.2 or later versions supporting NAT action.
- IPSec Support: I believe future versions of Openflow specification may add IPsec action on the tables.
- Multi Controller Support: A given device may be controlled by more than one controller. Resource division across controllers is one feature that can be expected in future.
- Multi-Tenant Support: Virtualization of network for each tenant would be supported in future. Data Center provider no longer need to worry about creating several physical networks for multiple tenants when this feature is supported by Controllers.
- Avoiding running control plane protocols across devices that are managed by the same Controller.
- Topology specific configuration rather than the device specific configuration.
- I also expect more programmability options in controllers for Network operators to customize or add new features on controllers.
Phase 4 - Extending Programmabililty to Network Devices to support Service Planes
As discussed in the previous post, service plane functionality is different from the control plane. Service plane functions normally process certain amount of data before they handover the flows to Data Plane (Fast path). Though the amount of traffic expected to be processed is subset of entire traffic, this could be significant. Due to this, some service plane software may not be implemented in the controller for reasons such as performance and reduce the amount of traffic between devices and controllers.
In addition, there are some services such as IPFIX/NetFlow which are better implemented along with Data Plane.
If these services are expected to be implemented by device vendors, then it beats the SDN purpose. SDN is expected to give flexibility for network operators to develop service plane functionality or customize the service planes or purchase service planes from different vendor than the network device vendor.
I believe phase4 of SDN involves not only controller side flexibility for network operators, but also extending this programmability on the processors in the devices.
How it may work:
- Controller Software vendor provides the binary image for several services.
- Controller, based on services provisioned, pushes the relevant binary images to network devices.
- Network devices have different types of processors - Power Cores, MIPS, ARM, x86 etc.. Creation of binary images for multiple CPU architectures for each service could become cumbersome.
- Many processors in recent past are SoCs (System-On-Chip), which contains different types of accelerators. Even though multiple SoCs might use same cores, programming will be different across different SoCs due to different types of peripherals and acceleration engines. That adds to the complexity and increases the number of binary images required.
I believe there would be standardization on the software architecture in Network devices too. One possible standardization could be a requirement to support Java Virtual Machine in processors used in Network devices. There could be more abstractions on top of JVM by usage of middleware packages such as "Spring framework" or "OSGi' etc.. This standardization allows software vendors to develop the software in Java using one of these frameworks. Since they are java based, these applications need not worry about CPU architecture.
Java SDK also provide several providers for different accelerations - Crypto Provider (JCP) is one example. As long as operating system in device processors provide these providers based on their acceleration devices, then one Java based image would work fine.
No comments:
Post a Comment