JPH06311164A - データリンク層形式の自動設定装置 - Google Patents

Abstract

(57)【要約】 【目的】ネットワークに影響を及ぼすことなく、データ
リンク層のヘッダの形式を自動的に設定する。 【構成】ネットワークに接続されたノード装置１に用い
られるデータリンク層形式の自動設定装置１１におい
て、前記ネットワークからの受信データからデータリン
ク層のヘッダの形式を判断する判断部１１ａと、判断部
１１ａの判断結果からノード装置１におけるデータリン
ク層のヘッダの形式を設定する設定部１１ｃとから構成
される。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ネットワークのデータ
リンク層形式の自動設定装置に関し、特にアメリカ電気
・電子技術者協会（以下、「ＩＥＥＥ」という）８０
２．３が標準化した搬送波感知多重アクセス／衝突検出
（ＣＳＭＡ／ＣＤ）方式を採るバス型ＬＡＮ（以下、
「イーサネット」という）等のローカルエリアネットワ
ークにおけるデータリンク層形式の自動設定装置に関す
る。

【０００２】

【従来の技術】従来、イーサネット等のネットワークに
おいてデータ通信を行う際には、国際標準化機構（ＩＳ
Ｏ）で採択された開放型システム間相互接続（以下、
「ＯＳＩ」という）の参照モデルに基づき、通信機能を
階層化するのが一般的である。

【０００３】例えば、イーサネットは、物理層とデータ
リンク層の下位２層をサポートするため、ゼロックス・
ネットワーク・システム（ＸＮＳ）プロトコル、ＴＣＰ
／ＩＰ（Transmission Control Protocol / Internet P
rotocol）、ネットウエア（NetWare）等の上位プロトコ
ルがネットワーク上に構築されることになる。

【０００４】ここで、物理層とは物理コネクションを活
性化・非活性化する手段を提供する層であるのに対し、
データリンク層はデータリンクコネクションの確立・開
放等のサービスを上位層に提供する層であるため、デー
タリンク層において当該データに宛先アドレス・送信元
アドレス等のヘッダを付加することになる。

【０００５】また、データリンク層で付加されるヘッダ
形式は複数種類あるため、通信相手のヘッダ形式と同一
に設定する必要がある。

【０００６】このデータリンク層のヘッダ形式を設定す
る従来の技術には、ユーザがコンソールか又はスイッチ
を用いて手動で設定する方式（以下、「手動設定方式」
という）と、データリンク層より上位のアプリケーショ
ンを用いて自動的に設定する方式（以下、「自動設定方
式」という）とがある。

【０００７】この自動設定方式では、あるヘッダ形式で
とりあえず相手側に送信を行い、応答がなければ応答が
あるまで様々なヘッダ形式で試行錯誤的に送信を行い、
応答されたヘッダ形式を採用する方式を用いるのが一般
的である。

【０００８】例えば、上位層のプロトコルであるネット
ワーク層のルーティング情報プロトコル（Routing Info
rmation Protocol：以下、「ＲＩＰ」という）やサービ
ス通知プロトコル（Service Advertise Protocol：以
下、「ＳＡＰ」という）等から送信要求を受けたなら
ば、まずデフォールトのヘッダ形式を用いてパケットを
送信し、相手側の機器からの応答があれば当該ヘッダ形
式を採用する。一方、相手側の機器からの応答がなけれ
ば、次のヘッダ形式を用いた送信を行い応答の有無を確
認する。以下、同様の手順を繰り返し、相手側の機器が
使用するヘッダ形式を判断することになる。

【０００９】

【発明が解決しようとする課題】しかしながら、手動設
定方式では、人手を介してヘッダ形式を設定する必要が
あるため、ネットワークにデータリンク層のヘッダ形式
を複数持つのネットワーク機器が接続される場合には、
ヘッダ形式の変更が煩雑になるという問題がある。

【００１０】また、自動設定方式では、上記問題は解決
できるものの、相手側が使用していないヘッダ形式でパ
ケットを送信するため、回線上に意味のないパケットを
滞留させ、ネットワーク効率の低下を招くという問題が
生じる。

