JP3677153B2 - 蓄積装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、受信した放送を蓄積する蓄積装置に関する。
【０００２】
【従来の技術】
近年、マルチメディアという言葉に代表されるように、電子機器のデジタル化が急速に進行している。この傾向は、まずオフィス環境で始まっている。具体的に言うと、まずハードウエアとしては、パソコンの導入、ＯＡ機器のデジタル化およびそれらのネットワーク化という形で進行している。また、ソフトウエアとして、ホストによる（あるいはライトサイジングされてパソコン等に移行されつつある）基幹業務や、ワープロ、表計算などのソフトウエアあるいはＷＷＷ等のインターネットアプリケーション等、その発展はとどまるところを知らない。
【０００３】
この動きは、家庭においても見られる。すなわち、家庭においても、ＡＶ機器のデジタル化（ＤＶＤ、デジタルＶＴＲ、デジタルビデオカメラ等）や、放送のデジタル化あるいはＯＣＮ等のインターネットアクセス等の形で、デジタル化の進行は着実に進んでいる。
【０００４】
オフィス環境と同様に、これらの波はネットワーク化へと今後向かっていくことが考えられる。すなわち、情報・通信・放送といった種々の分野の技術がデジタル化によって束ねられ、ネットワーク化によって相互乗り入れを始めていくと言われている。
【０００５】
このためのネットワーク技術としては、種々の候補が有る。例えば、イーサネットは、オフィス環境にて圧倒的な実績を持っており、家庭でのパソコンネットワークにおいても、その有力候補であろう。また、ＡＴＭも有力な候補である。これは、インフラの構築側（電話会社やＣＡＴＶ等）が、高速、リアルタイム、広帯域といったＡＴＭの特徴に注目し、この技術を使ってインフラを構築していこうというのが一般的な動きだからである。
【０００６】
これらの候補に加えて、最近、ＩＥＥＥ１３９４なるネットワーク技術（バス技術）が注目を集めている。これは、高速、リアルタイム（ＱＯＳ保証）、プラグアンドプレイ等の数々の注目すべき特徴を持っており、特にデジタルＡＶ機器同士の接続方式の最有力候補としてＡＶ機器業界等から大変な注目を集めている。これにひきづられるように、パソコンなどのコンピュータ業界も、この技術への注目が集まりはじめた。
【０００７】
当初は、家庭向けのデジタル機器の普及に伴い、それらの機器の相互接続が、ユーザの好み・要望により、これらの数々のネットワーク技術により実現されていくと考えられる。このようにして、徐々に家庭内にデジタルネットワークの雛形が誕生していく。
【０００８】
ある程度の家庭内ネットワーク、それも広帯域の家庭内ネットワークが存在することが前提と考えられれば、家庭と家庭を結ぶ公衆網についても、広帯域のものが出現すると期待される。しかしながら、この部分については、莫大な投資がかかり、かつ、その公衆網上で展開されるサービスが不透明なため、簡単にそのようなインフラが構築されるとは考えにくい。
【０００９】
また、デジタル放送など、映像分配のインフラが急速に普及しようとしている。例えばデジタル衛星放送では既に１００チャンネル近くの映像サービスを既に開始している。このようなデジタル放送インフラの急速な普及を考えると、広帯域通信インフラの主な用途は映像サービスであると単純に考えられるため、広帯域の通信インフラが整備がさらに遅れる可能性は否定できない。
【００１０】
しかしながら、広帯域通信の需要は存在する。テレビ電話や、ビデオのネットワークを介したダビング等はその典型的なアプリケーションである。
【００１１】
そのための解決策の一つとして、マンションやアパート等の集合住宅内に広帯域のネットワークを敷設する方法が考えられる。この方法では、公衆網の整備と異なり、公道上での架空／地中回線の設置などのコストがかからないことや、集合住宅のオーナが集合住宅の付加価値を高めるためにそういった設備の導入を積極的に図ることが出来ると考えられることから、公衆網とは別に、集合住宅内のみとはいえ、家庭間通信のインフラの候補としてあげることができよう。
【００１２】
しかしながら、集合住宅内の広帯域網を構築するにあたり、ビデオ伝送等を有効に利用する方法、各家庭でのセキュリティを確保する方法、機器等の資源を低コスト化する方法などが提供されていなかった。
【００１３】
ところで、キャンパス網や企業網のバックボーン、ネットワークキャリアやインターネットサービスプロバイダー（ＩＳＰ）のネットワークでは、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）などのレイヤ３パケット通信を行うルータ等のノード装置において、ノード間で特定のパケットストリームに特定のチャネル識別子（ラベル）を割り当てるための制御情報を交換し、各ノードでは個々のストリームに対して割り当てた入力側のラベル（および入力インタフェース）と出力側のラベル（および出力インタフェース）とを記憶し、記憶したラベル値の対応関係をもとに実際のパケット転送処理（スイッチング処理）を行うことが可能であり、ラベルスイッチングと呼ばれている。ラベルは一般に固定長であり、ラベルスイッチングによるパケット転送は、従来の可変長のパケットヘッダ情報（宛先ＩＰアドレスプレフィクスなど）を解析してパケット転送する場合に比べて高速な処理が可能であるとともに、より柔軟な経路制御が可能になる。ラベルスイッチングの具体的適用方法には、ＡＴＭやフレームリレーなどの既存のスイッチングネットワークに適用する方法と、新たにラベルスイッチのためのラベルヘッダを定義してＰＰＰ ｏｖｅｒ ＳＯＮＥＴリンクやＩＥＥＥ８０２．３／イーサネットなどのＬＡＮ上にスイッチを接続する方法とが考えられる。
【００１４】
このラベルスイッチングによりパケット転送されるパスをラベルスイッチングパス（ＬＳＰ）と呼ぶ。ＬＳＰの始点となるノード（ルータあるいはホスト）では送信するパケットのヘッダ情報から定義されるパケットストリーム毎に同一のラベル値を付与して送信し、中継点となるルータでは受信したパケットのラベル値を参照して送出すべきインタフェースおよびラベル値を決定、付与して送信し、終点となるノードでは受信したパケットのラベルを削除しヘッダを参照して送出すべきインタフェースを決定、送信する。
【００１５】
ＬＳＰを利用してパケットを転送することにより、ＬＳＰの中継点のルータでは、レイヤ３および上位層のヘッダを参照することなしにパケット転送を行うことが可能になり、転送性能の向上や経路制御の柔軟性などのメリットが得られる。しかしその反面、以下のような問題点が存在する。
【００１６】
まず、従来パケット毎に行っていたフィルタリング処理（レイヤ３および上位層のヘッダ情報に基づき、受信パケットをさらに転送するか否かを判断する処理）がＬＳＰの中継ルータにおいて行えなくなる。このフィルタリング処理は、あるセグメント（以下では、特定のキャンパス網、企業網、ＩＳＰ網などのような、同一の管理ポリシーにより運営される物理的あるいは論理的ネットワークの単位をセグメント（ネットワークセグメント）と呼ぶことにする）へのパケットの流入やあるセグメントからのパケットの流出を、セキュリティ上の理由により特定の送信元や宛先のもの、特定の上位層プロトコルのものに制限するために行うことが主な目的であるが、ＬＳＰの中継点がセグメントの境界であった場合にパケットヘッダが参照できないため、これが行えなくなってしまう。
【００１７】
また、従来隣接するセグメント同士がお互いからのパケットの中継を行うか否かのポリシーを互いの契約等により決定し、その結果に基づきルーティングプロトコルを通してパケット転送可否の制限（ピアリングの制御）を行っている（特定の隣接セグメントに対してルーティング情報を与えない、あるいはルーティング情報とともに自分のセグメント通過に対する希望（プレファレンス）を伝えることなどにより）。セグメントにまたがるＬＳＰ設定に関しても、そうしたルーティングプロトコルを通した制限を行うことは可能である。しかしながら、ルーティングプロトコルとは別な条件により、隣接セグメントに対してＬＳＰの設定を制限することが現状では行うことができない。例えば、ラベルスイッチングのためのラベルリソースは有限であるため、ある隣接セグメントに対して、通常のルータが行うホップバイホップによるパケットの中継転送は行うが、ＬＳＰによるパケット転送（セグメントにまたがるＬＳＰの設定）は制限したいというようなポリシー制御を実行したいケースが考えられるが、こうしたＬＳＰ設定に関するポリシーを現在のルーティングプロトコルにより実現することはできない。
【００１８】
【発明が解決しようとする課題】
従来、放送された映像等のデータを、選択的に蓄積し、要求に応じて配送できる環境を提供できる蓄積装置は提供されていなかった。
【００１９】
本発明は、上記事情を考慮してなされたもので、放送された映像等のデータを、選択的に蓄積し、要求に応じて配送できる環境を提供できる蓄積装置を提供することを目的とする。
【００２３】
【課題を解決するための手段】
本発明（請求項１）に係る蓄積装置は、放送を受信する第１のインタフェースと、複数のユーザ側の端末が接続されたネットワークと接続する第２のインタフェースと、前記第２のインタフェースを介して受信した、前記端末からのインターネットパケットを処理する処理手段と、前記第１のインタフェースを介して受信した放送のうち、蓄積すべき部分を選択する第１の選択手段と、前記第１の選択手段により選択された放送を蓄積する蓄積手段と、前記蓄積手段に蓄積されたデータのうち、前記第２のインタフェースから送出するべきデータを選択する第２の選択手段と、前記処理手段による前記処理を経て渡される前記インターネットパケットに含まれる、前記蓄積すべき部分に係る要求の内容に基づいて、前記第１の選択手段における選択対象を制御する第１の制御手段と、前記処理手段による前記処理を経て渡される前記インターネットパケットに含まれる、前記送出するべきデータに係る要求の内容に基づいて、前記第２の選択手段における選択対象を制御する第２の制御手段とを含むことを特徴とする。
本発明によれば、放送波より受信した映像を、ネットワークの種別に関わらずあるいはネットワークが異種ネットワークの相互接続である場合においてすら、選択蓄積、選択送信ができる環境を提供することが可能となる。これは、選択蓄積、選択送信を行うプロトコルとして、ネットワーク種別を問わないインターネットを採用していることにより達成されるものである。
本発明（請求項２）に係る蓄積装置は、請求項１に記載の蓄積装置において、前記第１の選択手段及び第２の選択手段における選択対象の選択の際に、前記処理手段にて行われる前記インターネットパケットの処理は、ＨＴＴＰに基づいて行われることを特徴とする。
本発明（請求項３）に係る蓄積装置は、請求項１に記載の蓄積装置において、前記第１の選択手段により選択され、前記蓄積手段に蓄積される放送は、複数チャンネルの放送を含むことを特徴とする。
本発明（請求項４）に係る蓄積装置は、請求項１に記載の蓄積装置において、前記第１の選択手段により選択され、前記蓄積手段に蓄積される放送の少なくとも一部は、デジタル放送であることを特徴とする。
本発明（請求項５）は、請求項１に記載の蓄積装置において、前記第２のインタフェースから前記蓄積されたデータを送信するのに先立って、該第２のインタフェースから該データを受信すべき端末に至る経路の少なくとも一部の通信資源の確保を行う通信資源確保手段をさらに備えたことを特徴とする。
本発明によれば、映像通信に一般に不可欠と考えられる通信路の通信資源の確保を、該蓄積装置から受信ノードに至る経路の少なくとも一部において行うことが可能となり、さらにこれをインターネットプロトコルにおいて行うこととすれば、通過するネットワーク種別を問わず、上記通信資源確保を行うことができるようになる。
本発明（請求項６）は、請求項１に記載の蓄積装置において、データの送信先またはデータ送信の依頼者となるユーザまたは端末毎に、前記第２のインタフェースを介して前記蓄積されたデータを送信する際に同時に使用可能な通信資源量と現在そのユーザまたは端末について使用している通信資源量とを記した管理テーブルをさらに備えたことを特徴とする。
本発明によれば、蓄積装置は、あるユーザ（例えば集合住宅の各住宅の代表者）または端末について、使用することが許可された通信資源量と、実際に使用している通信資源量とを、逐次把握することができるようになると同時に、このテーブルの値を適宜比較、使用することにより、そのユーザについての通信資源使用要求の使用許可制御に用いることも可能となる。
本発明（請求項７）に係る蓄積装置は、請求項１に記載の蓄積装置において、データ送信要求を受ける前または受けた後に、該データ送信要求の要求元のユーザまたは端末との間で認証手続きを行うことを特徴とする。
本発明（請求項８）に係る蓄積装置は、請求項１に記載の蓄積装置において、前記蓄積装置は、集合住宅内のバックボーン網に接続され、前記第２の選択手段は、前記集合住宅内の個々の住宅の端末からの要求に従って、選択対象を選択することを特徴とする。
【００９８】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
【００９９】
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【０１００】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【０１０１】
本発明は、マンション、アパート、寮等のように複数の住宅またはこれに相当するものが１つの建物に集合されている集合住宅（ホテル等の集合住宅的な宿泊施設も集合住宅と呼ぶものとする）ならばどのような形態のものにもまたいくつの住宅（あるいは客室などこれに相当するもの；以下、住宅や客室などを含めて住宅等と言う）を収容するものであっても適用可能であり、またその集合住宅に収容されるすべての住宅等を対象とするのも一部の住宅等を対象とするのも任意である。本実施形態では説明を簡単にするために４戸分の住宅を収容するマンションを例にとって説明する。
【０１０２】
図１に、本発明の一実施形態に係るシステムのうち集合住宅のバックボーン網の部分の一構成例を示す。
【０１０３】
このマンションには、４戸分の住宅が収容されているとともに、それらの住宅（以下、家庭と言う）とは別に管理室が設けられている。また、４戸分の住宅すべてにシステムを導入するものとする。
【０１０４】
このマンションには、デジタル衛星放送受信用の共同アンテナ１０１が設けられており、共同アンテナ１０１により受信された放送信号は、同軸ケーブルを通り、例えば管理室内に設けられた分配器１０２を介して、同軸ケーブル経由で各家庭１〜４に分配される。各家庭１〜４に入り込んだ同軸ケーブルはそれぞれ分配器１０３〜１０６で終端される。各分配器１０３〜１０６からは、各家庭のテレビやセットトップボックスあるいはＶＴＲ等に接続される。なお、本発明はデジタル衛星放送への適用に限定されるものではなく、デジタル地上波放送、デジタルＣＡＴＶ放送などを受信する場合にももちろん適用可能である。
【０１０５】
分配器１０２からは、上記の他に、管理室内のデジタル放送蓄積サーバ１０７にも同軸ケーブルが分岐される。
【０１０６】
次に、図１に示されるように、このマンションには「マンションバックボーンネットワーク」としてＩＥＥＥ１３９４バスが敷設されている。すなわち、ＩＥＥＥ１３９４バスを、管理室内のデジタル放送蓄積サーバ１０７およびインターネットサーバ１０８ならびに各家庭に配置されたホームルータ１０９〜１１２を１３９４ノードとする、ネットワークとみなすことができる。
【０１０７】
詳細は後述するが、放送蓄積サーバ１０７は、受信した放送のうち所定の番組等を蓄積し、各家庭内の端末からの要求に応じて該当するデータを配送する。ホームルータ１０９〜１１２は、マンションバックボーンネットワークと家庭内ネットワークを接続する。インターネットサーバ１０８は、インターネットにアクセスする際の代理サーバとＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）の働きをする。なお、インターネットへのアクセスを考えない場合、インターネットサーバ１０８を省いてもかまわない。この場合、例えば、デジタル放送蓄積サーバ１０７とホームルータ１０９を接続する。
【０１０８】
図１には示していないが、上記の設備の他に電話もしくはＩＳＤＮの配線が、ネットワークの配線として各家庭まで敷設されていてる場合もある（通常、このような場合が多いと考えられる）。
【０１０９】
なお、本実施形態では、４つのホームルータ１０９〜１１２が接続されているが、もちろん、３台以下であってもよいし、より規模の大きい集合住宅等においてより多数のホームルータを接続してもよい。
【０１１０】
次に、本実施形態に係るシステムのうち家庭内システムについて説明する。家庭内システムは、本システムを導入する各家庭ごとに設けられ、バックボーン網を通じて管理室システムおよび他の家庭内システムと相互に通信可能となる。
【０１１１】
図２に、本家庭内システムのうち配線システムの一構成例を示す。なお、図２は、家庭１を例にとってその様子を示しているが、他の家庭２〜４もその間取り等に応じて具体的な構成が変わり得る以外は同じような考え方で構成される。
【０１１２】
図２に示されるように、家庭１は、その内部が、応接間、子供部屋、居間、台所等に区切られている。管理室内の分配器１０２から同軸ケーブルを使って分配されてきたデジタル放送波は、家庭１の分配器１０３を介して、各部屋すなわち応接間、子供部屋、居間、台所の各情報コンセント２０１〜２０４に分配されるものとする。他の家庭２〜４についても、デジタル放送波は、管理室内の分配器１０２から同軸ケーブル、そして分配器を介して、各部屋に分配される。
【０１１３】
ここで、情報コンセント２０１〜２０４について簡単に説明する。図３に、本実施形態の情報コンセントの概観図の一例を示す。本情報コンセントには、放送波受信のための同軸ケーブルのコネクタ２１１と、家庭内バックボーンネットワークであるＩＥＥＥ１３９４のコネクタ（例えば電気コネクタもしくは光コネクタ）２１２との少なくとも２つのコネクタが設けられている。なお、この情報コンセントは、放送波受信のためのコネクタとして複数個のコネクタ（例えば、通信衛星用と衛星放送用と地上波用の各コネクタ等）を備えているものであってもよいし、１または複数の放送波受信のためのコネクタとＩＥＥＥ１３９４のコネクタに加えて電話用のコネクタおよび／またはイーサネットのコネクタを備えているものであってもよいし、その他にも種々の形態が考えられる。
【０１１４】
上記のように本情報コンセントは少なくともＩＥＥＥ１３９４のコネクタを有しており、これらＩＥＥＥ１３９４のコネクタが相互に接続されて、家庭内バックボーン（ＩＥＥＥ１３９４バックボーン）を構成している。図２の家庭１の例の場合、ホームルータ１０９から、居間の情報コンセント２０３、台所の情報コンセント２０４、子供部屋の情報コンセント２０２、応接間の情報コンセント２０１が、相互にＩＥＥＥ１３９４ケーブルで相互接続されており、ホームルータ１０９および情報コンセント２０１〜２０４のそれぞれがＩＥＥＥ１３９４ノードとして稼動している。他の家庭２〜４でも同様にホームルータおよび情報コンセントのそれぞれがＩＥＥＥ１３９４ノードとして稼動している。
【０１１５】
なお、これらのＩＥＥＥ１３９４ケーブルおよび同軸ケーブルは、各家庭の壁の裏側等に配線されていることが望ましい。
【０１１６】
さて、各家庭では、各部屋に家庭内システムを構成する各種装置が配置され、分配器および／または情報コンセントに接続されている。以下では、家庭１を例にとって各部屋に配置されている各装置について説明する。図４に、家庭１の各部屋に配置されている各装置の例を示す。
【０１１７】
図４に示されるように、放送系の配線につながる形として、応接間の情報コンセント２０１の同軸ケーブルコネクタにＳＴＢ（セットトップボックス）内蔵テレビ４０１が、子供部屋の情報コンセント２０２の同軸ケーブルコネクタにセットトップボックス４０４が、居間の情報コンセント２０３の同軸ケーブルコネクタにセットトップボックス４０７が、それぞれ接続されている。接続ケーブルは同軸ケーブルである。
【０１１８】
一方、１３９４系の配線につながる形として、子供部屋の情報コンセント２０２の１３９４コネクタにセットトップボックス４０４、デジタルＶＴＲ４０３、ＰＣ４０２がそれぞれディージチェーン状に接続されている。また、居間の情報コンセント２０３の１３９４コネクタにＤＶＤ４０６、セットトップボックス４０７が、それぞれディージチェーンで接続されている。接続ケーブルは１３９４ケーブル（例えば電気ケーブルもしくは光ケーブル）である。
【０１１９】
また、各セットトップボックス４０４，４０７は、ＡＶコネクタ（アナログコネクタ；映像端子と音声端子）も有しており、それぞれＡＶコネクタを通してテレビ４０５，４０８とも接続されている。
【０１２０】
以上から、本実施形態におけるセットトップボックス４０４，４０７は、それぞれ、同軸ケーブルコネクタ、１３９４コネクタ、ＡＶコネクタの少なくとも３種のインタフェースを持つことになる。もちろん、これ以外のコネクタ、例えば電話／ＩＳＤＮへの接続のためのコネクタなどを有しても構わない。
【０１２１】
次に、上記のような家庭１内の接続状況を、放送系のみに着目してまとめたものが図５である。分配器１０３から分岐した放送波が、ＳＴＢ内蔵テレビ４０１、セットトップボックス４０４，４０７に分岐していることになる。
【０１２２】
また、家庭１内の接続状況を、１３９４系のみに着目してまとめたものが図６である。家庭内バックボーンを通して、ホームルータ１０９、各情報コンセント２０１〜２０４が相互接続され、さらに、各部屋の１３９４機器４０２〜４０４，４０６，４０７が情報コンセントに接続される形態となる。
【０１２３】
なお、上記の家庭内システムの構成は一例であり、情報コンセント数が３以下でも５以上でもよいし、各部屋の装置の配置状況が相違するものであってもよいし、機器台数や種類が増減したものであってもよい。
【０１２４】
ところで、ホームルータ１０９〜１１２は、前述のようにマンションバックボーン網にも接続されている。この様子を示したものが図７である。図７のように、マンションバックボーン網は、デジタル放送蓄積サーバ１０７、インターネットサーバ１０８、ホームルータ１０９〜１１２を１３９４ノードとして構成されていることになる。
【０１２５】
これらのことから分かるように、マンション１３９４バックボーン網と、各家庭内の１３９４バックボーン網とは、ホームルータを介してルータ接続されていて、インターネット的に見ると別個のサブネットと見ることができる。すなわち、マンションバックボーン網と、各家庭のバックボーン網は、どちらもＩＥＥＥ１３９４により構成されているが、ＩＰサブネットアドレスとしては、別個のものが与えられており、それぞれ異なるＩＰサブネットとして、ルーティング処理などが行われる。なお、後述するように、ビデオ転送などを行う場合は、ＩＰレイヤ処理を行うことなく、両バックボーン間で、データのやり取りを行うことができるようにしている。
【０１２６】
以下では、上記にて説明したような環境下での本実施形態のデジタル放送蓄積サーバ１０７、ホームルータ１０９〜１１２、マンションバックボーン網、家庭内バックボーン網、インターネットサーバ１０８の構成、動作、典型的な使い方などについて説明する。
【０１２７】
最初に、家庭内の端末、例えば図４に示す子供部屋のＰＣ４０２が、図１に示す管理室内のデジタル放送蓄積サーバ１０７から、任意のテレビ番組を取り出して、それをＰＣ４０２に映し出しつつ、同じ子供部屋のデジタルＶＴＲ４０３でデジタル録画する手順について説明する。
【０１２８】
まず、ＰＣ４０２とデジタル放送蓄積サーバ１０７は、インターネットプロトコル（ＩＰ）にて通信を行う。これは、主に、システムの家庭の入り口に相当する部分にセキュリティ等の理由によりファイアウオールを配置するため、家庭内バックボーン網とマンションバックボーン網を直接ＩＥＥＥ１３９４でブリッジ接続するのは難しく、ルータ接続とするのが適当と判断されることによる。
【０１２９】
デジタル放送蓄積サーバ１０７は、例えばホームページ等を通して、提供しているサービスを紹介するものとする。
【０１３０】
ＰＣ４０２は、デジタル放送蓄積サーバ１０７が提供しているサービスを紹介しているホームページ等を通して、録画する番組を申告したり、見たい番組を要求したりすることができる。このときに使用するプロトコルとしては、例えばＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）がある。つまり、録画番組の申告をデジタル放送蓄積サーバ１０７のホームページを参照して行なったり（この場合、両者の間のプロトコルはＨＴＴＰ）、ＲＴＳＰを介して番組案内とその要求やサーバの遠隔制御を行うことを基本として考える。なお、ＨＴＴＰの詳細に関してはＲＦＣ２０６８に、ＲＴＳＰの詳細に関してはインターネットドラフトｄｒａｆｔ−ｉｅｔｆ−ｍｍｕｓｉｃ−ｒｔｓｐ−０２．ｐｓや特願平９−１１５６８５等にそれぞれ開示されている。
【０１３１】
このようにホームページ等を通して、インターネットパケットがデジタル放送蓄積サーバ１０７に到達する。パケットが到達するにあたっては、パケットは家庭内のＩＥＥＥ１３９４バス、ホームルータ１０９、そしてマンションバックボーン網のＩＥＥＥ１３９４バスを順に通ってくることになる。この場合のＩＥＥＥ１３９４バス上のインターネットパケットの伝送は、例えばＩＥＴＦにより標準化されるＩＰｏｖｅｒ１３９４の方式に従うものとする。なお、ホームルータでのＩＰパケットの取り扱いについては後述する。
【０１３２】
デジタル放送蓄積サーバ１０７には、大きく分けて２つの機能がある。１つは、衛星放送から受信した放送波のうち、適当なものを取り出して、内部に蓄積する機能である。もう一つは、ユーザ（各家庭のユーザ）からの要求に従って、上記の蓄積したデータ（番組など）から適当なものを取り出して、各家庭に配送する機能である。
【０１３３】
図８に、デジタル放送蓄積サーバ１０７の内部構造の一例を示す。
【０１３４】
図１の衛星放送アンテナ１０１から分配器１０２および同軸ケーブルを通してやってきたデジタル放送データは、例えば数百チャンネルの映像チャンネル等が多重化（周波数多重、ＭＰＥＧ多重等）されている。そこで、ユーザ蓄積要求解析部８０６からの要求に従い、適当な周波数に変調された放送波データを、周波数フィルタ８０１で取り出し、これを復調器８０２にて復調し、例えばＭＰＥＧフレームとした上で、データ蓄積部８０３にて蓄積する。もちろん、データ蓄積部８０３での蓄積の際に、ＭＰＥＧ多重されたデータのうちから必要なもののみを取り出して蓄積する、いわゆるＭＰＥＧフィルタリングを加えてもよい。
【０１３５】
「どのチャンネル（どのＭＰＥＧフレーム／データ）を蓄積すべきか」を判断して、それを周波数フィルタ８０１に司令するのは、ユーザ蓄積要求解析部８０６である。
【０１３６】
この判断のためにユーザ蓄積要求解析部８０６に与えられるユーザからの蓄積チャンネルの指定要求は、インターネットパケットを通じて、ユーザ宅の端末から、このデジタル放送蓄積サーバ１０７に対して送られてくる。具体的には、ユーザ宅の任意のインターネット端末から、例えばＷＷＷブラウザ経由で、「このチャンネルとこのチャンネルを常時録画しておいてください」あるいは「このチャンネルの何曜日の何時から何時までを録画しておいてください」等といった制御をユーザが行う。このような要求を、デジタル放送蓄積サーバ１０７が、ＣＧＩ等を経由して解釈し、要求された番組／データをデータ蓄積部８０３に蓄積していく。なお、このユーザによる設定情報等の制御情報も、このユーザ蓄積要求解析部８０６にて蓄積しておいてもよい。
【０１３７】
本実施形態においては、このユーザからの要求は、ＩＰパケットを介して送られてくる。すなわち、家庭内の任意のインターネット端末から、その家庭のホームルータ、マンションバックボーン網を介して、デジタル放送蓄積サーバ１０７にＩＰパケットが到着する。このパケットは、ＩＥＥＥ１３９４インタフェース８１０にて受信され、ＩＰ処理部８０９を経由してユーザ蓄積要求解析部８０６に渡される。ユーザ蓄積要求解析部８０６は、ユーザがどのチャンネルあるいはデータの蓄積を望んでいるかを解析して、それを周波数フィルタ８０１や、データ蓄積部８０３でのフィルタリング動作に反映させる。
【０１３８】
なお、周波数フィルタ８０１やデータ蓄積部８０３では、ユーザから要求の有無にかかわらず、予め定められたチャンネルやデータを常時（あるいはスポット的に）録画・蓄積するようにしてもよい。この場合、ユーザから要求の有無にかかわらず録画・蓄積すべきチャンネルやデータの指定は、例えば、マンションの管理者等が適宜行なうものとする。
【０１３９】
もちろん、蓄積するチャンネル等は必ずしも１つとは限らない。
【０１４０】
一方、ユーザからの「この番組が見たい」という知らせ（データ取り出し要求）をデジタル放送蓄積サーバ１０７が受信すると、この番組／データを取り出して、これをユーザに向けて伝送する。具体的な伝送の手順は後述するが、このデータ取り出し要求もＩＰパケットを介して送られてくる。すなわち、家庭内の任意のインターネット端末から、その家庭のホームルータ、マンションバックボーン網を介して、デジタル放送蓄積サーバ１０７にＩＰパケットが到着する。このパケットは、ＩＥＥＥ１３９４インタフェース８１０にて受信され、ＩＰ処理部８０９を経由してユーザ取り出し要求解析部８０７に渡される。ここで、ユーザがどのチャンネルあるいはデータの取り出し、伝送を望んでいるかを解析して、その番組の送信をユーザ取り出し要求解析部８０７が、データ選択取り出し部８０４に通知する。その際の番組の選択やその制御プロトコルとしては、例えばＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）等を用いる。
【０１４１】
上記の要求を受けたデータ選択取り出し要求解析部８０７は、まずユーザ毎使用帯域監視部８０８に問い合わせを行う。マンションバックボーン網における帯域には上限があるため、ユーザ毎使用帯域監視部８０８では、デジタル放送蓄積サーバ１０７から各家庭への同時映像／データ配信を、例えば数Ｍｂｐｓあるいは数チャンネルなどに抑えている。この各家庭への同時映像／データ配信の上限値は、マンションの管理者と、各家庭との契約に基づくものとしてもよい。
【０１４２】
なお、同時映像／データ配信の制限の設定は、ユーザごとではなく、他の単位、例えば各家庭の各端末ごとに行なってもよい。
【０１４３】
図９に、データ取り出し要求の到着から該当するデータの送出までの手順の一例を示す。
【０１４４】
まず、家庭ユーザからのデータ取り出し要求が到着する（ステップＳ１０）。この要求はＩＰパケットの形で到着し、ＩＰ処理部８０９は、アドレスとポート番号の組み合わせ等から、そのパケットがどのユーザからのデータ取り出し要求であるかを認識し、このパケットをユーザ取り出し要求解析部８０７に送出する。なお、データ取り出し要求を解析するプログラムに対して、特定のポート番号があらかじめ割り当てられるものとする。
【０１４５】
ユーザ取り出し要求解析部８０７では、あらかじめ本蓄積サーバ１０７の使用を許可されたユーザであるかどうかの認証を行う（ステップＳ１１）。認証が通らない場合は、認証失敗通知をユーザに対して送り返す（ステップＳ１２）。認証が通った場合は、要求されたサービスを開始するための準備に入る。
【０１４６】
ここで、本実施形態のデジタル放送蓄積サーバ１０７でのポリシーの一例を示す。本実施形態のデジタル放送蓄積サーバ１０７では、マンションバックボーン網の帯域や同期チャネル番号数に上限があるため、契約家庭毎に、使用できる帯域あるいはチャネル番号数に上限が設けられている。つまり、「家庭１は同じ視聴チャンネル数３まで、合計配信帯域１８Ｍｂｐｓまで」等といった制限を各家庭毎に記した図１０のような表を有し、「要求されたサービスを提供したときに、その家庭により消費されるマンションバックボーン網等の資源量が、このテーブルで定められた値以下にあるような場合に、そのサービスを行う」という方法である。
【０１４７】
データ選択取り出し要求解析部８０７は、ユーザ毎使用帯域監視部８０８を通じて要求したユーザに割り当てられた帯域あるいはチャネル数を調べ（ステップＳ１３）、要求されたサービスの提供の可否を判断し（ステップＳ１４）、サービスが不可能である場合は、ユーザに対してサービス不可能通知を行う（ステップＳ１５）。なお、サービス不可能通知には、その理由（例えば規定チャンネル数を越えたことなど）を示す情報を付加するようにしてもよいし、さらに上限値を確認させるための情報を付加するようにしてもよい。
【０１４８】
このようなサービスを迅速に実現するため、このデジタル放送蓄積サーバ１０７が、常に１３９４バスの同期リソースマネージャになっていてもよい。そのためには、同期リソースマネージャのｐｒｅｆｅｒｅｎｃｅの値を大きな値として持っておく等の方法が考えられる。この場合は、自らが持っている同期リソースマネージャのリソーステーブル（残余帯域と、残余同期チャネル番号についてのテーブル）を参照できるので、迅速な処理が可能になる。
【０１４９】
ステップＳ１４にて、上記のサービスを行うことが可能であると判断された場合には、デジタル放送蓄積サーバ１０７から、マンションバックボーン網を通して、ユーザの端末に対して、データを送信するための通信資源を確保すべく、ＩＥＣ１８８３等のプロトコルを用いて、マンションバックボーン網の通信資源（帯域、同期チャネル番号）を確保する（ステップＳ１６）。その後、該サービスの要求端末（方向）に対して、ＦＡＮＰ（Ｆｌｏｗ Ａｔｔｒｉｂｕｔｅ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）メッセージを送出する（ステップＳ１６）。ＦＡＮＰは、今後送信するデータの宛先（ＩＰアドレス）と、リンクレイヤの識別子情報（ここでは、同期チャネル番号）を隣接するノードに対して通知するプロトコルである。このＦＡＮＰを用いて、デジタル放送蓄積装置１０７から、受信端末までの通信資源の確保を行っていく。なお、ＦＡＮＰの詳細は、電子情報通信学会交換システム研究会予稿ＳＳＥ９７−１９や特願平８−２６４４９６等に詳しく開示されている。
【０１５０】
このＦＡＮＰメッセージには、宛先アドレスとして、データ配信を要求してきたノードのＩＰアドレス、デジタル放送蓄積サーバ１０７がデータを配信する際に使用するマンションバックボーン網の同期チャネル番号、伝送するデータの属性（例えば、ＭＰＥＧ映像等）等の情報が入る。使用する帯域などについての情報や、送信ノードのアドレス、エンド−エンドのＡＣＫメッセージの要求の有無についての情報などが入ってもよい。
【０１５１】
ここで、ＦＡＮＰの代わりにＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｓｅｔｕｐ Ｐｒｏｔｏｃｏｌ）を用いて、通信資源の確保を行なってもよい。ＲＳＶＰはＩＰレベルのシグナリングプロトコルであり、詳細はインターネットドラフト“ｄｒａｆｔ−ｉｅｔｆ−ｒｓｖｐ−ｓｐｅｃ−１５”や特願平９−５２１２５などに開示されている。
【０１５２】
また、ＦＡＮＰとＲＳＶＰを併用しても、もちろん構わない。この場合、ＲＳＶＰにてデジタル放送蓄積装置１０７から、受信端末までの通信資源の確保を行なっていく。ＦＡＮＰは使用するデータリンク識別子の隣接ノードへの通知に用いる。
【０１５３】
次に、必要な通信資源が確保され、相手端末への映像データなどのデータ転送の準備が整ったならば、データ蓄積部８０３に蓄積されていたデータの伝送が開始される。すなわち、ユーザ取り出し要求解析部８０７は、データ選択取り出し部８０４を介して、データ蓄積部８０３から必要な（要求された）データを取り出し（ステップＳ１７）、ＣＩＰヘッダ付加部８０５にて、１３９４上でのデータ転送に必要なフォーマットに変換した上で、１３９４インタフェース（Ｉ／Ｆ）８１０を通して、データを送出する（ステップＳ１８）。
【０１５４】
次に、ホームルータ１０９の内部構造とその働きについて一連のシーケンス図を参照しながら説明する。
【０１５５】
図１１に、ホームルータ１０９の内部構造の一例を示す。
【０１５６】
本ホームルータ１０９は、マンションバックボーン網側にＩＥＥＥ１３９４インタフェース１１０１を、家庭内バックボーン網側に第２のＩＥＥＥ１３９４インタフェース１１０５をそれぞれ持っている。
【０１５７】
また、ホームルータ１０９は、その家庭内のＩＰノードのＩＰアドレスを決定するためのＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ ＣｏｎｆｉｇｕｒａｔｉｏｎＰｒｏｔｏｃｏｌ）サーバ処理部１１１２を持つ。どのようなＩＰアドレスを与えるべきかについては、あらかじめマンションの管理者が決定しておくものとする。なお、マンション全体のアドレス管理を行っているノードが管理室内にあり、このノードが該ＤＨＣＰサーバ処理部１１１２に対して、与えるべきＩＰアドレスを通知する方式を取ってもよい。なお、ＤＨＣＰについてはＲＦＣ１５４１や特願平８−３１６５５２等に詳しく開示されている。
【０１５８】
ここで、前述のようなＰＣ４０２からホームルータ１０９を介して、デジタル放送蓄積サーバ１０７にアクセスする場合を例として、図１２にそのシーケンス図を示す。以下、図１２を参照しながら、ホームルータ１０９の動作を説明する。
【０１５９】
まず、ＰＣ４０２は、デジタル放送蓄積サーバ１０７にアクセスすべく、デジタル放送蓄積サーバ１０７が立ち上げているホームページにアクセスする。始めは、ユーザがデジタル放送蓄積サーバ１０７に対して、「このチャンネルを常時録画しておいてほしい」という登録をするための、録画チャンネルの設定を行う場合を考える。ここでは、デジタル放送蓄積サーバ１０７のホームページに適当な書き込みや設定を行うことにより登録できるようになっているものとする。このため、図８のデジタル放送蓄積サーバ１０７のＩＰ処理部８０９では、ＷＷＷサーバのデーモンが走っている。ＰＣ４０２は、ＨＴＴＰでデジタル放送蓄積サーバ１０７と情報のやりとりを行うために、デジタル放送蓄積サーバ１０７宛てにＩＰパケットを送出する。
【０１６０】
このパケットは、ホームルータ１０９では、単純なパケットフォワーディングとして扱われる。前述の例のように、単純なＩＰパケットのフォワーディングの際には、このＩＰパケットはＩＥＥＥ１３９４の非同期パケットとして、ＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を通して認識されたそのノードのしかるべきレジスタ宛に転送されてくるので、例えばＰＣ４０２からデジタル放送蓄積サーバ１０７へのＩＰパケット転送の際には、ＩＰパケットは、次の順、すなわち１３９４インタフェース１１０５、レジスタ処理部１１０８、ＩＰルーチング処理を行うＩＰ処理部１１０９、レジスタ処理部１１０６、マンションバックボーン網側の１３９４インタフェース１１０１という順で転送される。なお、レジスタ処理部１１０６，１１０８は、それぞれ、転送されてくる１３９４パケットのレジスタ値（オフセットアドレス値）を参照してしかるべき処理部への振り分けやフィルタリングを行うものである。この場合は、処理されるＩＰパケットは単にホームルータにおいてルーチング処理をなされるのみでよい。
【０１６１】
なお、転送されてきたＩＰパケットがＤＨＣＰパケット等の場合は、ＩＰ処理部１１０９においてパケットの宛先（自分宛のパケットであるか否か）やポート番号などを解析し、しかるべき処理部にそのパケットを転送する処理を行うことになる（例えばＤＨＣＰパケットであることが判明したならば、ＤＨＣＰサーバ処理部１１１２に転送する等）。
【０１６２】
また、マンションバックボーン側からみて、ホームルータにはなんらセキュリティ機能が備わっていないとすると、その家庭へは電子的に入り放題という形になってしまい、家庭網のプライバシやクラッカーの脅威に対して、大変な問題がある。そこで、本ホームルータにおいては、マンションバックボーン網側にファイアウオール／認証処理部１１１０を設けており、該ファイアウオール／認証処理部１１１０が、その家庭にマンションバックボーン網側から入ってくる全ＩＰパケット（ただし、後述する同期チャネルを通じて入ってくるＩＰパケットを除く）について、認証処理あるいはファイアウオール処理を行い、セキュリティを確保している。
【０１６３】
１３９４代理サービス処理部１１１１については後述する。
【０１６４】
さて、デジタル放送蓄積サーバ１０７に到達したＨＴＴＰのパケット（録画チャンネル設定パケット）は、前述のようにデジタル放送蓄積サーバ１０７内にて処理を施され、この結果、ユーザの要求するデジタル放送チャンネルの録画が自動的に行われる。
【０１６５】
次に、ユーザは、その録画した番組を見るために、ＰＣ４０２を通してデジタル放送蓄積サーバ１０７のホームページにアクセスする。ユーザは、このホームページの表示の「どこのチャンネルか」あるいは「どの番組か」などについて設定を行い、ＲＴＳＰ等を通して、見たい番組の設定を行う。このパケット（ＩＰパケット）のＰＣ４０２とデジタル放送蓄積サーバ１０７との間のやり取りは、ＨＴＴＰの場合と同様である（ＲＴＳＰはＨＴＴＰをベースとしている）。
【０１６６】
なお、ＰＣ４０２は、ＲＴＳＰパケットにユーザ情報としてある識別番号（Ｐ）を含ませてもよい。この識別番号の値によって、ユーザ側は、どのＲＴＳＰパケットによる要求に対する設定であるかを、後に照合することができるようになる。
【０１６７】
データ取り出し要求により番組送信を要求されたデジタル放送蓄積サーバ１０７は、前述のようにユーザ認証やマンションバックボーン網の通信資源（帯域、同期チャネル番号）の確保などをＩＥＣ１８８３等を通して行った後、前述のＦＡＮＰメッセージをホームルータ１０９に向かって送出する。この場合、確保された同期チャネルを＃ｘとする。このＦＡＮＰメッセージには、ターゲット端末がＰＣ４０２であること（ＰＣ４０２のＩＰアドレスが記載されている）、転送するデータがＭＰＥＧ映像であること（ＩＰパケットではない；よってＩＥＣ１８８３で定められたＭＰＥＧｏｖｅｒ１３９４の伝送フォーマットにて伝送されることを意味する）、その要求帯域が６Ｍｂｐｓであること、ホームルータ１０９まではデジタル放送蓄積サーバ１０７が先に確保した同期チャネル番号＃ｘの同期チャネルを使って伝送すること等が記されている。なお、ＦＡＮＰメッセージには、必要な認証情報などが入っていてもよい。また、ターゲット端末（この場合、ＰＣ４０２）において、このＦＡＮＰパケットが、前述のＲＴＳＰによる制御に対応するものであることを認識することができるようにするために、前述の識別番号（Ｐ）を、ＦＡＮＰパケットに含んで送信してもよい。この値は、ターゲット端末まで、書き換えられることなく伝送されるものとする。
【０１６８】
このＦＡＮＰパケットは、１３９４インタフェース１１０１、レジスタ処理部１１０６、ＩＰ処理部１１０９を経由して、ＦＡＮＰ処理部１１０７に到達する。
【０１６９】
ＦＡＮＰ処理部１１０７では、まずターゲットがＰＣ４０２であることを認識し、該ＰＣ４０２とつながるネットワークが家庭内バックボーン網であることを認識する。次に、ＭＰＥＧ映像を伝送するのに必要な、家庭内バックボーン網であるＩＥＥＥ１３９４バスの通信資源（帯域、同期チャネル番号）＃ｙを確保する。次に、ＩＥＣ１８８３を使って、ＰＣ４０２のＰＣＲ（プラグコントロールレジスタ）を設定し、ＰＣ４０２が同期チャネル＃ｙからの情報を受信できるようにする。次に、ＰＣ４０２に向けて、ＦＡＮＰメッセージを送出する。
【０１７０】
このＦＡＮＰメッセージには、ターゲット端末がＰＣ４０２であること（ＰＣ４０２のＩＰアドレスが記載されている）、転送するデータがＭＰＥＧ映像であること（ＩＰパケットではない；よってＩＥＣ１８８３で定められたＭＰＥＧｏｖｅｒ１３９４の伝送フォーマットにて伝送されることを意味する）、その要求帯域が６Ｍｂｐｓであること、ＰＣ４０２までホームサーバ１０９が先に確保した同期チャネル番号＃ｙの同期チャネルを使って伝送すること等が記されている。なお、ＦＡＮＰメッセージには、必要な認証情報などが入っていてもよい。また、前述のように、ターゲット端末（この場合、ＰＣ４０２）において、このＦＡＮＰパケットが、前述のＲＴＳＰによる制御に対応するものであることを認識することができるようにするために、前述の識別番号（Ｐ）を、ＦＡＮＰパケットに含んで送信してもよい。
【０１７１】
それと同時に、ＦＡＮＰ処理部１１０７は、１３９４スイッチ１１０３に、「マンションバックボーン網側から入力された同期チャネル番号＃ｘから入力された同期チャネルの信号は、家庭内バックボーン網側の同期チャネル番号＃ｙに転送する。転送データはＭＰＥＧｏｖｅｒ１３９４である。」といったことを設定する。そのために、１３９４スイッチ１１０３には、図１３のような設定テーブルを持っている。このようにして、１３９４スイッチ１１０３の設定がなされる。
【０１７２】
その後、デジタル放送蓄積サーバ１０７が、マンションバックボーン網の同期チャネル番号＃ｘの同期チャネルに対して、ＭＰＥＧ映像のデータ送出を開始すると、これは１３９４インタフェース１１０１、チャネル番号処理部１１０２、１３９４スイッチ１１０３、チャネル番号処理部１１０４、１３９４インタフェース１１０５を経由して、家庭内バックボーン網に転送される。
【０１７３】
ここで、入り側のチャネル番号処理部１１０２は、１３９４スイッチ１１０３内の設定テーブル（図１３参照）にて設定された入力同期チャネル番号について、これをフィルタリングして取り出し、該同期チャネル番号を持って入力されてきた同期パケットを、１３９４スイッチ１１０３にフォワードする機能を持つ。
【０１７４】
また、出側のチャネル番号処理部１１０４は、１３９４スイッチ１１０３内の設定テーブル（図１３参照）にて設定された出力同期チャネル番号を付与し、これを同期パケットとして、１３９４Ｉ／Ｆ１１０５を介して送出する機能を持つ。
【０１７５】
さて、このＭＰＥＧ映像データは、ＰＣ４０２に到達して、ＰＣ４０２上でＰＣ内のＭＰＥＧデコード処理と、画像表示機能を用いて、閲覧することが可能である。
【０１７６】
さらに、ＰＣ４０２からの制御により、デジタル放送蓄積サーバ１０７から送られてきているＭＰＥＧ映像をデジタルＶＴＲ４０３にて録画することも可能である。この手順について図１２を参照しながら簡単に説明すると、ＰＣ４０２はＩＥＣ１８８３を使ってデジタルＶＴＲ４０３のＰＣＲ（プラグコントロールレジスタ）にアクセスし、同期チャネル番号＃ｙからの信号を受信するように設定し、さらにＩＥＥＥ１３９４ＡＶ／Ｃ（ＡＶ制御）プロトコルを用いて、録画モードにする。このようにすることにより、デジタルＶＴＲ４０３には、ＰＣ４０２が要求したデジタル放送蓄積サーバ１０７からのＭＰＥＧ映像が同期チャネル＃ｙを通じて到達し、それを録画することが可能となる（なお、このような手順については特願平９−１１５６８５に詳しい）。
【０１７７】
なお、図１２においては、家庭内バックボーン網の帯域予約はホームルータ１０９により行われていたが、この帯域予約を図１４のように、ＰＣ４０２により行うことも可能である。この場合、ホームルータ１０９に対して、データリンクスイッチを行って、「映像データを転送すべきは家庭内バックボーン網の同期チャネル＃ｙであること」を認識させる必要がある。このため、データ取り出し要求のメッセージにあるＩＤ番号（ｐ）を搭載し、「そのＩＤ番号を含むＦＡＮＰメッセージが到達したならば、そのＦＡＮＰで通知された同期チャネル（本実施形態の場合、＃ｘ）を家庭内バックボーンの同期チャネル（＃ｙ）にデータリンクスイッチングすべきこと」を通知するメッセージが、ＰＣ４０２からホームルータ１０９に対して送られることになる。これらのメッセージを元に、ホームルータ１０９は、内部のテーブルを設定し、データリンクスイッチを実現する。
【０１７８】
さて、上記では、高速通信あるいはリアルタイム通信の１つの方法として、デジタル放送蓄積サーバ１０７からの映像の伝送に、マンションバックボーン網および家庭１の家庭内バックボーン網の同期チャネルを使い、ホームルータにおける同期チャネル番号を参照した１３９４スイッチ部による、データリンクスイッチによるスイッチングの例を示した。
【０１７９】
以下では、高速通信あるいはリアルタイム通信の他の方法として、同期チャネルの代わりに、ＩＥＥＥ１３９４の非同期チャネルを用い、かつ、ホームルータにおいては、やはりデータリンク識別子のみを参照した、データリンクスイッチの例を説明する。
【０１８０】
この場合、ホームルータ１０９〜１１２の構成において、２つのチャネル番号処理部（１１０２，１１０４）夫々を、チャネル番号のみならず、非同期パケットのレジスタオフセットの値を使ったフィルタリング処理をも行うチャネル番号・レジスタオフセット処理部にする修正を加えるだけである。以下、チャネル番号・レジスタオフセット処理部に１１０２−２，１１０４−２の符号を付して説明する。
【０１８１】
ここでも、前述の場合と同様に、図４の家庭１の子供部屋のＰＣ４０２が、図１のデジタル放送蓄積サーバ１０７から任意のテレビ番組を取り出して、それをＰＣ４０２に映し出しつつ、同じ子供部屋のデジタルＶＴＲ４０３でデジタル録画する場合を考える。前述の例との相違点は、実際のＭＰＥＧ映像の伝送の際に、同期チャネルではなく、非同期チャネル（非同期パケット）を用いる点である。図１５にこの場合のシーケンス図の一例を示す。
【０１８２】
デジタル放送蓄積サーバ１０７が、映像データを出力する場合、図１５のように、中継装置であるホームルータ１０９に「どのレジスタオフセットを用いて、映像データを送信して良いか」についての問い合わせを発行する。この問い合わせは、「ホームルータ１０９のマンションバックボーン網側のインタフェースにおいて、空いているレジスタオフセットの値を使うことができるか」について伺いを立てるものと位置づけることができる。この問い合わせのパケットには、今後、このレジスタオフセットを用いて、どのような通信をしようとしているのか（例えば通信帯域や上位アプリケーションなど）に関する情報を搭載してもよい。
【０１８３】
このオフセットアドレス問い合わせ／応答のメッセージについては、アドレスレゾリューションパケット（ＡＲＰパケット）を流用することも可能である。すなわち、ＡＲＰ要求として、上記の「どのレジスタオフセットを用いて、映像データを送信して良いか」についての問い合わせを発行し、ＡＲＰの解決アドレスとして、ＡＲＰ応答メッセージとして、上記レジスタオフセットの値を通知してもらう方法である。
【０１８４】
上記の問い合わせに対し、ホームルータ１０９は、現在空いている適当なレジスタオフセットの値をデジタル放送蓄積サーバ１０７に送り返す。ここでは、送り返されたレジスタオフセットの値が、＃ｘであるとする。つまり、非同期パケットの宛先として、ホームルータ１０９のノードＩＤと、＃ｘを付与して出すことを示している。
【０１８５】
レジスタオフセットの値の返送を受けたデジタル放送蓄積サーバ１０７は、前述の同期チャネルを使う場合と同様に、隣接ノード（この場合、ホームルータ１０９）に対してデータリンクレイヤにおけるスイッチングを促すため、ＦＡＮＰ（Ｆｌｏｗ Ａｔｔｒｉｂｕｔｅ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）メッセージを送出する。このＦＡＮＰメッセージには、宛先アドレスとして、データ配信を要求してきたノードのＩＰアドレス（この場合、ＰＣ４０２）、デジタル放送蓄積サーバ１０７がデータを配信する際に使用するレジスタオフセット値（＃ｘ）、伝送するデータの属性（例えば、ＭＰＥＧ映像等）等の情報が入る。使用する帯域などについての情報や、送信ノードのアドレス、エンドエンドのＡＣＫメッセージの要求の有無についての情報などが入ってもよい。
【０１８６】
次に、必要な手続きが終了し、相手端末への映像データなどのデータ転送の準備が整ったならば、データ蓄積部８０３に蓄積されていた、データの伝送が開始される。すなわち、ユーザ取り出し要求解析部８０７は、データ選択取り出し部８０４を介して、データ蓄積部８０３から必要な（要求された）データを取り出し、ＣＩＰヘッダ付加部８０５にて、１３９４上の非同期転送モードにおいて転送に必要なフォーマットに変換した上で、１３９４インタフェース（Ｉ／Ｆ）８１０を通して、データを送出する。その非同期パケットの宛先は、前述のように、「ホームルータ１０９のノードＩＤ、レジスタオフセット＃ｘ」である。
【０１８７】
次に、ホームルータ１０９の動作について、一連のシーケンス図を見ながら説明する。
【０１８８】
前述のデジタル放送蓄積サーバ１０７からホームルータ１０９に向かって送出されたＦＡＮＰパケットは、１３９４インタフェース１１０１、レジスタ処理部１１０６、ＩＰ処理部１１０９を経由して、ＦＡＮＰ処理部１１０７に到達する。ここでは、まずターゲットがＰＣ４０２であることを認識し、該ＰＣ４０２とつながるネットワークが家庭内バックボーン網であることを認識する。次に、デジタル放送蓄積装置１０７がホームルータ１０９に対して行ったのと同様の、レジスタオフセット値の獲得手続きを家庭１の家庭内バックボーン網について、ＰＣ４０２に対して行う。獲得できたレジスタオフセット値が＃ｙであるとする。次に、ＰＣ４０２に向けて、ＦＡＮＰメッセージを送出する（ＰＣ４０２は、この段のネットワーク上に存在しているので、送出しなくてもよい。）
これと同時に、ＦＡＮＰ処理部１１０７は、１３９４スイッチ１１０３に、「マンションバックボーン網側から入力されたレジスタオフセット＃ｘ宛てのパケットは、家庭１の家庭内バックボーン網側に、ＰＣ４０２（のノードＩＤ）のレジスタオフセット＃ｙ宛ての非同期パケットに書き直した上で、家庭１の家庭内バックボーン網に送出する」といった設定を行う。その際の設定テーブルの内容は図１６のようになる。このようにして、１３９４スイッチ１１０３の設定がなされる。
【０１８９】
その後、デジタル放送蓄積サーバ１０７が、マンションバックボーン網に、ホームルータ１０９のレジスタオフセット＃ｘ宛てに、非同期パケットでＭＰＥＧ映像のデータ送出を開始すると、送出されたデータは、１３９４インタフェース１１０１、チャネル番号・レジスタオフセット処理部１１０２−２、１３９４スイッチ１１０３、チャネル番号・レジスタオフセット処理部１１０４−２、１３９４インタフェース１１０５を経由して、家庭内バックボーン網に転送される。この間、図１６のテーブルを参照することにより、ＩＰ処理は行われず、データリンクレイヤヘッダのみを参照したスイッチングが行われている。
【０１９０】
ここで、入り側のチャネル番号・レジスタオフセット処理部１１０２−２は、１３９４スイッチ１１０３内の設定テーブル（図１６参照）にて設定された入力レジスタオフセット値について、これをフィルタリングして取り出し、該レジスタオフセット値を持って入力されてきた非同期パケットを、１３９４スイッチ１１０３にフォワードする機能を持つ。
【０１９１】
また、出側のチャネル番号・レジスタオフセット処理部１１０４−２は、１３９４スイッチ１１０３内の設定テーブル（図１６参照）にて設定された宛先ノードＩＤ（この場合、ＰＣ４０２のノードＩＤ）としてレジスタオフセット値を付与し、これを非同期パケットとして、１３９４Ｉ／Ｆ１１０５を介して送出する機能を持つ。
【０１９２】
このＭＰＥＧ映像データは、ＰＣ４０２に到達して、ＰＣ４０２上でＰＣ内のＭＰＥＧデコード処理と、画像表示機能を用いて、閲覧することが可能である。
【０１９３】
なお、この場合は、ＭＰＥＧ映像の伝送を非同期パケット、すなわちベストエフォートにて行っているため、通信品質の保証は必ずしもなわれておらず、高品質の映像をユーザが求めている場合には、アプリケーションレイヤでの対応が必要になる。また、非同期転送モードの際には、バスリセットの前後にノードＩＤが変化する可能性があるので、このような場合は、オフセットアドレス問い合わせ／応答メッセージなどのやり取りを再度行う必要がある。
【０１９４】
次に、マンションの家庭間で行なわれる家間通信を行う場合について説明する。家間通信の例として、図１の家庭１と家庭２との間での通信を想定する。まず、家庭１のユーザが、家庭２のＶＴＲ（図４のＶＴＲ４０３に相当；以下、４０３−２と付す）にアクセスして、該ＶＴＲ（４０３−２）に録画してあるＭＰＥＧ映像データを家庭１の家庭内バックボーン網、マンションバックボーン網、家庭２の家庭内バックボーン網を経て、家庭１のＰＣ４０２に映し出すプロセスを例として説明する。なお、説明の簡略化のため、家庭２の中の装置構成も図４と同様の構成になっているものとする。また、以下、ＶＴＲ（４０３−２）と同様に参照符号に−２を付してあるものは、家庭２の機器（図４の各機器（−２を除いた参照符号を持つもの）に相当するもの）であることを示すものとする（図１７、図１８、図２１も同様）。
【０１９５】
まず、家庭２のホームルータ１１０は、他の家庭（本例では家庭１）に対して、家庭２の中にどのような装置および／またはサービスが提供されているかを紹介する。このサービスをディレクトリサービスと呼ぶものとする。
【０１９６】
ところで、各家庭のユーザは、自分の家庭の中の装置構成やサービス、ましてそのコンテンツなどを他の家庭に公開することには、一般にプライバシの問題もあり、大きな抵抗があることが考えられる。そこで、本実施形態では、家庭の中の装置構成やサービスのうち、どれを外部に公開するかを選択的に設定できる機構を提供する。この設定は、家庭の内部からでも、家庭の外部からでも、どちらからでも行うことができる。
【０１９７】
まず、家庭内部から公開する装置および／またはサービスを設定する方法について説明する。まず、ホームルータ１１０は、家庭２内の装置、サービスについての情報を収集する。なお、この手順の詳細はインターネットのサービスロケーションプロトコル（インターネットドラフトのｄｒａｆｔ−ｉｅｔｆ−ｓｖｒｌｏｃ−ｒｏｔｏｃｏｌ−１５．ｔｘｔ）、ＩＥＥＥ１３９４スペック（ＩＥＥＥ１３９４−１９９５ ｓｐｅｃｉｆｉｃａｔｉｏｎ）、特願平９−１１５６８５等に詳しく開示されている。
【０１９８】
この手順の一例を図１７に示す。図１７のように、ホームルータ１１０は、サービスロケーションプロトコルのディレクトリエージェント（ＤＡ）となっている。最初に、家庭内のサービスロケーションプロトコルが実装されたノードからの、サービスリクエスト（ｐｒｅｄｉｃａｔｅ＝ＤＡ，宛先ＩＰアドレス＝ディレクトリエージェントディスカバリ用マルチキャストアドレス）をホームルータ１１０は受信する。このメッセージは、「ディレクトリサーバはどこにあるのか」をネットワークに尋ねる意味がある。このサービスリクエストに対し、ホームルータ１１０は、自身がディレクトリサーバであることを示すＤＡアドバタイズメントを送り返す。このＤＡアドバタイズメントを受けたノードは、自分がどのようなサービスを行っているかについての情報を登録するサービス登録メッセージを、ホームルータ１１０に対して送出する。ホームルータ１１０がサービスＡＣＫを送り返すことで、サービスの登録は終了する。
【０１９９】
また、上記の手順とは別に、図１８のように、ホームルータ１１０が、家庭２の家庭内ネットワークに接続された１３９４ノードのコンフィグレーションメモリの読み込みを順次行っていくことにより、各１３９４ノードのレジスタから、その接続された機器についての情報を収集する。通常は、機種名やメーカ名などを入手できる。
【０２００】
さらに、手設定による情報入力などを行うようにしてもよい。
【０２０１】
これらの方法を通して、ホームルータ１１０は、家庭２内に存在する、ネットワークに接続されたサービスあるいは機器についての情報を収集する。
【０２０２】
これら収集したサービスあるいは機器についての情報のうち、家庭２のユーザが外部に見せてもよいと考えるサービス／機器もあれば、外部には見せたくないと考えるサービス／機器もあろう。そのため、ホームルータ１１０には、家庭２内に存在すると認識したサービス／機器のうち、どれを外部に見せてもよいかをユーザ側に選択させる手順を持つ。
【０２０３】
例えば、ホームルータ１１０の何らかの画面上に、認識されたサービス／機器の一覧を表示し、ユーザに対して「どのサービス／機器を外に見せてもよいですか？」といった聞き方で、ユーザに選択をさせる、といった方法が考えられる。この場合は、ホームルータ１１０自身がＷＷＷサーバとなって、ホームページを持ち、このホームページ上でどのサービスあるいは機器を外に見せるか（家庭外からの制御を可能にするか）を選択できるようにしておけば、このホームページをアクセスすることによって、家庭の内外からの「どの機器／サービスを、見せる／見せない」に関する制御を可能にすることができる。
【０２０４】
なお、選択された公開する端末／サービスは、サービス表示テーブル１１１４に登録される。
【０２０５】
上記の方法であれば、家庭外からの設定も可能である。ただし、家庭外から、このホームページを通した設定を行うためには、その設定の前に、その設定を行う者について、許されたその家庭２のユーザであるか否かを認証するステップを設けるのが望ましい。この場合の手順の一例を図１９に示す。
【０２０６】
また、例えばＭｉｃｒｏｓｏｆｔ社のウインドウズ９５等のように「共有」の機能を提供するＯＳを搭載した機器については、このウインドウズＯＳ等に含まれる「共有」の機能を用いても、これを実現することができる。すなわち、共有において、同じワークグループに属している場合について、その機器を外に見せる、といった方法である。
【０２０７】
このようにして、家庭外に見せてもよいサービス、機器が設定される。ここでは、家庭２のデジタルＶＴＲ（４０２−３）とＰＣ（４０２−２）を外部に見せてもよいサービス／装置として登録したものとする。
【０２０８】
さて、ホームルータ１１０は、マンションバックボーン側（あるいは、電話／ＩＳＤＮ端子側）に対して、サービスロケーションプロトコルを稼動する場合に、サービス要求（サービスロケーションプロトコルにおけるサービスタイプリクエスト、サービスリクエスト、属性リクエストの各メッセージ）に対して、ホームルータ１１０以外の家庭２外のノードには、デジタルＶＴＲ（４０３−２）とＰＣ（４０２−２）あるいはＰＣ（４０２−２）上で稼動しているしかるべきサービスのみを外部に見せる。
【０２０９】
例えば、図２０のシーケンスのようにして、サービスタイプとして、デジタルＶＴＲ（４０３−２）と、ホームルータ１１０にて稼動しているＷＷＷ（ＨＴＴＰ）サーバ、ＰＣ（４０２−２）にて稼動しているファイルサーバのサービスのみを外部に見せるように設定したとすると、それらのサービスのロケーションがサービスタイプリプライメッセージ等に含められて、外部に紹介される。
【０２１０】
その際、ＩＰのサービスロケーションプロトコルによって登録されたサービス（例えば、ＩＰ端末であるＰＣ（４０２−２）で提供されるサービスや、ホームルータ１１０で提供されるサービス）については、そのまま、その装置のＩＰアドレス（あるいはドメインネームなど）を使って、サービスの広告が行われる。また、１３９４端末であるデジタルＶＴＲ（４０３−２）については、ホームルータ１１０が代理サーバとして、自分のアドレスと、デジタルＶＴＲを特定できるポート番号と共に、これを外部に広告する。以降、そのアドレスに対して、ＲＴＳＰ等を用いて、その制御要求がきた場合は、これを１３９４コマンドに翻訳して、デジタルＶＴＲ（４０３−２）に通知したり、必要な通信資源を確保するなりの動作を行うことになる。これらは、１３９４代理サービス処理部１１１１の役割である。選択された端末／サービスは、サービス表示テーブル１１１４に登録される（なお、以上の手順は特願平９−１１５６８５に詳しく開示されている）。
【０２１１】
次に、上記のようにして家庭２のホームルータ１１０に登録されたサービス／装置情報をもとに、家庭１のＰＣ４０２から、家庭２のデジタルＶＴＲ（４０３−２）を制御して、該家庭２のデジタルＶＴＲ（４０３−２）内に録画された映像データを、家庭１のＰＣ４０２上で見る場合の手続きについて図２１を参照しながら詳述する。
【０２１２】
まず、家庭１のＰＣ４０２は、家庭２のホームルータ１１０にアクセスし、サービスタイプリクエストを送出する。ＰＣ４０２上のＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）は、Ｗｅｂのホームページなどでよい。家庭２のホームルータ１１０は、自身のＷＷＷサーバ、ＰＣ（４０２−２）のファイルサーバ、それにデジタルＶＴＲ（４０３−２）についてサービスタイプリプライを行う。続いて、サービスタイプリクエストや属性リクエストを行って、そのサービスや機器についてのアドレス情報やその属性情報を入手する。家庭１のＰＣ４０２上に表示されるＧＵＩの例を図２２に示す。
【０２１３】
次に、家庭１のＰＣ４０２は、例えば図２２のＧＵＩ上で家庭２のデジタルＶＴＲ（４０３−２）を選択し、その端末もしくはサービスに対して遠隔制御コマンドを発行する。具体的には、ＲＴＳＰを使って、ある特定の番組の再生コマンドを発行する。実際には、このコマンドは、代理サーバである家庭２のホームサーバ１１０のあらかじめ定められたポートに到達する。
【０２１４】
すると、家庭２のホームルータ１１０は、これが家庭２のデジタルＶＴＲ（４０３−２）への遠隔操作要求であることを認知し、家庭２のデジタルＶＴＲ（４０３−２）の遠隔操作をすべく必要な処理を行う。まず映像伝送に必要な通信資源を確保すべく、家庭２の家庭内バックボーン網の通信資源（帯域、同期チャネル番号＃ｘ）を獲得する。次に、その同期チャネルについて、データ送信を促すＩＥＣ１８８３と、デジタルＶＴＲ用に定められた１３９４ＡＶ／Ｃプロトコルを用いて、家庭２のデジタルＶＴＲ（４０３−２）に対して、データ送出を働きかける。
【０２１５】
これと前後して、家庭２のホームルータ１１０は、マンションバックボーン網上に、映像伝送に必要な通信資源（帯域、同期チャネル番号＃ｙ）を獲得し、ＩＥＣ１８８３にて、家庭１のホームルータ１０９に、データ受信を促す。
【０２１６】
この時点で、家庭２のホームルータ１１０は、家庭２のバックボーン網側の同期チャネル＃ｘと、マンションバックボーン網側の同期チャネル＃ｙとが互いに対応することを認識し、図１２や図１４を参照しながら先に説明したように、内部の１３９４スイッチ１１０３のテーブルの設定を行う。
【０２１７】
その後、前述したＦＡＮＰメッセージをホームルータ１０９に対して送出する。このＦＡＮＰメッセージには、ターゲット端末が家庭１のＰＣ４０２であること（ＰＣ４０２のＩＰアドレスが記載されている）、転送するデータがＭＰＥＧ映像であること（ＩＰパケットではない。よって、ＩＥＣ１８８３で定められたＭＰＥＧｏｖｅ１３９４の伝送フォーマットにて伝送されることを意味する）、その要求帯域が６Ｍｂｐｓであること、家庭１のホームルータ１０９まで家庭２のホームサーバ１１０が先に確保した同期チャネル番号＃ｙの同期チャネルを使って伝送すること等が記されている。なお、ＦＡＮＰメッセージには、必要な認証情報などが入っていてもよい。この認証情報には、そのＦＡＮＰパケットの送出元が家庭２のホームルータ（あるいは家庭２のユーザ）である旨の情報や、そのＦＡＮＰパケットが改ざんされていないことを証明する認証情報等が含まれていてもよい。
【０２１８】
ＦＡＮＰメッセージを受信した家庭１のホームルータ１０９の動作は、図１２等を参照しながら説明した場合とほぼ同様である。すなわち、家庭１のホームルータ１０９内のスイッチ使用許可テーブル１１１３を参照して、家庭２のユーザが家庭１のホームルータにおいて、１３９４スイッチ１１０３を介してデータリンクレイヤの識別子のみの参照により、パケット（フレーム）のフォワーディングを行なってもよいかどうかについてチェックを行ない、これが許可されている場合には、その導通を許可する。
【０２１９】
ここで、スイッチ使用許可テーブル１１１３への設定については、例えば図２３のように、導通が許可されるユーザあるいは端末、ホームルータの一覧表が用意されており、このテーブルへの設定という形で、該設定が行なわれる。
【０２２０】
さて、家庭１内のホームルータは、導通が許可されると、家庭１内の家庭内ネットワークにおいて、同期チャネル＃ｚを確保し、家庭１のホームルータ１０９は、マンションバックボーン網側の同期チャネル＃ｙと、家庭１の家庭内バックボーン網側の同期チャネル＃ｚとが互いに対応することを認識し、図１２等を参照しながら説明した場合と同様に、内部の１３９４スイッチ１１０３のテーブルの設定を行う。
【０２２１】
結局、実際の家庭２のデジタルＶＴＲ４０３から、家庭１のＰＣ４０２への映像データは、家庭２の家庭内バックボーン網、家庭２のホームルータ１１０の１３９４スイッチ、マンションバックボーン網、ホームルータ１０９の１３９４スイッチ、家庭１の家庭内バックボーン網を通して、ＰＣ４０２に到達する。よって、家庭１のＰＣ４０２上で家庭２のデジタルＶＴＲ４０３−２からの映像を見ることができるようになる。
【０２２２】
この場合、転送されるデータは必ずしもＩＰパケットではないこと、１３９４スイッチの使用のための認証のステップがＦＡＮＰ内の領域として確保してもろいこと等から、この同期チャネルおよびデータリンクスイッチングの場合は、ホームルータ内でのＩＰパケット毎のパケットフィルタリング／ファイアウオール処理を省略することができる。これは、一般にパケットフィルタリングは処理負荷のかかるため、映像通信などの広帯域通信を行う場合には、極めて有益である。しかしながら、パケットフィルタリング無しでのパケット透過ができてしまうことから、認証等の運用は慎重に行うべきであることは言うまでもない。
【０２２３】
インターネットサーバ１０８は、インターネットにアクセスする際の代理サーバとＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）の働きをする。端末（例えば、ＰＣ４０２）は、インターネットサーバ１０８にまずアクセスする。インターネットサーバ１０８は、いわゆるプロキシサーバや、ＮＡＴの機能を使うことにより、マンション内部のアドレス構造が外部に見えないようにしている。よって、マンション内部ではプライベートＩＰアドレスでの運用が可能である。
【０２２４】
さて、上記ではネットワークレイヤのパケットをそれより下位のレイヤの処理によってスイッチングする際のセキュリティーに関してホームルータとＩＥＥＥ１３９４に適用した場合について説明しているが、以下では、これを一般的なラベルスイッチングに適用した例を示す。
【０２２５】
ここで、以下の説明で使用される語句と、これまでの実施形態において使用された語句との対応について示しておく。なお、基本的に、以下の説明で使用される語句は、これまでの実施形態において使用された語句を包含するより一般的な概念である。
・「パケットストリーム」は、「データ（例えば映像データ）」と対応する。
・「チャネル識別子（ラベル）」は、「リンクレイヤの識別子（例えば同期チャネル番号）」と対応する。
・「ラベルスイッチングによるパケット転送」は、「同期チャネル＃ｘ：＃ｙの対応関係が設定テーブルに記憶された１３９４スイッチによるデータ転送」／「１３９４スイッチによる、データリンクレイヤ識別子のみの参照で行われるパケット（フレーム）のフォワーディング」／「導通」／「データリンクスイッチング」と対応する。
・「ＬＳＰの中継点のルータ」は、「マンションバックボーン網と家庭内網との境界にあるホームルータ」と対応する。
・「ＬＳＰ設定要求メッセージ」は、「ＦＡＮＰメッセージ」と対応する。
・「ＬＳＰ設定要求メッセージの送信元を示す情報（ＬＳＰを設定してあげるべき隣接ルータ（登録された）との比較対象となるもの）」は、「ＦＡＮＰパケットの送出元が家庭２のホームルータである旨の情報（導通が許可される主体（登録された）との比較対象となるもの）」と対応する。
・「ＬＳＰに流したいストリームに関する情報（宛先）」は、「ターゲット端末のＩＰアドレス」と対応する。
・「ポリシーテーブル」は、「スイッチ使用許可テーブル」と対応する。
なお、「ＬＳＰの始点となるノード」と、「（この）ＬＳＰに流したいストリームの送信元」とを、以下では区別して説明するが、これまでの実施形態においてはそれらが同じもの（家庭２のユーザあるいは端末）である例を示した。これまでの実施形態でも、家庭２のユーザあるいは端末が、導通が許可される主体（登録された）との比較対象となり得ることは示されている。
【０２２６】
以下では、キャンパス／企業網、インターネットサービスプロバイダー（ＩＳＰ）網などから構成される広域ＩＰネットワークにおいて、ラベルスイッチングパス（ＬＳＰ）を設定する範囲の限定、およびＬＳＰを利用できるパケットストリームの限定を行う実施形態について説明する。これら範囲や対象の限定は、後述するＬＳＰ設定制御手順によって行われる。
【０２２７】
本発明では、例えば、あるセグメントにとって、すべての外部セグメントから／へのパケットストリームの送受信はしないか、あるいは特定のパケットストリーム（送受信アドレスやアプリケーション等により指定される）に限定して外部セグメントとのパケット送受信をしたいような場合、セグメント外部のノードを始点／終点とするＬＳＰの設定はしないか、あるいは特定のストリームしか送受信されないことが確実な場合に限りセグメント外部を始点／終点とするＬＳＰ設定を行えることが望ましい。
【０２２８】
また、例えば、あるセグメントにとって、特定のセグメントとの間でのみＬＳＰによるパケットストリームの送受信を行って、その他のセグメントから／へのパケットストリームの送受信はしないか、あるいはパケット毎のフィルタリングを行いたいような場合、その特定のセグメント内のノードを始点／終点とするＬＳＰのみを設定できることが望ましい。さらに特定のセグメントとの間で特定のパケットストリームに限定して送受信したいような場合、そのセグメントとの間で特定のストリームしか送受信されないことが確実な場合に限りそのセグメントとのＬＳＰ設定を行えることが望ましい。
【０２２９】
また、例えば、あるセグメントにとって、他のセグメントにまたがるＬＳＰの設定を、ＬＳＰの始点や終点による制限ではなく、隣接するセグメントによる制限として、１）あらかじめ契約等により定めた特定の隣接セグメントの特定の隣接ルータにまたがるＬＳＰ設定に制限したい場合、２）あらかじめ契約等により定めた特定の隣接セグメントにまたがる特定のストリームを運ぶＬＳＰに制限したい場合、３）上記の１）と２）の両方の制限をしたい場合、などが考えられる。
【０２３０】
以上のように、ラベルスイッチングを利用した場合でも特定のセグメントに／から流入／流出するパケットストリームを制限することで従来と同様のセキュリティ機能を維持できること、また特定のセグメントとの間や特定のセグメントの特定の隣接ルータとの間でのＬＳＰ設定に限定することで通信帯域やラベル値などの網リソースの消費を制限できることが望ましい。
【０２３１】
なお、隣接ルータとは、物理リンクで直接接続された隣接ルータだけでなく、なんらかの論理リンク（データリンク層の仮想コネクションあるいはＬＳＰで作られたトンネルなど）によって接続されたルータも含むものとする。
【０２３２】
図２４に、広域ＩＰネットワークの一例を示す。図２４に示されるように、この広域ＩＰネットワークは、３つのネットワークセグメント、すなわち、境界ルータ２０１１，２０１２，２０１３，２０１４および内部ルータ２０１５，２０１６より構成されるネットワークセグメント２０１０、境界ルータ２０２１，２０２２，２０２３，２０２４および内部ルータ２０２５より構成されるネットワークセグメント２０２０、境界ルータ２０３１，２０３２，２０３３および内部ルータ２０３４より構成されるネットワークセグメント２０３０を含んでいる。本ネットワークでは、ネットワークセグメント２０１０とネットワークセグメント２０２０とは、２個所（すなわち、境界ルータ２０１２−２０２１間と境界ルータ２０１３−２０２４間）で相互接続されているものとする。なお、各ネットワークセグメントは、図示したルータ以外に他のルータを含んでいても良い。
【０２３３】
図２５に、本実施形態に係るラベルスイッチルータの構成例を示す。本実施形態に係るＬＳＰ設定制御手順は、このラベルスイッチルータによって行われる。
【０２３４】
図２５に示されるように、このラベルスイッチルータは、ＡＴＭセル、フレームリレーフレーム、あるいは他の形式のラベルヘッダの付与されたフレームの送受信を行う、ｋ（ｋは任意数）個の送受信インタフェース部４００１−１〜４００１−ｋ、いずれかの送受信インタフェース部（４００１−１〜４００１−ｋ）で受信したフレームの受信ラベル値をもとに決定された他のいずれかの送受信インタフェース部（４００１−１〜４００１−ｋ）へフレームを転送するスイッチ部４００３、コントローラ部４０００を備えている。
【０２３５】
コントローラ部４０００は、ラベル付きフレームからレイヤ３パケットを抽出し（フレームをパケットに変換し）およびその逆変換（パケットからフレームへの変換）を行うフレーム・パケット変換部４００４、レイヤ３パケットの転送処理（データパケットであれば経路表４０１１に従い所定の次段ノードへの転送処理、制御パケットであれば制御メッセージ処理部４００６へ転送）を行うパケット転送部４００５、ＬＳＰ制御（設定・解放、隣接認識など）に関わるメッセージの送受信処理を行いＬＳＰ制御部４００７への通知を行う制御メッセージ処理部４００６、ＬＳＰの状態管理や設定・解放制御に関わる処理を行うＬＳＰ制御部４００７、ＬＳＰ設定・解放に伴うスイッチ部４００３の設定変更等の制御を行うスイッチ制御部４００８、後述するＬＳＰ設定可否の判断に関するポリシー的なルールを記憶するポリシー管理部４００９、ラベル値や通信帯域などの網リソースの観点からＬＳＰ設定が可能か否かを判断するためのリソース使用状況を記憶するリソース管理部４０１０、レイヤ３ルーティングプロトコルに基づき管理する経路情報を記憶する経路表４０１１、などから構成される。
【０２３６】
なお、パケット転送部４００５として説明した、データパケットを経路表４０１１に従い所定の次段ノードへ転送する機能は、持たないように本装置を構成することも可能である。
【０２３７】
以下では、図２４の広域ＩＰネットワークと図２５のラベルスイッチルータを用いて、設定可否の制御のバリエーションに関して４つのＬＳＰ設定制御の例について順番に説明する。なお、以下では、ネットワークセグメントを略してセグメントと呼ぶものとする。
【０２３８】
＜隣接セグメント（隣接ルータ）により設定可否を制御する例（第１の例）＞まず、第１の例として、ラベルスイッチを行うルータが、隣接ルータ毎にＬＳＰ提供を許容するか否かのポリシーを記憶し、その記憶内容に基づきＬＳＰ設定可否を制御する例について説明する。
【０２３９】
図２４において、例えば、セグメント２０１０とセグメント２０２０の２個所の接続点のうち、セグメント２０１０の一方の境界ルータ２０１２においてセグメント２０２０（境界ルータ２０２１）に対するＬＳＰ提供サービスを行い、他方の境界ルータ２０１３においてはセグメント２０２０（境界ルータ２０２４）に対するＬＳＰ提供サービスを行わないものとする。
【０２４０】
まず、セグメント２０１０の境界ルータ２０１２とセグメント２０２０の境界ルータ２０２１との間では、ＬＳＰ制御を行うための隣接ノードとしての隣接認識手順を実行している。これは例えば、自ノードのアドレス等の識別子を含んだＨＥＬＬＯメッセージとそれへの応答メッセージの相互のやり取り、およびＫＥＥＰＡＬＩＶＥメッセージによる継続的な隣接認識の確認等により実現される。なお、この隣接認識手順で交換されるメッセージには、お互いが契約している隣接ルータかどうかを認識するための認証情報（パスワードあるいは情報内容を特定の鍵で暗号化したビット列など）を含ませるようにしてもよい（このようにすれば、より安全性を向上させることができる）。
【０２４１】
上記のような隣接認識手順の後、境界ルータ２０１２と境界ルータ２０２１との間での実際のＬＳＰ設定、解放、経路変更などの各種制御メッセージのやり取りのためのセッションが確立され、以後そのセッション上で各種制御メッセージをやり取りすることが可能になる。
【０２４２】
次に実際に、セグメント２０２０からセグメント２０１０の方向へ向けて転送する特定のパケットストリームのために、セグメント２０２０の境界ルータ２０２１がセグメント２０１０の境界ルータ２０１２に対してＬＳＰ設定要求メッセージを送信する場合の動作について説明する。
【０２４３】
図２６に、ＬＳＰ設定要求メッセージ受信時における判断処理の手順の一例を示す。
【０２４４】
ここで、図２７に、ＬＳＰ設定要求メッセージのメッセージ形式の２つの例を示す。図２７に示すように、ＬＳＰ設定要求メッセージに含まれる情報には、ＬＳＰに流したいストリームに関する情報、実現したいＣｏＳ（クラスオブサービス）に関する情報、メッセージの送信元を示す情報（メッセージ送信元情報）などが含まれる。さらに、後述する例のように、ＬＳＰの始点を表す情報を含めるようにしてもよい（本例では、含めなくても構わない）。
【０２４５】
図２７の（ａ）の例では、メッセージ送信元情報は、ＬＳＰ設定要求メッセージのヘッダ内に記載された送信元レイヤ３アドレスから抽出する。図２７の（ｂ）の例では、メッセージ送信元情報は、ＬＳＰ設定要求メッセージの情報フィールドに記載される。
【０２４６】
また、図２８に、ポリシーテーブルの一例を示す。
【０２４７】
ポリシーテーブルには、ＬＳＰの設定（中継）を行うべき隣接ルータの識別する情報（レイヤ３アドレスなど）の一覧が記載さいている。後述するような、さらにそのＬＳＰを利用するストリームまで制限するような場合には、その許容するストリーム情報が記載される（ストリーム情報を限定しない場合には、その欄もしくは記載は不要である）。なお、そのＬＳＰに提供すべきＣｏＳ値を限定するような場合には、そのＣｏＳ値も記載される（ＣｏＳ値を限定しない場合には、その欄もしくは記載は不要である）。
【０２４８】
さて、境界ルータは、ＬＳＰ設定要求メッセージを受信すると、ステップＳ２０１にて、このメッセージの送信元ルータが登録されているものであるか否かを判断する。
【０２４９】
具体的には、ＬＳＰ設定要求メッセージを受信した境界ルータ２０１２のＬＳＰ制御部４００７では、まず、メッセージの送信元情報（および必要な場合にＣｏＳ情報）を抽出し、ＬＳＰの中継をすべきノードからのメッセージか否かをポリシー管理部４００９に問い合わせる（なお、本例では、ストリーム情報はポリシー管理部４００９での判定には用いない）。
【０２５０】
ポリシー管理部４００９では、図２８に例示したようなポリシーテーブルを参照し、メッセージ送信元情報に示されたノードがポリシーテーブルに登録されているか否かをチェックする。
【０２５１】
このポリシーテーブルの参照の結果、ＬＳＰ設定要求元があらかじめ契約等によりＬＳＰを提供すべきセグメント２０２０の境界ルータ２０２１であるか否かを判断する（なお、前述の認証情報による認証を採用する場合には認証情報のチェックも併せて行う）。さらにＬＳＰ設定要求メッセージに要求ＣｏＳが含まれている場合には、要求ＣｏＳ値とポリシーテーブル内の許容ＣｏＳ値とを比較し、受付け可否を判断する。
【０２５２】
設定要求メッセージの送信元が契約しているセグメントの登録されたルータ以外である場合（またはメッセージ内の要求ＣｏＳ値がポリシーテーブル内の許容値により条件を満足しない場合）には、ＬＳＰ制御部４００７は、設定要求を拒絶することになる。
【０２５３】
このとき、拒絶を通知するメッセージ（このメッセージ内に拒絶の理由を記述するようにしてもよい）を制御メッセージ処理部４００６から返送するように取り決めてもよいし、あるいは特にメッセージは返送しないように取り決めてもよい（後者の場合、送信元ノードが、例えば、応答メッセージが返ってこないことから直ちに、あるいは規定回数だけ要求メッセージを再送しても応答メッセージが返ってこないことから、拒絶されたものと判断する）。なお、この点は、後述する第２〜第４の例の場合も同様である。
【０２５４】
なお、設定要求メッセージには、メッセージ送信元が確かに正しい送信元であることをメッセージの受信側が確認するための認証情報が含まれていることがあるが、この場合にはメッセージ送信元情報とともに認証情報をＬＳＰ制御部４００７において確認した上で、受信メッセージを受け付ける否かを判断する。
【０２５５】
さて、受信メッセージ内のメッセージ送信元情報（および必要な場合にＣｏＳ値）とポリシーテーブルの比較チェックにより、受信したＬＳＰ設定要求メッセージを処理しても良いと判断した境界ルータ２０１２は、次に、ステップＳ２０２にて、ラベル（あるいは必要なら帯域）などの網リソースが確保できるか否かなどをリソース管理部４０１０に問い合わせ、ここでＬＳＰ設定要求を受け付け可能であるか否かの判断が行われる。
【０２５６】
受け付け可能であると判断した場合には、例えば、境界ルータ２０２１に対してＬＳＰ設定要求の受け付けを示すメッセージ（要求ストリームに割り当てられるラベル情報などが含まれる）を返送するとともに、要求ストリームに関する次段（下流）ルータ（図２４では例えばルータ２０１５）に対して同様のＬＳＰ設定要求メッセージを制御メッセージ処理部４００６から送信する。なお、応答メッセージのバリエーションについては後に言及する。
【０２５７】
以下、ルータ２０１５，２０１６などの下流のルータでは、上流隣接ルータから受け取ったＬＳＰ設定要求に対して、境界ルータ２０１２が行ったのと同様にメッセージ送信元情報等のポリシー情報のチェックおよび必要な場合に網リソースチェックを行い、また必要に応じて所定のメッセージを送信する。
【０２５８】
これによって、例えばルータ２０２１→ルータ２０１２→ルータ２０１５→…といったラベルスイッチングパスが設定される。
【０２５９】
上記では、ルータ２０１５，２０１６などの下流のルータが境界ルータ２０２１と同様の判断を行うとして説明したが、同一のセグメント内の隣接ルータから受信したメッセージであることが保証されるような場合に関しては、メッセージ送信元情報のチェックを省略するようにしてもよい。例えば、ルータ２０１５がメッセージを受信したインタフェース（図２４では４００１−１〜４００１−ｋ）には、ポイント−ポイント接続により同一セグメントのルータ２０１２が接続されている場合には、セグメント外部の他のルータが偽ってルータ２０１２から送信したように見せかけてルータ２０１５にメッセージを送ることはほぼ不可能であるため、ルータ２０１５におけるメッセージ送信元情報の認証を不要とすることができる。一方、例えば、ルータ２０１５とルータ２０１２がスイッチ等により接続されていて、かつそのスイッチ経由でルータ２０１５とセグメント外のルータとが直接接続可能であるような場合には、セグメント外部のルータが偽ってルータ２０１２から送信したように見せかけてルータ２０１５にメッセージを送出できる可能性があるため、ルータ２０１５においても境界ルータ２０１２と同様にメッセージ送信元情報のチェックを行う方が好ましい。
【０２６０】
なお、契約しているセグメントの登録されたルータ以外の隣接ルータに対しては、（１）ラベルスイッチの隣接ルータとしての隣接認識手順は登録されているルータの場合と同様に実行するが、個々のＬＳＰ設定要求時に送信元をチェックし拒絶する、（２）隣接認識手順は実行するが、その認識手順においてＬＳＰ設定要求は拒絶する旨を明示する、（３）隣接認識手順自体あるいはそれに続く制御メッセージ用セッションの確立自体を拒絶する、などのいずれかによりＬＳＰの提供を拒絶することになる。
【０２６１】
ところで、上記では、ＬＳＰ設定要求メッセージを受信したルータが、これを受け付け可能であると判断した場合に、上流ノードに受け付けを示すメッセージを返送するとともに、下流ノードにＬＳＰ設定要求メッセージを送信する例で説明したが、応答メッセージのやり取りに関しては一般的なラベルスイッチングプロトコルにおいて種々のバリエーションがあり、本発明はそのいずれにも適用可能である。例えば、受け付け可能であると判断した場合に上流ノードに受け付けを示すメッセージをすぐには送信せずに下流ノードにＬＳＰ設定要求メッセージを送信することを、各ノードが次々と行った後に、設定されるラベルスイッチングパスの最下流側のノードから上流側に次々と受け付けを示すメッセージを伝える（すなわち、下流ノードから受け付けを示すメッセージを受信したら、上流ノードに受け付けを示すメッセージを送信する）ようにしてもよい。また、自ノードの下流ノードで拒絶の判断がされた場合に、上流ノードに受け付けを示すメッセージを出すことで、可能な範囲でパスを設定するようにしてもよいし、あるいは自ノードの下流ノードで拒絶の判断がされた場合に、上流ノードに拒絶を通知するメッセージを出してこの場合にはパスは一切設定しないようにしてもよい（この場合、他のノードは下流ノードから拒絶を通知するメッセージを受信したら、自装置で受け付けの判断がされていても上流ノードに拒絶を通知するメッセージを送信する）。また、その他にも種々のバリエーションが存在する。なお、この点は、後述する第２〜第４の例の場合も同様である。
【０２６２】
さて、図２８に例示したポリシーテーブルの登録内容には、ＬＳＰを提供するか否かという情報に加えて、通信品質を問わないベストエフォット（低い通信クラス）のＬＳＰのみに限定した提供なのか、所定の通信品質クラスあるいは具体的な通信品質値を実現するＬＳＰも提供するのか等の情報も含むことが可能であるが、そのようにした場合には、上述した隣接認識手順あるいはその後に行われる制御メッセージ用セッション確立手順においてその通信品質等の付随情報を交換、交渉するようにしてもよい。なお、図２８のポリシーテーブルにはＬＳＰを提供可能なパケットストリームに関する情報も含むことが可能であるが、これを利用する例については、次の第２の例で述べる。この第１の例では、このＬＳＰを利用するストリーム情報は問わない（ワイルドカード）で隣接ルータ情報（および必要な場合に通信品質情報）からＬＳＰ設定可否を判断する場合に関して説明した（もちろん、この第１の例では、図２８の内容からストリーム情報の欄を省いた構成のポリシーテーブルを用いてもよい）。
【０２６３】
あるパケットストリームのためのＬＳＰ設定要求をいずれかの理由により拒絶した境界ルータ２０１２が、そのＬＳＰ設定を拒絶した相手の境界ルータからのパケット（ラベルの付与されていないもの）を受信した場合には、パケット転送処理部４００５もしくはスイッチ部４００３が、以下のような動作を行う。すなわち、受信したパケットを廃棄する（パケットの受信すら拒絶する）、あるいは従来のネットワーク層のヘッダ処理を行って次段のルータ２０１５を選択し、選択した次段ルータ２０１５へ向けてパケットを転送する（ホップバイポップ転送処理を行う）、あるいは自ノードが始点となって設定されているＬＳＰにそのパケットを転送する、などの対処が考えられる。登録されていない通信品質クラスを要求したためにＬＳＰ設定を拒絶されたパケットストリームに属するパケットを境界ルータ２０１２が受信した場合には、境界ルータ２０１２を始点として、あるいは境界ルータ２０２１から境界ルータ２０１２を中継点として設定されている別の（低品質の）ＬＳＰのうちで、パケットストリームの定義を満たすものが存在する場合には、受信パケットにネットワーク層処理を行って、そのＬＳＰへパケットを転送することも可能である。あるいは、登録されていない通信品質クラスを要求された場合に、境界ルータ２０１２が上流側のラベルと下流側の低品質のラベルとを対応付け、受信パケットにネットワーク層処理を行わずに、境界ルータ２０１２を中継点とする、設定が要求されたＬＳＰとは別のＬＳＰでパケットストリームの定義を満たすものの上へパケットを転送することもできる。
【０２６４】
＜隣接セグメント（隣接ルータ）およびストリーム情報により設定可否を制御する例（第２の例）＞
次に、第２の例として、ラベルスイッチルータが、隣接ルータ毎にＬＳＰ提供（中継）を許容するか否か、およびどのようなパケットストリームに対してＬＳＰ提供を許容するかに関するポリシーを記憶し、その記憶内容に基づきＬＳＰ設定を制御する例について説明する。
【０２６５】
ここでは、図２４において、セグメント２０１０とセグメント２０２０の２個所の接続点のうち、セグメント２０１０の一方の境界ルータ２０１２においてはセグメント２０２０からのトラヒックに対するＬＳＰ提供をある特定のパケットストリームに限定し、他方の境界ルータ２０１３においてはセグメント２０２０からのトラヒックに対するＬＳＰ提供を別の特定のパケットストリームに限定した場合を例にとって考える。
【０２６６】
ここで、パケットストリームの定義としては、例えば、データパケットの送信元に関する情報（例えば、送信元ホストアドレス、あるいは送信元ネットワークアドレス、あるいは送信元ホストアドレスとプロトコルとポート番号の組など）と、データパケットの宛先に関する情報（例えば、宛先ホストアドレス、あるいは宛先ネットワークアドレス、あるいは宛先ホストアドレスとプロトコルとポート番号の組、あるいはルーティングドメインの出口ルータなど）とのいずれか一方、あるいは両方の組み合わせが考えられる。
【０２６７】
この例でも、ＬＳＰ設定、解放等の制御を行うための隣接ノードとしての隣接認識手順が、セグメント２０１０の境界ルータ２０１２とセグメント２０２０の境界ルータ２０２１との間、および境界ルータ２０１３と境界ルータ２０２４との間でそれぞれ実行されている。この隣接認識手順で交換される制御メッセージには、第１の例と同様に、お互いのルータのアドレス等の識別子や必要であればお互いの正当性を確認するための認識情報（パスワードあるいは情報内容を特定の鍵で暗号化したビット列など）が含まれる。どのようなパケットストリームに対してＬＳＰ提供を要求するか（あるいは提供を許容するか）に関しては、オフラインの契約等により決定され、決定した内容を境界ルータ２０１２および境界ルータ２０１３（および必要なら他の内部ルータ１０１５，１０１６等も）の各々のポリシー管理部４００９が参照する図２８に例示するようなポリシーテーブルに登録しておく。この登録内容は、個々のルータにマニュアルにより設定しても構わないし、特定のノードから何らかの手順（隣接認識手順、制御メッセージ用セッション確立手順、あるいは他の何らかの情報配布（マルチキャスト）のための手順）により配布しても構わない。
【０２６８】
例えば、セグメント２０２０の境界ルータ２０２２の下につながるネットワークアドレスを持つ送信元から送信されるパケットストリームは、境界ルータ２０２１→境界ルータ２０１２の経路で転送し、境界ルータ２０２３の下につながるネットワークアドレスを持つ送信元から送信されるパケットストリームは境界ルータ２０２４→境界ルータ２０１３の経路で転送するようなトラヒック分散を図る場合には、その内容をオフラインの契約あるいは隣接認識手順等によって決定し、境界ルータ２０１２，２０１３のポリシーテーブルに記憶させる。なお、ＬＳＰの経路が通常のルーティングプロトコルによって決定される経路と異なる場合には、各々のストリーム用のＬＳＰが指定したい経路上に設定されるように、ＬＳＰ設定要求メッセージの中に経路情報（例えば、境界ルータを２０２２→２０２５→２０２１→２０２１のように経由するという指定）を陽に含ませるようにしてもよい。
【０２６９】
次に実際に、セグメント２０２０の境界ルータ２０２１がセグメント２０１０方向へ向けて転送する特定のパケットストリームのために、セグメント２０２０の境界ルータ２０２１がセグメント２０１０の境界ルータ２０１２に対してＬＳＰ設定要求メッセージを送信する場合の動作について説明する。
【０２７０】
図２９に、ＬＳＰ設定要求メッセージ受信時における判断処理の手順の一例を示す。
【０２７１】
ポリシーテーブルは先に図２８に例示したものを用いるものとする。なお、図２８中の「＊」は、その項目については制限しない（その項目についてはどのようなものであっても許可する）ことを意味している。例えば、ストリーム情報に関して、第１番目のエントリでは隣接ルータアドレスが１３３．１９９．１９．０ならばストリーム情報はどのような値でも許し、第２番目のエントリでは隣接ルータアドレスが１３３．１９９．９８．０で、かつ、パケットストリームのソースアドレスの上位１６桁が１３３．１９６または１３３．１９５ならば許す（ソースアドレスの残りの下位１６桁とディスティネーションアドレスの全桁はどのような値でもよい）ことを示している。
【０２７２】
さて、ＬＳＰ設定要求メッセージを受信した境界ルータ２０１２では、まず、第１の例と同様に、ポリシー管理部４００９において要求メッセージの送信元をチェックし（ステップＳ２１１）、それがあらかじめポリシーテーブルに隣接ルータとして登録されていることを確認した時点で、その設定要求を処理するための手順を実行する。そうでない場合は設定要求を拒絶する。その際、第１の例と同様に、ＬＳＰ設定要求メッセージには認証情報を含ませ、この情報に関して境界ルータ２０１２でチェックするようにしてもよい。
【０２７３】
メッセージの送信元のチェックにより、ポリシー管理部４００９において受信したＬＳＰ設定要求メッセージを処理しても良いと判断した境界ルータ２０１２は、次に、ＬＳＰ設定要求メッセージ内のパケットストリーム情報を解析し、ＬＳＰ利用の対象として登録されているストリームに含まれるものであるか否かをポリシーテーブルによりチェックする（ステップＳ２１２）。
【０２７４】
なお、ステップＳ２１１の判断とステップＳ２１２の判断は１回のポリシーテーブル検索にて併せて行うようにしてもよい。
【０２７５】
要求されたストリームがポリシーテーブルに登録されているストリームに含まれていない場合には、その時点で要求を拒絶することになるが、登録されているストリームに含まれている場合には、次に、そのＬＳＰのためにラベル（あるいは必要なら帯域）などの網リソースが確保できるか否かなどをリソース管理部４０１０により判断して最終的にＬＳＰ設定要求を受け付け可能であるかを判定する（ステップＳ２１３）。
【０２７６】
受け付け可能であると判断した場合の手順は第１の例と同様である。
【０２７７】
以下、ルータ２０１５，２０１６などの下流のルータでも、受け取ったＬＳＰ設定要求に対して、境界ルータ２０１２が行ったのと同様にメッセージの送信元情報のチェック（および認証等）、要求ストリームの登録有無チェックおよび網リソースチェックのすべてを行う。あるいは、第１の例で説明したものと同様に、同一のセグメント内の隣接ルータから受信したメッセージであることが保証されるような場合に関してはメッセージ送信元情報のチェックを省略するようにしてもよい。また、同一のセグメント内のルータから受信したメッセージであることが確実で、すでに上流でポリシーチェックが行われていると思われる場合（ＬＳＰ設定要求メッセージに、同一の網セグメント内の上流にあるいずれかのルータがストリームについてのポリシーチェックを行って受付可能と判断したということが示されている場合など）には登録ストリームか否かのチェックを省略してもよい。
【０２７８】
あるパケットストリームのためのＬＳＰ設定要求をいずれかの理由により拒絶した境界ルータ２０１２が、そのＬＳＰ設定を拒絶した境界ルータから拒絶したストリームに属するパケット（ラベルの付与されていないもの）を受信した場合には、受信したパケットを廃棄する（パケットの受信すら拒絶する）、あるいは従来のネットワーク層のヘッダ処理を行って次段のルータ２０１５を選択し、選択した次段ルータ２０１５へ向けてパケットを転送する（ホップバイポップ転送処理を行う）、あるいは自ノードが始点となって設定されているＬＳＰにそのパケットを転送する、などの対処が考えられる。登録されていない通信品質クラスを要求したためにＬＳＰ設定を拒絶されたパケットストリームに属するパケットを境界ルータ２０１２が受信した場合には、境界ルータ２０１２を始点として、あるいは境界ルータ２０２１から境界ルータ２０１２を中継点として設定されている別の（低品質の）ＬＳＰのうちで、パケットストリームの定義を満たすものが存在する場合には、受信パケットにネットワーク層処理を行って、そのＬＳＰへパケットを転送することも可能である。あるいは、登録されていない通信品質クラスを要求された場合に、境界ルータ２０１２が上流側のラベルと下流側の低品質のラベルとを対応付け、受信パケットにネットワーク層処理を行わずに、境界ルータ２０１２を中継点とする、設定が要求されたＬＳＰとは別のＬＳＰでパケットストリームの定義を満たすものの上へパケットを転送することもできる。
【０２７９】
以上説明した手順と同様の手順がもう一方の境界ルータ２０１３，２０２４間においても実行される。
【０２８０】
なお、図２８のテーブルでは、パケットストリームがどこから来るか（送信元）でそれ用のＬＳＰの設定可否を判断する例を示したが、どこへ行くパケットストリームなのか（宛先）で設定可否を判断する、あるいは組合せでどこからどこへのストリームなのかで可否を判断することも、勿論可能である。
【０２８１】
＜ストリーム情報により設定可否を制御する（第３の例）＞
次に、第３の例として、第２の例と同様にセグメント２０１０がセグメント２０２０からの特定のパケットストリームに限定してＬＳＰによる転送サービスを提供するが、セグメント２０１０とセグメント２０２０の間の２つの接続点のうちのどちらを通過するかを特に限定しない場合のＬＳＰ接続動作について説明する。
【０２８２】
パケットストリームの定義としては、第２の例と同様、例えば、データパケットの送信元に関する情報（例えば、送信元ホストアドレス、あるいは送信元ネットワークアドレス、あるいは送信元ホストアドレスとプロトコルとポート番号の組など）と、データパケットの宛先に関する情報（例えば、宛先ホストアドレス、あるいは宛先ネットワークアドレス、あるいは宛先ホストアドレスとプロトコルとポート番号の組、あるいはルーティングドメインの出口ルータなど）とのいずれか一方、あるいは両方の組み合わせが考えられる。
【０２８３】
この例でも、第１、第２の例と同様、ＬＳＰ設定、解放等の制御を行うための隣接ノードとしての隣接認識手順が、セグメント２０１０の境界ルータ２０１２とセグメント２０２０の境界ルータ２０２１との間、および境界ルータ２０１３と境界ルータ２０２４との間で実行されている。また、第２の例と同様、どのようなパケットストリームに対してＬＳＰ提供を要求するか（あるいは提供を許容するか）に関しては、オフラインの契約により決定され、決定した内容を少なくとも境界ルータ２０１２および境界ルータ２０１３の各々のポリシーテーブルに設定しておく。第２の例とは異なり、特に境界ルータによって意識的にストリームの分散を行わない場合、許容するパケットストリームの情報に関しては、両方の境界ルータに同じ設定をしておけばよい（この第３の例では、ポリシーテーブルがストリーム情報の欄のみからなっていても構わない）。
【０２８４】
次に実際に、セグメント２０２０の境界ルータ２０２１がセグメント２０１０方向へ向けて転送する特定のパケットストリームのために、セグメント２０２０の境界ルータ２０２１がセグメント２０１０の境界ルータ２０１２に対してＬＳＰ設定要求メッセージを送信する場合の動作について説明する。ＬＳＰ設定要求メッセージ受信時における判断処理の手順は先に図２９に例示したものからステップＳ２１１の判断を省いたものを用いるものとする。ポリシーテーブルは先に図２８に例示したものを用いるものとする。
【０２８５】
まず、ＬＳＰ設定要求メッセージを受信した境界ルータ２０１２では、第１や第２の例で行っていた（ステップＳ２０１やステップＳ２１１での）隣接ルータのチェックは行わずに、ＬＳＰ設定要求メッセージ内のパケットストリーム情報をポリシー管理部４００９にて解析し、あらかじめ契約あるいは隣接認識手順によりポリシーテーブルに登録されているストリームに含まれるものであるか否かをチェックする（ステップＳ２１２）。
【０２８６】
登録されているストリームである場合には、次に、ラベル（あるいは必要なら帯域）などの網リソースが確保できるか否かなどを考慮してＬＳＰ設定要求を受け付け可能であるか否かをリソース管理部４０１０にて判定する（ステップＳ２１３）。
【０２８７】
受け付け可能であると判断した場合の手順は第１および第２の例と同様である。
【０２８８】
以下、ルータ２０１５，２０１６などの下流のルータでも、受け取ったＬＳＰ設定要求に対して、境界ルータ２０１２が行ったのと同様に、登録ストリームのチェックおよび網リソースチェックのすべてを行うようにしてもよいし、あるいは第１、第２の例と同様に、同一のセグメント内のルータから受信したメッセージであることが確実で、すでに上流でポリシーチェックが行われていると思われる場合（ＬＳＰ設定要求メッセージに、同一の網セグメント内の上流にあるいずれかのルータがストリームについてのポリシーチェックを行って受付可能と判断したということが示されている場合など）には登録ストリームか否かのチェックを省略してもよい。
【０２８９】
ＬＳＰを提供するストリーム情報に関する契約、登録に際しては、付加情報として、ストリーム毎にベストエフォットのＬＳＰのみに限定するのか、所定の通信品質クラスあるいは具体的な通信品質値を実現するＬＳＰも提供するのか等の情報も付随して登録することも可能である。その場合には、上述した隣接認識手順や制御用セッション確立手順等においてそうしたストリーム情報毎に通信品質クラス等の付随情報を交換、交渉するようにしてもよい。また、ＬＳＰ要求設定時の受け付け可否判定においても、登録ストリームか否かのチェックの際に、通信品質クラスに関しても登録されているものに反していないかのチェックをポリシーテーブルにより行い、それが許容された場合に実際の網リソースのチェックを行うことになる。
【０２９０】
あるパケットストリームのためのＬＳＰ設定要求をいずれかの理由により拒絶した境界ルータ２０１２が、そのＬＳＰ設定を拒絶した境界ルータから拒絶したストリームに属するパケットを受信した場合の処理については、第２の例と同様である。
【０２９１】
以上説明した手順と同様の手順がもう一方の境界ルータ２０１３，２０２４間においても実行される。
【０２９２】
以上説明した、第１〜第３の例では、ストリームの上流方向から下流方向へ向けてＬＳＰ設定の要求を行い、下流側から上流側へそれに対する可否の応答を返すという方法を例にして説明したが、ストリームの下流側から上流側へ向けてＬＳＰ設定要求を行い、上流から下流へ向けてその可否の応答を返す方法の場合でも同様のメカニズムを適用することができる。
【０２９３】
＜始点情報により設定可否を制御する（第４の例）＞
次に、第４の例として、ＬＳＰ設定要求を起動する始点ノード（ルータもしくはホスト）の情報がＬＳＰ設定要求メッセージに含まれ、その始点情報をもとにＬＳＰ設定要求の受け付け可否を判断する例について説明する。
【０２９４】
始点ノードの情報は、ＬＳＰ設定要求メッセージ内に明示的に記載されている場合には、それを用いればよいし、ＬＳＰ設定要求メッセージ内のパケットストリームの情報（例えば送信元ネットワークアドレス等）から始点ノードを求めることができる場合には、そのようにして求めたものを用いてもよい。
【０２９５】
ここでは、例えば、セグメント２０３０において、外部セグメントからのＬＳＰについては、セグメント２０２０内の境界ルータ２０２１を始点とするＬＳＰのみ設定を許容し、それ以外の場合には外部セグメントからのＬＳＰ設定を受け付けない場合について考える。さらに、そのＬＳＰにて運ばれるストリームの限定については、１）データパケットの送信元アドレスとして特定のホストアドレスあるいは特定のネットワークアドレスを持つパケット、２）データパケットの送信元アドレスは限定しないが、特定のアプリケーションのパケット（プロトコル番号やポート番号で指定される）、３）データパケットの送信元アドレスとして特定のホストアドレスあるいは特定のネットワークアドレスを持ち、かつ、特定のアプリケーションのパケット（すなわち、上記の１）と２）を組み合わせたもの）、４）特にストリームは限定しない、などが考えられる。ＬＳＰが設定されると始点ノードが実際にデータパケットをそのストリーム用のＬＳＰへ送出する動作を行うため、始点ノードが信用できる（登録された始点ノードであって認証が成功した）場合には、ＬＳＰ設定要求メッセージに記載された通りのストリームが実際にそのＬＳＰを通って流れてくると仮定してシステムを運用することが可能である。
【０２９６】
図３０に、ＬＳＰ設定要求メッセージ受信時における判断処理の手順の一例を示す。
【０２９７】
まず、要求されているＬＳＰで運ばれるストリームを限定しない場合について説明する。この場合、図３０のステップＳ２２２の判断は省かれる。
【０２９８】
図３１に、始点情報を利用してＬＳＰ設定可否判断を行うセグメント２０３０の境界ルータ２０３１内のポリシーテーブルの一例を示す。このポリシーテーブルの内容は、ＬＳＰ設定を受け付ける始点ルータとしてルータ２０２１が登録されているが、その中に流すストリームに関する情報やさらにそのＬＳＰが要求するＣｏＳ等の付加情報に関しては特に制限がない場合を示している。
【０２９９】
ＬＳＰ設定要求メッセージをルータ２０１４から受信したセグメント２０３０の境界ルータ２０３１では、メッセージ内のＬＳＰ始点ノード情報がポリシーテーブルに登録されていることを認識すると（ステップＳ２２１）、メッセージ内のストリーム情報にかかわらずＬＳＰ設定をポリシー的に（セキュリティ的に）許容できると判断する。なお、ここで、ＬＳＰの始点ノード情報には、それが信頼できる情報か否かを判断するための認証情報が一緒に含れていて、認証に失敗したＬＳＰ設定を拒絶するようにしてもよい。また、ストリーム情報も受付け可否の判断に用いる場合は、認証結果が真であったときに限り「ＬＳＰ設定要求メッセージ中のストリームに関する情報がポリシーテーブルに登録されていれば設定を許可する」という動作を行うようにしてもよい。
【０３００】
ポリシー的に受け付けられたＬＳＰ設定要求は、さらに実際のラベル（および必要ならば帯域）などの網リソースが割り当てられるか否かも判断し、最終的に設定要求を受け付けるか否かを決定する（ステップＳ２２３）。
【０３０１】
境界ルータ２０３１において設定要求を受け付けられると判断されたならば、ＬＳＰがこの境界ルータ１０３１で終端される場合にはそこから応答を表すメッセージがセグメント２０１０の境界ルータ２０１４へ返されるが、さらに先のノードまでＬＳＰが伸びる場合にはＬＳＰ設定要求メッセージを次段ルータ２０３４に送信する。
【０３０２】
後者の場合にＬＳＰ設定要求メッセージを受信したルータ２０３４では、ルータ２０３１で行ったのと同様のポリシーチェックを行ってもよいし、第１〜第３の例と同様に、同一セグメントの境界ルータ２０３１から受信したＬＳＰ設定要求にはポリシーチェックを行う必要はないと判断してそれを行わないようにしてもよい。なお、境界ルータ２０３１において、ポリシーチェックを行った旨をＬＳＰ設定要求メッセージ内に明示的に示すようにしてもよい。
【０３０３】
次に、要求されているＬＳＰで運ばれるストリームに限定を設ける場合について説明する。
【０３０４】
次に、図３２に、始点情報を利用してＬＳＰ設定可否判断を行うセグメント２０３０の境界ルータ２０３１内のポリシーテーブルの他の例を示す。このポリシーテーブルの内容は、ＬＳＰ設定を受け付ける始点ルータとしてルータ２０２１が登録されており、さらにその中に流すストリームに関する情報としてパケット送信元ネットワークアドレスが指定されている場合を示している（ＣｏＳに関する指定はここでもないものとする）。
【０３０５】
ＬＳＰ設定要求メッセージをルータ２０１４から受信したセグメント２０３０の境界ルータ２０３１では、メッセージ内のＬＳＰ始点ノード情報およびストリーム情報（パケット送信元ネットワークアドレス）がポリシーテーブルに登録されていることを認識すると（ステップＳ２２１，Ｓ２２２）、ＬＳＰ設定をポリシー的に（セキュリティ的に）許容できると判断する。なお、前述と同様に、ＬＳＰの始点ノード情報には、それが信頼できる情報か否かを判断するための認証情報が一緒に含れていて、認証に失敗したＬＳＰ設定を拒絶するようにしてもよい。
【０３０６】
ポリシー的に受け付けられたＬＳＰ設定要求は、さらに実際のラベル（および必要ならば帯域）などの網リソースが割り当てられるか否かも判断し、最終的に設定要求を受け付けるか否かを決定する（ステップＳ２２３）。
【０３０７】
以降は前述と同様で、境界ルータ２０３１において設定要求を受け付けられると判断されたならば、ＬＳＰがこの境界ルータ１０３１で終端される場合にはそこから応答を表すメッセージがセグメント２０１０の境界ルータ２０１４へ返されるが、さらに先のノードまでＬＳＰが伸びる場合にはＬＳＰ設定要求メッセージを次段ルータ２０３４に送信する。
【０３０８】
また同様に、後者の場合にＬＳＰ設定要求メッセージを受信したルータ２０３４では、ルータ２０３１で行ったのと同様のポリシーチェックを行ってもよいし、同一セグメントの境界ルータ２０３１から受信したＬＳＰ設定要求にはポリシーチェックを行う必要はないと判断してそれを行わないようにしてもよい。なお、境界ルータ２０３１において、ポリシーチェックを行った旨をＬＳＰ設定要求メッセージ内に明示的に示され、これを受けたルータ２０３４等は自分の属するセグメントの境界ルータが既にポリシーチェックを済ませたことをＬＳＰ設定要求メッセージを解釈して知った場合にはポリシーチェックを省略するようにしてもよい。
【０３０９】
他にもストリーム情報として、アプリケーションに相当するポート番号等をポリシーテーブルに登録したり、送信元アドレスとポート番号の両方をポリシーテーブルに登録してもよい。また、ＬＳＰにより提供可能なＣｏＳ情報についてもポリシーテーブルに登録してもよい。これらの場合にも、境界ルータ２０３１において、ルータ２０１４から受信したＬＳＰ設定要求メッセージ内のストリーム情報（および要求ＣｏＳ情報）とポリシーテーブル内の情報とを比較して、ポリシー的な受け付け可否判断を行う。ここでは、例えば境界ルータ２０３１がセグメント２０３０へ外部から流入するストリームからセグメント２０３０内のノードを守る場合を想定して、ストリームの送信元に関する情報に基づいて受付け可否を判断する例を説明したが、例えばルータ２０３３がセグメント２０３０から外部へ流出するストリームに対して制御をかけるために、ストリームの宛先に関する情報に基づいて受付け可否を判断するようなことも可能である。勿論、ストリームの送信元と宛先の情報を組合せて受付け可否を判断する実施形態もあり得る。
【０３１０】
このＬＳＰ設定要求メッセージ内の始点ノード情報には、それに付随した認証情報を含ませると好ましい点についてはすでに説明したが、始点情報に認証情報が付随していない場合に、ＬＳＰ設定要求メッセージを受信したルータがメッセージ内の始点情報およびストリーム等の付随情報を信用するか否かは、そのルータあるいはセグメントにより異なるようにしてもよい。もし、認証情報が付随していない場合には、１）たとえ登録してある始点ノードがメッセージ内に記述されていてもＬＳＰ設定要求を拒否する、２）登録してある始点ノードがメッセージ内に記載されていて、ＬＳＰ設定要求メッセージ内に記述されたストリーム以外のストリームが実際にはそのＬＳＰから送信されてきたとしても構わない場合に限りＬＳＰ設定要求を受け付ける、などのバリエーションが可能である。
【０３１１】
あるパケットストリームのためのＬＳＰ設定要求をいずれかの理由により拒絶した境界ルータ２０１２が、そのＬＳＰ設定を拒絶した相手の境界ルータからのパケット（ラベルの付与されていないもの）を受信した場合には、パケット転送処理部４００５もしくはスイッチ部４００３が、以下のような動作を行う。すなわち、受信したパケットを廃棄する（パケットの受信すら拒絶する）、あるいは従来のネットワーク層のヘッダ処理を行って次段のルータ２０１５を選択し、選択した次段ルータ２０１５へ向けてパケットを転送する（ホップバイポップ転送処理を行う）、あるいは自ノードが始点となって設定されているＬＳＰにそのパケットを転送する、などの対処が考えられる。登録されていない通信品質クラスを要求したためにＬＳＰ設定を拒絶されたパケットストリームに属するパケットを境界ルータ２０１２が受信した場合には、境界ルータ２０１２を始点として、あるいは境界ルータ２０２１から境界ルータ２０１２を中継点として設定されている別の（低品質の）ＬＳＰのうちで、パケットストリームの定義を満たすものが存在する場合には、受信パケットにネットワーク層処理を行って、そのＬＳＰへパケットを転送することも可能である。あるいは、登録されていない通信品質クラスを要求された場合に、境界ルータ２０１２が上流側のラベルと下流側の低品質のラベルとを対応付け、受信パケットにネットワーク層処理を行わずに、境界ルータ２０１２を中継点とする、設定が要求されたＬＳＰとは別のＬＳＰでパケットストリームの定義を満たすものの上へパケットを転送することもできる。
【０３１２】
なお、この第４の例は第１〜第３の例に述べた隣接ノードおよび／またはストリーム情報による可否判定等と組合せて使用する場合も考えられるし、次の第５の例に述べる終点ノード情報による可否判定等と組合せて使用する場合も考えられるし、ここに述べる始点情報のみで可否判定する場合も考えられる。
【０３１３】
＜終点情報により設定可否を制御する（第５の例）＞
次に、第５の例として、ＬＳＰの終点となるノード（ルータもしくはホスト）の情報がＬＳＰ設定要求メッセージに含まれ、その終点情報をもとにＬＳＰ設定要求可否を判断する場合について説明する。例えば、セグメント２０３０の境界ルータ２０３１では、外部セグメント２０１０からのＬＳＰ設定要求について、自分自身が終点となるＬＳＰのみ許容するが、セグメント２０３０内のさらに先のノード２０３４、２０３２、２０３３までＬＳＰを設定することは許容しない場合を考える（例えば境界ルータ２０３１にてすべてのパケットのヘッダチェックを従来通り行いたいような場合）。その場合には、境界ルータ１０３１は、セグメント２０１０の境界ルータ２０２４から受信したＬＳＰ設定要求メッセージ内に含まれるＬＳＰ終点ノードに関する情報を参照し、終点ノードが自分自身であればＬＳＰ設定要求を許容するための処理を行うが、自分と同じセグメント内でかつ自分よりもさらに経路的に先のノードが終点として指定されている場合には、ＬＳＰ設定要求を拒絶する旨を示すメッセージを境界ルータ２０２４に返すか、あるいは自分自身でＬＳＰを終端させて設定許可を示すメッセージを境界ルータ２０２４に返す。
【０３１４】
終点ノードの情報は、ＬＳＰ設定要求メッセージ内に明示的に記載されている場合には、それを用いればよいし、ＬＳＰ設定要求メッセージ内のパケットストリームの情報（例えば宛先ネットワークアドレス等）から終点ノードを求めることができる場合には、そのようにして求めたものを用いてもよい。
【０３１５】
この終点ノード情報に基づいてＬＳＰ設定可否を判断する他の例としては、例えば、境界ルータ２０３１が自分自身のセグメント２０３０内で終端するＬＳＰなら許容するが、ＬＳＰの終点がセグメント２０３０の外であるような設定要求（セグメント２０３０を中継点として他のセグメントへ出て行くようなＬＳＰの設定要求）は受け付けたくないような場合がある。この場合には、ポリシーテーブルとして、ＬＳＰの設定を許容する終点ノード情報の一覧を境界ルータ２０３１が保持し、ＬＳＰ設定要求メッセージを受けたルータ２０３１が、そのＬＳＰの終点がここに登録された終点ノードであれば、ＬＳＰ設定要求を許容するための処理を行うようにすればよい。
【０３１６】
なお、第５の例は第１〜第４の例に述べた隣接ノード情報、パケットストリーム情報、および／または始点ノード情報による可否判定と組合せて使用することも可能である。
【０３１７】
なお、上記の各例では隣接、始点、終点等によるＬＳＰ設定可否の制御を各ノードの情報（例えばＩＰアドレス）に基づいて行う例を説明したが、各ノードが属するネットワークもしくはセグメント（例えばＩＰアドレスプレフィクスや、各ノードとセグメントの対応情報などを用いる）に基づいて行うことも可能である。
【０３１８】
以上、ラベルスイッチングパスの設定におけるセキュリティーに関していくつかの例を示してきたが、本実施形態によれば、特定の隣接ノードに限定したＬＳＰ提供、特定のパケットストリームに限定したＬＳＰ提供、さらに特定の始点ノードを持つ場合に限定したＬＳＰ提供等を行うことが可能になり、セキュリティ面あるいは網リソースの使用（ポリシー制御）面において、ラベルスイッチを用いない場合と同様に問題を生じることなく、ラベルスイッチを利用することが可能になる。
【０３１９】
本実施形態にて説明した各機能は、ハードウェアとしてもソフトウェアとしても実現可能である。また、ソフトウェアとしても実現する場合、コンピュータに所定の手順を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【０３２０】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０３２１】
【発明の効果】
本発明によれば、放送された映像等のデータを、選択的に蓄積し、要求に応じて配送できる環境を提供することが可能となる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る集合住宅内のバックボーン網の構成例を示す図
【図２】同実施形態に係る集合住宅の家庭内の配線システムの構成例を示す図
【図３】同実施形態に係る情報コンセントの概観図の一例を示す図
【図４】同実施形態に係る家庭内に配置された各装置の例を示す図
【図５】図４における放送系の接続状況を示す図
【図６】図４における１３９４系の接続状況を示す図
【図７】図１のマンションバックボーン網における接続状況を示す図
【図８】同実施形態に係るデジタル放送蓄積サーバの内部構造の一例を示す図
【図９】データ取り出し要求の到着から該当するデータの送出までの手順の一例を示すフローチャート
【図１０】各家庭と使用中の通信資源と規定された同時使用可能な通信資源との対応を記憶したテーブルの一例を示す図
【図１１】同実施形態に係るホームルータの内部構造の一例を示す図
【図１２】家庭内の計算機からホームルータを介してデジタル放送蓄積サーバにアクセスし映像の配送を受ける際のシーケンスの一例を示す図
【図１３】入力同期チャネル番号と出力同期チャネル番号との対応を設定したテーブルの一例を示す図
【図１４】家庭内の計算機からホームルータを介してデジタル放送蓄積サーバにアクセスし映像の配送を受ける際のシーケンスの他の例を示す図
【図１５】家庭内の計算機からホームルータを介してデジタル放送蓄積サーバにアクセスし映像の配送を受ける際のシーケンスのさらに他の例を示す図
【図１６】入力されたレジスタオフセットと出力すべき宛先ノードＩＤおよびレジスタオフセットとの対応を設定したテーブルの一例を示す図
【図１７】ホームルータにその家庭内の装置および／またはサービスについての情報を登録する手順の一例を示す図
【図１８】ホームルータがその家庭内の装置および／またはサービスについての情報を収集する手順の一例を示す図
【図１９】公開する端末および／またはサービスを選択・設定するための手順の一例を示す図
【図２０】ホームルータがその家庭内の装置および／またはサービスの情報をその家庭外部に紹介するシーケンスの一例を示す図
【図２１】ある家庭の計算機から他の家庭のサービスを利用する際のシーケンスの一例を示す図
【図２２】ある家庭内の装置および／またはサービスの情報を紹介するためのＧＵＩの一例を示す図
【図２３】データリンクスイッチングの使用を許可するホームルータのアドレスを設定したテーブルの一例を示す図
【図２４】本発明の他の実施形態に係るネットワーク構成例を説明するための図
【図２５】本発明の他の実施形態に係るラベルスイッチ機能を有するルータの構成例を示す図
【図２６】ＬＳＰ設定要求メッセージ受信時における判断処理の手順の一例を示すフローチャート
【図２７】ＬＳＰ設定要求メッセージのメッセージ形式の例を示す図
【図２８】ポリシーテーブルの一構成例を示す図
【図２９】ＬＳＰ設定要求メッセージ受信時における判断処理の手順の他の例を示すフローチャート
【図３０】ＬＳＰ設定要求メッセージ受信時における判断処理の手順のさらに他の例を示すフローチャート
【図３１】ポリシーテーブルの構成例を示す図
【図３２】ポリシーテーブルの構成例を示す図
【符号の説明】
１０１…共同アンテナ
１０２〜１０６…分配器
サーバ１０７…デジタル放送蓄積
１０８…インターネットサーバ
１０９〜１１２…ホームルータ
２０１〜２０４…情報コンセント
４０１…セットトップボックス内蔵テレビ
４０２…ＰＣ
４０３…デジタルＶＴＲ
４０４，４０７…セットトップボックス
４０５，４０８…テレビ
４０６…ＤＶＤ
８０１…周波数フィルタ
８０２…復調器
８０３…データ蓄積部
８０４…データ選択取り出し部
８０５…ＣＩＰヘッダ付加部
８０６…ユーザ蓄積要求解析部
８０７…ユーザ取り出し要求解析部
８０８…ユーザ毎使用帯域監視部
８０９…ＩＰ処理部
８１０…１３９４インタフェース
１１０１，１１０５…１３９４インタフェース
１１０２…チャネル番号処理部
１１０３…１３９４スイッチ
１１０４…チャネル番号処理部
１１０６…レジスタ処理部
１１０７…ＦＡＮＰ処理部
１１０８…レジスタ処理部
１１０９…ＩＰ処理部
１１１０…ファイアウオール／認証処理部
１１１１…１３９４代理サービス処理部
１１１２…ＤＨＣＰサーバ処理部
１１１３…スイッチ使用許可テーブル
１１１４…サービス表示テーブル
２０１０，２０２０，２０３０…ネットワークセグメント
２０１１〜２０１４，２０２１〜２０２４，２０３１〜２０３３…境界ルータ
２０１５，２０１６，２０２５，２０３４…内部ルータ
４０００…コントローラ部
４００１−１，４００１−ｋ…送受信インタフェース部
４００３…スイッチ部
４００４…フレーム・パケット変換部
４００５…パケット転送部
４００６…制御メッセージ処理部
４００７…ＬＳＰ制御部
４００８…スイッチ制御部
４００９…ポリシー管理部
４０１０…リソース管理部
４０１１…経路表

