特許 5737723 パケット交換通信網におけるスケジューリング方法、エンドノード及びコアネットワークスイッチ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5737723

(24)【登録日】2015年5月1日

(45)【発行日】2015年6月17日

(54)【発明の名称】パケット交換通信網におけるスケジューリング方法、エンドノード及びコアネットワークスイッチ

(51)【国際特許分類】

   H04L 12/911 20130101AFI20150528BHJP

   H04L 12/853 20130101ALI20150528BHJP

   H04L 12/44 20060101ALI20150528BHJP

【ＦＩ】

   H04L12/911

   H04L12/853

   H04L12/44 B

   H04L12/44 300

【請求項の数】6

【全頁数】13

(21)【出願番号】特願2011-550517(P2011-550517)

(86)(22)【出願日】2010年2月9日

(65)【公表番号】特表2012-518928(P2012-518928A)

(43)【公表日】2012年8月16日

(86)【国際出願番号】EP2010051555

(87)【国際公開番号】WO2010094595

(87)【国際公開日】20100826

【審査請求日】2012年12月14日

(31)【優先権主張番号】09305166.2

(32)【優先日】2009年2月20日

(33)【優先権主張国】EP

【前置審査】

(73)【特許権者】

【識別番号】501263810

【氏名又は名称】トムソン ライセンシング

【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ

(74)【代理人】

【識別番号】100134094

【弁理士】

【氏名又は名称】倉持 誠

(74)【代理人】

【識別番号】100121175

【弁理士】

【氏名又は名称】石井 たかし

(74)【代理人】

【識別番号】100123629

【弁理士】

【氏名又は名称】吹田 礼子

(72)【発明者】

【氏名】マーチェ，ゲール

(72)【発明者】

【氏名】ル・ルー，ジャン

(72)【発明者】

【氏名】シャペル，クロード

【審査官】 廣川 浩

(56)【参考文献】

【文献】 国際公開第２００８／１１３７９１（ＷＯ，Ａ１）

【文献】 特開２００８−１３１２４７（ＪＰ，Ａ）

【文献】 特開２００６−０８７０１４（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／００−１２／９５５

(57)【特許請求の範囲】

【請求項1】

エンドノード及びコアネットワークスイッチを有するパケット交換通信網におけるリソースの予約をスケジューリングする方法であって、
該方法は、ＯＳＩ（開放型システム間相互接続）モデルのデータリンクレイヤのレベルで実施される、
エンドノードが発行し、少なくとも１つのコアネットワークスイッチにより転送されるリクエストの各々に時間情報を含め、仕様で規定されるストリームを該時間情報が示す時間に受信するためのリソースの予約を要求するステップと、
関連するストリームの前記仕様に従う、転送されたエンドノードのリクエスト各々に含まれている前記時間情報を、前記リクエストの転送に関わるコアネットワークスイッチが管理している少なくとも１つの関連するデータベースに保存するステップと、を有する、前記リソースの予約をスケジューリングする方法。

【請求項2】

前記時間情報は、前記エンドノード及び前記コアネットワークスイッチにより共有されているクロックが提供する時間から導出される、請求項１記載の方法。

【請求項3】

前記時間情報は、ＩＥＥＥ８０２．１Ｑａｔ標準仕様に従うエンドノードリクエストを形成するマルチプルストリームレジストレーションプロトコルデータユニットの新たな個別フィールドとして追加される、請求項１記載の方法。

【請求項4】

前記新たな個別フィールドは、ストリームの識別子を規定する「ＳｔｒｅａｍＩＤ」という名称のフィールドと並列的に、「Ｆｉｒｓｔ Ｖａｌｕｅ」という名称でマルチプルストリームレジストレーションプロトコルデータユニットのサブブランチに付加される、請求項３記載の方法。

【請求項5】

コアネットワークスイッチを有するパケット交換通信網に接続されかつ処理手段を有するエンドノードであって、前記処理手段は、当該エンドノードが仕様で規定されたストリームを受信するためのリソースの予約を要求する毎に、
ｉ）前記ストリームの仕様の情報と当該エンドノードが前記ストリームの受信を開始したい時間を示す時間情報とが含まれているリクエストを生成し、そして、
ｉｉ）前記生成したリクエストを当該エンドノードが接続されているコアネットワークスイッチに送信し、前記リクエストが、ＯＳＩモデルのデータリンクレイヤのレベルで、前記パケット交換通信網における他のコアネットワークスイッチに転送されるようにする、前記エンドノード。

