在Main中先是加载模块,启动REST服务,而后构建一个实现了IFloodlightProviderService接口的实例(即Controller)并运行,进入Controller的run()方法;
位置:net.floodlightcontroller.core.Main.java ;
功能:初始化IFloodlightModuleContext变量,启动Controller和RESTApi Service位置:net.floodlightcontroller.core.internal.Controller.java
Run()方法启动Controller,监听Switch的请求和将监听事前发送给各个监听模块。
此时所有的环境初始化工作已经完成,构建一个基于netty的TCP server,最重要的是流水线factory OpenflowPipelineFactory 的设置,里面是controller上流,下流处理的handler。
Floodlight 使用的是Netty架构,在Controller.java 入口函数中显示创建ServerBootstrap:
//使用到了JBoss 的Netty框架
//创建Netty的服务端ServerBootstrap
final ServerBootstrap bootstrap = createServerBootStrap();
bootstrap.setOption("reuseAddr", true);
bootstrap.setOption("child.keepAlive", true);
bootstrap.setOption("child.tcpNoDelay", true);
bootstrap.setOption("child.sendBufferSize",Controller.SEND_BUFFER_SIZE);
//创建处理Switch连接的工厂
ChannelPipelineFactory pfact =
new OpenflowPipelineFactory(this, null);
//设置服务端处理连接的工厂
bootstrap.setPipelineFactory(pfact);
InetSocketAddress sa = (openFlowHost == null) ? new InetSocketAddress(openFlowPort)
: new InetSocketAddress(openFlowHost, openFlowPort);
//将服务端加入线程池
final ChannelGroup cg = new DefaultChannelGroup(); cg.add(bootstrap.bind(sa));
log.info("Listening for switch connections on {}", sa);
设置套接字选项ChannelPipeline,此时监听套接字就准备好处理来自SW的各种消息;这里最核心的就是 OpenflowPipelineFactory ,会加入各个业务相关的Handler,ChannelPipeline工厂代码如下:
public ChannelPipeline getPipeline() throws Exception {
OFChannelState state = new OFChannelState();
ChannelPipeline pipeline = Channels. pipeline();
pipeline.addLast( "ofmessagedecoder", new OFMessageDecoder());
pipeline.addLast( "ofmessageencoder", new OFMessageEncoder());
pipeline.addLast( "idle", idleHandler );
pipeline.addLast( "timeout", readTimeoutHandler );
pipeline.addLast( "handshaketimeout",
new HandshakeTimeoutHandler(state, timer , 15));
if (pipelineExecutor != null)
pipeline.addLast( "pipelineExecutor",
new ExecutionHandler(pipelineExecutor ));
//OFChannelHandler 是核心
pipeline.addLast( "handler", controller.getChannelHandler(state));
return pipeline;
}
当Channel建立,接收到来自OF SW的消息之后就会调用 messageReceived() 方法;根据不同的of msg类型,分发给 processOFMessage 进行具体处理;此外,如果这个消息需要进行对SW的回复,或者有其他监听者感兴趣,就呼叫 handleMessage 进行额外的处理,代码贴出来。
protected void handleMessage(IOFSwitch sw, OFMessage m, FloodlightContext bContext){
Ethernet eth = null;
switch (m.getType()) {
case PACKET_IN:
OFPacketIn pi = (OFPacketIn)m;
// 默认情况下总是true
if (Controller.ALWAYS_DECODE_ETH) {
eth = new Ethernet();
//解析packet_in消息到eth中,所以下面的bcStore可以直接存储
eth.deserialize(pi.getPacketData(), 0, pi.getPacketData().length);
counterStore.updatePacketInCounters(sw, m, eth);
}
// fall through to default case...
default:
List<IOFMessageListener> listeners = null;
if (messageListeners.containsKey(m.getType())) {
listeners = messageListeners.get(m.getType()).getOrderedListeners();
}
FloodlightContext bc = null;
if (listeners != null) {
// Check if floodlight context is passed from the calling
// function, if so use that floodlight context, otherwise
// allocate one
if (bContext == null) {
bc = flcontext_alloc();
} else {
bc = bContext;
}
if (eth != null) {
IFloodlightProviderService.bcStore.put(bc,IFloodlightProviderService.CONTEXT_PI_PAYLOAD, eth);
//缓存到hashmap中,所以当我们添加自己的模块来监听packetin消息的时候,可以从中取出,做自己的业务处理。
}
Command cmd;
for (IOFMessageListener listener : listeners) {
if (listener instanceof IOFSwitchFilter) {
if (!((IOFSwitchFilter)listener).isInterested(sw)) {
continue;
}
}
// 遍历所有对packetin感兴趣的listener,分别执行他们的receive方法;
cmd = listener.receive(sw, m, bc);
if (Command.STOP.equals(cmd)) {
break;
} } }
if ((bContext == null) && (bc != null)) flcontext_free(bc);
} }
3. 在循环中随时处理SW的更新消息,开始分发事件给监听者:
// main loop
// 不断处理阻塞队列中SW的更新信息
while (true ) {
try {
IUpdate update = updates.take();
update.dispatch();
} catch (InterruptedException e) {
return;
} catch (StorageException e) {
log.error("Storage exception in controller "
+ "updates loop; terminating process", e);
return;
} catch (Exception e) {
log.error("Exception in controller updates loop", e);
}
}
4. 那么Controller中的BlockingQueue中的更新信息是在何时加入的呢?这里只跟踪交换机加入的情况,很容易想到当监听套接字收到一个来自OF SW请求的时候。所以我们看 OFChannelHandler ,可以视为是业务相关的第一个UpstreamHandler,在通道连接的时候会回送一个HELLO消息,这里的重点看处理消息的过程,进入函数 messageReceived 接下来的处理流程(如下),在收到 GET_CONFIG_REPLY 消息之后说明这个SW准备好了(会把握手状态改为 HandshakeState.READY),而后会把这个SW加入到activeSwitches 和 updates中。
Floodlight controller和OF SW交互流程图:
更新阻塞队列的代码是:
updateActiveSwitchInfo(sw);
SwitchUpdate update = new SwitchUpdate(sw, true);
try {
// 把update加到BlockingQueue里,如果BlockQueue没有空间,则调用此方法的线程被阻断
// 直到BlockingQueue里面有空间再继续.
this.updates .put(update);
} catch (InterruptedException e) {
log.error("Failure adding update to queue" , e);
}
通过上面的分析,相当于有了一个生产消费者模型,生产者就是交换机的加入或者移除消息,消费者就是Controller的处理过程,取出消息进行计算,为拓扑更新服务。具体过程仍然是一个监听者模式,把SW的更新信息分发到各个订阅者中进行处理(看SwitchUpdate类),代码如下:
public void dispatch() {
if (log .isDebugEnabled()) {
log.debug("Dispatching switch update {} {}", sw, added);
}
// 遍历这些listeners,处理加入或移除事件
if (switchListeners != null) {
for (IOFSwitchListener listener : switchListeners) {
if (added )
listener.addedSwitch( sw);
else
listener.removedSwitch( sw);
}
}
}
那么订阅 SwitchUpdate 消息的类是谁呢?LinkDiscoveryManager!交换机的加入或者移除活动肯定会带来链路信息的改变,当加入一个新SW的时候,就会通过发送 LLDP frame 来发现拓扑结构(参见 Floodlight Controller 路由原理 )。代码如下
public void addedSwitch(IOFSwitch sw) {
//这里的设计需要优化
// It's probably overkill to send LLDP from all switches, but we don't
// know which switches might be connected to the new switch.
// Need to optimize when supporting a large number of switches.
sendLLDPTask.reschedule(2000, TimeUnit.MILLISECONDS );
// Update event history
evHistTopoSwitch(sw, EvAction. SWITCH_CONNECTED, "None");
}
5.当一个packet到达openflow交换机,会进行流表的匹配,如果没有找到相应的流表项,就会发送一个packet_in消息到达SDN controller端,控制器根据一定的路由算法决策后,会向该路径上的所有交换机下发流表(也就是发送FLOW_MOD消息,里面有对应的action)。这里要知道的是在SDN的环境下,控制器具有全局拓扑信息,每当有链路状态改变时就会跟新拓扑,而路由的计算是需要下发转发规则的时候进行。下面对这个流程进行详细分析。
链路发现模块会关注两种消息 PACKET_IN 和 PORT_STATUS ,从而分析链路的变更。这里看对于PACKET_IN ,LinkDiscoveryManager的处理过程:
LinkDiscoveryManager完成的工作是增加或更新链路状态,加入到一个LDUpdates队列中,接下来看拓扑管理模块TopologyManager,它在启动的时候会新起一个线程 NewInstanceWorker :首先根据消息类型来增删该链路的状态,然后创建一个计算拓扑的实例TopologyInstance来计算出拓扑并存储,具体过程如下:
当完成拓扑计算后,当来了一个packet_in,就会根据源目SW得到路径。
接下来防火墙,负载均衡模块会发挥作用(这里先略过)。
最后路由模块会完成最终的下发流表操作,这里看Forwarding模块中的processPacketInMessage()。
会从packet中得到相应的源目设备实例IDevice,而后判断是否在同一个openflow island上,如果不在的话就
doFlood(sw, pi, cntx),这里主要看二者在同一个island的情况。然后得到每个设备的AttachmentPoints,
然后找到二者能够连通的粘合点,接下来得到路劲,最后构造flow_mod消息,写入通道,下发给SW。