JP2017517951A

JP2017517951A - ネットワークプロトコル更新に適応させるためのシステムおよび方法

Info

Publication number: JP2017517951A
Application number: JP2016565022A
Authority: JP
Inventors: マオ，ユホン
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2014-05-09
Filing date: 2015-05-07
Publication date: 2017-06-29
Anticipated expiration: 2035-05-07
Also published as: CN113765892A; DE202015009279U1; JP6310573B2; DK3120528T3; US9503552B2; KR20160138519A; CN106256112A; EP3120528A1; WO2015171922A1; KR20180088531A; KR102146947B1; EP3120528B1; US20150326696A1

Abstract

ネットワークプロトコルを更新するためのシステムおよび方法が提供される。少なくとも１つのパケット編集プログラムを有する新たなＡＳＩＣは、将来のネットワークプロトコルに適応するように設計されている。ＡＳＩＣは、受信されたパケットを分類して（８２０）更新されるパケットの新たなプロトコルを決定し、パケットの選択された既存のヘッダを削除し（８３０）、分類に基づいて新たなヘッダをパケット内に挿入し（８４０）、選択されたヘッダを分類に基づいて変更する（８５０）ように構成されている。

Description

関連出願の相互参照
本願は、２０１４年５月９日に出願された米国特許出願第１４／２７３，９５３号の継続出願であり、その開示を引用により本明細書に援用する。

背景
ほとんどのネットワーキング特定用途向け集積回路（ＡＳＩＣ：application specific integrated circuit）は、既定のネットワークプロトコルのための小規模な一定の１セットのパケットヘッダ編集機能を実現する。特定のネットワークプロトコルのためのこのようなヘッダ編集機能の例として、ＧＲＥ（generic routing encapsulation）トンネルカプセル化および非カプセル化、ＶＬＡＮ／ＭＰＬＳ（virtual local area network：仮想ローカルエリアネットワーク／multiprotocol label switching：マルチプロトコルラベルスイッチング）タグプッシュ／ポップなどが挙げられる。新たなネットワークプロトコルによってＡＳＩＣのリスピンまたは完全な再設計が必要となり、それには費用も時間も両方かかる。たとえば、ネットワーク内のＡＳＩＣの再設計および交換には数年の時間と何百万ドルものコストがかかる可能性がある。

概要
ネットワークプロトコルを好都合に更新するためのシステムおよび方法が提供される。将来のネットワークプロトコルに適応可能なＡＳＩＣは、プロトコル非依存パケットエディタ（ＰＩＰＥ：Protocol Independent Packet Editor）を含み、これは現在の、および将来あり得るネットワークプロトコルのパケットヘッダ編集要件をサポートするようにプログラムされ得る。

上記技術の一局面は、パケットを受信するステップと、１つ以上のプロセッサを用いてパケットを分類するステップとを含む方法を提供する。分類するステップは、更新されるパケットの新たなプロトコルを決定するステップを含む。上記方法はさらに、１つ以上のプロセッサを用いてパケットの既存のヘッダを削除するステップと、１つ以上のプロセッサを用いて分類に基づいて新たなヘッダをパケット内に挿入するステップと、１つ以上のプロセッサを用いて分類に基づいて新たなヘッダを変更するステップとを含む。いくつかの例によれば、更新されるパケットの新たなプロトコルを決定するステップは、パケット編集プログラムへのポインタを識別するステップを含む。既存のパケットヘッダを削除するステップは、既存のヘッダのうち、新たなプロトコルによって用いられない選択された部分を削除するステップを含み得る。さらに、新たなパケットヘッダを挿入するステップは、新たなパケットヘッダのうち新たなプロトコルに基づく部分と、前のパケットヘッダからの残留部分とを挿入するステップを含み得る。新たなヘッダを含むパケットは、新たなヘッダに基づいてネットワークを介して送信され得る。

本開示の別の局面は、少なくとも１つのメモリと、当該少なくとも１つのメモリと通信する少なくとも１つのプロセッサとを含むシステムを提供する。少なくとも１つのプロセッサは、パケットを受信し、パケットを分類するように構成されている。当該分類は、更新されるパケットの新たなプロトコルを決定することを含む。少なくとも１つのプロセッサはさらに、パケットの既存のヘッダを削除し、分類に基づいて新たなヘッダをパケット内に挿入し、分類に基づいて新たなヘッダを変更するように構成されている。

少なくとも１つのメモリは少なくとも１つのパケット編集プログラムを含んでもよく、各パケット編集プログラムは、その編集命令へのポインタと、静的データ、共有データ、および動的データのセットへのポインタとを含み得る。少なくとも１つのメモリは、編集命令によってアクセス可能なメタデータとレジスタデータとをさらに含み得る。さらに、少なくとも１つのメモリおよび少なくとも１つのプロセッサは、特定用途向け集積回路（ＡＳＩＣ）上に設けられ得る。

