End-to-End QoS

---

Voice and multimedia applications require end-to-end QoS. As the reader should now understand, in the communications industry, "Quality of Service" describes the treatment data receives over a network. QoS may be applied at various points that can serve as "bottlenecks" or "points of aggregation," to give precedence to specific data to ensure quality across those points. However, appropriate levels of QoS must be applied throughout the network to ensure consistent treatment. This is known as "end-to-end QoS."

From the overall network service perspective, QoS should provide end-to-end traffic control, so that users' applications can be properly served according to the allowable quality requirements, such as latency, jitter, and packet loss rate. To comply with the service quality requirements, user level traffic of the applications should coordinate QoS traffic control with transport level QoS at the network interfaces. 802.11e working alone can't provide this. However, an end-to-end QoS architecture across wired wide area networks, wired local area networks, and wireless LANs, which are based on DiffServ, 802.1D/Q, and 802.11e, respectively, could provide the level of service necessary to support quality real-time traffic.

Consider Fig. 16.3, where the user traffic QoS specifies end-to-end network traffic delay, jitter, and policing. Since most data services accessed by remote servers carry user traffic through multiple heterogeneous networking environments, the user level QoS should be decomposed into each network interface segment as follows:

Figure 16.3: End-to-end Quality of Service (QoS) network structures.

Radio access network allows air interface between a mobile station (wireless computing device) and an access point (AP) as defined by 802.11e. Under the prioritized QoS paradigm of 802.11e, there is differentiated channel access to traffic with eight different priority levels.

Wired LAN is the Ethernet interconnection between AP and gateway terminating subnet traffic, including traffic through other MAC bridges. 802.1D/Q specifications define the QoS mechanisms that can be used in a wired LAN. Similar to a WAN's DiffServ, 802.1D/Q also classifies the traffic type and prioritizes on the traffic class at the bridge.

Managed IP WAN is a wireline interface managed by network service providers such as a telco. The Managed IP WAN is normally managed by a Service Level Agreement (SLA). A user's traffic DiffServ parameters can be directly reflected into the IP routers, so that traffic can be prioritized over other traffic, if necessary.

802.11 WLAN will utilize mechanisms set forth in the 802.11e specification, when it is ratified. The specification is virtually complete and should be ratified before 2004, thus there have been some reports about the utility of 802.11e. These reports, however, have been focused on QoS issues at the Layer 2 single hop, i.e., the wireless link between a computing device and an access point. Yet, most user traffic in the Application Layer traverses multiple networks, which means that end-to-end QoS is crucial.

802.11e

As the multimedia applications (e.g. voice over IP) and streaming media (e.g. audio/visual streaming via the Internet) emerge, and as portable devices such as laptops and PDAs become more and more popular, interest in having a level of service similar to those available from the conventional wired networks grows. But the wireless network's architecture must extend so it can handle such applications. The emerging 802.11e standard just may be the ticket for the air interface for such multimedia applications.

In fact, the main push for QoS features over a Wi-Fi network comes from the 802.11e specification. The 802.11 Working Group established the 802.11e Task Group and gave them the mandate of enhancing the current 802.11 MAC protocol to support applications with QoS requirements. This new QoS initiative should provide several levels of performance specifically tailored to take maximum advantage of all available data rates, from 802.11b's 11 Mbps to 802.11a/g's 54 Mbps. The multi-tiered performance levels provisioned in the 802.11e specification range from basic Internet applications to high quality video streaming and support for voice applications.

The basic Wi-Fi media access mechanism is to listen before sending, with slotted random backoff (i.e. CSMA/CA) and packet-by-packet acknowledgment (i.e. automatic repeat request or ARQ). This mechanism is used because today's radios can't transmit and receive at the same time, so that detecting collisions is difficult. Instead of collision detection (as used in 802.3 wired networks, ergo their use of CSMA/CD rather than CSMA/CA), a positive acknowledgment is sent for each correctly received packet. The sending device knows to retransmit the packet if an acknowledgment is not received. Furthermore, since WLANs often operate with packet loss rates of around 10 percent because of noise and interference, quick retransmission at the physical level is necessary. As shown in Fig. 16.4, 802.11e enhances this basic media access mechanism to provide QoS. Different traffic streams can be given different priority access to the wireless channel by adjusting their initial waiting period (i.e. Arbitration InterFrame Space or AIFS), and their random backoff contention window (i.e. CW min and CW max).

