JP5691958B2 - ＰＰＰｏＥクライアント装置 - Google Patents

Description

本発明は、ＰＰＰｏＥ（Point-to-Point Protocol over Ethernet）プロトコルによるデータ通信を行なうＰＰＰｏＥクライアント装置に関する。

ＰＰＰｏＥサーバとの間でＰＰＰｏＥセッションを確立してデータ通信を行なうＰＰＰｏＥクライアント装置が知られている。図１は、一般的なＰＰＰｏＥセッション確立処理の流れを示すシーケンス図である。ＰＰＰｏＥセッション確立処理は、ＰＰＰｏＥクライアント装置がＰＰＰｏＥサーバを発見するためのＰＰＰｏＥディスカバリステージと、ＰＰＰｏＥサーバとの間でＰＰＰセッションを確立するＰＰＰｏＥセッションステージとからなる。ＰＰＰｏＥディスカバリステージにおいては、ＰＡＤＩ（PPPoE Active Discovery Initiation）パケット、ＰＡＤＯ（PPPoE Active Discovery Offer）パケット、ＰＡＤＲ（PPPoE Active Discovery Request）パケット、及びＰＡＤＳ（PPPoE Active Discovery Session-confirmation）パケットが順に送受信される。ＰＰＰｏＥディスカバリステージからＰＰＰｏＥセッションステージに移行する際には、ＰＰＰｏＥサーバから送信されるＰＡＤＳパケットに含まれるセッションＩＤに対応するソケットをＰＰＰｏＥクライアント装置が生成する。ＰＰＰｏＥクライアント装置は当該ソケットにより当該セッションＩＤを含むパケットを送受信してＰＰＰｏＥサーバとの間でＰＰＰｏＥセッションを確立する。例えば特許文献１には、ＰＰＰｏＥセッションを確立するまでの時間を短縮することを課題としたＰＰＰｏＥクライアント装置が記載されている。

特開２００７−１１６３４６号公報

ところで、従来、ＰＰＰｏＥディスカバリステージからＰＰＰｏＥセッションステージに移行する際には以下のような問題があった。ＰＰＰｏＥディスカバリステージにおける最後のパケットであるＰＡＤＳパケットがＰＰＰｏＥサーバから送信された後、直ぐにＰＰＰｏＥセッションステージの開始パケットであるＬＣＰＣＯＮＦＩＧ ＲＥＱパケットが送信される場合がある。ＰＡＤＳパケットの送信からＬＣＰＣＯＮＦＩＧ ＲＥＱパケットの送信までの間隔が例えば０．５ミリ秒などの非常に短い時間となることもある。この場合、ＰＡＤＳパケットに含まれるセッションＩＤに対応するソケットをＰＰＰｏＥクライアント装置が生成し終わる前にＬＣＰＣＯＮＦＩＧ ＲＥＱパケットがＰＰＰｏＥクライアント装置に到来する。そうすると、ＰＰＰｏＥクライアント装置はＬＣＰＣＯＮＦＩＧ ＲＥＱパケットを受信できなくなってしまう。ＰＰＰｏＥクライアント装置は、ＰＰＰｏＥサーバから再送されるＬＣＰＣＯＮＦＩＧ ＲＥＱパケットの到来を待つこともできるが、例えば１０秒などの再送間隔の間だけ待機しなければならず、その分だけセッション確立が遅延してしまうという問題あった。また、ＰＰＰｏＥサーバがＬＣＰＣＯＮＦＩＧ ＲＥＱパケットの再送を行なわない設定となっている場合には、ＰＰＰｏＥセッションを確立できなくなってしまうという問題あった。

本発明は上記した如き問題点に鑑みてなされたものであって、ＰＰＰｏＥセッションを早期に確立することができるＰＰＰｏＥクライアント装置を提供することを目的とする。