本開示のさらに別の局面は、方法を実施するための、１つ以上のプロセッサによって実行可能な命令を格納する非一時的なコンピュータ読取可能媒体を提供する。上記方法は、パケットを受信するステップと、パケットを分類するステップとを含む。分類するステップは、更新されるパケットの新たなプロトコルを決定するステップを含む。上記方法はさらに、パケットの既存のヘッダを削除するステップと、分類に基づいて新たなヘッダをパケット内に挿入するステップと、分類に基づいて新たなヘッダを変更するステップとを含む。

本開示の一局面に係るシステム図である。本開示の局面に係る別のシステム図である。本開示の局面に係る命令形式の例を示す図である。本開示の局面に係る命令形式の例を示す図である。本開示の局面に係る別のシステム図である。本開示の局面に係る命令の例を示す図である。本開示の局面に係る命令の例を示す図である。本開示の局面に係る命令の例を示す図である。本開示の局面に係る命令の例を示す図である。本開示の局面に係る命令の例を示す図である。本開示の局面に係る命令の例を示す図である。本開示の局面に係る命令の例を示す図である。本開示の局面に係る命令の例を示す図である。本開示の局面に係る命令の例を示す図である。本開示の局面に係る命令の例を示す図である。本開示の局面に係る命令の例を示す図である。本開示の局面に係る命令の例を示す図である。本開示の局面に係る別のシステム図である。本開示の局面に係る方法の一例の流れ図である。

詳細な説明
本開示は、ネットワークプロトコルを好都合に更新するためのシステムおよび方法を提供する。ネットワークプロトコルが更新された際に特定用途向け集積回路（ＡＳＩＣ）を再設計および交換するのではなく、新たなＡＳＩＣが、将来のネットワークプロトコルに適応するように設計されている。ＡＳＩＣはプロトコル非依存パケットエディタ（ＰＩＰＥ）を含み、このプロトコル非依存パケットエディタは、現在の、および将来あり得るネットワークプロトコルのパケットヘッダ編集要件をサポートするようにプログラムされ得る。

一実施形態によれば、ＡＳＩＣは、パケットヘッダを処理するための編集プログラムを実行する中央編集ユニット（ＣＥＵ：Central Editing Unit）を含む。中央編集ユニットは、削除ユニット、挿入ユニット、および変更ユニットの、３つの別個の編集ユニットの処理パイプラインである。各ユニットは、前のユニットから変更されたパケットを処理する。このＣＥＵパイプラインによって、シリコンで効率的にハードウェアを実装して、高い帯域幅およびパケットレートでのフレキシブルなパケットヘッダ編集が可能になる。

削除ユニットは、パケットからの任意のプロトコルヘッダの除去を可能にする。挿入ユニットは、パケットへの任意のプロトコルヘッダの挿入を可能にする。変更ユニットは、ヘッダフィールドのフレキシブルな書換え（上書きまたはリードモディファイライト）を可能にする。

ＣＥＵによって実行されたパケット編集プログラムは、１セットの編集命令（削除、挿入、およびフィールド変更）と、１セットの編集データ（構成、メタ、共有、および動的）とを含む。１つ以上のさまざまな編集プログラムは、カプセル化、非カプセル化、暗号化、復号化などのさまざまなパケットヘッダ編集機能のために存在し得る。論理部は、受信パケットを構文解析および分類して、プログラム命令および関連データセットへのポインタを決定する。

編集命令は、たとえば３２バイトまたは６４バイトの長さであり得る。編集命令は、さまざまなネットワーク処理のためのさまざまな編集プログラムによって共有され得る。各編集プログラムは、３セットのデータへのポインタを含み得る。すなわち、静的データ、共有データ（たとえば、さまざまなパケット編集プログラムの間で共有されるセキュリティフロー状態の［ｆｌｏｗＩＤ、ｐｋｔ＿ｃｎｔ、ｅｎｃｒｙｐｔｉｏｎｋｅｙ］）、および動的データ（たとえばプログラムに専用のデータ）である。さらに、編集命令が利用することのできる２セットのグローバルデータがある。すなわち、メタデータおよび定型データである。

図１は、本開示の局面に係るＡＳＩＣ１００を示す。ＡＳＩＣ１００は、パケット１５０などのパケットを受信して、更新されたネットワークプロトコルに従ってパケットを更新するように適合されている。いくつかの例によれば、更新されたネットワークプロトコルは、現時点では開発されていない将来のネットワークプロトコルであり得る。この点に関して、プロトコルが更新される度にネットワーク内の各ＡＳＩＣを交換するのではなく、ＡＳＩＣと、ネットワークを介して送信されたパケットとが効率的に更新され得る。

