(57)【要約】【課題】装置内で必要となる転送帯域の変動を抑え、運用上の負荷を軽減可能なパケット通信装置を提供する。【解決手段】ＭＡＣ受信イーサ終端回路１１は多元的なイーサネット（Ｒ）を終端し、ＧＦＰカプセル化回路１３はＭＡＣフレームをＧＦＰフレームにカプセル化し、ＳＴＳマッパ回路１７は収容帯域に応じてＳＴＳ−１チャネルにＧＦＰフレームをマッピングし、ＯＣ−Ｎラインに転送する。ＳＴＳデマッパ回路１８はＯＣ−Ｎラインから受信したＳＴＳ−１チャネルを逆多重し、ＧＦＰフレームにデマッピングし、ＧＦＰデカプセル化回路１４はＧＦＰフレームを取出してＭＡＣフレームにデカプセル化し、ＭＡＣ送信イーサ生成回路１６は抽出したＭＡＣフレームを送信する。拡張回路１２，１５はＳｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ａｇｒｅｅｍｅｎｔ　支援とバーチャルＬＡＮの支援とを図る。【選択図】　　　図２
2004064574.tif 000002
【特許請求の範囲】
【請求項１】
入力パケットのヘッダ情報と入力物理ポート番号との組合せ情報を基に転送先を解決する際に、送信側の転送アクションを示すＤｔａｇ情報に一旦変換して装置内を持ち回ることを特徴とするパケット通信装置。
【請求項２】
ネットワーク内においてラベルを用いてパケット転送を行うパケット通信装置であって、
受信した主信号パケットのプロトコルを識別して当該プロトコルに対応したパケット転送及び廃棄処理のいずれかを決定するプロトコル識別手段と、前記プロトコル識別手段から転送されるパケットのヘッダ情報を基に当該パケットのフローを識別して転送経路と当該識別フローとに対する処理方法を示すＤｔａｇ情報を解決するフロー識別手段と、前記フロー識別手段の解決結果に応じて前記ラベルを収容するための装置内ヘッダを当該パケットの先頭位置に付与する装置内ヘッダ付与手段と、前記フロー識別手段の解決結果に応じて当該パケットの前記Ｄｔａｇ情報を収容する属性情報を生成して出力するパケット属性生成手段とを有することを特徴とするパケット通信装置。
【請求項３】
前記装置内ヘッダ付与手段は、前記フロー識別手段の解決結果に応じて受信パケットの前記ラベルを抜去した後に共通インタフェースとのアクセス制御を行うことを特徴とする請求項２記載のパケット通信装置。
【請求項４】
前記属性情報内に収容された前記Ｄｔａｇ情報に基づいて前記パケットの前記処理方法を特定するための装置内フロー識別子に変換するスケジューリング処理手段と、前記スケジューリング処理手段で変換された前記装置内フロー識別子に対応しかつ送信パケットに対するラベル化処理方法を決定する送信パケット処理判定手段と、前記送信パケット処理判定手段で決定された前記ラベル化処理方法にしたがって前記主信号パケットの読出し制御を行いかつ読出した主信号パケットに対してラベルの挿抜及びラベル変換処理を行って前記送信パケットの組立てを行う送信パケット組立手段とを含むこと特徴とする請求項２または請求項３記載のパケット通信装置。
【請求項５】
前記スケジューリング処理手段は、前記装置内フロー識別子毎に前記属性情報をキューイングするとともに、ピークレートと平均レートに基づくＤｕａｌ　Ｔｏｋｅｎ　Ｂｕｃｋｅｔ方式によるシェーピング及び優先スケジューリングを行うことを特徴とする請求項４記載のパケット通信装置。
【請求項６】
前記Ｄｔａｇ情報を複数の装置内フロー識別子に対応付けたことを特徴とする請求項４または請求項５記載のパケット通信装置。
【請求項７】
入力パケットのヘッダ情報と入力物理ポート番号との組合せ情報を基に転送先を解決する際に、送信側の転送アクションを示すＤｔａｇ情報に一旦変換して装置内を持ち回るようにしたことを特徴とするネットワーク拡張方法。
【請求項８】
ネットワーク内においてラベルを用いてパケット転送を行うパケット通信装置のネットワーク拡張方法であって、
受信した主信号パケットのプロトコルを識別して当該プロトコルに対応したパケット転送及び廃棄処理のいずれかを決定するステップと、前記パケット転送と決定された際にその転送されたパケットのヘッダ情報を基に当該パケットのフローを識別して転送経路と当該識別フローとに対する処理方法を示すＤｔａｇ情報を解決するステップと、この解決結果に応じて前記ラベルを収容するための装置内ヘッダをパケットの先頭位置に付与するステップと、前記解決結果に応じて当該パケットの前記Ｄｔａｇ情報を収容する属性情報を生成して出力するステップとを有することを特徴とするネットワーク拡張方法。
【請求項９】
前記装置内ヘッダをパケットの先頭位置に付与するステップは、前記解決結果に応じて受信パケットの前記ラベルを抜去した後に共通インタフェースとのアクセス制御を行うことを特徴とする請求項８記載のネットワーク拡張方法。
【請求項１０】
前記属性情報内に収容された前記Ｄｔａｇ情報に基づいて前記パケットの前記処理方法を特定するための装置内フロー識別子に変換するステップと、この変換された前記装置内フロー識別子に対応しかつ送信パケットに対するラベル化処理方法を決定するステップと、その決定された前記ラベル化処理方法にしたがって前記主信号パケットの読出し制御を行いかつ読出した主信号パケットに対してラベルの挿抜及びラベル変換処理を行って前記送信パケットの組立てを行うステップとを含むこと特徴とする請求項８または請求項９記載のネットワーク拡張方法。
【請求項１１】
前記装置内フロー識別子に変換するステップは、前記装置内フロー識別子毎に前記属性情報をキューイングするとともに、ピークレートと平均レートに基づくＤｕａｌ　Ｔｏｋｅｎ　Ｂｕｃｋｅｔ方式によるシェーピング及び優先スケジューリングを行うことを特徴とする請求項１０記載のネットワーク拡張方法。
【請求項１２】
前記Ｄｔａｇ情報を複数の装置内フロー識別子に対応付けたことを特徴とする請求項１０または請求項１１記載のネットワーク拡張方法。
【請求項１３】
ネットワーク内においてラベルを用いてパケット転送を行うパケット通信装置のネットワーク拡張方法のプログラムであって、コンピュータに、受信した主信号パケットのプロトコルを識別して当該プロトコルに対応したパケット転送及び廃棄処理のいずれかを決定する処理と、前記パケット転送と決定された際にその転送されたパケットのヘッダ情報を基に当該パケットのフローを識別して転送経路と当該識別フローとに対する処理方法を示すＤｔａｇ情報を解決する処理と、この解決結果に応じて前記ラベルを収容するための装置内ヘッダをパケットの先頭位置に付与する処理と、前記解決結果に応じて当該パケットの前記Ｄｔａｇ情報を収容する属性情報を生成して出力する処理とを実行させるためのプログラム。
【請求項１４】
前記コンピュータに、前記属性情報内に収容された前記Ｄｔａｇ情報に基づいて前記パケットの前記処理方法を特定するための装置内フロー識別子に変換する処理と、この変換された前記装置内フロー識別子に対応しかつ送信パケットに対するラベル化処理方法を決定する処理と、その決定された前記ラベル化処理方法にしたがって前記主信号パケットの読出し制御を行いかつ読出した主信号パケットに対してラベルの挿抜及びラベル変換処理を行って前記送信パケットの組立てを行う処理とを実行させること特徴とする請求項１３記載のプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はパケット通信装置及びそれに用いるネットワーク拡張方法並びにそのプログラムに関し、特にメトロネットワーク内を安価なイーサネット（Ｒ）で構築するネットワーク構築方法に関する。
【０００２】
【従来の技術】
近年、ネットワークを構築する技術としては、メトロネットワーク内を安価なイーサネット（Ｒ）で構築する技術が主流となっている。イーサネット（Ｒ）の速度データレートはフレームリレーやＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ　Ｔｒａｎｓｆｅｒ　Ｍｏｄｅ：非同期通信モード）のような他の広帯域ネットワークのインタフェース速度を追越しており、また妥当なコストでスケールする利点を活かして、既存のＳＯＮＥＴ（Ｓｙｎｃｈｒｏｎｏｕｓ　Ｏｐｔｉｃａｌ　ＮＥＴｗｏｒｋ）相場に置換わり、メトロネットワークへの導入が加速している。
【０００３】
例えば、イーサネット（Ｒ）ベースの技術は２００３年までに、世界のネットワーク接続機器の９８パーセント以上を占めるだろうと想定されている。このイーサネット（Ｒ）ベースの技術はインプリメントが単純であるため、ＡＴＭ、トークンリング及びＦＤＤＩ（Ｆｉｂｅｒ　Ｄｉｓｔｒｉｂｕｔｅｄ　Ｄａｔａ　Ｉｎｔｅｒｆａｃｅ）のような競合ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）技術に打ち勝っており、かつスタッフトレーニングを必要とせず、コスト効率に優れている。
【０００４】
メトロオプティカルイーサネット（Ｒ）の将来のインプリメンテーションを支援するために必要となるＤｏＳ（Ｄａｔａ　ｏｖｅｒ　ＳＯＮＥＴ）技術に関しては、ＩＴＵ−Ｔ，　Ｔ１Ｘ１．５等にて標準化が進んでいる。これによって、ＬＡＮ−ＷＡＮ（Ｗｉｄｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）間のインタフェース速度のミスマッチ問題を克服したＶＣ（　Ｖｉｒｔｕａｌ　Ｃｏｎｃａｔｅｎａｔｉｏｎ）技術と、従来の方式と比べて高い同期特性を持つＧＦＰ（Ｇｅｎｅｒｉｃ　Ｆｒａｍｉｎｇ　Ｐｒｏｃｅｄｕｒｅ）技術とが現実解として受け入れられている。
【０００５】
従来のＤｏＳネットワークモデルを図１０に示す。図１０において、ノード（ＳＯＮＥＴ　ＮＥ）５１，５２は多元的なイーサネット（Ｒ）｛ＦＥ［１００Ｍｂｐｓ　Ｆａｓｔ　Ｅｔｈｅｒｎｅｔ（Ｒ）］，ＧＥ［１Ｇｂｐｓ　Ｅｔｈｅｒｎｅｔ（Ｒ）］，ＥｏＭＰＬＳ［Ｅｔｈｅｒｎｅｔ（Ｒ）　ｏｖｅｒ　Ｍｕｌｔｉ　Ｐｒｏｔｏｃｏｌ　Ｌａｂｅｌ　Ｓｗｉｔｃｈｉｎｇ］｝を適切な回線速度で収容する。
【０００６】
ノード５１はＶＣ生成用のノードであり、多種イーサネット（Ｒ）（ＦＥ／ＧＥ／１０ＧＥ）をＶＣ−３−Ｎｖにマッピングし、中継フレームとしてＧＦＰを採用している。ノード５２はＶＣ終端点用のノードであり、逆多重手法によってデマッピングを行い、ＧＦＰのＨＥＣ（Ｈｅａｄｅｒ　Ｅｒｒｏｒ　Ｃｏｎｔｒｏｌ）演算による同期方式がとられている。ノード（ＮＥ）６１，６２は中継ノードであり、多種イーサネット（Ｒ）がマッピングされたパケットにおいてＶＣを意識せず、ＶＣ−３（ＶＣ−４）パスとして処理する。
【０００７】
上記のノード５１，５２，６１，６２のイーサネット（Ｒ）回線収容部はＭＡＣ　（Ｍｅｄｉａ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）受信イーサ終端回路と、ＧＦＰカプセル化回路と、ＳＴＳ（Ｓｙｎｃｈｒｏｎｏｕｓ　ＴｒａｎｓｐｏｒｔＳｉｇｎａｌ）マッパ回路とからなるＩｎｂｏｕｎｄ側と、ＳＴＳデマッパ回路と、ＧＦＰデカプセル化回路と、ＭＡＣ送信イーサ生成回路とからなるｏｕｔｂｏｕｎｄ側とによって構成されている。
【０００８】
イーサネット（Ｒ）回線収容部のＩｎｂｏｕｎｄ側では、ＭＡＣ受信イーサ終端回路で多元的なイーサネット（Ｒ）を終端し、ＧＦＰカプセル化回路でＭＡＣフレームをＧＦＰフレームにカプセル化し（図１１参照）、ＳＴＳマッパ回路で収容帯域に応じてＳＴＳ−１（約５０Ｍｂｐｓ）単位でＳＴＳ−１チャネルにＧＦＰフレームをマッピングした後、ＯＣ−Ｎ（Ｏｐｔｉｃａｌ　Ｃａｒｒｉｅｒ−Ｎ）ラインに転送する。
【０００９】
ここで、イーサネット（Ｒ）のフォーマットは、図１１に示すように、Ｉｎｔｅｒ　Ｆｒａｍｅ　Ｇａｐと、Ｐｒｅａｍｂｌｅと、ＳＦＤ（スタートフレームデリミタ）と、ＤＡ（宛先アドレス）と、ＳＡ（送信元アドレス）と、ＬＥＮ（長さ）と、Ｐａｙｌｏａｄと、ＦＣＳ（フレームチェックシーケンス）とからなる。
【００１０】
また、ＧＦＰフレームのフォーマットは、ＰＬＩ及びｃＨＥＣからなるＣｏｒｅ　Ｈｅａｄｅｒと、Ｔｙｐｅ及びｔＨＥＣからなるＰａｙｌｏａｄ　Ｈｅａｄｅｒと、Ｐａｙｌｏａｄとからなり、Ｐａｙｌｏａｄにイーサネット（Ｒ）のＤＡと、ＳＡと、ＬＥＮと、Ｐａｙｌｏａｄと、ＦＣＳとがカプセル化される。
【００１１】
イーサネット（Ｒ）回線収容部のｏｕｔｂｏｕｎｄ側は、ＳＴＳデマッパ回路でＯＣ−Ｎラインから受信したＳＴＳ−１チャネルを逆多重し、ＧＦＰフレームにデマッピングし、ＧＦＰデカプセル化回路でＧＦＰフレーム同期をとり、ＧＦＰフレームを取出した後、ＭＡＣフレームにデカプセル化する機能を有し、さらに抽出したＭＡＣフレームをＭＡＣ送信イーサ生成回路から送信する。
【００１２】
一方、ＥｏＭＰＬＳドメイン内に転送されるパケットはＭＰＬＳパケットだけとは限らず、▲１▼ＭＰＬＳ［非ＶＰＮ（Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）：ｎ段ラベル付の］パケット、▲２▼ＭＰＬＳ（ＶＰＮ：ｎ段ラベル付の）パケット、▲３▼非ＭＰＬＳ［通常のイーサネット（Ｒ）］パケットだが特別にフローの管理を行うもの、▲４▼非ＭＰＬＳ［通常のイーサネット（Ｒ）］パケットで特別な管理を行わないものの４種類があり、これらは同一の物理ポートに混在する場合がある。
【００１３】
【発明が解決しようとする課題】
従来の装置では、イーサネット（Ｒ）転送系のみに特化しており、上記の▲３▼，▲４▼のみの転送が可能であり、▲１▼，▲２▼のＭＰＬＳラベル化パケット転送手段を持たない。また、通常のイーサネット（Ｒ）パケットについては、半固定的で時分割多重クロスコネクトするためだけのテーブルしか有しておらず、▲１▼，▲２▼のＭＰＬＳラベル化パケット転送に対応するために、別カードを配備し、宛先検索を行った後、スイッチ経由で宛先カードに転送する方式では、無駄にスイッチ帯域を浪費する問題がある。
【００１４】
そこで、本発明の目的は上記の問題点を解消し、装置内で必要となる転送帯域の変動を抑えることができ、運用上の負荷を軽減することができるパケット通信装置及びそれに用いるネットワーク拡張方法並びにそのプログラムを提供することにある。
【００１５】
【課題を解決するための手段】
本発明によるパケット通信装置は、入力パケットのヘッダ情報と入力物理ポート番号との組合せ情報を基に転送先を解決する際に、送信側の転送アクションを示すＤｔａｇ情報に一旦変換して装置内を持ち回っている。
【００１６】
本発明による他のパケット通信装置は、ネットワーク内においてラベルを用いてパケット転送を行うパケット通信装置であって、
受信した主信号パケットのプロトコルを識別して当該プロトコルに対応したパケット転送及び廃棄処理のいずれかを決定するプロトコル識別手段と、前記プロトコル識別手段から転送されるパケットのヘッダ情報を基に当該パケットのフローを識別して転送経路と当該識別フローとに対する処理方法を示すＤｔａｇ情報を解決するフロー識別手段と、前記フロー識別手段の解決結果に応じて前記ラベルを収容するための装置内ヘッダを当該パケットの先頭位置に付与する装置内ヘッダ付与手段と、前記フロー識別手段の解決結果に応じて当該パケットの前記Ｄｔａｇ情報を収容する属性情報を生成して出力するパケット属性生成手段とを備えている。
【００１７】
本発明による別のパケット通信装置は、上記の構成のほかに、前記属性情報内に収容された前記Ｄｔａｇ情報に基づいて前記パケットの前記処理方法を特定するための装置内フロー識別子に変換するスケジューリング処理手段と、前記スケジューリング処理手段で変換された前記装置内フロー識別子に対応しかつ送信パケットに対するラベル化処理方法を決定する送信パケット処理判定手段と、前記送信パケット処理判定手段で決定された前記ラベル化処理方法にしたがって前記主信号パケットの読出し制御を行いかつ読出した主信号パケットに対してラベルの挿抜及びラベル変換処理を行って前記送信パケットの組立てを行う送信パケット組立手段とを具備している。
【００１８】
本発明によるネットワーク拡張方法は、入力パケットのヘッダ情報と入力物理ポート番号との組合せ情報を基に転送先を解決する際に、送信側の転送アクションを示すＤｔａｇ情報に一旦変換して装置内を持ち回るようにしている。
【００１９】
本発明による他のネットワーク拡張方法は、ネットワーク内においてラベルを用いてパケット転送を行うパケット通信装置のネットワーク拡張方法であって、受信した主信号パケットのプロトコルを識別して当該プロトコルに対応したパケット転送及び廃棄処理のいずれかを決定するステップと、前記パケット転送と決定された際にその転送されたパケットのヘッダ情報を基に当該パケットのフローを識別して転送経路と当該識別フローとに対する処理方法を示すＤｔａｇ情報を解決するステップと、この解決結果に応じて前記ラベルを収容するための装置内ヘッダをパケットの先頭位置に付与するステップと、前記解決結果に応じて当該パケットの前記Ｄｔａｇ情報を収容する属性情報を生成して出力するステップとを備えている。
【００２０】
本発明による別のネットワーク拡張方法は、上記のステップのほかに、前記属性情報内に収容された前記Ｄｔａｇ情報に基づいて前記パケットの前記処理方法を特定するための装置内フロー識別子に変換するステップと、この変換された前記装置内フロー識別子に対応しかつ送信パケットに対するラベル化処理方法を決定するステップと、その決定された前記ラベル化処理方法にしたがって前記主信号パケットの読出し制御を行いかつ読出した主信号パケットに対してラベルの挿抜及びラベル変換処理を行って前記送信パケットの組立てを行うステップとを具備している。
【００２１】
本発明によるネットワーク拡張方法のプログラムは、ネットワーク内においてラベルを用いてパケット転送を行うパケット通信装置のネットワーク拡張方法のプログラムであって、コンピュータに、受信した主信号パケットのプロトコルを識別して当該プロトコルに対応したパケット転送及び廃棄処理のいずれかを決定する処理と、前記パケット転送と決定された際にその転送されたパケットのヘッダ情報を基に当該パケットのフローを識別して転送経路と当該識別フローとに対する処理方法を示すＤｔａｇ情報を解決する処理と、この解決結果に応じて前記ラベルを収容するための装置内ヘッダをパケットの先頭位置に付与する処理と、前記解決結果に応じて当該パケットの前記Ｄｔａｇ情報を収容する属性情報を生成して出力する処理とを実行させている。
【００２２】
本発明による他のネットワーク拡張方法のプログラムは、上記の処理のほかに、前記コンピュータに、前記属性情報内に収容された前記Ｄｔａｇ情報に基づいて前記パケットの前記処理方法を特定するための装置内フロー識別子に変換する処理と、この変換された前記装置内フロー識別子に対応しかつ送信パケットに対するラベル化処理方法を決定する処理と、その決定された前記ラベル化処理方法にしたがって前記主信号パケットの読出し制御を行いかつ読出した主信号パケットに対してラベルの挿抜及びラベル変換処理を行って前記送信パケットの組立てを行う処理とを実行させている。
【００２３】
すなわち、本発明のパケット通信装置は、既存のネットワークインフラストラクチャ上で多元的なイーサネット（Ｒ）パケットのデータ転送を可能にし、低コストで先行投資に対する収益を最大限に活用するネットワークへ拡張する方式を実現するものである。拡張に際しては補足設備やオーバレイネットワークが要求されず、トランスポート帯域を効率よく共有することで、高価なファイバプラントを加えず、かつ汎用性に優れた通信装置を提供する。
【００２４】
つまり、本発明のパケット通信装置では、Ｉｎｂｏｕｎｄ側（パケット受信側）のインタフェースカードにおいて、受信したパケットがＥｏＭＰＬＳ［Ｅｔｈｅｒｎｅｔ（Ｒ）　ｏｖｅｒ　Ｍｕｌｔｉ　Ｐｒｏｔｏｃｏｌ　Ｌａｂｅｌ　Ｓｗｉｔｃｈｉｎｇ］に代表されるスペシャルパケットであると判断した場合、以下のようなパケットハンドリングを実施する手段を有している。
【００２５】
本発明のパケット通信装置では、入力パケットのヘッダ情報と入力物理ポート番号との組合わせ情報を基に転送先を解決する際に、送信側の転送アクション（転送経路と識別フローとに対する処理方法）を示すＤｔａｇ情報を入力パケットの先頭部分に付与し、入力パケットをそのＤｔａｇ情報で装置内を持ち回ることによって、汎用的なパケットスイッチ機構のみを有しているスイッチ処理部を改版することなく、上記の通信装置を実現することが可能である。このため、本発明のパケット通信装置では、装置コストを下げ、ＭＰＬＳ（Ｍｕｌｔｉ　Ｐｒｏｔｏｃｏｌ　Ｌａｂｅｌ　Ｓｗｉｔｃｈｉｎｇ）網の収容（　まきとり）が容易に実現可能となる。
【００２６】
また、本発明のパケット通信装置では、入力パケットの装置内転送において、出力ラベルを持ち回る必要がなく、装置内における転送オーバヘッドが固定長でよくなるため、装置内で必要となる転送帯域の変動を抑えることが可能となり、運用上の負荷を軽減することが可能となる。
【００２７】
一方、本発明のパケット通信装置では、Ｏｕｔｂｏｕｎｄ側（パケット送信側）のインタフェースカードにおいて、Ｏｂｊｅｃｔに含まれるＤｔａｇ情報でフロー（Ｆｌｏｗ）識別し、パケット転送のシェーピング（Ｓｈａｐｉｎｇ）（回線の伝送速度にあわせて送出するパケットを調整すること）／スケジューリング（Ｓｃｈｅｄｕｌｉｎｇ）を実行し、Ｄｔａｇ情報を装置内における動作規定ポインタとして、転送アクションを決定する手段を有している。
【００２８】
これによって、本発明のパケット通信装置では、多元的なプロトコルタイプが混在した運用形態においても、装置内においてＤｔａｇ情報のみの一元管理で当該パケットの処理アクションが決定付けられるため、装置トータルでの管理が簡素化され、出力処理が容易となる。マルチキャスト（Ｍｕｌｔｉｃａｓｔ）転送等の付加的サービスを実現する場合においても、既存のアーキテクチャの延長で転送処理が実現可能である。
【００２９】
上述したような構成及び動作をとることで、本発明は、オプティカルイーサネット（Ｒ）によってＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）対ＬＡＮのメトロ接続を可能とし、ＬＡＮ側のインタフェース速度にマッチさせるべく、１００Ｍｂｐｓ間隔で、１００Ｍｂｐｓから１０Ｇｂｐｓまでに及ぶ実行レートで収容設計、高速転送が可能となる。
【００３０】
また、本発明は、統合イーサネット（Ｒ）及びＤＷＤＭ（Ｄｅｎｓｅ　Ｗａｖｅｌｅｎｇｔｈ　Ｄｉｖｉｓｉｏｎ　Ｍｕｌｔｉｐｌｅｘｉｎｇ）技術を使用する１０Ｇｂｐｓあるいは１００Ｇｂｐｓクラス転送レートで高機能メトロコア接続を実現している。
【００３１】
ＭＰＬＳ（Ｍｕｌｔｉ　Ｐｒｏｔｏｃｏｌ　Ｌａｂｅｌ　Ｓｗｉｔｃｈｉｎｇ）に基づくサービスは、メトロネットワークをトランスペアレントさせ、トランスポート上のフローを保証しつつ、従来のＳＯＮＥＴ（ＳｙｎｃｈｒｏｎｏｕｓＯｐｔｉｃａｌ　ＮＥＴｗｏｒｋ）　ＲＩＮＧネットワークインフラストラクチュアに対する代案としている。
【００３２】
本発明の特徴は、サービス柔軟性、サービス区別及び収入増強、帯域幅再使用、パケット粒状を備えた帯域幅管理、ハイブリッドネットワーク要素、スケーラビリティへの解決策、廉価な在来のＬＡＮインタフェースのまきとり収容、Ｓｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ａｇｒｅｅｍｅｎｔ支援、バーチャルＬＡＮの支援のための手段を有する点にある。
【００３３】
【発明の実施の形態】
次に、本発明の一実施例について図面を参照して説明する。図１は本発明の一実施例によるパケット通信装置の構成を示すブロック図である。図１において、本発明の一実施例によるパケット通信装置は多元的なイーサネット（Ｒ）回線を収容し、主信号入出力部を有するイーサネット（Ｒ）回線収容部１−１〜１−ｎと、収容回線に応じてＮ×ＳＴＳ（Ｓｙｎｃｈｒｏｎｏｕｓ　Ｔｒａｎｓｐｏｒｔ　Ｓｉｇｎａｌ）−１単位にクロスコネクト可能でかつラベルスイッチ２ａを持つクロスコネクト部２と、多様な制御プロトコルを終端し、複数のイーサネット（Ｒ）回線収容部１−１〜１−ｎとクロスコネクト部２とに設定情報を設定し、監視項目を収集する機能を有する監視制御部３と、ＳＯＮＥＴ（Ｓｙｎｃｈｒｏｎｏｕｓ　Ｏｐｔｉｃａｌ　ＮＥＴｗｏｒｋ）回線収容部４−１〜４−ｎから構成されている。
【００３４】
図２は図１のイーサネット（Ｒ）回線収容部１−１〜１−ｎの要部構成を示すブロック図である。図２においてはイーサネット（Ｒ）回線収容部１−１〜１−ｎをイーサネット（Ｒ）回線収容部１として図示している。
【００３５】
図２において、イーサネット（Ｒ）回線収容部１はＭＡＣ（Ｍｅｄｉａ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）受信イーサ終端回路１１と、ＧＦＰ（Ｇｅｎｅｒｉｃ　Ｆｒａｍｉｎｇ　Ｐｒｏｃｅｄｕｒｅ）カプセル化回路１３と、ＳＴＳマッパ回路１７とからなるＩｎｂｏｕｎｄ側（パケット受信側）と、ＳＴＳデマッパ回路１８と、ＧＦＰデカプセル化回路１４と、ＭＡＣ送信イーサ生成回路１６とからなるＯｕｔｂｏｕｎｄ側（パケット送信側）と、拡張回路（＃１，＃２）１２，１５と、オンボードＣＰＵ（中央処理装置）１９と、記録媒体２０とによって構成されている。
【００３６】
イーサネット（Ｒ）回線収容部１のＩｎｂｏｕｎｄ側では、ＭＡＣ受信イーサ終端回路１１で多元的なイーサネット（Ｒ）を終端し、ＧＦＰカプセル化回路１３でＭＡＣフレームをＧＦＰフレームにカプセル化し（　図９参照）　、ＳＴＳマッパ回路１７で収容帯域に応じてＳＴＳ−１（約５０Ｍｂｐｓ）単位でＳＴＳ−１チャネルにＧＦＰフレームをマッピングした後、ＯＣ（Ｏｐｔｉｃａｌ　Ｃａｒｒｉｅｒ）−Ｎラインに転送する。
【００３７】
尚、ＳＴＳマッパ回路１７でマッピングされたＧＦＰフレームは、実際には、上記のクロスコネクト部２のラベルスイッチ２ａを通してＳＯＮＥＴ回線収容部４−１〜４−ｎへと送出され、ＳＯＮＥＴ回線収容部４−１〜４−ｎからＯＣ−Ｎラインへと転送される。
【００３８】
イーサネット（Ｒ）回線収容部１のＯｕｔｂｏｕｎｄ側では、ＳＴＳデマッパ回路１８でＯＣ−Ｎライン（クロスコネクト部２）から受信したＳＴＳ−１チャネルを逆多重し、ＧＦＰフレームにデマッピングし、ＧＦＰデカプセル化回路１４でＧＦＰフレーム同期をとり、ＧＦＰフレームを取出した後、ＭＡＣフレームにデカプセル化し、その抽出されたＭＡＣフレームがＭＡＣ送信イーサ生成回路１６から送信される。
【００３９】
上述したイーサネット（Ｒ）回線収容部１のＩｎｂｏｕｎｄ側とＯｕｔｂｏｕｎｄ側とによって、ＬＡＮ対ＬＡＮのメトロ接続が可能となるが、本発明ではＳｅｒｖｉｃｅ　Ｌｅｖｅｌ　Ａｇｒｅｅｍｅｎｔ　支援とバーチャルＬＡＮの支援とを図る拡張回路（＃１，＃２）１２，１５をａｄｄ−ｏｎしている。尚、上述したイーサネット（Ｒ）回線収容部１の処理は図示せぬコンピュータが記録媒体２０に格納されたプログラムを実行することでも実現される。
【００４０】
図３は本発明の一実施例によるネットワークアプリケーションモデルを示す図である。図３において、本発明の一実施例によるネットワークアプリケーションモデルは、ＥｏＭＰＬＳ［Ｅｔｈｅｒｎｅｔ（Ｒ）　ｏｖｅｒ　Ｍｕｌｔｉ　Ｐｒｏｔｏｃｏｌ　Ｌａｂｅｌ　Ｓｗｉｔｃｈｉｎｇ］クライアントを収容可能としており、この点が本発明の一実施例によるネットワークアプリケーションモデルと図１１に示す従来のネットワークモデルとの違いである。
【００４１】
図３に示すＥｏＭＰＬＳドメイン内に転送されるパケットはＭＰＬＳ（Ｍｕｌｔｉ　Ｐｒｏｔｏｃｏｌ　Ｌａｂｅｌ　Ｓｗｉｔｃｈｉｎｇ）パケットだけとは限らず、本発明におけるパケットとしては、▲１▼ＭＰＬＳ［非ＶＰＮ（Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）：ｎ段ラベル付の］パケット、▲２▼ＭＰＬＳ（ＶＰＮ：ｎ段ラベル付の）パケット、▲３▼非ＭＰＬＳ［通常のイーサネット（Ｒ）］パケットだが特別にフローの管理を行うもの、▲４▼非ＭＰＬＳ［通常のイーサネット（Ｒ）］パケットで特別な管理を行わないものの４種類があり、これらは同一の物理ポートに混在する場合がある。
【００４２】
従来の通信装置では、イーサネット（Ｒ）転送系のみに特化しており、上記の▲３▼，▲４▼のみの転送が可能であり、▲１▼，▲２▼のＭＰＬＳラベル化パケット転送手段を持たない。また、通常のイーサネット（Ｒ）パケットについては、半固定的で時分割多重クロスコネクトするためだけのテーブルしか有しておらず、▲１▼，▲２▼のＭＰＬＳラベル化パケット転送に対応するために、別カードを配備し、宛先検索を行った後、スイッチ経由で宛先カードに転送する方式では、無駄にスイッチ帯域を浪費するという問題がある。
【００４３】
ここで、ＭＰＬＳラベル化パケット転送ではＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）アドレスとラベルと呼ぶ下位レイヤの情報とを対応付け、ラベルだけ参照してパケットを転送する方法であり、ラベルはＩＰアドレスへのパケット転送先をＭＰＬＳ網上で識別するためのデータである。
【００４４】
すなわち、図３において、ノード（ＳＯＮＥＴ　ＮＥ）５１，５２は多元的なイーサネット（Ｒ）｛ＦＥ［１００Ｍｂｐｓ　Ｆａｓｔ　Ｅｔｈｅｒｎｅｔ（Ｒ）］，ＧＥ［１Ｇｂｐｓ　Ｅｔｈｅｒｎｅｔ（Ｒ）］，ＥｏＭＰＬＳ［Ｅｔｈｅｒｎｅｔ（Ｒ）　ｏｖｅｒ　Ｍｕｌｔｉ　Ｐｒｏｔｏｃｏｌ　Ｌａｂｅｌ　Ｓｗｉｔｃｈｉｎｇ］｝を適切な回線速度で収容する。
【００４５】
ノード５１はＶＣ生成用のノードであり、多種イーサネット（Ｒ）（ＦＥ／ＧＥ／１０ＧＥ）をＶＣ−３−Ｎｖにマッピングし、中継フレームとしてＧＦＰを採用している。ノード５２はＶＣ終端点用のノードであり、逆多重手法によってデマッピングを行い、ＧＦＰのＨＥＣ（Ｈｅａｄｅｒ　Ｅｒｒｏｒ　Ｃｏｎｔｒｏｌ）演算による同期方式がとられている。ノード（ＮＥ）６１，６２は中継ノードであり、多種イーサネット（Ｒ）がマッピングされたパケットにおいてＶＣを意識せず、ＶＣ−３（ＶＣ−４）パスとして処理する。
【００４６】
ノード５１は受信したイーサネット（Ｒ）パケットのＭＡＣフレームにラベル（Ｌａｂｅｌ＃１）を付与（Ｌａｂｅｌ　Ｐｕｓｈ）したＧＦＰフレームをノード６１に送信する。ノード６１はＧＦＰフレームのラベル（Ｌａｂｅｌ＃１）を基にノード６２へと転送し、ノード６２はＧＦＰフレームのラベル（Ｌａｂｅｌ＃２）を基にノード５２へと転送する。ノード５２は受信したＧＦＰフレームのラベル（Ｌａｂｅｌ＃３）を除去してＭＡＣフレームを抽出し、この抽出したＭＡＣフレームを外部へと送信する。
【００４７】
この場合、ノード６１ではラベル（Ｌａｂｅｌ＃１）がラベル（Ｌａｂｅｌ＃２）に置換えられ（Ｌａｂｅｌ　Ｓｗａｐ）、ノード６２ではラベル（Ｌａｂｅｌ＃２）がラベル（Ｌａｂｅｌ＃３）に置換えられる（Ｌａｂｅｌ　Ｓｗａｐ）。
【００４８】
本実施例では上記の課題を解決するために、図２に示すように、拡張回路（＃１，＃２）１２，１５を配設することで、ＥｏＭＰＬＳにてラベル化されたパケットについてもハンドリングが可能となる。
【００４９】
図４は図２のイーサネット（Ｒ）回線収容部１のＩｎｂｏｕｎｄ側の詳細な構成を示すブロック図であり、図５は図２のイーサネット（Ｒ）回線収容部１のＯｕｔｂｏｕｎｄ側の詳細な構成を示すブロック図である。これら図４及び図５を参照して拡張回路（＃１）１２及び拡張回路（＃２）１５の構成についてそれぞれ説明する。
【００５０】
図４において、ＭＡＣ受信イーサ終端回路１１はプロトコル識別部１１ａを備え、拡張回路（＃１）１２はフロー識別／経路解決部１２ａ及びＣｌａｓｓｆｉｅｒテーブル（Ｔａｂｌｅ）１２ｂを備え、ＧＦＰカプセル化回路１３は装置内ヘッダ付与部１３ａ及びパケット属性生成部１３ｂを備えている。
【００５１】
プロトコル識別部１１ａはリンクフェーズとプロトコルタイプとに対応したパケット転送、あるいは廃棄処理を決定するための機能を有している。フロー識別／経路解決部１２ａはプロトコル識別部１１ａによって転送されたパケットヘッダから、当該パケットのフロー（特定のヘッダ情報を共有しており、同じルーティング処理を受ける単方向のパケットが複数まとまったもの）（　あるいはラベル）　を識別し、転送経路と当該識別フロー（　あるいは識別ラベル）　とに応じた処理方法（Ｄｔａｇ情報）　を、テーブル（Ｃｌａｓｓｆｉｅｒテーブル１２ｂ）を参照することによって解決し、装置内ヘッダ付与部１３ａ及びパケット属性生成部１３ｂに対して指示する機能を有する。
【００５２】
ここで、Ｃｌａｓｓｆｉｅｒテーブル１２ｂはヘッダ情報とＤｔａｇ情報とが対応付けられて格納されている。また、フロー識別／経路解決部１２ａから装置内ヘッダ付与部１３ａ及びパケット属性生成部１３ｂには指示内容として、Ｄｔａｇ，Ａｃｔｉｏｎ，ＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ），Ｒｏｕｔｅ，・・・が送出される。
【００５３】
装置内ヘッダ付与部１３ａはフロー識別／経路解決部１２ａの指示によってラベルを収容するための装置内ヘッダをパケットの先頭位置に付与し、パケット属性生成部１３ｂはフロー識別／経路解決部１２ａの指示内容によって、Ｄｔａｇ情報を収容した当該パケットの属性情報を生成する。
【００５４】
図５において、拡張回路（＃２）１５はパケットスケジューリング処理部１５ａ及びＦｌｏｗテーブル（Ｔａｂｌｅ）１５ｂを備え、ＭＡＣ送信イーサ生成回路１６は送信パケット処理判定部１６ａと送信パケット組立及び送信パケット多重部１６ｂとＡｃｔｉｏｎテーブル（Ｔａｂｌｅ）１６ｃとを備えている。
【００５５】
パケットスケジューリング処理部１５ａは受信したパケット属性情報内に収容されたＤｔａｇ情報を基にＦｌｏｗテーブル１５ｂを参照して当該パケットの装置内フロー識別子（Ｆｌｏｗ　ＩＤ）を解決し、その装置内フロー識別子毎にパケット属性情報をキューイング（　メモリに格納）　するとともに、ピークレートと平均レートとに基づくＤｕａｌ　Ｔｏｋｅｎ　Ｂｕｃｋｅｔ方式によるシェーピング（Ｓｈａｐｉｎｇ）及び優先スケジューリング（ｓｃｈｅｄｕｌｉｎｇ）（によるメモリ読出し）を行う。
【００５６】
ここで、Ｆｌｏｗテーブル１５ｂはＤｔａｇ情報をアドレスとして、装置内フロー識別子を管理するテーブル構成であり、装置内フロー識別子を複数のリンクポインタにて繋ぐ構成にすることによって、１つのＤｔａｇ情報が複数の回線ポートに対するフロー処理を割当てることも可能となり、一対多（　マルチキャスト）　転送にも対応することができる。
【００５７】
すなわち、Ｄｔａｇ情報を装置内フロー識別子と１対Ｎ（Ｎは正の整数）に対応付けることで、１つのＤｔａｇ情報によってＦｌｏｗテーブル１５ｂからＮ個の装置内フロー識別子が読出され、Ｎ個の装置内フロー識別子各々に対応する回線ポートに対するフロー処理を割当てることができる。
【００５８】
送信パケット処理判定部１６ａはパケットスケジューリング処理部１５ａから受信したパケット属性情報内に収容される装置内フロー識別子を基にＡｃｔｉｏｎテーブル１６ｃを参照し、送信パケットに対するラベル化処理方法（Ａｃｔｉｏｎ）を決定する。ここで、Ａｃｔｉｏｎテーブル１６ｃは装置内フロー識別子をアドレスとして、パケットヘッダ処理を設定するＬａｂｅｌ　Ａｃｔｉｏｎ　Ｅｎｔｒｙを有するメモリである。Ｌａｂｅｌ　Ａｃｔｉｏｎ　Ｅｎｔｒｙはパケットスケジューリング処理部１５ａからのｏｂｊｅｃｔに含まれる装置内フロー識別子毎に管理されている。
【００５９】
送信パケット組立及び送信パケット多重部１６ｂは送信パケット処理判定部１６ａが決定したラベル化処理方法にしたがってＳＴＳデマッパ回路１８でワード逆多重された主信号パケットの読出し制御を行い、さらに読出した主信号パケットに対してラベルの挿抜またはラベル変換処理を行った後、送信パケット組立てを行い、その送信パケットを送信する。
【００６０】
図６及び図７は図２のイーサネット（Ｒ）回線収容部１の基本処理を示すフローチャートであり、図８は図２のイーサネット（Ｒ）回線収容部１のＩｎｇｒｅｓｓ処理の流れを示す図であり、図９は図２のイーサネット（Ｒ）回線収容部１のＥｇｒｅｓｓ処理の流れを示す図である。これら図２と図４〜図９とを参照してイーサネット　（Ｒ）回線収容部１の基本処理について説明する。
【００６１】
尚、図６はイーサネット（Ｒ）回線収容部１のＩｎｂｏｕｎｄ側の処理を示し、図７はイーサネット（Ｒ）回線収容部１のＯｕｔｂｏｕｎｄ側の処理を示している。また、図６〜図９に示す処理はイーサネット（Ｒ）回線収容部１のコンピュータが記録媒体２０のプログラムを実行することでも実現される。
【００６２】
プロトコル識別部１１ａは受信したパケットヘッダのプロトコルＩＤを参照して制御パケットであるか、主信号パケットであるかを識別する（プロトコル判定、制御パケットの分離）（図６ステップＳ１）。プロトコル識別部１１ａはこの識別処理において主信号パケットであると識別すると、そのパケットヘッダをフロー識別／経路解決部１２ａに送出し、制御パケットであると識別すると、ボード上に実装されるオンボードＣＰＵ１９によってリンク確立等の処理が実施される。ここで、主信号パケットとは、通常のイーサネット（Ｒ）パケット及びイーサネット（Ｒ）バーＭＰＬＳパケットが該当する。
【００６３】
フロー識別／経路解決部１２ａはプロトコル識別部１１ａからパケットヘッダを受信すると、上述したパケットヘッダ内の複数フィールドの任意組合せを検索キーとして、Ｃｌａｓｓｉｆｉｅｒテーブル１２ｂの検索処理を行う（図６ステップＳ２）。
【００６４】
このＭｕｌｔｉ−Ｆｉｅｌｄ検索の結果、ＦＥＣ　ＩＤ（Ｆｏｒｗａｒｄｉｎｇ　Ｅｑｕｉｖａｌｅｎｔ　Ｃｌａｓｓ　Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ：転送先経路を決定する識別子）、ＰＬＣ　ＩＤ（Ｐｏｌｉｃｉｎｇ　Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ：ポリシング対象となるフローを決定する識別子）、ＣＬＳ　ＩＤ［Ｃｌａｓｓ　Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ：転送ＱｏＳ（Ｑｕａｌｉｔｙｏｆ　Ｓｅｒｖｉｃｅ）クラスを決定する識別子］、ＳＴＡＴ　ＩＤ（Ｓｔａｔｉｓｔｉｃ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｃｏｕｎｔｅｒ　Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ：統計情報のカウント単位を規定する識別子）、ＰＣＯＬＯＲ（Ｐｒｅ−ｄｅｆｉｎｅｄ　Ｃｏｌｏｒ：ポリシング処理を行う以前に、パケットに設定されている優先度）という５つの要素が解決対象となる。
【００６５】
フロー識別／経路解決部１２ａにて解決されたＩＤ情報は、図示せぬワード多重回路内の装置内ヘッダ付与部１３ａとパケット属性生成部１３ｂとに配布され、それぞれにおいて、ワード多重、タイムスロット割当て、及びＯｂｊｅｃｔの所定位置にマッピングされた後、図示せぬスイッチ経由でＯｕｔｂｏｕｎｄ側のパケット処理部まで持ち回る（図６のステップＳ３，Ｓ４）。
【００６６】
スイッチ経由で受信したＯｂｊｅｃｔには、Ｉｎｂｏｕｎｄ側で解決したＤｔａｇ情報が搭載されている。パケットスケジューリング処理部１５ａはＤｔａｇ情報を基にフロー毎のシェーピング（　出力規制）　処理、あるいはスケジューリング（　出力順序決定）　処理等のＱｏＳ制御を行う。ここで、装置に要求されるサービスモデルや運用形態に応じて具備するＱｏＳ機構が異なることが想定されるが、このＤｔａｇ情報毎にポリシング及びシェーピングのパラメータを予め設定することで、シェーピング及びスケジューリングをラベル単位もしくはフロー単位で実施する（図７ステップＳ１１）。
【００６７】
上記の機能を実現するために、拡張回路（＃２）１５はＤｔａｇ情報から任意の処理フロー番号［＝装置内フロー識別子（Ｆｌｏｗ　ＩＤ）］を割当てることを目的としたＦｌｏｗテーブル１５ｂを有している。Ｆｌｏｗテーブル１５ｂはＤｔａｇ情報をアドレスとして、装置内フロー識別子を管理するテーブル構成である。また、装置内フロー識別子を複数のリンクポインタにて繋ぐ構成にすることによって、１つのＤｔａｇ情報が複数の回線ポートに対するフロー処理を割当てることも可能となり、一対多（　マルチキャスト）　転送にも対応することができる。
【００６８】
送信パケット処理判定部１６ａでは、パケットスケジューリング処理部１５ａでＤｔａｇ情報を基に変換された装置内フロー識別子（１つあるいは複数）によって、そのパケットに対する処理を決定付ける処理を行う。ＭＡＣ送信イーサ生成回路１６はこの処理フロー（装置内フロー識別子）単位で、パケット処理を決定するためのＡｃｔｉｏｎテーブル１６ｃを有している。Ａｃｔｉｏｎテーブル１６ｃは装置内フロー識別子をアドレスとして、パケットヘッダ処理を設定するＬａｂｅｌ　Ａｃｔｉｏｎ　Ｅｎｔｒｙを有するメモリである。Ｌａｂｅｌ　Ａｃｔｉｏｎ　Ｅｎｔｒｙはパケットスケジューリング処理部１５ａからのｏｂｊｅｃｔに含まれる装置内フロー識別子毎に管理されている。
【００６９】
装置内フロー識別子をアドレスとして、Ａｃｔｉｏｎテーブル１６ｃを引き、Ｌａｂｅｌ　Ａｃｔｉｏｎ　Ｅｎｔｒｙを得ることで、当該パケットに対するアクションを決定する。Ｌａｂｅｌ　Ａｃｔｉｏｎ　Ｅｎｔｒｙは、１５ｂｉｔのａｃｔｉｏｎエントリと、２０ｂｉｔのＬａｂｅｌエントリとから構成される。Ａｃｔｉｏｎエントリは出力Ｓｈｉｍ−Ｈｅａｄｅｒに挿入するラベル、ＥＸＰ、ＴＴＬを導き出す目的で使用し、挿入するＥＸＰ，ＴＴＬ値は、装置内ヘッダに付与されてＩｎｂｏｕｎｄ側からスイッチ経由で通知される値と、Ｏｕｔｂｏｕｎｄ側に備えるＡｃｔｉｏｎテーブル１６ｃに予め登録されている値のいずれかが選択可能である（図７ステップＳ１３）。
【００７０】
ＭＡＣ送信イーサ生成回路１６ではＡｃｔｉｏｎテーブル１６ｃの表引きによって、Ｌａｂｅｌ　Ａｃｔｉｏｎ　Ｅｎｔｒｙを取得し、パケットに対するアクションを決定付けられると、そのアクションにかなったパケット処理が行われる（図７ステップＳ１２，Ｓ１４）。
【００７１】
イーサネット（Ｒ）回線収容部１のＩｎｂｏｕｎｄ側では、受信したＭＡＣパケットに対してＤｔａｇ情報を解決し（図８ステップＳ２１）、ＭＡＣパケットの装置内ヘッダにＤｔａｇ情報を搭載する。
【００７２】
イーサネット（Ｒ）回線収容部１のＯｕｔｂｏｕｎｄ側では、Ｄｔａｇ情報を利用して宛先ポートの解決、Ｆｌｏｗ識別、スタックするＬａｂｅｌの決定等を行い、ＧＦＰパケットを生成し（図８ステップＳ２２）、ＥｏＭＰＬＳドメインやＳＯＮＥＴネットワークに送出する。
【００７３】
また、イーサネット（Ｒ）回線収容部１のＩｎｂｏｕｎｄ側では、ＥｏＭＰＬＳドメインやＳＯＮＥＴネットワークから受信したＧＦＰパケットからラベルを取外し、ＭＡＣパケットを取出し、Ｄｔａｇ情報を解決する（図９ステップＳ３１）。
【００７４】
イーサネット（Ｒ）回線収容部１のＯｕｔｂｏｕｎｄ側では、Ｄｔａｇ情報を利用して宛先ポートの解決、Ｆｌｏｗ識別してＭＡＣパケットを組立てて出力する（図９ステップＳ３２）。
【００７５】
尚、クロスコネクト部２のラベルスイッチ２ａは上述したイーサネット（Ｒ）回線収容部１のＯｕｔｂｏｕｎｄ側と同様の処理動作を行い、イーサネット（Ｒ）回線収容部１−１〜１−ｎからのＤｔａｇ情報が付与されたパケットの先頭に付与された装置内ヘッダにラベルを書込んでＳＯＮＥＴ回線収容部４−１〜４−ｎに送出し、ＳＯＮＥＴ回線収容部４−１〜４−ｎからのＤｔａｇ情報及びラベルが付与されたパケットをそのままイーサネット（Ｒ）回線収容部１−１〜１−ｎに送出する。イーサネット（Ｒ）回線収容部１−１〜１−ｎは上記のＯｕｔｂｏｕｎｄ側と同様の処理動作を行い、ＭＡＣパケットを送信する。
【００７６】
このように、本実施例では、Ｉｎｂｏｕｎｄ側のインタフェースカードにおいて、受信したパケットがＥｏＭＰＬＳに代表されるスペシャルパケットであると判断した場合、以下のパケットハンドリングを実施する手段を有している。
【００７７】
すなわち、本実施例では、入力パケットのヘッダ情報と入力物理ポート番号との組合わせ情報を基に転送先を解決する際に、送信側の転送アクションであるＤｔａｇ情報に一旦変換して装置内を持ち回ることによって、汎用的なパケットスイッチ機構のみを有しているスイッチ処理部の改版なく実現することが可能である。このため、本実施例では、装置コストを下げ、ＭＰＬＳ網の収容（　まきとり）を容易に実現することができる。
【００７８】
また、本実施例では、装置内転送において、出力ラベルを持ち回る必要がなく、装置内における転送オーバヘッドが固定長でよい。そのため、装置内で必要となる転送帯域の変動を抑えることができ、運用上の負荷を軽減することができる。
【００７９】
一方、本実施例では、Ｏｕｔｂｏｕｎｄ側（パケット送信側）のインタフェースカードにおいて、Ｏｂｊｅｃｔに含まれるＤｔａｇ情報でＦｌｏｗ識別し、パケット転送のＳｈａｐｉｎｇ／Ｓｃｈｅｄｕｌｉｎｇを実行し、Ｄｔａｇ情報を装置内における動作規定ポインタとして、転送アクションを決定する手段を有している。
【００８０】
これによって、本実施例では多元的なプロトコルタイプが混在した運用形態においても、装置内では、Ｄｔａｇ情報のみの一元管理で当該パケットの処理アクションが決定付けられるため、装置トータルでの管理が簡素化され、出力処理が容易となる。Ｍｕｌｔｉｃａｓｔ転送等の付加的サービスを実現する場合においても、既存のアーキテクチャの延長で転送処理が実現可能である。
【００８１】
【発明の効果】
以上説明したように本発明は、入力パケットのヘッダ情報と入力物理ポート番号との組合せ情報を基に転送先を解決する際に、送信側の転送アクションを示すＤｔａｇ情報に一旦変換して装置内を持ち回ることによって、装置内で必要となる転送帯域の変動を抑えることができ、運用上の負荷を軽減することができるという効果が得られる。
【図面の簡単な説明】
【図１】本発明の一実施例によるパケット通信装置の構成を示すブロック図である。
【図２】図１のイーサネット（Ｒ）回線収容部の要部構成を示すブロック図である。
【図３】本発明の一実施例によるネットワークアプリケーションモデルを示す図である。
【図４】図２のイーサネット（Ｒ）回線収容部のＩｎｂｏｕｎｄ側の詳細な構成を示すブロック図である。
【図５】図２のイーサネット（Ｒ）回線収容部のｏｕｔｂｏｕｎｄ側の詳細な構成を示すブロック図である。
【図６】図２のイーサネット（Ｒ）回線収容部の基本処理を示すフローチャートである。
【図７】図２のイーサネット（Ｒ）回線収容部の基本処理を示すフローチャートである。
【図８】図２のイーサネット（Ｒ）回線収容部のＩｎｇｒｅｓｓ処理の流れを示す図である。
【図９】図２のイーサネット（Ｒ）回線収容部のＥｇｒｅｓｓ処理の流れを示す図である。
【図１０】従来例によるネットワークアプリケーションモデルを示す図である。
【図１１】ＧＦＰカプセル化処理を示す図である。
【符号の説明】
１，１−１〜１−ｎ　イーサネット（Ｒ）回線収容部
２　クロスコネクト部
２ａ　ラベルスイッチ
３　監視制御部
４−１〜４−ｎ　ＳＯＮＥＴ回線収容部
１１　ＭＡＣ受信イーサ終端回路
１２，１５　拡張回路（＃１，＃２）
１３　ＧＦＰカプセル化回路
１４　ＧＦＰデカプセル化回路
１６　ＭＡＣ送信イーサ生成回路
１７　ＳＴＳマッパ回路
１８　ＳＴＳデマッパ回路
１９　オンボードＣＰＵ
２０　記録媒体
【図１】
2004064574.tif 000003
【図２】
2004064574.tif 000004
【図３】
2004064574.tif 000005
【図４】
2004064574.tif 000006
【図５】
2004064574.tif 000007
【図６】
2004064574.tif 000008
【図７】
2004064574.tif 000009
【図８】
2004064574.tif 000010
【図９】
2004064574.tif 000011
【図１０】
2004064574.tif 000012
【図１１】
2004064574.tif 000013