技术领域

本发明涉及互联网技术领域， 尤其涉及一种网络地址转换 （Network Address Translation, NAT) 的设备及方法。 背景技术

因特网 ( internet )使用的 IPv4 ( Internet Protocol version 4, 互联网协议版本 4) 有 32位（4字节）地址， 最多可以允许 2的 32次方数量的电脑联到互联网中。 随着互联网的 迅速发展， 对 IP地址的需求愈来愈大， IPv4地址将被分配殆尽这个问题已无法回避。� �这 种需求下， 推出了下一版本的互联网协议， 即 IPv6 ( Internet Protocol version 6， 互 联网协议版本 6)。 IPv6采用 128位地址长度， 几乎可以不受限制地提供 IP地址， 并且在安 全性、 网络管理、移动性以及服务质量等方面有明显 的改进， 是下一代互联网络协议采用 的核心标准。

然而， 由于使用 IPv4的网络 （下文简称 IPv4网络） 已发展的非常成熟， IPv4网络非 常庞大， 以至于不得不需要一段很长的时间逐步从 IPv4网络向 IPv6网络 （使用 IPv6的网 络）过渡。在 IPv4网络向 IPv6网络漫长的过渡期间， NAT (Network Address Translation, 网络地址转换） 技术仍将得到广泛使用。 NAT技术属于接入广域网 （WAN，） 技术， 是一种 将私有 （private )地址转化为公网 （publ ic ) IP地址的转换技术， 被广泛应用于各种因 特网 （internet ) 的接入方式中。

与普通家用或企业级的 NAT不同， 对于运营商（Carrier)来讲， 其面对的客户更多， 因此对 NAT的性能、 可运营性和可管理性的要求高。

运营商级网络地址转换 ( Carrier Grade Network Address Translation, BP CGNAT, 简称 CGN)技术是目前各运营商广泛采用的过渡方案� � CGN也曾经被称为 LSN (Large Scale NAT) , 其实质就是 NAT。 由于运营商面对的客户很多， 大多可以以亿为单位来计算， 因此 CGN设备所需要处理的网络地址转换的业务量也 很大。在 IPv4网络向 IPv6网络漫长的过 渡期间， CGN需要能够保证现有的终端或业务的正常使用 ， 同时又能实现真正的 IPv6应 用， 并且在性能、 可运营程度以及可管理程度方面满足业务的需 求。 发明内容

有鉴于此，本发明提供了一种网络地址转换的 设备及方法，将网络地址转换设备所管 理的端口资源分别发送给各个业务板的 CPU, 由业务板的 CPU来负责对端口资源进行管理 和分配， 并且每个端口资源由一个 CPU来独立管理， 这样在实现网络地址转换的整个过程 中， 管理端口资源的业务板的 CPU会为接收到报文的业务板的 CPU分配端口资源， 多个业 务板的 CPU共同参与实现网络地址转换， 充分发挥了分布式系统的优势， 提高了端口资源 的分配效率和利用率。

为了解决上述问题， 第一方面， 本发明实施例提供了一种实现网络地址转换的 设备， 所述设备包括： 控制板（11)、 业务板和接口板（15)， 所述业务板包括多个中央处理单元 ( central processing unit, CPU) ，其中所述设备的端口资源分配给所述业务板 的多个 CPU进行管理和分配； 所述接口板（15)用于接收用户驻地设备 (301)发送的第一会话的第 一报文， 并将所述第一报文转发给所述业务板的第一 CPU; 所述第一 CPU用于， 根据 NAT策 略确定第二 CPU负责管理所述第一报文进行网络地址转换所 需要的端口资源；从所述第二 CPU获得 N个端口资源；从所述 N个端口资源中使用第一端口资源对所述第一� �文进行网络 地址转换得到转换后的报文； 将所述转换后的报文发送给所述接口板（15) ; 所述接口板 (15)还用于将接收到的所述转换后的报文发送� �外部网络。

结合第一方面， 在第一种可能的实现方式中， 所述设备还包括： 控制板用于： 将端 口资源广播到所述业务板的多个 CPU; 或者将端口分配策略广播到业务板的多个 CPU, 其 中所述端口分配策略将所述设备的端口资源分 配给所述业务板的多个 CPU,每个所述 CPU 负责管理所分配的端口资源。

结合第一方面的第二种可能的实现方式中， 所述设备还包括： 所述接口板（15)进一 步用于： 根据所述第一报文的源 IP地址将所述第一报文转发给所述业务板的第� �� CPU。

在第三种可能的实现方式中， 所述设备还包括： 当所述第一 CPU接收到所述第一报文 所在会话的第二报文时，所述第一 CPU进一步用于根据保存的会话表对所述第二报 文进行 处理，其中所述会话表是在所述第一报文完成 网络地址转换后建立的。 在第四种可能的实现方式中， 所述设备还包括： 当所述第一 CPU接收到所述用户驻地 设备 (301)发送的第二会话的第三报文时，其中所述� ��二会话是与所述第一会话不同的一 个新会话， 所述第一 CPU进一步用于从所述 N个端口资源中选取第二端口资源对所述第三 报文进行网络地址转换。

在第五种可能的实现方式中， 所述设备还包括： 所述网络地址转换策略用于根据接 收到的报文的特性确定对应的端口资源信息

在第六种可能的实现方式中， 所述设备还包括： 所述第一 CPU用于接收第四报文； 根 据所述 NAT策略确定所述第一 CPU负责管理所述第四报文进行网络地址转换所 需要的端口 资源； 从第一 CPU所管理的端口资源池中为发送所述第四报文 的用户驻地设备分配 M个端 口资源； 使用 M个端口资源中的第一端口资源对所述第四报� �进行网络地址转换。

在第七种可能的实现方式中， 所述设备还包括： 所述第一 CPU还用于存储所述 M个端 口资源的使用状态， 并定期更新所述 M个端口资源的使用状态。

在第八种可能的实现方式中， 所述设备还包括： 所述第二 CPU进一步用于存储所述 N 个端口资源的使用状态， 并将所述 N个端口资源的使用状态发送给所述第一 CPU; 所述第 一 CPU进一步用于定期更新所述 N个端口资源的使用状态， 并将所述更新的使用状态发送 给所述第二 CPU。

