JP4500701B2

JP4500701B2 - パケット転送装置

Info

Publication number: JP4500701B2
Application number: JP2005035403A
Authority: JP
Inventors: 有一石川
Original assignee: Alaxala Networks Corp
Current assignee: Alaxala Networks Corp
Priority date: 2005-02-14
Filing date: 2005-02-14
Publication date: 2010-07-14
Anticipated expiration: 2025-02-14
Also published as: JP2006222821A

Description

本発明は、ネットワークに流入するパケットの流量を監視して、契約に適合しないパケットを廃棄するポリシング方法およびこれに基いたネットワーク監視方法およびパケット転送装置に関する。

インターネットの普及に伴い、従来一般的であった通常のWeb閲覧のデータに加えて、VoIP(Voice over IP)、ストリーム転送をはじめとするリアルタイム系アプリケーションのデータや、ビジネス用途のミッションクリティカルデータ等の高い通信品質を要求するアプリケーションデータもIPネットワーク上で通信されるようになってきている。このため、IPネットワーク上で通信品質を制御する技術の一つとして、インターネット技術の標準化団体IETF(Internet Engineering Task Fore)においてDiffserv(Differentiated Services)が標準化されており（非特許文献１、２参照）、ネットワークを構成するルータ、スイッチ等のネットワークノードに広く実装されている。
Diffservを実装しているネットワークノード(DS-compliant node)では、アプリケーション毎の通信品質要求を満たすために各種のPHB(Per-Hop-Behavior)と呼ばれる転送処理を実行することができる。PHBの種別には、最低帯域を保証して低遅延の完全優先転送を提供するEF(Expedited Forwarding)、複数のクラスをもち、クラス毎に相対的な優先転送を提供するAF(Assured Forwarding)、そしてベストエフォートでの転送を提供するBE(Best Effort)がある。アプリケーション毎に適用するPHBとして例えば、低遅延を厳しく求められるVoIPにはEFを、VoIP以外で通信品質を要求するアプリケーションには、アプリケーション毎に求められる遅延および廃棄率特性に応じたクラスのAFを、そしてWeb閲覧のように通信品質の要求が高くないアプリケーションにはBEを適用することにより、アプリケーション毎の品質要求を満たすことができる。
上述の各種PHBを実現するため、DS-compliant nodeはDiffservの構成要素として規定されているClassifier、Meter、Marker、Dropper、Shaperを所持する（非特許文献２参照）。以上の構成要素から成るDiffservの機能ブロックの構成を、図１に示す。
図1に示した処理の流れに沿って、Diffservの機能ブロックにおけるパケット処理の流れを説明する。DS-compliant node108のDiffserv機能ブロック107に入力した入力パケットに対しては、まず各種PHBのうちいずれのPHBを適用すべきか判定することが必要である。入力パケット毎にいずれのPHBを適用すべきかという分類は、Diffservに基づいて共通のポリシーで運用されるネットワーク(DSドメイン)の管理者がパケットのヘッダ内容に対応して予め定義しておく必要があり、この分類定義はClassifierに登録される。この分類定義に従って、Classifier101にて入力パケットのヘッダ内容がいずれのPHBの分類定義に一致するか識別し、パケットの分類を行う。以下、Classifierにて入力パケットのヘッダ内容に基づいて分類されたパケットの各集合をフロー、フローに分類するための定義をフロー定義と呼ぶ。

次にMarker102では、Classifier101にて分類されたフロー毎に適用されるPHBに対応するDSCP（Differentiated Services Code Point）が与えられる。この処理をMarkingと呼ぶ。DSCPとはIPヘッダ中のType of Service（IPv6ではTraffic Class）の上位6bitであり、DSドメイン内でPHBを識別するために用いられる。各種PHBに推奨されるDSCPの値は各々、EFは非特許文献３、AFは非特許文献４、BEは非特許文献１で規定されている。

DSドメインの管理者と、DSドメインを利用して通信を行うユーザとの間でトラフィックプロファイルを契約している場合には、Meter103にてユーザ毎のトラフィックの帯域、バースト量等の流量を計測し、各ユーザとの契約に適合している(in-profile)か、適合していないか(out-of-profile)を判定する。EFを適用されるパケットがout-of-profileとなった場合には、当該パケットはDropper104にて廃棄され、AFを適用されるパケットがout-of-profileとなった場合には、Marker102にて廃棄率のより高いクラスに再Markingされる。なお、以上のMeter103、Marker102、Dropper104を合わせて、Policer106と呼ばれる流量監視機構を構成する。Policer106において計測する流量と、out-of-profileとなった場合にDropper104にて廃棄するか否かの設定、およびout-of-profileとなっても廃棄しなかった場合に再MarkingされるDSCPの値に関する定義をPolicer定義と呼ぶ。

