本发明涉及报文重组技术， 尤其涉及一种 IP (互联网协议）分片报文 的重组方法和装置。 背景技术

IP是 TCP (传输控制协议）/ IP协议族中最为核心的协议。所有的 TCP、 UDP (用户数据报协议）、 ICMP (互联网控制消息协议）及 IGMP (互联网 组管理协议）数据都以 IP数据报文格式传输， 用 IP协议封装的数据单元叫 做 IP报文。 IP协议的下层协议是链路层协议，对于大多数� ��路层协议来说， 所能传输的数据帧长度都有一个上限，比如以 太网和 802.3对所能传输的长 度其最大值分别为 1500和 1492字节， 链路层的这个特性称作 MTU, 即最 大传输单元。

如果 IP层有一个数据报文需要传递， 而且数据的长度比链路的 MTU 还大， 那么 IP层就需要对 IP报文进行分片，使每个报文的长度都不大于� �� 路层的 MTU, 然后才能在链路上发送报文。

在接收端， 为了还原发送端发来的原始报文， 必须将收到的属于同一 个原始 "¾文的各个 IP分片进行重组， 重组成一个完整的 "¾文之后再交由上 层协议处理。 重组一般由目的主机完成， 但是对于一般特殊的情况， 比如 说 NAT (网络地址转换）过程需要重新计算整个报文� �校验和， 路由器等 中间节点也需要对分片报文进行重组。

RFC791描述了对 ΙΡ ·¾文进行分片和重组的过程。 该协议指出， IP头 中的 IP_ID、 源 IP地址、 目的 IP地址以及协议号四个字段用于标识属于同 一原始 IP报文的各个分片。 如果这些字段相同， 则认为它们是由同一个原 始报文分片成的多个报文， 需要将其重组成一个报文。

图 1 是重组表的基本结构图。 在系统初始化阶段， 重组模块首先在内 存中分配两片内存， 其中一片内存用于重组表， 另外一片内存用于重组表 对应的沖突表。 重组表用于保存在后续的重组过程中每个分片 报文的必要 信息， 需要保存的信息包括 IP_ID、 协议号、 源 IP地址、 目的 IP地址。 这 样一个数据结构叫做重组表， 除了能够保存以上信息之外， 每个重组表的 表项还需要保存两个指针， 分别指向重组表的沖突表项， 以及一个叫做 "分 片报文链表" 的数据结构。 在重组模块寻找每个分片报文对应的重组表项 时， 对 IP_ID、 协议号、 源 IP地址、 目的 IP地址这四个值进行哈希（ hash ) 计算， 当不同报文的哈希结果相同时， 就需要使用沖突表项 （沖突的重组 表项）。 沖突表项与重组表表项一样， 都保存在内存中， 其结构与重组表表 项结构完全相同， 在某些系统实现中， 并不区分重组表表项和沖突表项， 因此在后面的描述中，可能会将沖突表项直接 描述为重组表表项。所谓 "分 片报文链表"，是指网络设备所接收到的一串� �同特征的 IP分片报文，所谓 相同特征是指 IP_ID、 协议号、 源 IP地址、 目的 IP地址这四个字段完全相 同。 事实上， 当 IP分片报文被接收到网络设备中时， 它已经保存在了网络 设备的内存中， 重组模块只是使用分片报文链表将属于同一原 始 IP报文的 多个分片才艮文链接起来， 以完成对 ·艮文的重组。 图 1 中分别画出了前面所 提到的重组表项、 沖突表项、 分片报文链表。 在这个重组表中， 重组表项 2 和表项 η被使用， 并且每个表项后面还链接有沖突表项， 每个表项还有一 个指针指向分片报文链表。

在 IP网络运行了多年之后， VPN (虚拟专用网） 出现了， VPN的出现 改变了一个事实， 互联网由原来平面结构变成了立体结构， 由于 VPN之间 相互隔绝， 不同 VPN内的主机可以具有相同的 IP地址。

由于 IPv4 (互联网协议第四版）报文的 IP头内没有携带 VPN信息， 而且 IPv4的出现远远早于 VPN,因此 IPv4报文的重组流程没有考虑到 VPN 因素， 这样一来， IPv4报文的重组过程就不再具有完备性。 如果分别属于 VPN1和 VPN2的主机 A1和主机 A2发出去的 IP分片报文的源 IP地址、 目的 IP地址、 IP_ID、 协议号相同， 报文到达路由器 R之后， 由于路由器 R 的重组模块不区分 VPN信息， 因此路由器 R在重组时就会认为来自主机 A1和主机 A2的分片报文属于同一个原始 IP报文， 就可能会把来自主机 A1和主机 A2的分片报文重组到一起， 显然这样重组出来的是一个错误的 报文。 虽然 IPv6 (互联网协议第六版）协议出现时间要晚于 IPv4协议， 但 是 IPv6报文的重组流程依然是只考虑了 IP头本身的内容， 并未考虑 VPN, 因此 IPv6报文的重组流程也有与 IPv4重组流程相同的问题。 发明内容

本发明的目的是， 针对上述 IP重组方法的现状， 改进 IP重组流程， 使 不同 VPN内需要重组的 IP报文相互之间不受影响。

为解决上述技术问题， 本发明提出了一种 IP分片报文的重组方法， 具 体包括：

获取分片报文的 VPN标识，并结合从分片报文中获取的 IP头信息，计 算出哈希索引以确定本分片报文所对应的重组 表项， 根据重组表项、 VPN 标识和 IP头信息完成分片报文的比较、 重组。

进一步地， 当确定本分片才艮文所对应的重组表项未被使 用时， 该方法 还包括：将 VPN标识和 IP头信息保存到重组表表项中，并将本分片报� ��添 加到当前重组表项的分片报文链表中， 其中， 分片报文链表用于保存同一 原始报文中的分片。

进一步地， 当确定本分片才艮文所对应的重组表项已被使 用时， 所述比 较是将收到的 VPN标识和 IP头信息与已使用重组表项中保存的 VPN标识 和 IP头信息进行比较。 进一步地， 比较结果为全部匹配时， 该方法还包括： 将本分片报文添 加到对应的重组表项的分片报文链表中。

进一步地， 所述重组具体包括： 当同一原始报文的所有分片都添加到 对应的重组表项的分片报文链表中时， 将当前重组表项的分片报文链表中 的所有分片报文按顺序拼装到一起， 完成原始报文的重组。

进一步地， 比较结果不匹配时， 该方法还包括： 判断当前重组表项是 否有沖突表项。

进一步地， 没有沖突表项时， 该方法还包括： 新分配一个沖突表项， 将该沖突表项链接到当前所查重组表项的后面 ， 并将当前分片报文的 VPN 标识和 IP头信息保存到该沖突表项中。

进一步地， 已有沖突表项时， 该方法还包括： 重新将 文的 VPN标识 和 IP头信息与沖突表项中保存的 VPN标识和 IP头信息进行比较， 如果匹 配， 则将当前分片报文保存在匹配到的沖突表项的 分片报文链表中； 否贝' J , 新分配一个沖突表项，并保存 VPN标识和 IP头信息到新分配的沖突表项中。

进一步地， 所述 VPN标识为 VPN_ID, 所述 IP头信息为 IP_ID、 源 IP 地址、 目的 IP地址以及协议号。

本发明还提出一种 IP分片报文的重组装置， 包括： 获取单元、 计算确 定单元、 比较重组单元； 其中， 获取单元， 用于获取分片报文的 VPN标识 和 IP头信息； 计算确定单元， 用于根据获取单元获取的 VPN标识和 IP头 信息， 计算出哈希索引以确定分片报文所对应的重组 表项； 比较重组单元， 用于根据计算确定单元确定的重组表项与 VPN标识、 IP头信息进行分片报 文的比较、 拼装， 完成原始报文的重组。

本发明具有以下有益效果：避免了不同 VPN内的 IP分片报文在重组时 错误和相互影响的可能，补充了 RFC协议关于 IP分片报文重组过程的描述， 完善了现有的 IP重组流程， 能够提高网络设备的稳定性，提高 IP网络的传 输质量。 附图说明

图 1是重组表的基本结构图；

图 2为使用本发明改进后， 不同 VPN内分片报文在路由器上的转发处 理示意图；

图 3为实施例中用于实现本发明的算法流程图；

图 4为实施本方法的重组模块结构图。 具体实施方式 以下结合附图和具体实施例对本发明作进一步 详细的描述。

图 2 示出了使用本发明的 IP 重组流程之后， 路由器设备在处理不同 VPN内分片报文的情况。 从示意图中可以看出， 重组模块也跟 VRF ( VPN 路由 /转发）一样， 在逻辑上每个 VPN中存在一个重组模块， 而事实上重组 模块在整个路由器设备中只有一个， 只是对原来的重组模块进行了稍微的 变动，在判断分片报文是否属于同一个原始报 文时，除比较 IP头内的 IP_ID、 源 IP地址、目的 IP地址和协议号这四个字段之外，还比较报文� �� VPN_ID, 只有同一个 VPN下的报文， 才有可能来源于同一个原始报文， 才能够重组 到一起。

对于每一个分片报文， 在将其送到重组模块处理之前， 路由器必须获 取报文所属的 VPN, 也即确定报文的 VPN_ID, 然后将 VPN_ID带给重组 模块使用。 重组模块在对报文进行重组时， 首先使用传给重组模块的 VPNJD以及才艮文 IP头中的 IP_ID、 源 IP地址、 目的 IP地址、 协议号字段 计算报文在重组表中的索引， 再根据索引定位到相应的重组表项。 然后， 使用 文的 VPN_ID、 IP_ID、 源 IP地址、 目的 IP地址以及协议号与緩存 在重组表项中的相应的五个值进行比较， 只有所有五个值都相同时， 才认 为找到了自己所属的重组表项。 找到自己所属的重组表项之后， 对分片报 文进行排序、 复制等实际的报文内容重组操作， 与此前的重组过程相同。

VPNJD是本发明的关键， 相比之前的重组过程， 本发明中新增了 VPN_ID 的比较， 保证了不同 VPN下的分片报文相互不影响。

下面将以一个实施例来描述本发明的具体实施 方式。

图 3是本实施例的算法流程图， 下面将对算法中的每一个步骤进行详 细说明。

在步骤 410, 重组模块收到一个 IP分片报文。

在步骤 411 , 路由器通过当前分片报文的描述信息， 获取报文所属的 VPN, 即报文的 VPN_ID, 并从当前分片报文的 IP头中获取报文的 IP_ID、 源 IP地址、 目的 IP地址和协议号。 并使用这五个值计算出一个哈希索引， 以确定本分片才艮文所对应的重组表表项。

在步骤 412, 通过步骤 411计算出的哈希索引， 定位到重组表的对应表 项， 判断该表项是否还处于未被使用的状态。 如果该重组表项还未被使用， 则说明当前报文为同一原始报文中第一个到达 的分片，转入步骤 420;否则， 说明已经有同一原始报文的分片到达， 转入步骤 430。

在步骤 420, 将当前报文的 VPN_ID、 IP_ID、 源 IP地址、 目的 IP地址 以及协议号这五个值保存到重组表项中， 并将当前报文添加到当前重组表 项的分片报文链表中， 重组模块对当前分片报文的处理流程结束。 其中， 重组表项的分片报文链表用于保存同一原始报 文中已经收到的分片。

在步骤 430, 将报文的 VPN_ID、 IP_ID、 源 IP地址、 目的 IP地址以及 协议号分别与重组表项中保存的这五个值进行 比较， 然后进入步骤 431。

在步骤 431 , 判断步骤 430的比较结果， 如果比较结果为全部匹配， 则 说明已经找到了当前报文所属的重组表项， 转入步骤 440; 否则， 说明有报 文的哈希索引与当前报文的哈希索引相同， 重组表项相沖突， 转入步骤 460 查找沖突表项。

在步骤 440, 将当前报文添加到当前重组表项的分片报文链 表中， 然后 进入步骤 441。

在步骤 441 , 判断同一原始报文的所有分片是否全部到齐， 如果未全部 到齐， 则重组模块对当前报文的处理流程结束； 否则， 转入步骤 450。

在步骤 450,将当前重组表项的分片报文链表中的所有� �片报文按顺序 拼装到一起， 完成对当前报文所属原始报文的重组过程， 重组模块对当前 报文的处理流程结束。

在步骤 460, 判断当前重组表项的沖突表项指针是否为空。 如果该指针 为空， 则说明当前报文是同一原始报文中第一个到达 重组模块的分片， 转 入步骤 470; 否则， 说明已经有同一原始报文的分片到达， 转入步骤 480。

在步骤 470,新分配一个沖突表项， 并将该沖突表项接到步骤 460所查 重组表项的后面， 进入步骤 471。

在步骤 471 , 将当前报文的 VPN_ID、 IP_ID、 源 IP地址、 目的 IP地址 以及协议号这五个值保存到步骤 470分配的沖突表项中， 重组模块对当前 报文的处理流程结束。

在步骤 480,根据步骤 460中所查的重组表项的沖突表项指针， 定位到 下一个的沖突表项， 然后进入步骤 430, 开始对当前报文与沖突表项内容的 新一轮比较操作。

以上即为本实施例的实现算法描述，该算法对 IPv4报文和 IPv6报文都 适用。

图 4为实施本方法的重组装置结构图。 如图 4所示， 重组装置包括： 获取单元， 用于获取分片报文的 VPN标识和 IP头信息；

计算确定单元，用于根据获取单元获取的 VPN标识和 IP头信息，计算 出哈希索引以确定分片报文所对应的重组表项 ； 及 比较重组单元， 用于根据计算确定单元确定的重组表项与 VPN标识、 IP头信息进行分片报文的比较、 拼装， 完成原始报文的重组。

以上所述仅为本发明的较佳实施例而已， 并不用以限制本发明， 凡在 本发明的精神和原则之内所作的任何修改、 等同替换和改进等， 均应包含 在本发明的保护范围之内。