第二方面， 本发明实施例提供了一种网络地址转换方法， 其中，实现所述网络地址转 换方法的设备包括控制板（11)、接口板（15)和 带有多个 CPU的业务板， 所述设备的端口资 源分配给所述业务板的多个 CPU进行管理和分配； 所述业务板的第一 CPU接收所述接口板 (15)转发的用户驻地设备 (301)发送的第一会话的第一报文；根据网络地� ��转换策略确定 第二 CPU管理所述第一报文进行网络地址转换所需要 的端口资源；从所述第二 CPU获得 N个 端口资源；使用所述 N个端口资源中的第一端口资源对所述第一报� �进行网络地址转换得 到转换后的报文； 将所述转换后的报文发送给所述接口板（15) ; 所述接口板（15)将所述 转换后的报文发送到外部网络。

结合第二方面， 在第一种可能的实现方式中， 所述网络地址转换方法还包括： 所述 控制板（11)将所述端口资源广播到所述业务板 的多个 CPU;或者所述控制板（11)将端口分 配策略广播给所述业务板的多个 CPU,其中所述端口分配策略用于将所述设备的� �口资源 分配给所述业务板的多个 CPU, 每个所述 CPU负责管理所分配的端口资源。

结合第二方面的第二种可能的实现方式中， 所述网络地址转换方法还包括， 所述接 口板（15)根据所述第一报文的源 IP地址将所述第一报文分配给所述业务板的所� ��第一 CPU。

结合第二方面的第三种可能的实现方式中， 所述网络地址转换方法还包括， 当所述 第一 CPU接收到属于所述第一报文所在会话的第二报 文时， 所述第一 CPU根据保存的会话 表对所述第二报文进行处理，其中所述会话表 是在所述第一报文完成网络地址转换后建 立的。

结合第二方面的第四种可能的实现方式中， 所述网络地址转换方法还包括， 当所述 第一 CPU接收到所述用户驻地设备 (301)发送的第二会话的第三报文时， 其中所述第二会 话是与所述第一会话不同的一个新会话， 所述第一 CPU使用 N个端口资源中的第二端口资 源对所述第三报文进行网络地址转换。

结合第二方面的第五种可能的实现方式中， 所述网络地址转换方法还包括， 所述 网络地址转换策略用于根据接收到的报文的特 性确定对应的端口资源。

结合第二方面的第六种可能的实现方式中， 所述网络地址转换方法还包括， 所述第 一 CPU接收第四报文； 根据所述网络地址转换策略确定所述第一 CPU负责管理所述第四报 文进行网络地址转换所需要的端口资源;从第� � CPU所管理的端口资源中为发送所述第四 报文的用户驻地设备分配 M个端口资源； 使用 M个端口资源中的第一端口资源对所述第四 报文进行网络地址转换。

结合第二方面的第七种可能的实现方式中， 所述网络地址转换方法还包括， 所述第 一 CPU保存所述 M个端口资源的使用状态， 并定期更新所述 M个端口资源的使用状态。

结合第二方面的第八种可能的实现方式中， 所述网络地址转换方法还包括， 所述第 二 CPU存储所述 N个端口资源的使用状态，并将所述 N个端口资源的使用状态发送给所述第 一 CPU; 所述第一 CPU定期更新所述 N个端口资源的使用状态， 并将所述更新的使用状态发 送给所述第二 CPU。

本发明实施例通过把网络地址转换设备所管理 的端口资源分别发送给各个业务板的 CPU, 由业务板的 CPU来负责对端口资源的管理和分配， 并且每个端口资源由一个 CPU来独 立管理， 在实现网络地址转换的整个过程中， 管理端口资源的业务板的 CPU会为接收到报 文的业务板的 CPU分配端口资源， 多个业务板的 CPU共同参与实现网络地址转换。 这样由 业务板的 CPU来对网络地址转换设备的端口资源进行管理 ，避免了控制板成为端口资源分 配的瓶颈， 充分发挥了分布式系统的优势， 提高了端口资源的分配效率和利用率。

根据下面参考附图对示例性实施例的详细说明 ， 本发明的其它特征及方面将变得清 楚。

附图说明

为了更清楚地说明本发明实施例或现有技术中 的技术方案， 下面将对实施例或现有 技术描述中所需要使用的附图作一简单地介绍 。 图 1为运营商级网络地址转换业务应用的应用场� �示意图；

图 2为运营商级网络地址转换设备的结构示意图� �

图 3为已有的运营商级网络地址转换方法的流程� �意图；

图 4为本发明实施例中的网络地址转换的信号示� �图；

图 5为本发明实施例的网络地址转换的方法流程� �意图。

具体实施方式

以下将参考附图详细说明本发明的各种示例性 实施例、 特征和方法。

另外， 为了更好的说明本发明， 在下文的具体实施方式中给出了众多的具体细 节。 本领域技术人员应当理解， 没有这些具体细节， 本发明同样可以实施。 在另外一些实例 中， 对于大家熟知的方法、手段、 元件和电路未作详细描述， 以便于凸显本发明的主旨。

运营商级网络地址转换 ( Carrier Grade Network Address Translation, 即 CGNAT, 简称 CGN) 技术是目前各运营商广泛采用的 IPv4-IPv6的过渡方案， 其实质为网络地址转 换设备。 CGN解决方案有多种实现方式， 例如： DS-Lite ( Dual-Stack Lite , 双栈精简技 术）， NAT444 (双层 NAT44技术， 即双层 IPv4私有地址到 IPv4公有地址的地址网络地址转 换技术）， PNAT ( Prefix Based NAT,基于主机的 IPv6过渡网络地址转换技术）， NAT64 ( IPv6 与 IPv4之间的网络地址转换技术）。 CGN解决方案主要应用于城域网的网络过渡，其 应用场景请参见附图 1。 终端用户 User (401)与用户驻地设备 （Customer Presidial Equipment, 简称 CPE) (301)相连， CPE (301)作为终端用户（401)的出口网关， 通过宽带远程接入服务 （Broadband Remote Access Service, 简称 BRAS) (2)拨号上线后， 转发报文至 CGN设备（1)。 CGN设备（1)为 各 CPE分配端口资源，并实现运营级 NAT转换，并将转换后的报文发送到外部网络 (5)中。

