Chapter 2 Architecture

Product Structure

Solaris Bandwidth Manager contains the following major components:

• The administration tool, batool, provides a graphical interface for configuring bandwidth management. This can be run as an applet or an application from any machine in your network that has a Java Virtual Machine. It also allows you to create a bandwidth management schedule, and view statistics.

• The policy agent implements the configuration and handles communication with the kernel module. See "The Policy Agent" for details of how the policy agent works.

• The kernel module is viewed as a STREAMS driver, /dev/ipqos, by the tools in user space, and is viewed as a STREAMS module, ipqos, by the IP stack. It contains the classifier and the scheduler.

  • The classifier allocates packets to a class queue.

  • The scheduler determines the order in which queued packets are forwarded across the network, and applies the bandwidth limits and priorities configured for each type of traffic.

• A set of Java APIs allow you to write applications to configure Solaris Bandwidth Manager, use a directory service with Solaris Bandwidth Manager and gather statistics. There is also a C Statistics API.

• In addition to the statistics gathering capabilities of batool, the statistics utility, bastat, displays statistics on the bandwidth management configuration in use.

• The SNMP agent enables you to monitor Solaris Bandwidth Manager using any SNMP management utility, such as Solstice(TM) Site Manager(TM) or Solstice Domain Manager(TM). This is a component of the policy agent.

• Commands and utilities for managing the Solaris Bandwidth Manager software and monitoring your network

The diagram below shows the architecture of Solaris Bandwidth Manager.

Figure 2-1 Solaris Bandwidth Manager Architecture

Administration Tool

You can use the administration tool, batool, to configure Solaris Bandwidth Manager. It has two modes:

• In on-line mode, you can change the configuration currently being used by the kernel module. This is useful if an immediate temporary change is required because of a problem in your network. You also have the option of saving the current configuration, so that your changes are preserved. On-line mode allows you to observe the consequences of a particular configuration before you save it.

• In off-line mode, you can change a configuration without disturbing the current behavior of the kernel module. This is useful if you want to make changes in the configuration without disrupting users, and have them implemented the next time the product is restarted.

The administration tool communicates with the kernel module through the policy agent. batool sends configuration changes to the kernel module, and the kernel module sends statistics to batool.

See Chapter 5, Configuring Solaris Bandwidth Manager Using batool for a more detailed description of batool and how to use it. You can also configure Solaris Bandwidth Manager by editing the configuration files, or from a directory service.

The Policy Agent

The policy agent is the communications hub of Solaris Bandwidth Manager. It controls the information sent to and from all other components, and the policies that they operate. It is implemented using the Java Dynamic Management^TM Kit framework. It contains a set of Java management beans (m-beans) and their exported interfaces. See Appendix A, Policy Agent Architecture for more detail on the architecture of the policy agent.

Flows

A flow is a complete exchange of information between a sender and a recipient, as seen from the user's point of view. Examples of flows include sending a mail message, or downloading a web page.

A flow is defined by:

• The interface used

• The source and destination IP addresses

• The IP protocol (TCP, UDP or other)

• The source and destination ports (TCP and UDP)

• The IP type of service (TOS) value

• The URL

Since the TOS value can change during the lifetime of a flow, a flow can move from one class to another. However, this is not recommended, as packet ordering can be compromised.

Information about all current flows is stored in a cache. When a packet arrives, its flow characteristics are compared with the cache information to see whether it is part of an existing flow or whether a new flow has started. The cache record includes the flow identification information and the following statistics:

• The number of packets sent

• The number of octets sent

• The system uptime when the first packet arrived

• The system uptime when the last packet arrived

---

Note -

A flow is terminated 60 seconds after the last packet in the flow was detected. This is not configurable.

---

Monitoring flows rather than classes gives a more accurate picture of network usage, at finer granularity. This enables you to predict future network needs more accurately, and gives you information that can be used in accounting.

You can use batool to view flow statistics. See Chapter 8, Statistics. You can also use any billing or accounting package that is compatible with version 5 of the CISCO NetFlow protocol.

Type of Service Support

An IP packet contains a type of service (TOS) field. Its purpose is to convey information about how the packet should be processed. Solaris Bandwidth Manager can use this information when classifying a packet. It can also change the information, to influence how the packet is processed.

"IP Specification of TOS" is a summary of the type of service definition from the IP specification. "Solaris Bandwidth Manager and Type of Service" explains how Solaris Bandwidth Manager interacts with TOS.

IP Specification of TOS

The IP specification includes a definition of a Type of Service field in an IP packet header. This is intended to be used by upper-layer protocols to pass information to the Internet layer about how to optimize routing for the packet.

Network topology means that there are often a number of available routes between the source and destination of a packet. Some routes are more reliable than others. Some are expensive, with high call setup or usage charges, while some are low-cost but slow. The most suitable route for a packet depends on the application and user, and might even vary with other factors such as the time of day. For example, if you are a system administrator monitoring a remote system, you need to receive alarm traffic as rapidly as possible regardless of the cost, because the cost of routing the alarm is significantly lower than the cost incurred by a system problem. However, if you start to get a document by ftp from the same system at the end of your working day, intending to use it the following day, a low-cost, slow route is sufficient.

The Internet Layer has no direct knowledge of how to optimize a route for a given application or user. The TOS facility was intended to provide hints about how best to route a packet, influencing both queueing algorithms and routing. It contains a 3-bit precedence field and a 4-bit TOS field. The setting of precedence field indicates one of the following values for the precedence:

• Network

• Internet

• Critical

• Flash-override

• Flash

• Immediate

• Priority

• Routine

The possible settings of the TOS field are:

• Minimize delay

• Maximize throughput

• Maximize reliability

• Minimize monetary cost

