JP2012175481A - 通信システムおよび伝送装置 - Google Patents

Abstract

【課題】廃棄率を低減させて通信品質の向上を図ることが可能になる。
【解決手段】通信システムは、第１の伝送装置と第２の伝送装置を備える。第１の伝送装置は、パケットを格納するバッファを有し、バッファからパケットを所定レートで読み出してシェーピングを行う。第２の伝送装置は、第１の伝送装置から送信されたパケットを受信して中継する。第１の伝送装置は、バッファのリソース状況に応じて、シェーピングを第２の伝送装置へ依頼し、第２の伝送装置は、第１の伝送装置に代わってシェーピングを実行して、第１の伝送装置から第２の伝送装置へ、シェーピングポイントを動的に移行させる。
【選択図】図１

Description

本発明は、情報通信を行う通信システムおよび伝送装置に関する。

情報ネットワークにおいて、ルータやＬ２ＳＷ（Layer 2 Switch）などのパケット伝送を行う装置では、シェーピング（Shaping）と呼ばれるトラフィック出力制御が行われている。

シェーピングは、ユーザとの契約帯域に応じて、送信パケットの間隔を調整し、契約帯域を越えないように、転送レートを平滑化する制御である。
パケットシェーピングを行う装置では、ユーザ毎のキュー（論理キュー）にパケットをいったんキューイングし、設定されたレートで読み出してパケットを出力する。

出力レートよりも入力レートの方が大きい場合は、パケットはキューイングされ、キュー長が一定の廃棄閾値を超えると、到着パケットはキューイングされずに、廃棄される（Tail Dropと呼ばれる）。

また、キューには、バースト耐性を持たせるために、ある程度のキュー長のバッファスペースが用意されるが、ユーザ毎の個別キューすべてに対して、廃棄閾値までのバッファスペースを静的に確保しておくことは利用効率が悪く、実装面においても限界がある。

このため、一般的には共通バッファ方式が用いられている。これは、個別キューのバッファスペースの他に、共通のバッファスペース（プール）も用意しておく方式である。到着パケットの容量が個別キューに用意してあるスペース分を越えたら、共通バッファから必要なスペースを動的に確保するようにする。これにより、利用効率を向上させ、実装規模も縮小化できる。

従来技術として、受信データを共通バッファに方路別に記憶させ、共通バッファを仮想的に個別バッファとして使用する技術が提案されている。また、Ｎ個の入力バッファと１個の共有バッファとを持ち、共有バッファの空きスペースがＮパケット分以上ある場合に、パケット格納先を入力バッファから共有バッファに移行して、バースト耐力を持たせた技術が提案されている。

特開平１１−３２０５５号公報 特開平７−１０７１１６号公報

共通バッファ方式では、統計多重効果を計るべく、共通バッファのバッファサイズよりも、各個別キューにおける廃棄閾値までのバッファサイズの合計の方が大きくなるように設計される。

しかし、あるキューがバースト的に共通バッファのバッファスペースを占有した場合、他のキューでは、共通バッファのリソース枯渇に伴って、共通バッファからスペースを確保できなくなる。すると、該キューでは、廃棄閾値に達していないにもかかわらず、パケット廃棄が行われてしまう。

このように、共通バッファ方式のような限られたバッファ資源の中では、キュー間での干渉が発生し、キューの輻輳耐力が低下する。このため、パケットの廃棄率が上昇してしまい、通信品質を劣化するといった問題があった。

本発明はこのような点に鑑みてなされたものであり、パケットの廃棄率を低減して、通信品質の向上を図った通信システムを提供することを目的とする。
また、本発明の他の目的は、パケットの廃棄率を低減して、通信品質の向上を図った伝送装置を提供することを目的とする。

上記課題を解決するために、通信システムが提供される。通信システムは、パケットを格納するバッファから、前記パケットを所定レートで読み出してシェーピングを行う第１の伝送装置と、前記第１の伝送装置から送信された前記パケットを受信して中継する第２の伝送装置とを備える。前記第１の伝送装置は、前記バッファのリソース状況に応じて、前記シェーピングを前記第２の伝送装置へ依頼し、前記第２の伝送装置は、前記第１の伝送装置に代わって前記シェーピングを実行する。

廃棄率を低減して通信品質の向上を図ることが可能になる。

通信システムの構成例を示す図である。 共通バッファ方式を説明するための図である。 ネットワークの構成例を示す図である。 通信システムの動作を説明するための図である。 通信システムの動作を説明するための図である。 前段ノードの構成例を示す図である。 後段ノードの構成例を示す図である。 シェーピング依頼時の前段ノードの動作を示すフローチャートである。 シェーピング依頼時の後段ノードの動作を示すフローチャートである。 シェーピング依頼解除時の前段ノードの動作を示すフローチャートである。 シェーピング依頼解除時の後段ノードの動作を示すフローチャートである。 前段ノードにおけるシェーピング依頼前のフロー処理を示す図である。 前段ノードにおけるシェーピング依頼後のフロー処理を示す図である。 シェーピング依頼前の後段ノードのフロー処理を示す図である。 シェーピング依頼後の後段ノードのフロー処理を示す図である。 送出レートのネゴシエーションを示す図である。 シェーピングポイントが移行した場合の状態を示す図である。 キュー長のネゴシエーションを示す図である。 後段ノードからのバッファリソース広報を示す図である。 シェーピング依頼の解除を示す図である。 フォーマットの一例を示す図である。 シェーピング依頼を行う際のシーケンスを示す図である。 バッファリソース広報を行う際のシーケンスを示す図である。 シェーピング依頼解除を行う際のシーケンスを示す図である。 最大送出レートでのシェーピング依頼を示す図である。 予備パスを利用したシェーピング依頼を示す図である。

以下、本発明の実施の形態を図面を参照して説明する。図１は通信システムの構成例を示す図である。通信システム１は、伝送装置１ａ（第１の伝送装置）と伝送装置２ａ（第２の伝送装置）を備える。

伝送装置１ａは、パケットを格納するバッファ１１を有し、バッファ１１から、パケットを所定レートで読み出してシェーピングを行う。また、伝送装置２ａは、伝送装置１ａから送信されたパケットを受信して中継する。

ここで、伝送装置１ａは、バッファ１１のリソース状況に応じて、シェーピングを伝送装置２ａへ依頼し、伝送装置２ａは、伝送装置１ａに代わってシェーピングを実行する。
このように、通信システム１では、伝送装置１ａのバッファ１１のリソース状況に応じて、伝送装置１ａから伝送装置２ａへ、シェーピングポイントを動的に移行する構成とした。

これにより、伝送装置１ａのバッファ１１のリソース枯渇（容量不足）が生じたような場合でも、伝送装置２ａ側でシェーピングが行われることにより、バッファ１１のリソース枯渇状態をすみやかに解消させることができ、パケットの廃棄率を低減させて、通信品質の向上を図ることが可能になる。