在 DS-Lite解决方案中， CPE (301 )会将终端用户（401 )发来的报文封装在以 CPE设备 的 IP地址 （CPE-IP) 为源 IP的 IPv4-in-IPv6隧道报文中， 发给 CGN设备（1 )。 而在 NAT444 解决方案中， CPE (301 )会将终端用户（401 )发来的报文的源 IP转换为 CPE-IP后，发给 CGN 设备。 因此， 在 DS-Lite和 NAT444解决方案中， 每个 CPE下所有终端用户发起的报文到达 CGN设备（1 )后， 报文的源 IP都是所属 CPE的 IP地址， CGN设备（1 )可以通过报文源 IP区分 和识别不同 CPE发送来的报文。其他的 CGN实现方式在端口分配方案及 NAT功能的实现上类 似， 因此， 在本申请文件中主要是基于 DS-Lite和 NAT444解决方案进行介绍， 其他解决方 案类似的实现方式不再单独进行记述。

为了满足高转发性能以及解决大量 NAT应用带来的用户溯源的难题， CGN提供了端口 预分配 （port-range) 技术和增量分配 （ semi -dynamic) 技术。 端口预分配技术是指， 运营商级网络地址转换设备（简称 CGN设备）为各个 CPE预先分配端口资源， 后续 CPE所连 接的所有终端用户发送的报文均使用已分配的 端口资源进行网络地址转换。 随着新建会 话的不断增加， 当 CPE分配到的端口资源不足时， 可以通过增量分配为该 CPE追加分配新 的端口资源。

CGN设备（1 )一般安装在在局域网或者城域网等网络接口� �， CGN设备（ 1 )可以是一个 独立的设备， 也可以集成在防火墙设备中， 或者可以集成到路由器设备中， 具体设置方 式根据业务需要确定。终端用户发送的报文通 过 CPE发送到 CGN设备， 由 CGN设备进行网络 地址转换后发送到外部网络中， 获取所需的服务或信息。

CGN设备的结构如附图 2所示， 包括控制板 （main processing unit，简称 MPU，有的也 称之为主控板） （11)， 业务板（service processing unit，简称 SPU)， 和接口板 （line processing unit，简称 LPU) ( 15)。 图 2中给出的各板之间的相互位置关系仅为示例� �的 说明，表明相互之间的连接关系，不同厂家生 产的 CGN设备中各种板的个数以及具体安装 位置会有不同， 只能具有能实现类似功能的板即可。 另外， CGN设备还包括交换网板、 电 源、 风扇等组成部件， 与现有技术类似， 在此不再详述。

如果将网络地址转换功能集成到其他设备中时 ， 如将网络地址转换功能集成到防火 墙或者路由器中， 控制板、 业务板以及接口板等的功能可以由具备类似功 能的元器件来 实现。 相应的， 电源、 风扇等部件也根据集成的其他设备的情况来设 置。 在此不再另行 说明。 在本发明实施例中， 以单独的 CGN设备来进行说明。

CGN设备中， 控制板（11)负责对 CGN设备（1)进行管理， 特别是负责该 CGN设备所拥 有的 NAT地址池以及端口资源的分配和使用。所述 NAT地址池为 CGN设备所管理的可用于网 络地址转换的公网 IP地址的集合。 所述端口资源是指可用于网络地址转换的公网 IP地址 及对应的端口号段的集合。

业务板与控制板（11)相连， 负责对报文进行处理。 CGN设备中一般会有多块业务板， 以满足处理大量报文的需求， 多个业务板分别与控制板（11)相连， 各个业务板也互相连 接； 业务板与控制板（11)之间的连接以及各业务板 之间的连接与现有连接方式相同。每 个业务板可以包括单个 CPU或者包括多个 CPU。 对于运营商来讲， 由于需要处理的报文业 务量大， 因此， 业务板大都包含多个 CPU。对报文进行网络地址转换的功能， 由业务板中 的 CPU来实现。

接口板（15)与控制板（11)、 业务板相连， 连接方式与现有连接方式相同。 接口板 (15)将接收到的终端用户（401)发送来的报文根� ��预先配置的策略分流给业务板，业务 板对报文进行处理， 再将处理后的报文发送给接口板（15)， 接口板（15)再将业务板处 理后的报文发送到外部网络中去。 接口板接收报文和发送报文的功能可以分开由 一个接 口板负责接收终端用户发送来的报文， 由另外一个接口板负责将业务板处理后的报文 发 送到公共网络中去。

附图 3给出了已有的 CGN设备对报文进行网络地址转换的示意图。

如附图 3所示， ?51(301)将终端用户11^1~1(401)发送来的报文通过81 ^5(2)发送 给 CGN设备（1) ; CGN设备（1)的接口板（15)接收到 CPEU301)发送来的报文后， 根据预 定的策略将报文转发给对应的业务板。例如根 据报文的源 IP将报文转发给对应的业务板， 如 SPU1。 业务板的 CPU (例如 SPU1(131)的 CPU0(1311) )接收到 CPE1 (301)发送的第一条会话 的第一个报文时， 向控制板（11)申请 N个端口资源， 并从 N个端口资源中取出一个端口资 源供该第一条会话的第一个报文进行网络地址 转换，同时保存该第一条会话的会话状态， 即会话表。当 SPUU131)的 CPU0(1311)接收到的报文是该第一条会话的后续� �文时，根 据会话表对该第一条会话的后续报文进行转发 ， 此技术已为本领域技术人员所熟知， 在 此不再详述。

以此类推，当 SPUU131)的 CPU0(1311)接收到 CPEU301)发送的一个新的会话的第 一条报文时， 从剩余的端口资源中取出一个端口资源供该新 会话的第一条报文进行端口 转换， 并保存相应的会话状态， 即会话表。 例如， 当 SPUU131)的 CPU0(1311)接收的是 第二条会话的第一个报文时，从除了已为第一 条会话所采用的端口外的剩余的 N-1个端口 中取出一个端口供第二条会话的第一个报文进 行网络地址转换， 并保存所述第二条会话 的会话状态， 即会话表； 当 SPUU131)的 CPU0(1311)接收到第二条会话的后续报文时， 根据保存的第二条会话的会话表对该报文进行 转发。

在该方案中， 端口资源由控制板（11)统一管理， 各业务板的 CPU需要向控制板申请 端口资源来为新建会话做网络地址转换时使用 。 此时， 控制板（11)是各业务板的各 CPU 获取端口资源的唯一途径， 同时也是各业务板的各 CPU获取端口资源性能的瓶颈所在，无 法发挥分布式系统的优势。

并且， 当 SPUU131)的 CPU0(1311)接收到的新会话数量增多， 控制板（11)分配的 N 个端口资源被使用完毕时， CPU0(1311)需要再次向控制板（11)申请新的端口� �源， 这样 会引起端口资源的二次分配和管理的问题， 增加了端口资源分配的复杂性。

