WO2009003405A1 - Procédé et dispositif de notification, de recherche d'adresse de communication et procédé et dispositif de détection, de reprise de communication - Google Patents

Procédé et dispositif de notification, de recherche d'adresse de communication et procédé et dispositif de détection, de reprise de communication Download PDF

Info

Publication number
WO2009003405A1
WO2009003405A1 PCT/CN2008/071488 CN2008071488W WO2009003405A1 WO 2009003405 A1 WO2009003405 A1 WO 2009003405A1 CN 2008071488 W CN2008071488 W CN 2008071488W WO 2009003405 A1 WO2009003405 A1 WO 2009003405A1
Authority
WO
WIPO (PCT)
Prior art keywords
network node
address
message
response
module
Prior art date
Application number
PCT/CN2008/071488
Other languages
English (en)
Chinese (zh)
Inventor
Zhongqi Xia
Wei Cao
Sheng Jiang
Original Assignee
Huawei Technologies Co., Ltd.
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 Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2009003405A1 publication Critical patent/WO2009003405A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H04L61/103—Mapping addresses of different types across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5084—Providing for device mobility
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/677—Multiple interfaces, e.g. multihomed nodes
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/005—Multiple registrations, e.g. multihoming

Definitions

  • the present invention relates to a communication technology in a multi-homing environment in the field of network communication, and in particular, to a communication address notification method for a multi-homed network node, a communication detection method, a communication address exploration method, a communication recovery method, and a multi-homing network node.
  • IP Internet Protocol
  • IP enterprise networks including the Internet, IP enterprise networks, and metropolitan area networks
  • IP addresses play a dual role. From a network perspective, the IP address has the function of addressing and routing. The IP address identifies the location of the IP device/node in the network. The network routing protocol sends the IP packet to the specified destination according to the IP address. From the application point of view, the IP address represents the identity of the communication node; the application does not need to pay attention to the specific location of the communication node, but only needs to pay attention to the identity of the communication node represented by the IP address.
  • Multi-homing feature mainly refers to a host or network accessing the Internet through multiple addresses or interfaces; for example, a network accesses the Internet through multiple ISPs (Internet Service Providers), or a terminal is connected to multiple interfaces through multiple interfaces. External network.
  • ISPs Internet Service Providers
  • a terminal is connected to multiple interfaces through multiple interfaces.
  • External network Such a network supporting multi-homing characteristics is called a multi-homing network, and a network node supporting multi-homing characteristics is called a multi-homing node.
  • HIP Home Identity Protocol
  • the IP address is only used as a location identifier in the network; in addition, the protocol also enters another namespace.
  • the architecture of the HIP protocol is shown in Figure 1.
  • a host identity layer HIP is introduced between the transport layer and the network layer, and the HIP layer isolates the transport layer from the IP interconnect layer.
  • the transmission itself does not care about the underlying IP protocol, and the interface provided by the transport layer to the application layer mainly includes the identity ID and the protocol port.
  • the HIP layer mainly performs the process of converting the identity ID to the IP address.
  • the HIP needs to maintain the mapping relationship between the identity and the IP address, and the mapping relationship mainly includes the mapping relationship between the peer identity ID and the IP address, and the local identity ID and IP address. Mapping relationship. Since the maintenance of this mapping relationship is a dynamic process that exists for a long time, this process is called an environment Context.
  • the HIP Context plays a very important role. For packets sent from the host, they can be identified by the host identity pair (source HI, destination HI). Because the packet is encrypted and protected by IPSec (IP security protocol), there is an SPI (Security Parameter Index) in the IPSec header. In the HIP protocol, the SPI can be used not only. It is used to identify the security association and also to identify the HIP Context. This is because the security association negotiation is done through the HIP protocol. For packets received from the host, the SPI can be identified by the SPI.
  • source HI source HI
  • destination HI destination HI
  • SPI Security Parameter Index
  • Mobility and multi-homing Since the transport layer only cares about the identity, the change of the network access location caused by the movement and multi-homing of the node does not affect the transport layer, and only the corresponding mapping relationship needs to be changed in the corresponding HIP layer. Just fine.
  • Host A In the HIP protocol process, for two hosts A and B, if host A needs to initiate communication with host B, host A needs to obtain the identity ID and corresponding IP of host B through DNS (Domain Name Server) query. address. Before Host A initiates a formal transmission connection to Host B, Host A needs to establish a HIP environment with Host B.
  • DNS Domain Name Server
  • the HIP environment establishment process of Host A and Host B is as shown in Figure 2.
  • the process is a 4-time grip.
  • Hand protocol process
  • Step 201 The host A sends an II message to the host B, where the message is an initialization message initiated by the host A to the host B, indicating that the host A wants to perform a HIP session with the host B.
  • Step 202 Host B returns an R1 message to host A, where the message is a response message sent by host B to host A, and host B requests host A to solve the problem;
  • Step 203 Host A sends a message to host B, and host A submits a solution to the problem, and negotiates the IPSec security association and the key exchange packet D-H for data transmission, and provides its own security parameter index SPI;
  • Step 204 Host B returns an R2 message to Host A, and Host B sends back its own security parameter index SPI and sends a key exchange packet D-H.
  • the HIP environment is established, the mapping between the host identity HI and the IP address is established, and the security association negotiation of data transmission is completed.
  • R2 the second HIP response packet
  • a HIP packet consists of a HIP header and a HIP parameter.
  • the HIP protocol is designed to support mobility and multi-homing features
  • the specific implementation of the HIP protocol in a multi-homing environment has not been explicitly defined. Therefore, the HIP protocol needs to be improved and extended to truly support mobile and multi-homing features.
  • An embodiment of the present invention provides a method for notifying a multi-home network node communication address, To notify the peer network node of the IP address corresponding to the network node identity, the method includes:
  • the second network node receives the first address update message sent by the first network node, where the first address update message includes an IP address corresponding to the identifier of the first network node, where the IP address is recovered by communication failure.
  • the second network node acquires a correspondence between the IP address and the identifier of the first network node, and sends a second address update message to the first network node to respond.
  • Another embodiment of the present invention provides a multi-homing network node, where the network node includes: a messaging module, an address notification module, and an address storage module, where
  • An address notification module configured to: the message sending and receiving module sends an address update message to the peer network node, where the IP address corresponding to the identity of the local network node is included, where the IP address is a candidate IP address for communication failure recovery;
  • a message sending and receiving module configured to send the address update message according to the indication of the address notification module, and receive an address update message sent by the peer multi-network node to the local network node, where the address update message includes The IP address corresponding to the network node identity, where the IP address is a candidate IP address for communication failure recovery;
  • an address storage module configured to acquire the IP address received by the messaging module, establish a correspondence between the IP address and the identifier of the peer network node, and store the IP address.
  • the address update message is sent between the network nodes, and the candidate IP address corresponding to the identity of the local network node is included, so that the peer network node can receive the IP address, and establish an identity with the corresponding network node.
  • Corresponding relationship realizes the notification of the communication address of the multi-homed network node, which provides the possibility of address switching for the multi-homed network node.
  • Another embodiment of the present invention provides a method for detecting communication of a multi-homed network node to detect a communication state between the multi-homed networks, the method comprising:
  • the first network node sends a connection hold request message to the second network node, and instructs the second network node to respond after receiving the connection hold request message; If the first network node receives the connection hold response message returned by the second network node according to the connection hold request message, the first network node and the second network node currently communicate normally; The first network node does not receive the connection hold response message returned by the second network node, and the first network node and the second network node currently fail to communicate.
  • Another embodiment of the present invention provides a multi-homing network node, where the network node includes: a messaging module and a detection judging module, wherein
  • a message sending and receiving module configured to send a connection hold request message to the communication peer network node, and instruct the peer network node to respond; receive a connection hold response message returned by the peer network node;
  • the detecting and determining module is configured to determine whether the message receiving and receiving module receives the connection hold response message returned by the peer network node, and if yes, determine that the communication with the peer network node is normal; Then, it is determined that the communication with the peer network node fails.
  • connection holding request message is sent between the multi-homed network nodes, and the current communication state is determined according to whether the connection holding response message of the opposite end can be received, and the current communication state is detected, which is timely. Communication address switching is possible.
  • Another embodiment of the present invention provides a method for exploring a multi-home network node communication address, so as to implement detection of the validity of a candidate address pair, the method includes:
  • the first network node selects a new IP address pair by selecting one IP address from each of the candidate IP address pools corresponding to the first network node identifier and the candidate IP address pool corresponding to the second network node identifier;
  • the first network node sends a discovery request message to the second network node, instructing the second network node to respond;
  • the source address and the destination address of the discovery request message are addresses in the new IP address pair;
  • the new IP address pair is valid; if the first network node does not receive the first The discovery response message returned by the second network node, the new IP address pair is invalid.
  • Another embodiment of the present invention provides a multi-homing network node, where the network node includes: a messaging module, an address selection module, and an address exploration module, where
  • An address selection module configured to select a new IP address pair from a candidate IP address pool corresponding to the local network node identifier and a candidate IP address pool corresponding to the peer network node identifier;
  • An address search module configured to instruct the message sending and receiving module to send a search request message to the peer network node, where the search request message indicates that the peer network node responds, and the source address and the destination address of the search request message are The IP address in the new address pair;
  • the message receiving and receiving module receives the discovery response message returned by the peer network node, determining that the address pair selected by the address selection module is valid; if the message transceiver module does not receive the peer network node return Determining the response message, determining that the address pair selected by the address selection module is invalid;
  • a message sending and receiving module configured to send the discovery request message according to the indication of the address discovery module, and receive the discovery response message.
  • the network node uses the selected candidate address pair to send a discovery request message to the opposite end, and determines whether the candidate address pair is valid according to whether the search response message returned by the opposite end can be received.
  • the process of detecting whether an address pair is valid provides a possibility to cut off to a valid address pair when the communication fails.
  • Another embodiment of the present invention provides a method for recovering communication of a multi-homed network node, so as to implement recovery of communication when a communication failure occurs between multiple home hosts, the method includes:
  • the first network node When the communication between the first network node and the second network node fails, the first network node respectively obtains a candidate IP address pool corresponding to the first network node identity and a candidate IP address corresponding to the second network node identity Each pool selects an IP address to form a new IP address pair, and explores the validity of the selected new address pair; or selects a pair of candidate IP address pairs from the candidate IP address pairs that have been explored as valid. ;
  • the first network node, the first network node and the second network node, The IP address pair corresponding to the first network node identity and the second network node identity is updated to the new IP address pair or the candidate IP address pair that is searched to be valid.
  • Another embodiment of the present invention provides a multi-homing network node, where the network node includes: a communication detection module, an address selection module, an address discovery module, an address update module, and a messaging module, wherein
  • a communication detection module configured to detect a communication state between the local network node and the peer network node; and an address selection module, configured to: when the communication detection module detects that the local network node fails to communicate with the peer network node, Selecting a candidate IP address pool corresponding to the identifier of the end network node, and selecting an IP address in each of the candidate IP address pools corresponding to the identity of the peer network node to form a new IP address pair;
  • An address search module configured to instruct the message sending and receiving module to send a search request message to the peer network node, where the search request message indicates that the peer network node responds, and the source address and the destination address of the search request message are And the IP address of the new address pair; and when the message receiving and receiving module receives the discovery response message returned by the peer network node, starting the address update module;
  • An address update module configured to update an IP address pair corresponding to the local network node identifier and the peer network node identifier in the local network node to the new address pair; and pass the message
  • the transceiver module sends an update request message to the peer network node, and updates the IP address pair corresponding to the local network node identity and the peer network node identity to the new address pair in the peer network node.
  • the message sending and receiving module is configured to send the discovery request message and the update request message to the peer network node, and receive a corresponding response message returned by the peer network node.
  • the multi-homing network node selects a pair of new address pairs and verifies whether it is valid. If the address pair is valid, it updates to the address pair used by the current communication, thereby It realizes timely switching to a valid address pair when communication fails, thus realizing a reliable communication recovery process.
  • FIG. 1 is a schematic diagram of a HIP protocol architecture of the prior art
  • FIG. 2 is a schematic diagram of a HIP environment establishment process in the prior art
  • FIG. 3 is a schematic diagram of a flow of a multi-home address notification process according to Embodiment 1 of the present invention.
  • FIG. 4 is a second schematic diagram of a multi-home address notification process according to Embodiment 1 of the present invention.
  • FIG. 5 is a schematic diagram of a format of a HIP protocol packet according to Embodiment 2 of the present invention.
  • FIG. 6 is a schematic diagram of a communication failure detection process according to Embodiment 2 of the present invention.
  • FIG. 7 is a second schematic diagram of a communication failure detection process according to Embodiment 2 of the present invention.
  • FIG. 8 is a schematic diagram of a HIP protocol packet format according to Embodiment 3 of the present invention.
  • FIG. 9 is a schematic diagram of an address searching process according to Embodiment 3 of the present invention.
  • FIG. 10 is a schematic diagram of a communication recovery process according to Embodiment 4 of the present invention.
  • FIG. 11 is a schematic flowchart of an address pair update process according to Embodiment 4 of the present invention.
  • FIG. 12 is a schematic structural diagram of a multi-homing network node according to an embodiment of the present invention.
  • FIG. 13 is a second schematic structural diagram of a multi-homing network node according to an embodiment of the present invention.
  • FIG. 14 is a third schematic structural diagram of a multi-homing network node according to an embodiment of the present invention.
  • FIG. 15 is a fourth schematic structural diagram of a multi-homing network node according to an embodiment of the present invention.
  • This embodiment describes a process in which host A and host B notify each other of an additional address after the multi-homed host A and the multi-homed host B establish a HIP environment.
  • the HIP communication parties need to know the IP address corresponding to the identity of the other party, so that when the IP address pair corresponding to the identity of the communication party fails, the identity of the two parties of the communication may be selected. Other IP address pairs ensure that communication can proceed normally. Since the prior art does not clarify the address notification process of both parties of the multi-homing host, the embodiment needs to extend the HIP protocol. In this embodiment, the four exchanges of the HIP protocol are completed, After the HIP environment is established, the communicating parties may notify other parties of other multi-homing addresses corresponding to the respective identity identifiers.
  • the multi-homing address notification process of the HIP protocol can be as shown in FIG. 3.
  • FIG. 3 it is a schematic diagram of a multi-homing address notification process according to Embodiment 1 of the present invention, where the process may occur at a certain random time after the HIP environment of both communicating parties is established.
  • the identity identifier pair currently communicating by the multihomed hosts A and B is (HI A , HI B ), and the corresponding IP address pair is (A l Bj ), and the identity of the host A is ⁇ ⁇
  • the identity of the host B, HI B is also mapped to the IP address B 2 . Therefore, the host A needs to notify its address B 2 to the host B, and the host B needs to notify its address B 2 .
  • the notification process includes:
  • the multi-homing host A sends an address update message 1 (Address Update 1 ) to the multi-homing host B, and notifies the host B of the multi-homing address A 2 of the host A.
  • Address Update 1 an address update message 1
  • the address update message carries the LOCATOR parameter (the LOCATOR parameter is a parameter already defined in the existing HIP protocol), and the parameter is used to carry a multi-homing address, and the bearer address may be one or more, and these addresses will serve as communication.
  • the LOCATOR parameter carries the address A 2 of host A.
  • the address update message also carries the sequence number SEQ of the current address update message. Since the HIP signaling protocol is not a protocol for reliable connection, the serial number can be used to verify the reliability of the address update message transmission to ensure reliable transmission of the address update message.
  • the multi-homing host B After receiving the address update message sent by the multi-homing host A, the multi-homing host B records and establishes a mapping relationship between the identity identifier HIA of the host A and the multi-homing address A 2 , and sends an address update message 2 to the multi-homing host A ( Address Update2) prolong By this address update message, Host B responds to Host A's address update message and sends its own Multi-Home Address B 2 to Host A.
  • Address Update2 Address Update2
  • the address update message carries the LOCATOR parameter.
  • the LOCATOR parameter carries the address B 2 of the host B.
  • the address update message also carries the sequence number SEQ of the current address update message.
  • the address update message also carries a response message ACK to the address update message 1 to confirm receipt of the address information notified by the host A.
  • the address update message can also carry other parameters as needed.
  • the multi-homing host A After receiving the address update message sent by the multi-homing host B, the multi-homing host A records and establishes a mapping relationship between the identity identifier HI B of the host B and the multi-homing address B 2 , and sends an address update message 3 to the multi-homing host B ( Address Update3) to respond to the host's address update message.
  • the address update message mainly carries the sequence number SEQ of the current address update message.
  • the address update message in the above steps of this embodiment may be carried by an existing HIP packet.
  • Figure 3 shows only the general flow of address notification. In fact, there may be a notification flow of the multi-homing address as shown in Figure 4.
  • the multi-homing host A and the multi-homed host B initiate address notification to the other party at the same time, and the two address update messages are intersected in time series, and 401 and 402 in FIG. 4 are the host A and the host respectively.
  • the address update message sent by B which carries the multi-homing address and the serial number that are respectively notified to the other party; after receiving the address update message sent by the other party, the host A and the host B respectively send an address update response message to the other party, as shown in the figure.
  • 403 and 404 in 4 are address update response messages sent by host A and host B, respectively, which carry a serial number.
  • the content of the address update message is basically similar to the address update message of FIG. 3, and will not be described again.
  • a single-sided address notification process may also occur. For example, host A sends an address update message to host B, and carries the address of host A through the LOCATOR parameter. After receiving the message, host B sends an address update response message only to host A because there is no need to notify the address of host A.
  • the LOCATOR parameter is not included in this message.
  • This embodiment describes the process of detecting the current communication between the multihomed host A and the multihomed host B, that is, the process of checking the validity of the IP address pair used for the current communication.
  • This embodiment extends the HIP protocol packet to implement validity detection on the current communication IP address.
  • the message defined in this embodiment is called a Keepalive message (the name of the message is only an example and does not constitute a limitation of the present invention).
  • Keepalive ⁇ There are two subtypes, one is a keepalive request, and the other is a keepalive response. You can also combine keepalive requests and responses into a keepalive message.
  • the format of the Keepalive message can be as shown in Figure 5.
  • the keepalive packet shown in Figure 5 consists of the HIP header and HIP parameters, where:
  • the HIP header is the same as the HIP header defined by the existing HIP protocol;
  • Keepalive messages can also include other parameters, such as Sig (signature) parameters, Sig parameters for message integrity, data source verification, and are standard parameters of the HIP protocol.
  • FIG. 6 is a schematic diagram of a communication detection process according to Embodiment 2 of the present invention
  • communication detection can be performed to detect whether the IP address currently used by both communicating parties is valid.
  • the identity identifier pair currently being communicated by the multi-homed host A and the multi-homed host B is ( ⁇ ⁇ , ⁇ ⁇ ), and the corresponding IP address pair is (A Bj ), and the detection process includes:
  • the multihoming host A sends a detection request message ( Keepalive Request;) to the multihomed host B, and instructs the multihomed host B to respond.
  • the host identity pair used by the keepalive message is (HI A , HI B ), and the corresponding IP address pair is ( A Bj ) 0
  • Keepalive request messages can be sent periodically so that the validity of the communication address can be detected in time.
  • a timer may be set. When the timer expires, the keepalive request message is sent, and the timer is reset at the same time as the keepalive request is sent, and the timing is restarted, so that the address validity can be implemented according to the period specified by the timer. Detection.
  • the setting of the keepalive timer can be prompted by the application of the upper layer. For example, if the upper layer application has traffic, it indicates that the address pair can work normally, and does not need to trigger the keepalive process. If there is no traffic in the upper layer, the keepalive process needs to be triggered.
  • the multihoming host B returns a detection response message (a keepalive response) to the multihoming host A.
  • the host identity pair used by the Keepalive message is ( ⁇ ⁇ , ⁇ ⁇ ), and the corresponding IP address pair is ( , Ai ).
  • the Keepalive message can also carry the response message Ack.
  • host A receives a response from host B, it indicates that the current address pair corresponding to the identity pair of host A and host B is valid; otherwise, the current address pair is invalid.
  • a timer can be set in the host A. If the timer has expired and the host A has not received the response returned by the host B, the current address pair is considered invalid, that is, communication failure occurs; otherwise, the current address pair is considered valid. , you can continue normal communication.
  • the multihoming host B sends a detection request message ( Keepalive request;) to the multihomed host A, and instructs the multihomed host A to respond.
  • the host identity pair used by the Keepalive message is (HI A , HI B ), and the corresponding IP address pair is ( Aj , Bj ) 0
  • the request/response indication parameter in the Keepalive message is set to the request type; the carried response indication parameter value is set to require a response.
  • the multihoming host A returns a detection response message ( Keepalive response) to the multihoming host B.
  • the host identity pair used by the Keepalive message is ( ⁇ ⁇ , ⁇ ⁇ ), and the corresponding IP address pair is ( , Ai ).
  • the request/response indication parameter carried by the Keepalive message is set to the response type; the carried response indication parameter is set to no response.
  • the Keepalive message can also carry the response message Ack.
  • host B If the host B receives the response returned by the host A within the specified time, it indicates that the current address pair corresponding to the host identity pair is valid; otherwise, the current address pair is considered invalid. In the specific implementation In the process, host B can set a timer. If the timer has not timed out and has received a response from host A, it determines that the current address pair is invalid.
  • FIG. 7 is a schematic diagram of a communication detection process according to Embodiment 2 of the present invention, which specifically includes:
  • the multi-homing host A sends an address detection request message ( Keepalive request) to the multi-homing host B, and instructs the multi-homing host B to respond.
  • the parameter in the Keepalive request message is set with the Keepalive request message of 601 in Figure 6.
  • the multi-homing host B sends a detection request/response message (Keepalive request/response) to the multi-homing host A.
  • a detection request/response message Keepalive request/response
  • the Keepalive message can also carry the response message Ack.
  • host A If host A receives the response sent by host B within the specified time, it indicates that the address pair corresponding to the current identity pair is valid; otherwise, the current address pair is considered invalid.
  • Multi-homing host A returns a detection response message (Keepalive response) to the multi-homing host B.
  • the parameters in the Keepalive response message are set with the Keepalive response message of 604 in Figure 6.
  • host B receives a response from host A within the specified time, it indicates that the address pair corresponding to the host identity is valid; otherwise, the current address pair is considered invalid.
  • FIGS. 6 and 7 are processes for detecting the bidirectional reachability of both communication nodes.
  • One of the two nodes of the communication node sends a Keepalive request message and correctly receives the Keepalive response message, which only indicates that the node is bidirectionally reachable. Only when both nodes of the communication node perform such a detection process, the two-way can be implemented for both nodes. Tested. In some cases, it may be necessary to perform bidirectional reachability detection on one of the two nodes of the communication node.
  • the detection process at this time may be 601-602 in FIG. 6.
  • the failure detection may also integrate other factors, such as the failure of the underlying link, such as the renumbering of the network or the invalidity of the interface, etc., which may indicate that the current communication address pair is invalid.
  • This embodiment describes a process of exploring available candidate address pairs between multi-homed host A and multi-homed host B.
  • HIP Probe HIP Probe
  • HIP Probe HIP Probe
  • This HIP packet name is only an example and does not constitute a limitation of the present invention.
  • the HIP Probe packet is divided into two subtypes, one is a HIP Probe request packet, and the other is a HIP Probe response packet.
  • the format of the HIP Probe packet is shown in Figure 8.
  • the HIP Probe packet shown in Figure 8 includes an IP header, a HIP header, and a HIP parameter part, where:
  • the source address and the destination address in the IP header are the address pairs to be explored;
  • the HIP header is the same as the HIP header defined by the existing HIP protocol, and the packet type is set to the Probe packet;
  • the HIP parameters include the request/response (Seq/Ack) indication parameter, the response (Echo) indication parameter, and some other parameters, such as a signature (Sig). )parameter.
  • Seq/Ack request/response
  • Echo response
  • Sig signature
  • FIG. 9 is a schematic diagram of an address pair exploration process according to Embodiment 3 of the present invention.
  • the host A A 2 is selected from the identifier the HI A corresponding Host A identity of the IP address A ⁇ address, Beta corresponding IP address from the host Beta identity ⁇ ⁇ and select an address to form a new present embodiment
  • the address pair such as (AB 2 ), (A 2 , Bj ) or (A 2 , B 2 ), in this embodiment, selects an address pair (AB 2 ) for reachability exploration, and the specific steps include:
  • the multihoming host A sends a Probe request packet to the multihomed host B, and instructs the multihomed host B to respond.
  • the host identity pair used by the Probe request packet is (HI A , HI B ), and the corresponding IP address pair is ( Aj , B 2 ).
  • the source address of the Probe packet is the address of Host A, and the destination address is the address B 2 of Host B.
  • the multihoming host B returns a Probe response packet to the multihoming host A.
  • the host identity pair used by the Probe response packet is (HI B , HI A ), and the corresponding IP address pair is (B 2 , Ai ) 0
  • the source address of the Probe packet is the address B 2 of the host B, and the destination address is the address of the host A.
  • host A receives the Probe response packet returned by host B, it indicates that the address pair (A l ⁇ 2 ) corresponding to the host identity pair is a valid address pair. It is also possible to set a timer in the host ,. If the timer has expired and the host A has not received the Probe response packet returned by the host B, the address pair (Aj , B 2 ) is considered invalid, otherwise the address pair is considered valid.
  • Host A can traverse all possible combinations of address pairs and determine the validity of these address pairs in the manner described above, so that once a communication failure occurs, the address pair that is considered to be valid can be enabled immediately. .
  • This embodiment describes a communication recovery procedure between the multi-homed host A and the multi-homed host B after the current communication fails.
  • the process of failure detection may be the detection process described in Embodiment 2, or may be other failure detection processes
  • communication recovery is required, that is, a pair is explored.
  • the process of exploring a pair of new address pairs for communication includes selecting an address pair (selecting the address pair is a category of address selection, which is clearly defined in RFC 3484, not detailed here), and using the selected address pair Session exploration to verify that the address pair is valid.
  • HIP Probe HIP Probe
  • Specific definition of the HIP Probe group is as an embodiment. Three said.
  • FIG. 10 it is a schematic flowchart of Embodiment 4 of the present invention.
  • the host A and the host The IP address corresponding to the A identity identifier HI A and the address selected in A 2 are selected from the IP address ⁇ and the IP address corresponding to the host B identity HI B to form a new address pair.
  • the address pair is selected. (A l ⁇ 2 ) for reachability exploration, the specific method of address exploration is similar to that of Figure 9, including:
  • the multi-homed host sends a Probe request packet to the multi-homed host, and instructs the multi-homed host B to respond.
  • the host identity pair used by the Probe request packet is (HI A , HI B ), and the corresponding IP address pair is ( AB 2 ).
  • the source address of the Probe packet is the address of Host A, and the destination address is the address B 2 of Host B.
  • the request/response indication parameter in the Probe packet is set to the request type, indicating that the Probe packet is a request packet; the carried response indicates that the parameter value is set to require a response.
  • the multihoming host B returns a Probe response packet to the multihomed host A.
  • the host identity pair used by the Probe response packet is (HI B , HI A ), and the corresponding IP address pair is (B 2 , Aj ) 0.
  • the source address of the Probe packet is the address B 2 of the host B, and the destination address is the host. Address of A
  • the request/response indication parameter in the Probe packet is set to the response type, indicating that the Probe packet is a response packet; the carried response indicates that the parameter value is set to no response.
  • host A receives the Probe response packet returned by host B, it indicates that the address pair (A l ⁇ 2 ) corresponding to the host identity pair is a valid address pair. It is also possible to set a timer in the host ,. If the timer has expired and the host A has not received the Probe response packet returned by the host B, the address pair (Aj, B 2 ) is considered invalid, otherwise the address pair is considered valid.
  • host A determines that the address pair (A l ⁇ 2 ) is invalid, then reselect a pair of address pairs, such as ( ⁇ 2 , ⁇ 2 ), and judge the validity of the reselected address pair according to the above procedure until selection A pair of valid address pairs.
  • Host A and Host B can enable the address pair that is considered to be valid by the update packet defined by the HIP protocol.
  • the process can be as shown in FIG. In Figure 11, host A sends an update message to host B, carries the new SPI parameter, and carries the update sequence number, key exchange parameter DH, etc., and is carried by LACOTOR parameter 7 ( ⁇ B 2 ); host B receives After the update message completes the address update, an update response is returned to the host A, which carries the ACK acknowledgement information, and instructs the host A to respond; the host A returns an update message according to the indication to respond.
  • the host identity pair (HI A , HI B ) when Host A and Host B communicate does not change, and the IP address corresponding to the host identity pair ( ⁇ ⁇ , ⁇ ⁇ ) is changed. Correct.
  • the HIP upper layer communication is only related to the host identity pair (HI A , HI B ). Therefore, as long as the IP address pair has a corresponding relationship with the host identity pair, the change of the IP address pair does not affect the HIP upper layer communication.
  • a pair of valid address pairs are searched, and address pair switching is performed to implement communication recovery.
  • the candidate valid address pairs may also be explored in advance (the address pair exploration process may be as described in Embodiment 3), so that when the communication fails, a pair of address pairs may be directly selected from the candidate address pairs that are explored as valid. Perform address pair switching to achieve communication recovery.
  • Embodiments of the present invention also provide several multi-homing network nodes.
  • FIG. 12 is a schematic structural diagram of a multi-homing network node according to an embodiment of the present invention.
  • the network node includes: a messaging module 121, an address notification module 122, and an address storage module 123, wherein
  • the address notification module 122 is configured to instruct the message sending and receiving module 121 to send an address update message to the peer network node, and carry an IP address corresponding to the identity of the local network node, where the IP address is a candidate IP address for communication failure recovery;
  • the message sending and receiving module 121 is configured to send an address update message according to the indication of the address notification module 122.
  • the address update message sent and received by the messaging module 121 is carried by the HIP packet; the IP address is carried by the LOCATOR parameter of the HIP protocol in the address update message.
  • the message sending and receiving module 121 After the message sending and receiving module 121 sends the address update message to the peer end, it is also used to receive the response message returned by the peer end. After receiving the address update message carried by the peer end carrying the peer IP address, the message sending and receiving module 121 may also send an address update message to the opposite end according to the indication of the address notification module 122, and update the address at the sending address. The message carries the IP address corresponding to the identity of the local network node.
  • the address storage module 123 is configured to obtain the IP address received by the messaging module 121, establish a correspondence between the IP address and the identifier of the peer network node, and store the IP address.
  • FIG. 13 is a schematic structural diagram of a multi-homed network node according to an embodiment of the present invention.
  • the network node includes: a message sending and receiving module 131 and a detecting and determining module 132, where
  • the message sending and receiving module 131 is configured to send a connection hold request message ( Keepalive request;) to the communication peer network node, and instruct the peer network node to respond; and receive a connection hold response message ( Keepalive response) returned by the peer network node.
  • the messaging module 131 can send a connection hold request message according to a set period, or send a connection hold request message when there is no current session.
  • the keepalive request message sent by the messaging module 131 and the received keepalive response message are carried by the HIP packet;
  • the HIP parameter in the HIP packet bearer includes an indication parameter for identifying the message type, and a response for identifying whether the peer response is needed.
  • Indication parameter for identifying the message type, and a response for identifying whether the peer response is needed.
  • the message type parameter in the keepalive request message is set to the request type, and the response indication parameter is set to require the peer response; the message type parameter in the keepalive response message is set to the request and response type, and the response indication parameter is set to require the peer response.
  • the detecting and determining module 132 is configured to determine whether the message sending and receiving module 131 receives the connection hold response message returned by the peer network node, and if yes, determine that the communication with the peer network node is normal; If it is not received, it is judged that the communication with the peer network node has failed.
  • the network node further includes: a timing module 133, configured to start timing after the message sending and receiving module 131 sends a connection hold request message; and the detection determining module 132 determines whether the message transmitting and receiving module 131 is at a specified time according to the timing of the timing module 133.
  • the connection hold response message is received, and if it is received within the specified time, it is judged that the communication with the peer network node is normal; if it is not received within the predetermined time, it is determined that the communication with the opposite network node fails.
  • FIG. 14 is a schematic structural diagram of a multi-homed network node according to an embodiment of the present invention.
  • the network node includes: a message sending and receiving module 141, an address selecting module 142, and an address searching module 143, wherein the address selecting module 142 is configured to be used from the local end.
  • a candidate IP address pool corresponding to the network node identifier and a candidate IP address pool corresponding to the peer network node identifier respectively form a new IP address pair;
  • the address search module 143 is configured to instruct the message sending and receiving module 141 to send a discovery request message (Probe request) to the peer network node, where the search request message indicates that the peer network node responds, and the source address and the destination address of the request message are The IP address of the new address pair; and when the messaging module 141 receives the discovery response message (Probe response) returned by the peer network node, it determines that the address pair selected by the address selection module 142 is valid; When receiving the discovery response message returned by the peer network node, determining that the address pair selected by the address selection module 142 is invalid;
  • the message sending and receiving module 141 is configured to send a Probe request message according to the indication of the address search module 143, and receive a Probe response message sent by the peer network node.
  • the discovery request message sent by the messaging module 141 and the received discovery response message are carried by the HIP packet, and the HIP packet includes an IP header, a HIP header, and a HIP parameter.
  • the source address and the destination address of the IP header are the IP addresses in the new address pair;
  • the HIP parameter includes an indication parameter for identifying a message type, and a response indication parameter that identifies whether the peer needs to respond;
  • the message type indication parameter in the discovery request message is set to the request type, and the response indication parameter is set. Set to require the peer response; the message type in the discovery response message indicates that the parameter is set to the response type, and the response indication parameter is set to not require the peer response.
  • the network node further includes: a timing module 144, configured to start timing after the message sending and receiving module 141 sends the discovery request message; and the address searching module 143 determines whether the message transmitting and receiving module 141 is within a prescribed time according to the timing of the timing module 144. A discovery response message is received, and if received, the new address pair is determined to be valid.
  • the network node includes: a communication detection module 151, an address selection module 152, an address search module 153, an address update module 154, and a message transceiver module 155.
  • the communication detecting module 151 is configured to detect a communication state between the local network node and the peer network node.
  • the communication detecting module 151 can instruct the message sending and receiving module 155 to send a connection holding request message, the request message instructs the peer network node to respond, and determines whether the message transmitting and receiving module 155 receives the connection hold response message returned by the peer network node, if Then, it is determined that the communication between the local network node and the peer network node is normal; if not, the communication between the local network node and the peer network node is determined to be unsuccessful.
  • the address selection module 152 is configured to: when the communication detection module 151 detects that the local network node fails to communicate with the peer network node, from the candidate IP address pool corresponding to the local network node identity, and the peer network node identity Each of the corresponding candidate IP address pools selects one IP address to form a new IP address pair;
  • the address search module 153 is configured to instruct the message sending and receiving module 155 to send a search request message to the peer network node, where the search request message indicates that the peer network node responds, and the source address and the destination address of the search request message are the new one.
  • the IP address of the address pair and when the messaging module 155 receives the discovery response message returned by the peer network node, the address update module 154 is activated;
  • the address update module 154 is configured to update the IP address pair corresponding to the local network node identifier and the peer network node identifier in the local network node to the new address pair, and use the messaging module 155 to the opposite end.
  • the network node sends an update request message, and the peer network node and the local network
  • the network node identifier corresponding to the network node identity and the peer network node identity is updated to the new address pair.
  • the message sending and receiving module 155 is configured to send the discovery request message and the update request message to the peer network node, and receive a corresponding response message returned by the peer network node.
  • the discovery request message sent by the messaging module 155 and the received discovery response message are carried by the HIP discovery packet;
  • the HIP packet includes an IP header, a HIP header, and a HIP parameter;
  • the source address and the destination address of the IP header are the IP addresses in the new address pair;
  • the HIP parameter includes an indication parameter for identifying a message type, and a response indication parameter that identifies whether the peer needs to respond;
  • the message type parameter in the discovery request message is set to the request type, and the response indication parameter is set to require the peer response; the message type parameter in the discovery response message is set to the request-response type, and the response indication parameter is set to require the peer response.

