From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

OECG – Chapter 14

807 Words. Plan about 5 minute(s) to read this.

And so we begin the discussion of QoS. This chapter focuses on how we can mark packets for Quality of Service configuration: the fields that can be marked, the IOS QoS CLI, and tools that can be used to classify and mark packets. This post will focus on the fields that we can mark as related to QoS. Remember that the whole idea behind Quality of Service is to provide network devices a way to make sure really important traffic makes it where it needs to go in a timely fashion and/or prevents other traffic from hogging the pipe. The first step in providing a particular service quality is to mark packets such that the router knows how to treat it. So that’s why we’re starting here…we need to know how to mark packets first. Once they are marked, we can decide what to do with them.

IP, 802.1q & ISL, frame relay and ATM headers all have fields that can be used for QoS marking. IP is the perhaps the most interesting, and will receive the most attention.

IP Precedence and DSCP

  • RFC 791 defines the IP header, including a 1 byte field known as “Type of Service” or ToS. The ToS byte is broken up further, the 3 high-order bits known as the IP Precedence (IPP) field.
    • Precedence 0 (binary 000) – routine
    • Precedence 1 (binary 001) – priority
    • Precedence 2 (binary 010) – immediate
    • Precedence 3 (binary 011) – flash
    • Precedence 4 (binary 100) – flash override
    • Precedence 5 (binary 101) – critic/critical
    • Precedence 6 (binary 110) – internetwork control
    • Precedence 7 (binary 111) – network control
  • The remaining ToS bits were little used, 3-6 for various flags and bit 7 not defined. In practice, the ToS byte is a carrier for the IPP bits.
  • After ToS, a new series of RFCs defined Differentiated Services (DiffServ). DiffServ required more than 3 bits to mark traffic. The ToS byte was redefined to do this, but in such a way as to be backward compatible with the ToS standard. The ToS byte was called the Differentiated Services field. The 3-bit IPP field was replaced wiht a 6-bit Differentiated Services Code Point (DSCP) field. The remaining 2 bits are used for the QoS Explicit Congestion Notification (ECN) feature. Groups of DiffServ codes and recommended treatments of those codes are known collectively as “Per-Hop Behaviors” or PHBs.
    • The Class Selector PHB was written for backwards compatibility with IPP. The PHB says that packets with lower CS values should be given less preference than packets with higher CS values.
      • Default/CS0 (binary 000000) = routine
      • CS1 (binary 001000) = priority
      • CS2 (binary 010000) = immediate
      • CS3 (binary 011000) = flash
      • CS4 (binary 100000) = flash override
      • CS5 (binary 101000) = critic/critical
      • CS6 (binary 110000) = internetwork control
      • CS7 (binary 111000) = network control
    • The Assured Forwarding PHB defines 4 classes of queuing, and 3 levels of drop probability inside each queue. Therefore, there are 12 DSCP values that correspond to each possibility. The values are named AFxy, where x is the queue (1-3), and y is the drop class (1-3)
      • AF11 = DSCP 10 = binary 001010 = queue 1, low drop probability
      • AF21 = DSCP 18 = binary 010010 = queue 2, low drop probability
      • AF31 = DSCP 26 = binary 011010 = queue 3, low drop probability
      • AF41 = DSCP 34 = binary 100010 = queue 4, low drop probability
      • AF12 = DSCP 12 = binary 001100 = queue 1, medium drop probability
      • AF22 = DSCP 20 = binary 010100 = queue 2, medium drop probability
      • AF32 = DSCP 28 = binary 011100 = queue 3, medium drop probability
      • AF42 = DSCP 36 = binary 100100 = queue 4, medium drop probability
      • AF13 = DSCP 14 = binary 001110 = queue 1, high drop probability
      • AF23 = DSCP 22 = binary 010110 = queue 2, high drop probability
      • AF33 = DSCP 30 = binary 011110 = queue 3, high drop probability
      • AF43 = DSCP 38 = binary 100110 = queue 4, high drop probability
    • The Expedited Forwarding PHB states that EF packets should be queued in a low-latency fashion. EF packets should not eat the pipe or starve other queues. There is only DSCP value here.
      • EF = DSCP 46 = binary 101110.
  • There are other, non IP fields that can be used for marking. They are somewhat less important in the overall scheme of QoS, because these markings will be lost whenever the layer 2 header is replaced.
    • Ethernet supports a 3-bit QoS field, but this is only used when a frame includes an 802.1q or ISL trunk header. The 3 most significant bytes from the 2-byte dot1q tag control and 3 least significant bytes from the ISL 1-byte user field are both referred to by most people as “Class of Service” or CoS.
    • Frame Relay and ATM support a single bit that can bit flipped on for the purposes of making the frame or cell more likely to be dropped. In FR, this is the “Discard Eligible” bit; in ATM, it’s the Cell Loss Priority bit.
    • MPLS has a 3-bit experimental field (EXP) used for QoS. Often, MPLS routers will map IPP or DSCP values into this field for QoS through the MPLS cloud.
    • There are logical rules governing how these non-IP fields can be marked or used for classification.
      • For classification – inbound to an interface only, assuming the interface supports that header field.
      • For marking – outbound from an interface only, assuming the interface supports that header field.