(57)【要約】【課題】  本発明の課題は、第１ネットワークの送信ステーションと第２ネットワークの受信ステーションとの間のデータ転送を効果的に制御する方法及び装置を提供することである。【解決手段】  本発明は、細粒度ＱｏＳメソッドを有するよう設計された第１ネットワークの送信ステーションと第２ネットワークの受信ステーションとの間でデータを転送する方法であって、前記第１及び第２ネットワークは、前記第１ネットワークより粗い粒度のＱｏＳメソッドを有するよう構成される第３ネットワークを介し接続され、当該方法は、前記受信ステーションのため前記第２ネットワーク内の前記受信ステーションへのデータ送信を制御するため、前記第１ネットワーク内で確立された信号接続を終了するステップを有する方法である。【選択図】  図２
2007336545.tif 000002
【特許請求の範囲】
【請求項１】
細粒度ＱｏＳメソッドを有するよう設計された第１ネットワークの送信ステーションと第２ネットワークの受信ステーションとの間でデータを転送する方法であって、
前記第１及び第２ネットワークは、前記第１ネットワークより粗い粒度のＱｏＳメソッドを有するよう構成される第３ネットワークを介し接続され、
当該方法は、前記受信ステーションのため前記第２ネットワーク内の前記受信ステーションへのデータ送信を制御するため、前記第１ネットワーク内で確立された信号接続を終了するステップを有する方法。
【請求項２】
当該方法はさらに、前記送信ステーションによって要求されるＱｏＳと、前記受信ステーションに対するデータ転送のため前記第３ネットワークにサポートされるＱｏＳとの間のＱｏＳマッピングを実行するステップを有する、請求項１記載の方法。
【請求項３】
当該方法はさらに、前記第２ネットワークの受信ステーションに到達可能な前記第３ネットワーク内のターゲットステーションを選択するステップと、
前記送信ステーションから要求されたＱｏＳ記述と前記ターゲットステーションに利用可能なＱｏＳ記述セットとを比較するステップと、
を有する、請求項１又は２記載の方法。
【請求項４】
当該方法はさらに、前記送信ステーションから要求されたＱｏＳ記述に適合する前記利用可能なＱｏＳ記述セットからのＱｏＳにより、前記第３ネットワーク内で前記ターゲットステーションとの接続を確立するステップを有する、請求項３記載の方法。
【請求項５】
当該方法はさらに、前記ターゲットステーションとの既存の接続の存在及びロードをチェックし、前記既存の接続が十分な残りの能力を有する場合、前記必要とされる能力を占有し、前記既存の接続にさらなるデータフローを導くステップを有する、請求項３記載の方法。
【請求項６】
前記第１ネットワークは、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）対応ネットワークタイプであり、
前記第３ネットワークは、ＭＰＬＳ（Ｍｕｌｔｉｐｒｏｔｏｃｏｌ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｉｎｇ）対応ネットワークタイプである、請求項１乃至５何れか一項記載の方法。
【請求項７】
細粒度ＱｏＳメソッドを有するよう設計された第１ネットワークの送信ステーションと第２ネットワークの受信ステーションとの間のデータ転送を制御する装置であって、
前記第１及び第２ネットワークは、前記第１ネットワークより粗い粒度のＱｏＳメソッドを有するよう構成される第３ネットワークを介し接続され、
当該装置は、前記受信ステーションのため前記第２ネットワーク内の前記受信ステーションへのデータ送信を制御するため、前記第１ネットワーク内で確立された信号接続を終了するよう構成される終了手段を有する装置。
【請求項８】
前記終了手段は、前記第２ネットワークにおける前記受信ステーションに向けられるデータ転送のため、前記送信ステーションによって要求されるＱｏＳと、前記第３ネットワークにおいてサポートされるＱｏＳとをマッピングするよう構成される、請求項７記載の装置。
【請求項９】
前記終了手段は、前記第２ネットワークの受信ステーションに到達可能な前記第３ネットワーク内のターゲットステーションを選択する手段を有する、請求項７又は８記載の装置。
【請求項１０】
前記終了手段はさらに、前記送信ステーションから要求されたＱｏＳ記述と前記ターゲットステーションに利用可能なＱｏＳ記述セットとを比較する比較手段を有する、請求項７乃至９何れか一項記載の装置。
【請求項１１】
前記終了手段は、前記送信ステーションから要求されたＱｏＳ記述に適合する前記利用可能なＱｏＳ記述セットからのＱｏＳにより、前記第３ネットワーク内で前記ターゲットステーションとの接続を確立する手段を有する、請求項７乃至１０何れか一項記載の装置。
【請求項１２】
前記終了手段は、前記第３ネットワークにおける前記ターゲットステーションとの既存の接続の存在及びロードをチェックし、前記既存の接続が十分な残りの能力を有する場合、前記必要とされる能力を占有し、前記既存の接続に前記要求元の送信ステーションからのさらなるデータフローを導く手段を有する、請求項７乃至１１何れか一項記載の装置。
【請求項１３】
前記第１ネットワークは、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）対応ネットワークタイプであり、
前記第３ネットワークは、ＭＰＬＳ（Ｍｕｌｔｉｐｒｏｔｏｃｏｌ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｉｎｇ）対応ネットワークタイプである、請求項７乃至１２何れか一項記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、第１タイプのローカルネットワークが第２タイプのローカルネットワークの受信ステーションと通信する送信ステーションを有するワイドエリアのネットワーク通信の分野に関する。これら２つのネットワークのステーションは、バーチャルプライベートネットワーク接続を提供する第３タイプのワイドエリアネットワークを介し通信している。
【背景技術】
【０００２】
インターネットにおいてバーチャルプライベートネットワークを実現するため、いわゆるＶＰＮ技術が開発されてきた。バーチャルプライベートネットワーク（ＶＰＮ）は、パブリックネットワークを介し通信するため、企業内で又は複数の異なる企業や組織によって通常使用されるプライベート通信ネットワークである。ＶＰＮメッセージトラフィックは、標準的な（しばしば非セキュアな）プロトコルを使用するパブリックネットワーク接続インフラストラクチャ（インターネットなど）を介し、又はＶＰＮカスタマとＶＰＮサービスプロバイダとの間の明確なサービスレベルアグリメント（ＳＬＡ）によって保護されるＶＰＮサービスを提供するサービスプロバイダのネットワークを介し搬送される。
【０００３】
ＶＰＮは、２つのパート、すなわち、伝送をプロテクトするのに十分な物理的セキュリティと管理的セキュリティとを提供するプロテクトされた又は“インサイド”ネットワークと（ときには、それは常にそのケースになるとは限らない）、より信頼性の低い又は“アウトサイド”ネットワーク又はセグメント（インターネット）とに関する。一般に、リモートユーザのワークステーション又はクライアントと、ホストネットワーク又はサーバとの間にはファイアウォールが設けられている。ユーザのクライアントがファイアウォールとの通信を確立すると、クライアントは、周辺内部の認証サービスに認証データをわたすかもしれない。ときには信頼されている装置を使用しているときに限って、既知の信頼されている人には、一般的なユーザに利用不可なリソースにアクセスする適切なセキュリティ権限を提供することが可能である。
【０００４】
多数のＶＰＮクライアントプログラムは、より良好なセキュリティのため、ＶＰＮがアクティブである間、すべてのＩＰトラフィックが“トンネル”を通過しなければならないことを要求するよう構成可能である。ユーザの視点から、このことは、ＶＰＮクライアントがアクティブである間は、オフィスのイーサネット（登録商標）に物理的に接続されている間と同様に、従業員のセキュアネットワークの外部のすべてのアクセスは同一のファイアウォールを通過しなければならないことを意味する。これは、従業員のラップトップを攻撃することによって、攻撃者がセキュアネットワークにアクセス可能となるリスクを低減する。従業員のホームネットワーク上の他のコンピュータにとって、又はパブリックインターネットを介し、それがあたかもＶＰＮクライアントを実行しているマシーンが単に存在しないかのようである。このようなセキュリティは、クライアントコンピュータが動作しているネットワークにローカルな他のコンピュータが信頼されていない、又は部分的にしか信頼されていない可能性があるため、重要である。ファイアウォールにより外部のインターネットからプロテクトされているホームネットワークによってでさえ、ホームを共有する人々は、共有されているホームネットワークから各自のＶＰＮ接続を介し異なる従業員のために同時に動作しているかもしれない。各従業員は、ローカルネットワークの他のコンピュータがマルウェア（ｍａｌｗａｒｅ）により感染した場合であっても、自らが所有するデータを確保することを所望するであろう。また移動中の従業員が公共の場所のＷｉＦｉアクセスポイントからＶＰＮクライアントを使用する場合、このようなセキュリティはさらに重要となる。しかしながら、ＩＰＸ／ＳＰＸの使用は、ユーザが依然としてローカルリソースにアクセスすることを可能にする１つの方法である。
【０００５】
トンネリング（ｔｕｎｎｅｌｉｎｇ）は、パブリックネットワークのルーティングノードが伝送がプライベートネットワークの一部であることを気付かせないような方法により、パブリックネットワークを介しプライベート、通常は企業ネットワーク内のみの使用のためのデータの伝送である。トンネリングは、一般にプライベートネットワークプロトコル情報がパブリックネットワークに対してデータとして現れるように、パブリックネットワーク伝送ユニット内でプライベートネットワークデータ及びプロトコル情報をカプセル化することによって実行される。トンネリングは、パブリックネットワークであるインターネットの使用がプライベートネットワークのためにデータを搬送することを可能にする。
【０００６】
Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ）内には、ＶＰＮ技術にＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）の向上を追加するのに関するいくつかのワーキンググループが存在する。Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅｓ（ＩｎｔＳｅｒｖ）ワーキンググループは、アグリゲーション機構と共にトンネリングを議論してきた。それらは、Ｒｅｑｕｅｓｔ  ｆｏｒ  ＣｏｍｍｅｎｔｓドキュメントＲＦＣ２３７９、ＲＦＣ２７４６、ＲＦＣ２９９８及びＲＦＣ３１７５に記載されている。
【０００７】
Ｔｒａｆｆｉｃ  Ｅｎｇｉｎｅｅｒｉｎｇ及びＱｏＳについて言うと、Ｍｕｌｔｉｐｒｏｔｏｃｏｌ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｉｎｇ（ＭＰＬＳ）ネットワーク接続技術は、大変面白いものである。この技術は、高度なＴｒａｆｆｉｃ  Ｅｎｇｉｎｅｅｒｉｎｇ及びＱｏＳサポートによるものである。また、それはトンネリングを使用し、ＶＰＮ技術に良好に適合する。ＭＰＬＳネットワーク内でＴｒａｆｆｉｃ  Ｅｎｇｉｎｅｅｒｉｎｇを実行するための専用のシグナリング拡張がまた規定されてきた（ＲＦＣ３２０９、ＲＦＣ３６３０、ＲＦＣ３１０７及びＲＦＣ３２１２を参照されたい）。特に、Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅｓ（ＤｉｆｆＳｅｒｖ）ネットワークを介したＲｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＲＳＶＰ）制御されたＩＰ接続の動作と、これらのデータフローの適切なＤｉｆｆＳｅｒｖコードポイント（ＤＳＣＰ）へのマッピングは、ＩＥＴＦの対応する文書内に記載されている（ＲＦＣ２９９８及びＲＦＣ３１７５を参照されたい）。
【０００８】
ＩＥＴＦ内に記載されるこれらのアプローチの主要な問題点は、以下の通りである。すなわち、受信サイドと送信サイドの双方におけるネットワークの少なくとも一部が、ＲＳＶＰアウェアであることが求められるということである。ＲＳＶＰトンネリング機能は、ＩＰネットワークの内部部分を介した伝送のみを処理する。図１を参照されたい。
【０００９】
図１において、参照番号１０はインターネットを示す。参照番号２０により、インターネット内のＲＳＶＰドメインが示される。左ＲＳＶＰドメイン２０の内部に、送信ステーション２１が示される。右ＲＳＶＰドメイン２０の内部に、対応する受信ステーション２３が示される。これら２つのＲＳＶＰドメイン２０は、世界の異なるエリアに配置されてもよい。１つのドメインは米国カリフォルニア州にあり、他方のドメインは英国などの欧州にある。両ドメインは、組織又は企業の２つの信頼性のある場所に属している。パッチを介したＱｏＳ確保のため、ＲＳＶＰトンネリング技術が使用される。確立されたトンネルは、図１の参照番号４０によりラベル付けされている。
【００１０】
特に異なる管理的ドメインに送信機と受信機が存在し、ＭＰＬＳなどのＶＰＮ技術がインナーネットワークに適用される場合、インナーネットワークは典型的にはすでにあるＱｏＳコントロールを提供しているため、受信サイドは、受信サイドのＱｏＳ能力に従って受信サイドのため十分な設備をもった（ｏｖｅｒｐｒｏｖｉｓｉｏｎｉｎｇ）又は統計的に構成されたプライオリティキューニング機構など、ＲＳＶＰ対応であることはしばしば要求されない。
【００１１】
ＲＳＶＰは、細粒度（ｆｉｎｅ−ｇｒａｉｎｅｄ）トラフィック（フロー）記述を開示し、ネットワークリソースが確保されるべきであるが、ネットワークオペレータは通常はそのような細粒度ベースにより大量のリザベーションを処理し、又はこのような詳細に規定されたリクエストをサービスのクラスに適切にマップすることはできない。フローアグリゲーションはＲＦＣ２７４６及びＲＦＣ３１７５において検討されているが、これらの文書に記載されるアグリゲーションモデルは、ＲＳＶＰアウェアネットワークにのみ適用可能である。
【００１２】
一般的なＩｎｔＳｅｒｖ／ＲＳＶＰモデルによって、送信機２１と受信機２３との間のＩＰ接続性が、リソースリザベーション時に存在する必要がある。ＲＳＶＰリザベーションリクエストのためＩＰネットワーク内において、おそらくＤｉｆｆＳｅｒｖと共にアグリゲートされたＲＳＶＰを用いたトンネルの確立しか、ＩＥＴＦドキュメント内で規定されていない。
【特許文献１】国際出願公報ＷＯ０２／３７８６９
【特許文献２】米国特許第６，７６５，９２７号
【非特許文献１】ＭＡＲＣＨＥＳＥ  Ｍ  ＥＴ  ＡＬ：“ＭＰＬＳ−Ｂａｓｅｄ  ＱｏＳ  Ｉｎｔｅｒｗｏｒｋｉｎｇ  Ａｍｏｎｇ  Ｗｉｄｅ  Ａｒｅａ  Ｓｕｂｓｙｓｔｅｍｓ”ＭＩＬＩＴＡＲＹ  ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ  ＣＯＮＦＥＲＥＮＣＥ，２００５．ＭＩＬＣＯＭ  ２００５．ＩＥＥＥ  ＡＴＬＡＮＴＩＣ  ＣＩＴＹ，ＮＪ，ＵＳＡ  １７−２０  ＯＣＴ．２００５，ＰＩＳＣＡＴＡＷＡＹ，ＮＪ，ＵＳＡ，ＩＥＥＥ，１７  Ｏｃｔｏｂｅｒ  ２００５（２００５−１０−１７），ｐａｇｅｓ  １−７，ＸＰ０１０９０３０１８  ＩＳＢＮ：０−７８０３−９３９３−７
【非特許文献２】ＢＨＡＲＧＡＶＡ  Ａ．，ＰＨＥＬＡＮ  Ｔ．：“ＭＰＬＳ  Ｐｒｏｘｙ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｄｅｆｉｎｉｔｉｏｎ  Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  Ａｇｒｅｅｍｅｎｔ”ＭＰＬＳ＆ＦＲＡＭＥ  ＲＥＬＡＹ  ＡＬＬＩＡＮＣＥ  ＴＥＣＨＮＩＣＡＬ  ＣＯＭＭＩＴＴＥＥ，［Ｏｎｌｉｎｅ］  Ｏｃｔｏｂｅｒ  ２００４（２００４−１０），ｐａｇｅｓ  １−９，ＸＰ００２４０４９２０
【発明の開示】
【発明が解決しようとする課題】
【００１３】
従来のシナリオによってはカバーされない一般的なトポロジーは、例えば、ＭＰＬＳ技術などを利用して構成されるキャリアのワイドエリアネットワークに接続されるＲＳＶＰアウェアローカルエリアネットワークである。受信サイドにおけるローカルネットワークは、これにより、必ずしもＩＰベースネットワークである必要はなく、それは、Ｉｎｆｉｎｉｂａｎｄなどに基づき構成することが可能である。この場合、送信ステーションからＲＳＶＰリクエストを開始する２つのネットワークの間の通信を設定することは不可能である。
【００１４】
本発明の課題は、上記問題点に鑑み、第１ネットワークの送信ステーションと第２ネットワークの受信ステーションとの間のデータ転送を効果的に制御する方法及び装置を提供することである。
【課題を解決するための手段】
【００１５】
本発明は、第１タイプのネットワークの送信ステーションと第２タイプのネットワークの受信ステーションとの間の通信を制御する方法に関する。本方法は、受信ステーション（３１）のため第２ネットワーク（３０）内の受信ステーション（３１）へのデータ送信を制御するため、第１ネットワーク内で確立された信号接続をターミネート（ｔｅｒｍｉｎａｔｅ）又は終了するステップに関する。これは、通常通りに第１ネットワーク内の接続を確立することを可能にする。
【００１６】
効果的な実施例では、この接続は、受信ステーションに対するデータ転送のため、送信ステーションによって要求されるＱｏＳと第３ネットワークにおいてサポートされるＱｏＳとの間のＱｏＳマッピングを実行することによって、第３ネットワーク内で拡張される。ＱｏＳマッピングは、受信サイドがリソースリザベーション通信プロセスに参加する必要はないという効果を有する。
【００１７】
本発明はまた、細粒度ＱｏＳメソッドを有するよう構成される第１ネットワークの送信ステーションと、第２ネットワークの受信ステーションとの間の通信を制御する装置に関し、第１及び第２ネットワークは、第１ネットワークより粗い粒度のＱｏＳメソッドを有するよう構成される第３ネットワークを介し接続される。本装置は、受信ステーション（３１）のため第２ネットワーク（３０）内において受信ステーション（３１）へのデータ送信を制御するため、第１ネットワーク内に確立された信号接続を終了するよう構成される終了手段を有する。本装置は、プロキシなどの第２タイプのネットワークからの受信ステーションの代理として機能する。すなわち、本発明は、第１タイプのネットワークと第２タイプのネットワークとの間の信号スイッチエンティティに関する。一実施例では、この信号スイッチエンティティは、第１ネットワークタイプに対応するＲＳＶＰアウェアネットワークと、第３ネットワークタイプに対応するＭＰＬＳネットワークとの間の移行の近傍に配置される。当該エンティティは、ＲＳＶＰ−ＭＰＬＳプロキシと示すことができる。これにより、受信サイドは必ずしもＲＳＶＰに対応する必要はなく、一般には必ずしもＩＰプロトコルを介しＭＰＬＳネットワークと通信する必要もない。
【発明の効果】
【００１８】
本発明によると、第１ネットワークの送信ステーションと第２ネットワークの受信ステーションとの間のデータ転送を効果的に制御する方法及び装置を提供することができる。
【発明を実施するための最良の形態】
【００１９】
図２及び３は、本発明によるＲＳＶＰ−ＭＰＬＳプロキシが使用されるネットワークの２つの例を示す。これらの図の既出の参照番号は、上述した図１の記載で説明されたもの同様のコンポーネントに対応している。カスタマＩＰネットワークのＲＳＶＰデータ送信機２１と、ネットワークオペレータのＭＰＬＳネットワーク５０との間の信号パス内にＲＳＶＰ−ＭＰＬＳプロキシ１００を一体化することが提案されている。図２において、ＲＳＶＰ−ＭＰＬＳプロキシは、ＲＳＶＰドメイン２０とＭＰＬＳネットワーク５０との間の境界に配置される。ＲＳＶＰドメイン２０は、送信ステーション２１を含む。送信ステーションは他の位置のネットワークの受信ステーション３１と通信する必要があると仮定する。この他のネットワークは、非ＲＳＶＰドメインであると考えられる。図２において、ＩｎｆｉｎｉＢａｎｄネットワーク３０は、他の位置のネットワークの一例としてとられている。これは、各方向に１６Ｇｂｉｔ／ｓまでのデータ転送能力を有する双方向シリアルバスシステムを利用する。これら２つの位置の間のＭＰＬＳネットワークは、インターネットのワイドエリアに拡がっている。従って、送信ステーション２１により送信されたメッセージは、当該メッセージがＭＰＬＳネットワーク５０と非ＲＳＶＰドメイン３０との間の境界にあるゲートウェイ６０に最終的に到達するまで、ＭＰＬＳネットワーク５０の１つのルータ５１から他のルータにルーティングされる。
【００２０】
図３に示される例は、受信エンドにおいて３つの非ＲＳＶＰドメイン３０を示す。企業／組織は、各サイトに１以上のドメインとの４つの各サイトを有する。
【００２１】
非ＲＳＶＰ対応ドメイン内の所定の許可されたターゲットセットＳＴ＝｛Ｔ１，．．．，Ｔｍ｝と、ＱｏＳ記述セットＳＤ＝｛Ｄ１，．．．，Ｄｎ｝は、ＭＰＬＳネットワーク５０に接続されたカスタマとＭＰＬＳネットワークオペレータとの間で交渉される必要がある。カスタマは、各ターゲットについてセットＳＤから選ばれた所望のＱｏＳを有するセットＳＴからの１以上のターゲットとのＭＰＬＳ接続を確立することが可能であり、各ターゲットに適用可能なサービスの範囲はまた、受信サイドのＱｏＳ能力に依存するかもしれない。ＭＰＬＳネットワーク５０は、ＳＤ（ＭＰＬＳ）により特定されるＱｏＳ記述セットに従ってＱｏＳを特定のターゲットに配信し、接続された送信先のローカルネットワーク３０が、セットＳＤ（ＤｅｓｔＤｏｍａｉｎ）に従ってＱｏＳをサポートしていると仮定すると、ターゲットＱｏＳ記述セットは、
ＳＤ（Ｔａｒｇｅｔ）＝ｍｉｎ（ＳＤ（ＭＰＬＳ），ＳＤ（ＤｅｓｔＤｏｍａｉｎ））
として計算されるべきである。これにより、セットＳＤ（ＤｅｓｔＤｏｍａｉｎ）は、十分な設備をもった又は他のものなど大変シンプルなＱｏＳ機構によって実現可能である。言及された各セットは多次元ベクトルであり、このため、ｍｉｎ関数が各サービスについて定義される必要がある。ｍｉｎ関数の具体例が、以下のセクションにおいて説明される。ネットワークオペレータは、ＱｏＳ記述ＳＤ（ＭＰＬＳ）においてこうしょうｓあれている規定されたＳｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ａｇｒｅｅｍｅｎｔｓ（ＳＬＡ）に従ってＭＰＬＳトランスポートサービスをターゲットに配信する。
【００２２】
本発明は、“ＲＳＶＰ−ＭＰＬＳプロキシ”（以降において、“プロキシ”と略称される）と呼ばれるネットワーク装置を提供する。このプロキシは、ＲＳＶＰアウェアドメインとＭＰＬＳネットワークとの間の信号パスに挿入される。ＩｎｔＳｅｒｖアーキテクチャと意味的に同様に使用されるＲＳＶＰシグナリングが、プロキシ１００においてターミネートされる。送信機２１からＰＡＴＨメッセージ内のフロー記述を受信すると、プロキシは第１ステップにおいて、当該データフローの送信先に到達するように、セットＳＴから適切なターゲットを選択する。第２ステップでは、トラフィック記述は、当該ターゲットに適用可能なセットＳＤからの各ＱｏＳ記述と対比される。各ＱｏＳ記述は、対応するＭＰＬＳ接続が確立可能なＱｏＳ関連パラメータのベクトルを含む。テーブル１において、ＳＤ内のＱｏＳ記述の具体例が示される。
【００２３】
【表１】
2007336545.tif 000003
適切なＱｏＳ記述が検出されると、プロキシは、当該ＱｏＳ記述に従って選ばれたターゲットとの各ＭＰＬＳ接続を確立する。ＭＰＬＳ接続が確立されると、開始ＲＳＶＰホストに対するＲＳＶＰリザベーションが実行される。選択されたターゲットとのＭＰＬＳ接続がすでに存在する場合、プロキシ１００は、所望のトラフィックフローが同一のＭＰＬＳ接続にマップされた他のＲＳＶＰリザーブされたフローにマージ可能であるかチェックする。この場合、プロキシは、受信機のため開始ＲＳＶＰホストに対するＲＳＶＰリザベーションのみを実行する。
【００２４】
ＲＳＶＰ制御ネットワークとＭＰＬＳネットワークとの間の適切なＱｏＳマッピングを可能にするため、ＱｏＳ記述の基本的な計算ルールが規定される必要がある。サンプルＭＰＬＳ記述Ｄにより、テーブル１に示されるように、ｍｉｎ（ｍｉｎｉｍｕｍ）及びａｄｄ（ａｄｄｉｔｉｏｎ）の演算のターゲットコンポーネントは、以下のように計算されるべきである。
【００２５】
ｍｉｎ（Ｄ１，Ｄ２）：ｍｉｎ（最大データレート）、ｍａｘ（最大遅延）、ｍａｘ（最大ジッタ）、ｍａｘ（最大パケットロス）、ｍｉｎ（最大パケットロス距離）
ａｄｄ（Ｄ１，Ｄ２）：ａｄｄ（最大データレート）、ｍｉｎ（最大遅延）、ｍｉｎ（最大ジッタ）、ｍｉｎ（最大パケットロス）、ｍａｘ（最大パケットロス距離）
また、必要な比較塩酸が、ｍｉｎ演算を用いて定義することが可能である。
【００２６】
ａ）第１記述の各コンポーネントが第２記述の対応するコンポーネントに等しい場合、２つのＱｏＳ記述は等しい。
【００２７】
ｂ）比較演算子ｌｅｓｓ（＜）の計算：Ｄ１≠Ｄ２かつＤ１＝ｍｉｎ（Ｄ１，Ｄ２）である場合、Ｄ１＜Ｄ２となる。
【００２８】
本発明による提案されたＲＳＶＰ−ＭＰＬＳプロキシ１００について、以下の要件が充足されるべきである。
【００２９】
１．ネットワーク２０のデータ送信機２１が存在し、完全又は一部ＲＳＶＰ対応可能であり、リソースアナウンスメント及びリソースリザベーションがデータ送信機のため送信される。プロキシは、ＲＳＶＰメッセージを搬送するＩＰパケットが通過する信号パスを介し送信される。
【００３０】
２．ＲＳＶＰドメインオペレータとＭＰＬＳネットワークオペレータとの間のＳｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＳＬＳ）が存在する。このようなＳＬＳは、ネットワークオペレータが提供するＱｏＳレベルの技術的パラメータを規定する。ＳＬＳは、ＭＰＬＳ接続が確立可能なターゲットセットＳＴ＝｛Ｔ１，．．．，Ｔｍ｝に関して、少なくとも１つのＱｏＳ記述を有するＱｏＳ記述セットＳＤ＝｛Ｄ１，．．．，Ｄｎ｝を規定すべきである。必ずしもすべてのターゲットが、すべてのＱｏＳ記述Ｄ１〜Ｄｎに到達可能とされるべきでなく、セットＳＤからの１つに少なくとも到達可能であるべきである。テーブル１は、ＱｏＳ記述の一例を示す。テーブル２は、ＳＴターゲットの特定のターゲットにより使用されることが許可されているＱｏＳ記述のＱｏＳの一例を示す。
【００３１】
【表２】
2007336545.tif 000004
３．ＭＰＬＳネットワークオペレータは、ＳＤからの所定のＱｏＳ記述の１つとのＭＰＬＳ接続のオンデマンドな開始及び制御をプロキシ手段に提供する。このような手段は、ＲＳＶＰ−ＴＥプロトコル（ＲＦＣ３２０９）又はＭＰＬＳネットワークオペレータが実現可能な、ＬＤＰ、ＣＲ−ＬＤＰ（ＲＦＣ３２１２）、ＯＳＰＦ−ＴＥ（ＲＦＣ３６３０）などの他のトラフィック制御アーキテクチャとすることが可能である。
【００３２】
４．ＭＰＬＳネットワークオペレータは、所望のＭＰＬＳ接続を確立するため、ＲＳＶＰアウェアドメインのユーザにより使用されるプロキシの保証を受け付ける。
【００３３】
これらの要件に従って、図４のフローチャートに示されるように、ＲＳＶＰ−ＭＰＬＳプロキシ１００が動作する。
【００３４】
アイドル状態１０１では、プロキシ１００は、許可されたＲＳＶＰピアからの入力ＰＡＴＨメッセージを待機する。ＰＡＴＨメッセージが到着すると、プロキシはステップ１０２においてＰＡＴＨメッセージを評価する。
【００３５】
次に、ＳＴからの何れかＭＰＬＳターゲットがＰＡＴＨメッセージの受信機３１に到達するのに利用可能であるかチェックされる必要がある。当該ターゲットをＴＲにより示す。これはステップ１０３において実行される。
【００３６】
ＴＲの判定プロセスは、２つの段階において実行されるべきである。第１に、ＭＰＬＳピアが従来のＩＰルーティングにより決定可能である。第２に、ＲＳＶＰメッセージのトラフィック仕様（ＴＳＰＥＣ）が、ＭＰＬＳサイドにおいてＱｏＳ記述フォーマットにマップされるべきである。送信機ＤＳの結果として得られるＱｏＳ記述が、当該ターゲットの各ＱｏＳ記述エントリと比較される（テーブル２を参照されたい）。一般に、ＲＳＶＰフローは、ＭＰＬＳサイドＱｏＳ記述にマップされ、ＤＳに最も良く適合される。「最も良く適合される」とは、ＤＳより小さくはない最小の記述（演算ｍｉｎにより決定される）を意味する。セットＳＤからの最も良く適合する記述をＤＢとして示す。ターゲットＴＲのＤＢが存在しない場合、高度なＩＰルーティング方法による他のルートが検討可能である。十分大きなＱｏＳ記述によるＭＰＬＳネットワーク内のルートがない場合、送信機に対するリザベーションは開始されない。このケースでは、本プロセスはさらにステップ１１３に移行する。さらに、ベンダー固有の理由コードに関するエラーコード“２１”（トラフィックコントロール）によるＰＡＴＨ＿ＥＲＲＯＲメッセージが送信機２１に送信可能である。ＰＡＴＨ＿ＥＲＲＯＲのケースでは、アプリケーションは、ＭＰＬＳネットワークからのサービス拒絶により迅速に応答することが可能である。
【００３７】
ステップ１０３において、プロキシは、選択されたターゲットＴＲとのすでに確立されているＭＰＬＳ接続を検索する。プロキシ１００は、すでに確立されているすべてのＲＳＶＰリザベーションによって使用され、確立された各ＭＰＬＳ接続にマップされるリソースの合計を追跡する必要がある。これにより、ＰＡＴＨメッセージのＴＳＰＥＣオブジェクトからのトラフィック仕様は、ＱｏＳ記述フォーマットにマップされる必要がある。全リソース使用のＱｏＳ記述は、上述した演算ａｄｄにより計算することが可能である。特定のＭＰＬＳターゲットへのすべての送信機の全リソース使用は、ここではＤｏｖｅｒａｌｌと呼ばれる。
【００３８】
確立された接続が存在する場合、フローチャートのステップ１０４に続く。プロキシ１００はまず、データフローのＭＰＬＳラベルを取得する。さらに、プロキシは、当該ステップにおいて、ＰＡＴＨメッセージから抽出され、Ｄｏｖｅｒａｌｌに加えられる要求されたフローＤＳのＱｏＳ記述が対応するＱｏＳ記述に適合するかテストする。これは、以下の式が真となる場合、ターゲットＴＲの行へのエントリＤＢが存在することを意味する。
【００３９】
ａｄｄ（Ｄｏｖｅｒａｌｌ，ＤＳ）≦ＤＢ
このケースでは、通知されたトラフィックパラメータによるリソースリザベーションが、ＲＳＶＰ送信機２１に送信される。
【００４０】
照会１０５により、ＲＳＶＰリザベーションが維持されているか確認される。
【００４１】
当該ＲＳＶＰリザベーションに属する連続するすべてのデータパケットが、ＭＰＬＳにより関連するＭＰＬＳ接続にわたされる。これはステップ１０６において行われる。以下において、ＲＳＶＰフローをＭＰＬＳ接続にマッピングすることに関する詳細が説明される。
【００４２】
ステップ１０３において実行された２つのテストの１つが否定的なものである場合、ＰＡＴＨメッセージのトラフィック仕様がセットＳＤから適切なＱｏＳ記述にマップされ、当該記述に対応するＭＰＬＳ接続が開始される。これはステップ１１３において実行される。ステップ１１４において、適切なＱｏＳ記述ＤＢが検索され、検出された場合、プロキシ１００は、ＱｏＳ記述ＤＢとのＭＰＬＳ接続を次のルータ５１から要求する。
【００４３】
ＭＰＬＳ接続が失敗した場合、データ送信機２１に対するリソースリザベーションは開始されない。これは、照会１１６においてチェックされる。上述されるように、明示的なＰＡＴＨ＿ＥＲＲＯＲがデータ送信機２１に送り返すことが可能である。ＭＰＬＳ接続が成功した場合、ＰＡＴＨメッセージのＴＳＰＥＣオブジェクトにより通知される仕様に従うトラフィック仕様によるＲＳＶＰリザベーションが、ＲＳＶＰ送信機２１に送信される。
【００４４】
ＭＰＬＳサイドでは、ＲＳＶＰ−ＴＥ、ＣＲ−ＬＤＰ、ＯＳＰＦ−ＴＥなどの異なるシグナリングプロトコルが利用可能である。ＭＰＬＳがＭＰＬＳ接続を確立すると、ＲＳＶＰ送信機に対するＲＳＶＰリザベーションがステップ１１７において実行される。対応するＲＳＶＰリザベーションに属するすべてのデータパケットは、対応するＭＰＬＳ接続にわたされる（ステップ１０６）。
【００４５】
ＲＳＶＰホストからＭＰＬＳノードへの確立された接続は、ステップ１１０のＲＳＶＰドメイン（ＲＳＶＰ送信機２１を含む）又はステップ１０７のＭＰＬＳネットワーク５０のためにリリースすることが可能である。何れのケースでも、補完的なネットワークトポロジー内の適切な切断手続が、実行される必要がある。ＭＰＬＳ接続が失敗した場合、又はＲＳＶＰ送信機に対するＲＳＶＰリザベーションが確立することができない場合、それぞれ適切なリザベーション又は接続リリースが実行される必要がある。この切断手続は、２つの部分に分割される。１つは、ステップ１１１及び１１２のＭＰＬＳ接続の切断に関するものであり、他方は、ステップ１０８及び１０９のＲＳＶＰ  ＰＡＴＨの切断及びリザベーション状態に関するものである。言及されるべき重要な点は、ステップ１１１において実行されるテストである。ここでは、他のＲＳＶＰフローが同一のＭＰＬＳ接続にマップされるかチェックされる。そうである場合、ＭＰＬＳ接続はリリースすることができず、アクティブ状態を維持する。この場合、ＲＳＶＰ  ＰＡＴＨ及びリザベーション状態のみが、ステップ１０８及び１０９においてリリースされる。
【００４６】
記載されたシナリオでは、プロキシは、ＲＳＶＰアウェアネットワークから異なるＲＳＶＰリザベーションを同時に処理し、ＲＳＶＰ送信機のため異なるＭＰＬＳ出力ポイントＴ１、Ｔ２及びＴ３と、当該ＲＳＶＰリザベーションに係るＭＰＬＳ接続を管理する。
【００４７】
以下において、ＭＰＬＳ接続の確立に関するさらなる詳細が説明される。ＭＰＬＳでは、いわゆるラベルスイッチングルータ（ＬＳＲ）は、それらの間で、またそれらを介しトラフィックを転送するのに使用されるラベルの意味について合意している必要がある。ＬＤＰは、ＭＰＬＳドメイン内のラベル配信について規定されるプロトコルである。Ｃｏｎｓｔｒａｉｎｔ−ｂａｓｅｄルーティングＬＤＰ（ＣＲ−ＬＤＰ）は、Ｔｒａｆｆｉｃ  Ｅｎｇｉｎｅｅｒｉｎｇ要求を満たすための拡張である。
【００４８】
ＬＳＲは、ＣＲ―ＬＤＰを使用してＭＰＬＳネットワークを介しＬａｂｅｌ  Ｓｗｉｔｃｈｅｄ  Ｐａｔｈ（ＬＳＰ）を確立する。Ｆｏｒｗａｒｄｉｎｇ  Ｅｑｕｉｖａｌｅｎｃｅ  Ｃｌａｓｓ（ＦＥＣ）が、生成された各ＬＳＰに関連付けされる。このＦＥＣは、何れのパケットが当該ＬＳＰにマッピングされるか規定する。
【００４９】
ＣＲ−ＬＤＰを使用してラベルマッピング情報を交換する２つのＬＳＲ（Ｌａｂｌｅ  Ｓｗｉｔｃｈｅｄ  Ｒｏｕｔｅｒ）は、ＬＤＰピアとして知られており、それらは、それらの間のＬＤＰセッションを有する。１つのセッションでは、各ピアはその他のラベルマッピングに関して学習することが可能である。図５は、３つのＬＳＲのＡ、Ｂ及びＣの間のＬＳＰの確立のための設定手続を示す。ＭＰＬＳプロキシ１００は、Ｌａｂｅｌ  Ｒｅｑｕｅｓｔを送信することによって近隣のＬＳＲ  Ｂとの通信を開始する。ＬＳＲ  Ｂは、当該リクエストを次の近傍のＬＳＲ  Ｃに転送する。両ルータは、トラフィックパラメータをチェックし、利用可能であるときには、対応するリソースをリザーブする。Ｌａｂｅｌ  Ｍａｐｐｉｎｇメッセージは、ＬＳＰの確立の成功を示すペンディングリクエストのためＭＰＬＳプロキシに上流方向に送信される。各ＬＳＲは、リザーブされたリソースを検証し、必要な場合には、Ｌａｂｅｌ  Ｍａｐｐｉｎｇメッセージが受信されると、パラメータを再調整する。各ＬＳＲは、それのデータベースにルーティング情報（ラベルイン、ラベルアウト、ポート）とトラフィック制約（ベストエフォート、ギャランティードサービスなど）を格納する。
【００５０】
ここで、ＲＳＶＰリザベーションに関するさらなる詳細が提供される。ＲＳＶＰを利用した接続及びリザベーション確立は、ＭＰＬＳネットワーク内よりやや複雑である。特に、ＲＳＶＰによるリソースリザベーション（ＱｏＳ接続確立）が、データ送信機２１でなくデータ受信機３１により開始されるべきである。従って、ＲＳＶＰ送信機２１がＱｏＳサポートを利用してＲＳＶＰ受信機にデータを送信しようとする場合、それはＰＡＴＨメッセージを使用して受信機にデータフローしか通知しない。他のオブジェクトの中で、ＰＡＴＨメッセージはＴＳＰＥＣオブジェクトを含む。ＴＳＰＥＣオブジェクトは、送信機が送信しようとするトラフィックフローを記述する。図６において、ＴＳＰＥＣオブジェクトの全体的な構成が示される。
【００５１】
実際のリソースリザベーションは、ＲＥＳＶメッセージによりＲＳＶＰ受信機３１によりリクエストされるべきである。本発明による説明されるシナリオでは、受信機３１は、非ＲＳＶＰドメインにある。本発明によると、ＲＳＶＰ−ＭＰＬＳプロキシ１００は、データ受信機３１のためリソースリザベーションを要求する。リザベーションのトラフィックパラメータは、ＦＬＯＷＳＰＥＣオブジェクトの内部に記述される。図７において、ＦＬＯＷＳＰＥＣオブジェクトのフォーマットが示される。ＴＳＰＥＣ及びＦＬＯＷＳＰＥＣに対して示されたフォーマットが新たなＲＳＶＰベースサービスについて再定義することが可能であるということに留意すべきである。一般に、ＰＡＴＨメッセージ内に記述されるものと異なるフロー記述をリザーブすることは、受信機次第である。しかしながら、記載されるプロキシ処理シナリオでは、ＲＳＰＥＣのトラフィック記述を対応するＴＳＰＥＣのものに制限することはもっともである。
【００５２】
ＲＳＶＰフローマージ処理機構の簡単化のため、以降においてマージ処理の具体例が説明される。一般に、ＲＳＶＰメッセージのフロー記述（ＰＡＴＨメッセージ内のＴＳＰＥＣオブジェクトと、ＲＥＳＶメッセージ内のＦＬＯＷＳＰＥＣ）が、ＲＳＶＰネットワークオペレータとＭＰＬＳネットワークオペレータとの間で合意されるＭＰＬＳ接続のＱｏＳ記述よりはるかに詳述される。テーブル３は、ＭＰＬＳターゲットの設定されたＱｏＳ記述セットの一例を示す。送信機がＭＰＬＳターゲットを介し到達可能な送信先にリクエストをスタートする。プロキシ１００は、ＱｏＳ記述Ｄ１、Ｄ２又はＤ３の１つを有するターゲットのみと接続を確立することが可能である。
【００５３】
【表３】
2007336545.tif 000005
図８に参照できるように、送信機２１とプロキシ１００との間の第１ＲＳＶＰリザベーションがすでに確立されていると仮定する。このことは、送信機１がプロキシにＴＳＰＥＣ１を含むＲＳＶＰ  ＰＡＴＨメッセージを送信し、プロキシが、ＴＳＰＥＣ１のものと等しいＦＬＯＷＳＰＥＣ「１のトラフィックパラメータにより送信機１にＦＬＯＷＳＰＥＣ１を含むＲＥＳＶメッセージを送信したことを意味する（テーブル４を参照されたい）。
【００５４】
【表４】
2007336545.tif 000006
最大遅延を１００ｍｓに制限することによって、このＲＳＶＰフローはＱｏＳ記述Ｄ３とのＭＰＬＳ接続にマッピングされた。ここで、ＴＳＰＥＣ１に等しいＴＳＰＥＣ２による同一のＭＰＬＳターゲットＴ２を介し到達可能な送信機２から受信機へのＲＳＶＰ  ＰＡＴＨメッセージがプロキシ１００に到着する。ＴＳＰＥＣ１及びＴＳＰＥＣ２は、ＱｏＳ記述フォーマットにマッピングされ、一緒に加えられる。結果として得られる記述は、記述Ｄ３に適合し、このため、ＴＳＰＥＣ２のものに等しいトラフィックパラメータを含むＦＬＯＷＳＰＥＣ２による送信機２へのＲＳＶＰリザベーションが実行される。ＭＰＬＳ  ＱｏＳ記述に関するＭＰＬＳトンネルの結果としての使用が計算され、トラックダウンされる。テーブル５において、確立されたＭＰＬＳトンネルの計算されたリソース使用Ｄｏｖｅｒａｌｌが示される。
【００５５】
【表５】
2007336545.tif 000007
ＲＳＶＰ仕様の範囲内で、特定のＲＳＶＰ接続に属するフローが、ＩＤ＝｛送信機ＩＰアドレス，受信機ＩＰアドレス，送信機ポート，受信機ポート，プロトコルＩＰ（ＴＣＰ又はＵＤＰ）｝の識別子により特定される。特定のＩＤを有するＩＰパケットは、ノード内のＲＥＳＶ状態が有効である限り、ＲＳＶＰリザベーションに属する。ＭＰＬＳは、特定のＭＰＬＳの接続に割り当てられるローカルスコープタグを有するＭＰＬＳフレームへのデータパケットのさらなるカプセル化を提供する。このため、プロキシは、ＲＳＶＰ  ＩＤとＭＰＬＳラベルの関連付けを有するテーブルを維持する必要がある。ＲＳＶＰ  ＩＤを有する各ＩＰパケットは、特定のＭＰＬＳ接続について当該ノードに割り当てられる他ベルを有するＭＰＬＳフレームにマッピングされる。
【００５６】
最後に、引用されたＲｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ文書のリストが与えられる。
【００５７】
【表６】
2007336545.tif 000008
【図面の簡単な説明】
【００５８】
【図１】図１は、非ＲＳＶＰ対応ネットワークを介したＲＳＶＰ制御ＱｏＳの従来のトンネリングを示す。
【図２】図２は、Ｉｎｆｉｎｉｂａｎｄベース受信機によるネットワークアーキテクチャを示す。
【図３】図３は、ＲＳＶＰ−ＭＰＬＳプロキシによる本発明のネットワークアーキテクチャを示す。
【図４】図４は、ＲＳＶＰ−ＭＰＬＳプロキシの状態図である。
【図５】図５は、Ｌａｂｅｌ  Ｓｗｉｔｃｈｅｄ  Ｐａｔｈ確立のためのＣＲ−ＬＤＰメッセージを示す。
【図６】図６は、ＴＳＰＥＣオブジェクトのフォーマットを示す。
【図７】図７は、ギャランティードサービスのＦＬＯＷＳＰＥＣオブジェクトのフォーマットを示す。
【図８】図８は、ＭＰＬＳネットワークに対するフローマージ処理の一例を示す。
【符号の説明】
【００５９】
１０  インターネット
２０  ＲＳＶＰドメイン
２１  送信機、送信ステーション
２３  受信機
３１  受信ステーション
４０  トンネル
１００  ＲＳＶＰ−ＭＰＬＳプロキシ
【図１】
2007336545.tif 000009
【図２】
2007336545.tif 000010
【図３】
2007336545.tif 000011
【図４】
2007336545.tif 000012
【図５】
2007336545.tif 000013
【図６】
2007336545.tif 000014
【図７】
2007336545.tif 000015
【図８】
2007336545.tif 000016