WO2024201612A1

WO2024201612A1 - 通信装置、トラヒック制御方法、及びプログラム

Info

Publication number: WO2024201612A1
Application number: PCT/JP2023/012007
Authority: WO
Inventors: 宏紀岩澤; 俊哉松田
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: NTT Inc
Priority date: 2023-03-24
Filing date: 2023-03-24
Publication date: 2024-10-03
Anticipated expiration: 2025-09-24
Also published as: JPWO2024201612A1

Abstract

他の拠点との接続を行う第１通信装置と、デバイスを接続する複数の第２通信装置とを備える拠点において、前記第１通信装置として使用される通信装置において、ある第２通信装置から受信したメッセージに基づいて、前記通信装置の送信ポートにおける今後の送信量を推定する推定部と、前記推定部により推定された送信量に基づいて、第２通信装置又は前記通信装置に対するトラヒック制御を実行する制御部とを備える。

Description

通信装置、トラヒック制御方法、及びプログラム

　本発明は、パケット通信におけるトラヒック制御の技術分野に関連するものである。

　近年データセンタは、電力の効率利用や、低遅延アプリケーションの収容、柔軟なフロア設計等の観点から、近距離に分散して小さなデータセンタを展開するマイクロデータセンタ化が進んでいる。このような環境では、マイクロデータセンタ間の通信が増え、データセンタ内通信と混在することが想定される。またデータセンタ間の通信遅延低減が重要となる。

　通信遅延の低減の一つに、離れたサーバ間でPCIe（登録商標）通信を行う手法としてExpEther（登録商標）や超低遅延パケット伝送がある。データセンタ内は複数のスイッチで各サーバを接続し、特定のスイッチはWDM（Wavelength Division Multiplexing）システムなどの伝送装置に接続され、データセンタ間ネットワークはWDMシステムで構成される。もしくは、サーバ内部の内部バス信号を直接光化し、データセンタ間を伝送する。

Toshiya Matsuda, Kota Nishiyama, Kana Masumoto, Masahiro Nakagawa, and Takashi Miyamura, "Ultra-Low Latency Short Packet Transmission Experiments with Optical Bus Platform Based on PCIe," OFC 2022. "IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks-Amendment 17: Priority-based Flow Control (IEEE Std 802.1QbbTM-2011)," Sep.30, 2011. "IEEE Standard for Local and metropolitan area networks-Bridges and Bridged Networks Amendment 25: Enhancements for Scheduled Traffic (IEEE Std 802.1QbvTM-2015)," Mar.18, 2016. "PCI Express Base Specification Revision 1.0," Apr.29, 2002.

　上記のように、データセンタ内／データセンタ間においてWDMシステムを用いる場合、複数のフレーム変換が必要となり、遅延の増加を招く要因となる。一方、サーバ内部のバス信号を直接光化して伝送する場合、フレーム変換の遅延は小さくなり、また、データセンタ間トラフィック量はデータセンタ内に比べ一般に小さいためパケットが廃棄される確率も極めて小さくなる。

　しかし、サーバ内部のバス信号を直接光化して伝送する場合でも、トラフィック量の多いデータセンタ内ネットワークと接続する際に、パケットが廃棄される確率が高くなり、再送等による遅延が増加する可能性がある。

　本発明は上記の点に鑑みてなされたものであり、複数の通信装置を備える拠点において、他の拠点と接続する通信装置におけるパケットの廃棄を削減することを可能とする技術を提供することを目的とする。

　開示の技術によれば、他の拠点との接続を行う第１通信装置と、デバイスを接続する複数の第２通信装置とを備える拠点において、前記第１通信装置として使用される通信装置であって、
　ある第２通信装置から受信したメッセージに基づいて、前記通信装置の送信ポートにおける今後の送信量を推定する推定部と、
　前記推定部により推定された送信量に基づいて、第２通信装置又は前記通信装置に対するトラヒック制御を実行する制御部と
　を備える通信装置が提供される。

　開示の技術によれば、複数の通信装置を備える拠点において、他の拠点と接続する通信装置におけるパケットの廃棄を削減することを可能とする技術が提供される。

２つのＤＣを接続する基本的なＮＷ構成を示す図である。ＤＣ内のＮＷ構成例を示す図である。想定する通信方法を説明するための図である。想定する通信方法を説明するための図である。本発明の実施の形態におけるシステム構成例を示す図である。システムの動作の概要を説明するためのフローチャートである。トラヒック制御のパターンを示す図である。カウント方法の具体例を説明するための図である。送信許可判定処理を示すフローチャートである。実施例１におけるルートＳＷ１０の構成図である。実施例１におけるＳＷ２０の構成図である。実施例１におけるルートＳＷ１０の処理の全体の流れを示すフローチャートである。トラヒック推定処理１の処理手順を示すフローチャートである。各ＳＷ２０における転送処理の手順を示すフローチャートである。実施例１のシーケンス例を示す図である。実施例１のシーケンス例を示す図である。実施例２におけるルートＳＷ１０の構成図である。実施例２におけるルートＳＷ１０の処理の全体の流れを示すフローチャートである。トラヒック推定処理２の処理手順を示すフローチャートである。実施例２のシーケンス例を示す図である。実施例２のシーケンス例を示す図である。通信装置１００の構成図である。通信装置１００のハードウェア構成例を示す図である。

　以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

　以下で説明する例では、ＤＣ（データセンタ）に関わる通信について説明するが、本実施の形態に係る技術は、ＤＣに限らない拠点において適用可能である。

　以下ではまず、本実施の形態に係る技術についての課題を説明し、その後に、本実施の形態に係る技術を説明する。なお、以下の課題の説明において示されるスイッチ（ＳＷ）やデバイス自体は公知技術であるが、課題の説明（どこが問題であるかの分析など）は公知技術ではない。

　（課題について）
　図１に、２つのＤＣを接続する基本的なＮＷ（ネットワーク）構成を示す。図１は、「グローバル」と記載されている（１）ＤＣ間のＮＷ構成と、「ローカル」と記載されている（２）ＤＣ内のＮＷ構成を示す。（１）ＤＣ間、（２）ＤＣ内の何れも階層構造を有する。ＤＣ間のみであれば超低遅延パケット伝送技術をそのまま適用可能である。しかし、ＤＣ内までを含めたＮＷに関しては、前述したようなパケット廃棄（パケットロス）などの課題がある。

　ここでは一例として、ＤＣ内においてPCIe（登録商標）を用いることを想定する。上記の課題に関して、より具体的には、ＤＣ内においてPCIe（登録商標）のフロー制御に起因する遅延増加・パケットロスによるスループット低下が課題となる。