次に一般的な共通バッファ方式について図２を用いて説明する。図２は共通バッファ方式を説明するための図である。個別キューｑ１〜ｑ４はそれぞれ、あらかじめ設けた固定的な個別バッファスペースを有しており、必要に応じて共通バッファからスペースを確保して、パケットのキューイングを行う。なお、個別キューｑ１〜ｑ４の廃棄閾値までのバッファスペースの合計は、共通バッファスペースよりも大きい。

到着したパケットは、個別キューｑ１〜ｑ４にキューイングされる。今、個別キューｑ１〜ｑ３では、個別バッファスペースを超えて、さらに共通バッファスペースを確保して、それぞれの廃棄閾値まで到着パケットをキューイングしているとする。

このとき、個別キューｑ１〜ｑ３によって、共通バッファスペースが占有されたとすると、個別キューｑ４では、まだ廃棄閾値に達していなくても、共通バッファスペースの枯渇により、パケットを廃棄してしまうことになる。このように、共通バッファ方式では、キュー間での干渉が発生して、キューの輻輳耐力が低下し、パケット廃棄率が増加してしまう。

一方、キュー長が廃棄閾値を超過した、または超過しそうな場合には、パケットの入力元に対してバックプレッシャ（Back Pressure）をかけて、キューへの入力を制限する場合がある。

しかし、すでにキューに滞留してしまったパケットは、例えば、入力＞＞＞出力のような場合には、キュー枯渇の解消（すなわち枯渇が解消するまでパケットが読み出される）までには非常に長い時間を要し、また、パケット入力元の機器がバックプレッシャによって制御できる機能を有しているとは限らない（例えば、顧客の機器など）。

なお、共通バッファ方式を例にして説明したが、上記の問題は、共通バッファ方式に限定されるものではなく、限られたバッファ資源の中でのシェーピング（キューイング）に関して生じるものである。

本技術はこのような点に鑑みてなされたものであり、限られたバッファ資源の中でのシェーピング（キューイング）に対して、パケット廃棄率を低減し、通信品質の向上を図った通信システムおよび伝送装置を提供するものである。

次に通信システム１が適用されるネットワークの一例について説明する。図３はネットワークの構成例を示す図である。通信システム１が適用されるネットワークの例としてMPLS−VPN（Multiprotocol Label Switching−Virtual Private Network）のネットワーク２を考える。

ネットワーク２は、送信元エッジノードＰＥ０（PE：Provider Edge）、宛先エッジノードＰＥ５およびコアノードＰ１〜Ｐ４を含む。送信元エッジノードＰＥ０には、ユーザ端末ａ、ｂが接続し、また、コアノードＰ１、Ｐ２が接続する。宛先エッジノードＰＥ５には、ユーザ端末ｃ、ｄが接続し、また、コアノードＰ３、Ｐ４が接続する。コアノードＰ１〜Ｐ４は、メッシュ状に接続する。

送信元エッジノードＰＥ０では、ユーザ（VPN）を識別するためのPWラベル（Pseudo Wire Label）と、宛先エッジノードＰＥ５を識別するためのTunnelラベルとをパケットに付与して転送する。

例えば、ユーザ端末ａは、パケットｐ１に対して、TunnelラベルとしてT01と、PWラベルとしてPWaとを付与して、パケットｐ１−１を生成して転送する。なお、PWxは、VPNxを示すユーザ識別ラベルである。したがって、PWaは、VPNaであり、この例では、VPNa内のユーザ端末ａから転送されたパケットであることを示す。

また、Tx1x2は、x1からx2へ転送することを示す。したがって、T01は、ノード＃０（送信元エッジノードＰＥ０）からノード＃１（コアノードＰ１）への転送を示す。以下、同様の見方である。

ユーザ端末ｂは、パケットｐ２に対して、TunnelラベルとしてT01と、PWラベルとしてPWbとを付与して、パケットｐ２−１を生成して転送する。
パケットｐ１−１、ｐ２−１は、コアノードＰ１に到着する。コアノードＰ１では、パケットに付与されているラベルのうち、Tunnelラベルのみを参照し、あらかじめシグナリングされたラベルテーブルからラベルスワップする。

例えば、コアノードＰ１は、パケットｐ１−１、ｐ２−１のTunnelラベルT01をT13に変換して、パケットｐ１−２、ｐ２−２を生成して、後段のコアノードＰ３へ転送する。
同様に、パケットｐ１−２、ｐ２−２を受信したコアノードＰ３は、付与されたラベルのうち、Tunnelラベルのみを参照し、あらかじめシグナリングされたラベルテーブルからラベルスワップする。

例えば、コアノードＰ３は、パケットｐ１−２、ｐ２−２のTunnelラベルT13をT35に変換して、パケットｐ１−３、ｐ２−３を生成して、後段の宛先エッジノードＰＥ５へ転送する。

宛先エッジノードＰＥ５では、PWラベルを参照して（Tunnelラベルは１つ手前のコアノード＃３、＃４であらかじめ取り外されて転送される場合もある）、VPNを識別して、ユーザ端末ｃ、ｄそれぞれに転送する。

ここで、Tunnelラベルのシグナリングは、LDP（Label Distribution Protocol：RFC3036）やRSVP−TE（Resource Reservation Protocol−Traffic Engineering：RFC3209）などの公知のプロトコルを用いて実施される。また、コアノードＰ１〜Ｐ４は、ラベルテーブルを個々に有して、ラベルテーブルの登録内容に従って、パケットをラベルスワップしながら転送する。

なお、RSVP−TEを用いた場合、ラベルシグナリングと合わせて帯域リソースの予約を行うことも可能である。このとき、コアノードＰ１〜Ｐ４は、物理帯域を超過しないようにリソースの予約が行われるため、コアノードＰ１〜Ｐ４は、定常的には非輻輳の状態となる。

したがって、ユーザのトラフィックは、送信元エッジノードＰＥ０で契約に応じてシェーピングされた後は、従来のコアノードＰ１〜Ｐ４ではシェーピング（キューイング）されることなく、宛先エッジノードＰＥ５まで転送される。

次に通信システム１の動作例について図４、図５を用いて説明する。通信システム１では、前段ノード（伝送装置１ａ）におけるシェーピング時に、バッファリソースの枯渇が生じるような場合には、後段ノード（伝送装置２ａ）にシェーピングを依頼して、前段ノードの代わりに後段ノードにおいてシェーピングを実行させて、キュー輻輳時の廃棄率を低減させる。

図４、図５は通信システム１の動作例を説明するための図である。図４は後段ノードへのシェーピングの依頼を示し、図５は後段ノードでのシェーピングの実行を示している。
ネットワーク２−１（MPLS−VPN）は、送信元エッジノードＰＥ０およびコアノードＰ１〜Ｐ３を含み、送信元エッジノードＰＥ０は、コアノードＰ１〜Ｐ３と接続する。

