Jump to: navigation, search

SNMP4SDN:Architecture and Design

Features

  • OpenDayLight SAL plugin
  • Enable Ethernet switch on the SDN paradigm by means of SNMP & CLI as the south bound protocol
  • New mechanisms for topology discovery for Ethernet switch in SDN
  • Realize flow configuration on Ethernet switches over the forwarding table, ACL, and VLAN table

Overview

We propose a southbound plugin that can control the off-the-shelf commodity Ethernet switches for the purpose of building SDN using Ethernet switches. For Ethernet switches, forwarding table, ACL, and VLAN table are where one can install the flow configuration on, and this is done via SNMP and CLI in the proposed plugin. In addition, extensions to the SAL configuration APIs are needed to provide additional API to support some settings, e.g. disabling STP and flooding, etc, which are required for Ethernet switches in SDN.

SNMP4SDN in ODL Architecture.jpg

Figure. SNMP4SDN as a southbound plugin in OpenDaylight architecture

Functionality

For the SDN controller to support building an SDN using Ethernet switches, it needs to be able to configure flows on the Ethernet switches. In addition, in initial, it has to discover which switches are under its management and then can configure flows on them. Also, the connectivity topology among switches is necessary information for the controller and applications. In this plugin, flow configuration on Ethernet switch would be done via SNMP or CLI, switch discovery would be achieved via SNMP trap sent from the switch, and topology discovery would be resolved by reading LLDP data on the switches.

Flow configuration on Ethernet switch

A flow’s configuration on an Ethernet switch could be implemented by configuring forwarding table, ACL, and VLAN, via SNMP or CLI.

Forwarding table configuration

The entry of the forwarding table is composed of “destination mac address” and “output port”, so a flow with indicating only its destination mac address and output port could be configured on the forwarding table. The configuration could be done via SNMP. That is, the plugin could send corresponding SNMP command to the switch so as to add/modify/delete/read an entry on the forwarding table that equivalents to add/modify/delete/read a flow on the switch.

ACL configuration

(TBD)

VLAN configuration

A VLAN could be regarded as a kind of flow. A VLAN is given a specific VLAN ID and the VLAN ports on the switches. VLAN settings on a switch, including adding/removing/showing VLAN and assign VLAN ports on a switch, could be done via SNMP.

Switch discovery

A mechanism for the controller and switches to know each other are necessary in an SDN. For example, OpenFlow switches need to be configured to have a controller IP address set, then every switch will proactively connects the controller, then the controller can manage the switches. As for Ethernet switches, however, they were not designed to behave like OpenFlow switches to proactively connect to the specific controller, since in tradition it is not assumed to have a central controller above. Therefore, the approach for Ethernet switch to proactively notify the controller of its existence could be: using SNMP trap. That is, every Ethernet switch is (1) configured with its SNMP host (i.e. the controller’s IP address) and (2) configured to send SNMP trap when the switch boots up. (1) and (2) are supported in general and needs to be configured manually via CLI for only once. In this way, the controller will know a switch joining in, when receiving the switch’s SNMP trap of booting up. And note that the controller will check the community provided in the SNMP trap that whether the community is the same as the controller's, given that the controller has a community. If the community is not the same, the controller will neglect this switch.

We had introduced this approach with the ODL community, and the feedbacks include: agreeing with this approach since it is very similar to how OpenFlow switch is set to join the controller in initial, or other ideas such as using LLDP or using DNS-SD. And then their limitations or concern of prerequisite had been discussed. So we will still use the approach of SNMP trap.

SNMP4SDN SwitchDiscovery.jpg

Figure. Switch discovery by means of SNMP trap

Topology discovery

To discover the connectivity topology among all the switches, we can know the connectivity between switches by reading the LLDP data on every switch, and then the whole topology among all the switches could be resolved. An example is illustrated as below. The plugin queries each switch, and each switch responds with its LLDP data, including the switch it self’s port IDs, chassis IDs of the connected switches, and port IDs of the connected switches. Then, this information could be resolved as edges.

SNMP4SDN TopologyDiscovery.jpg

Figure. Topology discovery example

Design

Modules in SNMP4SDN

