特許7329627 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ 中興通訊股▲ふん▼有限公司の特許一覧

特許7329627パケット処理方法及び関連装置

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-08-09

(45)【発行日】2023-08-18

(54)【発明の名称】パケット処理方法及び関連装置

(51)【国際特許分類】

H04L 47/431 20220101AFI20230810BHJP

H04L 47/6275 20220101ALI20230810BHJP

【ＦＩ】

H04L47/431

H04L47/6275

【請求項の数】 17

(21)【出願番号】P 2021573141

(86)(22)【出願日】2020-06-05

(65)【公表番号】

(43)【公表日】2022-09-13

(86)【国際出願番号】 CN2020094646

(87)【国際公開番号】W WO2021004210

(87)【国際公開日】2021-01-14

【審査請求日】2021-12-10

(31)【優先権主張番号】201910615340.8

(32)【優先日】2019-07-09

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】511151662

【氏名又は名称】中興通訊股▲ふん▼有限公司

【氏名又は名称原語表記】ＺＴＥＣＯＲＰＯＲＡＴＩＯＮ

【住所又は居所原語表記】ＺＴＥＰｌａｚａ，ＫｅｊｉＲｏａｄＳｏｕｔｈ，Ｈｉ－ＴｅｃｈＩｎｄｕｓｔｒｉａｌＰａｒｋ，ＮａｎｓｈａｎＳｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ５１８０５７Ｃｈｉｎａ

(74)【代理人】

【識別番号】110002468

【氏名又は名称】弁理士法人後藤特許事務所

(74)【代理人】

【識別番号】100199819

【弁理士】

【氏名又は名称】大行尚哉

(74)【代理人】

【識別番号】100087859

【弁理士】

【氏名又は名称】渡辺秀治

(72)【発明者】

【氏名】劉峰

【審査官】大石博見

(56)【参考文献】

【文献】特表２０２０－５１８１７２（ＪＰ，Ａ）

【文献】国際公開第２０１８／１９５７２８（ＷＯ，Ａ１）

【文献】米国特許出願公開第２００４／０１８４４４９（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ４７／４３１

Ｈ０４Ｌ４７／６２７５

(57)【特許請求の範囲】

【請求項1】

ソースノードデバイスに適用されるクライアントパケットの処理方法であって、
予め設定されたフラグメントの長さに従ってクライアントパケットをフラグメントしてカプセル化し、各フラグメントのいずれにもラベル値を追加することであって、そのうち、前記ラベル値は、フラグメントにおけるクライアントパケットの特徴情報を識別することに用いられることと、
カプセル化されたフラグメントを出力することと、を含み、
前記ラベル値のコンテンツは、パケットフロー番号及びフローシーケンス番号のうちの１つまたは複数を含む
ことを特徴とするクライアントパケットの処理方法。

【請求項2】

前記フラグメントに、プリアンブル及び開始フレーム識別子がさらに設けられている、
ことを特徴とする請求項１に記載の方法。

【請求項3】

前記方法は、
タイムセンシティブネットワークＴＳＮプロトコルに基づいて、前記クライアントパケットの最初のフラグメントの先頭フィールドをプリアンブルフィールド、第１開始フレーム識別子ＳＭＤ－ＳＸフィールド及びラベル値フィールドとして設定し、前記クライアントパケットの後続フラグメントの先頭フィールドをプリアンブルフィールド、第２開始フレーム識別子ＳＭＤ－ＣＸフィールド及びラベル値フィールドとして設定することをさらに含む、
ことを特徴とする請求項２に記載の方法。

【請求項4】

予め設定されたフラグメントの長さに従ってクライアントパケットをフラグメントしてカプセル化することは、
前記クライアントパケットの情報量が前記予め設定されたフラグメントの長さよりも小さい場合、前記予め設定されたフラグメントの長さ未満の箇所をアイドル情報で充填した後に、前記クライアントパケットをカプセル化することと、
１つのフラグメントに同じクライアントの複数のクライアントパケットが含まれる場合、フラグメントにおける各クライアントパケットのそれぞれの前に当該クライアントパケットの長さをカプセル化することと、を含む、
ことを特徴とする請求項１に記載の方法。