Figure 16.4: How the 802.11 MAC's basic mechanism is being enhanced in 802.11e to provide QoS.

In order to support both IntServ and DiffServ QoS approaches (see Text Box) in Wi-Fi networks, 802.11e defines a new mechanism called hybrid coordination function (HCF). This mechanism is backwardly compatible with basic DCF/PCF. It has both polling-based and contention-based channel access mechanisms in a single channel access protocol. Thus the HCF combines functions from the DCF and PCF with some enhanced QoS-specific mechanisms (EDCF and EPCF) and QoS data frames in order to allow a uniform set of frame exchange sequences to be used for QoS data transfers.

The HCF uses Enhanced DCF (EDCF) as a contention-based channel access, which operates concurrently with a controlled channel access based on a poll-and-response protocol. EDCF is designed to provide differentiated, distributed channel accesses for frames with eight different priorities (from 0 to 7), by enhancing the legacy DCF. Each frame from the higher layer arrives at the MAC along with a specific priority value. Each QoS data frame also carries its priority value in the MAC frame header. In the context of the 802.11e standard, the priority value is called Traffic Category Identification (TCID). An 802.11e computing device implements four access categories, where an access category is an enhanced variant of the DCF with a single FIFO queue. Each frame arriving at the MAC with a priority is mapped into an access category. This relative priority is rooted from the IEEE 802.1D bridge specification.

More specifically, EDCF uses priority-based service differentiation, but is still statistical in nature (which means that no absolute quality guarantees can be made), while Enhanced PCF (EPCF) allows parameterized support of QoS. Both PCF and EPCF provide the means for guaranteed bandwidth management, including support for various types of traffic, but these are optional features formulated by the 802.11e Task Group. Such option features still require CSMA/CA legacy functions.

The 1394 Trade Association Gets Involved

The 1394 Trade Association is an industry forum that develops specifications for implementation of IEEE 1394 high performance serial bus technology based on the IEEE 1394 series of standards. The IEEE 1394 series of standards provides the necessary bandwidth for audio and video content to be sent from one 1394 device to another, essentially using bridging products. Since IEEE 1394 was originally designed as a serial bus or pathway between computer peripherals, the 1394 series defines a digital serial network for interconnect by cable for a wide range of devices that employ diverse protocols and data types, including IP, MPEG, and digital video data.

Note 

IEEE 1394 provides for a single plug-and-socket connection on which up to 63 devices can be attached with data transfer speeds up to 400 Mbps. While the standard describes a serial bus or pathway between one or more peripheral devices and your computer's microprocessor, because IEEE 1394 is a peer-to-peer interface, one camcorder, for example, can dub to another without being plugged into a computer. Many peripheral devices now come equipped to meet IEEE 1394.

Wired IEEE 1394 proponents seeking the path to wireless are taking a serious look at 802.11e developments. In fact, the 1394 Trade Association's Wireless Working Group (WWG), which is chartered to deliver their industry's standard into the wireless domain, has jumped into 802.11e group activities. According to Peter Johansson, a project leader of the 1394 Working Group, this was because the WWG felt that there was a need for "a lot of explaining and education on what's needed for QoS tailored for asymmetric data traffic like audio and video." He went on to explain that the 1394 Trade Association is looking to add so-called "express traffic," which Johansson defines as "a mechanism for a prior allocation of time for access to a channel." While this isn't a guaranteed access to the radio in the strict telco sense, "we are asking that when a radio is available we get a shot at it," he said.

Note 

Peter Johansson is also the IEEE P1394.1 chairman and author of the proposal for a method to improve IEEE 802.11 QoS for audio/visual streams by applying fundamental principals and mechanisms based on the IEEE 1394 architecture.)