Claims (8)

1. 放送を受信する第１のインタフェースと、
   複数のユーザ側の端末が接続されたネットワークと接続する第２のインタフェースと、
   前記第２のインタフェースを介して受信した、前記端末からのインターネットパケットを処理する処理手段と、
   前記第１のインタフェースを介して受信した放送のうち、蓄積すべき部分を選択する第１の選択手段と、
   前記第１の選択手段により選択された放送を蓄積する蓄積手段と、
   前記蓄積手段に蓄積されたデータのうち、前記第２のインタフェースから送出するべきデータを選択する第２の選択手段と、
   前記処理手段による前記処理を経て渡される前記インターネットパケットに含まれる、前記蓄積すべき部分に係る要求の内容に基づいて、前記第１の選択手段における選択対象を制御する第１の制御手段と、
   前記処理手段による前記処理を経て渡される前記インターネットパケットに含まれる、前記送出するべきデータに係る要求の内容に基づいて、前記第２の選択手段における選択対象を制御する第２の制御手段とを含むことを特徴とする蓄積装置。
2. 前記第１の選択手段及び第２の選択手段における選択対象の選択の際に、前記処理手段にて行われる前記インターネットパケットの処理は、ＨＴＴＰに基づいて行われることを特徴とする請求項１に記載の蓄積装置。
3. 前記第１の選択手段により選択され、前記蓄積手段に蓄積される放送は、複数チャンネルの放送を含むことを特徴とする請求項１に記載の蓄積装置。
4. 前記第１の選択手段により選択され、前記蓄積手段に蓄積される放送の少なくとも一部は、デジタル放送であることを特徴とする請求項１に記載の蓄積装置。
5. 前記第２のインタフェースから前記蓄積されたデータを送信するのに先立って、該第２のインタフェースから該データを受信すべき端末に至る経路の少なくとも一部の通信資源の確保を行う通信資源確保手段をさらに備えたことを特徴とする請求項１に記載の蓄積装置。
6. データの送信先またはデータ送信の依頼者となるユーザまたは端末毎に、前記第２のインタフェースを介して前記蓄積されたデータを送信する際に同時に使用可能な通信資源量と現在そのユーザまたは端末について使用している通信資源量とを記した管理テーブルをさらに備えたことを特徴とする請求項１に記載の蓄積装置。
7. データ送信要求を受ける前または受けた後に、該データ送信要求の要求元のユーザまたは端末との間で認証手続きを行うことを特徴とする請求項１に記載の蓄積装置。
8. 前記蓄積装置は、集合住宅内のバックボーン網に接続され、前記第２の選択手段は、前記集合住宅内の個々の住宅の端末からの要求に従って、選択対象を選択することを特徴とする請求項１に記載の蓄積装置。

Images