JP4167072B2 - リング・トポロジーに対する選択的保護 - Google Patents

Description

本発明は、概して、ネットワーク通信システムおよびプロトコルに関し、特にパケット交換ネットワークにおける故障を保護するための方法に関する。

ネットワーク・リング・トポロジーは、広く使用されるようになってきているが、特にインターネット・プロトコル（ＩＰ）ネットワークにおいて広く使用されるようになってきている。このようなネットワークにおいては、キャリヤはコスト・パフォーマンスの高い方法で、ユーザに広い帯域幅を提供することができる。何故なら、ネットワーク内の各ノードは、メッシュ・ネットワーク内でのように、他の各ノードに対して個々のインタフェースを維持する必要がなく、たった２つのインタフェースしか必要としないからである。リング・ネットワークは、また、ネットワークが故障した場合、高速で再経路指定を行うことができる。何故なら、一般的に、時計方向および反時計方向の２つの交互の経路を、リング上の任意の２つのノードを接続するために使用することができるからである。

ＳＯＮＥＴ／ＳＤＨのような従来のリング・ネットワークの欠点は、複数の方向のうちの１つが能動リングとして指定されることである。一方、他の方向は、必要な場合に故障保護を行うために待機状態になっている。すなわち、任意の所与の時点で、リング内のすべてのノードは能動方向にしかデータを送受信することができない。それ故、これらのリング内で使用できる帯域幅の普通半分は、故障保護のために留保され、通常の動作条件の下では使用することができない。

最近開発されたいくつかの両方向プロトコルの場合には、故障に対する高速な保護を維持しながら、リング内の任意の一組のノード間で、どちらの方向にもデータを転送することができるようにすることにより、帯域幅をもっと効率的に使用することができる。２つの対向トラヒック方向は、通常、内部リングおよび外部リングと呼ばれる。しかし、本特許出願および特許請求の範囲においては、「内部」および「外部」という用語、および「時計方向」および「反時計方向」という用語は、リング・ネットワーク内のパケットの流れの２つの対向方向間を区別するために、ただ便宜上使用されていることを理解することができるだろう。これらの用語は、説明の便宜のために使用しているだけで、必ずしもネットワークの物理的特性に何らの関係も持つものではない。

高速パケット・リング用に最も広く使用されている両方向プロトコルは、ＩＥＥＥ規格８０２．１７として、現在定義の作成が行われている弾性パケット・リング（ＲＰＲ）プロトコルである。ＲＰＲによるネットワーク層経路指定については、例えば、ジョガレカ他が、「弾性パケット・リングによるＩＰ」（IP over Resilient Packet Rings）（インターネット草稿、ｄｒａｆｔ−ｊｏｇａｌｅｋａｒ−ｉｐｏｒｐｒ−００）内で記述しているし、ヘレラ他が、「パケット転送リングによるＩＰに対するフレームワーク」（A Framework for IP over Packet Transport Rings）（インターネット草稿、ｄｒａｆｔ−ｉｅｔｆ−ｉｐｏｐｔｒ−ｆｒａｍｅｗｏｒｋ−００）内で記述している。両方向リング・ネットワーク内の媒体アクセス制御（ＭＡＣ−プロトコル層２）に対して提案された解決方法は、インターネット技術調査会（ＩＥＴＦ）のコメント要請（ＲＦＣ）２８９２内に、チアング他が記述している空間再使用プロトコル（ＳＲＰ）である。これらの文書は、引用によって本明細書の記載に援用する。これらの文書はｗｗｗ．ｉｅｔｆ．ｏｒｇから入手することができる。

これらのようなプロトコルを使用した場合、リング・ネットワーク内の各ノードは、ノードの適当な媒体アクセス制御（ＭＡＣ）アドレスを使用することにより、内部リングまたは外部リングを通して他のすべてのノードと直接通信することができる。リングの中の１つを通して送信された各パケットは、その宛先ノードを示すヘッダを運ぶ。宛先ノードは、ヘッダ内のそのアドレスを認識し、リングからパケットを取り出す。他のすべてのノードは、介入しないでリングを通してパケットを通過させる。

両方向リング・ネットワーク上のリンク内で故障が起こると、リングの一方の上の故障したリンクを横切るパケットを、他のリングを通してその宛先に送るために、急いで再経路指定しなければならない。この再経路指定は、この業界においては「保護（protection）」と呼ばれている。この目的のために２つのスキーム、すなわち、折り返しおよび振り替えが使用される。ＳＲＰリングで使用される方法である折り返しは、故障したリンクに隣接するノードのところで、パケットの流れをループバックすることにより実行される。それ故、内部リング上の故障したリンクに到着するパケットは、外部リングを通してその宛先に到着するようにループバックされる。その逆も行われる。このようにして、保護は、故障したリンクに隣接するノードにより簡単に行われる。一方、振り替えをベースとする保護の場合には、各ノードに対して故障したリンクが報告される。各ノードは、次に、それに従って、そのトラヒック全部を故障したリンクを経由させないで所望の宛先に接続しているリングに振り替える。

