JP2007306562A - 保護されたメディア・デバイス間の切換え - Google Patents

保護されたメディア・デバイス間の切換え Download PDF

Info

Publication number
JP2007306562A
JP2007306562A JP2007123041A JP2007123041A JP2007306562A JP 2007306562 A JP2007306562 A JP 2007306562A JP 2007123041 A JP2007123041 A JP 2007123041A JP 2007123041 A JP2007123041 A JP 2007123041A JP 2007306562 A JP2007306562 A JP 2007306562A
Authority
JP
Japan
Prior art keywords
network media
media device
switchover
redundant
nmd
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2007123041A
Other languages
English (en)
Inventor
Yuval Nissan
ユヴァル・ニッサン
Ofer Idan
オフェール・イダン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
AudioCodes Ltd
Original Assignee
AudioCodes Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by AudioCodes Ltd filed Critical AudioCodes Ltd
Publication of JP2007306562A publication Critical patent/JP2007306562A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1083In-session procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121Timestamp
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】1次ネットワーク・メディア・デバイスと、冗長ネットワーク・メディア・デバイスである2次ネットワーク・メディア・デバイスと、をほぼ同様の暗号化状態に維持することを含む通信システムを提供する。
【解決手段】2個のパケットが、1次ネットワーク・メディア・デバイスから送信される度に、又は1次ネットワーク・メディア・デバイスにおいて受信される度に少なくとも1回、1次ネットワーク・メディア・デバイスから冗長ネットワーク・メディア・デバイスに、受信スイッチオーバ・パラメータと、送信スイッチオーバ・パラメータと、をコピーすることにより、同様の暗号化状態が維持され得る。冗長ネットワーク・メディア・デバイスは、コピーされた受信スイッチオーバ・パラメータを利用することによってパケットを受信することができ、又、コピーされた送信スイッチオーバ・パラメータに基づいて送信スイッチオーバ・パラメータを推定することによってパケットを送信することができる。
【選択図】図1

Description

本開示は、一般にコンピュータ・ネットワーク及びネットワーク・セキュリティの分野に関する。より詳細には、本開示は、ネットワーク・メディア・デバイス間の切換えを行うシステム、装置、及び方法に関する。
インターネットの普及及びマルチメディア分野の絶え間ない発展に伴い、今日の音声及びビデオ・データ通信の大部分は、インターネット・プロトコル(IP)標準を利用するインターネット等のパケット交換ネットワークを使用して行われる。インターネットを介して音声及びビデオ・データを転送するように設計されたIP使用可能デバイスは、非常に人気が高まっている。
ホット・スワップ
インターネット等の通信システムでは、それ自体の高可用性(HA)が重大な関心事となる。即ち、通信システムの信頼性を高めるために、ネットワーク・デバイスは、平均で、それ自体の存続期間の99.999%稼動状態にあることが必要とされる。その要件を満たすことができない通信システムは、しばしば信頼性の低いものと見なされる。HAは、故障中のインスタントが1つ(又は複数)のネットワーク・ユーザに再びサービスを提供するようになるまで、故障中のデバイスによってそれまで提供されてきたサービスを引き続き提供するために、誤動作を起こしている活動状態の(1次)ネットワーク・デバイスをバックアップ・デバイス又は冗長デバイスに置き換えることを可能にすることによって保証される。誤動作を起こしているデバイスと、バックアップ・デバイス又は冗長デバイスとの置き換えは、当技術分野では「ホット・スワップ」として知られる機能であり、「フェイルオーバ(fail over)」及び「スイッチオーバ(switch over/switchover)」とも呼ばれる。
スイッチオーバは、一般に活動状態のデバイスから冗長デバイスに制御を移行することを指す。スイッチオーバでは、典型的には活動状態のサービス提供デバイスに関連する通信パラメータ(スイッチオーバ・パラメータ)を(直接又は間接的に)冗長デバイスに送ることが必要となる。スイッチオーバの成功とは、通信を遮断する必要なく活動状態のデバイスから冗長デバイスに制御が移行され、次いで、冗長デバイスが通信の制御を再開しながら、サービス提供対象のユーザとネゴシエートすることを指す。
スイッチオーバには、1次ネットワーク・デバイスから当該1次ネットワーク・デバイスのバックアップ・デバイスとして働く冗長ネットワーク・デバイスに、比較的単純な(non−challenging)通信パラメータをコピーすることしか必要とされない故に、非安全通信が行われる場合の1次VoIPネットワーク・デバイスと、(当該1次ネットワーク・デバイスをバックアップする)冗長VoIPネットワーク・デバイスとの間のスイッチオーバは、比較的容易である。「単純な(non−challenging)」という用語は、静的パラメータ、又はユーザ(リモートのネットワーク・デバイス)との間で行われる全体の通信セッションを通じて実質的に変更されないパラメータを指すが、これらのパラメータは、各通信セッション毎に数千ものデータ・パケットが両方向に移動する故に、変更される可能性もある。1次ネットワーク・デバイスからバックアップ・ネットワーク・デバイスにコピーされる例示的な通信パラメータは、IPアドレス、UDP(ユーザ・データグラム・プロトコル)ポート、フレーム・サイズ、エンコーダ及びデコーダ・タイプである。
保護されたデータが関与する場合のネットワーク・デバイス間のスイッチオーバの実施は、セキュリティ機能が必要とされる故に容易ではない。例えば、セキュリティ機能は、出力パケットに一意に割り当てられるシーケンス番号及び/又はタイムスタンプ、暗号化/解読及び認証スキーム、並びにリプレイ保護(replay protection)に役立つ測定値の使用を含む。従って、1次デバイスから冗長デバイスに制御が移行されるときは常に、透過的なスイッチオーバを保証する上で(非安全通信におけるスイッチオーバの要件よりも)多くの要件が存在し、例えば、スイッチオーバの成功を保証するために、セキュリティ機能に関するデータが1次デバイス/活動状態のデバイスから冗長デバイスにコピーされる必要がある。一般原則として、データ通信に要する(セキュリティ)機能の複雑性が高まるほど、スイッチオーバの容易性が低下する。
セキュリティ関係データをコピーすることが困難であるのは、1つ(又は複数)の非安全スイッチオーバで使用される静的パラメータとは対照的に、セキュリティ関係データが、動的パラメータを含むことに由来する。「動的パラメータ」という用語は、通常パケット・ストリーム内の各パケットを一意に特徴付けるために、所与の通信セッションにおいてそれ自体の値がパケット毎に変更されるパラメータを意味する。動的パラメータは、例えば、パケットが生成される相対時間に相当するタイムスタンプ(TimeStamp)、パケットに割り当てられる通し番号に相当するシーケンス番号(SEQ)、SRTPロールオーバ・カウンタ(ROC)、及びSRTP RTCPインデックスである。
IPプロトコルは、本来セキュリティ機能を提供しない。特に、データ・ネットワークを横切るデータ及び視聴覚関係データは、その時々に個人情報及び機密情報を含むことがある。従って、又、(任意のタイプのデータ・ネットワークを介した)安全なデータ転送が重要である故に、個人情報及び機密情報が権限のないユーザによって傍受されるのを防止する認証や暗号化等のセキュリティ機能を利用することが、望ましいこともある。かかるセキュリティを実装する1つのプロトコル・スイートは、一般にIPセキュリティ(IPsec又はIPSEC)として知られており、インターネット技術特別調査委員会(IETF)によって定義されている。IPSECは、参照によりその内容全体が本明細書に組み込まれるRFC(Requests For Comments:コメント要求)2401〜2412(S.Kent他著/1998年11月)に、より詳しく記載される。又、VoIPネットワークを介したメディア・トランスポートに使用されるRTPプロトコル向けに適合されたセキュリティを提供するために、セキュア・リアル・タイム・トランスポート・プロトコル(SRTP)として知られるより新しいプロトコルも、IETFによって定義されている。上記のセキュリティ・スイート(IPSEC及びSRTP)は、例えば「Using ESP to Prevent Replay Attacks」(Brien M.Posey著/MCSE、2002 Posey Enterprises)、「The longest short IP Sec Paper」(Walberts著/2005年1月10日)、及び「How Secure Is VoIP?」(Ahmar Ghaffar著/2004年11月)により詳しく記載されるように、何れもリプレイ攻撃に対する保護を提供する。
リプレイ攻撃及び保護
リプレイ攻撃は、有効なデータ送信が悪意をもって又は不正に繰り返され又は遅延される、ネットワーク攻撃の一形態である。このリプレイ攻撃は、場合によってはマスカレード攻撃の一部として発信者によって実行され、或いはデータの傍受又はコピー及び再送信を行う敵対者によって実行される。従って、2つのネットワーク・デバイス間で交換されるパケットを権限のないネットワーク・デバイスがコピーし「リプレイ」するのを防止するリプレイ防止手段が、使用される。リプレイ防止(replay prevention)は、参照によりその内容全体が本明細書に組み込まれるRFC 2402及びRFC 2406(S.Kent他著/1998年11月)に、より詳しく記載される。
OSI
OSI(開放型システム間相互接続)モデルは、開放型システム間相互接続イニシアティブの一部として開発された通信及びコンピュータ・ネットワーク・プロトコル設計に関する階層的な抽象記述である。このモデルは、OSI 7層モデルとも呼ばれる。簡潔にいうと、レイヤ1は、物理層であり、レイヤ2は、データ・リンク層であり、レイヤ3は、ネットワーク層である。最もよく知られるレイヤ3のプロトコル例は、インターネット・プロトコル(IP)である。レイヤ4は、トランスポート層である。最もよく知られるレイヤ4のプロトコル例は、伝送制御プロトコル(TCP)及びユーザ・データグラム・プロトコル(UDP)である。レイヤ5は、セッション層であり、レイヤ6は、プレゼンテーション層であり、レイヤ7は、アプリケーション層である。
IPSEC
IPプロトコルは、本来セキュリティ機能を提供しないので、(1)トラフィック暗号化(これにより、送信時にトラフィックが読み取られる恐れがなくなる)、(2)インテグリティ確認(これにより、トラフィックがそれ自体の途中の経路で修正されていないことが、保証される)、(3)ピア認証(これにより、両端のピアが、トラフィックの宛先である信頼されるエンティティと通信していることを確信する)、(4)アンチ・リプレイ(これにより、セッション・リプレイから保護される)等のセキュリティ・サービスを提供するIPセキュリティ(IPsec又はIPSEC)が、導入された。
一般に、IPSECは、全てのIPパケットを暗号化及び/又は認証することによってインターネット・プロトコル(IP)通信を保護するための規格である。IPSECは、ネットワーク層(OSIモデルのレイヤ3)のセキュリティを提供し、当該セキュリティは、TCPベースのプロトコルとUDPベースのプロトコルの両方を保護するのに使用され得ることから、IPSECを比較的柔軟なものにするが、IPSECは、TCP(OSIモデルのレイヤ4)に基づいて信頼性及びフラグメンテーションを管理することができない故に、IPSECの複雑性と、処理上のオーバーヘッドと、を高めることになる。IPSECは、パケット・フローと、1つ(又は複数)の通信鍵交換と、を保護するのに使用される1組の暗号化プロトコルである。パケット・フローを保護するのに使用される暗号化プロトコルには、(1)認証、データ秘匿性、及びメッセージ・インテグリティを提供するカプセル化セキュリティ・ペイロード(ESP)と、(2)認証及びメッセージ・インテグリティを提供するが秘匿性は提供しない認証ヘッダ(AH)の、2つの暗号化プロトコルが存在する。当初、AHは、インテグリティのためにだけ使用され、ESPは、暗号化のためにだけ使用されていたが、その後、認証機能が、ESPに追加された。現時点では、IKE(インターネット鍵交換)プロトコルという1つの鍵交換プロトコルだけが、定義されている。
IPSECでは、セキュリティ・アソシエーション(SA)が、ゲートウェイ等の2つのネットワーク・デバイス間における、保護された単方向のデータ・フローを記述する。SAは通常、必要に応じて、IKEを使用して自動的に確立されるが、IPSECの幾つかの実装形態を用いると、手動によるSAの確立が可能となる。SAは、宛先アドレスと、セキュリティ・パラメータ・インデックス(SPI)と、セキュリティ・プロトコルとによって定義される。SPIは、セキュリティ・パラメータを、IPアドレスと組み合わせて識別する。IPSECプロトコルは、RFC 2401〜2412で定義される。セキュリティ・アソシエーション(SA)は、OSIモデルのネットワーク層(レイヤ3)で使用されるIPSECを使用して2つのネットワーク・デバイス間の安全な通信を確立するために、関与する2つのネットワーク・デバイス間でネゴシエートされ、セットアップされ得る。SAは、典型的には鍵寿命、暗号化アルゴリズム、認証アルゴリズム等の情報の使用を含む。SAは、参照によりその内容全体が本明細書に組み込まれるRFC 2409に、より詳細に記載される。2つのネットワーク・デバイスは、SAを確立することに加えて、リプレイ防止もイネーブルしてセキュリティを高めることを可能にすることができる。
RTP
RTP(実時間トランスポート・プロトコル)プロトコルは、セッション層(OSIモデルのレイヤ5)で機能する。RTPは、RFC 3550(RFC 1889の進化版)で定義される。RFC 3551(RFC 1890の進化版)は、最小制御によるオーディオ及びビデオ会議(Audio and Video Conferences with Minimal Control)の特定プロファイルを定義する。参照によりその内容全体が本明細書に組み込まれるRFC 3711は、セキュア・リアル・タイム・トランスポート・プロトコル(SRTP)のプロファイル(実際にはオーディオ及びビデオ会議に関するRTPプロファイルの拡張版)を定義し、当該プロファイルは、配信されるオーディオ及びビデオ・ストリームの秘匿性、メッセージ認証、及びリプレイ保護を実現するために(任意選択で)使用され得る。
参照によりその内容全体が本明細書に組み込まれるRFC 3550によれば、RTPによって提供されるサービスは、(1)ペイロード・タイプの識別(Payload−type identification)と、(2)パケットの送信前に送信機によってパケットに割り当てられる単調増加番号に相当するシーケンス番号の付与(Sequence numbering)と、(3)各送信パケットへの生成時間の割当てを指すタイムスタンプの付与(Time stamping)と、(4)配信の監視(Delivery monitoring)(RTCP)と、を含む。
RTPは、音声及びビデオ・パケットを取り扱うように設計され、従って(パケットの再順序付けを可能にし、許容できない遅延及びジッタを回避するには)パケットのタイミングの側面が重要となることから、RTPに関連するプロトコルは、アプリケーションが受信パケットを正しい順序に確実に並べ替えることができるように、アプリケーションに対して必要なデータを配信する。又、RTCPは、(RTCPパケットを間欠的に送信することにより)アプリケーションがその情報を使用してローカルの(時間及び他の)調整を行うことができるようになる受信品質に関する情報も提供する。例えば、輻輳が生じつつある場合は、アプリケーションは、データ転送速度を下げることを決定することができる。
SRTP
SRTPは、RTPのプロフィルを定義し、当該プロファイルは、暗号化、メッセージ認証、及びインテグリティ、並びにユニキャストとマルチキャストの両方のアプリケーションにおけるRTPデータのリプレイ保護を提供することが企図される。SRTPは、高スループット化を促進するだけでなく、有線と無線の両方の通信ネットワーク要素から成る異種環境の適切な保護も実現することが考えられる。一般に、SRTPは、RTPパケットを傍受し、次いで、傍受されたRTPパケット毎に、それと等価な又は関連するSRTPパケットを送信者(送信)側に転送する。SRTPは、SRTPパケットも傍受し、それと等価なRTPパケットを受信側のスタック上に転送する。安全なRTCP(SRTCP)とRTCPの間の関係は、SRTPとRTPの間の関係と同様であり、即ち、SRTCPは、RTCPと同様のセキュリティ・サービスを提供する。SRTCPのメッセージ認証の使用は、例えばストリーム・メンバシップを追跡するためにRTCPフィールドを保護し、フィードバック・データをRTP送信者に供給する上で、又、パケット・シーケンス・カウンタを維持する上で義務付けられている。
SRTP等のセキュリティ・プロトコルは、典型的にはリプレイ保護として知られる機能を含む。RFC 3711を参照すると、パケットが「リプレイ」されることが記載されており、又、パケットの記憶が敵対者によって行われたときに「リプレイ攻撃」が発生し、次いで、当該パケットが敵対者によってパケット傍受元のデータ・ネットワークに再注入されることが、記載されている。RFC 3711、即ちSRTPプロトコルは、リプレイ攻撃から受信デバイスを保護する手段として、リプレイ・リストを利用する。受信デバイスは、それ自体が受信する全てのパケットのインデックスを含むリプレイ・リストを有し、正当なパケットと、不正な(リプレイ)パケットと、を区別する「スライディング・ウィンドウ(sliding window)」を使用する。受信デバイスは、入力パケットを、リプレイ・リストに記憶されたインデックスと突き合わせて比較することによって、リプレイ・パケットを認識する。受信パケットのインデックスが、スライディング・ウィンドウ内に存在するが、当該パケットが、初めて受信されたものである場合は、当該パケットは、正当なものと見なされる。このことは、スイッチオーバが発生するときは常に、次の受信パケットのインデックスが、最後に使用された/知られたインデックスよりも大きくなることを意味する。
PacketCable(商標)
PacketCable(商標)は、Cable Television Laboratories,Inc(CableLabs(登録商標))によって設立された組織であり、ケーブル・システムを介してパケット・ベースの音声及びビデオ製品を識別し、検定し、サポートすることを目的とする。CableLabsは、双方向ケーブル・ネットワークを介して実時間マルチメディア・サービスを配信する、相互運用可能なインターフェイス仕様を提供するためのイニシアティブを主導する。当業界のDOCSIS(商標)1.1(データ・オーバ・ケーブル・サービス・インターフェイス仕様)ケーブル・モデム・インフラストラクチャに基づいて構築されたPacketCableネットワークは、インターネット・プロトコル(IP)を使用して、IP電話、マルチメディア会議、対話型ゲーム、及び一般的なマルチメディア・アプリケーションのような広範なマルチメディア・サービスを可能にする。PacketCableの機能拡張を伴うDOCSIS 1.1ネットワークは、ケーブル事業者が、サービス品質(QoS)対応の単一の高速ブロードバンド(ケーブル)アーキテクチャを使用してデータ及び音声トラフィックを効率的に配信することを可能にする。
PacketCableは、光ファイバ同軸ハイブリッド(HFC)接続ネットワークと、公衆交換電話網(PSTN)と、TCP/IP管理型IPネットワークの、3つのネットワークを相互接続する。PacketCableプロトコルには、データ・オーバ・ケーブルの仕様であるDOCSISと、メディア転送に必要とされる実時間トランスポート・プロトコル(RTP)及び実時間制御プロトコル(RTCP)と、メディア・ゲートウェイに関するMGCP(メディア・ゲートウェイ制御プロトコル)の拡張仕様であるPSTNゲートウェイ・コール・シグナリング・プロトコル仕様(TGCP)と、家庭用アナログ・メディア・ゲートウェイに関するMGCPの拡張仕様であるネットワーク・ベース・コール・シグナリング・プロトコル仕様(NCS)とがあるが、これらの内、NCS仕様は、MGCPに関するIETFのRFC 2705から派生したものであり、VoIPシグナリングの詳細を示すものである。
PacketCableは、SRTPの場合のようにROC値を使用する(ROCが通信パケット数と関連付けられる)代わりに、RTPのタイムスタンプが循環(wrap around)する回数をカウントするカウンタであるNwrapと呼ばれるパラメータを使用する。送信デバイスと受信デバイスとは、RTPタイムスタンプが0〜216−1の範囲内で循環するカウント(Nwrap)を維持する必要があるが、このことは、RTPパケットのタイムスタンプ値が循環する度に、Nwrap値が1だけ増分されることを意味する。Nwrap値は、通信接続が確立されると同時にゼロに初期化される。循環点を過ぎて受信されたRTPパケットを受信機が正しく解読できるように、Nwrapは、(同期的に)受信機側でも増分される必要がある。Nwrapの意味については、以下の例を使用して説明する。

