PICMG 2.16 and the proposed CompactTCA spec are the only open standard means of providing server blade systems for wide use in embedded designs at the network edge. While closed systems from single vendors are available, designers lack the flexibility to choose the exact processor and I/O blades, OSes and applications that would make the best choice for their product.

So, as designers move away from bus-based systems, they are going to need increasingly sophisticated networking technologies in order to produce more complex and powerful — yet easier to manage and maintain — systems. Given its transparent packet processing and flexible management capabilities, the venerable Network Address Translation methodology makes a perfect addition to an network edge system design.

And as network systems proliferate in designs closer to the edge and the number of locally available IP addresses decrease, the inclusion of traditional Network Address Translation (NAT) capabilities becomes more and more important, rather than less so, growing far beyond its original design goal, as a solution to combat the rapid depletion of IPv4 addresses by allowing globally registered IP addresses to be re-used or shared by several hosts. This "classic" NAT, defined by RFC 1631, maps IP addresses from one realm to another.

NAT allows a set of private IP addresses to be converted to another set of public Internet IP addresses. Although it can be used to translate between any two address realms, NAT is most often used to map IPs from non-routable, private address spaces to public, routable addresses. This allows an organization with unregistered "private" addresses to connect to the Internet by translating those addresses into globally registered, "public" IP addresses.

The Internet Assigned Numbers Authority, or IANA, issues sets of unique IP addresses defined in RFC 1918 that can be used in a private domain. These addresses are non-routable, i.e., they cannot be communicated over the Internet, and take the familiar form of 192.168.1.101, as an example.

Network managers can freely use these internal addresses to avoid obtaining registered public addresses, but because they can only use these private addresses within their own realm, they are non-routable over a public infrastructure. If one of these 'private' packets is transmitted to a 'public' network, the first router it meets will kill it. When communication between a privately addressed host and a public network like the Internet is needed, address translation is required.

While it was originally developed to increase the number of usable IP addresses by setting up private networks with portals to the public address space, NAT is now used primarily as a means of sharing external network connections among a number of users. It is also employed to shield internal networks from an outside observer or to dynamically share processing load across a pool of servers.

NAT offers some real benefits in the area of network administration. Web or other services can be moved from one server blade to another node without having to worry about broken links. Simply change the inbound mapping at the NAT module to reflect the new host. You can also make changes to your internal network easily, since there is typically only a single external IP address and it belongs to the NAT module itself, shielding internal changes from the outside environment.

This enables integrators of embedded systems to, for example, pre-configure the internal/private IP addresses of the blades(or "nodes" in the chassis. When the system is delivered to the field, only the external/public IP address(es) for the installation site have to be set.

Network Address Port Translation (NAPT) is commonly implemented on the NAT server to enable masquerading/sharing, giving multiple inside users simultaneous access to outside resources for an entire internal LAN through a single public address. As a side benefit, NAPT also increases network privacy by hiding IP addresses from external networks. Because NAPT works with unique combinations of IP addresses and individual software port numbers, it is not possible for outsiders to "reverse map" incoming connections to get to other nodes within the chassis.

Scalability options

Having NAPT services provided by the NAT module and DHCP running on the switch carrier card are a natural fit. You can choose a range of unregistered IP addresses for your internal network and have the embedded switch dole them out as necessary. This also makes it much easier to maintain or scale up your network as your needs grow, since you don't have to request more public IP addresses. Network managers can just increase the range of available internal IP addresses configured in DHCP and immediately have room for additional nodes in their system.

The next most common use of NAT is called Static NAT. It is often used where a block of public IP addresses is provided by an Internet Service Provider (ISP) for use by the same number of internal client nodes. This static mapping allows the internal clients to maintain their setup information, even if the public IP addresses change.

Multiple ISP's can be enlisted to provide a degree of fault-tolerant access to a system. If network performance or quality degrades, connections can be swapped to another supplier, with only the NAT module's external addresses needing to be changed. The NAT's single management interface makes changeover a much easier task.

Static NAPT is typically used at both ends of a client/server connection in order to create a "tunneled" connection over a public network. The user hides the clients behind a NAT Module that uses Static NAPT to translate well-known TCP/UDP (Destination) Port numbers to an administratively specified Port number unique to that client. At the other end of the connection, the servers are hidden behind another NAT Module that is configured with Static NAPT mappings that translate the administratively dictated TCP/UDP (Destination) Port number back to a well-know Port number and a previously determined destination IP address in the private-side domain.

Mappings for Static NAPT specify translations between a single private IP address and Private TCP/UDP Service Port pair, and a single public IP address and Public TCP/UDP destination Service Port pair. Unlike NAPT and Dynamic NAT, sessions may originate on either the public-side or the private side. Static NAPT differs from Static NAT in that both the IP address and the TCP/UDP Service port are translated in both directions. Static NAPT also allows the network administrator to select the port numbers used. This allows sessions from a particular client to be directed to a particular server.

Dynamic NAT

NAT also supports dynamic NAT, where the bindings between internal and external client/servers are not pre-set but follow established rules specifying the mapping of a group of internal IP addresses to a pool of external IP addresses. Typically, the number of public addresses is smaller than the number of internal addresses. Dynamic NAT is used in cases where you want to allow the internal nodes shared access to public IP addresses. Only one of the internal nodes can be mapped to an external address at a time. These mappings can be set to expire if they are not used within a programmable period of time.

Implementing dynamic NAT and the appropriate filters automatically creates a firewall between your internal network and outside networks or the Internet. Dynamic NAT only allows connections that originate inside the internal domain.

Essentially, this means that a computer on an external network cannot connect to one of the internal servers unless the internal node has initiated the contact. Outside users can't simply latch onto an internal IP address and use it to connect to a software port or an internal node. Once again, this allows integrators to set the internal addresses in the factory and only have to manage the NAT module interface when the system is installed at a customer site.

Load Sharing NAT (LSNAT), as defined by RFC 2391, enables the NAT module to distribute a session load across a pool of servers. A common example would be an embedded server farm acting as a single, virtual Web, e-mail or database server. Load sharing is used to decrease response time for each function by leveling the work each server has to do. It also allows systems to grow over time by transparently adding servers to handle increasing session load.

LSNAT is most often used in server farms, where a single blade server is not able to cope with the demands of an increasing number of clients or sessions. Load sharing of that same workload across multiple servers also enhances responsiveness. LSNAT makes it easy to scale load to resources, by transparently spreading the client load among several server nodes.

One of LSNAT's real strengths is the flexibility it offers to a systems administrator, making it very easy to reorganize and rearrange server nodes in the chassis. Nodes in a server pool may be replaced/upgraded, or new nodes may be added without the clients being aware of any background activity. Changes to servers, whether blade- or box-based, can be shielded from client nodes by making the NAT module the focal point for change management and network traffic.

All requests and responses pertaining to a session between a client and server node pass through the same NAT. This gives designers a single control point for all traffic to/from an "internal" domain.