WO2021161463A1 - 通信システム、通信方法及び通信プログラム - Google Patents

通信システム、通信方法及び通信プログラム Download PDF

Info

Publication number
WO2021161463A1
WO2021161463A1 PCT/JP2020/005606 JP2020005606W WO2021161463A1 WO 2021161463 A1 WO2021161463 A1 WO 2021161463A1 JP 2020005606 W JP2020005606 W JP 2020005606W WO 2021161463 A1 WO2021161463 A1 WO 2021161463A1
Authority
WO
WIPO (PCT)
Prior art keywords
user terminal
packet
transfer device
unit
service
Prior art date
Application number
PCT/JP2020/005606
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/JP2020/005606 priority Critical patent/WO2021161463A1/ja
Publication of WO2021161463A1 publication Critical patent/WO2021161463A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks

Definitions

  • the present invention relates to a communication system, a communication method and a communication program.
  • NFV Network Function Virtualization
  • Network edge provides various functions including tunnel termination. Each of these network functions may require different amounts of system resources (CPU, memory capacity, etc.) or may fluctuate over time. For this reason, we would like to utilize NFV and make the edge function distributed and deployed so that the necessary resources can be prepared as much as necessary. In such a deployment, it is necessary to select the packet to be serviced and forward it to the service unit that provides the necessary edge function.
  • system resources CPU, memory capacity, etc.
  • the matching condition is described in the firewall filter, and an M / A (Match / Action) rule is set so that the corresponding packet is forwarded in a direction different from the normal routine. It is possible to do so. This setting takes precedence over normal routing.
  • a method for confirming that a packet correctly reaches a target device via VNF (Virtual Network Function) distributed in this way is desired.
  • VNF Virtual Network Function
  • a method of confirming the arrival of a packet to a target device and the communication to the target device a method of verifying operation using an actual machine before use, and confirmation of IP communication such as ping and Traceroute.
  • IPMP Internet Control Message Protocol
  • the matching condition is described in the filter of the transfer device, and the transfer process is performed in a direction different from the normal routine. Since it is not possible to match the matching conditions with the commonly used ICMP for these specific packets, it is not possible to confirm the communication from the user terminal to the service unit, including the matching of the route and the transfer processing on the route. (It is not possible to confirm whether or not the filter is set correctly on the transfer device).
  • a filter for transferring a specific packet may be newly set in the transfer device after the start of commercialization, and the filter processing in the transfer device is correctly performed by means other than transmitting a packet matching the filter conditions from the user terminal. It is difficult to confirm whether it is operating, that is, from the standpoint of the network operator.
  • FIG. 9 is a diagram showing a 5-tuple for distinguishing a specific user and a specific flow of service traffic.
  • FIG. 10 is a diagram showing 5-tuple when ICMP is used.
  • the source IP address is fixed to the user terminal, but other conditions differ for each service, so that the specific service It can be a condition for identifying (especially the port number).
  • the destination IP address can be freely specified, so that the filter setting can be confirmed under the same conditions as the service packet. difficult.
  • the filter condition when the filter condition is specified by 5-tuple, the part that can be confirmed by ICMP is considerably limited. In ICMP, the port number cannot be confirmed, and the protocol number of the IP header is also fixed. Therefore, in order to match the filter conditions for actual service traffic, it is usually necessary to specify the conditions with the source IP address or the destination IP address. However, if the source IP address is transferred to the service unit as a condition, the traffic of all the relevant users will be filtered, and the specific traffic will not be selected.
  • test tool As a test packet imitating a user, for example, a ping in which the source IP address is the user terminal and the destination IP address is the IF of the device on the core network side, and the VLAN corresponding to the user terminal is used. Further functionality is needed to generate packets with headers. In such a case, since the return of the ping is returned to the user, a function of accepting the return packet is also required separately, which complicates the system configuration. In addition, since the number of users is enormous, the number of interposing test tools is also enormous, and the preparation cost of test equipment is high.
  • the present invention has been made in view of the above, and an object of the present invention is to provide a communication system, a communication method, and a communication program that can easily confirm that the filter of the transfer device that transfers packets is correctly set. do.
  • the communication system of the present invention transmits a packet by a user terminal via a first transfer device on the user terminal side and a second transfer device on the service provider side. It is a communication system that transfers to the service unit that provides the service, and when the start registration of the service is received from the user terminal, the reception unit instructs the setting unit to set the packet transfer according to the received service, and the reception unit gives an instruction.
  • the first transfer device sets a filter for packets by the user terminal according to the transfer setting, and the setting unit that sets the transfer of the packet by the user terminal to the confirmation unit in the second transfer device and the user terminal. It is characterized by having a confirmation unit for confirming a filter setting for a packet by a user terminal in the first transfer device based on a packet reception result.
  • the communication method of the present invention is a communication system that transfers a packet by a user terminal to a service unit that provides a service via a first transfer device on the user terminal side and a second transfer device on the service provider side. It is a communication method executed by a communication system having a reception unit, a setting unit, and a confirmation unit.
  • the reception unit accepts a service start registration from a user terminal
  • packet transfer setting according to the received service is performed.
  • the setting unit sets a filter for packets by the user terminal in the first transfer device according to the transfer setting according to the instruction in the step of instructing the setting unit and the setting unit, and sends the packet confirmation unit by the user terminal.
  • the communication program of the present invention receives the service start registration from the user terminal, the user according to the transfer setting according to the step of instructing the packet transfer setting according to the received service and the instruction in the instructing step.
  • the computer is made to execute the step of confirming the filter setting for the packet by the user terminal in the first transfer device.
  • the filter of the transfer device that transfers packets is set correctly.
  • FIG. 1 is a diagram illustrating a part of the configuration of the communication system according to the embodiment.
  • FIG. 2 is a diagram illustrating an example of a configuration of a communication system according to an embodiment.
  • FIG. 3 is a diagram illustrating a configuration of a transfer device.
  • FIG. 4 is a diagram illustrating a flow of a filter setting confirmation process in a communication system.
  • FIG. 5 is a sequence diagram showing a processing procedure of the confirmation processing of the filter setting according to the embodiment.
  • FIG. 6 is a diagram illustrating a flow of a filter setting confirmation process in the first modification of the embodiment.
  • FIG. 7 is a diagram illustrating a flow of a filter setting confirmation process in the second modification of the embodiment.
  • FIG. 1 is a diagram illustrating a part of the configuration of the communication system according to the embodiment.
  • FIG. 2 is a diagram illustrating an example of a configuration of a communication system according to an embodiment.
  • FIG. 3 is a diagram illustrating a configuration of a
  • FIG. 8 is a diagram showing an example of a computer that realizes a device provided with a service unit, a reception unit, a DB, a setting unit, and a confirmation unit of a communication system by executing a program.
  • FIG. 9 is a diagram showing a 5-tuple for distinguishing a specific user and a specific flow of service traffic.
  • FIG. 10 is a diagram showing 5-tuple when ICMP is used.
  • the communication system according to the present embodiment is a communication system that transfers a packet from a user terminal to a service unit that provides a service via a transfer device on the user terminal side and a transfer device on the service provider side.
  • FIG. 1 is a diagram illustrating a part of the configuration of the communication system according to the embodiment.
  • the normal packet P1 in addition to the normal packet P1 that reaches the website or the like via the core network N2, the normal packet P1 is different from the normal packet P1 according to the M / A set in the filter of the transfer device 20A. Packets P2 that match the filter and are transferred by different routes are transmitted from the user terminal 10. Specifically, the packet P2 transmitted from the user terminal 10 reaches the service unit 30 via the transfer device 20A, the Fabric N1 and the transfer device 20B.
  • FIG. 2 is a diagram illustrating an example of the configuration of the communication system according to the embodiment.
  • the communication system 1 further includes a reception unit 40 capable of communicating with the transfer device 20A via the core network N2, a setting unit 60 for connecting the reception unit 40 and the transfer devices 20A and 20B, and a transfer.
  • the device 20B and the confirmation unit 70 connected to the setting unit 60, the communicability of the route until the packet P2 transmitted from the user terminal 10 reaches the service unit 30 is confirmed.
  • the configuration of the communication system 1 according to the first embodiment will be specifically described with reference to FIGS. 1 and 2.
  • the premise of the network configuration of the communication system 1 will be described.
  • the user's home, the normal network, and the service network are considered.
  • the network and service network are under the control of the network operator.
  • an HTTP request from a user terminal 10 in the user's home reaches an arbitrary Web site via a transfer device 20A or a core network N2, and information on the corresponding Web page is displayed. It returns to the user terminal 10 as an HTTP response.
  • the transfer device 20A is an edge of the network, and is a router or the like that can realize transfer processing based on filter conditions in addition to normal routines.
  • the transfer device 20A is connected to the core network N2 and the service network.
  • the service network includes a service unit 30, a Fabric N1 that connects the transfer device 20A and the service unit 30.
  • the service unit 30 provides some service to the packet that has reached itself.
  • the service is, for example, a network service such as NAT (Network Address Translation) or shaping.
  • the transfer device 20B is a router or the like existing in Fabric N1.
  • the transfer device 20B is a transfer device of Fabric N1 that is directly connected to the service unit 30.
  • the transfer device 20A can transfer packets that match the set M / A toward the service unit 30 side.
  • M / A is a rule for executing a specified Action for a packet that matches the conditions, and as a specific example, there is a Road-map used in Policy Based Routing of Cisco ASR1009.
  • FIG. 3 is a diagram illustrating the configuration of the transfer device 20A.
  • the transfer device 20A includes a user-side IF21 accommodating a user, a service unit-side IF22, 24 (for service node bound and return) for transferring / connecting to the service unit 30, and a core network N2. It has a core side IF25 for transferring to.
  • each user may be separated by a VLAN. Further, the user-side IF21 applies M / A to this VLAN in order to service a specific packet of a specific user.
  • the matching condition is 5-tuple or the like described in ACL (Access Control List), and VRF (Virtual Routing and Forwarding) is specified in next-hop as Action.
  • VRF23 is applied to the service unit side IF22 which is the compute side IF.
  • the VRF 23 is set to forward a packet arriving based on the M / A of the user-side IF 21 toward the service unit 30 as a next-hop (see route R1 in FIG. 3).
  • the packet returned from the service unit 30 flows in from the service unit side IF 24 and is transferred to the core network N2 via the core side IF 25 according to the normal routine (see route R1 in FIG. 3).
  • the SV in FIG. 1 is a service node or a server.
  • the core side IF 25 transfers a normal packet that does not pass through the service unit 30 from the user side IF 21 to the core side IF 25 or from the core side IF to the user side IF according to the contents of the routing table of the transfer device 20A. .. Some packets flowing in from the core side IF 25 are transferred to the user side IF 21 after passing through the service unit 30 (see route R2 in FIG. 3). For such packets, M / A is also set on the core side IF25.
  • the packet transmitted from the user terminal 10 to the service unit 30 on the route of the route R1 is different from the normal IP routine, and the information that determines the next-hop is not only the destination IP address. Can not do it.
  • the reception unit 40 sets whether the packet to be serviced can reach the target service unit 30 by an appropriate route according to the setting. Confirmation is possible by providing the unit 60 and the confirmation unit 70. That is, in the first embodiment, the communication of the route until the packet P2 transmitted from the user terminal 10 reaches the service unit 30 and the filter setting for the packet by the user terminal 10 in the transfer device 20A are confirmed. For example, in the first embodiment, the correctness of the filter setting of the transfer device 20A can be confirmed from the standpoint of the network operator before the user side sends out the packet for the original service purpose.
  • reception unit 40 the database (Data Base: DB) 50 setting unit 60, and the confirmation unit 70 in the communication system 1 will be described.
  • database Data Base: DB
  • the reception unit 40 can communicate with the transfer device 20A via the core network N2.
  • the reception unit 40 is provided at a location that can be reached via the core network N2 (normal routine).
  • the reception unit 40 receives the service start registration from the user terminal 10
  • the reception unit 40 refers to the DB 50 and instructs the setting unit 60 to set the packet transfer according to the received service.
  • the reception unit 40 instructs the user terminal 10 to generate a test packet addressed to the service unit 30. Further, the reception unit 40 notifies the user terminal 10 of the opening of the service when the communication between the user terminal 10 and the service unit 30 can be confirmed.
  • DB50 5-tuple for identifying a new service is registered in advance.
  • DB 50 5-tuples of packets to be transmitted to each service are registered.
  • the data of the DB 50 is registered by, for example, a network operator or the like before the start of the service.
  • the setting unit 60 sets a filter for packets by the user terminal 10 in the transfer device 20A according to the transfer setting instructed by the reception unit 40. At the same time, the setting unit 60 sets the transfer of the packet by the user terminal 10 to the confirmation unit 70 (described later) in the transfer device 20B. The setting unit 60 sets the transfer device 20B so that the packet from the user terminal 10 is transferred to the confirmation unit 70 via the transfer devices 20A and 20B. The setting unit 60 is provided at a place where settings can be made to the transfer devices 20A and 20B.
  • the confirmation unit 70 confirms the filter setting for the packet by the user terminal 10 in the transfer device 20A based on the reception result of the packet by the user terminal 10.
  • the confirmation unit 70 is provided ahead of the transfer device 20A via the Fabric N1.
  • the confirmation unit 70 When the confirmation unit 70 receives the packet from the user terminal 10, the confirmation unit 70 confirms that the filter setting in the transfer device 20A is correct. This result is notified to the reception unit 40 via the setting unit 60, and when the reception unit 40 receives this notification, the reception unit 40 notifies the user terminal 10 of the opening of the service.
  • the confirmation unit 70 when the confirmation unit 70 receives a packet other than the packet by the user terminal 10, the confirmation unit 70 confirms that the filter setting in the transfer device 20A is incorrect. This result is notified to the setting unit 60 and the reception unit 40 as an error. Upon receiving this error, the setting unit 60 deletes the filter settings of the transfer devices 20A and 20B. Upon receiving this error, the reception unit 40 notifies the user terminal 10 that the reception of the service is an error. In response to this, the user terminal 10 can also request the start registration of a new service. Then, when the reception unit 40 receives this error, it may notify the higher-level management device or the like that there is a risk of abnormality in the transfer devices 20A and 20B.
  • FIG. 4 is a diagram illustrating a flow of a filter setting confirmation process in the communication system 1.
  • FIG. 5 is a sequence diagram showing a processing procedure of the confirmation processing of the filter setting according to the embodiment.
  • a service start registration request is transmitted from the user terminal 10 to the reception unit 40 via the transfer device 20A and the core network N2 ((1) and FIG. 5 in FIG. 4).
  • Step S1 The reception unit 40 refers to the DB 50 and instructs the setting unit 60 to set the transfer devices 20A and 20B for the service requested to be registered ((2) in FIG. 4 and step S2 in FIG. 5).
  • a 5-tuple for identifying a new service is registered in advance for the DB 50 as a preliminary preparation (see (A) in FIG. 4).
  • the setting unit 60 notifies the confirmation unit 60 of the traffic information transferred from the transfer device 20A by temporarily setting the test M / A rule to the transfer device 20B ((3) in FIG. 4 and Step S3-1) in FIG. Then, the setting unit 60 sets the M / A rule for this service in the transfer device 20A ((3) in FIG. 4 and step S3-2 in FIG. 5). Then, the setting unit 60 temporarily sets the test M / A rule on the transfer device 20B ((3) in FIG. 4 and step S3-3 in FIG. 5). As a result, the test packet transmitted from the user terminal 10 reaches the confirmation unit 70 via the transfer devices 20A and 20B.
  • the setting unit 60 When the setting unit 60 completes steps S3-1 to S3-3, the setting unit 60 notifies the reception unit 40 that the setting for the transfer devices 20A and 20B is completed ((4) in FIG. 4 and step S4 in FIG. 5). ..
  • the reception unit 40 simulates the downlink service traffic to the confirmation unit 70 ((5) in FIG. 4 and step S5 in FIG. 5). If the service traffic meets the conditions, the transfer devices 20A and 20B perform the filter transfer of the service traffic to the confirmation unit 70 ((6) in FIG. 4 and step S6-1 in FIG. 5). S6-2).
  • the reception unit 40 induces a test packet addressed to the service unit 30 as a service traffic on the user terminal 10 ((7) in FIG. 4 and step S7-1 in FIG. 5).
  • the user terminal 10 generates a service traffic (test packet) addressed to the service unit 30 according to the induction by the reception unit 40 (step S7-2 in FIG. 5), and sends out this test packet ((8) in FIG. 4).
  • the transfer devices 20A and 20B perform service traffic filter transfer ((9) in FIG. 4 and steps S9-1 and S9-2 in FIG. 5).
  • the test packet is transferred to the confirmation unit 70.
  • the confirmation unit 70 confirms the arrival of the test packet (step S10-1 in FIG. 5), it can confirm that the filter setting in the transfer device 20B is correct, and therefore notifies the setting unit 60 of the arrival of the test packet (FIG. 5). 4 (10) and step S10-2 in FIG.
  • the setting unit 60 deletes the temporary setting of the test M / A rule for the transfer device 20B ((11) in FIG. 4) and step S11 in FIG.
  • the reception unit 40 is notified of the completion of the temporary setting deletion indicating that the temporary setting of the test M / A rule for 20B has been deleted ((12) in FIG. 4 and step S12 in FIG. 5).
  • the reception unit 40 When the reception unit 40 receives the temporary setting deletion completion notification from the setting unit 60, it can confirm that the filter setting in the transfer device 20A is correct, so that the service setting is completed on the user terminal 10 and the service is opened. Notify ((13) of FIG. 4 and step S13 of FIG. 5). As a result, the service packet transmitted by the user terminal 10 is transferred to the service unit 30 when the conditions of the transfer device 20A are met (steps S14-1 to S14-3 in FIG. 5).
  • the reception unit 40 and the reception unit 40 instruct the setting unit 60 to set the packet transfer according to the received service.
  • the transfer device 20A sets a filter for the packet by the user terminal 10 according to the transfer setting, and the setting unit 60 that sets the transfer of the packet by the user terminal 10 to the confirmation unit in the transfer device 20B, and the user.
  • the transfer device 20A includes a confirmation unit 70 for confirming the filter setting for the packet by the user terminal 10.
  • the M / A is set in the transfer device 20A by confirming whether or not the test packet transmitted from the user device 10 reaches the confirmation unit 70 via the transfer devices 20A and 20B. In this case, it is possible to confirm whether the packet to be serviced can reach the target service unit 30 by an appropriate route before providing the service.
  • the transfer device 20A on the communication path You can check whether the transfer processing settings are set correctly. Then, in the first embodiment, the correctness of the filter setting of the transfer device 20A can be confirmed from the standpoint of the network operator before the user side sends out the packet for the original service purpose.
  • the filter of the transfer device 20A when the filter of the transfer device 20A is set, the test packet is once sent from the user terminal 10 and the reception result of the test packet is confirmed by the confirmation unit 70. You can confirm that the filter is set correctly. Therefore, according to the present embodiment, it can be easily confirmed that the filter of the transfer device 20A for transferring the packet is correctly set.
  • FIG. 6 is a diagram illustrating a flow of a filter setting confirmation process in the first modification of the embodiment.
  • the reception unit 40 transmits an HTTP redirect when inducing a service traffic ((1) in FIG. 6 ((6)). 7)).
  • the user terminal 10 sends out a test packet (see (8) in FIG. 6).
  • the processes of FIGS. 4 (9) to 4 (13) are executed.
  • the test packet can be sent to the confirmation unit 70 without adding the test packet generation function to the user terminal 10.
  • FIG. 7 is a diagram illustrating a flow of a filter setting confirmation process in the second modification of the embodiment.
  • the communication system 1 is provided in front of the transfer device 20A and the service unit 30 core network N2 by issuing a ping to the device provided in front of the core network N2, for example, before the confirmation process shown in FIG.
  • the communication with the device may be confirmed in advance.
  • a ping is issued from the VRF23 of the service unit side IF22 to the device in the core side IF25. Since ICMP is a standard protocol, it is not necessary to add a new function to the service unit 30.
  • the VRF23 of the service unit side IF22 of the transfer device 20A emits a ping toward the device in the core side IF25, so that the VRF23 set in the service unit side IF22 of the transfer device 20A can be used. It is possible to confirm the communication on the route to the device beyond the core side IF 25 via the service unit 30.
  • the communication system 1 transfers from the user terminal 10 to the service unit 30 via the M / A rule set in the user-side IF 21 of the transfer device 20A by performing the process shown in FIG. 4 or FIG. It is possible to confirm the communication of the route until it is completed.
  • each component of each of the illustrated devices is a functional concept and does not necessarily have to be physically configured as shown in the figure. That is, the specific form of distribution / integration of each device is not limited to the one shown in the figure, and all or part of the device is functionally or physically distributed in arbitrary units according to various loads and usage conditions. Can be integrated and configured. Further, each processing function performed by each device may be realized by a CPU and a program analyzed and executed by the CPU, or may be realized as hardware by wired logic.
  • FIG. 8 is a diagram showing an example of a computer that realizes a device provided with a service unit 30, a reception unit 40, a DB 50, a setting unit 60, and a confirmation unit 70 of the communication system 1 by executing a program.
  • the computer 1000 has, for example, a memory 1010 and a CPU 1020.
  • the computer 1000 also has a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. Each of these parts is connected by a bus 1080.
  • the memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012.
  • the ROM 1011 stores, for example, a boot program such as a BIOS (Basic Input Output System).
  • BIOS Basic Input Output System
  • the hard disk drive interface 1030 is connected to the hard disk drive 1090.
  • the disk drive interface 1040 is connected to the disk drive 1100.
  • a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1100.
  • the serial port interface 1050 is connected to, for example, a mouse 1110 and a keyboard 1120.
  • the video adapter 1060 is connected to, for example, the display 1130.
  • the hard disk drive 1090 stores, for example, an OS (Operating System) 1091, an application program 1092, a program module 1093, and program data 1094. That is, the program that defines each process in each part of the communication system 1 is implemented as a program module 1093 in which a code that can be executed by a computer is described.
  • the program module 1093 is stored in, for example, the hard disk drive 1090.
  • a program module 1093 for executing processing similar to the functional configuration in each part of the communication system 1 is stored in the hard disk drive 1090.
  • the hard disk drive 1090 may be replaced by an SSD (Solid State Drive).
  • the setting data used in the processing of the above-described embodiment is stored as program data 1094 in, for example, a memory 1010 or a hard disk drive 1090. Then, the CPU 1020 reads the program module 1093 and the program data 1094 stored in the memory 1010 and the hard disk drive 1090 into the RAM 1012 as needed, and executes the program.
  • the program module 1093 and the program data 1094 are not limited to those stored in the hard disk drive 1090, but may be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and the program data 1094 may be stored in another computer connected via a network (LAN, WAN (Wide Area Network), etc.). Then, the program module 1093 and the program data 1094 may be read by the CPU 1020 from another computer via the network interface 1070.
  • LAN Local Area Network
  • WAN Wide Area Network
  • Communication system 10 User terminal 20A, 20B Transfer device 30 Service department 40 Reception department 50 Database (DB) 60 Setting unit 70 Confirmation unit

