WO2008054022A2 - ++noeud mobile et routeur d'accès - Google Patents

++noeud mobile et routeur d'accès Download PDF

Info

Publication number
WO2008054022A2
WO2008054022A2 PCT/JP2007/071598 JP2007071598W WO2008054022A2 WO 2008054022 A2 WO2008054022 A2 WO 2008054022A2 JP 2007071598 W JP2007071598 W JP 2007071598W WO 2008054022 A2 WO2008054022 A2 WO 2008054022A2
Authority
WO
WIPO (PCT)
Prior art keywords
packet
vmn
address
tlmr
access router
Prior art date
Application number
PCT/JP2007/071598
Other languages
English (en)
Other versions
WO2008054022A3 (fr
Inventor
Jun Hirano
Mohana Dhamayanthi Jeyatharan
Chan Wah Ng
Pek Yew Tan
Original Assignee
Panasonic Corporation
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 Panasonic Corporation filed Critical Panasonic Corporation
Publication of WO2008054022A2 publication Critical patent/WO2008054022A2/fr
Publication of WO2008054022A3 publication Critical patent/WO2008054022A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0471—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload applying encryption by an intermediary, e.g. receiving clear information at the intermediary and encrypting the received information at the intermediary before forwarding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/102—Route integrity, e.g. using trusted paths
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/108—Source integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/005—Moving wireless networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/005—Data network PoA devices

Definitions

  • the present invention relates to a mobile node and access router made to manage a packet transmission route in a packet-switched data communication network such as an IP (Internet Protocol) network.
  • IP Internet Protocol
  • Non-Patent Document 1 the mobility support has been put in practice by introducing an entity, known as a home agent (HA) , into a home network.
  • HA home agent
  • a mobile node registers a care-of address (CoA: a temporary address a mobile node acquires in an external link) in a home agent by use of a binding update (BU) message.
  • This allows the home agent to produce a bindingbetween a home address (HoA: a long-term address acquired in a home link) of the mobile node and the care-of address thereof.
  • the home agent fulfills a function to receive (intercept) a message directed to the home address of the mobile node and transfer a packet to the care-of address of the mobile node by means of a packet encapsulation (setting a given packet as a payload of a new packet, which is also known as packet tunneling) .
  • the solutions to the local mobility management for a mobile node are classified into two classes.
  • One class involves mobility management in a local domain by means of a tunneling mechanism in the local domain, while the other class involves mobility management in a local domain through the use of a route update mechanism in the local domain.
  • the term "local domain" can signify a large access network existing under a gateway. This gateway is a host router in a routing hierarchy. Advantages and disadvantages exist in the local mobility management methods in the respective classes.
  • the local mobility management based on the routing mechanism eliminates the overhead stemming from tunneling of data as well as a signaling packet in a local domain. Moreover, with the local mobility management method in a case in which a MN moves into a local domain, a QoS reservation is only made up to a path changing point. In such a situation, preferably, a QoS reservation packet is transmitted without undergoing the encapsulation. Thus, in the routing based LMM an intermediate router can carry out the QoS reservation without referring to the contents of the original packet (inner packet) encapsulated.
  • the following Non-Patent Document 3 discloses a method referred to as cellular IP . This is a local mobility management method concerning a MN.
  • the actual position of the MN is hidden with respect to a peer node (correspondent node) , and it operates with the mobile IP.
  • a CoA allocated to an enduser is a gatewayCoA
  • an HoA is held as an identifier of a MN within a cellular IP network or an access network.
  • a soft state route having a next hop media access control (MAC) address is maintained in conjunction with the HoA.
  • MAC media access control
  • NEMO networkmobility
  • Non-Patent Document 2 a solution to the network mobility is currently in an advancing state as disclosed in the following Non-Patent Document 2.
  • the mobile router when a mobile router transmits a BU to a home agent, the mobile router designates a network prefix a node is using in a mobile network.
  • This network prefix is designated by use of a special option known as a network prefix option to be inserted into a BU.
  • the home agent configures a routing table on the basis of the prefix, which enables the home agent to tunnel a packet, transmitted to a destination having such a prefix, to a care-of address of the mobile router.
  • the first type of problem involves an overhead and sub-optimal routing (which is not a completely optimized routing) due to multiple encapsulation on data. This is a problem in that the nested NEMO creates a nested tunneling.
  • the second type of problem is that a long delay occurs when a deeply nestedMN realizes the layer-3 hand-off and a high signaling cost (ineffective cost) is imposed on a network due to the signaling overhead of a BU stream.
  • upstream side MRs signify all MRs existing on the default path to the root of the tree hierarchy (or root of the escape froma nested state) .
  • the root for example, there exists a top-level mobile router
  • Patent Document 1 discloses the reduction of the routing header mentioned above for a solution to a nested tunnel in the NEMO.
  • the Patent Document 1 also discloses a solution to a problem in multiple encapsulation in the nested NEMO in a manner such that each MR within a nested NEMO network implements the route update with respect to all the otherMRs within the nestedNEMO network.
  • the MR advertises a care-of address of the TLMR to its own HA.
  • the HA of the MR establish a tunnel to the TLMR.
  • the HA of the MR can make a packet tunnel to the TLMR.
  • the CoA and prefix of the MR are set as a destination, and the routing in a nested NEMO network is really made on the basis of an NEMO routing protocol . This solution can remove the tunnel.
  • Non-Patent Document 4 discloses a solution coping with both the above-mentioned two types of problems (tunneling in a nested state and delay due to the layer-3 hand-off) .
  • This solution employs a hierarchical network architecture, thereby cutting down the delay related to the BU of a deeply nested MN in the NEMO.
  • the MN updates the position by means of two types of architectures.
  • an entity referred to as a mobility anchor point (MAP) defines a first-stage hierarchical architecture.
  • the function of the MAP can be introduced into, for example, a fixed router in a domain or it can also be incorporated into the TLMR.
  • all the MNs or MRs in the MAP domain have a local care-of address (LCoA) and a regional care-of address (RCoA) .
  • the LCoA is obtainable fromthe prefix of the NEMO with which the MN/MR is directly in connection or the prefix of the AR (Access Router) with which the MN/MR is directly in connection.
  • the RCoA is obtainable from the prefix the MAP possesses.
  • a change of the LCoA takes place whereas no change of the RCoA takes place.
  • only the RCoA is revealed to entities such as a CN and a HA. This cuts down the average delay stemming from the BU signaling according to movement (or average hand-off delay according to movement) and realizes route optimization.
  • the MAP when the RCoA is acquired from the prefix of the MAP, the MAP carries out a proxy for the. MN with respect to this address .
  • a data packet to the MN within the MAP domain is delivered to the MAP, and a tunnel is made from the MAP to the MN.
  • This tunnel it is possible to set a type 2 (RH2) extended routing header.
  • This extended routing header contains the CoAs of all the MRs connected to the MN in the tree topology.
  • the MAP conducts a recursive search on binding cache entries (BCEs) to form this RH.
  • BCEs binding cache entries
  • the BCE contains the LCoA of the MN, the RCoA of the MN and the prefix which is the MR' s prefix obtainable by the MR on the home link.
  • an access router is used as the term indicative of a router, which provides a connection of a mobile node (MN) with a network. That is, in this specification, the term "access router” contains a router
  • the mobile function is a function handling the mobility, which is realized as MIP or NEMO) and a mobile router (MR) equipped with the
  • Non-Patent Document 1 Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Engineering Task Force (IETF) Request For Comments (RFC) 3775, June 2004.
  • Non-Patent Document 2 Devarapalli, V., et. al., "NEMO Basic Support Protocol", IETF RFC 3963, January 2005.
  • Non-Patent Document 3 Valko, A., Campbell, A., and Gomez, J., "Cellular IP” , IETF Internet Draft: draft-valko-cellularip-00.txt, May 1999.
  • Non-Patent Document 4 Ohnishi, H., Sakitani, K., and
  • the first problem is that, when nests with a large number of levels exist in a nested NEMO network, a considerable signaling load occurs at the production of a routing table for the entire network.
  • a considerable signaling load occurs at the production of a routing table for the entire network.
  • a method of forming a reliable routing table is not revealed among the MRs pertaining to different internet service providers (ISP), which creates a problem in security.
  • ISP internet service providers
  • An arbitrary signaling packet or arbitrary data packet transmitted from an MN tunnels through the MN and all the upstream side MRS toward the MAP, which can create a problem in the overhead. Yet additionally, the explicit BU and BA (Binding Acknowledgment) processing are conducted relative to the MAP at every change on the RCoA or LCoA of the MN. This creates the overhead problem with respect to bi-directional signaling.
  • prefix delegation wastes resources (address spaces) in subnets of the MAP, and in a case in which a local fixed router exists in a nested NEMO, a legacy router cannot seize this prefix and, hence, the prefix delegation operation does not take place.
  • the MNP of the NEMO is a prefix acquired from a home link
  • a very important consideration involves a mechanism for verifying the validity of the prefix in the MAP. For example, let it be assumed that the MN is connectable to a tree-type topology with the TLMR being set as a root and all the mobile routers in the tree structure are valid MRs.
  • an object of the present invention is to, in a nested NEMO network in which a plurality of mobile routers exist on a default path through which a MN establishes a connection with the internet, realize the reduction of a routing path, the reduction of hand-off delay and the reduction of signaling in a network between a mobile node (MN) which is in a deeply nested state in a mobile network and a correspondent node (CN) while maintaining a secure route for the MN.
  • MN mobile node
  • CN correspondent node
  • a mobile node connectable under the network in the nested state comprising : means for generating a packet passing through a host access router in the nested state; and means for adding, to the packet, certificate information produced in a manner such that an address of the mobile node is encrypted with a private key of the host access router.
  • the mobile node In an end-to-end communication, this configuration enables minimizing the number of tunnels and the size of a routing header to cut down the cost of a network and establishing an optimized route promptly in a high-security condition.
  • the mobile node according to the present invention further comprises: means for, at the generation of the packet, setting a destination address of a tunnel header, in which a data packet is encapsulated, as an address of the host access router in the nested state; and means for, at the addition of the certificate information, setting, in the tunnel header, a router alert option including the certificate information produced in a manner such that the address of the mobile node is encrypted with the private key of the host access router.
  • the mobile node according to the present invention further comprises means for transmitting a message including at least an address of the mobile node to the host access router to make a request to the host access router for the production of the certificate information.
  • an access router locatable on a route between a host access router in the nested state and a mobile mode connectable under a network in the nested state comprising: means for receiving a packet; means for checking whether or not a router alert option including certificate information produced in a manner such that an address of a predetermined mobile node is encrypted with a private key of the host access router in the nested state is set in the received packet; means for, whenthe router alert option exists , extracting the certificate information to decrypt it with a public key of the host access router; means for, when the decryption of the certificate information reaches success, extracting the address of the mobile node from the certificate information; means for storing a source
  • an access router locatable on a route between a host access router in the nested state and a mobile mode connectable under a network in the nested state comprising: means for receiving a packet; means for, when a destination address of the received packet is an address of the access router itself, checking whether or not a routing header is added to the packet; means for storing a routing table describing an entry registered in a state where a specified value and a next hop address are associated with each other; means for, when the routing header is added to the packet, extracting a value of the routing header and referring to the routing table
  • a host access router in the nested state comprising: means for receiving a packet; means for checking whether or not a router alert option including certificate information produced in a manner such that an address of a predetermined mobile node is encrypted with a private key of the host access router itself is set in the received packet; means for, whenthe router alert option exists, extracting the certificate information to decrypt it with a public key of the host access router itself; means for, when the decryption of the certificate information reaches success, extracting the address of the mobile node from the certificate information; and means for storing a source address of the received packet as a next hop address in a state associated with the address of the mobile node.
  • a host access router in the nested state comprising: means for receiving a packet; means for making a judgment as to whether or not the received packet is a packet to be transferred to a mobile node connected under a network in the nested state; means for storing a routing table describing an entry- registered in a state where a specified value and a next hop address are associated with each other; means for, when the judgment shows that the received packet is a packet to be transferred to the mobile node, encapsulating the packet into a tunnel header; means for selecting the next hop address from the routing table so that appropriate transfer takes place
  • this configuration enables minimizing the number of tunnels and the size of a routing header to cut down the cost of a network and establishing an optimized route promptly in a high-security condition.
  • the present invention has the above-described configurations and provides an advantage of, in an end-to-end communication, minimizing the number of tunnels and the size of a routing header to cut down the cost of a network and establishing an optimized route promptly in a high-security condition.
  • the present invention can realize the reduction of a routing path, the reduction of hand-off delay and the reduction of signaling in a network between a mobile node which is in a deeply nested state in a mobile network and a correspondent node while maintaining a secure route for the MN.
  • FIG. IA is a message sequence chart showing the concept of a preferred embodiment of the present invention.
  • FIG. IB is a general view showing a configuration of a network concerning the message sequence chart shown in FIG. IA.
  • FIG. 1C is an illustration of one example of the contents contained in a packet involving the message sequence chart shown in FIG. IA.
  • FIG. 2 is an illustration of one example of a routing cache according to an embodiment of the present invention.
  • FIG.3 is a message sequence chart showing a first example of signaling between a VMN and a CN according to a preferred embodiment of the present invention.
  • FIG.4 is amessage sequence chart showing a second example of signaling between a VMN and a CN according to a preferred embodiment of the present invention.
  • FIG.5A is amessage sequence chart showing a third example of signaling between a VMN and a CN according to a preferred embodiment of the present invention.
  • FIG. 5B is an illustration of one example of the contents included in a packet involving the message sequence chart shown in FIG. 5A.
  • FIG. 6A is a message sequence chart showing a fourth example of signaling between a VMN and a CN according to a preferred embodiment of the present invention.
  • FIG. 6B is an illustration of one example of the contents included in a packet involving the message sequence charts shown in FIGs . 6A and 7.
  • FIG.7 is amessage sequence chart showing a fifth example of signaling between a VMN and a CN according to a preferred embodiment of the present invention.
  • FIG. 8 is an illustration of one example of a functional architecture of a MN according to an embodiment of the present invention.
  • FIG. 9 is an illustration of one example of a functional architecture of a MR according to an embodiment of the present invention.
  • FIG. 10 is a flow chart showing one example of processing in a MR (processing to be conducted when a MR is not a TLMR) according to an embodiment of the present invention.
  • FIG. 11 is a flow chart showing one example of processing in a MR (processing to be conducted when a MR is a TLMR) according to an embodiment of the present invention.
  • FIG. 12A is a message sequence chart showing a sixth example of signaling between a VMN and a CN according to a preferred embodiment of the present invention.
  • FIG.12B is an illustration of one example of the contents included in a packet involving the message sequence chart shown in FIG. 12A.
  • FIG. 13 is an illustration of one example of a packet format according to an embodiment of the present invention.
  • FIG.14 is an illustration of a configuration of a network according to an embodiment of the present invention and an illustration of a case in which two VMNs exist within a NEMO network, which is in a nested state.
  • FIG. IA is an illustration of a message sequence chart (MSC) of the concept of an embodiment of the present invention.
  • FIG. IB is a general view showing a configuration of a network involving the message sequence chart shown in FIG. IA.
  • FIG. 1C is an illustration of one example of the contents contained in several packets to be transmitted in the message sequence shown in FIG. IA.
  • FIG. 1C shows one example of the contents of packets 10OA, 10OB, IOOC and IOOD to be transmitted from a VMN 10, an MR 20, an MR 21 and a TLMR 30 through a data packet path 100, respectively, one example of the contents of packets 101A, 101B, IOIC and 101D to be transmitted from a CN 40, the TLMR 30, the MR 21 and the MR 20 through a data packet path 101, respectively, and one example of the contents of packets
  • the visiting mobile node (VMN) 10 is in a deeply nested state (multiple nesting condition) under the MR 20, the MR 21 and the TLMR (Top Level Mobile Router) 30, and it makes a route-optimized data communication with the CN 40 through the use of data packet paths 100 and 101 (which sometimes will be referred to simply as paths 100 and 101) according to a method involving the present invention. As shown in FIG. IA, the visiting mobile node (VMN) 10 is in a deeply nested state (multiple nesting condition) under the MR 20, the MR 21 and the TLMR (Top Level Mobile Router) 30, and it makes a route-optimized data communication with the CN 40 through the use of data packet paths 100 and 101 (which sometimes will be referred to simply as paths 100 and 101) according to a method involving the present invention. As shown in FIG.
  • the VMN 10 the MR 20, the MR 21 and the TLMR 30 are connected in series and, for example, the MR 20 and the VMN 10 exist under the MR 21 (the VMN 10 is also under the MR 20 and under the MR 21), and the MR 21 itself exists under the TLMR 30.
  • the VMN 10 is also under the MR 20 and under the MR 21
  • the MR 21 itself exists under the TLMR 30.
  • a connected state of a plurality of MRs i.e., the MR 20, the MR 21 and the TLMR 30, is referred to as a nested state and, in this case, a packet to be transmitted between the VMN 10 and the CN 40 existing in a global communication network 50 is subj ected to multiple tunneling or it is transmitted through a redundant route passing through an HA of each MR.
  • a packet to be transmitted between the VMN 10 and the CN 40 existing in a global communication network 50 is subj ected to multiple tunneling or it is transmitted through a redundant route passing through an HA of each MR.
  • a router having no mobility function intervenes between the MR 20 and the MR 21
  • the CN 40 side (global communication network 50 side) will be referred to as upstream side
  • the VMN 10 side will be referredto as downstream side
  • the direction from the CN 40 to the VMN 10 will be referred to as a forward direction
  • the direction from the VMN 10 to the CN 40 will be referred to as a reverse direction.
  • a MR existing on the upstream side with respect to a certain node will be referred to as an upstream side MR while an MR existing on the downstream side with respect to the certain node will be referred to as a downstream side MR.
  • a mobile router signifies a movable router having a packet transferring function (routing function) while amobile node wholly signifies movable communication apparatus including a mobile router and a mobile host.
  • a route update according to the present invention takes place in a data transmission (path 100) from the VMN 10 to the CN 40.
  • a parameter (s) needed for the route update is appended to a tunnel header related to the path 100.
  • An inner packet embedded in the interior of this tunnel header is a data packet to the CN 40.
  • a route update mechanism is combined or integrated with a data packet transmission.
  • each MR can transfer a packet using an updated route instead of carrying out the tunneling to its HA.
  • the combination of the data packet transmission and the route updating is useful in a case in which the VMN frequently changes the topology or when the VMN does not receive the advertisement on the mobility of the upstream side MR.
  • the VMN 10 transmits a ping packet (ping packet for the route update) specified in the ICMP (Internet Control and Management Protocol) to the TLMR 30.
  • a ping packet ping packet for the route update
  • ICMP Internet Control and Management Protocol
  • FIG. IA the transmission of this ping packet is shown in the route update ping packet 102.
  • the above-mentioned LCoA of the VMN 10 is acquired (configured) from the prefix of the MR 20.
  • IA is based on the assumption that the VMN 10 already reveals its own CoA securely to the CN 40 prior to the data transmission through the path 100. At this time, for example, it is preferable to employ signaling such as an- RR (Return Routability) test, a BU (Binding Update) or the like.
  • signaling such as an- RR (Return Routability) test, a BU (Binding Update) or the like.
  • the CoA to be revealed by the VMN 10 to the CN 40 is the CoA of the TLMR 30 or an address of the VMN 10 (corresponding to the RCoA of the VMN 10) configured using the same prefix as the prefix the TLMR 30 possesses (TLMR egress address prefix or the prefix delegated to TLMR by the access router directly attached to TLMR) .
  • This CoA is an unique address the CN 40 seizes, which allows the route optimized arrival at the VMN 10. Basically, the CN 40 does not have the information on the addresses of the upstream side MRs such as the MR 20, the MR 21 and the TLMR 30.
  • the VMN 10 In a case in which the VMN 10 tries to transmit a data packet to the CN 40 to which it has already conducted the RR and BU signaling, it encapsulates the data packet in a single tunnel having tunnel header parameters.
  • the source address is a CoA of the VMN 10 and the destination address is an address of the CN 40, and the HoA of the VMN 10 is included in a home address destination option.
  • the source address of the outer tunnel header becomes a local care-of address (LCoA) of the VMN 10.
  • LCoA local care-of address
  • This LCoA of the VMN 10 is configured using the prefix of the MN 20.
  • the destination address of the tunnel header becomes an address of the TLMR 30.
  • the address of the TLMR 30 is, for example, a CoA of the TLMR 30 or a HoA of the TLMR 30, there is a case in which it is preferable to use one of the CoA of the TLMR 30 than the HoA of the TLMR 30 as mentioned later.
  • the tunnel header includes a hop-by-hop option referred to as a router alert option (RAO) and appended to a hop-by-hop extension header.
  • RAO router alert option
  • IANA Internet Assigned Numbers Authority
  • the aforesaid RAO includes key parameters inserted by the VMN 10 so that the upstream side MRs can establish a secure route .
  • Two keyparameters involving the RAO are, for example, a certificate produced by the TLMR 30 and an encrypted hash value.
  • the certificate issued by the TLMR 30 is generated by combining a public key and the ID of the VMN 10 and further encrypting it with a private key of the TLMR 30.
  • this VMN_ID is, for example, a HoA of the VMN 10 or an address (CoA of the VMN 10) configured by the VMN 10 on the basis of the prefix the TLMR 30 possesses (TLMR egress address prefix or the prefix delegated to TLMR by the access router directly attached to TLMR) .
  • the ID of the VMN 10 is produced on the basis of the prefix of the TLMR 30, it becomes an address to be used as a CoA of the VMN 10 at the communication with the CN 40.
  • the TLMR 30 issues a certificate to the VMN 10.
  • the TLMR 30 verifies the proprietary right of the predetermined VMN_ID and then provides the aforesaid certificate.
  • the VMN 10 gets this certificate, the VMN 10 decrypts the certificate through the use of the public key (the VMN 10 seizes) of the TLMR 30, thereby enabling the verification as to whether or not the TLMR 30 has created the certificate.
  • the VMN 10 starts the RR test, the BU, the route update mechanism and the optimized data communication 100.
  • the VMN 10 produces an encrypted hash value by using tunnel parameters, which does not undergo a change.
  • the source address of the tunnel header is changed.
  • the VMN 10 can produce a hash value.
  • This hash value is encrypted using the private key of the VMN 10 and is appended as a field in an option to the RAO.
  • the first parameter of the RAO (i.e., the certificate) of the tunnel header can be decrypted by the upstream side MRs.
  • the public key of the TLMR 30 can be set statically in a MR and a VMN, or it can also be distributed through a router advertisement (RA) according to a secure method.
  • RA router advertisement
  • the TLMR 30 can encrypt this public key through the use of a given key Kl and put the encrypted public key as an option into the RA.
  • This key Kl is offered to a VMN and MR in a nested NEMO network by a reliable third party according to a secure method.
  • intermediate MRs can decrypt the value of the encrypted public key through the use of the key Kl.
  • the intermediate MRs can acquire the public key of the TLMR 30 so as to further relay the value of the encrypted public key through the use of its own RA.
  • the value of the public key also changes.
  • the normal decryption of the certificate given by the original TLMR 30 becomes impossible, so the VMN 10 does not start a route updatemechanism, which allows the route update of the VMN_ID.
  • the MR 20 when the MR 20 detects a tunnel packet at its own ingress interface, it first verifies the validity of the certificate in the RAO in the tunnel header . If the certificate is valid, then the decryption of the certificate using the public key of the TLMR 30 reaches success . When the decryption reaches success, the MR 20 can acquire the public key of the VMN 10, which was also used to produce the certificate generated by TLMR 30.
  • the VMN 10 describes an encrypted hash value in the tunnel header and, if the MR 20 can again generate the decrypted hash value from the field of the tunnel header, then this demonstrates that the tunnel packet is actually sent by the VMN 10 associated with the VMN_ID existing in the certificate .
  • the MR 20 first decrypts the hash in the RAO through the use of the public key of the VMN 10.
  • the public key of the VMN 10 is obtainable by decrypting the certificate.
  • the hash value is used for the upstream side MRs to test the authenticity (validity) of the VMN 10. If the attacker produces a false hash value, since the hash value offeredby the attacker cannot be decrypted by the public key of the VMN 10, the upstream side MRs can easily seize the false hash value.
  • the verification of the VMN_ID is made by only the TLMR 30, and all the upstream side MRs verify that the two parameters in the RAO have basically been produced by the right nodes (TLMR and VMN) .
  • all the MRs trust that the TLMR 30 verifies the proprietary right of the VMN_ID of the VMN 10 and, if the route update parameters have been issued from the TLMR 30, then it merely creates a route.
  • the route update packet shows that this route update packet has been sent from a node, which needs the route, update.
  • the VMN 10 is mounted in a movable vehicle and is in a connection with the TLMR 30 in this vehicle for a long term.
  • the relationship in trust is necessary between the TLMR 30 and the VMN 10 and, for example, the trust and distribution of the public key of the TLMR 30 relative to the VMN 10 can be made statically in advance .
  • the MR 20 After the verification of the aforesaid two parameters, the MR 20 establishes a new route update on the VMN_ID in a new routing cache.
  • the entry of the new route update in the MR 20 becomes a next hop address for the arrival at the VMN_ID and, in this case, for example, it becomes an LCoA of the VMN
  • an address which can become the next hop address, is an LCoA of the VMN 10 or a tunnel source address.
  • the MR 20 After the establishment of the aforesaid route with respect to the VMN_ID, the MR 20 merely replaces the source address of the tunnel header with its own LCoA (produced using the prefix of the MR 21) , and a packet where the source address of the tunnel header is the LCoA of the MR 20 is transmitted from an egress interface of the MR 20.
  • the MR 20 After the verification of the RAO parameters and after the establishment of a secure route which enables the arrival at the VMN_ID, the MR 20 has a valid route which enables the arrival at the VMN ID, which allows a person skilled in the art to understand that the tunneling is avoidable.
  • the MR 20 changes the source address of the tunnel header to its own LCoA so as to avoid the ingress filtering in routers within an access network, and further transfers a packet through a default router.
  • a route update verification mechanism takes place as well as the case mentioned above.
  • the MR 21 produces a route to the next hop so as to enable the arrival at the VMN_ID of the VMN 10.
  • the address of the next hop in the MR 21 becomes a local care-of address (LCoA) of the MR 20.
  • the MR 21 changes the source address of the tunnel header to its own LCoA.
  • FIG. 2 shows a new routing cache in a MR in a case of establishing a route verifiedwith respect to one ormore VMN_ID.
  • a decapsulated packet in the TLMR 30 is produced on the basis of the VMN_ID of the VMN 10 and is the same as an inner packet encapsulated into a tunnel by the VMN 10.
  • This data packet is usually sent by use of a routing mechanism according to the IPv6 so as to reach the CN 40.
  • the route for the data packet to be transmitted from the CN 40 to the VMN 10 becomes the data packet path 101 shown in FIG. IA.
  • the packet destination address is the CoA of the VMN 10
  • the packet source address is the CN 40 destination
  • the RH2 is set so as to contain the HoA of the VMN 10.
  • This packet is transmitted with the care-of address of the TLMR 30 being set as a destination, or in a case in which the CoA of the VMN 10 is derived from the prefix of the TLMR 30 that was explained previously, it is received (intercepted) by the TLMR 30.
  • the TLMR 30 encapsulates this packet with a tunnel header and carries out first-stage tunneling.
  • This tunnel source address becomes an address of the TLMR 30, and the destination address becomes a next hop address, which allows the arrival at the VMN_ID.
  • the TLMR 30 acquires the next hop address by using the value of the RH2 (HoA of the VMN 10) or using a destination address (i.e., the CoA of the VMN 10) of a packet received by the egress interface.
  • the TLMR 30 retrieves the routing cache shown in FIG.2 to acquire a next hop address corresponding to the VMN__ID.
  • the TLMR 30 uses the RH2 to search the next hop address (the destination address of the tunnel header) .
  • the TLMR 30 searches the next hop address by using the CoA of the VMN 10 or a destination address of a packet produced in the CN 40.
  • the TLMR 30 uses the acquired next hop address as a destination address of the tunnel header. At this time, the TLMR 30 acquires the LCoA of the MR 21 as the next hop address and sets this LCoA of the MR 21 as a destination address of the tunnel header.
  • the RH2 into which the VMN_ID is inserted is included in the tunnel header. In this connection, since the RAO increases the processing load of the legacy fixed router, it is preferable that the RH2 rather than the RAO is used for the storage of the VMN_ID. In the case of the employment of the RH2, the legacy router does not carry out the inspection on these packets .
  • the MR 21 inspects the RH2 within the tunnel. Still moreover, the MR 21 checks its own routing cache to acquire the next hop address concerning the VMN_ID contained in the RH2. After the acquisition of this next hop address (the LCoA of the MR 20) , the MR 21 replaces the destination address with the LCoA of the MR 20 and sends the packet to the correct interface. Yet moreover, also in the MR 20, a similar destination address replacement mechanism is employed, so the packet finally reaches the VMN 10.
  • the VMN 10 changes the TLMR 30, there is a need to update the CoA of the VMN 10 to the CN 40. Therefore, according to this method, the VMN 10 (the VMN 10 which is moving under the TLMR 30) which does not change the TLMR 30 is not particularly required to update a new CoA, and a local mobility management mechanism is realizable.
  • FIG. IA shows the data packet path for the route update ping packet.
  • the LCoA of the VMN 10 is set as the source address of the route update ping packet to be transmitted from the VMN 10
  • the address of the TLMR 30 is set as the destination address.
  • the RAO (the same RAO as that for the tunnel packet on the above-mentioned path 100) including the certificate and the hash value is set with respect to the route update ping packet.
  • This route update ping packet does not contain the contents of a valid message (i.e., NULL).
  • each of the MR 20 and the MR 21 upon receipt (intercept) of the route update ping packet, each of the MR 20 and the MR 21 records the association between the VMN_ID in the RAO and the next hop address in a new route update entry in the routing cache, and it replaces the source address of the route update ping packet with its own address (the LCoA of the MR 20 and the LCoA of the MR 21) and carries out the packet transfer.
  • the route update ping packet is useful, for example, in a case in which the route update is conducted when no data packet is transmitted.
  • the embodiment is described with reference to FIG. IA on the assumption that there is no need to change the HA of the VMN 10 fromthe standards.
  • the HA of the VMN 10 conducts an operation slightly different from the standards (that is, improving the HA of the VMN 10) and inserts the RH2 into the tunneling data packet, thereby enabling the packet coining to the VMN 10 from the legacy IPv6 type CN 40 to reach the VMN 10 through a more optimized path.
  • FIG. 3 shows signaling between the VMN 10 and the CN 40 in a preferred embodiment of the present invention.
  • FIG. 3 is an illustration of a message sequence chart indicating -events needed for establishing a secure route for a VMN in a nested NEMO network in a case in which the VMN 10 merely moves into the nested NEMO network (the TLMR 30 as a root) .
  • the VMN 10 After the movement into the nested NEMO network, the VMN 10 receives an RA 300 fromthe MR 20, which is a router, connected thereto.
  • This RA 300 reliably contains the prefix of the MR 20, thereby enabling the VMN 10 to configure the LCoA thereof.
  • the RA 300 there is a need for the RA 300 to contain the identifier of the TLMR 30. As this identifier, it is preferable to use one of the HoA of the TLMR 30, the public key of the TLMR 30 and the prefix of the TLMR 30 preferably obtained from the home network of MR.
  • the VMN 10 can grasp whether the VMN 10 still exists under the same TLMR 30 or it has moved under a different TLMR and, in this respect, this identifier is important.
  • the RA 300 contains the CoA of the TLMR 30 or the prefix of the TLMR 30.
  • the prefix of the TLMR 30 (or the prefix of the CoA of the TLMR 30) is used for configuring the CoA of the VMN 10, and the configured CoA of the VMN 10 can be advertised to the CN 40.
  • all the above-mentioned parameters can be inserted as an option into the RA 300.
  • the parameters intheRA300, relatedto theTLMR30 are information originally transmitted from the TLMR 30 through an RA.
  • the downstream side MRs basically relays, as its own RA option, these parameters (for example, information contained in the RA from the upstream side MRs (including the TLMR 30) ).
  • the identifier of the TLMR 30 is the same as that before the movement, then there is no need to make a request for acquiring the certificate about the VMN_ID from the TLMR 30. On the other hand, if the identifier of the TLMR 30 is different there from, then this request becomes necessary, thus conducting the processing shown in FIG. 3.
  • the VMN 10 Upon the acquisition of the RA 300, the VMN 10 discovers a new TLMR 30 and first tries to transmit a request (sign request message for the registration of an ID) 301 to the newly discovered TLMR 30 and then makes a request to the TLMR 30 for the production of a certificate on the VMN_ID.
  • This sign request message 301 is transmittable to the CoA or HoA of the TLMR 30.
  • this sign request message 301 contains the ID of the VMN 10. The details of this sign request message 301 will be mentioned later.
  • the upstream side MR 20 tunnels this sign request message 301 through its own HA.
  • the TLMR 30 verifies the validity of the VMN_ID of the VMN 10 (mentioned later) . If this verification reaches success, then the TLMR 30 produces a certificate as mentioned above and transmits this certificate to the VMN 10 as indicated by a sign request response message 302.
  • the address of the VMN 10 is an arbitrary reachable address, for example, the HoA of the VMN 10, a local care-of address (LCoA) of the VMN 10 configured on the basis of the prefix notified from the MR 20, or the like.
  • this sign request response message 302 passes through the HA of the MR 20 prior to the arrival at the VMN 10.
  • an RR test signaling 303 is conductedbetween the VMN 10 and the CN 40, and a BU 304 is transmitted from the VMN 10 to the CN 40.
  • FIG. 3 shows a single session with one CN 40 for simplicity and clarity only.
  • all the upstream side MRs employ the NEMO basic mechanism disclosed in the Non-Patent Document 2 so as to send these signaling packets through the corresponding HAs.
  • the VMN 10 engages in the RR signaling as well as the BU, then the VMN 10 uses the CoA of the TLMR 30 or an address, configured on the basis of the prefix of the TLMR 30 (prefix of TLMR care of address) , as its own CoA at the binding to the CN 40. After the binding to the CN 40 reaches success, the VMN 10 transmits a data packet to the CN 40. In this case, the above-mentioned secured route update mechanism is incorporated into the data packet.
  • the MR 20 and the TLMR 30 can establish a secure route which enables the arrival at the VMN_ID related to the VMN 10. Moreover, through this secure route, an encapsulated data packet is tunneled to the HA of an MR or the HA of a TLMR. Still moreover, in like manner, the data packet from the CN 40 to the VMN 10 becomes reachable according to an optimum way.
  • a packet structure in the CN 40 is made such that the TLMR 30 carries out the packet verification without violating regulations defined in the standards. Following this, in a common case, the TLMR 30 encapsulates the data packet so that the packet immediately reaches the VMN 10 without passing through the HA of the MR on the upstream side with respect to the VMN 10. Moreover, the tunnel header of the tunnel packet 306 from the CN 40 to the VMN 10 has a key element (the VMN_ID in the RH2) . Thus, each MR can discover a next hop address, which enables the arrival at the VMN 10. Upon the discovery of the next hop address, the TLMR 30 and, similarly, the MR 20 change the destination address to the next hop address. In the forward direction, the TLMR 30 inserts the tunnel packet 306. Owing to the secure route update in a nested NEMO network, the packet sent from the CN 40 can easily reach that destination in a deeply nested state via the most optimized route.
  • FIG. 4 shows a case in which the VMN 10 discovers that the identifier of the TLMR 30 received from the RA 300 is the same as that received before.
  • the VMN 10 there is no need for the VMN 10 to carry out the sign request signaling with respect to the TLMR 30 and further to conduct the RR and BU signaling with respect to the CN 40.
  • the reason why there is no need to carry out the RR and BU signaling is that, when the TLMR 30 is the same without changing irrespective of the movement of the VMN 10, no change of the CoA of the VMN 10 to be offered to the CN 40 occurs. Let us assume that a data flow from the VMN 10 to the CN 40 exists .
  • the VMN 10 constructs a packet and encapsulates this packet into a tunnel header previouslyput to use.
  • This tunnel header includes a RAOhaving a certificate and a hash value.
  • a route is configured with respect to the MR 20 and the TLMR 30.
  • the packet from the VMN 10 passes through a data packet path 320 and easily reaches the CN 40.
  • the VMN 10 transmits a route update ping packet 322 to the TLMR 30. This route update ping packet 322 is not subjected to tunneling.
  • this route update ping packet 322 is the LCoA of the VMN 10 and the destination address thereof is the address of the TLMR 30. Moreover, the route update ping packet 322 includes a RAO having a certificate and a hash value. This route update ping packet 322 does not contain contents (that is, NULL message) .
  • the MR 20 Upon receipt of this route update ping packet, the MR 20 performs the route update as needed and changes the source address ofthis routeupdatepingpacketto its LCoA. Moreover, the TLMR 30 also conducts similar processing. After the start of the data packet transmission, there is no need to transmit such a route update ping packet. In a case in which the information on the movement of the upstream side MRs is not notified to the VMN 10, the VMN 10 is required to transmit the route update ping packet with a high frequency (i.e., at a short packet interval) .
  • the VMN_ID can be the HoA of the VMN 10 and the CoA of the VMN 10 to be advertised to the CN 40.
  • This said CoA can also be the CoA of the TLMR 30 (this CoA of the TLMR 30 is configured on the basis of the prefix of a host access router with respect to the TLMR 30) .
  • FIG. 5A is a message sequence chart in the case of using parameters on the VMN_ID and the CoA of the VMN 10 according to a preferred embodiment of the present invention.
  • the VMN 10 is in a nested state under the MR 20 and the TLMR 30.
  • the HA 35 is a home agent of the VMN 10.
  • the VMN 10 merely moves into a NEMO network existing under the TLMR 30 and the VMN 10 establishes a data session with respect to the CN 40.
  • the CN 40 is a CN where the MlPv ⁇ is workable.
  • the CoA of the TLMR 30 is not advertised as the CoA of the VMN 10 to the HA 35. Instead, the LCoA of the VMN 10 is notified as the CoA of the VMN 10 to the HA 35.
  • This LCoA of the VMN 10 is obtained on the basis of the prefix of its access router. This is based on a specified reason. For example, let it be assumed that the CoA of the TLMR 30 is given to the HA of the VMN 10 and a legacy CN (IPv6) 40 transmits a packet to the HoA of the VMN 10.
  • IPv6 legacy CN
  • the TLMR 30 cannot obtain the VMN_ID of the VMN 10 (HoA of the VMN 10) .
  • ESP encapsulation security payload
  • the present invention is useful only for the communications between the VMN 10 and the CN 40 where the MlPv ⁇ is workable.
  • the legacy encapsulation security payload
  • CN 40 is capable of transmitting a packet to the VMN 10, which is in a nested state. In this case, although it is reachable to the VMN, the path has a long and distorted configuration.
  • the VMN 10 requires the CoA of the TLMR 30, the prefix of the MR 20 and some identifier of the TLMR 30. Moreover, in a case in which the public key of the TLMR 30 is not set statically in advance, it is also possible that the public key of the TLMR 30 is appended to the RA 401 so as to use it as the identifier of the TLMR 30. On the other hand, in a case in which the public key of the TLMR 30 is set statically in the VMN 10 in advance, it is also acceptable that the HoA of the TLMR 30 is transmitted as the identifier of the TLMR 30 through the use of the RA 401.
  • the VMN 10 When acquiring this RA 401, the VMN 10 configures its own LCoA on the basis of the prefix of the MR 20 transmitted through the use of the RA 401. After the configuration processing, the VMN 10 first transmits an MlPv ⁇ -based BU 402 to the HA 35. This BU transmission step is necessary for enabling the legacy CN (IPv6) to reach the VMN 10 and for setting up a route according to the present invention.
  • IPv6 legacy CN
  • a BU packet is encapsulated in the MR 20 and the TLMR 30 and transmitted to each of the corresponding HAs. These events are omitted from illustration for simplicity.
  • the HA 35 accepts this BU and transmits a response thereto through the use of a BA 403.
  • the VMN 10 tries to acquire a certificate about the VMN_ID (the HoA of the VMN 10) from the TLMR 30.
  • the VMN 10 is required to prove that it is the true owner of this address. Accordingly, for example, the VMN 10 uses a mechanism similar to home address test verification in the RR processing. This processing uses the present processing and parameters or options answering the purpose.
  • the VMN 10 configures a sign request message.
  • This message is a home test initiation (HoTI) message 404.
  • This HoTI message can include, as options, the public key of the VMN 10 and a home address test cookie (random number) .
  • the HoA of the VMN 10 and the CoA of the TLMR 30 are set as the source address of the HoTI message 404 and the destination address thereof, respectively. Formaintaining firm security while enabling the passage of ingress filtering in an access network, the VMN 10 encapsulates this HoTI message 404 into a tunnel directed to its own HA.
  • the source address of the tunnel is the LCoA of the VMN 10 (obtainable using the prefix of the MR 20) while the destination address thereof is the address of the HA 35.
  • the tunneling of the HoTI message 404 is not shown in FIG. 5A, it is obvious to a person skilled in the art. In an operation according to the standards, all the upstream side MRs perforin the tunneling for this encapsulated HoTI message 404 through the corresponding HAs. After the encapsulation in the HA 35, an HoTI message 405 transferred from the HA 35 reaches the CoA of the TLMR 30.
  • the TLMR 30 trusts the security of the infrastructure of the internet, which allows the production of the above-mentioned certificate in a state where the HoA of the VMN 10 is set as a valid home address.
  • a home test (HoT) message 406 shown in FIG. 5A becomes a response to the sign request message.
  • this HoT message 406 includes a certificate as an option as well as the cookie transmitted before.
  • This HoT message 406 has a source address by use of the CoA of the TLMR 30, and the HoA of the VMN 10 is set as the destination address.
  • This HoTmessage 406 arrives at the HA 35 where it is encapsulated in a tunnel, and then it reaches the LCoA of the VMN 10. After passing through the HAs of all the upstream side MRs, this packet is sent to the VMN 10. This is omitted from the illustration for simplicity of description only.
  • the HoTI message 404 is transmitted to the home address of the TLMR 30 in order to increase the reliability (validity) of the HoA of the VMN
  • the TLMR 30 can transmit the
  • HoT message 406 by use of its own home address as the source address, so the packet is tunneled via the HA of the TLMR 30.
  • the VMN 10 is required to seize not only the CoA of the TLMR 30 but also the HoA of the TLMR 30.
  • the public key of the VMN 10 to be transmitted through the use of the HoT message 406 is encrypted with the public key of the TLMR 30. This can provide more reliable security.
  • this packet is doubly encapsulated in the VMN 10.
  • the source address of the innermost packet in this HoTI message 408 is the HoA of the VMN 10
  • the destination address thereof is the address of the CN 40.
  • the source address of the next tunnel is the LCoA of the VMN 10 and the destination address thereof is the address of the HA 35.
  • the source address is the LCoA of the VMN 10 and the destination address is the CoA of the TLMR 30.
  • the outermost tunnel includes a RAO having a certificate and a hash value.
  • the MR 20 When this packet is sent to the MR 20, the MR 20 creates a relevant route to the HoA of the VMN 10 (that is, it changes an entry of- the routing cache) and changes the source address of the outermost tunnel to its own CoA and then sends the packet .
  • this HoTI message 408 reaches the TLMR 30, the TLMR 30 updates the route to the VMN_ID of the VMN 10 and decapsulates the packet.
  • the TLMR 30 conducts the decapsulation by one level and then tunnels the packet to the HA of the TLMR 30.
  • the source address of this tunnel header becomes the CoA of the TLMR 30.
  • this packet arrives at the CN 40.
  • a care-of test init (CoTI) 411 is producible using a single tunnel in the VMN 10. This is shown in FIG. 5A.
  • the outer tunnel can be used to create routes in the upstream side MRs.
  • the source address of the inner CoTI packet is the CoA of the VMN 10, which is the CoA of the TLMR 30.
  • the source address of the outer tunnel is the LCoA of the VMN 10 as usual.
  • a care-of test (CoT) message 413 is transmitted from the CN 40 to the VMN 10
  • this CoT message 413 directly arrives at the CoA of the TLMR 30.
  • the TLMR 30 is required to check the care-of init cookie.
  • the aforesaid care-of init cookie is offered from the VMN 10 through the HoTI message 405 to the TLMR 30.
  • FIG.5Adoes not explicitly illustrate a detailed structure of a CoT packet and a path through which a packet passes, a person skilled in the art can easily predict it.
  • the CoT message directly arrives at the TLMR 30 and, in the TLMR 30, it is encapsulated in a signal tunnel so as to enable the arrival at the VMN 10.
  • an HoT message 414 sent from the CN 40 is transmitted toward the HoA of the VMN 10.
  • This HoA message 414 arrives at the HA 35, and the HA 35 encapsulates this HoT message 414 in a tunnel addressed to the LCoA of the VMN 10.
  • the packet is delivered to pass through the HA of the MR 20 and the HA of the TLMR 30 and reach the CoA of the TLMR 30. After the passage of such long and distorted paths, the multiple encapsulation and decapsulation, the packet reaches the VMN 10.
  • the advantages of this scenario in a case in which a data packet reaches the VMN 10 after the transmission from the CN 40 are as follows.
  • the destination address of the data packet is the CoA of the TLMR 30 and the data packet has a formation where the HoA of the VMN 10 is included in the RH2.
  • the TLMR 30 can inspect the RH2 to acquire the VMN_ID.
  • the TLMR 30 can check the routing table to find the next hop address. Therefore, without tunneling, the packet can be sent in a state where the destination address thereof is replaced with the LCoA of the MR 20.
  • the source address is the address of the CN 40 and the destination address is the CoA of the MR 20, and the received packet has the RH2 containing the HoA of the VMN 10.
  • the source address is the address of the CN 40 and the destination address is the CoA of the VMN 10, and the received packet has the RH2 containing the HoA of the VMN 10.
  • This mechanism is operable even in a case in which the CN 40 uses IPSec at the transmission of a packet to the VMN 10.
  • this packet passes through paths 416 and 417. This denotes a configuration similar to the path mentioned above. In the case of passing through the message path 415 as mentioned above, it is possible to realize an extremely optimized path without employing an extended routing header or tunneling.
  • a description will be given herein below of a case in which a VMN_ID is obtainable on the basis of a prefix of the TLMR 30. This value is offered as a care-of address of the VMN 10 to the CN 40 where the MlPv ⁇ is workable and the HA of the VMN 10. This is a different scenario where the present invention is applicable.
  • the different preferred embodiment of the present invention will be described herein below with reference to FIGs, 6A and 7.
  • FIG. 6B shows one example of the contents contained in several packets to be transmitted in the message sequences of FIGs. 6A and 7.
  • FIG.6B shows one example of the contents contained in a packet (RA packet) 500 to be transmitted from a MR 20 and the contents contained on packets 508, 509 and 510 to be respectively transmitted from a CN (legacy IPv6 CN) 45, an HA 35 and an TLMR 30.
  • FIG. 6B shows one example of the contents contained in a packet 607 to be transmitted from a VMN in FIG. 7.
  • the VMN 10 is in a deeply nested state under the MR 20 and the TLMR 30.
  • the HA 35 is a home agent of the VMN 10.
  • the VMN 10 moves into a nested NEMO network where the TLMR 30 being set as a root and already has a communication session with respect to the CN 45 which is a legacy IPv6 type node (which cannot understand an MlPv ⁇ RO (Route Optimization) mechanism) .
  • an RA 500 includes, as options, the prefix of the TLMR 30, the prefix of the MR 20 and the HoA of the TLMR 30. Moreover, in a case in which the public key of the TLMR 30 is not set in the VMN 10 in advance, the public key of the TLMR 30 is also required to be appended as an option. Still moreover, as the identifier of the TLMR 30, it is also possible to employ the HoA of the TLMR 30.
  • the VMN 10 configures the CoA of the VMN 10 on the basis of the prefix of the TLMR 30, and configures the LCoA of the VMN 10 on the basis of the prefix of the MR 20.
  • the duplicate address-detection is conducted with respect to only the LCoA of the VMN 10 configured using the prefix of the MR 20.
  • the VMN 10 transmits an MlPv ⁇ type BU 501 to its own HA (HA 35) .
  • the source address of this BU 501 is the LCoA of the VMN 10, and the care-of address which is the CoA of the VMN 10 obtainable on the basis of the prefix of the TLMR 30 is inserted into an alternate care-of address option attendant on the BU mobility header.
  • this BU packet is encapsulated in tunnels directed to the respective HAs. These are omitted from the illustrations for simplicity only.
  • the HA 35 produces a BCE on the CoA of the VMN 10 and then transmits a BA 502 to the LCoA of the VMN 10. After the reception of this packet, the VMN 10 initiates a sign request message 503.
  • this sign request message 503 can be configured so as to have a source address equal to the LCoA of the VMN 10 and a destination address equal to the HoA of the TLMR 30.
  • this sign request message 503 contains a new mobility header in which an option is appended as a field.
  • the mobility header option in the VMN 10 for example, there is included the public key of the VMN 10, the cookie and the CoA of the VMN 10 obtainable on the basis of the prefix of the TLMR 30.
  • the upstream side MRs tunnel this packet through the respective HAs.
  • the TLMR 30 carries out the duplicate address detection (DAD) on the CoA of the VMN 10 appended as an option.
  • DAD duplicate address detection
  • the TLMR 30 returns a response (a sign request response message 504) to the LCoA of the VMN 10.
  • the sign request response message 504 is transmitted to the LCoA of the VMN.
  • the VMN 10 knows that the CN 45 is a node of a legacy IPv6 type. Accordingly, when the VMN 10 moves to a nested NEMO network, there is no need for the VMN 10 to carry out the RR or BU type signaling the CN 45 cannot seize. Instead, the VMN 10 can configure a packet so as to realize an optimized route, which enables the arrival at the CN 45.
  • the VMN 10 produces a data packet 505 so as to enable the arrival at the CN 45.
  • This packet is doubly encapsulated in VMN 10.
  • the source address of the outermost tunnel is the LCoA of the VMN 10, and the destination address thereof is set at the HoA of the TLMR 30.
  • a RAO having a certificate and a hash value is appended to the outermost tunnel .
  • the CoA of the VMN 10 is set as the source address of the inner tunnel packet, and the address of the HA 35 is set as the destination address thereof.
  • the HoA of the VMN 10 is set as the source address of the innermost data packet, and the address of the CN 45 is set as the destination address thereof.
  • the outermost tunnel is used in order to establish a valid route with respect to the VMN_ID.
  • the tunneling to the HAs of the upstream side MRs does not take place, and the packet from the VMN 10 can arrive at the CN 45 through an optimized route from the TLMR 30.
  • the data packet has a double tunnel 505 up to the TLMR 30.
  • the MR 20 andtheTLMR30 establish a next hop route, which enables the arrival at the VMN_ID (CoA of the VMN 10) .
  • the TLMR 30 decapsulates the packet and sends the decapsulated packet 506 to the HA of the VMN 10.
  • this packet 507 reaches the CN 45 as shown in FIG. 6A.
  • the encapsulation is made with a single tunnel directed to the TLMR 30.
  • the tunneling is made to the HA of the TLMR 30 and the packet finally arrives at the CN 45.
  • the method to be preferably employed depends upon the situations (for example, the distance between an MR and an HA, traffic conditions and others) at that time.
  • the CN 45 transmits data to the VMN 10
  • the CN 45 produces a packet 508 and this packet 508 arrives at the HA 35.
  • the HA 35 encapsulates this packet in a tunnel directed to the CoA of the VMN 10.
  • the TLMR 30 is a proxy for this address, and this packet 509 arrives at the TLMR 30.
  • the TLMR 30 refers to the destination address of the received
  • the TLMR 30 encapsulates the packet in a tunnel.
  • the source address of a tunnel packet 510 at the ingress interface of the TLMR 30 is the address (HoA) of the TLMR 30, and the destination thereof is the LCoA of the next hop MR 20.
  • the CoA of the VMN 10, which is the VMN_ID is inserted into the RH2 forming a tunnel routing header.
  • a node of the legacy CN 45 can reach the VMN 10 according to an optimized manner without passing through the HAs of the upstream side MRs. Moreover, only one address is inserted into the RH2 in the forward direction of the traffic, and only a simple tunnel produced by the TLMR 30 exists. This is very remote from a solution according to a conventional technique in which there is a possibility of implementation of multiple encapsulations or a solution according to a conventional technique where an extended RH" is employed in a TLMR/MAP so as to enable the arrival at the VMN 10. In comparison with the above-mentioned scenario shown in FIG. 5A, this scenario provides a more optimized route from a legacy CN to a VMN.
  • the LCoA of the VMN 10 is merely notified to the HA of the VMN 10 and the effect is that excessive pinball routing (transfer is made through a plurality of nodes) occurs at the arrival at the VMN 10 which is in a nested state.
  • FIG. 7 shows a case in which the VMN_ID is obtained on the basis of the prefix of the TLMR 30 and the CoA of the VMN 10 is the same as the VMN_ID.
  • the VMN 10 has a data communication session with respect to the CN 40 where the MlPv ⁇ is workable.
  • the signaling streams 600 to 604 are the same as those shown in FIG. 6A.
  • the VMN 10 can start a RR 605 and a BU 606 with respect to the CN 40. These signaling are tunneled to the home agents of the upstream side MRs. This tunnel will be omitted from the illustrations.
  • the CoA to be offered to the CN 40 is the CoA of the VMN 10 obtained on the basis of the prefix of the TLMR 30 (prefix of TLMR care-of address or prefix delegated to TLMR from its attached access router) .
  • the route update mechanism on the VMN_ID can be combined with the RR signaling or the data packet directed to the CN 40.
  • the route update mechanism is combined with the data transmission.
  • the data packet produced in the VMN 10 has a tunnel header where the source address is the LCoA of the VMN 10 and the destination address is the address of the TLMR 30.
  • the source address of the inner packet is the CoA of a VMN while the destination address is the address of a CN, and it has a home address destination option.
  • the MR 20 and the TLMR 30 store the next hop address which enables the arrival at the VMN_ID.
  • a single tunnel exists between the VMN 10 and the TLMR 30.
  • the CN 40 constructs a data packet whose destination address is the CoA of the VMN 10.
  • This packet 609 arrives at the TLMR 30 without undergoing the encapsulation.
  • the TLMR 30 receives (intercepts) this packet 609 and tunnels it.
  • the TLMR 30 inserts the CoA of the VMN 10 in the RH2 of the tunnel.
  • the source address of a tunnel packet 610 becomes the address of the TLMR 30 while the destination address thereof becomes the LCoA of the MR 20.
  • the TLMR 30 retrieves the VMN_ID within the routing table to acquire the next hop address . Likewise, the MR 20 conducts processing similar thereto. In the case of the discovery of the next hop, the MR 20 changes the destination address to the LCoA of the VMN 10.
  • a person skilled in the art would recognize that the use of this type of VMN__ID cannot provide a great useful advantage for the route optimization relative to a CN.
  • no tunnel exists in the forward direction in FIG. 5A in this case, one tunnel exists in the forward direction.
  • FIG.8 is an illustration of a functional architecture of a MN suitable for carrying out the present invention. Referring to FIG.8, a description will be given herein below of a configuration of a MN.
  • a functional architecture 700 of the MN has all software and hardware needed for carrying out the protocols mentioned in the aforesaid embodiments.
  • a functional entity 701 indicates a lower-layer protocol of protocol stack of an OSI (Open System Interconnection) reference model, and it comprises a physical layer, an MAC layer and a logical link control layer.
  • FIG. 8 shows a MN routing layer protocol
  • the higher-layer protocol 709 includes protocols such as a transport layer, a session layer and an application layer.
  • the interaction between the higher-layer protocol 709 and the routing layer protocol 702 is made through an interface 711.
  • the interaction between a lower-layer protocol 701 and the routing layer protocol 702 is conducted through an interface 710.
  • the present invention is realized by improving a routing layer protocol of a MN.
  • a routing layer of a MN in the most general case has an MlPv ⁇ location management (LM) unit 703, a new RO unit 705 for realizing an intra NEMO network in a nested state and a default router list 708 for storing default routers
  • LM MlPv ⁇ location management
  • the MlPv ⁇ location management unit 703 also has an additional binding list (BL) 704 shown in FIG. 8.
  • the MN stores an address of a home agent disclosing the CoA of the MN in the binding list
  • the MN stores the lifetime of this binding cache.
  • the location management unit 703 includes a list of CNs (CNs with which the MN frequently make communications or CNs which are currently in communications and which has a data communication session) the MN classifies as the IPv6 type.
  • the MIPv6 location management unit 703 fulfills a function to transmit a BU packet to the HA of the MN itself and a function to construct a packet to be tunneled via the HA of the MN.
  • This packet structure becomes basically identical to the MIPv6 standards.
  • DR which routes the packet .
  • the information on the default router is given through a signaling interface 714 to the MIPv6 location management unit 703.
  • the MlPv ⁇ location management unit 703 can check a neighbor caches to acquire the MAC address of the default router.
  • the new RO unit 705 and the MlPv ⁇ location management unit 703 interact with each other through the use of a signaling interface 712.
  • the new RO unit 705 is a new routing unit and has a binding list (BL) 706 for storing the addresses of all the CNs for which the route optimizations have already been established and the relevant parameters of the binding caches thereof. Still moreover, the new RO unit 705 has an RR parameter storing section 707 for storing the parameters for an RR test. In the RR parameter storing section 707, there are stored RR-related parameters to be used when the MN constructs a BU to be transmitted to a MIPv6 handling CN.
  • BL binding list
  • the new RO unit 705 fulfills a function to configure a new CoA (for example, CoA of a TLMR or address obtained from a prefixed of the TLMR) different from that configured by the MIPv6 LM unit 703.
  • the new RO unit 705 has a function to, in the case of the discovery of a new TLMR, conduct the processing on the transmission of a sign requestmessage to the TLMR 30 and carry out the processing on a sign request response message.
  • the new RO unit 705 has a function to initiate a RR and a BU between CNs classified as handling the MlPv ⁇ or between CNs non-classified. Yet additionally, this new RO unit 705 has a function to carry out the processing on the construction of a data packet (data packet to be transmitted to a CN where the implementation of RR and BU signaling has already reached success) containing an appropriate tunnel introduction and others. In a case in which the new RO unit 705 constructs a data packet directed to a CN handling the MIPv6, the location management unit 703 hands over the LCoA through the signaling interface 712 to the new RO unit 705.
  • the new RO unit 705 conducts this processing.
  • the new RO unit 705 hands over this address through the signaling interface 712 to the location management unit 703, so the location management unit 703 can construct a packet to be transmitted to its own HA or a legacy IPv6 type CN.
  • the destination address is first checked by the main functions of a routing unit .
  • the destination pertains to an address in the IPv6 neighbor cache
  • an appropriate MAC layer address is obtainable, and the packet is handed over through the functional interface 710 to the lower-layer protocol 701 and supplied to a proper interface or the relevant protocol.
  • the care-of address becomes the LCoA of the MN or an address attained on the basis of a prefix of a TLMR.
  • the MlPv ⁇ location management unit 703 makes an inquiry at the new RO unit 705 about which of CoAs is to be put to use.
  • the new RO unit 705 advertises the use of one of the CoA of the MN attained on the basis of a prefix of the TLMR and the LCoA of the MN to the location management unit 705.
  • the location management unit 703 Upon receipt of the advertisement on a proper CoA from the new RO unit 705, the location management unit 703 constructs an appropriate packet .
  • the packet destination does not have a specified value in the neighbor cache or in the MlPv ⁇ location management unit 703
  • a check is made on the new RO unit 705. If a CN is registered in the binding list 706 associated with this new RO unit 705, then the new RO unit 705 constructs a tunnel packet having a RAO as mentioned above.
  • FIG. 9 shows the details of a preferred functional architecture of a MR including a TLMR according to an embodiment of the present invention.
  • a configuration of a MR will be described herein below with reference to FIG. 9. Similar to the MN functional architecture 700 shown in FIG. 8, in FIG. 9 the functional architecture 800 of MR is given.
  • FIG. 9 there exist a lower-layer protocol 801, a routing layer protocol 802 and a higher-layer protocol 815.
  • the higher-layer protocol 815 interacts with the routing layer protocol 802 through an interface 810
  • the lower-layer protocol 801 interacts with the routing layer protocol 802 through an interface 811.
  • the functions according to the present invention are principally realizable through the use of the routing layer protocol 802.
  • the routing layer protocol 802 has a NEMO basic unit 803 for realizing the functions defined in the NEMO basic standards . Moreover, according to the standards, the NEMO basic unit 803 further has a binding list 804 involving the binding produced by the MN and registered in a home agent. In this case, the binding signifies a binding between a MNP (mobile network prefix) of a MR and a CoA of the MR.
  • MNP mobile network prefix
  • the routing layer protocol 802 has an IPv6 routing unit 807.
  • This IPv6 routing unit 807 further has an IPv6 routing table 808 and a default router list 809.
  • the routing layer protocol 802 also has a new RO unit 805.
  • This new RO unit 805 realizes a new function on a MR involving an operation according to the present invention.
  • this new RO unit 805 there exists a routing table 806.
  • the routing table 806 includes a MN_ID of a downstream side MN and a next hop address (next hop IPv6 global address which enables the arrival at a certain MN_ID) .
  • the new RO unit 805 interacts with the NEMO basic unit 803 through a signaling interface 812 and interacts with the IPv6 routing unit 807 through a signaling interface 813. Moreover, the NEMO basic unit 803 interacts with the IPv6 routing unit 807 through a signaling interface 814.
  • the routing layer protocol 802 first passes this packet to the new RO unit 805.
  • FIG. 10 is a flow chart showing an operation of a MR excluding a TLMR
  • FIG. 11 is a flow chart showing an operation of a TLMR.
  • FIG. 10 shows a flow chart of an operation of a MR (MR remote from a home link and different from a TLMR) at the processing on a packet by the new RO unit 805.
  • MR MR remote from a home link and different from a TLMR
  • a description will be given herein below of a preferred operation at the processing on a packet in the new RO unit 805 and the interaction between the new RO unit 805 and the IPv6 routing unit 807 or the NEMO basic unit 803.
  • addresses indicated in FIG. 10 are IPv6 global unicast addressees.
  • the processing shown in FIG. 10 is valid to all the scenarios shown in FIGs. 5A, 6A and 7.
  • step SlOOO a check is made as to whether or not the MR is a TLMR.
  • step SlOOl a check is made as to whether or not the destination address of the packet is the same as the address of the MR itself. If the judgment in this step SlOOl shows that the destination address of the packet is not the address of the MR itself, a step S1002 follows to evaluate the parameters of the packet.
  • the packet has already arrived through an ingress interface.
  • a check is made as to whether or not a new type of RAO according to the present invention exists.
  • the new type of RAO can be specified by the presence of a certificate and a hash. If the judgment in the step S1002 shows that the new type of RAO does not exist, then the packet is handed over through the interface 812 to the NEMO basic unit 803 and, in a step S1005, the NEMO basic unit 803 carries out the packet processing.
  • the NEMO basic unit 803 encapsulates the packet in a tunnel addressed to its own HA.
  • the NEMO basic unit 803 hands over the packet through the signaling interface 814 to the IPv6 routing unit 807 and, in a step S1004, the IPv6 routing unit 807 carries out the packet processing.
  • the default router list is checked and, if the relevant MAC address is discovered, then the packet transmission is made.
  • the packet is processedinastepSlOO ⁇ .
  • step S1006 the verification on the certificate and the hash is made as described in the aforesaid embodiments.
  • a step S1007 follows to check whether or not the verification on the certificate and the hash has reached success. If the verification in the step S1007 has reached the success, then the processing proceeds to a step S1008 where a new route is established with respect to the ID of the MN inserted into the certificate and the source address of the packet is changed to the LCoA of the MR itself. This packet is not supplied to the NEMO basic unit 803 and, instead, the packet is handed over to the IPv6 routing unit 807 and the packet processing starts in the step S1004.
  • the tunnel to the TLMR is removed, and the packet is handed over to the NEMO basic unit 803 and the packet processing takes place in the step S1005.
  • the packet is encapsulated in a tunnel directed to the HA.
  • the new RO unit 805 carries out the processing in a step S1009 to check the presence of the RH2.
  • step SlOlO a check is made as to whether or not the value of the RH2 is equal to the MN_ID of an entry in the routing table 806 of the new RO unit 805. If in the step SlOlO the entry having the MN_ID equal to the value of the RH2 exists in the routing table 806 of the new RO unit 805, then the new RO unit 805 conducts the processing in a step SlOIl.
  • step SlOIl the destination of the packet is changed to the next hop address involving the MN_ID.
  • the packet is handed over to the IPv6 routing unit 807 where normal processing and routing take place. If the check in the step SlOlO shows that the MN_ID equal to the value of the RH2 does not exist in the routing table 806, then the packet is handed over to the NEMO basic unit 803 so as to carry out the packet processing. This can occur in a case in which an NEMO basic type BA is delivered from its own HA.
  • FIG. 11 is a flow chart showing an operation of a TLMR when the new RO unit 805 processes a packet.
  • a MR can become a TLMR in a case in which a connection router is a fixed access router.
  • the MR operates as a TLMR, there is a need to carry out the processing different from the processing in the case of a normal MR.
  • a portion of the processing is the same as the processing to be conducted in the case of the normal MR.
  • FIG. 11 the packet processing in the new RO unit 805 is mainly described.
  • the processing in FIG. 11 is also valid to all the scenarios shown in FIGs. 5A, 6A and 7.
  • the new RO unit 805 checks whether or not the MR is a TLMR.
  • the operational flow advances to carry out the processing in a step SIlOl. If the destination address is the same as the address of the TLMR, the operational flow advances to a step S1102 to check whether or not a new type of RAO exists within the packet.
  • the case in which the destination address is identical to the address of the TLMR can appear when the MN_ID is identical to the HoA of the MN and the CoA of the MN to be notified to a CN is the CoA of the TLMR. If the new type of RAO exists, then a flow similar to the MR processing mentioned above takes place, and the operational flow proceeds to steps S1103 and S1104.
  • the verification on a certificate and a hash is made in the step S1103, and then followed by a step S1104 so as to check whether or not the verification on the certificate and the hash has reached success . If the verification in the step
  • step S1104 the operational flow proceeds to a step S1105 where the route on the MN_ID is updated in the routing table 806 of the new RO unit 805. Following this, a step S1106 follows to decapsulate the packet. On the other hand, if the verification in the step S1104 has turned out a failure, the operational flow advances to carry out the packet decapsulation without updating the route in the step S1105.
  • this packet is handed over to the NEMO basic unit 803 which carries out the encapsulation in a tunnel directed to the HA, or it is directly handed over to the IPv6 routing unit 807.
  • the source address of the packet is the CoA of the TLMR, orwhen the prefixof the source address is identical to the prefix of the TLMR, then this packet is directly transmitted to the IPv6 routing unit 807.
  • the source address is other than this, then the packet is transmitted to the NEMO basic unit 803 and further tunneled to the HA.
  • step S1102 If the check in the step S1102 shows that a new type of RAO does not exist in the packet, then the operational flow advances to a step SlIO 9 to check whether or not the RH2 exists in the packet and further to check whether or not the RH2 is equal in value to the MN_ID on which a route exists in the routing table 806 of the new RO unit 805.
  • step S1109 a check is made as to whether or not the value of a care-of init cookie associated with the MN_ID exists in the packet, and a check is made as to whether or not the route on the MN_ID corresponding to the care-of init cookie exists within the routing table 806 of the new RO unit 805.
  • the value of this care-of init coolie is handed over from the MN at the transmission of a sign request message.
  • a check is made as to whether or not this packet involves a sign request message. If the judgment in this step S1112 shows that it is not the sign request message, a step S1115 follows to make a check. The check in the step S1115 relates to verification as to whether or not the HoA is associated with the care-of init cookie (whether or not it is stored in the TLMR) . If the judgment in the step S1115 shows that the HoA is associated with the care-of init cookie, the operational flow proceeds to a step S1114 to encapsulate the packet .
  • the destination address of the encapsulated packet becomes the HoA of the MN, while the source address thereof becomes the CoA or HoA of the TLMR.
  • this packet is directly transmitted to the IPv6 routing unit 807.
  • the processing on the packet is conducted in the IPv6 routing unit 807.
  • the packet is transmitted to the NEMO basic unit 803 because of the tunneling passing through the HA.
  • the judgment in the step S1115 shows that the HoA is not associated with the care-of init cookie, it is considered that the packet is a normal packet transmitted from a legacy IPv6 type CN to a mobile network node under the TLMR.
  • the packet is handed over to the NEMO basic unit 803 and, in a step S1107, the NEMO basic unit 803 carries out the processing on the packet.
  • step S1112 shows a sign request message
  • step S1113 the operational flow advances to a step S1113 where, after the verification of the address of theMN_ID, a sign request response message is produced and is handed over to the NEMO basic unit 803 and the IPv6 routing unit 807.
  • the unit to which the message is to be handed over is determined depending on the method of producing the sign request response message.
  • the operational flow goes to a step SlIlO so as to carry- out the processing of finding the next hop address, which enables the arrival at the MN_ID, from the routing table 806 of the new RO unit 805 and then encapsulate the packet in a tunnel in the most general case according to the present invention.
  • the packet is handed over to the IPv6 routing unit 807, and then followed by the step S1108 to carry out the normal routing processing on the IPv6 packet according to the IPv6 standard.
  • step Sllll The case in which the destination address is not the address of the TLMR in the step SIlOl signifies that the MN_ID is obtainable on the basis of the prefix of the TLMR. In this case, further verification is made in a step Sllll.
  • a check is made as to whether or not an available route exists with respect to this address within the routing table 806. If the judgment in the step Sllll shows that the available route exists with respect to this address, then the processing is conducted in the step S1110.
  • the packet is encapsulated in the source address identical to the address of the TLMR and the destination address identical to the LCoA of the MN and then sent in an appropriate manner.
  • the TLMR can keep the LCoA of the MN associated with the MN_ID and, in consequence, it can send the CoT and HoT message delivered from the CN.
  • the tunnels not only in the forward direction but also in the reverse direction are completely removable in conjunction with the data communications between a VMN in a deeply nested state and CN where the MIPv6 are workable.
  • This complete tunnel removal is feasible in a case in which the ID of the VMN is identical to the HoA of the VMN and the CoA of the VMN to be advertised to the CN is identical to the CoA of the TLMR.
  • FIG. 12A is an illustration of a message sequence chart (MSC) related to a different embodiment of the present invention.
  • the VMN 10 is in a deeply nested state under the MR 20 and the TLMR 30.
  • the HA 35 is the HA of the VMN.
  • the VMN 10 has a communication session with respect to the CN 40 where the MlPv ⁇ is workable and the VMN 10 moves into a nested NEMO network with the TLMR 30 being placed into a root.
  • a route update signaling having a new RAO is not integrated with the transmission of a data packet and it is different from the scenario shown in FIG. 5A.
  • FIG. 5A FIG.
  • FIG. 12B shows one example of the contents contained in several packets to be transmitted according to the message sequence shown in FIG. 12A.
  • FIG. 12B there are shown one example of the contents of a packet (RA packet) 1200 to be transmitted from the TLMR 30 and the contents of a packet (RA packet) 1201 to be transmitted from the MR 20.
  • the route update is integratedwith the data transmission.
  • the topology of the NEMO in a nested state does not largely vary, there is little advantage when the data transmission and the route update signaling are integrated into a single mechanism.
  • the data transmission and the route update mechanism are integrated with each other.
  • the overhead of the signaling increases and the end-to-end data packet delay lengthens.
  • a VMN receives the advertisement about a variation in the upstream side MRs through the use of some manner.
  • the VMN can transmit a route update packet to a TLMR by itself. In this case, there is no need for the route update packet to be integrated with a data packet.
  • FIG. 12A the RA 1201 has the contents similar to those (for example, the RA 401 in FIG.
  • the VMN 10 acquires the RA 1201 and specifies the movement into a new nested NEMO network and then conducts the signaling interchange indicated by the respective messages 1202 to 1207 in FIG. 12A.
  • These signaling are the same as the respectivemessages 502 to 507 in FIG.5A, whichwere already described in the aforesaid embodiment, and the detailed description thereof will be omitted for simplicity.
  • the VMN 10 transmits a pure location update packet having a format similar to that of the route update ping packet 102 in FIG. IA.
  • the source address of this location update packet 1208 becomes the LCoA of the VMN 10 while the destination address thereof becomes CoA of the TLMR.
  • this location update packet 1208 includes a new type of RAO having a certificate and a hash value.
  • the MR 20 and the TLMR 30 create a new hop route, which enables the arrival at the HoA of the VMN 10.
  • the VMN 10 initiates an RR test signaling 1209 and a BU 1210 to the CN 40.
  • These signaling packets can have the same format as that mentioned with reference to FIG. 5A.
  • the packet format in the VMN 10 can become a format indicated by a data packet 1300 in FIG. 13.
  • the source address of this data packet 1300 is the LCoA of the VMN 10 and the destination address thereof is the CoA of the TLMR 30.
  • the packet has an RH type 0 (1303) and it can be made to include the address of the CN 40.
  • an authentication header (AH) 1304 can be included in the case of the use of IPsec. For example, this AH is produced by using the CoA of the TLMR 30 as the CoA of the VMN 10.
  • a home address destination option 1305 having the HoA of the VMN 10 exists therein.
  • Data is contained in a payload 1306 of the packet.
  • the MR 20 can grasp an operation of this protocol by referring to this destination address thereof.
  • the TLMR can obtain a CoA of a fully new TLMR and can notify a different CoA to an HA of the TLMR.
  • this TLMR address is the destination address
  • the MR 20 sends a packet through a default router with the source address being changed to its own LCoA.
  • the TLMR 30 carries out the inspection on the RHO because it is the destination of the packet.
  • the TLMR 30 switches the destination address to the address of the CN 40 and changes the contents of the RH type 0 to its own LCoA and further changes the source address to the LCoA.
  • This packet is sent as usual and reaches the CN 40 without undergoing the end-to-end tunneling.
  • the CN 40 can process this packet without departing fromthe operation according to the standardprotocol . 7 !
  • the data packet from the CN 40 to VMN 10 has a format identical to that shown in FIG. 5A, and the description thereof will be omitted for brevity.
  • FIG. 12A a method shown in FIG. 12A is useful to the communications between these two VMNs.
  • the VMN 10 and a VMN 11 have just moved into a nested NEMO network where the TLMR 30 makes a root.
  • the HA of each of the VMN 10 and the VMN 11 is in connection with a global communication network 1400.
  • the VMN 10 initiates a RR and a BU with the VMN 11 for the advertisement of a CoA.
  • the VMN 11 also conducts the same processing as that in the VMN 10.
  • the VMN 11 has the CoA of the TLMR 30 as a CoA for the VMN 10
  • the VMN 10 also has the CoA of the TLMR 30 as a CoA for the VMN 11.
  • the VMN 10 can construct a packet shown in FIG. 13. This packet has the CoA of the TLMR 30 as a destination address, and the HoA of the VMN 11 is included in the RHO.
  • the MR 20 Upon receipt of the data packet transmitted from the VMN 10 to the VMN 11, the MR 20 only examines this packet and refers to the destination address to change the source address to the LCoA of the MR 20.
  • the TLMR 30 refers to the routing table 806 in the new RO unit 805 searches the next hop address concerning the RHO entry (i.e., the HoA of the VMN 11) .
  • the entry regarding the HoA of the VMN 11 is found in the routing table 806, and the TLMR 30 changes the destination address of the packet to the LCoA of the MR 21 before sending the packet .
  • the TLMR 30 does not change the contents of the RHO.
  • the MR 21 finds out the next hop address by using this value . This indicates a method of obtaining an optimized path -1401 in a case in which the route update mechanism is separated from the data transmission.
  • the VMN 11 can seize that the peer node VMN 10 exists in the same nested NEMO network (for example, it is graspable on the basis of the CoA of the TLMR) and, hence, it can grasp the format of the packet and correctly carry out the processing on the packet. Moreover, in a case in which CoT and CoTI messages are created by the VMN 10 and the VMN 11, since a route based on the VMN home address exists within the nested NEMO network, this method also provide an advantage in that these CoT and CoTI messages are transmitted through an optimized route. In consequence, these care-of addresses concerning the test signaling packet is reachable to the destination without passing through the interior of the global internet.
  • the TLMR operates as an endpoint state having functions such as the sign request processing and the local mobility management, it is also appropriate that these functions are packaged in a fixed access router in an access network. Moreover, in a case in which a mobile router existing at an intermediate position does not have the functions according to the present invention, or if the information on a TLMR is not transmittable to a network there under, a person skilled in the art would easily recognize that a mobile router connected to this mobile router can fulfill a function as a TLMR.
  • the credit information on the TLMR (the public key of the TLMR and others) can be distributed in advance and the fact that the credit information thereon can be distributed on the basis of the credit of the third party
  • a VMN or a mobile network with which the VMN is in connection establishes a connection with (moves ⁇ into) a network under a different TLMR, for carrying out the immediate initiation of the data communication preferentially with respect to the processing including a sign request
  • a person skilled in the art would easily recognize that it is possible to permit the temporary transmission of a packet in a manner such that a TLMR (nTLMR) with which the VMN newly establishes a connection makes an inquiry at a TLMR (pTLMR) , with which the VMN established a connection before, about the verification on the certificate and hash value of the pTLMR.
  • anLSI Large Scale Integration
  • these functional blocks are individually formed as one chip, or that a portion of or all of these functional blocks are formed as one chip.
  • anLSI is taken in this case, it is sometimes referred to as an IC (Integrated Circuit) , system LSI, super LSI or ultra LSI according to the level of integration.
  • the technique for the formation of an integrated circuit is not limited to the LSI, but it is also realizable with a dedicated circuit or a general-purpose processor.
  • FPGA Field Programmable Gate Array
  • the technique for the formation of an integrated circuit is not limited to the LSI, but it is also realizable with a dedicated circuit or a general-purpose processor.
  • FPGA Field Programmable Gate Array
  • a reconfigurable processor which allows the reconfiguration of connections and setting of circuit cells in the interior of the LSI.
  • the present invention provides an advantage of, in end-to-end communications, reducing a cost of a network by minimizing the number of tunnels and the size of a routing header and establishing an optimized route promptly in a high-security state. Moreover, the present invention is applicable to a technique for the management of a packet transmission route in a packet switched data communication network such as an IP network (in addition, mobile IP network and NEMO network) .
  • IP network in addition, mobile IP network and NEMO network

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne une technique permettant, dans un système de réseau mobile qui se trouve dans un état imbriqué, d'établir une trajectoire optimisée rapidement dans un état de sécurité élevée. Selon cette technique, dans un système de réseau mobile dans lequel un routeur mobile (MR) (20) et un MR (21) sont connectés de manière hiérarchique sous un routeur mobile de niveau supérieur (TLMR) (30) de façon à établir un état imbriqué, un noeud mobile visiteur (VMN) (10) acquiert préalablement des informations de certificat produites de sorte qu'un TLMR code une adresse d'un VMN en se servant d'une clé privée, et ajoute une option d'avertissement routeur (RAO) comprenant les informations de certificat à un paquet tunnel avant transmission au TLMR. Des MR intermédiaires (MR 20 et MR 21) acquièrent l'adresse du VMN en se servant de la clé publique du TLMR et enregistrent l'adresse source de ce paquet. Le MR est conçu pour remplacer l'adresse source par sa propre adresse au moment du transfert de ce paquet. Ainsi, l'adresse source du paquet enregistré devient un saut de transfert d'un paquet dirigé vers le VMN.
PCT/JP2007/071598 2006-11-02 2007-10-31 ++noeud mobile et routeur d'accès WO2008054022A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2006299684 2006-11-02
JP2006-299684 2006-11-02

Publications (2)

Publication Number Publication Date
WO2008054022A2 true WO2008054022A2 (fr) 2008-05-08
WO2008054022A3 WO2008054022A3 (fr) 2008-07-10

Family

ID=38926223

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2007/071598 WO2008054022A2 (fr) 2006-11-02 2007-10-31 ++noeud mobile et routeur d'accès

Country Status (1)

Country Link
WO (1) WO2008054022A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108055316A (zh) * 2017-12-08 2018-05-18 深圳市田言智能科技有限公司 一种基于物联网的智能路由器启停系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050041634A1 (en) * 2003-08-06 2005-02-24 Aura Anssi Tuomas Verifying location of a mobile node
US20050058100A1 (en) * 2003-09-15 2005-03-17 Samsung Electronics Co., Ltd. Method for optimizing nested tunnels using nested path information in a mobile network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050041634A1 (en) * 2003-08-06 2005-02-24 Aura Anssi Tuomas Verifying location of a mobile node
US20050058100A1 (en) * 2003-09-15 2005-03-17 Samsung Electronics Co., Ltd. Method for optimizing nested tunnels using nested path information in a mobile network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NG PANASONIC SINGAPORE LABS J HIRANO PANASONIC C: "Securing Nested Tunnels Optimization with Access Router Option; draft-ng-nemo-access-router-option-01.txt; " IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, no. 1, 12 July 2004 (2004-07-12), XP015033183 ISSN: 0000-0004 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108055316A (zh) * 2017-12-08 2018-05-18 深圳市田言智能科技有限公司 一种基于物联网的智能路由器启停系统
CN108055316B (zh) * 2017-12-08 2021-06-01 深圳市田言智能科技有限公司 一种基于物联网的智能路由器启停系统

Also Published As

Publication number Publication date
WO2008054022A3 (fr) 2008-07-10

Similar Documents

Publication Publication Date Title
KR100679882B1 (ko) 사설 네트워크와 로밍 모바일 단말 사이의 통신
Ng et al. Network mobility route optimization solution space analysis
US7924745B2 (en) Hybrid mobile communication system comprising multi-hop-ad-hoc and circuit-switched modes
US8437345B2 (en) Terminal and communication system
EP2144416B1 (fr) Appareil de gestion de réseau mobile et appareil de gestion d'informations mobiles pour le contrôle des demandes d'accès
US8259649B2 (en) Route optimization with location privacy support
EP1956755A1 (fr) Réduction de surcharge contrôlée d'un réseau de paquets de données par procédure d'optimisation d'itinéraire
US20100097993A1 (en) System for Effective Position Management Signaling Associated with Mobile Node Moving in Mobile Network, Router, Mobile Node, and Mobile Router
KR20070093979A (ko) 통신 루트 최적화 방법, 통신자 장치 및 시스템
EP2272270B1 (fr) Procédé d accès à un réseau, réseau associé et progiciel à cet effet
US20100296443A1 (en) System, method and apparatus for route-optimized communication for a mobile node nested in a mobile network
US20090106831A1 (en) IPsec GRE TUNNEL IN SPLIT ASN-CSN SCENARIO
US20100046558A1 (en) Header reduction of data packets by route optimization procedure
AU2010267639B2 (en) Methods and systems for mobile IP route optimization
JP2008543120A (ja) パケット転送制御方法及びパケット転送制御装置
WO2008054022A2 (fr) ++noeud mobile et routeur d'accès
US20100175109A1 (en) Route optimisation for proxy mobile ip
JP5192065B2 (ja) パケット伝送システムおよびパケット伝送方法
Ng et al. RFC 4889: Network mobility route optimization solution space analysis
Bernardos et al. RFC 8885: Proxy Mobile IPv6 Extensions for Distributed Mobility Management
JP2009225158A (ja) 移動体通信システム
Watari et al. Network Working Group C. Ng Request for Comments: 4889 Panasonic Singapore Labs Category: Informational F. Zhao UC Davis
Rónai et al. IST-2001-35125 (OverDRiVE) D07
Iapichino et al. Mobility, Access Heterogeneity and Security for Next Generation Public Safety Communications

Legal Events

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

Ref document number: 07831329

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: JP

122 Ep: pct application non-entry in european phase

Ref document number: 07831329

Country of ref document: EP

Kind code of ref document: A2