ＡＳＩＣ１００はネットワーク内で相互接続されたいくつかのＡＳＩＣのうちいずれであってもよい。別の例によれば、ＡＳＩＣはプロトコル更新のために設計され得る。ＡＳＩＣ１００は特定の構成要素を有するものとして説明するが、ＡＳＩＣにおいて典型的に見られるような他の構成要素も含み得ると理解すべきである。さらに、構成要素はＡＳＩＣ１００内にあるものとして示すが、構成要素は、ＡＳＩＣ１００と通信するネットワーク内の他のどこにあってもよいと理解すべきである。

ＡＳＩＣ１００は、ユーザ論理部１１０とパケットエディタ１２０とを含む。パケットエディタ１２０はさらに、編集命令１３２および編集データ１３４を含む少なくとも１つの編集プログラム１３０と、中央編集ユニット１４０とを含む。

ユーザ論理部１１０は、ＡＳＩＣで受信したパケットを構文解析し、パケットを分類する。たとえば、ユーザ論理部１１０は、いくつかの編集プログラムのうちいずれがパケット１５０を処理すべきかを決定し得る。異なる編集プログラムが作成されて、異なるタイプのパケットが更新され得る。たとえば、第１の編集プログラムを用いて第１のプロトコルから新たなプロトコルにパケットを更新し得る一方、第２の編集プログラムを用いて第２のプロトコルから新たなプロトコルにパケットを更新し得る。別の例によれば、カプセル化されたパケットを第３の編集プログラムを用いて更新し得る一方、非カプセル化されたパケットを第３の編集プログラムを用いて更新し得る。

各編集プログラムは編集データと編集命令とを含む。たとえば、編集プログラム１３０は編集命令１３２と編集データ１３４とを含む。編集プログラムのさらなる詳細については図４に関連して後述する。

中央編集ユニット１４０は、ユーザ論理部１１０によって識別された編集プログラムに従ってパケット１５０を更新する処理パイプラインである。したがって、ＡＳＩＣ１００は、更新されたパケット１５０′をネットワークを介して送信可能である。

図２は中央編集ユニット１４０のさらなる詳細を示す。図示するように、中央編集ユニット１４０は、削除ユニット２１０と、挿入ユニット２２０と、変更ユニット２３０とを含む。これらのユニット２１０、２２０、２３０の各々は、特定の編集プログラムのための１セットの命令、たとえば命令１３２などに従って、受信パケット１５０を処理する。図４に関連して後述するように、命令１３２は、ユニット２１０、２２０、２３０の各々について別々の命令のセットを含み得る。挿入ユニット２２０は、パケット１５０が削除ユニット２１０によって変更された後に当該パケットを処理する。同様に、変更ユニット２３０は、パケットが挿入ユニット２２０によって変更された後に当該パケットを処理する。各ユニットは、その処理の後、かつパケットを次のユニットに渡す前に、パケットのバイトストリームを再編成し得る。この中央編集ユニットパイプラインによって、高い帯域幅およびパケットレートでのフレキシブルなパケットヘッダ編集が可能になる。さらに、このパイプラインによって、シリコンでの効率的なハードウェア実装が提供される。

削除ユニット２１０は、パケットからの任意のプロトコルヘッダの除去を可能にする。たとえば、削除ユニット２１０は、トンネリングされたネットワーク内の内部ＩＰヘッダおよび外部ＩＰヘッダなどの複数のヘッダを含むパケットについて、すべてのパケットヘッダまたは選択されたパケットヘッダを除去し得る。別の例によれば、削除ユニット２１０は、パケットの特定のフィールドを削除し得る一方、更新されたネットワークプロトコルに関連する他のフィールドを維持し得る。

挿入ユニット２２０は、パケットへの任意のプロトコルヘッダの挿入を可能にする。たとえば、挿入ユニット２２０は、更新ネットワークプロトコルに関係する１セットの新たなヘッダフィールドを生成して、これらの生成されたフィールドをパケット１５０に付加し得る。特定のフィールドのみが削除ユニット２１０によって削除される例において、挿入ユニット２２０は、残りのフィールドを再生成する必要がないと判断して、その代わり必要なフィールドのみを生成し得る。他の例において、挿入ユニット２２０は、ヘッダ全体を生成し得る。

変更ユニット２３０は、ヘッダフィールドのフレキシブルな書換え、たとえば上書きまたはリードモディファイライト（read-modify-write）などを可能にする。たとえば、変更ユニット２３０は、更新されたネットワークを介してパケットを適切に送信することを可能にする情報によって、パケットヘッダフィールドを埋めてもよい。

図１に関連して上述したように、各パケット編集プログラムは編集命令と編集データセットとを含む。たとえば、プログラムは、その編集命令への１６ビットのポインタを有し得る。いくつかの例によれば、編集命令は、さまざまな編集プログラムによって共有可能である。たとえば、第１のネットワークプロトコルに基づくカプセル化と、第２のネットワークプロトコルに基づくカプセル化とは、同一の編集命令を利用し得る。