Diffserv機能ブロックの最終段に位置するShaper105では、Marker102により与えられたDSCPが指示するPHBに相当する転送処理を実行する。一般的にShaper105は、図2に示すようにパケットを蓄積する複数のキュー201-i（i=1〜6）と、複数のキュー201-iのうちいずれのキューからパケットを送信するかを判定するスケジューラ202から構成されており、EF用のキュー201-1とAF用のキュー201-2、201-3、201-4、201-5、BE用のキュー201-6は独立に所持している。複数のキューの間には送信制御に関する優先関係があり、EF用のキュー201-1として最優先キューを割り当てることにより、低遅延の完全優先転送を実現できる。BE用のキュー201-6には最低優先キューを割り当て、AFの各クラス用のキュー201-2、201-3、201-4、201-5には、各クラス間の優先関係に一致した順序で優先キューを割り当てることにより、各種のPHBに対応した転送処理を実現できる。

K. Nichols, et al. "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", IETF, RFC2474, December 1998.

S. Blake, et al. "An Architecture for Differentiated Services", IETF, RFC2475, December 1998. B. Davie, et al. "An Expedited Forwarding PHB (Per-Hop Behavior)", IETF, RFC3246, March 2002. J.Heinanen, et al. "Assured Forwarding PHB Group", IETF, RFC2597, June 1999.

スケジューラ202は、最優先キューにパケットが蓄積されている限り最優先キューに蓄積されているパケットを最優先で送信すると判定するため、その間は他のキューからはパケットが送信されなくなってしまう。その結果、他のキューに蓄積されるパケットは遅延が増大したり、キュー長が増加してキューからパケットが溢れてしまうことにより廃棄が発生したりしてしまうといった悪影響を無制限に被ってしまう。この、EFトラフィックによる他のPHBへの無制限な悪影響を防止するためには、EFトラフィックの帯域を適当な値以下に制限することが必要であり、非特許文献３ではこの制限帯域と許容するバースト量の値をDSドメインの管理者が設定可能となっていなければならないと定められている。また、非特許文献３ではEFトラフィックに対して最低帯域を保証することも定められているので、制限帯域は最低帯域以上の値とする必要がある。

以下では、ユーザ毎にトラフィックプロファイルを契約しているDSドメインにおいて、最優先キューを割り当てられたEFとBEを適用されるフローを制御しようとする場合について考える。なおAFを適用されるフローが混在している場合にも、以下に示す課題は同様に発生する。

図3に示すように、n個のユーザ網302-1〜302-n に接続されたDSドメイン301での通信を考える。DSドメイン301はn個のユーザ網302-1〜302-nとの間で帯域とバースト量に関するトラフィックプロファイルを契約している。更に、各ユーザ網302-1〜302-nから送信されるトラフィックに対しては、アプリケーション毎に適用するPHBが予め定義されており、EFを適用されるパケットとBEを適用されるパケットの両方が送信され得るものとする。
各ユーザ網302-1〜302-nからの入力トラフィックは全て、DS-compliant nodeであるDSノード108-１に送信され、DSノード108-１内のDiffserv機能ブロック107にて帯域制御と、PHBに応じた転送処理が実行される。以下に、Diffserv機能ブロック107における処理の流れの概要を説明する。
DSノード108-1への全ての入力トラフィックに対してまず、Diffserv機能ブロック107内のClassifier101にてパケットの分類が行われる。例えば、IPヘッダ中の送信元のIPアドレスをチェックすることでパケットを送信したユーザを識別でき、更にトランスポート層のTCPヘッダ、あるいはUDPヘッダの送信元ポート番号をチェックすることで、アプリケーションを識別することができる。

