JP6051320B2 - 光伝送ネットワークにおける保護されたＯＤＵｆｌｅｘコネクションのリサイジング方法 - Google Patents

Description

本発明は、電気通信分野に関し、特に、光伝送ネットワーク（ＯＴＮ）送信プロテクションに関し、より具体的にはフレキシブルサイズの下位光データユニットで表される保護されたコネクションのリサイジングに関する。

国際電気通信連合（ＩＴＵ）はＩＴＵ−Ｔ勧告Ｇ．７０９を定めており、その最新版であるＧ．７０９（２０１２年２月）において、光伝送ネットワーク（Ｏｐｔｉｃａｌ Ｔｒａｎｓｐｏｒｔ Ｎｅｔｗｏｒｋ；ＯＴＮ）の信号フォーマットおよびインタフェースを定めている。基本フレーム構造はＯＴＵｋ（サイズｋの光伝送モジュール）である（ここでｋは１、２、２ｅ、３、３ｅ２または４をとることができ、このうちＯＴＵ２ｅおよびＯＴＵ３ｅ２は、ＩＴＵ−Ｔ勧告Ｇ．７０９の原理を用いてＩＴＵ−Ｔ補足文書Ｇ．ｓｕｐ４３に記述されている）。ＯＴＵｋは、フレーミングおよびセクションオーバーヘッドとこれに加えてＯＤＵｋ（サイズｋの光データユニット）と呼ばれるビット同期マッピングされたトランスポートエンティティとを含む。ＯＤＵｋは、ペイロードエリアとＯＤＵｋオーバーヘッド（ＯＨ）とを含む。このペイロードエリア内には光ペイロードユニット（Ｏｐｔｉｃａｌ Ｐａｙｌｏａｄ Ｕｎｉｔ；ＯＰＵｋ）がマッピングされており、クライアント信号または時分割多重されたその他の下位（ｌｏｗｅｒ ｏｒｄｅｒ；ＬＯ）ＯＤＵを搬送する。

光伝送ネットワークにおいては、コネクションはＯＤＵレベルで切り替えられる。このため、ＯＤＵはネットワークパス上を移動する切り替え可能なトランスポートエンティティであり、ネットワークパスをＯＤＵｋで表現することができる。ここで、２つの可能性、すなわち、クライアントを直接搬送する、サブストラクチャをもたない直接下位（ＬＯ）ＯＤＵｋと、それぞれネットワークパスを表現する複数の下位（ＬＯ）ＯＤＵｊを搬送する、より一般的なＨＯ−ＯＤＵｋとが考えられる。

従来はＯＤＵの各タイプは特定の公称サイズをもつものであったが、その後、より一層多様なクライアント信号レートをサポートするために、ＯＤＵｆｌｅｘと呼ばれるフレキシブルサイズのＯＤＵが導入された。これは、特定のクライアントアダプテーションによる特定ビットレートのＯＤＵｆｌｅｘをもたらす直接ＣＢＲ（ｃｏｎｓｔａｎｔ ｂｉｔ ｒａｔｅ）信号クライアントであり、あるいは、パケットデータ転送の場合には、パケットデータがＧＦＰフレーム内にカプセル化されていることが一般的である。ＨＯ−ＯＰＵｋは、多数の１，２５Ｇトリビュタリスロット（Ｔｒｉｂｕｔａｒｙ Ｓｌｏｔ）に分割され、ＯＤＵｆｌｅｘは任意の数のトリビュタリスロットを割り当てることができる。すべてのトリビュタリスロットが同一のＯＤＵｋの一部である必要があるものの、トリビュタリスロットの選択は任意的である。このように、ＯＤＵｆｌｅｘにおけるＧＦＰマッピングされたデータのサイズは１，２５Ｇトリビュタリスロットの粒度で、サーバＯＤＵｋがサポートする最大トリビュタリスロット数になるまでのサイズで構成することができる。

可変トラヒック負荷状況をサポートするために、ＩＴＵ−Ｔ勧告Ｇ．７０４４（２０１１年１０月）は、動作中のＯＤＵｆｌｅｘコネクションのための無瞬断（ヒットレス、ｈｉｔｌｅｓｓ）リサイジングオプションを規定している。勧告Ｇ．７０４４によって規定されるリサイズプロトコルは主に２つの部分、すなわち、それぞれセクションレイヤおよびＯＤＵパスレイヤを含む、ＬＣＲ（Ｌｉｎｋ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｉｚｅ；リンクコネクションリサイズ）プロトコル部と、ＢＷＲ（Ｂａｎｄｗｉｄｔｈ Ｒｅｓｉｚｅ；帯域幅リサイズ）プロトコル部からなる。

すべてのＯＳＩレイヤ１伝送ネットワークにおけると同様、ネットワークパスのエンドツーエンドプロテクションがＯＴＮにおける重要な特徴となる。アクティブなコネクションを障害から保護するために冗長な保護パスが確立され、障害が発生した場合、トラヒックは障害が発生したアクティブなパスから保護パスへ切り替えられる。ＯＴＮプロテクション機構のためのリニアプロテクション機構がＩＴＵ−Ｔ勧告Ｇ．８７３．１（２０１１年７月）において規定されており、またＯＤＵｋシェアドリングプロテクション（ＯＤＵｋ ｓｈａｒｅｄ ｒｉｎｇ ｐｒｏｔｅｃｔｉｏｎ）がＩＴＵ−Ｔ勧告Ｇ．８７３．２（２０１２年４月）において規定されている。

しかしながら、これらの標準においては、リサイズされたＯＤＵｆｌｅｘコンテナのプロテクションが規定およびサポートされていない。問題は、セクションレイヤとパスレイヤに関係する２部構成のリサイズ機構の複雑さであり、プロテクションを実行可能とするためには現用コネクションと保護コネクションとが同じサイズをもたなければならず、したがって同時にリサイズされなければならないという事実にあるが、そのような同時的リサイズは容易には可能でないのである。

近時、韓国電子通信研究院（Ｋｏｒｅａｎ’ｓ Ｅｌｅｃｔｒｏｎｉｃｓ ａｎｄ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｒｅｓｅａｒｃｈ Ｉｎｓｔｉｔｕｔｅ）所属のＪ．ＹｏｕｎらによりＩＴＵ ＳＧ１５へ提供されたコントリビューション第２２５４号においては、現用ＯＤＵｆｌｅｘに対しては現行の２ステップ型のリサイジング機構を用いてリサイズを行う一方で、保護トランスポートエンティティについてはＯＤＵｆｌｅｘ帯域幅リサイジングを行うことなくリンクコネクションリサイジングのみを行うことが提唱されている。帯域幅リサイジングプロセスを抑制するために新たな信号ビットが定義されるとされている。

ＩＴＵ−Ｔ勧告Ｇ．７０９（２０１２年） ＩＴＵ−Ｔ勧告Ｇ．７０４４（２０１１年） ＩＴＵ−Ｔ勧告Ｇ．８７３．１（２０１１年） ＩＴＵ−Ｔ勧告Ｇ．８７３．２（２０１２年） ＩＴＵ−Ｔ補足文書Ｇ．ｓｕｐ４３（２０１１年） ＩＴＵ ＳＧ１５ Ｃｏｎｔｒｉｂｕｔｉｏｎ ２２５４

しかしながら、リサイジングプロトコルのＢＷＲ部の抑制という解決方法は満足のいくものではない。かかる解決方法は保護パスの帯域幅リサイジングの適切な完結をもたらすものではなく、また、利用可能なリソースが不足するために保護パスのリサイジングに失敗した場合には、リサイズされた現用パスを利用可能な保護パスがない状態に放置してしまうことがあるからである。

本発明の目的は、したがって、光伝送ネットワークにおける保護されたＯＤＵｆｌｅｘコネクションの無瞬断なリサイジングを行うことができる方法および関連するネットワークノードを提供することにある。

これらの目的および以下に記載のその他の目的は、アクティブパスと保護パスとのリサイジングを同期するために、プロテクショングループを終端するシンク側接続機能内に、エンドツーエンドシグナリングおよび／または接続性チェックに関連するリサイズオーバーヘッド信号の論理処理を導入することによって達成される。

より具体的には、保護されたコネクションのリサイジング方法であって、この保護されたコネクションがフレキシブルサイズの下位光データユニットによって表されている、該保護されたコネクションのリサイジング方法が提供される。保護されたコネクションは、少なくとも１つのアクティブパスメンバーと少なくとも１つの保護パスメンバーとで構成されたプロテクショングループを含む。リサイジングは、２部構成のリサイズプロトコルを用いて行われ、このリサイズプロトコルは、リンクコネクションリサイズプロトコル部と帯域幅リサイズプロトコル部とを有している。リンクコネクションリサイズプロトコル部は、少なくとも１つのアクティブパスおよび少なくとも１つの保護パスに沿ってリンクのリサイズを行うために実行される。帯域幅リサイズプロトコル部は、フレキシブルサイズの下位光データユニットの容量をリサイズするために実行される。リンクリサイズプロトコルの一部として、少なくとも１つのアクティブパスおよび少なくとも１つの保護パスに沿うリンクのリサイジングの成功または失敗を示す確認信号が、交換されて最終的にプロテクショングループを終端する接続機能において受信される。接続機能は、帯域幅リサイズプロトコル部を完結させる下位光データユニットターミネーション機能のための単一の論理的に処理された出力確認信号を生成するために、少なくとも１つのアクティブパスからの確認信号と少なくとも１つの保護パスからの確認信号とを論理的に組み合わせる。

追加的におよび／または代替的に、それぞれアクティブパスと保護パスとを介して交換され、リサイズ処理の開始および終了を示すステータス信号を、リサイジング処理を同期化するために、プロテクショングループのブリッジ機能およびセレクタ機能を提供する接続機能において論理的に組み合わせることができる。

リサイズ処理を同期化するとともに確認および／またはステータスプロトコルメッセージを論理的に組み合わせることにより、すべてのプロテクショングループに対してリサイジングが成功するか、あるいはすべてのプロテクショングループメンバーに対してリサイジングが失敗することを達成することができ、これにより、プロテクショングループをそのまま常時動作可能に維持することができる。

本発明の好ましい実施形態を、添付の図面を参照しながら以下に説明する。

勧告Ｇ．７０４４に準拠するリンクコネクションリサイズ（ＬＣＲ）プロトコルの概要を示した図である。 勧告Ｇ．７０４４に準拠する帯域幅リサイズ（ＢＷＲ）プロトコルの概要を示した図である。 勧告Ｇ．７０４４に規定されるリサイズ制御オーバーヘッド（Ｒｅｓｉｚｅ Ｃｏｎｔｒｏｌ Ｏｖｅｒｈｅａｄ；ＲＣＯＨ）を示した図である。 リサイジングを完了できなかった場合の保護されたＯＤＵｆｌｅｘコネクションを示した図である。 １＋１リニアパスプロテクションでＯＤＵｆｌｅｘコネクションをリサイジングするための実施形態を示した図である。 １：１リニアパスプロテクションでＯＤＵｆｌｅｘコネクションをリサイジングするための実施形態を示した図である。

ＯＤＵｆｌｅｘエンティティは、様々なクライアント固有のデータレートを光送信で搬送するためにＯＴＮにおいて用いられるエンティティである。１つの重要なケースは、ＧＦＰ（Ｇｅｎｅｒｉｃ Ｆｒａｍｅ Ｐｒｏｃｅｓｓｉｎｇ）でカプセル化したデータＰＤＵ（ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）を、ＯＴＮを介して搬送するケースであり、このための無瞬断（ヒットレスな）リサイズのオプションが勧告Ｇ．７０４４に規定されている。

前述のように、リサイズされたＯＤＵｆｌｅｘエンティティの送信プロテクションは、ＩＴＵ標準では規定されていない。他方、リサイズプロトコルの処理は、２つの独立なステップである、ＬＣＲ（リンクコネクションリサイズ；Ｌｉｎｋ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｉｚｅ）プロトコル部と、ＢＷＲ（帯域幅リサイズ；Ｂａｎｄｗｉｄｔｈ Ｒｅｓｉｚｅ）プロトコル部とを含み、これらのプロトコル部は、セクションレイヤおよびＯＤＵパスレイヤに関与する。アクティブなコネクションと保護コネクションとの双方をリサイズするためには、プロトコルを完了するために２組のセクションレイヤエンティティと、１つだけのパスレイヤエンティティが必要となると考えられる。現状では、プロトコルを完了するためにアクティブなセクションエンティティのみがＯＤＵｆｌｅｘパスレイヤとやりとりを行うことができる。他方、保護コネクションのリサイジングはアクティブなセクションの組と同期されて行われること、および、保護コネクションがこのようにして障害の場合にトラヒックを引き継ぐことができること、が確保されなければならない。そうでない場合には、保護切り替えがトラヒックの損失につながりうる。

前述したように、ＯＤＵｋは、ネットワークパス上を移動する切り替え可能なトランスポートエンティティである。このことは、ネットワークパス上のネットワークノードが切り替えマトリックスを介して個々のＯＤＵｋエンティティどうしを相互接続することを前提としている。ＯＴＮ用ネットワーク設備の機能ブロックはＩＴＵ勧告Ｇ．７９８に記述されている。

近時承認されたＩＴＵ−Ｔ勧告Ｇ．７９８の改訂版は、その図１４−５において、ＯＤＵ接続マトリックスを通過しなければならないリサイズプロトコル信号を含め、ＯＤＵｋ接続機能プロセスを示している。以下にさらに詳述するように、ＯＤＵｆｌｅｘコンテナのリサイズ処理に必要な関連信号は、ＯＤＵｋ＿ＣＩ＿ＲＰおよびＯＤＵｋ＿ＣＩ＿ＴＳＣＣであって、これらはともにＯＤＵｆｌｅｘ ＣＩ（特徴的情報；Ｃｈａｒａｃｔｅｒｉｓｔｉｃ Ｉｎｆｏｒｍａｔｉｏｎ）と接続されなければならないものである。

まず、リサイズ機構そのものについてさらに詳細に説明する。

無瞬断リサイズ処理は、ＯＴＮのすべてのエンドツーエンドパスにわたってＯＤＵｆｌｅｘクライアントデータレートの増大または減少をサポートすることを可能とするＯＴＮ内のリサイジング機構である。ＯＤＵｆｌｅｘパスは、各送信セグメント上でＨＯ−ＯＤＵエンティティ内のトリビュタリスロット（ＴＳ）のグループ上のＯＴＮ送信セグメントで伝送される。

無瞬断リサイズ機能性は、ターミネーションシンク（Ｔｅｒｍｉｎａｔｉｏｎ Ｓｉｎｋ）機能およびターミネーションソース（Ｔｅｒｍｉｎａｔｉｏｎ Ｓｏｕｒｃｅ）機能を可能とすることに加えて、パケットクライアントに対する関連するアダプテーションのほか、個々の送信セグメントと比較したエンドツーエンドＯＤＵｆｌｅｘレートの増大に加えて、上位送信セグメントのこのサーバ能力の無瞬断増大縮小を可能とする。

パケットクライアントＢＷは、パケットストリームを個々のＯＤＵｆｌｅｘに適合するために、ＧＦＰ（Ｇｅｎｅｒｉｃ Ｆｒａｍｉｎｇ Ｐｒｏｃｅｄｕｒｅ）カプセル化を用いてカプセル化されている。リサイズ可能なＯＤＵｆｌｅｘ（ＧＦＰ）は、サーバセグメントの各リンク上で同数のトリビュタリスロットを占有する。帯域幅調整（すなわち増大または減少）の場合、リサイズされたＯＤＵｆｌｅｘ（ＧＦＰ）によってトラバースされる各リンク上で同数のトリビュタリスロットが備えられていなければならない。

これが、２ステップに組織化されたプロトコルおよびそれに関連する通信を形成する。これらのステップは、２つのプロトコル部すなわちＬＣＲ（リンクコネクションリサイズ；Ｌｉｎｋ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｉｚｅ）プロトコル部およびＢＷＲ（帯域幅リサイズ；Ｂａｎｄｗｉｄｔｈ Ｒｅｓｉｚｅ）プロトコル部において反映される。

ＬＣＲフェーズの間、伝送されるＯＤＵｆｌｅｘの伝送に用いられる上位ＯＤＵリンクコネクションのサーバトリビュタリスロット容量を構築する個々のリンクがリサイズされ、一方、ＢＷＲ部においては、ＯＤＵｆｌｅｘ容量そのものがリサイズされる。異なるプロトコルステップに対して関連するネットワーク要素機能の間の通信のため、交換すべき異なる特定のオーバーヘッド情報が定義されかつ必要となる。

ＬＣＲプロトコル部は図１においてより一層詳細に示されているところ、同図は、勧告Ｇ．７０４４図６−４「ＬＣＲプロトコル」から採用されたものであり、また、ＢＷＲプロトコル部は、ＩＴＵ−Ｔ Ｒｅｃ．７０４４の図６−５「ＢＷＲプロトコル」から採用された図２においてより一層詳細に示されている。両図は、３つの相互接続されたネットワークノードＡ、ＢおよびＣと、それに伴うそれらのターミネーション機能およびアダプテーション機能を示している。ＯＤＵｆｌｅｘコネクションは、ノードＡおよびノードＣの間に、ノードＢをこえて存在していると想定している。送信は双方向性通信であって、すべての機能は受信方向および送信方向において機能要素を有している。ターミネーション機能は例えば、各別に終端されるエンティティ（ＯＤＵｋ、ＯＴＵｋ等）を生成する送信機能と、各エンティティを受信および処理する受信側機能とを有している。

ノードＡにおいては、上から下へ順に、パケットレイヤソース／シンク機能１０と、パケットレイヤからＯＤＵｆｌｅｘへのアダプテーション機能１１と、ＯＤＵｆｌｅｘターミネーション機能１２と、ＯＤＵｆｌｅｘからＨＯ−ＯＤＵｋへのアダプテーション機能１３と、ＨＯ−ＯＤＵｋターミネーション機能１４と、ＯＤＵｋからＯＴＵｋへのアダプテーション機能１５と、ＯＴＵｋターミネーション機能とが備えられている。

同様にノードＣは、ネットワークノードＡにおける対応する機能ブロックと区別するために参照符号１０’−１６’を付した同じ機能ブロックを有している。

ノードＢは、下位（ＬＯ）ＯＤＵ相互接続機能２０と、ＯＤＵｆｌｅｘからＨＯ−ＯＤＵｋへのアダプテーション機能２１、２１’と、ＨＯ−ＯＤＵｋターミネーション機能２２、２２’と、ＯＤＵｋからＯＴＵｋへのアダプテーション機能２３、２３’と、ＯＴＵｋターミネーション機能２４、２４’とを有している。

光リンクは、インタフェースＡ１およびインタフェースＢ１の間でノードＡおよびノードＢを相互に接続し、インタフェースＢ２およびインタフェースＣ１の間でノードＢおよびノードＣを相互に接続する。ノードＡおよびノードＢの間のＯＤＵｆｌｅｘコネクションを確立するために、相互接続機能２０は、対応するトリビュタリスロットを相互接続するクロスコネクションをインタフェースＢ１からインタフェースＢ２へ切り替える必要がある。

本実施形態においては、ノードＡ、ＢおよびＣの間のリンクは、ＯＤＵ３リンクである。各ＯＤＵ３は、３２個の１，２５ＧトリビュタリスロットをもつペイロードユニットＯＰＵ３を有している。ＯＤＵｆｌｅｘコネクションは当初は２つのトリビュタリスロット（ＴＳ）を占有している。前述のとおり、ＯＰＵ３内におけるタイムスロット割当ては任意になされる。そのため、一例として、ノードＡおよびノードＢの間のリンク上では、トリビュタリスロットＴＳ３およびＴＳ１２が割り当てられている一方、ノードＢおよびノードＣの間のリンク上では、トリビュタリスロットＴＳ５およびＴＳ８が割り当てられている。これは図１に反映されている。

リンクコネクションリサイズプロトコル機能概要

増大用ＬＣＲプロトコルは、増大用ＯＤＵｆｌｅｘのためのサーバとして用いられるトリビュタリスロット（ＴＳ）の数を増大させるためにＨＯ−ＯＤＵセクションで初期化された後は独立的に実行される。この増大が完了すると、当該完了はエンドポイントにシグナリングされ、ＯＨ信号に基づくエンドツーエンドＯＤＵｆｌｅｘの接続性チェックは、完了の確認に成功する。

ＯＤＵｆｌｅｘレートの減少については、ＬＣＲプロトコルは、エンドツーエンドＢＷＲプロトコルによって実行されるＯＤＵｆｌｅｘ帯域幅の減少が個々のセクションへのＯＨ通信を介して確認されるまで一時停止する。これは、その後、不要となったトリビュタリスロット（ＴＳ）の削除のために上位ＯＤＵ単位のリンクプロトコルをトリガする。すべての関係するエンティティへのエンドツーエンドの確認がこのプロトコルを完了させる。

再び図１に戻ると、既存のＯＤＵｆｌｅｘコネクションは、２つのトリビュタリスロットによってその容量を増大させるためにリサイズされなければならないと仮定する。このＬＣＲフェーズの間、トリビュタリスロットＴＳが割り当てられなければならない。リサイズプロトコルは、ノードＡおよびノードＢの間のリンク上の隣接するＯＤＵｆｌｅｘアダプテーション機能１３および２１の間で動作し、かつ、ノードＢおよびノードＣの間のリンク上の隣り合うＯＤＵｆｌｅｘアダプテーション機能２１’および１３’の間で動作する。ＬＣＲフェーズの結果、トリビュタリスロットＴＳ５およびＴＳ９がノードＡおよびノードＢの間のリンク上に追加され、また、トリビュタリスロットＴＳ１１およびＴＳ１２がノードＢおよびノードＣの間のリンク上に追加される。加えて、インタフェースＢ１からのＴＳ５およびＴＳ９と、インタフェースＢ２上のトリビュタリスロットＴＳ１１およびトリビュタリスロットＴＳ１２との間で接続機能２０を介してクロスコネクションが確立される。

帯域幅リサイズプロトコル概要

ＢＷＲプロトコルはエンドツーエンドでＯＤＵｆｌｅｘ上で実行され、増大方向では、ＬＣＲプロトコルの完了と、必要な数のタイムスロットのエンドツーエンド接続性チェックの成功と、のシグナリングによってトリガされる。この確認の後、ＢＷＲ増大処理が開始されて、ＯＤＵレートが必要目標値になるように増大される。これは、その後、エンドツーエンドでシグナリングされて、確認後、プロトコルは完了する。

減少方向では、エンドツーエンドのＢＷＲはまずＯＤＵｆｌｅｘ容量およびレートを減少させてから、その後、この完了がリンクコネクションレイヤに伝達されて、影響を受けたタイムスロットの削除を行うために減少用ＬＣＲがトリガされる。

再び図２に戻ると、ＢＷＲプロトコルは、ノードＡおよびノードＣにおいて、それぞれ、ＯＤＵｆｌｅｘアダプテーション機能１１およびＯＤＵｆｌｅｘアダプテーション機能１１’の間で行われる。ＢＷＲプロトコルメッセージフローは、ＯＤＵｆｌｅｘアダプテーション機能１１からＯＤＵｋアダプテーション機能１３へ向かう。プロトコルメッセージはその後、ＯＤＵｋアダプテーション機能１３とＯＤＵｋアダプテーション機能２１との間で中継される。ノードＢ内においては、メッセージフローは下位（ＬＯ）ＯＤＵ接続機能２０を通ってＯＤＵｋアダプテーション機能２１’へ向かう。プロトコルメッセージはその後ＯＤＵｋアダプテーション機能２１’およびＯＤＵｋアダプテーション機能１３’の間で中継され、そして、ノードＣ内では、ＯＤＵｋアダプテーション機能１３’からＯＤＵｋアダプテーション機能１１’へ中継される。

リサイズオーバーヘッド（Ｒｅｓｉｚｅ Ｏｖｅｒｈｅａｄ）

これらのプロセスのため、通信、完了確認および接続性チェックのために伝送され交換されるべきオーバーヘッド信号が定義されて関連ネットワークノードによって処理されなければならない。そこで、上位ＯＤＵｋサーバエンティティとリサイズされた下位（ＬＯ）ＯＤＵｆｌｅｘエンティティとの間に１：１の関係が成り立つと仮定する。プロテクションアーキテクチャの場合、ＬＣＲは、少なくとも２つの組の上位サーバリンクコネクション上で実行されなければならず、また、１組の下位（ＬＯ）ＯＤＵｆｌｅｘターミネーションおよびクライアントアダプテーションへ接続性を通信しおよび確認しなければならない。

増大の際には、ＬＣＲは、当初は、互いに独立なリンク処理によってリンク上で実行されるが、完了については、ＢＷＲプロセスとの通信およびエンドツーエンド接続性チェックが必要となる。減少の場合には、ＬＣＲはまた、各リンクコネクション上にてローカルで実行されるが、ＢＷＲ減少プロセスのエンドツーエンドの完了によってトリガされ、それ以降、エンドツーエンドでの確認後に完了となる。

勧告Ｇ．７０４４に規定するリサイズオーバーヘッド（Ｒｅｓｉｚｅ Ｏｖｅｒｈｅａｄ）は、２つのロケーション、すなわち、個々のリンクコネクションのための上位ＯＰＵオーバーヘッドと、ＯＤＵｆｌｅｘからクライアントへのアダプテーションの間でエンドツーエンドで移動するＯＤＵｆｌｅｘフレームのＯＰＵ部に配置されたＯＰＵｆｌｅｘオーバーヘッドと、に存在している。これは図３に示されており、同図はＩＴＵ−Ｔ勧告Ｇ．７０４４の図６−２と同じ図である。ＯＤＵｆｌｅｘを搬送するＨＯ−ＯＤＵｋの経路オーバーヘッドにおけるリサイズオーバーヘッド部、すなわち、ＨＯ ＯＰＵｋ ＯＨは、ＲＣＯＨ１およびＲＣＯＨ２のビット位置１において、それぞれ、２つの関連信号ＲＰおよびＴＳＣＣを含み、これらはＢＷＲプロトコルの一部である。

リンクコネクションのＨＯ ＯＰＵオーバーヘッドのために勧告Ｇ．７０４４に規定するこの通信のためのオーバーヘッド位置と、勧告Ｇ．７０４４に規定するこれらのビットの関連する機能とは、以下のとおりである。

