JP2010508680A

JP2010508680A - Ｉｐネットワークをインタフェースするための方法及び装置

Info

Publication number: JP2010508680A
Application number: JP2009533670A
Authority: JP
Inventors: パオライオヴァンナ、; ウンベルトプロペルツィ，; クラウディオポルフィリ，; ラウラヴェッランテ，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2006-10-31
Filing date: 2006-10-31
Publication date: 2010-03-18
Anticipated expiration: 2026-10-31
Also published as: EP2087711A1; DE602006019331D1; EP2087711B1; JP5054114B2; US20080101357A1; ATE493833T1; WO2008052597A1

Abstract

電気通信システム内のノードを操作する方法である。このノードは、ネットワークアドレス変換機能を介して、レイヤ４制御プロトコルを使用するピアエンティティ群とＩＰパケットを送受信するように構成されている複数のエンティティを備える。レイヤ４制御プロトコルは、レイヤ４パケットチャンクに複数のＩＰアドレスを含めることをエンティティに許容することによってマルチホーミングを促進する。この方法は、複数のエンティティのそれぞれにおいて、エンティティの１つ以上のプライベートアドレスをネットワークアドレス変換機能の１つ以上のパブリックアドレスにマッピングするテーブルを保持し、エンティティによって生成されるアソシエーション開始メッセージそれぞれに対して、対応するプライベートＩＰアドレス（群）に対して、テーブルから取得されるネットワークアドレス変換機能のパブリックＩＰアドレス（群）を、アソシエーション開始メッセージのレイヤ４パケットチャンクに含める。
【選択図】なし

Description

本発明は、異なるＩＰアドレス空間を有するＩＰネットワーク群をインタフェースするための方法及び装置に関するものである。本発明は、特に、必須ではないが、ストリーム制御送信プロトコルを利用するノードに対して、ネットワークアドレス変換インタフェース（Network Address Translation interface）を提供することに適用可能である。

電気通信ネットワークのオペレータは、自身のネットワークを、伝統的な回線交換機能からＩＰ機能へ切り替えることを開始している。後者のＩＰ機能は、ＩＰが可能にする相互運用性の部分によって、ネットワーク容量の増加、インフラストラクチャコストの削減の効果を有している。ＩＰシグナリングネットワーク（ある程度の範囲までは、ユーザプレーンネットワーク（user plane network）とトランスポートリソースを共有する仮想ネットワークである）では、ネットワークエンティティは、従来より、オペレータドメイン内の固有のＩＰアドレスが割り当てられている。これらのエンティティに、他のオペレータのドメイン内のエンティティと通信することを可能にするために、ネットワークアドレス変換（ＮＡＴ）プロトコルが、ドメイン間のインタフェースで実現されても良い。ＮＡＴの使用は、他のドメインのアドレス割当処理に影響を与えることなく、オペレータに、エンティティとそのＩＰアドレスを動的に変更することを可能にする。

エンティティ群は、単一のノードを形成するためにクラスタにすることができ、これに伴い、クラスタの各エンティティは、ホームドメイン内の自身が所有する「プライベート」ＩＰアドレスを使用してアドレスされることが可能であるが、エンティティ群全体では、単一の「パブリック」ＩＰアドレスを使用して、あるいはパブリックアドレスのプールを共有してアドレスされることが可能である。ＮＡＴインタフェースは、共通のＩＰアドレスにアドレスが割り当てられている、あるいは正規のエンティティに所有されるプールのＩＰアドレス群にアドレスが割り当てられているパケットをルーティングする責任がある。

トランスポート制御プロトコル（ＴＣＰ）は、ＩＰベースの電気通信ネットワーク内で一般的に使用されているレイヤ４プロトコルであり、これは、エンドツーエンドのパケット搬送を保証し、かつ受信したＩＰパケットの上位レイヤ（即ち、アプリケーション）へのルーティングを取り扱う。それゆえ、ＴＣＰは、ノード（エンティティ群のクラスタを構成する）内の各ネットワークエンティティで実現されることになる。与えられる（ポート番号によって特定される）アプリケーションにおいて、ＴＣＰは、バイトストリームの搬送に対して、それぞれがシーケンス番号を有するバイトを提供する。受信側ノードでは、ＴＣＰレイヤは、適切なアプリケーションのためにバイトを受け渡す。ＴＣＰは、バイトストリーム内の個々のメッセージストリームを識別する機能は有していない。

