JP2002026958A - マルチレイヤスイッチのアドレス管理システム - Google Patents

Abstract

(57)【要約】 【課題】 本発明はマルチレイヤスイッチのアドレス管
理システムに関し、複数のサービスを１つの装置で提供
できるマルチレイヤスイッチのアドレス管理システムを
提供することを目的としている。 【解決手段】 各ＬＡＮ間がＡＴＭネットワーク１２を
介して接続されたシステムにおいて、ＡＴＭネットワー
ク１２内に各サービスとカスタマに接続されるＶＣＩと
を対応付けるテーブル４０を設け、ＡＴＭネットワーク
１２内のコアネットワーク１３内にコアプロトコルを用
い、Ｇｌｏｂａｌ ＩＰサービス、ＩＰＣＵＧサービ
ス、ＭＡＣブリッジングサービスのフォーマットをカプ
セル化してフォワーディングを行ない、コアネットワー
ク１３から出る場合は、カプセル化されたパケットをデ
カプセル化するように構成される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はマルチレイヤスイッ
チのアドレス管理システムに関し、更に詳しくはキャリ
ア（通信事業者）のＡＴＭネットワーク上でＧｌｏｂａ
ｌ ＩＰサービス、ＩＰ ＣＵＧサービス、ＭＡＣブリ
ッジングサービス等の複数のレイヤにまたがる複数のサ
ービスのアドレスをエッジノード（ネットワークとＬＡ
Ｎ間の境界に位置するノード）で管理するマルチレイヤ
スイッチのアドレス管理システムに関する。

【０００２】

【従来の技術】キャリアのＡＴＭネットワーク上では、
各種のサービスが行われている。この種のサービスで
は、例えばＧｌｏｂａｌ ＩＰサービス、ＩＰ ＣＵＧ
（Ｃｌｏｓｅｄ Ｕｓｅｒ Ｇｒｏｕｐ）サービス、Ｍ
ＡＣ（Ｍｅｄｉａ ＡｃｃｅｓｓＣｏｎｔｒｏｌ）ブリ
ッジングサービス等の複数のレイヤにまたがるサービス
が行われている。

【０００３】図２３はＧｌｏｂａｌ ＩＰサービスのネ
ットワークを示す図である。ＬＡＮ（Ｌｏｃａｌ Ａｒ
ｅａ Ｎｅｔｗｏｒｋ）１１に属する端末２１からＬＡ
Ｎ１４に属する端末２９に向けて通信を行なう場合、汎
用ルータ２３、エッジノード２４、エッジノード２７、
汎用ルータ２８がそれぞれＩＰホップになり、ＩＰアド
レスによってフォワーディング（前進）され、最終端末
２９に到達する。ここで、ＩＰホップとはＩＰのヘッダ
の中にあるＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｅａｄ）の１つ
のルータなりワークステーションを通過した時に１つ減
算するものである。そして、０になったパケットは廃棄
される。ここで、使用されるＩＰアドレスはキャリアが
管理しているＩＰアドレスの中からカスタマ（顧客）に
割り振られる。エッジノード２４において、３２はコア
アドレスであり、該コアアドレスに基づいてパスを設定
する。エッジノード２７において、３４はコアアドレス
であり、該コアアドレスに基づいてパスを設定するもの
である。

【０００４】図２４はＩＰ ＣＵＧサービスのネットワ
ークを示す図である。図２３と同一のものは、同一の符
号を付して示す。ここでは、イントラネット（１企業内
で閉じたネットワーク）やエキストラネット（閉じられ
たネットワークであるが、キャリアと共同で使用するネ
ットワーク）のような閉じられた空間におけるＴＣＰ／
ＩＰ（ネットワーク用の通信プロトコル）接続を提供す
るＩＰ ＣＵＧの概要を示している。

【０００５】ＬＡＮ１１に属する端末２１からＬＡＮ１
４に属する端末２９に向けて通信を行なう場合、汎用ル
ータ２３、エッジノード２４、エッジノード２７、汎用
ルータ２８がそれぞれＩＰホップになり、ＩＰアドレス
によってフォワーディングされ、最終端末２９に到達す
る。ここで、使用されるＩＰアドレスは、カスタマが管
理しているＩＰアドレスを使用することがあるため、同
じＩＰアドレスを別のＣＵＧ空間で使用することもあ
る。

【０００６】図２５はＭＡＣブリッジングサービスのネ
ットワークを示す図である。図２４と同一のものは、同
一の符号を付して示す。図はＴｈｅ ＡＴＭ Ｆｏｒｕ
ｍＬＡＮＥ仕様を提供するＭＡＣブリッジングサービス
の概要を示している。ＬＡＮ１１に属する端末２１から
同じＬＡＮ１１に属するＷＡＮ（Ｗｉｄｅ Ａｒｅａ
Ｎｅｔｗｏｒｋ）を経由して接続される端末２９に向け
て通信を行なう場合、スイッチングハブ２３’、エッジ
ノード２４’、エッジノード２７’、スイッチングハブ
２８’がそれぞれレイヤ２ブリッジを行ない、ＭＡＣア
ドレスによってフォワーディングされ、最終端末２９に
到達する。図２５において、３２’はエッジノード２
４’内に設けたＡＴＭアドレス、３４’はエッジノード
２７’内に設けたＡＴＭアドレスである。

【０００７】

【発明が解決しようとする課題】前述したサービスにお
いて、１つのノードで複数のサービスを提供する場合に
は、以下に示すような問題がある。

【０００８】（問題点１）ＩＰアドレス又はＭＡＣアド
レスのうち、１つのアドレスを持っているだけでは、Ｇ
ｌｏｂａｌ ＩＰサービス、ＩＰ ＣＵＧサービス、Ｍ
ＡＣブリッジングサービス等の全てのサービスを提供で
きない。

【０００９】（問題点２）１つのノード内に論理的な空
間を分けて、Ｇｌｏｂａｌ ＩＰサービス、ＩＰＣＵＧ
サービス、ＭＡＣブリッジングサービス等のサービス毎
に分けた場合、コアネットワーク内もサービス毎にルー
チング処理が必要となり、メモリ量の増大とネットワー
ク管理の複雑性を生じる。

【００１０】（問題点３）１つのノード内に論理的な空
間を分けて、Ｇｌｏｂａｌ ＩＰサービス、ＩＰＣＵＧ
サービス、ＭＡＣブリッジングサービス等のサービス毎
に分けた場合、コアネットワーク側の接続ＶＣ（Ｖｉｒ
ｔｕａｌ Ｃｈａｎｎｅｌ）が最低サービス毎に必要と
なり、ＶＣ数が不足する。