此外， 业务板的 CPU还可以向控制板（11)申请 N个端口资源直接分配给发送报文的 CPE, 当接收到其他的 CPE的报文时， 业务板的 CPU再向控制板（11)新申请 M个端口资源。 或者， 业务板的 CPU向控制板（11)申请 N个端口资源后， 从这 N个端口资源中划分 M个端口 资源给发送报文的 CPE； 当接收到其他的 CPE的会话报文时， 业务板的 CPU再从剩余的 N-M 个端口资源中分配 Q个端口资源分配给新接入的 CPE。 同样的， 这两种端口资源的方式会 面临控制板的端口资源分配的瓶颈以及端口资 源二次分配和管理的问题。此处的 M、 N和 P 为一个整数， 不代表具体的数量。 为了克服控制板的瓶颈和端口资源二次分配和 管理的问题，还有另外一种实现方法。 控制板将端口资源分块并划分给各业务板的各 个 CPU,这样就避免了控制板成为理端口资 源分配和管理的瓶颈。 各业务板的 CPU接收到新建会话的报文时， 直接从该 CPU所划分的 端口资源中获取端口并进行网络地址转换。这 种方案中，各业务板的 CPU只能利用所划分 的 NAT端口资源为 CPE发送的会话分配端口资源， 当 CPU的剩余端口资源不足，只能等待释 放出端口资源后再进行处理， 无法发挥分布式系统的优势， 端口利用率低。

本发明提供了一种端口资源分配以及网络地址 转换的设备及方法， 既能解决控制板 为端口资源分配的瓶颈的问题，又能解决多业 务板 CPU之间端口资源管理和分配冲突的问 题， 提高端口利用率， 充分发挥分布式系统的优势。

本发明实施例提供的解决方案中，将端口资源 映射到各个业务板的 CPU上， 由业务板 的 CPU对端口资源进行管理， 并且每个端口资源由所映射的 CPU单独进行管理。 这样端口 资源由业务板的 CPU来管理和分配， 避免了控制板成为端口资源分配和管理的瓶颈 的问 题；而且每个端口资源由所映射的 CPU单独进行管理，解决了分布式系统中的端口 资源管 理的二次分配和管理的问题； 另外， 在端口资源分配以及网络地址转换的过程中， 有多 个 CPU共同参与， 这样提高了端口利用率， 又充分发挥分布式系统的架构和性能优势。

在本发明实施例中， CGN设备包括控制板（11)、 业务板以及接口板（15)， 如附图 2所 示。 交换网板、 电源、 风扇等部件与现有的实现方式相同 （未在图中示出）， 在此不再详 述。集成了 CGN功能的防火墙或者路由器由具有相同功能的 元器件参照本文中提到的解决 来实现运营商级的网络地址转换， 在本发明实施例中不再另行说明。

控制板（11)包括 CPU (1101)和存储器（1103)。 控制板（11)中的 CPU (1101)用于对 CGN 设备及 CGN的所有资源及信息进行管理，并将端口资源 根据端口分配策略分配给各个业务 板的 CPU;存储器（1103)用于存储 CGN设备所能管理的 NAT地址池和端口资源， 以及端口资 源与分配的业务板 CPU之间的对应关系。 CGN设备所管理的可用于网络地址转换的公网 IP 地址的集合组成 NAT地址池。所述端口资源是指可用于网络地址 转换的各个公网 IP地址及 对应的端口号段的集合。

业务板包括 CPU和存储器。 业务板中的 CPU用于处理接收到的报文， 包括端口资源分 配、 网络地址转换等。 存储器用于存储用户表和会话表。 所述用户表包含有端口资源和 用户驻地设备之间的对应关系等信息， 所述会话表包含有会话状态等信息。 用户表及会 话表可以利用本领域中已有的实现方式， 在本实施例中不再详述。

接口板（15)包括 CPU (1503)、接收器（1501)和发送器（1505)。接收器� �1501)用于接收 CPE发送来的报文，并将报文发送给接口板的 CPU。接口板的 CPU根据一定的规则把报文分 发给业务板的 CPU, 例如接口板的 CPU根据接收到的报文的源 IP地址把报文分发给业务板 的 CPU。 发送器（1505)用于接收业务板的 CPU发送过来的报文并发送到外部网络去。 在运 营商级网络地址转换的应用场景下， 也可以根据业务量的需要， 将接收报文的功能与发 送报文的功能分别由两个接口板来完成。也即 CGN设备可以包括两个接口板，一个接口板 包括 CPU和接收器， 另外一个接口板包括 CPU和发送器。

CGN设备拥有的用于网络地址转换的公网 IP地址组成 NAT地址池，保存在控制板（11) 的存储器（1103)中。 CGN设备的可使用的公网 IP地址可以组成一个 NAT地址池， 也可以分 成多个 NAT地址池， 在本发明实施例中， 以一个 NAT地址池为例进行说明。 每个公网 IP地 址对应一段可用的端口号段，例如端口 2049-65535，也保存在控制板（11)的存储器（1103) 中， 所述可用于网络地址转换的各个公网 IP地址及对应的端口号段组成端口资源。 控制 板（11)的 CPU (1101)根据端口分配策略把端口资源分别映射给 各业务板的 CPU, 并将端口 资源与业务板中的 CPU的对应关系保存在存储器中。 端口分配策略是一种算法， 将 CGN设 备的端口资源分配给业务板的 CPU, 由业务板的 CPU分别负责管理所分配的端口资源。 控 制板可以运行算法把端口资源映射到业务板的 CPU,然后将各端口资源广播到业务板的 CPU;控制板也可以将端口分配策略广播到业务� �的 CPU,业务板的 CPU通过运行端口分配 策略得到负责管理的端口资源。 这样， 就把对端口资源的管理和分配从控制板转移给 了 业务板的 CPU, 由业务板的 CPU对分配的端口资源独立进行管理。

例如， 所述 CGN设备管理的 NAT地址池中有 N个可以用于网络地址转换的公网 IP地址， 每个公网 IP地址都有可供使用的一段端口号。 CGN设备使用固定算法将端口资源分别映射 到各个业务板的 CPU, 然后将端口资源广播到对应的业务板的 CPU。 具体的端口分配策略 可以根据 CGN设备的各个性能参数和运营商的实际需要来 设定。端口分配策略中可以包含 如表一所示的几个参数。 表一中的参数仅为示例， 不对本方案进行限制， 实际使用中， 可以根据需要对参数以及参数的数值进行修改 。 公网 IP地址 ID 公网 IP地址 SPU编号 CPU编号 端口块 端口分配粒度

