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 JP2023500468A priority Critical patent/JPWO2022176168A1/ja
Priority to PCT/JP2021/006444 priority patent/WO2022176168A1/ja
Publication of WO2022176168A1 publication Critical patent/WO2022176168A1/ja

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing
    • H04L45/745Address table lookup; Address filtering
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0011Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0019Control or signalling for completing the hand-off for data sessions of end-to-end connection adapted for mobile IP [MIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/34Modification of an existing route
    • H04W40/36Modification of an existing route due to handover
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing 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/08Mobility data transfer
    • H04W8/087Mobility data transfer for preserving data network PoA address despite hand-offs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/60Types of network addresses
    • H04L2101/695Types of network addresses using masks or ranges of addresses
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/10Mapping addresses of different types
    • H04L61/103Mapping addresses of different types across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5084Providing for device mobility
    • YGENERAL 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
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE 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/00Reducing energy consumption in communication networks
    • Y02D30/70Reducing 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)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

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

Description

通信装置、通信方法及びプログラム
 本発明は、通信装置、通信方法及びプログラムに関する。
 コネクテッドカー等のように、物理的に移動するデバイスをネットワークに接続して、接続性を提供し続けるためには、IPモビリティの機能が必要である。IPモビリティは、デバイスのIPアドレスが変わったとしても、デバイスのアプリケーションが影響を受けずに通信を継続できる機能のことである。
 IPモビリティを実現する技術の代表例としては、LISP(Locator/ID Separation Protocol)がある(非特許文献1)。LISPでは、アプリケーションが通信に利用するIPアドレスをEID(End Point ID)とし、デバイスが外部のネットワークと通信する際に利用するIPアドレスをRLOC(Routing Locator)として定義する。RLOCは、デバイスが接続するネットワークが変更されたり、移動に伴ってIPアドレスの再割り当てがあったりすると変更される。一般的には、RLOCは、デバイスがセルラー網やWi-Fi(登録商標)等に接続した際に払い出されるIPアドレスである。一方、EIDは、常に同じ値である。LISPでは、外部のデータベースで、EID-RLOCの対応関係を保持し、その対応関係を常に最新に保つ。デバイスは、通信先のアプリケーションのEIDをキーとして、RLOCを問い合わせ、宛先のRLOCでIPパケットをカプセル化してネットワークに送信することで、IPモビリティを実現する。
"The Locator/ID Separation Protocol (LISP)"、IETF RFC6830、[online]、<URL:https://tools.ietf.org/html/rfc6830>
 LISPは、LISPに参加する全端末間でIPモビリティを実現することができるが、コネクテッドカーやセンサ等のデバイスからクラウド側にデータを収集するような一般的なIoT(Internet of Things)のユースケースにおいては、デバイス数が増加すると、スケーラビリティが問題になる。例えば、コネクテッドカーでは、デバイス数が数百万~数千万にもなる。
 具体的には、デバイスの通信先のクラウド側のデバイスのルーティングテーブル量(経路数)が問題になる。
 デバイスのルーティングテーブルは、そのデバイスが通信する宛先となるEIDをキーとして、対応するRLOCでカプセル化するための情報が保持されている。或るデバイスが多数のデバイスやアプリケーションと同時に通信する場合、EIDの数に応じてルーティングテーブルの量(経路数)が増えてしまう。例えば、移動するIoTデバイスのセンサ情報を定期的に収集するようなアプリケーションを想定すると、IoTデバイスの通信先はクラウド側のアプリケーションのみであるが、クラウド側のデバイス(デバイス相当の終端装置)は、大量のIoTデバイスと通信する必要がある。センサ情報のような小容量のデータを間欠的に送信するアプリケーションの場合、ネットワーク帯域よりも先に、クラウド側のデバイスのルーティングテーブルの量(経路数)がボトルネックとなる可能性がある。
 本発明は、上記の点に鑑みてなされたものであって、IPアドレスが変化する通信装置に関する通信を効率化することを目的とする。
 そこで上記課題を解決するため、複数のエリア間を移動し、所定の情報処理装置と通信する通信装置は、それぞれが前記複数のエリアのうちのいずれか一つのエリアに対応する複数の収容装置のうち、当該通信装置が属するエリアに対応する前記収容装置に対し、当該通信装置の移動によって変更される第1のIPアドレスと、前記移動によって変更されない第2のIPアドレスとを通知することで、前記所定の情報処理装置からの前記第2のIPアドレスを宛先とするパケットを前記第1のIPアドレスによってカプセル化して送信させるための情報を当該収容装置に登録させる登録部と、前記第1のIPアドレスによってカプセル化されたパケットを前記第2のIPアドレスを宛先とするパケットにデカプセル化するパケット処理部と、を有する。
 IPアドレスが変化する通信装置に関する通信を効率化することができる。
