众所周知Open vSwitch支持的openflow版本从1.0到1.5版本(当前Open vSwitch版本是2.3.2)通过阅读代码,处理openflow协议的入口函数是openflow_handle__(一看命名就知道这个是老外写的,因为老外比较喜欢用handle这个单词)。当我看到这个函数后,和我想象中处理不太一样,我个人想法应该会有各种版本号判断,然而实际上却没有而只有switch-case,那么Open vSwitch是如何做到不同协议版本的兼容呢?
为了弄清楚这个问题,我大概花了三四天时间,终于揭开了版本兼容面纱—raw这个结构。因此今天来分析一下raw这个结构体。
在介绍之前,说明一下Open vSwitch代码风格,函数名字凡是以两个下划线结尾(__),都是静态函数,并且是真正逻辑处理函数。
我们开始步入正题吧,还是以往的形式,所有解释说明都在代码注释中,除非特别需要强调的才会单独摘出来进行补充说明。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 |
/* * 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注释对于我们理解代码非常有帮助。
我们在阅读代码的时候,会发现每个枚举类型的上方有类似的注释
1 2 |
/* 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协议版本号,如果是
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各个版本兼容,这个抽象过程非常重要,只有充分理解这个抽象过程,才能更好的理解处理流程。
1 2 3 4 5 6 7 8 9 10 |
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消息
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 |
/* * 解析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[] = {...}。我们分析一下这个结构体定义:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 |
/* 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的定义:
1 2 3 4 5 6 7 |
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。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
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。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 |
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是怎么操作的,下面我们返回到这个最开始的函数:
1 2 3 4 5 6 7 8 9 10 |
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进行二次开发的时候,就能够知道在哪些地方增加对应的消息啦。
作者简介:
徐小冰:毕业于河北大学,主要从事嵌入式软件开发,虚拟化,SDN。目前基于ODL和Open vSwitch进行二次开发,希望与广大网友一起探讨学习。作者系OpenDaylihgt群(194240432)资深活跃用户,@IT难人。