折り返し(wrapping)は、速度が速いという点および簡単であると点では優れている。何故なら、保護機能を実行するために、故障を検出するノードしか必要としないからである。さらに、他のノードに故障が発生したことを知らせる必要もない。折り返しの欠点は、保護されたパケットがその宛先に到着するのに遥かに長い経路を通らなければならないことである。ネットワーク・リソースの利用度も低減する。何故なら、保護されたパケットが、少なくとも１回、多くの場合２回、ネットワークのすべてのセグメントを通るからである。さらに、故障の修理が行われ、折り返しが終了すると、いくつかのパケットが、故障しているその宛先に到着する可能性もある。何故なら、そのようなパケットは、時間的に早いパケットが使用している折り返し措置がとられた経路より遥かに短い、その元の経路を再び通ることができるからである。その結果、折り返しは、ジッタ（jitter）およびパケットの順序の混乱により影響を受けやすい音声またはビデオのようなリアルタイム・トラヒックに対する保護機構としては問題がある。

それ故、折り返しよりは複雑ではあるが、リアルタイム・トラヒックの処理には、振り替えの方が適している。振り替えは、すべてのノードに通知しなければならないし、故障保護を行わなければならないので、折り返しと比較するとその始動速度は当然遅い。ノードが相互に故障状況を通知することができるように、ノードを適当な保護プロトコルでリンクしなければならない。このプロトコルによりあるノードが送った故障通知パケットは、次に、他のすべてのノードを更新するために全リングを通らなければならない。故障の発生と振り替えの始動の間に送信されるパケットは通常喪失する。あるデータ・アプリケーションの場合には、たった１つのパケットが喪失しただけで、データの全フレームまたは全ブロックを廃棄しなければならなくなる恐れがある。それ故、保護によるパケットの喪失は、最小限度にとどめなければならない。

それ故、ブロック・データ・アプリケーションに対しては、一般的に、折り返しはより優れた保護スキームであるが、リアルタイム・トラヒックに対しては振り替えの方が優れている。現在のパケット・ネットワークは、通常、両方のタイプのトラヒックを運ぶので、折り返しも振り替えも最適な解決方法ではない。ＳＲＰの場合には、上記ＲＦＣ２８９２（第３．４節）のところですでに説明したように、故障が起こると最初に折り返しトラヒック、次に、振り替えトラヒックにより２つのスキームが結合される。しかし、この場合、リアルタイム・トラヒックは２回中断される。最初、故障が発生し、折り返しがスタートした時点で行われ、その後で、振り替えが行われる。何故なら、振り替え措置がとられた経路の方が、折り返し措置がとられた経路より短いからである。それ故、ブロック・データおよびリアルタイム・トラヒック両方のニーズに適合する保護解決方法の開発が待望されている。

ジョガレカ他の、"IP over Resilient Packet Rings"（インターネット草稿、ｄｒａｆｔ−ｊｏｇａｌｅｋａｒ−ｉｐｏｒｐｒ−００） ヘレラ他の、"A Framework for IP over Packet Transport Rings"（インターネット草稿、ｄｒａｆｔ−ｉｅｔｆ−ｉｐｏｐｔｒ−ｆｒａｍｅｗｏｒｋ−００）

本発明の１つの目的は、改善された保護方法およびリング・ネットワークで使用するための上記方法を実施するためのデバイスを提供することである。

本発明のいくつかの態様のもう１つの目的は、異なるタイプのトラヒックを同時に最適化することができる保護方法を提供することである。

本発明の好ましい実施形態の場合には、両方向リング・ネットワークは、ネットワーク・リンクの１つで故障が発生した場合に、あるタイプのパケットに対して折り返し措置がとられ、他のタイプのパケットに対して折り返し措置が行われないように配置される。好適には、故障により喪失するパケットの数を最小限度に低減するために、遅延により影響を受けにくく、パケットの順序の混乱を処理することができるデータ・サービスに対して折り返し措置がとられ、一方、ジッタおよび順序の混乱の影響を受けやすいリアルタイム・サービスに対しては折り返し措置をとらないことが好ましい。最も好適には、振り替えをリアルタイム・サービスに適用し、一方遅延の影響を受けないデータ・サービスには折り返し措置を行うことである。別の方法としては、振り替えが確立される最初の折り返し周期が経過した後で、データ・サービスを振り替えすることもできる。さらに、もう１つの別の方法としては、いくつかのサービスに折り返し措置を行い、そうしたい場合には、その後で振り替え措置を行うこともできる。一方、故障が発生した状況で、保護された高い優先順位のトラヒックに対して、ネットワーク上で十分な帯域幅が確実に使用できるように、いくつかの他のサービスはそのまま廃棄される。

