(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-12-27
(54)【発明の名称】パケット処理方法及び装置
(51)【国際特許分類】
H04L 47/43 20220101AFI20231220BHJP
H04L 47/41 20220101ALI20231220BHJP
【ＦＩ】
H04L47/43
H04L47/41
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2023535438
(86)(22)【出願日】2021-11-17
(85)【翻訳文提出日】2023-07-19
(86)【国際出願番号】 CN2021131088
(87)【国際公開番号】W WO2022121638
(87)【国際公開日】2022-06-16
(31)【優先権主張番号】202011463979.8
(32)【優先日】2020-12-11
(33)【優先権主張国・地域又は機関】CN
(31)【優先権主張番号】202110183765.3
(32)【優先日】2021-02-10
(33)【優先権主張国・地域又は機関】CN
(81)【指定国・地域】
(71)【出願人】
【識別番号】503433420
【氏名又は名称】華為技術有限公司
【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】Ｈｕａｗｅｉ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｂｕｉｌｄｉｎｇ， Ｂａｎｔｉａｎ， Ｌｏｎｇｇａｎｇ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ， Ｇｕａｎｇｄｏｎｇ ５１８１２９， Ｐ．Ｒ． Ｃｈｉｎａ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ヤーン，ファン
(72)【発明者】
【氏名】ワーン，ヤーリー
(72)【発明者】
【氏名】ジョウ，ティエンゥラン
【テーマコード（参考）】
5K030
【Ｆターム（参考）】
5K030GA03
5K030HB14
5K030JA07
5K030LE13
(57)【要約】
この出願の実施形態はパケット処理方法を開示する。一例において、連合チャネルが、ＩＰｖ６パケット内で搬送されて、複数の異なるタイプの制御チャネルを提供し得る。連合チャネルはユーザデータと共に伝送され得る。各タイプの制御チャネルが、少なくとも１つのタイプの制御・管理メッセージを搬送し、１つのタイプの制御・管理メッセージで、１つのタイプの制御及び管理機能を実装し得る。換言すれば、ＩＰｖ６パケットは、少なくとも１つのタイプの制御・管理メッセージを含み得る。ＩＰｖ６ネットワーク、特にＳＲｖ６ネットワークにおいて、トランシーバノード間の異なるタイプの制御・管理情報が全て、全般的な連合チャネルに基づいて搬送され得る。例えば、ＩＰｖ６ネットワークのために複数の制御及び管理機能を実装する必要がある場合に、複数の異なるタイプの制御・管理メッセージを全て、それら複数のタイプの制御・管理メッセージを搬送するために複数のプロトコルを使用することなく、連合チャネルを用いて搬送することができ、ＩＰｖ６ネットワーク上での制御及び管理の効率を効果的に向上させる。
【特許請求の範囲】
【請求項1】
パケット処理方法であって、第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを取得するステップであり、該第１のＩＰｖ６パケットは、連合チャネルを有し、該連合チャネルは、複数の異なるタイプの制御チャネルを搬送し、各タイプの制御チャネルが、少なくとも１つのタイプの制御・管理メッセージを搬送する、ステップと、
前記第１のＩＰｖ６パケットを転送するステップと、
を有する方法。
【請求項2】
パケット処理方法であって、第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを受信するステップであり、該第１のＩＰｖ６パケットは、連合チャネルを有し、該連合チャネルは、複数の異なるタイプの制御チャネルを搬送し、各タイプの制御チャネルが、少なくとも１つのタイプの制御・管理メッセージを搬送する、ステップと、
前記少なくとも１つのタイプの制御・管理メッセージを取得するステップと、
を有する方法。
【請求項3】
前記第１のＩＰｖ６パケットは指示情報を有し、該指示情報が前記連合チャネルを示す、請求項１又は２に記載の方法。
【請求項4】
前記指示情報はタイプ長さ値（ＴＬＶ）フィールド内で搬送され、該ＴＬＶフィールドのタイプフィールドが前記指示情報を搬送する、請求項３に記載の方法。
【請求項5】
前記ＴＬＶフィールドはチャネルタイプフィールドを有し、該チャネルタイプフィールドは、前記連合チャネルによって搬送される制御チャネルのタイプを示す、請求項４に記載の方法。
【請求項6】
前記連合チャネルは、前記第１のＩＰｖ６パケットの拡張ヘッダ内で搬送され、該拡張ヘッダは、ホップバイホップ（ＨＢＨ）オプションヘッダ又は宛先オプションヘッダ（ＤＯＨ）である、請求項１乃至５のいずれか一項に記載の方法。
【請求項7】
前記第１のＩＰｖ６パケットは、セグメントルーティングインターネットプロトコルバージョン６（ＳＲｖ６）パケットである、請求項１乃至５のいずれか一項に記載の方法。
【請求項8】
前記連合チャネルは、前記第１のＩＰｖ６パケットの拡張ヘッダ内で搬送され、該拡張ヘッダは、セグメントルーティングヘッダ（ＳＲＨ）である、請求項７に記載の方法。
【請求項9】
前記第１のＩＰｖ６パケットは識別情報を有し、該識別情報は第１パスを識別するために使用され、該第１パスは前記第１のＩＰｖ６パケットの伝送パスである、請求項１乃至８のいずれか一項に記載の方法。
【請求項10】
前記識別情報は、前記連合チャネルと前記第１パスとの間の関連付け関係を特定するために前記第１パス上のノードによって使用される、請求項９に記載の方法。
【請求項11】
前記第１のＩＰｖ６パケットは、セグメントルーティングインターネットプロトコルバージョン６（ＳＲｖ６）パケットであり、該ＳＲｖ６パケットのセグメントリスト（ｓｅｇｍｅｎｔ ｌｉｓｔ）又はパスセグメント（ｐａｔｈ ｓｅｇｍｅｎｔ）が前記識別情報を搬送する、請求項９又は１０に記載の方法。
【請求項12】
前記複数の異なるタイプの制御チャネルは、運用・管理・保守（ＯＡＭ）チャネルと、障害指示チャネル、リソース管理チャネル、シグナリング通信チャネル（ＳＣＣ）、及び管理通信チャネル（ＭＣＣ）、
のうちのいずれか１つ以上を有する、請求項１乃至１１のいずれか一項に記載の方法。
【請求項13】
前記障害指示チャネルによって搬送される制御・管理メッセージは障害指示情報を記録する、請求項１２に記載の方法。
【請求項14】
第１のＩＰｖ６パケットを前記取得するステップは、第２のＩＰｖ６パケットを受信し、該第２のＩＰｖ６パケットは、連合チャネルを有し、
前記第２のＩＰｖ６パケット内の前記連合チャネルに基づいて前記第２のＩＰｖ６パケットを処理して、前記第１のＩＰｖ６パケットを取得する、
ことを有する、請求項１又は請求項３乃至１３のいずれか一項に記載の方法。
【請求項15】
前記連合チャネルは、前記第１のＩＰｖ６パケットのペイロード内で搬送される、請求項１乃至５のいずれか一項に記載の方法。
【請求項16】
前記第１のＩＰｖ６パケットの前記ペイロードは更にユーザデータを搬送する、請求項１乃至１５のいずれか一項に記載の方法。
【請求項17】
パケット処理方法であって、第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを取得するステップであり、該第１のＩＰｖ６パケットは障害指示チャネルを有し、該障害指示チャネルは第１パスの障害指示情報を記録する、ステップと、
前記第１のＩＰｖ６パケットを転送するステップと、
を有する方法。
【請求項18】
第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを前記取得するステップは、第２のＩＰｖ６パケットを受信し、該第２のＩＰｖ６パケットは障害指示チャネルを有し、
前記第２のＩＰｖ６パケット内の前記障害指示チャネルに第１の障害指示情報を記録することで、前記第１のＩＰｖ６パケットを取得する、
ことを有する、請求項１６に記載の方法。
【請求項19】
パケット処理方法であって、第１パスのテールノードにより、第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを受信するステップであり、該第１のＩＰｖ６パケットは障害指示チャネルを有し、該障害指示チャネルは前記第１パスの障害指示情報を記録する、ステップと、
前記第１パスの前記障害指示情報を取得するステップと、
を有する方法。
【請求項20】
請求項１乃至１９のいずれか一項に記載の方法を実行するように構成された通信装置であって、請求項１乃至１９のいずれか一項に記載の方法における受信及び／又は送信に関係する動作を実施するように構成されたトランシーバユニットと、
前記受信及び／又は送信以外の動作を実行するように構成された処理ユニットと、
を有する通信装置。
【請求項21】
メモリ及びプロセッサを有する通信装置であって、前記メモリは、プログラムコードを格納するように構成され、
前記プロセッサは、請求項１乃至１９のいずれか一項に記載の方法を前記通信装置が実行するように、前記プログラムコード内の命令を実行するように構成される、
通信装置。
【請求項22】
プログラムを有するコンピュータプログラムプロダクトであって、前記プログラムがプロセッサ上で実行されるときに、請求項１乃至１９のいずれか一項に記載の方法が実施される、コンピュータプログラムプロダクト。
【請求項23】
通信システムであって、請求項１に記載の方法を実行するための通信装置と、請求項２乃至１６のいずれか一項に記載の方法を実行するための通信装置、又は
請求項１７又は１８に記載の方法を実行するための通信装置と、請求項１９に記載の方法を実行するための通信装置、
を有する通信システム。
【請求項24】
パケット処理装置であって、第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを取得するように構成された処理ユニットであり、該第１のＩＰｖ６パケットは、連合チャネルを有し、該連合チャネルは、複数の異なるタイプの制御チャネルを搬送し、各タイプの制御チャネルが、少なくとも１つのタイプの制御・管理メッセージを搬送する、処理ユニットと、
前記第１のＩＰｖ６パケットを転送するように構成された送信ユニットと、
を有する装置。
【請求項25】
パケット処理装置であって、第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを受信するように構成された受信ユニットであり、該第１のＩＰｖ６パケットは、連合チャネルを有し、該連合チャネルは、複数の異なるタイプの制御チャネルを搬送し、各タイプの制御チャネルが、少なくとも１つのタイプの制御・管理メッセージを搬送する、受信ユニットと、
前記少なくとも１つのタイプの制御・管理メッセージを取得するように構成された処理ユニットと、
を有する装置。
【請求項26】
前記第１のＩＰｖ６パケットは指示情報を有し、該指示情報が前記連合チャネルを示す、請求項２４又は２５に記載の装置。
【請求項27】
前記指示情報はタイプ長さ値（ＴＬＶ）フィールド内で搬送され、該ＴＬＶフィールドのタイプフィールドが前記指示情報を搬送する、請求項２６に記載の装置。
【請求項28】
前記ＴＬＶフィールドはチャネルタイプフィールドを有し、該チャネルタイプフィールドは、前記連合チャネルによって搬送される制御チャネルのタイプを示す、請求項２７に記載の装置。
【請求項29】
前記連合チャネルは、前記第１のＩＰｖ６パケットの拡張ヘッダ内で搬送され、該拡張ヘッダは、ホップバイホップ（ＨＢＨ）オプションヘッダ又は宛先オプションヘッダ（ＤＯＨ）である、請求項２４乃至２８のいずれか一項に記載の装置。
【請求項30】
前記第１のＩＰｖ６パケットは、セグメントルーティングインターネットプロトコルバージョン６（ＳＲｖ６）パケットである、請求項２４乃至２８のいずれか一項に記載の装置。
【請求項31】
前記連合チャネルは、前記第１のＩＰｖ６パケットの拡張ヘッダ内で搬送され、該拡張ヘッダは、セグメントルーティングヘッダ（ＳＲＨ）である、請求項３０に記載の装置。
【請求項32】
前記第１のＩＰｖ６パケットは識別情報を有し、該識別情報は第１パスを識別するために使用され、該第１パスは前記第１のＩＰｖ６パケットの伝送パスである、請求項２４乃至３１のいずれか一項に記載の装置。
【請求項33】
前記識別情報は、前記連合チャネルと前記第１パスとの間の関連付け関係を特定するために前記第１パス上のノードによって使用される、請求項３２に記載の装置。
【請求項34】
前記第１のＩＰｖ６パケットは、セグメントルーティングインターネットプロトコルバージョン６（ＳＲｖ６）パケットであり、該ＳＲｖ６パケットのセグメントリスト又はパスセグメントが前記識別情報を搬送する、請求項３２又は３３に記載の装置。
【請求項35】
前記複数の異なるタイプの制御チャネルは、運用・管理・保守（ＯＡＭ）チャネルと、障害指示チャネル、リソース管理チャネル、シグナリング通信チャネル（ＳＣＣ）、及び管理通信チャネル（ＭＣＣ）、
のうちのいずれか１つ以上を有する、請求項２４乃至３４のいずれか一項に記載の装置。
【請求項36】
前記障害指示チャネルによって搬送される制御・管理メッセージは障害指示情報を記録する、請求項３５に記載の装置。
【請求項37】
第１のＩＰｖ６パケットを前記取得することは、第２のＩＰｖ６パケットを受信し、該第２のＩＰｖ６パケットは、連合チャネルを有し、
前記第２のＩＰｖ６パケット内の前記連合チャネルに基づいて前記第２のＩＰｖ６パケットを処理して、前記第１のＩＰｖ６パケットを取得する、
ことを有する、請求項２４又は請求項２６乃至３６のいずれか一項に記載の装置。
【請求項38】
前記連合チャネルは、前記第１のＩＰｖ６パケットのペイロード内で搬送される、請求項２４乃至２８のいずれか一項に記載の装置。
【請求項39】
前記第１のＩＰｖ６パケットの前記ペイロードは更にユーザデータを搬送する、請求項２４乃至３８のいずれか一項に記載の装置。
【請求項40】
パケット処理装置であって、第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを取得するように構成された処理ユニットであり、該第１のＩＰｖ６パケットは障害指示チャネルを有し、該障害指示チャネルは第１パスの障害指示情報を記録する、処理ユニットと、
前記第１のＩＰｖ６パケットを転送するように構成された送信ユニットと、
を有する装置。
【請求項41】
前記処理ユニットは、第２のＩＰｖ６パケットを受信し、該第２のＩＰｖ６パケットは障害指示チャネルを有し、
前記第２のＩＰｖ６パケット内の前記障害指示チャネルに第１の障害指示情報を記録することで、前記第１のＩＰｖ６パケットを取得する、
ように構成されている、請求項３９に記載の装置。
【請求項42】
第１パスのテールノードに適用されるパケット処理装置であって、第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを受信するように構成された受信ユニットであり、該第１のＩＰｖ６パケットは障害指示チャネルを有し、該障害指示チャネルは前記第１パスの障害指示情報を記録する、受信ユニットと、
前記第１パスの前記障害指示情報を取得するように構成された処理ユニットと、
を有する装置。
【発明の詳細な説明】
【技術分野】
【0001】
この出願は、以下の特許出願に対する優先権を主張するものであり、それらのコンテンツ全体をここに援用する：
１．“通信方法及び装置”と題されて２０２０年１２月１１日に中国国家知的所有権管理局に出願された中国特許出願第２０２０１１４６３９７９．８号；
２．“パケット処理方法及び装置”と題されて２０２１年２月１０日に中国国家知的所有権管理局に出願された中国特許出願第２０２１１０１８３７６５．３号。
この出願は、通信分野に関し、特に、パケット処理方法及び装置に関する。
１．“通信方法及び装置”と題されて２０２０年１２月１１日に中国国家知的所有権管理局に出願された中国特許出願第２０２０１１４６３９７９．８号；
２．“パケット処理方法及び装置”と題されて２０２１年２月１０日に中国国家知的所有権管理局に出願された中国特許出願第２０２１１０１８３７６５．３号。
この出願は、通信分野に関し、特に、パケット処理方法及び装置に関する。
【背景技術】
【0002】
インターネットプロトコルバージョン６（Internet Protocol version 6，ＩＰｖ６）ネットワーク上で制御及び管理を実行するために、制御・管理メッセージが、ＩＰｖ６ネットワーク内のノード間で伝送され得る。例えば、伝送パス上のヘッドノードとテールノードとの間で制御・管理メッセージが伝送され得る。制御・管理メッセージを受信したノードが、制御・管理メッセージに基づいて対応する動作を実行して、ＩＰｖ６ネットワーク上で制御及び管理を実施し得る。１つのタイプの制御・管理メッセージで、１つのタイプの制御・管理機能を実装し得る。ＩＰｖ６ネットワーク上での制御及び管理は、例えば、伝送パスのレイテンシ及びパケット損失を決定すること、別の例では、伝送パスの接続性を試験すること、及び別の例では、伝送パス上のリソース管理を実行することといった、複数の態様をカバーする。
【0003】
現行では、制御・管理メッセージを搬送するための各制御・管理機能について独立にプロトコルを設計する必要がある。結果として、ＩＰｖ６ネットワーク上の様々な機能の制御及び管理を実行するために、ＩＰｖ６ネットワーク内のノード間で複数のプロトコルリンクを確立する必要がある。斯くして様々な制御・管理メッセージを送信することは複雑である。従って、ＩＰｖ６ネットワーク上で制御及び管理を実行することの効率が低い。
【発明の概要】
【0004】
この出願の一実施形態は、ＩＰｖ６ネットワーク上で制御及び管理を実施するためのパケット処理方法を提供する。
【0005】
第１態様によれば、この出願の実施形態はパケット処理方法を提供し、当該方法は、例えば、第１の通信装置によって実行され得る。第１の通信装置は、第１のＩＰｖ６パケットの伝送パス上のヘッドノード又は中間ノードに相当し得る。一例において、第１の通信装置は第１のＩＰｖ６パケットを取得することができ、該第１のＩＰｖ６パケットは連合チャネルを含む。該連合チャネルは、複数の異なるタイプの制御チャネルを搬送することができ、各タイプの制御チャネルが、少なくとも１つのタイプの制御・管理メッセージを搬送することができ、１つのタイプの制御・管理メッセージで、１つのタイプの制御及び管理機能を実装することができる。制御・管理メッセージは、例えば、プロトコルメッセージとし得る。換言すれば、第１のＩＰｖ６パケットは、少なくとも１つのタイプの制御・管理メッセージを含む。第１のＩＰｖ６パケットを取得した後に、第１の通信装置は第１のＩＰｖ６パケットを転送し得る。
【0006】
この出願では、全般的な連合チャネルがＩＰｖ６パケットにおいて設計され、該連合チャネルを使用することによって様々な異なるタイプの制御チャネルを搬送することができる。従って、ＩＰｖ６ネットワークのために複数の制御及び管理機能を実装する必要がある場合に、１つの全般的な連合チャネルが複数の異なるタイプの制御チャネルを搬送することができ、すなわち、複数のタイプの制御・管理メッセージを、それら複数のタイプの制御・管理メッセージを搬送するために複数のプロトコルを使用することなく、１つの全般的な連合チャネルで搬送し得る。従って、ネットワーク装置間での制御・管理シグナリングの量が削減され、制御・管理シグナリングの伝送方式が簡略化され、幾つかの新しい制御・管理チャネルをＩＰネットワークにおいてサポートすることができる。例えば、この出願の実施形態におけるシグナリング通信チャネルＳＣＣ、管理通信チャネルＭＣＣ、及び障害指示チャネルをサポートすることができ、ＩＰｖ６ネットワーク上での制御及び管理の効率を向上させる。連合チャネルが複数のプロトコルの制御・管理メッセージを搬送することで、１つのパケットを用いて複数のＴＬＶフィールドを搬送して、装置間で制御・管理情報を伝送するパケットの量を減らすことができる。取り得る一実装において、連合チャネルは一般的なＴＬＶフォーマットであることができ、ＴＬＶカプセル化をＩＰｖ６拡張ヘッダ内で行うことで、制御・管理メッセージのパケットカプセル化及び伝送方式を統一化及び簡略化し、例えばユーザデータグラムプロトコルポート番号エントリといった装置保守パラメータを減少させる。さらに、この出願における連合チャネルに基づいて、可変値長を持つＴＬＶフォーマットにおける制御・管理メッセージの伝送が、拡張によって更にサポートされ得る。従って、より多くのチャネル保守情報が搬送され得る。この出願のこの実施形態で提供されるソリューションに基づいて、ＩＰｖ６パケットヘッダを用いてメッセージ伝送が行われることで、パケットヘッダのコンテンツについて高速なパス処理を装置転送プレーン上で行うことができメッセージ処理効率を向上させる。
【0007】
一実装において、この出願における連合チャネルは、ＩＰｖ６拡張ヘッダ内で搬送され得る。従って、ユーザデータとともに連合チャネルを送ることをサポートし、その場（in-situ）フロー情報テレメトリを実装し得る。
【0008】
一実装において、この出願における連合チャネルは、代わりにＩＰｖ６パケットのペイロード内で搬送されてもよい。
【0009】
一実装において、第１の通信装置が第１のＩＰｖ６パケットの伝送パス上のヘッドノードに相当する場合、第１の通信装置が第１のＩＰｖ６パケットを生成し得る。
【0010】
特定の一実装において、伝送パスはＩＰｖ６トンネルであり、例えば、ＩＰカプセル化仮想拡張ローカルエリアネットワーク（virtual extensible local area network，ＶＸＬＡＮ）トンネルとすることができ、あるいはＳＲｖ６トンネルとすることができる。
【0011】
一実装で、第１の通信装置が第１のＩＰｖ６パケットの伝送パス上の中間ノードに相当する場合、特定の実装において、第１の通信装置が第１のＩＰｖ６パケットを取得するときに、例えば、第１の通信装置は、第１の通信装置の上流ノードから第２のＩＰｖ６パケットを受信することができ、第２のＩＰｖ６パケットが連合チャネルを含む。第２のＩＰｖ６パケットを受信した後に、第１の通信装置は、連合チャネルに基づいて第２のＩＰｖ６パケットを処理して、第１のＩＰｖ６パケットを取得し得る。例えば、第１の通信装置は、連合チャネルで搬送される少なくとも１つのタイプの制御・管理メッセージに基づいて、対応する情報（例えば、ローカルタイムスタンプ）を第２のＩＰｖ６パケットに追加して、第１のＩＰｖ６パケットを取得し得る。この出願における方法に基づいて、中間ノードは連合チャネルを解析することができる。例えば、中間ノードは、関係するＯＡＭ検出情報、リソース予約情報、又は障害指示情報を連合チャネル内に記録し得る。従って、より精緻な制御及び管理を実装することができる。
【0012】
第２態様によれば、この出願の一実施形態はパケット処理方法を提供する。当該方法は、例えば、第１の通信装置によって実行されることができ、第１の通信装置は、例えば、第１のＩＰｖ６パケットの伝送パス上のテールノードに相当し得る。一例において、第１の通信装置は第１のＩＰｖ６パケットを受信することができ、該第１のＩＰｖ６パケットは連合チャネルを含み、該連合チャネルは複数の異なるタイプの制御チャネルを搬送することができ、各タイプの制御チャネルが、少なくとも１つのタイプの制御・管理メッセージを搬送する。第１のＩＰｖ６パケットを受信した後に、第１の通信装置は、上記少なくとも１つのタイプの制御・管理メッセージに対応する動作を実行し得る。第１のＩＰｖ６パケットが連合チャネルを含むので、ＩＰｖ６ネットワークのために複数の制御及び管理機能を実装する必要がある場合に、複数のタイプの制御・管理メッセージを、それら複数のタイプの制御・管理メッセージを搬送するために複数のプロトコルを使用することなく、連合チャネルを用いて搬送することができ、ＩＰｖ６ネットワーク上での制御及び管理の効率を向上させる。また、第１のＩＰｖ６パケットの伝送パス上のノード間で複数のプロトコルを走らせる必要がない。従って、複数のプロトコルを走らせることによって占有される帯域幅が削減され、対応してサービスデータ伝送効率も向上される。
【0013】
第１態様及び第２態様について：
一実装において、連合チャネルは、少なくとも１つの制御・管理メッセージを搬送することができ、該制御・管理メッセージは、パスを制御及び／又は管理するためのメッセージである。第１のＩＰｖ６パケットを受信するノードが、連合チャネルに関連付けられたパスを決定することを可能にするために、第１のＩＰｖ６パケットは更に識別情報を含むことができ、該識別情報は、第１パスを識別するために使用され、該第１パスが第１のＩＰｖ６パケットの伝送パスである。斯くして、第１のＩＰｖ６パケットを受信するノードは、第１パスを制御及び／又は管理するための連合チャネル内の少なくとも１つの制御・管理メッセージを決定するために、第１のＩＰｖ６パケット内の連合チャネルと第１パスとの間の連関関係を特定し得る。さらに、第１のＩＰｖ６パケットを受信するノードは、該識別情報と連合チャネル内の上記少なくとも１つの制御・管理メッセージとに基づいて、対応する動作を実行し得る。
一実装において、連合チャネルは、少なくとも１つの制御・管理メッセージを搬送することができ、該制御・管理メッセージは、パスを制御及び／又は管理するためのメッセージである。第１のＩＰｖ６パケットを受信するノードが、連合チャネルに関連付けられたパスを決定することを可能にするために、第１のＩＰｖ６パケットは更に識別情報を含むことができ、該識別情報は、第１パスを識別するために使用され、該第１パスが第１のＩＰｖ６パケットの伝送パスである。斯くして、第１のＩＰｖ６パケットを受信するノードは、第１パスを制御及び／又は管理するための連合チャネル内の少なくとも１つの制御・管理メッセージを決定するために、第１のＩＰｖ６パケット内の連合チャネルと第１パスとの間の連関関係を特定し得る。さらに、第１のＩＰｖ６パケットを受信するノードは、該識別情報と連合チャネル内の上記少なくとも１つの制御・管理メッセージとに基づいて、対応する動作を実行し得る。
【0014】
一実装において、上述の識別情報は、例えば、パス識別子（path ID）とし得る。
【0015】
一実装において、上述の識別情報は、エンドツーエンドパスを識別してもよいし、エンドツーエンドパス内のパスのセグメントを識別してもよい。
【0016】
一実装において、識別情報は、連合チャネル内で搬送されてもよいし、連合チャネルの外で搬送されてもよい。
【0017】
一実装において、第１のＩＰｖ６パケットがＳＲｖ６パケットである場合、ＳＲｖ６パケットのＳＲＨに含まれるセグメントリスト（segment list）がＳＲｖ６パケットの伝送パスを示し得る。従って、識別情報は、ＳＲｖ６パケットのセグメントリストを用いることによって搬送されてもよく、すなわち、識別情報はＳＲｖ６パケットのセグメントリストであってもよい。この実装では、ＳＲｖ６伝送パス内の特定のノードのホップバイホップ及びエンドツーエンドの制御及び管理が実装され得る。例えば、ＯＡＭ検出のために、ホップバイホップ及びエンドツーエンドの接続性監視及び性能測定がサポートされ得る。例えば、リソース予約管理のために、ホップバイホップリソース予約管理がサポートされ得る。
【0018】
一実装において、ＳＲｖ６パケットについて、ＳＲｖ６パケットのＳＲＨは更に、パスセグメント（path segment）フィールドを含むことができ、ＳＲｖ６パスを識別するためにパスセグメントフィールドの値が使用される。ＳＲｖ６パケットとして使用される第１のＩＰｖ６パケットがパスセグメントフィールドを含む場合、パスセグメントフィールドの値が、第１のＩＰｖ６パケットの伝送パスを識別するために使用される。従って、識別情報は、代わりにＳＲｖ６パケットのパスセグメントフィールド内で搬送されてもよい。
【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】
一実装において、第１のＩＰｖ６パケットは、セグメントルーティングインターネットプロトコルバージョン６（ＳＲｖ６）パケットであり、ＳＲｖ６パケットのセグメントリスト（segment list）又はパスセグメント（path segment）が識別情報を搬送する。
【0046】
一実装において、連合チャネルは、第１パスを識別するために使用される識別情報を含む。
【0047】
第５態様によれば、この出願は、トランシーバユニットと処理ユニットとを含む通信装置を提供する。トランシーバユニットは、第１態様又は第１態様のいずれか１つに従った受信及び送信動作を実行するように構成され、処理ユニットは、第１態様又は第１態様のいずれか１つに従った受信及び送信動作以外の動作を実行するように構成される。あるいは、トランシーバユニットは、第２態様又は第２態様のいずれか１つに従った受信及び送信動作を実行するように構成され、処理ユニットは、第２態様又は第２態様のいずれか１つに従った受信及び送信動作以外の動作を実行するように構成される。あるいは、トランシーバユニットは、第３態様又は第３態様のいずれか１つに従った受信及び送信動作を実行するように構成され、処理ユニットは、第３態様又は第３態様のいずれか１つに従った受信及び送信動作以外の動作を実行するように構成される。あるいは、トランシーバユニットは、第４態様又は第４態様のいずれか１つに従った受信及び送信動作を実行するように構成され、処理ユニットは、第４態様又は第４態様のいずれか１つに従った受信及び送信動作以外の動作を実行するように構成される。
【0048】
第６態様によれば、この出願は通信装置を提供する。当該通信装置はメモリ及びプロセッサを含み、メモリはプログラムコードを格納するように構成され、プロセッサはプログラムコード内の命令を実行するように構成され、当該通信装置は、第１態様若しくは第１態様のいずれか１つに従った方法を実行することを可能にされ、あるいは、当該通信装置は、第２態様若しくは第２態様のいずれか１つに従った方法を実行することを可能にされ、あるいは、当該通信装置は、第３態様若しくは第３態様のいずれか１つに従った方法を実行することを可能にされ、あるいは、当該通信装置は、第４態様若しくは第４態様のいずれか１つに従った方法を実行することを可能にされる。
【0049】
第７態様によれば、この出願は通信装置を提供する。当該通信装置は、通信インタフェースとプロセッサとを含む。通信インタフェースは、第１態様又は第１態様のいずれか１つに従った受信及び送信動作を実行するように構成され、プロセッサは、第１態様又は第１態様のいずれか１つに従った受信及び送信動作以外の動作を実行するように構成される。あるいは、通信インタフェースは、第２態様又は第２態様のいずれか１つに従った受信及び送信動作を実行するように構成され、プロセッサは、第２態様又は第２態様のいずれか１つに従った受信及び送信動作以外の動作を実行するように構成される。あるいは、通信インタフェースは、第３態様又は第３態様のいずれか１つに従った受信及び送信動作を実行するように構成され、プロセッサは、第３態様又は第３態様のいずれか１つに従った受信及び送信動作以外の動作を実行するように構成される。あるいは、通信インタフェースは、第４態様又は第４態様のいずれか１つに従った受信及び送信動作を実行するように構成され、プロセッサは、第４態様又は第４態様のいずれか１つに従った受信及び送信動作以外の動作を実行するように構成される。
【0050】
第８態様によれば、この出願はコンピュータ読み取り可能記憶媒体を提供し、当該コンピュータ読み取り可能記憶媒体は命令を格納し、該命令がコンピュータ上で実行されるとき、該コンピュータは、第１態様若しくは第１態様のいずれか１つに従った方法を実行することを可能にされ、あるいは、該コンピュータは、第２態様若しくは第２態様のいずれか１つに従った方法を実行することを可能にされ、あるいは、該コンピュータは、第３態様若しくは第３態様のいずれか１つに従った方法を実行することを可能にされ、あるいは、該コンピュータは、第４態様若しくは第４態様のいずれか１つに従った方法を実行することを可能にされる。
【0051】
第９態様によれば、この出願は通信システムを提供する。当該通信システムは、第５態様若しくは第６態様若しくは第７態様に従った通信装置であって、第１態様若しくは第１態様のいずれか１つに従った方法を実行する通信装置、又は、第５態様若しくは第６態様若しくは第７態様に従った通信装置であって、第２態様若しくは第２態様のいずれか１つに従った方法を実行する通信装置を含む。
【0052】
第１０態様によれば、この出願は通信システムを提供する。当該通信システムは、第５態様若しくは第６態様若しくは第７態様に従った通信装置であって、第３態様若しくは第３態様のいずれか１つに従った方法を実行する通信装置、又は、第５態様若しくは第６態様若しくは第７態様に従った通信装置であって、第４態様若しくは第４態様のいずれか１つに従った方法を実行する通信装置を含む。
【図面の簡単な説明】
【0053】
この出願の実施形態における又は従来技術における技術的ソリューションをいっそう明確に説明するために、以下にて、実施形態又は従来技術を説明するのに使用される添付図面を簡単に紹介する。明らかなことには、以下の説明における添付図面は、この出願の一部の実施形態を示すに過ぎず、当業者は、創造的労力なしに、これらの添付図面から他の添付図面をなおも導出し得る。
【図1a】この出願の一実施形態に従ったＩＰｖ６ネットワークの構成の概略図である。
【図1b】この出願の一実施形態に従ったパケット処理方法の概略フローチャートである。
【図2a-1】この出願の一実施形態に従ったＴＬＶフィールドの構造の概略図である。
【図2a-2】この出願の一実施形態に従ったＴＬＶフィールドの構造の概略図である。
【図2b】この出願の一実施形態に従った障害指示メッセージの構造の概略図である。
【図2c】この出願の一実施形態に従ったメッセージリソース予約要求メッセージの構造の概略図である。
【図2d】この出願の一実施形態に従ったリソースステータス更新メッセージの構造の概略図である。
【図2e】この出願の一実施形態に従ったリソース取消メッセージの構造の概略図である。
【図2f】この出願の一実施形態に従った第１のＩＰｖ６パケットの構造の概略図である。
【図2g】この出願の一実施形態に従った第１のＩＰｖ６パケットの構造の概略図である。
【図3】この出願の一実施形態に従ったパケット処理方法の概略フローチャートである。
【図4】この出願の一実施形態に従ったパケット処理方法の概略フローチャートである。
【図5】この出願の一実施形態に従ったパケット処理方法の概略フローチャートである。
【図6】この出願の一実施形態に従った通信装置の構成の概略図である。
【図7】この出願の一実施形態に従った通信装置の構成の概略図である。
【図8】この出願の一実施形態に従った通信装置の構成の概略図である。
【発明を実施するための形態】
【0054】
この出願の一実施形態は、ＩＰｖ６ネットワーク上で制御及び管理を実施するためのパケット処理方法を提供する。
【0055】
この出願の一実施形態に従ったＩＰｖ６ネットワークの構成の概略図である図１ａを参照されたい。
【0056】
図１ａに示すネットワークシナリオにおいて、カスタマエッジ（customer edge，ＣＥ）ＣＥ１が、ＩＰｖ６ネットワーク１００を使用することによってＣＥ２と通信するとし得る。ノードプロバイダエッジ（provider edge，ＰＥ）装置ＰＥ１、ＰＥ２、並びにプロバイダバックボーン（provider，Ｐ）装置Ｐ１、Ｐ２、Ｐ３、及びＰ４は全てＩＰｖ６ネットワーク１００内のノードである。伝送パス１：ＰＥ１－Ｐ１－Ｐ２－ＰＥ２は、ＩＰｖ６ネットワーク１００における伝送パスである。一例において、ＩＰｖ６ネットワーク１００は、セグメントルーティング（segment routing，ＳＲ）技術が適用されるネットワークとすることができ、すなわち、ＩＰｖ６ネットワーク１００は、セグメントルーティングインターネットプロトコルバージョン６（segment routing Internet Protocol version 6，ＳＲｖ６）ネットワークであるとすることができる。この場合、上述のノードＰＥ１、ＰＥ２、Ｐ１、Ｐ２、Ｐ３、及びＰ４は全て、ＳＲｖ６転送をサポートするノードであるとし得る。一例において、ネットワークは更に、例えばネットワーク装置を制御及び／又は管理するように構成されたコントローラといった、制御・管理装置を含み得る。例えば、該コントローラは、ネットワークトポロジに基づいてパス計算を実行し得る。
【0057】
一例において、ＩＰｖ６ネットワーク１００はＳＲｖ６ネットワークであり、コントローラが、ＳＲｖ６ネットワーク内の伝送パスを計算し、ＳＲｖ６転送パスを示すセグメントリストをＳＲｖ６ネットワーク内のノードに送達する。例えば、コントローラは、伝送パス１を示すセグメントリストをＰＥ１に送達することができ、ＰＥ１は、伝送パス１を示すセグメントリストに基づいてＳＲｖ６パケットを生成することができる。他の一例において、コントローラは、伝送パスＰＥ２－Ｐ２－Ｐ１－ＰＥ１を示すセグメントリストをＰＥ２に送達することができ、ＰＥ２は、伝送パスＰＥ２－Ｐ２－Ｐ１－ＰＥ１を示すセグメントリストに基づいてＳＲｖ６パケットを生成することができる。
【0058】
なお、図１ａは、理解を容易にするために示されているにすぎず、この出願の実施形態に対する限定を構成するものではない。ＩＰｖ６ネットワークのネットワークアーキテクチャは、図１ａに示される形態に限定されない。
【0059】
現在、ＩＰｖ６ネットワーク上での制御及び管理は、例えば、伝送パス（例えば、図１ａに示される伝送パス１）のレイテンシ及びパケット損失を決定すること、別の例では、伝送パスの接続性を試験すること、及び別の例では、伝送パス上のリソース管理を実行することといった、複数の態様をカバーする。制御・管理メッセージを搬送するための各制御・管理機能について独立にプロトコルを設計する必要がある。結果として、ＩＰｖ６ネットワーク上で制御及び管理を実行することの効率が低い。さらに、ノードについて、複数のプロトコルを走らせることは帯域幅を占有し、それが結果としてサービスデータ伝送効率を低下させる。現在、プロトコルを用いて制御・管理メッセージを搬送して、対応する制御及び管理機能を実装していることについて、説明のために例を提供する。
【0060】
例１： セグメントルーティングインターネットプロトコルバージョン６（segment routing Internet Protocol version 6，ＳＲｖ６）セグメント識別子（segment identifier，ＳＩＤ）に対する接続性及び可用性検出を実装するために、ＩＰｖ６プロトコルのｐｉｎｇ機能が使用されることがある。ここで言及されるＳＩＤは、例えば、図１ａに示すノードＰＥ２に対応するＳＩＤとし得る。Ｉパケット検出ポイントから宛先アドレスまでのホップバイホップ障害位置特定を実装し、ＳＲｖ６ ＳＩＤのパスをトレースするために、Ｐｖ６プロトコルのトレースルート（trace route）機能が使用されることがあるい。ここで言及されるパケット検出ポイントと宛先アドレスとの間のパスは、例えば、図１ａに示される伝送パス１とし得る。
【0061】
例２： 双方向アクティブ測定プロトコル（two-way active measurement protocol，ＴＷＡＭＰ）パケット及び単純双方向アクティブ測定プロトコル（simple two-way active measurement protocol，ＳＴＡＭＰ）パケットを測定パケットとして別々に搬送するために、ユーザデータグラムプロトコル（user datagram protocol，ＵＤＰ）パケットが使用されることがあり、ＰＥ１とＰＥ２との間での双方向レイテンシ、一方向パケット損失率、及び一方向ジッタを測定するために、ＰＥ１とＰＥ２との間で測定パケットが送られる。
【0062】
例３： 障害検出機能を実装するために、双方向転送検出（bidirectional forwarding detection，ＢＦＤ）プロトコルが使用されることがある。具体的な詳細については、リクエストフォーコメンツ（request for comments，ＲＦＣ）５８８０の関連する説明部分を参照されたく、詳細をここで説明することはしない。
【0063】
例４： リソース予約機能を実装するために、リソース予約プロトコル（resource reservation protocol，ＲＳＶＰ）が使用されることがある。具体的な詳細については、ＲＦＣ ３２０９の関連する説明部分を参照されたく、詳細をここで説明することはしない。
【0064】
しかしながら、上述の４つの例に示される対応する制御及び管理機能を実装する方式では、各方式が一部の制御及び管理機能のみをサポートする。加えて、各方式がＩＰ上位層プロトコルカプセル化を使用する必要があり、ノードが上位層プロトコル機能をサポートする必要があり、処理のために上位層プロトコルの制御プレーンが必要とされる。ここで言及されるＩＰ上位層プロトコルカプセル化は、レイヤ４（layer 4，Ｌ４）プロトコルカプセル化、Ｌ５プロトコルカプセル化、Ｌ６プロトコルカプセル化、又はＬ７プロトコルカプセル化を指す。上述の４つの例に記載された複数の制御及び管理機能を同時に実装するために、異なるプロトコル間で類似の機能を有するセッション識別情報が別々に搬送され（例えば、ＳＴＡＭＰとＢＦＤの両方がＵＤＰポート番号を搬送する）、冗長で繰り返して搬送される情報につながる。
【0065】
例５： 例えば伝送パス１を用いてＰＥ１によってＰＥ２に伝送されるＳＲｖ６パケットといった、ＳＲｖ６パケットにおいて、ＳＲｖ６パケットのセグメントルーティングヘッダ（segment routing header，ＳＲＨ）において０ビット染色マーカが定義されることがあり、それが、テレメトリ（telemetry）データを収集及び出力するか否かの基礎として用いられる。例えばＰ１、Ｐ２、又はＰＥ２などのＳＲｖ６ノードにおいて、受信したパケットが０ビット染色マーカを搬送している場合、そのノードは、データ収集を実施するために、受信した元のＳＲｖ６パケットをコピーし、コピーしたＳＲｖ６パケットにタイムスタンプを追加し、そして、該パケットをコントローラに送信し得る。コントローラは、収集したデータ情報を処理して、伝送パス１の又は伝送パス１内のＳＲｖ６パスのセグメントのトラフィックサンプリング結果を取得して、例えば、伝送パス１の又は伝送パス１内のＳＲｖ６パスのセグメントの伝送レイテンシを取得し得る。確かなことには、コピーしたＳＲｖ６パケットにタイムスタンプを追加することに加えて、０ビット染色マーカを受信したノードは、コピーしたＳＲｖ６パケットに更に他のデータを追加してもよく、それをここで１つずつ説明することはしない。
【0066】
しかしながら、例５に示される対応する制御及び管理機能を実装する方式は、ＳＲＨにおいて０ビット染色マーカを定義するものである。従って、この方式は、ＳＲｖ６転送シナリオにのみ適用可能であり、転送のためにＳＲＨを使用しない純粋なＩＰｖ６転送ノードには適用可能でない。
【0067】
例えば産業用インターネットなどのアプリケーションシナリオの出現に伴い、元の“物理層＋リンク層＋アプリケーション層”をメインストリームのプロトコルスタックとして使用する産業分野に、ＩＰ層技術が導入され、これが、オペレーションテクノロジー（operation technology，ＯＴ）システム間の長距離及び大規模伝送を実装するための相互接続技術として使用される。また、産業用ＯＴシステムは、一般的に閉じたシステムであり、自律システム内で効率的な伝送を実現するために、非常に単純化されたプロトコルスタックが必要とされる。従って、例えば運用・管理・保守（operation, administration and maintenance，ＯＡＭ）、管理通信チャネル（management communication channel，ＭＣＣ）、ＩＰ層のリソース予約などの複数の異なる制御及び管理機能を実装するために、過度に多くのプロトコルを導入することは不可能である。
【0068】
これに鑑み、この出願の一実施形態はパケット処理方法を提供する。この出願のこの実施形態で提供されるパケット処理方法はＩＰｖ６ネットワークに適用され得る。ＩＰｖ６ネットワークのネットワーク構造は、この出願のこの実施形態において特に限定されない。例えば、ＩＰｖ６ネットワークのアーキテクチャは図１ａに示され得る。一部の例において、ＩＰｖ６ネットワーク内の一部の又は全てのノードがＳＲｖ６をサポートし得る。以下の実施形態で言及される第１パスは、例えば、図１ａに示される伝送パス１とし得る。
【0069】
この出願のこの実施形態で提供されるパケット処理方法を説明する前に、先ず、この出願の実施形態に関係する用語を説明する。
【0070】
連合チャネル： 連合チャネルは制御チャネルを提供することができる。この出願では、１つの連合チャネルを用いることによって、複数の異なるタイプの制御チャネルを提供することができる。換言すれば、この出願で提供される全般的な連合チャネルを用いて、異なるタイプの制御チャネルが搬送される。必要に応じて、１つの連合チャネルが１つ以上の制御チャネルを搬送し得る。各タイプの制御チャネルが、少なくとも１つのタイプの制御・管理メッセージを搬送することができる。
【0071】
制御チャネル： 制御チャネルは制御・管理メッセージを搬送し、１つの制御チャネルが、少なくとも１つのタイプの制御・管理メッセージを搬送し得る。
【0072】
制御・管理メッセージ： 制御・管理メッセージは、例えばトンネルといったパスを制御及び／又は管理することができるメッセージである。制御・管理メッセージのフォーマット及び制御・管理メッセージに具体的なコンテンツは、制御・管理メッセージが対応する制御及び／又は管理機能を実装することができるのであれば、この出願の実施形態において特に限定されない。一例において、１つのタイプの制御機能又は１つのタイプの管理機能を実装するために、１つのタイプの制御・管理メッセージが使用され得る。
【0073】
以下、添付図面を参照してパケット処理方法を説明する。
【0074】
なお、この出願のこの実施形態で言及されるタイプ長さ値（type length value，ＴＬＶ）フィールドは、タイプ、長さ、及び値の３つのフィールドを含み得る。ＴＬＶフィールドの長さが固定であるとき、この出願におけるＴＬＶフィールドは代わりに、長さフィールドを含まないタイプ値（ＴＶ）フィールドとし得る。
【0075】
図１ｂを参照するに、図１ｂは、この出願の一実施形態に従ったパケット処理方法の概略フローチャートである。図１ｂに示すパケット処理方法１００は、第１の通信装置によって実行されることができ、該第１の通信装置は、ＩＰｖ６ネットワーク内のノードに相当し得る。例えば、第１の通信装置は、図１ａに示したノードＰＥ１に相当してもよいし、図１ａに示したノードＰ１に対応してもよい。
【0076】
この出願のこの実施形態で言及される通信装置は、例えば交換機又はルータなどのネットワーク装置であってよいし、例えばネットワーク装置上のボード又はラインカードといった、ネットワーク装置上のコンポーネントの部分であってよいし、ネットワーク装置上の機能モジュールであってよいし、この出願における方法を実装するように構成されたチップであってよい。これはこの出願のこの実施形態において特に限定されることではない。通信装置は、例えば、以下に限られないが、イーサネット（登録商標）ケーブル又は光ケーブルを用いて、直接接続され得る。
【0077】
この出願のこの実施形態において、通信装置がノードに相当するとは、通信装置がノード自体であり得ること、又はノード上のコンポーネントの部分であり得ることを指す。この出願のこの実施形態におけるノードは、例えば交換機又はルータなどのネットワーク装置とし得る。
【0078】
この出願の実施形態における図２ａ－１から図２ｇは、この出願の実施形態で言及される関連コンテンツの理解を容易にするための取り得る例として示されているにすぎず、この出願の実施形態に対する限定を構成するものではない。
【0079】
方法１００は、例えば、以下のＳ１０１及びＳ１０２を含み得る。
【0080】
Ｓ１０１： 第１のＩＰｖ６パケットを取得し、該第１のＩＰｖ６パケットは連合チャネルを含み、該連合チャネルは複数の異なるタイプの制御チャネルを搬送し、各タイプの制御チャネルが少なくとも１つのタイプの制御・管理メッセージを搬送する。
【0081】
この出願のこの実施形態において、第１の通信装置が第１のＩＰｖ６パケットの伝送パス上のヘッドノードに相当する場合、第１の通信装置は第１のＩＰｖ６パケットを生成し得る。第１の通信装置が第１のＩＰｖ６パケットの伝送パス上の中間ノードに相当する場合、第１の通信装置は上流ノードから第２のＩＰｖ６パケットを受信することができ、該第２のＩＰｖ６パケットが連合チャネルを含み、第１の通信装置は、第２のＩＰｖ６パケット内の連合チャネルに基づいて第２のＩＰｖ６パケットを処理して、第１のＩＰｖ６パケットを取得し得る。なお、第２のＩＰｖ６パケットに含まれる連合チャネルの具体的なコンテンツは、第１のＩＰｖ６パケット内の連合チャネルに含まれる具体的なコンテンツとは異なっていてもよく、確かなことには、同じであってもよい。同じであるか異なるかは、ノードが受信したパケット内の連合チャネルを処理する必要があるかに依存する。これはこの出願のこの実施形態において特に限定されることではない。確かなことには、第１の通信装置が第１のＩＰｖ６パケットの伝送パス上の中間ノードに相当する場合、第１の通信装置は代わりに、上流ノードから第１のＩＰｖ６パケットを受信してもよい。連合チャネルに基づいて第２のＩＰｖ６パケットに対して第１の通信装置によって実行される処理の具体的な実装については、以下の関係する説明を参照されたく、詳細をここで説明することはしない。
【0082】
この出願のこの実施形態において、ＩＰｖ６ネットワーク上での制御及び管理の効率を改善するために、ＩＰｖ６パケットは拡張されることができ、連合チャネルを反映するようにＩＰｖ６パケット内で一般フィールドが拡張される。一般フィールドは、少なくとも１つの制御チャネルを搬送することができ、１つのタイプの制御チャネルが、少なくとも１つのタイプの制御・管理メッセージに対応する。ＩＰｖ６パケットのペイロードが拡張されてもよく、連合チャネルを反映するようにペイロード内で一般フィールドが拡張されることができ、あるいは、ＩＰｖ６パケットの拡張ヘッダが拡張されてもよく、連合チャネルを反映するように一般フィールドが拡張されることができる。換言すれば、連合チャネルは、第１のＩＰｖ６パケットのペイロード内で搬送されてもよいし、第１のＩＰｖ６パケットの拡張ヘッダ内で搬送されてもよい。
【0083】
一例において、ＩＰｖ６パケットの拡張ヘッダが拡張される場合、指示情報を搬送するようにフィールドを拡張することができ、該指示情報が、ＩＰｖ６パケットの拡張ヘッダが連合チャネルを搬送することを指し示す。換言すれば、一例において、第１のＩＰｖ６パケットにおいて、第１のＩＰｖ６パケットの拡張ヘッダが連合チャネルを含み、第１のＩＰｖ６パケットの拡張ヘッダは更に指示情報を含み、該指示情報が、第１のＩＰｖ６パケットの拡張ヘッダが連合チャネルを含むことを指し示す。
【0084】
この出願のこの実施形態の一実装において、指示情報は、拡張ヘッダのタイプ長さ値（type length value，ＴＬＶ）フィールド内で搬送され得る。換言すれば、ＩＰｖ６パケットの拡張ヘッダが拡張される場合、指示情報を搬送するようにＴＬＶフィールドが拡張され得る。説明のための例：第１のＩＰｖ６パケットの拡張ヘッダはＴＬＶフィールド１を含み、ＴＬＶフィールド１が指示情報を搬送する。一例において、拡張されたＴＬＶフィールドのタイプフィールドが指示情報を搬送し得る。
【0085】
この出願のこの実施形態の一実装において、連合チャネルは代わりに、拡張ヘッダのＴＬＶフィールド内で搬送されてもよい。換言すれば、ＩＰｖ６パケットの拡張ヘッダが拡張される場合に、連合チャネルを搬送するようにＴＬＶフィールドが拡張され得る。説明のための例：第１のＩＰｖ６パケットの拡張ヘッダはＴＬＶフィールド２を含み、ＴＬＶフィールド２が連合チャネルを搬送する。
【0086】
一実装において、連合チャネルがＴＬＶフィールド２を用いて搬送されるときに、連合チャネルが複数のタイプの制御チャネルを搬送する場合、ＴＬＶフィールド２は、各タイプの制御チャネルの指示情報を含むことができ、各タイプの制御チャネルの指示情報が、ＴＬＶフィールド２に含まれる制御チャネルのタイプを指し示す。例えば、各タイプの制御チャネルの指示情報は、ＴＬＶフィールド２の値フィールド内で搬送され得る。各制御チャネルの指示情報は、各制御チャネルに対応する指示ビットの値であってもよいし、各制御チャネルを指し示す特定の値であってもよい。これはこの出願のこの実施形態において特に限定されることではない。例えば、ＴＬＶフィールド２において、制御チャネル１及び制御チャネル２に対応する指示ビットの値がどちらも１であり、且つ他の制御チャネルに対応する指示ビットの値が０である場合、それは、ＴＬＶフィールドが制御チャネル１及び制御チャネル２を含むことを指し示す。ここで言及される指示ビットは、例えば、１ビットを含み得る。他の一例において、ＴＬＶフィールドの値フィールドに値１が含まれ、且つ値１が制御チャネル１に対応する場合、それは、ＴＬＶフィールドが制御チャネル１を含むことを指し示す。ここで言及される値１は、例えば、図２ａ－１又は図２ａ－２に示されるチャネルタイプ（channel type）フィールド内で搬送され得る。
【0087】
なお、この出願のこの実施形態の一実装において、同じＴＬＶフィールド内で指示情報及び連合チャネルが搬送されてもよく、すなわち、ＴＬＶフィールド１とＴＬＶフィールド２が同一のＴＬＶフィールドであってもよい。この場合、指示情報はＴＬＶフィールドのタイプフィールドで搬送されることができ、連合チャネルはＴＬＶフィールドの値フィールドで搬送される。このソリューションを使用することにより、ＩＰｖ６パケットが拡張されるときに、複数のＴＬＶフィールドを拡張する必要はなく、１つのＴＬＶフィールドのみを拡張すればよい。
【0088】
一実装において、指示情報及び連合チャネルが同一のＴＬＶフィールド内で搬送され得る場合、ＴＬＶフィールドは更にチャネルタイプフィールドを含むことができ、該チャネルタイプフィールドが、連合チャネルによって搬送される制御チャネルのタイプを指し示す。この場合、ＴＬＶフィールドのタイプフィールドが指示情報を搬送し、該指示情報が、ＴＬＶフィールド内で搬送されるコンテンツが連合チャネルであることを指し示す。ＴＬＶフィールドの値フィールドがチャネルタイプフィールドを含み、該チャネルタイプフィールドが、連合チャネルによって搬送される制御チャネルのタイプを指し示す。連合チャネルが複数のタイプの制御チャネルを搬送するとき、ＴＬＶフィールドの値フィールドは複数のチャネルタイプフィールドを含むことができ、該複数のチャネルタイプフィールドは上記複数のタイプの制御チャネルと一対一の対応関係にある。
【0089】
この場合、ＴＬＶフィールドの構造について、図２ａ－１及び図２ａ－２を参照されたい。図２ａ－１及び図２ａ－２はどちらも、この出願の一実施形態に従ったＴＬＶフィールドの構造の概略図である。図２ａ－１は、連合チャネルが１つのタイプの制御チャネルを搬送する場合のＴＬＶフィールドの構造を示しており、図２ａ－２は、連合チャネルが複数のタイプの制御チャネルを搬送する場合のＴＬＶフィールドの構造を示している。
【0090】
【0091】
チャネルタイプフィールド２０２及びチャネルタイプフィールド２０４はチャネルタイプを搬送する。
【0092】
予約（reserved）フィールドは、後にＴＬＶフィールドを拡張するために取っておかれるフィールドであり、予約フィールドはオプションのフィールドである。
【0093】
値フィールド２０３は、チャネルタイプ２０２によって示される制御チャネルによって搬送される少なくとも１つの制御・管理メッセージを搬送する。一例において、値フィールド２０３は、少なくとも１つのサブ（sub）ＴＬＶを含むことができ、１つのサブＴＬＶが１つのタイプの制御・管理メッセージを搬送する。値フィールド２０３の長さは、搬送される制御・管理メッセージに基づいて決定されてもよいし、固定長であってもよく、これはここで限定されることではない。
【0094】
値フィールド２０５は、チャネルタイプ２０４によって搬送される少なくとも１つの制御・管理メッセージを搬送する。一例において、値フィールド２０５は、少なくとも１つのサブ（sub）ＴＬＶを含むことができ、１つのサブＴＬＶが１つのタイプの制御・管理メッセージを搬送する。値フィールド２０５の長さは、搬送される制御・管理メッセージに基づいて決定されてもよいし、固定長であってもよく、これはここで限定されることではない。一例において、値フィールド２０３又は値フィールド２０５内で搬送される上記少なくとも１つの制御・管理メッセージは、制御・管理メッセージを搬送するプロトコルデータユニット（protocol data unit，ＰＤＵ）として理解され得る。
【0095】
更なる他の一例において、ＩＰｖ６パケットの拡張ヘッダの過度な延長を回避するために、ＩＰｖ６パケットの拡張ヘッダ内の未定義フィールドが指示情報を搬送してもよい。ＳＲｖ６パケットではＳＲｖ６パケットのＳＲＨ内のフラグ（flags）フィールドが明確に定義されないことを考慮して、一部の実施形態において、第１のＩＰｖ６パケットがＳＲｖ６パケットである場合に、第１のＩＰｖ６パケットのＳＲＨ内のフラグフィールドが指示情報を含む。
【0096】
この出願のこの実施形態において、管理チャネルによって搬送される上記少なくとも１つのタイプの制御チャネルは、例えば、ＯＡＭチャネル、障害指示チャネル、リソース管理チャネル、シグナリング通信チャネル（signaling communication channel，ＳＣＣ）、及びＭＣＣのうちの１つ以上を含み得る。
【0097】
ＯＡＭチャネルによって搬送される制御・管理メッセージは、例えば、ＯＡＭメッセージとし得る。ＯＡＭメッセージは、例えばＳＲｖ６パスといったエンドツーエンドＩＰｖ６パス上で運用・管理・保守を実施するための一連のメッセージの総称である。この出願におけるＯＡＭチャネルは、ホップバイホップ検出をサポートすることができ、また、エンドツーエンド検出もサポートすることができる。ＯＡＭメッセージは、以下に限られないが、接続性検査メッセージ、クライアント信号障害指示メッセージ、一方向／双方向パケット損失測定メッセージ、一方向／双方向レイテンシ測定メッセージ、及びリンクループバックメッセージを含む。接続性検査メッセージは、ＩＰｖ６パス上で接続性検査を実施するために使用される。クライアント信号障害指示メッセージは、クライアント信号障害がＩＰｖ６パスに存在するかを検出するために使用される。一方向／双方向パケット損失測定メッセージは、ＳＲｖ６パス上での一方向／双方向パケット損失を検出するために使用される。一方向／双方向レイテンシ測定メッセージは、ＩＰｖ６パスの一方向／双方向レイテンシを検出するために使用される。リンクループバックメッセージは、ＩＰｖ６パス上でループバック検出を実施するために使用される。一例において、ＯＡＭメッセージが複数の異なるタイプのメッセージに対応するとき、ＯＡＭチャネルは複数の異なるタイプのＯＡＭチャネルに対応する。例えば、ＯＡＭメッセージが接続性検査メッセージである場合、ＯＡＭチャネルは、接続性検査チャネルに対応し、接続性検査メッセージを搬送する。
【0098】
ＯＡＭメッセージのフォーマットは、メッセージが対応するＯＡＭ検出機能を実装することができれば、この出願のこの実施形態において限定されるものではない。ＯＡＭメッセージを搬送するパケットのフォーマットも、この出願のこの実施形態において特に限定るものではない。一例において、ＯＡＭメッセージが接続性検査メッセージである場合、例えば、制御チャネルが接続性検査チャネルであることをチャネルタイプが指し示すことができ、値フィールドが接続性検査メッセージを搬送する。
【0099】
障害指示チャネルによって搬送される制御・管理メッセージは、例えば、障害指示メッセージであるとし得る。障害指示チャネルによって搬送される制御・管理メッセージは、第１パスの障害指示情報を記録する。この場合、第１の通信装置は、第１パス上のノードに相当し、第１パスは第１のＩＰｖ６パケットの伝送パスとし得る。ここで言及される第１パスは、エンドツーエンドパスであってもよいし、パスのセグメントであってもよく、これはここで限定されることではない。一例において、障害指示メッセージは、障害指示情報のうち１つ以上を含んでもよく、例えば、前方障害指示情報及び／又は後方障害指示情報を含み得る。前方障害指示情報は、第１のＩＰｖ６パケットの伝送パス上の第１の通信装置の上流ノードに障害があることを示し、例えば、第１のＩＰｖ６パケットの伝送パス上の中間ノードに障害があることを示す。ここで言及される上流ノードに障害があることは、例えば、上流ノードのビット誤り率が特定の閾値より高いこと、又は上流ノードのパケット損失率が特定の閾値より高いこととすることができ、これはここで限定されることではない。後方障害指示情報は、第１のＩＰｖ６パケットの伝送パス上の第１の通信装置の下流ノードに障害があることを示し、例えば、第１のＩＰｖ６パケットの伝送パス上のテールノードに障害があることを示す。同様に、ここで言及される下流ノードに障害があることは、例えば、下流ノードのビット誤り率が特定の閾値より高いこと、又は下流ノードのパケット損失率が特定の閾値より高いこととすることができ、これはここで限定されることではない。更なる他の一例において、障害指示情報は、例えば、第１パスの障害状態を反映し得る。例えば、障害指示情報は、信号障害（signal fail，ＳＦ）、信号劣化（signal degrade，ＳＤ）、特定の閾値より高いビット誤り率、特定の閾値より高いパケット損失率、及び特定の閾値より高いレイテンシ、のうちの１つ以上を含む。この場合、障害指示チャネルによって搬送される制御・管理メッセージは、例えば、様々なタイプの障害指示情報に対応する指示ビットを含み得る。他の一実装において、障害指示情報は、例えば、第１パス上のノードの例えばビット誤り率及びパケット損失率などの情報であってもよい。この場合、障害指示チャネルによって搬送される制御・管理メッセージは、例えば、ビット誤り率の特定の値及び／又はパケット損失率の特定の値を含み得る。オプションで、障害指示メッセージは更に第１パスの識別子を含んでもよい。
【0100】
一例において、連合チャネル内のチャネルタイプフィールドが障害指示チャネルを指し示すとき、連合チャネルを搬送するＴＬＶフィールドの値フィールドが障害指示メッセージを含む。例えば、図２ａ－１で、チャネルタイプフィールド２０２が障害指示チャネルを指し示し、値フィールド２０３が障害指示メッセージを搬送する。他の一例において、図２ａ－２で、チャネルタイプフィールド２０４が障害指示チャネルを指し示し、値フィールド２０５が障害指示メッセージを搬送する。
【0101】
更なる他の一例において、障害指示メッセージはＴＬＶフィールド内で搬送され、ここで言及されるＴＬＶフィールドは、図２ａ－１に示されるＴＬＶフィールドの値フィールド２０３で搬送されることができ、あるいは図２ａ－２に示されるＴＬＶフィールドの値フィールド２０３又は２０５で搬送されることができる。図２ｂを参照するに、図２ｂは、この出願の一実施形態に従った障害指示メッセージの構造の概略図である。図２ｂについて、以下のことに留意されたい。
【0102】
図２ｂに示すＴＬＶフィールドのタイプフィールドは、ＴＬＶフィールドで搬送される制御・管理メッセージが障害指示メッセージであることを指し示し、
パス識別子（path ID）フィールド（オプション）は第１パスの識別子を搬送し、第１パスの識別子は障害指示メッセージ内で搬送されなくてもよく、
ｆｌａｇｓ（flags）フィールドは、上述の障害指示情報のうちの１つ以上を搬送する。例えば、一例において、フラグフィールドは２つの指示ビットを含む。１つの指示ビットは前方障害指示情報を示し、もう１つの指示ビットは後方障害指示情報を示す。前方障害指示情報を示す指示ビットの値が１であるとき、それは、障害指示メッセージが前方障害指示情報を含むことを指し示し、後方障害指示情報を示す指示ビットの値が１であるとき、それは、障害指示メッセージが後方障害指示情報を含むことを指し示す。更なる他の一例において、フラグフィールドは５つの指示ビットを含み、それら５つの指示ビットは、ＳＦ、ＳＤ、特定の閾値より高いビット誤り率、特定の閾値より高いパケット損失率、及び特定の閾値より高いレイテンシである５つのタイプの障害指示情報を示すことができ、１つの指示ビットが１つのタイプの障害指示情報を示す。他の一例において、フラグフィールドは、ビット誤り率を搬送するフィールドと、パケット損失率を搬送するフィールドとを含む。
パス識別子（path ID）フィールド（オプション）は第１パスの識別子を搬送し、第１パスの識別子は障害指示メッセージ内で搬送されなくてもよく、
ｆｌａｇｓ（flags）フィールドは、上述の障害指示情報のうちの１つ以上を搬送する。例えば、一例において、フラグフィールドは２つの指示ビットを含む。１つの指示ビットは前方障害指示情報を示し、もう１つの指示ビットは後方障害指示情報を示す。前方障害指示情報を示す指示ビットの値が１であるとき、それは、障害指示メッセージが前方障害指示情報を含むことを指し示し、後方障害指示情報を示す指示ビットの値が１であるとき、それは、障害指示メッセージが後方障害指示情報を含むことを指し示す。更なる他の一例において、フラグフィールドは５つの指示ビットを含み、それら５つの指示ビットは、ＳＦ、ＳＤ、特定の閾値より高いビット誤り率、特定の閾値より高いパケット損失率、及び特定の閾値より高いレイテンシである５つのタイプの障害指示情報を示すことができ、１つの指示ビットが１つのタイプの障害指示情報を示す。他の一例において、フラグフィールドは、ビット誤り率を搬送するフィールドと、パケット損失率を搬送するフィールドとを含む。
【0103】
加えて、更なる他の一例において、障害指示メッセージは複数のタイプのメッセージを含んでもよく、例えば、リンクステータス指示メッセージ及びリンクパラメータ指示メッセージを含み得る。リンクステータス指示メッセージは、例えばＳＦ、ＳＤ、特定の閾値より高いビット誤り率、特定の閾値より高いパケット損失率、及び特定の閾値より高いレイテンシなどの障害指示情報のうちの１つ以上を含み得る。リンクパラメータ指示メッセージは、例えばビット誤り率及びパケット損失率などの情報を含み得る。この場合、図２ｂに示すタイプフィールドは、リンクステータス指示メッセージ又はリンクパラメータ指示メッセージのうちの一方を示し得る。対応して、図２ｂに示すタイプフィールドがリンクステータス指示メッセージを示すとき、図２ｂに示すフラグフィールドは、例えばＳＦ、ＳＤ、特定の閾値より高いビット誤り率、特定の閾値より高いパケット損失率、及び特定の閾値より高いレイテンシなどの障害指示情報のうちの１つ以上を含む。図２ｂに示すタイプフィールドがリンクパラメータ指示メッセージを示すとき、図２ｂに示すフラグフィールドは、例えばビット誤り率及びパケット損失率などの障害指示情報のうちの１つ以上を含む。
【0104】
リソース管理チャネルによって搬送される制御・管理メッセージは、例えば第１パスといったパス上でリソース管理を実施するために使用される。この場合、第１の通信装置は、第１パス上のノードに相当し、第１パスは第１のＩＰｖ６パケットの伝送パスとし得る。
【0105】
リソース管理チャネルによって搬送される制御・管理メッセージは、例えば、リソース管理メッセージとし得る。リソース管理メッセージは複数のタイプのメッセージを含み得る。一例において、リソース管理メッセージは、第１パス上のノードにリソースを予約するように指示するものであるリソース予約要求メッセージを含み得る。例えば、リソース予約要求メッセージは、例えば帯域幅及びレイテンシなどのＳＬＡ情報を搬送し得る。更なる他の一例において、リソース管理メッセージは、第１パス上のノードの利用可能なリソースを収集するために使用されるものであるリソースステータス更新メッセージを含むことができ、例えば、第１パス上のノードによって提供されることができる例えば帯域幅、バッファ、及びレイテンシなどのリソース情報を収集し得る。他の一例において、リソース管理メッセージは、リソース予約要求を取り消すために使用されるものであるリソース予約取消メッセージを含み得る。
【0106】
リソース予約要求メッセージの理解のために、図２ｃを参照されたい。図２ｃは、この出願の一実施形態に従ったリソース予約要求メッセージの構造の概略図である。リソース予約要求メッセージはＴＬＶフィールド内で搬送される。ここで言及されるＴＬＶフィールドは、図２ａ－１又は図２ａ－２に示したＴＬＶフィールドの値フィールド内で搬送され得る。図２ｃについて、以下のことに留意されたい。
【0107】
メッセージタイプ（message type）フィールドは、ＴＬＶフィールドで搬送されるリソース管理メッセージがリソース予約要求メッセージであることを指し示し、
パスＩＤフィールドは第１パスの識別子を示し、
所望帯域幅（desired bandwidth）は、予約されるように要求される帯域幅を示す。
パスＩＤフィールドは第１パスの識別子を示し、
所望帯域幅（desired bandwidth）は、予約されるように要求される帯域幅を示す。
【0108】
リソース予約要求メッセージについて、留意されたいことには、図２ｃは単なる例であり、この出願のこの実施形態に対する限定を構成するものではない。
【0109】
リソースステータス更新メッセージの理解のために、図２ｄを参照されたい。図２ｄは、この出願の一実施形態に従ったリソースステータス更新メッセージの構造の概略図である。リソース状態更新メッセージはＴＬＶフィールド内で搬送される。ここで言及されるＴＬＶフィールドは、図２ａ－１又は図２ａ－２に示したＴＬＶフィールドの値フィールド内で搬送され得る。図２ｄについて、以下のことに留意されたい。
【0110】
メッセージタイプフィールドは、ＴＬＶフィールドで搬送されるリソース管理メッセージがリソースステータス更新メッセージであることを示し、
パスＩＤフィールドは第１パスの識別子を示し、
ノードＩＤ［ｉ］（node ID）は、前記第１パス上のノードｉの識別子を搬送し、ｉの値はｎ以下かつ０以上であり、第１パスは、少なくとも（ｎ＋１）個のノードを含み、
インタフェースＩＤ［ｉ］はノードｉのインタフェース識別子を示し、
提供帯域幅（offered bandwidth）［ｉ］は、ノードｉによって提供されることができる帯域幅を示し、
提供レイテンシ（offered latency）［ｉ］は、ノードｉによって提供されることができるレイテンシを示す。
パスＩＤフィールドは第１パスの識別子を示し、
ノードＩＤ［ｉ］（node ID）は、前記第１パス上のノードｉの識別子を搬送し、ｉの値はｎ以下かつ０以上であり、第１パスは、少なくとも（ｎ＋１）個のノードを含み、
インタフェースＩＤ［ｉ］はノードｉのインタフェース識別子を示し、
提供帯域幅（offered bandwidth）［ｉ］は、ノードｉによって提供されることができる帯域幅を示し、
提供レイテンシ（offered latency）［ｉ］は、ノードｉによって提供されることができるレイテンシを示す。
【0111】
リソースステータス更新メッセージについて、留意されたいことには、図２ｄは単なる例であり、この出願のこの実施形態に対する限定を構成するものではない。
【0112】
リソース取消メッセージの理解のために、図２ｅを参照されたい。図２ｅは、この出願の一実施形態に従ったリソース取消メッセージの構造の概略図である。リソース取消メッセージはＴＬＶフィールド内で搬送される。ここで言及されるＴＬＶフィールドは、図２ａ－１又は図２ａ－２に示したＴＬＶフィールドの値フィールド内で搬送され得る。図２ｅについて、以下のことに留意されたい。
【0113】
情報タイプ（message type）フィールドは、ＴＬＶフィールドで搬送されるリソース管理メッセージがリソース取消メッセージであることを示し、
パスＩＤフィールドは、リソース予約を取り消すことに関するパスの識別子を示す。
パスＩＤフィールドは、リソース予約を取り消すことに関するパスの識別子を示す。
【0114】
確かなことには、リソース取消メッセージは更に、例えば所望サービス品質、リソース予約様式、及び要求帯域幅などの情報といった、他のオプションのフィールドを含み得る。これはこの出願のこの実施形態において特に限定されることではない。
【0115】
リソース取消メッセージについて、留意されたいことには、図２ｅは単なる例であり、この出願のこの実施形態に対する限定を構成するものではない。
【0116】
なお、この出願のこの実施形態におけるリソース管理メッセージは代わりに、例えばＲＦＣ ３２０９において言及されているＲＳＶＰメッセージといったＲＳＶＰメッセージであってもよく、あるいは、言及されているＲＳＶＰメッセージに対して対応する拡張が行われた後に得られるメッセージであってもよい。これはこの出願のこの実施形態において特に限定されることではない。
【0117】
ＳＣＣは、ＩＰｖ６パス上の２つのノード間に、ＳＣＣメッセージを伝送するための独立したチャネルを提供するように構成され、ＳＣＣメッセージは、制御情報を伝送するために使用される。
【0118】
ＭＣＣは、ＩＰｖ６パス上の２つのノード間に、ＭＣＣメッセージを伝送するための独立したチャネルを提供するように構成され、ＭＣＣメッセージは、管理情報を伝送するために使用される。
【0119】
ＭＣＣ及びＳＣＣについて、留意されたいことには、従来のＩＰｖ６ネットワークでは、任意の２つのノード間に管理情報又は制御情報を伝送するための独立したチャネルは存在しない。従って、管理メッセージ及び制御メッセージを伝送するために独立した制御及び管理機構が必要とされる。ＭＣＣは、独立した制御及び管理機構を使用することなく管理メッセージを伝送する効果を実装し、ＳＣＣは、独立した制御及び管理機構を使用することなく制御メッセージを伝送する効果を実装する。
【0120】
ＳＣＣメッセージ及びＭＣＣメッセージの具体的なフォーマットは、この出願のこの実施形態において特に限定されるものではない。一例において、ＳＣＣメッセージ及びＭＣＣメッセージのフォーマットについては、ＲＦＣ ５７１８における関連する説明部分を参照されたく、詳細をここで説明することはしない。
【0121】
上述のように、連合チャネルは、少なくとも１つの制御・管理メッセージを搬送することができ、該制御・管理メッセージは、パスを制御及び／又は管理するためのメッセージである。この出願のこの実施形態において、第１のＩＰｖ６パケットを受信するノードが、連合チャネルに関連付けられたパスを決定することを可能にするために、第１のＩＰｖ６パケットは更に識別情報を含むことができ、該識別情報は、第１パスを識別するために使用され、該第１パスが第１のＩＰｖ６パケットの伝送パスである。斯くして、第１のＩＰｖ６パケットを受信するノードは、第１パスを制御及び／又は管理するための連合チャネル内の少なくとも１つの制御・管理メッセージを決定するために、第１のＩＰｖ６パケット内の連合チャネルと第１パスとの間の連関関係を特定し得る。さらに、第１のＩＰｖ６パケットを受信するノードは、該識別情報と連合チャネル内の上記少なくとも１つの制御・管理メッセージとに基づいて、対応する動作を実行し得る。
【0122】
第１パスを識別するための識別情報について、以下のことに留意されたい。
【0123】
一例において、第１のＩＰｖ６パケットがＳＲｖ６パケットである場合、ＳＲｖ６パケットのＳＲＨに含まれるセグメントリスト（segment list）がＳＲｖ６パケットの伝送パスを示し得る。従って、識別情報は、ＳＲｖ６パケットのセグメントリストを用いることによって搬送されてもよく、すなわち、識別情報はＳＲｖ６パケットのセグメントリストであってもよい。セグメントリストは幾つかのＳＩＤを含み得る。ＳＩＤは、伝送パスが通る中間ノードを示し、あるいは、ＳＩＤは、伝送パスに含まれるＳＲｖ６隣接リンクを示す。２つのノード間の隣接リンクは、それら２つのノード間の直接的な通信に使用されるリンクを指す。一方のノードが隣接リンクを用いることによって他方のノードにパケットを送信するとき、他方のノードは先行ノードの次ホップである。また、ＳＲｖ６パケットでは、ＳＲｖ６パケットのＳＲＨが更にパスセグメントフィールドを含むことができ、パスセグメントフィールドは１２８ビットを含み、ＳＲｖ６パスを識別するためにパスセグメントフィールドの値が使用される。ＳＲｖ６パケットとして使用される第１のＩＰｖ６パケットがパスセグメントフィールドを含む場合、パスセグメントフィールドの値が、第１のＩＰｖ６パケットの伝送パスを識別するために使用される。従って、識別情報は、代わりにＳＲｖ６パケットのパスセグメントフィールド内で搬送されてもよい。一例において、この出願のこの実施形態で言及される第１のＩＰｖ６パケットの拡張ヘッダは、ホップバイホップ（hop-by-hop，ＨＢＨ）オプションヘッダとし得る。換言すれば、第１のＩＰｖ６パケットのＨＢＨオプションヘッダが連合チャネルを含み得る。更なる他の一例において、この出願のこの実施形態で言及される第１のＩＰｖ６パケットの拡張ヘッダは宛先オプションヘッダ（destination option header，ＤＯＨ）であってもよい。換言すれば、第１のＩＰｖ６パケットのＤＯＨが連合チャネルを含んでもよい。他の一例において、第１のＩＰｖ６パケットがＳＲｖ６パケットである場合、この出願のこの実施形態で言及される第１のＩＰｖ６パケットの拡張ヘッダはＳＲＨであってもよい。換言すれば、第１のＩＰｖ６パケットのＳＲＨが連合チャネルを含んでもよい。確かなことには、第１のＩＰｖ６パケットがＳＲｖ６パケットである場合に、第１のＩＰｖ６パケットの拡張ヘッダはＤＯＨであってもよい。換言すれば、第１のＩＰｖ６パケットがＳＲｖ６パケットである場合、第１のＩＰｖ６パケットのＤＯＨが連合チャネルを含んでもよい。
【0124】
第１のＩＰｖ６パケットのＳＲＨが連合チャネルを搬送する場合、第１のＩＰｖ６パケットの構造について、図２ｆを参照されたい。図２ｆは、この出願の一実施形態に従った第１のＩＰｖ６パケットの構造の概略図である。
【0125】
図２ｆに示す連合チャネルを搬送するＴＬＶについては、図２ａ－１又は図２ａ－２の説明部分を参照されたく、それをここで再び説明することはしない。図２ｆに示す他のフィールドについては、ＲＦＣ ８２００及びＲＦＣ ８７５４における関連する説明部分を参照されたく、詳細をここで説明することはしない。
【0126】
第１のＩＰｖ６パケットのＤＯＨが連合チャネルを搬送する場合、第１のＩＰｖ６パケットの構造について、図２ｇを参照されたい。図２ｇは、この出願の一実施形態に従った第１のＩＰｖ６パケットの構造の概略図である。
【0127】
図２ｇに示す連合チャネルを搬送するＴＬＶについては、図２ａ－１又は図２ａ－２の説明部分を参照されたく、それをここで再び説明することはしない。図２ｆに示す他のフィールドについては、ＲＦＣ ８２００における関連する説明部分を参照されたく、詳細をここで説明することはしない。
【0128】
なお、図２ｆ及び図２ｇは、理解を容易にするために示されているにすぎず、この出願のこの実施形態に対する限定を構成するものではない。例えば、一例において、図２ｆに示す第１のＩＰｖ６パケットが更にＤＯＨを含んでもよく、また、図２ｇに示す第１のＩＰｖ６パケットが更にＳＲＨを含んでもよい。図２ｇがＳＲＨを含む場合、ＤＯＨはＳＲＨとＩＰｖ６ベースヘッダとの間に置かれることができ、ホップバイホップ制御チャネルが実装され得る。ＤＯＨは代わりに、ＳＲＨとペイロードとの間のＤＯＨであってもよい。この場合、エンドツーエンド制御チャネルがサポートされ得る。
【0129】
なお、この出願のこの実施形態における第１のＩＰｖ６パケットは、サービスパケット又は測定パケットであってもよい。これはこの出願のこの実施形態において特に限定されることではない。理解され得ることには、第１のＩＰｖ６パケットがサービスパケットである場合、サービスパケットが伝送されるときに、ＩＰｖ６ネットワークが実際のサービスパケットを伝送するときのステータスに基づいて、ＩＰｖ６ネットワーク上で制御及び管理が実行され得る。すなわち、この出願においては、トラフィックとともに制御チャネルを、データプレーンに基づいて実装することができる。第１のＩＰｖ６パケットが測定パケットである場合、要件に従ってＩＰｖ６ネットワーク上で制御及び管理が実行され得る。例えば、サービスパケットが伝送される前にＩＰｖ６ネットワーク上で制御及び管理を実行することができ、ＩＰｖ６ネットワークの伝送品質が最適化された後にサービスパケットが伝送され、ＩＰｖ６ネットワークのサービス品質が向上される。
【0130】
Ｓ１０２： 第１のＩＰｖ６パケットを転送する。
【0131】
第１のＩＰｖ６パケットを取得した後、第１の通信装置は第１のＩＰｖ６パケットを転送し得る。第１のＩＰｖ６パケットを受信するノードは、上記少なくとも１つのタイプの制御・管理メッセージに対応する制御及び管理機能を実施するために、連合チャネルで搬送された上記少なくとも１つのタイプの制御・管理メッセージに基づいて、対応する動作を実行し得る。
【0132】
一部の実施形態において、第１のＩＰｖ６パケットを受信した後に、第１のＩＰｖ６パケットの伝送パス上の中間ノードは、上記少なくとも１つのタイプの制御・管理メッセージに対応する動作を実行し得る。第１のＩＰｖ６パケットに基づいて中間ノードによって実行される動作については、第２のＩＰｖ６パケットに基づいて第１の通信装置によって実行される動作に関する以下の部分を参照されたく、詳細をここで説明することはしない。
【0133】
一部の実施形態において、第１のＩＰｖ６パケットを受信した後に、第１のＩＰｖ６パケットの伝送パス上のテールノードは、上記少なくとも１つのタイプの制御・管理メッセージに対応する動作を実行し得る。
【0134】
一例において、第１のＩＰｖ６パケットの連合チャネルがＯＡＭチャネルを含む場合、すなわち、第１のＩＰｖ６パケットがＯＡＭメッセージを含む場合、例えば、テールノードは、タイムスタンプをコントローラにアップロードし得る。他の一例において、テールノードは、受信したＯＡＭメッセージに含まれるタイムスタンプとローカルタイムスタンプとに基づいて、第１のＩＰｖ６パケットの伝送レイテンシを計算し得る。
【0135】
更なる他の一例において、第１のＩＰｖ６パケットの連合チャネルが障害指示チャネルを含む場合、すなわち、第１のＩＰｖ６パケットが障害指示メッセージを含む場合、テールノードは、障害指示メッセージ内で搬送された障害指示情報を取得し得る。さらに、一例において、テールノードは、障害指示情報に基づいて対応する動作を実行し得る。説明のための例：第１のＩＰｖ６パケットの連合チャネルに含まれる障害指示メッセージが前方障害指示情報を含む場合、テールノードは、例えば、後方障害指示情報を搬送するＩＰｖ６パケットをヘッドノードに返信し得る。第１のＩＰｖ６パケットの連合チャネルに含まれる障害指示メッセージが後方障害指示情報を含む場合、テールノードは、例えば、テールノードに障害があるかを検証することができ、例えば、テールノードのパケット損失率及び／又はビット誤り率が特定の閾値を超えているかを検証し得る。第１のＩＰｖ６パケットの連合チャネルに含まれる障害指示メッセージが、ＳＦ、ＳＤ、特定の閾値より高いビット誤り率、特定の閾値より高いパケット損失率、及び特定の閾値より高いレイテンシのうちの１つ以上を含む場合、テールノードは、例えば、パス切り替えを実行するようにヘッドノードに通知し得る。第１のＩＰｖ６パケットの連合チャネルに含まれる障害指示メッセージが各ノードのビット誤り率及びパケット損失率を含む場合、テールノードは、例えば、例えばビット誤り率及びパケット損失率などの障害指示情報をコントローラにアップロードするか、又は障害指示情報を第１のＩＰｖ６パケットのヘッドノードに返すかし得る。
【0136】
他の一例において、第１のＩＰｖ６パケットの連合チャネルがリソース管理チャネルを含む場合には以下である。
【0137】
第１のＩＰｖ６パケットの連合チャネルが予約要求メッセージを含む場合、テールノードは、例えば、リソース予約要求メッセージに基づいて第１パスのために対応するリソースを予約し得る。第１のＩＰｖ６パケットの連合チャネルがリソースステータス更新メッセージを含む場合、テールノードの利用可能なリソース情報が第１のＩＰｖ６パケットに追加され、該利用可能なリソース情報が第１パスのヘッドノードに返される。理解のために図２ｄを参照されたい。テールノードが図２ｄに示されるノードＩＤ［ｎ］に対応すると仮定すると、テールノードは、図２ｄに示される提供帯域幅［ｎ］フィールドに、テールノードによって提供され得る帯域幅を記録し、図２ｄに示される提供レイテンシ［ｎ］フィールドに、テールノードによって提供され得るレイテンシを記録し得る。第１のＩＰｖ６パケットの連合チャネルがリソース予約取消メッセージを含む場合、第１の通信装置は、例えば、リソース予約取消メッセージによって示される第１パスのために予約されたリソースを解放し得る。
【0138】
以上の説明から、以下のことが分かる。
【0139】
第１のＩＰｖ６パケットの拡張ヘッダが連合チャネルを含むので、通信ネットワークのために複数の制御及び管理機能を実装する必要がある場合に、複数のタイプの制御・管理メッセージを、それら複数の制御・管理メッセージを搬送するために複数のプロトコルを使用することなく、連合チャネルを用いて搬送することができ、ＩＰｖ６ネットワーク上での制御及び管理の効率を向上させる。
【0140】
例１、例２、例３、及び例４で説明した方式と比較して、方法１００は以下の技術的効果を有する。
【0141】
１． 連合チャネルが、複数のプロトコルの制御・管理メッセージを搬送し、それ故に、１つのパケットを用いて複数のＴＬＶフィールドを搬送することができ、ノード間で制御・管理情報を伝送するパケットの量を減らすことができる。
【0142】
２． 連合チャネルが一般的なＴＬＶフィールドを用いて搬送され得る。例えばＵＤＰなどの他のネットワーク層を除去するように、ＩＰｖ６拡張ヘッダ内でＴＬＶカプセル化が行われ、制御・管理メッセージを含むパケットのカプセル化及び伝送が統一化及び簡略化され、例えばＵＤＰポート番号エントリなどの装置保守パラメータが削減される。
【0143】
３． 可変値長を持つＴＬＶフォーマットでの制御・管理メッセージの伝送は、拡張によってサポートされることができる。従って、より多くのチャネル保守情報が搬送され得る。
【0144】
４． ＩＰｖ６パケットヘッダを用いてメッセージ伝送が行われ、その結果、パケットヘッダのコンテンツについてデバイス転送プレーン上で高速なパス処理を実行することができ、メッセージ処理効率を向上させる。
【0145】
例５で説明した方式と比較して、連合チャネルは、例えばＨＢＨオプションヘッダ又はＤＯＨで搬送されるなど、複数のＩＰｖ６拡張ヘッダで搬送され得るので、方法１００は、ＳＲｖ６ノードに適用され得るのみでなく、ＳＲをサポートしないＩＰｖ６ノードにも適用され得る。
【0146】
また、既存のＩＰ層プロトコルは、ＭＣＣ及びＳＣＣをサポートしていない。さらに、ＩＣＭＰｖ６は、例えばパス接続性及び到達可能性などの診断情報を示すことができるが、ノード又はネットワークの障害情報を示すことはできない。ＢＦＤ診断ワードは、ＢＦＤセッションステータスが最後に変化した理由を示すことができ、すなわち、ＢＦＤプロトコルの制御プレーン上でのプロトコルステータスの変化をノードに示すが、ノード又はネットワークの障害情報を示すことはできない。方法１００は、例えば、ＭＣＣ、ＳＣＣ、及びノード若しくはネットワークの障害情報を示すことなどの機能をサポートすることができる。ノードが新しい上位層プロトコルをサポートする必要があるとき、上位層プロトコルによって必要とされる制御・管理情報が、新しい上位層プロトコルを再設計することなしに、連合チャネルを用いることによって搬送され得る。従って、プロトコルスケーラビリティが良好であり、ノードプロトコルの量及び保守の複雑さが低減される。
【0147】
加えて、複数の異なるタイプのネットワーク収束シナリオにおいて、連合チャネルは、ＩＰ拡張ヘッダ内で複数のタイプの制御・管理メッセージを搬送し、別のレイヤプロトコルを追加せずにプロトコルスタックを単純化し、ノード実装の複雑さを低減し、産業シナリオにおける展開可能性を向上させる。
【0148】
上述のように、第１の通信装置は、第１のＩＰｖ６パケットの伝送パス上のヘッドノードに相当することができ、あるいは、第１のＩＰｖ６パケットの伝送パス上の中間ノードに相当することができる。一例において、第１の通信装置が第１のＩＰｖ６パケットの伝送パス上の中間ノードに相当する場合、一例において、第１の通信装置は、上流ノードから第２のＩＰｖ６パケットを受信することができ、該第２のＩＰｖ６パケットは連合チャネルを含み、第１の通信装置は、第２のＩＰｖ６パケット内の連合チャネルに基づいて第２のＩＰｖ６パケットを処理して、第１のＩＰｖ６パケットを取得することができる。
【0149】
以下では、第１の通信装置が第２のＩＰｖ６パケット内の連合チャネルに基づいて第２のＩＰｖ６パケットを処理する具体的な実装を説明するための例として、第１の通信装置が第１のＩＰｖ６パケットの伝送パス上の中間ノード１に相当する例を用いる。
【0150】
一例において、第２のＩＰｖ６パケットの連合チャネルがＯＡＭチャネルを含む場合、すなわち、第２のＩＰｖ６パケットの連合チャネルがＯＡＭメッセージを含む場合、一部の実施形態において、例えば、第１の通信装置は、中間ノード１のローカルタイムスタンプを第２のＩＰｖ６パケットに追加して、第１のＩＰｖ６パケットを取得し得る。他の一例において、第１の通信装置は、中間ノード１のパケット損失情報を第２のＩＰｖ６パケットに追加して、第１のＩＰｖ６パケットを取得し得る。一例において、第１の通信装置は、中間ノード１のタイムスタンプ及び／又はパケット損失情報を第２のＩＰｖ６パケットの拡張ヘッダに追加し得る。一例において、第２のＩＰｖ６パケットの過度な延長を回避するために、中間ノード１のタイムスタンプ及び／又はパケット損失情報は、ＯＡＭメッセージを搬送するＴＬＶの値フィールド内で搬送され得る。更なる他の一例において、中間ノード１のタイムスタンプ及び／又はパケット損失情報を搬送するために、追加のＴＬＶが第２のＩＰｖ６パケットの拡張ヘッダ内で拡張され得る。ここで言及される拡張ヘッダは、以下に限られないが、ＨＢＨオプションヘッダ、ＤＯＨ、及びＳＲＨを含む。
【0151】
他の一例において、連合チャネルが障害指示チャネルを含む場合、すなわち、第２のＩＰｖ６パケットの連合チャネルが障害指示メッセージを含む場合、一部の実施形態において、中間ノード１は、例えば、パケット損失率及び／又はビット誤り率などの中間ノード１によって確認された障害指示情報を第２のＩＰｖ６パケットに記録して、第１のＩＰｖ６パケットを取得し得る。一例において、第２のＩＰｖ６パケットの過度な延長を回避するために、中間ノード１のビット誤り率及び／又はパケット損失率は、障害指示メッセージを搬送するＴＬＶの値フィールド内で搬送され得る。更なる他の一例において、中間ノード１のパケット損失率及び／又はビット誤り率を搬送するために、追加のＴＬＶが第２のＩＰｖ６パケットの拡張ヘッダ内で拡張され得る。ここで言及される拡張ヘッダは、以下に限られないが、ＨＢＨオプションヘッダ、ＤＯＨ、及びＳＲＨを含む。
【0152】
更なる他の一例において、連合チャネルがリソース管理チャネルを含み、且つ該リソース管理チャネルがステータス更新メッセージを搬送する場合、第１の通信装置は、例えば、中間ノード１の利用可能なリソース情報を第２のＩＰｖ６パケットに追加して、第１のＩＰｖ６パケットを取得し得る。理解のために、図２ｄを参照されたい。中間ノード１が図２ｄに示したノードＩＤ［０］に相当すると仮定すると、第１の通信装置は、中間ノード１によって提供されることができる帯域幅を、図２ｄに示した提供帯域幅［０］フィールドに記録するとともに、中間ノード１によって提供されることができるレイテンシを、図２ｄに示した提供レイテンシ［０］フィールドに記録し得る。
【0153】
一部の実施形態において、第１の通信装置が第１のＩＰｖ６パケットの伝送パス上の中間ノードに相当する場合、第１の通信装置は、第２のＩＰｖ６パケットを受信した後に、第２のＩＰｖ６パケットの管理チャネルで搬送された少なくとも１つのタイプの制御・管理メッセージに基づいて別の動作を実行してもよい。
【0154】
例えば、第２のＩＰｖ６パケットの連合チャネルがＯＡＭメッセージを含む場合、第１の通信装置は更に、中間ノード１のタイムスタンプ及び／又はパケット損失情報をコントローラに送信し得る。他の一例において、第２のＩＰｖ６パケットの連合チャネルがリソース予約要求メッセージを含む場合、第１の通信装置は、例えば、リソース予約要求指示に基づいて、対応するリソースを第１パスのために予約し得る。第２のＩＰｖ６パケットの連合チャネルがリソース予約取消メッセージを含む場合、第１の通信装置は、例えば、リソース予約取消メッセージによって示された、第１パスのために予約されたリソースを解放し得る。
【0155】
ＩＰｖ６ネットワークでは、例えば第１パスなどのパスについて、第１パスに障害があるかを判定することが特に重要である。例えばヘッドノード又はテールノードといった第１パス上のノードが第１パスに障害があると判定すると、障害ある第１パスによってサービス品質が影響を受けることを防ぐために、対応する対策を講じることができ、例えば、パス切り替えを実行することができる。
【0156】
現行では、第１パスに障害があるとき、第１パス上のノードが管理プレーンに対してアラームを報告し得る。しかしながら、アラームを受信した後に、管理プレーンは現場で障害を手動で解決する必要があり、これは非効率的である。
【0157】
これに鑑み、この出願の一実施形態はパケット処理方法を提供する。以下、添付図面を参照して当該方法を説明する。
【0158】
図３は、この出願の一実施形態に従ったパケット処理方法の概略フローチャートである。図３に示すパケット処理方法２００は、第１の通信装置によって実行され得る。該第１の通信装置は、ＩＰｖ６ネットワーク内のノードに相当し、例えば、第１パス上のヘッドノード又は中間ノードとし得る。図３に示すパケット処理方法２００は、例えば、以下のＳ２０１及びＳ２０２を含み得る。
【0159】
Ｓ２０１： 第１のＩＰｖ６パケットを取得し、該第１のＩＰｖ６パケットは障害指示チャネルを含み、該障害指示チャネルは第１パスの障害指示情報を記録する。
【0160】
第１の通信装置が第１パス上のヘッドノードに相当する場合、第１の通信装置は第１のＩＰｖ６パケットを生成し得る。第１の通信装置が第１パス上の中間ノードに相当する場合、第１の通信装置は、上流ノードから第２のＩＰｖ６パケットを受信し得る。一例において、第２のＩＰｖ６パケットも障害指示チャネルを含む。第２のＩＰｖ６パケットを受信した後に、第１の通信装置は、第２のＩＰｖ６パケットを処理して第１のＩＰｖ６パケットを取得し得る。ここで言及される第１パスは、第１のＩＰｖ６パケットの伝送パスとし得る。ここで言及される、第２のＩＰｖ６パケットに含まれる障害通知チャネルは、例えば、第１の通信装置の上流ノードによって第２のＩＰｖ６パケットに記録された障害通知情報を含み得る。確かなことには、第１の通信装置が第１パス上の中間ノードに相当する場合、第１の通信装置は代わりに、上流ノードから第１のＩＰｖ６パケットを受信してもよい。
【0161】
この出願のこの実施形態において、障害指示チャネルは、第１のＩＰｖ６パケットのペイロード内で搬送されてもよいし、第１のＩＰｖ６パケットの拡張ヘッダ内で搬送されてもよい。ここで言及される拡張ヘッダはＨＢＨオプションヘッダとし得る。換言すれば、第１のＩＰｖ６パケットのＨＢＨオプションヘッダが障害指示メッセージを含み得る。更なる他の一例において、ここで言及される拡張ヘッダはＤＯＨであってもよい。換言すれば、第１のＩＰｖ６パケットのＤＯＨが障害指示メッセージを含み得る。他の一例において、第１のＩＰｖ６パケットがＳＲｖ６パケットである場合、ここで言及される拡張ヘッダはＳＲＨとし得る。換言すれば、第１のＩＰｖ６パケットのＳＲＨが障害指示メッセージを含み得る。
【0162】
一例において、障害指示チャネルは、障害指示メッセージを搬送するように構成され得る。障害指示メッセージは、拡張されたＴＬＶ内で搬送され得る。拡張されたＴＬＶは独立したＴＬＶであってもよく、独立したＴＬＶは、障害指示チャネルを搬送することに加えて他のタイプの制御チャネルを搬送することはしない。拡張されたＴＬＶは代わりに、連合チャネルを搬送するＴＬＶであってもよい。この場合、障害指示チャネルを搬送することに加えて、ＴＬＶは他の制御チャネルも搬送し得る。障害指示メッセージを搬送するＴＬＶの構造、及び障害指示メッセージ内で搬送され得る障害指示情報については、方法１００における障害指示メッセージの説明部分を参照されたく、詳細をここで説明することはしない。
【0163】
なお、障害指示メッセージを搬送するＴＬＶは、例えば、連合チャネルを含むＴＬＶの値フィールド内で搬送され得る。例えば、障害指示メッセージを搬送するＴＬＶは、図２ａ－１又は図２ａ－２に示したＴＬＶフィールドの値フィールド内で搬送され得る。連合チャネルを含むＴＬＶについては、方法１００における関連する説明部分を参照されたく、詳細をここで説明することはしない。
【0164】
なお、この出願のこの実施形態における第１のＩＰｖ６パケットは、サービスパケットであってもよいし、測定パケットであってもよい。これはこの出願のこの実施形態において特に限定されることではない。理解され得ることには、第１のＩＰｖ６パケットがサービスパケットである場合、ＩＰｖ６ネットワークが実際のサービスパケットを送信するときの障害指示情報が決定され得る。第１のＩＰｖ６パケットが測定パケットである場合、要件に従って第１パスの障害指示情報が決定され得る。例えば、サービスのサービス品質を満足する伝送パスを決定して、サービス品質を保証するために、サービスパケットが伝送される前に、第１パスの障害指示情報が決定され得る。第１のＩＰｖ６パケットがサービスパケットであることは、第１のＩＰｖ６パケットのデータペイロードがユーザデータを搬送することを指し示す。第１のＩＰｖ６パケットが測定パケットである場合、第１のＩＰｖ６パケットのデータペイロードはユーザデータを搬送しない。
【0165】
Ｓ２０２： 第１のＩＰｖ６パケットを転送する。
【0166】
第１のＩＰｖ６パケットを取得した後に、第１の通信装置は第１のＩＰｖ６パケットを転送し得る。例えば第１のＩＰｖ６パケットの伝送パス上のテールノードといった、第１のＩＰｖ６パケットを受信したノードは、障害指示メッセージに基づいて対応する動作を実行し得る。第１のＩＰｖ６パケットを受信したノードによって障害指示情報に基づいて実行される動作部分については、方法１００における障害指示メッセージに基づいてテールノードによって実行される動作部分を参照されたく、詳細をここで再び説明することはしない。
【0167】
分かることには、方法２００を使用することにより、ＩＰｖ６ネットワークにおいて第１パスの障害指示情報を決定する機能が実装され得る。具体的には、第１パスにおける障害指示情報を、データプレーンを介して第１パス上の例えばテールノードなどの別のノードに迅速に伝送することができ、それ故に、第１パス上の例えばテールノードなどのノードが第１パスに障害があると判定したときに、対応する対策を迅速且つ効率的に講じることができ、障害ある第１パスによってサービス品質が影響を受けることが防止される。
【0168】
理解され得ることには、方法２００において、障害指示メッセージを搬送するＴＬＶが、連合チャネルを含むＴＬＶの値フィールド内で搬送される場合、第１のＩＰｖ６パケットは連合チャネルを搬送し、該連合チャネルは複数の異なるタイプの制御チャネルを搬送する。各タイプの制御チャネルが、少なくとも１つのタイプの制御・管理メッセージを搬送し、複数の異なるタイプの制御・管理メッセージが障害指示チャネルを含む。連合ユニバーサルチャネルについては、方法１００の関連する説明部分を参照されたく、詳細をここで再び説明することはしない。対応して、方法２００における第１のＩＰｖ６パケットが連合チャネルを搬送する場合に、第１の通信装置が連合チャネルを処理する方式については、方法１００における関連する説明部分を参照されたく、詳細をここで再び説明することはしない。
【0169】
この出願の一実施形態は更にパケット処理方法３００を提供する。この出願の一実施形態に従ったパケット処理方法の概略フローチャートである図４を参照されたい。図４に示す方法３００は、方法１００における第１のＩＰｖ６パケットの伝送パス上のテールノードによって実行され得る。例えば、方法３００は、以下のＳ３０１及びＳ３０２を含み得る。
【0170】
Ｓ３０１： 第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを受信し、該第１のＩＰｖ６パケットは連合チャネルを含み、該連合チャネルは複数の異なるタイプの制御チャネルを搬送し、各タイプの制御チャネルが少なくとも１つのタイプの制御・管理メッセージを搬送する。
【0171】
Ｓ３０２： 上記少なくとも１つのタイプの制御・管理メッセージに対応する動作を実行する。
【0172】
なお、方法３００の具体的な実装については、方法１００における関連する説明部分を参照されたく、詳細をここで再び説明することはしない。
【0173】
また、方法３００における連合チャネル、制御チャネル、制御・管理メッセージ、及び制御・管理メッセージに対応する動作については、方法１００における関連する説明部分を参照されたく、詳細をここで再び説明することはしない。
【0174】
この出願の一実施形態は更にパケット処理方法４００を提供する。この出願の一実施形態に従ったパケット処理方法の概略フローチャートである図５を参照されたい。図５に示す方法４００は、方法２００における第１のＩＰｖ６パケットの伝送パス上のテールノードによって実行され得る。例えば、方法４００は、以下のＳ４０１及びＳ４０２を含み得る。
【0175】
Ｓ４０１： 第１パスのテールノードが第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを受信し、該第１のＩＰｖ６パケットは障害指示チャネルを含み、該障害指示チャネルは第１パスの障害指示情報を記録する。
【0176】
Ｓ４０２： 第１パスの障害指示情報を取得する。
【0177】
なお、方法４００の具体的な実装については、方法２００における関連する説明部分を参照されたく、詳細をここで再び説明することはしない。
【0178】
また、方法４００における障害指示メッセージ、及び制御・管理メッセージに対応する動作については、方法２００における関連する説明部分を参照されたく、詳細をここで再び説明することはしない。
【0179】
加えて、この出願の一実施形態は更に、図６に示すような通信装置６００を提供する。図６は、この出願の一実施形態に従った通信装置の構成の概略図である。通信装置６００は、トランシーバユニット６０１及び処理ユニット６０２を含む。通信装置６００は、上述の実施形態における方法１００、方法２００、方法３００、又は方法４００を実行するように構成され得る。
【0180】
一例において、通信装置６００は、上述の実施形態における方法１００を実行し得る。通信装置６００が上述の実施形態における方法１００を実行するように構成される場合、トランシーバユニット６０１は、方法１００における受信及び送信動作を実行するように構成される（この出願において、受信及び送信動作は、受信及び／又は送信に関係する動作である）。処理ユニット６０２は、方法１００における受信及び送信動作以外の動作を実行するように構成される。例えば、処理ユニット６０２は、第１のＩＰｖ６パケットを取得するように構成され、該第１のＩＰｖ６パケットは連合チャネルを含み、該連合チャネルは複数の異なるタイプの制御チャネルを搬送し、各タイプの制御チャネルが少なくとも１つのタイプの制御・管理メッセージを搬送する。トランシーバユニット６０１は、第１のＩＰｖ６パケットを転送するように構成される。
【0181】
一例において、通信装置６００は、上述の実施形態における方法２００を実行し得る。通信装置６００が上述の実施形態における方法２００を実行するように構成される場合、トランシーバユニット６０１は、方法２００における受信及び送信動作を実行するように構成される。処理ユニット６０２は、方法２００における受信及び送信動作以外の動作を実行するように構成される。例えば、処理ユニット６０２は、第１のＩＰｖ６パケットを取得するように構成され、該第１のＩＰｖ６パケットは障害指示チャネルを含み、該障害指示チャネルは第１パスの障害指示情報を記録する。トランシーバユニット６０１は、第１のＩＰｖ６パケットを転送するように構成される。
【0182】
一例において、通信装置６００は、上述の実施形態における方法３００を実行し得る。通信装置６００が上述の実施形態における方法３００を実行するように構成される場合、トランシーバユニット６０１は、方法３００における受信及び送信動作を実行するように構成される。処理ユニット６０２は、方法３００における受信及び送信動作以外の動作を実行するように構成される。例えば、トランシーバユニット６０１は、第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを受信するように構成され、該第１のＩＰｖ６パケットは連合チャネルを含み、該連合チャネルは複数の異なるタイプの制御チャネルを搬送し、各タイプの制御チャネルが少なくとも１つのタイプの制御・管理メッセージを搬送する。処理ユニット６０２は、上記少なくとも１つのタイプの制御・管理メッセージに対応する動作を実行するように構成される。
【0183】
一例において、通信装置６００は、上述の実施形態における方法４００を実行し得る。通信装置６００が上述の実施形態における方法４００を実行するように構成される場合、トランシーバユニット６０１は、方法４００における受信及び送信動作を実行するように構成される。処理ユニット６０２は、方法４００における受信及び送信動作以外の動作を実行するように構成される。例えば、トランシーバユニット６０１は、第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを受信するように構成され、該第１のＩＰｖ６パケットは障害指示チャネルを含み、該障害指示チャネルは第１パスの障害指示情報を記録する。処理ユニット６０２は、第１パスの障害指示情報を取得するように構成される。
【0184】
加えて、この出願の一実施形態は更に、図７に示すような通信装置７００を提供する。図７は、この出願の一実施形態に従った通信装置の構成の概略図である。通信装置７００は、通信インタフェース７０１と、通信インタフェース７０１に接続されたプロセッサ７０２とを含む。通信装置７００は、上述の実施形態における方法１００、方法２００、方法３００、又は方法４００を実行するように構成され得る。
【0185】
一例において、通信装置７００は、上述の実施形態における方法１００を実行し得る。通信装置７００が上述の実施形態における方法１００を実行するように構成される場合、通信インタフェース７０１は、方法１００における受信及び送信動作を実行するように構成される。プロセッサ７０２は、方法１００における受信及び送信動作以外の動作を実行するように構成される。例えば、プロセッサ７０２は、第１のＩＰｖ６パケットを取得するように構成され、該第１のＩＰｖ６パケットは連合チャネルを含み、該連合チャネルは複数の異なるタイプの制御チャネルを搬送し、各タイプの制御チャネルが少なくとも１つのタイプの制御・管理メッセージを搬送する。通信インタフェース７０１は、第１のＩＰｖ６パケットを転送するように構成される。
【0186】
一例において、通信装置７００は、上述の実施形態における方法２００を実行し得る。通信装置７００が上述の実施形態における方法２００を実行するように構成される場合、通信インタフェース７０１は、方法２００における受信及び送信動作を実行するように構成される。プロセッサ７０２は、方法２００における受信及び送信動作以外の動作を実行するように構成される。例えば、プロセッサ７０２は、第１のＩＰｖ６パケットを取得するように構成され、該第１のＩＰｖ６パケットは障害指示チャネルを含み、該障害指示チャネルは第１パスの障害指示情報を記録する。通信インタフェース７０１は、第１のＩＰｖ６パケットを転送するように構成される。
【0187】
一例において、通信装置７００は、上述の実施形態における方法３００を実行し得る。通信装置７００が上述の実施形態における方法３００を実行するように構成される場合、通信インタフェース７０１は、方法３００における受信及び送信動作を実行するように構成される。プロセッサ７０２は、方法３００における受信及び送信動作以外の動作を実行するように構成される。例えば、通信インタフェース７０１は、第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを受信するように構成され、該第１のＩＰｖ６パケットは連合チャネルを含み、該連合チャネルは複数の異なるタイプの制御チャネルを搬送し、各タイプの制御チャネルが少なくとも１つのタイプの制御・管理メッセージを搬送する。プロセッサ７０２は、上記少なくとも１つのタイプの制御・管理メッセージに対応する動作を実行するように構成される。
【0188】
一例において、通信装置７００は、上述の実施形態における方法４００を実行し得る。通信装置７００が上述の実施形態における方法４００を実行するように構成される場合、通信インタフェース７０１は、方法４００における受信及び送信動作を実行するように構成される。プロセッサ７０２は、方法４００における受信及び送信動作以外の動作を実行するように構成される。例えば、通信インタフェース７０１は、第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを受信するように構成され、該第１のＩＰｖ６パケットは障害指示チャネルを含み、該障害指示チャネルは第１パスの障害指示情報を記録する。プロセッサ７０２は、第１パスの障害指示情報を取得するように構成される。
【0189】
【0190】
通信装置８００は、上述の実施形態における方法１００、方法２００、方法３００、又は方法４００を実行するように構成され得る。
【0191】
図８に示すように、通信装置８００は、プロセッサ８１０と、プロセッサ８１０に結合されたメモリ８２０と、トランシーバ８３０とを含み得る。トランシーバ８３０は、例えば、通信インタフェース、光モジュール、又はこれらに類するものとし得る。プロセッサ８１０は、中央処理ユニット（central processing unit，ＣＰＵ）、ネットワークプロセッサ（network processor，ＮＰ）、又はＣＰＵとＮＰとの組み合わせとし得る。あるいは、プロセッサは、特定用途向け集積回路（application-specific integrated circuit，ＡＳＩＣ）、プログラマブルロジックデバイス（programmable logic device，ＰＬＤ）、又はこれらの組み合わせであってもよい。ＰＬＤは、コンプレックスプログラマブルロジックデバイス（complex programmable logic device，ＣＰＬＤ）、フィールドプログラマブルロジックゲートアレイ（field programmable gate array，ＦＰＧＡ）、ジェネリックアレイロジック（generic array logic，ＧＡＬ）、又はこれらの任意の組み合わせとし得る。プロセッサ８１０は、１つのプロセッサであってもよいし、複数のプロセッサを含んでいてもよい。メモリ８２０は、例えばランダムアクセスメモリ（random access memory，ＲＡＭ）といった揮発性メモリ（volatile memory）を含み得る。メモリはまた、例えば読み出し専用メモリ（read-only memory，ＲＯＭ）、フラッシュメモリ（flash memory）、ハードディスクドライブ（hard disk drive，ＨＤＤ）、又はソリッドステートドライブ（solid-state drive，ＳＳＤ）といった、不揮発性メモリ（non-volatile memory）を含み得る。メモリ８２０は更に、上述のタイプの組み合わせを含んでいてもよい。メモリ８２０は、１つのメモリであってもよいし、複数のメモリを含んでいてもよい。一実装において、メモリ８２０はコンピュータ読み取り可能命令を格納し、該コンピュータ読み取り可能命令は、例えば送信モジュール８２１、処理モジュール８２２、及び受信モジュール８２３といった、複数のソフトウェアモジュールを含む。各ソフトウェアモジュールを実行した後、プロセッサ８１０は、各ソフトウェアモジュールの指示に基づいて対応する動作を実行し得る。この実施形態において、ソフトウェアモジュールによって実行される動作は、実際には、ソフトウェアモジュールの指示に基づいてプロセッサ８１０によって実行される動作である。
【0192】
一例において、通信装置８００は、上述の実施形態における方法１００を実行し得る。通信装置８００が上述の実施形態における方法１００を実行するように構成される場合、トランシーバ８３０は、方法１００における受信及び送信動作を実行するように構成される。プロセッサ８１０は、方法１００における受信及び送信動作以外の動作を実行するように構成される。例えば、プロセッサ８１０は、第１のＩＰｖ６パケットを取得するように構成され、該第１のＩＰｖ６パケットは連合チャネルを含み、該連合チャネルは複数の異なるタイプの制御チャネルを搬送し、各タイプの制御チャネルが少なくとも１つのタイプの制御・管理メッセージを搬送する。トランシーバ８３０は、第１のＩＰｖ６パケットを転送するように構成される。
【0193】
一例において、通信装置８００は、上述の実施形態における方法２００を実行し得る。通信装置８００が上述の実施形態における方法２００を実行するように構成される場合、トランシーバ８３０は、方法２００における受信及び送信動作を実行するように構成される。プロセッサ８１０は、方法２００における受信及び送信動作以外の動作を実行するように構成される。例えば、プロセッサ８１０は、第１のＩＰｖ６パケットを取得するように構成され、該第１のＩＰｖ６パケットは障害指示チャネルを含み、該障害指示チャネルは第１パスの障害指示情報を記録する。トランシーバ８３０は、第１のＩＰｖ６パケットを転送するように構成される。
【0194】
一例において、通信装置８００は、上述の実施形態における方法３００を実行し得る。通信装置８００が上述の実施形態における方法３００を実行するように構成される場合、トランシーバ８３０は、方法３００における受信及び送信動作を実行するように構成される。プロセッサ８１０は、方法３００における受信及び送信動作以外の動作を実行するように構成される。例えば、トランシーバ８３０は、第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを受信するように構成され、該第１のＩＰｖ６パケットは連合チャネルを含み、該連合チャネルは複数の異なるタイプの制御チャネルを搬送し、各タイプの制御チャネルが少なくとも１つのタイプの制御・管理メッセージを搬送する。プロセッサ８１０は、上記少なくとも１つのタイプの制御・管理メッセージに対応する動作を実行するように構成される。
【0195】
一例において、通信装置８００は、上述の実施形態における方法４００を実行し得る。通信装置８００が上述の実施形態における方法４００を実行するように構成される場合、トランシーバ８３０は、方法４００における受信及び送信動作を実行するように構成される。プロセッサ８１０は、方法４００における受信及び送信動作以外の動作を実行するように構成される。例えば、トランシーバ８３０は、第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを受信するように構成され、該第１のＩＰｖ６パケットは障害指示チャネルを含み、該障害指示チャネルは第１パスの障害指示情報を記録する。プロセッサ８１０は、第１パスの障害指示情報を取得するように構成される。
【0196】
この出願は更に、コンピュータ読み取り可能記憶媒体を提供する。当該コンピュータ読み取り可能記憶媒体は命令を格納する。該命令がコンピュータ上で実行されるとき、該コンピュータは、上述の実施形態のうちのいずれかの実施形態における方法（例えば、方法１００、方法２００、方法３００、及び方法４００）におけるいずれか１つ以上の動作を実行することが可能にされる。
【0197】
この出願は更に、コンピュータプログラムを含んだコンピュータプログラムプロダクトを提供する。該コンピュータプログラムがコンピュータ上で実行されるとき、該コンピュータは、上述の実施形態のうちのいずれかの実施形態における方法（例えば、方法１００、方法２００、方法３００、及び方法４００）におけるいずれか１つ以上の動作を実行することが可能にされる。
【0198】
この出願は更に、上述の実施形態において言及された方法１００を実行するための通信装置及び方法３００を実行するための通信装置を含む通信システムを提供する。
【0199】
この出願は更に、上述の実施形態において言及された方法２００を実行するための通信装置及び方法４００を実行するための通信装置を含む通信システムを提供する。
【0200】
この出願は更に、少なくとも１つのメモリと少なくとも１つのプロセッサとを含む通信システムを提供し、該少なくとも１つのメモリは命令を格納し、該少なくとも１つのプロセッサが命令を実行することで、当該通信システムは、この出願の上述の実施形態における、方法１００におけるいずれか１つ以上の動作及び方法３００におけるいずれか１つ以上の動作を実行する。
【0201】
この出願は更に、少なくとも１つのメモリと少なくとも１つのプロセッサとを含む通信システムを提供し、該少なくとも１つのメモリは命令を格納し、該少なくとも１つのプロセッサが命令を実行することで、当該通信システムは、この出願の上述の実施形態における、方法２００におけるいずれか１つ以上の動作及び方法４００におけるいずれか１つ以上の動作を実行する。
【0202】
この出願の明細書、特許請求の範囲、及び添付図面において、用語“第１”、“第２”、“第３”、“第４”、及びこれらに類するもの（存在する場合）は、同様の対象を区別するために用いられており、特定の順序又は順番を記述するために使用される必要はない。理解されるべきことには、このように使用されるデータは適切な状況において相互に入れ替え可能であり、それ故に、ここで説明されたこの出願の実施形態は、図面に示された又はここで説明されたものとは異なる順序で実装されることができる。また、用語“含む”及び“有する”並びにこれらの任意の変形は、非排他的な包含をカバーすることを意図している。例えば、一連のステップ又はユニットを含むプロセス、方法、システム、プロダクト、又は装置は、明確に列挙されたステップ又はユニットに限定される必要はなく、明確に列挙されてはいない他のステップ又はユニットや、そのプロセス、方法、プロダクト、又は装置に生来的に備わる他のステップ又はユニットを含み得る。
【0203】
当業者によって明確に理解され得ることには、簡便且つ簡潔な説明の目的のため、上述のシステム、装置、及びユニットの具体的な動作プロセスについては、上述の方法の実施形態における対応するプロセスを参照されたい。詳細をここで再び説明することはしない。
【0204】
この出願にて提供された幾つかの実施形態において、理解されるべきことには、開示されたシステム、装置、及び方法は、その他のようにして実施されてもよい。例えば、記載された装置の実施形態は単なる例である。例えば、ユニット分割は、単なる論理サービス分割であり、実際の実装においてはその他の方式が存在し得る。例えば、複数のユニット又はコンポーネントが別のシステムへと組み合わされたり統合されたりしてもよく、あるいは、一部の機構が無視されたり実行されなかったりしてもよい。また、示された又は説明された相互結合又は直接結合又は通信接続は、何らかのインタフェースを介して実装され得る。装置又はユニットの間の間接結合又は通信接続は、電子的な形態、機械的な形態、又はその他の形態にて実装され得る。
【0205】
別々の部分として記載されたユニットは、物理的に別々であってもなくてもよく、また、ユニットとして示されたコンポーネントは、物理的なユニットであってもなくてもよく、すなわち、一箇所にあってもよいし複数のネットワークユニットに分散されてもよい。それらユニットの一部又は全てが、実施形態のソリューションの目的を達成するように、実際の要求に従って選択され得る。
【0206】
また、この出願の実施形態における複数のサービスユニットが１つの処理ユニットへと統合されてもよく、あるいは、それらユニットの各々が物理的に単独で存在してもよく、あるいは、２つ以上のユニットが１つのユニットへと統合される。統合されるユニットは、ハードウェアの形態で実装されてもよいし、ソフトウェアサービスユニットの形態で実装されてもよい。
【0207】
統合されたユニットがソフトウェアサービスユニットの形態で実装されて、独立したプロダクトとして販売又は使用されるとき、その統合されたユニットはコンピュータ読み取り可能記憶媒体に格納されてもよい。このような理解に基づき、この出願の技術的ソリューションは本質的に、又は現行技術に対して寄与する部分は、又は技術的ソリューションの全て若しくは一部は、ソフトウェアプロダクトの形態で実装され得る。コンピュータソフトウェアプロダクトは、記憶媒体に格納されるとともに、この出願の実施形態にて記載された方法のステップの全て又は一部を実行するようにコンピュータ装置（これは、パーソナルコンピュータ、サーバ、ネットワーク装置、及びこれらに類するもの）に命令する幾つかの命令を含む。上述の記憶媒体は、例えばＵＳＢフラッシュドライブ、リムーバブルハードディスク、読み出し専用メモリ（read-only memory，ＲＯＭ）、ランダムアクセスメモリ（random access memory，ＲＡＭ）、磁気ディスク、又は光ディスクなどの、プログラムコードを記憶することができる任意の媒体を含む。
【0208】
当業者が認識するはずのことには、上述の１つ以上の例において、本発明にて説明されるサービスは、ハードウェア、ソフトウェア、ファームウェア、又はこれらの任意の組み合わせを用いて実装され得る。サービスがソフトウェアを用いて実装される場合、サービスは、コンピュータ読み取り可能媒体に格納されたり、コンピュータ読み取り可能媒体上の１つ以上の命令又はコードとして伝送されたりし得る。コンピュータ読み取り可能媒体は、コンピュータ記憶媒体及び通信媒体を含み、通信媒体は、ある場所から別の場所へのコンピュータプログラムの伝送を容易にする任意の媒体を含む。記憶媒体は、汎用コンピュータ又は専用コンピュータによってアクセスされることができる任意の利用可能な媒体とし得る。
【0209】
本発明の目的、技術的ソリューション、及び有益な効果は、上述の具体的な実装において更に詳細に説明されている。理解されるべきことには、上述のものは単に本発明の具体的な実装にすぎない。
【0210】
上述の実施形態は、単にこの出願の技術的ソリューションを説明するための用いられており、技術的ソリューションを限定することを意図するものではない。この出願は上述の実施形態を参照して詳細に説明されているが、当業者が理解するはずのことには、上述の実施形態で説明された技術的ソリューションにはなおも変更が為されたり、技術的特徴の部分に対して均等な置き換えが為されたりすることができ、そのような変更又は置き換えは、対応する技術的ソリューションの本質をこの出願の実施形態における技術的ソリューションの精神及び範囲から逸脱させることにはならないものである。
【図1a】
【図1b】
【図2a-1】
【図2a-2】
【図2b】
【図2c】
【図2d】
【図2e】
【図2f】
【図2g】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【手続補正書】
【提出日】2023-07-19
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
パケット処理方法であって、第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを受信するステップであり、該第１のＩＰｖ６パケットは、連合チャネルを有し、該連合チャネルは、複数の異なるタイプの制御チャネルを搬送し、各タイプの制御チャネルが、少なくとも１つのタイプの制御・管理メッセージを搬送する、ステップと、
前記少なくとも１つのタイプの制御・管理メッセージを取得するステップと、
を有する方法。
【請求項2】
前記第１のＩＰｖ６パケットは指示情報を有し、該指示情報が前記連合チャネルを示す、請求項１に記載の方法。
【請求項3】
前記指示情報はタイプ長さ値（ＴＬＶ）フィールド内で搬送され、該ＴＬＶフィールドのタイプフィールドが前記指示情報を搬送する、請求項２に記載の方法。
【請求項4】
前記ＴＬＶフィールドはチャネルタイプフィールドを有し、該チャネルタイプフィールドは、前記連合チャネルによって搬送される制御チャネルのタイプを示す、請求項３に記載の方法。
【請求項5】
前記連合チャネルは、前記第１のＩＰｖ６パケットの拡張ヘッダ内で搬送され、該拡張ヘッダは、ホップバイホップ（ＨＢＨ）オプションヘッダ又は宛先オプションヘッダ（ＤＯＨ）である、請求項１に記載の方法。
【請求項6】
前記第１のＩＰｖ６パケットは、セグメントルーティングインターネットプロトコルバージョン６（ＳＲｖ６）パケットである、請求項１に記載の方法。
【請求項7】
前記連合チャネルは、前記第１のＩＰｖ６パケットの拡張ヘッダ内で搬送され、該拡張ヘッダは、セグメントルーティングヘッダ（ＳＲＨ）である、請求項６に記載の方法。
【請求項8】
前記第１のＩＰｖ６パケットは識別情報を有し、該識別情報は第１パスを識別するために使用され、該第１パスは前記第１のＩＰｖ６パケットの伝送パスである、請求項１に記載の方法。
【請求項9】
前記識別情報は、前記連合チャネルと前記第１パスとの間の関連付け関係を特定するために前記第１パス上のノードによって使用される、請求項８に記載の方法。
【請求項10】
前記第１のＩＰｖ６パケットは、セグメントルーティングインターネットプロトコルバージョン６（ＳＲｖ６）パケットであり、該ＳＲｖ６パケットのセグメントリスト（ｓｅｇｍｅｎｔ ｌｉｓｔ）又はパスセグメント（ｐａｔｈ ｓｅｇｍｅｎｔ）が前記識別情報を搬送する、請求項８に記載の方法。
【請求項11】
前記複数の異なるタイプの制御チャネルは、運用・管理・保守（ＯＡＭ）チャネルと、障害指示チャネル、リソース管理チャネル、シグナリング通信チャネル（ＳＣＣ）、及び管理通信チャネル（ＭＣＣ）、
のうちのいずれか１つ以上を有する、請求項１に記載の方法。
【請求項12】
前記障害指示チャネルによって搬送される制御・管理メッセージは障害指示情報を記録する、請求項１１に記載の方法。
【請求項13】
前記連合チャネルは、前記第１のＩＰｖ６パケットのペイロード内で搬送される、請求項１に記載の方法。
【請求項14】
前記第１のＩＰｖ６パケットの前記ペイロードは更にユーザデータを搬送する、請求項１３に記載の方法。
【請求項15】
パケット処理方法であって、
第１のインターネットプロトコルバージョン６（ＩＰｖ６）パケットを取得するステップであり、該第１のＩＰｖ６パケットは、連合チャネルを有し、該連合チャネルは、複数の異なるタイプの制御チャネルを搬送し、各タイプの制御チャネルが、少なくとも１つのタイプの制御・管理メッセージを搬送する、ステップと、
前記第１のＩＰｖ６パケットを転送するステップと、
を有する方法。
【請求項16】
メモリ及びプロセッサを有する通信装置であって、前記メモリは、プログラムコードを格納するように構成され、
前記プロセッサは、請求項１乃至１５のいずれか一項に記載の方法を前記通信装置が実行するように、前記プログラムコード内の命令を実行するように構成される、
通信装置。
【請求項17】
プログラムを有するコンピュータプログラムプロダクトであって、前記プログラムがプロセッサ上で実行されるときに、請求項１乃至１５のいずれか一項に記載の方法が実施される、コンピュータプログラムプロダクト。
【請求項18】
請求項１乃至１４のいずれか一項に記載の方法を実行するための通信装置と、請求項１５に記載の方法を実行するための通信装置、を有する通信システム。
【手続補正2】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【0001】
この出願は、通信分野に関し、特に、パケット処理方法及び装置に関する。
【手続補正3】
【補正対象書類名】明細書
【補正対象項目名】０００６
【補正方法】変更
【補正の内容】
【0006】
この出願では、全般的な連合チャネルがＩＰｖ６パケットにおいて設計され、該連合チャネルを使用することによって様々な異なるタイプの制御チャネルを搬送することができる。従って、ＩＰｖ６ネットワークのために複数の制御及び管理機能を実装する必要がある場合に、１つの全般的な連合チャネルが複数の異なるタイプの制御チャネルを搬送することができ、すなわち、複数のタイプの制御・管理メッセージを、それら複数のタイプの制御・管理メッセージを搬送するために複数のプロトコルを使用することなく、１つの全般的な連合チャネルで搬送し得る。従って、ネットワーク装置間での制御・管理シグナリングの量が削減され、制御・管理シグナリングの伝送方式が簡略化され、幾つかの新しい制御・管理チャネルをＩＰｖ６ネットワークにおいてサポートすることができる。例えば、この出願の実施形態におけるシグナリング通信チャネルＳＣＣ、管理通信チャネルＭＣＣ、及び障害指示チャネルをサポートすることができ、ＩＰｖ６ネットワーク上での制御及び管理の効率を向上させる。連合チャネルが複数のプロトコルの制御・管理メッセージを搬送することで、１つのパケットを用いて複数のＴＬＶフィールドを搬送して、装置間で制御・管理情報を伝送するパケットの量を減らすことができる。取り得る一実装において、連合チャネルは一般的なＴＬＶフォーマットであることができ、ＴＬＶカプセル化をＩＰｖ６拡張ヘッダ内で行うことで、制御・管理メッセージのパケットカプセル化及び伝送方式を統一化及び簡略化し、例えばユーザデータグラムプロトコルポート番号エントリといった装置保守パラメータを減少させる。さらに、この出願における連合チャネルに基づいて、可変値長を持つＴＬＶフォーマットにおける制御・管理メッセージの伝送が、拡張によって更にサポートされ得る。従って、より多くのチャネル保守情報が搬送され得る。この出願のこの実施形態で提供されるソリューションに基づいて、ＩＰｖ６パケットヘッダを用いてメッセージ伝送が行われることで、パケットヘッダのコンテンツについて高速なパス処理を装置転送プレーン上で行うことができメッセージ処理効率を向上させる。
【国際調査報告】