WO2007058228A1 - 通信方法、移動エージェント装置、及びホームエージェント装置 - Google Patents

通信方法、移動エージェント装置、及びホームエージェント装置 Download PDF

Info

Publication number
WO2007058228A1
WO2007058228A1 PCT/JP2006/322804 JP2006322804W WO2007058228A1 WO 2007058228 A1 WO2007058228 A1 WO 2007058228A1 JP 2006322804 W JP2006322804 W JP 2006322804W WO 2007058228 A1 WO2007058228 A1 WO 2007058228A1
Authority
WO
WIPO (PCT)
Prior art keywords
layer
agent device
address
user terminal
frame
Prior art date
Application number
PCT/JP2006/322804
Other languages
English (en)
French (fr)
Inventor
Hiroaki Hata
Nobuaki Futana
Hajime Ishikawa
Original Assignee
Nttpc Communications, Inc.
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 Nttpc Communications, Inc. filed Critical Nttpc Communications, Inc.
Priority to ES06832694T priority Critical patent/ES2428065T3/es
Priority to EP20060832694 priority patent/EP1950918B1/en
Priority to CN2006800429345A priority patent/CN101310487B/zh
Priority to US12/093,962 priority patent/US8717941B2/en
Priority to PL06832694T priority patent/PL1950918T3/pl
Publication of WO2007058228A1 publication Critical patent/WO2007058228A1/ja
Priority to NO20082696A priority patent/NO20082696L/no

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W60/00Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • 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
    • 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/59Network arrangements, protocols or services for addressing or naming using proxies for addressing
    • 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/04Registration at HLR or HSS [Home Subscriber Server]
    • 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/06Registration at serving network Location Register, VLR or user mobility server
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18Service support devices; Network management devices
    • H04W88/182Network node acting on behalf of an other network entity, e.g. proxy

