(57)【要約】  シンク側からリンク容量調整スキーム（ＬＣＡＳ）のメンバーを削除する方法であって、シンク側が、削除指示を受信した後、メンバーが削除（ＲＥＭＯＶＥ）状態に入ることをソース側へ通知するステップと、シンク側が、ソース側からの通知応答を受信したか否かを判断して、受信しなかった場合、前記メンバーの削除状態を続け、且つ前記メンバーからのペイロード読み出しを続け、通知応答を待ち、受信した場合、当該メンバーの状態をアイドル状態に遷移するステップとを含む。同時にシンク側状態機を開示する。シンク側において削除（ＲＥＭＯＶＥ）状態が各メンバーに追加される。ソース側とシンク側の帯域幅の同期調整を確保して、トラヒックの無損害を確保する。
2008533777.tif 000002
【特許請求の範囲】
【請求項１】
シンク側からリンク容量調整スキーム（ＬＣＡＳ）のメンバーを削除する方法であって、
シンク側が、削除指示を受信した後、メンバーが削除（ＲＥＭＯＶＥ）状態に入ることをソース側へ通知するステップと、
シンク側が、ソース側からの通知応答を受信したか否かを判断して、受信しなかった場合、前記メンバーの削除（ＲＥＭＯＶＥ）状態を続け、且つ前記メンバーからのペイロード読み出しを続け、通知応答を待ち、受信した場合、当該メンバーの状態をアイドル（ＩＤＬＥ）状態に遷移するステップと
を含むことを特徴とする方法。
【請求項２】
前記削除指示を受信した後、メンバーが削除状態に入ることをソース側へ通知することは、
前記シンク側から前記ソース側へメンバー状態（ＭＳＴ）＝失敗（ＦＡＩＬ）を送信し、
前記シンク側が前記メンバーの状態をトラヒック搭載（ＯＫ）状態から削除（ＲＥＭＯＶＥ）状態に遷移することを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記通知応答には、制御（ＣＴＲＬ）＝経路失効（ＤＮＵ）、又はＣＴＲＬ＝追加（ＡＤＤ）、又はＣＴＲＬ＝アイドル（ＩＤＬＥ）が含まれることを特徴とする請求項１に記載の方法。
【請求項４】
前記ソース側からの通知応答を受信した後、シンク側が次のマルチフレームにおいて前記メンバーからのペイロード読み出しを停止することを更に含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記メンバーの状態をアイドル（ＩＤＬＥ）状態に遷移した後、シンク側が前記メンバーからのペイロード読み出しを停止し、
前記メンバーに故障が発生したことを検出した場合、通知応答の待ちを終了することを更に含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記メンバーからのペイロード読み出しを停止した後、前記シンク側が前記メンバーを削除することを更に含むことを特徴とする請求項５に記載の方法。
【請求項７】
シンク側から開始されるメンバー削除を実現するＬＣＡＳシンク側状態機であって、アイドル（ＩＤＬＥ）状態と、トラヒック搭載（ＯＫ）状態と、失敗（ＦＡＩＬ）状態とを含み、
ソース側からの、メンバーの削除を確認する通知応答を待ち、且つ前記メンバーからのペイロード読み出しを続ける削除（ＲＥＭＯＶＥ）状態を更に含むことを特徴とするシンク側状態機。
【請求項８】
前記ＲＥＭＯＶＥ状態において、前記シンク側がソース側からの通知応答を受信した後、次のマルチフレームにおいて前記メンバーからのペイロード読み出しを停止することを特徴する請求項８に記載のシンク側状態機。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信技術分野に関し、特にシンク側からリンク容量調整スキーム（ＬＣＡＳ：Ｌｉｎｋ  Ｃａｐａｃｉｔｙ  Ａｄｊｕｓｔｍｅｎｔ  Ｓｃｈｅｍｅ）のメンバーを削除する方法及びシンク側状態機に関する。
【背景技術】
【０００２】
ＬＣＡＳは、国際電気通信連合（ＩＴＵ−Ｔ）Ｇ．７０４２標準により定義され、仮想連結グレープ（ＶＣＧ  ：Ｖｉｒｔｕａｌ  Ｃｏｎｃａｔｅｎａｔｉｏｎ  Ｇｒｏｕｐ）のソース側（Ｓｏｕｒｃｅ  Ｓｉｄｅ）とシンク側（Ｓｉｎｋ  Ｓｉｄｅ）との交渉プロセスを提供して、メンバーを追加又は削除するときトラヒックに損害（ｈｉｔ）を与えないようにし、帯域幅の無瞬断（ｈｉｔｌｅｓｓ）調整を実現している。
【０００３】
仮想連結（ＶＣ：Ｖｉｒｔｕａｌ  Ｃｏｎｃａｔｅｎａｔｉｏｎ）の確立又は削除、メンバーの追加又は削除は、制御パケット（Ｃｏｎｔｒｏｌ  Ｐａｃｋｅｔ）におけるフィールドを改め、ソース側とシンク側との間で交渉通信プロセスを確立することにより実現される。制御パケットは、仮想連結のリンク状態を説明し、ネットワークに変化が発生するとき、ソース側とシンク側の同期を確保する。制御パケットには主に下記のフィールドが含まれる。
１、メンバー状態（ＭＳＴ：Ｍｅｍｂｅｒ  ｓｔａｔｕｓ）フィールドであり、シンク側からソース側へ送信され、仮想連結の各メンバーの状態を伝送する。
２、リシーケンス確認（ＲＳ−Ａｃｋ：Ｒｅ−ｓｅｑｕｅｎｃｅ  ａｃｋｎｏｗｌｅｄｇｅ）ビットであり、シンク側からソース側へ送信され、シンク側によって検出されたメンバーのシーケンスの変化を伝送する。
３、制御（ＣＴＲＬ：Ｃｏｎｔｒｏｌ）フィールドであり、ソース側からシンク側へ送信され、シンク側をソース側と同期し、仮想連結グループのメンバー状態を提供する。
４、グループ識別子（ＧＩＤ：Ｇｒｏｕｐ  ＩＤ）ビットであり、ＶＣＧを識別する。
５、巡回冗長検査（ＣＲＣ：Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）であり、制御パケットを保護する。
【０００４】
仮想連結グループ中の各メンバーにとって、ソース側にある１つのソース側状態機とシンク側にある１つのシンク側状態機とを有する。ソース側状態機は、アイドル（ＩＤＬＥ）状態と、正常状態（ＮＯＲＭＡＬ）と、経路失効（ＤＮＵ：Ｄｏ  Ｎｏｔ  Ｕｓｅ）状態と、追加（ＡＤＤ）状態と、削除（ＲＥＭＯＶＥ）状態との５つの状態を含む。シンク側状態機は、アイドル（ＩＤＬＥ）状態と、トラヒック搭載（ＯＫ）状態と、失敗（ＦＡＩＬ）状態との３つの状態を含む。そのうち、メンバーに関する入力信号に故障状況がない又はメンバー加入の要求が受信され、確認された場合、当該メンバーはトラヒック搭載（ＯＫ）状態にあり、メンバーに関する入力信号に故障状況があり又はメンバー削除の入力要求が受信され、確認された場合、当該メンバーは失敗（ＦＡＩＬ）状態にある。
【０００５】
Ｇ．７０４２において、トラヒックの無損害を確保するため、ＬＣＡＳは、メンバーの追加又は削除操作がソース側により開始されることを要求し、具体的な実現プロセスは、関連する標準を参照することができる。ソース側から開始されるメンバーの追加又は削除プロセスは本発明と関係がないため、ここで説明を省略する。シンク側からメンバーの削除操作を開始する場合においては、Ｇ．７０４２標準により定義のシンク側状態機では、トラヒックに対する無損害を確保できなく、帯域幅の無瞬断調整を実現できない。
【０００６】
図１は、従来技術においてＧ．７０４２標準により定義のシンク側からメンバーの削除を開始する交渉プロセスを示す図である。図１に示すように、シンク側のメンバーがトラヒック搭載状態、即ちＯＫ状態で、ネットワークマネジメントシステム（ＮＭＳ：Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）からの削除指示ＭＲＥＭＯＶＥを受信した後、シンク側は、ソース側へＭＳＴ＝ＦＡＩＬを送信し、次に、当該メンバーからのペイロード読み出しを停止する（Ｓｔｏｐ  ｒｅａｄｉｎｇ  ｐａｙｌｏａｄ）。その後、当該メンバーの状態がＩＤＬＥ状態に遷移し、即ち当該メンバーが成功に削除される。
【０００７】
ここで、ＮＭＳがシンク側からメンバーの削除操作を開始する場合、シンク側状態機の交渉プロセスは、具体的に下記のとおりである。
１）ＮＭＳからの削除指示を受信したシンク側が、ＭＳＴ＝ＦＡＩＬをソース側へ送信する。
２）次のマルチフレームにおいて、シンク側が、当該メンバーからのペイロード読み出しを停止し、且つ当該メンバーの状態がＩＤＬＥ状態に遷移し、即ち当該メンバーが削除される。
【０００８】
説明すべきことは、図１において本発明に関連するのは、点線枠内の、メンバーを削除する状態機部分であり、他の部分は標準中の規定と一致するため、ここで説明を省略する。
【０００９】
Ｇ．７０４２により定義のソース側状態機に相応する交渉プロセスは、具体的に下記のとおりである。
１）ソース側は、ＭＳＴ＝ＦＡＩＬを読み出す。
２）ＣＴＲＬ＝ＤＮＵに改める。即ち、当該メンバーの状態がソース側でＮＯＲＭＡＬからＤＮＵ状態に遷移したことを表す。
３）ソース側は、次のマルチフレームにおいて、当該メンバーへのペイロード送信を停止する（Ｓｔｏｐ  ｓｅｎｄｉｎｇ  ｐａｙｌｏａｄ）。
【００１０】
上記交渉プロセスにおいて、シンク側から送信したＭＳＴ＝ＦＡＩＬは６４ｍｓ／１２８ｍｓを経た後に、ソース側によって読み出される。シンク側においてＭＳＴ＝ＦＡＩＬを送信する時から当該メンバーからのペイロード読み出しを停止する時までの時間間隔がｔＲｘであり、ソース側においてＭＳＴ＝ＦＡＩＬを獲得した時から当該メンバーの状態がＤＮＵ状態に遷移するまでの時間がｔＴｘであると仮定すれば、ソース側においてペイロード送信を停止する時刻とシンク側においてペイロード読み出しを停止する時刻とが異なる場合、例えばｔＲｘがｔＴｘ＋６４ｍｓ／１２８ｍｓより小さく又は大きい場合、トラヒックに損害を与えるようになる。且つ、各シンク側又はソース側のｔＲｘとｔＴｘがすべて異なっている。したがって、Ｇ．７０４２によるシンク側状態機では、シンク側からメンバーの削除を開始する場合のトラヒックの無損害を確保できなく、帯域幅の無瞬断調整を実現できない。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明は、上記問題点に鑑みてなされたものであって、シンク側からメンバー削除を開始する場合に、トラヒックに対する無損害を確保できるようにする、シンク側からＬＣＡＳのメンバーを削除する方法を提供することを主な目的とする。
【００１２】
本発明は、シンク側からメンバー削除を開始する場合に、トラヒックに対する無損害を確保できるようにする、シンク側から開始されるメンバー削除を実現するシンク側状態機を提供することを他の目的とする。
【課題を解決するための手段】
【００１３】
上記目的を達成するため、本発明は下記の具体的な解決手段によって実現されるものである。
【００１４】
シンク側からリンク容量調整スキーム（ＬＣＡＳ）のメンバーを削除する方法であって、シンク側が、削除指示を受信した後、メンバーが削除（ＲＥＭＯＶＥ）状態に入ることをソース側へ通知するステップと、シンク側が、ソース側からの通知応答を受信したか否かを判断して、受信しなかった場合、前記メンバーの削除（ＲＥＭＯＶＥ）状態を続け、且つ前記メンバーからのペイロード読み出しを続け、通知応答を待ち、受信した場合、当該メンバーの状態をアイドル（ＩＤＬＥ）状態に遷移するステップとを含む。
【００１５】
前記削除指示を受信した後、メンバーが削除状態に入ることをソース側へ通知することは、前記シンク側から前記ソース側へメンバー状態（ＭＳＴ）＝失敗（ＦＡＩＬ）を送信し、前記シンク側が前記メンバーの状態をトラヒック搭載（ＯＫ）状態から削除（ＲＥＭＯＶＥ）状態に遷移することを含む。
【００１６】
前記通知応答には、制御（ＣＴＲＬ）＝経路失効（ＤＮＵ）、又はＣＴＲＬ＝追加（ＡＤＤ）、又はＣＴＲＬ＝アイドル（ＩＤＬＥ）が含まれる。
【００１７】
前記ソース側からの通知応答を受信した後、シンク側が次のマルチフレームにおいて前記メンバーからのペイロード読み出しを停止することを更に含む。
【００１８】
前記メンバーの状態をアイドル（ＩＤＬＥ）状態に遷移した後、シンク側が前記メンバーからのペイロード読み出しを停止し、前記メンバーに故障が発生したことを検出した場合、通知応答の待ちを終了することを更に含む。
【００１９】
前記メンバーからのペイロード読み出しを停止した後、前記シンク側が前記メンバーを削除することを更に含む。
【００２０】
シンク側から開始されるメンバー削除を実現するＬＣＡＳシンク側状態機であって、アイドル（ＩＤＬＥ）状態と、トラヒック搭載（ＯＫ）状態と、失敗（ＦＡＩＬ）状態とを含み、ソース側からの、メンバーの削除を確認する通知応答を待ち、且つ前記メンバーからのペイロード読み出しを続ける削除（ＲＥＭＯＶＥ）状態を更に含む。
【００２１】
前記ＲＥＭＯＶＥ状態において、前記シンク側がソース側からの通知応答を受信した後、次のマルチフレームにおいて前記メンバーからのペイロード読み出しを停止する。
【００２２】
本発明は、Ｇ．７０４２により定義のＬＣＡＳシンク側状態機に、メンバーが削除プロセスにあることを表示する状態即ちＲＥＭＯＶＥ状態を追加する。ＲＥＭＯＶＥ状態において、シンク側は、ソース側からの通知応答を待ち、且つ、前記メンバーからのペイロード読み出しを続ける。シンク側は、ソース側からの通知応答を受信した後、次のマルチフレームにおいて前記メンバーからのペイロード読み出しを停止する。
【００２３】
本発明による方法、装置、及び状態機では、ソース側とシンク側の帯域幅の同期調整を確保することにより、トラヒックに対する無損害を確保している。
【発明を実施するための最良の形態】
【００２４】
本発明の目的、解決手段を更に明確するため、以下、図面を参照し実施例を挙げて本発明を更に詳しく説明する。
【００２５】
図２は、本発明においてシンク側からメンバーの削除を開始する交渉プロセスを示す図である。トラヒック搭載（ＯＫ）状態で、シンク側は、ＮＭＳ又はソース側又は他の管理設備からの削除指示ＭＲＥＭＯＶＥを受信する。シンク側は削除待ちメンバーが削除（ＲＥＭＯＶＥ）状態に入ることをソース側へ通知し、ソース側からの通知応答を受信したか否かを判断する。受信しなかった場合、シンク側は前記メンバーの削除状態を続け、且つペイロード読み出しを続け、通知応答を待つ。受信した場合、当該メンバーの状態をアイドル状態に遷移する。交渉プロセスは、具体的に下記のようなステップを含む。
ａ）シンク側はソース側へＭＳＴ＝ＦＡＩＬを送信して、ソース側で当該メンバーの状態を改めるように通知し、且つシンク側で当該メンバーの状態をＯＫ状態からＲＥＭＯＶＥ状態に遷移する。
ｂ）ソース側は、ＭＳＴ＝ＦＡＩＬを獲得した後、ＣＴＲＬフィールドの情報をＤＮＵ状態に改めて、当該メンバーの状態をＮＯＲＭＡＬ状態からＤＮＵ状態に遷移し、且つＣＴＲＬ＝ＤＮＵをシンク側へ送信する。
ｃ）シンク側は、ＣＴＲＬ＝ＤＮＵを受信した後、次のマルチフレームにおいて当該メンバーからのペイロード読み出しを停止する。
ｄ）シンク側は、当該メンバーの状態をＲＥＭＯＶＥ状態からＩＤＬＥ状態に遷移して、当該メンバーの削除が成功したことを示す。
【００２６】
ソース側において、ＣＴＲＬフィールドの情報がＤＮＵ状態に改めた次のマルチフレームにおいて、ソース側が当該メンバーへのペイロード送信を停止し、シンク側において、ＣＴＲＬ＝ＤＮＵを受信した次のマルチフレームにおいて、シンク側が当該メンバーからのペイロード読み出しを停止して、ソース側とシンク側の帯域幅の同期調整を確保でき、これによって、トラヒックに対する無損害を確保する。
【００２７】
説明すべきことは、図２において本発明に関連するのは、点線枠内の、メンバーを削除する状態機部分であり、他の部分はＧ．７０４２中の規定と一致するため、ここで説明を省略する。
【００２８】
さらに、シンク側においてソース側からの通知応答を待つ間に、シンク側が削除待ちメンバーに故障が発生したことを検出した場合、シンク側は直ちに当該メンバーからのペイロード読み出しを停止するとともに、当該メンバーをシンク側から削除する。又は、当該メンバーが正常（ＮＯＲＭ）状態にある場合、シンク側はソース側から送信したＣＴＲＬフィールドの情報に基づいてメンバーを削除するか否かを決定し、例えば、ＣＴＲＬ＝ＤＮＵ／ＡＤＤ／ＩＤＬＥを受信した場合、当該メンバーを削除するように決定する。
【００２９】
上記説明されたのは、本発明の好ましい実施例にすぎず、本発明の保護範囲を限定するものではない。本発明の精神と原則内で行われる種々の修正、均等切替、改善などは全て本発明の保護範囲内に含まれるべきである。
【図面の簡単な説明】
【００３０】
【図１】従来技術においてＧ．７０４２標準により定義のシンク側からメンバーの削除を開始する交渉プロセスを示す図である。
【図２】本発明においてシンク側からメンバーの削除を開始する交渉プロセスを示す図である。
【図１】
2008533777.tif 000003
【図２】
2008533777.tif 000004
【手続補正書】
【提出日】平成19年9月3日(2007.9.3)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
シンク側からリンク容量調整スキーム（ＬＣＡＳ）のメンバーを削除する方法であって、
シンク側が、削除指示を受信した後、メンバーが削除（ＲＥＭＯＶＥ）状態に入ることをソース側へ通知するステップと、
シンク側が、ソース側からの通知応答を受信したか否かを判断して、受信しなかった場合、前記メンバーの削除（ＲＥＭＯＶＥ）状態を続け、且つ前記メンバーからのペイロード読み出しを続け、通知応答を待ち、受信した場合、当該メンバーの状態をアイドル（ＩＤＬＥ）状態に遷移するステップと
を含むことを特徴とする方法。
【請求項２】
前記削除指示を受信した後、メンバーが削除状態に入ることをソース側へ通知することは、
前記シンク側から前記ソース側へメンバー状態（ＭＳＴ）＝失敗（ＦＡＩＬ）を送信し、
前記シンク側が前記メンバーの状態をトラヒック搭載（ＯＫ）状態から削除（ＲＥＭＯＶＥ）状態に遷移することを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記通知応答には、制御（ＣＴＲＬ）＝経路失効（ＤＮＵ）、又はＣＴＲＬ＝追加（ＡＤＤ）、又はＣＴＲＬ＝アイドル（ＩＤＬＥ）が含まれることを特徴とする請求項１に記載の方法。
【請求項４】
前記ソース側からの通知応答を受信した後、シンク側が次のマルチフレームにおいて前記メンバーからのペイロード読み出しを停止することを更に含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記メンバーの状態をアイドル（ＩＤＬＥ）状態に遷移した後、シンク側が前記メンバーからのペイロード読み出しを停止することを更に含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記メンバーに故障が発生したことを検出した場合、通知応答の待ちを終了することを更に含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記メンバーからのペイロード読み出しを停止した後、前記シンク側が前記メンバーを削除することを更に含むことを特徴とする請求項５に記載の方法。
【請求項８】
シンク側から開始されるメンバー削除を実現するＬＣＡＳシンク側状態機であって、アイドル（ＩＤＬＥ）状態と、トラヒック搭載（ＯＫ）状態と、失敗（ＦＡＩＬ）状態とを含み、
ソース側からの、メンバーの削除を確認する通知応答を待ち、且つ前記メンバーからのペイロード読み出しを続ける削除（ＲＥＭＯＶＥ）状態を更に含むことを特徴とするシンク側状態機。
【請求項９】
前記ＲＥＭＯＶＥ状態において、前記シンク側がソース側からの通知応答を受信した後、次のマルチフレームにおいて前記メンバーからのペイロード読み出しを停止することを特徴する請求項８に記載のシンク側状態機。
【請求項１０】
シンク側からリンク容量調整スキーム（ＬＣＡＳ）のメンバーを削除する装置であって、
削除指示を受信した後、メンバーが削除（ＲＥＭＯＶＥ）状態に入ることをソース側へ通知し、ソース側からの通知応答を受信したか否かを判断して、受信しなかった場合、前記メンバーの削除（ＲＥＭＯＶＥ）状態を続け、且つ前記メンバーからのペイロード読み出しを続け、通知応答を待ち、受信した場合、当該メンバーの状態をアイドル（ＩＤＬＥ）状態に遷移するユニットを含むことを特徴とする装置。
【請求項１１】
前記ユニットが更に、前記ソース側へメンバー状態（ＭＳＴ）＝失敗（ＦＡＩＬ）を送信し、前記メンバーの状態をトラヒック搭載（ＯＫ）状態から削除（ＲＥＭＯＶＥ）状態に遷移することを特徴とする請求項１０に記載の装置。
【請求項１２】
前記ユニットが更に、前記ソース側からの通知応答を受信した後、次のマルチフレームにおいて前記メンバーからのペイロード読み出しを停止することを特徴とする請求項１０に記載の装置。
【請求項１３】
前記ユニットが更に、前記メンバーの状態をアイドル（ＩＤＬＥ）状態に遷移した後、前記メンバーからのペイロード読み出しを停止することを特徴とする請求項１０に記載の装置。
【請求項１４】
前記ユニットが更に、前記メンバーに故障が発生したことを検出した場合、通知応答の待ちを終了することを特徴とする請求項１０に記載の装置。
【請求項１５】
前記ユニットが更に、前記メンバーからのペイロード読み出しを停止した後、前記メンバーを削除することを特徴とする請求項１３に記載の装置。
【請求項１６】
シンク側からリンク容量調整スキーム（ＬＣＡＳ）のメンバーを削除する装置であって、
メンバーが削除（ＲＥＭＯＶＥ）状態に入ることを通知するシンク側からの通知を受信し、通知応答をシンク側へ送信するユニットを含む、ことを特徴とする装置。
【請求項１７】
シンク側からの通知には、メンバー状態（ＭＳＴ）＝失敗（ＦＡＩＬ）が含まれる、ことを特徴とする請求項１６に記載の装置。
【請求項１８】
前記通知応答には、制御（ＣＴＲＬ）＝経路失効（ＤＮＵ）、又はＣＴＲＬ＝追加（ＡＤＤ）、又はＣＴＲＬ＝アイドル（ＩＤＬＥ）が含まれる、ことを特徴とする請求項１６に記載の装置。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信技術分野に関し、特にシンク側からリンク容量調整スキーム（ＬＣＡＳ：Ｌｉｎｋ  Ｃａｐａｃｉｔｙ  Ａｄｊｕｓｔｍｅｎｔ  Ｓｃｈｅｍｅ）のメンバーを削除する方法、装置及びシンク側状態機に関する。
【背景技術】
【０００２】
ＬＣＡＳは、国際電気通信連合（ＩＴＵ−Ｔ）Ｇ．７０４２標準により定義され、仮想連結グレープ（ＶＣＧ  ：Ｖｉｒｔｕａｌ  Ｃｏｎｃａｔｅｎａｔｉｏｎ  Ｇｒｏｕｐ）のソース側（Ｓｏｕｒｃｅ  Ｓｉｄｅ）とシンク側（Ｓｉｎｋ  Ｓｉｄｅ）との交渉プロセスを提供して、メンバーを追加又は削除するときトラヒックに損害（ｈｉｔ）を与えないようにし、帯域幅の無瞬断（ｈｉｔｌｅｓｓ）調整を実現している。
【０００３】
仮想連結（ＶＣ：Ｖｉｒｔｕａｌ  Ｃｏｎｃａｔｅｎａｔｉｏｎ）の確立又は削除、メンバーの追加又は削除は、制御パケット（Ｃｏｎｔｒｏｌ  Ｐａｃｋｅｔ）におけるフィールドを改め、ソース側とシンク側との間で交渉通信プロセスを確立することにより実現される。制御パケットは、仮想連結のリンク状態を説明し、ネットワークに変化が発生するとき、ソース側とシンク側の同期を確保する。制御パケットには主に下記のフィールドが含まれる。
１、メンバー状態（ＭＳＴ：Ｍｅｍｂｅｒ  ｓｔａｔｕｓ）フィールドであり、シンク側からソース側へ送信され、仮想連結の各メンバーの状態を伝送する。
２、リシーケンス確認（ＲＳ−Ａｃｋ：Ｒｅ−ｓｅｑｕｅｎｃｅ  ａｃｋｎｏｗｌｅｄｇｅ）ビットであり、シンク側からソース側へ送信され、シンク側によって検出されたメンバーのシーケンスの変化を伝送する。
３、制御（ＣＴＲＬ：Ｃｏｎｔｒｏｌ）フィールドであり、ソース側からシンク側へ送信され、シンク側をソース側と同期し、仮想連結グループのメンバー状態を提供する。
４、グループ識別子（ＧＩＤ：Ｇｒｏｕｐ  ＩＤ）ビットであり、ＶＣＧを識別する。
５、巡回冗長検査（ＣＲＣ：Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）であり、制御パケットを保護する。
【０００４】
仮想連結グループ中の各メンバーにとって、ソース側にある１つのソース側状態機とシンク側にある１つのシンク側状態機とを有する。ソース側状態機は、アイドル（ＩＤＬＥ）状態と、正常状態（ＮＯＲＭＡＬ）と、経路失効（ＤＮＵ：Ｄｏ  Ｎｏｔ  Ｕｓｅ）状態と、追加（ＡＤＤ）状態と、削除（ＲＥＭＯＶＥ）状態との５つの状態を含む。シンク側状態機は、アイドル（ＩＤＬＥ）状態と、トラヒック搭載（ＯＫ）状態と、失敗（ＦＡＩＬ）状態との３つの状態を含む。そのうち、メンバーに関する入力信号に故障状況がない又はメンバー加入の要求が受信され、確認された場合、当該メンバーはトラヒック搭載（ＯＫ）状態にあり、メンバーに関する入力信号に故障状況があり又はメンバー削除の入力要求が受信され、確認された場合、当該メンバーは失敗（ＦＡＩＬ）状態にある。
【０００５】
Ｇ．７０４２において、トラヒックの無損害を確保するため、ＬＣＡＳは、メンバーの追加又は削除操作がソース側により開始されることを要求し、具体的な実現プロセスは、関連する標準を参照することができる。ソース側から開始されるメンバーの追加又は削除プロセスは本発明と関係がないため、ここで説明を省略する。シンク側からメンバーの削除操作を開始する場合においては、Ｇ．７０４２標準により定義のシンク側状態機では、トラヒックに対する無損害を確保できなく、帯域幅の無瞬断調整を実現できない。
【０００６】
図１は、従来技術においてＧ．７０４２標準により定義のシンク側からメンバーの削除を開始する交渉プロセスを示す図である。図１に示すように、シンク側のメンバーがトラヒック搭載状態、即ちＯＫ状態で、ネットワークマネジメントシステム（ＮＭＳ：Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）からの削除指示ＭＲＥＭＯＶＥを受信した後、シンク側は、ソース側へＭＳＴ＝ＦＡＩＬを送信し、次に、当該メンバーからのペイロード読み出しを停止する（Ｓｔｏｐ  ｒｅａｄｉｎｇ  ｐａｙｌｏａｄ）。その後、当該メンバーの状態がＩＤＬＥ状態に遷移し、即ち当該メンバーが成功に削除される。
【０００７】
ここで、ＮＭＳがシンク側からメンバーの削除操作を開始する場合、シンク側状態機の交渉プロセスは、具体的に下記のとおりである。
１）ＮＭＳからの削除指示を受信したシンク側が、ＭＳＴ＝ＦＡＩＬをソース側へ送信する。
２）次のマルチフレームにおいて、シンク側が、当該メンバーからのペイロード読み出しを停止し、且つ当該メンバーの状態がＩＤＬＥ状態に遷移し、即ち当該メンバーが削除される。
【０００８】
説明すべきことは、図１において本発明に関連するのは、点線枠内の、メンバーを削除する状態機部分であり、他の部分は標準中の規定と一致するため、ここで説明を省略する。
【０００９】
Ｇ．７０４２により定義のソース側状態機に相応する交渉プロセスは、具体的に下記のとおりである。
１）ソース側は、ＭＳＴ＝ＦＡＩＬを読み出す。
２）ＣＴＲＬ＝ＤＮＵに改める。即ち、当該メンバーの状態がソース側でＮＯＲＭＡＬからＤＮＵ状態に遷移したことを表す。
３）ソース側は、次のマルチフレームにおいて、当該メンバーへのペイロード送信を停止する（Ｓｔｏｐ  ｓｅｎｄｉｎｇ  ｐａｙｌｏａｄ）。
【００１０】
上記交渉プロセスにおいて、シンク側から送信したＭＳＴ＝ＦＡＩＬは６４ｍｓ／１２８ｍｓを経た後に、ソース側によって読み出される。シンク側においてＭＳＴ＝ＦＡＩＬを送信する時から当該メンバーからのペイロード読み出しを停止する時までの時間間隔がｔＲｘであり、ソース側においてＭＳＴ＝ＦＡＩＬを獲得した時から当該メンバーの状態がＤＮＵ状態に遷移するまでの時間がｔＴｘであると仮定すれば、ソース側においてペイロード送信を停止する時刻とシンク側においてペイロード読み出しを停止する時刻とが異なる場合、例えばｔＲｘがｔＴｘ＋６４ｍｓ／１２８ｍｓより小さく又は大きい場合、トラヒックに損害を与えるようになる。且つ、各シンク側又はソース側のｔＲｘとｔＴｘがすべて異なっている。したがって、Ｇ．７０４２によるシンク側状態機では、シンク側からメンバーの削除を開始する場合のトラヒックの無損害を確保できなく、帯域幅の無瞬断調整を実現できない。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明は、上記問題点に鑑みてなされたものであって、シンク側からメンバー削除を開始する場合に、トラヒックに対する無損害を確保できるようにする、シンク側からＬＣＡＳのメンバーを削除する方法及び装置を提供することを主な目的とする。
【００１２】
本発明は、シンク側からメンバー削除を開始する場合に、トラヒックに対する無損害を確保できるようにする、シンク側から開始されるメンバー削除を実現するシンク側状態機を提供することを他の目的とする。
【課題を解決するための手段】
【００１３】
上記目的を達成するため、本発明は下記の具体的な解決手段によって実現されるものである。
【００１４】
シンク側からリンク容量調整スキーム（ＬＣＡＳ）のメンバーを削除する方法であって、シンク側が、削除指示を受信した後、メンバーが削除（ＲＥＭＯＶＥ）状態に入ることをソース側へ通知するステップと、シンク側が、ソース側からの通知応答を受信したか否かを判断して、受信しなかった場合、前記メンバーの削除（ＲＥＭＯＶＥ）状態を続け、且つ前記メンバーからのペイロード読み出しを続け、通知応答を待ち、受信した場合、当該メンバーの状態をアイドル（ＩＤＬＥ）状態に遷移するステップとを含む。
【００１５】
前記削除指示を受信した後、メンバーが削除状態に入ることをソース側へ通知することは、前記シンク側から前記ソース側へメンバー状態（ＭＳＴ）＝失敗（ＦＡＩＬ）を送信し、前記シンク側が前記メンバーの状態をトラヒック搭載（ＯＫ）状態から削除（ＲＥＭＯＶＥ）状態に遷移することを含む。
【００１６】
前記通知応答には、制御（ＣＴＲＬ）＝経路失効（ＤＮＵ）、又はＣＴＲＬ＝追加（ＡＤＤ）、又はＣＴＲＬ＝アイドル（ＩＤＬＥ）が含まれる。
【００１７】
前記ソース側からの通知応答を受信した後、シンク側が次のマルチフレームにおいて前記メンバーからのペイロード読み出しを停止することを更に含む。
【００１８】
前記メンバーの状態をアイドル（ＩＤＬＥ）状態に遷移した後、シンク側が前記メンバーからのペイロード読み出しを停止することを更に含む。
【００１９】
前記メンバーに故障が発生したことを検出した場合、通知応答の待ちを終了することを更に含む。
【００２０】
前記メンバーからのペイロード読み出しを停止した後、前記シンク側が前記メンバーを削除することを更に含む。
【００２１】
シンク側から開始されるメンバー削除を実現するＬＣＡＳシンク側状態機であって、アイドル（ＩＤＬＥ）状態と、トラヒック搭載（ＯＫ）状態と、失敗（ＦＡＩＬ）状態とを含み、ソース側からの、メンバーの削除を確認する通知応答を待ち、且つ前記メンバーからのペイロード読み出しを続ける削除（ＲＥＭＯＶＥ）状態を更に含む。
【００２２】
前記ＲＥＭＯＶＥ状態において、前記シンク側がソース側からの通知応答を受信した後、次のマルチフレームにおいて前記メンバーからのペイロード読み出しを停止する。
【００２３】
シンク側からリンク容量調整スキーム（ＬＣＡＳ）のメンバーを削除する装置であって、削除指示を受信した後、メンバーが削除（ＲＥＭＯＶＥ）状態に入ることをソース側へ通知し、ソース側からの通知応答を受信したか否かを判断して、受信しなかった場合、前記メンバーの削除（ＲＥＭＯＶＥ）状態を続け、且つ前記メンバーからのペイロード読み出しを続け、通知応答を待ち、受信した場合、当該メンバーの状態をアイドル（ＩＤＬＥ）状態に遷移するユニットを含む。
【００２４】
前記ユニットは更に、前記ソース側へメンバー状態（ＭＳＴ）＝失敗（ＦＡＩＬ）を送信し、前記メンバーの状態をトラヒック搭載（ＯＫ）状態から削除（ＲＥＭＯＶＥ）状態に遷移する。
【００２５】
前記ユニットは更に、前記ソース側からの通知応答を受信した後、次のマルチフレームにおいて前記メンバーからのペイロード読み出しを停止する。
【００２６】
前記ユニットは更に、前記メンバーの状態をアイドル（ＩＤＬＥ）状態に遷移した後、前記メンバーからのペイロード読み出しを停止する。
【００２７】
前記ユニットは更に、前記メンバーに故障が発生したことを検出した場合、通知応答の待ちを終了する。
【００２８】
前記ユニットは更に、前記メンバーからのペイロード読み出しを停止した後、前記メンバーを削除する。
【００２９】
シンク側からリンク容量調整スキーム（ＬＣＡＳ）のメンバーを削除する装置であって、メンバーが削除（ＲＥＭＯＶＥ）状態に入ることを通知するシンク側からの通知を受信し、通知応答をシンク側へ送信するユニットを含む。
【００３０】
シンク側からの通知には、メンバー状態（ＭＳＴ）＝失敗（ＦＡＩＬ）が含まれる。
【００３１】
前記通知応答には、制御（ＣＴＲＬ）＝経路失効（ＤＮＵ）、又はＣＴＲＬ＝追加（ＡＤＤ）、又はＣＴＲＬ＝アイドル（ＩＤＬＥ）が含まれる。
【００３２】
本発明は、Ｇ．７０４２により定義のＬＣＡＳシンク側状態機に、メンバーが削除プロセスにあることを表示する状態即ちＲＥＭＯＶＥ状態を追加する。ＲＥＭＯＶＥ状態において、シンク側は、ソース側からの通知応答を待ち、且つ、前記メンバーからのペイロード読み出しを続ける。シンク側は、ソース側からの通知応答を受信した後、次のマルチフレームにおいて前記メンバーからのペイロード読み出しを停止する。
【００３３】
本発明による方法、装置、及び状態機では、ソース側とシンク側の帯域幅の同期調整を確保することにより、トラヒックに対する無損害を確保している。
【発明を実施するための最良の形態】
【００３４】
本発明の目的、解決手段を更に明確するため、以下、図面を参照し実施例を挙げて本発明を更に詳しく説明する。
【００３５】
図２は、本発明においてシンク側からメンバーの削除を開始する交渉プロセスを示す図である。トラヒック搭載（ＯＫ）状態で、シンク側は、ＮＭＳ又はソース側又は他の管理設備からの削除指示ＭＲＥＭＯＶＥを受信する。シンク側は削除待ちメンバーが削除（ＲＥＭＯＶＥ）状態に入ることをソース側へ通知し、ソース側からの通知応答を受信したか否かを判断する。受信しなかった場合、シンク側は前記メンバーの削除状態を続け、且つペイロード読み出しを続け、通知応答を待つ。受信した場合、当該メンバーの状態をアイドル状態に遷移する。交渉プロセスは、具体的に下記のようなステップを含む。
ａ）シンク側はソース側へＭＳＴ＝ＦＡＩＬを送信して、ソース側で当該メンバーの状態を改めるように通知し、且つシンク側で当該メンバーの状態をＯＫ状態からＲＥＭＯＶＥ状態に遷移する。
ｂ）ソース側は、ＭＳＴ＝ＦＡＩＬを獲得した後、ＣＴＲＬフィールドの情報をＤＮＵ状態に改めて、当該メンバーの状態をＮＯＲＭＡＬ状態からＤＮＵ状態に遷移し、且つＣＴＲＬ＝ＤＮＵをシンク側へ送信する。
ｃ）シンク側は、ＣＴＲＬ＝ＤＮＵを受信した後、次のマルチフレームにおいて当該メンバーからのペイロード読み出しを停止する。
ｄ）シンク側は、当該メンバーの状態をＲＥＭＯＶＥ状態からＩＤＬＥ状態に遷移して、当該メンバーの削除が成功したことを示す。
【００３６】
ソース側において、ＣＴＲＬフィールドの情報がＤＮＵ状態に改めた次のマルチフレームにおいて、ソース側が当該メンバーへのペイロード送信を停止し、シンク側において、ＣＴＲＬ＝ＤＮＵを受信した次のマルチフレームにおいて、シンク側が当該メンバーからのペイロード読み出しを停止して、ソース側とシンク側の帯域幅の同期調整を確保でき、これによって、トラヒックに対する無損害を確保する。
【００３７】
説明すべきことは、図２において本発明に関連するのは、点線枠内の、メンバーを削除する状態機部分であり、他の部分はＧ．７０４２中の規定と一致するため、ここで説明を省略する。
【００３８】
さらに、シンク側においてソース側からの通知応答を待つ間に、シンク側が削除待ちメンバーに故障が発生したことを検出した場合、シンク側は直ちに当該メンバーからのペイロード読み出しを停止するとともに、当該メンバーをシンク側から削除する。又は、当該メンバーが正常（ＮＯＲＭ）状態にある場合、シンク側はソース側から送信したＣＴＲＬフィールドの情報に基づいてメンバーを削除するか否かを決定し、例えば、ＣＴＲＬ＝ＤＮＵ／ＡＤＤ／ＩＤＬＥを受信した場合、当該メンバーを削除するように決定する。
【００３９】
上記説明されたのは、本発明の好ましい実施例にすぎず、本発明の保護範囲を限定するものではない。本発明の精神と原則内で行われる種々の修正、均等切替、改善などは全て本発明の保護範囲内に含まれるべきである。
【図面の簡単な説明】
【００４０】
【図１】従来技術においてＧ．７０４２標準により定義のシンク側からメンバーの削除を開始する交渉プロセスを示す図である。
【図２】本発明においてシンク側からメンバーの削除を開始する交渉プロセスを示す図である。
【国際調査報告】
2008533777.tif 000005
2008533777.tif 000006
2008533777.tif 000007
2008533777.tif 000008