(57)【要約】【課題】リアセンブル処理によりデカプセル化装置にかかる負荷を低減させ、高速処理を可能とする技術を提供する。【解決手段】公衆ＩＰ網１０を介して接続されたデカプセル化装置３に送信すべきパケットをカプセル化するためのカプセル化装置２において、パケットがネットワークにおけるＭＴＵ（Maximum Transmission Unit）を超える場合には、パケットのフラグメントを実施する。デカプセル化装置３におけるリアセンブル処理状態を標示するリアセンブル処理情報をデカプセル化装置３から受信し、受信したリアセンブル処理情報に基づいて、カプセル化処理及びフラグメント処理の処理順序を設定する。【選択図】図２
2010011344.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して接続された他の装置に送信すべきパケットをカプセル化するためのパケット処理装置であって、
前記パケットが前記ネットワークにおける１回の転送で送信できるデータの最大値を超える場合には、該パケットのフラグメントを実施するフラグメント手段と、
前記他の装置におけるリアセンブル処理状態を標示するリアセンブル処理情報を該他の装置から受信する受信手段と、
前記受信したリアセンブル処理情報に基づいて、カプセル化処理及びフラグメント処理の処理順序を設定する設定手段と、
を備えたことを特徴とするパケット処理装置。
【請求項２】
前記リアセンブル処理情報には、組立メモリ使用率、組立タイムアウト統計及び送信待ちパケット統計のうち少なくとも１つが含まれ、
前記設定手段は、前記リアセンブル処理情報が所定のしきい値を超える場合には、フラグメント処理をカプセル化処理よりも先に実施するよう処理順序を変更する
ことを特徴とする請求項１記載のパケット処理装置。
【請求項３】
ネットワークを管理するためのプロトコルであるＳＮＭＰ（Simple Network Management Protocol）を実装して前記ネットワークに接続された機器を管理するＳＮＭＰマネージャ、
を更に備え、
前記ＳＮＭＰマネージャは、前記ＳＮＭＰマネージャの管理対象であるＳＮＭＰエージェント及びＳＮＭＰを利用して収集した情報を管理情報であるＭＩＢ（Management Information Base）情報として格納する格納手段を備えた前記他の装置からＳＮＭＰ通信により該ＭＩＢ情報を収集し、
前記設定手段は、前記ＭＩＢ情報から求めた前記リアセンブル処理情報を参照して、カプセル化処理及び前記フラグメント処理の処理順序を設定する
ことを特徴とする請求項２記載のパケット処理装置。
【請求項４】
前記パケットは、トンネリングあるいは暗号化通信を行うためのプロトコルであるＩＰｓｅｃ（Security Architecture for Internet Protocol）によりカプセル化されたパケットから構成される
ことを特徴とする請求項２記載のパケット処理装置。
【請求項５】
ネットワークを介して接続された他の装置から受信したパケットをデカプセル化するためのパケット処理装置であって、
前記他の装置から受信したパケットを参照し、該パケットについて、カプセル化処理の後にフラグメント処理が実施されている場合には、該パケットのリアセンブルを実施するリアセンブル手段と、
前記リアセンブル手段における処理状態を標示するリアセンブル処理情報を前記他の装置に対して通知する通知手段と、
を備えたことを特徴とするパケット処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケットのカプセル化／デカプセル化技術に関し、特に、ＭＴＵ（Maximum Transmission Unit）によりフラグメントを伴うパケットについてのカプセル化／デカプセル化技術に関する。
【背景技術】
【０００２】
トンネルカプセル化パケットを終端するトンネルカプセル化パケット処理装置においては、ネットワークにおいて１回の転送で送信できるデータの最大値であるＭＴＵを超えるＩＰ（Internet Protocol）パケットをカプセル化する場合は、パケットのフラグメントを実施する必要がある。
【０００３】
ここで、企業ＩＰ網Ａから受信したパケットをパケット処理装置Ａ（カプセル化装置）においてトンネルカプセル化し、公衆ＩＰ網を介してパケット処理装置Ｂ（デカプセル化装置）に送信し、パケット処理装置Ｂは、受信したトンネルカプセル化パケットをデカプセル化して企業ＩＰ網Ｂに渡す場合を考える。
【０００４】
図８は、企業ＩＰ網及び公衆ＩＰ網のＭＴＵの組み合わせとトンネルカプセル化パケットのフラグメントの要否との関係を示す図である。ここでは、トンネリングプロトコルのオーバーヘッドは、６０バイトとする。また、企業ＩＰ網Ａから公衆ＩＰ網（トンネルネットワーク）を介して企業ＩＰ網Ｂに転送されるＩＰパケットのサイズは、１５００バイトとする。
【０００５】
１５００バイトのＩＰパケットをカプセル化すると、トンネリングプロトコルのオーバーヘッドにより、パケットサイズは１５００バイト超となる。このため、公衆ＩＰ網のＭＴＵが１５００バイトのネットワーク構成すなわち図８の項番１及び３のネットワーク構成においては、フラグメントが必要となる。
【０００６】
図９は、従来におけるパケットのカプセル化処理を示したフローチャートであり、上記の構成例では、パケット処理装置Ａにおいて実行される処理を示す。
図９に示すように、従来においては、まずパケットのカプセル化を行い、カプセル化の後に、ＭＴＵに応じてフラグメントが必要なパケットについてフラグメントを行っていた。
【０００７】
フラグメントされたパケットを受信したパケット処理装置Ｂにおいては、デカプセル化する前にリアセンブルを実施する必要がある。接続するカプセル化装置数が多くなると、デカプセル化装置において処理すべきパケット量も増大し、これに伴って、リアセンブルに伴う負荷も増大する。
【０００８】
公知技術として、インターネットワーク装置（ルータ）が、隣接ホストとの通信相手となるホストとの間のＴＣＰコネクションを監視し、ＴＣＰのフロー制御による回線使用率の低下を検出すると、相手ホストに代って隣接ホストに対して受信確認セグメントを送ることにより、遅延を克服することのできる技術が提供されている（例えば、特許文献１）。
【０００９】
また、通信サーバが、ネットワークを介してクライアントより受信したＩＰパケットあるいはリアセンブルしたＩＰパケットをバッファリングし、バッファリングしたデータをカプセル化して高速バスパケットとして高速バス上に送出するとともに、高速バスを解し
て受信した高速バスパケットからＩＰパケットを取り出し、フラグメント化してネットワークに送出することにより、通信処理にかかるサーバの負担を分散させる技術が提供されている（例えば、特許文献２）。
【特許文献１】特開平１１−１１２５７６号公報
【特許文献２】特開２０００−１０１６１３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
高速処理が要求されるネットワークでは、リアセンブルに伴う処理負荷の増大により、大量のトンネルセッションとトラフィックフローを処理する際には、デカプセル化装置のパフォーマンスが低下することがある。パフォーマンスの低下により生じるケースには、組立メモリ不足、組立タイムアウト、パケット送信待ち等がある。
【００１１】
図１０、図１１及び図１２は、従来技術に係るデカプセル化装置において発生する問題を説明する図である。
図１０に示すように、カプセル化装置からフラグメントパケットを受信すると、デカプセル化装置は、まず、リアセンブル処理部においてパケットのリアセンブルを行う。リアセンブル処理部は、セッションごとにリアセンブル用の組立メモリを用意して、受信したパケットのリアセンブルを行ってデカプセル化処理部にパケットを渡す。処理すべきパケットが増大すると、デカプセル化装置が備える組立メモリの不足によりパケット廃棄が発生し、デカプセル化装置全体のパフォーマンスも低下することとなる。
【００１２】
図１１に示すように、リアセンブル処理部においてパケットの処理に要する時間が増大すると、組立タイムアウトが発生することとなる。組立タイムアウトが発生すると、デカプセル化装置は、ＩＣＭＰ（Internet Control Message Protocol）にしたがってカプセル化装置に対して所定のメッセージ（図１１に示す例ではＴｙｐｅ＝１１のメッセージ）を送信しなければならない。ＩＣＭＰによる処理を実行するために、デカプセル化装置のパフォーマンスが低下することとなる。
【００１３】
図１２に示すように、リアセンブル処理部においてリアセンブル処理が完了したパケットについては、デカプセル化処理部に転送される。リアセンブル処理は、セッションごとに行われるため、複数のパケットについて一斉にリアセンブル処理が完了することも起こり得る。一斉にパケットのリアセンブルが完了した場合であっても、デカプセル化処理部へのパケットの転送については順次組立メモリから読み出して行う必要がある。このため、デカプセル化処理部への送信を待機している間に次のパケットについてリアセンブルを行うための組立メモリが不足して、パケットの廃棄が発生し、デカプセル化装置のパフォーマンスに影響することとなる。
【００１４】
上記のようなデカプセル化処理におけるパフォーマンスの低下を防止するためには、通信の状態等に応じて、デカプセル化装置において、リアセンブル処理にかかる負荷を低減させる構成を備えることが望ましい。
【００１５】
開示のパケット処理装置は、リアセンブル処理によりデカプセル化装置にかかる負荷を低減させ、高速処理を可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【００１６】
開示のパケット処理装置によれば、ネットワークを介して接続された他の装置に送信すべきパケットをカプセル化するためのパケット処理装置であって、前記パケットが前記ネットワークにおける１回の転送で送信できるデータの最大値（ＭＴＵ（Maximum Transmission Unit））を超える場合には、該パケットのフラグメントを実施するフラグメント手段と、前記他の装置におけるリアセンブル処理状態を標示するリアセンブル処理情報を該他の装置から受信する受信手段と、前記受信したリアセンブル処理情報に基づいて、カプセル化処理及びフラグメント処理の処理順序を設定する設定手段と、を備えた構成とする。
【００１７】
リアセンブル処理によりデカプセル化装置（他の装置）にかかる負荷に応じて、カプセル化処理とフラグメント処理の実行順序を変更する。デカプセル化装置においてリアセンブル処理の負荷が増大しているときは、フラグメント処理をカプセル化処理よりも先に実行する。このようにしてカプセル化されたパケットを受信したデカプセル化装置は、自装置においてはリアセンブル処理の実施が不要となる。これにより、デカプセル化装置にかかる負荷を軽減させ、ネットワークの高速化を図ることが可能となる。
【発明の効果】
【００１８】
開示のパケット処理装置によれば、リアセンブル処理によりデカプセル化を行う装置にかかる負荷に応じて、カプセル化処理とフラグメント処理の処理順序を変更する。フラグメントをカプセル化よりも先に実施した場合には、デカプセル化を行う装置においてリアセンブル処理を実施せずにデカプセル化処理のみ実施すれば足りる。これにより、デカプセル化を行う装置にかかる負荷が軽減され、ネットワークの高速化に資する。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の好適な実施の形態について、図面を参照して詳細に説明する。
図１は、本実施形態に係る通信システムの構成図である。図１に示す通信システム１は、カプセル化装置２及びデカプセル化装置３を含み、公衆ＩＰ網１０を介して互いに接続されている。
【００２０】
図１に示す３台のカプセル化装置（装置Ａ、装置Ｍ、装置Ｎ）のうち、本実施形態に係るカプセル化装置２は、装置Ａである。３台のカプセル化装置のそれぞれが、デカプセル化装置３（装置Ｂ）との間でセッションを確立して通信を行う。カプセル化装置及びデカプセル化装置は、それぞれ企業ＩＰ網と接続され、カプセル化装置と接続された企業ＩＰ網側からＩＰパケットを受信すると、パケットのカプセル化を行って、トンネルを利用してデカプセル装置３にパケットを送信する。
【００２１】
本実施形態に係るカプセル化装置２は、企業ＩＰ網１１から受け取ったパケットについてカプセル化する前に、デカプセル化装置３から通知された情報を参照して、デカプセル化装置３におけるリアセンブル処理の状態を判定する。そして、デカプセル化装置３においてリアセンブル処理の負荷が増大しているか否かに応じて、フラグメント処理とカプセル化処理の順序を決定する。決定した順序にしたがって処理したパケットを、デカプセル化装置３宛に送信する。
【００２２】
デカプセル化装置３は、カプセル化装置２から受信したパケットをデカプセル化して企業ＩＰ網１２に渡す。
カプセル化装置２において、従来と同様にカプセル化してから必要なフラグメントをしている場合には、デカプセル化装置３においても、従来と同様の処理を実行する。すなわち、受信したパケットについてまずリアセンブルをし、次にデカプセル化処理を実施する。これに対し、カプセル化装置２において、フラグメントしてからカプセル化を行っている場合には、デカプセル化装置３においては、リアセンブル処理を行わずにデカプセル化処理のみを実施して、企業ＩＰ網１２にパケットを渡す。すなわち、パケットのデカプセル化はデカプセル化装置３で実施し、リアセンブル処理は企業ＩＰ網１２側で実施させる。
【００２３】
このように、本実施形態に係る通信システムを構成するカプセル化装置２においては、通知されたデカプセル化装置３における処理状態を参照し、デカプセル化装置３に係る負荷が増大していると判定した場合には、フラグメント処理とカプセル化処理の順序を変更する。デカプセル化装置３は、カプセル化装置２から受信したパケットが、フラグメント処理を先に実施してからカプセル化したパケットである場合には、デカプセル化処理のみを行い、リアセンブル処理については、自装置では行わない。これにより、デカプセル化装置３にかかる負荷が軽減される。
【００２４】
図２は、本実施形態に係るトンネルカプセル化処理を示すフローチャートである。図２に示す処理は、カプセル化装置２が、図１の企業ＩＰ網１２宛のパケットを企業ＩＰ網１１から受信したことを契機として開始される。
【００２５】
まず、ステップＳ１で、デカプセル化装置３におけるリアセンブル処理状態を判定する。ここでは、事前にデカプセル化装置３から通知された情報に基づいて判定を行う。デカプセル化装置３から通知される情報には、リアセンブル処理状態、すなわち、デカプセル化装置３におけるリアセンブル処理の負荷状況を示す情報が含まれる。デカプセル化装置３から通知される情報に関しては、後述する。
【００２６】
ステップＳ１の判定において、デカプセル化装置３にかかるリアセンブル処理の負荷が大きいと判定されると、ステップＳ２に進む。そして、ステップＳ２で、パケットサイズ及びＭＴＵに応じて必要な場合にはフラグメント処理を実施し、ステップＳ３で、カプセル化処理を実施して、処理を終了する。
【００２７】
ステップＳ１の判定において、デカプセル化装置３にかかるリアセンブル処理の負荷は比較的小さいと判定されると、ステップＳ４に進む。そして、ステップＳ４で、カプセル化処理を実施し、ステップＳ５でフラグメントの要否を判定し、フラグメント不要と判定された場合には、処理を終了する。ステップＳ５の判定において、フラグメントが必要と判定された場合には、ステップＳ６で、フラグメント処理を行い、処理を終了する。
【００２８】
図２に示すように、カプセル化装置２においては、まずデカプセル化装置３におけるリアセンブル処理状態に基づいて、フラグメント処理及びカプセル化処理の実行順序を決定する。デカプセル化装置３においてリアセンブル処理の負荷が大きい場合には、カプセル化処理の前にフラグメント処理を実施する。
【００２９】
なお、ステップＳ４以降の一連の処理、すなわちカプセル化処理を先に実施してから必要に応じてフラグメント処理を行うことについては、従来技術におけるカプセル化処理方法と同様である。本実施形態においては、カプセル化処理を実施する前にステップＳ１においてカプセル化装置３におけるリアセンブル処理状態を判定して、判定結果によってはフラグメントを先に実施させる点に特徴を有する。
【００３０】
図３は、リアセンブル処理状態判定処理の詳細を示す図である。デカプセル化装置３は、定期的にあるいは所定のタイミングで、自装置におけるリアセンブル処理状態を示す情報をカプセル化装置２に通知する。以下、デカプセル化装置２におけるリアセンブル処理状態を示す情報を「リアセンブル処理情報」とし、リアセンブル処理情報をカプセル化装置２に通知するためのパケットを「リアセンブル処理情報通知パケット」とする。
【００３１】
リアセンブル処理情報は、例えば、組立メモリ使用率情報、組立タイムアウト統計情報及び送信待ちパケット統計情報を含む。
組立メモリ使用率情報は、リアセンブル処理用に用意されたメモリ量のうち、新たに公衆ＩＰ網１０を介して受信したパケットをリアセンブルするために使用可能なメモリ量す
なわちリアセンブリ待ちで使用しているメモリ量の割合を表す。
【００３２】
組立タイムアウト統計情報は、リアセンブリ処理中にタイムアウトによりリアセンブリ処理が失敗したパケット数すなわちリアセンブリ処理結果が失敗であった受信ＩＰデータグラム数を表す。
【００３３】
送信待ちパケット統計情報は、リアセンブリ処理部において、リアセンブリが完了し、デカプセル化処理部への転送を待機しているＩＰデータグラム数を表す。
デカプセル化装置３は、これらの情報を求めてパケットのデータ部に格納し、ＩＰヘッダを付してカプセル化装置２に送信する。
【００３４】
カプセル化装置２は、リアセンブル処理情報通知パケットを受信すると、データ部からリアセンブル処理情報を取り出し、取り出した情報に基づいて、図２のステップＳ１の判定を行う。
【００３５】
具体的には、組立メモリ使用率、組立タイムアウト統計及び送信待ちパケット統計のそれぞれについて予め設定された所定の閾値とリアセンブル処理情報に含まれる値のそれぞれとを比較する。そして、いずれかの値が閾値を超えている場合には、フラグメントをカプセル化よりも先に実施することとする。いずれの値も閾値を超えていない場合には、従来における方法と同様に、カプセル化をしてからフラグメントを実施する。
【００３６】
図４は、リアセンブル処理情報の通知方法を説明する図である。実施例では、カプセル化装置２をネットワークに接続された機器を管理するＳＮＭＰ（Simple Network Management Protocol）マネージャとして動作させ、デカプセル化装置３をＳＮＭＰマネージャの管理対象であるＳＮＭＰエージェントとして動作させることで、リアセンブル処理情報の測定及び通知を行っている。なお、ネットワークを管理するためのプロトコルであるＳＮＭＰは公知の技術であるので、ここでは、詳細な説明は省略する。
【００３７】
ＳＮＭＰエージェントとして動作するデカプセル化装置３は、格納部４にＳＮＭＰを利用して収集した情報をＭＩＢ（Management Information Base）として保有している。図４（ｂ）に、格納部４において保有するＭＩＢを例示する。このうち、（１）〜（４）については、標準ＭＩＢで実装されている識別子であり、（５）〜（７）については、プライベートＭＩＢとして追加で実装される識別子である。実施例では、（４）〜（７）の情報を用いてリアセンブル処理情報を求める。
【００３８】
図４（ａ）に示すように、まず、カプセル化装置２が、デカプセル化装置３に対して情報要求を送信し、所望のＭＩＢ情報すなわちリアセンブル処理情報を求めるために必要な情報を要求する。情報要求を受信したデカプセル化装置３は、格納部４から必要なＭＩＢを取り出して、情報要求応答で取り出した情報をカプセル化装置２に伝達する。
【００３９】
上記のとおり、リアセンブル処理情報を求めるには図４（ｂ）の（４）〜（７）の情報が必要である。しかし、このうち（４）、（５）及び（７）の情報は、デカプセル化装置３のリアセンブル処理状況によりその値が変動する。そこで、実施例では、これら（４）、（５）及び（７）の情報については、値が所定のレベルに達した場合にデカプセル化装置３からカプセル化装置２に通知する構成としている。
【００４０】
より具体的には、図４（ａ）に示すように、カプセル化装置２は、デカプセル化装置３に設定要求を送信する。設定要求には、（４）、（５）及び（７）の各情報を通知する条件が含まれる。設定要求を受信したデカプセル化装置３は、設定要求に対して設定要求応答を返すとともに、設定要求に含まれる通知の条件を設定する。
【００４１】
デカプセル化装置３は、（４）、（５）及び（７）の情報について、設定要求に基づいて設定した条件を満たすレベルに達した場合には、リアセンブル処理情報通知パケットのデータ部に情報を格納する。そして、リアセンブル処理情報通知パケットをカプセル化装置２に送信（イベント通知）し、処理を終了する。
【００４２】
カプセル化装置２は、リアセンブル処理情報通知パケットから（４）〜（７）の情報を取り出し、リアセンブル処理情報を算出する。図４（ｃ）において、リアセンブル処理情報の算出方法を例示する。
【００４３】
図４（ｃ）に示すように、組立メモリ使用率については、（（５）リアセンブリ待ちで使用しているメモリ量）／（（６）リアセンブリに使用できるメモリ量）×１００から求められる。組立タイムアウト統計は、（４）リアセンブリが失敗した受信ＩＰデータグラムの数とする。送信待ちパケット統計は、（７）リアセンブリが成功してメモリに送信待ちで滞留しているＩＰデータグラムの数とする。
【００４４】
なお、上記の実施例では、所定のタイミングでデカプセル化装置３（ＳＮＭＰエージェント）からカプセル化装置２（ＳＮＭＰマネージャ）にＭＩＢを通知する構成としているが、これには限らない。リアセンブル処理情報に必要なＭＩＢをデカプセル装置３からカプセル化装置２に定期的に通知する構成としてもよい。
【００４５】
図５Ａ及び図５Ｂは、それぞれ従来技術に係るパケット処理方法（カプセル化を行ってからフラグメントする方法）、及びフラグメントをカプセル化より先に実施した場合のパケットの処理方法を示す図である。
【００４６】
パケットをカプセル化してからフラグメントする場合は、図５Ａに示すように、デカプセル化装置３においては、カプセル化を行う前にリアセンブル処理を実施する必要がある。大量のセッションを処理する場合には、リアセンブル処理によりデカプセル化装置３にかかる負荷が増大する。従来技術においては、リアセンブル処理の負荷が増大することにより、上記のとおり、デカプセル化装置のパフォーマンスの低下を招いていた。
【００４７】
これに対し、パケットをフラグメントしてからカプセル化する場合には、図５Ｂに示すように、デカプセル化装置３では、フラグメント処理の実施が不要となり、カプセル化のみを行って企業ＩＰ網１２に渡すことが可能となる。デカプセル化装置３には、フラグメント処理による負荷がかからなくなり、これにより、デカプセル化装置３のパフォーマンスの低下を効果的に防止することができる。
【００４８】
図６及び図７は、本実施形態に係る通信システム１（カプセル化装置２及びデカプセル化装置３）による効果を説明する図である。
カプセル化装置２においてカプセル化をフラグメントの後に行った場合には、上記のとおり、デカプセル化装置３ではリアセンブル処理を実施することが不要となる。大量のセッションを処理する場合であっても、従来はデカプセル化装置のみにおいて実施していたリアセンブル処理が分散されることで、デカプセル化装置３におけるリアセンブル処理に伴う組立メモリ不足、組立タイムアウト等の問題が起こりにくくなる。また、リアセンブル処理を不要とするセッションについては、各セッションのリアセンブル処理が一斉に完了して、デカプセル化処理部への転送待ちによるパケット廃棄が生じにくくなる。
【００４９】
一方、デカプセル化装置３におけるリアセンブル処理の負荷が比較的小さい場合には、図７に示すように、カプセル化の後に必要な場合にはフラグメントを実施する構成とする。デカプセル化装置３におけるリアセンブル処理能力に比較的余裕がある場合には、カプセル化装置２は、リアセンブル処理情報にしたがって、カプセル化処理を行ってからフラグメント処理を実施する。パケットを受信したデカプセル化装置３においては、リアセンブルしてからデカプセル化し、企業ＩＰ網１２にパケットを渡す。すなわち、デカプセル化装置３にかかる負荷が比較的小さい場合には、デカプセル化装置３においてリアセンブル処理を行うこととし、企業ＩＰ網１２にかかる負荷を抑制する。
【００５０】
以上説明したように、本実施形態によれば、デカプセル化装置３におけるリアセンブル処理の負荷の状態に応じて、カプセル化装置２においてカプセル化処理及びフラグメント処理の実行順序を変更する。デカプセル化装置３においては、カプセル化処理の先にフラグメント処理を実施したパケットを受信した場合には、自装置においてリアセンブル処理を実施することが不要となる。これにより、デカプセル化装置３のリアセンブル処理部にかかる負荷の増大によるパフォーマンスの低下を効果的に防止し、ネットワークの高速化を図ることが可能となる。
【００５１】
なお、上記の実施形態においては、トンネルカプセル化パケットを例に説明しているが、これには限らない。例えば、暗号化通信を行うためのプロトコルであるＩＰｓｅｃ（Security Architecture for Internet Protocol）を用いてパケットを送受信する場合についても適用が可能である。
【図面の簡単な説明】
【００５２】
【図１】実施形態に係る通信システムの構成図である。
【図２】実施形態に係るトンネルカプセル化処理を示すフローチャートである。
【図３】リアセンブル処理状態判定処理の詳細を示す図である。
【図４】リアセンブル処理情報の通知方法を説明する図である。
【図５Ａ】従来技術に係るパケット処理方法を示す図である。
【図５Ｂ】フラグメントをカプセル化より先に実施した場合のパケットの処理方法を示す図である。
【図６】実施形態に係るトンネルカプセル化方法による効果を説明する図（その１）である。
【図７】実施形態に係るトンネルカプセル化方法による効果を説明する図（その２）である。
【図８】企業ＩＰ網及び公衆ＩＰ網のＭＴＵの組み合わせとトンネルカプセル化パケットのフラグメントの要否との関係を示す図である。
【図９】従来におけるパケットのカプセル化処理を示したフローチャートである。
【図１０】従来技術に係るデカプセル化装置において発生する問題を説明する図（その１）である。
【図１１】従来技術に係るデカプセル化装置において発生する問題を説明する図（その２）である。
【図１２】従来技術に係るデカプセル化装置において発生する問題を説明する図（その３）である。
【符号の説明】
【００５３】
１      通信システム
２      カプセル化装置（パケット処理装置）
３      デカプセル化装置（パケット処理装置）
４      格納部
１０      公衆ＩＰ網
１１      企業ＩＰ網
１２      企業ＩＰ網
１３Ｍ、１３Ｎ      企業ＩＰ網
【図１】
2010011344.tif 000003
【図２】
2010011344.tif 000004
【図３】
2010011344.tif 000005
【図４】
2010011344.tif 000006
【図５Ａ】
2010011344.tif 000007
【図５Ｂ】
2010011344.tif 000008
【図６】
2010011344.tif 000009
【図７】
2010011344.tif 000010
【図８】
2010011344.tif 000011
【図９】
2010011344.tif 000012
【図１０】
2010011344.tif 000013
【図１１】
2010011344.tif 000014
【図１２】
2010011344.tif 000015