LearnOpenSolaris

Networking

Major Components

Sun has invested heavily over the last 8 years in the network stack. For Solaris 10 the TCP/IP engine was the primary focus. After that work was completed, the focus shifted from improvement to determining the functionality the next generation stack would need to offer. For more on the motivations behind the new stack architecture see below.

Image Map

Many of the projects below tie into the grand vision for a thoroughly updated stack. This includes the centerpiece Crossbow Project, but there are many other aspects-

  • • Improve, expand, simplify data link management.
  • • Improve performance of sockets for developers.
  • • Create hooks for developers at different levels in the stack to allow them to customize for their needs.
  • • Quagga router offering support for a wide range of routing protocols
  • • Solaris IPFilter for NAT and firewall facilities
  • • High Availability networking capabilites enabled through IP Multipathing or link aggregation

The chart below is an overview of networking projects that have been incorporated into OpenSolaris 2009.06 (or earlier OpenSolaris releases). See the networking community site on opensolaris.org for project futures.

Projects described below are organized around 4 categories, User level, Kernel level, Device level, and System APIs.

User
Automatic Network Configuration


Automatic Network Configuration (the Network Auto-Magic Project, or simply NWAM) greatly improves LAN and WiFi configuration for OpenSolaris users. It includes:
  • • A desktop tool for better control and observability of the current configuration.
  • • Simplified administration of wireless network connectivity.

Along with the WiFi project (listed under Drivers), OpenSolaris networking on laptops is greatly enhanced.
OpenSolaris.org Project Page
Quagga Router Quagga is an open source routing software suite that enables a system running OpenSolaris to offer highly flexible IP router services. The combination of open source software including full packet routing capabilities (and firewall services, see IPFilter below) running on industry standard hardware allows OEMs and integrators to develop single integrated system solutions, not a solution dependent on a rack of networking equipment and computers.

Quagga software allows an OpenSolaris system to listen to routing announcements in order to transmit packets intelligently in the network and to recover from network failures. A variety of routing protocols are supported including OSPFv2, OSPFv3, RIP v1 and v2, RIPng, BGP-4 and IS-IS.
OpenSolaris.org Project Page

External Community Page
Solaris IPFilter Firewall IPFilter is a full featured software package that can be used to provide fireewall and network address translation (NAT) services. External Community Site

Documentation
IP Multipathing IP Multipathing (IPMP) enables building high availability networking and offers load spreading capabilities. Every major Sun customer uses IPMP. To understand why, see the What's New section. OpenSolaris.org Project Page

Documentation

Blog

Link Aggregation Link aggregation provides a method to combine the capacity of multiple full-duplex Ethernet links into a single logical link. The link aggregation group is then treated as though it were a single link.

The most obvious benefits are:
  • • Increase bandwith
  • • Simple administration – administer one link not multiple ones.

Other less obvious but powerful benefits:
  • • Very simple way to obtain high availability configurations. If two physical links are aggregated, one link can fail and all traffic will flow over the other one.
  • • Link aggregation can be used for load balancing by setting policies for what traffic can use which underlying link.
  • • Integration with virtual networking also allows simple high availability Virtual NIC configurations. As an example, a particular configuration could involves 2 physical links with 3 virtual interfaces (VNICs). To set this up, first aggregrate the physical link into one logical link, then assign the 3 Virtual NICs to that aggregation link. If one of the physical links should fail, all the VNIC traffic will flow over the other physical link.
Documentation
Simplify Data Link Administration Management of data links is centralized in the dladm command which offers a unified syntax and improved consistency over previous commands. All aspects of data link administration, virtual and physical, are handled through this management tool.

There are many aspects to dladm. For example the Vanity Naming sub-project allows assigning user-defined names to network interfaces. This can help in self-documenting an interface by identifying its use (e.g. publicnet) and more important, makes it possible to change underlying hardware NICs, Virtual NICs, VLANs, and link aggregations without affecting the software configuration that contains the network interface names. This separation of configuration information from network topology also makes it possible to migrate network interface software configuration from one system to another even if systems are not identically configured.
Documentation:

OpenSolaris.org Projects:

Blog

Kernel
Project Crossbow Project Crossbow represents multi-year engineering effort to fully integrate network virtualization and network resource management capabilities into OpenSolaris, offering developers and customers virtualization breadth and flexibility that no other operating system can match. Crossbow Links