【請求項6】

パケット交換通信網において使用される、エンドノードに接続され、処理手段を有するコアネットワークスイッチであって、前記処理手段は、ストリームの仕様の情報と前記エンドノードが該ストリームの受信を開始し始めることを希望する時間を示す時間情報とが含まれているエンドノードが発行したリクエストを受信した場合に、関連するストリームの仕様に従って前記時間情報を、当該コアネットワークスイッチの関連データベースに保存し、前記コアネットワークスイッチは、前記保存された時間情報が示す時間から、前記要求されたストリームを、ＯＳＩモデルのデータリンクレイヤのレベルで、リクエストを送信したエンドノードに転送する、前記コアネットワークスイッチ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は通信ネットワークの技術分野に関連し、特にパケット交換網におけるリソース割当管理に関連する。

【背景技術】

【0002】

IEEE機構のような近年の標準化の努力によって、OSIレベル2(リンクレイヤ)においてかなり精密なリソース割当法が可能になっている。しかしながらこれらの新たな仕組みは時間的に相関しているものではなく(time correlated)、現在の予約の終了時間を通知したり、あるいは将来の予約を予定することはできない。

【0003】

本願において、「リソース」という用語は、所与のインフラストラクチャを通じて2つのノードの間でなされるデータフロー(又はストリーム)を特徴付ける任意のネットワーク変数(例えば、帯域幅、ジッタ、遅延時間及びレイテンシ等)に関わるものとする。

【0004】

専門的な映像製作及び放送の環境のようなある種の環境は、非常に時間的制約が厳しい環境である。このため、それらが現在パケット交換網で使用しているものを1対1のインフラストラクチャで置き換えることが提案されている。しかしながらそれはシステム全体のパフォーマンスに影響を及ぼし得る全ての遅延時間に配慮することが強いられる。

【0005】

従来のOSIモデル(図1に概略的に示されており、ISO機構により標準化されている)は、7つの階層で通信手段を実現するネットワーキングフレームワークを規定している。階層又はレイヤ1-4は、所与の通信媒体でデータを伝送する機能を有し、レイヤ5-7は使用される通信インフラストラクチャとは無関係に様々なアプリケーションで通信できるようにする。

【0006】

本発明はOSIレイヤ2(すなわち、データリンクレイヤ)のみに関連する。従って以下に説明される全ての手段はOSIレイヤ2において取り扱われる。

【0007】

当業者に知られているように、コアネットワークスイッチは、レイヤ2のヘッダに含まれている情報によりトラフィックを転送するコアネットワーク装置である。この「転送(forwarding)」は、レイヤ3情報による処理に関する「ルーティング」とは異なる概念である。

【0008】

これらのコアネットワークスイッチは、ハードウェアのアドレスを各自の何れかのポートに関連付ける転送テーブルを利用して、トラフィックをアドレスに転送するにすぎない。フレームがコアネットワークスイッチにより受信されると、そのレイヤ2ヘッダは、ハードウェアのアドレスと転送テーブルにおいて関連付けられているエントリを与え、コアネットワークスイッチがフレームを転送しなければならないポートを指定する。これらは低い階層で行われるので、ネットワークスイッチの処理はハードウェアで実現され、各自の遅延時間を克服できるようにする。

【0009】

IEEE802.1の一部であるIEEE802.1オーディオ/ビデオブリッジ(AVB)タスクグループ(TG)は、802ネットワークを介する時間同期した低遅延ストリーミングサービスを可能にする標準仕様を提供することを目的としている。このTGはサブグループ「IEEE802.1AS:Timing and Synchronization」を含み、標準的なレイヤ2を介する時間同期サービスを規定することを目的とし、その時間同期サービスはコンシューマの電子製品の中で最も厳しい条件に適したものである。

【0010】

