(12) United States Patent
`Swales
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 6,982,953 B1
`Jan. 3, 2006
`
`USOO6982.953B1
`
`(54) AUTOMATIC DETERMINATION OF
`CORRECT PADDRESS FOR
`NETWORK-CONNECTED DEVICES
`
`75
`(75) Inventor: Andrew G. Swales, Windham, NH
`
`(73) Assignee: Scorpion Controls, Inc., Hampton, NH
`(US)
`
`6,567,405 B1* 5/2003 Borella et al. .............. 370/389
`6,597,700 B2 * 7/2003 Golikeri et al. ............. 370/401
`6,601,101 B1* 7/2003 Lee et al. .........
`... 709/227
`6,636,499 B1* 10/2003 Dowling ....
`... 370/338
`6,654,796 B1* 11/2003 Slater et al.
`... 709/220
`2003/0217041 A1 11/2003 Mao .............................. 707/1
`FOREIGN PATENT DOCUMENTS
`
`WO
`
`WO 01/50711 A1
`
`7/2001
`
`OTHER PUBLICATIONS
`
`Internet standard document RFC 951, Bootstrap Protocol
`(BOOTP), Sep. 1985, pp 1-12.
`Internet standard document RFC 1531, Dynamic Host
`Configuration Protocol, Oct. 1993, pp 1-39.
`Internet standard document RFC 1493, Definitions of Man
`d Obi
`for Bridges, Jul 1993
`1-34
`age
`jects for Bridges, Jul.
`, pp 1-34.
`EP Search Report dated Nov. 8, 2004 of Patent Application
`No. 0096 0131 filed Jul 11, 2000.
`sk -
`cited by examiner
`Primary Examiner-Khanh Dinh
`(74) Attorney, Agent, or Firm-Maine & Asmus
`(57)
`ABSTRACT
`The present invention is for automatic reconfiguration of
`industrial networked devices. More particularly, the System
`described herein facilitates use of TCP/IP networks, such as
`Ethernet, as an alternative for industrial fieldbus or device
`buses by removing the need to perform Significant recon
`figuration of devices Such as I/O modules, Sensors, or
`transducers under field replacement Situations. The present
`invention uses a monitor agent to track the IP and MAC
`addresses of networked devices as well as port information.
`If a device fails, maintenance perSonnel make an in-field
`replacement of the failed device and the monitor agent
`automatically reassigns the IP address to the replacement
`device.
`
`24 Claims, 8 Drawing Sheets
`
`(*) Notice:
`
`-
`
`0
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 714 days.
`(21) Appl. No.: 09/614,489
`
`22) Filled
`CC
`
`Jul. 11, 2000
`ul. II,
`
`(51) Int. Cl.
`(2006.01)
`H04J III6
`(52) U.S. Cl. ...................... 370/218; 709/220; 709/221;
`370/245; 370/216
`(58) Field of Classification Search ................ 709/203,
`709/206, 208, 217, 226, 227, 228, 245, 225,
`709/220, 221; 370/254, 218, 245, 216, 217,
`370/466; 364/131; 714/25, 48
`See application file for complete Search history.
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`5.432,907
`5.490.252
`5,526,489
`5,751,967
`6,047.222
`6,055,236
`6,061,739
`6,108,300
`6,392,990
`6,532,088
`6,532.241
`
`7/1995
`A *
`A 2/1996
`A 6/1996
`A * 5/1998
`A 4/2000
`A * 4/2000
`A 5/2000
`A * 8/2000
`B1* 5/2002
`B1* 3/2003
`B1* 3/2003
`
`PicaZo et al. ............... 709/249
`Macera et al. .............. 709/206
`Nilakantan et al.
`Raab et al. ................. 709/228
`Burns et al. .................. 700/79
`Nessett et al. .............. 370/389
`Reed et al.
`Coile et al. ................. 370/217
`Tosey et al. ................ 370/218
`Dantu et al. .................. 398/43
`Ferguson et al. ........... 370/469
`
`Supervisor
`
`---
`
`
`
`
`
`
`
`250
`
`Managed Switch
`2 3 4 5 6
`
`300
`
`
`
`
`
`TargetIP
`unit
`1234
`
`220
`
`Unmanaged switch or hub
`
`TargetP
`unit
`1.2.35
`
`310
`
`320
`targe IP /
`unit
`12.3.6
`
`1. ARP Request - inquire MAC address of selected IP address 1.2.3.6 (unicast)
`2. ARP response - MAC address of requested IP address is xxx
`If no response is received, signify that the targetIP unit is “down
`If 1.2.3.6 is the ONLY unit on port 3 of the switch which is down, then it is a
`candidate for automatic reallocation. If any of the other units found on this port are
`also down, automatic reallocation will be suppressed.
`
`Page 1 of 22
`
`

`