… … … … … …

199 10. 10. 2. 0 1 0 2049-65535 256

200 10. 10. 2. 1 1 1 2049-65535 256

201 10. 12. 2. 2 1 1 2049-65535 256

202 10. 12. 2. 3 1 2 2049-33793 256

… … … … … … 表一 端口资源分配策略所含参数

如表一所示， 第一组参数表示： 将第 199个公网 IP地址 （10. 10. 2. 0 ) 的端口资源按 照 256个端口为一个块来进行划分并分配给 SPU1的 CPU0, 即 SPU1的 CPU0是负责管理第 199 个公网 IP地址对应的端口资源的 CPU。 第二组参数表示： 将第 200个公网 IP地址 ( 10. 10. 2. 1 ) 的端口资源按照 256个端口为一个块来进行划分并分配给 SPU0的 CPU2, 即 SPU0的 CPU2是负责管理第 200个公网 IP地址的端口资源的 CPU。 由于数量多， 在表中无法 一一列出， 未列出的参数以省略号 （…） 表示。

这样对端口资源的管理就由控制板转移到各个 业务板的 CPU，避免了控制板成为端口 资源分配和管理的瓶颈。 同时， 每个端口资源由一个 CPU独立进行管理， 避免了端口分配 的冲突。

业务板中的 CPU (第一 CPU)接收的接口板分发的报文如果为一个 CPE发送的第一个会 话的第一条报文 （第一报文）， 第一 CPU查找 NAT策略， 第一 CPU根据接收到的报文的特性 确定需要进行网络地址转换的公网 IP地址的 ID号， 对公网 IP地址的 ID号做 HASH计算， 得 到管理需要进行网络地址转换的端口资源的 CPU (第二 CPU)。所述报文的特性可以为报文 的 ACL信息， 报文的源 IP、 目的 IP、 源端口、 目的端口以及协议等五元组信息， NAT类型 等信息中的一种或者多种。 根据报文的特性确定进行网络地址转换的 IP地址的方法与现 有实现方式相近似， 在此不再详述。

如果所述第二 CPU与所述第一 CPU不是同一个 CPU, 即接收到报文的业务板的 CPU不同 于管理端口资源的业务板的 CPU,则所述第一 CPU将所述第一报文发送给第二 CPU, 即接收 到报文的业务板的 CPU将所述第一报文发送给管理端口资源的业务 板的 CPU。所述第一 CPU 和所述第二 CPU可以位于同一个业务板，也可以位于不同的 业务板。对本发明实施例中的 技术方案的实现没有影响。

所述第二 CPU接收到所述第一报文后， 从管理的端口资源中为发送所述第一报文的 CPE分配 N个端口， 并保存所述 N个端口资源的使用状态， 例如将分配的 N个端口资源的使 用状态以及与对应的 CPE之间的关系保存到用户表中。 所述第二 CPU将所述第一报文、 所 述分配的 N个端口发送给所述第一 CPU。

所述第一 CPU接收到所述第二 CPU发送过来的第一报文、 所述 N个端口资源之后， 从 N 个端口资源中选取一个端口资源对所述第一报 文进行网络地址转换，并保存所述 N个端口 资源的使用状态， 例如将所述分配的 N个端口资源的使用状态以及与对应的 CPE之间的关 系保存到用户表中， 并定时更新用户表。 用户表中的其他信息与现有技术实现方式中类 似， 在此不再另行说明。第一 CPU将完成了网络地址转换的第一报文发送给接 口板， 由接 口板将所述完成了网络地址转换的第一报文发 送到外部网络中。为了确保 N个端口不会被 第二 CPU回收，第一 CPU定时更新所述 N个端口资源的使用状态并发送刷新消息给第� � CPU。 当该 CPE的所有会话都断开后，第一 CPU不再刷新所述 N个端口资源的使用状态，也不再发 送刷新消息给第二 CPU，第二 CPU上的所述 N个端口资源的使用状态如果在设定的时间范� � 内没有收到刷新消息， 则释放所述 N个端口资源以供重新分配。

如果得出的负责管理所述公网 IP地址的 CPU (即第二 CPU)与接收第一报文的 CPU (即 第一 CPU) 为同一个 CPU,则所述第一 CPU从管理的端口资源中为发送所述第一报文的 用户 驻地设备分配 N个端口， 并从 N个端口资源中选取一个端口资源对所述第一� �文进行网络 地址转换， 将所述分配的 N个端口资源的使用状态以及与对应的 CPE之间的关系保存到用 户表中并更新存储的用户表。 用户表中的其他信息与现有技术实现方式中类 似， 在此不 再另行说明。第一 CPU将完成了网络地址转换的第一报文发送给接 口板， 由接口板将所述 完成了网络地址转换的第一报文发送到网络中 。

当所述 N个资源不够使用时， 可以使用以上描述的方法再新申请 M个新的端口资源用 于网络地址转换， 在此不再详述。

这样，一个端口资源由唯一的 CPU管理，解决了现有技术中端口资源分配和管 理复杂 的问题。另外， 多个业务板的 CPU共同参与完整的网络地址转换全过程， 并且当端口资源 不再使用时， 可以释放以供重新使用， 这样可以充分发挥分布式系统的优势， 提高端口 资源的利用率。

当业务板中的 CPU (第一 CPU)接收的接口板分发的报文为一个会话的后� �报文时（第 二报文）， 所述第一 CPU根据存储的会话表将第二报文发送出去， 此时的处理方式可参考 现有方式中同一会话后续报文的处理方式， 在此不再详述。

当业务板中的 CPU (第一 CPU)接收的接口板分发的报文为同一个 CPE发送的新的会话 的第一个报文时（第三报文），所述第一 CPU从分配的 N个端口资源中选择第二端口资源对 所述第三报文进行网络地址转换。也就是说从 分配的 N个端口资源中， 除了已经分配给第 一报文的端口资源以外的其他端口资源（即 N-1个端口资源）中，选择一个端口资源对第三 报文进行网络地址转换。 后面的处理方式与第一报文类似， 在此不再另行说明。 此时， 第一 CPU不再需要把报文转发给第二 CPU, 直接从已经分配的端口资源中选取未使用的端 口资源进行网络地址转换， 充分发挥了分布式系统的优势。