Landscapes

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

Abstract

通信システム（１）は、ユーザ端末（１０）によるパケットを、ユーザ端末側の第１の転送装置及びサービス提供側の第２の転送装置を介して、サービスを提供するサービス部に転送する通信システムであって、ユーザ端末（１０）からサービスの開始登録を受け付けると、受け付けたサービスに応じたパケットの転送設定を設定部に指示する受付部（４０）と、受付部による指示に従って、転送設定に応じて転送装置（２０Ａ）にユーザ端末（１０）によるパケットに対するフィルタを設定するとともに、ユーザ端末（１０）によるパケットの確認部（７０）への転送を転送装置（２０Ｂ）に設定する設定部（６０）と、ユーザ端末（１０）によるパケットの受信結果を基に、転送装置（２０Ａ）におけるユーザ端末（１０）によるパケットに対するフィルタ設定を確認する確認部（７０）と、を有する。

Description

通信システム、通信方法及び通信プログラム
　本発明は、通信システム、通信方法及び通信プログラムに関する。
　ネットワーク機能を仮想化する方法として、ＮＦＶ（Network　Function　Virtualization）がある。ＮＦＶを活用すると、装置が同一箇所に集中的に置かれている必要はなく、分散配備が可能である。
　ネットワークエッジは、トンネル終端を始めとして、様々な機能を提供する。これらのネットワーク機能はそれぞれ、要求するシステムリソース（ＣＰＵ、メモリ容量等）の量が異なったり、時間とともに変動したりすることがある。このためＮＦＶを活用し、エッジ機能を分散配備型にすることで必要なリソースを必要なだけ準備できるようにしておきたい。このような配備をした場合、サービス対象のパケットを選別し、必要なエッジ機能を提供するサービス部へ転送する必要がある。
　また、特定のパケットをサービス部へ転送する処理は、マッチング条件をファイアウォールフィルタに記載し、該当するパケットを通常ルーチングとは異なる方向へ転送するようにＭ／Ａ（Match／Action）ルールを設定することで実現可能である。この設定は通常のルーチングより優先される。
　このように分散配置されたＶＮＦ（Virtual　Network　Function）を介して、パケットが目的の装置に正しく到達することを確認する手法が望まれている。従来手法としては、目的の装置へのパケットの到達や目的の装置までの疎通性を確認する手法として、利用前に実機を用いた動作検証をする手法、ｐｉｎｇやＴｒａｃｅｒｏｕｔｅ等のＩＰ疎通性の確認のために使用されるＩＣＭＰ（Internet　Control　Message　Protocol）を用いる手法、及び、転送装置の各インタフェースにＴＡＰを接続し、トラヒックを監視することでパケット転送の正確性を確認する手法がある（例えば、非特許文献１～３参照）。
小島　敏宏，"高品質システムを実現するネットワーク機器検証手法",　UNISYS　TECHNOLOGY　REVIEW　第　102　号，NOV.　2009.，　［online］，［令和２年２月６日検索］、インターネット＜ＵＲＬ：https://www.unisys.co.jp/tec_info/tr102/10209.pdf＞ RFC792，"INTERNET　CONTROL　MESSAGE　PROTOCOL",　［online］，［令和２年２月６日検索］、インターネット＜ＵＲＬ：https://tools.ietf.org/html/rfc792＞ macnica　networks，"ネットワークタップ(Network　TAP)とは",　［online］，［令和２年２月６日検索］、インターネット＜ＵＲＬ：https://www.macnica.net/gigamon/sol_ntap.html＞
　上記したように、特定パケットの転送では、転送装置のフィルタにマッチング条件を記載して通常ルーチングとは異なる方向へ転送処理を行なう。これらの特定パケットに対しては、一般的に用いられるＩＣＭＰではマッチング条件に一致させることができないため、ユーザ端末からサービス部までの、経路および経路上における転送処理の一致まで含めた疎通確認ができない（転送装置に正しくフィルタが設定されたか否かを確認できない）という問題があった。特に、商用開始後に特定パケットを転送するためのフィルタが転送装置に新たに設定されることがあり、転送装置におけるフィルタ処理を、ユーザ端末からフィルタ条件にマッチするパケットを送信する以外の手段で正しく動作しているかを確認すること、つまり、ネットワーク事業者の立場から確認することが難しい。
　図９は、サービストラヒックを特定ユーザ、特定フローを区別するための５－ｔｕｐｐｌｅを示す図である。図１０は、ＩＣＭＰを用いた場合の５－ｔｕｐｐｌｅを示す図である。図９に示すように、サービストラヒックを特定ユーザ、特定フローを区別するための５－ｔｕｐｐｌｅは、送信元ＩＰアドレスはユーザ端末固定であるが、その他の条件がサービス毎で異なるため、特定のサービス（特にポート番号）を識別するための条件になりうる。これに対し、図１０に示すように、ＩＣＭＰを用いた場合の５－ｔｕｐｐｌｅは、自由に指定できるものは宛先ＩＰアドレスのみであるため、サービス用パケットと同じ条件でフィルタ設定を確認することが難しい。
　このように、フィルタ条件が５－ｔｕｐｐｌｅで指定されている場合、ＩＣＭＰで確認できる部分はかなり限定される。ＩＣＭＰでは、ポート番号は確認できず、ＩＰヘッダのプロトコル番号も固定される。このため、実際のサービストラヒックのためのフィルタ条件に合致させるためには、普段から送信元ＩＰアドレスまたは宛先ＩＰアドレスで条件指定しておく必要がある。しかしながら、送信元ＩＰアドレスを条件としてサービス部へ転送すると、該当ユーザ全てのトラヒックがフィルタ対象になってしまい、特定トラヒックを選別していることにならない。
　そして、ユーザ側ＩＦ（Interface）から流入するパケットを例とすると、Ｍ／Ａルールは、転送装置Ａユーザ側ＩＦのＶＬＡＮに対して設定されているため、ＶＬＡＮタグが付いた状態でユーザ側ＩＦから、フィルタにかかるようなパケットを流入させない限り、このルールが適用されることはない。つまり、ユーザ端末と通常ネットワーク上の転送装置との間に試験用ツールが挟まっていない限り、ネットワーク事業者の立場でユーザ側ＩＦのＶＬＡＮに設定したＭ／Ａルールの設定が正しく機能しているか否かを確認する手段がない。
　試験用ツールを用いる場合、ユーザを模した試験用パケットとして、例えば送信元ＩＰアドレスをユーザ端末とし、宛先ＩＰアドレスをコアネットワーク側にある装置のＩＦとしたｐｉｎｇであり、ユーザ端末に該当するＶＬＡＮヘッダを付したパケットを生成する機能がさらに必要となる。このような場合、ｐｉｎｇの戻りはユーザに返るため、戻りのパケットを受け付ける機能も別途必要となり、システム構成が複雑になる。また、ユーザ数は膨大であるため、試験用ツールを挟み込む数も膨大になり、試験用設備の準備コストが高くなる。
　本発明は、上記に鑑みてなされたものであって、パケットを転送する転送装置のフィルタが正しく設定されていることを容易に確認できる通信システム、通信方法及び通信プログラムを提供することを目的とする。
　上述した課題を解決し、目的を達成するために、本発明の通信システムは、ユーザ端末によるパケットを、ユーザ端末側の第１の転送装置及びサービス提供側の第２の転送装置を介して、サービスを提供するサービス部に転送する通信システムであって、ユーザ端末からサービスの開始登録を受け付けると、受け付けたサービスに応じたパケットの転送設定を設定部に指示する受付部と、受付部による指示に従って、転送設定に応じて第１の転送装置にユーザ端末によるパケットに対するフィルタを設定するとともに、ユーザ端末によるパケットの確認部への転送を第２の転送装置に設定する設定部と、ユーザ端末によるパケットの受信結果を基に、第１の転送装置におけるユーザ端末によるパケットに対するフィルタ設定を確認する確認部と、を有することを特徴とする。
　また、本発明の通信方法は、ユーザ端末によるパケットを、ユーザ端末側の第１の転送装置及びサービス提供側の第２の転送装置を介して、サービスを提供するサービス部に転送する通信システムであって、受付部と設定部と確認部とを有する通信システムが実行する通信方法であって、受付部が、ユーザ端末からサービスの開始登録を受け付けると、受け付けたサービスに応じたパケットの転送設定を設定部に指示する工程と、設定部が、指示する工程における指示に従って、転送設定に応じて第１の転送装置にユーザ端末によるパケットに対するフィルタを設定するとともに、ユーザ端末によるパケットの確認部への転送を第２の転送装置に設定する工程と、確認部が、ユーザ端末によるパケットの受信結果を基に、第１の転送装置におけるユーザ端末によるパケットに対するフィルタ設定を確認する工程と、を含んだことを特徴とする。
　また、本発明の通信プログラムは、ユーザ端末からサービスの開始登録を受け付けると、受け付けたサービスに応じたパケットの転送設定を指示するステップと、指示するステップにおける指示に従って、転送設定に応じて、ユーザ端末側の第１の転送装置にユーザ端末によるパケットに対するフィルタを設定するとともに、ユーザ端末によるパケットの確認部への転送をサービス提供側の第２の転送装置に設定するステップと、確認部におけるユーザ端末によるパケットの受信結果を基に、第１の転送装置におけるユーザ端末によるパケットに対するフィルタ設定を確認するステップと、をコンピュータに実行させる。
　本発明によれば、パケットを転送する転送装置のフィルタが正しく設定されていることを容易に確認できる。
図１は、実施の形態に係る通信システムの構成の一部を説明する図である。 図２は、実施の形態に係る通信システムの構成の一例を説明する図である。 図３は、転送装置の構成を説明する図である。 図４は、通信システムにおけるフィルタ設定の確認処理の流れを説明する図である。 図５は、実施の形態に係るフィルタ設定の確認処理の処理手順を示すシーケンス図である。 図６は、実施の形態の変形例１におけるフィルタ設定の確認処理の流れについて説明する図である。 図７は、実施の形態の変形例２におけるフィルタ設定の確認処理の流れについて説明する図である。 図８は、プログラムが実行されることにより、通信システムのサービス部、受付部、ＤＢ、設定部及び確認部が設けられた装置を実現するコンピュータの一例を示す図である。 図９は、サービストラヒックを特定ユーザ、特定フローを区別するための５－ｔｕｐｐｌｅを示す図である。 図１０は、ＩＣＭＰを用いた場合の５－ｔｕｐｐｌｅを示す図である。
　以下、図面を参照して、本発明の一実施形態を詳細に説明する。なお、この実施形態により本発明が限定されるものではない。また、図面の記載において、同一部分には同一の符号を付して示している。
［実施の形態］
　本実施の形態に係る通信システムは、ユーザ端末によるパケットを、ユーザ端末側の転送装置及びサービス提供側の転送装置を介して、サービスを提供するサービス部に転送する通信システムである。図１は、実施の形態に係る通信システムの構成の一部を説明する図である。
　本実施の形態に係る通信システム１では、コア網Ｎ２を介してＷｅｂサイト等に到達する通常のパケットＰ１に加え、転送装置２０Ａのフィルタに設定されたＭ／Ａに従って、通常のパケットＰ１とは異なる経路で転送される、フィルタに合致したパケットＰ２がユーザ端末１０から送信される。具体的には、ユーザ端末１０から送信されたパケットＰ２は、転送装置２０Ａ、Ｆａｂｒｉｃ　Ｎ１及び転送装置２０Ｂを介して、サービス部３０に到達する。
　図２は、実施の形態に係る通信システムの構成の一例を説明する図である。図２に示すように、通信システム１は、さらに、コア網Ｎ２を介して転送装置２０Ａと通信が可能である受付部４０、受付部４０と転送装置２０Ａ，２０Ｂと接続する設定部６０、転送装置２０Ｂと設定部６０と接続する確認部７０とを有することで、ユーザ端末１０から送信されたパケットＰ２がサービス部３０に到達するまでの経路の疎通性を確認する。以降、図１及び図２を参照して、実施の形態１に係る通信システム１の構成を具体的に説明する。
　まず、通信システム１のネットワーク構成の前提について説明する。図１に示すように、通信システム１では、ユーザ宅内、通常ネットワーク及びサービスネットワークという領域を考える。通常ネットワーク及びサービスネットワークは、ネットワーク事業者の管理下である。
　例えば、ユーザからの通常のＷｅｂ閲覧等は、ユーザ宅内のユーザ端末１０からのＨＴＴＰリクエストが、転送装置２０Ａやコア網Ｎ２を経由し、任意のＷｅｂサイトに到達し、該当するＷｅｂページの情報がＨＴＴＰレスポンスとしてユーザ端末１０へ返る。
　転送装置２０Ａは、ネットワークのエッジであり、通常のルーチングの他に、フィルタ条件による転送処理を実現できるルータ等である。転送装置２０Ａは、コア網Ｎ２やサービスネットワークと接続している。
　サービスネットワークは、サービス部３０と、転送装置２０Ａとサービス部３０とを接続するＦａｂｒｉｃ　Ｎ１から成る。サービス部３０は、自身まで到達したパケットに対して何らかのサービスを実施する。サービスは、例えば、ＮＡＴ（Network　Address　Translation）やシェーピング等のネットワークサービスである。転送装置２０Ｂは、Ｆａｂｒｉｃ　Ｎ１内に存在するルータ等である。転送装置２０Ｂは、サービス部３０に直結するＦａｂｒｉｃ　Ｎ１の転送装置である。
　転送装置２０Ａは、設定されたＭ／Ａに合致したパケットについて、サービス部３０側へ向けて転送することができる。Ｍ／Ａは、条件に合致したパケットに対し、指定したＡｃｔｉｏｎを実施するルールであり、具体例として、Cisco　ASR1009のPolicy　Based　Routingで用いるＲｏｕｔｅ－ｍａｐがある。
　図３は、転送装置２０Ａの構成を説明する図である。図３に示すように、転送装置２０Ａは、ユーザを収容するユーザ側ＩＦ２１、サービス部３０への転送・接続するためのサービス部側ＩＦ２２，２４（サービスノード行き用、戻り用）、コア網Ｎ２へ転送するためのコア側ＩＦ２５を有する。
　ユーザ側ＩＦ２１は、物理ポート１本に複数のユーザを収容するため、ユーザ毎にＶＬＡＮで区切ることがある。また、ユーザ側ＩＦ２１は、特定のユーザの特定のパケットをサービス対象とするために、このＶＬＡＮに対してＭ／Ａを適用する。合致条件がＡＣＬ（Access　Control　List）に記載の５－ｔｕｐｐｌｅ等であり、Ａｃｔｉｏｎとしてはｎｅｘｔ－ｈｏｐにＶＲＦ（Virtual　Routing　and　Forwarding）を指定する。
　サービス部側ＩＦ２２，２４のうち、コンピュート側ＩＦであるサービス部側ＩＦ２２にＶＲＦ２３が適用される。このＶＲＦ２３は、ユーザ側ＩＦ２１のＭ／Ａに基づいて到達するパケットについては、ｎｅｘｔ－ｈｏｐとしてサービス部３０に向かって転送するように設定されている（図３のルートＲ１参照）。サービス部３０から戻ってきたパケットは、サービス部側ＩＦ２４から流入し、通常のルーチングに従って、コア側ＩＦ２５を介してコア網Ｎ２へ転送される（図３のルートＲ１参照）。なお、図１のＳＶは、サービスノードまたはサーバーである。
　コア側ＩＦ２５は、サービス部３０を経由しない通常のパケットについては、転送装置２０Ａのルーチングテーブルの内容に応じて、ユーザ側ＩＦ２１からコア側ＩＦ２５へ、またはコア側ＩＦからユーザ側ＩＦへ転送される。コア側ＩＦ２５から流入するパケットの中には、サービス部３０を経由してからユーザ側ＩＦ２１へ転送されるものもある（図３のルートＲ２参照）。そのようなパケットのために、コア側ＩＦ２５にもＭ／Ａが設定される。
　ルートＲ１の経路でユーザ端末１０からサービス部３０に送信されるパケットは、通常のＩＰルーチングと異なり、ｎｅｘｔ－ｈｏｐを決める情報が宛先ＩＰアドレスだけではないため、従来のｐｉｎｇで同じように疎通確認することができない。
　そこで、本実施の形態１では、転送装置２０ＡにおいてＭ／Ａを設定した際、その設定によりサービス対象としたいパケットが適切な経路で目的のサービス部３０まで到達できるかを、受付部４０、設定部６０及び確認部７０を設けることで、確認可能とする。すなわち、本実施の形態１では、ユーザ端末１０から送信されたパケットＰ２がサービス部３０に到達するまでの経路の疎通性と、転送装置２０Ａにおけるユーザ端末１０によるパケットに対するフィルタ設定を確認する。例えば、本実施の形態１では、ユーザ側が本来のサービス目的のパケットを送出する前の段階で、ネットワーク事業者側の立場で転送装置２０Ａのフィルタ設定の正しさを確認できるようにした。
　次に、通信システム１における受付部４０、データベース（Data　Base：ＤＢ）５０設定部６０及び確認部７０について説明する。
　受付部４０は、コア網Ｎ２を介して転送装置２０Ａと通信が可能である。受付部４０は、コア網Ｎ２経由（通常のルーチング）で到達できる場所に設けられる。受付部４０は、ユーザ端末１０からサービスの開始登録を受け付けると、ＤＢ５０を参照して、受け付けたサービスに応じたパケットの転送設定を設定部６０に指示する。受付部４０は、ユーザ端末１０にサービス部３０宛の試験パケットの生成を指示する。また、受付部４０は、ユーザ端末１０とサービス部３０との間の疎通性が確認できた場合に、ユーザ端末１０にサービス開通を通知する。
　ＤＢ５０は、予め、新サービスを識別するための５－ｔｕｐｐｌｅが登録されている。ＤＢ５０は、各サービスに対して送信される、パケットの５－ｔｕｐｐｌｅがそれぞれ登録されている。ＤＢ５０のデータは、例えば、サービス開始前にネットワーク事業者等によって登録される。
　設定部６０は、受付部４０による指示された転送設定に応じて、転送装置２０Ａにユーザ端末１０によるパケットに対するフィルタを設定する。これとともに、設定部６０は、ユーザ端末１０によるパケットの確認部７０（後述）への転送を、転送装置２０Ｂに設定する。設定部６０は、ユーザ端末１０によるパケットを、転送装置２０Ａ，２０Ｂを介して、確認部７０へ転送されるように、転送装置２０Ｂに設定を行う。設定部６０は、転送装置２０Ａ，２０Ｂへの設定が行える場所に設けられる。
　確認部７０は、ユーザ端末１０によるパケットの受信結果を基に、転送装置２０Ａにおけるユーザ端末１０によるパケットに対するフィルタ設定を確認する。確認部７０は、転送装置２０Ａから見て、Ｆａｂｒｉｃ　Ｎ１を経由した先に設けられる。
　確認部７０は、ユーザ端末１０によるパケットを受信した場合、転送装置２０Ａにおけるフィルタ設定が正しいことを確認する。この結果は、設定部６０を介して受付部４０に通知され、受付部４０は、この通知を受けると、ユーザ端末１０にサービス開通を通知する。
　また、確認部７０は、ユーザ端末１０によるパケット以外のパケットを受信した場合、転送装置２０Ａにおけるフィルタ設定が誤っていることを確認する。この結果は、設定部６０及び受付部４０にエラーとして通知される。設定部６０は、このエラーを受けると、転送装置２０Ａ，２０Ｂのフィルタ設定を削除する。受付部４０は、このエラーを受けると、ユーザ端末１０にサービスの受付がエラーであることを通知する。これに応じて、ユーザ端末１０は、新規サービスの開始登録を要求することもできる。そして、受付部４０は、このエラーを受けると、上位の管理装置等に、転送装置２０Ａ，２０Ｂに異常のおそれがあることを通知してもよい。
［処理の流れ］
　次に、図４及び図５を参照して、通信システム１におけるフィルタ設定の確認処理の流れについて説明する。図４は、通信システム１におけるフィルタ設定の確認処理の流れを説明する図である。図５は、実施の形態に係るフィルタ設定の確認処理の処理手順を示すシーケンス図である。
　図４及び図５に示すように、ユーザ端末１０から、サービス開始の登録要求が、転送装置２０Ａ及びコア網Ｎ２を介して、受付部４０に送信される（図４の（１）及び図５のステップＳ１）。受付部４０は、ＤＢ５０を参照して、登録を要求されたサービスに対する転送装置２０Ａ，２０Ｂへの設定を、設定部６０に指示する（図４の（２）及び図５のステップＳ２）。なお、ＤＢ５０に対しては、事前準備として新サービスを識別するための５－ｔｕｐｐｌｅが予め登録されている（図４の（Ａ）参照）。
　これに応じて、設定部６０は、転送装置２０Ｂへの試験用Ｍ／Ａルールの仮設定によって転送装置２０Ａから転送されてくるトラヒック情報を確認部６０に通知する（図４の（３）及び図５のステップＳ３－１）。そして、設定部６０は、転送装置２０Ａへの本サービス用Ｍ／Ａルールの設定を行う（図４の（３）及び図５のステップＳ３－２）。そして、設定部６０は、転送装置２０Ｂへの試験用Ｍ／Ａルールの仮設定を行う（図４の（３）及び図５のステップＳ３－３）。これによって、ユーザ端末１０から送信された試験用パケットは、転送装置２０Ａ，２０Ｂを介して、確認部７０に到達する。
　設定部６０は、ステップＳ３－１～Ｓ３－３を終了すると、転送装置２０Ａ，２０Ｂへの設定が完了したことを受付部４０に通知する（図４の（４）及び図５のステップＳ４）。受付部４０は、下りのサービストラヒックを模擬的に確認部７０に送信する（図４の（５）及び図５のステップＳ５）。転送装置２０Ａ，２０Ｂは、このサービストラヒックが、条件に合致している場合には、サービストラヒックのフィルタ転送を確認部７０宛に行う（図４の（６）及び図５のステップＳ６－１，Ｓ６－２）。
　続いて、受付部４０は、ユーザ端末１０に、サービストラヒックとしてサービス部３０宛の試験パケットを誘起する（図４の（７）及び図５のステップＳ７－１）。ユーザ端末１０は、受付部４０による誘起にしたがって、サービス部３０宛のサービストラヒック（試験パケット）を生成し（図５のステップＳ７－２）、この試験パケットを送出する（図４の（８）及び図５のステップＳ８）。
　転送装置２０Ａ，２０Ｂは、この試験パケットが条件に合致している場合には、サービストラヒックのフィルタ転送を行って（図４の（９）及び図５のステップＳ９－１，Ｓ９－２）、試験パケットを確認部７０に転送する。
　確認部７０は、試験パケットの到達を確認すると（図５のステップＳ１０－１）、転送装置２０Ｂにおけるフィルタ設定が正しいことを確認できるため、設定部６０に、試験パケットの到着を通知する（図４の（１０）及び図５のステップＳ１０－２）。設定部６０は、この通知を受けると、転送装置２０Ｂに対する試験用Ｍ／Ａルールの仮設定を削除し（図４の（１１））及び図５のステップＳ１１）、削除が完了すると、転送装置２０Ｂに対する試験用Ｍ／Ａルールの仮設定の削除が完了したことを示す仮設定削除完了通知を受付部４０に通知する（図４の（１２）及び図５のステップＳ１２）。
　受付部４０は、設定部６０からの仮設定削除完了通知を受けると、転送装置２０Ａにおけるフィルタ設定が正しいことが確認できたため、ユーザ端末１０にサービスの設定が完了し、サービスが開通したことを通知する（図４の（１３）及び図５のステップＳ１３）。これによって、ユーザ端末１０が送信したサービス用パケットは、転送装置２０Ａの条件に合致している場合、サービス部３０まで転送されることとなる（図５のステップＳ１４－１～Ｓ１４－３）。
［実施の形態の効果］
　このように、実施の形態に係る通信システム１は、ユーザ端末１０からサービスの開始登録を受け付けると、受け付けたサービスに応じたパケットの転送設定を設定部６０に指示する受付部４０と、受付部４０による指示に従って、転送設定に応じて転送装置２０Ａにユーザ端末１０によるパケットに対するフィルタを設定するとともに、ユーザ端末１０によるパケットの確認部への転送を転送装置２０Ｂに設定する設定部６０と、ユーザ端末１０によるパケットの受信結果を基に、転送装置２０Ａにおけるユーザ端末１０によるパケットに対するフィルタ設定を確認する確認部７０と、を有する。
　通信システム１では、ユーザ装置１０から送出された試験パケットを、転送装置２０Ａ，２０Ｂを経由して確認部７０に到達するか否かを確認することで、転送装置２０ＡにおいてＭ／Ａを設定した場合に、サービス対象としたいパケットが適切な経路で目的のサービス部３０まで到達できるかを、サービス提供前に確認可能とする。
　すなわち、本実施の形態では、ユーザ端末１０から送信されたパケットがサービス部３０に到達するまでの経路の疎通性が正しいか否かと、転送装置２０Ａにおけるユーザ端末１０によるパケットに対するフィルタ設定が正しい設定であるか否かと、を確認することができる。言い換えると、本実施の形態では、ユーザ端末１０から、ユーザ側ＩＦ２１に設定されたＭ／Ａルールを経由してサービス部３０側へ転送されるまでの経路の疎通性を確認することができる。
　本実施の形態では、試験パケットの疎通確認結果と、本来のサービスパケットの疎通性とが一致するか否かによって、通信経路が故障していないことだけでなく、通信経路上の転送装置２０Ａの転送処理設定が正しく設定されているかまで含めて、確認することができる。そして、本実施の形態１では、ユーザ側が本来のサービス目的のパケットを送出する前の段階で、ネットワーク事業者側の立場で転送装置２０Ａのフィルタ設定の正しさを確認することができる。
　上記のように、本実施の形態では、転送装置２０Ａのフィルタ設定時に、ユーザ端末１０から試験パケットを一度送出させて、確認部７０における試験パケットの受信結果を確認するだけで、転送装置２０Ａのフィルタが正しく設定されていることを確認できる。したがって、本実施の形態によれば、パケットを転送する転送装置２０Ａのフィルタが正しく設定されていることを容易に確認できる。
［実施の形態の変形例１］
　次に、実施の形態の変形例１について説明する。図６は、実施の形態の変形例１におけるフィルタ設定の確認処理の流れについて説明する図である。
　本変形例１では、サービス対象のパケットがＨＴＴＰに限定されることが予め分かっている場合について説明する。具体的には、図４の（１）～図４の（６）と同じ処理が行われた後、受付部４０は、サービストラヒックを誘起させる際に、ＨＴＴＰリダイレクトを送信する（図６の（７）参照）。これに応じたＨＴＴＰリクエストで、ユーザ端末１０は、試験用パケットを送出する（図６の（８）参照）。以降、通信システム１では、図４の（９）～図４の（１３）の処理が実行される。
　このように、誘起方法がＨＴＴＰリダイレクトである場合は、ユーザ端末１０に試験用パケットの生成機能を付加せずとも、確認部７０への試験用パケットを送出させることができる。
［実施の形態の変形例２］
　次に、実施の形態の変形例２について説明する。図７は、実施の形態の変形例２におけるフィルタ設定の確認処理の流れについて説明する図である。
　例えば、通信システム１は、例えば図４に示す確認処理の前に、コア網Ｎ２の先に設けられた装置にｐｉｎｇを発することによって、転送装置２０Ａとサービス部３０コア網Ｎ２の先に設けられた装置との間の疎通性を予め確認してもよい。具体的には、図７の（１）に示すように、サービス部側ＩＦ２２のＶＲＦ２３から、コア側ＩＦ２５にある装置に向かってpingを発する。なお、ＩＣＭＰは、標準的なプロトコルのため、サービス部３０に新たに機能を追加する必要はない。
　また、ＩＣＭＰのｅｃｈｏ　Ｒｅｐｌｙを、サービス部３０を経由させるために、コア側ＩＦ２５にＭ／Ａルールを設定する必要がある（図７の（２）参照）。ここで、確認を必要とするのは、往路方向の経路上の疎通性なので、復路でＭ／Ａによりサービス部３０を経由させることに問題はない。
　このように、通信システム１では、転送装置２０Ａのサービス部側ＩＦ２２のＶＲＦ２３から、コア側ＩＦ２５にある装置に向かってｐｉｎｇを発することによって、転送装置２０Ａのサービス部側ＩＦ２２に設定したＶＲＦ２３から、サービス部３０を経由してコア側ＩＦ２５の先にある装置までの経路上の疎通性を確認することができる。
　さらに、通信システム１は、図４または図６に示す処理を行うことで、ユーザ端末１０から、転送装置２０Ａのユーザ側ＩＦ２１に設定されたＭ／Ａルールを経由して、サービス部３０へ転送されるまでの経路の疎通性を確認することができる。
［システム構成等］
　図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部又は任意の一部が、ＣＰＵ及び当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
　また、本実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的におこなうこともでき、あるいは、手動的に行なわれるものとして説明した処理の全部又は一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
［プログラム］
　図８は、プログラムが実行されることにより、通信システム１のサービス部３０、受付部４０、ＤＢ５０、設定部６０及び確認部７０が設けられた装置を実現するコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。
　メモリ１０１０は、ＲＯＭ（Read　Only　Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic　Input　Output　System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１１３０に接続される。
　ハードディスクドライブ１０９０は、例えば、ＯＳ（Operating　System）１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、通信システム１の各部における各処理を規定するプログラムは、コンピュータにより実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、通信システム１の各部における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤ（Solid　State　Drive）により代替されてもよい。
　また、上述した実施形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して実行する。
　なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３及びプログラムデータ１０９４は、ネットワーク（ＬＡＮ、ＷＡＮ（Wide　Area　Network）等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３及びプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
　以上、本発明者によってなされた発明を適用した実施形態について説明したが、本実施形態による本発明の開示の一部をなす記述及び図面により本発明は限定されることはない。すなわち、本実施形態に基づいて当業者等によりなされる他の実施形態、実施例及び運用技術等は全て本発明の範疇に含まれる。
　１　通信システム
　１０　ユーザ端末
　２０Ａ，２０Ｂ　転送装置
　３０　サービス部
　４０　受付部
　５０　データベース（ＤＢ）
　６０　設定部
　７０　確認部