図３Ａおよび図３Ｂは、編集命令の形式の例を示す。図３Ａの例では、命令は３２Ｂ（３２バイト）である。バイト０〜７は削除にあてられ、バイト８〜１５は挿入にあてられ、バイト１６〜３１は変更にあてられている。図３Ｂの例では、命令は６４Ｂ（６４バイト）である。３２Ｂ形式と同様、ここでもバイト０〜７は削除にあてられている。しかしながら、３２Ｂ形式と異なり、６４Ｂ形式では、バイト８〜３１が挿入にあてられ、バイト３２〜６３が変更にあてられている。

図４は、編集プログラム４３０をより詳細に示す。編集プログラム４３０は、編集命令４４０と編集データ４５０とを含む。

編集データ４５０は、静的データ４５２と、共有データ４５４と、動的データ４５６とを含む。たとえば、各編集プログラムはこれらのデータセットへのポインタを含んでもよく、それらはＡＳＩＣと通信するメモリ内に記憶され得る。一例によれば、静的データ４５２および共有データ４５４の各々は３２Ｂの、動的データ４５６は３２Ｂ〜６４Ｂの、特定の編集プログラムに専用のデータであり得る。一例によれば、マルチパスロードバランシングは、選択されたｎ−タプル（n-tuple）のヘッダフィールドから生成されたハッシュを用いて１群の共有／動的データセットから共有／動的データセットを選択することによってサポートされ得る。

図示はしないが、メタデータやレジスタデータなどの追加のデータが編集命令に利用可能であってもよい。たとえば、第１の８×２Ｂ（２バイト）ハーフワードがｐｋｔ＿ｌｅｎｇｔｈ、ｉｐ＿ｐｋｔ＿ｉｄ、ｆｌｏｗ＿ｈａｓｈ、ｓｌｉｃｅ＿ＩＤなどのメタデータである３２Ｂのメタデータが利用可能であり得る。第２の８×２Ｂハーフワードは、たとえばＩＰ＿ＰＲＯＴＯ、ＴＴＬ、ＴＯＳなどの、パケットヘッダから集められた２Ｂのヘッダフィールドである。たとえばユーザ論理部の構文解析によって、パケット形式が識別され、８×２Ｂオフセットが指定されて、所望のヘッダフィールドが選択される。別の例として、８×８Ｂ（８バイト）のレジスタを有する６４Ｂのレジスタデータが編集命令に利用可能であってもよい。この例では、レジスタ０はすべてゼロにハードコード化されており、レジスタ１には６４ビットのパケットカウントが任意にロードされており、レジスタ２には６４ビットのタイムスタンプが任意にロードされており、レジスタ３〜７は静的データを用いてソフトウェアにより構成される。

編集命令４４０は、削除命令４４２と、挿入命令４４４と、変更命令４４６とを含む。＜ＩＮＳＮＯＰ＞および＜ＩＮＳＭＯＶ＞などの個々の挿入命令４４４の例が図５Ａ〜図５Ｆでさらに詳細に図示および記載される。また、＜ＭＯＤＮＯＰ＞および＜ＭＯＤＷＲＩＴＥＭＥＴＡ＞などの個々の変更命令４４６の例も、図６Ａ〜図６Ｆでさらに詳細に図示および記載される。

削除命令４４２は、たとえば８Ｂの長さであってもよく、各ビットは１２８Ｂ（１２８バイト）パケットヘッダの２Ｂハーフワードを表わし得る。ビットが設定されると、対応する２Ｂハーフワードがパケットヘッダから削除される。６４ビットのゼロは、実質的にノーオペレーション（ＮＯＰ：no operation）削除命令である。

挿入命令４４４は、たとえば図２の挿入ユニット２２０によって実行され得る。一例によれば、挿入ユニット２２０は、ゼロで始まるアクティブヘッダポインタを（たとえば、２Ｂハーフワード単位で）維持する。図５Ａに関連して以下でより詳しく説明するが、ＭＯＶ命令はヘッダポインタを順方向に移動させる。挿入命令は、現在のアクティブヘッダポインタにおいて指定データを挿入して、当該ヘッダポインタを、挿入されたハーフワードの数だけ順方向へ移動させる。すべての挿入命令４４４は、たとえば８ビット幅であり得る。

図５Ａ〜図５Ｆは、移動を含む挿入命令４４４の例および特定のデータセットに対する処理の例を示す。ノーオペレーション挿入命令は図示しない。たとえば、８ビットのゼロはＮＯＰであり、これは挿入命令の終わりを示す。

図５ＡはＩＮＳＭＯＶ命令の一例を示す。この命令は、指定されたカウント（ｃｎｔ：count）の分だけ現在の挿入ポインタを進める。たとえば、図示するように、ビット０〜５はカウントを含み、ビット７〜８は０に設定される。

