(57)【要約】【課題】レイヤ２／３スイッチ、伝送装置等がサポートするＲＰＲの送信経路をキャリアの運用にそって指定する。【解決手段】ＲＰＲの送信経路指定方法及び装置であって、左右両方向に通信ルートを持ち、複数のＲＰＲステーションを接続するＲＰＲに接続される制御装置とを含むシステムにおいて、ＲＰＲステーションの各々は、バイディレクショナルの通信方式の場合のフラッディングされたＲＰＲフレームを廃棄させるクリーブポイントを、ＲＰＲ上で通信を行わせたくないルート上に設定させ、ＲＰＲの左右両方向にＲＰＲフレームをフラッディングさせてＲＰＲステーションの各々においてＭＡＣアドレスの学習をさせ、受信したＲＰＲフレームを、ＭＡＣアドレスの学習結果に基づいて、ＲＰＲフレームのフラッディングが到着した通信ルートで通信を行う。【選択図】図１０Ａ
2008167008.tif 000002
【特許請求の範囲】
【請求項１】
複数のＲＰＲステーションを接続するレジリエント・パケット・リングと、該レジリエント・パケット・リングに接続され、前記複数のＲＰＲステーション及び前記レジリエント・パケット・リングを制御する制御装置とを含むシステムにおいて、前記ＲＰＲステーションの各々は、バイディレクショナルの通信方式の場合のフラッディングされたＲＰＲフレームを廃棄させるクリーブポイントを、前記レジリエント・パケット・リング上で通信を行わせたくないルート上に前記制御装置により設定させる第１ステップと、前記レジリエント・パケット・リングのリングレットの双方にＲＰＲフレームをフラッディングさせて前記ＲＰＲステーションの各々においてＭＡＣアドレスの学習をさせる第２ステップと、受信したＲＰＲフレームを、前記ＭＡＣアドレスの学習結果に基づいて、前記ＲＰＲフレームのフラッディングが到着した通信ルートで通信を行う第３ステップと、を備えたことを特徴としたＲＰＲの送信経路指定方法。
【請求項２】
複数のＲＰＲステーションを接続するレジリエント・パケット・リングと、該レジリエント・パケット・リングに接続され、前記複数のＲＰＲステーション及び前記レジリエント・パケット・リングを制御する制御装置とを含むシステムにおいて、前記ＲＰＲステーションの各々は、バイディレクショナルの通信方式の場合のフラッディングされたＲＰＲフレームを廃棄させるクリーブポイントを、前記制御装置により各ＲＰＲステーションまでの遅延時間の長い通信ルート上に自動で設定させる第１ステップと、前記レジリエント・パケット・リングのリングレットの双方にＲＰＲフレームをフラッディングさせて前記ＲＰＲステーションの各々においてＭＡＣアドレスの学習をさせる第２ステップと、受信したＲＰＲフレームを、前記ＭＡＣアドレスの学習結果に基づいて、前記ＲＰＲフレームのフラッディングが到着した通信ルートで通信を行う第３ステップと、を備えたことを特徴としたＲＰＲの送信経路指定方法。
【請求項３】
請求項２において、前記第１ステップは、前記ＲＰＲステーションの各々を通過するコントロールフレームを使用し、前記ＲＰＲステーションの各々が前記レジリエント・パケット・リングを構成する他のＲＰＲステーションまでの遅延時間を計算する第４ステップと、計算した遅延時間をもとに各ＲＰＲステーションから宛先のＲＰＲステーションまでの遅延時間が最も長い区間上のルートに前記クリーブポイントとなるように宛先までのＲＰＲステーション数の残数ＴＴＬを自動で設定する第５ステップと、を含むことを特徴としたＲＰＲの送信経路指定方法。
【請求項４】
複数のステーションを接続するレジリエント・パケット・リングと該レジリエント・パケット・リングに接続された制御装置とを含むシステムにおいて、クライアント側のポートおよびＶｌａｎを指定する第１ステップと、該ポートおよびＶｌａｎに対してはクリーブポイントとブリッジ機能の経路指定とは無関係に、指定した固定経路を介してパケットを送信させる第２ステップとを備えたことを特徴としたＲＰＲの送信経路指定方法。
【請求項５】
請求項４において、前記レジリエント・パケット・リング内で中継する各ＲＰＲステーションはあて先ＲＰＲ  Ｍａｃ宛のパケットの中継のみを実施する第３ステップと、前記レジリエント・パケット・リング内で前記固定経路のあて先となるＲＰＲステーションは前記レジリエント・パケット・リングからのフレームのドロップのみを実施する第４ステップと、を含むことを特徴としたＲＰＲの送信経路指定方法。
【請求項６】
複数のＲＰＲステーションを接続するレジリエント・パケット・リング（ＲＰＲ）と該レジリエント・パケット・リングに接続され、前記複数のＲＰＲステーション及び前記レジリエント・パケット・リングを制御する制御装置とを含むシステムにおいて、前記ＲＰＲステーションの各々は、バイディレクショナルの通信方式の場合のフラッディングされたＲＰＲフレームを廃棄させるポイントとして前記レジリエント・パケット・リング上に位置づけられるクリーブポイントを前記制御装置により設定させる第１手段と、前記レジリエント・パケット・リングのリングレットの双方にＲＰＲフレームをフラッディングさせて前記ＲＰＲステーションの各々においてＭＡＣアドレスの学習をさせる第２手段と、受信したＲＰＲフレームを前記レジリエント・パケット・リングのリングレットの双方のいずれに送信するかを、前記第２のステップで前記フレームが廃棄されなかったルートを通るように決定する第３手段と、を備えたことを特徴としたＲＰＲの送信経路指定装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はレジリエント・パケット・リング（ＲＰＲ）（Resilient Packet Ring : IEEE802.17に規定）の送信経路指定方法及び装置に関し、特に、通信事業者を中心にサービスが展開されている広域レイヤ２ネットワークにて使用されるイーサネット（登録商標）・インタフェースを具備する装置（レイヤ２／３スイッチ、伝送装置等）がサポートする、ＲＰＲの送信経路を指定する方法及び装置に関する。
【背景技術】
【０００２】
近年のデータ通信の高速化と広域化に伴い、レイヤ２／３ネットワークでのイーサネット（登録商標）サービスの需要が高まっている。その中で特に上位のプロトコルを意識しないネットワークとして、レイヤ２サービスの需要も伸びてきている。
【０００３】
従来、通信事業者が適用しているレイヤ２ネットワークの構築には、Ｌ２ＳＷとＷＤＭ（Wavelength Division Multiplexing）を組み合わせた構成、もしくはＬ２ＳＷとＡＤＭ（Add Drop Multiplexing）を組み合わせた構成で構築することが一般的であった。
【０００４】
しかし、ＷＤＭもしくはＡＤＭでの伝送はポイント・ツー・ポイントの伝送が一般的であり、ポイント・ツー・マルチポイントの伝送ができなかったり、１波長もしくは１ＳＴＳパスを固定的に使用するためイーサネット（登録商標）の特性であるバーストトラフィックを効率的に伝送することができなかった。
【０００５】
また、既存のレイヤ２ネットワークでは、Ｌ２ＳＷのもつプロテクション機能を使用するが、標準として規定されているものの切替時間はＳＴＰ（Spanning Tree Protocol IEEE : 802.1d）で４０秒程度、ＲＳＴＰ（Rapid Spanning Protocol:IEEE 802.1w）で２秒程度と、障害復旧能力が不十分であった。
【０００６】
このため、多対多の伝送、統計多重効果を用いたバーストトラフィックへの対応、および障害復旧がＳＤＨ／ＳＯＮＥＴの伝送装置並みの５０ｍｓｅｃ以下のレイヤ２技術が求められ、これらを解決するものとしてＲＰＲ（IEEE 802.17）が規定された。
【０００７】
以下にＲＰＲについて概略を示す。
図１はＲＰＲのリング構造の概略を示す図である。ＲＰＲは図１に示すように左右両回り（外回りと内回り）のリング構造をもち、各々をリングレットと呼ぶ。IEEE 802.17では外回り（時計回り）のリングレットをリングレット０、内回り（反時計回り）のリングレットをリングレット１と定義している。両方向にデータの送信を行うことができ、各ＲＰＲステーションではこのリングレットの帯域をシェアして伝送している。
【０００８】
またリングレットに接続された各ＲＰＲステーションはステーションアドレスを持っている。
図２は各ＲＰＲステーションが送受信する基本的なデータフレームのフォーマット示す図である。
図２において、ＴＴＬはTime To Liveの略であって、宛先ＲＰＲステーションまでのＲＰＲステーション数の残数を示す。送信元ＲＰＲステーションから送信されたフレームがＲＰＲステーションを通過するたびにＴＴＬの値を一つずつ減らし、ゼロになればそのフレームは廃棄される。
【０００９】
ベースコントロールの領域では、リングレット（０又は１）、フェアネス対象（Ｙ又はＮ）、フレーム種別（データ、コントロール、フェアネス又はアイドル）、サービスクラス（１１：クラスＡ０、１０：クラスＡ１、０１：クラスＢ、００：クラスＣ）、ラッピング対象（Ｙ又はＮ）について定義する。
【００１０】
ｄａはデスティネーション・アドレスであって、ステーションの宛先ＭＡＣアドレスである。
ｓａはソース・アドレスであって、ステーションの送り元ＭＡＣアドレスである。
【００１１】
ＴＴＬベースは、ＴＴＬの初期値である。ＴＴＬはフレームがＲＰＲステーション通過する毎に減少するが、ＴＴＬベース値はＴＴＬの初期値を示し続ける。トポロジ情報と照らし合わせてフレームの正当性を確認することに使用する。
【００１２】
エクステンデッド・コントロールでは、エクステンデッド・フレーム（Ｙ又はＮ）、フラッディング方法（無し、片方向又は両方向）、ストリクト・オーダ（ストリクト又はリラクスト）、その他について定義する。
Ｈｅｃ（Header Error Check）はＲＰＲヘッダの正当性確認のために使用される。
【００１３】
図３はレイヤ２のイーサネット（登録商標）フレームを中継するような場合に使用される拡張データフレームフォーマットを示す図である。
レイヤ２のイーサネット（登録商標）フレームを中継するような場合は、図３に示す拡張データフレームフォーマットのペイロードにイーサネット（登録商標）フレーム全体をマッピングする。
【００１４】
図４はコントロールフレームのフォーマットを示す図である。同図において、図２に示したデータフレームのフォーマットとの相違点は、図２におけるペイロードの代わりに図４におけるペイロードにはコントロールタイプと、コントロールバージョンと、コントロールデータユニットとが存在することである。
【００１５】
コントロールタイプには以下のものがある。
０１ｈ…ＣＴ＿ＳＴＡＴＩＯＮ＿ＡＴＤ
０２ｈ…ＣＴ＿ＴＯＰＯ＿ＰＲＯＴ
０３ｈ…ＣＴ＿ＴＯＰＯ＿ＣＨＫＳＵＭ
０４ｈ…ＣＴ＿ＬＲＴＴ＿ＲＥＱ
０５ｈ…ＣＴ＿ＬＲＴＴ＿ＲＳＰ
０６ｈ…ＣＴ＿ＦＤＤ
０７ｈ…ＣＴ＿ＯＡＭ＿ＥＣＨＯ＿ＲＥＱ
０８ｈ…ＣＴ＿ＯＡＭ＿ＥＣＨＯ＿ＲＳＰ
【００１６】
コントロールバージョンは０に固定されている。コントロールデータユニットはコントロールフレームフォーマット毎に定義されている。
【００１７】
ＲＰＲステーションは、リングトポロジを常に把握することでネットワークの変化や障害を検出する。リング上の各ステーションは、周期的（デフォルト１０ｍｓ）、もしくはステーションやリングのステータスに変化があった時に、上記制御フレームの一種であるＴＰ（topology and protection）フレームをブロードキャスト送信する。
【００１８】
図５は収集した各ステーションの情報から構築されたトポロジデータベースを示す図である。このトポロジデータベースに基づいて、リング全体のトポロジ構成を認識する。
【００１９】
ＲＰＲにおけるブロードキャストフレーム（アンノウン・ユニキャストフレーム含む）の送信方法にはユニキャスト・ディレクショナル・フラッディングとバイディレクショナル・フラッディングとの２種類がある。いずれのフラッディングでも、フレームを受信したステーションでＴＴＬ＝１又はｓａ（送信元アドレス）＝自ＭＡＣアドレスのときにそのフレームを廃棄する。
【００２０】
・ユニキャスト・ディレクショナル・フラッディング
一方のリングレットにのみフレームを送信する。フレームを送信する際に、ＴＴＬを「ステーション数−１」に設定する。
【００２１】
・バイディレクショナル・フラッディング
両方のリングレットにフレームを送信する。リングレット上にクリーブポイントを設定し、各リングレットに対して、クリーブポイントまでのホップ数をＴＴＬに設定する。どこをクリーブポイントにするかに関する規定は無いが、送信ステーションから最遠の地点、つまり（ステーション数−１）／２  又はステーション数／２とする場合がほとんどである。また、障害時は、障害箇所がクリーブポイントになる。
【００２２】
図６はIEEE 802.17bにおいて標準化されているスペーシャル・リユースの概要を説明するためのＲＰＲネットワークの構成を示す図であり、図７はそのスペーシャル・リユースの概要を説明するための図である。図６及び図７に示すように、ＲＰＲステーション間でフレームを伝送する際、片方向のみのリングレットを使ってフレームを送信する。このとき他方のリングレットは空いており、この空き帯域を他のフレーム伝送に使うことができる（IEEE 802.17ではスコープ外であった）。ＲＰＲステーションのＭＡＣアドレスとクライアント側のＭＡＣアドレスを関連付けて実施するが、詳細の方法についてはベンダーのインプリメントによるものとなっている。スペーシャル・リユースではＶＩＤ、クライアントＭＡＣアドレス、ステーションのアドレスを学習し、その結果をもとにユニキャスト通信を実施する。
【００２３】
【特許文献１】特開２００６−２６２１６９号公報
【特許文献２】特開２００２−３７４２７９号公報
【発明の開示】
【発明が解決しようとする課題】
【００２４】
上述のＲＰＲを使用し、イーサネット（登録商標）トラフィックを効率よく収容することが可能となったが、下記の理由により経路の指定をさせることができない。このため、キャリアの運用／サービスに柔軟に対応することができていない。
【００２５】
リング内のＲＰＲステーションがコントロールフレームのやりとりを実施し、リングトポロジを構築する。クライアント側からイーサネット（登録商標）フレームがリングに入力された場合、そのトポロジにそって最少ホップ数の経路にイーサネット（登録商標）フレームを送信する。このため、次の２つの課題がある。
【００２６】
第１の課題は、キャリアの運用ポリシーにそった経路への送信ができない、ということである。
図８はこの第１の課題を説明するためのＲＰＲシステムの構成図である。図８に示すように、例えば、東京のＲＰＲステーション８１にてクライアント８０側からイーサネット（登録商標）フレームがリングに入力されると、名古屋のＲＰＲステーション８７に接続されたクライアント８８向けのイーサネット（登録商標）フレームはトポロジの情報にそった最少ホップ数の経路により前橋のＲＰＲステーション８５、長野のＲＰＲステーション８６の経路で通信する。キャリアの運用ポリシーとしては、各エンドユーザの通信がどの経路を通って通信しているかを把握することにより、トラフィックの管理等を実施している。その上で障害のない通常時は運用管理の一環として、各エンドユーザのトラフィックはまとめて片側の経路に寄せて管理する、といった運用のポリシーを持って管理／保守を実施している（上記例では障害のない通常時は太平洋側経路にて通信させる、といった運用ポリシー）。
【００２７】
この結果、トポロジ情報にそった最少ホップ数の経路による送信の場合、キャリアの運用ポリシーに反し、意図しない経路での通信となる場合があり得る。
【００２８】
第２の課題は、キャリアのサービスに適した経路へパケット送信ができない、ということである。
図９はこの第２の課題を説明するためのＲＰＲシステムの構成図である。図９に示すように、例えば、東京のＲＰＲステーション８１にてクライアント８０側からイーサネット（登録商標）フレームがＲＰＲリングに入力されると、名古屋のＲＰＲステーション８７に接続されたクライアント８８向けのイーサネット（登録商標）フレームはトポロジの情報にそった最少ホップ数の経路により前橋、長野経路で通信する。
【００２９】
トポロジ情報にそった最少ホップ数の経路による送信の場合、前橋、長野経路が伝送距離が長く、遅延が大きいとしても、ホップ数の少ない前橋、長野経路で通信することになり、たとえばキャリアの低遅延サービス（遅延に厳しい音声などのサービス）を収容していた場合、キャリアのサービス・レベル・アグリーメント（ＳＬＡ）を保持することが困難となる。
【００３０】
また特許文献１には、クリーブポイントを設定しフレーム処理を行う、という技術が開示されているが、これはリング間を相互接続する方法として相互接続ステーション間と該別リングの（例えば）中間点にクリ−ブポイントを設定し、それにより複数リング間での障害切替および障害範囲の最小化を実施している技術であって、キャリアの運用にそった経路にフレームを送信させるシステムを提供する技術ではない。
【００３１】
同様に特許文献２にブリッジ機能を有するパケットスイッチノードにＭＡＣアドレス解決部を設け送信アドレスに対応したパケットパスへ振り分ける、という技術が開示されているが、これはパスラベルという概念を用いて、学習結果に基づいてパスラベルにパケットをマッピングする技術であり、そのノードから左右方向どちらの経路にパケットを送出するかまでの指定はしていない技術であって、キャリアの運用にそった経路にフレームを送信させるシステムを提供する技術ではない。
【００３２】
以上のように、キャリアの運用の観点から、ＲＰＲにおける送信経路指定の方法が求められている。
本発明は、通信事業者を中心に展開されているイーサネット（登録商標）サービスを各種装置にて構成する場合に、前述の問題点を踏まえ、次に示す課題を解決するものである。
【００３３】
現状では、通信事業者が適用しているＬ２サービスには、IEEE802.17にて規定されているＲＰＲが利用されつつあるが、送信経路の指定方法までは規定されていないことにより、前述したように、キャリアの運用にそったシステムを提供できないという課題が出てきている。
【００３４】
本発明は、通信事業者を中心にサービスが展開されている広域レイヤ２ネットワークにて使用されるイーサネット（登録商標）インタフェースを具備する装置（レイヤ２／３スイッチ、伝送装置等）がサポートする、レジリエント・パケット・リングＲＰＲ（Resilient Packet Ring IEEE802.17に規定）の送信経路を、キャリアの運用にそって指定する方式を提供することを目的とする。
【課題を解決するための手段】
【００３５】
本発明の第１の態様によれば、複数のＲＰＲステーションを接続するレジリエント・パケット・リングに接続され、複数のＲＰＲステーション及びレジリエント・パケット・リングを制御する制御装置を含むシステムにおいて、ＲＰＲステーションの各々は、バイディレクショナルの通信方式の場合のフラッディングされたＲＰＲフレームを廃棄させるクリーブポイントを、レジリエント・パケット・リング上で通信を行わせたくないルート上に制御装置により設定させる第１ステップと、レジリエント・パケット・リングのリングレットの双方にＲＰＲフレームをフラッディングさせてＲＰＲステーションの各々においてＭＡＣアドレスの学習をさせる第２ステップと、受信したＲＰＲフレームを、ＭＡＣアドレスの学習結果に基づいて、ＲＰＲフレームのフラッディングが到着した通信ルートで通信を行う第３ステップと、を備えたことを特徴としたＲＰＲの送信経路指定方法が提供される。
【００３６】
本発明の第２の態様によれば、複数のＲＰＲステーションを接続するレジリエント・パケット・リングに接続され、複数のＲＰＲステーション及びレジリエント・パケット・リングを制御する制御装置を含むシステムにおいて、ＲＰＲステーションの各々は、バイディレクショナルの通信方式の場合のフラッディングされたＲＰＲフレームを廃棄させるクリーブポイントを、制御装置により各ＲＰＲステーションまでの遅延時間の長い通信ルート上に自動で設定させる第１ステップと、レジリエント・パケット・リングのリングレットの双方にＲＰＲフレームをフラッディングさせてＲＰＲステーションの各々においてＭＡＣアドレスの学習をさせる第２ステップと、受信したＲＰＲフレームを、ＭＡＣアドレスの学習結果に基づいて、ＲＰＲフレームのフラッディングが到着した通信ルートで通信を行う第３ステップと、を備えたことを特徴としたＲＰＲの送信経路指定方法が提供される。
【００３７】
本発明の第３の態様によれば、第２の態様において、第１ステップは、ＲＰＲステーションの各々を通過するコントロールフレームを使用し、ＲＰＲステーションの各々がレジリエント・パケット・リングを構成する他のＲＰＲステーションまでの遅延時間を計算する第４ステップと、計算した遅延時間をもとに各ＲＰＲステーションから宛先のＲＰＲステーションまでの遅延時間が最も長い区間上のルートにクリーブポイントとなるように宛先までのＲＰＲステーション数の残数ＴＴＬを自動で設定する第５ステップと、を含む。
【００３８】
本発明の第４の態様によれば、複数のステーションを接続するレジリエント・パケット・リングに接続された制御装置を含むシステムにおいて、クライアント側のポートおよびＶｌａｎを指定する第１ステップと、そのポートおよびＶｌａｎに対してはクリーブポイントとブリッジ機能の経路指定とは無関係に、指定した固定経路を介してパケットを送信させる第２ステップとを備えたことを特徴としたＲＰＲの送信経路指定方法が提供される。
【００３９】
本発明の第５の態様によれば、第４の態様において、レジリエント・パケット・リング内で中継する各ＲＰＲステーションはあて先ＲＰＲ  Ｍａｃ宛のパケットの中継のみを実施する第３ステップと、レジリエント・パケット・リング内で固定経路のあて先となるＲＰＲステーションはレジリエント・パケット・リングからのフレームのドロップのみを実施する第４ステップと、を含む。
【００４０】
本発明の第６の態様によれば、上記第１から第５の態様による方法を実施する装置も提供される。
【発明の効果】
【００４１】
バイディレクショナルの通信方式の場合のフラッディングされたＲＰＲフレームを廃棄させるクリーブポイントを、レジリエント・パケット・リング上で通信を行わせたくないルート上に設定したり、送信経路を指定するようにしたので、キャリアの運用ポリシーにそった経路への送信ができ、且つ、キャリアのサービスに適した最少ホップ数の経路によりパケット送信が可能になる。
【発明を実施するための最良の形態】
【００４２】
以下、図面により本発明の実施例を説明する。全図において同一参照番号は同一の物を表わす。
本発明では、レイヤ２／３ネットワーク構成における、イーサネット（登録商標）インタフェースを具備する装置（レイヤ２／３スイッチ，伝送装置等）がサポートする、ＲＰＲ（Resilient Packet Ring:IEEE802.17に規定）に対し、以下の手段を講じることで前述した課題を解決するものである。
【実施例１】
【００４３】
図１０Ａから図１４は本発明の実施例１を説明する図である。
図１０Ａは本発明の実施例１によりクリーブポイントを設定する送信経路指定方法及び装置を説明するためのシステム構成図である。図１０Ｂは各ＲＰＲステーションが具備するリング側ブリッジ機能（入力されたフレームをＭａｃアドレスの学習結果に基づいて左右のいずれのリングに流すかを決定する機能）を説明する表図である。
【００４４】
図１０Ａにおいて、１００は送信側クライアント端末、１０１は東京のＲＰＲステーション、１０２は横浜のＲＰＲステーション、１０３は熱海のＲＰＲステーション、１０４は静岡のＲＰＲステーション、１０５は名古屋のＲＰＲステーション、１０６は長野のＲＰＲステーション、１０７は前橋のＲＰＲステーション、１０８は宛先クライアント端末、１０９は設定されたクリーブポイント、１１０は各ＲＰＲステーションを制御するオペレーションセンタ、１１１はレジリエント・パケット・リング（以下、ＲＰＲリングという）、１１２はＲＰＲリング１１１の右回りのリングレット０、１１３はＲＰＲリング１１１の左回りのリングレット１である。オペレーションセンター１１０は各ＲＰＲステーションの監視センタの役割を果たす制御装置である。
【００４５】
本実施例では、バイディレクショナルでフラッディングされたＲＰＲフレームを廃棄させるクリーブポイントを、オペレーションセンター１１０を手動制御することにより、ＲＰＲリング１１０上で通信を行わせたくないルート上に設定する。
【００４６】
図１０Ｂにおいて、各ＲＰＲステーションは図示のようなリング側ブリッジ機能を表すＲＰＲリング側フォワーディングテーブルを備えている。このテーブルは、フレームを受信した結果得られる学習結果を格納するもので、自ＲＰＲステーションの入力ポート番号と入力されたフレームをリングレット０（左回り）と１（右回り）のいずれに送信するかに関する情報であるリングレットを格納する部分と、送信元のエンドユーザ（法人等）の識別子であるＶＬＡＮＩＤ（以下ＶＩＤと記す）を含むサービス・プロバイダ・タグ（Ｓ−タグ）と、送信元のＲＰＲステーションのアドレスであるＲＰＲＭａｃアドレスと、エンドユーザ配下の送信元クライアントのＭａｃアドレスとを含む。
【００４７】
図１１は図１０Ａにおける各ＲＰＲステーションの構成例を示すブロック図である。図１１において、各ＲＰＲステーションのリング側には、ＭＡＣクライアント部１１４、ＭＡＣクライアント部１１４に相互接続されたＭＡＣ制御部１１５、ＭＡＣクライアント部１１４に接続されたリングレット選択部１１６、入力がリングレット選択部１１６に接続され、出力がＭａｃ制御部１１５に接続された、リングレット０用及びリングレット１用のデータパス部１１７、データパス部１１７にそれぞれ相互接続されたリング側インタフェース１１８、ＲＰＲリングレットのトポロジ情報を格納するトポロジデータベース１１９、及びリング側の経路を決定するリング側フォワーディングテーブル１２０を備えている。リングインターフェース部１１８はリング側入出力ポートＡ及びＢにそれぞれ接続されている。
【００４８】
また、各ＲＰＲステーションのクライアント側は、それぞれが複数のポートに相互接続された複数のＬａｎインタフェース部１２１、Ｌａｎインターフェース部１２１に相互接続された１個のスイッチ部１２２、およびＲＰＲリングに接続されるクライアント側のポートを決定するクライアント側フォワーディングテーブル１２３を備えている。
【００４９】
なお、ＭＡＣ制御部１１５は、制御インタフェース、フェアネスアルゴリズム、プロテクション、トポロジ管理、ＯＡＭ、及び制御フレームの送受信の各機能を有し、リングレット選択部１１６は、リングレット選択、フラッディング選択、及びフレームフォーマット選択の各機能を有し、さらにデータパス部１１７の各々は、カプセル化／デカプセル化、シェ−ピング、キューイング、フレーム廃棄（strip）、及びフレームの送受信の各機能を有する。
【００５０】
図１２は図１０Ａに示したシステムにおいて、東京のＲＰＲステーション１０１から名古屋のＲＰＲステーション１０５に向けてイーサネット（登録商標）フレームが送信された場合の状態を説明する図であり、図１３は１０Ａに示したシステムにおいて、図１２に示した状態の後に名古屋のＲＰＲステーション１０５から東京のＲＰＲステーション１０１向けてイーサネット（登録商標）フレームが送信された場合の状態を説明する図であり、図１４は図１３に示した状態の後に、東京のＲＰＲステーション１０１配下のクライアントにフレームが到達する状態を説明する図である。
【実施例２】
【００５１】
図１５Ａは本発明の実施例２によりクリーブポイントを自動設定する送信経路指定方法及び装置を説明するためのシステム構成図である。同図において１５は自動設定されたクリーブポイントである。図１５Ｂは図１５Ａにおける各ＲＰＲステーションが具備するリング側ブリッジ機能を説明する表図である。
【００５２】
図１６Ａは図１５ＡにおけるＬＲＴＴ（ループ・ラウンド・トリップ・タイム）リクエスト・フレームのペイロードのフォーマットを示す図である。
【００５３】
図１６Ｂは図１５ＡにおけるＬＲＴＴ（ループ・ラウンド・トリップ・タイム）レスポンス・フレームのペイロードのフォーマットを示す図である。
【実施例３】
【００５４】
図１７及び図１８は本発明の実施例３によるＰＲＰ経路のスタティックな設定をする送信経路指定方法及び装置を説明するためのシステム構成図である。本実施例３においては、実施例１又は２でクリーブポイントが設定されていてもこのクリーブポイント及びブリッジ機能とは無関係に、手動で指定した経路を固定的に（スタティックに）使用して通信を行う。
【００５５】
図１９Ａから図１９Ｄは本発明の全ての実施例による送信経路指定方法を説明するフローチャートである。
最初に図１０〜図１４に示した本発明の実施例１による送信経路指定方法を説明する。
図１９Ａにおいて、ステップ１９０１にて、リング１１１上のＲＰＲステーション１０１〜１０７の各々に、イーサネット（登録商標）インターフェースを具備する装置（レイヤ２／３スイッチ、伝送装置等）であってＲＰＲ機能を具備しているものを設ける。また、ＲＰＲステーション１０１〜１０７の各々に設けられた上記装置はリング側のブリッジ機能が動作している状態にする（図１０Ｂの（１）−１）。ブリッジ機能とは、入力されたフレームがリングレット０（右回り）のポートから入ってきたフレームなのか、リングレット１（左回り）のポートから入ってきたフレームなのかを学習させる機能である。
【００５６】
次いでステップ１９０２にて、ＯＰＳ１１０は各ＲＰＲステーションをバイディレクショナルの通信方式に設定する(図１０Ａの（１）−２）。これによりブロードキャストフレーム（アンノウン・ユニキャストフレーム含む）は下記のように設定されるクリーブポイント１０９まで到達し、そこで廃棄されることになる。
【００５７】
次にステップ１９０３にて、ＯＰＳ１１０を手動制御することにより、各ＲＰＲステーションは、クリーブポイント１０９を設定する（図１０Ａの（２））。このクリーブポイント１０９は、ＲＰＲリング上で通信を行わせたくないルート上に設定する。図示例では、東京のＲＰＲステーション１０１が設定したクリーブポイント１０９のみを示してある。
【００５８】
例えば、東京のＲＰＲステーション１０１において、東京から長野へ通信はリングレット０を用いて通信をしたいというポリシーがある場合は、ＯＰＳ１１０を手動制御することにより、長野と前橋の間にクリーブポイント１０９を設定する。これにより、東京⇒長野、東京⇒名古屋、東京⇒静岡、東京⇒熱海、あるいは東京⇒横浜向けの通信はリングレット０を使用して通信することになる。また東京⇒前橋向けの通信はリングレット１を使用して通信することになる。具体的には東京のＲＰＲステーション１０１は設定されたクリーブポイント１０９の位置をＯＰＳ１００から通知され、クライアント側から入ってきたイーサネット（登録商標）フレームをＲＰＲフレームにカプセリング（結合）するとき、そのクリーブポイントに応じて、リングレット０に送信するときはＴＴＬ＝５、リングレット１に送信するときはＴＴＬ＝１にセットすることになる。
【００５９】
同様に、名古屋のＲＰＲステーション１０５において、名古屋から東京への通信はリングレット１を用いて通信をしたいというポリシーがある場合は、ＯＰＳ１１０を手動制御することにより、長野と前橋の間にクリーブポイントを設定する。これにより、名古屋⇒静岡、名古屋⇒熱海、名古屋⇒横浜、名古屋⇒東京、あるいは名古屋⇒前橋向けの通信はリングレット１を使用して通信することになる。また名古屋⇒長野向けの通信はリングレット０を使用して通信することになる。具体的には名古屋のＲＰＲステーション１０５は設定されたにクリーブポイントの位置をＯＰＳ１００からから通知され、クライアント側から入ってきたイーサネット（登録商標）フレームをＲＰＲフレームにカプセリングするとき、そのクリーブポイントに応じて、リングレット１に送信するときはＴＴＬ＝５、リングレット０に送信するときはＴＴＬ＝１にセットすることになる。
【００６０】
次いで、ステップＳ１９０４にて、各ＲＰＲステーション配下の端末から、別のＲＰＲステーション配下の端末宛のフレームを送信する。
図１２は東京から名古屋に向けて通信を行う場合の具体例を示す図である。図１２において、東京のＲＰＲステーション１０１に、クライアント端末１００側から名古屋のＲＰＲステーション１０５に向けてイーサネット（登録商標）フレームが入力される（図１２の（３）、Ｍａｃ＝ａ→Ｍａｃ＝ｂのフレーム）。
【００６１】
このとき、東京のＲＰＲステーション１０１のクライアント側では、受信したフレームが未学習のフレームなので、ステップＳ１９０５にて、クライアント側学習テーブル(図１２の（４））に受信フレームの入力ポート１、Ｓ−タグ中のＶＬＡＮの識別子（法人等の識別子）であるＶＩＤ＝１０、送信元ＭＡＣアドレスｓａ＝ａを登録する。
【００６２】
次いで、ステップ１９０６にて、東京のＲＰＲステーション１０１では、リング側フォワーディング学習テーブルを検索して宛先が学習済みか否かを判定する。最初は、受信したフレームは未学習状態であるので、ステップＳ１９０７にて、リングレット０のポート３とリングレット１のポート４の両経路に受信したフレームをフラッディングする（図１２の（５））。
【００６３】
次いで、ステップ１９０８にて、リング内の各ＲＰＲステーション１０２、１０３、１０４、１０５、１０７でも、受信したフレームが未学習状態であるため、宛先クライアント端末が配下に存在しているかどうかを認識できないので、受信したフレームを配下にドロップするとともに、中継側にスルーする。また、リング側フォワーディングテーブルに、入力ポートと入力されたフレームが流れて来たリングレット（１又は０）、送信元の法人等のＶＬＡＮの識別子であるＳ−タグ中のＶＩＤ＝１０、送信元ステーションのＲＰＲ  Ｍａｃアドレス（図では理解を容易にするためにtokyoと記載されているが、実際には英数字で現される識別子である）、送信元のクライアントＭａｃアドレスａを登録する。リングレット０から長野のＲＰＲステーション１０６に到着したフレームもドロップとスルーとがされるが、スルーしたフレームはクリーブポイント１０９にて廃棄される。また、リングレット１から前橋のＲＰＲステーション１０７に到着したフレームもドロップとスルーとがされるが、スルーしたフレームはクリーブポイント１０９にて廃棄される。
【００６４】
ステップ１９０９では、宛先端末を配下に持つ名古屋のＲＰＲステーション１０５におけるリング側フォワーディング学習テーブルにおけるフレームの受信を説明している。基本的には、ステップ１９０８と同じであるが、ステップ１９０９では、宛先端末を配下に持つ名古屋のＲＰＲステーション１０５は、クリーブポイントにより指定した経路、この場合はリングレット０からのみフレームを受信して、ステップ１９０８で行ったのと同じように、リング側フォワーディングテーブルに、入力ポート４とリングレット０、送信元の法人等のＶＬＡＮの識別子であるＳ−タグ中のＶＩＤ＝１０、送信元ステーションのＲＰＲ  Ｍａｃアドレス、送信元のクライアントＭａｃアドレスａを登録する。
【００６５】
こうして、ステップ１９１０にて、最終的に名古屋のＲＰＲステーション１０５にてドロップされたフレームがＭａｃアドレス＝ｂである宛先クライアント端末１０８に届く（図１２の（６））。
【００６６】
ステップ１９０７からステップ１９１０の処理のより、東京のＲＰＲステーション１０１と名古屋のＲＰＲステーション１０５の間の全ＲＰＲステーションにおけるＲＰＲリング側フォワーディングテーブルに、送信元ステーションのＲＰＲ  Ｍａｃアドレスと送信元クライアントのＭａｃアドレスａが学習される。
【００６７】
次いで、図１９Ｂのステップ１９１１から１９１３にて、ステップ１９０４からステップ１９０６と同じ動作が、名古屋の各ＲＰＲステーション１０５で行われ、名古屋のＲＰＲステーション１０５にて図１２の（４）に示したようなクライアント側学習テーブルが作成され、リング側フォワーディングテーブルが未学習であればステップ１９０８〜１９１０と同じ動作が繰り返されて、リング側フォワーディングテーブルに図１２の（６）に示したものと同様の形式の内容が登録される。
【００６８】
ステップ１９０６又は１９１３にて、リング側フォワーディングテーブルに宛先クライアントＭａｃアドレスが登録済みであれば、ステップ１９１４に進み、例えば、名古屋のＲＰＲステーション１０５の配下のクライアント１０８と東京のＲＰＲステーション１０１の配下のクライアント１００との間の通信経路を確立するためには、名古屋のＲＰＲステーション１０５の配下のクライアント１０８から東京のＲＰＲステーション１０１の配下のクライアント１００宛のイーサネット（登録商標）フレーム（Ｍａｃ＝ｂ→Ｍａｃ＝ａのフレーム）が、名古屋のＲＰＲステーション１０５に入力される。このとき、名古屋のＲＰＲステーション１０５では受信したフレームは未学習であるので、クライアント側学習テーブルに入力ポート１０、ＶＩＤ＝１０、送信元Ｍａｃアドレスｓａ＝ｂを登録する（図１３の（８））。
【００６９】
また、名古屋のＲＰＲステーション１０５では、受信フレーム中の宛先アドレスａが学習済みのＲＰＲフォワーディングテーブル中の送信元クライアントＭａｃアドレスａと一致することから、宛先が東京のＲＰＲステーション１０１の配下のクライアント端末１００であることを検出し、且つ、リング側の送信ポート４及びリングレット１を検出し、Ｓ−タグ中のＶＩＤが１０で、宛先のＲＰＲステーションが東京であることを検出して、リング側フォワーディングテーブルにこれらの値を登録する（図１３の（９））。そして、そのリングレット１の経路にそのフレームを送信する。
【００７０】
次いで、ステップ１９１５でも、受信フレーム中の宛先アドレスａが学習済みのＲＰＲフォワーディングテーブル中の送信元クライアントＭａｃアドレスａと一致することから、宛先が東京のＲＰＲステーション１０１の配下のクライアント端末１００であることを検出し、且つ、リング側の送信ポート４及びリングレット１を検出し、Ｓ−タグ中のＶＩＤが１０で、宛先のＲＰＲステーションが東京であることを検出して、リング側フォワーディングテーブルにこれらの値を登録する（図１４の（１０））。そして、そのリングレット１の経路にそのフレームを送信する。
【００７１】
次いで、ステップ１９１６にて、東京のＲＰＲステーション１０１では、クリーブポイント１０９を指定したことにより、名古屋からはリングレット１の経路のみからフレームを受信する。東京のＲＰＲステーション１０１でも、他のＲＰＲステーションと同様に、リング側フォワーディングテーブルに受信ポート番号と受信リングレット、S-タグ中のＶＩＤ、送信元Ｍａｃアドレス、送信元クライアントアドレスを登録する。さらに、クライアント側学習テーブルと受信フレームの宛先Ｍａｃアドレスとを照合した結果、受信フレームの宛先Macアドレスが自ＲＰＲステーション宛であるので、ドロップ処理のみ実施する(図１４の（１１））。
【００７２】
こうして、ステップ１９１７にて、宛先クライアント端末１００の上位のステーションである東京のＲＰＲステーション１０１にてドロップされたフレームが宛先クライアント端末１００に届く。
【００７３】
図１９Ｃは本発明の実施例２による送信経路指定方法を説明するフローチャートである。本実施例ではステップ１９１８及び１９１９は実施例１におけるステップ１９０１及び１９０２と同じであり、ここでは説明を省略する。
【００７４】
本実施例２では、ステップ１９２０でＯＰＳ１１０（図１５Ａ）より各ＲＰＲステーションにおけるクリーブポイントの設定モードを遅延モードに設定する。
【００７５】
次いでステップ１９２１で、各ＲＰＲステーションは、コントロールフレームを使用し、各々のＲＰＲステーションがリングを構成する他のＲＰＲステーションまでの遅延時間を計算する。各ＲＰＲステーションは計算した遅延時間をもとに各ＲＰＲステーションからもっとも遅延の長い区間がクリーブポイントとなるようにＴＴＬを自動で設定する。
【００７６】
東京のＲＰＲステーション１０１における遅延モードによるクリーブポイントの設定を例として以下に説明する。
遅延時間測定にはコントロールフレームの一つであるループ・ラウンド・トリップ・タイムＬＲＴＴ（Loop Round Trip Time）フレームを使用する。
【００７７】
図１６ＡはＬＲＴＴフレームのリクエストペイロードを示す図であり、図１６ＢはＬＲＴＴフレームのレスポンスペイロードを示す図である。
【００７８】
東京のＲＰＲステーション１０１が、リング内の各ＲＰＲステーションに対してリングレット０及びリングレット１のそれぞれに対してＬＲＴＴフレームを使用して遅延時間を測定する。
【００７９】
測定の結果、東京⇒長野向けの遅延時間がもっとも長く、リングレット０の経路が４５０μｓ、リングレット１の経路が５００μｓであった場合、遅延時間の長い長野と前橋の間にクリーブポイントを設定する。これにより、東京⇒長野、東京⇒名古屋、東京⇒静岡、東京⇒熱海、あるいは東京⇒横浜向けの通信は、遅延時間の短いリングレット０を使用して通信することになる。また東京⇒前橋向けの通信も同様に遅延時間の少ないリングレット１を使用して通信することになる。具体的には東京においてクライアント側から入ってきたイーサネット（登録商標）フレームをＲＰＲフレームに結合するとき、リングレット０に送信するときはＴＴＬ＝５、リングレット１に送信するときはＴＴＬ＝１にセットする。
【００８０】
同様に、名古屋のＲＰＲステーション１０５を例に取ると、遅延時間測定の結果、遅延時間のもっとも長い長野と前橋の間にクリーブポイントを設定する。これにより、名古屋⇒静岡、名古屋⇒熱海、名古屋⇒横浜、名古屋⇒東京、あるいは名古屋⇒前橋向けの通信は遅延時間の少ないリングレット１を使用して通信することになる。また名古屋⇒長野向けの通信も同様に遅延時間の少ないリングレット０を使用して通信することになる。具体的には名古屋においてクライアント側から入ってきたイーサネット（登録商標）フレームをＲＰＲフレームに結合するとき、リングレット１に送信するときはＴＴＬ＝５、リングレット０に送信するときはＴＴＬ＝１にセットする。
【００８１】
ステップ１９２１の後は、図１９Ａに示したステップ１９０４〜１９１０と同じ動作をする。これにより低遅延でのサービス収容が可能となる。
【００８２】
図１９Ｄは本発明の実施例３による送信経路指定方法を説明するフローチャートである。本実施例ではステップ１９２２にて、実施例１及び２と同様にリング１１１上のＲＰＲステーション１０１〜１０７の各々に、イーサネット（登録商標）インターフェースを具備する装置（レイヤ２／３スイッチ、伝送装置等）であってＲＰＲ機能を具備しているものを設けるが、実施例１及び２と異なりリング側のブリッジ機能が動作している状態にする必要はない。
【００８３】
次いでステップ１９２３で、ＯＰＳ１１０から始点ＲＰＲステーションと終点ＲＰＲステーションのＲＰＲフォワーディングテーブルに、送信及び受信ポート及びリングレット、送受信に用いられるＳ−タグに含まれるＶＬＡＮの識別子ＶＩＤ、送信元及び宛先のＲＰＲステーションのＭａｃアドレス、及びスタティックフラグを設定する。スタティックな通信の場合は、通信をするＲＰＲステーションはＯＰＳ１１０により設定されるので、クライアント端末のＭａｃアドレスは設定不要である。
【００８４】
また、クライアント側学習テーブルには、送信及び受信ポート、送受信に用いられるＳ−タグに含まれるＶＬＡＮの識別子ＶＩＤ、及びスタティックフラグを設定する。
【００８５】
図１７に示す例では、東京のＲＰＲステーション１０１から名古屋のＲＰＲステーション１０５宛の固定の通信を行う例を示している。
図示例では、東京のＲＰＲステーション１０１のＲＰＲリング側フォワーディングテーブルには、送信経路としてポート３とリングレット０、Ｓ−タグに含まれるＶＬＡＮの識別子であるＶＩＤ１０、宛先ＲＰＲステーションのＭａｃアドレス(nagoya)、宛先クライアントのＭａｃアドレス、及びスタティック通信であるか否かを示すスタティックフラグ(yes)が設定されている（図１７の(１)）。また、クライアント側学習テーブルには、スタティック通信であるか否かを示すスタティックフラグ(yes)が設定されている（図１７の（２））。
【００８６】
また、名古屋のＲＰＲステーション１０５のＲＰＲリング側フォワーディングテーブルには、送信経路としてポート４とリングレット１、Ｓ−タグに含まれるＶＬＡＮの識別子であるＶＩＤ１０、宛先ＲＰＲステーションのＭａｃアドレス(tokyo)、宛先クライアントのＭａｃアドレス、及びスタティック通信であるか否かを示すスタティックフラグ(yes)が設定されている（図１７の（３）。クライアント側学習テーブルには、スタティック通信であるか否かを示すスタティックフラグ(yes)が設定されている（図１７の（４））。
【００８７】
次いでステップ１９２４にて、送信元ＲＰＲステーション（図示例では東京のＲＰＲステーション１０１）配下の一つの端末（図示例ではクライアント端末１００）から、送信宛ＲＲＲステーション（図示例では名古屋のＲＰＲステーション１０５）１０５配下のクライアント端末（図示例ではクライアント端末１０８）に宛ててＶＩＤ＝１０のイーサネトフレームを送信する。
【００８８】
ステップ１９２５では、フレームを受信したＲＰＲステーションは、アドレス未学習時のクライアント側学習テーブルに入力ポート、ＶＩＤ、送信元Ｍａｃアドレスを登録する。図示例では東京のＲＰＲステーション１０１ではクライアント端末１００からフレームを受信すると、入力ポート１、ＶＩＤ１０、及び送信元Ｍａｃアドレスを登録する。
【００８９】
次いでステップ１９２６にて、送信元のＲＰＲステーションのリング側フォワーディングテーブルを検索して、スタティックフラグが設定されているか否かを検索する。図示例では東京のＲＰＲステーション１０１リング側フォワーディングテーブルを検索し、受信フレームがスタティク設定されたフレームであることを検出する。
【００９０】
また、ステップ１９２７にて、スタティック設定された宛先ＰＲＰＭａｃアドレスが名古屋であることを検出し、且つスタティック設定されたリング側の送信ポート(リングレット）が３（０）であることを検出して、そのリングレット０のポート１、ＶＩＤ＝１０のフレームであるので、そのポート３のリングレット０に名古屋宛のフレームを送信する(図１８の（５））。
【００９１】
ステップ１９２８では、クライアント端末１００からフレームを受信した東京のＲＰＲステーション１０１と宛先ＲＰＲステーションである名古屋のＲＰＲステーション１０５との間の各ＲＰＲステーションでは、宛先ＲＰＲステーションのＭａｃアドレスが自己のＭａｃアドレスではないので、中継側へスルーのみを実施する(図１８の（６））。
【００９２】
ステップ１９２９では、宛先ＲＰＲステーションである名古屋のＲＰＲステーション１０５では、受信したフレーム中の送信元ＲＰＲ  Ｍａｃアドレス及びＶＩＤをＲＰＲリング側フォワーディングテーブルに登録されている送信元ＲＰＲ  Ｍａｃアドレス及びＶＩＤと照合し、一致したので、受信したフレームのドロップのみを実施する(図１８の（７））。こうして、ステップ１９３０にて、ドロップされたフレームが宛先クライアント端末１０８に届く。
【００９３】
名古屋⇒東京方向のスタティックな送信も上記と同様である。
なお、スタティック設定は、実施例１で説明した手動でのクリーブポイント設定や実施例２で説明した遅延時間によるクリーブポイント設定と併用して使用することが可能である。これにより、あるユーザ（もしくはサービス）のＶＩＤのみ、手動もしくは遅延での経路に無関係にスタティック設定できるため、柔軟なシステムを構築することが可能である。
【００９４】
また障害時、手動もしくは遅延設定でのクリーブポイントは、ＩＥＥＥ  ８０２．１７規定のとおり障害箇所に移動するが、スタティック設定は切替を実施するのみの動作となる。
（付記１）複数のＲＰＲステーションを接続するレジリエント・パケット・リング（ＲＰＲ）と、該レジリエント・パケット・リングに接続され、前記複数のＲＰＲステーション及び前記レジリエント・パケット・リングを制御する制御装置とを含むシステムにおいて、前記ＲＰＲステーションの各々は、バイディレクショナルの通信方式の場合のフラッディングされたＲＰＲフレームを廃棄させるクリーブポイントを、前記レジリエント・パケット・リング上で通信を行わせたくないルート上に前記制御装置により設定させる第１ステップと、前記レジリエント・パケット・リングのリングレットの双方にＲＰＲフレームをフラッディングさせて前記ＲＰＲステーションの各々においてＭＡＣアドレスの学習をさせる第２ステップと、受信したＲＰＲフレームを、前記ＭＡＣアドレスの学習結果に基づいて、前記ＲＰＲフレームのフラッディングが到着した通信ルートで通信を行う第３ステップと、を備えたことを特徴としたＲＰＲの送信経路指定方法。
（付記２）複数のＲＰＲステーションを接続するレジリエント・パケット・リングと、該レジリエント・パケット・リングに接続され、前記複数のＲＰＲステーション及び前記レジリエント・パケット・リングを制御する制御装置とを含むシステムにおいて、前記ＲＰＲステーションの各々は、バイディレクショナルの通信方式の場合のフラッディングされたＲＰＲフレームを廃棄させるクリーブポイントを、前記制御装置により各ＲＰＲステーションまでの遅延時間の長い通信ルート上に自動で設定させる第１ステップと、前記レジリエント・パケット・リングのリングレットの双方にＲＰＲフレームをフラッディングさせて前記ＲＰＲステーションの各々においてＭＡＣアドレスの学習をさせる第２ステップと、受信したＲＰＲフレームを、前記ＭＡＣアドレスの学習結果に基づいて、前記ＲＰＲフレームのフラッディングが到着した通信ルートで通信を行う第３ステップと、を備えたことを特徴としたＲＰＲの送信経路指定方法。
（付記３）付記２において、前記第１ステップは、前記ＲＰＲステーションの各々を通過するコントロールフレームを使用し、前記ＲＰＲステーションの各々が前記レジリエント・パケット・リングを構成する他のＲＰＲステーションまでの遅延時間を計算する第４ステップと、計算した遅延時間をもとに各ＲＰＲステーションから宛先のＲＰＲステーションまでの遅延時間が最も長い区間上のルートに前記クリーブポイントとなるように宛先までのＲＰＲステーション数の残数ＴＴＬを自動で設定する第５ステップと、を含むことを特徴としたＲＰＲの送信経路指定方法。
（付記４）複数のステーションを接続するレジリエント・パケット・リングと該レジリエント・パケット・リングに接続された制御装置とを含むシステムにおいて、クライアント側のポートおよびＶｌａｎを指定する第１ステップと、該ポートおよびＶｌａｎに対してはクリーブポイントとブリッジ機能の経路指定とは無関係に、手動で指定した固定経路を介してパケットを送信させる第２ステップとを備えたことを特徴としたＲＰＲの送信経路指定方法。
（付記５）付記４において、前記レジリエント・パケット・リング内で中継する各ＲＰＲステーションはあて先ＲＰＲ  Ｍａｃ宛のパケットの中継のみを実施する第３ステップと、前記レジリエント・パケット・リング内で前記固定経路のあて先となるＲＰＲステーションは前記レジリエント・パケット・リングからのフレームのドロップのみを実施する第４ステップと、を含むことを特徴としたＲＰＲの送信経路指定方法。
（付記６）複数のＲＰＲステーションを接続するレジリエント・パケット・リング（ＲＰＲ）と該レジリエント・パケット・リングに接続され、前記複数のＲＰＲステーション及び前記レジリエント・パケット・リングを制御する制御装置とを含むシステムにおいて、前記ＲＰＲステーションの各々は、バイディレクショナルの通信方式の場合のフラッディングされたＲＰＲフレームを廃棄させるポイントとして前記レジリエント・パケット・リング上に位置づけられるクリーブポイントを前記制御装置により設定させる第１手段と、前記レジリエント・パケット・リングのリングレットの双方にＲＰＲフレームをフラッディングさせて前記ＲＰＲステーションの各々においてＭＡＣアドレスの学習をさせる第２手段と、受信したＲＰＲフレームを前記レジリエント・パケット・リングのリングレットの双方のいずれに送信するかを、前記第２のステップで前記フレームが廃棄されなかったルートを通るように決定する第３手段と、を備えたことを特徴としたＲＰＲの送信経路指定装置。
（付記７）複数のＲＰＲステーションを接続するレジリエント・パケット・リング（ＲＰＲ）と該レジリエント・パケット・リングに接続され、前記複数のＲＰＲステーション及び前記レジリエント・パケット・リングを制御する制御装置とを含むシステムにおいて、前記ＲＰＲステーションの各々は、バイディレクショナルの通信方式の場合のフラッディングを廃棄させるポイントとして前記レジリエント・パケット・リング上に位置づけられるクリーブポイントを前記サーバにより各ＲＰＲステーションまでの遅延時間に基づき自動で設定させる第１手段と、前記レジリエント・パケット・リングのリングレットの双方にＲＰＲフレームをフラッディングさせて前記ＲＰＲステーションの各々においてＭＡＣアドレスの学習をさせる第２手段と、受信したＲＰＲフレームを前記レジリエント・パケット・リングのリングレットの双方のいずれに送信するかを、前記第２のステップで前記フレームが廃棄されなかったルートを通るように決定する第３手段と、を備えたことを特徴としたＲＰＲの送信経路指定装置。
（付記８）付記７において、前記第１手段は、前記ＲＰＲステーションの各々を通過するコントロールフレームを使用し、前記ＲＰＲステーションの各々が前記レジリエント・パケット・リングを構成する他のＲＰＲステーションまでの遅延時間を計算する第４手段と、計算した遅延時間をもとに各ＲＰＲステーションからもっとも遅延の長い区間が前記クリーブポイントとなるようにＲＰＲステーション数の残数ＴＴＬを自動で設定する第５手段と、を含むことを特徴としたＲＰＲの送信経路指定装置。
（付記９）複数のステーションを接続するレジリエント・パケット・リング（ＲＰＲ）と該レジリエント・パケット・リングに接続された制御装置とを含むシステムにおいて、クライアント側のポートおよびＶｌａｎを指定する第１手段と、該ポートおよびＶｌａｎに対してはクリーブポイントとブリッジ機能の経路指定とは無関係に、手動で指定した固定経路を介してパケットを送信させる第２手段とを備えたことを特徴としたＲＰＲの送信経路指定装置。
（付記１０）付記９において、前記レジリエント・パケット・リング内で中継する各ＲＰＲステーションはあて先ＲＰＲ  Ｍａｃ宛のパケットの中継のみを実施する第３手段と、前記レジリエント・パケット・リング内で前記固定経路のあて先となるＲＰＲステーションは前記レジリエント・パケット・リングからのフレームのドロップのみを実施する第４手段と、を含むことを特徴としたＲＰＲの送信経路指定装置。
【産業上の利用可能性】
【００９５】
以上説明したように、本発明では、通信事業者を中心にサービスが展開されているレイヤ２／３ネットワークにて使用されるイーサネット（登録商標）インタフェースを具備する装置（レイヤ２／３スイッチ，伝送装置等）がサポートする、ＲＰＲ（Ｒｅｓｉｌｉｅｎｔ  Ｐａｃｋｅｔ  Ｒｉｎｇ：ＩＥＥＥ８０２．１７に規定）の送信経路を指定することにより、キャリアの運用管理にそったシステムを提供し、機能面、運用管理面において信頼性と経済性にすぐれたイーサネット（登録商標）サービスの実現が可能となる。
【図面の簡単な説明】
【００９６】
【図１】ＲＰＲのリング構造の概略を示す図である。
【図２】各ＲＰＲステーションが送受信する基本的なデータフレームのフォーマット示す図である。
【図３】レイヤ２のイーサネット（登録商標）フレームを中継するような場合に使用される拡張データフレームフォーマットを示す図である。
【図４】コントロールフレームのフォーマットを示す図である。
【図５】収集した各ステーションの情報から構築されたトポロジデータベースを示す図である。
【図６】IEEE 802.17bにおいて標準化されているスペーシャル・リユースの概要を説明するためのＲＰＲネットワークの構成を示す図である。
【図７】図６におけるスペーシャル・リユースの概要を説明するための図である。
【図８】第１の課題を説明するためのＲＰＲシステムの構成図である。
【図９】第２の課題を説明するためのＲＰＲシステムの構成図である。
【図１０Ａ】本発明の実施例１によりクリーブポイントを設定する送信経路指定方法及び装置を説明するためのシステム構成図である。
【図１０Ｂ】各ＲＰＲステーションが具備するリング側ブリッジ機能（入力されたフレームをＭａｃアドレスの学習結果に基づいて左右のいずれのリングに流すかを決定する機能）を説明する表図である。
【図１１】図１０Ａにおける各ＲＰＲステーションの構成例を示すブロック図である。
【図１２】図１０Ａに示したシステムにおいて、東京のＲＰＲステーション１０１から名古屋のＲＰＲステーション１０５に向けてイーサネット（登録商標）フレームが送信された場合の状態を説明する図である。
【図１３】１０Ａに示したシステムにおいて、図１２に示した状態の後に名古屋のＲＰＲステーション１０５から東京のＲＰＲステーション１０１向けてイーサネット（登録商標）フレームが送信された場合の状態を説明する図である。
【図１４】図１３に示した状態の後に、東京のＲＰＲステーション１０１配下のクライアントにフレームが到達する状態を説明する図である。
【図１５Ａ】本発明の実施例２によりクリーブポイントを自動設定する送信経路指定方法及び装置を説明するためのシステム構成図である。
【図１５Ｂ】図１５Ａにおける各ＲＰＲステーションが具備するリング側ブリッジ機能を説明する表図である。
【図１６Ａ】図１５ＡにおけるＬＲＴＴ（ループ・ラウンド・トリップ・タイム）リクエスト・フレームのペイロードのフォーマットを示す図である。
【図１６Ｂ】図１５ＡにおけるＬＲＴＴ（ループ・ラウンド・トリップ・タイム）レスポンス・フレームのペイロードのフォーマットを示す図である。
【図１７】本発明の実施例３によるＰＲＰ経路のスタティックな設定をする送信経路指定方法及び装置を説明するためのシステム構成図である。
【図１８】本発明の実施例３によるＰＲＰ経路のスタティックな設定をする送信経路指定方法及び装置を説明するためのシステム構成図である。
【図１９Ａ】本発明の全ての実施例による送信経路指定方法を説明するフローチャートの一部である。
【図１９Ｂ】本発明の全ての実施例による送信経路指定方法を説明するフローチャートの他の一部である。
【図１９Ｃ】本発明の実施例２による送信経路指定方法を説明するフローチャートの一部である。
【図１９Ｄ】本発明の実施例３による送信経路指定方法を説明するフローチャートの一部である。
【符号の説明】
【００９７】
１００    送信側クライアント端末
１０１〜１０７    ＲＰＲステーション
１０８    宛先クライアント端末
１０９    設定されたクリーブポイント
１１０    各ＲＰＲステーションを制御するオペレーションセンタ(制御装置）
１１１    レジリエント・パケット・リング
１５    自動設定されたクリーブポイント
【図１】
2008167008.tif 000003
【図２】
2008167008.tif 000004
【図３】
2008167008.tif 000005
【図４】
2008167008.tif 000006
【図５】
2008167008.tif 000007
【図６】
2008167008.tif 000008
【図７】
2008167008.tif 000009
【図８】
2008167008.tif 000010
【図９】
2008167008.tif 000011
【図１０Ａ】
2008167008.tif 000012
【図１０Ｂ】
2008167008.tif 000013
【図１１】
2008167008.tif 000014
【図１２】
2008167008.tif 000015
【図１３】
2008167008.tif 000016
【図１４】
2008167008.tif 000017
【図１５Ａ】
2008167008.tif 000018
【図１５Ｂ】
2008167008.tif 000019
【図１６Ａ】
2008167008.tif 000020
【図１６Ｂ】
2008167008.tif 000021
【図１７】
2008167008.tif 000022
【図１８】
2008167008.tif 000023
【図１９Ａ】
2008167008.tif 000024
【図１９Ｂ】
2008167008.tif 000025
【図１９Ｃ】
2008167008.tif 000026
【図１９Ｄ】
2008167008.tif 000027