JP2021524217A - パッケージ送信方法、パッケージ受信方法及びネットワークデバイス - Google Patents

パッケージ送信方法、パッケージ受信方法及びネットワークデバイス Download PDF

Info

Publication number
JP2021524217A
JP2021524217A JP2021515271A JP2021515271A JP2021524217A JP 2021524217 A JP2021524217 A JP 2021524217A JP 2021515271 A JP2021515271 A JP 2021515271A JP 2021515271 A JP2021515271 A JP 2021515271A JP 2021524217 A JP2021524217 A JP 2021524217A
Authority
JP
Japan
Prior art keywords
packet
protocol
field
packet header
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2021515271A
Other languages
English (en)
Other versions
JP7228030B2 (ja
Inventor
ウエイ，ジエンシオーン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2021524217A publication Critical patent/JP2021524217A/ja
Application granted granted Critical
Publication of JP7228030B2 publication Critical patent/JP7228030B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/03—Protocol definition or specification 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H04L12/4645—Details on frame tagging
    • H04L12/465—Details on frame tagging wherein a single frame includes a plurality of VLAN tags
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H04L12/4645—Details on frame tagging
    • H04L12/4666—Operational details on the addition or the stripping of a tag in a frame, e.g. at a provider edge node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L2012/4629—LAN interconnection over a backbone network, e.g. Internet, Frame Relay using multilayer switching, e.g. layer 3 switching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

データ送信方法が提供される。当該方法は、ネットワークデバイスにより、第1のパケットを生成し、第1のパケットを送信することを含む。第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含む。第1のパケットヘッダは指示フィールドを含む。指示フィールドは、第1のパケットが第2のパケットヘッダを含むことを示すために使用される。第2のパケットヘッダはタイプフィールドを含む。タイプフィールドは、第1の保護プロトコルを示すために使用される。保護データは、第1の保護プロトコルを使用することにより保護されたデータである。上記の技術的解決策では、第2のパケットヘッダはこの出願で定義されたパケットヘッダである。第2のパケット内のタイプフィールドの値が既存のプロトコルで定義されていないので、タイプフィールドはより多くの保護プロトコルを示してもよい。したがって、上記の技術的解決策は、良いスケーラビリティを有し、より多くの保護プロトコルをサポートできる。

Description

［関連出願への相互参照］
この出願は、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))等でもよい。
この明細書の全ての部分は漸進的な方式で記載されている。実現方式における同じ或いは同様の部分については、相互参照が行われてもよい。各実現方式は、他の実現方式との違いに焦点を当てている。特に、装置及びシステムの実施形態は、基本的には、方法の実施形態と同様であり、したがって、簡単に記載されている。関連する部分については、方法の実施形態の説明を参照する。