図５ＢはＩＮＳＳＴＡＴＩＣ命令の一例を示す。この命令は、静的データセット（たとえば図４の静的データ４５２）から指定された（ｃｎｔ）ハーフワードを挿入する。ｈ＝０ならば、データは下位１６Ｂ（１６バイト）から始まる。ｈ＝１ならば、データは上位１６Ｂから始まる。

図５ＣはＩＮＳＳＨＡＲＥＤ命令の一例を示す。この命令は、ＩＮＳＳＴＡＴＩＣ命令が静的データセットを処理するのと同じ方法で、共有データセット（たとえば図４の共有データ４５４）を処理し得る。同様に、図５Ｄは、同じ方法で図４の動的データ４５６などの動的データの第１の３２Ｂを処理するＩＮＳＤＹＮＡＭＩＣＬ命令の一例を示す。さらに図５Ｅは、同じ方法で動的データの第２の３２Ｂを処理するＩＮＳＤＹＮＡＭＩＣＨ命令の一例を示す。

図５ＦはＩＮＳＲＥＧ命令の一例を示している。このＩＮＳＲＥＧ命令は、選択されたグローバルレジスタデータからｃｎｔハーフワードを挿入するものである。

変更命令４４６は概して、任意のビットまたはバイトがいくつかの命令において選択された状態で、ハーフワードを処理し得る。いくつかの例によれば、２つの変更命令が同一のハーフワードを処理してもよく、その各々が異なるバイトを処理してもよい。ＭＯＤＮＯＰはノーオペレーション変更命令を表わし、１６ビットの０によって表現され得る。これは変更命令の終わりを表わす。

図６ＡはＭＯＤＷＲＩＴＥＭＥＴＡ命令の一例を示す。この命令によれば、指定されたｏｐ＿ｃｏｄｅに従い、書込み処理が、メタデータセットから選択された（ｓｅｌ［３：０］）２Ｂフィールドで、（ハーフワード単位で）オフセットにおいて行なわれる。４ニブルのメタデータを書換えるサポートされた書込みｏｐ＿ｃｏｄｅの例として、１．ＡＢＣＤ＞ＡＢＣＤ；２．ＡＢＣＤ＞ＡＢＸＸ；３．ＡＢＣＤ＞ＸＸＣＤ；４．ＡＢＣＤ＞ＸＸＡＢ；５．ＡＢＣＤ＞ＣＤＸＸ；６．ＡＢＣＤ＞ＸＣＤＸ；７．ＡＢＣＤ＞ＸＸＢＣ、が挙げられる。これらの例において、「Ｘ」はそのニブルが変更されないことを表わす。例６および例７は、たとえばＩＰｖ４ヘッダとＩＰｖ６ヘッダとの間でＤＳＣＰ／ＥＣＮをコピーするのに有用であり得る。

図６ＢはＭＯＤ＿ＣＨＫＳＵＭ命令の一例を示す。この命令は、ｈｄｒ＿ｌｅｎハーフワードについて、（ヘッダの第１の６４Ｂ内の）ｈｄｒ＿ｏｆｆｓｅｔで始まる（ＩＰｖ４ヘッダにおけるような）１の補数チェックサムを計算し、ｈｄｒ＿ｏｆｆｓｅｔフィールドに対して指定されたｃｓｕｍ＿ｏｆｆｓｅｔ位置に、計算されたチェックサムフィールドを書込む。チェックサムフィールド自体はチェックサムの蓄積の中に含まれない。

図６ＣはＭＯＤ＿ＡＬＵ命令の一例を示している。このＭＯＤ＿ＡＬＵ命令は、ヘッダオフセットにおいて、（バイトイネーブル「ｂｅｎ」によって指定された）バイト／ハーフワードについて、ｏｐ＿ｃｏｄｅによって指定された処理を実行するものである。サポートされたｏｐ＿ｃｏｄｅの例として、０−ｓｅｔｔｏｚｅｒｏ、１−ｓｅｔｔｏ１、２−ａｄｄ１、３−ａｄｄ１ｂｕｔｓｔｏｐｓａｔ８ｈＦｏｒ１６ｈＦＦ、４−ｓｕｂｔｒａｃｔ１、５−ｓｕｂｔｒａｃｔ１ｂｕｔｓｔｏｐｓａｔｚｅｒｏ、が挙げられる。

図６ＤはＭＯＤ＿ＣＫＳＵＭ＿ＩＮＣ命令の一例を示している。このＭＯＤ＿ＣＫＳＵＭ＿ＩＮＣ命令は、ｉｍｍ＿ｄａｔａにおいて指定されたインクリメンタル値で、ｃｓｕｍ＿ｏｆｆｓｅｔにおいてチェックサムフィールドのインクリメンタルチェックサム更新を行なうものである。

図６ＥはＭＯＤ＿ＷＲＩＴＥ＿ＩＭＭ命令の一例を示している。このＭＯＤ＿ＷＲＩＴＥ＿ＩＭＭ命令は、１６ビット即値データｉｍｍ＿ｄａｔａでオフセットにおいてヘッダフィールドを上書きするものである。ｎｉｂｂｌｅ＿ｅｎの各ビットによって、ハーフワード内の１ニブルの上書きが可能になる。