個々のメッセージストリームの処理は、いくつかの理由で望ましいものである。例えば、ある事柄に関するあるメッセージストリームにおけるメッセージの損失が、他の事項に関する他のメッセージストリーム内のメッセージに影響することを回避することである。この目的を達成するために、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）は、ＴＣＰの代替物を提供するストリーム制御送信プロトコル（ＳＣＴＰ）として知られるプロトコルを規定している。ＳＣＴＰは、ピア（同位：peer）ＳＣＴＰエンティティ間のＳＣＴＰ「アソシエーション（関連付け）」の確立を提供する。アソシエーションは、両者のＩＰアドレス／ポート番号のペアによって、かつ検証タグ（各ＳＣＴＰピアによって割り当てられているもの）のペアによって定義される。ＳＣＴＰパケットは、共通ヘッダとデータチャンクとの２つの部分を構成している。この共通ヘッダは、送信者によって割り当てられる検証タグを含み、これは、アソシエーション識別子を提供する。新規のアソシエーションを開始するＳＣＴＰメッセージは、検証タグフィールドにゼロ値を含んでいる。一方、データチャンクは、「ＩＮＩＴ（あるいは開始）」チャンクと呼ばれる特定チャンクであり、これは、同一のアソシエーションに属する連続メッセージ群で使用される検証タグの値を保持する開始タグを含んでいる。加えて、同一のアソシエーション内のメッセージストリームは、ストリームＩＤによって区別される。これは、各データ（ＤＡＴＡ）チャンクのヘッダに含まれている（与えられるストリームの第１メッセージは、そのストリームに対して使用されることになるストリームＩＤを含んでいる）。送信者のＳＣＴＰメッセージは、メッセージヘッダ内に、ＳＣＴＰメッセージの内容の全体に渡って与えられているＡｄｌｅｒ−３２チェックサムを含んでいて、これにより、ネットワーク内のデータ破損に対して更なる保護を提供する。

同一セッション内で複数のストリームを容易にすることに加えて、ＳＣＴＰは、いわゆるマルチホーミングを提供する。マルチホーミングは、複数のＩＰアドレスによって、単一のノード（あるいはノードエンティティ）を識別するための機能のことを指している。ＳＣＴＰメッセージを開始するアソシエーションのＩＮＩＴチャンクは、送信ノードが利用可能であるＩＰｖ４及びＩＰｖ６アドレスの一方を含んでいて、一方、応答メッセージのＩＮＩＴＡＣＫチャンクは、ピアノードが利用可能であるＩＰｖ４及びＩＰｖ６アドレスの少なくとも一方を含んでいる。

ＩＥＴＦＲＦＣ３２５７［ストリーム制御送信プロトコルの適用性説明書］は、単一のホーム化セッション群が使用される場合の状況を検討していて、かつ、ピアエンティティ群の１つはＮＡＴの下に配置されていることを想定している。これは、トランスポート（ＩＰ）アドレスは、ＩＮＩＴチャンクあるいはＩＮＩＴＡＣＫチャンクで送信されるべきでないことを提案している。これは、エンドポイントに、この開始メッセージを受信して、このアソシエーションに対する唯一の宛先アドレスとしてＩＰヘッダのソースアドレスを使用することを強要することになる。このソースアドレスは、ＮＡＴによって、開始側のエンティティに割り当てられるパブリックＩＰアドレスとなる。ＩＰアドレス（群）は、送信側のＳＣＴＰエンティティによって省略されても良い。あるいは、ＮＡＴがＳＣＴＰアウェア（aware）を行なう場合には、ＮＡＴは、ＳＣＴＰチャンクを適切に修正することができる。しかしながら、後者の場合は、ＮＡＴに対しては、新規の３２ビットチェックサムを計算することが必要である。更に、これらの方法の重大な欠点は、その処理が、ＮＡＴの下にあるエンティティよるマルチホーミングの使用を排除することである。これは、複数のＩＰアドレスが、ＳＣＴＰＩＮＩＴチャンクあるいはＳＣＴＰＩＮＩＴＡＣＫチャンクに含まれることをマルチホーミングが要求することを定義していることによるものである。

マルチホーミングが要求される場合、ＮＡＴは、内部で表現されるＩＰアドレスそれぞれに対するパブリックＩＰアドレスを持たなければならない。ＮＡＴの下にあるマルチエンティティノードは、ＮＡＴがＩＮＩＴチャンクとＩＮＩＴＡＣＫチャンクに置換することができる、ＩＰアドレスを有するＮＡＴを事前にコンフィグレーション（構成）する（preconfigure）ことができる。選択的には、ＮＡＴは、内部のアプリケーションレイヤゲートウェイ（ＡＬＧ）を有することができる。これは、ノードが最初にＮＡＴをコンフィグレーション（configure：構成）することなく、ＩＮＩＴチャンクとＩＮＩＴＡＣＫチャンク内のＩＰアドレスをインテリジェントに変換することになる。両者の場合、ＮＡＴの下のエンティティ群は、１つ以上の共通パブリックＩＰアドレス（典型的な事例となる）を共有する場合、いくつかの適切なポート番号マッピングが、ピアアソシエーション単位でＮＡＴによって適用されなければならない。これは、ＳＣＴＰエンドポイントが、与えられるアソシエーション内のすべてのメッセージに対して同一のポート番号を受信し続けることを保証するためである。しかしながら、これらの方法は、いくつかの場合は、ＳＣＴＰメッセージを修正し、また、３２ビットのチェックサムを再計算し、そして、大量数のポートを管理するためのＮＡＴを必要とする。

