WO2022264230A1 - 通信制御装置、通信制御方法、及びプログラム - Google Patents

通信制御装置、通信制御方法、及びプログラム Download PDF

Info

Publication number
WO2022264230A1
WO2022264230A1 PCT/JP2021/022579 JP2021022579W WO2022264230A1 WO 2022264230 A1 WO2022264230 A1 WO 2022264230A1 JP 2021022579 W JP2021022579 W JP 2021022579W WO 2022264230 A1 WO2022264230 A1 WO 2022264230A1
Authority
WO
WIPO (PCT)
Prior art keywords
transmission
reception
packet
time
class
Prior art date
Application number
PCT/JP2021/022579
Other languages
English (en)
French (fr)
Inventor
宏紀 岩澤
信博 東
貴秀 木津
仁士 益谷
健 桑原
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to PCT/JP2021/022579 priority Critical patent/WO2022264230A1/ja
Priority to JP2023528772A priority patent/JPWO2022264230A1/ja
Publication of WO2022264230A1 publication Critical patent/WO2022264230A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]

Definitions

  • the present invention relates to a communication device that performs time division transmission such as Time Sensitive Networking.
  • Time Sensitive Networking which can coexist with best-effort communication while guaranteeing delay and jitter on industrial and automotive Ethernet (registered trademark), has been attracting attention in recent years.
  • TSN Time Sensitive Networking
  • LAN Local Area Network
  • TSN To expand the application area of TSN, it is effective to realize TSN communication in a virtual environment such as a container/virtual machine (VM) in order to provide TSN services flexibly.
  • VM container/virtual machine
  • Non-Patent Document 1 In an environment where multiple guests exist on the same physical host, when performing TSN communication from a guest, in the prior art disclosed in Non-Patent Document 1, etc., there is a method in which the guest side performs the same traffic control as the host. , it is not possible to prevent traffic collisions between guests and make delay guarantees.
  • the present invention has been made in view of the above points, and guarantees jitter without performing complicated time-division transmission control on the guest side in TSN communication in an environment where multiple guests are provided on the same physical host.
  • the purpose is to provide a mechanism.
  • a plurality of reception control units for receiving packets from a server on which an application is running are provided, and each reception control unit: a receive buffer; When the packet can be received by the transmission interface connected to an external network, the packet is transmitted to the transmission interface, and when the packet cannot be received by the transmission interface, the packet is stored in the reception buffer.
  • a communication control device comprising: a reception determination unit for
  • FIG. 1 is an overall configuration diagram of a system according to an embodiment of the present invention
  • FIG. 4 is a configuration diagram of a host in Example 1.
  • FIG. 4 is a configuration diagram of a reception control unit according to the first embodiment
  • FIG. 4 is a configuration diagram of a transmission control unit according to the first embodiment
  • FIG. 10 is a processing flow when a packet is received by a reception determination unit in reception determination method 1
  • 10 is a transfer flow from a reception buffer to a class assignment unit in reception determination method 1
  • FIG. 10 is a reception permitted time calculation flow in reception determination method 2;
  • FIG. FIG. 10 is a processing flow when a packet is received by a reception determination unit in reception determination method 2;
  • FIG. 10 is a reception permitted time calculation flow in reception determination method 3;
  • FIG. 10 is a processing flow when a packet is received by a reception determination unit in reception determination method 3;
  • FIG. 10 is a reception permitted time calculation flow in reception determination method 3;
  • FIG. 10 is a configuration diagram of a host in Example 2;
  • FIG. 11 is a configuration diagram of a reception control unit in Example 2;
  • FIG. 11 is a configuration diagram of a class assigning unit in Example 2;
  • FIG. 11 is a configuration diagram of a host in Example 3; It is a figure which shows the example of schedule information.
  • FIG. 11 is a configuration diagram of a reception control unit in Example 4;
  • FIG. 21 is a diagram illustrating an example of allocation of transmission queues in Example 5;
  • FIG. 12 is a configuration diagram of a reception control unit in Example 5;
  • FIG. 12 is a configuration diagram of a transmission control unit in Example 5;
  • FIG. 11 is a configuration diagram of a host in Example 6; It is a hardware configuration example of the device.
  • a TSN method a plurality of transmission queues are prepared for each port of a communication device, and gate opening/closing for controlling whether transmission is possible is controlled by a time based on an internal clock. system, but the present invention is applicable not only to the Qbv system.
  • FIG. 1 shows an example of a configuration in which three guests (containers/VMs) exist on the same physical host and share the transmission class of TSN. In such a configuration, queuing delay may occur due to traffic collision between guests, and transmission order reversal may occur within the same transmission class.
  • FIG. 1 is a diagram for explaining a problem of the conventional technology, and the configuration itself of FIG. 1 is not an existing technology that is open to the public.
  • FIG. 2 is also the same.
  • time-division transmission control is not performed on the guest side, the application transmission timing is not restricted. There is a risk that the time slot will be shifted.
  • FIG. 3 shows a transmission schedule indicating the original packet transmission order of a certain transmission class, and the lower part of FIG. 3 shows the transmission order when inter-guest traffic is interrupted.
  • a to E represent packets transmitted during periods of open1 and open2.
  • packet D is transmitted in the open2 transmission time slot in the original transmission schedule. However, if packet D is enqueued without waiting for the transmission schedule, packet D arrives earlier than packet C, which is earlier than the original transmission time slot open2, so that transmission of C is completed within one time slot. Gone. Also, if D is a time-sensitive packet, D will also be transmitted earlier than expected, resulting in increased jitter.
  • Non-Patent Document 1 Conventional technology 1 is a technology disclosed in Non-Patent Document 1.
  • IFB Intermediate Functional Block device
  • HTB Hierarchical Token Bucket
  • the transmission request time is given as metadata in the kernel of the communication packet, and the packet buffer (Qdisc) inside the kernel linked to the network interface uses the rbtree data structure so that the transmission request time is close to the current time. Arrange the packets in order and perform dequeue processing to the ring buffer in the driver so as to meet the transmission request time.
  • FIG. 4 is an example of a host with three guests. Note that the operation of each functional unit shown in FIG. 4 will be described in an embodiment described later.
  • a buffer is provided in the reception I/F of the host that pairs with the transmission I/F of the guest, and reception control is performed by opening and closing a gate that is synchronized with Qbv transmission control on the host side.
  • each guest's application (TSN Talker) does not need to be aware of the transmission timing and TSN settings, and can control the reception I/F to buffer packets if it is not the transmission timing. In this way, by performing reception control in synchronization with transmission control, only the traffic at the transmission timing is transferred, so packet collision does not occur and jitter can be guaranteed.
  • FIG. 5 shows an example of the overall configuration of the system according to this embodiment. As shown in FIG. 5, this system includes a host 100, a TSN domain 500, and a client terminal 200.
  • FIG. 5 shows an example of the overall configuration of the system according to this embodiment. As shown in FIG. 5, this system includes a host 100, a TSN domain 500, and a client terminal 200.
  • FIG. 5 shows an example of the overall configuration of the system according to this embodiment. As shown in FIG. 5, this system includes a host 100, a TSN domain 500, and a client terminal 200.
  • the host 100 is a physical server that accommodates multiple guests.
  • the TSN domain 500 is a network composed of devices that support TSN (including two of IEEE 802.1AS and Qbv).
  • FIG. 5 shows relay devices 300 and 400 as examples of devices that configure the TSN domain 500 .
  • a client terminal 200 communicates with a guest in the host 100 .
  • the host 100 has guests 110-1 to 110-n and a virtual relay device 120.
  • a plurality of guests 1 to n connect to the virtual relay device 120 in the host 100 and communicate with the client terminal 200 via the transmission/reception interface of the host 100 .
  • a guest and a virtual relay device are used, but a physically wired bare metal server may be used in place of the guest, and a physical relay device may be used in place of the virtual relay device.
  • a “guest” may also be referred to as a "server”.
  • the term “relay device” has a broad meaning including both “virtual relay device” and “physical relay device”.
  • a “relay device” or a device including a “relay device” may be called a "communication control device”.
  • Examples 1 to 6 can be arbitrarily combined and carried out.
  • Example 1 Basic method
  • FIG. 6 shows the configuration of the host 100.
  • the host 100 includes guests 110 - 1 to 110 - 3 , virtual relay device 120 , schedule DB (database) 130 , transmission control unit 140 and physical NIC 150 .
  • Each guest has an application and a vNIC, which is a virtual transmission/reception I/F.
  • the virtual relay device 120 includes a vNIC connected to each guest 110, a reception control unit 121, and a class assignment unit 122. You may call "vNIC+ reception control part 121" a reception interface.
  • Each guest 110 and the virtual relay device 120 are connected by each vNIC, and the application in each guest 110 passes through the vNIC, the vNIC in the virtual relay device 120, the reception control unit 121, and the class assignment unit 122, It communicates with an external network via the transmission control unit 140 and the physical NIC 150 .
  • transmission control unit 140 + physical NIC 150 may be called a transmission interface.
  • the transmission control unit 140 and the physical NIC 150 may be included in the virtual relay device 120 .
  • the multiple reception control units 121-1 to 121-3 and the transmission control unit 140 refer to the schedule DB 130.
  • the terminal (Talker) that transmits the packet attaches a class identifier (VLAN (Virtual LAN) tag) for transmission control according to IEEE802.1Qbv, but in Example 1, the packet is transmitted
  • VLAN Virtual LAN
  • the reception control unit 121 attaches class information as metadata to the packet. Assign a class identifier.
  • FIG. 7 shows a configuration example of the reception control unit 121 according to the first embodiment.
  • the reception control section 121 includes a reception determination section 11, a metadata addition section 12, and a reception buffer 13.
  • the reception determination unit 11 may include the function of the metadata addition unit 12 .
  • the reception determination unit 11 confirms to which class the packet received from the vNIC is assigned based on the information in the schedule DB 130, and after determining whether it is a receivable time or not, sends the packet to the metadata addition unit Hand over to 12. Detailed processing of the reception determination method will be described later.
  • the metadata adding unit 12 adds class information to the packet as packet metadata. If the current time is a receivable time, the packet is transmitted to the class assigning unit 122 as it is. Send to the granting unit 122 .
  • the class assignment unit 122 acquires metadata class information from the packet and assigns a class identifier to the packet.
  • a VLAN tag is added and a class is specified in the 3-bit Priority Code Point (PCP) area within the VLAN tag.
  • PCP Priority Code Point
  • FIG. 8 shows a configuration example of the transmission control unit 140 of the first embodiment.
  • the transmission control unit 140 includes a class classification unit 141, a plurality of transmission queues, and a transmission gate opening/closing unit 142, and performs transmission control according to IEEE802.1Qbv.
  • FIG. 8 shows transmission queues for eight classes, this is just an example.
  • the class classification unit 141 distributes packets arriving at the transmission control unit 140 to transmission queues that exist for each class.
  • the transmission gate opening/closing unit 142 transmits packets to the external network via the physical NIC 150 only during the time when transmission is permitted.
  • the time-division transmission schedule of the transmission gate opening/closing unit 142 is performed by referring to the schedule DB 130 .
  • FIG. 16 shows the relationship on the time axis of each variable used in the explanation. Note that FIG. 16 shows variables when using t base .
  • the reception determination unit 11 of the reception control unit 120 obtains from the schedule DB 130 in advance the time T cycle of one cycle during which the entire transmission schedule is repeated, the reference time t 0 at which the transmission schedule is started, and the offset from the reference time at which reception is permitted.
  • the value T open and the grant end offset value T close are obtained.
  • FIG. 9 An operation example of the reception determination unit 11 will be described with reference to FIGS. 9 and 10.
  • FIG. 9 is a processing flow when the reception determination unit 11 receives a packet.
  • the reception determination unit 11 receives packet i from the guest 110 .
  • the reception determination unit 11 acquires the current time stamp value t now .
  • the reception determining unit 11 determines whether or not T now ⁇ T open . If Yes, the process proceeds to S105, and if No, the process proceeds to S107. In S105, the reception determining unit 11 determines whether or not T now ⁇ T close , and if Yes, proceeds to S106, and if No, proceeds to S108.
  • the reception determination unit 11 transfers the packet i to the class assignment unit 122 .
  • the reception permission time is the time at which the transmission control unit 140 can start the reception process, and may be called the reception start time or the reception process start time.
  • FIG. 10 is a transfer flow from the reception buffer 13 to the class assignment unit 122.
  • the reception determination unit 11 acquires the current time stamp value t now .
  • the reception determination unit 11 determines whether or not there is a packet i whose minimum t i open is equal to t now among the packet groups in the reception buffer 13. If Yes (packet present), proceed to S203; If so, go to S204.
  • the reception determination unit 11 transfers the packet i to the class assignment unit 122 and deletes it from the reception buffer 13 .
  • the reception judging unit 11 judges whether or not "there is new data insertion in the rbtree and there is an update in min ⁇ t i open ⁇ ", and if Yes, the process proceeds to S206. , if No, the process returns to S201. In S206, when the time of min ⁇ t i open ⁇ -t now elapses, the process returns to S201.
  • ⁇ Reception determination method 2 of the reception control unit 121 in the first embodiment Reception determination method 2 of the reception control unit 121 according to the first embodiment will be described.
  • the reception determination unit 11 of the reception control unit 121 constantly calculates the absolute times t open and t close indicating the start and end of reception permission in a separate thread in order to reduce the amount of processing calculations when receiving packets. At the time of reception, only acquisition of the current time and determination of whether it is included in the reception permitted period are performed.
  • reception determination unit 11 in the reception determination method 2 An operation example of the reception determination unit 11 in the reception determination method 2 will be described with reference to FIGS.
  • the transmission process from the reception buffer is the same as the reception determination method 1.
  • FIG. 11 shows a reception permitted time calculation flow.
  • FIG. 12 is a processing flow when the reception determination unit 11 receives a packet.
  • the reception determination unit 11 receives packet i from the guest 110 .
  • the reception determination unit 11 acquires the current time stamp value t now .
  • the reception determining unit 11 determines whether or not t now ⁇ t open . If Yes, the process proceeds to S404, and if No, the process proceeds to S406. In S404, the reception determining unit 11 determines whether or not t now ⁇ t close . If Yes, the process proceeds to S405, and if No, the process proceeds to S407.
  • the reception determination unit 11 transfers the packet i to the class assignment unit 122 .
  • Reception determination method 3 of the reception control unit 121 in the first embodiment Reception determination method 3 of the reception control unit 121 according to the first embodiment will be described.
  • the reception determination method 3 by constantly calculating canRcv indicating whether or not reception is possible and the next transmission permission start time in the reception permission time calculation flow of the reception determination method 2, the amount of calculation in the flow at the time of packet reception can be reduced. Reduce further.
  • FIG. 13 An operation example of the reception determination unit 11 will be described with reference to FIGS. 13 and 14.
  • FIG. 13 The transmission processing from the reception buffer 13 is the same as the reception determination method 1.
  • FIG. 13 shows a reception permitted time calculation flow.
  • the reception determination unit 11 acquires the current time stamp value t now .
  • the reception determination unit 11 determines whether or not t now ⁇ t open . If Yes, the process proceeds to S504, and if No, the process proceeds to S506. In S504, the reception determination unit 11 determines whether or not t now >t close , and if Yes, the process proceeds to S505, and if No, the process proceeds to S507.
  • canRcv false
  • canRcv true.
  • FIG. 14 is a processing flow when the reception determination unit 11 receives a packet.
  • the reception determination unit 11 receives packet i from the guest 110 .
  • the reception determination unit 11 transfers the packet i to the class assignment unit 122 .
  • the first time t open,1 , t close,1 to the n-th time t open,n , t close,n are prepared.
  • t now >t close,i determination is made with the next (i+1)th reception permitted time.
  • FIG. 15 shows a reception permitted time calculation flow in this case.
  • the reception determination unit 11 acquires the current time stamp value t now . The following process is performed n times between S707 and S712.
  • the reception determination unit 11 determines whether or not t now ⁇ t open, i . If Yes, the process proceeds to S709, and if No, the process proceeds to S713. In S709, the reception determination unit 11 determines whether or not t now >t close, i , and if Yes, the process proceeds to S710, and if No, the process proceeds to S714.
  • canRcv false
  • canRcv true.
  • the schedule DB 130 manages schedule information for time-division transmission control in the reception control section 121 and the transmission control section 140 .
  • An example of representing schedule information in a three-level data structure is shown below. (a) of FIG. 17 shows the first hierarchy, (b) shows the second hierarchy, and (c) shows the third hierarchy.
  • the first layer stores the transmission start relative time (Gate open) and transmission end relative time (Gate close) of the time slot, and the transmission class for each time slot is stored in the second layer.
  • the third layer manages flow information (reception interface on the host (relay device) side, flow identifier, transmission amount) to be transmitted within the transmission class.
  • the transmission start/end relative time indicates the elapsed time from the reference time t0 at which the transmission cycle starts.
  • the flow identifier may be one or more of packet header information such as transmission/reception MAC address, transmission/reception IP address, transmission/reception port number, protocol type, VLAN number, VLAN PCP, DSCP value, etc. It may be a calculated hash value.
  • the transmission control unit 140 time-divisionally changes the transmission processing of the queues linked to the transmission class based on the information of the first and second layers.
  • FIG. 18 shows a data structure in which the schedule information is organized for each reception I/F.
  • the second to fourth hierarchies correspond to the first to third hierarchies in FIG.
  • the reception control unit 121 associated with each vNIC uses the Gate open/close values of the timeslots of the second layer as T open and T close .
  • the metadata adding unit 12 in the reception control unit 121 refers to the fourth layer table based on the flow identifier information such as the transmission/reception IP address of the received packet, and receives the matching transmission class information as packet metadata. given to the packet.
  • the transmission class and flow identifier transmitted in one time slot are uniquely determined.
  • Example 2 Method of performing class determination in the class assigning unit
  • the metadata addition of class information performed by each reception control unit 121 is collectively performed by the class attachment unit 122 .
  • the class assigning unit 122 refers to the schedule information from the schedule DB 130 because it is necessary to determine the class of the packet.
  • FIG. 19 showing the configuration of the host 100 of the second embodiment, a line indicating that the class assignment unit 122 refers to the schedule information is shown.
  • FIG. 20 shows a configuration example of the reception control unit 121 in the second embodiment.
  • the reception control unit 121 in the second embodiment includes a reception determination unit 11 and a reception buffer 13.
  • FIG. The reception control unit 121 only performs reception determination by the reception determination unit 11 and buffer processing when reception is not possible. It should be noted that “receivable” means whether or not packet reception by the transmission control unit 140 is possible.
  • FIG. 21 shows a configuration example of the class assigning unit 122 in the second embodiment.
  • the class assignment unit 122 includes a class determination unit 21 and an identifier assignment unit 22 .
  • the class determination unit 21 determines the class of the packet received from the reception control unit 121, and the identifier attachment unit 22 assigns an identifier such as a VLAN tag corresponding to the determined class.
  • the processing other than the class determination being performed by the class assignment unit 122 instead of the reception control unit 121 is the same as that of the first embodiment.
  • Example 3 Method of having an interface for each communication type
  • Example 3 will be described.
  • the search volume of the schedule DB 130 increases and delays occur.
  • vNICs are prepared in the relay device for the number of communications performed from the guest 110, and one vNIC is used for one communication type, thereby speeding up the class determination process.
  • FIG. 22 shows an example in which one guest 110 is connected to the virtual relay device 120 on the host 100 side by three vNICs 1-3.
  • the three vNICs 1-3 may belong to different networks, or may belong to the same L2 network.
  • the guest 110 has as many routing tables as the number of vNICs to which it belongs, and changes the routing table referred to by the source IP address.
  • FIG. 22 shows such an example.
  • FIG. 23 shows schedule information arranged for each reception I/F by allocating only one communication to one vNIC.
  • the reception control unit 121 corresponding to each vNIC can specify the transmission class only by referring to the time slot information for determining whether reception is possible. Only DB reference becomes unnecessary. This reduces the amount of searches and reduces delays.
  • Example 4 A system in which the reception control unit 121 has a reception buffer for each time slot.
  • the reception control unit 121 prepares a reception buffer for a time slot of one cycle in advance, so that reception determination is not performed in units of packets and processing is taken out from the reception buffer, but in units of time slots. , the amount of calculation of the reception determination unit 11 is reduced.
  • FIG. 24 shows a configuration example of the reception control unit 121 in the fourth embodiment.
  • the reception control unit 121 in the fourth embodiment includes a reception determination unit 11, a transmission determination unit 15, and reception buffers for each time slot.
  • the reception determination unit 11 determines in which time slot the packet received from the vNIC should be transmitted based on the information in the schedule DB 130, and stores the packet in the reception buffer corresponding to the time slot in which the packet is transmitted.
  • the transmission determination section 15 reads packets from the respective time slot reception buffers according to the same schedule as the transmission control section 140 and transmits the packets to the class assignment section 122 .
  • Example 5 Method of dividing transmission queues for each time slot
  • the transmission control unit 140 instead of the reception control unit 121 performing reception timing control by the reception buffer, the transmission control unit 140 distributes communications of the same class within one cycle to different transmission queues in the transmission schedule. , to prevent transmission schedule deviations.
  • FIG. 25 shows an example of transmission permission classes in one cycle.
  • 1-3 in FIG. 25 indicates the third transmission queue corresponding to transmission permission class 1.
  • FIG. 25 For example, 1-1, 1-2, 1-3 indicate that the same transmission class 1 is assigned different transmission queues.
  • one transmission class is assigned at the same time, but it is also possible to assign multiple transmission classes at the same time.
  • FIG. 26 shows a configuration example of the reception control unit 121 in the fifth embodiment.
  • the reception control section 121 does not have the reception buffer 13 but has the class determination section 21 .
  • the class determination unit 21 determines the transmission class of the received packet and to what time slot it is assigned in one cycle, and converts the transmission class and time slot information into the packet metadata. Assign as data and send to class assignment.
  • the reception control unit 121 may include the class assignment unit 122, and the reception control unit 121 may perform the assignment of the class identification.
  • the class assignment unit 122 instead of the reception control unit 121 may perform direct determination and class assignment. In that case, the reception control unit 121 becomes unnecessary. Note that in this case, the class assigning unit 122 may be called the reception control unit 121 . That is, the class assignment unit 122 may be used as the reception control unit 121 .
  • the transmission control unit 140 includes a class classification unit 141, a transmission gate opening/closing unit 142, and a plurality of transmission queues for each transmission class. Distributes packets to transmission queues.
  • the transmission gate opening/closing unit 142 opens and closes the gate for each transmission queue according to the schedule information.
  • the transmission queue in the transmission control unit 140 serves as a reception buffer, thereby realizing jitter guarantee.
  • Example 6 Example of applying the technology according to the present invention to one physical NIC
  • Example 6 will be described.
  • any one or any combination of Examples 1-5 is implemented within one physical NIC 150 .
  • FIG. 28 shows a configuration example of the host 100 in the sixth embodiment.
  • a physical NIC 150 has a plurality of VFs, which are virtual NICs, and each VF has a reception control unit 121 (other than the fifth embodiment). , and a schedule DB 130 .
  • the schedule DB 130 may be provided on the host side.
  • the portion including the VF, reception control section 121, and class assignment section 122 may be called a "relay device".
  • Each guest 110 bypasses the host's internal processing (such as network processing within the Linux Kernel) and directly uses the VF on the physical NIC 150. This can be achieved, for example, with Single Root I/O Virtualization.
  • the same functions may also be in charge of other functions.
  • the reception control unit 121 may have the functions of the class assigning unit 122 and the transmission control unit 140, so that the effect of the technology according to the present invention can be exhibited.
  • the time at which the packet is transmitted from the reception control unit 121 to the transmission control unit 141 may be earlier by the transfer delay after calculating the transfer delay from the reception control unit 121 to the transmission control unit 140 in advance.
  • Any of the devices described in the present embodiment can It can be realized by executing a program describing the contents.
  • the computer may be a physical machine or a virtual machine on the cloud.
  • the above program can be recorded on a computer-readable recording medium (portable memory, etc.), saved, or distributed. It is also possible to provide the above program through a network such as the Internet or e-mail.
  • FIG. 29 is a diagram showing a hardware configuration example of the computer.
  • the computer of FIG. 29 has a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, etc., which are connected to each other via a bus B.
  • a program that implements the processing in the computer is provided by a recording medium 1001 such as a CD-ROM or memory card, for example.
  • a recording medium 1001 such as a CD-ROM or memory card
  • the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000 .
  • the program does not necessarily need to be installed from the recording medium 1001, and may be downloaded from another computer via the network.
  • the auxiliary storage device 1002 stores installed programs, as well as necessary files and data.
  • the memory device 1003 reads and stores the program from the auxiliary storage device 1002 when a program activation instruction is received.
  • the CPU 1004 implements functions related to the device according to programs stored in the memory device 1003 .
  • the interface device 1005 is used as an interface for connecting to the network.
  • a display device 1006 displays a GUI (Graphical User Interface) or the like by a program.
  • An input device 1007 is composed of a keyboard, a mouse, buttons, a touch panel, or the like, and is used to input various operational instructions.
  • the output device 1008 outputs the calculation result.
  • the relay device connects to each server in synchronization with a transmission interface connected to an external network that performs time-division transmission control. Perform packet reception processing of the reception interface on the side.
  • the time slot and class in which the reception packet is transmitted through the transmission interface are determined from the flow information and reception time of the reception packet, and a transmission class identifier is added to the packet.
  • the packet is temporarily buffered until the reception processing start time. and transfers the received packet from the reception interface to the physical interface immediately before the transmission interface performs the transmission process.
  • the receiving interface has an independent receiving buffer for time slots included in one cycle of the time-division transmission schedule performed by the transmission interface, and is synchronized with the time-division transmission schedule performed by the transmission interface. It is also possible to transfer the packet from the receive buffer.
  • the transmission interface is provided with a virtual transmission queue for each time slot for one period, and the reception interface determines in which time slot the packet is to be transmitted, By assigning, even a packet received at a time different from the original time slot may be distributed to the transmission queue corresponding to the original transmission time slot.
  • a communication method combining any one of the above configurations or a plurality of any of them may be implemented within a single physical NIC.
  • the above-mentioned communication method does not exist in conventional technology.
  • the bottleneck in normal switches is the sending side, where multiple traffics converge, so existing Linux (registered trademark) and commercially available switches, etc. do not have a mechanism for controlling traffic on the receiving side.
  • Qbv similarly, only the control on the transmission side is defined.
  • This specification discloses at least a communication control device, a communication control method, and a program for each of the following items.
  • (Section 1) A plurality of reception control units for receiving packets from a server running an application, each reception control unit a receive buffer; When the packet can be received by the transmission interface connected to an external network, the packet is transmitted to the transmission interface, and when the packet cannot be received by the transmission interface, the packet is stored in the reception buffer.
  • a communication control device comprising: (Section 2) 2.
  • the reception determination unit always calculates the start and end of the receivable time based on schedule information for time-division transmission control in the transmission interface, and calculates the current time and the start and end of the receivable time. 3.
  • reception control unit includes the reception buffer for each time slot included in one cycle of a time-division transmission schedule in the transmission interface.
  • (Section 6) a plurality of reception control units that receive packets from a server running an application; a transmission control unit connected to an external network and having a plurality of transmission queues for each transmission class, The reception control unit determines a transmission class and time slot of the packet based on schedule information for time-division transmission control in the transmission control unit, adds the transmission class and time slot information to the packet, and Send to the transmission control unit, The transmission control unit distributes the packets to one transmission queue based on a transmission class and time slot information assigned to the packets.
  • a communication control method in a communication control device comprising a plurality of reception control units for receiving packets from a server running an application, comprising: Each reception control unit includes a reception buffer, transmits the packet to the transmission interface at a time when the packet can be received by the transmission interface connected to the external network, and transmits the packet to the transmission interface when the packet cannot be received by the transmission interface.
  • (Section 8) A program for causing a computer to function as each unit in the communication control device according to any one of items 1 to 6.
  • Reception determination unit 12 Metadata provision unit 13 Reception buffer 15 Transmission determination unit 21 Class determination unit 22 Identifier provision unit 100 Host 110 Guest 120 Virtual relay device 121 Reception control unit 122 Class provision unit 130 Schedule DB 140 transmission control unit 141 class classification unit 142 transmission gate opening/closing unit 150 physical NIC 200 Client terminals 300, 400 Relay device 500 TSN domain 1000 Drive device 1001 Recording medium 1002 Auxiliary storage device 1003 Memory device 1004 CPU 1005 interface device 1006 display device 1007 input device

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