【００１１】本発明は、このような課題に鑑みてなされ
たものであって、前記した複数のサービスを１つの装置
で提供できるマルチレイヤスイッチのアドレス管理シス
テムを提供することを目的としている。

【００１２】

【課題を解決するための手段】（１）図１は本発明の原
理ブロック図である。図２３と同一のものは、同一の符
号を付して示す。図において、１１はＬＡＮ、１２はこ
れらＬＡＮ１１と接続されるＡＴＭネットワーク、１４
は該ＡＴＭネットワーク１２と接続されるＬＡＮであ
る。ＬＡＮ１１において、２１は端末、２３は汎用ルー
タ、３０はＡＴＭスイッチである。ＬＡＮ１４におい
て、２９は端末、２８は汎用ルータ、３１はＡＴＭスイ
ッチである。

【００１３】ＡＴＭネットワーク１２において、１３は
該ＡＴＭネットワーク１２内に設けられたコアネットワ
ークである。４０はＡＴＭネットワーク１２内に設けら
れたルーチングテーブルである。コアネットワーク１３
において、２４’は汎用ルータ２３又はＡＴＭスイッチ
３０と接続されるエッジノード、２５は該エッジノード
２４’と接続されるコアノード、２７’は該コアノード
２５と接続されるエッジノードである。該エッジノード
２７’は、汎用ルータ２８及びＡＴＭスイッチ３１と接
続されている。エッジノード２４’は、ルーチングテー
ブル４０を参照して、コアノード２５内のパスを設定す
る。

【００１４】エッジノード２４’において、３２はコア
アドレス、３２’はＡＴＭアドレスである。エッジノー
ド２７’において、３４はコアアドレス、３４’はＡＴ
Ｍアドレスである。コアノード２５において、３５はコ
アアドレスである。なお、コアノード２５は本発明に必
須のものではなく、エッジノード２４’と２７’間を直
接接続するようにしてもよい。

【００１５】このような構成にすれば、以下の効果が得
られる。各サービスとカスタマに接続するＶＣＩを対応
付けるルーチングテーブル４０を設けることにより、１
ノードで複数のサービスの提供が可能になる。具体的に
は、カスタマからデータ受信時はそのＶＣＩに対応した
サービスのフォーマットで分析することができ、フォワ
ーディングを行なう。カスタマへのデータ送信時は、そ
のＶＣＩに対応したサービスのフォーマットでデータを
送信することにより、カスタマにパケットを伝達する。

【００１６】ＧｌｏｂａｌＩＰサービス、ＩＰ ＣＵＧ
サービス、ＭＡＣブリッジングサービス等の各サービス
のパケットが、コアネットワーク１３内ではコアプロト
コルにカプセル化されることにより、各サービスを意識
することなく、統一化されたコアプロトコルのみで制御
される。また、統一化されたコアプロトコルでのみ接続
すればよいので、エッジノード２４’、２７’からコア
ネットワーク１３に接続するＶＣ（Ｖｉｒｔｕａｌ Ｃ
ｏｎｎｅｃｔｉｏｎ）数も削減可能である。

【００１７】（２）請求項２記載の発明は、前記コアネ
ットワーク内はコアＩＤを使用して、階層的にフォワー
ディングすることを特徴とする。このように構成すれ
ば、コアネットワーク１３内をコア情報（コアアドレス
＋サービスインフォメーション）を使用して、階層的に
フォワーディングすることにより、現状のＩＰアドレス
の分散状態をキャリアによって管理されるアドレス構造
となる。階層化による利点で、接続するカスタマが増え
ても経路を集約できるため、検索するフォワーディング
テーブルの増大を抑えることができる。

【００１８】（３）請求項３記載の発明は、前記コアネ
ットワーク内にコアアドレスを設け、該コアアドレス
は、ユニキャスト用のアドレスフォーマットと、マルチ
キャスト用のアドレスフォーマットを用いることを特徴
とする。

【００１９】このように構成すれば、コアＩＤの中のコ
アアドレスをユニキャスト用とマルチキャスト用の２つ
のアドレスフォーマットを用いることにより、通常の１
対１にデータを配信するユニキャスト以外に１対多にデ
ータを配信するマルチキャストデータパケットを明確に
識別でき、その配信先となる複数の宛先に向けてデータ
コピー処理を行なうことができる。

【００２０】また、本発明において前記コアネットワー
ク内のアドレステーブルに振る舞いを記述するフラグ
（Ｍ，Ｃ，Ｕ）によって処理の簡易化／アドレステーブ
ルの縮小化を図るように構成すれば、処理の簡易化／ア
ドレステーブルの縮小化を図ることができる。

【００２１】

【発明の実施の形態】以下、図面を参照して本発明の実
施の形態例を詳細に説明する。コアアドレスは、ユニキ
ャスト用のアドレスフォーマットとマルチキャスト用の
アドレスフォーマットの２つを用いる。このコアアドレ
スを含むコアＩＤ（コアアドレスとサービスインフォメ
ーション）の情報要素は、以下に示すアドレス構造を採
る。

【００２２】 コアアドレスの要素 ・Ｆｏｒｍａｔ Ｐｒｅｆｉｘ：（ユニキャスト通信及びマルチキャ スト通信） ・Ｔｏｐ Ｌｅｖｅｌ Ａｇｇｒｅｇａｔｏｒ：（ユニキャスト通 信） ・Ｃｏｕｎｔｒｙ Ｃｏｄｅ ：（ユニキャスト通信） ・Ａｒｅａ Ｎｕｍｂｅｒ ：（ユニキャスト通信） ・Ｅｄｇｅ Ｎｏｄｅ Ｎｕｍｂｅｒ：（ユニキャスト通信） ・Ｅｄｇｅ Ｄｅｖｉｃｅ Ｎｕｍｂｅｒ：（ユニキャスト通信） ・フラグ ：（マルチキャスト通信） ・スコープ ：（マルチキャスト通信） ・ＭＣ Ｇｒｏｕｐ ＩＤ（ＭＣ Ｂｌｏｃｋ ＋ＭＣ Ｇｒｏｕ ｐ） ：（マルチキャスト通信） サービスインフォメーションの要素 ・Ｒｏｕｔｅ ＩＤ ：（ユニキャスト通信及びマルチキャ スト通信） ・ＳＴ（Ｓｅｒｖｉｃｅ Ｔｙｐｅ）：（ユニキャスト通信及びマル チキャスト通信） ・ＣＵＧ ＩＤ ：（ユニキャスト通信及びマルチキャ スト通信） 具体的なコアＩＤのフォーマットについては、以下に示
す。