・コントロール（ＣＴＲＬ）フィールド
コントロール（ＣＴＲＬ）フィールドは、ソースからシンクへＬＣＲプロトコルステータス情報を転送するために用いられるビットである。ＣＴＲＬフィールドは、指定されたものに属する個々のトリビュタリスロットの動作表示を提供するために用いられる。これは、ＯＤＵｆｌｅｘサーバセクションごとのＬＣＲシグナリングに関連するものであり、特定のサーバリンクコネクション上においてローカルで動作する。それゆえ、プロテクションアーキテクチャに関する特別な処理は必要ではない。

・トリビュタリポートＩＤ（ＴＰＩＤ）フィールド
ＴＰＩＤフィールドは、トリビュタリポート（ｔｒｉｂｕｔａｒｙ ｐｏｒｔ）ＩＤを識別するために用いられるビットである。ＴＰＩＤフィールドは、トリビュタリスロットが追加または削除されるべきトリビュタリポート番号を表す。これは、ＯＤＵｆｌｅｘサーバセクションごとのＬＣＲシグナリングに関連するものであり、特定のサーバリンクコネクション上においてローカルで動作する。それゆえ、プロテクションアーキテクチャに関する特別な処理は必要ではない。

・トリビュタリスロットグループステータス（ＴＳＧＳ）ビット
ＴＳＧＳ（ｔｒｉｂｕｔａｒｙ ｓｌｏｔ ｇｒｏｕｐ ｓｔａｔｕｓ）ビットは、リンクコネクション確認応答表示のために用いられるビットである。帯域幅増大の場合においては、ＴＳＧＳビットは、受信されたＣＴＲＬおよびＴＰＩＤによって追加されるべきものとして表示されたトリビュタリスロットと、シンクエンド側で（管理プレーンまたは制御プレーンによって）備えられているトリビュタリスロットとの間がマッチがしていることをＨＯ ＯＰＵソースに対して確認応答するためにＨＯ ＯＰＵシンクによって生成される。ＴＳＧＳビットは、さらにＨＯ ＯＰＵシンクエンドがＯＤＴＵｋ．Ｍを増大させてＯＤＴＵｋ．Ｍ＋Ｎとする増大を受け入れる準備ができていることを確認応答する。帯域幅減少の場合においては、ＯＤＵｆｌｅｘ（ＧＦＰ）帯域幅が減少されたことと、ＨＯ ＯＰＵシンクがソースからシンク（Ｓｏ ｔｏ Ｓｋ）の方向でＴＳＣＣ＝０を受信後、ＧＭＰ特殊モードを終了したことをＨＯ ＯＰＵソースに対して確認応答するために、ＴＳＧＳビットがＨＯ ＯＰＵシンクによって生成される。ＴＳＧＳビットはさらに、ＨＯ ＯＰＵシンクエンドがＯＤＴＵｋ．Ｍを減少させてＯＤＴＵｋ．Ｍ−Ｎとする減少を受け入れる準備ができていることを確認応答する。これは、ＯＤＵｆｌｅｘサーバセクションごとのＬＣＲシグナリングに関連するものであり、特定のサーバリンクコネクション上においてローカルで動作する。それゆえ、プロテクションアーキテクチャに関する特別な処理は必要ではない。

・トリビュタリスロット接続性チェック（ＴＳＣＣ）ビット
ＴＳＣＣ（Ｔｒｉｂｕｔａｒｙ Ｓｌｏｔ ｃｏｎｎｅｃｔｉｖｉｔｙ ｃｈｅｃｋ）ビットは、リンクコネクションおよびＯＤＵｆｌｅｘ（ＧＦＰ）接続の接続性をチェックするために用いられるビットである。ＴＳＣＣビットは、追加または削除されるトリビュタリスロット（ＴＳ）に関連するシグナリング情報を担い、ソースからシンクへホップバイホップで伝播される。初期状態ではＴＳＣＣの値は０に設定されている。リサイズ期間の間、ＴＳＣＣ＝１は中間ノードにおけるＧＭＰ特殊モードを確認し、かつ、ソースからシンク方向におけるすべてのＮＥが帯域幅リサイジング処理をサポートする準備ができていることをシンクに対してシグナリングする。

ＯＤＵｆｌｅｘ（ＧＦＰ）リサイズ処理の完了後、帯域幅リサイズ完了およびソースからシンク方向におけるＧＭＰ特殊モードの終了を示すためにＴＳＣＣ＝０がソースによって用いられる。ＴＳＣＣ＝０は、中間ノードおよびシンクにおけるＧＭＰ特殊モードの終了をトリガし、それらがＧＭＰ特殊モードを終了したときにのみ中間ノードによって転送される。

上位リンクのこのビットは、リサイズされる予定のＯＤＵｆｌｅｘレイヤへのリンクコネクションレイヤの確認として用いられ、これは、個々のリンクコネクションの容量変更が完了したことと、ＨＯ接続上でエンドツーエンドで必要な容量が利用可能であることを確認するためである。これは、ＯＤＵｆｌｅｘのリサイズプロセスの開始の可能性を示し、また、プロテクションアーキテクチャの場合において関連性を有する。

・リサイジングプロトコルインジケータ（ＲＰ）ビット
ＲＰ（Ｒｅｓｉｚｉｎｇ ｐｒｏｔｏｃｏｌ ｉｎｄｉｃａｔｏｒ）ビットは、リサイジングプロトコルがＲＣＯＨに担われているか否かを表すために用いられるビットである。ＲＰ＝１は、ＲＣＯＨにリサイジングプロトコルが担われていることを示す。ＲＰ＝０の場合、これらのバイトは勧告Ｇ．７０９に規定されるようなＧＭＰオーバーヘッド（ＣｎＤ）など、具体的情報をマッピングすることと関連するオーバーヘッドを担う。リサイズ処理の開始時においては、ＲＰビットは管理プレーンまたは制御プレーンによって１に設定されるべきである。ＲＰビットは、それがすべてのリサイジングプロトコル処理を終了したことを示すために、以下に示すように、ソースによって０にリセットされる。ＲＰ＝０は中間ノードにおける当該方向におけるＴＳＣＣ情報の中継とすべての他のリサイジング処理動作とを終了させる。中間ノードがＲＰ＝０を受信すると、中間ノードは、ＧＭＰ特殊モードを終了して当該方向でのＬＣＲプロトコル処理を終了したことを確認した後で、ＲＰ＝０を転送する。シンクがＲＰ＝０を受信すると、シンクはソースおよびすべての中間ノードによるリサイジング処理の終了を確認する。そして、シンクはネットワーク管理または制御プレーンへリサイジング完了を報告することができる。

上位リンクのこのビットは、すべての関与する機能から／へ、リサイズ処理における関連するステータスに移行したことを通信するための手段として用いられるビットである。このビットはまた、現用パスおよび保護パスにおける機能からの関連性を有し、そして、このビットは個々のリンクコネクションにおいて搬送される一方、リンクコネクションレイヤの現用ＨＯ−ＯＤＵエンティティおよびプロテクションＨＯ−ＯＤＵエンティティに関連するとともに、ＯＤＵｆｌｅｘターミネーションおよびクライアントアダプテーションと関連性がある。それゆえ、結果として、この位置もまたプロテクションアーキテクチャにおいて特別な処理を必要とする。

ＯＤＵｆｌｅｘトレイルのＬＯ ＯＰＵｆｌｅｘオーバーヘッドに係る勧告Ｇ．７０４４に規定するこの通信に係るオーバーヘッド位置は以下のとおりである。

・ネットワーク接続ステータス（ＮＣＳ）ビット
ＮＣＳ（ｎｅｔｗｏｒｋ ｃｏｎｎｅｃｔｉｖｉｔｙ ｓｔａｔｕｓ）ビットは、ネットワーク接続確認応答表示のために用いられるビットである。ＮＣＳビットは、ＯＰＵｆｌｅｘオーバーヘッドにおけるエンドツーエンドの確認応答表示として定義される。ＮＣＳビットは、シンクが正しいＴＳＣＣ値を受信した場合にＯＤＵｆｌｅｘ（ＧＦＰ）ソースに対して直接的に確認応答を行うために、ＯＤＵｆｌｅｘ（ＧＦＰ）シンクによって用いられる。この信号は中間ノードからみて透過的であるので、中間ノードではこの信号を処理する必要はない。シンクがＴＳＣＣ＝１を受信すると、ソースに対するシンクパスリサイズ準備完了のＡＣＫとして、シンクによってＮＣＳ＝１が用いられる。シンクがＴＳＣＣ＝０を受信すると、ＢＷＲ完了の確認応答を行うために、シンクによってＮＣＳ＝０が用いられる。ＮＣＳは各中間ノードを透過的に通過してソースへ戻る。

これは、ＯＤＵｆｌｅｘを介してエンドツーエンドで移動し、クライアントアダプテーションを伴う。リンクコネクションがこの情報に依存していないので、プロテクションの場合における特別な処理は必要でない。しかしながら、すべての機能は、この信号の暗黙的ブリッジングに起因して、読取りおよび反応を行うことができる。

・帯域幅リサイズインジケータ（ＢＷＲ＿ＩＮＤ）ビット
ＢＷＲ＿ＩＮＤ（ｂａｎｄｗｉｄｔｈ ｒｅｓｉｚｅ ｉｎｄｉｃａｔｏｒ）ビットは、ＯＤＵｆｌｅｘ（ＧＦＰ）ソースがＯＤＵｆｌｅｘ（ＧＦＰ）信号のビットレートを調整していることを示すために用いられるビットである。ＢＷＲ＿ＩＮＤビットは、ＯＤＵｆｌｅｘ（ＧＦＰ）信号のビットレート調整が開始する前に「０」に設定される。ひとたびＢＷＲ＿ＩＮＤビットが「０」から「１」へ遷移すると、ＯＤＵｆｌｅｘ（ＧＦＰ）ソースは、ｘμｓ後にランピング（ｒａｍｐｉｎｇ）を開始する。ＢＷＲ＿ＩＮＤが「１」から「０」へ遷移すると、ＯＤＵｆｌｅｘ（ＧＦＰ）ソースは、ｙμｓ後にランピングを停止する。ｘはほぼｙに等しく、１２５μｓないし２５０μｓの範囲である。

ＢＷＲ＿ＩＮＤは、ダウンストリームノードでのランプの開始をトリガするために用いられ、また、ランプの終了をシグナリングするために用いられる。これは、勧告Ｇ．７０４４、第７．１．１章および第７．２．１章により詳細に記述されている。

ＢＷＲ＿ＩＮＤ信号は、図３に示すように、ＯＤＵｆｌｅｘ（ＧＦＰ）ＲＣＯＨ１およびＲＣＯＨ２バイト双方のビット１にエンコードされる。ＢＷＲ＿ＩＮＤがセットされると、両ビットは「１」となり、ＢＷＲ＿ＩＮＤがリセットされると両ビットは「０」になる。受信側はＲＣＯＨ３を検証した後、ＢＷＲ＿ＩＮＤステートの遷移を決定する。ＣＲＣ−３値がＲＣＯＨ１またはＲＣＯＨ２におけるＢＷＲ＿ＩＮＤビットに影響を及ぼすエラーの検出を可能とし、正しい値の決定に用いられることができる。受信側ルールは以下のとおりである。

ＲＣＯＨ１とＲＣＯＨ２との両方におけるＢＷＲ＿ＩＮＤビットが「１」に設定されておりかつ受信されたＣＲＣ−３が「１」に設定されたＢＷＲ＿ＩＮＤ（および「１」に設定されたＮＣＳ）を送信したソースに対応する値をもつ場合には、受信側は、ＲＣＯＨ１ないしＲＣＯＨ３を検証後、ＢＷＲ＿ＩＮＤがセットされていると決定する。

ＲＣＯＨ１とＲＣＯＨ２との両方におけるＢＷＲ＿ＩＮＤビットが「０」に設定されておりかつ受信されたＣＲＣ−３が「０」に設定されたＢＷＲ＿ＩＮＤ（および「１」に設定されたＮＣＳ）を送信したソースに対応する値をもつ場合には、受信側は、ＲＣＯＨ１ないしＲＣＯＨ３を検証後、ＢＷＲ＿ＩＮＤがリセットされたと決定する。そうでない場合には、受信側は受信されたＢＷＲ＿ＩＮＤについてその現在値を維持する。

これは、ＯＤＵｆｌｅｘを介してエンドツーエンドで移動し、クライアントアダプテーションを伴う。リンクコネクションがこの情報に依存していないので、プロテクションの場合における特別な処理は必要でない。しかしながら、すべての機能は、この信号の暗黙的ブリッジングに起因して、読取りおよび反応を行うことができる。

これらのポジションに関する情報は、ＯＰＵオーバーヘッドフィールドに付加されたＣＲＣ符号によってエラーから保護される。

容量増大（Ｃａｐａｃｉｔｙ Ｉｎｃｒｅａｓｅ）

容量増大は、まずすべてのリンクがリンク容量ＬＣＲプロトコル部を増大させ、その後これに成功してＯＤＵｆｌｅｘトレイルエンドポイント間で確認された場合、ＢＷＲが開始する、というように原則的に処理される。これは、リンク容量が完全に増大された後で、帯域幅リサイズが開始されてエンドツーエンドで処理されるということを意味する。ＬＣＲは、エンドツーエンドＢＷＲプロトコルの前提条件として、各ＨＯリンクコネクションについて独立である。

勧告Ｇ．７０４４に記述されるＬＣＲ増大の記述内容は以下により一層詳細に説明される。

