JP5802829B2 - 障害表示状態を判定する方法、ノード、及びシステム - Google Patents

障害表示状態を判定する方法、ノード、及びシステム Download PDF

Info

Publication number
JP5802829B2
JP5802829B2 JP2014513022A JP2014513022A JP5802829B2 JP 5802829 B2 JP5802829 B2 JP 5802829B2 JP 2014513022 A JP2014513022 A JP 2014513022A JP 2014513022 A JP2014513022 A JP 2014513022A JP 5802829 B2 JP5802829 B2 JP 5802829B2
Authority
JP
Japan
Prior art keywords
service
service node
node
state
failure
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.)
Active
Application number
JP2014513022A
Other languages
English (en)
Other versions
JP2014522593A (ja
Inventor
智▲勇▼ 朱
智▲勇▼ 朱
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co 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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2014522593A publication Critical patent/JP2014522593A/ja
Application granted granted Critical
Publication of JP5802829B2 publication Critical patent/JP5802829B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/008—Reliability or availability analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • Environmental & Geological Engineering (AREA)
  • Mathematical Physics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Description

本発明は、通信の分野に関し、特に、障害表示状態を判定する方法、ノード、及びシステムに関する。
通信ネットワークでは、ネットワーク通信の信頼性を向上させるか、又はネットワーク・ノードの処理性能を増大させるために、通常、複数の通信ノードが通信経路上の同じレベルにおけるネットワーク・プレーン上で配置される。通信ノードのうちの１つに障害が生じた後、同じレベルにおける他の通信ノードのフェイルオーバ挙動及びネットワーク・リソース・プリエンプション挙動がトリガされる。したがって、通信ノード障害をどのようにして検出するかが、解決すべき重要な課題となる。
ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ、汎用パケット無線サービス）又はＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ、ユニバーサル移動通信システム）では、ピアＧＧＳＮの障害状態が、ＧＧＳＮ（Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ、ゲートウェイＧＰＲＳサポート・ノード）間のハロー・メッセージによって検出される。特定された持続時間内に応答パケットが受信されなかった場合、ピアＧＧＳＮに障害が生じたと送信側ＧＧＳＮは判断し、それにより、サービス・スイッチオーバ及びネットワーク・リソース・プリエンプション挙動がトリガされる。
本発明を実現する処理では、本発明者は、従来技術が少なくとも以下の課題を有していると理解する。すなわち、
既存の障害検出手法によれば、２つのＧＧＳＮ間の通信リンクが遮断された場合、２つのＧＧＳＮは何れも、ピア端に障害が生じたと判断する。しかし、実際には、２つのＧＧＳＮは何れも、正常であり得る。したがって、既存の障害検出手法では誤判断が存在し得る。
障害検出の信頼性を向上させるために、本発明の実施例は、障害表示状態を判定する方法、ノード、及びシステムを提供する。技術的解決策は以下の通りである。
障害表示状態を判定する方法は、
サービス・ノード・プールにおけるサービス・ノードそれぞれが障害状態にあるか否かについて、サービス要求ノードにより送信された検出の結果を受信する工程と、
検出の結果に応じて、サービス・ノード自体の障害表示状態、及び上記サービス・ノード自体以外の他のサービス・ノ―ドの障害表示状態を判定する工程とを含む。
障害表示状態を判定する方法は、
エコー要求メッセージを拡張する工程であって、エコー要求メッセージは、サービス・ノード・プールにおけるサービス・ノードそれぞれが、現在の期間の先行期間内に障害状態にあるか否かの検出の結果を有している工程と、
検出の結果に応じて、サービス・ノード自体の障害表示状態、及び上記サービス・ノード自体以外の他のサービス・ノードの障害表示状態をサービス・ノードそれぞれが判定することを可能にするよう、現在の期間の最初にサービス・ノード・プールにおけるサ―ビス・ノードそれぞれに向けてエコー要求メッセージを送信する工程とを含む。
サービス・ノードは、
サービス・ノード・プールにおけるサービス・ノードそれぞれが障害状態にあるか否かについて、サービス要求ノードにより送信された検出の結果を受信するよう構成された受信器と、
検出の結果に応じて、サービス・ノード自体の障害表示状態、及び上記サービス・ノード自体以外の他のサービス・ノ―ドの障害表示状態を判定するよう構成された判定器とを備える。
サービス要求ノードは、
エコー要求メッセージを拡張するよう構成された拡張器であって、エコー要求メッセージは、サービス・ノード・プールにおけるサービス・ノードそれぞれが、現在の期間の先行期間内に障害状態にあるか否かの検出の結果を有している拡張器と、
検出の結果に応じて、サービス・ノード自体の障害表示状態、及び上記サービス・ノード自体以外の他のサービス・ノードの障害表示状態をサービス・ノードそれぞれが判定することを可能にするよう、現在の期間の最初にサービス・ノード・プールにおけるサ―ビス・ノードそれぞれに向けてエコー要求メッセージを送信するよう構成された送信器とを備える。
障害表示状態を判定するシステムは、サービス・ノード・プールにおけるサービス・ノード及びサービス要求ノードを含み、
サービス要求ノードは拡張器及び送信器を含み、
拡張器は、エコー要求メッセージを拡張するよう構成され、エコー要求メッセージは、サービス・ノード・プールにおけるサービス・ノードそれぞれが、現在の期間の先行期間内に障害状態にあるか否かの、サービス要求ノード自体による検出の結果を有し、
送信器は、検出の結果に応じて、サービス・ノード自体の障害表示状態、及び上記サービス・ノード自体以外の他のサービス・ノードの障害表示状態をサービス・ノードそれぞれが判定することを可能にするよう、現在の期間の最初にサービス・ノード・プールにおけるサ―ビス・ノードそれぞれに向けてエコー要求メッセージを送信するよう構成され、
サービス・ノードそれぞれは、受信器及び判定器を含み、
受信器は、サービス要求ノードによって送信されたエコー要求メッセージを受信するよう構成され、エコー要求メッセージは、サービス・ノード・プールにおけるサービス・ノードそれぞれに、現在の期間の先行期間中に障害が生じたか否かの検出の結果を有し、
判定器は、検出の結果に応じ、サービス・ノード自体の障害表示状態、及び上記サービス・ノード自体以外の他のサービス・ノ―ドの障害表示状態を判定するよう構成される。
本発明の実施例によって提供される技術的解決策は、以下の効果を有する。すなわち、サービス要求ノードは、サービス・ノードに障害が生じているかを検出し、サービス・ノード自体及び他のサービス・ノードの障害表示状態は、サービス・ノードのサービス要求ノードの検出の結果に応じて判定され、それにより、サービス・ノード障害検出の信頼性が向上する。
本発明の実施例によるＮ×Ｍ相互接続ネットワーク・アーキテクチャを示す概略図である。 本発明の実施例１による、障害表示状態を判定する方法を示すフローチャートである。 本発明の実施例１による、障害表示状態を判定する方法を示すフローチャートである。 本発明の実施例２による、障害表示状態を判定する方法を示すフローチャートである。 本発明の実施例２による、障害表示状態の判定を示す概略フローチャートである。 本発明の実施例２による、挙動トリガ及び挙動時系列制御を示す概略図である。 本発明の実施例３による、サービス・ノードを示す概略構成図である。 本発明の実施例４による、サービス要求ノードを示す概略構成図である。 本発明の実施例５による、障害表示状態を判定するシステムを示す概略構成図である。
本発明の目的、技術的解決策、及び効果を明確にするために、以下では、更に、添付図面を参照して、本発明の実施形態を詳細に説明する。
本発明の実施例によって提供される技術的解決策は、Ｎ個のサービス要求ノード及びＭ個のサービス・ノードを含むＮ×Ｍ相互接続ネットワーク・アーキテクチャに適用し、Ｎは１以上であり、Ｍは１以上である。図１に示すＮ×Ｍ相互接続ネットワーク・アーキテクチャの概要図を参照するに、Ｍ個のサービス・ノードはサービス・ノード・プールを構成し、Ｎ個のサービス要求ノードはサービス要求ノード・プールを構成し、サービス・ノード・プールにおけるサービス・ノードはそれぞれ、ＩＰバックボーン・ネットワークを介して完全なメッシュとしてサービス要求ノード・プールにおけるサービス要求ノードそれぞれに相互接続される。サービス・ノード・プールにおけるサービス・ノードは同等のネットワーク位置にあり、同じ機能を有する。場合によっては、サ―ビス・ノードは、オペレータの構成に応じて、ＩＰアドレス・プール・リソースなどの一部のネットワーク・リソースを共有し、場合によっては、互いにサービスをバックアップする。サービス・ノードの１つに障害が生じた場合、正常に稼動している他のサービス・ノードは、障害が生じたサービス・ノードのネットワーク・リソースをプリエンプトするか、又は、障害が生じたサービス・ノードが担うサービスを引き継ぐ。ＧＰＲＳネットワーク又はＵＭＴＳネットワークでは、ＧＧＳＮに対してＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ、サービングＧＰＲＳサポート・ノード）はサービス要求者であり、ＳＧＳＮに対してＧＧＳＮはサービス提供者である。したがって、ＧＰＲＳネットワーク又はＵＭＴＳネットワークでは、実施例に関係するサービス・ノードはＧＧＳＮであり、サービス要求ノードはＳＧＳＮである。ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ、ロング・ターム・エボリューション）−ＳＡＥ（Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ、システム・アーキテクチャ・エボリューション）ネットワーク・アーキテクチャでは、サービスの開始方向は常に、ＭＭＥ（モビリティ管理エンティティ）からサービングＧＷ（Ｓｅｒｖｉｎｇ ＧａｔｅＷａｙ、サービング・ゲートウェイ）に向かう。したがって、相対的に言えば、ＭＭＥはサービス要求ノードであり、サービングＧＷはサービス・ノードである。サービングＧＷ及びＰＤＮ ＧＷ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ、パケット・データ・ネットワーク・ゲートウェイ）の場合、サービングＧＷはサービス要求ノードであり、ＰＤＮ ＧＷはサービス・ノードである。
本発明の技術的解決策は、Ｎ×Ｍ相互接続ネットワーク・アーキテクチャに基づいて以下に詳細に説明する。
（実施例１）
図２ａを参照するに、本実施例は、障害表示状態を判定する方法を提供し、この方法はサービス・ノードによって実現し得、上記方法は、
１０１ａ：サービス・ノード・プールにおけるサービス・ノードそれぞれが障害状態にあるか否かについて、サービス要求ノードにより送信された検出の結果を受信する工程と、
１０２ａ：検出の結果に応じ、サービス・ノード自体の障害表示状態、及びサービス・ノード自体以外の他のサービス・ノ―ドの障害表示状態を判定する工程と
を含む。
本実施例では、サービス・ノード・プールにおけるサービス・ノードそれぞれが障害状態にあるか否かについて、サービス要求ノードにより送信された検出の結果が受信され、サービス・ノード自体の障害表示状態、及びサービス・ノード自体以外の他のサービス・ノードの障害表示状態が検出の結果に応じて判定され、それにより、サービス・ノード障害検出の信頼性が向上する。
図２ｂを参照するに、この方法は、サービス要求ノードによって実現し得、上記方法は、
１０１ｂ：エコー要求メッセージを拡張する工程であって、エコー要求メッセージは、サービス・ノード・プールにおけるサービス・ノードそれぞれに、現在の期間の先行期間中に障害が生じたか否かの、サービス要求ノード自体による、検出の結果を有する工程と、
１０２ｂ：検出の結果に応じて、サービス・ノード自体の障害表示状態、及びサービス・ノード自体以外の他のサービス・ノードの障害表示状態をサービス・ノードそれぞれが判定することを可能にするよう、現在の期間の最初にサービス・ノード・プールにおけるサ―ビス・ノードそれぞれに向けてエコー要求メッセージを送信する工程と
を含む。
本実施例では、エコー要求メッセージは拡張されるので、エコー要求メッセージが、サービス・ノード・プールにおけるサービス・ノードそれぞれが現在の期間の先行期間内に障害状態にあるか否かの、サービス要求ノード自体による検出の結果を有しており、エコー要求メッセージが、検出の結果に応じて、サービス・ノード自体の障害表示状態、及びサービス・ノード自体以外の他のサービス・ノードの障害表示状態をサービス・ノードそれぞれが判定することを可能にするよう、サービス・ノード・プールにおけるサービス・ノードそれぞれに送信され、それにより、サービス・ノード障害検出の信頼性が向上する。
（実施例２）
本実施例は、障害表示状態を判定する方法を提供する。図３を参照するに、上記方法は、
２００：障害検出及び状態同期化期間（短縮して期間として表され、Ｔにセットされる）を選択し、サービス要求ノード・プールにおける各サービス要求ノード及びサービス・ノード・プールにおける各サービス・ノードに同じ期間Ｔをセットする。
工程２０１−２０４は、サービス要求ノード・プールにおける各サービス要求ノード上で実現される。
２０１：サービス要求ノードは、サービス・ノード・プールにおけるサービス・ノードそれぞれが、現在の期間の先行期間（期間Ｔ１にセットされる）内に障害状態にあるか否かの、サービス要求ノード自体による検出の結果をエコー要求メッセージが有することを可能にするようエコー要求Ｅｃｈｏ Ｒｅｑｕｅｓｔメッセージを拡張する。
更に、現在の期間が第１の期間である場合、エコー要求メッセージは、サービス・ノード・プールにおけるサービス・ノードそれぞれの初期化状態を有し得る。例えば、サ―ビス・ノードそれぞれの状態は障害状態に初期化し得る。
現在の期間の先行期間内にサービス・ノード・プールにおけるサービス・ノードそれぞれが障害状態にあるかをサービス要求ノード自体が検出する方法は以下の通りである。
サービス要求ノード自体は、期間Ｔ１の最初にサービス・ノード・プールにおけるサービス・ノード全てに向けてエコー要求メッセージを送信する。サービス要求ノード自体が、期間Ｔ１の終了前にサービス・ノードによって返されたエコー応答Ｅｃｈｏ Ｒｅｓｐｏｎｓｅメッセージを受信した場合、サービス要求ノード自体はサービス・ノードを正常にセットする。逆に、サービス要求ノード自体が、期間Ｔ１の終了前にサービス・ノードによって返されたエコー応答メッセージを受信しなかった場合、サービス要求ノード自体はサービス・ノードを障害状態にセットする。エコー要求メッセージは、サービス・ノード・プールにおけるサービス・ノードそれぞれが、期間Ｔ１の先行期間内に障害状態にあるか否かの、サービス要求ノード自体による検出の結果を有し得る。
エコー要求Ｅｃｈｏ Ｒｅｑｕｅｓｔメッセージをサービス要求ノードが拡張する方法は以下の通りである。すなわち、
サービス要求ノードは、エコー要求メッセージのアイドル・ビットを利用するか、又は新たなビットを追加し、ビットそれぞれは、サービス・ノードに障害が生じたか否かを表す。例えば、Ｅｃｈｏ Ｒｅｑｕｅｓｔ （ＧＧＳＮ＿ｓｔａｔｅｓ：００００ ０１１１）では、０番目のビットはＧＧＳＮ−１の状態を表し、１番目のビットはＧＧＳＮ−２の状態を表し、２番目のビットはＧＧＳＮ−３の状態を表す。ＧＧＳＮの場合、ＧＧＳＮに対応するビットが１である場合、ＧＧＳＮが正常であることが検出されていることを示し、ＧＧＳＮに対応するビットが０である場合、ＧＧＳＮが障害状態にあることが検出されていることを示す。
２０２：サービス要求ノードは、（期間Ｔ２にセットされる）現在の期間の最初にサービス・ノード・プールにおけるサービス・ノードそれぞれにエコー要求メッセージを送信する。
２０３：サービス要求ノードによって送信されたエコー要求メッセージを受信した後、サービス・ノードは検出の結果を記録し、エコー応答メッセージをサービス要求ノードに返す。
２０４：サービス要求ノードが、現在の期間の終了前にサービス・ノードによって返されるエコー応答メッセージを受信した場合、サービス要求ノードはサービス・ノードを正常にセットする。逆に、サービス要求ノードが、現在の期間の終了前にサービス・ノードによって返されるエコー応答メッセージを受信しなかった場合、サービス要求ノードはサービス・ノードを障害状態にセットする。
２０５：現在の期間の終了時に、サービス・ノードそれぞれは、サービス要求ノードそれぞれによって送信された検出の結果に応じ、サービス・ノード自体の障害表示状態、及びサービス・ノード自体以外の他のサービス・ノードの障害表示状態を判定する。
特に、サービス・ノードが、サービス要求ノードそれぞれによって送信された検出の結果に応じて、サービス・ノード自体以外の他のサービス・ノードの障害表示状態を判定することは、
少なくとも１つのサービス要求ノードによって送信され、現在の期間において受信された検出の結果が、他のサービス・ノードのうちのサービス・ノードＡが正常であることを示す場合、サービス・ノードＡの障害表示状態を正常にセットする状況、
サービス要求ノード全てによって送信され、現在の期間において受信された検出の結果が、他のサービス・ノードのうちのサービス・ノードＢが障害状態にあることを示す場合、サービス・ノードＢの障害表示状態を障害状態にセットする状況、及び
サービス要求ノードの一部によって送信された検出の結果が現在の期間において受信され、サービス要求ノードの一部によって送信された検出の結果が、他のサービス・ノードのうちのサービス・ノードＣに障害が生じたことを示す場合、サービス・ノードＣの障害表示状態を不確定にセットする状況
のうちの少なくとも１つを含む。
本実施例におけるサービス・ノードＡ、サービス・ノードＢ、又はサービス・ノードＣは特定のノードを特に表す訳でない一方、その検出結果が、本実施例の規定された特徴を満たすノードのタイプを表す。
特に、サービス・ノードが、サービス要求ノードそれぞれによって送信された検出の結果に応じて、サービス・ノード自体の障害表示状態を判定することは、
少なくとも１つのサービス要求ノードによって送信され、現在の期間内に受信された検出結果が、サービス・ノード自体が正常であることを示す場合、サービス・ノード自体の障害表示状態を正常にセットする状況、及び
何れかのサービス要求ノードによって送信された検出結果が、現在の期間内に受信されないか、又は、サービス要求ノードによって送信され、現在の期間内で受信された検出の結果全てが、サービス・ノード自体に障害が生じたことを示す場合、サービス・ノード自体の障害表示状態を異常にセットする状況
のうちの少なくとも１つを含む。
この工程の更に明確な説明については、図４に示す障害表示状態の判定の概略フローチャートを参照されたい。ここで、ＳＧＳＮ−１：ｘ１ｙ１ｚ１は、サービス・ノードＧＧＳＮ−ｘ、サービス・ノードＧＧＳＮ−ｙ、及びサービス・ノードＧＧＳＮ−ｚに対するサービス要求ノードＳＧＳＮ−１の障害検出結果がｘ１、ｙ１、及びｚ１それぞれであることを表す。ＳＧＳＮ−２：ｘ２ｙ２ｚ２は、サービス・ノードＧＧＳＮ−ｘ、サービス・ノードＧＧＳＮ−ｙ、及びサービス・ノードＧＧＳＮ−ｚに対するサービス要求ノードＳＧＳＮ−２の障害検出結果がｘ２、ｙ２、及びｚ２それぞれであることを表す。ＳＧＳＮ−３：ｘ３ｙ３ｚ３は、サービス・ノードＧＧＳＮ−ｘ、サービス・ノードＧＧＳＮ−ｙ、及びサービス・ノードＧＧＳＮ−ｚに対するサービス要求ノードＳＧＳＮ−３の障害検出結果がｘ３、ｙ３、及びｚ３それぞれであることを表す。ＳＧＳＮ−１：ｘ１ｙ１ｚ１、ＳＧＳＮ−２：ｘ２ｙ２ｚ２、及びＳＧＳＮ−３：ｘ３ｙ３ｚ３は、ＧＧＳＮ−ｘ、ＧＧＳＮ−ｙ、及びＧＧＳＮ−ｚそれぞれに送信される。ＧＧＳＮ−ｘ、ＧＧＳＮ−ｙ、及びＧＧＳＮ−ｚは、ＳＧＳＮ−１：ｘ１ｙ１ｚ１、ＳＧＳＮ−２：ｘ２ｙ２ｚ２、及びＳＧＳＮ−３：ｘ３ｙ３ｚ３に応じて、サービス・ノード自体及び他のサービス・ノードの障害表示状態を得る。ｘ：Ｎ／ＡはＧＧＳＮ−ｘの障害表示状態を表し、ｙ：Ｎ／Ｆ／ＵはＧＧＳＮ−ｙの障害表示状態を表し、ｚ：Ｎ／Ｆ／ＵはＧＧＳＮ−ｚの障害表示状態を表す。Ｎは正常の略であり、Ａは異常の略であり、Ｆが障害の略であり、Ｕは不確定の略である。
任意的には、工程２０６は、工程２０５の後に更に実現し得る。
２０６：サービス・ノードそれぞれは、主状態としてのサービス・ノード自体の障害表示状態、及び補助状態としての他のサービス・ノードの障害表示状態を使用することにより、ネットワーク・リソース獲得挙動及び／又はリリース挙動をトリガする。
図５に示す挙動トリガ及び挙動時系列制御の概略図を参照するに、本工程は特に、
サービス・ノード自体の障害表示状態が異常から正常に変化する場合、予め設定された第１の保護持続時間（Ｔｃ１にセットされる）後、サービス・ノード自体のネットワーク・リソースを獲得する処理と、サービス・ノード自体の障害表示状態が正常から異常に変化する場合、サービス・ノード自体のネットワーク・リソースをリリースする処理をトリガし、予め設定された第２の持続時間（Ｔｒ１にセットされる）内にサービス・ノード自体のネットワーク・リソースのリリースを完了する工程と、
サービス・ノード自体の障害表示状態が正常の場合に、他のサービス・ノードのうちのサービス・ノードＤの障害表示状態が正常から障害状態に変化した場合、サービス・ノードＤのネットワーク・リソースを獲得する処理を、予め設定された第３の保護持続時間（Ｔｃ２にセットされる）後にトリガする工程と、
サービス・ノード自体の障害表示状態が正常である場合に、他のサービス・ノードのうちのサービス・ノードＥの障害表示状態が障害状態から正常又は不確定に変化した場合、サービス・ノードＥのネットワーク・リソースをリリースする処理をトリガし、予め設定された第４の持続時間（Ｔｒ２にセットされる）内のサービス・ノードＥのネットワーク・リソースのリリースを完了する工程と
を含み、
第１の保護持続時間は第４の持続時間より長く、第３の保護持続時間は第２の持続時間よりも長い。
本実施例におけるサービス・ノードＤ、又はサービス・ノードＥは特定のノードを特に表す訳でない一方、その検出結果が、本実施例の規定された特徴を満たすノードのタイプを表す。
障害は、サービスを提供することができないことを意味する。したがって、サービス要求ノードの観点から、サービス・ノードに障害が生じたか否かは、サービス・ノードが、サービス要求ノードに対してサービスを提供することが可能であるか否かと同じ意味を有する。したがって、本実施例では、サービス要求ノードは、サービス・ノードに障害が生じたか否かを検出し、検出の結果をサービス・ノードに通知する。これは、互いの間でピア端に障害が生じたかのサービス・ノードによる検出と比較すると、状態の誤判断の可能性をなくすか（、又は障害の理解における曖昧性をなくし）、サービス・ノード障害検出の信頼性を向上させる。例えば、２つのＧＧＳＮ間の通信リンクが遮断された場合、既存の技術的解決策によれば、ピア端に障害が生じたと２つのＧＧＳＮは何れも判断する。本実施例の技術的解決策によれば、ＧＧＳＮがサービスをなお提供することが可能であるか否かをサービス要求ノードは検査し、ＧＧＳＮがサービスを提供することが可能である場合、ＧＧＳＮが正常であると結論付けることができ、ＧＧＳＮがサービスを提供することが可能でない場合、ＧＧＳＮに障害が生じたと結論付けられる。したがって、本実施例の技術的解決策によれば、障害検出の信頼性は高くなる。複数のサービス要求ノードが存在する場合、サービス・ノードは、複数のサービス要求ノードの検出の結果に応じて、サービス・ノード自体及び他のサービス・ノードの障害表示状態を包括的に判定し得、それにより、サービス・ノード障害検出の信頼性を更に向上させ得る。更に、本実施例は更に、完全な挙動トリガ及び挙動時系列制御ロジックを規定し、これにより、ネットワーク・リソース獲得及び／又はリリースなどのネットワーク挙動間の競合が回避され得る。
（実施例３）
図６を参照するに、本実施例はサービス・ノードを提供し、サービス・ノードは、
サービス・ノード・プールにおけるサービス・ノードそれぞれが障害状態にあるか否かについて、サービス要求ノードにより送信された検出の結果を受信するよう構成された受信器３０１と、
検出の結果に応じて、サービス・ノード自体の障害表示状態、及びサービス・ノード自体以外の他のサービス・ノ―ドの障害表示状態を判定するよう構成された判定器３０２と
を含む。
受信器３０１は、
サービス要求ノードによって送信されたエコー要求メッセージを現在の期間中に受信するよう構成され、エコー要求メッセージは、サービス・ノード・プールにおけるサービス・ノードそれぞれに、現在の期間の先行期間内に障害状態にあるか否かの、サービス要求ノードによる検出の結果を有する。
判定器３０２が、検出の結果に応じて、サービス・ノード自体以外の他のサービス・ノードの障害表示状態を判定するよう構成されることは、
サービス要求ノードのうちの少なくとも１つによって送信され、現在の期間において受信された検出の結果が、他のサービス・ノードのうちのサービス・ノードＡが正常であることを示す場合、サービス・ノードＡの障害表示状態を正常にセットする状況、
サービス要求ノード全てによって送信され、現在の期間において受信された検出の結果が、他のサービス・ノードのうちのサービス・ノードＢが障害状態であることを示す場合、サービス・ノードＢの障害表示状態を障害状態にセットする状況、及び
サービス要求ノードの一部によって送信された検出の結果が現在の期間において受信され、サービス要求ノードの一部によって送信された検出の結果が、他のサービス・ノードのうちのサービス・ノードＣに障害が生じたことを示す場合、サービス・ノードＣの障害表示状態を不確定にセットする状況
のうちの少なくとも１つを含む。
判定器３０２が、検出の結果に応じて、サービス・ノード自体の障害表示状態を判定するよう構成されることは、
サービス要求ノードのうちの少なくとも１つによって送信され、現在の期間内に受信された検出結果が、サービス・ノード自体が正常であることを示す場合、サービス・ノード自体の障害表示状態を正常にセットする状況、及び
サービス要求ノードのうちの何れかによって送信された検出結果が、現在の期間内に受信されないか、又は、サービス要求ノードによって送信され、現在の期間内で受信された検出の結果全てが、サービス・ノード自体に障害が生じたことを示す場合、サービス・ノード自体の障害表示状態を異常にセットする状況
のうちの少なくとも１つを含む。
サービス・ノードは、
トリガは、主状態としてのサービス・ノード自体の障害表示状態、及び補助状態としての他のサービス・ノードの障害表示状態を使用することにより、ネットワーク・リソース獲得挙動及び／又はリリース挙動を、判定器が実行された後にトリガするよう構成されたトリガ
を更に含む。
トリガは、
サービス・ノード自体の障害表示状態が異常から正常に変化する場合、予め設定された第１の保護持続時間後、サービス・ノード自体のネットワーク・リソースを獲得する処理をトリガする状況、
サービス・ノード自体の障害表示状態が正常から異常に変化する場合、サービス・ノード自体のネットワーク・リソースをリリースする処理をトリガし、予め設定された第２の持続時間内にサービス・ノード自体のネットワーク・リソースのリリースを完了する状況、
サービス・ノード自体の障害表示状態が正常の場合に、他のサービス・ノードのうちのサービス・ノードＤの障害表示状態が正常から障害状態に変化した場合、サービス・ノードＤのネットワーク・リソースを獲得する処理を、予めセットされた第３の保護持続時間後にトリガする状況、及び
サービス・ノード自体の障害表示状態が正常である場合に、他のサービス・ノードのうちのサービス・ノードＥの障害表示状態が障害状態から正常又は不確定に変化した場合、サービス・ノードＥのネットワーク・リソースをリリースする処理をトリガし、予め設定された第４の持続時間内のサービス・ノードＥのネットワーク・リソースのリリースを完了する状況
のうちの少なくとも１つを実現するよう構成され、
第１の保護持続時間は第４の持続時間よりも長く、第３の保護持続時間は第２の持続時間よりも長い。
本実施例において提供されるサービス・ノード、及び方法の実施例におけるサービス・ノードは同じ概念に属する。この特定の処理の場合、方法の実施例を参照し得るので、本明細書及び特許請求の範囲において、詳細は繰り返し、説明しない。
本実施例では、サービス・ノード・プールにおけるサービス・ノードそれぞれが障害状態にあるか否かについて、サービス要求ノードにより送信された検出の結果が受信され、サービス・ノード自体の障害表示状態、及びサービス・ノード自体以外の他のサービス・ノードの障害表示状態が検出の結果に応じて判定され、それにより、サービス・ノード障害検出の信頼性が向上する。複数のサービス要求ノードが存在する場合、サービス・ノードは、複数のサービス要求ノードの検出の結果に応じて、サービス・ノード自体及び他のサービス・ノードの障害表示状態を包括的に判定し得、それにより、サービス・ノード障害検出の信頼性を更に向上させ得る。更に、本実施例は更に、完全な挙動トリガ及び挙動時系列制御ロジックを更に規定し、これにより、ネットワーク挙動間の競合が避けられ得る。
（実施例４）
図７を参照するに、本実施例はサービス要求ノードを提供し、サービス要求ノードは、
エコー要求メッセージを拡張するよう構成された拡張器４０１であって、エコー要求メッセージは、サービス・ノード・プールにおけるサービス・ノードそれぞれが、現在の期間の先行期間内に障害状態にあるか否かの、サービス要求ノード自体による検出の結果を有している拡張器４０１と、
検出の結果に応じて、サービス・ノード自体の障害表示状態、及びサービス・ノード自体以外の他のサービス・ノードの障害表示状態をサービス・ノードそれぞれが判定することを可能にするよう、現在の期間の最初にサービス・ノード・プールにおけるサ―ビス・ノードそれぞれに向けてエコー要求メッセージを送信するよう構成された送信器４０２と
を備える。
拡張器４０１は、
エコー要求メッセージのアイドル・ビットを利用するよう構成され、アイドル・ビットそれぞれは、サービス・ノード・プールにおけるサービス・ノードに障害が生じたか否かを表し、又は、
新たなビットをエコー要求メッセージにおいて追加するよう構成され、新たなビットそれぞれは、サービス・ノード・プールにおけるサービス・ノードに障害が生じたか否かを表す。
本実施例において提供されるサービス要求ノード、及び方法の実施例におけるサービス要求ノードは同じ概念に属する。この特定の処理の場合、方法の実施例を参照し得るので、本明細書及び特許請求の範囲において、詳細は繰り返し、説明しない。
本実施例では、エコー要求メッセージは拡張されるので、エコー要求メッセージが、サービス・ノード・プールにおけるサービス・ノードそれぞれが現在の期間の先行期間内に障害状態にあるか否かの、サービス要求ノード自体による検出の結果を有しており、エコー要求メッセージが、検出の結果に応じて、サービス・ノード自体の障害表示状態、及びサービス・ノード自体以外の他のサービス・ノードの障害表示状態をサービス・ノードそれぞれが判定することを可能にするよう、サービス・ノード・プールにおけるサービス・ノードそれぞれに送信され、それにより、サービス・ノード障害検出の信頼性が向上する。複数のサービス要求ノードが存在する場合、サービス・ノードは、複数のサービス要求ノードの検出の結果に応じて、サービス・ノード自体及び他のサービス・ノードの障害表示状態を包括的に判定し得、それにより、サービス・ノード障害検出の信頼性を更に向上させ得る。
（実施例５）
図８を参照するに、本実施例は障害表示状態を判定するシステムを提供し、上記システムはサービス・ノード５０２をサービス・ノード・プールにおけるサービス・ノード５０２、及びサービス要求ノード５０１を含む。
サービス要求ノード５０１は拡張器４０１及び送信器４０２を含む。
拡張器４０１は、エコー要求メッセージを拡張するよう構成され、エコー要求メッセージは、サービス・ノード・プールにおけるサービス・ノードそれぞれに、現在の期間の先行期間内に障害状態にあるか否かの、サービス要求ノード自体による検出の結果を有する。
送信器４０２は、検出の結果に応じて、サービス・ノード自体の障害表示状態、及びサービス・ノード自体以外の他のサービス・ノードの障害表示状態をサービス・ノードそれぞれが判定することを可能にするよう、現在の期間の最初にサービス・ノード・プールにおけるサ―ビス・ノードそれぞれに向けてエコー要求メッセージを送信するよう構成される。
サービス・ノード５０２それぞれは、受信器３０１及び判定器３０２を含む。
受信器３０１は、サービス要求ノードによって送信されたエコー要求メッセージを受信するよう構成され、エコー要求メッセージは、サービス・ノード・プールにおけるサービス・ノードそれぞれが、現在の期間の先行期間中に障害状態にあるか否かの、サービス要求ノードによる検出の結果を有する。
判定器３０２は、検出の結果に応じて、サービス・ノード自体の障害表示状態、及びサービス・ノード自体以外の他のサービス・ノ―ドの障害表示状態を判定するよう構成される。
本実施例において提供されるサービス要求ノード及びサービス・ノードと、方法の実施例におけるサービス要求ノード及びサービス・ノードは同じ概念に属する。この特定の処理の場合、方法の実施例を参照し得るので、本明細書及び特許請求の範囲において、詳細は繰り返し、説明しない。
本実施例では、エコー要求メッセージは拡張されるので、エコー要求メッセージが、サービス・ノード・プールにおけるサービス・ノードそれぞれが現在の期間の先行期間内に障害状態にあるか否かの、サービス要求ノード自体による検出の結果を有しており、エコー要求メッセージが、検出の結果に応じて、サービス・ノード自体の障害表示状態、及びサービス・ノード自体以外の他のサービス・ノードの障害表示状態をサービス・ノードそれぞれが判定することを可能にするよう、サービス・ノード・プールにおけるサービス・ノードそれぞれに送信され、それにより、サービス・ノード障害検出の信頼性が向上する。複数のサービス要求ノードが存在する場合、サービス・ノードは、複数のサービス要求ノードの検出の結果に応じて、サービス・ノード自体及び他のサービス・ノードの障害表示状態を包括的に判定し得、それにより、サービス・ノード障害検出の信頼性を更に向上させ得る。
上記実施例の工程の全て又は一部をハードウェアによって実現し得、更に、関連したハードウェアに指示するプログラムによっても実現し得る。プログラムはコンピュータ読み取り可能な記憶媒体に記憶し得る。記憶媒体は、リードオンリ・メモリ、磁気ディスク、光ディスク等であり得る。
上記説明は、本発明の例示的な実施例に過ぎない一方、本発明を限定することを意図するものでない。本発明の趣旨及び原理の範囲内で行われた修正、均等の置換、又は改良は何れも、本発明の保護範囲内に収まるものとする。

Claims (16)

  1. サービス・ノードが障害状態にあるか否かを示す障害表示状態を判定する方法であって、
    サービス・ノード・プールにおけるサービス・ノードそれぞれが障害状態にあるか否かについて、サービス要求ノードにより送信された検出の結果をサービス・ノードによって受信する工程と、
    検出の結果に応じて、前記サービス・ノード自体の障害表示状態、及び前記サービス・ノード自体以外の他のサービス・ノ―ドの障害表示状態を前記サービス・ノードによって判定する工程と、
    検出の結果に応じて、サービス・ノード自体の障害表示状態、及び前記サービス・ノード自体以外の他のサービス・ノ―ドの障害表示状態を判定する工程の後、前記サービス・ノード自体の障害表示状態、及び他のサービス・ノードの障害表示状態を使用することにより、ネットワーク・リソース獲得挙動及びリリース挙動の一方をトリガする工程と
    を含む方法。
  2. 請求項１記載の方法であって、前記サービス・ノード・プールにおけるサービス・ノードそれぞれが障害状態にあるか否かについて、サービス要求ノードにより送信された検出の結果を受信する工程は、
    前記サービス要求ノードによって送信されたエコー要求メッセージを現在の期間内に受信する工程を含み、前記エコー要求メッセージは、前記サービス・ノード・プールにおけるサービス・ノードそれぞれが、前記現在の期間の先行期間内に障害状態にあるか否かの、前記サービス要求ノードによる検出の結果を有する方法。
  3. 請求項１又は２に記載の方法であって、検出の結果に応じて、前記サービス・ノード自体以外の他のサービス・ノードの障害表示状態を判定する工程は、
    前記サービス要求ノードのうちの少なくとも１つによって送信され、現在の期間において受信された検出の結果が、前記他のサービス・ノードのうちのサービス・ノードＡが正常であることを示す場合、前記サービス・ノードＡの障害表示状態を正常にセットする状況、
    前記サービス要求ノード全てによって送信され、前記現在の期間において受信された検出の結果が、前記他のサービス・ノードのうちのサービス・ノードＢが障害状態であることを示す場合、前記サービス・ノードＢの障害表示状態を障害状態にセットする状況、及び
    前記サービス要求ノードの一部によって送信された検出の結果が前記現在の期間において受信され、前記サービス要求ノードの前記一部によって送信された検出の結果が、前記他のサービス・ノードのうちのサービス・ノードＣが障害状態にあることを示す場合、前記サービス・ノードＣの障害表示状態を不確定にセットする状況
    のうちの少なくとも１つを含む方法。
  4. 請求項１又は２に記載の方法であって、検出の結果に応じて、サービス・ノード自体の障害表示状態を判定する工程は、
    前記サービス要求ノードのうちの少なくとも１つによって送信され、現在の期間内に受信された検出結果が、前記サービス・ノード自体が正常であることを示す場合、前記サービス・ノード自体の障害表示状態を正常にセットする状況、及び
    前記サービス要求ノードのうちの何れかによって送信された検出結果が、前記現在の期間内に受信されないか、又は、前記サービス要求ノードによって送信され、前記現在の期間内で受信された検出の結果全てが、前記サービス・ノード自体が障害状態にあることを示す場合、前記サービス・ノード自体の障害表示状態を異常にセットする状況
    のうちの少なくとも１つを含む方法。
  5. 請求項１記載の方法であって、前記サービス・ノード自体の障害表示状態、及び他のサービス・ノードの障害表示状態を使用することにより、ネットワーク・リソース獲得挙動及びリリース挙動の一方をトリガする工程は、
    前記サービス・ノード自体の障害表示状態が異常から正常に変化する場合、予め設定された第１の保護持続時間後、前記サービス・ノード自体のネットワーク・リソースを獲得する処理をトリガする状況、
    前記サービス・ノード自体の障害表示状態が正常から異常に変化する場合、前記サービス・ノード自体のネットワーク・リソースをリリースする処理をトリガし、予め設定された第２の持続時間内に前記サービス・ノード自体のネットワーク・リソースのリリースを完了する状況、
    前記サービス・ノード自体の障害表示状態が正常の場合に、他のサービス・ノードのうちのサービス・ノードＤの障害表示状態が正常から障害状態に変化した場合、前記サービス・ノードＤのネットワーク・リソースを獲得する処理を、予め設定された第３の保護持続時間後にトリガする状況、及び
    前記サービス・ノード自体の障害表示状態が正常である場合に、他のサービス・ノードのうちのサービス・ノードＥの障害表示状態が障害状態から正常又は不確定に変化した場合、前記サービス・ノードＥのネットワーク・リソースをリリースする処理をトリガし、予め設定された第４の持続時間内に前記サービス・ノードＥのネットワーク・リソースのリリースを完了する状況
    を含み、
    前記第１の保護持続時間は前記第４の持続時間よりも長く、前記第３の保護持続時間は前記第２の持続時間よりも長い方法。
  6. 請求項１乃至５の何れか一項に記載の方法であって、前記サービス・ノード・プールにおけるサービス・ノードそれぞれが障害状態にあるか否かについて、サービス要求ノードにより送信された検出の結果を受信する工程の前に、前記方法は、
    エコー要求メッセージを前記サービス要求ノードによって拡張する工程であって、前記エコー要求メッセージは、前記サービス・ノード・プールにおけるサービス・ノードそれぞれが、現在の期間の先行期間内に障害状態にあるか否かの、前記サービス要求ノードによる検出の結果を有する工程と、
    前記現在の期間の最初に前記サービス・ノード・プールにおけるサービス・ノードそれぞれに向けて前記エコー要求メッセージを前記サービス要求ノードによって送信する工程と
    を含む方法。
  7. サービス・ノードが障害状態にあるか否かを示す障害表示状態を判定する方法であって、
    エコー要求メッセージをサービス要求ノードによって拡張する工程であって、前記エコー要求メッセージは、サービス・ノード・プールにおけるサービス・ノードそれぞれが、現在の期間の先行期間内に障害状態にあるか否かの、サービス要求ノード自体による検出の結果を有している工程と、
    検出の結果に応じて、前記サービス・ノード自体の障害表示状態、及び前記サービス・ノード自体以外の他のサービス・ノードの障害表示状態をサービス・ノードそれぞれが判定し、前記サービス・ノード自体の障害表示状態、及び他のサービス・ノードの障害表示状態を使用することにより、ネットワーク・リソース獲得挙動及びリリース挙動の一方をトリガすることを可能にするよう、前記現在の期間の最初に前記サービス・ノード・プールにおけるサ―ビス・ノードそれぞれに向けて前記エコー要求メッセージをサービス要求ノードによって送信する工程と
    を含む方法。
  8. 請求項７記載の方法であって、前記エコー要求メッセージを拡張する工程は、
    前記エコー要求メッセージのアイドル・ビットを利用する工程であって、前記アイドル・ビットそれぞれは、前記サービス・ノード・プールにおけるサービス・ノードに障害が生じたか否かを表す工程、又は、
    新たなビットを前記エコー要求メッセージにおいて追加する工程であって、前記新たなビットそれぞれは、前記サービス・ノード・プールにおけるサービス・ノードに障害が生じたか否かを表す工程
    を含む方法。
  9. サービス・ノードであって、
    サービス・ノード・プールにおけるサービス・ノードそれぞれが障害状態にあるか否かについて、サービス要求ノードにより送信された検出の結果を受信するよう構成された受信器と、
    前記検出の結果に応じ、サービス・ノードが障害状態にあるか否かを示す前記サービス・ノード自体の障害表示状態、及び前記サービス・ノード自体以外の他のサービス・ノ―ドの障害表示状態を判定するよう構成された判定器と、
    前記サービス・ノード自体の障害表示状態及び他のサービス・ノードの障害表示状態を使用することにより、ネットワーク・リソース獲得挙動及びリリース挙動の一方を、前記判定器が実行された後にトリガするよう構成されたトリガと
    を備えるサービス・ノード。
  10. 請求項９記載のサービス・ノードであって、前記受信器は、
    前記サービス要求ノードによって送信されたエコー要求メッセージを現在の期間内に受信するよう構成され、前記エコー要求メッセージは、前記サービス・ノード・プールにおけるサービス・ノードそれぞれが、前記現在の期間の先行期間内に障害状態にあるか否かの、前記サービス要求ノードによる検出の結果を有するサービス・ノード。
  11. 請求項９又は１０に記載のサービス・ノードであって、前記判定器が、検出の結果に応じて、前記サービス・ノード自体以外の他のサービス・ノードの障害表示状態を判定するよう構成されることは、
    前記サービス要求ノードのうちの少なくとも１つによって送信され、現在の期間において受信された検出の結果が、前記他のサービス・ノードのうちのサービス・ノードＡが正常であることを示す場合、前記サービス・ノードＡの障害表示状態を正常にセットする状況、
    前記サービス要求ノード全てによって送信され、前記現在の期間において受信された検出の結果が、他のサービス・ノードのうちのサービス・ノードＢが障害状態であることを示す場合、前記サービス・ノードＢの障害表示状態を障害状態にセットする状況、及び
    前記サービス要求ノードの一部によって送信された検出の結果が前記現在の期間において受信され、前記サービス要求ノードの前記一部によって送信された検出の結果が、他のサービス・ノードのうちのサービス・ノードＣが障害状態にあることを示す場合、前記サービス・ノードＣの障害表示状態を不確定にセットする状況
    のうちの少なくとも１つを含むサービス・ノード。
  12. 請求項９又は１０に記載のサービス・ノードであって、前記判定器が、検出の結果に応じて、サービス・ノード自体の障害表示状態を判定するよう構成されることは、
    前記サービス要求ノードのうちの少なくとも１つによって送信され、現在の期間内に受信された検出結果が、前記サービス・ノード自体が正常であることを示す場合、前記サービス・ノード自体の障害表示状態を正常にセットする状況、及び
    前記サービス要求ノードのうちの何れかによって送信された検出結果が、前記現在の期間内に受信されないか、又は、前記サービス要求ノードによって送信され、前記現在の期間内で受信された検出の結果全てが、前記サービス・ノード自体が障害状態にあることを示す場合、前記サービス・ノード自体の障害表示状態を異常にセットする状況
    のうちの少なくとも１つを含むサービス・ノード。
  13. 請求項９記載のサービス・ノードであって、前記トリガは、
    前記サービス・ノード自体の障害表示状態が異常から正常に変化する場合、前記サービス・ノード自体のネットワーク・リソースを獲得する処理を、予め設定された第１の保護持続時間後にトリガする状況、
    前記サービス・ノード自体の障害表示状態が正常から異常に変化する場合、前記サービス・ノード自体のネットワーク・リソースをリリースする処理をトリガし、予め設定された第２の持続時間内に前記サービス・ノード自体のネットワーク・リソースのリリースを完了する状況、
    前記サービス・ノード自体の障害表示状態が正常の場合に、他のサービス・ノードのうちのサービス・ノードＤの障害表示状態が正常から障害状態に変化した場合、前記サービス・ノードＤのネットワーク・リソースを獲得する処理を、予め設定された第３の保護持続時間後にトリガする状況、及び
    前記サービス・ノード自体の障害表示状態が正常である場合に、他のサービス・ノードのうちのサービス・ノードＥの障害表示状態が障害状態から正常又は不確定に変化した場合、前記サービス・ノードＥのネットワーク・リソースをリリースする処理をトリガし、予め設定された第４の持続時間内に前記サービス・ノードＥのネットワーク・リソースのリリースを完了する状況
    のうちの少なくとも１つを実現するよう構成され、
    前記第１の保護持続時間は前記第４の持続時間よりも長く、前記第３の保護持続時間は前記第２の持続時間よりも長いサービス・ノード。
  14. サービス要求ノードであって、
    エコー要求メッセージを拡張するよう構成された拡張器であって、前記エコー要求メッセージは、サービス・ノード・プールにおけるサービス・ノードそれぞれが、現在の期間の先行期間内に障害状態にあるか否かの、前記サービス要求ノード自体による検出の結果を有している拡張器と、
    検出の結果に応じて、サービス・ノードが障害状態にあるか否かを示すサービス・ノード自体の障害表示状態、及び前記サービス・ノード自体以外の他のサービス・ノードの障害表示状態をサービス・ノードそれぞれが判定し、前記サービス・ノード自体の障害表示状態、及び他のサービス・ノードの障害表示状態を使用することにより、ネットワーク・リソース獲得挙動及びリリース挙動の一方をトリガすることを可能にするよう、現在の期間の最初に前記サービス・ノード・プールにおけるサ―ビス・ノードそれぞれに向けて前記エコー要求メッセージを送信するよう構成された送信器と
    を備えるサービス要求ノード。
  15. 請求項１４記載のサービス要求ノードであって、前記拡張器は、
    前記エコー要求メッセージのアイドル・ビットを利用するよう構成され、前記アイドル・ビットそれぞれは、前記サービス・ノード・プールにおけるサービス・ノードに障害が生じたか否かを表し、又は、
    新たなビットを前記エコー要求メッセージにおいて追加するよう構成され、前記新たなビットそれぞれは、前記サービス・ノード・プールにおけるサービス・ノードに障害が生じたか否かを表すサービス要求ノード。
  16. サービス・ノード・プールにおけるサービス・ノード、及びサービス要求ノードを備える、サービス・ノードが障害状態にあるか否かを示す障害表示状態を判定するシステムであって、
    前記サービス要求ノードは拡張器及び送信器を含み、
    前記拡張器は、エコー要求メッセージを拡張するよう構成され、前記エコー要求メッセージは、前記サービス・ノード・プールにおける前記サービス・ノードそれぞれが、現在の期間の先行期間中に障害状態にあるか否かの、前記サービス要求ノード自体による検出の結果を有し、
    前記送信器は、検出の結果に応じて、前記サービス・ノード自体の障害表示状態、及び前記サービス・ノード自体以外の他のサービス・ノードの障害表示状態を前記サービス・ノードそれぞれが判定し、前記サービス・ノード自体の障害表示状態、及び他のサービス・ノードの障害表示状態を使用することにより、ネットワーク・リソース獲得挙動及びリリース挙動の一方をトリガすることを可能にするよう、前記現在の期間の最初に前記サービス・ノード・プールにおける前記サ―ビス・ノードそれぞれに向けて前記エコー要求メッセージを送信するよう構成され、
    前記サービス・ノードそれぞれは、受信器、判定器及びトリガを含み、
    前記受信器は、前記サービス要求ノードによって送信された前記エコー要求メッセージを受信するよう構成され、前記エコー要求メッセージは、前記サービス・ノード・プールにおける前記サービス・ノードそれぞれが、前記現在の期間の前記先行期間内に障害状態にあるか否かの、前記サービス要求ノードによる検出の結果を有し、
    前記判定器は、検出の結果に応じて、前記サービス・ノード自体の障害表示状態、及び前記サービス・ノード自体以外の他のサービス・ノ―ドの障害表示状態を判定するよう構成され、
    前記トリガは、前記サービス・ノード自体の障害表示状態及び他のサービス・ノードの障害表示状態を使用することにより、ネットワーク・リソース獲得挙動及びリリース挙動の一方を、前記判定器が実行された後にトリガするよう構成されるシステム。
JP2014513022A 2011-05-30 2011-05-30 障害表示状態を判定する方法、ノード、及びシステム Active JP5802829B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2011/074888 WO2011157111A2 (zh) 2011-05-30 2011-05-30 确定故障指示状态的方法、节点和系统

Publications (2)

Publication Number Publication Date
JP2014522593A JP2014522593A (ja) 2014-09-04
JP5802829B2 true JP5802829B2 (ja) 2015-11-04

Family

ID=45348606

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014513022A Active JP5802829B2 (ja) 2011-05-30 2011-05-30 障害表示状態を判定する方法、ノード、及びシステム

Country Status (5)

Country Link
US (1) US9471408B2 (ja)
EP (1) EP2704356B1 (ja)
JP (1) JP5802829B2 (ja)
CN (1) CN102918802B (ja)
WO (1) WO2011157111A2 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104734867B (zh) * 2013-12-19 2019-05-03 中兴通讯股份有限公司 网络业务节点故障处理方法、装置及系统
CN106656580B (zh) * 2016-11-29 2020-06-26 华为技术有限公司 一种业务状态的迁移方法及装置
CN110162424B (zh) * 2019-05-23 2022-03-22 腾讯科技（深圳）有限公司 故障处理方法、系统、装置及存储介质
CN113489608A (zh) * 2021-06-30 2021-10-08 四川虹美智能科技有限公司 业务异常的处理方法和装置

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS61131933A (ja) * 1984-11-30 1986-06-19 Nec Eng Ltd 分散処理形交換装置のヘルスチエツク方式
US6161196A (en) * 1998-06-19 2000-12-12 Lucent Technologies Inc. Fault tolerance via N-modular software redundancy using indirect instrumentation
JP3983138B2 (ja) * 2002-08-29 2007-09-26 富士通株式会社 障害情報収集プログラムおよび障害情報収集装置
JP4457581B2 (ja) * 2003-05-28 2010-04-28 日本電気株式会社 耐障害システム、プログラム並列実行方法、耐障害システムの障害検出装置およびプログラム
US7284147B2 (en) * 2003-08-27 2007-10-16 International Business Machines Corporation Reliable fault resolution in a cluster
US7228460B2 (en) * 2004-01-23 2007-06-05 Hewlett-Packard Development Company, L.P. Multi-state status reporting for high-availability cluster nodes
CN1728658A (zh) * 2004-07-29 2006-02-01 华为技术有限公司 一种检测网关服务节点和计费网关之间连通性的方法
CN100431314C (zh) * 2005-05-08 2008-11-05 中兴通讯股份有限公司 自动交换光网络中维护控制平面可达性信息的方法
CN100579025C (zh) * 2006-03-30 2010-01-06 中兴通讯股份有限公司 一种自动交换光网络的路由信息维护方法
CN101207408B (zh) 2006-12-22 2012-07-11 中兴通讯股份有限公司 一种用于主备倒换的综合故障检测装置和方法
US8671151B2 (en) * 2007-01-24 2014-03-11 Oracle International Corporation Maintaining item-to-node mapping information in a distributed system
CN101420335B (zh) * 2007-10-26 2011-09-14 华为技术有限公司 对等网络节点故障检测/处理方法及装置
CN101459549B (zh) * 2007-12-14 2011-09-21 华为技术有限公司 链路故障处理方法及数据转发装置
US8774010B2 (en) * 2010-11-02 2014-07-08 Cisco Technology, Inc. System and method for providing proactive fault monitoring in a network environment

Also Published As

Publication number Publication date
US9471408B2 (en) 2016-10-18
WO2011157111A3 (zh) 2012-05-03
US20140082432A1 (en) 2014-03-20
EP2704356B1 (en) 2019-09-04
EP2704356A2 (en) 2014-03-05
EP2704356A4 (en) 2014-06-25
JP2014522593A (ja) 2014-09-04
CN102918802A (zh) 2013-02-06
CN102918802B (zh) 2015-03-11
WO2011157111A2 (zh) 2011-12-22

Similar Documents

Publication Publication Date Title
CN107332726B (zh) 一种通信链路的检测方法及装置
US9237092B2 (en) Method, apparatus, and system for updating ring network topology information
CN107612776B (zh) 一种通信连接检测方法及装置
US10560550B1 (en) Automatic configuration of a replacement network device in a high-availability cluster
US20070253327A1 (en) System and method of multi-nodal APS control protocol signalling
EP3029883B1 (en) Network protection method and apparatus, next-ring node, and system
JP5802829B2 (ja) 障害表示状態を判定する方法、ノード、及びシステム
US20130139178A1 (en) Cluster management system and method
US20140071813A1 (en) Protection switching method and apparatus
CN109462533B (zh) 链路切换方法、链路冗余备份网络和计算机可读存储介质
CN112367182A (zh) 容灾主备用设备的配置方法及装置
CN109194521B (zh) 一种流量转发方法及设备
KR101563133B1 (ko) 동적 멀티 도메인 환경에서 가상 회선 보호를 위한 시스템 및 방법
US10277484B2 (en) Self organizing network event reporting
CN108235800A (zh) 一种网络故障探测方法及控制中心设备
CN104639356A (zh) 一种故障恢复方法及设备
CN112422428B (zh) 链路状态获取方法、装置、电子设备及可读存储介质
CN111131035A (zh) 数据传输方法及装置
CN115152192B (zh) Pce受控网络可靠性
KR101207219B1 (ko) 데이터 분산 서비스 네트워크 과부하 방지 방법
CN112751740B (zh) 一种erps子环资源释放方法、系统、服务器及存储介质
US20230155931A1 (en) Method and apparatus for switching length of bidirectional forwarding detection packet and storage medium
CN113746574B (zh) 一种信息交互方法、系统及设备
CN112653596B (zh) 一种路由信息下发、网关设备切换的方法及装置
JP7120678B1 (ja) 通信処理装置、通信処理システム、障害通知方法及び障害通知プログラム

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20150202

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150224

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150521

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20150825

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150831

R150 Certificate of patent or registration of utility model

Ref document number: 5802829

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250