802.1ASは、LAN媒体から成るブリッジ及び仮想ブリッジローカルエリアネットワーク(Bridge and Virtual Bridged Local Area Network)において時間的制約が厳しいアプリケーション(例えば、オーディオ及びビデオ等)の同期条件が満たされることを保証するのに使用する必要があるプロトコル及び手順を規定しており、例えばIEEE802.3全二重リンクのように伝送遅延は一定でありかつ対称的である。これは、通常の動作中に加えて、ネットワーク素子及びネットワーク再構築に関する以後の追加、削除又は障害の最中にもそうである。802.1AS標準仕様は、IEEE802.1D及び802.1Q標準仕様に適用可能なIEEE1588標準仕様を利用することを規定している。(例えば、UTCやTAIのように認められている時間標準のような)外部から提供されるタイミング信号に同期することはこの標準仕様に規定されていないが、それが排除されているわけではない。

【0011】

IEEE802.1AVBタスクグループは、新たなリソース予約方法に関する他の2つのサブグループ802.1Qat及び802.1Qavを含む。

【0012】

802.1Qatの目的は、オーディオ/ビデオ(AV)ストリームに必要なリソースを保証できるようにするアドミッションコントロールシステムを規定することである。これは既存の高レイヤの仕組みで使用されるプロトコル、手順及び管理オブジェクトを規定し、ブリッジされたローカルエリアネットワークを伝送する特定のトラフィックストリームのためにネットワークリソースを確保できるようにする。それはスイッチに十分なレベルでストリームを識別し、必要なリソースを判定し、そのようなリソースを動的に管理する手段を提供する。

【0013】

この標準仕様は、QoSが保証されたストリームのリソース予約に関するエンドトゥエンドの管理を可能にするシグナリングプロトコルを提供する。このシグナリングプロトコルは、適切なネットワーク要素におけるリソース予約情報の登録、登録抹消及び保存を促進する。このシグナリングプロトコルは、レイテンシ(latency)及び帯域幅の保証を要するブリッジローカルエリアネットワークアプリケーションにおける自動構築にとって重要な要素である。高品質な時間的制約の厳しいストリーミングに対する現在のIEEE802技術によるアプリケーションは、ユーザが被る被害の程度をユーザに知らせることなく、ストリーミングのネットワーク負荷を増加させる。ストリーミングアプリケーションに対してQoSを確実に保証する機能を提供するには、データパス全体に対するネットワークリソースの利用可能性が、通信の実行前に保証されている必要がある。これは、トラフィックストリームの記述及びプロトコルの定義を行い、ストリームのエンドトゥエンドパス(端末間の経路)に対するリソース予約情報を通知することを要する。このプロトコルに基づいてマルチプルレジストレーションプロトコル(Multiple Registration Protocol: MRP)が使用される。これは、スイッチが、時間的な制約(すなわち、限られた遅延時間及び配信時間の変動等に関する制約)、リアルタイムオーディオビデオデータ通信(AVトラフィック)に対するパケット損失の制約等を保証できるようにする。これは、優先度入力測定(priority ingress metering)、優先度再生成及びタイミングを考慮したキュードレイニングアルゴリズム(timing-aware queue draining algorithms)等に関する事項を規定している。仮想ローカルエリアネットワーク(VLAN)タグエンコード優先度は、概して、管理された及び管理されていないキューにおけるフレームを分離するために割り当てられ、有線及び無線のローカルエリアネットワーク(WLAN)における及びその間におけるAVトラフィック及び他のブリッジされるトラフィック双方を同時にサポート(使用)できるようにする。この標準仕様は、(オーディオ及びビデオストリーミングアプリケーションをサポートする装置同士を相互接続するために益々使用されつつある)上記のネットワークスイッチの転送機能の強化を規定し、ローカルエリアネットワークにおいて時間的制約が厳しいトラフィックのパフォーマンスを保証できるようにし、レイヤ2ネットワークに関する遅延、ジッタ及びパケット欠落等を補償する。

【0014】

上記の新たに検討されつつある標準仕様は、(エンドノード及びコアネットワークの機器等のような)ネットワーク要素を正確に同期接続できるようにし、厳しいリソース予約を保証できるようにしようとしている。しかしながら、たとえそれらが制約の厳しいアプリケーションをサポートしようとしていたとしても、同期した任意の機器で共有されるウォールクロック(wall clock)に従ってリソース予約がスケジュールされていないので、既存の技法はそのような制約に十分に対処できていない。

【先行技術文献】

【特許文献】

【0015】

【特許文献1】IEEE802.1AS標準仕様(本願優先日前に公知であるもの)

