CN1529481A - 网络处理器内部实现分布式应用层转换网关的方法 - Google Patents

网络处理器内部实现分布式应用层转换网关的方法 Download PDF

Info

Publication number
CN1529481A
CN1529481A CNA2003101010680A CN200310101068A CN1529481A CN 1529481 A CN1529481 A CN 1529481A CN A2003101010680 A CNA2003101010680 A CN A2003101010680A CN 200310101068 A CN200310101068 A CN 200310101068A CN 1529481 A CN1529481 A CN 1529481A
Authority
CN
China
Prior art keywords
packet
protocol
bag
ftp
ipv4
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CNA2003101010680A
Other languages
English (en)
Other versions
CN1275443C (zh
Inventor
孙红兵
李忠诚
殷昭印
石晶林
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Institute of Computing Technology of CAS
Original Assignee
Institute of Computing Technology of CAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Institute of Computing Technology of CAS filed Critical Institute of Computing Technology of CAS
Priority to CNB2003101010680A priority Critical patent/CN1275443C/zh
Publication of CN1529481A publication Critical patent/CN1529481A/zh
Application granted granted Critical
Publication of CN1275443C publication Critical patent/CN1275443C/zh
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明涉及计算机网络通信技术领域的网络处理器平台的域名服务转换网关和文件传输协议转换网关方法,步骤如下:步骤1:接收端口接收数据包;步骤2:在微引擎上对接收的数据包进行地址和协议转换;步骤3:检查协议端口号,发现是域名服务包或者是文件传输协议命令包,采用捎带技术,构造数据包,并将构造后的数据包送StrongARM处理;步骤4:StrongARM对域名服务包调用域名服务转换网关模块处理,对文件传输协议命令包调用文件传输协议转换网关模块处理;步骤5:经应用层网关转换模块处理后的数据包送到发送队列等待发送。该方法在网络处理器平台上的实现进行了测试,结果证明用该方法实现的NAT-PT可以实时处理IPv4网络和IPv6网络的互访。

Description

网络处理器内部实现分布式应用层转换网关的方法
技术领域
本发明涉及计算机网络通信技术领域,特别是一种网络处理器内部实现分布应用层转换网关的方法,是一种在网络处理器平台上为提高IPv4(Internet Protocol Version 4)和IPv6(Internet Protocol Version 6)协议转换性能,实现片内分布式应用层转换处理的一种方法。
背景技术
IPv6协议是取代IPv4协议的下一代互联网络协议,它具有许多新的特性与功能。但是IPv6与现在因特网上广泛应用的IPv4协议不兼容,例如地址长度、包头格式不同等等,所以IPv4向IPv6过渡将是一个长期的过程。在这个过程中如何实现平滑过渡是采用IPv6协议的人们首先面临的问题。目前实现IPv4和IPv6互通的典型代表机制是:NAT-PT(Network addresstransition-Protocol translation,地址转换-协议翻译机制)和TRT(TransportRelay transition,传输层中继翻译机制)。
NAT-PT就是在做IPv4/IPv6地址转换的同时在IPv4分组和IPv6分组之间进行报头和语义翻译。适用于纯IPv4站点和纯IPv6站点之间的通信。对于一些内嵌地址信息的高层协议,如域名服务和文件传输协议,NAT-PT需要和应用层的网关协作来完成翻译。NAT-PT的具体规定可以参见RFC2766。RFC 2766主要是规定了如何实现地址翻译以及有域名服务转换网关支持的情况下两个网络中的节点如何实现通信。应用层转换网关(Applicationlevel gateway),是指在应用层进行转换处理的网关。当前大多数IPv4/IPv6转换技术都要涉及的应用层网关转换包括:域名服务转换网关和文件传输协议转换网关等。如果没有域名服务转换网关的支持,NAT-PT只能实现由IPv6发起的与IPv4之间的通信,反之,包就会被丢弃。TRT技术是在传输层进行中继的一种转换技术。它的实现如果没有应用层转换网关的支持也只能实现IPv6发起的通信。对于文件传输协议中用到的PORT等负载中含有IP地址的命令,穿越两种采用不同IP协议的网络时也必须要对负载中的IP地址进行翻译。
域名服务转换网关的相关规定见RFC2694,该规范主要是对域名服务转换网关的功能进行了规定。通常的域名服务再传输层采用UDP(用户数据报协议),文件传输协议在传输层采用TCP(传输控制协议)。如何实现应用层转换网关人们有不同的见解。一些人主张应用层转换网关与NAT-PT结合在一起实现,但是也有部分人认为为了避免应用层转换的实现影响整个NAT-PT的性能,建议把应用层转换网关做一个独立的代理服务器运行。
NAT-PT就像其他网络设备一样,可以在通用处理器上进行软件编程来实现,也可以用专用集成电路(ASIC)芯片硬件来实现。软件编程实现的好处是实现起来比较简单,也比较灵活,升级更新都比较容易进行。其缺点就是效率比较低,当网络速度比较慢的时候,还可以承担,但是对于骨干网络上庞大的数据流量显得力不从心,会构成网络瓶颈。相反,用专用集成电路芯片来实现,可以达到很高的性能,但是,实现起来要复杂得多,且开发时间长。由于专用集成电路芯片不能编程,所以一旦实现就不易改变,难以升级换代。通过对比分析,基于网络处理器的实现方式就显示了其巨大的优越性。
IXP1200系列是Intel公司推出的采用IXA框架的核心产品,它在结构上分为控制和数据两个平面,控制平面是一个StrongARM处理器,主要是负责维护系统信息和协调处理部分工作,数据平面则是由多个RISC处理器——微引擎(MicroEngine)和其他专用硬件组成,负责利用数据平面下发的微代码和命令,直接处理网络数据。其基本结构为:一个主频最高可达232M赫兹的处理核心StrongARM、6个RISC结构的可编程微引擎(每个微引擎又包含4个硬件线程)、一条64位的IX Bus(主频最高可达85MHz)、32位的SRAM接口单元(工作频率为核心频率的一半)、64位的SDRAM接口单元(工作频率为核心频率的一半)、一个32位的PCI总线接口单元(主频最高可达66M赫兹)。
发明内容
本发明的目的在于提供一种在网络处理器平台上为提高转换性能,在网络处理器内部实现分布式应用层转换网关转换的方法。此次提出的这种方法主要是合理利用网络处理器硬件平台的多处理器、硬件多线程的特性,对域名服务和文件传输等应用层协议进行分布式转换处理。网络处理器中微引擎负责接收数据包并对收到的数据包在网络层进行预处理。需要进行应用层转换处理的数据包通过微引擎和StrongARM间的数据通道送到StrongARM上进行处理。StrongARM根据端口号判断收到的是哪种应用层数据包而决定调用相应的应用层处理模块。为了实现StrongARM上的应用层网关转换处理,在数据包发送到StrongARM上的时候采用捎带技术,为应用层的转换提供必要的信息。这里的捎带技术,指的是一种传递信息的一种技术,即在正常传送的数据包的后面捎带该数据包经过地址转换前的源地址、源端口、目的地址、目的端口等信息。我们对该方法在Intel IXP1200网络处理器平台上的实现进行了测试,结果证明用该方法实现的应用层转换网关结合数据层面地址转换功能,可以实时高效地处理IPv4网络和IPv6网络的互访,支持的服务包括了:WWW、TELNET、email、DNS、FTP。该发明中的捎带技术为StrongARM和微引擎间的通信提供了一种有效的通信方式。
本发明的技术方案:
基于网络处理器平台的一种域名服务转换网关和文件传输协议转换网关实现方法,通过对需要应用层网关转换处理的数据包进行分布式处理,以保证整个NAT-PT系统的转换性能,其特征在于,具体步骤如下:
步骤1:接收端口接收数据包;
步骤2:在微引擎上对接收的数据包进行地址和协议转换;
步骤3:检查协议端口号,发现是域名服务包或者是文件传输协议命令包,采用捎带技术,构造数据包,并将构造后的数据包送StrongARM处理;
步骤4:StrongARM对域名服务包调用域名服务转换网关模块处理,对文件传输协议命令包调用文件传输协议转换网关模块处理;
步骤5:经应用层网关转换模块处理后的数据包送到发送队列等待发送。
其中步骤2对接收到的数据包,首先进行IP地址转换,包括包头协议格式的转换,然后执行步骤3。
其中步骤3采用捎带技术,捎带StrongARM上进行应用层网关转换处理时需要的源地址、源端口、目的地址。
其中步骤3将根据传输层的端口号判断包是否是域名服务包和文件传输协议命令包,如果是这两种包,则通过微引擎和StrongARM间的数据通道送到StrongARM核上处理。
其中步骤4将根据收到的包的类型是域名服务包还是文件传输协议命令包,判断是否调用域名服务转换网关处理模块,还是文件传输协议转换网关处理模块。
在实施IPv4和IPv6转换的设备中,通常需要应用层转换网关处理的包不仅需要在IP层进行地址和包头格式转换,还要对含有IP地址的负载进行翻译。如果将NAT与应用层转换网关集成在同一个系统中,而不合理设计均匀分配负载,将会对整个系统的转换性能构成瓶颈。本方法就是在把IP层转换和应用层转换网关功能集成在同一个系统的前提下,利用网络处理器的特点以及针对网络流量的特征设计一种既可以保障NAT-PT性能,又能提供高性能应用层转换网关的实现方法。本方法的主要思想就是对需要进行应用层转换网关处理的包进行分布式处理。将需要应用层转换网关处理的包首先经过网络处理器的微引擎进行NAT转换,转换微引擎会根据包的源和目的端口判断是否需要送控制层面处理,若是则通过微引擎和strong ARM间的通道送到strong ARM上处理。转换微引擎继续处理其它数据包。大多数网络数据包,都不需要经过应用层转换网关的处理,只需要在微引擎上进行NAT转换和包头协议翻译,然后直接由发送微引擎发送出去。网络处理器提供的硬件HASH保障了微引擎查找NAT表条目的速度,这些经过NAT转换处理的数据包,基本上可以达到线速。对于需要应用层转换网关处理的数据包,包头的处理也是在微引擎上实现的,strong ARM负责对包的载荷进行分析和转换。
附图说明
图1是本发明的从IPv6到IPv4的UDP包转换流程图。
图2是本发明的从IPv4到IPv6的UDP包转换流程图。
图3是本发明的从IPv6到IPv4的TCP包转换流程图。
图4是本发明的从IPv4到IPv6的TCP包转换流程图。
图5是本发明从IPv6到IPv4的TCP包转换时经微引擎送到StrongArm上的包格式图。
图1中,步骤s1微引擎上的微码处理程序从IPv6网络端口收到一个UDP数据包后,首先步骤s2根据IPv6地址查NAT表,取对应的IPv4地址进行相应的地址转换,将包头按照IPv4协议格式进行地址和协议转换,然后步骤s3微码处理程序根据传输层的服务端口号判断该数据包是否属于需要应用层进行转换的数据,如果不是,步骤s4微码处理程序会继续该数据包的处理,计算UDP的校验,然后将其通过IPv4端口发送出去;否则步骤s5该数据包将通过微引擎和StrongArm之间的通道送到StrongArm上进行处理,通常送到StrongArm上的UDP包都是域名服务数据包,所以应用层在收到这样的数据包后通常都会步骤s6调用域名服务协议转换处理模块进行处理,域名服务协议转换处理完成相应的协议转换处理后会步骤s7重新计算伪头校验和并将数据包从IPv4网络端口发送出去。
图2中,步骤s8微引擎上的微码处理程序从IPv4网络端口收到一个UDP数据包后,首先步骤s9根据IPv4地址查NAT表,取对应的IPv6地址进行相应的地址转换,将包头按照IPv6协议格式进行地址和协议转换,然后步骤s10微码处理程序根据传输层的服务端口号判断该数据包是否属于需要应用层进行转换的数据,如果不是,步骤s11微码处理程序会继续该数据包的处理,计算UDP的校验,然后将其通过IPv6端口发送出去,否则步骤s12该数据包将通过微引擎和StrongArm之间的通道送到StrongArm上进行处理,通常送到StrongArm上的UDP包都是域名服务数据包,所以应用层在收到这样的数据包后通常都会调用步骤s13域名服务协议转换处理模块进行处理域名服务协议转换处理完成相应的协议转换处理后会步骤s14重新计算伪头校验和并将数据包从IPv6网络端口发送出去。
图3中,步骤s15微引擎上的微码处理程序从IPv6网络端口收到一个TCP数据包后,首先步骤s16根据IPv6地址查NAT表,取对应的IPv4地址进行相应的地址转换,将包头按照IPv4协议格式进行地址和协议转换,然后步骤s17微码处理程序根据传输层的服务端口号判断该数据包是否属于需要应用层进行转换的数据,如果不是,步骤s18微码处理程序会继续该数据包的处理,计算伪头校验计算伪头校验,然后将其通过IPv4端口发送出去;否则步骤s19微引擎将会按照图5中描述的包格式,构造含有IPv4源地址、目的地址、源端口的数据包,该特殊数据包将通过微引擎和StrongArm之间的通道送到StrongArm上进行处理,应用层在收到这样的数据包后通常都会步骤s20调用文件传输协议转换处理模块进行处理,文件传输协议转换处理完成相应的协议转换处理后会步骤s21重新计算伪头校验和并将数据包从IPv4网络端口发送出去。
图4中,步骤s22微引擎上的微码处理程序从IPv4网络端口收到一个TCP数据包后,首先步骤s23根据IPv4地址查NAT表,取对应的IPv6地址进行相应的地址转换,将包头按照IPv6协议格式进行地址和协议转换,然后步骤s24微码处理程序根据传输层的服务端口号判断该数据包是否属于需要应用层进行转换的数据,如果不是,步骤s25微码处理程序会继续该数据包的处理,计算伪头校验,然后将其通过IPv6端口发送出去;否则步骤s26该数据包将通过微引擎和StrongArm之间的通道送到StrongArm上进行处理,通常送到StrongArm上的TCP包都是文件传输协议命令包,所以应用层在收到这样的数据包后通常都会步骤s27调用文件传输协议转换处理模块进行处理,文件传输协议转换处理完成相应的协议转换处理后会步骤s28重新计算伪头校验和并将数据包从IPv6网络端口发送出去。
图5中,描述的包格式只有当数据包在传输层采用TCP协议,并且包是从IPv6转换成IPv4的时候才会用到的包格式。微引擎送给StrongArm的包经过了包头地址格式转换,而在TCP数据包转换的过程中又需要用到IPv4源地址,目的地址和源端口,因此本发明在这里创造性地设计了该种包格式,在微引擎和StrongArm间提供了一种有效的信息传递方式。
具体实施方式
Intel IXP1200网络处理器在一个独立的芯片上集成了六个RISC处理器(MicroEngine)和一个StrongARM处理器。通常需要经过应用层转换网关处理的数据包,不仅要进行载荷内容分析与转换,还要记录载荷的状态。这些处理的复杂性决定了需要应用层转换网关处理的数据包全部放在微引擎上处理是不可行的。
通过对网络流量的分析发现,正常情况下域名服务数据包、文件传输协议命令包占整个Internet上数据包流量的比例并不是很大,并且在IPv6网络的系统设计方面进行优化可以尽量减少穿过转换网关要求进行应用层网关转换的数据包的流量。对于文件传输协议应用需要经过应用层网关转换的只有文件传输协议命令包。通常文件传输协议命令包只是在建立文件传输协议连接和结束连接的情况下才发生。因此这些数据包放到StrongARM上处理就完全可以满足通常的网络服务需求。于是我们对需要应用层网关处理的数据包做了如下的设计:
在微引擎上实现包头地址转换以及不同协议间的格式转换。地址映射表的初始化和查找由微引擎处理。通常NAT表的设计至少是几千个条目,在微引擎上可以用硬件HASH实现查表,查表速度可以有保障。域名服务包和文件传输协议命令包由转换微引擎进行了初步转换后送到StrongARM上处理。
控制层面收到数据包后对包的载荷内容进行翻译,并重新计算伪头校验和。对于域名服务请求包通常只需要将query类型进行翻译。而域名服务应答包则在资源记录中包含了一个或者多个IP地址,控制层面的应用层网关转换程序需要对这些IP地址进行翻译。当域名服务应答包是从IPv4网络到IPv6网络,资源记录中通常记录的是位于IPv4网络中的具有域名记录的节点IP地址。对于这种记录的包一种简便的方法就是直接对IPv4地址前面加上系统初始化的时候就分配给IPv4网络的前缀。当域名服务应答包是从IPv6网络到IPv4网络的,对资源记录中IP地址翻译的时候需要查找由控制层面维护的静态NAT映射表。如果静态NAT映射表中没有该IPv6地址对应的条目,默认的做法是将IPv6地址的前96位前最缀去掉。域名服务数据包处理流程参见图1。图1中显示的是从IPv6到IPv4的UDP数据包处理的流程。从IPv4到IPv6的UDP数据包处理的流程见图2。两者不同之处在于从IPv6到IPv4和从IPv4到IPv6所查找的是不同的NAT表。
应用层转换网关程序在处理送到控制层面的文件传输协议命令包时,有时也需要将其载荷中的IP地址进行翻译,方法同域名服务包的处理。这些含有IP地址的命令包括:PASV和EPASV,PORT和EPORT命令。由于文件传输协议命令包是采用TCP协议的数据包,数据包载荷内容进行转换后将会导致载荷长度发生变化。数据包经过NAT-PT转换后,两端的包序号和确认号也需要进行转换,所以在处理TCP的应用层网关转换模块中还应有适当的机制来记录包序号和确认号的这种变化。在实现中,我们需要一些经过地址转换前的数据信息。根据设计,在微引擎把这些包送到StrongARM上的时候需要在包后面捎带上有用的信息,供应用层网关转换模块处理的时候用。具体的数据包格式参见图5。文件传输协议命令包处理流程参见图3。图3显示的是从IPv6到IPv4包处理的过程,从IPv4到IPv6包处理的流程见图4。两者不同之处在于从IPv6到IPv4和从IPv4到IPv6所查找的是不同的NAT表,而且从IPv6到IPv4的TCP包经微引擎送到StrongArm上将会采用图5中描述的包格式,而从IPv4到IPv6的TCP包不需要采用这种特殊的包格式。
我们在Intel IXP1200网络处理器平台上实现了该方法。网络处理器中微引擎负责接收数据包并对收到的数据包进行预处理。需要进行应用层转换处理的数据包通过微引擎和StrongARM间的数据通道送到StrongARM上进行处理。StrongARM根据端口号判断收到的是哪种应用层数据包而决定调用相应的应用层处理模块。为了实现StrongARM上的应用层网关转换处理,在数据包发送到StrongARM上的时候采用特殊的信息传递技术,为应用层的转换提供必要的信息。我们对该方法在网络处理器平台上的实现进行了测试,结果证明用该方法实现的NAT-PT可以实时处理IPv4网络和IPv6网络的互访。

Claims (10)

1.一种基于网络处理器平台的域名服务转换网关和文件传输协议转换网关方法,通过对需要应用层网关转换处理的数据包进行分布式处理,以保证整个NAT-PT系统的转换性能,其特征在于,具体步骤如下:
步骤1:接收端口接收数据包;
步骤2:在微引擎上对接收的数据包进行地址和协议转换;
步骤3:检查协议端口号,发现是域名服务包或者是文件传输协议命令包,采用捎带技术,构造数据包,并将构造后的数据包送StrongARM处理;
步骤4:StrongARM对域名服务包调用域名服务转换网关模块处理,对文件传输协议命令包调用文件传输协议转换网关模块处理;
步骤5:经应用层网关转换模块处理后的数据包送到发送队列等待发送。
2.根据权利要求1所述的基于网络处理器平台的域名服务转换网关和文件传输协议转换网关方法,其特征在于,其中步骤2对接收到的数据包,首先进行IP地址转换,包括包头协议格式的转换,然后执行步骤3。
3.根据权利要求1所述的基于网络处理器平台的域名服务转换网关和文件传输协议转换网关方法,其特征在于,其中步骤3采用捎带技术,捎带StrongARM上进行应用层网关转换处理时需要的源地址、源端口、目的地址。
4.根据权利要求1所述的基于网络处理器平台的域名服务转换网关和文件传输协议转换网关方法,其特征在于,其中步骤3将根据传输层的端口号判断包是否是域名服务包和文件传输协议命令包,如果是这两种包,则通过微引擎和StrongARM间的数据通道送到StrongARM核上处理。
5.根据权利要求1所述的基于网络处理器平台的域名服务转换网关和文件传输协议转换网关方法,其特征在于,其中步骤4将根据收到的包的类型是域名服务包还是文件传输协议命令包,判断是否调用域名服务转换网关处理模块,还是文件传输协议转换网关处理模块。
6.根据权利要求1所述的基于网络处理器平台的域名服务转换网关和文件传输协议转换网关方法,其特征在于,包括:
从IPv6到IPv4的UDP包转换;
从IPv4到IPv6的UDP包转换;
从IPv6到IPv4的TCP包转换;
从IPv4到IPv6的TCP包转换。
7.根据权利要求6所述的基于网络处理器平台的域名服务转换网关和文件传输协议转换网关方法,其特征在于,从IPv6到IPv4的UDP包转换,包括:
步骤s1微引擎上的微码处理程序从IPv6网络端口收到一个UDP数据包后,步骤s2根据IPv6地址查NAT表,取对应的IPv4地址进行相应的地址转换,将包头按照IPv4协议格式进行地址和协议转换,然后步骤s3微码处理程序根据传输层的服务端口号判断该数据包是否属于需要应用层进行转换的数据,如果不是,步骤s4微码处理程序会继续该数据包的处理,计算UDP的校验,然后将其通过IPv4端口发送出去;否则步骤s5该数据包将通过微引擎和StrongArm之间的通道送到StrongArm上进行处理,通常送到StrongArm上的UDP包都是域名服务数据包,所以应用层在收到这样的数据包后通常都会步骤s6调用域名服务协议转换处理模块进行处理,域名服务协议转换处理完成相应的协议转换处理后会步骤s7重新计算伪头校验和并将数据包从IPv4网络端口发送出去。
8.根据权利要求6所述的基于网络处理器平台的域名服务转换网关和文件传输协议转换网关方法,其特征在于,从IPv4到IPv6的UDP包转换;包括:
步骤s8微引擎上的微码处理程序从IPv4网络端口收到一个UDP数据包后,步骤s9根据IPv4地址查NAT表,取对应的IPv6地址进行相应的地址转换,将包头按照IPv6协议格式进行地址和协议转换,然后步骤s10微码处理程序根据传输层的服务端口号判断该数据包是否属于需要应用层进行转换的数据,如果不是,步骤s11微码处理程序会继续该数据包的处理,计算UDP的校验,然后将其通过IPv6端口发送出去,否则步骤s12该数据包将通过微引擎和StrongArm之间的通道送到StrongArm上进行处理,通常送到StrongArm上的UDP包都是域名服务数据包,所以应用层在收到这样的数据包后通常都会调用步骤s13域名服务协议转换处理模块进行处理域名服务协议转换处理完成相应的协议转换处理后会步骤s14重新计算伪头校验和并将数据包从IPv6网络端口发送出去。
9.根据权利要求6所述的基于网络处理器平台的域名服务转换网关和文件传输协议转换网关方法,其特征在于,从IPv6到IPv4的TCP包转换;包括:
步骤s15微引擎上的微码处理程序从IPv6网络端口收到一个TCP数据包后,步骤s16根据IPv6地址查NAT表,取对应的IPv4地址进行相应的地址转换,将包头按照IPv4协议格式进行地址和协议转换,然后步骤s17微码处理程序根据传输层的服务端口号判断该数据包是否属于需要应用层进行转换的数据,如果不是,步骤s18微码处理程序会继续该数据包的处理,计算伪头校验计算伪头校验,然后将其通过IPv4端口发送出去;否则步骤s19微引擎将会按照图5中描述的包格式,构造含有IPv4源地址、目的地址、源端口的数据包,该特殊数据包将通过微引擎和StrongArm之间的通道送到StrongArm上进行处理,应用层在收到这样的数据包后通常都会步骤s20调用文件传输协议转换处理模块进行处理,文件传输协议转换处理完成相应的协议转换处理后会步骤s21重新计算伪头校验和并将数据包从IPv4网络端口发送出去。
10.根据权利要求6所述的基于网络处理器平台的域名服务转换网关和文件传输协议转换网关方法,其特征在于,从IPv4到IPv6的TCP包转换,包括:
步骤s22微引擎上的微码处理程序从IPv4网络端口收到一个TCP数据包后,步骤s23根据IPv4地址查NAT表,取对应的IPv6地址进行相应的地址转换,将包头按照IPv6协议格式进行地址和协议转换,然后步骤s24微码处理程序根据传输层的服务端口号判断该数据包是否属于需要应用层进行转换的数据,如果不是,步骤s25微码处理程序会继续该数据包的处理,计算伪头校验,然后将其通过IPv6端口发送出去;否则步骤s26该数据包将通过微引擎和StrongArm之间的通道送到StrongArm上进行处理,通常送到StrongArm上的TCP包都是文件传输协议命令包,所以应用层在收到这样的数据包后通常都会步骤s27调用文件传输协议转换处理模块进行处理,文件传输协议转换处理完成相应的协议转换处理后会步骤s28重新计算伪头校验和并将数据包从IPv6网络端口发送出去。
CNB2003101010680A 2003-10-14 2003-10-14 网络处理器内部实现分布式应用层转换网关的方法 Expired - Fee Related CN1275443C (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CNB2003101010680A CN1275443C (zh) 2003-10-14 2003-10-14 网络处理器内部实现分布式应用层转换网关的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CNB2003101010680A CN1275443C (zh) 2003-10-14 2003-10-14 网络处理器内部实现分布式应用层转换网关的方法

Publications (2)

Publication Number Publication Date
CN1529481A true CN1529481A (zh) 2004-09-15
CN1275443C CN1275443C (zh) 2006-09-13

Family

ID=34304165

Family Applications (1)

Application Number Title Priority Date Filing Date
CNB2003101010680A Expired - Fee Related CN1275443C (zh) 2003-10-14 2003-10-14 网络处理器内部实现分布式应用层转换网关的方法

Country Status (1)

Country Link
CN (1) CN1275443C (zh)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100380897C (zh) * 2004-11-16 2008-04-09 北京北方烽火科技有限公司 微引擎与StrongArm核的通信方法
CN101136852B (zh) * 2007-06-01 2010-05-19 武汉虹旭信息技术有限责任公司 微引擎的深度包处理方法
CN101136910B (zh) * 2006-08-30 2010-09-29 中国电信股份有限公司 网络地址和协议翻译设备与应用层网关设备
CN101938384A (zh) * 2010-08-31 2011-01-05 中山大学 一种数字家庭交互服务中的公共网关测试方法
CN101087296B (zh) * 2006-06-08 2011-06-15 上海亿人通信终端有限公司 利用网络处理器实现IPv4/IPv6网络协议转换的方法
CN101325580B (zh) * 2007-06-15 2012-01-25 上海亿人通信终端有限公司 基于nat-pt的ftp应用层网关的实现方法
CN109842609A (zh) * 2017-11-27 2019-06-04 三星电子株式会社 用于网络地址转换的通信系统和方法
US11195213B2 (en) * 2010-09-01 2021-12-07 Apixio, Inc. Method of optimizing patient-related outcomes
CN115242890A (zh) * 2022-06-14 2022-10-25 深圳市老狗科技有限公司 一种基于微码的通用工业协议转换方法
US11694239B2 (en) 2010-09-01 2023-07-04 Apixio, Inc. Method of optimizing patient-related outcomes
CN116614315A (zh) * 2023-07-19 2023-08-18 国家计算机网络与信息安全管理中心江西分中心 一种实现应用云安全托管的IPv6安全防护方法

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102925241B (zh) * 2012-11-27 2014-05-21 中国环境科学研究院 制备生活垃圾衍生燃料的方法和装置
CN106059817A (zh) * 2016-06-18 2016-10-26 青岛中云数据信息科技有限公司 一种通用型无线数据管理系统

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100380897C (zh) * 2004-11-16 2008-04-09 北京北方烽火科技有限公司 微引擎与StrongArm核的通信方法
CN101087296B (zh) * 2006-06-08 2011-06-15 上海亿人通信终端有限公司 利用网络处理器实现IPv4/IPv6网络协议转换的方法
CN101136910B (zh) * 2006-08-30 2010-09-29 中国电信股份有限公司 网络地址和协议翻译设备与应用层网关设备
CN101136852B (zh) * 2007-06-01 2010-05-19 武汉虹旭信息技术有限责任公司 微引擎的深度包处理方法
CN101325580B (zh) * 2007-06-15 2012-01-25 上海亿人通信终端有限公司 基于nat-pt的ftp应用层网关的实现方法
CN101938384A (zh) * 2010-08-31 2011-01-05 中山大学 一种数字家庭交互服务中的公共网关测试方法
US11195213B2 (en) * 2010-09-01 2021-12-07 Apixio, Inc. Method of optimizing patient-related outcomes
US11694239B2 (en) 2010-09-01 2023-07-04 Apixio, Inc. Method of optimizing patient-related outcomes
US12008613B2 (en) 2010-09-01 2024-06-11 Apixio, Inc. Method of optimizing patient-related outcomes
KR20190062166A (ko) * 2017-11-27 2019-06-05 삼성전자주식회사 네트워크 어드레스 변환을 위한 통신 시스템 및 방법
CN109842609A (zh) * 2017-11-27 2019-06-04 三星电子株式会社 用于网络地址转换的通信系统和方法
CN109842609B (zh) * 2017-11-27 2023-04-07 三星电子株式会社 用于网络地址转换的通信系统和方法
KR102610823B1 (ko) * 2017-11-27 2023-12-07 삼성전자주식회사 네트워크 어드레스 변환을 위한 통신 시스템 및 방법
CN115242890A (zh) * 2022-06-14 2022-10-25 深圳市老狗科技有限公司 一种基于微码的通用工业协议转换方法
CN116614315A (zh) * 2023-07-19 2023-08-18 国家计算机网络与信息安全管理中心江西分中心 一种实现应用云安全托管的IPv6安全防护方法
CN116614315B (zh) * 2023-07-19 2023-10-27 国家计算机网络与信息安全管理中心江西分中心 一种实现应用云安全托管的IPv6安全防护方法

Also Published As

Publication number Publication date
CN1275443C (zh) 2006-09-13

Similar Documents

Publication Publication Date Title
US6704786B1 (en) Network and end-host efficiency for web communication
Spatscheck et al. Optimizing TCP forwarder performance
CN1232080C (zh) 网络中节省ip地址提供内部服务器的方法
CN1275443C (zh) 网络处理器内部实现分布式应用层转换网关的方法
US7653075B2 (en) Processing communication flows in asymmetrically routed networks
US7826487B1 (en) Coalescing acknowledgement responses to improve network communications
US7298745B2 (en) Method and apparatus to manage packet fragmentation with address translation
US8447802B2 (en) Address manipulation to provide for the use of network tools even when transaction acceleration is in use over a network
CN1507734A (zh) 通用外部代理
US8601139B2 (en) Multiple core session initiation protocol (SIP)
CN1708959A (zh) 软件和硬件包流转发的方法、路由器或交换机
BRPI0616627A2 (pt) equipamento, sistema e método para comunicação entre cliente e lado do servidor
KR19980070104A (ko) 전송 제어 프로토콜 글루를 통한 세션 및 전송 계층 프록시 개선 방법
JP2008536369A (ja) 接続転送
US7290050B1 (en) Transparent load balancer for network connections
CN1493140A (zh) 允许数据传输穿越防火墙的方法和设备
Natarajan et al. SCTP: An innovative transport layer protocol for the web
US8892745B2 (en) Redirection of a request for information
US7564848B2 (en) Method for the establishing of connections in a communication system
CN103368872A (zh) 数据包转发系统和方法
CN1512377A (zh) 基于内核中套接字对接的第七层负载均衡的方法
WO2009053878A1 (en) Methods and systems for offload processing
US20030167338A1 (en) System and method to provide PPPoE connectivity to non-PPPoE clients
US8509235B2 (en) Layer-2 packet return in proxy-router communication protocol environments
WO2003105006A1 (en) Load balancing with direct terminal response

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
EE01 Entry into force of recordation of patent licensing contract

Assignee: Beijing Zhongke Jingshang Technology Co., Ltd.

Assignor: Institute of Computing Technology, Chinese Academy of Sciences

Contract record no.: 2011110000143

Denomination of invention: Method for realizing distributed application tier conversion gate-link in network processor

Granted publication date: 20060913

License type: Exclusive License

Open date: 20040915

Record date: 20110823

EC01 Cancellation of recordation of patent licensing contract
EC01 Cancellation of recordation of patent licensing contract

Assignee: Beijing Zhongke Polytron Technologies Inc

Assignor: Institute of Computing Technology, Chinese Academy of Sciences

Contract record no.: 2011110000143

Date of cancellation: 20181212

EM01 Change of recordation of patent licensing contract
EM01 Change of recordation of patent licensing contract

Change date: 20181212

Contract record no.: 2011110000143

Assignee after: Beijing Zhongke Polytron Technologies Inc

Assignee before: Beijing Zhongke Jingshang Technology Co., Ltd.

CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20060913

Termination date: 20191014