JP3479265B2

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

Info

Publication number: JP3479265B2
Application number: JP2000212521A
Authority: JP
Inventors: 正実百海; 英二川田; 真樹谷川
Original assignee: Fujitsu Ltd; Nippon Telegraph and Telephone Corp
Current assignee: Fujitsu Ltd; Nippon Telegraph and Telephone Corp
Priority date: 2000-07-13
Filing date: 2000-07-13
Publication date: 2003-12-15
Anticipated expiration: 2020-07-13
Also published as: JP2002026958A

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

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

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

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

【０００７】

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

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

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

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

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

【００１２】

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

【００１３】ＡＴＭネットワーク１２において、１３は
該ＡＴＭネットワーク１２内に設けられたコアネットワ
ークである。該コアネットワーク１３内のアドレステー
ブルには、マルチキャスト通信かどうかを指定するＭフ
ラグと、コアネットワークに向けて転送を行なうかどう
かを指定するＣフラグと、ユーザネットワークに向けて
転送を行なうかどうかを指定するＵフラグを設けてい
る。４０はＡＴＭネットワーク１２内に設けられたルー
チングテーブルである。コアネットワーク１３におい
て、２４’は汎用ルータ２３又はＡＴＭスイッチ３０と
接続されるエッジノード、２５は該エッジノード２４’
と接続されるコアノード、２７’は該コアノード２５と
接続されるエッジノードである。該エッジノード２７’
は、汎用ルータ２８及びＡＴＭスイッチ３１と接続され
ている。エッジノード２４’は、ルーチングテーブル４
０を参照して、コアノード２５内のパスを設定する。

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

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

【００１６】ＧｌｏｂａｌＩＰサービス、ＩＰＣＵ
Ｇサービス、ＭＡＣブリッジングサービス等の各サービ
スのパケットが、コアネットワーク１３内ではコアプロ
トコルにカプセル化されることにより、各サービスを意
識することなく、統一化されたコアプロトコルのみで制
御される。また、統一化されたコアプロトコルでのみ接
続すればよいので、エッジノード２４’、２７’からコ
アネットワーク１３に接続するＶＣ（Ｖｉｒｔｕｒａｌ
Ｃｏｎｎｅｃｔｉｏｎ）数も削減可能である。また、
前記コアネットワーク内のアドレステーブルに振る舞い
を記述するフラグ（Ｍ,Ｃ,Ｕ）を設けることによって処
理の簡易化／アドレステーブルの縮小化を図るように構
成すれば、処理の簡易化／アドレステーブルの縮小化を
図ることができる。

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

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

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

【００２０】

【００２１】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００８７】

【発明の効果】以上説明したように、本発明によれば、
以下の効果が得られる。（１）請求項１記載の発明によれば、各サービスとカス
タマに接続するＶＣＩを対応付けるルーチングテーブル
を設けることにより、１ノードで複数のサービスの提供
が可能になる。また、エッジノードからコアネットワー
クに接続するＶＣ数も削減可能である。また、前記コア
ネットワーク内のアドレステーブルに振る舞いを記述す
るフラグ（Ｍ,Ｃ,Ｕ）を設けることによって処理の簡易
化／アドレステーブルの縮小化を図ることができる。

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

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

【００９０】

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【符号の説明】

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

───────────────────────────────────────────────────── フロントページの続き (72)発明者谷川真樹東京都千代田区大手町二丁目３番１号日本電信電話株式会社内 (56)参考文献村上純一，北爪秀雄，久々津直哉，加藤愼一，大規模インターネット構築に向けたコアネットワークの設計，ＮＴＴＲ＆Ｄ，日本，1997年３月10日，第46 巻，第３号，ｐ223−232 村上純一，北爪秀雄，久々津直哉，原博之，広域ネットワーキングサービスプラットフォームに適した経路制御セルの設計，電子情報通信学会技術研究報告，日本，電子情報通信学会，1997年10 月17日，ＩＮ97−118 安部敦史，新籾純，則武克誌，大規模ネットワークにおけるＩＰマルチキャスト実現方法，マスユーザ向け情報配信ネットワークへの適用，1997年電子情報通信学会ソサイエティ大会講演論文集２, 日本，電子情報通信学会，1997年８月 13日，Ｂ−７−８ (58)調査した分野(Int.Cl.⁷，ＤＢ名) H04L 12/28 - 12/46 H04L 12/56

Claims

(57)【特許請求の範囲】

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