【発明の概要】

【発明が解決しようとする課題】

【0016】

本発明の課題は、上記のリソース予約及び同期手段に基づいて、リソースの予約及び解放の間の遅延時間を少なくとも最小化しかつリソース割当計画を立てることが可能な時間同期したリソース予約管理の手段を提供することである。そのような時間同期リソース予約管理は、指定されたネットワーク変数(例えば、リソース)を厳格に尊重することを含み、これは、サービス品質(QoS)全体に影響を及ぼさないように、そのような関連する変数値に対する如何なる変更も許容されないことを意味する。

【課題を解決するための手段】

【0017】

一実施例による方法は、
エンドノード及びコアネットワークスイッチを有するパケット交換通信網におけるリソースの予約をスケジューリングする方法であって、
・エンドノードが発行しかつ少なくとも1つのコアネットワークスイッチにより転送されるリクエストの各々に時間情報を含め、仕様で規定されるストリームを該時間情報が示す時間に受信するのに必要なリソースを要求し、
・関連するストリームの前記仕様に従うエンドノードからのリクエスト各々に含まれている前記時間情報を、前記リクエストの転送に関わる前記コアネットワークが管理している少なくとも1つの関連データベースに保存するステップ
を有する、リソースの予約をスケジューリングする方法である。

【図面の簡単な説明】

【0018】

【図1】OSIモデルにおけるレイヤ構成を概略的に示す図。

【図2】イーサーネット/IPネットワークによるスタジオ製作インフラストラクチャの一例を概略的に示す図。

【図3】ウォールクロックとともに簡易なLANトポロジ(左側)及び関連するスパニングツリー表現(右側)を概略的に示す図。

【図4】同期していない及び同期したリリース及び予約リクエストを概略的に示す図。

【図5】タイムスタンプを含むリスナー修正マルチプルストリームレジストレーションPDU(MSRPDU)を概略的に示す図。

【図6】非同期データベースの動作例を概略的に示す図。

【図7】本発明による同期データベースの動作を概略的に示す図。

【発明を実施するための形態】

【0019】

具体的に言えば、本発明は、エンドノードにより発行されかつコアネットワークスイッチにより内部データベースに転送されるリソース予約リクエストに時間情報を含めることを含み、その内部データベースはリソース予約に関する情報を保存するためにコアネットワークスイッチにより管理されている。

【0020】

より具体的に言えば、本発明は、エンドノード及びコアネットワークスイッチ(又は機器その他の装置)を有するパケット交換通信網におけるリソースの予約をスケジューリングする方法を提供し本方法は：
・エンドノードが発行しかつ少なくとも1つのコアネットワークスイッチにより転送されるリクエストの各々に時間情報を含め、仕様で規定されるストリームを該時間情報が示す時間に受信するのに必要なリソースを要求し、
・関連するストリームの前記仕様に従うエンドノードからのリクエスト各々に含まれている前記時間情報を、前記リクエストの転送に関わる前記コアネットワークが管理している少なくとも1つの関連データベースに保存するステップ
を有する方法である。

【0021】

本発明による方法は、以下の特徴を単独で又は組み合わせて包含してもよい：
＿前記時間情報は、前記エンドノード及び前記コアネットワークスイッチにより共有されているウォールクロックが提供する時間から導出されてもよい；
＿前記時間情報は、複数ストリームレジストレーションプロトコルデータユニット(MSRPDU)の新たな個別フィールドとして追加されてもよい。MSRPDUは、802.1Qav標準仕様に従うエンドノードリクエストを形成する。

【0022】

＿＿前記新たな個別フィールドは、ストリームの識別子を規定する「StreamID」という名称のフィールドと並列的に、「First Value」という名称でマルチプルストリームレジストレーションプロトコルデータユニットのサブブランチに付加されてもよい。

【0023】

本発明は更にエンドノードを提供し、本エンドノードはコアネットワークスイッチを有するパケット交換通信網に接続されかつ処理手段を有するエンドノードであって、前記処理手段は、当該エンドノードが仕様で規定されたストリームを受信(又は加入)するのに必要なリソースの予約を要求する毎に、i)ストリームの仕様の情報とストリームの受信を開始し始めることを希望する時間を示す時間情報とが含まれているリクエストを生成し、及びii)生成した前記リクエストを当該エンドノードが接続されているコアネットワークスイッチに送信し、前記リクエストが前記パケット交換通信網における他のコアネットワークスイッチに転送されるようにする、エンドノードである。