RTP音声パケットは、当初16進数値の0xFFFFF000と等しいランダムなタイムスタンプを有することができる。各音声パケットの長さが、40ミリ秒であり、音声信号のサンプリング・レートが、8サンプル/ミリ秒であると仮定すると、各音声パケットの長さは、サンプル数で表せば320となる(40*8=320)。又、簡略化のために、Nwrapの現在値はゼロと仮定される。以下の表1も参照すると、送信サンプル(TS)の数は、(音声)パケットが送信される度に320(サンプル)ずつ増加する。TS値が0〜232−1の範囲内にある限り、パケット番号1〜iに関するNwrap値は、変更されないまま(この例では0)である。しかしながら、パケット番号i+1における320個のサンプルを0xFFFFFF00(パケット番号iに関するTS値)に追加すると、TS値(0x40)が、TSの最大限界を循環することになり、この理由から、以下の表では、パケットi+1に関するNwrap値が、(0から)1に増分されている。
Figure 2007306562
ROC値の場合と同様に、送信機と受信機とが、それぞれのNwrapカウンタを増分させ、受信機が、(受信パケット内の他のデータを利用することによって)送信機のNwrap値を追跡しようと(同期をとろうと)試みるので、Nwrap値は、送信パケットと共に送信されるわけではない。
メディア・スイッチオーバ
IPSECに関しては、あるネットワーク・デバイスと、別のネットワーク・デバイスとの間のスイッチオーバに関する解決策は、デバイス間のセキュリティ・アソシエーションの切換えと、所定の最大シーケンス番号に対する2つの異なるシーケンス番号ドメインの使用と、を含むことができる。この解決策によれば、関与する2つのネットワーク・デバイスが、同じセキュリティ・アソシエーションと関連付けられるが、一方のネットワーク・デバイスは、最大シーケンス番号よりも小さくなるように予め定義されたシーケンス番号の限界と関連付けられ、他方のネットワーク・デバイスは、最大シーケンス番号よりも大きい所期シーケンス番号を有する。かかる解決策は、米国特許第6966003号に、より完全な形で開示される。
しかしながら、(32ビットのシーケンス番号(SEQ)が、各IPSECパケットのヘッダに明示的に含められ、それによって受信デバイス側での当該シーケンス番号の抽出が比較的容易となる)IPSECとは対照的に、SRTPでは、RTPのSEQの長さが、16ビットしかなく、従って、IPSECシーケンス番号が米国特許第6966003号で利用されるような手法で、1つ(又は複数)のスイッチオーバについてRTPのSEQ番号を利用することができない故に、米国特許第6966003号に開示される解決策は、SRTPに関しては効果を発揮することができない。その代わりに、従来、SRTPプロトコルは、通信帯域幅を節約するために、式(1)に示されるような暗黙的なインデックス要素を含み、又はそれらの要素から成る、パケットを順序付けするためのインデックス(以下、本明細書では修正版SEQインデックス(modified SEQ index)iと呼ぶ)を利用する。
i=216 * ROC+SEQ (1)
上式で、iは、各パケットを順序付けするのに使用される修正版SEQインデックスであり、SEQは、216個のパケットから成る所与の集合の範囲内で各パケットに一意に割り当てられる、明示的なRTPシーケンス番号であり、ROC(ロールオーバ・カウンタ)は、送信機側では、それ自体の値が、SEQが循環される度に1だけ増分され、受信機側では、それ自体の値が、受信パケットに従ってやはり1だけ増分されるカウンタであるが、ROCは、参照によりその内容全体が本明細書に組み込まれるRFC 3711に、より詳しく開示され記載される。送信機が、送信機自体のROC値を送信するのではなく、受信機が、送信機のROC値の分だけ受信機自体のROC値を増分させることにより、送信機のROC値との同期をとろうと試みる。
修正版SEQインデックスiは、リプレイ保護(RFC 3711、Section3.3.2参照)、暗号化(RFC 3711、Section4.1参照)、メッセージ認証(RFC 3711、Section4.2参照)、及び通信鍵の導出(RFC 3711、Section4.3参照)で使用される。更に、シーケンス番号が、新しいパケット毎に更新され、毎秒数千ものパケットが、送信され得ることから、スイッチオーバのために多数のシーケンス番号を更新し維持することは、非常に非効率な解決策である。例えば、シーケンス番号情報をパケット単位で更新し維持することによって、処理時間や帯域幅等の貴重なネットワーク資源が浪費されることになる。更に、冗長ネットワーク・デバイスが、2つ以上のネットワーク・デバイスにサービスする(それらをバックアップする)場合は、冗長ネットワーク・デバイスがそれぞれ複数のネットワーク・デバイスに対応する膨大な数のシーケンス番号を取り扱うことは、一層難しくなる可能性がある。
SRTP及び(やはりRTPに基づく)PacketCable(商標)のセキュリティは、メディア・セキュリティの分野で普及していくことが予想されることから、RTP対応のネットワーク・デバイス等、保護されたメディア・ネットワーク・デバイス間のスイッチオーバを可能にする手法を考案することが、有益であるはずである。
概要
本発明に関する以下の諸実施形態及び態様は、システム、ツール、及び方法に関して説明され図示されるが、これらは、例示的且つ説明的なものであり、本発明の範囲を限定するものではない。様々な実施形態では、上述の問題の1つ又は複数が、緩和され又は解消されているが、他の利点又は改良点を対象とする他の実施形態も存在する。
本開示の一部として、1つ(又は複数)の1次ネットワーク・メディア・デバイス(1つ(又は複数)の「NMD」)と、1つ(又は複数)の1次NMDをバックアップする冗長ネットワーク・メディア・デバイスであってもよい2次ネットワーク・メディア・デバイス(NMD)と、をほぼ同様の暗号化状態に維持する方法が、提供される。1つ(又は複数)のNMDは、1つ(又は複数)のネットワーク・メディア処理ボード、1つ(又は複数)のネットワーク・メディア・ゲートウェイ、1つ(又は複数)のネットワーク・メディア・サーバ等であってもよい。この方法は、1次NMDが、リモートNMDであってもよいリモートのネットワーク・デバイスにサービスを提供することができなくなった場合に、1次NMD(通常は活動状態の又はメインのNMD)と、冗長NMDとの間の切換えを行うステップを含むことができる。
幾つかの実施形態によれば、例えば次の何れかの状態に最初に到達した時点で、即ち、2個のパケット(1≦X≦15、好ましくはX=13)が、1次ネットワーク・デバイスからリモートの(ユーザの)ネットワーク・デバイスに送信される度に、又は、リモートのネットワーク・デバイスから2個のパケットが、1次ネットワーク・デバイスにおいて受信された後に、少なくとも1回、所定の基準に従って1つ(又は複数)のスイッチオーバに関連するパラメータ(以下、「スイッチオーバ・パラメータ」と呼ぶ)が、更新され得る。
幾つかの実施形態によれば、1次NMDが通信を維持することができなくなった(リモートNMDにサービスを提供することができなくなった)ことを理由に、1次NMDと、リモートNMDとの間の通信セッションが、中断されたときに、リモートNMDは、(サービスを引き続き提供するために)メモリ・ストレージ・アレイに記憶されたスイッチオーバ・パラメータを利用してリモートNMDとの通信セッションを継続することができる。リモートNMDは、それ自体のローカル・メモリ・ストレージ・アレイに記憶され、又はリモートのメモリ・ストレージ・アレイから冗長NMDに転送された、更新済みのスイッチオーバ・パラメータにアクセスすることができる。
幾つかの実施形態によれば、冗長NMDは、それ自体と直接結合され得る1つの1次NMDをバックアップすることができる。幾つかの実施形態によれば、冗長NMDは、中央ネットワーク・デバイス(「CND」)と直接結合され得るものであれば、2つ以上の活動状態のNMDをバックアップすることもできる。これらの実施形態によれば、CNDは、CNDに結合された各1次NMDに関するスイッチオーバ・パラメータをそれ自体のメモリ・ストレージ・アレイに記憶することができ、故障中の1次NMDに関する又はそれと関連付けられるスイッチオーバ・パラメータだけを(やはりCNDと結合された)冗長NMDに転送することができる。
幾つかの実施形態によれば、活動状態の1次NMDから冗長NMDにスイッチオーバすることは、冗長NMDによって行われる、スイッチオーバ・パラメータの最後の更新値に基づく現在の送信スイッチオーバ・パラメータの推定を含むことができる。スイッチオーバ・パラメータは、冗長NMDに(1つ又は複数の活動状態の1次NMDから)直接供給されても、(CNDから)間接的に供給されてもよい。
幾つかの実施形態によれば、スイッチオーバ・パラメータは、IPSECプロトコルに関連するものであってよい。幾つかの他の実施形態によれば、スイッチオーバ・パラメータは、SRTP或いはPacketCableセキュリティ・プロトコルに関連するものであってもよい。
添付の図面を参照し、以下の詳細な説明を検討すれば、上述の例示的な諸態様及び実施形態だけでなく、他の態様及び実施形態も明らかとなるであろう。
なお、例示的な諸実施形態は、参照図面に記載される。本明細書に開示される諸実施形態及び図面は、限定的なものではなく例示的なものであることが企図される。しかしながら、動作構成と動作方法の両方に関する開示、並びにそれ自体の目的、特徴、及び利点は、以下の詳細な説明を添付の図面と併せて読めば最もよく理解されるであろう。
図面を簡潔にし、分かりやすくするために、添付の図面に示される各要素は、必ずしも縮尺どおりに描かれてはいないことが理解されるであろう。例えば、幾つかの構成要素の寸法は、図面を分かりやすくするために、他の要素よりも拡大されて示されることがある。更に、それが適切であると見なされる場合は、対応する又は類似する要素を示す参照番号が、各図面を通して繰り返されることもある。
以下の詳細な説明では、本開示の完全な理解を与えるために、様々な具体的な詳細が、詳しく記載される。しかしながら、本開示はこれらの具体的な詳細が与えられない場合にも実施され得ることが、当業者には理解されるであろう。その他の場合にも、本開示が不明瞭にならないように、よく知られた方法、手順、構成要素、及び回路については、詳細には説明していない。
以下の論述を読めば明らかとなるように、「処理(processing)」、「コンピューティング(computing)」、「計算(calculating)」、「判定(determining)」等の用語を利用した表現は、本明細書の全体を通じて別段の記述がない限り、コンピューティング・システムのレジスタ及び/又はメモリ内の物理量、例えば電子量等で表現されるデータを操作し、且つ/又は、当該データを、コンピューティング・システムのメモリ、レジスタ、又は他のそのような情報記憶デバイス、伝送デバイス、又は表示デバイス内の物理量として同様に表現される他のデータに変換するコンピュータ、又はコンピューティング・システム、或いは同様の電子コンピューティング・デバイスの動作及び/又は処理を指す。
本発明は全体的にハードウェアの実施形態の形をとることも、全体的にソフトウェアの実施形態の形をとることも、ハードウェア要素とソフトウェア要素の両方を含む実施形態の形をとることもできる。好ましい一実施形態では、本開示は、それだけに限らないが、ファームウェア、常駐ソフトウェア、マイクロコード等を含むソフトウェアの形で実施される。
本開示の諸実施形態は、本明細書に記載の各処理を実施する装置を含むことができる。本装置は、所望の目的に合わせて特別に設計されてもよく、又、コンピュータに記憶されたコンピュータ・プログラムによって活動化され又は再構成される汎用コンピュータを備えてもよい。
更に、本開示は、コンピュータ又は任意の命令実行システムによって或いはそれらと併せて使用されるプログラム・コードを備えるコンピュータ使用可能な媒体又はコンピュータ読取り可能な媒体からアクセス可能な、コンピュータ・プログラムの形をとることもできる。本明細書では、コンピュータ使用可能な媒体又はコンピュータ読取り可能な媒体は、上記の命令実行システム、装置、又はデバイスによって或いはそれらと併せて使用される上記のプログラムを収容し、記憶し、通信し、伝搬し、又は移送することができる任意の装置であってよい。
プログラム・コードを記憶及び/又は実行するのに適したデータ処理システムは、システム・バスを介してメモリ要素に直接又は間接的に結合された少なくとも1つのプロセッサを含むことができる。メモリ要素は、実際のプログラム・コードの実行時に利用されるローカル・メモリと、バルク・ストレージと、実行時に必要とされるバルク・ストレージからのコード検索の回数を減らすために少なくとも一部のプログラム・コードの一時記憶域を提供するキャッシュ・メモリと、を含むことができる。入力/出力又はI/Oデバイス(それだけに限らないが、キーボード、表示装置、ポインティング・デバイス等を含む)は、システムと直接結合されても、介在するI/Oコントローラを介して結合されてもよい。
このシステムには、介在する私設ネットワーク又は公衆ネットワークを介してデータ処理システムが他のデータ処理システムと、或いはリモートのプリンタ又はストレージ・デバイスと結合されることを可能にするネットワーク・アダプタも結合され得る。モデム、ケーブル・モデム、及びイーサネット(登録商標)・カードは、現時点で利用可能なタイプのネットワーク・アダプタのほんの一部に過ぎない。
本明細書に提示される処理は、何らかの特定のコンピュータ又は他の装置と固有に関係付けられるものではない。本明細書の教示によるプログラムと共に様々な汎用システムが使用される可能性があり、又、所望の方法を実施するために、より専門性の高い装置を構築することが、便利であるとされる可能性もある。これらの様々なシステムに必要とされる構造は、以下の記載から明らかとなるであろう。更に、本開示の諸実施形態は、何らかの特定のプログラム言語を参照して説明されるわけではない。本明細書の記載されるように本開示の教示を実施するために、様々なプログラム言語が使用され得ることが、理解されるであろう。
ネットワーク・メディア・デバイスという用語は、一般には、主にマルチメディアの通信、実時間セッションの通信、及びオーディオ・ファイル、ビデオ・ファイル、画像ファイル等のファイルの通信を円滑にするために(インターネット等の)コンピュータ・ネットワークで使用されるデバイスを指す。
ここで、図1を参照すると、(全体的に100で示される)典型的な冗長システムの全体的なレイアウト及び機能が、概略的に示される。システム100は、ネットワーク・メディア・デバイス(NMD)101等、1つ(又は複数)の1次ネットワーク・デバイスと、1つ(又は複数)の1次ネットワーク・デバイスをバックアップする冗長ネットワーク・デバイスとして働くことができる冗長NMD 102等の2次ネットワーク・デバイスと、を含むことができる。システム100が、(図1に示されるように)活動状態のデバイスであるNMD 101等、1つのNMDだけを含む場合は、ユーザに1つ(又は複数)のサービスを提供することが企図されたNMD 101は、受信スイッチオーバ・パラメータと、送信スイッチオーバ・パラメータと、をメモリ・ストレージ・アレイ111にコピーすること等によって、冗長NMD 102内のメモリ・ストレージ・アレイ111を直接更新することができる(103)。幾つかの実施形態によれば、メモリ・ストレージ・アレイ111(例えばデータベース)は、(他のデータの内でもとりわけ)スイッチオーバ・パラメータを記憶するのに使用され得、活動状態のNMD(NMD 101)は、所定の時間間隔に従って、記憶済みのスイッチオーバ・パラメータの値を更新することができる(以下では、この処理を一般に「スイッチオーバ更新」と呼ぶ)。
幾つかの実施形態によれば、例えばメモリ・ストレージ・アレイ111に記憶されたスイッチオーバ・パラメータは、非安全通信と関連付けられることもある。例示的な非安全スイッチオーバ・パラメータは、ユーザのIPアドレス、UDPポート、音声に関するパラメータ(コーダー使用情報、無音圧縮時の使用情報、フレーム・サイズ情報等)、及びパケット化パラメータ(各パケットのフレーム数、冗長モード、RTPのペイロード・タイプ、同期化ソースの識別子等)である。
幾つかの実施形態によれば、メモリ・ストレージ・アレイに記憶されたスイッチオーバ・パラメータは、保護されたデータ通信と関連付けられることもある。例示的な安全なスイッチオーバ・パラメータは、セキュリティ・キー、パケットのタイムスタンプ(TimeStamp)、パケットのシーケンス番号(SEQ)、RTCPインデックス、ロールオーバ・カウンタ(ROC)、及びNwrap(RTPタイムスタンプの循環数)である。
幾つかの実施形態によれば、メモリ・ストレージ・アレイ111は、(図1に示されるような)冗長NMD 102内に所在することもあり、活動状態のNMD 101は、冗長NMD 102と直接通信することによってメモリ・ストレージ・アレイ111を更新することができる。幾つかの他の実施形態によれば、メモリ・ストレージ・アレイ111は、(104で示されるように)活動状態のNMD 101と結合され、(106で示されるように)冗長NMD 102と結合された、中央ネットワーク・デバイス(CND)105等の中央ネットワーク・デバイス内に所在することもあり、活動状態のNMD 101は、(2個のパケットが、NMD 101において受信され、又はNMD 101から送信される)所定の基準に従って、CND 105内のメモリ・ストレージ・アレイを更新することができる。
別法として、NMD 101は、(104で示されるように)スイッチオーバ・パラメータを用いて中央ネットワーク・デバイス105等の中央ネットワーク・デバイス(CND)内に所在するメモリ・ストレージ・アレイ(図示せず)を更新することができ、中央ネットワーク・デバイス105は、(106で示されるように)冗長NMD 102内のメモリ・ストレージ・アレイ111を更新することもできるが、冗長NMD 102にとっては複数のNMDを取り扱うことよりも1つの中央ネットワーク・デバイスを取り扱うことの方が遥かに容易である故に、例えばNMD 101等、比較的多くの数のネットワーク・メディア・デバイスが使用される場合は、(中央ネットワーク・デバイス105等の中央ネットワーク・デバイスを使用する)後者のアーキテクチャが採用される。
システム100は、(108で示される)パケット交換ネットワークを介してリモートNMD 107等の多くのリモートNMDにメディア・コンテンツを供給することができる。メディア・コンテンツの通信では典型的に比較的高いデータ転送速度が必要とされるので、通信経路109は、高帯域幅チャネルである必要がある。NMD 101が、例えばリモートNMD 107から必要とされるメディア・コンテンツを提供することができなくなったときは、誓約された(vowed)高可用性を保証するために、リモートNMD 107との通信が、(109に示されるように)NMD 101から冗長NMD 102へと透過的に移行され、サービスが、実質的に中断されることなくリモートNMD 107に提供される。
安全なメディア・スイッチオーバ
本開示によれば、冗長NMD 102は、NMD 101と、リモートNMD 107との間で進行中の通信セッションに関連するスイッチオーバ・パラメータがそれ自体に記憶されるデータベース或いは(図1の111で示される)任意の適当なメモリ・ストレージ・アレイを含むことができる。通常、2つのデバイス間の通信セッションは、ネゴシエーションと呼ばれるステージを使用して開始され、各デバイスは、当該ステージの間にそれぞれの能力と、通信の詳細(例えば鍵)と、を交換する。しかしながら、メモリ・ストレージ・アレイ(メモリ・ストレージ・アレイ111等)を本明細書に記載される手法で使用することにより、冗長NMD 102と、リモートNMD 107との間のかかるネゴシエーションは、省略される。即ち、冗長NMD 102は、ユーザとの(例えばリモートNMD 107との)ネゴシエーションを行う必要がない。
非安全通信に関しては、ある通信セッションから別の通信セッションに移るときにだけ、メモリ・ストレージ・アレイ111に記憶されたスイッチオーバ・パラメータが、変更(更新)され得る。従って、(103に示される)NMD 101と、冗長NMD 102との間の通信は、通信経路109を介してメディア・コンテンツを転送するのに必要とされる帯域幅よりも遥かに狭い帯域幅しか必要としない。メモリ・ストレージ・アレイに記憶され得る例示的なスイッチオーバ・パラメータは、音声通信に関連する発信元及び宛先IPアドレス、発信元及び宛先UDPポート、コーダーに関するパラメータ、パケット化に関するパラメータ等である。
別法として、冗長NMD 102が、更新済みのスイッチオーバ・パラメータを、(103に示されるように)直接更新されたものではなく、中央ネットワーク・デバイス105等の第3のポートから取得した場合は、メモリ・ストレージ・アレイ111は、NMD 101及び冗長NMD 102と個別に通信することができるCND 105内に所在させてもよい。1つのデバイス(例えば冗長NMD 102)が冗長デバイスとして働して例えばNMD 101等、N個のNMDをバックアップするアーキテクチャは、当技術分野では一般に「N+1」(又は「1+N」)アーキテクチャとして知られており、その概略図が、図2に示される。
SRTP
リモートのネットワーク・メディア・デバイス(リモートNMD 107等)と、ネットワーク・メディア・デバイス(NMD 101等)との間の通信セッションが開始されるときは、各側でROC値をゼロにセットしなければならない。各側(例えば冗長NMD 107とNMD 101)は、(双方向の)通信セッション中に他方側との間でパケットを送受信する。送信者は、(リモートNMD 107に関連するものであれ、NMD 101に関連するものであれ)送信者に関連するSEQ(RTPパケットのシーケンス番号)が循環される度に、ROC値を1だけ増分させる必要がある。
式(1)に示されるように、ROC値は、修正版SEQインデックス(i)を作成するのに使用されるが、ROC値自体は、パケットに入れて明示的に(そのままの形で)送信されるわけではない。更に、通信セッション内で活動状態のNMDから送信されるパケットの数は、RTPパケットに利用可能な最大のシーケンス数である64,000(=216)を超えることが多い故に、米国特許第6966003号に開示されるIPSECの32ビット長SEQの使用とは対照的に、RTPの16ビット長SEQ番号は、スイッチオーバに使用され得ない。更に、SEQは、IPSECのSEQの使用とは対照的に、ゼロから開始するのではなく、あるランダム数から開始する。従って、1〜216の範囲内のSEQ値は、NMD 101等の活動状態のNMDと、冗長NMD 102等の冗長NMDとの間のスイッチオーバに関する新しい参照SEQ番号として使用されることはない。
理論的には、メモリ・ストレージ・アレイ111は、各受信パケット及び送信パケットに関する更新済みのROC値と、更新済みのSEQ値と、を収容することができる。しかしながら、本解決策は、広い通信帯域幅と、かなりの処理電力と、を必要とし、決して実用的なものではない。
本開示に記載のシステム及び方法は、SRTPプロトコルの機能を利用して、(ある種の制限下で)パケット損失やパケットの再順序付け等のネットワーク障害に対処することが可能である。RFC 3711によれば、受信機は、パケットの再順序付け及びパケット損失がそれ程多くなく、不都合なビット誤りが発生しない限り、支障なく機能することが予想される。特に、RFC 3711によれば、かかる大規模な損失又は再順序付けは、RTPの適用自体を妨げる可能性が高いので、必然的に、215個ものパケットが失われ、或いは215個のパケットの順序が狂うことになり、その後(送信デバイスと受信デバイスとの間の)同期は、失われることになる。
上述のSRTPプロトコルの機能を使用することにより、NMD(例えばNMD 101)から冗長NMD(例えば冗長NMD 102)にスイッチオーバ・パラメータがコピーされ得る更新レートは、実質上215個のパケット毎に1回という非常に低い更新レートとすることができる。スイッチオーバの更新レートが低くなるほど、メモリ・ストレージ・アレイの更新に要する通信帯域幅も狭くなり、その更新に必要な計算資源も少なくなる故に、スイッチオーバの更新レートは、低い方が良い。215よりも低いレート、例えば次の何れかの状態に最初に到達した時点で、即ち、213個のパケットが送信された時点又は受信された時点で冗長NMDを更新することによって、安全なマージン(safety margin)が、提供され得る。安全なマージンは、ネットワーク障害によって引き起こされる恐れがある問題又はそれによって生じ得る問題を防止又は回避するのに必要とされる。
RTPは、RTPセッションを制御するための、RTCPパケットと呼ばれる特別なタイプのパケットを使用するものである。RTCPパケットは、1つ(又は複数)のエンド・ユーザ宛てのデータ又は情報のどのような部分も保持しないが、それらのデータ又は情報を受信するデバイスが通信経路又はリンクの品質を推定することを可能にする。RTCPパケットは、他のタイプのパケットと同様に保護される(安全な状態にされる)必要がある。SRTPのRTCP保護(SRTCPとも呼ばれる)に関しては、SRTCPインデックスが、各送信パケットに付加される。SRTCPインデックスは、IPSECでSEQインデックスが使用されるのと同様の手法で、SRTPのリプレイ保護に使用される。
音声チャネルでは、次式(2)から、更新間隔(Time Between Updates:TBU)が、求められ得る。
TBU=213 * Frame_Size * Num_Frames_Per_Packet (2)
上式で、213は、例示的な更新レートであり、Frame_Sizeは、RTPパケットのミリ秒(msec)単位のフレーム・サイズであり、Num_Frames_Per_Packetは、RTPパケットのフレーム数である。例えば、Frame_Size=20msec、Num_Frames_Per_Packet=2と仮定した場合、TBU=327.68秒となり、このTBUは、かなり低い更新レートである。
本開示によれば、実質的に透過的なスイッチオーバを得るために(NMD 101と、冗長NMD 102と、をほぼ同様の暗号化状態に維持するために)、NMDから冗長NMDに、(1)パケットのタイムスタンプ(TimeStamp)と、(2)パケットのシーケンス番号(SEQ)と、(3)ロールオーバ・カウンタ(ROC)と、(4)RTCPインデックスの、4つのタイプのスイッチオーバ・パラメータが、コピーされ得る。NMDは、パケットの送信及び受信を行う故に、本明細書で「送信スイッチオーバ・パラメータ」と呼ばれ、NMDからパケットを送信する際に使用される4つのスイッチオーバ・パラメータと、本明細書で「受信スイッチオーバ・パラメータ」と呼ばれ、NMDにおいてパケットを受信する際に使用される4つのスイッチオーバ・パラメータの、合計8つのパラメータが、冗長NMDにコピーされる必要がある。従って、冗長NMD 102等の冗長NMDを更新するには、以下の8つのスイッチオーバ・パラメータ(4つの受信スイッチオーバ・パラメータと、4つの送信スイッチオーバ・パラメータ)を冗長NMDにコピーする必要がある。
送信スイッチオーバ・パラメータは、次の4つである。
(1)NMD(例えばNMD 101)からリモートNMD(例えばリモートNMD 107)に送信されるパケットに割り当てられるタイムスタンプに相当する、RTP_Tx_TimeStamp(RTPは、RTPプロトコルを指す)と、
(2)NMD(例えばNMD 101)からリモートNMD(例えばリモートNMD 107)に送信されるパケットに関する(当該パケットに割り当てられる)シーケンス番号に相当する、RTP_Tx_SEQ(RTPは、RTPプロトコルを指す)と、
(3)NMD(例えばNMD 101)からリモートNMD(例えばリモートNMD 107)に送信されるパケットに関連するROC値に相当する、RTP_Tx_ROC(RTPは、RTPプロトコルを指す)と、
(4)NMD(例えばNMD 101)からリモートNMD(例えばリモートNMD 107)に送信されるパケットに関連するRTCPインデックスに相当する、RTCP_Tx_Index(RTPは、RTPプロトコルを指す)。
受信スイッチオーバ・パラメータは、次の4つである。
(5)NMD(例えばNMD 101)によって受信されるリモートNMD(例えばリモートNMD 107)からのパケットに割り当てられるタイムスタンプに相当する、RTP_Rx_TimeStamp(RTPは、RTPプロトコルを指す)と、
(6)NMD(例えばNMD 101)によって受信されるリモートNMD(例えばリモートNMD 107)からのパケットに関する(当該パケットに割り当てられる)シーケンス番号に相当する、RTP_Rx_SEQ(RTPは、RTPプロトコルを指す)と、
(7)NMD(例えばNMD 101)によって受信されるリモートNMD(例えばリモートNMD 107)からのパケットに関連するROC値に相当する、RTP_Rx_ROC(RTPは、RTPプロトコルを指す)と、
(8)NMD(例えばNMD 101)によって受信されるリモートNMD(例えばリモートNMD 107)からのパケットに関連するRTCPインデックスに相当する、RTCP_Rx_Index(RTPは、RTPプロトコルを指す)。
本明細書で、特定のスイッチオーバ・パラメータに関して「現在の(current)」という用語が使用されたときは常に、スイッチオーバが完了した後に冗長NMD(例えば冗長NMD 102)によって使用されることになるスイッチオーバ・パラメータの初期値を指す。特定のスイッチオーバ・パラメータに関して「最後の(last)」という用語が使用されたときは常に、最後のスイッチオーバ・パラメータの更新中に又はその更新の結果、冗長NMDに最後にコピーされたスイッチオーバ・パラメータの値を指す。
先に説明したように、受信メディア・デバイスは、SRTPを使用して最大215個の損失パケットと、順序が狂った215個のパケットと、を修復し、又、以下で説明するように、送信スイッチオーバ・パラメータ及び受信スイッチオーバ・パラメータが、様々な手法で計算される。NMD 101が、リモートNMDにサービスを提供することができなくなったときは、冗長NMD 102は、最後のスイッチオーバの更新中にそれ自体に送信されたスイッチオーバ・パラメータを利用して、送信及び受信スイッチオーバ・パラメータを計算/推定することができる。先に説明したように、スイッチオーバの更新は、例えば213個のパケット毎に1回行われ、スイッチオーバは、2つの連続するスイッチオーバの更新間で必要とされる可能性が最も高いことから、又、スイッチオーバ・パラメータは、送信パケット毎に変更されるので、冗長NMD 102は、パケットをリモートNMD 107に送信するために、冗長NMD 102に送信された最後のスイッチオーバ・パラメータを使用することができない。従って、関連性のない最後のスイッチオーバ・パラメータを使用して(例えば)冗長NMD 102から(例えば)リモートNMD 107にパケットを送信しようと試みても、当該パケットは、冗長NMD 102によって無視され又は破棄されることになる。従って、本開示の幾つかの実施形態によれば、冗長NMD 102は、以下に示すように、最後に知られたスイッチオーバ・パラメータの値を利用して送信スイッチオーバ・パラメータの現在値(又は実際の値)を推定することができる。
1)現在のRTP_Tx_TimeStamp=最後のRTP_Tx_TimeStamp+ΔT
上式で、最後のRTP_Tx_TimeStampは、最後のスイッチオーバの更新中に冗長NMDに送信されたRTP_Tx_TimeStampの値であり、ΔTは、最後の更新時間と、スイッチオーバ時間との間の時間差である。従って、現在のRTP_Tx_TimeStampは、(この例では)冗長NMD 102がそれ自体の送信した最初のパケットに割り当てる初期のタイムスタンプである。
2)現在のRTP_Tx_SEQ=最後のRTP_Tx_SEQ+213+ΔSEQ
上式で、最後のRTP_Tx_SEQは、最後のスイッチオーバの更新中に冗長NMD 102に送信されたRTP_Tx_SEQの値であり、213は、スイッチオーバのパケット更新レートの例示的な数である。(例えば)213の値を追加し、ΔSEQを使用すると、リモートNMD 107において、冗長NMD 102から送信されるパケットと、NMD 101から送信されるが冗長NMD 102において受信される1つ(又は複数)のパケットとの間の衝突が実質的に生じないことを保証する、安全なマージン又はオフセットが、提供される。ΔSEQの例示的な値は、500(パケット)とすることができる。SRTPプロトコルは、最大215個の損失パケットを取り扱い又はそれらに対処するように設計されているので、リモート・ネットワーク・メディア・デバイス(例えばリモートNMD 107)は、かかるオフセット値(213+ΔSEQ)を問題なく取り扱うことができる。
3)現在のRTP_Tx_ROC=最後のRTP_Tx_ROC
上式で、最後のRTP_Tx_ROCは、最後のスイッチオーバの更新中に冗長NMD 102に送信されたRTP_Tx_ROCの値である。213及びΔSEQが最後のRTP_Tx_ROCに追加された後は、その時々に、現在のRTP_Tx_ROCがオーバーフローする(循環又は一巡する)ことを意味する以下の条件(3)が、満足される可能性があり、従って、そのような場合には、リモートNMD(例えばリモートNMD 107)との同期をとるために、現在のRTP_Tx_ROCの値が、1だけ増分される(現在のROC=現在のROC+1となる)ことに留意されたい。
Current RTP_Tx_SEQ < Last RTP_Tx_SEQ (3)
4)現在のRTCP_Tx_Index=最後のRTCP_Tx_Index+ΔT/(Mean_RTCP_Interval)+Δindex
上式で、Mean_RTCP_Intervalは、NMD 101からリモートNMD 107に送信される2つの連続するRTCPパケット間の平均経過時間である。従って、ΔT/(Mean_RTCP_Interval)は、最後のスイッチオーバの更新から実際のスイッチオーバの時点までに送信されたRTCPパケットの平均数を提供する。例えば、最後のスイッチオーバの更新が、時間t0に発生し、その後、実際のスイッチオーバが、300秒後(t0+300秒)に発生する場合は、ΔT=300秒となる。次に、Mean_RTCP_Intervalが、5秒と等しい場合は、そのことをもって、スイッチオーバが発生する前に、NMD 101が、60個(300/5)のRTCPパケットを(リモートNMD 107に)送信したことが示される。RTCP_Tx_Indexの値は、各RTCPパケットの送信に従って単調増加する故に、最後のRTCP_Tx_Indexは、期間ΔTの間に送信されるRTCPパケットの平均数だけ増分される。
先に説明したように、受信メディア・デバイスは、最大215個の損失パケットと、順序が狂った215個のパケットと、を問題なく取り扱うことができる。従って、冗長NMD 102は、推定の必要がある送信スイッチオーバ・パラメータとは対照的に、受信スイッチオーバ・パラメータの現在値を推定する必要がなく、それらの値は、以下のように直接取得され得る。
5)現在のRTP_Rx_SEQ=最後のRTP_Rx_SEQ
上式で、最後のRTP_Rx_SEQは、最後のスイッチオーバの更新中に冗長NMD 102に送信されたRTP_Rx_SEQの値である。
6)現在のRTP_Rx_ROC=最後のRTP_Rx_ROC
上式で、最後のRTP_Rx_ROCは、最後のスイッチオーバの更新中に冗長NMD 102に送信されたRTP_Rx_ROCの値である。
7)現在のRTCP_Rx_Index=最後のRTCP_Rx_Index
上式で、最後のRTCP_Rx_Indexは、最後のスイッチオーバの更新中に冗長NMD 102に送信されたRTCP_Rx_Indexの値である。
PacketCable
PacketCableは、RTPパケットを利用するので、活動状態のNMD(NMD 101等)と、冗長NMD(冗長NMD 102等)との間のスイッチオーバは、SRTPスイッチオーバでパケットのシーケンス番号(SEQ)が使用されるのとは対照的に、PacketCableのスイッチオーバではパケットのタイムスタンプが利用される点と、SRTPで使用されるROCが、PacketCableではNwrapと呼ばれる等価なパラメータに置き換えられる点と、を除けば、SRTP(SRTPスイッチオーバ)と同様の様式で実施され得る。SRTPの場合と同様に、PacketCableも、リプレイ攻撃に対する保護を提供する。
タイムスタンプの許容差チェック(Tolerance Check)
パケットが、NMD 101等のNMDにおいて受信され、当該NMDよって処理される前に、NMDは、各RTPヘッダ内のタイムスタンプ値のサニティ・テストを実施しなければならない。サニティ・テストは、コンピュータ・プログラム又は他の製品の主要な機能に関する簡易なラン・スルーである。サニティ・テストを用いると、より網羅的なテスト・ラウンドに先立って、システムが予期されるとおりに機能することの信頼性がある程度もたらされる。
PacketCableの方法論の一部として、サニティ・テストは、典型的には以下のステップから成る。
1.まず、新しい通信セッションで送信者から受信された最初のパケットにRTPタイムスタンプが割り当てられた後、受信機は、同じ通信セッション内でそれ以前に受信されたパケットに関するタイムスタンプの外挿に基づいて、送信者の次のRTPパケットに関するタイムスタンプの予想値を計算し、
2.当該パケットに関連するタイムスタンプの値が、計算された予想値の合理的な許容差の範囲から外れ、又は当該許容差を超えた場合には、次の受信パケットは、処理されずに拒否される。拒否されたパケットに関連するタイムスタンプは、将来のパケットのタイムスタンプを推定し又は予測する外挿に用いられることはない。「合理的な許容差(reasonable tolerance)」とは、有効なタイムスタンプの値によって、受信機が有効進入パケットを迅速に復元して解読することができなくなる程度まで、受信機の状態を逸脱させる恐れがないことを保証する上で、十分に小さいタイムスタンプの許容差範囲を意味する。更に、タイムスタンプの許容差範囲は、予想されたタイムスタンプの値と、受信されたタイムスタンプの値との間の知られた差が考慮に入られるように選択される必要がある。なぜなら、そのような差は、コール起動時及びコーデックのスイッチオーバ時、並びに、ある条件下では送信者/受信者の非同期化を招く恐れもある送信者/受信者のクロック・ドリフトに起因して生じる可能性があるからである。
比較的長い連続する一連のRTPパケットが、それ自体の値が許容可能な範囲を超えるタイムスタンプを有する場合には、受信メディア・デバイス(例えばNMD 101)は、その通信セッションを終了し又は打ち切ることになる。そうではなく、(正当な)各パケットが受信された場合には、受信メディア・デバイス(例えばNMD 101)は、パケットの送信者(例えばリモートNMD 107)との同期をとることができるように、即ち、推定されるタイムスタンプの許容可能な許容差範囲に収まるように、それ自体の時間の調整又は相対位置変更を行う。
PacketCableのスイッチオーバは、SRTPに関して説明したのと同様の様式で、スイッチオーバの更新を冗長デバイス(例えば冗長NMD 102)に送信するが、以下で説明するように、PacketCableでは、(SRTPで使用される)シーケンス番号及びROC値が、それぞれタイムスタンプ及びNwrapに置き換えられる。SRTPスイッチオーバの場合と同様に、PacketCableのスイッチオーバでも、(この例では3つのタイプの)送信及び受信スイッチオーバ・パラメータを冗長NMDにコピーすることが必要となる。
送信スイッチオーバ・パラメータは、次の3つである。
1)NMDから送信されるパケットのタイムスタンプに相当する、RTP_Tx_TimeStampと、
2)NMDから送信されるパケットに関連するNwrapに相当する、RTP_Tx_Nwrapと、
3)NMDから送信されるパケットのシーケンス番号に相当する、RTCP_Tx_SequenceNumber。
受信スイッチオーバ・パラメータは、次の3つである。
4)NMDにおいて受信されるパケットのタイムスタンプに相当する、RTP_Rx_TimeStampと、
5)NMDにおいて受信されるパケットに関連するNwrapに相当する、RTP_Rx_Nwrapと、
6)NMDにおいて受信されるパケットのシーケンス番号に相当する、RTCP_Rx_SequenceNumber。
SRTPスイッチオーバの場合と同様に、又それと同じ理由で、透過的なスイッチオーバ・パラメータを取得するために、現在のRTP_Tx_TimeStampと、現在のRTP_Tx_Nwrapと、現在のRTCP_Tx_SequenceNumberの、合計3つの送信スイッチオーバ・パラメータの値が、冗長NMDによって推定される必要がある。従って、(例えば)冗長NMD 102は、最後に知られたスイッチオーバ・パラメータの値を利用して、送信スイッチオーバ・パラメータの現在値(又は実際の値)を次のように推定することができる。
1)現在のRTP_Tx_TimeStamp=最後のRTP_Tx_TimeStamp+ΔT
上式で、最後のRTP_Tx_TimeStampは、最後のスイッチオーバの更新中に冗長NMDに送信されたRTP_Tx_TimeStampの値であり、ΔTは、最後の更新時間と、スイッチオーバ時間との間の時間差である。従って、現在のRTP_Tx_TimeStampは、(この例では)冗長NMD 102から送信された最初のパケットに割り当てられる初期のタイムスタンプとなる。
2)現在のRTP_Tx_Nwrap=最後のRTP_Tx_Nwrap
上式で、最後のRTP_Tx_Nwrapは、最後のスイッチオーバの更新中に冗長NMDに送信されたRTP_Tx_Nwrapの値である。現在のRTP_Tx_TimeStampが循環することを意味する以下の条件(4)が、その時々に満足される可能性があり、従って、そのような場合には、リモートNMD(例えばリモートNMD 107)との同期を維持するために、Nwrapの値が、1だけ増分される(Nwrap=Nwrap+1となる)ことに留意されたい。
現在のRTP_Tx_TimeStamp<最後のRTP_Tx_TimeStamp (4)
3)現在のRTCP_Tx_SequenceNumber=最後のRTCP_Tx_SequenceNumber+ΔT/(Mean_RTCP_Interval)+ΔSEQ
上式で、Mean_RTCP_Intervalは、(例えば)NMD 101から(例えば)リモートNMD 107に送信される2つの連続するRTCPパケット間の平均経過時間である。従って、式ΔT/(Mean_RTCP_Interval)は、最後のスイッチオーバの更新から実際のスイッチオーバの時点までに送信されたRTCPパケットの平均数を提供する。例えば、最後のスイッチオーバの更新が、時間t0に発生し、その後、別のスイッチオーバが、300秒後の時間t1(t1=t0+300秒)に発生する場合は、ΔT=300秒となる。次に、Mean_RTCP_Intervalが、5秒と等しい場合は、そのことをもって、スイッチオーバが発生する前に、NMD 101が、60個(300/5)のRTCPパケットを(リモートNMD 107に)送信したことが示される。RTCP_Tx_SequenceNumberの値は、各RTCPパケットの送信に従って単調増加する故に、最後のRTCP_Tx_SequenceNumberは、期間ΔTの間に送信されるRTCPパケットの平均数だけ増分される。
SRTPスイッチオーバに関して先に指定された理由から、受信スイッチオーバ・パラメータの現在値が、以下のように直接取得され得るので、冗長NMD 102等の冗長NMDは、受信スイッチオーバ・パラメータの現在値を推定する必要がない。
4)現在のRTP_Rx_TimeStamp=最後のRTP_Rx_TimeStampとなり、
5)現在のRTP_Rx_Nwrap=最後のRTP_Rx_Nwrapとなり、
6)現在のRTCP_Rx_SequenceNumber=最後のRTCP_Rx_SequenceNumberとなる。
言い換えれば、現在のRTP_Rx_TimeStamp、現在のRTP_Rx_Nwrap、及び現在のRTCP_Rx_SequenceNumberには、(それぞれ)最後のスイッチオーバの更新中に冗長NMDが取得した(冗長NMDにコピーされた)最後のRTP_Rx_TimeStamp、最後のRTP_Rx_Nwrap、及び最後のRTCP_Rx_SequenceNumberが割り当てられる。
次に、図2を参照すると、(全体的に200で示される)例示的な「N+1」冗長レンダリング・システムの全体的なレイアウト及び機能が、概略的に示される。この例によれば、システム200は、図1のNMD 101とほぼ同様の働きをする、201/1、201/2、201/3、及び201/4で指定された複数の1次ネットワーク・メディア・デバイスを含むことから、あるネットワーク・メディア・デバイス、例えばNMD 201/1が故障する恐れもある故に、図1の通信経路103を介して行われる直接的なスイッチオーバの更新のような直接的なスイッチオーバの更新は、推奨されない。(例えば)NMD 201/1が故障した結果、冗長NMD 202等の2次NMDへのスイッチオーバが、必要とされることもある。しかしながら、当該スイッチオーバの間に別のネットワーク・メディア・デバイス、例えばNMD 201/4が、冗長NMD 202を更新しようと試みる可能性もあり、それによってスイッチオーバ・プロセスが妨げられることになる。従って、NMDと、冗長NMDとの間の直接的な通信経路(図1の103で示される直接的な通信経路等)を使用する代わりに、中央ネットワーク・デバイス205等の中央デバイスが、使用される。NMD 201/1〜201/4の各NMDは、それぞれ(204で示されるように)スイッチオーバ・パラメータを用いて中央ネットワーク・デバイス205を更新することができる。更新レートは、1つのネットワーク・メディア・デバイスに使用される更新レートと同様(即ち、2個のパケットの送信又は受信の都度)であってよい。ネットワーク・デバイス205は、(204で示されるように)それ自体と結合された各NMDから転送されてきた最後のスイッチオーバ・パラメータをメモリ・ストレージ・アレイ211に記憶することができる。NMD 201/1〜201/4の内の1つが、(データ・ネットワーク208を介して)リモートNMD 207にサービスを提供することができなくなった場合は、中央ネットワーク・デバイス205は、NMD 201/1〜201/4を監視することによって故障中のNMDを特定することができ、又、(206で示されるように)故障中のNMDに関する又はそれと関連付けられるスイッチオーバ・パラメータだけを冗長NMD 202に転送することができる。冗長NMD 202は、中央ネットワーク・デバイス205からそれ自体に転送されたスイッチオーバ・パラメータを使用することにより故障中のNMDを置き換え、通信経路210及びデータ・ネットワーク208を介してリモートNMD 207と通信することができる。
幾つかの実施形態によれば、中央ネットワーク・デバイス205は、NMD 201/1〜201/4に関連するスイッチオーバ・パラメータを、メモリ・ストレージ・アレイ211等の中央メモリ・ストレージ・アレイに記憶することができる。これらの実施形態によれば、中央ネットワーク・デバイス205は、故障中のNMDを特定するときに、メモリ・ストレージ・アレイ211内の位置を探索し、そこから故障中のNMDに関連するスイッチオーバ・パラメータだけを収集し、それらのパラメータを冗長NMDに送信することができる。別法として、中央ネットワーク・デバイス205は、別個のNMDに関連するスイッチオーバ・パラメータを別個のメモリ・ストレージ・アレイに記憶することもできる。
次に、図3を参照すると、流れ図は、RTPスイッチオーバの更新がいつ発生することになるかを判定する例示的な方法を示す。図3は、図1に関連して説明される。ここでは、先のスイッチオーバの更新が暫く前に既に発生しており、後続の即ち次のスイッチオーバの更新時の判定が必要とされることが、想定される。(1)NOP(例えばNMD 101からリモートNMD 107に送信されるパケット数(Number Of Packets))と、(2)NOP(例えばリモートNMD 107から送信され、例えばNMD 101において受信されるパケット数(Number Of Packets))の、合わせて2つの変数が使用され得る。送信パケット及び受信パケットの数は、各パケットに一意のシーケンス番号が割り当てられることから、パケットのシーケンス番号(SEQ)を使用することによって取得され得る。
NOP及びNOPは、先のスイッチオーバの更新が発生した時点で又はその直後に、それぞれの値をゼロにセットすること等によって初期化される(ステップ301)。先のスイッチオーバの更新が完了したかどうかに関わらず、アプリケーションは、通常どおり実行され得、即ち、(例えば)NMD 101は、例えばリモートNMD 107との間のパケットの送受信を継続することができる。最後の(先の)スイッチオーバの更新以降に(例えば)NMD 101から送信されたパケットをカウントするために、(例えば)NMD 101が、(例えば)リモートNMD 107にパケットを送信する度に、変数NOPが、1だけ増分される(303)。最後の増分以降に、NMD 101が追加的なパケットを送信しない限り(302のNo)、NOPの値は、変更されないままである。同様に、最後の(先の)スイッチオーバの更新以降に(例えば)NMD 101において受信されたパケットをカウントするために、NMD 101が、(例えば)リモートNMD 107からパケットを受信する度に(304のYes)、変数NOPが、1だけ増分される(305)。
本開示の幾つかの実施形態によれば、NOP又はNOPの値が、2つの連続するスイッチオーバの更新間に通信することが許可されたパケットの所定の最大数である2(例えばX=13)に達した場合には(306のYes)、別のスイッチオーバの更新が、発生し(307)、変数NOP及びNOPが、初期化される(301)。変数NOPとNOPの何れの変数も、2の値に達する基準を満たさない場合には(306のNo)、アプリケーションは、通常どおり実行され得、即ち、(例えば)NMD 101は、(例えば)リモートNMD 107との間のパケットの送受信を継続することができ、これにより、NOP及びNOPが、送信パケット及び受信パケットの数に従って増分されることになる。図3の流れ図は、図2に示される例示的な「1+N」システム(この例ではN=4)等、任意の「1+N」システム・アーキテクチャにも同様に適用され得る。再び図2を参照すると、メモリ・ストレージ・アレイ211は、(図3の307に示されるように)各NMD 201/i(この例では、i=1〜4)によって個別に更新される。
図3の流れ図は、SRTPのスイッチオーバと、PacketCableのスイッチオーバとが、様々なタイプのスイッチオーバ・パラメータを冗長NMDにコピーすることを要するにも関わらず、SRTPとPacketCableの何れのスイッチオーバにおいても使用され得る。非安全データ通信が関与する場合にも、図1のメモリ・ストレージ・アレイ111及び図2のメモリ・ストレージ・アレイ211は、(所定の数(2個)の送信/受信パケット毎にではなく)通信セッション毎に1回更新され得る。
以上、本明細書では本開示の幾つかの特徴を図示し説明してきたが、当業者なら様々な修正形態、置換物、変更形態、及び等価物に想到することであろう。従って、添付の特許請求の範囲は、本開示の真の趣旨から逸脱しない全ての修正形態及び変更形態を包含するものであることが、理解されるであろう。
典型的な冗長システムの全体的なレイアウト及び機能を示す概略図である。 典型的な「1+N」冗長システムの全体的なレイアウト及び機能を示す概略図である。 SRTPスイッチオーバの更新がいつ発生することになるかを判定する例示的な方法を示す流れ図である。
符号の説明
100 冗長システム
101 ネットワーク・メディア・デバイス
102 冗長ネットワーク・メディア・デバイス
105 中央ネットワーク・デバイス(任意選択)
107 リモートのネットワーク・メディア・デバイス
108 IP
111 メモリ・ストレージ・アレイ
201/1〜4 ネットワーク・メディア・デバイス
202 冗長ネットワーク・メディア・デバイス
205 中央ネットワーク・デバイス
207 リモートのネットワーク・メディア・デバイス
211 メモリ・ストレージ・アレイ