１．各ノードは、ネットワーク管理または制御プレーンのＩＮＣＲＥＡＳＥコマンドを受信後、ＬＣＲプロトコルおよびＢＷＲプロトコルを開始する。ＩＮＣＲＥＡＳＥコマンドをネットワーク管理または制御プレーンから受信後、各ノードは（ＥＭＦに）追加されるべきＴＳの可用性をチェックする。可用性チェック後、各中間ノードにおける各ポートは、ＲＰ＝１およびＴＳＣＣ＝０（ＢＷＲリレージェネレータ（ＢＷＲ Ｒｅｌａｙ Ｇｅｎｅｒａｔｏｒ））とあわせて［ＡＤＤ，♯ａ，ＮＡＣＫ］（ＬＣＲジェネレータ（ＬＣＲ Ｇｅｎｅｒａｔｏｒ））を送信する。２つのエンドノードにおけるポートはＲＰ＝１およびＴＳＣＣ＝０（ＢＷＲ Ｒｅｌａｙ Ｇｅｎｅｒａｔｏｒ）とあわせて［ＡＤＤ，♯ａ，ＮＡＣＫ］（ＬＣＲ Ｇｅｎｅｒａｔｏｒ）を送信する。

２．ＣＴＲＬ＝ＡＤＤがスパンの他端のポートから受信されたこと（ＬＣＲ Ｇｅｎｅｒａｔｏｒ）と、ローカルポートのトリビュタリスロット（ＴＳ）構成が、当該スパンの他端のポートにおいてシグナリングされたものと同一であること（ＲＣＯＨ Ｒｅｃｅｉｖｅｒ）とをチェック後、各ポートは、応答として隣接ポートへＴＳＧＳ＝ＡＣＫ信号（ＬＣＲ Ｇｅｎｅｒａｔｏｒ）を送信する。

３．各ポートは、ＬＣＲハンドシェイクが両方向で成功した後で、つまり、同じリンクコ
ネクションリサイズに関与しているすべてのＴＳ上でコンフィギュレーションチェックが通過されてＴＳＧＳ＝ＡＣＫが送信（ＬＣＲ Ｇｅｎｅｒａｔｏｒ）されかつ受信（ＬＣＲ Ｒｅｃｅｉｖｅｒ）された後で、リンクコネクション増大プロセスを開始する。追加されたトリビュタリスロット（ＴＳ）すべてについてＡＣＫを受信した後、ポートは、まず、ＬＣＲハンドシェイク後のリサイズマルチフレームバウンダリで追加されたトリビュタリスロット（ＴＳ）の各々に対して［ＡＤＤ，♯ａ，ＡＣＫ］に代えて［ＮＯＲＭ，♯ａ，ＡＣＫ］を送信する。ノードがすべてのトリビュタリスロット（ＴＳ）についてＡＣＫを受信してから、ノードが［ＮＯＲＭ，♯ａ，ＡＣＫ］を送信し始めるリサイズマルチフレームバウンダリまでの時間は、実装態様に依存して決まることに留意すべきである。その後、［ＮＯＲＭ，♯ａ，ＡＣＫ］送信後最初のリサイズマルチフレームバウンダリにおいて、ノードはリンクコネクション増大を、すべての追加されたトリビュタリスロット（ＴＳ）を用いて開始する。［ＡＤＤ，♯ａ，ＡＣＫ］から［ＮＯＲＭ，♯ａ，ＡＣＫ］への変化は、リンクコネクション増大が次のリサイズマルチフレームバウンダリで開始するであろうことをダウンストリームポートに対してシグナリングするものである。

４．ＬＣＲリサイズを完了しかつＣＴＲＬ＝ＮＯＲＭを受信後、ノードは、追加されたトリビュタリスロット（ＴＳ）の各々に対してリサイズマルチフレームバウンダリＰにおいて［ＩＤＬＥ，０，ＮＡＣＫ］（ＬＣＲ Ｇｅｎｅｒａｔｏｒ）を送信することで、ＬＣＲプロトコルを終了する。換言すれば、すべての影響を受けるトリビュタリスロット（ＴＳ）がそれらのシグナリング内容の各々を（同じリサイズマルチフレームにおいて）同時的に遷移させる。

５．ＣＴＲＬ＝ＩＤＬＥがスパンの他端のポートから受信されたこと（ＬＣＲ Ｇｅｎｅｒａｔｏｒ）をチェック後、ＬＣＲプロトコルは一方の方向で終了する。ノードはその後ＢＷＲプロトコルを開始する。

この処理は、エンドツーエンドＯＤＵｆｌｅｘトレイルが影響を受ける前に実行され、それゆえ、プロテクションアーキテクチャが存在するか、この時点までに存在していないかの事実によって影響を受けない。

ＬＣＲの完了を確認応答する信号は、ソースエンドポイントにおいて１に設定されるＴＳＣＣ信号であり、ＬＣＲの完了後、ＴＳＣＣはＯＤＵｆｌｅｘトレイルを供するリンク群を介して中継される。保護されたＯＤＵｆｌｅｘトレイルの場合、現用リンクおよび保護リンクの双方がこのＴＳＣＣ確認応答を中継および転送する必要があり、両リンクコネクションがともに増大されることを確保するために、２つのＴＳＣＣ信号がＡＮＤ演算で結合されなければならない。

この後、プロトコルのＢＷＲ部が開始される。ここで、勧告Ｇ．７０４４第７．１節のステップ３、および、さらに詳細な記述が勧告Ｇ．７０４４に規定されているとおり、エンドポイント間でのシグナリングおよびすべての暫定ノードへのシグナリングを介して、帯域幅調整ランプが開始される。

勧告Ｇ．７０４４に規定されるプロトコルのＢＷＲ部の記述内容は以下により一層詳細に説明される。

帯域幅増大用ＢＷＲプロトコルの各ステップは以下のとおりである。

１．ＬＣＲプロトコルが終了しかつシンク方向でＳＣＣ＝１が受信されると、入力ポートは、そのＧＭＰシンクプロセッサを特殊モード（ＢＷＲ Ｒｅｌａｙ Ｒｅｃｅｉｖｅｒ）に設定することを開始する。ＬＣＲプロトコルがソース方向で終了すると、出力ポートはそのＧＭＰソースプロセッサを特殊モード（ＢＷＲ Ｒｅｌａｙ Ｇｅｎｅｒａｔｏｒ）に設定する。ノードは、所与の方向でのＧＭＰ特殊モードに移行する前に、変更に関連する必要な内部バッファ調整をワードサイズで行うと予期されている。これらのＧＭＰシンクおよびソースプロセッサを特殊モードに設定することに成功し、かつ、アップストリームノード群における新しいマトリックス接続と関連するｄＴＩＭ欠陥が存在しないことを確認した後で、ノードはＴＳＣＣ＝１を当該方向において中継し、ＢＷＲプロトコルの持続期間の間（ＴＩＭＡｃｔＤｉｓを用いて）ＴＣＭ ｄＴＩＭ関連の結果として起こるアクションを無効化する。すべての中間ノードがＴＳＣＣ＝１を中継すると、ＴＳＣＣ＝１はソースからシンクへ伝播する。

２．すべての追加されたトリビュタリスロット（ＴＳ）についてのＴＳＣＣ＝１かつＲＰ＝１がＯＤＵｆｌｅｘ（ＧＦＰ）シンクノードに到達すると、入力ポートは、この方向において経路全体がＯＫであることと、その設定が受信されたＴＳＣＣ値（ＲＣＯＨ Ｒｅｃｅｉｖｅｒ）に見出されるトリビュタリスロット（ＴＳ）構成にマッチすることとを示すために、ＮＣＳ＝ＡＣＫ（１）（ＢＷＲ Ｇｅｎｅｒａｔｏｒ）を設定することによって応答する。ＮＣＳはＯＤＵｆｌｅｘ（ＧＦＰ）オーバーヘッドエリア内に配置されているので、ＮＣＳ＝ＡＣＫ（１）は各中間ポートを透過的に通過して最遠のＯＤＵｆｌｅｘ（ＧＦＰ）ノードに戻る。

３．エンドノードがＴＳＣＣ＝１、ＲＰ＝１およびＮＣＳ＝ＡＣＫを受信し、かつ、ＴＳＣＣ＝１に応じてＮＣＳ＝ＡＣＫを送信すると、双方向性シグナリングが完了する。エンドノードはその後、帯域幅増大を開始する。帯域幅増大はＢＷＲ＿ＩＮＤを１に設定することから開始する。増大レートの詳細については７．１．１を参照されたい。帯域幅増大はＢＷＲ＿ＩＮＤを０に設定した後で終了する。

４．ＯＤＵｆｌｅｘ（ＧＦＰ）ソースノードは、の送信方向での帯域幅増大の完了とそのＧＭＰノーマルモードへの復帰をシグナリングするために、ＴＳＣＣ＝１（ＢＷＲ Ｇｅｎｅｒａｔｏｒ）の代わりにＴＳＣＣ＝０の発信を開始する。

５．中間入力ポートがＴＳＣＣ＝０およびＲＰ＝１を受信すると、中間入力ポートはそのＧＭＰシンクプロセッサをノーマルモード（ＢＷＲ Ｒｅｌａｙ Ｒｅｃｅｉｖｅｒ）に設定するとともにＴＳＣＣ＝０を出力ポートへ転送する。帯域幅増大が終了してＴＳＣＣ＝０が受信されると、出力ポートはそのＧＭＰソースプロセッサを今やノーマルモード（ＢＷＲ Ｒｅｌａｙ Ｇｅｎｅｒａｔｏｒ）に設定する。これらのＧＭＰプロセッサをノーマルモードに設定後、ＴＳＣＣ＝０が直ちに当該ノードを介してその方向に中継される。

６．ＴＳＣＣ＝０（ＢＷＲ Ｒｅｃｅｉｖｅｒ）がＯＤＵｆｌｅｘ（ＧＦＰ）シンクに到達すると、関連するＯＤＵｆｌｅｘ（ＧＦＰ）ソースがＮＣＳ＝ＮＡＣＫ（ＢＷＲ Ｇｅｎｅｒａｔｏｒ）を設定することにより応答を送信する。

７．エンドノードがＮＣＳ＝ＮＡＣＫを受信および送信すると、エンドノードは、フレームをＲＰ＝０（ＢＷＲ Ｇｅｎｅｒａｔｏｒ）で送出することを開始する。中間ノードがＲＰ＝０（ＢＷＲ Ｒｅｌａｙ Ｒｅｃｅｉｖｅｒ）を受信すると、中間ノードはＲＰ＝０（ＢＷＲ Ｒｅｌａｙ Ｇｅｎｅｒａｔｏｒ）をダウンストリームノードへ透過的に転送する。ＲＰ＝０がもう一方のエンドノードに伝播される、つまり、中間ノード群がそれらのＴＳＣＣ情報中継とすべての他のリサイジングプロトコル動作とを終了することを示すと、増大動作は完了となる。ＯＤＵｆｌｅｘ（ＧＦＰ）シンクノードがＲＰ＝０を受信しかつ反対方向にＲＰ＝０を送信すると、ＯＤＵｆｌｅｘ（ＧＦＰ）シンクノードは当該方向における増大リサイジングプロセスの完了をネットワーク管理または制御プレーンへ報告する（ＢＷＲ Ｇｅｎｅｒａｔｏｒ）。

８．ネットワーク管理または制御プレーンが両方向の完了表示を受信すると、全体プロセスは、完了する。

ここで、エンドツーエンドシグナリングと接続性チェックとに関連する関連信号が処理され、これらの信号はプロテクションに関して接続機能における特別な処理の対象とされなければならない。

完了成功後、すべてのプロトコルが終了する。エンドツーエンド通信およびターミネーションの確認応答は関連するＯＨ信号を介して関与するノードと機能とへシグナリングされる。ここで、インターレイヤ関係を提供するエンドツーエンド重要信号は、マトリックス接続を通過する中継信号であり、すなわちＴＳＣＣ信号およびＲＰ信号である。ＴＳＣＣおよびＲＰの０への遷移により、プロトコルの完了成功がシグナリングされる（ＩＴＵ−Ｔ勧告Ｇ．７０４４第７．１節におけるＢＷＲ増大のＢＷＲプロトコル記述におけるステップ６、７、８）。

容量減少（Ｃａｐａｃｉｔｙ Ｄｅｃｒｅａｓｅ）

容量減少は、原則的に、まず、どのトリビュタリスロット（ＴＳ）が削除されるべきかに関する情報が利用可能かつ整合性があるか否かに関するチェックが減少するであろうすべてのリンクに対して行われるような態様にて処理される。その後、リンク容量ＬＣＲプロトコル部が一時停止され、ＯＤＵｆｌｅｘトレイルエンドポイント間でＢＷＲが開始して、ＯＤＵｆｌｅｘ帯域幅（ＢＷ）が所要値になるまで減少される。これの完了はシグナリングされ−このシグナリングおよび確認はまた現用リンクおよび保護リンクに関連するプロトコル部である−そして、この完了は、接続機能における処理に関連性を有するものとなる。

ＢＷＲの確認後、容量減少のＬＣＲ部が処理され、現用ＢＷおよび保護ＢＷについてシグナリングされる。完了後、プロトコルを終了させるためにエンドツーエンドシグナリング確認が用いられ、ＯＰＵ ＯＨは、通常動作へ再切り替えされる。勧告Ｇ．７０４４に規定される詳細プロセス記述を以下に説明する。

