CN113132270B

CN113132270B - 基于虚拟交换机的多协议兼容的数据交互方法及装置

Info

Publication number: CN113132270B
Application number: CN202110265711.1A
Authority: CN
Inventors: 李保平; 孙梁; 刘步荣; 刘磊
Original assignee: Nanjing Xingtian Network Technology Co ltd
Current assignee: Guangzhou Huitong Guoxin Technology Co ltd
Priority date: 2021-03-11
Filing date: 2021-03-11
Publication date: 2022-07-15
Anticipated expiration: 2041-03-11
Also published as: CN113132270A

Abstract

本发明公开了基于虚拟交换机的多协议兼容的数据交互方法及装置，所述方法包括以下步骤：S100，获取设置在智能变电站的站控层的虚拟交换机中的汇总报文信息；S200，根据虚拟交换机中预设的匹配域字段将所述汇总报文信息中的各类报文信息分离出来；S300，分别对分离出来的各类报文信息进行消息解析得到消息解析的结果；S400，根据消息解析的结果进行显示输出等相关应答处理。通过对虚拟交换机的控制域进行定义进而能够从虚拟交换机接收到的各类报文中将各类报文尤其是GOOSE报文分离出来并进行相应的应答处理，能够使虚拟交换机实现多协议兼容，进而满足电网的业务需求。

Description

基于虚拟交换机的多协议兼容的数据交互方法及装置

技术领域

本公开涉及数据通信技术领域，具体涉及基于虚拟交换机的多协议兼容的数据交互方法及装置。

背景技术

目前智能变电站采用开放式分层分布式网络结构，由站控层、间隔层、过程层以及网络设备构成。站控层与间隔层之间的网络称为站控层网络，间隔层和过程层之间的网络称为过程层网络，即所谓的“三层两网”结构。

MMS报文：采用TCP协议进行报文传输，远动或后台与IED设备建立连接前需要先发送ARP报文(广播)查询对方的MAC地址，当得到对方的应答并获取MAC地址后开始发送MMS信息报文。ARP报文发送间隔一般为20min。MMS报文长度最小为64byte，最大为交换机能够传输的最大长度1518byte或各种装置控制的最大长度(必须小于交换机能够传输的最大报文长度，否则将会直接被丢弃，导致装置间连接中断)。一般变电站内的MMS报文流量小于10Mbps。

GOOSE报文：GOOSE报文为组播报文，发送频率较低，一般为几秒钟发送一包报文，当有突发变位等信息上送时，发送间隔最小为1ms一包报文。GOOSE报文的报文长度理论上为64byte～1518byte之间。正常情况下一路GOOSE报文的流量基本可以忽略不计，当发生雪崩情况下一路GOOSE的流量可以达到10Mbps左右，对网络上的瞬时冲击非常大。以此，在与SV等信息共网时应充分考虑GOOSE报文的这一特性。防止GOOSE的雪崩对SV等报文的传输带来不利影响。

SV报文：SV报文为组播报文，每250us发送一包报文，SV报文长度在实际工程中一般在200byte～300byte之间，因此，一路SV报文的流量在6Mbps～10Mbps之间。SV报文流量以恒定速率发送，没有突发报文流量。

1588报文：为PTP对时报文，包括sync、followup、announce、Pdelayrequest、Pdelayrespond报文等组成，报文发送间隔一般可以在秒级范围内调节。平均报文流量在几Kbps，对整体网络流量的影响可以忽略不计。

对于MMS报文以及1588报文现有技术在虚拟交换机OVS的应用中已经存在对应的匹配域以进行报文分离处理操作，但是GOOSE报文以及SV报文目前仍没有较佳的解决方案。

发明内容

本公开提供基于虚拟交换机的多协议兼容的数据交互方法及装置，以解决现有技术中所存在的一个或多个技术问题，至少提供一种有益的选择或创造条件。