【0024】

前記処理手段は、前記パケット交換通信網の前記コアネットワークスイッチ及び当該エンドノードにより共有されているウォールクロックが提供する時間から、前記時間情報を導出してもよい。

【0025】

本発明は、パケット交換通信網において使用される、エンドノードに接続されかつ処理手段を有するコアネットワークスイッチを更に提供し、当該コアネットワークスイッチは処理手段を有し、前記処理手段は、ストリームの仕様の情報と該ストリームの受信を開始し始めることを希望する時間を示す時間情報とが含まれているエンドノードが発行したリクエストを受信した場合に、関連するストリームの仕様に従って前記時間情報を、当該コアネットワークスイッチの関連データベースに保存し、保存された前記時間情報が示す時間から、要求されたストリームを、リクエストを送信したエンドノードに転送する、コアネットワークスイッチである。

【0026】

本発明による他の形態や利点は以下の詳細な説明及び添付図面から更に明らかになるであろう。

【実施例1】

【0027】

添付図面は本発明の説明を補完するだけでなく、必要に応じて定義を提供することにも資する。

【0028】

以下の説明において、本発明が使用されるパケット交換(通信)網は、専門的なオーディオ/ビデオ制作施設に配備されたイーサーネット/IPローカルネットワークインフラストラクチャであるものとして説明される。そのようなイーサーネット/IPローカルネットワークインフラストラクチャの具体例は図2に示されている。

【0029】

このインフラストラクチャは、i)データストリームの形式でオーディオ及び/又はビデオコンテンツを生成又は配信する第1のエンドノード(例えば、カメラ、サーバ、ビデオテープレコーダ(VTR)、マイクロフォン、オーディオミキサ、スイッチ等)、ii)ビデオコンテンツ又はテレビジョン番組を表示したり、或いはオーディオコンテンツを配信する第2のエンドノード(例えば、テレビジョン又は拡声スピーカ等)及びiii)第1のエンドノードが提供したデータストリームをパケット又はプロトコルデータユニット(PDU)により転送するコアネットワーク装置(又はブリッジ)(例えば、イーサネット（登録商標）スイッチ)を特に有する。

【0030】

プロトコルデータユニット(PDU)は、接続されたホスト(又はエンドノード(Hi))が送信したプロトコルパケットであることに留意を要する。更に、ブリッジされたプロトコルデータユニット(BPDU)は、接続されたコアネットワークスイッチ装置(Sj)が送信したプロトコルパケットである。

【0031】

トーカー(talker)と言及される第1のノードが、リスナー(listener)と言及される他の(第2の)エンドノードにより受信されるデータストリームを提供しようとする場合、第1のエンドノードはストリームデクラレーション(stream declaration)を発行又は通知する。ストリームデクラレーションは、接続されているコアネットワーク装置(イーサーネットスイッチ等)が、データストリームの仕様情報(TSpec)(例えば、トーカーId、最大帯域幅及び最大遅延時間等)を取得し、リソースの予約に関連する自身の内部データベースを初期化できるようにする。しかしながら、コアネットワーク装置各々が各自の内部データベースを初期化した場合、如何なるリソースも未だ予約されていないことになる。

【0032】

リスナーが過去に宣言されたストリームを受信するように「ジョイン(join)」リクエストを発行した場合、完全なリソース要約及びTSpec制約検査が実行される。この検査において、(過去に発行された)リソース予約が、現在の残りのリソース量と比較され、そして予約が継続される又はされないことになる。この状況については図3及び図4を参照しながら後述される。

【0033】

図3は、上記のリソース予約プロセスを行う簡易な同期ネットワークインフラストラクチャを概略的に示す。このインフラストラクチャにおいて、エンドノード(又はユーザ)ホストi(又はHi、例えば、i=1ないし3である)は、イーサーネットスイッチSj(例えば、j=1又は2)を介して互いに結合されている。図3の右側に示されているインフラストラクチャのスパニングツリー表現は、スイッチポートの接続状況を示す。

【0034】