プロトコルは、減少初期化の後、現用ＢＷおよび保護ＢＷのためのプロテクションアーキテクチャにおいて、ＬＣＲをもって開始する。

本明細書におけるＬＣＲシグナリングは、フォーマット［＜ＣＴＲＬ値＞，＜ＴＰＩＤ♯＞，＜ＴＳＧＳ値＞］を用いる。

１．各ノードは、ネットワーク管理または制御プレーンのＤＥＣＲＥＡＳＥコマンドを受信後、ＬＣＲプロトコルおよびＢＷＲプロトコルを開始する。ＤＥＣＲＥＡＳＥコマンドをネットワーク管理または制御プレーンから受信後、各ノードは（ＥＭＦにおいて）削除されるべきトリビュタリスロット（ＴＳ）の可用性をチェックする。可用性チェック後、各中間ノードにおける各ポートは、ＲＰ＝１およびＴＳＣＣ＝０（ＢＷＲ Ｒｅｌａｙ Ｇｅｎｅｒａｔｏｒ）とあわせて［ＲＥＭ，♯ａ，ＮＡＣＫ］（ＬＣＲ Ｇｅｎｅｒａｔｏｒ）を送信する。２つのエンドノードにおけるポートはＲＰ＝１およびＴＳＣＣ＝０（ＢＷＲ Ｒｅｌａｙ Ｇｅｎｅｒａｔｏｒ）とあわせて［ＲＥＭ，♯ａ，ＮＡＣＫ］（ＢＷＲ Ｒｅｌａｙ Ｇｅｎｅｒａｔｏｒ）を送信する。

２．ＣＴＲＬ＝ＲＥＭがスパンの他端のポートから受信されたこと（ＬＣＲ Ｇｅｎｅｒａｔｏｒ）と、ローカルポートのＴＳコンフィギュレーションが当該スパンの他端のポートにおいてシグナリングしているものと同一であること（ＲＣＯＨ Ｒｅｃｅｉｖｅｒ）とをチェック後、各ポートはそのＧＭＰソースまたはＧＭＰシンクプロセッサを特殊モードに設定する。今や、ＬＣＲプロトコルは一時停止されて、ポートはＢＷＲプロトコルを使って継続する。ＴＳＣＣ＝１を受信後、各入力ポートはそのＧＭＰシンクプロセッサを特殊モードに設定する。

ＴＳＣＣ情報およびＲＰ情報はエンドツーエンドで渡されて、ＯＤＵｆｌｅｘトレイルエンドポイント機能、および、ＯＤＵｆｌｅｘプロテクションの場合における接続機能における特別プロテクション処理のサブジェクトで用いられる。

この後、ＢＷＲ部が開始され、ＯＤＵｆｌｅｘ帯域幅（ＢＷ）が減少されて、プロトコルは下記のように続く。

１．（エンドノード内または中間ノード内の）出力ポートにおけるＬＣＲプロトコルが一時停止されると、出力ポートは、そのＧＭＰソースプロセッサを特殊モード（ＢＷＲ Ｒｅｌａｙ Ｇｅｎｅｒａｔｏｒ）に設定する。ノードは、所与の方向でのＧＭＰ特殊モードに移行する前に、変更に関連する必要な内部バッファ調整をワードサイズで行うと予期されている。ＧＭＰソースプロセッサを特殊モードに設定するのに成功しかつ、アップストリームノード群における新しいマトリックス接続と関連するｄＴＩＭ欠陥が存在しないことを確認した後で、出力ポートは、受信されたＴＳＣＣ＝１を当該方向において中継し（ＢＷＲ Ｒｅｌａｙ Ｇｅｎｅｒａｔｏｒ）、ＢＷＲプロトコルの持続期間の間（ＴＩＭＡｃｔＤｉｓを用いて）ＴＣＭｄＴＩＭ関連の結果として起こるアクションを無効化する。ＴＳＣＣは削除されるべきトリビュタリスロット（ＴＳ）の各々と関連するＨＯ ＯＰＵｋオーバーヘッドにおいて送信される。

２．（エンドノード内または中間ノード内の）入力ポートにおけるＬＣＲプロトコルが一時停止されると入力ポートは、ＴＳＣＣ＝１を受信後、そのＧＭＰシンクプロセッサを特殊モードに設定することを開始する（ＢＷＲ Ｒｅｌａｙ Ｒｅｃｅｉｖｅｒ）。ノードは、所与の方向でのＧＭＰ特殊モードに移行する前に、変更に関連する必要な内部バッファ調整をワードサイズで行うと予期されている。これらのＧＭＰシンクプロセッサを特殊モードに設定することに成功し、かつ、アップストリームノード群における新しいマトリックス接続と関連するｄＴＩＭ欠陥が存在しないことを確認した後で、入力ポートはＴＳＣＣ＝１（ＢＷＲ Ｒｅｌａｙ Ｒｅｃｅｉｖｅｒ）を当該方向において中継し、ＢＷＲプロトコルの持続期間の間（ＴＩＭＡｃｔＤｉｓを用いて）ＴＣＭｄＴＩＭ関連の結果として起こるさらなるアクションを無効化する。

３．すべての中間入力ポートおよび出力ポートがＴＳＣＣ＝１を中継すると、ＴＳＣＣ＝１はソースからシンクへ伝播する。

４．すべての削除されたＴＳについてＴＳＣＣ＝１がＯＤＵｆｌｅｘ（ＧＦＰ）シンクに到達すると、ＯＤＵｆｌｅｘ（ＧＦＰ）シンクは、この方向において経路全体がＯＫであることを示すために、ＮＣＳ＝ＡＣＫ（１）（ＢＷＲ Ｇｅｎｅｒａｔｏｒ）を設定することで応答する。ＮＣＳはＯＤＵｆｌｅｘオーバーヘッドエリアに配置されているので、ＮＣＳ＝ＡＣＫ（１）は各ノードを透過的に通過して最遠端のＯＤＵｆｌｅｘ（ＧＦＰ）エンドノードへ至る。

５．ＯＤＵｆｌｅｘ（ＧＦＰ）エンドノードがＴＳＣＣ＝１とＮＣＳ＝ＡＣＫ（１）との双方を受信しかつ、ＴＳＣＣ＝１に応答してＮＣＳ＝ＡＣＫ（１）を送信すると、双方向シグナリングが完了する。ＯＤＵｆｌｅｘ（ＧＦＰ）エンドノードはその後、帯域幅減少を開始する。帯域幅減少は、ＢＷＲ＿ＩＮＤを１に設定することから開始する。減少レートの詳細については７．２．１を参照されたい。帯域幅減少は、ＢＷＲ＿ＩＮＤを０に設定した後で終了する。

６．ＧＭＰソースプロセッサをノーマルモード（ＢＷＲ Ｒｅｌａｙ Ｇｅｎｅｒａｔｏｒ）へ設定後、ＯＤＵｆｌｅｘ（ＧＦＰ）ソースノードは、その送信方向での帯域幅減少命令の完了とそのＧＭＰノーマルモードへの復帰をシグナリングするために、ＴＳＣＣ＝１（ＢＷＲ Ｇｅｎｅｒａｔｏｒ，ＢＷＲ Ｒｅｌａｙ Ｇｅｎｅｒａｔｏｒ）の代わりにＴＳＣＣ＝０の発信を開始する。

７．中間入力ポートがＴＳＣＣ＝０およびＲＰ＝１を受信すると、中間入力ポートはそのＧＭＰシンクプロセッサをノーマルモード（ＢＷＲ Ｒｅｌａｙ Ｒｅｃｅｉｖｅｒ）に設定するとともにＴＳＣＣ＝０を出力ポートへ転送する。出力ポートはそのＧＭＰソースプロセッサをノーマルモード（ＢＷＲ Ｒｅｌａｙ Ｇｅｎｅｒａｔｏｒ）に設定する。
これらのＧＭＰプロセッサをノーマルモードに設定後、ＴＳＣＣ＝０が直ちに当該ノードを介してその方向に中継される。

８．ＴＳＣＣ＝０がＯＤＵｆｌｅｘ（ＧＦＰ）シンク（ＢＷＲ Ｒｅｃｅｉｖｅｒ）に到達すると、関連するＯＤＵｆｌｅｘ（ＧＦＰ）ソースがＮＣＳ＝ＮＡＣＫ（０）を設定することにより応答を送信する（ＢＷＲ Ｇｅｎｅｒａｔｏｒ）。

９．ＯＤＵｆｌｅｘ（ＧＦＰ）エンドノードがＮＣＳ＝ＮＡＣＫ（０）を受信および送信すると、ＢＷＲプロトコルは、ほとんど完了しており、ＬＣＲプロトコルは再開することができる。

１０．ＯＤＵｆｌｅｘ（ＧＦＰ）エンドノードがＮＣＳ＝ＮＡＣＫを受信および送信すると、当該ノードはＲＰ＝０（ＢＷＲ Ｇｅｎｅｒａｔｏｒ）に設定する。ＢＷＲ Ｒｅｌａｙ ＧｅｎｅｒａｔｏｒはＬＣＲプロトコルが終了するまで、このＲＰ＝０の出力ポートへの転送を禁止する。

１１．ＬＣＲプロトコルがＯＤＵｆｌｅｘ（ＧＦＰ）エンドノードにおいて終了すると、ＯＤＵｆｌｅｘ（ＧＦＰ）エンドノードは、ＲＰ＝０の転送禁止を終了する。中間入力ポートがＲＰ＝０を受信すると（ＢＷＲ Ｒｅｌａｙ Ｒｅｃｅｉｖｅｒ）、中間入力ポートはＲＰ＝０を透過的に関連する出力ポートへ転送する（ＢＷＲ Ｒｅｌａｙ Ｇｅｎｅｒａｔｏｒ）。ＲＰ＝０が最遠端ノードのＯＤＵｆｌｅｘ（ＧＦＰ）に伝播される、つまり、中間ノード群がそれらのＴＳＣＣ情報中継とすべての他のリサイジングプロトコル動作とを終了したことを示すと、増大動作は完了となる。ＯＤＵｆｌｅｘ（ＧＦＰ）シンクノードがＲＰ＝０を受信しかつ反対方向にＲＰ＝０を送信すると、ＯＤＵｆｌｅｘ（ＧＦＰ）シンクノードは当該方向における減少リサイジングプロセスの完了をネットワーク管理または制御プレーンへ報告する（ＢＷＲ Ｇｅｎｅｒａｔｏｒ）。

ＴＳＣＣ情報およびＲＰ情報はエンドツーエンドで渡されて、ＯＤＵｆｌｅｘトレイルエンドポイント機能、および、ＯＤＵｆｌｅｘプロテクションの場合における接続機能における特別プロテクション処理のサブジェクトで用いられる。

ＰＡＵＳＥの終了後かつＢＷＲ減少の完了後のプロトコルのＬＣＲ部は、以下の各ステップにより処理される。これは、リンクコネクション現用リンクおよび保護リンクのための独立のリンクごとの接続であって、ＲＰシグナリングはプロテクションエンドポイントにおいて用いられる。

１．ＢＷＲリレージェネレータ（ＢＷＲ Ｒｅｌａｙ Ｇｅｎｅｒａｔｏｒ）プロセスによってトリガされると、出力ポートがＴＳＧＳ＝ＡＣＫ（１）を送信する。

２．実装に依存して決まる所定時間の経過後、ＣＴＲＬ＝ＲＥＭおよびＴＳＧＳ＝ＡＣＫを送信し、かつ同じ側で、ＣＴＲＬ＝ＲＥＭおよびＴＳＧＳ＝ＡＣＫ（１）を受信すると、ポートは、同じリサイズマルチフレームバウンダリ（ＲＭＦｂｏｕｎｄａｒｙ１）（ＬＣＲ Ｇｅｎｅｒａｔｏｒ）で削除される各トリビュタリスロット（ＴＳ）に対して、［ＮＯＲＭ，♯ａ，ＡＣＫ］を送信する。［ＮＯＲＭ，♯ａ，ＡＣＫ］の送信後、ポートは、ＯＤＵｆｌｅｘ（ＧＦＰ）リンクコネクション減少を行う。［ＲＥＭ，♯ａ，ＡＣＫ］から［ＮＯＲＭ，♯ａ，ＡＣＫ］への変化は、リンクコネクション減少が次のリサイズマルチフレームバウンダリ（ＲＭＦｂｏｕｎｄａｒｙ２）において開始するであろうことをダウンストリームポートに対してシグナリングするものである。

３．ＬＣＲリサイズの完了および削除される各トリビュタリスロット（ＴＳ）についてＮＯＲＭの受信後、実装態様により決まる所定時間が経過した後、ポートはリサイズマルチフレームバウンダリＰで［ＩＤＬＥ，０，ＮＡＣＫ］を削除される各トリビュタリスロット（ＴＳ）に対して送信することによりＬＣＲプロトコルを終了する（ＬＣＲ Ｇｅｎｅｒａｔｏｒ）。

４．ＯＤＵｆｌｅｘ（ＧＦＰ）エンドノード上の出力ポートがＬＣＲプロトコルを完了すると、出力ポートはＲＰ＝０を転送する。