【００２３】図２はコアプロトコルパケットフォーマッ
トの構成例を示す図である。このフォーマットは、前述
したカプセルに付いているヘッダの構成を示しており、
コアネットワーク１３内はこのヘッダだけで転送され
る。

【００２４】図において、Ｖｅｒｓｉｏｎは４ビットの
コアプロトコルバージョン番号であり、ここではＶｅｒ
ｓｉｏｎ＝１とする。Ｔｒａｆｆｉｃ Ｃｌａｓｓは、
８ビットの符号なし整数であり、図３に示すように用い
られる。ここで、Ｐｒｉｏは４ビットの符号なし整数で
あり、コアプロトコルＰＤＵ（Ｐａｃｋｅｄ Ｄａｔａ
Ｕｎｉｔ）の優先度を示す。優先度識別のために、以
下の値を使用する。

【００２５】 ０（００００Ｂ）Ｐｒｉｏ−０ＰＤＵ ８（１０００Ｂ）Ｐｒｉｏ−８ＰＤＵ １０（１０１０Ｂ）Ｐｒｉｏ−１０ＰＤＵ １２（１１００Ｂ）Ｐｒｉｏ−１２ＰＤＵ ここで、Ｂは２進を示し、他の値は未定義である。

【００２６】図３において、次のＣＵはＣｕｒｒｅｎｔ
ｌｙ Ｕｎｕｓｅｄである。次のＨＬＳＩは８ビットの
Ｈｉｇｈｅｒ Ｌａｙｅｒ Ｓｅｒｖｉｃｅ Ｉｄｅｎ
ｔｉｆｉｅｒであり、コアプロトコルによって運ばれる
上位プロトコル及びサービスを識別する。割り当ては以
下の通りである。

【００２７】０〜１５ ユーザサービス １６〜３１ ＣＣＭＰ（Ｃｏｒｅ Ｃｏｎｔｒｏｌ
ＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ：ユーザサービ
ス対応） ３２〜２５５ その他のプロトコル（制御用プロトコル
等） 具体的には、以下の値をとる。

【００２８】 ０ Ｇｌｏｂａｌ ＩＰサービス １ ＩＰ ＣＵＧサービス ２ ＭＡＣ ＣＵＧサービス ３ 仮想リンク交換サービス １５ 情報設定用に予約 １６ ＣＣＭＰ（Ｇｌｏｂａｌ ＩＰ、共通） １７ ＣＣＭＰ（ＩＰ ＣＵＧ） １８ ＣＣＭＰ（ＭＡＣ ＣＵＧ） ３２ ＮＨＲＰ（Ｎｅｘｔ Ｈｏｐ Ｒｅｓｏｌｕ
ｔｉｏｎ Ｐｒｏｔｏｃｏｌ） ３３ ＲＳＶＰ（Ｒｅｓｏｕｃｅ Ｒｅｓｅｒｖａ
ｔｉｏｎ Ｐｒｏｔｏｃｏｌ） ３４ ＵＣルーチングプロトコル用に予約 ３５ ＭＣルーチングプロトコル その他の値 将来のために予約 次のＨＯＰ Ｌｉｍｉｔは８ビットの符号なし整数であ
り、コアアドレスＰＤＵを中継するノードによって１ず
つ減らされる。１つ１つのノードで自律的にテーブルを
もって次に転送する先を決めていく場合、あるテーブル
の作り方によってはループを含む可能性がある。そこ
で、ループができた場合に輻輳することを防止するた
め、１つずつ減らしていき、ＨＯＰ Ｌｉｍｉｔ値が０
又は１のＰＤＵは受信ノードにおいて廃棄されるように
なっている。

【００２９】次に、Ｓｏｕｒｃｅ ＩＤは１２８ビット
の送信元ＩＤであり、ソースコアアドレスとソースサー
ビスインフォメーションより構成されている。次に、Ｄ
ｅｓｔｉｎａｔｉｏｎ ＩＤは１２８ビットの送信先Ｉ
Ｄであり、ディスティネーションコアアドレスとディス
ティネーションサービスインフォメーションより構成さ
れている。

【００３０】図４はユニキャストコアアドレスのフォー
マットの構成例を示す図であり、Ｓｏｕｒｃｅ ＩＤ又
はＤｅｓｔｉｎａｔｉｏｎ ＩＤ内のフォーマットを示
す。ＵＣはＷCL点の個々のインタフェースのアドレスを
表す。ＵＣは、宛先コアアドレス（ＤＣＡ）及び送信元
コアアドレス（ＳＣＡ）に用いられる。ＵＣはＩＰV6
（バージョン６）アドレッシングにおけるＡｇｇｒｅｇ
ａｔａｂｌｅ Ｇｌｏｂａｌ Ｕｎｉｃａｓｔ Ａｄｄ
ｒｅｓｓを基にして構成される。コアアドレスの各フィ
ールド毎にバイナリエンコーディングを行ない、以下の
通りコーディングされる。但し、予約部の２進８ビット
としてコーディングされる。

【００３１】図において、ＦＰはＦｏｒｍａｔ Ｐｒｅ
ｆｉｘで、Ａｇｇｒｅｇａｔａｂｌｅ Ｇｌｏｂａｌ
Ｕｎｉｃａｓｔ Ａｄｄｒｅｓｓは００１Ｂである。次
のＴＬＡはＴｏｐ Ｌｅｖｅｌ Ａｇｇｒｅｇａｔｏｒ
であり、ＩＰV6アドレスにおけるＴＬＡ相当部として予
約される。そして、全て“０”コーディングとする。

【００３２】次のＰＣは、Ｐｒｏｖｉｄｅｒ Ｃｏｄｅ
であり、０をデフォルト値とする。次のＣＣはＣｏｕｎ
ｔｏｒｙ Ｃｏｄｅであり、コアアドレスでの国番号フ
ィールドである。次のＡｒｅａはエリアナンバであり、
コアアドレスでの地域番号フィールドである。

【００３３】次のＥＮはＥｄｇｅ Ｎｏｄｅ Ｎｕｍｂ
ｅｒであり、インタフェースを収容するエッジノードの
番号である。次の、ＥＤはＥｄｇＥ Ｄｅｖｉｃｅ Ｎ
ｕｍｂｅｒであり、インタフェースを収容するエッジデ
バイスの番号である。

