JP2006238039A - パケット処理装置 - Google Patents
パケット処理装置 Download PDFInfo
- Publication number
- JP2006238039A JP2006238039A JP2005049445A JP2005049445A JP2006238039A JP 2006238039 A JP2006238039 A JP 2006238039A JP 2005049445 A JP2005049445 A JP 2005049445A JP 2005049445 A JP2005049445 A JP 2005049445A JP 2006238039 A JP2006238039 A JP 2006238039A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- receiving
- received
- type
- processing means
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Communication Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Abstract
【課題】 輻輳の発生時にパケット受信手段からパケット処理手段に引き継ぐパケットを特定のパケットに絞り込むことにより、優先されるべき特定のパケットの通過を確保し得るとともに輻輳を早期に解消し得るパケット処理装置を提供する。
【解決手段】 パケットを受信するパケット受信部２と、受信したパケットに含まれる宛先情報に基づいて転送先を決定するパケット処理部３と、転送先を決定されたパケットを当該転送先に送信するパケット送信部４と、前記各部の動作を制御する制御部６とを備えるパケット処理装置１では、パケット受信部２およびパケット処理部３の間にパケット入力制限処理部５を設け、制御部６によるパケット処理部３の輻輳判定時には、パケット入力制限処理部５を動作させて、制御部６によって指定されたタイプのパケットを優先的にパケット処理部４に通過させるように構成した。
【選択図】図１
【解決手段】 パケットを受信するパケット受信部２と、受信したパケットに含まれる宛先情報に基づいて転送先を決定するパケット処理部３と、転送先を決定されたパケットを当該転送先に送信するパケット送信部４と、前記各部の動作を制御する制御部６とを備えるパケット処理装置１では、パケット受信部２およびパケット処理部３の間にパケット入力制限処理部５を設け、制御部６によるパケット処理部３の輻輳判定時には、パケット入力制限処理部５を動作させて、制御部６によって指定されたタイプのパケットを優先的にパケット処理部４に通過させるように構成した。
【選択図】図１
Description
本発明は、パケットを受信するパケット受信手段と、受信したパケットに含まれる宛先情報に基づいて転送先を決定するパケット処理手段と、転送先を決定されたパケットを当該転送先に送信するパケット送信手段と、前記各手段の動作を制御する制御手段とを備える、ルータ等のパケット処理装置に関するものであり、特に、ＩＰ電話等のリアルタイム性が要求されるパケットを優先的に転送することができるパケット処理装置に関するものである。
従来、インターネットの利用形態は、企業ユースもしくはプロバイダの提供するＷｅｂアクセス等のデータ系利用が主体であったが、最近ではＩＰ電話サービス等のリアルタイム系のアプリケーションが急速に普及しつつあり、利用形態の多様化が進んでいる。一方、インターネットのコモディティ化は、不正アクセスの増大を生み、社会的な問題となっている。
上述したような最近のインターネットの傾向に対応して、パケット処理装置は、「リアルタイム性を有するパケットを優先的に転送すること」および「不正アクセスによる処理低下を抑止し、必要なパケットの転送を確保すること」が要求されている。
上述したような最近のインターネットの傾向に対応して、パケット処理装置は、「リアルタイム性を有するパケットを優先的に転送すること」および「不正アクセスによる処理低下を抑止し、必要なパケットの転送を確保すること」が要求されている。
一般的にルータと呼ばれる従来のパケット処理装置は、例えば「非特許文献１」にその構成や作用等が記載されているが、概念的には、図１５に示すように構成されている。
すなわち、従来のパケット処理装置１０１は、図１５に示すように、パケットを受信するパケット受信部１０２と、受信したパケットに含まれる宛先情報に基づいて転送先を決定するパケット処理部１０３と、転送先を決定されたパケットを当該転送先に送信するパケット送信部１０４と、前記各部の動作を制御する制御部（ＣＰＵ等）１０５とを具備して成る。上記パケット受信部１０２には、構内通信網（ＬＡＮ１）およびメディアコンバータ（ＭＣ）を介してインターネットが接続されたり、構内通信網（ＬＡＮ２）を介してパーソナルコンピュータ（ＰＣ）やＩＰ電話機が接続されたり、構内通信網（ＬＡＮ３）を介してサーバが接続されたりする。同様に、上記パケット送信部１０４には、構内通信網（ＬＡＮ４）およびメディアコンバータ（ＭＣ）を介してインターネットが接続されたり、構内通信網（ＬＡＮ５）を介してパーソナルコンピュータ（ＰＣ）やＩＰ電話機が接続されたり、構内通信網（ＬＡＮ６）を介してサーバが接続されたりする。
すなわち、従来のパケット処理装置１０１は、図１５に示すように、パケットを受信するパケット受信部１０２と、受信したパケットに含まれる宛先情報に基づいて転送先を決定するパケット処理部１０３と、転送先を決定されたパケットを当該転送先に送信するパケット送信部１０４と、前記各部の動作を制御する制御部（ＣＰＵ等）１０５とを具備して成る。上記パケット受信部１０２には、構内通信網（ＬＡＮ１）およびメディアコンバータ（ＭＣ）を介してインターネットが接続されたり、構内通信網（ＬＡＮ２）を介してパーソナルコンピュータ（ＰＣ）やＩＰ電話機が接続されたり、構内通信網（ＬＡＮ３）を介してサーバが接続されたりする。同様に、上記パケット送信部１０４には、構内通信網（ＬＡＮ４）およびメディアコンバータ（ＭＣ）を介してインターネットが接続されたり、構内通信網（ＬＡＮ５）を介してパーソナルコンピュータ（ＰＣ）やＩＰ電話機が接続されたり、構内通信網（ＬＡＮ６）を介してサーバが接続されたりする。
ネットワンシステムズ (著)、"Ｃｉｓｃｏ技術者認定教科書 ＣＣＮＡ 第３版"、翔泳社、２００４年２月１１日、第6章 ルータコンフィグレーションとソフトウェア管理、第9章 ルーティングプロトコル
しかしながら、上述した従来のパケット処理装置は、インターネットの普及拡大、利用形態の多様化に合わせて、セキュリティの強化、通過させるパケット量の制限または保証、仮想的なＬＡＮ間接続等によって処理内容が複雑化したため、本来のパケット転送機能以外に多くの機能が追加されたことにより、パケット転送能力の低下を招いている。その対策として、より性能の高いＣＰＵの採用や、ソフトウエア処理の工夫等で性能向上を図っているが、この性能向上は常にインターネットの情報量増大との競争関係にある。
また、高速化するアクセス回線とパケット処理装置の転送能力との関係についても同様に、常に競合する関係にあるため、一般的にアクセス回線の回線速度はパケット処理装置の転送能力を上回る状況にある。すなわち、パケット処理装置は可能な限りパケット転送能力を高めようとしているが、処理内容の増大、アクセス回線の高速化により、パケット処理装置内でパケットが破棄される現象が生じることは、否定できない。
パケットの破棄は、パケット処理装置の入口であるパケット受信部で発生する。パケット処理装置のボトルネックはパケット処理部にあるが、そのしわ寄せとして、パケット処理待ちとなるパケット受信部の受信バッファがオーバーフローすることによりパケット廃棄、すなわちパケットロスが発生する。その結果、再送不可能なパケットである音声パケットの破棄が生じた場合には、音声品質の劣化につながり、ＩＰ電話サービスの一般提供に重大な問題をもたらすことになる。
インターネットは、ＬＡＮ等のネットワーク、パケット処理装置（ルータ）、端末を含めた全体のトラフィック制御が困難な性格を持っており、一時的なトラフィック輻輳は比較的頻繁に発生するものであるが、従来はデータ中心のネットワークであったため、上記課題はそれ程重大な問題となっていなかったが、ＩＰ電話等のリアルタイム的性格を有するアプリケーションの普及に伴い、上記課題は解決しなければならない重要課題となっている。
また、高速化するアクセス回線とパケット処理装置の転送能力との関係についても同様に、常に競合する関係にあるため、一般的にアクセス回線の回線速度はパケット処理装置の転送能力を上回る状況にある。すなわち、パケット処理装置は可能な限りパケット転送能力を高めようとしているが、処理内容の増大、アクセス回線の高速化により、パケット処理装置内でパケットが破棄される現象が生じることは、否定できない。
パケットの破棄は、パケット処理装置の入口であるパケット受信部で発生する。パケット処理装置のボトルネックはパケット処理部にあるが、そのしわ寄せとして、パケット処理待ちとなるパケット受信部の受信バッファがオーバーフローすることによりパケット廃棄、すなわちパケットロスが発生する。その結果、再送不可能なパケットである音声パケットの破棄が生じた場合には、音声品質の劣化につながり、ＩＰ電話サービスの一般提供に重大な問題をもたらすことになる。
インターネットは、ＬＡＮ等のネットワーク、パケット処理装置（ルータ）、端末を含めた全体のトラフィック制御が困難な性格を持っており、一時的なトラフィック輻輳は比較的頻繁に発生するものであるが、従来はデータ中心のネットワークであったため、上記課題はそれ程重大な問題となっていなかったが、ＩＰ電話等のリアルタイム的性格を有するアプリケーションの普及に伴い、上記課題は解決しなければならない重要課題となっている。
本発明は、輻輳の発生時にパケット受信手段からパケット処理手段に引き継ぐパケットを特定のパケットに絞り込むことにより、優先されるべき特定のパケットの通過を確保し得るとともに輻輳を早期に解消し得るパケット処理装置を提供することを目的とする。
上記目的を達成するため、請求項１に記載の第１発明は、パケットを受信するパケット受信手段と、受信したパケットに含まれる宛先情報に基づいて転送先を決定するパケット処理手段と、転送先を決定されたパケットを当該転送先に送信するパケット送信手段と、前記各手段の動作を制御する制御手段とを備えるパケット処理装置であって、前記パケット受信手段および前記パケット処理手段の間にパケット入力制限処理手段を設け、前記制御手段による前記パケット処理手段の輻輳判定時には、前記パケット入力制限処理手段を動作させて、前記制御手段によって指定されたタイプのパケットを優先的に前記パケット処理手段に通過させるようにしたことを特徴とする。
請求項２に記載の第２発明は、前記制御手段によって指定されたタイプのパケット以外のパケットを廃棄するようにしたことを特徴とする。
請求項３に記載の第３発明は、前記パケット受信手段は、外部から入力されたパケットを受信する受信回路と、該受信回路で受信したパケットを格納する受信バッファと、受信したパケットのタイプを識別する受信パケットタイプ識別回路とを備え、該受信パケットタイプ識別回路は、前記制御手段によって予め指定された受信バッファの先頭アドレスに基づいてパケットのタイプを特定するヘッダ情報位置を算出し、前記受信回路で受信されたパケットが前記受信バッファに格納されると同時に、前記ヘッダ情報位置のヘッダ情報を保持し、該ヘッダ情報に基づいてパケット毎にパケットタイプの識別結果を生成して保持するようにしたことを特徴とする。
請求項４に記載の第４発明は、前記パケット受信手段は、外部から入力されたパケットを受信する受信回路と、該受信回路で受信したパケットを格納する受信バッファと、受信したパケットのタイプを識別する受信パケットタイプ識別回路とを備え、該受信パケットタイプ識別回路は、前記制御手段によって予め指定された受信バッファの先頭アドレスに基づいてパケットのタイプを特定するヘッダ情報位置を算出し、前記受信回路で受信されたパケットが前記受信バッファに格納されると同時に、前記ヘッダ情報位置のヘッダ情報を保持し、該ヘッダ情報に基づいてパケット毎にパケットタイプの識別結果を生成するとともに、該パケットタイプの識別結果と前記制御手段によって予め指定されたパケットタイプ毎のパケット通過条件またはパケット廃棄条件とを照合して、パケット毎に通過または廃棄の判定を行い、判定結果を保持するようにしたことを特徴とする。
請求項５に記載の第５発明は、前記パケット受信手段は、外部から入力されたパケットを受信する受信回路と、該受信回路で受信したパケットを格納する受信バッファと、受信したパケットのタイプを識別する受信パケットタイプ識別回路とを備え、該受信パケットタイプ識別回路は、前記制御手段によって予め指定された受信バッファの先頭アドレスに基づいてパケットのタイプを特定するヘッダ情報位置を算出し、前記受信回路で受信されたパケットが前記受信バッファに格納されると同時に、前記ヘッダ情報位置のヘッダ情報を保持し、該ヘッダ情報に基づいてパケット毎にパケットタイプの識別結果を生成するとともに、該パケットタイプの識別結果と前記制御手段によって予め指定された検出すべきパケットタイプとを照合して、パケット毎に予め指定された検出すべきパケットタイプであるか否かの判定を行い、判定結果を保持するようにしたことを特徴とする。
請求項６に記載の第６発明は、前記パケット入力制限処理手段は、前記パケット受信手段の受信バッファから受信したパケットを取り出して前記パケット処理手段に引き渡す際に、前記制御手段による前記パケット処理手段の輻輳判定時には、前記受信パケットタイプ識別回路によるパケットタイプの識別結果に基づいて、受信したパケットを前記パケット処理手段に引き渡す処理または受信したパケットを破棄する処理を行うようにしたことを特徴とする。
請求項７に記載の第７発明は、前記パケット入力制限処理手段は、前記パケット受信手段の受信バッファから受信したパケットを取り出して前記パケット処理手段に引き渡す際に、前記制御手段による前記パケット処理手段の輻輳判定時には、前記受信パケットタイプ識別回路によるパケット毎の通過または廃棄の判定結果に基づき、受信したパケットを前記パケット処理手段に引き渡す処理または受信したパケットを破棄する処理を行うようにしたことを特徴とする。
請求項８に記載の第８発明は、前記パケット入力制限処理手段は、前記パケット受信手段の受信バッファから受信したパケットを取り出して前記パケット処理手段に引き渡す際に、前記制御手段による前記パケット処理手段の輻輳判定時には、ヘッダ情報に基づいてパケット毎にパケットタイプの識別結果を生成するとともに、該パケットタイプの識別結果に基づいて受信したパケットを前記パケット処理手段に引き渡す処理または破棄する処理を行うようにしたことを特徴とする。
請求項９に記載の第９発明は、前記制御手段による前記パケット処理手段の輻輳判定は、前記パケット受信手段から前記パケット入力制限処理手段を経由して前記パケット処理手段に設けた共通受信キューに積まれたパケットのパケット数が上限値を越えた場合に前記パケット処理手段の輻輳と判定するようにしたことを特徴とする。
請求項１０に記載の第１０発明は、前記制御手段によって指定されたタイプのパケットは、音声パケットを含むリアルタイム性を要求されるパケットであることを特徴とする。
第１発明によれば、パケットを受信するパケット受信手段と、受信したパケットに含まれる宛先情報に基づいて転送先を決定するパケット処理手段との間にパケット入力制限処理手段を設け、制御手段による前記パケット処理手段の輻輳判定時には、前記パケット入力制限処理手段を動作させて、前記制御手段によって指定されたタイプのパケットを優先的に前記パケット処理手段に通過させるようにしたから、パケット処理装置の輻輳の発生時には、パケット受信手段からパケット処理手段に引き継ぐパケットが前記制御手段によって指定されたタイプの特定のパケットに絞り込まれることになる。したがって、パケットトラフィックが増大してパケット処理装置が輻輳状態に陥った場合であっても、優先されるべき特定のパケットの通過を確保し得るとともに輻輳を早期に解消し得るパケット処理装置を提供することができる。
第２発明によれば、前記制御手段によって指定されたタイプのパケット以外のパケットを廃棄するようにしたから、パケット処理装置の輻輳の発生時にパケット受信手段からパケット処理手段に引き継ぐパケットがさらに絞り込まれて、前記パケット処理手段が処理すべきパケット数が減少するので、輻輳をさらに早期に解消し得るパケット処理装置となる。
第３発明によれば、前記パケット受信手段は、外部から入力されたパケットを受信する受信回路と、該受信回路で受信したパケットを格納する受信バッファと、受信したパケットのタイプを識別する受信パケットタイプ識別回路とを備え、該受信パケットタイプ識別回路は、前記制御手段によって予め指定された受信バッファの先頭アドレスに基づいてパケットのタイプを特定するヘッダ情報位置を算出し、前記受信回路で受信されたパケットが前記受信バッファに格納されると同時に、前記ヘッダ情報位置のヘッダ情報を保持し、該ヘッダ情報に基づいてパケット毎にパケットタイプの識別結果を生成して保持するようにしたから、外部から入力されたパケットが前記制御手段によって指定されたタイプのパケットに該当するか否かの識別結果が前記パケット受信手段を通過する際に得られることになり、該識別結果に基づく前記パケット入力制限処理手段の動作により、外部から入力されたパケットが前記制御手段によって指定されたタイプのパケットに該当しない場合に当該パケットの入力を制限して、パケット処理装置の輻輳の早期解消を図ることができるとともに、前記パケット受信手段内に受信パケットタイプ識別回路というハードウエアを設けたことにより、受信したパケットのパケットタイプを識別するソフトウエア処理を軽減することができる。
第４発明によれば、前記パケット受信手段は、外部から入力されたパケットを受信する受信回路と、該受信回路で受信したパケットを格納する受信バッファと、受信したパケットのタイプを識別する受信パケットタイプ識別回路とを備え、該受信パケットタイプ識別回路は、前記制御手段によって予め指定された受信バッファの先頭アドレスに基づいてパケットのタイプを特定するヘッダ情報位置を算出し、前記受信回路で受信されたパケットが前記受信バッファに格納されると同時に、前記ヘッダ情報位置のヘッダ情報を保持し、該ヘッダ情報に基づいてパケット毎にパケットタイプの識別結果を生成するとともに、該パケットタイプの識別結果と前記制御手段によって予め指定されたパケットタイプ毎のパケット通過条件またはパケット廃棄条件とを照合して、パケット毎に通過または廃棄の判定を行い、判定結果を保持するようにしたから、外部から入力されたパケットのパケットタイプの識別結果およびその識別結果に応じたパケット毎の通過または廃棄の判定結果が前記パケット受信手段を通過する際に得られることになり、該判定結果に基づく前記パケット入力制限処理手段の動作により、外部から入力されたパケットの識別されたパケットタイプがパケット廃棄条件に該当する場合に当該パケットを破棄して、パケット処理装置の輻輳の早期解消を図ることができるとともに、前記パケット受信手段内に受信パケットタイプ識別回路というハードウエアを設けたことにより、受信したパケットのパケットタイプを識別するソフトウエア処理を軽減することができる。
第５発明によれば、前記パケット受信手段は、外部から入力されたパケットを受信する受信回路と、該受信回路で受信したパケットを格納する受信バッファと、受信したパケットのタイプを識別する受信パケットタイプ識別回路とを備え、該受信パケットタイプ識別回路は、前記制御手段によって予め指定された受信バッファの先頭アドレスに基づいてパケットのタイプを特定するヘッダ情報位置を算出し、前記受信回路で受信されたパケットが前記受信バッファに格納されると同時に、前記ヘッダ情報位置のヘッダ情報を保持し、該ヘッダ情報に基づいてパケット毎にパケットタイプの識別結果を生成するとともに、該パケットタイプの識別結果と前記制御手段によって予め指定された検出すべきパケットタイプとを照合して、パケット毎に予め指定された検出すべきパケットタイプであるか否かの判定を行い、判定結果を保持するようにしたから、外部から入力されたパケットのパケットタイプの識別結果および識別されたパケットタイプがパケット毎に予め指定された検出すべきパケットタイプであるか否かの判定結果が前記パケット受信手段を通過する際に得られることになり、該判定結果に基づく前記パケット入力制限処理手段の動作により、外部から入力されたパケットが前記制御手段によって予め指定された検出すべきパケットタイプのパケットに該当しない場合に当該パケットの入力を制限して、パケット処理装置の輻輳の早期解消を図ることができるとともに、前記パケット受信手段内に受信パケットタイプ識別回路というハードウエアを設けたことにより、受信したパケットのパケットタイプを識別するソフトウエア処理を軽減することができる。
第６発明によれば、前記パケット入力制限処理手段は、前記パケット受信手段の受信バッファから受信したパケットを取り出して前記パケット処理手段に引き渡す際に、前記制御手段による前記パケット処理手段の輻輳判定時には、前記受信パケットタイプ識別回路によるパケットタイプの識別結果に基づいて、受信したパケットを前記パケット処理手段に引き渡す処理または受信したパケットを破棄する処理を行うようにしたから、前記パケット処理手段が処理すべきパケット数が減少することになり、パケット処理装置の輻輳の早期解消に寄与することになる。
第７発明によれば、前記パケット入力制限処理手段は、前記パケット受信手段の受信バッファから受信したパケットを取り出して前記パケット処理手段に引き渡す際に、前記制御手段による前記パケット処理手段の輻輳判定時には、前記受信パケットタイプ識別回路によるパケット毎の通過または廃棄の判定結果に基づき、受信したパケットを前記パケット処理手段に引き渡す処理または受信したパケットを破棄する処理を行うようにしたから、前記パケット処理手段が処理すべきパケット数が減少することになり、パケット処理装置の輻輳の早期解消に寄与することになる。
第８発明によれば、前記パケット入力制限処理手段は、前記パケット受信手段の受信バッファから受信したパケットを取り出して前記パケット処理手段に引き渡す際に、前記制御手段による前記パケット処理手段の輻輳判定時には、ヘッダ情報に基づいてパケット毎にパケットタイプの識別結果を生成するとともに、該パケットタイプの識別結果に基づいて受信したパケットを前記パケット処理手段に引き渡す処理または破棄する処理を行うようにしたから、前記パケット処理手段が処理すべきパケット数が減少することになり、パケット処理装置の輻輳の早期解消に寄与することになるとともに、前記パケット受信手段内に受信パケットタイプ識別回路というハードウエアを設けずに、受信したパケットのパケットタイプの識別をソフトウエア処理のみで実行するように構成することにより、パケット処理装置のコストダウンを図ることができる。
第９発明によれば、前記制御手段による前記パケット処理手段の輻輳判定は、前記パケット受信手段から前記パケット入力制限処理手段を経由して前記パケット処理手段に設けた共通受信キューに積まれたパケットのパケット数が上限値を越えた場合に前記パケット処理手段の輻輳と判定するようにしたから、当該パケット処理装置の輻輳を的確に判定することができる。
第１０発明によれば、前記制御手段によって指定されたタイプのパケットは、音声パケットを含むリアルタイム性を要求されるパケットであるから、パケットトラフィックが増大してパケット処理装置が輻輳状態に陥った場合であっても、所望の通り、最も通過が優先されるべき特定のパケットである音声パケットの通過を確保して音声品質の劣化を防止できるようになる。
以下、本発明を実施するための最良の形態を図面に基づき詳細に説明する。
［第１実施形態］
図１は本発明の第１実施形態のパケット処理装置の構成を概念的に示すブロック図であり、図２および図３はそれぞれ、第１実施形態のパケット処理装置が適用されるネットワーク構成例１，２を示す図である。
図１は本発明の第１実施形態のパケット処理装置の構成を概念的に示すブロック図であり、図２および図３はそれぞれ、第１実施形態のパケット処理装置が適用されるネットワーク構成例１，２を示す図である。
まず、図２および図３について説明する。図２および図３は企業での適用例を示したものであり、図２の例では、企業の本社、支社がそれぞれイントラネットＡ，イントラネットＢを構成し、インターネットを介してイントラネットＡ，イントラネットＢ間が接続されている。図３の例では、企業の本社、支社がそれぞれイントラネットＡ，イントラネットＢおよびイントラネットＣを構成し、インターネットを介してイントラネットＡ，イントラネットＢ，イントラネットＣ間が接続されている。また、インターネットを経由して他プロバイダが提供するインターネットサービス等を利用することが可能な構成となっている。なお、図２中、ＭＣは、電話回線（メタル線）と光ケーブル等の接続を仲介するメディアコンバータを示し、ＳＷは、データリンク層で動作するパケット交換装置であるスイッチング装置を示す。
イントラネットＡ，Ｂ，Ｃでは、パーソナルコンピュータ（ＰＣ）、サーバ、ＩＰ電話機等が、１つまたは複数に分割された構内通信網（ＬＡＮ；イーサネット（登録商標）ともいう）を経由して、本実施形態のパケット処理装置１に接続されている。パケット処理装置１は、イントラネット内部アクセスか、外部（他イントラネットまたはプロバイダ）アクセスかをルーティングする機能を有している。
イントラネットＡ，Ｂ，Ｃでは、パーソナルコンピュータ（ＰＣ）、サーバ、ＩＰ電話機等が、１つまたは複数に分割された構内通信網（ＬＡＮ；イーサネット（登録商標）ともいう）を経由して、本実施形態のパケット処理装置１に接続されている。パケット処理装置１は、イントラネット内部アクセスか、外部（他イントラネットまたはプロバイダ）アクセスかをルーティングする機能を有している。
本実施形態のパケット処理装置１は、図１に示すように、外部からパケットを受信するパケット受信部２と、受信したパケットに含まれる宛先情報に基づいて転送先を決定するパケット処理部３と、転送先を決定されたパケットを当該転送先に送信するパケット送信部４と、パケット受信部２およびパケット処理部３間に設けられ、パケット受信部２で受信したパケットをパケット処理部３に引き渡す処理または引き渡さずに破棄する処理を行うパケット入力制限処理部５と、前記各部の動作を制御する制御部（例えばＣＰＵ）６とを具備して成る。本実施形態のパケット処理装置１は、大規模なセンタールータ、コアルータとは若干相違するが、中小規模のエッジルータやアクセスルータと呼ばれるパケット処理装置を対象としており、上記各部の機能の大半は、ＣＰＵ上のソフトウェア処理により実現されている。
上記パケット受信部２は、図４に示すように、外部のインターネットからメディアコンバータ（ＭＣ）を介して入力されたパケットを受信する受信回路１１−１および外部のＰＣやＩＰ電話機等からＬＡＮ（イーサネット）を介して入力されたパケットを受信する受信回路１１−２と、受信回路１１−１で受信したパケットを格納する受信バッファ１２−１と、受信回路１１−２で受信したパケットを格納する受信バッファ１２−２と、受信回路１１−１で受信したパケットパケットのパケットタイプを識別する受信パケットタイプ識別回路１３−１と、受信回路１１−２で受信したパケットパケットのパケットタイプを識別する受信パケットタイプ識別回路１３−２とを備えて成る。なお、図４に示す例では、受信回路、受信バッファおよび受信パケットタイプ識別回路をパケット受信部２内に２組設けているが、必要に応じて３組以上設けることもできる。
上記受信回路１１−１，１１−２は、イーサネットの物理層、データリンク層に対応し、パケットの受信および組み立てを行い、受信したパケットをそれぞれの受信バッファ１２−１，１２−２に順次格納する。
上記受信バッファ１２−１，１２−２は、実際にはＣＰＵのメモリ上に定義されており、受信回路１１−１，１１−２からＣＰＵのシステムバスを経由して受信パケットがメモリ上の受信バッファ領域へ書き込まれるように構成されている。図９に詳細を示すが、受信バッファ１２−１，１２−２はそれぞれ、複数（図９の図示例では６４個）の受信パケットを受信可能に区分されたパケットバッファから構成されており、区分されたパケットバッファは各々、固有な先頭システムバスアドレスを有しており、受信されたパケットは、先頭アドレスから順次格納されていくようになっている。
上記受信バッファ１２−１，１２−２は、実際にはＣＰＵのメモリ上に定義されており、受信回路１１−１，１１−２からＣＰＵのシステムバスを経由して受信パケットがメモリ上の受信バッファ領域へ書き込まれるように構成されている。図９に詳細を示すが、受信バッファ１２−１，１２−２はそれぞれ、複数（図９の図示例では６４個）の受信パケットを受信可能に区分されたパケットバッファから構成されており、区分されたパケットバッファは各々、固有な先頭システムバスアドレスを有しており、受信されたパケットは、先頭アドレスから順次格納されていくようになっている。
上記受信パケットタイプ識別回路１３−１，１３−２は、ハードウエアで実現することも、ソフトウエアで実現することも可能であり、図５は受信パケットタイプ識別回路をハードウェアで実現した構成例を示している。図５に示す受信パケットタイプ識別回路１３−１，１３−２は、システムバス上に設けられており、受信回路１１−１，１１−２で受信したパケットが受信バッファ１２−１，１２−２に格納される際に、並行して受信パケットのパケットタイプを識別する機能を有しており、構成要素として、アドレス検出回路１３ａと、１個または複数のパケットレジスタ（図示例では８個のパケットレジスタ１３ｂ１〜１３ｂ８）と、識別回路１３ｃと、識別条件レジスタ１３ｄと、複数（受信バッファと同数、図示例では６４個）の識別結果レジスタ１３ｅ１〜１３ｅ６４とから成る。
上記受信パケットタイプ識別回路１３−１，１３−２において、アドレス検出回路１３ａは、受信パケットの特定バイト（後述する図９に示すパケットタイプを識別する情報バイト）が受信バッファ１２−１または受信バッファ１２−２に格納されるアドレスを検出し、そのバイト情報を同時にパケットレジスタ１３ｂ１〜１３ｂ８に取り込む。識別条件レジスタ１３ｄは、予め制御部（ＣＰＵおよびソフトウエア）６から照合すべきパケットタイプの条件が設定されている。識別回路１３ｃでは、パケットレジスタ１３ｂ１〜１３ｂ８に取り込まれたタイプ識別情報と制御部６から設定された識別条件レジスタ１３ｄの内容とを照合して、当該パケットのパケットタイプを識別し、識別結果は識別結果レジスタ１３ｅ１〜１３ｅ６４に格納される。
上記識別結果レジスタ１３ｅ１〜１３ｅ６４に格納されたパケットのパケットタイプの識別結果は、受信したパケットを受信バッファ１２−１または受信バッファ１２−２から取り出して共通受信キュー１４に積み込む際に、制御部６によって、同時に読み込むことにより、当該パケットのパケットタイプを認識できることになる。仮に、パケット処理装置１が輻輳状態であれば、後述するようにして、認識したパケットタイプに応じて、通過の判断もしくは廃棄の判断を行うことになる。
上記識別結果レジスタ１３ｅ１〜１３ｅ６４に格納されたパケットのパケットタイプの識別結果は、受信したパケットを受信バッファ１２−１または受信バッファ１２−２から取り出して共通受信キュー１４に積み込む際に、制御部６によって、同時に読み込むことにより、当該パケットのパケットタイプを認識できることになる。仮に、パケット処理装置１が輻輳状態であれば、後述するようにして、認識したパケットタイプに応じて、通過の判断もしくは廃棄の判断を行うことになる。
上記受信パケットタイプ識別回路１３−１，１３−２の構成を図６によってさらに詳しく説明する。
アドレス検出回路１３ａは、受信バッファ先頭アドレスレジスタ、アドレス演算回路、アドレス照合回路から構成される。
上記受信バッファ先頭アドレスレジスタは、ソフトウェアが後述する「受信コントロールテーブル」に受信バッファアドレス（ＢＲＡ）を書き込む際に、該受信バッファ先頭アドレスレジスタに同じＢＲＡを設定するように構成されている。
上記アドレス演算回路は、パケットタイプを識別するための、イーサ（ether ）ヘッダのタイプ情報、ＩＰヘッダのＴＯＳフィールド、プロトコル情報等のアドレスを算出する回路である。それぞれの情報は、ＢＲＡから何バイト目であるかで計算が可能である。ＵＤＰ（User Datagram Protocol）のポート番号情報は、ＩＰヘッダのヘッダ長が可変であることから、「ＢＲＡ＋ＩＰヘッダ長＋１４バイト」で算出することができる。
上記アドレス照合回路では、システムバス上を介して受信回路１１−１，１１−２から受信バッファ１２−１，１２−２へ受信パケットが格納されることを監視し、システムバス上のアドレスが上記アドレス演算回路の演算結果と一致する際に、どのレジスタの情報であるかを判断して、パケットレジスタ１３ｂ１〜１３ｂ８の何れか１つを選択する信号を作成する。
アドレス検出回路１３ａは、受信バッファ先頭アドレスレジスタ、アドレス演算回路、アドレス照合回路から構成される。
上記受信バッファ先頭アドレスレジスタは、ソフトウェアが後述する「受信コントロールテーブル」に受信バッファアドレス（ＢＲＡ）を書き込む際に、該受信バッファ先頭アドレスレジスタに同じＢＲＡを設定するように構成されている。
上記アドレス演算回路は、パケットタイプを識別するための、イーサ（ether ）ヘッダのタイプ情報、ＩＰヘッダのＴＯＳフィールド、プロトコル情報等のアドレスを算出する回路である。それぞれの情報は、ＢＲＡから何バイト目であるかで計算が可能である。ＵＤＰ（User Datagram Protocol）のポート番号情報は、ＩＰヘッダのヘッダ長が可変であることから、「ＢＲＡ＋ＩＰヘッダ長＋１４バイト」で算出することができる。
上記アドレス照合回路では、システムバス上を介して受信回路１１−１，１１−２から受信バッファ１２−１，１２−２へ受信パケットが格納されることを監視し、システムバス上のアドレスが上記アドレス演算回路の演算結果と一致する際に、どのレジスタの情報であるかを判断して、パケットレジスタ１３ｂ１〜１３ｂ８の何れか１つを選択する信号を作成する。
上記パケットレジスタ１３ｂ１〜１３ｂ８は、パケットタイプを判断する情報を格納するレジスタであり、上記アドレス照合回路からレジスタ選択信号を受け取り、パケットレジスタ１３ｂ１〜１３ｂ８の中の選択されたパケットレジスタにシステムバス上のデータ情報（該当タイプ識別情報）を取り込む。
上記識別回路１３ｃは、パケットレジスタ１３ｂ１〜１３ｂ８（受信パケットのパケットタイプ識別情報が格納されている）の内容と識別条件レジスタ１３ｄの内容とから、当該受信パケットが通過させるものか廃棄するものかを識別し、その識別結果を識別結果レジスタ１３ｅ１〜１３ｅ６４へ出力する。
上記識別回路１３ｃの出力を識別結果レジスタ１３ｅ１〜１３ｅ６４へ格納するための指令信号は、結果格納タイミング回路１３ｆから与えられる。結果格納タイミング回路１３ｆは、上記アドレス照合回路から最終アドレス検出信号（本実施形態ではＵＤＰのポート番号レジスタ選択と同一である）を受信した後、識別回路１３ｃの出力が確定する時間分のタイミングを確保して、その後、識別結果レジスタ１３ｅ１〜１３ｅ６４の該当する識別結果レジスタへ識別回路１３ｃの出力を格納するための指令信号を送出する。
上記識別回路１３ｃは、パケットレジスタ１３ｂ１〜１３ｂ８（受信パケットのパケットタイプ識別情報が格納されている）の内容と識別条件レジスタ１３ｄの内容とから、当該受信パケットが通過させるものか廃棄するものかを識別し、その識別結果を識別結果レジスタ１３ｅ１〜１３ｅ６４へ出力する。
上記識別回路１３ｃの出力を識別結果レジスタ１３ｅ１〜１３ｅ６４へ格納するための指令信号は、結果格納タイミング回路１３ｆから与えられる。結果格納タイミング回路１３ｆは、上記アドレス照合回路から最終アドレス検出信号（本実施形態ではＵＤＰのポート番号レジスタ選択と同一である）を受信した後、識別回路１３ｃの出力が確定する時間分のタイミングを確保して、その後、識別結果レジスタ１３ｅ１〜１３ｅ６４の該当する識別結果レジスタへ識別回路１３ｃの出力を格納するための指令信号を送出する。
上記識別条件レジスタ１３ｄは、ソフトウェアにより設定されるレジスタであり、受信バッファと同数設けられており、各々にシステムバス上の固有アドレスが予め付与されている。
図６に示す受信パケットタイプ識別回路１３−１，１３−２にはさらに、システムバス制御回路１３ｇおよび読出選択回路１３ｈが設けられている。システムバス制御回路１３ｇは、受信パケットタイプ識別回路１３−１，１３−２がシステムバスに接続されたときに、ソフトウェア制御により、上記受信バッファ先頭アドレスレジスタおよび識別条件レジスタ１３ｄの設定および識別結果レジスタ１３ｅ１〜１３ｅ６４の読出しを可能とする制御回路であり、読出選択回路１３ｈは、識別結果レジスタ１３ｅ１〜１３ｅ６４の何れかから所望の識別結果を読み出す回路である。
図６に示す受信パケットタイプ識別回路１３−１，１３−２にはさらに、システムバス制御回路１３ｇおよび読出選択回路１３ｈが設けられている。システムバス制御回路１３ｇは、受信パケットタイプ識別回路１３−１，１３−２がシステムバスに接続されたときに、ソフトウェア制御により、上記受信バッファ先頭アドレスレジスタおよび識別条件レジスタ１３ｄの設定および識別結果レジスタ１３ｅ１〜１３ｅ６４の読出しを可能とする制御回路であり、読出選択回路１３ｈは、識別結果レジスタ１３ｅ１〜１３ｅ６４の何れかから所望の識別結果を読み出す回路である。
上記識別条件レジスタ１３ｄの設定は、図７（ａ）に例示するように、８ビットのレジスタの各ビットにそれぞれ、通過させるパケットの識別条件を指定するようになっている。図示例では、ビット番号０には、「ＰＰＰｏＥ」が割り当てられ、０が破棄、１が通過に設定されている他、ビット番号１〜ビット番号７にはそれぞれ、図示のような識別条件が設定されており、パケットタイプ毎に通過させるか廃棄させるかの条件（通過条件／廃棄条件）が設定されている。これらの条件に基づいて、受信したパケットの各ヘッダの該当バイト部分との照合を識別回路１３ｃで行い、その結果は識別結果レジスタ１３ｅ１〜１３ｅ６４に保持される。
図７（ｂ）は、パケット識別結果例であり、識別条件レジスタ１３ｄに図７（ａ）の識別条件が設定されているときに受信したパケットの種別が通過条件を満たすか否かの、識別結果レジスタ１３ｅ１〜１３ｅ６４に出力（格納）される識別結果（０または１）を例示している。
また、別のパケット識別結果例（パケットタイプの識別）は、後述する第２実施形態の図１２において説明する。
図７（ｂ）は、パケット識別結果例であり、識別条件レジスタ１３ｄに図７（ａ）の識別条件が設定されているときに受信したパケットの種別が通過条件を満たすか否かの、識別結果レジスタ１３ｅ１〜１３ｅ６４に出力（格納）される識別結果（０または１）を例示している。
また、別のパケット識別結果例（パケットタイプの識別）は、後述する第２実施形態の図１２において説明する。
上記パケット処理部３は、受信したパケットを当該パケットの宛先ＩＰアドレス情報に基づいて適切な経路に転送することが主要な機能であり、経路選択に必要な情報（それぞれのパケット処理装置に属するＩＰアドレス情報）を隣接するパケット処理装置間で交換して、宛先ＩＰアドレスと経路との対応を示す情報をルーティングテーブルとして作成して、そのルーティングテーブルにより経路選択を行うようになっている。パケット処理部３は、図８に示す一連のパケット処理を行うものであり、「ＩＰフィルタ処理」では、宛先アドレスまたは発信元アドレスから転送が許可されたパケットであるか否かを判断し、「ＴＯＳ値書き換え処理」では、パケットを転送するにあたり、予め設定されたサービスタイプに書き換えを行い、「ＷＦＱ（Weighted flow queueing）処理」では、経路毎に指定されたパケットの通過量を制御し、「ＮＡＴ（Network address transration ）処理」では、プライベートＩＰアドレスとグローバルＩＰアドレスとの交換を行い、「シェーピング処理」では、経路毎に指定された帯域内の通過パケット量を制限し、「ＩＰｓｅｃ処理」では、パケットの暗号化を行い、「ルーティング処理」では、隣接するパケット処理装置間でそれぞれの有する経路情報およびアドレス情報を交換し、当該パケットの転送先を決定する。
上記パケット送信部４は、図４に示すように、パケット処理部３の共通受信キュー１４から入力されたパケットを格納する送信バッファ１５と、送信バッファ１５から入力されたパケットを外部のインターネット等に送信する送信回路１６とから成る。
次に、パケット処理の輻輳について図４を用いて説明する。
パケット処理装置１の輻輳（内部輻輳）は、当該パケット処理装置のパケット処理能力を超えるパケットが到来する状況で発生する。具体的には、有限長である共通受信キュー１４が満杯になると、それ以上受信したパケットを受け入れられない状態になり、この状態では受信バッファ１２−１または受信バッファ１２−２に新たな受信したパケットが到来しても受け付けができなくなり、有限長の受信バッファ１２−１または受信バッファ１２−２も満杯となる。受信バッファ１２−１または受信バッファ１２−２が満杯になった状態で、次に外部からパケットが到来すると、そのパケットは受信回路１１−１または１１−２で廃棄されることになり、この現象は、通常、オーバーフローと呼ばれる。
パケット処理装置１の輻輳（内部輻輳）は、当該パケット処理装置のパケット処理能力を超えるパケットが到来する状況で発生する。具体的には、有限長である共通受信キュー１４が満杯になると、それ以上受信したパケットを受け入れられない状態になり、この状態では受信バッファ１２−１または受信バッファ１２−２に新たな受信したパケットが到来しても受け付けができなくなり、有限長の受信バッファ１２−１または受信バッファ１２−２も満杯となる。受信バッファ１２−１または受信バッファ１２−２が満杯になった状態で、次に外部からパケットが到来すると、そのパケットは受信回路１１−１または１１−２で廃棄されることになり、この現象は、通常、オーバーフローと呼ばれる。
ところで、従来の一般的なパケット処理装置（ルータ）では、インターネットの輻輳状態の対策として、パケットの優先度やパケット品質等をＩＰヘッダの「タイプ・オブ・サービス」フィールド等で指定したり、ＩＰヘッダのＴＯＳフィールドによりパケットの優先処理、帯域制御を行ったり、あるいは、パケット処理装置の設定において優先度を指定可能にしたりしている。特に、音声パケットについては、高い優先度を設定して音声品質を確保しようとしている。しかし、従来の一般的なパケット処理装置では、共通受信キュー以降、パケット処理においてパケットのシェーピング、最低帯域保証等のパケット優先処理を実施しているため、あくまでもパケット処理装置の内部に取り込んだパケットのみに作用するに過ぎない。インターネットの特質でもある緩い網トラフィック制御下では、当然、一時的なバースト的な過負荷が発生し得るが、そのような状況下では、受信バッファのオーバーフローが発生するパケット処理装置１の輻輳時には、パケット種別に拘わらず受信したパケットが一様に廃棄されることになり、パケット優先処理の効果が不十分な状況にある。重ねて言うと、上記従来技術のような「パケット処理装置に取り込んだ以降のパケットのみを対象とする優先処理」では、本来のパケット優先がなされているとは言えず、可能な限りパケットの取りこぼしを抑止する必要がある。
本発明のパケット処理装置１は、まさに、この問題に対する解決策を提供しようとするものである。本発明のパケット処理装置１は、パケット受信バッファのオーバーフロー発生時には受信したパケットを一律に廃棄するのではなく、特定のパケット（例えば音声パケット）は可能な限り通過させるように構成されている。本発明のパケット処理装置１の特徴的な構成は、（１）共通受信キュー１４のキュー長が上限値（所定の閾値）を越えたときに、輻輳と認識する（これとは異なる「輻輳認識ロジックを用いることも可能である）ようにしたこと、（２）パケット受信部２とパケット処理部３との間にパケット入力制限処理部５を設けたこと、（３）受信したパケットのパケットタイプを識別するようにしたこと、である。
すなわち、パケット処理装置１が輻輳状態になった際には、受信パケットタイプ識別回路１３−１，１３−２において受信したパケットのパケットタイプを判定して、パケット入力制限処理部５において通過させるパケットのみがパケット処理部３でパケット処理されるように、パケットの入力制限を実施する。
上記「輻輳」は、受信したパケットを受信バッファから共通受信キューに積み替える際にキュー長が上限値（閾値）を越えたか否かで判断する。すなわち、上限値以上であれば輻輳状態であると認識し、上限値未満であれば輻輳解除状態（非輻輳状態）であると認識する。
上記パケット入力制限処理部５は、受信バッファから共通受信キューに受信したパケットを積み替える際に、上述した輻輳状態の認識において非輻輳状態と認識された場合であれば、受信したパケットをそのまま共通受信キューに通過させるが、輻輳状態と認識された場合は、受信したパケットのタイプを判定して、制御部６によって指定されたパケットタイプのパケットのみを入力する、パケット入力制限処理を実施する。
上記「輻輳」は、受信したパケットを受信バッファから共通受信キューに積み替える際にキュー長が上限値（閾値）を越えたか否かで判断する。すなわち、上限値以上であれば輻輳状態であると認識し、上限値未満であれば輻輳解除状態（非輻輳状態）であると認識する。
上記パケット入力制限処理部５は、受信バッファから共通受信キューに受信したパケットを積み替える際に、上述した輻輳状態の認識において非輻輳状態と認識された場合であれば、受信したパケットをそのまま共通受信キューに通過させるが、輻輳状態と認識された場合は、受信したパケットのタイプを判定して、制御部６によって指定されたパケットタイプのパケットのみを入力する、パケット入力制限処理を実施する。
次に、本実施形態のパケット処理装置におけるパケット処理の流れを説明する。
まず、「パケットの受信の仕組み」について図９に基づいて説明する。パケット受信部２においてパケットを受信する際には、受信回路１１−１，１１−２とソフトウェアとの間で、受信したパケットの格納場所やパケット長等のパケット受信に関する制御情報の受け渡しが必要であるが、本実施形態では、上記制御情報の受け渡しを、図９に示す「受信コントロールテーブル」を用いて行う。この「受信コントロールテーブル」は、メインメモリの所定アドレスに格納されるものであり、受信回路１１−１，１１−２にはそれぞれ、予め、その所定アドレスを通知済みである。上記「受信コントロールテーブル」は、受信バッファと同数（図示例では６４個）だけ用意されている。
各受信コントロールテーブルは、受信ステータス、パケット長および受信バッファアドレス（ＢＲＡ）から構成されている。
上記受信ステータスは、受信バッファが空き状態（０が割り当てられている）か、受信完了状態（１が割り当てられている）かを示すものである。上記パケット長は、受信したパケットのパケットサイズを示すものである。上記受信バッファアドレス（ＢＲＡ）は、パケットを格納する受信バッファの先頭番地を示すものである。
まず、「パケットの受信の仕組み」について図９に基づいて説明する。パケット受信部２においてパケットを受信する際には、受信回路１１−１，１１−２とソフトウェアとの間で、受信したパケットの格納場所やパケット長等のパケット受信に関する制御情報の受け渡しが必要であるが、本実施形態では、上記制御情報の受け渡しを、図９に示す「受信コントロールテーブル」を用いて行う。この「受信コントロールテーブル」は、メインメモリの所定アドレスに格納されるものであり、受信回路１１−１，１１−２にはそれぞれ、予め、その所定アドレスを通知済みである。上記「受信コントロールテーブル」は、受信バッファと同数（図示例では６４個）だけ用意されている。
各受信コントロールテーブルは、受信ステータス、パケット長および受信バッファアドレス（ＢＲＡ）から構成されている。
上記受信ステータスは、受信バッファが空き状態（０が割り当てられている）か、受信完了状態（１が割り当てられている）かを示すものである。上記パケット長は、受信したパケットのパケットサイズを示すものである。上記受信バッファアドレス（ＢＲＡ）は、パケットを格納する受信バッファの先頭番地を示すものである。
本実施形態では、ソフトウェアによってメインメモリ上に受信バッファ領域を確保しておき、その先頭アドレスであるＢＲＡの設定と受信ステータスとを空き状態に設定する。それにより、受信回路１１−１は、パケットの受信に先立って、受信コントロールテーブルの受信ステータスが空き状態であるか否かを確認して、空きであれば受信したパケットをＢＲＡで示されるメインメモリの領域に格納する。パケットの受信完了時に、受信ステータスを受信済に書き換え、受信したパケットのパケット長を受信コントロールテーブルに書き込む。仮に、受信ステータスが空き状態でない場合には、空きになるまで待つことになる。
図９に示す例では、受信バッファ１２−１，１２−２内に受信バッファを６４個設けているが、一般的に受信バッファ領域は連続して確保されるようになっている。また、１個の受信バッファのバッファサイズは、最大受信パケット長である２０４８バイト（２Ｋバイト）が確保されている。したがって、各受信バッファの先頭アドレスは、ＢＲＡ＋（ｎ−１）×２０４８バイトで示すことができる。
本実施形態では、ソフトウェアによって、パケットを受信したことを、「受信コントロールテーブルの受信ステータスが受信済に変わったこと」で検出可能である。受信済のパケットは、後述するようにして、受信バッファから取り出されて、共通受信キューに積まれることになる。
図９に示す例では、受信バッファ１２−１，１２−２内に受信バッファを６４個設けているが、一般的に受信バッファ領域は連続して確保されるようになっている。また、１個の受信バッファのバッファサイズは、最大受信パケット長である２０４８バイト（２Ｋバイト）が確保されている。したがって、各受信バッファの先頭アドレスは、ＢＲＡ＋（ｎ−１）×２０４８バイトで示すことができる。
本実施形態では、ソフトウェアによって、パケットを受信したことを、「受信コントロールテーブルの受信ステータスが受信済に変わったこと」で検出可能である。受信済のパケットは、後述するようにして、受信バッファから取り出されて、共通受信キューに積まれることになる。
パケットの受信が完了すると、パケット受信部２は、図４に示すように、受信したパケットを受信バッファ１２−１または受信バッファ１２−２に格納すると共に、制御部６（ＣＰＵ＋ソフトウエア）にパケットの受信を通知する。その際の通知手段としては、ＣＰＵへの割り込みが一般的である。上記ソフトウエアは、パケット受信の通知を受けると、受信したパケットを受信バッファ１２−１または受信バッファ１２−２から一旦パケット処理部３の共通受信キュー１４に移し変え、図８に示す各種パケット処理の待ち行列に入れる。
次に、受信パケットタイプ識別回路１３−１，１３−２において実施する、「受信したパケットのヘッダ情報に基づいて当該パケットのパケットタイプを所定のパケットタイプに分類する、パケットタイプの識別処理」について図１０に基づいて説明する。
パケットのパケットヘッダは、図１０に示すように構成されており、一般的に、パケットヘッダはプロトコル階層に対応して、イーサヘッダ（データリンク層）、ＩＰヘッダ（ネットワーク層）およびＵＤＰヘッダまたはＴＣＰヘッダ（トランスポート層）から成る。図１０では、音声系パケットに着目して、イーサヘッダ、ＩＰヘッダ、ＵＤＰヘッダの場合を例示している。図示のパケットタイプの識別例では、まずイーサヘッダのタイプフィールドにおいて、ＩＰパケット／Ｔａｇ−ＶＬＡＮパケット／ＰＰＰｏＥパケット／ＩＰｖ６パケット等が識別される。次に、ＩＰヘッダにおいては、サービスタイプフィールド（ＴＯＳ）において、パケットの優先度や信頼度要求レベル等が識別される。また、プロトコルフィールドにおいて、パケットタイプであるＩＰ／ＴＣＰ／ＵＤＰが識別される。さらに、ＵＤＰヘッダにおいては、ポート番号にて音声で使用されるＳＩＰ（Session Initiation Protocol ），ＲＴＰ（Real-time Transport Protocol）が認識可能である。
以上のヘッダ情報から、受信したパケットのパケットタイプ、すなわち属性が識別可能であり、これらの情報から、輻輳状況において通過させるパケットであるか輻輳状況において廃棄するパケットであるかを決定して、通過させるパケットを優先的に通過させる優先制御が可能になる。
パケットのパケットヘッダは、図１０に示すように構成されており、一般的に、パケットヘッダはプロトコル階層に対応して、イーサヘッダ（データリンク層）、ＩＰヘッダ（ネットワーク層）およびＵＤＰヘッダまたはＴＣＰヘッダ（トランスポート層）から成る。図１０では、音声系パケットに着目して、イーサヘッダ、ＩＰヘッダ、ＵＤＰヘッダの場合を例示している。図示のパケットタイプの識別例では、まずイーサヘッダのタイプフィールドにおいて、ＩＰパケット／Ｔａｇ−ＶＬＡＮパケット／ＰＰＰｏＥパケット／ＩＰｖ６パケット等が識別される。次に、ＩＰヘッダにおいては、サービスタイプフィールド（ＴＯＳ）において、パケットの優先度や信頼度要求レベル等が識別される。また、プロトコルフィールドにおいて、パケットタイプであるＩＰ／ＴＣＰ／ＵＤＰが識別される。さらに、ＵＤＰヘッダにおいては、ポート番号にて音声で使用されるＳＩＰ（Session Initiation Protocol ），ＲＴＰ（Real-time Transport Protocol）が認識可能である。
以上のヘッダ情報から、受信したパケットのパケットタイプ、すなわち属性が識別可能であり、これらの情報から、輻輳状況において通過させるパケットであるか輻輳状況において廃棄するパケットであるかを決定して、通過させるパケットを優先的に通過させる優先制御が可能になる。
次に、パケット入力制限処理部５において実施する第１実施形態のパケット入力制限処理について図１１に基づいて説明する。
図１１は本発明のパケット処理装置のパケット入力制限処理部において実施する第１実施形態のパケット入力制限処理を例示するフローチャートである。まず、図１１のステップＳ１では、受信パケットタイプ識別回路（１３−１または１３−２）から次に処理すべきパケット（以下、当該パケットという）に対応する識別結果レジスタ（１３ｅ１〜１３ｅ６４の何れか）の内容を読み出す。次のステップＳ２では、当該パケットが通過パケットであるか否かを判定し、通過パケットであれば処理をステップＳ３に進め、廃棄パケットであれば処理をステップＳ４に進める。ステップＳ３では、受信バッファ（１２−１または１２−２）より当該パケットを取り出してパケット処理部３の共通受信キューに積み込み、ステップＳ４では、受信バッファ（１２−１または１２−２）より当該パケットを取り出して破棄する。
図１１は本発明のパケット処理装置のパケット入力制限処理部において実施する第１実施形態のパケット入力制限処理を例示するフローチャートである。まず、図１１のステップＳ１では、受信パケットタイプ識別回路（１３−１または１３−２）から次に処理すべきパケット（以下、当該パケットという）に対応する識別結果レジスタ（１３ｅ１〜１３ｅ６４の何れか）の内容を読み出す。次のステップＳ２では、当該パケットが通過パケットであるか否かを判定し、通過パケットであれば処理をステップＳ３に進め、廃棄パケットであれば処理をステップＳ４に進める。ステップＳ３では、受信バッファ（１２−１または１２−２）より当該パケットを取り出してパケット処理部３の共通受信キューに積み込み、ステップＳ４では、受信バッファ（１２−１または１２−２）より当該パケットを取り出して破棄する。
本実施形態のパケット処理装置によれば、パケット処理装置１の輻輳の発生時には、パケット受信部２からパケット処理部３に引き継ぐパケットが制御部６によって指定されたタイプの特定のパケットに絞り込まれるとともに、指定されたタイプの特定のパケット以外のパケットが廃棄されるので、パケット処理部３が処理すべきパケット数が減少することになり、パケットトラフィックが増大してパケット処理装置１が輻輳状態に陥った場合であっても、優先されるべき特定のパケットの通過を確保し得るとともに、パケット処理装置の輻輳を早期に解消することができるようになる。
また、本実施形態のパケット処理装置によれば、パケット処理装置の輻輳対策をＣＰＵ等のハードウエアやソフトウエアの過大な性能向上に頼るのではなく、（１）共通受信キュー１４のキュー長が上限値（閾値）を越えたときに輻輳と認識する構成、（２）パケット受信部２とパケット処理部３との間にパケット入力制限処理部５を設ける構成、（３）パケット受信部２内に受信パケットタイプ識別回路１３−１，１３−２をハードウエアで設ける構成を用いたため、比較的安価なカスタマエッジルータにも上記本実施形態の構成を適用可能になる。
また、本実施形態のパケット処理装置によれば、制御部６によって指定されたタイプのパケットを、音声パケットを含むリアルタイム性を要求されるパケットとすることにより、パケットトラフィックが増大してパケット処理装置が輻輳状態に陥った場合であっても、所望の通り、最も通過が優先されるべき特定のパケットである音声パケットの通過を確保し、音声品質の劣化を防止して品質を確保することが可能になる。
また、本実施形態のパケット処理装置によれば、パケット処理装置の輻輳対策をＣＰＵ等のハードウエアやソフトウエアの過大な性能向上に頼るのではなく、（１）共通受信キュー１４のキュー長が上限値（閾値）を越えたときに輻輳と認識する構成、（２）パケット受信部２とパケット処理部３との間にパケット入力制限処理部５を設ける構成、（３）パケット受信部２内に受信パケットタイプ識別回路１３−１，１３−２をハードウエアで設ける構成を用いたため、比較的安価なカスタマエッジルータにも上記本実施形態の構成を適用可能になる。
また、本実施形態のパケット処理装置によれば、制御部６によって指定されたタイプのパケットを、音声パケットを含むリアルタイム性を要求されるパケットとすることにより、パケットトラフィックが増大してパケット処理装置が輻輳状態に陥った場合であっても、所望の通り、最も通過が優先されるべき特定のパケットである音声パケットの通過を確保し、音声品質の劣化を防止して品質を確保することが可能になる。
また、本実施形態のパケット処理装置によれば、受信部２で受信したパケットが制御部６によって指定されたタイプのパケットに該当しない場合や、受信部２で受信したパケットが制御部６によって予め指定された検出すべきパケットタイプのパケットに該当しない場合に当該パケットの入力を制限するから、パケット処理装置１の輻輳の早期解消を図ることができるとともに、パケット受信部２内に受信パケットタイプ識別回路１３−１，１３−２というハードウエアを設けたことにより、受信したパケットのパケットタイプを識別するソフトウエア処理を軽減することができる。
［第２実施形態］
図１２は本発明の第２実施形態のパケット処理装置における受信パケットタイプ識別回路のパケット識別結果レジスタの内容を示す図である。本実施形態では、上記第１実施形態のような識別条件を特に設定せず、識別回路１３ｃの構成により受信したパケットのパケットタイプおよび優先度情報をレジスタに格納するように構成されている。図１２に示す例では、ビット番号０の「ＳＩＰ／ＲＴＰパケット」には、識別回路１２ｃの論理式が以下の内容でセットされる。
（ａ）イーサヘッダのタイプがＩＰパケットである。
（ｂ）ＩＰヘッダのプロトコルフィールドがＵＤＰである。
（ｃ）ＵＤＰヘッダのポート番号が５００４〜５０６０である。
同様にして、ビット番号１のＩＰｖ６パケット、ビット番号２のＴａｇＶＬＡＮパケット、ビット番号３のＰＰＰｏＥパケット、ビット番号４のＩＰパケット、ビット番号５のＴＣＰパケット等がハードウエア的に識別可能であり、制御部（ＣＰＵ＋ソフトウエア）６は、識別結果に基づいて、輻輳状態の場合における通過／廃棄の判断が可能となる。
図１２は本発明の第２実施形態のパケット処理装置における受信パケットタイプ識別回路のパケット識別結果レジスタの内容を示す図である。本実施形態では、上記第１実施形態のような識別条件を特に設定せず、識別回路１３ｃの構成により受信したパケットのパケットタイプおよび優先度情報をレジスタに格納するように構成されている。図１２に示す例では、ビット番号０の「ＳＩＰ／ＲＴＰパケット」には、識別回路１２ｃの論理式が以下の内容でセットされる。
（ａ）イーサヘッダのタイプがＩＰパケットである。
（ｂ）ＩＰヘッダのプロトコルフィールドがＵＤＰである。
（ｃ）ＵＤＰヘッダのポート番号が５００４〜５０６０である。
同様にして、ビット番号１のＩＰｖ６パケット、ビット番号２のＴａｇＶＬＡＮパケット、ビット番号３のＰＰＰｏＥパケット、ビット番号４のＩＰパケット、ビット番号５のＴＣＰパケット等がハードウエア的に識別可能であり、制御部（ＣＰＵ＋ソフトウエア）６は、識別結果に基づいて、輻輳状態の場合における通過／廃棄の判断が可能となる。
図１３は本発明のパケット処理装置のパケット入力制限処理部において実施する第２実施形態のパケット入力制限処理を例示するフローチャートである。まず、図１３のステップＳ１１では、受信パケットタイプ識別回路（１３−１または１３−２）から次に処理すべきパケット（以下、当該パケットという）に対応する識別結果レジスタ（１３ｅ１〜１３ｅ６４の何れか）の内容を読み出す。次のステップＳ１２では、読み出した識別結果レジスタの内容から当該パケットの通過／破棄を判定し、通過と判定された場合には処理をステップＳ１３に進め、廃棄と判定された場合には処理をステップＳ１４に進める。ステップＳ１３では、受信バッファ（１２−１または１２−２）より当該パケットを取り出してパケット処理部３の共通受信キューに積み込み、ステップＳ１４では、受信バッファ（１２−１または１２−２）より当該パケットを取り出して破棄する。
本実施形態のパケット処理装置によれば、上記第１実施形態と同様の作用効果が得られるとともに、受信部２で受信したパケットの識別されたパケットタイプがパケット廃棄条件に該当する場合に当該パケットを破棄するから、パケット処理装置１の輻輳の早期解消を図ることができるとともに、パケット受信部２内に受信パケットタイプ識別回路１３−１，１３−２というハードウエアを設けたことにより、受信したパケットのパケットタイプを識別するソフトウエア処理を軽減することができる。
［第３実施形態］
図１４は本発明のパケット処理装置のパケット受信部において実施する第３実施形態の受信パケットタイプ識別処理を例示するフローチャートであり、受信部２で受信したパケットを受信バッファ１２−１，１２−２から取り出してパケット処理部３の共通受信キュー１４に積み込む際に、通過条件に合致するパケットのみを積み込むようになっている。本実施形態では、図４に示すパケット受信部２の受信パケットタイプ識別回路１３−１，１３−２として、ハードウエアを設けずに、同等の機能をソフトウエアによって実現するように構成している。
図１４は本発明のパケット処理装置のパケット受信部において実施する第３実施形態の受信パケットタイプ識別処理を例示するフローチャートであり、受信部２で受信したパケットを受信バッファ１２−１，１２−２から取り出してパケット処理部３の共通受信キュー１４に積み込む際に、通過条件に合致するパケットのみを積み込むようになっている。本実施形態では、図４に示すパケット受信部２の受信パケットタイプ識別回路１３−１，１３−２として、ハードウエアを設けずに、同等の機能をソフトウエアによって実現するように構成している。
まず、図１４のステップＳ２１では、受信バッファ（１２−１または１２−２）から次に処理すべきパケット（以下、当該パケットという）の１２バイト目および１３バイト目を読み出し、次のステップＳ２２では、「パケットタイプの通過判定」を行う。このパケットタイプの通過判定では、当該パケットのパケットタイプと予め設定されたパケットタイプ毎の通過条件／廃棄条件とを照合して、「通過」、「廃棄」、「無視」の何れかの判定を下して、得られた判定結果は自己保持するものとする。
次のステップＳ２３では、受信バッファ（１２−１または１２−２）から当該パケットの１５バイト目を読み出し、次のステップＳ２４では、「ＴＯＳの通過判定」を行う。このＴＯＳの通過判定では、当該ＴＯＳ値と予め設定されたＴＯＳ値毎の通過条件／廃棄条件とを照合して、「通過」、「廃棄」、「無視」の何れかの判定を下して、得られた判定結果は自己保持するものとする。
次のステップＳ２３では、受信バッファ（１２−１または１２−２）から当該パケットの１５バイト目を読み出し、次のステップＳ２４では、「ＴＯＳの通過判定」を行う。このＴＯＳの通過判定では、当該ＴＯＳ値と予め設定されたＴＯＳ値毎の通過条件／廃棄条件とを照合して、「通過」、「廃棄」、「無視」の何れかの判定を下して、得られた判定結果は自己保持するものとする。
次のステップＳ２５では、受信バッファ（１２−１または１２−２）から当該パケットの２５バイト目を読み出し、次のステップＳ２６では、「プロトコルの通過判定」を行う。このプロトコルの通過判定では、当該プロトコルと予め設定されたプロトコル毎の通過条件／廃棄条件とを照合して、「通過」、「廃棄」、「無視」の何れかの判定を下して、得られた判定結果は自己保持するものとする。
次のステップＳ２７では、受信バッファ（１２−１または１２−２）から当該パケットの３８バイト目および３９バイト目を読み出し、次のステップＳ２８では、「ポート番号の通過判定」を行う。このポート番号の通過判定では、当該ポート番号と予め設定されたポート番号毎の通過条件／廃棄条件とを照合して、「通過」、「廃棄」、「無視」の何れかの判定を下して、得られた判定結果は自己保持するものとする。
次のステップＳ２８では、以上によって得られた判定結果を評価に基づき、下記1.または2.の処理を行う。
1.受信バッファより当該パケットを取り出し、破棄する。
2.受信バッファより当該パケットを取り出し、共通受信キューに積み込む。
その後、次のステップＳ２９では、受信バッファ（１２−１または１２−２）の次の処理対象となるパケットの処理に進むことになる。
次のステップＳ２７では、受信バッファ（１２−１または１２−２）から当該パケットの３８バイト目および３９バイト目を読み出し、次のステップＳ２８では、「ポート番号の通過判定」を行う。このポート番号の通過判定では、当該ポート番号と予め設定されたポート番号毎の通過条件／廃棄条件とを照合して、「通過」、「廃棄」、「無視」の何れかの判定を下して、得られた判定結果は自己保持するものとする。
次のステップＳ２８では、以上によって得られた判定結果を評価に基づき、下記1.または2.の処理を行う。
1.受信バッファより当該パケットを取り出し、破棄する。
2.受信バッファより当該パケットを取り出し、共通受信キューに積み込む。
その後、次のステップＳ２９では、受信バッファ（１２−１または１２−２）の次の処理対象となるパケットの処理に進むことになる。
本実施形態のパケット処理装置によれば、上記第１実施形態と同様の作用効果が得られるとともに、受信部２の受信パケットタイプ識別回路１３−１，１３−２を、ハードウエアを用いずに、ソフトウエアによって実現しているので、パケット処理装置のコストダウンを図ることができる。
１ パケット処理装置
２ パケット受信部
３ パケット処理部
４ パケット送信部
５ パケット入力制限処理部
６ 制御部
１１−１，１１−２ 受信回路
１２−１，１２−２ 受信バッファ
１３−１，１３−２ 受信パケットタイプ識別回路
１３ａ アドレス検出回路
１３ｂ１〜１３ｂ８ パケットレジスタ
１３ｃ 識別回路
１３ｄ 識別条件レジスタ
１３ｅ１〜１３ｅ６４ 識別結果レジスタ
１３ｆ 結果格納タイミング回路
１３ｇ システムバス制御回路
１３ｈ 読出選択回路
１４ 共通受信キュー
１５ 送信バッファ
１６ 送信回路
２ パケット受信部
３ パケット処理部
４ パケット送信部
５ パケット入力制限処理部
６ 制御部
１１−１，１１−２ 受信回路
１２−１，１２−２ 受信バッファ
１３−１，１３−２ 受信パケットタイプ識別回路
１３ａ アドレス検出回路
１３ｂ１〜１３ｂ８ パケットレジスタ
１３ｃ 識別回路
１３ｄ 識別条件レジスタ
１３ｅ１〜１３ｅ６４ 識別結果レジスタ
１３ｆ 結果格納タイミング回路
１３ｇ システムバス制御回路
１３ｈ 読出選択回路
１４ 共通受信キュー
１５ 送信バッファ
１６ 送信回路
Claims (10)
- パケットを受信するパケット受信手段と、受信したパケットに含まれる宛先情報に基づいて転送先を決定するパケット処理手段と、転送先を決定されたパケットを当該転送先に送信するパケット送信手段と、前記各手段の動作を制御する制御手段とを備えるパケット処理装置であって、
前記パケット受信手段および前記パケット処理手段の間にパケット入力制限処理手段を設け、前記制御手段による前記パケット処理手段の輻輳判定時には、前記パケット入力制限処理手段を動作させて、前記制御手段によって指定されたタイプのパケットを優先的に前記パケット処理手段に通過させるようにしたことを特徴とするパケット処理装置。 - 前記制御手段によって指定されたタイプのパケット以外のパケットを廃棄するようにしたことを特徴とする請求項１記載のパケット処理装置。
- 前記パケット受信手段は、外部から入力されたパケットを受信する受信回路と、該受信回路で受信したパケットを格納する受信バッファと、受信したパケットのタイプを識別する受信パケットタイプ識別回路とを備え、
該受信パケットタイプ識別回路は、前記制御手段によって予め指定された受信バッファの先頭アドレスに基づいてパケットのタイプを特定するヘッダ情報位置を算出し、前記受信回路で受信されたパケットが前記受信バッファに格納されると同時に、前記ヘッダ情報位置のヘッダ情報を保持し、該ヘッダ情報に基づいてパケット毎にパケットタイプの識別結果を生成して保持するようにしたことを特徴とする請求項１または２記載のパケット処理装置。 - 前記パケット受信手段は、外部から入力されたパケットを受信する受信回路と、該受信回路で受信したパケットを格納する受信バッファと、受信したパケットのタイプを識別する受信パケットタイプ識別回路とを備え、
該受信パケットタイプ識別回路は、前記制御手段によって予め指定された受信バッファの先頭アドレスに基づいてパケットのタイプを特定するヘッダ情報位置を算出し、前記受信回路で受信されたパケットが前記受信バッファに格納されると同時に、前記ヘッダ情報位置のヘッダ情報を保持し、該ヘッダ情報に基づいてパケット毎にパケットタイプの識別結果を生成するとともに、該パケットタイプの識別結果と前記制御手段によって予め指定されたパケットタイプ毎のパケット通過条件またはパケット廃棄条件とを照合して、パケット毎に通過または廃棄の判定を行い、判定結果を保持するようにしたことを特徴とする請求項１または２記載のパケット処理装置。 - 前記パケット受信手段は、外部から入力されたパケットを受信する受信回路と、該受信回路で受信したパケットを格納する受信バッファと、受信したパケットのタイプを識別する受信パケットタイプ識別回路とを備え、
該受信パケットタイプ識別回路は、前記制御手段によって予め指定された受信バッファの先頭アドレスに基づいてパケットのタイプを特定するヘッダ情報位置を算出し、前記受信回路で受信されたパケットが前記受信バッファに格納されると同時に、前記ヘッダ情報位置のヘッダ情報を保持し、該ヘッダ情報に基づいてパケット毎にパケットタイプの識別結果を生成するとともに、該パケットタイプの識別結果と前記制御手段によって予め指定された検出すべきパケットタイプとを照合して、パケット毎に予め指定された検出すべきパケットタイプであるか否かの判定を行い、判定結果を保持するようにしたことを特徴とする請求項１または２記載のパケット処理装置。 - 前記パケット入力制限処理手段は、前記パケット受信手段の受信バッファから受信したパケットを取り出して前記パケット処理手段に引き渡す際に、前記制御手段による前記パケット処理手段の輻輳判定時には、前記受信パケットタイプ識別回路によるパケットタイプの識別結果に基づいて、受信したパケットを前記パケット処理手段に引き渡す処理または受信したパケットを破棄する処理を行うようにしたことを特徴とする請求項１、２、３または５記載のパケット処理装置。
- 前記パケット入力制限処理手段は、前記パケット受信手段の受信バッファから受信したパケットを取り出して前記パケット処理手段に引き渡す際に、前記制御手段による前記パケット処理手段の輻輳判定時には、前記受信パケットタイプ識別回路によるパケット毎の通過または廃棄の判定結果に基づき、受信したパケットを前記パケット処理手段に引き渡す処理または受信したパケットを破棄する処理を行うようにしたことを特徴とする請求項４記載のパケット処理装置。
- 前記パケット入力制限処理手段は、前記パケット受信手段の受信バッファから受信したパケットを取り出して前記パケット処理手段に引き渡す際に、前記制御手段による前記パケット処理手段の輻輳判定時には、ヘッダ情報に基づいてパケット毎にパケットタイプの識別結果を生成するとともに、該パケットタイプの識別結果に基づいて受信したパケットを前記パケット処理手段に引き渡す処理または破棄する処理を行うようにしたことを特徴とする請求項１記載のパケット処理装置。
- 前記制御手段による前記パケット処理手段の輻輳判定は、前記パケット受信手段から前記パケット入力制限処理手段を経由して前記パケット処理手段に設けた共通受信キューに積まれたパケットのパケット数が上限値を越えた場合に前記パケット処理手段の輻輳と判定するようにしたことを特徴とする請求項１〜８の何れか１項記載のパケット処理装置。
- 前記制御手段によって指定されたタイプのパケットは、音声パケットを含むリアルタイム性を要求されるパケットであることを特徴とする請求項１〜９の何れか１項記載のパケット処理装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2005049445A JP2006238039A (ja) | 2005-02-24 | 2005-02-24 | パケット処理装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2005049445A JP2006238039A (ja) | 2005-02-24 | 2005-02-24 | パケット処理装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2006238039A true JP2006238039A (ja) | 2006-09-07 |
Family
ID=37045209
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005049445A Pending JP2006238039A (ja) | 2005-02-24 | 2005-02-24 | パケット処理装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2006238039A (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009239785A (ja) * | 2008-03-28 | 2009-10-15 | Saxa Inc | 通信装置および中継装置 |
| US9201611B2 (en) | 2013-04-19 | 2015-12-01 | Kabushiki Kaisha Toshiba | Interface control apparatus, data storage apparatus and interface control method |
| JP2019121017A (ja) * | 2017-12-28 | 2019-07-22 | 株式会社リコー | 情報処理装置、脆弱性検知方法およびプログラム |
-
2005
- 2005-02-24 JP JP2005049445A patent/JP2006238039A/ja active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009239785A (ja) * | 2008-03-28 | 2009-10-15 | Saxa Inc | 通信装置および中継装置 |
| US9201611B2 (en) | 2013-04-19 | 2015-12-01 | Kabushiki Kaisha Toshiba | Interface control apparatus, data storage apparatus and interface control method |
| JP2019121017A (ja) * | 2017-12-28 | 2019-07-22 | 株式会社リコー | 情報処理装置、脆弱性検知方法およびプログラム |
| JP7167439B2 (ja) | 2017-12-28 | 2022-11-09 | 株式会社リコー | 情報処理装置、脆弱性検知方法およびプログラム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9344377B2 (en) | Packet processing architecture | |
| US9246825B2 (en) | Accelerated processing of aggregate data flows in a network environment | |
| US9166921B2 (en) | Selective packet sequence acceleration in a network environment | |
| EP3014851B1 (en) | Apparatus and method for distribution of policy enforcement point | |
| US6434153B1 (en) | Packet communication system with QoS control function | |
| JP3993092B2 (ja) | サービス拒否攻撃を防ぐための方法 | |
| US8792353B1 (en) | Preserving sequencing during selective packet acceleration in a network environment | |
| US8630294B1 (en) | Dynamic bypass mechanism to alleviate bloom filter bank contention | |
| US8149705B2 (en) | Packet communications unit | |
| US8792495B1 (en) | System and method for managing out of order packets in a network environment | |
| US9722933B2 (en) | Selective packet sequence acceleration in a network environment | |
| US10701190B2 (en) | Efficient parsing of optional header fields | |
| US10135736B1 (en) | Dynamic trunk distribution on egress | |
| US10637792B2 (en) | Real-time analysis of quality of service for multimedia traffic in a local area network | |
| JP2000332817A (ja) | パケット処理装置 | |
| JP2004503986A (ja) | コンテンツ・アウェアネットワーク装置 | |
| US10122735B1 (en) | Switch having dynamic bypass per flow | |
| US8320249B2 (en) | Method and system for controlling network access on a per-flow basis | |
| US20130294449A1 (en) | Efficient application recognition in network traffic | |
| US10516615B2 (en) | Network traffic congestion control | |
| CN108737217B (zh) | 一种抓包方法及装置 | |
| US8630296B2 (en) | Shared and separate network stack instances | |
| WO2014112616A1 (ja) | 制御装置、通信装置、通信システム、スイッチの制御方法及びプログラム | |
| US20190097931A1 (en) | System and method for control traffic reduction between sdn controller and switch | |
| US9942161B1 (en) | Methods and systems for configuring and updating session-based quality of service for multimedia traffic in a local area network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20060609 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20060711 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20060713 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20060711 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20070613 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070703 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20071030 |