Name
OF-CONFIG
Repo Name
off-config
Description
The motivation for the OpenFlow Configuration Protocol (OF-CONFIG) is to enable the remote configuration of OpenFlow datapaths. As described in Figure 1, an OpenFlow Configuration Point communicates with an Operation Context that contains an OpenFlow Switch using OF-CONFIG.
Figure 1
OF-CONFIG defines an OpenFlow switch as an abstraction called an OpenFlow Logical Switch. The OF-CONFIG protocol enables configuration of essential artifacts of an OpenFlow Logical Switch so that an OpenFlow controller can communicate and control the OpenFlow Logical switch via the OpenFlow protocol. OF-CONFIG introduces an operating context for one or more OpenFlow datapaths called an OpenFlow Capable Switch for one or more switchs. An OpenFlow Capable Switch is intended to be equivalent to an actual physical or virtual network element (e.g. an Ethernet switch) which is hosting one or more OpenFlow datapaths by partitioning a set of OpenFlow related resources such as ports and queues among the hosted OpenFlow datapaths. The OF-CONFIG protocol enables dynamic association of the OpenFlow related resources of an OpenFlow Capable Switch with specific OpenFlow Logical Switches which are being hosted on the OpenFlow Capable Switch. OF-CONFIG does not specify or report how the partitioning of resources on an OpenFlow Capable Switch is achieved. OF-CONFIG assumes that resources such as ports and queues are partitioned amongst multiple OpenFlow Logical Switches such that each OpenFlow Logical Switch can assume full control over the resources that is assigned to it.
Network Intent Models
Figure 2 shows the basic abstractions detailed in OF-CONFIG and the lines indicate that the OpenFlow Configuration Points and OpenFlow Capable Switches communicate via OF-CONFIG. The configuration settings then take effect on targeted logical switch(es). OpenFlow Controllers and OpenFlow Logical Switches (i.e. datapaths) communicate via OpenFlow.
Figure 2
OF-CONFIG and OF-SWITCH
OF-CONFIG is considered a complementary protocol to the main OpenFlow switch specification (OF-SWITCH), The table below summarizes the key differences between OpenFlow and OF-CONFIG.
| OpenFlow | OF-CONFIG | |
|---|---|---|
| Primary purpose | Modification of match action rules effecting flows of network packets access an OpenFlow datapath | Remote configuration of possibly multiple OpenFlow datapaths on a physical or virtual platform |
| Terminology | OpenFlow Logical Switch | OpenFlow Capable Switch OpenFlow Configuration Point |
| Transport | TCP,TLS,SSL | XML data model bound to NETCONF |
| Protocol endpoint | 1) An OpenFlow Logic Switch (OFLS) 2) An OpenFlow Controller(OFC) | 1) An OpenFlow Capable Switch(OCS) 2) An OpenFlow Configuration Point(can be hosted on OFC) |
OF-CONFIG engine
It is worth mentioning that integrating OpenFlow Configuration Point in OpenFlow Controller is a convenient way to operate and deploy. In such scenario, OF-CONFIG can be treated as a new project to implement OF-CONFIG within OpenDaylight system, As described in Figure 3,
Figure 3
OF-CONFIG depends on the implementations of YANG Tools and Controller Project. The latest version OF-CONFIG protocol will be implemented on schedule. The OF-CONFIG will be notified the configuration changes by Data Store transaction, meanwhile it might provide MD-SAL API to the application so as to achieve some special configurations such as tunnel, controller IP address and the connection with external system (OpenStack ...). Parameters are configured on OpenFlow Capable Switch via OF-CONFIG Agent in OCS. The main works of OF-CONFIG project are: definition of YANG model for MD-SAL, implementation of OF-CONFIG model, interaction with NETCONF and Data Store. Figure 4 shows the a high-level view of the architecture. The figure has the some components (OF Config, OpenFlow Configuration Application, …), it shows details about the components' interactions with MD-SAL (and other components in the system) and how the APIs should be implemented. The figure also shows other relevant components in the system: the OF-Plugin and the FRM. OF-CONFIG uses Netconf Topology - it provides a lot of stuff the OF-CONFIG would have to implement. Similarly, it would be good if the OF-CONFIG can provide its functionality in a manner where it can be used not only by a single-purpose OpenFlow Configuration Application(OF-CONFIG APP), but also by apps that deal with flows and/or the OpenFlow protocol - such as the FRM. Inventory/topology monitoring the data changes in real-time. OF-CONFIG will be notified the changes of configuration for a specific OpenFlow Capable switch by inventory/topology Data Store transaction when data changes occur. Next, OF-CONFIG sends the configuration to the OpenFlow Capable switch via NETCONF.
Figure 4
Figue 5 shows the 3 typical operation types in one OF-Capable node - Query/Edit/Delete.
Figure 5
Dependency
The dependency graph of OF-CONFIG project and other related projects is as described in Figure 6.
Figure 6
Scope
While there are many modules and corresponding SBIs existed in OpenDayligh, this proposal provides another method to configure OpenFlow Capable Switch. The scope of this proposal includes:
- Design and develop consistent OF-CONFIG for intent networks.
- Model-to-model translation between the OpenFlow configuration model in MD-SAL inventory and the OF-CONFIG device model instances that are mounted in Netconf topology.
- Define OF-CONFIG YANG model in MD-SAL.
Resources Committed (developers committed to working)
- Yuehua Wei (wei.yuehua@zte.com.cn) Username: corona.wei
- Wei Meng (meng.wei2@zte.com.cn) Username: valley
- Ran Chen (chen.ran@zte.com.cn) Username: ranchen6
- Rui Hu (hu.rui2@zte.com.cn) Username: hu.rui
- Hui Xu (xu.hui7@zte.com.cn) Username: susanxu711
- Rui Zhang (zhang.rui65@zte.com.cn) Username: zhang.rui
- Xiang Huang (huang.xiang2@zte.com.cn) Username: hxfirefox
- Xutao Yu (yu.xutao@zte.com.cn) Username: yuxutao
- Deepak Bansal (dbansal@microsoft.com) Username: DeepakBansal
- Maros Marsalek (mmarsale@cisco.com) Username: mmarsale
- Anantha Ramaiah (anantha.ramaiah@ericsson.com) Username: anantha05
- Yifeng Bee (bi.yifeng@zte.com.cn) Username: yifeng
Initial Committers
- Yuehua Wei (wei.yuehua@zte.com.cn) Username: corona.wei
- Wei Meng (meng.wei2@zte.com.cn) Username: valley
- Ran Chen (chen.ran@zte.com.cn) Username: ranchen6
- Rui Hu (hu.rui2@zte.com.cn) Username: hu.rui
- Hui Xu (xu.hui7@zte.com.cn) Username: susanxu711
- Rui Zhang (zhang.rui65@zte.com.cn) Username: zhang.rui
- Xiang Huang (huang.xiang2@zte.com.cn) Username: hxfirefox
- Xutao Yu (yu.xutao@zte.com.cn) Username: yuxutao
- Deepak Bansal (dbansal@microsoft.com) Username: DeepakBansal
- Maros Marsalek (mmarsale@cisco.com) Username: mmarsale
- Anantha Ramaiah (anantha.ramaiah@ericsson.com) Username: anantha05
- Yifeng Bee (bi.yifeng@zte.com.cn) Username: yifeng
Vendor Neutral
- No vendor package names in code
- No vendor branding present in code or output of build
- No vendor branding present in documentation