　すなわち、従来の一般的なPCIe（登録商標）の使用形態では、P2P(GPU-ホストメモリ間等)の通信を基本とするため、上記のＤＣ内のような課題は発生せず、上位のTCP/IP/Ethernet（登録商標）においてフロー制御、輻輳制御を実施していた。

　これに対して、今後想定される多数のPCIe（登録商標）デバイスがスイッチを介して接続される環境では、オーバーサブスクリプションが避けられないため、フロー制御による遅延の悪化や、バッファあふれによるパケットロスが生じるという課題がある。

　図２に、上記想定に基づくＮＷ構成例を示す。図２は、ＤＣ間通信を行う複数ＤＣのうちのある１つのＤＣ内のＮＷ構成例を示している。

　図２の構成例において、ＳＷ（スイッチ）を備える光バス装置が複数台存在し、光バス装置には、ＳＷとデバイスを備えるサーバが接続される。各ＳＷ、各デバイスはいずれもPCIe（登録商標）機能を備える。なお、PCIe（登録商標）に代えて、ＣＸＬ（Compute Express Link）を使用してもよい。図２に示すとおり、ＤＣ間通信がバッファあふれにより破棄されたり、PCIe（登録商標）のフロー制御において、特定のデバイスが長時間通信できなかったりする可能性がある。

　以下、上記のような課題を解決するためのシステム／装置の構成及び動作を説明する。具体例として実施例１、２を説明するが、まずは、実施例１、２に共通の事項を説明する。実施例１、２に共通の事項の説明の後に、実施例１、２それぞれを説明する。

　（本実施の形態において想定する通信方法について）
　まず、本実施の形態において想定する通信方法を説明する。本実施の形態では、PCIe（登録商標）機能を備えるデバイス間で、図３、図４に示す通信方法で通信が行われることを想定する。なお、これらの通信方法は、PCIe（登録商標）の代表的な通信方法である。図３、図４において、デバイスＡとデバイスＢとの間には１以上のＳＷが存在するが、図３、図４にはＳＷを図示していない。

　図３に示すケースにおいて、まず、デバイスＡは、Read RequestをデバイスＢに送信する。Read Requestには、デバイスＢから読み込みたいデータの量（要求サイズ、要求データ量）がLengthの値として含まれる。Read Requestを読込要求メッセージと呼んでもよい。Read Requestを送信するデバイスＡをRequester（要求者）と呼んでもよい。