为了实现上述目的，根据本公开的一方面，提供基于虚拟交换机的多协议兼容的数据交互方法，所述方法包括以下步骤：

S100，获取设置在智能变电站的站控层的虚拟交换机中的汇总报文信息；

S200，根据虚拟交换机中预设的匹配域字段将所述汇总报文信息中的各类报文信息分离出来；

S300，分别对分离出来的各类报文信息进行消息解析得到消息解析的结果；

S400，根据消息解析的结果进行显示输出等相关应答处理。

进一步，所述汇总报文信息包括MMS报文、GOOSE报文、SV报文以及1588报文，上述步骤S200中GOOSE报文的匹配域字段的预设方法具体包括以下，

对匹配域进行定义，在虚拟交换机的meta-flow.h中mf_field_id结构中，新增MFF_GOOSE_APPID字段，meta-flow.xml中增加GOOSE_APPID信息。

进一步，上述步骤S300中分别对分离出来的各类报文信息进行消息解析得到消息解析的结果具体包括以下步骤，

S310，虚拟交换机从flow_mod消息中提取出匹配域，查找到mf_field，在通过各域的依赖性检测、重复性检测以及有效性检测后，得到最终的匹配结果插入原生的虚拟交换机的流表中；

S320，用户侧在完成flow_mod的匹配域解析后，进行流表添加、删除等操作；

S330，数据包进入交换机，在内核层datapath进行流表项匹配，匹配失败或匹配到的action为发向用户空间，去用户层继续查找匹配，在用户侧匹配成功的数据包会按照表项action相应处理，并向内核下发匹配到的流表项，方便以后类似数据包直接在内核层完成匹配转发。

进一步，上述步骤S310中查找mf_field具体包括以下，

flow_mod匹配域中解析出TLV格式的OXM，通过header，在匹配域哈希表ofproto->vl_mff_map中做hash查找，找到对应的mf_field结构体。

进一步，上述步骤S310中的有效性检测具体通过在mf_is_value_valid函数中增加goose_appid处理实现，依赖性检测具体通过在meta-flow.h文件的mf_prereqs结构中添加MFP_GOOSE_APPID信息，在Packets.h以及Ethernet.h文件中定义GOOSE报文的以太类型0x88b8以及在mf_are_prereqs_ok__函数中增加goose_appid处理，重复性检测具体通过在mf_is_all_wild函数中增加goose_appid处理，相应的在mf_set、mf_set_value、mf_set_wild函数中增加goose_appid处理。

进一步，上述步骤S330具体包括以下，

虚拟交换机收到数据包，解析包头字段，组成key，根据key在流表中进行匹配查找，查询key的数据结构为sw_flow_key，添加goose_appid信息，新增skb_reset_goose_header函数，从数据包中提取gooseheader结构信息，key_extract函数中，新增goose_appid处理，从gooseheader获取goose_appid，赋值给sw_flow_key，根据key在流表中匹配查找，

上送用户流程具体包括以下：

上送用户层时(主要在queue_userspace_packet函数中)，会构造上送数据包user_skb(sk_buf结构体)，然后通过genericnetlink通信机制上交给用户层，upcall_msg_size--虚拟交换机_key_attr_size，分配上送数据包长度，增加goose_appid的长度，上送数据包user_skb中key包含匹配字段，--虚拟交换机_nla_put_key函数中增加goose_appid处理，enum虚拟交换机_key_attr匹配域数据类型中新增goose_appid内容。

进一步，在用户侧收到内核发来的包后，从包中提取flow信息，从报文的key中提取信息组成flow的处理odp_flow_key_to_flow__函数，添加goose_appid处理，miniflow_extract函数增加goose_appid处理。

进一步，上述步骤S300中分别对分离出来的各类报文信息进行消息解析得到消息解析的结果具体包括以下，

