知財求人 - 知財ポータルサイト「IP Force」
▶ 中国移動通信有限公司研究院の特許一覧 ▶ 中国移動通信集団有限公司の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-09-10
(54)【発明の名称】メッセージ送信方法、装置及び記憶媒体
(51)【国際特許分類】
H04L 69/16 20220101AFI20240903BHJP
H04L 69/22 20220101ALI20240903BHJP
【ＦＩ】
H04L69/16
H04L69/22
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024510361
(86)(22)【出願日】2022-08-02
(85)【翻訳文提出日】2024-02-19
(86)【国際出願番号】 CN2022109673
(87)【国際公開番号】W WO2023020273
(87)【国際公開日】2023-02-23
(31)【優先権主張番号】202110953970.3
(32)【優先日】2021-08-19
(33)【優先権主張国・地域又は機関】CN
(81)【指定国・地域】
(71)【出願人】
【識別番号】518389015
【氏名又は名称】中国移動通信有限公司研究院
【氏名又は名称原語表記】Ｃｈｉｎａ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｏ．， Ｌｔｄ Ｒｅｓｅａｒｃｈ Ｉｎｓｔｉｔｕｔｅ
【住所又は居所原語表記】３２ Ｘｕａｎｗｕｍｅｎ Ｗｅｓｔ Ｓｔｒｅｅｔ， Ｘｉｃｈｅｎｇ Ｄｉｓｔｒｉｃｔ， Ｂｅｉｊｉｎｇ １０００５３， Ｃｈｉｎａ
(71)【出願人】
【識別番号】518301095
【氏名又は名称】中国移動通信集団有限公司
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】程 ▲偉▼▲強▼
(72)【発明者】
【氏名】▲楊▼ 雪
(72)【発明者】
【氏名】姜 文▲頴▼
(72)【発明者】
【氏名】▲劉▼ 毅松
(72)【発明者】
【氏名】▲ゴン▼ 立▲艶▼
(57)【要約】
本願は、メッセージ送信方法、装置及び記憶媒体を開示しており、当該方法は、メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信することと、メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせることと、前記メッセージを送信することとを含む。本願を用いれば、従来のホップバイホップ処理機能をサポートすることに加えて、転送プレーンでメッセージ情報をホップバイホップ処理する能力もサポートすることができ、この機能によれば、スライスやインサイチュフロー検出等の新しいテクノロジのニーズを更に満たすことができる。制御プレーンへの送り識別子が改竄されたり、ハッカーによってネットワークノードへの攻撃を引き起こすために利用されたりすることを効果的に防止可能である。
【特許請求の範囲】
【請求項1】
メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信することと、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせることと、
前記メッセージを送信することとを含む、メッセージ送信方法。
【請求項2】
前記メッセージは、インターネットプロトコルバージョン６（ＩＰｖ６）メッセージである、請求項１に記載の方法。
【請求項3】
前記メッセージの拡張ヘッダは、ＩＰｖ６メッセージ拡張ヘッダホップバイホップオプションヘッダ（Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒ）である、請求項２に記載の方法。
【請求項4】
メッセージ拡張ヘッダにチェックサム（ＣｈｅｃｋＳｕｍ）をキャリーさせることを更に含む、請求項１～３の何れか一項に記載の方法。
【請求項5】
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせることを更に含む、請求項４に記載の方法。
【請求項6】
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含む、請求項５に記載の方法。
【請求項7】
メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信することと、制御プレーンへの送り識別子に応じて、前記メッセージを制御プレーン又は転送プレーンに渡して処理させることとを含む、メッセージ送信方法。
【請求項8】
前記メッセージは、ＩＰｖ６メッセージである、請求項７に記載の方法。
【請求項9】
前記メッセージの拡張ヘッダは、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒである、請求項８に記載の方法。
【請求項10】
メッセージ拡張ヘッダに第一ＣｈｅｃｋＳｕｍをキャリーさせていることを更に含む、請求項７～９の何れか一項に記載の方法。
【請求項11】
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせていることを更に含む、請求項１０に記載の方法。
【請求項12】
ＣｈｅｃｋＳｕｍＩｄによって指示されるアルゴリズムに従って計算された第二ＣｈｅｃｋＳｕｍと、メッセージにキャリーされている第一ＣｈｅｃｋＳｕｍとを照合して、当該メッセージが正当なメッセージであるかどうかを確定することを更に含む、請求項１１に記載の方法。
【請求項13】
ＣｈｅｃｋＳｕｍの計算内容に可変部分が含まれる場合、可変部分を更新した後、ＣｈｅｃｋＳｕｍＩｄによって指示されるＣｈｅｃｋＳｕｍの計算方法に従って、第三ＣｈｅｃｋＳｕｍを再計算し、メッセージ内の第一ＣｈｅｃｋＳｕｍを第三ＣｈｅｃｋＳｕｍで更新することを更に含む、請求項１２に記載の方法。
【請求項14】
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含む、請求項１１に記載の方法。
【請求項15】
メモリ内のプログラムを読み取んで、メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信する手順と、
前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせる手順と、
前記メッセージを送信する手順とを実行するためのプロセッサと、
プロセッサの制御の下で、データを送受信するための送受信機とを含む、第一ネットワークノード。
【請求項16】
メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信するための第一ノード受信モジュールと、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせるための第一ノード識別モジュールと、
前記メッセージを送信するための第一ノード送信モジュールとを含む、第一ネットワークノード。
【請求項17】
メモリ内のプログラムを読み取んで、メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信する手順と、
制御プレーンへの送り識別子に応じて、前記メッセージを制御プレーン又は転送プレーンに渡して処理させる手順とを実行するためのプロセッサと、
プロセッサの制御の下で、データを送受信するための送受信機とを含む、第二ネットワークノード。
【請求項18】
メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信するための第二ノード受信モジュールと、制御プレーンへの送り識別子に応じて、前記メッセージを制御プレーン又は転送プレーンに渡して処理させるための第二ノード送信モジュールとを含む、第二ネットワークノード。
【請求項19】
請求項１～１４の何れか一項に記載の方法を実行するコンピュータプログラムを記憶した、コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
（関連出願の相互参照）
本願は、出願番号が２０２１１０９５３９７０．３、出願日が２０２１年０８月１９日である中国特許出願に基づいて出願され、当該中国特許出願の優先権を主張し、当該中国特許出願の内容の全ては、ここで参照として本願に組み込まれる。
本願は、通信の技術分野に関し、特に、メッセージ送信方法、装置及び記憶媒体に関する。
本願は、出願番号が２０２１１０９５３９７０．３、出願日が２０２１年０８月１９日である中国特許出願に基づいて出願され、当該中国特許出願の優先権を主張し、当該中国特許出願の内容の全ては、ここで参照として本願に組み込まれる。
本願は、通信の技術分野に関し、特に、メッセージ送信方法、装置及び記憶媒体に関する。
【背景技術】
【0002】
スライスやインサイチュフロー検出（ｉｎ－ｓｉｔｕ Ｆｌｏｗ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｌｅｍｅｔｒｙ、ｉＦＩＴ）等の新しいテクノロジの出現により、ネットワーク機器によるいくつかの情報のホップバイホップ検出及び処理が必要となる。図１は、スライス転送の模式図であり、スライスを例にすると、図に示すように、メッセージ内には、スライスＩＤ（識別子）情報がキャリーされる必要があり、これは、転送経路内のネットワークノードによりスライスＩＤ情報に従って、対応するリンクリソースをマッチングし、対応するハードスライス技術と組み合わせて、最終的にエンドツーエンドのネットワークスライス機能を実現させるためである。
【0003】
従来技術の欠点として、スライス及びインサイチュフロー検出技術には、関連情報をどのような方式でキャリーするかを確定する態様がないことである。
【発明の概要】
【発明が解決しようとする課題】
【0004】
本願の実施例に係る技術態様は、スライス及びインサイチュフロー検出技術には、関連情報をどのような方式でキャリーするかを確定する態様がないという問題を解決するためのメッセージ送信方法、装置及び記憶媒体を提供する。
【課題を解決するための手段】
【0005】
本願の実施例は、
メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信することと、
前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせることと、
前記メッセージを送信することとを含む、メッセージ送信方法を提供している。
メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信することと、
前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせることと、
前記メッセージを送信することとを含む、メッセージ送信方法を提供している。
【0006】
いくつかの実施形態において、前記メッセージは、ＩＰｖ６メッセージである。
【0007】
いくつかの実施形態において、前記メッセージの拡張ヘッダは、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒである。
【0008】
いくつかの実施形態において、
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍをキャリーさせることを更に含む。
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍをキャリーさせることを更に含む。
【0009】
いくつかの実施形態において、
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせることを更に含む。
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせることを更に含む。
【0010】
いくつかの実施形態において、
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含む。
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含む。
【0011】
本願の実施例は、
メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信することと、
制御プレーンへの送り識別子に応じて、前記ＩＰｖ６メッセージを制御プレーン又は転送プレーンに渡して処理させることとを含む、メッセージ送信方法を提供している。
メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信することと、
制御プレーンへの送り識別子に応じて、前記ＩＰｖ６メッセージを制御プレーン又は転送プレーンに渡して処理させることとを含む、メッセージ送信方法を提供している。
【0012】
いくつかの実施形態において、前記メッセージは、ＩＰｖ６メッセージである。
【0013】
いくつかの実施形態において、前記メッセージの拡張ヘッダは、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒである。
【0014】
いくつかの実施形態において、
メッセージ拡張ヘッダに第一ＣｈｅｃｋＳｕｍをキャリーさせていることを更に含む。
メッセージ拡張ヘッダに第一ＣｈｅｃｋＳｕｍをキャリーさせていることを更に含む。
【0015】
いくつかの実施形態において、
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせていることを更に含む。
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせていることを更に含む。
【0016】
いくつかの実施形態において、
ＣｈｅｃｋＳｕｍＩｄによって指示されるアルゴリズムに従って計算された第二ＣｈｅｃｋＳｕｍと、メッセージにキャリーされている第一ＣｈｅｃｋＳｕｍとを照合して、当該メッセージが正当なメッセージであるかどうかを確定することを更に含む。
ＣｈｅｃｋＳｕｍＩｄによって指示されるアルゴリズムに従って計算された第二ＣｈｅｃｋＳｕｍと、メッセージにキャリーされている第一ＣｈｅｃｋＳｕｍとを照合して、当該メッセージが正当なメッセージであるかどうかを確定することを更に含む。
【0017】
いくつかの実施形態において、
ＣｈｅｃｋＳｕｍの計算内容に可変部分が含まれる場合、可変部分を更新した後、ＣｈｅｃｋＳｕｍＩｄによって指示されるＣｈｅｃｋＳｕｍの計算方法に従って、第三ＣｈｅｃｋＳｕｍを再計算し、メッセージ内の第一ＣｈｅｃｋＳｕｍを第三ＣｈｅｃｋＳｕｍで更新することを更に含む。
ＣｈｅｃｋＳｕｍの計算内容に可変部分が含まれる場合、可変部分を更新した後、ＣｈｅｃｋＳｕｍＩｄによって指示されるＣｈｅｃｋＳｕｍの計算方法に従って、第三ＣｈｅｃｋＳｕｍを再計算し、メッセージ内の第一ＣｈｅｃｋＳｕｍを第三ＣｈｅｃｋＳｕｍで更新することを更に含む。
【0018】
いくつかの実施形態において、
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含む。
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含む。
【0019】
本願の実施例は、
メモリ内のプログラムを読み取んで、
メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信する手順と、
前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせる手順と、
前記メッセージを送信する手順とを実行するためのプロセッサと、
プロセッサの制御の下で、データを送受信するための送受信機とを含む、第一ネットワークノードを提供している。
メモリ内のプログラムを読み取んで、
メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信する手順と、
前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせる手順と、
前記メッセージを送信する手順とを実行するためのプロセッサと、
プロセッサの制御の下で、データを送受信するための送受信機とを含む、第一ネットワークノードを提供している。
【0020】
いくつかの実施形態において、前記メッセージは、ＩＰｖ６メッセージである。
【0021】
いくつかの実施形態において、前記メッセージの拡張ヘッダは、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒである。
【0022】
いくつかの実施形態において、
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍをキャリーさせることを更に含む。
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍをキャリーさせることを更に含む。
【0023】
いくつかの実施形態において、
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせることを更に含む。
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせることを更に含む。
【0024】
いくつかの実施形態において、
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含む。
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含む。
【0025】
本願の実施例は、
メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信するための第一ノード受信モジュールと、
前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせるための第一ノード識別モジュールと、
前記メッセージを送信するための第一ノード送信モジュールとを含む、第一ネットワークノードを提供している。
メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信するための第一ノード受信モジュールと、
前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせるための第一ノード識別モジュールと、
前記メッセージを送信するための第一ノード送信モジュールとを含む、第一ネットワークノードを提供している。
【0026】
いくつかの実施形態において、前記メッセージは、ＩＰｖ６メッセージである。
【0027】
いくつかの実施形態において、前記メッセージの拡張ヘッダは、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒである。
【0028】
いくつかの実施形態において、第一ノード識別モジュールは、メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍをキャリーさせるために更に使用される。
【0029】
いくつかの実施形態において、第一ノード識別モジュールは、メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせるために更に使用される。
【0030】
いくつかの実施形態において、第一ノード識別モジュールは、予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新するために更に使用される。
【0031】
本願の実施例は、
メモリ内のプログラムを読み取んで、
メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信する手順と、
制御プレーンへの送り識別子に応じて、前記メッセージを制御プレーン又は転送プレーンに渡して処理させる手順とを実行するためのプロセッサと、
プロセッサの制御の下で、データを送受信するための送受信機とを含む、第二ネットワークノードを提供している。
メモリ内のプログラムを読み取んで、
メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信する手順と、
制御プレーンへの送り識別子に応じて、前記メッセージを制御プレーン又は転送プレーンに渡して処理させる手順とを実行するためのプロセッサと、
プロセッサの制御の下で、データを送受信するための送受信機とを含む、第二ネットワークノードを提供している。
【0032】
いくつかの実施形態において、前記メッセージは、ＩＰｖ６メッセージである。
【0033】
いくつかの実施形態において、前記メッセージの拡張ヘッダは、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒである。
【0034】
いくつかの実施形態において、
メッセージ拡張ヘッダに第一ＣｈｅｃｋＳｕｍをキャリーさせていることを更に含む。
メッセージ拡張ヘッダに第一ＣｈｅｃｋＳｕｍをキャリーさせていることを更に含む。
【0035】
いくつかの実施形態において、
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせていることを更に含む。
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせていることを更に含む。
【0036】
いくつかの実施形態において、
ＣｈｅｃｋＳｕｍＩｄによって指示されるアルゴリズムに従って計算された第二ＣｈｅｃｋＳｕｍと、メッセージにキャリーされている第一ＣｈｅｃｋＳｕｍとを照合して、当該メッセージが正当なメッセージであるかどうかを確定することを更に含む。
ＣｈｅｃｋＳｕｍＩｄによって指示されるアルゴリズムに従って計算された第二ＣｈｅｃｋＳｕｍと、メッセージにキャリーされている第一ＣｈｅｃｋＳｕｍとを照合して、当該メッセージが正当なメッセージであるかどうかを確定することを更に含む。
【0037】
いくつかの実施形態において、
ＣｈｅｃｋＳｕｍの計算内容に可変部分が含まれる場合、可変部分を更新した後、ＣｈｅｃｋＳｕｍＩｄによって指示されるＣｈｅｃｋＳｕｍの計算方法に従って、第三ＣｈｅｃｋＳｕｍを再計算し、メッセージ内の第一ＣｈｅｃｋＳｕｍを第三ＣｈｅｃｋＳｕｍで更新することを更に含む。
ＣｈｅｃｋＳｕｍの計算内容に可変部分が含まれる場合、可変部分を更新した後、ＣｈｅｃｋＳｕｍＩｄによって指示されるＣｈｅｃｋＳｕｍの計算方法に従って、第三ＣｈｅｃｋＳｕｍを再計算し、メッセージ内の第一ＣｈｅｃｋＳｕｍを第三ＣｈｅｃｋＳｕｍで更新することを更に含む。
【0038】
いくつかの実施形態において、
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含む。
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含む。
【0039】
本願の実施例は、
メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信するための第二ノード受信モジュールと、
制御プレーンへの送り識別子に応じて、前記メッセージを制御プレーン又は転送プレーンに渡して処理させるための第二ノード送信モジュールとを含む、第二ネットワークノードを提供している。
メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信するための第二ノード受信モジュールと、
制御プレーンへの送り識別子に応じて、前記メッセージを制御プレーン又は転送プレーンに渡して処理させるための第二ノード送信モジュールとを含む、第二ネットワークノードを提供している。
【0040】
いくつかの実施形態において、前記メッセージは、ＩＰｖ６メッセージである。
【0041】
いくつかの実施形態において、前記メッセージの拡張ヘッダは、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒである。
【0042】
いくつかの実施形態において、第二ノード受信モジュールは、メッセージ拡張ヘッダに第一ＣｈｅｃｋＳｕｍがキャリーされているメッセージを受信するために更に使用される。
【0043】
いくつかの実施形態において、第二ノード受信モジュールは、メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄがキャリーされているメッセージを受信するために更に使用される。
【0044】
いくつかの実施形態において、第二ノード受信モジュールは、ＣｈｅｃｋＳｕｍＩｄによって指示されるアルゴリズムに従って計算された第二ＣｈｅｃｋＳｕｍと、メッセージにキャリーされている第一ＣｈｅｃｋＳｕｍとを照合して、当該メッセージが正当なメッセージであるかどうかを確定するために更に使用される。
【0045】
いくつかの実施形態において、第二ノード受信モジュールは、ＣｈｅｃｋＳｕｍの計算内容に可変部分が含まれる場合、可変部分を更新した後、ＣｈｅｃｋＳｕｍＩｄによって指示されるＣｈｅｃｋＳｕｍの計算方法に従って、第三ＣｈｅｃｋＳｕｍを再計算し、メッセージ内の第一ＣｈｅｃｋＳｕｍを第三ＣｈｅｃｋＳｕｍで更新するために更に使用される。
【0046】
いくつかの実施形態において、第二ノード受信モジュールは、予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新するために更に使用される。
【0047】
本願の実施例は、上記メッセージ送信方法を実行するコンピュータプログラムを記憶した、コンピュータ可読記憶媒体を提供している。
【発明の効果】
【0048】
本願の有益な効果は、以下の通りである。
本願の実施例による技術態様では、メッセージの拡張ヘッダには、制御プレーンへの送り識別子であって、当該メッセージについて、それにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子がキャリーされ、転送経路内の全てのネットワークノードは、当該拡張ヘッダにキャリーされている情報を検出及び処理するとともに、拡張ヘッダにキャリーされている制御プレーンへの送り識別子に応じて、当該拡張ヘッダにキャリーされている情報を制御プレーンで処理するか転送プレーンで処理するかを決定しなければならないので、従来のホップバイホップ処理機能をサポートすることに加えて、転送プレーンでメッセージ情報をホップバイホップ処理する能力もサポートすることができ、この機能によれば、スライスやインサイチュフロー検出等の新しいテクノロジのニーズを更に満たすことができる。
本願の実施例による技術態様では、メッセージの拡張ヘッダには、制御プレーンへの送り識別子であって、当該メッセージについて、それにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子がキャリーされ、転送経路内の全てのネットワークノードは、当該拡張ヘッダにキャリーされている情報を検出及び処理するとともに、拡張ヘッダにキャリーされている制御プレーンへの送り識別子に応じて、当該拡張ヘッダにキャリーされている情報を制御プレーンで処理するか転送プレーンで処理するかを決定しなければならないので、従来のホップバイホップ処理機能をサポートすることに加えて、転送プレーンでメッセージ情報をホップバイホップ処理する能力もサポートすることができ、この機能によれば、スライスやインサイチュフロー検出等の新しいテクノロジのニーズを更に満たすことができる。
【0049】
さらには、ＣｈｅｃｋＳｕｍの計算態様も提案されており、メッセージの完全性を検証し、転送手順中に内容の変化があったかどうかを認識することができる一方で、メッセージ送信者の身分の正当性を検証することができる。柔軟で可変なＣｈｅｃｋＳｕｍの計算方法により、従来のＣｈｅｃｋＳｕｍによるメッセージの完全性の保証が満たされながら、メッセージ送信者の身分の正当性の検証へのサポートも新規追加される。ハッカーによって偽造された不正なメッセージを効果的に認識可能であり、制御プレーンへの送り識別子が改竄されたり、ハッカーによってネットワークノードへの攻撃を引き起こすために利用されたりすることを効果的に防止可能である。
【図面の簡単な説明】
【0050】
ここで説明される図面は、本願のさらなる理解を提供するためのものであり、本願の一部を構成し、本願の例示的な実施例及びその説明は、本願を解釈するためのものであり、本願に対する不適切な制限を構成しない。
【図1】背景技術におけるスライス転送の模式図である。
【図2】本願の実施例におけるメッセージ送信方法一の実施の流れの模式図である。
【図3】本願の実施例におけるメッセージ送信方法二の実施の流れの模式図である。
【図4】本願の実施例におけるメッセージ転送手順におけるビット（ｂｉｔ）トランジション手順の模式図である。
【図5】本願の実施例において不正なネットワーク機器から、制御プレーンへの送り識別子が偽造されたメッセージを大量に送信してネットワーク機器を攻撃する手順の模式図である。
【図6】本願の実施例におけるＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒのメッセージフォーマットの模式図である。
【図7】本願の実施例におけるＩＰｖ６メッセージの処理の流れの実施模式図である。
【図8】本願の実施例における第一ネットワークノードの構造模式図である。
【図9】本願の実施例における第二ネットワークノードの構造模式図である。
【発明を実施するための形態】
【0051】
発明者は、発明の際に以下のことを気付いた。
即ち、従来態様で定義されたＩＰｖ６（インターネットプロトコルバージョン６、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ６）拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒ（ホップバイホップオプションヘッダ、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒ。Ｈｏｐ－ｂｙ－Ｈｏｐとは、パケットが通過するホップバイホップルータを指す）にキャリーされている情報は、メッセージ転送経路内の全てのネットワークノードによって検出及び処理されなければならない。当該拡張ヘッダによってスライス情報、インサイチュフロー検出情報がキャリーされる場合、転送経路上のノードは、キャリーされている情報を検出及び処理することになる。
即ち、従来態様で定義されたＩＰｖ６（インターネットプロトコルバージョン６、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ６）拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒ（ホップバイホップオプションヘッダ、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒ。Ｈｏｐ－ｂｙ－Ｈｏｐとは、パケットが通過するホップバイホップルータを指す）にキャリーされている情報は、メッセージ転送経路内の全てのネットワークノードによって検出及び処理されなければならない。当該拡張ヘッダによってスライス情報、インサイチュフロー検出情報がキャリーされる場合、転送経路上のノードは、キャリーされている情報を検出及び処理することになる。
【0052】
スライス及びインサイチュフロー検出技術は、新しいテクノロジであり、成熟していないため、未だに関連情報をどのような方式でキャリーするかを確定する態様がない。ただし、ＩＰｖ６ Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒによってそれをキャリーすることは、使用される可能性が最も高い従来技術の１つである。
【0053】
しかし、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒによるスライス及びインサイチュフロー検出情報のキャリーには、以下の技術的問題の少なくとも１つがある。
現在、ネットワークノードは、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒを受信した場合、制御プレーンボードへ送って処理させる必要があり、サービスメッセージにスライス情報がキャリーされると、メッセージの数が多く、全て制御プレーンに送って処理させることで、制御プレーンに過度の負荷がかかり、機器が処理できなくなり、機器の麻痺が発生する可能性があり、また、サービスメッセージには、転送遅延の要件があり、もし全てのホップバイホップノードが当該メッセージをメインコントロールボードに送って処理させると、間違いなくメッセージの転送遅延に重大な影響を与えてしまう。したがって、従来のＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒによるスライス及びインサイチュフロー検出情報のキャリーは、基本的にできない。
現在、ネットワークノードは、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒを受信した場合、制御プレーンボードへ送って処理させる必要があり、サービスメッセージにスライス情報がキャリーされると、メッセージの数が多く、全て制御プレーンに送って処理させることで、制御プレーンに過度の負荷がかかり、機器が処理できなくなり、機器の麻痺が発生する可能性があり、また、サービスメッセージには、転送遅延の要件があり、もし全てのホップバイホップノードが当該メッセージをメインコントロールボードに送って処理させると、間違いなくメッセージの転送遅延に重大な影響を与えてしまう。したがって、従来のＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒによるスライス及びインサイチュフロー検出情報のキャリーは、基本的にできない。
【0054】
また、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒの現状について、以下のことを言及した態様がある。
即ち、一部のノードは、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒ拡張ヘッダを無視するように構成され、
一部のノードは、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒがキャリーされているメッセージを破棄するように構成され、
一部のノードは、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒがキャリーされているメッセージにレート制限をかけるか、又はそれを低速キューに入れて処理するように構成される。
即ち、一部のノードは、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒ拡張ヘッダを無視するように構成され、
一部のノードは、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒがキャリーされているメッセージを破棄するように構成され、
一部のノードは、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒがキャリーされているメッセージにレート制限をかけるか、又はそれを低速キューに入れて処理するように構成される。
【0055】
具体的な内容としては、「Ｎｅｗ ｈｏｐ－ｂｙ－ｈｏｐ ｏｐｔｉｏｎｓ ａｒｅ ｎｏｔ ｒｅｃｏｍｍｅｎｄｅｄ ｂｅｃａｕｓｅ ｎｏｄｅｓ ｍａｙ ｂｅ ｃｏｎｆｉｇｕｒｅｄ ｔｏ ｉｇｎｏｒｅ ｔｈｅ Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ ｈｅａｄｅｒ，ｄｒｏｐ ｐａｃｋｅｔｓ ｃｏｎｔａｉｎｉｎｇ ａ Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ ｈｅａｄｅｒ，ｏｒ ａｓｓｉｇｎ ｐａｃｋｅｔｓ ｃｏｎｔａｉｎｉｎｇ ａ Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ ｈｅａｄｅｒ ｔｏ ａ ｓｌｏｗ ｐｒｏｃｅｓｓｉｎｇ ｐａｔｈ．」（「新しいホップバイホップオプションの使用は推奨されず、その理由として、ノードは、ホップバイホップオプションヘッダを無視するか、ホップバイホップオプションヘッダが含まれているパケットを破棄するか、ホップバイホップオプションヘッダが含まれているパケットを低速処理経路に割り当てるように構成されることにある」）である。
【0056】
要約すると、従来のＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒは、上記の問題があるため、スライス及びインサイチュフロー検出情報のキャリーに適していない。スライス及びインサイチュフロー検出等の新しいテクノロジについては、キャリーされている情報が転送経路上のノードによって検出及び処理されることになる態様が切望されている。また、これらの情報は、メッセージの転送遅延に影響が与えられず、転送ノードの制御プレーンのオーバーヘッドが増加されないように、転送プレーンで処理する必要がある。
【0057】
これに基づいて、本願の実施例は、ホップバイホップ処理を必要とするメッセージの拡張ヘッダの改良した態様を提案する。当該態様によれば、従来のホップバイホップ処理機能が実現されるだけでなく、スライス及びインサイチュフロー検出等の新しいテクノロジについて、転送プレーンで情報のホップバイホップ検出及び処理を行うニーズも満たされる。
【0058】
以下、図面を参照して、本願の具体的な実施形態を説明する。
【0059】
説明の際、それぞれ各ノード側の実施から説明し、その後、本願の実施例に挙げられた態様の実施をよりよく理解するために、そららを連携させた実施の例も挙げる。このような説明方式は、それらを連携させて実施しなければならないことや、単独で実施しなければならないことを意味するものではなく、実際には、それらが別々に実施する場合、それぞれ自身側の問題が解決される一方で、それらを組み合わせて使用する場合、より高い技術的効果が得られることになる。
【0060】
図２は、メッセージ送信方法一の実施の流れの模式図であり、図に示すように、
メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信するステップ２０１と、
前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせるステップ２０２と、
前記メッセージを送信するステップ２０３とを含んでもよい。
メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信するステップ２０１と、
前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせるステップ２０２と、
前記メッセージを送信するステップ２０３とを含んでもよい。
【0061】
図３は、メッセージ送信方法二の実施の流れの模式図であり、図に示すように、
メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信するステップ３０１と、
制御プレーンへの送り識別子に応じて、前記メッセージを制御プレーン又は転送プレーンに渡して処理させるステップ３０２とを含んでもよい。
メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信するステップ３０１と、
制御プレーンへの送り識別子に応じて、前記メッセージを制御プレーン又は転送プレーンに渡して処理させるステップ３０２とを含んでもよい。
【0062】
いくつかの実施形態において、前記メッセージは、ＩＰｖ６メッセージである。
【0063】
具体的な実施において、前記メッセージの拡張ヘッダは、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒである。
【0064】
実施において、ＩＰｖ６メッセージ、及び拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒを例とすることが可能であり、ＩＰｖ６メッセージは、幅広く適用されて代表的なものであり、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒは、メッセージ転送経路内で全てのホップバイホップネットワークノードによって検出及び処理されることになる特性を有するという理由により、それを例とするが、メッセージ転送経路内のホップバイホップネットワークノードによってメッセージが検出及び処理されることになるという特性を満たす限り、他のメッセージ、及び拡張ヘッダを使用することも可能である。ＩＰｖ６メッセージ、及び拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒは、本願の実施例に係る技術態様を具体的にどのように実施するかを当業者に教示するためのものに過ぎず、ＩＰｖ６メッセージ、及び拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒのみに適用できることを意味するものではなく、実施の際、実際の必要に応じて、対応するメッセージ、及び拡張ヘッダを確定することが可能である。
【0065】
すると、具体的な態様としては、ＩＰｖ６メッセージを受信することと、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒに制御プレーンへの送り識別子であって、当該メッセージについて、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせることと、前記ＩＰｖ６メッセージを送信することとにされてもよい。
そして、受信側について、ＩＰｖ６メッセージであって、その拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるＩＰｖ６メッセージを受信することと、制御プレーンへの送り識別子に応じて、前記ＩＰｖ６メッセージを制御プレーン又は転送プレーンに渡して処理させることとにされてもよい。
そして、受信側について、ＩＰｖ６メッセージであって、その拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるＩＰｖ６メッセージを受信することと、制御プレーンへの送り識別子に応じて、前記ＩＰｖ６メッセージを制御プレーン又は転送プレーンに渡して処理させることとにされてもよい。
【0066】
本態様では、新しいＩＰｖ６拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒを定義する。当該拡張ヘッダは、制御プレーンへの送り識別子をキャリーすることで、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示す。
【0067】
いくつかの実施形態において、メッセージを受信するノードとしては、
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍをキャリーさせることを更に含んでもよい。
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍをキャリーさせることを更に含んでもよい。
【0068】
具体的に、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ ＨｅａｄｅｒにＣｈｅｃｋＳｕｍをキャリーさせる。
【0069】
それに応じて、メッセージを受信するノードとしては、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒに第一ＣｈｅｃｋＳｕｍをキャリーさせている。
【0070】
図４は、メッセージ転送手順におけるビットトランジション手順の模式図であり、メッセージ転送手順中には、図４に示すような問題が発生する可能性があり、例えばルータＡからルータＢにユーザＨのメッセージを転送するとき、何らかの原因でビットトランジションが発生して、制御プレーンへの送りフラグが誤ってセットされ、転送プレーンに処理させるべきであったメッセージが誤って制御プレーンへ送られ、このようなメッセージが大量に存在すると、制御プレーンに過度の負荷がかかることで、ネットワークノードのルータＢがクラッシュしてしまう。
【0071】
図５は、不正なネットワーク機器から、制御プレーンへの送り識別子が偽造されたメッセージを大量に送信してネットワーク機器を攻撃する手順の模式図であり、ハッカーがネットワークノードを能動的に攻撃すると、図５に示すような問題が発生する可能性があり。例えば、不正なＡＰ＿ＡからルータＣに、セット済みの制御プレーンへの送りの処理識別子がキャリーされている偽造メッセージを大量に送信し、ルータＣがそれらの偽造メッセージを受信した後、全ての偽造メッセージを制御プレーンへ送って処理させることで、ルータＣが麻痺してしまい、その結果、通常のユーザＨによるサービスＳへのアクセスにおける正当なメッセージ転送に影響を与え、サービス障害を引き起こしてしまう。
【0072】
このように、メッセージ内にＣｈｅｃｋＳｕｍ（チェックサム）をキャリーさせることで、上記２つの問題を回避できる。メッセージの完全性を検証し、転送手順中に変化があったかどうかを確かめることができる一方で、メッセージ送信者の身分の正当性を検証することができる。
【0073】
それに応じて、いくつかの実施形態において、メッセージを受信するノードとしては、
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせることを更に含んでもよい。
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせることを更に含んでもよい。
【0074】
すると、メッセージを受信するノードとしては、メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせている。
【0075】
具体的に、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ ＨｅａｄｅｒにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせる。
【0076】
すると、メッセージを受信するノードとしては、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ ＨｅａｄｅｒにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせている。
【0077】
具体的な実施において、
ＣｈｅｃｋＳｕｍＩｄによって指示されるアルゴリズムに従って計算された第二ＣｈｅｃｋＳｕｍと、メッセージにキャリーされている第一ＣｈｅｃｋＳｕｍとを照合して、当該メッセージが正当なメッセージであるかどうかを確定することを更に含む。
ＣｈｅｃｋＳｕｍＩｄによって指示されるアルゴリズムに従って計算された第二ＣｈｅｃｋＳｕｍと、メッセージにキャリーされている第一ＣｈｅｃｋＳｕｍとを照合して、当該メッセージが正当なメッセージであるかどうかを確定することを更に含む。
【0078】
以下、例を挙げて説明する。
【0079】
まず、メッセージフォーマットの実施について説明する。
【0080】
図６は、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒメッセージフォーマットの模式図であり、図に示すように、以下のものが含まれる。
Ｎｅｘｔ Ｈｅａｄｅｒ：Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒの後の拡張ヘッダのタイプである。
Ｈｄｒ Ｅｘｔ Ｌｅｎ：拡張ヘッダの長さである。
Ｆｌａｇ：制御プレーンへ送って処理させる必要があるかどうかの識別子である。例えば、１に設定される場合、メッセージが制御プレーンで処理され、０に設定される場合、メッセージが転送プレーンで処理される。
ＣｈｅｃｋＳｕｍＩｄ（チェックサム識別子）：ＣｈｅｃｋＳｕｍの計算方法のインデックス値である。
ＣｈｅｃｋＳｕｍ：ＣｈｅｃｋＳｕｍＩｄによって指示される方法に従って、ＣｈｅｃｋＳｕｍが計算される。
Ｏｐｔｉｏｎｓ：任意数のＯｐｔｉｏｎ（オプション）がキャリーされる。Ｏｐｔｉｏｎの定義は、少なくともＳｅｃｔｉｏｎ ４．２ ｏｆ ［ＲＦＣ８２００］を参照可能である（ＲＦＣ８２００の４．２部分、ＲＦＣ：コメント募集、Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ、ＲＦＣは、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）によって発行された一連の覚書である）。
Ｎｅｘｔ Ｈｅａｄｅｒ：Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒの後の拡張ヘッダのタイプである。
Ｈｄｒ Ｅｘｔ Ｌｅｎ：拡張ヘッダの長さである。
Ｆｌａｇ：制御プレーンへ送って処理させる必要があるかどうかの識別子である。例えば、１に設定される場合、メッセージが制御プレーンで処理され、０に設定される場合、メッセージが転送プレーンで処理される。
ＣｈｅｃｋＳｕｍＩｄ（チェックサム識別子）：ＣｈｅｃｋＳｕｍの計算方法のインデックス値である。
ＣｈｅｃｋＳｕｍ：ＣｈｅｃｋＳｕｍＩｄによって指示される方法に従って、ＣｈｅｃｋＳｕｍが計算される。
Ｏｐｔｉｏｎｓ：任意数のＯｐｔｉｏｎ（オプション）がキャリーされる。Ｏｐｔｉｏｎの定義は、少なくともＳｅｃｔｉｏｎ ４．２ ｏｆ ［ＲＦＣ８２００］を参照可能である（ＲＦＣ８２００の４．２部分、ＲＦＣ：コメント募集、Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ、ＲＦＣは、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）によって発行された一連の覚書である）。
【0081】
以下、ＣｈｅｃｋＳｕｍの計算の実施について説明する。
【0082】
ネットワーク機器は、ＣｈｅｃｋＳｕｍＩｄに対応するＣｈｅｃｋＳｕｍの計算方法を事前に構成しておき、かかる計算方法には、ＣｈｅｃｋＳｕｍのアルゴリズム、ＣｈｅｃｋＳｕｍの計算内容等が含まれる。例えば、ＣｈｅｃｋＳｕｍのアルゴリズムは、パリティチェック、ＬＲＣ（縦方向冗長チェック、Ｌｏｎｇｉｔｕｄｉｎａｌ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）等に設定され得る。ＣｈｅｃｋＳｕｍの計算内容は、可変部分を除くＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒ部分の計算、可変部分を除くＩＰｖ６メッセージヘッダ全体の計算、可変部分等を含むＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒ部分の計算に設定され得る。
【0083】
いくつかの実施形態において、
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含んでもよい。
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含んでもよい。
【0084】
具体的に、ネットワーク機器は、複数の異なるＣｈｅｃｋＳｕｍの計算方法に対応して複数のＣｈｅｃｋＳｕｍＩｄを構成することをサポートし、ネットワーク機器は、ＣｈｅｃｋＳｕｍＩｄを周期的に変更することが可能である。ハッカーは、ネットワークメッセージを盗聴したとしても、ＣｈｅｃｋＳｕｍＩｄに対応するアルゴリズム及びＣｈｅｃｋＳｕｍの計算内容を知ることができないため、正当なメッセージの偽造が困難であり、それに、ネットワーク機器がＣｈｅｃｋＳｕｍＩｄを周期的に変更することで、ハッカーによるＣｈｅｃｋＳｕｍＩｄ内容の解読が更に困難となる。
【0085】
以下、メッセージ処理の実施について説明する。
【0086】
図７は、ＩＰｖ６メッセージの処理の流れの実施模式図であり、図に示すように、以下の１～６を含んでもよい。
１、ノードＡは、ユーザＨのメッセージを受信して、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒをカプセル化してホップバイホップ検出及び処理の情報をキャリーさせ、当該情報には、制御プレーンへ送って処理させる必要のあるものが存在すれば、Ｆｌａｇが１に設定され、そうでなければ、０に設定される。
２、ノードＡは、ローカルに構成されたＣｈｅｃｋＳｕｍ情報に従って、ユーザＨのメッセージの為に、対応するＣｈｅｃｋＳｕｍＩｄをマッチングし、ＣｈｅｃｋＳｕｍＩｄによって指示される方法に従ってＣｈｅｃｋＳｕｍを計算し、ＣｈｅｃｋＳｕｍＩｄ及びＣｈｅｃｋＳｕｍ情報をＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒにキャリーさせる。
３、ノードＢは、ノードＡから転送されたユーザＨのメッセージを受信して、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒ内のＣｈｅｃｋＳｕｍＩｄに従ってローカルのＣｈｅｃｋＳｕｍの計算方法を取得し、メッセージのＣｈｅｃｋＳｕｍ’を計算する。ＣｈｅｃｋＳｕｍ’と、メッセージにキャリーされているＣｈｅｃｋＳｕｍとを比較し、
両者が同じであれば、メッセージは、正当なメッセージとされ、Ｆｌａｇの指示通りに、制御プレーン又は転送プレーンで処理され、そうでなければ、メッセージは、不正なものとされ、例えばメッセージが破棄される等、管理者の設定に従って処理される。
一例として、不正なノードＤは、偽造メッセージを送信した場合、ＣｈｅｃｋＳｕｍの計算方法が分からないため、正当なＣｈｅｃｋＳｕｍを計算できない。ノードＢは、不正なメッセージを受信した後、メッセージにキャリーされているＣｈｅｃｋＳｕｍと一致しないＣｈｅｃｋＳｕｍ’を算出して、不正なメッセージを破棄することで、ハッカーによる攻撃を回避した。
５、ＣｈｅｃｋＳｕｍの計算内容に可変部分が含まれる場合、ノードＢは、可変部分を更新した後、ＣｈｅｃｋＳｕｍＩｄによって指示されるＣｈｅｃｋＳｕｍの計算方法に従って、ＣｈｅｃｋＳｕｍ２を再計算し、メッセージ内のＣｈｅｃｋＳｕｍをＣｈｅｃｋＳｕｍ２で更新する。つまり、いくつかの実施形態において、
ＣｈｅｃｋＳｕｍの計算内容に可変部分が含まれる場合、可変部分を更新した後、ＣｈｅｃｋＳｕｍＩｄによって指示されるＣｈｅｃｋＳｕｍの計算方法に従って、第三ＣｈｅｃｋＳｕｍを再計算し、メッセージ内の第一ＣｈｅｃｋＳｕｍを第三ＣｈｅｃｋＳｕｍで更新することを更に含んでもよい。
６、ノードＣは、ユーザＨのメッセージを受信した後、ノードＢと同じ流れでメッセージを処理する。
１、ノードＡは、ユーザＨのメッセージを受信して、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒをカプセル化してホップバイホップ検出及び処理の情報をキャリーさせ、当該情報には、制御プレーンへ送って処理させる必要のあるものが存在すれば、Ｆｌａｇが１に設定され、そうでなければ、０に設定される。
２、ノードＡは、ローカルに構成されたＣｈｅｃｋＳｕｍ情報に従って、ユーザＨのメッセージの為に、対応するＣｈｅｃｋＳｕｍＩｄをマッチングし、ＣｈｅｃｋＳｕｍＩｄによって指示される方法に従ってＣｈｅｃｋＳｕｍを計算し、ＣｈｅｃｋＳｕｍＩｄ及びＣｈｅｃｋＳｕｍ情報をＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒにキャリーさせる。
３、ノードＢは、ノードＡから転送されたユーザＨのメッセージを受信して、Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒ内のＣｈｅｃｋＳｕｍＩｄに従ってローカルのＣｈｅｃｋＳｕｍの計算方法を取得し、メッセージのＣｈｅｃｋＳｕｍ’を計算する。ＣｈｅｃｋＳｕｍ’と、メッセージにキャリーされているＣｈｅｃｋＳｕｍとを比較し、
両者が同じであれば、メッセージは、正当なメッセージとされ、Ｆｌａｇの指示通りに、制御プレーン又は転送プレーンで処理され、そうでなければ、メッセージは、不正なものとされ、例えばメッセージが破棄される等、管理者の設定に従って処理される。
一例として、不正なノードＤは、偽造メッセージを送信した場合、ＣｈｅｃｋＳｕｍの計算方法が分からないため、正当なＣｈｅｃｋＳｕｍを計算できない。ノードＢは、不正なメッセージを受信した後、メッセージにキャリーされているＣｈｅｃｋＳｕｍと一致しないＣｈｅｃｋＳｕｍ’を算出して、不正なメッセージを破棄することで、ハッカーによる攻撃を回避した。
５、ＣｈｅｃｋＳｕｍの計算内容に可変部分が含まれる場合、ノードＢは、可変部分を更新した後、ＣｈｅｃｋＳｕｍＩｄによって指示されるＣｈｅｃｋＳｕｍの計算方法に従って、ＣｈｅｃｋＳｕｍ２を再計算し、メッセージ内のＣｈｅｃｋＳｕｍをＣｈｅｃｋＳｕｍ２で更新する。つまり、いくつかの実施形態において、
ＣｈｅｃｋＳｕｍの計算内容に可変部分が含まれる場合、可変部分を更新した後、ＣｈｅｃｋＳｕｍＩｄによって指示されるＣｈｅｃｋＳｕｍの計算方法に従って、第三ＣｈｅｃｋＳｕｍを再計算し、メッセージ内の第一ＣｈｅｃｋＳｕｍを第三ＣｈｅｃｋＳｕｍで更新することを更に含んでもよい。
６、ノードＣは、ユーザＨのメッセージを受信した後、ノードＢと同じ流れでメッセージを処理する。
【0087】
同じ発明構想に基づいて、本願の実施例は、ネットワークノード、及びコンピュータ可読記憶媒体を更に提供しており、これらの機器は、問題を解決する原理がメッセージ送信方法と類似するため、これらの機器の実施について、方法の実施を参照可能であり、重複部分を繰り返して述べない。
【0088】
本願の実施例による技術態様を実施するとき、次の形態で実施することが可能である。
【0089】
図８は、第一ネットワークノードの構造模式図であり、図に示すように、ノードには、
メモリ８２０内のプログラムを読み取んで、
メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信する手順と、
前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせる手順と、
前記メッセージを送信する手順とを実行するためのプロセッサ８００と、
プロセッサ８００の制御の下で、データを送受信するための送受信機８１０とが含まれる。
メモリ８２０内のプログラムを読み取んで、
メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信する手順と、
前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせる手順と、
前記メッセージを送信する手順とを実行するためのプロセッサ８００と、
プロセッサ８００の制御の下で、データを送受信するための送受信機８１０とが含まれる。
【0090】
いくつかの実施形態において、前記メッセージは、ＩＰｖ６メッセージである。
【0091】
いくつかの実施形態において、前記メッセージの拡張ヘッダは、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒである。
【0092】
いくつかの実施形態において、
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍをキャリーさせることを更に含む。
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍをキャリーさせることを更に含む。
【0093】
いくつかの実施形態において、
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせることを更に含む。
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせることを更に含む。
【0094】
いくつかの実施形態において、
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含む。
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含む。
【0095】
図８において、バスアーキテクチャは、任意数の相互接続されたバス及びブリッジを含んでもよく、具体的には、プロセッサ８００を代表とした１つ又は複数のプロセッサと、メモリ８２０を代表としたメモリとの各種回路が繋げられている。バスアーキテクチャは、周辺機器、電圧レギュレータや電力管理回路等の様々な他の回路を互いに繋げることも可能であるが、これらは、当分野において公知されているため、本明細書において、さらなる記述をしない。バスインターフェースは、インターフェースを提供するものである。送受信機８１０は、複数の要素であってもよく、即ち送信機及び受信機を含んでもよく、伝送媒体にて様々な他の装置と通信するための手段を提供するものである。プロセッサ８００は、バスアーキテクチャ及び一般的な処理の管理を担っており、メモリ８２０は、プロセッサ８００による操作実行時に使用されるデータを記憶可能である。
【0096】
本願の実施例は、
メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信するための第一ノード受信モジュールと、
前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせるための第一ノード識別モジュールと、
前記メッセージを送信するための第一ノード送信モジュールとを含む、第一ネットワークノードを更に提供している。
メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信するための第一ノード受信モジュールと、
前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせるための第一ノード識別モジュールと、
前記メッセージを送信するための第一ノード送信モジュールとを含む、第一ネットワークノードを更に提供している。
【0097】
いくつかの実施形態において、前記メッセージは、ＩＰｖ６メッセージである。
【0098】
いくつかの実施形態において、前記メッセージの拡張ヘッダは、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒである。
【0099】
いくつかの実施形態において、第一ノード識別モジュールは、メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍをキャリーさせるために更に使用される。
【0100】
いくつかの実施形態において、第一ノード識別モジュールは、メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせるために更に使用される。
【0101】
いくつかの実施形態において、第一ノード識別モジュールは、予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新するために更に使用される。
【0102】
記述の便宜上、上記の装置の各部分については、機能別に様々なモジュール又はユニットに分割してそれぞれ記述した。勿論、本願の実施の際、各モジュール又はユニットの機能は、同一又は複数のソフトウェア又はハードウェアで実現され得る。
【0103】
図９は、第二ネットワークノードの構造模式図であり、図に示すように、ノードには、
メモリ９２０内のプログラムを読み取んで、
メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信する手順と、
制御プレーンへの送り識別子に応じて、前記メッセージを制御プレーン又は転送プレーンに渡して処理させる手順とを実行するためのプロセッサ９００と、
プロセッサ９００の制御の下で、データを送受信するための送受信機９１０とが含まれる。
メモリ９２０内のプログラムを読み取んで、
メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信する手順と、
制御プレーンへの送り識別子に応じて、前記メッセージを制御プレーン又は転送プレーンに渡して処理させる手順とを実行するためのプロセッサ９００と、
プロセッサ９００の制御の下で、データを送受信するための送受信機９１０とが含まれる。
【0104】
いくつかの実施形態において、前記メッセージは、ＩＰｖ６メッセージである。
【0105】
いくつかの実施形態において、前記メッセージの拡張ヘッダは、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒである。
【0106】
いくつかの実施形態において、
メッセージ拡張ヘッダに第一ＣｈｅｃｋＳｕｍをキャリーさせていることを更に含む。
メッセージ拡張ヘッダに第一ＣｈｅｃｋＳｕｍをキャリーさせていることを更に含む。
【0107】
いくつかの実施形態において、
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせていることを更に含む。
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせていることを更に含む。
【0108】
いくつかの実施形態において、
ＣｈｅｃｋＳｕｍＩｄによって指示されるアルゴリズムに従って計算された第二ＣｈｅｃｋＳｕｍと、メッセージにキャリーされている第一ＣｈｅｃｋＳｕｍとを照合して、当該メッセージが正当なメッセージであるかどうかを確定することを更に含む。
ＣｈｅｃｋＳｕｍＩｄによって指示されるアルゴリズムに従って計算された第二ＣｈｅｃｋＳｕｍと、メッセージにキャリーされている第一ＣｈｅｃｋＳｕｍとを照合して、当該メッセージが正当なメッセージであるかどうかを確定することを更に含む。
【0109】
いくつかの実施形態において、
ＣｈｅｃｋＳｕｍの計算内容に可変部分が含まれる場合、可変部分を更新した後、ＣｈｅｃｋＳｕｍＩｄによって指示されるＣｈｅｃｋＳｕｍの計算方法に従って、第三ＣｈｅｃｋＳｕｍを再計算し、メッセージ内の第一ＣｈｅｃｋＳｕｍを第三ＣｈｅｃｋＳｕｍで更新することを更に含む。
ＣｈｅｃｋＳｕｍの計算内容に可変部分が含まれる場合、可変部分を更新した後、ＣｈｅｃｋＳｕｍＩｄによって指示されるＣｈｅｃｋＳｕｍの計算方法に従って、第三ＣｈｅｃｋＳｕｍを再計算し、メッセージ内の第一ＣｈｅｃｋＳｕｍを第三ＣｈｅｃｋＳｕｍで更新することを更に含む。
【0110】
いくつかの実施形態において、
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含む。
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含む。
【0111】
図９において、バスアーキテクチャは、任意数の相互接続されたバス及びブリッジを含んでもよく、具体的には、プロセッサ９００を代表とした１つ又は複数のプロセッサと、メモリ９２０を代表としたメモリとの各種回路が繋げられている。バスアーキテクチャは、周辺機器、電圧レギュレータや電力管理回路等の様々な他の回路を互いに繋げることも可能であるが、これらは、当分野において公知されているため、本明細書において、さらなる記述をしない。バスインターフェースは、インターフェースを提供するものである。送受信機９１０は、複数の要素であってもよく、即ち送信機及び受信機を含んでもよく、伝送媒体にて様々な他の装置と通信するための手段を提供するものである。プロセッサ９００は、バスアーキテクチャ及び一般的な処理の管理を担っており、メモリ９２０は、プロセッサ９００による操作実行時に使用されるデータを記憶可能である。
【0112】
本願の実施例は、
メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信するための第二ノード受信モジュールと、
制御プレーンへの送り識別子に応じて、前記メッセージを制御プレーン又は転送プレーンに渡して処理させるための第二ノード送信モジュールとを含む、第二ネットワークノードを更に提供している。
メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信するための第二ノード受信モジュールと、
制御プレーンへの送り識別子に応じて、前記メッセージを制御プレーン又は転送プレーンに渡して処理させるための第二ノード送信モジュールとを含む、第二ネットワークノードを更に提供している。
【0113】
いくつかの実施形態において、前記メッセージは、ＩＰｖ６メッセージである。
【0114】
いくつかの実施形態において、前記メッセージの拡張ヘッダは、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒである。
【0115】
いくつかの実施形態において、第二ノード受信モジュールは、メッセージ拡張ヘッダに第一ＣｈｅｃｋＳｕｍがキャリーされているメッセージを受信するために更に使用される。
【0116】
いくつかの実施形態において、第二ノード受信モジュールは、メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄがキャリーされているメッセージを受信するために更に使用される。
【0117】
いくつかの実施形態において、第二ノード受信モジュールは、ＣｈｅｃｋＳｕｍＩｄによって指示されるアルゴリズムに従って計算された第二ＣｈｅｃｋＳｕｍと、メッセージにキャリーされている第一ＣｈｅｃｋＳｕｍとを照合して、当該メッセージが正当なメッセージであるかどうかを確定するために更に使用される。
【0118】
いくつかの実施形態において、第二ノード受信モジュールは、ＣｈｅｃｋＳｕｍの計算内容に可変部分が含まれる場合、可変部分を更新した後、ＣｈｅｃｋＳｕｍＩｄによって指示されるＣｈｅｃｋＳｕｍの計算方法に従って、第三ＣｈｅｃｋＳｕｍを再計算し、メッセージ内の第一ＣｈｅｃｋＳｕｍを第三ＣｈｅｃｋＳｕｍで更新するために更に使用される。
【0119】
いくつかの実施形態において、第二ノード受信モジュールは、予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新するために更に使用される。
【0120】
記述の便宜上、上記の装置の各部分については、機能別に様々なモジュール又はユニットに分割してそれぞれ記述した。勿論、本願の実施の際、各モジュール又はユニットの機能は、同一又は複数のソフトウェア又はハードウェアで実現され得る。
【0121】
本願の実施例は、上記メッセージ送信方法を実行するコンピュータプログラムを記憶したコンピュータ可読記憶媒体を更に提供している。
【0122】
具体的な実施については、各ノード上のメッセージ送信方法の実施を参照可能である。
【0123】
上記を要約すると、本願の実施例による技術態様では、新しいメッセージ拡張ヘッダが提案され、転送経路内のネットワークノードは何れも、当該拡張ヘッダにキャリーされている情報を検出及び処理するとともに、拡張ヘッダにキャリーされている制御プレーンへの送り識別子に従って、当該拡張ヘッダにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを決定しなければならない。
【0124】
従来技術におけるＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒに比べて、従来のＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒ機能がサポートされることに加えて、転送プレーンでメッセージ情報をホップバイホップ処理することをサポートする能力も新規追加され、この機能によれば、スライスやインサイチュフロー検出等の新しいテクノロジのニーズを更に満たすことができる。従来のＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒは、スライスやインサイチュフロー検出等の新しいテクノロジのニーズを満たすことができない。
【0125】
さらには、ＣｈｅｃｋＳｕｍの計算方法も提案されており、メッセージの完全性を検証し、転送手順中に内容の変化があったかどうかを認識することができる一方で、メッセージ送信者の身分の正当性を検証することができる。ＣｈｅｃｋＳｕｍＩｄを周期的に変更することで、ハッカーによる攻撃が更に困難となる。
【0126】
柔軟で可変なＣｈｅｃｋＳｕｍの計算方法により、従来のＣｈｅｃｋＳｕｍによるメッセージの完全性の保証が満たされながら、メッセージ送信者の身分の正当性の検証へのサポートも新規追加される。ハッカーによって偽造された不正なメッセージを効果的に認識可能である。本願が提案した当該ＣｈｅｃｋＳｕｍの計算方法を使用すれば、制御プレーンへの送り識別子が改竄されたり、ハッカーによってネットワークノードへの攻撃を引き起こすために利用されたりすることを効果的に防止可能である。
【0127】
当業者であれば、本願の実施例は、方法、システム、又はコンピュータプログラム製品として提供され得ると理解できる。従って、本願は、完全にハードウェアの実施例、完全にソフトウェアの実施例、又はソフトウェアとハードウェアとを組み合わせた実施例の形態を取り得る。しかも、本願は、コンピュータ利用可能なプログラムコードを含む１つ又は複数のコンピュータ利用可能な記憶媒体（磁気ディスクメモリ及び光学メモリなどを含むが、それらに限定されない）で実施されるコンピュータプログラム製品の形態を取り得る。
【0128】
本願は、本願の実施例による方法、機器（システム）及びコンピュータプログラム製品のフローチャート及び／又はブロック図を参照にして記述されている。フローチャート及び／又はブロック図における各フロー及び／又はブロック、及びフローチャート及び／又はブロック図におけるフロー及び／又はブロックの組み合わせは、コンピュータプログラム命令により実現され得ると理解されるべきである。これらのコンピュータプログラム命令を汎用コンピュータ、専用コンピュータ、嵌め込み式プロセッサ又は他のプログラマブルデータ処理機器のプロセッサに提供して１つのマシンを形成し、コンピュータ又は他のプログラマブルデータ処理機器のプロセッサで実行される命令により、フローチャートの１つ又は複数のフロー及び／又はブロック図の１つ又は複数のブロックで指定される機能を実現するための装置を形成する。
【0129】
これらのコンピュータプログラム命令は、コンピュータ又は他のプログラマブルデータ処理機器を特定の方式で動作させるように導けるコンピュータ可読メモリに格納されてもよく、当該コンピュータ可読メモリに格納される命令により、命令装置を含む製品を形成する。当該命令装置は、フローチャートの１つ又は複数のフロー及び／又はブロック図の１つ又は複数のブロックで指定される機能を実現する。
【0130】
これらのコンピュータプログラム命令は、コンピュータ又は他のプログラマブルデータ処理機器にロードされてもよく、コンピュータ又は他のプログラマブルデータ処理機器で一連の操作ステップを実行することにより、コンピュータで実現される処理を形成し、コンピュータ又は他のプログラマブルデータ処理機器で実行される命令により、フローチャートの１つ又は複数のフロー及び／又はブロック図の１つ又は複数のブロックで指定される機能を実現するためのステップを提供する。
【0131】
明らかなことに、当業者であれば、本願の精神及び範囲を逸脱せずに、本願に対して様々な修正や変形をすることが可能である。よって、本願のこれらの修正や変形が、本願の特許請求の範囲及びその均等な技術的範囲に属するものであれば、本願には、これらの修正や変形も含むこととする。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【手続補正書】
【提出日】2024-02-19
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信することと、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせることと、
前記メッセージを送信することとを含む、メッセージ送信方法。
【請求項2】
前記メッセージは、インターネットプロトコルバージョン６（ＩＰｖ６）メッセージである、請求項１に記載の方法。
【請求項3】
前記メッセージの拡張ヘッダは、ＩＰｖ６メッセージ拡張ヘッダホップバイホップオプションヘッダ（Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒ）である、請求項２に記載の方法。
【請求項4】
メッセージ拡張ヘッダにチェックサム（ＣｈｅｃｋＳｕｍ）をキャリーさせることを更に含む、請求項１～３の何れか一項に記載の方法。
【請求項5】
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせることを更に含む、請求項４に記載の方法。
【請求項6】
予め設定された時間にＣｈｅｃｋＳｕｍのアルゴリズムを更新することを更に含む、請求項５に記載の方法。
【請求項7】
メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信することと、制御プレーンへの送り識別子に応じて、前記メッセージを制御プレーン又は転送プレーンに渡して処理させることとを含む、メッセージ送信方法。
【請求項8】
前記メッセージは、ＩＰｖ６メッセージである、請求項７に記載の方法。
【請求項9】
前記メッセージの拡張ヘッダは、ＩＰｖ６メッセージ拡張ヘッダＨｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎｓ Ｈｅａｄｅｒである、請求項８に記載の方法。
【請求項10】
メッセージ拡張ヘッダに第一ＣｈｅｃｋＳｕｍをキャリーさせていることを更に含む、請求項７～９の何れか一項に記載の方法。
【請求項11】
メッセージ拡張ヘッダにＣｈｅｃｋＳｕｍで使用されるアルゴリズムを指示するためのＣｈｅｃｋＳｕｍＩｄをキャリーさせていることを更に含む、請求項１０に記載の方法。
【請求項12】
ＣｈｅｃｋＳｕｍＩｄによって指示されるアルゴリズムに従って計算された第二ＣｈｅｃｋＳｕｍと、メッセージにキャリーされている第一ＣｈｅｃｋＳｕｍとを照合して、当該メッセージが正当なメッセージであるかどうかを確定することを更に含む、請求項１１に記載の方法。
【請求項13】
ＣｈｅｃｋＳｕｍの計算内容に可変部分が含まれる場合、可変部分を更新した後、ＣｈｅｃｋＳｕｍＩｄによって指示されるＣｈｅｃｋＳｕｍの計算方法に従って、第三ＣｈｅｃｋＳｕｍを再計算し、メッセージ内の第一ＣｈｅｃｋＳｕｍを第三ＣｈｅｃｋＳｕｍで更新することを更に含む、請求項１２に記載の方法。
【請求項14】
メッセージ転送経路内のホップバイホップネットワークノードによって検出及び処理されることになるメッセージを受信するための第一ノード受信モジュールと、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子であって、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子をキャリーさせるための第一ノード識別モジュールと、
前記メッセージを送信するための第一ノード送信モジュールとを含む、第一ネットワークノード。
【請求項15】
メッセージであって、前記メッセージの拡張ヘッダに制御プレーンへの送り識別子がキャリーされており、前記制御プレーンへの送り識別子は、当該メッセージについて、メッセージにキャリーされている情報が制御プレーンで処理されるか転送プレーンで処理されるかを示すための識別子であるメッセージを受信するための第二ノード受信モジュールと、制御プレーンへの送り識別子に応じて、前記メッセージを制御プレーン又は転送プレーンに渡して処理させるための第二ノード送信モジュールとを含む、第二ネットワークノード。
【国際調査報告】