由于在 CGN方案中，一个 CPE连接的终端用户的数量可能会很多，可能会 出现分配的 N 个端口资源不够使用的情况， 此时可以重新申请 M个端口资源， 申请的方法与前述的 N个 端口资源的方法相同。

通过本发明提供的实施例，解决了现有技术中 控制板为端口资源管理和分配的瓶颈、 端口资源分配和管理问题复杂、 以及端口资源利用率低等等问题， 充分利用了分布式系 统的优势， 提高了端口资源的利用效率。

下面以一个具体的例子来说明 CGN设备在实现网络地址转换的过程中是如何来 实现 高效简单的端口资源分配和管理的。

本发明实施例提供的网络地址转换的方法流程 如附图 4和附图 5所示。

步骤 1， CGN设备控制板（11)的 CPU (1101)将 CGN设备（1)所拥有的端口资源映射到业务 板的 CPU。

CGN设备所拥有的用于网络地址转换的公网 IP地址组成 NAT地址池， CGN设备的可使用 的公网 IP地址可以组成一个 NAT地址池，也可以分成多个 NAT地址池，在本发明实施例中， 以一个 NAT地址池为例进行说明。 每个 IP地址都对应一段端口号段用于进行网络地址� �� 换， 用于网络地址转换的公网 IP地址及对应的端口号段构成了可以用于网络� ��址转换的 端口资源。 控制板（11)的 CPU (l lOl)根据端口分配策略把端口资源映射到各个� �务板的 CPU, 由业务板的 CPU对分配到的端口资源进行管理和分配。 控制板（11)可以运行端口分 配算法把端口资源映射到业务板的 CPU,然后将各端口资源广播到业务板的 CPU; 控制板 (11)也可以将端口分配策略广播到业务板的 CPU, 业务板的 CPU通过运行端口分配策略得 到负责管理的端口资源。

例如， CGN设备有 N个可用于网络地址转换的公网 IP地址， 每个公网 IP地址对应的可 用的端口资源为 2049-65535， 存储在控制板（11)的存储器（1103)中。 控制板（l l) MPU的 CPU (1101)将端口资源映射到业务板 SPU上的各个 CPU。 例如， CGN设备某个可用于网络地 址转换的公网 IP地址为 10. 10. 2. 0， 其对应的端口资源为 2049-65535， 控制板（11)的 CPU 将该端口资源映射给 SPU1 (131)的 CPU0 (1311)管理， 即由 SPU1 (131)的 CPU0 (1311)负责这 个公网 IP地址的端口资源的管理和分配。 将端口资源与各业务板 SPU以及各个 CPU之间的 映射关系保存到 MPU (11)的存储器（1103)中。端口分配策略在前文已 给出具体的示例，在 此不同详述。

这样， 每个端口资源由所映射的业务板的 CPU独立管理。这样， 一个端口资源只会由 一个 CPU进行管理， 避免了端口分配冲突； 并且， 从网络地址转换整个过程来看， 业务板 的多个 CPU共同参与端口资源的管理和分配， 充分利用了分布式系统的架构优势。

步骤 2， 接口板（15)接收到 CPE发送来的报文后， 发送给业务板的 CPU。

接口板（15)根据报文的源 IP地址将接收到的报文分流至对应业务板的 CPU。因此具有 相同源 IP地址的所有报文都会分流到同一业务板的同� ��个 CPU上。 在 DS-Lite和 NAT444解 决方案中， 报文的源 IP地址即是 CPE的 IP地址， 即 CPE-IP, 所以同一个 CPE连接的所有终 端用户发出的报文都会被分流至同一个业务板 的同一个 CPU处理。 CPE对接收到的终端用 户发出的报文的处理前文已提及， 在此不再另行说明。 根据报文的源 IP地址分配到业务 板的 CPU已为本领域技术人员所熟知， 在此不再详述。

如附图 4所示， 接口板 LPU (15)上的接收器（1501)接收到 CPE1发送来的报文， 发送给 接口板（15)的 CPU (1503)。 接口板（15)的 CPU (1503)根据报文的源 IP地址， 将报文分流给 SPU1 (131)的 CPU0 (1311)。后续 CPE1发来新的报文或者新的会话时， 由于报文的源 IP地址 即为 CPE1的 IP地址，所以这些报文仍然会被分流给 SPU1 (131)上的 CPU0 (1311)。如果接口 板 LPU (15)的接收器（1501)接收到的是 CPE2发送来的报文， 则发送给接口板的 CPU后， 接 口板的 CPU根据该报文的源 IP地址， 将报文分流给 SPUU131)上的 CPUU1313)。 为了清楚 的显示出一个完整的过程， CPE2发送的报文， 未在附图 5中示出。 由于 CPE2发送来的报文 的源 IP地址为所述 CPE2的 IP地址， 因此， CPE2发送的新的报文或者新的会话也会被分流 至 IJSPUl (131)上的 CPU1 (1313)。 也就是说， 同一个 CPE下的所有终端发出的报文会被分流 给同一个业务板的同一个 CPU处理。

步骤 3， 业务板的 CPU对接收到的报文进行处理。

为了描述方便，将接收到接口板分流的报文的 CPU称之为第一 CPU。如果第一 CPU接收 到的报文是 CPE发送的第一个会话的第一条报文 （第一报文）， 第一 CPU查找 NAT策略， 根 据第一报文的特性， 获得需要进行网络地址转换的公网 IP地址的 ID号， 对所述公网 IP地 址的 ID号进行哈希计算， 得到负责管理需要进行网络地址转换的端口资 源的 CPU (第二 CPU)。 所述报文的特性可以包含所述报文的 ACL信息， 报文的源 IP、 目的 IP、 源端口、 目 的端口以及协议等五元组信息， 以及 NAT类型等信息中的一种或者多种。根据报文的 特性 确定进行网络地址转换的 IP地址的方法与现有实现方式相近似， 在此不再详述。 所述第 一 CPU和所述第二 CPU可以位于同一个业务板， 也可以位于不同的业务板。

所述 NAT策略可以预先写入并保存到控制板（11)的存 储器（1103)中， 当第一 CPU接收 到第一报文后，向控制板（11)的存储器（1103)� ��取 NAT策略获得需要进行网络地址转换的 公网 IP地址的 ID号， 对所述公网 IP地址的 ID号进行哈希计算， 得出端口资源对应的 CPU 号。 所述 NAT策略也可以预先写入并保存到各业务板的存 储器中， 当第一 CPU接收到第一 报文后，向所在的业务板的存储器读取 NAT策略获得需要进行网络地址转换的公网 IP地址 的 ID号， 对所述公网 IP地址的 ID号进行哈希计算， 得出端口资源对应的 CPU号。