Claims (48)

  1. 通信方法であって、
    1次ネットワーク・メディア・デバイスと、冗長ネットワーク・メディア・デバイスである2次ネットワーク・メディア・デバイスと、をほぼ同様の暗号化状態に維持するステップを含む方法。
  2. 請求項1に記載の方法であって、前記維持するステップは、
    前記1次ネットワーク・メディア・デバイスから前記冗長ネットワーク・メディア・デバイスに、受信スイッチオーバ・パラメータと、送信スイッチオーバ・パラメータと、をコピーするステップを含む、方法。
  3. 請求項2に記載の方法であって、前記コピーするステップは、2個のパケットが、前記1次ネットワーク・メディア・デバイスから送信される度に、又は前記1次ネットワーク・メディア・デバイスにおいて受信される度に少なくとも1回発生する、方法。
  4. 請求項3に記載の方法であって、X=13である、方法。
  5. 請求項2に記載の方法であって、前記冗長ネットワーク・メディア・デバイスは、コピーされた受信スイッチオーバ・パラメータを利用することによってパケットを受信する、方法。
  6. 請求項2に記載の方法であって、前記冗長ネットワーク・メディア・デバイスは、現在の送信スイッチオーバ・パラメータを推定することによってパケットを送信する、方法。
  7. 請求項6に記載の方法であって、前記現在の送信スイッチオーバ・パラメータは、コピーされた送信スイッチオーバ・パラメータに基づいて推定される、方法。
  8. 請求項2に記載の方法であって、前記各スイッチオーバ・パラメータは、セキュア・リアル・タイム・トランスポート・プロトコルに関連する、方法。
  9. 請求項2に記載の方法であって、前記受信及び送信スイッチオーバ・パラメータは、PacketCableプロトコルに関連する、方法。
  10. 請求項2に記載の方法であって、スイッチオーバ・パラメータは、パケットのタイムスタンプと、パケットのシーケンス番号と、ロールオーバ・カウンタと、RTCPインデックスと、の内の1つ又は複数を含む、方法。
  11. 請求項2に記載の方法であって、スイッチオーバ・パラメータは、パケットのタイムスタンプと、Nwrapと、RTCPシーケンス番号と、の内の1つ又は複数を含む、方法。
  12. 請求項1に記載の方法であって、前記冗長ネットワーク・メディア・デバイスは、幾つかの1次ネットワーク・メディア・デバイスをバックアップする、方法。
  13. 請求項12に記載の方法であって、スイッチオーバ・パラメータは、ネットワーク・メディア・デバイスから中央ネットワーク・デバイスにコピーされ、故障中の1次ネットワーク・メディア・デバイスに関連するスイッチオーバ・パラメータは、前記中央ネットワーク・デバイスから前記冗長ネットワーク・メディア・デバイスにコピーされる、方法。
  14. 通信システムであって、
    1次ネットワーク・メディア・デバイスと、
    冗長ネットワーク・メディア・デバイスである2次ネットワーク・メディア・デバイスと、
    を備え、
    前記1次及び2次ネットワーク・メディア・デバイスは、ほぼ同様の暗号化状態に維持される、
    通信システム。
  15. 請求項14に記載の通信システムであって、前記維持は、
    前記1次ネットワーク・メディア・デバイスから前記冗長ネットワーク・メディア・デバイスに、受信スイッチオーバ・パラメータと、送信スイッチオーバ・パラメータと、をコピーすることを含む、
    通信システム。
  16. 請求項15に記載の通信システムであって、前記コピーは、2個のパケットが、前記1次ネットワーク・メディア・デバイスから送信される度に、又は前記1次ネットワーク・メディア・デバイスにおいて受信される度に1回発生する、通信システム。
  17. 請求項16に記載の通信システムであって、X=13である、通信システム。
  18. 請求項15に記載の通信システムであって、前記冗長ネットワーク・メディア・デバイスは、コピーされた受信スイッチオーバ・パラメータを利用することによってパケットを受信し、現在の送信スイッチオーバ・パラメータを推定することによってパケットを送信する、通信システム。
  19. 請求項18に記載の通信システムであって、前記冗長ネットワーク・メディア・デバイスは、コピーされた送信スイッチオーバ・パラメータに基づいて前記現在の送信スイッチオーバ・パラメータを推定する、通信システム。
  20. 請求項15に記載の通信システムであって、前記受信及び送信スイッチオーバ・パラメータは、セキュア・リアル・タイム・トランスポート・プロトコルに関連する、通信システム。
  21. 請求項15に記載の通信システムであって、前記受信及び送信スイッチオーバ・パラメータは、PacketCableプロトコルに関連する、通信システム。
  22. 請求項15に記載の通信システムであって、スイッチオーバ・パラメータは、パケットのタイムスタンプと、パケットのシーケンス番号と、ロールオーバ・カウンタと、RTCPインデックスと、の内の1つ又は複数を含む、通信システム。
  23. 請求項15に記載の通信システムであって、スイッチオーバ・パラメータは、パケットのタイムスタンプと、Nwrapと、RTCPシーケンス番号と、の内の1つ又は複数を含む、通信システム。
  24. 請求項14に記載の通信システムであって、前記冗長ネットワーク・メディア・デバイスは、幾つかの1次ネットワーク・メディア・デバイスをバックアップする、通信システム。
  25. 請求項24に記載の通信システムであって、各1次ネットワーク・メディア・デバイスからそれに対してスイッチオーバ・パラメータがコピーされる中央ネットワーク・デバイスを更に備え、前記中央ネットワーク・デバイスは、故障中の1次ネットワーク・メディア・デバイスに関連するスイッチオーバ・パラメータを前記冗長ネットワーク・メディア・デバイスにコピーするように適合される、通信システム。
  26. 請求項25に記載の通信システムであって、前記中央ネットワーク・デバイスは、前記各1次ネットワーク・メディア・デバイスに関連するスイッチオーバ・パラメータを記憶するためのストレージ・アレイを備える、通信システム。
  27. 冗長ネットワーク・メディア・デバイスとして使用される2次ネットワーク・メディア・デバイスをほぼ同様の暗号化状態に維持するように適合された1次ネットワーク・メディア・デバイス。
  28. 請求項27に記載の1次ネットワーク・メディア・デバイスであって、前記冗長ネットワーク・メディア・デバイスに受信スイッチオーバ・パラメータと、送信スイッチオーバ・パラメータと、をコピーすることによって、前記冗長ネットワーク・メディア・デバイスをほぼ同様の暗号化状態に維持する1次ネットワーク・メディア・デバイス。
  29. 請求項28に記載の1次ネットワーク・メディア・デバイスであって、前記コピーは、2個のパケットが、前記1次ネットワーク・メディア・デバイスから送信される度に、又は前記1次ネットワーク・メディア・デバイスにおいて受信される度に1回発生する、1次ネットワーク・メディア・デバイス。
  30. 請求項29に記載の1次ネットワーク・メディア・デバイスであって、X=13である、1次ネットワーク・メディア・デバイス。
  31. 請求項28に記載の1次ネットワーク・メディア・デバイスであって、前記受信及び送信スイッチオーバ・パラメータは、セキュア・リアル・タイム・トランスポート・プロトコルに関連する、1次ネットワーク・メディア・デバイス。
  32. 請求項28に記載の1次ネットワーク・メディア・デバイスであって、前記受信及び送信スイッチオーバ・パラメータは、PacketCableプロトコルに関連する、1次ネットワーク・メディア・デバイス。
  33. 請求項28に記載の1次ネットワーク・メディア・デバイスであって、スイッチオーバ・パラメータは、パケットのタイムスタンプと、パケットのシーケンス番号と、ロールオーバ・カウンタと、RTCPインデックスと、の内の1つ又は複数を含む、1次ネットワーク・メディア・デバイス。
  34. 請求項28に記載の1次ネットワーク・メディア・デバイスであって、スイッチオーバ・パラメータは、パケットのタイムスタンプと、Nwrapと、RTCPシーケンス番号と、の内の1つ又は複数を含む、1次ネットワーク・メディア・デバイス。
  35. 請求項27に記載の1次ネットワーク・メディア・デバイスであって、前記1次ネットワーク・メディア・デバイスがそれに対してスイッチオーバ・パラメータをコピーする中央ネットワーク・デバイスを更に備え、前記中央ネットワーク・デバイスは、前記1次ネットワーク・メディア・デバイスが、サービスを提供することができなくなった場合に、前記スイッチオーバ・パラメータを前記冗長ネットワーク・メディア・デバイスにコピーするように適合される、1次ネットワーク・メディア・デバイス。
  36. 1次ネットワーク・メディア・デバイスとほぼ同様の暗号化状態に維持されるように適合された冗長ネットワーク・メディア・デバイス。
  37. 請求項36に記載の冗長ネットワーク・メディア・デバイスであって、前記維持は、
    前記1次ネットワーク・メディア・デバイスから前記冗長ネットワーク・メディア・デバイスに、受信スイッチオーバ・パラメータと、送信スイッチオーバ・パラメータと、をコピーすることを含む、
    冗長ネットワーク・メディア・デバイス。
  38. 請求項36に記載の冗長ネットワーク・メディア・デバイスであって、前記コピーは、2個のパケットが、前記1次ネットワーク・メディア・デバイスから送信される度に、又は前記1次ネットワーク・メディア・デバイスにおいて受信される度に1回発生する、冗長ネットワーク・メディア・デバイス。
  39. 請求項37に記載の冗長ネットワーク・メディア・デバイスであって、X=13である、冗長ネットワーク・メディア・デバイス。
  40. 請求項37に記載の冗長ネットワーク・メディア・デバイスであって、コピーされた受信スイッチオーバ・パラメータを利用することによってパケットを受信する冗長ネットワーク・メディア・デバイス。
  41. 請求項37に記載の冗長ネットワーク・メディア・デバイスであって、現在の送信スイッチオーバ・パラメータを推定することによってパケットを送信する冗長ネットワーク・メディア・デバイス。
  42. 請求項37に記載の冗長ネットワーク・メディア・デバイスであって、コピーされた送信スイッチオーバ・パラメータに基づいて前記現在の送信スイッチオーバ・パラメータを推定する冗長ネットワーク・メディア・デバイス。
  43. 請求項37に記載の冗長ネットワーク・メディア・デバイスであって、前記受信及び送信スイッチオーバ・パラメータは、セキュア・リアル・タイム・トランスポート・プロトコルに関連する、冗長ネットワーク・メディア・デバイス。
  44. 請求項37に記載の冗長ネットワーク・メディア・デバイスであって、前記受信及び送信スイッチオーバ・パラメータは、PacketCableプロトコルに関連する、冗長ネットワーク・メディア・デバイス。
  45. 請求項37に記載の冗長ネットワーク・メディア・デバイスであって、スイッチオーバ・パラメータは、パケットのタイムスタンプと、パケットのシーケンス番号と、ロールオーバ・カウンタと、RTCPインデックスと、の内の1つ又は複数を含む、冗長ネットワーク・メディア・デバイス。
  46. 請求項37に記載の冗長ネットワーク・メディア・デバイスであって、スイッチオーバ・パラメータは、パケットのタイムスタンプと、Nwrapと、RTCPシーケンス番号と、の内の1つ又は複数を含む、冗長ネットワーク・メディア・デバイス。
  47. 請求項37に記載の冗長ネットワーク・メディア・デバイスであって、幾つかの1次ネットワーク・メディア・デバイスをバックアップするように適合された冗長ネットワーク・メディア・デバイス。
  48. 請求項47に記載の冗長ネットワーク・メディア・デバイスであって、1次ネットワーク・メディア・デバイスからそれに対してスイッチオーバ・パラメータがコピーされる中央ネットワーク・デバイスを更に備え、前記中央ネットワーク・デバイスは、故障中の1次ネットワーク・メディア・デバイスに関連するスイッチオーバ・パラメータを前記冗長ネットワーク・メディア・デバイスにコピーするように適合される、冗長ネットワーク・メディア・デバイス。
