Introducing to QoS


QoS is a generic term that defines the level or measure of service that is provided for a particular application or network service. For example, consider the various passenger classes on an international air flight. Typically, first class, business class, and economy class exist. The first-class passengers get the highest degree of service (e.g., better food, bigger seats, personalized service) because these passengers pay extra for that service. Similarly, business-class passengers get a higher degree of service than economy-class passengers, but do not enjoy some of the service that first-class passengers enjoy. The business-class passenger pays more than an economy class passenger, but less than a first-class passenger. Taking this example a step further, those passengers on standby might be equated to a best-effort service.

The same concepts apply to data networks. Specific applications and services might be more important for an organization than others. These applications require a higher quality of service (QoS). Referring back to the airline example, certain characteristics of the whole flying experience define the level of service you receive. For example, these characteristics could include quality of food, leg room, in-flight entertainment, and baggage clearance priority. Each passenger class receives a varying level of service for each characteristic, with the overall quality of service being defined by the sum of these service levels.

On data networks, the characteristics of the network that define quality of service are described in Table 9-1.

Table 9-1. Characteristics of the Network that Define Quality of Service

Characteristic

Description

Bandwidth

The amount of data transferred over a certain time frame defines the bandwidth used by the application.

Latency

The amount of time required for a piece of information to travel from source to destination.

Jitter

This term applies to the variation in latency. Certain applications can compensate for latency, but require that the latency be consistent.

Packet loss

Packet loss can occur when congestion occurs in the network. It is possible to assign a preference to certain applications, reducing the likelihood that they can experience packet loss.


Now that you understand a little about QoS, it is time to examine how network devices actually implement and apply QoS. The following topics are now discussed:

  • QoS models

  • DiffServ model

  • QoS functions

QoS Models

Three models define how quality of service can be implemented in modern networks today:

  • Best effort This model provides no quality of service. All traffic received is sent on a best-effort basis (normally first come, first served).

  • Integrated Services (IntServ) In this model, applications need to signal their QoS requirements to the network before sending data. Network devices receive signaling messages from the application and allocate the requested network resources.

  • Differentiated Services (DiffServ) In this model, each packet in the network contains a marking that indicates the required QoS. Each network device applies QoS based upon this marking.

Cisco LAN switches implement the DiffServ model, where they inspect or mark QoS information contained within each frame or packet and apply QoS based upon these values.

DiffServ Model

The DiffServ model requires applications to indicate QoS requirements in every data packet that is sent. This means that applications do not need to explicitly signal QoS requirements to the network before sending data (which is required in the IntServ model). Figure 9-1 demonstrates the DiffServ approach.

Figure 9-1. The DiffServ Model


In Figure 9-1, the following steps occur:

Step 1.

The sender immediately sends session data, with each packet of the session being marked with QoS information in the header of each packet. Router X receives this packet, reads the QoS marking in the header, and applies the appropriate behavior based upon the QoS marking.

Step 2.

Router Y receives the packet from Router X, reads the QoS marking in the header, and behaves according to the QoS marking. Router Y then forwards the packet to its final destination.

The DiffServ model signals QoS requirements by using the following markers in each packet or frame transmitted:

  • Type of service (applies to IP traffic)

  • Class of service (applies to Layer 2 traffic)

  • Differentiated Services Code Point (DSCP)Applies to IP traffic

Type of Service (ToS)

The most common form of QoS marking present in IP networks today is the use of the type of service (ToS) field. Interpreted by routers, the ToS field is a part of the IP header and allows for a QoS marking to be applied on a per-packet basis. Figure 9-2 illustrates the ToS field.

Figure 9-2. The Type of Service Field


Figure 9-2 shows two subfields that exist within the ToS field. The ToS subfield is not used, with the Precedence subfield being the only portion of the ToS field actually used today. The IP Precedence value is simply a 3-bit binary value, which in decimal terms represents a value of 0 through 7. The value indicates the relative priority of the packet, with 0 representing the lowest priority and 7 representing the highest priority. Each priority level is also assigned a name; for example, an IP Precedence value of 6 represents Internetwork Control traffic.

Class of Service (CoS)

Class of service (CoS) refers to the marking of Layer 2 frames to indicate the quality of service requirements of the frame. CoS is required for Layer 2 devices to apply QoS within a Layer 2 network. If we consider Ethernet as the Layer 2 technology, none of the various Ethernet frame types include a CoS field. A CoS field is created on tagged traffic, where the tag is primarily used to identify the VLAN that the tagged frame belongs to. Two major tagging techniques (trunking protocols) are supported by Cisco switches todayIEEE 802.1Q and ISL.

Figure 9-3 illustrates the tag format used for 802.1Q tags.

Figure 9-3. 802.1Q Tag Format


Notice that the tag is contained within the actual Ethernet frame and that a 3-bit 802.1p priority field exists that provides up to 8 CoS values.

Differentiated Services Code Point (DSCP)