Landscapes

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

Abstract

L'invention concerne un procédé de notification et de recherche d'adresse de communication de nœud de réseau multidomestique, un procédé de détection et de reprise de communication et un nœud de réseau multidomestique. Dans le procédé de recherche de l'adresse de communication, le premier nœud de réseau envoie le message de demande de recherche au nœud d'extrémité en adoptant une paire d'adresses candidates, indique la réponse du nœud d'extrémité et détermine si les adresses candidates sont valables selon le résultat obtenu en déterminant si la réponse du nœud d'extrémité est reçue ; dans le procédé de détection de communication, le premier nœud de réseau envoie un message de demande de maintien de connexion au nœud d'extrémité pour indiquer la réponse du nœud d'extrémité et détermine si la communication est normale selon le résultat obtenu en déterminant si la réponse du nœud d'extrémité est reçue ; dans le procédé de reprise de communication, le premier nœud de réseau sélectionne la paire d'adresses candidates ou recherche une paire de nouvelles adresses valables lorsque la communication a échoué et met à jour la paire d'adresses actuelles en adoptant l'adresse candidate ou la paire d'adresses valables recherchées. En utilisant l'invention, il est possible de réaliser la détection et la reprise de la communication du hôte multidomestique en utilisant les caractéristiques de l'hôte multidomestique.
PCT/CN2008/071488 2007-07-01 2008-06-30 Procédé et dispositif de notification, de recherche d'adresse de communication et procédé et dispositif de détection, de reprise de communication WO2009003405A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200710126798A CN101335747B (zh) 2007-07-01 2007-07-01 通信地址通知、探索及通信检测、恢复方法及其装置
CN200710126798.4 2007-07-01