Classifier101にて識別されたユーザ情報に基づいて、Policer106にてユーザ毎の流量監視を実行し、out-of-profileとなった場合にはDropper104にて当該パケットを廃棄する。廃棄されなかったパケットに対しては、Classifier101にて識別されたアプリケーション情報に基づいて、当該パケットに対し適用すべきPHBに対応するDSCPがMarker102にて与えられる。このDSCPに基づいて、当該パケットはShaper105で適用すべきPHBに割り当てられたキュー210-iに蓄積され、スケジューラ202による送信判定の結果、PHBに対応した適当な転送処理が実行される。
ここで、DSノード108-1に求められる帯域制御について述べる。DSノード108-1におけるPolicer106では、上述したようにユーザ間の帯域干渉を防止してユーザ毎に契約された帯域を提供するため、ユーザ毎のトラフィックの流量を監視し、これがユーザ毎の契約帯域を超過した場合には当該パケットをDropper104にて廃棄することにより帯域制限することが必要である。冒頭でも説明した通り、EF以外のPHBに対する無制限な悪影響を防止するために、EFトラフィックに対しても適当な制限帯域で帯域制限をかけることが必要である。特定のユーザによるEF用の最優先キューの占有を防止するためには、EFトラフィックに対する帯域制限はユーザ毎にも実行するのが望ましい。即ち、ユーザ毎のEFトラフィックの流量、即ちユーザ毎かつアプリケーション毎の流量を監視し、これを帯域制限することもまた、必要である。以上に述べたユーザ毎の帯域制限と、ユーザ毎かつアプリケーション毎の帯域制限を共に実現する上での課題について以下に説明する。
ユーザiのトラフィックの制限帯域をM_i、ユーザiかつアプリケーションjのパケットとして構成されるユーザiのEFトラフィックの制限帯域をm_i(M_i≧m_i)とする。図4に示すように、Classifier101に「ユーザiかつアプリケーションj」というフロー定義401-1を登録して、これに対するPolicer定義402-1を「制限帯域m_iで帯域制限」と定義する。また、「ユーザi」というフロー定義401-2を登録して、これに対するPolicer定義402-2を「制限帯域M_iで帯域制限」と定義する。なお、通常Classifierに登録されるフロー定義は図5のようなリストの形をとっており、登録された順序に従って上位のフロー定義1 501-1から順番にパケットのヘッダ内容と一致するか識別され、一致した時点で一致比較の処理を終了する。従って、リスト中にパケットのヘッダ内容と一致するフロー定義が複数ある場合でも、そのうち最上位に登録されているフロー定義のみ一致すると識別される。従って、図4の例では「ユーザiかつ、アプリケーションj以外」のフローだけがフロー定義401-2「ユーザi」に一致し、「ユーザiかつアプリケーションj」のフローはフロー定義401-2「ユーザi」には一致しないと識別される。従って、Policer定義402-2によってM_iに帯域制限されるのは、「ユーザiかつ、アプリケーションj以外」のフローだけである。「ユーザiかつアプリケーションj」のフローは、Policer定義402-2によるM_iの帯域制限を受けず、Policer定義402-1によるm_iの帯域制限だけを受ける。「ユーザiかつ、アプリケーションj以外」のフローはM_iに帯域制限され、「ユーザiかつアプリケーションj」のフローはm_iに帯域制限されるので、これらのフローを合わせた「ユーザi」のフローとしての制限帯域はM_i+m_iとなってしまい、本来の制限帯域であるM_iを超過してしまうという課題がある。

次に上述の課題を回避するため、図6に示すように「ユーザiかつ、アプリケーションj以外」のフローに対し適用される制限帯域から予め超過分のm_iを差し引いて、Policer定義402-3「制限帯域M_i−m_iで帯域制限」と設定する方法について考える。この場合、「ユーザi」のフローとしての制限帯域をM_i、「ユーザiかつアプリケーションj」のフローの制限帯域をm_iとすることができる。しかしこの場合には、「ユーザiかつ、アプリケーションj以外」のフローの制限帯域がM_i−m_iに抑えられてしまうので、「ユーザiかつアプリケーションj」のフローが通信されていない場合の「ユーザi」のフローとしても制限帯域M_i−m_iとなってしまう。従って、「ユーザiかつアプリケーションj」の未使用帯域を有効に活用することができず、DSドメイン301としてユーザiが契約した契約帯域を十分に提供することができないという課題がある。

上述の課題を解決するため本発明のポリシング方法では、あるフローのパケットの流量を制限する際に、当該フローのうち一部のフローだけの流量を更に制限することを特徴とする。更に、あるフローのパケットの流量である全帯域と、前記特定種類のパケットのうち一部のパケットのみの流量である一部帯域とを各々パケットの送信元であるユーザと契約されている場合に、
前記あるフローのパケットのうち一部のパケットが流入したときの全帯域が契約に適合しない場合であっても、一部帯域が契約に適合している場合には当該パケットを廃棄しないことを特徴とする。

[発明が解決しようとする課題]の欄において述べた、DSドメイン301内のDSノード108-1における帯域制御の問題が、本発明によっていかに解決されるかを以下に説明する。まず、図4に示されたClassifierとPolicerの関係は、図7のように変更される。図７では図４の制御に加えて、「制限帯域M_iで帯域制限」というPolicer定義402-2を「ユーザiかつアプリケーションj」というフロー定義401-1と「ユーザi」というフロー定義401-2の両方に適用するため、フロー定義401-1に対してもPolicer定義402-2を適用することを示す矢印701が追加されている。図4の制御では、「ユーザiかつアプリケーションj」のフローはフロー定義401-2「ユーザi」には一致しないので、Policer定義402-2によってM_iに帯域制限されるのは、「ユーザiかつ、アプリケーションj以外」のフローだけであった。しかし図7の制御では、「ユーザiかつアプリケーションj」のフローに対してもPolicer定義402-2が適用されるので、「ユーザi」のフロー全てがM_iに帯域制限される。これによって、あるフローのパケットの流量を制限する際に、当該フローのうち一部のフローだけの流量を更に制限することが可能となる。
しかし、この制御だけでは「ユーザiかつアプリケーションj」のフローが過剰に帯域制限されてしまう問題があることを、次に説明する。