本発明によるＰＰＰｏＥクライアント装置は、通信網を介してＰＰＰｏＥサーバにセッションＩＤ発行要求を発してセッションＩＤを取得すると共にセッション確立指令を発するセッションＩＤ発行要求部と、前記セッション確立指令に応じて前記セッションＩＤに対応するソケットの生成を開始し、当該生成が完了してから前記ＰＰＰｏＥサーバからのセッション開始パケットに応じて前記ＰＰＰｏＥサーバとの間での前記ソケットによる通信セッションを確立するセッション確立部と、を含むＰＰＰｏＥクライアント装置であって、前記ソケットの生成完了前に前記セッション開始パケットを取得してこれを記憶パケットとして記憶するパケット取得記憶部を更に含み、前記セッション確立部は、前記記憶パケットの内容に基づいて前記ソケットによる通信セッションを確立することを特徴とする。

本発明によるＰＰＰｏＥクライアント装置によれば、ＰＰＰｏＥセッションを早期に確立することができる。

一般的なＰＰＰｏＥセッション確立処理の流れを示すシーケンス図である。 本発明の第１の実施例であるＰＰＰｏＥクライアント装置の構成をＰＰＰｏＥサーバ及び通信網と共に示すブロック図である。 データテーブルの一例を示す図である。 図２のＰＰＰｏＥクライアント装置によるセッション確立処理の動作を示すシーケンス図である。 本発明の第２の実施例であるＰＰＰｏＥクライアント装置の構成をＰＰＰｏＥサーバ、通信網、及びルータと共に示すブロック図である。 図５のＰＰＰｏＥクライアント装置によるセッション確立処理の動作を示すシーケンス図である。

以下、本発明に係る実施例について添付の図面を参照しつつ詳細に説明する。

＜第１の実施例＞
図２には、本発明の実施例であるＰＰＰｏＥクライアント装置１の構成がＰＰＰｏＥサーバ２及び通信網３と共に示されている。ＰＰＰｏＥクライアント装置１は、ＰＰＰｏＥサーバ２との間でＰＰＰｏＥセッションを確立し、通信網３を介してパケットを送受信することができる。ＰＰＰｏＥクライアント装置１は、例えばパケット中継機能を備えたルータである。

ＷＡＮポート１１は、通信網３を介してＰＰＰｏＥサーバ２との間でパケットを送受信する。

ディスカバリステージ制御部１２は、ＰＰＰｏＥセッション確立処理のうちのＰＰＰｏＥディスカバリステージ処理を行なう。詳細には、ディスカバリステージ制御部１２は、ＰＰＰｏＥサーバ２との間でＰＡＤＩパケット、ＰＡＤＯパケット、ＰＡＤＲパケット、及びＰＡＤＳパケットを順次送受信して当該処理を行なう。

また、ディスカバリステージ制御部１２は、ＰＰＰｏＥサーバ２から送信されたＰＡＤＯパケットがＷＡＮポート１１によって受信された直後に、ＰＰＰｏＥクライアント装置１を宛先とするＬＣＰＣＯＮＦＩＧ ＲＥＱパケットの取得を開始すべき旨の取得開始指令をセッション開始パケット取得部１４に対して発する。ＬＣＰＣＯＮＦＩＧ ＲＥＱパケットは、ＰＰＰｏＥセッションステージの最初のパケットである。以下、当該パケットをセッション開始パケットと称する。

また、ディスカバリステージ制御部１２は、ＰＰＰｏＥサーバ２から送信されＷＡＮポート１１によって受信されたＰＡＤＳパケットに含まれるセッションＩＤを取得する。以下、ディスカバリステージ制御部１２をセッションＩＤ発行要求部とも称する。また、ＰＡＤＳパケットをセッションＩＤ発行パケットとも称する。ディスカバリステージ制御部１２は、当該セッションＩＤを取得した直後に、セッションステージ制御部１３に対してセッション確立指令を発する。