Claims (20)

  1. パケット送信方法であって、
    ネットワークデバイスにより、第1のパケットを生成するステップであり、前記第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含み、前記第1のパケットヘッダは指示フィールドを含み、前記指示フィールドは、前記第1のパケットが前記第2のパケットヘッダを含むことを示すために使用され、前記第2のパケットヘッダはタイプフィールドを含み、前記タイプフィールドは、第1の保護プロトコルを示すために使用され、前記保護データは、前記第1の保護プロトコルを使用することにより保護されたデータである、ステップと、
    前記ネットワークデバイスにより、前記第1のパケットを送信するステップと
    を含む方法。
  2. 前記第2のパケットヘッダはオフセットフィールドを更に含み、前記オフセットフィールドは、前記保護データの位置を示すために使用される、請求項１に記載の方法。
  3. 前記第2のパケットヘッダはフラグフィールドを更に含み、前記フラグフィールドは、前記第2のパケットヘッダが前記オフセットフィールドを含むことを示す、請求項２に記載の方法。
  4. 前記第2のパケットヘッダは長さフィールドを更に含み、前記長さフィールドは前記第2のパケットヘッダの長さを示す、請求項１乃至３のうちいずれか１項に記載の方法。
  5. 前記第1の保護プロトコルは暗号化プロトコル又は完全性保護プロトコルである、請求項１乃至４のうちいずれか１項に記載の方法。
  6. パケット受信方法であって、
    ネットワークデバイスにより、第1のパケットを受信するステップであり、前記第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含み、前記第1のパケットヘッダは指示フィールドを含み、前記指示フィールドは、前記第1のパケットが前記第2のパケットヘッダを含むことを示すために使用され、前記第2のパケットヘッダはタイプフィールドを含み、前記タイプフィールドは、第1の保護プロトコルを示すために使用され、前記保護データは、前記第1の保護プロトコルを使用することにより保護されたデータである、ステップと、
    前記ネットワークデバイスにより、前記第1の保護プロトコル及び前記保護データに従って元のデータを取得するステップであり、前記元のデータは、前記第1の保護プロトコルを使用することにより保護されていない、ステップと
    を含む方法。
  7. 前記第2のパケットヘッダはオフセットフィールドを更に含み、前記オフセットフィールドは、前記保護データの位置を示すために使用される、請求項６に記載の方法。
  8. 前記第2のパケットヘッダはフラグフィールドを更に含み、前記フラグフィールドは、前記第2のパケットヘッダが前記オフセットフィールドを含むことを示す、請求項７に記載の方法。
  9. 前記第2のパケットヘッダは長さフィールドを更に含み、前記長さフィールドは前記第2のパケットヘッダの長さを示す、請求項６乃至８のうちいずれか１項に記載の方法。
  10. 前記第1の保護プロトコルは暗号化プロトコル又は完全性保護プロトコルである、請求項６乃至９のうちいずれか１項に記載の方法。
  11. ネットワークデバイスであって、
    プロセッサと、前記プロセッサに結合されたメモリとを含み、前記メモリは、コンピュータプログラムを記憶し、前記コンピュータプログラムが前記プロセッサにより実行されたとき、前記ネットワークデバイスは、
    第1のパケットを生成し、前記第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含み、前記第1のパケットヘッダは指示フィールドを含み、前記指示フィールドは、前記第1のパケットが前記第2のパケットヘッダを含むことを示すために使用され、前記第2のパケットヘッダはタイプフィールドを含み、前記タイプフィールドは、第1の保護プロトコルを示すために使用され、前記保護データは、前記第1の保護プロトコルを使用することにより保護されたデータであり、
    前記第1のパケットを送信する、
    ことが可能になるネットワークデバイス。
  12. 前記第2のパケットヘッダはオフセットフィールドを更に含み、前記オフセットフィールドは、前記保護データの位置を示すために使用される、請求項１１に記載のネットワークデバイス。
  13. 前記第2のパケットヘッダはフラグフィールドを更に含み、前記フラグフィールドは、前記第2のパケットヘッダが前記オフセットフィールドを含むことを示す、請求項１２に記載のネットワークデバイス。
  14. 前記第2のパケットヘッダは長さフィールドを更に含み、前記長さフィールドは前記第2のパケットヘッダの長さを示す、請求項１１乃至１３のうちいずれか１項に記載のネットワークデバイス。
  15. 前記第1の保護プロトコルは暗号化プロトコル又は完全性保護プロトコルである、請求項１１乃至１４のうちいずれか１項に記載のネットワークデバイス。
  16. ネットワークデバイスであって、
    プロセッサと、前記プロセッサに結合されたメモリとを含み、前記メモリは、コンピュータプログラムを記憶し、前記コンピュータプログラムが前記プロセッサにより実行されたとき、前記ネットワークデバイスは、
    第1のパケットを受信し、前記第1のパケットは、第1のパケットヘッダと、第2のパケットヘッダと、保護データとを含み、前記第1のパケットヘッダは指示フィールドを含み、前記指示フィールドは、前記第1のパケットが前記第2のパケットヘッダを含むことを示すために使用され、前記第2のパケットヘッダはタイプフィールドを含み、前記タイプフィールドは、第1の保護プロトコルを示すために使用され、前記保護データは、前記第1の保護プロトコルを使用することにより保護されたデータであり、
    前記第1の保護プロトコル及び前記保護データに従って元のデータを取得し、前記元のデータは、前記第1の保護プロトコルを使用することにより保護されていない、
    ことが可能になるネットワークデバイス。
  17. 前記第2のパケットヘッダはオフセットフィールドを更に含み、前記オフセットフィールドは、前記保護データの位置を示すために使用される、請求項１６に記載のネットワークデバイス。
  18. 前記第2のパケットヘッダはフラグフィールドを更に含み、前記フラグフィールドは、前記第2のパケットヘッダが前記オフセットフィールドを含むことを示す、請求項１７に記載のネットワークデバイス。
  19. 前記第2のパケットヘッダは長さフィールドを更に含み、前記長さフィールドは前記第2のパケットヘッダの長さを示す、請求項１６乃至１８に記載のネットワークデバイス。
  20. 前記第1の保護プロトコルは暗号化プロトコル又は完全性保護プロトコルである、請求項１６乃至１９のうちいずれか１項に記載のネットワークデバイス。