アプリケーションが動作するサーバからパケットを受信する複数の受信制御部を備え、各受信制御部は、受信バッファと、外部ネットワークと接続する送信インターフェースにおいて前記パケットを受信可能な時刻に、前記パケットを前記送信インターフェースに向けて送信し、前記送信インターフェースにおいて前記パケットを受信不可の時刻に、前記パケットを前記受信バッファに格納する受信判定部とを備える通信制御装置。

Description

通信制御装置、通信制御方法、及びプログラム
　本発明は、Time Sensitive Networkingなどの時分割送信を行う通信装置に関連するものである。
　産業・車載イーサネット（登録商標）上で遅延・ジッタを保証しつつ、ベストエフォート通信と共存可能なTime Sensitive Networking（ＴＳＮ）が近年注目されている。今後、工場内、自動車内に閉じたLocal Area Network（ＬＡＮ）内だけでなく、離れた工場間での閉ループ制御など、広域での確定時間通信サービスの実現が期待される。
　ＴＳＮの適用領域拡大に向けて、柔軟にＴＳＮサービスを提供する上で、コンテナ・Virtual Machine（ＶＭ）等の仮想環境下でＴＳＮ通信を実現することが有効である。
　また、ＴＳＮ（特にIEEE 802.1Qbv、以後Ｑｂｖ）のタイムスロットを、固定的に特定のクラスに割当てるのではなく、複数のアプリケーションで共用することで、より多くのサービスを収容可能となる。
　一方で、同一物理ホスト上に複数のコンテナ／ＶＭ（以後ゲスト）が存在し、ＴＳＮの送信クラスを共用する場合、ゲスト間のトラヒックの衝突によるキューイング遅延の発生や、同一クラス内での順序逆転が発生し、ジッタ保証が実現できない恐れがある。
C. Xu, K. Rajamani and W. Felter, "NBWGuard: Realizing Network QoS for Kubernetes," Computer Science Proceeding of the 19th International Middleware Conference Industry, 2018.
　同一物理ホスト上に複数のゲストが存在する環境において、ゲストからＴＳＮ通信を行う際、非特許文献１等に開示されている従来技術では、ゲスト側でホストと同一のトラヒック制御を行う方法以外に、ゲスト間のトラヒック衝突を防ぎ、遅延保証を行うことができない。
　しかし、ゲスト側でホスト側と同一のトラヒック制御を行う場合、ゲスト毎に複雑なタイムスロット割り当て処理を実装する必要がある。また、設定ミスや意図的な攻撃により他ゲストのＴＳＮ通信を妨害することが可能となってしまう。すなわち、ゲスト側で複雑な時分割送信制御行うことなく、ゲスト－ホスト間の通信においてジッタ（遅延のゆらぎ）を保証する仕組みが存在しないという課題がある。
　本発明は上記の点に鑑みてなされたものであり、同一物理ホスト上に複数のゲストが備えられる環境でのＴＳＮ通信において、ゲスト側で複雑な時分割送信制御行うことなく、ジッタを保証する仕組みを提供することを目的とする。
　開示の技術によれば、アプリケーションが動作するサーバからパケットを受信する複数の受信制御部を備え、各受信制御部は、
　受信バッファと、
　外部ネットワークと接続する送信インターフェースにおいて前記パケットを受信可能な時刻に、前記パケットを前記送信インターフェースに向けて送信し、前記送信インターフェースにおいて前記パケットを受信不可の時刻に、前記パケットを前記受信バッファに格納する受信判定部と
　を備える通信制御装置が提供される。
　開示の技術によれば、同一物理ホスト上に複数のゲストが備えられる環境でのＴＳＮ通信において、ゲスト側で複雑な時分割送信制御行うことなく、ジッタを保証する仕組みを実現することができる。
課題を説明するための図である。 課題を説明するための図である。 課題を説明するための図である。 実施の形態の概要を説明するための図である。 本発明の実施の形態におけるシステムの全体構成図である。 実施例１におけるホストの構成図である。 実施例１における受信制御部の構成図である。 実施例１における送信制御部の構成図である。 受信判定方法１における受信判定部のパケット受信時の処理フローである。 受信判定方法１における受信バッファからクラス付与部への転送フローである。 受信判定方法２における受信許可時刻算出フローである。 受信判定方法２における受信判定部のパケット受信時の処理フローである。 受信判定方法３における受信許可時刻算出フローである。 受信判定方法３における受信判定部のパケット受信時の処理フローである。 受信判定方法３における受信許可時刻算出フローである。 変数の関係を示す図である。 スケジュール情報の例を示す図である。 スケジュール情報の例を示す図である。 実施例２におけるホストの構成図である。 実施例２における受信制御部の構成図である。 実施例２におけるクラス付与部の構成図である。 実施例３におけるホストの構成図である。 スケジュール情報の例を示す図である。 実施例４における受信制御部の構成図である。 実施例５における送信キューの割り当て例を示す図である。 実施例５における受信制御部の構成図である。 実施例５における送信制御部の構成図である。 実施例６におけるホストの構成図である。 装置のハードウェア構成例である。
　以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。
　以下、Time Sensitive Networkingなどの時分割送信を行うネットワーク内で時分割送信に対応していないサーバと接続する中継装置の受信インターフェースにおいて、時分割受信制御を行うことで、他のトラヒックとの衝突を防止する技術に関する実施の形態を説明する。
　以下の説明に係る本実施の形態では、ＴＳＮの方式として、通信装置のポート毎に、複数の送信キューを用意し、送信可否を制御するゲート開閉を、内部クロックに基づく時間により制御するＱｂｖの方式を想定しているが、本発明はＱｂｖの方式に限らずに適用可能である。
　また、本実施の形態では、Ｑｂｖの時分割送信スケジュールにおけるタイムスロットを、複数のゲスト（ＴＳＮ　Ｔａｌｋｅｒ）にて共用する環境を前提としているが、本発明はこのような前提に限定されるわけではない。
　（課題について）
　まず、後述する実施例に係る技術に対する課題についてより詳細に説明する。図１に、同一物理ホスト上に３つのゲスト（コンテナ／ＶＭ）が存在し、ＴＳＮの送信クラスを共用する構成の例を示す。このような構成では、ゲスト間のトラヒック衝突によるキューイング遅延発生や、同一送信クラス内での送信順序逆転が生じる可能性がある。なお、図１は、従来技術の課題の説明のための図であり、図１の構成自体は公開されている既存技術ではない。図２も同様である。
　上記の課題に対し、図２に示すように、ゲスト側にもホストと同じＱｂｖの送信スケジュールに従う時分割送信制御を設定することが考えらえる。これにより、トラヒックの衝突は防ぐことができる。しかし、そのためにはゲスト側でＱｂｖを行うためのクラス付与と送信制御を行う必要がある。クラスの付与にはアプリケーション毎にＬ２のネットワークレイヤまで独自に実装するか、Ｌｉｎｕｘ（登録商標）が提供するｉｐｔａｂｌｅｓ，ｔｃ等の機能を利用する必要がある。
　前者の独自実装に関しては、アプリケーション作成者がネットワークレイヤまで実装する必要があり、後者のｉｐｔａｂｌｅｓ，ｔｃ等の機能を利用するにはゲスト側で機能を利用するための特権が必要となり、セキュリティ上の問題がある。特権をゲストに付与した場合、ゲスト側の設定ミスや意図的な攻撃による時分割送信制御の妨害が可能となってしまう。またタイムスロットを複数のゲストで共用する場合、ゲスト毎に複雑なタイムスロット割り当てを実施する必要がある。
　一方、ゲスト側で時分割送信制御を行わない場合、アプリケーションの送信タイミングが制限されないため、ホスト側送信インターフェース（以後Ｉ／Ｆ）へのパケットのエンキュー順序の逆転によるキューイング遅延の増加や、送信タイムスロットがずれてしまう恐れがある。
　図３を参照して上記の状況の例を説明する。図３の上段は、ある送信クラスの本来のパケット送信順を示す送信スケジュールを示し、図３の下段は、ゲスト間トラヒックの割込が生じた際の送信順序を示す。Ａ～Ｅはｏｐｅｎ１及びｏｐｅｎ２の期間で送信されるパケットを意味する。
　図３に示すとおり、本来の送信スケジュールにおいてパケットＤがｏｐｅｎ２の送信タイムスロットで送信される。しかし、送信スケジュールを待たずにパケットＤがｅｎｑｕｅｕｅされた場合、パケットＤが、本来の送信タイムスロットｏｐｅｎ２より前の、パケットＣより先に到着することで、Ｃの送信が１タイムスロット内で間に合わなくなる。またＤがタイムセンシティブなパケットであった場合、Ｄも想定より早く送信処理が行われ、ジッタが拡大することとなる。
　続いて、公開されている従来技術の例として従来技術１と従来技術２を説明する。
　＜従来技術１＞
　従来技術１は、非特許文献１に開示されている技術である。従来技術１では、Ｌｉｎｕｘ（登録商標）の拡張機能であるIntermediate Functional Block device（ＩＦＢ）を利用し、ゲストと接続するホストの仮想Ｉ／Ｆで受信したパケットをＩＦＢに転送する。ＩＦＢ上でHierarchical Token Bucket（ＨＴＢ）を用いて、Ｐｏｄ間の最大データ送信量をｋｕｂｅｒｎｅｔｅｓのＭａｎｉｆｅｓｔファイルから指定することにより、Ｐｏｄ毎の送受信帯域を制限できる。
　従来技術１の適用により、ゲスト毎の帯域を管理できるが、ＨＴＢはジッタを犠牲に帯域を保証する方式のため、ゲスト間のトラヒックの競合によるキューイング遅延の悪化やタイムスロットのずれを解消できない。
　＜従来技術２＞
　「https://man7.org/linux/man-pages/man8/tc-etf.8.html」に開示されているとおり、Ｌｉｎｕｘ　ｋｅｒｎｅｌ４．１９からEarliest TxTime First（以下、ＥＴＦ）と呼ばれる、送信要求時刻に従って送信処理を行うキュー制御が導入されている。
　ＥＴＦでは、通信パケットのｋｅｒｎｅｌ内メタデータとして送信要求時刻を付与し、Ｎｅｔｗｏｒｋ　ｉｎｔｅｒｆａｃｅに紐づくｋｅｒｎｅｌ内部のパケットバッファ（Ｑｄｉｓｃ）にて、ｒｂｔｒｅｅデータ構造を用いて、送信要求時刻が現在の時刻に近い順にパケットを整列し、送信要求時刻に間に合うようにドライバ内リングバッファへのデキュー処理を行う。
　ＥＴＦを採用することで、ホストに閉じた通信に関しては、本来の送信タイミングではないパケットが送信されることは生じなくなる。しかし、ゲスト内で付与されたパケットメタデータは、通常仮想インターフェースからホストにパケットが渡された段階で失われるため、ゲスト－ホスト間の通信においては、利用できない。
　＜従来技術の課題＞
　上述したとおり、ホスト内に複数のゲストを備えた環境において、ゲストからＴＳＮ通信を行う際、ゲスト間のトラヒック衝突を防ぎ、遅延保証を行うことができない。これに対してゲスト側でホスト側と同一のトラヒック制御を行うことが考えられるが、ゲスト毎に複雑なタイムスロット割り当て処理を実装する必要があり、また設定ミスや意図的な攻撃により他ゲストのＴＳＮ通信を妨害することが可能となってしまう。
　すなわち、ゲスト側で複雑な時分割送信制御行うことなく、ゲスト－ホスト間の通信においてジッタを保証する仕組みが存在しない課題がある。以下、この課題を解決する本実施の形態に係る技術について説明する。
　（実施の形態の概要）
　まず、図４を参照して本実施の形態の概要を説明する。図４は、３つのゲストを備えるホストの例である。なお、図４に示す各機能部の動作については後述する実施例において説明する。
　本実施の形態では、ゲストの送信Ｉ／Ｆと対になるホストの受信Ｉ／Ｆにバッファを設け、ホスト側のＱｂｖ送信制御と同期するゲート開閉による受信制御を行う。
　このように受信Ｉ／Ｆにバッファを設けることで、ホストの送信タイミング以外にホスト側へ流れるトラヒックをフィルタし、ホストの送信タイミングになるまで受信Ｉ／Ｆにてバッファすることができる。これにより、ゲスト間のトラヒック衝突を防ぎ、ジッタを保証することができる。
　すなわち、図４に示すとおり、各ゲストのアプリケーション（ＴＳＮ　Ｔａｌｋｅｒ）は送信タイミングやＴＳＮの設定を意識不要であり、送信タイミングでなければ受信Ｉ／Ｆでパケットをバッファする制御が可能である。このように、送信制御と同期して受信制御を行うことで、送信タイミングのトラヒックのみを転送するため、パケットの衝突が生じず、ジッタ保証を実現できる。
　以下、本実施の形態におけるシステム構成と動作について詳細に説明する。
　（システムの全体構成例）
　図５に、本実施の形態におけるシステムの全体構成例を示す。図５に示すとおり、本システムは、ホスト１００、ＴＳＮドメイン５００、クライアント端末２００を含む。
　ホスト１００は、複数のゲストを収容する物理サーバである。ＴＳＮドメイン５００は、ＴＳＮ（ＩＥＥＥ　８０２．１ＡＳ，Ｑｂｖの２つを含む）をサポートした装置で構成されるネットワークである。図５には、ＴＳＮドメイン５００を構成する装置の例として中継装置３００、４００が示されている。クライアント端末２００は、ホスト１００内のゲストと通信する。
　ホスト１００は、ゲスト１１０‐１～１１０‐ｎ、及び仮想中継装置１２０を有する。複数のゲスト１～ｎは、ホスト１００内の仮想中継装置１２０に接続し、ホスト１００の送受信インターフェースを介してクライアント端末２００と通信を行う。
　なお、本実施の形態では、ゲストと仮想中継装置を用いるが、ゲストの代わりに物理的に配線されたベアメタルサーバ、仮想中継装置の代わりに物理中継装置を利用してもよい。「ゲスト」を「サーバ」と呼んでもよい。また、「中継装置」は、「仮想中継装置」と「物理中継装置」の両方を含む広い意味を持つ。
　また、「中継装置」や、「中継装置」を含む装置（例：ホスト、実施例５の物理ＮＩＣ）を、「通信制御装置」と呼んでもよい。
　以下、ホスト１００の詳細構成と詳細動作を実施例１～６を用いて説明する。実施例１～６は任意に組み合わせて実施することが可能である。
　（実施例１：基本方式）
　まず、基本方式を実施例１として説明する。
　＜ホスト１００の構成＞
　図６にホスト１００の構成を示す。図６に示す例において、ホスト１００は、ゲスト１１０－１～１１０－３、仮想中継装置１２０、スケジュールＤＢ（データベース）１３０、送信制御部１４０、物理ＮＩＣ１５０を備える。各ゲストは、アプリケーションと、仮想送受信Ｉ／ＦであるｖＮＩＣを備える。
　仮想中継装置１２０は、各ゲスト１１０と接続するｖＮＩＣと受信制御部１２１、及びクラス付与部１２２を備える。「ｖＮＩＣ＋受信制御部１２１」を受信インターフェースと呼んでもよい。
　各ゲスト１１０と仮想中継装置１２０は、それぞれのｖＮＩＣで接続され、各ゲスト１１０内のアプリケーションはｖＮＩＣを介して、仮想中継装置１２０内のｖＮＩＣ、受信制御部１２１、クラス付与部１２２を経由し、送信制御部１４０、物理ＮＩＣ１５０を介して外部ネットワークと通信を行う。ここで、「送信制御部１４０＋物理ＮＩＣ１５０」を送信インターフェースと呼んでもよい。また、仮想中継装置１２０の中に送信制御部１４０と物理ＮＩＣ１５０（つまり送信インターフェース）が含まれることとしてもよい。
　複数の受信制御部１２１－１～１２１－３、及び送信制御部１４０がスケジュールＤＢ１３０を参照する。
　標準のＴＳＮでは、パケットを送信する端末（Ｔａｌｋｅｒ）において、ＩＥＥＥ８０２．１Ｑｂｖによる送信制御を行うためのクラス識別子（ＶＬＡＮ（Ｖｉｒｔｕａｌ　ＬＡＮ）タグ）の付与を行うが、実施例１では、パケットを送信するゲスト１１０ではＶＬＡＮタグを付与せず、スケジュールＤＢ１３０の情報を元に、受信制御部１２１にて、パケットのメタデータとしてクラス情報が付与され、クラス付与部１２２にて、クラス情報を元にパケットにクラス識別子を付与する。
　＜受信制御部１２１、クラス付与部１２２＞
　図７に、実施例１における受信制御部１２１の構成例を示す。図７に示すとおり、受信制御部１２１は、受信判定部１１、メタデータ付与部１２、受信バッファ１３を備える。なお、受信判定部１１がメタデータ付与部１２の機能を含んでいてもよい。
　受信判定部１１は、ｖＮＩＣから受信したパケットを、スケジュールＤＢ１３０の情報を元に、どのクラスに割当てるかを確認し、受信可能な時間か否かの判定をした後、当該パケットをメタデータ付与部１２に渡す。受信判定方法の詳細処理は後述する。
　メタデータ付与部１２は、パケットのメタデータとしてパケットにクラス情報を付与する。現在時刻が受信可能な時刻であればそのままクラス付与部１２２へパケットを送信し、受信不可能な時刻であれば受信バッファ１３へパケットを格納し、受信可能な時刻になった際にパケットをクラス付与部１２２へ送信する。
　クラス付与部１２２は、パケットからメタデータのクラス情報を取得し、パケットにクラス識別子を付与する。標準のＴＳＮの場合、ＶＬＡＮタグを付与し、ＶＬＡＮタグ内のPriority Code Point（ＰＣＰ）領域３ｂｉｔにクラスを指定する。
　＜送信制御部１４０＞
　図８に、実施例１の送信制御部１４０の構成例を示す。図８に示すように、送信制御部１４０はクラス分類部１４１、複数の送信キュー、送信ゲート開閉部１４２を備え、ＩＥＥＥ８０２．１Ｑｂｖによる送信制御を行う。なお、図８の例では８クラス分の送信キューが示されているが、これは一例である。
　クラス分類部１４１は、送信制御部１４０に到着したパケットを、クラス毎に存在する送信キューへ振り分ける。送信ゲート開閉部１４２は、送信が許可された時間のみ、物理ＮＩＣ１５０を経由して外部ネットワークへパケットを送信する。送信ゲート開閉部１４２の時分割送信スケジュールはスケジュールＤＢ１３０を参照して行う。
　以下、実施例１における受信制御部１２１の受信判定方法１～３を説明する。説明において使用する各変数の時間軸上での関係は図１６に示されている。なお、図１６は、ｔｂａｓｅを使用する場合の変数を示している。
　＜実施例１における受信制御部１２１の受信判定方法１＞
　実施例１における受信制御部１２１の受信判定方法１について説明する。受信制御部１２０の受信判定部１１は、あらかじめスケジュールＤＢ１３０から、全体の送信スケジュールが繰り返される１周期の時間Ｔｃｙｃｌｅ、送信スケジュールが開始される基準時刻ｔ０、受信を許可する基準時刻からのオフセット値Ｔｏｐｅｎ、及び許可終了のオフセット値Ｔｃｌｏｓｅを取得しておく。
　図９、及び図１０を参照して、受信判定部１１の動作例を説明する。
　図９は、受信判定部１１のパケット受信時の処理フローである。Ｓ１０１において、受信判定部１１は、ゲスト１１０からパケットｉを受信する。Ｓ１０２において、受信判定部１１は、現在のタイムスタンプ値ｔｎｏｗを取得する。
　Ｓ１０３において、受信判定部１１は、現在の送信スケジュールに対するオフセット値ＴｎｏｗをＴｎｏｗ＝（ｔｎｏｗ－ｔ０）　ｍｏｄ　Ｔｃｙｃｌｅにより算出する。Ｓ１０４において、受信判定部１１は、Ｔｎｏｗ≧Ｔｏｐｅｎかどうかを判断し、ＹｅｓであればＳ１０５に進み、ＮｏであればＳ１０７に進む。Ｓ１０５において、受信判定部１１は、Ｔｎｏｗ≦Ｔｃｌｏｓｅかどうかを判断し、ＹｅｓであればＳ１０６に進み、ＮｏであればＳ１０８に進む。
　Ｓ１０６において、受信判定部１１は、パケットｉをクラス付与部１２２へ転送する。Ｓ１０７において、受信判定部１１は、次の受信許可時刻ｔｉ ｏｐｅｎ＝ｔｎｏｗ＋（Ｔｏｐｅｎ－Ｔｎｏｗ）＋Ｔｏｐｅｎを基準にパケットｉをｒｂｔｒｅｅデータ構造の受信バッファ１３へ格納する。Ｓ１０８において、受信判定部１１は、次の受信許可時刻ｔｉ ｏｐｅｎ＝ｔｎｏｗ＋（Ｔｃｙｃｌｅ－Ｔｎｏｗ）＋Ｔｏｐｅｎを基準にパケットｉをｒｂｔｒｅｅデータ構造の受信バッファ１３へ格納する。なお、受信許可時刻は、送信制御部１４０で受信処理を開始できる時刻であり、これを受信開始時刻あるいは受信処理開始時刻と呼んでもよい。
　図１０は、受信バッファ１３からクラス付与部１２２への転送フローである。Ｓ２０１において、受信判定部１１は、現在のタイムスタンプ値ｔｎｏｗを取得する。Ｓ２０２において、受信判定部１１は、受信バッファ１３内のパケット群のうち最小のｔｉ ｏｐｅｎがｔｎｏｗと等しいパケットｉの有無を判断し、Ｙｅｓ（パケット有）であればＳ２０３に進み、ＮｏであればＳ２０４に進む。
　Ｓ２０３において、受信判定部１１は、パケットｉをクラス付与部１２２へ転送し、受信バッファ１３から削除する。Ｓ２０４において、待機し、Ｓ２０５において、受信判定部１１は、「ｒｂｔｒｅｅに新規データ挿入があり、かつ、ｍｉｎ｛ｔｉ ｏｐｅｎ｝に更新あり」か否かを判断し、ＹｅｓであればＳ２０６に進み、ＮｏであればＳ２０１に戻る。Ｓ２０６において、ｍｉｎ｛ｔｉ ｏｐｅｎ｝‐ｔｎｏｗの時間が経過したらＳ２０１に戻る。
　＜実施例１における受信制御部１２１の受信判定方法２＞
　実施例１における受信制御部１２１の受信判定方法２について説明する。受信制御部１２１の受信判定部１１は、パケット受信時の処理演算量を削減するために、受信許可の開始と終了を示す絶対時刻ｔｏｐｅｎ、ｔｃｌｏｓｅを別スレッドで常時計算しておき、パケット受信時は現在時刻の取得と、受信許可期間に含まれるかの判定のみを行う。
　図１１、図１２を参照して、受信判定方法２における受信判定部１１の動作例を説明する。受信バッファからの送信処理は受信判定方法１と同じである。
　図１１は、受信許可時刻算出フローを示す。Ｓ３０１において、受信判定部１１は、サイクルの開始時刻ｔｂａｓｅ＝ｔ０とする。受信判定部１１は、受信開始時刻をｔｏｐｅｎ＝ｔｂａｓｅ＋Ｔｏｐｅｎにより算出し、受信終了時刻を、ｔｃｌｏｓｅ＝ｔｂａｓｅ＋Ｔｃｌｏｓｅにより算出する。
　Ｓ３０３において、Ｔｃｙｃｌｅ経過すると、Ｓ３０４においてｔｂａｓｅ＝ｔｂａｓｅ＋Ｔｃｙｃｌｅとしてｔｂａｓｅを計算し、Ｓ３０２に戻る。
　図１２は、受信判定部１１のパケット受信時の処理フローである。Ｓ４０１において、受信判定部１１は、ゲスト１１０からパケットｉを受信する。Ｓ４０２において、受信判定部１１は、現在のタイムスタンプ値ｔｎｏｗを取得する。
　Ｓ４０３において、受信判定部１１は、ｔｎｏｗ≧ｔｏｐｅｎかどうかを判断し、ＹｅｓであればＳ４０４に進み、ＮｏであればＳ４０６に進む。Ｓ４０４において、受信判定部１１は、ｔｎｏｗ≦ｔｃｌｏｓｅかどうかを判断し、ＹｅｓであればＳ４０５に進み、ＮｏであればＳ４０７に進む。
　Ｓ４０５において、受信判定部１１は、パケットｉをクラス付与部１２２へ転送する。Ｓ４０６において、受信判定部１１は、パケットｉの受信開始時刻ｔｉ ｏｐｅｎ＝ｔｏｐｅｎを基準にパケットｉをｒｂｔｒｅｅデータ構造の受信バッファ１３へ格納する。
　Ｓ４０７において、受信判定部１１は、パケットｉの受信開始時刻ｔｉ ｏｐｅｎ＝ｔｏｐｅｎ＋Ｔｃｙｃｌｅを基準にパケットｉをｒｂｔｒｅｅデータ構造の受信バッファ１３へ格納する。
　＜実施例１における受信制御部１２１の受信判定方法３＞
　実施例１における受信制御部１２１の受信判定方法３について説明する。受信判定方法３では、受信判定方法２の受信許可時刻算出フロー内で、受信可否を示すｃａｎＲｃｖと次の送信許可開始時刻を常時算出しておくことで、パケット受信時のフロー内の演算量を更に削減する。パケット受信時は真偽値ｃａｎＲｃｖの判定を行って、ｃａｎＲｃｖ＝ｆａｌｓｅの際に、受信バッファ１３への格納のみを行う。
　図１３と図１４を参照して、受信判定部１１の動作例を示す。受信バッファ１３からの送信処理は受信判定方法１と同じである。
　図１３に、受信許可時刻算出フローを示す。Ｓ５０１において、受信判定部１１は、ｔｏｐｅｎ＝ｔ０＋Ｔｏｐｅｎ、ｔｃｌｏｓｅ＝ｔ０＋Ｔｃｌｏｓｅ、ｃａｎＲｃｖ＝ｆａｌｓｅを計算する。Ｓ５０２において、受信判定部１１は、現在のタイムスタンプ値ｔｎｏｗを取得する。
　Ｓ５０３において、受信判定部１１は、ｔｎｏｗ≧ｔｏｐｅｎかどうかを判断し、ＹｅｓであればＳ５０４に進み、ＮｏであればＳ５０６に進む。Ｓ５０４において、受信判定部１１は、ｔｎｏｗ＞ｔｃｌｏｓｅかどうかを判断し、ＹｅｓであればＳ５０５に進み、ＮｏであればＳ５０７に進む。
　Ｓ５０５において、受信判定部１１は、ｃａｎＲｃｖ＝ｆａｌｓｅ、ｔｏｐｅｎ＝ｔｏｐｅｎ＋Ｔｃｙｃｌｅ、ｔｃｌｏｓｅ＝ｔｃｌｏｓｅ＋Ｔｃｙｃｌｅを計算する。Ｓ５０６において、ｃａｎＲｃｖ＝ｆａｌｓｅとし、Ｓ５０７においてｃａｎＲｃｖ＝ｔｒｕｅとする。
　図１４は、受信判定部１１のパケット受信時の処理フローである。Ｓ６０１において、受信判定部１１は、ゲスト１１０からパケットｉを受信する。Ｓ６０２において、受信判定部１１は、ｃａｎＲｃｖ＝ｔｒｕｅか否かを判定し、ＹｅｓであればＳ６０３に進み、ＮｏであればＳ６０４に進む。
　Ｓ６０３において、受信判定部１１は、パケットｉをクラス付与部１２２へ転送する。Ｓ６０４において、受信判定部１１は、次の受信許可時刻ｔｉ ｏｐｅｎ＝ｔｏｐｅｎを基準にパケットｉをｒｂｔｒｅｅデータ構造の受信バッファ１３へ格納する。
　１周期に複数回（ｎ回）の受信許可時間が存在する場合、１回目の時刻ｔｏｐｅｎ，１、ｔｃｌｏｓｅ，１からｎ回目の時刻ｔｏｐｅｎ，ｎ、ｔｃｌｏｓｅ，ｎを用意しておき、ｔｎｏｗ＞ｔｃｌｏｓｅ，ｉとなった場合、次のｉ＋１番目の受信許可時間との判定を行う。
　図１５に、この場合の受信許可時刻算出フローを示す。Ｓ７０１においてｉ＝１とし、Ｓ７０２～Ｓ７０４において、受信判定部１１は、ｔｏｐｅｎ，ｉ＝ｔ０＋Ｔｏｐｅｎ，ｉ、ｔｃｌｏｓｅ，ｉ＝ｔ０＋Ｔｃｌｏｓｅ，ｉ、ｃａｎＲｃｖ＝ｆａｌｓｅをｎ回分計算する。Ｓ７０５においてｉ＝１とし、Ｓ７０６において、受信判定部１１は、現在のタイムスタンプ値ｔｎｏｗを取得する。Ｓ７０７とＳ７１２の間で以下の処理をｎ回分行う。
　Ｓ７０８において、受信判定部１１は、ｔｎｏｗ≧ｔｏｐｅｎ，ｉかどうかを判断し、ＹｅｓであればＳ７０９に進み、ＮｏであればＳ７１３に進む。Ｓ７０９において、受信判定部１１は、ｔｎｏｗ＞ｔｃｌｏｓｅ，ｉかどうかを判断し、ＹｅｓであればＳ７１０に進み、ＮｏであればＳ７１４に進む。
　Ｓ７１０において、受信判定部１１は、ｃａｎＲｃｖ＝ｆａｌｓｅ、ｔｏｐｅｎ，ｉ＝ｔｏｐｅｎ，ｉ＋Ｔｃｙｃｌｅ、ｔｃｌｏｓｅ，ｉ＝ｔｃｌｏｓｅ，ｉ＋Ｔｃｙｃｌｅを算出する。Ｓ７１３において、ｃａｎＲｃｖ＝ｆａｌｓｅとし、Ｓ７１４においてｃａｎＲｃｖ＝ｔｒｕｅとする。
　＜スケジュールＤＢ１３０で管理するスケジュール情報＞
　次に、スケジュールＤＢ１３０で管理するスケジュール情報の例について説明する。スケジュールＤＢ１３０では、受信制御部１２１と送信制御部１４０における、時分割送信制御のスケジュール情報を管理する。以下にスケジュール情報を３階層のデータ構造で表す例を示す。図１７の（ａ）が第１階層を示し、（ｂ）が第２階層を示し、（ｃ）が第３階層を示す。
　第１階層は、タイムスロットの送信開始相対時刻（Ｇａｔｅ　ｏｐｅｎ）と送信終了相対時刻（Ｇａｔｅ　ｃｌｏｓｅ）を格納し、タイムスロットごとの送信クラスを第２階層に格納する。第３階層は、送信クラス内で送信するｆｌｏｗ情報（ホスト（中継装置）側の受信インターフェース、ｆｌｏｗ識別子、送信量）を管理する。
　送信開始／終了相対時刻は、送信周期が開始される基準時刻ｔ０からの経過時間を示す。ｆｌｏｗ識別子は送受信ＭＡＣアドレス、送受信ＩＰアドレス、送受信ポート番号、プロトコル種別、VLAN番号、VLAN PCP、DSCP値等のパケットヘッダ情報のいずれか１つ、またはいずれか複数であってもよいし、それらから算出されるハッシュ値であってもよい。
　送信制御部１４０は、第１、２階層の情報を元に送信クラスに紐づくキューの送信処理を時分割で変更する。
　スケジュール情報を受信Ｉ／Ｆ毎に整理したデータ構造を図１８に示す。図８において、第２～第４階層が図１７の第１～第３階層に対応する。各ｖＮＩＣに紐づく受信制御部１２１は、第２階層のタイムスロットのＧａｔｅ　ｏｐｅｎ／ｃｌｏｓｅの値をＴｏｐｅｎ、Ｔｃｌｏｓｅとして用いる。
　また受信制御部１２１内のメタデータ付与部１２は、受信パケットの送受信ＩＰアドレス等のｆｌｏｗ識別子情報に基づいて第４階層のテーブルを参照し、合致する送信クラスの情報をパケットのメタデータとして受信パケットに付与する。
　ゲスト１１０から送信されるパケットのｆｌｏｗ識別子が一意に定まる（ゲストから一種類の通信しか行われない場合）場合、１つのタイムスロットで送信される送信クラス及びｆｌｏｗ識別子は一意に定まる。
　（実施例２：クラス付与部でクラス判定を行う方式）
　次に、実施例２について説明する。実施例２では、各受信制御部１２１で行っていたクラス情報のメタデータ付与を、クラス付与部１２２にて一括して行う。クラス付与部１２２は、パケットのクラス判定を行う必要があるため、スケジュールＤＢ１３０から、スケジュール情報を参照する。実施例２のホスト１００の構成を示す図１９において、クラス付与部１２２によりスケジュール情報を参照することを示す線が示されている。
　図２０に、実施例２における受信制御部１２１の構成例を示す。図２０に示すように、実施例２における受信制御部１２１は、受信判定部１１と受信バッファ１３を備える。受信制御部１２１は、受信判定部１１による受信可否の判定と、受信不可の場合のバッファ処理のみ行う。なお、「受信可否」とは、送信制御部１４０によるパケット受信が可か否かということである。
　図２１に、実施例２におけるクラス付与部１２２の構成例を示す。図２１に示すように、クラス付与部１２２は、クラス判定部２１と識別子付与部２２を備える。クラス判定部２１は、受信制御部１２１から受信したパケットのクラスを判定し、識別子付与部２２は、判定したクラスに対応するＶＬＡＮタグ等の識別子を付与する。クラス判定を受信制御部１２１ではなく、クラス付与部１２２で行うこと以外の処理は、実施例１と同じである。
　（実施例３：通信種別毎にインターフェースを持つ方式）
　次に、実施例３を説明する。実施例１、２では、ゲスト１１０から複数種類の通信（宛先ＩＰアドレス、送受信ポート番号、プロトコル種別等が異なる通信）を行う場合に、スケジュールＤＢ１３０の検索量が増え、遅延が生じる。
　そこで、実施例３では、ゲスト１１０から行う通信の数だけ中継装置にｖＮＩＣを用意し、一つの通信種別は一つのｖＮＩＣを用いることで、クラス判定処理を高速化する。
　図２２は、ある一つのゲスト１１０が３つのｖＮＩＣ１～３によってホスト１００側の仮想中継装置１２０と接続されている例を示す。
　３つのｖＮＩＣ１～３はそれぞれ異なるネットワークに所属していてもよいし、同一のＬ２ネットワークに属していてもよい。同一のＬ２ネットワークに所属する場合、ゲスト１１０は更に所属するｖＮＩＣの数だけルーティングテーブルを持ち、送信元ＩＰのアドレスによって参照するルーティングテーブルを変更する。図２２は、そのような例を示している。
　図２３に、一つのｖＮＩＣに対して、一つの通信のみを割当てることで、受信Ｉ／Ｆ毎に整理したスケジュール情報を示す。図２３に示すスケジュール情報を用いることで、各ｖＮＩＣに対応する受信制御部１２１は、受信可否を判定するためのタイムスロット情報を参照するだけで、送信クラスまで特定できるため、送信クラス判定のためだけのＤＢ参照が不要となる。これにより、検索量を削減でき、遅延を削減できる。
　（実施例４：受信制御部１２１にてタイムスロット毎に受信バッファを持つ方式）
　次に実施例４を説明する。実施例４では、受信制御部１２１にて、予め１周期のタイムスロット分の受信バッファを用意しておくことで、パケット単位で受信判定・受信バッファから取り出す処理をするのではなく、タイムスロット単位で処理を行うことで、受信判定部１１の演算量を削減する。
　図２４に、実施例４における受信制御部１２１の構成例を示す。図２４に示すように、実施例４における受信制御部１２１は、受信判定部１１、送信判定部１５、各タイムスロット用の受信バッファを備える。
　受信判定部１１は、ｖＮＩＣから受信したパケットについて、どのタイムスロットで送信するかをスケジュールＤＢ１３０の情報を元に判定し、パケットが送信されるタイムスロットに対応する受信バッファへパケットを格納する。
　送信判定部１５は、スケジュールＤＢ１３０の情報を元に、送信制御部１４０と同じスケジュールでそれぞれのタイムスロット用受信バッファからパケットを読み出してクラス付与部１２２へ送信する。
　（実施例５：タイムスロット毎に送信キューを分ける方式）
　次に、実施例５を説明する。実施例５では、受信制御部１２１で受信バッファによる受信タイミング制御を行うのではなく、送信制御部１４０にて、送信スケジュールのうち、１周期内の同じクラスの通信を異なる送信キューに振り分けることで、送信スケジュールのズレを防止する。
　実施例５では、１周期のスケジュールに、複数回同じ送信クラスが割り当てられている場合、それぞれ別の送信キューを用意する。図２５は１周期における送信許可クラスの例を示す。図２５における、例えば１－３は、送信許可クラス１に対応する３番目の送信キューを示す。例えば、１－１、１－２、１－３は、同じ送信クラス１に異なる送信キューが割り当てられることを示す。
　なお、説明の便宜上、同じ時間に一つの送信クラスを割り当てているが、同時に複数の送信クラスを割当てることも可能である。
　図２６に、実施例５における受信制御部１２１の構成例を示す。図２６に示すように、受信制御部１２１は、受信バッファ１３を持たず、クラス判定部２１を持つ。クラス判定部２１は、スケジュールＤＢ１３０の情報に基づいて、受信したパケットの送信クラスと、１周期内の何番目のタイムスロットに割り当てられているかを判定し、送信クラス、タイムスロット情報をパケットのメタデータとして付与し、クラス付与へ送信する。なお、受信制御部１２１内にクラス付与部１２２を含め、受信制御部１２１がクラス識別付与まで行ってもよい。
　実施例２同様、受信制御部１２１ではなく、クラス付与部１２２で直接判定、クラス付与まで行ってもよい。その場合、受信制御部１２１は不要となる。なお、この場合、クラス付与部１２２を受信制御部１２１と呼んでもよい。つまり、受信制御部１２１としてクラス付与部１２２を使用してもよい。
　図２７に、送信制御部１４０の構成例を示す。図２７に示すとおり、送信制御部１４０は、クラス分類部１４１、送信ゲート開閉部１４２、及び、送信クラス毎に、複数の送信キューを備え、送信クラスと付与されたタイムスロット情報に基づいて、送信キューにパケットを振り分ける。
　送信ゲート開閉部１４２は、送信キュー毎に、スケジュール情報に従って、ゲートの開閉を行う。実施例５では、送信制御部１４０における送信キューが受信バッファの役割を果たし、これにより、ジッタ保証を実現できる。
　（実施例６：一つの物理ＮＩＣに本発明に係る技術を適用する例）
　次に、実施例６を説明する。実施例６では、実施例１－５のいずれか１つ、またはいずれか複数の組み合わせを一つの物理ＮＩＣ１５０内で実施する。
　図２８に、実施例６におけるホスト１００の構成例を示す。図２８に示すように、物理ＮＩＣ１５０内に複数の仮想的なＮＩＣであるＶＦと、ＶＦ毎に受信制御部１２１（実施例５以外の場合）を持ち、更にクラス付与部１２２、送信制御部１４０、スケジュールＤＢ１３０を備える。スケジュールＤＢ１３０はホスト側に具備してもよい。また、図２８に示す構成において、ＶＦ、受信制御部１２１、及びクラス付与部１２２からなる部分を「中継装置」と呼んでもよい。
　各ゲスト１１０は、ホストの内部処理（Ｌｉｎｕｘ　Ｋｅｒｎｅｌ内のＮｅｔｗｏｒｋ処理等）をバイパスし、物理ＮＩＣ１５０上のＶＦを直接利用する。これは例えばSingle Root I/O Virtualizationによって実現できる。
　（実施例１～６に共通の事項）
　これまでに説明した受信制御部１２１、クラス付与部１２２、送信制御部１４０の機能に関して、同一の機能が他の機能も担当することとしてもよい。例えば、受信制御部１２１内に、クラス付与部１２２、送信制御部１４０の機能を持つことでも、本発明に係る技術の効果を発揮できる。
　また、受信制御部１２１から送信制御部１４１に向けてパケットを送信する時刻は、受信制御部１２１から送信制御部１４０への転送遅延を予め算出した上で、転送遅延分早く行うこととしてもよい。
　（ハードウェア構成例）
　本実施の形態において説明した装置（ホスト、ゲスト、ゲストと同様の機能を持つサーバ、中継装置、仮想中継装置、通信制御装置）はいずれも、例えば、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。当該コンピュータは、物理的なマシンであってもよいし、クラウド上の仮想マシンであってもよい。
　上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。
　図２９は、上記コンピュータのハードウェア構成例を示す図である。図２９のコンピュータは、それぞれバスＢで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インターフェース装置１００５、表示装置１００６、入力装置１００７、出力装置１００８等を有する。
　当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ－ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
　メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、当該装置に係る機能を実現する。インターフェース装置１００５は、ネットワークに接続するためのインターフェースとして用いられる。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。出力装置１００８は演算結果を出力する。
　（実施の形態のまとめ）
　以上説明した本実施の形態においては、通信アプリケーションが動作する複数のサーバと接続する中継装置において、時分割送信制御を行う外部ネットワークと接続する送信インターフェースと同期して、各サーバと接続する中継装置側の受信インターフェースのパケット受信処理を行う。
　より具体的には、前記受信インターフェースにおいて、受信パケットのフロー情報と受信時刻から、受信パケットが前記送信インターフェースにて送信されるタイムスロットとクラスを判別し、送信クラス識別子をパケットに付与する。
　また、実施例１で説明したように、判別した受信パケットと、前記送信インターフェースにおける受信パケットの送信時刻から算出した受信処理開始時刻を対応づけることで、受信処理開始時刻までパケットを一時的にバッファし、前記送信インターフェースで送信処理を行う直前に前記受信インターフェースから前記物理インターフェースへ受信パケットを転送する。
　実施例４で説明したように、前記受信インターフェースにおいて、送信インターフェースが行う時分割送信スケジュール１周期に含まれるタイムスロット分の独立した受信バッファを具備し、送信インターフェースが行う時分割送信スケジュールと同期して受信バッファからパケットを転送することとしてもよい。
　実施例３で説明したとおり、ゲスト－ホスト間を複数の仮想送受信インターフェースで接続し、１対の送受信インターフェースに１種類の通信を割当てることで、前記受信インターフェースにおけるクラスの判別処理を高速化することとしてもよい。
　また、実施例５で説明したように、前記送信インターフェースにおいて、１周期分のタイムスロット毎の仮想送信キューを具備し、前記受信インターフェースにおいて、どのタイムスロットで送信するパケットかを判別し、識別子の付与を行うことで、本来のタイムスロットとは異なる時間に受信したパケットでも本来の送信タイムスロットに対応する送信キューへ振り分けることとしてもよい。
　また、実施例６で説明したように、上記の構成のいずれか１つ又はいずれか複数を組み合わせた通信方式を一つの物理ＮＩＣ内で完結して実施することとしてもよい。
　上述した通信方式は従来技術にはないものである。
　すなわち、通常スイッチ等でボトルネックとなるのは、複数のトラヒックが合流する送信側のため、既存のＬｉｎｕｘ（登録商標）や市販スイッチ等では受信側におけるトラヒック制御を行う仕組みは用意されておらず、Ｑｂｖの仕様についても同様に送信側の制御のみを規定している。
　一方、本発明に係る技術のように、複数の受信インターフェースにおいてトラヒック制御を行い、かつ複数受信インターフェースおよび送信インターフェースが協調してトラヒック制御を行う方式は従来技術には存在しない。
　また、ＱｂｖはＶＬＡＮタグのＣｏＳ値により制御するため、仮想環境下におけるホスト内部のＶＬＡＮタグが付いていなネットワーク内部の遅延保証や、複数の異なるユーザが利用するマルチテナントデータセンタの遅延保証は、既存のＱｂｖや送信側の制御だけではできず、本発明に係る技術によって解決できるものである。
　（実施の形態の効果）
　以上説明した本実施の形態により、ゲストマシン側で複雑な時分割送信制御をすることなく、他のゲストマシンとのトラヒック衝突によるキューイング遅延の増加や送信スケジュールのずれを防ぎ、ジッタを保証することが可能となる。また、ゲストマシン側の設定ミスやＤｏＳ攻撃によるＴＳＮ送信スケジュールへの影響を無効にすることができる。
　（付記）
　本明細書には、少なくとも下記各項の通信制御装置、通信制御方法、及びプログラムが開示されている。
（第１項）
　アプリケーションが動作するサーバからパケットを受信する複数の受信制御部を備え、各受信制御部は、
　受信バッファと、
　外部ネットワークと接続する送信インターフェースにおいて前記パケットを受信可能な時刻に、前記パケットを前記送信インターフェースに向けて送信し、前記送信インターフェースにおいて前記パケットを受信不可の時刻に、前記パケットを前記受信バッファに格納する受信判定部と
　を備える通信制御装置。
（第２項）
　前記送信インターフェースにおける時分割送信制御のためのスケジュール情報に基づいて、前記パケットのタイムスロットと送信クラスを判別し、前記パケットに送信クラス識別子を付与するクラス付与部
　を備える第１項に記載の通信制御装置。
（第３項）
　前記受信判定部は、前記送信インターフェースにおける時分割送信制御のためのスケジュール情報に基づいて、前記受信可能な時刻の開始及び終了を常時計算し、現在時刻と前記受信可能な時刻の開始及び終了とを比較することにより、現在時刻が前記送信インターフェースにおいて前記パケットを受信可能な時刻であるか否かを判定する
　第１項又は第２項に記載の通信制御装置。
（第４項）
　前記通信制御装置は、前記サーバとの通信における通信種別毎に前記受信制御部を備える
　第１項ないし第３項のうちいずれか１項に記載の通信制御装置。
（第５項）
　前記受信制御部は、前記送信インターフェースにおける時分割送信スケジュールの１周期に含まれるタイムスロット毎に前記受信バッファを備える
　第１項ないし第４項のうちいずれか１項に記載の通信制御装置。
（第６項）
　アプリケーションが動作するサーバからパケットを受信する複数の受信制御部と、
　外部ネットワークと接続し、送信クラス毎に複数の送信キューを持つ送信制御部と、を備え、
　前記受信制御部は、前記送信制御部における時分割送信制御のためのスケジュール情報に基づいて、前記パケットの送信クラスとタイムスロットを判定し、送信クラスとタイムスロット情報を前記パケットに付加して前記送信制御部に送信し、
　前記送信制御部は、前記パケットに付与された送信クラスとタイムスロット情報に基づいて、前記パケットを１つの送信キューに振り分ける
　通信制御装置。
（第７項）
　アプリケーションが動作するサーバからパケットを受信する複数の受信制御部を備える通信制御装置における通信制御方法であって、
　各受信制御部は、受信バッファを備え、外部ネットワークと接続する送信インターフェースにおいて前記パケットを受信可能な時刻に、前記パケットを前記送信インターフェースに向けて送信し、前記送信インターフェースにおいて前記パケットを受信不可の時刻に、前記パケットを前記受信バッファに格納する
　通信制御方法。
（第８項）
　コンピュータを、第１項ないし第６項のうちいずれか１項に記載の通信制御装置における各部として機能させるためのプログラム。
　以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
１１　受信判定部
１２　メタデータ付与部
１３　受信バッファ
１５　送信判定部
２１　クラス判定部
２２　識別子付与部
１００　ホスト
１１０　ゲスト
１２０　仮想中継装置
１２１　受信制御部
１２２　クラス付与部
１３０　スケジュールＤＢ
１４０　送信制御部
１４１　クラス分類部
１４２　送信ゲート開閉部
１５０　物理ＮＩＣ
２００　クライアント端末
３００、４００　中継装置
５００　ＴＳＮドメイン
１０００　ドライブ装置
１００１　記録媒体
１００２　補助記憶装置
１００３　メモリ装置
１００４　ＣＰＵ
１００５　インターフェース装置
１００６　表示装置
１００７　入力装置