本発明のある好ましい実施形態の場合には、この選択的折り返しは、各パケットにフラッグを追加し、そのパケットに対して折り返し措置をとるべきかどうかを表示することにより実施される。あるノードが、隣接するリンク内に故障を検出した後で、そのノードは、そのパケットに対して折り返し措置をとるべきかどうか、通過させるべきかどうか、または廃棄すべきかどうかを決定するために、自分が受信する各パケット内のフラッグをチェックする。所与のタイプのパケットが折り返しフラッグ・セットまたはリセットを持つべきかどうかは、通常、（例えば、データまたはリアルタイムのような）関連するサービスのタイプにより、送信側のノードが決定する。別の方法の場合、または追加的な措置の場合、フラッグの設定は、そのパケットを送るユーザの識別、またはシステム・オペレータが設定する他の要因により異なる。さらに、別の方法としては、他の実施形態の場合には、折り返しフラッグを使用しないで、その代わりに、ノードが、ソース・アドレスまたは宛先アドレスまたはプロトコル・タイプなどのパケットが運ぶ他の情報に基づいてどのパケットに対して折り返し措置をとるべきかを決める。

それ故、本発明の好ましい実施形態は、混合トラヒック・リング・ネットワークでの保護の問題に対して、簡単で柔軟な解決方法を提供する。すでに説明したように、折り返しも、振り替えも、またＳＲＰが提供するような折り返しの後での振り替えも、このようなネットワーク内のすべてのタイプのトラヒックに対する最適な解決方法ではない。

それ故、本発明の好ましい実施形態は、ネットワーク内でパケット・トラヒックが、時計方向および反時計方向の両方向に送信される両方向リング・ネットワークで故障保護を行う方法を提供する。該方法は、
両方向リング・ネットワーク内で、パケットの第１および第２の流れを送信するステップであって、第１の流れを折り返し流れとして、第２の流れを非折り返し流れとして定義するステップと、
ネットワーク内で、あるノードがそのノード隣接するネットワークのセグメントが故障したことを検出した場合に、故障したセグメントを回避するために、時計方向および反時計方向の間のノードのところで、第１の流れのパケットに対して折り返し措置を行い、一方、第２の流れのパケットに対しては折り返し措置をとらないステップとを含む。

そのノードに到着する第２の流れのパケットは、通過させることもできるし、廃棄することもできる。

追加的措置の場合、または別の方法の場合には、上記方法は、故障したセグメントを回避しながら、第２の流れの宛先に到着するために、時計方向および反時計方向の中の一方で、第２の流れの中のパケットを振り替えするステップを含む。好適には、第２の流れのパケットに対して振り替え措置を行うステップは、故障したセグメントを検出したノードから第２の流れのソース・ノードに、故障表示メッセージを送信するステップと、上記メッセージに応じて第２の流れのパケットの振り替えを開始するステップとを含むことが好ましい。より詳細に説明すると、上記方法は、第２の流れのパケットの振り替えが開始した時に、第１の流れのパケットを振り替えするステップと、パケットの折り返しを中断するステップとを含む。

さらに、追加的措置の場合、または別の方法の場合、上記方法は、故障セグメントを検出したノードからネットワーク内の他のノードに故障表示メッセージを送信するステップと、他のノードが上記メッセージを受信した後で、故障したセグメントを回避しながら、第１の流れの宛先に到着するために、時計方向および反時計方向の中の一方の方向に、第１の流れのパケットに対して振り替え措置を行うステップと、パケットの折り返しを中断するステップとを含む。通常、第２の流れのパケットは、故障が継続する限り廃棄される。

好適には、第１および第２の流れを送信するステップは、第１の流れの中のパケット内に折り返しフラッグをセットし、一方、第２の流れのパケット内で折り返しフラッグをリセットするステップを含むことが好ましい。また、パケットに対して折り返し措置を行うステップが、折り返しフラッグに応じて折り返し措置を行うパケットを決定するステップを含むことが好ましい。

好ましい実施形態の場合には、第２の流れを送信するステップは、リアルタイム・サービスを提供するステップを含み、一方、第１の流れを送信するステップは、リアルタイム・サービスよりも、パケットの供給の際に遅延の変動および順序の混乱に対してかなり許容度が高い、データ送信サービスを提供するステップを含む。通常、リアルタイム・サービスは、少なくとも１つのパケット化された音声サービスおよびパケット化されたビデオ・サービスを含む。