Claims (7)

  1. 　ユーザ端末によるパケットを、前記ユーザ端末側の第１の転送装置及びサービス提供側の第２の転送装置を介して、サービスを提供するサービス部に転送する通信システムであって、
    　前記ユーザ端末から前記サービスの開始登録を受け付けると、受け付けたサービスに応じたパケットの転送設定を設定部に指示する受付部と、
    　前記受付部による指示に従って、前記転送設定に応じて前記第１の転送装置に前記ユーザ端末によるパケットに対するフィルタを設定するとともに、前記ユーザ端末によるパケットの確認部への転送を前記第２の転送装置に設定する前記設定部と、
    　前記ユーザ端末によるパケットの受信結果を基に、前記第１の転送装置における前記ユーザ端末によるパケットに対するフィルタ設定を確認する確認部と、
    　を有することを特徴とする通信システム。
  2. 　前記確認部は、前記ユーザ端末によるパケットを受信した場合、前記第１の転送装置におけるフィルタ設定が正しいことを確認し、前記ユーザ端末によるパケット以外のパケットを受信した場合、前記第１の転送装置におけるフィルタ設定が誤っていることを確認することを特徴とする請求項１に記載の通信システム。
  3. 　前記受付部は、前記ユーザ端末に前記サービス部宛の試験パケットの生成を指示し、
    　前記ユーザ端末は、前記受付部による指示にしたがって、前記試験パケットを生成して送信し、
    　前記確認部は、前記試験パケットの受信結果を基に、前記第１の転送装置における前記ユーザ端末によるパケットに対するフィルタ設定を確認する
    　ことを特徴とする請求項１または２に記載の通信システム。
  4. 　前記受付部は、ＨＴＴＰリダイレクトを用いて前記サービス部宛のパケットの送信を誘起する
    　ことを特徴とする請求項１または２に記載の通信システム。
  5. 　前記第１の転送装置は、ｐｉｎｇを用いて、前記第１の転送装置と前記サービス部との間の疎通性を確認することを特徴とする請求項１～４のいずれか一つに記載の通信システム。
  6. 　ユーザ端末によるパケットを、前記ユーザ端末側の第１の転送装置及びサービス提供側の第２の転送装置を介して、サービスを提供するサービス部に転送する通信システムであって、受付部と設定部と確認部とを有する通信システムが実行する通信方法であって、
    　前記受付部が、前記ユーザ端末から前記サービスの開始登録を受け付けると、受け付けたサービスに応じたパケットの転送設定を前記設定部に指示する工程と、
    　前記設定部が、前記指示する工程における指示に従って、前記転送設定に応じて前記第１の転送装置に前記ユーザ端末によるパケットに対するフィルタを設定するとともに、前記ユーザ端末によるパケットの前記確認部への転送を前記第２の転送装置に設定する工程と、
    　前記確認部が、前記ユーザ端末によるパケットの受信結果を基に、前記第１の転送装置における前記ユーザ端末によるパケットに対するフィルタ設定を確認する工程と、
    　を含んだことを特徴とする通信方法。
  7. 　ユーザ端末からサービスの開始登録を受け付けると、受け付けたサービスに応じたパケットの転送設定を指示するステップと、
    　前記指示するステップにおける指示に従って、前記転送設定に応じて、ユーザ端末側の第１の転送装置に前記ユーザ端末によるパケットに対するフィルタを設定するとともに、前記ユーザ端末によるパケットの確認部への転送をサービス提供側の第２の転送装置に設定するステップと、
    　前記確認部における前記ユーザ端末によるパケットの受信結果を基に、前記第１の転送装置における前記ユーザ端末によるパケットに対するフィルタ設定を確認するステップと、
    　をコンピュータに実行させるための通信プログラム。