The modules in the plugin as well as the interaction among the modules are depicted as follows.

  • FlowProgrammerService: to add/modify/remove flows on the switches.
  • ReadService: to acquire the flow's or switch's or port's statistics.
  • InventoryService: to acquire the switches’ and their ports’ properties.
  • DiscoveryService: to probe and resolve the underlying switches as well as the port pairs connecting the switches. The probing is realized by SNMP queries. The updates from discovery will also be reflected to the TopologyService.
  • TopologyService: to query and acquire the switches' topology.
  • ConfigService: to do kinds of vendor-specific proprietary settings on switches
    • Supported vendor-specific proprietary settings, such as: to disable kind of flooding (BPDU flooding, broadcast flooding, multicast flooding, and unknown flooding), disabling source mac check and source learning, and setting SNMP host and community.

For the services above, when they need to read or configure the underlying switches via SNMP or CLI, these queries are dealt with the modules SNMPHandler and CLIHandler which directly talk with the switches.

SNMP4SDN Modules.jpg

Figure. Modules in the SNMP4SDN plugin


SNMP4SDN Architecture Internal.jpg

Figure. Architecture of the SNMP4SDN plugin and the interaction among the modules

Architecture for vendor specific APIs

For the configurations which cannot be implemented by SNMP but is implementable by CLI on commodity Ethernet switches, due to various format of CLI commands on different Ethernet switch products, the interface IConfigService defines the CLI-dependent APIs. Part of IConfigService is as follows.

package org.opendaylight.snmp4sdn;
public interface IConfigService {
    Status disableSTP(Node node)
    Status disableBpduFlooding(Node node)
    Status disableBpduFlooding(Node node, NodeConnector nodeConnector)
    ...
}

Then, IConfigService is implemented in ConfigService. ConfigService is to retrieve parameters from Node, NodeConnector, and CmethUtil (CmethUtil maintains every switch's CLI username, password, etc), and passes the parameters to CLIHandler. Vendor specific implementation is processed in CLIHandler. Then CLIHandler calls ExpectHandler to send out the CLI command to the switch. Parts of ConfigService and CLIHandler are as follows.

package org.opendaylight.snmp4sdn.internal;
public class ConfigService implements IConfigService{

    @Override
    public Status disableSTP(Node node){
        CmethUtil cmethUtil = controller.getCmethUtil();
        String sw_ipAddr = cmethUtil.getIpAddr((Long)node.getID());
        String username = cmethUtil.getCliUsername((Long)node.getID());
        String password = cmethUtil.getCliPassword((Long)node.getID());
        return new CLIHandler(sw_ipAddr, username, password).disableSTP();
    }

    @Override
    public Status disableBpduFlooding(Node node){
        CmethUtil cmethUtil = controller.getCmethUtil();
        String sw_ipAddr = cmethUtil.getIpAddr((Long)node.getID());
        String username = cmethUtil.getCliUsername((Long)node.getID());
        String password = cmethUtil.getCliPassword((Long)node.getID());
        return new CLIHandler(sw_ipAddr, username, password).disableBpduFlooding();
    }
    ...
}

In CLIHandler, vendor specific implementation is processed here. For example in the code below, in the CLIHandler(), ExpectHandler is called, given the prompt string. In disableBpduFlooding(), the CLI command string "config stp fbpdu disable" is given, and check whether the switch's respond string contains a substring "Success".

package org.opendaylight.snmp4sdn.internal;
import org.opendaylight.snmp4sdn.internal.ExpectHandler;
public class CLIHandler{
    ExpectHandler expect;
    String sw_ipAddr, username, password, prompt = "#";

    public CLIHandler(String sw_ipAddr, String username, String password){
        this.sw_ipAddr = new String(sw_ipAddr);
        this.username = new String(username);
        this.password = new String(password);
        try{
            expect = new ExpectHandler(sw_ipAddr, "UserName:", "PassWord:", username, password);//D-Link DGS-3120 switch's prompt for login: "UserName:" to prompt for username, and "PassWord" to prompt for password
        }catch(Exception e){
            logger.warn("CLIHandler() err:" + e);
        }
    }

    public Status disableSTP(){
        try{
            if(expect.execute("disable stp", "#", "Success"))
                return new Status(StatusCode.SUCCESS);
        }catch(Exception e){
            logger.warn("CLIHandler.disableSTP() err:" + e);
        }
        return new Status(StatusCode.INTERNALERROR);
    }

    public Status disableBpduFlooding(){
        try{
            if(expect.execute("config stp fbpdu disable", "#", "Success"))
                return new Status(StatusCode.SUCCESS);
        }catch(Exception e){
            logger.warn("CLIHandler.disableBpduFlooding() err:" + e);
        }
        return new Status(StatusCode.INTERNALERROR);
    }
    ...
}

Deep dive to architecture design

Architecture design in Developer Guide