The IP Precedence marking mechanism provides up to eight different indications of QofS. Eight levels of QoS is not sufficient for many large networks, causing scalability issues. Recently, the IETF has developed a new standard (see RFC 2474) that defines a Differentiated Services Field (DS Field) that obsoletes the old ToS and Precedence fields, and uses the first six high-order bits (up to 64 levels of QoS) for QoS marking. The value defined in the DS Field is known as the Differentiated Services Code Point (DSCP), and is designed to be backward compatible with older routers that only understand IP precedence. Figure 9-4 illustrates the DiffServ field.

Figure 9-4. The DiffServ Field


In the Diffserv model, each device that can provide QoS is able to provide a per-hop behavior (PHB) for different classes of traffic. The PHB is simply the way in which the queueing and scheduling mechanisms on a forwarding device are implemented for a particular class of traffic. Diffserv-compliant networks support the following PHBs:

  • Default PHB Defined in RFC 2474, this defines that traditional best-effort service (first-in, first-out) should be applied. RFC 2474 states that a DSCP value of 0 should be used to indicate that the default PHB be applied to a packet.

  • Class-Selector PHB Defined in RFC 2474, this is used to preserve backward compatibility with IP precedence, by setting the three low-order bits to 000 (DSCP values are in the format xxx000, where xxx is equivalent to IP precedence). With this PHB, forwarding devices must apply queueing and scheduling in same fashion as IP precedence is applied. For example, a packet with a DSCP value of 111000 (equivalent IP precedence of 7), is provided preferential treatment over a packet with a DSCP value of 101000 (equivalent IP precedence of 5).

  • Assured Forwarding PHB Defined in RFC 2597, this defines four classes of traffic called AF1, AF2, AF3 and AF4, each of which can be assigned a different level of QoS. For example, a forwarding device might allocate 10%, 20%, 30% and 40% of a links bandwidth to the AF1, AF2, AF3 and AF4 classes respectively. Within each class, three sub-classes exist (AFx1, AFx2 and AFx3), with each sub-class defining a relative drop precedence, which is used to determine which packets should be dropped first if a queue is full. For example, in the AF3 class, traffic assigned to the AF33 sub-class will be discarded before traffic in the AF32 sub-class, which in turn will be discarded before traffic in the AF31 sub-class. Table 9-2 describes each of the AF classes and subclasses and also indicates the DSCP value used to identify each subclass.

Table 9-2. IP Precedence and DSCP Backward Compatibility

Drop Precedence

Class 1 (AF1)

Class 2 (AF2)

Class 3 (AF3)

Class 4 (AF4)

Low Drop Precedence

AF11

DSCP = 10

AF21

DSCP = 18

AF31

DSCP = 26

AF41

DSCP = 34

Medium Drop Precedence

AF12

DSCP = 12

AF22

DSCP = 20

AF32

DSCP = 28

AF42

DSCP = 36

High Drop Precedence

AF13

DSCP = 14

AF23

DSCP = 22

AF33

DSCP = 30

AF43

DSCP = 38


In Table 9-2, each class of traffic is allocated a specific amount of bandwidth; for example, class 1 might be allocated 10% of the available bandwidth, whilst class 4 might be allocated 50% of the available bandwidth. Within each class, if the queue that services the class becomes full, packets are discarded according to their drop precedence. For example, packets with a DSCP value of 10, 12 or 14 are assigned to class 1. If the queue that these packets are placed into is full, packets in the class with a high drop precedence (for example, AF13 or DSCP 14) are discarded first, before packets with a medium and low drop precedence.

  • Expedited Forwarding PHB This PHB is designed for applications that required guaranteed bandwidth, low latency, and low jitter, such as voice and video. To provide this service, a forwarding device will typically place packets into a priority queue that is serviced before any other queues. RFC 2598 defines a DSCP value of 46 to indicate the expedited forwarding PHB is required.

QoS Functions

In previous sections, you have learned about the various QoS models. In the next few sections, you learn how each network device (in this case a LAN switch) implements QoS using the DiffServ model. Figure 9-5 summarizes the steps that occur when data is received by a LAN switch and how the appropriate QoS policy is determined and applied for that data.

Figure 9-5. QoS Process in a Catalyst Switch


As Figure 9-5 shows, certain functions are performed on the ingress port (the port that receives the packet), while other functions are performed at the egress port (the port the sends the packet towards its destination). These functions are discussed in Table 9-3.

Table 9-3. Ingress and Egress Port Functions

Function

Description

Classification and marking

Classification allows the switch to determine the QoS that should be assigned to a received frame, while marking sets the CoS, ToS, or DiffServ bits in the frame or packet.

Policing

Policing on a LAN switch refers to the switch monitoring the bandwidth used by traffic and ensuring a specific bandwidth threshold is not exceeded. If the threshold is exceeded, the switch polices the traffic in excess, either dropping it or marking it with a lower QoS marking (e.g., DSCP) value.

Queuing

Queuing is applied to traffic at the egress switch port. Queuing allows for the preferential treatment (in terms of transmission priority or loss characteristics) of certain traffic classes.

Scheduling

The process of scheduling determines how each queue is serviced. The scheduling process takes a frame from a queue and transmits the frame onto the wire.





CCNP Self-Study CCNP Practical Studies. Switching
CCNP(R) Practical Studies: Switching (CCNP Self-Study)
ISBN: 1587200600
EAN: 2147483647
Year: 2002
Pages: 135
Authors: Justin Menga

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net