PCT/JP2020/005606 2020-02-13 2020-02-13 通信システム、通信方法及び通信プログラム WO2021161463A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/005606 WO2021161463A1 (ja) 2020-02-13 2020-02-13 通信システム、通信方法及び通信プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/005606 WO2021161463A1 (ja) 2020-02-13 2020-02-13 通信システム、通信方法及び通信プログラム

Publications (1)

Publication Number Publication Date
WO2021161463A1 true WO2021161463A1 (ja) 2021-08-19

Family

ID=77292216

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/005606 WO2021161463A1 (ja) 2020-02-13 2020-02-13 通信システム、通信方法及び通信プログラム

Country Status (1)

Country Link
WO (1) WO2021161463A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006101170A (ja) * 2004-09-29 2006-04-13 Ntt Communications Kk 折り返し試験システム、宅内装置、及びセンター装置、並びにプログラム
JP2014236388A (ja) * 2013-06-03 2014-12-15 エヌ・ティ・ティ・コミュニケーションズ株式会社 パケット転送装置、検査制御装置、検査方法、検査制御方法、及びプログラム
JP2015154421A (ja) * 2014-02-18 2015-08-24 日本電信電話株式会社 通信ネットワークの経路制御連携システム及び方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006101170A (ja) * 2004-09-29 2006-04-13 Ntt Communications Kk 折り返し試験システム、宅内装置、及びセンター装置、並びにプログラム
JP2014236388A (ja) * 2013-06-03 2014-12-15 エヌ・ティ・ティ・コミュニケーションズ株式会社 パケット転送装置、検査制御装置、検査方法、検査制御方法、及びプログラム
JP2015154421A (ja) * 2014-02-18 2015-08-24 日本電信電話株式会社 通信ネットワークの経路制御連携システム及び方法