在odp_key_to_dp_packet函数中添加goose_appid处理，在structattr_len_tbl虚拟交换机_flow_key_attr_lens数据结构，添加goose_appid信息，并通过在虚拟交换机_key_attr结构体中增加goose_appid信息，虚拟交换机_key_lens结构体中增加goose_appid长度信息，虚拟交换机_key_from_nlattrs提取key和mask函数中，增加提取goose_appid处理，match_validate有效性检查函数中，增加goose_appid处理，虚拟交换机_key_attr_size计算key长度的函数中，增加goose_appid长度2字节，--虚拟交换机_nla_put_key组回包的key函数中，增加goose_appid处理以完成内核层flowrule插入和packet执行，在进行解析时，虚拟交换机收到flow_stats_request消息时解析报文，从rule中获取match、actions信息，组包回flow_stats_reply应答报文。

进一步，上述步骤S400中根据消息解析的结果进行显示输出等相关应答处理具体包括以下，在flow_format函数中增加goose信息处理，flow_wildcards_init_for_packet函数中增加goose信息处理，match_format函数中增加goose信息处理，format_odp_key_attr__函数中增加goose信息处理，mf_set_flow_value函数中增加goose信息处理，parse_odp_key_mask_attr__函数中增加goose信息处理。

本发明还提出基于虚拟交换机的多协议兼容的数据交互装置，所述装置包括：存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序运行在以下装置的单元中：

报文信息获取模块，用于获取设置在智能变电站的站控层的虚拟交换机中的汇总报文信息；

报文信息分离模块，用于根据虚拟交换机中预设的匹配域字段将所述汇总报文信息中的各类报文信息分离出来；

报文信息解析模块，用于分别对分离出来的各类报文信息进行消息解析得到消息解析的结果；

报文信息应答模块，用于根据消息解析的结果进行显示输出等相关应答处理。

本公开的有益效果为：本发明提供基于虚拟交换机的多协议兼容的数据交互方法及装置，通过对虚拟交换机的控制域进行定义进而能够从虚拟交换机接收到的各类报文中将各类报文尤其是GOOSE报文分离出来并进行相应的应答处理，能够使虚拟交换机实现多协议兼容，进而满足电网的业务需求。

附图说明

通过对结合附图所示出的实施方式进行详细说明，本公开的上述以及其他特征将更加明显，本公开附图中相同的参考标号表示相同或相似的元素，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图，在附图中：

图1所示为基于虚拟交换机的多协议兼容的数据交互方法的流程图；

图2所示为基于虚拟交换机的多协议兼容的数据交互方法的匹配处理流程图；

图3所示为基于虚拟交换机的多协议兼容的数据交互方法的flow_mod消息解析流程图；

图4所示为基于虚拟交换机的多协议兼容的数据交互方法的数据包匹配流程图。

具体实施方式

以下将结合实施例和附图对本公开的构思、具体结构及产生的技术效果进行清楚、完整的描述，以充分地理解本公开的目的、方案和效果。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

如图1所示为根据本公开的基于虚拟交换机的多协议兼容的数据交互方法的流程图，下面结合图1来阐述根据本公开的实施方式的基于虚拟交换机的多协议兼容的数据交互方法。

本公开提出基于虚拟交换机的多协议兼容的数据交互方法，所述方法包括以下步骤：

S400，根据消息解析的结果进行显示输出等相关应答处理。

作为本发明的优选实施方式，所述汇总报文信息包括MMS报文、GOOSE报文、SV报文以及1588报文，上述步骤S200中GOOSE报文的匹配域字段的预设方法具体包括以下，

GOOSE报文，二层广播报文，是一种特殊的以太报文，要识别到APPID，所以要增加APPID作为匹配域字段。

SV报文和GOOSE报文结构相同，仅DMAC和EthType具体值不同，可参考GOOSE报文处理。

GOOSE帧格式见下表：

采样报文帧格式见下表：

对虚拟交换机进行模块间分析

OpenFlow 1.2版本发展为下发规则的匹配字段不再通过固定长度的结构来定义，而是采用了TLV结构定义匹配字段，称为OXM(OpenFlow Extensible Match)，这样用户就可以灵活的下发自己的匹配字段。