送信元エッジノードＰＥ０は、キューｑ１〜ｑ３を備え、コアノードＰ１〜Ｐ３はそれぞれ、キューｑ１１、ｑ２１、ｑ３１を備える（本技術で適用するキューは論理キューである）。なお、キューの出力側に示される図中の丸印内の“Ｓ”は、該キューがシェーピングを行っていることを示す。

図４において、送信元エッジノードＰＥ０で契約帯域にもとづくレートでシェーピングを実行しようとしたときに、キューｑ１〜ｑ３のバッファスペースが枯渇しそうになったとする。

この場合、送信元エッジノードＰＥ０では、後段のコアノードＰ１〜Ｐ３に対して、所定レートでのシェーピングの依頼を行う。例えば、送信元エッジノードＰＥ０は、コアノードＰ１に対して、TunnelラベルがT01、PWラベルがPWaのフローの１００Ｍｂｐｓのシェーピングの依頼メッセージＲ１を送信する。

また、コアノードＰ２に対して、TunnelラベルがT02、PWラベルがPWbのフローの５０Ｍｂｐｓのシェーピングの依頼メッセージＲ２を送信する。さらに、コアノードＰ３に対して、TunnelラベルがT03、PWラベルがPWcのフローの２００Ｍｂｐｓのシェーピングの依頼メッセージＲ３を送信する。

そして、上記レートでのシェーピングが可能であるならば、該当のコアノードで、シェーピングを実行する。コアノードＰ１、Ｐ２では、依頼されたレートでシェーピングを行う際のバッファリソースに余裕があり、コアノードＰ３では余裕がないとすると、コアノードＰ１、Ｐ２は依頼を了承し、コアノードＰ３は、依頼を拒否する。

図５において、コアノードＰ１、Ｐ２は、依頼されたシェーピングを実行する。この場合、コアノードＰ１では、既存のキューｑ１１から、依頼されたレートでのシェーピングを行うための別キューｑ１１ａを割り当てて（切り出して）、別キューｑ１１ａにて１００Ｍｂｐｓのシェーピングを行う。

また、コアノードＰ２では、既存のキューｑ２１から、依頼されたレートでのシェーピングを行うための別キューｑ２１ａを切り出して、別キューｑ２１ａにて５０Ｍｂｐｓのシェーピングを行う。

コアノードＰ３に依頼したシェーピングは拒否されたので、コアノードＰ１、Ｐ２において、依頼したシェーピングが行われる。このため、送信元エッジノードＰＥ０では、バッファリソースの枯渇が徐々に解消されて、リソースに余裕ができる。このため、コアノードＰ３に依頼したT03／PWcのフローの２００Ｍｂｐｓのシェーピングを、自ノードＰＥ０で実行することが可能となる。

以上説明したように、送信元エッジノードにおいて、シェーピング時にバッファリソースが枯渇または枯渇しそうになった場合は、後段のコアノードがエッジノードに代わってシェーピングを実行するという動作を行う。すなわち、バッファのリソース資源の状況に応じて、シェーピング（キューイング）のポイントを動的に移す。

後段のコアノードでは、バッファリソースに余裕があり、送信元エッジノードの代わりにシェーピングが可能であるならば、依頼を受託し、該フローについて、シェーピングを実行する。

これにより、送信元エッジノードは、滞留パケットが読み出されるので、次第にバッファ枯渇が解消してゆく。その後、バッファリソースの枯渇が解消した場合には、シェーピング依頼を解除して、送信元エッジノードおよびコアノードそれぞれが、依頼前の元のシェーピング状態またはキューイング状態に戻る。

このように、例えば、バースト的なトラフィック（入力レート＞＞出力レート）によりバッファが占有されて枯渇状態となったような場合、該エッジノードから後段のコアノードに対して、輻輳（キュー長が廃棄閾値を超過）しているフローのシェーピングの移行（肩代わり）を依頼する。

ただし、一方的にシェーピングを押し付けると、バッファ枯渇のポイントが後段側に単に移動するだけになる。このため、対象フロー（MPLS−VPNの場合は、PWラベルとTunnelラベルによりフロー識別される）と、シェーピングレートとともにネゴシエーションを行って、了承された場合にのみシェーピングの移行を行う。

そして、後段ノードでは、エッジノードからシェーピングの移行を依頼されて、バッファリソースに余裕がない場合は、依頼を拒否する（ネゴシエーションの動作例については後述する）。

次に通信システム１が備える前段ノードおよび後段ノードの構成について説明する。図６は前段ノードの構成例を示す図である。前段ノード１０は、図１の伝送装置１ａおよび図３〜図５の送信元エッジノードＰＥ０に対応する。

前段ノード１０は、後段ノード２０と接続し、バッファ１１と、パケットをバッファ１１から所定レートで読み出してシェーピングを行うシェーピング制御部１２とを備える。
バッファ１１は、パケットをバッファリングする。シェーピング制御部１２は、バッファ１１のリソース状況に応じて、シェーピングを他ノードへ依頼して、自ノードに代わってシェーピングを他ノード側で実行させる。

シェーピング制御部１２は、キュー管理部１２ａ、パスデータベース（パスＤＢ）１２ｂ、シェーピング管理部１２ｃおよびＣＰＵ（Central Processing Unit）部１２ｄを含む。

キュー管理部１２ａは、バッファ１１のリソースを管理し、キュー長の監視・管理を行う。パスデータベース１２ｂは、パスのフロー情報を格納管理する。シェーピング管理部１２ｃは、該当キューに対してシェーピングレートの設定変更を行う。ＣＰＵ部１２ｄは、プロセッサ、メモリおよびＩ／Ｆ等を有して、各構成要素に対する全体制御および所定の制御を実行させるための指示を行い、また、他ノードとの通信を行う。

図７は後段ノードの構成例を示す図である。後段ノード２０は、図１の伝送装置２ａおよび図３〜図５のコアノードに対応する。後段ノード２０は、前段ノード１０と接続し、バッファ２１およびバッファ２１からパケットを読み出して出力する読み出し制御部２２を備える。

バッファ２１は、パケットをバッファリングする。読み出し制御部２２は、他ノードからシェーピングの依頼を受けた場合に、シェーピング対象のパケットを格納する別バッファをバッファ２１から割り当てて、別バッファからシェーピング対象のパケットを読み出し、他ノードに代わってシェーピングを実行する。

読み出し制御部２２は、フロー識別部２２ａ、パスデータベース２２ｂ、キュー管理部２２ｃ、シェーピング管理部２２ｄおよびＣＰＵ部２２ｅを含む。フロー識別部２２ａは、到着パケットのフロー識別を行う。パスデータベース２２ｂは、パスのフロー情報を格納管理する。

キュー管理部２２ｃは、バッファ２１のリソースを管理し、キュー長の監視・管理およびキューの設定変更を行う。シェーピング管理部２２ｄは、該当キューに対してシェーピングレートの設定変更を行う。ＣＰＵ部２２ｅは、プロセッサ、メモリおよびＩ／Ｆ等を有して、各構成要素に対する全体制御および所定の制御を実行させるための指示を行い、また、他ノードとの通信を行う。