本発明の第１の構成に従えば、電気通信システム内のプライベートネットワークを操作する方法が提供される。このプライベートネットワークは、ネットワークアドレス変換機能を介して、レイヤ４制御プロトコルを使用するピアエンティティ群とＩＰパケットを送受信するように構成されている複数のエンティティを備える。このレイヤ４制御プロトコルは、レイヤ４パケットチャンクに複数のＩＰアドレスを含めることをエンティティに許容することによってマルチホーミングを促進する。

この方法は、
複数のエンティティのそれぞれにおいて、エンティティの１つ以上のプライベートアドレスをネットワークアドレス変換機能の１つ以上のパブリックアドレスにマッピングするテーブルを保持し、
エンティティによって生成されるアソシエーション開始メッセージそれぞれに対して、対応するプライベートＩＰアドレス（群）に対して、テーブルから取得されるネットワークアドレス変換機能のパブリックＩＰアドレス（群）を、アソシエーション開始メッセージのレイヤ４パケットチャンクに含める。

典型的な実装では、複数のエンティティは、単一の物理ノードに含まれている。ネットワークアドレス変換機能は、プライベートネットワークに接続され、また、同一の物理ノード内に存在していても良い。

本発明の実施形態では、レイヤ４制御プロトコルは、ストリーム制御送信プロトコルであり、アソシエーション開始メッセージは、ＩＮＩＴチャンクあるいはＩＮＩＴＡＣＫチャンクを含むストリーム制御送信プロトコルである。

好ましくは、ネットワークアドレス変換機能は、ノード内のネットワークアドレス変換エンティティで実現され、また、ネットワークアドレス変換機能は、レイヤ４パケットを変更しない。複数のエンティティそれぞれに対するネットワークアドレス変換エンティティにおいて、ネットワークアドレス変換バインディングテーブルが保持されていて、また、ネットワークアドレス変換バインディングテーブルは、ネットワークアドレス変換エンティティのプライベートアドレスの１つあるいはそれぞれを、ネットワークアドレス変換機能のパブリックアドレスとアソシエーション識別タグの範囲にマッピングする。ＳＣＴＰの場合、これらのアソシエーション識別タグは、検証タグである。

好ましくは、ネットワークアドレス変換エンティティにおいての進行中のＩＰパケットそれぞれに対して、対応するネットワークアドレス変換バインディングテーブルを使用して、ＩＰパケットのヘッダのソースアドレスフィールドに含まれるプライベートアドレスが、パブリックＩＰアドレスにマッピングされ、かつパブリックＩＰアドレスの代わりにプライベートＩＰアドレスを使用する。ネットワークアドレス変換エンティティにおいて到来するＩＰパケットに対して、対応するネットワークアドレス変換バインディングテーブルを使用して、ＩＰパケットのヘッダの宛先フィールドに含まれるパブリックＩＰアドレスとレイヤ４パケットのヘッダに含まれるアソシエーション識別タグとを、プライベートＩＰアドレスへマッピングし、かつプライベートアドレスの代わりにパブリックＩＰアドレスを使用する。

好ましくは、複数のエンティティそれぞれは、複数のプライベートＩＰアドレスに割り当てられ、複数のプライベートＩＰアドレスは、ノードのローカルドメイン内で固有であり、また、パブリックＩＰアドレス群は、プールとしてアドレス間で共有される。

本発明の他の構成は、電気通信ネットワークで使用するためのノード、電気通信システムのノードをコンフィグレーションする方法、ネットワークアドレス変換エンティティをコンフィグレーションする方法、ネットワークアドレス変換エンティティを操作する方法、電子通信システム内のプライベートネットワークを操作する方法に関するものであり、これらは、請求項によって定義される。

ネットワークアドレス変換機能を利用する電気通信ネットワーク内のノードを示す図である。コンフィグレーションフェーズ中にＳＣＴＰエレメントからＮＡＴデバイスへ送信されるシグナリングを示す図である。コンフィグレーションフェーズ中にＮＡＴデバイスからＳＣＴＰエレメントへ送信されるシグナリングを示す図である。図１のノードにおいて発信するパケットの処理を示す図である。図１のノードにおいて到来するパケットの処理を示す図である。

図１では、ノード１が示され、これは、電気通信ネットワーク内に存在する場合がある。典型的には、ノードのすべてのコンポーネントは同じ位置に配置されていて、また、実際には、単一のラック構造内のいくつかのボードによって提供される場合がある。この例では、ノードは、エレメントのペアとして、それぞれ参照番号２及び３で示されるエレメント１とエレメント２を備えている。これらは、第１のＩＰアドレス空間を有するローカルあるいはプライベートネットワーク４内に配置されている。これらのエレメントは共に、ＳＣＴＰを利用可能であり、マルチホーミングを使用する。各エレメントは、この空間内で２つの固有アドレスに割り当てられていて、即ち、エレメント１にはＩＰ１とＩＰ２が割り当てられ、エレメント２にはＩＰ３とＩＰ４が割り当てられている。

ノード１は、更に、ＮＡＴデバイス５を備え、これは、プライベートネットワークアドレス空間内で１つ以上の固有のＩＰアドレスによって識別されるプライベートネットワーク４とのインタフェースを有している。ＮＡＴデバイスは、パブリックＩＰネットワーク６（ある意味では、パブリックは、他のプライベートネットワークによってアクセス可能であるが、だれもがアクセス可能である必要はない）に接続されていて、また、パブリックネットワークのアドレス空間内で２つの固有のＩＰアドレス、即ち、ＩＰ＿ＡとＩＰ＿Ｂとを有している。ＮＡＴデバイス５は、本質的には従来からのものであり、また、エレメントの１つから受信される発信ＳＣＴＰパケット群に対して、ＩＰヘッダ内に含まれるプライベートネットワークＩＰアドレスをパブリックＩＰアドレス群の１つに置換する。到来パケット群に対しては、ＮＡＴデバイスは、以下で説明する、マッピング機能を使用して、逆置換を実行する。ＮＡＴデバイスは、通常の方法で、プライベートネットワークアドレスの秘匿を提供する。

エレメント２及び３にはそれぞれ、本明細書では、ローカルＮＡＴ７として参照される新規の機能エンティティが提供されている。ローカルＮＡＴ７の役割は、ＩＰレイヤでのＩＰアドレスを変更しないまま、ＳＣＴＰレイヤで、プライベートＩＰアドレスのパブリックＩＰアドレスへの置換を実行することである。ローカルＮＡＴは、ＮＡＴデバイス５にのみ影響を与えて、標準的なＳＣＴＰに影響を与えることなく、対応するリモートエレメント要素間のエンドツーエンドＳＣＴＰアソシエーションを処理することを可能にする。

使用する前には、ローカルＮＡＴ７とＮＡＴデバイス５の両方を、ＩＰアドレスマッピングでコンフィグレーション（設定）する必要がある。コンフィグレーション（configuration）フェーズは、２つのステージを備える。第１ステージでは、（検証）タグ値の範囲がエレメント２及び３それぞれに対して定義され、かつ割り当てられる。一方、第２ステージでは、プライベートアドレスとパブリックアドレス間のマッピング情報を記憶するテーブルが、ＮＴデバイス５とローカルＮＡＴ７内にコンフィグレーションされる。

更にもう１つのステージを想定する場合、エレメント２及び３はそれぞれ、検証タグ値の範囲に割り当てられる。このレンジは、各エレメントに対して異なるものであり、それらの間では重複は存在しない。この範囲の割当は、様々な方法で実行することができる。例えば、それらのエレメント群に、隣接する同一のサイズの範囲を割り当てることができる。あるいは、最大処理能力を有するエレメントにより大きなレンジを割り当てるアルゴリズムを使用することもできる。

コンフィグレーションフェーズの第２ステージは、エレメント２及び３それぞれと、ＮＡＴデバイス５間でのメッセージの交換を行なう。かなり単純なメッセージの交換だけが必要とされる。このような交換は、ＴＣＰを使用して実行することができ、また、このステージでは、それのために、エレメント群とＮＡＴとの間のＳＣＴＰアソシエーションを確立する必要がないことが理解されるであろう。エレメントは、自身のプライベートＩＰアドレスと、エレメントに割り当てられている検証タグ範囲を、ＮＡＴデバイスに通信することによって、この交換を開始する。次に、ＮＡＴデバイス５は、エレメント２及び３のプライベートＩＰアドレスを１つのパブリックＩＰアドレスあるいは複数のパブリックＩＰアドレスにマッピングし、このマッピングと、検証タグ範囲を、自身が所有するマッピングテーブルに記憶する。次に、ＮＡＴデバイスは、そのマッピング情報をエレメントに送信する。そして、エレメントは、そのマッピング情報を、自身のローカルＮＡＴのマッピングテーブルに記憶する。

このコンフィグレーションフェーズが、ＮＡＴデバイス５の下の各エレメントに対して完了した後、すべてのエレメントとＮＡＴデバイスは、コンフィグレーションされたそれらの自身のマッピングテーブルを有することになる。図２及び図３は、コンフィグレーションフェーズ中に、ＳＣＴＰエレメントとＮＡＴデバイス間のシグナリングの交換を示している。一方、後述の表１から表３は、ＮＡＴデバイス、第１エレメント及び第２エレメントそれぞれで生成され得るマッピングテーブル群を示している。

ＳＣＴＰアソシエーションを開始する場合、エレメントは、ＩＮＩＴチャンクあるいはＩＮＩＴＡＣＫチャンクを含むＳＣＴＰメッセージを準備しなければならない。図に示されるエレメント１及びエレメント２の１つについて検討すると、ＩＮＩＴチャンクあるいはＩＮＩＴＡＣＫチャンクを準備する場合、エレメントは、事前に生成しているローカルのマッピングテーブルを使用して、自身のプライベートネットワークアドレスを各パブリックネットワークアドレスに置換する。この処理は、ローカルＮＡＴによって実行される。次に、エレメントは、修正されたメッセージに渡って３２ビットのチェックサムを生成し、これをＳＣＴＰメッセージヘッダに含める。

ＮＡＴデバイス５は、パブリックネットワークから受信されるＳＣＴＰパケットとは異なるパブリックネットワーク６へ送信されるＳＣＴＰパケットを処理する。しかしながら、この処理は、比較的単純であり、ＩＰレベルでのＩＰアドレスの変換を行なう。

外部ネットワークへ送信されるＳＣＴＰパケットが、ＮＡＴデバイスを通過する場合、ＮＡＴデバイスは、すべてのＳＣＴＰパケットに対して、図４にも示される、以下の処理を実行する。

ＮＡＴデバイスは、パケットのＩＰヘッダからソースプライベートＩＰアドレスを取得する。

ＮＡＴデバイスは、プライベートＩＰアドレスを検索キーとして使用する、自身のマッピングテーブルでのルックアップ処理を実行する。このルックアップ処理の結果は、コンフィグレーションフェーズ中にプライベートＩＰアドレスにマッピングされているパブリックＩＰアドレスである。

ＮＡＴデバイスは、ルックアップ処理の結果として得られるパブリックアドレスをソースＩＰアドレスとして使用して、ＩＰヘッダを構築し、ＳＣＴＰパケット内のフィールドを変更することなく、そのパケットをパブリックネットワークへ送信する。

［注ポート変換は発生しない、例えば、ＩＥＴＦＲＦＣ３２５７参照］
開始メッセージの場合では、そのメッセージを受信するピアＳＣＴＰエレメントは、ＩＮＩＴチャンクあるいはＩＮＩＴＡＣＫチャンク内の２つのパブリックＩＰアドレスのプレゼンスを検出することになる。これは、開始を行なうエレメントに対するプライマリ配信アドレスとして、それらの内の１つを使用することになる。一方で、必要とされる場合には、第２パブリックＩＰアドレスを維持している（例えば、それに続くリンク障害による）。

ここで、ＳＣＴＰパケットが、パブリックネットワーク６からＮＡＴデバイス５に到達し、これが、プライベートネットワークエレメント（また、これは、既に確立されているＳＣＴＰアソシエーションに関連している）に向けられているものと想定すると、この処理は、ＩＰヘッダ内の宛先ＩＰアドレスと、ＳＣＴＰヘッダで搬送される検証タグ値を使用する。特に、ＮＡＴデバイスは、
ＩＰヘッダから宛先ＩＰアドレスを取得して、また、ＳＣＴＰヘッダから検証タグ値を取得する。

このデータを検索キーとして使用して、自身のマッピングテーブルでルックアップ処理を実行し、その結果は、パケットがアドレスされているエレメントのプライベートＩＰアドレスとなる。

宛先アドレスとして判定されたプライベートアドレスを含む新規のＩＰヘッダを生成し、そのパケットをプライベートネットワークを介して送信する。

この処理は、図５で示される。

この処理は、ＩＮＩＴチャックを搬送するＳＣＴＰパケットを別として、パブリックネットワークから到来する各ＳＣＴＰパケットに対して実行される。上述のように、ＩＮＩＴチャンクを搬送するＳＣＴＰパケットは、ＳＣＴＰヘッダ内にゼロに設定されている検証タグ値を有している。ＮＡＴは、このようなパケットに対してはマッピングを実行することができない。これは、このような検証タグ値に対しては、ＮＡＴテーブルでは対応するものが存在しないからである。それゆえ、検証タグ値がゼロである場合、ＮＡＴは、いくつかの決定アルゴリズムに従って、そのメッセージを割り当てるためのエレメントを選択することになる。例えば、ＮＡＴ決定アルゴリズムは、現在の負荷に基づいて内部のエレメントを選択することができる。２つ以上のエレメントがこの負荷の要件を満足する場合、管理しているアソシエーションの数がより少ないエレメントが選択される。２つ以上のエレメントがこの基準を更に満足する場合、候補のエレメント群からランダムにエレメントが選択されても良い。

ＮＡＴデバイスはＳＣＴＰパケット内の任意のデータを変更する必要がないので、本明細書で提示されるソリューションは、ＮＡＴデバイスにかかる処理負担を最小にすることが理解されるであろう。特に、ＮＡＴデバイス内では、ＳＣＴＰによって必要とされる３２ビットチェックサムを計算する必要はない。代わりに、これは、ＳＣＴＰエレメント２及び３によって計算される。

ＳＣＴＰエレメント内では、ローカルＮＡＴは、ＳＣＴＰによって容易になされ、かつＮＡＴデバイスにかかる処理負荷を削減するような、マルチホーム化アソシエーションをサポートする基本的な役割を果たしている。特に、ローカルＮＡＴは、ＩＮＩＴチャンクあるいはＩＮＩＴＡＣＫチャンクに、プライベートアドレスの代わりに、ＳＣＴＰエンティティのプライベートマルチホーミングアドレスに対応するパブリックＩＰアドレスを含めることを担当する。

提案されるソリューションは、単一のアソシエーション及びマルチホーム化アソシエーションの両方の場合にも、リンク障害に関する高度の耐性をプライベートネットワークに導入する。リンク障害がプライベートネットワーク内で発生し、かつパブリックネットワークからエレメントあるいはＮＡＴＩＰアドレスに到達できない場合でも、システムは、正常に処理を継続することができる。本明細書で想定する事例としては、２つ存在する。

第１に、パブリックネットワークに向けて送信されるＳＣＴＰに対しては、ＳＣＴＰを利用可能なエレメント（プライベートネットワーク内の）自身はリンク障害を感知すると、現在のアソシエーションに対して使用している、代替プライベートＩＰアドレスからパケットを送信する。ＮＡＴが両方（あるいはすべての）プライベートアドレスに対して既にコンフィグレーションされている場合、パブリックネットワークに向かっているＳＣＴＰパケットに対するリンク障害はトランスペアレントである。

第２に、パブリックネットワークから到来するＳＣＴＰパケットの場合に対しては、２つの状況が想定され得る。第１の状況では、リンク障害の管理は、ＳＣＴＰメカニズムを単独で責任をとる。パブリックネットワークから到来するＳＣＴＰパケットが、リンク障害によって到達できないプライベートＩＰアドレスに向けられている場合、ＮＡＴは、パケットを破棄して、外部エレメントは、ＳＣＴＰ再送信メカニズムを介して、宛先ＩＰアドレスを変更して、パケットを再送信する。第２の状況では、リンク障害の管理がＮＡＴに割り当てられる。プライベートＩＰアドレスが到達可能でない場合、ＮＡＴは、同一の宛先エレメントのＩＰアドレスに望ましい別のＩＰアドレスに向けて、到達不可能な宛先にアドレスされている到来ＳＣＴＰパケットを転送する。

本明細書で提示されるソリューションは、プライベートネットワーク内のＳＣＴＰを利用可能なエレメント群の数に関してはスケーラブルであるので、ＮＡＴデバイスの下に存在することができるエレメントの数に制限はない。新規のエレメントが追加される場合、コンフィグレーションフェーズが、他のエレメントのコンフィグレーション、あるいは進行中のアソシエーションに影響を与えることなく実行される。

ピアツーピアＳＣＴＰ交換を容易にするように設計されているＮＡＴの実装は、適切な規格、この場合、ＩＥＴＦＲＦＣ２９６０に準拠しているべきである。ＩＮＩＴパケットとＩＮＩＴＡＣＫパケットが関与する限りは、準拠については、この議論での主要な焦点である。他のチャンクを含むパケットの場合では、ＲＦＣの要件は、本明細書で提案されるメカニズムでも満足されることが想定されている。特に、送信側の検証タグを含むが受信側の検証タグを含まないＡＢＯＲＴチャンクについて検討すると、ＮＡＴは、正しい受信先を認識することはしないので、そのメッセージを拒否する、あるいはそれを間違った受信先へ転送することになる。どちらの場合も、実効誤差、即ち、想定されている結果となる。本提案は、シャットダウン完了（ＳＨＵＴＤＯＷＮＣＯＭＰＬＥＴＥ）、クッキーエコー（ＣＯＯＫＩＥＥＣＨＯ）及びシャットダウン応答確認（ＳＨＵＴＤＯＷＮＡＣＫ）メッセージの要件にも準拠する。

本発明の範囲から逸脱することなく、上述の実施形態に様々な変形を行なうことができることが当業者には明らかであろう。例えば、上述のメカニズムは、ＮＡＴデバイスにおいてポート変換は必要しないが、ポート変換をＮＡＴで許容することができる。

Claims

電気通信システム内のプライベートネットワークを操作する方法であって、
前記プライベートネットワークは、ネットワークアドレス変換機能を介して、レイヤ４制御プロトコルを使用するピアエンティティ群とＩＰパケットを送受信するように構成されている複数のエンティティを備え、
前記レイヤ４制御プロトコルは、レイヤ４パケットチャンクに複数のＩＰアドレスを含めることをエンティティに許容することによってマルチホーミングを促進するものであり、
前記方法は、
前記複数のエンティティのそれぞれにおいて、前記エンティティの１つ以上のプライベートＩＰアドレスを前記ネットワークアドレス変換機能の１つ以上のパブリックＩＰアドレスにマッピングするテーブルを保持し、
エンティティによって生成されるアソシエーション開始メッセージそれぞれに対して、対応する前記プライベートＩＰアドレス（群）に対して、前記テーブルから取得される前記ネットワークアドレス変換機能の前記パブリックＩＰアドレス（群）を、前記アソシエーション開始メッセージの前記レイヤ４パケットチャンクに含める
を備えることを特徴とする方法。
前記レイヤ４制御プロトコルは、ストリーム制御送信プロトコルである
ことを特徴とする請求項１に記載の方法。
前記アソシエーション開始メッセージは、ＩＮＩＴチャンクあるいはＩＮＩＴＡＣＫチャンクを含むストリーム制御送信プロトコルである
ことを特徴とする請求項２に記載の方法。
前記複数のエンティティは、同一物理ノード内に含まれている
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
前記ネットワークアドレス変換機能を、前記ノード内のネットワークアドレス変換エンティティで実行する
ことを特徴とする請求項４に記載の方法。
前記ネットワークアドレス変換機能は、前記レイヤ４パケットを変更しない
ことを特徴とする請求項５に記載の方法。
前記複数のエンティティそれぞれに対する前記ネットワークアドレス変換エンティティにおいて、ネットワークアドレス変換バインディングテーブルを保持し、
前記ネットワークアドレス変換バインディングテーブルは、エンティティのプライベートＩＰアドレスの１つあるいはそれぞれを、前記ネットワークアドレス変換機能のパブリックＩＰアドレスとアソシエーション識別タグの範囲とにマッピングする
ことを特徴とする請求項５または６に記載の方法。
請求項２に従属する場合、前記アソシエーション識別タグは、検証タグである
ことを特徴とする請求項７に記載の方法。
前記ネットワークアドレス変換エンティティにおいての進行中のＩＰパケットそれぞれに対して、対応する前記ネットワークアドレス変換バインディングテーブルを使用して、前記ＩＰパケットのヘッダのソースアドレスフィールドに含まれる前記プライベートＩＰアドレスを、パブリックＩＰアドレスにマッピングし、かつ前記パブリックＩＰアドレスの代わりに前記プライベートＩＰアドレスを使用する
ことを特徴とする請求項７または８に記載の方法。
前記ネットワークアドレス変換エンティティにおいて到来するＩＰパケットに対して、対応する前記ネットワークアドレス変換バインディングテーブルを使用して、前記ＩＰパケットのヘッダの宛先フィールドに含まれる前記パブリックＩＰアドレスと前記レイヤ４パケットのヘッダに含まれるアソシエーション識別タグとを、プライベートＩＰアドレスへマッピングし、かつ前記プライベートＩＰアドレスの代わりに前記パブリックＩＰアドレスを使用する
ことを特徴とする請求項７乃至９のいずれか１項に記載の方法。
前記複数のエンティティそれぞれは、複数のプライベートＩＰアドレスに割り当てられ、
前記複数のプライベートＩＰアドレスは、前記ノードのローカルドメイン内で固有であり、
前記パブリックＩＰアドレス群は、プールとしてアドレス間で共有される
ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
電気通信ネットワークで使用するためのノードであって、
複数のコンピュータエンティティを備え、
前記複数のコンピュータエンティティはそれぞれ、レイヤ４パケットチャンクに複数のＩＰアドレスを含めることをエンティティに許容することによってマルチホーミングを促進するレイヤ４制御プロトコルを使用するように構成され、
前記複数のコンピュータエンティティはそれぞれ、前記コンピュータエンティティの１つ以上のプライベートＩＰアドレスを、ネットワークアドレス変換機能の１つ以上のパブリックＩＰアドレスにマッピングするテーブルを保持するためのメモリを備え、
前記複数のコンピュータエンティティはそれぞれ、エンティティによって生成されるアソシエーション開始メッセージそれぞれに対して、対応する前記プライベートＩＰアドレス（群）に対して、前記テーブルから取得される前記ネットワークアドレス変換機能の前記パブリックＩＰアドレス（群）を、前記アソシエーション開始メッセージの前記レイヤ４パケットチャンクに含めるように構成されている
ことを特徴とするノード。
ローカルＩＰネットワークを介して、前記複数のコンピュータエンティティのそれぞれに接続される、更なるコンピュータエンティティを更に備え、
前記更なるコンピュータエンティティは、前記ローカルＩＰネットワークと、前記パブリックＩＰアドレスが有効である更なるＩＰネットワーク間で前記ネットワークアドレス変換機能を実現するように構成されている
ことを特徴とする請求項１２に記載のノード。
電気通信システムのノードをコンフィグレーションする方法であって、
前記ノードは、ネットワークアドレス変換機能を介して、レイヤ４制御プロトコルを使用するピアエンティティ群とＩＰパケットを送受信するように構成されている複数のエンティティを備え、
前記レイヤ４制御プロトコルは、レイヤ４パケットチャンクに複数のＩＰアドレスを含めることをエンティティに許容することによってマルチホーミングを促進するものであり、
前記方法は、
前記複数のエンティティのそれぞれに対して、前記エンティティのプライベートＩＰアドレスとレイヤ４アソシエーション識別タグの範囲との間のマッピングを、前記エンティティからネットワークアドレス変換機能へ送信し、
前記ネットワークアドレス変換からの応答で、前記プライベートＩＰアドレスと、前記ネットワークアドレス変換機能のパブリックＩＰアドレス間のマッピングを受信し、
その受信したマッピングを次に使用するために記憶する
ことを特徴とする方法。
前記ネットワークアドレス変換機能は、前記ノード内で実現され、
更に、前記エンティティのプライベートＩＰアドレスとレイヤ４アソシエーション識別タグの範囲との間のマッピングの受信時に、前記プライベートＩＰアドレスと前記ネットワークアドレス変換機能のパブリックＩＰアドレス間のマッピングを構築し、かつ前記マッピングを対応するエンティティへ送信する
ことを特徴とする請求項１４に記載の方法。
ネットワークアドレス変換エンティティをコンフィグレーションする方法であって、
前記ネットワークアドレス変換エンティティは、複数のエンティティに代ってネットワークアドレス変換機能を実行する責任があり、
前記複数のエンティティは、ネットワークアドレス変換機能を介して、レイヤ４制御プロトコルを使用するピアエンティティ群とＩＰパケットを送受信するように構成されていて、
前記レイヤ４制御プロトコルは、レイヤ４パケットチャンクに複数のＩＰアドレスを含めることをエンティティに許容することによってマルチホーミングを促進するものであり、
前記方法は、
前記複数のエンティティそれぞれから、前記エンティティのプライベートＩＰアドレスとレイヤ４アソシエーション識別タグとの間のマッピングを受信し、それぞれのマッピングをパブリックＩＰアドレスへ割り当て、前記マッピングと前記パブリックＩＰアドレスとの割当とを記憶する
ことを特徴とする方法。
ネットワークアドレス変換エンティティを操作する方法であって、
前記ネットワークアドレス変換エンティティは、複数のエンティティに代ってネットワークアドレス変換機能を実行する責任があり、
前記複数のエンティティは、ネットワークアドレス変換機能を介して、レイヤ４制御プロトコルを使用するピアエンティティ群とＩＰパケットを送受信するように構成されていて、
前記レイヤ４制御プロトコルは、レイヤ４パケットチャンクに複数のＩＰアドレスを含めることをエンティティに許容することによってマルチホーミングを促進するものであり、
前記方法は、
到来するＩＰパケットを受信し、
前記ＩＰパケットヘッダに含まれる宛先ＩＰアドレスと、前記レイヤ４パケットのヘッダに含まれるアソシエーション識別タグとを識別し、
前記宛先ＩＰアドレスと、前記アソシエーション識別タグとをプライベートＩＰアドレスにマッピングし、
前記ＩＰパケットのヘッダに含まれる宛先ＩＰアドレスを前記プライベートＩＰアドレスに置換し、
前記ＩＰパケットを転送する
ことを特徴とする方法。