例えば、エンドノードH2及びH3は、過去に宣言されている各自の(データ)ストリームを有するトーカーである。エンドノードH1は、H2ストリーム及び/又はH3ストリームを受信するのに必要なリソースを要求するリスナーである。

【0035】

しかしながら、スイッチS1及びS2の間のリンクがH2及びH3のストリームを同時にはサポートできなかった場合、リスナーは、最初に要求したストリーム(例えば、H2ストリーム)を解放して第2のもの(例えば、H3ストリーム)を受信し、最大の帯域幅を超えないようにする必要がある。このため、一連の解放(リリース)及び予約の処理に起因して導入される余分な遅延に起因して、2つのソースH2及びH3の間で鮮明なビデオの切替を行うことができないかもしれない。図4は、非同期式及び同期式の解放及び予約を時間の関数として示す図である。

【0036】

上述したように、802.1Qat及び802.1Qav標準仕様により提案されているようなリソース予約方法は、解放及び予約のリクエストの変更を許容しない。

【0037】

にもかかわらず、本方法は、(インフラストラクチャ又は)ネットワークの接続ノード全ての間で非常に正確な時間を設定できるようにする。例えば、イーサーネット(802.3)及びWifi(802.11)に関するIEEE1588プロファイルを規定する新たなIEEE802.1ASドラフト及びIEEE1588標準仕様は、1つのクロックドメインを規定する7ホップのブリッジトポロジにおいて、1μsの精度を達成できるようにする。

【0038】

この時間同期は、タイムスタンプを利用して、少なくとも1つのストリームへの加入を終了する及び/又は少なくとも他のストリームへの加入を開始することを考慮して、リスナノードが解放/予約リクエスト(又はメッセージ)を希望する時間(日)を判定できるようにする。

【0039】

「解放/予約リクエスト」という表現は、ストリームの解放リクエスト又はストリームの予約リクエストを意味してもよいし、或いは第1のストリームのリソースを解放して第2のストリームのリソースの予約を意図したリクエストを意味してもよい。

【0040】

より正確に言えば、本発明は少なくとも1つの時間情報(又はタイムスタンプ)を解放及び/又は予約リクエストに(例えば、プロトコルデータユニット(PDU)内に)含め(追加し)、全てのリスナーな解放及び/又は予約リクエストを同期させる。タイムスタンプは、好ましくは、接続された全ての装置(エンドノード及びコアネットワーク装置)により共有されるウォールクロック(Wall Clock：WC)が提供する時間から導出され、その幅は対象のアプリケーションが必要とする精度に合致していなければならない。

【0041】

これらのタイムスタンプの追加及び時間の導出はエンドノードに関連する(すなわち、エンドノードHiの中に設けられている)第1の処理手段により実行されてもよい。第1の処理手段は、少なくとも部分的にソフトウェアモジュールにより、或いは電子回路又はハードウェアモジュールにより、或いはハードウェア及びソフトウェアモジュールの組み合わせにより形成される。

【0042】

図5は、802.1Qatドラフトにより規定されているマルチプルストリームレジストレーションPDU(MSPRDU)を、802.1ASタイムスタンプを含むように修正した非限定的な例を示す。この例の場合、802.1ASタイムスタンプは「PreciseTimeStamp」と言う名称のフィールドに設けられ、このフィールドは、「First Value」と言う名称のサブブランチにおいて「StreamID」という名称のフィールド(MSRPDUに属するストリームの識別子を規定する)と並列的に設定されている。図5に示す例の場合、タイムスタンプ「PreciseTimeStamp」は80ビットで規定されている。これは、802.1AS標準仕様におけるタイムスタンプが80ビッットで規定されていることに起因する。しかしながら、他の標準仕様に従うタイムスタンプを規定するために他のビット数が使用されてもよい。

【0043】

図5の例の場合、「PreciseTimeStamp」のフィールドが「FirstValue」サブブランチに追加されかつ80ビットで規定されるので、個のサブブランチの「ListeneraskingFailed」のフィールドを規定するバイト数を修正する必要がある。すなわち、それは18バイト(48ビット＋16ビット＋80ビット＝144ビット＝18バイト)に等しい。更に、従来の802.1QatのMSRPDUに対するこの修正は、「AttributeLength」及び「AttributedListLength」のような何らかの他のフィールドを規定するバイト数を修正及び/又は調整することを強いる。例えば、AttributeLengthのフィールドを規定するバイト数は18に設定され、AttributeListLengthのフィールドを規定するバイト数が24に調整されてもよい。