セッションステージ制御部１３は、ＰＰＰｏＥセッション確立処理のうちのＰＰＰｏＥセッションステージ処理を行なう。セッションステージ制御部１３は、ディスカバリステージ制御部１２によって発せられたセッション確立指令に応じて、ＷＡＮポート１１によって受信されたＰＡＤＳパケットに含まれるセッションＩＤに対応するソケットの生成を開始する。セッションステージ制御部１３は、ソケットの生成が完了してから、ＰＰＰｏＥサーバ２からのセッション開始パケットに応じてＰＰＰｏＥサーバとの間での当該ソケットによる通信セッションを確立する。セッションステージ制御部１３は、ＰＰＰｏＥサーバ２との間でＬＣＰＣＯＮＦＩＧ ＲＥＱパケットすなわちセッション開始パケット、ＬＣＰ ＣＯＮＦＩＧ ＡＣＫパケット、ＬＣＰ ＣＯＮＦＩＧ ＲＥＱパケット、及びＬＣＰ ＣＯＮＦＩＧ ＡＣＫパケットを順次送受信することによって通信セッションを確立する。以下、セッションステージ制御部１３をセッション確立部とも称する。

セッションステージ制御部１３は、ソケットの生成完了後にパケットデータ記憶部１５を参照し、当該ソケットに対応するセッションＩＤが記憶されているか否かを判別する。記憶されていない場合には、セッションステージ制御部１３は、当該ソケットに対応するセッションＩＤが含まれるセッション開始パケットがＷＡＮポート１１によって受信されるのを待ってＰＰＰｏＥサーバ２との間でのセッションを確立する。

一方、当該生成したソケットに対応するセッションＩＤがパケットデータ記憶部１５に記憶されている場合には、セッションステージ制御部１３は、当該セッションＩＤに対応付けられてパケットデータ記憶部１５に記憶されているペイロードデータの内容に応じてＰＰＰｏＥサーバ２との間でのセッションを確立する。

なお、セッションステージ制御部１３は、ソケットに対応するセッションＩＤがパケットデータ記憶部１５に記憶されていると判別した後、更に次の処理を行なうこともできる。すなわち、セッションステージ制御部１３は、ＷＡＮポート１１によって受信されたＰＡＤＳパケットに含まれるＭＡＣアドレスと、当該セッションＩＤに対応付けられてパケットデータ記憶部１５に記憶されているＭＡＣアドレスとが一致するか否かを判別する。セッションステージ制御部１３は、一致すると判別した場合に、当該セッションＩＤに対応付けられてパケットデータ記憶部１５に記憶されているペイロードデータの内容に応じてＰＰＰｏＥサーバ２との間でのセッションを確立する。つまり、セッションステージ制御部１３は、セッションＩＤとＭＡＣアドレスの両方が一致したと判別した場合にセッションを確立する。

なお、セッションステージ制御部１３は、ソケットの生成が完了したときに、セッション開始パケットの取得を停止すべき旨の取得停止指令をセッション開始パケット取得部１４に対して発する。また、セッションステージ制御部１３は、ＬＣＰＣＯＮＦＩＧ ＲＥＱ及びＡＣＫパケットの送受信後に、ＰＰＰｏＥサーバ２との間でＰＡＰ／ＣＨＡＰによる認証処理、及び、ＩＰＣＰＣＯＮＦＩＧ ＲＥＱ及びＡＣＫの送受信処理も行なう。

