JP2962276B2

JP2962276B2 - Ａｔｍコネクションレス通信網におけるセッション管理方式及びコネクション管理方式

Info

Publication number: JP2962276B2
Application number: JP12107297A
Authority: JP
Inventors: 道雄升田; 基夫西原; 亮小川
Original assignee: Nippon Electric Co Ltd
Current assignee: NEC Corp
Priority date: 1997-05-12
Filing date: 1997-05-12
Publication date: 1999-10-12
Anticipated expiration: 2017-05-12
Also published as: JPH10313316A; US6314098B1

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、セッション管理方
式及びコネクション管理方式に関し、特に、ＡＴＭ（非
同期転送モード：Asynchronous Transfer Mode）網を介
して、インターネットにおけるデータグラムのようなコ
ネクションレスデータ通信を行う形態でのセッション管
理方式及びコネクション管理方式に関する。

【０００２】

【従来の技術】現在、急激に増加しているＩＰ（インタ
ーネットプロトコル：Internet Protocol）トラヒック
をＡＴＭ網で収容し、レイヤ２スイッチングによりこの
トラヒックの処理の高速化を図る技術志向が盛んであ
る。しかしながら、標準のＡＴＭ通信方式は、“Connec
tion Oriented”すなわちコネクション指向型であっ
て、送信元ユーザ端末が宛先ユーザ端末にデータを送信
する際にはその送信前にユーザ間のコネクションを明示
的に設定する必要があり、コネクション確立過程とデー
タ転送過程が独立している。ＡＴＭ通信でのコネクショ
ン確立過程におけるＳＶＣ（Switched Virtual Connect
ion：相手選択接続）では、コネクション管理をＧＣＩ
Ｄ（Global Connection ID：グローバルコネクションＩ
Ｄ）とＡＴＭレイヤのセルラベル（ＶＰＩ／ＶＣＩ）と
によって行ない、エンド端末間の接続において各リンク
で一つのＶＣＩを割り当てている。ここで、ＶＰＩは仮
想パス識別子（Virtual Path Identifier）であり、Ｖ
ＣＩは仮想チャネル識別子（Virtual Channel Identifi
er）である。

【０００３】ＡＴＭ網でコネクションレスのデータ通信
を行う従来の方式として、ＩＴＵ−Ｔ勧告Ｉ．３６４に
示されたものがあり、この方式を用いたものとして、例
えば特開平７−７４７６７号公報に開示されるコネクシ
ョンレスサービス装置がある。この従来の方式では、サ
ーバ装置とユーザ装置とが伝送路により接続されたネッ
トワーク構成において、リンク上でデータ伝送単位のセ
ルを２階層の論理的なコネクションに多重し、下位層の
コネクション（以下、ＶＣ（仮想チャネル：Virtual Ch
annel）またはＡＴＭコネクションとする）と上位層の
コネクション（以下、ＡＡＬ（ＡＴＭアダプテーション
レイヤ：ATM Adaptation Layer）コネクションとする）
に分類した管理を行っている。ＡＴＭコネクションにお
いては、ＡＴＭセルレベルの配信先を決定するための識
別子として上述のＶＣＩを使用し、ＡＡＬコネクション
においては、ユーザ装置が生成するデータ伝送単位とし
てのセルがＶＣ上で複数に分割されている場合に、これ
ら分割セルを組み立てるための識別情報として、送信元
ユーザ装置ごとに多重識別子ＭＩＤ（Message IDentifi
er）を使用する。そして、このようなＭＩＤフィールド
を持つＡＡＬタイプ３／４を使用して、ユーザ情報をカ
プセル化（encapsulate）する。

【０００４】図８は、特開平７−７４７６７に示す従来
のコネクションレスサービス装置の構成を示したもので
ある。サーバ装置８１とユーザ装置８２とが伝送路８３
を介して接続している。サーバ装置８１には、ネットワ
ークへのアクセスを行うネットワークアクセス部８４
と、セルの生成や解析を行うセル生成・解析部８５とが
設けられ、さらに、サーバ装置８１および各ユーザ装置
８２が受信を行う際に用いる受信用ＶＣＩ値を各装置ご
とに１つずつ割り当て、割り当てた受信用ＶＣＩ値を各
ユーザ装置８２に通知する受信用ＶＣＩ初期割り当て部
８６と、ユーザ受信用ＶＣＩとユーザ識別子として割り
当てるＭＩＤとの対応を保持して各ＶＣについてのＭＩ
Ｄ値の使用状況を管理するＭＩＤ管理部８７とが、設け
られている。一方、ユーザ装置８２には、ネットワーク
アクセス部９１と、セルの多重化や分離を行うセル多重
・分離部９２と、セルの組み立てや分解を行うセル組立
・分解部９３と、コネクションの制御を行うコネクショ
ン制御部９４と、ユーザとのインタフェースを行うユー
ザインタフェース部９５と、ユーザアプリケーション９
６とが設けられている。

【０００５】ユーザ装置８２間で通信する時は、ユーザ
装置９２のコネクション制御部９４とサーバ装置８１の
ＭＩＤ管理部８７との通信により、受信用ＶＣＩ値をキ
ーに未使用のＭＩＤ（多重識別子）が検索され、選択さ
れたＭＩＤ値がユーザ装置８２に通知される。ＭＩＤを
獲得したユーザ装置８２は、そのＭＩＤを用いてＡＡＬ
コネクションを確立し、ユーザ装置８２間での通信を可
能とする。

【０００６】

【発明が解決しようとする課題】特開平７−７４７６７
号に例示される上述した従来の方式の第１の問題点は、
パケット管理がコネクション管理に依存しており、両者
ともＡＴＭレイヤで処理されていることである。ＩＰ通
信が目指すマルチキャスト（Multicast）サービスは多
対多通信を前提としており、同一セッション上に異なる
送信元から同一宛先に向かうパケットが混在する。ＡＴ
Ｍフォーラム（ATM Forum)のＩＰｏｖｅｒＡＴＭ
（ＩＰパケットをＡＴＭ網上で転送する方式）系で主流
となっているＡＡＬタイプ５のＳＡＲ（Segmentation a
nd Reassembly sublayer：セル分割・組立サブレイヤ）
処理は、ＭＩＤフィールドをもつＡＡＬタイプ３／４と
は異なり、ＥＯＭ（End Of Message：メッセージの終わ
り）フラグによるパケット単位の管理はできるが、１つ
のコネクション中で別のパケットからのセル混入に対処
する手段（複数のパケットを多重するフィールド）を持
たない。したがって、ＡＡＬタイプ５では、受信側ノー
ドでのパケット再構築プロセスにおいて、混入したセル
を識別し、首尾よくパケットに組み立てることができ
ず、このため、マルチキャストサービス実現上の課題を
有している。

【０００７】このようにＡＡＬタイプ５が多対多のマル
チキャスト通信に関する問題点を抱えているにもかかわ
らず、現在ではデータ伝送のためにＡＡＬタイプ３／４
を使用することは稀である。なぜなら、ＡＡＬタイプ３
／４は、ＳＡＲ処理において各セル単位にＬＩ（Length
Indication：データ長表示）やＣＲＣ（Cycllic Redun
dancy Check：巡回冗長検査）を付加し、セル単位に誤
り検出を行う点で、ＡＡＬタイプ５と較べて複雑なプロ
トコル処理を必要とし、実装上コストがかかるためであ
る。実際、ＡＡＬタイプ５は、ユーザ宅内装置に搭載す
るＡＴＭ−ＮＩＣ（Network Interface Card：ネットワ
ークインタフェースカード）等で広く使用されているの
が現状である。