如果计算出的第二 CPU与所述第一 CPU是同一个 CPU, 则转至步骤 4继续处理。 如果计 算出的第二 CPU与所述第一 CPU不是同一个 CPU, 则转至步骤 5继续处理。

如附图 4所示，业务板 SPUU131)的 CPU0 (1311)模块（即第一 CPU)接收到接口板 LPU (15) 发送的 CPE1的报文时， 如果接收到的报文是 CPE1发送的第一个会话的第一条报文， 业务 板 SPU1 (131)的 CPU0 ( 1311)根据报文的 ACL信息得到进行网络地址转换的公网 IP地址的 ID 号为 199， 对所述 IP地址的 ID进行哈希计算， 得到管理该端口资源的 CPU为 SPU0 (135)的 CPU2 (1353) (即第二 CPU)。此时第二 CPU与第一 CPU不是同一个 CPU,则转至步骤 5继续处理。

步骤 4，如果第二 CPU与所述第一 CPU是同一个 CPU,则所述第一 CPU为发送所述第一报 文的用户驻地设备分配 N个端口资源， 继续执行步骤 8。

如果管理端口资源的业务板的 CPU (第二 CPU ) 就是接收报文的业务板的 CPU (第一

CPU) , 所述第一 CPU为发送所述第一报文的用户驻地设备分配 N个端口资源。 另外， 所述 第一 CPU还保存所述 N个端口资源的使用状态，例如以用户表的形� �记录分配的 N个端口资 源的使用状态以及与对应的 CPE之间的对应关系， 该用户表存储在第一 CPU所在的业务板 的存储器中。

步骤 5，如果计算出的第二 CPU与所述第一 CPU不是同一个 CPU,则第一 CPU将所述第一 报文转发给所述第二 CPU。

如果管理端口资源的业务板的 CPU (第二 CPU)与接收报文的业务板的 CPU (第一 CPU) 不是同一个 CPU, 则接收报文的业务板的 CPU把接收到的报文转发给管理端口资源的业务 板的 CPU。 在本实例中， SPU1 (131)的 CPU0 (1311)将接收到的 CPE1发送的所述第一报文转 发给 SPU0 (135)的 CPU2 (1353)。

步骤 6， 所述第二 CPU给该发送所述第一报文的 CPE分配 N个端口资源。

在本实例中， SPU0 (135)的 CPU2 (1353)接收到的第一报文后， 给发送该第一报文的 CPE1分配 N个端口资源。

歩骤 7， 所述第二 CPU将分配的所述 N个端口资源以及所述第一报文发送给所述第� � CPU。

在本实施例中， SPU0 (135)的 CPU2 (1353)将 N个端口资源以及第一报文发送给 SPU1 (131)的 CPU0 (1311)。

步骤 8，第一 CPU从分配的 N个端口资源中选取一个端口资源对所述第一� �文进行网络 地址转换。

所述第一 CPU从接收到的第二 CPU分配的 N个端口资源中，选取一个端口资源对所述第 一报文进行网络地址转换。 另外， 所述第一 CPU保存所述 N个端口资源的使用状态， 以及 保存所述第一报文所在会话的会话状态， 剩余的 N-1个端口供该 CPE后续其它新建会话的 报文进行 NAT转换时使用。

如图 4所示， SPU1 (131)的 CPU0 (1311)从 SPU0 (135)的 CPU2 (1353)分配的 N个端口资源 中选取一个端口资源对 CPE1发送的第一个会话的第一条报文进行 NAT转换。 所述第一 CPU 保存所述 N个端口资源的使用状态， 并定时进行更新。

步骤 9， 第一 CPU将进行网络地址转换后的第一报文， 通过接口板发送到外部网络。

SPU1 (131)的 CPU0 (1311)模块将进行网络地址转换后的第一报文， 通过接口板（15) 发送到外部网络。

如图 4中所示的方法， 控制板将端口资源的管理和分配转移给业务板 的 CPU来管理和 分配， 且某个端口资源由唯一的一个 CPU管理， 避免了控制板成为端口资源分配的瓶颈， 以及端口资源分配和管理复杂的问题。 另外， 对报文进行网络地址转换的整个过程中， 由业务板的多个 CPU来共同参与，这样既能解决分布式系统端口 资源的管理和分配冲突的 问题， 又可以提高端口利用率， 让尽可能多的 CPU参与地址池管理， 充分发挥出分布式架 构的优势。

另外， 为了充分利用分布式系统的优势， 提高端口资源的利用率， 在上述步骤 4中， 所述第一 CPU为所述发送第一报文的 CPE分配 N个端口资源后， 保存所述 N个端口资源的使 用状态，例如以用户表的形式记录 N个端口资源的使用状态以及与对应的 CPE的对应关系， 并定时更新所述用户表。当在预定的时间范围 内，所述 N个端口资源的使用状态不再有新 的更新时， 所述第一 CPU释放所述 N个端口资源， 用于再次分配。 类似的， 在上述步骤 6 中，所述第二 CPU为所述发送第一报文的 CPE分配 N个端口后，第二 CPU保存所述 N个端口资 源的使用状态， 例如以用户表的形式记录分配的 N个端口资源的使用状态以及与对应的 CPE之间的对应关系， 并将用户表发送给所述第一 CPU。 同时， 所述第一 CPU在接收到所述 第二 CPU发送的第一报文和为所述发送第一报文的 CPE分配的 N个端口之后， 也保存所述 N 个端口资源的使用状态，例如以用户表的形式 保存所述 N个端口资源的使用状态以及与所 述发送第一报文的 CPE之间的对应关系， 定时更新用户表； 并定时发送刷新消息给第二 CPU, 避免所述 N个端口被回收重新分配。 当在预定的时间范围内， 第二 CPU保存的 N个端 口资源的使用状态没有新的更新时，所述第二 CPU释放所述 N个端口资源，用于再次分配。

这样， 可以充分发挥分布式系统的优点， 各个 CPU之间的端口资源可以互相使用； 同 时不再使用的端口资源可以回收后重新分配， 提高了端口资源的利用率。

如果所述第一 CPU接收到的报文是所述用户驻地设备发送的第 一个会话的后续报文 时，则所述第一 CPU根据保存的会话表将后续报文发送到网络中 。根据会话表发送报文为 本领域技术人员所熟知的技术， 并且不是本发明重点所述， 在此不再详述。