セッション開始パケット取得部１４は、ディスカバリステージ制御部１２からの取得開始指令に応じて、ＰＰＰｏＥクライアント装置１を宛先とするＬＣＰＣＯＮＦＩＧ ＲＥＱパケットすなわちセッション開始パケットの取得を開始する。セッション開始パケット取得部１４は、ＷＡＮポート１１によって受信されたパケットのうちからセッション開始パケットのみを取得する。セッション開始パケット取得部１４は、例えばパケットヘッダに含まれる識別子に基づいて当該パケットがセッション開始パケットであることを判別する。当該識別子は、例えば、ＥＴＨＥＲ＿ＴＹＰＥ＝０ｘ８８６４、ＰＰＰＰＲＯＴＯＣＯＬ＝０ｘｃ０２１、ＰＰＰ ＬＣＰ Ｃｏｄｅ＝０ｘ０１からなる。セッション開始パケット取得部１４は、セッション開始パケットに含まれるセッションＩＤの内容にかかわらず、セッション開始パケットを取得する。セッション開始パケット取得部１４は、当該取得したセッション開始パケットに含まれるセッションＩＤとＭＡＣアドレスとペイロードデータとを対応付けてパケットデータ記憶部１５に記憶させる。また、セッション開始パケット取得部１４は、セッションステージ制御部１３からの取得停止指令に応じて、セッション開始パケットの取得を停止する。

パケットデータ記憶部１５は、セッション開始パケット取得部１４によって取得されたセッション開始パケットを記憶する（以下、当該記憶されたパケットを記憶パケットとも称する）。詳細には、パケットデータ記憶部１５は、記憶パケットに含まれるセッションＩＤとＭＡＣアドレスとペイロードデータとを対応付けて記憶する。パケットデータ記憶部１５は、取得されたセッション開始パケット毎にセッションＩＤとＭＡＣアドレスとペイロードデータの組を例えば図３に示されるようなテーブル形式により記憶する。２つ以上のセッション開始パケットが順次受信された場合には、「Ｎｏ．」の１番から順に各セッション開始パケットのセッションＩＤ等のデータが記憶される。また、セッションの終了後には、当該セッションに対応するセッションＩＤ等のデータがセッションステージ制御部１３によって削除されることができる。なお、以下、セッション開始パケット取得部１４とパケットデータ記憶部１５とをあわせてパケット取得記憶部とも称する。

ＰＰＰｏＥクライアント装置１には、例えばＣＰＵ、メモリ、ＨＤＤ、バス、ＯＳ（オペレーティングシステム）等のハードウェア及びソフトウェアが含まれている。ディスカバリステージ制御部１２、セッションステージ制御部１３、及びセッション開始パケット取得部１４（以下、これらをまとめてクライアント機能と称する）は、ハードウェアにより構成されても良いし、ソフトウェアにより構成されても良い。ソフトウェアにより構成される場合には、例えば、クライアント機能はライブラリとしてＰＰＰｏＥクライアント装置１内のメモリ（図示せず）に記憶されており、ＯＳが当該ライブラリをローディングすることにより当該クライアント機能の処理系が構成される。

例えば、ＯＳ起動時にＰＰＰｏＥセッションを確立する設定となっている場合には、ＯＳ起動時にクライアント機能がローディングされ処理系が構成される。また、ＯＳ起動後にＰＰＰｏＥセッションの確立要求が発生する場合には、ＯＳがイベントドリブン処理としてＰＰＰｏＥセッションを確立するためにクライアント機能をローディングすることにより、処理系が構成される。クライアント機能については、１つのライブラリとして構成することもできるし、複数のライブラリとして構成することもできる。複数のライブラリとして構成する場合には、ライブラリをローディングする順番がＯＳに設定されている。ＰＰＰｏＥクライアント装置１が、ディスカバリステージ制御部１２、セッションステージ制御部１３、セッション開始パケット取得部１４をそれぞれ独立したライブラリとして有している場合にはこれらを以下の順番でローディングする。例えば、ＯＳは、最初にセッション開始パケット取得部１４に対応するライブラリをローディングしてＬＣＰＣＯＮＦＩＧ ＲＥＱパケットを受信できるようにしておき、続いて、ディスカバリステージ制御部１２に対応するライブラリ、セッションステージ制御部１３に対応するライブラリの順番でローディングする。