【０００８】上述した従来の方式の第２の問題点は、多
対多のコネクション確立手順が、ＡＴＭ標準での実現方
式として規定されていないことである。上述した従来の
方式では、多対多通信を行うためのＡＴＭコネクション
（ＶＣＩ）の割り当て方法、およびユーザ端末へのＶＣ
Ｉ通知処理負荷が高く、多対多コネクション確立手順の
複雑さがその後のデータ転送遅延を引き起こす原因とな
る。

【０００９】第３の問題点は、ＭＩＤリソースを浪費す
る問題である。上述した従来の方法では、多対多通信を
行うマルチキャストグループ内に属する端末ごとに予め
唯一のＭＩＤを割り当てておくことにより、網内ノード
でのセルの混入問題を排除し、両方向の多対多コネクシ
ョン確立を行っている。しかしながら、ＭＩＤが取りう
る値が１０ビット（１０２４端末）と小さいため、マル
チキャストグループ内で送信可能となる端末数が厳しく
制限される。特開平７−７４７６７号公報では、端末に
予めＭＩＤを割り当てることはせずにサーバ装置が空き
ＭＩＤ値を一元管理し、データ送信に先立ち送信元端末
がサーバ装置に空きＭＩＤを問い合わせ、その後データ
送信を行う例が示されており、ここでは、同時期に送出
されるパケットに対して、ユニークなＭＩＤ値を使うこ
とを保証するメカニズムを用意している。しかしなが
ら、この方法では、サーバ装置に負荷が集中し、サーバ
の処理能力が全体の処理に対するボトルネックになり得
る。またこの公報には、サーバの単一障害時におけるシ
ステム全体の頑強性に関する記載が明確でない。

【００１０】第４の問題点は、ＡＴＭ標準のシグナリン
グとＩＰ通信で仕様化が進められているＲＳＶＰ（リソ
ース予約プロトコル：resource ReSerVation Protoco
l）との相互作用（干渉）問題である。現在、ＩＰ通信
における帯域幅のダイナミックな割り当てに関する先進
的な方式として、リソース予約プロトコル（ＲＳＶＰ）
が認知されつつある。このＲＳＶＰは、ＩＰネットワー
ク全体の資源予約を行う現行のＩＰ通信の拡張として、
標準化が進められている。しかしながら、多対多のセッ
ション管理を前提としたＲＳＶＰと一対多のコネクショ
ン確立手段しか持たないＡＴＭ標準のシグナリング（Ａ
ＡＬＴｙｐｅ５ｏｎＶＣ：仮想チャネル上のＡ
ＡＬタイプ５）とでは、基本的な方式上の差異があり、
両者の協調が困難である。この差異を吸収するためには
ＲＳＶＰメッセージを下位レイヤのシグナリングメッセ
ージに変換する処理等が必要となり、ＲＳＶＰｏｖｅ
ｒＡＴＭ（ＡＴＭ網でＲＳＶＰパケットを転送する方
式）を実現する上での障壁となっている。

【００１１】本発明の目的は、ＡＴＭ網を介してコネク
ションレス型のデータグラムを転送する際に、多対多で
のマルチキャスト通信を可能とするセッション管理方式
とこれに対応したコネクション管理方式を提供すること
にある。

【００１２】

【課題を解決するための手段】本発明のセッション管理
方式は、ＡＴＭ網を介して、コネクションレス型のデー
タグラムを、特定のデータフローの受け渡しをセッショ
ンと呼ばれるグループ単位に配送するＡＴＭコネクショ
ンレス通信網における、セッション管理方式において、
ＱｏＳ（要求サービス品質）セッションとＮｏ−ＱｏＳ
セッションが混在する任意のユーザ網と相互接続され、
ユーザ網からのＩＰｖ４パケットを中間フレームにいっ
たん収容し、中間フレームをさらにＡＴＭセルに収容す
る、ＡＴＭセル化とデセル化を機能を有するエッジ装置
と、ＡＴＭ網内の中継転送処理を行うコア装置とを有
し、コア装置とエッジ装置との間、及びコア装置の相互
間が固定仮想パスにより接続されてコネクションレス
（ＣＬ）網が形成され、エッジ装置において前記ユーザ
網内のエンド端末のＱｏＳ申告手順の有無を解釈し、セ
ッション単位の識別子を割り当て、セッション単位の識
別子を中間フレームに収容することにより、転送径路上
の各ノードでセッション識別を行うことを特徴とする。

【００１３】このセッション管理方式において、エッジ
装置は典型的には相互接続装置（ＩＷＵ）であり、コア
装置は典型的にはコネクションレス−クロスコネクト装
置（ＣＬ−ＸＣ）である。

【００１４】本発明のコネクション管理方式は、ＡＴＭ
コネクションレス通信網におけるコネクション管理方式
において、ＱｏＳ（要求サービス品質）申告手順及びレ
ートベース制御機能を持たないエンド端末間のベストエ
フォートコネクションを、レイヤ３情報である送信元Ｉ
Ｐアドレス及び宛て先ＩＰアドレスで特定し、かつ宛て
先となるエッジ装置の番号毎に集約し、データ転送処理
過程内でエッジ装置間で双方向対称となる転送経路をス
トレートフォワードに管理するコネクション管理手段を
有し、ＡＴＭ標準の明示的なコネクション手順によるオ
ーバーヘッド処理を必要としないことを特徴とする。

【００１５】すなわち本発明は、上述した課題を解決す
るために、ＡＴＭ標準のコネクション確立手順を排除
し、かつＱｏＳセッションとＮｏ−ＱｏＳセッションが
混在するユーザＬＡＮを収容するコネクションレス（Ｃ
Ｌ）基幹網において、ＣＬ網内の各ノードにセッション
管理機能を設けたものである。

【００１６】ＣＬ網内の各エッジ装置及びコア装置は、
セッション管理手段およびコネクション管理手段とを備
え、両者の協調によりバッファリソースもしくはスイッ
チリソースを管理する。セッション管理手段では、受信
したユーザ端末からのデータパケットがＲＳＶＰの帯域
予約申告等によるＱｏＳセッションに属するか否かを解
釈し、そのセッションの性質に合わせた動作指示をコネ
クション管理手段に与える。

【００１７】本発明における構成要素の役割分担に関し
て以下に記す。セッション管理手段は、エンド端末の送
信元ＩＰアドレス（ＳＡ＿ＩＰ）と上位レイヤ（レイヤ
３以上）で規定されるセッション番号（Session ID）の
対応情報を管理する手段を有する。この手段は、エッジ
装置でＱｏｓセッションに属するか否かを識別し、各セ
ッションと一対一に対応するフロー番号（ｆｌｏｗ＿Ｉ
Ｄ）をＣＬ網内でローカルに割り当てる。このフロー番
号（ｆｌｏｗ＿ＩＤ）は、例えば、中間フレーム構築部
によりフローラベル（flow_label）フィールド内に収容
され、ＣＬ網内を転送される。転送経路上の各コア装置
では、送信元ＩＰアドレス（ＳＡ＿ＩＰ）とｆｌｏｗ＿
ＩＤを抽出し、セッション管理を行う。セッション管理
手段は、ＱｏＳセッションに属さないベストエフォート
トラヒックに関して、エッジ装置でのレート制御により
ＣＬ網内で発生した局所的な輻輳を吸収する制御指示
を、コネクション管理手段に与える。