【００３４】図５はマルチキャストコアアドレスのフォ
ーマットの構成例を示す図である。ＭＣ（マルチキャス
ト）は、複数の宛先に向けられる宛先アドレス（ＤＣ
Ａ）として用いられる。ＭＣはＩＰV6アドレッシングに
おけるマルチキャストアドレスを基にして構成される。

【００３５】図において、ＦＰはＦｏｒｍａｔ Ｐｒｅ
ｆｉｘであり、マルチキャストアドレスの場合、１１１
１１１１１Ｂである。次のＦｌａｇは、ＩＡＮＡ（イン
ターネットに関するアドレス管理部）から割り当てられ
たアドレスではないことを示すために以下の通りコード
化する。

【００３６】０００１Ｂ 次のＳｃｏｐｅはマルチキャストアドレスのスコープ
（配送範囲）をローカルとして定義するために、５（Ｓ
ｉｔｅ−ｌｏｃａｌ Ｓｃｏｐｅ）を値として用い、以
下の通りコード化する。

【００３７】０１０１Ｂ 次のＲｅｓｖは全て“０”エンコーディングする。次の
ＭＣ Ｇｒｏｕｐ ＩＤは３０ビットの符号なし整数で
あり、マルチキャストグループアドレス番号である。Ｍ
ＣＲＳ（Ｍｕｌｔｉ Ｃａｓｔ Ｒｏｕｔｅ Ｓｅｒｖ
ｅｒ）により１つのマルチキャストグループに対して１
つのグループアドレス番号が付与される。

【００３８】図６はＭＣ Ｇｒｏｕｐ ＩＤの構成例を
示す図である。図において、Ｒｅｓｖは予約、ＭＣ Ｂ
ｌｏｃｋはＭＣブロック、ＭＣ ＧｒｏｕｐはＭＣグル
ープである。

【００３９】図７はサービスインフォメーションのフォ
ーマットの構成例を示す図である。Ｒｏｕｔｅ ＩＤは
８ビットであり、ルート情報に関する将来の拡張のため
に予約するものである。全て“０”コーディングで、処
理はドントケアである。

【００４０】次のＳＴは４ビットの符号なし整数であ
り、以下のようにサービスタイプを識別するものであ
る。 ０ Ｇｌｏｂａｌ ＩＰサービス １ ＩＰ ＣＵＧ サービス ２ ＭＡＣ ＣＵＧ サービス ３〜１４ 将来のために予約するものである。

【００４１】１５ 情報設定用に予約するもので
ある。 次のＣＵＧ ＩＤは、２０ビットの符号なし整数であ
り、送信元或いは宛先に所属するＣＵＧの識別を行な
う。Ｇｌｏｂａｌ ＩＰサービスは０とする。

【００４２】図８はＧｌｏｂａｌ ＩＰ・ＩＰ ＣＵＧ
サービスを転送時のプロトコルスタックを示す図、図９
はＭＡＣブリッジングサービスを転送時のプロトコルス
タックを示す図、図１０はＮａｔｉｖｅ−ＡＴＭを使っ
た転送時のプロトコルスタックを示す図である。何れ
も、一番上のレイヤでそれぞれのノードが処理を実行し
ている。

【００４３】次に、実施の形態例について説明する。 Ａ．Ｉｎｇｒｅｓｓ（入り口）エッジノードの処理 エッジノード２４’において、汎用ルータ２３（端末を
含む）からのＡＡＬ（ＡＴＭ Ａｄａｐｔａｔｉｏｎ
Ｌａｙｅｒ）５のパケットを受信した時、先ず入力ＶＣ
Ｉをキーとして、サービス対応表テーブルを検索する。
検索した結果として、Ｇｌｏｂａｌ ＩＰサービスやＩ
Ｐ ＣＵＧサービス等を記すサービスタイプと、ＣＵＧ
ＩＤ及び次に検索を行なうルーティングテーブル４０
のトップノードが示される。

【００４４】図１１はサービスと対応付けたＰＯＲＴ／
ＶＰＩ／ＶＣＩの構成図である。パケットを受信すると
（Ｓ１）、そのパケットがコアからなのかユーザからな
のかを識別する（Ｓ２、Ｓ３）。コアからである場合に
は、コアネットワーク処理（カプセル処理）を行なう
（Ｓ４）。ユーザからのものである場合には、どのサー
ビスタイプであるかをＣＵＧ ＩＤを検索して調べる
（Ｓ５）。そして、サービスタイプに応じて分岐し（Ｓ
６）、各サービスを実行する（Ｓ７）。サービスの種類
には、Ｇｌｏｂａｌ ＩＰサービスや、ＩＰ ＣＵＧサ
ービスや、ＭＡＣブリッジングサービスや、その他のサ
ービスが含まれる。

【００４５】（ａ）サービスタイプがＧｌｏｂａｌ Ｉ
Ｐサービスの場合 この場合は、検索結果のＣＵＧ ＩＤが必ず０になって
いる。次に入力されたパケットをＡＡＬ５レイヤ、ＬＬ
Ｃ／ＳＮＡＰレイヤ、ＩＰレイヤと分析を行なう。ここ
で、ＬＬＣはＬｏｇｉｃａｌ Ｌｉｎｋ Ｃｏｎｔｒｏ
ｌ、ＳＮＡＰはＳｕｂ Ｎｅｔｗｏｒｋ Ａｔｔａｃｈ
ｍｅｎｔ Ｐｏｉｎｔの略である。ＩＰレイヤ分析から
取り出した宛先ＩＰアドレスをキーとして、ルーチング
テーブル４０のトップノードから順にＬｏｎｇｅｓｔ
Ｍａｔｃｈによる検索を行なう。ルーチングテーブル４
０を検索してどこに送るかを決める。その中に入ってい
るキー情報と今回自分のアドレスから抜き出したキー情
報とを比較する。この場合に、頭のビットからなるべく
長く一致するものを選択してエントリに送る。

【００４６】Ｌｏｎｇｅｓｔ Ｍａｔｃｈに検索した結
果がある場合には、そのノードのリーフのテーブルが参
照される。検索した結果がない場合には、パケットは不
正なパケットとして廃棄される。リーフのテーブルで
は、宛先ＩＰアドレスに対する振る舞いが記述される。
振る舞いを記述するフラグとしてＭ、Ｃ、Ｕの３つのフ
ラグが使用され、以下のように場合分けされる。