本発明の好ましい実施形態は、また、通信装置を提供する。該通信装置は、
通信媒体と、
ノードが、時計方向および反時計方向の両方向に、他のノードに対して、折り返し流れとして定義されたパケットの第１の流れと、非折り返し流れとして定義されたパケットの第２の流れを含むトラヒックを送信するように構成されているリング・ネットワークを形成するために、通信媒体により相互に結合している複数の通信ノードとを含み、
ノードは、ネットワーク内のノード内の所与のノードが、所与のノードに隣接するネットワークのセグメントが故障していることを検出した場合に、故障したセグメントを回避するように、時計方向および反時計方向の間の所与のノードのところで、第１の流れのパケットに対して折り返し措置が行われ、一方、第２の流れのパケットに対して折り返し措置が行われないようにすることができる。

本発明の好ましい実施形態は、さらに、トラヒックが、時計方向および反時計方向の両方向に送信されるリング・ネットワーク内でノードとして動作するための通信デバイスを提供する。該デバイスは、
パケットが折り返し流れとして定義されたパケットの第１の流れに属するか、または非折り返し流れとして定義された第２の流れに属するように、リング・ネットワークを通して送信を行うために、出力データ・パケットを作成することができるトラヒック処理ブロックと、
トラヒック処理ブロックに対してインタフェースとして機能し、時計方向および反時計方向の両方向で、リング・ネットワークを通して出力データ・パケットを送信し、入力パケットを受信するようにネットワークに接続することができ、さらに、デバイスに隣接するネットワークのセグメントの故障を検出し、故障に応じて、第２の流れのパケットに対して折り返し措置を行わないで、故障したセグメントを回避するように、時計方向および反時計方向の間の第１の流れに属するパケットに対して折り返し措置を行うことができる媒体アクセス制御（ＭＡＣ）ブロックとを含む。

添付の図面を参照しながら、本発明の好ましい実施形態の下記の詳細な説明を読めば、本発明をもっと完全に理解することができるだろう。

図１は、本発明の好ましい実施形態による、パケット・リング・ネットワーク２０の略ブロック図である。ネットワーク２０は、光ファイバまたは導電ワイヤなどの両方向通信媒体により相互に接続しているＮ１〜Ｎ６で示すノード２２を備える。ノードは、通常、切替え装置を備えていて、他のネットワークに対してアクセス・ポイントまたはゲートウェイとして機能する。ネットワーク２２内の通信媒体は、時計方向にノード間でパケットが送られる外部リング２４と、反時計方向にパケットが運ばれる内部リング２６を形成するように構成されている。しかし、すでに説明したように、「内部」、「外部」、「時計方向」および「反時計方向」の指定は任意のもので、本明細書においては、説明の便宜上および説明を分かりやすくするために使用しているに過ぎない。さらに、ネットワーク２０内のノードの指定および数は、単に例示としてのものに過ぎず、ネットワークは、同じ記号により、より多くのまたはより少ない数のノードを備えることができる。

図２は、本発明の好ましい実施形態による、ネットワーク２０内のノード２２の中の１つの詳細を略図で示すブロック図である。ノード２２は、リング２４および２６の両方を通してデータを送受信するために接続している媒体アクセス制御（ＭＡＣ）ブロック３３を備える。ブロック３３は、リング管理を行い、どちらかのリング上でノード２２にアドレス指定されるパケットを捕捉するＭＡＣ層機能を実行する。一方、リングに沿って、次のノードにすべての他のトラヒックを送る。好適には、ブロック３３は、発明の背景のところに記載したＲＰＲプロトコル、または両方向プロトコル類似の他のプロトコルにより動作することが好ましい。基本的リング・プロトコルは、以下に詳細に説明するように、本発明の好ましい実施形態により、選択的折り返しを行う保護プロトコルにより拡張される。

ＭＡＣブロック３３が、それ自身のノード２２宛のパケットを捕捉すると、ＭＡＣブロックは、そのパケットをノードのトラヒック処理ブロック３４に供給する。ブロック３４は、ＩＰ処理などのネットワーク層機能、およびそうしたい場合には、サービスの質（ＱｏＳ）およびネットワーク機密保護などの他のもっと高いレベルの機能を行う。例えば、アクセス・ポイントとして機能するノードの場合には、ブロック３４は、通常、ノードを通してネットワーク２０に接続しているユーザにパケットを供給し、ネットワーク２０を通して送信するためにユーザからパケットを受信する。