WHAT IS 1394?

The 1394 series of standards, which consists of (but is not limited to) 1394, 1394a, 1394b, and P1394.1, was originally designed to as an I/O InterConnect interface mainly for external digital devices. The IEEE 1394 interfacing standard's high data rates allow for real-time video transfer, and is extensively used in interconnectivity solutions for products such as PCs and PC peripherals, video cameras, video recorders, DVD players, and set-top boxes (STBs).

To understand the importance of the 1394/802.11 partnership you need to understand that 1394 is:

• A hardware and software standard for transporting data at 100, 200, or 400 megabits per second (Mbps).

• A digital interface—there is no need to convert digital data into analog and tolerate a loss of data integrity.

• Physically small—thin serial cable can replace larger and more expensive interfaces.

• Easy to use—there is no need for terminators, device IDs, or elaborate setup.

• Hot pluggable—users can add or remove 1394 devices with the bus active.

• Scaleable—may mix 100, 200, and 400 Mbps devices on a bus, flexible topology-support of daisy chaining and branching for true peer-to-peer communication.

• Inexpensive—guaranteed delivery of time critical data reduces costly buffer requirements.

• Non-proprietary—there is no licensing problem.

The 1394a standard is a supplement to the orginal 1394 specification. It supports data rates up to 400 Mbps over shielded twisted pair cable (not Category 5 cable) up to 15 feet, after which data rates fall off considerably. Nonetheless, a single 1394a cable could deliver data at speeds up to 100 Mbps up to 70 feet and through the use of $40 off-the-shelf 1394a repeaters, the distance could be extended and data rates accelerated to 400 Mbps.

1394b standard, which the IEEE ratified in April 2002, complements the IEEE's 1394a standard, and is intended mainly to replace multiple audio, video, and control cables with a single multiple-conductor cable to connect components in a cluster of components. The new standard also can be used to connect the clusters.

P1394.1 is a proposed high performance serial bus bridge that specifies the connection between multiple 1394 buses. It is being designed to allow high bandwidth subnets to be clustered together without affecting the performance of the overall interconnect.

Since 1394 is defined by the high level application interfaces that use it, not a single physical implementation, part of that backbone could be wireless. Magis, a supplier of wireless 802.11a chipsets, has demonstrated 802.11a equipment that simultaneously supports the 1394a and 802.11a protocols.

The lobbying effort appears to have worked. The 802.11e Task Group has embraced the initial QoS concepts for audio/video (A/V) streaming proposed by the 1394 Wireless Working Group. Acceptance enables the 1394 Wireless Working Group to develop a 1394 protocol adaptation layer for devices using the 802.11e QoS provisions.

Johansson also asserts that the IEEE 802.11e Task Group "looks at things from an Ethernet perspective." And that the 802.11e Task Group has "focused mainly on Voice over IP (VoIP) over 802.11 networks." But, as Johansson explains, "voice characteristics are very different from A/V [audio/visual]... and the data arrives differently." Voice doesn't require the same type of QoS guarantees as A/V because data loss is less of an issue.

The same cannot be said for multimedia, which requires a high quality, smoothly displayed multimedia stream, meaning that all of the data must arrive at the same time. But it is believed that convenient and cost effective distribution of multimedia content can be achieved by bridging 1394 content between clusters of devices using 1394/802.11 bridge devices.

The goal of especially the 1394 Trade Association, but also the 802.11e Task Group, is to apply 1394 QoS behaviors to 802.11 by addressing the problems encountered with intensive multimedia delivery over what is essentially an Ethernet standard evolved for the wireless world. Johansson says that both the 1394 and 802.11e groups "concur on the fundamental QoS concepts necessary for high-quality audio and video streams, such as scheduling and channel access. Wireless 1394 to some extent is an oxymoron." He further explains that it's more of the paradigms and behaviors of data transfer that are applicable to wireless LANs than the actual 1394 technology as it is implemented by PC manufacturers for wired devices.