• Normal service

The TOS facility has not been widely used in the past, but the Internet Engineering Task Force (IETF) is now working to modify the definition of TOS and to encourage its use.

Solaris Bandwidth Manager and Type of Service

The Type of Service facility is provided by the IP protocol to convey information about how individual packets should be directed over the Internet. The TOS field controls the routing and queueing algorithms in gateway operations.

The TOS byte contains a Precedence field, a TOS field and an Empty field.

• The Precedence field contains 3 bits which sets the Precedence level for the byte.

• The TOS field contains the TOS match value. This will be matched against the packet and is expressed as a hexadecimal value.

• The MBZ field is currently unused and must be set to 0.

For more information, refer to RFC 1349 Type of Service in the Internet Protocol Suite, by P. Almquist.

Solaris Bandwidth Manager Modes

Solaris Bandwidth Manager can be used in one of two modes: server mode or IP-transparent mode.

Server Mode

On a host that is a source of IP traffic, run Solaris Bandwidth Manager in server mode. A host is a source of IP traffic if has only one network connection, to either the WAN or the LAN, or because it is a router of traffic.

Figure 2-2 Solaris Bandwidth Manager in Server Mode

Figure 2-3 Solaris Bandwidth Manager on a Router in Server Mode

When an interface for which bandwidth management is configured is initialized (usually at system startup), the ipqos module is pushed on to the IP stack, between IP and the interface. The Solaris Bandwidth Manager policy agent reads the configuration file and loads the configuration information into the ipqos module. The ipqos module then processes all traffic according to the configured definitions.

---

Note -

If a firewall is running on the same machine, install Solaris Bandwidth Manager on an interface that is not running encryption software.

---

IP-Transparent Mode

On a host that is between a LAN and a router, run Solaris Bandwidth Manager in IP-transparent mode.

This mode is called IP-transparent because the host running Solaris Bandwidth Manager is completely transparent to the IP network and is perceived as just another machine connected to the LAN. The LAN and the WAN behave as though they are directly connected through the router only. It is not necessary to modify the routing tables.

Figure 2-4 Network Configuration Without Solaris Bandwidth Manager

Figure 2-5 Network Configuration--IP-Transparent Mode

Kernel Architecture

The Kernel contains three modules which receive, filter, classify, schedule and forward the packets between the LAN and the router. The logical flow of data in IP-transparent mode is shown by the dashed lines in Figure 2-6.

ipqos1	implemented into the IP stack by autopush.ba and autopush_usr.ba during system startup. This module monitors the packets arriving at the host from the LAN but only processes packets addressed to the host machine.
ipqos2	implemented when the policy agent is started. This module monitors the packets arriving at the host from the LAN, and is used to filter and distribute them within the kernel.
ipqos3	implemented when the policy agent is started. This module interface monitors the packets arriving at the host from the LAN or WAN and classifies and schedules them. The classes for the configuration file are stored in this module.

Traffic Flow From the LAN

Traffic from the LAN to the host running Solaris Bandwidth Manager is received by the LAN interface.

If the destination IP address of the packet is the host running Solaris Bandwidth Manager it is dropped by ipqos2 as it will have already been sent up the IP stack by ipqos1.

If the destination IP address of the packet is not the host running Solaris Bandwidth Manager then the packet is forwarded directly to the router in the following cases:

• the IP packet is addressed to the router

• the packet is not an IP packet and non-IP mode is set to direct in the configuration file

• it is a multicast packet and multicast mode is set to direct

Otherwise, the packet will be classifed and scheduled by ipqos3.

Traffic Flow From the WAN

Traffic from the WAN is forwarded to the LAN via ipqos3 and ipqos2.

• ipqos3. Packets are not classified and scheduled in the following circumstances:

  • if ipqos3 is not configured for regulating incoming traffic

  • the multicast parameter is set to direct

  • the packet is not an IP packet and non-IP mode is set to direct

• ipqos2. This module checks the destination IP address. If the packet is addressed to the host running Solaris Bandwidth Manager, it is sent up the IP stack, via ipqos1. Otherwise it is forwarded to its destination.

Figure 2-6 Traffic Flow in IP-Transparent Mode

Only ipqos3 can be configured via the configuration file so any reference to the interface in this file must be the WAN interface. Configure the network device option in the configuration file to reference the LAN interface in one of the following ways:

• by editing the network keyword in the interface section of the configuration file

• using the Configuration Interface window of batool.

Non-IP Packets

Non-IP traffic bypasses ipqos if the nonip_mode parameter is set to direct. These packets are not logged in the flow statistics. If set to ipqos, the traffic is sent to the default class, or the root class if no default class is configured.

Multicast Routing and Solaris Bandwidth Manager

In server mode, Solaris Bandwidth Manager does not distinguish between multicast and other types of traffic. However, if you are using Solaris Bandwidth Manager in IP-transparent mode, it is not possible to predict automatically whether a router will forward a multicast packet, since this depends on your network configuration.

Therefore, there are three options to control how Solaris Bandwidth Manager handles multicast traffic. Choose the most appropriate option for your network:

• Send through the ipqos module any traffic that might be forwarded by the router. This makes sure that traffic that is forwarded has bandwidth allocated. Send traffic that will not be forwarded by the router directly to the router, not through the ipqos module.

  The router needs to be aware of all multicast traffic, even traffic that it does not forward. The router does not forward traffic with a time-to-live of less than 2, or that is intended for the local subnet only (that is, traffic with a destination address in the range 224.0.0.0 to 224.0.0.255).

• Send all multicast traffic directly to the router, not through the ipqos module. Do this only if you know that the router will never forward any multicast traffic.

• Drop multicast packets and do not send them to the router. This means that the router never receives any multicast traffic.