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

Abstract

(57)【要約】 【課題】 ヘッダ部のサービス属性を高速に読み出し、
上位レイヤのデータが固定位置に存在しないＩＰｖ６プ
ロトコルであっても、パケットの属するサービス属性を
決定する処理負荷を軽減することを課題とする。 【解決手段】 通信経路を介してサービスを受けるイン
ターネットのサービス属性割り当て方法において、少な
くともフローラベルと送信元アドレスと宛先アドレスを
格納して通信プロトコルに従って送信され、該送信元ア
ドレスと前記フローラベルとサービス属性の関係を登録
したサービス属性テーブルを参照し、前記サービス属性
テーブルに前記送信元アドレスと前記フローラベルとが
登録されていた場合には、前記通信プロトコルの上位層
のサービスを提供し、登録されていない場合には前記送
信元アドレスと前記フローラベルと前記サービス属性と
を対として前記サービス属性テーブルに登録して前記通
信プロトコルの上位層のサービスを提供することを特徴
とする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、フローラベルと送
信元アドレスとを含むフローへのサービス属性割り当て
方法及びネットワーク機器に関し、特にデータの廃棄
率、伝送遅延量、伝送帯域クラス、伝送優先度等のサー
ビス属性の把握を、迅速に検出するサービス属性割り当
て方法及びネットワーク機器に関する。

【０００２】

【従来の技術】従来、さまざまな属性を有するパケット
が存在する通信網で、サービス属性に適した回線を設置
して通信効率を図るために、プロトコルによるヘッダ構
造の差異による属性を分別したり、ヘッダ情報に含まれ
る情報によってサービス属性を分別する方法が存在した
（特開平１０−０１３４３号公報）。

【０００３】また、ヘッダ情報に含まれる情報を解析す
るための方法として、図３に示されるレイヤ４プロトコ
ルのヘッダに含まれるDestination Port（宛先ポート）
番号とSource Port（送信元ポート）番号によって分別
する方法が存在する。この図２に示すヘッダ構造は、イ
ンターネット上のＴＣＰ／ＩＰプロトコルのＩＰｖ６の
構造であり、基本ヘッダ部はＩＳＯ参照モデルのレイヤ
３のネットワーク層に対応するコネクション型のＩＰ層
を示し、ＩＰが転送するパケットはデータグラムと呼ん
でおり、レイヤ４のトランスポート層に対応するＴＣＰ
層を示している。

【０００４】ここで、ＯＳＩ参照モデルとＴＣＰ／ＩＰ
プロトコルとを対比すると、ＯＳＩ参照モデルの７レイ
ヤに対して、ＴＣＰ／ＩＰプロトコルでは、第１レイヤ
と第２レイヤをネットワークインターフェース層とし、
第３レイヤのネットワーク層に対してＩＰを代表とする
インターネット層とし、第４レイヤのトランスポート層
に対してＴＣＰを代表とするトランスポート層とし、第
５レイヤから第７レイヤに対してNETBIOSやHTTP,DNSを
代表とするアプリケーション層としている。

【０００５】図２において、ＩＰデータグラムの最初の
４ビットにはＩＰのバージョン番号を入れ、この場合に
はバージョン６を示し、次の４ビットにはＩＰのクラス
を入れ、Ａ，Ｂ，Ｃ，Ｄ，Ｅのクラスのいずれかを指定
する。また、次の２４ビットのフロー（フローラベルと
送信元アドレス）ラベルはＩＰに対する実験的な部分が
残されており、これがＴＣＰ／ＩＰの将来のキーである
と考えられている。フローラベルは送信元アドレスと組
み合わせて、ネットワーク中の特定のトラフィック・フ
ローを見分けるために使われる。次の１６ビットはペイ
ロード長フィールドであり、ＩＰ基本ヘッダの後のＩＰ
データグラムの残りの部分の全長をバイト単位で示すも
のである。次の８ビットは次ヘッダであり、データグラ
ム中の基本ＩＰヘッダの次のヘッダを識別するためで、
オプションの拡張ＩＰヘッダの有無や上位層のプロトコ
ルがここに示される。次の８ビットはホップ制限であ
り、データグラムをどれくらい遠くまで転送できるかを
示し、ルータに渡される度に１を引かれ、０になったら
廃棄される。次の１２８ビットが送信元アドレスであ
り、その次の１２８ビットが宛先アドレスである。