【００１８】コネクション管理手段は、ＲＭ（リソース
管理：Resource Management）セルのフィードバックに
よるレート制御を行うために、双方向対称すなわち上り
／下り同一となる経路を維持管理する。送信元エッジ装
置におけるコネクション管理は、送信元ＩＰアドレス
（ＳＡ＿ＩＰ），宛て先ＩＰアドレス（ＤＡ＿ＩＰ）で
規定されるエンド端末間のベストエフォートコネクショ
ンを、宛先エッジ装置（ＤＡＣＬ）単位に集約して管
理する。

【００１９】ＣＬ内転送経路上の各コア装置は、データ
パケットもしくは順方向（Forward方向）のＲＭセル
（ＦＲＭセル）受信時に、送信元ＣＬアドレス（ＳＡ＿
ＣＬ）、宛先ＣＬアドレス（ＤＡ＿ＣＬ）、connection
-IDを、受信したポート番号と組み合わせてテーブルに
登録する手段と、逆方向（Backward）方向のＲＭセル
（ＢＲＭセル）受信時に、ペイロード中に記述されてい
る送信元ＣＬアドレス（ＳＡ＿ＣＬ）と宛先ＣＬアドレ
ス（ＤＡ＿ＣＬ）を元に左記テーブルを検索し登録デー
タを得る手段を有する。また、ＣＬ網内の送信元エッジ
装置および各コア装置は、宛先エッジ装置に向かうトラ
ヒック発生時のアクティブコネクションのみタイマー監
視するソフトステート型の維持手段を有する。

【００２０】《作用》本発明のＣＬ網におけるデータ転
送系の特徴は、ユーザパケット認識とコネクション認識
の両者を備え、かつ各々が独立したレイヤ処理により実
施される点である。パケット認識は、ＶＣＩを使用した
レイヤ２（ＡＴＭレイヤ）の処理であり，コネクション
認識はレイヤ３（中間フレームとして採用するＩＰｖ
６）の処理である。このように、パケット認識とコネク
ション認識が完全に独立したレイヤ処理で行われるた
め、ＭＩＤフィールドや明示的なＢＯＭ識別フィールド
をもたないＡＡＬタイプ５でも適用可能である。

【００２１】ＣＬ網内での転送動作は、セル単位に固定
ＶＰ（ＰＶＣ）間を動的に接続することにより、先頭セ
ルから、セル・バイ・セル（cell by cell）転送（いわ
ゆるカットスルー転送）を行うものである。ＣＬ網内コ
ネクション識別に、必要となる送信元ＣＬアドレス（Ｓ
Ａ＿ＣＬ），宛て先ＣＬアドレス（ＤＡ＿ＣＬ）の組情
報は、各パケットの先頭セルに全て含まれる。そのた
め、ストレートフォワード型の高速なコネクション管理
ができる。

【００２２】本発明は、ＱｏＳセッションとＮｏ−Ｑｏ
Ｓセッションが混在する網形態での運用を許容する。こ
のため、将来的なインターネットに付随するＲＳＶＰ等
の多対多通信サービス等に対して、ＩＴＵやＡＴＭフォ
ーラムのＡＴＭレイヤのみによるコネクション規定方法
よりも柔軟に対応できる。本発明におけるコネクション
管理は、ＱｏＳ申告手段を持たないエンド端末（Ｎｏ−
ＲＳＶＰ端末）間コネクションを宛先エッジ装置番号
（ＤＡ＿ＣＬ）毎に集約したバッファ管理である。これ
より、管理するコネクション数を節約すると共に統計多
重効果によるＩＷＵ内バッファの平滑化を図ることがで
きる。

【００２３】本発明では、エッジ装置間で双方向対称
（上り／下りが同一）となる経路をソフトステートによ
り維持する。このため、ＡＴＭ標準の明示的なコネクシ
ョンセットアップ（Set-up）／ティアダウン（Tear-dow
n）手順等のオーバーヘッド処理を必要とせず、側セル
に対し、ＦＲＭ側セルが同一経路を逆送することができ
ると共に、自律的な運用、頑強性（ロバスト性）の利点
が得られる。

【００２４】

【発明の実施の形態】次に、本発明の実施の形態につい
て、図面を参照して説明する。図１は、本発明の好まし
い実施の一形態のセッション管理方式である相互接続装
置（ＩＷＵ：InterWorking Unit）の構成を示すブロッ
ク図である。また、図２は、このＩＷＵが適用されるコ
ネクションレス（ＣＬ）網の構成を示す図である。

【００２５】まず、ＣＬ（コネクションレス）網の構成
から説明する。このＣＬ網１は、例えば既存のイーサネ
ット（Ethernet）に代表されるＬＡＮ（ローカルエリア
ネットワーク）であるユーザ網４に対して相互接続する
ためのＩＷＵ（相互接続装置）２と、ＣＬ網１内の中継
転送処理を行うコア装置であるＣＬ−ＸＣ（コネクショ
ンレス−クロスコネクト装置：ConnectionLess-crossco
nnect）３により構成されている。ＩＷＵ２は、ＣＬＡ
Ｄ（Cell Assembly Disassembly：ＡＴＭセル化とデセ
ル化）機能を有するエッジ装置である。隣接するＣＬ−
ＸＣ３とＩＷＵ２の間、及びＣＬ−ＸＣ３の相互間は固
定接続ＶＰ（ＰＶＣ接続）を使用する（ＶＰ：仮想パ
ス, Virtual Path、ＰＶＣ：Permanebt Virtual Connec
tion, 相手固定接続）。

【００２６】本実施の形態のセッション管理方式は、Ａ
ＴＭ標準のコネクション確立過程を排除したＣＬ網内の
ＩＷＵ２とＣＬ−ＣＸ３で適用する。ＣＬ網２が収容す
るユーザＬＡＮ（ユーザ網４）では、ＲＳＶＰトラヒッ
クとベストエフォート（BestEffort）トラヒックとが混
在する形態を許容する。ＲＳＶＰトラヒックとは、レイ
ヤ３以上でのＱｏＳ（要求サービス品質、要求通信品
質：Quality of Service）申告手順を持つ帯域保証型の
トラヒックであり、ＱｏＳセッション（QoS Session）
と呼ぶ。一方、ベストエフォートトラヒックとは、ＲＳ
ＶＰやシグナリング等の帯域予約手順やＱｏＳ申告手順
を持たない端末群のＩＰトラヒックであり、Ｎｏ−Ｑｏ
Ｓセッション（No-QoS Session）と呼ぶ。