OpenFlow 1.3流表支持的匹配关键字已经增加到40个，足以满足现有网络应用的需要。OpenFlow 1.3主要还增加了Meter表，用于控制关联流表的数据包的传送速率，但控制方式目前还相对简单。OpenFlow 1.3还改进了版本协商过程，允许交换机和控制器根据自己的能力协商支持的OpenFlow协议版本。

OVS的匹配域是基于OpenFlow协议的，添加一个新的匹配域，要延续OF协议定义一个匹配域的逻辑，这样新匹配域才能和已定义的匹配域兼容起来，同时保证OVS的匹配处理逻辑不发生改变。

新增的匹配域采用OXM格式，即TLV格式，RYU控制器和OVS协商OpenFlow

版本要1.3版本及以上。RYU通过flow_mod消息，OXM格式，带goose_appid匹配域给OVS。

新增GOOSE_APPID，具体Match字段填充，分析如下：

Match

Type：OFPMT_OXM(1)

Length：11字节(type_2+length_4+oxm_class_1+oxm_field+hasmask(1)+oxm_length_1+value_2＝11bytes，goose_appid占2字节)

OXM field

Class：OFPXMC12_OPENFLOW_BASIC(0x8000)

Field:MFF_GOOSE_APPID

Has mask:false

Length:2

Value:0x1122(goose_appid字段的值)

ovs-ofctl模块

ovs-ofctl解析命令/组包发送

ovs-ofctl命令中增加goose_appid作为match字段，解析用户输入的命令行字符串，提取match和action，采用OXM格式，即TLV格式，组包发送flow_mod消息。

设置网桥：ovs-ofctl set Bridge br0 protocols＝OpenFlow13

增加流表：

ovs-ofctl add-flow br0 dl_type＝0x88b8,goose_appid＝0x1122,actions＝output:2

修改流表:

ovs-ofctl mod-flows br0 dl_type＝0x88b8,goose_appid＝0x1122,actions＝output:2

删除流表：ovs-ofctl del-flows br0

函数入口：

Ovs-ofctl.c中static const struct ovs_cmdl_command all_commands[]＝

ofctl_add_flow

ofctl_mod_flows

ofctl_del_flows

函数处理流程和说明如下：

修改点如下：

ofp_parse_protocol函数增加GOOSE match字段处理。

match_set_packet_type,enum packet_type包类型，添加GOOSE报文的Ethtype类型。

ofputil_normalize_match函数增加GOOSE match字段处理。

ofputil_match_to_ofp11_match函数，ofp11_match结构，ofp11_flow_wildcards结构中，有match字段处理，是1.1版本，OXM模式至少要1.2版本，不增加GOOSE信息。

nx_put_raw函数设置OXM的TLV信息，增加GOOSE信息。

struct flow结构中增加goose_appid信息。

ovs-ofctl显示match字段

ovs-ofctl dump命令的显示信息中有goose_appid字段。

ovs-ofctl解析用户输入，组包发送flow_stats_request消息，收到应答消息后，提取信息显示。

显示流表：ovs-ofctl dump-flows br0

cookie＝0x0,duration＝616761.793s,table＝0,n_packets＝0,n_bytes＝0,dl_type＝0x88b8goose_appid＝0x1122 actions＝output:peer1

函数入口：

Ovs-ofctl.c中static const struct ovs_cmdl_command all_commands[]＝ofctl_dump_flows

Ofp-flow.h中

请求消息结构：ofputil_flow_stats_request

应答消息结构：ofputil_flow_stats

函数处理流程和说明如下：

修改函数：

mf_are_prereqs_ok__、mf_are_prereqs_ok函数，根据mf->prereqs，获取dl_type，添加goose的ethtype。

mf_set函数，根据mf_field，设置match的value和mask，增加goose信息处理。

mf_is_value_valid函数，判断value有效性，增加goose_appid信息。