次に前段ノード１０から後段ノード２０へのシェーピング依頼時の動作についてフローチャートで説明する。図８はシェーピング依頼時の前段ノードの動作を示すフローチャートである。

〔Ｓ１ａ〕ＣＰＵ部１２ｄは、キュー管理部１２ａに対して、バッファ１１のリソース監視を指示し、キュー管理部１２ａは、指示にもとづいて、バッファリソース監視を行う。

〔Ｓ２ａ〕ＣＰＵ部１２ｄは、リソース監視結果から、現在のキューイングにおいて、キューの廃棄閾値を超過するか否かを判断する。超過する場合は、ステップＳ３ａへ行き、超過しない場合は終了する。

〔Ｓ３ａ〕ＣＰＵ部１２ｄは、廃棄閾値を超えるおそれのあるフローを認識し、パスデータベース１２ｂからフロー情報を抽出する。
〔Ｓ４ａ〕ＣＰＵ部１２ｄは、後段ノード２０へシェーピングの実行依頼を送信する。

〔Ｓ５ａ〕ＣＰＵ部１２ｄは、シェーピング依頼が了承されたか否かを認識する。了承された場合はステップＳ６ａへ行き、了承されない場合はステップＳ４ａへ戻る（なお、シェーピング依頼を複数回送信しても、後段ノード２０から了承をとれない場合は終了する）。

〔Ｓ６ａ〕ＣＰＵ部１２ｄは、シェーピング管理部１２ｃへ該フローのシェーピングレート設定の変更を指示し、シェーピング管理部１２ｃは、指示にもとづきシェーピングのレートを変更する。

図９はシェーピング依頼時の後段ノードの動作を示すフローチャートである。
〔Ｓ１ｂ〕ＣＰＵ部２２ｅは、前段ノード１０からシェーピング依頼を受信する。
〔Ｓ２ｂ〕ＣＰＵ部２２ｅは、キュー管理部２２ｃに対してバッファ２１のリソースチェックを指示し、キュー管理部２２ｃは、指示にもとづいて、バッファリソースチェックを行う。

〔Ｓ３ｂ〕ＣＰＵ部２２ｅは、リソースチェック結果から、バッファリソースに余裕があるか否かを判断する。余裕があればステップＳ５ｂへ行き、なければステップＳ４ｂへいく。

〔Ｓ４ｂ〕ＣＰＵ部２２ｅは、前段ノード１０に対して、依頼拒否のメッセージを送信する。
〔Ｓ５ｂ〕ＣＰＵ部２２ｅは、フロー識別部２２ａにフロー識別設定の変更を指示し、フロー識別部２２ａは、指示にもとづいて、シェーピング対象フローに対するフロー識別設定の変更を行う。

〔Ｓ６ｂ〕ＣＰＵ部２２ｅは、キュー管理部２２ｃに対して、キュー設定変更指示を行い、キュー管理部２２ｃは、指示にもとづき、シェーピング対象フロー用のキューを設定する。

〔Ｓ７ｂ〕ＣＰＵ部２２ｅは、シェーピング管理部２２ｄにシェーピング設定を指示し、シェーピング管理部２２ｄは、依頼されたシェーピング設定を行う。
〔Ｓ８ｂ〕ＣＰＵ部２２ｅは、前段ノード１０に対して、シェーピングの依頼を了承した旨のメッセージを返信する。

次にシェーピング依頼の解除動作についてフローチャートで説明する。図１０はシェーピング依頼解除時の前段ノードの動作を示すフローチャートである。
〔Ｓ１１ａ〕ＣＰＵ部１２ｄは、キュー管理部１２ａに対して、バッファ１１のリソース監視を指示し、キュー管理部１２ａは、指示にもとづいて、バッファリソース監視を行う。

〔Ｓ１２ａ〕ＣＰＵ部１２ｄは、監視結果からキューの廃棄閾値超過が解消したか否かを判断する。解消した場合は、ステップＳ１３ａへ行き、解消しない場合は終了する。
〔Ｓ１３ａ〕ＣＰＵ部１２ｄは、シェーピング管理部１２ｃに対して、シェーピング設定を元に戻す指示を行い、シェーピング管理部１２ｃは、該フローのシェーピング設定を元に戻す。

〔Ｓ１４ａ〕ＣＰＵ部１２ｄは、後段ノード２０に対して、シェーピング依頼解除メッセージを送信する。
〔Ｓ１５ａ〕ＣＰＵ部１２ｄは、後段ノード２０から返信されるシェーピング解除完了メッセージの受信待ちを行い、シェーピング解除完了メッセージを受信した場合は終了する。

図１１はシェーピング依頼解除時の後段ノードの動作を示すフローチャートである。
〔Ｓ１１ｂ〕ＣＰＵ部２２ｅは、前段ノード１０からシェーピング依頼解除メッセージを受信する。

〔Ｓ１２ｂ〕ＣＰＵ部２２ｅは、キュー管理部２２ｃに対して、該フローのキュー長チェックを指示し、キュー管理部２２ｃは、指示にもとづいて、該フローのキュー長チェックを行う。

〔Ｓ１３ｂ〕ＣＰＵ部２２ｅは、チェック結果から、該キューが空になったか否かを確認する。空になった場合はステップＳ１４ｂへ行き、空でなければステップＳ１２ｂへ戻って空になるまで待つ。

〔Ｓ１４ｂ〕ＣＰＵ部２２ｅは、フロー識別部２２ａにフロー識別設定の変更を元に戻す指示を行い、フロー識別部２２ａは、指示にもとづいて、フロー識別設定の変更を元に戻す。

〔Ｓ１５ｂ〕ＣＰＵ部２２ｅは、キュー管理部２２ｃに対して、キュー設定を元に戻す指示を行い、キュー管理部２２ｃは、指示にもとづき、キュー設定を元に戻す。
〔Ｓ１６ｂ〕ＣＰＵ部２２ｅは、前段ノード１０に対して、シェーピング解除完了メッセージを送信する。

次に前段ノード１０におけるシェーピング依頼前と依頼後のフロー処理について説明する。図１２は前段ノードにおけるシェーピング依頼前のフロー処理を示す図である。
前段ノード１０では、入力ポートやＶＬＡＮなどから、入力したパケットｐ１〜ｐ３のフローを識別する。例えば、パケットｐ１のフローがＶＰＮａであり、パケットｐ２のフローがＶＰＮｂであり、パケットｐ３のフローがＶＰＮｃであるとして、それぞれのフローを識別する。

また、キューｑ１〜ｑ３がそれぞれ、ＶＰＮａ〜ＶＰＮｃのフローに対応しているとすると、ＶＰＮａのフローのパケットｐ１をキューｑ１にキューイングし、設定されたレート（例えば、１００Ｍｂｐｓとする）でシェーピングする。