【０００６】この後、ＩＰｖ６では上記ＩＰの基本ヘッ
ダの次に複数のＩＰ拡張ヘッダを有することが認められ
ている。図２では拡張ヘッダを２つ有する例を示し、そ
の最初の８ビットで次のヘッダを指示し、次の８ビット
でヘッダ長を示し、そのヘッダ長の区間に拡張ヘッダ用
データ領域を有し、例えばホップ毎オプションでデータ
グラムの経路上の全てのシステムに対するＩＰオプショ
ンであり、パス上の全てのルータは、ホップ毎オプショ
ンヘッダを見て、その処理を行う。

【０００７】次に、拡張ヘッダ用データ領域を有する拡
張ヘッダの後に、ＩＳＯ参照モデルのトランスポート層
として、ＴＣＰ層が対応している。このＴＣＰ層の構成
が図２に示されており、最初の１６ビットの送信元ポー
ト番号と、次の１６ビットの宛先ポート番号で、宛先ポ
ート番号によってそれがどのようなアプリケーションに
データを引き渡すのかを示している。次の３２ビットの
シーケンス番号、次の３２ビットの受信確認番号、次の
３２ビットにオフセット、予約、制御用、ウインドウと
を指定し、パケットに欠如がないかを調べ、情報が正常
に転送されているか否かを確認するためのものである。
次のチェックサムはデータ誤り訂正符号であり、緊急ポ
インタは本ＩＰデータの緊急度に対応したものである。
続いてＴＣＰオプションの後にＴＣＰアプリケーション
・データを備えている。

【０００８】また、図４に従来のＩＰｖ４に使用するヘ
ッダ部のフォーマットを示す。ＩＰｖ４のヘッダ内にお
いて、バージョンフィールドにはバージョン番号である
「４」が格納される。「ヘッダ長」フィールドには、Ｉ
Ｐで取り扱われるデータブロックにＩＰｖ４ヘッダを加
えたパケット全体の大きさが格納される。「サービスタ
イプ」フィールドには通信処理のサービス品位を示す情
報が格納され、「パケット長」フィールドには、該ヘッ
ダ部を含むパケット全体の大きさを格納している。「識
別子」フィールドには上位層へデータを渡す際の参考情
報として用いられる識別子が格納され、「フラグ」フィ
ールドにはパケットの分割に関する制御情報が格納さ
れ、「フラグメントオフセット」フィールドには分割さ
れたデータがオリジナルデータのどこに位置しているか
の情報を格納し、「生存期間」には、そのパケットがネ
ットワークに存在してよい時間が格納され、「プロトコ
ル」フィールドには、上位層のプロトコルが何であるか
を示す情報が格納され、「ヘッドチェックサム」フィー
ルドには、該ＩＰヘッダのチェックサムが格納され、
「送信元アドレス」の３２ビットフィールドには、送信
元のＩＰアドレスが格納され、「宛先アドレス」の３２
ビットフィールドには、宛先のＩＰアドレスが格納され
る。ＩＰアドレスは、ネットワークに接続される各ノー
ドに割り当てられるもので、そのネットワーク内におい
て、それぞれ異なる値に設定される。

【０００９】上述したＩＰｖ６のＴＣＰのヘッダ部中、
このＴＣＰのレイヤ４プロトコルや、ＩＰのレイヤ３プ
ロトコルは、ＩＰｖ４（インターネットプロトコル・バ
ージョン４）を想定したものであったため、パケットヘ
ッダの先頭から固定長のデータを取り出し、このデータ
の特定の位置のフィールドを取り出すことで、ＩＰｖ６
フォーマットでは、単純かつ確実に、Destination Port
番号とSource Port番号を取得できた。そして、この情
報を元にサービス属性を決定できた。

【００１０】

