Open vSwitch系列之openflow版本兼容
作者：互联网
众所周知Open vSwitch支持的openflow版本从1.0到1.5版本（当前Open vSwitch版本是2.3.2）通过阅读代码，处理openflow协议的入口函数是openflow_handle__(一看命名就知道这个是老外写的，因为老外比较喜欢用handle这个单词)。当我看到这个函数后，和我想象中处理不太一样，我个人想法应该会有各种版本号判断，然而实际上却没有而只有switch-case，那么Open vSwitch是如何做到不同协议版本的兼容呢？
为了弄清楚这个问题，我大概花了三四天时间，终于揭开了版本兼容面纱—raw这个结构。因此今天来分析一下raw这个结构体。
在介绍之前，说明一下Open vSwitch代码风格，函数名字凡是以两个下划线结尾(__)，都是静态函数，并且是真正逻辑处理函数。
我们开始步入正题吧，还是以往的形式，所有解释说明都在代码注释中，除非特别需要强调的才会单独摘出来进行补充说明。
/*
* openflow协议处理入口函数 为了节省篇幅删除一些case语句。
*/
static enum ofperr
handle_openflow__(struct ofconn *ofconn, const struct ofpbuf *msg)
OVS_EXCLUDED(ofproto_mutex)
{
const struct ofp_header *oh = msg->data; /* 从ofpbuf获取数据 */
enum ofptype type;
enum ofperr error;
/* openflow协议头解码 这个函数是我们介绍重点 */
error = ofptype_decode(&type, oh);
if (error) {
return error;
}
if (oh->version >= OFP13_VERSION && ofpmsg_is_stat_request(oh)
&& ofpmp_more(oh)) {
/* We have no buffer implementation for multipart requests.
* Report overflow for requests which consists of multiple
* messages. */
return OFPERR_OFPBRC_MULTIPART_BUFFER_OVERFLOW;
}
/*
* 根据不同type进行不同处理消息
*/
switch (type) {
/* OpenFlow requests. */
case OFPTYPE_ECHO_REQUEST:
return handle_echo_request(ofconn, oh);
case OFPTYPE_PACKET_OUT: /* packet out消息 */
return handle_packet_out(ofconn, oh);
case OFPTYPE_PORT_MOD:
return handle_port_mod(ofconn, oh);
case OFPTYPE_FLOW_MOD:
return handle_flow_mod(ofconn, oh);
...
case OFPTYPE_BARRIER_REQUEST: /* barrier消息 没有做什么啊!! */
return handle_barrier_request(ofconn, oh);
case OFPTYPE_ROLE_REQUEST:
return handle_role_request(ofconn, oh);
case OFPTYPE_TABLE_STATS_REQUEST:
return handle_table_stats_request(ofconn, oh);
case OFPTYPE_TABLE_FEATURES_STATS_REQUEST:
return handle_table_features_request(ofconn, oh);
....
case OFPTYPE_HELLO:
case OFPTYPE_ERROR:
case OFPTYPE_FEATURES_REPLY:
case OFPTYPE_GET_CONFIG_REPLY:
case OFPTYPE_PACKET_IN: /* PACKET_IN消息 */
...
case OFPTYPE_METER_FEATURES_STATS_REPLY:
case OFPTYPE_TABLE_FEATURES_STATS_REPLY:
case OFPTYPE_ROLE_STATUS:
default:
if (ofpmsg_is_stat_request(oh)) {
return OFPERR_OFPBRC_BAD_STAT;
} else {
return OFPERR_OFPBRC_BAD_TYPE;
}
}
}
在进行函数分析之前，我觉得理解枚举定义是重点，只有充分理解这个枚举，才能理解下面解析流程。因此在这里我强烈建议读者：阅读一下代码中注释。下面对于枚举解释只是我个人理解，不保证是正确的。由于这个枚举定义很长，为了节省篇幅，这里只摘取典型类型。
由于openflow版本较多并且有些版本差异化比较大（我经常说openflow还很年轻！！），OpenvSwitch为了支持各个版本的差异化，的确花费了很多心思。所以OpenvSwitch定义了一系列的枚举，枚举格式是以OFPRAW_开始。在介绍各个枚举之前，我们先说一下注释内容，因为RAW注释对于我们理解代码非常有帮助。
我们在阅读代码的时候，会发现每个枚举类型的上方有类似的注释
/* OFPT <all> (0): uint8_t[]. */，
/* OFPT 1.0 (6): struct ofp_switch_features, struct ofp10_phy_port[]. */，
根据注释内容我知道，这些注释格式大体是这样的：type versions (number): arguments
就那上面例子来说吧，就会出现下面的表格：
那么我们来看一下type，version,arguments分别代表什么意思？这部分主要是翻译源代码中注释，网友可以自行查阅。
Type：有下面几种OFPT（标准openflow协议消息），OFPST（标准openflow统计消息），NXT（Nicira扩展消息），NXST（Nicira扩展统计消息）
Version：对应openflow协议版本号，如果是则表示消息在所有版本都是一样的，例如hello消息。如果“1.1+”表示从openflow的1.1版本(含)之后消息是相同的。
Number：理解不是很深入，只能通过代码注释得知是类型值。然而当我自己去匹配的时候，没有匹配成功。这个字段需要在再仔细分析一下。
Arguments：表示消息体具体类型。如果是void表示无消息体，如果uint8[]表示消息体是变长的。Argument存在多个时候，表示消息体可能里面类型它们中之一，这就要依据openflow版本号啦。 例如： /* OFPT 1.1-1.3 (12): struct ofp_port_status, struct ofp11_port. */表示消息体既可以是ofp_port_status，又可以是ofp11_port.
通过上面分析，可以得出下面两种枚举定义格式：
1)标准协议
OFPRAW_OFPT_ (OFPRAW_OFPT10_, OFPRAW_OFPT11_等)
OFPRAW_OFPST_ (OFPRAW_OFPST10_, OFPRAW_OFPST11_等)
2)Nicira扩展协议
OFPRAW_NXT_
OFPRAW_NXST_
通过上面类型的抽象，完成对openflow各个版本兼容，这个抽象过程非常重要，只有充分理解这个抽象过程，才能更好的理解处理流程。
enum ofperr
ofptype_decode(enum ofptype *typep, const struct ofp_header *oh)
{
enum ofperr error;
enum ofpraw raw; /* 枚举类型 */
error = ofpraw_decode(&raw, oh); /* 解析openflow消息头并保存在raw中 */
*typep = error ? 0 : ofptype_from_ofpraw(raw); /* 根据raw中返回类型 */
return error;
}
上面这个两个函数都很重要，下面我会对它们进行详细说明的。我们现在调整一下介绍顺序，这样能够方便理解：
ofpraw_pull函数中会调用右侧三个函数，所我们先来介绍这三个函数，这三个函数搞清楚了ofpraw_pull函数也就清楚了。
在介绍之前，我抓取两个报文，方便解释代码：
图1：feature_reply消息
图2：multipart_request消息
/*
* 解析openflow头部，如果存在子类型则会进一步解析，针对报文图2就会进一步解码。
* 参数1：出参
*/
static enum ofperr
ofphdrs_decode(struct ofphdrs *hdrs, const struct ofp_header *oh, size_t length)
{
memset(hdrs, 0, sizeof *hdrs);
if (length < sizeof *oh) {
return OFPERR_OFPBRC_BAD_LEN;
}
/* 获取基本消息版本号和类型，如果当前消息存在子类型就会进入if-else分支进一步解析子类型，反之直接退出。*/
hdrs->version = oh->version;
hdrs->type = oh->type;
/* 如果存在子类型就会进入if-else分支进一步解析，针对上面两种报文，图1不会进入任何一个分支，而图2则会进入else分支。为了节省篇幅，我们只针对常见消息进行解析—openflow1.3消息。 */
if (hdrs->type == OFPT_VENDOR) {//获取设备厂商信息
...
} else if (hdrs->version == OFP10_VERSION
&& (hdrs->type == OFPT10_STATS_REQUEST ||
hdrs->type == OFPT10_STATS_REPLY)) {//openflow1.0的消息，我们不关系
...
} else if (hdrs->version != OFP10_VERSION
&& (hdrs->type == OFPT11_STATS_REQUEST ||
hdrs->type == OFPT11_STATS_REPLY)) {/* 通过报文和代码中枚举类型可知，图2中报文会进入此分支。 */
const struct ofp11_stats_msg *osm;
/* Get statistic type (OFPST_*). */
if (length < sizeof *osm) {
return OFPERR_OFPBRC_BAD_LEN;
}
osm = (const struct ofp11_stats_msg *) oh;
hdrs->stat = ntohs(osm->type);/* 将子类型赋值到出参的stat中 */
if (hdrs->stat == OFPST_VENDOR) {/* 这个分支也是获取厂商信息 对于上面消息而言不会进入，我们这里忽略掉。 */
}
}
return 0;
}
这个函数我们就分析完了，我们来看一下这个函数：ofpraw_from_ofphdrs。
/*
* 通过上面函数得到hdrs（参数2）传入到这个函数中，以便获取raw。
*/
static enum ofperr
ofpraw_from_ofphdrs(enum ofpraw *raw, const struct ofphdrs *hdrs)
{
static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 1);
struct raw_instance *raw_hdrs;
uint32_t hash;
ofpmsgs_init();
hash = ofphdrs_hash(hdrs);/* 对参数2进行hash运算，然后在hash-map中查找 */
HMAP_FOR_EACH_WITH_HASH (raw_hdrs, hmap_node, hash, &raw_instance_map) {
if (ofphdrs_equal(hdrs, &raw_hdrs->hdrs)) {
*raw = raw_hdrs->raw;/* 返回找到raw类型 */
return 0;
}
}
/* 如果没有找则记录日志并且返回错误 */
if (!VLOG_DROP_WARN(&rl)) {
struct ds s;
ds_init(&s);
ds_put_format(&s, "version %"PRIu8", type %"PRIu8,
hdrs->version, hdrs->type);
if (ofphdrs_is_stat(hdrs)) {
ds_put_format(&s, ", stat %"PRIu16, hdrs->stat);
}
if (hdrs->vendor) {
ds_put_format(&s, ", vendor 0x%"PRIx32", subtype %"PRIu32,
hdrs->vendor, hdrs->subtype);
}
VLOG_WARN("unknown OpenFlow message (%s)", ds_cstr(&s));
ds_destroy(&s);
}
return (hdrs->vendor ? OFPERR_OFPBRC_BAD_SUBTYPE
: ofphdrs_is_stat(hdrs) ? OFPERR_OFPBRC_BAD_STAT
: OFPERR_OFPBRC_BAD_TYPE);
}
上面这个函数逻辑相对简单，我们主要看一下raw_instance_map组成结构，ofpmsgs_init这个函数是用于初始化raw_instance_map的。通过查看这个函数源代码又可知，这个hashmap的输入是这个结构raw_infos（ofp-msg.inc文件）。我们看一下这个定义，这是一个结构体数组：static struct raw_info raw_infos[] = {...}。我们分析一下这个结构体定义：
/* Information about a particular 'enum ofpraw'. */
struct raw_info {
/* All possible instantiations of this OFPRAW_* into OpenFlow headers. */
struct raw_instance *instances; /* 这个是一个数组，其数组大小是min_version - max_version + 1. */
uint8_t min_version; /* 当前实例支持的最小版本号 最小是1*/
uint8_t max_version; /* 当前实例支持的最大版本号 最大是255*/
unsigned int min_body; /* 消息体最小大小 */
unsigned int extra_multiple;/* 这个字段不是很明白是什么意思 */
enum ofptype type;/* openflow消息类型，例如OFPTYPE_HELLO，OFPTYPE_PACKET_IN等 */
const char *name;/* 字符描述 */
};
/* A mapping from OpenFlow headers to OFPRAW_*. */
struct raw_instance {
struct hmap_node hmap_node; /* In 'raw_instance_map'. Hash节点*/
struct ofphdrs hdrs; /* Key. Hash-key*/
enum ofpraw raw; /* Value. */
unsigned int hdrs_len; /* ofphdrs_len(hdrs). */
};
我们来分析两个两个消息，一个是hello消息，一个是flow_mod消息。
static struct raw_info raw_infos[] = {
{
ofpraw_ofpt_hello_instances, /* 实例定义 */
1, 255,/* 最小版本号1说明hello消息是从openflow1.0开始， 最大版本号是255说明，这个hello消息在各个版本中都支持。*/
#line 109 "./lib/ofp-msgs.h"
0,/* 最小消息体长度是0，表明没有消息体 */
#line 109 "./lib/ofp-msgs.h"
sizeof(uint8_t),
#line 1620 "lib/ofp-msgs.inc"
OFPTYPE_HELLO,/* openflow消息类型，消息类型是hello消息 */
"OFPT_HELLO", /* 字符描述 */
},
...
{
ofpraw_ofpt10_flow_mod_instances,/* openflow1.0中flow_mod */
1, 1, /* 最小和最大版本号都是1，表明这个flow_mod消息支持1.0 */
#line 175 "./lib/ofp-msgs.h"
sizeof(struct ofp10_flow_mod),
#line 175 "./lib/ofp-msgs.h"
sizeof(uint8_t[8]),
#line 1884 "lib/ofp-msgs.inc"
OFPTYPE_FLOW_MOD,
"OFPT_FLOW_MOD",
},
{
ofpraw_ofpt11_flow_mod_instances, /* openflow1.1协议中flow_mod */
2, 6, /* 最小版本号是2，最大版本号是6，表明这个flow_mod支持openflow1.1到openflow1.5。 */
#line 177 "./lib/ofp-msgs.h"
sizeof(struct ofp11_flow_mod),/* 标准openflow中flow_mod结构大小 */
#line 177 "./lib/ofp-msgs.h"
sizeof(struct ofp11_instruction), /*扩展结构，即instruction结构*/
#line 1895 "lib/ofp-msgs.inc"
OFPTYPE_FLOW_MOD,
"OFPT_FLOW_MOD",
},
}
我们再来看一下ofpraw_ofpt11_flow_mod_instances的定义:
static struct raw_instance ofpraw_ofpt11_flow_mod_instances[] = {
{ {0, NULL}, {2, 14, 0, 0x0, 0}, OFPRAW_OFPT11_FLOW_MOD, 0 },
{ {0, NULL}, {3, 14, 0, 0x0, 0}, OFPRAW_OFPT11_FLOW_MOD, 0 },
{ {0, NULL}, {4, 14, 0, 0x0, 0}, OFPRAW_OFPT11_FLOW_MOD, 0 },
{ {0, NULL}, {5, 14, 0, 0x0, 0}, OFPRAW_OFPT11_FLOW_MOD, 0 },
{ {0, NULL}, {6, 14, 0, 0x0, 0}, OFPRAW_OFPT11_FLOW_MOD, 0 },
};
其中红色字体就是函数ofpraw_from_ofphdrs最终返回的raw类型,数组大小是6-2+1=5。
下面这个两个函数就是根据返回的raw，获取对应实例raw_instance，在定义的时候成员变量hdrs_len，定义成0。当在初始化hashmap的时候，会对这个成员进行初始化，可以参考函数ofpmsgs_init。
static const struct raw_info *
raw_info_get(enum ofpraw raw)
{
ofpmsgs_init();/* 这个函数只会被调用一次。 */
ovs_assert(raw < ARRAY_SIZE(raw_infos));
return &raw_infos[raw]; /* 返回raw_info */
}
static struct raw_instance *
raw_instance_get(const struct raw_info *info, uint8_t version)
{
ovs_assert(version >= info->min_version && version <= info->max_version);
return &info->instances[version - info->min_version];/* 返回raw_instance */
}
有了这个上面分析基础，我们再回过头来看一下这个最外部函数ofpraw_pull。
enum ofperr
ofpraw_pull(enum ofpraw *rawp, struct ofpbuf *msg)
{
static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
const struct raw_instance *instance;
const struct raw_info *info;
struct ofphdrs hdrs;
unsigned int min_len;
unsigned int len;
enum ofperr error;
enum ofpraw raw;
/* Set default outputs. */
msg->header = msg->data;
msg->msg = msg->header;
*rawp = 0;
len = msg->size;
error = ofphdrs_decode(&hdrs, msg->data, len);/* 解析openflow头部消息 保存在hdrs中 */
if (error) {
return error;
}
error = ofpraw_from_ofphdrs(&raw, &hdrs); /* 根据hdrs，从hmap中获取raw */
if (error) {
return error;
}
/* 获取实例对象 */
info = raw_info_get(raw);
instance = raw_instance_get(info, hdrs.version);
/* 根据实例对象配置，进行数据分割。 */
msg->header = ofpbuf_pull(msg, instance->hdrs_len);
msg->msg = msg->data;
min_len = instance->hdrs_len + info->min_body;
switch (info->extra_multiple) {
case 0:
if (len != min_len) {
VLOG_WARN_RL(&rl, "received %s with incorrect length %u (expected "
"length %u)", info->name, len, min_len);
return OFPERR_OFPBRC_BAD_LEN;
}
break;
case 1:
if (len < min_len) {
VLOG_WARN_RL(&rl, "received %s with incorrect length %u (expected "
"length at least %u bytes)",
info->name, len, min_len);
return OFPERR_OFPBRC_BAD_LEN;
}
break;
default:
if (len < min_len || (len - min_len) % info->extra_multiple) {
VLOG_WARN_RL(&rl, "received %s with incorrect length %u (must be "
"exactly %u bytes or longer by an integer multiple "
"of %u bytes)",
info->name, len, min_len, info->extra_multiple);
return OFPERR_OFPBRC_BAD_LEN;
}
break;
}
*rawp = raw; /* 返回从实例中获取raw类型。 */
return 0;
}
通过上面这一系列的分析，我们梳理清楚raw是怎么操作的，下面我们返回到这个最开始的函数：
enum ofperr
ofptype_decode(enum ofptype *typep, const struct ofp_header *oh)
{
enum ofperr error;
enum ofpraw raw; /* 枚举类型 */
error = ofpraw_decode(&raw, oh); /* 解析openflow消息头并保存在raw中 */
*typep = error ? 0 : ofptype_from_ofpraw(raw); /* 根据raw中返回类型 */
return error;
}
我们现在看一下函数ofptype_from_ofpraw，这个函数也非常简单，我们跟踪代码可以得知，返回来的类型，其实就是文件ofp-msg.inc中定义的数组结构体struct raw_info raw_infos，里面某个成员（raw是数组下标）。
这样我们就比较清楚的梳理出，openvswitch是如何进行各个版本兼容的。我们总结一下：
1、OpenvSwitch版本兼容核心技巧，在于这个数组定义，raw_info raw_infos，其中min_version，max_version是关键，通过这个两个变量做到了版本兼容。
2、虽然版本能做到兼容，但是各个版本还有差异，那么Open vSwitch是如何做到呢？是通过raw_instance数组定义，也是定义在文件Ofp-msgs.inc中。
只有充分理解上面这个两个数组，我们就能清楚知道Open vSwitch是何如做到版本兼容，当我们基于Open vSwitch进行二次开发的时候，就能够知道在哪些地方增加对应的消息啦。
标签：info,return,struct,openflow,len,raw,vSwitch,Open,hdrs 来源： https://blog.51cto.com/u_15127681/2821682