Wireless 1394

Wireless 1394 over 802.11a/e could serve as the wireless backbone of a multimedia network. But for this could occur, a number of details must be worked out. For instance, the 1394 Groups must:

• Design a protocol adaptation layer (PAL) specific to IEEE 802.11.

• Specify bridges to interconnect the wired and wireless domains. This would allow firmware developed for (wired) IEEE 1394 products to migrate to wireless domain. It would also minimize reengineering between wired and wireless domains.

• Complete draft standard IEEE P1394.1 and profile the details of P1394.1 specifically applicable to bridges for IEEE 802.11.

1394 PAL would support IEEE 1394 Transport Layer functions; support isochrony and streaming data; coexist with other users of the underlying IEEE 802.11 transport; behave "like" IEEE 1394, and conceal differences between IEEE 1394 and IEEE 802.11 Physical and Data Link Layers. In turn, 1394 PAL for IEEE 802.11 will be able to permit wireless devices to talk to each other via wired to wireless bridges with the bridges isolating Physical and Data Link Layer differences in each domain from the other. It also will enable wired across wireless via bridges, enabling a wireless domain to serve as the backbone to connect wired clusters in different areas.

Toward that end, the 1394 Trade Association developed a document that specifies methods to (1) mimic IEEE 1394 infrastructure (transactions, isochrony, stream data, configuration ROM and CSR architecture) using the facilities of IEEE 802.11, and (2) implement IEEE P1394.1 bridge behaviors in the same domain. The document also states that the methods are to be compatible with the simultaneous use of IEEE 802.11 by other protocols, e.g., IP.

Steve Bard, chairman of the 1394 WWG explains, "PAL is a piece of software or firmware or an application that accepts traffic from 1394, [and] maps it to a domain such as 802.11. The ability is to bridge between previously interoperable domains." He goes on to say that, of course, to do so involves cooperative effort between the 1394 WWG and the 802.11e Task Group.

The Wireless 1394 specification is intended to spell out support for "two different logical networks over one medium," says Bard. He also points out that, "several companies in consumer electronics industry are developing a 1394/802.11 bridge," which he describes as "a small box with a 1394 socket. Plug it into your device's 1394 connection. It gets power off the 1394 connection, but also has an 802.11 radio in it. The PAL is the firmware translation layer that bridges the two domains. One box doesn't do much, but two of them solve interesting problems."

The Goal of the 802.11/1394 Partnership

It is hoped that IEEE 1394 will enhance QoS for IEEE 802.11, by establishing QoS based on scheduled management of channel access guarantees. The behaviors of 1394 that the WWG seeks to emulate for 802.11 involve things like accurate clock distribution, connection management protocols, and command sets. According to Johansson, the 1394 Working Group's goal is to "complete a spec showing how you reproduce 1394 behaviors." Johansson goes on to say that ultimately, 1394 will provide a PAL for devices using the 802.11e QoS provisions. And if you look at the 1394.1 draft specification, it provides a logical description on how to bridge 1394 into an 802.11a network. It also defines how the 1394 Trade Association's work on PAL for 802.11 (which is still a work in progress) will further smooth data construction and timing integration between wired and wireless networks.

Audio and video experts agree that 802.11 must address MAC services encompassing scheduled access to the radio channel. James Snider, the 1394 Trade Association's executive director, comments that the experience gained with wired 1394 devices can be applied, and the firmware adapted, for use in the wired or wireless environment. The final outcome of using a 1394 protocol adaptation layer in devices using 802.11e will be data transfer methods that are suitable for multimedia over WLANs. Thus, any collaboration between these two groups would prove quite beneficial.

802.11e Applications

802.11e focuses on three kinds of multimedia applications: IP-based applications, IEEE 1394-based consumer device applications, and converged IEEE 1394 and wireless IP multimedia applications. Let's look at how 802.11e does it.