Definitions

  • the present invention relates to a technique for performing communication without changing an IP address before and after movement even when a terminal moves between networks.
  • a FA Form Agent
  • MN Mobile Node
  • HA Home Agent
  • Communication partner terminal CN: Correspondent Node
  • a packet sent to the above-mentioned terminal is routed to the HA, and if the destination address of the packet is registered to itself, the HA is the one of the terminal.
  • the packet taken out from the capsule is transmitted to the terminal using the layer 2 function in the LAN of the visited network.
  • packets that are transmitted by the terminal are captured by the FA and routed to the communication partner terminal.
  • CoA mode when a terminal (MN) is connected to a visited network, the address of the visited network (CoA: Care of Address) is given to the terminal by DHCP or the like.
  • the terminal has a fixed IP address, and the fixed IP address and CoA are registered in the HA. Packets destined for the terminal from the remote terminal are routed to the HA and sent to the terminal using CoA.
  • Non-Patent Document 1 C. E. Perkins, "IP Mobility Support for IPv4," RFC3344, Aug, 2002 Disclosure of Invention
  • the present invention has been made in view of the above points, and an object of the present invention is to provide a technology that enables a terminal to move between networks without providing a special function to the terminal or visited network. To do.
  • the above problem is a communication method in a communication system comprising a user terminal, a mobile agent device connected to the user terminal, and a home agent device connected to a home network of the user terminal,
  • the home agent device registers the layer 3 address of the user terminal and the layer 3 address of the source of the registration request in the address correspondence table in association with the registration request to which the mobile agent device power is also transmitted.
  • the mobile agent device holds the layer 3 address of the user terminal and transmits a packet to the user terminal communication partner terminal, the mobile agent device transmits a layer 2 frame from the user terminal.
  • the source layer 3 address in the layer 3 header in the layer 2 frame is received.
  • the received layer 2 frame is encapsulated and transmitted to the home agent device, and the home agent device decapsulates the encapsulated layer 2 frame and extracts the layer 2 frame.
  • the router accommodating the home network transfers the packet to the communication partner terminal, and transmits the packet to the communication partner terminal power, the user terminal.
  • the home agent device receives the layer 2 frame from the home network, confirms that the destination layer 3 address in the layer 3 header in the layer 2 frame is registered in the address correspondence table, and 3Register in association with the address To the layer 3 address of the source of the registration request
  • the layer 2 frame is encapsulated and transmitted, and the mobile agent device receives the encapsulated layer 2 frame, decapsulates and extracts the layer 2 frame, and transmits the layer 2 frame to the user terminal. It is solved by the communication method.
  • the above problem is a communication method in a communication system including a user terminal, a mobile agent device connected to the user terminal, and a home agent device connected to a home network of the user terminal.
  • the home agent device registers the layer 3 address of the user terminal in association with the layer 3 address of the source of the registration request in the address correspondence table based on the registration request transmitted from the mobile agent device.
  • the mobile agent device retains the layer 3 address of the user terminal and the user terminal power transmits a packet to the communication partner terminal, the mobile agent device also has the user terminal power of layer 2
  • the frame is received, and the source record in the Layer 3 header in the Layer 2 frame is received.
  • the home agent device When decapsulating and extracting the packet, transferring the packet based on the layer 3 header, and transmitting the packet from the communication counterpart terminal to the user terminal, the home agent device receives the packet, Confirm that the destination layer 3 address in the layer 3 header of the packet is registered in the address correspondence table, and the source layer of the registration request registered in association with the destination layer 3 address.
  • the home agent device receives the packet encapsulated, taking out the packet decapsulates also solved by a communication method for a feature to transmit to the user terminal.
  • the home agent device has identification information of a second mobile agent device that should not be connected to the home agent device, and an address of the second home agent device to which the second mobile agent device should connect. Are stored in the address correspondence table, and the home agent device is the second mobile agent device.
  • the redirect response including the address of the second home agent device is transmitted to the second mobile agent device with reference to the address correspondence table.
  • FIG. 1 is a schematic diagram of a system according to an embodiment of the present invention.
  • FIG. 2 is a diagram showing an example of MFA master data.
  • FIG. 3 is a diagram for explaining a normal registration procedure.
  • FIG. 4 is a diagram showing an example of a nodding cache.
  • FIG. 5 is a diagram for explaining a registration procedure including redirection.
  • FIG. 6 is a system configuration diagram of the layer 2 tunneling method.
  • FIG. 7 is a functional configuration diagram of MFA in the layer 2 tunneling method.
  • FIG. 8 is a functional configuration diagram of HA in the layer 2 tunneling method.
  • FIG. 9 is a diagram showing the format of a registration request packet sent to the HA also with MFA power.
  • FIG. 10A is a diagram showing a format of a registration response packet sent to the HA force MFA.
  • FIG. 10B is a diagram showing a format of a registration response packet sent to the HA force MFA.
  • FIG. 11 A diagram showing the format of a frame encapsulation packet (Data) sent by both HA and MFA.
  • FIG. 12 is a diagram for explaining an MFA uplink data transfer procedure in the layer 2 tunneling scheme.
  • FIG. 13 is a diagram for explaining a data transfer procedure in the uplink direction of HA in the layer 2 tunneling method.
  • FIG. 14 is a diagram for explaining a data transfer procedure in the downlink direction of HA in the layer 2 tunneling method.
  • Fig.15 MFA downlink data transfer procedure in layer 2 tunneling method 1
  • FIG. 16 is a system configuration diagram of the layer 3 tunneling method.
  • FIG. 17 is a functional configuration diagram of MFA in the layer 3 tunneling method.
  • FIG. 18 is a functional configuration diagram of HA in the layer 3 tunneling method.
  • FIG. 19 is a diagram for explaining an MFA uplink data transfer procedure in the layer 3 tunneling scheme.
  • FIG. 20 is a diagram for explaining the HA uplink data transfer procedure in the layer 3 tunneling method.
  • FIG. 21 is a diagram for explaining a data transfer procedure in the downlink direction of HA in the layer 3 tunneling method.
  • FIG. 22 is a diagram for explaining a data transfer procedure in the downlink direction of MFA in the layer 3 tunneling method.
  • MFA Mobile Foreign Agent
  • MN Mobile Foreign Agent
  • HA home agent device
  • the MFA has two interfaces, one interface is connected to the visited network, and the other interface is connected to the MN.
  • the IP address of MN is registered in advance in MFA.
  • the home agent device is connected to the home network of the MN. Note that the network address of the home network is the same as the network address of the MN.
  • the MFA to which the MN is connected is connected to the visited network
  • the IP address of the visited network is assigned to the MFA by DHCP or the like.
  • the MFA sends a registration request including its own ID (in this embodiment, the MFA's MAC address is used as the ID) to the HA.
  • the HA that has received the registration request associates the IP address of the registration request transmission source with the IP address of the MN and holds it as a binding cache. Packets destined for the MN to which the CN power is also sent are routed to the HA, and the HA refers to the binding cache and encapsulates and sends the packet to the MFA to which the MN is connected.
  • the MN and MFA are connected by a layer 2 link, and packets addressed to the MN received by the MFA are transmitted to the MN via the layer 2 link.
  • MFA encapsulates the packet and sends it to HA.
  • MFA master data In the HA, the MFA ID and the MN connected under the MFA or the address information of the HA are set in advance. This is called MFA master data.
  • MFA master data Example of MFA master data
  • the MFA with the MAC address 11111111 has the IP address A.A.A.
  • An MFA with a MAC address of 22222222, connected to A's MN, means that it should be connected to an HA with an IP address of B.B.B.B.
  • the MFA When the MFA is connected to the visited network, it creates a tunnel with the HA.
  • the HA Upon receiving the registration request, the HA acquires the IP address of the MN corresponding to the MAC address included in the registration request from the MFA master data, and returns a registration response (REG_RES) including the IP address to the MFA ( Step 2). MFA generates a filter using the IP address.
  • REG_RES registration response
  • the MFA that has received the registration response returns a registration response confirmation (REG.ACK) to the HA (step 3).
  • the HA that has received the registration response confirmation creates an entry in the nodding cache table.
  • the entry in addition to the IP address of the MN, the source IP address and port of the registration request (REG_REQ) packet are recorded as the destination address and destination port, and the destination port of the registration request (REG_REQ) packet is recorded as the source port. Is done.
  • Figure 4 shows an example of a binding cache table. If a Network Address Port Translation (NAPT) device is interposed between the MFA and the HA, the source IP address and port of the registration request (REG_REQ) packet are the IP address of the interface outside the NAPT device.
  • NAPT Network Address Port Translation
  • the port that receives the registration request (REG_REQ) is not determined in advance by the HA, and the MFA does not accept various port numbers until it can receive the registration response (REG_RES). Attempts to send a registration request (REG_R EQ).
  • a registration request (REG_REQ) is periodically sent from the MFA to the HA and used as a keep-alive for the binding cache.
  • HA if a registration request (REG_REQ) is not received for a certain period of time, it times out and the binding cache power deletes the corresponding entry.
  • the IP address of the HA registered in the MFA If it is not the IP address of the HA connected to the MN's home network, the HA1 that received the registration request is stored in the MFA master table in association with the MFA MAC address! Obtain the IP address of HA2 connected to the home network of the MN and return a redirect response including the IP address to the MFA (Step 2). The MFA that receives the redirect response tries again to issue a registration request to HA2 of the IP address included in it (step 3).
  • the HA2 If the destination HA2 of the registration request holds the IP address of the MN corresponding to the MAC address of the MFA in the MFA master table, the HA2 is the correct HA. HA2 returns a registration response (step 4). It also receives a registration confirmation response (Step 5) and generates a binding cache.
  • This method can also be used when dividing an operating HA. Assume that the number of MFAs accommodated in the HA increases and one HA (called HA before split) is split into two. In this case, two new HAs (called HA after division) are prepared in advance.
  • the MFA master table entry in the pre-split HA the MFA entry to be transferred to the post-split HA is rewritten with the post-split HA address.
  • the pre-split HA returns a redirect response that includes the post-split HA IP address in response to a registration request issued from the relocation target MFA. From this, the MFA is connected to the HA after the split.
  • the layer 2 tunneling scheme will be described as a first embodiment, and the layer 3 tunneling scheme will be described as a second embodiment.
  • Figure 6 shows the system configuration of the layer 2 tunneling method.
  • the MFA and HA act as a layer 2 bridge that connects the MN and the home network router, and the MN is connected to the home network router via the layer 2 bridge.
  • the HA is connected to the home network, and the HA operates as a layer 2 switch in the home network.
  • All the Ethernet (registered trademark) frames transmitted from the MN are received by the MFA (for example, the MN side interface of the MFA is set to the promiscuous mode).
  • the MFA determines whether or not the source IP address of the IP header in the received Ethernet (registered trademark) frame is registered, and if it is registered, the Ethernet (registered trademark) frame is displayed with the MIP header.
  • Capsulin Sending data to a specific destination in some cases may be expressed as sending to a tunnel.
  • the decapsulating device becomes the end point of the tunnel.
  • the HA decapsulates the received packet and transmits the obtained Ethernet (registered trademark) frame to the router.
  • the router performs the normal operation based on the layer 3 header and forwards the packet.
  • Router Power All Ethernet (registered trademark) frames sent to the home network are received by the HA.
  • the HA determines whether the destination address of the layer 3 header of the received Ethernet frame is a registered address in the binding cache registered in advance, and if it is a registered address, Ethernet (registered trademark) frame is encapsulated with MIP header and sent to MFA.
  • the MFA performs decapsulation and transmits an Ethernet (registered trademark) frame to the MN.
  • both the HA and MFA unconditionally send a packet with a MIP header (send to the tunnel). Therefore, all MNs on the home network receive the ARP sent from the MN and the router on the home network, and IP communication is possible even if the MN moves between networks together with the MFA.
  • FIG. 7 shows the functional configuration of MFA.
  • the MFA performs a polling processing unit 11 that issues a registration request, an Ethernet (registered trademark) processing unit 12, 13 that performs Ethernet (registered trademark) communication processing, and a UDP / IP communication process. It has a UDPZIP function unit 14 that performs, an upstream communication processing unit 15 that performs upstream communication processing, a downstream communication processing unit 16 that performs downstream communication processing, and various tables 17.
  • MFA may be realized by using a logic circuit V, or may be realized by installing a program for realizing processing of each processing unit in a computer having a CPU, a memory and the like.
  • the program can be installed on CD-ROM or memory. It can also be downloaded via a network.
  • Various tables are stored in a storage device such as a memory.
  • the various tables 17 include an HA setting table and an MN filter table. included.
  • the HA setting table stores the IP address and port number of the HA!
  • the HA setting table is referred to by the polling processing unit 11, and the polling processing unit 11 periodically issues a registration request to the HA set in this table.
  • the IP address of the configuration server is set when the MFA is initially shipped, and when the MFA is used, the appropriate HA IP address is overwritten by the registration redirect response.
  • the port number is set by the registration response (normal registration response).
  • the MN filter table stores the IP address of the MN stored in the registration response packet. Note that the MN's IP address may be stored in advance in the MFA.
  • the MN filter table is referred to by the upstream communication processing unit 15. When the upstream communication processing unit 15 receives the Ethernet (registered trademark) frame, it reads the IP header in the frame and the source IP address is this. If it is registered in the table, the frame is encapsulated with the MIP header and sent to the HA.
  • HA is an Ethernet (registered trademark) processing unit 21, 22, UDPZlP function unit 23, upstream communication processing unit 24, downstream communication processing unit 25, cache management unit 26, MFA master table 27.
  • HA can be realized by installing a program to implement the processing of each processing unit in a computer with CPU, memory, etc.
  • the program can be installed from CD-ROM or memory. It can also be downloaded via the network.
  • Various tables and binding caches are stored in a storage device such as a memory.
  • MFA information is stored in advance by an administrator or the like.
  • This MFA information includes MFA hardware m information (MAC address in this embodiment), IP address, and address type. They are associated. If the address type is MN, the address is the IP address of the MN connected to the corresponding MFA. If the address type is HA, the address indicates the IP address of the HA to which the corresponding MFA should connect.
  • the binding cache 28 is information in which the MN address and the MFA address are associated with each other.
  • the HA When the HA receives a frame from the home network, it reads the destination IP address. And search this binding cache. If the corresponding IP address is found, the registered source port number is encapsulated as the source port for transmission to the registered MFA IP address and port.
  • the nodding cache 28 is automatically updated when a registration response confirmation packet is received.
  • the HA sets the destination address and destination port from the source of the registration response confirmation packet using the address of the MN to which the source MFA of the registration request packet is connected as a key. Also, the destination of this registration response confirmation packet is set as the binding cache port. If the corresponding MFA registration request is not received for a certain period of time, the corresponding entry is deleted as old data.
  • FIG. 9 is a diagram showing the format of a registration request packet sent from the MFA to the HA.
  • Ver is a system version number and is fixed to 2.
  • Type is set to 05h, which indicates a registration request.
  • Length is set to the length of the entire packet including padding.
  • the MPDU is the maximum packet length that instructs the HA to disassemble and assemble (including the capsule header, not including the UDP / IP header). Data larger than this value cannot be sent to the tunnel.
  • Hardware ID is the MAC address set in MFA. If there are multiple interfaces and multiple MAC addresses, set the one with the smallest value.
  • the ProtocolType is used to suggest to the HA whether the tunnel is layer 2 tunneling or layer 3 tunneling.
  • Layer 3 tunneling it is used to specify whether the network address is IPv4 or IPv6.
  • AuthLength is the size of the BasicAuthData field in bytes.
  • BasicAuthData is a character string obtained by encoding the credential set in MFA according to the method specified in RFC2617 basic authentication. Padding sets arbitrary data to freely change the size of this packet. This is a good field.
  • FIG. 10A shows a format of a registration response packet sent from the HA to the MFA.
  • 07h indicating that it is a registration response packet is set in Type.
  • the length of the entire packet including padding is set in Length.
  • the result for the registration request is set in Protocol Type. If this field is OOlOh, registration is approved, and if it is 0020h, it is redirection. Notify address information at the time of registration approval and redirection.
  • AddressType is an address protocol that determines the data length per address. Number of Address specifies the number of addresses stored after that. Specific values of Address Type, protocol, and address length are as shown in Fig. 10B.
  • Figure 11 shows the format of the frame encapsulation packet (Data) sent by both HA and MFA.
  • Type is set to 10h, which indicates Data.
  • Length is set to the total length of this packet.
  • Protocol Type is set to the tunnel method (L2 tunnel, L3 tunnel type) authenticated at the time of registration. If this identifier specifies L2, the data part is an L2 frame including an Ethernet (registered trademark) header. If L3 is specified, an IP datagram including an IP header is obtained.
  • the group ID is non-zero when this packet is a segment after the frame is divided. Only when the GroupID is non-zero, the TotalLength and Offset fields are valid, indicating that long data has been divided and encapsulated.
  • the data pieces with the same GroupID are assembled and sent to the MN and CN.
  • the polling processing unit 11 is activated at regular intervals.
  • the activated polling processing unit 11 reads the HA setting table and sends a registration request to the registered IP address.
  • the destination port number at that time is randomly selected. If there is no response, the Registration requests are sent to the various destination port numbers until a port number is selected and a normal registration response is returned.
  • the downstream communication processing unit 16 When the downstream communication processing unit 16 receives the registration response, if the registration response is a normal response, the destination port number of the registration request at this time is set in the HA setting table. Thereafter, the polling processing unit 11 issues a registration request only to that port number.
  • the normal registration response contains the IP address of the MN, and this information is set in the filter table. Then, a registration response confirmation is returned to the HA.
  • the registration response is a redirect response
  • the polling processing unit 11 performs registration processing for the new HA.
  • the MFA If the MFA does not receive a registration response for a certain period of time, it reverts the HA table IP address to the initial value, assuming that HA has been deleted, and uses the HA port number and filter table.
  • the upstream communication processing unit 24 of the HA When the upstream communication processing unit 24 of the HA receives the registration request from the MFA, it passes the processing to the cache management unit 26.
  • the cache management unit 26 searches the MFA master table using the MFA MAC address included in the registration request as a key, and searches for the corresponding record.
  • the uplink communication processing unit 24 stores the IP address of the MN in the registration response packet, and returns a registration normal response to the MFA.
  • the record type is HA
  • a registration redirect response including the redirect IP address is returned.
  • the uplink communication processing unit 24 of the HA receives the registration response confirmation from the MFA, the processing is handed over to the cache management unit 26.
  • the cache management unit 26 updates the binding cache based on the address information of the registration response confirmation or registration request packet.
  • the uplink communication processing unit of the MFA receives all packets including the Ethernet (registered trademark) header from the interface connected to the MN (Step 1). If the destination address of the received Ethernet (registered trademark) frame is a broadcast address or a multicast address (Yes in step 2), the tunnel transfer operation is started (step 4). Also, when the received Ethernet (registered trademark) frame includes an IP packet and the source IP address is registered in the MN filter table (Yes in step 3), the tunnel transfer operation is started (step 4). Otherwise, do nothing.
  • the MFA refers to the HA configuration table, and if the HA IP address and port number are registered !, the MIP common header is added before the Ethernet frame to be sent. Then, it is registered using UDP and sends a packet to HA.
  • step 11 At the interface that receives packets from the MFA in the HA, all UDP packets for the local IP address are received regardless of the value of the destination port number (step 11).
  • the HA determines whether there is a MIP header after the UDP packet. If there is a MIP header, it determines that the packet is destined for its own HA (Yes in step 12).
  • the HA refers to the MIP header of the packet and determines whether it is a registration-related packet or a user frame storage packet (step 13). If it is a registration-related packet, the packet is transferred to the cache management unit, and the registration process described above is performed.
  • Ethernet (registered trademark) frame extracted in step 14 is a multicast and a PDU power P packet (a multicast in step 15)
  • the destination IP address is extracted. Then, referring to the binding cache, it is checked whether the corresponding IP address is registered (step 16). If the IP address is in the binding cache, The Ethernet frame is re-encapsulated and sent out to the tunnel (step 17).
  • the Ethernet® frame is sent to the home network side, so that the destination MAC address holder (of the home network Received by the router (step 18).
  • step 15 if the destination MAC address of the Ethernet (registered trademark) frame is addressed to the broadcast or multicast address, the HA sends the Ethernet (registered trademark) frame to the home network and stores the nodding cache.
  • the Ethernet frame is re-encapsulated and sent to all the tunnels that are currently open by reference (step 19).
  • the destination IP address, UDP port, and source port number follow the registration of the corresponding entry in the binding cache.
  • broadcast Z multicast frames are received by all nodes connected to the home network regardless of whether they are moving or not. Therefore, mopile IP communication can be realized because the ARP mechanism operates even between mobile MNs.
  • the HA receives all the packets including the Ethernet (registered trademark) header at the interface connected to the home network of the HA (step 21).
  • the received Ethernet (registered trademark) frame is a multicast and the PDU is an IP packet (cast in step 22)
  • the destination IP address is extracted and the corresponding MN is registered by referring to the binding cache. (Step 23). If the IP address is registered in the nodding cache, nothing is done.
  • the Ethernet (registered trademark) frame is encapsulated and sent out to the tunnel (Step 24).
  • the destination IP address, UDP port, and source port number are bindings.
  • the frame is encapsulated for all tunnels registered in the nodding cache. And send it out (step 25).
  • the destination IP address, UDP port, and source port number follow the registration of the corresponding entry in the binding cache.
  • IP address is assigned to an interface connected to the visited network of the MFA by an address assigning function such as DHCP of the visited network. Packets from the HA arrive on this interface.
  • the MFA receives the packet from the HA as a UDP datagram (step 31). Since the datagram contains the MIP header, decapsulation is performed, and the Ethernet® frame is extracted by removing the header (step 32).
  • the decapsulated Ether frame is sent to the interface connected to the MN! (Step 33). If the Ethernet (registered trademark) frame is broadcast or multicast, all MNs connected to that interface will receive it. If the Ethernet (registered trademark) frame is a cast frame, only the MN having the destination MAC address receives the Ethernet (registered trademark) frame.
  • FIG. 16 shows the system configuration of the layer 3 tunneling method.
  • the HA operates as a router (Layer 3 switch).
  • the operation outline of the Layer 3 tunneling method is described below.
  • the interface connected to the MN in the MFA does not have an IP address, and the MFA receives all Ethernet (registered trademark) frames transmitted from the MN.
  • ARP request from MN When the request is sent, the MFA determines whether the source IP address of the ARP request matches the IP address of the MN registered in the filter, and if so, the MFA responds to the ARP. Reply with your own MAC address. In other words, MFA behaves as a proxy ARP.
  • a multicast frame is sent from the MN. If the source IP address is registered in the filter, the MFA deletes the Ethernet (registered trademark) header, encapsulates it from the IP header, and sends it to the HA. The HA decapsulates the frame received from the tunnel and extracts the IP packet. The HA then forwards the IP packet to the appropriate destination based on the IP header. In other words, HA functions as a router.
  • the HA When receiving an IP datagram from the HA force CN or home network, the HA refers to the binding cache and, if the destination IP address is registered, the IP based on the destination address described in the entry. -In-IP encapsulation is performed and the packet is sent to the MFA via the tunnel.
  • the MFA determines if the destination IP address is listed in the filter! And if it matches the address, and if it matches, uses the ARP to obtain the destination MAC address and the Ethernet header And send it to MN as a cast frame.
  • MFA and HA are shown in Figs. 17 and 18, respectively. As shown in FIGS. 17 and 18, the MFA and HA of the first embodiment are different in that each has an ARP processing unit.
  • the MFA MN interface receives an Ethernet (registered trademark) frame addressed to its own MAC address. If it is a broadcast frame, only the ARP request is received (step 41).
  • Ethernet registered trademark
  • the MFA extracts the IP address of the communication request source and collates it with the MN filter table. If it is registered in the filter table (Yes in Step 43), the ARP request has been issued by the MN, so go to Step 44.
  • Step 44 MFA sends a reply with its own MAC address set to Target MAC to MN, even if the requested IP address of ARP request is! / Return it. As a result, MFA can receive the multicast frame generated by MN.
  • step 42 when the MFA receives a multicast frame addressed to its own MAC address, the MFA removes the Ethernet header of the received multicast frame, Confirm that the PDU is an IP datagram. If the IP header power source IP address is registered in the MN filter table! (Yes in step 45), IP datagram is encapsulated and sent to HA using UDP (step 46)
  • the HA Internet-side interface receives two types of IP packets, which are sent from the CN to the home network and encapsulated IP packets sent from the MN through the tunnel.
  • the HA When the HA receives the packet (step 51), it determines whether the packet is a packet for which the tunnel force has been received or a packet for which the CN force has also been transmitted (step 52). Here, if the packet is a UDP datagram addressed to its own IP address and is followed by a MIP header, it is determined that the frame is received from the tunnel force. Other IP datagrams are judged to have also been issued with CN power.
  • the HA determines that the received packet is a packet for which the tunneling power has also been received (step 52 tunnel)
  • the HA removes the MIP header and sets it as a normal IP packet (step 53). If the received packet is an IP packet (CN in step 52), the process proceeds to the next process.
  • the HA refers to the binding cache and checks whether the destination MN is registered! (Step 54). If the address is found in the binding cache, the IP packet is encapsulated Is sent to the specified address and port (step 55). If the destination IP address is not found in the binding cache (No in step 54), the IP packet is transferred according to the IP address (step 56). In other words, if the IP address indicates the home network, the IP packet is sent to the home network side. If the destination of the IP packet is not the home network, it is sent to the CN, so the IP packet is sent to the Internet. (3) Data transfer procedure in the downlink direction of HA
  • the HA receives only the ARP request among the Ethernet (registered trademark) frame and broadcast frame addressed to its own MAC at the MN side interface (step 61).
  • the target IP of the communication request destination is extracted (step 63).
  • the address is the power of its own IP address, or it is checked against the binding cache to determine whether a matching MN is registered (step 64). If the result matches (OK at step 64), go to step 65 to return an ARP reply. If it doesn't match, ⁇ should not return an ARP reply!
  • Step 65 that is, when the IP address of the ARP request is the local IP address (this is when a node connected to the home network attempts to send a packet to the default route HA to connect to the Internet. If it is directed to a moving MN, V, and then HA must receive the packet! / And respond with an ARP reply (step 65).
  • the returned ARP reply stores the MAC address of the interface connected to the HA home network.
  • step 62 if the received Ethernet frame is a multicast frame addressed to its own MAC address (No in step 62), the HA transmits the received multicast frame.
  • the Ethernet header is removed to confirm that the PDU is an IP datagram, and the destination IP address is extracted from the IP header (step 66). If the IP address is registered in the binding cache (Yes in step 67), Put it into a Psel and use UDP to send it to the corresponding MFA (step 68).
  • step 67 if the IP address is not registered in the binding cache, the IP packet is sent to the Internet because it is for the CN (step 69).
  • the interface connected to the visited network of the MFA is assigned a network address using an address assignment function such as DHCP in the visited network.
  • the MFA receives the packet from the HA through this interface (step 71).
  • the received packet is received as a UDP datagram. Since the MIP header is included in the datagram, the IP packet is decapsulated by deleting the header (step 72).
  • the destination IP address included in the IP header is extracted and the MN filter table is referenced. If the address information matches (Yes in step 73), the IP packet is sent to the MN side network using normal ARP processing (step 74).

Landscapes

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

Abstract

 MNと、当該MNに接続されたMFAと、MNのホームネットワークに接続されたHAとを備える通信システムにおいて、HAは、MNのレイヤ3アドレスと登録要求の発信元のレイヤ3アドレスとを対応付けて保持する。MFAは、MNからのレイヤ2フレームをカプセリングしてHAに送信する。HAはデカプセリングしてホームネットワークにフレームを送出する。HAは、ホームネットワークからレイヤ2フレームを受信すると、宛先レイヤ3アドレスが登録されていることを確認し、当該宛先レイヤ3アドレスに対応付けて登録されている登録要求の発信元のレイヤ3アドレスに向けてレイヤ2フレームをカプセリングして送信し、MFAは、カプセリングされたレイヤ2フレームをデカプセリングしてMNに送信する。

Description

明 細 書
通信方法、移動エージェント装置、及びホームエージェント装置 技術分野
[0001] 本発明は、端末がネットワーク間を移動しても、移動前と移動後で IPアドレスを変更 することなく通信を行うための技術に関するものである。
背景技術
[0002] 端末がネットワーク間を移動しても同じ IPアドレスを用いて通信を継続するための従 来技術として、例えば RFC3344で規定されている Mobile IP技術がある。
[0003] RFC3344で規定されて!、る Mobile IPのしくみでは、 Mobile IPをサポートするネットヮ ークに予め FA (Foreign Agent)を設置しておく。端末(MN: Mobile Node)がそのネット ワークに接続されると、 Mobile IPのプロトコルを使って FAを発見し、自身のアドレス情 報を FAに通知する。また、 FAはインターネット上に設置された HA (Home Agent)に対 し、端末が接続されたことを通知し、 HAは端末に関するアドレス情報を登録する。通 信相手端末 (CN: Correspondent Node)力 上記の端末に向けて発信されたパケット は、 HA向けにルーティングされ、 HAはそのパケットの宛先アドレスが自身に登録され て 、る端末のものであればパケットをカプセリングして FAに送信する。 FAではカプセ ルから取り出したパケットを、当該訪問先ネットワークの LANにおけるレイヤ 2機能を 使って端末に送信する。また、端末力も発信されたパケットは FAが捕捉し、通信相手 端末にルーティングされる。
[0004] また、 FAを使わな!/、構成も可能である(これを CoAモードと呼ぶ)。 CoAモードでは、 端末 (MN)が訪問先ネットワークに接続されると、 DHCP等により訪問先ネットワークの アドレス(CoA: Care of Address)が端末に付与される。また、端末は固定の IPアドレス を有しており、その固定の IPアドレスと CoAとを HAに登録する。通信相手端末からの 端末向けのパケットは HAにルーティングされ、 CoAを利用して端末に送信される。 非特許文献 1 : C. E. Perkins, "IP Mobility Support for IPv4," RFC3344, Aug, 2002 発明の開示
発明が解決しょうとする課題 [0005] しかし、上記の従来技術における FAを用いるモードでは、訪問先ネットワークに FA を設置する必要があり、 FAのないネットワークに端末が移動した場合には通信を行う ことができない。また、 FAモードと CoAモードの両方において、端末に Mobile IPの機 能をインストールしておく必要があるため、 Mobile IPの機能をインストールすることが 困難な機器 (例えばコピー機や POSレジスタ)では従来の Mobile IP技術を利用するこ とができな 、と 、う問題がある。
[0006] 本発明は上記の点に鑑みてなされたものであり、端末や訪問先のネットワークに特 別な機能を備えることなく端末のネットワーク間移動を可能とする技術を提供すること を目的とする。
課題を解決するための手段
[0007] 上記の課題は、ユーザ端末と、当該ユーザ端末に接続された移動エージェント装 置と、前記ユーザ端末のホームネットワークに接続されたホームエージェント装置とを 備える通信システムにおける通信方法であって、前記ホームエージェント装置は、前 記移動エージェント装置力も送信される登録要求に基づき、前記ユーザ端末のレイ ャ 3アドレスと前記登録要求の発信元のレイヤ 3アドレスとを対応付けてアドレス対応 表に登録し、前記移動エージェント装置は前記ユーザ端末のレイヤ 3アドレスを保持 し、前記ユーザ端末力 通信相手端末に対してパケットを送信する場合にぉ 、て、 前記移動エージェント装置は、前記ユーザ端末からレイヤ 2フレームを受信し、当該 レイヤ 2フレーム内のレイヤ 3ヘッダにおける発信元レイヤ 3アドレスが登録されている 場合に、受信したレイヤ 2フレームをカプセリングして前記ホームエージェント装置に 送信し、前記ホームエージェント装置は、カプセリングされた前記レイヤ 2フレームを デカプセリングして前記レイヤ 2フレームを取り出し、当該レイヤ 2フレームを前記ホー ムネットワークに送出し、ホームネットワークを収容するルータが前記通信相手端末宛 にパケットを転送し、前記通信相手端末力 前記ユーザ端末に対してパケットを送信 する場合において、前記ホームエージェント装置は、前記ホームネットワークからレイ ャ 2フレームを受信し、当該レイヤ 2フレーム内のレイヤ 3ヘッダにおける宛先レイヤ 3 アドレスが前記アドレス対応表に登録されていることを確認し、当該宛先レイヤ 3アド レスに対応付けて登録されている前記登録要求の発信元のレイヤ 3アドレスに向けて 前記レイヤ 2フレームをカプセリングして送信し、前記移動エージェント装置は、カプ セリングされた前記レイヤ 2フレームを受信し、デカプセリングして当該レイヤ 2フレー ムを取り出し、前記ユーザ端末に送信することを特徴とする通信方法により解決され る。
[0008] また、上記の課題は、ユーザ端末と、当該ユーザ端末に接続された移動エージ ン ト装置と、前記ユーザ端末のホームネットワークに接続されたホームエージェント装置 とを備える通信システムにおける通信方法であって、前記ホームエージェント装置は 、前記移動エージェント装置から送信される登録要求に基づき、前記ユーザ端末の レイヤ 3アドレスと前記登録要求の発信元のレイヤ 3アドレスとを対応付けてアドレス 対応表に登録し、前記移動エージェント装置は前記ユーザ端末のレイヤ 3アドレスを 保持し、前記ユーザ端末力も通信相手端末に対してパケットを送信する場合にぉ ヽ て、前記移動エージェント装置は、前記ユーザ端末力もレイヤ 2フレームを受信し、当 該レイヤ 2フレーム内のレイヤ 3ヘッダにおける発信元レイヤ 3アドレスが登録されて いる場合に、受信したレイヤ 2フレームからレイヤ 2ヘッダを削除したパケットをカプセ リングして前記ホームエージェント装置に送信し、前記ホームエージェント装置は、力 プセリングされた前記パケットをデカプセリングして前記パケットを取り出し、レイヤ 3 ヘッダに基づき当該パケットを転送し、前記通信相手端末から前記ユーザ端末に対 してパケットを送信する場合において、前記ホームエージェント装置は当該パケットを 受信し、当該パケットのレイヤ 3ヘッダにおける宛先レイヤ 3アドレスが前記アドレス対 応表に登録されて ヽることを確認し、当該宛先レイヤ 3アドレスに対応付けて登録さ れている前記登録要求の発信元のレイヤ 3アドレスに向けて前記パケットをカプセリン グして送信し、前記移動エージェント装置は、カプセリングされた前記パケットを受信 し、デカプセリングして当該パケットを取り出し、前記ユーザ端末に送信することを特 徴とする通信方法によっても解決される。
[0009] 前記ホームエージェント装置は、当該ホームエージェント装置に接続されるべきで ない第 2の移動エージェント装置の識別情報と、当該第 2の移動エージェント装置が 接続するべき第 2のホームエージェント装置のアドレスとを対応付けてアドレス対応表 に保持しており、前記ホームエージェント装置は、前記第 2の移動エージェント装置 から送信された登録要求を受信した場合にお!ヽて、前記アドレス対応表を参照して、 前記第 2のホームエージェント装置のアドレスを含むリダイレクト応答を前記第 2の移 動エージェント装置に送信するようにしてもよ 、。
発明の効果
[0010] 本発明によれば、端末や訪問先のネットワークに特別な機能を備えることなく端末 のネットワーク間移動を可能とする技術を実現することが可能となる。
図面の簡単な説明
[0011] [図 1]本発明の実施の形態のシステムの概要図である。
[図 2]MFAマスターデータの例を示す図である。
[図 3]正常な登録手順を説明するための図である。
[図 4]ノインデイングキャッシュの例を示す図である。
[図 5]リダイレクトを含む登録手順を説明するための図である。
[図 6]レイヤ 2トンネリング方式のシステム構成図である。
[図 7]レイヤ 2トンネリング方式における MFAの機能構成図である。
[図 8]レイヤ 2トンネリング方式における HAの機能構成図である。
[図 9]MFA力も HAに対し送出される登録要求パケットのフォーマットを示す図である。
[図 10A]HA力 MFAに対し送出される登録応答パケットのフォーマットを示す図であ る。
[図 10B]HA力 MFAに対し送出される登録応答パケットのフォーマットを示す図であ る。
[図 11]HAと MFAで双方で送りあうフレームカプセリングパケット (Data)のフォーマットを 示す図である。
[図 12]レイヤ 2トンネリング方式における MFAの上り方向のデータ転送手順を説明す るための図である。
[図 13]レイヤ 2トンネリング方式における HAの上り方向のデータ転送手順を説明する ための図である。
[図 14]レイヤ 2トンネリング方式における HAの下り方向のデータ転送手順を説明する ための図である。 [図 15]レイヤ 2トンネリング方式における MFAの下り方向のデータ転送手順を説明す1—
る1た— めの図である。
[図 16]レイヤ 3トンネリング方式のシステム構成図である。
[図 17]レイヤ 3トンネリング方式における MFAの機能構成図である。
[図 18]レイヤ 3トンネリング方式における HAの機能構成図である。
[図 19]レイヤ 3トンネリング方式における MFAの上り方向のデータ転送手順を説明す るための図である。
[図 20]レイヤ 3トンネリング方式における HAの上り方向データ転送手順を説明するた めの図である。
[図 21]レイヤ 3トンネリング方式における HAの下り方向のデータ転送手順を説明する ための図である。
[図 22]レイヤ 3トンネリング方式における MFAの下り方向のデータ転送手順を説明す るための図である。
符号の説明
ポーリング処理部
12, 13 Ethernet (登録商標)処理部
14 UDPZIP機能部
15 上り方向通信処理部
16 下り方向通信処理部
17 各種テーブル
18 ARP処理部
21, 22 Ethernet (登録商標)処理部
23 UDPZIP機能部
24 上り方向通信処理部
25 下り方向通信処理部
26 キャッシュ管理部
27 MFAマスタテーブル
28 バインディングキャッシュ 29 ARP処理部
発明を実施するための最良の形態
[0013] 以下、図面を参照して本発明の実施の形態について説明する。
[0014] (システム概要)
図 1を参照して本実施の形態のシステムの概要を説明する。図 1に示すように本実 施の形態のシステムでは、移動の対象となる端末 (以下、 MNと呼ぶことにする)ととも に移動する移動エージェント装置(以下、 MFA (Mobile Foreign Agent)と呼ぶことに する)を備える。なお、移動エージェント装置は MNに内蔵されていてもよい。また、通 信相手端末 (以下、 CNと呼ぶ)から MN向けに送信されるパケットを MFAに転送する 機能を持つホームエージェント装置(以下、 HAと呼ぶことにする)が備えられる。 MN には特別な機能を一切インストールする必要はない。
[0015] 図 1に示すように、 MFAは 2つのインタフェースを持ち、一方のインタフェースが訪問 先ネットワークに接続され、他方のインタフェースは MNに接続される。 MFAには MNの IPアドレスが事前に登録される。また、ホームエージェント装置は MNのホームネットヮ ークに接続される。なお、ホームネットワークのネットワークアドレスと MNのネットワーク アドレスとは同じである。
[0016] 以下、図 1を参照して動作概要を説明する。 MNが接続された MFAが訪問先のネッ トワークに接続されると、 DHCP等により訪問先ネットワークの IPアドレスが MFAに付与 される。そして、 MFAは自身の ID (本実施の形態では IDとして MFAの MACアドレスを 用いる)を含む登録要求を HAに送信する。
[0017] 登録要求を受信した HAは、登録要求送信元の IPアドレスと MNの IPアドレスとを対 応付けてバインディングキャッシュとして保持する。 CN力も送信された MN向けのパケ ットは HAにルーティングされ、 HAはバインディングキャッシュを参照することにより、 M Nが接続されている MFA宛にパケットをカプセリングして送信する。 MNと MFAとはレイ ャ 2リンクで接続されており、 MFAが受信した MN宛のパケットはレイヤ 2リンクにより M Nに送信される。 MNが CN向けにパケットを送信すると、 MFAはパケットをカプセリング して HAに送信する。
[0018] [登録の手順について] 本発明の適用例としてレイヤ 2トンネリング方式とレイヤ 3トンネリング方式を後に説 明するが、まず、バインディングキャッシュ等の情報の登録手順について説明する。 以下で説明する登録手順はレイヤ 2トンネリング方式とレイヤ 3トンネリング方式とで共 通である。
[0019] HAには MFAの IDと、その配下に接続される MN、もしくは HAのアドレス情報が事前 に設定されている。これを MFAマスターデータと呼ぶ。 MFAマスターデータの例を図
2に示す。図 2の例では、 MACアドレスが 11111111である MFAは IPアドレスが A.A.A.
Aの MNに接続され、 MACアドレスが 22222222の MFAは IPアドレスが B.B.B.Bの HAに 接続されるべきであることを意味して 、る。
[0020] まず、 MFAに適切な HAの IPアドレスが設定されており、 MFAが適切な HAに登録要 求を送信する場合の登録手順について図 3を参照して説明する。
[0021] MFAは訪問先のネットワークに接続されると HAとの間にトンネルを生成するために
、 HAに対して MFAの MACアドレスを含む登録要求(REG_REQ)を発行する(ステップ
D o
[0022] HAは登録要求を受信すると、登録要求に含まれる MACアドレスに対応する MNの I Pアドレスを MFAマスターデータから取得し、その IPアドレスを含む登録応答(REG_RE S)を MFAに返送する(ステップ 2)。 MFAはその IPアドレスを用いてフィルタを生成す る。
[0023] 登録応答を受信した MFAは、登録応答確認 (REG.ACK)を HAに返す (ステップ 3) 。登録応答確認を受信した HAは、ノインデイングキャッシュテーブルにエントリを作 成する。そのエントリには、 MNの IPアドレスに加え、登録要求(REG_REQ)パケットの 発信元 IPアドレス、ポートが着アドレス、着ポートとして記録され、登録要求(REG_RE Q)パケットの宛先ポートが発ポートとして記録される。バインディングキャッシュテープ ルの一例を図 4に示す。なお、 MFAと HAとの間に NAPT (Network Address Port Tran slation)装置が介在する場合には、登録要求(REG_REQ)パケットの発信元 IPアドレス 、ポートは、 NAPT装置の外側のインタフェースの IPアドレスとポート番号になる。つま り、着アドレス、着ポートとして NAPT装置の外側のインタフェースの IPアドレスとポート 番号が記録される。 [0024] また、 NAPT装置には FW機能を備えていることが多ぐ NAPT内部力 特定のポート 向けのポート番号に対する発信が禁止されている場合、及び外部の特定のポートか らの返りのパケットの流入が禁止されている場合がある。よって、本実施の形態では、 HAにお!/、て登録要求(REG_REQ)を受信するポートを予め決定しておらず、 MFAは 登録応答 (REG_RES)を受信できるまで様々なポート番号に対して登録要求 (REG_R EQ)の送信を試みる。一方、 HAでは登録要求 (REG_REQ)を受け取り登録応答 (RE G_RES)を送信したとしても、登録応答力MFAまで届いたという保証はないため、図 3 で示したとおり、 3ウェイハンドシェークを用いて、 MFAから登録応答(REG_RES)の送 達確認である登録応答確認 (REG.ACK)を受信するまではバインディングキャッシュ を生成しないこととしている。
[0025] 登録要求(REG_REQ)は定期的に MFAから HAに送信され、バインディングキヤッシ ュのキープアライブとして使用される。 HAでは、一定時間以上登録要求(REG_REQ) を受信しなければタイムアウトしてバインディングキャッシュ力も該当のエントリを削除 する。
[0026] 次に、 MFAが適切な HAに登録要求を送信しない場合について図 5を参照して説 明する。 MFAに登録された HAの IPアドレス力 MNのホームネットワークに接続された HAの IPアドレスでない場合、登録要求を受信した HA1は、 MFAの MACアドレスに対 応付けて MFAマスタテーブルに格納されて!、る、 MNのホームネットワークに接続され た HA2の IPアドレスを取得し、その IPアドレスを含むリダイレクト応答を MFAに返す (ス テツプ 2)。リダイレクト応答を受信した MFAは、それに含まれる IPアドレスの HA2に対 し再び登録要求の発行を試みる (ステップ 3)。そして、登録要求の宛先の HA2が、 M FAマスタテーブルに当該 MFAの MACアドレスに対応する MNの IPアドレスを保持して いれば、その HA2が正しい HAであり、図 3で説明したとおり、当該 HA2は登録応答を 返送する (ステップ 4)。また、登録確認応答 (ステップ 5)を受信してバインディングキ ャッシュを生成する。
[0027] このリダイレクト応答機能を用いることにより、以下に説明する自動設定を実現でき る。
[0028] ネットワーク上に、全ての MFAで共通に使用される設定サーノ (図 5における HA1 に相当)を備え、ここに全ての MFAの MACアドレスとその MFAが接続すべき HAァドレ ス情報を格納する。 MFAは工場出荷時には、設定サーバの IPアドレスを保持しており 、この状態でネットワークに接続されると、設定サーバに対して登録要求を発行する。 設定サーバは、上記の HAのリダイレクト応答と同様にして、その MFAが接続するべき HAの IPアドレスを含んだリダイレクト応答を返送する。
[0029] この方式は、運用中の HAを分割する場合にも利用できる。 HAに収容される MFAの 数が多くなり、一台の HA (分割前 HAと呼ぶ)を 2台に分割した状況であるものとする。 この場合、予め新たに 2台の HA (分割後 HAと呼ぶ)を用意しておく。
[0030] そして、分割前 HAにおける MFAマスタテーブルのエントリの中で、分割後 HAに移 すべき MFAのエントリを、分割後 HAのアドレスに書き換えておく。そして、分割前 HA は、定期的に移設対象 MFAから発行される登録要求に対し、分割後 HAの IPアドレス を含むリダイレクト応答を返送する。これ〖こより、当該 MFAは分割後 HAに接続される
[0031] 以下、レイヤ 2トンネリング方式を第 1の実施の形態として説明し、レイヤ 3トンネリン グ方式を第 2の実施の形態として説明する。
[0032] (第 1の実施の形態)
[システム構成概要]
図 6に、レイヤ 2トンネリング方式のシステム構成を示す。レイヤ 2トンネリング方式で は、 MFAと HAとが、 MNとホームネットワークのルータ間を結ぶレイヤ 2ブリッジの役割 を果たし、 MNが当該レイヤ 2ブリッジを経由してホームネットワークのルータに接続さ れる。 HAはホームネットワークに接続されており、ホームネットワークにおいて HAはレ ィャ 2スィッチとして動作する。 MFAと MNが訪問先ネットワークに存在する場合にお ける動作概要を次に説明する。
[0033] MNから送信されるイーサネット(登録商標)フレームは全て MFAが受信する(例えば 、 MFAの MN側インタフェースを promiscuousモードとする)。 MFAは受信したイーサネ ット(登録商標)フレーム内の IPヘッダの発信元 IPアドレスが登録されているか否かを 判定し、登録されて 、ればそのイーサネット(登録商標)フレームを MIPヘッダでィー サネット (登録商標)ヘッダを含めてカプセリングして HAに送信する。なお、カプセリン グして特定の宛先にデータを送信することを〃トンネルに送信する〃と表現する場合が ある。デカプセリングする装置がトンネルの終端点となる。
[0034] HAは受信したパケットをデカプセリングし、得られたイーサネット(登録商標)フレー ムをルータに送信する。ルータはレイヤ 3ヘッダに基づき通常の動作を行ってパケット を転送する。
[0035] ルータ力 ホームネットワークに送出されたイーサネット(登録商標)フレームは全て HAが受信する。 HAは受信したイーサネット(登録商標)フレームのレイヤ 3ヘッダの 宛先アドレスが、事前に登録したバインディングキャッシュに登録されたアドレスであ る力否かを判定し、登録されたアドレスである場合に、そのイーサネット (登録商標)フ レームを MIPヘッダでカプセリングして MFAに送信する。 MFAはデカプセリングを行つ て、イーサネット(登録商標)フレームを MNに送信する。
[0036] 送信するフレームがブロードキャストフレームやマルチキャストフレームである場合、 HA、 MFAはいずれも無条件に MIPヘッダを付けてパケットを送出する(トンネルに送り 出す)。よって、 MNやホームネットワーク上にあるルータから発信された ARPはホーム ネットワーク上の全ての MNが受信することになり、 MNが MFAとともにネットワーク間を 移動しても IP通信が可能となる。
[0037] [詳細装置構成]
次に、レイヤ 2トンネリング方式を実現する MFAと HAの機能構成を詳細に説明する 。図 7に MFAの機能構成を示す。図 7に示すように、 MFAは、登録要求を発行するポ 一リング処理部 11、イーサネット (登録商標)の通信処理を行う Ethernet (登録商標) 処理部 12、 13、 UDP/IPの通信処理を行う UDPZIP機能部 14、上り方向の通信処 理を行う上り方向通信処理部 15、下り方向の通信処理を行う下り方向通信処理部 1 6、各種テーブル 17を有している。 MFAの機能はロジック回路を用いて実現してもよ V、し、 CPUやメモリ等を有するコンピュータに各処理部の処理を実現するためのプロ グラムを搭載すること〖こより実現してもよい。当該プログラムは、 CD-ROMやメモリ力ら インストール可能である。また、ネットワークを介してダウンロードすることも可能である 。各種テーブルはメモリ等の記憶装置に格納される。
[0038] 図 7に示すように、各種テーブル 17には HA設定テーブルと MNフィルタテーブルが 含まれる。
[0039] HA設定テーブルには HAの IPアドレスとポート番号が格納されて!、る。 HA設定テ 一ブルはポーリング処理部 11により参照され、ポーリング処理部 11はこのテーブル に設定されている HAに対して登録要求を定期的に発行する。なお、 MFAの初期出 荷時には設定サーバの IPアドレスが設定されており、 MFAが使用されるときに、登録 リダイレクト応答により適切な HAの IPアドレスが上書きされる。また、登録応答 (正常 な登録応答)によりポート番号が設定される。
[0040] MNフィルタテーブルには登録応答パケットに格納されて!、る MNの IPアドレスが格 納される。なお、 MNの IPアドレスを予め MFAに格納しておいてもよい。 MNフィルタテ 一ブルは上り方向通信処理部 15により参照されるものであり、上り方向通信処理部 1 5はイーサネット(登録商標)フレームを受信すると、フレーム内の IPヘッダを読み取り 、発 IPアドレスがこのテーブルに登録されている場合に、そのフレームを MIPヘッダ でカプセリングして HAに送信する。
[0041] 続いて、 HAの機能構成を図 8を参照して説明する。図 8に示すように、 HAは、 Ethe rnet (登録商標)処理部 21、 22、 UDPZlP機能部 23、上り方向通信処理部 24、下り 方向通信処理部 25、キャッシュ管理部 26、 MFAマスタテーブル 27、及びバインディ ングキャッシュ 28を有して 、る。 HAは CPUやメモリ等を有するコンピュータに各処理 部の処理を実現するためのプログラムを搭載することにより実現可能である。当該プ ログラムは、 CD- ROMやメモリからインストール可能である。また、ネットワークを介して ダウンロードすることも可能である。また、各種テーブルやバインディングキャッシュは メモリ等の記憶装置に格納される。
[0042] MFAマスタテーブル 27には MFAの情報が管理者等により予め格納される。この M FAの情報は、 MFAのハードウェア m情報 (本実施形態では MACアドレス)、 IPァドレ ス、アドレスタイプを含み。それらが対応付けられている。アドレスタイプが MNであれ ばそのアドレスは該当 MFAに接続される MNの IPアドレスであり、アドレスタイプが H Aであればそのアドレスは該当 MFAが接続するべき HAの IPアドレスを示す。
[0043] バインディングキャッシュ 28は、 MNのアドレスと MFAのアドレスとを対応付けた情報 である。 HAはホームネットワークからフレームを受信したときに、宛先 IPアドレスを読 み取り、このバインディングキャッシュを検索する。該当 IPアドレスが見つかれば、登 録されている MFAの IPアドレスとポートに対し、登録されている発ポート番号を発信 元ポートとしてカプセリングして送信する。
[0044] ノインデイングキャッシュ 28は登録応答確認パケットを受信すると自動更新される。
HAは、登録要求パケットの発信元 MFAが接続されている MNのアドレスをキーとして 、登録応答確認パケットの発信元から着アドレス及び着ポートを設定する。またこの 登録応答確認パケットの宛先をバインディングキャッシュの発ポートとして設定する。 一定時間以上該当 MFA力 登録要求がこなければ、該当エントリは古いデータとし て削除される。
[0045] [MIPヘッダ]
ここで、登録関係の MIPパケット、及び通信データのカプセリングに使用される MIP ヘッダについて説明しておく。なお、以下での説明は第 2の実施の形態におけるレイ ャ 3トンネリング方式とも共通である。
[0046] 図 9は MFAから HAに対し送出される登録要求パケットのフォーマットを示す図であ る。
[0047] Verはシステムのバージョン番号で 2に固定である。 Typeは登録要求であることを表 す 05hが設定される。 Lengthは paddingを含めた本パケット全体の長さが設定される。 MPDUは HAに分解組み立てを指示する最大パケット長である(カプセルヘッダを含 めて、 UDP/IPヘッダは含まないで)。この値より大きなデータは、トンネルには送り込 むことができない。 Hardware IDは MFAに設定されている MACアドレスである。インタ フェースが複数あり MACアドレスを複数持つ場合は、そのうちで一番値の小さなもの を設定する。
[0048] ProtocolTypeはトンネルをレイヤ 2トンネリングとするかレイヤ 3トンネリングのどちら にするのか HAに提案するために使う。レイヤ 3トンネリングの場合には、ネットワークァ ドレスが IPv4なのか、 IPv6なのかの指定に使う。 AuthLengthは BasicAuthDataフィー ルドの大きさをバイト数で表したものである。 BasicAuthDataは、 MFAに設定されたク レデンシャルを RFC2617の基本認証で規定された方式に従って符号ィヒした文字列と なる。 Paddingはこのパケットの大きさを自由に変えるために、任意のデータを設定し てよいフィールドである。
[0049] 図 10Aに、 HAから MFAに対し送出される登録応答パケットのフォーマットを示す。 T ypeには登録応答パケットであることを表す 07hが設定される。 Lengthには paddingを含 めた本パケット全体の長さが設定される。 Protocol Typeには登録要求に対する結果 が設定される。このフィールドが OOlOhであれば登録承認、 0020hであればリダイレク シヨンである。登録承認時にもリダイレクション時にもアドレス情報を通知する。
[0050] AddressTypeはアドレスのプロトコルであり、これによりひとつのアドレスあたりのデー タ長が定まる。 Number of Addressで、その後に格納されるアドレスの数が指定される 。 Address Typeの具体的な値、プロトコル、アドレス長は図 10Bに示す通りである。
[0051] 図 11に、 HAと MFAで双方で送りあうフレームカプセリングパケット (Data)のフォーマ ットを示す。 Typeには Dataであることを表す 10hが設定される。 Lengthには本パケット 全体の長さが設定される。 Protocol Typeは登録時に認証されたトンネル方式 (L2トン ネル、 L3トンネルの種別)が設定される。この識別子が L2を指定すれば、データ部は イーサネット (登録商標)ヘッダを含む L2フレームであり、 L3を指定すると IPヘッダを 含む IPデータグラムとなる。グループ IDは、本パケットがフレーム分割された後のセグ メントである場合には非 0となっている。 GroupIDが非 0のときに限り、 TotalLengthおよ び Offsetフィールドが有効となり、長いデータが分割されてカプセリングされていること を示す。 HAや MFAでは、同じ GroupIDのデータ片を組み立ててから、 MNや CNに送 り出す。
[0052] [動作詳細]
次に、レイヤ 2トンネリング方式における各装置の動作を詳細に説明する。なお、以 下の MFAと HAの登録動作についてはレイヤ 3トンネリング方式と共通である。
(l) MFAの登録動作
まず、 MFAの登録動作について説明する。
[0053] MFAではポーリング処理部 11がー定時間ごとに起動される。起動されたポーリング 処理部 11は、 HA設定テーブルを読み取り、登録されている IPアドレスに対して登録 要求を発信する。
[0054] そのときの宛先ポート番号はランダムに選ばれる。応答がなければ次々と異なるポ ート番号が選ばれて、正常な登録応答が返されるまで、さまざまな宛先ポート番号に 登録要求が発信される。
[0055] 下り方向通信処理部 16が登録応答を受け取ると、登録応答が正常応答であれば、 HA設定テーブルにこのときの登録要求の宛先ポート番号を設定する。以降ポーリン グ処理部 11は、そのポート番号にだけ登録要求を発行することになる。また、正常な 登録応答には、 MNの IPアドレスが格納されており、この情報をフィルタテーブルに設 定する。そして HAに対して登録応答確認を返送する。
[0056] 登録応答がリダイレクト応答であれば、リダイレクト応答に格納されている IPアドレス で HAテーブルの IPアドレスを上書きして、 HAポート番号およびフィルタテーブルをク リアする。これによりポーリング処理部 11は新しい HAに対して登録処理を行う。
[0057] MFAは一定時間以上登録応答を受信しなければ、 HAが削除されたものとして HA テーブルの IPアドレスを初期値に書き戻し、 HAポート番号およびフィルタテーブルを タリ する。
(2) HAの登録動作
次に、 HAの登録動作を説明する。
[0058] HAの上り方向通信処理部 24が MFAからの登録要求を受け取ると、キャッシュ管理 部 26に処理を引き渡す。キャッシュ管理部 26では登録要求に含まれる MFAの MAC アドレスをキーとして MFAマスターテーブルを検索し、該当レコードを探す。
[0059] 抽出されたレコードのレコードタイプが MNであれば、上り方向通信処理部 24は、登 録応答パケットに当該 MNの IPアドレスを格納し、 MFAに対して登録正常応答を返す 。一方レコードタイプが HAであれば、リダイレクト先 IPアドレスを含む登録リダイレクト 応答を返す。
[0060] HAの上り方向通信処理部 24が MFAからの登録応答確認を受け取ると、キャッシュ 管理部 26に処理が引き渡たされる。キャッシュ管理部 26は、登録応答確認もしくは 登録要求のパケットのアドレス情報に基づきバインディングキャッシュをアップデート する。
(3) MFAの上り方向データ転送手順
次に、レイヤ 2トンネリング方式における MFAの上り方向のデータ転送手順につい て図 12のフローチャートを参照して説明する。
[0061] MFAの上り方向通信処理部は、 MNに接続されているインタフェースからすべての パケットをイーサネット (登録商標)ヘッダを含めて受信する (ステップ 1)。受信したィ ーサネット(登録商標)フレームの宛先アドレスがブロードキャストアドレスやマルチキ ャストアドレスであれば (ステップ 2の Yes)トンネル転送動作に入る(ステップ 4)。また 、受信したイーサネット(登録商標)フレームが IPパケットを含み、発信元 IPアドレスが MNフィルタテーブルに登録されている場合にも(ステップ 3の Yes)、トンネル転送動 作に入る (ステップ 4)。それ以外の場合は何もしない。
[0062] ステップ 4では、 MFAは HA設定テーブルを参照し、 HAの IPアドレスとポート番号が 登録されて!、れば、送るべきイーサネット(登録商標)フレームの前に MIP共通ヘッダ を付カ卩し、 UDPを使って登録されて 、る HAに対しパケットを送信する。
(4) HAの上り方向データ転送手順
次に、レイヤ 2トンネリング方式における HAの上り方向のデータ転送手順を図 13の フローチャートを参照して説明する。
[0063] HAにおける MFAからのパケットを受信するインタフェースにおいて、 自 IPアドレス向 け UDPパケットは宛先ポート番号の値にかかわらず全て受信する(ステップ 11)。 HA は、 UDPパケットの後に MIPヘッダがあるか否かを判断し、 MIPヘッダがあれば、自 HA あてのパケットであると判断する(ステップ 12の Yes)。
[0064] 受信したパケットが自 HAあてパケットであれば、 HAは、パケットの MIPヘッダを参照 し、登録関連パケットなのかユーザフレーム格納パケットなのかを判断する(ステップ 13)。登録関連パケットであれば当該パケットをキャッシュ管理部に引き渡し、前述し た登録処理を行う。
[0065] ユーザフレームパケットであれば、 MIPヘッダを取り外しイーサネット(登録商標)フ レームをパケットから取り出す (ステップ 14)。
[0066] ステップ 14において取り出されたイーサネット(登録商標)フレームがュ-キャストで あり PDU力 Pパケットであれば (ステップ 15のュ-キャスト)、宛先 IPアドレスを取り出 す。そしてバインディングキャッシュを参照し、該当 IPアドレスが登録されているかどう かを調べる(ステップ 16)。もしバインディングキャッシュに当該 IPアドレスがあれば、 そのイーサネット(登録商標)フレームごと再カプセルィ匕してトンネルに送り出す (ステ ップ 17)。
[0067] 当該 IPアドレスがバインディングキャッシュに存在しなければ (ステップ 16の No)、そ のイーサネット(登録商標)フレームは、ホームネットワーク側に送り出されることにより 、その宛先 MACアドレス保持者(ホームネットワークのルータ等)が受信する(ステップ 18)。
[0068] ステップ 15において、イーサネット(登録商標)フレームの宛先 MACアドレスがブロ ードキャストもしくはマルチキャストアドレス宛であれば、 HAはホームネットワークに当 該イーサネット (登録商標)フレームを送出するとともに、ノインデイングキャッシュを参 照して現在開設されて!ヽるすべてのトンネルに対して、イーサネット(登録商標)フレ 一ムを再カプセル化して送出する(ステップ 19)。送り先の IPアドレスと UDPポート、お よび発信元ポート番号はバインディングキャッシュの該当エントリの登録に従う。これ によりブロードキャスト Zマルチキャストフレームは移動中か否かに関わらず、ホーム ネットワークに接続されているすべてのノードが受信する。よって移動中同士の MN間 であっても ARPメカニズムが動作するために、モパイル IP通信が実現できる。
(5) HAの下り方向のデータ転送手順
次に、レイヤ 2トンネリング方式における HAの下り方向のデータ転送手順について 図 14を参照して説明する。
[0069] HAは、当該 HAのホームネットワークに接続されているインタフェースにおいてすベ てのパケットをイーサネット(登録商標)ヘッダを含めて受信する (ステップ 21)。
[0070] 受信したイーサネット(登録商標)フレームがュ-キャストであり PDUが IPパケットで あれば (ステップ 22のュ-キャスト)、宛先 IPアドレスを抽出しバインディングキャッシュ を参照して該当 MNが登録されているかどうか (移動中力どうか)を調べる (ステップ 23 )。 ノインデイングキャッシュにその IPアドレスが登録されて 、なければそれ以上何も しない。
[0071] バインディングキャッシュに宛先 IPアドレスが登録されて!ヽれば (ステップ 23の Yes) 、そのイーサネット (登録商標)フレームごとカプセルィ匕してトンネルに送り出す (ステツ プ 24)。送り先の IPアドレスと UDPポート、および発信元ポート番号はバインディング キャッシュの該当エントリの登録に従う。
[0072] 受信したイーサネット(登録商標)フレームの宛先 MACアドレスがブロードキャストも しくはマルチキャストであれば (ステップ 22のブロードキャスト等)、ノインデイングキヤ ッシュに登録されているすべてのトンネルに対しそのフレームをカプセル化して送り 出す (ステップ 25)。送り先の IPアドレスと UDPポート、および発信元ポート番号はバイ ンデイングキャッシュの該当エントリの登録に従う。
(6) MFAの下り方向のデータ転送手順
次に、レイヤ 2トンネリング方式における MFAの下り方向のデータ転送手順につい て図 15を参照して説明する。
[0073] MFAの訪問先ネットワークに接続されているインタフェースには、訪問先ネットヮー クの DHCP等のアドレス割り当て機能により IPアドレスが割り当てられる。 HAからのパ ケットはこのインタフェースに着信する。
[0074] MFAは、 HAからのパケットを UDPデータグラムとして受信する(ステップ 31)。データ グラムには MIPヘッダが含まれているので、デカプセル化を行い、ヘッダを削除するこ とによりイーサネット (登録商標)フレームを抽出する (ステップ 32)。
[0075] デカプセル化されたイーサフレームを MNの接続されて!、るインタフェースに送り出 す (ステップ 33)。イーサネット(登録商標)フレームがブロードキャストやマルチキャス トであれば、該当インタフェースに接続されているすべての MNが受け取ることになる 。イーサネット(登録商標)フレームがュ-キャストフレームであれば、その宛先の MA Cアドレスをもつ MNだけがそのイーサネット(登録商標)フレームを受け取る。
[0076] (第 2の実施の形態)
[システム構成概要]
次に、本発明の第 2の実施の形態としてのレイヤ 3トンネリング方式について説明す る。図 16にレイヤ 3トンネリング方式のシステム構成を示す。レイヤ 3トンネリング方式 では、 HAはルータ(レイヤ 3スィッチ)として動作する。以下、レイヤ 3トンネリング方式 の動作概要を説明する。
[0077] MFAにおいて MNと接続されるインタフェースは IPアドレスを持たず、 MFAは MNから 発信される全てのイーサネット (登録商標)フレームを受信する。また、 MNから ARPリク ェストが送信されると、 MFAはその ARPリクエストの発信元 IPアドレスがフィルタに登録 されている MNの IPアドレスと一致するか否かを判定し、一致する場合に、 MFAはその ARPに対して自分の MACアドレスを応答する。つまり、 MFAはプロキシ ARPとして振 舞う。
[0078] 続いて MNからはュ-キャストフレームが送られてくる。発信元 IPアドレスがフィルタ に登録されたものであれば、 MFAは、イーサネット(登録商標)ヘッダを削除し、 IPへ ッダからカプセル化して HAに送信する。 HAはトンネルから受信したフレームをデカプ セル化し、 IPパケットを取り出す。そして、 HAは IPヘッダに基づき適切な宛先に IPパケ ットを転送する。つまり、 HAはルータとして機能する。
[0079] HA力 CNもしくはホームネットワークから IPデータグラムを受信した場合には、 HAは バインディングキャッシュを参照し、宛先 IPアドレスが登録されていれば、そのエントリ に記載されている着アドレスに基づき IP-in-IPカプセリングを行ってトンネル経由で M FAにパケットを送信する。 MFAは宛先の IPアドレスがフィルタに記載されて!、るァドレ スに一致するか否かを判定し、一致するならば、 ARPを用いて宛先の MACアドレスを 得て、イーサネット(登録商標)ヘッダを付カ卩してュ-キャストフレームとして MNに送り 出す。
[0080] MFA、 HAの装置構成をそれぞれ図 17、図 18に示す。図 17、 18に示すように、そ れぞれ ARP処理部を備える点が第 1の実施の形態の MFA、 HAと異なる。
[0081] [動作詳細]
次に、レイヤ 3トンネリング方式における各装置の動作を詳細に説明する。
(l) MFAの上り方向のデータ転送手順
まず、レイヤ 3トンネリング方式における MFAの上り方向のデータ転送手順について 図 19を参照して説明する。
[0082] MFAの MN側インターフェースでは自 MACアドレスあてのイーサネット(登録商標)フ レームを受信する。また、ブロードキャストフレームであれば ARPリクエストのみを受信 する(ステップ 41)。
[0083] 受信したフレーム力ARPリクエストである場合 (ステップ 42の ARP)、 MFAは通信要求 元の IPアドレスを取りだして MNフィルターテーブルと照合し、もしそのアドレスがフィ ルターテーブルに登録してあれば(ステップ 43の Yes)、その ARPリクエストは MNから 発せられたものであるのでステップ 44に進む。
[0084] ステップ 44にお!/、て、 MFAは、 ARPリクエストの要求先 IPアドレスが!/、かなるもので あろうとも、自分の MACアドレスを Target MACに設定したリプライを MNに対して返送 する。これにより MN力 発せられるュ-キャストフレームは MFAが受信できる。
[0085] ステップ 42にお!/、て、 MFAが自 MACアドレス宛てのュ-キャストフレームを受信し た場合、 MFAは、受信したュ-キャストフレームのイーサネット (登録商標)ヘッダを取 り外し、 PDUが IPデータグラムであることを確認する。その IPヘッダ力 発信元 IPァドレ スが MNフィルターテーブルに登録されて!、るものであることを確認できれば (ステップ 45の Yes)、 IPデータグラムをカプセル化し、 UDPを使い HAに送信する(ステップ 46)
(2) HAの上り方向データ転送手順
次に、レイヤ 3トンネリング方式における HAの上り方向データ転送手順について図 20を参照して説明する。
[0086] HAのインターネット側インタフェースは、 CNからホームネットワークに向けられて送 られた IPパケット、及びトンネルを通じて MNから送られてくるカプセル化された IPパケ ットの 2種類を受信する。
[0087] HAがパケットを受信すると (ステップ 51)、そのパケットがトンネル力も受信したパケ ットか、 CN力も送信されたパケットか判定する (ステップ 52)。ここでは、パケットが自 IP アドレス宛で UDPデータグラムになっておりその後に MIPヘッダがあれば、トンネル力 ら受信されたフレームであると判定する。それ以外の IPデータグラムは CN力も発せら れたものとして判定する。
[0088] HAは、受信パケットがトンネル力も受信されたパケットであると判定した場合 (ステツ プ 52のトンネル)、 MIPヘッダを取り除き、通常の IPパケットとする(ステップ 53)。 CN 力も受信した IPパケットである場合には (ステップ 52の CN)そのまま次の処理に移る。
[0089] 続いて、 HAは、 IPパケットの宛先 IPアドレスがホームネットワークであれば、バインデ イングキャッシュを参照し宛先 MNが登録されて!、るかどうかを調べる(ステップ 54)。 該当アドレスがバインディングキャッシュに見つかれば、その IPパケットはカプセル化 されて指定のアドレス、ポートに送り出される (ステップ 55)。バインディングキャッシュ に宛先 IPアドレスが見つからなければ (ステップ 54の No)、 IPアドレスに応じて IPパケ ットを転送する(ステップ 56)。つまり、 IPアドレスがホームネットワークを示していれば I Pパケットをホームネットワーク側に送り出し、 IPパケットの宛先がホームネットワークで ない場合、それは CN向けであるのでその IPパケットをインターネット向けに送り出す。 (3) HAの下り方向のデータ転送手順
次に、レイヤ 3トンネリング方式における HAの下り方向のデータ転送手順について 図 21を参照して説明する。
[0090] HAは、 MN側インターフェースでは自 MACあてのイーサネット(登録商標)フレーム 、および、ブロードキャストフレームのうち ARPリクエストのみを受信する(ステップ 61)
[0091] ステップ 62において、受信したイーサネット(登録商標)フレームが ARPリクエストで あれば (ステップ 62の Yes)、通信要求先の Target IP を取り出す (ステップ 63)。そ のアドレスは自 IPアドレスである力、もしくはバインディングキャッシュと照合し一致す る MNが登録されているかどうかを判定する (ステップ 64)。もし判定結果が合致すれ ば (ステップ 64の OK)、 ARPリプライを返すためにステップ 65に進む。合致しなけれ ば、 ΗΑは ARPリプライを返すべきではな!/、ために何もしな!、。
[0092] ステップ 65において、つまり ARPリクエストの要求先 IPアドレスが自 IPアドレス(これ はホームネットワークに接続されているノードがインターネットに接続するためにデフ オルトルートである HAにパケットを送ろうとしたときに発生する)、もしくは移動中の MN を指向して 、る場合には、 V、つたん HAがパケットを受け取らなければならな!/、ために ARPリプライで応答する(ステップ 65)。返送する ARPリプライには、 HAのホームネット ワーク側に接続されているインタフェースの MACアドレスを格納する。
[0093] ステップ 62にお!/、て、受信したイーサネット(登録商標)フレームが自 MACアドレス あてのュ-キャストフレームであれば(ステップ 62の No)、 HAは、受信したュ-キャス トフレームのイーサネット(登録商標)ヘッダを取り外して PDUが IPデータグラムである ことを確認し、その IPヘッダから宛先 IPアドレスを取り出す (ステップ 66)。その IPァドレ スがバインディングキャッシュに登録されているものであれば (ステップ 67の Yes)、力 プセル化して UDPを使 、該当の MFAに送り出す (ステップ 68)。ステップ 67にお!/、て 、 IPアドレスがバインディングキャッシュに登録されているものでなければ、それは CN 向けであるのでその IPパケットをインターネット向けに送り出す (ステップ 69)。
(4) MFAの下り方向のデータ転送手順
次に、レイヤ 3トンネリング方式における MFAの下り方向のデータ転送手順につい て図 22を参照して説明する。
[0094] MFAの訪問先ネットワークに接続されているインタフェースは、訪問先ネットワーク における DHCP等のアドレス割り当て機能を使ってネットワークアドレスを割り当てられ ている。 MFAは HAからのパケットをこのインタフェースで受信する(ステップ 71)。受 信したパケットは UDPデータグラムとして受信される。データグラムには MIPヘッダが 含まれているのでヘッダを削除することにより IPパケットがデカプセル化される(ステツ プ 72)。その IPヘッダに含まれる宛先 IPアドレスを取り出し、 MNフィルターテーブルを 参照する。アドレス情報が合致すれば (ステップ 73の Yes)、その IPパケットを通常の A RP処理を使って MN側ネットワークに送り出す (ステップ 74)。
[0095] 以上説明したように、第 1、第 2の実施の形態で説明したシステムを用いることにより 、MNや移動先ネットワークに特別な仕組みを備えることなくモパイル IPを実現すること が可能となる。特に MNに特別な仕組みを備える必要がないことから、特別なソフトゥ エアを事前にインストールすることのできないコピー機や POSレジスタを MNとして使用 できる。
[0096] なお、本発明は、上記の実施の形態に限定されることなぐ特許請求の範囲内にお いて、種々変更 '応用が可能である。
[0097] 本国際出願は 2005年 11月 16日に出願された日本国特許出願第 2005— 33176
3号に基づく優先権を主張するものであり、その全内容を本国際出願に援用する。

Claims

請求の範囲
[1] ユーザ端末と、当該ユーザ端末に接続された移動エージェント装置と、前記ユーザ 端末のホームネットワークに接続されたホームエージェント装置とを備える通信システ ムにおける通信方法であって、
前記ホームエージェント装置は、前記移動エージェント装置から送信される登録要 求に基づき、前記ユーザ端末のレイヤ 3アドレスと前記登録要求の発信元のレイヤ 3 アドレスとを対応付けてアドレス対応表に登録し、前記移動エージェント装置は前記 ユーザ端末のレイヤ 3アドレスを保持し、
前記ユーザ端末力も通信相手端末に対してパケットを送信する場合にぉ 、て、前 記移動エージェント装置は、前記ユーザ端末からレイヤ 2フレームを受信し、当該レイ ャ 2フレーム内のレイヤ 3ヘッダにおける発信元レイヤ 3アドレスが登録されている場 合に、受信したレイヤ 2フレームをカプセリングして前記ホームエージェント装置に送 信し、
前記ホームエージェント装置は、カプセリングされた前記レイヤ 2フレームをデカプ セリングして前記レイヤ 2フレームを取り出し、当該レイヤ 2フレームを前記ホームネッ トワークに送出し、ホームネットワークを収容するルータが前記通信相手端末宛にパ ケットを転送し、
前記通信相手端末力 前記ユーザ端末に対してパケットを送信する場合において 、前記ホームエージェント装置は、前記ホームネットワーク力 レイヤ 2フレームを受信 し、当該レイヤ 2フレーム内のレイヤ 3ヘッダにおける宛先レイヤ 3アドレスが前記アド レス対応表に登録されていることを確認し、当該宛先レイヤ 3アドレスに対応付けて登 録されている前記登録要求の発信元のレイヤ 3アドレスに向けて前記レイヤ 2フレー ムをカプセリングして送信し、
前記移動エージェント装置は、カプセリングされた前記レイヤ 2フレームを受信し、 デカプセリングして当該レイヤ 2フレームを取り出し、前記ユーザ端末に送信する ことを特徴とする通信方法。
[2] ユーザ端末と、当該ユーザ端末に接続された移動エージェント装置と、前記ユーザ 端末のホームネットワークに接続されたホームエージェント装置とを備える通信システ ムにおける通信方法であって、
前記ホームエージェント装置は、前記移動エージェント装置から送信される登録要 求に基づき、前記ユーザ端末のレイヤ 3アドレスと前記登録要求の発信元のレイヤ 3 アドレスとを対応付けてアドレス対応表に登録し、前記移動エージェント装置は前記 ユーザ端末のレイヤ 3アドレスを保持し、
前記ユーザ端末力も通信相手端末に対してパケットを送信する場合にぉ 、て、前 記移動エージェント装置は、前記ユーザ端末からレイヤ 2フレームを受信し、当該レイ ャ 2フレーム内のレイヤ 3ヘッダにおける発信元レイヤ 3アドレスが登録されている場 合に、受信したレイヤ 2フレームからレイヤ 2ヘッダを削除したパケットをカプセリングし て前記ホームエージェント装置に送信し、
前記ホームエージェント装置は、カプセリングされた前記パケットをデカプセリングし て前記パケットを取り出し、レイヤ 3ヘッダに基づき当該パケットを転送し、
前記通信相手端末力 前記ユーザ端末に対してパケットを送信する場合において 、前記ホームエージェント装置は当該パケットを受信し、当該パケットのレイヤ 3ヘッダ における宛先レイヤ 3アドレスが前記アドレス対応表に登録されていることを確認し、 当該宛先レイヤ 3アドレスに対応付けて登録されている前記登録要求の発信元のレ ィャ 3アドレスに向けて前記パケットをカプセリングして送信し、
前記移動エージェント装置は、カプセリングされた前記パケットを受信し、デカプセ リングして当該パケットを取り出し、前記ユーザ端末に送信する
ことを特徴とする通信方法。
前記ホームエージェント装置は、当該ホームエージェント装置に接続されるべきで ない第 2の移動エージェント装置の識別情報と、当該第 2の移動エージェント装置が 接続するべき第 2のホームエージェント装置のアドレスとを対応付けてアドレス対応表 に保持しており、
前記ホームエージェント装置は、前記第 2の移動エージェント装置から送信された 登録要求を受信した場合において、前記アドレス対応表を参照して、前記第 2のホー ムエージェント装置のアドレスを含むリダイレクト応答を前記第 2の移動エージェント 装置に送信することを特徴とする請求項 1又は 2に記載の通信方法。 [4] 前記移動エージェント装置は、前記ユーザ端末から ARPリクエストを受信した場合 において、当該 ARPリクエストの発信元レイヤ 3アドレスが当該移動エージェント装置 に登録されていることを確認すると、自身の MACアドレスを ARPリクエストに対する応 答として前記ユーザ端末に送信することを特徴とする請求項 2に記載の通信方法。
[5] ユーザ端末と、当該ユーザ端末に接続された移動エージェント装置と、前記ユーザ 端末のホームネットワークに接続されたホームエージェント装置とを備える通信システ ムにお 、て使用される前記移動エージェント装置であって、
前記ユーザ端末のレイヤ 3アドレスを保持する記憶手段と、
前記ユーザ端末力もレイヤ 2フレームを受信し、当該レイヤ 2フレーム内のレイヤ 3 ヘッダにおける発信元レイヤ 3アドレスが前記記憶手段に登録されている場合に、受 信したレイヤ 2フレームをカプセリングして前記ホームエージェント装置に送信する手 段と、
カプセリングされたレイヤ 2フレームを前記ホームエージェント装置から受信し、デカ プセリングして当該レイヤ 2フレームを取り出し、前記ユーザ端末に送信する手段と を有することを特徴とする移動エージェント装置。
[6] ユーザ端末と、当該ユーザ端末に接続された移動エージェント装置と、前記ユーザ 端末のホームネットワークに接続されたホームエージェント装置とを備える通信システ ムにお 、て使用される前記移動エージェント装置であって、
前記ユーザ端末のレイヤ 3アドレスを保持する記憶手段と、
前記ユーザ端末力もレイヤ 2フレームを受信し、当該レイヤ 2フレーム内のレイヤ 3 ヘッダにおける発信元レイヤ 3アドレスが前記記憶手段に登録されている場合に、受 信したレイヤ 2フレームからレイヤ 2ヘッダを削除して得たパケットをカプセリングして 前記ホームエージェント装置に送信する手段と、
カプセリングされたパケットを前記ホームエージェント装置力も受信し、デカプセリン グしてパケットを取り出し、前記ユーザ端末に送信する手段と
を有することを特徴とする移動エージェント装置。
[7] 前記移動エージェント装置は、前記ユーザ端末から ARPリクエストを受信した場合 において、当該 ARPリクエストの発信元レイヤ 3アドレスが前記記憶手段に登録されて V、る場合に、自身の MACアドレスを ARPリクエストに対する応答として前記ユーザ端 末に送信することを特徴とする請求項 6に記載の移動エージェント装置。
[8] ユーザ端末と、当該ユーザ端末に接続された移動エージェント装置と、前記ユーザ 端末のホームネットワークに接続されたホームエージェント装置とを備える通信システ ムにおける前記ホームエージェント装置であって、
前記移動エージェント装置から送信される登録要求に基づき、前記ユーザ端末の レイヤ 3アドレスと前記登録要求の発信元のレイヤ 3アドレスとを対応付けてアドレス 対応表に登録する手段と、
通信相手端末宛のパケットを含むカプセリングされたレイヤ 2フレームを前記移動ェ ージェント装置力 受信し、デカプセリングして前記レイヤ 2フレームを取り出し、当該 レイヤ 2フレームを前記ホームネットワークのルータに送信する手段と、
前記ホームネットワークからパケットを含むレイヤ 2フレームを受信し、当該レイヤ 2フ レーム内のレイヤ 3ヘッダにおける宛先レイヤ 3アドレスが前記アドレス対応表に登録 されている場合に、当該宛先レイヤ 3アドレスに対応付けて登録されている前記登録 要求の発信元のレイヤ 3アドレスに向けて前記レイヤ 2フレームをカプセリングして送 信する手段と
を有することを特徴とするホームエージェント装置。
[9] ユーザ端末と、当該ユーザ端末に接続された移動エージェント装置と、前記ユーザ 端末のホームネットワークに接続されたホームエージェント装置とを備える通信システ ムにおける前記ホームエージェント装置であって、
前記移動エージェント装置から送信される登録要求に基づき、前記ユーザ端末の レイヤ 3アドレスと前記登録要求の発信元のレイヤ 3アドレスとを対応付けてアドレス 対応表に登録する手段と、
カプセリングされた通信相手端末宛のパケットをデカプセリングして当該パケットを 取り出し、レイヤ 3ヘッダに基づき当該パケットを前記通信相手端末に向けて転送す る手段と、
受信したパケットのレイヤ 3ヘッダにおける宛先レイヤ 3アドレスが前記アドレス対応 表に登録されて ヽることを確認し、当該宛先レイヤ 3アドレスに対応付けて登録されて いる前記登録要求の発信元のレイヤ 3アドレスに向けて前記パケットをカプセリングし て送信する手段と
を有することを特徴とするホームエージェント装置。
前記ホームエージェント装置は、当該ホームエージェント装置に接続されるべきで ない第 2の移動エージェント装置の識別情報と、当該第 2の移動エージェント装置が 接続するべき第 2のホームエージェント装置のアドレスとを対応付けてアドレス対応表 に保持しており、
前記ホームエージェント装置は、前記第 2の移動エージェント装置から送信された 登録要求を受信した場合において、前記アドレス対応表を参照して、前記第 2のホー ムエージェント装置のアドレスを含むリダイレクト応答を前記第 2の移動エージェント 装置に送信することを特徴とする請求項 8又は 9に記載のホームエージェント装置。
PCT/JP2006/322804 2005-11-16 2006-11-16 通信方法、移動エージェント装置、及びホームエージェント装置 WO2007058228A1 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
ES06832694T ES2428065T3 (es) 2005-11-16 2006-11-16 Método de comunicación, dispositivo de agente móvil y dispositivo de agente local
EP20060832694 EP1950918B1 (en) 2005-11-16 2006-11-16 Communication Method, Mobile Agent Device, and Home Agent Device
CN2006800429345A CN101310487B (zh) 2005-11-16 2006-11-16 通信方法、移动代理装置以及本地代理装置
US12/093,962 US8717941B2 (en) 2005-11-16 2006-11-16 Communication method, mobile agent device, and home agent device
PL06832694T PL1950918T3 (pl) 2005-11-16 2006-11-16 Sposób komunikacji, urządzenie agenta mobilnego i urządzenie agenta macierzystego
NO20082696A NO20082696L (no) 2005-11-16 2008-06-11 Kommunikasjonsmetode, mobilapparat og hjemmeapparat

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2005331763A JP4231042B2 (ja) 2005-11-16 2005-11-16 通信方法、移動エージェント装置、及びホームエージェント装置
JP2005-331763 2005-11-16

Publications (1)

Publication Number Publication Date
WO2007058228A1 true WO2007058228A1 (ja) 2007-05-24

Family

ID=38048612

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2006/322804 WO2007058228A1 (ja) 2005-11-16 2006-11-16 通信方法、移動エージェント装置、及びホームエージェント装置

Country Status (9)

Country Link
US (1) US8717941B2 (ja)
EP (2) EP2549781A1 (ja)
JP (1) JP4231042B2 (ja)
KR (1) KR100949355B1 (ja)
CN (1) CN101310487B (ja)
ES (1) ES2428065T3 (ja)
NO (1) NO20082696L (ja)
PL (1) PL1950918T3 (ja)
WO (1) WO2007058228A1 (ja)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4238897B2 (ja) 2006-08-24 2009-03-18 コニカミノルタビジネステクノロジーズ株式会社 ネットワークシステム、画像処理装置、及びプログラム
KR101466889B1 (ko) * 2008-04-03 2014-12-01 삼성전자주식회사 모바일 아이피 방식의 무선통신시스템에서 세션 식별자를검색하기 위한 시스템 및 방법
US8385300B2 (en) * 2008-10-03 2013-02-26 Cisco Technology, Inc. Internet protocol address management for communicating packets in a network environment
BR112012018762B1 (pt) 2010-05-28 2022-06-21 Huawei Technologies Co., Ltd Sistema, componente de rede e método para promover uma comunicação entre uma pluralidade de domínios de acesso
CN104396192B (zh) 2010-06-29 2018-03-06 华为技术有限公司 不对称网络地址封装
JP5795848B2 (ja) * 2010-09-22 2015-10-14 キヤノン株式会社 情報処理装置、その制御方法、及びプログラム
CN104247339A (zh) * 2012-04-27 2014-12-24 惠普发展公司,有限责任合伙企业 家庭网络分组递送
EP2891358A1 (en) * 2012-08-29 2015-07-08 Qualcomm Incorporated Improved fragmentation for long packets in a low-speed wireless network
CN103795627B (zh) * 2012-10-30 2017-08-18 华为技术有限公司 三层本地转发方法和设备
US9203694B2 (en) * 2013-03-15 2015-12-01 Telefonaktiebolaget L M Ericsson (Publ) Network assisted UPnP remote access
JP5980724B2 (ja) * 2013-05-24 2016-08-31 日本電信電話株式会社 ネットワーク装置、中継管理方法、中継管理プログラムおよび通信システム
US20180351911A1 (en) * 2015-12-10 2018-12-06 Telefonaktiebolaget Lm Ericsson (Publ) Collecting addresses in a subnetwork
CN107995646A (zh) * 2017-11-29 2018-05-04 中国人民解放军陆军工程大学 一种基于商用仿真系统的无线网络测试评估的系统和方法
US20210385188A1 (en) * 2018-10-11 2021-12-09 Telefonaktiebolaget Lm Ericsson (Publ) Communication Between a Controller and a Controlled Device Over a Wireless Network
US11258621B2 (en) * 2020-06-09 2022-02-22 Cisco Technology, Inc. Directed broadcast in network fabric

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1023076A (ja) * 1996-07-01 1998-01-23 Kokusai Denshin Denwa Co Ltd <Kdd> 移動コンピュータ通信システム
JP2001224070A (ja) * 2000-02-09 2001-08-17 Fujitsu Ltd モバイル通信システム及びその方法
JP2002077273A (ja) * 2000-08-30 2002-03-15 Nippon Telegr & Teleph Corp <Ntt> 移動vpnサービス方法及び装置
US20020067704A1 (en) 2000-12-01 2002-06-06 Telefonaktiebolaget Lm Ericsson (Publ) Method for ensuring reliable mobile IP service
JP2004349854A (ja) * 2003-05-20 2004-12-09 Nippon Telegr & Teleph Corp <Ntt> 通信システム
JP2005204289A (ja) * 2003-12-15 2005-07-28 Matsushita Electric Ind Co Ltd ホームエージェント装置、モバイルルータ装置、通信システム、および通信方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4161782B2 (ja) 2002-04-18 2008-10-08 松下電器産業株式会社 モバイルノードおよび移動通信方法
US7707310B2 (en) * 2002-11-20 2010-04-27 Cisco Technology, Inc. Mobile IP registration supporting port identification
US7609687B2 (en) * 2003-12-15 2009-10-27 Panasonic Corporation Home agent apparatus, mobile router communication system, and communication method
JP2005252997A (ja) 2004-03-08 2005-09-15 Nippon Telegr & Teleph Corp <Ntt> 通信システム、通信方法、通信プログラム、記録媒体、および、移動ルータ
JP2005331763A (ja) 2004-05-20 2005-12-02 Fuji Xerox Co Ltd 光記録材料及び光記録媒体

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1023076A (ja) * 1996-07-01 1998-01-23 Kokusai Denshin Denwa Co Ltd <Kdd> 移動コンピュータ通信システム
JP2001224070A (ja) * 2000-02-09 2001-08-17 Fujitsu Ltd モバイル通信システム及びその方法
JP2002077273A (ja) * 2000-08-30 2002-03-15 Nippon Telegr & Teleph Corp <Ntt> 移動vpnサービス方法及び装置
US20020067704A1 (en) 2000-12-01 2002-06-06 Telefonaktiebolaget Lm Ericsson (Publ) Method for ensuring reliable mobile IP service
JP2004349854A (ja) * 2003-05-20 2004-12-09 Nippon Telegr & Teleph Corp <Ntt> 通信システム
JP2005204289A (ja) * 2003-12-15 2005-07-28 Matsushita Electric Ind Co Ltd ホームエージェント装置、モバイルルータ装置、通信システム、および通信方法

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
C.E. PERKINS: "IP Mobility Support for IPv4", RFC3344, August 2002 (2002-08-01)
HATA H.: "An Implementation of Auto Configuration of Mobile Foreign Agent for Proxy Mobile IP", TECHNICAL REPORT OF IEICE SIS2005-46, 17 November 2005 (2005-11-17), XP003009073 *
HATA H.: "An Implementation of IP-VPN by using Proxy Mobile IP", TECHNICAL REPORT OF IEICE NS2005-95, 8 September 2005 (2005-09-08), XP003009072 *
MILIND; KULKARNI ET AL.: "Mobile IPv4 Dynamic Home Agent Assignment; draft-ietf-mip4-dynamic-assignment-06.txt", IETF DRAFT, 12 October 2005 (2005-10-12)
See also references of EP1950918A4

Also Published As

Publication number Publication date
NO20082696L (no) 2008-07-29
US20090092095A1 (en) 2009-04-09
EP2549781A1 (en) 2013-01-23
US8717941B2 (en) 2014-05-06
JP4231042B2 (ja) 2009-02-25
ES2428065T3 (es) 2013-11-05
PL1950918T3 (pl) 2013-11-29
EP1950918A1 (en) 2008-07-30
KR100949355B1 (ko) 2010-03-26
CN101310487A (zh) 2008-11-19
EP1950918A4 (en) 2011-10-19
JP2007142648A (ja) 2007-06-07
KR20080077114A (ko) 2008-08-21
EP1950918B1 (en) 2013-06-19
CN101310487B (zh) 2012-09-19

Similar Documents

Publication Publication Date Title
JP4231042B2 (ja) 通信方法、移動エージェント装置、及びホームエージェント装置
JP3581251B2 (ja) 通信システム、データパケット転送方法、ルータ装置及びパケット中継装置
JP4431112B2 (ja) 端末及び通信システム
US9584468B2 (en) Layer-2 IP networking method and apparatus for mobile hosts
KR101417744B1 (ko) 인터넷 프로토콜 버전6 기반 저전력 무선네트워크에서이동성 헤더 압축 방법 및 장치
US7616615B2 (en) Packet forwarding apparatus for connecting mobile terminal to ISP network
EP1618723B1 (en) Methods and apparatus for securing proxy mobile ip
US9331980B2 (en) Secure in-band signaling method for mobility management crossing firewalls
CN101212393B (zh) 介质无关切换消息的传输方法、系统及设备
JP2004153392A (ja) 通信システム
US20030053453A1 (en) Router and communication network system
EP1700430B1 (en) Method and system for maintaining a secure tunnel in a packet-based communication system
JP5298540B2 (ja) ネットワークシステム、データ送受信方法、及びデータ送受信プログラム
WO2007028311A1 (fr) Procede d&#39;optimisation de la communication entre noeuds mobiles
JP2004247836A (ja) 通信制御方法、中継装置、プログラムおよび記憶媒体

Legal Events

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

Ref document number: 200680042934.5

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006832694

Country of ref document: EP

Ref document number: 1020087011559

Country of ref document: KR

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 12093962

Country of ref document: US