(57)【要約】本発明は、ＵＤＰトランスポートを用いたメッセージの転送に関する。インターネットなどのデータ通信ネットワークの管理のためのシステム内にてマネージャ装置（Ｍ、Ｍ’）とエージェント装置（Ａ、Ａ’）の間で通信（Ｃ１、Ｃ２）を行うのに用いられる典型的な例が、ＳＮＭＰにより提示される。メッセージのペイロード及び好ましくは全体としてのメッセージが、メッセージ中に周期的に現れるシーケンスの認識に基づいて圧縮操作を受ける。
2005500606.tif 000002
【特許請求の範囲】
【請求項１】
ペイロード（ＯＩＤ）を組み込んだメッセージのＵＤＰ（ユーザー・データグラム・プロトコル）上での転送方法であって、メッセージ中に周期的に現れるシーケンスの認識に基づいて少なくとも前記ペイロードを圧縮ステップ（３０２、１０４、２０４）に掛けるステップを含むことを特徴とする前記方法。
【請求項２】
前記圧縮ステップが、ｚＬｉｂなどのｇｚｉｐタイプの技術により実行されることを特徴とする請求項１に記載の方法。
【請求項３】
ＵＤＰ上に転送されるメッセージへの実行された圧縮ステップを示すステップを含むことを特徴とする請求項１又は請求項２に記載の方法。
【請求項４】
実行された圧縮ステップ（３０２）を示すためにＵＤＰヘッダーの１ビットフィールドを用いることを特徴とする請求項３に記載の方法。
【請求項５】
実行された圧縮ステップ（３０２）を示すためにＵＤＰヘッダーのビット６２〜ビット６９のビットを用いることを特徴とする請求項４に記載の方法。
【請求項６】
ＵＤＰメッセージのヘッダーのビット６２〜６９のうちの少なくとも１つを１に設定するステップを含むことを特徴とする請求項５に記載の方法。
【請求項７】
圧縮ステップが以下の操作：
−  ＳＮＭＰメッセージ全体を読み出す操作（１００）、
−  読み出されたメッセージを１６進フォーマットに符号化する操作（１０２）、及び
−  １６進形式に符号化されたメッセージを圧縮に掛ける操作（１０４）
を含むことを特徴とする、ＳＮＭＰメッセージの転送に適用される請求項１〜６のいずれか一項に記載の方法。
【請求項８】
受信ステップが以下の操作：
−  受信したメッセージを前記圧縮ステップに相補的な解凍ステップに掛ける操作（２０４）であって、それにより解凍ステップに掛けられたメッセージを１６進フォーマットにて得ることが可能となる前記操作、
−  １６進フォーマットから開始して解凍ステップ（２０４）に掛けられたメッセージを復号化する操作（２０２）、及び
−  復号化されたメッセージから開始してＳＮＭＰメッセージ全体を再構築する操作（２００）
を含むことを特徴とする、ＳＮＭＰメッセージの転送に適用される請求項１〜７のいずれか一項に記載の方法。
【請求項９】
前記圧縮ステップ（１０４）に掛けられたメッセージの標準ＳＮＭＰメッセージへの封入化操作を含むことを特徴とする請求項７又は請求項８に記載の方法。
【請求項１０】
−  前記圧縮ステップ（１０４）に掛けられたメッセージを数バイトずつ読み出し（１０８）、それをＡＳＣＩＩ文字の対応するメッセージに変換する（１１０）操作、
−  元のファイルのサイズを示す第１ＯＩＤと、前記圧縮ステップ（１０４）に掛けられＡＳＣＩＩ文字に変換された前記メッセージの一部を運ぶ後続のＯＩＤ／値の対とを含んだ、変数結合セットを生成する（１１２）操作、
−  ＳＮＭＰメッセージのヘッダー情報を再構築する操作、
−  ＵＤＰペイロードを生成するため、そのようにして得られたＳＮＭＰメッセージを１６進フォーマットに符号化する（１１４）操作、及び
−  そのように生成されたペイロードをＵＤＰ上に転送する（１１６）操作
を含むことを特徴とする請求項９に記載の方法。
【請求項１１】
受信ステップが、
−  前記圧縮ステップに掛けられたメッセージをＵＤＰペイロードとして受け取る操作（２１６）、
−  そのように受け取られたペイロードを１６進復号化操作に掛ける操作（２１４）、
−  １６進復号化されたメッセージの変数結合を認識し組み立てる操作（２１２）、
−  前記認識し組み立てる操作（２１２）において認識され組み立てられたメッセージを、ＡＳＣＩＩからバイナリへの復号化操作に掛ける操作（２１０）、及び
−  バイナリ形式に復号化されたメッセージを前記解凍ステップに掛ける操作（２０４）
を含むことを特徴とする請求項８及び９又は１０に記載の方法。
【請求項１２】
ＵＤＰ上での封入化により前記圧縮ステップ（１０４）に掛けられたメッセージを統合するステップを含むことを特徴とする請求項７又は請求項８に記載の方法。
【請求項１３】
−  ＵＤＰメッセージのＰＤＵペイロード（ＰＤＵ−ＵＤＰのペイロード）として前記圧縮ステップ（１０４）に掛けられた前記メッセージを構成するステップ、及び
−  このようにして作られたＰＤＵ−ＵＤＰのペイロードを送信器の所与の送信ポートから受信器の所与の受信ポートに転送するステップ
を含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
−  受信ポートにて受信したＰＤＵ−ＵＤＰのペイロードとして前記メッセージを受信するステップ、及び
−  前記ＵＤＰメッセージから前記ペイロードを抽出するステップ
を含むことを特徴とする請求項１３に記載の方法。
【請求項１５】
送信端末（Ｍ、Ｍ’；Ａ、Ａ’）と受信端末（Ａ、Ａ’；Ｍ、Ｍ’）間でＳＮＭＰタイプの同期メッセージを伝送し、前記送信ポート及び／又は前記受信ポートを識別するステップを含むことを特徴とする請求項１３又は請求項１４に記載の方法。
【請求項１６】
少なくとも１つのマネージャ装置（Ｍ、Ｍ’）と少なくとも１つのエージェント装置（Ａ、Ａ’）とを備え、メッセージの伝送により少なくとも１つのチャンネル（Ｃ１、Ｃ２）上にて互いに通信し、データ通信ネットワークを管理するためのシステムであって、請求項１〜１５のいずれか一項に基づいた方法に続いて前記メッセージがＵＤＰ上を転送されることを特徴とする前記システム。
【請求項１７】
デジタルプロセッサの内部メモリ中に直接ロード可能なデータ処理プロダクトであって、該プロダクトがデジタルプロセッサ上にて実行されるとき、請求項１〜１５のいずれか一項に記載の方法を実行すべくソフトウエアコード部を含む前記データ処理プロダクト。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＵＤＰ（ユーザー・データグラム・プロトコルの略）トランスポートを用いるメッセージ、例えばＳＮＭＰ（シンプル・ネットワーク管理プロトコル）メッセージなどの転送に関する。
【０００２】
これらのメッセージは、インターネットなどのデータ通信ネットワーク内にて生成され伝送される。インターネットプロトコルのアーキテクチャーは、４つの論理層、すなわちアプリケーション、トランスポート、ネットワーク及びリンク層に基づいている。
【０００３】
ＳＮＭＰメッセージは、ネットワーク・マネージャ・システム（ＮＭＳ）と管理されているノードとの間での単純な通信機構を実施する。これは、「ネットワーク・マネージャ」と称されるＮＭＳ及び「エージェント」と称されるノードにそれぞれ設けられた特定のアプリケーションによって可能となる。従って、ＳＮＭＰメッセージはＵＤＰレベルにて発生し、そのような目的のためのトランスポートとしてＵＤＰを用いる。
【背景技術】
【０００４】
背景技術
それぞれがＳＮＭＰメッセージに対するネットワークマネージャを備えた「エージェント」と称されるアプリケーション（以下、エージェント）は、一般に「管理情報ベース」又は略してＭＩＢと称されるデータベースと連携してきた。このようなデータベース内では、対応するノード又はネットワーク要素の管理や監視に関する情報が集められる。このような情報としては特に以下のものが挙げられる。
−  ネットワーク要素についての情報を引き出すためにネットワークマネージャにより読み出すことができるＭＩＢ変数；
−  ネットワーク要素に作用するためにネットワークマネージャにより書き込むことができるＭＩＢ変数；及び
−  同じエージェントが特定の状況に関してネットワークマネージャ（マネージャ）に向けて生じさせ得るイベント（トラップ）。
【０００５】
従って、ＳＮＭＰレベルでの通信は本質的に、
−  ネットワークマネージャにより送出された上記変数（ＧｅｔＲｅｑｕｅｓｔ、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ、ＳｅｔＲｅｑｕｅｓｔ、ＧｅｔＢｕｌｋ）を読出し／書込みするのに必要なメッセージ、及び
−  エージェントにより伝送された応答メッセージ（ＧｅｔＲｅｓｐｏｎｓｅ）とトラップメッセージ
を含む。
【０００６】
エージェントにより管理される総ての変数／トラップのセットは、ネットワーク要素に密接に結びつき、特に関係するＭＩＢを表し、すなわちそれらは、ネットワーク要素の動作モードと固有の特性とをネットワークマネージャに示す。
【０００７】
各々の変数又はトラップは、オブジェクト識別子又はＯＩＤと称されるＡＳＮ．１表記法（アブストラクト・シンタックス・ノーテーション・ワン）でのストリングにより個別に識別される。
【０００８】
ストリングのフレームワークは、例えば「１．３．６．１．２．１．４．２１」型であり、ＡＳＮ．１表記法によって階層型ツリー構造に従ったオブジェクトの表現が可能になることを示している。
【０００９】
ＭＩＢの一部が標準として定義され、いずれのエージェントによってもサポートされているが、その他の変数といくつかのトラップは、各製造者には明確であり、ある場合には特定の装置類型の特性を示している。
【００１０】
１９８８年に生まれたＳＮＭＰプロトコルは、その間にいくつかの発展を遂げた。特に、エージェントが理解できなければならない新しいメッセージ類型が定義された。各エージェントがサポートできなければならないＭＩＢ規格が拡張されてきた。この出願の出願日時点で使用されているバージョンは第１及び第２バージョンであるが、現在バージョン３の規格化が進行中である。
【００１１】
ＭＩＢのサイズは、装置の種類によって変わり、数百ＯＩＤに対応するほぼ数百キロバイト程度にさえなり得る。
【００１２】
添付図面の図１は、ＳＮＭＰメッセージの典型的な構成要素を示す。各構成要素の内容はＡＳＣＩＩ文字で書き込まれ、最大許容サイズは、ＵＤＰメッセージの最大サイズに等しく、それを運ぶデータエンティティ(entity)は６５，５０７バイト又はオクテット（そのうち約６４キロバイトが運ばれる情報に対して予定される）に等しい。
【００１３】
特に、図１において、メッセージヘッダーとＰＤＵ（プロトコル・データ・ユニット）部分があるのが分かるが、そのうち１で示した部分が、ＧｅｔＲｅｑｕｅｓｔ、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ、ＳｅｔＲｅｑｕｅｓｔ及びＧｅｔＲｅｓｐｏｎｓｅなどのメッセージを収集し、２で示した部分が、ＧｅｔＢｕｌｋメッセージを収集するが、３で示した部分は一般にトラップ型メッセージに関係する。
【００１４】
さらに具体的には、ＳＮＭＰメッセージのヘッダー中には、以下の情報、すなわち
−  バージョン番号：メッセージの作成に用いられるＳＮＭＰバージョンの番号（Ｖ１、Ｖ２、Ｖ３、・・・）、及び
−  コミュニティ名：ＭＩＢモジュール中に含まれるオブジェクトに対して読出し及び書込みによってアクセスすることを許容する一種のパスワードが存在する。
【００１５】
ＰＤＵ内では以下の情報が利用可能である。
−  ＰＤＵタイプ：バージョン１ではＧｅｔＲｅｑｕｅｓｔ、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ、ＳｅｔＲｅｑｕｅｓｔ及びＲｅｑｕｅｓｔなどの命令を含み、バージョン２ではＧｅｔＢｕｌｋＲｅｑｕｅｓｔ及びＩｎｆｏｒｍＲｅｑｕｅｓｔなどの命令を含むこともできるメッセージ類型；
−  リクエストｉｄ：マネージャが要求された応答と適当なレファレンスを関連付けることができるように、マネージャによって割り当てられ、答えるときエージェントによって利用されるメッセージの個々の識別子；
−  エラーステータス：応答メッセージを除いて総てのメッセージ類型に０が設定され、もし１に設定されているならば、エラーが存在していることを意味する；
−  エラーインデックス：要求された変数（ＯＩＤ）のうちのどれがエラーを生じさせたかを示す；及び
−  変数結合(Variable Bindings)：これらはＯＩＤ／値の対であり、この値はリクエストの場合には「ヌル」であり、応答メッセージの場合には編集される。
【００１６】
特に、図１のちょうど左側の部分は、上述の変数結合を収集する部分の典型的な構造を示す。
【００１７】
本発明において添付図面のいくつかの図に現れるキャプションでは、検討中の異なる要素に対して対応する頭字語／名称／イニシャルを英語にて記載することにした。
【００１８】
このことは、明確かつ簡単な記載のために為されたものである。上述の頭字語、名称及びイニシャルは、これまで異なる国の言語に翻訳されてこなかったので、現在のところ当該技術の熟達者によって国際レベルにて使用されている。
【００１９】
ＵＤＰ上にて可能とされたＳＮＭＰメッセージの伝送によって、ネットワークにリンクされた２つのコンピュータ間でのデータパケット交換が可能である。すなわち、ＵＤＰメッセージのフォーマットは、ヘッダーから成り、その主データは、メッセージを伝送するコンピュータのＩＰアドレス、宛先コンピュータのＩＰ及びトランスポートされているＰＤＵのサイズである。ＰＤＵフォーマットは、ヘッダー部分と、一般に「ペイロード」又は「オクテットデータ」と称されるデータ部分とにより形成される。従って、ヘッダーは、以下のデータ、すなわちソースポート、宛先ポート、トランスポートされるユニットのサイズ、データユニットの完全性チェック（チェックサム）を含む。
【００２０】
ＵＤＰ上にてＳＮＭＰメッセージを（マネージャからエージェントに及びその逆に）転送するために一般に採用される方法は、完全なＳＮＭＰメッセージがＢＥＲ（ベーシック・エンコーディング・ルール）法により符号化されるということに本質的に基づいている。この操作方法により、ＳＮＭＰメッセージを形成するバイトを、ＵＤＰメッセージのペイロードとして用いるのに適した１６進構造に変換することができる。
【００２１】
このようにして得られたデータのＵＤＰ転送サービスは、本質的に以下のものを想定する。
−  伝送ステージ：ＵＤＰ上での伝送のための、ＳＮＭＰメッセージの読出し、及びそれに続くメッセージの１６進符号化（ＢＥＲエンコード）、及び
−  受信ステージ：ＵＤＰ上での受信後の、ＰＤＵの１６進復号化（ＢＥＲデコード）、及びそれに続くメッセージの再構築。
【００２２】
現在のアプリケーションの実践によって、インターネットなどのデータ通信ネットワークにおいて、ＳＮＭＰメッセージの形態にて伝達されるリクエスト／応答によって情報バルクを転送する必要が生じているのが分かった。
【００２３】
情報の全体サイズ、関係する転送に要する時間、及びそのように発生されたネットワークトラヒックゆえに、標準フォーマットにてＳＮＭＰメッセージを転送するのに従来採用されている解決策は、一般により劣った効率を示す。
【００２４】
このため、この問題に取り組むべく３つのＩＥＦＴ規格が既にドラフトレベルにて提案されている。
【００２５】
第１の提案（SNMP Object Identifier Compression, rev. April 2001−draft-ietf-eos-oidcompression-00.txtとして公知）は、ＭＩＢ中に含まれる情報の大部分が、ＯＩＤにより参照され、また、一定かつより大きな部分と可変かつ非常に小さい部分とによって形成されるという概念に基づいている。この原理から開始して、この提案の目的は、より短い番号付けによってＯＩＤの一定部分をアルゴリズムに従って符号化することである。この解決策は、サイズを大きく縮小させることなく、転送されている情報量を部分的にのみ最適化する。
【００２６】
第２の提案（「Efficient Transfer of Bulk SNMP Data, rev. April 2001-draft-ietf-eos-snmpbulk-00.txt」として公知）は、所与の情報セットの同時の収集を可能にするＧｅｔＢｕｌｋ命令の管理の問題に直面している。ＳＮＭＰバージョン２に導入された命令は、収集の最適化を可能にしない。というのは、マネージャは、いくつの要素が要求される情報セットを形成するかを知ることなく、収集される要素の数を宣言しなければならないからである。ＵＤＰプロトコルの修正が、メッセージのエンコードアルゴリズム（ＢＥＲからＰＥＲへであり、これはパケット・エンコーディング・ルールを表す）の変更によって、又はＦＴＰ（ファイル転送プロトコルの頭字語）の転送モードによって示唆された。上記引用文献に記載された解決策は、ＧｅｔＣｏｌｓＲｅｑｕｅｓｔと称されるエージェント側の新しい命令と、転送される要素数の認識、要求セットの終わりの識別、及びよってリクエストとネットワークトラヒックの最適化が可能なマネージャ側の関連メッセージとの導入である。しかしながら、この解決策もまた、送られているメッセージのサイズと数についての管理を最適化することができない。
【００２７】
考慮される第２の提案（「SNMP Payload Compression - rev. April 2001 - draft-irtf-nmrg-snmp-compression-01.txt」として公知）は、原理的に第１の提案と同様である。というのは、「ＯＩＤデルタ圧縮」又はＯＤＣと称される差動エンコーディングアルゴリズムを示唆しているからである。ＯＩＤルートから開始して、このような解決策は、ＯＩＤルートに関連したコードをＯＩＤに割り当てる後続のＯＩＤを記憶した後に、ＯＩＤの一部を変えることを想定する。実質的に、ルート要素と比較して、変化が差動インクリメントにより記憶される。この解決策は、プロトコルの前のバージョンと互換性がないことが欠点である。また、特に再帰的なＯＩＤ値、すなわちデータアレイに対して約３０％のおおよその節約が可能であり、再帰的な項目の数が少ない場合には実質的に非効率である。
【非特許文献１】
「シーケンシャルデータ圧縮のための汎用アルゴリズム(A Universal Algorithm for Sequential Data Compression)」、Ziv. J., Lempel a.、IEEE Transactions on Information Theory, Vol. 23, No. 3、第３３７〜３４３頁
【発明の開示】
【発明が解決しようとする課題】
【００２８】
発明の開示
本発明の目的は、マネージャ側のみならずエージェント側でもプロトコルと性能に影響を与えることなくＳＮＭＰメッセージなどのメッセージのＵＤＰ上での転送を最適化できるように、上記解決策と比較して代替的な解決策を提供することである。
【課題を解決するための手段】
【００２９】
本発明によれば、上記目的は、特許請求の範囲に特定した特徴を有する方法によって達成される。別に、本発明はまた、関連のシステム及びデータ処理プロダクトにも関し、これは、コンピュータの内部メモリに直接ロード可能であり、かつ、上記データ処理プロダクトがコンピュータ上にて実行されるときに本発明による方法を実施すべくソフトウエアコード部分を組み込む。
【００３０】
本質的に、本発明による解決策は、メッセージ全体（ヘッダーとＰＤＵ）の圧縮に基づいている。
【００３１】
特に、２つの異なる転送モードが予見される。第１のものは、ＳＮＭＰメッセージを専有(proprietary)タイプの新しいＳＮＭＰメッセージに封入(encapsulate)し、それをＵＤＰを用いて標準的なモードにて送る。
【００３２】
第２のものは、ドライバーによりＵＤＰを直接駆動し、データオクテットとしてＳＮＭＰメッセージの圧縮結果を与える。
【００３３】
この圧縮技術は、本質的にはメッセージ内にて周期的に現れるシーケンスの認識に基づいている。
【００３４】
本発明の特に好ましい実施態様では、使用される圧縮技術は、ＬＺ７７（論文「シーケンシャルデータ圧縮のための汎用アルゴリズム(A Universal Algorithm for Sequential Data Compression)」、Ziv. J., Lempel a.、IEEE Transactions on Information Theory, Vol. 23, No. 3、第３３７〜３４３頁参照）として公知の技術の変形であり、ＵＮＩＸ環境において周知であり、ｇｚｉｐと称され（gzip format - RFC 1952）、これもより普及しているＰＫＺＩＰにより使用される。このような技術の仕様は一般に公知であり、ソースライブラリも利用可能であり、異なる環境やＰＨ−ＵＸ、Ｄｉｇｉｔａｌ、ＢｅＯＳ、Ｌｉｎｕｘ、ＯＳ／２、Ｊａｖａ、Ｗｉｎ３２、ＷｉｎＣＥなどの異なるオペレーティングシステムに対するこのような解決策を実施し使用するものである。
【００３５】
特に、「ｚＬｉｂ」ライブラリを使用することによりｗｉｎ３２上にてアルゴリズムのポーティング(porting)を用いることができる。参考のため、インターネットサイトhttp://www.info-zip.org/pub/infozip/zlib/を参照することができる。このライブラリの主な特徴は、バイナリデータ構造及びストリングの両方についてランタイムかつオンメモリの圧縮が可能なことであり、このことはシステム性能に関する重要なファクターである。
【００３６】
図面の簡単な説明
以下、添付図面に関し、非制限的な例として本発明を説明する。
−  図１は背景技術に関するものであり、既に上記説明した；
−  図２は、本発明による解決策の典型的なアプリケーションアーキテクチャーについての一般的なブロック図である；
−  図３〜５の各々は、それぞれ送信（パートａ）と受信（パートｂ）に関係する２つの部分に分割されており、本発明による解決策の異なる種類の実施態様についてのフローチャートを示す；
−  図６は、本発明による解決策の一般的な特徴を示す追加のフローチャートである；
−  図７及び８は、図１で採用したものと実質的に同様の様式により、本発明による解決策の具体化基準を２つの可能な変形にて示す。
【発明を実施するための最良の形態】
【００３７】
発明を実施するためのベストモード
図２の概略図において、符号Ｎは、本発明による解決策の典型的なアプリケーション環境を定めるデータ通信ネットワーク（直接的な例としてインターネットを考えることができる）を示す。
【００３８】
符号Ａは、一般に「エージェント」と称されるモジュールを示し、これはネットワークＮの対応する要素を制御しモニターする機能を実行し、対応するマネージャＭと双方向の対話モードにて動作する。
【００３９】
後者（マネージャＭ）は、より高い階層レベルの追加エージェントＡ’と共に、ポート又はゲートＧを定め、こんどはこれがより高い階層レベルの追加マネージャＭ’とインターフェースする。
【００４０】
後者（マネージャＭ’）は、対応するアプリケーションと共に、観測モジュール又はオブザーバーＯを定める。
【００４１】
符号Ｃ１及びＣ２は、２つの双方向通信チャンネルを示し、下位の階層レベルにてエージェントＡとゲートＧの間での通信、及び上位の階層レベルにてゲートＧとオブザーバーＯとの間での通信を行う。
【００４２】
上記チャンネルＣ１、Ｃ２は、その上にてＳＮＭＰメッセージの伝送が行われるものである。
【００４３】
図３のフローチャートは、ＳＮＭＰメッセージの圧縮（図３ａ）及び解凍（図３ｂ）のために採用された様式を示す。
【００４４】
図４のフローチャートは、ＳＮＭＰに対する封入により圧縮されたＳＮＭＰメッセージの転送を想定する第１の解決策（これも送信は図４ａを受信は図４ｂを参照）を示す。
【００４５】
図５のフローチャートは、転送の代わりにＵＤＰに対する封入による解決策を示す。これも送信（図５ａ）と受信（図５ｂ）を特定して参照している。
【００４６】
図７及び８は、ＯＩＤ表現に関して図１と同じ形式を示し、圧縮と伝送操作のセットを示し、これらはそれぞれ図３及び４のパートａ（図７）と図３及び５のパートａ（図８）とにより例示される。
【００４７】
まず図３のフローチャートを調べると、符号１００は、ＳＮＭＰメッセージ全体（ヘッダー＋ＰＤＵ）を読み出すステップを示し、次に、１０２で示された次のステップ中にて１６進フォーマットに変換又はエンコードされる。これは、ＢＥＲエンコードタイプのコーディングを適用することにより達っせられる。
【００４８】
次に、このようにエンコードされたメッセージは、再帰的シーケンスの認識に基づいた圧縮技術、例えば上述したｚＬｉｂライブラリにある技術などを用いることにより圧縮される。
【００４９】
これは、１０４で示されたステップ中に行い、１０６で示されたステップ中では、伝送の準備が整った圧縮されたデータユニットを得る。
【００５０】
全く対称的に、図３のパートｂのフローチャートも、４つのステップ、すなわち２０６、２０４、２０２及び２００（示されたシーケンスに従って実行すべく設計されている）を組み込んでおり、受信した圧縮データユニット（ステップ２０６）は、次の１６進復号化（ステップ２０２）やその次のＳＮＭＰメッセージ全体の再構築（ステップ２００）を目的にして、解凍がなされる（ステップ２０４）。
【００５１】
図３のパートｂのフローチャートにその動作シーケンスに関して逆に並べ変えた参照番号を割り当てるのは、圧縮手順のステップ１００〜１０６に対称的な特徴を強調するためのみを目的としている。同様のことは、図４と図５のフローチャートに関しても行った。
【００５２】
既に示されているように、図４及び７は、圧縮されたデータユニットを標準的なＳＮＭＰメッセージに封入することを想定した転送案を参照しており、これは、ＵＤＰ上での標準的な伝送形式による専有又は独特の「変数結合(Variable Binding)」を特徴とする。
【００５３】
ステップ１０６中に得られた圧縮データユニットの封入様式は、１０８で示された初期ステップを組み込み、このステップ中にて圧縮データが数バイトずつ読み出され、１１０で示された次のエンコードステップ中にて対応するＡＳＣＩＩ文字セットに変換される。
【００５４】
１１２で示された次のステップ（場合によってはＡＣＫ  ＴＡＢ＋ＮＵＬＬなどの補助機能が先行し得る。図７のブロック１１０ａ参照。）において、専有又は独特の番号付け（例えば１．３．６．１．４．６６６．１）と共に第１ＯＩＤにより形成されたメッセージからなる「変数結合」が生成され、この番号付けはその値中に＿ＺＩＰ＿ｘｘｘｘなるストリングを含む。このｘｘｘｘは元のファイルのサイズを示す。上記の例では、独特コードたる６６６．１が示されており、これは現在のところＩＡＮＡ（Internet Assigned Numbers Authority）に登録されていないが、登録されていない他のどんなコードでも使用できる。
【００５５】
適切にＡＳＣＩＩ文字に変換された、圧縮されたデータユニットを含んだ変数結合の後続の要素は、ＯＩＤ／値の対によって形成される。この値は、ＡＳＣＩＩに変換され、２５５文字の最大サイズを有する圧縮されたデータユニット部分を含む。
【００５６】
次に、ＳＮＭＰメッセージのヘッダー情報が再構築される。このことは総てステップ１１２中に行われ、その後に続くステップ１１４にて、データ伝送に用いられるＵＤＰメッセージのＰＤＵペイロード（ＰＤＵ−ＵＤＰのペイロード）を生成するために、ＢＥＲ法による追加のエンコードが実行される（ステップ１１６）。
【００５７】
この場合においても、２１６、２１４、２１２、２１０及び２０８により示され、図４のパートｂにて再現され、前に述べた順序に従って実行されるべく構成されたステップは、送信動作に関係したステップ１０８〜１１６のデュアル機能（受信側にて実行されるべきもの）を表す。
【００５８】
従って、図４及び７が参照される解決策を採用することにより、圧縮されたＳＮＭＰメッセージは、標準的な論理ＳＮＭＰフォーマットと、専有又は独特の内容を有する。よって、たとえ小さくともエージェントのマネージャの機能の拡張、例えばその認識及び符号化／復号化を可能にすることなどが要求される。
【００５９】
出願人が行った実験により、このような解決策はネットワークアーキテクチャーに影響を与えることなく十分実現可能であることが分かった。
【００６０】
図５及び８が参照する代替の解決策は、図３に示された形式に従ってＳＮＭＰメッセージから開始して圧縮データユニットを作成し、その後に前記データユニットをＰＤＵ−ＵＤＰのペイロードに直接封入することを想定する。
【００６１】
正確な操作のためには明らかなように、この解決策では、例えば標準的なものとは異なるＵＤＰポートの利用が保証された条件下にて専用の送信器と受信器の使用が必要とされる。従って、送信器は、受信器により用いられるＵＤＰポートを知らなければならず、逆もまた同様である。使用されているポートについての情報は、後に詳しく説明する基準に従って上位レベルにて標準的なＳＮＭＰフォーマットの同期メッセージによって交換され得る。
【００６２】
図５及び８に示された代替の解決策が採用されると、ステップ１０８中に利用可能とされ且つメッセージのＢＥＲを置換するよう構成された圧縮データユニットが、ＰＤＵ−ＵＤＰメッセージのペイロードになる。
【００６３】
関係する操作が、図５及び８中に１１８及び１２０で示されたステップにより略示される。これらのステップの後に、受信器のそれぞれの専用ポート（一般にポートＸと称する）のために構成された伝送ステップ１２２が続く。
【００６４】
この場合にも、相補的な操作は、３つのステップを組み込み、それぞれ２２２（その時に受信器として動作するモジュールのポートＹでの受信）、２２０（ＰＤＵ−ＵＤＰのペイロードの抽出）、及び２１８（図３のパートｂのフローチャートのステップ２０６に転送されるよう構成された、受信された圧縮データユニットの取得）により示される。
【００６５】
この場合にも、言及された順番に従ってステップ２２２、２２０及び２１８が実行される。
【００６６】
前に参照した同期メッセージは、専有又は独特の「変数結合」を含んだ標準的なＳＮＭＰフォーマットを用いた一般的な原理「アプリケーション対アプリケーション」に従って、マネージャによりＳＮＭＰエージェントに送出される。
【００６７】
転送される情報は、以下のタイプとし得る。
【表１】
2005500606.tif 000003
【００６８】
マネージャは、ＳＮＭＰマネージャに専有メッセージを送り、ＵＤＰ受信に用いるポート数を用いて値＜ＵＤＰ＿ＲＸ＿Ｐｏｒｔ＞を編集するだけでなく（例えば１２２４）、ＵＤＰ送信に用いるポート数を用いて値＜ＵＤＰ＿ＴＸ＿Ｐｏｒｔ＞を編集する（例えば１０２４）。
【００６９】
エージェントは、マネージャに応答し、それ自身の情報を含んだ同様のメッセージを送る。この方法は、解決策の効率を改善することにより処理時間を短縮する。
【００７０】
図６のブロック図はさらに、ＵＤＰをトランスポート（例えばＳＮＭＰ、ＰＩＮＧなど）として用いて任意のメッセージ類型に適用するために、どのようにして上記解決策を一般化し得るかを示す。この一般化により、現在使用されているものを置換できるＵＤＰドライバを実現することができる。
【００７１】
この解決策は、転送されるペイロードのサイズを評価すること、及びサイズが適切な場合（例えば２０バイトより大）に、ここに記載の方法を用いることによりさらに進むことが可能である。ＵＤＰメッセージのコンパクトな性質を受信器に宣言するために、ＵＤＰメッセージのヘッダーのビット６５〜ビット６９に含まれる８ビット（現在これらのビットは使用されておらず、デフォルトの０に設定されている）を使用して、これらのビットの例えば１以上を１に設定することができる。
【００７２】
特に、図６では、符号３００は、ＵＤＰ上をトランスポートされ得るメッセージを送出する必要が生じる任意のステップを示し、その後に、図３に記載の様式に従って実行されるペイロードの圧縮ステップ３０２が続く。
【００７３】
次のステップ３０４は、上記想起した用語に従ったＵＤＰメッセージヘッダーの生成を想定するが、３０６で示した次のステップは、そのＩＰ伝送を目的に３０８で示したステップ中に実行されるＵＤＰメッセージ全体の作成に対応する。
【００７４】
上述の方法により、ＵＤＰ−ＩＰプロトコル・スタックを利用する任意のタイプのアプリケーションをサポートできる汎用目的の解決策を実現することが可能となる。
【００７５】
上記解決策は、ハードウエア又は「オンチップ」の解決策を実現するのに特に適している。
【００７６】
上記解決策の機能の拡張は、データ転送に用いられている方法、及びメッセージ若しくはその等価ＢＥＲ若しくはデータオクテットＵＤＰの符号化とは関係なく適用できる。この点について、安全で効果的な方法が、現在「ブロック暗号Ｒｉｊｎｄａｅｌ」（「ＡＥＳ」ともいう）と称されるものであると思われる。
【００７７】
ここに記載の解決策は、柔軟な圧縮技術を統合的に参照するだけでなく、他の圧縮技術（ＭＰＥＧなど）も参照し、本明細書の冒頭で述べた欠点を克服してＳＮＭＰメッセージを圧縮することが出来るという利点を有する。この解決策を再利用可能かつ再実施可能な解決策にすることができるこのような技術とそのアルゴリズムは、いくつかのオペレーティングシステムにおいて用いることができる。また、この解決策は、メッセージの圧縮及び解凍のために単純な上部構造のセットアップを必要とするので、マネージャとエージェントの両方に対する影響が最小である。
【００７８】
この解決策は、転送によるネットワークトラヒックの最適化、等しい時間間隔、より少ない数のメッセージによるより多量の情報又は同量の情報を可能にするので、効率的であることも分かった。また、本解決策は、情報が圧縮され符号化されてクリアテキストにてネットワーク内を移動するので、安全な解決策でもある。
【００７９】
明らかに、本発明の原理は変えず、特許請求の範囲に記載の発明の思想及び範囲から逸脱することなく、本発明の実施の詳細とその実施態様を、ここに記載してきたことに対して相当変更することができる。
【図面の簡単な説明】
【００８０】
【図１】背景技術に関する説明図である。
【図２】本発明による解決策の典型的なアプリケーションアーキテクチャーについての一般的なブロック図である。
【図３】本発明による解決策の実施態様についてのフローチャートであり、送信（パートａ）と受信（パートｂ）に関係する２つの部分に分けて示す。
【図４】本発明による解決策の実施態様についてのフローチャートであり、送信（パートａ）と受信（パートｂ）に関係する２つの部分に分けて示す。
【図５】本発明による解決策の実施態様についてのフローチャートであり、送信（パートａ）と受信（パートｂ）に関係する２つの部分に分けて示す。
【図６】本発明による解決策の一般的な特徴を示す追加のフローチャートである。
【図７】図１で採用したものと実質的に同様の様式により、本発明による解決策の具体化基準を示す。
【図８】図１で採用したものと実質的に同様の様式により、本発明による解決策の具体化基準を示す。
【符号の説明】
【００８１】
Ａ    エージェント
Ａ’  追加エージェント
Ｍ    マネージャ
Ｍ’  追加マネージャ
Ｎ    データ通信ネットワーク
Ｇ    ゲート
Ｏ    オブザーバー
Ｃ１、Ｃ２    双方向通信チャンネル
【図１】
2005500606.tif 000004
【図２】
2005500606.tif 000005
【図３】
2005500606.tif 000006
【図４】
2005500606.tif 000007
【図５】
2005500606.tif 000008
【図６】
2005500606.tif 000009
【図７】
2005500606.tif 000010
【図８】
2005500606.tif 000011
【国際公開パンフレット】
2005500606.tif 000012
2005500606.tif 000013
2005500606.tif 000014
2005500606.tif 000015
2005500606.tif 000016
2005500606.tif 000017
2005500606.tif 000018
2005500606.tif 000019
2005500606.tif 000020
2005500606.tif 000021
2005500606.tif 000022
2005500606.tif 000023
2005500606.tif 000024
2005500606.tif 000025
2005500606.tif 000026
2005500606.tif 000027
2005500606.tif 000028
2005500606.tif 000029
2005500606.tif 000030
2005500606.tif 000031
2005500606.tif 000032
2005500606.tif 000033
2005500606.tif 000034
2005500606.tif 000035
2005500606.tif 000036
2005500606.tif 000037
2005500606.tif 000038
【国際調査報告】
2005500606.tif 000039
2005500606.tif 000040
2005500606.tif 000041