図６ＦはＭＯＤ＿ＷＲＩＴＥ＿ＭＥＴＡ＿ＩＭＭ命令の一例を示している。このＭＯＤ＿ＷＲＩＴＥ＿ＭＥＴＡ＿ＩＭＭ命令は、ｉｍｍ＿ｄａｔａと、メタデータから選択された（ｓｅｌ［３：０］）２Ｂフィールドとの間の（ｏｐ＿ｃｏｄｅによって指定された）処理の結果を、オフセットにおいて（ハーフワード単位で）書込むものである。サポートされたｏｐ＿ｃｏｄｅの例として、０−Ａｄｄ、１−ＢｉｔｗｉｄｅＯＲ、２−ＢｉｔｗｉｄｅＡＮＤ、が挙げられる。

命令のいくつかの例を説明してきたが、これらの例は網羅的なものではなく、パケットヘッダを更新するために追加の命令を用い得ると理解すべきである。さらに、これらの命令の例は変更されてもよく、それでも意図した効果を達成し得ると理解すべきである。

図７は、本明細書で説明されるような、パケットヘッダを更新するために実装され得るコンピューティング装置の一例を示す。コンピューティング装置は、プロセッサ７３０とメモリ７２０とを含む、ＡＳＩＣもしくは他の装置または互いに通信する複数のコンピューティング装置もしくは構成要素であり得る。コンピューティング装置７００は、データパケットまたは他の情報を他のコンピューティング装置から受信するための１つ以上の入力ポート７５０を、さらに含み得る。同様に、コンピューティング装置７００は、たとえばパケットヘッダが新たなネットワークプロトコルに従って更新された後にパケットを送信するための１つ以上の出力ポート７６０を含み得る。

メモリ７２０は、プロセッサ７３０によってアクセス可能な情報を記憶する。この情報は、プロセッサ７３０によって実行されるかまたは他の方法で用いられ得るデータ７２２および命令７２８を含む。メモリ７２０は、プロセッサによってアクセス可能な情報を記憶することのできる如何なる種類のメモリであってもよく、ハードドライブ、メモリカード、ＲＯＭ、ＲＡＭ、ＤＶＤまたは他の光学ディスク、ならびに他の書込み可能および読出し専用のメモリなどの、コンピュータ読取可能媒体、または電子装置を用いて読出され得るデータを記憶する他の媒体を含む。一例によれば、図４に戻って、編集データ４５０および編集命令４４０は１つの論理ＳＲＡＭを共有し得る。これにより、これらの間でのＳＲＡＭリソースの動的割当てが可能になる。システムおよび方法は、上述した事項のさまざまな組合せを含んでもよく、命令およびデータのさまざまな部分がさまざまな種類の媒体に記憶され得る。

命令７２８は、プロセッサ７３０によって直接的に（たとえば機械語など）または間接的に（たとえばスクリプトなど）実行される如何なる命令のセットであってもよい。たとえば、命令はコンピュータコードとしてコンピュータ読取可能媒体に記憶され得る。この点に関して、「命令」および「プログラム」との用語は本明細書では区別なく用いられ得る。命令は、プロセッサによって直接処理されるようなオブジェクトコード形式で記憶されてもよく、または、要求に応じて解釈されるかもしくは予めコンパイルされる独立したソースコードモジュールのスクリプトもしくは集まりを含む他の如何なるコンピュータ言語で記憶されてもよい。プロセッサ７３０は、パケットを受信すると、たとえばパケットを分類し、パケットヘッダを削除し、分類に基づいて新たなパケットヘッダを挿入し、および分類に基づいてパケットヘッダを変更するように命令７２８を実行し得る。

命令７２８に従って、データ７２２はプロセッサ７３０によって抽出、記憶、または変更され得る。システムおよび方法は如何なる特定のデータ構造によっても限定されないが、データは、たとえば複数のさまざまなフィールドおよびレコードを有するテーブル、ＸＭＬドキュメント、またはフラットファイルとして、コンピュータレジスタ内のリレーショナルデータベースに記憶され得る。また、データは如何なるコンピュータ読取可能な形式でフォーマットされてもよい。データは、数、記述テキスト、プロプライエタリコード（proprietary codes）、同一メモリの他の領域もしくは異なるメモリ（他のネットワークロケーションを含む）に記憶されたデータへの参照、または関連データを計算する機能によって用いられる情報などの、関連情報を識別するのに十分な如何なる情報も含み得る。

