JP2008259238A - Gigabit ethernet adapter - Google Patents
Gigabit ethernet adapter Download PDFInfo
- Publication number
- JP2008259238A JP2008259238A JP2008139758A JP2008139758A JP2008259238A JP 2008259238 A JP2008259238 A JP 2008259238A JP 2008139758 A JP2008139758 A JP 2008139758A JP 2008139758 A JP2008139758 A JP 2008139758A JP 2008259238 A JP2008259238 A JP 2008259238A
- Authority
- JP
- Japan
- Prior art keywords
- module
- arp
- packet
- tcp
- network
- 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
Links
Images
Landscapes
- Communication Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
本発明は、電気通信に関するものである。より特定的には、本発明は、データを送受信するために用いられる通信プロトコルに関連するデータを処理するための方法および装置に関するものである。 The present invention relates to telecommunications. More particularly, the present invention relates to a method and apparatus for processing data associated with a communication protocol used to send and receive data.
コンピュータ・ネットワークは、データを送受信するために、種々の通信プロトコルの設置を必要とする。通常、コンピュータ・ネットワークは、互いに通信し合うように接続されたコンピュータ、プリンタ、および、他のコンピュータ周辺装置のようなデバイスのシステムを有している。データは、通信プロトコル標準を用いてネットワーク中を伝わるデータ・パケットを通して、それらのデバイスの各々の間を転送される。多くの相異なるプロトコル標準が、今日、用いられている。一般的なプロトコルの例としては、インターネット・プロトコル(IP)、インターネット・ワーク・パケット交換(IPX)、シーケンス・パケット交換(SPX)、トランスミッション・コントロール・プロトコル(TCP)、ポイント・ツー・ポイント・プロトコル(PPP)がある。各ネットワーク・デバイスには、プロトコルとプロセスデータとを中継するハードウェアとソフトウェアとのコンビネーションが含まれている。 Computer networks require the installation of various communication protocols in order to send and receive data. A computer network typically includes a system of devices such as computers, printers, and other computer peripherals connected in communication with each other. Data is transferred between each of these devices through data packets that travel through the network using communication protocol standards. Many different protocol standards are in use today. Examples of common protocols are Internet Protocol (IP), Internet Work Packet Exchange (IPX), Sequence Packet Exchange (SPX), Transmission Control Protocol (TCP), Point-to-Point Protocol (PPP). Each network device includes a combination of hardware and software that relays protocol and process data.
一例は、ローカル・エリア・ネットワーク(LAN)システムに配されたコンピュータであり、そこでは、ネットワーク・デバイスが、ハードウェアを用いて、リンク層プロトコルをハンドルし、ソフトウェアを用いて、ネットワーク・プロトコル、トランスポート・プロトコル、通信プロトコル、および、通信データ・ハンドリングをハンドルしている。ネットワーク・デバイスは、通常、ハードウェア内にただ1つのリンク層プロトコルをインプリメントしており、配されているコンピュータを、その特定のLANプロトコルのみに制限している。データ・ハンドラとともに、より高位のプロトコル、例えば、ネットワーク・プロトコル、トランスポート・プロトコル、通信プロトコルは、データがネットワーク・デバイス・ハードウェアを通ってシステム・メモリに渡されるとすぐに、それらのデータを処理するソフトウェアプログラムとしてインプリメントされている。このインプリメンテーションの利点は、それが、コンピュータのような多目的デバイスを、多くの相異なるネットワークセットアップに用い、また、必要とされるどんな任意のネットワークアプリケーションをもサポートさせることを可能にするということである。しかしながら、このインプリメンテーションの結果として、そのシステムは、高いプロセッサ・オーバーヘッド、大量のシステム・メモリ、相異なるソフトウェア・プロトコルを協働させるためのコンピュータユーザ側の複雑な構成セットアップ、および、コンピュータのオペレーティング・システム(O.S.)とコンピュータとネットワーク・ハードウェアとを通信させ合うデータ・ハンドラを必要とする。 An example is a computer located in a local area network (LAN) system, where a network device handles the link layer protocol using hardware and uses the network protocol, Handles transport protocols, communication protocols, and communication data handling. Network devices typically implement only one link layer protocol in hardware, limiting the computers that are deployed to that particular LAN protocol. Along with data handlers, higher-level protocols, such as network protocols, transport protocols, and communication protocols, can transfer their data as soon as it passes through the network device hardware to system memory. It is implemented as a software program to process. The advantage of this implementation is that it allows a multipurpose device such as a computer to be used in many different network setups and to support any arbitrary network application that is required. It is. However, as a result of this implementation, the system has a high processor overhead, a large amount of system memory, a complex configuration setup on the computer user side to work with different software protocols, and a computer operating system. • Requires a data handler that allows the system (OS), computer, and network hardware to communicate.
処理時間に必要とされるこの高いオーバーヘッドは、1つのデバイス上で同一のプロトコルをインプリメントしている複数のソフトウェア・プロトコル・スタックを動作させる方法を教示している、1996年1月16日にSchrier等に公告された米国特許番号5,485,460に明示されている。このタイプのインプリメンテーションは、マイクロソフト・ウィンドウズを走らせている、ディスク・オペレーティング・システム(DOS)ベースのマシンで用いられている。通常動作中、ハードウェアが、トランスポート・プロトコルまたはリンク層プロトコルを確認すると、結果として生じるデータ・パケットが、パケットフレームフォーマットを決定して、任意の特定のフレーム・ヘッダを取り除くソフトウェアレイヤに送られる。そのパケットは、次に、さまざまなプロトコル・スタックに送られ、そこで、特定のプロトコルに対して評価される。しかしながら、そのパケットは、いくつかのプロトコルのスタックに送られた後で、受け入れられる、または、拒絶されるかもしれない。ソフトウェア・プロトコル・スタックによって作り出される時間遅れは、オーディオおよびビデオ伝送をリアルタイムに処理することを妨げる。即ち、それらのデータを、再生の前にバッファしなければならない。1つのプロトコルを処理するために必要な処理オーバーヘッドの総計は、非常に高く、極端にかさばって扱いにくく、強力な中央処理装置(CPU)と大量のメモリとを用いるアプリケーションに向くことが、明白である。 This high overhead required for processing time teaches how to run multiple software protocol stacks implementing the same protocol on a single device on 16 January 1996, Schrier. In U.S. Pat. No. 5,485,460 published in the United States. This type of implementation is used on disk operating system (DOS) based machines running Microsoft Windows. During normal operation, when the hardware verifies the transport protocol or link layer protocol, the resulting data packet is sent to a software layer that determines the packet frame format and removes any specific frame header . The packet is then sent to various protocol stacks where it is evaluated for a particular protocol. However, the packet may be accepted or rejected after being sent to some protocol stack. The time delay created by the software protocol stack prevents real time processing of audio and video transmissions. That is, the data must be buffered before playback. Clearly, the total processing overhead required to process a single protocol is very high, extremely bulky and cumbersome, and is suitable for applications that use powerful central processing units (CPUs) and large amounts of memory. is there.
ネットワーク・デバイスの従来のモデルにはまらないコンシューマ製品が、市場に参入してきている。それらの製品の新しい例は、ページャ（ポケベル）、携帯電話、ゲームマシン、スマート電話、テレビジョンである。それらの製品の大多数は、小さなフットプリント、8ビットコントローラ、限られたメモリを持っており、あるいは、非常に限定されたフォーム・ファクタを必要とする。それらのようなコンシューマ製品は、単純であり、低価格および低電力消費を必要とする。上述のプロトコル・インプリメンテーションは、それらの必要条件をかなえるには、あまりにも大きなハードウェアおよびプロセッサ能力を必要とする。そのようなインプリメンテーションの複雑さは、費用効率を高く、コンシューマ製品に組み込むことを困難にする。ネットワーク・アクセスが、低価格、低電力、小フォーム・ファクタのデバイス上に容易につくりあげられるほどに単純化できるようになれば、それらの製品は、インターネットのようなネットワーク・サービスにアクセスできるようになる。 Consumer products that do not fit in traditional models of network devices have entered the market. New examples of these products are pagers, mobile phones, game machines, smart phones and televisions. The majority of these products have a small footprint, 8-bit controller, limited memory, or require a very limited form factor. Consumer products such as them are simple and require low cost and low power consumption. The protocol implementations described above require too much hardware and processor power to meet these requirements. Such implementation complexity is cost effective and difficult to incorporate into consumer products. If network access can be simplified so that it can be easily built on low-cost, low-power, small form-factor devices, they can access network services such as the Internet. Become.
通信ネットワークは、データを送受信するためにプロトコルを用いる。通常、通信ネットワークは、互いに通信し合うように接続されたコンピュータ、プリンタ、記憶デバイス、および、他のコンピュータ周辺装置のような、ノードとも呼ばれるネットワーク・デバイスの集合を有している。データは、プロトコルを用いて通信ネットワーク中を伝わるデータ・パケットを用いて、それらのネットワーク・デバイスの各々の間を転送する。多くの相異なるプロトコルが、今日、用いられている。一般的なプロトコルの例としては、インターネット・プロトコル(IP)、インターネット・ワーク・パケット交換(IPX) プロトコル、シーケンス・パケット交換(SPX) プロトコル、トランスミッション・コントロール・プロトコル(TCP)、ポイント・ツー・ポイント・プロトコル(PPP)、および、開発中の他の同様の新しいプロトコルがある。ネットワーク・デバイスには、プロトコルとデータ・パケットとを処理するハードウェアとソフトウェアとのコンビネーションが含まれている。 Communication networks use protocols to send and receive data. A communication network typically includes a collection of network devices, also referred to as nodes, such as computers, printers, storage devices, and other computer peripherals connected to communicate with each other. Data is transferred between each of these network devices using data packets that travel through the communication network using a protocol. Many different protocols are in use today. Examples of common protocols are Internet Protocol (IP), Internet Work Packet Exchange (IPX) Protocol, Sequence Packet Exchange (SPX) Protocol, Transmission Control Protocol (TCP), Point to Point There are protocols (PPP) and other similar new protocols under development. A network device includes a combination of hardware and software that processes protocols and data packets.
1978年に、標準設定母体である国際標準化機構(ISO)が、オープン・システム・インターコネクション(OSI)モデルとして知られるネットワーク参照モデルを作り出した。OSIモデルは、7つの概念層：1）ネットワーク・デバイスをネットワークに接続する物理的な構成要素を決定する物理(PHY)層、2）データ・パケットを含むフレームとして知られている離散形状にデータの動きを制御するデータリンク層、3）特定のプロトコルにしたがってデータ・パケットを組み立てるネットワーク層、4）データ・パケットの信頼性の高い送付を確実にするトランスポート層、5）ネットワーク・デバイス間の双方向通信を可能にするセッション層、6）データを表現する態様を制御し、そのデータが正しい形式にあることを確実にするプレゼンテーション層、7）ファイル共有、メッセージ・ハンドリング、プリンティング等を供給するアプリケーション層、を含有している。セッション層およびプレゼンテーション層は、このモデルから除外されることもある。最新の通信ネットワークおよびインターネットがどのようにISOの7層モデルに関係しているかに関する説明については、例えば、Douglas E. Comerによるテキスト“Internetworking with TCP/IP”（第1巻、第4版、国際標準図書コード0201633469）の第11章、および、W. Richard Stevensによるテキスト“TCP/IP Illustrated” （第1巻、国際標準図書コード0130183806）の第1章を参照されたい。
In 1978, the International Organization for Standardization (ISO), the standard-setting body, created a network reference model known as the Open System Interconnection (OSI) model. The OSI model consists of seven conceptual layers: 1) a physical (PHY) layer that determines the physical components that connect network devices to the network, and 2) data in discrete shapes known as frames containing data packets. A data link layer that controls the movement of data, 3) a network layer that assembles data packets according to a specific protocol, 4) a transport layer that ensures reliable delivery of data packets, and 5) between network devices Session layer that allows two-way communication, 6) Controls the way data is represented and provides a presentation layer that ensures that the data is in the correct format, 7) Provides file sharing, message handling, printing, etc. Application layer. The session layer and presentation layer may be excluded from this model. For an explanation of how the latest communication networks and the Internet are related to the ISO 7-layer model, see, for example, the text “Internetworking with TCP / IP” by Douglas E. Comer (
ネットワーク・デバイスの一例は、ローカル・エリア・ネットワーク(LAN)に配されたコンピュータであり、そこでは、ネットワーク・デバイスが、ホスト・コンピュータ内のハードウェアを用いて物理層およびデータリンク層をハンドルし、ホスト・コンピュータ上を走るソフトウェアを用いてネットワーク層、トランスポート層、セッション層、プレゼンテーション層、アプリケーション層をハンドルする。ネットワーク層、トランスポート層、セッション層、プレゼンテーション層は、プロトコル・スタックとも呼ばれるプロトコル処理ソフトウェアを用いてインプリメントされる。アプリケーション層は、データがネットワーク・デバイス・ハードウェアおよびプロトコル処理ソフトウェアを通ったときに、そのデータを処理するアプリケーション・ソフトウェアを用いてインプリメントされる。このソフトウェアベースのプロトコル処理インプリメンテーションの利点は、それが、多目的コンピュータを、多くの相異なるタイプの通信ネットワークに用い、また、必要とされるどんなアプリケーションをもサポートさせることを可能にするということである。しかしながら、このソフトウェアベースのプロトコル処理インプリメンテーションの結果として、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層を処理するために、ホスト・コンピュータの中央処理装置(CPU)上を走るプロトコル処理ソフトウェアのオーバーヘッドが、非常に高いものになる。ソフトウェアベースのプロトコル処理インプリメンテーションは、また、データが、ソフトウェアによって処理されるときにコピーされ、そして、移動されなければならないから、ホスト・コンピュータ上に大量のメモリをも必要とする。プロトコル処理ソフトウェアによって必要とされる高いオーバーヘッドは、複数のソフトウェア・プロトコル・スタックの動作方法を教示している、1996年1月16日にSchrier等に公告された米国特許番号5,485,460に明示されている。このタイプのソフトウェアベースのプロトコル処理インプリメンテーションは、例えば、マイクロソフト・ウィンドウズを走らせているコンピュータで用いられている。 An example of a network device is a computer located in a local area network (LAN), where the network device handles the physical and data link layers using the hardware in the host computer. The network layer, transport layer, session layer, presentation layer, and application layer are handled using software running on the host computer. The network layer, transport layer, session layer, and presentation layer are implemented using protocol processing software, also called a protocol stack. The application layer is implemented with application software that processes the data as it passes through the network device hardware and protocol processing software. The advantage of this software-based protocol processing implementation is that it allows a multipurpose computer to be used in many different types of communication networks and to support any required application. It is. However, as a result of this software-based protocol processing implementation, protocol processing software running on the central processing unit (CPU) of the host computer to process the network layer, transport layer, session layer, and presentation layer. The overhead is very high. Software-based protocol processing implementations also require a large amount of memory on the host computer because data must be copied and moved as it is processed by software. The high overhead required by the protocol processing software is specified in US Pat. No. 5,485,460 issued to Schrier et al. On Jan. 16, 1996 teaching how to operate multiple software protocol stacks. . This type of software-based protocol processing implementation is used, for example, on computers running Microsoft Windows.
ネットワーク・デバイスの通常動作中、ネットワーク・デバイス・ハードウェアは、その後にホスト・コンピュータ内のプロトコル処理ソフトウェアに送られることになるデータ・パケットを抽出する。プロトコル処理ソフトウェアは、ホスト・コンピュータ上で走り、このホスト・コンピュータは、そのタスクがプロトコル処理ソフトウェアによって遂行されるように最適化されてはいない。プロトコル処理ソフトウェアと多目的ホスト・コンピュータとのコンビネーションは、プロトコル処理に対して最適化されておらず、それは、遂行能力限界に導く。プロトコル処理ソフトウェアの実行によって作り出される時間遅れのような、プロトコル処理中の遂行能力限界は有害で、例えば、オーディオおよびビデオ伝送のリアルタイム処理を妨げるであろうし、また、通信ネットワークの最大速度、最大容量での使用を妨げるであろう。1つのプロトコルを処理するために必要なホスト・コンピュータCPUオーバーヘッドの総計は、非常に高く、極端にかさばって扱いにくく、そして、ホスト・コンピュータ内にCPUと大量のメモリとの使用を必要とすることが明白である。 During normal operation of the network device, the network device hardware extracts data packets that will then be sent to protocol processing software in the host computer. The protocol processing software runs on a host computer, which is not optimized for its tasks to be performed by the protocol processing software. The combination of protocol processing software and multipurpose host computer is not optimized for protocol processing, which leads to performance limits. Performance limits during protocol processing, such as time delays created by the execution of protocol processing software, are detrimental and will interfere with real-time processing of audio and video transmissions, for example, and the maximum speed, capacity of the communication network Will prevent its use in. The total host computer CPU overhead required to handle a single protocol is very high, extremely bulky and cumbersome, and requires the use of a CPU and a large amount of memory in the host computer Is obvious.
ネットワーク・デバイスの従来のモデルにはまらない新しいコンシューマ製品および工業製品が、市場に参入してきており、同時に、ネットワーク速度が、上昇し続けている。それらのコンシューマ製品の例には、インターネット接続可能なセルフォン、インターネット接続可能なTV、インターネットアプライアンスが含まれる。工業製品の例には、ネットワーク・インターフェイス・カード(NIC)、インターネット・ルータ、インターネット・スイッチ、インターネット・ストレージ・サーバが含まれる。ソフトウェアベースのプロトコル処理インプリメンテーションは、それらの新しいコンシューマ製品および工業製品の必要条件をかなえるには、あまりにも非能率的である。ソフトウェアベースのプロトコル処理インプリメンテーションは、その複雑さのために、費用効率を高くコンシューマ製品に組み込むことが困難である。ソフトウェアベースのプロトコル処理インプリメンテーションは、必要とされる処理電力のために、高速の工業製品にインプリメントすることが困難である。プロトコル処理が、低価格、低電力、高性能、集積化、小フォーム・ファクタのデバイス上に容易につくりだされるように単純化でき、最適化できれば、それらのコンシューマ製品および工業製品は、インターネットのような任意の通信ネットワーク上のデータを読み込んだり、書き込んだりできるようになる。 New consumer and industrial products that do not fit in the traditional models of network devices are entering the market, and at the same time, network speeds continue to rise. Examples of such consumer products include cell phones that can connect to the Internet, TVs that can connect to the Internet, and Internet appliances. Examples of industrial products include network interface cards (NICs), internet routers, internet switches, internet storage servers. Software-based protocol processing implementations are too inefficient to meet the requirements of these new consumer and industrial products. Software-based protocol processing implementations are difficult to incorporate cost-effectively into consumer products because of their complexity. Software-based protocol processing implementations are difficult to implement in high-speed industrial products because of the processing power required. If protocol processing can be simplified and optimized to be easily created on low cost, low power, high performance, integrated, small form factor devices, consumer and industrial products can Can read and write data on any communication network.
ソフトウェアベースのプロトコル処理インプリメンテーションとは対照的に、ハードウェアベースのプロトコル処理インプリメンテーション、即ち、インターネット・チューナが、J. Minami, R. Koyama, M. Johnson, M. Shinohara, T. Poff, D.Burkes,“Multiple network protocol encoder/decoder and data processor”, 米国特許番号6,034,963（2000年3月7日）（ ‘963特許）に記述されている。このインターネット・チューナは、プロトコルを処理するためのコア技術を提供する。 In contrast to software-based protocol processing implementations, hardware-based protocol processing implementations, ie Internet tuners, are available in J. Minami, R. Koyama, M. Johnson, M. Shinohara, T. Poff. , D. Burkes, “Multiple network protocol encoder / decoder and data processor”, US Pat. No. 6,034,963 (March 7, 2000) (the '963 patent). This Internet tuner provides the core technology for processing the protocol.
高いネットワーク通信速度に対するハードウェア解を備えたギガビット・イーサネット・アダプタを提供することは、有益なことである。さらに、複数の通信プロトコルを適合させるギガビット・イーサネット・アダプタを提供することも、有益なことである。 It would be beneficial to provide a Gigabit Ethernet adapter with a hardware solution for high network communication speeds. It would also be beneficial to provide a Gigabit Ethernet adapter that adapts multiple communication protocols.
本発明は、ギガビット・イーサネット・アダプタを提供する。そのシステムは、高ネットワーク通信速度を扱うためのコンパクトなハードウェア解を提供する。さらに、本発明は、モジュールの構築および設計を介して、複数の通信プロトコルに適合する。 The present invention provides a Gigabit Ethernet adapter. The system provides a compact hardware solution to handle high network communication speeds. Furthermore, the present invention adapts to multiple communication protocols through the construction and design of modules.
本発明の好適な一実施例は、低メモリ要請しか持たず、かつ、高度に効率的なプロトコルデコードを供給する、低価格で、低電力で、容易に製造可能で、小フォーム・ファクタのネットワーク・アクセス・モジュールを提供する。本発明は、複数のネットワーク・プロトコルを同時にバイト・ストリーム態様でデコードもし、また、パケット・データを1つのパスで処理もし、それによって、システム・メモリおよびフォーム・ファクタの要求条件を減少させ、また、ソフトウェアCPUオーバーヘッドを排除する、ハードウェア統合システムを有する。 One preferred embodiment of the present invention is a low cost, low power, easily manufacturable, small form factor network that has low memory requirements and provides highly efficient protocol decoding. Provide an access module. The present invention also decodes multiple network protocols simultaneously in a byte stream fashion, and also processes packet data in a single pass, thereby reducing system memory and form factor requirements, and Having a hardware integration system that eliminates software CPU overhead.
本発明の好適な一実施例は、TCP, IP, ユーザ・データグラム・プロトコル(UDP), PPP, ローソケット, RARP, ICMP, IGMP, Iscsi, RDMA, FCIPのようなネットワーク・プロトコルを、各バイトが受信されたときに同時にデコードする、複数のプロトコル・ステートマシンを有している。各プロトコル・ハンドラは、中間メモリを要求せずに、パケットからヘッダー情報を直接に構文解析し、インタプリトし、剥ぎ取る。 One preferred embodiment of the present invention is to use network protocols such as TCP, IP, User Datagram Protocol (UDP), PPP, raw socket, RARP, ICMP, IGMP, Iscsi, RDMA, FCIP for each byte. It has multiple protocol state machines that decode simultaneously when they are received. Each protocol handler parses, interprets, and strips header information directly from the packet without requiring intermediate memory.
本発明は、インターネット・チューナ・コア、周辺装置、および、外部インターフェイスを提供する。ネットワーク・スタックは、ネットワーク・パケットを処理し、生成し、受信する。プログラム可能な内部プロセッサは、ネットワーク・スタックを制御し、任意の他のタイプのICMPパケット、IGMPパケット、あるいは、専用ハードウェアによって直接サポートされていない他のプロトコルに対応するパケットをハンドルする。 The present invention provides an Internet tuner core, peripheral devices, and an external interface. The network stack processes, generates, and receives network packets. A programmable internal processor controls the network stack and handles any other types of ICMP packets, IGMP packets, or packets corresponding to other protocols not directly supported by dedicated hardware.
バーチャル・メモリ・マネージャが、最適化されたハード・ワイヤード・ロジックにインプリメントされる。そのバーチャル・メモリ・マネージャは、バーチャル・ナンバのネットワーク・コネクションの使用を可能にする。ネットワーク・コネクションのバーチャル・ナンバは、利用可能な内部メモリ量および外部メモリ量によってしか制限されない
どの出ていくネットワーク・パケットも、データ・ステートマシンによって作り出され、そして、そのパケットにフォーマットを付加して、ヘッダ情報のチェックサムを行い、その結果生じたネットワーク・パケットを物理的な輸送レベルメカニズムを介して配布するネットワーク・プロトコル・ステートマシンを通る。
A virtual memory manager is implemented in optimized hard-wired logic. The virtual memory manager allows the use of virtual number network connections. The virtual number of the network connection is that any outgoing network packet that is limited only by the amount of available internal and external memory is created by the data state machine and adds a format to that packet. Through a network protocol state machine that performs a checksum of the header information and distributes the resulting network packet via a physical transport level mechanism.
ハードウェア・ゲートレベル・インプリメンテーションは、設計者が、特定の応用に必要とされる機能を精選しながら、なおかつ、低価格で低電力で小フォーム・ファクタを維持することができる、モジュール性で嵌め込み可能な設計を提供する。 Hardware gate level implementation is modular, allowing designers to carefully select the features required for a specific application while still maintaining a small form factor at low cost and low power Provide a design that can be fitted with.
本発明の他の観点および利点は、添付の図面と組み合わせて、例として本発明の原理を例証する、以下の詳細な記述から明白になる。 Other aspects and advantages of the present invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.
本発明は、ギガビット・イーサネット・アダプタで具体的に表現される。本発明による1システムは、高ネットワーク通信速度をハンドリングするためのコンパクトなハードウェア解を提供する。さらに、本発明は、モジュール構造および設計を介して複数の通信プロトコルを適合させる。 The present invention is specifically represented by a Gigabit Ethernet adapter. One system according to the present invention provides a compact hardware solution for handling high network communication speeds. Furthermore, the present invention adapts multiple communication protocols through modular structure and design.
図1を参照すると、本発明は、ネットワーク・プロトコル層101、データ・ハンドラ102、メモリ制御モジュール103、オペレーティング・システム(O.S.)ステートマシン・モジュール104を有し、その各々が、ハードウェア・ゲートレベルでインプリメントされている。ネットワーク・プロトコル層101は、入ってくるネットワーク・パケットをデコードし、出て行くネットワーク・パケットをエンコードする。ネットワーク・プロトコル層101は、入ってくるネットワーク・パケットを同時にデコードする種々のネットワーク・プロトコル・スタック（即ち、PPP, TCP, IP, UDP, ローソケット）を表わす複数のステートマシンを有している。ゲートレベルロジックでのプロトコル・スタックのインプリメンテーションは、ネットワーク・パケットを受信しながら、そのパケットをリアルタイムにデコーディングすることを可能にし、それによって、一時メモリ記憶を全く不要にする。パケット・ヘッダ情報の全てが、はがされ、そして、ステートマシンによって確認された後、その結果として得られたデータが、データ・ハンドラ102に渡される。データ・ハンドラ102は、複数のステートマシンを有し、それらの各々は、特定のデータタイプ（即ち、HTTP、eメール・フォーマット（ポスト・オフィス・プロトコル(POP3)、インターネット・メッセージ・アクセス・プロトコル(IMAP4)、シンプル・メール・トランスファ・プロトコル(SMTP)）、グラフィックス標準（ジョイント・フォトグラフィック・エキスパーツ・グループ(JPEG)、グラフィックス・インターチェンジ・フォーマット(GIF)）、Java、HTML）を処理する。データ・ハンドラのゲートレベル・インプリメンテーションは、本発明が受信データをリアルタイムで同時に処理することを可能にし、特に、データ・ストリームを受信しながら、それらのデータ・ストリームをハンドルする応用、即ち、Java, HTML, POP3 eメール、および、オーディオ応用、ビデオ応用に適している。2つ以上のデータ・ステートマシンによって必要とされるどのデータも、同時に供給される。特定のデータ・ステートマシンによって2回以上必要とされるどのデータも、それらのデータを指定するポインタをつけて、特定のメモリ位置に置かれる。全てのメモリアクセスは、メモリ制御モジュール103によって調停される（アービトレーションを行われる）。その結果、どのディスプレイデータも、メモリ制御モジュール103によって発送される。O.S.ステートマシン104は、リソース制御、システム、ユーザインターフェイスのためのステートマシン全体の間のアービトレータ（アービタ）として働く。どのユーザ入力も、O.S.ステートマシンによってインタプリトされ、データ・ハンドラ102に発送される。
Referring to FIG. 1, the present invention includes a
一例として、HTMLフォーマットをインタプリトするデータ・ハンドラは、サイクリック・リダンダンシ・チェック(CRC)計算を用いてHTMLタグをデコードできる。HTMLフォーマットには、タグとして知られているキャラクタ・ストリングが含まれており、それは、後に続くテキストブロックが、ビデオ出力デバイス上に表示されるときに、そのフォーマティングを制御する。それらのタグは、1つの与えられたタグに対して1つのCRCナンバーを生成し、当該ナンバーを用いてフォーマティング命令をイネーブルにすることによって、効率的にデコードすることができる。そのようなデコーディングアルゴリズムは、ゲートレベル・インプリメンテーションに適しており、HTMLエンコードされたドキュメントを、今日可能であるよりもずっと敏速にビデオ出力デバイス上に表示させる。 As an example, a data handler that interprets an HTML format can decode an HTML tag using a cyclic redundancy check (CRC) calculation. The HTML format includes a character string known as a tag that controls the formatting of subsequent text blocks as they are displayed on a video output device. Those tags can be efficiently decoded by generating a CRC number for a given tag and using that number to enable formatting instructions. Such a decoding algorithm is suitable for gate-level implementations, allowing HTML encoded documents to be displayed on video output devices much more quickly than is possible today.
本発明は、ハードウェア・ゲートレベルであるとして記述されるが、当業者であれば、それらの機能は、プログラマブル・アレイ・ロジック(PAL)、ジェネラル・アレイ・ロジック(GAL)、読み出し専用メモリ(ROM)、ソフトウェアのような多くの他の仕方でインプリメントできるということを、容易に認識できる。さらに、特定のプロトコルおよびデータタイプが指示されてきたが、当業者であれば、本発明のモジュール性は、本発明を、それらの特定のプロトコルあるいはデータタイプに限定させないということを、容易に認識できる。 Although the present invention is described as being at the hardware gate level, those skilled in the art will recognize their functionality as programmable array logic (PAL), general array logic (GAL), read-only memory ( It can be easily recognized that it can be implemented in many other ways, such as ROM) or software. Furthermore, although specific protocols and data types have been indicated, those skilled in the art will readily recognize that the modularity of the present invention does not limit the present invention to those specific protocols or data types. it can.
図2を参照すると、本発明が、ハイレベル・ブロック・ダイアグラムで表現されている。このダイアグラムは、本発明の完全なインプリメンテーションにおける各モジュールの動作タスクを記述している。O.S.ステートマシン208は、システム“グルー”ロジック、および、デバイス制御インターフェイスを具備し、他のモジュールのステートマシン間の“トラフィックコップ”として働く。ネットワーク・プロトコル層207は，TCP/IPプロトコル, UDPプロトコル, ローソケット・プロトコル、PPPプロトコルに対するステートマシンを具備している。メモリ制御モジュール206は、システム・メモリとビデオ・ディスプレイ・メモリとが、同一のメモリエリアに存在することを可能にするユニファイド・メモリ・アーキテクチャ(UMA)のためのロジックを具備している。ディスプレイ・コントローラ205は、テレビジョン標準であるVGA、あるいは、他のタイプのディスプレイの制御を提供する。4つのデータ・ハンドラが、このインプリメンテーションに用いられている。Eメール・データ・ハンドラ201は、POP3フォーマットとIMAP4フォーマットとの両方をインタプリトする。JPEGフォーマットおよびGIFフォーマットをデコードする（商業標準および電話通信標準もデコードできる）インタプリタ202が、インプリメントされている。Java言語をバイトコード（中間言語）にインタプリトするJavaマシン203も、含まれている。ワールド・ワイド・ウェブ(WWW)ブラウザ204は、HTMLデコーダ／アクセラレータ、HTTPデータ・ハンドラ、および、集積されたeメール・ステート・マシンを具備している。
Referring to FIG. 2, the present invention is represented in a high level block diagram. This diagram describes the operational tasks of each module in a complete implementation of the invention. The O.S.
一例として、モデム物理トランスポートを想定して、入ってくるJPEG映像パケットが、システムによって追跡される。その要求は、ユーザが、定められたJPEG映像をダウンロードするという願望を、キーボード321をタイピングすることによって指示するとともに開始する。この入力は、キーボード・インターフェイス316によってインタプリトされ、O.S.ステートマシン315に渡される。O.S.ステートマシン315は、その入力を処理し、それを、1つのコマンドとして、HTTPクライアント311に渡す。HTTPクライアントは、要求されたパケットを生成し、それを、ポート・デコーダ309を介してTCP層308に渡す。TCP層は、適切なTCPヘッダをプリペンド（前方に追加）し、それを、IP層307に渡す。IP層は、次いで、適切なIPヘッダをプリペンドし、そのパケットを、PPP層306に渡す。PPP層は、適切なヘッダをプリペンドし、FCSをアペンド（後方に追加）し、そして、そのデータを物理トランスポート・インターフェイス305に渡す。物理トランスポート・インターフェイスは、そのデータをビットストリームに連続化し、そのパケットをモデム・ユニット304に送る。要求がホストサーバによって受け入れられると、ホストサーバは、要求されたJPEG映像をクライアント・システムに送り返す。そのデータは、最初に、データが存在することを物理トランスポート・インターフェイス305に指示するモデム 304によって受信される。物理トランスポート・インターフェイスは、次に、そのモデムからビット・シリアル・データを読み出し、それを、パラレル・バイト・データに変換し、そして、データが存在することをPPP層306に指示する。PPP層は、受信されたバイトを読み出す。PPP層が、有効なスタート・バイトを検出すると、そのPPP層は、入ってくるバイトを構文解析する。バイト・ストリームが、PPPプロトコル・フィールドに達すると、PPP層は、それをデコードし、そして、この例においては、埋め込まれているパケットを、タイプIPであるとしてデコードする。このプロトコルバイトに応えて、PPP層は、IP層307をイネーブルにし、そして、それに、IPデータが受信されていることを指示する。全てのそれ以降の受信データ・バイトは、今や、IP層に直接渡される。IP層は、次いで、入ってくるデータ・バイトの構文解析を始める。それが、IPヘッダ・プロトコル・フィールドまで来ると、それは、どのより高位のプロトコルがイネーブルにされるかを決定する。この例においては、IP層は、そのプロトコル・フィールドを、タイプTCPであるとしてデコードする。この時点で、IP層は、TCP層308をイネーブルにし、そして、TCPデータが受信されているときはいつでも、それに指示する。このインジケータがアクティブになると、全てのそれ以降の受信パケット内のデータ・バイトは、IP層とTCP層との両方に渡される（IP層は、チェックサム計算を完成させるためにデータ・バイトを必要とする）。TCP層は、その後、入ってくるデータ・バイトの構文解析を始める。それが、TCPヘッダ送信先ポート・フィールドまで来ると、それは、どのデータ・ハンドラがイネーブルにされるかを決定する。この例においては、そのポート・フィールドは、HTTPクライアント311をデコードする。この時点で、ポート・デコーダは、HTTPクライアントをイネーブルにし、そして、それに、HTTP要求データが受信されていることを指示する。HTTPクライアントは、次に、受信されたデータ・バイトの構文解析を始める。HTTPクライアントが、そのパケットがタイプJPEG映像であると決定すると、HTTPクライアントは、JPEGデコーダ313をイネーブルにする。この時点で、全てのデータ・バイトが、JPEGデコーダに発送される。JPEGデコーダは、次いで、全てのそれ以降に入ってくるデータ・バイトを受信し、したがって、それらを処理する。結果としてデコードされた映像が、メモリ・コントローラ312を介してディスプレイ・メモリに送られ、そして、ディスプレイデバイス326に出力するために、ディスプレイ・コントローラ324によって処理される。
As an example, assuming a modem physical transport, incoming JPEG video packets are tracked by the system. The request is initiated as the user indicates the desire to download a defined JPEG video by typing keyboard 321. This input is interpreted by the
図3に、また、示されているように、様々な層が、共有メモリリソースへのアクセスを必要とする。全てのメモリアクセスは、単一のメモリ・コントローラによって調停される。このメモリ・コントローラは、どの層あるいはどのハンドラが、任意の定められたサイクルでユニファイド・メモリ・バッファにアクセスを持つかを決定する。このメモリ・コントローラは、全てのシステム・メモリ・バッファおよびディスプレイ・メモリ・バッファが、単一のメモリ・バッファ・ユニットの内部に共有されるという事実のために必要とされる。ユニファイド・メモリ・コントローラ312は、様々な層からの読み出し要求および書き込み要求を取り上げ、一定の優先順位重み付けをなした動的循環アービトレーションスキームに基づいて、それらの要求を調停する。このアルゴリズムが、図3Aに描かれている。図示されている構成において、デバイスD2 302AとデバイスD3 303Aとの両方が、同時にメモリアクセスを要求すると、アービタ307Aが、最も最近にメモリアクセスを持たなかったデバイスにサイクルを振る。アービタ307Aは、次に、そのメモリ要求を、アービタ309AのA入力に渡す。アービタ309AのB入力がアイドル状態であれば、その要求は、アービタ310AのB入力に登る。アービタ310AのA入力がアイドル状態であれば、その要求は、メモリユニットに進む。全てのアービトレーション決定は、組み合わせ論理を用いて遂行され、それによって、どのデバイスに対しても、他のメモリ要求が全くなされていなければ、どんな待ち時間もなくしてしまう。優先順位重みは、アービトレーション樹構造を構成することによって割り当てられる。図3Aにおいて、デバイスDO 300AとデバイスD1 301Aとは、全てのデバイスが、不断のメモリ使用を要求した場合、それら2つのデバイスが、各々、25％時間アービトレーションを得ることのできる25％優先順位重み効力を、各々、持っている。デバイスD2 302A, D3 303A, D4 304A, D5 305Aは、各々、12.5％優先順位重みを持っている。メモリ・コントローラ設計は、個々のアービトレーション・ユニットの各々に同一の論理構造を持たせることによって、簡単になる。この仕組みにおいては、要求を出すデバイスの数、および、それらの優先順位重みは、アービタユニットを加え、そして、それらを配置することによって、簡単に構成できる。
As also shown in FIG. 3, various layers require access to shared memory resources. All memory accesses are arbitrated by a single memory controller. The memory controller determines which layer or which handler has access to the unified memory buffer in any given cycle. This memory controller is required due to the fact that all system memory buffers and display memory buffers are shared within a single memory buffer unit.
図4を参照すると、本発明が提示している速度的な優位性は、現在用いられている従来のアーキテクチャよりもずっと高い。図は、各タスクを完了するのに必要な時間を示している。HTMLダウンロード401、HTMLのデコード402、JPEGダウンロード403、JPEGのデコード404、JAVAダウンロード405、JAVAバイトのデコード406、および、ストリーミングオーディオ407を要求する一連のパケットに対して、それらのタスクに要する総時間が、従来のアーキテクチャ408と本発明（iReadyアーキテクチャ）409とにおいて示されている。本発明409は、それらのタスクにおいて、従来のアーキテクチャ408よりもはるかに速い。
Referring to FIG. 4, the speed advantage presented by the present invention is much higher than the traditional architecture currently in use. The figure shows the time required to complete each task. Total time required for these tasks for a series of packets that require
図5を参照すると、このタイプのネットワーク・アクセスの応用の発展が、示されている。現在、ネットワーク・クライアントの従来のモデル、即ち、コンピュータ501が、用いられている。ネットワークPC 502、ハンド・ヘルド・デバイス503、スマート電話504、セット・トップ・アプライアンス505、スマートテレビジョン506のコンシューマアプライアンス概念が、今や、現実となってきている。本発明は、コスト効率が高く、空間、速度、電力を重視したネットワーク・アクセスを備えた、それらの製品を供給する。
Referring to FIG. 5, the development of this type of network access application is shown. Currently, a conventional model of a network client,
図6を参照すると、本発明は、テレビジョンチューナ602あるいはラジオチューナ611とほとんど同じように動作する…信号（パケット）は、遅延なく即座に処理され、そして、ディスプレイ出力あるいはオーディオ出力に送られる。用語「インターネット・チューナ」608は、そのような信号処理デバイスとの類似性として、本発明を記述するために用いられる。インターネット・チューナ608は、インターネット信号609と、スマートテレビジョン604、セット・トップ・アプライアンス605、スマート電話606、ハンド・ヘルド・デバイス607のような応用製品との間のインターフェイスとして働く。それは、テレビジョンチューナ602やラジオチューナ611のように、リアルタイムでインターネット信号609を処理する。
Referring to FIG. 6, the present invention operates in much the same way as the
図7は、O.S.ステートマシン701、ネットワーク・プロトコル層702、メモリコントロール703、ディスプレイ・コントローラ704、eメール・データ・ハンドラ708、インタプリタ707、JAVAマシン706、WWWブラウザ705を用いた本発明の完全インプリメンテーションが、2つの分離したモジュールに分離されてもよいということを図解している。本発明のモジュール性は、データ・ハンドラ713（eメール・データ・ハンドラ717、インタプリタ716、JAVAマシン715、WWWブラウザ714）のような機能が、いくつかの応用において、1つの高水準ROMコード内に分離して置かれることを可能にする。
FIG. 7 shows a complete implementation of the present invention using an
以下の応用例は、本発明のモジュール設計の万能性をさらに図解する。 The following application examples further illustrate the versatility of the module design of the present invention.
図8は、ネットワークPC用として可能な本発明の構成を明示している。1つの変形例は、O.S.ステートマシン801、ネットワーク・プロトコル層802、メモリコントロール803、ディスプレイ・コントローラ804、eメール・データ・ハンドラ808、インタプリタ807、JAVAマシン806、WWWブラウザ805を含んでいる。これは、eメール817、インタプリタ816、JAVAマシン815、WWWブラウザ814コードに対するデータ・ハンドラを、1つのマイクロプロセッサ813上を走る高水準ROM（コード）内に置くことによって変形できる。マイクロプロセッサ813は、O.S.ステートマシン809を通じて、ネットワーク機能およびディスプレイ機能に対して交信する。第3の変形は、サードパーティROM 823を使うマイクロプロセッサ822が、ネットワーク・プロトコル層819およびO.S.ステートマシン818から入ってくるデータをインタプリトすることを可能にする。マイクロプロセッサ822は、ディスプレイ・コントローラ821を通してデータを表示する。
FIG. 8 demonstrates the possible configuration of the present invention for a network PC. One variation includes an
図9を参照すると、ハンド・ヘルド・デバイスは、ネットワーク・プロトコル層901しか用いず、それを、カスタム・トランスポート・メカニズム902および現行マイクロコントローラ904にインターフェイス接続するのであってもよい。Eメール機能が、この構成にeメール・データ・ハンドラ905を含ませることによって、付加されてもよい。本発明のモジュール性をさらに明示すると、ネットワーク・プロトコル層911およびJAVAマシン910を、ハンド・ヘルド・デバイスに加えてもよく、それによって、ハンド・ヘルド・デバイスは、JAVAアプレットを処理することが可能になる。
Referring to FIG. 9, the handheld device may only use the
図10を参照すると、スマート電話は、O.S.ステートマシン1001、ネットワーク・プロトコル層1002、メモリコントロール1003、eメール・データ・ハンドラ1006、ディスプレイ・コントローラ1004をインプリメントすることによって、eメール能力を付加されてもよい。ディスプレイ・コントローラ1004は、発光ダイオード(LED) ディスプレイ、液晶ディスプレイ(LCD)、あるいは、ビッグ・マップ・ディスプレイ(big-mapped display)を制御することができる。物理トランスポート・コントロール1005は、スマート電話の接続要件に応じて、オプション的に付加されてもよい。O.S.ステートマシン1007、ネットワーク・プロトコル層1008、メモリ・コントローラ1009が、現行マイクロコントローラ1010と一緒にスマート電話に付加されてもよい。マイクロコントローラ1010は、サードパーティeメール・クライアント・コード1011を用いて、eメール機能を遂行する。
Referring to FIG. 10, a smart phone is added with email capability by implementing an
最後に図11を参照すると、スマートテレビジョン、ケーブルボックス、ビデオ・カセット・レコーダ(VCR)、デジタルビデオディスク(DVD)プレーヤ、ゲームマシンが、本発明によって提示されるネットワーク・アクセス可能性を利用することができる。O.S.ステートマシン1102、ネットワーク・プロトコル層1103、メモリ・コントローラ1104、WWWブラウザ1107、JAVAマシン1106、および、（オプション的に）ディスプレイ・コントローラ1105が、現行コントローラ1101にインターフェイス接続されている。コントローラ1101が存在しないとき、ディスプレイ・コントローラ1105が、用いられる。eメール1115機能は、本発明のモジュール性の故に、容易に付加される。前述のように、eメール1124、インタプリタ1123、JAVAマシン1122、WWWブラウザ1121コードに対するデータ・ハンドラが、マイクロプロセッサ1120上を走る高水準ROM（コード）内にオプション的に置かれる。マイクロプロセッサ1120は、O.S.ステートマシン1116を通じて、ネットワーク機能およびディスプレイ機能に対して交信する。
Finally, referring to FIG. 11, smart televisions, cable boxes, video cassette recorders (VCRs), digital video disc (DVD) players, game machines take advantage of the network accessibility presented by the present invention. be able to. An O.S. state machine 1102, a network protocol layer 1103, a memory controller 1104, a
パケット受信の例
図12は、受信されたネットワーク・パケットを描いている。そのパケットには、以下のアイテムが、左から右に示すように含まれている。
Packet reception example Figure 12 depicts a received network packet. The packet includes the following items as shown from left to right.
PPPヘッダ
IPヘッダ
TCPヘッダ
JPEGデータ
PPP FCS（フィールド・チェックサム）
PPPレイヤイネーブルと表わされているラインが、有効なスタート・バイトが検出されたときにアクティブになり、図13のPPPブロックの内部に生成される。このラインがハイレベルになると、PPPブロックの残りの部分がアクティブになる。PPPヘッダ内には、PPPパケットがカプセル化されているプロトコルのタイプを指示するフィールドが存在する。圧縮されていないPPPヘッダでは、それらは、4バイトであり、（スタート・バイト0x7Eを含めて合計すると）5バイトである。図12において、それらのバイトは、カプセル化されているデータがIPパケットであることを指示する、0x00および0x21である。このフィールドをデコードした後、PPPブロックは、IPレイヤイネーブル信号およびPPPデータフィールド信号をアクティブにし、そして、それら両方が、図13のIPブロックをイネーブルにする。IPレイヤ・イネーブル・ラインは、PPPプロトコル・タイプ・フィールドによってデコードされ、PPPデータ・フィールド・ラインは、入ってくるデータ・バイト・ストリームがネットワーク・パケットのデータフィールド部にあることを指示する。これら2ラインは、IPブロックがイネーブルになるためには、アクティブでなければならない。IPブロックがイネーブルになると、それは、入ってくるデータ・バイトの構文解析を開始する。図12を参照し直すと、PPPヘッダの直ぐ後に続くデータは、IPヘッダである。IPヘッダ内には、IPパケットの内部にカプセル化されているデータタイプを指示するフィールドが存在する。図12において、このフィールドは、カプセル化されているデータがTCPパケットであることを指示する0x06であることが示されている。TCPレイヤ・イネーブル・ラインは、このフィールドをデコードするIPブロックに応えてアクティブになる。IPヘッダ・プロトコル・フィールドとIPデータフィールドの先頭との間にくるいくつかのバイトが存在するから、IPデータ・フィールド・ラインは、数バイトの後にアクティブになる。IPデータフィールド信号は、入ってくるデータ・バイト・ストリームがネットワーク・パケットのデータフィールド部にあることを指示する。図13のTCPブロックがイネーブルになるためには、TCPレイヤ・イネーブル・ラインとIPデータ・フィールド・ラインの両方ともが、アクティブでなければならない。TCPブロックがイネーブルになると、それは、入ってくるデータ・バイトの構文解析を開始する。図12を参照し直すと、IPヘッダの直ぐ後に続くデータは、TCPヘッダである。TCPヘッダ内には、送信先ポートに対する2バイトフィールドが、存在する。このフィールドは、カプセル化されたデータが、どのアプリケーションあるいはデータ・ハンドラに充てられているかを指示する。図12において、このフィールドは、ポート0x0003に対してデコードする。図13において、ポート3が、HTTPポートとして指定されている。TCPヘッダ内部の送信先ポート・フィールドをデコードした後、HTTPイネーブルラインが、アクティブになる。送信先ポート・フィールドとTCPデータフィールドの開始との間にいくつかの中間バイトが存在するから、TCPデータ・フィールド・ラインは、数バイトの後にアクティブになる。HTTPイネーブルラインとTCPデータ・フィールド・ラインの両方は、図13のHTTP/ポート3ブロックがイネーブルになるためには、アクティブでなければならない。HTTPブロックがイネーブルになると、それは、入ってくるデータ・バイトの構文解析を開始する。それが、JPEGヘッダをデコードすると、それは、図13のJPEGデコーダブロックをイネーブルにする。JPEGデコーダがイネーブルになると、それは、入ってくるデータ・バイトの処理を開始する。JPEGイネーブルラインは、JPEGブロックをイネーブルにするのに必要な唯一のラインである。
PPP header
IP header
TCP header
JPEG data
PPP FCS (field checksum)
A line labeled PPP layer enable is activated when a valid start byte is detected and is generated inside the PPP block of FIG. When this line goes high, the rest of the PPP block becomes active. Within the PPP header is a field that indicates the type of protocol in which the PPP packet is encapsulated. For uncompressed PPP headers, they are 4 bytes and 5 bytes (summing including the start byte 0x7E). In FIG. 12, these bytes are 0x00 and 0x21 indicating that the encapsulated data is an IP packet. After decoding this field, the PPP block activates the IP layer enable signal and the PPP data field signal, and both enable the IP block of FIG. The IP layer enable line is decoded by the PPP protocol type field, and the PPP data field line indicates that the incoming data byte stream is in the data field portion of the network packet. These two lines must be active for the IP block to be enabled. When the IP block is enabled, it starts parsing incoming data bytes. Referring back to FIG. 12, the data immediately following the PPP header is an IP header. In the IP header, there is a field indicating the data type encapsulated in the IP packet. In FIG. 12, this field is shown to be 0x06 indicating that the encapsulated data is a TCP packet. The TCP layer enable line becomes active in response to the IP block decoding this field. Since there are several bytes between the IP header protocol field and the beginning of the IP data field, the IP data field line becomes active after a few bytes. The IP data field signal indicates that the incoming data byte stream is in the data field portion of the network packet. In order for the TCP block of FIG. 13 to be enabled, both the TCP layer enable line and the IP data field line must be active. When the TCP block is enabled, it starts parsing incoming data bytes. Referring back to FIG. 12, the data immediately following the IP header is a TCP header. There is a 2-byte field for the destination port in the TCP header. This field indicates to which application or data handler the encapsulated data is devoted. In FIG. 12, this field is decoded for port 0x0003. In FIG. 13,
この詳細な記述は、TCP/IP処理の分野で十分に理解されている用語を用いている。これらの用語の詳細な記述を含む参照文献は、W. Richard Stevensによるテキストブック “TCP/IP Illustrated” 第1巻（国際標準図書コード0201633469）、第20刷であり、それは、ここで引用により援用される。適切な場所で、このテキストブックで説明されている、本記述に用いられる用語あるいは概念の説明が、適切なセクション番号あるいは図番によって示される。例えば、Stevens 2.2のような参照は、このテキストブックのセクション2.2のことを言っている。 This detailed description uses terms that are well understood in the field of TCP / IP processing. A reference containing a detailed description of these terms is the textbook “TCP / IP Illustrated”, Volume 1 (International Standard Book Code 0201633469), 20th edition by W. Richard Stevens, which is hereby incorporated by reference. Is done. Where appropriate, explanations of terms or concepts used in this description that are described in this text book are indicated by the appropriate section number or figure number. For example, references like Stevens 2.2 refer to section 2.2 of this textbook.
頭字語
以下の定義が、本明細書で、以下の頭字語に対して用いられる。
ADPCM 適応的差分パルス符号変調
ARP アドレス解決プロトコル
CPU 中央処理装置
DHCP 動的ホスト構成プロトコル
HATR ハードウェア・アシステッド・テキスト・ラスタライゼーション
ICMP インターネット制御メッセージプロトコル
IP インターネット・プロトコル
IPV4 インターネット・プロトコル・バージョン4
MAC メディア・アクセス・コントローラ
MDIO マネージメントデータ入力／出力
MII メディア・インデペンデント・インターフェイス
MIME 多目的インターネット・メール・エクステンション
PPP ポイント・ツー・ポイント・プロトコル
QoS クォリティ・オブ・サービス
RARP 逆アドレス解決プロトコル
SPI シリアル・ペリフェラル・インターフェイス
TCP トランスポート・コントロール・プロトコル
TTL タイム・ツー・ライブ（生存時間）
ToS タイプ・オブ・サービス
UDP ユーザ・データグラム・プロトコル
UI ユーザインターフェイス
The following acronyms are used herein for the following acronyms:
ADPCM adaptive differential pulse code modulation
ARP address resolution protocol
CPU central processing unit
DHCP dynamic host configuration protocol
HATR hardware-assisted text rasterization
ICMP Internet control message protocol
IP Internet protocol
IPV4 Internet Protocol version 4
MAC media access controller
MDIO management data input / output
MII Media Independent Interface
MIME multipurpose Internet mail extension
PPP point-to-point protocol
QoS quality of service
RARP reverse address resolution protocol
SPI serial peripheral interface
TCP transport control protocol
TTL time to live
ToS type of service
UDP user datagram protocol
UI user interface
モジュールリスト
以下の名称は、本明細書に記述されるモジュールに対して用いられ、参照のためにここにまとめられている。
The following names in the module list are used for the modules described herein and are grouped here for reference.
アドレス・フィルータ・モジュール
ARPキャッシュモジュール
ARPモジュール
データ・アライナ・モジュール
DMAエンジン・モジュール
イーサネット・フレーム・タイプ・パーザ・モジュール
イーサネット・インターフェイス・モジュール
イーサネットMACインターフェイス・モジュール
例外ハンドラ・モジュール
ICMPエコー応答モジュール
ICMPエコー応答プロセッサ・モジュール
ICMPエコー応答受信モジュール
インターナルプロセッサ
IP分割コントローラ・モジュール
IP分割モジュール
IPヘッダ・パーザ・モジュール
IP IDジェネレータ・モジュール
IPモジュール
IPパーザ・モジュール
IPルータ・モジュール
malloc1モジュール
メモリ・アロケータ・モジュール
NATとIPマスカレーディング・モジュール
パケット・スケジューラ・モジュール
パケット・タイプ・パーザ・モジュール
受信データ・メモリ・コントローラ・モジュール
受信DMAエンジン・モジュール
受信TCPパーザ・モジュール
受信器インターフェイス・モジュール
受信状態ハンドラ・モジュール
RSTジェネレータ・モジュール
ソケット受信インターフェイス・モジュール
ソケット受信モジュール
ソケット送信インターフェイス・モジュール
ソケット送信モジュール
TCPモジュール
TCPパーザ・モジュール
TCP受信インターフェイス・モジュール
TCP状態モジュール
TCP送信インターフェイス・モジュール
TCP送信モジュール
送信スケジューラ・モジュール
送信DMAエンジン・モジュール
送信器インターフェイス・モジュール
VSOCKメモリ・アロケータ・モジュール
VSOCKモジュール
Address field router module
ARP cache module
ARP module data aligner module
DMA engine module Ethernet frame type parser module Ethernet interface module Ethernet MAC interface module Exception handler module
ICMP echo response module
ICMP echo reply processor module
ICMP echo response receiving module internal processor
IP split controller module
IP partition module
IP header parser module
IP ID generator module
IP module
IP parser module
IP router module
malloc1 module memory allocator module
NAT and IP Masquerading Module Packet Scheduler Module Packet Type Parser Module Receive Data Memory Controller Module Receive DMA Engine Module Receive TCP Parser Module Receiver Interface Module Receive Status Handler Module
RST generator module socket reception interface module socket reception module socket transmission interface module socket transmission module
TCP module
TCP parser module
TCP receive interface module
TCP state module
TCP transmission interface module
TCP transmission module transmission scheduler module transmission DMA engine module transmitter interface module
VSOCK memory allocator module
VSOCK module
バンド幅が増加し続けるにつれて、TCP/IP通信を処理する能力は、システムプロセッサに対するオーバヘッドがますます大きくなる。イーサネット・データ・レートは、秒当り10ギガビットのレートに達するから、TCP/IPプロトコル処理は、ホストCPUの処理パワーの100％近くを消費する。イーサネット・データ・レートが、秒当り10ギガビットまで増加すると、全TCP/IPプロトコル処理は、専用のハードウェアにおろされなければならない。インターネット・チューナ10Gは、一連のステートマシンとして、ARP, RARP, IP ホストルーティングのような関連プロトコルとともに、TCP/IPをインプリメントしている。インターネット・チューナ10Gコアは、インターネット・チューナ10Gネットワーク・スタックの特徴を拡張するためにプロセッサを用いることができるような接続が設けられるが、なんらのプロセッサもソフトウェアも用いない。
As bandwidth continues to increase, the ability to handle TCP / IP communications becomes increasingly overhead to the system processor. Because the Ethernet data rate reaches 10 gigabits per second, TCP / IP protocol processing consumes nearly 100% of the host CPU processing power. As the Ethernet data rate increases to 10 gigabits per second, all TCP / IP protocol processing must be brought down to dedicated hardware.
図14を参照すると、インターネット・チューナ10G 1404コアの使用の一例は、ギガビット・イーサネット・アダプタ・カード用に意図されたギガビット・イーサネット・アダプタ・チップにある。応用の一例として、ギガビット・イーサネット・アダプタは、サーバ内にプラグインされ、TCP/UDP/IPパケットあるいは他のパケットに、同様のプロトコルを用いて、固有の処理を行う。
Referring to FIG. 14, an example of the use of an
インターネット・チューナ10Gコア 1404は、単一のギガビット・イーサネット・アダプタ・チップ内で、内部プロセッサ1406、システムペリフェラル1412、システムバスインターフェイス1414と連結している。このギガビット・イーサネット・アダプタ・チップは、イーサネット物理(PHY)デバイス1418、コンフィギュレーションEEPROM（コンフィギュレータ） 1410、インターネット・チューナ10Gコア 1404のためのオプションの外部メモリ1400と連結しており、ギガビット・イーサネット・アダプタを形成している。内部プロセッサ用のメモリ（ROMおよびRAMとも）は、ギガビット・イーサネット・アダプタ・チップ上（内部）にあってもよいし、ギガビット・イーサネット・アダプタ・チップの外側（外部）にあってもよい。
The
図15に関すると、インターネット・チューナ10G 1546は、例えば、ネットワークに配されたデバイス（記憶ユニット、プリンタ、カメラ等々のような）へのインターフェイスとして用いることができる。そのような応用において、カスタム・アプリケーション・ソケット1542が、第6層および第7層のプロトコルを処理し、そして、応用に特定のデータ移動を容易にするために、インターネット・チューナ10G 1546に付加されてもよい。このタイプの使用の例としては、ストリーミングメディアのためのカスタム・データ・パス、バルクデータ移動、および、iSCSI, RDMA, FCIPのようなプロトコルのためのサポートが、含まれる。
With reference to FIG. 15, the
インターネット・チューナ10Gは、秒当り10ギガビットレートで処理する回線速度をサポートするように設計されているが、それと同じアーキテクチャおよび論理を、より低い速度においても同様に用いることができる。そのような場合には、イーサネット・メディア・アクセス・コントローラ(MAC)およびPHYのみが異なるのみである。より低い回線速度でインターネット・チューナ10Gアーキテクチャを用いる利点には、より低い電力消費が含まれる。
The
高速バンド幅に対する課題は、無線回線速度でTCP/IPパケットを処理することにある。秒当り1ギガビットレベルで始めると、TCP/IPの処理オーバーヘッドがシステムの主要な消耗源となり、したがって、他の解が必要なことは、明らかである。インターネット・チューナ10Gは、種々のアーキテクチャ・インプリメンテーションによって、これに取り組む。それらには、以下の特徴が含まれる。
The challenge for high-speed bandwidth is to process TCP / IP packets at wireless link speeds. Clearly, starting at the 1 gigabit per second level, TCP / IP processing overhead is a major source of system exhaustion and therefore other solutions are needed. The
・入ってくるデータのストリーム処理
・広いデータ・パス
・プロトコル・ステートマシンの並列実行
・共有リソースのインテリジェント・スケジューリング
・最小のメモリコピー
インターネット・チューナ10Gは、インターネット・チューナ中にインプリメントされた、それらのアーキテクチャ概念を取り付けており、上述のエンハンスメントを付加している。
・ Streaming incoming data ・ Wide data path ・ Protocol ・ Parallel execution of state machine ・ Intelligent scheduling of shared resources ・ Minimum memory copy Internet ・ The
以下のセクションは、さまざまなデータ・パスおよび転送タイプにおける動作の理論の説明とともに、システムのブロックレベルの記述を提供する。 The following sections provide a block level description of the system, along with a description of the theory of operation in various data paths and transfer types.
ギガビット・イーサネット・アダプタ・チップは、インターネット・チューナ10G、内部プロセッサ、および、他の部品を具備する。ネットワーク・スタックが、プロトコル処理の大多数を遂行する。
The Gigabit Ethernet adapter chip includes an
図16を参照すると、ギガビット・イーサネット・アダプタ・チップのブロックレベルダイアグラムが、示されている。 Referring to FIG. 16, a block level diagram of the Gigabit Ethernet adapter chip is shown.
このセクションは、内部プロセッサの使用の概要を提供する。ギガビット・イーサネット・アダプタ・チップは、プログラム組み込みを可能にすることが要求されるところでは、プログラム組み込みを可能にするために内部プロセッサ1688を利用する。この内部プロセッサ1688は、周辺装置にも配されている。通常の動作条件では、内部プロセッサ1688は、ネットワーク・スタック1610を制御する。
This section provides an overview of the use of internal processors. The gigabit ethernet adapter chip uses an
内部プロセッサ1688は、メモリ（RAM、ROM、あるいは、その両方のいずれでも）の可変量にアクセスする能力を持っている。メモリは、インターネット・チューナ10Gチップと同じチップ上にあってもよいし、外部メモリであってもよい。内部プロセッサ周辺装置の全て、即ち、RAM、ROM、および、インターネット・チューナ10Gネットワーク・スタック1610は、内部プロセッサメモリのアドレス空間の内部に位置している。内部プロセッサRAM空間のうちの64キロバイトが、インターネット・チューナ10Gネットワーク・スタック1610に対するユニファイド・メモリとして構成されている。このユニファイド・メモリは、例外ハンドリングのために、また、内部プロセッサが、インターネット・チューナ10Gネットワーク・スタック1610によって送信または受信されるロー・イーサネット・パケットを組み立てるために、用いられる。このセクションは、インターネット・チューナ10Gアーキテクチャの概要を提供し、次いで、それに続くセクションは、個々のインターネット・チューナ10Gモジュールを記述する。インターネット・チューナ10Gは、上述のインターネット・チューナの元々のハードウェア・プロトコル処理のアイディアを採用しており、インターネット・チューナ10Gが、秒当り10ギガビット、および、それ以上のデータレートをハンドルすることをイネーブルにするエンハンスメントを付加している。
The
元々のインターネット・チューナに対する最も重要な付加は、増大されたデータ・パス幅、ステートマシンの並列実行、および、共有ハードウェアリソースのインテリジェント・スケジューリングである。さらに、インターネット・チューナ10Gは、RARP, ICMP, IGMP、および、iSCSIやRDMAのような新しい、より上位のプロトコルに対する直接のサポートを含めて、元々のインターネット・チューナよりも、プロトコルに対するさらなるサポートを供給する。
The most important additions to the original Internet tuner are increased data path width, parallel execution of state machines, and intelligent scheduling of shared hardware resources. In addition,
以下のセクションは、インターネット・チューナ10Gの基本的な構成要素の概要を提供する。その後のセクションは、インターネット・チューナ10Gの構成要素の全ての詳細な記述を提供する。
The following sections provide an overview of the basic components of
このセクションは、ソケット初期化を記述する。インターネット・チューナ10Gへの／からの任意のデータ転送に先立って、ソケットは、初期化されなければならない。ソケット初期化は、コマンド・ブロックを用いることによって遂行してもよいし、ソケットレジスタを直接プログラムすることによって遂行してもよい。全てのソケットに対してプログラムされなければならないパラメータには、送信先IPアドレス、送信先ポート番号、および、コネクションタイプ（TCPかUDPか、および、サーバかクライアントか）が含まれる。オプションのパラメータには、クォリティ・オブ・サービス(QoS)レベル、送信元ポート、タイム・ツー・ライブ(TTL)、および、タイプ・オブ・サービス(ToS)のセッティングが、含まれる。適切なパラメータがプログラムされると、そのソケットは、アクティブにされてもよいし、必要であれば、パケットを送受信するための接続が、確立されてもよい。UDPソケットの場合には、パケットは、即座に送信あるいは受信されてもよい。TCPクライアントにおいては、接続が、最初に確立されなければならない。TCPサーバにおいては、SYNパケットが、クライアントから受信されなければならず、そして、その後、接続が、確立されなければならない。
This section describes socket initialization. Prior to any data transfer to / from the
このセクションは、ホスト・コンピュータに接続されたインターネット・チューナ10Gによるパケットの送信の概要を提供する。
This section provides an overview of sending packets by the
図17に関すると、インターネット・チューナ10Gがパケットを送信するために、ホスト・コンピュータ上を走るソフトウェア・アプリケーションが、最初に、インターネット・チューナ10Gに接続されているソケット・バッファ・メモリ1742内のソケット・バッファに、そのパケット・データを書き込む。そのパケット・データは、ソケット・バッファ・メモリ1742内のソケット・バッファに書き込まれているパケット・データとして察知され（あるいは、モニタされ）、そのパケット・データの部分チェックサムが、保存される。この部分チェックサムの計算は、さらなるチェックサムの計算に対する開始シードとして用いられる。この部分チェックサムの計算は、パケットの送信に先立って、再度パケット・データを読み出す必要を取り除く。ソフトウェア・アプリケーションは、32ビット単位あるいは64ビット単位で、ソケット・バッファ・メモリ内のソケット・バッファにパケット・データを書き込むことができる。32ビット単位あるいは64ビット単位のパケット・データのどのビットが有効であるかを指示する信号が、用いられる。
Referring to FIG. 17, in order for the
ソフトウェア・アプリケーションが、ソケット・バッファ・メモリ1742内のソケット・バッファにパケットを書き込むと、ソフトウェア・アプリケーションは、インターネット・チューナ10Gに、送信コマンドを配給することができる。ソフトウェア・アプリケーションが、送信コマンドを配給すると、TCPモジュール1752が、パケット長を計算し、TCPチェックサムおよびIPチェックサムを計算し、そして、TCPヘッダおよびIPヘッダを組み立てる。TCP/UDPモジュールが、次に、それらのヘッダを、ソケット・バッファ1746内のパケットのデータ部の前面に挿入して、送信の準備のできた完全なパケットを形成する。次いで、TCPモジュール1752が、送信優先順位キューに基づいて、ソケット・バッファ・メモリ内のその完全なパケットに、ソケットQoSレベルといっしょに、ポインタを置く。
When the software application writes a packet to the socket buffer in
送信スケジューラ・モジュールは、送信優先順位キューをモニタしている。送信スケジューラ・モジュールは、送信を待っているパケットを持つ全てのソケットを調べて、最も高いソケットQoSレベルを備えたパケットを選択する。送信スケジューラ・モジュールは、TCP, UDP, ICMP, ARP, RARP、および、ロー・イーサネット・パケットを含む、送信を待っている全てのパケットを調べる。送信スケジューラ・モジュールは、最小バンド幅アルゴリズム(minimum-bandwidth algorithm)を用いて、どのソケットも、完全にはスターブされないことを確保する（後のセクションにおいて、最小バンド幅アルゴリズムが、記述される）。送信スケジューラ・モジュールは、送信のための1つのパケットを選択して、そのパケットのソケット・バッファ・メモリ・ポインタを、MAC TXインターフェイス・モジュールに渡す。MAC TXインターフェイス・モジュールは、そのソケット・バッファ・メモリ・ポインタを用いて、ソケット・バッファ・メモリからそのパケットを読み出して、そのパケットをMACモジュール1770に渡す。パケットが再送信の必要のある（イーサネット衝突のため、あるいは、他の理由のために）場合には、そのパケットは、MAC TXインターフェイス・モジュール・スニファ・バッファ1764にも記憶される。パケットが、ソケット・バッファ・メモリから送信されると、そのソケット・バッファ・メモリは、解放される。有効な送信ステータス信号が、MACモジュールから受信されると、MAC TXインターフェイス・モジュール・スニファ・バッファは、クリアされ、MACモジュールは、次のパケットを送信することができる。無効な送信ステータスが、MACモジュールから受信されると、その後、MAC TXインターフェイス・モジュール・スニファ・バッファに記憶された最後のパケットが、再送信される。
The transmission scheduler module monitors the transmission priority queue. The transmission scheduler module examines all sockets with packets waiting to be transmitted and selects the packet with the highest socket QoS level. The transmission scheduler module examines all packets waiting to be transmitted, including TCP, UDP, ICMP, ARP, RARP, and raw Ethernet packets. The transmit scheduler module uses a minimum-bandwidth algorithm to ensure that none of the sockets are completely starved (the minimum bandwidth algorithm is described in a later section). The transmission scheduler module selects one packet for transmission and passes the packet's socket buffer memory pointer to the MAC TX interface module. The MAC TX interface module reads the packet from the socket buffer memory using the socket buffer memory pointer and passes the packet to the
以下のセクションは、インターネット・チューナ10Gによるパケットの受信の概要を提供する。
The following section provides an overview of receiving packets by the
1つのパケットが、MACモジュールから受信されると、MACアドレス・フィルータ・モジュールが、イーサネット・ヘッダを調べて、そのパケットがハードウェア・インターフェイスに向けて送信されているかどうかを決定する。MACアドレス・フィルータ・モジュールは、ユニ・キャスト・アドレス、プログラムされたマスクの範囲内に収まるユニ・キャスト・アドレス、ブロードキャスト（一斉同報通信）アドレス、あるいは、マルチ・キャスト・アドレスを受信するようにプログラムできる。 When a packet is received from the MAC module, the MAC address phi router module examines the Ethernet header to determine if the packet is being sent towards the hardware interface. The MAC address phi router module receives a unicast address, a unicast address that falls within the programmed mask, a broadcast address, or a multicast address. Can be programmed.
受信されたパケットが、ARPパケットあるいはRARPパケットであれば、その受信されたパケットは、ARPモジュール1762に渡される。ARPモジュールは、受信されたパケットのOPフィールドを調べて、受信されたパケットがARP応答か（OPフィールドが1）、ARP要求か（OPフィールドが2）、RARP要求か（OPフィールドが3）、RARP応答か（OPフィールドが4）を決定する。受信されたパケットが、ARP要求パケットまたはRARP要求パケットであれば、ネットワーク上のあるデバイスが、そのARP要求パケットまたはRARP要求パケットに指定されているターゲットIPアドレスを持つネットワーク・デバイスからの情報を要求している。ARP要求パケットまたはRARP要求パケットのターゲットIPアドレスが、インターネット・チューナ10Gに属していれば、ARPモジュールが、ARP/RARP応答モジュールに、応答要求を渡す。受信されたパケットが、ARP応答パケットまたはRARP応答パケットであれば、受信されたパケットからの送り手のイーサネット・アドレスおよび受信されたパケットからの送り手のIPアドレスが、ARP/RARP要求モジュールに渡される。
If the received packet is an ARP packet or an RARP packet, the received packet is passed to the
受信されたパケットが、IPパケットであれば、そのパケットは、IPモジュールに渡される。IPモジュールは、受信されたIPパケットのIPヘッダの最初の4ビットにある4ビットIPバージョン・フィールドを調べて、そのパケットが、どのようにハンドルされなければならないかを決定する。パケットは、１度に64ビットずつ処理されるから、最初の64ビットが受信されただけでは、IPモジュールは、IPバージョン（IPv4かIPv6か）に関して、何らの想定もなすことができない。IPパケットの最初の64ビットが受信され、そして、処理されたときに、IPバージョンが、既知となる。この時点で、IPモジュールは、不用のIPバージョンデコードを中止し、そのIPバージョンデコーダをデフォルト状態にリセットする。 If the received packet is an IP packet, the packet is passed to the IP module. The IP module examines the 4-bit IP version field in the first 4 bits of the IP header of the received IP packet to determine how the packet must be handled. Since the packets are processed 64 bits at a time, the IP module cannot make any assumptions about the IP version (IPv4 or IPv6) just by receiving the first 64 bits. The IP version becomes known when the first 64 bits of the IP packet are received and processed. At this point, the IP module stops the unnecessary IP version decoding and resets the IP version decoder to the default state.
IPバージョンが既知になれば、IPモジュールは、IPヘッダの8ビット・プロトコル・フィールドをデコードする。デコードされたプロトコルに応じて、受信されたIPパケットが、さらなる処理のために、適切なモジュールに送られる。専用ハードウェア回路によって現在、直接的にサポートされているプロトコルには、TCP, UDP, ICMPが含まれる。 If the IP version is known, the IP module decodes the 8-bit protocol field of the IP header. Depending on the decoded protocol, the received IP packet is sent to the appropriate module for further processing. Protocols that are currently directly supported by dedicated hardware circuits include TCP, UDP, and ICMP.
インターネット・チューナ10Gの現在のバージョンでは、各ICMPエコー要求パケットが、専用ハードウェアによって直接的にハンドルされる。受信されたパケットが、ICMPエコー要求パケットであれば、そのICMPエコー要求パケットは、記憶され、そして、通知が、ICMP応答モジュールに渡される。ICMP応答モジュールは、ICMPエコー要求パケットのICMPコード・フィールドを、ICMPエコー応答パケットに対応する値に変更し、ICMPエコー応答パケットチェックサムを調整し、そして、送信のためにICMPエコー応答パケットをスケジュール化する。
In the current version of the
インターネット・チューナ10Gの現在のバージョンでは、各ICMPリダイレクト・パケットが、専用ハードウェアによって直接的にハンドルされる。受信されたパケットが、ICMPリダイレクト・パケットであれば、そのICMPリダイレクト・パケットは、構文解析され、そして、IPルートテーブルの適切なエントリが更新できるように、情報がIPルータ・モジュールに送られる。
In the current version of the
他のタイプのICMPパケット、IGMPパケット、あるいは、専用ハードウェアによって直接的にサポートされていない他のプロトコルに対応するパケットは、内部プロセッサがそれらをハンドルできるIPバッファにコピーされる。タイム・クリティカル・データを携行しないプロトコルは、しばしば、ハウス・キーピング・プロトコルと呼ばれる。どのハウス・キーピング・プロトコルが専用ハードウェア回路によって処理されるかの決定は、インターネット・チューナ10Gのインプリメンテーションに依存する。インターネット・チューナ10Gのアーキテクチャは、さまざまなインプリメンテーションが、ハウス・キーピング・プロトコルを処理するために、専用ハードウェア回路と内部プロセッサとのどちらをも用いることができるほどに、十分にフレキシブルである。
Packets corresponding to other types of ICMP packets, IGMP packets, or other protocols not directly supported by dedicated hardware are copied into an IP buffer that the internal processor can handle. Protocols that do not carry time critical data are often referred to as housekeeping protocols. The determination of which housekeeping protocol is handled by a dedicated hardware circuit depends on the implementation of the
受信されたパケットが、オ−プン・ソケットに対応するTCPパケットである場合には、そのソケット情報が構文解析され、そのソケットの状態情報が検索され、そして、受信されたTCPパケットのタイプに基づいて、そのソケット状態情報が更新される。受信されたTCPパケットのデータ・セクション（それが当てはまる場合には）が、そのソケットの受信データ・バッファに記憶される。ACKパケットが、TCPパケットを受信した結果として生成される必要のある場合には、TCP状態モジュールが、ACKパケットを生成し、そして、そのACKパケットを、送信のためにスケジュール化する。オ−プン・ソケットに対応していないTCPパケットが受信された場合には、TCP状態モジュールが、RSTパケットを生成し、そして、そのRSTパケットが、送信のためにスケジュール化される。 If the received packet is a TCP packet corresponding to an open socket, the socket information is parsed, the socket status information is retrieved, and based on the type of TCP packet received Thus, the socket status information is updated. The data section of the received TCP packet (if applicable) is stored in the socket's receive data buffer. If an ACK packet needs to be generated as a result of receiving a TCP packet, the TCP state module generates an ACK packet and schedules the ACK packet for transmission. If a TCP packet is received that does not correspond to an open socket, the TCP state module generates an RST packet and the RST packet is scheduled for transmission.
受信されたパケットが、UDPパケットである場合には、そのソケット情報が構文解析され、そのUDPパケット・データが、そのソケットの受信データ・バッファに記憶される。オ−プン・ソケットが、そのUDPパケットに全く存在しない場合には、そのUDPパケットは黙って放棄され、そして、ICMP送信先到達不能あるいは他のメッセージが生成される。 If the received packet is a UDP packet, the socket information is parsed and the UDP packet data is stored in the received data buffer of the socket. If there is no open socket in the UDP packet, the UDP packet is silently discarded and an ICMP destination unreachable or other message is generated.
インターネット・チューナ10Gネットワーク・スタックは、内部プロセッサに対する周辺装置であるようにみえる。インターネット・チューナ10Gネットワーク・スタックに対する基準アドレスは、レジスタを介してプログラムされる。全てのレジスタアドレスは、この基準アドレス・レジスタに対するオフセットである。このアーキテクチャは、内部プロセッサが、インターネット・チューナ10Gネットワーク・スタックを、内部プロセッサメモリあるいはI/O空間の任意の位置に置くことを可能にする。
The
以下のセクションは、インターネット・チューナ10Gの構成要素の詳細な記述を提供する。
The following section provides a detailed description of the components of
このセクションは、イーサネット・インターフェイス・モジュール1766を詳述する。イーサネット・インターフェイス・モジュールは、イーサネットMACインターフェイス・モジュール1770、ARPモジュール1762、および、IPモジュール1758と通信する。イーサネット・インターフェイス・モジュールは、受信パスおよび送信パスの両方のデータをハンドルする。
This section details the
送信パス上では、イーサネット・インターフェイス・モジュールは、以下のことに責を負っている。 On the transmit path, the Ethernet interface module is responsible for:
・送信のためにパケットをスケジュール化すること。 • Schedule packets for transmission.
・送信のためにDMAチャネルをセットアップすること。 • Set up a DMA channel for transmission.
・イーサネットMACインターフェイス送信信号をハンドルすること。 • Handle Ethernet MAC interface transmission signals.
受信パス上では、イーサネット・インターフェイス・モジュールは、以下のことに責を負っている。 On the receive path, the Ethernet interface module is responsible for:
・イーサネット・ヘッダを構文解析すること。
・アドレスフィルタセッティングに基づいて、受信されたパケットを受け入れるべきか排除すべきかを決定すること。
・受信されたパケットのフレーム・ヘッダのイーサネット・フレームタイプ・フィールドに基づいて、適切なプロトコル・モジュールをイネーブルにすること。
・受信されたパケットのデータ・セクションが、64ビット境界から始まるように、受信されたパケット・データを境界整列させること。
• Parse the Ethernet header.
Determine whether to accept or reject received packets based on address filter settings.
Enable the appropriate protocol module based on the Ethernet frame type field in the frame header of the received packet.
Align the received packet data so that the data section of the received packet starts on a 64-bit boundary.
このセクションは、送信スケジューラ・モジュールを扱う。送信スケジューラ・モジュールは、ARPモジュール, IPモジュール, TCPモジュール、および、ロー送信モジュールからパケット送信要求を受け取り、どのパケットが次に送信されるべきかを決定することに責を負っている。送信スケジューラ・モジュールは、各パケット送信要求のQoSレベルを比較することによって、次に送信されるべきパケットを決定する。QoSレベルとともに、各パケット送信要求には、そのパケットの開始メモリ・ブロックに対するポインタが、パケット長とともに含まれている。送信スケジューラ・モジュールは、コネクション型に属するパケットの送信に優先順位をつけるようにプログラムされる適応性を持っている。例えば、TCPモジュールからのQoSレベル5を持つパケット送信要求は、IPモジュールからのQoSレベル5を持つパケット送信要求よりも高い優先順位を持つようにすることができる。以下は、パケット送信優先順位を決定するために送信スケジューラ・モジュールによって用いられるアルゴリズムである。
This section deals with the transmission scheduler module. The transmission scheduler module is responsible for receiving packet transmission requests from the ARP module, IP module, TCP module, and raw transmission module and determining which packet should be transmitted next. The transmission scheduler module determines the next packet to be transmitted by comparing the QoS level of each packet transmission request. Along with the QoS level, each packet transmission request includes a pointer to the starting memory block of that packet along with the packet length. The transmission scheduler module has the flexibility to be programmed to prioritize the transmission of packets belonging to the connection type. For example, a packet transmission request having
・何らのパケットチャネルも、スターブされた状態に達していないことを確かめるためにチェックする。これは、送信スケジューラ・モジュールがQoSレベルに応じないで、パケットを送信する以前に、そのパケットが見過ごされる回数に対応する、プログラムに組めるレベル（パケット型にしたがって、あるいは、コネクション型にしたがって）である。2つ以上のパケットが、同時にスターブされた状態に達している場合には、より高いQoSレベルを持つチャネルに属するパケットが、優先される。より低いQoSレベルを持つチャネルに属するパケットは、次に送信されるようにスケジュール化される。2つ以上のパケットが、同一のQoSレベルを持っている場合には、それらは、次の順番；TCPまたはUDPパケット、その次にARPパケット、その次にIPパケット、その次にロー・イーサネット・パケット、にしたがって、順に送り出される。 Check to make sure that no packet channel has reached the starved state. This is a level that can be built into a program (according to the packet type or connection type) that corresponds to the number of times that the packet is overlooked before the transmission scheduler module sends the packet without depending on the QoS level. is there. If two or more packets have reached the starved state at the same time, the packet belonging to the channel with the higher QoS level is given priority. Packets belonging to channels with lower QoS levels are scheduled to be transmitted next. If two or more packets have the same QoS level, they are in the following order: TCP or UDP packets, then ARP packets, then IP packets, then Low Ethernet The packets are sent out in order.
・ スターブされた状態のパケットを持つチャネルが、何ら存在しない場合には、最も高くQoSレベルとチャネル重みとが結合されたチャネルが、送信される。 If there is no channel with packets in the starved state, the channel with the highest QoS level combined with the channel weight is transmitted.
・ただ1つのチャネルしか、送信されるべき1つのパケットを持たない場合には、そのパケットは、直ちに送信される。 If only one channel has one packet to be sent, that packet is sent immediately.
1つのチャネルに属する1つのパケットが、送信のために選択されると、そのチャネルのメモリ・ポインタ、パケット長、および、パケット・タイプが、DMAエンジン・モジュールに転送される。転送が完了すると、そのDMAエンジン・モジュールは、送信スケジューラ・モジュールに信号を送る。この時点で、送信スケジューラ・モジュールは、DMAエンジン・モジュールに、次のパケットのパラメータを転送する。 When a packet belonging to a channel is selected for transmission, the channel's memory pointer, packet length, and packet type are transferred to the DMA engine module. When the transfer is complete, the DMA engine module signals the transmit scheduler module. At this point, the transmission scheduler module transfers the parameters of the next packet to the DMA engine module.
このセクションは、DMAエンジン・モジュールについて記述する。送信スケジューラ・モジュールは、DMAエンジン・モジュールに、パケットパラメータ情報を渡す。パケットパラメータ情報には、パケット・タイプ、パケット長、および、パケット・データの開始に対するメモリ・ポインタが含まれる。DMAエンジン・モジュールは、パケット長を用いて、どれくらい多くのデータが、メモリ・バッファから転送されるかを決定する。パケット・タイプは、DMAエンジン・モジュールに、どのメモリ・バッファからパケット・データを検索するかを指示し、また、メモリ・ポインタは、どこからパケット・データの読み出しを開始するかを指示する。1つのパケットが、複数のメモリ・ブロックに渡ることができるから、DMAエンジン・モジュールは、そのチャネルのパケットに用いられているメモリ・ブロックの各々が、どのくらいの大きさであるかを理解する必要がある。DMAエンジン・モジュールは、メモリ・コントローラから、一度にデータ64ビットずつを受け取り、送信器インターフェイス・モジュールに、一度にデータ64ビットずつを渡す。 This section describes the DMA engine module. The transmission scheduler module passes packet parameter information to the DMA engine module. The packet parameter information includes a packet type, a packet length, and a memory pointer for the start of the packet data. The DMA engine module uses the packet length to determine how much data is transferred from the memory buffer. The packet type tells the DMA engine module from which memory buffer to retrieve packet data, and the memory pointer tells where to start reading packet data. Since one packet can span multiple memory blocks, the DMA engine module needs to understand how large each of the memory blocks used for that channel's packets is. There is. The DMA engine module receives 64 bits of data at a time from the memory controller and passes 64 bits of data at a time to the transmitter interface module.
このセクションは、送信器インターフェイス・モジュールを扱う。送信器インターフェイス・モジュールは、DMAエンジン・モジュールからの出力を受け取り、イーサネットMACインターフェイス・モジュールに対する信号を生成する。64ビット・データ・バスが、DMAエンジン・モジュールとイーサネットMACインターフェイス・モジュールとを接続する。 This section deals with transmitter interface modules. The transmitter interface module receives the output from the DMA engine module and generates a signal for the Ethernet MAC interface module. A 64-bit data bus connects the DMA engine module and the Ethernet MAC interface module.
このセクションは、受信器インターフェイス・モジュールを扱う。受信器インターフェイス・モジュールは、イーサネットMACインターフェイス・モジュールとインターフェイスしている。受信器インターフェイス・モジュールは、イーサネット・フレームを受け取り、そして、それらを、状態カウント情報とともに、アドレス・フィルータ・モジュールおよびイーサネット・フレームタイプ・パーザ（構文解析プログラム）モジュールに提出する。 This section deals with receiver interface modules. The receiver interface module interfaces with the Ethernet MAC interface module. The receiver interface module receives the Ethernet frames and submits them, along with the state count information, to the address phi router module and the Ethernet frame type parser module.
このセクションは、アドレス・フィルータ・モジュールおよびイーサネット・フレーム・タイプ・パーザ・モジュールを扱う。アドレス・フィルータ・モジュールおよびイーサネット・タイプ・パーザ・モジュールは、イーサネット・ヘッダを構文解析し、以下の2つの機能を遂行する。 This section deals with the address phi router module and the Ethernet frame type parser module. The address phi router module and the Ethernet type parser module parse the Ethernet header and perform the following two functions:
・そのイーサネット・フレームが、インターネット・チューナ10Gに属するハードウェア・インターフェイスに対するものであるかどうかを決定する。
・イーサネット・フレームタイプを構文解析して、イーサネット・フレームの残りを渡す場所を決定する。
アドレス・フィルータ・モジュールおよびイーサネット・フレーム・タイプ・パーザ・モジュールは、以下のフィルタオプションを用いてプログラムできる。
・プログラムされたユニ・キャスト・アドレスを受け入れる。
・ブロードキャスト・アドレスを受け入れる。
・マルチ・キャスト・アドレスを受け入れる。
・ネットマスクによって指定される範囲内のアドレスを受け入れる。
・無差別モード（全てのイーサネット・フレームを受け入れる）。
Determine if the Ethernet frame is for a hardware interface belonging to the
Parse the Ethernet frame type to determine where to pass the rest of the Ethernet frame.
The address filter module and the Ethernet frame type parser module can be programmed with the following filter options:
• Accept programmed unicast addresses.
-Accept broadcast address.
• Accept multi-cast addresses.
-Accept addresses within the range specified by the netmask.
Promiscuous mode (accepts all Ethernet frames).
これらのフィルタオプションを制御するパラメータは、ホスト・システムのソフトウェアによって設定される。 The parameters that control these filter options are set by the host system software.
以下のイーサネット・フレームタイプが、イーサネット・フレーム・タイプ・パーザ・モジュールによってサポートされている。 The following Ethernet frame types are supported by the Ethernet frame type parser module:
・イーサネット・フレームタイプ = 0x8000を持つIPv4パケット
・イーサネット・フレームタイプ = 0x86DDを持つIPv6パケット
・イーサネット・フレームタイプ = 0x0806を持つARPパケット
・イーサネット・フレームタイプ = 0x8035を持つRARPパケット
イーサネット・フレームタイプ・パーザは、他のイーサネット・フレームタイプを、例外ハンドラ・モジュールに渡す。
IPv4 packet with Ethernet frame type = 0x8000 Ethernet frame type = IPv6 packet with 0x86DD Ethernet frame type = ARP packet with 0x0806 Ethernet frame type = RARP packet with 0x8035 Ethernet frame type parser Passes other Ethernet frame types to the exception handler module.
イーサネット・フレームタイプ・パーザは、また、802.2/802.3フォーマット・イーサネット・フレームとDIXフォーマット・イーサネット・フレームとの両方もハンドルする。802.2/802.3フォーマット・イーサネット・フレームでは、DIXフォーマット・イーサネット・フレームに存在するイーサネット・フレームタイプ・フィールドに替わって、長さパラメータが存在する。802.2/802.3イーサネット・フレームは、イーサネット・フレームタイプ・フィールドの値が、1500（10進）以下になったときに検出される。この事例が検出されると、イーサネット・フレームタイプ・パーザは、ARPモジュールとIP受信モジュールとの両方に、そのイーサネット・フレームに含まれるパケットを送るとともに、以後の各モジュールが、パケットがそのモジュール用ではないこともあるということを認識しながら、パケットをデコードしなければならないということを知るような信号をアサートする（アクテイブにする）。0x8000と0x86DDとのどちらのイーサネット・フレームタイプが受信されても、IPパケット信号がアサートされる。そうすると、IPヘッダ・パーザ・モジュールは、そのパケットがIPv4パケットであるか、IPv6パケットであるかを決定する。IPヘッダのプロトコル・バージョン・フィールドは、インターネット・チューナ10Gがパケットのプロトコルを決定する場合には、イーサネットパケット・タイプ・フィールドに優先する。
The Ethernet frame type parser also handles both 802.2 / 802.3 format Ethernet frames and DIX format Ethernet frames. In the 802.2 / 802.3 format Ethernet frame, there is a length parameter instead of the Ethernet frame type field present in the DIX format Ethernet frame. An 802.2 / 802.3 Ethernet frame is detected when the value of the Ethernet frame type field is 1500 (decimal) or less. When this case is detected, the Ethernet frame type parser sends the packet contained in the Ethernet frame to both the ARP module and the IP receiver module, and each subsequent module sends a packet for that module. Recognize that it may not be, and assert (activate) a signal that knows that the packet must be decoded. The IP packet signal is asserted regardless of whether the Ethernet frame type 0x8000 or 0x86DD is received. Then, the IP header parser module determines whether the packet is an IPv4 packet or an IPv6 packet. The protocol version field of the IP header takes precedence over the Ethernet packet type field when the
このセクションは、データ・アライナ・モジュールを扱う。データ・アライナ・モジュールは、データ・アライナ・モジュールに続くプロトコル処理モジュールのためにデータ・バイトを境界整列させる。データ・アライナ・モジュールは、イーサネット・ヘッダが64ビットのちょうど倍数でないために必要とされる。VLAN（バーチャルLAN）タグが、イーサネット・ヘッダに存在するか否かに依存して、データライナが、イーサネット・ヘッダに64ビット・データを再整列させて、イーサネット・ヘッダが、データ・アライナ・モジュールに続くプロトコル処理モジュールに対して長さのそろったMSBで現れるようにする。そうすると、イーサネット・フレームのデータ・セクションが、常に、ちょうど64ビット境界に境界整列する。データ・アライナ・モジュールは、また、データ・アライナ・モジュールに続くプロトコル処理モジュールに対する準備信号も生成する。 This section deals with the data aligner module. The data aligner module aligns the data bytes for the protocol processing module that follows the data aligner module. The data aligner module is required because the Ethernet header is not a multiple of 64 bits. Depending on whether a VLAN tag is present in the Ethernet header, the data liner realigns the 64-bit data to the Ethernet header, and the Ethernet header is the data aligner module. For the protocol processing module following, make it appear in the MSB with the same length. Then, the data section of the Ethernet frame is always aligned on just a 64-bit boundary. The data aligner module also generates a prepare signal for the protocol processing module that follows the data aligner module.
このセクションは、ARPモジュール1762およびARPキャッシュモジュール1750について記述する。ARPモジュールは、RARPプロトコルもサポートするが、ARPキャッシュを含まない。パケットを送信できる各モジュールは、それに先立ってARPキャッシュに照会を行うから、ARPキャッシュは、ARPモジュールから分離しておかれる。ARPモジュールは、受信されたイーサネット・フレームタイプに基づいて、ARPキャッシュに更新を送ることができる。
This section describes the
ARPモジュールの能力は、以下の通りである。 The capabilities of the ARP module are as follows.
・ARP応答を生成することによってARP要求に応えることができる。
・ARPキャッシュに応えてARP要求を生成することができる。
・複数のIPアドレス（マルチホームホストの場合に、あるいは、ARPプロキシの機能を遂行するために用いられる）にARP応答を提供することができる。
・ターゲットされた（ユニキャスト）ARP要求を生成することができる。
・不法なイーサネット・アドレスおよび不法なIPアドレスを取り除く。
・整列されたARPデータを内部プロセッサに渡す。
・gratuitousARPを遂行することができる。
・内部プロセッサは、ARPデータを例外ハンドラにコピーして、自動的なARP応答の生成を回避することができる。
・内部プロセッサは、カスタムARP応答を生成することができる（回避モードにおいて）。
-It can respond to ARP requests by generating ARP responses.
-An ARP request can be generated in response to the ARP cache.
It can provide ARP responses to multiple IP addresses (used for multi-homed hosts or to perform ARP proxy functions).
Can generate targeted (unicast) ARP requests.
• Remove illegal Ethernet addresses and illegal IP addresses.
Pass the aligned ARP data to the internal processor.
-Gratuitous ARP can be performed.
• The internal processor can copy ARP data to an exception handler to avoid automatic ARP response generation.
• The internal processor can generate a custom ARP response (in avoidance mode).
ネットワーク状態に依存してのARPパケットの可変優先順位。 Variable priority of ARP packets depending on network conditions.
RARPモジュールの能力は、以下の通りである。 The capabilities of the RARP module are as follows.
・IPアドレスを要求する。
・特定のIPアドレスを要求する。
・はいってくるRARP要求が、例外ハンドラに渡される。
・イレギュラーRARP応答（ARP OPフィールドを持つRARPイーサネット・フレームタイプ、または、その逆）をハンドルする。
・整列したRARPデータを内部プロセッサに渡す。
・内部プロセッサは、カスタムRARP要求および応答を生成することができる。
-Request an IP address.
Request a specific IP address.
• The incoming RARP request is passed to the exception handler.
Handles an irregular RARP response (RARP Ethernet frame type with ARP OP field, or vice versa).
• Pass the aligned RARP data to the internal processor.
Internal processor can generate custom RARP requests and responses.
ARPキャッシュモジュールの能力は、以下のようである。 The capabilities of the ARP cache module are as follows.
・動的なARPテーブルサイズ。
・自動的に更新されるARPエントリ情報。
・送り手のハードウェアアドレスが変化したときに、ステータス・メッセージを生成する。
・ARPデータを無差別に収集できる。
・ARPモジュールを介するARP要求能力。
・静的なARPエントリをサポートする。
・静的なARPエントリを、動的なARPデータによって置き換えることをイネーブルにするためのオプション。
・ARPプロキシをサポートする。
・ARPキャッシュ・エントリに対して構成可能な終了時。
-Dynamic ARP table size.
-ARP entry information that is automatically updated.
Generate a status message when the sender's hardware address changes.
-ARP data can be collected indiscriminately.
-ARP request capability via the ARP module.
• Supports static ARP entries.
An option to enable the replacement of static ARP entries with dynamic ARP data.
-Supports ARP proxy.
• Configurable end for ARP cache entry.
以下のセクションは、ARPモジュールの動作の理論を説明する。 The following section explains the theory of operation of the ARP module.
このセクションは、ARPモジュールによるパケットの受信および構文解析を扱う。図18を参照すると、ARPモジュールは、ARPパケットとRARPパケットとの両方を処理する。ARPモジュールは、イーサネット受信モジュール1896から受信される、データに利用可能な信号を待っている。データに利用可能な信号が受信されると、入ってくるイーサネット・フレームのイーサネット・フレームタイプが、チェックされる。そのイーサネット・フレームタイプが、ARPまたはRARPに対応していなければ、ARPモジュールは、そのイーサネット・フレームに含まれているパケットを無視する。そうでなければ（対応していれば）、ARPモジュールは、そのイーサネット・フレームに含まれているパケット1898の構文解析を始める。
This section deals with packet reception and parsing by the ARP module. Referring to FIG. 18, the ARP module processes both ARP packets and RARP packets. The ARP module is waiting for a signal available for data received from the
パケットは、イーサネット・インターフェイス・モジュールから、64ビット・ワードで読み出される。28バイトARPパケット（イーサネット・ヘッダを除いて）は、3.5個の64ビット・ワードを占める。 Packets are read in 64-bit words from the Ethernet interface module. A 28-byte ARP packet (excluding the Ethernet header) occupies 3.5 64-bit words.
ARPパケットの最初の64ビット・ワードの最初の48ビットには、ハードウェアアドレスのタイプ、プロトコルアドレスのタイプ、バイト単位でのハードウェアアドレス長、および、バイト単位でのプロトコルアドレス長が、含まれる。ARPパケットのアドレスタイプ、および、長さフィールドの値が、イーサネット上でIPv4におけるARP要求に対して期待される値と比較される。それらの値が一致しなければ、そのARPパケットは、例外ハンドラ1894に渡される。そうでない場合には（一致していれば）、ARPモジュールが、ARPパケットの構文解析を続ける。ARPパケットの最初の64ビット・ワードの最後の16ビットには、ARP OPフィールドが、含まれる。ARPモジュールは、ARP OPフィールドを記憶し、そのARP OPフィールドが有効であるかどうかを確かめるためにチェックする。有効なARPパケットは、1, 2, 3または4に等しいARP OPフィールドを持つ。ARP OPフィールドが有効でない場合には、そのARPパケットは、例外ハンドラに渡される。そうでない場合には、ARPモジュールは、ARPパケットの構文解析を続ける。
The first 48 bits of the first 64-bit word of the ARP packet contains the hardware address type, protocol address type, hardware address length in bytes, and protocol address length in bytes . The address type of the ARP packet and the value of the length field are compared with the values expected for an ARP request in IPv4 over Ethernet. If the values do not match, the ARP packet is passed to the
ARPパケットの2番目の64ビット・ワードには、送り手ハードウェアアドレス、および、送り手プロトコルアドレスの半分が含まれなくてはならない。ARPモジュールは、、送り手ハードウェアアドレス・レジスタに、ARPパケットの2番目の64ビット・ワードの最初の48ビットを記憶する。次に、ARPモジュールは、送り手ハードウェアアドレスが有効かどうかをチェックする。送り手ハードウェアアドレスは、それがインターフェイスのイーサネット・アドレスと同様であるか、あるいは、それがブロードキャスト・アドレスであれば、無効である。送り手ハードウェアアドレスが無効であれば、そのパケットは、破棄される。ARPパケットの2番目の64ビット・ワードの最後の16ビットは、送り手プロトコルアドレス・レジスタの上部半分に記憶される。 The second 64-bit word of the ARP packet must contain the sender hardware address and half of the sender protocol address. The ARP module stores the first 48 bits of the second 64-bit word of the ARP packet in the sender hardware address register. The ARP module then checks whether the sender hardware address is valid. The sender hardware address is invalid if it is similar to the interface's Ethernet address or if it is a broadcast address. If the sender hardware address is invalid, the packet is discarded. The last 16 bits of the second 64-bit word of the ARP packet are stored in the upper half of the sender protocol address register.
ARPパケットの3番目の64ビット・ワードには、送り手プロトコルアドレスの後半が含まれており、また、ターゲットハードウェアアドレスも含まれている。ARPモジュールは、ARPパケットの3番目の64ビット・ワードの最初の16ビットを、送り手プロトコルアドレス・レジスタの下部の16ビットに記憶し、そして、送り手プロトコルアドレスが有効なことをチェックする。送り手プロトコルアドレスは、それがハードウェア・インターフェイスのIPアドレスと同様であるか、あるいは、その送り手プロトコルアドレスがブロードキャスト・アドレスであれば、無効である。送り手プロトコルアドレスが無効であれば、ARPモジュールは、そのARPパケットを破棄する。 The third 64-bit word of the ARP packet contains the second half of the sender protocol address and also contains the target hardware address. The ARP module stores the first 16 bits of the third 64-bit word of the ARP packet in the lower 16 bits of the sender protocol address register and checks that the sender protocol address is valid. The sender protocol address is invalid if it is similar to the hardware interface IP address or if the sender protocol address is a broadcast address. If the sender protocol address is invalid, the ARP module discards the ARP packet.
ARPモジュールは、ターゲットハードウェアアドレスとインターフェイスのイーサネット・アドレスとを比較する。ターゲットハードウェアアドレスが、そのインターフェイスに属するイーサネット・アドレスと一致しなければ、ARPモジュールは、そのARPパケットを破棄する。ターゲットハードウェアアドレスが、インターネット・チューナ10Gのインターフェイスのイーサネット・アドレスと同様であれば、ARPモジュールは、そのARPパケットの処理を続ける。
The ARP module compares the target hardware address with the Ethernet address of the interface. If the target hardware address does not match the Ethernet address belonging to the interface, the ARP module discards the ARP packet. If the target hardware address is similar to the Ethernet address of the
ARPパケットの4番目（最後）の64ビット・ワードの最初の32ビットには、ターゲットプロトコルアドレスが含まれている。ARPパケットは、長さが、3.5ワード即ち28バイト（224ビット）でなければならないので、この4番目の64ビット・ワードの最初の32ビットだけしか有効でない。ARPモジュールは、ターゲットプロトコルアドレスを、ターゲットプロトコルアドレス・レジスタに記憶する。ARPモジュールは、ターゲットプロトコルアドレスと、インターフェイスのIPアドレスとを比較する。ターゲットプロトコルアドレスが、インターフェイスのIPアドレスと一致しなければ、ARPモジュールは、そのARPパケットを破棄する。ターゲットプロトコルアドレスがインターフェイスのIPアドレスに一致し、また、ARPパケットがARP要求であれば、ARPモジュールは、ARP応答を生成する。ターゲットプロトコルアドレスがインターフェイスのIPアドレスに一致し、また、ARPパケットがRARP応答であれば、ARPモジュールは、割り当てられたIPアドレスを、RARPハンドラ・モジュールに渡す。 The first 32 bits of the fourth (last) 64-bit word of the ARP packet contains the target protocol address. Since the ARP packet must be 3.5 words or 28 bytes (224 bits) in length, only the first 32 bits of this fourth 64-bit word are valid. The ARP module stores the target protocol address in the target protocol address register. The ARP module compares the target protocol address with the IP address of the interface. If the target protocol address does not match the interface IP address, the ARP module discards the ARP packet. If the target protocol address matches the IP address of the interface and the ARP packet is an ARP request, the ARP module generates an ARP response. If the target protocol address matches the interface IP address and the ARP packet is a RARP response, the ARP module passes the assigned IP address to the RARP handler module.
ターゲットプロトコルアドレスが、インターネット・チューナ10GのインターフェイスのIPアドレスと一致すれば、ARPモジュールは、いずれもARPパケットから受け取られた送り手イーサネット・アドレスと送り手IPアドレスとを、ARPキャッシュモジュールに渡す。
If the target protocol address matches the IP address of the
このセクションは、ARPモジュールによるARPパケットの送信を扱う。ARPモジュールは、3つのソース；ARPキャッシュモジュール（ARP要求パケットおよびARPプロキシ応答のためのソース）、および、ARP応答FIFOを介してARPパーザから内部的に（ARP応答パケットのためのソース）、および、内部プロセッサから(カスタムARPパケットおよび全てのRARPパケットのためのソース)、からARPパケットを送信するための要求を受け取ることができる。ARPパケットおよびRARPパケットの複数のソースをハンドルするために、ARP送信スケジューラ1890は、ARPパケットおよびRARPパケットの送信をスケジュール化するために、送信優先順位キューを用いる。
This section deals with the transmission of ARP packets by the ARP module. The ARP module has three sources; the ARP cache module (source for ARP request packets and ARP proxy responses), and internally from the ARP parser (source for ARP response packets) via the ARP response FIFO, and From the internal processor (custom ARP packets and sources for all RARP packets), a request to send ARP packets can be received. In order to handle multiple sources of ARP packets and RARP packets, the
送信要求は、2つ以上のソースが送信を望むときを除いて、先着順にARP送信優先順位キューに置かれる。その場合（2つ以上のソースが送信を望むとき）には、ARP送信優先順位キューに置かれる次の送信要求は、送信要求の優先順位に依存する。RARP要求送信要求が、一般に最も高い優先順位を持ち、その後に、ARP要求送信要求が続く。ARP応答送信要求が、最も低い送信優先順位を持っている。 Requests for transmission are placed in the ARP transmission priority queue on a first-come, first-served basis, except when two or more sources wish to transmit. In that case (when more than one source wants to transmit), the next transmission request placed in the ARP transmission priority queue depends on the priority of the transmission request. RARP request transmission requests generally have the highest priority, followed by ARP request transmission requests. The ARP response transmission request has the lowest transmission priority.
ARP応答送信要求が最も高い送信優先順位を持つ1つの状況がある。これは、ARP応答FIFO 1892が一杯なときに起こる。ARP応答FIFOが一杯なとき、入ってくるARP要求送信要求が無視される。これが起こると、ARP応答送信要求は、ARP要求の再送信を余儀なくされることを回避するために、最も高い送信優先順位を与えられる。
There is one situation in which an ARP response transmission request has the highest transmission priority. This happens when the
ARP送信優先順位キューが一杯になると、ARP送信スケジューラ1890は、1つ以上の送信要求が完了するまで(そして、その送信要求がARP送信キューから取り除かれてしまうまで)、さらなる送信要求を受け入れない。ARPモジュールが、一杯になったARP送信キューを検出すると、ARPモジュールは、イーサネット送信スケジューラに、送信優先順位を増やすことを要求する。
When the ARP transmission priority queue is full, the
イーサネット送信スケジューラが、ARPモジュールが送信することを許可すると、ARPパケットあるいはRARPパケットが、送信されるARPパケットのタイプに依存して生成される。ARP OPフィールドが、ARPパケット・タイプを決定する。ARP OPフィールドは、ARP送信優先順位キューに、各送信要求とともに記憶される。 When the Ethernet transmission scheduler allows the ARP module to transmit, an ARP packet or RARP packet is generated depending on the type of ARP packet being transmitted. The ARP OP field determines the ARP packet type. The ARP OP field is stored with each transmission request in the ARP transmission priority queue.
このセクションは、入ってくるARPパケットの自動的な処理を回避する、ARPモジュールのARP回避モードの動作を扱う。ARPバイパスフラグがセットされ、そして、例外がイネーブルになると、入ってくるARPパケットおよびRARPパケットが、例外ハンドラバッファにコピーされる。次に、内部プロセッサが、例外ハンドラバッファにアクセスし、ARPパケットおよびRARPパケットを処理する。ARPバイパスモード中の場合、内部プロセッサは、ARP送信スケジューラに、ARP応答パケットを要求することができる。出て行くARPパケットおよびRARPパケットにカスタマイズできるフィールドは、送り手プロトコルアドレス、送信元ハードウェアアドレス、ターゲットプロトコルアドレス、および、ARP OPフィールドである。ARPパケットあるいはRARPパケットの他の全てのフィールドは、イーサネット上のIPv4におけるARPパケットおよびRARPパケットに使用される標準値にセットされる。送信元ハードウェアアドレスは、インターネット・チューナ10Gのインターフェイスのイーサネット・アドレスにセットされる。ARPパケットあるいはRARPパケットの他のフィールドを修正することが必要な場合には、内部プロセッサが、ローイーサネット・フレームを生成しなければならない。
This section deals with the behavior of the ARP module's ARP avoid mode, which avoids the automatic processing of incoming ARP packets. When the ARP bypass flag is set and the exception is enabled, incoming ARP and RARP packets are copied to the exception handler buffer. The internal processor then accesses the exception handler buffer and processes ARP and RARP packets. When in the ARP bypass mode, the internal processor can request an ARP response packet from the ARP transmission scheduler. The fields that can be customized for outgoing ARP packets and RARP packets are the sender protocol address, source hardware address, target protocol address, and ARP OP fields. All other fields of the ARP packet or RARP packet are set to the standard values used for ARP and RARP packets in IPv4 over Ethernet. The source hardware address is set to the Ethernet address of the
以下のセクションは、ARPキャッシュモジュールの動作について説明する。 The following sections describe the operation of the ARP cache module.
このセクションは、ARPキャッシュモジュール1750によるARPキャッシュへのARPキャッシュ・エントリの付加を扱う。ARPモジュール1762が、インターネット・チューナ10Gのイーサネット・インターフェイスに属するIPアドレスのうちの1つに対するARP要求あるいはARP応答を受け取ったとき、ARPキャッシュモジュールは、ARPキャッシュに動的なARPキャッシュ・エントリを作り出す。内部プロセッサが、ARPキャッシュモジュールがARPキャッシュ・エントリを作り出すことを要求したとき、静的なARPキャッシュ・エントリが、ARPキャッシュに作り出される。内部プロセッサは、また、動的なARPキャッシュ・エントリを作り出すこともできる。動的なARPキャッシュ・エントリがユーザによって指定された時間だけ存在してから、そのARPキャッシュ・エントリは満了し、また、ARPキャッシュモジュールが、そのキャッシュ・エントリを除去する。動的なARPキャッシュ・エントリの満了時間は、通常、5〜15分である。静的なARPキャッシュ・エントリは、一般に満了しない。ARPキャッシュに入力されることになる新しいARPデータは、2つの可能なソース：ARPレジスタを介しての内部プロセッサあるいはARPパケットパーザからARPキャッシュモジュールに渡される。両方の可能なソースが、ARPキャッシュモジュールに、ARPキャッシュ・エントリを加えることを同時に要求したときには、ARPパケットパーザからの動的なARPキャッシュ・エントリ要求の方が、優先順位を持っている。ARPパケットパーザからの動的なARPキャッシュ・エントリ要求は、入ってくるARPパケットをできるだけ速く処理することができるように、また、イーサネット・インターフェイスが動かなくなることを防ぐことができるように、優先順位を与えられる。
This section deals with the addition of ARP cache entries to the ARP cache by the
ARPキャッシュモジュールが、新しいARPキャッシュ・エントリのソースを選択すると、ARPキャッシュモジュールは、そのARPキャッシュ・エントリを、ARPモジュールメモリのどこに記憶するかを決定する。ARPキャッシュモジュールは、ARPルックアップテーブル(LUT)を用いて、ARPモジュールメモリ内の1つの位置に1つのIPアドレスをマップする。ARP LUTには、256個のARP LUTエントリが含まれる。各ARP LUTエントリは、広さ16ビットで、ARPコードによって割り付けられたm1メモリの位置に対するポインタ、および、ARPポインタ有効(PV)ビットを含んでいる。ARPキャッシュモジュールは、ARP PVビットを用いて、m1メモリ・ポインタが、ARPキャッシュによって割り付けられたm1メモリ内の有効なアドレスを指しているかどうかを決定する。m1アドレスは、それが、ARPキャッシュモジュールによって割り付けられたm1メモリのブロックの開始アドレスと等しければ、有効である。 When the ARP cache module selects a source for a new ARP cache entry, the ARP cache module determines where to store the ARP cache entry in ARP module memory. The ARP cache module maps one IP address to one location in the ARP module memory using an ARP lookup table (LUT). The ARP LUT includes 256 ARP LUT entries. Each ARP LUT entry is 16 bits wide and contains a pointer to the location of the m1 memory allocated by the ARP code, and an ARP pointer valid (PV) bit. The ARP cache module uses the ARP PV bit to determine if the m1 memory pointer points to a valid address in m1 memory allocated by the ARP cache. An m1 address is valid if it is equal to the starting address of the block of m1 memory allocated by the ARP cache module.
ARPキャッシュモジュールは、ARP LUT内の8ビットインデックスを用いて、ARP LUTからm1メモリ・ポインタを検索する。ARPキャッシュモジュールは、8ビットARP LUTインデックスとして、32ビットIPアドレスの最後の8個を用いる。32ビットIPアドレスの最後の8個を用いる理由は、ローカル・エリア・ネットワークにおいては、最後の8個が、ホスト間で最も大きく変化するIPアドレスの部分であるということである。 The ARP cache module uses the 8-bit index in the ARP LUT to retrieve the m1 memory pointer from the ARP LUT. The ARP cache module uses the last eight 32-bit IP addresses as the 8-bit ARP LUT index. The reason for using the last 8 32-bit IP addresses is that in a local area network, the last 8 are the part of the IP address that varies the most between hosts.
ARPキャッシュモジュールが、ARP LUT中のどのARP LUTエントリを用いるかを決定すると、ARPキャッシュモジュールは、そのARP LUTエントリが、有効なm1メモリ・ポインタを含有しているかどうかを確かめるためにチェックする。そのm1メモリ・ポインタが有効であると、ARPキャッシュモジュールは、そのm1メモリ・ポインタを用いて、ターゲットIPアドレスのためのARP情報を検索するためにm1メモリにアドレス指定する。ARP LUTエントリが、有効なm1メモリ・ポインタを含有していなければ、ARPキャッシュモジュールは、メモリ・アロケータ・モジュールを用いて、m1メモリ・ブロックを割り付ける。ARPキャッシュモジュールが、m1メモリ・ブロックを割り付けると、ARPキャッシュモジュールは、ARP LUTエントリのm1メモリ・ポインタ・フィールドに割り付けられたm1メモリ・ブロックの最初の128ビット・ワードのアドレスを記憶する。 When the ARP cache module determines which ARP LUT entry in the ARP LUT to use, the ARP cache module checks to see if the ARP LUT entry contains a valid m1 memory pointer. If the m1 memory pointer is valid, the ARP cache module uses the m1 memory pointer to address m1 memory to retrieve ARP information for the target IP address. If the ARP LUT entry does not contain a valid m1 memory pointer, the ARP cache module allocates an m1 memory block using the memory allocator module. When the ARP cache module allocates the m1 memory block, the ARP cache module stores the address of the first 128-bit word of the m1 memory block allocated in the m1 memory pointer field of the ARP LUT entry.
メモリ・アロケータ・モジュールを用いてm1メモリを割り付け、そして、ARP LUTにm1メモリ・ポインタを記憶した後、ARPキャッシュモジュールは、ARPキャッシュ内のARPデータをm1メモリに記憶する。m1メモリに記憶されたARPデータには、ARPモジュールが、ARPキャッシュルックアップ中に用いるのに必要である送り手IPアドレスが含まれている。ARPキャッシュモジュールは、ARPキャッシュ・エントリの一連のARP制御フィールドを用いる。ARPモジュールは、リトライ（再試行）カウンタARP制御フィールドを用いて、与えられたIPアドレスに対して遂行されるARP要求試みの回数を記録する。ARPモジュールは、エントリタイプ制御フィールドを用いて、ARPキャッシュ・エントリのタイプを指示する（000=動的なエントリ；001=静的なエントリ；010=プロキシエントリ；011=ARPチェックエントリ）。ARPモジュールは、解決フラグ制御フィールドを用いて、現在のARPキャッシュ・エントリのIPアドレスが、イーサネット・アドレスに成功のうちに解決されて（IPアドレスがイーサネット・アドレスに置き換えられて）しまっていることを指示する。ARPモジュールは、有効フラグ制御フィールドを用いて、このARPキャッシュ・エントリが有効なデータを含有することを指示する。一番最初のARP要求が遂行されている間は、ARPキャッシュ・エントリは、有効で、かつ、解決されていないことに注意されたい。ARPモジュールは、ソース制御フィールドを用いて、ARPキャッシュ・エントリのソースを指示する（00=動的に加えられた、01=システム・インターフェイス・モジュール、10=IPルータ・モジュール、11=システム・インターフェイス・モジュールとIPルータ・モジュールとの両方）。ARPキャッシュモジュールは、インターフェイス制御フィールドを用いて、インターネット・チューナ10Gに接続された複数のイーサネット・インターフェイスの使用を可能にする。ARP制御フィールドのセットに続いて、以後のARPキャッシュ・エントリのm1メモリ位置を指すARPキャッシュリンク・アドレスが存在する。ARPキャッシュリンク・アドレスの最上位ビットは、リンク有効フラグである。リンク有効フラグは、現在のARPキャッシュ・エントリに続いて、別のARPキャッシュ・エントリが存在することを指示する。ARPキャッシュ・エントリの最後の2つのフィールドは、IPアドレスが解決されてしまったイーサネット・アドレスおよびタイム・スタンプである。タイム・スタンプは、ARPキャッシュ・エントリがいつ作られたかを指示し、そのARPキャッシュ・エントリが満了したかどうかを決定するために用いられる。
After allocating m1 memory using the memory allocator module and storing the m1 memory pointer in the ARP LUT, the ARP cache module stores the ARP data in the ARP cache in the m1 memory. The ARP data stored in the m1 memory contains the sender IP address that the ARP module needs to use during the ARP cache lookup. The ARP cache module uses a series of ARP control fields in the ARP cache entry. The ARP module uses the retry counter ARP control field to record the number of ARP request attempts performed for a given IP address. The ARP module uses the entry type control field to indicate the type of ARP cache entry (000 = dynamic entry; 001 = static entry; 010 = proxy entry; 011 = ARP check entry). The ARP module uses the resolution flag control field to ensure that the current ARP cache entry's IP address has been successfully resolved to an Ethernet address (the IP address has been replaced with an Ethernet address). Instruct. The ARP module uses a valid flag control field to indicate that this ARP cache entry contains valid data. Note that the ARP cache entry is valid and unresolved while the very first ARP request is being fulfilled. The ARP module uses the source control field to indicate the source of the ARP cache entry (00 = dynamically added, 01 = system interface module, 10 = IP router module, 11 = system interface・ Both modules and IP router modules). The ARP cache module uses the interface control field to allow the use of multiple Ethernet interfaces connected to the
256以上のホストを備えた、あるいは、複数のサブネットを備えたネットワークでは、異なるIPアドレス間での衝突が、ARP LUTに起きることがある。2つ以上のIPアドレスが、同一のARP LUTインデックスにマップしていると、ARP LUT内での衝突が起きる。この衝突は、2つ以上のホストが、IPアドレスの最後の8個において同じ値を持っていることによる。衝突に対処するために、ARPキャッシュモジュールは、ARP LUT中でエントリをチェーン状につなぐ。 In networks with more than 256 hosts or multiple subnets, collisions between different IP addresses may occur in the ARP LUT. If two or more IP addresses map to the same ARP LUT index, a collision within the ARP LUT occurs. This collision is due to two or more hosts having the same value in the last eight IP addresses. To deal with collisions, the ARP cache module chains entries in the ARP LUT.
ARPキャッシュモジュールが、ARP LUTのルックアップを遂行し、そして、有効なARP LUTエントリが、そのスロットに既に存在することが見出されたときには、ARPキャッシュモジュールは、m1メモリによって指し示されているARPエントリを検索する。ARPキャッシュモジュールは、ARPキャッシュ・エントリに記憶されているIPアドレスを検査し、そして、それを、ターゲットIPアドレスと比較する。IPアドレスが一致すれば、ARPキャッシュモジュールは、単純にARPキャッシュ・エントリを更新することができる。しかしながら、アドレスが一致しなければ、ARPキャッシュモジュールは、ARPキャッシュ・エントリのリンク有効フラグおよびリンク・アドレスを検査する。ARPキャッシュ・エントリの最後の16ビットには、同一のLUTエントリにマップする別のARPエントリを指すARPキャッシュリンク・アドレスが含まれている。リンク有効フラグがセットされていると、ARPキャッシュモジュールは、ARPキャッシュリンク・アドレスが指しているARPキャッシュ・エントリを検索する。この第2のARPキャッシュ・エントリのIPアドレスが、ターゲットIPアドレスと比較される。一致すれば、ARPキャッシュモジュールは、ARPキャッシュ・エントリを更新する。そうでない場合には、一致が見出されるか、あるいは、ARPキャッシュモジュールが、リンク有効フラグのセットされていないARPキャッシュ・エントリに到達するまで、ARPキャッシュルックアップ処理が、継続する(ARPキャッシュ・エントリのチェーンのリンクをたどって)。 When the ARP cache module performs an ARP LUT lookup and a valid ARP LUT entry is found to already exist in that slot, the ARP cache module is pointed to by m1 memory Search for ARP entries. The ARP cache module examines the IP address stored in the ARP cache entry and compares it with the target IP address. If the IP addresses match, the ARP cache module can simply update the ARP cache entry. However, if the addresses do not match, the ARP cache module checks the link valid flag and link address of the ARP cache entry. The last 16 bits of the ARP cache entry contain an ARP cache link address that points to another ARP entry that maps to the same LUT entry. If the link valid flag is set, the ARP cache module searches the ARP cache entry pointed to by the ARP cache link address. The IP address of this second ARP cache entry is compared with the target IP address. If there is a match, the ARP cache module updates the ARP cache entry. Otherwise, the ARP cache lookup process continues until a match is found or the ARP cache module reaches an ARP cache entry that does not have the link valid flag set (ARP cache entry Follow the chain link).
ARPキャッシュモジュールが、一連のARPキャッシュ・エントリの端に到達し、そして、一致が見つからなかった場合には、ARPキャッシュモジュールが、新しいARPキャッシュ・エントリを作り出す。新しいARPキャッシュ・エントリを作り出すために、メモリ・コントローラ・モジュールに、m1メモリの割り付けを要求できる。m1メモリの各ブロックは、サイズが128バイトである。m1メモリの各ブロックは、8つのARPキャッシュ・エントリを収容することができる。ARPキャッシュモジュールが、m1メモリ・ブロックを、ARPキャッシュ・エントリで満たしてしまうと、ARPキャッシュモジュールは、メモリ・コントローラ・モジュールに、新しいメモリ・ブロックを要求する。 If the ARP cache module reaches the end of a series of ARP cache entries and no match is found, the ARP cache module creates a new ARP cache entry. To create a new ARP cache entry, the memory controller module can be requested to allocate m1 memory. Each block of m1 memory is 128 bytes in size. Each block of m1 memory can accommodate 8 ARP cache entries. When the ARP cache module fills the m1 memory block with an ARP cache entry, the ARP cache module requests a new memory block from the memory controller module.
ユーザは、静的なARPキャッシュ・エントリを作り出すことができる。静的なARPキャッシュ・エントリは、一般に永続し、満了しない。ユーザは、動的なARPデータが、静的なARPキャッシュ・エントリと置き換わることを可能にするオプションを持っている。言い換えれば、ARPデータが、既に静的なARPキャッシュ・エントリを持っているIPアドレスに対して受信されたときには、その静的なARPキャッシュ・エントリを、受信された動的なARPキャッシュデータで置き換えることができる。この静的なARPキャッシュ・エントリの置き換えの利益は、これが、静的なARPキャッシュ・エントリが陳腐になるのを防ぐことができるということである。ARPキャッシュ・エントリ置き換えは、動的なARPキャッシュデータを、静的なARPキャッシュデータに重ね書きすることを可能にし、それによって、より最新のARPキャッシュに帰着する。ユーザが、IPアドレスのイーサネット・アドレスへのマッピングが不断に繰り返されていると確信している場合（例えば、IPアドレスとルータインターフェイスのイーサネット・アドレスとを記憶している場合)には、このARPキャッシュ・エントリ置き換え能力は、デセーブルにすることもできる。ユーザは、ネットワーク上のARPブロードキャストの数を最小限にするために、静的なARPキャッシュ・エントリを保存することを選ぶこともできる。注：ARPキャッシュプロキシエントリが、動的なARPキャッシュ・エントリによって重ね書きされることは決してない。 Users can create static ARP cache entries. Static ARP cache entries are generally permanent and do not expire. The user has an option that allows dynamic ARP data to replace static ARP cache entries. In other words, when ARP data is received for an IP address that already has a static ARP cache entry, the static ARP cache entry is replaced with the received dynamic ARP cache data. be able to. The benefit of this static ARP cache entry replacement is that it can prevent static ARP cache entries from becoming obsolete. ARP cache entry replacement allows dynamic ARP cache data to be overwritten with static ARP cache data, thereby resulting in a more up-to-date ARP cache. If the user is convinced that the mapping of an IP address to an Ethernet address is continually repeated (for example, remembering the IP address and the Ethernet address of the router interface), this ARP The cache entry replacement capability can also be disabled. The user can also choose to save static ARP cache entries to minimize the number of ARP broadcasts on the network. Note: ARP cache proxy entries are never overwritten by dynamic ARP cache entries.
このセクションは、ARPキャッシュにおけるARPキャッシュ・エントリのルックアップを扱う。ARPキャッシュにおけるARPキャッシュ・エントリのルックアップは、ARPエントリの創出に対するそれと同様の処理に従う。図19に関して、ARPキャッシュルックアップは、ARP LUT 1920をチェックして、m1メモリが、与えられたARP LUTエントリに対して割り付けられているかどうかを決定することによって始まる。その通りであれば、ARPキャッシュ・エントリが見つかる（その場合には、ARPキャッシュヒットがある）か、あるいは、アサートされていないリンク有効フラグを持つARPキャッシュ・エントリが見つかる（その場合には、ARPキャッシュミスがある）まで、そのARP LUTエントリに連係したm1メモリが、探索される 1922。
This section deals with ARP cache entry lookup in the ARP cache. Lookup of ARP cache entries in the ARP cache follows a process similar to that for creation of ARP entries. With reference to FIG. 19, the ARP cache lookup begins by checking the
ARPキャッシュミスが起こった場合には、ARPキャッシュモジュールは、ARP要求を生成する 1934。ARP要求には、ARPキャッシュによって割り付けられるm1メモリ内への新しいARPエントリの創出、および、必要であれば、新しいARPLUTエントリの創出が含まれる。ターゲットIPアドレスが、新しいARPキャッシュ・エントリに記憶され、新しいARPキャッシュ・エントリの解決ビットは、0にセットされ、そして、新しいARPキャッシュ・エントリの有効ビットは、1にセットされる。新しいARPエントリの要求カウンタも、0にセットされる。次に、ARPキャッシュ・エントリが、タイム・スタンプされ、また、ARP要求が、ARPモジュールに渡される。ARP応答が、1秒の間隔の後にARPモジュールから受信されない場合には、ARPキャッシュ・エントリの要求カウンタが、インクリメントされて、別のARP要求が送信される。3度のARP要求が、ARP応答なく送信されたら、ターゲットIPアドレスを解決する試みは、中断される。注：ユーザは、ARP再試行間隔およびARP要求再試行の最大数を指定することができる。
If an ARP cache miss occurs, the ARP cache module generates an
ARPキャッシュルックアップを要求しているモジュールは、ARPキャッシュミスが起こったとき、ARPキャッシュミスの通知を受ける。このARPキャッシュミスの通知は、内部プロセッサあるいはIPルータ・モジュールに、現在のターゲットIPアドレスに対するARP返答を待つことを決めるか、または、別のIPアドレスのための新しいARPキャッシュルックアップを始めて、現在のIPアドレスを送信優先順位キューの奥（最後）に置くかする機会を与える。この処理は、複数の接続を確立するときに、ARPキャッシュミスの衝撃を最小限にするのに役立つ。 The module requesting the ARP cache lookup is notified of an ARP cache miss when an ARP cache miss occurs. This ARP cache miss notification either determines to wait for the internal processor or IP router module to wait for an ARP reply for the current target IP address, or initiates a new ARP cache lookup for another IP address. Give the opportunity to put the IP address of the back of the sending priority queue. This process helps to minimize the impact of ARP cache misses when establishing multiple connections.
一致するARPキャッシュ・エントリが、ARPキャッシュに見出されると、解決されたイーサネット・アドレスが、ARPキャッシュルックアップを要求したモジュールに返される。そうではなくて、ターゲットIPアドレスが、ARPキャッシュに見出されず、そして、全てのARP要求試行が、時間切れになった場合には、ARPキャッシュルックアップを要求したモジュールは、ターゲットIPアドレスが解決できなかったことを通知される。 If a matching ARP cache entry is found in the ARP cache, the resolved Ethernet address is returned to the module that requested the ARP cache lookup. Otherwise, if the target IP address is not found in the ARP cache, and all ARP request attempts time out, the module that requested the ARP cache lookup can resolve the target IP address. Notified that there was no.
注：IPルータ・モジュールからのARPキャッシュルックアップ要求が、イーサネット・アドレスに解決できなかった場合には、IPルータ・モジュールは、そのターゲットIPアドレスのための別のARPキャッシュルックアップを始める前に、最小20秒間待たなければならない。 Note: If an ARP cache lookup request from an IP router module could not be resolved to an Ethernet address, the IP router module must begin another ARP cache lookup for that target IP address. Must wait for a minimum of 20 seconds.
このセクションは、ARPキャッシュ・エントリの満了を扱う。動的なARPキャッシュ・エントリは、限定された時間量においてしか、ARPキャッシュに存在できない。これは、IPアドレスのイーサネット・アドレスへのマッピングが陳腐になる（古臭くなる、としても知られている）のを防ぐためである。例えば、ネットワークが、複数のホスト間で一溜まりのIPアドレスを共有するためにDHCPを用いている場合、あるいは、デバイスのイーサネット・インターフェイスが、接続の間に変更される場合に、陳腐なアドレスマッピングが起こり得る。 This section deals with the expiration of ARP cache entries. Dynamic ARP cache entries can only exist in the ARP cache for a limited amount of time. This is to prevent the mapping of IP addresses to Ethernet addresses from becoming stale (also known as obsolete). For example, if the network uses DHCP to share a bunch of IP addresses between multiple hosts, or if the device's Ethernet interface changes between connections, it will become stale address mapping Can happen.
キャッシュ・エントリの創出からの経過時間を記録するために、ARPキャッシュモジュールは、ARPキャッシュ満了タイマとして、16ビットARPキャッシュモジュールカウンタを用いる。ARPキャッシュ満了タイマは、2ヘルツの周波数で動作し、ARPキャッシュモジュールが創出してから経過した秒数を追跡するために用いられる。各ARPキャッシュ・エントリは、ARPキャッシュ満了タイマによって用いられる16ビットARPキャッシュモジュールカウンタから受け取られる16ビットARPキャッシュモジュールタイム・スタンプを含んでいる。この16ビットARPキャッシュモジュールタイム・スタンプは、IPアドレスが成功のうちに解決された時刻を示している。 In order to record the elapsed time since the creation of the cache entry, the ARP cache module uses a 16-bit ARP cache module counter as the ARP cache expiration timer. The ARP cache expiration timer runs at a frequency of 2 Hertz and is used to track the number of seconds that have elapsed since the ARP cache module was created. Each ARP cache entry includes a 16-bit ARP cache module time stamp received from a 16-bit ARP cache module counter used by the ARP cache expiration timer. This 16-bit ARP cache module time stamp indicates the time when the IP address was resolved successfully.
ARPキャッシュ・エントリは、ARPキャッシュモジュールがアイドル状態の間に、満了することができる。ARPキャッシュモジュールは、ARPキャッシュモジュールによって現在処理されているARP要求またはARPキャッシュルックアップが全く存在しないときには、アイドル状態にある。ARPキャッシュモジュールがアイドル状態にある間、8ビットARPキャッシュモジュールカウンタが、ARP LUTの間をサイクル動作して、それを探索するために用いられる。ARP LUTの各エントリが、有効なm1メモリ・ポインタを含んでいるかどうかを確かめるためにチェックされる。m1メモリ・ポインタが有効であれば、対応するm1メモリ位置が、m1モジュールメモリ・ポインタを用いて検索される。次に、そのm1メモリ位置のARPキャッシュ・エントリは、ARPキャッシュ満了タイマから受け取られた、そのARPキャッシュ・エントリのタイム・スタンプと現在の時刻との間の差が、ARPキャッシュ・エントリの最大寿命以上であるかどうかを確かめるためにチェックされる。ARP LUTエントリに連係する第1のARPキャッシュ・エントリが、静的なARPキャッシュ・エントリであり、また、他のm1メモリ位置が、第1のm1メモリ位置と遮断されている場合には、それらのm1メモリ・ブロックに含まれるARPキャッシュ・エントリも、チェックされる。動的なARPキャッシュ・エントリが見出されるか、あるいは、与えられたARP LUTエントリに連係する全てのARPキャッシュ・エントリがチェックされれば、続いて、次のARP LUTエントリがチェックされる。 The ARP cache entry can expire while the ARP cache module is idle. The ARP cache module is idle when there is no ARP request or ARP cache lookup currently being processed by the ARP cache module. While the ARP cache module is idle, an 8-bit ARP cache module counter is used to cycle through and search for ARP LUTs. Each entry in the ARP LUT is checked to see if it contains a valid m1 memory pointer. If the m1 memory pointer is valid, the corresponding m1 memory location is retrieved using the m1 module memory pointer. The ARP cache entry for that m1 memory location is then the difference between the time stamp of the ARP cache entry received from the ARP cache expiration timer and the current time, which is the maximum lifetime of the ARP cache entry. Checked to see if this is the case. If the first ARP cache entry associated with the ARP LUT entry is a static ARP cache entry and other m1 memory locations are blocked from the first m1 memory location, they ARP cache entries contained in the m1 memory block are also checked. If a dynamic ARP cache entry is found or all ARP cache entries associated with a given ARP LUT entry are checked, then the next ARP LUT entry is checked.
ARPキャッシュ・エントリが満了したことが見出されると、そのARPキャッシュ・エントリの有効ビットが、0にセットされる。同一のm1メモリ・ブロック内に他の有効なARPキャッシュ・エントリが全く存在しなければ、そのm1メモリ・ブロックは、割り付けを解放され、メモリ・コントローラ・モジュールに返される。割り付けを解放されているm1メモリ・ブロックが、与えられたARP LUTエントリに連係するただ一つのARPモジュールメモリ・ブロックである場合には、そのARP LUTエントリのPVビットも0にセットされ、それによって、そのポインタが無効になる。 If the ARP cache entry is found to have expired, the valid bit for that ARP cache entry is set to zero. If no other valid ARP cache entry exists in the same m1 memory block, the m1 memory block is deallocated and returned to the memory controller module. If the m1 memory block being deallocated is the only ARP module memory block associated with a given ARP LUT entry, the PV bit of that ARP LUT entry is also set to 0, thereby The pointer becomes invalid.
このセクションは、ARP プロキシィングを遂行するARPキャッシュを扱う。そのARPキャッシュは、ARPプロキシキャッシュ・エントリをサポートしている。ARP プロキシィングは、インターネット・チューナ10Gがルータとして働くか、あるいは、ARP照会に応えることができないネットワーク上のデバイスがあるときに、用いられる。
This section deals with the ARP cache that performs ARP proxying. The ARP cache supports ARP proxy cache entries. ARP proxying is used when the
ARPプロキシィングがイネーブルのとき、ARPモジュールは、ARPキャッシュモジュールに、インターネット・チューナ10Gのハードウェア・インターフェイスに属さないIPアドレスに対するARP要求を渡す。そうすると、ARPキャッシュモジュールは、ターゲットIPアドレスを探索するためにARPプロキシキャッシュ・エントリルックアップを遂行する。ARPキャッシュモジュールが、一致するIPアドレスを備えたARPキャッシュ・エントリを見出すと、ARPキャッシュモジュールは、そのARPキャッシュ・エントリのタイプ・フィールドをチェックして、そのARPキャッシュ・エントリが、ARPプロキシキャッシュ・エントリであるかどうかを決定する。そのARPキャッシュ・エントリが、ARPキャッシュプロキシエントリであれば、ARPキャッシュモジュールは、ARPモジュールに、そのARPプロキシキャッシュ・エントリからの対応するイーサネット・アドレスを渡し返す。次に、ARPモジュールは、送信元イーサネット・アドレスとしてARPプロキシキャッシュ・エントリに見出されたイーサネット・アドレスを用いて、ARP応答を生成する。ARPプロキシルックアップは、ARPモジュールによって受信されたARP要求に対してしか起こらない。
When ARP proxying is enabled, the ARP module passes an ARP request for an IP address that does not belong to the hardware interface of the
このセクションは、ARPキャッシュモジュールアクセス優先順位を扱う。相異なるARPタスクが、ARPキャッシュモジュールメモリへのアクセスに関して、相異なる優先順位を持つ。入ってくるARPパケットは、非常に高レートで受信されることもあり、再送信を回避するために、できるだけ速く処理されなければならない。ARPキャッシュプロキシエントリルックアップは、最高の優先順位を持っている。ARPモジュールからのデータを用いるARPキャッシュへの動的なARPキャッシュ・エントリの付加は、2番目の優先順位にある。IPルータ・モジュールからのARPキャッシュルックアップは、3番目の優先順位にある。内部プロセッサからのARPキャッシュルックアップは、4番目の優先順位にある。ARPキャッシュ・エントリの手動創出は、5番目の優先順位にある。ARPキャッシュ・エントリの満了は、最低の優先順位にある。 This section deals with ARP cache module access priority. Different ARP tasks have different priorities for accessing the ARP cache module memory. Incoming ARP packets may be received at a very high rate and must be processed as fast as possible to avoid retransmission. ARP cache proxy entry lookup has the highest priority. The addition of dynamic ARP cache entries to the ARP cache using data from the ARP module is of second priority. ARP cache lookup from the IP router module is the third priority. ARP cache lookups from internal processors are at the fourth priority. Manual creation of ARP cache entries is the fifth priority. The expiration of the ARP cache entry is at the lowest priority.
以下のセクションは、IPモジュール1758を扱う。IPモジュールは、イーサネットモジュール1766、TCPモジュール1752、メモリ・アロケータ・モジュール、例外ハンドラ1768、および、内部プロセッサとインターフェイスで接続している。
The following section deals with
以下のセクションは、IPモジュールを有するモジュールについて記述する。 The following sections describe modules with IP modules.
図20に関して、このセクションは、IPヘッダ・フィールド構文解析モジュール2062を扱う。IPヘッダの以下のフィールドは、IPヘッダ・フィールド構文解析モジュールによって構文解析される。
With respect to FIG. 20, this section deals with the IP header
プロトコル・バージョン・フィールドIPヘッダ・フィールド構文解析モジュールは、IPv4とIPv6とのどちらの IPパケットも検出する。プロトコル・バージョン・フィールドは、プロトコル・バージョンを決めるために用いられる。0x4または0x6のプロトコル・バージョン・フィールドを備えたIPパケットしか、デコードされない。サポートされていないIPバージョン・フィーチャがイネーブルであると、受信された他の全てのプロトコル・バージョンが、ホスト・システムに送られる。サポートされていないIPバージョン・フィーチャがイネーブルでないと、そのIPパケットは、黙って捨てられる。 Protocol version field IP header field parsing module detects both IPv4 and IPv6 IP packets. The protocol version field is used to determine the protocol version. Only IP packets with a protocol version field of 0x4 or 0x6 are decoded. If the unsupported IP version feature is enabled, all other received protocol versions are sent to the host system. If an unsupported IP version feature is not enabled, the IP packet is silently discarded.
タイプ・オブ・サービス(ToS)フィールドは、構文解析されずに、受信されるIPパケットのために、使わないでおかれる。 The type of service (ToS) field is left unparsed and not used for received IP packets.
IPパケット全長フィールド−IPヘッダ・フィールド構文解析モジュールは、受信されたIPパケット内のバイトの全数を決定するために、IPパケット全長フィールドを用いる。そうすると、IPヘッダ・フィールド構文解析モジュールは、以後のプロトコル・プロセッサ・モジュールに、IPパケットのデータ・セクションの端部の位置を指示することができる。指示されたバイト数を超えるIPパケット内のデータで、IPパケット信号がディアサートする（非アクティブになる）前に受信されたIPパケット内のデータは全て、パディング・バイトとみなされる。IPパケット内のパディング・バイトは、黙って破棄される。 IP packet length field—The IP header field parsing module uses the IP packet length field to determine the total number of bytes in the received IP packet. The IP header field parsing module can then instruct the subsequent protocol processor module to locate the end of the data section of the IP packet. Any data in the IP packet that is received before the IP packet signal deasserts (deactivates) with data in the IP packet that exceeds the indicated number of bytes is considered a padding byte. Padding bytes in IP packets are silently discarded.
識別フィールド、フラグフィールド、および、分割オフセット・フィールド・インターネット・チューナ10Gは、IPパケットを再構築するために、これらのフィールドを用いる。IP分割についてのセクションは、これらのフィールドがどのように用いられるかを記述する。
The identification field, flag field, and split offset
TTL（タイム・ツー・ライブ）フィールド−タイム・ツー・ライブ・フィールドは、構文解析されず、受信されるIPパケットのために、使わないでおかれる。 TTL (Time to Live) field-The Time to Live field is not parsed and is not used for received IP packets.
プロトコル・フィールドIPヘッダ・フィールド構文解析モジュールが、IPパケットにカプセル化されているプロトコルを決定するためにプロトコル・フィールドを用いる。表1は、インターネット・チューナ10Gにサポートされているプロトコル・フィールド値を示す。
サポートされているプロトコル・フィールドデコード
Protocol field The IP header field parsing module uses the protocol field to determine the protocol encapsulated in the IP packet. Table 1 shows the protocol field values supported by the
Supported protocol field decoding
IPパケットが、サポートされていないプロトコル・フィールド値を持って受信されたとき、そして、そのサポートされていないプロトコル・フィーチャがイネーブルであるとき、IPモジュールは、そのIPパケットを、ホスト・システムに渡す。サポートされていないプロトコル・フィーチャがイネーブルでないとき、IPモジュールは、そのIPパケットを、黙って破棄する。 When an IP packet is received with an unsupported protocol field value, and when the unsupported protocol feature is enabled, the IP module passes the IP packet to the host system . When an unsupported protocol feature is not enabled, the IP module silently discards the IP packet.
ヘッダ・チェックサム・フィールドIPヘッダ・フィールド構文解析モジュールは、IPヘッダ・チェックサム・フィールドを、黙って破棄して解析しないか、そうでなければ、使わないでおく。IPモジュールは、IPヘッダ・チェックサム・フィールドを用いて、IPヘッダ・チェックサムが正しいことを確かめる。IPチェックサムが正しくなければ、IPモジュールは、以後の全てのプロトコル処理モジュールに届く不良チェックサム信号をアサートする。IPモジュールは、不良チェックサム信号が確認応答されるまで、不良チェックサム信号をアサートし続ける。 Header Checksum Field The IP header field parsing module silently discards and does not parse the IP header checksum field or otherwise leave it unused. The IP module uses the IP header checksum field to verify that the IP header checksum is correct. If the IP checksum is not correct, the IP module asserts a bad checksum signal that reaches all subsequent protocol processing modules. The IP module continues to assert the bad checksum signal until the bad checksum signal is acknowledged.
送信元IPアドレス・フィールドIPヘッダ・フィールド構文解析モジュールは、送信元IPアドレスを構文解析して、それを以後のTCPプロトコル処理モジュールおよびUDPプロトコル処理モジュールに送る。ICMPエコー要求パケットが受信された場合には、送信元IPアドレス・フィールドは、ICMPエコー応答パケットの送信に先立って、送信先IPアドレス・フィールドと交換される。 Source IP address field IP header field parsing module parses the source IP address and sends it to the subsequent TCP and UDP protocol processing modules. When an ICMP echo request packet is received, the source IP address field is exchanged with the destination IP address field prior to the transmission of the ICMP echo response packet.
送信先IPアドレス・フィールドIPヘッダ・フィールド構文解析モジュールは、送信先IPアドレス・フィールドを構文解析して、それを、インターネット・チューナ10Gネットワーク・スタックが応えるべき有効IPアドレスのリストと比較する。このIPアドレス比較は、2クロック周期以上取ってもよいが、受信されたIPパケットの構文解析は、継続する。その後、IPアドレス比較の結果、受信されたIPパケットが、誤った宛名を書かれているということが判明した場合には、IPモジュールは、不良IPアドレス信号をアサートする。IPモジュールは、不良IPアドレス信号が確認応答されるまで、不良IPアドレス信号をアサートし続ける。
Destination IP address field The IP header field parsing module parses the destination IP address field and compares it to a list of valid IP addresses to be served by the
IPオプション・フィールド・セーブ・オプション・フィーチャがイネーブルであると、IPモジュールは、IPオプション・フィールドをホスト・システムに渡す。セーブ・オプション・フィーチャがイネーブルであると、IPモジュールは、また、受信されたIPパケット・ヘッダも、ホスト・システムに渡す。セーブ・オプション・フィーチャがイネーブルでなければ、受信されたIPパケットのオプション・フィールドは、黙って破棄される。 If the IP option field save option feature is enabled, the IP module passes the IP option field to the host system. If the save option feature is enabled, the IP module also passes the received IP packet header to the host system. If the save option feature is not enabled, the option field of the received IP packet is silently discarded.
このセクションは、ローIP受信モジュール2066を扱う。ローIP受信モジュールは、内部プロセッサ1688が、インターネット・チューナ10Gネットワーク・スタック1610に、任意のIPパケットを送ることをイネーブルにする。ローIP受信モジュールは、診断の目的のために用いてもよいし、あるいは、例えば、内部プロセッサが、IPパケットデフラグやIPsec解読のような機能を遂行することを可能にするために用いてもよい。ローIP受信モジュール・フィーチャを用いるために、内部プロセッサは、最初に、メモリ・バッファにIPパケット・データを書き込む。次に、内部プロセッサは、ロー受信アドレス・レジスタに、このメモリ・バッファの開始アドレスを書き込む。次いで、内部プロセッサは、ロー受信コマンドレジスタの受信ビットをアサートし、それによって、IPパケット・データの転送が起きる。IPパケット・データの転送が完了すると、IPステータスレジスタにロー受信ビットが、セットされる。IP割り込みイネーブル・レジスタの一部であるロー受信割り込みイネーブル・ビットがセットされると、ローIP受信モジュールが、内部プロセッサに割り込みを渡す。次に、ローIP受信モジュールが、ロー受信割り込みイネーブル・ビットに1を書き込むことによって、その受信ステータス・ビットをクリアする。
This section covers the raw
このセクションは、ICMPエコー応答生成2060を扱う。ICMPエコー応答モジュールが、ICMPエコー応答パケットの生成をハンドルする。ICMPエコー応答モジュールは、全ての受信されるICMPパケットをハンドルする。ICMPエコー応答モジュールは、最初に、ICMPパケットの8ビットICMPタイプ・フィールドおよび8ビットICMPコード・フィールドを構文解析して、受信されたICMPパケットのメッセージタイプを決定する。受信されたICMPパケットのICMPメッセージタイプがエコー要求であれば、ユーザは、ホスト・システムを通じて、ICMPエコー応答モジュールが、エコー応答で、これらのエコー要求に自動的に応えるようにプログラムすることができる。この自動ICMPエコー応答フィーチャがイネーブルであると、受信されたICMPパケットのデータ・セクションが、メモリ・バッファに記憶される。ICMPエコー応答モジュールは、受信されたICMPパケット全体を確認する。受信されたICMPパケットが誤りのないものであれば、ICMPエコー応答モジュールは、メモリ・バッファに記憶されている受信されたICMPパケットのデータ・セクションに、イーサネット・ヘッダ、IPヘッダ、および、ICMPヘッダを加える。ICMPエコー応答モジュールは、メモリ・バッファに記憶されているICMPパケットのタイプ・フィールドを、0x00に変更する。次に、ICMPエコー応答モジュールは、1の補数演算を用いて、0x08を加えることによりICMPチェックサム・フィールドを修正する。次いで、ICMPエコー応答モジュールは、メモリ・バッファに記憶されているICMPパケットのIPヘッダの送信元IPアドレス・フィールドと送信先IPアドレス・フィールドとを交換する。ICMPエコー応答モジュールは、また、メモリ・バッファに記憶されているICMPパケットのイーサネット・ヘッダの送信元イーサネット・アドレス・フィールドと送信先イーサネット・アドレス・フィールドとを交換する。新しいIPヘッダおよびイーサネット・ヘッダが生成されると、ICMPエコー応答モジュールは、ICMPエコー応答パケットを送信するために、送信アービトレータに対して送信要求をアサートする。
This section deals with ICMP
受信されたICMPパケットのメッセージタイプは、エコー要求でないこともある。受信されたICMPパケットのメッセージタイプがエコー要求でなければ、そのパケットは、例外ICMPパケットである。ユーザは、ホスト・システムを通じて、ICMPエコー応答モジュールが、次の2つの方法のうちの1つで例外ICMPパケットを処理するようにプログラムすることができる。ICMPエコー応答モジュールは、例外ICMPパケットを内部プロセッサに渡してもよく、あるいは、ICMPエコー応答モジュールは、例外ICMPパケットを黙って破棄してもよい。ICMP例外パケットが内部プロセッサに渡されることになる場合には、ICMPエコー応答モジュールは、IPヘッダを含む、受信されたICMPパケット全体を内部プロセッサに渡す。ICMP例外パケットは、IP例外ハンドラ・モジュールを介して内部プロセッサに送られる。 The message type of the received ICMP packet may not be an echo request. If the message type of the received ICMP packet is not an echo request, the packet is an exception ICMP packet. The user can program the ICMP echo reply module through the host system to process exception ICMP packets in one of two ways: The ICMP echo reply module may pass the exception ICMP packet to the internal processor, or the ICMP echo reply module may silently discard the exception ICMP packet. When the ICMP exception packet is to be passed to the internal processor, the ICMP echo reply module passes the entire received ICMP packet including the IP header to the internal processor. ICMP exception packets are sent to the internal processor via the IP exception handler module.
図21および22に関して、ICMPエコー応答モジュール2060は、ICMPエコー応答受信モジュール2180、および、ICMPエコー応答プロセッサ・モジュール2182から成っている。ICMPエコー応答受信モジュールは、ICMPパケットを受信し、ICMPパケットのコンテンツをm1メモリに記憶する。ICMPエコー応答受信モジュールは、受信されたICMPパケットが、誤りのないものであることを確認する2206。受信されたICMPパケットが、誤りのないものであれば、ICMPエコー応答受信モジュールは、受信されたICMPパケットからのIPヘッダ情報を、受信されたICMPパケット2202を含んでいるm1メモリ・ブロック2200のアドレスとともに、ICMPエコー応答プロセッサ・モジュール2182に渡す。
With reference to FIGS. 21 and 22, the ICMP
図23を参照すると、ICMPエコー応答プロセッサ・モジュールは、エコー応答パケット2322に対するイーサネット・ヘッダおよびIPヘッダを生成する。次に、ICMPエコー応答プロセッサ・モジュールは、アドレスがICMPエコー応答受信モジュールから受け取られたm1バッファブロックに、ICMPエコー応答パケットをアセンブルする。ICMPエコー応答プロセッサ・モジュールは、受信されたICMPエコー要求のICMPチェックサムに0x08を加えることによって、ICMPチェックサムを生成する 2326。ICMPチェックサムに影響するエコー要求とエコー応答との間の唯一の相違は、ICMPコード・フィールドの相違（それは、0x08から0x00に変わる）だけであるので、この付加は、エコー応答に対する正しいICMPチェックサムを作り出す。
Referring to FIG. 23, the ICMP echo reply processor module generates an Ethernet header and an IP header for the
ICMPエコー応答プロセッサ・モジュールは、m1メモリ2322に、ICMPエコー応答パケットをアセンブルする。ICMPエコー応答パケットのアセンブリが完了すると、ICMPエコー応答プロセッサ・モジュールは、ICMPエコー応答パケット送信キュー2324に、ICMPエコー応答パケットの開始アドレスを置く。ICMPエコー応答パケット送信キューは、8つのエントリのための空きを持っている。ICMPエコー応答パケット送信キューが一杯になると、そのあと受信されるどのICMPパケットも、破棄される。ICMPエコー応答パケットが送信の準備を整えると、ICMPエコー応答プロセッサ・モジュールが、イーサネット送信器モジュール1766に合図を送る。その後、ICMPエコー応答パケットが、成功のうちに送信されると、イーサネット送信器モジュールは、ICMPエコー応答プロセッサ・モジュールに合図を送り返す。次に、ICMPエコー応答プロセッサ・モジュールが、ICMPエコー応答パケットを含有しているm1メモリ・ブロックを解放する 2328。ICMPエコー応答プロセッサは、複数のm1ブロックにまたがる大きなICMPエコー応答パケットをサポートする。
The ICMP echo reply processor module assembles an ICMP echo reply packet in the
ICMPエコー応答受信モジュールは、ICMPエコー要求パケットの受信の間にエラーを検出することができる（エラーには、不良チェックサム、無効IPアドレスなどを含むことができる）。ICMPエコー応答受信モジュールがエラーを検出すると、それは、現在書き込まれているm1メモリ・ブロック（および、同じICMPエコー要求パケットに用いられた全ての以前のm1メモリ・ブロック）を解放する。ICMPエコー応答プロセッサ・モジュールは、ICMPエコー応答受信モジュールとICMPエコー応答プロセッサ・モジュールとの間で渡されるパケット中断信号によって、このエラー状態をハンドルする。 The ICMP echo reply receiving module can detect errors during the reception of ICMP echo request packets (errors can include bad checksums, invalid IP addresses, etc.). When the ICMP echo reply receiving module detects an error, it releases the currently written m1 memory block (and all previous m1 memory blocks used for the same ICMP echo request packet). The ICMP echo reply processor module handles this error condition by a packet break signal passed between the ICMP echo reply receiver module and the ICMP echo reply processor module.
このセクションは、IP分割を扱う。インターネット・チューナ10Gは、IP分割を、直接ハードウェアにおいてハンドルすることもできるし、あるいは、内部プロセッサを用いてハンドルすることもでき、IPパケットを再構築して、次に、その再構築されたIP データグラムを、インターネット・チューナ10Gネットワーク・スタックに注入し返す。インターネット・チューナ10Gは、識別フィールド、送信元フィールド、送信先フィールド、および、プロトコル・フィールドにおいて同一の値を持つフラグメント（断片）を組み合わせることによって、IPデータグラムのフラグメントをアセンブルする。インターネット・チューナ10Gは、各フラグメントの各データ・セクションを、そのフラグメントのIPヘッダの分割オフセットによって指示される相対位置に置く。最初のフラグメントは、0にセットされた分割オフセットを持ち、また、最後のフラグメントは、0にセットされたmore-fragmentフラグを持つ。
This section deals with IP partitioning. The
このセクションは、分割されたIPパケットを、ハードウェアで直接的にハンドルするIP分割モジュール2064を扱う。図24に関して、IPパケットが、分割されたIPデータグラムに属するときには、そのIPパケットは、IPパケット・ヘッダにセットされたフラグメントフラグを持つ。そのとき、IP分割モジュールは、次のステップを実行する。
This section deals with the
・IP分割モジュールは、IPパケット・ヘッダの16ビット識別フィールド、および、IPパケット・ヘッダの32ビット送信元IPアドレスを用いて、8ビットのハッシュ値を生成する 2456。
The IP segmentation module generates an 8 bit hash value using the 16 bit identification field of the IP packet header and the 32 bit source IP address of the
・エントリ使用中フラグとともに、32ビットメモリ・アドレスをルックアップするために、8ビット・ハッシュ値を用いる 2450。エントリ使用中フラグがセットされていなければ、それは、これが、この受信されたIPパケットの最初に受信されたIPフラグメントであることを指示している。
Use an 8-bit hash value to look up the 32-bit memory address with the entry
・次に、エントリ使用中フラグがセットされ、IPパケット・データベースが、初期化される。IPパケット・データベース2454, 2458は、VSOCKモジュール・オーバーフロー・ソケット・データベース・メモリ・エリアに存在する。IPパケット・データベースの内部には、IPパケット・データを保持するメモリ(ソケット受信データ・メモリ空間の)に対するポインタが、ある。このIPパケットセグメントが、どれくらい長く保持されているかがわかるように、タイム・スタンプも、IPパケットCBに含まれている。タイマが満了すると、全ての受信されたIPパケットセグメントが、破棄される。
Next, the entry busy flag is set and the IP packet database is initialized. The
・分割オフセットが、IPパケット・ヘッダにセットされていれば、その分割オフセットを用いて、メモリ・バッファ内をどれくらい下った位置で、受信されたIPパケット・データを書き込み始められるかを決定する 2452。
If a split offset is set in the IP packet header, use that split offset to determine how far down in the memory buffer to start writing received
・カウンタが、受信されたバイトの総数を記録し、IPパケット2462, 2460, 2464とともに保持される。このカウンタに受け取られた総バイトが、最後のIPパケット・フラグメント（IPヘッダの制御フラグフィールドのmore fragmentフラグが0にセットされるという事実によって指示される）のデータ量と、最後のIPパケット・フラグメントの分割オフセットとの和と比較される。分割されたIPデータグラムの全データが届いていると計算されると、そのソケット情報が、TCP/UDPプロトコル処理層に渡される。
A counter records the total number of bytes received and is kept with the
図25を参照すると、IPパケット・データベースに記憶されるさらなる情報に、IPパケット衝突テーブル2590、および、IPパケット・ポインタ・テーブル2588が含まれる。使用中の各ルックアップテーブルエントリ2580は、IP送信元アドレス、および、IPパケット識別ペアと連係している。そのペアは、衝突テーブルに記憶されている。ハッシング（ハッシュ法）2598が、既に使用中のルックアップテーブル中のエントリをヒットした場合、以下の2つの可能性がある。
Referring to FIG. 25, additional information stored in the IP packet database includes an IP packet collision table 2590 and an IP packet pointer table 2588. Each
・受信されたIPパケット・フラグメントが、既に考慮にはいっているIPデータグラムに属している。受信されたIPパケット・フラグメントのIP送信元アドレス・フィールドおよびIPパケット識別フィールドが、衝突テーブルエントリに記憶されている値と一致する。 • The received IP packet fragment belongs to an IP datagram that is already considered. The IP source address field and the IP packet identification field of the received IP packet fragment match the values stored in the collision table entry.
・受信されたIPパケット・フラグメントが、未知のIPデータグラムに属している。受信されたIPパケット・フラグメントのIP送信元アドレス・フィールドおよびIPパケット識別フィールドが、衝突テーブルエントリに記憶されている値と一致しない。それは、衝突が起こり、したがって、その受信されたIPパケット・フラグメントが棄てられるということを意味する。 • The received IP packet fragment belongs to an unknown IP datagram. The IP source address field and IP packet identification field of the received IP packet fragment do not match the values stored in the collision table entry. That means that a collision occurs and therefore the received IP packet fragment is discarded.
使用中のフラグのほかに、LUT 2580の各エントリは、パケットが受信データ・バッファ・メモリに収まるために振り当てられる開始アドレスを記憶する。ハッシング2598が、まだ使用されていないLUTのエントリをヒットしたら、メモリ要求が、開始アドレスを計算するVSOCKモジュール・メモリ・アロケータ・モジュール2500に送られる。メモリ・アロケータ・モジュールによって分割ブロックに配給されるメモリ・ブロックのサイズは、固定されている（2キロバイト）。再構築されるべきIPパケットが、1ブロックのメモリにぴったり合う場合には、IPパケット・フラグメントが、切れ目なく記憶され、そして、メモリ・ブロック内の正確な位置が、開始アドレスおよびIP分割オフセットから計算できる。メモリ・アロケータ・モジュールは、メモリ・ブロックを、切れ目なく割り当てない。再構築されるべきIPデータグラムが、2つ以上のメモリ・ブロックを必要とする場合には、受信データ・バッファ・メモリへのパケット・フラグメントのマッピングは、より難しくなる。開始アドレス、IP分割オフセット、および、IP長フィールドに基づいて、ユーザは、メモリ・ブロック境界が、再構築されたIPデータグラムによって交差されようとするときを計算することができる。最初にメモリ・ブロック境界が交差されるとき毎に、メモリ要求が、次に利用可能なブロックの開始アドレスをその後に配給するVSOCKメモリ・アロケータ・モジュールに送られなければならない。さらなるブロックの開始アドレスが、有効フラグとともに、ポインタテーブルに記憶される。イーサネット・ジャンボ・フレーム（最大9キロバイト）に収容されたパケットをハンドルできることが望ましいから、8メモリ・ブロックまで必要となることもある。これは、LUT内の各エントリに対して、ポインタテーブルに7つのポインタを記憶できるようにする必要があるということを意味する（256 x 7=1792 ポインタ）。
In addition to the in-use flag, each entry in the
IP分割モジュールは、IP分割モジュールコントローラ2594を必要とする。IP分割モジュールコントローラのタスクは、以下の通りである。
The IP partition module requires an IP
・ポインタテーブルおよび受信データ・メモリ・バッファに対するアドレス信号、書き込み信号、および、読み出し信号の生成。 Generation of address signals, write signals, and read signals for the pointer table and received data memory buffer.
・VSOCKメモリ・アロケータ・モジュール2500に、メモリ・ブロックを要求する（メモリ・アロケータ・モジュールが、配るべき、さらなるメモリ・ブロックを何ら持たない場合には、パケット・アセンブリ・タイマが満了し、それによって、IPパケットが棄てられるのを待たなければならない）。 Requests a memory block from the VSOCK memory allocator module 2500 (if the memory allocator module has no further memory blocks to distribute, the packet assembly timer expires, thereby , You have to wait for the IP packet to be discarded).
・IPデータグラムの再構築が完了したことを、TCP層に合図する。 Signal the TCP layer that IP datagram reconstruction is complete.
・IPデータグラムの再構築が完了すると、LUT中の全ての使用中のフラグ、および、ポインタテーブル中の有効フラグが、クリアされる。 • When the IP datagram reconstruction is complete, all in-use flags in the LUT and valid flags in the pointer table are cleared.
・タイムアウトの管理
・IPパケットのために受信されたバイトの総数をモニタする。
Timeout management. Monitor the total number of bytes received for IP packets.
・入ってくるIPデータ・ストリームから、必要とされるフィールドを抽出する。 Extract the required fields from the incoming IP data stream.
このセクションは、IP再構築をハンドルする別の方法を扱う。インターネット・チューナ10Gは、内部プロセッサおよびローIP受信モジュールを用いることによっても、IP再構築をハンドルすることができる。受信されたIPパケットが分割されていると、受信されたIPパケットは、内部プロセッサに渡される。そうすると、内部プロセッサは、そのパケット・フラグメントを完全なIPデータグラムにアセンブルするステップをハンドルする。IPデータグラムが完成すると、それは、ローIP受信モジュールを介してネットワーク・スタックの最後尾に注入し返される。
This section deals with another way to handle IP reconstruction. The
このセクションは、IP識別フィールド生成アルゴリズムを扱う。内部プロセッサは、IP識別フィールド・スタート・レジスタ2682に任意の16ビット値を書き込むことによって、IP識別フィールドシード値をセットすることができる。IP識別フィールド・ジェネレータ・モジュールは、この16ビット値を受け取り、そして、16ビットのマッピングを遂行して、IP識別フィールドを生成する 2686。次に、IP識別フィールドは、要求モジュールによって用いられる。内部プロセッサ、TCPモジュール、および、ICMPエコー応答ジェネレータ・モジュールは全て、IP識別フィールドを要求できる。
This section deals with the IP identification field generation algorithm. The internal processor can set the IP identification field seed value by writing any 16-bit value to the IP identification
IP識別フィールド・ジェネレータ・モジュール・シード・レジスタは、新しいIP識別フィールドが要求される度毎にインクリメントされる 2684。識別フィールド・ジェネレータ・モジュール・ビット・マッパ2686は、IP識別フィールド・レジスタ値IP_ID_Regを、識別フィールド・ジェネレータ・モジュールバスIP_ID_Outが各要求に対して単純に値をインクリメントしないように再配置する。
The IP identification field generator module seed register is incremented 2684 each time a new IP identification field is requested. The identification field generator
以下のセクションは、TCPトランスポート・プロトコルおよびUDPトランスポート・プロトコルの両方をハンドルするTCPモジュール1752を扱う。図27を参照すると、TCPモジュールは、4つのより小さな主要モジュール；ソケット送信インターフェイス2700、TCP送信インターフェイス2704、TCP受信インターフェイス2708、および、ソケット受信インターフェイス2702に分かれる。
The following section deals with
以下のリストは、インターネット・チューナ10GアーキテクチャにサポートされているTCP能力について記述している。
The following list describes the TCP capabilities supported by the
・64,000ソケットまでのサポート
・TCPアウト・オブ・オーダ・パケットのサポート
・スロー・スタート・アルゴリズム
・高速再送アルゴリズムおよび高速回復アルゴリズム
・選択可能なNagle（ナグル）アルゴリズム
・スケーリング・ウィンドウサポート
・セレクティブACK（SACK：選択確認応答）サポート
・周回シーケンス番号に対する保護(PAWS) サポート
・タイム・スタンプ・サポート
・キープ・アライブ・タイマ
ソケット制御ブロック(CB)2706には、各接続に特有であり、インターネット・チューナ10Gにおけるバーチャル・ソケット即ちVSOCKアーキテクチャの重要な構成要素である情報、状態およびパラメータのセッティングが含まれている。
Support for up to 64,000 sockets Support for TCP out-of-order packets Slow start algorithm Fast resend algorithm and fast recovery algorithm Selectable Nagle algorithm Scaling window support Selective ACK (SACK) : Selection confirmation response) Support • Protection against circulatory sequence number (PAWS) Support Time stamp Support Support keep alive timer The socket control block (CB) 2706 is specific to each connection, and in
このセクションは、TCP受信モジュール2708を扱う。図28は、TCP受信データ・フローを示している。
This section covers the TCP receive
標準のIPトラフィックにおいては、IPパケットは、64ビットTCP受信データ・パスを介して受信される。IPパケット・ヘッダは、TCPパーザ・モジュール2846に渡され、また、パケット・データは、受信データ・メモリ・コントローラ2848に渡される。分割されたIPパケットにおいては、パケット・データは、メモリ・ブロックを介して渡され、一方、パケット・ヘッダ情報は、標準の受信パスを介して渡される。これは、IP分割からのメモリ・ブロックが、受信データ・メモリ・コントローラによって書き込まれたデータブロックと同じフォーマットを持つことを可能にする。内部プロセッサも、受信データ・メモリ・コントローラを介して受信されたパケット・データを注入するために、メモリ・ブロックを用いる。
In standard IP traffic, IP packets are received via a 64-bit TCP receive data path. The IP packet header is passed to the
受信TCPパーザは、TCPヘッダー情報を構文解析し、パラメータを、VSOCKモジュール2834および受信状態ハンドラ・モジュール2832に渡す責を負っている。受信TCPパーザが、パケット・データに関して何を行うべきか知らない場合には、それは、そのパケット・データを例外ハンドラ・モジュール2838に渡す。さらに、受信TCPパーザ・モジュールは、全てのパケット・データを、例外ハンドラ・モジュールに送るようにプログラムすることもできる。
The receive TCP parser is responsible for parsing the TCP header information and passing parameters to the
VSOCKモジュール（他で詳細に記述される）は、ローカルIPアドレス、リモートIPアドレス、および、ポート・アドレスを受け取り、CBにポインタを返す。 The VSOCK module (described elsewhere in detail) receives a local IP address, a remote IP address, and a port address and returns a pointer to the CB.
NATとIPマスカレーディング・モジュール2842（他で詳細に記述される）は、受信されたパケットが、NATパケットまたはIPマスカレーディング・パケットであるかどうかを決定する。受信されたパケットが、NATパケットまたはIPマスカレーディング・パケットであれば、そのNATパケットまたはIPマスカレーディング・パケットが、ロー・パケットとして内部プロセッサに渡される。 A NAT and IP masquerading module 2842 (described in detail elsewhere) determines whether the received packet is a NAT packet or an IP masquerading packet. If the received packet is a NAT packet or IP masquerading packet, the NAT packet or IP masquerading packet is passed to the internal processor as a raw packet.
受信状態ハンドラ・モジュール（他で詳細に記述される）は、各接続の状態を追跡し、その接続に対応するCBを更新する。 A receive state handler module (described in detail elsewhere) tracks the state of each connection and updates the CB corresponding to that connection.
このセクションは、受信TCPパーザ・モジュール2846を扱う。受信TCPパーザ・モジュールは、TCPパケット・ヘッダ情報を、他のTCP受信モジュールに渡す。TCPパーザ・モジュールには、内部プロセッサから、インターネット・チューナ10Gネットワーク・スタックの受信データ・パスにデータを注入するために必要とされる内部プロセッサレジスタが含まれている。内部プロセッサは、メモリ・ブロックをセットアップし、そして、必要な情報を用いて受信TCPパーザ・レジスタをプログラムしなければならない。受信TCPパーザ・モジュールは、TCPヘッダの部分チェックサムを遂行し、受信データ・メモリ・コントローラからの部分チェックサムにこの部分チェックサムを加えて、このチェックサム足し算の結果と、TCPヘッダのチェックサムとを比較する。分割されたIPパケットにおいては、受信TCPパーザ・モジュールが、送られてきた最後のIPパケット・フラグメント中のチェックサムに対して、TCPヘッダのチェックサムをチェックする。
This section deals with the receive
IPモジュールは、IP分割ビットをセットし、適切なパケット・フラグメントのデータ・パスに最初のメモリ・ブロック・ポインタ、最後のメモリ・ブロック・ポインタ、インデックス、および、部分チェックサムを挿入しなければならない。また、TCP受信モジュールは、TCP擬似ヘッダを計算するために、IPプロトコル・フィールドを必要とする。 The IP module must set the IP split bit and insert the first memory block pointer, last memory block pointer, index, and partial checksum into the appropriate packet fragment data path . The TCP reception module also requires an IP protocol field to calculate the TCP pseudo header.
このセクションは、受信データ・メモリ・コントローラ・モジュール2848を扱う。受信データ・メモリ・コントローラ・モジュールは、IPモジュールとTCPモジュールとの間の64ビットバスから、受信データ・メモリのデータ・メモリ・ブロックにデータを転送する。データ転送の2つのモードがある。データ転送の標準モードが、メモリ・ブロックにTCPデータを記憶するために用いられる。データ転送のロー・モードが、メモリ・ブロックにパケット全体を記憶するために用いられる。データ転送のロー・モードが、NATとIPマスカレーディングのために用いられる。
This section covers the received data
このセクションは、VSOCKモジュール2834を扱う。VSOCKモジュールは、バーチャル・メモリ管理に等価な最適化されたハード・ワイヤード・ロジックをインプリメントしている。それに匹敵する機能が、プログラム可能なプロセッサ上で走る複雑なソフトウェアによって標準的に実行される。VSOCKモジュールを用いる結果として、インターネット・チューナ10Gが、仮想数(virtual number)のソケットを利用できる。ソケットの数は、オンチップに接続された、あるいは、外部的に接続された、あるいは、オンチップと外部的との両方で接続されたメモリ量によってしか制限されない。ソケットは、常設のコネクションである。コネクションは、以下の3つのステージ：ハーフ・オ−プン(HO)2858、オープン2840、タイム・ウェイト(TW)2850を通る。各コネクションに関する情報は、制御ブロック(CB)に記憶される。
This section deals with
図29は、VSOCKおよび受信状態ハンドラ制御ブロックの探索解決フローを示している。VSOCKモジュール2834は、受信されたパケットから、送信元IPアドレス、送信先IPアドレス、および、ポート・アドレスを渡される。VSOCKモジュールは、受信状態ハンドラ・モジュールに、ソケット・オープンCBポインタまたはTW CBポインタを返す。ロッキング機構が、1つのモジュールがある1つのソケットCB上で動作している間、他のどのモジュールもそのソケットCB上で動作できないことを確実にする。VSOCKは、送信元IPアドレス、送信先IPアドレス、送信元ポート・アドレス、送信先ポート・アドレス上でハッシュを実行する。ハッシュ関数2980は、オープン/TW CBルックアップテーブル(LUT)2986のインデックスとしての役割をする17ビット値を生成する。そのインデックスが付けられた位置のオープン/TW CB LUTエントリが、オープンCB 2988あるいはTW CB 2994に対するポインタを保持する。
FIG. 29 shows a search solution for the VSOCK and reception state handler control block. The
HOCBのハンドリングの説明に対しては、受信状態ハンドラ・モジュールについて記述しているセクションを参照されたい。 For a description of HOCB handling, see the section describing the receive state handler module.
オープン/TW CB LUTからのポインタは、各々異なるIPアドレスおよびポート・アドレスを持つが、同一のハッシュ番号に帰着する(ハッシュ衝突に起因して)、ゼロ以上のソケットCBのリンクされたリストの最初のCBを指し示す。VSOCKは、受信されたパケットのIPアドレスおよびポート・アドレスと、チェーン状につながれたソケットCB中のエントリとを比較しながら、一致が見つかるか、または、チェーンの終点に到達するまで、このチェーンを下っていく。一致が見つかれば、そのソケットCBに対するポインタが、受信状態ハンドラ・モジュールに渡される。VSOCKモジュールが、このチェーンの終点に到達すれば、それは、エラーである。そのときには、VSOCKモジュールは、TCPパーザ・モジュールにエラーを通知する。 Pointers from open / TW CB LUTs each have a different IP address and port address, but result in the same hash number (due to a hash collision), first in a linked list of zero or more socket CBs Point to CB. VSOCK compares the IP address and port address of the received packet with the entries in the chained socket CB until it finds a match or reaches the end of the chain. Go down. If a match is found, a pointer to that socket CB is passed to the receive state handler module. If the VSOCK module reaches the end of this chain, it is an error. At that time, the VSOCK module notifies the TCP parser module of the error.
オープン/TWソケットCB LUTエントリに接続されたソケットCBのチェーンには、オープンCBおよびTW CBが、含まれている。オープンCBは、チェーンの上位にある。オープンCBには最大数が存在し、チェーン・セッティング当りの受信TCPの最大オープンCBによって決定される。TW CBは、オープンCBの後にチェーン状につながれている。チェーン当たりのTW CBにも、最大数が存在する。オープンCBは、3ウェイTCPハンドシェークが完成したときに生成され、また、HO CBは、受信状態ハンドラ・モジュールによってオープンCBに移動される。TW CBは、最後のACKがFINシーケンスに送られたときに、受信状態ハンドラ・モジュールによって、オープンCBから生成される。いずれの場合にも、もはや空きがないときには、エラーが、受信状態ハンドラ・モジュールに返される。 The chain of sockets CB connected to the open / TW socket CB LUT entry includes an open CB and a TW CB. Open CB is at the top of the chain. There is a maximum number of open CBs, which are determined by the maximum open CB of received TCPs per chain setting. TW CB is chained after the open CB. There is also a maximum number of TW CBs per chain. The open CB is generated when the 3-way TCP handshake is completed, and the HO CB is moved to the open CB by the reception state handler module. The TW CB is generated from the open CB by the receive state handler module when the last ACK is sent in the FIN sequence. In either case, when there is no more room, an error is returned to the receive state handler module.
オープンCBのためのCBキャッシュが、LUTエントリからのリンクのセット番号と違うオープンCBにインプリメントされる。オープンCBがCBキャッシュ内にあるとき、そのオープンCBに1ビットがセットされる。そのCBキャッシュが、17ビット・ハッシュおよびLUT動作と同時に探索される。 The CB cache for the open CB is implemented on an open CB that is different from the link set number from the LUT entry. When an open CB is in the CB cache, 1 bit is set in the open CB. The CB cache is searched simultaneously with 17-bit hash and LUT operations.
このセクションは、受信状態ハンドラ・モジュール2832を扱う。SYNパケットが受信されると、12ビット・ハッシュが、VSOCKの起動（17ビット・ハッシュを遂行して、オープンCBまたはTW CBを探索する）に加えて作動し、送信先ポートが、認証されたポートリストと照合される。そのポートが、認証されたポートリストに載っており、VSOCK 2834が、一致するオープンCBまたはTW CBを見出さなかった場合には、その12ビット・ハッシュの結果が、HO CBテーブル2858のインデックスとして用いられる。VSOCKが、一致するオープンCBまたはTW CBを見出した場合には、重複CBエラーが、内部プロセッサに送られ、そして、そのSYNパケットは、棄てられる。異なるIPアドレスおよびポート・アドレスを持つHO CBテーブル中のエントリが、既に存在する場合には、受信されたパケット情報が、古い情報に重ね書きされる。この重ね書き動作は、リソースを、SYNパケット・フラッド攻撃あるいはサービス不能(DOS)攻撃に対して保護することを可能にする。重ね書き動作は、また、HO CBテーブルをエージする(age)必要も除去する。1つの側面の結果は、既にSYN/ACKされていたコネクションを、黙って棄てることができるということである。HO CBに対するポインタが、受信状態ハンドラ・モジュールに渡される。ローカル側によってオープンされたコネクション（ローカル側は、SYN/ACKパケットではなく、SYNパケットを受信する）しか、HO CBテーブルに入力されない。
This section deals with the receive
ACKパケットが受信されると、12ビット・ハッシュが作動し、また、VSOCKが起動する。12ビット・ハッシュを介してHO CBにヒットが存在するが、VSOCKが、オープンCBまたはTW CBを見出さず、また、シーケンス番号およびACKパケット番号が有効であれば、そのコネクションの3ウェイ・ハンドシェークが完成し、そして、そのCBが、受信状態ハンドラ・モジュールによってオープンCBテーブルに転送される。VSOCKが、オープンCBまたはTW CBを見出すが、12ビット・ハッシュによるヒットが存在しなければ、そのACKパケットが、重複ACKパケットでないかだけではなく、受信状態ハンドラ・モジュールによって、有効なシーケンス番号およびACK番号でないかチェックされる。 When an ACK packet is received, a 12-bit hash is activated and VSOCK is activated. If there is a hit in the HO CB via the 12-bit hash but VSOCK does not find an open CB or TW CB, and the sequence number and ACK packet number are valid, the 3-way handshake for that connection Once completed, the CB is transferred to the open CB table by the receive state handler module. If VSOCK finds an open CB or TW CB, but there is no hit with a 12-bit hash, not only is the ACK packet a duplicate ACK packet, but also a valid sequence number and It is checked whether it is an ACK number.
VSOCKモジュールが、正しいソケットCBを見出すと、他の関連する情報が、受信状態ハンドラ・モジュールによって読み出されて、更新される。TCPデータは、大きな（2 キロバイト）メモリ・バッファか、小さな（128バイト）メモリ・バッファかのいずれにでも記憶される。単一のセグメントが、メモリ・バッファ間にまたがることができる。1つのサイズのメモリ・バッファが尽きると、別のサイズのメモリ・バッファが用いられる。データが、与えられたソケットに対して受信されると、ソケット・ハッシュLUTにも、そのData_Availビットがセットされる。 When the VSOCK module finds the correct socket CB, other relevant information is read and updated by the receive state handler module. TCP data is stored in either a large (2 kilobyte) memory buffer or a small (128 byte) memory buffer. A single segment can span memory buffers. When one size of memory buffer is exhausted, another size of memory buffer is used. When data is received for a given socket, its Data_Avail bit is also set in the socket hash LUT.
受信状態ハンドラ・モジュールは、スティーブンズによって記述されているようなステートマシンを用いる（スティーブンズのセクション18.6の図18.12を参照のこと）。 The receive state handler module uses a state machine as described by Stevens (see Figure 18.12 in Stevens section 18.6).
受信状態ハンドラ・モジュールが、RSTパケットが必要であると決定すると、それは、RSTパケット・ジェネレータ・モジュール2830に適切なパラメータを配布する。SYN/ACKパケットまたはACKパケットが必要なときには、それはRX-TX FIFO 2860にCBハンドルを送る。
If the receive state handler module determines that an RST packet is needed, it distributes the appropriate parameters to the RST
このセクションは、RSTパケット・ジェネレータ・モジュール2830を扱う。図30を参照すると、RSTパケット・ジェネレータ・モジュールは、RSTパケット応答を必要とするパケット中に受信されるMACアドレス、4つのソケット・パラメータ、および、シーケンス番号を受け取って、RSTパケットを組み立てる。それは、最初に、MTXメモリ3014にパケットを構築するためのブロックを要求する。RSTパケットは、常に40バイト長であるから、RSTパケットは、どんなサイズのMTXブロックにもはまる。RSTパケット・ジェネレータ・モジュールは、常に、利用可能な最小のブロック（標準的に128バイト・ブロック）を要求する。RSTパケットは、0x0000に固定されたIP識別フィールドを持ち、それらのdon't fragmentビットが、IPヘッダに1とセットされる。
This section covers the RST
RSTパケット・ジェネレータ・モジュールが、RSTパケットを組み立てた後、RSTパケット・ジェネレータ・モジュールは、RSTパケット送信キューに、RSTパケットを含有しているMTXブロックの開始アドレスを記憶する。RSTパケット送信キューは、m1メモリに組み立てられる 3010。m1メモリの1ブロックが要求され 3016、それが一杯になるまで用いられる。各m1ブロックの最後のエントリが、用いられる次のm1ブロックのアドレスを指し示す。したがって、RSTパケット・キューは、動的に成長することができる。RSTパケット・ジェネレータ・モジュールは、m1メモリに一度に32ビットアクセスする（MTXブロック・アドレスが26ビットでしかないから）。RSTパケット送信キュー長は、m1メモリが利用可能な限り、成長することができる。最早、これ以上のm1メモリが、RSTパケット送信キューに利用可能でなくなれば、RSTパケット・ジェネレータ・モジュールは、受信状態ハンドラ・モジュールからのRSTパケット要求3018を黙って破棄する。RSTパケットの破棄は、送信中にRSTパケットを棄てるのと同等のネットワーク上の効果を持つ。コネクションが全く存在しないから、この状況においてRSTパケットを棄てることは、遂行に深刻な影響を持たない。
After the RST packet generator module assembles the RST packet, the RST packet generator module stores the start address of the MTX block containing the RST packet in the RST packet transmission queue. The RST packet transmission queue is assembled 3010 in m1 memory. A block of m1 memory is requested 3016 and used until it is full. The last entry in each m1 block points to the address of the next m1 block to be used. Thus, the RST packet queue can grow dynamically. The RST packet generator module accesses m1 memory 32 bits at a time (since the MTX block address is only 26 bits). The RST packet transmission queue length can grow as long as m1 memory is available. As soon as no more m1 memory is available for the RST packet transmission queue, the RST packet generator module silently discards the
RSTパケット送信キューの出力が、TCP送信パケット・スケジューラ・モジュールに渡される。TCP送信パケット・スケジューラ・モジュールが、RSTパケットが送られてしまったことを、RSTパケット・ジェネレータ・モジュールに指示すると、そのRSTパケットのために使用されていたMTXブロックは、解放される。1つのm1メモリ・ブロック中の全てのエントリが送られ、次のm1ブロックに対するリンク・アドレスが読み出されると、そのm1メモリ・ブロックは、解放される。 The output of the RST packet transmission queue is passed to the TCP transmission packet scheduler module. When the TCP transmit packet scheduler module indicates to the RST packet generator module that the RST packet has been sent, the MTX block used for that RST packet is released. When all entries in one m1 memory block have been sent and the link address for the next m1 block has been read, the m1 memory block is freed.
このセクションは、RX to TX FIFO 2860を扱う。このFIFOは、受信状態ハンドラ・モジュール2832が、受信されたパケットに応えて送る必要があると決定したSYN/ACKパケットおよびACKパケットのキューをつくるに用いられる。受信状態ハンドラ・モジュールは、RX to TX FIFOに、以下の情報を渡す。
This section deals with RX to
・ソケット情報を含有しているCBアドレス（16ビット）
・CBタイプ（2ビット；00 = HO、 01 = オープン、 10 = TW）
・送られるべきパケット（1ビット；0 = SYN/ACK, 1 = ACK）
各RX to TX FIFOエントリは、4バイト長で、雑メモリに記憶される。一般に、RX toTX FIFOは、1,000エントリのFIFO深さを供給する4キロバイトを割り付けられる。RX to TX FIFOの出力は、SYN/ACKパケット・ジェネレータ・モジュールに流れ込む。
-CB address containing socket information (16 bits)
• CB type (2 bits; 00 = HO, 01 = open, 10 = TW)
• Packet to be sent (1 bit; 0 = SYN / ACK, 1 = ACK)
Each RX to TX FIFO entry is 4 bytes long and is stored in miscellaneous memory. In general, the RX toTX FIFO is allocated 4 kilobytes which provides a FIFO depth of 1,000 entries. The output of the RX to TX FIFO flows into the SYN / ACK packet generator module.
このセクションは、SYN/ACKパケット・ジェネレータ・モジュール2841を扱う。SYN/ACKパケット・ジェネレータ・モジュールは、RX to TX FIFO 2860から情報出力を受け取り、そして、指定されたCB（HOCB 2858、オープンCB2840、TW CB2850のいずれか）から別の関連する情報をルックアップして、望みのパケット(SYN/ACKパケット、ACKパケットのいずれか)を組み立てる。RSTパケット・ジェネレータ・モジュール2830のように、SYN/ACKパケット・ジェネレータ・モジュールは、最初に、MTXメモリにパケットを構築するためのブロックを要求する。SYN/ACKパケットおよびACKパケットは、常に40バイト長であるから、そのパケットは、どんなサイズのMTXブロックにもはまる。SYN/ACKパケット・ジェネレータ・モジュールは、常に、利用可能な最小のブロック（標準的に128バイト・ブロック）を要求する。
This section covers the SYN / ACK
SYN/ACKパケットまたはACKパケットを組み立てた後、SYN/ACKパケット・ジェネレータ・モジュールは、開始MTXブロック・アドレスを、深さ16のキューに置き、それは、その後、TCP送信パケット・スケジューラ・モジュールに流れ込む。RXto TX FIFOが、プログラム可能な高いウォーター・マークを渡すと、送信パケット・スケジューラ・モジュールが、その状況を通知されて、これらのパケットの送信優先順位を増加させる。
After assembling the SYN / ACK packet or ACK packet, the SYN / ACK packet generator module places the starting MTX block address in a queue of
このセクションは、NATとIPマスカレーディングを扱う。NATとIPマスカレーディング・モジュール2842は、VSOCKモジュールと並列に働く。NATとIPマスカレーディング・モジュールは、入ってくるパケットをデコードして、そのパケットが、あらかじめ指定されたNATかIPマスカレーディングのポート範囲にあるかどうか確かめる。そのパケットが、NATかIPマスカレーディングのポート範囲にあれば、信号通知メカニズムを用いて、そのパケットがNATパケットであることをVSOCKブロックに指示する。これが起こると、パケット全体が、受信メモリ・バッファに記憶される。次に、そのパケットが、どこかのポイントでホスト・システムに転送される。ホスト・システムのドライバが、経路制御機能を遂行し、ヘッダパラメータを置き換え、そして、適切なネットワーク・インターフェイスにパケットを送る責を負う。
This section deals with NAT and IP masquerading. NAT and
このセクションは、例外ハンドラ・モジュール2838を扱う。例外ハンドラ・モジュールは、インターネット・チューナ10Gネットワーク・スタックによってハンドルできないパケットを、インターネット・チューナ10G内部プロセッサに送る。
This section deals with the
このセクションは、メモリ・ブロック制御回路を扱い、以下の機能について説明する。 This section deals with the memory block control circuit and describes the following functions:
リザーブ・メモリ・ブロックメモリ・ブロック制御回路は、1つの小さなメモリ・ブロックおよび1つの大きなメモリ・ブロックを蓄えとして常に使用可能にしておく。この蓄えは、データがメモリ・ブロックに書かれなければならないとき、遅れがほとんど出ないことを保証する。メモリ・ブロック制御回路は、また、できるだけ並列に、ブロック要求とデータ書き込みとを処理する。リザーブ・メモリ・ブロックは、リセットによって初期化される。 Reserved memory block The memory block control circuit always keeps one small memory block and one large memory block available for storage. This reserve ensures that there is little delay when data must be written to the memory block. The memory block control circuit also processes block requests and data writes in parallel as much as possible. The reserved memory block is initialized by reset.
初期化とメモリ・ブロックサイズ選択−TCPセグメントまたはUDPセグメントのパラメータが、初期化される。用いられるメモリ・ブロックのサイズは、IPパーザ・モジュールからのTCP長情報およびTCPヘッダ長情報によって決定される。データ・セクションのサイズ（TCPヘッダ長を引いたTCP長）が、小さなメモリ・ブロックにはまれば、そのリザーブ・メモリ・ブロックが、用いられ、そして、他の1つの小さなメモリ・ブロックが要求されて、リザーブ・メモリ・ブロックが補充される。そうでない場合には、蓄えられている大きなメモリ・ブロックが用いられ、そして、他の1つの大きなメモリ・ブロックが要求されて、リザーブ・メモリ・ブロックが補充される。小さなブロックが利用可能でない場合に、大きなブロックが用いられる。しかしながら、大きなブロックが、必要であるが利用可能でない場合、小さなブロックは、用いられない。上記のtcp_in_rd生成を参照されたい。 Initialization and memory block size selection-TCP or UDP segment parameters are initialized. The size of the memory block used is determined by the TCP length information and TCP header length information from the IP parser module. If the size of the data section (TCP length minus the TCP header length) fits in a small memory block, that reserved memory block is used, and another small memory block is required. Thus, the reserved memory block is replenished. Otherwise, the stored large memory block is used and another large memory block is requested to replenish the reserved memory block. Large blocks are used when small blocks are not available. However, if a large block is needed but not available, the small block is not used. Refer to tcp_in_rd generation above.
境界整列したTCPデータのメモリ・ブロックへの書き込み−ヘッダに奇数個のオプション半ワード（各32ビット幅）が存在すれば、TCPパケット内のデータは境界整列し、64ビット境界で開始するデータに帰着する。データが境界整列すると、それがIPから出たときに、それをメモリ・ブロックに直接入れることができる。そのセグメントのための最初のブロックのアドレスが、ステートマシンに送られる。TCPセグメントに残されているデータだけではなく、そのブロックの残りの空間に対するカウントが、維持される。メモリ・ブロックが既に一杯でないかどうかの記録も、維持されていなければならない。TCPセグメントの終端に到達するとき、その前のブロックが一杯であったならば、それは、現在のブロックにリンクされなければならない。さらに、現在のブロック・ヘッダのリンクがクリアされ、また、データのデータ長およびランニング・チェックサムが、そのブロック・ヘッダに書き込まれる。その長さは、ip_in_bytes_val中のビットによって決定されるから、最後の64ビット・ワード中のバイト数の関数である。そのブロックが、セグメントの終端の前で空きを使い果たした場合には、データ長およびランニング・チェックサムが、ブロック・ヘッダに書き込まれ、そして1つのブロックが終了したことを指示するフラグがセットされる。セグメントの残りのデータを用いて、大きいリザーブ・メモリ・ブロックと小さいリザーブ・メモリ・ブロックとのどちらを用いるかが決定される。ブロックサイズが尽きた場合には、前のパラグラフと同じ規則が用いられる。最後のメモリ・ブロックのアドレスが、ステートマシンに送られなければならない。 Write aligned TCP data to memory block-If there are an odd number of optional halfwords (each 32 bits wide) in the header, the data in the TCP packet is aligned and the data starts on a 64-bit boundary. Come back. Once the data is aligned, it can be put directly into the memory block when it leaves the IP. The address of the first block for that segment is sent to the state machine. A count for the remaining space of the block is maintained, not just the data left in the TCP segment. A record of whether the memory block is already full must also be maintained. When reaching the end of a TCP segment, if the previous block was full, it must be linked to the current block. In addition, the current block header link is cleared, and the data length and running checksum of the data is written to the block header. Its length is determined by the bits in ip_in_bytes_val, so it is a function of the number of bytes in the last 64-bit word. If the block runs out of space before the end of the segment, the data length and running checksum are written to the block header and a flag is set indicating that one block has ended. . The remaining data of the segment is used to determine whether to use a large reserved memory block or a small reserved memory block. If the block size is exhausted, the same rules as in the previous paragraph are used. The address of the last memory block must be sent to the state machine.
境界整列していないTCPデータのメモリ・ブロックへの書き込み−セグメントのデータが、境界整列していない場合には（ip_in_data[63:0]は、2つの異なるメモリ・ブロックの書き込みとなるデータを含んでいる）、そのメモリ・ブロックに、IPからの最初のロー32ビット半ワードを、ハイ32ビット半ワードとして書き込むことができるように、初めに、その最初のロー32ビット半ワードを記憶する余分のサイクルが存在しなければならない。IPからの次のバス・サイクルにおけるハイ32ビット半ワードは、記憶された半ワードと同じサイクルにおけるロー32ビット半ワードとして書き込まれる。カウントおよびチェックサム計算も、これをハンドルするために適合されなければならない。そうでなければ、境界整列していないデータは、境界整列しているデータと同じようにハンドルされ、同じ結末状態となる。 Writing unaligned TCP data to a memory block-If the segment data is not aligned (ip_in_data [63: 0] contains data to be written to two different memory blocks The first row 32 bits halfword from the IP can be written to the memory block as a high 32 bits halfword first so that the first row 32 bits halfword is stored in the memory block. There must be a cycle of The high 32-bit halfword in the next bus cycle from the IP is written as a low 32-bit halfword in the same cycle as the stored halfword. Count and checksum calculations must also be adapted to handle this. Otherwise, the unaligned data is handled in the same way as the aligned data and has the same end state.
UDPデータのメモリ・ブロックへの書き込み−UDPデータは、常に境界整列しており、したがって、UDPデータは、境界整列しているTCPデータと同じようにハンドルされる。同じ結末状態が、当てはまる。 Writing UDP data to a memory block—UDP data is always aligned, so UDP data is handled in the same way as aligned TCP data. The same ending situation applies.
チェックサム計算-チェックサムは、RFC 1071に記載されているように計算される。このブロックでは、チェックサムは、データ上でしか計算されない。パーザ・モジュールが、ヘッダ・チェックサムを計算し、そして、ステートマシンが、2つを組み合わせて、チェックサムエラーを持つパケットを、どう処理すべきか決定する。 Checksum calculation-The checksum is calculated as described in RFC 1071. In this block, the checksum is calculated only on the data. The parser module calculates the header checksum and the state machine combines the two to determine how to handle the packet with the checksum error.
このセクションは、ソケット受信モジュール2702を扱う。ソケット受信モジュールは、インターネット・チューナ10Gとホスト・システムとの間の受信されたデータのインターフェイスをハンドルする。
This section covers the socket receive
図31を参照すると、その処理は、受信ロジック3140が、ソケット受信DAVビット・マップ・テーブル3142にビットをセットすることから始まる。これは、64K個のソケットの各々に連係して1ビットを持つテーブルである（したがって、このテーブルは、8キロバイトである）。CBの位置を知ることによって、適切なビットが、セットされる。
Referring to FIG. 31, the process begins with receive
Socket_DAV照会モジュール3146は、バックグラウンドにおいて、このビット・マップ・テーブルを連続的に走査しているブロックである。それが、セットされているビットに遭遇したとき、それは、対応するCBアドレスを生成し、そして、CB構造3148をチェックして、それが有効なlink_listブロックを含むかどうかを確かめる 3144。このブロックは、64ビットのメモリ・アドレスから構成され、16ビット長である。CBが有効なlink_listブロックを持っていれば、CBアドレスおよびlink_list情報が、DMA準備モジュール3152に渡される（2段パイプラインレジスタペアを介して）。Socket_DAVモジュール3144は、また、その時、CBの対応するビットをクリアする。CBが有効なlink_listブロックを含んでいなければ、そのソケットでデータは利用可能であるが、そのソケットに有効な転送ブロック情報は存在しないということをホストに通知するステータス・メッセージが、そのソケットに対して生成される 3162。この場合には、ビット・マップ・テーブル中の対応するビットは、まだクリアされない。link_listブロックを求めているホストに既にステータス・メッセージを送り出したことが認識されているこの場合には、CBも、更新することができる（これは、同じCBに対するステータス・メッセージを重複して送ることに陥らないために必要である)。
The
有効なlink_listブロックが存在したときには、次のステップは、CBおよび転送情報が、DMA準備モジュール3152に送られることである。このモジュールは、ソケット・データ・バッファからデータを読み出して、それを、DMAエンジンのための2つのピンポン転送FIFO 3160, 3156のうちの1つに入れる責を負っている。これが完了すると、それは、転送されるべきデータが存在するという要求を、送信DMAエンジン3164に送る。link_list情報も、送信DMAエンジン3164に渡される。
If there is a valid link_list block, the next step is to send CB and transfer information to the
送信DMAエンジンがこの要求を得ると、それは、ホストへのDMA転送を行うことを求められているということを主DMAエンジンに合図する。バスが与えられると、DMAエンジンは、ピンポン・バッファからデータを読み出して、それらを、ホストに送る。転送が完了すると、そのソケットのCBが更新され、そして、データがホストに送られたことを指示するステータス・メッセージが生成される。 When the transmit DMA engine gets this request, it signals to the main DMA engine that it is required to perform a DMA transfer to the host. Given a bus, the DMA engine reads data from the ping-pong buffer and sends them to the host. When the transfer is complete, the socket's CB is updated and a status message is generated indicating that data has been sent to the host.
ステータス・メッセージ・ジェネレータ3162は、メッセージを実際に生成して、それらを、メモリ3154（1キロバイト）のステータス・メッセージ・ブロックに書き込む責を負っているモジュールである。ステータス・メッセージ生成要求は、送信DMAエンジン、ソケットDAV照会モジュール、あるいは、CPUから来ることができる。
このセクションは、ソケット送信モジュール2700を扱う。次のモジュールは、インターネット・チューナ10Gとホスト・システムとの間にデータを送信するためのインターフェイスをハンドルする。
This section covers the
図32を参照すると、フローが、ホストからのコマンド・ブロック・リストの受け取りで始まる。これは、DMA転送を介して受信され、コマンドリスト3202に置かれる。ここから、ブロックが、コマンド・パーザ・モジュール3204によって抽出されて、解析される。パーザによって認識されたコマンドは実行され、認識されなかったコマンドは、ローカルプロセッサに送られる。
Referring to FIG. 32, the flow begins with receiving a command block list from the host. This is received via DMA transfer and placed in the
そのコマンドが、データを転送するためのものである場合には、link_list情報が、CBアドレスとともに、コマンド・ブロックから抽出されて、転送キュー3206に置かれる。
If the command is for transferring data, the link_list information along with the CB address is extracted from the command block and placed in the
受信DMAエンジン・モジュール3208が、このキューからエントリを受け取り、ホストメモリからのデータ転送を実行する。データは、1対のピンポンFIFOバッファ3296, 3298に置かれる。ちょうど受信されたデータに連係するCBアドレスが、ソケット送信データ制御モジュール3294に渡される。
A receive
ソケット送信データ制御モジュールは、FIFOからデータを受け取って、それらを、送信ソケット・データ・メモリ3292に置く。それは、malloctxメモリ・アロケータ3200から、ブロック・アドレスを得る。制御モジュールは、また、ソケットCBに、そのソケットの優先順位レベルに関して照会を行う。全てのデータが、データ・バッファに転送されてしまうと、そのモジュールは、そのCBアドレスを、4つの優先順位キュー3280, 3282, 3284, 3286のうちの1つに入れる。ソケット送信制御モジュールは、また、ソケットCB 3290を、新しいデータ送信カウント情報で更新する。
The socket send data control module receives data from the FIFO and places them in the send
データが、DMA受信FIFOからソケット・データ・メモリに転送されると、ランニング・チェックサムが、そのときに遂行される。そのチェックサムは、ブロックごとに計算される。これは、その後、データが再度通読される必要がないから、送信待ち時間を縮小するのに役立つ。 When data is transferred from the DMA receive FIFO to the socket data memory, a running checksum is then performed. The checksum is calculated for each block. This then helps to reduce the transmission latency since the data does not need to be read through again.
以下のセクションは、TCP送信モジュール2704を扱う。TCP送信モジュールは、どのソケットが、データ送信のために次に情報を提供されなければならないかを決定し、そして、それにしたがってソケットCBブロックを更新する責を負っている。
The following section deals with
図33を参照すると、TCP送信データ・フローは、ソケット照会モジュールが、XMT_DAVビット・テーブルを通過して、送信データに利用可能なビット・セットを持つエントリを捜すことでスタートする。それが、1つのエントリを見つけると、それは、その後、そのエントリを、ソケットのUser_Priorityレベルにしたがって、4つのキュー3330, 3332, 3334, 3336のうちの1つに入れる。優先順位レベル7または6のソケットは、キューリスト3 3336に入れられ、レベル5および4のソケットは、キューリスト2 3334に入れられ、レベル3および2のソケットは、キューリスト1 3332に入れられ、レベル1および0のソケットは、キューリスト0 3330に入れられる。
Referring to FIG. 33, the TCP send data flow starts with the socket query module looking through the XMT_DAV bit table for an entry with a bit set available for send data. If it finds one entry, it then places that entry in one of the four
これらのリストはすべて、パケット・スケジューラ3350に流れ込む。このスケジューラは、スターブしないように優先順位キューからパケットを抜き取る責を負っている。実際のアービトレーション・パターンはプログラム可能で、次のセクションで扱われる。このスケジューラは、また、HOサポートモジュールから生成されるSYN_ACKパケット間およびRSTパケット間のほかに、送信データ・パケット間も調停する。
All these lists flow into the
パケット・スケジューラが、どのパケットを次に送り出すかを決定すると、それは、この情報を、ソケット送信ハンドラ・モジュール3352に配布する。ソケット送信ハンドラ・モジュールは、ソケットCB情報3338, 3342, 3344を読み出し、パケット・ヘッダを生成し、CBを更新し、そして、パケット送信情報を送信キュー3354に渡す。パケット・ヘッダは全て、別個のメモリ・バッファ3340, 3346内で生成され、それは、その後、データ・バッファにプリペンドされる。これは、また、送られるべきデータが、データ・バッファの中央でスタートする場合に当てはまる。この場合には、パケット・ヘッダデータ・バッファからのポイントが、送られるデータの最初のバイトを指す。このモジュールが、同時に別のモジュールが動作させているかもしれない同様のソケットCBを修正してしまわないようなロッキング機構が用いられる。
When the packet scheduler determines which packet to send next, it distributes this information to the socket send
送信キュー・モジュールは、マスタ送信アービトレータに送られるデータ・パケットのキューをつくる責を負っている。 The transmit queue module is responsible for creating a queue of data packets that are sent to the master transmit arbitrator.
このセクションは、パケット・スケジューラ・モジュール3350を扱う。パケット・スケジューラ・モジュールは、どのパケットが次に送信されるかを決定する責を負っている。図34は、パケット・スケジューラ・モジュールのブロック図を示している。
This section deals with the
そのプロセスは、コンパレータ3482が、現在の状態にあるキュー番号を受け取って、そのキューに、送られるべき何かがあるかどうかを確かめることでスタートする。そのキュー番号は、キューリスト3480のうちの1つ、あるいは、TCP受信パケットを表わすことができる。待機している、そのタイプのパケットが存在すれば、そのエントリは、次に送信されるパケット3484として抜き取られて、スケジュール化される。そのキューに何らのパケットも存在しなければ、状態カウンタがインクリメントされて、次のキュー状態がチェックされる。これは、キュー#が、送信の準備ができているパケットを持っているキューリスト(あるいはTCP受信パケット)と一致するまで、または、状態エントリのエンドビットがセットされるまで、継続する。エンドビットがセットされると、状態カウンタは、0にリセットバックされる。キュー・アービトレーション・シーケンスは、プログラム可能である。アプリケーションが、最初に、Queue_Stateレジスタを0x00にセットし、次に、キュー番号およびエンドビットをQueue _Entryレジスタに書き込むことによって、これをセットすることができる。Queue_Stateレジスタのフラット・ビットとステープビットとのどちらかをアサートすることによってセットすることができる2つの内蔵アービトレーション・シーケンスがある。これらの内蔵シーケンスが、以下に記述される。
The process starts with the
・フラット・シーケンス。これは、スケジューラが任意のリセットの後に用いるデフォルト・シーケンス状態である。これは、また、Tシーケンス・レジスタのseq_progフィールドを、01に書き込むことによってセットすることができる。 ・ Flat sequence. This is the default sequence state that the scheduler uses after any reset. This can also be set by writing the seq_prog field of the T sequence register to 01.
・ステープ・シーケンス。前もってプログラムされたフラット・シーケンスに換わるものが、ステープ・シーケンスである。このシーケンスは、優先順位の高いキューほど大きな重みを与え、多くの優先順位の高いアプリケーションが同時に走っている場合に有用である。これは、Tシーケンス・レジスタのseq_progフィールドを、10に書き込むことによってセットされる。 • Staple sequence. An alternative to the pre-programmed flat sequence is the staple sequence. This sequence gives higher weight to higher priority queues and is useful when many high priority applications are running at the same time. This is set by writing the seq_prog field of the T sequence register to 10.
このセクションは、ハッシュ・アルゴリズムを扱う。インターネット・チューナ10Gで用いられているハッシュ・アルゴリズムは、ソケットの送信元ポートと送信先ポート、および、送信元IPアドレスと送信先IPアドレスを組み合わせて、単一の17ビット・ハッシュ値を形成する。そのアルゴリズムは、極度に単純化するように設計されており、それによって、ハッシュLUT衝突を最小限にするのに十分な広がりの分布範囲を持つと同時に、単一クロック・サイクル結果を生じる。
This section deals with the hash algorithm. The hash algorithm used in
このセクションは、ISNアルゴリズムを扱う。インターネット・チューナ10Gで用いられているISNアルゴリズムは、RFC1948に記載されているそれと同様であり、4つのマイクロ秒をベースとしたタイマ、本システムによってセットできる任意のブート（起動）値、および、4つのソケット・パラメータ（送信元と送信先とのポートおよびIPアドレス）を組み込んでいる。
This section deals with the ISN algorithm. The ISN algorithm used in
このセクションは、TCP送信データ・バッファ・ヘッダ定義を扱う。TCPデータが記憶される各MTXブロック内に、128ビット・ヘッダが保持される。このヘッダのフォーマットは、以下のように定義される。 This section deals with TCP send data buffer header definitions. A 128-bit header is held in each MTX block where TCP data is stored. The format of this header is defined as follows.
最初のビット・ワード
[63:62] tcp_block_size（01= 2K、00 = 128）
[61:59] tcp_block_type（000 = データ、001 = RST）
[58] 有効な次のリンク・フィールド
[57:32] 次のブロック・リンク
[31:28] 使用未定の4ビット
[27:16] ブロック・データ長（ヘッダ・ワードを含まない）
[15:0] tcp_block_checksum
2番目の６４ビット・ワード
[63:32] 使用未定の32ビット
[31:0] ブロックのシーケンス番号
このセクションは、ソケット特定iAPIレジスタ・マップを扱う。これらのレジスタは、与えられたソケットに特定のものである。これらのレジスタは、以下の2通りのうちの1つでアクセスされる。第1の方法は、新しいソケットが初期化されるべきときに用いられる。この場合には、Socket_Controlレジスタ(0x46)のNew_Sckビットが、アサートされる。このビットがアサートされると、TCP_Statレジスタのsck_reg_valビットがディアサートする。次に、システムが、これらのレジスタに新しいソケット情報を書き込むことができる。ソケットを確立するために、システムは、最初に、Socket_Handleレジスタを書き込む。これは、sck_reg_valビットおよびNew_Sckビットをクリアする。ソケットの制御ブロック(CB)情報が検索されると、TCP_Statusレジスタのsck_reg_valビットが、再アサートする。
First bit word
[63:62] tcp_block_size (01 = 2K, 00 = 128)
[61:59] tcp_block_type (000 = data, 001 = RST)
[58] Valid next link field
[57:32] Next block link
[31:28] Undecided 4 bits used
[27:16] Block data length (not including header word)
[15: 0] tcp_block_checksum
Second 64-bit word
[63:32] Undecided 32-bit used
[31: 0] Block sequence number This section deals with the socket specific iAPI register map. These registers are specific to a given socket. These registers are accessed in one of two ways: The first method is used when a new socket is to be initialized. In this case, the New_Sck bit of the Socket_Control register (0x46) is asserted. When this bit is asserted, the sck_reg_val bit of the TCP_Stat register is deasserted. The system can then write new socket information to these registers. To establish a socket, the system first writes a Socket_Handle register. This clears the sck_reg_val and New_Sck bits. When the socket control block (CB) information is retrieved, the sck_reg_val bit of the TCP_Status register is reasserted.
このセクションは、確立したソケットCB構造を扱う。表2は、確立したソケットに対するメモリのCB構造の全フィールドをリストしている。 This section deals with the established socket CB structure. Table 2 lists all fields of the CB structure of memory for established sockets.
表2. 確立されたソケット制御ブロック構造
表3は、HOソケットのためのメモリ内のメインCB構造を定義している。さらに、次のセクションで記述されるアネックスCBが存在する。
Table 2. Established socket control block structure Table 3 defines the main CB structure in memory for HO sockets. In addition, there is an annex CB described in the next section.
表3. ハーフ・オ−プン・ソケットのメインCB構造
表4は、HOソケットのためのメモリ内のアネックスCB構造を定義している。メインCB構造は、前のセクションで定義されている。アネックスHOCBは、メイン・セクションにはまらないオーバーフロー情報を記憶する。各HO CBは、1つのメイン・セクションおよび1つのアネックス・セクションを持っている。
Table 3. Half-open socket main CB structure Table 4 defines the in-memory Annex CB structure for HO sockets. The main CB structure is defined in the previous section. Annex HOCB stores overflow information that does not fit in the main section. Each HO CB has one main section and one annex section.
表4. ハーフ・オ−プン・ソケットのアネックスCB構造
表5は、TW状態のソケットのためのメモリ内のCB構造を定義している。
Table 4. Half Open Socket Annex CB Structure Table 5 defines the in-memory CB structure for TW sockets.
表5. タイム・ウェイト制御ブロック構造
このセクションは、TCP輻輳制御サポートを扱う。インターネット・チューナ10Gは、スロー・スタート、輻輳回避、高速再送、高速回復のアルゴリズムをインプリメントしている。
Table 5. Time Weight Control Block Structure This section deals with TCP congestion control support.
さらに、そのチューナは、同時に2つ以上のセグメントの時間を測定することをイネーブルにする往復遅延時間(round-trip time)TCPオプションをサポートしている。この特徴は、高バンド域環境のために必要である。 In addition, the tuner supports a round-trip time TCP option that enables measuring the time of two or more segments simultaneously. This feature is necessary for high band environments.
このセクションは、往復遅延時間測定を扱う。インターネット・チューナ10Gは、2通りに往復遅延時間(RTT)を測定することができる。在来の方法では、時間測定は、PSHパケットのためのACKが受信されるときのTCP PSHパケットから受け取られた。時間測定されるパケットのシーケンス番号が、CBの時間測定されるパケットフィールドのシーケンス番号に記憶され、また、そのパケットのタイム・スタンプが、CBの最後の送信フィールドのタイム・スタンプに記憶される。時間測定されるパケットのACKが受信されたとき、現在（そのとき）のタイム・スタンプと記憶されているタイム・スタンプとの間の差が、RTTである。ACKが受信されると、そのソケットCBのRTO[1]ビットがクリアされて、次のパケットの時間が測定できることを指示する。
This section deals with round trip delay time measurements. The
RTTオプションが、TCPハンドシェークの開始している状態においてネゴシエートされているときには、RTT測定は、受信された各ACKから受け取ることができる。 When the RTT option is negotiated in the beginning of the TCP handshake, RTT measurements can be received from each received ACK.
RTT測定を得るために用いられる方法がどうであっても、その値を受け取って、再送タイムアウト(RTO)値を決定する論理フローは、同じである。 Whatever method is used to obtain the RTT measurement, the logical flow of receiving that value and determining the retransmission timeout (RTO) value is the same.
計量化されて平滑化されたRTT、平均偏差、および、RTOはすべて、ソケットCBに記憶される。 The scaled and smoothed RTT, mean deviation, and RTO are all stored in socket CB.
このセクションは、スロー・スタート・アルゴリズムを扱う。ネットワーク・スタックは、すべてのTCPコネクションにスロー・スタート・アルゴリズムをサポートしている。このアルゴリズムは、ソケットが最初に確立されるときに1 MSSに初期化される輻輳ウィンドウ・パラメータ(cwnd)を用いる。 This section deals with the slow start algorithm. The network stack supports a slow start algorithm for all TCP connections. This algorithm uses a congestion window parameter (cwnd) that is initialized to 1 MSS when the socket is first established.
スロー・スタート・アルゴリズムは、ソケットが最初に確立されたとき、1つのパケットしか送り出すことができず、そのパケットのACKが受信されるまでは、それ以上のデータを送信することができないことを命令する。ACKが受信されると、cwndは、1 MSSだけ増加する。それは、2つのパケットまで送信されることを可能にする。ACKが受信される毎に、cwndは、1 MSSだけ増加する。 The slow start algorithm indicates that when a socket is first established, only one packet can be sent out and no more data can be sent until an ACK for that packet is received. To do. When ACK is received, cwnd increases by 1 MSS. It allows up to 2 packets to be transmitted. Each time an ACK is received, cwnd is incremented by 1 MSS.
これは、cwndが、ピアから通知されるウィンドウ・サイズを越えるまで継続する。これは、cwndが、ピアから通知されるウィンドウ・サイズを越えるまで継続する。ネットワーク・スタックは、常に、cwndの最小値および通知されるウィンドウを送る。 This continues until cwnd exceeds the window size advertised by the peer. This continues until cwnd exceeds the window size advertised by the peer. The network stack always sends the minimum value of cwnd and the window to be notified.
ネットワーク・スタックが、ICMP送信元喪失メッセージを受け取った場合には、それは、cwndを、1 MSSにリセットし直す。しかしながら、スロー・スタートしきい変数(ssthresh)は、その同じ値に維持される（ssthreshについてのより詳細な情報に関しては次のセクションを参照のこと）。 If the network stack receives an ICMP lost source message, it resets cwnd back to 1 MSS. However, the slow start threshold variable (ssthresh) is maintained at that same value (see the next section for more information on ssthresh).
このセクションは、輻輳回避アルゴリズムを扱う。ネットワーク・スタックは、cwndの最小値およびピアから通知されるウィンドウを送り出し続ける。輻輳回避アルゴリズムは、また、0xFFFFに初期化されるスロー・スタートしきい変数(ssthresh)を用いる。 This section deals with congestion avoidance algorithms. The network stack keeps sending out the minimum value of cwnd and the window notified by the peer. The congestion avoidance algorithm also uses a slow start threshold variable (ssthresh) that is initialized to 0xFFFF.
輻輳が、タイムアウトを介して検出されると、ssthreshは、現在の送信ウィンドウ（cwndの最小値およびピアから通知されるウィンドウ）の2分の1にセットされる。この値が、そのとき、MSSの2倍よりも小さければ、この値が、替わって用いられる。また、cwndは、1 MSSにセットされる。 If congestion is detected via a timeout, ssthresh is set to one half of the current transmission window (minimum cwnd and the window informed by the peer). If this value is then less than twice the MSS, this value is used instead. Cwnd is set to 1 MSS.
新しいデータが確認応答されると、cwndは、それがssthreshより大きくなるまで、1 MSSだけ増加する（それで、この名前がついている）。その後は、cwndが、1/cwndだけずつ増加する。これは、輻輳回避フェーズである。 As new data is acknowledged, cwnd is incremented by 1 MSS until it becomes greater than ssthresh (so it has this name). After that, cwnd increases by 1 / cwnd. This is the congestion avoidance phase.
このセクションは、高速再送アルゴリズムおよび高速回復アルゴリズムを扱う。ネットワーク・スタックが、ACKを二重に受信した場合には、それは、パケットが失われたという強い徴候である。n重に重複したパケットが受信されたら、失われたセグメントは、たとえその再送タイマがまだ満了していなかったとしても、直ちに再送される。これが、高速再送アルゴリズムである。再送信が起きる前に受信されなければならない重複ACKの数は、TCP_Dup_ACKレジスタ(0x36)を介してセットでき、3つまで不履行とされる。 This section deals with fast retransmission algorithms and fast recovery algorithms. If the network stack receives an ACK twice, it is a strong indication that the packet has been lost. If n overlapping packets are received, the lost segment is retransmitted immediately, even if its retransmission timer has not yet expired. This is a fast retransmission algorithm. The number of duplicate ACKs that must be received before a retransmission occurs can be set via the TCP_Dup_ACK register (0x36) and defaults to three.
指定された数の重複ACKパケットが受信されると、ssthreshは、輻輳回避アルゴリズムの場合がそうであったように、この場合にも、現在のウィンドウ・サイズの2分の1にセットされるが、このとき、cwndは、ssthresh + (3 * MSS)にセットされる。これは、重複ACKパケットを受信した後、スロー・スタート・アルゴリズムではなく、輻輳回避アルゴリズムに戻ることを確実にする。他の重複ACKパケットが受信されるごとに、cwndは、1 MSSずつ増加する。これが、高速回復アルゴリズムである。 When the specified number of duplicate ACK packets are received, ssthresh is still set to half the current window size, as was the case with the congestion avoidance algorithm. At this time, cwnd is set to ssthresh + (3 * MSS). This ensures that after receiving the duplicate ACK packet, it returns to the congestion avoidance algorithm rather than the slow start algorithm. Each time another duplicate ACK packet is received, cwnd increases by 1 MSS. This is a fast recovery algorithm.
新しいデータに対するACKパケットが受信されると、cwndは、ssthreshにセットされる。 When an ACK packet for new data is received, cwnd is set to ssthresh.
このセクションは、どのようにMSSオプションが導出されるかを概説する。TCP処置をイネーブルにするに先立って、ホスト・システムは、以下のパラメータおよびセッティングをセットアップしなければならない。 This section outlines how MSS options are derived. Prior to enabling TCP treatment, the host system must set up the following parameters and settings:
・レジスタ0x1A4A-0x1A4Bで用いられるデフォルト非ローカルMSS
・レジスタ0x1A4C-0x1A4Dで用いられるデフォルトローカルMSS
このセクションは、MSS選択アルゴリズムを扱う。任意のコネクションに用いるために、2つのMSS値のどちらかを選択する時、TCPエンジン・モジュールは、IPルータ・モジュール照会を行う。送信先経路がゲートウェイを通る場合には、非ローカルMSSが用いられる。
Default non-local MSS used in registers 0x1A4A-0x1A4B
Default local MSS used in registers 0x1A4C-0x1A4D
This section deals with the MSS selection algorithm. The TCP engine module performs an IP router module query when selecting one of the two MSS values to use for any connection. A non-local MSS is used when the destination route passes through a gateway.
このセクションは、サポートされているTCPオプションおよびそれらのフォーマットを概説する。サポートされている4つのオプションは、次の通りである。 This section outlines the supported TCP options and their formats. The four supported options are:
・MSS
・ウィンドウ・スケーリング
・タイム・スタンプ
SACK
・ MSS
Window scaling time stamp
SACK
このセクションは、MSSオプションを扱う。このオプションは、常に組み入れられている。用いられるMSS値は、前のセクションで説明されたアルゴリズムを通じて決定される。このオプションのフォーマットは、以下の通りである。 This section deals with MSS options. This option is always included. The MSS value used is determined through the algorithm described in the previous section. The format of this option is as follows:
このセクションは、ウィンドウ・スケーリング・オプションを扱う。ウィンドウ・スケーリング・オプションは、Sl_Win_EnビットがTCP_Controlレジスタにセットされている限り、SYNパケットに常に組み入れられる。それは、そのオプションが、SYN/ACKパケット応答を生成したSYNパケットに含まれていた場合しか、SYN/ACKパケットに組み入れられない。そのオプションのフォーマットは、以下の通りである。そのオプションが4バイト境界上にならぶように、1つのNOPバイトが、常に、それに先行することに注意されたい。 This section deals with window scaling options. The window scaling option is always included in the SYN packet as long as the Sl_Win_En bit is set in the TCP_Control register. It is only included in the SYN / ACK packet if that option was included in the SYN packet that generated the SYN / ACK packet response. The format of the option is as follows. Note that one NOP byte always precedes it so that its options are aligned on a 4-byte boundary.
このセクションは、タイム・スタンプ・オプションを扱う。このオプションは、SYNパケットに常に組み入れられ、また、そのオプションが、SYN/ACK応答を生成したSYNパケットに含まれていた場合しか、SYN/ACKパケットには組み入れられない。それは、そのオプションが4バイト境界上にならぶように、2つのNOPバイトに常に先行されることに注意してされたい。タイム・スタンプ・オプションのフォーマットは、以下の通りである。 This section deals with time stamp options. This option is always included in the SYN packet, and is only included in the SYN / ACK packet if that option was included in the SYN packet that generated the SYN / ACK response. Note that it is always preceded by two NOP bytes so that the option is aligned on a 4-byte boundary. The format of the time stamp option is as follows.
このセクションは、選択ACK(SACK)オプションを扱う。このオプションは、SACK_EnビットがTCP_Controlレジスタにセットされている限り、SYNパケットおよびSYN/ACKパケットに常に組み入れられる。SACKは、2つの相異なるTCPオプション種類を用いる。1つは、SYNパケットで用いられ、他の1つは、データ・パケットで用いられる。それらのオプションのフォーマットが、以下に示される。 This section deals with the selection ACK (SACK) option. This option is always included in SYN and SYN / ACK packets as long as the SACK_En bit is set in the TCP_Control register. SACK uses two different TCP option types. One is used in SYN packets and the other is used in data packets. The format of those options is shown below.
SACK可能
SACKオプション
SACKオプションは、1穴報告(one-hole reporting)に制限されている。
SACK possible
SACK option
The SACK option is limited to one-hole reporting.
以下のセクションは、IPルータ・モジュールを扱う。IPルータ・モジュールの特徴は、以下の通りである。 The following sections deal with IP router modules. The characteristics of the IP router module are as follows.
・デフォルトルーティング（経路制御）能力を備える。
・複数のホストIPアドレスに対するルーティングを備える。
・ホスト指定経路およびネットワーク指定経路を供給する。
・ICMPがリダイレクトした後、動的に経路を更新する。
・IPブロードキャスト（リミテッド・ブロードキャスト、サブネット・ディレクテッド・ブロードキャストおよびネットワーク・ディレクテッド・ブロードキャスト）アドレスをハンドルする。
・IPループ・バック・アドレスをハンドルする。
・IPマルチ・キャスト・アドレスをハンドルする。
-It has a default routing capability.
• Provide routing for multiple host IP addresses.
・ Supply host specified route and network specified route.
・ Updates the route dynamically after ICMP redirects.
Handle IP broadcast (limited broadcast, subnet directed broadcast and network directed broadcast) addresses.
Handles IP loop back address.
• Handle IP multicast addresses.
このセクションは、IPルータ・モジュールがどのように経路を要求するか説明する。図35に関すると、ローカル・ホスト・システムが、IPパケットを送信したいとき、それは、そのパケットをどこに送るべきであるか−そのローカル・エリア・ネットワーク上の他のホストにか、外部ネットワークにか、それとも、そのローカル・ホスト・システム自体に戻すのかのいずれかに−決めなければならない。出ていくIPパケットを適切なホストに宛てるのが、IPルータ・モジュールのタスクである。 This section describes how the IP router module requests a route. With respect to FIG. 35, when a local host system wants to send an IP packet, it should send it to-another host on that local area network, to an external network, Or you have to decide either to go back to the local host system itself. The task of the IP router module is to direct outgoing IP packets to the appropriate host.
送信モジュールが、経路を要求するとき、その送信モジュールは、パケットの送信先IPアドレスをIPルータに渡す。次に、IPルータは、ターゲットとされたIPアドレスを、IP経路リスト3520に記憶されている送信先のリストと比較する。一致が見出されると、IPルータは、適切なイーサネット・アドレスに解決しようとする。そのルータは、この解決を、ARPキャッシュ中の送信先IPアドレスに対するARPルックアップを要求することによって遂行する。送信先イーサネット・アドレスが解決されると、それは、このイーサネット・アドレスを、出ていくイーサネット・フレームの送信先として用いる送信モジュールに渡される。
When the transmission module requests a route, the transmission module passes the destination IP address of the packet to the IP router. Next, the IP router compares the targeted IP address with a list of transmission destinations stored in the
経路情報は、3つの別々の構成要素：デフォルト経路レジスタ3522、カスタム経路リスト3520、アンルータブル・アドレス・キャッシュ3526、によって供給される。これらの構成要素は全て、経路要求が出されたとき、同時に照会される。
The route information is supplied by three separate components: a
このセクションは、IPルータ・モジュールがどのようにデフォルト経路を決定するかを説明する。パケット送信先は、ローカルか外部かのどちらかであるとして記述される。ローカル送信先は、送信しているホストと同じローカル・エリア・ネットワークに配されている。外部送信先は、送信しているホストのローカル・エリア・ネットワークと別個のネットワークに属している。 This section describes how the IP router module determines the default route. The packet destination is described as either local or external. The local destination is located on the same local area network as the sending host. The external destination belongs to a network that is separate from the local area network of the sending host.
出ていくパケットの送信先IPアドレスが、ローカル・エリア・ネットワークに配されたホストに属することが見出されると、IPルータは、ARPを用いて、送信先IPアドレスを、その対応するイーサネット・アドレスに解決しようとする。送信先IPアドレスが、外部ネットワークに属すると決定されると、IPルータは、出ていくパケットを、その外部ネットワークに伝えるために、どのゲートウエイ・ホストを用いるべきであるか決めなければならない。ゲートウエイ・ホストが選択されれば、出ていくIPパケットは、それらの送信先イーサネット・アドレスとして、そのゲートウエイ・ホストのイーサネット・アドレスを用いる。IPルータ・モジュールが、パケットの送信先IPアドレスに対する経路を見出すことができない場合には、そのパケットは、デフォルト経路によって指定されるゲートウエイ・ホストを用いなければならない。デフォルト経路は、他のどんな経路も、与えられた送信先IPアドレスに対して見出すことができないときしか、用いられない。 If the destination IP address of the outgoing packet is found to belong to a host located on the local area network, the IP router uses ARP to assign the destination IP address to its corresponding Ethernet address. Try to solve. When it is determined that the destination IP address belongs to an external network, the IP router must decide which gateway host should be used to communicate outgoing packets to that external network. If a gateway host is selected, outgoing IP packets will use that gateway host's Ethernet address as their destination Ethernet address. If the IP router module cannot find a route to the destination IP address of the packet, the packet must use the gateway host specified by the default route. The default route is used only when no other route can be found for a given destination IP address.
ARPキャッシュへのアクセス数を最小限にするために、デフォルト経路がセットされたとき、IPルータ・モジュールは、デフォルト・ゲートウェイのイーサネット・アドレスをキャッシュする。デフォルト・ゲートウェイのイーサネット・アドレスは、最大で、エントリがARPキャッシュに動的にキャッシュされていることを許される時間に等しい時間量の間、キャッシュされる。 To minimize the number of accesses to the ARP cache, the IP router module caches the default gateway Ethernet address when the default route is set. The default gateway Ethernet address is cached for a maximum amount of time equal to the time allowed for an entry to be dynamically cached in the ARP cache.
このセクションは、IPルータ・モジュールが、どのようにブロードキャスト送信先とマルチ・キャスト送信先とをハンドルするかを説明する。送信先IPアドレスが、ブロードキャストIPアドレスまたはマルチ・キャストIPアドレスである場合には、ARPルックアップは、必要ではない。その代りに、IPルータ・モジュールは、IPアドレスのタイプに依存して、動的に送信先イーサネット・アドレスを生成する。IPブロードキャスト・アドレス(255.255.255.255)にセットされた送信先IPアドレスを持つパケットは、イーサネット・ブロードキャスト・アドレス(FF:FF: FF:FF)に送られる。マルチ・キャストIPアドレス(224.x.x.x)にセットされた送信先IPアドレスを持つパケットは、そのマルチ・キャストIPアドレスから計算される送信先イーサネット・アドレスを持つ。 This section describes how the IP router module handles broadcast and multicast destinations. If the destination IP address is a broadcast IP address or a multicast IP address, an ARP lookup is not necessary. Instead, the IP router module dynamically generates a destination Ethernet address depending on the type of IP address. A packet having a destination IP address set to the IP broadcast address (255.255.255.255) is sent to the Ethernet broadcast address (FF: FF: FF: FF). A packet having a destination IP address set to the multicast IP address (224.x.x.x) has a destination Ethernet address calculated from the multicast IP address.
このセクションは、IPルータ・モジュールがどのように静的経路を扱うかを説明する。デフォルト経路に加えて、IPルータ・モジュールは、送信先IPアドレスを、特定のイーサネット・インターフェイスあるいはゲートウエイ・ホストにマップするために、静的経路を生ぜしめることを可能にする。IP経路エントリには、送信先IPアドレス、ネットマスク、および、ゲートウェイIPアドレスが含まれる。ネットマスクは、一連の送信先IPアドレスを、IP経路エントリの内部に記憶された送信先IPアドレスと一致させるために用いられる。ネットマスクは、また、特定のホストの経路とネットワークの経路の区別を可能にする。ゲートウェイIPアドレスは、ARPを介して送信先イーサネット・アドレスを解決するときに用いられる。 This section describes how the IP router module handles static routes. In addition to the default route, the IP router module allows a static route to be created to map the destination IP address to a specific Ethernet interface or gateway host. The IP route entry includes a transmission destination IP address, a netmask, and a gateway IP address. The netmask is used to match a series of destination IP addresses with destination IP addresses stored inside the IP route entry. Netmasks also allow the distinction between specific host paths and network paths. The gateway IP address is used when resolving the destination Ethernet address via ARP.
IP経路リストには、多数の経路を持つことが可能であるから、IP経路エントリは、動的に割り付けられたm1メモリに記憶される。各IP経路エントリは、128ビットを用いる。各エントリの最後の32ビットは、何らのデータも記憶しないで、64ビット境界に沿ってIP経路エントリを整列させるためのパディングとして用いられる。 Since it is possible to have multiple routes in the IP route list, IP route entries are stored in dynamically allocated m1 memory. Each IP route entry uses 128 bits. The last 32 bits of each entry are used as padding to align IP route entries along a 64-bit boundary without storing any data.
各IP経路エントリのフォーマットは、以下の通りである。 The format of each IP route entry is as follows.
IP経路エントリ・フォーマット
IP経路リストは、ソートされたリンクリストとしてインプリメントされる。IP経路が、IP経路リストに加えられると、それらは、最上位に特定的なIP経路がIP経路リストの最前に現われ、最下位に特定的なIP経路がIP経路リストの最後になるように、それらのネットマスクにしたがって順序づけられる。IP経路エントリの経路ポインタ・フィールドには、次のIP経路エントリをm1メモリで見出すことができるm1メモリ・アドレスが含まれている。経路ポインタ・フィールドの最初の（最上位の）ビットは、そのm1メモリ・アドレスが有効で、かつ、現在の経路に続く経路が存在するかどうかを決定するためのフラグとして用いられる。経路ポインタ・フィールドのポインタ有効ビットが、アサートされていなければ、IP経路リストに、それ以上のIP経路が全く存在せず、IP経路リストの終端に達している。
IP route entry format
The IP route list is implemented as a sorted linked list. When an IP route is added to the IP route list, they are such that the top specific IP route appears in front of the IP route list and the bottom specific IP route is at the end of the IP route list. , Ordered according to their netmask. The route pointer field of the IP route entry contains an m1 memory address where the next IP route entry can be found in the m1 memory. The first (most significant) bit of the path pointer field is used as a flag to determine whether the m1 memory address is valid and a path following the current path exists. If the pointer valid bit in the route pointer field is not asserted, there are no more IP routes in the IP route list and the end of the IP route list has been reached.
送信先IPアドレスがブロードキャストIPアドレスまたはマルチ・キャストIPアドレスであると決定されない場合には、そのIP経路リストが、一致するIP経路エントリを求めて探索される。一致が、IP経路リストで見つからない場合には、デフォルト経路が、ゲートウェイ情報を供給するために用いられる。 If it is not determined that the destination IP address is a broadcast IP address or a multicast IP address, the IP route list is searched for a matching IP route entry. If no match is found in the IP route list, the default route is used to supply gateway information.
IPルータ・モジュールは、また、複数の物理インターフェイスおよびループ・バックインターフェイスの使用を可能にする。IP経路エントリのインターフェイス識別フィールドを用いて、IPルータは、出ていくパケットを、インターネット・チューナ10Gの特定のイーサネット・インターフェイスに向けることができる。インターフェイス識別フィールドは、また、ARP要求を、適切なイーサネット・インターフェイスに向けるためにも使用される。
The IP router module also allows the use of multiple physical interfaces and loopback interfaces. Using the interface identification field of the IP route entry, the IP router can direct outgoing packets to a specific Ethernet interface of the
このセクションは、IPルータ・モジュールが、どのようにループ・バック・アドレスをハンドルするかを説明する。送信先IPアドレスが、ローカル・ホスト・システムのIPアドレスの1つ即ちループ・バック・アドレス(127.x.x.x)と同じであれば、出ていくパケットは、ホスト・システムにフィードバックされることになっている。ループ・バック送信先の経路は、静的経路リストに記憶されている。ホスト・システムに割り当てられないIPアドレスも、ループ・バック・アドレスとして構成してもよい。このローカルリダイレクションをイネーブルにするために、インターフェイス識別は、0x0000(ループ・バック)にセットされなければならない。そうでなければ、インターフェイス識別は、イーサネット・インターフェイス(0x0001, 0x0002など)のうちの1つにセットされなければならない。 This section describes how the IP router module handles the loop back address. If the destination IP address is the same as one of the local host system IP addresses, ie the loopback address (127.xxx), the outgoing packet will be fed back to the host system. ing. The route of the loopback destination is stored in the static route list. An IP address that is not assigned to the host system may also be configured as a loopback address. To enable this local redirection, the interface identification must be set to 0x0000 (loop back). Otherwise, the interface identification must be set to one of the Ethernet interfaces (0x0001, 0x0002, etc.).
このセクションは、IPルータ・モジュールがどのように経路を作り出すかを説明する。新しいIP経路は、内部プロセッサから来ることができる。内部プロセッサによって作り出されるIP経路は、それらが、内部プロセッサによって削除されるまでテーブルに存続しているということを意味する、静的経路である。内部プロセッサは、IPルータ・モジュールのレジスタインターフェイスを介して経路を加え、また、除去する。 This section describes how the IP router module creates a route. A new IP route can come from the internal processor. IP routes created by internal processors are static routes, meaning that they remain in the table until deleted by the internal processor. The internal processor adds and removes paths through the register interface of the IP router module.
IPパケットが、間違ったゲートウエイ・ホストに送られているとき、ICMPリダイレクト・メッセージが、送信される。ICMPリダイレクト・メッセージは、普通、間違った経路のIPパケットに対して使用するために、正しいゲートウエイ・ホストの情報を含んでいる。ICMPリダイレクト・メッセージが受信されると、そのメッセージは、システム・インターフェイスによって処理される。IPルータのレジスタインターフェイスを介して経路リストを更新することは、システム・インターフェイスの責任であり、そのときに存在しているIP経路を更新し、あるいは、新しいIP経路を作り出す。 An ICMP redirect message is sent when an IP packet is being sent to the wrong gateway host. ICMP redirect messages usually contain the correct gateway host information to use for incorrect routed IP packets. When an ICMP redirect message is received, the message is processed by the system interface. It is the responsibility of the system interface to update the route list via the IP router's register interface, updating the existing IP route or creating a new IP route.
このセクションは、IPルータ・モジュールが、どのようにローカル・ネットワーク上のホストに対するルーティングをハンドルするかを説明する。ローカルイーサネットネットワーク上の他のホストにパケットを直接発送するために、インターネット・チューナ10GのサブネットマスクによってIP経路が、作り出されなければならない。この経路に対するゲートウェイとして、もう1つのホストを指定する代わりに、ゲートウェイIPアドレスは、この経路が、ローカル・ネットワークを通る直接接続に帰することを指示する0.0.0.0にセットされなければならない。
This section explains how the IP router module handles routing to hosts on the local network. In order to route packets directly to other hosts on the local Ethernet network, an IP path must be created by the subnet mask of the
このセクションは、IPルータ・モジュールが、どのように経路要求信号制御をハンドルするかを説明する。各送信モジュールは、IPルータ内に、経路要求のためのそれ自身のインターフェイスを持っている。 This section describes how the IP router module handles path request signaling control. Each sending module has its own interface for route requests within the IP router.
図36は、経路を要求し、また、受信するために用いられる信号制御を図解している。 FIG. 36 illustrates the signal control used to request and receive a path.
モジュールが、経路を要求しているとき、それは、経路要求信号(例えば、TCP_Route_Req)をアサートし、そして、ルータに送信先IPアドレス(TCP_Trgt_IP)を供給する。ルータが、経路を見出すと、それは、経路完了信号をアサートし、そして、送信先イーサネット・アドレスを出力する。経路が成功のうちに見出されると、route_valid信号が、それを送信モジュールに指示するために用いられる。経路完了信号がアサートされたときに、それがアサートされると、有効な経路が、見出されたことになる。route_validビットがアサートされないと、それは、ルーティングが、失敗だったことを意味する。これは、デフォルト・ルートやゲートウェイをダウンさせないで、かつ、ARP要求に応えないような、いくつかの原因によるものであり得る。経路失敗の場合において、その後再度、経路を待ち受け、そして、解決しようとする、あるいは、現在の接続試みを終了させることは、送信モジュールの責任である。 When the module is requesting a route, it asserts a route request signal (eg, TCP_Route_Req) and supplies the destination IP address (TCP_Trgt_IP) to the router. When the router finds a path, it asserts a path complete signal and outputs the destination Ethernet address. If the route is found successfully, the route_valid signal is used to indicate it to the sending module. When the path completion signal is asserted, if it is asserted, a valid path has been found. If the route_valid bit is not asserted, it means that routing has failed. This can be due to a number of causes that do not bring down the default route or gateway and do not respond to ARP requests. In the case of a path failure, it is then the responsibility of the sending module to wait for the path again and try to resolve it or to terminate the current connection attempt.
経路が、ホストまたはゲートウェイのイーサネット・アドレスを解決するために、ARPルックアップを必要とする場合、そのイーサネット・アドレスがARPキャッシュ内に見出されなければ、遅延を起こすことは可能である。キャッシュミスがあったとき、そのキャッシュは、IPルータに通知する。その後、ルータは、キャッシュミスが生じたことを、適切な送信器(IP TX, TCP TX, ローTX)に合図する。この時点で、送信モジュールは、現在の接続を遅らせ、キュー中の次の接続を出し、別の経路を要求することを選ぶことができる。送信構成要素が、その経路要求を取り消したとしても、ARPルックアップは継続し、そのゲートウェイが、アクティブであれば、そのイーサネット・アドレスは、後の使用を可能にするために、ARPキャッシュに加えられる。注：IPルータは、複数の出ていくARP要求を持つことができる。 If a route requires an ARP lookup to resolve a host or gateway Ethernet address, a delay can occur if the Ethernet address is not found in the ARP cache. When there is a cache miss, the cache notifies the IP router. The router then signals to the appropriate transmitter (IP TX, TCP TX, raw TX) that a cache miss has occurred. At this point, the sending module can choose to delay the current connection, issue the next connection in the queue, and request another route. Even if the sending component cancels the route request, the ARP lookup continues, and if the gateway is active, the Ethernet address is added to the ARP cache to allow later use. It is done. Note: An IP router can have multiple outgoing ARP requests.
このセクションは、IPルータ・モジュールが、どのように個々の経路の表示をハンドルするかを説明する。静的経路を作り出した後、ユーザは、経路テーブルに記憶されたエントリを、2通りに読み返すことができる。ユーザが、与えられた経路のターゲットIPアドレスを知っていれば、Show_Routeコマンドコードを用いて、その経路のネットマスクおよびゲートウェイを表示することができる。 This section describes how the IP router module handles the display of individual routes. After creating a static route, the user can read back the entries stored in the route table in two ways. If the user knows the target IP address of a given route, the Show_Route command code can be used to display the netmask and gateway for that route.
経路テーブル内の全てのエントリを表示するために、Show_Indexコマンドを用いることができる。Route_Indexレジスタを用いて、システム・インターフェイスは、特定性の順に経路にアクセスすることができる。特定性の大きい（ホスト）経路が、最初に表示され、特定性の小さい（ネットワーク）経路が、その後に続く。例えば、route_index 0x0001を備えたIP経路エントリは、IP経路リストで最も特定性の大きい経路である。注：デフォルトは、インデックス0(0x0000)に記憶される。経路が、成功のうちに見出されると、Route_Foundレジスタが、アサートされ、そして、経路データが、Route_Trgtレジスタ、Route_Maskレジスタ、および、Route_Gwレジスタに記憶される。 The Show_Index command can be used to display all entries in the route table. Using the Route_Index register, the system interface can access the routes in order of specificity. The more specific (host) route is displayed first, followed by the less specific (network) route. For example, an IP route entry with route_index 0x0001 is the route with the highest specificity in the IP route list. Note: The default is stored in index 0 (0x0000). If the route is found successfully, the Route_Found register is asserted and the route data is stored in the Route_Trgt, Route_Mask, and Route_Gw registers.
このセクションは、IPルータ・モジュールが、どのようにして解決不能の送信先のキャッシングをハンドルするかを説明する。IPルータ・モジュールが、送信先ホストまたは送信先ゲートウェイに対するイーサネット・アドレスを解決することができないとき、そのIPルータ・モジュールは、その送信先IPアドレスを20秒間キャッシュしておく。その時間の間に、IPルータ・モジュールが、それらのキャッシュされている解決不能の送信先のうちの1つに対する要求を受信すると、そのIPルータ・モジュールは、直ちに、経路を要求しているモジュールに、経路失敗で応答する。この解決不能の送信先のキャッシングは、ARPキャッシュ・エントリが記憶されている共有m1メモリへのアクセス回数を減少させるためのものである。解決不能の送信先のキャッシングは、また、冗長なARP要求を回避するのに役立つ。解決されないアドレスをキャッシュできる時間量は、Unres_Cache_Timeレジスタを介して、ユーザが構成可能である。 This section describes how the IP router module handles unresolvable destination caching. When an IP router module is unable to resolve an Ethernet address for a destination host or destination gateway, the IP router module caches the destination IP address for 20 seconds. During that time, when the IP router module receives a request for one of its cached unresolvable destinations, the IP router module immediately requests the module that is requesting the route. In response to a route failure. This unresolvable destination caching is to reduce the number of accesses to the shared m1 memory in which the ARP cache entries are stored. Unresolvable destination caching also helps to avoid redundant ARP requests. The amount of time that an unresolved address can be cached is user configurable via the Unres_Cache_Time register.
以下のセクションは、システム例外ハンドラ・モジュール1768を扱う。図37を参照すると、システム例外ハンドラ・モジュールは、インターネット・チューナ10Gの専用の処理ハードウェアが直接ハンドルすることができないデータが存在するときにはいつでも、呼び出される。このデータは、未知のイーサネット・タイプパケット、IGMPパケット、TCPオプション、あるいは、IPオプションなどであり得る。これらの場合の各々において、初期パーザが、例外の場合を検知したときに、このモジュールをイネーブルにする。その後、システム例外ハンドラ・モジュールは、データを記憶し 3742, 3746、ハンドルされるべき例外データが存在することをシステムに通信し 3744、そして、そのデータをホスト・システムに渡す 3740、責を負う。
The following section deals with the system
このセクションは、システム・インターフェイス・モジュールを扱う。システム・インターフェイス・モジュールは、システム・コントローラとインターフェイス接続している。システムに利用可能な何らかの例外データが存在するとき、それは、割り込みを介してシステムに信号で知らせる。システム・インターフェイスは、利用可能な例外データのタイプを、利用可能なデータ量とともに指示する。次に、システム・コントローラは、このモジュールを通して、そのデータを読み出すこともできるし、あるいは、このモジュールから、そのデータに対するメモリ・ポインタを得ることもできる。後者の場合には、次いで、システム・コントローラは、そのデータを直接読み出すことができる。この場合、システムは、メモリ・バッファを自由に使えるようにするために、全てのデータを読み出したときに、例外ハンドラに通信しなければならない。 This section deals with system interface modules. The system interface module interfaces with the system controller. When there is any exception data available in the system, it signals the system via an interrupt. The system interface indicates the type of exception data available along with the amount of data available. The system controller can then read the data through this module, or it can obtain a memory pointer for the data from this module. In the latter case, the system controller can then read the data directly. In this case, the system must communicate to the exception handler when all data has been read in order to free up the memory buffer.
このセクションは、Mem_Blockリクエスタを扱う。このモジュールは、メモリ・アロケータにメモリ・ブロックを要求する責を負っている。それは、また、メモリアクセス中のアドレス生成もハンドルする。ブロックが自由に使えるようになると、このモジュールは、また、それらのブロックをメモリ・アロケータに戻して渡す責も負う。このモジュールは、任意の与えられた時間に利用可能な、少なくとも1つの予備メモリ・ブロックを常に持っている。 This section deals with Mem_Block requesters. This module is responsible for requesting memory blocks from the memory allocator. It also handles address generation during memory accesses. As the blocks become free for use, this module is also responsible for passing them back to the memory allocator. This module always has at least one spare memory block available at any given time.
このセクションは、制御信号ジェネレータ・モジュールを扱う。制御信号ジェネレータ・モジュールは、メモリ・コントローラ・モジュールとインターフェイス接続して、メモリ制御信号を生成する責を負っている。このインターフェイスは、要求/授与ハンドシェークプロトコルを用いる。 This section deals with the control signal generator module. The control signal generator module is responsible for interfacing with the memory controller module and generating memory control signals. This interface uses a request / grant handshake protocol.
全ての入力信号および出力信号は、クロックの立ち上がりエッジに同期している。 All input and output signals are synchronized to the rising edge of the clock.
これは、メモリ書き込みを制御するためのFIFOである。このFIFOは、16ワード深さ（即ち、16 x 64 ビット)である。 This is a FIFO for controlling memory writing. This FIFO is 16 words deep (ie, 16 x 64 bits).
以下のセクションは、IPモジュール、ARPキャッシュ、経路テーブル、および、内部プロセッサのために用いられるメモリ・アロケータ・モジュールを詳述する。メモリ・アロケータ・モジュールは、最初にm1メモリを個別のブロックに分け、それらを要求に割り付け、そして、自由に使えるようになったブロックをスタックに戻す責を負っている。メモリ・アロケータ・モジュールは、その動作を始めるに先立って、2つのパラメータを入力される必要がある。それらは、m1メモリ・ブロックの総サイズ、および、各メモリ・ブロックのサイズである。1つのメモリサイズしか、メモリ・アロケータ・モジュールのこのインプリメンテーションにはサポートされていない。 The following sections detail the memory allocator module used for the IP module, ARP cache, route table, and internal processor. The memory allocator module is responsible for first dividing the m1 memory into individual blocks, allocating them to requests, and returning the free blocks to the stack. The memory allocator module needs to be entered with two parameters before starting its operation. They are the total size of the m1 memory block and the size of each memory block. Only one memory size is supported for this implementation of the memory allocator module.
それら2つの必要とされるパラメータが入力された後、システムは、m1_Controlレジスタのm1_Enableビットをアサートする。これが起こると、メモリ・アロケータ・モジュールは、m1メモリ・ブロックのトップからスタートして、ブロック・アドレスを書き込み始める。例えば、m1メモリ・ブロックが、総計4キロバイト深さであり、 ブロックサイズが、512バイトであれば、m1メモリ・マップは、図38に示されるようになる。 After these two required parameters are entered, the system asserts the m1_Enable bit of the m1_Control register. When this happens, the memory allocator module starts writing the block address starting from the top of the m1 memory block. For example, if the m1 memory block has a total depth of 4 kilobytes and the block size is 512 bytes, the m1 memory map is as shown in FIG.
m1ブロック・アドレスのm1アドレス位置当り、4つのアドレスが、保持される。メモリに開始ブロック・アドレスを保持することに加えて、メモリ・アロケータ・モジュールは、また、16-エントリキャッシュも含有する。初期化に際して、最初の16アドレスが、キャッシュに保持される。ブロックが要求されたとき、それらは、キャッシュから受け取られる。キャッシュ数が0に達したとき、4つのアドレス（1メモリ読み出し）が、メモリから読み出される。さらに、キャッシュが、アドレスで一杯になったときには常に、4つのアドレスが、メモリに書き戻される（これは、メモリ・アロケータ・モジュールが、一番初めにm1メモリからアドレスを読み出した後でしか作用しない）。 Four addresses are retained per m1 address location of the m1 block address. In addition to keeping the starting block address in memory, the memory allocator module also contains a 16-entry cache. Upon initialization, the first 16 addresses are held in the cache. When blocks are requested, they are received from the cache. When the number of caches reaches 0, four addresses (one memory read) are read from the memory. In addition, whenever the cache is full of addresses, four addresses are written back to memory (this only works after the memory allocator module first reads the address from m1 memory). do not do).
このセクションは、TX, RX, CBメモリ・アロケータ・モジュールを扱う。これらのメモリ・アロケータ・モジュールは、ソケット送信メモリ(malloctx)、ソケット受信メモリ(mallocrx)、および、CB(malloccb)メモリに対して用いられるメモリ・アロケータである。これらのメモリ・アロケータ・モジュールは、メモリ・ブロックを要求に割り付け、自由に使えるようになったブロックをスタックに戻し、そして、メモリの使用を調停する責を負っている。 This section deals with TX, RX and CB memory allocator modules. These memory allocator modules are memory allocators used for socket transmit memory (malloctx), socket receive memory (mallocrx), and CB (malloccb) memory. These memory allocator modules are responsible for allocating memory blocks to requests, returning free blocks to the stack, and arbitrating memory usage.
メモリ・アロケータ・モジュールは、動作を開始するに先立って、いくつかのパラメータを入力される必要がある。これらのパラメータは、MPメモリ空間内の開始アドレス・ポインタ位置および終了アドレス・ポインタ位置、および、各メモリ空間内の利用可能な各ブロックを表わすビット・マップである。2つのサイズのブロックが、ソケット・データ・メモリに利用可能である：128バイトおよび2キロバイト。CBメモリは、128バイトに固定したブロックを持っている。全てのアロケータは、また、ブロック・アドレス（各メモリサイズに対する）に対して8-エントリキャッシュを利用する。 The memory allocator module needs to be entered with some parameters prior to starting operation. These parameters are a bit map representing the start and end address pointer locations in the MP memory space and each available block in each memory space. Two sizes of blocks are available for socket data memory: 128 bytes and 2 kilobytes. CB memory has a fixed block of 128 bytes. All allocators also utilize an 8-entry cache for block addresses (for each memory size).
これらのパラメータが入力された後、システムは、制御レジスタにイネーブル・ビットをアサートする。そうすると、アロケータは、メモリ・ブロックの割り付け、および、割り付けの解放を開始することができる。 After these parameters are entered, the system asserts an enable bit in the control register. The allocator can then begin allocating the memory block and releasing the allocation.
このセクションは、TX SDRAMインターフェイスおよびデータ・フローを扱う。コアロジックのアービトレータは、TX SDRAMへの読み出しサイクルか、書き込みサイクルか、どちらかに決める。1つのサイクルが始まれば、それは、完結させられる。TX SDRAMに書き込まれているデータは、PCIバスとデータ・メモリとの間にある128 x 128ビットFIFOペアから来る。TXデータ・メモリから読み出されたデータが、MACモジュールとインターフェイス接続している64 x 128ビットFIFOに入れられる。 This section covers the TX SDRAM interface and data flow. The core logic arbitrator decides either the read cycle or the write cycle for TX SDRAM. Once a cycle begins, it is completed. Data written to TX SDRAM comes from a 128 x 128 bit FIFO pair between the PCI bus and data memory. Data read from the TX data memory is placed in a 64 x 128-bit FIFO interfaced with the MAC module.
このセクションは、512キロバイト雑メモリバンクを詳述する。雑メモリバンクは、以下にリストされた目的のために使用される。それらの特徴は、他のところで詳細に記述されている。 This section details the 512 KB miscellaneous memory bank. The miscellaneous memory bank is used for the purposes listed below. Their features are described in detail elsewhere.
・ハーフ・オ−プンCB（メイン）
・ハーフ・オ−プンCB（アネックス）
・TCPポート許可テーブル
・UDPポート許可テーブル
・送信元ポート使用テーブル
・タイム・ウェイトCB割り付けテーブル
・確立されたCB割り付けテーブル
・TXメモリ・ブロック割り付けテーブル（128バイト・ブロックと2キロバイト・ブロックとの両方に対する）
・RXメモリ・ブロック割り付けテーブル（128バイト・ブロックと2キロバイト・ブロックとの両方に対する）
・TCP RXからTCP TXへのパケットに対するFIFO
・ソケット・データ使用可能ビット・マップ
・サーバ・ポート情報
・ Half open CB (main)
・ Half open CB (Annex)
-TCP port permission table-UDP port permission table-Source port usage table-Time wait CB allocation table-Established CB allocation table-TX memory block allocation table (both 128 byte block and 2 kilobyte block) Against)
RX memory block allocation table (for both 128 byte blocks and 2 kilobyte blocks)
FIFO for packets from TCP RX to TCP TX
・ Socket ・ Data available bit map ・ Server ・ Port information
このセクションは、雑メモリの編成および性能を扱う。図39を参照すると、この雑メモリは、物理的に256k x 16ビットとして編成されているが、この雑メモリを用いるモジュールの大部分は、この雑メモリを、あたかも、それが512k x 8ビットメモリであるかのように載せる。これは、全ての許可テーブルおよびアロケーションテーブルが、一度に1バイトしかメモリにアクセスする必要がないからである。HO CBデータ・パス、および、TCP RXからTCP TXに対するFIFO、および、サーバ・ポート情報は、フル16ビット・データ・パスを利用するリソースである。16ビット・データ・パスの必要性は、非常にわずかのクロック・サイクル内でデータにアクセスしなければならないHO CBから生じる。雑メモリは、単一サイクルメモリを用いてインプリメントされなければならない。性能要求は高くないが、アービトレーション・オーバヘッドのために、アクセス時間は、できるだけ短く保たれるべきである（ここでも、HO CBのために）。 This section deals with the organization and performance of miscellaneous memory. Referring to FIG. 39, this miscellaneous memory is physically organized as 256k x 16 bits, but most of the modules that use this miscellaneous memory treat this miscellaneous memory as if it were 512k x 8 bit memory Put it as if. This is because all grant tables and allocation tables only need to access memory one byte at a time. The HO CB data path, FIFO from TCP RX to TCP TX, and server port information are resources that utilize the full 16-bit data path. The need for a 16-bit data path arises from HO CBs that have to access data within very few clock cycles. The miscellaneous memory must be implemented using a single cycle memory. Although performance requirements are not high, due to arbitration overhead, the access time should be kept as short as possible (again, for HO CB).
・HOCB（メイン）3902。これらは、HO TCPコネクションのCBである。各CBは、サイズとして32バイトであり、合計4,000のCBがある。したがって、それらのHO CBに必要なバイトの合計数は、4キロバイト x 32 = 128キロバイトである。このリソースは、フル16ビット・データ・バスを用いる。 ・ HOCB (main) 3902. These are CBs for HO TCP connections. Each CB is 32 bytes in size, for a total of 4,000 CBs. Therefore, the total number of bytes required for those HO CBs is 4 kilobytes x 32 = 128 kilobytes. This resource uses a full 16-bit data bus.
・HOCB（アネックス）3984。これらは、HO TCPコネクションのCBで、CBのメイン部にはまらなかった、補足情報を含んでいる。各アネックスCBは、サイズとして16バイトであり、合計4,000のアネックスCBがある。したがって、それらのHO CBに必要なバイトの合計数は、4,000 x 16バイト = 64キロバイトである。このリソースは、フル16ビット・データ・バスを用いる。 ・ HOCB (Annex) 3984. These are CBs for HO TCP connections and contain supplementary information that did not fit in the main part of the CB. Each annex CB is 16 bytes in size, and there are a total of 4,000 annex CBs. Therefore, the total number of bytes required for those HO CBs is 4,000 x 16 bytes = 64 kilobytes. This resource uses a full 16-bit data bus.
・TCPポート許可テーブル3900。このテーブルは、どのTCPポートが、コネクションをを受け取ることを許可されるかを追跡する。64,000の可能なポートの各々の1ビットが、保持されている。したがって、このテーブルは、64,000ビット/8 = 8キロバイトを用いる。 TCP port permission table 3900. This table keeps track of which TCP ports are allowed to receive connections. One bit of each of 64,000 possible ports is retained. Therefore, this table uses 64,000 bits / 8 = 8 kilobytes.
・UDPポート許可テーブル3998。このテーブルは、どのUDPポートが、コネクションを受け取ることを許可されるかを追跡する。64,000の可能なポートの各々の1ビットが、保持されている。したがって、このテーブルは、64,000ビット/8 = 8 キロバイトを用いる。 -UDP port permission table 3998. This table keeps track of which UDP ports are allowed to receive connections. One bit of each of 64,000 possible ports is retained. Therefore, this table uses 64,000 bits / 8 = 8 kilobytes.
・送信元ポート使用テーブル3996。このテーブルは、どのポート番号が、ローカルに着手されるコネクションに用いられる送信元ポートに利用可能であるかを追跡する。64,000の可能なポートの各々の1ビットが、保持されている。したがって、このテーブルは、64,000ビット/8 = 8キロバイトを用いる。 Source port usage table 3996. This table tracks which port numbers are available for the source port used for the locally initiated connection. One bit of each of 64,000 possible ports is retained. Therefore, this table uses 64,000 bits / 8 = 8 kilobytes.
・TWCB割り付けテーブル3988。これは、TW CBのための割り付けテーブルである。32,000のTW CBの各々に対して1ビットが、保持されている。したがって、この割り付けテーブルは、32,000ビット/8 = 4 キロバイトを用いる。このテーブルは、フル16ビット・データ・バスを用いる。 ・ TWCB allocation table 3988. This is the allocation table for TW CB. One bit is held for each of 32,000 TW CBs. Therefore, this allocation table uses 32,000 bits / 8 = 4 kilobytes. This table uses a full 16-bit data bus.
・確立されたCB割り付けテーブル3994。これは、確立されたCBのための割り付けテーブルである。64,000のCBの各々に対して1ビットが、保持されている。したがって、この割り付けテーブルは、64,000ビット/8 = 8キロバイトを用いる。 -Established CB allocation table 3994. This is an allocation table for established CBs. One bit is retained for each of 64,000 CBs. Therefore, this allocation table uses 64,000 bits / 8 = 8 kilobytes.
・TXソケット・データ・バッファブロック割リ付けテーブル3982。このテーブルは、2キロバイト・ブロック割リ付けテーブルと128バイトブロック割り付けテーブルとから構成され、動的に割り付けられる送信データ・バッファ・メモリに使用される。各タイプのブロック数は、構成可変であるが、組み合わされた両方の割り付けテーブルのサイズは、72 キロバイトに固定される。これには、最大で475,000の128バイト・ブロックを充てることが許可されている。このレベルで、2キロバイト・ブロックの数は、98,000である。 TX socket data buffer block allocation table 3982. This table is composed of a 2 kilobyte block allocation table and a 128 byte block allocation table, and is used for a dynamically allocated transmission data buffer memory. The number of blocks of each type is variable, but the size of both combined allocation tables is fixed at 72 kilobytes. This allows up to 475,000 128-byte blocks to be allocated. At this level, the number of 2 kilobyte blocks is 98,000.
・RXソケット・データ・バッファブロック割リ付けテーブル3980。このテーブルは、2キロバイト・ブロック割リ付けテーブルと128バイトブロック割り付けテーブルとから構成され、動的に割り付けられる受信データ・バッファ・メモリに使用される。各タイプのブロック数は、構成可変であるが、組み合わされた両方の割り付けテーブルのサイズは、72 キロバイトに固定される。これには、最大で475,000の128バイト・ブロックを充てることが許可されている。このレベルで、2キロバイト・ブロックの数は、98,000である。 RX socket data buffer block allocation table 3980. This table is composed of a 2 kilobyte block allocation table and a 128 byte block allocation table, and is used for a dynamically allocated receive data buffer memory. The number of blocks of each type is variable, but the size of both combined allocation tables is fixed at 72 kilobytes. This allows up to 475,000 128-byte blocks to be allocated. At this level, the number of 2 kilobyte blocks is 98,000.
・TCPRX FIFO 3990。このFIFOは、TCP受信ロジックからTCP送信ロジックへのパケット送信要求を追跡するために用いられる。各FIFOエントリは、いくつかの制御フラグおよび1つのCBアドレスから構成され、合計4バイト(4つのフラグ、26ビットのアドレス、および、未使用の2ビット)である。このFIFOは、1024ワード深さで、したがって、1024 x 4バイト = 4キロバイトを必要とする。
•
・ソケット・データ利用可能ビット・マップ 3992。このビット・マップは、64,000のソケットのどれが、ホスト・システムに送られる準備ができているデータを持っているかを表わす。ソケットの各々に対して1ビットが、保持されている。したがって、このビット・マップは、64,000ビット/8 = 8 キロバイトを必要とする。
Socket data
・サーバ・ポート情報3986。このデータベースは、待機状態にオープンされているTCPポートのパラメータ情報を記憶するために用いられる。それらのサーバ・ポートは、それらがオープンされるまで、それらに連係するCBを持たないから、ポートに特定のパラメータが、このエリアに保持される。各ポートエントリは、2バイトから構成され、64,000の可能なポートがある。したがって、このデータベースは、64,000 x 2バイト = 128 キロバイトを必要とする。
-
このセクションは、雑メモリ・マップを扱う。雑メモリに使用されるメモリ・マップは、構成可変である。 This section deals with miscellaneous memory maps. The memory map used for miscellaneous memory is variable.
このセクションは、雑メモリ（即ちmiscmem）アービトレーションスキームを扱う。雑メモリ・アロケータは、さまざまな送信元からメモリ要求を受け取り、メモリ・ブロックへのアクセスについて、それらのメモリ要求間の調停をする。すべての要求のうち、HO CBへのアクセスに対するメモリサイクルが、最優先順位を与えられる。他のすべての送信元は、ラウンドロビン態様で、等しい優先順位に調停される。 This section deals with miscellaneous memory (ie miscmem) arbitration schemes. The miscellaneous memory allocator receives memory requests from various sources and arbitrates between the memory requests for access to the memory block. Of all requests, the memory cycle for access to the HO CB is given the highest priority. All other sources are arbitrated to equal priority in a round robin manner.
雑メモリアービトレータをアクティブにするのに先立って、内部プロセッサが初期化する必要のあることは、ほとんどない。デフォルト・メモリ・マップが、用いられるべきときには、内部プロセッサは、MiscMem_ControlレジスタのMM_Enableビットをアサートすることによって、アービトレータを簡単にイネーブルにすることができる。 There is very little that the internal processor needs to initialize prior to activating the miscellaneous memory arbitrator. When the default memory map is to be used, the internal processor can simply enable the arbitrator by asserting the MM_Enable bit in the MiscMem_Control register.
非デフォルト・メモリ・マップが、用いられるべきときには、基準アドレス・レジスタはすべて、アービトレータをイネーブルにするに先立って、初期化されなければならない。プログラムされた基準アドレスが、何らの重複するメモリエリアを引き起こさないことを保証するのは、ソフトウェアの責任である。これをチェックするどんなハードウェアも、用意されない。 When a non-default memory map is to be used, all reference address registers must be initialized prior to enabling the arbitrator. It is the software's responsibility to ensure that the programmed reference address does not cause any overlapping memory areas. No hardware to check this is provided.
内部プロセッサは、雑メモリ内のどの位置にもアクセスすることができる。最初に、MM_CPU_Addレジスタ(0x1870―0x1872)内の1つのアドレスにプログラムし、次に、MM_CPU_Dataレジスタ(0x1874)に1バイトを読み出すか、または、書き込むことによって、これがなされる。アドレス・レジスタは、データ・レジスタがアクセスされる度毎に、自動的にインクリメントする。 The internal processor can access any location in the miscellaneous memory. This is done by first programming to one address in the MM_CPU_Add register (0x1870-0x1872) and then reading or writing one byte to the MM_CPU_Data register (0x1874). The address register automatically increments every time the data register is accessed.
このセクションは、シリアル・ポート、SPI、および、テスト・インターフェイスを扱う。AUXシリアル・ポートは全て、標準の8ビット・シリアル・データ・フォーマットを用いる。シリアル・ポートは、16バイト受信FIFOおよびハードウェアフローの制御をサポートする。内部プロセッサが、全てのポート上で用いられるボーレートを制御し、それによって、全てのポートが、独立したボーレートをサポートすることができる。シリアル・ポート・テストモードは、内部プロセッサのテストモード・レジスタ(0x0000f0)にser_tstビットをセットすることにより、イネーブルとされる。オンチップ・プロトコル・プロセッサが、スレーブ（従）SPIデバイスを制御することができるように、マスター（主）SPIポートが設けられる。 This section covers the serial port, SPI, and test interface. All AUX serial ports use the standard 8-bit serial data format. The serial port supports 16 byte receive FIFO and hardware flow control. An internal processor controls the baud rate used on all ports, so that all ports can support independent baud rates. The serial port test mode is enabled by setting the ser_tst bit in the internal processor test mode register (0x0000f0). A master (primary) SPI port is provided so that the on-chip protocol processor can control the slave (slave) SPI device.
このセクションは、システムで用いられる割り込みコントローラ(INTC) 1688の概要を提供する。INTCは、全システム割り込みを集めて、それらを、内部プロセッサに流し込む。各割り込み元を、内部プロセッサ上でnFIQ割り込みかnIRQ割り込みかの一方に独立に導くことができる。 This section provides an overview of the interrupt controller (INTC) 1688 used in the system. INTC collects all system interrupts and flows them into the internal processor. Each interrupt source can be independently routed to either an nFIQ interrupt or an nIRQ interrupt on the internal processor.
このセクションは、インターネット・チューナ10Gで用いられる多目的タイマおよび監視タイマの概要を提供する。前のタイマと縦続接続されていてもよいし、あるいは、独立に用いられてもよい、8つの多目的32ビットタイマが、設けられる。全てのタイマが、単発モードか、あるいは、ループ（繰り返し）モードで動作することができる。さらに、メインのコアクロックを、それが各々のタイマによって用いられるのに先だって、分周できるクロック・プレスケーラが、設けられる。これは、異なるコアクロック周波数の変化を最小にする。
This section provides an overview of the multipurpose timers and watchdog timers used in
このセクションは、コマンド・ブロック構造を詳述する。ホスト・システムは、コマンド・ブロックを用いて、コマンドをインターネット・チューナ10Gに渡す。コマンドは、ステータスを要求したり、ソケットを制御したり、データを送ったり、ホスト状態を報告したりすることを、含むことができる。コマンド・ブロックは、通例、DMAを用いてホスト・システムから転送される。インターネット・チューナ10Gが、コマンドを受信すると、それらのコマンドは、コマンドリストに入れられる。次に、コマンドは、コマンド・パーザ・モジュールによって、一度に1つ、構文解析される。次いで、コマンド・パーザ・モジュールが理解したコマンド・ブロックのどれをも、コマンド・パーザ・モジュールが、実行する。コマンド・パーザ・モジュールが、どのようにデコードするのか分からないコマンド・ブロックのどれをも、コマンド・パーザ・モジュールは、内部プロセッサに送る。
This section details the command block structure. The host system uses the command block to pass the command to the
コマンド・ブロックは、長さが可変である。コマンドのタイプにかかわらず、各コマンド・ブロックは、偶数のバイトから構成されなければならない。奇数バイト・コマンド・ブロックには全て、パディング・バイトが、用いられなければならない。 The command block is variable in length. Regardless of the type of command, each command block must consist of an even number of bytes. For all odd byte command blocks, padding bytes must be used.
ホストとインターネット・チューナ10Gとの間にコマンド・ブロック通信をインプリメントするときには、特別の注意を払わなくてはならない。コマンド・ブロックは、ホストメモリ内に循環キューで作り出される。その後、周期的に、あるいは、ホストの手引きによって、これらのコマンド・ブロックは、DMAを用いてインターネット・チューナ10Gに転送される。ホスト・システムとインターネット・チューナ10Gとの間の信頼できる通信を確実にするために、いくつかの手続きが続く必要がある。
Special care must be taken when implementing command block communication between the host and the
このセクションは、受信コマンド・ブロックについて説明し、また、内部プロセッサが、ホスト・システムからコマンド・ブロックを受け取るために通過しなければならないステップの要点を述べる。 This section describes the received command block and outlines the steps that an internal processor must go through to receive a command block from the host system.
・内部プロセッサは、受け取ったコマンド・ブロックをハードウェアに記憶させたいメモリ領域を割り付けなければならない。 The internal processor must allocate a memory area where the received command block is to be stored in hardware.
・このメモリの開始アドレスが、Cmd_Addレジスタにプログラムされなければならない。 • The start address of this memory must be programmed into the Cmd_Add register.
・このバッファの長さが、Cmd_FIFO_Lenレジスタにプログラムされなければならない。 • The length of this buffer must be programmed into the Cmd_FIFO_Len register.
・コマンド・ブロックが利用可能なときに、内部プロセッサが、割り込みを介して通知してもらいたければ、それは、Cmd_Stat_ControlレジスタにCmd_Int_Enビットをセットしなければならない。 If the internal processor wants to be notified via an interrupt when a command block is available, it must set the Cmd_Int_En bit in the Cmd_Stat_Control register.
・これがすべて入力されたとき、内部プロセッサは、Cmd_Stat_ControlレジスタにCmd_Enビットをアサートする。このビットのセッティングは、ハードウェア・コマンド・パーザが、コマンドを内部プロセッサに渡し始めることをイネーブルにする。このビットがアサートされる前に、ハードウェアパーザがコマンド・ブロックを受け取ったら、そのハードウェアパーザは、そのコマンド・ブロックを黙って破棄する。 When this is all input, the internal processor asserts the Cmd_En bit in the Cmd_Stat_Control register. Setting this bit enables the hardware command parser to begin passing commands to the internal processor. If the hardware parser receives a command block before this bit is asserted, the hardware parser silently discards the command block.
・ハードウェアが、コマンド・ブロックを受信すると、そのハードウェアは、Cmd_Addレジスタによって指定されたバッファに、それらを記憶し始める。ハードウェアが、内部プロセッサメモリへのコマンド・ブロックの書き込みを完了した後、そのハードウェアは、Cmd_Stat_StatレジスタにCmd_Recビットをアサートする。Cmd_Recビットがアサートされてしまった後、さらなるコマンド・ブロックが受け取られたら、ハードウェアは、内部プロセッサによって指定されたFIFOに、それらの書き込みを継続する。 When the hardware receives the command blocks, it starts storing them in the buffer specified by the Cmd_Add register. After the hardware completes writing the command block to the internal processor memory, the hardware asserts the Cmd_Rec bit in the Cmd_Stat_Stat register. If additional command blocks are received after the Cmd_Rec bit has been asserted, the hardware continues to write them to the FIFO specified by the internal processor.
・それがFIFOの終端まで達したら、アドレスは、始点（Cmd_Addレジスタによって指定される）に周回する。 When it reaches the end of the FIFO, the address wraps around to the start point (specified by the Cmd_Add register).
・内部プロセッサは、それが、提出される全てのコマンド（Cmd_Rec_Lenレジスタによって指定される）を読み出して処理したときでなければ、Cmd_Recビットをクリアしてはいけない。Cmd_Recビットがクリアされるまで、ハードウェアは、それらのFIFO位置に重ね書きしない。したがって、Cmd_Recビットをクリアすることは、新しいコマンドのためにそれらのメモリ位置を再使用することができるハードウェアパーザに対するACKとして働く。 • The internal processor must not clear the Cmd_Rec bit unless it has read and processed all submitted commands (specified by the Cmd_Rec_Len register). The hardware does not overwrite those FIFO locations until the Cmd_Rec bit is cleared. Thus, clearing the Cmd_Rec bit serves as an ACK to the hardware parser that can reuse those memory locations for new commands.
このセクションは、ステータス・ブロック構造を詳述する。インターネット・チューナ10Gは、ステータス・ブロックを用いて、システムに情報を戻し渡す。ステータスは、受信されたデータの報告から、例外事例、エラー状態、あるいは、接続統計に及ぶことができる。ステータス・ブロックは、通例、DMAを用いてホスト・システムに転送される。インターネット・チューナ10Gは、最初に、ステータスコマンド・ブロックのリストを生成する。さまざまな元がステータス・メッセージを生成することができ、また、それらのステータス・メッセージは全て、1つのマスターステータス・メッセージ・ジェネレータに流し込まれる。これらのメッセージは、メッセージリストに入れられ、その後、送信DMAエンジン・モジュールに利用可能になる。
This section details the status block structure. The
ステータス・メッセージ・ブロックは、長さが可変で、以下のようなフィールド構造を持っている。ステータスのタイプにかかわらず、各ブロックは、偶数バイトから構成されなければならない。奇数バイト・ステータス・メッセージ・ブロックには、全て、パディング・バイトが、用いられなければならない。 The status message block is variable in length and has the following field structure. Regardless of the status type, each block must consist of an even number of bytes. All padding bytes must be used for odd byte status message blocks.
ステータス・ブロックハンドリングのホスト側インプリメントは、コマンド・ブロックメカニズムを補完する。適切なインプリメントが、正しい動作のために付けられなければならない。不適当なインプリメントは、行き詰まった状況に導くことがある。 The host side implementation of status block handling complements the command block mechanism. Appropriate implementation must be applied for correct operation. Improper implementation can lead to deadlocks.
ステータス・ブロック循環キューは、ホストメモリ内に作り出され、また、インターネット・チューナ10Gは、その開始(statqstart)アドレスおよびその終了(statqend)アドレスを付けて構成される。したがって、ステータス・ブロックは、周期的に、あるいは、要求に応じて、DMAを用いて、インターネット・チューナ10Gハードウェアから、このキューに転送される。
A status block circular queue is created in the host memory, and the
このセクションは、ステータス・メッセージを送る動作について説明し、内部プロセッサが、ステータス・メッセージをホスト・システムに送り返すために通過しなければならないステップを詳述する。 This section describes the operation of sending status messages and details the steps that an internal processor must go through to send status messages back to the host system.
・内部プロセッサは、メッセージ・ブロックを作り出して、それらのメッセージ・ブロックを、メモリ空間の連続的なセクションに入れなければならない。 The internal processor must create message blocks and place them in successive sections of memory space.
・このメモリ空間の開始アドレスが、Stat_Addレジスタ内にプログラムされる。 • The start address of this memory space is programmed into the Stat_Add register.
・ステータス・メッセージの全長が、Stat_Lengthレジスタ内にプログラムされる。 • The total length of the status message is programmed into the Stat_Length register.
・内部プロセッサは、ステータス・メッセージがホスト・システムに転送され終わったときについて、割り込みを介して通知してもらいたい場合には、Cmd_Stat_Int_EnレジスタにStat_Int_Enビットをセットしなければならない。 • The internal processor must set the Stat_Int_En bit in the Cmd_Stat_Int_En register if it wants to be notified via an interrupt when the status message has been transferred to the host system.
・これが全て、初期化されたときに、内部プロセッサは、Cmd_Stat_ControlレジスタにSend_Statビットをアサートする。このビットのセッティングによって、ホスト・システムに渡すために内部プロセッサによって生成されたステータス・メッセージが存在するということが、ハードウェアに通知される。 When this is all initialized, the internal processor asserts the Send_Stat bit in the Cmd_Stat_Control register. Setting this bit informs the hardware that there is a status message generated by the internal processor to pass to the host system.
・ハードウェアは、内部プロセッサ状態メッセージの送信を完了したとき、Cmd_Stat_ControlレジスタのSend_Statビットをクリアし、Cmd_Stat_StatレジスタにStat_Sentビットをセットする。 When the hardware completes the transmission of the internal processor status message, the hardware clears the Send_Stat bit in the Cmd_Stat_Control register and sets the Stat_Sent bit in the Cmd_Stat_Stat register.
・Stat_Int_Enビットもセットされていたら、ステップ番号6は、また、内部プロセッサ割り込みのトリガもする。
• If the Stat_Int_En bit is also set,
ここから、もし望めば、内部プロセッサが、新しいステータス・メッセージを入力する。 From here, if desired, the internal processor enters a new status message.
本明細書において、本発明が、好適な実施例に関して記述されているが、当業者であれば、他の応用が、本発明の精神および範囲から逸脱することなく、本明細書に説明されている応用に置き換えることのできるものであることが容易に認識される。したがって、本発明は、以下に含まれる請求項によってしか制限されるべきではない。 Although the invention has been described herein with reference to preferred embodiments, other applications will be described by those skilled in the art without departing from the spirit and scope of the invention. It can be easily recognized that it can be replaced by an existing application. Accordingly, the invention should be limited only by the claims included below.
1752 TCPモジュール
1758 IPモジュール
1762 ARPモジュール
1766 イーサネット・インターフェイス・モジュール
1770 イーサネットMACインターフェイス・モジュール
1890 ARP送信スケジューラ
1896 イーサネット受信モジュール
2062 IPヘッダ・フィールド構文解析モジュール
2064 IP分割モジュール
2180 ICMPエコー応答受信モジュール
2182 ICMPエコー応答プロセッサ・モジュール
2500 VSOCKモジュール・メモリ・アロケータ・モジュール
2830 RSTパケット・ジェネレータ・モジュール
2832 受信状態ハンドラ・モジュール
2834 VSOCKモジュール
2841 SYN/ACKパケット・ジェネレータ・モジュール
2842 NATとIPマスカレーディング・モジュール
3350 パケット・スケジューラ
3352 ソケット送信ハンドラ・モジュール
1752 TCP module
1758 IP module
1762 ARP module
1766 Ethernet interface module
1770 Ethernet MAC interface module
1890 ARP transmission scheduler
1896 Ethernet receiver module
2062 IP header field parsing module
2064 IP split module
2180 ICMP echo response receiving module
2182 ICMP Echo Reply Processor Module
2500 VSOCK module memory allocator module
2830 RST packet generator module
2832 Receive state handler module
2834 VSOCK module
2841 SYN / ACK packet generator module
2842 NAT and IP Masquerading Module
3350 packet scheduler
3352 Socket Send Handler Module
Claims (91)
パケットを受信および送信し、また、パケットをエンコードおよびデコードするためのネットワークスタックと、
複数の専用ハードワイヤードロジックプロトコルモジュールと、
を有する装置において、
当該プロトコルモジュールが、並列実行を行い、
当該プロトコルモジュールが、受領状態ハンドラモジュールを含み、
当該受領状態ハンドラモジュールが、
リセット（ＲＳＴ）パケットの生成、
アクノレッジメントパケットとの同期（ＳＹＮ／ＡＣＫ）の生成、
同期パケット（ＳＹＮ）の生成、
終了パケット（ＦＩＮ）の生成、
終了／アクノレッジメントパケット（ＦＩＮ／ＡＣＫ）の生成及び
リセット／アクノレッジメントパケット（ＲＳＴ／ＡＣＫ）の生成
の何れかを含む、ＴＣＰネットワークパケットに自動的に応答する
装置。 A device for decoding and encoding network protocols to process data,
A network stack for receiving and transmitting packets and for encoding and decoding packets;
Multiple dedicated hardwired logic protocol modules;
In a device having
The protocol module performs parallel execution,
The protocol module includes a receipt status handler module,
The receipt status handler module
Generation of reset (RST) packets;
Generation of synchronization with the acknowledgment packet (SYN / ACK),
Generation of a synchronization packet (SYN),
Generation of an end packet (FIN),
A device that automatically responds to TCP network packets, including either generation of termination / acknowledgment packets (FIN / ACK) and generation of reset / acknowledgment packets (RST / ACK).
複数の専用ハードワイアドロジックプロトコールモジュールと
を有する、ネットワークプロトコールをデコードしかつエンコードし、かつデータを処理する装置であって、
各プロトコールモジュールが、特定のネットワークプロトコールに最適化され、
当該プロトコールモジュールが、並列実行を行い、
当該プロトコールモジュールが、ＴＣＰプロトコールモジュールを含み、
当該TCPプロトコールモジュールが、最適化されたハードワイヤードロジックを用いて、周回シーケンス番号(PAWS)に対するTCP保護をサポートする、装置。 A network stack for receiving and transmitting packets and encoding and decoding packets;
An apparatus for decoding and encoding a network protocol and processing data, comprising a plurality of dedicated hardwired logic protocol modules;
Each protocol module is optimized for a specific network protocol,
The protocol module performs parallel execution,
The protocol module includes a TCP protocol module;
A device in which the TCP protocol module supports TCP protection against circular sequence numbers (PAWS) using optimized hard-wired logic.
当該IPルータモジュールが、
ネットワークアドレス中継のためのハードウェアを含むデフォルトIP経路制御能力と、
複数のホストIPアドレスに対する経路制御と、
ホスト指定経路およびネットワーク指定経路に対する経路制御と、
ICMPリダイレクトパケットメッセージ受信後の経路制御情報の動的な更新と、
リミテッドブロードキャスト、サブネットディレクテッドブロードキャストおよびネットワークディレクテッドブロードキャストを含むが、それらに制限されないIPブロードキャストアドレスを伴う経路制御と、
ループバックIPアドレスを伴う経路制御と、
IPマルチキャストアドレスを伴う経路制御と、
のうちの任意の1つ以上を遂行する請求項１に記載の装置。 An apparatus further comprising an IP router module,
The IP router module
Default IP routing capability including hardware for network address relay,
Routing for multiple host IP addresses,
Route control for host-specified routes and network-specified routes;
Dynamic update of routing information after receiving ICMP redirect packet message,
Routing with IP broadcast addresses including, but not limited to, limited broadcast, subnet directed broadcast and network directed broadcast;
Routing with a loopback IP address;
Routing with IP multicast address;
The apparatus of claim 1, which performs any one or more of:
ハードウェアARPアドレスキャッシュと組み合ったARP要求と、
複数のIPアドレスに対するARP要求と、
ユニキャストARP要求と、
グラシアス（gratuitous） ARP要求と、のうちの任意の1つ以上を生成する、請求項２６に記載の装置。 The ARP module
ARP requests combined with a hardware ARP address cache;
ARP requests for multiple IP addresses,
Unicast ARP request,
27. The apparatus of claim 26, wherein the apparatus generates any one or more of gratuitous ARP requests.
当該ARPキャッシュが、専用ハードウェアによって制御される、動的に分類されるテーブルを用い、
当該ARPキャッシュが、ARPプロキシとして働く能力をサポートし、そして、
当該ARPキャッシュが、専用ハードワイヤードロジックを用いて、ARPキャッシュエントリの満了時間を制御する、装置。 27. The apparatus of claim 26, further comprising a cache for ARP addresses constructed using optimized hardwired logic,
The ARP cache uses a dynamically classified table controlled by dedicated hardware,
The ARP cache supports the ability to act as an ARP proxy, and
A device in which the ARP cache controls the expiration time of an ARP cache entry using dedicated hard-wired logic.
当該メモリ構造が、
各々が自らの目的に対して最適化された、様々に分類された制御ブロックのセットと、
各制御ブロックに記憶されたポインタを用いて、制御ブロックをリンクするメカニズムと、を有する装置。 The apparatus of claim 1, further comprising a memory structure that enables hardwired virtual memory management,
The memory structure is
A set of variously classified control blocks, each optimized for its own purpose;
A mechanism for linking control blocks using pointers stored in each control block.
パケットを受信および送信し、かつ、パケットをエンコードおよびデコードするためのネットワークスタックを提供し、
複数の専用プロトコルステートマシンを提供するプロセスにおいて、
各プロトコルステートマシンが、特定のネットワークプロトコルに対して最適化されていて、
各プロトコルステートマシン内部の構成要素が、並列実行を行い、
当該プロトコルステートマシンが、受信状態ハンドラステートステートマシンを含み、
当該受信状態ハンドラステートステートマシンが、ＩＰネットワークパケットに自動的に応答する、
リセット（ＲＳＴ）パケットの生成と、
確認応答パケットに同期したパケット（ＳＹＮ／ＡＣＫ）の生成と、
同期パケット（ＳＹＮ）の生成と、
終了パケット（ＦＩＮ）の生成と、
終了／確認応答パケット（ＦＩＮ／ＡＣＫ）の生成と、
リセット／確認応答パケット（ＲＳＴ／ＡＣＫ）の生成と、のうちの任意の１つ以上を含む、
プロセス。 A process for decoding and encoding network protocols to process data,
Providing a network stack for receiving and transmitting packets and for encoding and decoding packets;
In the process of providing multiple dedicated protocol state machines,
Each protocol state machine is optimized for a specific network protocol,
The components inside each protocol state machine perform parallel execution,
The protocol state machine includes a receive state handler state state machine,
The reception state handler state state machine automatically responds to IP network packets.
Generating a reset (RST) packet;
Generation of a packet (SYN / ACK) synchronized with an acknowledgment packet;
Generation of a synchronization packet (SYN);
Generation of an end packet (FIN);
Generation of an end / acknowledgment packet (FIN / ACK);
Including generation of a reset / acknowledge packet (RST / ACK) and any one or more of the following:
process.
当該内部プロセッサが、当該ネットワークスタックを制御する、請求項４６に記載のプロセス。 A process further comprising a step comprising a programmable internal processor,
The process of claim 46, wherein the internal processor controls the network stack.
複数の専用ハードワイアドロジックプロトコールモジュールを提供する、
ネットワークプロトコールをデコードしかつエンコードし、かつデータを処理するプロセスであって、
各プロトコールモジュールが、特定のネットワークプロトコールに最適化され、
当該プロトコールモジュールが、並列実行を行い、
当該プロコールステートマシンが、ＴＣＰプロトコールステートマシンを含み、
当該TCPステートマシンが、専用の最適化されたハードワイヤードロジックを用いて、周回シーケンス番号(PAWS)に対するTCP保護をサポートする、プロセス。 Providing a network stack for receiving and transmitting packets and encoding and decoding packets;
Provides multiple dedicated hardwired logic protocol modules,
The process of decoding and encoding network protocols and processing data,
Each protocol module is optimized for a specific network protocol,
The protocol module performs parallel execution,
The Procall state machine includes a TCP protocol state machine,
A process in which the TCP state machine supports TCP protection against circular sequence numbers (PAWS) using dedicated optimized hard-wired logic.
当該IPルータモジュールが、
ネットワークアドレス中継のためのハードウェアを含むデフォルトIP経路制御能力と、
複数のホストIPアドレスに対する経路制御と、
ホスト指定経路およびネットワーク指定経路に対する経路制御と、
ICMPリダイレクトパケットメッセージ受信後の経路制御情報の動的な更新と、
リミテッドブロードキャスト、サブネットディレクテッドブロードキャストおよびネットワークディレクテッドブロードキャストを含むが、それらに制限されないIPブロードキャストアドレスを伴う経路制御と、
ループバックIPアドレスを伴う経路制御と、
IPマルチキャストアドレスを伴う経路制御と、のうちの任意の1つ以上を遂行する、請求項４６に記載のプロセス。 A process further comprising the step of providing an IP router module,
The IP router module
Default IP routing capability including hardware for network address relay,
Routing for multiple host IP addresses,
Route control for host-specified routes and network-specified routes;
Dynamic update of routing information after receiving ICMP redirect packet message,
Routing with IP broadcast addresses including, but not limited to, limited broadcast, subnet directed broadcast and network directed broadcast;
Routing with a loopback IP address;
The process of claim 46, wherein the process performs any one or more of routing with an IP multicast address.
ハードウェアARPアドレスキャッシュと組み合ったARP要求と、
複数のIPアドレスに対するARP要求と、
ユニキャストARP要求と、
グラティアス（gratuitous） ARP要求と、
のうちの任意の1つ以上を生成する、請求項７１に記載のプロセス。 The ARP module
ARP requests combined with a hardware ARP address cache;
ARP requests for multiple IP addresses,
Unicast ARP request,
Gratuitous ARP requests and
72. The process of claim 71, wherein any one or more of: is generated.
当該ARPキャッシュが、専用ハードウェアによって制御される、動的に分類されるテーブルを用い、
当該ARPキャッシュが、ARPプロキシとして働く能力をサポートし、そして、
当該ARPキャッシュが、専用ハードワイヤードロジックを用いて、ARPキャッシュエントリの満了時間を制御する、プロセス。 The process of claim 71, further comprising providing a cache for ARP addresses constructed using optimized hardwired logic,
The ARP cache uses a dynamically classified table controlled by dedicated hardware,
The ARP cache supports the ability to act as an ARP proxy, and
A process in which the ARP cache uses dedicated hardwired logic to control the expiration time of an ARP cache entry.
当該メモリ構造が、
各々が自らの目的に対して最適化された、様々に分類された制御ブロックのセットと、
各制御ブロックに記憶されたポインタを用いて、制御ブロックをリンクするメカニズムと、を有するプロセス。 The process of claim 46, further comprising providing a memory structure that enables hardwired virtual memory management.
The memory structure is
A set of variously classified control blocks, each optimized for its own purpose;
A mechanism for linking control blocks using pointers stored in each control block.
複数の専用ハードウェアモジュールと、
を有する装置において、
各ハードウェアモジュールが、プログラムにより最適化され、
当該ハードウェアモジュールが、並列実行を行い、
リセット（ＲＳＴ）パケットの生成、
アクノレッジメントパケットとの同期（ＳＹＮ／ＡＣＫ）の生成、
同期パケット（ＳＹＮ）の生成、
終了パケット（ＦＩＮ）の生成、
終了／アクノレッジメントパケット（ＦＩＮ／ＡＣＫ）の生成及び
リセット／アクノレッジメントパケット（ＲＳＴ／ＡＣＫ）の生成
の何れかを含む、ＴＣＰネットワークパケットに自動的に応答するために、少なくとも１個のコンポーネントが、含まれている装置。 The network stack,
Multiple dedicated hardware modules,
In a device having
Each hardware module is optimized by the program,
The hardware module performs parallel execution,
Generation of reset (RST) packets;
Generation of synchronization with the acknowledgment packet (SYN / ACK),
Generation of a synchronization packet (SYN),
Generation of an end packet (FIN),
At least one component is included to automatically respond to TCP network packets, including either termination / acknowledgment packet (FIN / ACK) generation and reset / acknowledgment packet (RST / ACK) generation. Equipment.
Applications Claiming Priority (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US28626501P | 2001-04-24 | 2001-04-24 | |
| US60/286,265 | 2001-04-24 | ||
| US10/093,340 USRE39501E1 (en) | 1996-10-31 | 2002-03-06 | Multiple network protocol encoder/decoder and data processor |
| US10/093,340 | 2002-03-06 | ||
| US10/131,118 | 2002-04-23 | ||
| US10/131,118 US8218555B2 (en) | 2001-04-24 | 2002-04-23 | Gigabit ethernet adapter |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002584131A Division JP2005502225A (en) | 2001-04-24 | 2002-04-24 | Gigabit Ethernet adapter |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2008259238A true JP2008259238A (en) | 2008-10-23 |
| JP4916482B2 JP4916482B2 (en) | 2012-04-11 |
Family
ID=39982279
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008139758A Expired - Lifetime JP4916482B2 (en) | 2001-04-24 | 2008-05-28 | Gigabit Ethernet adapter |
Country Status (3)
| Country | Link |
|---|---|
| JP (1) | JP4916482B2 (en) |
| AT (1) | ATE493821T1 (en) |
| DE (1) | DE60238751D1 (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011193223A (en) * | 2010-03-15 | 2011-09-29 | Mitsubishi Electric Corp | Network connection device |
| CN115695591A (en) * | 2022-10-27 | 2023-02-03 | 天津津航计算技术研究所 | Multi-channel GPS message reporting system based on FPGA |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH03273350A (en) * | 1990-02-23 | 1991-12-04 | Hitachi Ltd | High-speed protocol processor |
| JPH05183603A (en) * | 1992-01-08 | 1993-07-23 | Hitachi Ltd | Reception data processing system and communication controller |
| JPH06309251A (en) * | 1993-04-26 | 1994-11-04 | Hitachi Ltd | Computer on which high speed communication adaptor is mounted |
| JPH07281976A (en) * | 1994-04-05 | 1995-10-27 | Internatl Business Mach Corp <Ibm> | Method for control of packet fifo |
| JPH09153924A (en) * | 1995-11-28 | 1997-06-10 | Nec Corp | Procedure error detection system for communication control system |
| JP2000235536A (en) * | 1999-02-15 | 2000-08-29 | Fuji Xerox Co Ltd | Data communication system and device |
| JP2001503577A (en) * | 1996-10-31 | 2001-03-13 | アイレディー コーポレイション | Multiple network protocol encoder / decoder and data processor |
| JP2002517855A (en) * | 1998-06-12 | 2002-06-18 | マイクロソフト コーポレイション | Method and computer program product for offloading processing tasks from software to hardware |
| JP2002524005A (en) * | 1998-08-28 | 2002-07-30 | アラクリテック・インコーポレイテッド | Intelligent network interface device and system for speeding up communication |
-
2002
- 2002-04-24 DE DE60238751T patent/DE60238751D1/en not_active Expired - Lifetime
- 2002-04-24 AT AT02728953T patent/ATE493821T1/en not_active IP Right Cessation
-
2008
- 2008-05-28 JP JP2008139758A patent/JP4916482B2/en not_active Expired - Lifetime
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH03273350A (en) * | 1990-02-23 | 1991-12-04 | Hitachi Ltd | High-speed protocol processor |
| JPH05183603A (en) * | 1992-01-08 | 1993-07-23 | Hitachi Ltd | Reception data processing system and communication controller |
| JPH06309251A (en) * | 1993-04-26 | 1994-11-04 | Hitachi Ltd | Computer on which high speed communication adaptor is mounted |
| JPH07281976A (en) * | 1994-04-05 | 1995-10-27 | Internatl Business Mach Corp <Ibm> | Method for control of packet fifo |
| JPH09153924A (en) * | 1995-11-28 | 1997-06-10 | Nec Corp | Procedure error detection system for communication control system |
| JP2001503577A (en) * | 1996-10-31 | 2001-03-13 | アイレディー コーポレイション | Multiple network protocol encoder / decoder and data processor |
| JP2002517855A (en) * | 1998-06-12 | 2002-06-18 | マイクロソフト コーポレイション | Method and computer program product for offloading processing tasks from software to hardware |
| JP2002524005A (en) * | 1998-08-28 | 2002-07-30 | アラクリテック・インコーポレイテッド | Intelligent network interface device and system for speeding up communication |
| JP2000235536A (en) * | 1999-02-15 | 2000-08-29 | Fuji Xerox Co Ltd | Data communication system and device |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011193223A (en) * | 2010-03-15 | 2011-09-29 | Mitsubishi Electric Corp | Network connection device |
| CN115695591A (en) * | 2022-10-27 | 2023-02-03 | 天津津航计算技术研究所 | Multi-channel GPS message reporting system based on FPGA |
Also Published As
| Publication number | Publication date |
|---|---|
| ATE493821T1 (en) | 2011-01-15 |
| DE60238751D1 (en) | 2011-02-10 |
| JP4916482B2 (en) | 2012-04-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1382145B1 (en) | Gigabit ethernet adapter | |
| US20070253430A1 (en) | Gigabit Ethernet Adapter | |
| US7535913B2 (en) | Gigabit ethernet adapter supporting the iSCSI and IPSEC protocols | |
| US9264366B2 (en) | Method and apparatus for processing received network packets on a network interface for a computer | |
| US8059680B2 (en) | Offload system, method, and computer program product for processing network communications associated with a plurality of ports | |
| US7472156B2 (en) | Transferring control of a TCP connection between devices | |
| US7535907B2 (en) | TCP engine | |
| US20040078462A1 (en) | Providing window updates from a computer to a network interface device | |
| US20040258076A1 (en) | Setting up a delegated TCP connection | |
| JP4875126B2 (en) | Gigabit Ethernet adapter supporting ISCSI and IPSEC protocols | |
| JP4916482B2 (en) | Gigabit Ethernet adapter | |
| WO2002059757A1 (en) | Communications processor |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110412 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20110712 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20110715 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110812 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20111025 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20111205 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20120110 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20120124 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150203 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4916482 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |