(57)【要約】  データ送信方法が提供される。当該方法は、ネットワークデバイスにより、第1のパケットを生成し、第1のパケットを送信することを含む。第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含む。第1のパケットヘッダは指示フィールドを含む。指示フィールドは、第1のパケットが第2のパケットヘッダを含むことを示すために使用される。第2のパケットヘッダはタイプフィールドを含む。タイプフィールドは、第1の保護プロトコルを示すために使用される。保護データは、第1の保護プロトコルを使用することにより保護されたデータである。上記の技術的解決策では、第2のパケットヘッダはこの出願で定義されたパケットヘッダである。第2のパケット内のタイプフィールドの値が既存のプロトコルで定義されていないので、タイプフィールドはより多くの保護プロトコルを示してもよい。したがって、上記の技術的解決策は、良いスケーラビリティを有し、より多くの保護プロトコルをサポートできる。
2021524217.tif 000002
【特許請求の範囲】
【請求項１】
パケット送信方法であって、
ネットワークデバイスにより、第1のパケットを生成するステップであり、前記第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含み、前記第1のパケットヘッダは指示フィールドを含み、前記指示フィールドは、前記第1のパケットが前記第2のパケットヘッダを含むことを示すために使用され、前記第2のパケットヘッダはタイプフィールドを含み、前記タイプフィールドは、第1の保護プロトコルを示すために使用され、前記保護データは、前記第1の保護プロトコルを使用することにより保護されたデータである、ステップと、
前記ネットワークデバイスにより、前記第1のパケットを送信するステップと
を含む方法。
【請求項２】
前記第2のパケットヘッダはオフセットフィールドを更に含み、前記オフセットフィールドは、前記保護データの位置を示すために使用される、請求項１に記載の方法。
【請求項３】
前記第2のパケットヘッダはフラグフィールドを更に含み、前記フラグフィールドは、前記第2のパケットヘッダが前記オフセットフィールドを含むことを示す、請求項２に記載の方法。
【請求項４】
前記第2のパケットヘッダは長さフィールドを更に含み、前記長さフィールドは前記第2のパケットヘッダの長さを示す、請求項１乃至３のうちいずれか１項に記載の方法。
【請求項５】
前記第1の保護プロトコルは暗号化プロトコル又は完全性保護プロトコルである、請求項１乃至４のうちいずれか１項に記載の方法。
【請求項６】
パケット受信方法であって、
ネットワークデバイスにより、第1のパケットを受信するステップであり、前記第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含み、前記第1のパケットヘッダは指示フィールドを含み、前記指示フィールドは、前記第1のパケットが前記第2のパケットヘッダを含むことを示すために使用され、前記第2のパケットヘッダはタイプフィールドを含み、前記タイプフィールドは、第1の保護プロトコルを示すために使用され、前記保護データは、前記第1の保護プロトコルを使用することにより保護されたデータである、ステップと、
前記ネットワークデバイスにより、前記第1の保護プロトコル及び前記保護データに従って元のデータを取得するステップであり、前記元のデータは、前記第1の保護プロトコルを使用することにより保護されていない、ステップと
を含む方法。
【請求項７】
前記第2のパケットヘッダはオフセットフィールドを更に含み、前記オフセットフィールドは、前記保護データの位置を示すために使用される、請求項６に記載の方法。
【請求項８】
前記第2のパケットヘッダはフラグフィールドを更に含み、前記フラグフィールドは、前記第2のパケットヘッダが前記オフセットフィールドを含むことを示す、請求項７に記載の方法。
【請求項９】
前記第2のパケットヘッダは長さフィールドを更に含み、前記長さフィールドは前記第2のパケットヘッダの長さを示す、請求項６乃至８のうちいずれか１項に記載の方法。
【請求項１０】
前記第1の保護プロトコルは暗号化プロトコル又は完全性保護プロトコルである、請求項６乃至９のうちいずれか１項に記載の方法。
【請求項１１】
ネットワークデバイスであって、
プロセッサと、前記プロセッサに結合されたメモリとを含み、前記メモリは、コンピュータプログラムを記憶し、前記コンピュータプログラムが前記プロセッサにより実行されたとき、前記ネットワークデバイスは、
第1のパケットを生成し、前記第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含み、前記第1のパケットヘッダは指示フィールドを含み、前記指示フィールドは、前記第1のパケットが前記第2のパケットヘッダを含むことを示すために使用され、前記第2のパケットヘッダはタイプフィールドを含み、前記タイプフィールドは、第1の保護プロトコルを示すために使用され、前記保護データは、前記第1の保護プロトコルを使用することにより保護されたデータであり、
前記第1のパケットを送信する、
ことが可能になるネットワークデバイス。
【請求項１２】
前記第2のパケットヘッダはオフセットフィールドを更に含み、前記オフセットフィールドは、前記保護データの位置を示すために使用される、請求項１１に記載のネットワークデバイス。
【請求項１３】
前記第2のパケットヘッダはフラグフィールドを更に含み、前記フラグフィールドは、前記第2のパケットヘッダが前記オフセットフィールドを含むことを示す、請求項１２に記載のネットワークデバイス。
【請求項１４】
前記第2のパケットヘッダは長さフィールドを更に含み、前記長さフィールドは前記第2のパケットヘッダの長さを示す、請求項１１乃至１３のうちいずれか１項に記載のネットワークデバイス。
【請求項１５】
前記第1の保護プロトコルは暗号化プロトコル又は完全性保護プロトコルである、請求項１１乃至１４のうちいずれか１項に記載のネットワークデバイス。
【請求項１６】
ネットワークデバイスであって、
プロセッサと、前記プロセッサに結合されたメモリとを含み、前記メモリは、コンピュータプログラムを記憶し、前記コンピュータプログラムが前記プロセッサにより実行されたとき、前記ネットワークデバイスは、
第1のパケットを受信し、前記第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含み、前記第1のパケットヘッダは指示フィールドを含み、前記指示フィールドは、前記第1のパケットが前記第2のパケットヘッダを含むことを示すために使用され、前記第2のパケットヘッダはタイプフィールドを含み、前記タイプフィールドは、第1の保護プロトコルを示すために使用され、前記保護データは、前記第1の保護プロトコルを使用することにより保護されたデータであり、
前記第1の保護プロトコル及び前記保護データに従って元のデータを取得し、前記元のデータは、前記第1の保護プロトコルを使用することにより保護されていない、
ことが可能になるネットワークデバイス。
【請求項１７】
前記第2のパケットヘッダはオフセットフィールドを更に含み、前記オフセットフィールドは、前記保護データの位置を示すために使用される、請求項１６に記載のネットワークデバイス。
【請求項１８】
前記第2のパケットヘッダはフラグフィールドを更に含み、前記フラグフィールドは、前記第2のパケットヘッダが前記オフセットフィールドを含むことを示す、請求項１７に記載のネットワークデバイス。
【請求項１９】
前記第2のパケットヘッダは長さフィールドを更に含み、前記長さフィールドは前記第2のパケットヘッダの長さを示す、請求項１６乃至１８に記載のネットワークデバイス。
【請求項２０】
前記第1の保護プロトコルは暗号化プロトコル又は完全性保護プロトコルである、請求項１６乃至１９のうちいずれか１項に記載のネットワークデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願への相互参照］
この出願は、2018年9月17日に「PACKET  SENDING  METHOD,  PACKET  RECEIVING  METHOD,  AND  NETWORK  DEVICE」という名称で中国国家知識産権局に出願された中国特許出願第CN201811083093.3号の優先権を主張するものであり、その全内容を参照により援用する。
【０００２】
［技術分野］
この出願の実施形態は、通信技術の分野に関し、特に、パケット送信方法、パケット受信方法及びネットワークデバイスに関する。
【背景技術】
【０００３】
データセキュリティを強化するために、既存のネットワークで送信されるデータは、特定のプロトコルを使用することにより保護されることがある。以下では、特定のプロトコルを使用して保護されたデータは保護データと呼ばれ、データを保護するために使用されるプロトコルは保護プロトコルと呼ばれる。
【０００４】
ネットワークにおいて送信される保護データは、具体的にはパケットで搬送されてもよい。具体的には、パケットヘッダは、保護データに対応する保護プロトコルを示すために使用されるフィールドを含んでもよい。例えば、イーサネットフレームのパケットヘッダ(イーサネットフレームヘッダ)はイーサネットタイプ(Ethernet  type)フィールドを含む。Ethernet  typeフィールドの値が0x88E5であるとき、Ethernet  typeフィールドは、保護データに対応する保護プロトコルが媒体アクセス制御セキュリティ(media  access  control  security,  MACsec)プロトコルであることを示す。
【０００５】
上記の解決策は、比較的少数の保護プロトコルをサポートでき、比較的悪いスケーラビリティを有する。
【発明の概要】
【０００６】
この出願は、パケット送信方法、パケット受信方法及びネットワークデバイスを提供する。上記の技術的解決策は、より良いスケーラビリティを有し、より多くの保護プロトコルをサポートできる。
【０００７】
第1の態様によれば、パケット送信方法が提供される。当該方法は以下を含む。ネットワークデバイスは第1のパケットを生成し、第1のパケットを送信する。第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含む。第1のパケットヘッダは指示フィールドを含む。指示フィールドは、第1のパケットが第2のパケットヘッダを含むことを示すために使用される。第2のパケットヘッダはタイプフィールドを含む。タイプフィールドは、第1の保護プロトコルを示すために使用される。保護データは、第1の保護プロトコルを使用することにより保護されたデータである。
【０００８】
従来技術における解決法では、パケットヘッダ内の1つのフィールドが保護プロトコルを示すために使用される。以下では、従来技術におけるパケットヘッダ内で保護プロトコルを示すために使用されるフィールドは、特殊フィールドと呼ばれる。特殊フィールドのいくつかの値が特定のプロトコルで定義されていてもよい。したがって、特殊フィールドの利用可能な値の範囲は制限されてもよい。例えば、イーサネットフレームは、イーサネットフレームヘッダと、ペイロードとを含む。イーサネットフレームヘッダはEthernet  typeを含み、Ethernet  typeはペイロード内のパケットのプロトコルを示すために使用される。例えば、イーサネットフレームヘッダ内のEthernet  typeの値が0x0800であるとき、ペイロードはインターネットプロトコルバージョン4(internet  protocol  version  4,  IPv4)パケットを含み、或いは、イーサネットフレームヘッダのEthernet  typeの値が0x0806であるとき、ペイロードはアドレス解決プロトコル(address  resolution  protocol,  ARP)パケットを含む。したがって、Ethernet  typeは、理論的に216個のプロトコルを示す可能性がある。Ethernet  typeのいくつかの値が定義されているので、製品の実現の間にEthernet  typeの利用可能な値は216未満である。
【０００９】
この出願の解決策では、第1のパケットの第1のパケットヘッダは指示フィールドを含み、指示フィールドは、第1のパケットが第2のパケットヘッダを含むことを示し、第2のパケットヘッダはタイプフィールドを含み、タイプフィールドは第1の保護プロトコルを示す。上記のことは、この出願の解決策では、第1のパケットが第2のパケットヘッダを含むことを示すために、指示フィールドの1つの利用可能な値のみが使用される必要があることを意味する。第2のパケットヘッダはこの出願で定義されたパケットヘッダであり、第2のパケットヘッダ内のタイプフィールドの利用可能な値の範囲は制限されない。例えば、第2のパケットヘッダ内のタイプフィールドが16ビットを有するとき、第2のパケットヘッダ内のタイプフィールドは、理論的に216個の保護プロトコルを示してもよい。
【００１０】
この場合、この出願の解決策では、パケット内のフィールドは、より多くの保護プロトコルを示してもよい。したがって、この出願の解決策は、より良いスケーラビリティを有し、より多くの保護プロトコルをサポートできる。
【００１１】
可能な設計では、第2のパケットヘッダはオフセットフィールドを更に含み、オフセットフィールドは、保護データの位置を示すために使用される。
【００１２】
第1のパケットを受信した受信デバイスは、オフセットフィールドに基づいて保護データの位置を決定してもよい。さらに、受信デバイスは、元のデータを取得するために、保護データを保護解除してもよい。元のデータは、第1の保護プロトコルを使用することにより保護されていないデータである。
【００１３】
受信デバイスは、タイプフィールドにより示される第1の保護プロトコルに従って、第1のパケット内の保護データの位置を決定してもよい。例えば、第1の保護プロトコルがカプセル化セキュリティペイロード(encapsulating  security  payload,  ESP)プロトコルであるとき、受信デバイスは、保護データが第1のパケットのESPヘッダに続くことを決定してもよい。しかし、受信デバイスが第1の保護プロトコルに従って第1のパケット内の保護データの位置を決定するとき、受信デバイスは、比較的複雑な処理を実行する必要があり、第1のパケット内の保護データの位置を決定するのに多くの時間を費やす必要がある。オフセットフィールドに基づいて保護データの位置を決定することは比較的容易であり、これはより少ない時間を費やす。
【００１４】
可能な設計では、第2のパケットヘッダは長さフィールドを更に含み、長さフィールドは第2のパケットヘッダの長さを示す。
【００１５】
第1のパケットを受信した受信デバイスは、長さフィールドに基づいて保護プロトコルヘッダの位置を決定してもよい。例えば、第1の保護プロトコルがESPプロトコルであるとき、受信デバイスは、長さフィールドに基づいて第1のパケット内のESPヘッダの位置を決定してもよく、受信デバイスは、ESPプロトコルの規定に従ってESPヘッダを更に解析してもよい。
【００１６】
可能な設計では、第2のパケットヘッダはフラグフィールドを更に含み、フラグフィールドは、第2のパケットヘッダがオフセットフィールドを含むことを示す。
【００１７】
第1のパケットを受信した受信デバイスは、フラグフィールドに基づいて、第1のパケットがオフセットフィールドを含むことを決定してもよい。さらに、受信デバイスは、オフセットフィールドを取得し、オフセットフィールドに基づいて保護データの位置を決定してもよい。
【００１８】
第2の態様によれば、パケット受信方法が提供される。当該方法は以下を含む。ネットワークデバイスは第1のパケットを受信する。第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含む。第1のパケットヘッダは指示フィールドを含む。指示フィールドは、第1のパケットが第2のパケットヘッダを含むことを示すために使用される。第2のパケットヘッダはタイプフィールドを含む。タイプフィールドは、第1の保護プロトコルを示すために使用される。保護データは、第1の保護プロトコルを使用することにより保護されたデータである。
【００１９】
当該方法は以下を更に含む。ネットワークデバイスは、第1の保護プロトコル及び保護データに従って元のデータを取得する。元のデータは、第1の保護プロトコルを使用することにより保護されていない。
【００２０】
上記の技術的解決策では、第1のパケットは、第1の態様においてネットワークデバイスにより送信された第1のパケットでもよい。
【００２１】
可能な設計では、第2のパケットヘッダはオフセットフィールドを更に含み、オフセットフィールドは、保護データの位置を示すために使用される。
【００２２】
可能な設計では、第2のパケットヘッダは長さフィールドを更に含み、長さフィールドは第2のパケットヘッダの長さを示す。
【００２３】
可能な設計では、第2のパケットヘッダはフラグフィールドを更に含み、フラグフィールドは、第2のパケットヘッダがオフセットフィールドを含むことを示す。
【００２４】
第3の態様によれば、ネットワークデバイスが提供される。ネットワークデバイスは、プロセッサと、プロセッサに結合されたメモリとを含む。メモリは、コンピュータプログラムを記憶し、コンピュータプログラムがプロセッサにより実行されたとき、ネットワークデバイスは、第1の態様又は第1の態様の可能な設計において提供される方法を実行することが可能になる。
【００２５】
第4の態様によれば、ネットワークデバイスが提供される。ネットワークデバイスは、プロセッサと、プロセッサに結合されたメモリとを含む。メモリは、コンピュータプログラムを記憶し、コンピュータプログラムがプロセッサにより実行されたとき、ネットワークデバイスは、第2の態様又は第2の態様の可能な設計において提供される方法を実行することが可能になる。
【００２６】
第5の態様によれば、通信システムが提供され、第3の態様において提供されるネットワークデバイスと、第4の態様において提供されるネットワークデバイスとを含む。第3の態様において提供されるネットワークデバイスは、第1の態様又は第1の態様の可能な設計において提供される方法を実行するように構成される。第4の態様において提供されるネットワークデバイスは、第2の態様又は第2の態様の可能な設計において提供される方法を実行するように構成される。
【００２７】
第6の態様によれば、この出願はコンピュータ読み取り可能記憶媒体を提供する。コンピュータ読み取り可能記憶媒体は命令を記憶し、命令がコンピュータ上で実行されたとき、コンピュータは、第1の態様又は第1の態様の可能な設計において提供される方法を実行することが可能になる。
【００２８】
第7の態様によれば、この出願はコンピュータ読み取り可能記憶媒体を提供する。コンピュータ読み取り可能記憶媒体は命令を記憶し、命令がコンピュータ上で実行されたとき、コンピュータは、第2の態様又は第2の態様の可能な設計において提供される方法を実行することが可能になる。
【００２９】
可能な設計では、コンピュータ読み取り可能記憶媒体は、非一時的なコンピュータ読み取り可能記憶媒体である。
【００３０】
第8の態様によれば、この出願はコンピュータプログラム製品を提供する。コンピュータプログラム製品は命令を記憶し、命令がコンピュータ上で実行されたとき、コンピュータは、第1の態様又は第1の態様の可能な設計において提供される方法を実行することが可能になるか、或いは、コンピュータは、第2の態様又は第2の態様の可能な設計において提供される方法を実行することが可能になる。
【００３１】
第1の態様から第8の態様において提供される技術的解決策によれば、可能な設計では、第1の保護プロトコルは暗号化プロトコル又は完全性保護プロトコルである。
【００３２】
第1の態様から第8の態様において提供される技術的解決策によれば、可能な設計では、第1の保護プロトコルは、認証ヘッダ(authentication  header,  AH)プロトコル、ESPプロトコル、MACsecプロトコル、トランスポート層セキュリティ(transport  layer  security,  TLS)プロトコル又はセキュアソケット層(secure  sockets  layer,  SSL)プロトコルである。
【００３３】
第1の態様から第8の態様において提供される技術的解決策によれば、可能な設計では、第1のパケットヘッダはマルチプロトコルラベルスイッチング(multiprotocol  label  switching,  MPLS)headerであり、指示フィールドは第1のパケットヘッダ内のMPLS  labelフィールドである。
【００３４】
第1の態様から第8の態様において提供される技術的解決策によれば、可能な設計では、第1のパケットヘッダはEthernet  headerであり、指示フィールドは第1のパケットヘッダ内のEthernet  typeフィールドである。
【００３５】
第1の態様から第8の態様において提供される技術的解決策によれば、可能な設計では、第1のパケットヘッダはIP  headerであり、指示フィールドは第1のパケットヘッダ内のprotocolフィールドである。
【００３６】
第1の態様から第8の態様において提供される技術的解決策によれば、可能な設計では、第1のパケットヘッダは伝送制御プロトコル(transmission  control  protocol  TCP)headerであり、指示フィールドは予備(reserved)フィールド又はオプション(option)フィールドである。
【００３７】
第1の態様から第8の態様において提供される技術的解決策によれば、可能な設計では、第1のパケットヘッダはハイパーテキスト転送プロトコル(hypertext  transfer  protocol,  HTTP)ヘッダであり、タイプフィールドは拡張フィールドである。
【図面の簡単な説明】
【００３８】
この出願の実施形態における技術的解決策をより明確に説明するために、以下に、実施形態を説明するための添付の図面について簡単に説明する。明らかに、以下の説明における添付の図面は、この出願の単なるいくつかの実施形態にすぎない。
【図１】この出願によるネットワーク構造図である。
【図２】この出願によるルータの概略構造図である。
【図３】この出願によるIPパケットの概略構造図である。
【図４】この出願によるIPパケットの概略構造図である。
【図５】この出願によるパケットヘッダの概略構造図である。
【図６】この出願によるIPパケットの概略構造図である。
【図７】この出願によるMPLSパケットの概略構造図である。
【図８】この出願によるMPLSヘッダの概略構造図である。
【図９】この出願によるIPパケットの概略構造図である。
【図１０】この出願による元のレイヤ2フレーム及びVXLANパケットの概略構造図である。
【図１１】この出願によるVXLAN  GPEの概略構造図である。
【図１２】この出願による方法の概略フローチャートである。
【図１３】この出願による方法の概略フローチャートである。
【図１４】この出願によるネットワークデバイスの概略構造図である。
【図１５】この出願によるネットワークデバイスの概略構造図である。
【発明を実施するための形態】
【００３９】
データ通信分野において、パケットは、複数の転送装置により転送された後にのみ、宛先に到達してもよい。転送装置はルータでもよく、ルータはインターネットプロトコル(internet  protocol,  IP)パケットを転送してもよい。転送装置はネットワークスイッチでもよく、ネットワークスイッチはイーサネットフレームを転送してもよい。図１は、この出願によるネットワーク構造図である。図１を参照すると、ネットワーク構造図は、ルータ1からルータ7と、複数のイーサネット仮想プライベートネットワーク(Ethernet  virtual  private  network,  EVPN)サイト(site)とを含む。複数のEVPNサイトは、site1及びsite2を含む。site1及びsite2は、同じEVPNインスタンス(例えばEVPN1)に属する。各siteは、カスタマエッジ(customer  edge,  CE)デバイスとホストとを含んでもよい。ホストはユーザ機器(user  equipment,  UE)でもよい。各ルータは、複数の物理インタフェースカードを含んでもよい。各物理インタフェースカードは複数のポートを含んでもよい。図１は、ルータ1内の2つの出口ポート(第1の出口ポート及び第2の出口ポート)と、ルータ2内の2つの出口ポート(第3の出口ポート及び第4の出口ポート)とを示す。ルータ1は、第1の出口ポートを通じてルータ2に接続され、ルータ1は、第2の出口ポートを通じてルータ3に接続される。ルータ2は、第3の出口ポートを通じてルータ4に接続され、ルータ2は、第4の出口ポートを通じてルータ5に接続される。
【００４０】
ルータ1がパケットを受信した後に、ルータ1は、パケットを転送するために使用される出口ポート、例えば、第1の出口ポートを決定し、第1の出口ポートからパケットを転送する。ルータ2がルータ1により転送されたパケットを受信した後に、ルータ2は、パケットを転送するために使用される出口ポート、例えば、第3の出口ポートを決定し、第3の出口ポートからパケットを転送する。
【００４１】
図１において、ルータ2はPEでもよく、ルータ4はPEでもよい。ルータ2はCE1に接続されてもよく、site1内のホスト(例えば、UE1)は、CE1を通じてsite1の外側のホスト(例えば、UE2)と通信してもよい。ルータ4はCE2に接続されてもよく、site2内のホスト(例えば、UE2)は、CE2を通じてsite2の外側のホスト(例えば、UE1)と通信してもよい。
【００４２】
図２は、図１におけるルータ2の可能な概略構造図である。図２に示す概略構造図はまた、図１における他のルータ(例えば、ルータ4、CE1及びCE2)に使用されてもよい。
【００４３】
図２を参照すると、ルータ2は、制御ボード1210と、スイッチングボード1220と、インタフェースボード1230と、インタフェースボードと1240を含む。制御ボード1210は、中央処理装置1211を含む。制御ボード1210は、ルーティングプロトコルを実行するように構成されてもよい。ルーティングプロトコルは、ボーダーゲートウェイプロトコル(border  gateway  protocol,  BGP)又はインテリアゲートウェイプロトコル(interior  gateway  protocol,  IGP)でもよい。制御ボード1210は、ルーティングプロトコルを実行することによりルーティングテーブルを生成し、ルーティングテーブルをインタフェースボード1230及びインタフェースボード1240に送信してもよい。図１におけるルータ2は、代替として図２に示す構造とは異なる構造を使用してもよい点に留意すべきである。例えば、図１におけるルータ2は、1つの制御ボードと1つのインタフェースボードのみを含んでもよく、スイッチングボードを含まない。明らかに、図１におけるルータ2は少なくとも2つのインタフェースボードを含んでもよい。ルータ2が1つのインタフェースボードのみを含み、スイッチングボードを含まないとき、インタフェースボードの入口ポートを通じて受信されたIPパケットは、インタフェースボードにより処理された後に、インタフェースボードの出口ポートから送信されてもよい。ルータ2が複数のインタフェースボードを含み、スイッチングボードを含むとき、ルータ2の1つのインタフェースボードの入口ポートを通じて受信されたIPパケットは、スイッチングボードにより処理された後に、ルータ2の他のインタフェースボードの出口ポートから送信されてもよい。図１におけるルータ2及び他のルータの具体的な構造は、この出願では限定されない。
【００４４】
インタフェースボード1230は、ルーティングテーブルを検索することによりIPパケットを転送してもよい。具体的には、インタフェースボード1230は、中央処理装置1231と、ネットワークプロセッサ1232と、物理インタフェースカード1233と、メモリ1234とを含む。図２は、インタフェースボード1230に含まれることができる全ての構成要素を示していない点に留意すべきである。具体的な実現方式の中で、インタフェースボード1230は、他の構成要素を更に含んでもよい。例えば、インタフェースボード1230はトラフィックマネージャを更に含んでもよく、それにより、インタフェースボード1230は、待ち行列スケジューリング及び管理機能を有する。さらに、インタフェースボード1230は入口ファブリックインタフェースチップ(ingress  fabric  interface  chip,  iFIC)を更に含んでもよく、それにより、インタフェースボード1230からのパケットは、スイッチングボード1220を通じてインタフェースボード1240に切り替えられることができる。中央処理装置1231は、中央処理装置1211により送信されたルーティングテーブルを受信し、ルーティングテーブルをメモリ1234に記憶してもよい。物理インタフェースカード1233は、ルータ1により送信されたIPパケットを受信するように構成されてもよい。ネットワークプロセッサ1232は、物理インタフェースカード1233により受信されたIPパケットに一致するルーティングエントリを求めてメモリ1234内のルーティングテーブルを検索し、一致したルーティングエントリに基づいてIPパケットをスイッチングボード1220に送信してもよい。スイッチングボード1220は、インタフェースボードから他のインタフェースボードにIPパケットを切り替えるように構成されてもよい。例えば、スイッチングボード1220は、インタフェースボード1230からインタフェースボード1240にIPパケットを切り替えてもよい。具体的には、スイッチングボード1220は、セル切り替えを通じてインタフェースボード1230からインタフェースボード1240にIPパケットを切り替えてもよい。例えば、ネットワークプロセッサ1232は、IPパケット内の宛先IPアドレスを取得してもよい。ネットワークプロセッサ1232は、最長プレフィックスマッチングアルゴリズム(longest  prefix  matching  algorithm)に従って、IPパケットに一致するルーティングエントリを求めてルーティングテーブルを検索し、IPパケットに一致するルーティングエントリに基づいて出口ポートを決定してもよい。IPパケットに一致するルーティングエントリは、出口ポートの識別子を含む。ネットワークプロセッサ1232によりスイッチングボード1220に送信されたIPパケットがスイッチングボード1220に到達する前に、インタフェースボード1230は、IPパケットに対して待ち行列スケジューリング及び管理を実行してもよい。
【００４５】
インタフェースボード1240は、ルーティングテーブルを検索することによりIPパケットを転送してもよい。インタフェースボード1240は、中央処理装置1241と、ネットワークプロセッサ1242と、物理インタフェースカード1243と、メモリ1244とを含む。図２は、インタフェースボード1240に含まれることができる全ての構成要素を示していない。具体的なの実現方式の中で、インタフェースボード1240は、他の構成要素を更に含んでもよい。例えば、インタフェースボード1240はトラフィックマネージャを更に含んでもよく、それにより、インタフェースボード1240は、待ち行列スケジューリング及び管理機能を有する。さらに、インタフェースボード1240は、出口ファブリックインタフェースチップ(egress  fabric  interface  chip,  eFIC)を更に含んでもよく、それにより、インタフェースボード1240は、スイッチングボード1220を通じてインタフェースボード1230からパケットを正しく受信できる。中央処理装置1241は、中央処理装置1211により送信されたルーティングテーブルを受信し、ルーティングテーブルをメモリ1244に記憶してもよい。ネットワークプロセッサ1242は、スイッチングボード1220からIPパケットを受信するように構成されてもよい。スイッチングボード1220からのIPパケットは、ルータ1により送信されて物理インタフェースカード1233により受信されたIPパケットでもよい。ネットワークプロセッサ1242は、スイッチングボード1220からのIPパケットに一致するルーティングエントリを求めてメモリ1244内のルーティングテーブルを検索し、一致したルーティングエントリに基づいてIPパケットを物理インタフェースカード1243に送信してもよい。物理インタフェースカード1243は、IPパケットをルータ4に送信するように構成されてもよい。ネットワークプロセッサ1242により物理インタフェースカード1243に送信されたIPパケットが物理インタフェースカード1243に到達する前に、インタフェースボード1240は、IPパケットに対して待ち行列スケジューリング及び管理を実行してもよい。
【００４６】
図１に示すネットワークにおけるデバイスが互いに通信するとき、送信対象データは保護される必要があってもよく、例えば、送信対象データは暗号化される必要があるか、或いは、送信対象データに対して完全性保護が実行される必要がある。送信対象データが暗号化されているとき、完全性保護が送信対象データに対して実行されてもよく或いは実行されなくてもよく、或いは、完全性保護が送信対象データに対して実行されているとき、送信対象データが暗号化されもよく或いは暗号化されなくてもよいことが理解できる。可能な設計では、送信デバイスがデータを受信デバイスに送信する前に、送信デバイスは、保護データを生成するために、特定の保護プロトコルに従って送信対象データを保護してもよい。送信対象データは保護される必要があるが保護されていないので、送信対象データは保護対象データと呼ばれてもよい。送信デバイスは保護データを受信デバイスに送信する。保護データを受信した後に、受信デバイスは、送信対象データを取得するために、保護プロトコルに従って保護データを処理する。例えば、送信デバイスは、暗号化データを生成するために、暗号化プロトコルに従って、送信対象データを暗号化してもよい。送信対象データは暗号化される必要があるが暗号化されていないので、送信対象データは暗号化対象データと呼ばれてもよい。暗号化データを受信した後に、受信デバイスは、データを取得するために、暗号化プロトコルに従って暗号化データを解読する。他の例では、送信デバイスは、完全性保護データを生成するために、完全性保護プロトコルに従って送信対象データに対して完全性保護を実行してもよい。送信対象データは完全性保護されている必要があるが完全性保護されていないので、送信対象データは完全性保護対象データと呼ばれてもよい。完全性保護データを受信した後に、受信デバイスは、データの完全性が損なわれていないことを決定するために、完全性保護プロトコルに従って完全性保護データを検査する。図１に示すネットワークにおけるいずれか2つのデバイスの間で送信されるデータは、保護される必要があってもよい。ルータ2とルータ4との間で送信されるデータを保護するプロセスについて、例を使用することにより以下に説明する。
【００４７】
可能な設計では、ルータ2とルータ4との双方がIPsecプロトコルをサポートする。例えば、メモリ1234は、IPsecプロトコルを実行するために使用されるコンピュータプログラムを記憶し、ネットワークプロセッサ1232は、IPsecプロトコルを実行するためにコンピュータプログラムを実行する。IPsecプロトコルは、カプセル化セキュリティペイロード(encapsulating  security  payload,  ESP)プロトコルを含んでもよい。ルータ2はCE1を通じてホスト1(例えば、UE1)に接続され、ルータ4はCE2を通じてホスト2(例えば、UE2)に接続される。ホスト1によりホスト2に送信されたパケットは、ルータ2及びルータ4を通じて転送される。ルータ2は、ESPプロトコルを使用することにより受信パケット1を暗号化する。パケット1はIPパケットでもよく、パケット1はホスト1からのものでもよい。ホスト1は、スイッチ(図１に図示せず)を通じてルータ2に接続されてもよい。ホスト1は、パーソナルコンピュータでもよく、或いは、サーバ(図１に図示せず)において実行する仮想マシンでもよい。サーバは、スイッチを通じてルータ2に接続されてもよい。ホスト2は、スイッチ(図１に図示せず)を通じてルータ4に接続されてもよい。ホスト2は、パーソナルコンピュータでもよく、或いは、サーバ(図１に図示せず)において実行する仮想マシンでもよい。サーバは、スイッチを通じてルータ4に接続されてもよい。
【００４８】
図３は、パケット1の可能な概略構造図である。図３を参照すると、パケット1は、IPヘッダと、TCPヘッダと、データとを含む。例えば、IPヘッダはIPv4ヘッダでもよい。IPヘッダ内の送信元IPアドレスはホスト1のIPアドレスでもよく、IPヘッダ内の宛先アドレスはホスト2のIPアドレスでもよい。TCPヘッダは送信元ポートと宛先ポートとを含む。送信元ポートはホスト1により割り当てられたポートでもよく、宛先ポートはホスト2により割り当てられたポートでもよい。パケット1内のIPヘッダに続く内容は、TCPヘッダとデータとを含み、パケット1内のIPヘッダに続く内容は、暗号化対象データである。IPヘッダはプロトコルフィールドを含む。プロトコルフィールドの値は0x06である。プロトコルフィールドは、パケット1内のIPヘッダに続くパケットヘッダのプロトコルがTCPであることを示すために使用される。可能な実現方式では、パケット1はTCPヘッダを含まなくてもよく、パケット1内のプロトコルフィールドの値は0xFFでもよい。
【００４９】
ルータ2がパケット1を受信した後に、ネットワークプロセッサ1232は、メモリ1234内のコンピュータプログラムを実行することにより、パケット1を処理してもよい。具体的には、ネットワークプロセッサ1232は、パケット2を生成するために、拡張パケットヘッダ、ESPヘッダ、ESPトレーラ(trailer)及びESP完全性チェック値(integrity  check  value,  ICV)をパケット1に追加してもよい。例えば、ネットワークインタフェースカード1333がパケット1を受信した後に、ネットワークプロセッサ1232は、パケット1のバージョン(version)フィールドを取得するために、パケット1を解析してもよい。バージョンフィールドはパケット1の最初の4ビットである。ネットワークプロセッサ1232は、バージョンフィールドの値に基づいて、パケット1がIPv4パケットであることを決定してもよい。図４は、パケット2の可能な概略構造図である。図４を参照すると、拡張パケットヘッダは、IPヘッダの後に位置し、ESPヘッダは、TCPヘッダの前に位置する。ESPヘッダは、セキュリティパラメータインデックス(security  parameters  index,  SPI)と、シーケンス番号(sequence  number)と、ペイロードデータ(payload  data)とを含む。ESPトレーラは、パディング(padding)と、パッド長(pad  length)と、次ヘッダフィールド(next  header  field)とを含む。ペイロードデータは、暗号化アルゴリズム(encryption  algorithm)を使用することにより暗号化対象データを処理することにより取得される。ペイロードデータは、下部構造(substructure)を有してもよい。ルータ2がパケット1に基づいてパケット2を生成するプロセスにおいて、ルータ2は、暗号化データを取得するために、特定の暗号化プロトコル(例えば、ESPプロトコル)を使用することによりパケット1内の暗号化対象データ(図３におけるTCPヘッダ及びデータを参照する)を暗号化してもよい。図４を参照すると、暗号化データは、TCPヘッダとデータとを含んでもよい。さらに、暗号化データは、ESPトレーラを更に含んでもよい。図４に示すパケット2内のフィールドの意味及び具体的な実現方式については、インターネットエンジニアリングタスクフォース(internet  engineering  task  force,  IETF)により公表されたリクエストフォーコメント(request  for  comments,  RFC)4303における記述を参照し、詳細はここでは再び説明しない。
【００５０】
ルータ2がパケット1に基づいてパケット2を生成するプロセスにおいて、ネットワークプロセッサ1232は、パケット1内のIPヘッダ内のプロトコルフィールドの値を、実験及び試験(Use  for  experimentation  and  testing)のために使用される未割り当て又は使用として設定してもよい。当業者は、プロトコルフィールドのいくつかの値が割り当てられていることを理解し得る。例えば、0x06が割り当てられており、0x06は、伝送制御プロトコル(transmission  control  protocol,  TCP)を示すために具体的に使用される。他の例では、0x02が割り当てられており、0x02は、インターネットグループ管理プロトコル(internet  group  management  protocol,  IGMP)を示すために具体的に使用される。0x8Fから0xFCは割り当てられておらず、0xFD及び0xFEは実験及び試験のための使用である。可能な設計では、ルータ2は、パケット1内のIPヘッダ内のプロトコルフィールドの値を0x8F又は0xFDに設定してもよい。プロトコルフィールドの値が0x8F又は0xFDであるとき、これは、パケット2が拡張パケットヘッダを含むことを示す。
【００５１】
ルータ2は、図５に示す拡張パケットヘッダを生成するために使用されるコンピュータプログラムを記憶する。ルータ2内のプロセッサは、コンピュータプログラムに基づいて、図５に示す拡張パケットヘッダを生成してもよい。具体的には、ルータ2がパケット1を受信した後に、パケット1の内容がESPプロトコルを使用することにより保護される必要があることをルータ2が決定したとき、ルータ2内のプロセッサは、コンピュータプログラムに基づいて、図５に示す拡張パケットヘッダが生成される必要があることを決定してもよい。
【００５２】
ルータ4は、図５に示す拡張パケットヘッダを解析するために使用されるコンピュータプログラムを記憶する。ルータ4内のプロセッサは、コンピュータプログラムに基づいて、パケット2に含まれる図５に示す拡張パケットヘッダを解析してもよい。具体的には、ルータ4がパケット2を受信した後に、ルータ4は、IPヘッダからプロトコルフィールドを取得し、プロトコルフィールドの値に基づいて、パケット2が拡張パケットヘッダを含むことを決定してもよい。さらに、ルータ2内のプロセッサは、コンピュータプログラムに基づいて、パケット2から拡張パケットヘッダを取得し、図５に示す拡張パケットヘッダ内のフィールドを取得するために、図５に示す構造に基づいて拡張パケットヘッダを解析してもよい。
【００５３】
拡張パケットヘッダはタイプフィールドを含む。可能な設計では、拡張パケットヘッダは、フラグフィールドと、オフセットフィールドと、長さフィールドとを更に含む。図５は、拡張パケットヘッダの可能な概略構造図である。タイプフィールドは保護プロトコルを示すために使用される。この実施形態では、保護プロトコルは具体的には暗号化プロトコルであり、暗号化プロトコルは具体的にはESPプロトコルである。したがって、タイプフィールドはESPプロトコルを示すために使用されてもよい。図５に示す構造に関与する保護プロトコルはESPプロトコルである。代替として、他の保護プロトコル、例えば、MACsecプロトコル又はIP認証ヘッダ(authentication  header,  AH)プロトコルが、パケット2に使用されてもよい。言い換えると、ルータ2がパケット1を受信した後に、ルータ2は、ESPプロトコル又は媒体アクセス制御セキュリティ(media  access  control  security,  MACsec)プロトコルを使用することにより、パケット1の内容を保護してもよい。AHプロトコルについては、RFC4302を参照する。MACsecについては、米国電気電子技術者協会(institute  of  electrical  and  electronics  engineers,  IEEE)により公表されたIEEE802.1AEを参照する。
【００５４】
可能な設計では、タイプフィールドは8ビットを含む。言い換えると、タイプフィールドの長さは8ビットでもよい。上記のシナリオでは、拡張パケットヘッダ内のタイプフィールドは、256個の保護プロトコルを示してもよい。例えば、タイプフィールドの値が0x00であるとき、タイプフィールドはESPプロトコルを示すために使用され、或いは、タイプフィールドの値が0x01であるとき、タイプフィールドはMACsecプロトコルを示すために使用され、或いは、タイプフィールドの値が0x02であるとき、タイプフィールドはAHプロトコルを示すために使用される。
【００５５】
上記の技術的解決策から、拡張パケットヘッダはこの出願で定義された新たなパケットヘッダであり、拡張パケットヘッダ内のタイプフィールドはこの出願で定義された新たなフィールドであることが習得できる。したがって、タイプフィールドの値は割り当てられていない。この出願における保護プロトコル(例えば、暗号化プロトコル)を示すために使用できるタイプフィールドの値の数は、他の技術的解決策における保護プロトコル(例えば、暗号化プロトコル)を示すために使用できるタイプフィールドの値の数よりも大きくてもよい。例えば、IPヘッダ内のプロトコルフィールドのいくつかの値が割り当てられており、したがって、保護プロトコルを示すために使用できる比較的少数のプロトコルフィールドの値が存在してもよい。
【００５６】
図５を参照すると、拡張パケットヘッダは、オフセットフィールドを更に含んでもよい。オフセットフィールドは暗号化データの位置を示すために使用される。図４に示すパケット2では、暗号化データは拡張パケットヘッダに隣接していない。具体的には、暗号化データはESPヘッダに隣接し、暗号化データはESPヘッダの後ろに位置する。具体的には、オフセットフィールドは、暗号化データの開始位置を示すために使用される。可能な実現方式では、拡張パケットヘッダの後の連続した最初のビットを参照として使用することにより、暗号化データの開始位置は、オフセットフィールドの値を設定することにより示されてもよい。例えば、ESPヘッダの長さが100ビットであると仮定すると、オフセットフィールドの値は100ビットでもよい。可能な実現方式では、拡張パケットヘッダ内の連続した最初のビットを参照として使用することにより、暗号化データの開始位置は、オフセットフィールドの値を設定することにより示されてもよい。例えば、拡張パケットヘッダの長さが50ビットであり、ESPヘッダの長さが100ビットであると仮定すると、オフセットフィールドの値は150でもよい。可能な実現方式では、ESPヘッダの後の連続した最初のビットを参照として使用することにより、暗号化データの開始位置は、オフセットフィールドの値を設定することにより示されてもよい。図４によれば、ESPヘッダの後の連続した最初のビットはTCPヘッダ内の第1ビットであり、TCPヘッダの第1ビットは暗号化データの開始位置である。したがって、オフセットフィールドの値は0でもよい。
【００５７】
図４に示すパケット2では、暗号化データはTCPヘッダを含む。可能な実現方式では、暗号化データは、図４に示すデータ及びESPトレーラを含むが、TCPヘッダを含まない。TCPヘッダは平文であり、データは暗号文である。上記のシナリオでは、暗号化データの開始位置は、オフセットフィールドを使用することにより決定されてもよい。例えば、ESPヘッダの後の連続した最初のビットを参照として使用することにより、暗号化データの開始位置は、オフセットフィールドの値を設定することにより示されてもよい。TCPヘッダの長さが160ビットであるとき、オフセットフィールドの値は160でもよい。パケット2を受信した受信デバイス(例えば、図１におけるルータ4)は、オフセットフィールドの値に基づいて、暗号化データの開始位置が図４に示すデータの第1ビットであることを決定してもよい。さらに、ルータ4は、図４から暗号化データを取得し、暗号化プロトコルに対応する解読アルゴリズムに従って元のデータを取得してもよい。元のデータは、図３に示すデータを含む。元のデータは暗号化プロトコルを使用して暗号化されておらず、元のデータは暗号化プロトコルに従って暗号化が実行される前に存在するデータであることが理解できる。
【００５８】
上記の技術的解決策では、オフセットフィールドは、保護データ(例えば、暗号化データ)の位置を示すために使用される。暗号化プロトコルがESPプロトコルであるとき、暗号化データは拡張パケットヘッダに隣接しない。この場合、オフセットフィールドが存在しない場合、パケット2の受信機(例えば、ルータ4)が、パケット2内の暗号化データの位置を決定することは非常に困難である可能性がある。可能な実現方式では、ルータ2が他の暗号化プロトコルを使用することによりパケット1を暗号化するとき、暗号化データは拡張プロトコルヘッダに隣接しもよく、拡張プロトコルヘッダの後に位置してもよい。この場合、パケット2はオフセットフィールドを含まなくてもよい。ルータ2は、デフォルト位置(例えば、拡張パケットヘッダの後の連続した最初のビット)に基づいて、パケット2から保護データ(例えば、暗号化データ)を取得してもよい。
【００５９】
図５を参照すると、拡張パケットヘッダは、長さフィールドを更に含む。長さフィールドは拡張パケットヘッダの長さを示す。例えば、拡張パケットヘッダの長さは50ビットでもよく、長さフィールドの値は50でもよい。
【００６０】
図５を参照すると、拡張パケットヘッダはフラグフィールドを更に含む。フラグフィールドは、拡張パケットヘッダがオフセットフィールドを含むことを示す。例えば、フラグフィールドは1ビットを含む。フラグフィールドの値が1であるとき、これは、拡張パケットヘッダがオフセットフィールドを含むことを示し、或いは、フラグフィールドの値が0であるとき、これは、拡張パケットヘッダがオフセットフィールドを含まないことを示す。パケット2の受信機(例えば、ルータ4)がパケット2を受信したとき、受信機は、フラグフィールドの値に基づいて、パケット2がオフセットフィールドを含むか否かを決定してもよい。パケット2がオフセットフィールドを含むことを決定したとき、暗号化データの位置は、オフセットフィールドの値に基づいて決定されてもよい。さらに、ルータ4は、パケット2から暗号化データを取得し、暗号化プロトコル(例えば、ESPプロトコル)に従って暗号化データを処理してもよい。具体的には、ルータ4は、暗号化対象データを取得するために、ESPプロトコル及びパケット2内のESPヘッダに従って、暗号化データを解読してもよい。具体的には、ルータ4は、図４におけるパケット2に基づいて、図３におけるTCPヘッダ及びデータを取得してもよく、ルータ4はパケット1をホスト2に送信する。例えば、ルータ4は、パケット1内の宛先IPアドレスに基づいて、宛先IPアドレスに一致するエントリを求めてルータ4内のルーティングテーブルを検索する。エントリは出口ポートの識別子を含む。ルータ4は、出口ポートを通じてパケット1をホストに送信する。
【００６１】
図１２は、実施形態によるパケット送信方法1200の概略フローチャートである。図１２を参照すると、方法1200はS1202及びS1204を含む。
【００６２】
S1202:ネットワークデバイスは第1のパケットを生成する。
【００６３】
第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含む。第1のパケットヘッダは指示フィールドを含む。指示フィールドは、第1のパケットが第2のパケットヘッダを含むことを示すために使用される。第2のパケットヘッダはタイプフィールドを含む。タイプフィールドは、第1の保護プロトコルを示すために使用される。保護データは、第1の保護プロトコルを使用することにより保護されたデータである。
【００６４】
S1204:ネットワークデバイスは第1のパケットを送信する。
【００６５】
図１２に示す方法は、図１に示すネットワーク構造に適用されてもよい。具体的には、site1内のUE1はsite2内のUE2と通信する必要がある。UE1により送信されたパケットは、ルータ2及びルータ4を通じてUE2に到達する必要がある。ネットワークにおいて、UE1により送信された元のパケットをUE2に送信するプロセスにおいて、ルータ2は、図１２において提供される方法を使用することにより元のパケットを保護してもよい。例えば、ルータ2は、暗号化パケットを取得するために、図１２において提供される方法を使用することにより元のパケットを暗号化してもよく、暗号化パケットを受信した後に、ルータ4は、元のパケットを取得するために、暗号化パケットを解読してもよく、ルータ4は、元のパケットをUE2に更に送信する。他の例では、ルータ2は、完全性保護パケットを取得するために、図１２において提供される方法を使用することにより元のパケットに対して完全性保護を実行してもよく、完全性保護パケットを受信した後に、ルータ4は、元のパケットを取得するために、完全性保護パケットの完全性を検査してもよく、ルータ4は、元のパケットをUE2に更に送信する。
【００６６】
例えば、方法1200におけるネットワークデバイスは図１におけるルータ2でもよい。ルータ2は第1のパケットをルータ4に送信してもよい。第1のパケットは図４に示すパケット2でもよい。第1のパケットヘッダは図４に示すIPヘッダでもよい。第2のパケットヘッダは拡張パケットヘッダでもよい。保護データは、図４に示すTCPヘッダ及びデータを含んでもよい。さらに、保護データは、図４におけるESPトレーラを更に含んでもよい。第1の保護プロトコルは暗号化プロトコルでもよく、暗号化プロトコルはESPプロトコルでもよい。タイプフィールドは、図４に示すIPヘッダ内のprotocolフィールドでもよい。図４におけるTCPヘッダは、図３におけるTCPヘッダが第1の保護プロトコル(例えば、ESPプロトコル)を使用することにより保護された後に取得されることが理解できる。図４におけるTCPヘッダは、図３におけるTCPヘッダがESPプロトコルを使用することにより暗号化された後に取得されるので、図３におけるTCPヘッダの値は、図４におけるTCPヘッダの値と等しくなくてもよい。同じ原理に従って、図３におけるデータの値は、図４におけるデータの値と等しくなくてもよい。
【００６７】
可能な設計では、第1の保護プロトコルは完全性保護プロトコルである。例えば、第1の保護プロトコルはAHプロトコルでもよい。図６を参照して、第1の保護プロトコルがAHプロトコルであるシナリオについて、例を使用することにより以下に説明する。ネットワークデバイスは図１におけるルータ2でもよい。第1のパケットは図６における新たなIPパケットでもよい。具体的には、図６における元のIPパケットを受信した後に、ルータ2は、元のIPパケットに基づいて新たなIPパケットを生成してもよい。第1のパケットヘッダはIPヘッダでもよく、第2のパケットヘッダは拡張ヘッダでもよく、保護データはIPデータでもよく、指示フィールドはIPヘッダ内のprotocolフィールドでもよい。例えば、protocolフィールドの値は0xFCでもよい。protocolフィールドは、新たなIPパケットが拡張ヘッダを含むことを示すために使用される。拡張ヘッダはタイプフィールドを含み、タイプフィールドはAHプロトコルを示すために使用される。新たなIPパケット内のIPデータは、元のIPパケット内のIPデータが第1の保護プロトコル(例えば、AHプロトコル)を使用することにより保護された後に取得されることが理解できる。具体的には、元のIPパケット内のIPデータは、新たなIPパケット内のIPデータを取得するために、AHプロトコルの完全性アルゴリズムに従って処理される。したがって、元のIPパケット内のIPデータの値は、新たなIPパケット内のIPデータの値に等しい。AHプロトコルについては、RFC4302を参照する。新たなIPパケットが受信デバイス(例えば、図１におけるルータ4)により受信された後に、受信デバイスは、protocolフィールドに基づいて、新たなIPパケットが拡張ヘッダを含むことを決定してもよい。さらに、受信デバイスは、拡張ヘッダ内のタイプフィールドに基づいてAHプロトコルを決定してもよい。受信デバイスは、IPデータの完全性が損なわれているか否かを決定するために、AHプロトコルの完全性アルゴリズムに従って、IPデータの完全性を検査してもよい。IPデータの完全性が損なわれていない場合、受信デバイス(例えば、図１におけるルータ4)は、新たなIPパケットに基づいて元のIPパケットを生成し、元のIPパケットをホスト2(例えば、UE2)に送信してもよい。
【００６８】
可能な設計では、図１におけるルータ2とルータ4との双方がMPLSプロトコルをサポートする。ネットワークデバイスは図１におけるルータ2でもよい。第1のパケットは図７における新たなMPLSパケットでもよい。具体的には、ホスト1(例えば、UE1)により送信された元のIPパケットを受信した後に、ルータ2は、図７に示す元のMPLSパケットを生成するために、元のIPパケットをカプセル化してもよい。元のMPLSパケット内のMPLSペイロードは元のIPパケットを含む。さらに、ルータ2は、元のMPLSパケットに基づいて新たなMPLSパケットを生成してもよい。図７を参照すると、元のMPLSパケットは、MPLSヘッダ1とMPLSペイロードとを含む。元のMPLSパケットと比較して、新たなMPLSパケットは、MPLSヘッダ2と、MPLSヘッダ3と、拡張ヘッダと更にを含む。元のMPLSパケット内のMPLSヘッダ1の構造と、新たなMPLSパケット内のMPLSヘッダ1、MPLSヘッダ2及びMPLSヘッダ3の構造とについては、図８を参照する。元のMPLSパケット内のMPLSヘッダ1のSフィールドの値は1であり、新たなMPLSパケット内のMPLSヘッダ1のSフィールドの値は0である点に留意すべきである。さらに、MPLSヘッダ2において、Sフィールドの値は0であり、labelフィールドの値は15であり、MPLSヘッダ3において、Sフィールドの値は0であり、labelフィールドの値は252である。第1のパケットヘッダはMPLSヘッダ1でもよく、第2のパケットヘッダは拡張ヘッダでもよく、保護データはMPLSペイロードでもよい。指示フィールドはMPLSヘッダ3内のlabelフィールドでもよい。例えば、MPLSヘッダ3内のlabelフィールドの値は252でもよい。MPLSヘッダ3内のlabelフィールドは、新たなMPLSパケットが拡張ヘッダを含むことを示すために使用される。拡張ヘッダはタイプフィールドを含み、タイプフィールドは保護プロトコルを示すために使用される。保護プロトコルはMPLSペイロードを保護するために使用される。保護プロトコルは、暗号化プロトコル又は完全性保護プロトコルでもよい。可能な設計では、保護プロトコルはESPプロトコルでもよい。保護プロトコルがESPプロトコルであるとき、新たなMPLSパケットはESPヘッダを更に含み、ESPヘッダは拡張ヘッダとMPLSペイロードとの間に位置する。保護プロトコルがESPプロトコルである具体的な実現方式については、図４に対応する実施形態を参照する。可能な設計では、保護プロトコルはAHプロトコルでもよい。保護プロトコルがAHプロトコルであるとき、新たなMPLSパケットはAHヘッダを更に含み、AHヘッダは拡張ヘッダとMPLSペイロードとの間に位置する。保護プロトコルがAHプロトコルである具体的な実現方式については、図６に対応する実施形態を参照する。
【００６９】
可能な設計では、第1の保護プロトコルは暗号化プロトコルでもよい。例えば、第1の保護プロトコルはMACsecプロトコルでもよい。図９を参照して、第1の保護プロトコルがMACsecプロトコルであるシナリオについて、例を使用することにより以下に説明する。ネットワークデバイスは、図１におけるルータ2でもよい。第1のパケットは、図９における新たなIPパケットでもよい。具体的には、図９における元のIPパケットを受信した後に、ルータ2は、元のIPパケットに基づいて新たなIPパケットを生成してもよい。元のIPパケットは、IPヘッダとIPペイロードとを含む。IPペイロードはイーサネットフレームを含み、イーサネットフレームはイーサネットフレームヘッダとイーサネットフレームペイロードとを含む。イーサネットフレームヘッダは、宛先MACアドレス(DMAC)と、送信元MACアドレス(SMAC)と、イーサネットタイプ(ETYPE)とを含む。第1のパケットヘッダはIPヘッダでもよい。第2のパケットヘッダは拡張ヘッダでもよい。保護データはイーサネットフレームペイロードを含んでもよい。さらに、保護データはETYPEを更に含む。指示フィールドはIPヘッダ内のprotocolフィールドでもよい。例えば、protocolフィールドの値は0xFCでもよい。protocolフィールドは、新たなIPパケットが拡張ヘッダを含むことを示すために使用される。拡張ヘッダはタイプフィールドを含み、タイプフィールドはMACsecプロトコルを示すために使用される。新たなIPパケット内のイーサネットフレームペイロードは、元のIPパケット内のイーサネットフレームペイロードが第1の保護プロトコル(例えば、MACsecプロトコル)を使用することにより保護された後に取得されることが理解できる。具体的には、元のIPパケット内のイーサネットフレームペイロードは、新たなIPパケット内のイーサネットフレームペイロードを取得するために、MACsecプロトコルの暗号化アルゴリズムに従って処理される。したがって、元のIPパケット内のイーサネットフレームペイロードの値は、新たなIPパケット内のイーサネットフレームペイロードの値と等しくない。MACsecプロトコルについては、IEEE802.1AEを参照する。新たなIPパケットが受信デバイス(例えば、図１におけるルータ4)により受信された後に、受信デバイスは、protocolフィールドに基づいて、新たなIPパケットが拡張ヘッダを含むことを決定してもよい。さらに、受信デバイスは、拡張ヘッダ内のタイプフィールドに基づいてMACsecプロトコルを決定してもよい。受信デバイスは、MACsecプロトコルの解読アルゴリズムに従って新たなIPパケットを解読してもよい。具体的には、受信デバイスは、元のIPパケットを取得するために、新たなIPパケット内のETYPE及びイーサネットフレームペイロードを解読する。受信デバイス(例えば、図１におけるルータ4)は、元のIPパケットをホスト2(例えば、UE2)に送信してもよい。
【００７０】
可能な設計では、第1の保護プロトコルは暗号化プロトコルでもよい。例えば、第1の保護プロトコルはMACsecプロトコルでもよい。図１０及び図１１を参照して、第1の保護プロトコルがMACsecプロトコルであるシナリオについて、例を使用することにより以下に説明する。ネットワークデバイスは図１におけるルータ2でもよい。第1のパケットは図９における新たなVXLANパケットでもよい。具体的には、図１０における元のレイヤ2フレーム(original  L2  frame)を受信した後に、ルータ2は、元のVXLANパケットを取得するために、元のレイヤ2フレームに対してVXLANカプセル化を実行してもよい。ルータ2は、新たなVXLANパケットを取得するために、MACsecプロトコルで指定された暗号化アルゴリズムに従って、元のVXLANパケットを暗号化してもよい。図１０におけるVXLANヘッダは、具体的にはVXLAN  GPEでもよい。図１０におけるVXLANヘッダの構造については、図１１におけるVXLAN  GPEを参照する。具体的には、VXLAN  GPEは、フラグフィールドと、予備1フィールドと、次プロトコルフィールドと、VNIフィールドと、予備2フィールドとを含む。フラグフィールドは1バイトであり、予備1フィールドは2バイトであり、次プロトコルフィールドは1バイトであり、VNIフィールドは3バイトであり、予備2フィールドは1バイトである。図１１におけるフィールドの値及び機能については、draft-quinn-vxlan-gpe-03を参照する。元のレイヤ2フレームは、イーサネットフレームヘッダとイーサネットフレームペイロードとを含む。イーサネットフレームヘッダは、宛先MACアドレス(DMAC)と、送信元MACアドレス(SMAC)と、イーサネットタイプ(ETYPE)とを含む。第1のパケットヘッダはVXLANヘッダでもよい。第2のパケットヘッダは拡張ヘッダでもよい。保護データはイーサネットフレームペイロードを含んでもよい。さらに、保護データはETYPEを更に含む。指示フィールドは、VXLANヘッダ内の次プロトコル(Next  Protocol)フィールドでもよく、次プロトコルフィールドは、新たなVXLANパケットが拡張ヘッダを含むことを示すために使用される。拡張ヘッダはタイプフィールドを含み、タイプフィールドはMACsecプロトコルを示すために使用される。新たなVXLANパケット内のイーサネットフレームペイロードは、元のレイヤ2フレーム内のイーサネットフレームペイロードが第1の保護プロトコル(例えば、MACsecプロトコル)を使用することにより保護された後に取得されることが理解できる。具体的には、元のレイヤ2フレーム内のイーサネットフレームペイロードは、新たなVXLANパケット内のイーサネットフレームペイロードを取得するために、MACsecプロトコルの暗号化アルゴリズムに従って処理される。したがって、元のレイヤ2フレーム内のイーサネットフレームペイロードの値は、新たなVXLANパケット内のイーサネットフレームペイロードの値と等しくない。新たなVXLANパケットが受信デバイス(例えば、図１におけるルータ4)により受信された後に、受信デバイスは、次プロトコルフィールドに基づいて、新たなVXLANパケットが拡張ヘッダを含むことを決定してもよい。さらに、受信デバイスは、拡張ヘッダ内のタイプフィールドに基づいてMACsecプロトコルを決定してもよい。受信デバイスは、MACsecプロトコルの解読アルゴリズムに従って新たなVXLANパケットを解読してもよい。具体的には、受信デバイスは、元のレイヤ2フレームを取得するために、新たなVXLANパケット内のETYPE及びイーサネットフレームペイロードを解読する。受信デバイス(例えば、図１におけるルータ4)は、元のレイヤ2フレームをホスト2(例えば、UE2)に送信してもよい。
【００７１】
可能な設計では、第2のパケットヘッダはオフセットフィールドを更に含み、オフセットフィールドは保護データの位置を示すために使用される。
【００７２】
図１３は、実施形態によるパケット受信方法1300の概略フローチャートである。図１３を参照すると、当該方法はS1302及びS1304を含む。
【００７３】
S1302:ネットワークデバイスは第1のパケットを受信する。
【００７４】
第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含む。第1のパケットヘッダは指示フィールドを含む。指示フィールドは、第1のパケットが第2のパケットヘッダを含むことを示すために使用される。第2のパケットヘッダはタイプフィールドを含む。タイプフィールドは、第1の保護プロトコルを示すために使用される。保護データは、第1の保護プロトコルを使用することにより保護されたデータである。
【００７５】
S1304:ネットワークデバイスは、第1の保護プロトコル及び保護データに従って、元のデータを取得する。
【００７６】
元のデータは、第1の保護プロトコルを使用することにより保護されていない。
【００７７】
図１３に示す方法は、図１に示すネットワーク構造に適用されてもよい。具体的には、site1内のUE1はsite2内のUE2と通信する必要がある。UE1により送信されたパケットは、ルータ2及びルータ4を通じてUE2に到達する必要がある。ネットワークにおいて、UE1により送信された元のパケットをUE2に送信するプロセスにおいて、ルータ2は、方法1200を使用することにより元のパケットを保護してもよい。例えば、ルータ2は、暗号化パケットを取得するために、方法1200を使用することにより元のパケットを暗号化してもよく、ルータ4は、方法1300を使用することにより元のパケットを取得してもよい。具体的には、暗号化パケットを受信した後に、ルータ4は、元のパケットを取得するために、暗号化パケットを解読してもよく、ルータ4は、元のパケットをUE2に更に送信する。他の例では、ルータ2は、完全性保護パケットを取得するために、図１２において提供される方法を使用することにより元のパケットに対して完全性保護を実行してもよく、ルータ4は、方法1300を使用することにより元のパケットを取得してもよい。具体的には、完全性保護パケットを受信した後に、ルータ4は、元のパケットを取得するために、完全性保護パケットの完全性を検査してもよく、ルータ4は、元のパケットをUE2に更に送信する。
【００７８】
可能な設計では、第1の保護プロトコルは暗号化プロトコルでもよい。例えば、第1の保護プロトコルはMACsecプロトコルでもよい。図９を参照して、第1の保護プロトコルがMACsecプロトコルであるシナリオについて、例を使用することにより以下に説明する。方法100におけるネットワークデバイスは、図１におけるルータ4でもよい。第1のパケットは、図９における新たなIPパケットでもよい。具体的には、図９における元のIPパケットを受信した後に、ルータ2は、元のIPパケットに基づいて新たなIPパケットを生成してもよい。元のIPパケットは、IPヘッダとIPペイロードとを含む。IPペイロードはイーサネットフレームを含む。イーサネットフレームはイーサネットフレームヘッダとイーサネットフレームペイロードとを含む。イーサネットフレームヘッダは、宛先MACアドレス(DMAC)と、送信元MACアドレス(SMAC)と、イーサネットタイプ(ETYPE)とを含む。第1のパケットヘッダはIPヘッダでもよい。第2のパケットヘッダは拡張ヘッダでもよい。保護データはイーサネットフレームペイロードを含んでもよい。さらに、保護データはETYPEを更に含む。指示フィールドはIPヘッダ内のprotocolフィールドでもよい。例えば、protocolフィールドの値は0xFCでもよい。protocolフィールドは、新たなIPパケットが拡張ヘッダを含むことを示すために使用される。拡張ヘッダはタイプフィールドを含み、タイプフィールドはMACsecプロトコルを示すために使用される。新たなIPパケット内のイーサネットフレームペイロードは、元のIPパケット内のイーサネットフレームペイロードが第1の保護プロトコル(例えば、MACsecプロトコル)を使用することにより保護された後に取得されることが理解できる。具体的には、元のIPパケット内のイーサネットフレームペイロードは、新たなIPパケット内のイーサネットフレームペイロードを取得するために、MACsecプロトコルの暗号化アルゴリズムに従って処理される。したがって、元のIPパケット内のイーサネットフレームペイロードの値は、新たなIPパケット内のイーサネットフレームペイロードの値と等しくない。MACsecプロトコルについては、IEEE802.1AEを参照する。新たなIPパケットがルータ4により受信された後に、ルータ4は、protocolフィールドに基づいて、新たなIPパケットが拡張ヘッダを含むことを決定してもよい。さらに、ルータ4は、拡張ヘッダ内のタイプフィールドに基づいてMACsecプロトコルを決定してもよい。ルータ4は、MACsecプロトコルの解読アルゴリズムに従って新たなIPパケットを解読してもよい。具体的には、ルータ4は、元のIPパケットを取得するために、新たなIPパケット内のETYPE及びイーサネットフレームペイロードを解読する。方法1300において関与する元のデータは、元のIPパケット内のイーサネットフレームペイロードを含んでもよい。ルータ4は、元のIPパケットをホスト2(例えば、UE2)に送信してもよい。元のIPパケット内のイーサネットフレームペイロードは暗号化されていないデータであり、元のIPパケット内のイーサネットフレームペイロードは、MACsecプロトコルの暗号化アルゴリズムに従って暗号化が実行される前に存在するデータであることが理解できる。
【００７９】
方法1300における第1のパケット及び方法1200における第1のパケットは同じパケットでもよいことが習得できる。方法1200はルータ2により実行されてもよく、方法1300はルータ4により実行されてもよい。したがって、図１３に示す方法1300の具体的な実現方式については、実施形態における図１２に示す方法1200の説明を参照する。
【００８０】
図１４は、この出願によるネットワークデバイス1400の概略図である。ネットワークデバイス1400は、図１に示すネットワークアーキテクチャに適用されてもよく、例えば、図１に示すネットワークアーキテクチャにおけるルータ1でもよい。ネットワークデバイス1400は、図１２に示す方法1200を実行するように構成されてもよい。図１４に示すように、ネットワークデバイス1400は、プロセッサ810と、プロセッサ810に結合されたメモリ820と、トランシーバ830とを含んでもよい。プロセッサ810は、中央処理装置(central  processing  unit,  CPU)、ネットワークプロセッサ(network  processor,  NP)又はCPUとNPとの組み合わせでもよい。代替として、プロセッサは、特定用途向け集積回路(application-specific  integrated  circuit,  ASIC)、プログラマブルロジックデバイス(programmable  logic  device,  PLD)又はこれらの組み合わせでもよい。PLDは、複雑プログラマブルロジックデバイス(complex  programmable  logic  device,  CPLD)、フィールドプログラマブルゲートアレイ(field-programmable  gate  array,  FPGA)、ジェネリックアレイロジック(generic  array  logic,  GAL)又はこれらのいずれかの組み合わせでもよい。プロセッサ810は、1つのプロセッサでもよく、或いは、複数のプロセッサを含んでもよい。メモリ820は、ランダムアクセスメモリ(random  access  memory,  RAM)のような揮発性メモリを含んでもよく、或いは、メモリは、読み取り専用メモリ(read-only  memory,  ROM)、フラッシュメモリ、ハードディスク(hard  disk,  HDD)又はソリッドステートドライブ(solid-state  drive,  SSD)のような不揮発性メモリを含んでもよく、或いは、メモリ820は、上記のタイプのメモリの組み合わせを含んでもよい。メモリ820は、1つのメモリでもよく、或いは、複数のメモリを含んでもよい。実現方式では、メモリ820は、コンピュータ読み取り可能命令を記憶する。コンピュータ読み取り可能命令は、複数のソフトウェアモジュール、例えば、送信モジュール821、処理モジュール822及び受信モジュール823を含む。各ソフトウェアモジュールを実行した後に、プロセッサ810は、各ソフトウェアモジュールの指示に基づいて対応する動作を実行してもよい。この実施形態では、1つのソフトウェアモジュールにより実行される動作は、実際には、ソフトウェアモジュールの指示に基づいてプロセッサ810により実行される動作である。例えば、受信モジュール823は、UE1からパケット1を受信するように構成され、処理モジュール822は、パケット1に基づいて方法1200における第1のパケットを生成するように構成され、送信モジュール821は、第1のパケットをルータ4に送信するように構成される。
【００８１】
図１５は、この出願によるネットワークデバイス1500の概略図である。ネットワークデバイス1500は、図１に示すネットワークアーキテクチャに適用されてもよく、例えば、図１に示すネットワークアーキテクチャにおけるルータ4でもよい。ネットワークデバイス1500は、図１３に示す方法1300を実行するように構成されてもよい。図１５に示すように、ネットワークデバイス1500は、プロセッサ910と、プロセッサ910に結合されたメモリ920と、トランシーバ930とを含んでもよい。プロセッサ910は、CPU、NP又はCPUとNPとの組み合わせでもよい。プロセッサはハードウェアチップを更に含んでもよい。ハードウェアチップは、ASIC、PLD又はこれらの組み合わせでもよい。PLDは、CPLD、FPGA、GAL又はこれらのいずれかの組み合わせでもよい。プロセッサ910は、1つのプロセッサでもよく、或いは、複数のプロセッサを含んでもよい。メモリ920は、RAMのような揮発性メモリを含んでもよく、或いは、メモリは、ROM、フラッシュメモリ、HDD又はSSDのような不揮発性メモリを含んでもよく、或いは、メモリは、上記のタイプのメモリの組み合わせを含んでもよい。メモリ920は、1つのメモリでもよく、或いは、複数のメモリを含んでもよい。実現方式では、メモリ920は、コンピュータ読み取り可能命令を記憶する。コンピュータ読み取り可能命令は、複数のソフトウェアモジュール、例えば、送信モジュール921、処理モジュール922及び受信モジュール923を含んでもよい。各ソフトウェアモジュールを実行した後に、プロセッサ910は、各ソフトウェアモジュールの指示に基づいて対応する動作を実行してもよい。この実施形態では、1つのソフトウェアモジュールにより実行される動作は、実際には、ソフトウェアモジュールの指示に基づいてプロセッサ910により実行される動作である。例えば、受信モジュール923は、ルータ2から第1のパケットを受信するように構成され、処理モジュール922は、第1のパケットに基づいて、図９における元のIPパケットに含まれる元のデータのような元のデータを生成するように構成され、送信モジュール921は、図９に示す元のIPパケットをUE2に送信するように構成される。
【００８２】
この出願の実施形態は、通信システムを更に提供する。通信システムは、図１４において提供されるネットワークデバイス1400と、図１５において提供されるネットワークデバイス1500とを含む。
【００８３】
この出願は非一時的なコンピュータ読み取り可能記憶媒体を更に提供する。非一時的なコンピュータ読み取り可能記憶媒体は、コンピュータプログラムを記憶するように構成される。コンピュータプログラムがプロセッサにより実行されたとき、プロセッサは、図１２又は図１３に示す方法を実行することが可能になる。詳細については、図１２又は図１３に示す実施形態の説明を参照し、詳細はここでは再び説明しない。
【００８４】
上記の実施形態の可能な設計では、第1の保護プロトコルは暗号化プロトコル又は完全性保護プロトコルである。
【００８５】
上記の実施形態の可能な設計では、第1の保護プロトコルは、AHプロトコル、ESPプロトコル、MACsecプロトコル、TLSプロトコル又はSSLプロトコルである。
【００８６】
上記の実施形態の可能な設計では、第1のパケットヘッダはMPLS  headerであり、指示フィールドは第1のパケットヘッダ内のMPLS  labelフィールドである。
【００８７】
上記の実施形態の可能な設計では、第1のパケットヘッダはEthernet  headerであり、指示フィールドは第1のパケットヘッダ内のEthernet  typeフィールドである。
【００８８】
上記の実施形態の可能な設計では、第1のパケットヘッダはIP  headerであり、指示フィールドは第1のパケットヘッダ内のprotocolフィールドである。
【００８９】
上記の実施形態の可能な設計では、第1のパケットヘッダはTCP  headerであり、指示フィールドは予備(reserved)フィールド又はオプション(option)フィールドである。
【００９０】
上記の実施形態の可能な設計では、第1のパケットヘッダはHTTPヘッダであり、タイプフィールドは拡張フィールドである。
【００９１】
当業者は、この明細書に開示された実施形態に記載の例と組み合わせて、モジュール及び方法の動作は、電子ハードウェア又はコンピュータソフトウェアと電子ハードウェアとの組み合わせを通じて実現されてもよいことを認識し得る。機能がハードウェアにより実行されるかソフトウェアにより実行されるかは、技術的解決策の特定の用途及び設計上の制約に依存する。当業者は、特定の用途毎に、記載の機能を実現するために異なる方法を使用し得る。
【００９２】
簡便且つ簡単な説明の目的で、上記のシステム、装置及びモジュールの詳細な動作プロセスについては、上記の方法の実施形態における対応するプロセスを参照し、詳細はここでは再び説明しないことが当業者により明確に理解できる。
【００９３】
上記の実施形態の全部又は一部は、ハードウェア、ファームウェア又はこれらのいずれかの組み合わせを使用することにより実現されてもよい。実施形態がソフトウェアに関するとき、ソフトウェアの全部又は一部は、コンピュータプログラム製品の形式で実現されてもよい。コンピュータプログラム製品は、1つ以上のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータ上にロードされて実行されたとき、この出願の実施形態による手順又は機能が全部或いは部分的に生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク又は他のプログラム可能装置でもよい。コンピュータ命令は、コンピュータ読み取り可能記憶媒体に記憶されてもよく、或いは、コンピュータ読み取り可能記憶媒体から他のコンピュータ読み取り可能記憶媒体に送信されてもよい。例えば、コンピュータ命令は、有線(例えば、同軸ケーブル、光ファイバ又はデジタル加入者線(digital  subscriber  line,  DSL))又は無線(例えば、赤外線、無線又はマイクロ波)方式で、ウェブサイト、コンピュータ、サーバ又はデータセンターから、他のウェブサイト、コンピュータ、サーバ又はデータセンターに送信されてもよい。コンピュータ読み取り可能記憶媒体は、コンピュータによりアクセス可能ないずれかの使用可能媒体、又は1つ以上の使用可能媒体を統合するサーバ又はデータセンターのようなデータ記憶デバイスでもよい。使用可能媒体は、磁気媒体(例えば、フロッピーディスク、ハードディスク又は磁気テープ)、光媒体(例えば、DVD)、半導体媒体(例えば、ソリッドステートディスク(solid  state  disk,  SSD))等でもよい。
【００９４】
この明細書の全ての部分は漸進的な方式で記載されている。実現方式における同じ或いは同様の部分については、相互参照が行われてもよい。各実現方式は、他の実現方式との違いに焦点を当てている。特に、装置及びシステムの実施形態は、基本的には、方法の実施形態と同様であり、したがって、簡単に記載されている。関連する部分については、方法の実施形態の説明を参照する。
【図１】
2021524217.tif 000003
【図２】
2021524217.tif 000004
【図３】
2021524217.tif 000005
【図４】
2021524217.tif 000006
【図５】
2021524217.tif 000007
【図６】
2021524217.tif 000008
【図７】
2021524217.tif 000009
【図８】
2021524217.tif 000010
【図９】
2021524217.tif 000011
【図１０】
2021524217.tif 000012
【図１１】
2021524217.tif 000013
【図１２】
2021524217.tif 000014
【図１３】
2021524217.tif 000015
【図１４】
2021524217.tif 000016
【図１５】
2021524217.tif 000017
【手続補正書】
【提出日】令和2年11月25日(2020.11.25)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
パケット送信方法であって、
ネットワークデバイスにより、第1のパケットを生成するステップであり、前記第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含み、前記第1のパケットヘッダは指示フィールドを含み、前記指示フィールドは、前記第1のパケットが前記第2のパケットヘッダを含むことを示すために使用され、前記第2のパケットヘッダはタイプフィールドを含み、前記タイプフィールドは、第1の保護プロトコルを示すために使用され、前記保護データは、前記第1の保護プロトコルを使用することにより保護されたデータである、ステップと、
前記ネットワークデバイスにより、前記第1のパケットを送信するステップと
を含む方法。
【請求項２】
前記第2のパケットヘッダはオフセットフィールドを更に含み、前記オフセットフィールドは、前記保護データの位置を示すために使用される、請求項１に記載の方法。
【請求項３】
前記第2のパケットヘッダはフラグフィールドを更に含み、前記フラグフィールドは、前記第2のパケットヘッダが前記オフセットフィールドを含むことを示す、請求項２に記載の方法。
【請求項４】
前記第2のパケットヘッダは長さフィールドを更に含み、前記長さフィールドは前記第2のパケットヘッダの長さを示す、請求項１乃至３のうちいずれか１項に記載の方法。
【請求項５】
前記第1の保護プロトコルは暗号化プロトコル又は完全性保護プロトコルである、請求項１乃至４のうちいずれか１項に記載の方法。
【請求項６】
パケット受信方法であって、
ネットワークデバイスにより、第1のパケットを受信するステップであり、前記第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含み、前記第1のパケットヘッダは指示フィールドを含み、前記指示フィールドは、前記第1のパケットが前記第2のパケットヘッダを含むことを示すために使用され、前記第2のパケットヘッダはタイプフィールドを含み、前記タイプフィールドは、第1の保護プロトコルを示すために使用され、前記保護データは、前記第1の保護プロトコルを使用することにより保護されたデータである、ステップと、
前記ネットワークデバイスにより、前記第1の保護プロトコル及び前記保護データに従って元のデータを取得するステップであり、前記元のデータは、前記第1の保護プロトコルを使用することにより保護されていない、ステップと
を含む方法。
【請求項７】
前記第2のパケットヘッダはオフセットフィールドを更に含み、前記オフセットフィールドは、前記保護データの位置を示すために使用される、請求項６に記載の方法。
【請求項８】
前記第2のパケットヘッダはフラグフィールドを更に含み、前記フラグフィールドは、前記第2のパケットヘッダが前記オフセットフィールドを含むことを示す、請求項７に記載の方法。
【請求項９】
前記第2のパケットヘッダは長さフィールドを更に含み、前記長さフィールドは前記第2のパケットヘッダの長さを示す、請求項６乃至８のうちいずれか１項に記載の方法。
【請求項１０】
前記第1の保護プロトコルは暗号化プロトコル又は完全性保護プロトコルである、請求項６乃至９のうちいずれか１項に記載の方法。
【請求項１１】
ネットワークデバイスであって、
プロセッサと、前記プロセッサに結合されたメモリとを含み、前記メモリは、コンピュータプログラムを記憶し、前記コンピュータプログラムが前記プロセッサにより実行されたとき、前記ネットワークデバイスは、
第1のパケットを生成し、前記第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含み、前記第1のパケットヘッダは指示フィールドを含み、前記指示フィールドは、前記第1のパケットが前記第2のパケットヘッダを含むことを示すために使用され、前記第2のパケットヘッダはタイプフィールドを含み、前記タイプフィールドは、第1の保護プロトコルを示すために使用され、前記保護データは、前記第1の保護プロトコルを使用することにより保護されたデータであり、
前記第1のパケットを送信する、
ことが可能になるネットワークデバイス。
【請求項１２】
前記第2のパケットヘッダはオフセットフィールドを更に含み、前記オフセットフィールドは、前記保護データの位置を示すために使用される、請求項１１に記載のネットワークデバイス。
【請求項１３】
前記第2のパケットヘッダはフラグフィールドを更に含み、前記フラグフィールドは、前記第2のパケットヘッダが前記オフセットフィールドを含むことを示す、請求項１２に記載のネットワークデバイス。
【請求項１４】
前記第2のパケットヘッダは長さフィールドを更に含み、前記長さフィールドは前記第2のパケットヘッダの長さを示す、請求項１１乃至１３のうちいずれか１項に記載のネットワークデバイス。
【請求項１５】
前記第1の保護プロトコルは暗号化プロトコル又は完全性保護プロトコルである、請求項１１乃至１４のうちいずれか１項に記載のネットワークデバイス。
【請求項１６】
ネットワークデバイスであって、
プロセッサと、前記プロセッサに結合されたメモリとを含み、前記メモリは、コンピュータプログラムを記憶し、前記コンピュータプログラムが前記プロセッサにより実行されたとき、前記ネットワークデバイスは、
第1のパケットを受信し、前記第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含み、前記第1のパケットヘッダは指示フィールドを含み、前記指示フィールドは、前記第1のパケットが前記第2のパケットヘッダを含むことを示すために使用され、前記第2のパケットヘッダはタイプフィールドを含み、前記タイプフィールドは、第1の保護プロトコルを示すために使用され、前記保護データは、前記第1の保護プロトコルを使用することにより保護されたデータであり、
前記第1の保護プロトコル及び前記保護データに従って元のデータを取得し、前記元のデータは、前記第1の保護プロトコルを使用することにより保護されていない、
ことが可能になるネットワークデバイス。
【請求項１７】
前記第2のパケットヘッダはオフセットフィールドを更に含み、前記オフセットフィールドは、前記保護データの位置を示すために使用される、請求項１６に記載のネットワークデバイス。
【請求項１８】
前記第2のパケットヘッダはフラグフィールドを更に含み、前記フラグフィールドは、前記第2のパケットヘッダが前記オフセットフィールドを含むことを示す、請求項１７に記載のネットワークデバイス。
【請求項１９】
前記第2のパケットヘッダは長さフィールドを更に含み、前記長さフィールドは前記第2のパケットヘッダの長さを示す、請求項１６乃至１８のうちいずれか１項に記載のネットワークデバイス。
【請求項２０】
前記第1の保護プロトコルは暗号化プロトコル又は完全性保護プロトコルである、請求項１６乃至１９のうちいずれか１項に記載のネットワークデバイス。
【国際調査報告】
2021524217.tif 000018
2021524217.tif 000019
2021524217.tif 000020
2021524217.tif 000021