５．中間ノード上の出力ポートは、ＬＣＲプロトコルを終了後、ＲＰ＝０を転送する（ＢＷＲ Ｒｅｌａｙ Ｇｅｎｅｒａｔｏｒ）。入力ポートは、着信するＲＰ＝０を中継する（ＢＷＲ Ｒｅｌａｙ Ｒｅｃｅｉｖｅｒ）。

６．ＯＤＵｆｌｅｘ（ＧＦＰ）エンドノードがＲＰ＝０を受信しかつ反対方向にＲＰ＝０を送信すると、ＯＤＵｆｌｅｘ（ＧＦＰ）エンドノードはその方向における減少リサイジングプロセスの完了をネットワーク管理または制御プレーンに対して報告する。

このシグナリングと、エンドポイント接続機能およびＯＤＵｆｌｅｘトレイルエンドポイントにおけるＯＨ情報の結合された処理とによって、プロトコルの減少部は終了する。

保護切り替えおよびリサイズオーバーヘッド処理

勧告Ｇ．７９８の図１４−９ないし図１４−１３は、プロテクション関連処理機能を示した図である。これらの処理機能の適用は、図４に示すビヘイビアをもたらす。

図４は、双方向１＋１リニアパスプロテクションを示しており、これはＩＴＵ用語としてはＳＮＣ（Ｓｕｂ−Ｎｅｔｗｏｒｋ Ｃｏｎｎｅｃｔｉｏｎ）と呼ばれるものである。第１のネットワークノードにおけるソース機能４０は、ＲＰおよびＴＳＣＣプロトコルビットを生成するとともにこれらとあわせてＯＤＵｆｌｅｘ信号を生成する。第１のネットワークノードの接続機能は、それぞれＲＰビットおよびＴＳＣＣビットをもつＯＤＵｆｌｅｘを現用（Ｗ）セクションターミネーション機能４２とプロテクション（Ｐ）セクションターミネーション機能４３とにブリッジする。セクションターミネーション機能４２、４３は、ＯＤＵｆｌｅｘを、ＨＯ−ＯＤＵｋ上の下位（ＬＯ）ＯＤＵとして、ＯＴＵｋフレーム内にマッピングして、これらを送信する。異なるＨＯ−ＯＤＵｋ／ＯＴＵｋに多重化されて、ＬＯ ＯＤＵｆｌｅｘは、１＋１ＳＮＣの最遠端における目的ノードに到達するまで、２つの冗長なネットワークパス上を、すなわち現用パス４４と保護パス４５とを並列的に移動する。セクションターミネーション機能４６および４７は、信号を受信し、セクションオーバーヘッドを終端させて、ＯＤＵｆｌｅｘならびにそのＲＰおよびＴＳＣＣプロトコルビットをＨＯ ＯＰＵｋ ＯＨから抽出する。信号は、セレクタ４８に供給され、セレクタ４８は現用パスＷからの信号を選択し、また、障害が発生した場合には保護パスＰからの信号を選択するように切り替えを行う。選択されたＯＤＵｆｌｅｘ、ＲＰ信号およびＴＳＣＣ信号は、シンク機能４９に供給される。反対方向の信号フローは、２つのネットワークノードの間でそれらの役割を入れ替えたのと同じである。

帯域幅リサイズ処理を完了するために、ＬＣＲプロトコルを用いたリンクリサイズ処理はそれぞれセクションターミネーション機能４２、４３およびセクションターミネーション機能４６、４７のレベルで行われなければならない。加えて、ＢＷＲプロトコルを用いた帯域幅リサイズ処理はソース機能４０およびシンク機能４９のレベルで行われなければならない。しかしながら、ＢＷＲプロトコルが必要とするＲＰ信号およびＴＳＣＣ信号は、現用パスＷのみから選択されるので、リサイズ処理は、保護パスＰについては完了されることができない。もし保護パスＰのリサイズが、おそらくは利用可能なリソースが不十分なために、失敗した場合には保護系はもはや動作不能となる。

したがって、かかる欠陥を回避するために、本実施形態は、後述する特別な処理を提供する。本実施形態によって提示されるこの解決手段は、ＩＴＵ−Ｔ勧告Ｇ．８７３．１に規定されるリニア１＋１プロテクション、リニア１：１プロテクションおよびシェアド１：ｎプロテクション、ＩＴＵ−Ｔ勧告Ｇ．８７３．２に規定されるシェアドリングプロテクション（Ｓｈａｒｅｄ Ｒｉｎｇ Ｐｒｏｔｅｃｔｉｏｎ；ＳＲＰ）、さらにはＩＩＴＵ−Ｔ ＳＧ１５において現在検討中のシェアドメッシュプロテクション（Ｓｈａｒｅｄ Ｍｅｓｈ Ｐｒｏｔｅｃｔｉｏｎ；ＳＭＰ）を含め、あらゆる種類のプロテクションアーキテクチャに適用可能である。

図５は、リニア１＋１プロテクションのための信号フローおよびリサイズオーバーヘッド処理を示した図である。図４におけるように、第１のネットワークノードと第２のネットワークノードとの間のネットワーク接続は双方向的であって、信号フローおよび信号処理は２つの方向で対称的である。したがって、一方向のみ、すなわち、図５の左から右へのみが記載されている。縦方向のそれぞれＢＷＲおよびＬＣＲを付した両方向矢印は、ＬＣＲプロトコルステージの場合にはセクションを終端させるノード間、ＢＷＲプロトコルステージの場合にはエンドツーエンドでの進行方向および戻り方向（すなわち左から右およびその逆）におけるリサイズオーバーヘッドメッセージの双方向プロトコル交換を表す。

左側ネットワークノードは、ＧＦＰエンコードされたクライアント信号を搬送するＯＤＵｆｌｅｘのためのソース機能５０を含む。ソース機能５０は、ブリッジ機能５１に接続され、ブリッジ機能５１は、ＯＤＵｆｌｅｘソース機能５０から着信するＯＤＵｆｌｅｘ特徴的情報（ＣＩ）信号を２つのＨＯ−ＯＤＵｋソース機能５２、５３へブリッジし、ここで、ＯＤＵｆｌｅｘは、２つの冗長なネットワークパス５４、５５経由の送信のためにＯＤＵｋとして構成されかつ多重化されている。ネットワークパス５４、５５は、１＋１ＳＮＣ（サブネットワーク保護コネクション）のアクティブパスと保護パスとを表す。

右側ネットワークノードにおいては、２つの冗長なＯＤＵｋが、各ＯＤＵｋターミネーション機能５６、５７において受信および終端されており、ＯＤＵｆｌｅｘ特徴的情報（ＣＩ）信号は、それぞれアクティブパス５４および保護パス５５から並行的に受信された２つのＯＤＵｋから抽出されて、セレクタ５８に供給される。セレクタ５８は、通常動作中にはアクティブパス５４から受信された信号を選択し、障害が発生した場合には、保護パス５５から受信された信号に切り替える。

ここで、１＋１保護されたＯＤＵｆｌｅｘコネクションがリサイズされなければならないことが考慮される。ＯＤＵｆｌｅｘ特徴的情報（ＣＩ）に加えて、関連プロトコルメッセージＲＰおよびＴＳＣＣが示されている。

上述のとおり、ＲＰビットは、リサイジングプロトコルがＲＣＯＨに担われていることを示すために用いられるビットである。リサイズ処理の開始当初においては、ＯＤＵｆｌｅｘ ＲＰビットは、ソース機能５０において１に設定されている。すべてのリサイジングプロトコル処理が完了すると、ターミネーション機能５０がＲＰビットを０にリセットする。ＲＰ＝０は、ＴＳＣＣ情報中継と当該方向における中間ノードの他のすべてのリサイジング処理動作を終了させる。

ＴＳＣＣビットは、上位リンクの一部をなしていて、リンクコネクションおよびＯＤＵｆｌｅｘ（ＧＦＰ）接続の接続性をチェックするために用いられる。ＴＳＣＣビットは、追加または削除されるべきトリビュタリスロット（ＴＳ）と関連するシグナリング情報を搬送するためのビットで、ソースからシンクへホップバイホップで伝播される。当初は、ＴＳＣＣの値はＯＤＵｆｌｅｘソース機能５０において０に設定されている。リサイズ期間の間、ＴＳＣＣ＝１は、シンクへのＧＭＰ信号に対して、ソースからシンクに至る経路上のすべてのネットワークノードが帯域幅リサイジング動作をサポートする準備ができていることを確認するものである。ＯＤＵｆｌｅｘ（ＧＦＰ）リサイズ処理が完了した後、ＯＤＵｆｌｅｘソース機能５０は帯域幅リサイズ完了を表示するためにＴＳＣＣを０に設定する。

ＴＳＣＣは、このようにリサイズされるべきＯＤＵｆｌｅｘレイヤに対するリンクコネクションレイヤの確認として用いられ、個々のリンクコネクションの容量変更が完了してＨＯ接続上のエンドツーエンドで必要な容量が利用可能であることを確認するために用いられる。これは、ＯＤＵｆｌｅｘのリサイズプロセスの開始の可能性を示唆する。

保護系の起点としての接続機能５１において、ＲＰおよびＴＳＣＣを含むリサイズプロトコルのリサイズ関連のオーバーヘッド信号は、ＯＤＵｆｌｅｘの特徴的情報（ＣＩ）とあわせてブリッジされる。同じアーキテクチャ、すなわち、ブロードキャストブリッジがＲＰおよびＴＳＣＣについて用いられている。アクティブなＯＤＵｋソース機能５２および保護ＯＤＵｋソース機能５３は、ＯＤＵｆｌｅｘソース機能から受信されたＲＰビットおよびＴＳＣＣビットを、図３に示すＯＰＵｋ ＯＨポジションにおける各リサイズオーバーヘッド内にマッピングする。図１に示すように、パス５４、５５上の中間ネットワークノードは、ＲＰビットおよびＴＳＣＣビットを入力から出力へと中継し、これにより、これらが最終的にＯＤＵｆｌｅｘコネクションを終端している最遠端ネットワークノードに到達する。

このように、ＯＤＵｋシンク機能５６、５７は、ＲＰビットおよびＴＳＣＣビットをそれぞれアクティブパス５４および保護パス５５から受信し、これらの制御ビットを抽出して、後者を接続機能５８へ転送する。

プロテクショングループのシンクエンドを提供する接続機能５８において、ＲＰ信号およびＴＳＣＣ信号は、ＯＤＵｆｌｅｘ特徴的情報（ＣＩ）におけるようにセレクタではなく、ロジック機能６０、６１を用いて組み合わせられる。ロジック機能演算６０、６１の結果はＯＤＵｆｌｅｘターミネーション機能５９に接続する発信方向接続機能インタフェースに供給される。

ネットワークパス５４および５５上のネットワーク要素間のすべてのセクションは、上述したＬＣＲプロトコルを用いて従来の方法に従いリサイズされる。この時点まで、現用エンティティと保護エンティティとの間にＬＣＲフェーズについての相違は存在しない。帯域幅リサイズ処理は、アクティブな現用エンティティおよび保護エンティティについて同一であって、ＯＰＵｆｌｅｘオーバーヘッドにおいて搬送されるＢＷＲプロトコルにおけるＮＣＳビットおよびＢＷＲ＿ＩＮＤビットに関しても同一である。これにより、現用エンティティと保護エンティティとが調整された態様にてリサイズされかつＢＷＲ（帯域幅リサイズプロトコル）があわせてトリガされることが確保され、それゆえどの時点においても同じＢＷが現用および保護エンティティにおいて利用可能であり、また、保護切り替えの場合においても余計な瞬断が発生することがない。

ＯＤＵｆｌｅｘ保護コネクションを終端するネットワークノードにおいては、ロジック機能６０は、アクティブパス５４および保護パス５５からのＲＰビットを終端させる。特に、０から１への状態遷移は、リサイズ処理の開始を表す。ロジック機能６０は、したがって、アクティブパス５４および保護パス５５からの両方のＲＰが０から１への遷移を表す場合にのみ論理１を出力し、それ以外の場合は論理０を出力する。０から１への遷移については、論理演算６０はしたがってＲＰビット出力ステータス生成のために論理ＡＮＤ演算を含んでいてもよい。

反対に、１から０への遷移は、リサイズ処理の終了を表す。ロジック機能６０は、したがって、アクティブパス５４および保護パス５５からのＲＰが１から０への遷移を表す場合にのみ論理１から論理０へ戻ることになり、それ以外の場合は論理１を出力し続けることになる。１から０への遷移については、ロジック機能６０は、したがって、ＲＰビット出力ステータス生成のために論理ＮＯＴＡＮＤ機能を含んでいてもよい。

ここに説明したＴＳＣＣはリンクリサイズ処理の成功完了を表す。したがって、ロジック機能６１は、アクティブパス５４および保護パス５５からのＴＳＣＣが論理１を表す場合のみ、すなわち、ＬＣＲステージの成功完了の場合のみ出力が論理１となるように、論理ＡＮＤ演算を行う。

現用パス５４または保護パス５５のいずれかに対するリサイズに成功しなかった場合（その原因として利用可能なリソースが不十分であることが考えられる）には、ＴＳＣＣ信号およびＲＰ信号は、ＯＤＵｆｌｅｘターミネーション機能５９に到達することはなく、リサイズプロトコル処理は完了されない。これは、現用エンティティ５４または保護エンティティ５５のいずれかにおいてリンクがリサイズされないことを意味する。換言すれば、コネクション５４、５５が双方ともリサイズされるか、そうでなければいずれもリサイズされないので、ＯＤＵｆｌｅｘパスの保護系は常時稼働できる状態に維持される。さらに、コネクション５４、５５の双方に対するリサイズ処理が同期された状態に保持されるので、切り替えを起動させる障害の発生時においても、データ損失が発生しない。

