JP3834157B2

JP3834157B2 - サービス属性割り当て方法とネットワーク機器

Info

Publication number: JP3834157B2
Application number: JP34327398A
Authority: JP
Inventors: 継男岡本; 利也荒巻
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 1998-12-02
Filing date: 1998-12-02
Publication date: 2006-10-18
Anticipated expiration: 2018-12-02
Also published as: JP2000174811A

Description

【０００１】
【発明の属する技術分野】
本発明は、フローラベルと送信元アドレスとを含むフローへのサービス属性割り当て方法及びネットワーク機器に関し、特にデータの廃棄率、伝送遅延量、伝送帯域クラス、伝送優先度等のサービス属性の把握を、迅速に検出するサービス属性割り当て方法及びネットワーク機器に関する。
【０００２】
【従来の技術】
従来、さまざまな属性を有するパケットが存在する通信網で、サービス属性に適した回線を設置して通信効率を図るために、プロトコルによるヘッダ構造の差異による属性を分別したり、ヘッダ情報に含まれる情報によってサービス属性を分別する方法が存在した（特開平１０−０１３４３４号公報）。
【０００３】
また、ヘッダ情報に含まれる情報を解析するための方法として、図３に示されるレイヤ４プロトコルのヘッダに含まれるDestination Port（宛先ポート）番号とSource Port（送信元ポート）番号によって分別する方法が存在する。この図３に示すヘッダ構造は、インターネット上のＴＣＰ／ＩＰプロトコルのＩＰｖ６の構造であり、基本ヘッダ部はＩＳＯ参照モデルのレイヤ３のネットワーク層に対応するコネクション型のＩＰ層を示し、ＩＰが転送するパケットはデータグラムと呼んでおり、レイヤ４のトランスポート層に対応するＴＣＰ層を示している。
【０００４】
ここで、ＯＳＩ参照モデルとＴＣＰ／ＩＰプロトコルとを対比すると、ＯＳＩ参照モデルの７レイヤに対して、ＴＣＰ／ＩＰプロトコルでは、第１レイヤと第２レイヤをネットワークインターフェース層とし、第３レイヤのネットワーク層に対してＩＰを代表とするインターネット層とし、第４レイヤのトランスポート層に対してＴＣＰを代表とするトランスポート層とし、第５レイヤから第７レイヤに対してNETBIOSやHTTP,DNSを代表とするアプリケーション層としている。
【０００５】
図３において、ＩＰデータグラムの最初の４ビットにはＩＰのバージョン番号を入れ、この場合にはバージョン６を示し、次の４ビットにはＩＰのクラスを入れ、Ａ，Ｂ，Ｃ，Ｄ，Ｅのクラスのいずれかを指定する。また、次の２４ビットのフローラベルはＩＰに対する実験的な部分が残されており、これがＴＣＰ／ＩＰの将来のキーであると考えられている。フローラベルは送信元アドレスと組み合わせて、ネットワーク中の特定のトラフィック・フローを見分けるために使われる。次の１６ビットはペイロード長フィールドであり、ＩＰ基本ヘッダの後のＩＰデータグラムの残りの部分の全長をバイト単位で示すものである。次の８ビットは次ヘッダであり、データグラム中の基本ＩＰヘッダの次のヘッダを識別するためで、オプションの拡張ＩＰヘッダの有無や上位層のプロトコルがここに示される。次の８ビットはホップ制限であり、データグラムをどれくらい遠くまで転送できるかを示し、ルータに渡される度に１を引かれ、０になったら廃棄される。次の１２８ビットが送信元アドレスであり、その次の１２８ビットが宛先アドレスである。
【０００６】
この後、ＩＰｖ６では上記ＩＰの基本ヘッダの次に複数のＩＰ拡張ヘッダを有することが認められている。図３では拡張ヘッダを２つ有する例を示し、その最初の８ビットで次のヘッダを指示し、次の８ビットでヘッダ長を示し、そのヘッダ長の区間に拡張ヘッダ用データ領域を有し、例えばホップ毎オプションでデータグラムの経路上の全てのシステムに対するＩＰオプションであり、パス上の全てのルータは、ホップ毎オプションヘッダを見て、その処理を行う。
【０００７】
次に、拡張ヘッダ用データ領域を有する拡張ヘッダの後に、ＩＳＯ参照モデルのトランスポート層として、ＴＣＰ層が対応している。このＴＣＰ層の構成が図３に示されており、最初の１６ビットの送信元ポート番号と、次の１６ビットの宛先ポート番号で、宛先ポート番号によってそれがどのようなアプリケーションにデータを引き渡すのかを示している。次の３２ビットのシーケンス番号、次の３２ビットの受信確認番号、次の３２ビットにオフセット、予約、制御用、ウインドウとを指定し、パケットに欠如がないかを調べ、情報が正常に転送されているか否かを確認するためのものである。次のチェックサムはデータ誤り訂正符号であり、緊急ポインタは本ＩＰデータの緊急度に対応したものである。続いてＴＣＰオプションの後にＴＣＰアプリケーション・データを備えている。
【０００８】
また、図４に従来のＩＰｖ４に使用するヘッダ部のフォーマットを示す。ＩＰｖ４のヘッダ内において、バージョンフィールドにはバージョン番号である「４」が格納される。「ヘッダ長」フィールドには、ＩＰで取り扱われるデータブロックにＩＰｖ４ヘッダを加えたパケット全体の大きさが格納される。「サービスタイプ」フィールドには通信処理のサービス品位を示す情報が格納され、「パケット長」フィールドには、該ヘッダ部を含むパケット全体の大きさを格納している。「識別子」フィールドには上位層へデータを渡す際の参考情報として用いられる識別子が格納され、「フラグ」フィールドにはパケットの分割に関する制御情報が格納され、「フラグメントオフセット」フィールドには分割されたデータがオリジナルデータのどこに位置しているかの情報を格納し、「生存期間」には、そのパケットがネットワークに存在してよい時間が格納され、「プロトコル」フィールドには、上位層のプロトコルが何であるかを示す情報が格納され、「ヘッドチェックサム」フィールドには、該ＩＰヘッダのチェックサムが格納され、「送信元アドレス」の３２ビットフィールドには、送信元のＩＰアドレスが格納され、「宛先アドレス」の３２ビットフィールドには、宛先のＩＰアドレスが格納される。ＩＰアドレスは、ネットワークに接続される各ノードに割り当てられるもので、そのネットワーク内において、それぞれ異なる値に設定される。
【０００９】
上述したＩＰｖ６のＴＣＰのヘッダ部中、このＴＣＰのレイヤ４プロトコルや、ＩＰのレイヤ３プロトコルは、ＩＰｖ４（インターネットプロトコル・バージョン４）を想定したものであったため、パケットヘッダの先頭から固定長のデータを取り出し、このデータの特定の位置のフィールドを取り出すことで、ＩＰｖ４フォーマットでは、単純かつ確実に、Destination Port番号とSource Port番号を取得できた。そして、この情報を元にサービス属性を決定できた。
【００１０】
【発明が解決しようとする課題】
しかしながら、この従来技術で、ＩＰｖ６では、パケットの先頭（ＩＰｖ６基本ヘッダ部）からレイヤ４プロトコルのヘッダの位置が可変長であり、かつＩＰｖ６の基本ヘッダとトランスポート層プロトコル領域の間に、複数段の拡張ヘッダと呼ばれる領域が存在し、複数存在する拡張ヘッダの属性と長さを解析しなければ、ＴＣＰ層のレイヤ４プロトコルヘッダの位置を特定できず、サービス属性を認識することが容易ではない。その点、ＩＰｖ４の様に基本ヘッダ部の次にすぐサービス属性を表すオプション用ヘッド部が存在するので、サービス属性の把握が速く且つ容易である。ＩＰｖ６による、基本ヘッダ部から拡張ヘッダ用データ領域、その次でなければ、Destination Port番号とSource Port番号を取得することができないという問題点を有していた。更に、正確なサービス属性を取得するためには、ＴＣＰオプションの領域か、ＴＣＰアプリケーション領域から取得することができず、次のアプリケーションの立ち上げに支障が生じることもある。
【００１１】
また、新しいバージョンを推奨されてから全てのインターネットが新しいバージョンに変更されるまで、１０年以上を要することから、ＩＰｖ４とＩＰｖ６との両者のプロトコル処理を可能とするデュアル・スタック形式のホストも増加しているが、その場合も、サービス属性を早期に決定してサービス態勢を迅速に準備する必要がある。
【００１２】
本発明は、上記問題点を解決するもので、ヘッダ部に格納されたサービス属性を高速に読み出し、特に、ＩＰ層の上位レイヤのデータが固定位置に存在しないＩＰｖ６プロトコルであっても、パケットの属するサービス属性を決定する処理負荷を軽減できることを課題とする。
【００１３】
【課題を解決するための手段】
本発明は、通信経路を介してサービスを受けるインターネットのサービス属性割り当て方法において、少なくともフローラベルと送信元アドレスと宛先アドレスを格納して通信プロトコルに従って送信されてくるＩＰパケットに対し、該送信元アドレスと前記フローラベルとサービス属性の関係を登録したサービス属性テーブルを参照し、前記サービス属性テーブルに前記送信元アドレスと前記フローラベルとが登録されていた場合には、ＩＰレイヤの上位層のサービスを提供し、前記サービス属性テーブルに前記送信元アドレスと前記フローラベルとが登録されていない場合には前記ＩＰパケットに格納された送信元アドレス、送信先アドレス、送信元および送信先ポート番号情報に加え、上位プロトコルのデータ解析処理で抽出されるデータの内容を用いてサービス属性を検索して、前記送信元アドレスと前記フローラベルと前記サービス属性とを対として前記サービス属性テーブルに登録して前記ＩＰレイヤの上位層のサービスを提供することを特徴とする。
【００１４】
また、本発明は、通信経路を介してサービスを受けるインターネットのネットワーク機器において、少なくともフローラベルと送信元アドレスと宛先アドレスを格納して所定の通信プロトコルに従ってＩＰパケットを送信する送信手段から該ＩＰパケットを受ける受信手段と、前記送信元アドレスと前記フローラベルとサービス属性の関係を登録したサービス属性テーブルと、前記ＩＰパケットの少なくとも前記フローラベルと前記送信元アドレスとを前記サービス属性テーブルに参照するサービス属性検出手段と、を備え、前記サービス属性テーブルに前記送信元アドレスと前記フローラベルとが登録されていた場合には、ＩＰレイヤの上位層のサービスを提供し、前記サービス属性テーブルに前記送信元アドレスと前記フローラベルとが登録されていない場合には前記ＩＰパケットに格納された送信元アドレス、送信先アドレス、送信元および送信先ポート番号情報に加え、上位プロトコルのデータ解析処理で抽出されるデータの内容を用いてサービス属性を検索して、前記送信元アドレスと前記フローラベルと前記サービス属性とを対として前記サービス属性テーブルに登録して前記ＩＰレイヤの上位層のサービスを提供することを特徴とする。
【００１５】
以下、本発明と従来例とを対比しつつ、本発明の特徴を説明する。
【００１６】
従来、端末を含むネットワーク機器において、レイヤ３プロトコル（ＩＰ:Internet Protocol）に加えて、レイヤ４以上のプロトコルの情報を用いてサービス属性を決定して、ＱｏＳ制御や優先制御に利用されることが行われている。次世代インターネットプロトコルＩＰｖ６では、図３のヘッダ部構成に示すように、パケット毎に拡張ヘッダの構造の解析を行わなければ、レイヤ４プロトコル情報の位置を特定することができないため、処理時間を要し、処理負荷が大きくなる。
【００１７】
本発明では、ＩＰｖ６の基本ヘッダにある送信元アドレス（Source Address）と、フローラベル（Flow Label）フィールドの組とサービス属性の関係表を、動的に作成することにより、サービス属性の抽出のため処理負荷を軽減するものである。
【００１８】
また、従来ＩＰｖ４プロトコルを利用したネットワーク上のネットワーク機器が、レイヤ４のプロトコルＴＣＰやＵＤＰのポート番号の情報を用いて、サービス属性の決定を行うときは、Ｐｏｒｔ番号解析（図２のステップ３０６）とルール参照処理（ステップ３０８）をパケット毎に実行しても、高速にサービス属性抽出処理を終了することができた。これは、ＩＰｖ４パケットに含まれるSource Port番号とDestination Port番号の領域が、固定位置に存在する場合がほとんどだからである。しかし、ＩＰｖ６プロトコルの場合は通常ＩＰｖ６パケットは図３のような基本ヘッダと拡張ヘッダ、ＴＣＰ／ＵＤＰプロトコルデータで構成される構造を持っているために、パケットのＴＣＰ／ＵＤＰプロトコルデータの位置を解析するためのＰｏｒｔ番号解析処理（ステップ３０６）の負荷が大きかったため、高速にサービス属性決定処理を終了することが困難であった。
【００１９】
ＩＰｖ６プロトコルではフロー（フローラベルと送信元アドレス）ラベルと呼ばれる概念が導入され、Source AddressとDestination Address、及びSource Port番号とDestination Port番号が同一のパケットは同じフロー（フローラベルと送信元アドレス）ラベルに属するとして、フロー（フローラベルと送信元アドレス）ラベルに唯一な値であるFlowlabelを設定することにより、ネットワーク上の機器はSource AddressとFlowlabelの組を利用することにより、複数のフロー（フローラベルと送信元アドレス）ラベルに属するパケットを識別することができる。
【００２０】
ただし、フロー（フローラベルと送信元アドレス）ラベルを識別できても、ＱｏＳ（Quality of Service）制御や優先制御を行うためのサービス属性ができない。本発明では、フロー（フローラベルと送信元アドレス）ラベル（ＩＰｖ６のSource AddressとFlowlabelの組)と、サービス属性の関係が作成されていないときは、パケットの拡張ヘッダ構造の解析を行い、レイヤ４プロトコル情報を抽出し、ルール参照処理によって、レイヤ４プロトコル情報に対応するサービス属性を決定する。決定後、ＩＰｖ６のSource AddressとFlowlabelの組と、ルール参照処理で検索したサービス属性の関係をサービス属性検索テーブルに登録する処理(図２のステップ３１０）を行い、登録後にネットワーク機器に到着する同一フロー（フローラベルと送信元アドレス）ラベルがレイヤ４プロトコル情報の抽出のための拡張ヘッダ構造解析処理を除くことができ、サービス属性の決定のための処理を軽減させることができる。
【００２１】
【発明の実施の形態】
本発明の実施形態について、図面を参照しつつ詳細に説明する。
【００２２】
[第１の実施形態]
（本実施形態の構成）
本第１の実施形態の概念的構成例を図１に示す。図１において、ＬＡＮ１には複数のパソコン１１とルータ１２とがイーサネット（登録商標）等の物理層を設定するプロトコルにより接続されており、ルータ１２には複数のハブ１３が１０ＢＡＳＥ−Ｔ等で接続され、ハブ１３にはパソコン１４，１５が接続され、パソコン１１，１４，１５間ではそれぞれＴＣＰ／ＩＰプロトコルによりデータの送受信を行うネットワークを組んでいる。
【００２３】
また、ルータ１２は公衆回線やＩＳＤＮ回線を介してパケット交換局やデジタル交換局等のスイッチに接続され、インターネット通信を可能としている。また、ＷＡＮ２には、ＷＡＮ２内に専用線を用いて複数のネットワークに接続されており、その代表としてパソコン３２が接続されている。ＷＡＮ２内には共通の通信プロトコルとしてＴＣＰ／ＩＰを使うことができる。この場合、ＬＡＮ１で例えばUNIX系でコネクションレス型として使用されるＵＤＰ（User Datagram Protocol）や、NetWearで使用されるIPX/SPXや、NetBIOSの拡張版プロトコルで使用されるNetBEUI等を用いてもよい。
【００２４】
また、ＬＡＮ１とＷＡＮ２とを公衆回線を用いずに接続する場合のローカルブリッジや、ＩＳＤＮ回線網等を介してＬＡＮ間を接続するリモートブリッジ等をスイッチの代わりに用いてもよい。
【００２５】
また、ＬＡＮシステムやＷＡＮシステム等は、パケット交換ネットワーク技術のプロトコルであるイーサネットで組まれることが多く、１０ＢＡＳＥ−Ｔを使うツインペア線や１０ＢＡＳＥ５や１０ＢＡＳＥ２を使う同軸ケーブルを用いて接続され、ＣＳＭＡ／ＣＤ方式でデータの衝突防止を図っている。また、トークンリンクで組まれる場合もあり、トークンパッシング方式によりリング状にパソコンを接続し、パケットを入れる容器のトークンを巡回させて用い、この方式であってもよい。
【００２６】
このような構成で、パソコン１５からＴＣＰ／ＩＰのＩＰｖ４で宛先パソコンをパソコン１１としてデータ出力された場合、ハブ１３を介してルータ１２は宛先を読み込んで即座にパソコン１１にデータを転送する。パソコン１１はこのＩＰｖ４のヘッダ部を読み込むと共にその上位層のデータを読み込んで、アプリケーション層に求められたデータ処理を行う。
【００２７】
この際、パソコン１５からＩＰｖ６で宛先パソコンをパソコン１１としてデータ出力した場合、ルータ１２またはパソコン１１は、図３に示すＩＰｖ６の各ビットを読み込み・解析すると共にフロー・ラベル（Flow label）と送信元アドレス（Source Address）を読み込んで、当該パソコン１５の求めるサービス属性をサービス属性テーブルから割り出し、ＯＳＩ参照モデルの第５レイヤ乃至第７レイヤに求められるアプリケーション層のデータ処理を行う。
【００２８】
ここで、サービス属性テーブルの参考例を、表１に示す。
【００２９】
【表１】

【００３０】
本表１から、フローラベルと送信元アドレスが判れば、そのサービス属性が取得できるので、次のアプリケーション層による負担を事前に判断し、負担増の場合にはパイプライン的に２つのパソコンに振り分けるなどの対策が高速に取れることになる。また特定フローラベルと特定送信元アドレスとから決まるサービス属性は１つに限ればよいが、複数であっても、登録されて複数あってもよく、また、同一の特定フローラベルと特定送信元アドレスで、複数のサービス属性を用いることができるとしてもよい。
【００３１】
また、パソコン１４からパソコン３２を宛先アドレスとしてＩＰｖ６にてデータパケットを送信しようとした場合、ハブ１３やルータ１２、スイッチ２１、ルータ３１を介してパソコン３２に転送されるが、この場合も各中継装置がそれぞれ有するサービス属性テーブルに、フローラベルと送信元アドレスとそのサービス属性を登録している場合には、その登録に従ってサービス属性を解釈して適切な動作を行って高速転送を可能とする。又、登録されていなかった場合には、サービス属性テーブルに新規にフローラベルと送信元アドレスとそのサービス属性を登録する。
【００３２】
（本実施形態の動作の説明）
次に、図２のフローチャートを参照して本実施形態の全体の動作について、詳細に説明する。
【００３３】
本発明は、例えば、ＩＰｖ６プロトコルを扱うパケットを転送する装置であるルータ、ハブ、スイッチおよび端末等で利用され、フロー（フローラベルと送信元アドレス）ラベルからサービス属性を求めることによりＱｏＳ制御や優先制御を決定する装置に利用される。
【００３４】
図２において、本発明を利用したサービス属性検索処理手段にＩＰｖ６パケットが入力されたとする（ステップ３０１）。次に、ＩＰｖ６プロトコルで規定されたＩＰｖ６パケットの正当性の検査を行う（ステップ３０２）。本発明のサービス属性処理手段を利用した装置が既にＩＰｖ６のパケットヘッダの正当性の検査を行っている場合は、ステップ３０２とステップ３０３の処理を省略することができる。
【００３５】
つぎに、ＩＰｖ６パケットの正当性の検査で異常になった場合は（ステップ３０３）、管理機能への報告やパケット廃棄等のエラー処理を行う（ステップ３１１）。
【００３６】
入力したＩＰｖ６パケットが正常である場合は、サービス属性検索処理（ステップ３０４）で利用するＩＰｖ６のSource AddressとFlowlabelの組と対応するサービス属性が記録されたサービス属性テーブルの中から、ＩＰｖ６パケットのＩＰｖ６のSource AddressとFlowlabelの組と一致するエントリーを検索して、サービス属性を抽出する（ステップ３０４）。
【００３７】
サービス属性の抽出が成功した場合は、サービス属性検索処理手段を終了する（ステップ３０５）。例えば、本発明のサービス属性検索処理手段の実行を依頼した機能あるいは手段に対して、抽出したサービス属性を通知する。
【００３８】
サービス属性の抽出が失敗した場合は、フローラベルとサービス属性の関係がサービス属性テーブルに登録していない場合である。入力したＩＰｖ６パケットからＴＣＰやＵＤＰ等の上位プロトコルのＰｏｒｔ番号を抽出する（ステップ３０６）。ここで、Ｐｏｒｔ番号を抽出するためには、図３で示すような、拡張ヘッダの構造の解析処理を行い、上位プロトコルのデータの存在する位置を検索して、ＴＣＰやＵＤＰ等の上位プロトコルのＰｏｒｔ番号を抽出する。
【００３９】
Ｐｏｒｔ番号解析が失敗したか否かを調べて、成功したらステップ３０８へ、失敗したらサービス属性検索処理手段を終了する。失敗した場合は上位プロトコルがＴＣＰ／ＵＤＰ以外である場合なので、Ｐｏｒｔ番号でサービス属性を決定できない場合である。例えば、本発明のサービス属性検索処理手段の実行を依頼した機能あるいは手段に対して、サービス属性の検索が失敗したことを通知する。
【００４０】
つぎに、Ｐｏｒｔ番号解析が成功した場合は、ＩＰｖ６パケットのＩＰｖ６のDestination Address、Source Address、抽出したDestination Port（宛先ポート）番号、Source Port（送信元ポート）番号に対応するサービス属性を、ルール参照テーブルから検索する(ステップ３０８）。
【００４１】
ステップ３０８のルール参照処理によるサービス属性の検索が成功した場合は、ＩＰｖ６パケットのＩＰｖ６のSource AddressとFlowlabelの組と、抽出したサービス属性を、サービス属性テーブルに登録する（ステップ３１０）。検索が失敗した場合は、サービス属性検索処理手段の実行を終了する。
【００４２】
次に、同じフロー（フローラベルと送信元アドレス）ラベルに属するＩＰｖ６パケットが到着して、パケットの属するサービス属性を検索するときは、ステップ３０４のサービス属性検索によってサービス属性を抽出することができるので、Ｐｏｒｔ番号解析処理（ステップ３０６）やルール参照処理（ステップ３０８）を省略して、検索処理を高速に終了することができる。
【００４３】
本発明は端末を含むネットワーク機器全てに適用可能である。例えばルータ、ハブ、スイッチ、ブリッジ装置に適用することができる。
【００４４】
［第２の実施形態］
図２において、Ｐｏｒｔ番号解析処理（ステップ３０６）を拡張して、上位プロトコルのデータ解析処理も行うことで、通常Ｐｏｒｔ番号から予測できるアプリケーションの種別の他に、転送しているデータの内容を抽出できるため、より細かなサービス属性を、フロー（フローラベルと送信元アドレス）ラベルに対して割り当てることができる。
【００４５】
具体的には、例えばＴＣＰやＵＤＰの上位レイヤで用いられるＨＴＴＰプロトコルのデータの内容を解析することで、アプリケーションがテキストデータ、画像データ、音声データを利用していることが判明する。ＴＣＰやＵＤＰの上位レイヤの解析は、検索処理の手順を多く必要とし、また複数パケットにまたがることがあるが、本実施形態によるサービス属性検索処理手段を用いることで、初期段階のパケットの処理手順は大きくなるが、サービス属性テーブル登録後は、ＩＰｖ６のSource AddressとFlowlabelから検索すればよくなり、上位プロトコルデータ解析処理の負荷を軽減することができる。
【００４６】
また、ＴＣＰやＵＤＰの上位レイヤ以外のＩＣＭＰ（Internet Control Message Protocol）等の上位レイヤの種別によって、サービス属性を抽出することもできる。このＩＣＭＰはインターネット層の最小限の機能を補うもので、ＴＣＰ／ＩＰではこれらを１つのプロトコルにまとめたものである。ＩＣＭＰメッセージ・フォーマットはバラエティ豊かな役割を有し、本実施形態による上位レイヤのサービスを特定することもできる。
【００４７】
この場合、Ｐｏｒｔ番号解析処理でＰｏｒｔ番号を取得できないプロトコルの場合は、上位プロトコル番号を抽出し、またルール参照テーブルをＩＰｖ６のDestination Address、Source Address、Destination Port番号、Source Port番号に上位プロトコル番号を加え、さらにステップ３０７でＴＣＰ／ＵＤＰ以外による分岐処理を省略して、全ての場合にルール参照処理（ステップ３０８）に手順を移すようにすることで実現できる。上位プロトコル番号はＩＰｖ６パケットの一番最後に位置する拡張ヘッダのNext ExtHDR noを調べることで識別できる。
【００４８】
【発明の効果】
本発明によれば、パケット毎にＩＰｖ６パケットの拡張ヘッダ構造の解析を行って、上位レイヤのDestination Port番号、Source Port番号を抽出しており、処理負荷になっていたが、ＩＰｖ６のフローラベルの概念を利用してＩＰｖ６ Source AddressとFlowlabelに対して、サービス属性をサービス属性テーブルに登録するために、一度登録したフローラベルに属するパケット（同一のDestination Address、Source Address、Destination Port番号、Source Port番号を持つ）は、ＩＰｖ６パケットの固定位置に存在するSource AddressとFlow labelの組を検索するだけで、サービス属性を取得することができるので、ＩＰ層の上位レイヤのデータが固定位置に存在しないＩＰｖ６プロトコルであっても、パケットの属するサービス属性を決定する処理負荷を軽減できる。
【図面の簡単な説明】
【図１】発明の実施形態による通信システムのフローラベル割当方法の説明図である。
【図２】発明の実施形態の動作を示すフローチャートである。
【図３】ＩＰｖ６プロトコルで利用されるパケットの例を示す図である。
【図４】従来のＩＰｖ４に使用するヘッダ部のフォーマットである。
【符号の説明】
１ＬＡＮ
２ＷＡＮ
１１，１４，１５，３２パソコン
１２，３１ルータ
１３ハブ
２１スイッチ又はブリッジ

Claims

通信経路を介してサービスを受けるインターネットのサービス属性割り当て方法において、
少なくともフローラベルと送信元アドレスと宛先アドレスを格納して通信プロトコルに従って送信されてくるＩＰパケットに対し、
該送信元アドレスと前記フローラベルとサービス属性の関係を登録したサービス属性テーブルを参照し、
前記サービス属性テーブルに前記送信元アドレスと前記フローラベルとが登録されていた場合には、ＩＰレイヤの上位層のサービスを提供し、
前記サービス属性テーブルに前記送信元アドレスと前記フローラベルとが登録されていない場合には前記ＩＰパケットに格納された送信元アドレス、送信先アドレス、送信元および送信先ポート番号情報に加え、上位プロトコルのデータ解析処理で抽出されるデータの内容を用いてサービス属性を検索して、前記送信元アドレスと前記フローラベルと前記サービス属性とを対として前記サービス属性テーブルに登録して前記ＩＰレイヤの上位層のサービスを提供することを特徴とするサービス属性割り当て方法。
請求項１に記載のサービス属性割り当て方法において、前記通信プロトコルはＩＰｖ４（インターネット・プロトコル・バージョン４）に対するＩＰｖ６であることを特徴とするサービス属性割り当て方法。
請求項１又は２に記載のサービス属性割り当て方法において、前記ＩＰパケットのヘッダ部に格納したデータに従って、順次前記ヘッダ部のデータ処理を行い、前記ヘッダ部の正当性を判断し、次に前記サービス属性テーブルを参照して登録されていれば、登録されているサービス属性に基づいて前記ＩＰレイヤの上位層のサービスを提供し、登録されていなければ次に前記ＩＰパケットに格納されたポート番号を解析してポート番号の取得が可能で有れば更に前記ＩＰパケットに格納された送信元アドレス、送信先アドレス、送信元および送信先ポート番号情報を用いてサービス属性を検索して、前記送信元アドレスと前記フローラベルと前記サービス属性とを対として前記サービス属性テーブルに登録することを特徴とするサービス属性割り当て方法。
請求項１又は、２，３に記載のサービス属性割り当て方法において、前記サービス属性にはデータの廃棄率、伝送遅延量、伝送帯域クラス、伝送優先度の少なくとも一つを含み、前記インターネットはイーサネット（登録商標）又はトークンリンクのＬＡＮ又はＷＡＮであることを特徴とするサービス属性割り当て方法。
通信経路を介してサービスを受けるインターネットのネットワーク機器において、
少なくともフローラベルと送信元アドレスと宛先アドレスを格納して所定の通信プロトコルに従ってＩＰパケットを送信する送信手段から該ＩＰパケットを受ける受信手段と、前記送信元アドレスと前記フローラベルとサービス属性の関係を登録したサービス属性テーブルと、
前記ＩＰパケットの少なくとも前記フローラベルと前記送信元アドレスとを前記サービス属性テーブルに参照するサービス属性検出手段と、を備え、
前記サービス属性テーブルに前記送信元アドレスと前記フローラベルとが登録されていた場合には、ＩＰレイヤの上位層のサービスを提供し、
前記サービス属性テーブルに前記送信元アドレスと前記フローラベルとが登録されていない場合には前記ＩＰパケットに格納された送信元アドレス、送信先アドレス、送信元および送信先ポート番号情報に加え、上位プロトコルのデータ解析処理で抽出されるデータの内容を用いてサービス属性を検索して、前記送信元アドレスと前記フローラベルと前記サービス属性とを対として前記サービス属性テーブルに登録して前記ＩＰレイヤの上位層のサービスを提供することを特徴とするネットワーク機器。
請求項５に記載のネットワーク機器において、前記サービス属性にはデータの廃棄率、伝送遅延量、伝送帯域クラス、伝送優先度の少なくとも一つを含み、前記通信プロトコルはＩＰｖ４（インターネット・プロトコル・バージョン４）に対するＩＰｖ６であることを特徴とするネットワーク機器。
請求項５に記載のネットワーク機器は、ハブ、ルータ、スイッチ、又はブリッジであることを特徴とするネットワーク機器。