`U.S. Patent
`
`Jan. 3, 2006
`
`Sheet 1 of 8
`
`US 6,982,953 B1
`
`10
`
`Enterprise Net
`
`Local Plant Area
`
`20
`
`Managed Ethernet Switch
`
`Port 1
`
`Port 9
`
`HUB
`
`40 uly
`
`Port
`
`POrt
`
`Port
`
`Port
`
`HUB
`
`Port
`
`Port
`
`- I/O
`
`45
`
`I/O
`
`PLC
`
`60
`
`FIG. 1
`
`Page 2 of 22
`
`

`

`U.S. Patent
`
`Jan. 3, 2006
`
`Sheet 2 of 8
`
`US 6,982,953 B1
`
`10
`N
`Monitor Agent
`
`Enterprise Net
`
`Local Plant
`
`20
`
`Managed Ethernet Switch
`
`Port 1
`
`Port 9
`
`HUB
`
`40
`
`HUB
`
`Port 1
`
`Port 2
`
`Port 3
`
`Port
`
`Port
`
`Port
`
`
`
`70
`
`MAC=ABC
`IP=10.0.0.1
`-
`MAC=DEF
`
`I/O
`
`I/O
`
`PLC
`
`Ali/AC=EFG I/O
`
`IP=10.0.0.3
`
`100
`
`O
`
`MACHIJ
`IP= O.O.O.3
`
`FIG. 2
`
`Page 3 of 22
`
`

`

`U.S. Patent
`
`Jan. 3, 2006
`
`Sheet 3 of 8
`
`US 6,982,953 B1
`
`200
`
`Managed Switch
`2 3 4 5 6
`
`
`
`
`
`Target IP
`unit w.x.y.z
`
`220
`
`1. ARP Request - inquire MAC address of IP address w.x.y.z
`(broadcast)
`2. ARP response - MAC address of requested IP address is XXX
`3. SNMP Findport request - request port number of MAC XXX
`4. SNMP Findport response - port number of MAC XXX was 3
`
`FIG 3
`
`Page 4 of 22
`
`

`

`U.S. Patent
`
`Jan. 3, 2006
`
`Sheet 4 of 8
`
`US 6,982,953 B1
`
`200
`
`Supervisor
`
`v - -
`
`250
`
`300
`
`320
`
`wa
`
`3
`
`Managed Switch
`r-
`/ 1 2 3 4 5 6
`
`2
`
`Unmanaged Switch or
`Hub
`
`220
`
`310
`
`
`
`Target IP
`
`Target IP
`unit 1.2.3.6
`
`1. ARP Request - inquire MAC address of selected IP address 1.2.3.4
`(broadcast)
`2. ARP response - MAC address of requested IP address is XXX
`3. SNMP Findport request - request port number of MAC XXX
`4. SNMP Findport response - port number of MAC xxx was 3
`Targets are automatically determined to be sharing port 3 of the switch.
`
`FIG. 4
`
`Page 5 of 22
`
`

`

`U.S. Patent
`
`Jan. 3, 2006
`
`Sheet 5 of 8
`
`US 6,982,953 B1
`
`200
`
`
`
`Supervisor
`
`
`
`
`
`220
`
`Managed Switch
`1 2 3 4 5 6
`
`1. ARP Request - inquire MAC address of selected IP address
`(unicast)
`2. ARP response - MAC address of requested IP address is XXX
`If no response is received, signify that the target IP unit is
`down
`
`FIG.S
`
`Page 6 of 22
`
`

`

