Adding IoT friendliness to AdvancedTCA and related specifications

3The Internet of Things vision of a massively Internet-connected world is rapidly coming to fruition, along with numerous associated challenges. One of them, exhaustion of the available public Internet Protocol (IP) addresses in traditional IP version 4 (IPv4) is already upon us. Along with many other improvements, IP version 6 (IPv6), which was formalized way back in 1998, grows IP addresses from 32 bits to 128 bits, massively expanding the number of devices that can be addressed.

Until just the last few years, the adoption rate for IPv6 has been very low. One reason (or consequence!) is that numerous workarounds were developed to stave off the biggest downsides of IPv4. For instance, Network Address Translation (NAT) applied at a point of Internet access can allow one IPv4 address to represent hundreds, thousands, or more private IP addresses; only the public address needs to be unique. But NAT and the other workarounds have downsides, such as complicating direct device-to-device communication, an important part of IoT friendliness.

Now, however, the adoption rate is accelerating. As of September, 2015, for instance, of the 10 largest network operators (by traffic volume) tracked by the IPv6 Launch organization, the fraction of IPv6 traffic was over 70 percent for Verizon , and at or near 50 percent for ATT and T-Mobile USA.

In 2013, the promoter companies of the Intelligent Platform Management Interface () – Intel, Hewlett-Packard, NEC, and Dell – released an update of the IPMI specification that adds IPv6 awareness. That was a key gating factor for the AdvancedTCA (), AdvancedMC (AMC), and (collectively, ) hardware platform management subsystems, which are based on IPMI, becoming IPv6-aware as well. Existing IPv4-based network architectures, and the ATCA systems used therein, can continue to take advantage of the various available workarounds. New architectures, however, can begin to take advantage of the inherent benefits of IPv6.

This article describes the IPv6-awareness initiative of PICMG, which is led by its Hardware Platform Management (HPM) subcommittee.

IPv6-aware AdvancedTCA Base and Base Extensions specifications