同様に、ＶＰＮｂのフローのパケットｐ２をキューｑ２にキューイングし、１００Ｍｂｐｓでシェーピングし、ＶＰＮｃのフローのパケットｐ３をキューｑ３にキューイングし、１００Ｍｂｐｓでシェーピングする。

なお、キューｑ１から出力するパケットについては、ラベルテーブルにしたがって、TunnelラベルであるT01と、PWラベルであるPWaとを付与して、パケットｐ１−１を生成して出力する。

また、キューｑ２から出力するパケットについては、TunnelラベルであるT01と、PWラベルであるPWbとを付与して、パケットｐ２−１を生成して出力し、キューｑ３から出力するパケットについては、TunnelラベルであるT01と、PWラベルであるPWcとを付与して、パケットｐ３−１を生成して出力する。

図１３は前段ノードにおけるシェーピング依頼後のフロー処理を示す図である。図１２で示したPWa／T01のフロー（ＶＰＮａ）のシェーピングを後段ノード２０に依頼し、キューｑ１の滞留パケットが解消されている状態を示している。

なお、上記では、フロー識別後にキューイングを行っているが、フロー識別後にポリシング（契約帯域を満たしているか否かを監視して契約帯域を超える場合は、その時点でパケットを破棄する）を行ってからキューイングする構成にしてもよい。

次に後段ノード２０におけるシェーピング依頼前と依頼後のフロー処理について説明する。図１４はシェーピング依頼前の後段ノードのフロー処理を示す図である。後段ノード２０は、パケットｐ１−１、ｐ２−１、ｐ３−１を受信する。シェーピング依頼前では、Tunnelラベル＝T01は、すべて同一フローと認識し、パケットｐ１−１、ｐ２−１、ｐ３−１をキューｑ１１にキューイングする。

また、キューｑ１１からのパケット読み出し時には、例えば、次段ノードへ転送するためのラベルとして、TunnelラベルのT01を外してT13を付与して、パケットｐ１−２、ｐ２−２、ｐ３−２を生成して出力する。

図１５はシェーピング依頼後の後段ノードのフロー処理を示す図である。シェーピング依頼を了承する前では、Tunnelラベルのみを参照してフロー識別を行っていたが、シェーピング依頼の了承後では、PWラベルも参照してフロー識別を行い、対象フロー（この例ではPWa／T01のフロー）を別キューｑ１１ａに割り当てる。

そして、別キューｑ１１ａにおいて、前段ノード１０で依頼された１００Ｍｂｐｓのレートにてシェーピングを行って、さらに後段のノードへ転送する。対象フロー以外（例えば、同じTunnelラベルであってもPWは別ラベルのフロー）は、Tunnelラベルのみを参照したフローのキューイングのルールにしたがって転送を行う。

次にシェーピング依頼時における送出レートのネゴシエーションについて説明する。上記では、後段ノード２０に対してシェーピングを依頼した場合、前段ノード１０では、該フローのシェーピングを行わずに出力するとした。

この場合、全くシェーピングを行わずに入力レートと同じレートで出力してしまうと、後段ノード２０側が輻輳してしまう可能性がある。そこで、シェーピングレートすべてを後段ノード２０で実行させるのでなく、前段ノード１０での送出レートをネゴシエーションし、前段ノード１０から折り合ったレートで送出する。

図１６は送出レートのネゴシエーションを示す図である。ノードＰＥ０（前段ノード１０）と、ノードＰ１（後段ノード２０）が接続し、ノードＰＥ０は、キューｑ１〜ｑ３を含み、ノードＰ１はキューｑ１１を含む。

ノードＰＥ０において、現在、キューｑ１では３Ｇｂｐｓのシェーピングを行い、キューｑ２では２Ｇｂｐｓのシェーピングを行い、キューｑ３では１Ｇｂｐｓのシェーピングを行っているとする。

このとき、キューｑ１の入力フロー（フローｆ１とする）が７Ｇｂｐｓとなって、キューｑ１のバッファリソースが枯渇しそうになった場合、以下に示すようなシーケンス制御が行われる。

〔Ｓ１〕ノードＰＥ０は、ノードＰ１に対して、フローｆ１のシェーピング依頼を行う。依頼内容としては、「ノードＰ１へ向けて、フローｆ１を７Ｇｂｐｓで送信すること」および「ノードＰ１において、７Ｇｂｐｓのフローｆ１を３Ｇｂｐｓに絞ってシェーピングしてもらうこと」であるとする。

〔Ｓ２〕ノードＰ１では、ノードＰＥ０以外のノードから送信されたフローも受信しているので、ノードＰＥ０から７Ｇｂｐｓのフローが送信されると、キューｑ１１でのキューイング許容力を超えると判断したとする。ノードＰ１では、７Ｇｂｐｓのフローの受信ができないことをノードＰＥ０へ通知する。

〔Ｓ３〕ノードＰＥ０は、ステップＳ１の依頼内容を変えて、「ノードＰ１へ向けて、フローｆ１を５Ｇｂｐｓで送信すること」および「ノードＰ１において、５Ｇｂｐｓのフローｆ１を３Ｇｂｐｓに絞ってシェーピングしてもらうこと」を依頼する。

〔Ｓ４〕ノードＰ１は、５Ｇｂｐｓのフローの受信が可能であり、かつ５Ｇｂｐｓのフローｆ１の３Ｇｂｐｓのシェーピングが可能であるとすると、ステップＳ３の依頼に対して了承の応答を返信する。

なお、図１７にシェーピングポイントが移行した場合の状態を示す。ノードＰ１では、キューｑ１１ａに５Ｇｂｐｓのフローｆ１をキューイングして、３Ｇｂｐｓのシェーピングを行って出力する。

このように、ノードＰＥ０では、シェーピングを依頼した際に、自ノードで全くシェーピングをしないのではなく、ノードＰ１でも輻輳せず、かつ自ノードでもバッファリソース枯渇が解消されるレートを、ノードＰ１とネゴシエーションする。そして、ネゴシエーションによってノードＰ１で了承されたレートで送出する。これにより、シェーピングを依頼した際に、ノードＰ１が輻輳してしまうことがなく、効率よくシェーピングポイントを移行することが可能になる。

次にキュー長（廃棄閾値）のネゴシエーションについて説明する。シェーピングの依頼時に、シェーピング対象のフローのキュー長（廃棄閾値）をネゴシエーションして、後段ノードのキューに対して、所定の廃棄閾値を設定させる。

図１８はキュー長のネゴシエーションを示す図である。図１６で示したノードＰＥ０のキューｑ１のキュー長が１００ＫＢ（キロバイト）であるとする。
〔Ｓ１１〕ノードＰＥ０は、図１６で上述したシェーピング依頼の内容（ノードＰ１において、５Ｇｂｐｓのフローｆ１を３Ｇｂｐｓに絞ってシェーピングしてもらう）に加えて、さらに自ノードと同じ１００ＫＢのキュー長（廃棄閾値）の設定を依頼する。