パケットデータ記憶部１５は、例えばＲＡＭ等のメモリやＨＤＤにより構成され得る。パケットデータのインターフェースを考慮して、パケットデータ記憶部１５をＲＡＭ等のメモリによって構成する場合がある。この場合、ディスカバリステージ制御部１２及びセッションステージ制御部１３に対応するライブラリをローディングしたときにも、セッションＩＤを含むＰＡＤＳパケットを高速且つ確実に保持することができるようにするために、メモリ内のヒープエリアを確保することが望ましい。

セッション開始パケット取得部１４に対応するライブラリは、いわゆるパケットキャプチャ機能を有するライブラリである。例えばＬｉｎｕｘ等の一般的なＯＳにおいては、イーサフレームの処理をＯＳ（Ｋｅｒｎｅｌ）上で行なうことが想定される。詳細には、ＰＰＰｏＥクライアント装置１に到来するパケットを取り込むべきか否かの判断をＯＳが行い、パケットの受信及び破棄を適宜行なっている。ライブラリとしてローディングされたセッション開始パケット取得部１４は、ＯＳからパケットを受け取る設定をする。かかる設定により、セッション開始パケット取得部１４は、ＷＡＮポート１１によって受信されたパケットのうちから、セッション開始パケットであることを示す識別子を含むパケットを取得すなわちキャプチャできる。

以下、図４を参照しつつ、ＰＰＰｏＥクライアント装置１によるセッション確立処理の動作について説明する。

先ず、ディスカバリステージ制御部１２は、ＰＰＰｏＥディスカバリステージ処理の開始に当たり、ＰＰＰｏＥサーバ２に対してＰＡＤＩパケットをＷＡＮポート１１から送信する（ステップＳ１）。なお、この時点においては、図３に示されるデータテーブルには、セッションＩＤ等のデータは未だ記憶されていない。

次に、ディスカバリステージ制御部１２は、当該ＰＡＤＩパケットに対してＰＰＰｏＥサーバ２から送信されたＰＡＤＯパケットをＷＡＮポート１１を介して受信する（ステップＳ２）。

次に、ディスカバリステージ制御部１２は、ＰＰＰｏＥサーバ２に対してＰＡＤＲパケットをＷＡＮポート１１から送信すると共に、取得開始指令をセッション開始パケット取得部１４に対して発する（ステップＳ３及びＳ４）。

セッション開始パケット取得部１４は、当該取得開始指令に応じて、ＷＡＮポート１１によって受信されたパケットのうちからＬＣＰＣＯＮＦＩＧ ＲＥＱパケットすなわちセッション開始パケットのみの取得を開始する（ステップＳ５）。

次に、ディスカバリステージ制御部１２は、当該ＰＡＤＲパケットに対してＰＰＰｏＥサーバ２から送信されたＰＡＤＳパケットをＷＡＮポート１１を介して受信する（ステップＳ６）。

ディスカバリステージ制御部１２は、ＰＡＤＳパケットを受信した直後に、セッション確立指令をセッションステージ制御部１３に対して発する（ステップＳ７）。

セッションステージ制御部１３は、当該セッション確立指令に応じて、当該ＰＡＤＳパケットに含まれるセッションＩＤに対応するソケットの生成を開始する（ステップＳ８）。

セッション開始パケット取得部１４は、セッションステージ制御部１３がソケットを生成している間に、ＰＰＰｏＥサーバ２から送信されたＬＣＰＣＯＮＦＩＧ ＲＥＱパケットすなわちセッション開始パケットをＷＡＮポート１１を介して取得する（ステップＳ９）。ＰＡＤＳパケットの送信直後にＬＣＰＣＯＮＦＩＧ ＲＥＱパケットが送信された場合であっても、セッション開始パケット取得部１４はステップＳ４の時点から取得を開始しているのでＬＣＰＣＯＮＦＩＧ ＲＥＱパケットを受信できる。なお、ステップＳ９の時点においては、ディスカバリステージ制御部１２によるソケットの生成が完了していないので、ディスカバリステージ制御部１２はＬＣＰＣＯＮＦＩＧ ＲＥＱパケットを受信しない。

