特表2023-531987IP Force 特許公報全文掲載

(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】
(54)【発明の名称】インサイチュフロー検出方法及び電子デバイス
(51)【国際特許分類】
   
   
【FI】
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】
(86)(22)【出願日】
(85)【翻訳文提出日】
(86)【国際出願番号】
(87)【国際公開番号】
(87)【国際公開日】
(81)【指定国・地域】
(71)【出願人】
【識別番号】518056748
【氏名又は名称】新華三技術有限公司
【氏名又は名称原語表記】NEW H3C TECHNOLOGIES CO., LTD.
(74)【代理人】
【識別番号】110002468
【氏名又は名称】弁理士法人後藤特許事務所
(72)【発明者】
【氏名】▲キュウ▼ 元香
(57)【要約】
本発明はインサイチュフロー検出方式及び電子デバイスを提供する。本発明では、第1のサービスパケットが、第1のネットワークドメインから第2のネットワークドメインに跨って転送されるなど、ドメインに跨って転送されても、第2のネットワークドメインの入口ノードが第1のサービスパケットを受信すると、簡単に第2のネットワークドメインに基づいて第1のサービスパケットをカプセル化するのではなく、カプセル化するときにさらに第1のサービスパケットに付加されている第1のインサイチュフロー検出オプションを参照して第1のサービスパケットの外層をカプセル化するパケットヘッダに第2のインサイチュフロー検出オプションを付加し、第2のインサイチュフロー検出オプションに基づいて第2のネットワークドメインでインサイチュフロー検出を行うことを実現し、第1のサービスパケットがドメインに跨って転送されるときのインサイチュフロー検出を実現した。
【選択図】図1
【特許請求の範囲】
【請求項】
インサイチュフロー検出方法であって、ネットワークデバイスに適用され、
第1のサービスパケットを受信するステップであって、前記第1のサービスパケットには第1のパケットヘッダが付加されており、前記第1のパケットヘッダは少なくとも第1のインサイチュフロー検出オプションを含み、前記第1のインサイチュフロー検出オプションは第1のネットワークドメインの入口ノードによって前記第1のパケットヘッダに追加され、前記第1のインサイチュフロー検出オプションはインサイチュフロー検出を示すために用いられるステップと、
前記ネットワークデバイスが第2のネットワークドメインの入口ノードである場合、前記第2のネットワークドメイン内で第2のサービスパケットを転送するステップであって、前記第2のサービスパケットは前記第1のサービスパケットの外層を第2のパケットヘッダでカプセル化することによって得られ、前記第2のパケットヘッダは少なくとも第2のインサイチュフロー検出オプションを含み、前記第2のインサイチュフロー検出オプションは前記第1のインサイチュフロー検出オプションと同じインサイチュフロー検出方式で同じサービスフローに対してインサイチュフロー検出を行うことを示すために用いられるステップとを含む、ことを特徴とするインサイチュフロー検出方法。
【請求項】
前記第2のインサイチュフロー検出オプションは前記第1のインサイチュフロー検出オプションをコピーすることによって得られ、
又は、
前記第1のインサイチュフロー検出オプションにおける検出制御情報フィールドと、前記第2のインサイチュフロー検出オプションにおける検出制御情報フィールドは同じ検出制御情報を含み、前記検出制御情報は前記サービスフロー及び前記インサイチュフロー検出方式を示すために用いられる、ことを特徴とする請求項1に記載の方法。
【請求項】
前記検出制御情報フィールドは少なくとも、
サービスフローを示すためのFlowMonIDフィールドと、
インサイチュフロー検出方式を示すためのインサイチュフロー検出方式フィールドとを含む、ことを特徴とする請求項2に記載の方法。
【請求項】
前記インサイチュフロー検出方式フィールドは、
パケット損失フラグを示すためのLフィールドと、
遅延フラグを示すためのDフィールドと、
前記第1のネットワークドメインの入口ノードのノード識別子を示すためのFlowMonID Extフィールドと、
インサイチュフロー検出のデータのデータタイプを示すためのIOAM-Trace-typeフィールドとの少なくとも1つのフィールドを含む、ことを特徴とする請求項3に記載の方法。
【請求項】
前記FlowMonIDフィールドは20bitsを占有する、ことを特徴とする請求項3に記載の方法。
【請求項】
前記Lフィールドと、前記Dフィールドはそれぞれ1bitを占有し、及び/又は
前記FlowMonID Extフィールドは20bitsを占有し、及び/又は
前記IOAM-Trace-typeフィールドは24bitsを占有する、ことを特徴とする請求項4に記載の方法。
【請求項】
前記検出制御情報フィールドはさらに、
インサイチュフロー検出の周期を示すためのPeriodフィールドを含む、ことを特徴とする請求項3に記載の方法。
【請求項】
前記第1のインサイチュフロー検出オプションと、前記第2のインサイチュフロー検出オプションは、前記検出制御情報フィールド以外、さらに他のフィールドを含み、
前記他のフィールドは少なくとも、
拡張データのタイプが付加されているか否かを示すためのNextHeaderフィールドであって、第1の値である場合、拡張データのタイプが付加されていないことを表し、第2の値である場合、拡張データのタイプが付加されていることを表すNextHeaderフィールドと、
前記NextHeaderフィールドが第2の値である場合、付加されている拡張データを示すための拡張データのタイプTLVsフィールドであって、前記拡張データは少なくとも、サービスパケットが経由するノードの識別子を含む拡張データのタイプTLVsフィールドとを含む、ことを特徴とする請求項2に記載の方法。
【請求項】
前記第2のパケットヘッダは、IPv6拡張ヘッダを含み、
前記第2のインサイチュフロー検出オプションは、前記IPv6拡張ヘッダにおける宛先オプション拡張ヘッダDOHの1つのオプションである、ことを特徴とする請求項1に記載の方法。
【請求項】
電子デバイスであって、プロセッサと機械可読記憶媒体とを含み、
前記機械可読記憶媒体には前記プロセッサによって実行可能な機械実行可能命令が記憶されており、
前記プロセッサは、請求項1~9のいずれか一項の方法のステップを実施するように機械実行可能命令を実行するために用いられる、ことを特徴とする電子デバイス。
【発明の詳細な説明】
【技術分野】
【】
本発明はネットワーク通信技術の分野に関し、特にインサイチュフロー検出方法及び電子デバイス
【背景技術】
【】
インサイチュフロー検出(IOAM:In-situ OAM)とは、通常どおり転送されるサービスパケットを利用して行われるネットワーク検出である。インサイチュフロー検出はネットワークデバイス及びアナライザーが協働して行ってもよく、具体的には以下の方式で実現されてもよい。
【】
入口(Ingress)ノードとしてのネットワークデバイスはサービスパケットに検出制御情報を挿入し、サービスパケット内に挿入された検出制御情報に基づいてデータを収集し、収集されたデータをアナライザーに報告する。伝送ノード(Transmit)又は出口(Egress)ノードとしてのネットワークデバイスはサービスパケット内に挿入された検出制御情報に基づいてデータを収集し、収集されたデータをアナライザーに報告する。アナライザーは、各デバイスから報告された収集データに基づいてネットワーク内の異常を検出・識別することで、各サービスの遅延、パケット損失などの性能を正確に検出し、ネットワーク品質のサービスレベル契約(SLA:Service-Level Agreement)をリアルタイムで視覚化し、迅速な故障の境界付け及び位置特定を実現する。
【】
しかしながら、従来のインサイチュフロー検出は同じネットワークドメイン、例えばSRv6ドメイン、BIERv6ドメインなどに制限され、サービスフローがドメインに跨って転送されると、インサイチュフロー検出を実現することができない。
【発明の概要】
【発明が解決しようとする課題】
【】
本発明の実施例は、クロス転送シナリオにおいてドメインに跨って転送されるサービスパケットに基づいてインサイチュフロー検出を実現するように、インサイチュフロー検出方法及び電子デバイスを提供する。
【課題を解決するための手段】
【】
一実施例として、本発明の実施例は以下の技術案によって実現される。
【】
インサイチュフロー検出方法であって、当該方法は、ネットワークデバイスに適用され、
第1のサービスパケットを受信するステップであって、前記第1のサービスパケットには第1のパケットヘッダが付加されており、前記第1のパケットヘッダは少なくとも第1のインサイチュフロー検出オプションを含み、前記第1のインサイチュフロー検出オプションは第1のネットワークドメインの入口ノードによって前記第1のパケットヘッダに追加され、前記第1のインサイチュフロー検出オプションはインサイチュフロー検出を示すために用いられるステップと、
前記ネットワークデバイスが第2のネットワークドメインの入口ノードである場合、前記第2のネットワークドメイン内で第2のサービスパケットを転送するステップであって、前記第2のサービスパケットは前記第1のサービスパケットの外層を第2のパケットヘッダでカプセル化することによって得られ、前記第2のパケットヘッダには少なくとも第2のインサイチュフロー検出オプションが付加されており、前記第2のインサイチュフロー検出オプションは前記第1のインサイチュフロー検出オプションと同じインサイチュフロー検出方式で同じサービスフローに対してインサイチュフロー検出を行うことを示すために用いられるステップとを含む。
【】
オプションで、前記第2のインサイチュフロー検出オプションは前記第1のインサイチュフロー検出オプションをコピーすることによって得られ、又は、前記第1のインサイチュフロー検出オプションにおける検出制御情報フィールドと、前記第2のインサイチュフロー検出オプションにおける検出制御情報フィールドは同じ検出制御情報を含み、前記検出制御情報は前記サービスフロー及び前記インサイチュフロー検出方式を示すために用いられる。
【】
オプションで、前記検出制御情報フィールドは少なくとも、サービスフローを示すためのFlowMonIDフィールドと、インサイチュフロー検出方式を示すためのインサイチュフロー検出方式フィールドとを含む。
【】
オプションで、前記インサイチュフロー検出方式フィールドは、
パケット損失フラグを示すためのLフィールドと、
遅延フラグを示すためのDフィールドと、
前記第1のネットワークドメインの入口ノードのノード識別子を示すためのFlowMonID Extフィールドと、
インサイチュフロー検出のデータのデータタイプを示すためのIOAM-Trace-typeフィールドとの少なくとも1つのフィールドを含む。
【】
オプションで、前記FlowMonIDフィールドは20bitsを占有する。
【】
オプションで、前記Lフィールドと、前記Dフィールドはそれぞれ1bitを占有する。
【】
オプションで、前記FlowMonID Extフィールドは20bitsを占有する。
【】
オプションで、前記IOAM-Trace-typeフィールドは24bitsを占有する。
【】
オプションで、前記検出制御情報フィールドはさらに、インサイチュフロー検出の周期を示すためのPeriodフィールドを含む。
【】
オプションで、前記第1のインサイチュフロー検出オプションと、前記第2のインサイチュフロー検出オプションは、前記検出制御情報フィールド以外、さらに他のフィールドを含み、前記他のフィールドは少なくとも、拡張データのタイプが付加されているか否かを示すためのNextHeaderフィールドであって、第1の値である場合、拡張データのタイプが付加されていないことを表し、第2の値である場合、拡張データのタイプが付加されていることを表すNextHeaderフィールドと、前記NextHeaderフィールドが第2の値である場合、付加されている拡張データを示すための拡張データのタイプTLVsフィールドであって、前記拡張データは少なくとも、サービスパケットが経由するノードの識別子を含む拡張データのタイプTLVsフィールドとを含む。
【】
オプションで、前記第2のパケットヘッダは、IPv6拡張ヘッダを含み、前記第2のインサイチュフロー検出オプションは、前記IPv6拡張ヘッダにおける宛先オプション拡張ヘッダDOHの1つのオプションである。
【】
本実施例はさらに、電子デバイスを提供し、当該電子デバイスは、プロセッサと機械可読記憶媒体とを含み、
前記機械可読記憶媒体には前記プロセッサによって実行可能な機械実行可能命令が記憶されており、
前記プロセッサは、方法ステップを実施するように機械実行可能命令を実行するために用いられる。
【発明の効果】
【】
本発明の技術案によって、本発明では、第1のサービスパケットが、第1のネットワークドメインから第2のネットワークドメインに跨って転送されるなど、ドメインに跨って転送されても、第2のネットワークドメインの入口ノードが第1のサービスパケットを受信すると、簡単に第2のネットワークドメインに基づいて第1のサービスパケットをカプセル化するのではなく、カプセル化するときにさらに第1のサービスパケットに付加されている第1のインサイチュフロー検出オプションを参照して第1のサービスパケットの外層をカプセル化するパケットヘッダに第2のインサイチュフロー検出オプションを付加し、第2のインサイチュフロー検出オプションに基づいて第2のネットワークドメインでインサイチュフロー検出を行うことを実現し、第1のサービスパケットがドメインに跨って転送されるときのインサイチュフロー検出を実現した。
【図面の簡単な説明】
【】
【図】本発明の実施例により提供される方法のフローチャートである。
【図】本発明の実施例により提供される検出制御情報フィールドの構造図である。
【図】本発明の実施例により提供されるIPv6拡張ヘッダの概略図である。
【図】本発明の実施例により提供されるIPv6基本ヘッダの概略図である。
【図】本発明により提供される実施例1のネットワーキングの概略図である。
【図】本発明の実施例により提供されるインサイチュフロー検出オプションの構造図である。
【図】本発明により提供される実施例2のネットワーキングの概略図である。
【図】本発明により提供される装置の構造図である。
【図】本発明により提供される装置のハードウェア構造図である。
【発明を実施するための形態】
【】
例示的な実施例をここで詳細に説明し、その例示は添付の図面に示される。以下の説明が図面に言及している場合、特に断りのない限り、異なる図面の同じ番号は、同じ又は類似の要素を示す。以下の例示的な実施例に記載の本発明と一致する全ての実施形態を表すわけではない。それどころか、それらは、添付の特許請求の範囲に詳述されているような、本発明のいくつかの態様と一致する装置及び方法の例に過ぎない。
【】
本発明で使用される用語は、特定の実施例を説明するためのものに過ぎず、本発明を限定するものではない。本発明及び添付の特許請求の範囲で使用される単数形「一種」、「前記」及び「当該」は、文脈が明らかに他の意味を示さない限り、複数形も含むことを意図している。
【】
本発明の実施例により提供される技術案を当業者がよりよく理解し、且つ本発明の実施例の上述の目的、特徴及び利点をより理解しやすくするために、以下、添付の図面を合わせて本発明の実施例をさらに詳細に説明する。
【】
図1を参照し、図1は本発明の実施例により提供される方法のフローチャートである。当該方法はネットワークデバイスに適用され、ここでのネットワークデバイスはルータ、スイッチなどであってもよく、本実施例は特に限定しない。
【】
図1に示すように、当該方法は、以下のステップを含み得る。
【】
ステップ101において、ネットワークデバイスは第1のサービスパケットを受信し、第1のサービスパケットには第1のパケットヘッダが付加されており、第1のパケットヘッダは少なくとも第1のインサイチュフロー検出オプションを含み、第1のインサイチュフロー検出オプションは第1のネットワークドメインの入口ノードによって前記第1のパケットヘッダに追加され、第1のインサイチュフロー検出オプションはインサイチュフロー検出を示すために用いられる。
【】
ここで、第1のサービスパケット、第1のパケットヘッダはただ説明しやすくするための命名であり、限定するものではない。本ステップ101において、第1のパケットヘッダは第1のサービスパケットの外層パケットヘッダである。
【】
オプションで、本実施例では、第1のネットワークドメインの入口ノードがオリジナルサービスパケットを受信すると、予め設定されたインサイチュフロー検出方式に基づいてオリジナルサービスパケットがインサイチュフロー検出を行う必要がある目標パケットであるか否かを識別し、オリジナルサービスパケットがインサイチュフロー検出を行う必要がある目標パケットであると識別した場合、オリジナルサービスパケットの外層を第1のインサイチュフロー検出オプションが付加されている外層パケットヘッダ(すなわち第1のパケットヘッダである)でカプセル化する。第1のネットワークドメインの入口ノードがいかにオリジナルサービスパケットの外層を第1のインサイチュフロー検出オプションが付加されている第1のパケットヘッダでカプセル化するかについては、以下、具体的な実施例を通して説明し、ここでは詳細な説明を省略する。
【】
説明の便宜上、ここでは、外層を第1のインサイチュフロー検出オプションが付加されている第1のパケットヘッダでカプセル化されたオリジナルサービスパケットを第1のサービスパケットとして記し、その後、第1のネットワークドメインの入口ノードは第1のネットワークドメインで第1のサービスパケットを転送し、転送プロセス中、ネットワークデバイスは、第1のサービスパケットを受信する可能性があり、第1のサービスパケットを受信すると、ステップ101を実行する。
【】
本実施例では、第1のインサイチュフロー検出オプションはインサイチュフロー検出を示すために用いられ、具体的には、第1のサービスパケットの属するサービスフロー、及びインサイチュフロー検出方式を指示してもよい。オプションで、本実施例では、第1のサービスパケットの属するサービスフローはオリジナルサービスパケットのソースアドレス及び宛先アドレスによってマーキングされてもよい。インサイチュフロー検出方式については、以下、例を挙げて説明し、ここでは詳細な説明を省略する。
【】
ステップ102において、ネットワークデバイスが第2のネットワークドメインの入口ノードである場合、第2のネットワークドメイン内で第2のサービスパケットを転送し、第2のサービスパケットは第1のサービスパケットの外層を第2のパケットヘッダでカプセル化することによって得られ、前記第2のパケットヘッダは少なくとも第2のインサイチュフロー検出オプションを含み、前記第2のインサイチュフロー検出オプションは第1のインサイチュフロー検出オプションと同じインサイチュフロー検出方式で同じサービスフローに対してインサイチュフロー検出を行うことを示すために用いられる。
【】
本ステップ102は、ネットワークデバイスが第2のネットワークドメインの入口ノードであるという前提で実行される。ネットワークデバイスが第2のネットワークドメインの入口ノードである場合に受信された第1のサービスパケットは説明したように、第1のサービスパケットの第1のパケットヘッダには第1のインサイチュフロー検出オプションが付加されている場合、第1のサービスパケットが第1のネットワークドメインから出ていないことを意味し、このとき、第1のサービスパケットがドメインに跨って転送される(すなわち、第1のネットワークドメインから第2のネットワークドメインに跨って転送される)ことを意味する。このような場合、ステップ102に説明したように、ネットワークデバイスは、第1のサービスパケットの外層を外層パケットヘッダでカプセル化する。区別しやすくするために、ここでの第1のサービスパケットの外層をカプセル化する外層パケットヘッダは第2のパケットヘッダと記されてもよい。この場合、ここでの第2のパケットヘッダは外層パケットヘッダであり、第1のサービスパケットに付加されている第1のパケットヘッダは第2のパケットヘッダに比べて、内層パケットヘッダと呼ばれてもよい。区別しやすくするために、この場合、外層を第2のパケットヘッダでカプセル化された第1のサービスパケットを第2のサービスパケットと記しもよい。
【】
本実施例では、第2のパケットヘッダは少なくとも第2のインサイチュフロー検出オプションを含む。第2のインサイチュフロー検出オプションは、第2のネットワークドメインでインサイチュフロー検出を行うことを示すために用いられる。本実施例では、第2のサービスパケットの第2のパケットヘッダには第2のインサイチュフロー検出オプションが付加されると、第2のネットワークドメインの入口ノード(つまりネットワークデバイス)、第2のネットワークドメインで第2のサービスパケットが経由する伝送ノード、第2のネットワークドメインの出口ノードは、第2のインサイチュフロー検出オプションに基づいてインサイチュフロー検出を行う。
【】
本実施例では、第2のインサイチュフロー検出オプション及び第1のインサイチュフロー検出オプションは同じ方式で同じサービスフローに対するインサイチュフロー検出を実現する。これに基づいて、第2のインサイチュフロー検出オプションは前記第1のインサイチュフロー検出オプションと同じインサイチュフロー検出方式で同じサービスフローに対してインサイチュフロー検出を行うことを示すために用いられる。
【】
図1に示すフローによって、第1のサービスパケットが、第1のネットワークドメインから第2のネットワークドメインに跨って転送されるなど、ドメインに跨って転送されても、第2のネットワークドメインの入口ノードが第1のサービスパケットを受信すると、簡単に第2のネットワークドメインに基づいて第1のサービスパケットをカプセル化するのではなく、カプセル化するときにさらに第1のサービスパケットの第1のパケットヘッダに付加されている第1のインサイチュフロー検出オプションに基づいて第1のサービスパケットの外層をカプセル化する外層パケットヘッダに第2のインサイチュフロー検出オプションを付加し、第2のインサイチュフロー検出オプションに基づいて第2のネットワークドメインでインサイチュフロー検出を行うことを実現し、第1のサービスパケットがドメインに跨って転送されるときのインサイチュフロー検出を実現した。
【】
一実施例として、第2のインサイチュフロー検出オプションは第1のインサイチュフロー検出オプションと同じである。オプションで、第2のインサイチュフロー検出オプションは第1のインサイチュフロー検出オプションをコピーすることによって得られてもよい。
【】
別の実施例として、第2のインサイチュフロー検出オプションは第1のインサイチュフロー検出オプションをコピーすることによって得られたものでなくてもよく、第2のインサイチュフロー検出オプションにおける検出制御情報フィールドは少なくとも、第1のインサイチュフロー検出オプションにおける検出制御情報フィールドと同じ検出制御情報を含めばよい。ここで、検出制御情報はサービスフロー及びインサイチュフロー検出方式を示すために用いられる。
【】
オプションで、本実施例では、検出制御情報フィールドは少なくとも、FlowMonIDフィールドと、インサイチュフロー検出方式フィールドとを含む。
【】
ここで、FlowMonIDフィールドはサービスフローを示すために用いられる。オプションで、FlowMonIDフィールドは20bitsを占有してもよい。ここで、1つのサービスフローは、ソースアドレスと宛先アドレスを合わせて表されてもよい。
【】
インサイチュフロー検出方式フィールドは、インサイチュフロー検出方式を示すために用いられる。本実施例では、インサイチュフロー検出方式フィールドは、Lフィールドと、Dフィールドと、FlowMonID Extフィールドと、IOAM-Trace-typeフィールドとの少なくとも1つのフィールドを含む。
【】
ここで、Lフィールドはパケット損失フラグを示すために用いられる。例えば、パケット損失フラグの値が数値1例えば0である場合、パケット損失検出を実行することを示し、パケット損失フラグの値が数値2例えば1である場合、パケット損失検出を実行しないことを示す。オプションで、本実施例では、Lフィールドは1bitを占有する。
【】
Dフィールドは遅延フラグを示すために用いられる。例えば、遅延フラグの値が数値3例えば0である場合、遅延検出を実行することを示し、遅延フラグの値が数値4例えば1である場合、遅延検出を実行しないことを示す。オプションで、本実施例では、Dフィールドは1bitを占有する。
【】
FlowMonID Extフィールドは第1のネットワークドメインの入口ノードのノード識別子を示すために用いられる。オプションで、FlowMonID Extフィールドは20bitsを占有する。
【】
IOAM-Trace-typeフィールドはインサイチュフロー検出のデータのデータタイプを示すために用いられる。オプションで、IOAM-Trace-typeフィールドは24bitsを占有し、各bitは1つのデータタイプを表し、例えばインサイチュフロー検出が遅延検出に用いられることを例とすると、このようなデータタイプは、パケットを受信するタイムスタンプ情報、パケットカウント情報などを含み得る。
【】
図2は、インサイチュフロー検出方式フィールドがLフィールドと、Dフィールドと、FlowMonID Extフィールドと、IOAM-Trace-typeフィールドとを含むことを例として検出制御情報フィールドの構造を示す。
【】
一実施例として、検出制御情報フィールドはさらに、Periodフィールドを含み得る。ここで、Periodフィールドは、インサイチュフロー検出の周期を示すために用いられる。一実施例として、Periodフィールドは8bitsを占有する。またインサイチュフロー検出が遅延検出に用いられることを例とすると、パケットカウント情報は1つの周期内のパケットカウント情報を意味する。
【】
オプションで、一実施例として、第1のインサイチュフロー検出オプションと、第2のインサイチュフロー検出オプションは、検出制御情報フィールド以外、さらに他のフィールドを含み得る。例えば、他のフィールドは、NextHeaderフィールド、拡張データのタイプTLVsフィールドなどである。
【】
ここで、NextHeaderフィールドは、拡張データのタイプが付加されているか否かを示すために用いられ、第1の値である場合、拡張データのタイプが付加されていないことを表し、第2の値である場合、拡張データのタイプが付加されていることを表す。
【】
拡張データのタイプTLVsフィールドは、NextHeaderフィールドが第2の値である場合、付加されている拡張データを示すために用いられ、拡張データは少なくとも、パケットが経由するノードの識別子を含む。
【】
IPv6に適用されるシナリオでは、第2のパケットヘッダは、IPv6拡張ヘッダ(Extension Header)を含み得る。図3はIPv6拡張ヘッダの構造を例示する。一実施例として、第2のインサイチュフロー検出オプションは、IPv6拡張ヘッダにおける宛先オプション拡張ヘッダ(DOH:Destination Option Header)の1つのオプションである。
【】
一実施例として、第1のサービスパケットがユニキャストパケットで、第2のネットワークドメインがIPv6セグメントルーティング(SR:Segment Routing)に基づくと仮定すると、IPv6拡張ヘッダはさらに、セグメントルーティング拡張ヘッダ(SRH:Segment Routing Header)を含む。本実施例では、ホップバイホップインサイチュフロー検出を実行する場合、IPv6拡張ヘッダにおいて、DOHはSRHの前にある。エンドツーエンドインサイチュフロー検出を実行する場合、IPv6拡張ヘッダにおいて、DOHはSRHの後にある。本実施例では、SRHには、第2のサービスパケットの第2のネットワークドメインで転送されるパス情報が付加されており、その構造は、既存のSRHのカプセル化形式に類似している。
【】
なお、本実施例では、オプションで、第2のパケットヘッダはさらに、IPv6ヘッダ(Header)を含む。ここでのIPv6ヘッダはIPv6拡張ヘッダと異なる。IPv6拡張ヘッダに対して、ここでのIPv6ヘッダはIPv6基本ヘッダと記されてもよく、その構造は図4に示すとおりである。一例では、第2のパケットヘッダにおいて、IPv6基本ヘッダはIPv6拡張ヘッダの前にある。以下、図5に示される一実施例を通してユニキャストパケットのインサイチュフロー検出を例示する。
【】
別の実施例として、第1のサービスパケットがマルチキャストパケットで、第2のネットワークドメインの入口ノードがビットインデックス明示的複製(BIER:Bit Indexed Explicit Replication)をサポートし、第2のネットワークドメインがBIERドメインであると仮定すると、IPv6拡張ヘッダはさらにBIERパケットヘッダを含む。
【】
BIERはビットインデックス明示的複製に基づく新規マルチキャスト技術であり、当該技術はマルチキャストディストリビューションツリーを明示的に構築する必要がなく、中間ノードがいかなるマルチキャストフローの状態を保存する必要もない。BIER機能を有するルータはビット転送ルータ(BFR:Bit-Forwarding Router)と呼ばれ、BFRからなるドメインはBIERドメインと呼ばれ、BIERドメインにおいてエッジに位置するBFRはそれぞれBFIR及びBFERと呼ばれる。BIERドメイン内のBFRは制御プレーンプロトコル(control plane protocol)を実行することにより、BFRの識別子、位置するBIERサブドメイン及びBIER転送能力などの情報を交換し、これらの情報に基づいてビットインデックス転送ルーティングテーブル(BIFT:Bit Index Forwarding Table)を計算して生成する。BIFTは転送ビット列マスクF-BM及びBFRネイバー(BFR neighbors)からなり、F-BMの各ビットはBIERドメイン内の唯一のBFRを表し、当該情報はBFRの識別子BFR-idによって定義される。マルチキャストパケットがBIERドメインに入ると、BFIRはBIERドメインにおける当該マルチキャストパケットのBFERセットを決定し、そしてマルチキャストパケットをBIERパケットヘッダでカプセル化し、マルチキャストパケットがBFERに到達するとき、BFERは外層のBIERヘッダを取り除き、マルチキャストパケットに復元し、マルチキャストパケットの転送を実行し続ける。以下、図7に示される実施例を通してマルチキャストパケット転送を説明し、ここでは詳細な説明を省略する。
【】
本実施例では、BIERパケットヘッダにはBFERセットが付加されている。オプションで、本実施例では、BFERセットはビット列(BitString)で表されてもよく、ここで、BitStringにおける、1に設定されているビットは、対応するBFERを示す。
【】
一実施例として、BIERパケットヘッダはDOHにおける別のオプションであってもよい。オプションで、本実施例では、ホップバイホップインサイチュフロー検出を実行する場合、DOHにおいて、第2のインサイチュフロー検出オプションはBIERパケットヘッダの前にあってもよい。エンドツーエンドインサイチュフロー検出を実行する場合、DOHにおいて、第2のインサイチュフロー検出オプションはBIERパケットヘッダの後にある。
【】
以下、2つの実施例を組み合わせて図1に示すフローについて説明する。
【】
実施例1:図5を参照し、図5は本発明により提供される実施例1のネットワーキングの概略図である。本実施例は、SRv6ユニキャストパケットがドメインに跨って転送されるときのインサイチュフロー検出を例とする。
【】
図5に示すように、第1のSRv6ドメインにおける入口ノードとしてのデバイスA1がオリジナルSRv6ユニキャストパケット(パケット501と記される)を受信すると、ソースアドレス、宛先アドレスなどのパケット特徴を解析し、解析されたパケット特徴に基づいて、予め設定されたインサイチュフロー検出の識別方式でパケット501がインサイチュフロー検出を行う必要があると識別した場合、パケット501の外層をパケットヘッダ(第1のパケットヘッダと記される)でカプセル化する。カプセル化に用いる第1のパケットヘッダはIPv6基本ヘッダ及びIPv6拡張ヘッダを含み得る。ここで、IPv6拡張ヘッダは少なくともDOHとSRHとを含む。ここで、DOHには、インサイチュフロー検出に用いられる1つのオプションが追加されており、第1のインサイチュフロー検出オプションと記される。オプションで、インサイチュフロー検出オプションの構造に基づいて、図6は第1のインサイチュフロー検出オプションの構造を例示する。なお、IPv6基本ヘッダ及びSRHは既存のカプセル化方式に類似し、詳細な説明を省略する。本実施例は、ホップバイホップでインサイチュフロー検出を行うことを例とすると、IPv6拡張ヘッダにおいて、DOHはSRHの前にあってもよい。
【】
図5に示す実施例では、デバイスA1が第1のインサイチュフロー検出オプションにおけるIOAM-Trace-typeフィールドに指示されるデータタイプに基づいて、パケット受信タイムスタンプ、パケットカウントなどの対応するデータを取得し、取得されたデータをアナライザーに報告する。
【】
説明の便宜上、第1のパケットヘッダでカプセル化されたパケット501をパケット502として記す。
【】
その後、デバイスA1はパケット502に付加されているSRHにおけるパス情報に基づいてパケット502をデバイスB1に転送する。
【】
デバイスB1がパケット502を受信すると、パケット502のDOHに第1のインサイチュフロー検出オプションが付加されていると識別した場合、第1のインサイチュフロー検出オプションにおけるIOAM-Trace-typeフィールドに指示されるデータタイプに基づいて、パケット受信タイムスタンプ、パケットカウントなどの対応するデータを取得し、取得されたデータをアナライザーに報告する。その後、デバイスB1はパケット502に付加されているSRHにおけるパス情報に基づいてパケット502をデバイスC1に転送する。
【】
図5に示すように、デバイスC1が第2のSRv6ドメインの入口ノードであり、デバイスC1がパケット502を受信すると、パケット502のDOHに第1のインサイチュフロー検出オプションが付加されていると識別した場合、第1のインサイチュフロー検出オプションにおけるIOAM-Trace-typeフィールドに指示されるデータタイプに基づいて、パケット受信タイムスタンプ、パケットカウントなどの対応するデータを取得し、取得されたデータをアナライザーに報告する。その後、デバイスC1はパケット502の外層をパケットヘッダ(第2のパケットヘッダと記される)でカプセル化する。カプセル化に用いる第2のパケットヘッダはIPv6基本ヘッダ及びIPv6拡張ヘッダを含み得る。
【】
本実施例では、第2のパケットヘッダにおけるIPv6拡張ヘッダは少なくともDOHとSRHとを含む。ここで、DOHには、インサイチュフロー検出に用いられる1つのオプションが追加されており、第2のインサイチュフロー検出オプションと記される。オプションで、第2のインサイチュフロー検出オプションは第1のインサイチュフロー検出オプションをコピーすることによって得られてもよく、又は、第2のインサイチュフロー検出オプションにおける検出制御情報フィールドに含まれる検出制御情報は第1のインサイチュフロー検出オプションにおける検出制御情報フィールドに含まれる検出制御情報と同じであってもよく、第2のインサイチュフロー検出オプションの構造は図6に示される第1のインサイチュフロー検出オプションの構造と類似する。説明の便宜上、第2のパケットヘッダでカプセル化されたパケット502をパケット503として記す。なお、外層パケットヘッダにおけるIPv6基本ヘッダ及びSRHは既存のカプセル化方式に類似し、詳細な説明を省略する。
【】
その後、デバイスC1はパケット503に付加されているSRHにおけるパス情報に基づいてパケット503をデバイスD1に転送する。
【】
デバイスD1がパケット503を受信すると、パケット503のDOHに第2のインサイチュフロー検出オプションが付加されていると識別した場合、第2のインサイチュフロー検出オプションにおけるIOAM-Trace-typeフィールドに示されるデータタイプに基づいて、パケット受信タイムスタンプ、パケットカウントなどの対応するデータを取得し、取得されたデータをアナライザーに報告する。その後、デバイスD1はパケット503に付加されているSRHにおけるパス情報に基づいてパケット503をデバイスE1に転送する。
【】
デバイスE1が第2のSRv6ドメインの出口ノードとして、パケット503を受信すると、パケット503のDOHに第2のインサイチュフロー検出オプションが付加されていると識別した場合、第2のインサイチュフロー検出オプションにおけるIOAM-Trace-typeフィールドに示されるデータタイプに基づいて、パケット受信タイムスタンプ、パケットカウントなどの対応するデータを取得し、取得されたデータをアナライザーに報告する。その後、デバイスE1はパケット503の第2のパケットヘッダを取り除いてパケット502に復元し、パケット502に付加されているSRHにおけるパス情報に基づいてパケット502をデバイスF1に転送する。
【】
デバイスF1は第1のSRv6ドメインの出口ノードとして、パケット502を受信すると、パケット502のDOHに第1のインサイチュフロー検出オプションが付加されていると識別した場合、第1のインサイチュフロー検出オプションにおけるIOAM-Trace-typeフィールドに示されるデータタイプに基づいて、パケット受信タイムスタンプ、パケットカウントなどの対応するデータを取得し、取得されたデータをアナライザーに報告する。その後、デバイスF1はパケット502の内層パケットヘッダを取り除いてパケット502に復元し、パケット501を転送し続ける。
【】
アナライザーについては、デバイスA1~デバイスF1から報告されたデータを受信すると、従来の検出方式でパケット501の属するサービスフローのパス全体の転送性能データをまとめて決定する。本実施例は、アナライザーがサービスフローのパス全体の転送性能データをいかに決定するかを具体的に限定せず、従来の決定方式を参照してもよい。
【】
実施例1から分かるように、SRv6ユニキャストパケットが第1のSRv6ドメインから第2のSRv6ドメインに跨って転送されても、第2のSRv6ドメインの入口ノード例えばデバイスC1は、第1のSRv6ドメインからのSRv6ユニキャストパケット例えばパケット502を受信すると、簡単に第2のSRv6ドメインに基づいてSRv6ユニキャストパケット例えばパケット502の外層をカプセル化するのではなく、カプセル化するときにさらにパケット502に付加されている第1のインサイチュフロー検出オプションを参照して、SRv6ユニキャストパケット例えばパケット502の外層を、少なくとも第2のインサイチュフロー検出オプションが付加されている外層パケットヘッダでカプセル化し、最終的に第2のSRv6ドメインにおけるノードは外層パケットヘッダに付加されている第2のインサイチュフロー検出オプションに基づいてインサイチュフロー検出を行い、SRv6ユニキャストパケットがドメインに跨って転送されるときのインサイチュフロー検出を実現した。
【】
はSRv6ユニキャストパケットがドメインに跨って転送されることを例として実施例1を通して説明したが、以下、SRv6マルチキャストパケットを例として実施例2を通して説明する。
【】
実施例2:図7を参照し、図7は本発明により提供される実施例2のネットワーキングの概略図である。本実施例は、SRv6マルチキャストパケットがメインに跨って転送されるときのインサイチュフロー検出を例とする。
【】
図7に示すように、デバイスA2がBIERドメインの入口ノードとして、オリジナルSRv6マルチキャストパケット(パケット701と記される)を受信すると、ソースアドレス、宛先アドレスなどのパケット特徴を解析し、解析されたパケット特徴に基づいて、予め設定されたインサイチュフロー検出の識別方式でパケット701がインサイチュフロー検出を行う必要があると識別した場合、パケット701の外層を外層パケットヘッダ(第1のパケットヘッダと記される)でカプセル化する。カプセル化に用いる第1のパケットヘッダはIPv6基本ヘッダ及びIPv6拡張ヘッダを含み得る。IPv6拡張ヘッダにおけるDOHは2つのオプションを含み、その1つのオプションはインサイチュフロー検出に用いられ、第1のインサイチュフロー検出オプションと記され、もう1つのオプションはBIERパケットヘッダである。本実施例におけるインサイチュフロー検出はホップバイホップインサイチュフロー検出であると仮定すると、DOHにおいて、第1のインサイチュフロー検出オプションはBIERパケットヘッダの前にあり、図7は第1のインサイチュフロー検出オプション及びBIERパケットヘッダのDOHにおける位置の順序を例示する。なお、IPv6基本ヘッダ及びIPv6拡張ヘッダは既存のカプセル化方式に類似し、詳細な説明を省略する。BIERパケットヘッダにはBFERセットが付加されており、BFERセットは、パケット701がBIERドメインから出るときの出口ノードのセットである。
【】
図7に示す実施例では、デバイスA2が第1のインサイチュフロー検出オプションにおけるIOAM-Trace-typeフィールドに指示されるデータタイプに基づいて、パケット受信タイムスタンプ、パケットカウントなどの対応するデータを取得し、取得されたデータをアナライザーに報告する。
【】
説明の便宜上、第1のパケットヘッダでカプセル化されたパケット701をパケット702として記す。
【】
その後、デバイスA2はパケット702に付加されているBIERパケットヘッダにおけるBFERセットに基づいてパケット702をデバイスB2に転送する。
【】
デバイスB2がパケット702を受信すると、パケット702のDOHに第1のインサイチュフロー検出オプションが付加されていると識別した場合、第1のインサイチュフロー検出オプションにおけるIOAM-Trace-typeフィールドに指示されるデータタイプに基づいて、パケット受信タイムスタンプ、パケットカウントなどの対応するデータを取得し、取得されたデータをアナライザーに報告する。その後、デバイスB2はパケット702に付加されているBIERパケットヘッダにおけるBFERセットに基づいてパケット702をデバイスC2に転送する。
【】
図7に示すように、デバイスC2がSRv6ドメインの入口ノードであり、デバイスC2がパケット702を受信すると、パケット702のDOHに第1のインサイチュフロー検出オプションが付加されていると識別した場合、第1のインサイチュフロー検出オプションにおけるIOAM-Trace-typeフィールドに指示されるデータタイプに基づいて、パケット受信タイムスタンプ、パケットカウントなどの対応するデータを取得し、取得されたデータをアナライザーに報告する。その後、デバイスC2はパケット702の外層を外層パケットヘッダ(第2のパケットヘッダと記される)でカプセル化する。カプセル化に用いる第2のパケットヘッダはIPv6基本ヘッダ及びIPv6拡張ヘッダを含み得る。
【】
本実施例では、第2のパケットヘッダにおけるIPv6拡張ヘッダはDOHとSRHとを含む。ここで、DOHには、インサイチュフロー検出に用いられる1つのオプションが追加されており、第2のインサイチュフロー検出オプションと記される。オプションで、第2のインサイチュフロー検出オプションは第1のインサイチュフロー検出オプションをコピーすることによって得られてもよく、又は、第2のインサイチュフロー検出オプションにおける検出制御情報フィールドに含まれる検出制御情報は第1のインサイチュフロー検出オプションにおける検出制御情報フィールドに含まれる検出制御情報と同じであってもよい。説明の便宜上、新たなパケットヘッダでカプセル化されたパケット702をパケット703として記す。SRHには、パケット703がSRv6ドメインで転送されるパス情報が付加されている。なお、外層パケットヘッダにおけるIPv6基本ヘッダ及びSRHは既存のカプセル化方式に類似し、詳細な説明を省略する。
【】
その後、デバイスC2はパケット703に付加されているSRHにおけるパス情報に基づいてパケット703をデバイスD2に転送する。
【】
デバイスD2がパケット703を受信すると、パケット703のDOHに第2のインサイチュフロー検出オプションが付加されていると識別した場合、第2のインサイチュフロー検出オプションにおけるIOAM-Trace-typeフィールドに指示されるデータタイプに基づいて、パケット受信タイムスタンプ、パケットカウントなどの対応するデータを取得し、取得されたデータをアナライザーに報告する。その後、デバイスD2はパケット703に付加されているSRHにおけるパス情報に基づいてパケット703をデバイスE2に転送する。
【】
デバイスE2がSRv6ドメインの出口ノードとして、パケット703を受信すると、パケット703のDOHに第2のインサイチュフロー検出オプションが付加されていると識別した場合、第2のインサイチュフロー検出オプションにおけるIOAM-Trace-typeフィールドに指示されるデータタイプに基づいて、パケット受信タイムスタンプ、パケットカウントなどの対応するデータを取得し、取得されたデータをアナライザーに報告する。その後、デバイスE2はパケット703の第2のパケットヘッダを取り除いてパケット702に復元し、パケット702に付加されているBIERパケットヘッダにおけるBFERセットに基づいてパケット702をデバイスF2に転送する。
【】
デバイスF2はBIERドメインの出口ノードとして、パケット702を受信すると、パケット702のDOHに第1のインサイチュフロー検出オプションが付加されていると識別した場合、第1のインサイチュフロー検出オプションにおけるIOAM-Trace-typeフィールドに指示されるデータタイプに基づいて、パケット受信タイムスタンプ、パケットカウントなどの対応するデータを取得し、取得されたデータをアナライザーに報告する。その後、デバイスF2はパケット702のパケットヘッダを取り除いてパケット701に復元し、パケット701を転送し続ける。
【】
アナライザーについては、デバイスA2~デバイスF2から報告されたデータを受信すると、従来の検出方式でパケット701の属するサービスフローのパス全体の転送性能データをまとめて決定する。本実施例は、アナライザーがサービスフローのパス全体の転送性能データをいかに決定するかを具体的に限定せず、従来の決定方式を参照してもよい。
【】
実施例2から分かるように、SRv6マルチキャストパケットがBIERドメインからSRv6ドメインに跨って転送されても、SRv6ドメインの入口ノード例えばデバイスC2は、BIERドメインからのSRv6マルチキャストパケット例えばパケット702を受信すると、簡単にSRv6ドメインに基づいて受信されたSRv6マルチキャストパケット例えばパケット702の外層をカプセル化するのではなく、カプセル化するときにさらにSRv6マルチキャストパケット例えばパケット702に付加されている第1のインサイチュフロー検出オプションを参照して、SRv6マルチキャストパケット例えばパケット702の外層を、少なくとも第2のインサイチュフロー検出オプションを含む外層パケットヘッダでカプセル化し、最終的にSRv6ドメインにおけるノードは外層パケットヘッダに付加されている第2のインサイチュフロー検出オプションに基づいてインサイチュフロー検出を行い、SRv6マルチキャストパケットがドメインに跨って転送されるときのインサイチュフロー検出を実現した。
【】
以上、本発明の実施例により提供される方法について説明したが、以下、本発明の実施例により提供される装置について説明する。
【】
図8を参照し、図8は本発明の実施例により提供される装置の構造図である。当該装置はネットワークデバイスに適用され、図8に示すように、当該装置は、
第1のサービスパケットを受信するための受信ユニットであって、前記第1のサービスパケットには第1のパケットヘッダが付加されており、前記第1のパケットヘッダは少なくとも第1のインサイチュフロー検出オプションを含み、前記第1のインサイチュフロー検出オプションは第1のネットワークドメインの入口ノードによって前記第1のパケットヘッダに追加され、前記第1のインサイチュフロー検出オプションはインサイチュフロー検出を示すための受信ユニットと、
前記ネットワークデバイスが第2のネットワークドメインの入口ノードである場合、前記第2のネットワークドメイン内で第2のサービスパケットを転送するためのクロスドメイン転送ユニットであって、前記第2のサービスパケットは前記第1のサービスパケットの外層を第2のパケットヘッダでカプセル化することによって得られ、前記第2のパケットヘッダは少なくとも第2のインサイチュフロー検出オプションを含み、前記第2のインサイチュフロー検出オプションは前記第1のインサイチュフロー検出オプションと同じインサイチュフロー検出方式で同じサービスフローに対してインサイチュフロー検出を行うことを示すために用いられるクロスドメイン転送ユニットとを含み得る。
【】
オプションで、本実施例では、前記第2のインサイチュフロー検出オプションは前記第1のインサイチュフロー検出オプションをコピーすることによって得られ、又は、前記第1のインサイチュフロー検出オプションにおける検出制御情報フィールドと、前記第2のインサイチュフロー検出オプションにおける検出制御情報フィールドは同じ検出制御情報を含み、前記検出制御情報は前記サービスフロー及び前記インサイチュフロー検出方式を示すために用いられる。
【】
オプションで、本実施例では、前記検出制御情報フィールドは少なくとも、
サービスフローを示すためのFlowMonIDフィールドと、
インサイチュフロー検出方式を示すためのインサイチュフロー検出方式フィールドとを含む。
【】
ここで、インサイチュフロー検出方式フィールドは、
パケット損失フラグを示すためのLフィールドと、
遅延フラグを示すためのDフィールドと、
前記第1のネットワークドメインの入口ノードのノード識別子を示すためのFlowMonID Extフィールドと、
インサイチュフロー検出のデータのデータタイプを示すためのIOAM-Trace-typeフィールドとの少なくとも1つのフィールドを含む。
【】
オプションで、本実施例では、FlowMonIDフィールドは20bitsを占有する。
【】
オプションで、本実施例では、Lフィールドと、Dフィールドはそれぞれ1bitを占有する。
【】
オプションで、本実施例では、FlowMonID Extフィールドは20bitsを占有する。
【】
オプションで、本実施例では、IOAM-Trace-typeフィールドは24bitsを占有する。
【】
オプションで、本実施例では、検出制御情報フィールドはさらに、
インサイチュフロー検出の周期を示すためのPeriodフィールドを含む。
【】
オプションで、本実施例では、第1のインサイチュフロー検出オプションと、第2のインサイチュフロー検出オプションは、検出制御情報フィールド以外、さらに他のフィールドを含み、他のフィールドは少なくとも、
拡張データのタイプが付加されているか否かを示すためのNextHeaderフィールドであって、第1の値である場合、拡張データのタイプが付加されていないことを表し、第2の値である場合、拡張データのタイプが付加されていることを表すNextHeaderフィールドと、
NextHeaderフィールドが第2の値である場合、付加されている拡張データを示すための拡張データのタイプTLVsフィールドであって、拡張データは少なくとも、サービスパケットが経由するノードの識別子を含む拡張データのタイプTLVsフィールドとを含む。
【】
オプションで、本実施例では、第2のパケットヘッダは、IPv6拡張ヘッダを含む。ここで、第2のインサイチュフロー検出オプションは、IPv6拡張ヘッダにおけるDOHの1つのオプションである。
【】
オプションで、本実施例では、DOHはさらに別のオプションを含み、別のオプションはビットインデックス明示的複製BIERパケットヘッダであり、BIERパケットヘッダには、第2のサービスパケットの第2のネットワークドメインで転送される転送情報が付加されている。ホップバイホップインサイチュフロー検出を実行する場合、DOHにおいて、第2のインサイチュフロー検出オプションはBIERパケットヘッダの前にある。エンドツーエンドインサイチュフロー検出を実行する場合、DOHにおいて、第2のインサイチュフロー検出オプションはBIERパケットヘッダの後にある。
【】
オプションで、本実施例では、前記IPv6拡張ヘッダはさらにSRHを含み、SRHには、第2のサービスパケットの第2のネットワークドメインで転送されるパス情報が付加されている。オプションで、ホップバイホップインサイチュフロー検出を実行する場合、IPv6拡張ヘッダにおいて、DOHはSRHの前にある。エンドツーエンドインサイチュフロー検出を実行する場合、IPv6拡張ヘッダにおいて、DOHはSRHの後にある。
【】
ここまで、図8に示す装置の構造の説明を完了する。
【】
本発明の実施例はさらに図8に示す装置のハードウェア構造を提供する。図9を参照し、図9は本発明の実施例により提供される電子デバイスの構造図である。図9に示すように、当該ハードウェア構造は、プロセッサと機械可読記憶媒体とを含み得、機械可読記憶媒体には前記プロセッサによって実行可能な機械実行可能命令が記憶されており、前記プロセッサは、本発明の例示に開示された方法を実施するように機械実行可能命令を実行するために用いられる。
【】
方法と同様の出願思想に基づき、本発明の実施例はさらに、いくつかのコンピュータ命令が記憶されている機械可読記憶媒体を提供し、前記コンピュータ命令がプロセッサに実行されると、本発明の例示に開示された方法を実施することができる。
【】
例示的に、機械可読記憶媒体は任意の電子的、磁性的、光学的又は他の物理的記憶装置であってもよく、実行可能な命令、データなどの情報を含むか、又は記憶することができるものである。例えば、機械可読記憶媒体は、RAM(Radom Access Memory、ランダムアクセスメモリ)、揮発性メモリ、不揮発性メモリ、フラッシュメモリ、ストレージドライブ(ハードドライブなど)、ソリッドステートドライブ、任意の記憶ディスク(光ディスク、dvdなど)、又は類似の記憶媒体や、これらの組み合わせなどが挙げられる。
【】
実施例で説明したシステム、装置、モジュール又はユニットは、具体的には、コンピュータチップ、エンティティ、又は何らかの機能を有する製品によって実現されてもよい。典型的な実現デバイスはコンピュータであり、コンピュータの具体的な形態はパーソナルコンピュータ、ラップトップコンピュータ、携帯電話、カメラ付き電話、スマートフォン、パーソナルデジタルアシスタント、メディアプレーヤ、ナビゲーションデバイス、電子メール送受信デバイス、ゲーム機、タブレット、ウェアラブルデバイス、又はこれらのデバイスの任意のいくつかの組み合わせであってもよい。
【】
説明の便宜上、の装置を説明するときに機能によって様々なユニットに分けてそれぞれ説明する。もちろん、本発明を実施する際に、各ユニットの機能を同一又は複数のソフトウェア及び/又はハードウェアで実現することも可能である。
【】
当業者であれば分かるように、本発明の実施例が、方法、システム、又はコンピュータプログラム製品として提供されてもよい。したがって、本発明は、ハードウェアだけからなる実施例、ソフトウェアだけからなる実施例、又はソフトウェアとハードウェアを組み合わせた実施例なる形態を用いてもよい。さらに、本発明の実施例は、コンピュータで使用可能なプログラムコードを含む1つ又は複数のコンピュータで使用可能な記憶媒体(磁気ディスクメモリ、CD-ROM、光学メモリなどを含むが、これらに限定されない)において実施されるコンピュータプログラム製品の形態であってもよい。
【】
本発明は、本発明の実施例による方法、デバイス(システム)、及びコンピュータプログラム製品のフローチャート及び/又はブロック図を参照して説明される。フローチャート及び/又はブロック図における各フロー及び/又はブロック、並びにフローチャート及び/又はブロック図におけるフロー及び/又はブロックの組み合わせは、コンピュータプログラム命令によって実現されてもよいことが理解されるべきである。これらのコンピュータプログラム命令は、マシンを生成するために、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、又は他のプログラム可能なデータ処理デバイスのプロセッサに提供されてもよく、それにより、コンピュータ又は他のプログラム可能なデータ処理デバイスのプロセッサによって実行される命令により、フローチャートの1つ又は複数のフロー、及び/又はブロック図の1つ又は複数のブロックにおいて指定される機能を実現するための装置が生成される。
【】
また、これらのコンピュータプログラム命令は、コンピュータ又は他のプログラム可能なデータ処理デバイスに特定の方法で作業することを示すことができるコンピュータ可読メモリに記憶されてもよく、その結果、当該コンピュータ可読メモリに記憶されている命令により、フローチャートの1つ又は複数のフロー及び/又はブロック図の1つ又は複数のブロックにおいて指定される機能を実現する命令装置を含む製品が生成される。
【】
これらのコンピュータプログラム命令は、コンピュータ又は他のプログラム可能なデータ処理デバイスにロードしてもよく、それにより、一連の動作ステップがコンピュータ又は他のプログラム可能なデバイス上で実行されることで、コンピュータにより実施される処理が生成され、それにより、コンピュータ又は他のプログラム可能なデバイス上で実行される命令により、フローチャートの1つ又は複数のフロー、及び/又はブロック図の1つ又は複数のブロック内で指定される機能を実現するためのステップが提供される。
【】
は、本発明の実施例にすぎず、本発明を限定するために使用されるものではない。当業者にとって、本発明は、様々な変更及び変化があり得る。本発明の趣旨と原理から逸脱することなく修正、同等な置換、改善などを行った場合、いずれも本発明の特許請求の範囲に含まれるものとするべきである。
【図】
【図】
【図】
【図】
【図】
【図】
【図】
【図】
【図】
【手続補正書】
【提出日】
【手続補正】
【補正対象書類名】図面
【補正対象項目名】図7
【補正方法】変更
【補正の内容】
【図】
【国際調査報告】

[広告欄]

ログインすれば広告は減ります

ログインすれば広告は減ります