【００４７】Ｍ：マルチキャスト通信かどうかを指定 Ｃ：コアネットワークに向けて転送を行なうかどうかを
指定 Ｕ：ユーザネットワークに向けて転送を行なうかどうか
を指定 （ユニキャスト通信で宛先ＩＰアドレスのユーザが１つ
のエッジノード内にある場合）この場合には、Ｍ＝０、
Ｕ＝１、Ｃ＝０となる。この場合は、パケットフォーマ
ットはそのままで、指定されるＶＣＩに対して、パケッ
トを送信する。

【００４８】（ユニキャスト通信で宛先ＩＰアドレスの
ユーザが別のエッジノードにある場合）この場合には、
Ｍ＝０、Ｕ＝０、Ｃ＝１となる。この場合は、コアプロ
トコル用のＬＬＣ／ＳＮＡＰを含むコアプロトコルをパ
ケットに挿入する。ソースコアアドレスは、自エッジノ
ードの初期設定時に設定されたコアアドレスを使用す
る。宛先コアアドレスは、そのリーフ内で指定されるコ
アアドレスを使用する。サービスタイプ及びＣＵＧ Ｉ
Ｄは現在の値を使用する。パケットの組み立てが終わっ
た後、指定されるＶＣＩに対してパケットを送信する。

【００４９】（マルチキャスト通信でマルチキャストグ
ループのユーザが１つのエッジノード内にある場合）こ
の場合には、Ｍ＝１、Ｕ＝１、Ｃ＝０となる。この場合
は、パケットフォーマットはそのままで、指定される内
部ＣＨ（チャネル）に対して、パケットを送信する。内
部ＣＨで送信されたパケットは、後段にて、その内部Ｃ
Ｈに対応したマルチキャストグループメンバリストを検
索し、そのメンバリストに対してパケットを送信する。

【００５０】（マルチキャスト通信でマルチキャストグ
ループのユーザが別のエッジノードにある場合）この場
合には、Ｍ＝１、Ｕ＝０、Ｃ＝１となる。この場合は、
コアプロトコル用のＬＬＣ／ＳＮＡＰを含むコアプロト
コルをパケットに挿入する。ソースコアアドレスは、自
エッジノードの初期設定時に設定されたコアアドレスを
使用する。宛先コアアドレスは、そのリーフ内で指定さ
れるコアアドレスを使用する。

【００５１】サービスタイプ及びＣＵＧ ＩＤは、現在
の値を使用する。パケットの組み立てが終わった後、指
定されるＶＣＩに対して、パケットを送信する。これら
を受信するコアネットワークでは、送信を終了するエッ
ジノードをマルチキャスト配信ツリーのトップとなるツ
リー構造を構築しており、その分岐点ではコピーされ、
その分岐毎にパケットが送信される。

【００５２】（マルチキャスト通信でマルチキャストグ
ループのユーザが自エッジノードを含む複数のエッジノ
ードにある場合）この場合には、Ｍ＝１、Ｕ＝１、Ｃ＝
１となる。そこで、Ｍ＝１、Ｕ＝１、Ｃ＝０と、Ｍ＝
１、Ｕ＝０、Ｃ＝１の両方の処理を行なう。

【００５３】図１２はＧｌｏｂａｌ ＩＰサービスでの
処理フローを示す図で、エッジノードの動作を示す。先
ずサービスタイプとＣＵＧ ＩＤに対応するアドレステ
ーブルを宛先ＩＰアドレスで検索する（Ｓ１）。次に、
検索結果の有無を調べる（Ｓ２）。検索結果がある場合
には、検索結果のノードを参照する（Ｓ３）。そして、
Ｍフラグが０であるか１であるかチェックする（Ｓ
４）。０である場合には、Ｇｌｏｂａｌ ＩＰ用ユニキ
ャスト通信を行なう（Ｓ５）。１である場合には、Ｇｌ
ｏｂａｌ ＩＰ用マルチキャスト通信を行なう（Ｓ
６）。

【００５４】図１３は図１２におけるＧｌｏｂａｌ Ｉ
Ｐサービスでのユニキャスト通信の処理フローを示す図
で、エッジノードの動作を示している。先ずＵフラグが
０であるか１であるかをチェックする（Ｓ１）。０であ
る場合には、次にＣフラグが０であるか１であるかをチ
ェックする（Ｓ２）。０である場合には、Ｍ＝Ｕ＝Ｃ＝
０で、不正な値であるので、ＮＧ処理を行なう（Ｓ
３）。

【００５５】１である場合には、設定されているコアア
ドレスを基にコアプロトコルのスタックを作成し（Ｓ
４）、設定されているＰＯＲＴ／ＶＰＩ／ＶＣＩに送信
する（Ｓ５）。ステップＳ１において、Ｕ＝１の場合に
は、設定されているＰＯＲＴ／ＶＰＩ／ＶＣＩにパケッ
トを送信する（Ｓ６）。

【００５６】図１４は図１２におけるＧｌｏｂａｌ Ｉ
Ｐサービスでのマルチキャスト通信の処理フローを示す
図で、エッジノードの動作を示している。先ずＵフラグ
が０であるか１であるかをチェックする（Ｓ１）。１で
ある場合には、設定されている内部ＣＨ ＩＤ（シェー
パＩＤ）にパケットを送信する（Ｓ２）。０である場合
には、Ｃフラグが０であるか１であるかをチェックする
（Ｓ３）。Ｃフラグが１である場合には、設定されてい
るコアアドレスを基にコアプロトコルのスタックを作成
し（Ｓ４）、設定されている内部ＣＨに送信する（Ｓ
５）。

【００５７】（ｂ）サービスタイプがＩＰ ＣＵＧサー
ビスの場合 この場合は、検索結果のＣＵＧ ＩＤが１以上になって
いること以外は、Ｇｌｏｂａｌ ＩＰサービスの処理と
同じである。

【００５８】図１５はＩＰ ＣＵＧサービスでの処理フ
ローを示す図で、エッジノードの動作を示している。先
ず、サービスタイプとＣＵＧ ＩＤに対応するアドレス
テーブルを宛先ＩＰアドレスで検索する（Ｓ１）。そし
て、検索結果の有無を調べる（Ｓ２）。検索結果がある
場合には、検索結果のノードを参照し（Ｓ３）、Ｍフラ
グをチェックし、Ｍが０又は１であるかどうかチェック
する（Ｓ４）。Ｍ＝０の場合には、ＩＰ ＣＵＧ用ユニ
キャスト通信を行なう（Ｓ５）。Ｍ＝１の場合には、Ｉ
Ｐ ＣＵＧ用マルチキャスト通信を行なう（Ｓ６）。