セッション開始パケット取得部１４は、当該取得したＬＣＰ ＣＯＮＦＩＧ ＲＥＱパケットに含まれるセッションＩＤとＭＡＣアドレスとペイロードデータとを対応付けてパケットデータ記憶部１５に記憶する（ステップＳ１０）。セッションＩＤとＭＡＣアドレスとペイロードデータとは、例えば図３に示されるデータテーブル形式により互いに対応付けられて例えば「Ｎｏ．１」の欄に記憶される。

セッションステージ制御部１３は、ソケットの生成を完了したときに、セッション開始パケット取得部１４に対して取得停止指令を発する（ステップＳ１１）。これ以降、当該セッションＩＤを含むパケットについては、セッションステージ制御部１３によって処理される。

セッション開始パケット取得部１４は、当該取得停止指令に応じてセッション開始パケットの取得を停止する（ステップＳ１２）。

セッションステージ制御部１３は、ソケットの生成完了後にパケットデータ記憶部１５を参照し、当該ソケットに対応するセッションＩＤが記憶されているか否かを判別する（ステップＳ１３）。

記憶されていない場合には、セッションステージ制御部１３は、当該ソケットに対応するセッションＩＤが含まれるセッション開始パケットがＷＡＮポート１１によって受信されるのを待って、ＰＰＰｏＥサーバ２に対してＬＣＰＣＯＮＦＩＧ ＡＣＫパケットを送信する（ステップＳ１４）。

一方、当該生成したソケットに対応するセッションＩＤがパケットデータ記憶部１５に記憶されている場合には、セッションステージ制御部１３は、当該セッションＩＤに対応付けられてパケットデータ記憶部１５に記憶されているペイロードデータの内容に応じてＰＰＰｏＥサーバ２との間でセッションの確立を開始する。なお、セッションステージ制御部１３は、ＷＡＮポート１１によって受信されたＰＡＤＳパケットに含まれるＭＡＣアドレスと、当該セッションＩＤに対応付けられてパケットデータ記憶部１５に記憶されているＭＡＣアドレスとが一致すると判別した場合に、ＰＰＰｏＥサーバ２との間でのセッションの確立を開始することもできる。

先ず、ＰＰＰｏＥサーバ２に対してＬＣＰ ＣＯＮＦＩＧ ＡＣＫパケットを送信する（ステップＳ１４）。

次に、セッションステージ制御部１３は、ＰＰＰｏＥサーバ２に対してＬＣＰ ＣＯＮＦＩＧ ＲＥＱパケットを送信する（ステップＳ１５）。

次に、セッションステージ制御部１３は、当該ＬＣＰ ＣＯＮＦＩＧ ＲＥＱパケットに対してＰＰＰｏＥサーバ２から送信されたＬＣＰ ＣＯＮＦＩＧ ＡＣＫパケットをＷＡＮポート１１を介して受信する（ステップＳ１６）。

次に、セッションステージ制御部１３は、ＰＰＰｏＥサーバ２との間でＰＡＰ／ＣＨＡＰによる認証を行なう（ステップＳ１７）。

その後、セッションステージ制御部１３は、ＰＰＰｏＥサーバ２との間でＩＰＣＰ ＣＯＮＦＩＧ ＲＥＱパケット及びＩＰＣＰ ＣＯＮＦＩＧ ＡＣＫパケットを送受信するなどしてＰＰＰｏＥセッションステージ処理を継続する（これらのパケットについては図示せず）。