ネットワーク２０に適用される保護プロトコルによれば、ネットワークを通るパケットは、好適には、各パケットの特定されたまたは先頭近くの位置の１つのビットの形をしていることが好ましい折り返しフラッグを含む。トラヒック処理ブロック３４は、好適には、自分がネットワーク内に送信する各パケット内で折り返しフラッグをセットまたはリセットすることが好ましい。通常、折り返しフラッグの設定は、パケットが属するサービスのタイプにより異なる。追加的措置の場合、または別の方法の場合、フラッグの設定は、パケットを送信するユーザの識別（特に、ユーザが契約しているＱｏＳのレベルにより）、またはユーザまたはネットワーク２０のマネージャが設定する他の基準により異なる。

図１の例に戻って説明すると、２つのパケットの流れ２８および３０は、中間ノードＮ６およびＮ５を通して、内部リング２６を経てソース・ノードＮ１から宛先ノードＮ４へと向かう。この例の場合には、流れ２８は、ＴＣＰ／ＩＰで稼働する電子メール・アプリケーション、または他のデータ転送アプリケーションなどの比較的ジッタおよびパケットの順序の混乱の影響を受けないプロトコルによるデータのブロックを転送するデータ・サービスに属しているものと仮定する。一方、流れ３０は、ＩＰ上の音声（ＶｏＩＰ）または時々脱落するパケットには強いけれども、ジッタおよび順序の混乱には弱いストリーミング・ビデオ・サービスなどのリアルタイム・サービスに属するものと仮定する。折り返しフラッグは、流れ２８のパケット内でセットされ、流れ３０のパケット内でリセットされる。これらの流れの両方は、ノードＮ５とＮ６の間のリンクの故障３２により中断される。

図３Ａおよび図３Ｂは、ネットワーク２０が、本発明の好ましい実施形態による、流れ２８および３０で示す２つの異なるタイプのサービスに対する故障３２をどのように処理するのかを示す略図である。図面を簡単にするために、図３Ａおよび図３Ｂは別々の図面になっているが、実際には、２つの図面に示す保護機構は、同時に動作することができる。図３Ａに示すように、流れ２８は、ノードＮ６およびＮ５のところで外部リング２４上に折り返され、折り返された流れ経路３６を形成している。一方、流れ３０はリングＮ１により外部リング２４に振り分けられ、そのため振り分けられた流れ経路３８を形成している。流れ３０は、フラッグにより非折り返し流れであると表示されているので、Ｎ１がパケットを外部リングへの振り分けをスタートする前にノードＮ６に到着する流れ３０内のすべてのパケットは通常廃棄される。追加的措置の場合、または別の方法の場合、ネットワーク２０内には、折り返しに対してフラッグも設定されていないし、振り替えもされていない流れ（図示せず）が存在する。これらの流れの中のパケットは、故障３２が継続している間に、ノードＮ５およびＮ６に到着した場合にはそのまま廃棄される。もう１つの別の方法の場合には、通常、ネットワーク２０内のすべてのノードに対して故障３２が通知され、振り替えをスタートする準備ができるまで、流れ２８を経路３６上で一時的に折り返すことができる。この時点で、流れ経路３６は一時的に中止され、代わりに、流れ２８が流れ経路３８に沿って振り分けられる。

ここで、本発明の好ましい実施形態による、ネットワーク２０内の故障保護の方法の概略を示すフローチャートである図４および図５を参照する。流れ２８および３０を参照しながら、この方法について説明するが、これは単に例示としてのものに過ぎない。流れ２８内のパケットは折り返しのためにフラッグがオンになっているが、流れ３０内のパケットのフラッグはオンになっていないで、振り分けられるものと仮定する。図４は、ノード６のような、故障３２が発生したリンクに隣接するノードの行動を示す。一方、図５は、ノードＮ１などのパケットの流れがスタートするノードを示す。この方法は、他のノード構成およびすでに説明したような代わりの保護スキームに簡単に拡張することができる。

図４の方法は、ノードＮ６が、故障検出ステップ４０でリンク故障３２を検出した場合にスタートする。故障が検出されると直ちに、Ｎ６は、通知ステップ４２で、他のノードに故障を通知するために、リング２４を通して故障表示パケットを送信する。（ノードＮ５も、通常、故障を検出し、それに従ってリング２６を通して故障表示パケットを送信する。）ノードＮ６は、その後で、パケット受信ステップ４４で、リング２６上でパケットを受信し、個々に各パケットの処理方法を決定する。このノードは、折り返しフラッグがセットされているか、またはリセットされているかを判断するために、パケット・ヘッダをチェックする。フラッグがセットされている場合には、ノードＮ６は、リング２６からのパケットを、折り返しステップ４８において、リング２４上に折り返す。流れ２８の場合には、パケットは経路３６上で折り返される。パケットがノードＮ５に到着すると、折り返しフラッグが再度チェックされ、それによりパケットがリング２６上に再度折り返される。このリング２６上でパケットは最後に宛先ノードＮ４に到着する。