【発明が解決しようとする課題】しかしながら、この従
来技術で、ＩＰｖ６では、パケットの先頭（ＩＰｖ６基
本ヘッダ部）からレイヤ４プロトコルのヘッダの位置が
可変長であり、かつＩＰｖ６の基本ヘッダとトランスポ
ート層プロトコル領域の間に、複数段の拡張ヘッダと呼
ばれる領域が存在し、複数存在する拡張ヘッダの属性と
長さを解析しなければ、ＴＣＰ層のレイヤ４プロトコル
ヘッダの位置を特定できず、サービス属性を認識するこ
とが容易ではない。その点、ＩＰｖ４の様に基本ヘッダ
部の次にすぐサービス属性を表すオプション用ヘッド部
が存在するので、サービス属性の把握が速く且つ容易で
ある。ＩＰｖ６による、基本ヘッダ部から拡張ヘッダ用
データ領域、その次でなければ、Destination Port番号
とSource Port番号を取得することができないという問
題点を有していた。更に、正確なサービス属性を取得す
るためには、ＴＣＰオプションの領域か、ＴＣＰアプリ
ケーション領域から取得することができず、次のアプリ
ケーションの立ち上げに支障が生じることもある。

【００１１】また、新しいバージョンを推奨されてから
全てのインターネットが新しいバージョンに変更される
まで、１０年以上を要することから、ＩＰｖ４とＩＰｖ
６との両者のプロトコル処理を可能とするデュアル・ス
タック形式のホストも増加しているが、その場合も、サ
ービス属性を早期に決定してサービス態勢を迅速に準備
する必要がある。

【００１２】本発明は、上記問題点を解決するもので、
ヘッダ部に格納されたサービス属性を高速に読み出し、
特に、ＩＰ層の上位レイヤのデータが固定位置に存在し
ないＩＰｖ６プロトコルであっても、パケットの属する
サービス属性を決定する処理負荷を軽減できることを課
題とする。

【００１３】

【課題を解決するための手段】本発明は、通信経路を介
してサービスを受けるインターネットのサービス属性割
り当て方法において、少なくともフローラベルと送信元
アドレスと宛先アドレスを格納して通信プロトコルに従
って送信され、該送信元アドレスと前記フローラベルと
サービス属性の関係を登録したサービス属性テーブルを
参照し、前記サービス属性テーブルに前記送信元アドレ
スと前記フローラベルとが登録されていた場合には、前
記通信プロトコルの上位層のサービスを提供し、前記サ
ービス属性テーブルに前記送信元アドレスと前記フロー
ラベルとが登録されていない場合には前記通信プロトコ
ルに格納されたサービス属性を解析して前記送信元アド
レスと前記フローラベルと前記サービス属性とを対とし
て前記サービス属性テーブルに登録して前記通信プロト
コルの上位層のサービスを提供することを特徴とする。

【００１４】また、本発明は、通信経路を介してサービ
スを受けるインターネットのネットワーク機器におい
て、少なくともフローラベルと送信元アドレスと宛先ア
ドレスを形成して所定の通信プロトコルに従って送信す
る送信手段から受ける受信手段と、前記送信元アドレス
と前記フローラベルとサービス属性の関係を登録したサ
ービス属性テーブルと、少なくとも前記フローラベルと
前記送信元アドレスとを前記サービス属性テーブルに参
照するサービス属性検出手段と、を備え、前記サービス
属性テーブルに前記送信元アドレスと前記フローラベル
とが登録されていた場合には、前記通信プロトコルの上
位層のサービスを提供し、前記サービス属性テーブルに
前記送信元アドレスと前記フローラベルとが登録されて
いない場合には前記通信プロトコルに格納されたサービ
ス属性を解析して前記送信元アドレスと前記フローラベ
ルと前記サービス属性とを対として前記サービス属性テ
ーブルに登録して前記通信プロトコルの上位層のサービ
スを提供することを特徴とする。

【００１５】以下、本発明と従来例とを対比しつつ、本
発明の特徴を説明する。

【００１６】従来、端末を含むネットワーク機器におい
て、レイヤ３プロトコル（ＩＰ:Internet Protocol）に
加えて、レイヤ４以上のプロトコルの情報を用いてサー
ビス属性を決定して、ＱｏＳ制御や優先制御に利用され
ることが行われている。次世代インターネットプロトコ
ルＩＰｖ６では、図３のヘッダ部構成に示すように、パ
ケット毎に拡張ヘッダの構造の解析を行わなければ、レ
イヤ４プロトコル情報の位置を特定することができない
ため、処理時間を要し、処理負荷が大きくなる。

