« Previous 1 2 3 4 Next »
DiffServ service classes for network QoS
Service Quality
Differentiation of Services
Differentiation of services is based on the various service classes available on the network to provide the necessary performance for applications while allowing several applications with similar traffic characteristics and performance requirements to be grouped together in the same service class (Figure 2). The IETF chose to divide services into two groups: network control traffic and user traffic.
To enable differentiation of services, different service classes are defined in each group: two for the Network Control traffic group for routing and network control functions and OAM for network operations, administration, and management functions.
The user traffic group has the following services:
- The Telephony service class is suitable for applications that rely on delay changes being very low and provide constant transmission speeds.
- The Signaling service class is best suited for peer-to-peer and client-server signaling functions that use protocols such as Session Initiation Protocol (SIP), H.323, H.248, and the Media Gateway Control Protocol (MGCP).
- The Multimedia Conferencing service class supports applications that require very low delay and can change the encoding rate (rate-adaptive), such as H.323/V2 and newer video conferencing services.
- The Real-Time Interactive service class is intended for interactive non-elastic applications with variable data rates that require low jitter and loss and very low delay.
- The Multimedia Streaming service class is used for elastic streaming applications with a variable rate, wherein a human is waiting for data output and in which the application is able to react to packet loss by reducing the transmission rate.
- The Broadcast Video service class is suitable for non-elastic streaming applications that have constant or variable data rates and also require low jitter and packet loss rate (e.g., video surveillance).
- The Low-Latency Data service class is suitable for applications in which a human interacts with a PC.
- The High-Throughput Data service class is intended for store-and-forward applications (e.g., FTP).
- The Standard service class is intended for normal (non-priority) traffic and is referred to as the best-effort class.
- The Low-Priority Data service class is intended for traffic with no need for bandwidth assurance.
User Service Class Categories
The 10 user service classes can be grouped into a small number of application categories. However, for some application categories, it was necessary to define more than one service class to allow for differentiation of services within each category.
The Application Control category is intended for controlling applications or user endpoints. Protocols that use this service class are the SIP or H.248 for IP telephony services or the Internet Group Management Protocol (IGMP) for multicast control. The main difference is the administrative control and management of the affected data streams, because the protocols of this class tend to be bound to the media stream they signal and control.
Because of the large number of media-oriented services on IP networks, five service classes in the Media-Oriented category are defined: Telephony, Real-Time Interactive, Multimedia Conferencing (for video conferencing solutions that are able to reduce their transmission rates after detecting a traffic bottleneck), Broadcast Video, and Multimedia Streaming. The latter content is usually stored before transmission and buffered at the receiving end before being played back. The buffer is sufficiently large to take into account any transmission variation that may occur in the network.
The Data category comprises Low-Latency Data for applications and services that require low delay or latency for bursty but short-lived data flows, High-Throughput Data for applications and services characterized by good throughput for long-lasting burst-like data streams, and Low-Priority Data for applications or services that tolerate short or long interruptions in packet flow.
All undifferentiated traffic on the network falls under the best-effort umbrella and is classified in the Standard service class. If a packet is marked with a DSCP value that is not supported on the network, it should be forwarded by the Standard service class.
Table 2 shows the traffic behavior for the different traffic flows. The Characteristics column defines the desired characteristics and profiles of the respective traffic flows, as well as their tolerance in the areas of packet loss, delay, and jitter. The performance parameters are based on ITU-T Recommendations Y.1541 and Y.1540 [1]. The DSCP Mapping column provides a summary of the DiffServ QoS mechanisms to be used for the defined service classes.
Table 2
Traffic Behavior and QoS Mechanisms
Characteristics | DSCP Mapping | |||||||||
---|---|---|---|---|---|---|---|---|---|---|
Tolerance | ||||||||||
Service Class | Traffic | Package Loss | Delay | Jitter (a) | DSCP | Condition on DS edge (b) | PHB Used | Queuing | AQM | |
Network Control | Packets of variable size, mostly inelastic short messages, but traffic can also contain bursts. | Low | Low | Low | CS6 | Guaranteed services | RFC 2474 | Rate | Yes | |
Telephony | Short packets of fixed size, constant data rate, inelastic and low-performance traffic streams. | Extremely low | Extremely low | Extremely low | EF | Policy based on sr+bs | RFC 3246 | Priority | No | |
Signaling | Packets of variable size, some of which are short-term, burst-like data streams. | Low | Low | Low | CS5 | Policy based on sr+bs | RFC 2474 | Rate | No | |
Multimedia Conferencing | Packets of variable size, constant transmission interval, rate-adaptive, react critically to losses | Low to medium | Low | Extremely low | AF41, AF42, AF43 | Use of bivalent, three-color markers (RFC 2698) | RFC 2597 | Rate | via DHCP | |
Real-Time Interactive | RTP/UDP streams, inelastic, mostly variable data rate. | Low | Extremely low | Low | CS4 | Policy based on sr+bs | RFC 2474 | Rate | No | |
Multimedia Streaming | Packets with variable size, elastic with variable data rate. | Low to medium | Medium | Yes | AF31, AF32, AF33 | Use of bivalent, three-color markers (RFC 2698) | RFC 2597 | Rate | via DHCP | |
Broadcast Video | Constant and variable data rates, non-elastic and non-burst data streams. | Extremely low | Low | Low | CS3 | Policy based on sr+bs | RFC 2474 | Rate | No | |
Low-Latency Data | Variable data rate, burst-like, short-lived, elastic data streams. | Low | Low to medium | Yes | AF21, AF22, AF23 | Use of monovalent, three-color markers (RFC 2697) | RFC 2597 | Rate | via DHCP | |
OAM | Variable size packets, elastic and inelastic data streams. | Low | Low | Yes | CS2 | Policy based on sr+bs | RFC 2474 | Rate | Yes | |
High-Throughput Data | Variable data rate, burst-like, long-lasting, elastic data streams. | Low | Low to medium | Yes | AF11, AF12, AF13 | Use of bivalent, three-color markers (RFC 2698) | RFC 2597 | Rate | via DHCP | |
Standard | Contains all traffic characteristics in varying proportions. | Unspecified | DF | Not applicable | RFC 2474 | Rate | Yes | |||
Low-Priority Data | Elastic non-real-time currents. | High | High | Yes | CS1 | Not applicable | RFC 3662 | Rate | Yes | |
(a) "Yes" in the Jitter column means that the data is buffered at the endpoint and that a moderate network-induced variation in delay will not affect the application. | ||||||||||
(b) sr+bs provides a control mechanism that offers a uniform data rate with control of the burst sizes. |
Service Classes in Practice
Now that the theoretical foundations for the use of the service classes has been presented and the theory behind the 12 DiffServ service classes that provide QoS on the network for demanding modern applications has been discussed, the next step is to use these classes to control the data streams on the network and to ensure optimal quality for video and voice over IP. In the next sections, I look into practical implementations on the network for telephony, video communication, and controlling data streams.
The integration of QoS mechanisms usually starts with three or four service classes on most networks; more classes are then added later as needed. I will look at this integration with reference to two examples.
In the first case, an administrator wants to provide different performance levels (i.e., QoS) for the services to be transmitted, including reliable transport for VoIP services (comparable to the public telephone network), data services with low latency and guaranteed bandwidth, and support for current Internet services.
The admin fulfills these requirements by providing the following six service classes:
- The Network Control service class is responsible for routing and controlling traffic and ensures the reliable operation of the provider's network.
- The Standard service class is responsible for all data traffic (e.g., Internet services) and guarantees undifferentiated forwarding of data over the provider's network.
- The Telephony service class ensures the smooth transmission of VoIP traffic.
- The Signaling service class controls the VoIP service.
- The Low-Latency Data service classes guarantee a bandwidth-differentiated data service.
- The OAM service class ensures operation and management of the provider's network.
In a second example, a network administrator has to provide different features on the network. The requirements are:
- Reliable VoIP services
- Video conferencing services for selected conference rooms
- On-demand delivery of pre-recorded audio and video information to a large number of users
- Provision of a priority data transmission function
- Reduction of available bandwidth during peak hours for selected applications
- Availability of a normal IP service for all other applications and services
Admins meet these network requirements with the help of nine service classes: the six service classes used in the first example plus the Multimedia Conferencing service class for video conferences, the Multimedia Streaming service class for pre-recorded audio and video information, and the High-Throughput Data service class for mass data transport.
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)
Buy ADMIN Magazine
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Most Popular
Support Our Work
ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.