〔Ｓ１２〕ノードＰ１は、ステップＳ１１の依頼が可能である場合は、了承の旨の応答を返信する。
このように、シェーピング依頼時に、シェーピング対象のフローのキュー長をネゴシエーションし、自ノードＰＥ０と同一の廃棄閾値も合わせてノードＰ１側に持たせる構成とした。これにより、ノードＰ１側にノードＰＥ０と同じバースト耐性を持たせることが可能になる。なお、廃棄閾値の単位としては、「バイト長」または「パケット数」などがある。

次に後段ノードからのバッファリソース広報について説明する。図１９は後段ノードからのバッファリソース広報を示す図である。ネットワーク２−１は、ノードＰＥ０およびノードＰ１〜Ｐ３を含み、ノードＰＥ０とノードＰ１〜Ｐ３が接続し、ノードＰＥ０は、キューｑ１〜ｑ３を含む。

ノードＰ１〜Ｐ３は、自己のバッファリソースの情報をノードＰＥ０へ定期的に通知する。例えば、ノードＰ１は、現在のバッファの空きは５００Ｍバイトであることを通知する。また、ノードＰ２は、現在のバッファの空きは１Ｇバイトであることを通知し、ノードＰ３は、現在のバッファの空きは０バイトであることを通知する。

ノードＰＥ０は、これらのノードＰ１〜Ｐ３からのバッファリソース情報を受け取って、どの後段ノードならシェーピングが可能であるかを判断する。この例では、ノードＰ１に対して、キューｑ１のフローｆ１のシェーピングを依頼し、ノードＰ２に対して、キューｑ２のフローｆ２のシェーピングを依頼している。また、ノードＰ３には、バッファの空きがないので、ノードＰ３に対してはシェーピング依頼を行わない。

このように、定期的に後段ノードから前段ノードへバッファリソース情報を広報することにより、前段ノードでは、後段ノードの現在のバッファリソース状況を知ることができる。したがって、シェーピング可能な後段ノードに対してのみ、シェーピング依頼を送信することができるので、依頼はしてみたものの拒絶されるといったことがなくなり、効率よくシェーピング依頼を行うことが可能になる。

次にシェーピング依頼の解除について説明する。図２０はシェーピング依頼の解除を示す図である。上述したように、前段ノードから後段ノードへシェーピングを移行させることで、前段ノードではバッファリソースの枯渇が解消されてゆく。その場合には、元の前段ノード側にシェーピングポイントを戻す。

〔Ｓ２１〕シェーピングポイントの移行により、ノードＰＥ０のキューｑ１におけるフローｆ１のシェーピングが、ノードＰ１のキューｑ１１ａでシェーピングされている。また、ノードＰＥ０のキューｑ２におけるフローｆ２のシェーピングが、ノードＰ２のキューｑ２１ａでシェーピングされている。

〔Ｓ２２〕ノードＰＥ０のキューｑ１、ｑ２のバッファリソース枯渇が解消される。
〔Ｓ２３〕ノードＰＥ０は、キューｑ１、ｑ２によるシェーピングを再開する。
〔Ｓ２４〕ノードＰＥ０は、ノードＰ１、Ｐ２にシェーピング依頼解除を通知する。

〔Ｓ２５ａ〕ノードＰ１は、シェーピング依頼解除通知を受信すると、キューｑ１１ａが空になるまで待ち、空になったらフローｆ１のキューイング先をキューｑ１１へ切り替える。

〔Ｓ２５ｂ〕ノードＰ２は、シェーピング依頼解除通知を受信すると、キューｑ２１ａが空になるまで待ち、空になったらフローｆ２のキューイング先をキューｑ２１へ切り替える。

〔Ｓ２６ａ〕ノードＰ１は、解除完了通知をノードＰＥ０へ送信する。
〔Ｓ２６ｂ〕ノードＰ２は、解除完了通知をノードＰＥ０へ送信する。
このように、ノードＰＥ０でのバッファリソース枯渇が解消された場合には、シェーピング依頼解除をノードＰ１に通知して、ノードＰ１でのシェーピング実行を解除させる。これにより、元の通信状態にすみやかに戻って、通常の運用状態へ移行することができる。

ここで、ノードＰ１、Ｐ２において、シェーピング依頼解除のメッセージ受信直後に、シェーピングを行っているキューから、元のキューへ戻してしまうと、該フローの出力順序が逆転するおそれがある（シェーピングのために切り出したキューより、戻した後のキューから先にパケットが読み出されると、出力に順序逆転が生じる可能性がある）。

したがって、上記のように、ノードＰ１、Ｐ２では、シェーピング用に切り出したキューが空になってから、解除完了通知を返信する。なお、前段ノードでシェーピングを再開した際に、後段ノードでなかなかキューが空にならない場合は、後段ノードから前段ノードへバックプレッシャをかけて、後段ノードへの入力を一旦完全に停止させる構成にしてもよい。

次にシェーピング依頼のネゴシエーションを行う際のパケットフォーマットについて説明する。図２１はフォーマットの一例を示す図である。図では、Ethernet（登録商標）のフレーム上に実装した場合を示している。なお、IP（Internet Protocol）スタックやTCP／UDP（Transmission Control Protocol／User Datagram Protocol）スタック上に実装してもよい。

パケットは、６バイトのMAC−DA（Media Access Control−Destination Address：後段ノードアドレス）、６バイトのMAC−SA（MAC−Source Address：前段ノードアドレス）、２バイトのイーサーネットタイプおよび可変長のペイロードの各フィールドを備える。

ペイロードは、バージョン情報（Ver）、リクエストコード（Req Code）、リクエストＩＤ（Request ID）、メッセージ長（Length）のフィールドを備える。
リクエストコードは、例えば、0x01がRequest（依頼）、0x02がAck（了承）、0x03がNack（拒否）、0x04がInfo（情報通知）、0x05がRelease Request（解除通知）と設定する。

また、ペイロードは、TLV（Type／Length／Value）形式の各フィールドを備え、TypeとValueに関して、例えば、Type＝1は、ネットワークタイプであり、Value として、0x01をMPLS−VPN（L3）とし、0x02をMPLS−VPN（L2）とし、0x03をPBB−TE（Provider Backbone Bridge−Traffic Engineering）として設定する。

Type＝2は、フロー識別子であり、Valueには、TunnelラベルおよびPWラベルの値を設定する。Type＝3は、シェーピングレートであり、Valueには、シェーピングレートの値（bps）を設定する。Type＝4は、フロー送出レートであり、Valueには、フロー送出レートの値（bps）を設定する。

Type＝5は、キュー長（廃棄閾値）であり、Valueには、廃棄閾値（byte）を設定する。Type＝6は、キュー長（リソース）であり、Valueには、キュー長リソースの値（byte）を設定する。