【００１１】ところで、特開平３−８９６４５号公報に
は、複数種類の上位プロトコルに対応したアドレスを予
め準備し、受信フレームの宛先アドレスと当該アドレス
とを比較して上位層に受信フレームを自動的に供給する
ＬＡＮアダプタが開示されているが、データリンク層の
パケットの送信を行う際には、やはり手動設定方式か又
は自動設定方式を用いる必要があるため上記の問題を解
決することはできない。

【００１２】そこで、本発明は、かかる問題点を除去
し、ネットワークに影響を及ぼすことなく、使用すべき
データリンク層のヘッダの形式を自動的に設定すること
ができるデータリンク層形式の自動設定装置を提供する
ことを目的とする。

【００１３】

【課題を解決するための手段】上記目的を達成するた
め、本発明では、ネットワークに接続されるノード装置
に用いられるデータリンク層形式の自動設定装置におい
て、前記ネットワークからの受信データからデータリン
ク層のヘッダの形式を判断する判断手段（図１の１１
ａ）と、前記判断手段の判断結果から前記ノード装置に
おけるデータリンク層のヘッダの形式を設定する設定手
段（図１の１１ｃ）とを具備したことを特徴とする。

【００１４】

【作用】本発明は、ネットワークに接続されるノード装
置がデータリンク層形式を自動的に設定する際に、前記
ネットワークから得られる受信データのデータリンク層
形式に基づき、当該ノード装置において使用するデータ
リンク層のヘッダ形式を前記判断手段を用いて判断し、
当該判断結果に基づき当該ノード装置のデータリンク層
形式を前記設定手段を用いて設定する。かかる構成によ
り、ネットワークに影響を及ぼすことなく、データリン
ク層のヘッダの形式を自動的に設定することができる。

【００１５】

【実施例】以下、図面を参照して本発明の一実施例につ
いて説明する。

【００１６】図１は、ネットワークの全体構成と本発明
に係わるデータリンク層形式の自動設定装置（自動設定
モジュール）を内蔵するノード装置の構成を示すブロッ
ク図である。

【００１７】図１に示すように、本実施例で用いる通信
システムは、４台のワークステーション（ＷＳ）２〜５
が接続されたローカルエリアネットワーク（ＬＡＮ）と
してのイーサネット６に、パケットの送信及び受信を行
うイーサネットドライバ（トランシーバ）１０、データ
リンク層のヘッダ形式（以下、「コンフィグレーショ
ン」という）を設定する自動設定モジュール１１、１以
上の上位層プロトコルのうちの１つの上位層プロトコル
としてのネットウエア（NetWare）１２を有するノード
装置１を接続した構成をとる。

【００１８】ここで、イーサネットドライバ１０は、通
常のものと同様にノード装置１宛の受信パケットを自動
設定モジュール１１に送るようにして良いし、更にイー
サネット６上を流れるパケットを自動設定モジュール１
１に送るようにしても良い。

【００１９】また、自動設定モジュール１１は、判断部
１１ａと、記憶部１１ｂと、設定部１１ｃとから構成さ
れる。

【００２０】判断部１１ａは、イーサネットドライバ１
０から受け取った受信パケットの持つコンフィグレーシ
ョンを判定するとともに、当該コンフィグレーションが
ノード装置１で使用可能なコンフィグレーションか否か
を判断する。

【００２１】記憶部１１ｂは、ノード装置１がサポート
する複数種類のコンフィグレーションを記憶する。そし
て、この記憶部１１ｂの内容を参照して、判断部１１ａ
の判断が行われる。

【００２２】この際、上記受信パケットは、ノード装置
１を宛先として送信されたパケットだけでなく、イーサ
ネット６上を流れるパケットであれば、例えばワークス
テーション２〜５を宛先として送信されたパケットであ
ってもかまわない。

【００２３】設定部１１ｃは、判断部１１ａの判断結果
を受け取って、判断結果に対応したコンフィグレーショ
ンをデータリンク層に設定する。

【００２４】次に、上記構成を持つノード装置１が、コ
ンフィグレーションを設定する一連の動作について図２
を用いて説明する。

