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

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

Info

Publication number
WO2022176168A1
WO2022176168A1 PCT/JP2021/006444 JP2021006444W WO2022176168A1 WO 2022176168 A1 WO2022176168 A1 WO 2022176168A1 JP 2021006444 W JP2021006444 W JP 2021006444W WO 2022176168 A1 WO2022176168 A1 WO 2022176168A1
Authority
WO
WIPO (PCT)
Prior art keywords
cpe
address
packet
eid
area
Prior art date
Application number
PCT/JP2021/006444
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/006444 priority Critical patent/WO2022176168A1/ja
Priority to JP2023500468A priority patent/JPWO2022176168A1/ja
Publication of WO2022176168A1 publication Critical patent/WO2022176168A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0019—Control or signalling for completing the hand-off for data sessions of end-to-end connection adapted for mobile IP [MIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/34—Modification of an existing route
    • H04W40/36—Modification of an existing route due to handover
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/087—Mobility data transfer for preserving data network PoA address despite hand-offs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/695—Types of network addresses using masks or ranges of addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H04L61/103—Mapping addresses of different types across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5084—Providing for device mobility
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Definitions

  • the present invention relates to a communication device, communication method and program.
  • IP mobility functions are necessary to connect physically moving devices to the network and continue to provide connectivity, such as connected cars. IP mobility is a function that allows communication to continue without affecting the device's application even if the device's IP address changes.
  • Non-Patent Document 1 A representative example of technology that realizes IP mobility is LISP (Locator/ID Separation Protocol) (Non-Patent Document 1).
  • LISP an IP address used by an application for communication is defined as an EID (End Point ID), and an IP address used when a device communicates with an external network is defined as an RLOC (Routing Locator).
  • EID End Point ID
  • RLOC Ring Locator
  • the RLOC is changed when the network to which the device is connected is changed or when the IP address is reassigned due to movement.
  • RLOC is an IP address assigned when a device connects to a cellular network, Wi-Fi (registered trademark), or the like.
  • EID always has the same value.
  • an external database holds the EID-RLOC correspondence and always keeps the correspondence up-to-date.
  • the device uses the EID of the communication destination application as a key to inquire about the RLOC, encapsulates the IP packet with the destination RLOC, and transmits the IP packet to the network, thereby realizing IP mobility.
  • Locator/ID Separation Protocol (LISP)
  • IETF RFC6830 [online]
  • LISP can realize IP mobility between all terminals participating in LISP, but it is a general IoT (Internet of Things) use case that collects data from devices such as connected cars and sensors to the cloud.
  • IoT Internet of Things
  • scalability becomes an issue as the number of devices increases. For example, connected cars have millions to tens of millions of devices.
  • the size of the routing table (number of routes) of the device on the cloud side that the device communicates with is a problem.
  • a device's routing table holds information for encapsulation with the corresponding RLOC, using the EID as the communication destination of the device as a key.
  • the amount of routing tables increases according to the number of EIDs. For example, assuming an application that periodically collects sensor information from a moving IoT device, the communication destination of the IoT device is only the cloud-side application, but the cloud-side device (terminal device equivalent to the device) We need to communicate with a large number of IoT devices. For applications that intermittently transmit small amounts of data such as sensor information, the amount of routing tables (number of routes) in the cloud-side device may become a bottleneck before the network bandwidth.
  • the present invention has been made in view of the above points, and an object of the present invention is to improve the efficiency of communication related to communication devices whose IP addresses change.
  • a communication device that moves between a plurality of areas and communicates with a predetermined information processing device includes a plurality of accommodation devices each corresponding to one of the plurality of areas.
  • a registration unit for registering in the accommodation device information for encapsulating and transmitting a packet destined for the second IP address from the predetermined information processing device with the first IP address; and a packet processing unit that decapsulates a packet encapsulated by an IP address into a packet destined for the second IP address.
  • FIG. 2 is a diagram showing a hardware configuration example of device 10 according to an embodiment of the present invention
  • FIG. It is a figure which shows the functional structural example of CPE50.
  • FIG. It is a figure which shows the functional structural example of an area representative router (AR40).
  • AR40 area representative router
  • FIG. 3 is a diagram showing an example of a functional configuration of a controller 30;
  • FIG. 3 is a diagram showing a configuration example of an EID-RLOC database 33;
  • FIG. 4 is a sequence diagram for explaining the connection of the CPE 50 on the device 10 side to the AR 40 and the registration of the CPE 50 on the cloud side to the controller 30, which are executed prior to communication.
  • FIG. 11 is a sequence diagram for explaining an example of a processing procedure when a packet is transmitted from a host 60-11 under CPE 50-11 to a host 60-3 under CPE 50-31;
  • FIG. 4 is a sequence diagram for explaining the flow of communication from a host 60-3 to a host 60-11;
  • FIG. 10 is a flow chart for explaining an example of a processing procedure executed when the area to which CPE 50-11 belongs is changed;
  • FIG. 10 is a flow chart for explaining an example of a processing procedure executed when the area to which CPE 50-11 belongs is changed;
  • FIG. 10 is a diagram showing an example of changes in each routing table when the area to which CPE 50-11 belongs is changed;
  • an area representative router (AR 40) that accommodates the device 10 that moves between a plurality of areas is installed in each area, and (2) the cloud side terminal device and the area representative router are paired.
  • the problem is solved by adopting the configuration of matching with 1.
  • an area representative router is installed in each physical area (for example, on a prefecture-by-prefecture basis), and the moving device 10 connects to the nearest area representative router prior to communication.
  • the area representative router holds the EID-RLOC correspondence of the devices 10 connected under itself as a routing table.
  • EID End Point ID
  • LISP Licator/ID Separation Protocol
  • RLOC Ring Locator
  • the end device on the cloud side is implemented in the form of a VM (Virtual Machine) or a container by virtualization technology, and multiple units can be launched within the range of computing resources. Therefore, one terminating device can be installed for one area representative router, and from the perspective of the terminating device, the communication partner is limited to the corresponding area representative router. That is, only the information of one corresponding area representative router is registered in the routing table of the terminal device on the cloud side. Therefore, since the end device on the cloud side does not need to maintain the EID-RLOC correspondence relationship, there is no need to query the database, and a reduction in database query processing volume can be expected.
  • VM Virtual Machine
  • an IP address held by a communication destination terminal or application is set as an EID (Endpoint ID), and a CPE (Customer ID) that connects (accommodates) each device 10 or cloud base (data center 20) to the core network N1.
  • EID Endpoint ID
  • CPE Customer ID
  • SRv6 Segment Routing for IPv6
  • the core network N1 only needs to support IPv6.
  • the protocol for encapsulation between CPEs is not limited to SRv6, and may be substituted by other means capable of encapsulating IP packets.
  • FIG. 1 is a diagram showing a configuration example of a communication system according to an embodiment of the present invention.
  • a plurality of devices 10 devices 10-11, device 10-12, device 10-21
  • data center 20 have CPE 50 and host 60 as terminal devices, and connect to core network N1 via CPE 50.
  • the CPE 50 and the host 60 are connected by a LAN inside the device 10 or inside the data center 20 .
  • the CPE 50 of each device 10 belongs to an area and is connected via an SRv6 tunnel to the AR 40, which is the area representative router that controls that area.
  • the controller 30 is arranged at a location accessible from the CPE 50 via the core network N1.
  • character strings indicating the IP address of each device and host 60 are shown in parentheses.
  • a character string beginning with "IP” is the IP address (RLOC) of the CPE 50 or AR 40, which is reachable via the core network N1. Communications via the core network N1 are encapsulated with this IP address.
  • a character string beginning with "EID” is an IP address assigned to the host 60 or application existing within the LAN under the control of the CPE 50. FIG. The EID is permanently assigned and does not change even if the device 10 moves or the connected network changes (that is, does not depend on the location of the device 10). Applications can always continue to communicate with this EID.
  • FIG. 2 is a diagram showing a hardware configuration example of the device 10 according to the embodiment of the present invention.
  • the device 10 shown in FIG. 2 has a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, etc., which are connected to each other via a bus B, respectively.
  • a program that implements processing in the device 10 is provided by a recording medium 101 such as a CD-ROM.
  • a recording medium 101 such as a CD-ROM.
  • the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100 .
  • the program does not necessarily need to be installed from the recording medium 101, and may be downloaded from another computer via the network.
  • the auxiliary storage device 102 stores installed programs, as well as necessary files and data.
  • the memory device 103 reads and stores the program from the auxiliary storage device 102 when a program activation instruction is received.
  • the CPU 104 executes functions related to the device 10 according to programs stored in the memory device 103 .
  • the interface device 105 is used as an interface for connecting to a network.
  • the data center 20, controller 30, AR 40, etc. may also have the same hardware configuration as in FIG.
  • FIG. 3 is a diagram showing a functional configuration example of the CPE 50.
  • the CPEs 50 have the same configuration on the device 10 side (CPEs 50-11, 12, 21) and on the data center 20 side (CPEs 50-31, 32).
  • CPE 50 has forwarding section 51 , RLOC resolution section 52 and CPE registration section 53 .
  • Each of these units is realized by processing that one or more programs installed in the device 10 or the data center 20 cause the CPU of the device 10 or the data center 20 to execute.
  • CPE 50 also utilizes routing table 54 .
  • the routing table 54 can be implemented using, for example, a memory device or auxiliary storage device of the device 10 or data center 20 .
  • the forwarding unit 51 encapsulates a packet from the host 60 under its own CPE 50 to the data center 20 and sends it to the core network N1, and forwards the encapsulated packet from the data center 20 or the like to the host 60 under its own CPE 50 to the core. When received from the network N1, it decapsulates the packet and delivers the decapsulated packet to the host 60.
  • the routing table 54 is a storage unit that holds a routing table required when the forwarding unit 51 executes packet transfer, packet encapsulation, and packet decapsulation. A specific example of the routing table 54 will be described later.
  • the RLOC resolution unit 52 resolves the RLOC corresponding to the destination EID if the RLOC corresponding to the destination EID is not registered in the routing table 54 when the forwarding unit 51 sends out the packet. Specifically, when the RLOC resolution unit 52 inquires of the controller 30 about the RLOC corresponding to the destination EID, and acquires the RLOC as a response, the RLOC resolution unit 52 stores the correspondence relationship between the destination EID and the RLOC in the routing table 54 (the destination EID and Correspondence information with the relevant RLOC) is registered.
  • the CPE registration unit 53 When the CPE 50 is activated, the CPE registration unit 53 notifies the predesignated area representative router (AR 40) of the IP address (RLOC) of the CPE 50 itself and the subordinate EID.
  • the CPE registration unit 53 also receives the area ID from the AR 40 as a response to the notification of the RLOC and EID, and also enables the routing table 54 to receive the encapsulated packet from the AR 40 (decapsulation is possible). register information for Note that the area ID is identification information of an area.
  • FIG. 4 is a diagram showing a functional configuration example of the area representative router (AR40).
  • AR 40 has forwarding section 41 and CPE connection section 42 . Each of these units is implemented by one or more programs installed in the AR 40 that are executed by the CPU of the AR 40 .
  • AR 40 also utilizes routing table 43 .
  • the routing table 43 can be implemented using, for example, the memory device or auxiliary storage device of the AR40.
  • the forwarding unit 41 decapsulates the packet from the data center 20, searches the routing table 43 using the destination EID of the original IP packet (EID under the destination CPE 50) as a key, and acquires the RLOC of the CPE 50 corresponding to the destination EID. do. The forwarding unit 41 then re-encapsulates the original packet with the RLOC and transmits the re-encapsulated packet to the destination CPE 50 .
  • the AR 40 does not have to be involved in the communication in the direction of the CPE 50 on the device 10 side to the CPE 50 on the cloud side, but may play a role of forwarding IPv6 packets encapsulated with SRv6 or the like as a normal router. In this case, the forwarding unit 41 has a standard IPv6 forwarding function.
  • the CPE connection unit 42 executes processing for connecting the CPE 50 when receiving a connection request from the CPE 50 .
  • the CPE connection unit 42 receives the IP address (RLOC) and EID of the CPE 50 included in the connection request from the CPE 50, and stores the EID of the CPE 50 in the routing table 43 of its own AR 40 with the corresponding RLOC. Register route information for encapsulation and transmission.
  • the CPE connection unit 42 notifies the CPE 50 of the area ID of the area under the jurisdiction of its own AR 40 as a connection response. This enables the forwarding unit 41 to deliver packets transmitted from the cloud side to the destination CPE 50 .
  • the routing table 43 is a storage unit that holds a routing table necessary when the forwarding unit 41 executes packet transfer, packet encapsulation, and packet decapsulation. A specific example of the routing table 43 will be described later.
  • FIG. 5 is a diagram showing a configuration example of the routing table 54 of each CPE 50.
  • FIG. FIG. 5 shows a specific example of the routing table 54 for the network configuration example of FIG.
  • the routing table 54 of the CPE 50 consists of destination addresses (destination prefixes) and corresponding processing details.
  • the forwarding unit 51 searches the routing table 54 using the destination address of the received IP packet as a key, and executes the processing described in the record. A specific description will be given based on an example of the routing table 54-11 of the CPE 50-11.
  • the forwarding unit 51 encapsulates the packet received by the CPE 50-11 from the host 60 under its control with IP#31, which is the RLOC of the CPE 50-31, which is reachable within the core network N1, and sends the encapsulated packet.
  • IP#31 which is the RLOC of the CPE 50-31, which is reachable within the core network N1
  • the routing table 54 of the CPE 50 on the device 10 side holds such a record for each host 60 on the cloud side with which it communicates.
  • the routing table 54-21 of CPE 50-21 is almost the same as the routing table 54-11 of CPE 50-11, but since CPE 50-21 belongs to area 2, the corresponding CPE 50 on the cloud side is CPE 50-32. Therefore, the processing of the first record is "Encap (IP#32)". In addition, since the RLOC of the CPE 50-21 is IP#21 and the subordinate EID is EID#21, the "destination" of the third and fourth records of the routing table 54-21 is the routing table 54-11 of the CPE 50-11. different from
  • CPE50-31 and CPE50-32 are CPE50 on the cloud side.
  • These routing tables 54 are also basically the same as the CPE 50 on the device 10 side.
  • there is a CPE 50 corresponding to each area on the cloud side and all packets from the cloud side CPE 50 to the CPE 50 on the device 10 side are sent to the area representative router (this If so, it is to be sent to AR40-1).
  • This record fulfills that role, and this one record alone can handle all communications from the cloud side to the device 10 side.
  • FIG. 6 is a diagram showing a configuration example of the routing table 43 of the area representative router (AR40). A specific description will be given by taking the routing table 43-1 of the AR 40-1 as an example.
  • FIG. 7 is a diagram showing a functional configuration example of the controller 30.
  • the controller 30 has a CPE inquiry unit 31 and a CPE registration/update unit 32 . Each of these units is realized by one or more programs installed in the controller 30 causing the CPU of the controller 30 to execute the process.
  • Controller 30 also utilizes EID-RLOC database 33 . It can be implemented using the EID-RLOC database 33, for example, the memory device of the controller 30 or an auxiliary storage device.
  • the EID-RLOC database 33 is a storage unit that stores the correspondence between the EID assigned under the CPE 50 and the RLOC currently assigned to the CPE 50 . In this embodiment, only the correspondence relationship between the EID of the cloud-side CPE 50 and the RLOC is registered in the EID-RLOC database 33 . The configuration of the EID-RLOC database 33 will be described later.
  • the CPE inquiry unit 31 searches the EID-RLOC database 33 in response to an inquiry about the RLOC corresponding to the EID from the CPE 50, and responds with the RLOC corresponding to the EID.
  • An area ID is registered in each entry of the EID-RLOC database 33, and the CPE inquiry unit 31 replies with the RLOC of the area to which the inquiring CPE 50 belongs.
  • the CPE registration/update unit 32 newly registers or updates the EID-RLOC correspondence registered in the EID-RLOC database 33 . Specifically, the CPE registration/update unit 32 adds a new record to the EID-RLOC database 33 when the CPE 50 is newly connected to the network, or when the CPE 50 moves and the RLOC changes. In addition, the existing EID-RLOC correspondence relationship is changed.
  • FIG. 8 is a diagram showing a configuration example of the EID-RLOC database 33.
  • the EID-RLOC database 33 holds the area ID of the area to which each CPE 50 belongs (corresponding to each CPE 50), in addition to the correspondence between the EID and RLOC of each CPE 50.
  • FIG. In other words, the EID-RLOC database 33 stores an RLOC for each combination of the EID and area ID of each CPE 50 .
  • FIG. 8 shows an example of the EID-RLOC database 33 corresponding to FIG.
  • the EID-RLOC database 33 holds only the information of the CPE 50 on the cloud side, so the EID-RLOC database 33 of FIG. ), and holds only the information of CPE50-32 (second record).
  • the EID-RLOC correspondence of the CPE 50 (CPE 50-11, CPE 50-12, CPE 50-21 in FIG. 1) on the device 10 side is held in the routing table 43 (FIG. 6) of the area representative router AR40.
  • FIG. 9 is a sequence diagram for explaining the connection of the CPE 50 on the device 10 side to the AR 40 and the registration of the CPE 50 on the cloud side to the controller 30, which are executed prior to communication.
  • the CPE registration unit 53 of the CPE 50-11 sends the CPE to the nearest AR 40 (AR 40-1 in this case) (the area to which the CPE 50-11 belongs).
  • a connection request is transmitted (S11).
  • the CPE connection request includes an EID (EID#11) assigned under the CPE 50-11 and an RLOC (IP#11) given by the network.
  • EID#11 assigned under the CPE 50-11
  • IP#11 RLOC
  • the RLOC of the CPE 50-11 is a global IP address issued from the network to which the CPE 50-11 is connected. Also, it is assumed that the EID under the CPE 50 is set in the CPE 50 in advance.
  • the CPE registration unit 53 of the CPE 50-11 receives the CPE connection response
  • the CPE 50-11 recognizes that the area ID to which it belongs is #1.
  • the CPE registration unit 53 of the CPE 50-31 After starting up the CPE 50 (CPE 50-31) on the cloud side, the CPE registration unit 53 of the CPE 50-31 transmits a CPE registration request to the controller 30 (S21).
  • the CPE registration request includes the EID (EID#3) under the CPE 50-31, the RLOC (IP#31) of the CPE 50-31, and the area ID (#1) of the area in charge of the CPE 50-31.
  • the RLOC of the CPE50-31 is also assumed to be a global IP address like the RLOC of the CPE50-11.
  • Various methods are conceivable for assigning IP addresses in a cloud environment, but this embodiment does not depend on the assigning method. As a result, a global IP address that can be reached from the outside should be assigned to the CPEs 50-31.
  • FIG. 10 is a sequence diagram for explaining an example of a processing procedure when a packet is transmitted from host 60-11 under CPE 50-11 to host 60-3 under CPE 50-31.
  • the host 60-11 transmits a packet to the host 60-3 (S31).
  • the host 60-11 recognizes EID#11, which is its own EID, as its own IP address, assigns it to the source address of the packet (represented as SA in FIG. 10), and assigns EID#3 of the host 60-3 to the host.
  • the IP address of 60-3 is recognized and added to the destination address of the packet (denoted as DA in FIG. 10).
  • the hosts 60-11 and 60-3 operate by recognizing the EID as it is as an IP address. Therefore, it suffices to operate as a normal IP host, and functions specific to this embodiment are unnecessary.
  • the RLOC resolution unit 52 sends the RLOC to the controller 30 because the destination EID of the packet is not described in the routing table 54-11.
  • a resolution request is sent (S32).
  • the RLOC resolution request contains EID#3, which is the destination address of the packet received from the host 60-11, and #1, which is the area ID to which the CPE 50-11 belongs.
  • the forwarding unit 51 of the CPE 50-31 When the forwarding unit 51 of the CPE 50-31 receives the packet from the CPE 50-11, it processes the packet based on the routing table 54-31 (see FIG. 5).
  • FIG. 11 is a sequence diagram for explaining the communication flow from the host 60-3 to the host 60-11.
  • step S41 the host 60-3 transmits a packet (hereinafter referred to as "target packet") to the host 60-11 (S41).
  • target packet a packet
  • the destination address of the target packet is set to EID#11, which is the EID of host 60-11
  • the source address of the target packet is set to EID#3, which is the EID of host 60-3.
  • the CPE 50-31 and the CPE 50-32 are listed as candidates, and there are several methods for selecting one of them. Since the host 60-3 has received the packet from the host 60-11 from the CPE 50-31, it may be sent to the CPE 50-31 as a response (reply), or the CPE 50-31 ⁇ host 60- 3, the forwarding unit 51 of the CPE 50-31 may perform SNAT (Source NAT) to change the source address of the packet to the CPE 50-31. In the latter case, the host 60-3 determines that it has received a packet from the CPE 50-31. It is converted to the original address (EID#11, which is the address of host 60-11).
  • EID#11 which is the address of host 60-11
  • IP#11 RLOC of the CPE 50-11
  • FIGS. 12 to 14 the processing procedure executed when CPE 50-11 moves from being under AR40-1 to being under AR40-2 will be described.
  • 12 and 13 show sequence diagrams
  • FIG. 14 shows changes in the routing table of CPE 50-11 and routing tables of AR 40-1 and AR 40-2.
  • CPE50-11 device 10-11 having CPE50-11
  • CPE50-11 reconnects to the access network. That is, the RLOC of CPE50-11 is changed (S51).
  • this record when a packet is sent from the AR 40 to the CPE 50-11, if it is addressed to itself (to the RLOC of the CPE 50-11), it is decapsulated and the routing table 54-11 is searched again. It is for doing
  • the CPE registration unit 53 transmits a CPE connection request to the nearest AR 40 (AR 40-2 in this case) (S52).
  • the EID remains unchanged from before the move, but the RLOC becomes IP#22, which is the newly assigned IP address, as described above.
  • the CPE connection unit 42 of the AR 40-2 when successfully registered in the routing table 43-2, transmits a CPE registration response to the CPE 50-11 (S54).
  • CPE connection 42 is deleted.
  • timeout may be performed (if a specific entry in the routing table 43-1 is not referenced for a certain period of time, it will be deleted); -11 or AR 40-2 or the like explicitly notifies AR 40-1 of the completion of the movement of CPE 50-11, and CPE connection unit 42 of CPE 50-11 creates routing table 43-1 of AR 40-1. You may delete information that is no longer needed in
  • the host 60-11 transmits a packet to the host 60-3 (S55).
  • the RLOC resolution unit 52 of the CPE 50-11 issues an RLOC resolution request to the controller 30 in order to acquire the RLOC corresponding to EID#3, which is the destination address of the packet.
  • the CPE inquiry unit 31 of the controller 30 Upon receiving the RLOC resolution request, the CPE inquiry unit 31 of the controller 30 searches the EID-RLOC database 33 using the EID (EID#3) and area ID (#2) included in the RLOC resolution request as keys (S57). .
  • the area ID was #1
  • CPE50-11 was under AR40-2
  • area ID #2.
  • each CPE 50 (CPE 50-31 and CPE 50-32) on the cloud side receives only packets from CPE 50 under a specific AR 40 (that is, a specific area).
  • step S64 the host 60-3 sends a packet to the host 60-11 (S64).
  • the amount of processing of inquiries (transactions) to the database holding the EID-RLOC correspondence information is also a problem. Specifically, query processing to the database holding the EID-RLOC correspondence information occurs each time the device initiates communication to an application with a new EID.
  • the device side can cache information that has been queried once, but as described above, the EID-RLOC correspondence information held in the database is constantly updated. If the cache is held for a longer period of time, the number of inquiries can be reduced. communication may not be possible.
  • the device 10 is an example of a communication device.
  • the data center 20 is an example of a predetermined information processing device.
  • AR40 is an example of a containment device.
  • RLOC is an example of a first IP address.
  • EID is an example of a second IP address.
  • CPE registration unit 53 is an example of a registration unit.
  • the forwarding unit 51 is an example of a packet processing unit.
  • RLOC resolver 52 is an example of a resolver.
  • the RLOC of CPE 50-31 or CPE 50-32 is an example of a third IP address.
  • the EID of host 60-3 is an example of a fourth IP address.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

複数のエリア間を移動し、所定の情報処理装置と通信する通信装置は、それぞれが前記複数のエリアのうちのいずれか一つのエリアに対応する複数の収容装置のうち、当該通信装置が属するエリアに対応する前記収容装置に対し、当該通信装置の移動によって変更される第１のＩＰアドレスと、前記移動によって変更されない第２のＩＰアドレスとを通知することで、前記所定の情報処理装置からの前記第２のＩＰアドレスを宛先とするパケットを前記第１のＩＰアドレスによってカプセル化して送信させるための情報を当該収容装置に登録させる登録部と、前記第１のＩＰアドレスによってカプセル化されたパケットを前記第２のＩＰアドレスを宛先とするパケットにデカプセル化するパケット処理部と、を有することで、ＩＰアドレスが変化する通信装置に関する通信を効率化する。

Description

通信装置、通信方法及びプログラム
　本発明は、通信装置、通信方法及びプログラムに関する。
　コネクテッドカー等のように、物理的に移動するデバイスをネットワークに接続して、接続性を提供し続けるためには、ＩＰモビリティの機能が必要である。ＩＰモビリティは、デバイスのＩＰアドレスが変わったとしても、デバイスのアプリケーションが影響を受けずに通信を継続できる機能のことである。
　ＩＰモビリティを実現する技術の代表例としては、ＬＩＳＰ（Locator/ID Separation Protocol）がある（非特許文献１）。ＬＩＳＰでは、アプリケーションが通信に利用するＩＰアドレスをＥＩＤ（End Point ID）とし、デバイスが外部のネットワークと通信する際に利用するＩＰアドレスをＲＬＯＣ（Routing Locator）として定義する。ＲＬＯＣは、デバイスが接続するネットワークが変更されたり、移動に伴ってＩＰアドレスの再割り当てがあったりすると変更される。一般的には、ＲＬＯＣは、デバイスがセルラー網やＷｉ－Ｆｉ（登録商標）等に接続した際に払い出されるＩＰアドレスである。一方、ＥＩＤは、常に同じ値である。ＬＩＳＰでは、外部のデータベースで、ＥＩＤ－ＲＬＯＣの対応関係を保持し、その対応関係を常に最新に保つ。デバイスは、通信先のアプリケーションのＥＩＤをキーとして、ＲＬＯＣを問い合わせ、宛先のＲＬＯＣでＩＰパケットをカプセル化してネットワークに送信することで、ＩＰモビリティを実現する。
"The Locator/ID Separation Protocol (LISP)"、IETF RFC6830、［online］、＜ＵＲＬ：https://tools.ietf.org/html/rfc6830＞
　ＬＩＳＰは、ＬＩＳＰに参加する全端末間でＩＰモビリティを実現することができるが、コネクテッドカーやセンサ等のデバイスからクラウド側にデータを収集するような一般的なＩｏＴ（Internet of Things）のユースケースにおいては、デバイス数が増加すると、スケーラビリティが問題になる。例えば、コネクテッドカーでは、デバイス数が数百万～数千万にもなる。
　具体的には、デバイスの通信先のクラウド側のデバイスのルーティングテーブル量（経路数）が問題になる。
　デバイスのルーティングテーブルは、そのデバイスが通信する宛先となるＥＩＤをキーとして、対応するＲＬＯＣでカプセル化するための情報が保持されている。或るデバイスが多数のデバイスやアプリケーションと同時に通信する場合、ＥＩＤの数に応じてルーティングテーブルの量（経路数）が増えてしまう。例えば、移動するＩｏＴデバイスのセンサ情報を定期的に収集するようなアプリケーションを想定すると、ＩｏＴデバイスの通信先はクラウド側のアプリケーションのみであるが、クラウド側のデバイス（デバイス相当の終端装置）は、大量のＩｏＴデバイスと通信する必要がある。センサ情報のような小容量のデータを間欠的に送信するアプリケーションの場合、ネットワーク帯域よりも先に、クラウド側のデバイスのルーティングテーブルの量（経路数）がボトルネックとなる可能性がある。
　本発明は、上記の点に鑑みてなされたものであって、ＩＰアドレスが変化する通信装置に関する通信を効率化することを目的とする。
　そこで上記課題を解決するため、複数のエリア間を移動し、所定の情報処理装置と通信する通信装置は、それぞれが前記複数のエリアのうちのいずれか一つのエリアに対応する複数の収容装置のうち、当該通信装置が属するエリアに対応する前記収容装置に対し、当該通信装置の移動によって変更される第１のＩＰアドレスと、前記移動によって変更されない第２のＩＰアドレスとを通知することで、前記所定の情報処理装置からの前記第２のＩＰアドレスを宛先とするパケットを前記第１のＩＰアドレスによってカプセル化して送信させるための情報を当該収容装置に登録させる登録部と、前記第１のＩＰアドレスによってカプセル化されたパケットを前記第２のＩＰアドレスを宛先とするパケットにデカプセル化するパケット処理部と、を有する。
　ＩＰアドレスが変化する通信装置に関する通信を効率化することができる。
本発明の実施の形態における通信システムの構成例を示す図である。 本発明の実施の形態におけるデバイス１０のハードウェア構成例を示す図である。 ＣＰＥ５０の機能構成例を示す図である。 エリア代表ルータ（ＡＲ４０）の機能構成例を示す図である。 各ＣＰＥ５０のルーティングテーブル５４の構成例を示す図である。 エリア代表ルータ（ＡＲ４０）のルーティングテーブル４３の構成例を示す図である。 コントローラ３０の機能構成例を示す図である。 ＥＩＤ－ＲＬＯＣデータベース３３の構成例を示す図である。 通信に先立って実行される、デバイス１０側ＣＰＥ５０のＡＲ４０への接続や、クラウド側ＣＰＥ５０のコントローラ３０への登録を説明するためのシーケンス図である。 ＣＰＥ５０－１１の配下のホスト６０－１１からＣＰＥ５０－３１の配下のホスト６０－３に向けてパケットが送信される際の処理手順の一例を説明するためのシーケンス図である。 ホスト６０－３からホスト６０－１１への通信の流れを説明するためのシーケンス図である。 ＣＰＥ５０－１１が属するエリアが変化した際に実行される処理手順の一例を説明するためのフローチャートである。 ＣＰＥ５０－１１が属するエリアが変化した際に実行される処理手順の一例を説明するためのフローチャートである。 ＣＰＥ５０－１１が属するエリアが変化した際の各ルーティングテーブルの変化の例を示す図である。
　以下、図面に基づいて本発明の実施の形態を説明する。
　［本実施の形態の概要］
　本実施の形態では、（１）複数のエリア間を移動するデバイス１０を収容するエリア代表ルータ（ＡＲ４０）をエリアごとに設置し、（２）クラウド側の終端装置とエリア代表ルータとを１対１で対応付ける、という構成をとることで課題を解決する。
　（１）に関して、エリア代表ルータは、物理的なエリア毎（例えば、県単位など）に設置され、移動するデバイス１０は、通信に先立って、最寄りのエリア代表ルータに接続する。エリア代表ルータは、自身の配下に接続されているデバイス１０のＥＩＤ－ＲＬＯＣの対応関係をルーティングテーブルとして保持する。なお、ＥＩＤ（End Point ID）とは、ＩＰモビリティを実現する代表的な技術であるＬＩＳＰ（Locator/ID Separation Protocol）において、アプリケーションが通信に利用するＩＰアドレスをいい、デバイス１０の移動に依存しない（デバイス１０の移動にともなって変化しない）。一方、ＲＬＯＣ（Routing Locator）とは、ＬＩＳＰにおいて、デバイス１０等の端末が外部のネットワークと通信する際に利用するＩＰアドレスをいい、デバイス１０の移動にともなって変化する。
　（２）により、クラウド側の終端装置のルーティングテーブルを削減する。クラウド側の終端装置は、仮想化技術によってＶＭ（Virtual Machine）やコンテナといった形態で実装され、コンピューティングリソースの許す範囲内で、複数立ち上げることができる。そのため、１つのエリア代表ルータに対して、１つの終端装置を設置することが可能となり、終端装置から見ると、通信相手は、対応するエリア代表ルータに限定される。すなわち、クラウド側の終端装置のルーティングテーブルには、対応する１つのエリア代表ルータの情報のみが登録されこととなる。したがって、クラウド側の終端装置は、ＥＩＤ－ＲＬＯＣの対応関係を保持する必要がないため、データベースへの問い合わせをする必要がなく、データベースの問い合わせ処理量の削減も期待できる。
　［システム構成］
　本実施の形態では、通信先の端末やアプリケーションが保持するＩＰアドレスをＥＩＤ（Endpoint ID）とし、各デバイス１０やクラウドの拠点（データセンタ２０）をコアネットワークＮ１に接続（収容）するＣＰＥ（Customer Premises Equipment）間で、ＩＰパケットをカプセル化して送信する手段としてＳＲｖ６（Segment Routing for IPv6）を利用することとする。コアネットワークＮ１は、ＩＰｖ６に対応していればよい。ただし、ＣＰＥ間でカプセル化するプロトコルはＳＲｖ６に限定されず、ＩＰパケットをカプセル化できる他の手段によって代用されてもよい。
　図１は、本発明の実施の形態における通信システムの構成例を示す図である。図１において、複数のデバイス１０（デバイス１０－１１、デバイス１０－１２、デバイス１０－２１）やデータセンタ２０は、終端装置としてのＣＰＥ５０やホスト６０を有し、ＣＰＥ５０を介してコアネットワークＮ１に接続される。デバイス１０内又はデータセンタ内２０において、ＣＰＥ５０とホスト６０とはデバイス１０内又はデータセンタ内２０のＬＡＮによって接続される。各デバイス１０のＣＰＥ５０は、いずれかのエリアに所属し、そのエリアを管轄するエリア代表ルータであるＡＲ４０に対して、ＳＲｖ６トンネルを介して接続される。また、ＣＰＥ５０からコアネットワークＮ１を介してアクセスできる場所にコントローラ３０が配置される。
　図１には、各装置やホスト６０のＩＰアドレスを示す文字列が括弧内に示されている。"ＩＰ"で始まる文字列は、ＣＰＥ５０又はＡＲ４０のＩＰアドレス（ＲＬＯＣ）であり、コアネットワークＮ１を介して到達性の有るアドレスである。コアネットワークＮ１を介した通信は、このＩＰアドレスでカプセル化される。一方、"ＥＩＤ"で始まる文字列は、ＣＰＥ５０配下のＬＡＮ内に存在するホスト６０やアプリケーションに付与されたＩＰアドレスである。ＥＩＤは固定的に付与され、デバイス１０が移動したり、接続するネットワークが変更になったりしても、変化しない（すなわち、デバイス１０の位置に依存せしない）。アプリケーションは、常に、このＥＩＤで通信をし続けることができる。
　［デバイス１０等のハードウェア構成］
　図２は、本発明の実施の形態におけるデバイス１０のハードウェア構成例を示す図である。図２のデバイス１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。
　デバイス１０での処理を実現するプログラムは、ＣＤ－ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
　メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってデバイス１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
　なお、データセンタ２０、コントローラ３０及びＡＲ４０等も、図２と同様のハードウェア構成を有してもよい。
　［各装置の機能構成］
　図３は、ＣＰＥ５０の機能構成例を示す図である。なお、デバイス１０側（ＣＰＥ５０－１１，１２，２１）、データセンタ２０側（ＣＰＥ５０－３１，３２）のいずれにおいてＣＰＥ５０は同じ構成を有する。図３において、ＣＰＥ５０は、フォワーディング部５１、ＲＬＯＣ解決部５２及びＣＰＥ登録部５３を有する。これら各部は、デバイス１０又はデータセンタ２０にインストールされた１以上のプログラムが、デバイス１０又はデータセンタ２０のＣＰＵに実行させる処理により実現される。ＣＰＥ５０は、また、ルーティングテーブル５４を利用する。ルーティングテーブル５４は、例えば、デバイス１０又はデータセンタ２０のメモリ装置又は補助記憶装置等を用いて実現可能である。
　フォワーディング部５１は、自ＣＰＥ５０配下のホスト６０からデータセンタ２０へのパケットをカプセル化してコアネットワークＮ１へ送出すると共に、データセンタ２０等から自ＣＰＥ５０配下のホスト６０へのカプセル化されたパケットをコアネットワークＮ１から受信した際に、当該パケットをデカプセル化して、デカプセル化されたパケットをホスト６０へ配送する。本実施の形態では、カプセル化プロトコルとしてＳＲｖ６が利用されるため、ＣＰＥ５０のフォワーディング部５１はＳＲｖ６のカプセル化、デカプセル化を実行することになる。
　ルーティングテーブル５４は、パケットの転送、パケットのカプセル化、パケットのデカプセル化をフォワーディング部５１が実行する際に必要な経路表を保持する記憶部である。ルーティングテーブル５４の具体例は後述する。
　ＲＬＯＣ解決部５２は、フォワーディング部５１がパケットを送出する際に、宛先ＥＩＤに対応するＲＬＯＣがルーティングテーブル５４に登録されていなかった場合に、宛先ＥＩＤに対応するＲＬＯＣを解決する。具体的には、ＲＬＯＣ解決部５２は、コントローラ３０に対して、宛先ＥＩＤに対応するＲＬＯＣを問い合わせ、その応答としてＲＬＯＣを取得したら、ルーティングテーブル５４に宛先ＥＩＤ－ＲＬＯＣの対応関係（当該宛先ＥＩＤと当該ＲＬＯＣとの対応情報）を登録する。
　ＣＰＥ登録部５３は、ＣＰＥ５０が起動された際に、予め指定されたエリア代表ルータ（ＡＲ４０）に対して、ＣＰＥ５０自身のＩＰアドレス（ＲＬＯＣ）と配下のＥＩＤを通知する。ＣＰＥ登録部５３は、また、ＲＬＯＣ及びＥＩＤの通知に対する応答として、エリアＩＤをＡＲ４０から受け取るとともに、ルーティングテーブル５４に対して、ＡＲ４０からのカプセル化されたパケットを受け取れるようにする（デカプセル化できるようにする）ための情報を登録する。なお、エリアＩＤとは、エリアの識別情報である。
　図４は、エリア代表ルータ（ＡＲ４０）の機能構成例を示す図である。図４において、ＡＲ４０は、フォワーディング部４１及びＣＰＥ接続部４２を有する。これら各部は、ＡＲ４０にインストールされた１以上のプログラムが、ＡＲ４０のＣＰＵに実行させる処理により実現される。ＡＲ４０は、また、ルーティングテーブル４３を利用する。ルーティングテーブル４３は、例えば、ＡＲ４０のメモリ装置又は補助記憶装置等を用いて実現可能である。
　フォワーディング部４１は、データセンタ２０からのパケットをデカプセル化して、元のＩＰパケットの宛先ＥＩＤ（宛先ＣＰＥ５０配下のＥＩＤ）をキーとしてルーティングテーブル４３を検索し、宛先ＥＩＤに対応するＣＰＥ５０のＲＬＯＣを取得する。その後、フォワーディング部４１は、当該ＲＬＯＣで元のパケットを再カプセル化して、再カプセル化されたパケットを宛先ＣＰＥ５０に送信する。なお、ＡＲ４０は、デバイス１０側ＣＰＥ５０→クラウド側ＣＰＥ５０方向の通信には関与しなくてよいが、通常のルータとして、ＳＲｖ６等でカプセル化されたＩＰｖ６パケットを転送する役割を担ってもよい。この場合、フォワーディング部４１は、標準的なＩＰｖ６の転送機能を有することになる。
　ＣＰＥ接続部４２は、ＣＰＥ５０からの接続要求を受信した際に、ＣＰＥ５０を接続するための処理を実行する。具体的には、ＣＰＥ接続部４２は、ＣＰＥ５０からの接続要求に含まれるＣＰＥ５０のＩＰアドレス（ＲＬＯＣ）とＥＩＤを受け取り、自ＡＲ４０のルーティングテーブル４３に、ＣＰＥ５０のＥＩＤに対して、対応するＲＬＯＣでカプセル化して送出するための経路情報を登録する。その後、ＣＰＥ接続部４２は、接続応答として、自ＡＲ４０が管轄するエリアのエリアＩＤをＣＰＥ５０に通知する。これにより、フォワーディング部４１が、クラウド側から送信されてきたパケットを、宛先となるＣＰＥ５０に配送することができるようになる。
　ルーティングテーブル４３は、フォワーディング部４１がパケットの転送、パケットのカプセル化、パケットのデカプセル化を実行する際に必要な経路表を保持する記憶部である。ルーティングテーブル４３の具体例は後述する。
　図５は、各ＣＰＥ５０のルーティングテーブル５４の構成例を示す図である。図５には、図１のネットワーク構成例の場合の具体的なルーティングテーブル５４の例が示されている。
　ＣＰＥ５０のルーティングテーブル５４は、宛先アドレス（宛先プレフィックス）と対応する処理内容から構成される。フォワーディング部５１は、受信したＩＰパケットの宛先アドレスをキーとしてルーティングテーブル５４を検索して、そのレコードに記載された処理を実施する。ＣＰＥ５０－１１のルーティングテーブル５４－１１の例に基づいて、具体的に説明する。
　「宛先＝ＥＩＤ＃３、処理＝Ｅｎｃａｐ（ＩＰ＃３１）」というレコードは、デバイス１０側のＣＰＥ５０－１１が、クラウド側のＣＰＥ５０－３１（ＲＬＯＣ：ＩＰ＃３１）へと通信する際に利用するものである。宛先欄にある「ＥＩＤ＃３」は、クラウド側のホスト６０やアプリケーションが利用するアドレスであり、ＣＰＥ５０－１１が受信したパケットの宛先アドレスがこれに該当する場合には、フォワーディング部５１は、「Ｅｎｃａｐ（ＩＰ＃３１）」の処理を実行する。「Ｅｎｃａｐ（ＩＰ＃３１）」は、宛先ＩＰアドレスをＩＰ＃３１として、ＳＲｖ６でカプセル化して送出するという意味を示す。すなわち、ＣＰＥ５０－１１が配下のホスト６０から受信したパケットを、フォワーディング部５１は、コアネットワークＮ１内に到達性のあるＣＰＥ５０－３１のＲＬＯＣであるＩＰ＃３１でカプセル化して送出することになる。デバイス１０側のＣＰＥ５０のルーティングテーブル５４は、通信する先のクラウド側のホスト６０毎に、このようなレコードを保持する。
　「宛先＝ＩＰ＃１１、処理＝Ｄｅｃａｐ－＞Ｌｏｏｋｕｐ」というレコードは、宛先ＩＰアドレスが「ＩＰ＃１１」の場合、そのパケットをデカプセル化（Ｄｅｃａｐ）して、再度、ルーティングテーブル５４－１１を検索する（Ｌｏｏｋｕｐ）という意味を示す。ＩＰ＃１１は、ＣＰＥ５０－１１のＩＰアドレス（ＲＬＯＣ）であるため、このレコードは、「自分宛ての（カプセル化された）パケットに対して、デカプセル化して、ルーティングテーブル５４－１１を再検索する」という処理を示す。
　「宛先＝ＥＩＤ＃１１、処理＝Ｄｉｒｅｃｔ」というレコードは、ＩＰパケットの宛先アドレスが「ＥＩＤ＃１１」の場合には、直接配送する、という意味を示す。直接配送とは、同一ＬＡＮ内に宛先アドレスが存在し、宛先に対して直接ＩＰパケットを送出するという意味である。このレコードは、前述の「宛先＝ＩＰ＃１１、処理＝Ｄｅｃａｐ－＞Ｌｏｏｋｕｐ」の結果、ルーティングテーブル５４－１１を再検索したときに、宛先が自身の配下のホスト６０である場合に、直接配送できるようにするためのものである。
　ＣＰＥ５０－２１のルーティングテーブル５４－２１は、ＣＰＥ５０－１１のルーティングテーブル５４－１１とほぼ同様であるが、ＣＰＥ５０－２１はエリア２に属するため、クラウド側において対応するＣＰＥ５０がＣＰＥ５０－３２である。そのため、１レコード目の処理が「Ｅｎｃａｐ（ＩＰ＃３２）」となっている。また、ＣＰＥ５０－２１のＲＬＯＣがＩＰ＃２１であり、配下のＥＩＤがＥＩＤ＃２１であるため、ルーティングテーブル５４－２１の３～４レコード目の「宛先」がＣＰＥ５０－１１のルーティングテーブル５４－１１と異なる。
　ＣＰＥ５０－３１及びＣＰＥ５０－３２はクラウド側のＣＰＥ５０である。これらのルーティングテーブル５４も基本的にはデバイス１０側のＣＰＥ５０と同じである。
　ＣＰＥ５０－３１のルーティングテーブル５４－３１の１レコード目の、「宛先＝Ｄｅｆａｕｌｔ、処理＝Ｅｎｃａｐ（ＩＰ＃Ａ１）」は、他のレコードの宛先に当てはまらないパケットは、カプセル化してＩＰ＃Ａ１、すなわち、エリア代表ルータＡＲ４０－１に送信するという意味を示す。本実施の形態では、クラウド側にはエリアごとに対応するＣＰＥ５０が存在し、そのクラウド側ＣＰＥ５０からデバイス１０側のＣＰＥ５０へのパケットは、全て当該クラウド側ＣＰＥ５０が対応するエリアのエリア代表ルータ（この場合はＡＲ４０－１）に送信することになっている。このレコードは、その役割を果たすものであり、この１レコードのみで、クラウド側→デバイス１０側の全ての通信に対応できる。ＣＰＥ５０－３２のルーティングテーブル５４－３２の１レコード目も同様であるが、ＣＰＥ５０－３２はエリア２に対応するエリア代表ルータＡＲ４０－２に送信することになるため、処理が「Ｅｎｃａｐ（ＩＰ＃Ａ２）」となっている。
　ＣＰＥ５０－３１又はＣＰＥ５０－３２のルーティングテーブル５４の２～３レコード目は、デバイス１０側→クラウド側のパケットを処理するレコードであり、宛先が自分であればデカプセル化し（「宛先＝ＩＰ＃３１、処理＝Ｄｅｃａｐ－＞Ｌｏｏｋｕｐ」のレコード）、直接宛先のホスト６０へ配送する（「宛先＝ＥＩＤ＃３、処理＝Ｄｉｒｅｃｔ」）ことを示す。
　図６は、エリア代表ルータ（ＡＲ４０）のルーティングテーブル４３の構成例を示す図である。ＡＲ４０－１のルーティングテーブル４３－１を例に、具体的に説明する。
　１レコード目（（１）の行）の「宛先＝ＩＰ＃Ａ１、処理＝Ｄｅｃａｐ－＞Ｌｏｏｋｕｐ」は、クラウド側のＣＰＥ５０から送信されてきた自分宛て（ＩＰ＃Ａ１宛て）のパケットを受信したらデカプセル化して、再度ルーティングテーブル４３を検索する、という意味を示す。
　２レコード目の「宛先＝ＥＩＤ＃１１、処理＝Ｅｎｃａｐ（ＩＰ＃１１）」は、宛先がＥＩＤ＃１１、すなわち、ＣＰＥ５０－１１配下のＥＩＤである場合には、ＣＰＥ５０－１１のＲＬＯＣであるＩＰ＃１１でカプセル化して送出する、という意味を示す。３レコード目も同様に、ＣＰＥ５０－１２配下のＥＩＤ（ＩＰ＃１２）宛てのパケットを、ＣＰＥ５０－１２のＲＬＯＣであるＩＰ＃１２でカプセル化して送出するという意味を示す。これらの処理（（２）の行の処理）は、１レコード目（（２）の行）の処理の結果、デカプセル化されたパケットに対して実施される。ＡＲ４０－２のルーティングテーブル４３－２も同様である。
　図７は、コントローラ３０の機能構成例を示す図である。図７において、コントローラ３０は、ＣＰＥ問い合わせ部３１及びＣＰＥ登録・更新部３２を有する。これら各部は、コントローラ３０にインストールされた１以上のプログラムが、コントローラ３０のＣＰＵに実行させる処理により実現される。コントローラ３０は、また、ＥＩＤ－ＲＬＯＣデータベース３３を利用する。ＥＩＤ－ＲＬＯＣデータベース３３、例えば、コントローラ３０のメモリ装置又は補助記憶装置等を用いて実現可能である。
　ＥＩＤ－ＲＬＯＣデータベース３３は、ＣＰＥ５０配下に割り当てられているＥＩＤと、そのＣＰＥ５０に現在割り当てられているＲＬＯＣとの対応関係を記憶する記憶部である。本実施の形態では、クラウド側ＣＰＥ５０のＥＩＤとＲＬＯＣとの対応関係だけがＥＩＤ－ＲＬＯＣデータベース３３に登録されている。ＥＩＤ－ＲＬＯＣデータベース３３の構成は後述する。
　ＣＰＥ問い合わせ部３１は、ＣＰＥ５０からの、ＥＩＤに対応するＲＬＯＣの問い合わせに対して、ＥＩＤ－ＲＬＯＣデータベース３３を検索して、当該ＥＩＤに対応するＲＬＯＣを応答する。ＥＩＤ－ＲＬＯＣデータベース３３の各エントリにはエリアＩＤが登録されており、ＣＰＥ問い合わせ部３１は、問い合わせ元のＣＰＥ５０が所属するエリアのＲＬＯＣを返答する。
　ＣＰＥ登録・更新部３２は、ＥＩＤ－ＲＬＯＣデータベース３３に登録されているＥＩＤ－ＲＬＯＣの対応関係の新規登録や更新を実行する。具体的には、ＣＰＥ登録・更新部３２は、ＣＰＥ５０が新たにネットワーク接続された場合に、新規にＥＩＤ－ＲＬＯＣデータベース３３にレコードを追加したり、ＣＰＥ５０が移動してＲＬＯＣが変更になった場合に、既存のＥＩＤ－ＲＬＯＣの対応関係を変更したりする。
　図８は、ＥＩＤ－ＲＬＯＣデータベース３３の構成例を示す図である。ＥＩＤ－ＲＬＯＣデータベース３３は、各ＣＰＥ５０のＥＩＤとＲＬＯＣの対応関係に加えて、各ＣＰＥ５０が所属する（各ＣＰＥ５０に対応する）エリアのエリアＩＤも保持する。換言すれば、ＥＩＤ－ＲＬＯＣデータベース３３は、各ＣＰＥ５０のＥＩＤとエリアＩＤとの組み合わせごとにＲＬＯＣを記憶する。図８には、図１に対応したＥＩＤ－ＲＬＯＣデータベース３３の例が示されている。前述の通り、本実施の形態において、ＥＩＤ－ＲＬＯＣデータベース３３には、クラウド側のＣＰＥ５０の情報だけが保持されるため、図８のＥＩＤ－ＲＬＯＣデータベース３３は、ＣＰＥ５０－３１の情報（１レコード目）、ＣＰＥ５０－３２の情報（２レコード目）のみを保持する。なお、デバイス１０側のＣＰＥ５０（図１のＣＰＥ５０－１１、ＣＰＥ５０－１２、ＣＰＥ５０－２１）のＥＩＤ－ＲＬＯＣの対応関係は、エリア代表ルータＡＲ４０のルーティングテーブル４３（図６）に保持される。
　［処理手順］
　以下、図１の通信システムにおいて実行される処理手順について説明する。図９は、通信に先立って実行される、デバイス１０側ＣＰＥ５０のＡＲ４０への接続や、クラウド側ＣＰＥ５０のコントローラ３０への登録を説明するためのシーケンス図である。
　まず、デバイス１０側ＣＰＥ５０（ＣＰＥ５０－１１）がＡＲ４０に接続する際の処理手順を説明する。
　ＣＰＥ５０－１１がネットワークに接続されＩＰアドレス（ＲＬＯＣ）を付与されると、ＣＰＥ５０－１１のＣＰＥ登録部５３は、最寄り（ＣＰＥ５０－１１が属するエリア）のＡＲ４０（この場合はＡＲ４０－１）にＣＰＥ接続要求を送信する（Ｓ１１）。ＣＰＥ接続要求には、ＣＰＥ５０－１１の配下に割り当てられているＥＩＤ（ＥＩＤ＃１１）と、ネットワークから付与されたＲＬＯＣ（ＩＰ＃１１）とが含まれる。なお、ＣＰＥ５０－１１のＲＬＯＣは、ＣＰＥ５０－１１が接続されるネットワークから払い出されるグローバルＩＰアドレス等である。また、ＣＰＥ５０配下のＥＩＤは、予めＣＰＥ５０に設定されているものとする。
　ＡＲ４０－１のＣＰＥ接続部４２は、ＣＰＥ５０－１１からのＣＰＥ接続要求を受信すると、ＡＲ４０－１のルーティングテーブル４３－１に、ＡＲ４０－１からＣＰＥ５０－１１へのパケット転送に必要な情報を登録する（Ｓ１２）。この場合、「宛先＝ＥＩＤ＃１１、処理＝Ｅｎｃａｐ（ＩＰ＃１１）」という情報が登録される（図６参照）。これは、ＡＲ４０－１が、宛先ＩＰアドレスがＥＩＤ＃１１のパケット、すなわち、ＣＰＥ５０－１１配下のホスト６０宛てのパケットを受信したら、宛先アドレス＝ＩＰ＃１１、すなわち、ＣＰＥ５０－１１のＲＬＯＣのＩＰアドレスでカプセル化をして送信する、という意味を示す。
　続いて、ＡＲ４０－１のＣＰＥ接続部４２は、ＣＰＥ接続応答（接続＝ＯＫ、エリアＩＤ＝＃１）をＣＰＥ５０－１１へ送信する（Ｓ１３）。ＣＰＥ５０－１１のＣＰＥ登録部５３が当該ＣＰＥ接続応答を受信することで、ＣＰＥ５０－１１は、自身が所属するエリアＩＤが＃１であることを認識する。
　次に、クラウド側のＣＰＥ５０（ＣＰＥ５０－３１）の情報をコントローラ３０に登録する際の処理手順を説明する。
　クラウド側のＣＰＥ５０（ＣＰＥ５０－３１）の起動後に、ＣＰＥ５０－３１のＣＰＥ登録部５３は、ＣＰＥ登録要求をコントローラ３０へ送信する（Ｓ２１）。ＣＰＥ登録要求には、ＣＰＥ５０－３１配下のＥＩＤ（ＥＩＤ＃３）と、ＣＰＥ５０－３１のＲＬＯＣ（ＩＰ＃３１）、ＣＰＥ５０－３１が担当するエリアのエリアＩＤ（＃１）が含まれる。なお、ＣＰＥ５０－３１のＲＬＯＣも、ＣＰＥ５０－１１のＲＬＯＣと同様にグローバルＩＰアドレスが想定される。クラウド環境におけるＩＰアドレスの払い出しについては様々な方法が想定されるが、本実施の形態では払い出しの方法には依存しない。結果的にＣＰＥ５０－３１に外部から到達可能なグローバルＩＰアドレスが付与されればよい。
　コントローラ３０のＣＰＥ登録・更新部３２は、ＣＰＥ登録要求を受信すると、ＣＰＥ登録要求に含まれている情報を自身のＥＩＤ－ＲＬＯＣデータベース３３に登録（記憶）する（Ｓ２２）。この場合、「ＥＩＤ＝ＥＩＤ＃３、ＲＬＯＣ＝ＩＰ＃３１、エリアＩＤ＝＃１」というレコードがＥＩＤ－ＲＬＯＣデータベース３３に登録される（図８参照）。続いて、ＣＰＥ登録・更新部３２は、ＣＰＥ登録応答（登録＝ＯＫ）をＣＰＥ５０－３１へ送信する（Ｓ２３）。
　図１０は、ＣＰＥ５０－１１の配下のホスト６０－１１からＣＰＥ５０－３１の配下のホスト６０－３に向けてパケットが送信される際の処理手順の一例を説明するためのシーケンス図である。
　ホスト６０－１１は、ホスト６０－３に向けてパケットを送信する（Ｓ３１）。ホスト６０－１１は、自身のＥＩＤであるＥＩＤ＃１１を自身のＩＰアドレスと認識してパケットの送信元アドレス（図１０ではＳＡと表記）に付与し、ホスト６０－３のＥＩＤ＃３をホスト６０－３のＩＰアドレスと認識してパケットの宛先アドレス（図１０ではＤＡと表記）に付与する。つまり、ホスト６０－１１やホスト６０－３は、ＥＩＤをそのままＩＰアドレスとして認識して動作する。そのため、通常のＩＰホストとして動作すればよく、本実施の形態に特有の機能は不要となる。
　ＣＰＥ５０－１１のフォワーディング部５１が、ホスト６０－１１からのパケットを受信すると、ルーティングテーブル５４－１１に当該パケットの宛先ＥＩＤが記載されていないため、ＲＬＯＣ解決部５２は、コントローラ３０に対してＲＬＯＣ解決要求を送信する（Ｓ３２）。ＲＬＯＣ解決要求には、ホスト６０－１１から受信したパケットの宛先アドレスであるＥＩＤ＃３と、ＣＰＥ５０－１１自身が所属するエリアＩＤである＃１が含まれる。
　コントローラ３０のＣＰＥ問い合わせ部３１は、ＣＰＥ５０－１１からのＲＬＯＣ解決要求を受信すると、当該ＲＬＯＣ解決要求に含まれているＥＩＤ＝ＥＩＤ＃３、エリアＩＤ＝＃１をキーとしてＥＩＤ－ＲＬＯＣデータベース３３を検索する（Ｓ３３）。検索した結果、ＥＩＤ＝ＥＩＤ＃３、エリアＩＤ＝＃１に該当するＲＬＯＣは、ＣＰＥ５０－３１のＲＬＯＣであるＩＰ＃３１であることがわかる。なお、このレコードは、Ｓ２１～Ｓ２３においてＣＰＥ５０－３１がコントローラ３０に対して登録したものである。
　続いて、ＣＰＥ問い合わせ部３１は、ＣＰＥ５０－１１のＲＬＯＣ解決部５２に対してＲＬＯＣ解決応答（ＲＬＯＣ＝ＩＰ＃３１）を送信する（Ｓ３４）。
　ＣＰＥ５０－１１のＲＬＯＣ解決部５２は、当該ＲＬＯＣ解決応答を受信すると、ＣＰＥ５０－１１のルーティングテーブル５４－１１に、「宛先＝ＥＩＤ＃３、処理＝Ｅｎｃａｐ（ＩＰ＃３１）」を登録する（Ｓ３５）（図５のルーティングテーブル５４－１１参照）。これは、宛先アドレスがＥＩＤ＃３のパケットを受信したら、（ＥＩＤ＃３はＣＰＥ５０－３１配下に存在し、ＣＰＥ５０－３１のＲＬＯＣがＩＰ＃３１であるため）宛先＝ＩＰ＃３１でカプセル化して送信することを示す。
　続いて、ＣＰＥ５０－１１のフォワーディング部５１はルーティングテーブル５４－１１を参照して、ホスト６０－１１から受信したパケットを、宛先アドレス＝ＩＰ＃３１、送信元アドレス＝ＩＰ＃１１（ＣＰＥ５０－１１自身のＲＬＯＣ）でカプセル化し、ＣＰＥ５０－３１に向けて送信する（Ｓ３６）。
　ＣＰＥ５０－３１のフォワーディング部５１は、ＣＰＥ５０－１１からのパケットを受信すると、ルーティングテーブル５４－３１（図５参照）に基づいて当該パケットを処理する。ここで、当該パケット（カプセル化されたパケット）は、宛先アドレス＝ＩＰ＃３１であるため、フォワーディング部５１は、該当する処理＝Ｄｅｃａｐ－＞Ｌｏｏｋｕｐを実行する。すなわち、フォワーディング部５１は、当該パケットをデカプセル化したうえで、ルーティングテーブル５４－３１を再検索する（Ｓ３７）。再検索する際のパケット（デカプセル化されたパケット）の宛先アドレスはＥＩＤ＃３であるため、該当する処理＝Ｄｉｒｅｃｔとなり、フォワーディング部５１は、当該パケットをＥＩＤ＃３のホスト６０へ直接配送する（Ｓ３８）。その結果、ホスト６０－３がＣＰＥ５０－３１から当該パケットを受信する。
　図１１は、ホスト６０－３からホスト６０－１１への通信の流れを説明するためのシーケンス図である。
　ステップＳ４１において、ホスト６０－３がホスト６０－１１に向けてパケット（以下、「対象パケット」という。）を送信する（Ｓ４１）。この際、対象パケットの宛先アドレスはホスト６０－１１のＥＩＤであるＥＩＤ＃１１にセットされ、対象パケットの送信元アドレスはホスト６０－３のＥＩＤであるＥＩＤ＃３にセットされる。
　なお、ホスト６０－３が対象パケットを送信する先（次ホップ）としては、ＣＰＥ５０－３１及びＣＰＥ５０－３２が候補として挙げられるが、これらのうちのいずれかを選択する方法はいくつか考えられる。ホスト６０－３がホスト６０－１１からのパケットをＣＰＥ５０－３１から受信したため、その応答（リプライ）となる対象パケットをＣＰＥ５０－３１へ送信するようにしてもよいし、ＣＰＥ５０－３１→ホスト６０－３にパケットを送信する際にＣＰＥ５０－３１のフォワーディング部５１がＳＮＡＴ（Source NAT）を実施して当該パケットの送信元アドレスをＣＰＥ５０－３１に変更してもよい。後者の場合、ホスト６０－３はＣＰＥ５０－３１からパケットを受信したと判断するため、その応答となる対象パケットの宛先アドレスはＣＰＥ５０－３１宛てとなるが、ＣＰＥ５０－３１においてＳＮＡＴにより当該宛先アドレスが元のアドレス（ホスト６０－１１のアドレスであるＥＩＤ＃１１）に変換される。
　ＣＰＥ５０－３１のフォワーディング部５１は、ホスト６０－３から対象パケットを受信すると、ルーティングテーブル５４－３１を参照する（Ｓ４２）。ルーティングテーブル５４－３１（図５参照）には、宛先＝ＥＩＤ＃１１にマッチする具体的なレコードは存在しないため、宛先＝Ｄｅｆａｕｌｔにマッチすることになる。宛先＝Ｄｅｆａｕｌｔの処理はＥｎｃａｐ（ＩＰ＃Ａ１）であるため、フォワーディング部５１は、対象パケットを宛先＝ＩＰ＃Ａ１でカプセル化して、ＡＲ４０－１（エリア＃１のエリア代表ルータ）に送信する（Ｓ４３）。この宛先＝Ｄｅｆａｕｌｔのレコードにより、ＣＰＥ５０－３１がクラウド側のホスト６０から受信したパケットの全てをエリア１のエリア代表ルータであるＡＲ４０－１にカプセル化して送信することになり、ＣＰＥ５０－３１では、デバイス１０側のＣＰＥ５０の個別の経路情報を保持する必要がなくなる。
　ＡＲ４０－１のフォワーディング部４１は、ＣＰＥ５０－３１からカプセル化された対象パケットを受信すると、ルーティングテーブル４３－１（図６参照）を参照する（Ｓ４４）。カプセル化された対象パケットの宛先アドレスはＡＲ４０－１自身のＲＬＯＣであるＩＰ＃Ａ１であるため、ルーティングテーブル４３－１の「宛先＝ＩＰ＃Ａ１、処理＝Ｄｅｃａｐ－＞Ｌｏｏｋｕｐ」のレコードが対象パケットに対応する。そこで、フォワーディング部４１は、対象パケットをデカプセル化して、再度、ルーティングテーブル４３－１を再検索する。デカプセル化されたパケットの宛先アドレスはＥＩＤ＃１１であるため、ルーティングテーブル４３－１では、「宛先＝ＥＩＤ＃１１、処理＝Ｅｎｃａｐ（ＩＰ＃１１）」に該当する。したがって、フォワーディング部４１は、対象パケットの宛先アドレスをＩＰ＃１１にセットしてカプセル化をしたうえで、対象パケットをＣＰＥ５０－１１（ＲＬＯＣ＝ＩＰ＃１１）に向けて送信する（Ｓ４５）。
　ＣＰＥ５０－１１のフォワーディング部５１は、ＡＲ４０－１からカプセル化された対象パケットを受信すると、ルーティングテーブル５４－１１を参照する（Ｓ４６）。具体的には、フォワーディング部５１は、対象パケットの宛先アドレス＝ＩＰ＃１１（ＣＰＥ５０－１１のＲＬＯＣ、つまり、自分宛て）をキーとしてＣＰＥ５０－１１のルーティングテーブル５４－１１を検索する。すると、「宛先＝ＩＰ＃１１、処理＝Ｄｅｃａｐ－＞Ｌｏｏｋｕｐ」のレコードが該当するため、フォワーディング部５１は、対象パケットをデカプセル化して、ルーティングテーブル５４－１１を再検索する。デカプセル化された対象パケットの宛先アドレスはＥＩＤ＃１１であるため、「宛先＝ＥＩＤ＃１１、処理＝Ｄｉｒｅｃｔ」のレコードに該当する。そこで、フォワーディング部５１は、ＥＩＤ＃１１宛て、すなわち、ホスト６０－１１宛てに対象パケットを直接配送する（Ｓ４７）。その結果、ホスト６０－１１は対象パケットを受信する。
　次に、図１２～図１４を用いて、ＣＰＥ５０－１１が、ＡＲ４０－１配下からＡＲ４０－２配下へ移動した際に実行される処理手順について説明する。図１２及び図１３はシーケンス図を示し、図１４はＣＰＥ５０－１１のルーティングテーブルの変化と、ＡＲ４０－１、ＡＲ４０－２のルーティングテーブルを示す図である。
　ＣＰＥ５０－１１（ＣＰＥ５０－１１を有するデバイス１０－１１）がＡＲ４０－１配下からＡＲ４０－２配下へ移動すると、ＣＰＥ５０－１１は、アクセス網に再接続する形になるため、ネットワークから払い出されるＩＰアドレス、すなわち、ＣＰＥ５０－１１のＲＬＯＣが変更になる（Ｓ５１）。この例では、ＣＰＥ５０－１１のＲＬＯＣがＩＰ＃１１からＩＰ＃２２に変更になったと仮定する。そのため、ＣＰＥ５０－１１のＣＰＥ登録部５３は、ＣＰＥ５０－１１のルーティングテーブル５４－１１において、「宛先＝ＩＰ＃１１、処理＝Ｄｅｃａｐ－＞Ｌｏｏｋｕｐ」のレコードを、「宛先＝ＩＰ＃２２、処理＝Ｄｅｃａｐ－＞Ｌｏｏｋｕｐ」に変更する（図１４参照）。なお、このレコードは、ＡＲ４０からＣＰＥ５０－１１宛てにパケットが送信されてきた場合、自分宛て（ＣＰＥ５０－１１のＲＬＯＣ宛て）であれば、デカプセル化してルーティングテーブル５４－１１を再検索する、という処理を行うためのものである。
　ＣＰＥ５０－１１がネットワークに接続されたら、ＣＰＥ登録部５３は、最寄りのＡＲ４０（この場合、ＡＲ４０－２）に対して、ＣＰＥ接続要求を送信する（Ｓ５２）。ＣＰＥ接続要求には、ＥＩＤ＝ＥＩＤ＃１１、ＲＬＯＣ＝ＩＰ＃２２が含まれる。ＥＩＤは移動前から変更は無いが、ＲＬＯＣは前述のように、新たに払い出されたＩＰアドレスであるＩＰ＃２２となる。
　ＡＲ４０－２のＣＰＥ接続部４２は、ＣＰＥ５０－１１からのＣＰＥ接続要求を受信すると、ＣＰＥ５０－１１へパケットを送信するためのレコードをルーティングテーブル４３－２へ登録する（Ｓ５３）。具体的には、ＣＰＥ接続部４２は、図１４のＡＲ４０－２のルーティングテーブル４３－２に対し、「宛先＝ＥＩＤ＃１１、処理＝Ｅｎｃａｐ（ＩＰ＃２２）」というレコードを登録する。これは、宛先アドレスがＣＰＥ５０－１１配下のＥＩＤ＃１１宛てのパケットであれば、ＣＰＥ５０－１１の新たなＲＬＯＣであるＩＰ＃２２でカプセル化して当該パケットを送信する、という処理を示す。
　ＡＲ４０－２のＣＰＥ接続部４２は、正常にルーティングテーブル４３－２への登録ができたら、ＣＰＥ５０－１１へＣＰＥ登録応答を送信する（Ｓ５４）。ＣＰＥ登録応答には、ＡＲ４０－２が所属するエリアＩＤとして、エリアＩＤ＝＃２が含まれる。
　以上で、ＣＰＥ５０－１１がＡＲ４０－１からＡＲ４０－２の配下へ移動した際の接続手続きが完了する。
　なお、ＡＲ４０－１のルーティングテーブル４３－１に登録されていたＣＰＥ５０－１１移動前の情報（宛先＝ＥＩＤ＃１１、処理＝Ｅｎｃａｐ（ＩＰ＃１１））は、今後不要となるためにＣＰＥ５０－１１のＣＰＥ接続部４２が削除する。削除する方法としては、ＣＰＥ５０－１１へのパケットが到着しない状態が一定時間継続したらタイムアウト（一定時間、ルーティングテーブル４３－１の特定のエントリが参照されなかったら削除する）してもよいし、ＣＰＥ５０－１１又はＡＲ４０－２等からＡＲ４０－１に対してＣＰＥ５０－１１の移動が完了したことを明示的に通知して、ＣＰＥ５０－１１のＣＰＥ接続部４２が、ＡＲ４０－１のルーティングテーブル４３－１において不要になった情報を削除してもよい。
　次に、ホスト６０－１１からホスト６０－３へのパケットの流れを説明する。
　ホスト６０－１１はホスト６０－３に向けてパケットを送信する（Ｓ５５）。
　ＣＰＥ５０－１１のフォワーディング部５１が当該パケットを受信すると、ＣＰＥ５０－１１のＲＬＯＣ解決部５２は、当該パケットの宛先アドレスであるＥＩＤ＃３に対応するＲＬＯＣを取得するため、コントローラ３０にＲＬＯＣ解決要求を送信する（Ｓ５６）。ＲＬＯＣ解決要求には、解決したいＥＩＤであるＥＩＤ＝＃３と、ＣＰＥ５０－１１が所属するエリアのＩＤであるエリアＩＤ＝＃２が含まれる。
　コントローラ３０のＣＰＥ問い合わせ部３１は、ＲＬＯＣ解決要求を受信すると、ＲＬＯＣ解決要求に含まれるＥＩＤ（ＥＩＤ＃３）及びエリアＩＤ（＃２）をキーとして、ＥＩＤ－ＲＬＯＣデータベース３３を検索する（Ｓ５７）。ＥＩＤ－ＲＬＯＣデータベース３３（図８）には、ＥＩＤ＝ＥＩＤ＃３、エリアＩＤ＝＃２に該当するＲＬＯＣとして、ＩＰ＃３２（ＣＰＥ５０－３２のＲＬＯＣ）が登録されているため、ＣＰＥ問い合わせ部３１は、ＲＬＯＣ＝ＩＰ＃３２を含むＲＬＯＣ解決応答を送信する（Ｓ５８）。なお、ＣＰＥ５０－１１がＡＲ４０－１配下に接続されていた時には、エリアＩＤ＝＃１であったため、ＲＬＯＣ＝ＩＰ＃３１が返されたが、ＡＲ４０－２配下の場合にはエリアＩＤ＝＃２であるためＲＬＯＣ＝ＩＰ＃３２が返される。この仕組みにより、クラウド側の各ＣＰＥ５０（ＣＰＥ５０－３１やＣＰＥ５０－３２）は、特定のＡＲ４０配下（すなわち、特定のエリア）のＣＰＥ５０からのパケットのみを受信することになる。
　ＣＰＥ５０－１１のＲＬＯＣ解決部５２は、コントローラ３０からＲＬＯＣ解決応答を受信すると、ＥＩＤ＝ＥＩＤ＃３に対応するＲＬＯＣとしてＲＬＯＣ＝ＩＰ＃３２を解決できたため、ルーティングテーブル５４－１１に「宛先＝ＥＩＤ＃３、処理＝Ｅｎｃａｐ（ＩＰ＃３２）」のレコードを登録する（Ｓ５９）。当該レコードは、ＥＩＤ＃３宛てのパケットに対して、宛先アドレスをＩＰ＃３２としたカプセル化を実施し、ＩＰ＃３２（すなわちＣＰＥ５０－３２）に向けて当該パケットを送出することを意味する。
　ルーティングテーブル５４－１１の登録が完了すると、ＣＰＥ５０－１１のフォワーディング部５１は、宛先アドレス＝ＩＰ＃３２でカプセル化したパケットをＣＰＥ５０－３２に向けて送出する（Ｓ６０）。
　ＣＰＥ５０－３２のフォワーディング部５１は、当該パケットを受信すると、ルーティングテーブル５４－３２を参照する（Ｓ６１）。当該パケットについては、図５のルーティングテーブル５４－３２の、「宛先＝ＩＰ＃３２、処理＝Ｄｅｃａｐ－＞Ｌｏｏｋｕｐ」が該当する。これは、ＩＰ＃３２宛てのパケット（すなわち、ＣＰＥ５０－３２自身宛て）を受信したら、デカプセル化して、再度ルーティングテーブル５４－３２を検索する処理を意味する。
　そこで、ＣＰＥ５０－３２のフォワーディング部５１は、当該パケットをデカプセル化して、再度ルーティングテーブル５４－３２を検索する。すると、図５の「宛先＝ＥＩＤ＃３、処理＝Ｄｉｒｅｃｔ」のレコードが該当するため、フォワーディング部５１は、ＥＩＤ＃３（すなわち、ホスト６０－３）にパケットを直接配送する（Ｓ６２）。その結果、ホスト６０－３は、ホスト６０－１１からのパケットを受信する。
　一方、ホスト６０－３からホスト６０－１１へのパケットの流れは、図１３に示されるようになる。
　ステップＳ６４において、ホスト６０－３がホスト６０－１１に向けてパケットを送出する（Ｓ６４）。
　ＣＰＥ５０－３２のフォワーディング部５１は、ホスト６０－３からのパケットを受信すると、ルーティングテーブル５４－３２を参照する（Ｓ６５）。当該パケットには、図５の「宛先＝Ｄｅｆａｕｌｔ、処理＝Ｅｎｃａｐ（ＩＰ＃Ａ２）」が該当するため、フォワーディング部５１は、宛先アドレス＝ＩＰ＃Ａ２（ＡＲ４０－２のＲＬＯＣ）でカプセル化して、当該パケットをＡＲ４０－２宛てに送信する（Ｓ６６）。
　ＡＲ４０－２のフォワーディング部４１は、当該パケットを受信すると、ルーティングテーブル４３－２（図１４参照）を参照する（Ｓ６７）。当該パケットには、図１４のルーティングテーブル４３－２の「宛先＝ＩＰ＃Ａ２、処理＝Ｄｅｃａｐ－＞Ｌｏｏｋｕｐ」のレコードが該当するため、フォワーディング部４１は、当該パケットをデカプセル化して、再度ルーティングテーブルを検索する。デカプセル化されたパケット（元のパケット）の宛先はＥＩＤ＃１１であるため、次の検索では、「宛先＝ＥＩＤ＃１１、処理＝Ｅｎｃａｐ（ＩＰ＃２２）のレコード」が該当する。そのため、フォワーディング部４１は、宛先アドレス＝ＩＰ＃２２で当該パケットをカプセル化して、ＩＰ＃２２宛て、すなわち、ＣＰＥ５０－１１宛てに当該パケットを送信する（Ｓ６８）。
　ＣＰＥ５０－１１のフォワーディング部５１は、ＡＲ４０－２からのパケットを受信すると、ルーティングテーブル５４－１１を参照する（Ｓ６９）。当該パケットには、図１４の移動後のＣＰＥ５０－１１のルーティングテーブル５４－１１の、「宛先＝ＩＰ＃２２、処理＝Ｄｅｃａｐ－＞Ｌｏｏｋｕｐ」が該当するため、フォワーディング部５１は、当該パケットをデカプセル化して、再度ルーティングテーブル５４－１１を検索する。すると、次は、「宛先＝ＥＩＤ＃１１、処理＝Ｄｉｒｅｃｔ」のレコードが該当するため、フォワーディング部５１は、当該パケットをＥＩＤ＃１１、すなわち、ホスト６０－１１に直接配送する（Ｓ７０）。その結果、ホスト６０－１１は、ホスト６０－３からのパケットを受信する。
　このように、ＣＰＥ５０－１１がＡＲ４０－１配下からＡＲ４０－２配下へ移動した場合、ルーティングテーブルに変更があるのは、ＡＲ４０－１、ＡＲ４０－２、ＣＰＥ５０－１１のみであり、クラウド側のＣＰＥ５０－３１やＣＰＥ５０－３２には変更は発生しない。このことは、デバイス１０数の増減や、デバイス１０の移動によって、クラウド側ＣＰＥ５０のルーティングテーブル５４に一切変化はなく、クラウド側ＣＰＥ５０が、ルーティングテーブル量や、ルーティングテーブルを変更するための処理量による影響を受けないことを示している。
　上述したように、本実施の形態によれば、クラウド側のＣＰＥ５０のルーティングテーブルで保持すべき経路数を削減することができる。したがって、ＩＰアドレスが変化するデバイスに関する通信を効率化することができる。
　なお、従来技術では、ＥＩＤ－ＲＬＯＣの対応情報を保持しているデータベースへの問い合わせ（トランザクション）の処理量も問題となる。具体的には、ＥＩＤ－ＲＬＯＣの対応情報を保持しているデータベースへの問い合わせ処理は、デバイスが新たなＥＩＤを持つアプリケーションへの通信を開始するたびに発生する。一度問い合わせた情報をデバイス側でキャッシュすることはできるが、前述のように、データベースで保持しているＥＩＤ－ＲＬＯＣの対応情報は常に更新される。キャッシュを保持する時間を長くすれば、問い合わせを減らすことはできるが、長くしすぎると、キャッシュと最新情報との間に乖離が発生し、デバイスの移動等でＥＩＤ－ＲＬＯＣの対応関係が変更された場合に、正常に通信ができなくなる可能性がある。
　本実施の形態によれば、クラウド側ＣＰＥ５０からコントローラ３０への問い合わせ（ＲＬＯＣ解決要求）を削減する（不要とする）ことで、既存技術におけるボトルネックを解消し、本システムに収容可能なデバイス１０数（ＣＰＥ５０数）を増加させることができる。
　なお、本実施の形態において、デバイス１０は、通信装置の一例である。データセンタ２０は、所定の情報処理装置の一例である。ＡＲ４０は、収容装置の一例である。ＲＬＯＣは、第１のＩＰアドレスの一例である。ＥＩＤは、第２のＩＰアドレスの一例である。ＣＰＥ登録部５３は、登録部の一例である。フォワーディング部５１は、パケット処理部の一例である。ＲＬＯＣ解決部５２は、解決部の一例である。ＣＰＥ５０－３１又はＣＰＥ５０－３２のＲＬＯＣは、第３のＩＰアドレスの一例である。ホスト６０－３のＥＩＤは、第４のＩＰアドレスの一例である。
　以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
１０　　　　　デバイス
２０　　　　　データセンタ
３０　　　　　コントローラ
３１　　　　　ＣＰＥ問い合わせ部
３２　　　　　ＣＰＥ登録・更新部
３３　　　　　ＥＩＤ－ＲＬＯＣデータベース
４０　　　　　ＡＲ
４１　　　　　フォワーディング部
４２　　　　　ＣＰＥ接続部
４３　　　　　ルーティングテーブル
５０　　　　　ＣＰＥ
５１　　　　　フォワーディング部
５２　　　　　ＲＬＯＣ解決部
５３　　　　　ＣＰＥ登録部
５４　　　　　ルーティングテーブル
１００　　　　ドライブ装置
１０１　　　　記録媒体
１０２　　　　補助記憶装置
１０３　　　　メモリ装置
１０４　　　　ＣＰＵ
１０５　　　　インタフェース装置
Ｂ　　　　　　バス
Ｎ１　　　　　コアネットワーク

Claims (7)

  1. 　複数のエリア間を移動し、所定の情報処理装置と通信する通信装置であって、
    　それぞれが前記複数のエリアのうちのいずれか一つのエリアに対応する複数の収容装置のうち、当該通信装置が属するエリアに対応する前記収容装置に対し、当該通信装置の移動によって変更される第１のＩＰアドレスと、前記移動によって変更されない第２のＩＰアドレスとを通知することで、前記所定の情報処理装置からの前記第２のＩＰアドレスを宛先とするパケットを前記第１のＩＰアドレスによってカプセル化して送信させるための情報を当該収容装置に登録させる登録部と、
    　前記第１のＩＰアドレスによってカプセル化されたパケットを前記第２のＩＰアドレスを宛先とするパケットにデカプセル化するパケット処理部と、
    を有することを特徴とする通信装置。
  2. 　前記登録部は、当該通信装置が属するエリアに対応する前記収容装置から当該エリアの識別情報を受信する、
    ことを特徴とする請求項１記載の通信装置。
  3. 　前記所定の情報処理装置は、前記エリアごとの第３のＩＰアドレスと、前記エリアに依存しない第４のＩＰアドレスとを有し、
    　前記通信装置は、
    　当該通信装置からのパケットの宛先に指定された前記第４のＩＰアドレスと当該通信装置が属するエリアとに対応する前記第３のＩＰアドレスを、前記第４のＩＰアドレスと前記エリアとの組み合わせごとに前記第３のＩＰアドレスを記憶するコントローラから取得する解決部を有し、
    　前記パケット処理部は、当該通信装置からのパケットを、前記解決部が取得した前記第３のＩＰアドレスによってカプセル化する、
    ことを特徴とする請求項１又は２記載の通信装置。
  4. 　複数のエリア間を移動し、所定の情報処理装置と通信する通信装置が、
    　それぞれが前記複数のエリアのうちのいずれか一つのエリアに対応する複数の収容装置のうち、当該通信装置が属するエリアに対応する前記収容装置に対し、当該通信装置の移動によって変更される第１のＩＰアドレスと、前記移動によって変更されない第２のＩＰアドレスとを通知することで、前記所定の情報処理装置からの前記第２のＩＰアドレスを宛先とするパケットを前記第１のＩＰアドレスによってカプセル化して送信させるための情報を当該収容装置に登録させる登録手順と、
    　前記第１のＩＰアドレスによってカプセル化されたパケットを前記第２のＩＰアドレスを宛先とするパケットにデカプセル化するパケット処理手順と、
    を実行することを特徴とする通信方法。
  5. 　前記登録手順は、当該通信装置が属するエリアに対応する前記収容装置から当該エリアの識別情報を受信する、
    ことを特徴とする請求項４記載の通信方法。
  6. 　前記所定の情報処理装置は、前記エリアごとの第３のＩＰアドレスと、前記エリアに依存しない第４のＩＰアドレスとを有し、
    　前記通信装置が、
    　当該通信装置からのパケットの宛先に指定された前記第４のＩＰアドレスと当該通信装置が属するエリアとに対応する前記第３のＩＰアドレスを、前記第４のＩＰアドレスと前記エリアとの組み合わせごとに前記第３のＩＰアドレスを記憶するコントローラから取得する解決手順を実行し、
    　前記パケット処理手順は、当該通信装置からのパケットを、前記解決手順が取得した前記第３のＩＰアドレスによってカプセル化する、
    ことを特徴とする請求項４又は５記載の通信方法。
  7. 　請求項４乃至６いずれか一項記載の通信方法を通信装置に実行させることを特徴とするプログラム。
PCT/JP2021/006444 2021-02-19 2021-02-19 通信装置、通信方法及びプログラム WO2022176168A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2021/006444 WO2022176168A1 (ja) 2021-02-19 2021-02-19 通信装置、通信方法及びプログラム
JP2023500468A JPWO2022176168A1 (ja) 2021-02-19 2021-02-19

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/006444 WO2022176168A1 (ja) 2021-02-19 2021-02-19 通信装置、通信方法及びプログラム

Publications (1)

Publication Number Publication Date
WO2022176168A1 true WO2022176168A1 (ja) 2022-08-25

Family

ID=82930400

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/006444 WO2022176168A1 (ja) 2021-02-19 2021-02-19 通信装置、通信方法及びプログラム

Country Status (2)

Country Link
JP (1) JPWO2022176168A1 (ja)
WO (1) WO2022176168A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2775674A1 (en) * 2011-11-01 2014-09-10 ZTE Corporation Method for mobile node to dynamically acquire location identifier, and lisp network
US20160065531A1 (en) * 2014-08-27 2016-03-03 Cisco Technology, Inc. Source-aware technique for facilitating lisp host mobility

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2775674A1 (en) * 2011-11-01 2014-09-10 ZTE Corporation Method for mobile node to dynamically acquire location identifier, and lisp network
US20160065531A1 (en) * 2014-08-27 2016-03-03 Cisco Technology, Inc. Source-aware technique for facilitating lisp host mobility

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MICHAEL MENTH ; DOMINIK KLEIN ; MATTHIAS HARTMANN: "Improvements to LISP Mobile Node", TELETRAFFIC CONGRESS (ITC), 2010 22ND INTERNATIONAL, 7 September 2010 (2010-09-07), Piscataway, NJ, USA , pages 1 - 8, XP031780097, ISBN: 978-1-4244-8837-7 *

Also Published As

Publication number Publication date
JPWO2022176168A1 (ja) 2022-08-25

Similar Documents

Publication Publication Date Title
JP4075318B2 (ja) プロトコル変換方法，及びアドレス変換サーバ
CN100583903C (zh) 利用IPv6移动路由器穿过IPv4网络的布置
JP3688547B2 (ja) 位置識別子管理装置及び移動計算機並びに位置識別子管理方法及び位置識別子処理方法
JP3876741B2 (ja) プロトコル変換方法及び装置
US7639686B2 (en) Access network clusterhead for providing local mobility management of a roaming IPv4 node
TWI449380B (zh) 資料中心網路系統及其封包傳送方法
EP1139632B1 (en) Method for packet communication with mobile node
CN100469038C (zh) 用于隧穿分组的isatap路由器及其方法
JP5966561B2 (ja) 通信装置および通信方法
JP2003258838A (ja) 通信装置およびネットワークシステム
JP2000201183A (ja) デ―タ送信方法
US8547998B2 (en) Tunneling IPv6 packet through IPv4 network using a tunnel entry based on IPv6 prefix and tunneling IPv4 packet using a tunnel entry based on IPv4 prefix
WO2022176168A1 (ja) 通信装置、通信方法及びプログラム
JP3589089B2 (ja) 通信プロトコル代行処理方法、通信プロトコル代行処理装置、及び通信プロトコル代行処理サービス装置
JP3875121B2 (ja) 通信システム、通信方法、転送装置及びネットワーク管理装置
JP3621917B2 (ja) データ中継方法、及びその方法に用いられるデータ中継装置
WO2023100371A1 (ja) 通信装置、通信方法及びプログラム
JP6470640B2 (ja) 通信装置及びその制御方法、コンピュータプログラム
JP7318737B2 (ja) 通信装置、移動通信端末、通信方法、及びプログラム
JP2002094546A (ja) モバイルｉｐにおけるアドレス変換方法
JP4425757B2 (ja) モバイルネットワークシステム
JP6904846B2 (ja) 通信装置、通信装置の制御方法、および、プログラム
JP7215597B2 (ja) 制御装置、通信システム、制御方法、及びプログラム
CN115361328B (zh) 一种身份标识报文寻址和转发方法及相关设备
WO2012083676A1 (zh) 一种提高映射路由表使用效率的方法及系统

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2023500468

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21926601

Country of ref document: EP

Kind code of ref document: A1