`U.S. Patent
`
`Jan. 3, 2006
`
`Sheet 6 of 8
`
`US 6,982,953 B1
`
`200 N.
`
`\
`
`\
`
`
`
`220
`
`Managed Switch
`1 2 3 4 5 6
`
`300
`
`Unmanaged switch or hub
`
`320
`
`310
`-1
`
`Target IP
`unit
`1.2.3.6
`
`1. ARP Request - inquire MAC address of selected IP address 1.2.3.6 (unicast)
`2. ARP response - MAC address of requested IP address is XXX
`If no response is received, signify that the target IP unit is 'down
`If 1.2.3.6 is the ONLY unit on port 3 of the switch which is down, then it is a
`candidate for automatic reallocation. If any of the other units found on this port are
`also down, automatic reallocation will be suppressed.
`
`F.G. 6
`
`Page 7 of 22
`
`

`

`U.S. Patent
`
`Jan. 3, 2006
`
`Sheet 7 of 8
`
`US 6,982,953 B1
`
`200
`
`
`
`Managed Switch
`1 2 3 4 5 6
`
`1. BOOTP request - please supply IP address for MAC XXX
`(broadcast)
`2. SNMP Findport request - request port number of MAC xxx
`3. SNMP Findport response - port number of MACXXX was 3
`(MAC xxx already associated with IP at that canonical location -
`OK to assign)
`4. BOOTP response - IP address for MAC XXX is w.x.y.z
`
`FG. 7
`
`Page 8 of 22
`
`

`

`U.S. Patent
`
`Jan. 3, 2006
`
`Sheet 8 of 8
`
`US 6,982,953 B1
`
`200
`
`
`
`
`
`Target IP
`unit -
`
`Managed Switch
`1 2 3 4 5 6
`
`1. BOOTP request - please supply IP address for MAC xxx (broadcast)
`2. SNMP Findport request - request port number of MAC XXX
`3. SNMP Findport response - port number of MAC xxx was 3
`(MAC XXX not known. However a single unit at that location is not
`currently responding. Update BOOTP equivalence table to record new IP
`assignment and authorize assignment)
`4. BOOTP response - IP address for MAC xxx is w.x.y.z
`
`FIG. 8
`
`Page 9 of 22
`
`

`