【００２５】今、ノード装置１を立ち上げる時点で、ワ
ークステーション２〜５が相互にデータ通信を行ってい
る場合を考える。この場合、ノード装置１のイーサネッ
トドライバ１０は、イーサネット６からワークステーシ
ョン２〜５のいずれかを宛先とするイーサネットパケッ
トを受信する（Ｓ２０１）。この受信したパケットは、
ノード装置１の自動設定モジュール１１内にある判断部
１１ａに出力される。

【００２６】判断部１１ａは、まずこの受信パケットの
コンフィグレーションを判定する（Ｓ２０２）。このコ
ンフィグレーションの判定処理については後に詳述す
る。

【００２７】その後、このコンフィグレーションがこの
ノード装置１で使用可能か否かを判断する（Ｓ２０
３）。この判断は、判断部１１ａが記憶部１１ｂに格納
された複数のコンフィグレーションを参照することによ
り行われる。すなわち、受信パケットのコンフィグレー
ションと、記憶部１１ｂに格納されているこのノード装
置１がサポートするコンフィグレーションとを比較し
て、当該コンフィグレーションがこのノード装置１がサ
ポートするもので、かつ上位のパケットタイプが同一で
あれば使用可能であると判断する。これに対して、この
ノード装置１がサポートするものでなければ使用不能で
あると判断する。

【００２８】なお、上記判断指標に代えて、この受信パ
ケットが、例えば上位プロトコル（ＲＩＰ、ＳＡＰ等）
の応答パケットである場合のように、信頼性が高いノー
ド（ルータ、サーバ等）が送信したものか否かを判断指
標とすることもできる。

【００２９】その後、設定部１１ｃは、この判断結果を
受け取り、判断結果に対応するコンフィグレーションの
設定を行う（Ｓ２０４）。

【００３０】なお、Ｓ２０３において、受信パケットの
コンフィグレーションが使用可能でない場合は、このま
まこの処理を終了する。

【００３１】次に、Ｓ２０２で行うコンフィグレーショ
ンの判定処理について、さらに詳細に説明する。

【００３２】図３は、記憶部１１ｂに記憶したこのノー
ド装置１でサポートする複数のコンフィグレーションの
一例を示した図である。

【００３３】図３において、フォーマット１は、標準的
なイーサネットの改良型（バージョン２（ｖ．２））フ
ォーマットであり、宛先アドレス（ＤＡ）を記述する第
１フィールド（６バイト）、発信元アドレス（ＳＡ）を
記述する第２フィールド（６バイト）、第３層のパケッ
トタイプ（ＴＹＰＥ）を記述する第３フィールド（２バ
イト）から構成されている。

【００３４】フォーマット２は、ＩＥＥＥ８０２．３の
みに準拠したノベル（Novell）社独自のフォーマットで
あり、宛先アドレス及び発信元アドレスを記述する第１
フィールド及び第２フィールドと、フレーム長（ＬＥ
Ｎ）を記述する第３フィールド（２バイト）から構成さ
れる。

【００３５】フォーマット３は、ＩＥＥＥ８０２．３と
８０２．２とに準拠したノベル社独自のフォーマットで
あり、フォーマット２の構成に、宛先サービスアクセス
ポイントヘッダ（ＤＳＡＰ）、送信元サービスアクセス
ポイントヘッダ（ＳＳＡＰ）、制御ヘッダを記述する第
４フィールド（３バイト）を付加した構成をとる。

【００３６】フォーマット４は、ＩＥＥＥ８０２．３、
８０２．２、８０２．１に準拠したＯＳＩ国際標準のフ
ォーマットであり、フォーマット３の構成に、パケット
タイプ等を記述する第５フィールド（５バイト）を付加
した構成をとる。

【００３７】ここで、フォーマット１〜４は、第１フィ
ールドと第２フィールドとを備える点では共通する。

【００３８】しかし、フォーマット１は、第３フィール
ドにおいてパケットタイプを記述するのに対して、フォ
ーマット２〜４ではフレーム長を記述するという差異が
ある。