如果所述第一 CPU接收到的报文是所述用户驻地设备发送的一 个新建会话的第一个 报文， 则第一 CPU从分配的 N-1个端口资源中取出一个端口资源对新建会话 的第一个报文 进行网络地址转换， 并将网络地址转换后的新建会话的第一个报文 通过接口板发送到外 部网络。也就是说从分配的 N个端口资源中， 除了已经分配给第一报文的端口资源以外的 其他端口资源（即 N-1个端口资源）中， 选择一个端口资源对第三报文进行网络地址转 换。 这样，第一 CPU接收到所述用户驻地设备发送的新建会话的 第一个报文时，不需要再把接 收到的新建会话的第一个报文转发给第二 CPU, 这样节省了业务板 CPU的流量消耗， 减轻 了业务板 CPU的负担，并加快了报文处理的时间。第一 CPU从分配的 N-1个端口资源中取出 一个端口资源对新建会话的第一个报文进行网 络地址转换后， 更新存储的用户表和会话 表， 并发送刷新消息给第二 CPU所在业务板的存储器刷新所存储的用户表。

在本实施中，当 SPUU131)的 CPU0 (1311)模块接收到的报文是 CPE1发送的一个新建会 话的第一个报文时， SPU1 (131)的 CPU0 (1311)从 SPU0 (135)的 CPU2 (1353)分配的 N-1个端口 资源中取出一个端口资源对新建会话的第一个 报文进行网络地址转换， 并将网络地址转 换后的新建会话的第一个报文通过接口板发送 出去。 即除了已经分配给 CPE1发送的第一 个会话的第一个报文的端口资源之外的其他的 端口资源中， SPUU131)的 CPU0 (1311)从剩 下的 N-1端口资源中选取一个端口资源对新建会话的 第一个报文进行网络地址转换。 SPU1 (131)的 CPU0 (1311)将新的会话状态保存到 SPU1的存储器中，并发送刷新消息给 SPU0 的存储器刷新所存储的用户表。

本发明通过将 NAT端口资源分配到不同业务板的 CPU，由这些 CPU负责管理和分配端口 资源， 避免了控制板成为端口资源的瓶颈， 也避免了端口管理的冲突问题， 充分发挥了 分布式系统的优势， 提高了端口资源的利用率。

如果第一 CPU接收到所述用户驻地设备 E发送的新的新建会话的第一条报文时， 第二 CPU为该 CPE分配的 N个端口资源已经全部被使用，没有剩余的端� �资源可以使用了。可以 参照当第一 CPU接收到 CPE发送的第一个会话的第一条报文时的处理方 式。 当接收到报文 的业务板的 CPU (第一 CPU) 与管理端口资源的业务板的 CPU (第二 CPU ) 不是同一个 CPU 时，第一 CPU该新的新建会话的第一条报文转发给第二 CPU。第二 CPU为该发送该报文的用 户驻地设备再分配 M个端口资源，并更新所在业务板的存储器中� �储的用户表， 即更新其 中记录的 CPE与分配的端口资源之间的对应关系。第二 CPU将新分配的 M个端口资源和所述 新的新建会话的第一条报文发送给第一 CPU，第一 CPU从接收到的 M个端口资源中选取一个 端口资源对所述新的新建会话的第一条报文做 网络地址转换， 将网络地址转换后的报文 通过接口板发送到外部网络。另外， 第一 CPU会更新存储的会话状态， 并定时发送刷新新 消息给第二 CPU更新第二 CPU所在业务板的存储器的存储的用户表， 以保证对应端口块资 源不会被第二 CPU回收。 当所述接收到报文的业务板的 CPU (第一 CPU)与管理端口资源的 业务板的 CPU (第二 CPU)是同一个 CPU时， 第一 CPU为发送该报文的用户驻地设备再分配 M 个端口资源，更新业务板的存储器中存储的用 户表，再从分配的 M个端口资源中选择一个 端口资源对所述新的新建会话的第一条报文做 网络地址转换， 将网络地址转换后的报文 通过接口板发送到外部网络。另外， 第一 CPU会更新存储的会话状态和用户表。根据上述 方面， 实现了端口资源的增量分配。

本发明通过把对端口资源的管理和分配由控制 板转移给业务板的 CPU，并且某个端口 资源由一个 CPU独立管理，避免了控制板成为端口资源的管 理和分配的瓶颈，也简化了端 口资源管理和分配的复杂度。 并且在实现网络地址转换的过程中， 有多个业务板的 CPU 参与整个过程， 并且端口资源是动态分配的， 这样就充分发挥了分布式系统的优势。 并 且提高了端口资源的利用率。

本发明技术方案中提示的端口资源的管理和分 配方法也可以适用于普通的网络地址 转换设备。 只要是将端口资源的管理和分配的控制权由控 制板转移到业务板， 即为本发 明的技术方案所涵盖。

本领域普通技术人员可以意识到， 结合本文中所公开的实施例描述的各示例的单 元 及方法步骤， 能够以电子硬件、 或者计算机软件和电子硬件的结合来实现。 这些功能究 竟以硬件还是软件方式来执行， 取决于技术方案的特定应用和设计约束条件。 专业技术 人员可以对每个特定的应用来使用不同方法来 实现所描述的功能， 但是这种实现不应认 为超出本发明的范围。

所述功能如果以软件功能单元的形式实现并作 为独立的产品销售或使用时， 可以存 储在一个计算机可读取存储介质中。 基于这样的理解， 本发明的技术方案本质上或者说 对现有技术做出贡献的部分或者该技术方案的 部分可以以软件产品的形式体现出来， 该 计算机软件产品存储在一个存储介质中， 包括若干指令用以使得一台计算机设备 （可以 是个人计算机， 服务器， 或者网络设备等） 执行本发明各个实施例所述方法的全部或部 分步骤。而前述的存储介质包括： U盘、移动硬盘、只读存储器（ROM, Read-Only Memory), 随机存取存储器 （RAM, Random Access Memory), 磁碟或者光盘等各种可以存储程序代 码的介质。

以上实施方式仅用于说明本发明， 而并非对本发明的限制， 有关技术领域的普通技 术人员， 在不脱离本发明的精神和范围的情况下， 还可以做出各种变化和变型， 因此所 有等同的技术方案也属于本发明的范畴， 本发明的专利保护范围应由权利要求限定。