図８に、DSノード108-1への入力帯域の例として、「ユーザiかつアプリケーションj以外」のフローの入力帯域801と、「ユーザiかつアプリケーションj」のフローの入力帯域802を示す。初め、「ユーザiかつアプリケーションj以外」のフローがPolicer定義402-2による制限帯域M_iを超過する入力帯域801で入力し、その後時刻tからユーザiかつアプリケーションj」のフローがPolicer定義402-1による制限帯域m_iを満たす入力帯域802で入力する。「ユーザiかつアプリケーションj以外」のフローの入力帯域は、制限帯域M_iを超過するのでPolicer定義402-2に不適合と判定され、図９に示すようにPolicer106による帯域制限後の「ユーザiかつアプリケーションj以外」のフローの帯域901は制限帯域M_iに抑えられ、制限帯域M_iを有効に使い切っている。このとき「ユーザiかつアプリケーションj」のパケットが入力すると、「ユーザiかつアプリケーションj」のパケットに対するPolicer定義402-1には適合であっても、「ユーザi」のパケットとしては制限帯域M_iを既に使い切っているので、Policer定義402-2には不適合と判定されてしまう。図１０に示すように、あるフローのパケットの流量である全帯域と、あるフローのパケットのうち一部のパケットのみの流量である一部帯域とのいずれかに不適合と判定されたパケットを廃棄する制御を行っている場合には、「ユーザiかつアプリケーションj」のパケットはPolicer定義402-1に適合しているにも関わらず廃棄されてしまう。その結果、「ユーザiかつアプリケーションj」のパケットは、当該フローに対する制限帯域以内の帯域で入力された場合であっても必ずしも制限帯域分の帯域を提供されずなくなってしまう。即ち、EFトラフィックを制限帯域以内で入力した場合であっても、必ずしも完全優先転送されず廃棄されてしまうので、EFトラフィックとしての最低帯域も必ずしも保証できなくなってしまう。

非特許文献３では、EFトラフィックとしての最低帯域を保証することが定められている。EFトラフィックが制限帯域内で入力した場合にはこれを廃棄せず必ず完全優先転送するものとすれば、EFトラフィックの制限帯域分を固定的な帯域として割り当てることができるので、最低帯域を保証することも可能となる。そのためには図11に示すように、あるフローのパケットのうち一部のパケットのみの流量である一部帯域に適合と判定されたパケットに対しては、あるフローのパケットの流量である全帯域に不適合と判定された場合であっても当該パケットを廃棄しない制御が必要となる。この制御により、上述の「ユーザiかつアプリケーションj」のパケットは、当該フローに対する制限帯域以内の帯域で入力された場合であれば必ず制限帯域分の帯域を提供される。即ち、EFトラフィックを制限帯域以内で入力した場合には、廃棄されず必ず完全優先転送されるので、EFトラフィックとしての最低帯域を保証することができる。

なお上述の制御では、あるフローの全帯域に不適合と判定された場合であっても当該パケットを廃棄しない場合があるため、この制御だけでは当該フローの全帯域に対する制限帯域を定常的に超過してしまう。この問題を回避するため、全帯域に不適合と判定されたが一部帯域には適合と判定されて廃棄されなかったパケットが使用した分の、全帯域に対する超過帯域を管理する。そして、後続の到着パケットに対してこの超過帯域分を解消するように帯域制限の処理を制御する必要がある。パケットが到着する度に、前回パケットが到着してからの経過時間を考慮した上でこの超過帯域を再計算する。再計算された超過帯域が正の値である場合は、全帯域に対する超過帯域分がまだ解消されていない。そこで、超過帯域が正の値である場合に到着したパケットに対して、一部帯域が契約されておりかつこれに適合している場合を除き、到着パケットを廃棄する。これにより、全帯域から超過帯域を差し引きした帯域値で帯域制限がなされる。その結果、一部帯域を保証すると共に超過帯域を解消して、全帯域に対する制限帯域を定常的に超過することのないように制御できる。Policer106内のMeter103における本制御の詳細な実施例は、「発明を実施するための最良の形態」の欄にて説明する。

図8に示されたDSノード108-1への入力帯域に対して本制御を実施した際の、Policer106による帯域制限後の「ユーザiかつアプリケーションj以外」のフローの帯域1201と、「ユーザiかつアプリケーションj」のフローの帯域1202の時間変化を、図12に示す。時刻tから「ユーザiかつアプリケーションj」のフローが制限帯域m_iを満たす入力帯域802で入力し始めると、本制御を実施するPolicer106は「ユーザiかつアプリケーションj」のパケットを全て適合と判定して転送する。この結果、「ユーザiかつアプリケーションj」のフローが使用する帯域が帯域1202である。一方この間、「ユーザiかつアプリケーションj以外」のフローは、M_i−帯域1202の帯域1201に帯域制限される。最終的に帯域1202がm_iで帯域制限されるようになると、Mi−miが「ユーザiかつアプリケーションj以外」のフローが使用する帯域1201となり、「ユーザi」のフローとしては帯域1201と帯域1202合わせてM_iに帯域制限される。

