(57)【特許請求の範囲】
【請求項１】
ユーザプレーンのネットワーク要素に使用するための方法において、
ユーザプレーンのメッセージが事前構成ルールに合致するかどうかチェックし、ユーザプレーンのメッセージは、そのメッセージがダイナミックホスト構成プロトコルＤＨＣＰ、リモート認証ダイヤルインユーザサービスＲＡＤＩＵＳ、レイヤ２トンネルプロトコルＬ２ＴＰ、及びポイント対ポイントプロトコルＰＰＰの１つに合致するときに事前構成ルールに合致するものであり、及び
前記メッセージが事前構成ルールに合致すると決定された場合には、
前記ＤＨＣＰ、ＲＡＤＩＵＳ、Ｌ２ＴＰ及びＰＰＰの１つによる、コントローラに送られた、アドレス割り当てに関連した特定シグナリングメッセージの数が所定のスレッシュホールドに達したかどうかチェックし、
前記所定のスレッシュホールドに達した場合には、前記コントローラへの特定シグナリングメッセージの送信を減少させ、
前記所定のスレッシュホールドに達しない場合には、前記特定シグナリングメッセージを前記コントローラへ送信し、
前記特定スレッシュホールドに達し且つ送信が絞られた場合には、前記コントローラから要求があったときに前記特定シグナリングメッセージの送信を再開し、
特定情報を搬送する特定シグナリングメッセージをサーチし、
前記特定シグナリングメッセージからその特定情報を抽出し、及び
その抽出された特定情報を前記コントローラへ送信する、
ことを含む、方法。
【請求項２】
ＤＨＣＰリレー又はＬＣＰ／認証／ＩＰＣＰネゴシエーションを経てＲＡＤＩＵＳ／ＤＨＣＰ／Ｌ２ＴＰマッピング機能へ前記特定情報を送信することを更に含み、前記特定情報は、インターネットプロトコルアドレス、又はインターネットプロトコルアドレスのリース時間である、請求項１に記載の方法。
【請求項３】
前記コントローラは、ＯｐｅｎＦｌｏｗプロトコル、又は転送及び制御エレメント分離プロトコルの一方に適合する、請求項１から２のいずれか１項に記載の方法。
【請求項４】
ネットワーク要素に使用するための方法において、
アドレス割り当ての要求が所定の条件を満足するかどうか評価することを含み、前記所定の条件は、ダイナミックホスト構成プロトコルＤＨＣＰ、リモート認証ダイヤルインユーザサービスＲＡＤＩＵＳ、レイヤ２トンネルプロトコルＬ２ＴＰ、又はポイント対ポイントプロトコルＰＰＰの１つを経てアドレス割り当てが要求されたことを含み、
前記要求が所定の条件を満足すると決定された場合には、
ユーザプレーンの別のネットワーク要素が、ユーザプレーンのメッセージが事前構成ルールに合致するかどうかチェックするようにさせ、その事前構成ルールは、ユーザプレーンのメッセージが、ＤＨＣＰ、ＲＡＤＩＵＳ、Ｌ２ＴＰ又はＰＰＰの１つに適合するメッセージであることを含み、及び
ユーザプレーンのメッセージが事前構成ルールに適合する場合には、ユーザプレーンの別のネットワーク要素が、ＤＨＣＰ、ＲＡＤＩＵＳ、Ｌ２ＴＰ及びＰＰＰの１つによる、コントローラへのアドレス割り当てに関連した特定のシグナリングメッセージを減少するようにさせる、
ことを含む方法。
【請求項５】
前記アドレス割り当ては、セッション生成要求メッセージにおいて汎用パケット無線サービストンネルプロトコルコントロールプレーンＧＴＰ−Ｃを経て要求され、又は
前記アドレス割り当ては、パケットデータプロトコルＰＤＰコンテキスト生成要求メッセージにおいてゲートウェイ汎用パケット無線サービスサポートノードＧＧＳＮを経て要求され、及び／又は
前記方法は、更に、プロトコル構成オプションＰＣＯにおいて、ＤＨＣＰ、リンクコントロールプロトコルＬＣＰ、パスワード認証プロトコルＰＡＰ、チャレンジハンドシェーク認証プロトコルＣＨＡＰ、及びインターネットプロトコルコントロールプロトコルＩＰＣＰの１つを経てアドレス割り当てが要求されるかどうか評価することを含む、請求項４に記載の方法。
【請求項６】
ユーザプレーンのネットワーク要素に使用するための装置において、
少なくとも１つのプロセッサ、及び
プロセッサにより実行されるべきインストラクションを記憶するための少なくとも１つのメモリ、
を備え、前記少なくとも１つのメモリ及びインストラクションは、少なくとも１つのプロセッサとで、装置が、少なくとも、
ユーザプレーンのメッセージが事前構成ルールに合致するかどうかチェックし、ユーザプレーンのメッセージは、そのメッセージがダイナミックホスト構成プロトコルＤＨＣＰ、リモート認証ダイヤルインユーザサービスＲＡＤＩＵＳ、レイヤ２トンネルプロトコルＬ２ＴＰ、及びポイント対ポイントプロトコルＰＰＰの１つに合致するときに事前構成ルールに合致するものであり、及び
前記メッセージが事前構成ルールに合致すると決定された場合には、
前記ＤＨＣＰ、ＲＡＤＩＵＳ、Ｌ２ＴＰ及びＰＰＰの１つによる、コントローラに送られた、アドレス割り当てに関連した特定シグナリングメッセージの数が所定のスレッシュホールドに達したかどうかチェックし、
前記所定のスレッシュホールドに達した場合には、前記コントローラへの特定シグナリングメッセージの送信を減少させ、
前記所定のスレッシュホールドに達しない場合には、前記特定シグナリングメッセージを前記コントローラへ送信し、
前記特定スレッシュホールドに達し且つ送信が絞られた場合には、前記コントローラから要求があったときに前記特定シグナリングメッセージの送信を再開し、
特定情報を搬送する特定シグナリングメッセージをサーチし、
前記特定シグナリングメッセージからその特定情報を抽出し、及び
その抽出された特定情報を前記コントローラへ送信する、
ことを遂行させるよう構成された装置。
【請求項７】
前記少なくとも１つのメモリ及びインストラクションは、少なくとも１つのプロセッサとで、装置が、少なくとも、
ＤＨＣＰリレー又はＬＣＰ／認証／ＩＰＣＰネゴシエーションを経てＲＡＤＩＵＳ／ＤＨＣＰ／Ｌ２ＴＰマッピング機能へ前記特定情報を送信する、
ことを遂行させるように更に構成され、前記特定情報は、インターネットプロトコルアドレス、又はインターネットプロトコルアドレスのリース時間である、請求項６に記載の装置。
【請求項８】
前記コントローラは、ＯｐｅｎＦｌｏｗプロトコル、又は転送及び制御エレメント分離プロトコルの一方に適合する、請求項６から７のいずれか１項に記載の装置。
【請求項９】
ネットワーク要素に使用するための装置において、
少なくとも１つのプロセッサ、及び
プロセッサにより実行されるべきインストラクションを記憶するための少なくとも１つのメモリ、
を備え、前記少なくとも１つのメモリ及びインストラクションは、少なくとも１つのプロセッサとで、装置が、少なくとも、
アドレス割り当ての要求が所定の条件を満足するかどうか評価し、前記所定の条件は、ダイナミックホスト構成プロトコルＤＨＣＰ、リモート認証ダイヤルインユーザサービスＲＡＤＩＵＳ、レイヤ２トンネルプロトコルＬ２ＴＰ、又はポイント対ポイントプロトコルＰＰＰの１つを経てアドレス割り当てが要求されたことを含み、
前記要求が所定の条件を満足すると決定された場合には、
ユーザプレーンの別のネットワーク要素が、ユーザプレーンのメッセージが事前構成ルールに合致するかどうかチェックするようにさせ、その事前構成ルールは、ユーザプレーンのメッセージが、ＤＨＣＰ、ＲＡＤＩＵＳ、Ｌ２ＴＰ又はＰＰＰの１つに適合するメッセージであることを含み、及び
ユーザプレーンのメッセージが事前構成ルールに適合する場合には、ＤＨＣＰ、ＲＡＤＩＵＳ、Ｌ２ＴＰ及びＰＰＰの１つによる、コントローラへのアドレス割り当てに関連した特定のシグナリングメッセージを減少する指示をユーザプレーンの別のネットワーク要素に与える、
ことを遂行させるよう構成された装置。
【請求項１０】
前記アドレス割り当ては、セッション生成要求メッセージにおいて汎用パケット無線サービストンネルプロトコルコントロールプレーンＧＴＰ−Ｃを経て要求され、又は
前記アドレス割り当ては、パケットデータプロトコルＰＤＰコンテキスト生成要求メッセージにおいてゲートウェイ汎用パケット無線サービスサポートノードＧＧＳＮを経て要求され、及び／又は
前記少なくとも１つのメモリ及びインストラクションは、少なくとも１つのプロセッサとで、装置が、少なくとも、
プロトコル構成オプションＰＣＯにおいて、ＤＨＣＰ、リンクコントロールプロトコルＬＣＰ、パスワード認証プロトコルＰＡＰ、チャレンジハンドシェーク認証プロトコルＣＨＡＰ、及びインターネットプロトコルコントロールプロトコルＩＰＣＰの１つを経てアドレス割り当てが要求されるかどうか評価する、
ことを遂行するようにさせるよう更に構成された、請求項９に記載の装置。
【請求項１１】
処理装置において実行されるときに請求項１から５のいずれか１項に記載の方法を遂行するためのソフトウェアコード部分を備えたコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＳＤＮ（ソフトウェア定義ネットワーキング, Software Defined Networking）セキュリティに関する装置、方法、システム、コンピュータプログラム、コンピュータプログラム製品、及びコンピュータ読み取り可能な媒体に関する。
【０００２】
本発明は、例えば、ＤＨＣＰ（ダイナミックホスト構成プロトコル）、ＲＡＤＩＵＳ（リモート認証ダイヤルインユーザサービス）、Ｌ２ＴＰ（レイヤ２トンネルプロトコル）及びＰＰＰ（ポイント対ポイントプロトコル）、等の種々のプロトコルに適用することができる。
【背景技術】
【０００３】
ダイナミックホスト構成プロトコル（ＤＨＣＰ）は、ＩＰ（インターネットプロトコル）アドレスを管理し、そしてそれをＴＣＰ／ＩＰ（送信コントロールプロトコル／インターネットプロトコル）ネットワークのステーションへ動的に指定するためのプロトコルである。ＤＨＣＰは、クライアント・サーバーアーキテクチャーであり、そして図１に示すプロセスは、（ＧＴＰ（ＧＰＲＳ(汎用パケット無線サービス)トンネルプロトコル）を考慮せずに）ＩＰアドレスを指定するためにクライアントとサーバーとの間で遂行される。
【０００４】
図１に示すように、クライアントは、ステップＳ１１において、ブロードキャストメッセージ“ＤＨＣＰ−Ｄｉｓｃｏｖｅｒｙ”をサーバーへ送信し、次いで、サーバーは、ステップＳ１２において、ＩＰアドレス及び他の当該パラメータについての提案を含む“ＤＨＣＰ−Ｏｆｆｅｒ”でそれに応答する。次いで、クライアントは、ステップＳ１３において、“ＤＨＣＰ−Ｏｆｆｅｒ”でオファーされたＩＰアドレスを確認／要求するために“ＤＨＣＰ−Ｒｅｑｕｅｓｔ”メッセージをブロードキャストし、そしてサーバーは、ステップＳ１４において、要求側クライアントのための構成パラメータを含む“ＤＨＣＰ−ＡＣＫ”メッセージでそれに応答する。この点に関する詳細は、ドキュメントＲＦＣ（リクエスト・フォー・コメント）２１３１に記述されている。
【０００５】
図２は、ＤＨＣＰクライアントとして働くターミナル装置（ＴＥ）と、ＤＨＣＰサーバーとして働くイントラネット又はＩＳＰ（インターネットサービスプロバイダー）との間にＤＨＣＰｖ４を使用するアドレス割り当ての別の例を示すシグナリング図（３ＧＰＰ  ＴＳ（技術的仕様書）２９．０６１を参照）である。更に、図２は、移動ターミナル（ＭＴ）、ＳＧＳＮ（サービングＧＰＲＳサポートノード）、及びＤＨＣＰリレーエージェントとして働くＧＧＳＮ（ゲートウェイＧＰＲＳ(汎用パケット無線サービス)サポートノード）も示している。図２のステップ１）から１２）の以下の説明は、ＴＳ２９．０６１から取り出されたものである。この点に関する詳細については、そのドキュメントを参照されたい。
【０００６】
ステップＳ２１において、ＴＥ（ターミナル装置）及びＭＴ（移動ターミナル）は、多数のＡＴ（例えば、３ＧＰＰ  ＴＳ２７．００７に述べられたＡｔｔｅｎｔｉｏｎ）コマンドを交換し、これらコマンドは、ＱｏＳ（サービスクオリティ）を搬送すると共に、ＴＥにより要求される他のパラメータであって、ＰＤＰ（パケットデータプロトコル）タイプＩＰのＰＤＰコンテキストのアクチベーションを要求する他のパラメータを搬送する。ＴＥは、ＤＨＣＰサービスを提供する構成されたイントラネット／ＩＳＰのＡＰＮ（アクセスポイント名）、及びユーザが加入したＤＨＣＰの予約サービスラベルより成るＡＰＮを選択する。後者のケースでは、ＴＥは、（ＡＰＮ選択ルールに基づいて）ＤＨＣＰサービスを提供するＰＬＭＮ（公衆地上移動ネットワーク）運営者構成サービスプロバイダーに接続される。
【０００７】
ステップＳ２２において、ＭＴは、空のＰＤＰアドレスフィールドと共にＰＤＰコンテキストアクチベート要求メッセージをＳＧＳＮへ送信する。
【０００８】
ステップＳ２３において、ＳＧＳＮは、ＭＳ（移動ステーション）により要求されるＡＰＮに基づき、ＴＥ及びＭＴにより構成されたＧＧＳＮを選択し、そしてＰＤＰ（パケットデータプロトコル）コンテキスト生成要求メッセージをそのＧＧＳＮへ送信する。ＧＧＳＮは、ＰＤＰコンテキスト生成応答メッセージで応答する。ＧＧＳＮが、要求されたＡＰＮに対しＤＨＣＰとの外部ＰＤＮ（パケットデータネットワーク）アドレス割り当てを使用するように運営者により構成されていない場合には、原因が「サービス非サポート」にセットされねばならない。この点においてＩＰアドレスが指定されない場合には、ＧＧＳＮにより返送されるＰＤＰアドレスが０．０．０．０．にセットされ、これは、ＩＰアドレスがまだ指定されておらず、ＰＤＰコンテキストアクチベーション手順の後にＴＥによりイントラネット／ＩＳＰとネゴシエーションされねばならないことを示す。
【０００９】
ステップＳ２４において、ＰＤＰコンテキスト生成応答で受け取られた原因値に基づいて、ＳＧＳＮは、ＰＤＰコンテキストアクチベート受け容れ又はＰＤＰコンテキストアクチベート拒絶のいずれかをＭＴへ返送する。首尾良いアクチベーションの場合には、ＰＤＰアドレスが０．０．０．０．にセットされた状態でＰＤＰコンテキストが確立される。
【００１０】
ステップＳ２５において、ＰＤＰコンテキストアクチベート受け容れを受け取ると、ＭＴは、ＰＤＰコンテキストアクチベーション手順の完了を確認するＡＴ応答をＴＥへ送信する。
【００１１】
ステップＳ２６において、ＴＥは、ＩＰ行先アドレスを限定ブロードキャストアドレス（全て１）にセットしてＤＨＣＰＤＩＳＣＯＶＥＲメッセージを送信する。ＧＧＳＮは、ＤＨＣＰＤＩＳＣＯＶＥＲをＤＨＣＰリレーエージェントへ通過させ、これは、ＰＤＰコンテキストのＡＰＮに対して構成されたＤＨＣＰサーバーへその要求を中継する。所与のＡＰＮに対して２つ以上のＤＨＣＰサーバーが構成される場合には、要求がそれらの全部に送られる。ＤＨＣＰリレーエージェントは、応答をＭＳへリレー返送できるようにするに充分な情報をＤＨＣＰＤＩＳＣＯＶＥＲメッセージに追加する。
【００１２】
ステップＳ２７において、ＤＨＣＰＤＩＳＣＯＶＥＲ要求を受け取るＤＨＣＰサーバーは、オファーされるＩＰアドレスを含むＤＨＣＰＯＦＦＥＲメッセージを送信することにより応答する。ＤＨＣＰリレーエージェントは、その応答を適切なＭＳへ転送する。
【００１３】
ステップＳ２８において、ＴＥは、おそらく多数のＤＨＣＰＯＦＦＥＲの１つを選択し、そしてその選択を確認すると共に付加的な構成情報を要求するＤＨＣＰＲＥＱＵＥＳＴを送信する。リレーエージェントは、ステップＳ２６で述べたようにＤＨＣＰＯＦＦＥＲを中継する。
【００１４】
ステップＳ２９において、選択されたＤＨＣＰサーバーは、ＤＨＣＰＲＥＱＵＥＳＴを受け取り、そしてＴＥにより要求される構成情報を含むＤＨＣＰＡＣＫで応答する。ＤＨＣＰリレーエージェントは、ＤＨＣＰＡＣＫをＴＥへ中継する。
【００１５】
ステップＳ２１０において、ＤＨＣＰリレーエージェントは、割り当てられたＩＰアドレスをＧＧＳＮへ通過し、ＧＧＳＮは、それを、対応するＰＤＰコンテキストに記憶する。次いで、ＧＧＳＮは、割り当てられたＩＰアドレスにセットされたエンドユーザアドレス情報エレメントと共にＰＤＰコンテキスト更新要求を適当なＳＧＳＮへ送ることによりＰＤＰコンテキスト変更手順を開始する。
【００１６】
ステップＳ２１１において、ＳＧＳＮは、ＰＤＰアドレス情報エレメントにおける割り当てられたＩＰアドレスと共にＰＤＰコンテキスト変更要求をＭＴに送る。ＭＴは、ＰＤＰコンテキスト変更受け容れをＳＧＳＮに送ることにより確認を行う。
【００１７】
ステップＳ２１２において、ＳＧＳＮは、ＰＤＰコンテキスト更新応答をＧＧＳＮに送る。ＰＤＰコンテキストは、割り当てられたＩＰアドレスで首尾良く更新されている。
【００１８】
３ＧＰＰに関しては、ＵＥがＤＨＣＰを経てＩＰアドレス割り当てを要求した場合に、ＧＴＰ−Ｕ（ＧＰＲＳトンネルプロトコルユーザプレーン）は、ＤＨＣＰシグナリングトラフィックと、ＵＥにより発生されるトラフィックのペイロードと、の両方を搬送する。
【００１９】
更に、今日のＯｐｅｎＦｌｏｗ仕様によれば、一般的に、ＥＰＣ  ＧＷ（進化型パケットコアゲートウェイ）のＧＴＰ−Ｕで受け取られる全ＤＨＣＰメッセージをＳＤＮ（ソフトウェア定義ネットワーキング）環境においてコントローラまで送信することができる。
【００２０】
従って、ＳＤＮでは、ユーザプレーンで受け取られる全ＤＨＣＰメッセージがＳＤＮコントローラへ送られる。しかしながら、これは、ＤｏＳ（サービス妨害）攻撃によりＳＤＮコントローラを氾濫させることができるので、セキュリティの問題を生じさせる。
【００２１】
従って、顧客のネットワーク及びもちろんネットワークそれ自体の他のユーザ／加入者がそれに対応する攻撃により影響を受けないようにネットワークのキャリアグレード振舞いを保証するようコントローラをセキュア化する解決策が要求される。
【００２２】
ＤＨＣＰプロトコルはＵＥ起源であるから、ＵＥがＰＣＯ（プロトコル構成オプション；３ＧＰＰ  ＴＳ２４．００８を参照）を経て（Ｓ５／Ｓ８インターフェイスＴＳ２９．２７４ＧＴＰｖ２コントロールプレーン（４Ｇ）を経て又はＧｎインターフェイスＴＳ２９．０６０ＧＴＰｖ１コントロールプレーン（３Ｇ）を経て）ＤＨＣＰを要求する場合には、ＵＥがネットワークＳＤＮコントローラに影響を及ぼす。
【００２３】
従って、以前は、ＳＤＮコントローラが存在しなかった。それ故、（特に、ＳＤＮコントローラがネットワーク内の指定のスイッチにおける流れを適切に制御できないために）運営者のネットワークが潜在的に攻撃及びダメージを受ける脅威がＳＤＮ解決策によって新たに生じる。現在まで、ＳＤＮが導入される以前は、脅威がないので心配する必要がなかった。
【００２４】
現在、全てのＤＨＣＰメッセージがコントローラへ送られるか否かであるが、ＰＧＷ−Ｃ（パケットデータネットワークゲートウェイコントロールプレーン）は、ＵＥに割り当てられ／指定されるＩＰアドレスを持つ必要がある。従って、ＳＤＮ環境では、現在解決されない対立する要求がある。
【００２５】
しかしながら、ＤＨＣＰは、単なる一例に過ぎないことに注意されたい。上述した問題及び本発明は、例えば、ＲＡＤＩＵＳ（リモート認証ダイヤルインユーザサービス）、Ｌ２ＴＰ（レイヤ２トンネルプロトコル）、及びＰＰＰ（ポイント対ポイント）、等の他のプロトコルにも適用できる。
【００２６】
図９は、３ＧＰＰ  ＴＳ２９．０６１に定義された首尾良いＰＤＰコンテキストアクチベーションの一例を示すシグナリングである。
【００２７】
図９に示す例では、ＭＳ（移動ステーション）に、イントラネット／ＩＳＰアドレススペースに属するアドレスが与えられる。このアドレスは、加入時に与えられる（この場合は、スタティックアドレスである）か、又はＰＤＰコンテキストアクチベーション時に与えられる（この場合は、ダイナミックアドレスである）。このアドレスは、ＧＧＳＮ内でのパケット転送、及びイントラネット／ＩＳＰにおけるパケット転送に使用される。これは、ＧＧＳＮとアドレス割り当てサーバーとの間に、イントラネット／ＩＳＰに属するＡＡＡ（認証、許可及びアカウンティング）又はＤＨＣＰのようなリンクを要求する。
【００２８】
パケットドメインとイントラネット／ＩＳＰとの間の通信は、非セキュアなネットワーク、例えば、インターネットを経て遂行される。ＧＧＳＮとイントラネット／ＩＳＰとの間の非セキュアな接続の場合には、それらの間に特定のセキュリティプロトコルがある。このセキュリティプロトコルは、ＰＬＭＮ（公衆地上移動ネットワーク）運営者とイントラネット／ＩＳＰ管理者との間の相互合意により定義される。
【００２９】
ステップＳ９１において、ＴＥは、ＡＴコマンドをＭＴに送信してパラメータを設定する。ステップＳ９２において、ＭＴは、ＰＤＰコンテキストアクチベート要求メッセージをＳＧＳＮへ送り、ＳＧＳＮは、ステップＳ９３において、ＰＤＰコンテキスト生成要求メッセージを選択されたＧＧＳＮへ送る。
【００３０】
ＧＧＳＮは、ＡＰＮから次のものを推論する。
−アドレス割り当て及び認証に使用されるサーバー（１つ又は複数）；
−この／それらのサーバーと共に使用されるべきＲＡＤＩＵＳ、ＤＨＣＰ又はＬ２ＴＰのようなプロトコル；
−この／それらのサーバーと対話する必要のある通信及びセキュリティ特徴、例えば、トンネル、ＩＰＳｅｃセキュリティ関連性、ダイヤルアップ接続（考えられるＰＰＰを使用する）。
【００３１】
一例として、ＧＧＳＮは、次の選択肢の１つを使用する。
−認証及びＩＰアドレス割り当てのためのＲＡＤＩＵＳ。ＡＡＡサーバーは、ＧＧＳＮにおけるＲＡＤＩＵＳクライアントに対するアクセス受け容れ又はアクセス拒絶のいずれかで応答する；
−認証のためのＲＡＤＩＵＳ及びホスト構成及びアドレス割り当てのためのＤＨＣＰ。ＡＡＡサーバーは、ＧＧＳＮにおけるＲＡＤＩＵＳクライアントに対するアクセス受け容れ又はアクセス拒絶のいずれかで応答する。認証成功の後に、ＤＨＣＰクライアントは、ＩＳＰ／イントラネットにおけるＤＨＣＰサーバーを発見し、そしてホスト構成データを受け取る；
−ＰＰＰフレームをＬ２ＴＰネットワークサーバーへ転送するためのＬ２ＴＰ。
【００３２】
ステップＳ９４において、ＧＧＳＮは、ＰＤＰコンテキスト生成応答メッセージをＳＧＳＮへ返送する。ＰＤＰコンテキスト生成応答で受け取られる原因値に基づき、ＳＧＳＮは、ステップＳ９５において、ＰＤＰコンテキストアクチベート受け容れメッセージ又はＰＤＰコンテキストアクチベート拒絶メッセージをＭＳに送る。
【００３３】
ステップＳ９６において、ＭＴは、コンテキストアクチベーションが成功であったか否かを示すＡＴ応答で応答する。コンテキストアクチベーションが成功でない場合には、その応答が原因も示す。
【００３４】
コンテキストアクチベーションが成功の場合には、ＴＥは、ＬＬＣ（論理的リンクコントロール）リンクが確立された後にそのＰＰＰプロトコルをスタートする。次いで、ＬＣＰ（リンクコントロールプロトコル）、認証及びＮＣＰ（ネットワークコントロールプロトコル）ネゴシエーションがステップＳ９７において実行され、そしてＲＡＤＩＵＳ／ＤＨＣＰ又はＬ２ＴＰネゴシエーションがステップＳ９８において実行される。
【００３５】
図１０は、３ＧＰＰ  ＴＳ２９．０６１に述べられたように、ＰＰＰがＧＧＳＮにおいて終了する場合に、ＧＧＳＮと、認証、許可及びアカウンティング（ＡＡＡ）サーバーとの間にＲＡＤＩＵＳメッセージが流れる一例を示す。その詳細な説明は、ここでは、省略し、これについてはＴＳ２９．０６１を参照されたい。
【００３６】
Seungwon氏等の“AVANT-GUARD: Scalable and Vigilant Switch Flow Management in Dofitware-Defined Networks”という論文は、ソフトウェア定義ネットワークにおけるスイッチフロー管理について開示すると共に、ある起点及び／又は行先からの及び／又はそれに向かうあるトラフィックを一般的にブロックするメカニズム、並びにあるＤｏＳ攻撃を回避できるようにするパケット／バイトの数について開示している。
【発明の概要】
【発明が解決しようとする課題】
【００３７】
それ故、本発明の目的は、前記問題を解消すると共に、ＳＤＮ（ソフトウェア定義ネットワーキング）セキュリティに関する装置、方法、システム、コンピュータプログラム、コンピュータプログラム製品、及びコンピュータ読み取り可能な媒体を提供することである。
【課題を解決するための手段】
【００３８】
本発明のある観点によれば、ユーザプレーンのメッセージが事前構成ルールに合致するかどうかチェックし、及びメッセージが事前構成ルールに合致すると決定された場合は、コントローラに送られるアドレス割り当てに関連した特定シグナリングメッセージの数が所定のスレッシュホールドに達したかどうかチェックし、そして所定のスレッシュホールドに達した場合には、コントローラへの特定シグナリングメッセージの送信を絞ることを含む方法が提供される。
【００３９】
本発明の別の観点によれば、アドレス割り当ての要求が所定の条件を満足するかどうか評価し、その要求が所定の条件を満足すると決定された場合には、ユーザプレーンの別のネットワーク要素が、ユーザプレーンのメッセージが事前構成ルールに合致するかどうかチェックするようにさせ、及びユーザプレーンのメッセージが事前構成ルールに合致する場合には、ユーザプレーンの別のネットワーク要素が、コントローラへの特定のシグナリングメッセージを絞るようにさせることを含む方法が提供される。
【００４０】
本発明の別の観点によれば、ユーザプレーンのネットワーク要素に使用するための装置において、少なくとも１つのプロセッサ、及びプロセッサにより実行されるべきインストラクションを記憶するための少なくとも１つのメモリを備え、この少なくとも１つのメモリ及びインストラクションは、少なくとも１つのプロセッサとで、装置が、少なくとも、ユーザプレーンのメッセージが事前構成ルールに合致するかどうかチェックし、及びメッセージが事前構成ルールに合致すると決定された場合には、コントローラに送られるアドレス割り当てに関連した特定シグナリングメッセージの数が所定のスレッシュホールドに達したかどうかチェックし、及び所定のスレッシュホールドに達した場合には、コントローラへの特定シグナリングメッセージの送信を絞る、ことを遂行するようにさせるよう構成された装置が提供される。
【００４１】
本発明の別の観点によれば、ネットワーク要素に使用するための装置において、少なくとも１つのプロセッサ、及びプロセッサにより実行されるべきインストラクションを記憶するための少なくとも１つのメモリを備え、この少なくとも１つのメモリ及びインストラクションは、少なくとも１つのプロセッサとで、装置が、少なくとも、アドレス割り当ての要求が所定の条件を満足するかどうか評価し、その要求が所定の条件を満足すると決定された場合には、ユーザプレーンの別のネットワーク要素が、ユーザプレーンのメッセージが事前構成ルールに合致するかどうかチェックするようにさせ、及びユーザプレーンのメッセージが事前構成ルールに合致する場合には、コントローラへの特定のシグナリングメッセージを絞ることをユーザプレーンの別のネットワーク要素に指示させる、よう構成された装置が提供される。
【００４２】
本発明の別の観点によれば、コンピュータのメモリにロードされるときに前記いずれかの方法のステップを生成するためのコード手段を備えたコンピュータプログラム製品が提供される。
【００４３】
本発明の更に別の観点によれば、ソフトウェアコード部分が記憶されるコンピュータ読み取り可能な媒体を備えた前記コンピュータプログラム製品が提供される。
【００４４】
本発明の更に別の観点によれば、処理装置の内部メモリにプログラムを直接ロードできる前記コンピュータプログラム製品が提供される。
【００４５】
本発明の更に別の観点によれば、ユーザプレーンのメッセージが事前構成ルールに合致するかどうかチェックするための手段、メッセージが事前構成ルールに合致すると決定された場合には、コントローラに送られるアドレス割り当てに関連した特定シグナリングメッセージの数が所定スレッシュホールドに達したかどうかチェックするための手段、及び所定スレッシュホールドに達した場合には、コントローラへの特定シグナリングメッセージの送信を絞るための手段、を備えた装置が提供される。
【００４６】
本発明の更に別の観点によれば、アドレス割り当ての要求が所定の条件を満足するかどうか評価するための手段、その要求が所定の条件を満足すると決定された場合には、ユーザプレーンの別のネットワーク要素が、ユーザプレーンのメッセージが事前構成ルールに合致するかどうかチェックするようにさせる手段、及びユーザプレーンのメッセージが事前構成ルールに合致する場合には、ユーザプレーンの別のネットワーク要素が、コントローラへの特定のシグナリングメッセージを絞るようにさせる手段、を備えた装置が提供される。
【００４７】
これら及び他の目的、特徴、詳細、及び効果は、添付図面に関連してなされる本発明の観点／実施形態の以下の詳細な説明から完全に明らかとなろう。
【図面の簡単な説明】
【００４８】
【図１】クライアントとサーバーとの間にＤＨＣＰを使用するアドレス割り当ての基本的な例を示すシグナリング図である。
【図２】ＤＨＣＰクライアントとして働くターミナル装置（ＴＥ）と、ＤＨＣＰサーバーとして働くイントラネット又はＩＳＰ（インターネットサービスプロバイダー）との間にＤＨＣＰｖ４を使用するアドレス割り当ての別の例を示すシグナリング図である。
【図３】スレッシュホールドに達しない場合に「パケット・イン」メッセージを絞るためにオープンフローコントローラを経てＰＧＷ−Ｃにより命令されるＰＧＷ−ＵにおけるＤＨＣＰリレーの一例を示す図である。
【図４】スレッシュホールドに達し且つ「パケット・イン」メッセージがない場合に「パケット・イン」メッセージを絞るためにオープンフローコントローラを経てＰＧＷ−Ｃにより命令されるＰＧＷ−ＵにおけるＤＨＣＰリレーの一例を示す図である。
【図５】スレッシュホールドに達しない場合にＤＨＣＰプロトコルを変更し且つ割り当てられたＩＰアドレスをＰＧＷ−Ｃに報告するためにオープンフローコントローラを経てＰＧＷ−Ｃにより命令されるＰＧＷ−ＵにおけるＤＨＣＰリレーを示す図である。
【図６】本発明のある規範的形態による方法の一例を示すフローチャートである。
【図７】本発明のある規範的形態による方法の別の例を示すフローチャートである。
【図８】本発明のある規範的形態による装置の一例を示すフローチャートである。
【図９】首尾良いＰＤＰコンテキストアクチベーションの一例を示すシグナリング図である。
【図１０】ＧＧＳＮと、認証、許可及びアカウンティング（ＡＡＡ）サーバーとの間のＲＡＤＩＵＳメッセージフローの一例を示すシグナリング図である。
【図１１】ＳＤＮをもたない最新形態のＤＨＣＰ構成信号フローを示すシグナリング図である。
【発明を実施するための形態】
【００４９】
以下、本発明の開示の規範的形態及び実施形態を、図面を参照して説明する。本発明を例示するために、３ＧＰＰベースの通信システム、例えば、ＬＴＥ／ＬＴＥ−Ａベースのシステムに基づくセルラー通信ネットワークに関連して実施例及び実施形態を説明する。しかしながら、本発明は、そのようなタイプの通信システム又は通信ネットワークを使用する用途に限定されず、例えば、５Ｇ通信ネットワーク又は固定ネットワーク、等の他のタイプの通信システム又は通信ネットワークにも適用できることに注意されたい。
【００５０】
以下の規範的形態及び実施形態は、例示に過ぎないことを理解されたい。明細書の多数の位置に「一(an)」、「１つの(one)」又は「幾つかの(some)」規範的形態又は実施形態が現れるが、これは、必ずしも、その各々が同じ規範的形態又は実施形態を指すか又は特徴が１つの規範的形態又は実施形態のみに適用されることを意味するものではない。異なる実施形態の１つの特徴を組み合わせて他の実施形態を形成してもよい。更に、「備える(comprising)」及び「含む(including)」という語は、ここに述べる実施形態を、ここに記載した特徴のみで構成することに限定するものではなく、又、そのような規範的形態及び実施形態は、ここに特別に記載されない特徴、構造、ユニット、モジュール、等を含んでもよいことを理解されたい。
【００５１】
本発明の規範的実施形態を適用できる通信ネットワークの基本的システムアーキテクチャーは、ワイヤード又はワイヤレスアクセスネットワークサブシステム及びコアネットワークを備えた１つ以上の通信システムの通常知られたアーキテクチャーを含む。そのようなアーキテクチャーは、１つ以上の通信ネットワーク制御要素、アクセスネットワーク要素、無線アクセスネットワーク要素、アクセスサービスネットワークゲートウェイ又はベーストランシーバステーション、例えば、ベースステーション（ＢＳ）、各カバレージエリア又はセルを制御するアクセスポイント又はｅＮＢ（進化型ノードＢ）を含み、それらと共に、ＵＥの一部でもあり又はＵＥ等に個別の要素として取り付けられる１つ以上の通信要素又はターミナル装置、例えば、ＵＥ（ユーザ装置）、又は同様の機能を有する別の装置、例えば、モデムチップセット、チップ、モジュール、等は、多数のタイプのデータを送信するために１つ以上のチャンネルを経て通信することができる。更に、コアネットワーク要素、例えば、ゲートウェイネットワーク要素、ポリシー及び課金制御ネットワーク要素、移動管理エンティティ、運転及び保守要素、等が含まれる。
【００５２】
実際のネットワーク形式にも依存するここに述べる要素の一般的機能及び相互接続は、当業者に良く知られ且つ対応規格にも記載されており、従って、詳細な説明は省略する。しかしながら、以下に詳細に述べるものの他に、ＵＥのような通信要素又はターミナル装置、及び無線ネットワークコントローラのような通信ネットワーク制御要素への又はそこからの通信に対して多数の付加的なネットワーク要素及びシグナリングリンクを使用してもよいことに注意されたい。
【００５３】
又、通信ネットワークは、他のネットワーク、例えば、公衆交換電話ネットワーク又はインターネットと通信することもできる。又、通信ネットワークは、クラウドサービスの使用をサポートすることもできる。ＢＳ及び／又はｅＮＢ又はそれらの機能は、ノード、ホスト、サーバー、クラウド、データセンター又はアクセスノードを使用し、そしてそのような使用に適したノード等のエンティティをフォワーディングすることにより実施できることが明らかである。
【００５４】
更に、本発明は、クラウドコンピューティング、バーチャル化及び工業規格大量サーバーにも適用できる。
【００５５】
この点に関して、クラウドコンピューティング及び工業規格大量サーバーは、文献“Network Functions Virtualization - Introductory White Paper”、ＥＳＴＩ（ヨーロピアンテレコミュニケーションズスタンダードインスティテュート）に次のように定義されている。
【００５６】
クラウドコンピューティング
ネットワーク機能バーチャル化は、クラウドコンピューティングについて開発されたもののような近代的なテクノロジーをレバレッジする。これらクラウドテクノロジーの中心には、バーチャル化メカニズム、即ちハイパーバイザー及び／又は（ドッカー）コンテナ又は同等のものによるハードウェアバーチャル化、並びにバーチャルマシンと物理的インターフェイスとの間にトラフィックを接続するためのバーチャルイーサネット（登録商標）スイッチ（例えば、ｖｓｗｉｔｃｈ）の使用がある。通信指向の機能については、広いＩ／Ｏ帯域巾を伴う高速マルチコアＣＰＵ（中央処理ユニット）、負荷分担及びＴＣＰオフローディングのためのスマートイーサネットＮＩＣの使用、バーチャルマシンメモリへのパケットの直接的ルーティング、及びポールモードイーサネットドライバ（割り込み駆動ではない、例えば、リナックス（登録商標）ＮＡＰＩ(新アプリケーションプログラミングインターフェイス)及びインテルのＤＰＤＫ(データプレーン開発キット)）により高性能パケット処理を利用することができる。クラウドインフラストラクチャーは、ネットワークのバーチャルアプライアンスの自動インスタンス化、正しいＣＰＵコア、メモリ及びインターフェイスへのバーチャルアプライアンスの指定によるリソースの管理、フェイルしたＶＭ（バーチャルマシン）の再初期化、スナップショットＶＭ状態、及びＶＭの移動に適用できるオーケストレーション及び管理メカニズムによりリソース利用性及び使用を改善する方法を提供する。最終的に、ＯｐｅｎＦｌｏｗ、ＯｐｅｎＳｔａｃｋ、ＯｐｅｎＮａａＳ、又はＯＧＦのＮＳＩのような管理及びデータプレーン制御のためのオープンＡＰＩの利用性は、ネットワーク機能バーチャル化及びクラウドインフラストラクチャーの付加的な集積度を与える。
【００５７】
工業規格大量サーバー
工業規格大量サーバーの使用は、ネットワーク機能バーチャル化のための経済的ケースにおける重要な要素である。ネットワーク機能バーチャル化は、ＩＴ産業の規模の経済性をレバレッジする。工業規格大量サーバーとは、標準的なＩＴコンポーネント（例えば、×８６アーキテクチャー）を使用して構築されそして数百万台販売されているサーバーである。工業規格大量サーバーの共通の特徴は、サーバー内で交換可能なサブコンポーネントの競合供給があることである。
【００５８】
更に、ここに述べるネットワーク要素及び通信装置、例えば、ターミナル装置又はＵＥのようなユーザ装置、ＢＳ又はｅＮＢのようなセルの通信ネットワーク制御要素、ＡＰ（アクセスポイント）のようなアクセスネットワーク要素、等、ＡＡＡ（認証、許可及びアカウンティング）サーバーのようなネットワークアクセス制御要素、等、並びにここに述べる対応する機能は、ソフトウェアにより、例えば、コンピュータのためのコンピュータプログラム製品により、及び／又はハードウェアにより、実施される。いずれにせよ、各機能を実行するため、対応的に使用される装置、ノード又はネットワーク要素は、制御、処理、及び／又は通信／シグナリング機能のために要求される多数の手段、モジュール、ユニット、コンポーネント、等（図示せず）を含む。そのような機能、モジュール、ユニット及びコンポーネントは、例えば、インストラクション及び／又はプログラムを実行し及び／又はデータを処理するために１つ以上の処理部分を含む１つ以上のプロセッサ又はプロセッサユニット、プロセッサのワークエリア又は処理部分等として働くためにインストラクション、プログラム及び／又はデータを記憶するストレージ又はメモリユニット又は手段（例えば、ＲＯＭ、ＲＡＭ、ＥＥＰＲＯＭ、等）、ソフトウェアによりデータ及びインストラクションを入力するための入力又はインターフェイス手段、監視及び操作の可能性をユーザに与えるためのユーザインターフェイス（例えば、スクリーン、キーボード、等）、プロセッサユニット又は部分の制御のもとでリンク及び／又は接続を確立するための他のインターフェイス又は手段（例えば、ワイヤード及びワイヤレスインターフェイス手段、例えば、アンテナユニット等を含む無線インターフェイス手段、無線通信部等を形成する手段）、等を含み、インターフェイスを形成する各手段、例えば、無線通信部分は、リモートサイト（例えば、無線ヘッド又は無線ステーション、等）に配置することもできる。本明細書において、処理部分は、１つ以上のプロセッサの物理的部分を表わすと考えるだけではなく、１つ以上のプロセッサによって遂行される関連処理タスクの論理的分割と考えてもよいことに注意されたい。
【００５９】
本発明の幾つかの規範的形態の目的は、（オンライン）課金及びトラフィック操向のような機能、例えば、サービスチェーン化／ＴＤＦ（トラフィック検出機能）環境に対し、ＰＧＷ−Ｃ及びＳＤＮコントローラを氾濫から保護すると同時に、必要に応じてＰＧＷ−ＣにおいてＩＰアドレス付与をサポートすることである。
【００６０】
専用イベント／トリガー情報、例えば、コントロールプレーン情報に基づいて、ユーザプレーンは、ＯｐｅｎＦｌｏｗメッセージ「パケット・イン(Packet IN)」を経てＳＤＮコントローラまで送られるシグナリング（ＤＨＣＰ）メッセージを絞るように指令される。これにより、ＳＤＮコントローラは、氾濫に対して保護される一方、ＳＤＮコントローラの頂部に乗るＰＧＷ−Ｃアプリケーションに必要なＩＰアドレスについて通知される。
【００６１】
或いは又、ＯｐｅｎＦｌｏｗプロトコルは、ＩＰアドレス（或いはＰＧＷ−Ｃにとってどんな情報エレメント（又はどんなアプリケーション）に関心があるか）のみがＳＤＮコントローラに報告されるように変更されてもよい。
【００６２】
現在ＯｐｅｎＦｌｏｗ仕様によれば、ＤＨＣＰプロトコルは、ＯｐｅｎＦｌｏｗ「パケット・イン」メッセージを経てＯＦコントローラ及び／又はＰＧＷ−Ｃへ転送され、コントローラ又はＰＧＷ−Ｃは、受け取った情報の操作の後に、ＯｐｅｎＦｌｏｗ「パケット・アウト(Packet Out)」メッセージを経てＤＨＣＰメッセージを転送するようにユーザプレーンに命令することができる。ＤＨＣＰメッセージをＯｐｅｎＦｌｏｗコントローラ（ＯＦＣ）及びＰＧＷ−Ｃまで転送するこの能力は、現在のＯｐｅｎＦｌｏｗプロトコルがＵＤＰ（ユーザデータグラムプロトコル）ポート６７及び６８（ＤＨＣＰを表わす）のマッチングを許すので、既に可能である。
【００６３】
しかしながら、全てのＤＨＣＰメッセージをＳＤＮコントローラまで送ることは、セキュリティ上の問題を引き起こす。というのは、ＳＤＮコントローラは、上述したように、ＤｏＳ攻撃により氾濫を受けるからである。
【００６４】
それ故、本発明の幾つかの規範的態様によれば、次の測定が示唆される。
【００６５】
ＤＨＣＰｖ４
全ＧＴＰ−Ｕトラフィックを完全に絞るのではなく、ＰＧＷ−Ｃ／ＳＤＮ−Ｃ（ソフトウェア定義ネットワーキングコントローラ）がＤＨＣＰ／ＲＡＤＩＵＳ絞りを要求することが示唆される３ＧＰＰ  ＴＳ２９．２７４に定義されたように、セッション生成要求メッセージ又は「ＰＤＮ接続」メッセージにおいてＰＣＯ（プロトコル構成オプション）内のＤＨＣＰｖ４を経てＵＥがＩＰｖ４アドレス割り当てを要求した場合は、通常のＧＴＰ−Ｕペイロード、及びユーザプレーンで搬送されるＤＨＣＰに別々にスキャンを適用することが示唆される。例えば、ＰＣＯ追加パラメータリストが０００ＢＨ（ＤＨＣＰｖ４を経てのＩＰｖ４アドレス割り当て）を含む場合には、ＵＥは、ＧＴＰトンネル確立の後にＧＴＰ−Ｕペイロードを経てそのＩＰｖ４アドレスそれ自体を割り当てようとし、そしてその場合、ＳＤＮコントローラ／ＰＧＷ−Ｃは、ＵＥが高い頻度で送られるＤＨＣＰｖ４メッセージで（例えば、ＯｐｅｎＦｌｏｗ又はＦｏｒｃｅを経て）ＳＤＮコントローラをおそらく氾濫させるセキュリティリスクにそれ自身を露出することがある。
【００６６】
従って、ＰＣＯが評価され、そしてＵＥがＰＣＯのＤＨＣＰｖ４又はＮＡＳ（非アクセス層）のＩＰｖ６を経てＩＰアドレス割り当てを要求する場合にのみ、ＰＧＷ−Ｃ  ＳＤＮコントローラは、ＩＰアドレス及びリース時間に関心があり、そしてＰＧＷ−Ｃ／ＳＤＮコントローラまで送信されるＵＥシグナリングで通知されることによりセキュリティリスクが生じる。
【００６７】
ＬＴＥ／４Ｇに定義されたＰＧＷ−Ｃは、ここでも一例に過ぎず、３ＧのＰＧＷに対応する機能は、ＧＧＳＮであることに注意されたい。ＰＧＷは、Ｓ５／Ｓ８インターフェイスを経てアドレスされ（３ＧＰＰ  ＴＳ２９．２７４  ＧＴＰｖ２コントロールプレーン（４Ｇ）を参照）、一方、ＧＧＳＮは、Ｇｎインターフェイスを経てアドレスされる（３ＧＰＰ  ＴＳ２９．０６０  ＧＴＰｖ１コントロールプレーン（３Ｇ）を参照）。
【００６８】
更に、ＰＧＷ及びＧＧＳＮのみがＣ及びＵプレーン分割を有するのではなく、ＳＧＷ（サービングゲートウェイ）もそうであることに注意されたい。これは、例えば、３ＧＰＰＴＳ２３．４０２、第４．７．１章、“Figure 4.7.1-1: IPv4 Address Allocation using DHCP with DHCP Server Collocated with the PDN GW and DHCP Relay in the Serving GW”、及び／又は第４．７．６章、“Figure 4.7.6-1: Prefix Delegation with DHCP Server Collocated with the PDN GW and DHCP Relay in the Serving GW when using PMIP-based S5/S8”に記載されている。
【００６９】
ＤＨＣＰがＰＧＷ−Ｕにおいて各々ＩＰ及びＧＴＰレベルにあるので、ＤＨＣＰシグナリングメッセージは、送信されて、ペイロードレベルでのみ評価される。
【００７０】
そのため、ＯｐｅｎＦｌｏｗプロトコル内の別のアクションが定義されてユーザプレーンへシグナリングされることが示唆される。
【００７１】
ＰＧＷ−Ｃは、（例えば、ＰＣＯの評価を伴う）当該ＧＴＰトンネルのためのＭＯＤ−Ｆｌｏｗ又はＡＤＤ−ＦＬＯＷを、ＤＨＣＰ／ＢＯＯＴＯプロトコルのＢＯＯＴＲＥＱＵＥＳＴ／ＢＯＯＴＲＥＰＬＹのための新たな追加アクションと共にＯＦＣコントローラへ送信する。
【００７２】
ＯＦコントローラは、これを、改善型対応ＯｐｅｎＦｌｏｗスイッチ（ＰＧＷ−Ｕ）へ転送する。改善型ＯｐｅｎＦｌｏｗスイッチは、
−ＤＨＣＰ発見（ＢＯＯＴＲＥＱＵＥＳＴ）、又は
−ＤＨＣＰオファー（ＢＯＯＴＲＥＰＬＹ）、又は
−ＤＨＣＰ要求（ＢＯＯＴＲＥＱＵＥＳＴ）、又は
−ＤＨＣＰ  ａｃｋ（ＢＯＯＴＲＥＰＬＹ）、又は
−ＤＨＣＰ情報（ＢＯＯＴＲＥＱＵＥＳＴ）、又は
−ＤＨＣＰ解除（ＢＯＯＴＲＥＱＵＥＳＴ）
が後で受け取られると、新たなアクションを評価する。
【００７３】
多数のＤＨＣＰサーバーへの異なる脚に対するＧＴＰ−Ｕの相関
例えば、ＰＧＷ−Ｕは、受け取ったメッセージを操作して、それが、ＤＨＣＰサーバーへ送られる進行中のＤＨＣＰ発見メッセージとして再書き込みされるようにするために、その領域内でのＤＨＣＰ発見メッセージの一致に関連したアクションの要求に基づいてＤＨＣＰ発見メッセージを保持する。
【００７４】
例えば、ＰＧＷ−Ｕは、ＤＨＣＰリレーエージェントのＩＰアドレスをｇｉａｄｄｒｅフィールドに挿入し、そして自身の新たなトランザクションＩＤをＤＨＣＰ発見メッセージの“ＸＩＤ”フィールドに戻すことが命令される。ＤＨＣＰオファーメッセージを受け取ると（各ＤＨＣＰサーバーから）、ＰＧＷ−Ｕは、受け取ったＸＩＤを、クライアントにより“ＸＩＤ”フィールドに送られたＤＨＣＰ発見メッセージで受け取られた値に置き換える。
【００７５】
ＰＧＷ−Ｕは、ＤＨＣＰ要求メッセージ及びＤＨＣＰ確認メッセージを受け取ると、同じアクションを遂行することが命令される。
【００７６】
ＰＧＷ−Ｕが多数のＤＨＣＰサーバーに接続される場合には、ＰＧＷ−Ｕは、ＤＨＣＰ発見メッセージを多数のＤＨＣＰサーバーへ複写することが命令される。
【００７７】
ＯＦコントローラがＸＩＤ値ごとにＤＨＣＰサーバーに向かってトランザクションＩＤを動的に決定しそしてＸＩＤごとにＰＧＷ−Ｕを非常に詳細に命令する権限を持つことは良いアイデアではないので、ＰＧＷ−Ｕ  ＤＨＣＰリレーがＵプレーンにおいてＤＨＣＰクライアントとＤＨＣＰサーバーとの間に相関を維持するのが極めて良好である。そのために、ＰＧＷ−Ｕが、到来するＸＩＤのハッシュ／マップテーブル、及び対応するＤＨＣＰサーバーのＩＰアドレス当りの出て行くＸＩＤと相関されるクライアントのＧＴＰ  ＴＥＩＤを生成／維持することが示唆される。
【００７８】
これがＰＧＷ−Ｕにおいて適用されない場合には、ＰＧＷ−Ｕが前記ＸＩＤをコントローラへ転送し、そしてコントローラがＰＧＷ−ＵにＸＩＤ値に置き換えることを命令することが示唆される。しかしながら、上述したように、これは、時間が掛かると共に、ＯＦコントローラに不必要な負担を負わせる。
【００７９】
ＤＨＣＰメッセージがクライアントから（即ち、ＧＴＰ側から）到来する場合には、ＤＨＣＰリレーエージェントのＩＰアドレスを挿入しなければならない（即ち、“ＯＰ”フィールドは、指示ＢＯＯＴＲＥＱＵＥＳＴを搬送する）。
【００８０】
ＤＨＣＰメッセージがサーバー（即ち、ＩＰ側）から到来する場合には、ＩＰアドレスが変更されない（即ち、“ＯＰ”フィールドは、指示ＢＯＯＴＲＥＰＬＹを搬送する）。
【００８１】
それ故、次のＯｐｅｎＦｌｏｗマッチングルールが示唆される。
−ＸＩＤ（トランザクションＩＤを搬送する）；
−ｇｉａｄｄｒ（ＤＨＣＰリレーエージェントのＩＰアドレスを搬送する）；
−ｙｉａｄｄｒ（ＵＥのＩＰアドレス(最近指定された)を搬送する）；
−ｃｉａｄｄｒ（ＵＥのＩＰアドレスクライアント(以前に指定／選択された)を搬送する）。
【００８２】
それ故、ＤＨＣＰメッセージを再書き込みできるようにするために、ＯｐｅｎＦｌｏｗプロトコルに対して有効な次の新たなアクションが創案される。
【００８３】
ＯｐｅｎＦｌｏｗ内に特定される新たな独占的アクション：
0006532963.tif 000002
テーブル１：ＯｐｅｎＦｌｏｗ内に特定される新たなアクション
【００８４】
前記新たなＯｐｅｎＦｌｏｗアクションは、ＤＨＣＰメッセージの受信に対するマッチングルールに関連している。
【００８５】
ＰＧＷ−ＵにおいてＧＴＰ−ＵとＤＨＣＰとの間に生じるプロトコルスタックマッピングを以下に示す。
0006532963.tif 000003
テーブル２：Ｓ５／Ｓ８からＳＧｉへのマッピング
0006532963.tif 000004
テーブル３：ＳＧｉからＳ５／Ｓ８へのマッピング
【００８６】
前記原子的アクションをマッチングルールにリストするのではなく、それらをコンパウンドリストにアグリゲートすることが更に示唆され、それについては、ＯＦＣ（ＯｐｅｎＦｌｏｗコントローラ）とＰＧＷ−Ｕ（ＯｐｅｎＦｌｏｗスイッチ）との間のＯｐｅｎＦｌｏｗシグナリングチャンネル上のバイトをいっそうセーブするために、より短い参照で言及される。
【００８７】
ＩＰアドレスの報告
更に、ＰＧＷ−Ｕは、指定されたＩＰアドレスをＯＦＣ及びＰＧＷ−Ｃに報告することが要求される。更に、割り当てられたＩＰアドレスのリース時間が経過するか又はＩＰアドレスの更新が拒絶されるか又はＩＰアドレスが除去されるときに、ＰＧＷ−Ｕがそれをコントローラにも報告するように、ＯｐｅｎＦｌｏｗコントローラ又はＰＧＷ−Ｃにより要求されることが通知で示唆される。
【００８８】
３ＧＰＰ  ＴＳ２９．０６１  Ｖ１２．６．０（第１３章を参照）によれば、次の条件によりベアラを解除することが要求される。
−ａ）ＤＨＣＰリースが満了になった場合；
−ｂ）ＤＨＣＰ更新がＤＨＣＰサーバーにより拒絶された場合；
−ｃ）更新プロセス中にＩＰアドレスが変化した場合。通常は、リースが更新されるとき、ＩＰアドレスは、不変のままである。しかしながら、何らかの理由で（例えば、ＤＨＣＰサーバーの構成不良）、リース更新プロセス中に異なるＩＰアドレスが割り当てられる場合には、その関連ベアラを解除しなければならない。
【００８９】
注：更に、ＵＥに又はＵＥから指定又は指定解除されるＩＰアドレスの割り当て及び割り当て解除は、ＰＣＲＦ（ポリシー・課金ルール機能）がそれに対応する変化をＴＤＦ（トラフィック検出機能）に通知できるように、ＰＣＲＦによりＰＣＥＦ（ポリシー・課金施行機能）／ＰＧＷ（３ＧＰＰ  ＴＳ２９．２１２、第４．５．３及び４ｂ．５．８章）から要求される。
【００９０】
ＩＰアドレスがＵＥに割り当てられることを報告できるようにするため、ＰＧＷ−ＣがＢＯＯＴＲＥＰＬＹメッセージ（即ち、サーバーからクライアントへ送られる）において“ｃｉａｄｄｒ”及び“ｙｉａｄｄｒ”の両フィールドのコンテンツをチェックするようにＯｐｅｎＦｌｏｗコントローラを経てＰＧＷ−Ｕに命令することが示唆される。“ｃｉａｄｄｒ”のコンテンツが“０”に等しくない場合には、“ｙｉａｄｄｒ”のコンテンツがＯｐｅｎＦｌｏｗを経てＰＧＷ−Ｃに報告される。というのは、それがリースされたＩＰアドレスを含むからである。
【００９１】
更に別の最適化として、ＰＧＷ−Ｕは、実際のＩＰアドレスを記憶し、次いで、ＩＰアドレスを、ＯｐｅｎＦｌｏｗを経てＰＧＷ−Ｃに設定された早期通知に比してそれが変化した場合だけ報告しなければならない。
【００９２】
ＤＨＣＰサーバーにより撤回されるＩＰアドレスの報告
ＩＰアドレスが撤回されることを報告できるようにするために、ＰＧＷ−ＣがＢＯＯＴＲＥＰＬＹメッセージ（即ち、サーバーからクライアントへ送られる）において“ｃｉａｄｄｒ”及び“ｙｉａｄｄｒ”の両フィールドのコンテンツをチェックするようにＯｐｅｎＦｌｏｗコントローラを経てＰＧＷ−Ｕに命令することが示唆される。“ｙｉａｄｄｒ”のコンテンツが“０”に等しく、次いで、“ｃｉａｄｄｒ”のコンテンツも“０”である場合には、ＩＰアドレスがＵＥから撤回されている。この場合には、このイベントを、ＯｐｅｎＦｌｏｗを経てＰＧＷ−Ｃに報告して、ＰＧＷ−Ｃがセッション／ヘッダを終了すべきかどうか判断できるようにしなければならない。
【００９３】
更に別の最適化として、ＰＧＷ−Ｕは、それに対応する流れをフローテーブルから除去し、そしてＯｐｅｎＦｌｏｗを経てＰＧＷ−Ｃに適宜に通知してもよい。
【００９４】
リース時間の監督
あるＵＥクライアントは、ＤＨＣＰ仕様に従って振舞わないことがあり得るので、ＵＥによるリソースの不正使用を拒絶するため付加的なセキュリティ及び課金監督手順が導入される。一般的に、ＩＰアドレスは、特定のリース時間に対してのみＵＥに指定される。リース時間が満了となる前に、ＵＥは、セッションを延長するようにＤＨＣＰサーバーに要求しなければならない。しかし、ＵＥが長いリース時間を要求しなかった場合は、ネットワークがそれに気付いて、ＧＴＰベアラの使用を終了することができる。
【００９５】
この問題は、次のいずれかで解決する。
ａ）ＤＨＣＰサーバーがリース時間をＯＦＣＳ（オフライン課金システム）及び／又はＯＣＳ（オンライン課金システム）に報告し、それらが考えられる悪用を監督するか、又は
ｂ）ＰＧＷ−Ｃが、ＵＥのためのＩＰアドレスを指定したＢＯＯＴＲＥＰＬＹメッセージの「再結合（Ｔ２）時間値」オプション（ＲＦＣ１５３３）においてシグナリングされるリース時間にマッチングさせ且つそれを抽出するようにＯＦＣを経てＰＧＷ−Ｕに命令しなければならない。
【００９６】
更に、ＰＧＷ−Ｃは、セッションを終了させ且つ不正使用を回避するために満了がＰＧＷ−Ｃに通知されるところのアコーディングタイマー(an according timer)をスタートさせるようＰＧＷ−Ｕに要求する。
【００９７】
このオプションのコード（「再結合（Ｔ２）時間値」）は５９であり、そしてその長さは４である（ＲＦＣ１５３３を参照）。
コード  長さ            Ｔ２間隔
＋- - -＋- - -＋- - -＋- - -＋- - -＋- - -＋
｜５９ ｜  ４ ｜ｔ１ ｜ｔ２ ｜ｔ３ ｜ｔ４ ｜
＋- - -＋- - -＋- - -＋- - -＋- - -＋- - -＋
【００９８】
ＰＧＷは、一例に過ぎないことに注意されたい。というのは、ＧＧＳＮ、ＢＲＡＳ（ブロードバンドリモートアクセスサーバー）、ＢＮＧ（ブロードバンドネットワークゲートウェイ）及びＳＧＳＮは、ＳＤＮの原理及びここに明らかにされる発明により分離できるからである。
【００９９】
ＰＰＰ等のためのＰＣＯ
ＰＣＯ追加パラメータリストがＩＰ  ＰＤＰタイプ又はＩＰ  ＰＤＮタイプに使用するために００００Ｈ  ＰＰＰを含む場合には、ＵＥは、ＧＴＰトンネル確立の後にＧＴＰ−Ｕペイロードを経てそのＩＰｖ４アドレスそれ自体を割り当てようとし、そしてその場合に、ＳＤＮコントローラＰＧＷ−Ｃは、それ自身を、例えば、次のような非常に頻繁に送信されるメッセージでＵＥがＳＤＮコントローラを（例えば、ＯｐｅｎＦｌｏｗ又はＦｏｒｃｅを経て）氾濫させるセキュリティリスクに曝すことがある。
−Ｃ０２１Ｈ（ＬＣＰ）；
−Ｃ０２３Ｈ（ＰＡＰ）パスワード認証プロトコル；
−Ｃ２２３Ｈ（ＣＨＡＰ）チャレンジハンドシェーク認証プロトコル；及び
−８０２１Ｈ（ＩＰＣＰ）ＩＰコントロールプロトコル。
【０１００】
ＰＰＰを経て
例えば、ここでは、ＩＰＣＰの取り扱いだけを説明する。しかしながら、ＰＰＰを経てのＬＰＣ、ＰＡＰＣＨＡＰの使用も除外されない。いずれにせよ、どのプロトコルも、潜在的には、ＵＥがＳＤＮコントローラを氾濫させそしてネットワークに著しくダメージを及ぼすのを許す。本発明では、それらの脅威を改善するための手段が設けられる。
【０１０１】
ＩＰｖ６ＣＰ構成オプションは、ＩＰＣＰにおける望ましいＩＰｖ６パラメータのネゴシエーションを許す。ＩＰＣＰがＮＣＰプロトコルとして使用される場合には、ＵＥは、「インターフェイス識別子」構成オプションを要求する。この構成オプションは、リンクのローカル端においてアドレス自動構成に使用されるべき独特の６４ビットインターフェイス識別子をネゴシエーションする方法を与える。ＩＰｖ６ユニキャストアドレスのインターフェイス識別子は、リンク上のインターフェイスを識別するのに使用される。それらは、サブネットプレフィックス内で独特であることが要求される。それ故、ＳＤＮコントローラＰＧＷ−Ｃは、識別子に関心がある。それ故、ＯｐｅｎＦｌｏｗ／ＦｏｒＣＥインターフェイスは、ＳＤＮコントローラ／ＰＧＷ−Ｃに「インターフェイス識別子」が通知される一方、プロトコル細部の他の観点がコントロールプレーンまで報告されないように「リンク識別子」構成オプションにおいてマッチングするために新たなアクション／メカニズムで増強される。
【０１０２】
ＤＨＣＰｖ６
ＩＰｖ６アドレスを得たＵＥは、ステートレスＤＨＣＰを使用して、例えば、０００ＡＨ  ＩＰアドレス割り当てを経、ＣＲＥＡＴＥ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ（セッション生成要求）のＰＣＯ追加パラメータリストのＮＡＳシグナリングを経て、ＤＮＳ（ドメインネームサービス）繰り返しネームサーバー又はＳＩＰ（セッションイニシエーションプロトコル）サーバーのリストのような他の構成情報を要求することができる。その場合に、ＳＤＮコントローラＰＧＷ−Ｃは、それ自身を、例えば、Ｉｎｆｏｒｍａｔｉｏｎ  Ｒｅｑｕｅｓｔ（情報要求）メッセージ及びＲｅｐｌｙ（応答）のような非常に頻繁に送信されるＤＨＣＰｖ６メッセージでＵＥがＳＤＮコントローラを（例えば、ＯｐｅｎＦｌｏｗ又はＦｏｒｃｅを経て）氾濫させるセキュリティリスクに曝すことがある。それに対して、プロトコルが、例えば、ＲＥＰＬＹ（応答）メッセージのＩＡアドレスオプションのような情報エレメントを情報要求メッセージにマッチングさせてＩＰｖ６アドレスを報告／サーチできるように、ＯｐｅｎＦｌｏｗプロトコルが改善される。又、Ｒｏｕｔｅｒ  Ａｄｖｅｒｔｉｓｅｍｅｎｔ（ルーター広告）メッセージは、除外されてもよい。
【０１０３】
図１１は、ＳＤＮを伴わない最新の３ＧＰＰ  ＴＳ２９．０６１に述べられたＤＨＣＰ構成信号フローを示すシグナリング図である。
【０１０４】
ステップＳ１１１において、Ｏ−ｆｌａｇセットを伴うＲｏｕｔｅｒ  ＡｄｖｅｒｔｉｓｅｍｅｎｔがＧＧＳＮからＴＥへ送信されて、他の構成情報を検索することをそれに指示する。
【０１０５】
ステップＳ１１２において、ＴＥは、ＩＰ行先アドレスセットを伴うＩＮＦＯＲＭＡＴＩＯＮ−ＲＥＱＵＥＳＴメッセージを、ＤＨＣＰｖ６  ＩＥＴＦ  ＲＦＣ３３１５に定義されたａｌｌ＿ＤＨＣＰ＿Ｒｅｌａｙ＿Ａｇｅｎｔｓ＿ａｎｄ＿Ｓｅｒｖｅｒｓへ送信する。ソースアドレスは、ＭＳのリンクローカルアドレスでなければならない。ＧＧＳＮのＤＨＣＰリレーエージェントは、メッセージを転送しなければならない。
【０１０６】
ステップＳ１１３において、転送されたＩＮＦＯＲＭＡＴＩＯＮ−ＲＥＱＵＥＳＴメッセージを受け取るＤＨＣＰサーバーは、ＲＥＬＡＹ−ＲＥＰＬＹ（リレー応答）メッセージを送信することにより、要求された構成パラメータと共にＲＥＰＬＹメッセージを含む“Ｒｅｌａｙ  Ｍｅｓｓａｇｅ（リレーメッセージ）”オプションで応答する。
【０１０７】
更に、ＰＭＩＰ（プロキシーモバイルＩＰ）に関連した３ＧＰＰ  ＴＳ２３．４０２に述べられたように、ＳＧＷは、ＤＨＣＰリレー機能も遂行する。
【０１０８】
更に、図９において、ＬＣＰ、認証及びＩＰＣＰネゴシエーションは、ＲＡＤＩＵＳ／ＤＨＣＰ又はＬ２ＴＰネゴシエーションへ及びそこからマップされる。それ故、ユーザプレーンに単純なＤＨＣＰリレーを与えるだけでなく、該当する場合には、ＳＤＮコントローラ／ＰＧＷ−Ｃからの詳細なインストラクションに基づき、ＬＣＰ又は認証又はＩＰＣＰネゴシエーションからＲＡＤＩＵＳ又はＤＨＣＰ又はＬ２ＴＰへのマッピング及びそれとは逆のマッピングを実施できることも示唆される。
【０１０９】
氾濫を絞り且つ回避するために、コントローラからユーザプレーンへ送信されるＯｐｅｎＦｌｏｗのＡＤＤＦｌｏｗ／ＭｏｄＦｌｏｗにおいて、例えば、“Ｓｃａｎ  ＤＨＣＰｖ４”又は“Ｓｃａｎ  ＤＨＣＰｖ６”及び“ＤＨＣＰ絞り”のような新たな独占的情報エレメントをＯｐｅｎＦｌｏｗプロトコルに追加することが提案される。
【０１１０】
例えば、“Ｓｃａｎ  ＤＨＣＰ”指示は、ＤＨＣＰメッセージを、正しさに対して及び“ＤＨＣＰ絞り”指示に基づき評価するようにユーザプレーンに命令しなければならず、ユーザプレーンは、ＤＨＣＰメッセージのあるスレッシュホールド（シグナリングされた）を越えた場合にはＤＨＣＰメッセージをコントローラまで送信（及び／又は減少）してはならない。又、もちろん、絞りを除去する指示も示唆される。
【０１１１】
しかしながら、更に、悪意のあるＤＨＣＰシグナリングによりコントローラが全く影響を受けないようなメカニズムが実施されねばならず／実施されてもよい。その原理は、次の通りである。
１）増強されたＯｐｅｎＦｌｏｗコントローラが、ＰＧＷ−Ｕにおけるユーザプレーンレベルで新たなＯｐｅｎＦｌｏｗルールによりＤＨＣＰプロトコルコンテンツを操作することによりＳＤＮベースのＤＨＣＰリレーエージェントへＧＴＰ  ＤＨＣＰユーザプレーンコンテンツを転送することを要求できるように、新たなＯｐｅｎＦｌｏｗプロトコルエレメントを特定しそして配置する。
２）増強されたＯｐｅｎＦｌｏｗコントローラが、割り当てられたＩＰアドレス及びそれに対応するリース時間に関する通知を要求でき、そして指定されたＩＰアドレスの変化について通知されるように、新たなＯｐｅｎＦｌｏｗプロトコルエレメントを特定しそして配置する。
３）どのみち、ステップ２）で指定されたＩＰアドレスは、ＰＣＲＦ（図５を参照）へ報告され、ＰＧＷ−Ｃ／ＯＦＣは、新たに指定されたＩＰアドレスがそれに対応する確立されたＧＴＰトンネルに接着されるようにルールをインストールしなければならない（このステップ３）のこのメカニズムは、ＤＨＣＰリレー機能がなくてもＰＧＷ−Ｕに既にサポートされるので、最新型であると思われる）。
【０１１２】
このケースで、ＰＧＷ−Ｃ／ＳＤＮコントローラが全てのＤＨＣＰメッセージ又はフィルタされたＤＨＣＰメッセージについて通知されない場合には、ユーザプレーンにおいて全てのＤＨＣＰメッセージをスキャンし、そしてそのメッセージをコントローラへ転送する前に絞りメカニズムを適用する強い必要性はない。即ち、そのケースでは、ＵＥが非常に高いレートでＤＨＣＰメッセージを送信する場合にはＵＥがそれ自身のサービスにしか影響を及ぼさないので（悪意のあるＤＨＣＰシグナリングに対してそのＧＴＰトンネルの帯域巾を消費するので）、ＳＤＮコントローラは、氾濫しない。しかしながら、ユーザプレーンは、そのケースでは、ＤＨＣＰシグナリングに対して透過的であるので、コントローラは、頻繁なＩＰアドレス（及び／又はリース時間指示）通知から保護されねばならない。それ故、ＩＰアドレス（リース時間）通知の数も絞る新たな情報エレメントを導入することが示唆される。
【０１１３】
一般的に、ＯｐｅｎＦｌｏｗは一例に過ぎないことに注意されたい。フォース(Force)は、別のプロトコルである。
【０１１４】
ＰＧＷも一例に過ぎない。というのは、一般的に、ＧＧＳＮがＰＧＷと同じ機能を与えるからである。
【０１１５】
前記説明は、ＰＧＷに焦点を当てたものであったが、もちろん、分解型ＳＧＷ及び分解型ｅＮＢに解決策を適用することもできる。原理的に、ｅＮＢ−Ｃ及びＳＧＷ−Ｃには同じメカニズムを適用できるが、最終的には、ＰＧＷ−Ｃは、ＵＥのＩＰアドレスを得ることも必要であり、従って、ＰＧＷでも同じ手順を遂行しなければならない。しかし、これは、手順が２回遂行されたときにリソースの浪費を意味する。それとは別に、ｅＮＢ−Ｃ又はＳＧＷ−Ｃは、ＩＰアドレスをＰＧＷ−Ｃへ送信する（好ましくは、ＧＴＰ−Ｃプロトコルのセッション生成要求又は同様のものを経て）。
【０１１６】
しかしながら、ＤＨＣＰプロトコルからＩＰアドレスを抽出するための同じ手順が遂行される。
【０１１７】
ＤＨＣＰ  ｖ４は、一例に過ぎず、そしてＤＨＣＰ  ｖ６は、本発明を適用する別のプロトコルである。それとは別に、ＰＰＰ及びＲＡＤＩＵＳ（リモート認証ダイヤルインユーザサービス）プロトコル、又はＬ２ＴＰ（レイヤ２トンネルプロトコル）も、別の例である。
【０１１８】
例えば、ＬＣＰ（リンクコントロールプロトコル）、認証及びＩＰＣＰ（ＩＰコントロールプロトコル）（ＩＰｖ４のためのＰＰＰ  ＮＣＰ(ネットワークコントロールプロトコル)）ネゴシエーションを受け取ると、対応するシグナリングをＲＡＤＩＵＳ／ＤＨＣＰ／Ｌ２ＴＰ（図９）へマップしなければならない（及び逆方向においてはそれと逆に）。平易なＤＨＣＰリレー機能の説明と同様に、ＳＤＮコントローラ／ＰＧＷ−Ｃ／ＧＧＳＮ−Ｃは、攻撃に対して保護される必要がある。例えば、全部ではないがＰＰＰシグナリングをＳＤＮコントローラ／ＰＧＷ−Ｃ／ＧＧＳＮ−Ｃへ転送しなければならない。しかしながら、ＵＥに割り当てられるＩＰアドレス、リース時間、等は、前記情報を搬送する対応プロトコルを評価しそして関連情報を検出して上位レイヤ（ＳＤＮ）コントローラ／ＧＧＳＮ−Ｃに報告することにより、ＳＤＮコントローラ／ＰＧＷ−Ｃ／ＧＧＳＮ−Ｃにも入手できねばならない。
【０１１９】
更に、ＩＰアドレスそれ自体も一例に過ぎず、ＩＰアドレスのリース時間は、抽出されて／コントローラへ送信されるべき別の例である。
【０１２０】
或いは又、ＯｐｅｎＦｌｏｗプロトコルの既知の「パケット・イン」メッセージを使用して、全ＤＨＣＰメッセージをコントローラまで送信するのではなく、ＯｐｅｎＦｌｏｗプロトコルは、ＩＰアドレスのみを（又はＰＧＷ−Ｃにとって関心のあるどんな情報エレメントも）ＳＤＮコントローラへ報告するように変更されてもよい。しかしながら、「パケット・イン」メッセージが要求されるか、或いは、例えば、ＩＰアドレス又は「リース時間」等の報告が要求されるかに関わらず、絞りメカニズムを適用しなければならない。
【０１２１】
ＤＨＣＰは、ここでも、一例に過ぎず、ＰＧＷ−Ｃだけでなく、ＢＲＡＳ（ブロードバンドリモートアクセスサーバー）も、ＳＤＮコントローラに依存するアプリケーションの一例であり、そしてＳＤＮコントローラは、敵意のあるＵＥシグナリング（ＰＰＰｏＥ  ＰＰＰオーバーイーサネット、ＲＡＤＩＵＳ）からのセキュリティ保護を必要とする。
【０１２２】
コントロールプレーンにおけるＤＨＣＰリレー
図３は、スレッシュホールドに達していない場合に「パケット・イン」メッセージを絞るためにＯｐｅｎＦｌｏｗコントローラを経てＰＧＷ−Ｃにより命令されるＰＧＷ−ＵにおけるＤＨＣＰ応答の一例を示す図である。
【０１２３】
図３に見られるように、例えば、「ＤＨＣＰｖ４を経てのＩＰｖ４アドレス割り当て」に対してセットされたＰＣＯと共に３ＧＰＰ  ＧＴＰ−Ｃ（ＴＳ２９．２７４）セッション生成要求を受信すると（ステップＳ３１）、ＰＧＷ−Ｃは、ＵＥにより送られるＤＨＣＰメッセージの数を、例えば、ＯｐｅｎＦｌｏｗのＡｄｄＦｌｏｗ又はＭｏｄＦｌｏｗにおける「１ＤＨＣＰメッセージ／秒」にセットされた「ＤＨＣＰ絞る」指示と比較することを、ＳＤＮコントローラを経てＰＧＷ−Ｕに命令する（ステップＳ３２）。
【０１２４】
そのケースにおいて、ＰＧＷ−Ｕは、過負荷を回避するために「パケット・イン」メッセージにおける全てのＤＨＣＰメッセージをコントローラまで送信しない。ステップＳ３３（セッション生成応答）の後であって且つＳＧＷ及びｅＮＢを経てＵＥに到達した後に（ステップＳ３４）、ＵＥは、そのＩＰアドレスを得るためにＤＨＣＰ  ＤＩＳＣＯＶＥＲ（発見）メッセージを発生する（ステップＳ３５）。これは、第１のＤＨＣＰメッセージであるから、ＰＧＷ−Ｕは、その発見メッセージを、「パケット・イン」メッセージにおいてＤＳＮコントローラを経てＰＧＷ−Ｃへ（命令されたように）報告する（ステップＳ３６）。ＤＨＣＰメッセージがＳＤＮコントローラで保持されること又は保持されないことが考えられる。ＰＧＷ−Ｃ又はＳＤＮコントローラは、ＰＧＷ−Ｕに命令して（ステップＳ３７）、ＯｐｅｎＦｌｏｗのパケット・アウトメッセージにより発見メッセージを送信する（ステップＳ３８）。それに続く及び／又はそれに応答するＤＨＣＰメッセージは、一般に、スレッシュホールドに違反しない限り、同様に取り扱われる。
【０１２５】
図４は、スレッシュホールドに達し且つ「パケット・イン」メッセージがない場合に「パケット・イン」メッセージを絞るためにオープンフローコントローラを経てＰＧＷ−Ｃにより命令されるＰＧＷ−ＵにおけるＤＨＣＰリレーの一例を示す図である。
【０１２６】
図４に示すように、多数のＤＩＳＣＯＶＥＲＹメッセージ（又はＲＥＱＵＥＳＴ等のような他のＤＨＣＰメッセージ）がステップＳ３５において送信され、従って、ＳＤＮコントローラによりＰＧＷ−Ｕに指示されるようにスレッシュホールドに違反する。その結果、それらのメッセージは、ＳＤＮコントローラに影響を及ぼしたり面倒をかけたりすることなく、ＰＧＷ−Ｕプレーンにより破棄される。図４のステップＳ３１からＳ３５は、図３のステップＳ３１からＳ３５に対応し、その説明を繰り返すことは省略する。
【０１２７】
更に、それに加えて、ＳＤＮコントローラは、不正形式のメッセージが無視されるようにＤＨＣＰメッセージを（例えば、「ＤＨＣＰスキャン」で）スキャンすることをユーザプレーンに要求することによっても保護され、それ故、ＳＤＮコントローラに面倒がかからないか、又は既に述べたように、敵意のある情報エレメントは、コントローラへ送られる前に除去される。
【０１２８】
ユーザプレーンにおけるＤＨＣＰリレー
図５は、スレッシュホールドに達しない場合にＤＨＣＰプロトコルを変更し且つ割り当てられたＩＰアドレスを、その後の使用のために（例えば、課金等のために）、ＰＧＷ−Ｃに報告するように、オープンフローコントローラを経てＰＧＷ−Ｃにより命令されるＰＧＷ−ＵにおけるＤＨＣＰリレーを示す図である。
【０１２９】
前記とは別に、ユーザプレーンは、全てのＤＨＣＰメッセージをコントローラへ送信し且つ全てのＤＨＣＰメッセージをコントローラから受信するのではなく、図５に示すように、ＤＨＣＰオファーで検出されるリース時間又はＩＰアドレスを報告することだけが命令される。この点に関して、対応するメッセージをＰＧＷ−Ｕレベルに保持するために、ＧＴＰトンネルを考えられる多数の異なるＤＨＣＰ行先サーバーと相関させることが必要である。これを達成するために、ＳＤＮコントローラは、一致が検出されてコントローラへ報告される前に相関を行うようにＰＧＷ−Ｕに命令する必要がある。
【０１３０】
このケースでは、ＤＨＣＰメッセージがユーザプレーンに完全に保持され、そしてこのケースでは、ＳＤＮコントローラは、「スレッシュホールド指示」により同様に保護される。というのは、このケースでも、ＳＤＮコントローラは、それが、例えば、ＩＰアドレスについて頻繁に通知される場合には、悪意のある振舞いにより氾濫及び影響を受けるからである。
【０１３１】
ＵＥがセッション生成要求メッセージ又は「ＰＤＮ接続」メッセージにおいてＰＣＯ（プロトコル構成オプション）内のＤＨＣＰｖ４を経てＩＰｖ４アドレス割り当てを要求する場合には、ＰＧＷ−Ｃは、ＰＧＷ−ＵにおいてＯｐｅｎＦｌｏｗコントローラを経てＤＨＣＰリレー機能の呼び出しを要求することが示唆される。更に、ＰＧＷ−Ｃは、ＩＰアドレスの割り当て及び割り当て解除を報告することを、ＯＦＣを経て、ＰＧＷ−Ｕに要求しなければならない（詳細については、ステップＳ３２を参照されたい）。
【０１３２】
そのため、ユーザプレーンがＤＨＣＰメッセージのコンテンツに一致しそしてＤＨＣＰメッセージにおけるアクションを遂行することができるようにＯｐｅｎＦｌｏｗプロトコルにおいて新たなルールが示唆される。
【０１３３】
ＵＥのためのＤＨＣＰリレーエージェントは、例えば、ＧＴＰトンネルの割り当てと一緒に割り当てられねばならないので、ＩＰアドレス（割り当て／割り当て解除）をＯＦＣ及びＰＧＷ−Ｃに報告する要求は、ＭＯＤ−Ｆｌｏｗ又はＡＤＤ−Ｆｌｏｗのような通常のＳＤＮメッセージと共に搬送されるのが好ましく、これは、ＧＴＰトンネル及び／又はＩＰトンネル等を設定するためにアプリケーションとコントローラとの間で交換される必要が既にある。
【０１３４】
ＤＨＣＰは、この場合も、１つの特定アプリケーションの一例に過ぎないことに注意されたい。というのは、本発明から利益を得ることのできる他のアプリケーションも考えられるからである。
【０１３５】
ＤＨＣＰリレー手順を完全にサポートするために、次のことが創案される。
【０１３６】
ＤＨＣＰシグナリングメッセージは、ＤＨＣＰがＰＧＷ−Ｕにおいて各々ＩＰ及びＧＴＰレベルにあるので、ペイロードレベルのみにおいて送信されて評価される。
【０１３７】
図５から分かるように、ＰＧＷ−Ｃは、ステップＳ３２において強調されたユーザプレーン内でのＤＨＣＰリレー機能を遂行するようにＳＤＮコントローラを経てＰＧＷ−Ｕに要求し、そして更に、あるスレッシュホールドを越える場合にはＩＰアドレス（及びリース時間）の通知を絞るようにユーザプレーンに命令する。更に、ステップＳ５６において、ＰＧＷ−ＵのＤＨＣＰリレー機能は、ＧＴＰ−Ｕトンネルをユーザプレーン上の１つ以上の外部ＤＨＣＰサーバーと相関させ、そしておそらく変更されたＤＨＣＰシグナリング（相関を許すための）を（コントローラに通知するのではなく）ＤＨＣＰサーバーへ直接転送する。ステップＳ５７においてＤＨＣＰサーバーからの応答を受け取ると、ＤＨＣＰリレー機能は、スレッシュホールドを越えない場合には、ステップＳ５８において、ＩＰアドレス及びリース時間をコピーし、そしてそれをコントロータへ報告する。ＰＣＲＦは、ステップＳ５８ａにおいて、ＩＰアドレス、等が通知される。ステップＳ５８と同時に、ＤＨＣＰシグナリングがステップＳ５９においてＵＥに向けて転送される。
【０１３８】
図５のステップＳ３１からＳ３５は、図３のステップＳ３１からＳ３５に対応し、その説明を繰り返すことは省略する。
【０１３９】
スレッシュホールドを越えた場合には、通知（ステップＳ５８）が抑制され、そしてステップＳ５９も抑制される。
【０１４０】
ＩＰアドレス及びリース時間は、コントローラに関心のある情報の一例に過ぎないことに注意されたい。
【０１４１】
更に、それに加えて、ＳＤＮコントローラは、不正形式のメッセージを無視するようにＤＨＣＰメッセージをスキャンすることをユーザプレーンに要求することによっても保護され、それ故、ＳＤＮコントローラに面倒がかからないか、又は図３に示すように、敵意のある情報エレメントは、コントローラへ送られる前に除去される。
【０１４２】
以上のことから、本発明のある規範的態様によれば、ＳＤＮコントローラがＳＤＮ環境において攻撃されることがないので、ネットワークのセキュリティが確保される。
【０１４３】
以下、図６から８を参照して、本発明の規範的態様のより一般的な説明を行う。
【０１４４】
図６は、本発明の規範的形態による方法の一例を示すフローチャートである。
【０１４５】
本発明のある規範的形態によれば、この方法は、例えば、ＰＧＷ−Ｕ、等のユーザプレーンにおけるネットワーク要素で実施されてもよいし、又はその一部分であってもよい。この方法は、ステップＳ６１において、ユーザプレーンのメッセージが事前構成ルールに合致するかどうかチェックすることを含む。ステップＳ６１において、メッセージが事前構成ルールに合致すると決定された場合には、この方法は、更に、ステップＳ６２において、コントローラに送られるアドレス割り当てに関連した特定シグナリングメッセージの数が所定のスレッシュホールドに達したかどうかチェックし、及び所定のスレッシュホールドに達した場合には、ステップＳ６３において、コントローラへの特定シグナリングメッセージの送信を絞る、ことを含む。
【０１４６】
本発明のある規範的形態によれば、前記絞ることは、特定シグナリングメッセージの送信を減少し、そしてコントローラへの特定シグナリングメッセージの送信を完全に停止することを含む。
【０１４７】
本発明のある規範的形態によれば、この方法は、更に、所定のスレッシュホールドに達しない場合には、特定シグナリングメッセージをコントローラへ送信し、そして特定スレッシュホールドに達し且つ送信が絞られた場合には、コントローラから要求があったときに特定シグナリングメッセージの送信を再開することを含む。
【０１４８】
本発明のある規範的形態によれば、この方法は、更に、特定情報を搬送する特定シグナリングメッセージをサーチし、特定シグナリングメッセージからその特定情報を抽出し、及びその抽出された特定情報をコントローラへ送信することを含む。
【０１４９】
本発明のある規範的形態によれば、特定シグナリングメッセージは、ダイナミックホスト構成プロトコルＤＨＣＰ、リモート認証ダイヤルインユーザサービスＲＡＤＩＵＳ、レイヤ２トンネルプロトコルＬ２ＴＰ、及びポイント対ポイントプロトコルＰＰＰの１つによるシグナリングメッセージである。
【０１５０】
本発明のある規範的形態によれば、この方法は、更に、ＤＨＣＰリレー又はＬＣＰ／認証／ＩＰＣＰネゴシエーションを経てＲＡＤＩＵＳ／ＤＨＣＰ／Ｌ２ＴＰマッピング機能へ特定情報を送信することを含む。
【０１５１】
本発明のある規範的形態によれば、その特定情報は、インターネットプロトコルアドレス、又はインターネットプロトコルアドレスのリース時間である。
【０１５２】
本発明のある規範的形態によれば、ユーザプレーンのメッセージは、そのメッセージが動的なホスト構成、ＲＡＤＩＵＳ、Ｌ２ＴＰ、又はＰＰＰプロトコルに合致するときに、事前構成ルールに合致する。
【０１５３】
本発明のある規範的形態によれば、コントローラは、ＯｐｅｎＦｌｏｗプロトコル又は転送及び制御エレメント分離プロトコルの一方に合致する。
【０１５４】
図７は、本発明の規範的形態による方法の別の例を示すフローチャートである。
【０１５５】
本発明のある規範的形態によれば、この方法は、例えば、ＰＧＷ−Ｃ又はＳＤＮコントローラ、等のネットワーク要素で実施されてもよいし、又はその一部分であってもよい。この方法は、ステップＳ７１において、アドレス割り当ての要求が所定の条件を満足するかどうか評価することを含む。ステップＳ７１においてその要求が所定の条件を満足すると決定された場合には、この方法は、更に、ステップＳ７２において、ユーザプレーンの別のネットワーク要素が、ユーザプレーンのメッセージが事前構成ルールに合致するかどうかチェックするようにさせ、及びステップＳ７３において、ユーザプレーンのメッセージが事前構成ルールに合致する場合には、ユーザプレーンの別のネットワーク要素が、コントローラへの特定のシグナリングメッセージを絞るようにさせることを含む。
【０１５６】
本発明のある規範的形態によれば、前記絞ることは、特定シグナリングメッセージの送信を減少し、そしてコントローラへの特定シグナリングメッセージの送信を完全に停止することを含む。
【０１５７】
本発明のある規範的形態によれば、前記所定の条件は、ダイナミックホスト構成プロトコルＤＨＣＰ、リモート認証ダイヤルインユーザサービスＲＡＤＩＵＳ、レイヤ２トンネルプロトコルＬ２ＴＰ、又はポイント対ポイントプロトコルＰＰＰの１つを経てアドレス割り当てが要求されたことを含む。
【０１５８】
本発明のある規範的形態によれば、アドレス割り当ては、少なくとも、ユーザ装置又はサーバー、等のようなマシンタイプ通信を遂行する装置である要素によって要求される。更に、アドレス割り当てを要求する要素は、いずれかの種類のセンサ、スマートウェアラブル（衣服）、又はモバイルビデオ監視に関連したいずれかの種類の装置、自律的駆動、触覚インターネット、クラウドのサーバー、ローカル及び／又はリモート、集中型又は分散型データセンターにおそらく存在するロボット制御及びそれに対応するアプリケーション対応部である。
【０１５９】
本発明のある規範的形態によれば、事前構成ルールは、ユーザプレーンのメッセージが、ダイナミックホスト構成プロトコルＤＨＣＰ、リモート認証ダイヤルインユーザサービスＲＡＤＩＵＳ、レイヤ２トンネルプロトコルＬ２ＴＰ、又はポイント対ポイントプロトコルＰＰＰの１つに合致するメッセージであることを含む。
【０１６０】
本発明のある規範的形態によれば、アドレス割り当ては、セッション生成要求メッセージにおいて汎用パケット無線サービストンネルプロトコルコントロールプレーンＧＴＰ−Ｃを経て要求される。
【０１６１】
本発明のある規範的形態によれば、アドレス割り当ては、パケットデータプロトコルＰＤＰコンテキスト生成要求メッセージにおいてゲートウェイ汎用パケット無線サービスサポートノードＧＧＳＮを経て要求される。
【０１６２】
本発明のある規範的形態によれば、この方法は、更に、プロトコル構成オプションＰＣＯにおいて、ＤＨＣＰ、リンクコントロールプロトコルＬＣＰ、パスワード認証プロトコルＰＡＰ、チャレンジハンドシェーク認証プロトコルＣＨＡＰ、及びインターネットプロトコルコントロールプロトコルの１つを経てアドレス割り当てが要求されるかどうか評価することを含む。
【０１６３】
図８は、本発明のある規範的形態による装置の一例を示すブロック図である。
【０１６４】
図８は、本発明の前記観点を実施するように構成された装置８０の構成を示すブロック回路図である。図８に示す装置は、以下に述べるものの他に多数の更に別の要素又は機能を備えているが、それらは、本発明を理解する上で重要ではないので簡単化のために省略する。更に、装置は、装置の一部分であるか、装置に個別の要素として取り付けられる、等々の同様の機能を有する別の装置、例えば、チップセット、チップ、モジュール、等でもよい。
【０１６５】
装置８０は、プログラム等により与えられるインストラクションを実行するＣＰＵ等の処理機能又はプロセッサ８１を備えている。プロセッサ８１は、以下に述べる特定の処理専用の１つ以上の処理部分を含むか、又は単一のプロセッサで処理が実行されてもよい。又、そのような特定の処理を実行するための部分は、例えば、ＣＰＵのような１つの物理的プロセッサ又は多数の物理的エンティティにおいて、個別の要素として或いは１つ又は更に別のプロセッサ又は処理部分内に設けられてもよい。参照符号８２は、プロセッサ８１に接続されたトランシーバ又は入力／出力（Ｉ／Ｏ）ユニット（インターフェイス）を表わす。Ｉ／Ｏユニット８２は、１つ以上の他のネットワーク要素、エンティティ、ターミナル、等と通信するのに使用される。Ｉ／Ｏユニット８２は、多数のネットワーク要素に向かう通信装置を含む複合ユニットでもよいし、或いは異なるネットワーク要素のための複数の異なるインターフェイスを伴う分散型構造を含んでもよい。装置８０は、更に、プロセッサ８１により実行されるプログラム及びデータを記憶するのに使用でき及び／又はプロセッサ８１のワーキングストレージとして使用できる少なくとも１つのメモリ８３も備えている。
【０１６６】
プロセッサ８１は、前記観点に関連した処理を実行するように構成される。特に、装置８０は、例えば、ＰＧＷ−Ｕ等のユーザプレーンのネットワーク要素で実施されてもよいし又はその一部分でもよく、そして図６に関連して述べた方法を遂行するように構成される。従って、プロセッサ８１は、ユーザプレーンのメッセージが事前構成ルールに合致するかどうかチェックを行い、そしてメッセージが事前構成ルールに合致すると決定された場合には、コントローラに送られるアドレス割り当てに関連した特定のシグナリングメッセージの数が所定のスレッシュホールドに達したかどうかチェックし、及び所定のスレッシュホールドに達した場合には、コントローラへの特定のシグナリングメッセージの送信を絞るように構成される。
【０１６７】
本発明のある規範的形態によれば、装置８０は、例えば、ＰＧＷ−Ｃ又はＳＤＮコントローラ等のネットワーク要素で実施されてもよいし又はその一部分でもよく、そして図７を参照して述べる方法を遂行するように構成される。従って、プロセッサ８１は、アドレス割り当ての要求が所定の条件を満足するかどうか評価し、その要求が所定の条件を満足すると決定された場合には、ユーザプレーンの別のネットワーク要素が、ユーザプレーンのメッセージが事前構成ルールに合致するかどうかチェックするようにさせ、及びユーザプレーンのメッセージが事前構成ルールに合致する場合には、ユーザプレーンの別のネットワーク要素がコントローラへの特定のシグナリングメッセージを絞るようにさせることを遂行するように構成される。
【０１６８】
装置８０の機能に関する更なる詳細については、図６及び７に関連して述べた本発明のある規範的形態による方法の説明を参照されたい。
【０１６９】
従って、ユーザプレーンのネットワーク要素に使用するための装置、及びネットワーク要素に使用するための装置は、一般的に、同じ構造上のコンポーネントを有し、それらのコンポーネントは、上述したように、各々、ネットワーク要素の各機能を実行するように構成されることに注意されたい。
【０１７０】
装置の前記規範的説明において、本発明の原理を理解する上で関連性のあるユニット／手段だけを、機能的ブロックを使用して説明した。装置は、その各々の動作に必要な更に別のユニット／手段を備えている。しかしながら、それらのユニット／手段の説明は、本明細書では省略する。装置の機能的ブロックの構成は、本発明を限定するものではなく、それらの機能は、１つのブロックにより遂行されてもよいし、又はサブブロックへと更に分割されてもよい。
【０１７１】
以上の説明において、装置（又は何らかの他の手段）がある機能を遂行するように構成されると述べられたときは、各装置のメモリに記憶されたコンピュータプログラムコードと潜在的に協働する（少なくとも１つの）プロセッサ又はそれに対応する回路が、少なくともそのように述べられた機能を装置に遂行させるよう構成されたと述べることと同等であると解釈されたい。又、そのような機能は、各機能を遂行するための特別に構成された回路又は手段により同等に実施可能であると解釈されたい（即ち、「・・するように構成されたユニット」という表現は、「・・のための手段」のような表現と同等であると解釈されたい。
【０１７２】
上述した本発明の目的に対して、次のことに注意されたい。
【０１７３】
−おそらくソフトウェアコード部分として実施され且つ（デバイス、装置及び／又はそのモジュールの例として或いは装置及び／又はそのモジュールを含むエンティティの例として）装置のプロセッサを使用して実行される方法ステップは、ソフトウェアコード独立であり、そしてそれら方法ステップにより定義される機能が保存される限り、既知の又は将来開発されるプログラミング言語を使用して特定することができる。
【０１７４】
−一般的に、いずれの方法ステップも、その観点／実施形態の考え方を変化させたり、実施される機能に関して変更したりすることなく、ソフトウェアとして又はハードウェアにより実施するのに適している。
【０１７５】
−前記で定義された装置又はそのモジュールにおいておそらくハードウェアコンポーネントとして実施される方法ステップ及び／又はデバイス、ユニット、又は手段（例えば、前記観点／実施形態により装置の機能を実行するデバイス）は、ハードウェア独立であり、そして既知の又は将来開発されるハードウェアテクノロジー或いはそれらの混成、例えば、ＭＯＳ（金属酸化物半導体）、ＣＭＯＳ（相補的ＭＯＳ）、ＢｉＭＯＳ（バイポーラＭＯＳ）、ＢｉＣＭＯＳ（バイポーラＣＭＯＳ）、ＥＣＬ（エミッタ結合ロジック）、ＴＴＬ（トランジスタ・トランジスタロジック）等を使用し、例えば、ＡＳＩＣ（特定用途向けＩＣ(集積回路)）コンポーネント、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）コンポーネント、ＣＰＬＤ（コンプレックスプログラマブルロジックデバイス）コンポーネント、又はＤＳＰ（デジタル信号プロセッサ）コンポーネントを使用して、実施することができる。
【０１７６】
−デバイス、ユニット又は手段（例えば、前記で定義された装置、又はそれらの各ユニット／手段の１つ）は、個々のデバイス、ユニット又は手段として実施できるが、これは、デバイス、ユニット又は手段の機能が保存される限り、それらがシステム全体にわたり分散形態で実施されることを除外するものではない。
【０１７７】
−装置は、半導体チップ、チップセット、或いはそのようなチップ又はチップセットを含む（ハードウェア）モジュールによって表わされるが、これは、装置又はモジュールの機能が、ハードウェアで実施されるのではなく、プロセッサにおいて実行／ランするための実行可能なソフトウェアコード部分を含むコンピュータプログラム又はコンピュータプログラム製品のような（ソフトウェア）モジュールのソフトウェアとして実施される可能性を除外するものではない。
【０１７８】
−デバイスは、１つの装置と考えてもよいし、或いは例えば、同じデバイスハウジング内で互いに機能的に協働するか又は互いに機能的に独立であるかに関わりなく、２つ以上の装置のアッセンブリと考えてもよい。
【０１７９】
一般的に、前記観点による各機能的ブロック又は要素は、各部分の前記機能を遂行するようにのみ適応される場合には、各々、ハードウェア及び／又はソフトウェアのいずれかの既知の手段により実施できることに注意されたい。ここに述べる方法ステップは、個々の機能的ブロックにおいて又は個々のデバイスにより実現することができ、或いは方法ステップの１つ以上は、単一の機能的ブロックにおいて又は単一のデバイスにより実現することができる。
【０１８０】
一般的に、いずれの方法ステップも、本発明の考え方を変更せずに、ソフトウェアとして又はハードウェアにより実施するのに適している。デバイス及び手段は、個々のデバイスとして実施できるが、これは、デバイスの機能が保存される限り、それらがシステム全体にわたって分散形態で実施されることを除外するものではない。そのような及びそれと同様の原理が当業者に知られていると考えるべきである。
【０１８１】
ソフトウェアとは、ここでの説明の意味では、コード手段又は部分を含むソフトウェアコード、或いは各機能を遂行するためのコンピュータプログラム又はコンピュータプログラム製品、並びに各データ構造又はコード手段／部分が記憶されたコンピュータ読み取り可能な（ストレージ）媒体のような有形媒体において実施されるか或いは信号又はチップにおいて潜在的にその処理中に実施されるソフトウェア（或いはコンピュータプログラム又はコンピュータプログラム製品）を含む。
【０１８２】
上述した観点／実施形態並びに一般的及び特定の例は、例示のために設けられたものに過ぎず、本発明をそれに限定するものではないことに注意されたい。むしろ、特許請求の範囲内に入る全ての変更及び修正も網羅されるものとする。
【符号の説明】
【０１８３】
８０：装置
８１：プロセッサ
８２：Ｉ／Ｏユニット
８３：メモリ
【図１】
0006532963.tif 000005
【図２】
0006532963.tif 000006
【図３】
0006532963.tif 000007
【図４】
0006532963.tif 000008
【図５】
0006532963.tif 000009
【図６】
0006532963.tif 000010
【図７】
0006532963.tif 000011
【図８】
0006532963.tif 000012
【図９】
0006532963.tif 000013
【図１０】
0006532963.tif 000014
【図１１】
0006532963.tif 000015