【００３９】この際、パケットタイプとは、複数種類の
上位層プロトコルを指定するためのデータであるため、
このパケットタイプを有するフォーマット１では、マル
チプロトコルを許容できることになる。例えば、ＸＮＳ
ではＩＤＰ（Internet Datagram Protocol）、ネットウ
エアではＩＰＸ、ＴＣＰ／ＩＰではＩＰがパケットタイ
プに対応する。

【００４０】また、フォーマット２は第４フィールドを
使用しないのに対して、フォーマット３〜４では第４フ
ィールドを使用するという差異もある。

【００４１】すなわち、フォーマット２では、第４フィ
ールドのＤＳＡＰ及びＳＳＡＰに相当する２バイトの領
域に、上位層で使用するチェックサムの疑似データを示
す’ＦＦＦＦ(H)’が格納される。

【００４２】これに対して、フォーマット３では、ＤＳ
ＡＰ及びＳＳＡＰの値として１６進数の’Ｅ０’（以
下、「Ｅ０(H)」という）を使用し、フォーマット４で
は、’ＡＡ(H)’を使用する。

【００４３】また、フォーマット４のみが使用する第５
フィールドには、フォーマット１の第３フィールドと同
様のパケットタイプ等が記述されるため、フォーマット
１と同様にマルチプロトコルが許容される。

【００４４】なお、フォーマット２、３は、パケットタ
イプの記述はないので、パケットタイプをネットウエア
として扱う。

【００４５】このように、上記フォーマット１〜４は、
第３フィールド以降に差異があるため、この差異を利用
してフォーマット１〜４を識別することができる。

【００４６】図４は、上記フォーマット１〜４の識別手
順を示すフローチャートである。

【００４７】まず、フォーマット１については、第３フ
ィールドを用いて識別を行う。

【００４８】すなわち、第３フィールドには、フォーマ
ット１の場合にはパケットタイプが格納されるのに対し
て、フォーマット２〜４の場合にはフレーム長が格納さ
れるため、第３フィールドの値を確認して（Ｓ４０
１）、パケットタイプが記述される場合にはフォーマッ
ト１であると判断する。

【００４９】具体的には、フレーム長は１５００バイト
以下に制限されるため、第３フィールドの値が０６００
(H)以上の場合には、パケットタイプが記述されている
と判断する。

【００５０】次に、フォーマット２〜４については、第
４フィールドを用いて識別を行う。

【００５１】すなわち、フォーマット２の場合には、第
４フィールドのＤＳＡＰ及びＳＳＡＰに相当する領域に
各々’ＦＦ(H)’が格納される。これに対して、フォー
マット３のＤＳＡＰ及びＳＳＡＰには各々”Ｅ０(H)”
が、フォーマット４の場合には各々’ＡＡ(H)’が格納
される。

【００５２】そこで、第４フィールドの２バイト（ＤＳ
ＡＰとＳＳＡＰ）が、’ＦＦＦＦ(H)’であれば（Ｓ４
０２）、フォーマット２であると判断し、’Ｅ０Ｅ０
(H)’であれば（Ｓ４０３）、フォーマット３であると
判断し、’ＡＡＡＡ(H)’であれば（Ｓ４０４）、フォ
ーマット４であると判断する。

【００５３】なお、上記フォーマット１〜４のいずれに
も該当しない場合には、サポートするコンフィグレーシ
ョンが存在しないと判断する（Ｓ４０５）。

【００５４】このように、記憶部１１ｂに記憶したノー
ド装置１がサポートするコンフィグレーションを基に、
判断部１１ａが受信パケットのコンフィグレーションを
判定（Ｓ２０２）することができる。

【００５５】このため、例えばワークステーション２〜
５がフォーマット１のコンフィグレーションを使用する
場合には、上述した一連のパケット受信処理により、ノ
ード装置１のコンフィグレーションをフォーマット１に
設定することができる。

【００５６】ところが、例えば信頼性の低い機器をワー
クステーション２〜５に用いた場合には、ワークステー
ションにフォーマット１を設定したにもかかわらず、フ
ォーマット２を誤って使用される場合がある。

【００５７】このような場合に、上記コンフィグレーシ
ョンの設定処理を実施すると、フォーマット２はノード
装置１がサポートするコンフィグレーションであるた
め、上記誤りが発生する度にコンフィグレーションのフ
ォーマットを変更する必要が生じ、ノード装置１の送信
動作を制限する結果となる。