【００２７】本実施の形態によるセッション管理方式で
は、ＩＷＵ２でエンド端末のＱｏＳ申告手段の有無を解
釈し、ＱｏＳセッションに対しては、特定のデータフロ
ーの受け渡しを行う“セッション”と呼ばれるグループ
単位に、制御用のフロー番号ｆｌｏｗ＿ＩＤを割り当
て、中間フレーム内の所定フィールドにこのｆｌｏｗ＿
ＩＤを収容する。機能を有すると共に、ＱｏＳ申告手順
やソーストラヒックに対する規制手段もたない端末群の
Ｎｏ−ＱｏＳセッションに対しては、ＩＷＵ２間コネク
ションに集約し、双方向同一経路を管理し、レートベー
ス(rate base）でのフロー制御を行う。

【００２８】図３は、ＩＷＵ２がＣＬ網１へ送信する際
のカプセル化過程を示したものである。ここでは、ユー
ザ網４（ユーザＬＡＮ）からＩＰｖ４フレームがＩＷＵ
２に送られてくるものとする。ＩＷＵ２では、ユーザ網
４から受け取ったＩＰｖ４フレームを一旦、中間フレー
ムであるＩＰｖ６フレームに収容する。ＩＰｖ６フレー
ムのヘッダ部には、ＣＬ網内転送情報として使用する発
信元ＩＷＵ番号（ＳＡ＿ＣＬ）と宛先ＩＷＵ番号（ＤＡ
＿ＣＬ）、およびセッションを識別する情報としてフロ
ー番号ｆｌｏｗ＿ＩＤが含まれる。また、このＩＰｖ６
フレームにＡＡＬタイプ５のヘッダおよびトレイラを付
加することにより、ＣＰＣＳ−ＰＤＵ（Common Part Co
nvergence Sublayer-Protocol Data Unit、コンバージ
ェンスサブレイヤ共通部−プロトコルデータユニット）
フレームを生成する。さらに、ＡＡＬのＳＡＲ処理によ
り、ＣＰＣＳ−ＰＤＵフレームをＡＴＭセルに収容す
る。同一のＣＰＣＳ−ＰＤＵフレームを構成する全ての
ＡＴＭセルには、同一の仮想チャネル識別子ＶＣＩを付
与し、セル順序を崩すことなくＣＬ網１側に転送される
ようにする。ＩＰｖ６ヘッダは通常４０バイトであり、
ＡＡＬタイプ５でセル化した場合は、ＣＬ網内転送情報
として使用する発信元ＩＷＵ番号と宛先ＩＷＵ番号、お
よびｆｌｏｗ＿ＩＤは、先頭セル（ＢＯＭセル）に全て
収容される。

【００２９】図１に戻ってＩＷＵ２の構成を説明する。
ＩＷＵ２において、ユーザＬＡＮインターフェース１１
はユーザ網４とのパケットの送受信インタフェースであ
り、ＣＬ網インタフェース２１はＣＬ網１との送受信イ
ンタフェースである。ユーザＬＡＮインタフェース１１
の出力側には、受信したパケットヘッダ情報からＲＳＶ
Ｐ制御パケットか主信号データパケットかを識別するパ
ケット識別部１２が設けられている。パケット識別部１
２においてＲＳＶＰ制御パケットと識別された場合に
は、パケット識別部１２は、送信セッション管理部１３
を経由してそのＲＳＶＰ制御パケットをＲＳＶＰ制御部
１７へ転送する。

【００３０】ここでセッション管理部１３は、パケット
識別部１２の他に、中間フレーム構築部１４と、ＲＳＶ
Ｐ制御部１７、コネクション管理部２２及び受信パケッ
ト識別部２４と接続している。また、セッション管理部
１３は、テーブルを持ち、ＲＳＶＰ制御パケット受信タ
イミングで、送信元ＩＰアドレス（ＳＡ＿ＣＬ）とセッ
ション番号とをキーにして、ｆｌｏｗ＿ＩＤに対応付け
た登録処理を行った後、ＲＳＶＰ制御部１７にＲＳＶＰ
制御パケットを転送する。ＲＳＶＰ制御部１７は、ＲＳ
ＶＰパケット内のＱｏＳ情報（サービス指定要求）を解
釈し、バッファ管理部１８及び出力スケジューラ部２０
へのリソースパラメータ設定を行うインタフェースを備
えている。

【００３１】一方、パケット識別部１１において主信号
データパケットと識別した場合には、セッション管理部
１３内のテーブルが検索され、そのデータパケットがＲ
ＳＶＰによるＱｏＳセッションに属するか否かが識別さ
れる。テーブル検索の結果、事前登録されたテーブルエ
ントリにヒットした場合は、ＱｏＳセッションと特定
し、セッション管理部１３は、同一送信ＩＰアドレスと
セッション番号に対応するｆｌｏｗ＿ＩＤを一対一に割
り当て、中間フレーム構築部１４へ転送する。このｆｌ
ｏｗ＿ＩＤは、中間フレーム構築部１４において、（Ｓ
Ａ＿ＣＬ：ＤＡ＿ＣＬ）の対応情報とともに中間フレー
ムのヘッダ部に収容される。セッション管理部１３での
検索の結果、Ｎｏ−ＱｏＳ（非帯域予約）セッションと
判定された場合には、ベストエフォートトラヒックを明
示するｆｌｏｗ＿ＩＤ（例えば全部が“０”）が、セッ
ション管理部１３から中間フレーム構築部１４へ渡され
る。中間フレーム構築部１４は、取得したｆｌｏｗ＿Ｉ
Ｄを中間フレームのヘッダに付与した後、エンド端末間
コネクションを宛先ＩＷＵ毎コネクションに集約した形
式でコネクション管理部２２に渡す。コネクション管理
部２２は、コネクション管理テーブルを備えており、集
約された宛先ＩＷＵ毎コネクションＩＤとともにエンド
端末間コネクションをコネクション管理テーブルに登録
する。コネクション管理テーブルはソフトステート（so
ft-state）管理であり、各宛先ＩＷＵ毎コネクションに
属するセルの到着をタイマーで監視することにより、ア
クティブコネクションのみの維持管理を行う。コネクシ
ョン管理部２２は、セッション管理部１３や中間フレー
ム構築部１４の他に、バッファ管理部１８、出力スケジ
ューラ部２０及びＦＲＭセル挿入部２３と接続してい
る。そしてコネクション管理部２２は、コネクションが
アクティブな状態の時には、定期的なＲＭ（リソース管
理：Resource Management）セルの挿入、転送指示をＦ
ＲＭ挿入部２３に送出し、ＣＬ網１内の輻輳状況を監視
する。ＦＲＭセルは、ＣＬ網インタフェース２１を介し
てＣＬ網１に送出される。ここでＦＲＭセルとは、フォ
ワード（Forward）ＲＭセルのことである。

【００３２】中間フレーム構築部１４でｆｌｏｗ＿ＩＤ
を取得した主信号データパケットは、セル化多重部１５
においてＡＴＭセルに収容され、多重処理が施された
後、セルラベル付与部１６においてパケット単位にＶＣ
Ｉが付与され、セルバッファ１９に格納される。バッフ
ァ管理部１８は、セルバッファ１９の使用状況をＱｏＳ
セッションであればＱｏＳセッションごとに管理し、Ｎ
ｏ−ＱｏＳセッションの場合は宛先ＩＷＵ毎に管理す
る。また、セルバッファ１９は、出力スケジューラ部２
０によって、出力帯域速度に基づいた読み出し制御を受
け、セルバッファ１９内のセルは、この読み出し制御に
したがってＣＬ網インタフェース２１に入力し、ＣＬ網
１に送出される。

【００３３】また、ＣＬ網１側から受信したパケットを
識別するために受信パケット識別部２４が設けられてい
る。受信パケットはＣＬ網インタフェース２１を介して
受信パケット識別部２４に入力する。受信パケット識別
部２４には、ＲＭセルを折り返すためにＲＭセル折り返
し部２５とＢＲＭセルを検出するためのＢＲＭセル検出
部２６も接続している。ＲＭセル折り返し部２５で折り
返されたＲＭセルは、ＣＬ網インタフェース２１を介し
て再びＣＬ網１側に送出される。ＢＲＭセルとは、バッ
クワード(Backward)ＲＭセルのことである。

【００３４】

【実施例】次に、実施例によって、本発明のセッション
管理方式をさらに詳しく説明する。図４は本実施例での
相互接続装置（ＩＷＵ）の要部の構成とデータの流れを
説明する図である。図４は、図１に示すＩＷＵにおける
セッション管理部１３や中間フレーム構築部１４からＣ
Ｌ網インタフェース部２１までの部分に相当する部分を
示したものであり、ＩＷＵで中間フレームに構築された
主信号データパケットがセッション別に分類され、ＣＬ
網に送出される過程を模式的に示している。

【００３５】ところで、本発明のセッション管理方式
は、ＣＬ網が収容対象とするユーザＬＡＮの性質によ
り、２種類の構成要素を有する。そして、ＣＬ網におい
ては、ＱｏＳセッションとＮｏ−ＱｏＳセッションが混
在する。

【００３６】そこでまず、ＱｏＳセッションの収容方式
について説明する。

【００３７】ＱｏＳセッションでは、特定のサービス品
質として要求されるデータフローを設定するために、Ｒ
ＳＶＰ制御パケットに収容される帯域予約要求を用い
る。ＲＳＶＰ制御部３３で受信した帯域予約要求は、帯
域管理部３４に渡され許可判定を受ける。リソースの提
供が許可された場合には、ＲＳＶＰ制御部３３は、セッ
ション管理部３４に対し、送信元ＩＰアドレス（ＳＡ＿
ＩＰ）とセッション番号と対応付けたｆｌｏｗ＿ＩＤの
登録処理を行った後、バッファ管理部３５に対し、キュ
ー３７での書込処理に必要となるフィルタリングパラメ
ータを設定し、また、出力スケジューラ部３６に対し、
読出処理に必要なリソース制御パラメータ設定を行う。
また、ｆｌｏｗ＿ＩＤは、中間フレーム構築部３１にも
渡される。キュー３７はセッションごとのキュー（Per
session Queue）であり、このキュー３７の出力側に
は、スケジューラ３８が設けられている。このスケジュ
ーラ３８は、セッションごとのスケジューラ（Per sess
ion Schedular）である。

【００３８】上述の処理により、あるデータパケットが
予約設定されたノードに到着した場合、セッション管理
部３２によりそのパケットの属するセッション毎に分類
され、事前に出力スケジューラ部３６に設定されたパラ
メータに従って配送される。ここではＱｏＳセッション
に属するデータパケットなので、このデータパケット
は、中間フレーム構築部インタフェース３１から、キュ
ー３７、スケジューラ３８、ＣＬ網インタフェース部４
３を介して配送されることになる。

【００３９】ＱｏＳセッションに属するデータパケット
の識別情報となるｆｌｏｗ＿ＩＤの維持管理は、ソフト
ステート管理である。セッション管理部３２は、ソフト
ステートの削除を行うまでの期間を計るために、クリー
ンアップタイマを備える。セッション管理部３２のｆｌ
ｏｗ＿ＩＤは、データフローを定期的に検出することに
よりリフレッシュされ、クリーンアップタイムアウトの
期間内にリフレッシュされない場合は、ソフトステート
が削除される。

【００４０】ＲＳＶＰ制御部３３はＱｏＳセッションを
ＣＬ網でエミュレートするために、以下の機能を有す
る。ユーザ端末が送出するＲＳＶＰパケットのＱｏＳ情報
（サービス指定要求）をＣＬ網でサポートするＱｏＳ情
報に翻訳する機能，ＲＳＶＰパケット転送経路の定期的なチェック（ＲＳ
ＶＰで規定されるパスメッセージ(Path Message)とリバ
ースメッセージ(Reserve Message)）をエミュレートす
る機能，受信ユーザ端末単位の異なるＱｏＳの保持機能。

【００４１】次に、ＣＬ網におけるＮｏ−ＱｏＳセッシ
ョンの収容方式について説明する。

【００４２】データパケット受信時に、セッション管理
部３２のセッション管理テーブルを参照し、送信元ＩＰ
アドレス（ＳＡ＿ＩＰ）とセッション番号（Session_I
D）とをキーとして、フロー番号ｆｌｏｗ＿ＩＤを検索
する。セッション管理テーブル内にｆｌｏｗ＿ＩＤのエ
ントリが存在しないことにより、そのデータパケット
は、Ｎｏ−ＱｏＳセッションに属するものと特定され
る。Ｎｏ−ＱｏＳセッションと特定された場合は、中間
フレーム構築部３１によってｆｌｏｗ＿ＩＤ＝“０…
０”（全部が“０”）を持つ中間フレームが構築され
る。そして、コネクション管理部３９が多重化部（ＭＵ
Ｘ）４０を制御することにより、エンド端末間のコネク
ション（ＳＡ＿ＩＰ，ＤＡ＿ＩＰ）がＩＷＵ間のコネク
ション（ＳＡ＿ＣＬ，ＤＡ＿ＣＬ）に多重化される。こ
こで、ＳＡ＿ＩＰ，ＤＡ＿ＩＰはそれぞれ送信元と宛て
先の端末のＩＰアドレスであり、ＳＡ＿ＣＬ，ＤＡ＿Ｃ
Ｌはそれぞれ送信元と宛て先となるＩＷＵを表してい
る。この多重化されたコネクションはキュー４１に格納
される。このキュー４１は、宛て先となるＩＷＵごとの
キュー（Per DA_CL Queue）であり、大量のバッファメ
モリから構成されている。バッファ管理部３５は、宛て
先となるＩＷＵ（ＤＡ＿ＣＬ）単位にバッファ使用状況
の管理を行う。キュー４１の出力側には、スケジューラ
４２が設けられている。このスケジューラ４２は、宛て
先となるＩＷＵごとのスケジューラ（Per DA_CL Schedu
lar）である。

【００４３】このようなＩＷＵ間コネクションは、コネ
クション管理部３９において、送信元ＩＷＵで宛先ＣＬ
アドレスをエントリとして持つコネクション管理テーブ
ルにより管理される。コネクション管理部３９はタイマ
ーを有しており、このコネクション管理は、宛先ＩＷＵ
に向かうトラヒックの発生をタイマーで監視するソフト
ステート管理である。タイムアウト時、つまり宛先ＩＷ
Ｕに向かうトラヒックのないコネクションは解消したと
みなし、前記コネクション管理テーブルから削除する。
新規宛先ＣＬアドレスへのパケットが入力した時に、コ
ネクションＩＤの登録を行う。

【００４４】なお、ＣＬ−ＸＣは、ＢＯＭセルまたはＦ
ＲＭセルに収容される、送信元ＣＬアドレス及び宛て先
ＣＬアドレスの対を基にアクティブなコネクションのみ
を管理する。

【００４５】Ｎｏ−ＱｏＳセッションを扱うＣＬ網は、
高負荷時のセル廃棄によるスループット低下に対応する
ために、レートベースのフロー制御機能を有する。ＩＷ
Ｕにおいては、データパケット送出に伴い、アクティブ
なコネクションのみ定期的にＲＭ（Resource Managemen
t：リソース管理）セルを挿入する。ＲＭセルのフィー
ドバック制御により、輻輳発生時の該当リンクを通過す
るトラヒックをＣＬ網とユーザＬＡＮの境界点であるＩ
ＷＵで吸収し、レート規制、出力スケジューリングによ
るフロー制御を行う。宛て先ＩＷＵ（ＤＡ＿ＣＬ）毎コ
ネクション間のフィードバック制御により、ＣＬ網内で
規定した最小セルレート（ＭＣＲ：Minimum Cell Rat
e）を保証しつつ、必要に応じてピークセルレート（Ｐ
ＣＲ：PeakCell Rate）までＣＬ網内リソースを提供す
ることが可能となる。

【００４６】図５は、ＡＴＭフォーラムのトラヒック・
マネージメント・スペシフィケーション第４.０版（Tra
ffic Management Specification Ver4.0）（１９９６年
３月）の規定のＲＭセルフォーマットを示す。ＣＬ網内
でのＲＭセルルーティングに必要となる（ＳＡ＿ＣＬ，
ＤＡ＿ＣＬ）は、主信号データパケットをＡＡＬタイプ
５でセル化する際にＢＯＭセルに収容する（ＳＡ＿Ｃ
Ｌ，ＤＡ＿ＣＬ）の箇所と統一し、ＲＭセルペイロード
部の２６バイト目から２８バイトまでの３バイトにＳＡ
＿ＣＬを、４２バイト目から４４バイト目までの３バイ
トにＤＡ＿ＣＬを設定する。ＦＲＭセルを折り返す宛て
先ＩＷＵでの処理は、メッセージタイプ（Message Typ
e）フィールドの方向ビット（Direction bit）を“０”
すなわち順方向（Forward）から“１”すなわち（Backw
ard）に変更する。

【００４７】次に、本実施例の動作について説明する。
図６は、本実施例でのＲＭセルのフィードバックルーテ
ィングの動作概念図である。

【００４８】ここでは、２つのＩＷＵ（ＩＷＵ＿ＡとＩ
ＷＵ＿Ｂ）と４つのＣＬ−ＸＣ（ＣＬ−ＸＣ＿１〜ＣＬ
−ＸＣ＿４）によってＣＬ網が構成されている。ＩＷＵ
Ａ（６ａ）とＩＷＵＢ（６ｆ）との間は上り下りで
異なる転送経路が設定されており、ＩＷＵＡ（６ａ）
からＩＷＵＢ（６ｆ）への主信号セル転送経路はＣＬ
−ＸＣ１（６ｂ）→ＣＬ−ＸＣ２（６ｃ）→ＣＬ−
ＸＣ４（６ｅ）を経由し、ＩＷＵＢ（６ｆ）からＩ
ＷＵＡ（６ａ）への主信号セル転送経路はＣＬ−ＸＣ
４（６ｅ）→ＣＬ−ＸＣ３（６ｄ）→ＣＬ−ＸＣ
１（６ｂ）を経由するものとする。

【００４９】送信元ＩＷＵ（６ａ）では、宛て先ＩＷＵ
毎にアクティブなコネクションの管理を行う。データパ
ケット先頭セル（ＢＯＭセル）の所定フィールド、及び
ＲＭセル内の空きペイロード部に送信元（Source）ＣＬ
アドレス（ＳＡ＿ＣＬ）：宛て先（Destination）ＣＬ
アドレス（ＤＡ＿ＣＬ）の組を設定して送出する。

【００５０】ＦＲＭセル転送経路上に位置するＣＬ−Ｘ
Ｃは、データフロー中のＢＯＭセル、またはこのＦＲＭ
セル転送時にこのセル内に収容される（ＳＡ＿ＣＬ：Ｄ
Ａ＿ＣＬ）をキーとして、（入力ポート番号，出力ポー
ト番号）をアクティブコネクション管理テーブルに登録
する。ＦＲＭセル転送経路上のＣＬ−ＸＣは、同一の
（ＳＡ＿ＣＬ：ＤＡ＿ＣＬ）を収容するＦＲＭセルの到
着をタイマー監視することにより、アクティブコネクシ
ョン管理テーブルの維持管理を行い、ＢＲＭセル転送用
に使用される。このような登録・管理動作により、ＡＴ
Ｍ標準のシグナリング等による明示的なコネクション確
立手段を使用しないＣＬ網においても、ＲＭセルのフィ
ードバック転送が可能となる。

【００５１】次に、図６により、ＲＭセルのフィードバ
ック制御におけるＩＷＵ／ＣＬ−ＸＣの動作手順を説明
する。

【００５２】１．送信元であるＩＷＵ＿Ａは、宛て先Ｃ
Ｌアドレス（ＤＡ＿ＣＬ）毎にＦＲＭセルを送出すると
ともに、アクティブコネクションをソフトステートによ
り管理する。

【００５３】２．ＢＯＭセル及びＦＲＭセル内に（Ｓ
Ａ＿ＣＬ：ＤＡ＿ＣＬ）の組を収容してＣＬ網内に転送
する。ＲＭセルにおいては，ペイロ−ドの空き領域（１
７バイト目から４６バイト目まで）中にこの（ＳＡ＿Ｃ
Ｌ：ＤＡ＿ＣＬ）の組を収容する。

【００５４】３．経路上の各ＣＬ−ＸＣは、ＦＲＭセル
受信時に（ＳＡ＿ＣＬ：ＤＡ＿ＣＬ）に対応する（入力
ポート番号、出力ポート番号）を保持し、タイマーによ
るテーブル管理を行う。このテーブルは、ＢＲＭセルの
フィードバックルーティング時に使用する。また（ＳＡ
＿ＣＬ：ＤＡ＿ＣＬ）の組は、該当ＣＬ−ＸＣ内のみで
定義されるコネクション番号と一意に対応つけられ、標
準のＡＴＭ網においてＶＣ単位にバッファ管理を行うレ
ートベース制御のキーに変換（Translate）される。各
ＣＬ−ＸＣでは、ＦＲＭセルに、バッファ輻輳状況及び
レート情報であるＥＣＲ（Explicit Cell Rate：明示的
セルレート）値やＣＣＲ（Current CellRate：現在のセ
ルレート）値等が書き込まれて、転送が繰り返される。

【００５５】４．送信先であるＩＷＵ＿Ｂは、ＦＲＭセ
ルの所定ビットを順方向（forward）から逆方向（backw
ard）に変更したＢＲＭセルを折り返す。

【００５６】５．ＢＲＭセルを受信したＣＬ−ＸＣは、
コネクション管理テーブルより、ＳＡ＿ＣＬ，ＤＡ＿Ｃ
Ｌ及び出力ポート番号をキーに、逆方向（Backward方
向）のポート（ＦＲＭセル入力ポート番号）を取得する
とともに、該当ポートの最新のバッファ輻輳状況を必要
に応じてＢＲＭセルに上書きし、送信元のＩＷＵ＿Ａま
で逆方向に配送する。

【００５７】６．ＢＲＭセルを受信した送信元のＩＷＵ
＿Ａは、ＢＲＭセル内の（レート情報，輻輳状況）及び
自ＩＷＵ内のバッファ状況を基に、各ＤＡ＿ＣＬに対応
するレート制御、及び出力スケジューリングを行う。

【００５８】図７は、図６におけるＣＬ−ＸＣ＿２（６
ｃ）に着目し、ＦＲＭ／ＢＲＭセル転送動作を示したも
のである。ＦＲＭセル受信時は、データセル転送用と同
様のスイッチングテーブルを参照し、ＤＡ＿ＣＬをキー
に出力ポート番号を取得して順方向に転送するととも
に、ＳＡ＿ＣＬ，入力ポート番号（＃０）をアクティブ
コネクション管理テーブルに保持し、ＢＲＭセルの逆方
向転送に備える。送信先ＩＷＵで折り返されたＢＲＭセ
ルは、ＦＲＭセルを送出した出力ポート番号と同値の入
力ポート番号（＃１）より、このＣＬ−ＸＣ＿２に受信
する。ＢＲＭセル受信時は、ＦＲＭセル転送時に保持し
ていたアクティブコネクション管理テーブルを（ＳＡ＿
ＣＬ）の組と出力ポート番号（＃１）ちによってキーに
逆引きして、入力ポート番号（＃０）を取得する。この
処理により、ＢＲＭセル転送時はＦＲＭセル転送経路を
逆方向に転送することが可能となる。ＢＲＭセル中のＥ
Ｒ値と自ＣＬ−ＸＣで算出したＥＲ値を比較し、ＢＲＭ
セル中のＥＲ（明示的レート）値より自ＣＬ−ＸＣで算
出したＥＲ値が小さい時のみ、ＥＲ値を上書きする。

【００５９】次に、本発明のセッション管理方式につい
て、パケットごとの処理過程を説明することによって、
さらに詳しく説明する。図８、図９及び図１０は、本発
明を適用したセッション管理方式の動作を示すフローチ
ャートである。図８は、ＩＷＵなどのエッジ装置がＣＬ
（コネクションレス）網へ送信する際のセッショシ管理
方式の動作を示すフローチャートであり、図９は、コネ
クション管理方式と主信号のセッション識別動作を示す
フローチヤートであり、図１０は、ＲＳＶＰ制御パケッ
トの転送動作を示すフローチャートである。これらの図
を参照して、パケット毎の処理過程を説明する。

【００６０】最初にＲＳＶＰ制御パケットの転送動作フ
ローについて、図８により説明する。ここでは、図１に
示すのと同様のＩＷＵがエッジ装置として使用されるも
のとする。ユーザＬＡＮ（ユーザ網）のホストからＩＰ
ｖ４パケットを受信すると、このＩＰｖ４パケットを受
信した送信元ＩＷＵは、受信パケットがＲＳＶＰパケッ
トか否かをパケット識別部１２で識別する（Ｓ１）。Ｒ
ＳＶＰ制御パケットは、プロトコル番号：４６（0x2E）
のＩＰデータグラムとして規定されており、ＩＷＵで
は、ＩＰヘッダ内のプロトコルフィールド（８ビット）
を抽出し、プロトコル番号が４６であるかどうかでＲＳ
ＶＰパケットか否かを識別する。

【００６１】ＲＳＶＰ制御パケットと判別された場合
は、そのパケットはＲＳＶＰ制御部１７へ転送され、Ｒ
ＳＶＰメッセージの共通ヘッダ（Common Header）内の
ＭｓｇＴｙｐｅ（メッセージタイプ）フィールド（８ビ
ット）を参照することにより、７タイプある各ＲＳＶＰ
メッセージ種別を判別し、メッセージ種別に応じたプロ
トコル処理およびシーケンス管理が実施される。ＲＳＶ
Ｐの予約メッセージを受信した場合は、帯域管理部へ渡
され（Ｄに遷移する）、リソース提供の可否判定を受け
る。判定が“ＯＫ”であれは、バッファ管理部、および
出力スケジューラ部への本パラメータ設定を行い、判定
が“ＮＧ”であればエラーメッセージが返信される。

【００６２】ここで、セッション管理部へと登録処理
（Ｓ２）、すなわちセッションテーブルへの登録と維持
動作について説明する。ＲＳＶＰ制御部１７は、セッシ
ョンテーブルを管理し、ＲＳＶＰ制御パケット内に含ま
れる（ＳＡ＿ＩＰ，sesson_ID）を抽出して、これをキ
ーにして、セッションテーブル（sessionTBL）を検索す
る。次に、ｆｌｏｗ＿ＩＤが登録されているかどうかを
判断する。ｆｌｏｗ＿ＩＤが登録されていない場合は、
新規ｆｌｏｗ＿ＩＤをテーブルに登録し、既に登録され
ている場合は、エージング（Aging）用タイマがリフレ
ッシュされる。

【００６３】次に、主信号パケットにセッション識別情
報であるｆｌｏｗ＿ＩＤが付与されて転送される過程
（Ｓ３）を説明する。パケット識別部１２で主信号と識
別されたパケット群は、ヘッダ部が抽出され、そのパケ
ットヘッダ部より送信元ＩＰアドレス（ＳＡ＿ＩＰ）と
セッション番号（session_ID）が抽出され、これにより
セッションテーブルの検索が行なわれる。パケットのデ
ータ領域は、中間フレーム構築待ちバッファに格納され
る。ここで、ｆｌｏｗ＿ＩＤがすでに登録されているか
どうかが判断され、ＲＳＶＰ制御パケットによりｆｌｏ
ｗ＿ＩＤが事前登録されている場合は、該当ｆｌｏｗ＿
ＩＤを取得しＱｏＳセッションとして扱われる。テーブ
ル検索結果、登録データが取得できない場合は、ｆｌｏ
ｗ＿ＩＤ＝ａｌｌ“０”が割り当てられ、Ｎｏ−ＱｏＳ
セッションとして扱われる。その後、ＱｏＳ、Ｎｏ−Ｑ
ｏＳのいずれの場合も、セッション管理テーブルの参照
によりｆｌｏｗ＿ＩＤが取得されてこの値は中間フレー
ム構築部１４に転送される。中間フレームに構築された
データパケットは、セッション別のキューに格納され、
出力スケジューラによる読み出し制御を受ける。なお、
Ｎｏ−ＱｏＳの場合は、コネクション管理部２２へのア
クティブ指示も行われる。

【００６４】図９を参照して、アクティブコネクション
管理動作を説明する。Ｎｏ−ＱｏＳセッションに属する
（ｆｌｏｗ＿ＩＤ＝ａｌｌ“０”）データパケット群
は、同一宛先ＩＷＵに向かうパケット毎のキューに格納
され、出力スケジューラによる読み出し制御を受ける。
ｆｌｏｗ＿ＩＤ＝ａｌｌ“０”が割り当てられたタイミ
ングで、コネクション管理がアクティブモードに遷移す
る（Ｂ）。中間フレームヘッダ内のDA_CLをキーにして
コネクション管理テーブルが検索され、レートベース制
御のキーとなるコネクション番号（Connection_ID）を
取得する。テーブル内にエントリが存在しない場合は、
Connection_IDが新規登録され、アクティブモードに遷
移する。アクティブなコネクションに対しては、定期的
なＦＲＭセルを挿入し、送信先ＩＷＵまでの経路の輻輳
状況を監視する。受信部では、ＢＲＭセルを検出し、Ｂ
ＲＭセル内に含まれるレート情報に基づく読出速度が出
力スケジューラ部に設定される。

【００６５】

【発明の効果】以上説明したように本発明は、ＡＴＭ標
準のコネクション確立手段を持たないＣＬ網においても
ソフトステート型のコネクション管理が可能となるとい
う効果がある。本発明によれば、ＡＴＭ標準の明示的な
コネクションセットアップ（Set-up）／ティアダウン
（Tear-down）手順等のオーバーヘッド処理を必要とせ
ずに、ストレートフォワード（straight forward）型の
高速なコネクション管理ができる。そして本発明の方
式、上り／下りの経路が異なるデータ転送網においても
双方向同一となる経路管理を可能とし、レートベースの
フロー制御におけるバッファ管理及びＢＲＭセルのフィ
ードバック転送に使用できる。エンド端末間のベストエ
フォートコネクションをＩＷＵ間コネクションに集約
（aggregate）することにより、管理するコネクション
数を節約すると共に統計多重効果によるＩＷＵ内バッフ
ァの平滑化を図ることができる。

【００６６】本発明によれば、ＲＳＶＰ等の今後のＩＰ
通信サービスが目指す多対多通信のセッション管理が可
能となる。そのため、ＩＰ通信の柔軟性を残しつつ、下
位レイヤでの余分な遅延を感じることなくＱｏＳセッシ
ョンとＮｏ−ＱｏＳセッションが混在する網形態におい
ても、各セッションの性質に合わせた転送処理ができ、
ＲＳＶＰｏｖｅｒＡＴＭへの高い流用性が得られ
る。

【図面の簡単な説明】

【図１】本発明の実施の一形態のセッション管理方式を
用いた相互接続装置（ＩＷＵ）の構成を示すブロック図
である。

【図２】図１のＩＷＵが使用されるコネクションレス網
の構成を示すブロック図である。

【図３】ＩＷＵでのカプセル化処理を説明する図であ
る。

【図４】本発明の一実施例でのＩＷＵの要部の構成とデ
ータの流れを説明する図である。

【図５】ＲＭセルのフォーマット例を示す図である。

【図６】実施例でのフロー制御動作を示す説明図であ
る。

【図７】ＣＬ−ＸＣ内での動作を示す説明図である。

【図８】エッジ装置からＣＬ網へ送信する際のセッショ
ン管理方式の動作を示すフローチャートである。

【図９】コネクション管理方式と主信号のセッション識
別動作を示すフローチャートである。

【図１０】ＲＳＶＰ制御パケットの転送動作を示すフロ
ーチャートである。

【図１１】従来のコネクションレスサービス装置の構成
を示すブロック図である。

【符号の説明】

１コネクションレス（ＣＬ）網２相互接続装置（ＩＷＵ）３コネクションレス−クロスコネクト（ＣＬ−Ｘ
Ｃ）４ユーザ網１１ユーザＬＡＮインタフェース１２パケット識別部１３,３２セッション管理部１４,３１中間フレーム構築部１５セル化多重部１６セルラベル付与部１７,３３ＲＳＶＰ制御部１８,３５バッファ管理部１９セルバッファ２０,３６出力スケジューラ部２１,４３ＣＬ網インタフェース２２コネクション管理部２３ＦＲＭセル挿入部２４受信パケット識別部２５ＲＭセル折返し部２６ＢＲＭセル検出部３４帯域管理部３７,４１キュー３８,４２スケジューラ

───────────────────────────────────────────────────── フロントページの続き (56)参考文献特開平７−95199（ＪＰ，Ａ) 特開平７−202906（ＪＰ，Ａ) 特開平９−83537（ＪＰ，Ａ) 特開平９−64915（ＪＰ，Ａ) 特開平10−28143（ＪＰ，Ａ) 信学技報ＳＳＥ97−36 (58)調査した分野(Int.Cl.⁶，ＤＢ名) H04L 12/28