プロセッサ７３０は、市販のルータにおけるプロセッサなど、従来の如何なるプロセッサであってもよい。代替的には、プロセッサは、ＡＳＩＣなどの専用コントローラまたは他のハードウェアベースのプロセッサであってもよい。プロセッサおよびメモリは、複数のプロセッサおよびメモリを実際に含んでもよく、それらは同一の物理筐体内に収容されてもよいし同一の物理筐体内に収容されなくてもよい。たとえば、メモリは、データセンタのサーバファーム内に置かれたハードドライブまたは他の記憶媒体であってもよい。したがって、プロセッサ、メモリまたはコンピュータに言及する場合、これは、複数のプロセッサ、メモリ、またはコンピュータの集まりへの言及を含み、これら複数のプロセッサ、メモリ、またはコンピュータは並行して動作してもよいし並行して動作しなくてもよいと理解されるだろう。

コンピューティング装置７００は、たとえばネットワークを介して他のコンピューティング装置と通信し得る。たとえば、装置は有線接続を介してまたは無線で通信し得る。ネットワーク、および介在するノードは、インターネット、ワールドワイドウェブ、イントラネット、仮想プライベートネットワーク、広域ネットワーク、ローカルネットワーク、１つ以上の企業独自の通信プロトコルを用いたプライベートネットワーク、イーサネット（登録商標）、Ｗｉ−Ｆｉ（登録商標；８０２.１１、８０２.１１b、ｇ、ｎ、または他の同類の規格など）、ＨＴＴＰ、およびこれらのさまざまな組合せを含む、さまざまな設定とプロトコルとを含み得る。このような通信は、モデム（たとえば、ダイヤルアップ式、ケーブル、または光ファイバ）および無線インターフェイスなどの、他のコンピュータとの間でデータを送受信可能な如何なる装置によっても手助けされ得る。

図８は、新たなネットワークプロトコルに準拠するようにパケットを更新する方法の一例を示す。たとえばこの方法は、上述したコンピューティング装置などのコンピューティング装置によって行なわれ得る。この方法に含まれる処理は、記載された通りの順序で行なわなくてもよいと理解すべきである。その代りに、さまざまな処理は、異なる順序でまたは同時に行なわれてもよく、処理が追加または省略されてもよい。

ブロック８１０では、パケットが受信される。ブロック８２０では、受信されたパケットが分類される。たとえば、分類は、受信されたパケットの形式を決定することと、受信されたパケットが更新される際に従うべき新たなプロトコルを決定することとを含み得る。一例によれば、分類は、受信されたパケットが、特定のパケット編集プログラムおよび関連データセットへのポインタを含んでいるか否かを決定することを含む。

ブロック８３０では、パケットヘッダが削除される。たとえば、ヘッダは、新たなプロトコルヘッダ形式に基づいて全体または一部が削除され得る。

ブロック８４０では、分類に基づいて新たなプロトコルヘッダが挿入される。たとえば、新たなヘッダは、上記削除に基づいて全体または一部が挿入され得る。ヘッダは、たとえば、図４および図５Ａ〜図５Ｆに関連して上述した処理のうちいずれかを用いて挿入され得る。

ブロック８５０では、ヘッダが変更され得る。たとえば、新たなヘッダフィールドが書込まれてもよく、および／または既存のヘッダフィールドが上書きもしくは変更されてもよい。ヘッダフィールドの変更は、たとえば、図４および図６Ａ〜図６Ｆに関連して上述した命令のうちいずれかを用いて行なわれ得る。パケットヘッダが変更されると、更新されたパケットは、たとえば、コンピューティング装置の出力ポートを通じて出力され得る。

上述したシステム、方法、および例は、まだ定義されていない新たなプロトコルに既存のネットワークを適応させることにおいて有利である。プロトコルの更新が起る度に多数のＡＳＩＣを再設計および交換するのではなく、パケットヘッダが既存のＡＳＩＣによって用いられるように変更され得る。この点に関して、かなりの時間、労力、およびコストが省かれる。

上述した特徴のこれらおよび他の変形例ならびに組合せは、特許請求の範囲によって定義された主題から逸脱することなく用いることができる。したがって、上述の実施形態の記載は、特許請求の範囲によって定義された主題を限定するものではなく、例示のためのものであると考えられるべきである。一例として、上述の処理は、上述の通りの順序で行なう必要はない。代わりに、さまざまなステップは異なる順序でまたは同時に処理されてもよい。別段の記載がない限り、ステップを省略することも可能である。さらに、本明細書に記載された例の条件ならびに「などの（such as）」および「含む（including）」などで表現された節は、特許請求の範囲の主題を特定の例に限定するものとして解釈されるべきではなく、例は、多くの可能な実施形態のうちの１つを例示するよう意図されているに過ぎない。さらに、異なる図中の同一の参照符号は、同一または同様の要素を識別し得る。

Claims

