(57)【特許請求の範囲】
【請求項１】
ネットワークに接続された複数のデータ転送装置を備え、一方のエッジノードから他方のエッジノードへデータ転送装置を介してデータを転送するネットワークシステムにおいて、該複数のデータ転送装置の少なくとも２つに相当するエッジノードが、宛先アドレスがマルチキャストアドレスである保守管理データの伝送経路を構成しているネットワークシステムであって、
上記保守管理データの伝送経路の端点に位置するデータ転送装置に相当するエッジノードは、
上記伝送経路の識別子を含む上記保守管理データを送信する送信部を備え、
上記保守管理データの伝送経路の端点以外に位置するデータ転送装置は、
上記伝送経路の端点に位置するデータ転送装置が送信した上記保守管理データを受信する受信部と、
上記受信部において上記保守管理データを受信すると、該受信した保守管理データに含まれる伝送経路の上記識別子と、該保守管理データを受信したポートの識別子と、上記保守管理データの宛先マルチキャストアドレスと、を上記保守管理データから抽出して対応付けて記憶する記憶部とを有し、
上記受信部は、上記両方のエッジノードから同じマルチキャストアドレス及び伝送経路の識別子を含む保守管理データを受信し、
上記宛先マルチキャストアドレスは、メンテナンスエンティティレベルを示し、上記伝送経路の識別子は、上記エッジノード間で上記保守管理データを転送するための伝送経路を識別するための識別子であり、
上記記憶部は、上記保守管理データのメンテナンスエンティティレベルが、受信したポートに設定されたメンテナンスエンティティレベルと一致する場合に、この対応関係を記憶し、
宛先をマルチキャストアドレスとする保守管理データを受信した場合、経路情報に基づき、該保守管理データに含まれる伝送経路の識別子と同一の伝送経路の識別子及びマルチキャストアドレスと対応付けられた、該保守管理データを受信したポートとは異なる出力ポートに該保守管理データを送信することを特徴とするネットワークシステム。
【請求項２】
請求項１記載のネットワークシステムであって、
上記保守管理データの伝送経路は保守管理レベルに合わせた論理的階層構造を有しており、
上記伝送経路の端点以外に位置するデータ転送装置の記憶部には、上記伝送経路の識別子と上記ポートの識別子に加えて、上記階層構造のうち上記受信した保守管理データが属する階層の識別子が対応付けられて経路情報として記憶されていることを特徴とするネットワークシステム。
【請求項３】
請求項１記載のネットワークシステムであって、
上記伝送経路の端点に位置するデータ転送装置は、
受信した保守管理データの伝送経路の識別子と、該保守管理データを受信したポートの識別子を対応付けて記憶する記憶部を有することを特徴とするネットワークシステム。
【請求項４】
請求項１記載のネットワークシステムであって、
上記伝送経路の識別子は、ＭＥＧＩＤであることを特徴とするネットワークシステム。
【請求項５】
請求項１記載のネットワークシステムであって、
上記保守管理データはＶＬＡＮを介して転送され、
上記伝送経路の識別子は、該ＶＬＡＮの識別子であることを特徴とするネットワークシステム。
【請求項６】
請求項５記載のネットワークシステムであって、
上記保守管理データは、保守管理データ専用のＶＬＡＮを介して転送されることを特徴とするネットワークシステム。
【請求項７】
請求項１記載のネットワークシステムであって、
上記保守管理データはＭＰＬＳ網を介して転送され、
上記伝送経路の識別子は、ＭＰＬＳ網内の伝送経路を識別するラベルであることを特徴とするネットワークシステム。
【請求項８】
請求項１記載のネットワークシステムであって、
上記伝送経路の端点以外のデータ転送装置の記憶部に記憶されている経路情報には該経路情報の有効期限を表す情報が含まれており、
該有効期限が過ぎた場合、該経路情報を削除することを特徴とするネットワークシステム。
【請求項９】
ネットワークに接続された複数のデータ転送装置を備え、一方のエッジノードから他方のエッジノードへデータ転送装置を介してデータを転送するネットワークシステムにおいて、該複数のデータ転送装置の少なくとも２つに相当するエッジノードが、宛先アドレスがマルチキャストアドレスである保守管理データの伝送経路を構成しているネットワークシステムに接続され、かつ上記伝送経路上にあり、さらに上記伝送経路の端点以外に位置するデータ転送装置であって、
上記伝送経路の端点に位置するデータ転送装置に相当するエッジノードが送信した保守管理データを受信する受信部と、
上記受信部において上記保守管理データを受信すると、該受信した保守管理データに含まれる伝送経路の上記識別子と、該保守管理データを受信したポートの識別子と、上記保守管理データの宛先マルチキャストアドレスと、を上記保守管理データから抽出して対応付けて記憶する記憶部とを有し、
上記受信部は、上記両方のエッジノードから同じマルチキャストアドレス及び伝送経路の識別子を含む保守管理データを受信し、
上記宛先マルチキャストアドレスは、メンテナンスエンティティレベルを示し、上記伝送経路の識別子は、上記エッジノード間で上記保守管理データを転送するための伝送経路を識別するための識別子であり、
上記記憶部は、上記保守管理データのメンテナンスエンティティレベルが、受信したポートに設定されたメンテナンスエンティティレベルと一致した場合に、この対応関係を記憶し、
宛先をマルチキャストアドレスとする保守管理データを受信した場合、経路情報に基づき、該保守管理データに含まれれる伝送経路の識別子と同一の伝送経路の識別子及びマルチキャストアドレスと対応付けられた、該保守管理データを受信したポートとは異なる出力ポートに該保守管理データを送信することを特徴とするデータ転送装置。
【請求項１０】
請求項９記載のデータ転送装置であって、
上記保守管理データの伝送経路は保守管理レベルに合わせた階層構造を有しており、
上記記憶部には、上記伝送経路の識別子と上記ポートの識別子に加えて、上記階層構造のうち上記受信した保守管理データが属する階層の識別子が対応付けられて経路情報として記憶されていることを特徴とするデータ転送装置。
【請求項１１】
請求項９記載のデータ転送装置であって、
上記伝送経路の識別子は、ＭＥＧＩＤであることを特徴とするデータ転送装置。
【請求項１２】
請求項９記載のデータ転送装置であって、
上記保守管理データはＶＬＡＮを介して転送され、
上記伝送経路の識別子は、該ＶＬＡＮの識別子であることを特徴とするデータ転送装置。
【請求項１３】
請求項１２記載のデータ転送装置であって、
上記保守管理データは、保守管理データ専用のＶＬＡＮを介して転送されることを特徴とするデータ転送装置。
【請求項１４】
請求項９記載のデータ転送装置であって、
上記保守管理データはＭＰＬＳ網を介して転送され、
上記伝送経路の識別子は、ＭＰＬＳ網内の伝送経路を識別するラベルであることを特徴とするデータ転送装置。
【請求項１５】
請求項９記載のデータ転送装置であって、
上記記憶部に記憶されている経路情報には該経路情報の有効期限を表す情報が含まれており、
該有効期限が過ぎた場合、該経路情報を削除することを特徴とするデータ転送装置。
【発明の詳細な説明】
【参照による取り込み】
【０００１】
本出願は、２００６年１月４日に出願された日本特許出願第２００６−００００３３号の優先権及び２００６年１１月２２日に出願された日本特許出願第２００６−３１４９８４号の優先権を主張し、その内容を参照することにより本出願に取り込む。
【技術分野】
【０００２】
本発明は、パケット若しくはフレーム通信網における保守管理情報の通信路制御方法に関する。特にＯＳＩ参照モデルにおけるデータリンク層の保守管理に利用されるＯＡＭフレームの制御に関し、それをサポートするためノード内にデータベースを備えるフレーム処理方式、また既存装置を利用した場合にも適用可能な、ＯＡＭフレーム向け転送経路設定方式に関する。
【背景技術】
【０００３】
パケット技術をベースとした網の需要が高まる中、次世代ネットワーク（Ｎｅｘｔ  Ｇｅｎｅｒａｔｉｏｎ  Ｎｅｔｗｏｒｋ：ＮＧＮ）構想に基づいたネットワークサービスのＩＰ化が、今後より推進されると予想される。この構想での足回りとして、イーサやＭＰＬＳ（ＭｕｌｔｉＰｒｏｔｏｃｏｌ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｉｎｇ）のようなＩＰ化されたアプリケーションに親和性の高い低位レイヤが要求される。また一方でＮＧＮが次世代インフラとなるためには、インフラとしての信頼感、安心感が必要であり、アクセス系、中継系共に、既存のレガシー網に匹敵する品質と信頼性を具備したネットワークの構築が重要となる。【０００４】
この様な背景の中、各標準化団体では既にイーサ網のＯＡＭが検討されている。イーサネットに関するＯＡＭ（Ｏｐｅｒａｔｉｏｎ，Ａｄｍｉｎｉｓｔｒａｔｉｏｎ  ａｎｄ  Ｍａｉｎｔｅｎａｎｃｅ）については、ＩＴＵではメカニズム勧告Ｙ．１７ｅｔｈｏａｍ（非特許文献１）、およびリニア切り替え勧告Ｇ．８０３１（非特許文献２）の検討を行っている。また、ＩＥＥＥではイーサＯＡＭのメカニズムをｐ８０２．１ａｇ（非特許文献３）で検討を行っている。これらの団体は連携を取り、概念およびフォーマットの統一を試みている。【０００５】
網の管理するための概念として網の保守を行う場合、保守者はメンテナンス区間（メンテナンスエンティティー）の設定を行う必要がある。このメンテナンス区間は、ＯＡＭ機能や管理者の管理意図によって、トポロジーが異なる。例えば、リニア切り替えを行う場合は、ポイントツーポイントとなり、あるドメインの範囲の接続性を確認する場合には２次元的な構成となる。ＯＡＭフローは、このメンテナンス区間の端点間で流される必要がある。しかし、本来のイーサ技術はコネクションレス技術であるため、網内の各ノードにおいて経路を特定させる技術が必要となる。【０００６】
イーサのメンテナンス区間（Ｍａｉｎｔｅｎａｎｃｅ  Ｅｎｔｉｔｙ：ＭＥ）は、ＯＡＭパケットフローが挿入され、終端される範囲である。ＭＥはエンティティーがポイントツーポイントの形態の場合の呼称であるが、面で管理する場合には管理エンティティーグループ（ＭＥ  Ｇｒｏｕｐ：ＭＥＧ）と呼ばれる。ＭＥＧは複数のポイントツーポイント、またはマルチポイントの集合体である場合がある。各ＭＥＧはＭＥＧＩＤ識別子で管理される。ＭＥＧは、サービス等で区別された管理ドメイン（ＶＬＡＮ（Ｖｉｒｔｕａｌ  Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等）内に存在する。【０００７】
イーサＯＡＭではＭＥをネスト化（それぞれのメンテナンス区間につき、複数レベル（現在は８レベルで定義されている）のメンテナンスエンティティを設定できる。下位レベルのメンテナンスエンティティ区間は、上位レベルのメンテナンスエンティティ区間に含まれる構造となる。）して定義し、各ＭＥをＭＥレベル識別子で管理する。現状、８レベルまで取得可能で、ＯＡＭフローはＭＥレベル毎に定義される。各ＭＥレベルによって識別されたＭＥは互いに独立で、以下の様なフィルター機能を持つ。
ａ）ＯＡＭフロー挿入点では、外部より侵入するＯＡＭパケットが上位レベルであれば通過させ、同レベル以下であれば廃棄する。
ｂ）ＯＡＭフロー分離点では、ＭＥ内部からのＯＡＭパケットが上位レベルであれば通過させ、同レベル以下であれば適切に終端する。【０００８】
ＯＡＭフローを終端する端点として、ＭＥエンド点（ＭＥ  Ｅｎｄ  Ｐｏｉｎｔ：ＭＥＰ）およびＭＥ中間点（ＭＥ  Ｉｎｔｅｒｍｅｄｉａｔｅ  Ｐｏｉｎｔ：ＭＩＰ）が定義されている。ＭＥＰは、ＭＥレベル毎の全てのＯＡＭフローを終端する。一方ＭＩＰは、ＭＥレベル毎に特定区間で使用されるＯＡＭフローを終端する。ＯＡＭ機能として、接続確認のためのＣＣ（Ｃｏｎｔｉｎｕｉｔｙ  Ｃｈｅｃｋ）、切り替え（ＡＰＳ）、ＡＩＳ（Ａｌａｒｍ  Ｉｎｄｉｃａｔｉｏｎ  Ｓｉｇｎａｌ）、ループバック（ＬＢ）、リンクトレース（ＬＴ）等が検討されている。【０００９】
ＯＡＭ機能は、大別してＭＥＰ間でのみ送受信される機能とＭＩＰで終端されうる機能に分類される。前者は主にサービス開始時に設定されることを想定して、プロアクティブＯＡＭと呼ばれる。後者は障害切り分け等の診断に使用されるので、診断ＯＡＭまたはオンデマンドＯＡＭ等と呼ばれる。例えば、ＣＣ、ＡＰＳ、ＡＩＳ等はプロアクティブＯＡＭに属し、ＬＢ、ＬＴは診断ＯＡＭに分類される。特に、周期的に駆動されるＣＣフレーム内には性能情報、ＲＤＩ（Ｒｅｍｏｔｅ  Ｄｅｆｅｃｔ  Ｉｎｄｉｃａｔｉｏｎ）情報等の他ＯＡＭ機能も含み、また初期接続時の構成情報を取得しデータベース（ＣＣ  Ｄａｔａｂａｓｅ：ＣＣＤＢ）を構築する用途でも使用される。【００１０】
ＯＡＭフレームのＤＡ（Ｄｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ）としては、ユニキャストまたはマルチキャストが考えられるが、網を管理するオペレータの立場からすると、機材交換の度に変更となるユニキャストＤＡを使用することは望ましくない。そのため、特殊な用途以外ではマルチキャストが推奨されている。例えばユニキャストは、ＬＢの要求、ＬＢの返信、ＬＴの返信である。また、マルチキャストＤＡを利用してＭＥレベルを識別する方法が考案されている。ＭＥレベル識別子領域はＯＡＭフレーム内に存在するが、ＭＰＵ等の内部処理を軽減するために、ＤＡを識別のための補助手段として利用する目的である。更に、ＭＩＰはプロアクティブＯＡＭを処理せず通過させる（ｓｉｍｐｌｅ動作）必要があるが、これを容易にするために、プロアクティブ用、診断用の２種類のＤＡを定義する。すなわち、８レベル×２＝１６種類のマルチキャストＤＡを、ＯＡＭ用に定義する。
【非特許文献１】”Ｄｒａｆｔ  Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ  Ｙ．１７３１−ＯＡＭ  Ｆｕｎｃｔｉｏｎｓ  ａｎｄ  Ｍｅｃｈａｎｉｓｍｓ  ｆｏｒ  Ｅｔｈｅｒｎｅｔ  ｂａｓｅｄ  Ｎｅｔｗｏｒｋｓ，”ＩＴＵ−Ｔ  ＳＧ１３，Ｎｏｖ．２００５．
【非特許文献２】”Ｄｒａｆｔ  Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ  Ｇ．８０３１−Ｅｔｈｅｒｎｅｔ  Ｐｒｏｔｅｃｔｉｏｎ  Ｓｗｉｔｃｈｉｎｇ，”ＩＴＵ−Ｔ  ＳＧ１５，Ｎｏｖ．２００５．
【非特許文献３】”Ｖｉｒｔｕａｌ  Ｂｒｉｄｇｅｄ  Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋｓ−Ａｍｅｎｄｍｅｎｔ  ５：Ｃｏｎｎｅｃｔｉｖｉｔｙ  Ｆａｕｌｔ  Ｍａｎａｇｅｍｅｎｔ，”ＩＥＥＥ  Ｐ８０２．１ａｇ／Ｄ５．２，Ｄｅｃ．２００５．
【発明の開示】
【発明が解決しようとする課題】
【００１１】
マルチキャストＤＡをＯＡＭフレームに用いる場合、ＯＳＩレイヤ２ではブロードキャストフレームとして扱われる。ブロードキャストドメイン内の全方路にフレームが送出されるため、管理ドメインの中で、メンテナンス対象経路を限定したい場合に対応できない。ブロードキャストによって乗じる問題点は、ＯＡＭ情報を含むフレームが他のノードに転送されることによる、ネットワーク帯域及びノード処理の負荷増大である。これによって管理者は正確なネットワークの稼動状態を取得することが難しくなる。さらにはＯＡＭ情報が他ノードに伝わることによる網の信頼性低下という問題も生じ得る。そこで、これらＯＡＭフレームをユーザデータと区別して経路制御を行うことが必要となる。
これまでのスイッチではＯＡＭフレームを適切な方路のみに転送するための、ＯＡＭフレームとユーザデータとを区別する経路制御ができない点が課題となる。
【課題を解決するための手段】
【００１２】
ＯＡＭフレームをユーザデータと独立して制御可能とするため、ＭＥの中継ノードにおいてＯＡＭフレーム制御用の経路制御テーブルを備えることを特徴とする。テーブルの生成にはＯＡＭフレーム用のｓｎｏｏｐｉｎｇ機能を用いる。Ｓｎｏｏｐｉｎｇ機能とは、ＩＧＭＰあるいはＭＬＤメッセージを監視して，受信者が接続しているポートに対してマルチキャストトラフィックを中継する機能である。この機能により，不要なマルチキャストトラフィックの中継を抑止し，ネットワークを効率的に利用できる。また、フレーム制御に使用するフィールドを含まないＯＡＭフレームに関して、ＭＥの端点となるエッジノードにおいて、ＭＡＣアドレスその他の基本フレーム情報とＯＡＭ制御用フィールド（ＭＥＧＩＤフィールド）を対応付け、フレームに付与して送出することを特徴とする。さらに、中継ノードがＯＡＭ機能をサポートしない場合に、ＯＡＭフレーム転送区間とユーザデータ転送区間をＶＬＡＮタグ、ＭＰＬＳラベルなどのパス識別子を用いて識別すること、及び中継ノードでｓｎｏｏｐｉｎｇ機能を利用して経路制御を行うため、ＯＡＭフレーム制御に必要なフィールド（ＭＥＧＩＤフィールド）をそれらのパス識別子と対応付けて、ＯＡＭフレームを生成することを特徴とする。
【発明の効果】
【００１３】
ＯＡＭの適用にあたりマルチキャストＤＡを使用する場合にも、中継ノードにおけるフレームのフラッディングを抑止でき、管理ドメイン内の帯域及びＣＰＵリソースの利用効率を向上できる。
本発明の他の目的、特徴及び利点は添付図面に関する以下の本発明の実施例の記載から明らかになるであろう。
【発明を実施するための最良の形態】
【００１４】
ＯＡＭフレームの宛先アドレスとしてマルチキャストアドレスを用いる場合に、ネットワーク管理ドメイン内におけるＯＡＭフレームの通過領域を識別するため、イーサＯＡＭ対応ノード内に経路制御データベースを備える方法と、ＩＧＭＰ／ＭＬＤ  ｓｎｏｏｐｉｎｇを用いる方法との二通りを提案する。前者は今後の新規ネットワーク構成時に、後者は既存網におけるＯＡＭ機能追加、ＯＡＭ機能対応ネットワーク構築への移行措置、また安価なＯＡＭ機能導入手段として有効である。【００１５】
図１は、ネットワークの管理ドメイン内でのＭＥ設定例を示す。ここでのＭＥは管理ドメインの境界に位置する装置を両端として設定されており、このＭＥが管理ドメイン内では唯一のＭＥとして設定される状況を示している。ノード間はデータリンク層プロトコルを用いて接続される。データリンク層の代表的プロトコルとしてイーサネットが挙げられる。以降ではイーサネットを想定した実施例の説明を行うが、他のプロトコルを用いてもよい。【００１６】
本実施例のネットワーク１０００は、エッジノードＥＮ１ａ、１ｂ、３ａ〜３ｄ、中継ノード２ａ、２ｂ、３ｅで構成する。端末もしくはサーバ１００ａと１００ｂとが通信を行う場合に、エッジノードＥＮ１ａから中継ノード２ａ、中継ノード２ｂ、及びエッジノード１ｂを通過する経路と、中継ノード３ｅを通過する経路とが利用可能である。ここでは前者の経路に対して、ＯＡＭ機能を適用する場合を示す。本実施例では、ＯＡＭ適用対象経路上のノードＥＮ１ａ、１ｂ、中継ノード２ａ、２ｂはイーサＯＡＭ機能をサポートするノードとする。その他エッジノード３ａ〜３ｄ、中継ノード３ｅについてのＯＡＭサポート有無は問わない。【００１７】
上記ＯＡＭ対象経路に対して、ＯＡＭを適用するためのＭＥ（メンテナンスエンティティ）を設定する。それには、エッジノード１ａ及び１ｂにおいて、上記ＭＥを収容する管理対象ポートにＭＥＰ（ＭＥＧ  Ｅｎｄ  Ｐｏｉｎｔ）ＩＤ、ＭＥレベル、ＭＥＧＩＤ（ＭＥ  Ｇｒｏｕｐ  ＩＤ）を含むＯＡＭパラメータを設定する。具体的には、管理対象となる論理／物理ポートの識別子と、それぞれに対して設定されるＭＥＰＩＤ、ＭＥレベル、ＭＥＧＩＤとを対応付けるデータベースを構築する。ＭＥＰとは、ＭＥの端点であることを示す識別子である。ＭＥレベルとは、当該経路について、イーサＯＡＭで定義される、ＯＡＭ設定レベル（８レベル）のうちのいずれのレベルでＯＡＭを行うかを示す。ＭＥは８レベルのいずれかに属するように設定される。また、ＭＥＧＩＤとは、ＭＥレベルが同一のＭＥを複数本束ねた集合体を識別するための識別子である。同一ＭＥＧＩＤに含まれる複数のＭＥは、その全てが同一の区間（両端が同一のＭＥＰ）である必要はない。また、ＭＥＧＩＤに含まれるＭＥの全てが同一区間に属する必要もない。基本的な構成では、装置の物理ポートは一つ又は複数の論理ポートを収容し、論理ポートは、それがＯＡＭにおけるＭＥの終端ポートである場合に、一つ又は複数のＭＥレベル、ＭＥＧＩＤ、ＭＥＰを収容する。ＭＥＰはＭＥの終端点を示し、自分自身の属するＭＥレベルを識別する。自分自身が属するレベル以下のＭＥレベルを持つＯＡＭフレームは、ＭＥＰにおいて廃棄される。従って、ＭＥＰＩＤの組合せで識別されるＭＥ、及びその集合体を示すＭＥＧＩＤは、固有のＭＥレベルをもち、ＭＥレベルとＭＥＧＩＤとの組合わせにより、管理ドメイン内のＭＥＧが特定できる。【００１８】
イーサＯＡＭでは、管理対象経路の状態を監視するため、ＣＣ（Ｃｏｎｔｉｎｕｉｔｙ  Ｃｈｅｃｋ）フレームを用いる。ＣＣフレームはＭＥＰ（ＭＥの端点）から対向ＭＥＰに対して定期的に送出され、経路の接続状態（到達可能か否か、受信側でのＣＣフレーム到着間隔は正しく保たれているか、など）の確認に使用される。ＣＣフレームには、ＭＥレベルを示すマルチキャストグループアドレス（ＤＡ；Ｄｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ）、ＣＣフレーム送信周期を定義するｐｅｒｉｏｄフィールド、ＭＥＧＩＤフィールド、ＭＥＰＩＤフィールドを含む。ＣＣフレームフォーマットは非特許文献１で定義されている。【００１９】
ＭＥが設定された経路を構成するエッジノードＥＮ１ａ、１ｂは、ＣＣフレームに含まれるＭＥレベル、ＭＥＧＩＤとＭＥＰＩＤとの対応関係を記録し、ＣＣＤＢ（ＣＣ  Ｄａｔａｂａｓｅ；受信したＯＡＭフレームに含まれるヘッダ情報などの識別子を記録しておくためのテーブル）１０ａ、１０ｂを構成する。ＣＣＤＢは、ＭＥＰが設定されたポートにおいて生成される。ＣＣＤＢ生成時に記録されるパラメータは、送信元ＭＡＣアドレス、ＭＥＧＩＤ、ＭＥＰＩＤ，ＶＬＡＮタグなどのパス識別情報である。ＣＣＤＢはＯＡＭのためのトポロジーデータベースである。ここでＭＥＰはポート毎に設定されるため、ＣＣＤＢでは、受信ＣＣフレームに含まれるＭＥＰＩＤと受信ポートとの対応関係を学習している。これにより、あるＭＥＰＩＤに向かうＣＣフレームの送出先ポートをいずれにするべきかを選択でき、ＣＣフレームの経路制御に用いることができる。ＣＣＤＢの構成に関しては非特許文献１及び非特許文献２に記載されている。【００２０】
中継ノードＭＮ２ａ、２ｂでは、ＯＡＭフレームをＯＡＭフレーム別のフィールド定義に従って処理する。ここではＯＡＭフレームのうち、ＯＡＭ通過領域を示すＭＥＧＩＤフィールドを含むＯＡＭフレームからの経路学習を考える。なお現時点ではＣＣフレームのみがこれに該当するが、ＣＣフレームは経路の状態を管理するため、定期的に送出されるフレームであり、他のＯＡＭ機能を使用する際にも、ＣＣフレームが予め存在していることが想定される。そのためＣＣフレームの送出頻度が他のＯＡＭフレームに比較してもきわめて高く、このままＣＣフレームのみが経路制御対象となる場合であっても十分に帯域節約効果が期待できる。他のＯＡＭフレームを制御する方法は後述する。【００２１】
中継ノードでは、ＣＣＤＢを持たない（非特許文献１）ため、ＣＣＤＢを参照することによるＣＣフレームの経路制御ができない。そこでＣＣフレームの制御のため、各ノードにおいてＣＣフレームを受信したポートとＭＥレベル、及びＭＥＧＩＤの対応関係を含むテーブル（以降、転送制御テーブルと称する）２０ａ、２０ｂを構築する。本処理はＭＥＰにおけるＣＣＤＢ学習と独立したＣＣフレームの学習機能により行う。【００２２】
ＯＡＭ対象経路上では、ＭＥ両端のエッジノードＥＮ１ａ、１ｂよりそれぞれＣＣフレームが送信される。一方のエッジノードから受信したＣＣフレームの送信方路（ＭＥＧＩＤ毎）は、他方のエッジノードから受信したＣＣフレームの受信ポートから特定できる。こうして双方向からのＣＣフレーム学習を繰り返すことにより、ＭＥに沿ったＯＡＭフレーム制御のための転送制御テーブル２０ａ、２０ｂを構築する。【００２３】
以上の方法により、ＣＣＤＢを備えない（非特許文献１に規定）中継ノードにおいてもＭＥＧＩＤ毎に転送経路を識別できるため、ＯＡＭフレームが、監視対象経路以外にブロードキャストされることを防ぐことができる。そのためネットワークの利用を効率化し、ＯＡＭ対象ポートを含まないノードの処理負荷を低減できる。【００２４】
図２は、図１のネットワーク構成においてＯＡＭ転送制御テーブルを生成する手順を示すシーケンスである。図１のネットワークにおいて、ＯＡＭフレーム転送範囲を管理対象経路にのみ限定するために、経路両端の装置から送信されるＣＣフレームを参照し、そこに含まれるＭＥＧＩＤ、ＭＥレベルと受信ポートとの対応関係を学習する。ここでは、そのうち片方向に着目してシーケンスを説明する。逆方向についての転送経路テーブル生成処理も、全く同様の手順で実現できる。なお、以下でＭＥＧＩＤと表記しているが、ＭＥＩＤと読み替えても構わない。本実施例ではＭＥは管理ドメイン内で単一のため、ＭＥＧＩＤによってＭＥそのものを特定可能だからである。【００２５】
また、ＭＥレベル情報はＯＡＭフレームに専用フィールドが定義されている（非特許文献１）が、ここではＯＡＭフレームにマルチキャストＤＡ（２００ａ、２００ｂ）を用い、各ＤＡがＭＥレベル毎に定義されることを前提とする。そこで、以下の記述において、ＭＥレベル情報はＯＡＭフレームのＤＡと置き換えてもよい。ＯＡＭフレームでは、マルチキャストグループアドレスを、ＯＡＭフレームとユーザフレームとの識別、及びＭＥレベルの識別という用途で使用する。【００２６】
処理２０１において、エッジノード１ａと１ｂに対し、ＭＥが設定される。ここで、各ノードへの設定情報は次のようになる。エッジノード１ａ，及び１ｂでは、ＯＡＭの対象ポート毎に、ＭＥの両端点であるＭＥＰのＩＤ、ＭＥが属するＭＥＧのＩＤ、ＭＥＧのレベルを示すＭＥレベル情報を含むＯＡＭパラメータを設定する。設定情報は、ＯＡＭ設定情報データベース（後出）に記録する。中継ノード２ａ、２ｂにおいては、ポート毎に、それらの属するＭＥレベル情報を含むＯＡＭパラメータが設定される。【００２７】
ＯＡＭ情報が設定された後、エッジノードでは処理２０２においてＣＣフレームを生成し、対向ＭＥＰが設定されたポートに向けて送出する。ＣＣフレーム２０３を受信した隣接ノード２ｂでは、処理２０４において、当該受信ポートの識別子と、受信したＣＣフレームに含まれるＭＥＧＩＤ、及びＭＥレベルを学習し、ＯＡＭフレーム転送制御テーブル（後出）に記述する。続いて、ＣＣフレーム２０５を受信した中継ノード２ａは、処理２０６において、当該ＣＣフレームを受信したポートとＣＣフレーム内のＭＥＧＩＤ及びＭＥレベルを対応付けてＯＡＭフレーム転送制御テーブルに格納する。【００２８】
対向エッジノード１ａにおいても、受信ＣＣフレーム２０７を参照して、処理２０８にてＣＣＤＢを構築する。エッジノード１ａでは、処理２０９にて受信したＣＣフレームを終端し、フレーム内のＭＥＧＩＤ、ＭＥレベル、送信元ＭＥＰＩＤ、及びＣＣフレーム送信間隔がＯＡＭパラメータの設定どおり正しく処理されているかを確認する。もし上記の情報が誤っていることが分かれば、それぞれのエラーを示す警報を発する。ここで、エラー及び警報の処理方法について、本発明では限定しない。【００２９】
初めに述べたように、逆方向についても全く同様のＣＣフレーム学習処理を行う。すなわち、エッジノード１ａにおいてＣＣフレームを生成、送出し、中継ノード２ａ、２ｂにてＭＥＧＩＤ，ＭＥレベルと受信ポートを互いに関連付けて転送制御テーブルを構成する。対向ＭＥＰが設定されたエッジノード１ｂにおいては、ＣＣＤＢの設定、ＣＣフレームの示すＯＡＭパラメータの確認を行い、処理を終了する。【００３０】
図３は図２のシーケンスで設定したＯＡＭフレーム転送制御テーブルから、不要なエントリを削除する場合のシーケンスを示す。ポイントツーポイントで設定されるＭＥは、ＭＥに沿ったパスを構成するエッジノードもしくは中継ノードにおいて、ＭＥ設定が消去された場合などにその存在意義がなくなり、削除される。ＭＥの消去にあたっては、各ノードにおいてオペレータによって設定を削除するなどの方法がとられる。これに伴い、ＯＡＭフレーム転送制御テーブルのエントリも消去する。その方法として、各ノードで個別にテーブルエントリを消去してもよいが、自動学習によって構成される転送制御テーブルは、エントリ毎のエージング処理によって各エントリの有効期間を管理できる。ここではＭＥ消滅後にＣＣフレームが存在しないことを利用し、エージングタイマ機能を利用して有効期間が過ぎたエントリを消去する方法を示す。【００３１】
エッジノード１ｂにおいて、最初にＭＥ設定が解除される場合を考える。ＭＥに沿って構築されていたＯＡＭフレーム転送経路２１０は、ＭＥ解除３０１により不要となる。そこで、エッジノード１ｂでは、ＯＡＭフレーム転送制御テーブルの中から該当するエントリを、処理３０２で消去する。処理３０１により、エッジノード１ｄから対向エッジノード１ａに向かうＣＣフレームは最早送信されないため、中継ノード２ａ、２ｂでは当該ＣＣフレームを受信することなく、ＣＣフレーム学習によって構築されたテーブルエントリはエージングタイマの期限切れに伴い、学習タイミング順にそれぞれ処理３０３〜３０４のようにエントリが消滅する。【００３２】
なお、対向エッジノード１ａでは、エージングタイマ期限を待たずに、ポートに設定されたＭＥＰＩＤ、ＭＥＧＩＤを含むＯＡＭパラメータの設定解除に伴い、各ノードにおいてそれぞれ関連するＣＣＤＢ、転送制御テーブルのエントリを消去してもよい。【００３３】
図３では、片方向のみを説明しているが、逆方向も同様である。ＭＥＰ情報（ＣＣＤＢエントリ）は、現勧告に基づけば送信側ＭＥＰと受信側ＭＥＰが区別される。そのため、一方向分のエントリ削除が他の方向のＯＡＭ制御に影響することはない。そこで、本実施例で経路上のＭＥを全て消去するためには、処理３０１から処理３０６を逆方向に対しても同様に行えばよい。【００３４】
エージング処理を行うことにより、万が一、ＭＥの管理が解除されたときにも、不要な経路制御情報が保持され続ける状況に陥ることを回避できる。【００３５】
図４は、マルチキャストＤＡを含むＯＡＭフレームフォーマットを示す。ＯＡＭフレームはＯＡＭ共通ヘッダと各ＯＡＭ機能個別の情報フィールドから構成される。【００３６】
本発明が対象とする、マルチキャストＤＡによってＭＥレベルを判断するＯＡＭにおいては、宛先アドレスからは送信先を特定できない。また、ＯＡＭフレームのマルチキャストグループに関してはノード（ポート）の組を示すものではない。こうした事情により、ＯＡＭフレームの送出先ポートをＭＡＣアドレスではなくＭＥＰＩＤで識別し、ＯＡＭフレーム内にはそれらが構成するＭＥを束ねるＭＥＧのＩＤを記述することが望ましい。【００３７】
図中のＤＡ４０１には、ＯＡＭフレームのＭＥレベルを示すマルチキャストアドレスを記載し、ＯＡＭ機能別の情報フィールドにはＭＥＧＩＤ４０６を記述する。ここで、現在の勧告でＭＡＣアドレスにより識別されるポートは、本フレーム送信元となるノードにおいて、ＭＡＣアドレスとＭＥＧＩＤとを対応づけるテーブルを参照し、情報の置き換えを行う。【００３８】
その他フィールドは勧告（非特許文献１）に記載のフォーマットに従う。ＳＡフィールド４０２にはフレーム送信元のアドレス、ＥｔｈｅｒＴｙｐｅフィールド４０３には当該フレームがＯＡＭフレームであることを示すコード番号、またＯＡＭフレーム共通ヘッダ内には、ＭＥレベル４０４、及び当該フレームのＯＡＭ種別を示す識別子ＯｐＣｏｄｅ４０５を含む。【００３９】
図５はイーサＯＡＭをサポートするフレーム通信装置の構成を表す機能ブロック図である。ＯＡＭ情報５４０、ＣＣＤＢ５４１、ＯＡＭフレーム送出機能５４２、ＣＣＤＢ５５０を備える点が主要な特徴である。【００４０】
エッジノード１は、装置制御部５００と入出力制御部５１０−ｎ（ｎ＝１，２，．．）、スイッチ５２０から構成される。【００４１】
装置制御部には、プロセッサ５０１、メモリ５０２、入出力制御部５０３を備える。入出力制御部５０３は、スイッチ５２０から送られる情報をメモリ５０２に格納するか、プロセッサ５０１へ通知するかを判断する機能を持つ。また、プロセッサ５０１より通知を受けた場合に、メモリ内のＯＡＭフレーム挿入処理部よりフレームを読み出し、スイッチ５２０へ転送する。メモリ５０２にはルーティング若しくはスイッチング情報を格納する経路制御表５３０が保持される。経路制御表５３０は、スイッチ５２０より、受信フレームの送出先を振り分けるために参照される。メモリ５０２には、さらにＯＡＭ情報ＤＢ５４０、ＣＣＤＢ５４１を保持する。ＯＡＭ情報ＤＢには、ノードの各ポートに設定されたＭＥＰＩＤ、ＭＥレベル、ＭＥＧＩＤを含むＯＡＭ情報を格納する。ＣＣＤＢには、自ノードが他ノードより受信したＣＣフレームに基づいて構築した、ＭＥＰＩＤを用いた管理トポロジー情報を保持する。【００４２】
入出力処理部５１０は、物理ポート５１１、受信制御部５１２、送信制御部５１６、スイッチ５１３、プロセッサ５１４、メモリ５１５を含む。物理ポート５１１にて受信したフレームは、入力制御部５１２にて多重処理、及びヘッダ解析、ヘッダ変換処理、内部ヘッダ処理が行われてスイッチ５１３へ送られる。ここで、ヘッダ変換方法は装置制御部のメモリ５０２に格納されたものを受信制御部５１２が参照するか、入出力制御部５１０のメモリ５１５に個別に処理方法を記述しておいてもよい。スイッチ５１３は、受信制御部５１２から受信するフレーム情報を元に各フレームの転送先を決定する。ここでも、フレーム転送先の決定にあたり、装置制御部のメモリを参照してもよいし、入出力処理部のメモリ５１５を参照してもよい。ここではメモリ５１５を参照して適切な送出先が決定できない場合に、上位スイッチ５２０にフレームを転送し、スイッチ５２０で転送先経路を決定する構成を示す。スイッチ５１５は受信制御部５１２の処理に従い、フレーム処理をプロセッサ５１４に通知するか、フレーム情報をメモリ５１５に保持するか、スイッチ５２０へ転送するか、といった判断を行う。送信制御部では、内部ヘッダ取り外し、シェーピングといった送出フレームの整形、タイミング制御を行う。【００４３】
受信制御部において、フレーム解析によってＣＣフレームであることが分かった場合の処理例を説明する。受信制御部にて、当該フレームからＯＡＭ情報を読み出すため、メモリ５１５に一時格納し、メモリ５１５内のＣＣＤＢ５５０にＯＡＭ情報を反映させることを示す内部ヘッダを付与する。スイッチ５１３ではフレームをメモリ５１５に転送すると共に、プロセッサ５１４へその格納完了を通知する。また、本実施例ではノード全体のＣＣＤＢ情報を集約して管理するためのＣＣＤＢ５４１を装置制御部５００に備えており、スイッチ５１３はスイッチ５２０へも当該フレームを転送する。スイッチ５２０は当該フレームをメモリ５０２に格納するとともに、プロセッサ５０１にその旨を通知する。ＣＣフレームを終端するべきか他ノードへ転送すべきかについては、入出力処理部５１０のプロセッサ５１４、若しくは装置制御部５００内のプロセッサ５０１で判断される。どちらで判断されるかは、ＣＣＤＢ５５０及びＣＣＤＢ５４１に保持されるＭＥＧＩＤ情報のうち、受信フレームに該当するものがあるか否かにより異なる。【００４４】
もちろん、ＣＣＤＢを装置制御部５００内にのみ保持し、各入出力処理部５１０−ｉから参照する形でも構わない。また、一旦全てのＯＡＭ情報をＣＣＤＢ５４１に記録した後、必要な情報を、随時個別のＣＣＤＢ５５０に反映する方法を採ることもできる。これらの方法では、ＯＡＭ情報が装置制御部に集中するため、データベースの更新処理のタイミング等によって双方のデータベースに保持される情報の相互矛盾が生じることを回避できる。また、装置制御部にてＯＡＭ情報のハンドリングをまとめられるため、情報管理を行い易いという利点がある。【００４５】
図６は、ＭＥＰにおける、フレーム受信からＣＣＤＢ構築までの処理の流れを説明するフローチャートである。【００４６】
フレームを受信すると、ステップＳ１０１でＥｔｈｅｒＴｙｐｅフィールドを参照し、ＯＡＭフレームか否かを判断する。ＯＡＭフレームではない場合、通常のフレーム転送若しくは終端処理を行うため、ＯＡＭフレームに関わる本フローチャートの処理は終了する。ステップＳ１０２でＯＡＭフレームであることが分かると、続くステップＳ１０３でＯＡＭバージョンの確認、さらにステップＳ１０４でＭＥレベルの確認を行う。ステップＳ１０５ではＭＥレベルの正誤判断を行う。予期しないＭＥレベルのフレームが到着したときは、警報を送出（ステップＳ１１５）して処理を終了する。正しいＭＥレベルのＯＡＭフレームであった場合は、ステップＳ１０６で、ＯＡＭ種別を示すＯｐＣｏｄｅを読み込む。ＯｐＣｏｄｅ参照の結果、ステップＳ１０７でＣＣフレームでなかった場合、そのＯＡＭ毎の処理を行うため、ステップＳ１１６に移行する。【００４７】
ＣＣフレームの場合、ステップＳ１０８で、ＭＥＧＩＤの確認、及びステップＳ１１０でＭＥＰＩＤの確認を行う。それぞれ、予め設定されたＭＥＧＩＤ、ＭＥＰＩＤでない場合にはステップＳ１０９、Ｓ１１１において警報が送出され（ステップＳ１１７，Ｓ１１８）、処理を終了する。ＭＥＧＩＤとＭＥＰＩＤが予め設定されたものである場合、ＣＣフレームの受信間隔を確認し（ステップＳ１１２）、ＯＡＭ情報として設定された値の通りであれば、ステップＳ１１４で受信フレームの内容をＣＣＤＢに記録するか、エントリが既にある場合には、当該エントリの情報を更新する。ＣＣフレームの受信間隔が設定値と異なる場合、ステップＳ１１３からＳ１１９に移り、警報を出力した後に処理を終わる。【００４８】
図７は、ＯＡＭ対象経路上の中継ノード２の構成を示す機能ブロック図である。基本構成は図５に示すエッジノードの構成と同様である。中継ノードにおいては、ＭＥＰＩＤを学習するＣＤＤＢを持たないため、転送制御テーブル７５０を入出力処理部５１０に備える。また、ＯＡＭ情報ＤＢ７４０についてもエッジノードとは保持する内容が異なる。【００４９】
ＯＡＭ情報ＤＢ７４０について説明する。現在の勧告（非特許文献１、３）では、エッジノード（ＭＥＰ）に保持するＣＣＤＢが自装置のポートに割当てられるＭＥＰＩＤ、ＭＥＧＩＤ、ＭＥレベルを含むのに対し、中継ノードではポートにＭＥＰＩＤを持たない。中継ノードでは、受信したＯＡＭフレームのＭＥレベルが正しいか否かを確認するよう規定されており、ＭＥＰのようなトポロジー学習機能が規定されていない。そこで、ＯＡＭ情報ＤＢ７４０には、ポート毎のＭＥレベル情報を設定することになる。【００５０】
中継ノードでのＯＡＭフレーム識別、及び転送経路制御のために転送制御テーブル７５０を備える。本テーブルは、入出力処理部５１０毎に備えているが、図５の場合と同様に装置制御部５００内に保持される構成も可能である。ここでは図７の構成で説明する。【００５１】
受信されたＣＣフレームは、スイッチ５１３からメモリ５１５に送られる。またスイッチはプロセッサ５１４にその受信を通知する。プロセッサ５１４はメモリ５１５内のＣＣフレームから、ＭＥレベル、ＭＥＧＩＤ情報を読み出し、受信ＣＣフレームのＭＥレベルが、受信ポートに設定されたＭＥレベルと一致する場合に、受信制御部５１２にて受信フレームに付与される内部ヘッダに含まれる受信ポートＩＤと共に、転送制御テーブル７５０にその対応関係を保持する。【００５２】
転送制御テーブル７５０により、マルチキャストＤＡを持つＯＡＭフレームの経路制御が可能である。中継ノードにおいてはＭＥレベルの判定のみが規定されており、ＯＡＭフレームからＭＥＰＩＤ，ＭＥＧＩＤを学習する機能は用意されていない。そこで、宛先アドレスからは転送先が特定できないマルチキャストＤＡを含むＯＡＭフレームについては、経路制御が不可能であった。【００５３】
図８は、中継ノードにおけるＣＣフレーム受信から転送制御テーブル７５０構築までの処理の流れを説明するフローチャートである。【００５４】
ステップＳ１０１からステップＳ１０７までの処理は、図６の説明と同様である。ＣＣフレーム以外のＯＡＭフレームを受信した場合、ステップＳ１１６において、後述する方法により当該ＯＡＭフレームの転送経路を学習することも可能である。【００５５】
ステップＳ１０８、Ｓ１１０で取得する受信ＣＣフレームのＭＥＧＩＤとＭＥＰＩＤは、受信ポート情報と対応付けて、ステップＳ２０１において転送制御テーブルに格納される。【００５６】
図９に中継ノードに保持される転送制御テーブル７５０の基本構成を示す。本テーブルは、ＭＥレベル９０１、ＭＥＧＩＤ９０２、受信ポートＩＤ９０３を含む。テーブルの各エントリは、ＣＣフレームを受信した時刻、すなわちエントリが生成された時刻から一定時間経過した場合に削除する。ＣＣフレームはエッジノードより定期的に送出されるため、エントリが既に存在する場合には、タイマを更新することで経路情報を保持する。これによって、常時最新のＯＡＭ経路情報を利用することが可能である。【００５７】
図１０は、本実施例におけるＯＡＭフレーム、特にＣＣフレームの経路学習効果を説明する図である。
ＣＣＤＢ及び転送制御テーブルが、経路上のノードにおいて構築された状態を考える。エッジノードＥＮ１ａより送出されたＣＣフレームは、中継ノードＭＮ２ａにおいて、そのＭＥレベルとＭＥＧＩＤから、送出先ポートが選択されて中継ノードＭＮ２ｂに転送される。中継ノードＭＮ２ｂでは、同様にＭＥレベルとＭＥＧＩＤを参照して、エッジノードＥＮ１ｂへＣＣフレームを転送する。転送制御テーブル７５０によって、中継ノードＭＮ３ｅへのフラッディングが抑止され、ＯＡＭの処理効率化と管理ドメイン全体でのリソース利用効率化が実現できる。【００５８】
図１１には、図１に示したポイントツーポイントでのＭＥトポロジーの一般的な形として、同一のＭＥＧＩＤの中に複数の経路の異なるＭＥを含む場合のＭＥ構成を示す。【００５９】
このとき、以下の二通りのＭＥ設定方法が考えられる。一つには、ＭＥのレベルがＭＥＧ１とＭＥＧ２とで各々異なるように設定する方法であり、もう一つは同レベルのＭＥＧで経路の異なるものを同一管理ドメイン内に設定する方法である。前者はＯＡＭフレームのマルチキャストＤＡによってＭＥ、すなわちＭＥＧを識別できるため、ポイントツーポイントのＭＥＧが独立に複数存在することになり、図１で説明したＯＡＭ制御方法をそのまま双方のＭＥＧＩＤに対して適用することで、ＭＥＧ単位での経路制御を実現できる。後者はＭＥレベルが同一であることから、複数のＭＥを束ねるＭＥＧは単一のＩＤで表される。そのためＭＥＧＩＤレベル、若しくはマルチキャストＤＡが示すＭＥレベルでの経路構成を考えると、複数の装置から構成されるエッジノードグループ（ＭＥＰグループ）が、複数の絡み合った経路を介して別のエッジノードグループに接続される二次元の網目構造を成す。【００６０】
このとき、図１で説明したように、ＣＣフレームに含まれるＭＥＰＩＤとＣＣＤＢを参照することにより、同一ＭＥＧＩＤを含む複数の送信ポートの中から、当該ＣＣフレームを送出するべき方路を選択することができる。一方、例えばＬＢ（Ｌｏｏｐ  Ｂａｃｋ）フレームのようにＭＥＰＩＤを含まないＯＡＭフレームに関して、どのポートへＣＣフレームを送出するかを判断できない。この場合は個別のＭＥＰに向かう方路を限定することは原理上不可能である。しかしながら、マルチキャストＤＡ（ＭＥレベル）と、ＭＥＧＩＤと、受信ポートとを関連付けるＯＡＭ転送制御テーブルを用意することにより、図１に説明したＯＡＭ制御方法で、当該ＭＥＧＩＤが設定された管理パスにのみＯＡＭフレームを転送することが可能となる。これによって、管理対象外の装置及びポートにＯＡＭフレームを処理させるという事態を回避できることから、管理ドメイン内リソースの負担を軽減し、ひいてはユーザトラフィックへの影響を抑えることができる。【００６１】
エッジノードＥＮ１ａ〜１ｃでは、ＭＥＰＩＤを用いてＭＥ１とＭＥ２を識別できる。ＥＮ１ａからは対向エッジノード１ｂ、１ｃへＣＣフレームが送出され、ＥＮ１ｂからＥＮ１ａへ、ＥＮ１ｃからＥＮ１ａへそれぞれＣＣフレームが送出される。中継ノードでは、ＭＥＰＩＤを識別できないため、ＭＮ２ａではＭＥＧＩＤが同一の場合はＭＮ２ｂとＭＮ２ｃへの経路を識別することができない。そのため、各方向へ２つのＣＣフレームをそれぞれフラッディングする。しかしながら、例えばＭＮ２ａがＭＮ２ｂ、ＭＮ２ｃ以外にノード３ｅと接続されていた場合には、これまでに説明した方法によりノード３ｅへのフレーム転送を抑止することができる。ＭＮ２ｃでは、ＥＮ１ｂからのＣＣフレームを受信していないため、転送制御テーブルを参照すればＭＮ２ａからのＣＣフレーム転送先をＥＮ１ｃに絞ることができる。ＭＮ２ｃにおける動作は、図１０の場合と同様である。【００６２】
以上のように、フレーム内にＭＥＧＩＤを含むフレームは、中継ノードによってその転送方路をＯＡＭ対象経路にのみ絞り込むことが可能である。図１１の場合にはＯＡＭ対象経路上のフレーム数が増加するが、マルチキャストＤＡを使用する場合に、本発明を適用しないとき、ＯＡＭ対象外のノードへのフラッディングされるフレーム数は、各ノードにおいて分岐ＭＥ数倍だけ増加することになる。従って、本発明は図１１のようなマルチキャスト形態において、より有効と考えられる。【００６３】
これまでＣＣフレームを対象とする経路制御方法を説明してきた。ここではＣＣフレーム以外のＯＡＭフレームについて、その経路制御方法を提案する。【００６４】
ＭＡＣアドレスで送信先を識別する場合、ＯＡＭフレームの宛先アドレスにはＭＥレベルを示すマルチキャストＤＡが用いることが想定されていない。そこで、ＯＡＭフレームにＭＥレベルを表すマルチキャストＤＡを用いる方法に統一するには、宛先を意味する別の情報をフレーム内に含む必要がある。そうでなければ、中継ノードにおいて経路を絞りこむことができない。マルチキャストＤＡの別の用途としては、例えば、複数の宛先に対してＬＢフレームを送出する場合に宛先ノードのグループをマルチキャストアドレスで指定することが考えられる。中継ノードでは、ＭＥに関する情報としてはＭＥレベル以外に利用できないことになっており、このときは必然的にフレームが全ての方路へフラッディングされてしまう。【００６５】
これを防ぐため、宛先ＭＡＣアドレスで送信先を指示することになっているＯＡＭフレームに関しても、そのフレーム内に中継ノードでのＭＥ識別パラメータとしてＭＥＧＩＤを含むことで、その転送経路を限定することができる。ＭＥはポイントツーポイントでの使用が前提であり、上述のマルチキャストＬＢにおいても、複数のＭＥを束ねたトポロジーで実現することが想定される。従って、ＯＡＭフレームを送出するエッジノードにおいて、宛先ＭＡＣアドレスもしくは宛先ＭＡＣアドレスグループとしてのマルチキャストＭＡＣアドレスに対応するＭＥＧＩＤを取得してフレームに挿入する。【００６６】
図１２は、そのためにエッジノードにおいて保持する、宛先ＭＡＣアドレス１２０１とＭＥＧＩＤ１２０２との対応テーブル１２００の構成例である。本テーブルはＣＣＤＢの拡張として準備してもよいし、ＣＣＤＢとは別に用意してもよい。なお、ＣＣＤＢには宛先ＭＡＣアドレスをエントリ内に保持することが規定されていないため、本テーブルを新たに追加することが必要である。中継ノードにおける経路学習動作については、図８と同様である。また、この方法を用いる場合は、ＭＥ設定時にネットワーク構成を参照して宛先ノードのＭＥＰ、ＭＡＣアドレスを設定しておくことが必要である。通常のオペレータによる設定を想定すれば、ネットワークの構成は予め分かっているため、容易に実現できる。【００６７】
ここまでは、中継ノードもエッジノードと同様にＯＡＭ機能をサポートする場合の経路制御方法を説明した。しかしながら、網の設備移行期には、全てのノードがＯＡＭ機能を備えているとは限らず、既存のスイッチを用いてネットワークを構成する場合も考えられる。以下、ＯＡＭをサポートしないスイッチが共存する場合のＯＡＭフレーム経路制御について説明する。【００６８】
なお、図１１で述べたのと同様に、同一ＭＥＧＩＤに経路の異なる複数のＭＥを含む場合は通常のポイントツーポイントＭＥの場合と同様に扱えるため、以下では特に言及せずにポイントツーポイントの場合を例として説明する。【００６９】
図１３は、中継ノードに既存ノード（ＯＡＭ機能をサポートしないノード）、エッジノードにＯＡＭをサポートするノードを用いた場合のネットワーク構成を示す。中継ノード５ａ、５ｂがＯＡＭをサポートしない点を除いて、経路制御の概念は図１の場合と同様である。本実施例では、中継ノードにおける転送経路制御テーブル５０ａ、５０ｂを構築するに当たって、従来ノードに備えられているＩＧＭＰ／ＭＬＤ  ｓｎｏｏｐｉｎｇ機能を利用する。すなわち、エッジノードではＩＧＭＰ／ＭＬＤのｒｅｐｏｒｔ  フレームフォーマットを利用して経路設定フレームを送出し、受信した中継ノードはｓｎｏｏｐｉｎｇ機能により、当該フレームの受信ポートを学習する。この機能を利用し、ＭＥの両端からＩＧＭＰ／ＭＭＬＤフレームフォーマットのＯＡＭ経路設定フレームを送出することで、ＯＡＭフレーム転送方路を絞り込める。転送制御テーブル５０ａ、５０ｂはｓｎｏｏｐｉｎｇにより設定される、ポート別フレーム送信方路制御テーブルである。【００７０】
図１４は図１３の実施例での経路設定シーケンスである。処理１４０１、１４０２にてＯＡＭ対応ノードであるエッジノードでＭＥの設定を行う。エッジノードでは、処理１４０３で生成する経路設定用フレームを、ＭＥの属する方路へ送出し（処理１４０４）、そのフレームを受信したノードは、ｓｎｏｏｐｉｎｇ処理により、マルチキャストアドレスと受信ポートの対応関係を学習する（処理１４０５）。この制御情報は、エントリの有効期限をタイマによって管理する。以下、同様に処理１４０６〜１４０７で中継ノードＭＮ５ａが経路情報を取得し、ＭＥの終端点であるエッジノード１ａに経路設定フレームを転送する（処理１４０８）。エッジノード１ａでは、設定フレームを終端して、自装置にｓｎｏｏｐｉｎｇによる転送制御テーブルを構築して処理を終了する（処理１４０９）。【００７１】
以上の処理を逆方向に対しても行うことにより、ＭＥに沿ったＯＡＭフレーム転送経路１４１０が設定できる。【００７２】
なお、ＯＡＭ対応のエッジノードにおいてＣＣＤＢを構築するためには、ＣＣフレームを送信しなければならない。本方式ではエッジノードからは経路設定フレームを送出してＯＡＭ経路が構築できた後に、各ノードで学習されているマルチキャストＤＡを持つＣＣフレームを送出することで、ＣＣフレームのフラッディングを抑止できる。【００７３】
図１５はＭＥを削除するときに、経路情報を削除する方法の一例を示すシーケンスである。処理１５０１及び１５０２にてＭＥを削除した後、エッジノードからは経路設定用フレームを送出する。このときのフレームは、ＩＧＭＰ／ＭＬＤの、グループ離脱通知を利用する。例えばＩＧＭＰｖ２のフォーマットでは、Ｌｅａｖｅメッセージを利用する（処理１５０３）。このメッセージ送出１５０４とそれに伴う学習処理１５０５で、当該エントリがｓｎｏｏｐｉｎｇテーブルより削除される。これをエッジノード１ａに到達するまで繰り返すことで、経路情報をクリアする（処理１５０６から１５０９）。【００７４】
図１６は、単一ＭＥ上のノードのＯＡＭ対応状況は図１３と同様であるが、管理ドメイン内に複数のＭＥを設定する場合のネットワーク構成例である。ここで、ＭＥはそれぞれ異なるＭＥＧＩＤに属するか、図１６のように一つのノードに複数のＭＥが存在しないように設定したとき、それぞれのＭＥを独立して識別する必要が生じる。【００７５】
この様な状況でマルチキャストＤＡ毎の経路制御を独立して行うため、管理ドメイン内では、ＶＬＡＮ毎にｓｎｏｏｐｉｎｇ処理を行う必要がある。Ｓｎｏｏｐｉｎｇ処理では、ＩＧＭＰ／ＭＬＤ  Ｒｅｐｏｒｔメッセージを受信すると，メッセージに含まれるマルチキャストグループアドレスからマルチキャストＭＡＣアドレスを学習し，ＩＧＭＰ／ＭＬＤ  Ｒｅｐｏｒｔメッセージを受信したポートにだけマルチキャストグループ宛のトラフィックを転送するエントリを作成する。【００７６】
具体的には、管理ドメイン内でユーザデータを転送するために単一のＶＬＡＮドメインを設定し、個々のＭＥＧＩＤを識別するため、及びＯＡＭフレームとユーザデータを識別するために、ＭＥＧＩＤ毎に別々のＶＬＡＮドメインを設定する。従って、管理ドメイン内にはユーザデータ転送用、ＭＥＧＩＤ用のＶＬＡＮをそれぞれ互いに独立に設定し、ＭＥに沿ったノードにはユーザデータ用ＶＬＡＮとＯＡＭ用ＶＬＡＮの双方を収容するよう設定する。【００７７】
本構成の場合、図１４及び図１５のシーケンスで、エッジノードからＩＧＭＰ／ＭＬＤフレームを送出する際に、ＭＥＧＩＤに対応するＶＬＡＮタグを付与して送出する。これにより、中継ノードではＶＬＡＮ毎にｓｎｏｏｐｉｎｇ処理を行い、ＶＬＡＮ単位でポートを識別して、個々の論理ポート毎に経路制御テーブルを構築する。【００７８】
図１７はエッジノードＥＮ１ａ、１ｂから送出するＩＧＭＰ／ＭＬＤフレームの例を示す。ここではＩＧＭＰｖ２のフォーマットに従う場合のフレーム構成例を示す。しかし本発明は他のプロトコルにも適用可能である。【００７９】
フレームには、イーサネットヘッダ、ＩＰヘッダ、ＩＧＭＰヘッダを含む。宛先アドレス１７０１は、マルチキャストグループアドレス１７０８の下位２３ビットと、マルチキャストであることを示す固定パターンを含む２５ビット情報とを組み合わせて生成する。送信元アドレス１７０２は、送出元エッジノードのポートに設定されたアドレスである。ＥｔｈｅｒＴｙｐｅフィールド１７０３には、ＩＧＭＰメッセージであることを示すＸＸＸＸが入る。ＶＬＡＮタグ１７０４、１７０５は、必要に応じて挿入する。図１６に示すように、管理ドメイン内に複数のＭＥＧＩＤを設定する場合は、ＶＬＡＮ  ＩＤでのＯＡＭ経路識別を行うため、ＶＬＡＮタグが必要である。ＩＰヘッダには、宛先ＩＰアドレス１７０８、及び送信元装置に設定されるＩＰアドレス１７０７を含む。宛先ＩＰアドレスは、ＩＧＭＰメッセージの種別によって固定的に割当てられており、グループへの参加要求の場合は２４４．０．０．１、グループからの離脱要求の場合は２２４．０．０．２が挿入される。【００８０】
ＩＰパケットの中には、ＩＧＭＰメッセージ１７１０を含む。ＩＧＭＰメッセージ１７１０には、ＩＧＭＰＴＹＰＥ情報１７１１、最大応答時間１７１２、マルチキャストグループアドレス１７１５（必要に応じて、Ｒｅｓｅｒｖｅｄ１７１３，Ｃｈｅｃｋｓｕｍ１７１４）を含む。ＩＧＭＰＴＹＰＥフィールド１７１１は、ＩＧＭＰメッセージの種別を示す。参加要求メッセージの場合は０ｘ１１、グループ離脱メッセージの場合には０ｘ１７となる。Ｓｎｏｏｐｉｎｇ対象となるのは、マルチキャストグループアドレス１７１５である。ここでｓｎｏｏｐｉｎｇ対象アドレス１７０８は、ＯＡＭフレームに付与するマルチキャストアドレスの一部（下位２３ビット）を含む、ＩＰマルチキャストアドレスである。送信元ＩＰアドレスについては、エッジ装置がそれぞれのポートにおいてＩＰ情報を保持している場合には送出ポートのＩＰアドレスを挿入する。但し、本送信元ＩＰアドレスフィールドはＯＡＭフレームの制御には不要のため、フレーム制御に影響の出ない範囲でダミーのアドレスを挿入しておけばよい。【００８１】
図１８は、図１３若しくは図１６のＯＡＭトポロジーにおいて、エッジノードでのＯＡＭ経路設定フレームを生成する処理の流れを示すフローチャートである。
Ｓ３０１でＯＡＭを適用するネットワークにおける、ＭＥＧＩＤ設定数を調べる。なお、ＭＥＧＩＤが単一の場合でも、ＶＬＡＮを用いてユーザデータとＯＡＭフレームとを識別してもよい。ＶＬＡＮを使用する場合は、ステップＳ３０２においてエッジノード内に保持しているＭＥＧＩＤとＶＩＤとの対応テーブル（以下、ＯＡＭトポロジ管理テーブルと称する）を参照し、該当するＶＩＤを取得する。取得したＶＬＡＮ  ＩＤを含むタグを挿入し、図１７のステップＳ３０３に示すようにＩＧＭＰフレーム若しくはＭＬＤフレームを生成して、ＯＡＭ対象経路に向けて送出する。【００８２】
図１９は中継ノードにおいて保持するＯＡＭフレーム転送制御テーブルの構成例である。Ｓｎｏｏｐｉｎｇ機能を用いるため、基本構成は従来のスイッチのものと同様である。ＶＬＡＮ毎に、マルチキャストグループアドレスと受信ポートとの組合せを学習する。具体的には、ＩＧＭＰ／ＭＬＤ  Ｒｅｐｏｒｔメッセージを受信すると，メッセージに含まれるマルチキャストグループアドレスからマルチキャストＭＡＣアドレスを学習し，ＩＧＭＰ／ＭＬＤ  Ｒｅｐｏｒｔメッセージを受信したポートにだけマルチキャストグループ宛のトラフィックを転送するエントリを作成する。学習するアドレスについて、ここではデータリンク送のＯＡＭ機能を提供することが目的であるため、マルチキャストＭＡＣアドレスを受信ポートと関連付けてテーブルを構成する。通常のスイッチでは、ＩＰマルチキャストアドレスとＭＡＣマルチキャストアドレスを共に学習して、受信ポートＩＤと関連付けて管理することが多い。ＩＰマルチキャストアドレスを管理テーブルに含んでもよいし、ファームウエアで別途マルチキャストフローの管理を行ってもよいが、ここではイーサＯＡＭなどレイヤ２ＯＡＭフレームの経路制御を実現するため、ＭＡＣアドレスを学習する方法を例示する。【００８３】
テーブルは、マルチキャストＭＡＣアドレス１２０１、ＶＬＡＮ  ＩＤ１２０２、受信ポート１２０３を含む。マルチキャストアドレスはＭＥレベルを、ＶＬＡＮ  ＩＤはＭＥＧＩＤを示すものであり、図９の転送制御テーブルに対応するテーブルである。【００８４】
図２０は図１２の説明で述べたように、ＯＡＭフレームにＭＥＧＩＤを含まないフレームについて、転送経路を制限するためのテーブル２０００である。ＭＥＧＩＤを含まない場合、図１３〜図１９の方法では、中継ノードにおいて受信ＯＡＭフレームが対象とするＭＥを識別できないため、ＭＥレベル（すなわち、マルチキャストアドレス）以外でのフィルタリングができない。【００８５】
そこで、ＯＡＭフレームを送出する際に、エッジノードにおいて、経路制御のためのＶＬＡＮタグを付与する。ＯＡＭ対象経路上のポートに設定されたＭＥＰ，ＭＩＰのＩＤもしくはＭＡＣアドレス２００１は、エッジノードにおいて設定される。そこで、これら対象とするＭＥ情報（ＭＥＰ／ＭＩＰＩＤ、ＭＥレベル、ＭＥＧＩＤ）に対して、対応するＶＬＡＮ  ＩＤ２００２を予め設定しておき、本テーブルに記載しておく。ＯＡＭフレーム送出時に、ＯＡＭが対象とするＭＥについて、ＣＣＤＢからＭＡＣアドレス及びＭＥレベルとから、対応するＭＥＧＩＤ、ＭＥＰ・ＭＩＰＩＤを取得する。さらにＭＥＧＩＤに対応するＶＬＡＮ  ＩＤを取得する。このＶＬＡＮ  ＩＤをタグに挿入したＯＡＭフレームを生成することにより、ＭＥＧＩＤ情報を含まないＯＡＭフレームについても、ＣＣフレームと同様に制御できる。図２０のテーブルは、この、ＭＥＧＩＤを介してＶＬＡＮを取得する過程において、対応するパラメータを直接対応付けるものである。図１２のテーブルを拡張してもよいし、本テーブルをそのまま実装することでも実現できる。【００８６】
図２１は、ＭＥＧを複数設定（ＭＥＧ１：２１２０，ＭＥＧ２：２１１０）し、かつＭＥＧに含まれるＭＥがすべて管理ネットワーク内で閉じたＯＡＭ領域を構成する場合のＯＡＭトポロジーを示す。すなわち、管理領域内に領域を識別するためのＭＥＧＩＤを設定する。これは装置の入替え、装置ベンダの違い等を反映してネットワークの一部分に対し、他と区別して性能測定その他の運用管理を行いたい場合に利用する。
このケースでは、通常ＭＥＧＩＤで識別される管理領域の境界にはＭＥＰが設定されるため、正しく設定されている以上、他のＭＥＧＩＤの領域へフレームが転送されることはない。但し誤接続などの理由により他のＭＥＧＩＤ領域からのＯＡＭフレームが混入した場合に、その転送を抑止する必要がある。本ケースに関して、装置に要求される機能は図２０までに説明したポイントツーポイントのケースと同様である。但し、この場合は、正しいＭＥＧＩＤの転送先を識別方法以外に、不正なＭＥＧＩＤのフレームを転送しないように予め有効ＭＥＧＩＤを設定しておく方法も可能である。【００８７】
以上、ＭＥＧＩＤ情報をＶＬＡＮ  ＩＤに変換して制御する方法を説明したが、これらＶＬＡＮ  ＩＤ情報は、ＭＰＬＳラベル情報に置き換えることで、ＯＡＭの対象パスをラベル情報に基づき識別することができ、ＭＰＬＳ網におけるＯＡＭ機能についても同様に経路制御を実現することができる。【００８８】
以下に本発明の効果を具体的に説明する。上記本発明で想定する動作と比較するため、ここでは本発明のイーサＯＡＭ制御方法を使用しない場合における、ネットワーク内パケット処理手順を示す。【００８９】
図２２は、図１のネットワークを、イーサＯＡＭに対応しない装置のみで構成した場合の構成例を示す。図１３で、中継ノード２ａ，２ｂに転送制御テーブルを持たない場合と同等である。このとき、図２２の各ノードは従来Ｌ２フレーム若しくはＬ３パケットを転送するために用いてきたＡＲＰテーブルとＩＰルーティングテーブルとを備えている。今、ネットワーク管理ドメインは一つのＶＬＡＮで構成されるものとする。【００９０】
ＯＡＭフレームが装置１ｂから挿入されるものとし、ユーザデータが流れるパスを装置１ｂから２ｂ，２ａを経て装置３ａに至る経路とする。通常、装置を（例えばＥｔｈｅｒｎｅｔで）相互に接続し、接続される装置インタフェース間にルーティングプロトコル（例えばＯＳＰＦ又はＲＩＰ）が動作するよう設定することにより、装置内メモリにＡＲＰテーブル及びＩＰルーティングテーブルが構成される。これにより、各装置が受信したパケットのヘッダ情報である宛先ＭＡＣアドレス若しくは宛先ＩＰアドレスによって、各々のパケットを転送すべきインタフェースを装置内で識別でき、ユーザデータは目的の場所に到達する。【００９１】
一方ＯＡＭフレームを転送するには、ＭＡＣレイヤにてＯＡＭフレームの宛先を知らなければならない。イーサＯＡＭはＬ２処理のため、上位プロトコルであるＩＰプロトコルは、ＯＡＭフレームの転送に一切関与しない。そのため、従来持っているＡＲＰテーブル及びＩＰルーティングテーブルはＯＡＭフレーム転送制御には使用できない。【００９２】
図２２では、フレームを送信するノード１ｂ、フレームの宛先であるノード１ａ以外はＯＡＭフレームとその他ユーザデータフレームを識別する手段を持たない。そこで、ノード１ｂ，１ｃ以外のノードでは、ＯＡＭフレームは単にブロードキャストフレームと見なして転送処理を行う。【００９３】
マルチキャストフレームは、同一のＶＬＡＮドメイン内ではブロードキャストされる。従って図２２のネットワークにおいて、ノード２ｂのインタフェースＡで受信したＯＡＭフレームは、インタフェースＢ，Ｃへコピー、転送される。同様にノード２ａにおいては、インタフェースＤで受信したＯＡＭフレームは、インタフェースＥ，Ｆへも同時に展開される。このように、マルチキャストアドレスを用いるＯＡＭフレームは、経路上で各方向に展開され、他のノードを介してネットワーク全体に拡大する。図中には、ＥＮ１ａに向かうフローのみ記述しているが、ＥＮ１ｂからのＯＡＭフレーム送信後、一定時間経過後の定常状態では、中継ノードであるＭＮ２ａ，ＭＮ２ｂ，ＭＮ３ｅでは全インタフェースからＯＡＭフレームがブロードキャストされることになる。この状態では特定経路の監視は不可能である。【００９４】
上記の状態は、ネットワークリソースを浪費するだけではなく、ＯＡＭフレーム、特にＣＣフレームのように経路の状態確認を行うためのフレーム処理を実現するために、イーサＯＡＭを理解する装置において特別な処理を必要とする。例えば、想定する時間内に得られる返信による状態通知のみ採用し、その他は不要経路を通過したパケットによる誤った経路情報として廃棄する、などの方法が考えられるが、こうした処理を行うには通常システム構成により変化するトラフィックパターンを全て把握する必要があり、一般に正しく動作させるための条件設定は困難である。よって、従来のテーブルのみではＯＡＭフレームを有効に利用することができない。【００９５】
以上より、イーサネットやＭＰＬＳのようなパケット通信網においてＬ２レベルでの通信の保守管理を実現するためには、ＯＡＭ対応中継ノード若しくはＯＡＭ非対応中継ノードにおいて本発明の転送制御テーブルが必要となる。【００９６】
図２３は、イーサＯＡＭ機能を適用するネットワークの構成例として、光アクセスシステム（ＰＯＮ；Ｐａｓｓｉｖｅ  Ｏｐｔｉｃａｌ  Ｎｅｔｗｏｒｋ）を含む場合を示す。【００９７】
ネットワークサービスの充実とコンテンツ数及びサイズの増大により、エンドユーザのネットワーク利用の伴うトラフィック量が拡大している。そのため加入者収容回線も光通信が主体となり、更なる高速化が進められている。ユーザトラフィックはその殆どがイーサネットで実現されている。安価かつ取扱い易い反面、ネットワークトポロジの変更が頻発すること、ＣＳＭＡ／ＣＤ方式の通信であってパケット伝送に不測の遅延やパケットロスが発生し得るベストエフォート方式であることから、その通信品質を確保することが難しい。特に近年、放送通信融合が唱えられており、また行政や個人生活を支える社会インフラとしてのネットワークが浸透してきた現在は、イーサネットを初めとするパケット網において通信を確保することが必須となりつつある。【００９８】
図２３は、ＰＯＮを含むキャリア網を介して各家庭若しくは企業をネットワークに接続する形態を示す。ここで、キャリア網としては広域イーサネット網、若しくはＭＰＬＳを用いた中継用のパケット伝送網を指す。従来、中継網は専用線で構成されてきたが、近年はより柔軟なシステム構築、ネットワークリソースの有効活用等によるコスト削減を求め、専用線通信からパケット通信へのシフトが進んでいる。ＰＯＮシステムは光信号を用いた大容量な情報配信システムである。主にＬ２未満の処理を行うシステムであるが、イーサネットや電話線など複数のサービスを収容するため、イーサＯＡＭの実装が必要である。【００９９】
図２３では両端にＰＯＮを接続した例を示す。ＰＯＮが収容するものは、各家庭からのユーザ回線、企業サイトから中継網へのアクセス回線、また無線キャリアの基地局など拠点間を接続するための中継光回線としても使用できる。ここではＯＬＴ（Ｏｐｔｉｃａｌ  Ｌｉｎｅ  Ｔｅｒｍｉｎａｌ）２３０１にＥＮ１が収容される形で記述したが、ここでは要素のみ記述しており、実際の装置としては一体型でも分離型でも構わない。なお、２３０２はＯｐｔｉｃａｌ  Ｎｅｔｗｏｒｋ  Ｕｎｉｔ（ＯＮＵ）である。【０１００】
ここでは２階層でのＭＥ設定例を示した。上位にエンド・ツー・エンドのサービス区間を監視するためのＭＥ２３４０、その下位で各セグメント毎に経路状況を保守管理するためのＭＥとして、ユーザセグメントＭＥ２３３０、ＰＯＮセグメントＭＥ２３２０、イーサセグメントＭＥ２３１０を設定する。もちろんさらに細かく階層化することは可能である。ＰＯＮセグメントはＰＯＮ区間ＯＡＭ機能を別途適用することもできるが、エンド・ツー・エンドの保守を行うためには、図のようにＰＯＮ区間の保守にイーサＯＡＭを適用する方法も考えられる。【０１０１】
上記記載は実施例についてなされたが、本発明はそれに限らず、本発明の精神と添付の請求の範囲の範囲内で種々の変更および修正をすることができることは当業者には明らかである。
【図面の簡単な説明】
【０１０２】
【図１】ネットワークの管理ドメイン内でのＭＥ設定例を示す。
【図２】図１のネットワーク構成においてＯＡＭ転送制御テーブルを生成する手順を示すシーケンスである。
【図３】図２のシーケンスで設定したＯＡＭフレーム転送制御テーブルから、不要なエントリを削除する場合のシーケンスを示す。
【図４】マルチキャストＤＡを含むＯＡＭフレームフォーマットを示す。
【図５】イーサＯＡＭをサポートするフレーム通信装置の構成を表す機能ブロック図である。
【図６】ＭＥＰにおける、フレーム受信からＣＣＤＢ構築までの処理の流れを説明するフローチャートである。
【図７】ＯＡＭ対象経路上の中継ノードの構成を示す機能ブロック図である。
【図８】中継ノードにおけるＣＣフレーム受信から転送制御テーブル７５０構築までの処理の流れを説明するフローチャートである。
【図９】中継ノードに保持される転送制御テーブル７５０の基本構成を示す。
【図１０】本実施例におけるＯＡＭフレーム、特にＣＣフレームの経路学習効果を説明する図である。
【図１１】図１に示したポイントツーポイントでのＭＥトポロジーの一般的な形として、同一のＭＥＧＩＤの中に複数の経路の異なるＭＥを含む場合のＭＥ構成を示す。
【図１２】ＭＥＧＩＤを含まないＯＡＭフレームの経路制御を行うにあたり、エッジノードにおいて保持する、宛先ＭＡＣアドレス１２０１とＭＥＧＩＤ１２０２との対応テーブルの構成例である。
【図１３】中継ノードに既存ノード（ＯＡＭ機能をサポートしないノード）、エッジノードにＯＡＭをサポートするノードを用いた場合のネットワーク構成を示す。
【図１４】図１３の実施例での経路設定シーケンスである。
【図１５】ＭＥを削除するときに、経路情報を削除する方法の一例を示すシーケンスである。
【図１６】図１３の条件で、管理ドメイン内に複数のＭＥを設定する場合のネットワーク構成例である。
【図１７】図１３及び図１６において、エッジノードから送出するＩＧＭＰ／ＭＬＤフレームの例を示す。ここではＩＧＭＰｖ２のフォーマットに従う場合のフレーム構成例を示す。
【図１８】図１３若しくは図１６のＯＡＭトポロジーにおいて、エッジノードでのＯＡＭ経路設定フレームを生成する処理の流れを示すフローチャートである。
【図１９】中継ノードにおいて保持するＯＡＭフレーム転送制御テーブルの構成例である。
【図２０】図１３の条件で、ＯＡＭフレームにＭＥＧＩＤを含まないフレームについて、転送経路を制限するためのテーブルである。
【図２１】ハンドスキャナの実施方法を示した説明図である。（実施例２）
【図２２】図１のネットワークを、イーサＯＡＭに対応しない装置のみで構成した場合の構成例を示す。
【図２３】イーサＯＡＭ機能を適用するネットワークの構成例として、光アクセスシステム（ＰＯＮ；Ｐａｓｓｉｖｅ  Ｏｐｔｉｃａｌ  Ｎｅｔｗｏｒｋ）を含む場合を示す。
【産業上の利用可能性】
【０１０３】
次世代ネットワーク（Ｎｅｘｔ  Ｇｅｎｅｒａｔｉｏｎ  Ｎｅｔｗｏｒｋ：ＮＧＮ）構想の足回りとして、また次世代インフラとしての信頼感、安心感を提供するためのインフラ構築製品として、イーサネット対応スイッチ、ＭＰＬＳスイッチなどのＬＡＮ、アクセス網、メトロ網構築向け通信装置に適用可能である。
【符号の説明】
【０１０４】
１  エッジノード
２  中継ノード
５  ＯＡＭ非対応中継ノード
１０、５４１、５５０  ＣＣデータベース
２０、７５０  転送制御テーブル
５０  ＯＡＭ非対応中継ノードでの転送制御テーブル
１２００  ＭＥＧＩＤ取得テーブル
２０００  ＯＡＭ非対応中継ノードを含む場合のＭＥＧＩＤ，ＶＩＤ取得テーブル
【図１】
0004777363.tif 000002
【図２】
0004777363.tif 000003
【図３】
0004777363.tif 000004
【図４】
0004777363.tif 000005
【図５】
0004777363.tif 000006
【図６】
0004777363.tif 000007
【図７】
0004777363.tif 000008
【図８】
0004777363.tif 000009
【図９】
0004777363.tif 000010
【図１０】
0004777363.tif 000011
【図１１】
0004777363.tif 000012
【図１２】
0004777363.tif 000013
【図１３】
0004777363.tif 000014
【図１４】
0004777363.tif 000015
【図１５】
0004777363.tif 000016
【図１６】
0004777363.tif 000017
【図１７】
0004777363.tif 000018
【図１８】
0004777363.tif 000019
【図１９】
0004777363.tif 000020
【図２０】
0004777363.tif 000021
【図２１】
0004777363.tif 000022
【図２２】
0004777363.tif 000023
【図２３】
0004777363.tif 000024