Planning the Diffserv Network Topology
To provide differentiated services for your network, you need at least one IPQoS-enabled system and a Diffserv-aware router. You can expand this basic scenario in a variety of ways, as explained in this section.
Hardware Strategies for the Diffserv Network
Typically, customers run IPQoS on servers and server consolidations. Conversely, you can also run IPQoS on desktop systems, depending on the needs of your network.
Oracle Solaris systems that offer various services, such as web servers and database servers
Application servers that offer email, FTP, or other popular network applications
Web cache servers or proxy servers
Network of IPQoS-enabled server farms that are managed by Diffserv-aware load balancers
Firewalls that manage traffic for a single heterogeneous network
IPQoS systems that are part of a virtual local area network (LAN)
The following list describes possible systems for an IPQoS configuration:
You might introduce IPQoS systems into a network topology with already functioning Diffserv-aware routers. If the local router does not implement Diffserv, then the router passes marked packets on to the next hop without evaluating the marks.
IPQoS Network Topologies
This section illustrates IPQoS strategies for various network needs.
IPQoS on Individual Hosts
The following figure shows a single network of IPQoS-enabled systems. This network is only one segment of a corporate intranet. By enabling IPQoS on the application servers and web servers, you can control the rate at which each IPQoS system releases outgoing traffic. If you make the router Diffserv aware, you can further control incoming and outgoing traffic.
The examples in this guide use this scenario.
Figure 3 IPQoS Systems on a Network Segment
IPQoS on a Network of Server Farms
The following figure shows a network with several heterogeneous server farms. In this setup, the router is Diffserv-aware, and therefore able to queue and rate both incoming and outgoing traffic. The load balancer is also Diffserv-aware, and the server farms are IPQoS enabled. The load balancer can provide additional filtering beyond the router by using selectors such as user ID and project ID. These selectors are included in the application data.
Figure 4 Network of IPQoS-Enabled Server Farms
This scenario provides flow control and traffic forwarding to manage congestion on the local network. This scenario also prevents outgoing traffic from the server farms from overloading other portions of the intranet.
IPQoS on a Firewall
The following figure shows a segment of a corporate network that is secured from other segments by a firewall. In this scenario, traffic flows into a Diffserv-aware router where the packets are filtered and queued. All incoming traffic that is forwarded by the router then travels into the IPQoS-enabled firewall. To use IPQoS, the firewall must not bypass the IP forwarding stack.
Figure 5 Network Protected by an IPQoS-Enabled Firewall
The firewall's security policy determines whether incoming traffic is permitted to enter or depart the internal network. The QoS policy controls the service levels for incoming traffic that has passed the firewall. Depending on the QoS policy, outgoing traffic can also be marked with a forwarding behavior.