JP2021515271A 2018-09-17 2019-09-12 パッケージ送信方法、パッケージ受信方法及びネットワークデバイス Active JP7228030B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201811083093.3 2018-09-17
CN201811083093.3A CN110912859B (zh) 2018-09-17 2018-09-17 发送报文的方法、接收报文的方法及网络设备
PCT/CN2019/105673 WO2020057436A1 (zh) 2018-09-17 2019-09-12 发送报文的方法、接收报文的方法及网络设备

Publications (2)

Publication Number Publication Date
JP2021524217A true JP2021524217A (ja) 2021-09-09
JP7228030B2 JP7228030B2 (ja) 2023-02-22

Family

ID=69813119

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021515271A Active JP7228030B2 (ja) 2018-09-17 2019-09-12 パッケージ送信方法、パッケージ受信方法及びネットワークデバイス

Country Status (5)

Country Link
US (1) US11888904B2 (ja)
EP (1) EP3771170A4 (ja)
JP (1) JP7228030B2 (ja)
CN (1) CN110912859B (ja)
WO (1) WO2020057436A1 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4135280B1 (en) * 2020-04-30 2024-07-24 Huawei Technologies Co., Ltd. Message parsing method and apparatus
CN114244917B (zh) * 2020-08-31 2023-06-02 华为技术有限公司 一种数据传输方法、装置及系统
US20230133729A1 (en) * 2021-10-29 2023-05-04 Nokia Solutions And Networks Oy Security for communication protocols
CN114567478B (zh) * 2022-02-24 2024-07-02 北京华三通信技术有限公司 通信方法及装置
CN117915398A (zh) * 2022-10-12 2024-04-19 上海朗帛通信技术有限公司 一种被用于无线通信的通信节点中的方法和装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10126406A (ja) * 1996-10-23 1998-05-15 Toyo Commun Equip Co Ltd ネットワークにおけるデータの暗号方式
JP2000287192A (ja) * 1999-03-31 2000-10-13 Toshiba Corp 情報配信装置、受信装置及び通信方法
JP2002537720A (ja) * 1999-02-16 2002-11-05 フラウンホーファー−ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン データストリームを生成する方法及び装置、及びデータストリームを再生する方法及び装置
CN102271086A (zh) * 2011-07-25 2011-12-07 华为技术有限公司 发送报文的方法和装置
JP2016140058A (ja) * 2014-12-18 2016-08-04 横河電機株式会社 ルーティング情報を判定するためのシステムおよび方法

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7254835B2 (en) 2002-01-04 2007-08-07 Sun Microsystems, Inc. Method and apparatus for conveying a security context in addressing information
US7248582B2 (en) * 2002-02-13 2007-07-24 Sun Microsystems, Inc. Method and system for labeling data in a communications system
US7797411B1 (en) 2005-02-02 2010-09-14 Juniper Networks, Inc. Detection and prevention of encapsulated network attacks using an intermediate device
ES2314534T3 (es) * 2005-09-20 2009-03-16 Panasonic Corporation Procedimiento y dispositivo para la señalizacion de segmentacion y concatenacion de paquetes en un sistema de telecomunicaciones.
US7853691B2 (en) * 2006-11-29 2010-12-14 Broadcom Corporation Method and system for securing a network utilizing IPsec and MACsec protocols
US8638795B2 (en) 2010-08-12 2014-01-28 Citrix Systems, Inc. Systems and methods for quality of service of encrypted network traffic
WO2013179551A1 (ja) 2012-05-29 2013-12-05 パナソニック株式会社 送信装置、受信装置、通信システム、送信方法、及び受信方法
WO2014000307A1 (zh) 2012-06-30 2014-01-03 华为技术有限公司 数据传输方法、网元设备及通信系统
US9338172B2 (en) * 2013-03-13 2016-05-10 Futurewei Technologies, Inc. Enhanced IPsec anti-replay/anti-DDOS performance
EP2987296B1 (en) * 2013-04-17 2020-09-30 InterDigital VC Holdings, Inc. Method and apparatus for packet header compression
CN104184645B (zh) 2013-05-27 2018-05-04 华为技术有限公司 一种生成操作请求的方法、设备及系统
WO2015056095A1 (en) * 2013-10-17 2015-04-23 Marvell World Trade Ltd. Packet parsing and key generation in a network device
CN103873464B (zh) * 2014-02-27 2017-05-10 华为技术有限公司 报文处理的方法及转发设备
US9762488B2 (en) * 2014-03-06 2017-09-12 Cisco Technology, Inc. Segment routing extension headers
CN105592030B (zh) * 2014-11-18 2019-06-07 华为技术有限公司 Ip报文处理方法及装置
CN105721359B (zh) * 2014-12-04 2019-11-15 中兴通讯股份有限公司 Vxlan报文传输方法及装置
CN106161225B (zh) * 2015-03-23 2019-05-28 华为技术有限公司 用于处理vxlan报文的方法、装置及系统
CN107306198B (zh) * 2016-04-20 2019-12-06 华为技术有限公司 报文转发方法、设备和系统
CN107342964B (zh) 2016-04-28 2019-05-07 华为技术有限公司 一种报文解析方法及设备
CN107547508B (zh) * 2017-06-29 2021-07-30 新华三信息安全技术有限公司 一种报文发送、接收方法、装置及网络设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10126406A (ja) * 1996-10-23 1998-05-15 Toyo Commun Equip Co Ltd ネットワークにおけるデータの暗号方式
JP2002537720A (ja) * 1999-02-16 2002-11-05 フラウンホーファー−ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン データストリームを生成する方法及び装置、及びデータストリームを再生する方法及び装置
JP2000287192A (ja) * 1999-03-31 2000-10-13 Toshiba Corp 情報配信装置、受信装置及び通信方法
CN102271086A (zh) * 2011-07-25 2011-12-07 华为技术有限公司 发送报文的方法和装置
JP2016140058A (ja) * 2014-12-18 2016-08-04 横河電機株式会社 ルーティング情報を判定するためのシステムおよび方法