上記したように、本実施例によるＰＰＰｏＥクライアント装置１においては、セッションＩＤを含むＰＡＤＳパケットを受信してから当該セッションＩＤに対応するソケットの生成を開始する。ＰＡＤＳの送信直後にＰＰＰｏＥサーバ２からＬＣＰＣＯＮＦＩＧ ＲＥＱパケットが送信された場合には、セッションステージ制御部１３による当該セッションＩＤに対応するソケットの生成が完了していない場合も考えられる。このような場合であっても、セッション開始パケット取得部１４が、ＰＰＰｏＥサーバ２よるＰＡＤＳパケットの送信前からＬＣＰＣＯＮＦＩＧ ＲＥＱパケットの到来を待ち受けており、ソケットの生成完了前であってもＰＰＰｏＥクライアント装置１に到来したＬＣＰＣＯＮＦＩＧ ＲＥＱパケットを取得することができる。当該パケットに含まれるセッションＩＤとＭＡＣアドレスとペイロードデータとは互いに対応付けられてパケットデータ記憶部１５に記憶される。セッションステージ制御部１３は、ソケットの生成完了後にパケットデータ記憶部１５を参照する。当該ソケットに対応するセッションＩＤが記憶されている場合には、セッションステージ制御部１３は、当該セッションＩＤに対応付けられているペイロードデータの内容に応じてＬＣＰＣＯＮＦＩＧ ＡＣＫ等のパケットを送信してＰＰＰｏＥセッションステージ処理を行なうことができる。

かかる動作により、ＰＡＤＳの送信直後にＰＰＰｏＥサーバ２からＬＣＰ ＣＯＮＦＩＧ ＲＥＱパケットが送信されて当該ＰＡＤＳに含まれるセッションＩＤに対応するソケットの生成が完了する前に当該ＬＣＰＣＯＮＦＩＧ ＲＥＱパケットがＰＰＰｏＥクライアント装置１に到来した場合であっても、ＰＰＰｏＥセッションステージ処理を継続することができる。すなわち、ＰＰＰｏＥディスカバリステージ処理からＰＰＰｏＥセッションステージ処理へ移行する際にＰＰＰｏＥクライアント装置１が取り込むべきＬＣＰＣＯＮＦＩＧ ＲＥＱパケットの取りこぼしを防止することができる。それ故、ＬＣＰ ＣＯＮＦＩＧ ＲＥＱパケットを受信できずにＰＰＰｏＥサーバ２による当該パケットの再送を待つということがないので、早期にセッションを確立できる。また、ソケット生成完了前からＬＣＰＣＯＮＦＩＧ ＲＥＱパケットを受信できるので、ＰＰＰｏＥサーバ２が当該パケットを再送しない場合であっても、セッションを確実に確立できるという効果も奏する。

＜第２の実施例＞
図５には、本実施例であるＰＰＰｏＥクライアント装置１の構成がＰＰＰｏＥサーバ２、通信網３、及びルータ４と共に示されている。本実施例のＰＰＰｏＥクライアント装置１は、例えば通信機能を備えたパーソナルコンピュータであり、ブリッジ機能を備えたルータ４に収容されている。本実施例のＰＰＰｏＥクライアント装置１の構成は第１の実施例と同様に図２に示されている。ＷＡＮポート１１、ディスカバリステージ制御部１２、セッションステージ制御部１３、セッション開始パケット取得部１４、及びパケットデータ記憶部１５の構成及び動作は第１の実施例と同様である。

図６には、ＰＰＰｏＥクライアント装置１によるセッション確立処理の動作を示すシーケンスが示されている。ＰＰＰｏＥクライアント装置１とＰＰＰｏＥサーバ２との間では、第１の実施例と同様のＰＰＰｏＥディスカバリステージ処理及びＰＰＰｏＥセッションステージ処理が実行される（ステップＳ１〜Ｓ１７）。ＰＰＰｏＥクライアント装置１とＰＰＰｏＥサーバ２との間で送受信される全てのＰＰＰｏＥディスカバリパケット及びＰＰＰセッションパケットをルータ４がＰＰＰｏＥクライアント装置１とＰＰＰｏＥサーバ２との間でブリッジする点が第１の実施例と異なる。

