8.6 Integrating QoS

As indicated, quality of service is a highly active area of research and experimentation, with several competing and complementary technologies. Over the next few years it is anticipated that these technologies will begin to integrate, since without true integration between LAN, MAN, and WAN environments there is no hope of providing true end-to-end service quality. If different QoS mechanisms are to be run in each of these environments (and this is to be expected), then clear interfaces and service mappings must be defined and adhered to. To this end several initiatives are underway, particularly within the IETE Perhaps before discussing some of these initiatives it is worth placing the components of the various QoS and traffic engineering architectures in context, as illustrated in Figure 8.14. Note that this figure does not imply protocol stack choices or combinations; it merely places the various components in their logical position.

click to expand
Figure 8.14: Pieces of the QoS jigsaw puzzle in context.

8.6.1 Using RSVP with DS

There are several fundamental issues with RSVP and the IS model that hinder widespread adoption, particularly over the Internet. In particular RSVP's reliance on per flow state and per flow processing raises scalability concerns. This complexity means that only a minority of hosts generate RSVP signaling, and many applications may never generate RSVP signaling. For these reasons it may be applicable to deploy IS only in intranets, and use DS over the Internet backbone. This is currently the subject of a draft RFC [35].

Figure 8.15 illustrates an example: Two RSVP-capable customer intranets are connected to the Internet backbone, running DS. Within the DS domain, Boundary Routers (BR) may condition incoming and outgoing traffic at the backbone ingress and egress. Note that the boundary routers are not required to run RSVP; they are expected to implement the policing functions of the DS ingress router. The routers in the DS network must provide a set of per hop behaviors that support an appropriate end-to-end service quality, enabling the mapping of RSVP flow reservations to an appropriate DS service class. The edge boundary routers that join the DS and IS domains support both RSVP and DS functions. The RSVP component must be able to process path and Resv messages, but it is not required to support packet classification or hold RSVP states. The DS component provides an admission control function for the DS network. If a static SLA is used at the IS-DS boundary, then the admission control service could just be a simple table that specifies the QoS for each service level. If the SLA is dynamic, then the admission control service communicates with counterparts within the DS network to make decisions based on the capacity of the network.

click to expand
Figure 8.15: The transit (backbone) network is running DiffServ for scalability and ease of deployment. RSVP is run on the stub (access) networks between the edge routers and the backbone routers.

RSVP signaling is used to provide admission control to specific service levels in the DS and the IS network. If an RSVP reservation message from the IS domain arrives at an edge boundary router, the RSVP flow descriptor must be mapped to a PHB that represents the corresponding service level in the DS network. The edge router appends the PHB value to the RSVP reservation message, which is carried to the sending host. The sending host then marks all outgoing packets with this PHB value. This approach allows end-to-end QoS guarantees for RSVP applications in different intranets that use the DS Internet as backbone.

8.6.2 Using RSVP with 802.1p

In order to offer true end-to-end QoS from LAN to other network media, we need a way to bind RSVP and IEEE 802.1p together. Reference [27] defines a signaling protocol for RSVP-based admission control over IEEE 802 networks called the Subnet Bandwidth Manager (SBM). SBM conveys 802.1p priorities between Layer 2 switches. It also maps Class of Service (CoS) between RSVP clients and RSVP-enabled networks, describing how LAN hosts, switches, bridges, and routers should operate to enable LAN-based resources to be reserved for RSVP-enabled data flows. For the interested reader, [24] specifies a framework for providing IS over shared and switched LAN technologies.

8.6.3 Using 802.1p with ATM

An increasing number of customers are deploying 802.1p on their switched Ethernet LANs to queue packets using priority. 802.1p prioritizations may be mapped to high-speed ATM switch uplinks provided that the uplinks support both 802.1p and PNNI/LANE. The ATM uplink can request QoS Available Bit Rate (ABR) for those packets destined to travel across the ATM fabric. ABR enables a connection to use whatever bandwidth is currently available, so theoretically the switch could request different ABR QoS profiles for different 802.1p priorities. This does not provide all of ATM's QoS features to Ethernet, but it does enable Ethernet prioritization over ATM.

8.6.4 Using DS with IPSec

IPSec considers the DS field (or ToS field) an immutable field in an IP header; therefore, changes made to the DS field in transit do not compromise end-to-end security. If IPSec is used in tunnel mode, then different DS domains may be supported. Here, the outer IP header and the encapsulated IP header correspond to two different DS domains, and the tunnel end points delimit the two DS domains.

8.6.5 Interoperability with constraint-based routing

Constraint-Based Routing (CBR) is a complementary technology to many of the technologies described in this chapter, as follows:

CBR with DiffServ—DS and CBR are complementary. CBR may be used to assist in the delivery of DS since the QoS requirement of the flow and the load of the networks are considered in selecting the best path.
CBR with RSVP—RSVP and CBR are also complementary. The next hop of the RSVP path message determined by CBR might be different from that calculated by dynamic routing, since the QoS requirement of the flow and the load of the networks are considered in selecting the next hop.
CBR with MPLS—MPLS and CBR together provide a powerful traffic engineering tool. Given a set of routes MPLS uses its label distribution protocol to set up the LSPs. The routing agent is transparent to MPLS and vice versa. If these routes are determined by CBR instead of a dynamic routing protocol, then this makes it possible to do CBR with traffic trunk granularity, without having to perform flow classification within the core routers. MPLS provides per LSP statistics that offer CBR very precise information on traffic levels between every ingress-egress pair, enabling CBR to compute better routes for setting up LSPs.

8.6.6 QoS policy management

In a large QoS-enabled internetwork, especially in a multivendor environment, conventional ways of managing control and configuration data do not scale. It is critical in this environment, where customers are paying for service differentiation, that systems behave consistently. All network entities should ideally be configured under a single policy-based framework, so that service differentiation can be expressed in business terms and then translated into specific device behavior. For example, the network planner may wish to create predefined service classes (e.g., bronze, silver, or gold) and then have routers and switches utilize queuing and congestion control features to support these service classes. If conflicting policy information exists in parts of the network, packets may not receive the requested level of service in certain domains, and the SLA made between customer and provider could be violated. In dynamic network environments it is also necessary to support flexible policy definitions so that behavior can be altered dynamically in the face of certain events (e.g., time of day, network overload, link loss, etc.).

Reference [36] describes a preemption priority policy element for use by signaled policy-based admission protocols (such as RSVP and COPS). For other RSVP policy-related specifications, see [37, 38].