`TECHNICAL FIELD OF THE INVENTION
`
`The present invention relates generally to networked
`devices. More specifically, the present invention relates to a
`System of assigning addresses to network devices, and more
`Specifically, to a System encompassing automatic assign
`ment of a network address after in-field replacement.
`
`BACKGROUND OF THE INVENTION
`
`15
`
`25
`
`35
`
`40
`
`US 6,982,953 B1
`
`1.
`AUTOMATIC DETERMINATION OF
`CORRECT IPADDRESS FOR
`NETWORK-CONNECTED DEVICES
`
`2
`Reverse ARP (RARP) is an older protocol than BOOTP
`and intended for devices that did not require any configu
`ration other than the IP address assignment. RARP is not as
`widely used as BOOTP because the tools to implement
`RARP are not as commonplace. RARP is implemented on
`Some embedded System protocol stacks, wherein the Super
`visory server may respond with a RARP response if inter
`rogated using a RARP request for a given MAC address.
`The MAC address is a key identification parameter of all
`devices on a network such as Ethernet. It is a 48-bit number
`that combines information about the vendor and a unique
`unit Sequence number, and is permanently allocated by the
`manufacturer of the network interface itself. It is not nor
`mally related in any way to the Serial number or similar
`representation that a device might require for other reasons.
`Industrial devices Such as temperature or pressure sensors
`The MAC address is conventionally expressed as a hexa
`are accessed by a client using an Internet Protocol (IP)
`decimal representation that is hard for non-specialists to
`Address or DNS symbolic name (machine.company.com). If
`a unit needs to be replaced, the replacement must appear to
`handle. The Ethernet hardware uses the MAC address to
`determine which network messages are intended for specific
`have the same IP Address as the predecessor to allow
`operations to proceed automatically. Typical maintenance
`delivery (unicast) to this station.
`PING is another Internet protocol used for periodic inter
`perSonnel are not qualified to manipulate IP Addresses and
`rogation of an IP device as an alternative to repeated use of
`must defer to Information Systems (IS) department or other
`the ARP request. There is little practical benefit for using
`network Specialists. This causes a significant delay in con
`PING, as the ARP messages are faster and less intrusive. All
`necting devices, which results in factory down-time. Alter
`modern IP devices will respond to an ARP request because
`natively, expensive specialists must be maintained around
`it is the only way to determine the MAC address.
`the clock to handle such problems.
`The prior art encompasses several networking techniques.
`An Ethernet Switch or Layer 2 switch is a device that
`transmits message packets unchanged from one of its ports
`The Bootstrap Protocol (BOOTP) is an established method
`to another, using rules that are dependent only upon the
`for assigning IP address and other key networking param
`destination MAC address of the message. Such devices are
`eters to a device where the only information known about
`becoming the preferred interconnection devices for large
`the device is its Ethernet Media Access Control (MAC)
`Ethernet networks, since they do not require significant
`address. The protocol was invented by Sun Microsystems in
`configuration. This is as opposed to routers, otherwise
`1985 to Support diskless UNIX workstations. It is available
`known as Layer 3 switches.
`as an option on most Software products intended for use in
`embedded (no operator terminal) applications.
`A Managed Ethernet Switch is an Ethernet switch which
`includes a management entity conforming to the reporting
`The Dynamic Host Configuration Protocol (DCHP) is a
`requirements of RFC 1493, and which therefore specifically
`Standard for networking communications. DCHP is a com
`may be interrogated to determine which port of the device
`patible extension to BOOTP and queries in DCHP form can
`was used recently to receive a message from a particular
`be generated by devices using modern operating systems
`MAC address.
`Such as Windows CE or LINUX.
`The protocol eXchanges between the system components,
`DCHP is primarily used for laptop computers or office
`namely the device, the managed Switch, and the target IP
`Systems in large companies where the addresses are leased
`for a period of time rather than being assigned indefinitely.
`unit are structurally defined in various standards documents.
`Software designers refer to these specifications when trying
`Likewise, the Simple Network Management Protocol
`(SNMP) is intended to allow Network Administrators to find 45 to implement software that encodes or decodes various
`and adjust key networking parameters on devices already
`messages. The Internet Request for Comment (RFC) docu
`installed on a network, particularly the routers, bridges, and
`ments are the Standard form of documents for all commu
`hubs which form the infrastructure of the network. The
`nications using the Internet or TCP/IP.
`Jet Admin Network Printer tool is a Hewlett-Packard system
`The following table defines the primary applicable Inter
`for reporting printer errors and administrating usage.
`net protocol messages:
`
`TABLE 1.
`
`ARP Request
`See RFC 826
`
`ARP Response
`See RFC 826
`
`Message type =
`address resolution
`request
`
`Desired IP
`address =
`32 bit IP address
`(eg. 1.2.3.4)
`
`Message type =
`address resolution
`response requested
`IPAddress
`Resolved MAC
`address =
`48 bit MAC address
`(eg: 01:23:45:67:89:ab)
`
`SNMP Findport
`Request
`See RFC 1493/1157
`Message type =
`SNMP get object
`request
`
`Object ID =
`.1.3.6.1.2.17.4.3.1.2.
`(MAC as 6 decimal
`number 0-255)
`
`SNMP Findport
`Response
`Message type =
`SNMP get object
`response
`
`BOOTP Request
`See RFC 951
`Message type =
`BOOT protocol
`request
`
`Object ID =
`.1.3.6.1.2.17.4.3.1.2.
`(MAC as 6 decimal
`number 0-255)
`Object value = port
`number, or 0 if not found
`
`Requesting MAC =
`48 bit MAC address
`(eg: 01:23:45:67:89:ab)
`
`BOOTP Response
`Message type =
`BOOT protocol
`response
`
`Requesting MAC =
`48 bit MAC address
`(eg: 01:23:45:67:89:ab)
`Assigned IP = 32 bit
`IPAddress
`
`Page 10 of 22
`
`

`