かかる構成によれば、ＰＰＰｏＥクライアント装置１がパケット中継等のルータ機能を有しない情報通信端末である場合にも、ＰＰＰｏＥサーバ２との間でセッションを確立することができる。

なお、上記実施例は、ＰＡＤＲパケットの送信時にディスカバリステージ制御部１２がセッション開始パケット取得部１４に対して取得開始指令を発する例であるが、これに限られない。ディスカバリステージ制御部１２は、例えばＰＡＤＩパケットの送信時やＰＡＤＯパケットの受信時等、セッションＩＤを含むＰＡＤＳの受信前の任意の時点において取得開始指令を発することができる。

１ ＰＰＰｏＥクライアント装置
２ ＰＰＰｏＥサーバ
３ 通信網
１１ ＷＡＮポート
１２ ディスカバリステージ制御部（セッションＩＤ発行要求部）
１３ セッションステージ制御部（セッション確立部）
１４ セッション開始パケット取得部（パケット取得記憶部）
１５ パケットデータ記憶部（パケット取得記憶部）

Claims (7)

1. 通信網を介してＰＰＰｏＥサーバにセッションＩＤ発行要求を発してセッションＩＤを取得すると共にセッション確立指令を発するセッションＩＤ発行要求部と、
   前記セッション確立指令に応じて前記セッションＩＤに対応するソケットの生成を開始し、当該生成が完了してから前記ＰＰＰｏＥサーバからのセッション開始パケットに応じて前記ＰＰＰｏＥサーバとの間での前記ソケットによる通信セッションを確立するセッション確立部と、を含むＰＰＰｏＥクライアント装置であって、
   前記ソケットの生成完了前に前記セッション開始パケットを取得してこれを記憶パケットとして記憶するパケット取得記憶部を更に含み、
   前記セッション確立部は、前記記憶パケットの内容に基づいて前記ソケットによる通信セッションを確立することを特徴とするＰＰＰｏＥクライアント装置。
2. 前記セッション確立部は、前記ソケットに対応するセッションＩＤと前記記憶パケットに含まれるセッションＩＤとが一致すると判別した場合に前記ソケットによる通信セッションを確立することを特徴とする請求項１に記載のＰＰＰｏＥクライアント装置。
3. 前記セッション確立部は、前記ＰＰＰｏＥサーバから前記セッションＩＤと共に送信されたＭＡＣアドレスと、前記記憶パケットに含まれるＭＡＣアドレスとが一致すると判別した場合に前記ソケットによる通信セッションを確立することを特徴とする請求項２に記載のＰＰＰｏＥクライアント装置。
4. 前記セッションＩＤ発行要求部は、前記セッションＩＤの取得に先立って前記セッション開始パケットの取得を開始すべき旨の取得開始指令を前記パケット取得記憶部に発し、
   前記パケット取得記憶部は、前記取得開始指令に応じて前記セッション開始パケットの到来を待ってこれを取得することを特徴とする請求項３に記載のＰＰＰｏＥクライアント装置。
5. 前記セッション確立部は、前記ソケットの生成を完了したときに前記セッション開始パケットの取得を停止すべき旨の取得停止指令を前記パケット取得記憶部に発し、
   前記パケット取得記憶部は、前記取得停止指令に応じて前記セッション開始パケットの取得を停止することを特徴とする請求項４に記載のＰＰＰｏＥクライアント装置。
6. 前記セッションＩＤ発行要求部は、前記ＰＰＰｏＥサーバからＰＡＤＯパケットを受信したときに前記取得開始指令を発することを特徴とする請求項４又は５に記載のＰＰＰｏＥクライアント装置。
7. 前記通信セッションの確立後に前記ＰＰＰｏＥサーバからのパケットを中継する中継部を更に含むことを特徴とする請求項６に記載のＰＰＰｏＥクライアント装置。

Images