【００５９】図１６は、図１５におけるＩＰ ＣＵＧサ
ービスでのユニキャスト通信の処理フローを示す図で、
エッジノードの動作を示している。先ずＵフラグが０で
あるか１であるかチェックする（Ｓ１）。Ｕ＝０であっ
た場合には、Ｃフラグが０であるか１であるかチェック
する（Ｓ２）。Ｃ＝０である場合には、ＮＧ処理を行な
う（Ｓ３）。

【００６０】Ｃ＝１である場合には、設定されているコ
アアドレスを基にコアプロトコルのスタックを作成し
（Ｓ４）、設定されているＰＯＲＴ／ＶＰＩ／ＶＣＩに
送信する（Ｓ５）。ステップＳ１においてＵ＝１である
場合には、パケットを設定されているＰＯＲＴ／ＶＰＩ
／ＶＣＩに送信する（Ｓ６）。

【００６１】図１７は、図１５におけるＩＰ ＣＵＧサ
ービスでのマルチキャスト通信の処理フローを示す図
で、エッジノードの動作を示している。先ずＵフラグが
０であるか１であるかチェックする（Ｓ１）。Ｕ＝１で
ある場合には、設定されている内部ＣＨ ＩＤにパケッ
トを送信する（Ｓ２）。

【００６２】Ｕ＝０である場合には、Ｃフラグが０であ
るか１であるかチェックする（Ｓ３）。Ｃ＝１である場
合には、設定されているコアアドレスを基にコアプロト
コルのスタックを作成し（Ｓ４）、設定されている内部
ＣＨに送信する（Ｓ５）。

【００６３】（ｃ）サービスタイプがＭＡＣブリッジン
グサービスの場合 この場合は、検索結果はＣＵＧ ＩＤが０以上になって
いる。次に、入力されたパケットをＡＡＬ５レイヤ、Ｍ
ＡＣレイヤと分析を行なう。ＭＡＣレイヤから取り出し
た宛先ＭＡＣアドレスをキーとして、ルーチングテーブ
ル４０のトップノードから順に検索を行なう。検索した
結果がある場合には、そのノードのリーフのテーブルが
参照される。検索した結果がない場合には、パケットは
ＬＡＮＥの解決手順が取られる。リーフのテーブルで
は、宛先ＭＡＣアドレスに対する振る舞いが記述され
る。

【００６４】（ユニキャスト通信で宛先ＭＡＣアドレス
のユーザが１つのエッジノード内にある場合）この場合
は、Ｍ＝０、Ｕ＝１、Ｃ＝０となる。この場合は、パケ
ットフォーマットはそのままで、指定されるＶＣＩに対
して、パケットを送信する。

【００６５】（ユニキャスト通信で宛先ＭＡＣアドレス
のユーザが別のエッジノードにある場合）この場合は、
Ｍ＝０、Ｕ＝０、Ｃ＝１となる。この場合は、コアプロ
トコル用のＬＬＣ／ＳＮＡＰを含むコアプロトコルをパ
ケットに挿入する。ソースコアアドレスは、自エッジノ
ードの初期設定時に設定されたコアアドレスを使用す
る。宛先コアアドレスはそのリーフ内で指定されるコア
アドレスを使用する。サービスタイプ及びＣＵＧ ＩＤ
は、現在の値を使用する。パケットの組み立てが終わっ
た後、指定されるＶＣＩに対して、パケットを送信す
る。

【００６６】（ブロードキャスト通信又はマルチキャス
ト通信の場合）この場合はＭ＝０、Ｕ＝０、Ｃ＝１とな
る。コアプロトコル用のＬＬＣ／ＳＮＡＰを含むコアプ
ロトコルをパケットに挿入する。ソースコアアドレス
は、自エッジノードの初期設定時に設定されたコアアド
レスを使用する。宛先コアアドレスはそのリーフ内で指
定されるコアアドレスを使用する。この宛先アドレスは
ＬＡＮＥのエンティティ（実体）のＢＵＳのコアアドレ
スを示す。サービスタイプ及びＣＵＧ ＩＤは現在の値
を使用する。パケットの組み立てが終わった後、指定さ
れるＶＣＩに対して、パケットを送信する。

【００６７】図１８はＭＡＣブリッジングサービスでの
処理フローを示す図である。先ず、サービスタイプとＣ
ＵＧ ＩＤに対応するアドレステーブルを宛先ＭＡＣア
ドレスで検索する（Ｓ１）。次に、検索結果の有無をチ
ェックする（Ｓ２）。検索結果がある場合には、検索結
果のノードを参照する（Ｓ３）。そして、Ｍが０である
か１であるかチェックする（Ｓ４）。Ｍ＝０の場合に
は、ＭＡＣブリッジング用ユニキャスト通信を行なう
（Ｓ５）。Ｍ＝１の場合には、マルチキャスト通信を行
なう。

【００６８】図１９はＭＡＣブリッジングサービスでの
ユニキャスト通信の処理フローを示す図である。先ずＵ
が０であるか１であるかチェックする（Ｓ１）。Ｕ＝０
の場合には、Ｃが０であるか１であるかチェックする
（Ｓ２）。Ｃ＝０の場合にはＮＧ処理を行なう（Ｓ
３）。Ｃ＝１の場合には、設定されているコアアドレス
を基にコアプロトコルのスタックを作成し（Ｓ４）、設
定されているＰＯＲＴ／ＶＰＩ／ＶＣＩに送信する（Ｓ
５）。ステップＳ１において、Ｕ＝１の場合には、設定
されているＰＯＲＴ／ＶＰＩ／ＶＣＩにパケットを送信
する（Ｓ６）。 Ｂ．ｅｇｒｅｓｓ（出口）エッジノード処理 エッジノード２７において、コアネットワーク１３から
のＡＡＬ５のパケットを受信した時、ＡＡＬ５レイヤ、
ＬＬＣ／ＳＮＡＰレイヤ及びコアプロトコルレイヤのパ
ケット分析を行なう。若し、宛先コアアドレスが自コア
アドレスと等しくない、又はマルチキャストコアアドレ
スでない場合は、パケットを廃棄する。

【００６９】次に、コアＩＤからサービスタイプとＣＵ
Ｇ ＩＤを取り出し、それをキーとして、サービス対応
表テーブルの検索を行なう。検索した結果として、Ｇｌ
ｏｂａｌ ＩＰサービスやＩＰ ＣＵＧサービス等を記
すサービスタイプと、ＣＵＧＩＤ及び次に検索を行なう
ルーチングテーブル４０のトップノードが示される。