　Read Requestを受信したデバイスＢは、デバイスＡに対してCompletion Message(以降、Completion Msg.と記載）を返す。Read Requestに対するCompletion Msg.には、Read Requestで要求されたサイズのデータが含まれる。Completion Msg.を応答メッセージ、あるいは、完了通知と呼んでもよい。

　図４のケースにおいて、デバイスＡは、Write RequestをデバイスＢに送信する。Write Requestには、デバイスＡがデバイスＢに書き込みたいデータが含まれる。また、Write Requestには、そのデータの量（要求サイズ）がLengthの値として含まれる。Write Requestを書込要求メッセージと呼んでもよい。Write Requestを送信するデバイスＡをRequester（要求者）と呼んでもよい。

　なお、本実施の形態では、例として、上記のようにPCIe（登録商標）の通信方法を用いることを想定しているが、本発明に係る技術は、PCIe（登録商標）に限定されない。Read Request／Write Requestなどと同様の読込要求／書込要求などのメッセージを使用する通信方法であれば、どのような通信方法にも本技術を適用可能である。

　（システム構成例）
　図５に、本実施の形態におけるシステム構成例（ＮＷ構成例）を示す。図５は、ＤＣ内の構成の例を示すものである。図５に示す構成は、後述する実施例１、２に共通の構成である。

　なお、以下の説明においては、装置の名前（ＳＷ１など）を構成する番号と、図面に記載する符号との区別がしやすいように、符号を括弧内に記載する場合がある。また、動作説明等において、符号を記載することで、表記が煩雑になることを避けるために、括弧での符号を付けないで説明する場合がある。また、ルートＳＷ以外のＳＷを総称する場合（ＳＷ１、２などの区別をしない場合）、ＳＷ２０と記載する。同様にＤｅｖについてはＤｅｖ３０と記載する。

　図５に示すように、ルートＳＷ１０の配下に、ＳＷ１（２０－１）とＳＷ２（２０―２）が接続される。また、ＳＷ１（２０－１）には、Ｄｅｖ１（３０－１）とＤｅｖ２（３０－２）が接続され、ＳＷ２（２０－２）には、Ｄｅｖ３（３０－３）とＤｅｖ４（３０－４）が接続される。

　ルートＳＷ１０は、ＤＣ間を接続するＳＷである。各Ｄｅｖ３０は、例えばPCIe（登録商標）の機能を備えるデバイスである。

　ルートＳＷ１０を含む各ＳＷをバススイッチと呼んでもよい。特にルートＳＷ１０をルートバススイッチと呼んでもよい。

　各ＳＷ（バススイッチ）は、例えば、PCIe（登録商標）スイッチ、CXLスイッチ、ExpEther（登録商標）、光バス装置のうちのいずれであってもよい。なお、光バス装置とは、超低遅延パケット伝送を行うためのフレーム（例えばPCIe（登録商標）フレーム）を直接光信号へ変換およびスイッチングする装置である。

　本実施の形態では、動作を分かり易く説明するために、図５に示すとおり、ルートＳＷ１０の配下に１段のＳＷ２０が接続される構成を用いているが、より多くのＳＷ２０が多段に接続される場合でも、その基本的な動作は、図５の構成に基づいて以降で説明する動作と同様である。

　また、本発明に係る技術は、ＳＷ以外の装置に適用することも可能である。ＳＷと「ＳＷ以外の装置」とを総称して通信装置と呼んでもよい。「ＳＷ以外の装置」には、ＳＷと同様に動作するが、ＳＷとは呼ばれない装置が含まれる。

　ルートＳＷ１０、及び各ＳＷ２０はいずれも、他のＳＷあるいはデバイスと接続するためのポートを備える。ポートを介して他のＳＷあるいはデバイスとパケットの送受信を行うことができる。図５では、例として、ルートＳＷ１０のポート１１及びポート１２を図示している。

　ポートを入出力ＩＦ部と呼んでもよい。また、ポートにおいて送信を行う機能部を送信ポートと呼んでもよく、ポートにおいて受信を行う機能部を受信ポートと呼んでもよい。

　送信ポートは、送信しようとするデータ（パケット）を格納するバッファを有する。当該バッファを送信バッファあるいは送信キューと呼んでもよい。送信バッファがポートの外部にあってもよい。つまり、ポートに送信バッファが接続される形態であってもよい。

　（動作概要）
　次に、システムの動作の概要を説明する。本実施の形態では、ルートＳＷ１０が、受信したメッセージ(Read Request等）から、この後に発生するであろうトラヒック量を推定し、ルートＳＷ１０の宛先ＳＷ２０向けの送信バッファが送信データで溢れないよう、配下のＳＷ２０を制御する。もしくは、ルートＳＷ１０において、受信したパケットの送信（転送）を制御する。図６のフローチャートを参照して処理手順の概要を説明する。

　Ｓ１において、ルートＳＷ１０は、受信したメッセージから、ルートＳＷ１０の宛先ＳＷ２０毎のポートの送信バッファ毎のトラヒック量を推定する。Ｓ２において、ルートＳＷ１０は、算出したトラヒック推定量と送信許可ポリシーに従って送信可否判定処理を実施する。

　送信を許可する場合、Ｓ３において、ルートＳＷ１０は、送信許可を制御対象ＳＷ（例：配下のＳＷ）に通知する。Ｓ４において、各ＳＷ２０は送信許可条件に応じて送信を行う。なお、制御対象ＳＷがルートＳＷ１０自身である場合、ルートＳＷ１０は、Ｓ２で送信を許可する判定を行ったら、Ｓ４で送信を行うこととしてもよい。

　上記のような処理により、本実施の形態に係るシステムにおいて、Read/Write Requestメッセージ等から今後発生するトラック量を推定し、例えば、推定値に基づいて高負荷時に動的に時分割多重通信を行うことで、ロスレス、最大バッファ遅延低減を実現することが可能である。本実施の形態では、ＳＷ間で制御を行うので、デバイスからは透過的にロスレス・最大遅延保証を行いつつ帯域利用効率の向上が可能となる。

　（トラヒック量の推定方法について）
　次に、トラヒック量の推定方法を説明する。本実施の形態では、トラヒック量の推定方法として、（１）Read/Write Requestから推定する方法、及び（２）Read Requestのみから推定する方法がある。

　より具体的には、上記のいずれの方法においても、トラヒック量の推定には、パケットヘッダのLength値を使用する。

　前述したとおり、本実施の形態で想定する通信方法において、Read RequestとWrite RequestそれぞれのヘッダにはLengthフィールドがあり、その値から、デバイス間で送受されるトラヒック量を推定することが可能である。

　既存のPCIe（登録商標）では、エンドポイント間でバッファ量を通知することでパケットロスを抑制しているが、本実施の形態に係る技術では、ルートＳＷ１０により推定したトラヒック量が、ＳＷ２０宛のポートのバッファを超えないよう、各ＳＷ１０／２０でのパケット送信を制御することで、パケットの廃棄、それに起因する再送による遅延を削減することとしている。

　（トラヒック制御のパターンについて）
　本実施の形態では、図７に示すように、トラヒック制御のパターンとして、パターン１とパターン２がある。詳細については実施例１（パターン１に対応）、及び実施例２（パターン２に対応）で説明するが、ここでは概要を説明する。

　パターン１は、「（１）Read/Write Requestからトラヒック量を推定する」ケースに対応し、パターン２は「Read Requestのみからトラヒック量を推定する」ケースに対応する。

　パターン１では、「Ａ」に示す、Write RequestのトラヒックとCompletion Msg.のトラヒックに対する制御方法として、各ＳＷ２０は、Ｄｅｖ３０からパケットを受信したら当該各ＳＷ２０で当該パケットを一旦バッファする。ルートＳＷ１０は、Read Request、 Write Requestのヘッダ等から推定したトラヒック量が、ルートＳＷ１０の宛先ＳＷ向けの送信バッファをあふれさせない量であれば、各ＳＷ２０に送信許可を通知する。あふれる量であれば、該当ＳＷ２０への送信を要求しているＳＷ２０間で時分割送信を指示する。

　パターン２において、「Ｂ」に示す、Read Requestのトラヒックに対する制御方法として、ルートＳＷ１０は、受信したRead Requestを一旦保留（バッファ）し、Read Requestから推定したCompletion Msgサイズがバッファをあふれさせなければ、当該Read Requestを宛先ＳＷ２０へ送信する。

　パターン２において、「Ｃ」に示すWrite Requestのトラヒックに対する制御方法は次のとおりである。Write RequestはＳＷ２０、ルートＳＷ１０まですぐに送信し、ルートＳＷ１０から宛先ＳＷ２０に向けた送信ポート（送信キュー）の空バッファ量がRead Requestによるトラヒックの推定量（つまりCompletion Msg.のトラヒック推定量）と比較して十分小さい場合、ＳＷ２０、及び、ルートＳＷ１０側で即座にWrite Requestを破棄し、要求元Ｄｅｖ３０へのＮＡＫを返す。

　（トラヒックのカウント方法と送信許可判定）
　次に、トラヒックのカウント方法と送信許可判定について説明する。本実施の形態におけるカウント方法として、下記のカウント方法１とカウント方法２がある。カウント方法１とカウント方法２のいずれの方法を用いてもよい。

　カウント方法１：送受信Ｄｅｖ３０のペア毎にトラヒックをカウントする。

　カウント方法２：Requesterが接続されたＳＷ２０宛下り送信バッファ毎にトラヒックをカウントする。

　なお、本実施の形態では、メッセージ種別に依存せずに１つのカウンタを使用することを想定しているが、メッセージ種別毎にカウンタを分けてカウントしてもよい。送信許可判定については下記のとおりである。

　カウント方法１の場合は、ルートＳＷ１０の宛先ＳＷ２０向けのポートに含まれる送受信ペア毎のカウンタの総計と送信ポートのバッファ量の比較で送信許可するか否かを評価する。送信許可判定時、各送受信ペアのトラヒックを平等に送出するという条件としてもよいし、送受信ペア毎に重みづけして送信しても良い。

　カウント方法２の場合は、カウンタでカウントされた順（早いもの順）で送信許可情報を作成する。

　図８を参照してカウント方法の具体例を説明する。図８は、図５に対してパケットの送受信の流れを記載した図である。図８に示す例において、Ｄｅｖ１に対してＤｅｖ３とＤｅｖ４のそれぞれからRead Requestパケットを送信する。また、図８において、Ｂ１、Ｂ２はそれぞれ送信バッファのイメージを示す。

　このケースでのカウント方法１とカウント方法２それぞれのカウント方法は下記のとおりである。

　カウント方法１：
　ルートＳＷ１０は、送受信ペア毎（Ｄｅｖ１とＤｅｖ３、Ｄｅｖ１とＤｅｖ４）に別々のカウンタでカウントを行う。つまり、ルートＳＷ１０は、Ｄｅｖ１からＤｅｖ３へのCompletion Msgにより発生するトラヒックと、Ｄｅｖ１からＤｅｖ４へのCompletion Msgにより発生するトラヒックとを別々のカウンタでカウントする。

　カウント方法２:
　ルートＳＷ１０は、RequesterであるＤｅｖ３、　Ｄｅｖ４が接続されたＳＷ２宛ての下り送信バッファＢ２に紐付けられるトラヒックを１つのカウンタでカウントする。つまり、ルートＳＷ１０は、Ｄｅｖ３、Ｄｅｖ４宛てのCompletion Msgにより発生するトラヒックを同一のカウンタでカウントする。

　（ルートＳＷ１０における送信許可判定処理）
　次に、ルートＳＷ１０における送信許可判定処理を図９のフローチャートを参照して説明する。前述したとおり、本実施の形態には、トラヒック制御のパターンとしてパターン１とパターン２があるが、図９に示すフローは、パターン１とパターン２で共通である。なお、パターン１のケースでは、制御対象ＳＷはルートＳＷ１０配下のＳＷ２０となり、パターン２のケースでは、ルートＳＷ１０自身が制御対象ＳＷとなる。

　図９のＳ１００１において、ルートＳＷ１０は、宛先ＳＷ向けのトラヒック推定量がルートＳＷ２０の宛先向け送信バッファの一定量を超えるかどうかを判断する。「送信バッファの一定量を超える」とは、例えば、「送信バッファの格納容量全部を１００％とした場合、トラヒック推定量を現在の送信バッファ格納量に加えたときに、送信バッファの格納量がＸ％を超える」ことである。Ｘは予め定めておく数である。

　超える場合（Ｙｅｓの場合）はＳ１００２に進み、超えない場合（Ｎｏの場合）はＳ１００３に進む。

　Ｓ１００２において、ルートＳＷ１０は、トラヒックが当該バッファをあふれさせずに送信できる条件（例：ＳＷ間で時分割）を計算し、制御対象ＳＷへの送信許可を作成する。

　Ｓ１００３において、ルートＳＷ１０は、制御対象ＳＷがバッファリングしているパケットの全送信許可を作成する。

　図９に示すフローにおいて、送信調整が必要なパターンでは、１回調整が行われるのみとしているが、予め定めたスケジューリングアルゴリズムに基づいて、送信許可量あるいは時間が変わるたびに通知を行っても良い。例えば、１回目の送信許可だけでは各ＳＷのバッファにパケットが残ってしまう場合、一定の時間が経過後に、再度送信許可判定を実施してもよい。

　以下、実施例１と実施例２を説明する。実施例１はトラヒック制御のパターン１を用いる実施例であり、実施例２はトラヒック制御のパターン２を用いる実施例である。

　（実施例１）
　まず、パターン１を用いる実施例１を説明する。実施例１におけるトラヒック量推定方法、及び、トラヒック制御方法は下記のとおりである。

　＜実施例１：トラヒック量推定方法＞
　Write Request：
　各ＳＷ２０でTLP(Transaction Layer Packet)のメモリ情報とPCIe（登録商標）メモリアドレス全体の情報から、送信先ごとにWrite Request量をカウントし、一定周期毎または逐次、ルートＳＷ１０に通知する。もしくは、各ＳＷで受信したWrite Requestのヘッダ情報のみルートＳＷ１０に送信してルートＳＷ１０が、ヘッダ情報からトラヒック量を推定してもよい。

　Completion Msg：
　ルートＳＷ１０は、Read RequestのLengthフィールドを活用し、返信としてRequester側に送られるCompletion Msgのトラヒック量を推定する。

　＜実施例１：トラヒック制御方法＞
　Read Requestに対する制御：
　新規のトラヒック制御はなく、各デバイスからノンブロッキングでの送信とする。

　Write Requestに対する制御：
　Ｄｅｖ３０からＳＷ２０への送信に関しては新規のトラヒック制御はなし。

　ＳＷ２０からルートＳＷ１０への送信時、ＳＷ２０はルートＳＷ１０から送信許可を通知された場合のみ送信可能とする。ルートＳＷ１０からの送信許可がない場合はＳＷ２０内の送信キュー（送信バッファ）でバッファする。ルートＳＷ１０は、送信許可を、以下のポリシーで送信する。

　・ルートＳＷ１０の宛先ＳＷ２０向けの送信ポート毎に、推定トラヒック量が少なく、バッファあふれが発生しない（推定トラヒック量が送信バッファに対して一定値を超えない）場合の送信は全て許可する。つまり、Write Requestのサイズがバッファあふれを起こさせなければ、送信可能とする。

　・ルートＳＷ１０の宛先ＳＷ２０向けの送信ポート毎に、推定トラヒック量が多く、バッファあふれが発生しうる（推定トラヒック量が送信バッファに対して一定値を超える）場合、該当ＳＷ２０への送信を要求しているＳＷ２０間で時分割できる形で送信許可をする。また、制御対象のＳＷ２０に対して、ある送信データ量毎に送信許可してもよい。

　Completion Msgに対する制御：
　Ｄｅｖ３０からＳＷ２０への送信に関しては新規のトラヒック制御はなし。

　ＳＷ２０からルートＳＷ１０への送信は、ルートＳＷ１０が送信許可を行った場合のみ送信可能とする。ルートＳＷ１０からの送信許可がない場合はＳＷ２０内の送信キューでバッファする。ルートＳＷ１０は、送信許可を、以下のポリシーで送信する。

　・ルートＳＷ１０の宛先ＳＷ２０向けのポート毎に、推定トラヒック量が少なく、バッファあふれが発生しない(推定トラヒック量が送信バッファに対して一定値を超えない)場合の送信は全て許可する。つまり、RequesterへのCompletion Msgのサイズがバッファあふれを起こさせなければ、送信可能とする。

　・ルートＳＷ１０の宛先ＳＷ２０向けのポート毎に、推定トラヒック量が多く、バッファあふれが発生しうる（推定トラヒック量が送信バッファに対して一定値を超える）場合、該当ＳＷ２０への送信を要求しているＳＷ２０間で時分割できる形で送信許可をする。また、制御対象のＳＷ２０に対して、ある送信データ量毎に送信許可してもよい。

　＜実施例１：ルートＳＷ１０の構成＞
　図１０に、ルートＳＷ１０の機能構成例を示す。図１０は、主に実施例１での処理に関わる構成を示しており、その他の一般的なＳＷが備える機能は図示していない。

　図１０に示すように、ルートＳＷ１０は、入出力ＩＦ部１１、トラヒック量推定部１２、送信可否判定部１３、送信許可送信部１４、転送処理部１５を備える。

　入出力ＩＦ部１１は、外部と情報の入出力を行う。トラヒック量推定部１２は、受信したメッセージ（例：Read Request、Completion Msg.、Write Requestのヘッダ情報、もしくは、トラヒック推定用情報）から、宛先ＳＷ２０毎に発生するトラヒック量を推定する。トラヒック量推定部１２は、トラヒック量推定のためのカウンタを有する。

　送信可否判定部１３は、宛先ＳＷ２０毎に送信ポートのバッファ量とトラヒック量推定部１２で推定したトラヒック量を比較して、配下のＳＷ２０がバッファリングしている「Completion Msg.、及び／又は、Write Request」の送信可否を判定する。

　送信許可送信部１４は、送信可と判定された場合、該当ＳＷ２０に対して送信可を示す情報と送信可能なデータ量を通知する。転送処理部１５は、パケットの転送処理等を行う。

　＜実施例１：ＳＷ２０の構成＞
　図１１に、ＳＷ２０の機能構成例を示す。図１１は、主に実施例１での処理に関わる構成を示しており、その他の一般的なＳＷが備える機能は図示していない。図１１に示すように、　　ＳＷ２０は、入出力ＩＦ部２１、トラヒック推定用情報通知部２２、送信許可受信部２３、パケットバッファ部２４、転送処理部２５を備える。

　入出力ＩＦ部２１は、外部と情報の入出力を行う。トラヒック推定用情報通知部２２は、受信したパケット(例：Write Request)からヘッダ情報を切出したものを含むトラヒック推定用情報、もしくは、ヘッダ情報に格納されているLength情報を含むトラヒック推定用情報を生成し、ルートＳＷ１０に通知する。

　送信許可受信部２３は、ルートＳＷ１０から通知された送信許可を受信し、送信許可条件に応じて、パケットバッファ部２４に格納されたパケットを取り出し、転送処理部２５を介して、ルートＳＷ１０もしくはＤｅｖ３０に送信する。

　パケットバッファ部２４は、Ｄｅｖ３０から受信したパケット（例：Completion Msg.、Write Request)を、ルートＳＷ１０からの送信許可がでるまでバッファリングする。転送処理部２５は、パケットの転送処理等を行う。

　＜実施例１におけるルートＳＷ１０の処理の全体の流れ＞
　図１２のフローチャートを参照して、実施例１のルートＳＷ１０における処理全体のフローを説明する。

　Ｓ１０において、入出力ＩＦ部１１がメッセージを受信する。当該メッセージはトラヒック量推定部１２に渡される。

　Ｓ１１において、トラヒック量推定部１２が、トラヒック推定処理１を行う。トラヒック推定処理１の処理については後述する。Ｓ１２において、受信したメッセージの種別が「Read Request、Write Requestヘッダ、又は、トラヒック推定量」である場合はＳ１３に進み、受信したメッセージの種別が「Write Request、又は、Completion Msg.」である場合はＳ１５に進む。

　Ｓ１３において、送信可否判定部１３が、送信許可判定処理を行う。Ｓ１４において、送信許可送信部１４が、送信を許可する各ＳＷ２０へ送信許可を通知する。

　受信したメッセージの種別が「Write Request、又は、Completion Msg.」である場合のＳ１５において、転送処理部１５が、パケットを宛先に転送する。

　＜ルートＳＷ１０におけるトラヒック推定処理１＞
　図１３は、ルートＳＷ１０におけるトラヒック推定処理１の処理手順を示すフローチャートである。図１３を参照して、ルートＳＷ１０におけるトラヒック推定処理１の処理手順を説明する。

　Ｓ１１－１において、トラヒック量推定部１２は、受信したメッセージの種別を判断する。種別が「Read Request」であればＳ１１－２に進み、種別が「Completion Msg.
もしくはWrite Request」であればＳ１１－３に進み、種別が「Write Requestヘッダ、もしくはトラヒック推定量」であればＳ１１－４に進む。

　Ｓ１１－２において、トラヒック量推定部１２は、受信したRead RequestのヘッダのLengthから取得したCompletion Msgのサイズ分をトラヒック推定カウンタに加算する。

　Ｓ１１－３において、トラヒック量推定部１２は、受信したCompletion Msg.もしくはWrite Requestのサイズ分をトラヒック推定カウンタから減算する。

　Ｓ１１－４において、トラヒック量推定部１２は、受信したWrite RequestヘッダのLengthのサイズ分、もしくは、受信したトラヒック推定量のサイズ分をトラヒック推定カウンタに加算する。

　＜各ＳＷ２０における転送処理＞
　図１４は、ルートＳＷ１０配下の各ＳＷ２０における転送処理の手順を示すフローチャートである。図１４を参照して、各ＳＷ２０における転送処理を説明する。

　Ｓ２０において、転送処理部２５は、受信パケットがルートＳＷ１０から転送されてきたものか、それとも、Ｄｅｖ３０から送信されたものか、を判断する。ルートＳＷ１０から転送されてきたものである場合はＳ２７に進み、Ｄｅｖ３０から送信されたものである場合はＳ２１に進む。

　Ｓ２１において、転送処理部２５は、Ｄｅｖ３０から受信したメッセージの種別を判断する。種別が「Read Request」である場合はＳ２５に進み、種別が「Write Request」である場合はＳ２２に進み、種別が「Completion Msg.」である場合はＳ２６に進む。

　メッセージ種別が「Write Request」である場合のＳ２２において、パケットバッファ部２４がパケットを一旦バッファする。Ｓ２３において、トラヒック推定用情報通知部２２は、Write Requestにおける送信量をルートＳＷ１０に通知する。もしくは、トラヒック推定用情報通知部２２は、受信したWrite RequestのヘッダのみルートＳＷ１０に転送してもよい。その後、Ｓ２４に進む。

　メッセージ種別が「Completion Msg.」である場合のＳ２６において、パケットバッファ部２４がパケットを一旦バッファし、Ｓ２４に進む。

　Ｓ２４において、送信許可受信部２３は、ルートＳＷ１０からの送信許可を受けたかどうかを判断し、受けていればＳ２５に進む。Ｓ２５において、転送処理部２５は、パケットを宛先に転送する。

　また、受信パケットがルートＳＷ１０から転送されてきた場合であるＳ２７において、転送処理部２５は宛先のＤｅｖ３０へパケットを転送する。

　＜実施例１のシーケンス例(Read Request～Completion Msg.の動作）＞
　図１５を参照して、Ｄｅｖ１からＤｅｖ３へRead Requestを送信した時のシーケンス例を説明する。

　Ｓ１０１において、Ｄｅｖ１はＳＷ１にRead Requestを送信する。Ｓ１０２において、ＳＷ１がRead RequestをルートＳＷ１０に転送する。ルートＳＷ１０は、Ｓ１０３においてトラヒック量推定処理１を実行し、Ｓ１０４においてRead RequestをＳＷ２に転送する。ＳＷ２は、Ｓ１０５においてRead RequestをＤｅｖ３に転送する。Ｓ１０７において、Ｄｅｖ３は、Completion Msg.をＳＷ２に送信し、Ｓ１０８においてＳＷ２はCompletion Msg.をバッファリングする。

　一方、Ｓ１０６において、ルートＳＷ１０は、送信許可判定処理を行う。ＳＷ２に対して送信許可するとの判定がなされると、Ｓ１０９において、ルートＳＷ１０は送信許可通知をＳＷ２に送信する。Ｓ１１０において、ＳＷ２はCompletion Msg.をルートＳＷ１０に送信する。Ｓ１１１において、ルートＳＷ１０は、トラヒック量推定処理１を行い、Ｓ１１２においてCompletion Msg.をＳＷ１に転送する。Ｓ１１３において、ＳＷ１はCompletion Msg.をＤｅｖ１に転送する。

　＜実施例１のシーケンス例(Write Requestの制御例）＞
　図１６を参照して、Ｄｅｖ３からＤｅｖ１へWrite Requestを送信した時のシーケンス例を説明する。

　Ｓ２０１において、Ｄｅｖ３はＳＷ２にWrite Requestを送信する。Ｓ２０２において、ＳＷ２は、Write Requestをバッファリングする。Ｓ２０３において、ＳＷ２は、推定トラヒック量もしくはWrite Requestヘッダ情報をルートＳＷ１０に通知する。

　ルートＳＷ１０は、Ｓ２０４においてトラヒック量推定処理１を行い、Ｓ２０５において送信許可判定処理を行う。

　ＳＷ２の送信が許可されたとすると、Ｓ２０６において、ルートＳＷ１０は、ＳＷ２に対して送信許可通知を送信する。Ｓ２０７において、ＳＷ２はルートＳＷ１０に対してWrite Requestを送信する。Ｓ２０８において、ルートＳＷ１０はＳＷ１に対してWrite Requestを転送し、Ｓ２０９において、ＳＷ１はＤｅｖ１に対してWrite Requestを転送する。Ｓ２１０において、ルートＳＷ１０は、トラヒック量推定処理１を行う。

　＜その他の例＞
　本実施例１において、以上説明したトラヒック制御の例では、送信停止をデフォルトとし、送信許可の場合にルートＳＷ１０から許可・停止（ｏｒ送信量）を通知することとしているが、これは一例である。トラヒック制御において、送信許可をデフォルトとし、送信不可の場合にルートＳＷ１０から停止・再開を通知してもよい。また、PCIe（登録商標）のフロー制御のように送信可能なデータ量(バイトor DW(4byte)単位)を管理し、ルートＳＷ１０がデータ量を更新してもよい。

　（実施例２）
　次に、トラヒック制御のパターン２を用いる実施例２を説明する。実施例２におけるトラヒック量推定方法、トラヒック制御方法は下記のとおりである。

　＜実施例２：トラヒック量推定方法＞
　Write Request：
　実施例２ではWrite Requestについてのトラヒック量推定を行わない。

　Completion Msg：
　ルートＳＷ１０は、Read RequestのLengthフィールドを活用し、返信としてRequester側に送られるCompletion Msgのデータ量を推定する。

　＜実施例２：トラヒック制御方法＞
　Read Requestに対する制御：
　ルートＳＷ１０で一旦バッファし、Requesterが接続されたＳＷ２０宛の、上記で算出した推定トラヒック量と下り送信バッファ空き容量に基づき、下記のスケジューリングポリシーに従ってRead Requestの送信制御を行う。

　・ルートＳＷ１０の宛先ＳＷ２０向けの送信ポート毎に、推定トラヒック量が少なく、バッファあふれが発生しない（推定トラヒック量が送信バッファに対して一定値を超えない）場合の送信は全て許可する。つまり、Completion Msg.のサイズがバッファあふれを起こさせなければ、送信可能とする。

　・ルートＳＷ１０の宛先ＳＷ２０向けの送信ポート毎に、推定トラヒック量が多く、バッファあふれが発生しうる（推定トラヒック量が送信バッファに対して一定値を超える）場合、該当ＳＷ２０への送信を要求しているＳＷ２０間で時分割できる形で送信許可をする。また、制御対象ＳＷに対して、ある送信データ量毎に送信許可してもよい。時分割としては、例えば「（パケットサイズ／転送速度）＋ＲＴＴ時間」ごとに送信許可タイミングを割り当てるなどの処理が可能である。なお、上記転送速度は例えばＰＣＩｅ（登録商標）の転送速度である。

　Write Requestに対する制御：
　Write RequestはＳＷ２０、ルートＳＷ１０まですぐに送信可能とするが、ルートＳＷ１０から宛先ＳＷ２０に向けた送信キュー（送信バッファ）の空バッファ量が、Read Requestから推定したCompletion Msg.のトラヒック推定量と比較して十分小さい場合、ＳＷ２０、ルートＳＷ１０側で即座にWrite Requestを破棄し、要求元Ｄｅｖ３０へのＮＡＫを返す（再送を促す）。

　Completion Msgに対する制御：
　新規のトラヒック制御は行わない。　　
　＜実施例２：ルートＳＷ１０の構成＞
　実施例２において、ルートＳＷ１０配下のＳＷ２０としては通常の機能を持つものを使用することができる。

　図１７に、実施例２におけるルートＳＷ１０の機能構成例を示す。図１７は、主に実施例２での処理に関わる構成を示しており、その他の一般的なＳＷが備える機能は図示していない。

　図１７に示すように、ルートＳＷ１０は、入出力ＩＦ部１１、転送処理部１５、Write Req.送信可否判定部１６、トラヒック量推定部１７、送信可否判定部１８、パケットバッファ部１９を備える。

　入出力ＩＦ部１１は、外部と情報の入出力を行う。転送処理部１５はパケットの転送処理等を行う。Write Req.送信可否判定部１６は、受信したWrite Requestメッセージの送信可否を判断する。トラヒック量推定部１７は、受信したメッセージ（例：Read Request、Completion Msg.）から、宛先ＳＷ２０毎に発生するトラヒック量を推定する。

　送信可否判定部１８は、宛先ＳＷ２０毎に送信ポートのバッファ量とトラヒック量推定部１７で推定したトラヒック量を比較して、自身がバッファリングしているRead Requestの送信可否を判断する。パケットバッファ部１９は、受信したパケット（Read Request)を、送信可否判定部１８からの送信許可がでるまでバッファリングする。

　＜実施例２におけるルートＳＷ１０の処理の全体の流れ＞
　図１８のフローチャートを参照して、ルートＳＷ１０における処理全体のフローを説明する。

　転送処理部１５が、Ｓ３１においてメッセージを受信し、Ｓ３２において、受信したメッセージの種別を判断する。受信したメッセージの種別が「Read RequestもしくはCompletion Msg.」である場合はＳ３３に進み、受信したメッセージの種別が「Write Request」である場合はＳ３８に進む。

　Ｓ３３において、トラヒック推定部１７がトラヒック推定処理２を行う。Ｓ３４において、受信したメッセージの種別が「Read Request」である場合はＳ３５に進み、受信したメッセージの種別が「Completion Msg.」である場合はＳ３７に進む。

　Ｓ３５において、送信可否判定部１８は、送信可否判定処理を行う。送信可（Ｓ３６のＹｅｓ）であれば、Ｓ３７において転送処理部１５がパケットを宛先ＳＷ２０に転送する。

　受信したメッセージ種別がWrite Requestである場合のＳ３８において、送信可否判定部１８は、宛先ＳＷ２０に向けた送信キューの送信バッファの空きが、Read Requestから推定したCompletion Msg.のトラヒック推定量と比較して十分に小さい場合、（Ｓ３８のＹｅｓ）にＳ４０に進み、十分に小さくはない場合（Ｓ３８のＮｏ）にＳ３９に進む。

　Ｓ３９において、転送処理部１５は、受信したWrite Requestパケットを宛先ＳＷ２０に転送する。Ｓ４０において、転送処理部１５は、受信したWrite Requestパケットを廃棄し、送信元Ｄｅｖ３０にＮＡＫを送信する。

　＜ルートＳＷ１０におけるトラヒック推定処理２＞
　図１９は、ルートＳＷ１０におけるトラヒック推定処理２の処理手順を示すフローチャートである。図１９を参照して、ルートＳＷ１０におけるトラヒック推定処理２の処理手順を説明する。

　Ｓ３３－１において、トラヒック量推定部１７は、受信したメッセージの種別を判断する。種別が「Read Request」であればＳ３３－３に進み、種別が「Completion Msg.」であればＳ３３－２に進む。

　Ｓ３３－３において、トラヒック量推定部１７は、受信したRead RequestのヘッダのLengthから取得したCompletion Msgのサイズ分をトラヒック推定カウンタに加算する。

　Ｓ３３－２において、トラヒック量推定部１７は、受信したCompletion Msg.のサイズ分をトラヒック推定カウンタから減算する。

　＜実施例２のシーケンス例(Read Request受信時の動作）＞
　図２０を参照して、Ｄｅｖ１からＤｅｖ３へRead Requestを送信した時のシーケンス例を説明する。

　Ｓ３０１において、Ｄｅｖ１はＳＷ１にRead Requestを送信する。Ｓ３０２において、ＳＷ１がRead RequestをルートＳＷ１０に転送する。ルートＳＷ１０は、Ｓ３０３においてRead Requestをバッファリングし、Ｓ３０４においてトラヒック量推定処理２を行い、Ｓ３０５において送信可否判定処理を行う。

　Ｓ３０６において、ルートＳＷ１０はＳＷ２にRead Requestを転送する。Ｓ３０７において、ＳＷ２がRead RequestをＤｅｖ３に転送する。Ｓ３０８において、Ｄｅｖ３がCompletion Msg.をＳＷ２に送信し、Ｓ３０９において、ＳＷ２がCompletion Msg.をルートＳＷ１０に転送する。

　Ｓ３１０において、ルートＳＷ１０がCompletion Msg.をＳＷ１に転送し、Ｓ３１１において、ＳＷ１がCompletion Msg.をＤｅｖ１に転送する。Ｓ３１２において、トラヒック推定部１７は、トラヒック推定処理２を実行する。

　＜実施例２のシーケンス例(Write Request受信時の動作）＞
　図２１を参照して、Ｄｅｖ３からＤｅｖ１へWrite Requestを送信した時のシーケンス例を説明する。本シーケンス例では、Write Requestを受信し、トラヒック推定量と空きバッファの比較を実施した結果、送信不可と判定した場合の流れを示す。なお、送信可と判定された場合、ルートＳＷ１０は受信したパケットを宛先に転送する。

　Ｓ４０１において、Ｄｅｖ３はＳＷ２にWrite Requestを送信する。Ｓ４０２において、ＳＷ２は、Write RequestをルートＳＷ１０に転送する。Ｓ４０３においてルートＳＷ１０の送信可否判定部１８は送信許可判定処理を行い、上記のとおり送信不可と判定し、Write Requestを破棄し、Ｓ４０４においてＮＡＫをＳＷ２に返す。Ｓ４０５において、ＳＷ２はＤｅｖ３にＮＡＫを返す。

　（他の構成例）
　ルートＳＷ１０においてトラヒック量推定、及びトラヒック制御を行う機能を含む通信装置１００の構成例を図２２に示す。図２２に示す通信装置１００は、ルートＳＷ１０そのものであってもよいし、ルートＳＷ１０におけるトラヒック量推定、及びトラヒック制御を行う機能を、スイッチング機能の外部に備えることとした場合のその外部の装置であってもよい。

　図２２に示すとおり、通信装置１００は、推定部１１０と制御部１２０を含む。当該通信装置１００は、他の拠点との接続を行う第１通信装置と、デバイスを接続する複数の第２通信装置とを備える拠点において、前記第１通信装置として使用される通信装置に相当する。

　推定部１１０は、ある第２通信装置から受信したメッセージに基づいて、前記通信装置１００の送信ポートにおける今後の送信量（トラヒック量）を推定する。制御部１２０は、記推定部１１０により推定された送信量に基づいて、第２通信装置又は前記通信装置１００に対するトラヒック制御を実行する。

　（ハードウェア構成例）
　通信装置１００は、例えば、コンピュータにプログラムを実行させることにより実現できる。このコンピュータは、物理的なコンピュータであってもよいし、クラウド上の仮想マシンであってもよい。

　すなわち、通信装置１００は、コンピュータに内蔵されるＣＰＵやメモリ等のハードウェア資源を用いて、当該装置で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。

　図２３は、上記コンピュータのハードウェア構成例を示す図である。図２３のコンピュータは、それぞれバスＢＳで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インタフェース装置１００５、表示装置１００６、入力装置１００７、出力装置１００８等を有する。なお、当該コンピュータは、更にＧＰＵを備えてもよい。

　当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ－ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

　メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、通信装置１００に係る機能を実現する。インタフェース装置１００５は、ネットワーク等に接続するためのインタフェースとして用いられる。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。出力装置１００８は演算結果を出力する。

　（実施の形態の効果）
　以上説明したとおり、本実施の形態で説明した技術により、ルートＳＷ１０の送信バッファが溢れないよう、ルートＳＷ１０や配下のＳＷ２０を制御することで、ＤＣ内通信のようにトラヒック量が多い場合でも、パケット廃棄を少なくすることが可能となる。

　以上の実施形態に関し、更に以下の付記を開示する。

　＜付記＞
（付記項１）
　他の拠点との接続を行う第１通信装置と、デバイスを接続する複数の第２通信装置とを備える拠点において、前記第１通信装置として使用される通信装置であって、
　ある第２通信装置から受信したメッセージに基づいて、前記通信装置の送信ポートにおける今後の送信量を推定する推定部と、
　前記推定部により推定された送信量に基づいて、第２通信装置又は前記通信装置に対するトラヒック制御を実行する制御部と
　を備える通信装置。
（付記項２）
　前記メッセージは読込要求メッセージであり、前記推定部は、前記読込要求メッセージの要求データ量に基づいて、前記読込要求メッセージの送信元に向けたトラヒックの送信量を推定する
　付記項１に記載の通信装置。
（付記項３）
　前記メッセージは、書込要求メッセージから取得された要求データ量を含むメッセージであり、前記推定部は、前記要求データ量に基づいて、前記書込要求メッセージの送信先に向けたトラヒックの送信量を推定する
　付記項１に記載の通信装置。
（付記項４）
　前記制御部は、読込要求メッセージに対する応答メッセージの送信制御、又は、書込要求メッセージに対する送信制御を、第２通信装置に対して実行する
　付記項１に記載の通信装置。
（付記項５）
　前記メッセージは読込要求メッセージであり、前記制御部は、前記推定部により推定された、前記読込要求メッセージに対する応答メッセージの送信量に基づいて、前記読込要求メッセージの送信制御を実行する
　付記項１に記載の通信装置。
（付記項６）
　前記制御部は、送信ポートの空きバッファ量に基づいて、前記通信装置が受信した書込要求メッセージの送信制御を実行する
　付記項１に記載の通信装置。
（付記項７）
　他の拠点との接続を行う第１通信装置と、デバイスを接続する複数の第２通信装置とを備える拠点において、前記第１通信装置として使用される通信装置が実行するトラヒック制御方法であって、
　ある第２通信装置から受信したメッセージに基づいて、前記通信装置の送信ポートにおける今後の送信量を推定する推定ステップと、
　前記推定ステップにより推定された送信量に基づいて、第２通信装置又は前記通信装置に対するトラヒック制御を実行する制御ステップと
　を備えるトラヒック制御方法。
（付記項８）
　コンピュータを、付記項１ないし６のうちいずれか１項に記載の通信装置における各部として機能させるためのプログラムを記憶した非一時的記憶媒体。

　以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０　ルートＳＷ
１１　入出力ＩＦ部
１２　トラヒック量推定部
１３　送信可否判定部
１４　送信許可送信部
１５　転送処理部１
１６　Write Req.送信可否判定部
１７　トラヒック量推定部
１８　送信可否判定部
１９　パケットバッファ部
２０　ＳＷ
２１　入出力ＩＦ部
２２　トラヒック推定用情報通知部
２３　送信許可受信部
２４　パケットバッファ部
２５　転送処理部
３０　Ｄｅｖ
１０００　ドライブ装置
１００１　記録媒体
１００２　補助記憶装置
１００３　メモリ装置
１００４　ＣＰＵ
１００５　インタフェース装置
１００６　表示装置
１００７　入力装置
１００８　出力装置

Claims

　他の拠点との接続を行う第１通信装置と、デバイスを接続する複数の第２通信装置とを備える拠点において、前記第１通信装置として使用される通信装置であって、
　ある第２通信装置から受信したメッセージに基づいて、前記通信装置の送信ポートにおける今後の送信量を推定する推定部と、
　前記推定部により推定された送信量に基づいて、第２通信装置又は前記通信装置に対するトラヒック制御を実行する制御部と
　を備える通信装置。
　前記メッセージは読込要求メッセージであり、前記推定部は、前記読込要求メッセージの要求データ量に基づいて、前記読込要求メッセージの送信元に向けたトラヒックの送信量を推定する
　請求項１に記載の通信装置。
　前記メッセージは、書込要求メッセージから取得された要求データ量を含むメッセージであり、前記推定部は、前記要求データ量に基づいて、前記書込要求メッセージの送信先に向けたトラヒックの送信量を推定する
　請求項１に記載の通信装置。
　前記制御部は、読込要求メッセージに対する応答メッセージの送信制御、又は、書込要求メッセージに対する送信制御を、第２通信装置に対して実行する
　請求項１に記載の通信装置。
　前記メッセージは読込要求メッセージであり、前記制御部は、前記推定部により推定された、前記読込要求メッセージに対する応答メッセージの送信量に基づいて、前記読込要求メッセージの送信制御を実行する
　請求項１に記載の通信装置。
　前記制御部は、送信ポートの空きバッファ量に基づいて、前記通信装置が受信した書込要求メッセージの送信制御を実行する
　請求項１に記載の通信装置。
　他の拠点との接続を行う第１通信装置と、デバイスを接続する複数の第２通信装置とを備える拠点において、前記第１通信装置として使用される通信装置が実行するトラヒック制御方法であって、
　ある第２通信装置から受信したメッセージに基づいて、前記通信装置の送信ポートにおける今後の送信量を推定する推定ステップと、
　前記推定ステップにより推定された送信量に基づいて、第２通信装置又は前記通信装置に対するトラヒック制御を実行する制御ステップと
　を備えるトラヒック制御方法。
　コンピュータを、請求項１ないし６のうちいずれか１項に記載の通信装置における各部として機能させるためのプログラム。