【００１７】本発明では、ＩＰｖ６の基本ヘッダにある
送信元アドレス（Source Address）と、フローラベル
（Flow Label）フィールドの組とサービス属性の関係表
を、動的に作成することにより、サービス属性の抽出の
ため処理負荷を軽減するものである。

【００１８】また、従来ＩＰｖ４プロトコルを利用した
ネットワーク上のネットワーク機器が、レイヤ４のプロ
トコルＴＣＰやＵＤＰのポート番号の情報を用いて、サ
ービス属性の決定を行うときは、Ｐｏｒｔ番号解析（図
１のステップ３０６）とルール参照処理（ステップ３０
８）をパケット毎に実行しても、高速にサービス属性抽
出処理を終了することができた。これは、ＩＰｖ４パケ
ットに含まれるSourcePort番号とDestination Port番号
の領域が、固定位置に存在する場合がほとんどだからで
ある。 しかし、ＩＰｖ６プロトコルの場合は通常ＩＰ
ｖ６パケットは図２のような基本ヘッダと拡張ヘッダ、
ＴＣＰ／ＵＤＰプロトコルデータで構成される構造を持
っているために、パケットのＴＣＰ／ＵＤＰプロトコル
データの位置を解析するためのＰｏｒｔ番号解析処理
（ステップ３０６）の負荷が大きかったため、高速にサ
ービス属性決定処理を終了することが困難であった。

【００１９】ＩＰｖ６プロトコルではフロー（フローラ
ベルと送信元アドレス）ラベルと呼ばれる概念が導入さ
れ、Source AddressとDestination Address、及びSourc
e Port番号とDestination Port番号が同一のパケットは
同じフロー（フローラベルと送信元アドレス）ラベルに
属するとして、フロー（フローラベルと送信元アドレ
ス）ラベルに唯一な値であるFlowlabelを設定すること
により、ネットワーク上の機器はSource AddressとFlow
labelの組を利用することにより、複数のフロー（フロ
ーラベルと送信元アドレス）ラベルに属するパケットを
識別することができる。