IP-based multimedia applications are supported by not only the H.323 series of standards including the G.723.1 audio codec to enable interoperability between IP-based multimedia applications, but also the Session Initiation Protocol (SIP), which is used for initiating an interactive user session that involves multimedia elements such as video, voice, chat, gaming, and virtual reality. IP-based multimedia applications (e.g. web-based call centers, multicast enabled applications, and H.323-enabled and/or SIP-enabled interactive audio and video applications) are commonly found in not only the Internet, but also corporate intranets. Implementation of VoIP over Wi-Fi networks is an obvious extension of IP-based multimedia applications.

For VoIP applications, wireless handsets, softphones, or PDAs typically support either H.323 or SIP for call control. Originally developed by the International Telecommunications Union (ITU) for desktop videoconferencing, H.323 is commonly used for IP telephony phones and IP PBXs. But, because H.323 was originally a videoconferencing standard, its functionality is better suited for multimedia applications.

SIP, which was developed by the Internet Engineering Task Force (IETF) as an Application Layer signaling protocol, allows end-users to use IP networks (including Wi-Fi networks) to establish sessions, instead of just phone calls, which can include voice, video, or instant messaging. SIP can be used in "presence" applications where users can list themselves as available, similar to a buddy list. With a SIP client on a PDA, you can turn the PDA into an 802.11 phone.

Furthermore, unlike H.323, which is based on binary-encoding, SIP is a text-based protocol so applications are easier to implement, thus SIP will win out over H.323, especially for voice over WLAN applications. Another item in SIP's favor is that it can support IP mobility and thus should be able to work with 802.11e to provide quality voice delivery over a Wi-Fi network.

IEEE 1394-based multimedia applications include both consumer device applications and converged 1394 and wireless IP multimedia applications. IEEE 1394 is an evolutionary standard when compared to current I/O (input/output) interfaces, and provides a good networking foundation for consumer electronic devices, with hot plug and play, high data rate, and QoS support benefits. The 802.11e specification is being designed to support at least three simultaneous 1394-based DVD rate MPEG-2 channels, or one HDTV rate MPEG-2 channel over an 802.1 la network. The IEEE 1394 applications can run directly over the 802.11e MAC, or use an IP encapsulation to run over the 802.11e MAC. Since the IEEE 1394 bus is a Data Link Layer network with isochronous transfer mode capability, it is quite natural that there must be the capability to transmit specific IP flow through a certain isochronous channel of 1394 bus, and A/V flow (such as MPEG2-TS) through a certain isochronous channel of the 1394 bus. So it is necessary to take note of the relationship between channel ID and IP flow, the bandwidth of the isochronous channel, the direction of the IP flow transmitted through the channel, and the attribute of the flow.

Wireless IP multimedia applications are supported by 802.11e when the transmission is between computers, gateways, PDAs, STB (Set-in-Box) TVs, and so on. Higher-layer multimedia applications can use the RTP/RTCP protocol and IP DiffServ to map the user priority to 802.1D-based MAC priority and then pass the prioritized data to different access categories of 802.11e MAC. They communicate to the 802.11e MAC through the 802 Data Service Access Point (DSAP) and Management SAP (MSAP).

802.1D/Q

The IEEE 802.1D MAC bridge specification (for wired networks) allows different MAC sublayers in the IEEE 802 family to interwork. (An 802.11 access point typically implements an 802.1D bridge connecting the 802.11 MAC and 802.3 MAC.) The 802.1D bridge supports up to eight user priorities by implementing multiple FIFO (first in first out) transmission queues between two MAC entities. By default, priority queuing can be used for these multiple queues. That is, a frame can be forwarded to the egress MAC only if there is no frame in the higher priority queues.

The 802.1Q Virtual LAN (VLAN) tag extends the existing 802.3 frame format for wired LANs, and it specifies the user priority of the frame. (The 802.3 MAC itself does not support any differentiated channel access to different priority traffic, but via the 802.1Q VLAN tag, the 802.3 MAC frames can carry the corresponding priority value, which in turn can be used by the 802.1D MAC bridge for a prioritized forwarding.) Since the 802.11e EDCF QoS scheme roots are in the 802.1D specification, priority parameters of 802.11e and 802.1D are interoperable.