ステップ４２において、故障表示パケットを送信した後で、しかし、ノードＮ１が、流れ３０を経路３８に振り分ける準備ができる前は、ノードＮ６は、依然として流れ３０に属するパケットを受信することができる。これらのパケットの折り返しフラッグがセットされていないので、ノードＮ６は、非折り返しステップ５０において、折り返しを行わないで、単にパケットを通過させるだけである。その結果、パケットは廃棄される。

図５に示すように、ノードＮ１は、パケット作成ステップ６０において、送信のために流れ２８および３０でパケットを準備する。ネットワーク内に故障が発生していない場合には、パケットは、送信のために、ノードＮ６およびＮ５を通る経路上に送られる。パケットを送信する前に、Ｎ１は、故障チェック・ステップ６２において、各流れが通るリンク内に何らかの故障が発生したのが検出されたかどうかを確認するためにチェックを行う。他のどのノードもそのような故障を報告していない限り、またノードＮ１が故障自身を検出していない限り、通常送信ステップ６４において、振り分けを行わないで、パケットは通常の経路に沿って送信される。故障３２が発生したが、Ｎ６から故障表示がＮ１にまだ到着していない場合には、パケットは通常の経路に沿って依然として送信される。この場合、流れ２８内のパケットは、すでに説明したように、Ｎ６により折り返されるが、流れ３０内のパケットは、ステップ５０のところでＮ６を通過し、それ故、廃棄される。

Ｎ１が故障表示を受信すると、Ｎ１は流れ３０のパケットを、振り替えステップ６６において、経路３８への振分けをスタートする。同様に、ネットワーク２０内のノードＮ６および他のノードは、この時点で、自分のところからスタートするパケットの流れの適当な宛先への振り分けをスタートする。好適には、ネットワーク・リソースを節約するために、Ｎ１および他のノードも、流れ２８のような折り返された流れを振り分ける。別の方法としては、故障期間の間、ネットワーク・リソースを節約するために、いくつかの流れだけを振り分け、一方他の流れは折り返したり、または遅延させたり、または廃棄したりする。

いくつかの特定のタイプのネットワークおよびプロトコル、特にＲＰＲプロトコルをベースとするパケット・ネットワークを参照しながら好ましい実施形態について説明してきたが、本発明の原理は、他のタイプの両方向リング・ネットワークおよびプロトコルにも同様に適用することができる。それ故、上記好ましい実施形態は、単に例示としてのものに過ぎず、本発明は、上記記述に制限されるものでないことを理解することができるだろう。それどころか、本発明の範囲は、上記種々の機能の組合わせおよびサブ組合わせ、および上記の説明を読んで当業者であれば思い浮かぶ、また従来技術が開示していない種々の変更および修正も含む。

本発明の好ましい実施形態による、両方向リング・ネットワークの略ブロック図である。 本発明の好ましい実施形態による、図１のネットワーク内の１つのノードの詳細を略図で示すブロック図である。 本発明の好ましい実施形態による、リンク故障に応じて、図１のネットワークで実施される保護機構を略図で示すブロック図である。 本発明の好ましい実施形態による、リンク故障に応じて、図１のネットワークで実施される保護機構を略図で示すブロック図である。 本発明の好ましい実施形態による、リング・ネットワーク内の故障保護のための方法の簡単なフローチャートである。 本発明の好ましい実施形態による、リング・ネットワーク内の故障保護のための方法の簡単なフローチャートである。

Claims (30)

1. パケット・トラヒックが時計方向および反時計方向の両方向同時に送信される両方向リング・ネットワーク内で故障保護を行うための方法であって、
   前記両方向リング・ネットワーク内で、パケットの第１および第２の流れを送信し、一方、前記第１の流れを折り返し流れとして、および前記第２の流れを非折り返し流れとして定義するステップと、
   前記ネットワーク内のあるノードが、該ノードに隣接する前記ネットワークのあるセグメントが故障したことを検出した場合に、前記故障したセグメントを回避するために、前記ノードのところで、前記第１の流れの前記パケットを前記時計方向および反時計方向の間で折り返し、すなわち、前記ノードで受信された時計方向の前記第１の流れの前記パケットを反時計方向にループさせるか、前記ノードで受信された反時計方向の前記第１の流れの前記パケットを時計方向にループさせ、一方、前記第２の流れの前記パケットは折り返さないステップとを含む方法。