`3
`Alternatively, other Internet protocols messages are:
`
`US 6,982,953 B1
`
`TABLE 2
`
`PING Request
`See RFC 792
`
`DCHP Request
`PING Response See RFC 2131/2132
`Message type = Message type = Message contents =
`ICMPECHO
`ICMPECHO
`same as BOOTP
`request
`response
`Message data
`unimportant
`
`DCHP
`Response
`
`Message contents =
`same as BOOTP
`
`RARP Request
`See RFC 903
`Message type =
`reverse address
`resolution request
`MAC = 48 bit
`MAC address (e.g:
`01:23:45:67:89:ab)
`
`RARP Response
`Message type =
`reverse address
`resolution response
`MAC = 48 bit
`MAC address (e.g.:
`01:23:45:67:89:ab)
`Assigned IP =
`32 bit IP Address (eg.
`1.2.3.4)
`
`There have been numerous attempts to provide an auto
`matic addressing System. Many of the prior art Systems
`employ non-IP means to Set the address in advance, Such as
`manually alterable Switches, Special connectors, front panel
`interface for manually entering addresses, and Separate
`Serial port interface for issuing an address. Although these
`existing means are Satisfactory in Some instances, they do
`not adequately address the industrial or factory market for
`devices Such as Sensors and I/O devices. And, it is not
`feasible or cost-effective to employ the existing addressing
`techniques into certain devices or certain environments.
`Historically, almost all devices which have been attached
`to a TCP/IP network have been computer systems of some
`type, either of a conventional (with keyboard and display)
`or “embedded (Such as a network printer) type.
`In order to make a TCP/IP device functional on a network,
`it is necessary to assign certain address parameters, most
`importantly the 32-bit IP address. In many cases additional
`parameterS Such as netmask, gateway, and Domain Name
`Server Settings also need to be established. These Settings
`are important for proper performance, otherwise the network
`becomes unstable and exhibits erratic behavior affecting the
`performance not just of the device being configured, but also
`other devices on the network.
`The typical prior art Sequence for manual assignment of
`the IP address and other networking parameters begins with
`the direct assignment of the IP Address using a local data
`entry port prior to attachment on the network. This is
`normally accomplished through the operator panel or user
`interface. The operator assigns the IP address by keystroke
`and confirms the Settings before allowing communication on
`the network.
`One prior art method of automatic assignment of IP
`addresses uses BOOTP or DHCP. The BOOTP or DCHP
`techniques require that a database be maintained Separately
`that associates the MAC address of the device to be
`attached with the required IP address and other parameters.
`This database is created and maintained by the network
`Specialist and requires considerable skills that would not be
`held by the typical field replacement technician. In addition,
`DHCP cannot be used conventionally, to assign an unpre
`dictable address within a pool of available addresses,
`because the primary network protocols between industrial
`devices, such as ModbuS/TCP, use explicit knowledge of the
`IP addresses of the designated targets. For example, when
`DHCP is used on systems using Windows NT Server, the
`option known as IP address reservation is typically used.
`This actually makes DHCP equivalent to BOOTP in this
`embodiment.
`
`50
`
`35
`
`This prior art invention uses a central BOOTP or DHCP
`server to maintain a list of MAC addresses and IP addresses
`in a central location and allows acces by the experienced
`20 network or System administer to manage the lists. Although
`this protocol is implemented by many devices, the assign
`ment must be done by the IS department or System admin
`istrator. In a factory environment with automated devices
`running 24 hrs a dayx7 days a week, employing a System
`25 administrator to assign IP addresses on devices around the
`clock is not cost-effective. The technician or engineer
`replacing the device does not possess the adequate skill or
`knowledge to also assign the IP address, and having a device
`failure may cripple the plant operation. Businesses must
`30 minimize the downtime associated with field replacement of
`devices in order to make the production numbers. Delaying
`a factory line until a system administer can issue an IP
`address to the device is not a Satisfactory option in the highly
`competitive marketplace.
`Another prior art System of assigning IP addresses is done
`via indirect assignment using Static address resolution pro
`tocol (ARP) override. The device is designed to assume’
`that any IP message arriving at the device that includes a
`MAC address that matches that of the device implies the
`0 registration of the IP address in the target. This forces the IP
`address sent to the device to be adopted by the device even
`if it is already in use. It also requires matching of the MAC
`address to the particular device. AS noted herein, forcing the
`wrong IP address to a device on the network can result in
`“S unexpected catastrophe.
`Typically the ARP override method involves an operator
`Sequence at a management Station Such as:
`arp-s 10.0.0.1 00:00:54:ab:cd:ef
`ping 10.0.0.1
`This forces the local station to build a directed unicast
`message to the Ethernet address 00:00:54:ab:cd:ef and des
`ignate the IP address as 10.0.0.1. This is interpreted by the
`device with address OO:00:54:ab:cd:ef as authority to assign
`55 the IP address 10.0.0.1 Any internet protocol can be used
`during the second phase. Instead of PING, it is common to
`use TELNET on obscure port numbers in an attempt to avoid
`accidental reconfiguration.
`There are also alternative network protocols for devices,
`60 Such as HPJetDirect cards. The HPJetDirect cards use the
`IPX protocol to advertise their presence to any management
`Station on the local network. A management program run
`ning on Some Station on the local network picks up the
`advertisement and displays the device as requiring configu
`65 ration to the operator. Since typically only one Station at a
`time on a network will be in an unconfigured State, this
`allows the operator to recognize and Select that unconfigured
`
`Page 11 of 22
`
`

`

`US 6,982,953 B1
`
`15
`
`25
`
`S
`device without recording the MAC address. All of these
`mechanisms require either knowledge of the MAC address
`of the device being attached, or at least Specialized knowl
`edge of the desired network function of the device by an
`operator. Use of an alternative protocol such as IPX will
`cause problems in use of the devices in environments where
`these protocols are not Supported.
`All the referenced techniqueS of IP Address assignment
`require either knowledge of the MAC address of the device
`being attached, Specialized skills and training, or preferably
`both. IPX protocol implementations has some further inher
`ent difficulty with devices not supporting IPX protocols on
`the network.
`Industrial control devices pose particular problems
`because of the importance of operation, continuous opera
`tion, and location of the devices. These devices may fail in
`Service and must be replaced rapidly from a Spares Stock
`with minimum Mean Time To Repair (MTTR). For
`example, the devices may fail because they are exposed to
`electrical or mechanical Stresses that exceed their specifica
`tions. An example of a mechanical StreSS is being crushed by
`impact with a fork lift truck. A common example of an
`electrical stress is 110/220 V line power being shorted to low
`Voltage input circuits. In Such situations, the devices are
`usually designed to go safe, but they need to be replaced
`as rapidly as possible in order to allow the process to
`continue.
`Most industrial users maintain a Stock of Spare devices of
`each type that need to be replaced. These users provide
`instructions to maintenance perSonnel for replacement of
`faulty devices. However, the need to assign IP addresses
`accurately under such critical replacement conditions is
`usually not practical. This is particularly true in industrial
`environments with Strict responsibility partitioning between
`an electrician who can rewire a module, but requires the
`Service of an IT technician to alter network parameters.
`Previously, Ethernet was not considered a viable option to
`the business community. One problem with the implemen
`tation of Ethernet as a replacement for the device level
`networks such as ASi or DeviceNet was that you could not
`require anything more elaborate than the Setting of a rotary
`Switch to match the predecessor device. Such problems
`diminished as the protocols changed and expanded the
`Ethernet options.
`One such protocol the industrial protocol MODBUS/TCP.
`MODBUS/TCP is a communication protocol designed to
`allow industrial equipment Such as Programmable Logic
`Controllers, computers, operator panels, motors, Sensors,
`and other types of physical input/output devices to commu
`nicate over a network. It was introduced by Schneider
`50
`Automation in the early 1990's as a variant of the widely
`used MODBUS protocol, which had been implemented in
`turn by almost all vendors and users of automation equip
`ment. The specification of the MODBUS/TCP variant was
`published on Schneider's web site, in order to encourage all
`vendors to implement the protocol consistently, and thus
`avoid interoperability problems that typically result when
`implementors must deduce or reverse-engineer an inter
`face Specification.
`There have been several attempts to resolve the afore
`mentioned problems. U.S. Pat. No. 5,410,730 (730), dis
`cuSSes automating the initial assignment of a proceSS device
`address by allowing a number of devices to be attached to
`the network, issuing queries to which all devices will
`respond, and then using unique parameters or Serialization
`included in those devices before installation to assist an
`operator in assigning the network address.
`
`6
`The mechanism of the 730 patent requires foreknowl
`edge of the unique characteristics of the device in order to
`provide address assignment, and cannot be used to perform
`automated assignment when replacing one of potentially
`many identical devices on a network Segment. It is also not
`designed to work with TCP/IP local area networks. The
`mechanism of assigning a temporary address first, and then
`using that to complete the configuration proceSS, is only
`necessary when using networks which have no native boot
`strap address assignment process. In the case of a TCP/IP
`local area network, all of this functionality can be done using
`the Internet standard BOOTP protocol (RFC 951). With
`BOOTP, the information needed to perform the match is the
`serial number or MAC address that is uniquely associated
`with the network interface hardware and readily available
`upon request.
`U.S. Pat. No. 5,724,510, (510) describes a technique
`which would most likely be banned in any practical Internet
`TCP/IP local area network because it assigns an address for
`a device by using Speculation. Specifically, it deduces the
`range of addresses in use on the network to which the device
`is attached, and then issues a Series of queries to determine
`whether a given address within that range has already been
`assigned to another device. The novelty claimed in the 510
`patent is that in addition to the standard ARP technique
`ordinarily used to query the existence of a given IP address,
`the 510 System extends this by issuing a Series of appli
`cation level queries. The reason for doing this is to over
`come problems relating to the cacheing of ARP records.
`A flaw in the 510 invention is that it fails to address the
`case where the address being speculatively assigned has in
`fact already been assigned to another device, but that device
`is temporarily inaccessible, Such as by being reset or through
`a temporary network disruption. The 510 system would
`complete its assignment of the duplicate address in a finite
`time period, after which, if the original device were to come
`back on line, there would be a duplicate address situation
`that would impede operation of the original device. This
`flaw supports the conclusion that it would likely never be
`permitted on a network used for automation purposes, as
`multiple devices with the same IP address would result in
`grave networking problems. A more appropriate Solution to
`the assignment of an arbitrary address on a network is to use
`the Dynamic Host Configuration Protocol (DHCP)
`described in RFC 1531.
`The invention of U.S. Pat. No. 5,446,897 (897) allows
`for the assignment of the network address for a replaced
`device, automatically, by recognizing a unique logical
`identifier, or an arbitrary word, number, or combination
`thereof. One application of this 897 patent is the replace
`ment of one of many identical devices on a network.
`Maintenance perSonnel Set a plurality of Switches or jumpers
`that are accessible on the device So that they have an
`identical Setting to that on the device being replaced. Once
`completed, the application technique described in the 897
`patent completes the replacement.
`There are several limitations of technique of the 897
`patent. Firstly, it requires that the devices being replaced
`incorporate the capability of reading Some Sort of logical
`identifier before attempting address assignment. Secondly,
`the devices being replaced must incorporate a non-Standard
`protocol capability to transmit that information to the man
`agement device for the purpose of address assignment.
`These two requirements severely limit the usefulness of the
`technique, Since network administrators would be unwilling
`to deploy an automated configuration technique unless it
`applied to a high proportion of devices likely to require Such
`
`35
`
`40
`
`45
`
`55
`
`60
`
`65
`
`Page 12 of 22
`
`

`

`15
`
`7
`assignment. Any attempt to make the requirements into a
`Standard would require agreement among multiple vendors
`of equipment to adopt this additional feature Voluntarily.
`Such cooperation would likely not Succeed. The appropriate
`way of achieving Such agreement is to propose the technique
`and get it adopted by a Standards body Such as the Internet
`Engineering Task Force (IETF). However, the IETF would
`be skeptical about the widespread adoption of Such a tech
`nique because of its similarity to the BOOTP and DHCP
`protocols already available. In fact, the 897 patent describes
`1O
`a technique identical to the prior art of BOOTP, where the
`logical identifier is the MAC address.
`A System for allowing decentralization of a directory
`previously maintained on a single file Server is described in
`U.S. Pat. No. 6,021,429 (429). Decentralization and resil
`ience is achieved by arranging the list Servers to follow a
`defined protocol for determining the existence of list Servers
`on a network. And, updating their contents from one of the
`devices whose contents are authoritative in order that any of
`the devices can Serve the information in the case of unavail
`ability of the original.
`This 429 technique has much in common with the
`distributed Yellow Pages database implemented on Sun
`Microsystems workstations dating back to the mid 1980's.
`The primary difference is that the identity of a device being
`available to take on directory Service duties need not be
`configured in advance. Instead, the devices negotiate for
`authority based upon their assigned network addresses. This
`in turn is similar to the procedure used by Microsoft in
`implementing the automatic browse master assignment for
`Windows 95 peer to peer file service. Indeed, almost all of
`the described capabilities have an equivalent in the “browse
`list feature maintained automatically by Windows 95
`machines, and which is updated by notification messages
`Sent out on a timed basis by network devices Such as
`printers, computers, and other file Server devices.
`Similar to 510 patent, the invention of U.S. Pat. No.
`5,586.269 (269) discloses a mechanism that is concerned
`with assignment of an arbitrary network address that allows
`the device to become functional on the network. This is
`accomplished by attempting to contact the existing devices
`that have been assigned the proposed addresses, in turn, until
`one is found that is not currently assigned.
`The 269 mechanism is not appropriate for use on a
`TCP/IP local area network because of the problems caused
`if the address in question actually had been assigned to
`another device, but that device was temporarily inaccessible.
`Such a Situation would likely cause network disruption and
`possibly a failure of control in an automation System.
`Therefore, the 269 methodology would not be acceptable
`on a network used for automation purposes. Instead, the
`appropriate protocol to use if an arbitrary address were
`desired on a TCP/IP local area network is the standard
`DHCP protocol described in RFC 1531.
`The techniques of U.S. Pat. No. 4,677.588 (588) are not
`appropriate for TCP/IP local area networks. ASSigning
`appropriate address ranges for network Segments which are
`Subsequently linked together is cumberSome, and cannot
`generally be overcome by defining an address assignment
`protocol that would be binding upon the existing devices on
`those networks. The existing TCP/IP devices expect stability
`in address assignment, and the act of interconnecting two
`networks cannot by itself, cause reassignment of network
`addresses without knowledge of the devices themselves. The
`588 patent describes a mechanism for more convenient
`allocation of addresses in a network environment that is not
`bound by the address assignment conventions of TCP/IP.
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,982,953 B1
`
`25
`
`35
`
`40
`
`8
`U.S. Pat. No. 5,987,524 (524) describes what is com
`monly called a network firewall technique to overcome an
`intended intrusion attack using address spoofing. The
`firewall is pre-configured with an association between the
`physical address of each subscriber device and the IP
`address assigned to that device. The firewall recognizes the
`case where an incorrect Source network address is being
`presented by an intruding System, and prevents the messages
`from being propagated to their intended target device.
`The invention of U.S. Pat. No. 5,980,078 ('078) allows a
`general-purpose network to be used as part of a bootstrap
`ping mechanism to enter the initial configuration data for a
`device after it has been physically installed on a network, but
`before it has been made operational. The 078 mechanism is
`Specifically unsuitable for use with arbitrary target devices
`on a TCP/IP local area network since it relies on assignment
`of a temporary network address, and a non-operational State
`known as 'standby, in order to allow the device configu
`ration to be completed with manual assistance.
`The invention described in U.S. Pat. No. 5,917,8