JP2007123041A 2006-05-08 2007-05-08 保護されたメディア・デバイス間の切換え Pending JP2007306562A (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/429,931 US7944814B2 (en) 2006-05-08 2006-05-08 Switching between secured media devices

Publications (1)

Publication Number Publication Date
JP2007306562A true JP2007306562A (ja) 2007-11-22

Family

ID=38434418

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007123041A Pending JP2007306562A (ja) 2006-05-08 2007-05-08 保護されたメディア・デバイス間の切換え

Country Status (5)

Country Link
US (1) US7944814B2 (ja)
EP (1) EP1855447A1 (ja)
JP (1) JP2007306562A (ja)
KR (1) KR20070108825A (ja)
CN (1) CN101114942A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8693313B2 (en) 2009-12-01 2014-04-08 Fujitsu Limited Apparatus and method for switching between redundant communication devices

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101132347A (zh) * 2006-08-24 2008-02-27 华为技术有限公司 一种实现tcp连接备份的系统及方法
KR20080082830A (ko) * 2007-03-09 2008-09-12 삼성전자주식회사 스패닝 트리 프로토콜을 이용하는 네트워크에서 스위칭장치의 플러싱 처리 장치 및 방법
US8705348B2 (en) * 2007-04-18 2014-04-22 Cisco Technology, Inc. Use of metadata for time based anti-replay
FI120284B (fi) * 2007-07-20 2009-08-31 Tellabs Oy Huojuntapuskurin täyttöasteen säätö
US7778166B2 (en) * 2007-11-28 2010-08-17 Intel Corporation Synchronizing sequence numbers among peers in a network
US8788079B2 (en) 2010-11-09 2014-07-22 Vmware, Inc. Monitoring audio fidelity and audio-video synchronization
US9214004B2 (en) 2008-12-18 2015-12-15 Vmware, Inc. Watermarking and scalability techniques for a virtual desktop planning tool
US9674562B1 (en) * 2008-12-18 2017-06-06 Vmware, Inc. Quality evaluation of multimedia delivery in cloud environments
CN101714916B (zh) * 2009-11-26 2013-06-05 华为数字技术(成都)有限公司 一种备份方法、设备和系统
EP2367309B1 (en) 2010-02-10 2016-07-13 Alcatel Lucent Method for detecting a synchronization failure of a transparent clock and related protection schemes
US8656170B2 (en) * 2010-05-28 2014-02-18 Cisco Technology, Inc. Protection of control plane traffic against replayed and delayed packet attack
DE102012208836A1 (de) * 2012-05-25 2013-11-28 Siemens Aktiengesellschaft Verfahren und Vorrichtung zur Erzeugung kryptographisch geschützter redundanter Datenpakete
US8831001B2 (en) * 2012-06-24 2014-09-09 Audiocodes Ltd. Device, system, and method of voice-over-IP communication
CN102891850A (zh) * 2012-09-25 2013-01-23 汉柏科技有限公司 IPSec隧道更新防重放参数的方法
CN103414637B (zh) * 2013-07-29 2016-03-30 北京华为数字技术有限公司 一种流量转发的方法及相关装置
US9288810B2 (en) * 2013-12-05 2016-03-15 Qualcomm Incorporated Wireless media sharing from multiple sources to a single sink
US9961054B2 (en) * 2014-01-29 2018-05-01 Honeywell International Inc. Apparatus and method for establishing secure communication with redundant device after switchover
US9729574B2 (en) * 2014-02-14 2017-08-08 Alcatel Lucent Seamless switchover for anti-replay connections in multiple network processor systems
US9600432B2 (en) * 2014-04-17 2017-03-21 International Business Machines Corporation Verifying runtime switch-over between multiple I/O protocols on shared I/O connection
US9722976B1 (en) * 2015-02-26 2017-08-01 Sonus Networks, Inc. Methods and apparatus for synchronizing decryption state with remote encryption state
US20160323792A1 (en) * 2015-04-29 2016-11-03 Aruba Networks, Inc. Wireless client session continuity across controller failover and load-balancing
CN112929324B (zh) * 2019-12-06 2023-02-21 中兴通讯股份有限公司 一种加密与非加密的切换方法、装置、设备及存储介质
CN112492340B (zh) * 2020-11-27 2023-08-11 努比亚技术有限公司 直播音频采集方法、移动终端及计算机可读存储介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6966003B1 (en) 2001-01-12 2005-11-15 3Com Corporation System and method for switching security associations
US7305450B2 (en) 2001-03-29 2007-12-04 Nokia Corporation Method and apparatus for clustered SSL accelerator
US20050102497A1 (en) * 2002-12-05 2005-05-12 Buer Mark L. Security processor mirroring
US7529898B2 (en) * 2004-07-09 2009-05-05 International Business Machines Corporation Method for backing up and restoring data

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8693313B2 (en) 2009-12-01 2014-04-08 Fujitsu Limited Apparatus and method for switching between redundant communication devices

Also Published As

Publication number Publication date
US7944814B2 (en) 2011-05-17
EP1855447A1 (en) 2007-11-14
CN101114942A (zh) 2008-01-30
KR20070108825A (ko) 2007-11-13
US20070260870A1 (en) 2007-11-08

Similar Documents

Publication Publication Date Title
JP2007306562A (ja) 保護されたメディア・デバイス間の切換え
US10432590B2 (en) Establishing a communication event using secure signalling
Langley et al. The quic transport protocol: Design and internet-scale deployment
US10855654B2 (en) Session identifier for a communication session
US10893076B2 (en) Data compression for communications signalling
US9900291B2 (en) Methods and apparatus for synchronizing decryption state with remote encryption state
Schulzrinne et al. RTP: A transport protocol for real-time applications
Fairhurst et al. Services provided by IETF transport protocols and congestion control mechanisms
JP4734244B2 (ja) 無線ローカルエリアネットワークのための鍵同期メカニズム
Frederick et al. Rtp: A transport protocol for real-time applications
US10362069B2 (en) Protocol fallback
EP1746801A2 (en) Transmission of packet data over a network with a security protocol
US8228898B2 (en) Method and system for distributed call recording
EP2521335B1 (en) Synchronizing sequence numbers
CA2571891A1 (en) Device authentication and secure channel management for peer-to-peer initiated communications
KR20040026315A (ko) 실시간 전송 프로토콜 패킷의 부분 암호화 방법
JP2004328563A (ja) 暗号通信装置および暗号通信システム
KR101410510B1 (ko) Sctp를 이용한 데이터 전송 방법 및 장치
Klaue et al. On the impact of ipsec on interactive communications
Grozev et al. PERC double media encryption for WebRTC 1.0 sender simulcast
JP2007201973A (ja) データ送受信システム、暗号化情報共有方法、データ送信装置、及びデータ受信装置
JPH11220495A (ja) 暗号通信装置
Clayton et al. Integrating Secure RTP into the Open Source VoIP PBX Asterisk.
Nowlan Unordered Delivery in TLS-Encrypted TCP Connections
JP2009065625A (ja) 暗号化データ通信方法と暗号化データ通信システム