第２の実施形態が図６に示されている。ここに提示される解決手段は、勧告Ｇ．８７３．１に規定されるリニア１：ｎプロテクションに適用可能であるが、また、勧告Ｇ．８７３．２に規定するＯＴＮシェアドリングプロテクション（ＳＲＰ）、あるいはシェアドメッシュプロテクション（ＳＭＰ）の各プロテクションアーキテクチャにも適用可能であるところ、これらのプロテクションアーキテクチャはいずれも、ＯＤＵｆｌｅｘプロテクショングループソースに配置された接続機能には常駐のブリッジが備えられていないアーキテクチャである。

特に、第２の実施形態は、常駐のブリッジが利用可能でなく、それゆえに常駐の保護エンティティも利用可能でないという点で相違している。保護切り替えの場合に、正しいコンフィギュレーションが関連するＨＯ ＬＯ ＯＤＵアダプテーション機能および接続機能内にロードされる。

結果として、ＨＯ ＯＰＵ ＯＨにおけるリサイズシグナリングはＨＯ ＯＰＵ ＯＨにおいてもＬＯ ＯＰＵｆｌｅｘ ＯＨにおいても利用可能でない。したがって、本実施形態は、保護エンティティセクション上において追加的リサイズＯＨチャネルを用いる、そしてこの追加的リサイズＯＨチャネルは、ＨＯ ＯＰＵポジションにおけるリサイズＯＨとは分離されているものである。これは、現行の勧告Ｇ．７０９、勧告Ｇ．８７３．１、勧告Ｇ．８７３．２および勧告Ｇ．７０４４のシグナリングでは予約（リザーブ）および／または未使用のＯＨポジションにおける、ビット志向シグナリングとするか、あるいは、これらの未使用ＯＨポジションの幾つかの上のパケット志向メッセージングチャネルとすることができる。

インアクティブな保護エンティティのためのより一層適切なリサイズシグナリングチャネルは、ＨＯ ＯＤＵセクションのリサイズＯＨのパケットカプセル化を用いるとともに、それを、通信中のＯＴＮネットワーク要素のＨＯ−ＯＤＵから下位（ＬＯ）ＯＤＵへのアダプテーションと関連するネットワーク要素におけるマトリックス接続とをエミュレートするリサイズＯＨプロセッサ内に供給する、メッセージ志向チャネルオプションとされてもよい。これは、この処理がタイムクリティカルな処理ではなく、情報ステータスの変化に大部分が関連しているという事実ゆえに可能となるものである。

このチャネルの正確なフォーマットおよびサーバビット位置は、二次的な重要性をもつ事項であって、必要に応じて当業者により適宜選択されるべき事項である。例えば追加的リサイズオーバーヘッドチャネルは管理通信帯域幅の一部を用いることができる。

また、ＧＭＰ（Ｇｅｎｅｒｉｃ Ｍａｐｐｉｎｇ Ｐｒｏｃｅｄｕｒｅ）のためのＢＷＲ容量ランプ（ｃａｐａｃｉｔｙ ｒａｍｐ）がリサイズ処理機能においてエミュレートされる。保護されたＯＤＵｆｌｅｘの「Ｎ」個のインスタンスごとにマッピングされるべき信号は、勧告Ｇ．７０４４に規定されるＯＨ信号である。それらのビットは、ＨＯ−ＯＰＵおよびＯＤＵｆｌｅｘリサイズＯＨに担われるとともに利用可能な暫定ノード構成の正しい処理のために暫定ノードにおいて利用可能とされるべき信号群の完全なセットをなす。

追加的リサイズオーバーヘッドチャネル経由で伝送される必要があるオーバーヘッド信号は、特に、ＨＯ ＯＰＵｋ ＯＨのＲＣＯＨ１位置からはＲＰビットおよび４つのＴＰＩＤビット；ＨＯ ＯＰＵｋ ＯＨのＲＣＯＨ２位置からは、ＴＳＣＣビット、ＴＳＧＳビットおよび２つのＣＴＲＬビットおよびＴＰＩＤビット；ＯＰＵｆｌｅｘオーバーヘッドからは、ＲＣＯＨ１に担われるＢＷＲ＿ＩＮＤ；およびＲＣＯＨ２位置において搬送されるＢＷＲ＿ＩＮＤビットおよびＮＣＳビットである。

それゆえこの観点から、ＯＤＵｆｌｅｘプロテクションのための追加的リサイズＯＨチャネルは、ＯＰＵｆｌｅｘから、ＲＣＯＨ、ＲＣＯＨ１からＢＷＲ＿ＩＮＤビット；ＲＣＯＨ２からＢＷＲ＿ＩＮＤビットおよびＮＣＳビットを搬送しなければならず、また、ＲＣＯＨ３に定義されたＣＲＣ−３と同一または同等の誤り検出をサポートしなければならず、また、ＨＯ ＯＰＵｋ ＯＨのＲＣＯＨ１の位置からは、ＲＰビットおよび４つのＴＰＩＤビットを、ＲＣＯＨ２の位置からはＴＳＣＣビットおよびＴＳＧＳビットを、ＲＣＯＨ３の位置については、２つのＣＴＲＬビットおよびＴＰＩＤビットを搬送しなければならず、そして、勧告Ｇ．７０４４において規定されかつ勧告Ｇ．７０４４の図６−２−ＲＣＯＨフォーマットに示されるＣＲＣ３およびＣＲＣ−５と同一または同等の誤り検出をサポートしなければならない。

図６においても、図４および図５と同様、第１のネットワークノードと第２のネットワークノードとの間のネットワーク接続は双方向であって、信号フローおよび処理は２つの方向で対称的である。したがって、一方向のみ、すなわち、図６の左から右へのみが以下にさらに詳述されている。図５におけると同様、縦方向のそれぞれＢＷＲおよびＬＣＲを付記した両方向矢印は、ＬＣＲプロトコルステージの場合にはセクションを終端させるノード間、ＢＷＲプロトコルステージの場合にはエンドツーエンドでの進行方向および戻り方向（すなわち左から右およびその逆）におけるリサイズオーバーヘッドメッセージの双方向プロトコル交換を表す。

左側ネットワークノードは、ＧＦＰエンコードされたクライアント信号を搬送するＯＤＵｆｌｅｘのためのソース機能７０を含む。ソース機能７０は、接続機能７１に接続され、接続機能７１は、ＯＤＵｆｌｅｘソース機能７０から着信するＯＤＵｆｌｅｘ特徴的情報（ＣＩ）信号をＨＯ−ＯＤＵｋソース機能７２へ接続し、ここで、ＯＤＵｆｌｅｘは、ネットワークパス７４経由の送信のためにＯＤＵｋとして構成されかつ多重化されている。冗長な保護ネットワークパス７５が存在するが、現時点ではＯＤＵｆｌｅｘソース７０に接続されていない。反対に、保護パス７５は、アクティブパス５４からの保護切り替えが開始される前にアクティブパス７４上で障害が発生した場合に、プリエンプトされなければならない優先度の低いトラヒック信号８２を送信するために用いることができる。例えば、ネットワークパス７４、７５は、１＋１ＳＮＣ（サブネットワーク保護コネクション）のアクティブパスおよび保護パスを表すことができる。したがって、ＯＤＵｋソース機能７３は、接続機能７１を介してソース（図示せず）または低優先度トラヒック信号８２に接続されている。

ＯＤＵｆｌｅｘソース７０からのＲＰ信号およびＴＳＣＣ信号は、ＯＤＵｋソース７２に接続されており、リサイズＯＨプロセッサ８３へブリッジされ、このリサイズＯＨプロセッサ８３はＯＤＵｆｌｅｘリサイズ情報を別のリサイズＯＨチャネル内に組み込み、後者をＯＤＵｋソース７３を介して送出方向ＨＯ−ＯＤＵｋ内へマッピングする。

保護系の起点としての接続機能７１において、リサイズプロトコルのリサイズ関連オーバーヘッド信号、すなわち、ＯＤＵｆｌｅｘ＜ｎ＞のＯＤＵｋ＿ＣＩ＿ＲＰおよびＯＤＵｋ＿ＣＩ＿ＴＳＣＣは、保護エンティティのリサイズＯＨチャネル内にブリッジされるが、このリサイズＯＨチャネルは他のトラヒックのために現在使用されていてもよい。ＯＤＵｆｌｅｘの特徴的情報（ＣＩ）はアダプテーション機能７３に常にブリッジされているわけではなく、プロテクションプロトコルから要求があった場合にのみブリッジされる。

ネットワークパス７４、７５がそれぞれＯＤＵｋターミネーション機能７６、７７で終端されている右手側ネットワークノードにおいては、ＯＤＵｆｌｅｘの特徴的情報（ＣＩ）信号は、アクティブパス７４から受信されたＯＤＵｋから抽出され、接続機能７８に供給される。内部接続機能７８のセレクタ８５は、通常動作の間、アクティブパス７４から受信された信号を選択し、障害が発生した場合には、このパスのトラヒックがプリエンプトされて左側ノード側の切り替えが適切なプロテクションプロトコルを用いてシグナリングされた後で、保護パス７５から受信された信号に切り替える。余剰トラヒック信号を保護パス７５から通常動作で選択し当該信号を適切な出力に接続するセレクタ８６は、同時に、保護パス７５からのＯＤＵｆｌｅｘ特徴的情報（ＣＩ）信号を非選択とし、保護パス７５は、接続７１によるブリッジの設定が成功後、ＯＤＵｆｌｅｘソース機能７０からのこの保護されたＯＤＵｆｌｅｘ特徴的情報（ＣＩ）信号を搬送する。プロテクションプロトコルそれ自体は、ここでは当業者に一般に知られているものとして記載されている。

リサイズＯＨプロセッサ８４が提供されており、リサイズＯＨプロセッサ８４は、受信されたサイズオーバーヘッドチャネルからＯＤＵｋターミネーション機能７７において抽出されたリサイズオーバーヘッド信号を受信し、もともとはリサイズＯＨプロセッサ８３から送信されたＴＳＣＣ信号およびＲＰ信号を抽出する。これらのＴＳＣＣ信号およびＲＰ信号ならびにＯＤＵｋターミネーション機能７６によって受信されたＴＳＣＣ信号およびＲＰ信号が接続機能７８に供給され、そこでこれらの信号は前の実施形態におけると類似の特別処理の対象とされる。

プロテクショングループのシンクエンドを提供する接続機能７８において、シェアドプロテクションのための新しいリサイズＯＨチャネルによって提供されるＯＤＵｋ＿ＣＩ＿ＲＰ信号およびＯＤＵｋ＿ＣＩ＿ＴＳＣＣ信号は、１＋１プロテクションについてのものと類似のロジック機能を用いて組み合わせられ、ＯＤＵｆｌｅｘ＜Ｎ＞ターミネーション機能７９に供給される。

特に、ロジック機能８０は、このようにして、アクティブパス７４からのＲＰと、保護パス７５上の追加的リサイズオーバーヘッドチャネルにおいて受信されかつリサイズオーバーヘッドプロセッサ８４によって抽出されるＲＰとがともに０から１への遷移を示す場合にのみ、論理１を出力し、そうでない場合には論理０を出力する。反対に、ロジック機能８０（図５におけるとロジック機能６０同様）は、アクティブパス７４および保護パス７５からのＲＰがともに１から０への遷移を表す場合にのみ論理１から論理０へ戻り、そうでない場合には論理１の出力を継続する。ロジック機能８１は、アクティブパス７４および保護パス７５からのＴＳＣＣに対して論理ＡＮＤ演算を行う。

シェアドプロテクションまたは１：Ｎプロテクションについては、プロテクションセクションのエミュレートされた暫定ＨＯセクションは、現用エンティティと同様に、下位保護されたＯＤＵｆｌｅｘごとに、同一の管理コマンドを介してリサイズされる。これにより、現用エンティティとエミュレートされた保護エンティティとが調整のとれた仕方でリサイズされ、ＢＷＲ（帯域幅リサイズプロトコル）は両方のためにトリガされ、それによりいつでも同じ帯域幅が現用エンティティおよび保護エンティティにおいて利用可能であり、何ら余計な瞬断が作出されないように確保されることができる。

保護切り替え実行の場合には、ＨＯ／ＬＯアダプテーションのエミュレートされたコンフィギュレーションは、ブリッジおよびスイッチ（セレクタ）要求とともに、保護エンティティのアダプテーションおよび接続機能内にロードされて使用される保護エンティティを構成する必要がある。これとともに、トラヒックへのインパクトが最小化され、また、リサイズ処理の間、マッチング信号構造は直ちに利用可能となる。保護エンティティも現用エンティティも利用可能でない場合には、ＴＳＣＣ信号およびＲＰ信号はＯＤＵｆｌｅｘターミネーションにおいて利用可能ではなく、リサイズプロトコル処理は完了せず、また、リンクは両エンティティ上でリサイズされず、かくして保護コネクションは随時動作可能な状態に保たれる。