Publications (1)

Publication Number Publication Date
WO2009003405A1 true WO2009003405A1 (fr) 2009-01-08

Family

ID=40198055

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/071488 WO2009003405A1 (fr) 2007-07-01 2008-06-30 Procédé et dispositif de notification, de recherche d'adresse de communication et procédé et dispositif de détection, de reprise de communication

Country Status (2)

Country Link
CN (1) CN101335747B (fr)
WO (1) WO2009003405A1 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI501601B (zh) * 2011-08-15 2015-09-21 Mediatek Inc 裝置搜尋的處理方法
CN102957573B (zh) * 2011-08-24 2017-05-17 中兴通讯股份有限公司 一种路径检测的实现方法及节点
US10034340B2 (en) 2011-10-06 2018-07-24 Philips Lighting Holding B.V. Electrical lighting system power control
CN102801825B (zh) * 2012-08-29 2015-06-17 清华大学 终端多ip地址有效性检测方法
CN107864082B (zh) * 2016-09-22 2020-08-21 腾讯科技（深圳）有限公司 消息发送方法及装置
US10797959B2 (en) * 2017-08-11 2020-10-06 Quanta Computer Inc. LLDP based rack management controller
CN109962991B (zh) * 2017-12-26 2022-06-14 中国移动通信集团四川有限公司 物联网故障处理方法、装置、设备及介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005081466A1 (fr) * 2004-02-13 2005-09-01 Telefonaktiebolaget Lm Ericsson (Publ) Methode et appareil d'adressage pour etablir des connexions de protocole d'identite (hip) entre un noeud existant et un noeud hip
WO2005101753A1 (fr) * 2004-04-15 2005-10-27 Telefonaktiebolaget Lm Ericsson (Publ) Procede et appareil d'identification permettant d'etablir les connexions du protocole d'identite de l'hote (pih) entre les noeuds existants et les noeuds pih
CN1741523A (zh) * 2004-08-25 2006-03-01 华为技术有限公司 一种实现主机移动性和多家乡功能的密钥交换协议方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100493227C (zh) * 2004-11-15 2009-05-27 华为技术有限公司 一种网络侧对更新ip地址的用户的处理方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005081466A1 (fr) * 2004-02-13 2005-09-01 Telefonaktiebolaget Lm Ericsson (Publ) Methode et appareil d'adressage pour etablir des connexions de protocole d'identite (hip) entre un noeud existant et un noeud hip
WO2005101753A1 (fr) * 2004-04-15 2005-10-27 Telefonaktiebolaget Lm Ericsson (Publ) Procede et appareil d'identification permettant d'etablir les connexions du protocole d'identite de l'hote (pih) entre les noeuds existants et les noeuds pih
CN1741523A (zh) * 2004-08-25 2006-03-01 华为技术有限公司 一种实现主机移动性和多家乡功能的密钥交换协议方法

