【０００１】
【発明の属する技術分野】
本発明はパケット通信装置及びそれに用いるネットワーク拡張方法並びにそのプログラムに関し、特にメトロネットワーク内を安価なイーサネット（Ｒ）で構築するネットワーク構築方法に関する。
【０００２】
【従来の技術】
近年、ネットワークを構築する技術としては、メトロネットワーク内を安価なイーサネット（Ｒ）で構築する技術が主流となっている。イーサネット（Ｒ）の速度データレートはフレームリレーやＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ：非同期通信モード）のような他の広帯域ネットワークのインタフェース速度を追越しており、また妥当なコストでスケールする利点を活かして、既存のＳＯＮＥＴ（Ｓｙｎｃｈｒｏｎｏｕｓ Ｏｐｔｉｃａｌ ＮＥＴｗｏｒｋ）相場に置換わり、メトロネットワークへの導入が加速している。
【０００３】
例えば、イーサネット（Ｒ）ベースの技術は２００３年までに、世界のネットワーク接続機器の９８パーセント以上を占めるだろうと想定されている。このイーサネット（Ｒ）ベースの技術はインプリメントが単純であるため、ＡＴＭ、トークンリング及びＦＤＤＩ（Ｆｉｂｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ）のような競合ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）技術に打ち勝っており、かつスタッフトレーニングを必要とせず、コスト効率に優れている。
【０００４】
メトロオプティカルイーサネット（Ｒ）の将来のインプリメンテーションを支援するために必要となるＤｏＳ（Ｄａｔａ ｏｖｅｒ ＳＯＮＥＴ）技術に関しては、ＩＴＵ−Ｔ， Ｔ１Ｘ１．５等にて標準化が進んでいる。これによって、ＬＡＮ−ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）間のインタフェース速度のミスマッチ問題を克服したＶＣ（ Ｖｉｒｔｕａｌ Ｃｏｎｃａｔｅｎａｔｉｏｎ）技術と、従来の方式と比べて高い同期特性を持つＧＦＰ（Ｇｅｎｅｒｉｃ Ｆｒａｍｉｎｇ Ｐｒｏｃｅｄｕｒｅ）技術とが現実解として受け入れられている。
【０００５】
従来のＤｏＳネットワークモデルを図１０に示す。図１０において、ノード（ＳＯＮＥＴ ＮＥ）５１，５２は多元的なイーサネット（Ｒ）｛ＦＥ［１００Ｍｂｐｓ Ｆａｓｔ Ｅｔｈｅｒｎｅｔ（Ｒ）］，ＧＥ［１Ｇｂｐｓ Ｅｔｈｅｒｎｅｔ（Ｒ）］，ＥｏＭＰＬＳ［Ｅｔｈｅｒｎｅｔ（Ｒ） ｏｖｅｒ Ｍｕｌｔｉ Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ］｝を適切な回線速度で収容する。
【０００６】
ノード５１はＶＣ生成用のノードであり、多種イーサネット（Ｒ）（ＦＥ／ＧＥ／１０ＧＥ）をＶＣ−３−Ｎｖにマッピングし、中継フレームとしてＧＦＰを採用している。ノード５２はＶＣ終端点用のノードであり、逆多重手法によってデマッピングを行い、ＧＦＰのＨＥＣ（Ｈｅａｄｅｒ Ｅｒｒｏｒ Ｃｏｎｔｒｏｌ）演算による同期方式がとられている。ノード（ＮＥ）６１，６２は中継ノードであり、多種イーサネット（Ｒ）がマッピングされたパケットにおいてＶＣを意識せず、ＶＣ−３（ＶＣ−４）パスとして処理する。
【０００７】
上記のノード５１，５２，６１，６２のイーサネット（Ｒ）回線収容部はＭＡＣ （Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）受信イーサ終端回路と、ＧＦＰカプセル化回路と、ＳＴＳ（Ｓｙｎｃｈｒｏｎｏｕｓ ＴｒａｎｓｐｏｒｔＳｉｇｎａｌ）マッパ回路とからなるＩｎｂｏｕｎｄ側と、ＳＴＳデマッパ回路と、ＧＦＰデカプセル化回路と、ＭＡＣ送信イーサ生成回路とからなるｏｕｔｂｏｕｎｄ側とによって構成されている。
【０００８】
イーサネット（Ｒ）回線収容部のＩｎｂｏｕｎｄ側では、ＭＡＣ受信イーサ終端回路で多元的なイーサネット（Ｒ）を終端し、ＧＦＰカプセル化回路でＭＡＣフレームをＧＦＰフレームにカプセル化し（図１１参照）、ＳＴＳマッパ回路で収容帯域に応じてＳＴＳ−１（約５０Ｍｂｐｓ）単位でＳＴＳ−１チャネルにＧＦＰフレームをマッピングした後、ＯＣ−Ｎ（Ｏｐｔｉｃａｌ Ｃａｒｒｉｅｒ−Ｎ）ラインに転送する。
【０００９】
ここで、イーサネット（Ｒ）のフォーマットは、図１１に示すように、Ｉｎｔｅｒ Ｆｒａｍｅ Ｇａｐと、Ｐｒｅａｍｂｌｅと、ＳＦＤ（スタートフレームデリミタ）と、ＤＡ（宛先アドレス）と、ＳＡ（送信元アドレス）と、ＬＥＮ（長さ）と、Ｐａｙｌｏａｄと、ＦＣＳ（フレームチェックシーケンス）とからなる。
【００１０】
また、ＧＦＰフレームのフォーマットは、ＰＬＩ及びｃＨＥＣからなるＣｏｒｅ Ｈｅａｄｅｒと、Ｔｙｐｅ及びｔＨＥＣからなるＰａｙｌｏａｄ Ｈｅａｄｅｒと、Ｐａｙｌｏａｄとからなり、Ｐａｙｌｏａｄにイーサネット（Ｒ）のＤＡと、ＳＡと、ＬＥＮと、Ｐａｙｌｏａｄと、ＦＣＳとがカプセル化される。
【００１１】
イーサネット（Ｒ）回線収容部のｏｕｔｂｏｕｎｄ側は、ＳＴＳデマッパ回路でＯＣ−Ｎラインから受信したＳＴＳ−１チャネルを逆多重し、ＧＦＰフレームにデマッピングし、ＧＦＰデカプセル化回路でＧＦＰフレーム同期をとり、ＧＦＰフレームを取出した後、ＭＡＣフレームにデカプセル化する機能を有し、さらに抽出したＭＡＣフレームをＭＡＣ送信イーサ生成回路から送信する。
【００１２】
一方、ＥｏＭＰＬＳドメイン内に転送されるパケットはＭＰＬＳパケットだけとは限らず、▲１▼ＭＰＬＳ［非ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）：ｎ段ラベル付の］パケット、▲２▼ＭＰＬＳ（ＶＰＮ：ｎ段ラベル付の）パケット、▲３▼非ＭＰＬＳ［通常のイーサネット（Ｒ）］パケットだが特別にフローの管理を行うもの、▲４▼非ＭＰＬＳ［通常のイーサネット（Ｒ）］パケットで特別な管理を行わないものの４種類があり、これらは同一の物理ポートに混在する場合がある。
【００１３】
【発明が解決しようとする課題】
従来の装置では、イーサネット（Ｒ）転送系のみに特化しており、上記の▲３▼，▲４▼のみの転送が可能であり、▲１▼，▲２▼のＭＰＬＳラベル化パケット転送手段を持たない。また、通常のイーサネット（Ｒ）パケットについては、半固定的で時分割多重クロスコネクトするためだけのテーブルしか有しておらず、▲１▼，▲２▼のＭＰＬＳラベル化パケット転送に対応するために、別カードを配備し、宛先検索を行った後、スイッチ経由で宛先カードに転送する方式では、無駄にスイッチ帯域を浪費する問題がある。
【００１４】
そこで、本発明の目的は上記の問題点を解消し、装置内で必要となる転送帯域の変動を抑えることができ、運用上の負荷を軽減することができるパケット通信装置及びそれに用いるネットワーク拡張方法並びにそのプログラムを提供することにある。
【００１５】
【課題を解決するための手段】
本発明によるパケット通信装置は、入力パケットのヘッダ情報と入力物理ポート番号との組合せ情報を基に転送先を解決する際に、送信側の転送アクションを示すＤｔａｇ情報に一旦変換して装置内を持ち回っている。
【００１６】
本発明による他のパケット通信装置は、ネットワーク内においてラベルを用いてパケット転送を行うパケット通信装置であって、
受信した主信号パケットのプロトコルを識別して当該プロトコルに対応したパケット転送及び廃棄処理のいずれかを決定するプロトコル識別手段と、前記プロトコル識別手段から転送されるパケットのヘッダ情報を基に当該パケットのフローを識別して転送経路と当該識別フローとに対する処理方法を示すＤｔａｇ情報を解決するフロー識別手段と、前記フロー識別手段の解決結果に応じて前記ラベルを収容するための装置内ヘッダを当該パケットの先頭位置に付与する装置内ヘッダ付与手段と、前記フロー識別手段の解決結果に応じて当該パケットの前記Ｄｔａｇ情報を収容する属性情報を生成して出力するパケット属性生成手段とを備えている。
【００１７】
本発明による別のパケット通信装置は、上記の構成のほかに、前記属性情報内に収容された前記Ｄｔａｇ情報に基づいて前記パケットの前記処理方法を特定するための装置内フロー識別子に変換するスケジューリング処理手段と、前記スケジューリング処理手段で変換された前記装置内フロー識別子に対応しかつ送信パケットに対するラベル化処理方法を決定する送信パケット処理判定手段と、前記送信パケット処理判定手段で決定された前記ラベル化処理方法にしたがって前記主信号パケットの読出し制御を行いかつ読出した主信号パケットに対してラベルの挿抜及びラベル変換処理を行って前記送信パケットの組立てを行う送信パケット組立手段とを具備している。
【００１８】
本発明によるネットワーク拡張方法は、入力パケットのヘッダ情報と入力物理ポート番号との組合せ情報を基に転送先を解決する際に、送信側の転送アクションを示すＤｔａｇ情報に一旦変換して装置内を持ち回るようにしている。
【００１９】
本発明による他のネットワーク拡張方法は、ネットワーク内においてラベルを用いてパケット転送を行うパケット通信装置のネットワーク拡張方法であって、受信した主信号パケットのプロトコルを識別して当該プロトコルに対応したパケット転送及び廃棄処理のいずれかを決定するステップと、前記パケット転送と決定された際にその転送されたパケットのヘッダ情報を基に当該パケットのフローを識別して転送経路と当該識別フローとに対する処理方法を示すＤｔａｇ情報を解決するステップと、この解決結果に応じて前記ラベルを収容するための装置内ヘッダをパケットの先頭位置に付与するステップと、前記解決結果に応じて当該パケットの前記Ｄｔａｇ情報を収容する属性情報を生成して出力するステップとを備えている。
【００２０】
本発明による別のネットワーク拡張方法は、上記のステップのほかに、前記属性情報内に収容された前記Ｄｔａｇ情報に基づいて前記パケットの前記処理方法を特定するための装置内フロー識別子に変換するステップと、この変換された前記装置内フロー識別子に対応しかつ送信パケットに対するラベル化処理方法を決定するステップと、その決定された前記ラベル化処理方法にしたがって前記主信号パケットの読出し制御を行いかつ読出した主信号パケットに対してラベルの挿抜及びラベル変換処理を行って前記送信パケットの組立てを行うステップとを具備している。
【００２１】
本発明によるネットワーク拡張方法のプログラムは、ネットワーク内においてラベルを用いてパケット転送を行うパケット通信装置のネットワーク拡張方法のプログラムであって、コンピュータに、受信した主信号パケットのプロトコルを識別して当該プロトコルに対応したパケット転送及び廃棄処理のいずれかを決定する処理と、前記パケット転送と決定された際にその転送されたパケットのヘッダ情報を基に当該パケットのフローを識別して転送経路と当該識別フローとに対する処理方法を示すＤｔａｇ情報を解決する処理と、この解決結果に応じて前記ラベルを収容するための装置内ヘッダをパケットの先頭位置に付与する処理と、前記解決結果に応じて当該パケットの前記Ｄｔａｇ情報を収容する属性情報を生成して出力する処理とを実行させている。
【００２２】
本発明による他のネットワーク拡張方法のプログラムは、上記の処理のほかに、前記コンピュータに、前記属性情報内に収容された前記Ｄｔａｇ情報に基づいて前記パケットの前記処理方法を特定するための装置内フロー識別子に変換する処理と、この変換された前記装置内フロー識別子に対応しかつ送信パケットに対するラベル化処理方法を決定する処理と、その決定された前記ラベル化処理方法にしたがって前記主信号パケットの読出し制御を行いかつ読出した主信号パケットに対してラベルの挿抜及びラベル変換処理を行って前記送信パケットの組立てを行う処理とを実行させている。
【００２３】
すなわち、本発明のパケット通信装置は、既存のネットワークインフラストラクチャ上で多元的なイーサネット（Ｒ）パケットのデータ転送を可能にし、低コストで先行投資に対する収益を最大限に活用するネットワークへ拡張する方式を実現するものである。拡張に際しては補足設備やオーバレイネットワークが要求されず、トランスポート帯域を効率よく共有することで、高価なファイバプラントを加えず、かつ汎用性に優れた通信装置を提供する。
【００２４】
つまり、本発明のパケット通信装置では、Ｉｎｂｏｕｎｄ側（パケット受信側）のインタフェースカードにおいて、受信したパケットがＥｏＭＰＬＳ［Ｅｔｈｅｒｎｅｔ（Ｒ） ｏｖｅｒ Ｍｕｌｔｉ Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ］に代表されるスペシャルパケットであると判断した場合、以下のようなパケットハンドリングを実施する手段を有している。
【００２５】
本発明のパケット通信装置では、入力パケットのヘッダ情報と入力物理ポート番号との組合わせ情報を基に転送先を解決する際に、送信側の転送アクション（転送経路と識別フローとに対する処理方法）を示すＤｔａｇ情報を入力パケットの先頭部分に付与し、入力パケットをそのＤｔａｇ情報で装置内を持ち回ることによって、汎用的なパケットスイッチ機構のみを有しているスイッチ処理部を改版することなく、上記の通信装置を実現することが可能である。このため、本発明のパケット通信装置では、装置コストを下げ、ＭＰＬＳ（Ｍｕｌｔｉ Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）網の収容（ まきとり）が容易に実現可能となる。
【００２６】
また、本発明のパケット通信装置では、入力パケットの装置内転送において、出力ラベルを持ち回る必要がなく、装置内における転送オーバヘッドが固定長でよくなるため、装置内で必要となる転送帯域の変動を抑えることが可能となり、運用上の負荷を軽減することが可能となる。
【００２７】
一方、本発明のパケット通信装置では、Ｏｕｔｂｏｕｎｄ側（パケット送信側）のインタフェースカードにおいて、Ｏｂｊｅｃｔに含まれるＤｔａｇ情報でフロー（Ｆｌｏｗ）識別し、パケット転送のシェーピング（Ｓｈａｐｉｎｇ）（回線の伝送速度にあわせて送出するパケットを調整すること）／スケジューリング（Ｓｃｈｅｄｕｌｉｎｇ）を実行し、Ｄｔａｇ情報を装置内における動作規定ポインタとして、転送アクションを決定する手段を有している。
【００２８】
これによって、本発明のパケット通信装置では、多元的なプロトコルタイプが混在した運用形態においても、装置内においてＤｔａｇ情報のみの一元管理で当該パケットの処理アクションが決定付けられるため、装置トータルでの管理が簡素化され、出力処理が容易となる。マルチキャスト（Ｍｕｌｔｉｃａｓｔ）転送等の付加的サービスを実現する場合においても、既存のアーキテクチャの延長で転送処理が実現可能である。
【００２９】
上述したような構成及び動作をとることで、本発明は、オプティカルイーサネット（Ｒ）によってＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）対ＬＡＮのメトロ接続を可能とし、ＬＡＮ側のインタフェース速度にマッチさせるべく、１００Ｍｂｐｓ間隔で、１００Ｍｂｐｓから１０Ｇｂｐｓまでに及ぶ実行レートで収容設計、高速転送が可能となる。
【００３０】
また、本発明は、統合イーサネット（Ｒ）及びＤＷＤＭ（Ｄｅｎｓｅ Ｗａｖｅｌｅｎｇｔｈ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）技術を使用する１０Ｇｂｐｓあるいは１００Ｇｂｐｓクラス転送レートで高機能メトロコア接続を実現している。
【００３１】
ＭＰＬＳ（Ｍｕｌｔｉ Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）に基づくサービスは、メトロネットワークをトランスペアレントさせ、トランスポート上のフローを保証しつつ、従来のＳＯＮＥＴ（ＳｙｎｃｈｒｏｎｏｕｓＯｐｔｉｃａｌ ＮＥＴｗｏｒｋ） ＲＩＮＧネットワークインフラストラクチュアに対する代案としている。
【００３２】
本発明の特徴は、サービス柔軟性、サービス区別及び収入増強、帯域幅再使用、パケット粒状を備えた帯域幅管理、ハイブリッドネットワーク要素、スケーラビリティへの解決策、廉価な在来のＬＡＮインタフェースのまきとり収容、Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ支援、バーチャルＬＡＮの支援のための手段を有する点にある。
【００３３】
【発明の実施の形態】
次に、本発明の一実施例について図面を参照して説明する。図１は本発明の一実施例によるパケット通信装置の構成を示すブロック図である。図１において、本発明の一実施例によるパケット通信装置は多元的なイーサネット（Ｒ）回線を収容し、主信号入出力部を有するイーサネット（Ｒ）回線収容部１−１〜１−ｎと、収容回線に応じてＮ×ＳＴＳ（Ｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｐｏｒｔ Ｓｉｇｎａｌ）−１単位にクロスコネクト可能でかつラベルスイッチ２ａを持つクロスコネクト部２と、多様な制御プロトコルを終端し、複数のイーサネット（Ｒ）回線収容部１−１〜１−ｎとクロスコネクト部２とに設定情報を設定し、監視項目を収集する機能を有する監視制御部３と、ＳＯＮＥＴ（Ｓｙｎｃｈｒｏｎｏｕｓ Ｏｐｔｉｃａｌ ＮＥＴｗｏｒｋ）回線収容部４−１〜４−ｎから構成されている。
【００３４】
図２は図１のイーサネット（Ｒ）回線収容部１−１〜１−ｎの要部構成を示すブロック図である。図２においてはイーサネット（Ｒ）回線収容部１−１〜１−ｎをイーサネット（Ｒ）回線収容部１として図示している。
【００３５】
図２において、イーサネット（Ｒ）回線収容部１はＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）受信イーサ終端回路１１と、ＧＦＰ（Ｇｅｎｅｒｉｃ Ｆｒａｍｉｎｇ Ｐｒｏｃｅｄｕｒｅ）カプセル化回路１３と、ＳＴＳマッパ回路１７とからなるＩｎｂｏｕｎｄ側（パケット受信側）と、ＳＴＳデマッパ回路１８と、ＧＦＰデカプセル化回路１４と、ＭＡＣ送信イーサ生成回路１６とからなるＯｕｔｂｏｕｎｄ側（パケット送信側）と、拡張回路（＃１，＃２）１２，１５と、オンボードＣＰＵ（中央処理装置）１９と、記録媒体２０とによって構成されている。
【００３６】
イーサネット（Ｒ）回線収容部１のＩｎｂｏｕｎｄ側では、ＭＡＣ受信イーサ終端回路１１で多元的なイーサネット（Ｒ）を終端し、ＧＦＰカプセル化回路１３でＭＡＣフレームをＧＦＰフレームにカプセル化し（ 図９参照） 、ＳＴＳマッパ回路１７で収容帯域に応じてＳＴＳ−１（約５０Ｍｂｐｓ）単位でＳＴＳ−１チャネルにＧＦＰフレームをマッピングした後、ＯＣ（Ｏｐｔｉｃａｌ Ｃａｒｒｉｅｒ）−Ｎラインに転送する。
【００３７】
尚、ＳＴＳマッパ回路１７でマッピングされたＧＦＰフレームは、実際には、上記のクロスコネクト部２のラベルスイッチ２ａを通してＳＯＮＥＴ回線収容部４−１〜４−ｎへと送出され、ＳＯＮＥＴ回線収容部４−１〜４−ｎからＯＣ−Ｎラインへと転送される。
【００３８】
イーサネット（Ｒ）回線収容部１のＯｕｔｂｏｕｎｄ側では、ＳＴＳデマッパ回路１８でＯＣ−Ｎライン（クロスコネクト部２）から受信したＳＴＳ−１チャネルを逆多重し、ＧＦＰフレームにデマッピングし、ＧＦＰデカプセル化回路１４でＧＦＰフレーム同期をとり、ＧＦＰフレームを取出した後、ＭＡＣフレームにデカプセル化し、その抽出されたＭＡＣフレームがＭＡＣ送信イーサ生成回路１６から送信される。
【００３９】
上述したイーサネット（Ｒ）回線収容部１のＩｎｂｏｕｎｄ側とＯｕｔｂｏｕｎｄ側とによって、ＬＡＮ対ＬＡＮのメトロ接続が可能となるが、本発明ではＳｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ 支援とバーチャルＬＡＮの支援とを図る拡張回路（＃１，＃２）１２，１５をａｄｄ−ｏｎしている。尚、上述したイーサネット（Ｒ）回線収容部１の処理は図示せぬコンピュータが記録媒体２０に格納されたプログラムを実行することでも実現される。
【００４０】
図３は本発明の一実施例によるネットワークアプリケーションモデルを示す図である。図３において、本発明の一実施例によるネットワークアプリケーションモデルは、ＥｏＭＰＬＳ［Ｅｔｈｅｒｎｅｔ（Ｒ） ｏｖｅｒ Ｍｕｌｔｉ Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ］クライアントを収容可能としており、この点が本発明の一実施例によるネットワークアプリケーションモデルと図１１に示す従来のネットワークモデルとの違いである。
【００４１】
図３に示すＥｏＭＰＬＳドメイン内に転送されるパケットはＭＰＬＳ（Ｍｕｌｔｉ Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）パケットだけとは限らず、本発明におけるパケットとしては、▲１▼ＭＰＬＳ［非ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）：ｎ段ラベル付の］パケット、▲２▼ＭＰＬＳ（ＶＰＮ：ｎ段ラベル付の）パケット、▲３▼非ＭＰＬＳ［通常のイーサネット（Ｒ）］パケットだが特別にフローの管理を行うもの、▲４▼非ＭＰＬＳ［通常のイーサネット（Ｒ）］パケットで特別な管理を行わないものの４種類があり、これらは同一の物理ポートに混在する場合がある。
【００４２】
従来の通信装置では、イーサネット（Ｒ）転送系のみに特化しており、上記の▲３▼，▲４▼のみの転送が可能であり、▲１▼，▲２▼のＭＰＬＳラベル化パケット転送手段を持たない。また、通常のイーサネット（Ｒ）パケットについては、半固定的で時分割多重クロスコネクトするためだけのテーブルしか有しておらず、▲１▼，▲２▼のＭＰＬＳラベル化パケット転送に対応するために、別カードを配備し、宛先検索を行った後、スイッチ経由で宛先カードに転送する方式では、無駄にスイッチ帯域を浪費するという問題がある。
【００４３】
ここで、ＭＰＬＳラベル化パケット転送ではＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスとラベルと呼ぶ下位レイヤの情報とを対応付け、ラベルだけ参照してパケットを転送する方法であり、ラベルはＩＰアドレスへのパケット転送先をＭＰＬＳ網上で識別するためのデータである。
【００４４】
すなわち、図３において、ノード（ＳＯＮＥＴ ＮＥ）５１，５２は多元的なイーサネット（Ｒ）｛ＦＥ［１００Ｍｂｐｓ Ｆａｓｔ Ｅｔｈｅｒｎｅｔ（Ｒ）］，ＧＥ［１Ｇｂｐｓ Ｅｔｈｅｒｎｅｔ（Ｒ）］，ＥｏＭＰＬＳ［Ｅｔｈｅｒｎｅｔ（Ｒ） ｏｖｅｒ Ｍｕｌｔｉ Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ］｝を適切な回線速度で収容する。
【００４５】
ノード５１はＶＣ生成用のノードであり、多種イーサネット（Ｒ）（ＦＥ／ＧＥ／１０ＧＥ）をＶＣ−３−Ｎｖにマッピングし、中継フレームとしてＧＦＰを採用している。ノード５２はＶＣ終端点用のノードであり、逆多重手法によってデマッピングを行い、ＧＦＰのＨＥＣ（Ｈｅａｄｅｒ Ｅｒｒｏｒ Ｃｏｎｔｒｏｌ）演算による同期方式がとられている。ノード（ＮＥ）６１，６２は中継ノードであり、多種イーサネット（Ｒ）がマッピングされたパケットにおいてＶＣを意識せず、ＶＣ−３（ＶＣ−４）パスとして処理する。
【００４６】
ノード５１は受信したイーサネット（Ｒ）パケットのＭＡＣフレームにラベル（Ｌａｂｅｌ＃１）を付与（Ｌａｂｅｌ Ｐｕｓｈ）したＧＦＰフレームをノード６１に送信する。ノード６１はＧＦＰフレームのラベル（Ｌａｂｅｌ＃１）を基にノード６２へと転送し、ノード６２はＧＦＰフレームのラベル（Ｌａｂｅｌ＃２）を基にノード５２へと転送する。ノード５２は受信したＧＦＰフレームのラベル（Ｌａｂｅｌ＃３）を除去してＭＡＣフレームを抽出し、この抽出したＭＡＣフレームを外部へと送信する。
【００４７】
この場合、ノード６１ではラベル（Ｌａｂｅｌ＃１）がラベル（Ｌａｂｅｌ＃２）に置換えられ（Ｌａｂｅｌ Ｓｗａｐ）、ノード６２ではラベル（Ｌａｂｅｌ＃２）がラベル（Ｌａｂｅｌ＃３）に置換えられる（Ｌａｂｅｌ Ｓｗａｐ）。
【００４８】
本実施例では上記の課題を解決するために、図２に示すように、拡張回路（＃１，＃２）１２，１５を配設することで、ＥｏＭＰＬＳにてラベル化されたパケットについてもハンドリングが可能となる。
【００４９】
図４は図２のイーサネット（Ｒ）回線収容部１のＩｎｂｏｕｎｄ側の詳細な構成を示すブロック図であり、図５は図２のイーサネット（Ｒ）回線収容部１のＯｕｔｂｏｕｎｄ側の詳細な構成を示すブロック図である。これら図４及び図５を参照して拡張回路（＃１）１２及び拡張回路（＃２）１５の構成についてそれぞれ説明する。
【００５０】
図４において、ＭＡＣ受信イーサ終端回路１１はプロトコル識別部１１ａを備え、拡張回路（＃１）１２はフロー識別／経路解決部１２ａ及びＣｌａｓｓｆｉｅｒテーブル（Ｔａｂｌｅ）１２ｂを備え、ＧＦＰカプセル化回路１３は装置内ヘッダ付与部１３ａ及びパケット属性生成部１３ｂを備えている。
【００５１】
プロトコル識別部１１ａはリンクフェーズとプロトコルタイプとに対応したパケット転送、あるいは廃棄処理を決定するための機能を有している。フロー識別／経路解決部１２ａはプロトコル識別部１１ａによって転送されたパケットヘッダから、当該パケットのフロー（特定のヘッダ情報を共有しており、同じルーティング処理を受ける単方向のパケットが複数まとまったもの）（ あるいはラベル） を識別し、転送経路と当該識別フロー（ あるいは識別ラベル） とに応じた処理方法（Ｄｔａｇ情報） を、テーブル（Ｃｌａｓｓｆｉｅｒテーブル１２ｂ）を参照することによって解決し、装置内ヘッダ付与部１３ａ及びパケット属性生成部１３ｂに対して指示する機能を有する。
【００５２】
ここで、Ｃｌａｓｓｆｉｅｒテーブル１２ｂはヘッダ情報とＤｔａｇ情報とが対応付けられて格納されている。また、フロー識別／経路解決部１２ａから装置内ヘッダ付与部１３ａ及びパケット属性生成部１３ｂには指示内容として、Ｄｔａｇ，Ａｃｔｉｏｎ，ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ），Ｒｏｕｔｅ，・・・が送出される。
【００５３】
装置内ヘッダ付与部１３ａはフロー識別／経路解決部１２ａの指示によってラベルを収容するための装置内ヘッダをパケットの先頭位置に付与し、パケット属性生成部１３ｂはフロー識別／経路解決部１２ａの指示内容によって、Ｄｔａｇ情報を収容した当該パケットの属性情報を生成する。
【００５４】
図５において、拡張回路（＃２）１５はパケットスケジューリング処理部１５ａ及びＦｌｏｗテーブル（Ｔａｂｌｅ）１５ｂを備え、ＭＡＣ送信イーサ生成回路１６は送信パケット処理判定部１６ａと送信パケット組立及び送信パケット多重部１６ｂとＡｃｔｉｏｎテーブル（Ｔａｂｌｅ）１６ｃとを備えている。
【００５５】
パケットスケジューリング処理部１５ａは受信したパケット属性情報内に収容されたＤｔａｇ情報を基にＦｌｏｗテーブル１５ｂを参照して当該パケットの装置内フロー識別子（Ｆｌｏｗ ＩＤ）を解決し、その装置内フロー識別子毎にパケット属性情報をキューイング（ メモリに格納） するとともに、ピークレートと平均レートとに基づくＤｕａｌ Ｔｏｋｅｎ Ｂｕｃｋｅｔ方式によるシェーピング（Ｓｈａｐｉｎｇ）及び優先スケジューリング（ｓｃｈｅｄｕｌｉｎｇ）（によるメモリ読出し）を行う。
【００５６】
ここで、Ｆｌｏｗテーブル１５ｂはＤｔａｇ情報をアドレスとして、装置内フロー識別子を管理するテーブル構成であり、装置内フロー識別子を複数のリンクポインタにて繋ぐ構成にすることによって、１つのＤｔａｇ情報が複数の回線ポートに対するフロー処理を割当てることも可能となり、一対多（ マルチキャスト） 転送にも対応することができる。
【００５７】
すなわち、Ｄｔａｇ情報を装置内フロー識別子と１対Ｎ（Ｎは正の整数）に対応付けることで、１つのＤｔａｇ情報によってＦｌｏｗテーブル１５ｂからＮ個の装置内フロー識別子が読出され、Ｎ個の装置内フロー識別子各々に対応する回線ポートに対するフロー処理を割当てることができる。
【００５８】
送信パケット処理判定部１６ａはパケットスケジューリング処理部１５ａから受信したパケット属性情報内に収容される装置内フロー識別子を基にＡｃｔｉｏｎテーブル１６ｃを参照し、送信パケットに対するラベル化処理方法（Ａｃｔｉｏｎ）を決定する。ここで、Ａｃｔｉｏｎテーブル１６ｃは装置内フロー識別子をアドレスとして、パケットヘッダ処理を設定するＬａｂｅｌ Ａｃｔｉｏｎ Ｅｎｔｒｙを有するメモリである。Ｌａｂｅｌ Ａｃｔｉｏｎ Ｅｎｔｒｙはパケットスケジューリング処理部１５ａからのｏｂｊｅｃｔに含まれる装置内フロー識別子毎に管理されている。
【００５９】
送信パケット組立及び送信パケット多重部１６ｂは送信パケット処理判定部１６ａが決定したラベル化処理方法にしたがってＳＴＳデマッパ回路１８でワード逆多重された主信号パケットの読出し制御を行い、さらに読出した主信号パケットに対してラベルの挿抜またはラベル変換処理を行った後、送信パケット組立てを行い、その送信パケットを送信する。
【００６０】
図６及び図７は図２のイーサネット（Ｒ）回線収容部１の基本処理を示すフローチャートであり、図８は図２のイーサネット（Ｒ）回線収容部１のＩｎｇｒｅｓｓ処理の流れを示す図であり、図９は図２のイーサネット（Ｒ）回線収容部１のＥｇｒｅｓｓ処理の流れを示す図である。これら図２と図４〜図９とを参照してイーサネット （Ｒ）回線収容部１の基本処理について説明する。
【００６１】
尚、図６はイーサネット（Ｒ）回線収容部１のＩｎｂｏｕｎｄ側の処理を示し、図７はイーサネット（Ｒ）回線収容部１のＯｕｔｂｏｕｎｄ側の処理を示している。また、図６〜図９に示す処理はイーサネット（Ｒ）回線収容部１のコンピュータが記録媒体２０のプログラムを実行することでも実現される。
【００６２】
プロトコル識別部１１ａは受信したパケットヘッダのプロトコルＩＤを参照して制御パケットであるか、主信号パケットであるかを識別する（プロトコル判定、制御パケットの分離）（図６ステップＳ１）。プロトコル識別部１１ａはこの識別処理において主信号パケットであると識別すると、そのパケットヘッダをフロー識別／経路解決部１２ａに送出し、制御パケットであると識別すると、ボード上に実装されるオンボードＣＰＵ１９によってリンク確立等の処理が実施される。ここで、主信号パケットとは、通常のイーサネット（Ｒ）パケット及びイーサネット（Ｒ）バーＭＰＬＳパケットが該当する。
【００６３】
フロー識別／経路解決部１２ａはプロトコル識別部１１ａからパケットヘッダを受信すると、上述したパケットヘッダ内の複数フィールドの任意組合せを検索キーとして、Ｃｌａｓｓｉｆｉｅｒテーブル１２ｂの検索処理を行う（図６ステップＳ２）。
【００６４】
このＭｕｌｔｉ−Ｆｉｅｌｄ検索の結果、ＦＥＣ ＩＤ（Ｆｏｒｗａｒｄｉｎｇ Ｅｑｕｉｖａｌｅｎｔ Ｃｌａｓｓ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ：転送先経路を決定する識別子）、ＰＬＣ ＩＤ（Ｐｏｌｉｃｉｎｇ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ：ポリシング対象となるフローを決定する識別子）、ＣＬＳ ＩＤ［Ｃｌａｓｓ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ：転送ＱｏＳ（Ｑｕａｌｉｔｙｏｆ Ｓｅｒｖｉｃｅ）クラスを決定する識別子］、ＳＴＡＴ ＩＤ（Ｓｔａｔｉｓｔｉｃ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｏｕｎｔｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ：統計情報のカウント単位を規定する識別子）、ＰＣＯＬＯＲ（Ｐｒｅ−ｄｅｆｉｎｅｄ Ｃｏｌｏｒ：ポリシング処理を行う以前に、パケットに設定されている優先度）という５つの要素が解決対象となる。
【００６５】
フロー識別／経路解決部１２ａにて解決されたＩＤ情報は、図示せぬワード多重回路内の装置内ヘッダ付与部１３ａとパケット属性生成部１３ｂとに配布され、それぞれにおいて、ワード多重、タイムスロット割当て、及びＯｂｊｅｃｔの所定位置にマッピングされた後、図示せぬスイッチ経由でＯｕｔｂｏｕｎｄ側のパケット処理部まで持ち回る（図６のステップＳ３，Ｓ４）。
【００６６】
スイッチ経由で受信したＯｂｊｅｃｔには、Ｉｎｂｏｕｎｄ側で解決したＤｔａｇ情報が搭載されている。パケットスケジューリング処理部１５ａはＤｔａｇ情報を基にフロー毎のシェーピング（ 出力規制） 処理、あるいはスケジューリング（ 出力順序決定） 処理等のＱｏＳ制御を行う。ここで、装置に要求されるサービスモデルや運用形態に応じて具備するＱｏＳ機構が異なることが想定されるが、このＤｔａｇ情報毎にポリシング及びシェーピングのパラメータを予め設定することで、シェーピング及びスケジューリングをラベル単位もしくはフロー単位で実施する（図７ステップＳ１１）。
【００６７】
上記の機能を実現するために、拡張回路（＃２）１５はＤｔａｇ情報から任意の処理フロー番号［＝装置内フロー識別子（Ｆｌｏｗ ＩＤ）］を割当てることを目的としたＦｌｏｗテーブル１５ｂを有している。Ｆｌｏｗテーブル１５ｂはＤｔａｇ情報をアドレスとして、装置内フロー識別子を管理するテーブル構成である。また、装置内フロー識別子を複数のリンクポインタにて繋ぐ構成にすることによって、１つのＤｔａｇ情報が複数の回線ポートに対するフロー処理を割当てることも可能となり、一対多（ マルチキャスト） 転送にも対応することができる。
【００６８】
送信パケット処理判定部１６ａでは、パケットスケジューリング処理部１５ａでＤｔａｇ情報を基に変換された装置内フロー識別子（１つあるいは複数）によって、そのパケットに対する処理を決定付ける処理を行う。ＭＡＣ送信イーサ生成回路１６はこの処理フロー（装置内フロー識別子）単位で、パケット処理を決定するためのＡｃｔｉｏｎテーブル１６ｃを有している。Ａｃｔｉｏｎテーブル１６ｃは装置内フロー識別子をアドレスとして、パケットヘッダ処理を設定するＬａｂｅｌ Ａｃｔｉｏｎ Ｅｎｔｒｙを有するメモリである。Ｌａｂｅｌ Ａｃｔｉｏｎ Ｅｎｔｒｙはパケットスケジューリング処理部１５ａからのｏｂｊｅｃｔに含まれる装置内フロー識別子毎に管理されている。
【００６９】
装置内フロー識別子をアドレスとして、Ａｃｔｉｏｎテーブル１６ｃを引き、Ｌａｂｅｌ Ａｃｔｉｏｎ Ｅｎｔｒｙを得ることで、当該パケットに対するアクションを決定する。Ｌａｂｅｌ Ａｃｔｉｏｎ Ｅｎｔｒｙは、１５ｂｉｔのａｃｔｉｏｎエントリと、２０ｂｉｔのＬａｂｅｌエントリとから構成される。Ａｃｔｉｏｎエントリは出力Ｓｈｉｍ−Ｈｅａｄｅｒに挿入するラベル、ＥＸＰ、ＴＴＬを導き出す目的で使用し、挿入するＥＸＰ，ＴＴＬ値は、装置内ヘッダに付与されてＩｎｂｏｕｎｄ側からスイッチ経由で通知される値と、Ｏｕｔｂｏｕｎｄ側に備えるＡｃｔｉｏｎテーブル１６ｃに予め登録されている値のいずれかが選択可能である（図７ステップＳ１３）。
【００７０】
ＭＡＣ送信イーサ生成回路１６ではＡｃｔｉｏｎテーブル１６ｃの表引きによって、Ｌａｂｅｌ Ａｃｔｉｏｎ Ｅｎｔｒｙを取得し、パケットに対するアクションを決定付けられると、そのアクションにかなったパケット処理が行われる（図７ステップＳ１２，Ｓ１４）。
【００７１】
イーサネット（Ｒ）回線収容部１のＩｎｂｏｕｎｄ側では、受信したＭＡＣパケットに対してＤｔａｇ情報を解決し（図８ステップＳ２１）、ＭＡＣパケットの装置内ヘッダにＤｔａｇ情報を搭載する。
【００７２】
イーサネット（Ｒ）回線収容部１のＯｕｔｂｏｕｎｄ側では、Ｄｔａｇ情報を利用して宛先ポートの解決、Ｆｌｏｗ識別、スタックするＬａｂｅｌの決定等を行い、ＧＦＰパケットを生成し（図８ステップＳ２２）、ＥｏＭＰＬＳドメインやＳＯＮＥＴネットワークに送出する。
【００７３】
また、イーサネット（Ｒ）回線収容部１のＩｎｂｏｕｎｄ側では、ＥｏＭＰＬＳドメインやＳＯＮＥＴネットワークから受信したＧＦＰパケットからラベルを取外し、ＭＡＣパケットを取出し、Ｄｔａｇ情報を解決する（図９ステップＳ３１）。
【００７４】
イーサネット（Ｒ）回線収容部１のＯｕｔｂｏｕｎｄ側では、Ｄｔａｇ情報を利用して宛先ポートの解決、Ｆｌｏｗ識別してＭＡＣパケットを組立てて出力する（図９ステップＳ３２）。
【００７５】
尚、クロスコネクト部２のラベルスイッチ２ａは上述したイーサネット（Ｒ）回線収容部１のＯｕｔｂｏｕｎｄ側と同様の処理動作を行い、イーサネット（Ｒ）回線収容部１−１〜１−ｎからのＤｔａｇ情報が付与されたパケットの先頭に付与された装置内ヘッダにラベルを書込んでＳＯＮＥＴ回線収容部４−１〜４−ｎに送出し、ＳＯＮＥＴ回線収容部４−１〜４−ｎからのＤｔａｇ情報及びラベルが付与されたパケットをそのままイーサネット（Ｒ）回線収容部１−１〜１−ｎに送出する。イーサネット（Ｒ）回線収容部１−１〜１−ｎは上記のＯｕｔｂｏｕｎｄ側と同様の処理動作を行い、ＭＡＣパケットを送信する。
【００７６】
このように、本実施例では、Ｉｎｂｏｕｎｄ側のインタフェースカードにおいて、受信したパケットがＥｏＭＰＬＳに代表されるスペシャルパケットであると判断した場合、以下のパケットハンドリングを実施する手段を有している。
【００７７】
すなわち、本実施例では、入力パケットのヘッダ情報と入力物理ポート番号との組合わせ情報を基に転送先を解決する際に、送信側の転送アクションであるＤｔａｇ情報に一旦変換して装置内を持ち回ることによって、汎用的なパケットスイッチ機構のみを有しているスイッチ処理部の改版なく実現することが可能である。このため、本実施例では、装置コストを下げ、ＭＰＬＳ網の収容（ まきとり）を容易に実現することができる。
【００７８】
また、本実施例では、装置内転送において、出力ラベルを持ち回る必要がなく、装置内における転送オーバヘッドが固定長でよい。そのため、装置内で必要となる転送帯域の変動を抑えることができ、運用上の負荷を軽減することができる。
【００７９】
一方、本実施例では、Ｏｕｔｂｏｕｎｄ側（パケット送信側）のインタフェースカードにおいて、Ｏｂｊｅｃｔに含まれるＤｔａｇ情報でＦｌｏｗ識別し、パケット転送のＳｈａｐｉｎｇ／Ｓｃｈｅｄｕｌｉｎｇを実行し、Ｄｔａｇ情報を装置内における動作規定ポインタとして、転送アクションを決定する手段を有している。
【００８０】
これによって、本実施例では多元的なプロトコルタイプが混在した運用形態においても、装置内では、Ｄｔａｇ情報のみの一元管理で当該パケットの処理アクションが決定付けられるため、装置トータルでの管理が簡素化され、出力処理が容易となる。Ｍｕｌｔｉｃａｓｔ転送等の付加的サービスを実現する場合においても、既存のアーキテクチャの延長で転送処理が実現可能である。
【００８１】
【発明の効果】
以上説明したように本発明は、入力パケットのヘッダ情報と入力物理ポート番号との組合せ情報を基に転送先を解決する際に、送信側の転送アクションを示すＤｔａｇ情報に一旦変換して装置内を持ち回ることによって、装置内で必要となる転送帯域の変動を抑えることができ、運用上の負荷を軽減することができるという効果が得られる。
【図面の簡単な説明】
【図１】本発明の一実施例によるパケット通信装置の構成を示すブロック図である。
【図２】図１のイーサネット（Ｒ）回線収容部の要部構成を示すブロック図である。
【図３】本発明の一実施例によるネットワークアプリケーションモデルを示す図である。
【図４】図２のイーサネット（Ｒ）回線収容部のＩｎｂｏｕｎｄ側の詳細な構成を示すブロック図である。
【図５】図２のイーサネット（Ｒ）回線収容部のｏｕｔｂｏｕｎｄ側の詳細な構成を示すブロック図である。
【図６】図２のイーサネット（Ｒ）回線収容部の基本処理を示すフローチャートである。
【図７】図２のイーサネット（Ｒ）回線収容部の基本処理を示すフローチャートである。
【図８】図２のイーサネット（Ｒ）回線収容部のＩｎｇｒｅｓｓ処理の流れを示す図である。
【図９】図２のイーサネット（Ｒ）回線収容部のＥｇｒｅｓｓ処理の流れを示す図である。
【図１０】従来例によるネットワークアプリケーションモデルを示す図である。
【図１１】ＧＦＰカプセル化処理を示す図である。
【符号の説明】
１，１−１〜１−ｎ イーサネット（Ｒ）回線収容部
２ クロスコネクト部
２ａ ラベルスイッチ
３ 監視制御部
４−１〜４−ｎ ＳＯＮＥＴ回線収容部
１１ ＭＡＣ受信イーサ終端回路
１２，１５ 拡張回路（＃１，＃２）
１３ ＧＦＰカプセル化回路
１４ ＧＦＰデカプセル化回路
１６ ＭＡＣ送信イーサ生成回路
１７ ＳＴＳマッパ回路
１８ ＳＴＳデマッパ回路
１９ オンボードＣＰＵ
２０ 記録媒体[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a packet communication device, a network expansion method used therefor, and a program therefor, and more particularly to a network construction method for constructing a metro network using an inexpensive Ethernet (R).
[0002]
[Prior art]
In recent years, as a technology for constructing a network, a technology for constructing a metro network using inexpensive Ethernet (R) has become mainstream. Ethernet® data rates have surpassed the interface speeds of other broadband networks, such as Frame Relay and Asynchronous Transfer Mode (ATM), and take advantage of scaling at a reasonable cost. Has been replaced by the SONET (Synchronous Optical NETwork) market, and its introduction into the metro network is accelerating.
[0003]
For example, it is envisioned that Ethernet-based technology will account for more than 98 percent of the world's networked equipment by 2003. Due to the simplicity of implementation of this Ethernet (R) based technology, it overcomes competing LAN (Local Area Network) technologies such as ATM, Token Ring and Fiber Distributed Data Interface (FDDI) and requires staff training. And cost-effective.
[0004]
The DoS (Data over SONET) technology required to support future implementation of Metro Optical Ethernet (R) is being standardized by ITU-T, T1X1.5, and the like. As a result, a VC (Virtual Concatenation) technique that overcomes the interface speed mismatch problem between a LAN and a WAN (Wide Area Network), and a GFP (Generic Framing Procedure) technique that has higher synchronization characteristics than the conventional scheme are actually realized. Accepted as a solution.
[0005]
FIG. 10 shows a conventional DoS network model. In FIG. 10, nodes (SONET NE) 51 and 52 are multiple Ethernet (R) @FE [100 Mbps Fast Ethernet (R)], GE [1 Gbps Ethernet (R)], EoMPLS [Ethernet (R) over Multiprotocol Label]. Switching] is accommodated at an appropriate line speed.
[0006]
The node 51 is a node for generating a VC, maps various types of Ethernet® (FE / GE / 10GE) to VC-3-Nv, and employs GFP as a relay frame. The node 52 is a node for a VC terminal point, performs demapping by an inverse multiplexing method, and adopts a synchronization method based on GFP HEC (Header Error Control) operation. The nodes (NE) 61 and 62 are relay nodes, and process packets as VC-3 (VC-4) paths without being aware of VC in packets to which various types of Ethernet (R) are mapped.
[0007]
The Ethernet (R) line accommodating units of the nodes 51, 52, 61, and 62 have an Inbound side including a MAC (Media Access Control) reception Ethernet termination circuit, a GFP encapsulation circuit, and an STS (Synchronous Transport Signal) mapper circuit. , An STS demapper circuit, a GFP decapsulation circuit, and an outbound side including a MAC transmission Ethernet generation circuit.
[0008]
On the Inbound side of the Ethernet (R) line accommodating unit, the multiple Ethernet (R) is terminated by the MAC reception Ethernet termination circuit, the MAC frame is encapsulated into the GFP frame by the GFP encapsulation circuit (see FIG. 11), and the STS mapper is used. The circuit maps the GFP frame to the STS-1 channel in STS-1 (approximately 50 Mbps) units according to the accommodating band, and then transfers it to the OC-N (Optical Carrier-N) line.
[0009]
Here, as shown in FIG. 11, the format of the Ethernet (R) is Inter Frame Gap, Preamble, SFD (Start Frame Delimiter), DA (Destination Address), SA (Source Address), and LEN. (Length), Payload, and FCS (frame check sequence).
[0010]
The format of the GFP frame is composed of a Core Header composed of PLI and cHEC, a Payload Header composed of Type and tHEC, and a Payload, and the Payload includes DA of Ethernet®, SA, LEN, and Payload. FCS is encapsulated.
[0011]
The outbound side of the Ethernet (R) line accommodating unit demultiplexes the STS-1 channel received from the OC-N line by the STS demapper circuit, demaps the STS-1 channel to the GFP frame, and synchronizes the GFP frame by the GFP decapsulation circuit. After taking out the GFP frame, it has a function of decapsulating it into a MAC frame, and transmits the extracted MAC frame from the MAC transmission Ethernet generation circuit.
[0012]
On the other hand, the packets transferred within the EoMPLS domain are not limited to MPLS packets. (1) MPLS [Non-VPN (Virtual Private Network): with n-stage label] packet, (2) MPLS (VPN: n-stage label) 3) Non-MPLS [Normal Ethernet (R)] packet but specially manages flow, [4] Non-MPLS [Normal Ethernet (R)] packet does not perform special management There are four types, which may coexist on the same physical port.
[0013]
[Problems to be solved by the invention]
In the conventional apparatus, only the Ethernet (R) transfer system is specialized, and only the above-mentioned (3) and (4) can be transferred, and the (1) and (2) MPLS-labeled packet transfer means are provided. do not have. In addition, ordinary Ethernet (R) packets have only a semi-fixed and time-division multiplexed cross-connect table, and are compatible with (1) and (2) MPLS-labeled packet transfer. In a method in which another card is arranged, a destination search is performed, and then the destination card is transferred to the destination card via a switch, there is a problem that the switch band is wasted.
[0014]
Therefore, an object of the present invention is to solve the above-mentioned problems, to suppress a change in a transfer band required in the device, and to reduce an operational load, and a network expansion method used therefor. And to provide the program.
[0015]
[Means for Solving the Problems]
The packet communication device according to the present invention, when resolving the transfer destination based on the combination information of the header information of the input packet and the input physical port number, temporarily converts it into Dtag information indicating the transfer action of the transmitting side and I am carrying around.
[0016]
Another packet communication device according to the present invention is a packet communication device that performs packet transfer using a label in a network,
A protocol identification unit that identifies a protocol of the received main signal packet and determines one of packet transfer and discard processing corresponding to the protocol; and a header of the packet based on header information of the packet transferred from the protocol identification unit. A flow identifying means for identifying a flow and resolving a transfer path and Dtag information indicating a processing method for the identified flow, and an apparatus header for accommodating the label according to a result of the resolution by the flow identifying means, And a packet attribute generating means for generating and outputting attribute information accommodating the Dtag information of the packet in accordance with the solution result of the flow identifying means.
[0017]
Another packet communication device according to the present invention, in addition to the above-described configuration, scheduling for converting the packet into an in-device flow identifier for specifying the processing method of the packet based on the Dtag information contained in the attribute information. Processing means; transmission packet processing determination means corresponding to the in-device flow identifier converted by the scheduling processing means and determining a labeling processing method for a transmission packet; and the label determined by the transmission packet processing determination means Transmission packet assembling means for performing read control of the main signal packet according to the conversion processing method, and performing label insertion / removal and label conversion processing on the read main signal packet to assemble the transmission packet. .
[0018]
According to the network expansion method of the present invention, when the transfer destination is resolved based on the combination information of the header information of the input packet and the input physical port number, it is temporarily converted into Dtag information indicating the transfer action of the transmission side, and the inside of the device is converted. I try to carry around.
[0019]
Another network expansion method according to the present invention is a network expansion method for a packet communication device that performs packet transfer using a label in a network, and identifies a protocol of a received main signal packet to transfer a packet corresponding to the protocol. Deciding any one of the packet processing and the discarding process, and, when the packet transfer is determined, identifying the flow of the packet based on the header information of the transferred packet and processing the transfer path and the identified flow Resolving the Dtag information indicating the tag, a step of adding an in-device header for accommodating the label to the head position of the packet in accordance with the solution result, and a step of adding the Dtag information of the packet in accordance with the solution result. Generating and outputting the attribute information to be accommodated.
[0020]
In another network extension method according to the present invention, in addition to the above steps, a step of converting the packet into an in-device flow identifier for specifying the processing method of the packet based on the Dtag information contained in the attribute information Determining a labeling processing method for a transmission packet corresponding to the converted in-device flow identifier; performing read control of the main signal packet according to the determined labeling processing method; Performing a label insertion / removal process and a label conversion process on the main signal packet to assemble the transmission packet.
[0021]
A program for a network expansion method according to the present invention is a program for a network expansion method for a packet communication device that performs packet transfer using a label in a network. And a process for determining any of packet transfer and discarding processes corresponding to the above, and, when the packet transfer is determined, identifying the flow of the packet based on the header information of the transferred packet and identifying the transfer route and the identification. A process of resolving Dtag information indicating a processing method for a flow, a process of adding an in-device header for accommodating the label to a head position of a packet according to the solution result, and a process of resolving the packet according to the solution result Generating and outputting attribute information accommodating the Dtag information of It is to be executed.
[0022]
According to another embodiment of the present invention, there is provided a program of another network expansion method, which includes, in addition to the above-described processing, an apparatus for specifying the processing method of the packet based on the Dtag information contained in the attribute information. A process of converting to a flow identifier, a process of determining a labeling processing method for a transmission packet corresponding to the converted in-device flow identifier, and processing of the main signal packet according to the determined labeling processing method. It performs read control, performs label insertion / removal and label conversion for the read main signal packet, and assembles the transmission packet.
[0023]
That is, the packet communication device of the present invention enables data transfer of multiple Ethernet (R) packets over an existing network infrastructure, and expands the network to a network that makes the most of the return on upfront investment at a low cost. Is realized. When expansion is performed, no supplementary equipment or overlay network is required, and by efficiently sharing the transport band, an expensive fiber plant is not added, and a communication device excellent in versatility is provided.
[0024]
That is, in the packet communication device of the present invention, when the received packet is determined to be a special packet represented by EoMPLS [Ethernet (R) over Multi Protocol Label Switching] in the interface card on the inbound side (packet receiving side). And means for performing the following packet handling.
[0025]
In the packet communication device of the present invention, when the transfer destination is resolved based on the combination information of the header information of the input packet and the input physical port number, the transfer action on the transmission side (processing method for the transfer path and the identification flow) Is added to the beginning of the input packet, and the input packet is carried around in the device with the Dtag information, without updating the switch processing unit having only a general-purpose packet switch mechanism. The above communication device can be realized. For this reason, in the packet communication device of the present invention, the cost of the device can be reduced and the accommodation (swinging) of an MPLS (Multi Protocol Label Switching) network can be easily realized.
[0026]
Further, in the packet communication device of the present invention, it is not necessary to carry around the output label in the transfer of the input packet in the device, and the transfer overhead in the device can be a fixed length. This makes it possible to reduce the operational load.
[0027]
On the other hand, in the packet communication device of the present invention, in the interface card on the outbound side (packet transmitting side), the flow (Flow) is identified by the Dtag information included in the Object, and the packet transfer shaping (Shaping) is performed according to the line transmission speed. And means for determining a transfer action by using Dtag information as an operation defining pointer in the apparatus.
[0028]
As a result, in the packet communication device of the present invention, even in an operation mode in which multiple protocol types are mixed, since the processing action of the packet is determined by the unified management of only the Dtag information in the device, the management of the entire device is performed. Is simplified, and the output processing is facilitated. Even when an additional service such as a multicast (Multicast) transfer is realized, the transfer processing can be realized by extension of the existing architecture.
[0029]
By adopting the above-described configuration and operation, the present invention enables metro connection between LAN (Local Area Network) and LAN by Optical Ethernet (R), and in order to match the interface speed on the LAN side at 100 Mbps intervals. , And accommodates an execution rate ranging from 100 Mbps to 10 Gbps, and enables high-speed transfer.
[0030]
Further, the present invention realizes a high-performance metro core connection at a 10 Gbps or 100 Gbps class transfer rate using integrated Ethernet (R) and DWDM (Dense Wavelength Division Multiplexing) technology.
[0031]
Services based on MPLS (Multi Protocol Label Switching) are an alternative to the traditional SONET (Synchronous Optical NETwork) RING network infrastructure, making the metro network transparent and guaranteeing the flow on the transport.
[0032]
Features of the present invention include service flexibility, service differentiation and revenue enhancement, bandwidth reuse, bandwidth management with packet granularity, hybrid network elements, scalability solutions, and inexpensive conventional LAN interface decoupling. The present invention has a means for accommodating, supporting a service level agreement, and supporting a virtual LAN.
[0033]
BEST MODE FOR CARRYING OUT THE INVENTION
Next, an embodiment of the present invention will be described with reference to the drawings. FIG. 1 is a block diagram showing a configuration of a packet communication device according to one embodiment of the present invention. In FIG. 1, a packet communication device according to one embodiment of the present invention accommodates multiple Ethernet (R) lines and has Ethernet (R) line accommodation units 1-1 to 1-n having a main signal input / output unit; A plurality of Ethernet (R) line accommodating units that terminate a variety of control protocols and a cross-connect unit 2 that can be cross-connected in units of N × STS (Synchronous Transport Signal) -1 according to the accommodated lines and have a label switch 2a. A monitoring control unit 3 having a function of setting setting information in the 1-1 to 1-n and the cross-connect unit 2 and collecting monitoring items, and a SONET (Synchronous Optical NETwork) line accommodating unit 4-1 to 4-n. It is composed of
[0034]
FIG. 2 is a block diagram showing a main configuration of the Ethernet (R) line accommodating units 1-1 to 1-n of FIG. In FIG. 2, the Ethernet (R) line accommodating units 1-1 to 1-n are illustrated as the Ethernet (R) line accommodating units 1.
[0035]
In FIG. 2, the Ethernet (R) line accommodating unit 1 includes a media access control (MAC) reception Ethernet termination circuit 11, a GFP (Generic Framing Procedure) encapsulation circuit 13, and an STS mapper circuit 17 on the inbound side (packet reception). Side), an STS demapper circuit 18, an GFP decapsulation circuit 14, and an Outbound side (packet transmitting side) including a MAC transmission Ethernet generation circuit 16, and extension circuits (# 1, # 2) 12, 15; It comprises a board CPU (central processing unit) 19 and a recording medium 20.
[0036]
On the inbound side of the Ethernet (R) line accommodating unit 1, the multiple Ethernet (R) is terminated by the MAC receiving Ethernet termination circuit 11, and the MAC frame is encapsulated into the GFP frame by the GFP encapsulation circuit 13 (see FIG. 9). After the STS mapper circuit 17 maps the GFP frame to the STS-1 channel in STS-1 (approximately 50 Mbps) units according to the accommodating bandwidth, the GFP frame is transferred to the OC (Optical Carrier) -N line.
[0037]
The GFP frame mapped by the STS mapper circuit 17 is actually sent to the SONET line accommodating units 4-1 to 4-n through the label switch 2a of the cross-connect unit 2, and is transmitted to the SONET line accommodating unit 4. -1 to 4-n are transferred to the OC-N line.
[0038]
On the Outbound side of the Ethernet (R) circuit accommodating unit 1, the STS demapper circuit 18 demultiplexes the STS-1 channel received from the OC-N line (cross-connect unit 2), demaps it to a GFP frame, and decapsulates the GFP. After the GFP frame is synchronized by the circuit 14 and the GFP frame is extracted, the GFP frame is decapsulated into a MAC frame, and the extracted MAC frame is transmitted from the MAC transmission Ethernet generation circuit 16.
[0039]
Although the above-described Inbound side and Outbound side of the Ethernet (R) line accommodating section 1 enable LAN-to-LAN metro connection, in the present invention, an extension circuit (#) for supporting Service Level Agreement and supporting virtual LAN. 1, # 2) 12, 15 are added-on. The processing of the Ethernet (R) line accommodating unit 1 described above is also realized by a computer (not shown) executing a program stored in the recording medium 20.
[0040]
FIG. 3 is a diagram illustrating a network application model according to an embodiment of the present invention. In FIG. 3, the network application model according to an embodiment of the present invention is capable of accommodating an EoMPLS [Ethernet (R) over Multi Protocol Label Switching] client, which is the same as the network application model according to an embodiment of the present invention. This is a difference from the conventional network model shown in FIG.
[0041]
The packet transferred in the EoMPLS domain shown in FIG. 3 is not limited to an MPLS (Multi Protocol Label Switching) packet, and the packet in the present invention includes: (1) MPLS [Non-VPN (Virtual Private Network): n-stage label] Attached), (2) MPLS (VPN: with n-stage label) packet, (3) non-MPLS [normal Ethernet (R)] packet, which specially manages the flow, (4) non-MPLS [ There are four types of normal Ethernet (R) packets that do not perform any special management, and these may be mixed in the same physical port.
[0042]
In the conventional communication device, only the Ethernet (R) transfer system is specialized, and only the above (3) and (4) can be transferred, and the (1) and (2) MPLS-labeled packet transfer means Do not have. In addition, ordinary Ethernet (R) packets have only a semi-fixed and time-division multiplexed cross-connect table, and are compatible with (1) and (2) MPLS-labeled packet transfer. In the method in which another card is arranged, a destination search is performed, and then the destination card is transferred to the destination card via the switch, there is a problem that the switch band is wasted.
[0043]
Here, in the MPLS labeled packet transfer, a method of associating an IP (Internet Protocol) address with information of a lower layer called a label and transferring the packet by referring only to the label, and the label is a destination of the packet to the IP address Is data for identifying on the MPLS network.
[0044]
That is, in FIG. 3, the nodes (SONET NEs) 51 and 52 are multiple Ethernet (R) @FE [100 Mbps Fast Ethernet (R)], GE [1 Gbps Ethernet (R)], and EoMPLS [Ethernet (R) over Multi]. Protocol Label Switching] at an appropriate line speed.
[0045]
The node 51 is a node for generating a VC, maps various types of Ethernet® (FE / GE / 10GE) to VC-3-Nv, and employs GFP as a relay frame. The node 52 is a node for a VC end point, performs demapping by an inverse multiplexing method, and adopts a synchronization method based on HEC (Header Error Control) operation of GFP. The nodes (NE) 61 and 62 are relay nodes, and process packets as VC-3 (VC-4) paths without being aware of VC in packets to which various types of Ethernet (R) are mapped.
[0046]
The node 51 transmits, to the node 61, a GFP frame in which a label (Label # 1) is added (Label Push) to the MAC frame of the received Ethernet (R) packet. The node 61 transfers to the node 62 based on the label (Label # 1) of the GFP frame, and the node 62 transfers to the node 52 based on the label (Label # 2) of the GFP frame. The node 52 extracts the MAC frame by removing the label (Label # 3) of the received GFP frame, and transmits the extracted MAC frame to the outside.
[0047]
In this case, at the node 61, the label (Label # 1) is replaced with the label (Label # 2) (Label Swap), and at the node 62, the label (Label # 2) is replaced with the label (Label # 3) (Label Swap). .
[0048]
In the present embodiment, in order to solve the above-mentioned problem, as shown in FIG. 2, the extension circuits (# 1, # 2) 12, 15 are provided to handle packets labeled by EoMPLS. Becomes possible.
[0049]
FIG. 4 is a block diagram showing a detailed configuration of the Ethernet (R) line accommodating unit 1 shown in FIG. 2 on the inbound side, and FIG. 5 is a detailed configuration of an Ethernet (R) line accommodating unit 1 shown in FIG. 2 on the Outbound side. FIG. The configurations of the extension circuit (# 1) 12 and the extension circuit (# 2) 15 will be described with reference to FIGS.
[0050]
In FIG. 4, the MAC reception Ethernet termination circuit 11 includes a protocol identification unit 11a, the extension circuit (# 1) 12 includes a flow identification / route resolution unit 12a and a classifier table (Table) 12b, and the GFP encapsulation circuit 13 includes a device. An inner header providing unit 13a and a packet attribute generating unit 13b are provided.
[0051]
The protocol identification unit 11a has a function for determining packet transfer or discard processing corresponding to a link phase and a protocol type. From the packet header transferred by the protocol identification unit 11a, the flow identification / route resolution unit 12a uses the flow of the packet (specific header information is shared, and a plurality of unidirectional packets subjected to the same routing process are collected). (Or label), and a processing method (Dtag information) corresponding to the transfer path and the identification flow (or identification label) is solved by referring to the table (Classfire table 12b). 13a and a function to instruct the packet attribute generation unit 13b.
[0052]
Here, the Classfire table 12b stores header information and Dtag information in association with each other. Further, Dtag, Action, QoS (Quality of Service), Route,... Are transmitted from the flow identification / route resolution unit 12a to the in-device header providing unit 13a and the packet attribute generation unit 13b as instruction contents.
[0053]
The in-device header adding unit 13a adds an in-device header for accommodating a label to the head position of the packet according to the instruction of the flow identification / route resolution unit 12a, and the packet attribute generation unit 13b issues the instruction of the flow identification / route resolution unit 12a. Depending on the content, attribute information of the packet containing the Dtag information is generated.
[0054]
5, the extension circuit (# 2) 15 includes a packet scheduling unit 15a and a flow table (Table) 15b, and the MAC transmission Ethernet generation circuit 16 includes a transmission packet processing determination unit 16a, a transmission packet assembling and transmission packet multiplexing unit 16b. And an action table (Table) 16c.
[0055]
The packet scheduling processor 15a refers to the Flow table 15b based on the Dtag information contained in the received packet attribute information, resolves the in-device flow identifier (Flow ID) of the packet, and resolves each in-device flow identifier. The packet attribute information is queued (stored in the memory), and shaping (Shaping) by the Dual Token Bucket method based on the peak rate and the average rate and memory reading (by memory reading by the priority scheduling) are performed.
[0056]
Here, the Flow table 15b is a table configuration that manages internal device flow identifiers using Dtag information as an address. By configuring the internal device flow identifiers with a plurality of link pointers, one Dtag information is stored in a plurality of link pointers. It is also possible to assign a flow process to a line port, and it is possible to support one-to-many (multicast) transfer.
[0057]
That is, by associating the Dtag information with the in-apparatus flow identifiers in one-to-N correspondence (N is a positive integer), N pieces of in-apparatus flow identifiers are read from the Flow table 15b by one piece of Dtag information, and the N in-apparatus flow identifiers are read out. A flow process for a line port corresponding to each flow identifier can be assigned.
[0058]
The transmission packet processing determination unit 16a refers to the Action table 16c based on the in-device flow identifier contained in the packet attribute information received from the packet scheduling processing unit 15a, and determines a labeling processing method (Action) for the transmission packet. . Here, the Action table 16c is a memory having a Label Action Entry for setting a packet header process using the in-device flow identifier as an address. The Label Action Entry is managed for each in-apparatus flow identifier included in the object from the packet scheduling unit 15a.
[0059]
The transmission packet assembling and transmission packet multiplexing unit 16b controls reading of the main signal packet word-demultiplexed by the STS demapper circuit 18 in accordance with the labeling processing method determined by the transmission packet processing determining unit 16a. After performing label insertion / removal or label conversion processing on the, the transmission packet is assembled and the transmission packet is transmitted.
[0060]
6 and 7 are flowcharts showing the basic processing of the Ethernet (R) line accommodating unit 1 of FIG. 2, and FIG. 8 is a diagram showing the flow of the ingress processing of the Ethernet (R) line accommodating unit 1 of FIG. FIG. 9 is a diagram showing a flow of the egress processing of the Ethernet (R) line accommodating unit 1 of FIG. The basic processing of the Ethernet® line accommodating unit 1 will be described with reference to FIG. 2 and FIGS.
[0061]
6 shows processing on the Inbound side of the Ethernet (R) line accommodating unit 1, and FIG. 7 shows processing on the Outbound side of the Ethernet (R) line accommodating unit 1. 6 to 9 are also realized when the computer of the Ethernet (R) line accommodating unit 1 executes the program of the recording medium 20.
[0062]
The protocol identifying unit 11a refers to the protocol ID of the received packet header to identify whether the packet is a control packet or a main signal packet (protocol determination and control packet separation) (step S1 in FIG. 6). When the protocol identification unit 11a identifies the packet as a main signal packet in this identification processing, it sends the packet header to the flow identification / route resolution unit 12a, and when identifies the packet as a control packet, the on-board CPU 19 mounted on the board. Thus, processing such as link establishment is performed. Here, the main signal packet corresponds to a normal Ethernet (R) packet and an Ethernet (R) MPLS packet.
[0063]
When receiving the packet header from the protocol identification unit 11a, the flow identification / route resolution unit 12a performs a search process of the classifier table 12b using an arbitrary combination of a plurality of fields in the packet header as a search key (step S2 in FIG. 6).
[0064]
As a result of the Multi-Field search, a FEC ID (Forwarding Equivalent Class Identification: an identifier for determining a transfer destination route), a PLC ID (Policing Identity: an identifier for determining a flow to be policed), and a CLS ID [Classic Identity: (Quality of Service) Identifier that determines the class], STAT ID (Statistical Information Counter Identification: an identifier that defines the unit of counting statistical information), PCOLOR (Pre-defined Color: Pre-defined Color: set in the packet before performing policing processing) Priority) is the solution The target.
[0065]
The ID information resolved by the flow identification / route resolution unit 12a is distributed to an in-device header adding unit 13a and a packet attribute generating unit 13b in a word multiplexing circuit (not shown), where word multiplexing and time slot allocation are performed. , And a predetermined position of the Object, and carried to a packet processing unit on the Outbound side via a switch (not shown) (Steps S3 and S4 in FIG. 6).
[0066]
The object received via the switch carries the Dtag information resolved on the inbound side. The packet scheduling processing unit 15a performs QoS control such as shaping (output regulation) processing or scheduling (output order determination) processing for each flow based on the Dtag information. Here, it is assumed that the QoS mechanism provided differs depending on the service model and operation mode required for the device. However, by setting policing and shaping parameters in advance for each Dtag information, shaping and scheduling can be performed. This is performed in units of labels or in units of flows (step S11 in FIG. 7).
[0067]
In order to realize the above function, the extension circuit (# 2) 15 has a Flow table 15b for assigning an arbitrary processing flow number [= internal flow identifier (Flow ID)] from Dtag information. I have. The Flow table 15b is a table configuration that manages an in-apparatus flow identifier using Dtag information as an address. In addition, by using a configuration in which the in-device flow identifiers are linked by a plurality of link pointers, one Dtag information can also assign a flow process to a plurality of line ports, and can support one-to-many (multicast) transfer. it can.
[0068]
The transmission packet processing determination unit 16a performs a process of determining a process for the packet based on the in-device flow identifier (one or a plurality) converted based on the Dtag information in the packet scheduling processing unit 15a. The MAC transmission Ethernet generation circuit 16 has an Action table 16c for determining a packet process for each processing flow (in-device flow identifier). The Action table 16c is a memory having a Label Action Entry for setting a packet header process using the in-device flow identifier as an address. The Label Action Entry is managed for each in-apparatus flow identifier included in the object from the packet scheduling unit 15a.
[0069]
The action for the packet is determined by obtaining the Label Action Entry by referring to the Action Table 16c using the in-device flow identifier as an address. The Label Action Entry is composed of a 15-bit action entry and a 20-bit Label entry. The Action entry is used to derive a label, EXP, and TTL to be inserted into the output Shim-Header, and the EXP and TTL values to be inserted are added to a header in the device and notified from the inbound side via a switch, and an Outbound. Any of the values registered in advance in the Action table 16c provided on the side can be selected (step S13 in FIG. 7).
[0070]
The MAC transmission Ethernet generation circuit 16 acquires the Label Action Entry by looking up the Action table 16c, and determines the action for the packet. Then, the packet processing corresponding to the action is performed (steps S12 and S14 in FIG. 7).
[0071]
On the inbound side of the Ethernet (R) line accommodating unit 1, the Dtag information is resolved for the received MAC packet (step S21 in FIG. 8), and the Dtag information is mounted on the in-device header of the MAC packet.
[0072]
The Outbound side of the Ethernet (R) line accommodating unit 1 uses the Dtag information to resolve the destination port, identify the Flow, determine the label to be stacked, etc., generate a GFP packet (step S22 in FIG. 8), and generate an EoMPLS domain. And to the SONET network.
[0073]
Also, on the inbound side of the Ethernet (R) line accommodating unit 1, the label is removed from the GFP packet received from the EoMPLS domain or the SONET network, the MAC packet is extracted, and the Dtag information is resolved (step S31 in FIG. 9).
[0074]
The Outbound side of the Ethernet (R) line accommodating unit 1 uses the Dtag information to resolve the destination port, identifies the flow, and assembles and outputs the MAC packet (step S32 in FIG. 9).
[0075]
The label switch 2a of the cross-connect unit 2 performs the same processing operation as that on the Outbound side of the Ethernet (R) line accommodating unit 1 described above, and outputs the Dtag information from the Ethernet (R) line accommodating units 1-1 to 1-n. A label is written in the in-apparatus header added to the head of the packet to which the tag has been added, and the label is sent to the SONET line accommodating units 4-1 to 4-n, and the Dtag information from the SONET line accommodating units 4-1 to 4-n is written. And the packets to which the labels have been added are sent as they are to the Ethernet (R) line accommodating units 1-1 to 1-n. The Ethernet (R) line accommodating units 1-1 to 1-n perform the same processing operation as the above Outbound side, and transmit the MAC packet.
[0076]
As described above, in the present embodiment, the interface card on the inbound side has means for performing the following packet handling when it is determined that the received packet is a special packet represented by EoMPLS.
[0077]
That is, in this embodiment, when the transfer destination is resolved based on the combination information of the header information of the input packet and the input physical port number, it is temporarily converted into Dtag information which is a transfer action on the transmission side, and the inside of the device is converted. By carrying around, it is possible to realize without a revision of the switch processing unit having only a general-purpose packet switch mechanism. For this reason, in the present embodiment, it is possible to reduce the apparatus cost and easily realize the accommodation (rolling) of the MPLS network.
[0078]
Further, in this embodiment, it is not necessary to carry the output label in the transfer within the device, and the transfer overhead in the device may be a fixed length. Therefore, it is possible to suppress a change in the transfer band required in the device, and to reduce an operation load.
[0079]
On the other hand, in the present embodiment, in the interface card on the Outbound side (packet transmitting side), Flow identification is performed using Dtag information included in the object, and the packet transfer is performed as Shaping / Scheduling. And means for determining a transfer action.
[0080]
As a result, in the present embodiment, even in an operation mode in which multiple protocol types are mixed, in the device, the processing action of the packet is determined by the unified management of only the Dtag information, so that the management of the entire device is simplified. Output processing is facilitated. Even when an additional service such as Multicast transfer is realized, the transfer processing can be realized by extension of the existing architecture.
[0081]
【The invention's effect】
As described above, according to the present invention, when the transfer destination is resolved based on the combination information of the header information of the input packet and the input physical port number, it is temporarily converted into Dtag information indicating the transfer action of the transmission side and By carrying around, it is possible to suppress the fluctuation of the transfer band required in the device and to reduce the operational load.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a configuration of a packet communication device according to an embodiment of the present invention.
FIG. 2 is a block diagram illustrating a main configuration of an Ethernet (R) line accommodating unit in FIG. 1;
FIG. 3 is a diagram illustrating a network application model according to an embodiment of the present invention.
FIG. 4 is a block diagram illustrating a detailed configuration of an Ethernet (R) line accommodating unit in FIG. 2 on an Inbound side;
FIG. 5 is a block diagram showing a detailed configuration of an outbound side of the Ethernet (R) line accommodating unit in FIG. 2;
FIG. 6 is a flowchart showing a basic process of an Ethernet (R) line accommodating unit in FIG. 2;
FIG. 7 is a flowchart showing basic processing of the Ethernet (R) line accommodating unit in FIG. 2;
FIG. 8 is a diagram showing a flow of an ingress process of the Ethernet® line accommodating unit of FIG. 2;
9 is a diagram showing a flow of an egress process of the Ethernet® line accommodating unit in FIG. 2;
FIG. 10 is a diagram showing a network application model according to a conventional example.
FIG. 11 is a diagram showing a GFP encapsulation process.
[Explanation of symbols]
1,1-1-1-n Ethernet (R) line accommodating unit
2 Cross Connect Department
2a Label switch
3 Monitoring control unit
4-1 to 4-n SONET line accommodation unit
11 MAC reception Ethernet termination circuit
12, 15 Extension circuit (# 1, # 2)
13 GFP encapsulation circuit
14 GFP decapsulation circuit
16 MAC transmission ether generation circuit
17 STS mapper circuit
18 STS demapper circuit
19 On-board CPU
20 Recording media