Also Published As

Publication number Publication date
CN110912859A (zh) 2020-03-24
WO2020057436A1 (zh) 2020-03-26
JP7228030B2 (ja) 2023-02-22
EP3771170A1 (en) 2021-01-27
US20210075829A1 (en) 2021-03-11
US11888904B2 (en) 2024-01-30
CN110912859B (zh) 2021-12-14
EP3771170A4 (en) 2021-06-09

Similar Documents

Publication Publication Date Title
JP7228030B2 (ja) パッケージ送信方法、パッケージ受信方法及びネットワークデバイス
US10757138B2 (en) Systems and methods for storing a security parameter index in an options field of an encapsulation header
US9065701B2 (en) Enhanced serialization mechanism
US9712504B2 (en) Method and apparatus for avoiding double-encryption in site-to-site IPsec VPN connections
US10009336B2 (en) Network security system to validate a server certificate
WO2014040411A1 (zh) 一种数据报文处理方法、系统及设备
US9369550B2 (en) Protocol for layer two multiple network links tunnelling
US20150150073A1 (en) Smart Virtual Private Network
CA2870048A1 (en) Multi-tunnel virtual private network
CN112491821B (zh) 一种IPSec报文转发的方法及装置
WO2020072682A1 (en) Securing mpls network traffic
WO2016165277A1 (zh) 一种实现IPsec分流的方法和装置
CN117254976B (zh) 基于VPP的国标IPsec VPN实现方法、装置、系统及电子设备
US20230239279A1 (en) Method and apparatus for security communication
US11095619B2 (en) Information exchange for secure communication
WO2005008997A1 (en) Hardware acceleration for unified ipsec and l2tp with ipsec processing in a device that integrates wired and wireless lan, l2 and l3 switching functionality
EP4156622A1 (en) Method for checking application information, message processing method and device
Hussain et al. Securing the insecure link of internet-of-things using next-generation smart gateways
Zhang et al. Application research of MPLS VPN all-in-one campus card network based on IPSec
US20210092103A1 (en) In-line encryption of network data
EP4436109A1 (en) Key distribution over ip/udp
US20220150058A1 (en) Forwarding device, key management server device, communication system, forwarding method, and computer program product
Song et al. One new research about IPSec communication based on HTTP tunnel
CN117879996A (zh) 一种基于ipsec vpn的数据传输方法及装置
Cui et al. RFC 7856: Softwire Mesh Management Information Base (MIB)

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201125

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20201125

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20211221

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220322

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20220809

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221118

C60 Trial request (containing other claim documents, opposition documents)

Free format text: JAPANESE INTERMEDIATE CODE: C60

Effective date: 20221118

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20221130

C21 Notice of transfer of a case for reconsideration by examiners before appeal proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C21

Effective date: 20221206

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230117

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230210

R150 Certificate of patent or registration of utility model

Ref document number: 7228030

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150