Similar Documents

Publication Publication Date Title
AbdelSalam et al. Implementation of virtual network function chaining through segment routing in a linux-based NFV infrastructure
CN108551464B (zh) 一种混合云的连接建立、数据传输方法、装置和系统
US11856018B2 (en) Managing traffic control in a network mitigating DDOS
JP5111256B2 (ja) 通信システムおよびサーバ装置
US20120257529A1 (en) Computer system and method of monitoring computer system
JP5679343B2 (ja) クラウドシステム、ゲートウェイ装置、通信制御方法、及び通信制御プログラム
US8359377B2 (en) Interface for automated deployment and management of network devices
CN112202930B (zh) 一种移动设备接入sd-wan网络方法、pop和系统
US20130212241A1 (en) System and method for operating network based on network virtualization
Rodriguez-Natal et al. Programmable overlays via openoverlayrouter
EP3552370B1 (en) Implementing service function chains
US7747849B2 (en) Secure communications equipment for processing data packets according to the send mechanism
CN118118422A (zh) 流量转发的方法、装置及电子设备
WO2021161463A1 (ja) 通信システム、通信方法及び通信プログラム
CN102780584B (zh) 一种快速访问以太网设备网管系统的方法及装置
WO2011147334A1 (zh) 提供虚拟私有网业务的方法、设备和系统
Jain et al. Performance Comparison Between Different Tunneling Techniques Using Different Routing Protocols
Marchal et al. Leveraging NFV for the deployment of NDN: Application to HTTP traffic transport
US20230216733A1 (en) Distributed node discovery and overlay path management on a data communication network
US11057304B1 (en) DNS (domain name server)-based application-aware routing on SD-WAN (software-defined wide access network)
EP3185510B1 (en) Method for data packet inspection, related device and computer-program product
Lehocine et al. VINEMA: Towards automated management of virtual networks in SDN infrastructures
Zaalouk et al. Network configuration in OpenFlow networks
Fowler Cloud network engineering
CN117201135B (zh) 业务随行方法、装置、计算机设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20918900

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20918900

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP