Software Definition X has become increasingly popular. Software is eating the world. The same is true for Software Defined networks. Both in the industrial and academic fields will be a great revolution. They are all following the direction of this industry, looking for their own research points, and paying attention to the development of standardization. Various controllers and prototype systems have emerged one after another. Some of them are SDN debug and security. In short, they make the ecosystem more robust. Although there are many southbound interface standards, openflow is suitable for our learning and the Community is huge. Next I will record my main views on this.
1. first, it should be clear that, like other communication protocols, openflow defines communication rules between SDN controller and of SW, so that the switch device can be controlled centrally; 2. openflow message is divided into different types, including flow table behavior (such as flow mod), handshake (such as HELO), and macro control switch (such as ofp_set_config ), define their meaning. 3. if we need to expand the openflow protocol for our business, we need to consider simply adding a message type? Still need to control switch behavior based on this message? Or do you want to manipulate the actions of each flow table item? To control the action of each stream, we need to add the corresponding action for the message. It can imitate the flow mod, which is a flow mod structure diagram sent by the Controller to the switch (if the action-list of the flow_mod is just an ofpact_output to indicate the outbound port of the stream, there can be many other actions ).
Reprinted with the source: http://blog.csdn.net/vonzhoufz/article/details/37937759
Thoughts on extended openflow Protocol