【００７０】図２０はコアＩＤによる転送処理フローを
示す図で、コアノードの動作を示している。先ず、ＡＡ
Ｌ５の最初の１セルを受信し（Ｓ１）、コアＩＤを検索
する（Ｓ２）。そして、検索結果の有無を調べる（Ｓ
３）。検索結果がある場合には、検索結果のノードを参
照する（Ｓ４）。

【００７１】そして、Ｍフラグが０であるか１であるか
チェックする（Ｓ５）。Ｍ＝０の場合には、ユニキャス
ト通信であり、設定されているＰＯＲＴ／ＶＰＩ／ＶＣ
Ｉにパケットを送信する（Ｓ６）。Ｍ＝１の場合には、
マルチキャスト通信であり、設定されている複数のＰＯ
ＲＴ／ＶＰＩ／ＶＣＩにパケットを送信する（Ｓ７）。

【００７２】（ａ）サービスタイプがＧｌｏｂａｌ Ｉ
Ｐサービスの場合 この場合は、検索結果のＣＵＧ ＩＤが必ず０になって
いる。次に、入力されたパケットをＬＬＣ／ＳＮＡＰレ
イヤ、ＩＰレイヤと分析を行なう。ＩＰレイヤ分析から
取り出した宛先ＩＰアドレスをキーとして、ルーチング
テーブル４０のトップノードから順にＬｏｎｇｅｓｔ
Ｍａｔｃｈによる検索を行なう。Ｌｏｎｇｅｓｔ Ｍａ
ｔｃｈに検索した結果がある場合は、そのノードのリー
フのテーブルが参照される。検索した結果がない場合
は、パケットは不正なパケットとして廃棄される。

【００７３】リーフのテーブルでは、宛先ＩＰアドレス
に対する振る舞いが記述される。但し、コアネットワー
クのエンドポイントとなるため、更にコアネットワーク
に転送する処理はない。

【００７４】（ユニキャスト通信の場合）この場合は、
Ｍ＝０、Ｕ＝１、Ｃ＝０となる。この場合は、コアプロ
トコル用のＬＬＣ／ＳＮＡＰを含むコアアドレスをパケ
ットから取り除く。その後、指定されるＶＣＩに対し
て、パケットを送信する。

【００７５】（マルチキャスト通信の場合）この場合
は、Ｍ＝１、Ｕ＝１、Ｃ＝０／１となる。この場合は、
コアプロトコル用のＬＬＣ／ＳＮＡＰを含むコアアドレ
スをパケットから取り除く。その後、指定される内部Ｃ
Ｈに対して、パケットを送信する。内部ＣＨで送信され
たパケットは、後段にて、その内部ＣＨに対応したマル
チキャストグループメンバリストを検索し、そのメンバ
リストに対して、パケットを送信する。コアに対しては
値に拘らず送信しない。

【００７６】（ｂ）サービスタイプがＩＰ ＣＵＧサー
ビスの場合この場合は、検索結果のＣＵＧ ＩＤが１以
上になっていること以外は、Ｇｌｏｂａｌ ＩＰサービ
スの処理と同じである。

【００７７】（ｃ）サービスタイプがＭＡＣブリッジン
グサービスの場合 この場合は、検索結果はＣＵＧ ＩＤが０以上になって
いる。次に入力されたパケットをＡＡＬ５レイヤ、ＭＡ
Ｃレイヤと分析を行なう。ＭＡＣレイヤから取り出した
宛先ＭＡＣアドレスをキーとして、ルーチングテーブル
のトップノードから順に検索を行なう。検索した結果が
ある場合は、そのノードのリーフのテーブルが参照され
る。

【００７８】検索した結果がない場合は、パケットは廃
棄される。リーフのテーブルでは、宛先ＭＡＣアドレス
に対する振る舞いが記述される。但し、コアネットワー
クからくるパケットは、アドレス解析が行なわれて、全
てユニキャスト通信として処理される。

【００７９】（ユニキャスト通信の場合）この場合は、
Ｍ＝０、Ｕ＝１、Ｃ＝０となる。この場合は、コアプロ
トコル用のＬＬＣ／ＳＮＡＰを含むコアアドレスをパケ
ットから取り除く。その後、指定されるＶＣＩに対し
て、パケットを送信する。

【００８０】図２１はコアネットワークからのパケット
受信のサービス変換処理フローを示す図で、エッジノー
ドの動作を示している。先ず、コアＩＤからサービスタ
イプとＣＵＧ ＩＤを取り出す（Ｓ１）。次に、コアプ
ロトコルを取り除く（Ｓ２）。そして、サービスの種類
毎に分岐させる（Ｓ３）。そして、サービスの種類に応
じた処理を行なう（Ｓ４）。

【００８１】図２２はＩＰマルチキャスト転送機能の処
理フローを示す図で、エッジノードの動作を示してい
る。先ず内部ＣＨを使用した送信を行なう（Ｓ１）。次
に、内部ＣＨに対応したマルチキャストグループリスト
を検索する（Ｓ２）。次に、検索結果の有無を調べる
（Ｓ３）。検索結果がある場合には、設定されている複
数のＰＯＲＴ／ＶＰＩ／ＶＣＩにパケットを送信する
（Ｓ４）。

【００８２】本発明によれば、コアネットワーク内に振
る舞いを記述するフラグ（Ｍ、Ｃ、Ｕ）を用いることに
より、エッジノード２４’、２７’での送信処理の簡易
化及びアドレステーブルの縮小化を図ることができる。

【００８３】（付記１） 各ＬＡＮ間がＡＴＭネットワ
ークを介して接続されたシステムにおいて、ＡＴＭネッ
トワーク内に各サービスとカスタマに接続されるＶＣＩ
とを対応付けるテーブルを設け、ＡＴＭネットワーク内
のコアネットワーク内にコアプロトコルを用い、Ｇｌｏ
ｂａｌ ＩＰサービス、ＩＰ ＣＵＧサービス、ＭＡＣ
ブリッジングサービスのフォーマットをカプセル化して
フォワーディングを行ない、コアネットワークから出る
場合は、カプセル化されたパケットをデカプセル化する
ように構成されたことを特徴とするマルチレイヤスイッ
チのアドレス管理システム。

【００８４】（付記２） 前記コアネットワーク内はコ
アＩＤを使用して、階層的にフォワーディングすること
を特徴とする付記１記載のマルチレイヤスイッチのアド
レス管理システム。