【００２０】ただし、フロー（フローラベルと送信元ア
ドレス）ラベルを識別できても、ＱｏＳ（Quality of S
ervice）制御や優先制御を行うためのサービス属性がで
きない。本発明では、フロー（フローラベルと送信元ア
ドレス）ラベル（ＩＰｖ６のSource AddressとFlowlabe
lの組)と、サービス属性の関係が作成されていないとき
は、パケットの拡張ヘッダ構造の解析を行い、レイヤ４
プロトコル情報を抽出し、ルール参照処理によって、レ
イヤ４プロトコル情報に対応するサービス属性を決定す
る。決定後、ＩＰｖ６のSource AddressとFlowlabelの
組と、ルール参照処理で検索したサービス属性の関係を
サービス属性検索テーブルに登録する処理(図１のステ
ップ３１０）を行い、登録後にネットワーク機器に到着
する同一フロー（フローラベルと送信元アドレス）ラベ
ルがレイヤ４プロトコル情報の抽出のための拡張ヘッダ
構造解析処理を除くことができ、サービス属性の決定の
ための処理を軽減させることができる。

【００２１】

【発明の実施の形態】本発明の実施形態について、図面
を参照しつつ詳細に説明する。

【００２２】［第１の実施形態］ （本実施形態の構成）本第１の実施形態の概念的構成例
を図１に示す。図１において、ＬＡＮ１には複数のパソ
コン１１とルータ１２とがイーサネット等の物理層を設
定するプロトコルにより接続されており、ルータ１２に
は複数のハブ１３が１０ＢＡＳＥ−Ｔ等で接続され、ハ
ブ１３にはパソコン１４，１５が接続され、パソコン１
１，１４，１５間ではそれぞれＴＣＰ／ＩＰプロトコル
によりデータの送受信を行うネットワークを組んでい
る。

【００２３】また、ルータ１２は公衆回線やＩＳＤＮ回
線を介してパケット交換局やデジタル交換局等のスイッ
チに接続され、インターネット通信を可能としている。
また、ＷＡＮ２には、ＷＡＮ２内に専用線を用いて複数
のネットワークに接続されており、その代表としてパソ
コン３２が接続されている。ＷＡＮ２内には共通の通信
プロトコルとしてＴＣＰ／ＩＰを使うことができる。こ
の場合、ＬＡＮ１で例えばUNIX系でコネクションレス型
として使用されるＵＤＰ（User Datagram Protocol）
や、NetWearで使用されるIPX/SPXや、NetBIOSの拡張版
プロトコルで使用されるNetBEUI等を用いてもよい。

【００２４】また、ＬＡＮ１とＷＡＮ２とを公衆回線を
用いずに接続する場合のローカルブリッジや、ＩＳＤＮ
回線網等を介してＬＡＮ間を接続するリモートブリッジ
等をスイッチの代わりに用いてもよい。

【００２５】また、ＬＡＮシステムやＷＡＮシステム等
は、パケット交換ネットワーク技術のプロトコルである
イーサネットで組まれることが多く、１０ＢＡＳＥ−Ｔ
を使うツインペア線や１０ＢＡＳＥ５や１０ＢＡＳＥ２
を使う同軸ケーブルを用いて接続され、ＣＳＭＡ／ＣＤ
方式でデータの衝突防止を図っている。また、トークン
リンクで組まれる場合もあり、トークンパッシング方式
によりリング状にパソコンを接続し、パケットを入れる
容器のトークンを巡回させて用い、この方式であっても
よい。

【００２６】このような構成で、パソコン１５からＴＣ
Ｐ／ＩＰのＩＰｖ４で宛先パソコンをパソコン１１とし
てデータ出力された場合、ハブ１３を介してルータ１２
は宛先を読み込んで即座にパソコン１１にデータを転送
する。パソコン１１はこのＩＰｖ４のヘッダ部を読み込
むと共にその上位層のデータを読み込んで、アプリケー
ション層に求められたデータ処理を行う。

【００２７】この際、パソコン１５からＩＰｖ６で宛先
パソコンをパソコン１１としてデータ出力した場合、ル
ータ１２またはパソコン１１は、図２に示すＩＰｖ６の
各ビットを読み込み・解析すると共にフロー・ラベル
（Flow label）と送信元アドレス（Source Address）を
読み込んで、当該パソコン１５の求めるサービス属性を
サービス属性テーブルから割り出し、ＯＳＩ参照モデル
の第５レイヤ乃至第７レイヤに求められるアプリケーシ
ョン層のデータ処理を行う。

【００２８】ここで、サービス属性テーブルの参考例
を、表１に示す。

【００２９】

【表１】

【００３０】本表１から、フローラベルと送信先アドレ
スが判れば、そのサービス属性が取得できるので、次の
アプリケーション層による負担を事前に判断し、負担増
の場合にはパイプライン的に２つのパソコンに振り分け
るなどの対策が高速に取れることになる。また特定フロ
ーラベルと特定宛先アドレスとから決まるサービス属性
は１つに限ればよいが、複数であっても、登録されて複
数あってもよく、また、同一の特定フローラベルと特定
宛先アドレスで、複数のサービス属性を用いることがで
きるとしてもよい。

【００３１】また、パソコン１４からパソコン３２を宛
先アドレスとしてＩＰｖ６にてデータパケットを送信し
ようとした場合、ハブ１３やルータ１２、スイッチ２
１、ルータ３１を介してパソコン３２に転送されるが、
この場合も各中継装置がそれぞれ有するサービス属性テ
ーブルに、フローラベルと送信元アドレスとそのサービ
ス属性を登録している場合には、その登録に従ってサー
ビス属性を解釈して適切な動作を行って高速転送を可能
とする。又、登録されていなかった場合には、サービス
属性テーブルに新規にフローラベルと送信元アドレスと
そのサービス属性を登録する。

【００３２】（本実施形態の動作の説明）次に、図２の
フローチャートを参照して本実施形態の全体の動作につ
いて、詳細に説明する。

【００３３】本発明は、例えば、ＩＰｖ６プロトコルを
扱うパケットを転送する装置であるルータ、ハブ、スイ
ッチおよび端末等で利用され、フロー（フローラベルと
送信元アドレス）ラベルからサービス属性を求めること
によりＱｏＳ制御や優先制御を決定する装置に利用され
る。

【００３４】図１において、本発明を利用したサービス
属性検索処理手段にＩＰｖ６パケットが入力されたとす
る（ステップ３０１）。次に、ＩＰｖ６プロトコルで規
定されたＩＰｖ６パケットの正当性の検査を行う（ステ
ップ３０２）。本発明のサービス属性処理手段を利用し
た装置が既にＩＰｖ６のパケットヘッダの正当性の検査
を行っている場合は、ステップ３０２とステップ３０３
の処理を省略することができる。

【００３５】つぎに、ＩＰｖ６パケットの正当性の検査
で異常になった場合は（ステップ３０３）、管理機能へ
の報告やパケット廃棄等のエラー処理を行う（ステップ
３１１）。

【００３６】入力したＩＰｖ６パケットが正常である場
合は、サービス属性検索処理（ステップ３０４）で利用
するＩＰｖ６のSource AddressとFlowlabelの組と対応
するサービス属性が記録されたサービス属性テーブルの
中から、ＩＰｖ６パケットのＩＰｖ６のSource Address
とFlowlabelの組と一致するエントリーを検索して、サ
ービス属性を抽出する（ステップ３０４）。

【００３７】サービス属性の抽出が成功した場合は、サ
ービス属性検索処理手段を終了する（ステップ３０
５）。例えば、本発明のサービス属性検索処理手段の実
行を依頼した機能あるいは手段に対して、抽出したサー
ビス属性を通知する。

【００３８】サービス属性の抽出が失敗した場合は、フ
ローラベルとサービス属性の関係がサービス属性テーブ
ルに登録していない場合である。入力したＩＰｖ６パケ
ットからＴＣＰやＵＤＰ等の上位プロトコルのＰｏｒｔ
番号を抽出する（ステップ３０６）。ここで、Ｐｏｒｔ
番号を抽出するためには、図２で示すような、拡張ヘッ
ダの構造の解析処理を行い、上位プロトコルのデータの
存在する位置を検索して、ＴＣＰやＵＤＰ等の上位プロ
トコルのＰｏｒｔ番号を抽出する。

【００３９】Ｐｏｒｔ番号解析が失敗したか否かを調べ
て、成功したらステップ３０８へ、失敗したらサービス
属性検索処理手段を終了する。失敗した場合は上位プロ
トコルがＴＣＰ／ＵＤＰ以外である場合なので、Ｐｏｒ
ｔ番号でサービス属性を決定できない場合である。例え
ば、本発明のサービス属性検索処理手段の実行を依頼し
た機能あるいは手段に対して、サービス属性の検索が失
敗したことを通知する。

【００４０】つぎに、Ｐｏｒｔ番号解析が成功した場合
は、ＩＰｖ６パケットのＩＰｖ６のDestination Addres
s、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とFlowlabe
lに対して、サービス属性をサービス属性テーブルに登
録するために、一度登録したフローラベルに属するパケ
ット（同一のDestination Address、Source Address、D
estination Port番号、Source Port番号を持つ）は、Ｉ
Ｐｖ６パケットの固定位置に存在するSource Addressと
Flow labelの組を検索するだけで、サービス属性を取得
することができるので、ＩＰ層の上位レイヤのデータが
固定位置に存在しないＩＰｖ６プロトコルであっても、
パケットの属するサービス属性を決定する処理負荷を軽
減できる。

【図面の簡単な説明】

【図１】発明の実施形態による通信システムのフローラ
ベル割当方法の説明図である。

【図２】発明の実施形態の動作を示すフローチャートで
ある。

【図３】ＩＰｖ６プロトコルで利用されるパケットの例
を示す図である。

【図４】従来のＩＰｖ４に使用するヘッダ部のフォーマ
ットである。

【符号の説明】

１ ＬＡＮ ２ ＷＡＮ １１，１４，１５，３２ パソコン １２，３１ ルータ １３ ハブ ２１ スイッチ又はブリッジ

───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5K030 GA01 HA08 HB17 HC01 HC14 KA04 LA03 5K034 AA02 AA07 EE11 9A001 CC04 CC06 CC07 CC08 FF03

Claims (7)

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