ネットワークに流入するパケットの流量を制限するポリシングにおいて、特定種類のパケットの流量を制限する際に、前記特定種類のパケットのうち一部のパケットのみの流量を更に制限することができる。
更に特定種類のパケットの流量である全帯域と、前記特定種類のパケットのうち一部のパケットのみの流量である一部帯域とを各々パケットの送信元であるユーザと契約されている場合に、前記特定種類のパケットのうち一部のパケットが流入したときの全帯域が契約に適合しない場合であっても、一部帯域が契約に適合している場合には当該パケットを廃棄しないことにより、一部帯域を最低帯域として保証することができる。
ポリシングによるネットワーク監視方法では、シェーピングのようにパケットを遅延させるのではなく、廃棄することによってパケットの使用する帯域が契約に適合するよう制御する。従って、パケットを遅延させるためのキューを構成するメモリ資源を必要としないため、前述の帯域制御をシェーピングによって実現しようとする場合と比較すると、本発明のポリシング方法の方がより低コストに実現することができる。
また、シェーピングではキューにおける遅延時間の計算や、パケットを送信するキューの選択を実行するスケジューリングが処理を高速化する上でのネックとなる。従って、前述の帯域制御をシェーピングによって実現しようとする場合と比較すると、本発明のポリシング方法の方が処理をより高速化することができ、高速回線に適用する上で有利である。

本発明のポリシング方法において、前記特定種類のパケットの例としてこれをユーザ毎のパケットとし、前記特定種類のパケットのうち一部のパケットの例としてこれをネットワーク内のパケット中継装置における最優先キューに蓄積されるパケット、あるいはネットワーク内で最優先に転送されるパケットとすることによってユーザ毎のパケットの流量を制限する際に、ユーザ毎のパケットのうち最優先に処理されるパケットの流量を更に制限することができる。また、ユーザ毎のパケットのうち最優先に処理されるパケットに契約された一部帯域を最低帯域として保証することができる。また、ユーザ毎のパケットのうち最優先に処理されるパケットが流れていない場合には、ユーザ毎のパケットのうち最優先に処理されるパケット以外のパケットがユーザ毎のパケットに契約された全帯域を有効に使い切ることができる。

また、前記特定種類のパケットの他の例としてこれをユーザ毎のパケットとし、前記特定種類のパケットのうち一部のパケットの例としてこれをDiffservにおけるEF-PHBを適用されるパケットとする。この場合には、ユーザ毎のパケットの流量を制限する際に、ユーザ毎のパケットのうちEFを適用されるパケットの流量を更に制限することができる。また、ユーザ毎のパケットのうちEFを適用されるパケットに契約された一部帯域を最低帯域として保証することができる。また、ユーザ毎のパケットのうちEFを適用されるパケットが流れていない場合には、ユーザ毎のパケットのうちEFを適用されないパケットがユーザ毎のパケットに契約された全帯域を有効に使い切ることができる。

また、前記特定種類のパケットの他の例として、前記特定種類のパケットのうち一部のパケットが、ネットワーク内の輻輳状態に応じて送信するパケットの流量を制御する輻輳制御を伴わずに送信されるパケットであり、その他の前記特定種類のパケットが輻輳制御を伴って送信されるパケットである場合には、ユーザ毎のパケットの流量を制限する際に、輻輳制御を伴わないパケットの流量を更に制限することによって、輻輳制御を伴って送信されるパケットの流量が輻輳制御を伴わないパケットの流量によって無制限に制限されてしまうことを防止できる。

また、前記特定種類のパケットの他の例として、トランスポート層のプロトコルにUDPまたはTCPを用いて通信しているユーザ毎のパケットを考え、前記特定種類のパケットのうち一部のパケットの例としてこれをトランスポート層のプロトコルがUDPであるUDPパケットとする。この場合には、ユーザ毎のパケットの流量を制限する際に、ユーザ毎のパケットのうちUDPパケットの流量を更に制限することができる。また、ユーザ毎のパケットのうちUDPパケットに契約された一部帯域を最低帯域として保証することができる。また、ユーザ毎のパケットのうちUDPパケットが流れていない場合には、ユーザ毎のパケットのうちトランスポート層のプロトコルがTCPであるTCPパケットがユーザ毎のパケットに契約された全帯域を有効に使い切ることができる。

まず、本発明を適用したパケット転送装置の構成概要を、図１３を用いて説明する。パケット転送装置600は、パケットが入力するN個の入力回線610-i(i=1〜N)と、パケットの受信処理を行なうパケット受信回路620-iと、ルーティング処理部630と、パケットをスイッチングするパケット中継処理手段640と、出力回線毎の帯域監視部650-j(j=1〜M)と、廃棄制御部660-jと、送信処理を行なうパケット送信回路670-jと、パケットが出力されるN個の出力回線680-jから構成される。

図１４は、本発明が想定するネットワークにおけるパケットのフォーマットの一例を示す。パケットはヘッダ部710とデータ部720から構成される。ヘッダ部710は送信元IPアドレス(Source IP address：以下「SIP」と称する。)711と、宛先IPアドレス(Destination IP address：以下「DIP」と称する。)712と、送信元ポート(Source PORT：以下「SPORT」と称する。)713と、宛先ポート(Destination PORT：以下「DPORT」と称する。)714とから構成される。また、データ部720はユーザデータ721から構成される。ヘッダ部710には、前記情報以外にも生存時間(TTL：Time to Live)等の情報も格納されているが、前記情報と同様に後述の処理を実行できる。