Claims (8)

  1. 　アプリケーションが動作するサーバからパケットを受信する複数の受信制御部を備え、各受信制御部は、
    　受信バッファと、
    　外部ネットワークと接続する送信インターフェースにおいて前記パケットを受信可能な時刻に、前記パケットを前記送信インターフェースに向けて送信し、前記送信インターフェースにおいて前記パケットを受信不可の時刻に、前記パケットを前記受信バッファに格納する受信判定部と
    　を備える通信制御装置。
  2. 　前記送信インターフェースにおける時分割送信制御のためのスケジュール情報に基づいて、前記パケットのタイムスロットと送信クラスを判別し、前記パケットに送信クラス識別子を付与するクラス付与部
    　を備える請求項１に記載の通信制御装置。
  3. 　前記受信判定部は、前記送信インターフェースにおける時分割送信制御のためのスケジュール情報に基づいて、前記受信可能な時刻の開始及び終了を常時計算し、現在時刻と前記受信可能な時刻の開始及び終了とを比較することにより、現在時刻が前記送信インターフェースにおいて前記パケットを受信可能な時刻であるか否かを判定する
    　請求項１又は２に記載の通信制御装置。
  4. 　前記通信制御装置は、前記サーバとの通信における通信種別毎に前記受信制御部を備える
    　請求項１ないし３のうちいずれか１項に記載の通信制御装置。
  5. 　前記受信制御部は、前記送信インターフェースにおける時分割送信スケジュールの１周期に含まれるタイムスロット毎に前記受信バッファを備える
    　請求項１ないし４のうちいずれか１項に記載の通信制御装置。
  6. 　アプリケーションが動作するサーバからパケットを受信する複数の受信制御部と、
    　外部ネットワークと接続し、送信クラス毎に複数の送信キューを持つ送信制御部と、を備え、
    　前記受信制御部は、前記送信制御部における時分割送信制御のためのスケジュール情報に基づいて、前記パケットの送信クラスとタイムスロットを判定し、送信クラスとタイムスロット情報を前記パケットに付加して前記送信制御部に送信し、
    　前記送信制御部は、前記パケットに付与された送信クラスとタイムスロット情報に基づいて、前記パケットを１つの送信キューに振り分ける
    　通信制御装置。
  7. 　アプリケーションが動作するサーバからパケットを受信する複数の受信制御部を備える通信制御装置における通信制御方法であって、
    　各受信制御部は、受信バッファを備え、外部ネットワークと接続する送信インターフェースにおいて前記パケットを受信可能な時刻に、前記パケットを前記送信インターフェースに向けて送信し、前記送信インターフェースにおいて前記パケットを受信不可の時刻に、前記パケットを前記受信バッファに格納する
    　通信制御方法。
  8. 　コンピュータを、請求項１ないし６のうちいずれか１項に記載の通信制御装置における各部として機能させるためのプログラム。