【請求項5】

予め設定されたフラグメントの長さに従ってクライアントパケットをフラグメントした後に、カプセル化されたフラグメントを出力する前に、前記方法は、
前記フラグメントのＣＲＣチェック値を計算し、前記ＣＲＣチェック値を前記フラグメント内にカプセル化することをさらに含む、
ことを特徴とする請求項１～４のいずれか１項に記載の方法。

【請求項6】

カプセル化されたフラグメントを出力することは、
予め設定された送信時間に従って、予め設定された送信レートでカプセル化されたフラグメントを出力することを含む、
ことを特徴とする請求項１～４のいずれか１項に記載の方法。

【請求項7】

前記クライアントパケットは、イーサネットＭＡＣパケット及びＰＣＳ層の符号化ブロックのうちの１つまたは複数を含む、
ことを特徴とする請求項１～４のいずれか１項に記載の方法。

【請求項8】

中間ノードデバイスに適用されるパケット処理方法であって、前記方法は、
受信したカプセル化後のフラグメントがパススルー操作であるか終結操作であるかを判断することと、
前記フラグメントに対してパススルー操作を行うと判定された場合、前記フラグメントに担持されたラベル値に基づいて前記フラグメントをスケジューリングして出力することと、を含む、
ことを特徴とするパケット処理方法。

【請求項9】

受信したフラグメントがパススルー操作であるか終結操作であるかを判断することは、
前記フラグメントにおけるラベル値を解析し、パケットフロー番号を取得することと、
前記パケットフロー番号に基づいて、前記フラグメントがパススルー操作であるか終結操作であるかを判断することと、を含む、
ことを特徴とする請求項８に記載の方法。

【請求項10】

前記フラグメントに担持されたラベル値に基づいて前記フラグメントをスケジューリングして出力することは、
前記パケットフロー番号に基づいて前記フラグメントをスケジューリングして出力することを含む、
ことを特徴とする請求項９に記載の方法。

【請求項11】

シンクノードデバイスに適用されるパケット処理方法であって、前記方法は、
受信したカプセル化後のフラグメントがパススルー操作であるか終結操作であるかを判断することと、
前記フラグメントに対して終結操作を行うと判定された場合、前記フラグメントに担持されたラベル値に基づいてフラグメントパケットを再構築し、クライアントパケットを復元することと、を含む、
ことを特徴とするパケット処理方法。

【請求項12】

受信したフラグメントがパススルー操作であるか終結操作であるかを判断することは、
前記フラグメントにおけるラベル値を解析し、パケットフロー番号を取得することと、
前記パケットフロー番号に基づいて、前記フラグメントがパススルー操作であるか終結操作であるかを判断することと、を含む、
ことを特徴とする請求項１１に記載の方法。

【請求項13】

前記フラグメントに担持されたラベル値に基づいて前記フラグメントパケットを再構築することは、
前記フラグメントにおけるラベル値を解析し、フラグメントシーケンス番号を取得することと、
前記フラグメントシーケンス番号及び前記フラグメントのリアセンブルに基づいてクライアントパケットを得ることと、を含む、
ことを特徴とする請求項１１または１２に記載の方法。

【請求項14】

プロセッサによって実行される際に、請求項１～１３のいずれか１項に記載の方法のステップを実現するコンピュータプログラムが格納されている、
ことを特徴とするコンピュータ読み取り可能な記憶媒体。

【請求項15】

メモリと、プロセッサと、前記メモリに格納され、前記プロセッサ上で実行可能であり、前記プロセッサによって実行される際に請求項１～７のいずれか１項に記載の方法のステップを実現するコンピュータプログラムと、を備える、
ことを特徴とするソースノードデバイス。

【請求項16】

メモリと、プロセッサと、前記メモリに格納され、前記プロセッサ上で実行可能であり、前記プロセッサによって実行される際に請求項８～１０のいずれか１項に記載の方法のステップを実現するコンピュータプログラムと、を備える、
ことを特徴とする中間ノードデバイス。

【請求項17】