2. 前記ノードに到着する前記第２の流れの前記パケットが廃棄される請求項１記載の方法。
3. 前記故障したセグメントを回避しながら前記第２の流れの宛先に到着するために、各ノードに前記第２の流れを送信させるようにするために前記ネットワークにある全てのノードにセグメント故障情報が通知されることにより、各ノードにおいて、前記第２の流れの前記パケットを前記時計方向および反時計方向のいずれかの方向に送信させるステップを含む請求項１記載の方法。
4. 前記第２の流れの前記パケットを振り替えるステップが、前記故障したセグメントを検出した前記ノードから前記第２の流れのソース・ノードに故障表示メッセージを送信するステップと、前記メッセージに応じて、前記第２の流れの前記パケットの振り替えをスタートするステップとを含む請求項３記載の方法。
5. 前記第２の流れの前記パケットの振り替えがスタートした場合に、前記第１の流れの前記パケットも振り替えるステップと、前記パケットの前記折り返しを中断するステップとを含む請求項４記載の方法。
6. 前記ネットワーク内で、前記故障したセグメントを検出した前記ノードから他のノードに故障表示メッセージを送信するステップと、前記他のノードが前記メッセージを受信した後で、前記故障したセグメントを回避しながら、前記第１の流れの宛先に到着するために、前記時計方向および反時計方向の中の一方で、前記第１の流れの前記パケットを選択された一方向に送信させるステップと、前記パケットの前記折り返しを中断するステップとを含む請求項１〜５のいずれか記載の方法。
7. 前記故障が継続している限り、前記第２の流れの前記パケットが廃棄される請求項６記載の方法。
8. 前記第１および第２の流れを送信するステップが、前記第１の流れの前記パケット内に折り返しフラッグをセットし、一方、前記第２の流れの前記パケット内の前記折り返しフラッグをリセットするステップを含み、前記パケットを折り返すステップが、前記折り返しフラッグに応じて、折り返す前記パケットを決定するステップを含む請求項１〜５のいずれか記載の方法。
9. 前記第２の流れを送信するステップが、リアルタイム・サービスを提供するステップを含み、一方、前記第１の流れを送信するステップが、リアルタイム・サービスと比較した場合、前記パケットの供給の際に、遅延の変動および順序の混乱に対してかなり許容度が高いデータ送信サービスを提供するステップを含む請求項１〜５のいずれか記載の方法。
10. 前記リアルタイム・サービスが、パケット化された音声サービスおよびパケット化されたビデオ・サービスの中の少なくとも一方を含む請求項９記載の方法。
11. 通信装置であって、
    通信媒体と、
    複数の通信ノードとを含み、該ノードが、時計方向および反時計方向の両方向で、他のノードに対して、折り返し流れと定義されたパケットの第１の流れと、非折り返し流れと定義されたパケットの第２の流れを含むトラヒックを送信するように構成されているリング・ネットワークを形成するために、前記通信媒体により相互に結合していて、
    前記ノードが、前記ネットワーク内の前記ノードの中の所与のノードが前記所与のノードに隣接する前記ネットワークのあるセグメントが故障していることを検出した場合に、前記故障したセグメントを回避するように、前記所与のノードのところで、前記第１の流れの前記パケットが前記時計方向および反時計方向の間で折り返され、すなわち、前記所与のノードで受信された時計方向の前記第１の流れの前記パケットを反時計方向にループさせるか、前記所与のノードで受信された反時計方向の前記第１の流れの前記パケットを時計方向にループさせ、一方、前記第２の流れの前記パケットは折り返されないようにすることができる装置。