方法であって、
パケットを受信するステップと、
１つ以上のプロセッサを用いて前記パケットを分類するステップとを含み、前記分類するステップは、
更新される前記パケットの新たなプロトコルを決定するステップを含み、前記方法はさらに、
１つ以上のプロセッサを用いて、前記パケットの既存のヘッダを削除するステップと、
１つ以上のプロセッサを用いて、前記分類に基づいて新たなヘッダを前記パケット内に挿入するステップと、
１つ以上のプロセッサを用いて、前記分類に基づいて前記新たなヘッダを変更するステップとを含む、方法。
前記更新されるパケットの新たなプロトコルを決定するステップは、パケット編集プログラムへのポインタを識別するステップを含む、請求項１に記載の方法。
前記既存のパケットヘッダを削除するステップは、前記既存のヘッダのうち、前記新たなプロトコルによって用いられない選択された部分を削除するステップを含む、請求項１に記載の方法。
前記新たなパケットヘッダを挿入するステップは、前記新たなパケットヘッダのうち前記新たなプロトコルに基づく部分と、前のパケットヘッダからの残留部分とを挿入するステップを含む、請求項３に記載の方法。
前記新たなパケットヘッダを変更するステップは、上書き処理またはリードモディファイライト処理のうち少なくとも１つを実行するステップを含む、請求項１に記載の方法。
前記新たなヘッダを含む前記パケットを、前記新たなヘッダに基づいてネットワークを介して送信するステップをさらに含む、請求項１に記載の方法。
システムであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリと通信する少なくとも１つのプロセッサとを備え、前記少なくとも１つのプロセッサは、
パケットを受信し、
前記パケットを分類し、前記分類は、更新される前記パケットの新たなプロトコルを決定することを含み、前記少なくとも１つのプロセッサはさらに、
前記パケットの既存のヘッダを削除し、
前記分類に基づいて新たなヘッダを前記パケット内に挿入し、
前記分類に基づいて前記新たなヘッダを変更する、システム。
前記少なくとも１つのメモリは少なくとも１つのパケット編集プログラムを含み、各パケット編集プログラムは、編集命令へのポインタと、静的データ、共有データ、および動的データのセットへのポインタとを含む、請求項７に記載のシステム。
前記少なくとも１つのメモリは、前記編集命令によってアクセス可能なメタデータとレジスタデータとをさらに含む、請求項８に記載のシステム。
前記少なくとも１つのメモリおよび前記少なくとも１つのプロセッサは、特定用途向け集積回路（ＡＳＩＣ）上に設けられている、請求項７に記載のシステム。
前記更新されるパケットの新たなプロトコルを決定することは、パケット編集プログラムへのポインタを識別することを含む、請求項７に記載のシステム。
前記既存のパケットヘッダを削除することは、前記既存のヘッダのうち、前記新たなプロトコルによって用いられない選択された部分を削除することを含む、請求項７に記載のシステム。
前記新たなパケットヘッダを挿入することは、前記新たなパケットヘッダのうち前記新たなプロトコルに基づく部分と、前のパケットヘッダからの残留部分とを挿入することを含む、請求項１２に記載のシステム。
前記新たなパケットヘッダを変更することは、上書き処理またはリードモディファイライト処理のうち少なくとも１つを実行することを含む、請求項７に記載のシステム。
前記少なくとも１つのプロセッサはさらに、前記新たなヘッダを含む前記パケットを、前記新たなヘッダに基づいてネットワークを介して送信するように構成されている、請求項７に記載のシステム。
方法を実施するための、１つ以上のプロセッサによって実行可能な命令を格納する非一時的なコンピュータ読取可能媒体であって、前記方法は、
パケットを受信するステップと、
前記パケットを分類するステップとを含み、前記分類するステップは、更新される前記パケットの新たなプロトコルを決定するステップを含み、前記方法はさらに、
前記パケットの既存のヘッダを削除するステップと、
前記分類に基づいて新たなヘッダを前記パケット内に挿入するステップと、
前記分類に基づいて前記新たなヘッダを変更するステップとを含む、非一時的なコンピュータ読取可能媒体。
前記更新されるパケットの新たなプロトコルを決定するステップは、パケット編集プログラムへのポインタを識別するステップを含む、請求項１６に記載の非一時的なコンピュータ読取可能媒体。
前記既存のパケットヘッダを削除するステップは、前記既存のヘッダのうち、前記新たなプロトコルによって用いられない選択された部分を削除するステップを含み、
前記新たなパケットヘッダを挿入するステップは、前記新たなパケットヘッダのうち前記新たなプロトコルに基づく部分と、前のパケットヘッダからの残留部分とを挿入するステップを含む、請求項１６に記載の非一時的なコンピュータ読取可能媒体。
前記新たなパケットヘッダを変更するステップは、上書き処理またはリードモディファイライト処理のうち少なくとも１つを実行するステップを含む、請求項１６に記載の非一時的なコンピュータ読取可能媒体。
前記新たなヘッダを含む前記パケットを、前記新たなヘッダに基づいてネットワークを介して送信するステップをさらに含む、請求項１６に記載の非一時的なコンピュータ読取可能媒体。