Wiki code for Networking

Hide Line numbers
1: **Networking in Solaris 10**
2: 
3: Exponential growth in Web connectivity, services, and applications is generating a critical need for increased network performance. With the Solaris 10 Operating System, Sun meets future networking challenges by radically improving your network performance without requiring changes to your existing applications.
4: 
5: * Speeds application performance by about 50 percent via an enhanced TCP/IP stack
6: * Supports the latest networking technologies, such as 10 Gigabit Ethernet, wireless networking, and hardware offloading
7: * Accommodates high-availability, streaming, and Voice over IP (VoIP) networking features through extended routing and protocol support
8: * Supports current IPv6 specifications
9: 
10:  Slide Presentation at [[BayLISA>>http://www.baylisa.org]]: [[Solaris Networking: Today and Tomorrow>>attach:Community Group networking.WebHome@august2005-1.pdf]] 18 August 2005
11: 
12: **FireEngine**
13: 
14: FireEngine is a high performance networking framework based on an IP classifier and vertical perimeters. It transitions Solaris message passing based network stacks to function call based stacks while maintaining the current scalability. The architecture is very different from the old BSD style stack. FireEngine binds a connection to a CPU ensuring all packets for that connections are processed on the same CPU thus taking full advantage of NUMA architecture.
15: 
16: [[FireEngine Whitepaper>>attach:Community Group networking.WebHome@fewppublic.pdf]]
17: 
18: **NL7C (Network Layer 7 Cache) Project**
19: 
20: NL7C as part of SOCKFS provides an in-kernel gateway cache for objects transported via a generic request/response message based protocol in a semantically transparent manner.
21: 
22:  That is, neither the requesting user agent (client, e.g. web browser) nor the origin server (e.g. webserver) that provided the response cached by NL7C are impacted in any way.
23: 
24:  The first L7 protocol to be supported is HTTP which will supersede NCA (Network Cache and Accelerator) allowing NCA to be deprecated at a futre time.
25: 
26: **Nemo aka GLDv3**
27: 
28:  The Generic LAN Driver module has been in Solaris for many years. It provides much of the functionality required of a network driver and thus helps to accelerate the development and improve the consistency of such drivers. This project aims to evolve the Generic LAN Driver to improve performance and add features.
29: 
30:  Some key features include:
31: 
32: * trunking
33: * vlan
34: * dynamic polling
35: * chaining support
36: * large segment offload support
37: 
38: **Yosemite**
39: 
40:  The Yosemite project is aimed at improving Solaris UDP performance, and is made up of various smaller projects ranging from UDP/IP merge, UDP hardware checksum offload, roadcast/ multicast performance, socket-layer processing, and many others. The goal is to make Solaris more competitive when compared to Linux when UDP is used as the transport protocol, especially for workloads sensitive to latency and/or throughput.
41: 
42: [[Yosemite Whitepaper >>attach:Community Group networking.WebHome@yosemite-3.pdf]]
43: 
44: **IPFilter**
45: 
46:  IPFilter was initially integrated into Solaris late in 2003, just prior to the first release of IPFilter 4.1. Now that Solaris 10 is released and people are starting to use Solaris IPFilter as bundled, we’re accelerating the effort in engineering to bring that up to date with what’s available in the open source world. First off will be providing support for IPv6 (but not NAT.) In addition to the normal "catchup" type of project, we’ll soon be engaging in a project to provide a native interface in Solaris for firewall software to use, rather than having to depend on the pfil STREAMS module.
47: 
48: **IPsec**
49: 
50:  Along with IPFilter, IPsec is the intersection of networking and [[security>>Community Group security.WebHome]]. Solaris IPsec projects and discussion happen either here or in the [[Security Community>>Community Group security.WebHome]]. IPsec projects should be discussed on both communities, if at all possible.
51: 
52: **IPv6**
53: 
54:  With Solaris 10, IPv6 has been further enhanced to support 6to4 Router (RFC 3056), default address selection (RFC 3484), privacy extensions for stateless address autoconfiguration (RFC 3041), the new IPv6 Basic API (RFC 2553), and the new IPv6 Advanced API (RFC 2292).
55: 
56: **SCTP**
57: 
58:  SCTP (Streams Control Transmission Protocol, RFC 2960, RFC 3309 and RFC 3758) was added in Solaris 10. It is an in-kernel implementation that implements the socket API as defined in the draft-ietf-tsvwg-sctpsocket-10.txt. There is a lot of research going on around SCTP, such as how to do load balancing among streams, mobility extension, and multipathing handling. We welcome the community to use the OpenSolaris SCTP stack as an experimental platform. For comments, questions, bugs and suggestions, please send to sctp-questions AT sun DOT com.
59: 
60: **Surya**
61: 
62:  The Surya project is aimed at improving forwarding path scalability. Forwarding scalability deals with the ability for the solaris box to forward a higher number of packets per second given a number of routes in the forwarding table. This project is currently in its prototyping phase.
63: 
64:  Click [[here>>attach:Community Group networking.WebHome@surya-design.pdf]] for the Surya design document.
65: 
66: **Collaboration opportunities...**
67: 
68: **Clearview**
69: 
70: Clearview defines and implements a set of common requirements that all Solaris network interfaces must adhere to in order to improve the integration of key networking technologies, the observability of network traffic, and the administration of network interfaces as a whole.
71: 
72:  As a result, you will be able to:
73: 
74: * Observe all IP layer network traffic, including loopback, IPMP group and IP tunnel traffic.
75: * Observe all IP layer network traffic flowing to and from a zone.
76: * Administrate all network interfaces using dladm(1M).
77: * Use VLANs and form link aggregations on all Ethernet devices.
78: * Use IPMP with technologies such as DHCP and routing protocols.
79: * Select names for network interfaces, easing migration of network configuration information between systems or zones, and markedly improving Dynamic Reconfiguration.
80: 
81: ... and more.
82: 
83:  The foundation of Clearview, dubbed "Phase 0" or "Clearview for Nemo", has already integrated into Solaris 11, providing a much-simplified dladm command and the ability to monitor packets on the links that comprise an 802.3ad link aggregation. We are now hard at work on the [[core components>>attach:Community Group networking.WebHome@clearviewcomponents.txt]] which build upon the foundation laid by Phase 0.
84: 
85:  These components are:
86: 
87: * IPMP Rearchitecture [[[Initial Design Discussion]>>http://www.opensolaris.org/jive/thread.jspa?threadID=2199]] [[[Follow-up Discussion]>>http://www.opensolaris.org/jive/thread.jspa?threadID=2481]] [[[Wrap-up Discussion]>>http://www.opensolaris.org/jive/thread.jspa?threadID=3393]]
88: * IP Tunnel Device [[[Initial Design Discussion]>>http://www.opensolaris.org/jive/thread.jspa?threadID=2382]] [[[Follow-up Discussion]>>http://www.opensolaris.org/jive/thread.jspa?threadID=2574]] [[[Wrap-up Discussion]>>http://www.opensolaris.org/jive/thread.jspa?threadID=2382&#17039]]
89: * Vanity Naming and Nemo Unification [[ [Initial Design Discussion]>>http://www.opensolaris.org/jive/thread.jspa?threadID=4141]] [[ [Follow-up Discussion]>>http://www.opensolaris.org/jive/thread.jspa?threadID=4721]] [[[Wrap-up Discussion]>>http://www.opensolaris.org/jive/thread.jspa?threadID=5981]]
90: * IP-Level Observability Devices [[[Initial Design Discussion]>>http://www.opensolaris.org/jive/thread.jspa?threadID=3072]][[[Wrap-up Discussion]>>http://www.opensolaris.org/jive/thread.jspa?threadID=5750]]
91: 
92:  We are currently in the development phase. Community members with technical expertise and interest in one or more of the areas being worked on by Clearview are welcome to contact meem for details on possible collaboration opportunities.
93: 
94: **CrossBow**
95: 
96:  Crossbow provides the building blocks for utility computing by creating virtual stacks around any service (HTTP, HTTPS, FTP, NFS, etc.), protocol (TCP, UDP, SCTP, etc.), or Solaris Containers. The virtual stacks are separated by means to H/W classification engine such that traffic for one stack does not impact other virtual stacks. Each virtual stack can be assigned its own priority and band-width on a shared NIC without causing performance degradation to the system or the service/ container. The architecture dynamically manages priority and bandwidth resources, and can provide better defense against denial-of-service attacks directed at a particular service or container by isolating the impact just to that service or container.
97: 
98:  Slide Presentation at [[SunLabs>>http://research.sun.com/]] Open House 2005 (28 April 2005):
99: [[CrossBow: Network Stack Virtualization & Resource Control>>attach:Community Group networking.WebHome@crossbowsunlabsext.pdf]]
100: 
101: **Quagga Routing Protocol Suite Project**
102: 
103:  This project aims to integrate the [[open-source quagga routing protocol suite>>http://www.quagga.net]] into the Solaris Nevada SFW consolidation, replacing the SFWzebra package. Quagga is a fork of GNU Zebra (the version of zebra currently in sfw - SFWzebra - is based on GNU Zebra 0.92a, with many fixes, particularly to ospfd).
104: 
105:  By integrating quagga, we hope to provide customers with a routing protocol suite supporting a wide range of routing protocols, and with a very active developer community. We aim to integrate quagga into Solaris "as is" ~-- i.e. the community version, with no changes.
106: 
107:  One challenge is that quagga for Solaris now provides an SMF manifest for its routing daemons, but Solaris routing management is not currently SMF-oriented. As such, this project also contains a Solaris Nevada ON component to update routing management to support SMF routing daemons, and refactor routing management as a set of SMF services. It also intends to provide service conversions for in.routed and in.ripngd. Of course these intentions are based on the current design, and may change based on feedback received ~-- hopefully from you!
108: 
109:  If you’re interested in quagga/routing management or SMF we’d love to hear your comments and suggestions, and we welcome community participation throughout the project. In addition, there are a few bite-size pieces of this reasonably small project that the community might like to get involved with. You can also participate in the [[ongoing design discussion on networking-discuss>>http://www.opensolaris.org/jive/thread.jspa?threadID=3091]]. We’d prefer to have the conversation there so the community can participate, but if you need to you can reach us in Sun at quagga-iteam at sun dot com.
110: 
111: **IPFilter (Follow-on)**
112: 
113:  A primary opporunity for you to develop code to form part of Solaris IPFilter is to provide additional proxy modules that have more knowledge about protocols such as HTTP, SMTP, etc. There is support within IPFilter to allow external entities to register proxies, paving the way for independant kernel modules to be developed and provide this kind of functionality. The interfaces involved here have **no** stability level here, so there’s no guarantee of backward compatibility if you do embark down this path.
114: 
115:  Another prime candidate here is development of more detailed knowledge of other layer 4 protocols, such as SCTP.
116: 
117: **hxbt**
118: 
119:  Hxbt is a Stream module/driver which emulates a WAN environment. It captures packets from IP and manipulates the packets according to the WAN setup. There are five parameters to control the environment. They are network propagation delay, bandwidth, drop rate, reordering, and corruption. Hxbt acts like a "pipe" between two hosts. And the pipe is the emulated WAN.
120: 
121:  For more information download the [[source>>attach:Community Group networking.WebHome@hxbt.tar.gz]] or take a look at the [[README.>>attach:Community Group networking.WebHome@readme.hxbt.txt]]
122: 
123: **Network Auto-Magic**
124: 
125:  Network Auto-Magic, aka NWAM, is a project to simplify and automate network configuration on Solaris.
126: 
127:  For more information about this project, please check out the [[NWAM project page>>Project nwam.WebHome]].
128: 
129: **Additional Solaris Networking Information**
130: 
131: BigAdmin System Administration Portal:
132: [[Solaris OS Network Performance>>http://www.sun.com/bigadmin/content/networkperf/]]
133: 
134: Solaris Forum Discussion Forum:
135: [[BigAdmin High Performance Networking Discussion Forum>>http://forum.sun.com/forum.jspa?forumID=272]]
136: 
137: **Linking to other Communities**
138: 
139: [[Laptop Community>>Community Group laptop.wireless]]
140: 
141: [[Approachability Community>>https://www.opensolaris.org/os/community/approachability/]]
142: 
143: [[Security Community>>Community Group security.WebHome]]
OpenSolaris

Top Menu

Wiki code for Networking

Search

Collectives

Community Group

Project

User Group

Subsites

Community Group networking Pages