【0044】

首尾一貫した又は矛盾のない厳格なリソース管理を保証するために、コアネットワーク装置の各々は、リソースの解放/予約リクエスト(又はメッセージ)が何れかのポートで受信される度に、自身の内部データベースを更新しなければならない。

【0045】

上述したように、コアネットワーク装置Sjがトーカーの通知メッセージ(又はトーカーの通知デクラレーションTA)を受信した場合、コアネットワーク装置は、そのトーカー通知メッセージを隣接する他のコアネットワーク装置(例えば、スイッチ)及びエンドノードに転送する前に、受信したトーカーの通知メッセージで規定されているストリーム仕様(TSpec)を登録する。

【0046】

更に、コアネットワーク装置Sjが「リスナーレディ」リクエスト又はデクラレーション(リスナーのエンドノードHiが指定されたストリームを受信する準備が整っていることを示す)を受信した場合、コアネットワーク装置は、内部データベースにおいて、その指定されたストリームを規定しかつトーカーノードが過去に送信した情報を含んでいるか否かをトーカーの通知メッセージを用いて検査し、含んでいた場合、データストリームの仕様(特に、帯域幅及び最大遅延時間(待ち時間))の観点から、受信したリスナーのレディリクエストのステータスが、指定されたストリームについて保存されているデータストリーム仕様(TSpec)に適合するか否かを確認する。

【0047】

適合していた場合、コアネットワーク装置は、対象の登録されたトーカー通知メッセージに関連するポートにより、リスナーレディリクエストを転送する。

【0048】

適合していなかった場合、リクエストは拒否され、拒否する通知がトーカーノード及びリスナーエンドノードに転送される。そのように拒否する状況の具体例は、図6左側に示されている非同期内部データベースの3つの進展図(1)、(2)及び(3)に示されている。この例の場合、TAはトーカーの通知メッセージ(又は、トーカー通知)を示し、LRはリスナーのエンドノードが送信したリソースの予約(又は「リスナーレディ」)リクエストであって、要求に応じることができないものを示し、LF(又は「リスナーフェイル(Listener Failed)」)はストリームを要求したが不適合であることに起因してそれを受信できないリスナーノードを示す。コアネットワーク装置の内部データベースの第1段階(1)において、H1はリスナーのエンドノードを示し、H2は第1のストリームを送信する準備が整ったことを通知した第1のトーカーエンドノードを示し、H3は第2のストリームを送信する準備が整ったことを通知した第2のトーカーエンドノードを示す。コアネットワーク装置の内部データベースの第2段階(2)において、コアネットワーク装置は、第1の(H2の)ストリームを指定するリスナーの予約リクエスト(LR)をエンドノードH1から受信し、そのリクエストを満足させることが可能であることを確認して登録する(LR)。コアネットワーク装置の内部データベースの第3段階(3)において、コアネットワーク装置は、第2の(H3の)ストリームを指定するリスナーの予約リクエストをエンドノードH1から受信し、そのリクエストを満足させることは不可能であることを確認して登録する。すなわち、リスナーエンドノードH1の最後の予約リクエストは拒否される。

【0049】

このように拒否する状況を回避するため、本発明において、異なるリスナーエンドノードリクエストのタイムスタンプが存在しなかった場合、リスナーエンドノードH1は、第1の(H2の)リクエストされたストリームを解放して第2の(H3)のものを受信しなければならず、これは追加的な遅延を導入してしまう。そのような解放の状況の具体例は、図6右側に示す非同期の内部データベースにおける4つの進展図(1’)、(2’)、(3’)及び(4’)に示されている。

【0050】