図５におけるＯＤＵｆｌｅｘターミネーション機能５９または図６におけるＯＤＵｆｌｅｘターミネーション機能７９に代えて、ＯＤＵｆｌｅｘは別の出力に接続されることができ、図２におけるネットワークノードＢがそうするように、その後のＨＯセクションを介して続行されることができることが理解されるべきである。

ネットワークノードは、保護されたＯＤＵｆｌｅｘコネクションのリサイジングをサポートするために、光トランスポート信号のための複数のネットワークインタフェースを有している。特に、１：１プロテクションまたは１＋１プロテクションをサポートするために、ネットワークノードは少なくとも２つのインタフェースを必要とし、その１つは、アクティブパスと保護パスとを受付けるインタフェースである。図１および図２を参照すると、インタフェースは、典型的には、ＯＴＵｋターミネーション機能、ＨＯ−ＯＤＵｋアダプテーション機能、ＯＤＵｋターミネーション機能およびＬＯ−ＯＤＵｋアダプテーション機能の各機能１３−１６、１３’−１６’、２１−２４および２１’−２４’を含むと考えられる。

図５および図６を参照すると、ネットワークノードは、さらにＬＯ−ＯＤＵｋのための接続機能５８、７８を含んでいるであろう。これは、ＨＯ−ＯＤＵｋ信号の個々のトリビュタリスロットを切り替えるＬＯスイッチマトリックスとすることができるが、専用の保護切り替え機能とすることもできる。接続機能は、プロテクショングループに対してシンク側ターミネーション機能を行うが、ここで、プロテクションのタイプに従って、プロテクショングループは少なくとも１つのアクティブパスと少なくとも１つの保護パスとを含む。

プロテクショングループのターミネーションは典型的にノードのユーザインタフェースまたはトリビュタリインタフェースに存在しているＬＯ−ＯＤＵｋターミネーション機能５９、７９へのアクティブパスの接続を伴うと考えられる。リサイズ処理のＢＷＲ部はこのようなＬＯ−ＯＤＵｋターミネーション機能５９、７９によって行われ、他方、リサイズ処理のＬＣＲ部はその間に、セクションターミネーションネットワークインタフェースによって、アクティブパスおよび保護パスに沿って行われる。

接続機能は、アクティブパスおよび保護パス上で受信されるリサイズプロトコル信号ＴＳＣＣおよびＲＰに対して論理演算を行って、単一の論理処理されたＴＳＣＣ信号およびＲＰ信号をＬＯ−ＯＤＵｋターミネーション機能５９、７９へ出力する。

ＴＳＣＣおよびＲＰ信号に対して行われる論理演算は論理的にはプロテクショングループを終端させる接続機能に属しているが、それらの機能は、物理的には分離して実装されてもよいことが明らかである。例えば、アクティブパスおよび保護パスからのＴＳＣＣ信号および／またはＲＰ信号を論理的に組み合わせる処理は、ＬＯ−ＯＤＵｋを終端するインタフェースボード上で実装されることができ、あるいは、スイッチマトリックスのような、障害が発生した場合のアクティブパスから保護パスへの切り替えを実際に行う中央接続機能によって実装されることができる。

Ｎ：１プロテクションスキームまたはＮ：Ｍプロテクションスキームにおけるようにプロテクショングループが２つ以上のアクティブパスと１つの保護パスとを含んでいるとき、２つよりも多いＴＳＣＣ信号および／またはＲＰ信号が一度に論理的に処理されて結合されることができることもまた明らかである。あるプロテクショングループに属するどれくらい多くのメンバーがリサイズされるべきか、および、どのリサイジング処理が同期されるべきかに依存して、これらのメンバーのＴＳＣＣ信号および／またはＲＰ信号は論理的処理および結合の処理対象とされると考えられる。

本明細書および各図面は単に本発明の原理を説明したものである。したがって、当業者であれば、ここに明示的に記載または図示されたものではなくても本発明の原理を具現化するとともにその趣旨および範囲に含まれる様々な構成を構想することができるであろうことが理解されると考えられる。また、ここに言及されるすべての例は、原則として本発明の原理と、技術分野の進展のために発明者によって提供されたコンセプトとに対する読み手の理解を助けるという教育的目的のためにのみ明示的に意図されたものであって、このような具体的に言及された各例と各条件とに限定される趣旨ではないものとして解釈されるべきである。さらに、ここに記載した本発明の原理、様相および実施形態ならびにその具体例に言及するすべての記載は、それと均等なものをも包含するものとして意図されたものである。

ラベル「プロセッサ」を付した任意の機能ブロックを含め、各図に示した様々な要素がもつ機能は、適切なソフトウェアと関連するソフトウェアを実行することができるハードウェアだけでなく専用ハードウェアの使用によって提供されてもよい。プロセッサによって提供される場合、これら機能は、単一の専用プロセッサによって、単一の共用プロセッサによって、あるいは、複数の個別プロセッサによって提供されてもよく、その一部は共有されていてもよい。さらに、用語「プロセッサ」または「コントローラ」を明示的に使用している場合でも、ソフトウェアを実行することができるハードウェアを排他的にさすものと解釈されるべきではなく、これらに限定する趣旨ではないが、デジタル信号処理プロセッサ（ＤＳＰ）ハードウェア、ネットワークプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するための読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）および不揮発性ストレージをも黙示的に含んでいてもよい。通常であるとカスタムとを問わず他のハードウェアも含まれてもよい。同様に、各図に示す任意のスイッチは専ら概念的なものである。それらの機能は、プログラムロジックの演算によって、専用ロジックによって、プログラム制御および専用ロジックのインタラクションによって、あるいは、さらには、文脈に従いより一層具体的に理解されるところに従い実装担当者によって選択可能な特定の技術を用いて行われてもよい。

Claims (12)

1. 光伝送ネットワークにおける保護されたコネクションのリサイジング方法であって、保護されたコネクションがフレキシブルサイズの下位光データユニットによって表され、
   前記保護されたコネクションが、少なくとも１つのアクティブパス（５４、７４）と少なくとも１つの保護パス（５５、７５）とで構成され、アクティブパス（５４、７４）と保護パス（５５、７５）とでプロテクショングループが形成され、
   リンクコネクションリサイズプロトコル部と帯域幅リサイズプロトコル部とで構成されたリサイズプロトコルを用いて行われる、方法において、
   − 前記少なくとも１つのアクティブパス（５４、７４）と少なくとも１つの保護パス（５５、７５）とに沿ってリンクをリサイズするために、前記リンクコネクションリサイズプロトコル部を行うステップと、
   − フレキシブルサイズの前記下位光データユニットの容量をリサイズするために、前記アクティブパスと前記保護パスとの双方に対してトリガされる前記帯域幅リサイズプロトコル部を行うステップと、
   − 前記少なくとも１つのアクティブパス（５４、７４）と前記少なくとも１つの保護パス（５５、７５）とに沿う前記リンクのリサイジングの成功または失敗を示す確認信号（ＴＳＣＣ）を、それぞれ、前記プロテクショングループを終端させる接続機能（５８、７８）へ送信するステップと、
   − 前記接続機能（５８、７８）において、前記少なくとも１つのアクティブパス（５４、７４）と前記少なくとも１つの保護パス（５５、７５）とに沿って送信される前記確認信号（ＴＳＣＣ）どうしを論理的に組み合わせるステップと、
   を含む、方法。
2. 前記確認信号を論理的に組み合わせる前記ステップが、前記確認信号に対してブールＡＮＤ演算（６１、８１）を行うことを含む、請求項１に記載の方法。
3. 前記確認信号（ＴＳＣＣ）が、フレキシブルサイズの前記下位光データユニットを担う上位光データユニットのオーバーヘッド位置において送信されるトリビュタリスロット接続性チェックビットである、請求項２に記載の方法。
4. − それぞれ、前記少なくとも１つのアクティブパス（５４、７４）および前記少なくとも１つの保護パス（５５、７５）に沿うリサイズ処理の開始および終了を示すステータス信号（ＲＰ）を、前記プロテクショングループを終端する前記接続機能（５８、７８）へ送信するステップと、
   − 前記接続機能（５８、７８）において、前記少なくとも１つのアクティブパス（５４、７４）と前記少なくとも１つの保護パス（５５、７５）とに沿って送信される前記ステータス信号どうしを論理的に組み合わせるステップと、
   をさらに含む、請求項１に記載の方法。
5. 前記ステータス信号を論理的に組み合わせる前記ステップが、演算（６０、８０）を含み、この演算が、
   − 前記アクティブパス（５４、７４）上で送信された前記ステータス信号（ＲＰ）および前記保護パス（５５、７５）上で送信された前記ステータス信号（ＲＰ）がいずれも０から１への遷移を示す場合にのみ出力状態を論理０から論理１へ変更し、それ以外の場合には論理０を出力し続け、
   − 前記アクティブパス（５４、７４）上で送信された前記ステータス信号（ＲＰ）および前記保護パス（５５、７５）上で送信された前記ステータス信号（ＲＰ）がともに１から０への遷移を示す場合にのみ出力状態を論理１から論理０へ変更し、それ以外の場合には論理１を出力し続ける、
   請求項４に記載の方法。
6. 前記ステータス信号（ＲＰ）が、フレキシブルサイズの前記下位光データユニットを担う上位光データユニットのオーバーヘッド位置において送信されるリサイジングプロトコルインジケータビットである、請求項４または５に記載の方法。
7. 前記確認信号（ＴＳＣＣ）および／または前記ステータス信号（ＲＰ）が、追加的オーバーヘッドチャネル上の前記少なくとも１つの保護パス（７５）上で送信され、この追加的オーバーヘッドチャネルが、フレキシブルサイズの前記下位光データユニットを担う上位光データユニットのオーバーヘッド位置内で定義されるリサイズオーバーヘッドとは分離されている、請求項４に記載の方法。
8. 光伝送ネットワークにおいて用いられるネットワークノードであって、
   上位光データユニットを搬送する光トランスポート信号のための複数のネットワークインタフェース（Ａ１、Ｂ１、Ｂ２、Ｃ１、５６、５７、７６、７７）と、上位光データユニットのペイロードセクション内で伝送される下位光データユニットのための接続機能（５８、７８）と、が備えられ、
   前記接続機能が、少なくとも１つのアクティブパス（５４、７４）および少なくとも１つの保護パス（５５、７５）で構成されたプロテクショングループのためのシンク側ターミネーション機能を行うように構成され、
   前記接続機能（５８、７８）が、さらに、リサイジングプロトコルの一部として前記少なくとも１つのアクティブパス（５４、７４）から受信された確認信号（ＴＳＣＣ）と前記少なくとも１つの保護パス（５５、７５）から受信された確認信号（ＴＳＣＣ）とを論理的に組み合わせるように構成されていて、この確認信号（ＴＳＣＣ）が、それぞれ、前記少なくとも１つのアクティブパス（５４、７４）および前記少なくとも１つの保護パス（５５、７５）に沿うリンクのリサイジングの成功または失敗を示し、かつ、
   前記接続機能（５８、７８）が、さらに、前記リサイジングプロトコルの一部として前記少なくとも１つのアクティブパス（５４、７４）から受信されるステータス信号（ＲＰ）および前記少なくとも１つの保護パス（５５、７５）から受信されるステータス信号（ＲＰ）を論理的に組み合わせるように構成されていて、このステータス信号（ＲＰ）が、それぞれ、前記少なくとも１つのアクティブパス（５４、７４）および前記少なくとも１つの保護パス（５５、７５）に沿う帯域幅リサイズ処理の開始および終了を示す、ネットワークノード。
9. 前記接続機能が、さらに、前記確認信号に対してブールＡＮＤ演算（６１、８１）を行うように構成されている、請求項８に記載のネットワークノード。
10. 前記接続機能（５８、７８）が、さらに、論理演算（６０、８０）を行うように構成され、この論理演算（６０、８０）が、
    − 前記アクティブパス（５４、７４）から受信された前記ステータス信号および前記保護パス（５５、７５）から受信された前記ステータス信号がいずれも０から１への遷移を示す場合にのみ出力状態を論理０から論理１へ変更し、それ以外の場合には論理０を出力し続け、
    − 前記アクティブパス（５４、７４）から送信された前記ステータス信号および前記保護パス（５５、７５）から送信された前記ステータス信号がともに１から０への遷移を示す場合にのみ出力状態を論理１から論理０へ変更し、それ以外の場合には論理１を出力し続ける、
    請求項８に記載のネットワークノード。
11. シンク側リサイズオーバーヘッドプロセッサ（８４）が備えられていて、このシンク側リサイズオーバーヘッドプロセッサ（８４）が、追加的オーバーヘッドチャネルから前記少なくとも１つの保護パスにおいて受信される前記確認信号および／または前記ステータス信号を抽出し、この追加的オーバーヘッドチャネルが、フレキシブルサイズの前記下位光データユニットを担う上位光データユニットのオーバーヘッド位置内で定義されるリサイズオーバーヘッドとは分離されている、請求項８に記載のネットワークノード。
12. ソース側リサイズオーバーヘッドプロセッサ（８３）がさらに備えられていて、このソース側リサイズオーバーヘッドプロセッサ（８３）が、戻り方向保護パス上で戻り方向に送信されるべき前記確認信号および／または前記ステータス信号を、フレキシブルサイズの前記下位光データユニットを担う上位光データユニットのオーバーヘッド位置において定義されるリサイズオーバーヘッドとは分離された前記追加的オーバーヘッドチャネル内に組み込む、請求項１１に記載のネットワークノード。

Images