PCT/JP2021/022579 2021-06-14 2021-06-14 通信制御装置、通信制御方法、及びプログラム WO2022264230A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2021/022579 WO2022264230A1 (ja) 2021-06-14 2021-06-14 通信制御装置、通信制御方法、及びプログラム
JP2023528772A JPWO2022264230A1 (ja) 2021-06-14 2021-06-14

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/022579 WO2022264230A1 (ja) 2021-06-14 2021-06-14 通信制御装置、通信制御方法、及びプログラム

Publications (1)

Publication Number Publication Date
WO2022264230A1 true WO2022264230A1 (ja) 2022-12-22

Family

ID=84526663

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/022579 WO2022264230A1 (ja) 2021-06-14 2021-06-14 通信制御装置、通信制御方法、及びプログラム

Country Status (2)

Country Link
JP (1) JPWO2022264230A1 (ja)
WO (1) WO2022264230A1 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019054350A (ja) * 2017-09-13 2019-04-04 株式会社東芝 転送装置、転送方法及びプログラム
JP2019053591A (ja) * 2017-09-15 2019-04-04 株式会社東芝 通知制御装置、通知制御方法及びプログラム
WO2019224860A1 (ja) * 2018-05-21 2019-11-28 三菱電機株式会社 通信装置、通信方法及び通信プログラム
WO2020031908A1 (ja) * 2018-08-06 2020-02-13 オムロン株式会社 通信システム、通信装置および通信方法
JP2020048045A (ja) * 2018-09-18 2020-03-26 株式会社東芝 スイッチ装置、スイッチング方法及びプログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019054350A (ja) * 2017-09-13 2019-04-04 株式会社東芝 転送装置、転送方法及びプログラム
JP2019053591A (ja) * 2017-09-15 2019-04-04 株式会社東芝 通知制御装置、通知制御方法及びプログラム
WO2019224860A1 (ja) * 2018-05-21 2019-11-28 三菱電機株式会社 通信装置、通信方法及び通信プログラム
WO2020031908A1 (ja) * 2018-08-06 2020-02-13 オムロン株式会社 通信システム、通信装置および通信方法
JP2020048045A (ja) * 2018-09-18 2020-03-26 株式会社東芝 スイッチ装置、スイッチング方法及びプログラム

Also Published As

Publication number Publication date
JPWO2022264230A1 (ja) 2022-12-22

Similar Documents

Publication Publication Date Title
US11563602B2 (en) Method and apparatus for providing a point-to-point connection over a network
US20170257269A1 (en) Network controller with integrated resource management capability
US10986041B2 (en) Method and apparatus for virtual network functions and packet forwarding
US10606454B2 (en) Stage upgrade of image versions on devices in a cluster
CN105591863B (zh) 一种实现虚拟私有云网络与外部网络互通的方法和装置
CN113811858A (zh) 使用机架顶交换机启用对虚拟网络中的专用资源的访问
US9961021B2 (en) Enabling applications in a multi-transport stack environment
KR101893963B1 (ko) 소프트웨어 정의 프로토콜 네트워크 노드를 위한 시스템 및 방법
EP2760174A1 (en) Virtual private cloud access authentication method and related apparatus
JP4663761B2 (ja) パケット中継装置
US20160323189A1 (en) Method for controlling qos by handling traffic depending on service
CN103748558A (zh) 虚拟网络覆盖
US9654394B2 (en) Multi-tenant system, switch, controller and packet transferring method
WO2015149604A1 (zh) 一种负载均衡方法、装置及系统
CN101964799A (zh) 点到网隧道方式下地址冲突的解决方法
Davoli et al. Implementation of service function chaining control plane through OpenFlow
CN112602292B (zh) 5g核心网中的片间共享
US20220385497A1 (en) Method for network slices to share uplink port, apparatus, and storage medium
US10581738B2 (en) Efficient inter-VLAN routing in openflow networks
KR20180104377A (ko) 패킷 광 전송 네트워크를 통한 클라우드 간 가상 네트워킹 제공 방법
US20200112500A1 (en) Adaptive polling in software-defined networking (sdn) environments
KR101794719B1 (ko) Sdn 기반 네트워크 가상화 플랫폼에서의 ip 주소 가상화 방법 및 시스템
WO2022264230A1 (ja) 通信制御装置、通信制御方法、及びプログラム
CN112671811B (zh) 一种网络接入方法和设备
KR20200076342A (ko) 가상 네트워크 기반 분산 다중 데이터처리방법

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2023528772

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21945910

Country of ref document: EP

Kind code of ref document: A1