次に上記の図２１で示したフォーマットを用いてネゴシエーションする場合のシーケンス例について図２２〜図２４を用いて説明する。
図２２はシェーピング依頼を行う際のシーケンスを示す図である。ノードＰＥ０からノードＰ１に対し、Tunnelラベル＝T01、PWラベル＝PWaのフローについて、シェーピングレート＝１００Ｍｂｐｓ、送信レート＝１Ｇｂｐｓ、キュー長＝１００ＫＢで依頼した場合の例を示している。

〔Ｓ３１〕ノードＰＥ０は、ノードＰ１に対して、シェーピングの依頼メッセージＭ１を送信する。シェーピング依頼動作に関連する、依頼メッセージＭ１の各フィールドの値を以下に示す。

Req Code＝0x01（依頼：Request）、Request ID＝0x01、Type＝1のValue＝0x02（ネットワークタイプがMPLS−VPN（L2））、Type＝2のValueは、Flow ID＃1＝T01、Flow ID＃2＝PWa、Type＝3のValue＝100Mbps（シェーピングレート＝100Mbps）、Type＝4のValue＝1Gbps（送出レート＝1Gbps）、Type＝5のValue＝100KB（キュー長（廃棄閾値）＝100KB）と設定されている。

〔Ｓ３２〕ノードＰ１は、ステップＳ３１の条件のシェーピングを拒否するとして、拒否メッセージＭ２を返信する。シェーピング拒否動作に関連する、拒否メッセージＭ２の各フィールドの値を以下に示す。

Req Code＝0x03（Nack：拒否）、Request ID＝0x01、Type＝4のValue＝1Gbps（送出レート＝1Gbps）と設定されている。ノードＰＥ０から１Ｇｂｐｓで送られることは拒否している。

〔Ｓ３３〕ノードＰＥ０は、５００Ｍｂｐｓでの送信レートに切り替えて再度依頼メッセージＭ１ａを送信する。依頼メッセージＭ１ａの各フィールドの値は、Req Code＝0x01（依頼：Request）、Request ID＝0x01、Type＝4のValue＝500Mbps（送出レート＝500Mbps）と設定されている。ここで、Ｍ１ａには送信レート以外は（了承済として）依頼メッセージには含めていないが、他のパラメータも再依頼に含めてもよい。なお、依頼メッセージＭ１とＭ１ａは、Request IDが同一であることから、ノードＰ１は、Ｍ１ａがＭ１の再依頼であるということが判る。

〔Ｓ３４〕ノードＰ１は、ステップＳ３３の条件を了承したとして、了承メッセージＭ２ａを返信する。了承メッセージＭ２ａの各フィールドの値は、Req Code＝0x02（了承：Ack）、Request ID＝0x01と設定される。

図２３はバッファリソース広報を行う際のシーケンスを示す図である。コアノードから送信元ノードへバッファリソースの情報を定期的に広報している例を示している。この場合は、Req Code＝0x04（情報通知）をセットし、キュー長（リソース）の情報を送信元ノードへ通知している。なお、定期的に広報するたびにRequest IDはカウントアップして通知する。

〔Ｓ４１〕ノードＰ１は、ノードＰＥ０に対して、バッファリソース情報メッセージＭ１１−１を広報する。バッファリソース情報メッセージＭ１１−１の各フィールドの値は、Req Code＝0x04（情報通知：Info）、Request ID＝0x01、Type＝6のValue＝1GB（キュー長（リソース）＝1GB）と設定されている。

〔Ｓ４２〕ノードＰ１は、ノードＰＥ０に対して、バッファリソース情報メッセージＭ１１−２を広報する。バッファリソース情報メッセージＭ１１−２の各フィールドの値は、Req Code＝0x04（情報通知：Info）、Request ID＝0x02、Type＝6のValue＝800MB（キュー長（リソース）＝800MB）と設定されている。

〔Ｓ４３〕ノードＰ１は、ノードＰＥ０に対して、バッファリソース情報メッセージＭ１１−３を広報する。バッファリソース情報メッセージＭ１１−３の各フィールドの値は、Req Code＝0x04（情報通知：Info）、Request ID＝0x03、Type＝6のValue＝600B（キュー長（リソース）＝600B）と設定されている。

〔Ｓ４４〕ノードＰ１は、ノードＰＥ０に対して、バッファリソース情報メッセージＭ１１−４を広報する。バッファリソース情報メッセージＭ１１−４の各フィールドの値は、Req Code＝0x04（情報通知：Info）、Request ID＝0x04、Type＝6のValue＝900MB（キュー長（リソース）＝900MB）と設定されている。

図２４はシェーピング依頼解除を行う際のシーケンスを示す図である。ノードＰＥ０からノードＰ１に対し、シェーピング解除を通知している例を示している。ノードＰＥ０は、Req Code＝0x05（解除通知）をセットし、TLVのフィールドにシェーピングを依頼した各パラメータをセットして、ノードＰ１へ送信する。そして、ノードＰ１は、キュー構成等を元に戻した後に、Req Code=0x02（了承）を返信する。

〔Ｓ５１〕ノードＰＥ０は、ノードＰ１に対して、シェーピングの解除メッセージＭ３を送信する。シェーピング解除動作に関連する、解除メッセージＭ３の各フィールドの値を以下に示す。

Req Code＝0x05（解除通知：Release Request）、Request ID＝0x100、Type＝1のValue＝0x02（ネットワークタイプがMPLS−VPN（L2））、Type＝2のValueは、Flow ID＃1＝T01、Flow ID＃2＝PWa、Type＝3のValue＝100Mbps（シェーピングレート＝100Mbps）、Type＝4のValue＝500Mbps（送出レート＝500Mbps）、Type＝5のValue＝100KB（キュー長（廃棄閾値）＝100KB）と設定されている。

〔Ｓ５２〕ノードＰ１は、キュー構成等を元に戻す。
〔Ｓ５３〕ノードＰ１は、シェーピング解除完了メッセージＭ３ａを返信する。シェーピング解除完了に関連する、解除完了メッセージＭ３ａの各フィールドの値は、Req Code＝0x02（了承：Ack）、Request ID＝0x100と設定されている。

次に余剰帯域を利用した送出レートの設定について説明する。前段ノードと後段ノードとの間の物理リンク帯域の余剰帯域を利用して、最大送出レートを設定する。最大送出レートは、
（最大送出レート）＝（余剰帯域）＋（依頼フローのシェーピングレート）
となる。ただし、（余剰帯域）＝（物理リンク帯域）−（シェーピングレートの総和）である。

図２５は最大送出レートでのシェーピング依頼を示す図である。ノードＰＥ０とノードＰ１とを結ぶリンクの物理帯域を１０Ｇｂｐｓとする。また、ノードＰＥ０のキューｑ１のシェーピングレートが３Ｇｂｐｓ、キューｑ２のシェーピングレートが２Ｇｂｐｓ、キューｑ３のシェーピングレートが１Ｇｂｐｓとする。