【００５８】そこで、以下に示す第２の実施例では、上
記の誤りの都度行われる不要な設定（変更）動作を除く
ために、統計手法を適用した場合の処理手順について示
す。

【００５９】図５は、統計手法を用いてコンフィグレー
ションを設定する手順を示すフローチャートである。

【００６０】図５に示すように、前例（図２）と同様
に、イーサネットパケットを受信した（Ｓ５０１）なら
ば、Ｓ４０１〜Ｓ４０４を用いてこの受信パケットのコ
ンフィグレーションを判定し（Ｓ５０２）、当該コンフ
ィグレーションが使用可能か否かを判断する（Ｓ５０
３）。そして、使用可能と判断した場合には、受信パケ
ットのコンフィグレーションのフォーマットを記憶部１
１ｂに記憶する（Ｓ５０４）。

【００６１】次に、受信パケットの統計処理に移行する
前に、記憶部１１ｂに記憶した前回受信したパケットの
フォーマットを取り出して、受信パケットのフォーマッ
トと比較する（Ｓ５０５）。その結果、受信パケットの
フォーマットが、記憶部１１ｂに記憶された前回受信し
たパケットのフォーマットと一致するならば統計処理
（Ｓ５０６）へ移行する。これに対して、両者が一致し
ない場合には処理を終了する。

【００６２】ここで、今回受信したパケットのフォーマ
ットが、前回受信したフォーマットと一致することを統
計処理移行の条件としたのは、２度連続受信したフォー
マットを持つ受信パケットのみを統計処理の対象とする
ことにより、フォーマットに誤りのある受信パケットを
排除するためである。

【００６３】また、コンフィグレーションの統計処理
（Ｓ５０６）では、例えば各フォーマットの度数分布を
計算する等の処理を行い、この処理結果に基づいてコン
フィグレーションの設定又は変更を行うか否かの判断を
行う（Ｓ５０７）。

【００６４】ここで、上記の判断（Ｓ５０７）を行う際
には、例えば一定時間に受信したパケットのうち、ある
フォーマットのパケットが８０パーセント以上である場
合には設定を行うものと判断する。

【００６５】なお、Ｓ５０７の判断基準については、Ｓ
５０６で使用する統計処理の方式と連携して定めること
になる。

【００６６】その後、設定（変更）を行うという判断結
果の場合には、設定部１１ｃがこのコンフィグレーショ
ンを設定（変更）する（Ｓ５０８）のに対して、設定又
は変更を行わない場合には処理を終了する。

【００６７】また、この設定処理が終了したならば、こ
の設定処理が初期設定にあたるか否かを確認する（Ｓ５
０９）。そして、この設定が初期設定である場合には、
この時点ではじめてパケットの送信を許可する（Ｓ５１
０）。

【００６８】Ｓ５０９〜Ｓ５１０の処理を採用した理由
は、電源投入時のようにコンフィグレーションが確定し
ていない段階で、上位プロトコルから送信要求があった
場合に、誤ったフォーマットでパケットを組み立てて送
信することを防ぐためである。

【００６９】なお、本実施例では、２度同じフォーマッ
トを持つパケットを連続受信する（Ｓ５０４〜Ｓ５０
５）ことを、受信パケットが有効とみなすための条件と
したが、３度以上の連続受信を条件とすることも可能で
ある。

【００７０】また、統計処理（Ｓ５０６）においては、
度数分布を用いることとしたが、標準偏差等を用いた処
理を行うこともできる。

【００７１】上記の統計手法を用いた処理を行うことに
より、例えば、フォーマット１を用いてパケットの送信
を行うワークステーション２が、誤ってフォーマット２
を用いてパケットを送信した場合でも、ノード装置１の
コンフィグレーションをフォーマット２に変更すること
なく、本来使用すべきフォーマット１に設定を続行でき
る。

【００７２】また、上記実施例では、イーサネット６上
を流れるワークステーション２〜５宛のパケットを受信
した場合について説明したが、ノード装置１を宛先とす
るパケットを受信した場合についても、同様の処理が可
能である。