12. 前記所与のノードに到着する前記第２の流れの前記パケットが廃棄される請求項１１記載の装置。
13. 前記ノードが、さらに、前記故障したセグメントを回避しながら前記第２の流れの宛先に到着するために、各ノードに前記第２の流れを送信させるようにするために前記ネットワークにある全てのノードにセグメント故障情報が通知されることにより、前記第２の流れの前記パケットを前記時計方向および反時計方向のいずれかの方向に送信させることができる請求項１１記載の装置。
14. 前記所与のノードが、前記ネットワーク内の前記ノードの中の前記第２の流れのソース・ノードに故障表示メッセージを送信することができ、前記ネットワークが、前記メッセージに応じて、前記第２の流れの前記パケットの振り替えをスタートすることができる請求項１３記載の方法。
15. 前記ノードが、さらに、前記第２の流れの前記パケットの振り替えがスタートした場合に、前記第１の流れの前記パケットも振り替えることができ、その場合、前記所与のノードが前記パケットの折り返しを中断する請求項１４記載の装置。
16. 前記所与のノードが、前記ネットワーク内の前記他のノードに故障表示メッセージを送信することができ更に前記ノードが、前記メッセージを受信した後で、前記故障したセグメントを回避しながら前記第１の流れの宛先に到着するように、前記時計方向および反時計方向の中の一方で、前記第１の流れの前記パケットを選択された一方向に送信させることができ、その場合、前記所与のノードが、前記パケットの折り返しを中断する請求項１１〜１５のいずれか記載の装置。
17. 前記故障が継続している限り、前記所与のノードに到着する前記第２の流れの前記パケットが廃棄される請求項１６記載の装置。
18. 前記第１および第２の流れを送信する前記ノードが、前記第１の流れの前記パケット内に折り返しフラッグをセットすることができ、一方、前記第２の流れの前記パケット内で前記折り返しフラッグをリセットし、前記所与のノードが、前記折り返しフラッグに応じて折り返しを行う前記パケットを識別することができる請求項１１〜１５のいずれか記載の装置。
19. 前記第２の流れがリアルタイム・サービスに属していて、一方、前記第１の流れが、リアルタイム・サービスと比較した場合、前記パケットの供給の際に遅延の変動および順序の混乱に対してかなり許容度が高いデータ送信サービスを含む請求項１１〜１５のいずれか記載の装置。
20. 前記リアルタイム・サービスが、パケット化された音声サービスおよびパケット化されたビデオ・サービスの中の少なくとも一方を含む請求項１９記載の装置。
21. トラヒックが時計方向および反時計方向の両方向に送信されるリング・ネットワークで、ノードとして動作するための通信デバイスであって、
    前記リング・ネットワークを通して送信するために、出力データ・パケットを作成することができ、その結果、前記パケットが、折り返し流れとして定義された前記パケットの第１の流れに属するか、または非折り返し流れとして定義された第２の流れに属するトラヒック処理ブロックと、
    前記トラヒック処理ブロックに対してインタフェースとして機能し、前記時計方向および反時計方向の両方向に前記リング・ネットワークを通して出力データ・パケットを送信し、入力パケットを受信するように前記ネットワークに結合することができ、さらに、前記デバイスに隣接する前記ネットワークのあるセグメントの故障を検出することができ前記故障に応じて、前記第２の流れの前記パケットを折り返さないで、前記故障したセグメントを回避するように、前記第１の流れに属する前記パケットを前記時計方向および反時計方向の間で折り返すことができる、すなわち、受信された時計方向の前記第１の流れの前記パケットを反時計方向にループすることができ、受信された反時計方向の前記第１の流れの前記パケットを時計方向にループすることができる媒体アクセス制御（ＭＡＣ）ブロックとを含むデバイス。
22. 前記故障の発生後、前記ＭＡＣブロックに到着する前記第２の流れのパケットが廃棄される請求項２１記載のデバイス。
23. 前記ＭＡＣブロックが、さらに、前記故障したセグメントを回避しながら前記第２の流れの宛先に到着するために、各ノードに前記第２の流れを送信させるようにするために前記ネットワークにある全てのノードにセグメント故障情報が通知されることにより、前記第２の流れの前記パケットを前記時計方向および反時計方向のいずれかの方向に送信させることができる請求項２１記載のデバイス。
24. 前記ＭＡＣブロックが、前記ネットワークを通して前記第２の流れのソース・ノードに故障表示メッセージを送信することができ、その結果、前記ソース・ノードが、前記メッセージに応じて、前記第２の流れの前記パケットの振り替えをスタートする請求項２３に記載のデバイス。
25. 前記ＭＡＣブロックが、さらに、前記第２の流れの前記パケットの振り替えがスタートした場合に、前記第１の流れの前記パケットも振り替えることができ、その場合に、前記パケットの折り返しを中断することができる請求項２４記載のデバイス。
26. 前記ＭＡＣブロックが、前記ネットワーク内の、他のノードに故障表示メッセージを送信することができ、前記ネットワークが、前記メッセージを受信した後で、前記故障したセグメントを回避しながら前記第１の流れの宛先に到着するように、前記時計方向および反時計方向の中の一方で、前記第１の流れの前記パケットを選択された一方向に送信させることができ、その場合、前記ＭＡＣブロックが、前記パケットの折り返しを中断する請求項２１〜２５のいずれか記載のデバイス。
27. 前記故障が継続している限り、前記ＭＡＣブロックに到着する前記第２の流れの前記パケットが廃棄される請求項２６記載のデバイス。
28. 前記第１の流れの前記パケット内で折り返しフラッグをセットし、また、前記第２の流れの前記パケット内の前記折り返しフラッグをリセットし、前記ＭＡＣブロックが、前記折り返しフラッグに応じて折り返される前記パケットを識別することができる請求項２１〜２５のいずれか記載のデバイス。
29. 前記第２の流れがリアルタイム・サービスに属していて、一方、前記第１の流れが、リアルタイム・サービスと比較した場合、前記パケットの供給の際に、遅延の変動および順序の混乱に対してかなり許容度が高いデータ送信サービスを含む請求項２１〜２５のいずれか記載のデバイス。
30. 前記リアルタイム・サービスが、パケット化された音声サービスおよびパケット化されたビデオ・サービスの中の少なくとも一方を含む請求項２９記載の方法。

Images