図１５は、本発明を適用したパケット転送装置600内部におけるパケットのフォーマットの一例を示す。パケット転送装置600内部のパケットのフォーマットには、IPネットワークのパケットのフォーマットに内部ヘッダ810が加わる。内部ヘッダ810はパケットが入力した回線の識別子である入力回線番号811と、パケットが出力される回線の識別子である出力回線番号812と、パケットのバイト長を表すパケット長813と、帯域監視の結果指示された廃棄制御部660-jにおけるパケット蓄積FIFO665-ｊに対する蓄積・廃棄を指示する蓄積廃棄指示814と、パケット蓄積FIFO665-ｊに対するキューイング優先度815とから構成される。

次に、本発明を適用したパケット転送装置の動作概要を、図１３を用いて説明する。パケット転送装置600の入力回線610-iからパケットが入力すると、パケット受信回路620-iは内部ヘッダ810を付加し、パケットのバイト長を計算した上でパケット長813(単位はByte)に書き込む。更に、パケットが入力した入力回線610-iを入力回線番号811に書き込み、ルーティング処理部630へパケットを送信する。尚、この時点では出力回線番号812は無意味な値となっている。ルーティング処理部630は、パケットを受信するとDIP712
に基づいてパケットを出力する回線680-jを判定し、出力回線680-jの回線番号jを出力回線番号812に書き込みパケット中継処理手段640に送信する。パケット中継処理手段640は出力回線番号812に従ってパケットをスイッチングし、出力回線毎の帯域監視部650-jに送信する。
帯域監視部650-jは、SIP711に基づいてパケットの属するユーザを検出し、更にSPORT713またはDPORT714に基づいてアプリケーション種別を検出し、各アプリケーション毎の帯域監視と各ユーザの帯域監視を行ない、アプリケーション毎に契約された最低帯域を必ず保証すると共に、更にアプリケーション毎の帯域制限とユーザ毎の帯域制限を行う。この帯域監視部650-ｊの詳細動作については後述する。帯域監視されたパケットに対して、帯域監視の結果指示された図16の廃棄制御部660-jにおけるパケット蓄積FIFO665-jに対する蓄積・廃棄の指示を蓄積廃棄指示814に、パケット蓄積FIFO665-jに対するキューイング優先度をキューイング優先度815に書き込み、廃棄制御部660-jに送信する。
廃棄制御部660-jに送信されたパケットは、一旦一時蓄積バッファ662-jに蓄積される。帯域監視部650-jから送信されたパケットの蓄積廃棄指示814に基づき、「廃棄」と指示された場合には、一時蓄積バッファ662-jからパケット蓄積FIFO665-jにパケットを送信しない。そして、「廃棄」と判定されたパケットの次に廃棄制御部660-jに到着したパケットの情報を上書きする。「蓄積」と指示された場合には、キューイング優先度毎閾値蓄積手段661-jからキューイング優先度815に対するパケット蓄積FIFO665-jの閾値を参照して、この閾値とFIFOカウンタ664-jの値を比較する。この閾値がFIFOカウンタ664-jより大きい場合には、「蓄積」と判定してパケットをパケット蓄積FIFO665-jに送信すると共に、FIFOカウンタ664-jの値に1加算する。閾値がFIFOカウンタ664-j以下の場合には、「廃棄」と判定してパケットをパケット蓄積FIFO665-jに送信せず、FIFOカウンタ664-jの値に加算しない。そして、「廃棄」と判定されたパケットの次に廃棄制御部660-jに到着したパケットの情報を上書きする。
パケット出力制御部666-jはパケット蓄積FIFO665-jに蓄積した順番に回線帯域でパケットを送信するようにパケット送信起動信号667-jを送信し、この信号を受信したパケット蓄積FIFO665-jはパケット送信回路670-jへパケットを送信する。また、FIFOカウンタ665-jは前記パケット送信起動信号667-jを受信するとFIFOカウンタ665-jから1減算する。本発明では、パケット出力制御部666-jは回線帯域でパケットを送信するようにパケット送信起動信号667-jを送信するが、ネットワーク運用者によって設定された回線帯域以下の帯域(例えば、回線帯域の半分)で送信しても良い。パケット送信回路670-jへ送信されたパケットは、内部ヘッダ810を外されて出力回線680-ｊへ送信される。

次に、帯域監視部650-ｊの詳細動作について説明する。帯域監視アルゴリズムとしてリーキーバケットアルゴリズムを、IPの可変長パケットに拡張した帯域監視アルゴリズムを使用する。リーキーバケットアルゴリズムはある深さを持った穴の空いた漏れバケツのモデルで、バケツに水が入っている間は監視帯域で水は漏れ続け、パケット入力時にはこのパケットのバイト長分の水が注ぎ込まれる。パケットの到着揺らぎを許容するためにバケツに深さを持ち、バケツが溢れないうちは入力パケットは遵守と、溢れると違反と判定される。