mf_is_all_wild函数，根据mf_field，返回掩码信息，添加goose_appid信息。

mf_get_value函数，根据mf_field，获取mf_value，添加goose_appid信息。

match_format函数，match字段的显示输出，添加goose_appid信息。

打印函数：

ofp_print_flow_stats_request、ofp_print_flow_stats_reply，处理match信息，调用match_format函数。

参照图2，

ovs-vswitchd模块：

1、匹配域定义

2、flow_mod解析

3、用户层表项插入

5、Upcall接收和分类

6、用户层查找匹配处理

7、表项和packet的下发操作

openvswitch模块：

4、内核层packet解析和匹配处理

8、内核层flow插入和packet执行

域匹配定义

meta-flow.h中mf_field_id结构中，新增MFF_GOOSE_APPID字段。meta-flow.xml中增加GOOSE_APPID信息。

flow_mod消息解析

参照图3，OVS从flow_mod消息中提取出匹配域，查找到mf_field，一系列检测正确后，插入原生的OVS流表中。

Match结构如下：

在struct flow流表结构中增加goose_appid匹配字段。FLOW_WC_SEQ宏修改，全代码FLOW_WC_SEQ进行修改。

flow_mod匹配域中解析出OXM(TLV格式)，通过header，在匹配域哈希表ofproto->vl_mff_map中做hash查找，找到对应的mf_field结构体。

mf_field是OVS已申明定义好的匹配域信息集合，包含依赖性，名字，长度等信息，这些可以对分割出来的字段进行检验。

flow_mod处理总体流程相关函数：

说明	函数
		消息处理总入口	handle_single_part_openflow
flow_mod消息处理	handle_flow_mod
		解析flow_mod报文	ofputil_decode_flow_mod(A)
添加流表	handle_flow_mod__

flow_mod报文处理函数具体入参信息：

flow_mod报文解析流程相关函数：

flow_mod提取、校验和赋值相关函数：

查找mf_field:

mf_from_oxm_header函数具体分析：

a)在nxm_header_map中查header相等的nxm_field。

b)根据nxm_field中的id，在ofproto->vl_mff_map中匹配，获取mf_field.

在meta-flow.h文件，mf_field_id中添加goose_appid信息。build-aux/extract-ofp-fields文件根据meta-flow.h生成nxm_header_map和vl_mff_map信息。

有效性检测：

在mf_is_value_valid函数中增加goose_appid处理。

依赖性检测：

meta-flow.h文件的mf_prereqs结构中添加MFP_GOOSE_APPID信息。

Packets.h和Ethernet.h文件中定义GOOSE报文的以太类型，#define ETH_TYPE_GOOSE 0x88b8mf_are_prereqs_ok__函数中增加goose_appid处理。

重复性检测：

mf_is_all_wild函数中增加goose_appid处理。

设置match

mf_set、mf_set_value、mf_set_wild函数中增加goose_appid处理。

用户层表项插入

用户侧完成flow_mod的匹配域解析后，进行流表添加、删除等操作，这里对一个新字段无需改源码。

内核层Packet解析和匹配处理

参照图4，数据包进入交换机，在内核层datapath进行流表项匹配，匹配失败或匹配到的action为发向用户空间，去用户层继续查找匹配。在用户侧匹配成功的数据包会按照表项action相应处理，并向内核下发匹配到的流表项，方便以后类似数据包直接在内核层完成匹配转发。

收包匹配查找流程分析：

OVS收到数据包，解析包头字段，组成key，根据key在流表中进行匹配查找。

查询key的数据结构为sw_flow_key，添加goose_appid信息。

新增skb_reset_goose_header函数，从数据包中提取goose header结构信息。

key_extract函数中，新增goose_appid处理，从goose header获取goose_appid，赋值给sw_flow_key.

根据key在流表中匹配查找，不涉及代码修改。

上送用户流程分析：