Also Published As

Publication number Publication date
CN101335747A (zh) 2008-12-31
CN101335747B (zh) 2012-10-03

Similar Documents

Publication Publication Date Title
US7437479B2 (en) Position identifier management apparatus and method, mobile computer, and position identifier processing method
JP4579934B2 (ja) レガシーノードとｈｉｐノード間のホストアイデンティティプロトコル（ｈｉｐ）接続を確立するためのアドレス指定方法及び装置
JP4417417B2 (ja) ピア・ツー・ピア接続の確立方法
WO2009003405A1 (fr) Procédé et dispositif de notification, de recherche d'adresse de communication et procédé et dispositif de détection, de reprise de communication
US6061728A (en) Arrangement for controlling network proxy device traffic on a transparently-bridged local area network using a master proxy device
JP3665622B2 (ja) ソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法
WO2010118604A1 (fr) Procédé, système et dispositif de mise en oeuvre de séparation d'identifiant d'identité et d'emplacement
JP2006086800A (ja) ソースアドレスを選択する通信装置
WO2011035667A1 (fr) Procédés et systèmes pour réaliser une itinérance interréseau, interroger et rattacher un réseau
WO2006050672A1 (fr) Procede de communication entre noeuds serveurs de prise en charge de services de radiotransmission par paquets generaux
WO2010060304A1 (fr) Système de communication de données, routeur, procédé de transmission de données et de gestion de mobilité
WO2012126335A1 (fr) Procédé de contrôle d'accès, dispositif d'accès et système
WO2011120365A1 (fr) Procédé et système d'établissement de connexion entre terminaux multiconnectés
Stapp DHCPv6 Bulk Leasequery
AU2004214282B2 (en) Terminating a session in a network
US20080219271A1 (en) IP multicast based systems, apparatuses and methods for TCP connection migration
WO2011120276A1 (fr) Procédé et système permettant d'établir une connexion entre des terminaux
WO2011044810A1 (fr) Procédé, dispositif et système pour mettre en oeuvre une communication partagée
Cisco Commands: debug ppp bap through debug sdllc
JP2006019934A (ja) パケット交換網の呼設定方法
Pierrel et al. A policy system for simultaneous multiaccess with host identity protocol
JP6898120B2 (ja) ネットワークシステム、ネットワークシステムのアドレス解決方法、および、拠点側接続装置
WO2011044835A1 (fr) Procédé et routeur d'accès pour optimisation de trajet
JP4791402B2 (ja) 移動通信システム及び移動通信プログラム
WO2012059010A1 (fr) Procédé et système de transfert pour un point d'accès de protocole d'identification d'un hôte

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: 08773066

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08773066

Country of ref document: EP

Kind code of ref document: A1