Title of invention: communication device, communication method and data structure
Technical field
[0001]
　The present disclosure relates to communication devices, communication methods and data structures.
[0002]
　From the viewpoint of network operators and service providers, a service function (Service Function) that transfers packets transferred in the network to a server device that is not included in the original packet transfer path and operates on the server device as needed. : SF) acts on the packet is called Server Fusion Chaining (SFC). Examples of the SF include Network Addless Translation (NAT), Load Balancer, Web Application Firewall (WAF), and the like.
[0003]
　Non-Patent Document 1 describes the architecture of SFC. Further, Patent Document 1 describes a method of autonomously and decentralized failure detection and failure recovery of devices and links in order to increase the availability of virtualized network service functions.
Prior art literature
Patent documents
[0004]
Patent Document 1: Japanese Unexamined Patent Publication No. 2016-46736
Non-patent literature
[0005]
Non-Patent Document 1: J. Halpern and C. Pignataro. Service Function Chaining (SFC) Architecture, October 2015. RFC 7665.
Outline of the invention
Problems to be solved by the invention
[0006]
　In SFC, SFs such as WAF and Load Balancer are prepared from the viewpoint of network operators and service providers. That is, what kind of packet is targeted for SFC is determined by the intention of the network operator or the service provider.
[0007]
　Therefore, in the present disclosure, in a service for forwarding packets in a network, a new and improved function capable of causing one or more functions desired by a service user to act on a packet desired by the service user. We propose communication devices, communication methods, and data structures.
Means to solve problems
[0008]
　According to the present disclosure, a communication unit that executes communication with another node and a control unit that controls communication by the communication unit are provided, and the control unit directs the source node to the destination node. Add header information that describes at least the route information between the own device located after the source node and the target node located before the destination node to the packet, and it exists in the route. A communication device is provided that causes the communication unit to send a signal to another node.
[0009]
　Further, according to the present disclosure, a communication unit that executes communication with another node and a control unit that controls communication by the communication unit are provided, and the control unit has a source node to a transmission destination node. The communication is deleted by deleting at least the header information in which the route information from the start node located after the source node to the own device located before the destination node, which is added to the directed packet, is described. A communication device is provided to be sent to the unit.
[0010]
　Further, according to the present disclosure, a communication unit that executes communication with another node and a control unit that controls communication by the communication unit are provided, and the control unit has a source node to a transmission destination node. Refer to the data to which the header information in which at least the route information from the start node located in the subsequent stage of the source node to the target node located in the previous stage of the destination node is described is added to the directed packet. A communication device is provided that determines a next node and causes the communication unit to send the data toward the determined next node.
[0011]
　Further, according to the present disclosure, a communication unit that executes communication with another node and a control unit that controls communication by the communication unit are provided, and the control unit is between a start node and a target node. The start node is a node that adds header information in which at least the route information between the start node and the target node is described, and the target node deletes the header information. It is a node, and the route information between the start node and the target node is at least information about communication between the start node and at least one relay node existing between the target node and the relay node. A communication device is provided in which information on a function to be executed and the content of processing according to the execution result of the function on the relay node are described.
[0012]
　Further, according to the present disclosure, the transmission of the communication with the other node and the control of the communication with the other node are provided, and the control is transmitted by the source node. A route is added to the packet directed to the destination node by adding header information that describes at least the route information between the start node located after the source node and the target node located before the destination node. A communication method is provided for sending to other nodes existing in the node.
[0013]
　Further, according to the present disclosure, the transmission of the communication with the other node and the control of the communication with the other node are provided, and the control is transmitted by the source node. The header information in which at least the route information between the start node located after the source node and the target node located before the destination node is described in the packet directed to the destination node is deleted. A communication method is provided for sending to another node.
[0014]
　Further, according to the present disclosure, the transmission of the communication with the other node and the control of the communication with the other node are provided, and the control is transmitted by the source node. Data to which the header information in which at least the route information from the start node located in the subsequent stage of the source node to the target node located in the previous stage of the destination node is described is added to the packet directed to the destination node. A communication method is provided in which the next node is determined with reference to the data, and the data is sent to the determined next node.
[0015]
　Further, according to the present disclosure, a communication unit that executes communication with another node, a control unit that controls communication by the communication unit, and the control unit are packets directed by the source node to the destination node. The start node located after the source node between the start node and the target node and the transmission are used as the header information, which is used in a communication device that adds header information to the communication unit and sends the header information to the communication unit. A data structure is provided in which at least the route information to and from the target node located in front of the destination node is provided.
A brief description of the drawing
[0016]
FIG. 1 is an explanatory diagram showing an example of SFC architecture.
FIG. 2 is an explanatory diagram showing an architecture of AFC proposed in the embodiment of the present disclosure.
FIG. 3 is an explanatory diagram showing a structure of an AFC data packet.
[Fig. 4] Fig. 4 is an explanatory diagram showing security measures in AF installation.
[Fig. 5] Fig. 5 is an explanatory diagram showing security measures in the installation of AFC.
[Fig. 6] Fig. 6 is an explanatory diagram showing security measures in data packet transfer.
[Fig. 7] Fig. 7 is an explanatory diagram showing security measures for deleting AFC.
[Fig. 8] Fig. 8 is an explanatory diagram showing security measures for deleting AF.
FIG. 9 is an explanatory diagram showing a procedure for installing AF on AF Node.
FIG. 10 is an explanatory diagram showing a structural example of an AF Setup Request packet.
FIG. 11 is an explanatory diagram showing a structural example of an AF Setup Response packet.
FIG. 12 is an explanatory diagram showing a structural example of an AA Request packet.
FIG. 13 is an explanatory diagram showing a structural example of an AA Response packet.
FIG. 14 is an explanatory diagram showing a structural example of an AF Invoke Request packet.
FIG. 15 is an explanatory diagram showing a structural example of an AF Invoke Response packet.
FIG. 16 is an explanatory diagram showing a structural example of a Daemon AF Table.
FIG. 17 is an explanatory diagram showing a structural example of a Manager User Table, a Manager AF Table, and a Manager AF Node Table.
FIG. 18 is an explanatory diagram showing a structural example of a Daemon AF Table.
FIG. 19 is an explanatory diagram showing a structural example of a Daemon AF Table.
FIG. 20 is an explanatory diagram showing a structural example of a table held by an AFC Manager.
FIG. 21 is an explanatory diagram showing an installation procedure of AFC-1.
FIG. 22 is an explanatory diagram showing a path of AFC-1.
FIG. 23 is an explanatory diagram showing a structural example of an AFC Set Request packet.
FIG. 24 is an explanatory diagram showing a structural example of an AFC Setup Response packet.
FIG. 25 is an explanatory diagram showing a structural example of a table held by an AFC Manager.
FIG. 26 is an explanatory diagram showing a structural example of an AFC Installation Request packet.
FIG. 27 is an explanatory diagram showing a structural example of an AFC Installation Response packet.
FIG. 28 is an explanatory diagram showing a structural example of a table held by AFC Ingress.
FIG. 29 is an explanatory diagram showing a packet flow.
FIG. 30 is an explanatory diagram showing an example of a structure of a data packet.
FIG. 31 is an explanatory diagram showing a structural example of an AFC data packet.
FIG. 32 is an explanatory diagram showing a structural example of a Daemon AFC Table.
FIG. 33 is an explanatory diagram showing a structural example of a header of an AFC data packet.
FIG. 34 is an explanatory diagram showing a structural example of a header of an AFC data packet.
FIG. 35 is an explanatory diagram showing a path of AFC-2.
FIG. 36 is an explanatory diagram showing a structural example of an AFC Set Request packet.
FIG. 37 is an explanatory diagram showing a structural example of an AFC Switch Response packet.
FIG. 38 is an explanatory diagram showing a structural example of an AFC Installation Request packet.
FIG. 39 is an explanatory diagram showing a structural example of an AFC Installation Response packet.
FIG. 40 is an explanatory diagram showing a structural example of a table held by an AFC Manager.
FIG. 41 is an explanatory diagram showing a structural example of a table held by AFC Ingress.
FIG. 42 is an explanatory diagram showing an example of a structure of a data packet.
FIG. 43 is an explanatory diagram showing a structural example of a header of an AFC data packet.
FIG. 44 is an explanatory diagram showing a structural example of a header of an AFC data packet.
FIG. 45 is an explanatory diagram showing the deletion of AFC.
FIG. 46 is an explanatory diagram showing a structural example of an AFC Delete Request packet.
FIG. 47 is an explanatory diagram showing a structural example of an AFC Delete Response packet.
FIG. 48 is an explanatory diagram showing the deletion of AF.
FIG. 49 is an explanatory diagram showing a structural example of an AF Delete Request packet.
FIG. 50 is an explanatory diagram showing a structural example of an AF Delete Response packet.
FIG. 51 is an explanatory diagram showing a structural example of a table held by an AFC Manager.
FIG. 52 is an explanatory diagram showing a path of AFC-3.
FIG. 53 is an explanatory diagram showing an example of a structure of a table held by AF Node.
FIG. 54 is an explanatory diagram showing an example of a structure of a table held by AF Node.
FIG. 55 is an explanatory diagram showing a structural example of a table held by the AF Node.
FIG. 56 is an explanatory diagram showing an example of a structure of a table held by AF Node.
FIG. 57 is an explanatory diagram showing a structural example of a table held by an AFC Manager.
FIG. 58 is an explanatory diagram showing a structural example of an AFC Set Request packet.
FIG. 59 is an explanatory diagram showing a structural example of an AFC Setup Response packet.
FIG. 60 is an explanatory diagram showing a structural example of an AFC Installation Request packet.
FIG. 61 is an explanatory diagram showing a structural example of an AFC Installation Response packet.
FIG. 62 is an explanatory diagram showing a structural example of a table held by an AFC Manager.
FIG. 63 is an explanatory diagram showing a structural example of a table held by AFC Ingress.
FIG. 64 is an explanatory diagram showing monitoring of AF Node load by AFC Ingress.
FIG. 65 is an explanatory diagram showing a structural example of a Load Monitoring Packet.
FIG. 66 is an explanatory diagram showing a structural example of a Load Monitoring Packet.
FIG. 67 is an explanatory diagram showing a structural example of an Ingress AF Node Table.
[Fig. 68] Fig. 68 is an explanatory diagram showing an example of a structure of a data packet.
FIG. 69 is an explanatory diagram showing a structural example of an AFC data packet.
FIG. 70 is an explanatory diagram showing a structural example of an AFC data packet.
FIG. 71 is an explanatory diagram showing a structural example of an AFC data packet.
FIG. 72 is an explanatory diagram showing an example of packet transmission in AFC.
FIG. 73 is an explanatory diagram showing a structural example of an AFC Feedback packet.
FIG. 74 is an explanatory diagram showing a structural example of a table held by AFC Ingress.
[Fig. 75] Fig. 75 is an explanatory diagram showing an extension process of a time until a timeout.
FIG. 76 is an explanatory diagram showing a structural example of a Timeout Extension Request packet.
FIG. 77 is an explanatory diagram showing a structural example of a Timeout Extension Response packet.
FIG. 78 is an explanatory diagram showing a functional configuration example of a communication device 100 that can function as each node according to the embodiment of the present disclosure.
Mode for carrying out the invention
[0017]
　Preferred embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. In the present specification and the drawings, components having substantially the same functional configuration are designated by the same reference numerals, so that duplicate description will be omitted.
[0018]
　The explanations will be given in the following order.
　1. 1. Embodiments of the present disclosure
　　1.1. SFC architecture example
　　1.2. Specific explanation of AFC
　　1.3. Functional configuration example of communication device
　2. Summary
[0019]
　<1. Embodiments of the present disclosure>
　[1.1. SFC Architecture Example]
　Before explaining the embodiment of the present disclosure in detail, first, an SFC architecture example will be described. FIG. 1 is an example of the SFC architecture disclosed in Non-Patent Document 1.
[0020]
　In the SFC architecture as shown in FIG. 1, the range to which SFC is applied is referred to as SFC-enable Domain. Within the SFC-enabled Domain, there are a classifier, a service function forwarder (SFF), a service function (SF), a server, and the like.
[0021]
　In FIG. 1, consider the case of accessing a Web server from the Internet. Packets that enter the SFC-enable Domain from the Internet first reach the classifier. The classifier determines which SF should be applied to this packet from the header of the packet, inserts the information into the packet as a Network Service Header (NSH), and then relays the packet. For example, assume that only SF1 is applied to this packet.
[0022]
　When SFF1 receives this packet, it knows that SF1 is applied to this packet from the contents of NSH, and forwards this packet to SF1. SF1 processes this packet and returns it to SFF1. SFF1 forwards this packet to SFF2. In this example, only SF1 is applied to the packet, so SFF2 to SFFn simply relay this packet, and finally this packet reaches the Web server.
[0023]
　In SFC having such an architecture, SFs such as WAF and load balancer are prepared from the viewpoint of network operators and service providers. That is, what kind of packet is targeted for SFC is determined by the intention of the network operator or the service provider.
[0024]
　On the other hand, what is described below is an architecture for causing one or more functions desired by a service user to act on a packet desired by the service user in a service for forwarding packets in a network. is there. In the present embodiment, such an architecture is referred to as Application Function Chaining (AFC), and the function operated in the AFC architecture is referred to as Application Function (AF).
[0025]
　[1.2. Specific Description of AFC]
　FIG. 2 is an explanatory diagram showing the architecture of AFC proposed in the embodiment of the present disclosure. The network work area in which AFC can be set is called an AFC domain. Nodes called AFC Ingress and AFC Egress are arranged at the boundary of the AFC domain. AFC Ingress is a node that is an entrance to the AFC domain for data packets to which AFC is applied, and AFC Ingress is a node that is an exit of the AFC domain. The same node may operate as AFC Ingress or as AFC Ingress. Taking the core network of the mobile phone network as an example, it is conceivable that eNB, S-GW or P-GW plays the role of AFC Ingress. In FIG. 2, only one AFC Ingress and one AFC Ingress exist, but a plurality of AFC Ingress may exist.
[0026]
　It is assumed that AFC Ingress and AFC Ingress each have a well-known port as a port used for sending and receiving data packets and a port for sending and receiving control packets. The AFC Manager is a node that manages the AFC in the AFC domain. AFC User is a user who installs AFC in AFC domain. AAA Server is a node that authenticates and authorizes AFC User. There is one or more AF Nodes in the AFC domain. The AF Node is a node capable of executing AF.
[0027]
　A daemon process called AFC Daemon-p is always running in AF Node. It is assumed that the AFC Daemon-p has a well-known port as a port for sending and receiving control packets. In FIG. 2, the description of AFC Daemon-p is omitted. When the AFC User requests the activation of AF, the AFC Daemon-p activates the AFC Daemon as a child process, and then the AFC Daemon processes it. COTS (Commercial off-the-shelf) device is an off-the-shelf communication device, and it is assumed that settings such as parameters can be changed but software cannot be changed. Server is a communication partner of COTS device. The application on the COTS device shall communicate with the application on the Server.
[0028]
　When transmitting data from COTS device to Server, AFC Ingress is an example of the starting node of the present disclosure, and AFC Ingress is an example of the target node of the present disclosure. Further, COTS device is an example of the source node of the present disclosure, and Server is an example of the destination node of the present disclosure.
[0029]
　In an AFC that has branching and merging on the way or an AFC in which the same AF is arranged in a plurality of AF Nodes, the route to which the data packet is transferred may differ for each data packet. The route through which data packets are actually transferred on the AFC is referred to as an AFC path.
[0030]
　(Outline of operation of AFC for COTS device)
　The outline of the procedure for applying AFC to the communication between the application on COTS device and the application on Server is as follows (1) to (8).
[0031]
　(1) The AFC User is installed in the desired AF Node for one or more AFs used in the AFC. This work is called AF Setup.
[0032]
　(2) The AFC User connects the installed AF in a straight line or in a shape with a branch and a confluence, and installs the AFC. AFC Ingress holds AFC configuration information. This work is called AFC Setup. In order to select data packets to which AFC should be applied from the data packets transmitted by the application on COTS device, so-called 5 taples (start point IP address, end point IP address, protocol, start point port number, end point port number) are used. use.
[0033]
　(3) The application on COTS device transmits a data packet by TCP / IP or UDP / IP. This packet is called the original data packet. The original data packet arrives at AFC Ingress. AFC Ingress selects the AFC to be applied by 5 tuples, and adds an IP header, a UDP header, and an AFC header for realizing the AFC to the received data packet. This packet will be referred to as an AFC data packet. FIG. 3 is an explanatory diagram showing the structure of the AFC data packet. Hereinafter, the "IP header" and "UDP header" will refer to the IP header and UDP header added to the original data packet.
[0034]
　(4) AFC Ingress transmits AFC data packets. The AFC data packet passes through the AF Nodes constituting the AFC, and AF is applied to the original data packet in each AF Node. Finally, the AFC data packet reaches the AFC Egress.
[0035]
　(5) AFC Egress deletes the IP header, UDP header, and AFC header from the AFC data packet, extracts the original data packet, and transmits the extracted packet.
[0036]
　(6) Finally, the original data packet reaches the application on the Server.
[0037]
　(7) AFC User deletes AFC that is no longer needed. This operation is called AFC Delete.
[0038]
　(8) AFC User deletes AF that is no longer needed. This operation is called AF Delete.
[0039]
　(Role of field of control packet)
　There are the following 17 types of control packets used in this embodiment. AF Step Request packet, AF Set Response packet, AA Request packet, AA Response packet, AF Invest Request packet, AF Invest Request packet, AF Invest Request packet, AFC Reset Packet, AFC Reset Packet, AFC Reset Packet, AFC Reset Packet, AFC Reset Packet. Request packet, AFC Delete Response packet, AF Delete Request packet, AF Delete Response packet, Road Monitoring Request packet, Load Monitoring Packet, and Feedback packet.
[0040]
　Each field of the control packet has the following roles. The Type field indicates the type of packet. The packet type is roughly classified into a Request packet that requests an operation and a Response packet that is a response packet to the Request packet. The User ID field indicates the identifier of the AFC User. User Credentials provide information for AFC User certification. The information for authentication and authorization is, for example, a user name and a password. The AF Node IP Address field indicates the IP address of the AF Node. In this embodiment, it is assumed that AF is stored in AF Node as an executable file. The AF File Name field indicates the AF executable file name. The AF Parameters field indicates the parameters for invoking AF. The Status field indicates the processing result for the processing request indicated by the Request packet. The AF ID field indicates the AF identifier. The AFC Daemon Data Port field indicates the port number for the AFC Daemon to send and receive AFC data packets. The AFC Daemon Control Port field indicates the port number for the AFC Daemon to send and receive control packets.
[0041]
　The five fields shown below are match fields for selecting the original data packet to which AFC should be applied. The Source IP Address field indicates the starting IP address. The Destination IP Address field indicates the destination IP address. The Protocol field indicates the type of transport layer protocol. The Source Port field indicates the starting port number. The Destination Port field indicates the destination port number.
[0042]
　The Ingress IP Address field indicates the IP address of the AFC Ingress. The Egress IP Address field indicates the IP address of the AFC Egress. The No of AFs field indicates the number of AFs constituting the AFC.
[0043]
　The AF Session Key field indicates the key information shared by the AFC User, AFC Manager, AFC Ingress and AFC daemon with respect to the AF installed by the AFC User. The AF Certificate field indicates the certificate information generated from the AF Session Key. The Next Index Length field indicates the length of the Next Index field. The Next Index field indicates the index of the AF to be applied next among the AFs constituting the AFC (the number indicating the order in the AFC, starting from 0).
[0044]
　The AFC Session Key field indicates the key information shared by the AFC User, AFC Manager and AFC Ingress with respect to the AFC set up by the AFC User. The AFC Certificate field indicates the certificate information generated from the AFC Session Key. The Load field indicates the load of AF Node. The In Timestamp field indicates the time when the AF Node received the AFC data packet. The Out Timestamp field indicates the time when the AF Node transmitted the AFC data packet. The Ingress Out Timestamp field indicates the time when AFC Ingress sent the AFC data packet. The Egress In Timestamp field indicates the time when the AFC Egress received the AFC data packet.
[0045]
　(Role of field of AFC header)
　The header of the data packet in AFC is composed of IP header, UDP header and AFC header. In this embodiment, only the start point IP address (Src IP) field and the end point IP address (Dst IP) field are focused on the IP header. Regarding the UDP header, only the start point port (Src Port) field and the end point port (Dst Port) field are focused on.
[0046]
　ＡＦＣヘッダは以下のフィールドからなる。ＡＦＣ　ＩＤフィールドはＡＦＣの識別子を示す。Ｓｅｑｕｅｎｃｅ　ＮｕｍｂｅｒフィールドはＡＦＣデータパケットのシーケンス番号を示す。シーケンス番号はＡＦＣごとに割り当てられる。Ｉｎｇｒｅｓｓ　Ｏｕｔ　ＴｉｍｅｓｔａｍｐフィールドはＡＦＣ　ＩｎｇｒｅｓｓがＡＦＣデータパケットを送信したときの時刻を示す。Ｆｌａｇｓフィールドにはさまざまなフラグが設定されることができる。本実施形態ではＦｅｅｄｂａｃｋフラグのみを定義する。Ｆｅｅｄｂａｃｋフラグが設定されたＡＦＣデータパケットをＡＦＣ　Ｅｇｒｅｓｓが受信した場合、ＡＦＣ　ＥｇｒｅｓｓはＡＦＣ　ＩｎｇｒｅｓｓにＡＦＣ　Ｆｅｅｄｂａｃｋパケットを送信する。Ｎｏ　ｏｆ　ＡＦｓフィールドはＡＦＣを構成するＡＦの個数を示す。ＡＦ　Ｉｎｄｅｘフィールドは次に適用するＡＦのインデックス（０から始まる）を示す。ＡＦ　Ｎｏｄｅ　ＩＰ　ＡｄｄｒｅｓｓフィールドはＡＦ　ＮｏｄｅのＩＰアドレスを示す。Ｄａｅｍｏｎ　Ｄａｔａ　Ｐｏｒｔフィールドは、ＡＦＣ　ＤａｅｍｏｎがＡＦＣデータパケットの送受信に使用するポート番号を示す。ＡＦ　ＩＤフィールドはＡＦの識別子を示す。ＡＦ　Ｃｅｒｔｉｆｉｃａｔｅフィールドは、ＡＦＣ　Ｕｓｅｒが設置したＡＦに関してＡＦＣ　ＵｓｅｒとＡＦＣ　Ｄａｅｍｏｎとの間で共有する鍵情報から生成した証明書情報を示す。Ｎｅｘｔ　Ｉｎｄｅｘ　ＬｅｎｇｔｈフィールドはＮｅｘｔ　Ｉｎｄｅｘフィールドの長さを示す。Ｎｅｘｔ　Ｉｎｄｅｘフィールドは次に適用するＡＦのインデックスを示す。このフィールドは「条件式：ＡＦのインデックス」という対からなる。Ｉｎ　ＴｉｍｅｓｔａｍｐフィールドはＡＦ　ＮｏｄｅがＡＦＣデータパケットを受信したときの時刻を示す。Ｏｕｔ　ＴｉｍｅｓｔａｍｐフィールドはＡＦ　ＮｏｄｅがＡＦＣデータパケットを送信したときの時刻を示す。Ｅｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓはＡＦＣ　ＥｇｒｅｓｓのＩＰアドレスを示す。Ｅｇｒｅｓｓ　Ｄａｔａ　ＰｏｒｔフィールドはＡＦＣ　ＥｇｒｅｓｓがＡＦＣデータパケットを受信するためのポート番号を示す。
[0047]
　(Role of the field of the management table) The
　AFC Daemon holds the Daemon AF Table and the Daemon AFC Table as the management table. The AFC Manager holds a Manager User Table, a Manager AFC Table, a Manager AF Table, a Manager AF List, and a Manager AF Node Table as management tables. As a management table, AFC Ingress holds Ingress AFC Table, Ingress AF Table, Ingress AF Node Table, Ingress AFC Path List Table, Ingress AFC Path List Entry and Ingress.
[0048]
　管理用テーブルの各フィールドは以下の役割を持つ。ｐｔｒ　ｔｏ　ｎｅｘｔ　Ｕｓｅｒ　Ｔａｂｌｅフィールドは他のＵｓｅｒ　Ｔａｂｌｅを指すポインタを示す。ｐｔｒ　ｔｏ　ＡＦ　Ｔａｂｌｅフィールドは他のＡＦ　Ｔａｂｌｅを指すポインタを示す。ｐｔｒ　ｔｏ　ｎｅｘｔ　ＡＦ　Ｔａｂｌｅフィールドは他のＡＦ　Ｔａｂｌｅを指すポインタを示す。Ｕｓｅｒ　ＩＤフィールドはＡＦＣ　Ｕｓｅｒの識別子を示す。Ｔｉｍｅ　ｔｏ　ＬｉｖｅフィールドはＡＦＣ　Ｕｓｅｒに関連する設定情報がタイムアウトするまでの時間を示す。ＡＦ　ＩＤフィールドはＡＦの識別子を示す。ＡＦ　Ｉｎ　ＰｏｒｔフィールドはＡＦに元データパケットを入力する際に使用するポート番号を示す。ＡＦ　Ｏｕｔ　ＰｏｒｔフィールドはＡＦから処理済みの元データパケットを受け取る際に使用するポート番号を示す。ＡＦＣ　Ｓｅｓｓｉｏｎ　ＫｅｙはＡＦＣ　Ｕｓｅｒが設置したＡＦＣに関してＡＦＣ　ＵｓｅｒとＡＦＣ　Ｍａｎａｇｅｒとが共有する鍵情報を示す。ＡＦ　Ｓｅｓｓｉｏｎ　Ｋｅｙフィールドは、ＡＦＣ　Ｕｓｅｒが設置したＡＦに関してＡＦＣ　Ｕｓｅｒ、ＡＦＣ　Ｍａｎａｇｅｒ、ＡＦＣ　ＩｎｇｒｅｓｓおよびＡＦＣ　ｄａｅｍｏｎが共有する鍵情報を示す。ＡＦ　Ｎｏｄｅ　ＩＰ　ＡｄｄｒｅｓｓフィールドはＡＦ　ＮｏｄｅのＩＰアドレスを示す。Ｄａｅｍｏｎ　Ｄａｔａ　ＰｏｒｔフィールドはＡＦＣ　ＤａｅｍｏｎがＡＦＣデータパケットの送受信に使用するポート番号を示す。Ｄａｅｍｏｎ　ＣｏｎｔｒｏｌＰｏｒｔフィールドはＡＦＣ　Ｄａｅｍｏｎが制御パケットの送受信に使用するポート番号を示す。Ｉｎｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓフィールドはＡＦＣ　ＩｎｇｒｅｓｓのＩＰアドレスを示す。Ｅｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓフィールドはＡＦＣ　ＥｇｒｅｓｓのＩＰアドレスを示す。Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒフィールドは直近に受信したＡＦＣデータパケットのシーケンス番号を示す。Ｎｅｘｔ　Ｉｎｄｅｘ　ＬｅｎｇｔｈフィールドはＮｅｘｔ　Ｉｎｄｅｘフィールドの長さを示す。Ｎｅｘｔ　Ｉｎｄｅｘフィールドは次に適用するＡＦのインデックスを示す。このフィールドは「条件式：ＡＦのインデックス」という対からなる。ＬｏａｄフィールドはＡＦ　Ｎｏｄｅの負荷を示す。ｐｔｒ　ｔｏ　Ｎｅｘｔ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｔａｂｌｅフィールドは他のＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｔａｂｌｅを指すポインタを示す。ｐｔｒ　ｔｏ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　ＥｎｔｒｙフィールドはＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｅｎｔｒｙを指すポインタを示す。ＡＦＣ　Ｐａｔｈ　ＩＤフィールドはＡＦＣパスの識別子を示す。ｐｔｒ　ｔｏ　ｎｅｘｔ　ＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｅｎｔｒｙフィールドは他のＡＦＣ　Ｐａｔｈ　Ｌｉｓｔ　Ｅｎｔｒｙを指すポインタを示す。ｐｔｒ　ｔｏ　ＡＦ　Ｎｏｄｅ　ＴＳ　ＴａｂｌｅフィールドはＡＦ　Ｎｏｄｅ　ＴＳ　Ｔａｂｌｅを指すポインタを示す。Ｉｎｇｒｅｓｓ　Ｏｕｔ　ＴｉｍｅｓｔａｍｐフィールドはＡＦＣ　ＩｎｇｒｅｓｓがＡＦＣデータパケットを送信したときの時刻を示す。Ｅｇｒｅｓｓ　Ｉｎ　ＴｉｍｅｓｔａｍｐフィールドはＡＦＣ　ＥｇｒｅｓｓがＡＦＣデータパケットを受信したときの時刻を示す。ｐｔｒ　ｔｏ　ｎｅｘｔ　ＡＦ　Ｎｏｄｅ　ＴＳ　Ｔａｂｌｅフィールドは他のＡＦ　Ｎｏｄｅ　ＴＳ　Ｔａｂｌｅへのポインタを示す。Ｉｎ　ＴｉｍｅｓｔａｍｐフィールドはＡＦ　ＮｏｄｅがＡＦＣデータパケットを受信したときの時刻を示す。Ｏｕｔ　ＴｉｍｅｓｔａｍｐフィールドはＡＦ　ＮｏｄｅがＡＦＣデータパケットを送信したときの時刻を示す。
[0049]
　(Security Measures) In
　order to maintain security, the following is assumed in this embodiment. It is assumed that a secure communication path such as TLS (Transport Layer Security) is preset between the AFC Manager and the AAA server. It is assumed that a TLS connection can be established between the AFC User and the AFC Manager, between the AFC Manager and the AFC Ingress, between the AFC Ingress and the AFC Ingress, and between the AFC Manager and the AF Node, if necessary. .. In addition, by setting parameters in COTS device, it is possible to establish a secure communication path between COTS device and AFC Ingress by an authentication method such as WPA2 (Wi-Fi Protected Access 2) in Wi-Fi.
[0050]
　FIG. 4 is an explanatory diagram showing security measures in the installation of AF. The AFC User establishes a TLS connection with the AFC Manager (step S101). When the AFC User installs the AF in the AF Node, the AF User transmits an AF installation request packet (AF Set Request packet) including the authentication authorization information (User Credential) to the AFC Manager (step S102).
[0051]
　The AFC Manager transmits an authentication authorization request packet (AA Request packet) including a User Credential to the AAA server (step S103). The AAA Server verifies the User Credentials and certifies the AFC User (step S104). AFC User certification authorization is verification of the authenticity of AFC User and verification of whether AFC User has the authority to install and use a specific AF in a specific AF Node.
[0052]
　The AAA Server returns the result of the certification authorization to the AFC Manager (step S105). If the certification authorization is successful, the AFC Manager generates an AF Session Key (step S106). Any method may be used to generate the AF Session Key. The AF Session Key may be, for example, a random number having an arbitrary length.
[0053]
　Subsequently, the AFC Manager establishes a TLS connection with the AFC Daemon (step S107). The AFC Manager transmits an AF activation request packet (AF Invest Request packet) including an AF Session Key to the AFC Daemon (step S108).
[0054]
　The AFC Daemon activates the specified AF (omitted in FIG. 4). Then, the AFC Daemon shares the AF Session Key by saving the AF Session Key (step S109).
[0055]
　The AFC Daemon returns the AF activation result to the AFC Manager (step S110). The AFC Manager subsequently disconnects the TLS connection with the AFC Daemon (step S111).
[0056]
　Subsequently, the AFC Manager returns a packet (AF Session Response packet) containing the AF Session Key and the result of the AF installation to the AFC User (step S112). The AFC User disconnects the TLS connection with the AFC Manager (step S113). Then, the AFC User shares the AF Session Key by saving the AF Session Key (step S114).
[0057]
　As described above, only authorized AFC User can set and use AF. The authority of AFC User to install and use AF is shared among AFC User, AFC Manager and AFC Daemon as information called AF Session Key. AF Session Key is generated for each installed AF.
[0058]
　(Security Measures for AFC Installation)
　Next, security measures for AFC installation will be described. FIG. 5 is an explanatory diagram showing security measures in the installation of AFC.
[0059]
　By the process shown in FIG. 4, the AFC User and the AFC Manager share the AF Session Key for all the AFs constituting the AFC to be installed (step S121).
[0060]
　The AFC User establishes a TLS connection with the AFC Manager (step S122). Subsequently, the AFC User transmits an AFC installation request packet (AFC Setup Request packet) including an AF Certificate related to all AFs constituting the AFC to the AFC Merger (step S123). AF Certificate is certificate information generated from AF Session Key. As an example of the AF Certificate generation method, a method such as using a bit string obtained by applying a hash function on a bit string in which the AF identifier and the AF Session Key are concatenated can be considered.
[0061]
　The AFC Manager verifies the AF Certificate using the AF Session Key that it holds for all AFs included in the AFC Session Request (step S124). If the AF Certificate is successfully verified for all AFs included in the AFC Session Request, the AFC Manager generates an AFC Session Key (step S125). Any method may be used to generate the AFC Session Key. For example, the AFC Session Key may be a random number of any length.
[0062]
　Subsequently, the AFC Manager establishes a TLS connection with the AFC Ingress (step S126). Then, the AFC Manager transmits an AFC installation request packet (AFC Installation Request packet) including an AF Session Key and an AFC Session Key related to all AFs included in the AFC Set Request to the AFC Ingress (step S127).
[0063]
　AFC Ingress saves AFC installation information (omitted in FIG. 5), and shares AF Session Key by saving AF Session Key and AFC Session Key for all AFs constituting AFC (step S128).
[0064]
　Subsequently, AFC Ingress returns the result of the AFC installation process to the AFC Manager (step S129). The AFC Manager disconnects the TLS connection with the AFC Ingress (step S130).
[0065]
　The AFC Manager returns the result of the AFC installation process and the packet containing the AFC Session Key (AFC Session Response packet) to the AFC User (step S131). The AFC User disconnects the TLS connection with the AFC Manager (step S132). Then, the AFC User shares the AF Session Key by saving the AFC Session Key (step S133).
[0066]
　As described above, when the AFC User installs the AFC, the authority of the AFC User is confirmed. AFC Session Keys are generated for each AFC and are shared among AFC User, AFC Manager and AFC Ingress. The AF Session Key will also be shared with AFC Ingress in addition to AFC User, AFC Manager and AFC Daemon.
[0067]
　(Security Measures for Data Packet Transfer)
　Next, security measures for data packet transfer will be described. FIG. 6 is an explanatory diagram showing security measures in data packet transfer.
[0068]
　By the processing shown in FIGS. 4 and 5, the AF Session Key for each AF constituting the AFC is shared with the AFC User, the AFC Daemon, and the AFC Ingress (step S141).
[0069]
　The COTS device transmits the original data packet (step S142). When AFC Ingress receives the original data packet and transmits the AFC data packet, it generates an AF Certificate from the AF Session Key for each AF constituting the AFC and includes it in the AFC header (step S143). As an example of the AF certificate generation method, a method such as a bit string obtained by applying a hash function to a bit string in which a sequence number, an AF identifier, and an AF Session Key are concatenated can be considered.
[0070]
　Subsequently, AFC Ingress transmits an AFC data packet to the AFC Daemon (step S144). The AFC Daemon verifies the AF Certificate for the AF that operates on it (step S145). If the verification is successful, the AFC Daemon applies AF to the AFC data packet (omitted in FIG. 6). The AFC Daemon forwards the AFC data packet to the next AFC Daemon (step S146).
[0071]
　After that, the same processing is performed in the AFC path. By the above processing, even if the invalid node forges the invalid AFC data packet and sends it to the AF Node, the AFC Daemon can detect that it is the invalid AFC data packet. When AFC Ingress receives the original data packet and transmits the AFC data packet, it increments the sequence number for each packet and includes it in the AFC header. Sequence numbers are assigned to each AFC. On the other hand, the AFC Daemon records the sequence number of the received AFC data packet. Therefore, even if an unauthorized node eavesdrops and stores a legitimate AFC data packet and then transmits the eavesdropped packet (replay attack), the AFC Daemon can detect that it is a replay attack. If the sequence number is also used when generating the AF Certificate as described above, the forged sequence number can also be detected.
[0072]
　(Security Measures for AFC Deletion)
　Next, security measures for AFC deletion will be described. FIG. 7 is an explanatory diagram showing security measures for deleting AFC.
[0073]
　By the process shown in FIG. 5, AFC User, AFC Manager, and AFC Ingress share the AFC Session Key for the AFC to be deleted (step S151).
[0074]
　The AFC User transmits an AFC deletion request packet (AFC Delete Request packet) including an AFC Certificate to the AFC Manager (step S152). As an example of the method of generating the AFC Certificate, a method such as using a bit string obtained by applying a hash function on a bit string obtained by concatenating the AFC identifier and the AFC Session Key can be considered.
[0075]
　The AFC Manager verifies the AFC Certificate and confirms that the AFC User has authority over the target AFC (step S153). The AFC Manager then forwards the AFC Delete Request packet to AFC Ingress (step S154).
[0076]
　AFC Ingress verifies the AFC Certificate (step S155), confirms that the AFC User has authority over the target AFC, and deletes the AFC settings (omitted in FIG. 7). Subsequently, AFC Ingress returns the response packet to the AFC Manager (step S156). The AFC Manager forwards the response packet to the AFC User (step S157). As described above, only the authorized AFC User can delete the AFC.
[0077]
　(Security Measures for AF Deletion)
　Next, security measures for AF deletion will be described. FIG. 8 is an explanatory diagram showing security measures for deleting AF.
[0078]
　By the process shown in FIG. 4, the AFC User, the AFC Manager, and the AFC Daemon share the AF Session Key regarding the AF to be deleted (step S161).
[0079]
　The AFC User transmits an AF deletion request packet (AF Delete Request packet) including an AF Certificate relating to the AF to be deleted to the AFC Manager (step S162). As an example of the AF certificate generation method, a method such as using a bit string obtained by applying a hash function on a bit string in which the AF identifier and the AF Session Key are concatenated can be considered.
[0080]
　The AFC Manager verifies the AF Certificate using the AF Session Key (step S163) and deletes the relevant information if the verification is successful (omitted in FIG. 8). The AFC Manager then forwards the AF Delete Request packet to the AFC Daemon (step S164).
[0081]
　AFC Daemon verifies AF Certificate using AF Session Key (step S165), and if the verification is successful, deletes AF and deletes related information (omitted in FIG. 8). AFC Ingress returns the response packet to the AFC Manager (step S166). The AFC Manager forwards the response packet to the AFC User (step S167). As described above, only the authorized AFC User can delete the AF.
[0082]
　(Installation of AF-1 in AF Node-1)
　Next , installation of AF (AF-1) in a certain AF Node (referred to as AF Node-1) will be described. FIG. 9 is an explanatory diagram showing a procedure when the AFC User-1 installs the AF-1 on the AF Node-1. The identifier of AFC User-1 is USRID-1. Let the credential of AFC User-1 be USRCred-usr1. The executable file name of AF-1 is FName-af1. Let Param-af1 be the parameter when executing AF-1. Let the IP address of AF Node-1 be IP-afn1.
[0083]
　First, AFC User-1 establishes a TLS connection with AFC Manager (step S171).
[0084]
　Subsequently, the AFC User-1 transmits the AF Setup Request packet shown in FIG. 10 to the AFC Manager (step S172). The value of each field of the AF Set Request packet is as follows. “AF Set Request” is set in the Type field. USRID-1 is set in the User ID field. USRCred-usr1 is set in the User Credentialal field. IP-afn1 is set in the AF Node IP Address field. FName-af1 is set in the AF File Name field. Param-af1 is set in the AF Parameter field.
[0085]
　When the AFC Manager receives the AF Setup Request packet, it transmits the AA Request packet shown in FIG. 12 to the AAA Server (step S173). The value of each field of the AA Request packet is as follows. "AA Request" is set in the Type field. In the User ID field, USRID-1, which is the value of the User ID field of the AF Set Request packet, is set. In the User Credentialal field, USRCred-usr1, which is the value of the User Credentialal field of the AF Setup Request packet, is set. In the AF Node IP Address field, IP-afn1, which is the value of the AF Node IP Address field of the AF Set Request packet, is set. In the AF File Name field, FName-af1, which is the value of the AF File Name field of the AF Set Request packet, is set.
[0086]
　When the AAA Server receives the AA Request packet, it uses the value in the User Credentialal field to check if User-1 has the authority to activate AF-1 in AF Node-1. If the confirmation is successful, the AA Server transmits the AA Response packet shown in FIG. 13 to the AFC Manager (step S174). The value of each field of the AA Response packet is as follows. "AA Response" is set in the Type field. In the Status field, "OK" indicating the success of authentication and authorization is set. In the User ID field, USRID-1, which is the value of the User ID field of the AA Request packet, is set.
[0087]
　When the AFC Manager receives the AA Response packet, it knows the IP address of AF Node-1 from the AF Node IP address field of the AF Node Request packet, and establishes a TLS connection with AFC Node-1-p on AF Node-1. The process is started (step S175). When the AFC Daemon-1-p receives the TLS connection establishment request, it generates the child process AFC Daemon-1 (step S176). Subsequent processing is performed by AFC Daemon-1. As a result, a TLS connection is established between the AFC Manager and the AFC Daemon-1 (step S177).
[0088]
　Subsequently, the AFC Manager assigns AFID-1 as an identifier to AF-1 and generates AFSKay-af1 as a session key for AF-1. Next, the AFC Manager transmits the AF Invoke Request packet shown in FIG. 14 to the AFC Daemon-1 (step S178). The value of each field of the AF Invoke Request packet is as follows. “AF Invest Request” is set in the Type field. In the User ID field, USRID-1, which is the value of the User ID field of the AF Set Request packet, is set. AFID-1 is set in the AF ID field. AFSKey-af1 is set in the AF Session Key field. In the AF File Name field, FName-af1, which is the value of the AF File Name field of the AF Set Request packet, is set. In the AF Parameters field, Param-af1, which is the value of the AF Parameters field of the AF Setup Request packet, is set.
[0089]
　When the AFC Daemon-1 receives the AF Invoke Request packet, it activates the executable file specified by the AF File Name field and sets it as AF-1 (step S179). At that time, the AFC Daemon-1 connects the standard input and the standard output of the AF-1 to its own ports, InPt-af1 and OutPt-af1, respectively. Next, the AFC Daemon-1 generates DPt-afcd1 as a port for transmitting and receiving AFC data packets, and CPt-afcd1 as a port for transmitting and receiving control packets.
[0090]
　The AFC Daemon-1 then creates the Daemon AF Table shown in FIG. The values ​​of each field of Daemon AF Table are as follows. [Null] is set in the ptr to next AF Table field. AFID-1, which is the value of the AF ID field of the AF Invoke Request packet, is set in the AF ID field. InPt-af1 is set in the AF In Port field. OutPt-af1 is set in the AF Out Port field. In the User ID field, USRID-1, which is the value of the USER ID field of the AF Invoke Request packet, is set. AFSKey-af1, which is the value of the AF Session Key field of the AF Invoke Request packet, is set in the AF Session Key field.
[0091]
　Next, the AFC Daemon-1 transmits the AF Invoke Response packet shown in FIG. 15 to the AFC Manager (step S180). The value of each field of the AF Invoke Response packet is as follows. “AF Invoke Response” is set in the Type field. "OK" indicating the success of the process is set in the Status field. In the User ID field, USRID-1, which is the value of the User ID field of the AF Invoke Request packet, is set. AFID-1, which is the value of the AF ID field of the AF Invoke Request packet, is set in the AF ID field. DPt-afcd1 is set in the AFC Daemon Data Port field. CPt-afcd1 is set in the AFC Daemon Data Port field.
[0092]
　When the AFC Manager receives the AF Invoke Response packet, it creates the Manager User Table, Manager AF Table, and Manager AF Node Table shown in FIG.
[0093]
　The value of each field of Manager User Table is as follows. [Null] is set in the ptr to next User Table. In the User ID field, USRID-1, which is the value of the User ID field of the AF Set Request packet, is set. In the Time to Live field, TTL-usr1, which is the time until the setting information of AFC User-1 times out, is set. A pointer to the AF Table is set in the ptr to AF Table field. [Null] is set in the ptr to AFC Table field.
[0094]
　The values ​​of each field of Manager AF Table are as follows. [Null] is set for ptr to next AF Table. AFID-1 is set in the AF ID field. AFSKey-af1 is set in the AF Session Key field. A pointer to the Manager AF Node Table is set in the ptr to AF Node Table field.
[0095]
　The values ​​of each field of Manager AF Node Table are as follows. [Null] is set for ptr to next AF Node Table. In the AF Node IP Address field, IP-afn1, which is the value of the AF Node IP Address field of the AF Set Request packet, is set. In the Daemon Data Port field, DPt-afcd1 which is the value of the Daemon Data Port field of the AF Invoke Response packet is set. In the Daemon Control Port field, CPt-afcd1 which is the value of the Daemon Control Port field of the AF Invoke Response packet is set.
[0096]
　When the AFC Manager receives the AF Invoke Response packet, it disconnects the TLS connection with the AFC Daemon-1 (step S181).
[0097]
　Subsequently, the AFC Manager transmits the AF Setup Response packet shown in FIG. 11 to the AFC User-1 (step S182). The value of each field of the AF Setup Response packet is as follows. “AF Set Response” is set in the Type field. "OK" indicating the success of the process is set in the Status field. In the User ID field, USRID-1, which is the value of the User ID field of the AF Set Request packet, is set. AFID-1, which is the value of the AF ID field of the AF Invoke Response packet, is set in the AF ID field. AFSKey-af1 is set in the AF Session Key field.
[0098]
　Upon receiving the AF Setup Response packet, the AFC User-1 disconnects the TLS connection with the AFC Merger (step S183).
[0099]
　(Installation of AF-2 on AF Node-2 and installation of AF-3 on AF Node-3)
　Next, AFC User-1 installs AF-2 on AF Node-2 in the same procedure as above. It is assumed that AF-3 is installed in AF Node-3. The executable file name of AF-2 is FName-af2. The parameter for executing AF-2 is Param-af2. It is assumed that AFID-2 is assigned as the identifier of AF-2. The IP address of AF Node-2 is IP-afn2. The AFC Daemon operating in AF Node-2 is referred to as AFC Daemon-2. It is assumed that InPt-af2 and OutPt-af2 are assigned as ports for AFC Daemon-2 to exchange data with AF-2. It is assumed that AFSKey-af2 is generated as an AF Session Key for AF-2. The executable file name of AF-3 is FName-af3. The parameter for executing AF-3 is Param-af3. It is assumed that AFID-3 is assigned as an identifier of AF-3. The IP address of AF Node-3 is IP-afn3. The AFC Daemon operating in the AF Node-3 is referred to as the AFC Daemon-3. It is assumed that InPt-af3 and OutPt-af3 are assigned as ports for the AFC Daemon-3 to exchange data with the AF-3. It is assumed that AFSKey-af3 is generated as an AF Session Key for AF-3.
[0100]
　Then, the AFC Daemon-2 on the AFC Node-2 and the AFC Daemon-3 on the AFC Node-3 hold the Daemon AF Table shown in FIGS. 18 and 19, respectively. The AFC Manager also holds the table shown in FIG. For the table shown in FIG. 17, FIG. 20 shows the Manager AF Table for AF-2, the Manager AF Table for AF-3, the Manager AF Node Table for AF Node-2, and the AF Node-3. Manager AF Node Table has been added.
[0101]
　(Installation of linear AFC: AFC-1)
　AFC User-1 has already installed AF-1, AF-2 and AF-3 at this point. The IP address of the Server that the COTS device communicates with is IP-svr, and the port number used by the application on the Server is Pt-svr. The IP address of AFC Ingress is IP-ingress. Let the IP address of AFC Egress be IP-egress. AFC User-1 wants to apply a linear AFC (called AFC-1) of AF1 → AF3 to a data packet whose end point IP address is IP-svr and whose end point port number is Pt-svr. FIG. 21 is an explanatory diagram showing an installation procedure of AFC-1. FIG. 22 is an explanatory diagram showing the path of AFC-1.
[0102]
　AFC User-1 establishes a TLS connection with the AFC Manager (step S191).
[0103]
　The AFC User-1 transmits the AFC Setup Request packet shown in FIG. 23 to the AFC Manager (step S192). The value of each field of the AFC Setup Request packet is as follows. "AFC Setup Request" is set in the Type field. USRID-1 is set in the User ID field. The next five fields are match fields for identifying the source data packet to which the AFC is applied. If the values ​​of the corresponding fields of the original data packet all match the values ​​of this match field, AFC is applied to the original data packet. Since the value of the Source IP Address field is [any], the value of the start point IP address of the original data packet satisfies the condition in any case. Since the value of the Destination IP Address field is IP-svr, the condition is satisfied only when the value of the end point IP address of the original data packet is IP-svr. Since the value of the Source Port field is [any], the starting port number of the original data packet satisfies the condition in any case. Since the value of the Destination Port field is Pt-svr, the condition is satisfied only when the destination port number of the original data packet is Pt-svr. Since the value of the Protocol field is UDP, the condition is satisfied only when the transport layer protocol of the data packet is UDP. Next, IP-ingress, which is the IP address of AFC Ingress, is set in the Ingress IP Address field. The IP-egress, which is the IP address of AFC Egress, is set in the Egress IP Address field. In the No of AFs field, 2 which is the number of AFs constituting the AFC is set. The four fields that follow contain information about AF-1. AFID-1 is set in the AF ID field Is done. AFCert-af1 which is the certificate information generated by using AFSkey-af1 is set in the AF Certificate field. The Next Index Length field is set to NodeLen-1, which indicates the length of the Next Index field. In the Next Index field, it is shown that the execution result of AF-1 is AF (AF-3) in which Index is 1 in any case. The following four fields that follow contain information about AF-3. AFID-3 is set in the AF ID field. AFCert-af3, which is the certificate information generated by using AFSKay-af3, is set in the AF Certificate field. In the Next Index Length field, CondLen-3 indicating the length of the Next Index field is set. The value of the Next Index field indicates that the next execution result of AF-3 is AF in which Index is 2. Since this value is equal to the value in the No of AFs field, Index 2 means AFC Egress.
[0104]
　When the AFC Manager receives the AFC Set Request packet from the AFC User-1, the AFC User-1 has the AF-1 and AF-3 based on the AF Certificate field value for AF-1 and the AF Certificate field value for AF-3. Make sure you have the authority to use. Next, the AFC Manager assigns AFCID-1 as an identifier to the AFC (AFC-1) to be installed. The AFC Manager also generates AFCSKey-affc1, which is the key information shared with the AFC User-1 regarding the AFC-1.
[0105]
　The AFC Manager then holds the table shown in FIG. This is the one shown in FIG. 20 with the addition of the Manager AFC Table and the Manager AF List. The values ​​of each field of Manager AFC Table are as follows. [null] is set in the ptr to next AFC Table field. AFCID-1 is set in the AFC ID field. IP-ingress is set in the Ingress IP Address field. AFCSKey-affc1 is set in the AFC Session Key field. A pointer to the Manager AF List is set in the ptr to AF List field. The values ​​of each field of Manager AF List are as follows. The value of the No of AFs field is set to 2, which is the value of the No of AFs field of the AFC Setup Request packet. Subsequently, AFID-1 and AFID-3, which are the values ​​of the two AF ID fields of the AFC Set Request packet, are set in the following two fields.
[0106]
　The AFC Manager then establishes a TLS connection with AFC Ingress (step S193).
[0107]
　Next, the AFC Manager transmits the AFC Installation Request packet shown in FIG. 26 to the AFC Ingress (step S194). The value of each field of the AFC Installation Request packet is as follows. "AFC Installation Request" is set in the Type field. In the User ID field, USRID-1, which is the value of the User ID field of the AFC Setup Request packet, is set. AFCID-1 is set in the AFC ID field. AFCSKey-affc1 is set in the AFC Session Key field. The next five fields are match fields for identifying data packets to which AFC is applied. Set the values ​​of the corresponding fields in the AFC Setup Request packet to these fields. IP-ingress is set in the Ingress IP Address field. IP-egress is set in the Egress IP Address field. In the No of AFs field, the value 2 of the No of AFs field of the AFC Setup Request packet is set. The eight fields that follow are information about AF-1. AFID-1 is set in the AF ID field. In the AF Session Key field, AFSKey-af1, which is the value of the AF Session Key field of the Manager AF Table with respect to AF-1, is set in the table shown in FIG. 20. The value of the Next Index Length field and the value of the Next Index field are set to the values ​​of the corresponding fields of the received AFC Set Request packet. The No of AF Nodes field represents the number of AF Nodes on which AF-1 is installed. In this example, 1 is set. In the AF Node IP Address field , In the table shown in FIG. 20, IP-afn1, which is the value of the AF Node IP Address field of the Manager AF Node Table with respect to AF-1, is set. In the AFC Daemon Data Port field, DPt-afcd1 which is the value of the Daemon Data Port field of the Manager AF Node Table related to AF-1 is set in the table shown in FIG. 20. In the AFC Daemon Control Port field, CPt-afcd1, which is the value of the Daemon Control Port field of the Manager AF Node Table related to AF-1, is set in the table shown in FIG. 20. The eight fields that follow are information about AF-3. These fields are set in the same manner as the information regarding AF-1.
[0108]
　Upon receiving the AFC Installation Request packet, the AFC Ingress holds the Ingress AFC Table, Ingress AF Table, and Ingress AF Node Table shown in FIG. 28. Ingress AFC Table is assigned to each AFC. [null] is set in the ptr to next AFC Table field. From the AFC ID field to the AFC Session Key field, the value of the corresponding field of the AFC Installation Request packet is set. 0 is set as the initial value in the Sequence Number field. In the ptr to AF Table field, a pointer to the Ingress AF Table with respect to the first AF constituting the AFC is set. Ingress AF Table is assigned to each AF. In this example, AF-1 and AF-3 are assigned Ingress AF Table, respectively. The values ​​of each field of Ingress AF Table are as follows. A pointer to the Ingress AF Table of AF-3 is set in the ptr to next AF Table field of the Ingress AF Table of AF-1. [Null] is set in the ptr to next AF Table field of the Ingress AF Table of AF-3. From the AF ID field to the Next Index field, the value of the corresponding field of the AFC Installation Request packet is set. Ingress AF Node Table is assigned to each AF Node. In this example, Ingress AF Node Table is assigned to AF Node-1 and AF Node-3, respectively. The value of each field is as follows. [Null] is set in the ptr to next AF Node Table field. AF From the Node IP Address field to the Daemon Control Port field, the value of the corresponding field of the AFC Installation Request packet is set. The value of the Load field is indefinite ([undef]) at this point.
[0109]
　Next, AFC Ingress transmits the AFC Installation Response packet shown in FIG. 27 to the AFC Manager (step S195). The value of each field of the AFC Installation Response packet is as follows. "AFC Installation Response" is set in the Type field. "OK" indicating the success of the process is set in the Status field. In the User ID field, USRID-1, which is the value of the User ID field of the AFC Installation Request packet, is set. In the AFC ID field, AFCID-1, which is the value of the AFC ID field of the AFC Installation Request packet, is set.
[0110]
　When the AFC Manager receives the AF Installation Response packet, it disconnects the TLS connection with the AFC Ingress (step S196).
[0111]
　Next, the AFC Manager transmits the AFC Setup Response packet shown in FIG. 24 to the AFC User-1 (step S197). The value of each field of the AFC Setup Response packet is as follows. "AFC Setup Response" is set in the Type field. "OK" indicating the success of the process is set in the Status field. In the User ID field, USRID-1, which is the value of the User ID field of the AFC Setup Request packet, is set. In the AFC ID field, AFCID-1, which is the value of the AFC ID field of the AFC Setup Request packet, is set. AFCSKey-affc1 is set in the AFC Session Key field.
[0112]
　When the AFC User-1 receives the AFC Setup Response packet from the AFC Manager, it disconnects the TLS connection with the AFC Manager (step S198).
[0113]
　(Application of AFC-1 to Data Packet)
　Next, it is assumed that the application on COTS device in FIG. 22 transmits the original data packet shown in FIG. 30 to the application on Server. FIG. 29 is an explanatory diagram showing a packet flow when an application on COTS device transmits the original data packet shown in FIG. 30 to an application on Server. It is assumed that the IP address of the COTS device is IP-cots, and the port number used by the application on the COTS device is Pt-cots. It is assumed that the IP address of the Server is IP-svr and the port number used by the application on the Server is Pt-svr. In FIG. 30, only the start point IP address field and the end point IP address field are shown in the IP header, and only the start point port field and the end point port field are shown in the UDP header.
[0114]
　First, the application on the COTS device transmits the original data packet (step S201).
[0115]
　When AFC Ingress receives the original data packet transmitted from the application on the COTS device, it compares the value of the match field of the Ingress AFC Table shown in FIG. 28 with the field of the received data packet. As a result, it can be seen that this original data packet matches the Ingress AFC Table whose AFC ID field value is AFCID-1, so that the AFC Ingress has an IP header and a UDP header at the beginning of the original data packet as shown in FIG. And AFC headers are added to generate AFC data packets. In the IP header, IP-ingress, which is the IP address of AFC Ingress, is set in the Src IP field. In the Dst IP field, IP-afn1, which is the value of the AF Node IP Address field of the Ingress AF Node Table shown in the lower left of FIG. 28, is set. In the UDP header, DPt-ingress, which is a port number for AFC Ingress data packets, is set in the Src Port field. In the Dst Port field, DPt-afcd1 which is the value of the Daemon Data Port field of the Ingress AF Node Table shown in FIG. 28 is set. The value of each field of the AFC header is set as follows with reference to the table shown in FIG. 28. AFCID-1, which is the value of the AFC ID field of the Ingress AFC Table, is set in the AFC ID field. The value of the Access Number field of the Ingress AFC Table is set in the Sequence Number field, and the value of the Sequence Number field of the Ingress AFC Table is incremented. The Ingress Out Timestamp field shows the time when AFC Ingress sends an AFC data packet. Set. The No of AFs field is set to 2, which is the value of the No of AFs field of the Ingress AFC Table. 0 is set in the AF Index field. The eight fields that follow are for AF-1. The values ​​of the corresponding fields of the Ingress AF Node Table are set in the AF Node IP Address field and the AFC Daemon Data Port field. The values ​​of the corresponding fields of the Ingress AF Table are set in the AF ID field, the Next Index Length field, and the Next Index field. In the AF Certificate field, the AF Certificate generated by using the AF Session Key field of the Ingress AF Table is set. The values ​​of the In Timestamp field and the Out Timestamp field are undecided ([undef]). The field values ​​for AF-2 are set in the same way. The above AFC data packet reaches AFC Daemon-1 according to the end point address of the IP header and the end point port number of the UDP header (step S202).
[0116]
　Since the value of the AF Index field of the AFC header is 0, the AFC Daemon-1 applies AF (AF-1) having the identifier AFID-1 to the original data packet included in the received AFC data packet. Recognize. The AFC Daemon-1 calculates the AF certificate using the value of the AF Session Key field of the AF Table shown in FIG. 16, and compares this value with the value of the AF Certificate field of the AFC header. If they match, it can be confirmed that this data packet is a legitimate packet to which AFC should be applied. The AFC Daemon-1 calls the AF-1 when it recognizes that it is a legitimate packet to which the AFC should be applied.
[0117]
　The AFC Daemon-1 then searches for the Daemon AFC Table, but at this point the AFC Daemon-1 does not hold the Daemon AFC Table. Therefore, the AFC Daemon-1 creates the Daemon AFC Table shown in FIG. The value of each field is as follows. [null] is set in the ptr to next AFC Table field. AFCID-1, which is the value of the AFC ID field of the AFC header, is set in the AFC ID field. The Value Number field is set to Seq-affc1, which is the value of the Sequence Number field of the AFC header. If there is already a Daemon AFC Table for AFC indicated by the value of the AFC ID field in the AFC header and the value of the Sequence Number field of the AFC header is equal to or less than the value of the Sequence Number field of the Daemon AFC Table, the received AFC data packet. Determines that it is due to the play attack, and AFC Daemon-1 discards the received AFC data packet.
[0118]
　Next, the AFC Daemon-1 inputs the original data packet received from the port indicated by the AF In Port field of the Daemon AF Table shown in FIG. 16 into the called AF-1 (step S203). Next, the AFC Daemon-1 receives the original data packet processed by the AF-1 from the port indicated by the AF Out Port field of the Daemon AF Table. The value of the Next Index field of the AFC header specifies that the index of the next AF is 1 (AF-3) regardless of the execution result of AF-1, so the next AF of AFC Daemon-1 is AF-3. Know that. AFC Daemon-1 refers to the field related to AF-3 in the AFC header, and sets IP-afn3, which is the value of the AF Node IP Address field related to AF-3 in the AFC header, in the Dst IP field of the IP header. Further, AFC Daemon-1 sets DPt-afcd3, which is a value of the AFC Daemon Data Port field related to AF-3 of the AFC header, in the Dst Port field of the UDP header. In addition, AFC Daemon-1 increments the value in the AF Index field. As a result, the header of the AFC data packet is as shown in FIG.
[0119]
　Next, the AFC Daemon-1 transmits this AFC data packet (step S204). At that time, the AFC Daemon-1 sets the time when the AFC data packet is received in the In Timestamp field related to AF-1 of the AFC header, and sets the time when the AFC data packet is transmitted in the Out Timestamp field. This AFC data packet reaches the AFC Daemon-3 according to the end point address of the IP header and the end point port number of the UDP header.
[0120]
　Since the value of the AF Index field of the AFC header of the AFC data packet is 1, the AFC Daemon-3 uses AF (AF-3) whose identifier is AFID-3 as the original data packet included in the received AFC data packet. Recognize that it applies. Like AFC Daemon-1, AFC Daemon-3 confirms that the AFC data packet is legitimate and not that of the replay attack, then calls AF-3 and applies AF-3 to the original data packet ( Step S205). The value of the Next Index field for AF-3 in the AFC header specifies that the index of the next AF is 2 regardless of the execution result of AF-3. Since this value is equal to the value in the No of AFs field of the AFC header, it can be seen that the next node is AFC Egress. Therefore, AFC Daemon-3 sets the value of the AFC Egress IP Address field of the AFC header in the Dst IP field of the IP header, and sets DPt-egress, which is a well-know port for AFC Egress data packets, to the Dst Port field of the UDP header. Set to. In addition, the AFC Daemon-3 increments the value in the AF Index field. As a result, the header of the AFC data packet is as shown in FIG.
[0121]
　The AFC Daemon-3 transmits this AFC data packet (step S206). At that time, the AFC Daemon-3 sets the time when the AFC data packet is received in the In Timestamp field related to AF-3 of the AFC header, and sets the time when the AFC data packet is transmitted in the Out Timestamp field. This AFC data packet reaches the AFC Egress according to the end point address of the IP header and the end point port number of the UDP header.
[0122]
　The AFC Egress extracts the original data packet shown in FIG. 30 from the received AFC data packet and transfers it to the application (step S207). The original data packet reaches the application on the Server according to the destination address of the IP header and the destination port number of the UDP header.
[0123]
　(AFC setting with branching and merging: AFC-2)
　Next, depending on the execution result of AF-1, the AFC path goes directly from AF-1 to AF-3, and from AF-1 to AF-2, AF- Consider the case of setting an AFC (called AFC-2) that branches to the AFC path of proceeding to 3.
[0124]
　FIG. 35 is an explanatory diagram showing the path of AFC-2. The AFC User-1 transmits the AFC Setup Request packet shown in FIG. 36 to the AFC Manager in the same manner as in the procedure shown in FIG. When the AFC Manager receives the AFC Setup Request packet, it transmits the AFC Installation Request packet shown in FIG. 38 to the AFC Ingress. When AFC Ingress receives the AFC Installation Request packet, it transmits the AFC Installation Response packet shown in FIG. 39 to the AFC Manager.
[0125]
　When the AFC Manager receives the AFC Installation Response packet, it transmits the AFC Setup Response packet shown in FIG. 37 to the AFC User-1.
[0126]
　As a result of the above processing, the AFC Manager holds the table shown in FIG. 40. Compared with FIG. 5, Manager AFC Table and anager AF List for AFC-2 are added in FIG. 40. In addition, AFC Ingress holds the table shown in FIG. Compared with FIG. 28, Ingress AFC Table related to AFC-2 and Ingress AF Table and Ingress AF Node Table related to AF (AF-1, AF-2, AF-3) constituting AFC-2 are added to FIG. ing.
[0127]
　(Data transfer in AFC with branching and merging)
　Next, in the AFC with branching and merging shown in FIG. 35, the application on COTS device transmitted the original data packet shown in FIG. 42 to the application on Server. To do.
[0128]
　It is assumed that the IP address of the COTS device is IP-cots, and the port number used by the application on the COTS device is Pt-cots. It is assumed that the IP address of the Server is IP-svr2 and the port number used by the application on the Server is Pt-svr2.
[0129]
　In FIG. 42, the IP header shows only the start point IP address field and the end point IP address field, and the UDP header shows only the start point port field and the end point port field.
[0130]
　When this original data packet reaches AFC Ingress, AFC Ingress compares the value of the match field of the Ingress AFC Table shown in FIG. 41 with the field of the received original data packet. As a result, it can be seen that this original data packet matches the Ingress AFC Table whose AFC ID field value is AFC ID-2. Therefore, as shown in FIG. 43, the AFC Ingress has an IP header and a UDP header at the beginning of the original data packet. And add an AFC header. The value of each field of these headers is set in the same manner as in the procedure described above (Applying AFC-1 to data packets). The above data packet reaches AFC Daemon-1 according to the end point address of the IP header and the end point port number of the UDP header. Similar to the procedure described in (Applying AFC-1 to Data Packet) above, AFC Daemon-1 inputs the original data packet to AF-1 and obtains output data. When the output result satisfies the conditional expression Cond-1, the index of the next AF is 2 (AF-3). As a result, the header shown in FIG. 44 is generated in the same manner as the procedure described in (Application of AFC-1 to data packets) described above.
[0131]
　The AFC Daemon-1 then transmits this packet. This packet arrives at AFC Daemon-3 according to the end address of the IP header and the end port number of the UDP header. AFC Daemon-3 applies AF-3 to the original data packet. On the other hand, if the output result of AF-1 does not satisfy the conditional expression Cond-1, the index of the next AF becomes 1 (AF-2). After that, AFC Daemon-2 applies AF-2 to the original data packet, and subsequently AFC Daemon-3 applies AF-3 to the original data packet.
[0132]
　In either case, the AFC data packet reaches the AFC Egress, and finally the original data packet reaches the application on the Server.
[0133]
　(Deletion of AFC)
　The procedure for deleting AFC-2 after AFC User-1 sets AFC-1 and AFC-2 as described above will be described. FIG. 45 is an explanatory diagram showing the deletion of AFC.
[0134]
　First, AFC User-1 establishes a TLS session with AFC Manager (step S211).
[0135]
　Subsequently, the AFC User-1 transmits the AFC Delete Request packet shown in FIG. 46 to the AFC Manager (step S212). The value of each field of the AFC Delete Request message is as follows. “AFC Delete Request” is set in the Type field. USRID-1 is set in the User ID field. AFCID-2 is set in the AFC ID field. In the AFC Certificate field, AFC Celt-afc2, which is certificate information generated by using AFCSKay-affc2 obtained by receiving the AFC Set Response packet shown in FIG. 37, is set.
[0136]
　When the AFC Manager receives the AFC Delete Request packet, it knows the IP address of the AFC Ingress from the Manager AFC Table shown in FIG. 40 and establishes a TLS connection with the AFC Ingress (step S213).
[0137]
　The AFC Manager then forwards the received AFC Delete Request packet to AFC Ingress (step S214).
[0138]
　When AFC Ingress receives the AFC Delete Request packet, it deletes the table related to AFC-2 from the table shown in FIG. 41. As a result, AFC Ingress retains the table shown in FIG.
[0139]
　Next, AFC Ingress transmits the AFC Delete Response packet shown in FIG. 47 to the AFC Manager (step S215). The value of each field of the AFC Delete Response packet is as follows. "AFC Delete Response" is set in the Type field. "OK" indicating the success of the process is set in the Status field. In the User ID field, USRID-1, which is the value of the User ID field of the AFC Delete Request packet, is set. In the AFC ID field, AFCID-2, which is the value of the AFC ID field of the AFC Delete Request packet, is set.
[0140]
　When the AFC Manager receives the AFC Delete Response packet, it deletes the table related to AFC-2 from the table shown in FIG. 40. As a result, the AFC Manager retains the table shown in FIG.
[0141]
　The AFC Manager then disconnects the TLS connection with the AFC Ingress (step S216).
[0142]
　Next, the AFC Manager transfers the received AFC Delete Response packet to the AFC User-1 (step S217).
[0143]
　When the AFC User-1 receives the AFC Delete Response packet, it disconnects the TLS connection with the AFC Manager (step S218).
[0144]
　(Deletion of AF)
　Subsequently, a procedure for AFC User-1 to delete AF-2 after AFC User-1 deletes AFC-2 as described above will be described. FIG. 48 is an explanatory diagram showing the deletion of AF.
[0145]
　First, AFC User-1 establishes a TLS connection with AFC Manager (step S221).
[0146]
　Subsequently, the AFC User-1 transmits the AF Delete Request packet shown in FIG. 49 to the AFC Manager (step S222). The value of each field of the AF Delete Request packet is as follows. “AF Delete Request” is set in the Type field. USRID-1 is set in the User ID field. AFID-2 is set in the AF ID field. In the AF Certificate field, AFCert-af2, which is certificate information generated by using AFSKey-af2 obtained by the AF Set Response packet received at the time of setting AF-2, is set.
[0147]
　When the AFC Manager receives the AF Delete Request packet, it confirms that the Manager AF List shown in FIG. 25 does not contain AFID-2. Next, the AFC Manager knows the IP address of the AFC Daemon-2 from the Manager AF Node Table and establishes a TLS connection with the AFC Daemon-2 (step S223).
[0148]
　The AFC Manager then forwards the received AF Delete Request packet to the AFC Daemon-2 (step S224).
[0149]
　When the AFC Daemon-2 receives the AF Delete packet, the AFC Daemon-2 stops the execution of the AF-2 (step S225).
[0150]
　Next, the AFC Daemon-2 transmits the AF Delete Response packet shown in FIG. 50 to the AFC Manager (step S226). The value of each field of the AF Delete Response packet is as follows. "AF Delete Response" is set in the Type field. "OK" indicating the success of the process is set in the Status field. USRID-1, which is the value of the User ID field of AF Delete Request, is set in the User ID field. AFID-2, which is the value of the AF ID field of AF Delete Request, is set in the AF ID field.
[0151]
　When the AFC Manager receives the AF Delete Response packet, it disconnects the TLS connection with the AFC Daemon-2 (step S227). As a result, since there is no AF operating on the AFC Daemon-2, the execution of the AFC Daemon-2 also ends. On the other hand, AFC Manager deletes the table related to AF-2 from the table shown in FIG. As a result, the AFC Manager holds the table shown in FIG.
[0152]
　Next, the AFC Manager transfers the received AF Delete Response packet to the AFC User-1 (step S228).
[0153]
　When the AFC User-1 receives the AFC Delete Response packet, it disconnects the TLS connection with the AFC Manager (step S229).
[0154]
　(The same AF is activated by a plurality of AF Nodes.)
　After that, it is assumed that the AFC User-1 deletes the AFC-1, AF-2, and AF-1. Next, it is assumed that AFC User-1 installs AF-4 on AF Node-4-1 and AF Node-4-2 in the same procedure as in FIG. As a result, AFC User-1 learns that AFID-4 has been assigned as an identifier of AF-4, and obtains AFSKey-af4 as AF Session Key.
[0155]
　Further, it is assumed that AFC User-1 installs AF-5 in AF Node-5-1 and AF Node-5-2. As a result, AFC User-1 learns that AFID-5 has been assigned as an identifier of AF-5, and obtains AFSKey-af5 as AF Session Key. Further, AF Node-4-1, AF Node-4-2, AF Node-5-1, and AF Node-5-2 hold the tables shown in FIGS. 53 to 56, respectively, and the AFC Manager is shown in FIG. 57. Hold the table. As shown in FIG. 57, it can be seen that the two Manager AF Tables each have a list consisting of two Manager AF Node Tables. These four Manager AF Node Tables correspond to AF Node-4-1, AF Node-4-2, AF Node-5-1 and AF Node-5-2, respectively.
[0156]
　(AFC-3 setting)
　次に、ＡＦＣ　Ｕｓｅｒ－１は図２１と同様の手順でＡＦ－４とＡＦ－５から構成されるＡＦＣ（ＡＦＣ－３と呼ぶ）を設定するものとする。図５２は、ＡＦＣ－３のｐａｔｈを示す説明図である。また図５８は、ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットを示す説明図である。ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔパケットの各フィールドの値は以下の通りである。Ｔｙｐｅフィールドには「ＡＦＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔ」が設定される。Ｕｓｅｒ　ＩＤフィールドにはＵＳＲＩＤ－１が設定される。これに続く５つのフィールドは、ＡＦＣを適用するデータパケットを識別するためのマッチフィールドである。Ｓｏｕｒｃｅ　ＩＰ　Ａｄｄｒｅｓｓフィールドの値は［ａｎｙ］である。Ｄｅｓｔｉｎａｔｉｏｎ　ＩＰ　Ａｄｄｒｅｓｓフィールドの値はＩＰ－ｓｖｒ３である。Ｓｏｕｒｃｅ　Ｐｏｒｔフィールドの値は［ａｎｙ］である。Ｄｅｓｔｉｎａｔｉｏｎ　Ｐｏｒｔフィールドの値はＰｔ－ｓｖｒ３である。Ｐｒｏｔｏｃｏｌフィールドの値はＵＤＰである。Ｉｎｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓフィールドにはＡＦＣ　ＩｎｇｒｅｓｓのＩＰアドレスであるＩＰ－ｉｎｇｒｅｓｓが設定される。Ｅｇｒｅｓｓ　ＩＰ　ＡｄｄｒｅｓｓフィールドにはＡＦＣ　ＥｇｒｅｓｓのＩＰアドレスであるＩＰ－ｅｇｒｅｓｓが設定される。次に、Ｎｏ　ｏｆ　ＡＦｓフィールドにはＡＦＣを構成するＡＦの個数である２が設定される。これに続く４つのフィールドはＡＦ－４に関する情報を含む。ＡＦ　ＩＤフィールドにはＡＦＩＤ－４が設定される。ＡＦ　ＣｅｒｔｉｆｉｃａｔｅフィールドにはＡＦＳＫｅｙ－ａｆ４を用いて生成した証明書情報であるＡＦＣｅｒｔ－ａｆ４が設定される。Ｎｅｘｔ　Ｉｎｄｅｘ　ＬｅｎｇｔｈフィールドにはＮｅｘｔ　Ｉｎｄｅｘフィールドの長さを示すＣｏｎｄＬｅｎ－４が設定される。Ｎｅｘｔ　Ｉｎｄｅｘフィールドには、ＡＦ－４の実行結果がどのような場合でも次はＩｎｄｅｘが１であるＡＦ（ＡＦ－５）であることが示される。これに続く４つのフィールドはＡＦ－５に関する情報を含む。ＡＦ　ＩＤフィールドにはＡＦＩＤ－５が設定される。ＡＦ　ＣｅｒｔｉｆｉｃａｔｅフィールドにはＡＦＳＫｅｙ－ａｆ５を用いて生成した証明書情報であるＡＦＣｅｒｔ－ａｆ５が設定される。Ｎｅｘｔ　Ｉｎｄｅｘ　ＬｅｎｇｔｈフィールドにはＮｅｘｔ　Ｉｎｄｅｘフィールドの長さを示すＣｏｎｄＬｅｎ－５が設定される。Ｎｅｘｔ　Ｉｎｄｅｘフィールドには、ＡＦ－５の実行結果がどのような場合でも次はＩｎｄｅｘが２であるＡＦ（ＡＦ　Ｅｇｒｅｓｓ）であることが示される。ＡＦＣ　ＭａｎａｇｅｒはＡＦＣ－３に識別子としてＡＦＣＩＤ－３を割り当てる。
[0157]
　FIG. 60 is an explanatory diagram showing an AFC Installation Request packet. The value of each field of the AFC Installation Request packet is as follows. "AFC Installation Request" is set in the Type field. From the User ID field to the No of AFs field, the value of the corresponding field of the AFC Set Request packet is set. The 11 fields that follow are for AF-4. In the AF ID field, AFID-4, which is the value of the AF ID field of the AFC Set Request packet, is set. AFSKey-af4, which is a value of the AF Session Key field of the Manager AF Table shown in FIG. 57, is set in the AF Session Key field. The values ​​of the corresponding fields of the AFC Set Request packet are set in the Next Index Length field and the Next Index field. Since the Manager AF Table shown in FIG. 57 has two Manager AF Node Tables, 2 is set in the No of AF Nodes field. The next three fields are for AF Node-4-1. The values ​​of the corresponding fields of the Manager AF Node Table shown in FIG. 57 are set in the AF Node IP Address field, the AFC Daemon Data Port field, and the AFC Daemon Control Port field. The next three fields are for AF Node-4-2. Each field is set in the same way as the field for AF Node-4-1. The 11 fields that follow are for AF-5. These fields are set in the same way as the fields for AF-4. FIG. 61 shows the above AFC Installation Request package. It is explanatory drawing which shows the AFC installation response packet corresponding to this. Further, FIG. 59 is an explanatory diagram showing an AFC Setup Response packet corresponding to the above AFC Setup Request packet.
[0158]
　As a result of the above processing, the AFC Manager holds the table shown in FIG. 62. As shown in FIG. 62, each of the two Manager AF Tables has a list consisting of two Manager AF Node Tables. On the other hand, AFC Ingress holds the table shown in FIG. 63. As shown in FIG. 63, each of the two Ingress AF Tables has a list consisting of two Ingress AF Node Tables.
[0159]
　(Monitoring the load of AF Node)
　By setting AF Node as described above, AFC Ingress has two AF Nodes that operate AF-4 and two AF Nodes that operate AF-5. Since we recognize that, we monitor the load of each AF Node. FIG. 64 is an explanatory diagram showing monitoring of AF Node load by AFC Ingress.
[0160]
　AFC Ingress transmits the Load Monitoring Request packet shown in FIG. 65 to AF Node-4-1 (step S231). "Load Monitoring Request" is set in the Type field of the Load Monitoring Request packet.
[0161]
　Upon receiving the Load Monitoring Request packet, the AFC Daemon-4-1 transmits the Load Monitoring Response packet shown in FIG. 66 to the AFC Ingress (step S232). The value of each field of the Load Monitoring Packet is as follows. "Load Monitoring Response" is set in the Type field. "OK" indicating the success of the process is set in the Status field. LD-4-1 is set in the Load field, which is a numerical value indicating the degree of load of AF Node-4-1.
[0162]
　Subsequently, AFC Ingress performs the same processing on AF Node-4-2, AF Node-5-1 and AF Node-5-2 as described above (steps S233, S235, S237). AF Node-4-2, AF Node-5-1 and AF Node-5-2 perform the same processing as AF Node-4-1 (steps S234, S236, S238). When the AFC Ingress receives the Load Monitoring Response, it sets the value of the Load field to the Load field of the Ingress AF Node Table, as shown in FIG. 67.
[0163]
　AFC Ingress periodically repeats the above process. As a result, AFC Ingress can periodically acquire the load of each AF Node and update the load information. Here, as the load to be monitored, for example, CPU usage rate, memory usage rate, storage medium usage rate, temperature, number of running AFs, network interface usage rate, network interface data throughput, network of each AF Node Examples include the amount of packets discarded on the interface and the amount of traffic on the network interface. The load related to the network interface may be monitored separately for transmission and reception, and when the AF Node has a plurality of network interfaces, it may be monitored separately for each network interface. Further, the fields of the Load Monitoring Packet or the Load Monitoring Response packet may be set for a plurality of load items.
[0164]
　(Packet transfer in AFC-3 (selection of AF Node by load))
　Next, it is assumed that the application on COTS device in FIG. 52 transmits the original data packet shown in FIG. 68 to the application on Server. It is assumed that the IP address of the COTS device is IP-cots, and the port number used by the application on the COTS device is Pt-cots. It is assumed that the IP address of the Server is IP-svr3 and the port number used by the application on the Server is Pt-svr3. In the original data packet shown in FIG. 68, the IP header shows only the start point IP address field and the end point IP address field, and the UDP header shows only the start point port field and the end point port field.
[0165]
　When this original data packet reaches AFC Ingress, AFC Ingress compares the value of the match field of the Ingress AFC Table shown in FIG. 67 with the field of the received data packet. As a result, it can be seen that this original data packet matches the Ingress AFC Table whose AFC ID field value is AFC ID-3. Therefore, as shown in FIG. 69, the AFC Ingress has an IP header and a UDP header at the beginning of the original data packet. And AFC headers are added to generate AFC data packets. In the IP header, IP-ingress, which is the IP address of AFC Ingress, is set in the Src IP field. Regarding the values ​​of the Road fields of the two Ingress AF Node Tables related to AF-4 shown in FIG. 67, LD-4-1 is set to be smaller than LD-4-2. That is, it is assumed that the load of AF Node-4-1 is lower than the load of AF Node-4-2. Similarly, it is assumed that the load of AF Node-5-1 is lower than the load of AF Node-5-2. Therefore, AFC Ingress selects AF Node-4-1 as the AF Node of AF-4 and AF Node-5-1 as the AF Node of AF-5. IP-afn4-1, which is the IP address of AF Node-4-1, is set in the Dst IP field of the IP header. In the UDP header, DPt-ingress, which is a port number for AFC Ingress data packets, is set in the Src Port field. In the Dst Port field, DPt-afcd4-1 which is a port number for sending and receiving AFC data packets of AFC Daemon-4-1 is set. The value of each field of the AFC header is set in the same manner as the procedure described in (Application of AFC-1 to data packet).
[0166]
　The above AFC data packet reaches AFC Daemon-4-1 according to the end point address of the IP header and the end point port number of the UDP header. AFC Daemon-4-1 applies AF-4 to the original data packet in the same manner as the procedure described in (Applying AFC-1 to the data packet) to obtain output data. AFC Daemon-4-1 generates the header shown in FIG. 70 and transmits this packet. The above AFC data packet reaches AFC Daemon-5-1 according to the end point address of the IP header and the end point port number of the UDP header. AFC Daemon-5-1 applies AF-5 to the original data packet in the same manner as the procedure described in (Applying AFC-1 to data packet) to obtain output data. The AFC Daemon-5-1 generates the header shown in FIG. 71 and transmits this packet. The above AFC data packet reaches the AFC Egress according to the end point address of the IP header and the end point port number of the UDP header. AFC Egress extracts the original data packet from the received AFC data packet and transmits this original data packet to the Sever.
[0167]
　(Packet transfer in AFC-3 (round robin, random)) In the
　above example, when the original data packet transmitted by the application on COTS device arrives at AFC Ingress, AFC Ingress is based on the load of each AF Node. The AF Node that constitutes the AFC is selected. As another method, a method of selecting AF Node in round robin is also conceivable. In this example, (AF Node-4-1, AF Node-5-1), (AF Node-4-1, AF Node-5-2), (AF Node-4-2, AF Node-5-1). And (AF Node-4-2, AF Node-5-2). Round robin is a method of sequentially using these four combinations. A method of randomly selecting these four combinations may also be used.
[0168]
　(Packet transfer on AFC-3 (Feedback from AFC Header to AFC Ingress)) When
　the original data packet sent by the application on COTS device arrives at AFC Ingress, AFC Header becomes AF Node-4- as AFC-3. It is assumed that AF-4 on 1 and AF-5 on AF Node-5-1 are selected, and the Feedback flag is set in the Flags field of the AFC header. Then, the packet is transferred from the application on the COTS device to the application on the Server as in steps S241 to S247 of FIG.
[0169]
　Since the Feedback flag is set in the Flags field of the AFC header, AFC Egress establishes a TLS connection with AFC Ingress (step S248) and sends the AFC Feedback packet shown in FIG. 73 to AFC Ingress (step S249). ), And finally disconnect the TLS connection with AFC Ingress (step S250). The value of each field of the AFC Feedback packet is as follows. The value of the Type field is "AFC Feedback". The value of the AFC ID field is AFCID-3. The value of the No of AFs field is 2. The next four fields relate to AF Node-4-1. The value of the AF ID field is AFID-4. The value of AF Node IP Address is IP-afn4-1. In the In Timestamp field and the Out Timestamp field, the values ​​of the In Timestamp field and the Out Timestamp field of the corresponding AF of the AFC header of the received AFC data packet are set, respectively. The next four fields relate to AF Node-5-1 and are set in the same manner as above. In the Ingress Out Timestamp field, the value of the corresponding field of the received AFC data packet is set. In the Egress In Timestamp field, the time when the AFC Egress receives the AFC data packet is set.
[0170]
　Upon receiving the AFC Feedback packet, AFC Ingress retains the table shown in FIG. 74.
[0171]
　The values ​​of each field of Ingress AFC Path List Table are as follows. The value of the AFC ID field is AFCID-3. The value of the No of AFs field is 2. The value of the ptr to AFC Path List Entry field is a pointer to the Ingress AFC Path List Entry. The value of the Ingress Out Timestamp field is TSout-ingress, which is the value of the corresponding field of the AFC Feedback packet. The value of the Egress In Timestamp field is TSin-egress, which is the value of the corresponding field of the AFC Feedback packet. The value of ptr to Next AFC Path List Table is [null].
[0172]
　The values ​​of each field of Ingress AFC Path List Entry are as follows. AFC Ingress assigns AFCCID-afc3-1 as an identifier of the AFC path that is the target of the AFC Feedback packet, and stores this in the AFC Path ID field. The value of ptr to AF Node TS Table is a pointer to the Ingress AF Node TS Table. The value of ptr to Next AFC Path List Entry is [null]. When AFC Ingress receives an AFC Feedback packet for another AFC path for AFC-3, it creates a new Ingress AFC Path List Entry and points a pointer to this Ingress AFC Path List Entry to the above ptr to Next AFC Path. Store.
[0173]
　Of the two Ingress AFC Node TS Tables, the one on the left is for AF Node-4-1 and the one on the right is for AF Node-5-1.
[0174]
　The values ​​of each field of Ingress AF Node TS Table regarding AF Node-4-1 are as follows. The value of the ptr to Next AF Node TS Table field is a pointer to the AF Node TS Table for AF Node-5-1. The value of the AF ID field is AFID-4. The value of the AF Node IP Address field is IP-afn4-1 which is the IP address of AF Node-4-1. The value of the In Timestamp field is TSin-afn4-1, which is the value of the corresponding In Timestamp field of the AFC Feedback packet. The value of the Out Timestamp field is TSout-afn4-1 which is the value of the corresponding Out Timestamp field of the AFC Feedback packet.
[0175]
　The values ​​of each field of Ingress AF Node TS Table for AF Node-5-1 are as follows. The value of the ptr to Next AF Node TS Table field is [null]. The value of the AF ID field is AFID-5. The value of the AF Node IP Address field is IP-afn5-1, which is the IP address of AF Node-5-1. The value of the In Timestamp field is TSin-afn5-1, which is the value of the corresponding In Timestamp field of the AFC Feedback packet. The value of the Out Timestamp field is TSout-afn5-1, which is the value of the corresponding Out Timestamp field of the AFC Feedback packet.
[0176]
　In this example, the AFC-3 has four AFC paths, so when the AFC Ingress receives an AFC Feedback packet for each AFC path, it updates the corresponding Ingress AF Node TS Table. When the AFC Ingress receives the original data packet to which the AFC-3 is applied from the application of COTS device, the AFC Ingress may refer to the Ingress AFC Path List Table and select the AFC path. For example, the communication time of the entire AFC path can be considered. Alternatively, only the AF processing time can be considered. It is also possible to consider only the communication time between each node. Furthermore, the processing time of a specific AF and the communication time between a specific node can be combined.
[0177]
　(Time-out and request for extension of time-out) The
　AFC Manager decrements the value of the Time to Live field of the Manager User Table at regular intervals (for example, at 1-minute intervals). As a result of decrementing, when the value of the Time to Live field becomes 0 (timeout), all the tables related to the corresponding AFC User are deleted. In the above situation, when the value of the TTL-usr1 field of the Manager User Table for AFC User-1 becomes 0, the AFC Manager clears all the tables for AFC User-1.
[0178]
　AFC User-1 can extend the time to time out. FIG. 75 is an explanatory diagram showing an extension process of the time until the timeout by AFC User-1.
[0179]
　First, AFC User-1 establishes a TLS connection with AFC Manager (step S251).
[0180]
　Subsequently, the AFC User-1 transmits the Timeout Extension Request packet shown in FIG. 76 to the AFC Manager (step S252). The values ​​of each field of the Timeout Extension Request packet are as follows. "Timeout Extension Request" is set in the Type field. USRID-1 is set in the User ID field. In the AF ID field, AFC User-1 selects one of the AFs already installed at this point, and its identifier is set. In this example, it is AFID-4. In the AF Certificate field, AFCert-af4, which is the certificate information generated by using AFSKey-af4, is set. The Time to Live field is set to the desired new timeout value, TTL-usr1-2.
[0181]
　When the AFC Manager receives the Timeout Extension Request packet, it validates the value in the AF Certificate field. If the verification is successful, the AFC Manager confirms the value of the Time to Live field and determines a new allowable aim-out value, TTL-usr1-3. Next, the AFC Manager transmits the Timeout Extension Response packet shown in FIG. 77 to the AFC User-1 (step S253). The values ​​of each field of the Timeout Extension Response packet are as follows. "Timeout Extension Response" is set in the Type field. "OK" indicating the success of the process is set in the Status field. In the User ID field, USRID-1, which is the value of the User ID field of the Timeout Extension Request packet, is set. The Time to Live field is set to a new allowed aim-out value, TTL-usr1-3.
[0182]
　When the AFC User-1 receives the Timeout Extension Response packet, it disconnects the TLS connection with the AFC Manager (step S254).
[0183]
　[1.3. Functional configuration example of the communication device]
　Subsequently, a functional configuration example of the communication device that can function as each application or node according to the embodiment of the present disclosure will be described.
[0184]
　FIG. 78 is an explanatory diagram showing a functional configuration example of the communication device 100 that can function as each node according to the embodiment of the present disclosure. The communication device 100 shown in FIG. 78 includes a communication unit 110, a storage unit 120, and a control unit 130.
[0185]
　The communication unit 110 executes communication between the nodes. Communication between nodes may be wired or wireless. From the communication unit 110, the packets and messages described above are transmitted from a predetermined port and received from a predetermined port with another node under the control of the control unit 130.
[0186]
　The storage unit 120 stores various information and programs used in the above-mentioned AFC architecture. For example, the storage unit 120 stores the various tables described above. The storage unit 120 may be composed of various memories, HDDs, and the like.
[0187]
　The control unit 130 is composed of a processor such as a CPU, and executes processing based on the AFC architecture described above. For example, the control unit 130 sets a route to and from a target node, processes communication with a target node, processes when an AF node is added, changed, or deleted, and activates AFC-daemon. Execute the AF function, etc. That is, when the route between AFC Ingress and AFC Ingress changes, the control unit 130 generates a message for newly setting AF. This change may be, for example, a change in the case where the route is branched from AFC Ingress to AFC Ingress. Further, this change may be, for example, a change in the case of deleting the AF node between AFC Ingress and AFC Ingress. If the own device is AFC Ingress, the control unit 130 adds an AFC header to the packet sent from the COTS device, and if the own device is AFC Ingress, the control unit 130 deletes the AFC header from the packet to which the AFC header is attached. Execute the process.
[0188]
　<2. Summary> As
　described above, according to the embodiment of the present disclosure, in a service for transferring packets in a network, one or more functions desired by the service user are applied to the packets desired by the service user. A communication device capable of being provided is provided.
[0189]
　Each step in the process performed by each device of the present specification does not necessarily have to be processed in chronological order in the order described as a sequence diagram or a flowchart. For example, each step in the process executed by each device may be processed in an order different from the order described in the flowchart, or may be processed in parallel.
[0190]
　In addition, it is possible to create a computer program for making the hardware such as the CPU, ROM, and RAM built in each device exhibit the same functions as the configuration of each device described above. It is also possible to provide a storage medium in which the computer program is stored. Further, by configuring each functional block shown in the functional block diagram with hardware, a series of processes can be realized by hardware.
[0191]
　Although the preferred embodiments of the present disclosure have been described in detail with reference to the accompanying drawings, the technical scope of the present disclosure is not limited to such examples. It is clear that anyone with ordinary knowledge in the technical field of the present disclosure may come up with various modifications or modifications within the scope of the technical ideas set forth in the claims. Is, of course, understood to belong to the technical scope of the present disclosure.
[0192]
　In addition, the effects described herein are merely explanatory or exemplary and are not limited. That is, the techniques according to the present disclosure may exhibit other effects apparent to those skilled in the art from the description herein, in addition to or in place of the above effects.
[0193]
　For example, AFC Ingress may also serve as the first AF Node in the AFC path. That is, the AFC Ingress and the first AF Node on the path of the AFC path may be configured as physically or logically the same communication device. In this case, for example, when this communication device receives a packet, as the operation of AFC ingress, first, header information describing the route information between AFC Ingress and AFC Ingress is added to the packet, and then AF Node To perform the operation as. When AFC Ingress and AFC Node are configured as the same communication device, a part of the operation of AFC Ingress may be omitted. For example, the operation of sending a packet to another node as AFC Ingress may be omitted, and the operation may move to the operation of AF Node. Further, when the AFC Ingress and the AFC Node are configured as the same communication device, a part of the AF Node operation may be omitted.
[0194]
　Further, for example, the AFC Egress and the last AF Node on the route may be configured as physically or logically the same communication device. In this case, for example, when this communication device receives a packet, it first executes an operation as AF Node, and then, as an operation of AFC Egress, a header in which route information between AFC Ingress and AFC Egress is described. Remove the information from the packet. When the AFC Egress and the AFC Node are configured as the same communication device, a part of the operation of the AFC Egress may be omitted. For example, the operation of sending a packet to another node as AF Node may be omitted, and the operation may move to the operation of AFC Egress. Further, when the AFC Egress and the AFC Node are configured as the same communication device, a part of the AF Node operation may be omitted.
[0195]
　The following configurations also belong to the technical scope of the present disclosure.
(1)
　A communication unit that executes communication with another node and
　a control unit that controls communication by the communication 　unit are
provided, and the
control unit sends a packet directed by a source node to a destination node. , Add header information that describes at least the route information between the own device located after the source node and the target node located in front of the destination node, and other other existing in the route. A communication device that is sent to the communication unit toward a node.
(2)
　The route information between the own device and the target node includes at least information on communication with at least one relay node existing between the target node and information on a function to be executed by the relay node. The communication device according to (1) above, wherein the content of the process according to the execution result of the function at the relay node is described.
(3)
　The communication device according to (2) above, wherein the content of the process is selection of a node next to the relay node.
(4)
　The communication device according to (2) or (3) above, wherein the certificate information at the relay node is further described in the route information between the own device and the target node.
(5) The
　control unit selects one of the relay nodes from the plurality of relay nodes based on the load information of the plurality of relay nodes, according to any one of (2) to (4). The communication device described.
(6)
　A communication unit that executes communication with another node and
　a control unit that controls communication by the communication 　unit are
provided, and the
control unit sends a packet directed by the source node to the destination node. The added header information that describes at least the header information that describes the route information from the start node located after the source node to the own device located in front of the destination node is deleted and sent to the communication unit. ,Communication device.
(7)
　The route information from the start node to the own device includes at least information on communication with at least one relay node existing between the start node and the own device, and information on a function to be executed by the relay node. The communication device according to (6) above, wherein the content of processing according to the execution result of the function at the relay node is described.
(8)
　A communication unit that executes communication with another node and
　a control unit that controls communication by the communication 　unit are
provided, and the
control unit sends a packet directed by a source node to a destination node. , The next node is determined by referring to the data to which the header information at least describing the route information from the start node located after the source node to the target node located before the destination node is added. A communication device that sends the data to the communication unit toward the determined next node.
(9)
　The route information between the start node and the target node includes at least information regarding communication between the start node and at least one relay node existing between the target node and a function of causing the relay node to execute the route information. The communication device according to (8) above, wherein the information of the above and the content of processing according to the execution result of the function at the relay node are described.
(10)
　The communication device according to (9) above, wherein the content of the process is selection of a node next to the relay node.
(11)
　The communication device according to (9) or (10), wherein the route information between the start node and the target node further describes the certificate information at the relay node.
(12) The
　control unit selects one of the relay nodes from the plurality of relay nodes based on the load information of the plurality of relay nodes, according to any one of (9) to (11). The communication device described.
(13)
　A communication unit that executes communication with another node and
　a control unit that controls communication by the communication 　unit are
provided, and the
control unit provides route information between a start node and a target node. The
　start node is a node that adds header information in which at least the route information between the start node and the target node is described, and the
　target node is a node that deletes the header information.
　The route information between the start node and the target node includes at least information regarding communication with at least one relay node existing between the start node and the target node, and a function of causing the relay node to execute the route information. A communication device in which information and the content of processing according to the execution result of the function at the relay node are described.
(14)
　The communication device according to (13), wherein the content of the process is selection of a node next to the relay node.
(15)
　The communication device according to (13) or (14), wherein the route information between the start node and the target node is further described with certificate information at the relay node.
(16)
　and performing a communication with other nodes,
　and to control the communication with the other nodes
provided with,
　to the control directs the source node to the destination node In the packet, at least the header information in which the route information between the start node located after the source node and the target node located before the destination node is described is added and exists in the route. A communication method that sends out to other nodes.
(17) It includes
　executing communication with
　another node and controlling communication with the other node
.
　The control is that the packet directed by the source node to the destination node contains the route information between the start node located after the source node and the target node located before the destination node. A communication method in which at least the described header information is deleted and sent to the other node.
(18)
　and performing a communication with other nodes,
　and to control the communication with the other nodes
provided with,
　to the control directs the source node to the destination node With reference to the data to which the header information in which at least the route information from the start node located in the subsequent stage of the source node to the target node located in the previous stage of the destination node is described is added to the packet, the next A communication method in which a node is determined and the data is sent to the determined next node.
(19)
　A communication unit that executes communication with another node,
　a control unit that controls communication by the communication unit, and the
　control unit include header information in a packet directed by a source node to a destination node. Is used in the communication device to send to the communication unit by adding the above
　, and as the header information, the start node located after the source node between the start node and the target node and the front stage of the destination node. A data structure that at least the route information to and from the target node located at.
Code description
[0196]
　100 Communication device
　110 Communication unit
　120 Storage unit
　130 Control unit
The scope of the claims
[Claim 1]
　A communication unit that executes communication with another node and
　a control unit that controls communication by the communication 　unit are
provided, and the
control unit transmits the packet directed by the source node to the destination node. Add header information that describes at least the route information between the own device located after the original node and the target node located before the destination node, and direct it to other nodes existing in the route. A communication device to be sent to the communication unit.
[Claim 2]
　The route information between the own device and the target node includes at least information on communication with at least one relay node existing between the target node, information on a function to be executed by the relay node, and the above. The communication device according to claim 1, wherein the content of processing according to the execution result of the function at the relay node is described.
[Claim 3]
　The communication device according to claim 2, wherein the content of the process is selection of a node next to the relay node.
[Claim 4]
　The communication device according to claim 2, wherein the certificate information at the relay node is further described in the route information between the own device and the target node.
[Claim 5]
　The communication device according to claim 2, wherein the control unit selects one of the relay nodes from the plurality of relay nodes based on the load information of the plurality of relay nodes.
[Claim 6]
　A communication unit that executes communication with another node and
　a control unit that controls communication by the communication 　unit are
provided, and the
control unit is added to a packet directed by a source node to a destination node. , A communication device that deletes at least the header information in which the route information from the start node located after the source node to the own device located in the front stage of the destination node is described and sends it to the communication unit. ..
[Claim 7]
　The route information from the start node to the own device includes at least information on communication with at least one relay node existing between the start node and the own device, information on a function to be executed by the relay node, and the relay. The communication device according to claim 6, wherein the content of processing according to the execution result of the function on the node is described.
[Claim 8]
　A communication unit that executes communication with another node and
　a control unit that controls communication by the communication 　unit are
provided, and the
control unit transmits the packet directed by the source node to the destination node. The next node is determined by referring to the data to which the header information at least describing the route information from the start node located after the original node to the target node located before the destination node is added. A communication device for transmitting the data to the communication unit toward the next node.
[Claim 9]
　The route information between the start node and the target node includes at least information regarding communication with at least one relay node existing between the start node and the target node, and a function of causing the relay node to execute. The communication device according to claim 8, wherein the information of the above and the content of the process according to the execution result of the function at the relay node are described.
[Claim 10]
　The communication device according to claim 9, wherein the content of the process is selection of a node next to the relay node.
[Claim 11]
　The communication device according to claim 9, wherein the route information between the start node and the target node further describes the certificate information at the relay node.
[Claim 12]
　The communication device according to claim 9, wherein the control unit selects one of the relay nodes from the plurality of relay nodes based on the load information of the plurality of relay nodes.
[Claim 13]
　A communication unit that executes communication with another node and
　a control unit that controls communication by the communication 　unit are
provided, and the
control unit generates route information between a start node and a target node.
　The start node is a node that adds header information in which at least the route information between the start node and the target node is described, and the
　target node is a node that deletes the header information, and the
　start node. The route information between and the target node includes at least information on communication between the start node and at least one relay node existing between the target node, information on a function to be executed by the relay node, and information on functions to be executed by the relay node. A communication device in which the content of processing according to the execution result of the function at the relay node is described.
[Claim 14]
　The communication device according to claim 13, wherein the content of the process is selection of a node next to the relay node.
[Claim 15]
　The communication device according to claim 13, wherein the route information between the start node and the target node further describes the certificate information at the relay node.
[Claim 16]
　And performing communication with other nodes,
　and to control the communication with the other nodes
provided with,
　to the control, the source node towards the destination node packet , Other nodes existing in the route by adding at least header information in which the route information between the start node located after the source node and the target node located before the destination node is described. Communication method to send to.
[Claim 17]
　And performing communication with other nodes,
　and to control the communication with the other nodes
provided with,
　to the control, the source node towards the destination node packet , The header information in which at least the route information between the start node located after the source node and the target node located before the destination node is described is deleted and sent to the other node. Communication method to let.
[Claim 18]
　And performing communication with other nodes,
　and to control the communication with the other nodes
provided with,
　to the control, the source node towards the destination node packet , The next node is determined by referring to the data to which the header information at least describing the route information from the start node located after the source node to the target node located before the destination node is added. A communication method in which the data is sent to the determined next node.
[Claim 19]
　The communication unit that executes communication with other nodes, the
　control unit that controls communication by the communication unit, and the
　control unit add header information to the packet directed by the source node to the destination node. The
　start node located after the source node between the start node and the target node and the start node located before the destination node are located between the start node and the target node as the header information used in the communication device to be sent to the communication unit. A data structure that at least the route information to and from the target node contains.