著录项信息
| 专利名称 | 一种报文限速方法 |
| 申请号 | CN200510075128.5 | 申请日期 | 2005-06-08 |
| 法律状态 | 暂无 | 申报国家 | 中国 |
| 公开/公告日 | 2006-01-25 | 公开/公告号 | CN1725732 |
| 优先权 | 暂无 | 优先权号 | 暂无 |
| 主分类号 | H04L12/56 | IPC分类号 | H;0;4;L;1;2;/;5;6查看分类表>
|
| 申请人 | 杭州华为三康技术有限公司 | 申请人地址 | 浙江省杭州市滨江区长河路466号
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
| 权利人 | 新华三技术有限公司 | 当前权利人 | 新华三技术有限公司 |
| 发明人 | 王俊 |
| 代理机构 | 北京集佳知识产权代理有限公司 | 代理人 | 逯长明 |
摘要
本发明涉及一种报文限速方法,包括:A、预设时间窗宽度及其允许通过报文的数量;B、获取当前系统时刻,并根据前一个时间窗截止时刻计算当前时间窗已过时间;C、判断当前时间窗已过时间是否小于时间窗宽度,若否,则允许当前时间窗中的报文通过,并更新当前时间窗截止时刻,结束;若是,执行步骤D;D、判断当前时间窗已通过报文数量是否大于允许通过的报文数量,若是,直接丢弃超标的报文,结束;否则,允许当前时间窗正常接收上送的报文直至达到预设通过的数量。本发明通过对超标的报文进行流量限速或流量整形,以达到优化CPU资源使用、在系统遭受广播风暴或黑客攻击时对CPU进行保护等问题。
1、一种报文限速方法,其特征在于,包括步骤:
A2、预设时间窗宽度和时间窗内允许通过的报文数量;
B2、获取当前系统时刻,并根据前一个时间窗截止时间计算当前时间窗 的已过时间;
C2、判断当前时间窗的已过时间是否小于时间窗宽度,若否,则允许当 前时间窗中的报文通过,并更新当前时间窗的截止时刻,结束;若是,执行 步骤D2;
D2、判断当前时间窗已通过报文的数量是否大于预设的允许通过的报文 数量,若是,直接丢弃超标的报文,结束;否则,允许当前时间窗正常接收 上送的报文直至达到预设通过的数量。
2、根据权利要求1所述报文限速方法,其特征在于,该方法是嵌入到收 发报文任务中的。
3、根据权利要求2所述报文限速方法,其特征在于,在步骤A2之前, 所述收发报文任务包括对接收到的报文进行过滤处理。
技术领域\n本发明涉及报文的处理技术领域,特别是涉及一种报文限速方法。\n背景技术\n随着通信芯片技术的迅速发展,目前包括路由器、以太网交换机等在内 的数据通信设备处理速度越来越快,端口密度也越做越大,支持的功能、协 议特性也越来越丰富。需要设备的CPU处理的各种协议报文、中断、消息等 也越来越多。而这些协议报文一方面是由CPU接收后,进行解析,然后放到 相应的软件协议处理单元的报文处理队列中等待处理;另一方面,现在的CPU 处理速度也越来越快,在有的设备上也出现因为短时间内CPU上送协议栈的 报文速度太快而导致一些协议处理单元的报文处理队列溢出和内存占用太多 等问题。\n在上述设备中,特别是低端路由器、以太网交换机设备等一般是单CPU 架构,CPU除了处理上述任务外,还需要处理很多重要的工作:比如响应命 令行串口的输入、输出,执行相应的命令,对设备的单板操作系统进行任务 调度和维护,对硬件转发芯片和外围设备的状态进行维护,内存和FLASH、 SRAM等各种存储器读写等,对路由器来说还可能需要由CPU进行报文转发。 这样在网络流量大,运行的协议特性较多时CPU就经常处于高负荷甚至满负 荷状态,在这种情况下再接收报文时,会出现串口响应慢、协议报文丢失、 动态路由丢失和动态地址解析协议(ARP,Address Resolution Protocol)丢失 等问题。如何在大流量情况下,尤其是在网络存在广播风暴或者设备遭受攻 击时,有效的地利用CPU资源,保证系统运行稳定是以太网交换机设备需要 解决的重要问题。\n从目前对以太网交换机设备的CPU工作情况分析可知,对CPU接收报文进 行限制是优化CPU资源利用的主要手段之一。因为有许多报文都要求上送CPU 处理,但是其中有些报文例如ARP广播报文是会被重复送到CPU的,而实际上 对一个IP地址到MAC地址的映射关系的建立,CPU只需要收到一个ARP报文 即可。而且往往很多以太网交换机设备因为各种原因都将广播和多播报文上 送CPU,这在网络上有广播风暴的时候对设备的CPU造成很大的压力。\n目前,对于报文的控制方法主要有三种。\n第一种是CPU接收报文限制的方法,该方法是从转发芯片硬件设计上做一 些控制,例如Intel公司的IXE2412芯片,对互联网组管理协议(IGMP,Internet Group Management Protocol)、ARP报文都有单独的队列管理,通过寄存器设 置来保证这些报文能够得到优先处理,而对一般的广播、多播报文则给以较 低优先级,在CPU工作繁忙时对低优先级报文进行随机丢弃。但问题是目前 很多ASIC转发芯片都没有提供这种硬件上的CPU收包分类控制功能,或者提 供的控制功能有限,无法满足目前以太网交换机设备支持丰富协议特性的需 要。\n第二种是采用流分类的方法来控制报文的流量。所述方法通过设置接入控 制列表ACL对各种报文上送CPU进行限制以及带宽保证。但基于上述第一种 方法的原因,要支持较多的协议特性需要添加几十条甚至更多的ACL表项, 这对硬件流分类资源占用太大;并且还受一些转发芯片的流分类处理能力限 制(能够支持的从报文中提取的流分类关键字的数量、字段位置有限),还 有些协议报文无法通过流分类来识别和控制。\n第三种是采用软件方法对上送CPU的报文进行限制和带宽保证。所述采 用软件方法主要是对上报CPU报文进行限制是采用定时器,并用专门的单元 来监控定时器的运行。所述方法包括:首先,根据用户需要编写定时器的回 调函数;其次,向系统申请硬件定时器资源,如果申请失败,则结束;再次, 预设定时器时间间隔和定时器的超时的回调函数,启动定时器;最后,定时 器自动运行,每次超时时就自动调用设定的回调函数作相应的报文限速或者 流量整形操作。\n由上述分析可知,现有技术的缺点是:1)不能有效的利用CPU资源;2) 需要占用硬件的定时器资源,且预设定时器超时的回调函数需要消耗大量的 软件资源,且增加了操作系统的复杂度,增加操作系统任务调度的工作量和 风险。3)在系统遭受广播风暴或黑客攻击时不能有效的对CPU进行保护。\n发明内容\n本发明解决的技术问题是提供一种报文限速方法,该方法以解决在CPU 接收到的报文超过预定的报文数量时,通过对超标的报文进行流量限速或者 流量整形,从而达到优化CPU资源使用、在系统遭受广播风暴或黑客攻击时 对CPU进行保护等问题。\n为解决上述问题,本发明提供一种报文限速方法,所述方法包括步骤:\nA1、预设时间窗宽度和该时间窗内允许通过的报文数量;\nB1、获取当前系统时刻,并根据前一个时间窗截止时间计算当前时间窗 的已过时间;\nC1、判断当前时间窗的已过时间是否小于时间窗的宽度,若否,则允许 当前时间窗中的报文通过,并更新当前时间窗的截止时刻,结束;若是,执 行步骤D1;\nD1、判断当前时间窗已通过的报文数量是否大于允许通过的报文数量, 若是,计算超出允许通过的报文数量,并对其进行流量延迟处理后允许通过; 否则,允许当前时间窗正常接收上送的报文直至达到预设通过的数量。\n该方法是嵌入到收发报文任务中的。\n在步骤A1之前,所述处理器对接收到的报文进行过滤处理。\n步骤D1中所述计算超出允许通过的报文数量,并对其进行流量延迟处理 的实现过程包括:\n41)通过当前时间窗接收到的报文数量与预设的单位时间窗内允许通过 的报文数量之差来计算超出允许通过的报文数量;\n42)根据单位时间窗内允许通过的报文速率来计算超出允许通过的报文 需要延迟的时间;\n43)将所述超出允许通过的报文根据所述需要延迟的时间进行延迟处理;\n44)当到达延迟时间时允许所述超出允许通过的报文通过,并更新当前 时间窗的截止时刻。\n步骤42)中所述计算超出允许通过的报文需要延迟的时间的计算公式为: 需要延迟的时间=(超过预设的单位时间窗内允许通过的报文数量-单位时 间窗内允许通过的报文数量)/单位时间允许接收报文的数量*时间窗宽度。\n另外,本发明还提供一种报文限速方法,所属方法包括步骤:\nA2、预设时间窗宽度和时间窗内允许通过的报文数量;\nB2、获取当前系统时刻,并根据前一个时间窗截止时间计算当前时间窗 的已过时间;\nC2、判断当前时间窗的已过时间是否小于时间窗宽度,若否,则允许当 前时间窗中的报文通过,并更新当前时间窗的截止时刻,结束;若是,执行 步骤D2;\nD2、判断当前时间窗已通过报文的数量是否大于预设的允许通过的报文 数量,若是,直接丢弃超标的报文,结束;否则,允许当前时间窗正常接收 上送的报文直至达到预设通过的数量。\n该方法是嵌入到收发报文任务中的。\n在步骤A2之前,所述处理器对接收到的报文进行过滤处理。\n与现有技术相比,本发明具有以下有益效果:本发明通过设置时间窗宽 度和单位时间窗内通过的数量来对上送CPU报文进行流量限制或流量整形, 以保证在单位时间窗内上送报文的数量基本稳定,从而有效的保证CPU在大 流量报文的冲击下降低CPU的使用率,同时又不影响各种协议功能的正常运 行。本发明与现有技术通过创建定时器和收发报文任务的软件限制方式相比, 有实现简便、占用资源少,限速时间窗、最大流量阈值等易于在实际运行中 实时调整等优点。特别是在某在交换设备(比如以太网交换机)上应用了本 发明所述的方法,不但保证在单位时间窗内上送报文的数量基本稳定,而且 还能较好地实现对CPU的保护,显著地降低了CPU使用率,同时不影响各种 协议功能的正常运行。此外,在CPU负载较重时,最好分队列进行操作,也 就是将每个报文转发到CPU的硬件队列,并在各队列中设定不同的阈值,以 保证优先级较高的重要报文先上送,以避免重要的报文被丢弃。\n附图说明\n图1是本发明报文限速方法的一种流程图;\n图2是本发明报文限速方法的另一种流程图;\n图3是本发明报文限速方法的优化流程图。\n具体实施方式\n本发明的核心是通过设置时间窗内通过报文的流量来控制CPU接收报文 的流量,并对超出单位时间窗内报文采取相应的惩罚机制,即延迟处理,以 保证单位时间窗内上送的报文数量基本稳定,从而达到优化CPU资源的使用以 及在系统遭受广播风暴或黑客攻击时对CPU进行保护的目的。\n本发明提供一种通用简便的报文限速方法,该方法通过软件手段对上送的 CPU报文进行流量限速或流量整形,适用于各种类型的CPU和软件操作系统。 下面以在嵌入式操作系统Vxworks上的实现为例来进一步讲述该发明的技术 方案。\n请参考图1,为本发明报文限速方法的流程图,该方法在控制过程中, 以太网交换机设备运行时会运行一个专门负责接收报文的任务,本发明的先 将相应的代码嵌入到该收发报文任务的处理函数中,在每次报文接收过程中 得到处理。所述方法具体包括:\n步骤S10:预设时间窗的宽度和时间窗内允许通过报文的数量;\n步骤S11:获取当前系统时刻,并根据前一个时间窗截止时间计算当前时 间窗的已过时间;\n步骤S12:判断当前时间窗的已过时间是否小于时间窗的宽度,若否,则 允许当前时间窗中的报文通过,并更新当前时间窗的截止时刻,结束(步骤 S13);若是,执行(步骤S14);\n步骤S14:判断当前时间窗已通过报文的数量是否大于允许通过报文的数 量,若是,计算超出允许通过的报文数量,并对所述报文进行惩罚性延迟处 理后允许通过(步骤S15);否则,允许当前时间窗中的报文通过,并更新当 前时间窗的截止时刻(步骤S13)。\n在步骤S10之前,收发报文任务接收到上送CPU的报文,对上报CPU 的报文进行过滤处理,这是由于有些报文可能是系统不感兴趣的,或者某些 协议、功能模块要求将其丢弃的报文,则提前将其过滤掉。例如,如果系统 并未启动最短路径优先协议(OSPF,Open Short Path First),所述最短路径优 先协议是一种网络路由协议。在该步骤中,对于接收任务如果接收到OSPF 协议报文,就可以直接将其过滤掉,即在此步骤直接丢弃,不作下一步处理; 这样可以在收发报文任务处就限制一部分报文的流量控制。\n在步骤S10中,通过操作系统提供的处理函数来获取当前系统时刻,并将 其保存在变量ulNowTicks。比如,VxWorks系统可以使用sysTimeBaseIn函 数。所述处理函数中已预先嵌入本发明相应的代码,以便每次报文接收过程 中的得到相应的处理。在该步骤中所述当前时间窗的已过时间通过当前系统 时刻与上一个时间截止时刻之差来计算。其计算公式为:当前时间窗已过时 间ulTicksGo=当前系统时刻ulNowTicks一上一个时间窗截止时刻 ulOldTicks,其中,所述时间窗截止时刻是指当报文通过时间窗时所记录的时 刻。在初始启动时,上一个时间窗截至时刻初始化为0。所述时刻都是有Tick 来计数的。当当前时间窗接收报文时,并将其报文数量PacketsReceived加一, 其中,所述PacketsReceived初始化时预设为0。\n在步骤S12中,判断当前时间窗是否已经超时,即当前时间窗的已过时 间ulTicksGo是否小于预设的时间窗宽度ulTimeWindow,其中,所述时间窗 宽度是初始化时预设的,是根据系统性能和需求来设置的,并保存在全局变 量中,在运行中可以根据实际情况调整。\n若当前时间窗超时,也就是说当前时间窗的已过时间小于预设的时间窗宽 度时,则当前时间窗没有结束,再判断当前时间窗已通过报文的数量 PacketsReceived是否已经大于允许通过报文的数量PacketsPermit(步骤S14); 若是,则说明在该时间窗内正常接收的报文上送的数量已经超标,需要采取 流量控制措施,也就是说,当前时间窗内接收的报文数量已经超过初始化时 预设的单位时间窗内允许通过的报文数量PacketsPermit,为了优化CPU的资 源利用,本发明对超标的报文通过惩罚机制以控制其流量,来保证在平均单 位时间窗内上送的报文数量基本稳定(步骤S15)。其中所述单位时间窗内允 许通过的报文数量是根据系统性能和需求来设置,并保存在全局变量中,在 运行中可以根据实际情况调整,计算超出允许的报文数,其计算公式为:当 前单位时间窗内接收到的报文数量与预设的单位时间窗内允许通过的数量之 差为单位时间窗内超标的报文数量。\n其中,所述惩罚机制也就是需要对所计算出的超标报文进行一定流量延迟 处理,即“惩罚性”延时,以达到时间轴上的接收整形处理的效果。所述惩 罚性延迟的实现过程包括:\na.通过当前时间窗接收到的报文数量与预设的单位时间窗内允许通过的 报文数量之差来计算超出允许通过的报文数量;\nb.根据单位时间窗内允许通过的报文速率来计算超出允许通过的报文需 要延迟的时间;\nc.将所述超出允许通过的报文根据所述需要延迟的时间进行延迟处理;\nd.当到达延迟时间时允许所述超出允许通过的报文通过,并更新当前时 间窗的截止时刻。\n也就是说所述惩罚延迟是根据允许通过报文平均速率计算需要延时的时 间。而所述惩罚机制可以有多种,本发明目前实现的处理是:如果报文上送 速率较高,在不到时间窗的单位时间就超过了预设的单位时间窗内允许通过 的报文数量PacketsPermit,那就根据超过的报文数量PacketsReceived-单位 时间窗内允许通过的报文数量PacketsPermit,然后再除以单位时间窗内允许 接收报文数量PacketsPermit,最后再乘以预设的时间窗宽度ulTimeWindow, 就得到需要延时的时间,该时间也是以Tick计数。但是本发明并不限于所述 的惩罚机制,还可以通过其它的方式来实现。此外,对当前报文进行缓存, 并根据所计算的延时值,对当前的报文作延时处理;当到达延迟时刻时允许 当前的报文通过,即将该报文上送到协议栈进行处理。\n当当前时间窗已过的时间不小于时间宽度时,则结束当前时间窗,允许当 前报文通过,并对当前时间窗接收的报文数量清零(步骤S13)。以当前时刻 ulNowTicks作为新的当前时间窗截止时刻,即ulOldTicks等于ulNowTicks。 然后开始下一个处理循环。\n本发明通过上述过程来保证在单位时间窗内允许上送CPU的报文速率限 定在一定的时间范围内,如果短时上送CPU报文速率超标,则采取相应的“惩 罚”延迟机制,以保证平均单位时间窗上送CPU的报文数量基本稳定。在上 送CPU报文平均速率不大但偶尔有较大峰值速率时,本发明所述的方法可以 有效地实现对CPU的保护并可保证不丢失重要的报文。在延时过程中操作系 统可调度CPU处理其它任务。\n另外,本发明还提供另一种报文限速方法,其流程图详见图2,所述方法 包括步骤:\n步骤H10:预设时间窗的宽度和时间窗内允许通过报文的数量;\n步骤H11:获取当前系统时刻,并根据前一个时间窗截止时间计算当前 时间窗的已过时间;\n步骤H12:判断当前时间窗的已过时间是否小于时间窗的宽度,若否, 则允许当前时间窗中的报文通过,并更新当前时间窗的截止时刻,结束(步 骤H13);若是,执行(步骤H14);\n步骤H14:判断当前时间窗已通过报文的数量是否大于预设的允许通过 报文的数量,若是,直接丢弃超标的报文,结束(步骤H15);否则,允许当 前时间窗正常接收上送的报文直至达到预设通过的数量(步骤H16)。\n本发明所述的这种方法也可以保证将单位时间窗内允许上送CPU的报文 速率限制在一定的范围内。所述这种方法主要是在检测到上送CPU报文已经 超标时,直接丢弃该报文。虽然在实现过程中可能会丢包,但是,本方法在 设备运行协议繁多、CPU负载较重时可以有效的实现对CPU的保护。\n本发明所述的这种报文限速方法是对第一种报文限速方法的简化,其实 现步骤与第一种方法的实现步骤部分类似,具体为:\n在步骤H10之前,收发报文任务接收到上送CPU的报文,对上报CPU 的报文进行过滤处理,这是由于有些报文可能是系统不感兴趣的,或者某些 协议、功能模块要求将其丢弃的报文,则提前将其过滤掉。例如,如果系统 并未启动最短路径优先协议(OSPF,Open Short Path First),所述最短路径优 先协议是一种网络路由协议。在该步骤中,对于接收任务如果接收到OSPF 协议报文,就可以直接将其过滤掉,即在此步骤直接丢弃,不作下一步处理; 这样可以在收发报文任务处就限制一部分报文的流量控制。\n在步骤H10中,通过操作系统提供的处理函数来获取当前系统时刻,并将 其保存在变量ulNowTicks。比如,VxWorks系统可以使用sysTimeBaseIn函 数。所述处理函数中已预先嵌入本发明相应的代码,以便每次报文接收过程 中的得到相应的处理。在该步骤中所述当前时间窗的已过时间通过当前系统 时刻与上一个时间截止时刻之差来计算。其计算公式为:当前时间窗已过时 间ulTicksGo为当前系统时刻ulNowTicks减去上一个时间窗截止时刻 ulOldTicks,其中,所述时间窗截止时刻是指当报文通过时间窗时所记录的时 刻。在初始启动时,上一个时间窗截至时刻初始化为0。所述时刻都是有Tick 来计数的。当当前时间窗接收报文时,并将其报文数量PacketsReceived加一, 其中,所述PacketsReceived初始化时预设为0。\n在步骤H12中,判断当前时间窗是否已经超时,即当前时间窗的已过时 间ulTicksGo是否小于预设的时间窗宽度ulTimeWindow,其中,所述时间窗 宽度是初始化时预设的,是根据系统性能和需求来设置的,并保存在全局变 量中,在运行中可以根据实际情况调整。若当前时间窗的已过时间小于预设 的时间窗宽度,则当前时间窗内有结束,再判断当前时间窗已通过报文的数 量是否已经大于允许通过的数量,如果没有超过,则将该时间窗内正常接收 报文的数量正常上送,直至达到预定的限额才停止上送,并结束本次处理; 如果超过,则说明该时间窗内正常接收报文的数量已经超标,直接丢弃所述 超标的报文。\n若当前时间窗的已过时间不小于预设的时间窗宽度,则允许当前时间窗内 的报文通过,并结束当前时间窗和对当前时间窗的数量清零,以及更新当前 时间窗的截止时间ulOldTicks。\n本方法所述过程也能有效的保证在单位时间窗内将允许上送CPU的报文 速率限定在一定的范围内。若单位时间窗内上送CPU报文超标则报文被直接 丢弃。该方法可能会丢包,但是可以也很好地实现对CPU的保护,因为在设 备运行协议繁多、支持特性丰富,CPU负载较重时比较适用。\n此外,本发明再提供一种报文限速方法,该方法对于CPU负荷较重时为 优化报文限速方法,其流程图详见图3。该方法在CPU负载较重时,采用分 队列进行操作,并在各队列中设定不同的阈值,以保证优先级较高的重要报 文先上送,以保证重要报文基本不被丢弃。其中,所述用分队列的实现方式 也就是对每个报文转发到CPU的硬件队列,都采用如图3所述报文流量控制 的方法,该方法可以对高优先级队列设定较大的单位时间报文通过数量,对 低优先级队列设定较小的单位时间报文通过数量,来实现对CPU保护的同时, 对不同业务的分级控制和服务。\n如图3所示的报文限速方法的优化流程包括步骤:\n步骤M10:分别预设各个队列的时间窗宽度和该时间窗内分别允许通过 的报文数量;\n步骤M11:获取当前系统时刻,并根据前一个时间窗截止时间计算当前 时间窗的已过时间;\n步骤M12:分别判断当前时间窗的已过时间是否小于时间窗的宽度,若 否,则允许当前时间窗中的报文通过,并更新当前时间窗的截止时刻,结束 (步骤M13);若是,执行步骤M14;\n步骤M14:、分别判断当前时间窗已通过的各个队列的报文数量是否分别 大于各个队列允许通过的报文数量,若是,分别计算超出允许通过的报文数 量,并对其进行延迟处理后允许通过(步骤M15);否则,允许各个当前时间 窗中的报文通过,并更新当前时间窗的截止时刻(步骤M13)。\n所述方法与上述方法的相同之处,在这里不再赘述,其不同之处为:先 将接收到的报文按照报文的类型或优先级等分成不同的各个队列,然后再根 据各个队列优先级的不同来预设单位时间窗内允许通过的报文数量,对高优 先级队列设定较大的单位时间窗内通过的报文数量,对低优先级队列设定较 小的单位时间窗内通过的报文数量,从而当当前时间窗已通过的各个队列的 报文数量大于各个队列允许通过的报文数量时,先计算各个队列超出允许通 过的报文数量,然后再对此进行流量延迟处理后允许其通过。其中对于超标 的数据报文通过流量控制(即流量延迟处理)的具体实现过程包括:通过各 个队列当前时间窗接收到的报文数量与预设的单位时间窗内允许通过的报文 数量之差来计算各个队列超出允许通过的报文数量;根据各个队列单位时间 窗内允许通过的报文速率来计算各个队列超出允许通过的报文需要延迟的时 间,其计算各个队列延迟的时间的计算公式为:需要延迟的时间=(超过预 设的单位时间窗内允许通过的报文数量-单位时间窗内允许通过的报文数 量)/单位时间允许接收报文的数量*时间窗宽度;将所述超出允许通过的报 文根据所述需要延迟的时间分别进行延迟处理;当到达延迟时间时允许所述 各个队列超出允许通过的报文通过,并更新各个队列当前时间窗的截止时刻。\n以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普 通技术人员来说,在不脱离本发明原理的前提下,还可以作出若干改进和润 饰,这些改进和润饰也应视为本发明的保护范围。
法律信息
- 2017-05-31
专利权人的姓名或者名称、地址的变更
专利权人由杭州华三通信技术有限公司变更为新华三技术有限公司
地址由310053 浙江省杭州市高新技术产业开发区之江科技工业园六和路310号华为杭州生产基地变更为310052 浙江省杭州市滨江区长河路466号
- 2008-11-12
- 2006-03-22
- 2006-01-25
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 |
1
| |
2005-01-19
|
2003-06-18
| | |
2
| |
2005-01-26
|
2004-05-10
| | |
3
| |
2004-09-01
|
2004-02-23
| | |
4
| |
2005-04-13
|
2004-10-08
| | |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |