(57)【要約】【課題】管理者の少ない負担で、光網内のパス設定を自動的に効率よくなし得、ユーザ網における網構成の自由度を向上させる。【解決手段】複数のノード４１、４２によって構成される光網が複数のユーザ網を収容し、各ユーザ網が複数のノード３１，３２を持ち、ユーザ網内のノードの一部３１，３２が１〜複数のＵＮＩ２１、２２で光網に接続し、各ＵＮＩ２１，２２が光網側とユーザ網側とに異なるアドレスを持ち、ＵＮＩ２１、２２間を結ぶパスを光網内に設定してユーザ網のノード３１，３２間を接続するようにした光網システムにおいて、宛先ＵＮＩ２２のユーザ網側のアドレスに基づきパスの宛先ＵＮＩ２２の光網側のアドレスを求めるアドレス解決処理をユーザ網内のノードもしくは光網内のノードで実行させることを特徴とする。【選択図】      図２
2004266462.tif 000002
【特許請求の範囲】
【請求項１】
複数のノードによって構成される光網が複数のユーザ網を収容し、各ユーザ網が複数のノードを持ち、前記ユーザ網内のノードの一部が１〜複数のユーザネットワークインターフェース（以下ＵＮＩという）で光網に接続し、各ＵＮＩが光網側とユーザ網側とに異なるアドレスを持ち、ＵＮＩ間を結ぶパスを光網内に設定してユーザ網のノード間を接続するようにした光網システムにおいて、
宛先ＵＮＩのユーザ網側のアドレスに基づきパスの宛先ＵＮＩの光網側のアドレスを求めるアドレス解決処理をユーザ網内のノードで実行させることを特徴とする光網システムのアドレス解決方法。
【請求項２】
ユーザ網に接続されている各ＵＮＩについてのＵＮＩの光網側のアドレスとユーザ網側のアドレスとの対応を示すＵＮＩ情報を蓄積記憶するサーバをユーザ網に設け、前記アドレス解決処理を実行するユーザ網のノードは前記サーバに対してユーザ網側のアドレスを含むアドレス解決要求信号を送信することにより、送信したユーザ網側のアドレスに対応する光網側のアドレスを前記サーバから取得することを特徴とする請求項１に記載の光網システムのアドレス解決方法。
【請求項３】
ＵＮＩに接続されているユーザ網のノード間で、ユーザ網に接続されている各ＵＮＩについてのＵＮＩの光網側のアドレスとユーザ網側のアドレスとの対応を示すＵＮＩ情報を予め交換して保持することによって、ＵＮＩに接続されているユーザ網内のノードに前記ＵＮＩ情報を保持させ、前記アドレス解決処理を実行するユーザ網のノードは自身が保持しているＵＮＩ情報を用いてユーザ網側のアドレスに対応する光網側のアドレスを取得することを特徴とする請求項１に記載の光網システムのアドレス解決方法。
【請求項４】
ＵＮＩに接続されているユーザ網の各ノードに、自ノードが接続されているＵＮＩについてのＵＮＩの光網側のアドレスとユーザ網側のアドレスとの対応を示すＵＮＩ情報を保持させ、前記アドレス解決処理を実行するユーザ網のノードが、ＵＮＩに接続されているユーザ網の他のノードに対しユーザ網側のアドレスを含むアドレス解決要求信号を送信し、前記アドレス解決要求信号を受信しかつそのアドレス解決要求に対処できるノードが光網側のアドレスを含むアドレス解決応答信号を返送することにより、前記アドレス解決処理を実行するユーザ網のノードが送信したユーザ網側のアドレスに対応する光網側のアドレスを取得することを特徴とする請求項１に記載の光網システムのアドレス解決方法。
【請求項５】
前記アドレス解決要求信号を受信しかつそのアドレス解決要求に対応できないノードは、他のノードに前記アドレス解決要求信号を転送することを特徴とする請求項４に記載の光網システムのアドレス解決方法。
【請求項６】
前記アドレス解決処理を実行するユーザ網のノードは、ＵＮＩに接続されているユーザ網の全てのノードに対しユーザ網側のアドレスを含むアドレス解決要求信号を一斉に送信することにより、前記光網側のアドレスを取得することを特徴とする請求項４に記載の光網システムのアドレス解決方法。
【請求項７】
１〜複数のユーザ網が属するユーザグループを定義し、同一ユーザグループに属するユーザ網間でのみ前記アドレス解決処理を実行可能としたことを特徴とする請求項１〜６の何れか一つに記載の光網システムのアドレス解決方法。
【請求項８】
複数のノードによって構成される光網が複数のユーザ網を収容し、各ユーザ網は全ユーザ網間で一意のユーザ識別情報を持ち、各ユーザ網が複数のノードを持ち、前記ユーザ網内のノードの一部が１〜複数のユーザネットワークインターフェース（以下ＵＮＩという）で光網に接続し、各ＵＮＩが光網側とユーザ網側とに異なるアドレスを持ち、ＵＮＩ間を結ぶパスを光網内に設定してユーザ網のノード間を接続するようにした光網システムにおいて、
宛先ＵＮＩのユーザ網側のアドレス及びユーザ識別情報に基づきパスの宛先ＵＮＩの光網側のアドレスを求めるアドレス解決処理を光網内のノードで実行させることを特徴とする光網システムのアドレス解決方法。
【請求項９】
１〜複数のユーザ網が属するユーザグループを定義し、前記アドレス解決処理を実行する光網内のノードは、ユーザ網のユーザ識別情報をチェックすることによって同一ユーザグループ内のユーザ網間でのみ前記アドレス解決処理を実行可能としたことを特徴とする請求項８に記載の光網システムのアドレス解決方法。
【請求項１０】
光網に接続されている各ＵＮＩについてのＵＮＩの光網側のアドレスとユーザ網側のアドレスと当該ＵＮＩに接続されるユーザ網のユーザ識別情報との対応を示すＵＮＩ情報を蓄積記憶するサーバを光網に設け、前記アドレス解決処理を実行する光網のノードは前記サーバに対してユーザ網側のアドレスおよびユーザ網の識別情報を含むアドレス解決要求信号を送信することにより、送信したユーザ網側のアドレスに対応する光網側のアドレスを前記サーバから取得することを特徴とする請求項８または９に記載の光網システムのアドレス解決方法。
【請求項１１】
ＵＮＩに接続されている光網のノード間で、光網に接続されている各ＵＮＩについてのＵＮＩの光網側のアドレスとユーザ網側のアドレスと当該ＵＮＩに接続されるユーザ網のユーザ識別情報との対応を示すＵＮＩ情報を予め交換して保持することによって、ＵＮＩに接続されている光網内のノードに前記ＵＮＩ情報を保持させ、前記アドレス解決処理を実行する光網のノードは自身が保持しているＵＮＩ情報を用いてユーザ網側のアドレスに対応する光網側のアドレスを取得することを特徴とする請求項８または９に記載の光網システムのアドレス解決方法。
【請求項１２】
ＵＮＩに接続されている光網の各ノードに、自ノードが接続されているＵＮＩについてのＵＮＩの光網側のアドレスとユーザ網側のアドレスと当該ＵＮＩに接続されるユーザ網のユーザ識別情報との対応を示すＵＮＩ情報を保持させ、前記アドレス解決処理を実行する光網のノードが、ＵＮＩに接続されている光網の他のノードに対しユーザ網側のアドレスおよびユーザ網の識別情報を含むアドレス解決要求信号を送信し、前記アドレス解決要求信号を受信しかつそのアドレス解決要求に対処できるノードが光網側のアドレスを含むアドレス解決応答信号を返送することにより、前記アドレス解決処理を実行する光網のノードが送信したユーザ網側のアドレスに対応する光網側のアドレスを取得することを特徴とする請求項８または９に記載の光網システムのアドレス解決方法。
【請求項１３】
前記アドレス解決要求信号を受信しかつそのアドレス解決要求に対応できないノードは、他のノードに前記アドレス解決要求信号を転送することを特徴とする請求項１２に記載の光網システムのアドレス解決方法。
【請求項１４】
前記アドレス解決処理を実行するユーザ網のノードは、ＵＮＩに接続されている光網の全てのノードに対しユーザ網側のアドレスおよびユーザ網の識別情報を含むアドレス解決要求信号を一斉に送信することにより、前記光網側のアドレスを取得することを特徴とする請求項１２に記載の光網システムのアドレス解決方法。
【請求項１５】
光網は階層構造を用いて管理されるものであり、前記アドレス解決要求信号の送受信が、前記光網の階層構造に従って行われることを特徴とする請求項１２または１３に記載の光網システムのアドレス解決方法。
【請求項１６】
光網のノードは、そのノードの下位階層のノード、もしくは同階層のノード、もしくは上位階層のノードが所有する前記ＵＮＩ情報を所有し、そのノードが前記アドレス解決要求信号を受信した場合、所有するＵＮＩ情報を用いて下位階層のノード、もしくは同階層のノード、もしくは上位階層のノードについてのアドレス解決要求処理を代行することを特徴とする請求項１５に記載の光網システムのアドレス解決方法。
【請求項１７】
ノードが上位階層からアドレス解決要求信号を受信しかつそのノードではアドレス解決ができない場合は、そのノードは、下位階層の全てのノードにアドレス解決要求を送信し、下位階層の全てのノードからアドレス解決不可応答信号を受信したら同階層の全てのノードにアドレス解決要求信号を送信し、同階層の全てのノードからアドレス解決不可応答信号を受信したらアドレス解決不可応答信号を上位階層の前記アドレス解決要求信号の送信元に送信することを特徴とする請求項１５または１６に記載の光網システムのアドレス解決方法。
【請求項１８】
ノードが同位階層からアドレス解決要求信号を受信しかつそのノードではアドレス解決ができない場合は、そのノードは、下位階層の全てのノードにアドレス解決要求信号を送信し、下位階層の全てのノードからアドレス解決不可応答信号を受信したらアドレス解決不可応答信号を同階層の前記アドレス解決要求信号の送信元に送信することを特徴とする請求項１５〜１７の何れか一つに記載の光網システムのアドレス解決方法。
【請求項１９】
ノードが下位階層からアドレス解決要求信号を受信しかつそのノードではアドレス解決ができない場合は、そのノードは、同階層の全てのノードにアドレス解決要求を送信し、同階層の全てのノードからアドレス解決不可応答信号を受信してかつ上位階層が存在する場合には、上位階層にアドレス解決要求信号を送信し、上位階層が存在しないか上位階層からアドレス解決不可応答信号を受信した場合には、アドレス解決不可応答信号を下位階層の前記アドレス解決要求信号の送信元に送信することを特徴とする請求項１５〜１８の何れか一つに記載の光網システムのアドレス解決方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、光網システムのユーザ網インターフェース（ＵＮＩ：Ｕｓｅｒ  Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ）における光網側アドレスとユーザ網側アドレスとの間のアドレスを解決する光網システムのアドレス解決方法に関するものである。
【０００２】
【従来の技術】
ＧＭＰＬＳ（Ｇｅｎｅｒａｌｉｚｅｄ  Ｍｕｌｔｉ−Ｐｒｏｔｏｃｏｌ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｉｎｇ）は、光ネットワーク上に伝送経路を設けるための技術である。ＭＰＬＳ（Ｍｕｌｔｉ−Ｐｒｏｔｏｃｏｌ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｉｎｇ）では  ＨＹＰＥＲＬＩＮＫ  ”ｈｔｔｐ：／／ｎｔｔｃｏｍ．ｅ−ｗｏｒｄｓ．ｎｅ．ｊｐ／ｗ／Ｅ３８３９１Ｅ３８２Ｂ１Ｅ３８３８３Ｅ３８３８８．ｈｔｍｌ”  パケットにラベルを付加して伝送経路を指定していたが、ＧＭＰＬＳでは光信号の波長を元に伝送経路を決定したり、制御専用のＩＰチャネルを用意して実データは光信号のまま転送したりする。
【０００３】
標準化団体ＯＩＦ（Ｏｐｔｉｃａｌ  Ｉｎｔｅｒｎｅｔｗｏｒｋｉｎｇ  Ｆｏｒｕｍ）によるＧＭＰＬＳ網のモデルでは、光網を光コントロールプレーンと光データプレーンに分離し、光網を制御する為のプロトコルは光コントロールプレーン内で運用される。光網は、複数のユーザ網を収容し、各ユーザ網は単数もしくは複数のサイトから構成されている。全てのサイトは単一もしくは複数のＵＮＩを介して光網の光コントロールプレーン及び光データプレーンに接続されている。
【０００４】
ここで、ＯＩＦによるＧＭＰＬＳ網のモデルでは、光コントロールプレーンと、光コントロールプレーン１に接続する全てのユーザ網のアドレス空間を分離している。すなわち、光網とユーザ網とを接続している各ＵＮＩにおけるユーザ網側および光網側には、ノードが夫々接続され、ユーザ網側のノードは各ＵＮＩに対しそれぞれのユーザ網内で固有かつ一意のＩＰアドレスを割り当てており、また光網側のノードは、ＵＮＩの光データプレーンにそれぞれＴＮＡ（Ｔｒａｎｓｐｏｒｔ  Ｎｅｔｗｏｒｋ  Ａｓｓｉｇｎｅｄ）アドレスを割り当てている。ＴＮＡアドレスとはＵＮＩを光網内で一意に識別するものである。
【０００５】
ユーザ網側のユーザには、そのユーザ網が接続する全てのＵＮＩに割り当てられているＴＮＡアドレスが通知されている。したがって、ユーザが或る第１のＵＮＩから他の第２のＵＮＩへのパスを設定する場合には、従来は、パス設定要求と共に、該当パスの宛先となる第２のＵＮＩのＴＮＡアドレスを光コントロールプレーン内の第１のＵＮＩに接続する光網のノードに通知する。
【０００６】
ここで、該当パスの宛先となる第２のＵＮＩのＩＰアドレスから対応するＴＮＡアドレスを求める方法はＯＩＦの規定外となっている。
【０００７】
他方、ＯＩＦはＧＭＰＬＳ網での経路制御にＤＤＲＰ（Ｄｏｍａｉｎ  ｔｏ  Ｄｏｍａｉｎ  Ｒｏｕｔｉｎｇ  Ｐｒｏｔｏｃｏｌ）を規定している。ＤＤＲＰプロトコルでは、光網を階層化して制御する。
【０００８】
ＤＤＲＰでは、ある網の階層Ａ１は複数のノードによって構成される。この階層Ａ１は複数のノードのうちの１つのノードによって代表され、その代表ノード２４１もまたより上位の階層の構成ノードとなる。このとき、階層Ａ１に含まれる全てのＴＮＡアドレスは、代表ノードによって要約され、上位階層に伝達される。
【０００９】
しかし、ＯＩＦのＧＭＰＬＳ網では、上記代表ノードによるＴＮＡアドレスの要約の方法については何等議論されていない。
【００１０】
なお、特許文献１には、ＰＮＮＩ階層ネットワークのＰＡＲ対応デバイスのプロトコル情報を管理する方法が開示されているが、この特許文献１は、本発明に直接関連するものではない。
【００１１】
【特許文献１】
特開２００２−５１０８３号公報
【００１２】
【発明が解決しようとする課題】
上述したように、光網とユーザ網とでアドレス系が異なり、その境界にＵＮＩがある網において、光網側のアドレスとユーザ網におけるアドレスの解決を手動設定で行うようにした場合、オペレーションの工数がＵＮＩ数等に比例して増大し、ユーザ網管理者の負担が大きいという問題がある。
【００１３】
また、既存技術では、光網のアドレスをユーザ網側に公開しているため、ユーザ網管理者は新規のオペレーションを習得せねばならないという問題もある。
【００１４】
この発明は上記に鑑みてなされたもので、管理者の少ない負担で、光網内のパス設定を自動的に効率よくなし得る光網システムのアドレス解決方法を得ることを目的とする。また、この発明は、ユーザ網において、光網固有のオペレーションを不要とするサービスを可能とすることを目的とする。また、この発明は、ユーザ網における網構成の自由度を向上することが可能なサービスを可能とするものである。
【００１５】
【課題を解決するための手段】
上記目的を達成するため、この発明にかかる光網システムのアドレス解決方法は、複数のノードによって構成される光網が複数のユーザ網を収容し、各ユーザ網が複数のノードを持ち、前記ユーザ網内のノードの一部が１〜複数のＵＮＩで光網に接続し、各ＵＮＩが光網側とユーザ網側とに異なるアドレスを持ち、ＵＮＩ間を結ぶパスを光網内に設定してユーザ網のノード間を接続するようにした光網システムにおいて、宛先ＵＮＩのユーザ網側のアドレスに基づきパスの宛先ＵＮＩの光網側のアドレスを求めるアドレス解決処理をユーザ網内のノードで実行させることを特徴とする。
【００１６】
この発明によれば、ユーザ網内のノードは、ＵＮＩ間を結ぶパスを光網内に設定してユーザ網のノード間を接続する際、宛先ＵＮＩのユーザ網側のアドレスに基づきパスの宛先ＵＮＩの光網側のアドレスを求めるアドレス解決処理をユーザ網内のノードで実行するようにしており、ユーザ網における網構成の自由度を向上できる。また、ＵＮＩの光網側のアドレスが固定された場合、障害時の切り分けを容易にできる。
【００１７】
また、この発明にかかる光網システムのアドレス解決方法は、上記光網システムにおいて、宛先ＵＮＩのユーザ網側のアドレスに基づきパスの宛先ＵＮＩの光網側のアドレスを求めるアドレス解決処理を光網内のノードで実行させることを特徴とする。
【００１８】
この発明によれば、ユーザ網内のノードは、ＵＮＩ間を結ぶパスを光網内に設定してユーザ網のノード間を接続する際、宛先ＵＮＩのユーザ網側のアドレスに基づきパスの宛先ＵＮＩの光網側のアドレスを求めるアドレス解決処理を光網内のノードで実行するようにしており、これにより管理者の少ない負担で、光網内のパス設定を自動的に効率よくなし得る。
【００１９】
【発明の実施の形態】
以下に添付図面を参照して、この発明にかかる光網システムのアドレス解決方法の好適な実施の形態を詳細に説明する。
【００２０】
図１に、ＧＭＰＬＳに基づく光網の網構成及びユーザ網との接続形態の例を示す。ＧＭＰＬＳ網のモデルでは、前述したように、光網を光コントロールプレーン１と光データプレーン２に分離し、光網を制御する為のプロトコルは光コントロールプレーン１内で運用される。また、ＯＩＦによるＧＭＰＬＳ網のモデルでは、光コントロールプレーン１と、光コントロールプレーン１に接続する全てのユーザ網３〜４のアドレス空間を分離している。
【００２１】
光コントロールプレーン１および光データプレーン２を含む光網は、複数のユーザ網３〜４を収容し、あるユーザ網４は単数もしくは複数のサイト１１〜１２から構成されているとする。各サイト１１〜１２は、複数のノードを有し、単一もしくは複数のＵＮＩ２１〜２３で光コントロールプレーン１及び光データプレーン２に接続されている。すなわち、光網とユーザ網との境界にＵＮＩ２１〜２３が配置されており、光網およびユーザ網の一部のノードがＵＮＩに接続されている。
【００２２】
また、この光網システムは複数のユーザグループを持ち、複数のユーザが同一ユーザグループに属している。そして、同一ユーザグループに属さないユーザ（ユーザ網）間のＵＮＩを接続しないサービスを提供するものとする。
【００２３】
図２に、図１で示した光コントロールプレーン１と単一のユーザ網の接続例を示す。
【００２４】
光網とユーザ網との境界にある全てのＵＮＩ２１〜２２のユーザ網側には、ノード３１〜３２が接続され、ノード３１〜３２はＵＮＩ２１〜２２に対しそれぞれ固有かつユーザ網内で一意のＩＰアドレス５１〜５２を割り当てている。一方、全てのＵＮＩ２１〜２２の光コントロールプレーン１側には、ノード４１〜４２が接続され、これらのノード４１〜４２は、ＵＮＩ２１〜２２の光データプレーンに対しそれぞれ光コントロールプレーン１内で一意のＴＮＡアドレス６１〜６２を割り当てている。
【００２５】
ユーザ網のユーザには、そのユーザ網が接続されている全てのＵＮＩ２１〜２２に割り当てられているＴＮＡアドレス６１〜６２が通知されている。ユーザがＵＮＩ２１からＵＮＩ２２へのあるパス７１を設定する場合には、パス設定要求と共に、該当パス７１の宛先となるＵＮＩ２２のＴＮＡアドレス６２を光コントロールプレーン内のＵＮＩ２１に接続しているノード４１に通知する。
【００２６】
本発明では、ユーザ網のユーザが光網に対してＵＮＩ２１からＵＮＩ２２などへの光パス７１の設定を要求するときに、宛先側のＵＮＩ２２をユーザ側のＩＰアドレス５２をもって指定する事を可能としている。なお、光網とは、例えばキャリア網であり、またユーザ網とは、ＩＳＰ（Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）網や企業網などのことである。
【００２７】
図２の網構成を例にとって、アドレス解決をユーザ網内で行う場合と、光コントロールプレーン１内で行う場合のそれぞれについて、そのパス設定手順を説明する。
【００２８】
（１）ユーザ網内でアドレス解決を行う場合
例えば、ＵＮＩ２１に接続されているユーザ網内のノード３１が、ＩＰアドレス５２に到るパス７１を設定するとする。このＩＰアドレス５２はＵＮＩ２２に対応する。
【００２９】
ノード３１は、後述する何れかのアドレス解決方法を用いて、ＵＮＩ情報を取得する。すなわち、この場合、ＵＮＩ情報とは、宛先ＩＰアドレス５２と、これに対応するＴＮＡアドレス６２との対応関係を示す情報のことであり、ノード３１は、取得したＵＮＩ情報を用いて、宛先ＩＰアドレス５２が示すＵＮＩ２２に対応するＴＮＡアドレス６２を得る。
【００３０】
ただし、前述したように、同一ユーザグループに属さない、異なるユーザグループに属するユーザ（ユーザ網）間のＵＮＩを接続しないようにしているので、ユーザ網内のノード３１は、同一ユーザグループに属さないユーザ網のＵＮＩ情報を取得することはできない。
【００３１】
つぎに、ノード３１は、ＵＮＩ２１を挟んで対向する光コントロールプレーン１内のノード４１に対して宛先ＴＮＡアドレス６２までのパス設定要求を渡す。このパス設定要求を受け取ったノード４１は、ＴＮＡアドレス６２に接続するノード４２までパス７１を設定する。
【００３２】
なお、パス７１の設定後、光コントロールプレーン１内のノード４１，４２はそれぞれＵＮＩ２１，２２を挟んで対向するユーザ網内のノード３１，３２に対してパス設定完了通知を渡してもよい。
【００３３】
このように、ユーザ網内でアドレス解決を行う場合は、後述するアドレス解決方法において用いられるＵＮＩ情報とは、宛先ＩＰアドレスと、これに対応するＴＮＡアドレス６２との対応関係を示す情報のことを云う。また、ユーザ網内でアドレス解決を行う場合は、ユーザ網内の各ノード３１〜３２は、同一ユーザグループに属さないユーザ網のＵＮＩ情報を取得することはできない。さらに、後述する何れかのアドレス解決方法を用いてアドレス解決を行うときに、ノードは所要のサーバまたは他のノードなどにアドレス解決要求信号を送信するが、ユーザ網内でアドレス解決を行う場合には、アドレス解決要求信号には、宛先ＵＮＩのＩＰアドレスが含まれる。また、この際、所要のサーバまたは他のノードなどから返送されるアドレス解決応答信号には、ＴＮＡアドレス６２が含まれる。
【００３４】
ユーザ網内でアドレス解決を行う場合において、アドレス解決が可能であるとは、あるアドレス解決要求を受け取ったノード（例えば３２）において、そのノード３２が所持する全てのＵＮＩ情報の中に、アドレス解決要求に含まれているＩＰアドレス５２と等しいＩＰアドレスを持つＵＮＩ情報を保持している場合のことを指す。
【００３５】
このように、ユーザ網内でアドレス解決を行う場合は、光コントロールプレーン１内の全てのノード４１〜４２はユーザ網内の全てのＩＰアドレス５１〜５２を知る必要はなく、光コントロールプレーン１のオペレーションは容易であるが、ＴＮＡアドレス６１〜６２をユーザ網側に公開せねばならない。すなわち、ＴＮＡアドレス６１〜６２を固定する事で、ユーザ網と光網との間でアドレス情報の交換を行う必要がなくなり、障害時の問題の切り分けが容易になる。この反面、ユーザ網はそのユーザ網が所有する全てのＵＮＩ２１〜２２に対応するＴＮＡアドレス６１〜６２を扱わねばならず、また、アドレス解決に関するコストを負担する必要がある。
【００３６】
（２）光コントロールプレーン１内でアドレス解決を行う場合
この場合は、光コントロールプレーン１は、光コントロールプレーン１内で全てのユーザ網３〜４に一意のユーザＩＤ（ユーザ識別情報）を夫々割り当てる。この各ユーザ網のユーザＩＤは、各ユーザ網が同一ユーザグループに属するか否かを判別するために用いられ、異なるユーザグループに属するユーザ（ユーザ網）間のＵＮＩ間にパスは設定されない。
【００３７】
図２において、例えば、ＵＮＩ２１に接続されているユーザ網内のノード３１が、ＩＰアドレス５２に到るパス７１を設定するとする。このＩＰアドレス５２はＵＮＩ２２に対応している。
【００３８】
ノード３１は、ＵＮＩ２１を挟んで対向する光網内のノード４１に対して宛先ＩＰアドレス５２までのパス設定要求を渡す。このパス設定要求には、宛先ＩＰアドレスと、ノード３１が属するユーザ網のユーザＩＤが含まれている。
【００３９】
ノード４１は、後述する何れかのアドレス解決方法を用いて、ＵＮＩ情報を取得する。すなわち、この場合、ＵＮＩ情報とは、宛先ＩＰアドレス（この場合は５２）と、宛先ＩＰアドレスの属するユーザ網のユーザＩＤと、宛先ＵＮＩに対応するＴＮＡアドレスとの対応関係を示す情報のことであり、ノード４１は取得したＵＮＩ情報を用いて、パス設定要求に含まれる宛先ＩＰアドレスと等しいＩＰアドレスに対応するＴＮＡアドレス６２を得る。ただし、このＴＮＡアドレス６２は、パス設定要求を送信してきたノード３１が属するユーザ網のユーザＩＤと、ＵＮＩ情報に含まれる宛先ＩＰアドレスの属するユーザ網のユーザＩＤとが同一ユーザグループに属するものであるか否かがチェックされ、同一ユーザグループに属する場合にのみ有効な情報となる。すなわち、異なるユーザグループに属するユーザ網のユーザＩＤを持つＵＮＩ情報からは、ＴＮＡアドレスを取得しない。このような制御によって、異なるユーザグループに属するユーザ（ユーザ網）間のＵＮＩ間にパスを設定しないようにしている。
【００４０】
このようにして、ＵＮＩ２２のＴＮＡアドレス６２を得た光網内のノード４１は、ＴＮＡアドレス６２のＵＮＩ２２に接続されているノード４２までパス７１を設定する。
【００４１】
なお、パス７１の設定後、光コントロールプレーン１内のノード４１，４２はそれぞれＵＮＩ２１，２２を挟んで対向するユーザ網内のノード３１，３２に対してパス設定完了通知を渡してもよい。
【００４２】
このように、光コントロールプレーン１内でアドレス解決を行う場合は、後述するアドレス解決方法において用いられるＵＮＩ情報とは、宛先ＩＰアドレスの属するユーザ網のユーザＩＤと、宛先ＩＰアドレスと、ＵＮＩに割り当てられたＴＮＡアドレスとの対応関係を云うことになる。
【００４３】
また、後述する何れかのアドレス解決方法を用いてアドレス解決を行うときに、ノードは所要のサーバまたは他のノードなどにアドレス解決要求信号を送信するが、光コントロールプレーン１内でアドレス解決を行う場合には、アドレス解決要求信号には、パス設定要求を生成したノード３１を含むユーザ網のユーザＩＤと、宛先ＵＮＩのＩＰアドレスが含まれる。また、この際、所要のサーバまたは他のノードなどから返送されるアドレス解決応答信号には、ＴＮＡアドレス６２が含まれる。
【００４４】
したがって、光コントロールプレーン１内でアドレス解決を行う場合において、アドレス解決が可能であるとは、例えば、アドレス解決要求を受け取ったノード（例えば４２）において、そのノード４２が所持する全てのＵＮＩ情報の中に、アドレス解決要求に含まれているユーザ網のユーザＩＤと同一ユーザグループに属するユーザＩＤを持ち、かつ、アドレス解決要求に含まれているＩＰアドレス５２と等しいＩＰアドレスを持つＵＮＩ情報を保持している場合のことを指す。
【００４５】
このように光コントロールプレーン１内でアドレス解決を行う場合は、ユーザ網は光網内の一切のオペレーションに関知することはないが、ユーザ網側が接続されている全てのＵＮＩ２１〜２２に対応する網のＩＰアドレス５１〜５２を光網側に公開しなくてはいけない。また、ＩＰアドレス５１〜５２がユーザ網内で一意でなければならない為、ユーザ網におけるＩＰアドレス配分の自由度が低い。一方で、光網はユーザのユーザＩＤ及びＩＰアドレス５１〜５２を扱う必要がある。
【００４６】
つぎに、前述のアドレス解決についての各種手法について詳細に述べる。
【００４７】
（ａ）サーバ・クライアント方式を使用する方法。
網内に全てのＵＮＩについての前記ＵＮＩ情報が蓄積されたルートサーバを設ける。即ち、ユーザ網内でアドレス解決を行う場合は、ユーザ網内にユーザ網内の全てのＵＮＩについてのＵＮＩ情報を有するルートサーバを設け、光コントロールプレーン１内でアドレス解決を行う場合は、光網内に光網内の全てのＵＮＩについてのＵＮＩ情報を有するルートサーバを設ける。ＵＮＩの追加や削除があった場合には、ルートサーバに対してＵＮＩ情報の登録及び削除を行う。
【００４８】
アドレス解決が必要なノードは、ルートサーバに対し、アドレス解決要求信号を送付する。前述したように、ユーザ網内でアドレス解決を行う場合は、アドレス解決要求信号には、宛先ＵＮＩのＩＰアドレスが含まれ、また光コントロールプレーン１内でアドレス解決を行う場合は、アドレス解決要求信号には、パス設定要求を生成したノードを含むユーザ網のユーザＩＤと、宛先ＵＮＩのＩＰアドレスが含まれる。アドレス解決要求信号を受信したルートサーバは、その要求に対応するＴＮＡアドレスを含むアドレス解決応答信号を返信する。
【００４９】
なお、ＵＮＩ情報を蓄積するサーバは分散データベース化するようにしてもよい。その場合はＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）の仕組みが近い。ＤＮＳはＩＥＴＦ（Ｔｈｅ  Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）によりＲＦＣ（Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ）１０３４及びＲＦＣ１０３５に定義されている。ＤＮＳの仕組みは、基本的には、データベースを所有するサーバを設置し、クライアントはサーバに対しアドレス解決を要求し、サーバはデータベースを参照した結果を応答するというものである。
【００５０】
このようにサーバ・クライアント方式を使用した場合は、運用が容易、通信量や計算量が少ない、誤設定の影響が少ない、適用できる網規模が大きいという効果がある。その反面、障害に対しては脆弱である。
【００５１】
（ｂ）ルーティングプロトコルを使用する方法。
この手法では、網内のＵＮＩに接続されている各ノードは、お互いに、そのノードが所有する全てのＵＮＩ情報を交換する。即ち、ユーザ網内でアドレス解決を行う場合は、ユーザ網内のＵＮＩに接続されている各ノード間でＵＮＩ情報（宛先ＩＰアドレスとＴＮＡアドレスとの対応関係を示す情報）を交換し、光コントロールプレーン１内でアドレス解決を行う場合は、光網内のＵＮＩに接続されている各ノード間でＵＮＩ情報（宛先ＩＰアドレスと、宛先ＩＰアドレスの属するユーザ網のユーザＩＤと、ＴＮＡアドレスとの対応関係を示す情報）を交換する。また、ＵＮＩの追加や削除があった場合には、任意のノードに対してＵＮＩ情報の登録や削除を行う。すなわち、この方式では、アドレス解決が必要なノードは、網トポロジ情報交換によって、あらかじめ宛先のＵＮＩ情報を知っている事になる。
【００５２】
この情報交換のメカニズムにはＯＳＰＦ（Ｏｐｅｎ  Ｓｈｏｒｔｅｓｔ  Ｐａｔｈ  Ｆｉｒｓｔ）やＢＧＰ（Ｂｏｒｄｅｒ  Ｇａｔｅｗａｙ  Ｐｒｏｔｏｃｏｌ）等の既存のルーティングプロトコルを使用することができる。ＯＳＰＦはＲＦＣ２３２８、ＢＧＰ４はＲＦＣ１７７１に定義されている。これらルーティングプロトコルの基本的な仕組みは、プロトコルに参加するノード間でそれぞれのノードが所有する情報を交換し、全てのノードが所有する情報を同期する、というものである。なお、これらの既存のルーティングプロトコルを使用する場合は、仕様にはＵＮＩ情報を扱う為の拡張が必要である。ＢＧＰの場合にはＲＦＣ２８５８で規定されているｍｕｌｔｉ  ｐｒｏｔｏｃｏｌ拡張を、ＯＳＰＦの場合にはＲＦＣ２３７０で規定されているｏｐａｑｕｅ  ＬＳＡ  ｏｐｔｉｏｎを用いればＵＮＩ情報を扱うための拡張は可能である。
【００５３】
このようにルーティングプロトコル方式を使用する場合は、アドレス解決が早い、耐障害性が高いなどの効果がある反面、運用コストが大きく通信量や計算量や誤設定の影響が大きい、大き過ぎる網には適用できないなどの問題点がある。
【００５４】
（ｃ）アドレス解決プロトコルを使用する方法。
このアドレス解決プロトコルを使用する手法では、網内のＵＮＩに接続されている各ノードは、自分が接続されているＵＮＩの情報を保持している。そして、アドレス解決が必要なノードは、網内のＵＮＩに接続されている各ノードに対し、アドレス解決要求信号を送信する。即ち、ユーザ網内でアドレス解決を行う場合は、アドレス解決が必要なユーザ網内のノードはユーザ網内のＵＮＩに接続されている各ノードに、宛先ＵＮＩのＩＰアドレスを含むアドレス解決要求信号を送信し、光コントロールプレーン１内でアドレス解決を行う場合は、アドレス解決が必要な光網内のノードは光網内のＵＮＩに接続されている各ノードに、パス設定要求を生成したノードを含むユーザ網のユーザＩＤおよび宛先ＵＮＩのＩＰアドレスを含むアドレス解決要求信号を送信する。アドレス解決要求信号を受信し、かつアドレス解決要求に対応するＵＮＩに接続しているノードは、その要求に対応するＴＮＡアドレスを含むアドレス解決応答信号を返信する。
【００５５】
このアドレス解決のメカニズムにはＲＦＣ８２６に定義されているＡＲＰ（Ａｄｄｒｅｓｓ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）等の既存のアドレス解決プロトコルと同様の仕組みを使用することができる。アドレス解決プロトコルの基本的な仕組みは、アドレス解決が必要なノードが、プロトコルに参加するノード全てに対してアドレス解決要求を送信し、アドレスを解決できるノードが応答を返すというものである。なお、ＡＲＰ等の既存のアドレス解決プロトコルを使用する場合は、データリンク層のアドレスの代わりにＴＮＡアドレスを返す為の拡張が必要である。
【００５６】
このようにアドレス解決プロトコルを使用する場合は、運用が容易で、計算量が小さい、耐障害性が高い、誤設定の影響が小さいなどの効果がある反面、ブロードキャストを用いる為通信量が大きく、大き過ぎる網には適用できないなどの問題点がある。
【００５７】
（ｄ）Ｐ２Ｐ（ピアツーピア）プロトコルを使用する方法。
このピアツーピアプロトコルを使用する手法では、網内のＵＮＩに接続されている各ノードは、自分が接続するＵＮＩ、及び知る機会があったＵＮＩの情報を保持している。ＵＮＩ情報は、ＵＮＩ情報を保持している事が負担になれば削除する。但し、自分が接続されているＵＮＩのＵＮＩ情報についての削除は禁止する。これにより多くのパスの宛先となるＵＮＩのＵＮＩ情報は各ノードに拡散する。
【００５８】
また、近隣ノードグループを定義し、アドレス解決要求信号は近隣ノードグループに属するノードに対して送信するようにする。前述したように、ユーザ網内でアドレス解決を行う場合は、ユーザ網内で近隣ノードグループを定義し、ユーザ網内のノードは近隣ノードグループのノードに、宛先ＵＮＩのＩＰアドレスを含むアドレス解決要求信号を送信する。また、光コントロールプレーン１内でアドレス解決を行う場合は、光網内で近隣ノードグループを定義し、光網内のノードは近隣ノードグループのノードに、パス設定要求を生成したノードを含むユーザ網のユーザＩＤおよび宛先ＵＮＩのＩＰアドレスを含むアドレス解決要求信号を送信する。アドレス解決要求信号を受信したノードは、アドレス解決が可能ならば要求に対応するＴＮＡアドレスを含むアドレス解決応答信号をアドレス解決要求を発生させたノードに送信する。アドレス解決が不可能ならば、他の近隣ノードグループの任意のノードに対し、アドレス解決要求を転送する。
【００５９】
アドレス解決要求を発生もしくは転送した後、あるノードにおいてアドレス解決要求が解決される頻度が高いならば、アドレス解決要求を発生もしくは転送したノードは、アドレス解決要求を解決する頻度が高いノードを近隣ノードグループに追加し、その後このノードに優先的にアドレス解決要求を転送するようにする。また、アドレス解決要求を解決する頻度が低いノードは、近隣ノードグループから削除する。これにより網構成が最適化されていき、アドレス解決までの時間を短縮化することができる。なお、Ｐ２Ｐプロトコルをアドレス解決に用いる場合は、仕様の新規策定が必要である。
【００６０】
このようにピアツーピアプロトコルを使用する手法では、ルーティングプロトコルよりは通信量や計算量が小さい、耐障害性が高い、大規模な網に適用が可能などの効果がある反面、運用が難しく、必ず解が見つかる保証はなく、アドレス解決までに時間がかかるなどの問題もある。
【００６１】
実施の形態１．
実施の形態１においては、ユーザ網内でアドレス解決を行い、アドレス解決方法にはサーバ・クライアント方式のデータベース技術を用いるようにする。
【００６２】
例えば、図２において、ＵＮＩ２１に接続されているユーザ網内のノード３１が、ＩＰアドレス５２に到るパス７１を設定するとする。このＩＰアドレス５２はＵＮＩ２２に対応する。
【００６３】
ノード３１は、ユーザ網内のＵＮＩ情報が蓄積されたルートサーバに対し、宛先ＵＮＩ２２のＩＰアドレス５２を付加したアドレス解決要求信号を送付する。アドレス解決要求信号を受信したルートサーバは、蓄積されたＵＮＩ情報から宛先ＵＮＩ２２のＩＰアドレス５２に対応するＴＮＡアドレスを取り出し、取り出したＴＮＡアドレスを含むアドレス解決応答信号をノード３１に返信する。このようにして、ノード３１は、宛先ＩＰアドレス５２が示すＵＮＩ２２に対応するＴＮＡアドレス６２を得る。なお、ルートサーバには、同一ユーザグループに属さないユーザ網のＵＮＩ情報は所持しないようにしており、これにより異なるユーザグループ間でパスは設定されない。
【００６４】
つぎに、ノード３１は、ＵＮＩ２１を挟んで対向する光コントロールプレーン１内のノード４１に対して、宛先ＴＮＡアドレス６２を含む宛先ＴＮＡアドレス６２までのパス設定要求を渡す。パス設定要求を受け取ったノード４１は、ＴＮＡアドレス６２に接続するノード４２までパス７１を設定する。なお前述したように、パス７１の設定後、光コントロールプレーン１内のノード４１，４２はそれぞれＵＮＩ２１，２２を挟んで対向するユーザ網内のノード３１，３２に対してパス設定完了通知を渡してもよい。
【００６５】
この実施の形態１においては、アドレス解決方法をユーザ網側で運用しているので、ユーザ網における網構成の自由度を向上できる。また、ＴＮＡアドレスが固定された場合、障害時の切り分けを容易にできる。また、ユーザ網内にルートサーバを設け、アドレス解決にはサーバ・クライアント方式を用いるようにしているので、運用が容易で、通信量や計算量が少なく、誤設定の影響が少なく、適用できる網規模が大きくなる。
【００６６】
実施の形態２．
実施の形態２においては、ユーザ網内でアドレス解決を行い、アドレス解決方法にはルーティングプロトコルを用いるようにする。
【００６７】
例えば、図２において、ＵＮＩ２１に接続されているユーザ網内のノード３１が、ＩＰアドレス５２に到るパス７１を設定するとする。このＩＰアドレス５２はＵＮＩ２２に対応する。
【００６８】
ノード３１は、ユーザ網内のノード間のＵＮＩ情報を交換によって、あらかじめ宛先のＵＮＩ情報を知っており、ＵＮＩ情報を蓄積記憶している。また、前述したように、ユーザ網内の各ノードは、同一ユーザグループに属さないユーザ網のＵＮＩ情報は所持しないようにしているので、異なるユーザグループ間でパスは設定されない。そして、ノード３１は、この蓄積しているＵＮＩ情報を用いて、宛先ＩＰアドレス５２が示すＵＮＩ２２に対応するＴＮＡアドレス６２を得る。
【００６９】
つぎに、ノード３１は、ＵＮＩ２１を挟んで対向する光コントロールプレーン１内のノード４１に対して、宛先ＴＮＡアドレス６２を含む宛先ＴＮＡアドレス６２までのパス設定要求を渡す。パス設定要求を受け取ったノード４１は、ＴＮＡアドレス６２に接続するノード４２までパス７１を設定する。前述したように、パス７１の設定後、光コントロールプレーン１内のノード４１，４２はそれぞれＵＮＩ２１，２２を挟んで対向するユーザ網内のノード３１，３２に対してパス設定完了通知を渡してもよい。
【００７０】
この実施の形態２においては、アドレス解決方法をユーザ網側で運用しているので、ユーザ網における網構成の自由度を向上できる。また、ＴＮＡアドレスが固定された場合、障害時の切り分けを容易にできる。また、ユーザ網内でルーティングプロトコルを運用してアドレス解決を行っているので、応答の即時性が高く、耐障害性が高いアドレス解決をなし得る。
【００７１】
実施の形態３．
実施の形態３においては、ユーザ網内でアドレス解決を行い、アドレス解決方法にはアドレス解決プロトコルを用いるようにする。
【００７２】
例えば、図２において、ＵＮＩ２１に接続されているユーザ網内のノード３１が、ＩＰアドレス５２に到るパス７１を設定するとする。このＩＰアドレス５２はＵＮＩ２２に対応する。
【００７３】
ノード３１は、ユーザ網内のＵＮＩに接続されている各ノードに、宛先ＵＮＩのＩＰアドレスを含むアドレス解決要求信号を送信する。アドレス解決要求信号を受信し、かつアドレス解決要求に対応するＵＮＩに接続しているノードは、その要求に対応するＴＮＡアドレスを含むアドレス解決応答信号をノード３１に返信する。このようにして、ノード３１は、宛先ＩＰアドレス５２が示すＵＮＩ２２に対応するＴＮＡアドレス６２を得る。ユーザ網内の各ノードは、同一ユーザグループに属さないユーザ網のＵＮＩ情報は所持しないようにしているので、異なるユーザグループ間でパスは設定されない。
【００７４】
つぎに、ノード３１は、ＵＮＩ２１を挟んで対向する光コントロールプレーン１内のノード４１に対して、宛先ＴＮＡアドレス６２を含む宛先ＴＮＡアドレス６２までのパス設定要求を渡す。パス設定要求を受け取ったノード４１は、ＴＮＡアドレス６２に接続するノード４２までパス７１を設定する。前述したように、パス７１の設定後、光コントロールプレーン１内のノード４１，４２はそれぞれＵＮＩ２１，２２を挟んで対向するユーザ網内のノード３１，３２に対してパス設定完了通知を渡してもよい。
【００７５】
この実施の形態３においては、アドレス解決方法をユーザ網側で運用しているので、ユーザ網における網構成の自由度を向上できる。また、ＴＮＡアドレスが固定された場合、障害時の切り分けを容易にできる。また、ユーザ網内でアドレス解決プロトコルを運用することによりアドレス解決を行っているので、運用が容易で、計算量が小さく、耐障害性が高く、誤設定の影響が小さいアドレス解決をなし得る。
【００７６】
実施の形態４．
実施の形態４においては、ユーザ網内でアドレス解決を行い、アドレス解決方法にはＰ２Ｐプロトコルによる網トポロジ情報交換を用いるようにする。
【００７７】
例えば、図２において、ＵＮＩ２１に接続されているユーザ網内のノード３１が、ＩＰアドレス５２に到るパス７１を設定するとする。このＩＰアドレス５２はＵＮＩ２２に対応する。
【００７８】
ノード３１は、近隣ノードグループのノードに、宛先ＵＮＩのＩＰアドレスを含むアドレス解決要求信号を送信する。アドレス解決要求信号を受信したノードは、アドレス解決が可能ならば要求に対応するＴＮＡアドレスを含むアドレス解決応答信号をアドレス解決要求を発生させたノード３１に送信する。アドレス解決が不可能ならば、他の近隣ノードグループの任意のノードに対し、アドレス解決要求を転送する。このようにして、ノード３１は、宛先ＩＰアドレス５２が示すＵＮＩ２２に対応するＴＮＡアドレス６２を得る。ユーザ網内の各ノードは、同一ユーザグループに属さないユーザ網のＵＮＩ情報は所持しないようにしているので、異なるユーザグループ間でパスは設定されない。
【００７９】
つぎに、ノード３１は、ＵＮＩ２１を挟んで対向する光コントロールプレーン１内のノード４１に対して、宛先ＴＮＡアドレス６２を含む宛先ＴＮＡアドレス６２までのパス設定要求を渡す。パス設定要求を受け取ったノード４１は、ＴＮＡアドレス６２に接続するノード４２までパス７１を設定する。前述したように、パス７１の設定後、光コントロールプレーン１内のノード４１，４２はそれぞれＵＮＩ２１，２２を挟んで対向するユーザ網内のノード３１，３２に対してパス設定完了通知を渡してもよい。
【００８０】
この実施の形態４においては、アドレス解決方法をユーザ網側で運用しているので、ユーザ網における網構成の自由度を向上できる。また、ＴＮＡアドレスが固定された場合、障害時の切り分けを容易にできる。また、ユーザ網内でＰ２Ｐプロトコルを運用することによりアドレス解決を行っているので、耐障害性が高く、大規模な網に適用が可能なアドレス解決をなし得る。
【００８１】
実施の形態５．
実施の形態５においては、光網内でアドレス解決を行い、アドレス解決方法にはサーバ・クライアント方式のデータベース技術を用いるようにする。
【００８２】
図２において、例えば、ＵＮＩ２１に接続されているユーザ網内のノード３１が、ＩＰアドレス５２に到るパス７１を設定するとする。このＩＰアドレス５２はＵＮＩ２２に対応している。ノード３１は、ＵＮＩ２１を挟んで対向する光網内のノード４１に対して宛先ＩＰアドレス５２までのパス設定要求を渡す。このパス設定要求には、宛先ＩＰアドレスと、ノード３１が属するユーザ網のユーザＩＤが含まれている。
【００８３】
このパス設定要求を受信したノード４１は、ＵＮＩ情報が蓄積された光網内のルートサーバに対し、宛先ＵＮＩ２２のＩＰアドレス５２およびパス設定要求を送信してきたノード３１が属するユーザ網のユーザＩＤを付加したアドレス解決要求信号を送付する。
【００８４】
アドレス解決要求信号を受信したルートサーバは、蓄積されたＵＮＩ情報からアドレス解決要求に含まれているユーザ網のユーザＩＤと同一ユーザグループに属するユーザＩＤを持ち、かつ、アドレス解決要求に含まれているＩＰアドレス５２と等しいＩＰアドレスを持つＵＮＩ情報を取り出し、この取り出したＵＮＩ情報に含まれるＴＮＡアドレスを取得し、取得したＴＮＡアドレスを含むアドレス解決応答信号をノード４１に返信する。このようにして、ノード４１は、宛先ＩＰアドレス５２が示すＵＮＩ２２に対応するＴＮＡアドレス６２を得る。ただし、このＴＮＡアドレス６２は、パス設定要求を送信してきたノード３１が属するユーザ網のユーザＩＤと、ＵＮＩ情報に含まれる宛先ＩＰアドレスの属するユーザ網のユーザＩＤとが同一ユーザグループに属するＵＮＩ情報から得られるものである。このような制御によって、異なるユーザグループに属するユーザ（ユーザ網）間のＵＮＩ間にパスを設定しないようにしている。
【００８５】
つぎに、光網内のノード４１は、ＴＮＡアドレス６２のＵＮＩ２２に接続されているノード４２までパス７１を設定する。なお、パス７１の設定後、光コントロールプレーン１内のノード４１，４２はそれぞれＵＮＩ２１，２２を挟んで対向するユーザ網内のノード３１，３２に対してパス設定完了通知を渡してもよい。
【００８６】
この実施の形態５においては、アドレス解決を光網側で運用しているので、ユーザ網から光網固有の情報やオペレーションを隠蔽することができる。また、光網内にルートサーバを設け、アドレス解決にはサーバ・クライアント方式を用いるようにしているので、運用が容易で、通信量や計算量が少なく、誤設定の影響が少なく、適用できる網規模が大きくなる。
【００８７】
実施の形態６．
実施の形態６においては、光網内でアドレス解決を行い、アドレス解決方法にはルーティングプロトコルを用いるようにする。
【００８８】
図２において、例えば、ＵＮＩ２１に接続されているユーザ網内のノード３１が、ＩＰアドレス５２に到るパス７１を設定するとする。このＩＰアドレス５２はＵＮＩ２２に対応している。ノード３１は、ＵＮＩ２１を挟んで対向する光網内のノード４１に対して宛先ＩＰアドレス５２までのパス設定要求を渡す。このパス設定要求には、宛先ＩＰアドレスと、ノード３１が属するユーザ網のユーザＩＤが含まれている。
【００８９】
ノード４１は、光内のＵＮＩ情報を交換によって、あらかじめ宛先のＵＮＩ情報を知っており、ＵＮＩ情報を蓄積記憶している。そして、パス設定要求を受信したノード４１は、蓄積しているＵＮＩ情報を用いて、パス設定要求に含まれているユーザ網のユーザＩＤと同一ユーザグループに属するユーザＩＤを持ち、かつ、パス設定要求に含まれているＩＰアドレス５２と等しいＩＰアドレスを持つＵＮＩ情報を取り出し、この取り出したＵＮＩ情報に含まれるＴＮＡアドレスを取得する。
【００９０】
つぎに、光網内のノード４１は、ＴＮＡアドレス６２のＵＮＩ２２に接続されているノード４２までパス７１を設定する。なお、パス７１の設定後、光コントロールプレーン１内のノード４１，４２はそれぞれＵＮＩ２１，２２を挟んで対向するユーザ網内のノード３１，３２に対してパス設定完了通知を渡してもよい。
【００９１】
この実施の形態６においては、アドレス解決を光網側で運用しているので、ユーザ網から光網固有の情報やオペレーションを隠蔽することができる。また、光網内でルーティングプロトコルを運用してアドレス解決を行っているので、応答の即時性が高く、耐障害性が高いアドレス解決をなし得る。
【００９２】
実施の形態７．
実施の形態７においては、光網内でアドレス解決を行い、アドレス解決方法にはアドレス解決プロトコルを用いるようにする。
【００９３】
図２において、例えば、ＵＮＩ２１に接続されているユーザ網内のノード３１が、ＩＰアドレス５２に到るパス７１を設定するとする。このＩＰアドレス５２はＵＮＩ２２に対応している。ノード３１は、ＵＮＩ２１を挟んで対向する光網内のノード４１に対して宛先ＩＰアドレス５２までのパス設定要求を渡す。このパス設定要求には、宛先ＩＰアドレスと、ノード３１が属するユーザ網のユーザＩＤが含まれている。
【００９４】
パス設定要求を受信したノード４１は、光網内のＵＮＩに接続されている各ノードに、宛先ＵＮＩ２２のＩＰアドレス５２およびパス設定要求を送信してきたノード３１が属するユーザ網のユーザＩＤを付加したアドレス解決要求信号を送付する。
【００９５】
アドレス解決要求信号を受信し、かつアドレス解決要求に対応するＵＮＩに接続されているノードは、その要求に対応するＴＮＡアドレスを含むアドレス解決応答信号をノード４１に返信する。なお、アドレス解決要求信号を受信したノードでは、アドレス解決要求信号に含まれるパス設定要求を送信してきたノード３１が属するユーザ網のユーザＩＤと、ＵＮＩ情報に含まれる宛先ＩＰアドレスの属するユーザ網のユーザＩＤとが同一ユーザグループに属しているか否かがチェックされる。このようにして、ノード４１は、宛先ＩＰアドレス５２が示すＵＮＩ２２に対応するＴＮＡアドレス６２を得る。
【００９６】
つぎに、光網内のノード４１は、ＴＮＡアドレス６２のＵＮＩ２２に接続されているノード４２までパス７１を設定する。なお、パス７１の設定後、光コントロールプレーン１内のノード４１，４２はそれぞれＵＮＩ２１，２２を挟んで対向するユーザ網内のノード３１，３２に対してパス設定完了通知を渡してもよい。
【００９７】
この実施の形態７においては、アドレス解決を光網側で運用しているので、ユーザ網から光網固有の情報やオペレーションを隠蔽することができる。また、光網内でアドレス解決プロトコルを運用することによりアドレス解決を行っているので、運用が容易で、計算量が小さく、耐障害性が高く、誤設定の影響が小さいアドレス解決をなし得る。
【００９８】
実施の形態８．
実施の形態８においては、光網内でアドレス解決を行い、アドレス解決方法にはＰ２Ｐプロトコルによる網トポロジ情報交換を用いるようにする。
【００９９】
図２において、例えば、ＵＮＩ２１に接続されているユーザ網内のノード３１が、ＩＰアドレス５２に到るパス７１を設定するとする。このＩＰアドレス５２はＵＮＩ２２に対応している。ノード３１は、ＵＮＩ２１を挟んで対向する光網内のノード４１に対して宛先ＩＰアドレス５２までのパス設定要求を渡す。このパス設定要求には、宛先ＩＰアドレスと、ノード３１が属するユーザ網のユーザＩＤが含まれている。
【０１００】
パス設定要求を受信したノード４１は、光網の近隣ノードグループのノードに、宛先ＵＮＩ２２のＩＰアドレス５２およびパス設定要求を送信してきたノード３１が属するユーザ網のユーザＩＤを付加したアドレス解決要求信号を送付する。このアドレス解決要求信号を受信したノードは、アドレス解決が可能ならば要求に対応するＴＮＡアドレスを含むアドレス解決応答信号をアドレス解決要求を発生させたノード４１に送信する。アドレス解決が不可能ならば、他の近隣ノードグループの任意のノードに対し、アドレス解決要求を転送する。このようにして、ノード４１は、宛先ＩＰアドレス５２が示すＵＮＩ２２に対応するＴＮＡアドレス６２を得る。なお、アドレス解決要求信号を受信したノードでは、アドレス解決要求信号に含まれるパス設定要求を送信してきたノード３１が属するユーザ網のユーザＩＤと、ＵＮＩ情報に含まれる宛先ＩＰアドレスの属するユーザ網のユーザＩＤとが同一ユーザグループに属しているか否かがチェックされている。
【０１０１】
つぎに、光網内のノード４１は、ＴＮＡアドレス６２のＵＮＩ２２に接続されているノード４２までパス７１を設定する。なお、パス７１の設定後、光コントロールプレーン１内のノード４１，４２はそれぞれＵＮＩ２１，２２を挟んで対向するユーザ網内のノード３１，３２に対してパス設定完了通知を渡してもよい。
【０１０２】
この実施の形態８においては、アドレス解決を光網側で運用しているので、ユーザ網から光網固有の情報やオペレーションを隠蔽することができる。また、光網内でＰ２Ｐプロトコルを運用することによりアドレス解決を行っているので、耐障害性が高く、大規模な網に適用が可能なアドレス解決をなし得る。
【０１０３】
実施の形態９．
つぎに、実施の形態９を図３を用いて説明する。実施の形態９においては、光網がＤＤＲＰにより階層的に管理されている場合を想定している。実施の形態９においては、ＤＤＲＰ構造の光網内でアドレス解決を行い、アドレス解決方法にはアドレス解決プロトコルを用いる。
【０１０４】
図３はＤＤＲＰ網を表しており、図１における光網の光コントロールプレーン１が図３における網２０１〜２０４に対応し、１つのユーザ網４内の複数のサイト１１、１２が図３におけるユーザ網内サイト１０１、１０２に相当する。
【０１０５】
図３において、ユーザ網内のサイト１０１、１０２は、光網にＵＮＩ１１１、１１２、１１３で接続されている。ＵＮＩ１１１はそのユーザ網側にノード１２１及びユーザ網内固有のＩＰアドレスを持っている。また、ＵＮＩ１１１はその光網側にノード２４３及びＴＮＡアドレスを持っている。
【０１０６】
光網内において、ノード２４１〜２４３は網２０４を構成する。網２０４は網２０４の上位階層である網２０３においてノード２３１によって代表されている。網２０３は網２０３の上位階層である網２０２においてノード２２２によって代表される。ここで、ノード２２２、２３１、２４１は所属する階層は異なるが同一のノードである。
【０１０７】
実施の形態９においては、アドレス解決プロトコル及びＤＤＲＰプロトコルの拡張を行う。
【０１０８】
まず、ＤＤＲＰプロトコルを拡張し、ＤＤＲＰプロトコルのトポロジ情報交換において、ＴＮＡアドレスのみではなく、ＵＮＩ情報すなわちあるＵＮＩに対応するＴＮＡアドレスとＩＰアドレスとこのＩＰアドレスの属するユーザ網のユーザＩＤとの対応関係情報を交換する。
【０１０９】
そして、光網内の全てのノード（例えば２３１）は、自分が接続されているＵＮＩ（例えば１１３）についてのＵＮＩ情報に加えて、そのノード（例えば２３１）の下位階層（例えば２０４）内のノードが接続するＵＮＩについてのＵＮＩ情報、もしくは同階層（例えば２０３）内のノードが接続するＵＮＩについてのＵＮＩ情報、もしくは上位階層（例えば２０２）内のノードが接続するＵＮＩ情報を所有しても構わないものとする。
【０１１０】
さらに、光網内の全てのノード（例えば２３１）は、自分が接続されているＵＮＩ（例えば１１３）以外の他のＵＮＩ（例えば１１１）に対するアドレス解決要求を他のノードから受信したとき、そのＵＮＩ（例えば１１１）のＵＮＩ情報を当該ノード（例えば２３１）が所持している場合には、そのノード（例えば２３１）がＴＮＡアドレスを含むアドレス解決応答を生成してよいものとする。すなわち、光網内の全てのノードは、アドレス解決要求を受信した場合に、下位階層の他のノード、もしくは同階層の他のノード、もしくは上位階層の他のノードのアドレス解決要求処理を代行することができるものとする。
【０１１１】
さらに、アドレス解決不可応答信号を導入し、アドレス解決要求を送信した後、一定期間以上アドレス解決応答信号およびアドレス解決不可応答信号の何れかを送信してこないノードに対し、再度アドレス解決要求を送信してよいものとする。
【０１１２】
また、任意の階層（例えば２０３）においてアドレス解決要求を受信した任意のノード２３１がアドレス解決が不可能な時には、アドレス解決要求を別ノードに転送する。
【０１１３】
この際、アドレス解決要求を上位階層（例えば２０２）内の任意のノード（例えば２２２）から受信した場合には、下位階層（例えば２０４）の全てのノードにアドレス解決要求を送信し、それらの全てのノードからアドレス解決不可応答を受信したら、同階層２０３の全てのノードにアドレス解決要求を送信し、同階層２０３の全てのノードからアドレス解決不可応答信号を受信したら、アドレス解決不可応答信号をアドレス解決要求信号の送信元であるノード（この場合２２２）に返信する。
【０１１４】
また、アドレス解決要求信号を同位階層２０３内の任意のノード（例えば２３２）から受信した場合には、下位階層の全てのノード２４１〜２４３にアドレス解決要求を送信し、下位階層の全てのノード２４１〜２４３からアドレス解決不可応答信号を受信したら、アドレス解決不可応答信号をアドレス解決要求信号の送信元であるノード（この場合２３２）に返信する。
【０１１５】
また、アドレス解決要求信号を下位階層内の任意のノード（例えば２４１）から受信した場合には、同位階層２０３内の全てのノード２３１〜２３２にアドレス解決要求を送信し、同位階層２０３内の全てのノード２３１〜２３２からアドレス解決不可応答を受信して、かつ上位階層２０２が存在する場合には上位階層２０２内のノード２２２にアドレス解決要求を送信し、上位階層が存在しないか上位階層内のノード２２２からアドレス解決不可応答を受信した場合には、アドレス解決不可応答信号をアドレス解決要求信号の送信元であるノード（この場合２４１）に返信する。
【０１１６】
この実施の形態９によれば、網内に解が存在し、かつ適切な階層化がされていればアドレスが解決でき、大規模な網に適用が可能という効果がある。一方でアドレス解決に時間がかかり、網の集約を行うノードが障害を起こした場合に問題が発生する。
【０１１７】
【発明の効果】
以上説明したように、この発明によれば、ユーザ網内のノードは、ＵＮＩ間を結ぶパスを光網内に設定してユーザ網のノード間を接続する際、宛先ＵＮＩのユーザ網側のアドレスに基づきパスの宛先ＵＮＩの光網側のアドレスを求めるアドレス解決処理をユーザ網内のノードで実行するようにしており、ユーザ網における網構成の自由度を向上できるとともに、ＵＮＩの光網側のアドレスが固定された場合、障害時の切り分けを容易にできる。また、宛先ＵＮＩのユーザ網側のアドレスに基づきパスの宛先ＵＮＩの光網側のアドレスを求めるアドレス解決処理を光網内のノードで実行するようにしており、これにより管理者の少ない負担で、光網内のパス設定を自動的に効率よくなし得る。
【図面の簡単な説明】
【図１】この発明を適用する光網システムの構成を示す概念図である。
【図２】この発明を適用する光網システムの構成を示す概念図である。
【図３】この発明を適用する階層構造の光網を有する光網システムの構成を示す概念図である。
【符号の説明】
１  光コントロールプレーン、２  光データプレーン、３，４  ユーザ網、１１，１２  サイト、３１，３２  ユーザ網のノード、４１，４２  光網のノード、１０１，１０２  ユーザ網サイト、２０２〜２０４  網、２１１〜２１３，２２１〜２２３，２３１〜２３３，２４１〜２４３  光網のノード。
【図１】
2004266462.tif 000003
【図２】
2004266462.tif 000004
【図３】
2004266462.tif 000005