Source: https://patents.google.com/patent/US7492787B2/en
Timestamp: 2019-12-09 11:15:44
Document Index: 60243937

Matched Legal Cases: ['art 700', 'art 700', 'Application No. 03', 'Application No. 03', 'Application No. 03251755', 'Application No. 03251755', 'Application No. 2003']

US7492787B2 - Method, apparatus, and medium for migration across link technologies - Google Patents
US7492787B2
US7492787B2 US10/108,473 US10847302A US7492787B2 US 7492787 B2 US7492787 B2 US 7492787B2 US 10847302 A US10847302 A US 10847302A US 7492787 B2 US7492787 B2 US 7492787B2
US20030185233A1 (en
230000027455 binding Effects 0 abstract claims description 40
238000009739 binding Methods 0 abstract claims description 37
238000005516 engineering processes Methods 0 claims description 70
There are currently multiple network link technologies, including the Ethernet, wireless local area network (WLAN), Bluetooth, infrared, and others. A network interface card (NIC) implements a network link technology. Characteristics of concurrent network links are that there is no “one-size-fits-all” solution, computing devices likely have multiple interfaces installed, multiple network link options improve user connectivity (by providing different network connection environments and redundant connections), and they are an important feature for mobile computing devices.
Different wireless communication technologies are typically developed for different purposes. For instance, the Bluetooth (IEEE 802.15) and the Infrared technologies are aimed at short-range personal communication (<10 m) while the Wireless LAN (IEEE 802.11, IEEE 802.11b, IEEE 802.11a) is for providing mid-range communication services (<1km). Other wireless communication technologies such as 3-G wireless, wireless routers (i.e., Flash-OFDM Radio Router by Flarion, etc.), and satellite wireless access, are for serving rather large service areas (cells). Due to cost, performance, and many other issues, it is likely that multiple technologies will co-exist in the world of mobile computing because there is simply no “one-size-fits-all” solution. Thus, connectivity-enthusiastic users will be likely to have multiple interface cards installed in their computing device at the same time. Even for small PDA devices there can be multiple network interfaces such as an Infra Red (IR) port or a NIC through PCMCIA, USB, or Compact Flash interfaces. Throughout, the “service area” of each wireless communication technology is referred to as the geographic region in which the link will function under normal operating conditions. Sometimes the same term is used on a wired link technology. In this case it means the region where the user can plug the wired network medium (cable) into his/her computer.
Networks in the Internet are frequently organized into broadcast domains to facilitate routing and other administrative functions. A broadcast domain is the subset of a network within which broadcast ARP messages are distributed to all member host computers. Structurally, this domain may include multiple segments of broadcast mediums, possibly of different underlying link technologies. Over each single broadcast segment, any data frames carried by the network medium can be received by all hosts attached to the segment. These segments can be connected together via devices such as repeaters, hubs (multi-port repeaters), and switches to form larger broadcast segments. These bigger broadcast segments can then be connected using various bridging mechanisms (including any variations of the IEEE 802.1 standard, such as the MAC bridges defined by IEEE 802.1D and the Virtual LANs or VLANs as defined by IEEE 802.1Q) to form a “broadcast domain”. Since bridging devices typically perform filtering at the Medium Access Control (MAC) level and not all MAC broadcast frames are distributed over all bridged broadcast segments, some common usage of the term “broadcast domain” excludes bridged broadcast segments. In the above-mentioned definition, as long as broadcast ARP messages can pass through these bridging devices, the bridged broadcast segments are considered to belong to the same broadcast domain. For simplicity the terms “subnet:, “Local Area Network” or “LAN” and “broadcast domain” are used interchangeably. Also, in the following context, the terms “node”, “host”, and “MCD” are used interchangeably. Sometimes an MCD may be referred to using one of these terms as well when it is not particularly important to emphasize mobility.
The configuration of MCD 110 shown in FIG. 1 is not very common for end hosts on the wired Internet, which usually have only one network interface. Computers with multiple network interfaces are traditionally called “multi-homed” and are set up for data packet forwarding purposes such acting as a router, gateway, or performing firewall functions. Different interface cards on a “multi-homed” computer are typically assigned addresses on different subnets. Because Internet routing is interface-oriented, how a packet is routed into interface A of the destination computer is independent of how a packet is routed into interface B of the same computer. Moreover, the network will treat the routing to interface B as if it is routing for a totally different destination host.
The present invention is based on an extension of the Address Resolution Protocol (ARP) [RFC (Request for Comment, published by the Internet Engineering Task Force (IETF)) 826, D. Plummer, “An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Addresses for Transmission on Ethernet Hardware”, RFC826, November 1982], commonly used on local area networks (LANs) connected to the internet.
Moreover, the present invention makes use of the “Proxy ARP” and “Gratuitous ARP” methods to correctly reroute IP packets at the link level following a link technology switch and the maintenance of an associated “Interested Host Cache”.
As shown in FIG. 4A, the MALT of the present invention includes Link Migration Module (or MALT module) 510. Link Migration Module (LMM) 510 includes MALTARP Module (MAM) 512 and Link Sensing Module (LSM) 514. The MAM 512 (which performs on both proxy and gratuitous ARP messages), includes Interested Host Cache (IHC) module 516. When MALT module 510 needs to send an ARP message 518, it sends the message via conventional socket layer 520. Moreover, LMM 510 issues an “update local MAC to IP mapping” command 522 to conventional ARP engine 524 so it will reply to future queries for any of the MCD's local IPs with the MAC address of the preferred interface. Additionally, LMM 510 sends an “update binding” command 526 to initiate the dynamic MAC to IP binding operation through the Dynamic MAC to IP Binding Module (DBM) 528 of the present invention. DBM 528 of the present invention interfaces, in the NDLR 529, between IP processing 530 and MAC processing 532. Moreover, LSM 514 interfaces 534 to device drivers 536 and network interface 538 to obtain link quality information.
FIG. 6 shows the update_preferred_interface state flowchart 700 of the present invention, corresponding to the update_preferred_interface function 608 of the present invention shown in FIG. 5. Referring now to FIG. 6, after beginning the update_preferred_interface state flowchart 700, a link selection algorithm is executed 704 to determine the preferred interface. Subsequently, determination is made as to whether a different interface was selected 706. If a different interface was not selected, then the update_preferred_interface state flowchart ends 708. Alternatively, if a different interface was selected 706, then using the new interface, the local routing table is updated, and the local dynamic MAC to IP binding is updated 710. Then, for each local interface, one gratuitous ARP_REQUEST is broadcast 712 announcing the new mappings: (local interface IP maps to the preferred interface MAC). Next, and optionally, one ARP_REPLY is unicast 714 for each entry in the IHC, specifically announcing the new mapping to each “interested host”. Function 714 is not necessary to be executed if the underlying communication channel is highly reliable for broadcast communication. However, function 714 is needed to be executed when the channel is only reliable for unicast communication but unreliable for broadcast communications.
Using the link detection and selection algorithm included in link sensing module 514 of the present invention, link availability may be tested by having the mobile computing device periodically poll a server on the wired portion of the network via different link technologies. Another solution may not require the “link availability server” thus can be implemented completely on the MCD without introducing extra components to the network. For example, the mobile computing device may periodically send a ping message to the “all-host” multicast address 224.0.0.1 from each of its own interfaces and observe the echoes to determine the link availability. Link quality may be tested via various statistical and status readings from the device such as packet loss rate, signal quality, noise level, transmission rate, etc. The user may also input a cost factor for each technology so that economic reasons can also be considered in link sensing module 514. A user specified priority list (which is generally known in the art) can also be used as an alternative or in addition to the above-mentioned criteria. A link selection daemon can be implemented that periodically runs the link detection algorithm to determine which link is the best choice. If the current link is no longer the best option, and the new optimum is significantly better than the current selection, the daemon can initiate a link switch.
Such a mapping between an IP address and a MAC for a remote interface is typically learned by nodes exchanging ARP messages. When a mapping is needed but unknown, the transmitting node sends out a local broadcast ARP_REQUEST message asking “who knows the MAC address of this IP address, please tell me”. The interface whose IP address is being asked for will then reply within an ARP_REPLY message containing the mapping. The learned mapping information is then put into an ARP cache on the requesting node so future requests for the MAC address of the same IP address can be resolved without asking other nodes on the network. Cached entries may age and eventually be removed by timeout.
That is, when a node switches the mapping for IP1 1020 from MAC1 1022 to MAC2 1032, other nodes on the same subnet need to be notified of the mapping change so that if they have packets for IP1 1020, the packets can be sent in MAC envelopes addressed to MAC2 1032 (over link Tech2 1034). For informing other nodes on the network about the new mapping, the MALT of the present invention presents a new extension of the ARP protocol. The MALT extension is based upon a combination of the “Proxy ARP” [RFC925, J. Postel, “Multi-LAN Address Resolution Protocol, RFC925, October 1984] and the “Gratuitous ARP” [W. Richard Stevens, “TCP/IP Illustrated, Volume 1: The Protocols”, page 62, Addison-Wesley, Reading, Mass., 1994], two current special uses of the ARP protocol. The Proxy ARP is the mechanism for a router to answer ARP_REQUEST on one of its networks for a host on another of its networks.
The MALT of the present invention does not restrict the addressing for interfaces as long as they are on the same subnetwork. An interface should be able to proxy for any other interfaces on the same host. On the other hand, at any given time, MALT only allows the “preferred” interface of that moment to proxy for other local interfaces by replying to ARP_REQUEST's querying for any of the host's interfaces. In the ARP_REPLY, the requested MAC address is set to the MAC address of the preferred interface.
Normally, the existing ARP uses a “poll” model where a requester queries and the other parties reply. The Gratuitous ARP introduces a way to “push” address mappings to other hosts on the network. However, the “pushed” mapping is broadcast to the network in an ARP_REQUEST message. Due to the special characteristics of wireless and mobile communication, such a mechanism is highly unreliable. Hosts connecting to the network via wireless links may not receive this message. Thus the MALT of the present invention introduces an additional mechanism to refresh the caches on other hosts in a more reliable manner.
In the MALT of the present invention, a mobile computing device maintains a separate cache, referred to as the Interested Host Cache (IHC) and shown as element 516 in FIGS. 4A and 4B. The IHC 516 stores the identities of those who have asked for MAC address mappings of any of the MCD's own IP addresses and those who the MCD asked for their address mappings. These foreign hosts are named “Interested Hosts”. In the ARP protocol, the host whose hardware address is requested will also remember the address mapping of the requester, since ARP assumes bidirectional communication. That is, if one host's address mapping is requested, then someone is attempting to talk with this host, and this host will likely talk back. Therefore, caching the ARP requester's address mapping will save this host from asking the requester again later. Thus, those from whom a MCD asked for the address mapping will also store the mapping for the MCD (contained in the ARP_REQUEST sent by the mobile computing device) and also need to be updated.
Currently, although various link quality testing mechanisms exist, they are not typically integrated with the MCD networking kernel. If a MCD needs to switch between link technologies, without the MALT technology the user needs to configure the changes manually. In addition, during a link technology switch, transport connections will be terminated in current systems. Some applications do employ their own “keep-alive” mechanisms to maintain communication sessions in such events. However, because the session layer typically does not have enough API support, these mechanisms are very simple. Even for these “smart” applications, usually it takes very long (10's of seconds even minutes) for the application to discover the link termination and re-establish the connection. On the other hand, since MALT is able to maintain transport connections while switching between link technologies, communication sessions are not affected at all.
TABLE 1 MALT Advantages Current Technology MALT Link Technology Quality Not integrated with Link quality Sensing networking kernel auto-sensing Switch Between Link Manually configured Auto-switch based on Technologies link quality and user profile Transport Connection Terminated Maintained During Link Switch Communication Session Interrupted Uninterrupted During Link Switch
Although a simple method for determining when to cause a link switch and how to choose the best “link” for a switch is presented, the present invention is not limited to such a method as various methods of same are possible.
35. The computer-readable medium as in claim 22, wherein said first link element has a different link technology than said second link element.
DE2003606832 DE60306832T2 (en) 2002-03-29 2003-03-20 Method, device and medium for switching connection technologies
US20030185233A1 US20030185233A1 (en) 2003-10-02
US7492787B2 true US7492787B2 (en) 2009-02-17
US20130322433A1 (en) * 2011-03-16 2013-12-05 Michael Tietsch Method for setting up a communication link
JP4121298B2 (en) * 2002-04-18 2008-07-23 松下電器産業株式会社 Communication terminal device and communication control method
DE60336998D1 (en) * 2003-07-03 2011-06-16 Alcatel Lucent Check for duplicate MAC addresses and dynamic allocation of MAC addresses
JP4427653B2 (en) * 2004-02-27 2010-03-10 独立行政法人情報通信研究機構 Frame relay method in layer 2 switch network
WO2006129680A1 (en) * 2005-05-30 2006-12-07 Matsushita Electric Industrial Co., Ltd. Communication device provided with arp function
JP4862463B2 (en) * 2006-04-11 2012-01-25 ブラザー工業株式会社 Information communication system, content catalog information search method, node device, etc.
JP4655986B2 (en) * 2006-04-12 2011-03-23 ブラザー工業株式会社 Node device, storage control program, and information storage method
JP5638063B2 (en) * 2010-03-23 2014-12-10 キヤノン株式会社 Communication device, communication device control method, program
CN104301195B (en) * 2011-11-04 2017-12-19 迈普通信技术股份有限公司 A kind of method and system of 3G communications
US8995443B2 (en) * 2012-07-31 2015-03-31 Qualcomm Incorporated Address resolution mechanism for hybrid communication networks
WO1997016793A1 (en) 1995-11-03 1997-05-09 Sterling Commerce, Inc. Value added network with multiple access methodology
US20010020275A1 (en) 2000-03-04 2001-09-06 Arkko Jari Communication node, communication network and method of recovering from a temporary failure of a node
US20010024437A1 (en) 1998-09-22 2001-09-27 Bender Paul E. Distributed infrastructure for wireless data communications
"Dynamic Network Driver Interface Specification Media Access Control of High-Level Data Link Control and LAN Protocols", IBM TDB Database, #NN9311559, Nov. 1, 1993, (contents same as 5,630,061). *
Communication from the European Patent Office including Search Report mailed Jul. 29, 2003.
Communication pursuant to Article 96(2) EPC issued by the European Patent Office on Nov. 15, 2004 in corresponding European Application No. 03 251 755.9-2412 (4 pages).
Communication pursuant to Article 96(2) EPC issued by the European Patent Office on Nov. 3, 2003 in corresponding European Application No. 03 251 755.9-2412 (4 pages).
Decision on further processing under Article 121(3) EPC issued by the European Patent Office on Mar. 29, 2006 in corresponding European Application No. 03251755.9-2412 (1 page).
Decision to grant a European patent pursuant to article 97(2) EPC issued by the European Patent Office on Jun. 22, 2006 in corresponding European Application No. 03251755.9-2412 / 1349322 (1 page).
John Ionnidis et al., "IP-based Protocols for Mobile Networking", Computer Communications Review Association for Computing Machinery, New York, US, vol. 21, No. 4, Sep. 1, 1991,pp. 235-245.
Network Working Group, Request for Comments: 826, David C. Plummer (DCP@MIT-MC), dated Nov. 1982, "An Ethernet Address Resolution Protocol-or-Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", http://www.faqs.org/rfc/rfc826.txt, pp. 1-8, printed Mar. 28, 2002.
Network Working Group, Request for Comments: 925, J. Postel, ISI, dated Oct. 1984, "Multi-LAN Address Resolution", http://www.faqs.org/rfc/rfc925.txt, pp. 1-15, printed Mar. 28, 2002.
Official Action issued by the Japanese Patent Office on Dec. 18, 2007 in the corresponding Japanese Patent Application No. 2003-083697 (3 pages).
RFC 793. Transmission Control Protocol, www.faqs.org/ftp/rfc/pdf/rfc793.txt.pdf, pp. 4 & 40-41, TCP timeout mechanism. *
W. Richard Stevens, "TCP/IP Illustrated, Volume 1: The protocols," chapter 4-ARP: Address Resolution Protocol (10 pages) and chapter 5-RARP: Reverse Address Resolution Protocol (4 pages) (Addison-Wesley, Reading, Massachusetts, 1994).
US9448821B2 (en) * 2010-10-19 2016-09-20 Zte Corporation Method and system for realizing virtual machine mobility
US9350870B2 (en) * 2011-03-16 2016-05-24 Unify Gmbh & Co. Kg Method for setting up a communication link
US9742817B2 (en) 2011-03-16 2017-08-22 Unify Gmbh & Co. Kg Method for setting up a communication link
US10212197B2 (en) 2011-03-16 2019-02-19 Unify Gmbh & Co. Kg Method for setting up a communication link
US20030185233A1 (en) 2003-10-02