キューｑ１に関するシェーピング依頼を行う場合、最大送出レートは、物理リンク帯域（10G）−シェーピングレートの総和（3G+2G+1G）＋キューｑ１のシェーピングレート（3G）＝７Ｇｂｐｓとなる。

〔Ｓ６１〕ノードＰＥ０は、ノードＰ１に対して、フローｆ１のシェーピング依頼を行う。依頼の内容としては、「ノードＰ１へ向けて、フローｆ１を最大送出レートの７Ｇｂｐｓで送信すること」および「ノードＰ１において、７Ｇｂｐｓのフローｆ１を３Ｇｂｐｓに絞ってシェーピングしてもらうこと」であるとする。

〔Ｓ６２〕ノードＰ１では、ノードＰＥ０以外のノードから送信されたフローも受信しているので、ノードＰ１から７Ｇｂｐｓのフローが送信されると、キューｑ１１でのキューイング許容力を超えると判断したとする。ノードＰ１では、７Ｇｂｐｓのフローの受信ができないことをノードＰＥ０へ通知する。

〔Ｓ６３〕ノードＰＥ０は、ステップＳ６１の依頼内容を変えて、「ノードＰ１へ向けて、フローｆ１を５Ｇｂｐｓで送信すること」および「ノードＰ１において、５Ｇｂｐｓのフローｆ１を３Ｇｂｐｓに絞ってシェーピングしてもらうこと」を依頼する。

〔Ｓ６４〕ノードＰ１は、５Ｇｂｐｓのフローの受信が可能であり、かつ５Ｇｂｐｓのフローｆ１の３Ｇｂｐｓのシェーピングが可能であるとすると、ステップＳ６３の依頼に対してシェーピングが了承である旨の応答を返信する。

このように、前段ノードで最大送出レートを算出し、シェーピング対象フローを最大送出レートで送信可能か否かのネゴシエーションを行う。最大送出レートでの送信が可能であるならば、ノード間を結ぶリンク帯域を有効に活用することができ、前段ノード側のバッファリソース枯渇を高速に解消することが可能になる。

次に予備パスを利用したシェーピング依頼について説明する。図２６は予備パスを利用したシェーピング依頼を示す図である。ノードＰＥ０とノードＰ１とが現用パス（ACT）と予備パス（SBY）とで接続された冗長構成を有している（例えば、1：1 Link AggregationやMPLS FRR（Fast ReRoute）など）。

この場合、ノードＰＥ０からノードＰ１に対して、キューｑ１のフローｆ１のシェーピングを依頼して了承された場合、ノードＰＥ０は、フローｆ１を予備パスを通じて、ノードＰ１へ送信する。予備パスが通常運用時には使用されないような完全予備系のパスであるならば、最大送出レートは、予備パスの物理リンクレートとなる。

このように、予備パスの帯域を有効に活用することにより、ノードＰＥ０側のバッファリソース枯渇を高速に解消することが可能になる。
以上説明したように、限られたバッファ資源の中で、シェーピング（キューイング）のポイントを動的に移行することにより、キュー輻輳耐力を向上させ、トラフィック輻輳時の廃棄率を改善して、通信品質の向上を図ることが可能になる。

なお、上記では、パケットを送受信する通信システムについて説明したが、パケットの代わりにセルやフレーム等で送受信するシステムに関しても、本技術を同様に適用することが可能である。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。

１ 通信システム
１ａ、２ａ 伝送装置
１１ バッファ

Claims (10)

1. パケットを格納するバッファから、前記パケットを所定レートで読み出してシェーピングを行う第１の伝送装置と、
   前記第１の伝送装置から送信された前記パケットを受信して中継する第２の伝送装置と、
   を備え、
   前記第１の伝送装置は、前記バッファのリソース状況に応じて、前記シェーピングを前記第２の伝送装置へ依頼し、前記第２の伝送装置は、前記第１の伝送装置に代わって前記シェーピングを実行する、
   ことを特徴とする通信システム。
2. 前記第２の伝送装置で前記シェーピングを実行する際のシェーピングレートは、前記第１の伝送装置と前記第２の伝送装置との間でネゴシエーションを行い、前記第２の伝送装置は、自己が了承した前記シェーピングレートで前記シェーピングを実行することを特徴とする請求項１記載の通信システム。
3. シェーピング依頼の対象となる前記パケットの送信レートは、前記第１の伝送装置と前記第２の伝送装置との間でネゴシエーションを行い、
   前記第１の伝送装置は、前記第２の伝送装置が了承した前記送信レートで前記パケットを送信することを特徴とする請求項１記載の通信システム。
4. シェーピング依頼の対象となる前記パケットの廃棄閾値は、前記第１の伝送装置と前記第２の伝送装置との間でネゴシエーションを行い、
   前記第２の伝送装置は、自己が了承した前記廃棄閾値で前記シェーピングを実行することを特徴とする請求項１記載の通信システム。
5. 前記第１の伝送装置に複数の前記第２の伝送装置が接続し、複数の前記第２の伝送装置それぞれは、自己のバッファのリソース状況を前記第１の伝送装置へ通知し、
   前記第１の伝送装置は、通知された個々のリソース状況にもとづいて、前記シェーピングを依頼すべき前記第２の伝送装置を選択することを特徴とする請求項１記載の通信システム。
6. 前記第１の伝送装置は、自己の前記バッファのリソース不足が解消された場合には、前記シェーピングの依頼を解除することを特徴とする請求項１記載の通信システム。
7. 前記第１の伝送装置は、前記第２の伝送装置との間の物理リンク帯域の余剰帯域と、依頼した前記シェーピングのレートと、を加算した送信レートで、前記パケットを送信することを特徴とする請求項１記載の通信システム。
8. 前記第１の伝送装置と前記第２の伝送装置とは冗長構成で接続し、前記第１の伝送装置は、前記第２の伝送装置との間の冗長パスから、シェーピング対象の前記パスを送信することを特徴とする請求項１記載の通信システム。
9. パケットを格納するバッファと、
   前記パケットを前記バッファから所定レートで読み出してシェーピングを行うシェーピング制御部と、
   を備え、
   前記シェーピング制御部は、前記バッファのリソース状況に応じて、前記シェーピングを他装置へ依頼して、自装置に代わって前記シェーピングを前記他装置側で実行させる、
   ことを特徴とする伝送装置。
10. パケットを格納するバッファと、
    前記バッファから前記パケットを読み出して出力する読み出し制御部と、
    を備え、
    前記読み出し制御部は、他装置からシェーピングの依頼を受けた場合に、シェーピング対象のパケットを格納する別バッファを前記バッファから割り当てて、前記別バッファからシェーピング対象のパケットを読み出して、前記他装置に代わって前記シェーピングを実行する、
    ことを特徴とする伝送装置。

Images