Open Flow Agent

A number of network elements such as the PON ONU and OLT and the optical switch cannot be controlled through a native OF v1.4 protocol. We have developed an OF agent (Figure 11), running collocated with the controller, that emulates the Openflow protocol and provides a mediation interface between the upper Openflow Control plane and the lower non-native Openflow network devices such as the FPGA-based LR-PON OLTs and ONU. The OF agent interprets the Openflow commands coming from the Access Network controller and communicates various changes to the PON network via a UART control link in the FPGA hardware. The OLT and connected ONUs can be controlled via the access network controller like any other network components. The OLT uses a proprietary messaging system over a UART serial interface. The optical switch can be controlled through a TL1 session. Transaction language 1 (TL1) is a man-machine management

51

protocol defined by Bellcore and is commonly used to manage the optical broadband and access equipment [105].

Figure 11 – OLT Fast protection mechanism

To control the Openflow Agent, the standard Openflow V1.4 syntax is used. Firstly, the Feature Mask is set to include capabilities for OFPPC_PORT_DOWN, OFPPC_NO_RECV,

OFPPC_NO_FWD and OFPPC_NO_PACKET_IN. Secondly the

OFPPortModPropOptical properites is built up based on freq_lmda, fl_offset, grid_span, tx_pwr. Lastly, the OFPPortMod method is called on the Openflow Agent datapath ID (or the MAC address) with the OFPPortModPropOptical properites and Feature Mask just described. The OFPPC_PORT_DOWN bit indicates that the port has been administratively brought down and should not be used by Openflow. The OFPPC_NO_RECV bit indicates that packets received on that port should be ignored. The OFPPC_NO_FWD bit indicates that Openflow should not send packets to that port. The OFPPFL_NO_PACKET_IN bit indicates that packets on that port that generate a table miss should never trigger a packet-in message to the controller.

The Openflow standard V1.4 introduced support for querying and managing the characteristics of Optical ports. This includes the ability to configure and monitor transmit and receive frequency of a laser, as well as its power. The Optical ports may be Ethernet based optical ports (i.e. Ethernet through SFP+ interfaces) or optical ports on circuit switches. This allows an Openflow controller to configure the optical ports through the Optical port mod property (ofp_port_mod_prop_optical), monitor the optical ports through Optical port stats property (ofp_port_stats_prop_optical) and to describe the optical ports through the Optical port description property (ofp_port_desc_prop_optical). To support the mapping between the real device, Openflow Agent has a number of data structures defined on a per-port basis to handle the attributes required by the Openflow Controller. The ofp_port_desc_prop_optical data structure stores attributes for Maximum

Functional Components

52

and Minimum Transmitted Frequency , Maximum and Minimum Received, Maximum and Minimum Transmitted Power and Features. Features is a bit mask, with the bits representing the capabilities of the particular port. The right-hand most bit (OFPOPF_RX_TUNE) denotes if the Receiver is tuneable or not (OFPOPF_TX_TUNE), the second bit if the transmitter is tuneable or not (OFPOPF_TX_PWR), the third bit of the Power is configurable and lastly, the fourth bit denotes whether the to use frequency or wavelength (OFPOPF_USE_FREQ). For the Openflow Agent, all four bits are set to the on position. The minimum, maximum, and grid spacing are specified for both transmit and receive optical ports as either a frequency in MHz or wavelength (lambda) as nanometres scaled up by a factor of 100. For ports that are not tuneable, the minimum and maximum values need to be identical and so specify the fixed value.

The overall behaviour of the Openflow Agent is described by the Openflow Agent class. It has two main routines or methods, wait_on_controller() and get_optical_message(). On instantiation, the Openflow Agent makes a network connection to the standard TCP listening port for Openflow (6633). The wait_on_controller() routine is a loop that waits for Openflow messages. Once the upstream Openflow controller accepts the TCP connection, it issues an Openflow Hello message to which Openflow Agent responds with Hello. Thereafter, wait_on_controller() handles responses to upstream controller requests for message types OFPT_ECHO_REQUEST, OFPT_BARRIER_REQUEST,

OFPT_FEATURES_REQUEST, OFPT_PORT_MOD, OFPT_MULTIPART_REQUEST

and OFPT_FLOW_MOD. Wait_on_controller() uses the OFPT_PORT_MOD message with subtype OFPT_PORT_MOD_OPTICAL as a trigger to generate a message (get_optical_message()) to the downstream Optical device, for which the Openflow Agent is acting as agent. get_optical_message() is a stub, which is over-ridden when Openflow Agent is instantiated.

The Openflow Agent is composed of 2 main sets of Classes. The first set of classes details the messages which are exchanged between the Openflow Agent and the upstream Openflow Controller. The Openflow Agent acts as a client, and the Openflow Controller acts as the server in the relationship. It is the function of the Openflow Agent to initiate the relationship, by contacting the controller. It is the function of the Openflow Agent to sufficiently mediate between the non-native Openflow device and the controller, and behave in a manner that will give the impression that the device is a real Openflow Switch. The base class of Openflow Agent message is ofPkt. All messages derive their attributes for transaction ID and payload from the ofPkt Class. OfPkt also details the versions of Openflow which the Openflow Agent can support. It is possible for the Openflow Agent and the Controller to negotiate to the most optimal version of Openflow to be used in the relationship. All messages have a common header with fields for the size of the message as well as detailing the message type. Depending on the message type, the payload of the

53

message will vary in length as well as format. Depending on the switch characteristics the size of messages can vary also. For example, there is a common format of data structure and command structure to manipulate a single port, however, different switches have different numbers of ports so the size of the total structures is sufficiently expandable.