When the 802.11e MAC frame is received at the ingress of a VLAN bridge supporting 802.1D/Q, it is classified by a VLAN ID, filtered via a filtering ID, and forwarded based on the traffic class that is mapped by the user priority. When the traffic class is mapped by user priority, 802.1D/Q frames are allocated into specific priority queues according to the traffic classes. When the traffic frames are dequeued from the forwarding process, it is transmitted to the next bridge via egress. Also note that 802.1Q has a recommended mapping table between user priorities that are defined in 3 bits of TCI (Tag Control Information which is part of the VLAN Tag Header) in 802.1Q, and traffic classes that specify the priority queue in traffic forwarding process in VLAN bridges.

End-to-end QoS Coordination via DiffServ

DiffServ currently is considered the dominant QoS protocol in the Network Layer. It does this by dividing network traffic into classes:

• EF (Expedited Forwarding)—interactive application packets (e.g. online gaming, VoIP, or videoconferencing) will reach their destination with short delay and little jitter.

• AF (Assured Forwarding)—packets will be treated with minimal sustained throughput. While this might work in some instances for interactive applications, in most instances it would not assure delivery without delay or jitter.

• BE (Best Effort)—packets will be sent via best effort, so there may be some packet loss and the packets may not arrive together. Thus there might be delay and considerable jitter if the packets carry interactive application data.

However, even though DiffServ provides support across different network interfaces—in wireless and wired LAN environments—DiffServ alone cannot function to control traffic for QoS over these different topologies. That is because it is difficult to map between different service domains or subnetworks such as WLANs. Instead, 802.11e and 802.1D/Q must be used to provide QoS in the MAC sublayer. But since 802.11e and 801.1D/Q are non-DiffServ domains, end-to-end QoS environment cannot be provided properly unless these different QoS techniques are coordinated under common QoS specifications.

Let's take a second to recap. The 802.11 specifications provide for two coordination functions: (1) The mandatory distributed coordination function (DCF) built on Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA), and (2) an optional point coordination functions (PCF) built on a poll-and-response protocol. However, most Wi-Fi devices implement the mandatory DCF mode only.

Figure 16.5: A typical end-to-end DiffServ architecture. A DiffServ edge router handles the classification, metering, and marking of the packets, while the core routers take care of queue management, scheduling, and traffic shaping.

The DCF functions control traffic based on non-preemptive service (i.e. first in first out or FIFO). When the MAC frame arrives at the queue, it waits until the channel becomes idle, and defers another fixed time interval, called DCF InterFrame Space (DIFS), to avoid the potential collision with other network nodes. When the channel stays idle for the DIFS interval, it starts the random backoff counter. When the backoff counter expires, the frame is transmitted over the air. If a frame arrives at an empty queue and the medium has been idle longer than the DIFS time interval, the frame is transmitted immediately. Furthermore, each computing device maintains a contention window that selects the random backoff count. The backoff count is determined as a pseudo-random integer drawn from a uniform distribution over the interval. If the channel becomes busy during a backoff process, the backoff is suspended. When the channel becomes idle again, and stays idle for an extra DIFS time interval, the backoff process resumes with the suspended backoff counter value.

It is typical that a single computing device simultaneously services multiple sessions under different applications such as VoIP, streaming video, email, or FTP. According to the service type, traffic should be treated differently at the network node. As depicted in Fig. 16.3, three network interfaces can be defined in an end-to-end network. Each network interface has independent QoS coordination functions. However, the DiffServe Code Point (DSCP) is a single point of traffic control across multiple network interfaces, so that the end-to-end QoS can be provided transparently over all networks.

WLAN

In the wireless network, the wireless computing device performs the packet classification and conditioning in the Network Layer and forwards the packet to the AP. As illustrated in Fig. 16.3, a computing device should map QoS in the IP layer to the 802.11e. In computing devices supporting DiffServ and 802.11e, the DSCP value should be mapped to the TCID placed in the 802.11e MAC QoS control field. DSCP values are recommended by standards. According to the traffic control structure, two QoS architectures can be considered—direct mapped QoS between DSCP and TCID, and Hierarchical QoS architecture.

