パケットを格納するバッファから、前記パケットを所定レートで読み出してシェーピングを行う第1の伝送装置と、前記第1の伝送装置から送信された前記パケットを受信して中継する第2の伝送装置と、を備え、前記第1の伝送装置は、前記バッファのリソース状況に応じて、前記シェーピングを前記第2の伝送装置へ依頼し、前記第2の伝送装置は、前記第1の伝送装置に代わって前記シェーピングを実行する、ことを特徴とする通信システム。前記第2の伝送装置で前記シェーピングを実行する際のシェーピングレートは、前記第1の伝送装置と前記第2の伝送装置との間でネゴシエーションを行い、前記第2の伝送装置は、自己が了承した前記シェーピングレートで前記シェーピングを実行することを特徴とする請求項1記載の通信システム。シェーピング依頼の対象となる前記パケットの送信レートは、前記第1の伝送装置と前記第2の伝送装置との間でネゴシエーションを行い、前記第1の伝送装置は、前記第2の伝送装置が了承した前記送信レートで前記パケットを送信することを特徴とする請求項1記載の通信システム。シェーピング依頼の対象となる前記パケットの廃棄閾値は、前記第1の伝送装置と前記第2の伝送装置との間でネゴシエーションを行い、前記第2の伝送装置は、自己が了承した前記廃棄閾値で前記シェーピングを実行することを特徴とする請求項1記載の通信システム。前記第1の伝送装置に複数の前記第2の伝送装置が接続し、複数の前記第2の伝送装置それぞれは、自己のバッファのリソース状況を前記第1の伝送装置へ通知し、前記第1の伝送装置は、通知された個々のリソース状況にもとづいて、前記シェーピングを依頼すべき前記第2の伝送装置を選択することを特徴とする請求項1記載の通信システム。前記第1の伝送装置は、自己の前記バッファのリソース不足が解消された場合には、前記シェーピングの依頼を解除することを特徴とする請求項1記載の通信システム。前記第1の伝送装置は、前記第2の伝送装置との間の物理リンク帯域の余剰帯域と、依頼した前記シェーピングのレートと、を加算した送信レートで、前記パケットを送信することを特徴とする請求項1記載の通信システム。前記第1の伝送装置と前記第2の伝送装置とは冗長構成で接続し、前記第1の伝送装置は、前記第2の伝送装置との間の冗長パスから、シェーピング対象の前記パスを送信することを特徴とする請求項1記載の通信システム。パケットを格納するバッファと、前記パケットを前記バッファから所定レートで読み出してシェーピングを行うシェーピング制御部と、を備え、前記シェーピング制御部は、前記バッファのリソース状況に応じて、前記シェーピングを他装置へ依頼して、自装置に代わって前記シェーピングを前記他装置側で実行させる、ことを特徴とする伝送装置。パケットを格納するバッファと、前記バッファから前記パケットを読み出して出力する読み出し制御部と、を備え、前記読み出し制御部は、他装置からシェーピングの依頼を受けた場合に、シェーピング対象のパケットを格納する別バッファを前記バッファから割り当てて、前記別バッファからシェーピング対象のパケットを読み出して、前記他装置に代わって前記シェーピングを実行する、ことを特徴とする伝送装置。共通バッファ方式では、統計多重効果を計るべく、共通バッファのバッファサイズよりも、各個別キューにおける廃棄閾値までのバッファサイズの合計の方が大きくなるように設計される。しかし、あるキューがバースト的に共通バッファのバッファスペースを占有した場合、他のキューでは、共通バッファのリソース枯渇に伴って、共通バッファからスペースを確保できなくなる。すると、該キューでは、廃棄閾値に達していないにもかかわらず、パケット廃棄が行われてしまう。このように、共通バッファ方式のような限られたバッファ資源の中では、キュー間での干渉が発生し、キューの輻輳耐力が低下する。このため、パケットの廃棄率が上昇してしまい、通信品質を劣化するといった問題があった。本発明はこのような点に鑑みてなされたものであり、パケットの廃棄率を低減して、通信品質の向上を図った通信システムを提供することを目的とする。また、本発明の他の目的は、パケットの廃棄率を低減して、通信品質の向上を図った伝送装置を提供することを目的とする。上記課題を解決するために、通信システムが提供される。通信システムは、パケットを格納するバッファから、前記パケットを所定レートで読み出してシェーピングを行う第1の伝送装置と、前記第1の伝送装置から送信された前記パケットを受信して中継する第2の伝送装置とを備える。前記第1の伝送装置は、前記バッファのリソース状況に応じて、前記シェーピングを前記第2の伝送装置へ依頼し、前記第2の伝送装置は、前記第1の伝送装置に代わって前記シェーピングを実行する。廃棄率を低減して通信品質の向上を図ることが可能になる。以下、本発明の実施の形態を図面を参照して説明する。図1は通信システムの構成例を示す図である。通信システム1は、伝送装置1a第1の伝送装置と伝送装置2a第2の伝送装置を備える。伝送装置1aは、パケットを格納するバッファ11を有し、バッファ11から、パケットを所定レートで読み出してシェーピングを行う。また、伝送装置2aは、伝送装置1aから送信されたパケットを受信して中継する。ここで、伝送装置1aは、バッファ11のリソース状況に応じて、シェーピングを伝送装置2aへ依頼し、伝送装置2aは、伝送装置1aに代わってシェーピングを実行する。このように、通信システム1では、伝送装置1aのバッファ11のリソース状況に応じて、伝送装置1aから伝送装置2aへ、シェーピングポイントを動的に移行する構成とした。これにより、伝送装置1aのバッファ11のリソース枯渇容量不足が生じたような場合でも、伝送装置2a側でシェーピングが行われることにより、バッファ11のリソース枯渇状態をすみやかに解消させることができ、パケットの廃棄率を低減させて、通信品質の向上を図ることが可能になる。次に一般的な共通バッファ方式について図2を用いて説明する。図2は共通バッファ方式を説明するための図である。個別キューq1~q4はそれぞれ、あらかじめ設けた固定的な個別バッファスペースを有しており、必要に応じて共通バッファからスペースを確保して、パケットのキューイングを行う。なお、個別キューq1~q4の廃棄閾値までのバッファスペースの合計は、共通バッファスペースよりも大きい。到着したパケットは、個別キューq1~q4にキューイングされる。今、個別キューq1~q3では、個別バッファスペースを超えて、さらに共通バッファスペースを確保して、それぞれの廃棄閾値まで到着パケットをキューイングしているとする。このとき、個別キューq1~q3によって、共通バッファスペースが占有されたとすると、個別キューq4では、まだ廃棄閾値に達していなくても、共通バッファスペースの枯渇により、パケットを廃棄してしまうことになる。このように、共通バッファ方式では、キュー間での干渉が発生して、キューの輻輳耐力が低下し、パケット廃棄率が増加してしまう。一方、キュー長が廃棄閾値を超過した、または超過しそうな場合には、パケットの入力元に対してバックプレッシャBackPressureをかけて、キューへの入力を制限する場合がある。しかし、すでにキューに滞留してしまったパケットは、例えば、入力>>>出力のような場合には、キュー枯渇の解消すなわち枯渇が解消するまでパケットが読み出されるまでには非常に長い時間を要し、また、パケット入力元の機器がバックプレッシャによって制御できる機能を有しているとは限らない例えば、顧客の機器など。なお、共通バッファ方式を例にして説明したが、上記の問題は、共通バッファ方式に限定されるものではなく、限られたバッファ資源の中でのシェーピングキューイングに関して生じるものである。本技術はこのような点に鑑みてなされたものであり、限られたバッファ資源の中でのシェーピングキューイングに対して、パケット廃棄率を低減し、通信品質の向上を図った通信システムおよび伝送装置を提供するものである。次に通信システム1が適用されるネットワークの一例について説明する。図3はネットワークの構成例を示す図である。通信システム1が適用されるネットワークの例としてMPLS-VPNMultiprotocolLabelSwitching-VirtualPrivateNetworkのネットワーク2を考える。ネットワーク2は、送信元エッジノードPE0PE:ProviderEdge、宛先エッジノードPE5およびコアノードP1~P4を含む。送信元エッジノードPE0には、ユーザ端末a、bが接続し、また、コアノードP1、P2が接続する。宛先エッジノードPE5には、ユーザ端末c、dが接続し、また、コアノードP3、P4が接続する。コアノードP1~P4は、メッシュ状に接続する。送信元エッジノードPE0では、ユーザVPNを識別するためのPWラベルPseudoWireLabelと、宛先エッジノードPE5を識別するためのTunnelラベルとをパケットに付与して転送する。例えば、ユーザ端末aは、パケットp1に対して、TunnelラベルとしてT01と、PWラベルとしてPWaとを付与して、パケットp1-1を生成して転送する。なお、PWxは、VPNxを示すユーザ識別ラベルである。したがって、PWaは、VPNaであり、この例では、VPNa内のユーザ端末aから転送されたパケットであることを示す。また、Tx1x2は、x1からx2へ転送することを示す。したがって、T01は、ノード0送信元エッジノードPE0からノード1コアノードP1への転送を示す。以下、同様の見方である。ユーザ端末bは、パケットp2に対して、TunnelラベルとしてT01と、PWラベルとしてPWbとを付与して、パケットp2-1を生成して転送する。パケットp1-1、p2-1は、コアノードP1に到着する。コアノードP1では、パケットに付与されているラベルのうち、Tunnelラベルのみを参照し、あらかじめシグナリングされたラベルテーブルからラベルスワップする。例えば、コアノードP1は、パケットp1-1、p2-1のTunnelラベルT01をT13に変換して、パケットp1-2、p2-2を生成して、後段のコアノードP3へ転送する。同様に、パケットp1-2、p2-2を受信したコアノードP3は、付与されたラベルのうち、Tunnelラベルのみを参照し、あらかじめシグナリングされたラベルテーブルからラベルスワップする。例えば、コアノードP3は、パケットp1-2、p2-2のTunnelラベルT13をT35に変換して、パケットp1-3、p2-3を生成して、後段の宛先エッジノードPE5へ転送する。宛先エッジノードPE5では、PWラベルを参照してTunnelラベルは1つ手前のコアノード3、4であらかじめ取り外されて転送される場合もある、VPNを識別して、ユーザ端末c、dそれぞれに転送する。ここで、Tunnelラベルのシグナリングは、LDPLabelDistributionProtocol:RFC3036やRSVP-TEResourceReservationProtocol-TrafficEngineering:RFC3209などの公知のプロトコルを用いて実施される。また、コアノードP1~P4は、ラベルテーブルを個々に有して、ラベルテーブルの登録内容に従って、パケットをラベルスワップしながら転送する。なお、RSVP-TEを用いた場合、ラベルシグナリングと合わせて帯域リソースの予約を行うことも可能である。このとき、コアノードP1~P4は、物理帯域を超過しないようにリソースの予約が行われるため、コアノードP1~P4は、定常的には非輻輳の状態となる。したがって、ユーザのトラフィックは、送信元エッジノードPE0で契約に応じてシェーピングされた後は、従来のコアノードP1~P4ではシェーピングキューイングされることなく、宛先エッジノードPE5まで転送される。次に通信システム1の動作例について図4、図5を用いて説明する。通信システム1では、前段ノード伝送装置1aにおけるシェーピング時に、バッファリソースの枯渇が生じるような場合には、後段ノード伝送装置2aにシェーピングを依頼して、前段ノードの代わりに後段ノードにおいてシェーピングを実行させて、キュー輻輳時の廃棄率を低減させる。図4、図5は通信システム1の動作例を説明するための図である。図4は後段ノードへのシェーピングの依頼を示し、図5は後段ノードでのシェーピングの実行を示している。ネットワーク2-1MPLS-VPNは、送信元エッジノードPE0およびコアノードP1~P3を含み、送信元エッジノードPE0は、コアノードP1~P3と接続する。送信元エッジノードPE0は、キューq1~q3を備え、コアノードP1~P3はそれぞれ、キューq11、q21、q31を備える本技術で適用するキューは論理キューである。なお、キューの出力側に示される図中の丸印内のSは、該キューがシェーピングを行っていることを示す。図4において、送信元エッジノードPE0で契約帯域にもとづくレートでシェーピングを実行しようとしたときに、キューq1~q3のバッファスペースが枯渇しそうになったとする。この場合、送信元エッジノードPE0では、後段のコアノードP1~P3に対して、所定レートでのシェーピングの依頼を行う。例えば、送信元エッジノードPE0は、コアノードP1に対して、TunnelラベルがT01、PWラベルがPWaのフローの100Mbpsのシェーピングの依頼メッセージR1を送信する。また、コアノードP2に対して、TunnelラベルがT02、PWラベルがPWbのフローの50Mbpsのシェーピングの依頼メッセージR2を送信する。さらに、コアノードP3に対して、TunnelラベルがT03、PWラベルがPWcのフローの200Mbpsのシェーピングの依頼メッセージR3を送信する。そして、上記レートでのシェーピングが可能であるならば、該当のコアノードで、シェーピングを実行する。コアノードP1、P2では、依頼されたレートでシェーピングを行う際のバッファリソースに余裕があり、コアノードP3では余裕がないとすると、コアノードP1、P2は依頼を了承し、コアノードP3は、依頼を拒否する。図5において、コアノードP1、P2は、依頼されたシェーピングを実行する。この場合、コアノードP1では、既存のキューq11から、依頼されたレートでのシェーピングを行うための別キューq11aを割り当てて切り出して、別キューq11aにて100Mbpsのシェーピングを行う。また、コアノードP2では、既存のキューq21から、依頼されたレートでのシェーピングを行うための別キューq21aを切り出して、別キューq21aにて50Mbpsのシェーピングを行う。コアノードP3に依頼したシェーピングは拒否されたので、コアノードP1、P2において、依頼したシェーピングが行われる。このため、送信元エッジノードPE0では、バッファリソースの枯渇が徐々に解消されて、リソースに余裕ができる。このため、コアノードP3に依頼したT03/PWcのフローの200Mbpsのシェーピングを、自ノードPE0で実行することが可能となる。以上説明したように、送信元エッジノードにおいて、シェーピング時にバッファリソースが枯渇または枯渇しそうになった場合は、後段のコアノードがエッジノードに代わってシェーピングを実行するという動作を行う。すなわち、バッファのリソース資源の状況に応じて、シェーピングキューイングのポイントを動的に移す。後段のコアノードでは、バッファリソースに余裕があり、送信元エッジノードの代わりにシェーピングが可能であるならば、依頼を受託し、該フローについて、シェーピングを実行する。これにより、送信元エッジノードは、滞留パケットが読み出されるので、次第にバッファ枯渇が解消してゆく。その後、バッファリソースの枯渇が解消した場合には、シェーピング依頼を解除して、送信元エッジノードおよびコアノードそれぞれが、依頼前の元のシェーピング状態またはキューイング状態に戻る。このように、例えば、バースト的なトラフィック入力レート>>出力レートによりバッファが占有されて枯渇状態となったような場合、該エッジノードから後段のコアノードに対して、輻輳キュー長が廃棄閾値を超過しているフローのシェーピングの移行肩代わりを依頼する。ただし、一方的にシェーピングを押し付けると、バッファ枯渇のポイントが後段側に単に移動するだけになる。このため、対象フローMPLS-VPNの場合は、PWラベルとTunnelラベルによりフロー識別されると、シェーピングレートとともにネゴシエーションを行って、了承された場合にのみシェーピングの移行を行う。そして、後段ノードでは、エッジノードからシェーピングの移行を依頼されて、バッファリソースに余裕がない場合は、依頼を拒否するネゴシエーションの動作例については後述する。次に通信システム1が備える前段ノードおよび後段ノードの構成について説明する。図6は前段ノードの構成例を示す図である。前段ノード10は、図1の伝送装置1aおよび図3~図5の送信元エッジノードPE0に対応する。前段ノード10は、後段ノード20と接続し、バッファ11と、パケットをバッファ11から所定レートで読み出してシェーピングを行うシェーピング制御部12とを備える。バッファ11は、パケットをバッファリングする。シェーピング制御部12は、バッファ11のリソース状況に応じて、シェーピングを他ノードへ依頼して、自ノードに代わってシェーピングを他ノード側で実行させる。シェーピング制御部12は、キュー管理部12a、パスデータベースパスDB12b、シェーピング管理部12cおよびCPUCentralProcessingUnit部12dを含む。キュー管理部12aは、バッファ11のリソースを管理し、キュー長の監視管理を行う。パスデータベース12bは、パスのフロー情報を格納管理する。シェーピング管理部12cは、該当キューに対してシェーピングレートの設定変更を行う。CPU部12dは、プロセッサ、メモリおよびI/F等を有して、各構成要素に対する全体制御および所定の制御を実行させるための指示を行い、また、他ノードとの通信を行う。図7は後段ノードの構成例を示す図である。後段ノード20は、図1の伝送装置2aおよび図3~図5のコアノードに対応する。後段ノード20は、前段ノード10と接続し、バッファ21およびバッファ21からパケットを読み出して出力する読み出し制御部22を備える。バッファ21は、パケットをバッファリングする。読み出し制御部22は、他ノードからシェーピングの依頼を受けた場合に、シェーピング対象のパケットを格納する別バッファをバッファ21から割り当てて、別バッファからシェーピング対象のパケットを読み出し、他ノードに代わってシェーピングを実行する。読み出し制御部22は、フロー識別部22a、パスデータベース22b、キュー管理部22c、シェーピング管理部22dおよびCPU部22eを含む。フロー識別部22aは、到着パケットのフロー識別を行う。パスデータベース22bは、パスのフロー情報を格納管理する。キュー管理部22cは、バッファ21のリソースを管理し、キュー長の監視管理およびキューの設定変更を行う。シェーピング管理部22dは、該当キューに対してシェーピングレートの設定変更を行う。CPU部22eは、プロセッサ、メモリおよびI/F等を有して、各構成要素に対する全体制御および所定の制御を実行させるための指示を行い、また、他ノードとの通信を行う。次に前段ノード10から後段ノード20へのシェーピング依頼時の動作についてフローチャートで説明する。図8はシェーピング依頼時の前段ノードの動作を示すフローチャートである。S1aCPU部12dは、キュー管理部12aに対して、バッファ11のリソース監視を指示し、キュー管理部12aは、指示にもとづいて、バッファリソース監視を行う。S2aCPU部12dは、リソース監視結果から、現在のキューイングにおいて、キューの廃棄閾値を超過するか否かを判断する。超過する場合は、ステップS3aへ行き、超過しない場合は終了する。S3aCPU部12dは、廃棄閾値を超えるおそれのあるフローを認識し、パスデータベース12bからフロー情報を抽出する。S4aCPU部12dは、後段ノード20へシェーピングの実行依頼を送信する。S5aCPU部12dは、シェーピング依頼が了承されたか否かを認識する。了承された場合はステップS6aへ行き、了承されない場合はステップS4aへ戻るなお、シェーピング依頼を複数回送信しても、後段ノード20から了承をとれない場合は終了する。S6aCPU部12dは、シェーピング管理部12cへ該フローのシェーピングレート設定の変更を指示し、シェーピング管理部12cは、指示にもとづきシェーピングのレートを変更する。図9はシェーピング依頼時の後段ノードの動作を示すフローチャートである。S1bCPU部22eは、前段ノード10からシェーピング依頼を受信する。S2bCPU部22eは、キュー管理部22cに対してバッファ21のリソースチェックを指示し、キュー管理部22cは、指示にもとづいて、バッファリソースチェックを行う。S3bCPU部22eは、リソースチェック結果から、バッファリソースに余裕があるか否かを判断する。余裕があればステップS5bへ行き、なければステップS4bへいく。S4bCPU部22eは、前段ノード10に対して、依頼拒否のメッセージを送信する。S5bCPU部22eは、フロー識別部22aにフロー識別設定の変更を指示し、フロー識別部22aは、指示にもとづいて、シェーピング対象フローに対するフロー識別設定の変更を行う。S6bCPU部22eは、キュー管理部22cに対して、キュー設定変更指示を行い、キュー管理部22cは、指示にもとづき、シェーピング対象フロー用のキューを設定する。S7bCPU部22eは、シェーピング管理部22dにシェーピング設定を指示し、シェーピング管理部22dは、依頼されたシェーピング設定を行う。S8bCPU部22eは、前段ノード10に対して、シェーピングの依頼を了承した旨のメッセージを返信する。次にシェーピング依頼の解除動作についてフローチャートで説明する。図10はシェーピング依頼解除時の前段ノードの動作を示すフローチャートである。S11aCPU部12dは、キュー管理部12aに対して、バッファ11のリソース監視を指示し、キュー管理部12aは、指示にもとづいて、バッファリソース監視を行う。S12aCPU部12dは、監視結果からキューの廃棄閾値超過が解消したか否かを判断する。解消した場合は、ステップS13aへ行き、解消しない場合は終了する。S13aCPU部12dは、シェーピング管理部12cに対して、シェーピング設定を元に戻す指示を行い、シェーピング管理部12cは、該フローのシェーピング設定を元に戻す。S14aCPU部12dは、後段ノード20に対して、シェーピング依頼解除メッセージを送信する。S15aCPU部12dは、後段ノード20から返信されるシェーピング解除完了メッセージの受信待ちを行い、シェーピング解除完了メッセージを受信した場合は終了する。図11はシェーピング依頼解除時の後段ノードの動作を示すフローチャートである。S11bCPU部22eは、前段ノード10からシェーピング依頼解除メッセージを受信する。S12bCPU部22eは、キュー管理部22cに対して、該フローのキュー長チェックを指示し、キュー管理部22cは、指示にもとづいて、該フローのキュー長チェックを行う。S13bCPU部22eは、チェック結果から、該キューが空になったか否かを確認する。空になった場合はステップS14bへ行き、空でなければステップS12bへ戻って空になるまで待つ。S14bCPU部22eは、フロー識別部22aにフロー識別設定の変更を元に戻す指示を行い、フロー識別部22aは、指示にもとづいて、フロー識別設定の変更を元に戻す。S15bCPU部22eは、キュー管理部22cに対して、キュー設定を元に戻す指示を行い、キュー管理部22cは、指示にもとづき、キュー設定を元に戻す。S16bCPU部22eは、前段ノード10に対して、シェーピング解除完了メッセージを送信する。次に前段ノード10におけるシェーピング依頼前と依頼後のフロー処理について説明する。図12は前段ノードにおけるシェーピング依頼前のフロー処理を示す図である。前段ノード10では、入力ポートやVLANなどから、入力したパケットp1~p3のフローを識別する。例えば、パケットp1のフローがVPNaであり、パケットp2のフローがVPNbであり、パケットp3のフローがVPNcであるとして、それぞれのフローを識別する。また、キューq1~q3がそれぞれ、VPNa~VPNcのフローに対応しているとすると、VPNaのフローのパケットp1をキューq1にキューイングし、設定されたレート例えば、100Mbpsとするでシェーピングする。同様に、VPNbのフローのパケットp2をキューq2にキューイングし、100Mbpsでシェーピングし、VPNcのフローのパケットp3をキューq3にキューイングし、100Mbpsでシェーピングする。なお、キューq1から出力するパケットについては、ラベルテーブルにしたがって、TunnelラベルであるT01と、PWラベルであるPWaとを付与して、パケットp1-1を生成して出力する。また、キューq2から出力するパケットについては、TunnelラベルであるT01と、PWラベルであるPWbとを付与して、パケットp2-1を生成して出力し、キューq3から出力するパケットについては、TunnelラベルであるT01と、PWラベルであるPWcとを付与して、パケットp3-1を生成して出力する。図13は前段ノードにおけるシェーピング依頼後のフロー処理を示す図である。図12で示したPWa/T01のフローVPNaのシェーピングを後段ノード20に依頼し、キューq1の滞留パケットが解消されている状態を示している。なお、上記では、フロー識別後にキューイングを行っているが、フロー識別後にポリシング契約帯域を満たしているか否かを監視して契約帯域を超える場合は、その時点でパケットを破棄するを行ってからキューイングする構成にしてもよい。次に後段ノード20におけるシェーピング依頼前と依頼後のフロー処理について説明する。図14はシェーピング依頼前の後段ノードのフロー処理を示す図である。後段ノード20は、パケットp1-1、p2-1、p3-1を受信する。シェーピング依頼前では、Tunnelラベル=T01は、すべて同一フローと認識し、パケットp1-1、p2-1、p3-1をキューq11にキューイングする。また、キューq11からのパケット読み出し時には、例えば、次段ノードへ転送するためのラベルとして、TunnelラベルのT01を外してT13を付与して、パケットp1-2、p2-2、p3-2を生成して出力する。図15はシェーピング依頼後の後段ノードのフロー処理を示す図である。シェーピング依頼を了承する前では、Tunnelラベルのみを参照してフロー識別を行っていたが、シェーピング依頼の了承後では、PWラベルも参照してフロー識別を行い、対象フローこの例ではPWa/T01のフローを別キューq11aに割り当てる。そして、別キューq11aにおいて、前段ノード10で依頼された100Mbpsのレートにてシェーピングを行って、さらに後段のノードへ転送する。対象フロー以外例えば、同じTunnelラベルであってもPWは別ラベルのフローは、Tunnelラベルのみを参照したフローのキューイングのルールにしたがって転送を行う。次にシェーピング依頼時における送出レートのネゴシエーションについて説明する。上記では、後段ノード20に対してシェーピングを依頼した場合、前段ノード10では、該フローのシェーピングを行わずに出力するとした。この場合、全くシェーピングを行わずに入力レートと同じレートで出力してしまうと、後段ノード20側が輻輳してしまう可能性がある。そこで、シェーピングレートすべてを後段ノード20で実行させるのでなく、前段ノード10での送出レートをネゴシエーションし、前段ノード10から折り合ったレートで送出する。図16は送出レートのネゴシエーションを示す図である。ノードPE0前段ノード10と、ノードP1後段ノード20が接続し、ノードPE0は、キューq1~q3を含み、ノードP1はキューq11を含む。ノードPE0において、現在、キューq1では3Gbpsのシェーピングを行い、キューq2では2Gbpsのシェーピングを行い、キューq3では1Gbpsのシェーピングを行っているとする。このとき、キューq1の入力フローフローf1とするが7Gbpsとなって、キューq1のバッファリソースが枯渇しそうになった場合、以下に示すようなシーケンス制御が行われる。S1ノードPE0は、ノードP1に対して、フローf1のシェーピング依頼を行う。依頼内容としては、ノードP1へ向けて、フローf1を7Gbpsで送信することおよびノードP1において、7Gbpsのフローf1を3Gbpsに絞ってシェーピングしてもらうことであるとする。S2ノードP1では、ノードPE0以外のノードから送信されたフローも受信しているので、ノードPE0から7Gbpsのフローが送信されると、キューq11でのキューイング許容力を超えると判断したとする。ノードP1では、7Gbpsのフローの受信ができないことをノードPE0へ通知する。S3ノードPE0は、ステップS1の依頼内容を変えて、ノードP1へ向けて、フローf1を5Gbpsで送信することおよびノードP1において、5Gbpsのフローf1を3Gbpsに絞ってシェーピングしてもらうことを依頼する。S4ノードP1は、5Gbpsのフローの受信が可能であり、かつ5Gbpsのフローf1の3Gbpsのシェーピングが可能であるとすると、ステップS3の依頼に対して了承の応答を返信する。なお、図17にシェーピングポイントが移行した場合の状態を示す。ノードP1では、キューq11aに5Gbpsのフローf1をキューイングして、3Gbpsのシェーピングを行って出力する。このように、ノードPE0では、シェーピングを依頼した際に、自ノードで全くシェーピングをしないのではなく、ノードP1でも輻輳せず、かつ自ノードでもバッファリソース枯渇が解消されるレートを、ノードP1とネゴシエーションする。そして、ネゴシエーションによってノードP1で了承されたレートで送出する。これにより、シェーピングを依頼した際に、ノードP1が輻輳してしまうことがなく、効率よくシェーピングポイントを移行することが可能になる。次にキュー長廃棄閾値のネゴシエーションについて説明する。シェーピングの依頼時に、シェーピング対象のフローのキュー長廃棄閾値をネゴシエーションして、後段ノードのキューに対して、所定の廃棄閾値を設定させる。図18はキュー長のネゴシエーションを示す図である。図16で示したノードPE0のキューq1のキュー長が100KBキロバイトであるとする。S11ノードPE0は、図16で上述したシェーピング依頼の内容ノードP1において、5Gbpsのフローf1を3Gbpsに絞ってシェーピングしてもらうに加えて、さらに自ノードと同じ100KBのキュー長廃棄閾値の設定を依頼する。S12ノードP1は、ステップS11の依頼が可能である場合は、了承の旨の応答を返信する。このように、シェーピング依頼時に、シェーピング対象のフローのキュー長をネゴシエーションし、自ノードPE0と同一の廃棄閾値も合わせてノードP1側に持たせる構成とした。これにより、ノードP1側にノードPE0と同じバースト耐性を持たせることが可能になる。なお、廃棄閾値の単位としては、バイト長またはパケット数などがある。次に後段ノードからのバッファリソース広報について説明する。図19は後段ノードからのバッファリソース広報を示す図である。ネットワーク2-1は、ノードPE0およびノードP1~P3を含み、ノードPE0とノードP1~P3が接続し、ノードPE0は、キューq1~q3を含む。ノードP1~P3は、自己のバッファリソースの情報をノードPE0へ定期的に通知する。例えば、ノードP1は、現在のバッファの空きは500Mバイトであることを通知する。また、ノードP2は、現在のバッファの空きは1Gバイトであることを通知し、ノードP3は、現在のバッファの空きは0バイトであることを通知する。ノードPE0は、これらのノードP1~P3からのバッファリソース情報を受け取って、どの後段ノードならシェーピングが可能であるかを判断する。この例では、ノードP1に対して、キューq1のフローf1のシェーピングを依頼し、ノードP2に対して、キューq2のフローf2のシェーピングを依頼している。また、ノードP3には、バッファの空きがないので、ノードP3に対してはシェーピング依頼を行わない。このように、定期的に後段ノードから前段ノードへバッファリソース情報を広報することにより、前段ノードでは、後段ノードの現在のバッファリソース状況を知ることができる。したがって、シェーピング可能な後段ノードに対してのみ、シェーピング依頼を送信することができるので、依頼はしてみたものの拒絶されるといったことがなくなり、効率よくシェーピング依頼を行うことが可能になる。次にシェーピング依頼の解除について説明する。図20はシェーピング依頼の解除を示す図である。上述したように、前段ノードから後段ノードへシェーピングを移行させることで、前段ノードではバッファリソースの枯渇が解消されてゆく。その場合には、元の前段ノード側にシェーピングポイントを戻す。S21シェーピングポイントの移行により、ノードPE0のキューq1におけるフローf1のシェーピングが、ノードP1のキューq11aでシェーピングされている。また、ノードPE0のキューq2におけるフローf2のシェーピングが、ノードP2のキューq21aでシェーピングされている。S22ノードPE0のキューq1、q2のバッファリソース枯渇が解消される。S23ノードPE0は、キューq1、q2によるシェーピングを再開する。S24ノードPE0は、ノードP1、P2にシェーピング依頼解除を通知する。S25aノードP1は、シェーピング依頼解除通知を受信すると、キューq11aが空になるまで待ち、空になったらフローf1のキューイング先をキューq11へ切り替える。S25bノードP2は、シェーピング依頼解除通知を受信すると、キューq21aが空になるまで待ち、空になったらフローf2のキューイング先をキューq21へ切り替える。S26aノードP1は、解除完了通知をノードPE0へ送信する。S26bノードP2は、解除完了通知をノードPE0へ送信する。このように、ノードPE0でのバッファリソース枯渇が解消された場合には、シェーピング依頼解除をノードP1に通知して、ノードP1でのシェーピング実行を解除させる。これにより、元の通信状態にすみやかに戻って、通常の運用状態へ移行することができる。ここで、ノードP1、P2において、シェーピング依頼解除のメッセージ受信直後に、シェーピングを行っているキューから、元のキューへ戻してしまうと、該フローの出力順序が逆転するおそれがあるシェーピングのために切り出したキューより、戻した後のキューから先にパケットが読み出されると、出力に順序逆転が生じる可能性がある。したがって、上記のように、ノードP1、P2では、シェーピング用に切り出したキューが空になってから、解除完了通知を返信する。なお、前段ノードでシェーピングを再開した際に、後段ノードでなかなかキューが空にならない場合は、後段ノードから前段ノードへバックプレッシャをかけて、後段ノードへの入力を一旦完全に停止させる構成にしてもよい。次にシェーピング依頼のネゴシエーションを行う際のパケットフォーマットについて説明する。図21はフォーマットの一例を示す図である。図では、Ethernet登録商標のフレーム上に実装した場合を示している。なお、IPInternetProtocolスタックやTCP/UDPTransmissionControlProtocol/UserDatagramProtocolスタック上に実装してもよい。パケットは、6バイトのMAC-DAMediaAccessControl-DestinationAddress:後段ノードアドレス、6バイトのMAC-SAMAC-SourceAddress:前段ノードアドレス、2バイトのイーサーネットタイプおよび可変長のペイロードの各フィールドを備える。ペイロードは、バージョン情報Ver、リクエストコードReqCode、リクエストIDRequestID、メッセージ長Lengthのフィールドを備える。リクエストコードは、例えば、0x01がRequest依頼、0x02がAck了承、0x03がNack拒否、0x04がInfo情報通知、0x05がReleaseRequest解除通知と設定する。また、ペイロードは、TLVType/Length/Value形式の各フィールドを備え、TypeとValueに関して、例えば、Type=1は、ネットワークタイプであり、Valueとして、0x01をMPLS-VPNL3とし、0x02をMPLS-VPNL2とし、0x03をPBB-TEProviderBackboneBridge-TrafficEngineeringとして設定する。Type=2は、フロー識別子であり、Valueには、TunnelラベルおよびPWラベルの値を設定する。Type=3は、シェーピングレートであり、Valueには、シェーピングレートの値bpsを設定する。Type=4は、フロー送出レートであり、Valueには、フロー送出レートの値bpsを設定する。Type=5は、キュー長廃棄閾値であり、Valueには、廃棄閾値byteを設定する。Type=6は、キュー長リソースであり、Valueには、キュー長リソースの値byteを設定する。次に上記の図21で示したフォーマットを用いてネゴシエーションする場合のシーケンス例について図22~図24を用いて説明する。図22はシェーピング依頼を行う際のシーケンスを示す図である。ノードPE0からノードP1に対し、Tunnelラベル=T01、PWラベル=PWaのフローについて、シェーピングレート=100Mbps、送信レート=1Gbps、キュー長=100KBで依頼した場合の例を示している。S31ノードPE0は、ノードP1に対して、シェーピングの依頼メッセージM1を送信する。シェーピング依頼動作に関連する、依頼メッセージM1の各フィールドの値を以下に示す。ReqCode=0x01依頼:Request、RequestID=0x01、Type=1のValue=0x02ネットワークタイプがMPLS-VPNL2、Type=2のValueは、FlowID1=T01、FlowID2=PWa、Type=3のValue=100Mbpsシェーピングレート=100Mbps、Type=4のValue=1Gbps送出レート=1Gbps、Type=5のValue=100KBキュー長廃棄閾値=100KBと設定されている。S32ノードP1は、ステップS31の条件のシェーピングを拒否するとして、拒否メッセージM2を返信する。シェーピング拒否動作に関連する、拒否メッセージM2の各フィールドの値を以下に示す。ReqCode=0x03Nack:拒否、RequestID=0x01、Type=4のValue=1Gbps送出レート=1Gbpsと設定されている。ノードPE0から1Gbpsで送られることは拒否している。S33ノードPE0は、500Mbpsでの送信レートに切り替えて再度依頼メッセージM1aを送信する。依頼メッセージM1aの各フィールドの値は、ReqCode=0x01依頼:Request、RequestID=0x01、Type=4のValue=500Mbps送出レート=500Mbpsと設定されている。ここで、M1aには送信レート以外は了承済として依頼メッセージには含めていないが、他のパラメータも再依頼に含めてもよい。なお、依頼メッセージM1とM1aは、RequestIDが同一であることから、ノードP1は、M1aがM1の再依頼であるということが判る。S34ノードP1は、ステップS33の条件を了承したとして、了承メッセージM2aを返信する。了承メッセージM2aの各フィールドの値は、ReqCode=0x02了承:Ack、RequestID=0x01と設定される。図23はバッファリソース広報を行う際のシーケンスを示す図である。コアノードから送信元ノードへバッファリソースの情報を定期的に広報している例を示している。この場合は、ReqCode=0x04情報通知をセットし、キュー長リソースの情報を送信元ノードへ通知している。なお、定期的に広報するたびにRequestIDはカウントアップして通知する。S41ノードP1は、ノードPE0に対して、バッファリソース情報メッセージM11-1を広報する。バッファリソース情報メッセージM11-1の各フィールドの値は、ReqCode=0x04情報通知:Info、RequestID=0x01、Type=6のValue=1GBキュー長リソース=1GBと設定されている。S42ノードP1は、ノードPE0に対して、バッファリソース情報メッセージM11-2を広報する。バッファリソース情報メッセージM11-2の各フィールドの値は、ReqCode=0x04情報通知:Info、RequestID=0x02、Type=6のValue=800MBキュー長リソース=800MBと設定されている。S43ノードP1は、ノードPE0に対して、バッファリソース情報メッセージM11-3を広報する。バッファリソース情報メッセージM11-3の各フィールドの値は、ReqCode=0x04情報通知:Info、RequestID=0x03、Type=6のValue=600Bキュー長リソース=600Bと設定されている。S44ノードP1は、ノードPE0に対して、バッファリソース情報メッセージM11-4を広報する。バッファリソース情報メッセージM11-4の各フィールドの値は、ReqCode=0x04情報通知:Info、RequestID=0x04、Type=6のValue=900MBキュー長リソース=900MBと設定されている。図24はシェーピング依頼解除を行う際のシーケンスを示す図である。ノードPE0からノードP1に対し、シェーピング解除を通知している例を示している。ノードPE0は、ReqCode=0x05解除通知をセットし、TLVのフィールドにシェーピングを依頼した各パラメータをセットして、ノードP1へ送信する。そして、ノードP1は、キュー構成等を元に戻した後に、ReqCode0x02了承を返信する。S51ノードPE0は、ノードP1に対して、シェーピングの解除メッセージM3を送信する。シェーピング解除動作に関連する、解除メッセージM3の各フィールドの値を以下に示す。ReqCode=0x05解除通知:ReleaseRequest、RequestID=0x100、Type=1のValue=0x02ネットワークタイプがMPLS-VPNL2、Type=2のValueは、FlowID1=T01、FlowID2=PWa、Type=3のValue=100Mbpsシェーピングレート=100Mbps、Type=4のValue=500Mbps送出レート=500Mbps、Type=5のValue=100KBキュー長廃棄閾値=100KBと設定されている。S52ノードP1は、キュー構成等を元に戻す。S53ノードP1は、シェーピング解除完了メッセージM3aを返信する。シェーピング解除完了に関連する、解除完了メッセージM3aの各フィールドの値は、ReqCode=0x02了承:Ack、RequestID=0x100と設定されている。次に余剰帯域を利用した送出レートの設定について説明する。前段ノードと後段ノードとの間の物理リンク帯域の余剰帯域を利用して、最大送出レートを設定する。最大送出レートは、最大送出レート=余剰帯域依頼フローのシェーピングレートとなる。ただし、余剰帯域=物理リンク帯域-シェーピングレートの総和である。図25は最大送出レートでのシェーピング依頼を示す図である。ノードPE0とノードP1とを結ぶリンクの物理帯域を10Gbpsとする。また、ノードPE0のキューq1のシェーピングレートが3Gbps、キューq2のシェーピングレートが2Gbps、キューq3のシェーピングレートが1Gbpsとする。キューq1に関するシェーピング依頼を行う場合、最大送出レートは、物理リンク帯域10G-シェーピングレートの総和3G2G1Gキューq1のシェーピングレート3G=7Gbpsとなる。S61ノードPE0は、ノードP1に対して、フローf1のシェーピング依頼を行う。依頼の内容としては、ノードP1へ向けて、フローf1を最大送出レートの7Gbpsで送信することおよびノードP1において、7Gbpsのフローf1を3Gbpsに絞ってシェーピングしてもらうことであるとする。S62ノードP1では、ノードPE0以外のノードから送信されたフローも受信しているので、ノードP1から7Gbpsのフローが送信されると、キューq11でのキューイング許容力を超えると判断したとする。ノードP1では、7Gbpsのフローの受信ができないことをノードPE0へ通知する。S63ノードPE0は、ステップS61の依頼内容を変えて、ノードP1へ向けて、フローf1を5Gbpsで送信することおよびノードP1において、5Gbpsのフローf1を3Gbpsに絞ってシェーピングしてもらうことを依頼する。S64ノードP1は、5Gbpsのフローの受信が可能であり、かつ5Gbpsのフローf1の3Gbpsのシェーピングが可能であるとすると、ステップS63の依頼に対してシェーピングが了承である旨の応答を返信する。このように、前段ノードで最大送出レートを算出し、シェーピング対象フローを最大送出レートで送信可能か否かのネゴシエーションを行う。最大送出レートでの送信が可能であるならば、ノード間を結ぶリンク帯域を有効に活用することができ、前段ノード側のバッファリソース枯渇を高速に解消することが可能になる。次に予備パスを利用したシェーピング依頼について説明する。図26は予備パスを利用したシェーピング依頼を示す図である。ノードPE0とノードP1とが現用パスACTと予備パスSBYとで接続された冗長構成を有している例えば、1:1LinkAggregationやMPLSFRRFastReRouteなど。この場合、ノードPE0からノードP1に対して、キューq1のフローf1のシェーピングを依頼して了承された場合、ノードPE0は、フローf1を予備パスを通じて、ノードP1へ送信する。予備パスが通常運用時には使用されないような完全予備系のパスであるならば、最大送出レートは、予備パスの物理リンクレートとなる。このように、予備パスの帯域を有効に活用することにより、ノードPE0側のバッファリソース枯渇を高速に解消することが可能になる。以上説明したように、限られたバッファ資源の中で、シェーピングキューイングのポイントを動的に移行することにより、キュー輻輳耐力を向上させ、トラフィック輻輳時の廃棄率を改善して、通信品質の向上を図ることが可能になる。なお、上記では、パケットを送受信する通信システムについて説明したが、パケットの代わりにセルやフレーム等で送受信するシステムに関しても、本技術を同様に適用することが可能である。以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。