メモリと、プロセッサと、前記メモリに格納され、前記プロセッサ上で実行可能であり、前記プロセッサによって実行される際に請求項１１～１３のいずれか１項に記載の方法のステップを実現するコンピュータプログラムと、を備える、
ことを特徴とするシンクノードデバイス。

【発明の詳細な説明】

【関連出願の相互参照】

【0001】

本願は、出願番号が２０１９１０６１５３４０．８である、出願日が２０１９年７月９日である中国特許出願に基づいて提出され、当該中国特許出願の優先権が主張され、その開示全体はここで援用により本願に組み込まれるものとする。

【技術分野】

【0002】

本願は、通信分野に関し、特に、パケット処理方法及び関連装置に関する。

【背景技術】

【0003】

インターネット技術の急速な発展に伴い、ネットワーク上の伝送情報コンテンツは音声サービスからデータサービスに変化し、通信ネットワークは音声サービス向けの同期デジタル・ハイアラーキ（ＳｙｎｃｈｒｏｎｏｕｓＤｉｇｉｔａｌＨｉｅｒａｒｃｈｙ、ＳＤＨ）技術ネットワークからデータパケット向けのイーサネット技術ネットワークへ移行する。現在、通常のイーサネットパケットの長さが固定値（６４バイトから９６００バイトの間）ではないため、パケットでは、ネットワーク転送中にパケットフローに様々な長さのパケットが混在して伝送される現象が現れ、デバイス内でパケットを処理する時間が不確定であるため、これらのパケットは処理過程において処理の遅延時間が不確定になり、遅延時間が長くなり、遅延ジッタが大きくなってしまう。

【発明の概要】

【発明が解決しようとする課題】

【0004】

本願には、パケット処理方法及び関連装置が提供される。

【課題を解決するための手段】

【0005】

本願の実施例には、ソースノードデバイスに適用されるクライアントパケットの処理方法が提供され、前記方法は、予め設定されたフラグメントの長さに従ってクライアントパケットをフラグメントしてカプセル化し、各フラグメントのいずれにもラベル値を追加することであって、そのうち、前記ラベル値は、フラグメントにおけるクライアントパケットの特徴情報を識別することに用いられることと、カプセル化されたフラグメントを出力することと、を含む。

【0006】

本願の実施例には、中間ノードデバイスに適用されるパケット処理方法が提供され、前記方法は、受信したカプセル化後のフラグメントがパススルー操作であるか終結操作であるかを判断することと、前記フラグメントに対してパススルー操作を行うと判定された場合、前記フラグメントに担持されたラベル値に基づいて前記フラグメントをスケジューリングして出力することと、を含む。

【0007】

本願の実施例には、シンクノードデバイスに適用されるパケット処理方法が提供され、前記方法は、受信したカプセル化後のフラグメントがパススルー操作であるか終結操作であるかを判断することと、前記フラグメントに対して終結操作を行うと判定された場合、前記フラグメントに担持されたラベル値に基づいて前記フラグメントパケットを再構築し、前記クライアントパケットを復元することと、を含む。

【0008】

本願の実施例には、ソースノードデバイスに適用されるパケット処理装置が提供され、前記装置は、予め設定されたフラグメントの長さに従ってクライアントパケットをフラグメントしてカプセル化し、各フラグメントのいずれにもラベル値を追加することに用いられるフラグメントユニットであって、そのうち、前記ラベル値は、フラグメントにおけるクライアントパケットの特徴情報を識別することに用いられるフラグメントユニットと、カプセル化されたフラグメントを出力することに用いられる出力ユニットと、を備える。

【0009】

本願の実施例には、中間ノードデバイスに適用されるパケット処理装置が提供され、前記装置は、受信したカプセル化後のフラグメントがパススルー操作であるか終結操作であるかを判断し、前記フラグメントに対してパススルー操作を行うと判定された場合、第１処理ユニットをトリガすることに用いられる第１判断ユニットと、前記フラグメントに担持されたラベル値に基づいて前記フラグメントをスケジューリングして出力することに用いられる前記第１処理ユニットと、を備える。

【0010】

本願の実施例には、シンクノードデバイスに適用されるパケット処理装置が提供され、前記装置は、受信したカプセル化後のフラグメントがパススルー操作であるか終結操作であるかを判断し、前記フラグメントに対して終結操作を行うと判定された場合、第２処理ユニットをトリガすることに用いられる第２判断ユニットと、前記フラグメントに担持されたラベル値に基づいて前記フラグメントパケットを再構築し、前記クライアントパケットを復元することに用いられる前記第２処理ユニットと、を備える。

【0011】

本願の実施例には、プロセッサによって実行される際に、上記のいずれかの方法のステップを実現するコンピュータプログラムが格納されているコンピュータ読み取り可能な記憶媒体が提供される。

【0012】

本願の実施例には、メモリと、プロセッサと、前記メモリに格納され、前記プロセッサ上で実行可能であり、前記プロセッサによって実行される際に上記のいずれかのソースノードデバイス側の方法のステップを実現するコンピュータプログラムと、を備えるソースノードデバイスが提供される。

【0013】

本願の実施例には、メモリと、プロセッサと、前記メモリに格納され、前記プロセッサ上で実行可能であり、前記プロセッサによって実行される際に上記のいずれかの中間ノードデバイス側に記載の方法のステップを実現するコンピュータプログラムと、を備える中間ノードデバイスが提供される。

【0014】

本願の実施例には、メモリと、プロセッサと、前記メモリに格納され、前記プロセッサ上で実行可能であり、前記プロセッサによって実行される際に上記のいずれかのシンクノードデバイス側に記載の方法のステップを実現するコンピュータプログラムと、を備えるシンクノードデバイスが提供される。

【図面の簡単な説明】

【0015】

【図1】図１は、本願の第１実施例におけるクライアントパケットの処理方法のフローチャートである。

【図2】図２は、従来のイーサネットネットワークによるパケット伝送の過程を示す図である。

【図3】図３は、スケジューラによる従来のイーサネットパケットの出力を示す図である。

【図4】図４は、従来のＴＳＮ技術によりパケットをプリエンプトして出力した後の順序関係を示す図である。

【図5】図５は、従来の一般的なイーサネットのパケット構成を示す図である。

【図6】図６は、従来のＴＳＮ技術による中断後のＴＳＮフラグメントの構成を示す図である。

【図7】図７は、本願の第１実施例における第１種のＴＳＮフラグメント方案の構成を示す図である。

【図8】図８は、本願の第１実施例におけるフラグメントラベルフィールドの構成を示す図である。

【図9】図９は、本願の第１実施例においてＴＳＮフラグメントがクライアントパケットを収容する構成を示す図である。

【図10】図１０は、本願の第１実施例における第２種のＴＳＮフラグメント方案の構成を示す図である。

【図11】図１１は、本願の第１実施例における第３種のＴＳＮフラグメント方案の構成を示す図である。

【図12】図１２は、本願の第１実施例における第４種のＴＳＮフラグメント方案の構成を示す図である。

【図13】図１３は、本願の第２実施例におけるクライアントパケットの処理方法のフローチャートである。

【図14】図１４は、本願の第２実施例において中間デバイスがＴＳＮフラグメントを処理する過程を示す図である。

【図15】図１５は、本願の第３実施例におけるクライアントパケットの処理方法のフローチャートである。

【図16】図１６は、本願の第３実施例においてシンクノードデバイスがクライアントパケットを回復する過程を示す図である。

【図17】図１７は、本願の第４実施例におけるクライアントパケットの処理装置の構成を示す図である。

【図18】図１８は、本願の第５実施例におけるクライアントパケットの処理装置の構成を示す図である。

【図19】図１９は、本願の第６実施例におけるクライアントパケットの処理装置の構成を示す図である。

【発明を実施するための形態】

【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】

また、本願の実施例におけるクライアントパケットの後続フラグメントにおけるフラグメント順序カウンタｆｒａｇｃｏｕｎｔフィールド及びラベル値フィールドの位置は交換可能である。

【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】

本願の第８実施例には、メモリと、プロセッサと、前記メモリに格納され、前記プロセッサ上で実行可能であり、前記プロセッサによって実行される際に本願の第１実施例に記載のいずれかの方法のステップを実現するコンピュータプログラムと、を備えるソースノードデバイスが提供される。