【００８５】（付記３） 前記コアネットワーク内にコ
アアドレスを設け、該コアアドレスは、ユニキャスト用
のアドレスフォーマットと、マルチキャスト用のアドレ
スフォーマットを用いることを特徴とする付記２記載の
マルチレイヤスイッチのアドレス管理システム。

【００８６】（付記４） 前記コアネットワーク内のア
ドレステーブルに振る舞いを記述するフラグ（Ｍ、Ｃ、
Ｕ）によって処理の簡易化／アドレステーブルの縮小化
を図ることを特徴とする付記１記載のマルチレイヤスイ
ッチのアドレス管理システム。

【００８７】

【発明の効果】以上説明したように、本発明によれば、
以下の効果が得られる。 （１）請求項１記載の発明によれば、各サービスとカス
タマに接続するＶＣＩを対応付けるルーチングテーブル
を設けることにより、１ノードで複数のサービスの提供
が可能になる。また、エッジノードからコアネットワー
クに接続するＶＣ数も削減可能である。

【００８８】（２）請求項２記載の発明によれば、コア
ネットワーク内をコア情報（コアアドレス＋サービスイ
ンフォメーション）を使用して、階層的にフォワーディ
ングすることにより、現状のＩＰアドレスの分散状態を
キャリアによって管理されるアドレス構造となり、階層
化による利点で、接続するカスタマが増えても経路を集
約できるため、検索するフォワーディングテーブルの増
大を抑えることができる。

【００８９】（３）請求項３記載の発明によれば、コア
ＩＤの中のコアアドレスをユニキャスト用とマルチキャ
スト用の２つのアドレスフォーマットを用いることによ
り、通常の１対１にデータを配信するユニキャスト以外
に１対多にデータを配信するマルチキャストデータパケ
ットを明確に識別でき、その配信先となる複数の宛先に
向けてデータコピー処理を行なうことができる。

【００９０】また、本発明において、前記コアネットワ
ーク内のアドレステーブルに振る舞いを記述するフラグ
（Ｍ，Ｃ，Ｕ）によって処理の簡易化／アドレステーブ
ルの縮小化を図ることができる。

【図面の簡単な説明】

【図１】本発明の原理ブロック図である。

【図２】コアプロトコルパケットフォーマットの構成例
を示す図である。

【図３】Ｔｒａｆｆｉｃ Ｃｌａｓｓの構成例を示す図
である。

【図４】ユニキャストコアアドレスのフォーマットの構
成例を示す図である。

【図５】マルチキャストコアアドレスのフォーマットの
構成例を示す図である。

【図６】ＭＣ Ｇｒｏｕｐ ＩＤの構成例を示す図であ
る。

【図７】サービスインフォメーションのフォーマットの
構成例を示す図である。

【図８】Ｇｌｏｂａｌ ＩＰ・ＩＰ ＣＵＧサービスを
転送時のプロトコルスタックを示す図である。

【図９】ＭＡＣブリッジングサービスを転送時のプロト
コルスタックを示す図である。

【図１０】Ｎａｔｉｖｅ ＡＴＭを使った転送時のプロ
トコルスタックを示す図である。

【図１１】サービスと対応付けたＰＯＲＴ／ＶＰＩ／Ｖ
ＣＩの構成図である。

【図１２】Ｇｌｏｂａｌ ＩＰサービスでの処理フロー
を示す図である。

【図１３】Ｇｌｏｂａｌ ＩＰサービスでのユニキャス
ト通信の処理フローを示す図である。

【図１４】Ｇｌｏｂａｌ ＩＰサービスでのマルチキャ
スト通信の処理フローを示す図である。

【図１５】ＩＰ ＣＵＧサービスでの処理フローを示す
図である。

【図１６】ＩＰ ＣＵＧサービスでのユニキャスト通信
の処理フローを示す図である。

【図１７】ＩＰ ＣＵＧサービスでのマルチキャスト通
信の処理フローを示す図である。

【図１８】ＭＡＣブリッジングサービスでの処理フロー
を示す図である。

【図１９】ＭＡＣブリッジングサービスでのユニキャス
ト通信の処理フローを示す図である。

【図２０】コアＩＤによる転送処理フローを示す図であ
る。

【図２１】コアネットワークからのパケット受信のサー
ビス変換処理フローを示す図である。

【図２２】ＩＰ マルチキャスト転送機能の処理フロー
を示す図である。

【図２３】Ｇｌｏｂａｌ ＩＰサービスのネットワーク
を示す図である。

【図２４】ＩＰ ＣＵＧサービスのネットワークを示す
図である。

【図２５】ＭＡＣブリッジングサービスのネットワーク
を示す図である。

【符号の説明】

１１、１４ ＬＡＮ １２ ＡＴＭネットワーク １３ コアネットワーク ２１、２９ 端末 ２３、２８ 汎用ルータ ２４’、２７’ エッジノード ２５ コアノード ３０、３１ ＡＴＭスイッチ ３２、３４ コアアドレス ３２’、３４’ ＡＴＭアドレス ３５ コアアドレス ４０ ルーチングテーブル

───────────────────────────────────────────────────── フロントページの続き (72)発明者 川田 英二 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 谷川 真樹 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 Ｆターム(参考） 5K030 HA10 HB14 HC14 HD03 HD06 KA05 5K033 CB08 CC01 DA05 DB18 EC03

Claims (3)

【特許請求の範囲】
1. 【請求項１】 各ＬＡＮ間がＡＴＭネットワークを介し
   て接続されたシステムにおいて、 ＡＴＭネットワーク内に各サービスとカスタマに接続さ
   れるＶＣＩとを対応付けるテーブルを設け、 ＡＴＭネットワーク内のコアネットワーク内にコアプロ
   トコルを用い、Ｇｌｏｂａｌ ＩＰサービス、ＩＰ Ｃ
   ＵＧサービス、ＭＡＣブリッジングサービスのフォーマ
   ットをカプセル化してフォワーディングを行ない、 コアネットワークから出る場合は、カプセル化されたパ
   ケットをデカプセル化するように構成されたことを特徴
   とするマルチレイヤスイッチのアドレス管理システム。
2. 【請求項２】 前記コアネットワーク内はコアＩＤを使
   用して、階層的にフォワーディングすることを特徴とす
   る請求項１記載のマルチレイヤスイッチのアドレス管理
   システム。
3. 【請求項３】 前記コアネットワーク内にコアアドレス
   を設け、該コアアドレスは、ユニキャスト用のアドレス
   フォーマットと、マルチキャスト用のアドレスフォーマ
   ットを用いることを特徴とする請求項２記載のマルチレ
   イヤスイッチのアドレス管理システム。