図１７に帯域監視部650-ｊのブロック図を示す。帯域監視部650-ｊは、フロー検出部と、フロー毎帯域監視テーブル制御部と、フロー毎バケツ蓄積量判定部と、フロー毎帯域監視結果判定部と、フローグループ検出部と、フローグループ帯域監視テーブル制御部と、フローグループバケツ蓄積量判定部と、フローグループ帯域監視結果判定部と、監視結果総合判定部とから構成される。フロー毎帯域監視テーブルのフォーマットを図１８に、フローグループ帯域監視テーブルのフォーマットを図１９に示す。11-1〜11-6は各々、ユーザAのサービスA1からユーザBのサービスB3に対応するサービス毎帯域監視エントリ、12-1はユーザ、12-2はユーザBのユーザ帯域監視エントリである。THRはバケツの深さ、POLRは監視帯域、TSは前回パケット到着時刻、CNTはバケツに蓄積されている水量を示すバケツ蓄積量、TOSCは遵守時のサービス識別子、QCは遵守時のキューイング優先度、DROPは違反時の「廃棄」または「蓄積」の指示を示す。フロー検出部はフロー毎帯域監視をするためにパケットヘッダ内の情報のうちSIP711によりフロー識別子を判定する。フロー毎帯域監視テーブル制御部は、前記フロー識別子に対応するフロー毎帯域監視エントリを参照し、帯域監視に必要なTHR、POLR、TS、CNT、TOSC、QC、DROPのパラメタを読み出して、各々THR蓄積手段、POLR蓄積手段、TS蓄積手段、CNT蓄積手段、TOSC蓄積手段、QC蓄積手段、DROP蓄積手段に蓄積する。以下では、フローがサービスA1のパケットであり、フローグループがユーザAのパケットである場合を説明する。

フロー毎バケツ蓄積量判定部では、パケット入力直前のバケツの水量を判定する。まず、バケツ蓄積量判定回路は現時刻をカウントするタイマーの値とTS蓄積手段のTS-A1との差分を計算し、バケツに水が前回蓄積されてから経過した経過時間を計算する。次に経過時間にPOLR蓄積手段内のPOLR-A1を乗じて、バケツに水が前回蓄積されてから漏れた水の量を計算する。更に、CNT蓄積手段内のCNT-A1からバケツ内水量減少量を減算して、パケットが入力する直前の水量であるバケツ蓄積量を判定する。前記バケツ蓄積量の正負を判定し、判定結果が負の場合にはバケツ蓄積量を0に修正する。
フロー毎監視結果判定部の監視結果判定回路は、入力パケットのパケット長に相当する水がバケツに入るか否かを判定する。まず、前記のバケツ蓄積量にパケット長を加算して、これをTHR蓄積手段内のTHR-A1と大小比較する。バケツ蓄積量+パケット長がTHR-A1よりも大なるときは、パケット長に相当する水を入力した場合にバケツが溢れてしまうので、入力パケットを違反パケットと判定して、この判定結果を監視結果総合判定部に送信する。バケツ蓄積量+パケット長がTHR-A1以下のときは入力パケットを遵守パケットと判定し、この判定結果を監視結果総合判定部に送信する。
フローグループバケツ蓄積量判定部でも、フローグループ帯域監視テーブルから同様にして読み出したパラメタに対し同様の処理を繰り返し、判定結果を監視結果総合判定部に送信する。
監視結果総合判定部では、フロー毎の判定結果とフローグループ毎の判定結果に基づいて、このパケットに対する蓄積廃棄指示814、キューイング優先度815、サービス識別子713を判定して、これらを廃棄制御部660-jに送信する。サービス毎の判定結果が「遵守」のパケットに対しては、蓄積指示となりTOSC-A1、QC-A1を廃棄制御部660-jに送信する。「違反」の場合は廃棄される。
更に、フロー毎帯域監視の判定結果が「遵守」であった場合、バケツ蓄積量+パケット長を新たなバケツ蓄積量CNT-A1として、現時刻のタイマーの値を新たなTS-A1としてフロー毎帯域監視テーブル制御部に送信し、次の入力パケットに対してフロー毎帯域監視テーブルを読み出す前にユーザA1のフロー毎帯域監視エントリに書き込む。同様に、フローグループ帯域監視の判定結果が「遵守」であった場合にも新たなCNT-A、TS-Aをフローグループ帯域監視テーブルに書き込む。更に、フローグループ帯域監視の判定結果が「違反」であった場合にも、フロー毎帯域監視結果が「遵守」であれば、新たなCNT-A、TS-Aを超過帯域分を示す超過帯域情報としてフローグループ帯域監視テーブルに書き込む。