Claims

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

【請求項１】ＡＴＭ網を介して、コネクションレス型
のデータグラムを、特定のデータフローの受け渡しをセ
ッションと呼ばれるグループ単位に配送するＡＴＭコネ
クションレス通信網における、セッション管理方式にお
いて、ＱｏＳ（要求サービス品質）セッションとＮｏ−ＱｏＳ
セッションが混在する任意のユーザ網と相互接続され、
前記ユーザ網からのＩＰｖ４パケットを中間フレームに
いったん収容し、前記中間フレームをさらにＡＴＭセル
に収容する、ＡＴＭセル化とデセル化を機能を有するエ
ッジ装置と、前記ＡＴＭ網内の中継転送処理を行うコア装置とを有
し、前記コア装置と前記エッジ装置との間、及び前記コア装
置の相互間が固定仮想パスにより接続されてコネクショ
ンレス（ＣＬ）網が形成され、前記エッジ装置において前記ユーザ網内のエンド端末の
ＱｏＳ申告手順の有無を解釈し、前記セッション単位の
識別子を割り当て、前記セッション単位の識別子を前記
中間フレームに収容することにより、転送径路上の各ノ
ードでセッション識別を行うことを特徴とするセッショ
ン管理方式。
【請求項２】前記エッジ装置が相互接続装置（ＩＷ
Ｕ）であり、前記コア装置がコネクションレス−クロス
コネクト装置（ＣＬ−ＸＣ）である請求項１に記載のセ
ッション管理方式。
【請求項３】ＡＴＭコネクションレス通信網における
コネクション管理方式において、ＱｏＳ（要求サービス品質）申告手順及びレートベース
制御機能を持たないエンド端末間のベストエフォートコ
ネクションを、レイヤ３情報である送信元ＩＰアドレス
及び宛て先ＩＰアドレスで特定し、かつ宛て先となるエ
ッジ装置の番号毎に集約し、データ転送処理過程内で前
記エッジ装置間で双方向対称となる転送経路をストレー
トフォワードに管理するコネクション管理手段を有し、ＡＴＭ標準の明示的なコネクション手順によるオーバー
ヘッド処理を必要としないことを特徴とするコネクショ
ン網内コネクション管理方式。
【請求項４】前記エッジ装置及び前記コア装置が、Ｑ
ｏＳ申告手順及びレートベース制御機能を持たないエン
ド端末間のベストエフォートコネクションを、レイヤ３
情報である送信元ＩＰアドレス及び宛て先ＩＰアドレス
で特定し、かつ宛て先となるエッジ装置の番号毎に集約
し、データ転送処理過程内で前記エッジ装置間で双方向
対称となる転送経路をストレートフォワードに管理する
コネクション管理手段と、受信したユーザデータパケッ
トがＱｏＳセッションに属するか否かを判断して前記コ
ネクション管理手段に動作指示を与えるセッション管理
手段と、を有して、前記コネクション管理手段と前記セ
ッション管理手段との協調による管理動作を行い、さら
に、前記ユーザ網から受信したパケットヘッダ情報内に収容
する前記送信元ＩＰアドレスとレイヤ３以上の上位レイ
ヤで規定されるセッション番号との対応情報をフロー番
号として割り当ててソフトステートに管理する保持手段
と、前記中間フレームに収容するフロー番号の性質に合
わせた動作指示をコネクション管理手段に与える動作指
示手段を有する、請求項１または２に記載のセッション
管理方式。
【請求項５】前記エッジ装置が、宛先となるエッジ装
置のアドレス単位のバッファと、各バッファの出力に定
期的にリソース管理（ＲＭ）セルを挿入するＲＭセル挿
入手段を有し、前記コネクションレス網内の輻輳発生箇所に位置するコ
ア装置が、前記リソース管理セル及び逆方向リソース管
理セルに諸情報を書き込んで転送するＲＭセル転送手段
を有し、前記逆方向リソース管理セルを受け取ったエ
ッジ装置が、該当宛先のエッジ装置のアドレスのバッフ
ァにおいてセルの送出を規制し、トラヒックソースに対
するフロー制御機能を持たない送信元ユーザ端末の代わ
りにレートベースのフロー制御を実行する請求項３に記
載のコネクション管理方式。
【請求項６】前記ユーザ網から受けたＩＰｖ４フレー
ムが中間フレームであるＩＰｖ６フレームにいったん収
容され、前記ＩＰｖ６フレームのヘッダ部が発信元のエ
ッジ装置番号と宛先のエッジ装置番号とセッションを識
別する情報としてフロー番号とを含み、前記ＩＰｖ６フ
レームのヘッダ部がＡＡＬ（ＡＴＭアダプテーションレ
イヤ）タイプ５の先頭セル（ＢＯＭセル）に全て収容さ
れる請求項１または２に記載のセッション管理方式。
【請求項７】前記エッジ装置がリソース予約プロトコ
ル（ＲＳＶＰ）のセッションを解釈してフロー番号とし
て基幹網に転送し、帯域幅の動的な割当はレイヤ３以上
の処理で行われる請求項１，２及び６のいずれか１項に
記載のセッション管理方式。