上送用户层时(主要在queue_userspace_packet函数中)，会构造上送数据包user_skb(sk_buf结构体)，然后通过generic netlink通信机制上交给用户层。

upcall_msg_size--ovs_key_attr_size，分配上送数据包长度，增加goose_appid的长度。

上送数据user_skb中key包含匹配字段，__ovs_nla_put_key函数中增加goose_appid处理。

enum ovs_key_attr匹配域数据类型中新增goose_appid内容。

upcall接收和分类

用户侧接收内核包总处理流程，相关函数：

用户侧收到内核发来的包后，从包中提取flow信息：

从报文的key中提取信息组成flow的处理odp_flow_key_to_flow__函数，添加goose_appid处理。

miniflow_extract函数增加goose_appid处理。

用户层查找匹配处理

匹配查找流程process_upcall—>upcall_xlate--xlate_actions—>rule_dpif_lookup_from_table,不涉及代码修改。

flow rule和packet下发操作

odp_key_to_dp_packet函数，添加goose_appid处理。

struct attr_len_tbl ovs_flow_key_attr_lens数据结构，添加goose_appid信息。

内核层flow rule插入和packet执行

ovs_key_attr结构体中增加goose_appid信息。

ovs_key_lens结构体中增加goose_appid长度信息。

ovs_key_from_nlattrs提取key和mask函数中，增加提取goose_appid处理。

match_validate有效性检查函数中，增加goose_appid处理。

ovs_key_attr_size计算key长度的函数中，增加goose_appid长度2字节。

__ovs_nla_put_key组回包的key函数中，增加goose_appid处理。

flow_stats_request消息解析

OVS收到flow_stats_request消息，解析报文，从rule中获取match、actions信息，组包回flow_stats_reply应答报文。

说明	函数
			ofputil_append_flow_stats_reply
大包中设置match，见3.1.1分析修改	oxm_put_match--nx_put_raw
		大包中设置action	ofpacts_put_openflow_instructions

显示输出相关处理

flow_format函数，增加goose信息处理。

flow_wildcards_init_for_packet函数，增加goose信息处理。

match_format函数，增加goose信息处理。

format_odp_key_attr__函数，增加goose信息处理。

mf_set_flow_value函数，增加goose信息处理。

parse_odp_key_mask_attr__函数，增加goose信息处理。

所述基于虚拟交换机的多协议兼容的数据交互装置可以运行于桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备中。所述基于虚拟交换机的多协议兼容的数据交互装置，可运行的装置可包括，但不仅限于，处理器、存储器。本领域技术人员可以理解，所述例子仅仅是基于虚拟交换机的多协议兼容的数据交互装置的示例，并不构成对基于虚拟交换机的多协议兼容的数据交互装置的限定，可以包括比例子更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述基于虚拟交换机的多协议兼容的数据交互装置还可以包括输入输出设备、网络接入设备、总线等。