【００７３】上述したように、本実施例では、判断部１
１ａがイーサネット６から受信したパケットから設定す
べきコンフィグレーションを判断し、設定部１１ｃが判
断部１１ａの判断結果に基づいてコンフィグレーション
を設定することにより、イーサネット６に不要なパケッ
トを送出することなく、コンフィグレーションを自動的
に設定することができる。

【００７４】また、イーサネット６上に誤ったフォーマ
ットを持つパケットが送信された場合にも、統計手法を
用いることにより、使用頻度が高いコンフィグレーショ
ンを設定することもできる。

【００７５】さらに、本自動設定を行うことにより、デ
ータリンク層より上位層のアプリケーションを用いた試
行錯誤的送信を行う必要がなくなるため、上位層のアプ
リケーションと独立に、データリンク層レベルで、コン
フィグレーションを判断・設定しているので、ヘッダ形
式が変更された場合にもリセット処理等を行うことなく
動的にコンフィグレーションを自動設定できる。

【００７６】なお、本実施例では、ノード装置１がサポ
ートするコンフィグレーションを記憶部１１ｂに記憶す
ることとしたが、判断部１１ａ内に保持することも可能
である。

【００７７】また、本実施例では、イーサネットのデー
タリンク層の４つのフォーマットのヘッダ形式について
コンフィグレーションの判断を行ったが、同一ネットワ
ーク上に混在可能なパケットであれば本発明を適用する
ことができる。

【００７８】さらに、本発明を手動設定方式と併用し
て、状況に併せて臨機にコンフィグレーションの設定手
法を使い分けることもできる。

【００７９】なお、本実施例ではネットワークとしてイ
ーサネット６を用い、上位プロトコル群としてネットウ
エア１２（ＩＰＸ／ＳＰＸ）を用いたが、本発明は各種
ネットワーク、及びＴＣＰ／ＩＰ等の各種上位プロトコ
ルのうち、１以上のプロトコルに対して適用可能であ
る。

【００８０】

【発明の効果】以上詳細に説明したように、本発明で
は、ネットワークに接続されるノード装置においてデー
タリンク層形式を自動設定する際に、ネットワークから
の受信データからデータリンク層のヘッダの形式を判断
し、当該判断結果に応じてデータリンク層のヘッダの形
式を設定するように構成したので、ネットワークに悪影
響を及ぼすことなく、使用すべきデータリンク層のヘッ
ダの形式を自動的に設定することができる利点がある。

【００８１】更に、従来のように、上位層の自動設定用
の特別なアプリケーションを用いることなく、上位層の
アプリケーションと独立に、データリンク層レベルで、
データリンク層のヘッダ形式を判断・設定しているの
で、ヘッダ形式が変更された場合にもリセット処理等を
行うことなく動的にデータリンク層のヘッダ形式を自動
設定できる利点がある。

【図面の簡単な説明】

【図１】 本発明に係わるネットワークの全体構成とノ
ード装置の構成を示すブロック図。

【図２】 図１に示すノード装置におけるパケット受信
時の処理手順の一例を示すフローチャート。

【図３】 図１に示すノード装置にサポートされる４つ
のヘッダ形式を示す図。

【図４】 図２に示すヘッダ形式の識別手順を示すフロ
ーチャート。

【図５】 図１に示すノード装置におけるパケット受信
時の別の処理手順を示すフローチャート。

【符号の説明】

１ ノード装置、 ２〜５ ワークステーション（Ｗ
Ｓ）、６ イーサネット、 １０ イーサネットドライ
バ、１１ 自動設定モジュール、 １１ａ 判断部、
１１ｂ 記憶部、１１ｃ 設定部、 １２ ネットウエ
ア

Claims (1)

【特許請求の範囲】
1. 【請求項１】 ネットワークに接続されるノード装置に
   用いられるデータリンク層形式の自動設定装置におい
   て、 前記ネットワークからの受信データからデータリンク層
   のヘッダの形式を判断する判断手段と、 前記判断手段の判断結果から前記ノード装置におけるデ
   ータリンク層のヘッダの形式を設定する設定手段とを具
   備するデータリンク層形式の自動設定装置。