図２０に帯域監視アルゴリズムのフローチャートを示す。13の処理、即ちフロー毎帯域監視判定結果が「遵守」であった場合に、新たなCNT-A、TS-Aを超過帯域分を示す超過帯域情報としてフローグループ帯域監視テーブルに書き込む。
以上説明した本発明により、ネットワークに流入するパケットの流量を制限するポリシングにおいて、特定種類のパケットの流量を制限する際に、前記特定種類のパケットのうち一部のパケットのみの流量を更に制限することができる。
更に特定種類のパケットの流量である全帯域と、前記特定種類のパケットのうち一部のパケットのみの流量である一部帯域とを各々パケットの送信元であるユーザと契約されている場合に、前記特定種類のパケットのうち一部のパケットが流入したときの全帯域が契約に適合しない場合であっても、一部帯域が契約に適合している場合には当該パケットを廃棄しないことにより、一部帯域を最低帯域として保証することができる。

DS-compliant nodeの構成図。キューの構成例を示す図。 DSドメインを示す図。 ClassifierとPolicerを示す図。フロー定義リスト ClassifierとPolicerを示す図。 ClassifierとPolicerを示す図。帯域の時間変化。帯域の時間変化。フローチャート。フローチャート。帯域の時間変化。本発明を適用するパケット転送装置のブロック図。ネットワーク上のパケットのヘッダ及びデータ構成を示す図。図１６のパケット転送装置内のパケットの構成を示す図。図１３のパケット転送装置内の廃棄制御部のブロック図。帯域監視部のブロック図。フロー毎帯域監視テーブルのフォーマット。フローグループ帯域監視テーブルのフォーマット。帯域監視方法のフローチャート。

Claims

パケットを受信する受信部と、
パケットを送信する送信部と、
複数の種類のパケットが属するグループに対応づけられる第一のパケットの量と、
前記グループを構成するパケットの種類のうち、所定の種類に対応づけられる第二のパケットの量と、を保持する保持部と、
前記受信されたパケットの種類を判別し、
前記判別した種類が、前記所定の種類の場合は、前記受信されたパケットを前記第二のパケットの量を所定の時間内に受信した前記所定の種類のパケット量が超過するか否かを判断する第一の判断を行い、
前記第一の判断結果、超過した場合、前記受信されたパケットを廃棄し、
前記第一の判断結果、超過しない場合は、前記受信されたパケットを、前記送信部を介して、転送し、
前記判別した種類が、前記所定の種類でない場合は、前記受信パケットが属するグループを特定し、
前記特定されたグループに対応づけられる第一のパケットの量を所定の時間内に受信した前記グループに属するパケット量が超過するか否かを判断する第二の判断を行い、
前記第二の判断結果、超過した場合、前記受信されたパケットを廃棄し、
前記第二の判断結果、超過しない場合は、前記受信されたパケットを前記送信部を介して転送する制御部と、を有することを特徴とするパケット転送装置。
請求項１記載のパケット転送装置であって、
前記制御部は、前記第一の判断結果、超過しない場合は、前記グループに属するパケット量が前記第一のパケットの量を超過するにもかかわらず、前記受信されたパケットを、前記廃棄せずに前記送信部を介して、転送する、ことを特徴とするパケット転送装置。
請求項１記載のパケット転送装置であって、
前記制御部は、
前記受信したパケットの入力回線番号、出力回線番号、パケットヘッダ内のアドレス情報、該パケットの用途を識別する情報、または該パケットの優先度を識別する情報のうち少なくともいずれか一つの情報に基づいて、該受信したパケットが前記グループに属するか否か、および前記所定の種類のパケットに該当するか否かを識別することを特徴とするパケット転送装置。
請求項１記載のパケット転送装置であって、
前記グループに属するパケットは、所定の送信元からのパケットであって、
前記所定の種類のパケットは、前記所定の送信元のパケットであり、かつネットワーク内で優先的に転送されるパケットであることを特徴とするパケット転送装置。
請求項１記載のパケット転送装置であって、
前記グループに属するパケットは、所定の送信元からのパケットであって、
前記所定の種類のパケットは、前記所定の送信元からのであり、かつDiffserv (Differentiated Services)におけるEF-PHB (Expedited Forwarding-Per Hop Behavior)に基
づいて転送されるパケットであることを特徴とするパケット転送装置。
請求項１記載のパケット転送装置であって、
前記グループに属するパケットは、所定の送信元からのパケットであって、
前記グループに属する前記所定の種類以外の種類のパケットは、前記所定の送信元からのパケットであり、かつネットワーク内の輻輳状態に応じて送信するパケットの流量を制御して転送されるパケットであり、
前記所定の種類以外の種類のパケットは、前記特定のユーザのパケットであり、かつ前記所定の種類のパケットの流量の制御を受けずに転送されるパケットであることを特徴とするパケット転送装置。
請求項１記載のパケット転送装置であって、
前記グループに属するパケットは、所定の送信元からのパケットであって、
前記所定の種類のパケットは、前記所定の送信元からのパケットであり、かつトランスポート層のプロトコルがUDP (User Datagram Protocol)のパケットであり、
前記グループに属する前記所定の種類以外の種類のパケットは、前記所定の送信元からのパケットであって、かつトランスポート層のプロトコルがTCP（Transmission Control Protocol）である、ことを特徴とするパケット転送装置。