The present invention relates to data communications and particularly to data communication between components in a computer chassis across a network.
Presently, there are different types of data transmission systems employing existing cabled networks, or board level component traces specifically installed for that purpose. Such systems allow the automatic control and monitoring, at a distance, of components connected to the network.
These known systems generally allow a network or hardware administrator to respond to exigencies in the matter of monitoring and control of a network and its nodes. However, they exhibit a complex structure employing several individual control and monitoring modules managed by a single or several collective control modules, themselves possibly managed by a central module.
Over the years, communications technology has developed for the computer industry into what is now extensive sophistication in hardware and software systems for facilitating various types of communications. Nevertheless, extensive sophistication and advancements in many hardware and software systems can be thwarted from market or commercial applicability for many reasons. For example, if a new communications system is not compatible with an existing system, many users will not purchase the new system. Attempts for a single manufacturer to become the system to which all others must be compatible can be quite difficult to achieve and, even if successful, cost the manufacturer a great deal of investment capital. Attempts for different manufacturers to interface with each other often creates complex and expensive systems which can confuse system purchasers and installers alike, and can often making the problems worse. Also, manufacturers of systems are reluctant to develop or introduce new systems to the market when compatibility and user confusion are such big issues. Accordingly, compatibility with other existing or even future systems has been emphasized in various industries. Industry standards to accomplish compatibility goals of the data communication systems have resulted.
Despite the advancements of compatibility which result when particular industries adopt standards, another problem arises when an industry desires to change or make a transition to new standards. These new standards, for example can often provide higher speed capabilities or other significant improvements over previous standards. The new standards, however, often are not adopted because the new standard is not compatible with the existing standard. In other words, the market will not accept or is reluctant to accept, the new standard because it may require replacement of all existing systems with which the user wants to communicate. This can cause technology stagnation and inhibit rapid advancement of technology.
Home automation systems have long used special techniques for local communication over power mains. This was originally necessitated by the absence of any other type of bus over which xe2x80x9csmartxe2x80x9d devices could xe2x80x9ctalkxe2x80x9d to each other. However, communication over power mains also introduces very specific problems, including those of line noise received from motors and other devices attached to the power mains, the need to ensure that the data itself does not interfere with other devices connected to the mains, and limited bandwidth. For similar reasons, low-bandwidth power-mains communications have also been used for limited data communications between smart devices and local electric utility control systems.
One example of an industry standard for building or home automation data communication systems has been the X10 or X-10 communications protocol for remote control of electrical devices which communicate across standard wiring or power lines of a building such as a home. (In general, methods of ensuring the accuracy of transmitted and received data are known as communications protocols.) The X10 communications protocol allows various home electronic devices, such as lighting controllers or switches, status indicators, security systems, telephone interfaces, computer interfaces, and various home appliances, to readily be linked together for simple control applications. The X10 communications protocol generally has a narrow bandwidth, i.e., 120 KiloHertz (xe2x80x9cKHzxe2x80x9d), for communicating data at a relatively slow speed, i.e., 60 bits/second.
Another industry standard for home automation has been the Consumer Electronic Bus (xe2x80x9cCEBusxe2x80x9d) standard, which describes a local communications and control network designed specifically for the home. Like X10, the CEBus standard provides a standardized communication facility for exchange of control information and data among various devices and services in the home, such as lighting controllers or switches, status indicators, security systems, telephone interfaces, computer interfaces, stereo systems, and home appliances. The CEBus standard was developed by the Consumer Electronics. Group of the Electronic Industries Association (xe2x80x9cEIAxe2x80x9d) and an inter-industry committee of representatives from both EIA and non-member companies. The CEBus standard generally has a wide bandwidth, e.g. 100-400 KHz, for communicating data at a relatively fast speed, i.e., 10 Kilobits/second and is significantly faster and more reliable than the X10 communications protocol. The CEBus standard also allows full networking of consumer application devices. The CEBus standard encompasses both the physical media (wires, fiber, etc.) and the protocol (software) used to create an intelligent home or office.
The newest standard for home automation is the EIA-600 standard, which is intended to handle existing and anticipated control communication requirements at minimum practical costs consistent with a broad spectrum of residential applications. It is intended for such functions as remote control, status indication, remote instrumentation, energy management, security systems, entertainment device coordination, etc. These situations require economical connection to a shared local communication network carrying relatively short digital messages.
Presently, there are different types of data transmission systems which allow computer network components to be automatically controlled and monitored at a distance. These known systems are generally connected by a dedicated network, and consist of individual control and monitoring modules at each node, which are in turn managed by a central system.
The Intelligent Platform Management Interface (or xe2x80x9cIPMIxe2x80x9d) specification was announced by Intel, Dell, Hewlett-Packard Company, and NEC to provide a standard interface to hardware used for monitoring a server""s physical characteristics, such as temperature, voltage, fans, power supplies and chassis.
The IPMI specification defines a common interface and message-based protocol for accessing platform management hardware. IPMI is comprised of three specifications: Intelligent Platform Management Interface, Intelligent Platform Management Bus (IPMB) and Intelligent Chassis Management Bus (ICMB). The IPMI specification defines the interface to platform management hardware, the IPMB specification defines the internal Intelligent Platform Management Bus, and the ICMB specification defines the external Intelligent Chassis Management Bus, an external bus for connecting additional IPMI-enabled systems.
IPMI provides access to platform management information. IPMI-enabled servers monitor and store platform management information in a common format which can be easily accessed by server management software, add-in devices or even directly from other servers.
A management bus, IPMB, allows add-in devices such as Emergency Management Cards to access platform management information, even if the processor is down. The IPMB can also be extended externally to the chassis (ICMB) to enable xe2x80x9csystem-to-systemxe2x80x9d monitoring. This allows a server to manage another ICMB-connected server even if it has no system management software or the processor is down.
Functions such as failure alerting, power control and access to failure logs are supported for systems connected to the ICMB, so multiple servers or peripheral chassis (storage and power supplies) can connect to the ICMB as an alternative to using Emergency Management Cards.
IPMI allows differentiated hardware solutions to be implemented quickly and easily. The IPMI interface isolates server management software from hardware, enabling hardware changes to be made without impacting the software. Although IPMI is not tied to a specific operating system or management application, it is complementary to higher level management software interfaces such as the Simple Network Management Protocol (SNMP), Desktop Management Interface (DMI), Common Information Model (CIM), and Windows Management Interface (WMI), which facilitate the development of cross platform solutions.
IPMI allows system managers to determine the health of their server hardware, whether the server is running normally or is in a nonoperational state. Servers based on IPMI use xe2x80x9cintelligentxe2x80x9d or autonomous hardware that remains operational even when the processor is down so that platform management information is always accessible. The IPMI interfaces enable platform management hardware to be accessed not only by management software but also accessed by third party emergency management add-in cards and even other IPMI-enabled servers. System-to-system monitoring or management via a connected server is becoming increasingly important as system managers deploy complex system topologies such as clusters and rack-mounted configurations. In addition, the scalable nature of IPMI enables the architecture to be deployed across a server product line, from entry to high-end servers, and gives system managers a consistent base of platform management functionality upon which to effectively manage their servers. One specific disadvantage of this approach is that additional physical connections and device support is required to interconnect these components.
The CPU normally requires a number of support chips to handle buffering of data from memory, interfacing to legacy architectures, and caching and bus arbitration. These functions are managed by custom-designed chipsets which perform a xe2x80x9cbridgingxe2x80x9d function. More specifically, a bridging device may provide a connection between two independent buses.
FIG. 6 shows a typical design where bridging occurs between the host processor bus 622 and the PCI bus 604, between the PCI bus 604 and a standard expansion bus 606 (such as ISA or EISA), and between host bus 602 and PCI bus 604. For example, a host/PCI bridge 608 may take various actions based upon an action initiated by the CPU 626; if the CPU is performing a main memory read/write, the bridge 608 takes no action; if the CPU is targeting a device memory located on a bus behind the bridge, the bridge 608 must act as a surrogate target of the CPU""s transaction; if the CPU 626 accesses a PCI device configuration register, the bridge 608 must compare the target bus to the range of PCI buses that exist beyond the bridge, and initiate a transaction message based upon the location of the targeted bus. This particular rendition shows a multi-processor implementation using two processors, 626 and 628.
The present application discloses a method and system of interchassis and intrachassis computer component command and control. The existing power rail is used for network connectivity for intrachassis command and control. An existing common power mains can be used for interchassis command and control. Further, a protocol, for example, the CEBus protocol (or a CEBus protocol modified for the particular power rail) can be used to provide interchassis and intrachassis platform management functionality. This management functionality is similar to that provided by the proposed IPMI specification. A chassis bridge controller is necessary to interface the intrachassis power rail command and control infrastructure with an exterior network. External systems (interchassis communications) can communicate to the bridge via the particular protocol over an existing common power mains as a secondary channel exterior network. However, the management functionality is implemented intrachassis, that is, it is applied to the internal components of the machine.
An advantage of the present disclosure is that a loosely coupled secondary network can be constructed without the need for new cable. This secondary network can be accessed even when the primary network is down. The use of the existing common power mains allows for easy scalability.
Another advantage of the present disclosure is that it eliminates the cost that would be incurred by building a secondary network for command and control information.
Another advantage of the present disclosure is that the burden of the external cables of a secondary network between systems is avoided. This elimination of a second set of network cables eliminates the possibility of undesirable effects such as, EMI, safety issues, and cable management