RTC Magazine

AdvancedTCA (ATCA) and MicroTCA (μTCA) are being aggressively deployed, creating opportunities for enhancements in the hardware platform management infrastructure that has been such a vital part of the success of these platform architectures. The local management controllers (which are referenced generically here as Intelligent Platform Management Controllers or IPMCs) on Telecom Communications Architecture (TCA) boards and modules all have a mandatory connection via the Intelligent Platform Management Bus (IPMB) to upper level management layers. IPMB links use the ubiquitous and low-cost, but not high-performance, Inter-Integrated Circuit (I2C) bus. It is now clear that a supplementary connection for such IPMCs to an in-shelf LAN can be very valuable, especially for the more sophisticated boards and modules.

The article entitled Using I2C for “Behind-the-Scenes” Management, published in the June issue of RTC, introduces the role of IPMB in TCA management frameworks and focuses on using I2C for non-IPMB purposes in the management of TCA shelves. Figure 1 shows the management framework for both ATCA and μTCA and two promising applications for LAN-attached IPMCs.

Two Key Applications

One of the applications concerns upgrades of the firmware and other configurable elements of a TCA board or module. PICMG HPM.1, the IPM Controller Firmware Upgrade specification, provides a common framework for doing such upgrades, even in shelves that integrate independently implemented components. (See HPM.1 Spec Defines Interoperable Firmware Upgrade for PICMG Management Controllers, published in the August 2007 issue of RTC, for an introduction to HPM.1.) HPM.1-compliant IPMCs are required to support upgrades via IPMB, and the typical size of an instance of management controller firmware, a few hundred kilobytes, is a good fit for this approach.

As Figure 1 shows, however, HPM.1 also allows up to seven additional configurable components beyond the management controller firmware to be upgraded, including one or more programmable logic devices (PLDs) such as field-programmable gate arrays (FPGAs), where the upgrade image size may be an order of magnitude larger. With such upgrade image sizes, which could apply for controller type [B] in the figure, the higher bandwidth of a LAN transport is very attractive and possibly critical.

Another application for LAN-attached IPMCs is accessing serial consoles via the in-shelf LAN that is usually present, versus running separate serial cables for each of possibly hundreds or even thousands of console ports in a large system. The Intelligent Platform Management Interface (IPMI) specification, which provides a foundation for TCA’s management framework, defines an SOL architecture in which a LAN-attached IPMC can communicate with an SOL client somewhere on the LAN. The SOL client uses that LAN as the transport for console traffic involving one or more console ports associated with the IPMC. As demonstrated in Figure 1, those console ports can be used for the payload processor(s) that performs the main functions of a board or for a console interface to the management controller itself (such as the Carrier IPMC for module type [C]).

Payload processor console ports can, for example, allow monitoring of the boot phase of the payload processor during development, diagnosis, or debugging activities. Similarly, IPMC console port access can aid in monitoring the local activities of an IPMC, which can be especially important for a Carrier IPMC that is interacting with AdvancedMC modules installed on its board. In either case, using an in-shelf LAN (which is typically already present, such as the mandatory Base Interface in ATCA shelves, which uses Ethernet) for this traffic can be hugely preferable, from a logistics and operational expense point of view, to connecting individual serial console cables to each console port. But how can we share a single in-shelf LAN between payload and IPMC traffic?

Sideband Interfaces Enable Shared LAN Attachments

One key way to accomplish such sharing, as shown in Figure 2, is by choosing network controllers (NCs) that have a sideband interface for management traffic in addition to the primary interface for use by the payload processor. An NC with sideband interface routes management traffic from the LAN to the IPMC via the sideband and forwards LAN-addressed management traffic from the sideband to the LAN. Server-oriented NCs have long supported sideband interfaces. Until recently they tended to be NC vendor- and device-specific, but often based on the SMBus variant of I2C. As a result of the sideband interface differences, distinct firmware and hardware implementations have been needed for different NC vendors and even different devices from a single vendor.