所称处理器可以是中央处理单元(CentralProcessingUnit，CPU)，还可以是其他通用处理器、数字信号处理器(DigitalSignalProcessor，DSP)、专用集成电路(ApplicationSpecificIntegratedCircuit，ASIC)、现场可编程门阵列(Field-ProgrammableGateArray，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，所述处理器是所述基于虚拟交换机的多协议兼容的数据交互装置运行装置的控制中心，利用各种接口和线路连接整个基于虚拟交换机的多协议兼容的数据交互装置可运行装置的各个部分。

所述存储器可用于存储所述计算机程序和/或模块，所述处理器通过运行或执行存储在所述存储器内的计算机程序和/或模块，以及调用存储在存储器内的数据，实现所述基于虚拟交换机的多协议兼容的数据交互装置的各种功能。所述存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(SmartMediaCard,SMC)，安全数字(SecureDigital,SD)卡，闪存卡(FlashCard)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

尽管本公开的描述已经相当详尽且特别对几个所述实施例进行了描述，但其并非旨在局限于任何这些细节或实施例或任何特殊实施例，从而有效地涵盖本公开的预定范围。此外，上文以发明人可预见的实施例对本公开进行描述，其目的是为了提供有用的描述，而那些目前尚未预见的对本公开的非实质性改动仍可代表本公开的等效改动。

Claims

1.基于虚拟交换机的多协议兼容的数据交互方法，其特征在于，所述方法包括以下步骤：

S400，根据消息解析的结果进行显示输出的相关应答处理；

所述汇总报文信息包括MMS报文、GOOSE报文、SV报文以及1588报文，上述步骤S200中GOOSE报文的匹配域字段的预设方法具体包括以下，

2.根据权利要求1所述的基于虚拟交换机的多协议兼容的数据交互方法，其特征在于，上述步骤S300中分别对分离出来的各类报文信息进行消息解析得到消息解析的结果具体包括以下步骤，

S320，用户侧在完成flow_mod的匹配域解析后，进行流表添加、删除的操作；

3.根据权利要求2所述的基于虚拟交换机的多协议兼容的数据交互方法，其特征在于，上述步骤S310中查找mf_field具体包括以下，

4.根据权利要求3所述的基于虚拟交换机的多协议兼容的数据交互方法，其特征在于，上述步骤S310中的有效性检测具体通过在mf_is_value_valid函数中增加goose_appid处理实现，依赖性检测具体通过在meta-flow.h文件的mf_prereqs结构中添加MFP_GOOSE_APPID信息，在Packets.h以及Ethernet.h文件中定义GOOSE报文的以太类型0x88b8以及在mf_are_prereqs_ok__函数中增加goose_appid处理，重复性检测具体通过在mf_is_all_wild函数中增加goose_appid处理，相应的在mf_set、mf_set_value、mf_set_wild函数中增加goose_appid处理。

5.根据权利要求2所述的基于虚拟交换机的多协议兼容的数据交互方法，其特征在于，上述步骤S330具体包括以下，

上送用户流程具体包括以下：

上送用户层时在queue_userspace_packet函数中，会构造上送数据包user_skb，所述user_skb为sk_buf结构体，然后通过genericnetlink通信机制上交给用户层，upcall_msg_size--虚拟交换机_key_attr_size，分配上送数据包长度，增加goose_appid的长度，上送数据包user_skb中key包含匹配字段，--虚拟交换机_nla_put_key函数中增加goose_appid处理，enum虚拟交换机_key_attr匹配域数据类型中新增goose_appid内容。

6.根据权利要求5所述的基于虚拟交换机的多协议兼容的数据交互方法，其特征在于，在用户侧收到内核发来的包后，从包中提取flow信息，从报文的key中提取信息组成flow的处理odp_flow_key_to_flow__函数，添加goose_appid处理，miniflow_extract函数增加goose_appid处理。

7.根据权利要求1所述的基于虚拟交换机的多协议兼容的数据交互方法，其特征在于，上述步骤S300中分别对分离出来的各类报文信息进行消息解析得到消息解析的结果具体包括以下，

8.根据权利要求1所述的基于虚拟交换机的多协议兼容的数据交互方法，其特征在于，上述步骤S400中根据消息解析的结果进行显示输出的相关应答处理具体包括以下，在flow_format函数中增加goose信息处理，flow_wildcards_init_for_packet函数中增加goose信息处理，match_format函数中增加goose信息处理，format_odp_key_attr__函数中增加goose信息处理，mf_set_flow_value函数中增加goose信息处理，parse_odp_key_mask_attr__函数中增加goose信息处理。

9.基于虚拟交换机的多协议兼容的数据交互装置，其特征在于，所述装置包括：存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序运行在以下装置的单元中：

报文信息应答模块，用于根据消息解析的结果进行显示输出的相关应答处理；

所述汇总报文信息包括MMS报文、GOOSE报文、SV报文以及1588报文，上述GOOSE报文的匹配域字段的预设方法具体包括以下，