コアネットワークの内部データベースの第1段階(1’)において、H1はリスナーエンドノードを示し、H2は第1のストリームを送信する準備が整ったことを通知した第1のトーカーエンドノードを示し、H3は第2のストリームを送信する準備が整ったことを通知した第2のトーカーエンドノードを示す。コアネットワーク装置の内部データベースの第2段階(2’)において、コアネットワーク装置は、第1の(H2の)ストリームを指定する第1のリスナー予約リクエスト(LR)をエンドノードH1から受信し、その第1のリクエストを満足させることが可能であることを確認して登録する(LR)。コアネットワーク装置の内部データベースにおける第3段階(3’)において、コアネットワーク装置は、第2の(H3の)ストリームを指定する第2のリスナー予約リクエストをエンドノードH1から受信し、そのリクエストを満足させることは不可能であることを確認する。そして、コアネットワーク装置はリスナーエンドノードH1にその状況を通知し、リスナーエンドノードH1は第1の(H2の)ストリームについての第1の予約リクエストを解放するストリーム解放リクエストを送信する。そして、コアネットワーク装置は、LR情報をTA情報で更新することで、(3’)の状態の内部データベースを更新する。コアネットワーク装置の内部データベースの第4の状態(4’)において、コアネットワーク装置は、第2の(H3の)ストリームを指定する第2のリスナー予約リクエストをエンドノードH1から受信し、その第2の予約リクエストを今度は満足できることを確認して登録する。

【0051】

本発明によれば、リスナーエンドノードリクエストの中にタイムスタンプを導入することで、コアネットワーク装置の各々は、各自のタイムスタンプに従ってリクエストを、すなわちリクエストが処理されるべき時間に従ってリクエストを、処理することができる。言い換えれば、第1の時間に送信されたリスナーのエンドノードリクエストの各々は、エンドノードの第1の処理手段により追加されたタイムスタンプを含み、そのタイムスタンプは、後に生じる第2の時点を規定しており、その第2の時点においてリスナーエンドノードリクエストが考慮又は処理されることになる。

【0052】

コアネットワークスイッチSjがエンドノードHiにより発行されたリクエストを受信し、そのリクエストが、ストリームの仕様の情報とエンドノードがそのストリームを受信し始めることを希望する時間を表す時間情報とを含んでいた場合、コアネットワークスイッチ(Sj)に関連する第2の処理手段は、関連するストリーム仕様情報とともにその時間情報を関連するデータベースに保存し、関連するコアネットワークスイッチが、(ストリームに)対応する保存されている時間情報により示されている時間から、要求を行っているエンドノードHiに要求されているストリームを転送できるようにする。

【0053】

第2の処理手段は関連するコアネットワークスイッチSjの中に設けられている。第2の処理手段は、少なくとも部分的にソフトウェアモジュールにより形成されていてもよいし、あるいは電子回路又はハードウェアモジュールにより形成されていてもよいし、或いはハードウェア及びソフトウェアモジュールの組み合わせにより形成されていてもよい。

【0054】

図7は、本発明に従って登録されたタイムスタンプに基づく同期した処理により、コアネットワーク装置の内部データベースにおける進展図(1)、(2)及び(3)の具体例を示す。コアネットワーク装置の内部データベースにおける第1段階(1)において、H1はリスナーエンドノードを示し、H2は時間T0から第1のストリームを送信する準備が整ったことを通知した第1のトーカーエンドノードを示し、H3は時間T0から第2のストリームを送信する準備が整ったことを通知した第2のトーカーエンドノードを示す。コアネットワーク装置の内部データベースにおける第2段階(2)において、コアネットワーク装置は、i)第1の(H2の)ストリームを指定しかつ或る時間を規定するタイムスタンプ(T1＞T0)を含む第1のリスナー予約リクエスト(LR)をエンドノードH1から受信し、エンドノードH1は第1の予約リクエストがその或る時間に満たされることを希望しており、コアネットワーク装置は、ii)その第1の(H2の)予約リクエストを時間T1に満足できることを確認して登録する。コアネットワーク装置の内部データベースにおける第3段階(3)において、コアネットワーク装置は、i)時間T3を規定するタイムスタンプ(T3＞T1)を含む第2のリスナー解放及び予約リクエストをエンドノードH1から受信し、その時間T3においてエンドノードH1は第1の（H2の）ストリームに関する第1の予約リクエストが解放されかつ第2の(H3の)ストリームについてリソース予約が実行されることを希望しており、コアネットワーク装置は、ii)時間T3にその最新の(H3の)リソース予約を実行できることを確認及び登録する。

【0055】

本発明は一例に過ぎない上記の方法、エンドノード及びコアネットワークスイッチに限定されず、当業者によって想定される全ての代替例は、添付の特許請求の範囲内に包含されることが想定されている。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】