The ATCA HPM subsystem was first adopted with the rest of ATCA at the end of 2002 and has had multiple major rounds of enhancement since then. Other elements of xTCA, including MicroTCA, AMC, and related specifications (numbering almost two dozen in all) base their HPM subsystems on the foundation established by ATCA. It was natural, therefore, for the HPM subcommittee to begin its IPv6 work with PICMG 3.0, the ATCA specification. This work resulted in an Engineering Change Notice (formally, ECN 3.0-3.0-001, which is ECN #001 for PICMG 3.0 R3.0), which was adopted in April 2015.

One key principle for the ECN is that IPv6 support is optional. With the adoption of the ECN, the official definition of ATCA now includes IPv6 support, but an ATCA system without IPv6 support can still be fully compliant.

Another key principle of this ECN is that IPv6 complements, but does not replace IPv4 in the ATCA architecture. IPv4 support continues to be mandatory to maximize backward compatibility. If IPv6 support is present, however, it must be compliant with this ECN and with the IPv6 aspects of the IPMI 2.0 specification.

One challenge in adding IPv6 awareness was that in IPv6, unlike in IPv4, an IP connection endpoint can have multiple IPv6 addresses, versus normally having a single primary address in IPv4. As a consequence, ATCA originally assumed that the IP address of the active Shelf Manager is a single IPv4 address. After the ECN, that single address becomes the Active Shelf Manager IP Address Set and can include multiple IP addresses.

Figure 1 shows a block diagram for one ATCA Shelf Manager product, including the various elements of its System Manager Interface, which is IP-based. The diagram exemplifies what is likely to be the case for all ATCA Shelf Managers that add IPv6 awareness in that interface. Multiple protocols are supported in that interface, even though only the Remote Management Control Protocol (RMCP) is mandated and functionally specified in ATCA; it makes sense for all those protocols to enable IPv6 access, as is done in the Schroff Pigeon Point Shelf Manager shown.

Figure 1: A block diagram for an ATCA Shelf Manager, in this case the widely used Schroff Pigeon Point Shelf Manager, showing that all protocols in the System Manager Interface are IPv6 enabled (including the ATCA-mandated RMCP), assumed to be running here on the most recent Pigeon Point Shelf Manager hardware platform, the ShMM-700R.

PICMG 3.7, the AdvancedTCA Base Extensions specification, is organized as a series of changes to PICMG 3.0 R3.0. By design, the HPM portions of these changes were structured so that PICMG 3.0 as amended by ECN 3.0-3.0-001 could be easily used as an alternate base. A formal ECN to PICMG 3.7 makes exactly that change. No other changes are necessary to make PICMG 3.7 IPv6 aware.

Both the PICMG 3.0 and 3.7 ECNs are available free on the page:

What about MicroTCA?

The MicroTCA HPM subsystem was directly based on the corresponding ATCA subsystem. There is a PICMG subcommittee already working on a revision of the MicroTCA base specification. It will be straightforward for that subcommittee to include IPv6 awareness in that revision, following the model used for ATCA.

What about the HPM.x specifications?

This set of PICMG Hardware Platform Management specifications augments the xTCA architecture and includes the following members:

  • HPM.1: The Firmware Upgrade specification, which standardizes upgrades for xTCA management controllers. This critical function is not standardized by IPMI.
  • HPM.2: The LAN-attached IPM Controller (IPMC) specification, which enables IPMCs, which are board- and module-level management controllers, to directly connect to existing in-shelf LANs to augment their communication with the Shelf Manager and potentially with shelf-external entities.
  • HPM.3: The DHCP-assigned Platform Management Parameters specification, which provides a standard way for IP addresses and other parameters to be assigned to LAN-attached management controllers.

HPM.1 allows the use of IP connections for firmware upgrade traffic, but does not attempt to standardize any IP address-related aspect of that communication. Therefore, no IPv6 awareness changes are needed.

HPM.2 R1.0, which was adopted in 2012, already has some placeholder provisions for IPv6 support. Those provisions have been filled out, along with other modest changes, in the just-adopted R1.1.

Figure 2 shows how a LAN-attached IPMC connects to an in-shelf LAN, in this case the Base Interface (which supports 1G Ethernet in PICMG 3.0 and optionally 10G in PICMG 3.7). With HPM.2 R1.1, IPv6 is supported for such connections.

Figure 2: One way for HPM.2 IPMCs to connect with an in-shelf Ethernet Base Interface is to share access to one or more network controllers so that IPMI traffic can be multiplexed with other Ethernet traffic to or from the board’s payload CPU(s). The IPMC to network controller link is called a sideband interface.

HPM.3 R1.0 is tightly focused on IPv4 and the corresponding version 4 of DHCP, the Dynamic Host Control Protocol, which uses one or more DHCP servers in a network to provide IPv4 address assignments to DHCP clients in the network. Network entities must have IP addresses to use IP on the network. For instance, Shelf Manager(s) in Figure 1 and the IPMC in Figure 2 would usually, in production environments, receive their IP address assignments via DHCP.

Assignments of IPv6 addresses and other network parameters need version 6 of DHCP (DHCPv6), which operates quite differently, especially at the detailed level, than DHCPv4. Therefore, R2.0 of HPM.3 will be a significant extension of R1.0. Work on this revision is under way in the HPM subcommittee.

As with the other aspects of PICMG’s IPv6 initiative, backward compatibility will be preserved in HPM.3 R2.0, which will support existing IPv4- and DHCPv4-based network architectures as defined in HPM.3 R1.0. The new facilities, though different, will be as compatible as possible with R1.0’s IPv4-oriented approaches.

How can I get going with IPv6 for management controllers in ATCA?

The best way is to pick management controllers that already support IPv6. One option is Pentair’s Schroff Pigeon Point management solutions for ATCA, starting with the already available Pigeon Point ShMM-700R, a small mezzanine module. The ShMM-700R comes pre-loaded with the Pigeon Point Shelf Manager, the first Shelf Manager for ATCA to support the just-adopted IPv6 ECN. Multiple companies, including Pentair, are already delivering ATCA shelves managed by the ShMM-700R. Figure 3 shows a Schroff Shelf Manager board that includes a ShMM-700R and installs in a wide range of Schroff ATCA shelves.

Figure 3: Example IPv6-capable Shelf Manager board, the Schroff ACB-VI, which includes a Pigeon Point ShMM-700R.

ATCA boards and AMC modules, if designed to be LAN-attached (which would typically be done via HPM.2) can also be made IPv6-capable at the management controller level with Pigeon Point Board Management Reference (BMR) solutions for IPMCs, Carrier IPMCs, and Module Management Controllers (MMCs). Carrier IPMCs are the management controllers on AMC carrier boards and MMCs are the controllers on the AMCs themselves.


ATCA systems with IPv6-enabled hardware platform management can be an excellent part of a backend compute complex for the Internet of Things, as well as for new applications in ATCA’s traditional application spaces, including communications and defense. Mature, intensively field-tested management subsystems are critical to achieving the performance and reliability promise of the ATCA architecture.

Mark Overgaard is Architect, System Management for . Mark was the Founder and formerly the CTO of Pigeon Point Systems, which was acquired by Pentair in July 2015 and integrated into Pentair’s Electronics Protection platform, under the Schroff brand.

Pentair Electronics Protection