Open vSwitch系列之openflow版本兼容

时间:2022-05-06
本文章向大家介绍Open vSwitch系列之openflow版本兼容,主要内容包括图1:feature_reply消息、图2:multipart_request消息、基本概念、基础应用、原理机制和需要注意的事项等,并结合实例形式分析了其使用技巧,希望通过本文能帮助到大家理解应用这部分内容。

众所周知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进行二次开发的时候,就能够知道在哪些地方增加对应的消息啦。