OpenSolaris.org Project Page
Kernel Sockets Kernel sockets simplify kernel networking for kernel developers. See the What's New section. OpenSolaris.org Project Page
IP Observability IP Observability allows observing local IP traffic, for example traffic on loopback interfaces or traffic between Solaris Containers, using the same tools and techniques as used for monitoring external traffic. See the What's New section. OpenSolaris.org Project Page

Blog

Driver
Generic LAN Driver The Generic Lan Driver (GLDv3) project is a high-performance device driver framework supporting VLANs, 802.3ad Link Aggregation, as well as the many aspects of driver/kernel interaction required by Project Crossbow. OpenSolaris.org Project Page
InfiniBand InfiniBand (IB) has emerged as the high-performance alternative to Ethernet with performance 3x higher than 10GbE. InfiniBand is compelling technology for High Performance Computing and enterprises looking for higher throughput and ultra low latency data center communications within a rack or between racks. OpenSolaris supports the latest Mellanox ConnectX Host Channel Adapter (HCA) for both DDR (double data rate of 20Gbs) and QDR (quad data rate of 40Gbs) using the latest InfiniBand switches from Sun. OpenSolaris offers core kernel InfiniBand services that are compatible with and competitive with the Linux OFED IB stack. OpenSolaris IB capabilities include IB Transport, IP over InfiniBand (IPoIB), RDSv1, NFS/RDMA and iSER. When used for TCP/IP traffic, customers now have two sound choices for their high bandwidth network fabric- 10Gb Ethernet or InfiniBand. For more background on why enterprises should consider InfiniBand, see Sun's InfiniBand products.
WiFi NICs In support of the push to make OpenSolaris more attractive to developers on a wide front of issues, much work has been done to improve OpenSolaris on laptops, including support for a wide range of wireless network interfaces. OpenSolaris.org Project Page

System APIs
Sockets API Numerous enhancements have been made to the sockets interface for OpenSolaris 2009. See the What's New section. OpenSolaris.org Project Page
Packet Filtering Hooks API The Packet Filtering Hooks (pfhooks) API is a new interface that increases the flexibility for developing custom packet filtering. This would typically be used by firewalls and other software packages for packet inspection. In addition to providing the means to be notified each time a packet appears at one of the hook points, this interface also provides the developer with kernel access to network interface information, such as their names and addresses associated with them. It is also possible to intercept intra-system communications, for example between two Solaris Containers so virtual communication paths offer the same pfhooks functionality as physical ones. Documentation
Session Initiation Protocol (SIP) and Session Description Protocol (SDP) To enable telecommunications applications, OpenSolaris provides standard building blocks.

Session Initiation Protocols (SIP) is an application layer control protocol defined by the IETF in RFC 3261. SIP is used for creating, modifying and terminating sessions such as Voice over IP (VoIP), Instant messaging (IM) and presence.

OpenSolaris also supports the Session Description Protocol (SDP), described in RFC 4566. SDP is used to convey session information in SIP as well as for other types of sessions, e.g. streaming media (Real Time Streaming Protocol, RTSP), email and web and Multicast Session Announcement.
OpenSolaris.org Project Page

Motivations for the New OpenSolaris Network Stack

When designing the new network stack, three trends stood out for consideration- server virtualization, resource management, and the increasing sophistication of network interface chips and the services they can perform.

Top of the list was virtualization and the impact server virtualization would have on networking. The networking industry has used the term 'network virtualization' to cover component issues like VLANs or link aggregation as the virtual concepts. However from a server virtualization perspective, network virtualization was a much larger concept, the ability to virtualize all aspects of a network topology into a single compute system chassis.

The other trend, resource management, is important, both from the positive reception Sun's initial offering received for the ability to assign CPU and memory resources to applications, as well as for the trend for building more complex virtualized environments. The complexity increased the awareness of the importance to the enterprise of defining service level agreements for their applications. Network resource management was an obvious extension for providing a broader set of resource management tools to guarantee an application got the resources it needed.

And finally the trend toward more intelligent network interfaces meant that the network stack would need to know how to take advantage of these capabilties. This required fundamentally re-architecting the stack to include in the stack architecture those new facilities offered by the latest network interface chips.