Incorporating the Wired LAN

As illustrated in Fig. 16.3, when the AP receives either an Ethernet (i.e. 802.1D/Q) or a WLAN (i.e. 802.11e) frame in the local area network, the 802.11e AP converts the Ethernet frame into the 802.11e frame, and vice versa. Since User Priority in 802.1D/Q and TCID in 802.11e have the identical field size and meaning, they can coordinate the QoS parameters seamlessly. That is, when the 802.11e-prioritized QoS service is used, the first three bits of the 802.1Q TCI field are conveyed in the TCID field of the 802.11e QoS Control field. Note that both sets of three bits indicate the priority value of the frame. Further, the TCID of 802.11e in AP should be coordinated with the User Priorities specified in the 802.1D MAC bridge standard.

WAN

When the 802.3 MAC frames are terminated at a gateway, as illustrated in Fig. 16.3, IP packets are reassembled and forwarded to the destination. When the IP packets arrive at the intermediate IP router supporting DiffServ, specific forwarding treatments are enforced based on the DSCP values.

Delay-sensitive IP packets of the EF class are entered in the high priority queue and forwarded with preemption, as specified in RFC 2598. When the IP packets in the AF class enter in the IP router supporting QoS, the DiffServ engine performs AF specific forwarding treatment. Each AF class (e.g. AF1x, AF2x, AF3x, and AF4x) allocates different forwarding resources, which are typically priority buffer size and bandwidth. Once the IP router experiences traffic congestion, it is determined whether or not IP packets with AF class will be dropped in accordance with the drop precedence values that represents "x." When the network congestion occurs, IP packets in the EF class are always protected, so as to maintain the low-jitter, low-loss and low-latency parameters that are defined in the SLA. When the SLA defines the QoS traffic control requirements, network administration should configure every IP router under the DiffServ Domain where a single QoS framework is managed. In case of multiple DiffServ Domains, DSCP values can be modified at the Ingress node where the IP packets arrive across network service area.

INTSERV AND DIFFSERV

There are two main approaches to adding QoS support in an IP network: Integrated Services (IntServ) and Differentiated Services (DiffServ). IntServ provides fine-grained service guarantees to individual traffic flows. It requires a module in every hop IP router along the path that reserves resources for each session. However, IntServ is not widely deployed since its requirements of setting states in all routers along a path are not easily implemented or scalable. Whereas DiffServ only provides a framework offering coarsegrained controls to aggregates of traffic flows. DiffServ attempts to address the scaling issues associated with IntServ by requiring state awareness only at the edge of DiffServ domains. At the edge, packets are classified into flows, and the flows are conditioned (marked, policed and possibly shaped) to a Traffic Conditioning Specification. In this way, simple and effective QoS can be built from the components during early deployments, and network-wide QoS can evolve into a more sophisticated structure.

WANs and IntServ

As the 802.11e draft now stands, the QoS improvements can be implemented through software or firmware enhancements of the MAC in all 802.11 systems. Manufacturers producing 802.11a/b/g systems will be able to add these enhancements into their devices, and improve multimedia services without additional hardware or infrastructure costs. But the QoS is only guaranteed in the LAN, not across a series of unrelated networks. This leads us to the activities of the Integrated Services over Specific Link Layers (ISSLL) Working Group at the Internet Engineering Task Force (IETF). This Working Group is designing a method that can provide IntServ (see Text Box) QoS over specific link technologies by using DiffServ network segments. This solution maintains the IntServ signaling, delay-based admission, and the IntServ service definitions. The edge of the network consists of pure IntServ regions. However, the core of the network is a DiffServ region, and all flows are mapped into one of the few DiffServ classes at the boundary. Furthermore, in order to support both kinds of IP QoS approaches in WLAN links, different kinds of QoS enhancement schemes for both infrastructure and ad-hoc modes have been proposed.

---