本発明の実施の形態における通信システムの構成例を示す図である。 本発明の実施の形態におけるデバイス10のハードウェア構成例を示す図である。 CPE50の機能構成例を示す図である。 エリア代表ルータ(AR40)の機能構成例を示す図である。 各CPE50のルーティングテーブル54の構成例を示す図である。 エリア代表ルータ(AR40)のルーティングテーブル43の構成例を示す図である。 コントローラ30の機能構成例を示す図である。 EID-RLOCデータベース33の構成例を示す図である。 通信に先立って実行される、デバイス10側CPE50のAR40への接続や、クラウド側CPE50のコントローラ30への登録を説明するためのシーケンス図である。 CPE50-11の配下のホスト60-11からCPE50-31の配下のホスト60-3に向けてパケットが送信される際の処理手順の一例を説明するためのシーケンス図である。 ホスト60-3からホスト60-11への通信の流れを説明するためのシーケンス図である。 CPE50-11が属するエリアが変化した際に実行される処理手順の一例を説明するためのフローチャートである。 CPE50-11が属するエリアが変化した際に実行される処理手順の一例を説明するためのフローチャートである。 CPE50-11が属するエリアが変化した際の各ルーティングテーブルの変化の例を示す図である。
 以下、図面に基づいて本発明の実施の形態を説明する。
 [本実施の形態の概要]
 本実施の形態では、(1)複数のエリア間を移動するデバイス10を収容するエリア代表ルータ(AR40)をエリアごとに設置し、(2)クラウド側の終端装置とエリア代表ルータとを1対1で対応付ける、という構成をとることで課題を解決する。
 (1)に関して、エリア代表ルータは、物理的なエリア毎(例えば、県単位など)に設置され、移動するデバイス10は、通信に先立って、最寄りのエリア代表ルータに接続する。エリア代表ルータは、自身の配下に接続されているデバイス10のEID-RLOCの対応関係をルーティングテーブルとして保持する。なお、EID(End Point ID)とは、IPモビリティを実現する代表的な技術であるLISP(Locator/ID Separation Protocol)において、アプリケーションが通信に利用するIPアドレスをいい、デバイス10の移動に依存しない(デバイス10の移動にともなって変化しない)。一方、RLOC(Routing Locator)とは、LISPにおいて、デバイス10等の端末が外部のネットワークと通信する際に利用するIPアドレスをいい、デバイス10の移動にともなって変化する。
 (2)により、クラウド側の終端装置のルーティングテーブルを削減する。クラウド側の終端装置は、仮想化技術によってVM(Virtual Machine)やコンテナといった形態で実装され、コンピューティングリソースの許す範囲内で、複数立ち上げることができる。そのため、1つのエリア代表ルータに対して、1つの終端装置を設置することが可能となり、終端装置から見ると、通信相手は、対応するエリア代表ルータに限定される。すなわち、クラウド側の終端装置のルーティングテーブルには、対応する1つのエリア代表ルータの情報のみが登録されこととなる。したがって、クラウド側の終端装置は、EID-RLOCの対応関係を保持する必要がないため、データベースへの問い合わせをする必要がなく、データベースの問い合わせ処理量の削減も期待できる。
 [システム構成]
 本実施の形態では、通信先の端末やアプリケーションが保持するIPアドレスをEID(Endpoint ID)とし、各デバイス10やクラウドの拠点(データセンタ20)をコアネットワークN1に接続(収容)するCPE(Customer Premises Equipment)間で、IPパケットをカプセル化して送信する手段としてSRv6(Segment Routing for IPv6)を利用することとする。コアネットワークN1は、IPv6に対応していればよい。ただし、CPE間でカプセル化するプロトコルはSRv6に限定されず、IPパケットをカプセル化できる他の手段によって代用されてもよい。
 図1は、本発明の実施の形態における通信システムの構成例を示す図である。図1において、複数のデバイス10(デバイス10-11、デバイス10-12、デバイス10-21)やデータセンタ20は、終端装置としてのCPE50やホスト60を有し、CPE50を介してコアネットワークN1に接続される。デバイス10内又はデータセンタ内20において、CPE50とホスト60とはデバイス10内又はデータセンタ内20のLANによって接続される。各デバイス10のCPE50は、いずれかのエリアに所属し、そのエリアを管轄するエリア代表ルータであるAR40に対して、SRv6トンネルを介して接続される。また、CPE50からコアネットワークN1を介してアクセスできる場所にコントローラ30が配置される。
 図1には、各装置やホスト60のIPアドレスを示す文字列が括弧内に示されている。"IP"で始まる文字列は、CPE50又はAR40のIPアドレス(RLOC)であり、コアネットワークN1を介して到達性の有るアドレスである。コアネットワークN1を介した通信は、このIPアドレスでカプセル化される。一方、"EID"で始まる文字列は、CPE50配下のLAN内に存在するホスト60やアプリケーションに付与されたIPアドレスである。EIDは固定的に付与され、デバイス10が移動したり、接続するネットワークが変更になったりしても、変化しない(すなわち、デバイス10の位置に依存せしない)。アプリケーションは、常に、このEIDで通信をし続けることができる。
 [デバイス10等のハードウェア構成]
 図2は、本発明の実施の形態におけるデバイス10のハードウェア構成例を示す図である。図2のデバイス10は、それぞれバスBで相互に接続されているドライブ装置100、補助記憶装置102、メモリ装置103、CPU104、及びインタフェース装置105等を有する。
 デバイス10での処理を実現するプログラムは、CD-ROM等の記録媒体101によって提供される。プログラムを記憶した記録媒体101がドライブ装置100にセットされると、プログラムが記録媒体101からドライブ装置100を介して補助記憶装置102にインストールされる。但し、プログラムのインストールは必ずしも記録媒体101より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置102は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
 メモリ装置103は、プログラムの起動指示があった場合に、補助記憶装置102からプログラムを読み出して格納する。CPU104は、メモリ装置103に格納されたプログラムに従ってデバイス10に係る機能を実行する。インタフェース装置105は、ネットワークに接続するためのインタフェースとして用いられる。
 なお、データセンタ20、コントローラ30及びAR40等も、図2と同様のハードウェア構成を有してもよい。
 [各装置の機能構成]
 図3は、CPE50の機能構成例を示す図である。なお、デバイス10側(CPE50-11,12,21)、データセンタ20側(CPE50-31,32)のいずれにおいてCPE50は同じ構成を有する。図3において、CPE50は、フォワーディング部51、RLOC解決部52及びCPE登録部53を有する。これら各部は、デバイス10又はデータセンタ20にインストールされた1以上のプログラムが、デバイス10又はデータセンタ20のCPUに実行させる処理により実現される。CPE50は、また、ルーティングテーブル54を利用する。ルーティングテーブル54は、例えば、デバイス10又はデータセンタ20のメモリ装置又は補助記憶装置等を用いて実現可能である。
 フォワーディング部51は、自CPE50配下のホスト60からデータセンタ20へのパケットをカプセル化してコアネットワークN1へ送出すると共に、データセンタ20等から自CPE50配下のホスト60へのカプセル化されたパケットをコアネットワークN1から受信した際に、当該パケットをデカプセル化して、デカプセル化されたパケットをホスト60へ配送する。本実施の形態では、カプセル化プロトコルとしてSRv6が利用されるため、CPE50のフォワーディング部51はSRv6のカプセル化、デカプセル化を実行することになる。
 ルーティングテーブル54は、パケットの転送、パケットのカプセル化、パケットのデカプセル化をフォワーディング部51が実行する際に必要な経路表を保持する記憶部である。ルーティングテーブル54の具体例は後述する。
 RLOC解決部52は、フォワーディング部51がパケットを送出する際に、宛先EIDに対応するRLOCがルーティングテーブル54に登録されていなかった場合に、宛先EIDに対応するRLOCを解決する。具体的には、RLOC解決部52は、コントローラ30に対して、宛先EIDに対応するRLOCを問い合わせ、その応答としてRLOCを取得したら、ルーティングテーブル54に宛先EID-RLOCの対応関係(当該宛先EIDと当該RLOCとの対応情報)を登録する。
 CPE登録部53は、CPE50が起動された際に、予め指定されたエリア代表ルータ(AR40)に対して、CPE50自身のIPアドレス(RLOC)と配下のEIDを通知する。CPE登録部53は、また、RLOC及びEIDの通知に対する応答として、エリアIDをAR40から受け取るとともに、ルーティングテーブル54に対して、AR40からのカプセル化されたパケットを受け取れるようにする(デカプセル化できるようにする)ための情報を登録する。なお、エリアIDとは、エリアの識別情報である。
 図4は、エリア代表ルータ(AR40)の機能構成例を示す図である。図4において、AR40は、フォワーディング部41及びCPE接続部42を有する。これら各部は、AR40にインストールされた1以上のプログラムが、AR40のCPUに実行させる処理により実現される。AR40は、また、ルーティングテーブル43を利用する。ルーティングテーブル43は、例えば、AR40のメモリ装置又は補助記憶装置等を用いて実現可能である。
 フォワーディング部41は、データセンタ20からのパケットをデカプセル化して、元のIPパケットの宛先EID(宛先CPE50配下のEID)をキーとしてルーティングテーブル43を検索し、宛先EIDに対応するCPE50のRLOCを取得する。その後、フォワーディング部41は、当該RLOCで元のパケットを再カプセル化して、再カプセル化されたパケットを宛先CPE50に送信する。なお、AR40は、デバイス10側CPE50→クラウド側CPE50方向の通信には関与しなくてよいが、通常のルータとして、SRv6等でカプセル化されたIPv6パケットを転送する役割を担ってもよい。この場合、フォワーディング部41は、標準的なIPv6の転送機能を有することになる。
 CPE接続部42は、CPE50からの接続要求を受信した際に、CPE50を接続するための処理を実行する。具体的には、CPE接続部42は、CPE50からの接続要求に含まれるCPE50のIPアドレス(RLOC)とEIDを受け取り、自AR40のルーティングテーブル43に、CPE50のEIDに対して、対応するRLOCでカプセル化して送出するための経路情報を登録する。その後、CPE接続部42は、接続応答として、自AR40が管轄するエリアのエリアIDをCPE50に通知する。これにより、フォワーディング部41が、クラウド側から送信されてきたパケットを、宛先となるCPE50に配送することができるようになる。
 ルーティングテーブル43は、フォワーディング部41がパケットの転送、パケットのカプセル化、パケットのデカプセル化を実行する際に必要な経路表を保持する記憶部である。ルーティングテーブル43の具体例は後述する。
 図5は、各CPE50のルーティングテーブル54の構成例を示す図である。図5には、図1のネットワーク構成例の場合の具体的なルーティングテーブル54の例が示されている。
 CPE50のルーティングテーブル54は、宛先アドレス(宛先プレフィックス)と対応する処理内容から構成される。フォワーディング部51は、受信したIPパケットの宛先アドレスをキーとしてルーティングテーブル54を検索して、そのレコードに記載された処理を実施する。CPE50-11のルーティングテーブル54-11の例に基づいて、具体的に説明する。
 「宛先=EID#3、処理=Encap(IP#31)」というレコードは、デバイス10側のCPE50-11が、クラウド側のCPE50-31(RLOC:IP#31)へと通信する際に利用するものである。宛先欄にある「EID#3」は、クラウド側のホスト60やアプリケーションが利用するアドレスであり、CPE50-11が受信したパケットの宛先アドレスがこれに該当する場合には、フォワーディング部51は、「Encap(IP#31)」の処理を実行する。「Encap(IP#31)」は、宛先IPアドレスをIP#31として、SRv6でカプセル化して送出するという意味を示す。すなわち、CPE50-11が配下のホスト60から受信したパケットを、フォワーディング部51は、コアネットワークN1内に到達性のあるCPE50-31のRLOCであるIP#31でカプセル化して送出することになる。デバイス10側のCPE50のルーティングテーブル54は、通信する先のクラウド側のホスト60毎に、このようなレコードを保持する。
 「宛先=IP#11、処理=Decap->Lookup」というレコードは、宛先IPアドレスが「IP#11」の場合、そのパケットをデカプセル化(Decap)して、再度、ルーティングテーブル54-11を検索する(Lookup)という意味を示す。IP#11は、CPE50-11のIPアドレス(RLOC)であるため、このレコードは、「自分宛ての(カプセル化された)パケットに対して、デカプセル化して、ルーティングテーブル54-11を再検索する」という処理を示す。
 「宛先=EID#11、処理=Direct」というレコードは、IPパケットの宛先アドレスが「EID#11」の場合には、直接配送する、という意味を示す。直接配送とは、同一LAN内に宛先アドレスが存在し、宛先に対して直接IPパケットを送出するという意味である。このレコードは、前述の「宛先=IP#11、処理=Decap->Lookup」の結果、ルーティングテーブル54-11を再検索したときに、宛先が自身の配下のホスト60である場合に、直接配送できるようにするためのものである。
 CPE50-21のルーティングテーブル54-21は、CPE50-11のルーティングテーブル54-11とほぼ同様であるが、CPE50-21はエリア2に属するため、クラウド側において対応するCPE50がCPE50-32である。そのため、1レコード目の処理が「Encap(IP#32)」となっている。また、CPE50-21のRLOCがIP#21であり、配下のEIDがEID#21であるため、ルーティングテーブル54-21の3~4レコード目の「宛先」がCPE50-11のルーティングテーブル54-11と異なる。
 CPE50-31及びCPE50-32はクラウド側のCPE50である。これらのルーティングテーブル54も基本的にはデバイス10側のCPE50と同じである。
 CPE50-31のルーティングテーブル54-31の1レコード目の、「宛先=Default、処理=Encap(IP#A1)」は、他のレコードの宛先に当てはまらないパケットは、カプセル化してIP#A1、すなわち、エリア代表ルータAR40-1に送信するという意味を示す。本実施の形態では、クラウド側にはエリアごとに対応するCPE50が存在し、そのクラウド側CPE50からデバイス10側のCPE50へのパケットは、全て当該クラウド側CPE50が対応するエリアのエリア代表ルータ(この場合はAR40-1)に送信することになっている。このレコードは、その役割を果たすものであり、この1レコードのみで、クラウド側→デバイス10側の全ての通信に対応できる。CPE50-32のルーティングテーブル54-32の1レコード目も同様であるが、CPE50-32はエリア2に対応するエリア代表ルータAR40-2に送信することになるため、処理が「Encap(IP#A2)」となっている。
 CPE50-31又はCPE50-32のルーティングテーブル54の2~3レコード目は、デバイス10側→クラウド側のパケットを処理するレコードであり、宛先が自分であればデカプセル化し(「宛先=IP#31、処理=Decap->Lookup」のレコード)、直接宛先のホスト60へ配送する(「宛先=EID#3、処理=Direct」)ことを示す。
 図6は、エリア代表ルータ(AR40)のルーティングテーブル43の構成例を示す図である。AR40-1のルーティングテーブル43-1を例に、具体的に説明する。
 1レコード目((1)の行)の「宛先=IP#A1、処理=Decap->Lookup」は、クラウド側のCPE50から送信されてきた自分宛て(IP#A1宛て)のパケットを受信したらデカプセル化して、再度ルーティングテーブル43を検索する、という意味を示す。
 2レコード目の「宛先=EID#11、処理=Encap(IP#11)」は、宛先がEID#11、すなわち、CPE50-11配下のEIDである場合には、CPE50-11のRLOCであるIP#11でカプセル化して送出する、という意味を示す。3レコード目も同様に、CPE50-12配下のEID(IP#12)宛てのパケットを、CPE50-12のRLOCであるIP#12でカプセル化して送出するという意味を示す。これらの処理((2)の行の処理)は、1レコード目((2)の行)の処理の結果、デカプセル化されたパケットに対して実施される。AR40-2のルーティングテーブル43-2も同様である。
 図7は、コントローラ30の機能構成例を示す図である。図7において、コントローラ30は、CPE問い合わせ部31及びCPE登録・更新部32を有する。これら各部は、コントローラ30にインストールされた1以上のプログラムが、コントローラ30のCPUに実行させる処理により実現される。コントローラ30は、また、EID-RLOCデータベース33を利用する。EID-RLOCデータベース33、例えば、コントローラ30のメモリ装置又は補助記憶装置等を用いて実現可能である。
 EID-RLOCデータベース33は、CPE50配下に割り当てられているEIDと、そのCPE50に現在割り当てられているRLOCとの対応関係を記憶する記憶部である。本実施の形態では、クラウド側CPE50のEIDとRLOCとの対応関係だけがEID-RLOCデータベース33に登録されている。EID-RLOCデータベース33の構成は後述する。
 CPE問い合わせ部31は、CPE50からの、EIDに対応するRLOCの問い合わせに対して、EID-RLOCデータベース33を検索して、当該EIDに対応するRLOCを応答する。EID-RLOCデータベース33の各エントリにはエリアIDが登録されており、CPE問い合わせ部31は、問い合わせ元のCPE50が所属するエリアのRLOCを返答する。
 CPE登録・更新部32は、EID-RLOCデータベース33に登録されているEID-RLOCの対応関係の新規登録や更新を実行する。具体的には、CPE登録・更新部32は、CPE50が新たにネットワーク接続された場合に、新規にEID-RLOCデータベース33にレコードを追加したり、CPE50が移動してRLOCが変更になった場合に、既存のEID-RLOCの対応関係を変更したりする。
 図8は、EID-RLOCデータベース33の構成例を示す図である。EID-RLOCデータベース33は、各CPE50のEIDとRLOCの対応関係に加えて、各CPE50が所属する(各CPE50に対応する)エリアのエリアIDも保持する。換言すれば、EID-RLOCデータベース33は、各CPE50のEIDとエリアIDとの組み合わせごとにRLOCを記憶する。図8には、図1に対応したEID-RLOCデータベース33の例が示されている。前述の通り、本実施の形態において、EID-RLOCデータベース33には、クラウド側のCPE50の情報だけが保持されるため、図8のEID-RLOCデータベース33は、CPE50-31の情報(1レコード目)、CPE50-32の情報(2レコード目)のみを保持する。なお、デバイス10側のCPE50(図1のCPE50-11、CPE50-12、CPE50-21)のEID-RLOCの対応関係は、エリア代表ルータAR40のルーティングテーブル43(図6)に保持される。
 [処理手順]
 以下、図1の通信システムにおいて実行される処理手順について説明する。図9は、通信に先立って実行される、デバイス10側CPE50のAR40への接続や、クラウド側CPE50のコントローラ30への登録を説明するためのシーケンス図である。
 まず、デバイス10側CPE50(CPE50-11)がAR40に接続する際の処理手順を説明する。
 CPE50-11がネットワークに接続されIPアドレス(RLOC)を付与されると、CPE50-11のCPE登録部53は、最寄り(CPE50-11が属するエリア)のAR40(この場合はAR40-1)にCPE接続要求を送信する(S11)。CPE接続要求には、CPE50-11の配下に割り当てられているEID(EID#11)と、ネットワークから付与されたRLOC(IP#11)とが含まれる。なお、CPE50-11のRLOCは、CPE50-11が接続されるネットワークから払い出されるグローバルIPアドレス等である。また、CPE50配下のEIDは、予めCPE50に設定されているものとする。
 AR40-1のCPE接続部42は、CPE50-11からのCPE接続要求を受信すると、AR40-1のルーティングテーブル43-1に、AR40-1からCPE50-11へのパケット転送に必要な情報を登録する(S12)。この場合、「宛先=EID#11、処理=Encap(IP#11)」という情報が登録される(図6参照)。これは、AR40-1が、宛先IPアドレスがEID#11のパケット、すなわち、CPE50-11配下のホスト60宛てのパケットを受信したら、宛先アドレス=IP#11、すなわち、CPE50-11のRLOCのIPアドレスでカプセル化をして送信する、という意味を示す。
 続いて、AR40-1のCPE接続部42は、CPE接続応答(接続=OK、エリアID=#1)をCPE50-11へ送信する(S13)。CPE50-11のCPE登録部53が当該CPE接続応答を受信することで、CPE50-11は、自身が所属するエリアIDが#1であることを認識する。
 次に、クラウド側のCPE50(CPE50-31)の情報をコントローラ30に登録する際の処理手順を説明する。
 クラウド側のCPE50(CPE50-31)の起動後に、CPE50-31のCPE登録部53は、CPE登録要求をコントローラ30へ送信する(S21)。CPE登録要求には、CPE50-31配下のEID(EID#3)と、CPE50-31のRLOC(IP#31)、CPE50-31が担当するエリアのエリアID(#1)が含まれる。なお、CPE50-31のRLOCも、CPE50-11のRLOCと同様にグローバルIPアドレスが想定される。クラウド環境におけるIPアドレスの払い出しについては様々な方法が想定されるが、本実施の形態では払い出しの方法には依存しない。結果的にCPE50-31に外部から到達可能なグローバルIPアドレスが付与されればよい。
 コントローラ30のCPE登録・更新部32は、CPE登録要求を受信すると、CPE登録要求に含まれている情報を自身のEID-RLOCデータベース33に登録(記憶)する(S22)。この場合、「EID=EID#3、RLOC=IP#31、エリアID=#1」というレコードがEID-RLOCデータベース33に登録される(図8参照)。続いて、CPE登録・更新部32は、CPE登録応答(登録=OK)をCPE50-31へ送信する(S23)。
 図10は、CPE50-11の配下のホスト60-11からCPE50-31の配下のホスト60-3に向けてパケットが送信される際の処理手順の一例を説明するためのシーケンス図である。
 ホスト60-11は、ホスト60-3に向けてパケットを送信する(S31)。ホスト60-11は、自身のEIDであるEID#11を自身のIPアドレスと認識してパケットの送信元アドレス(図10ではSAと表記)に付与し、ホスト60-3のEID#3をホスト60-3のIPアドレスと認識してパケットの宛先アドレス(図10ではDAと表記)に付与する。つまり、ホスト60-11やホスト60-3は、EIDをそのままIPアドレスとして認識して動作する。そのため、通常のIPホストとして動作すればよく、本実施の形態に特有の機能は不要となる。
 CPE50-11のフォワーディング部51が、ホスト60-11からのパケットを受信すると、ルーティングテーブル54-11に当該パケットの宛先EIDが記載されていないため、RLOC解決部52は、コントローラ30に対してRLOC解決要求を送信する(S32)。RLOC解決要求には、ホスト60-11から受信したパケットの宛先アドレスであるEID#3と、CPE50-11自身が所属するエリアIDである#1が含まれる。
 コントローラ30のCPE問い合わせ部31は、CPE50-11からのRLOC解決要求を受信すると、当該RLOC解決要求に含まれているEID=EID#3、エリアID=#1をキーとしてEID-RLOCデータベース33を検索する(S33)。検索した結果、EID=EID#3、エリアID=#1に該当するRLOCは、CPE50-31のRLOCであるIP#31であることがわかる。なお、このレコードは、S21~S23においてCPE50-31がコントローラ30に対して登録したものである。
 続いて、CPE問い合わせ部31は、CPE50-11のRLOC解決部52に対してRLOC解決応答(RLOC=IP#31)を送信する(S34)。
 CPE50-11のRLOC解決部52は、当該RLOC解決応答を受信すると、CPE50-11のルーティングテーブル54-11に、「宛先=EID#3、処理=Encap(IP#31)」を登録する(S35)(図5のルーティングテーブル54-11参照)。これは、宛先アドレスがEID#3のパケットを受信したら、(EID#3はCPE50-31配下に存在し、CPE50-31のRLOCがIP#31であるため)宛先=IP#31でカプセル化して送信することを示す。
 続いて、CPE50-11のフォワーディング部51はルーティングテーブル54-11を参照して、ホスト60-11から受信したパケットを、宛先アドレス=IP#31、送信元アドレス=IP#11(CPE50-11自身のRLOC)でカプセル化し、CPE50-31に向けて送信する(S36)。
 CPE50-31のフォワーディング部51は、CPE50-11からのパケットを受信すると、ルーティングテーブル54-31(図5参照)に基づいて当該パケットを処理する。ここで、当該パケット(カプセル化されたパケット)は、宛先アドレス=IP#31であるため、フォワーディング部51は、該当する処理=Decap->Lookupを実行する。すなわち、フォワーディング部51は、当該パケットをデカプセル化したうえで、ルーティングテーブル54-31を再検索する(S37)。再検索する際のパケット(デカプセル化されたパケット)の宛先アドレスはEID#3であるため、該当する処理=Directとなり、フォワーディング部51は、当該パケットをEID#3のホスト60へ直接配送する(S38)。その結果、ホスト60-3がCPE50-31から当該パケットを受信する。
 図11は、ホスト60-3からホスト60-11への通信の流れを説明するためのシーケンス図である。
 ステップS41において、ホスト60-3がホスト60-11に向けてパケット(以下、「対象パケット」という。)を送信する(S41)。この際、対象パケットの宛先アドレスはホスト60-11のEIDであるEID#11にセットされ、対象パケットの送信元アドレスはホスト60-3のEIDであるEID#3にセットされる。
 なお、ホスト60-3が対象パケットを送信する先(次ホップ)としては、CPE50-31及びCPE50-32が候補として挙げられるが、これらのうちのいずれかを選択する方法はいくつか考えられる。ホスト60-3がホスト60-11からのパケットをCPE50-31から受信したため、その応答(リプライ)となる対象パケットをCPE50-31へ送信するようにしてもよいし、CPE50-31→ホスト60-3にパケットを送信する際にCPE50-31のフォワーディング部51がSNAT(Source NAT)を実施して当該パケットの送信元アドレスをCPE50-31に変更してもよい。後者の場合、ホスト60-3はCPE50-31からパケットを受信したと判断するため、その応答となる対象パケットの宛先アドレスはCPE50-31宛てとなるが、CPE50-31においてSNATにより当該宛先アドレスが元のアドレス(ホスト60-11のアドレスであるEID#11)に変換される。
 CPE50-31のフォワーディング部51は、ホスト60-3から対象パケットを受信すると、ルーティングテーブル54-31を参照する(S42)。ルーティングテーブル54-31(図5参照)には、宛先=EID#11にマッチする具体的なレコードは存在しないため、宛先=Defaultにマッチすることになる。宛先=Defaultの処理はEncap(IP#A1)であるため、フォワーディング部51は、対象パケットを宛先=IP#A1でカプセル化して、AR40-1(エリア#1のエリア代表ルータ)に送信する(S43)。この宛先=Defaultのレコードにより、CPE50-31がクラウド側のホスト60から受信したパケットの全てをエリア1のエリア代表ルータであるAR40-1にカプセル化して送信することになり、CPE50-31では、デバイス10側のCPE50の個別の経路情報を保持する必要がなくなる。
 AR40-1のフォワーディング部41は、CPE50-31からカプセル化された対象パケットを受信すると、ルーティングテーブル43-1(図6参照)を参照する(S44)。カプセル化された対象パケットの宛先アドレスはAR40-1自身のRLOCであるIP#A1であるため、ルーティングテーブル43-1の「宛先=IP#A1、処理=Decap->Lookup」のレコードが対象パケットに対応する。そこで、フォワーディング部41は、対象パケットをデカプセル化して、再度、ルーティングテーブル43-1を再検索する。デカプセル化されたパケットの宛先アドレスはEID#11であるため、ルーティングテーブル43-1では、「宛先=EID#11、処理=Encap(IP#11)」に該当する。したがって、フォワーディング部41は、対象パケットの宛先アドレスをIP#11にセットしてカプセル化をしたうえで、対象パケットをCPE50-11(RLOC=IP#11)に向けて送信する(S45)。
 CPE50-11のフォワーディング部51は、AR40-1からカプセル化された対象パケットを受信すると、ルーティングテーブル54-11を参照する(S46)。具体的には、フォワーディング部51は、対象パケットの宛先アドレス=IP#11(CPE50-11のRLOC、つまり、自分宛て)をキーとしてCPE50-11のルーティングテーブル54-11を検索する。すると、「宛先=IP#11、処理=Decap->Lookup」のレコードが該当するため、フォワーディング部51は、対象パケットをデカプセル化して、ルーティングテーブル54-11を再検索する。デカプセル化された対象パケットの宛先アドレスはEID#11であるため、「宛先=EID#11、処理=Direct」のレコードに該当する。そこで、フォワーディング部51は、EID#11宛て、すなわち、ホスト60-11宛てに対象パケットを直接配送する(S47)。その結果、ホスト60-11は対象パケットを受信する。
 次に、図12~図14を用いて、CPE50-11が、AR40-1配下からAR40-2配下へ移動した際に実行される処理手順について説明する。図12及び図13はシーケンス図を示し、図14はCPE50-11のルーティングテーブルの変化と、AR40-1、AR40-2のルーティングテーブルを示す図である。
 CPE50-11(CPE50-11を有するデバイス10-11)がAR40-1配下からAR40-2配下へ移動すると、CPE50-11は、アクセス網に再接続する形になるため、ネットワークから払い出されるIPアドレス、すなわち、CPE50-11のRLOCが変更になる(S51)。この例では、CPE50-11のRLOCがIP#11からIP#22に変更になったと仮定する。そのため、CPE50-11のCPE登録部53は、CPE50-11のルーティングテーブル54-11において、「宛先=IP#11、処理=Decap->Lookup」のレコードを、「宛先=IP#22、処理=Decap->Lookup」に変更する(図14参照)。なお、このレコードは、AR40からCPE50-11宛てにパケットが送信されてきた場合、自分宛て(CPE50-11のRLOC宛て)であれば、デカプセル化してルーティングテーブル54-11を再検索する、という処理を行うためのものである。
 CPE50-11がネットワークに接続されたら、CPE登録部53は、最寄りのAR40(この場合、AR40-2)に対して、CPE接続要求を送信する(S52)。CPE接続要求には、EID=EID#11、RLOC=IP#22が含まれる。EIDは移動前から変更は無いが、RLOCは前述のように、新たに払い出されたIPアドレスであるIP#22となる。
 AR40-2のCPE接続部42は、CPE50-11からのCPE接続要求を受信すると、CPE50-11へパケットを送信するためのレコードをルーティングテーブル43-2へ登録する(S53)。具体的には、CPE接続部42は、図14のAR40-2のルーティングテーブル43-2に対し、「宛先=EID#11、処理=Encap(IP#22)」というレコードを登録する。これは、宛先アドレスがCPE50-11配下のEID#11宛てのパケットであれば、CPE50-11の新たなRLOCであるIP#22でカプセル化して当該パケットを送信する、という処理を示す。
 AR40-2のCPE接続部42は、正常にルーティングテーブル43-2への登録ができたら、CPE50-11へCPE登録応答を送信する(S54)。CPE登録応答には、AR40-2が所属するエリアIDとして、エリアID=#2が含まれる。
 以上で、CPE50-11がAR40-1からAR40-2の配下へ移動した際の接続手続きが完了する。
 なお、AR40-1のルーティングテーブル43-1に登録されていたCPE50-11移動前の情報(宛先=EID#11、処理=Encap(IP#11))は、今後不要となるためにCPE50-11のCPE接続部42が削除する。削除する方法としては、CPE50-11へのパケットが到着しない状態が一定時間継続したらタイムアウト(一定時間、ルーティングテーブル43-1の特定のエントリが参照されなかったら削除する)してもよいし、CPE50-11又はAR40-2等からAR40-1に対してCPE50-11の移動が完了したことを明示的に通知して、CPE50-11のCPE接続部42が、AR40-1のルーティングテーブル43-1において不要になった情報を削除してもよい。
 次に、ホスト60-11からホスト60-3へのパケットの流れを説明する。
 ホスト60-11はホスト60-3に向けてパケットを送信する(S55)。
 CPE50-11のフォワーディング部51が当該パケットを受信すると、CPE50-11のRLOC解決部52は、当該パケットの宛先アドレスであるEID#3に対応するRLOCを取得するため、コントローラ30にRLOC解決要求を送信する(S56)。RLOC解決要求には、解決したいEIDであるEID=#3と、CPE50-11が所属するエリアのIDであるエリアID=#2が含まれる。
 コントローラ30のCPE問い合わせ部31は、RLOC解決要求を受信すると、RLOC解決要求に含まれるEID(EID#3)及びエリアID(#2)をキーとして、EID-RLOCデータベース33を検索する(S57)。EID-RLOCデータベース33(図8)には、EID=EID#3、エリアID=#2に該当するRLOCとして、IP#32(CPE50-32のRLOC)が登録されているため、CPE問い合わせ部31は、RLOC=IP#32を含むRLOC解決応答を送信する(S58)。なお、CPE50-11がAR40-1配下に接続されていた時には、エリアID=#1であったため、RLOC=IP#31が返されたが、AR40-2配下の場合にはエリアID=#2であるためRLOC=IP#32が返される。この仕組みにより、クラウド側の各CPE50(CPE50-31やCPE50-32)は、特定のAR40配下(すなわち、特定のエリア)のCPE50からのパケットのみを受信することになる。
 CPE50-11のRLOC解決部52は、コントローラ30からRLOC解決応答を受信すると、EID=EID#3に対応するRLOCとしてRLOC=IP#32を解決できたため、ルーティングテーブル54-11に「宛先=EID#3、処理=Encap(IP#32)」のレコードを登録する(S59)。当該レコードは、EID#3宛てのパケットに対して、宛先アドレスをIP#32としたカプセル化を実施し、IP#32(すなわちCPE50-32)に向けて当該パケットを送出することを意味する。
 ルーティングテーブル54-11の登録が完了すると、CPE50-11のフォワーディング部51は、宛先アドレス=IP#32でカプセル化したパケットをCPE50-32に向けて送出する(S60)。
 CPE50-32のフォワーディング部51は、当該パケットを受信すると、ルーティングテーブル54-32を参照する(S61)。当該パケットについては、図5のルーティングテーブル54-32の、「宛先=IP#32、処理=Decap->Lookup」が該当する。これは、IP#32宛てのパケット(すなわち、CPE50-32自身宛て)を受信したら、デカプセル化して、再度ルーティングテーブル54-32を検索する処理を意味する。
 そこで、CPE50-32のフォワーディング部51は、当該パケットをデカプセル化して、再度ルーティングテーブル54-32を検索する。すると、図5の「宛先=EID#3、処理=Direct」のレコードが該当するため、フォワーディング部51は、EID#3(すなわち、ホスト60-3)にパケットを直接配送する(S62)。その結果、ホスト60-3は、ホスト60-11からのパケットを受信する。
 一方、ホスト60-3からホスト60-11へのパケットの流れは、図13に示されるようになる。
 ステップS64において、ホスト60-3がホスト60-11に向けてパケットを送出する(S64)。
 CPE50-32のフォワーディング部51は、ホスト60-3からのパケットを受信すると、ルーティングテーブル54-32を参照する(S65)。当該パケットには、図5の「宛先=Default、処理=Encap(IP#A2)」が該当するため、フォワーディング部51は、宛先アドレス=IP#A2(AR40-2のRLOC)でカプセル化して、当該パケットをAR40-2宛てに送信する(S66)。
 AR40-2のフォワーディング部41は、当該パケットを受信すると、ルーティングテーブル43-2(図14参照)を参照する(S67)。当該パケットには、図14のルーティングテーブル43-2の「宛先=IP#A2、処理=Decap->Lookup」のレコードが該当するため、フォワーディング部41は、当該パケットをデカプセル化して、再度ルーティングテーブルを検索する。デカプセル化されたパケット(元のパケット)の宛先はEID#11であるため、次の検索では、「宛先=EID#11、処理=Encap(IP#22)のレコード」が該当する。そのため、フォワーディング部41は、宛先アドレス=IP#22で当該パケットをカプセル化して、IP#22宛て、すなわち、CPE50-11宛てに当該パケットを送信する(S68)。
 CPE50-11のフォワーディング部51は、AR40-2からのパケットを受信すると、ルーティングテーブル54-11を参照する(S69)。当該パケットには、図14の移動後のCPE50-11のルーティングテーブル54-11の、「宛先=IP#22、処理=Decap->Lookup」が該当するため、フォワーディング部51は、当該パケットをデカプセル化して、再度ルーティングテーブル54-11を検索する。すると、次は、「宛先=EID#11、処理=Direct」のレコードが該当するため、フォワーディング部51は、当該パケットをEID#11、すなわち、ホスト60-11に直接配送する(S70)。その結果、ホスト60-11は、ホスト60-3からのパケットを受信する。
 このように、CPE50-11がAR40-1配下からAR40-2配下へ移動した場合、ルーティングテーブルに変更があるのは、AR40-1、AR40-2、CPE50-11のみであり、クラウド側のCPE50-31やCPE50-32には変更は発生しない。このことは、デバイス10数の増減や、デバイス10の移動によって、クラウド側CPE50のルーティングテーブル54に一切変化はなく、クラウド側CPE50が、ルーティングテーブル量や、ルーティングテーブルを変更するための処理量による影響を受けないことを示している。
 上述したように、本実施の形態によれば、クラウド側のCPE50のルーティングテーブルで保持すべき経路数を削減することができる。したがって、IPアドレスが変化するデバイスに関する通信を効率化することができる。
 なお、従来技術では、EID-RLOCの対応情報を保持しているデータベースへの問い合わせ(トランザクション)の処理量も問題となる。具体的には、EID-RLOCの対応情報を保持しているデータベースへの問い合わせ処理は、デバイスが新たなEIDを持つアプリケーションへの通信を開始するたびに発生する。一度問い合わせた情報をデバイス側でキャッシュすることはできるが、前述のように、データベースで保持しているEID-RLOCの対応情報は常に更新される。キャッシュを保持する時間を長くすれば、問い合わせを減らすことはできるが、長くしすぎると、キャッシュと最新情報との間に乖離が発生し、デバイスの移動等でEID-RLOCの対応関係が変更された場合に、正常に通信ができなくなる可能性がある。
 本実施の形態によれば、クラウド側CPE50からコントローラ30への問い合わせ(RLOC解決要求)を削減する(不要とする)ことで、既存技術におけるボトルネックを解消し、本システムに収容可能なデバイス10数(CPE50数)を増加させることができる。
 なお、本実施の形態において、デバイス10は、通信装置の一例である。データセンタ20は、所定の情報処理装置の一例である。AR40は、収容装置の一例である。RLOCは、第1のIPアドレスの一例である。EIDは、第2のIPアドレスの一例である。CPE登録部53は、登録部の一例である。フォワーディング部51は、パケット処理部の一例である。RLOC解決部52は、解決部の一例である。CPE50-31又はCPE50-32のRLOCは、第3のIPアドレスの一例である。ホスト60-3のEIDは、第4のIPアドレスの一例である。
 以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
10     デバイス
20     データセンタ
30     コントローラ
31     CPE問い合わせ部
32     CPE登録・更新部
33     EID-RLOCデータベース
40     AR
41     フォワーディング部
42     CPE接続部
43     ルーティングテーブル
50     CPE
51     フォワーディング部
52     RLOC解決部
53     CPE登録部
54     ルーティングテーブル
100    ドライブ装置
101    記録媒体
102    補助記憶装置
103    メモリ装置
104    CPU
105    インタフェース装置
B      バス
N1     コアネットワーク

Claims (7)

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

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2023500468A JPWO2022176168A1 (ja) 2021-02-19 2021-02-19
PCT/JP2021/006444 WO2022176168A1 (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网络的布置
JP3876741B2 (ja) プロトコル変換方法及び装置
EP1126682B1 (en) Position identifier management apparatus and method, and position identifier processing method
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) 通信装置及びその制御方法、コンピュータプログラム
JP2002094546A (ja) モバイルipにおけるアドレス変換方法
JP4425757B2 (ja) モバイルネットワークシステム
JP6904846B2 (ja) 通信装置、通信装置の制御方法、および、プログラム
JP7215597B2 (ja) 制御装置、通信システム、制御方法、及びプログラム
CN115361328B (zh) 一种身份标识报文寻址和转发方法及相关设备
JP7318737B2 (ja) 通信装置、移動通信端末、通信方法、及びプログラム
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