QoS Basic & Processing

Packet forwarding on a router involves many quality of service (QoS) concepts, such as behavior aggregate (BA) classification, multi-field (MF) classification, CAR, queue, and buffer. This chapter provides QoS basics and Processing to help you better understand QoS on a router.

Why Do We Need QoS?

When a new product is launched, users and manufacturers are typically less concerned about quality issues. After competitor products go on sale, users start to compare the qualities of the products. This scenario applies to products including the IP network. Traditionally, the best effort (BE) model is used on an IP network so that the network makes its best attempt to send packets but without any guarantee for performance.

With continuous technology improvement and fierce product competition, users have higher requirements on network quality. To meet these demands, multiple IP QoS service models are introduced, among which integrated service (IntServ) and differentiated service (DiffServ) models are typically implemented.

Integrated Service Model

Integrated service model requires users to apply for specific levels of service from the network before sending packets. After receiving these requests, the network reserves sufficient resources for these requests. Integrated service model works like a shuttle bus, with seats reserved for every ticketed passenger, and drives off even if the seats are not fully occupied.

In addition, the vehicle company has to maintain great amount of booking information:

Due to these defects, the integrated service model has not been used on IP networks since 1990s. Currently the differentiated service model is widely used on IP networks.

Differentiated Service Model

The differentiated service model classifies network traffic into multiple classes for differentiated processing. To be specific, the differentiated service model implements traffic classification first and then allocates different identifiers to different classes of packets. After a network node receives these packets, it simply identifies these identifiers and processes packets based on the actions corresponding to these identifiers. The differentiated service model and train ticket service system is similar. A train ticket marks the service that you book: soft sleeper, hard sleeper, hard seat, or no seat. You get on a train and enjoy the specific service marked on your ticket. On an IP network, the relationship between an identifier and a packet is analogous to the relationship between a train ticket and a passenger.

DSCP and PHB

Differentiated services code point (DSCP) and per-hop behavior (PHB) are important concepts of the DiffServ model.

DSCP

As stated before, the identifier in a packet header is like a train ticket. Similarly, packets have various packet headers, for example, frame headers at Layer 2, MPLS headers at Layer 2.5, and IP headers at Layer 3. The 802.1p, EXP, and DSCP fields (identifiers) are used in frame, MPLS, and IP headers, respectively.

A packet may travel over multiple networks, such as an Ethernet, MPLS network, and IP network, and the forwarding behaviors vary according to networks. For example, on an Ethernet, a network node parses only the Ethernet header of a packet but ignores its MPLS or IP header. This is why each layer has its own identifier.

In addition to identifiers such as the 802.1p, EXP, and DSCP fields, there is another identifier called type of service (ToS), which is also a field in IP headers. Initially RFC 791 defines no DSCP value but an 8-bit ToS value and uses 3 bits from these 8 bits to indicate the Precedence. There are eight types of precedence then.

RFC 1349 redefines the ToS field and renames one of the reserved 2 bits as the C field. The D, T, R, and C fields constitute the ToS field. Due to these differences, the RFC version needs to be stated when speaking of ToS. Huawei routers comply with RFC 1349.

Subsequently, RFC 2474 redefines the 8 bits and renames the specific 6 bits as the DSCP field.

PHB

As its name suggests, per-hop behavior (PHB) refers to the behavior performed by packets on each hop. However, this does not mean that PHB is a specific action, such as traffic scheduling, packet dropping, traffic policing, traffic shaping, and re-marking. In fact, PHB only defines a forwarding behavior that is visible to users without any specific actions. In other words, PHB identifies the classes of behaviors similar to the star-rating of hotels, such as 3-star, 4-star, and 5-star. RFCs define four types of PHBs: CS, EF, AF, and BE, each of which corresponds to a DSCP value. PHB classifies packets as CS, EF, AF, and BE based on the service characteristics to which users are most sensitive, such as the delay, jitter, and packet loss rate.

·         The best effort (BE) PHB focuses only on whether packets can reach the destination, regardless of the transmission performance. Traditional IP packets can be transmitted in BE mode. The BE PHB is used on IP networks by default and all routers must support the BE PHB.

·         The assured forwarding (AF) PHB applies to services that require short delay, low packet loss rate, and high reliability, such as video, voice, and enterprise VPN services.

·         The expedited forwarding (EF) PHB applies to real-time services that require short delay, low jitter, and low packet loss rate, such as video, voice, and videoconferencing.

·         The class selector (CS) PHB indicates the same service class as the IP precedence value. RFC 2474 reserves all values of the XXX000 format to allow DiffServ-incapable devices that only parse the three leftmost bits in the ToS field to be compatible with other devices.

Typically an AF or CS PHB carries a suffix, such as AF11, AF22, CS6, and CS7, while a BE or EF PHB carries no suffix. This is because a BE or EF PHB corresponds to only one DSCP value and a CS or AF PHB corresponds to multiple DSCP values. Currently, four AF classes with three levels of drop precedence in each AF class are defined for general use. AF is expressed in the format of AF1x to AF4x, with x indicating the drop precedence and ranging from 1 to 3.

For example, assume that four community networks are connected to the same edge router on an ISP network. If a community sends a large number of FTP packets, traffic congestion may occur, affecting the FTP transmission of other communities. To address this issue, set the maximum FTP traffic rate to 500 Mbit/s for each community. After that, re-mark the DSCP field of packets on each inbound interface to compensate for the scenario where the traffic rate of one community exceeds 1 Gbit/s. Specifically, traffic transmitted at a rate of 500 Mbit/s or lower is marked AF11, traffic transmitted at a rate of 500 Mbit/s to 1 Gbit/s is marked AF12, and traffic transmitted at a rate higher than 1 Gbit/s is marked AF13. When traffic congestion occurs, the AF13 traffic is dropped first. If traffic congestion persists after the AF13 traffic is dropped, the AF12 traffic is dropped. If traffic congestion is still detected after that, the AF11 traffic has to be dropped at last. In this manner, all communities are fairly treated.

PHB = Service Quality?

PHB reflects the service class of packets but not the service quality. In other words, CS is higher than BE in service class, which does not mean that the service quality of CS traffic is higher than that of BE traffic. PHB is only a hop-by-hop behavior, whereas service quality is an end-to-end service guarantee. Service quality is typically measured based on the following specifications:

·         Bandwidth/throughput

·         Delay

·         Delay variation (jitter)

·         Packet loss rate

·         Availability

In addition to PHB, many other factors affect service quality, such as link bandwidth, device processing capability, network stability, and transmission distance.

PHB = Queue?

There are BE, AF1, AF2, AF3, AF4, EF, CS6, and CS7 queues on Huawei routers.

This does not mean that PHB is equal to all queues. To be specific, the name of a queue does not reflect the priority of the queue in service class. Similarly, if all hard seats in a hard seat coach are replaced with hard sleepers, this coach is actually a hard sleeper coach although it is still named a hard seat coach.

Queues can be treated in a similar fashion. For example, if strict priority (SP) scheduling is implemented for a BE queue (rarely happens) and weighted fair queuing (WFQ) scheduling is implemented for the other seven queues, the BE queue has the highest priority among all other queues in service class. In this case, the PHB of the BE queue is no longer BE. (The SP and WFQ concepts will be provided in the Queue Mechanism.) Although the name of a queue does not represent its PHB, a queue is still named similarly to PHB as it can vividly show a queue's priority. If the queues were named queue 1 to queue 8 instead, it would be hard figure out what these queues are.

How Are Packets Placed in Queues Based on DSCP Values?

Both the 802.1p and EXP fields are 3 bits long, which correspond to exactly eight values and can have one-to-one mappings with eight PHBs or queues. What about DSCP values? How do DSCP values map eight PHBs or queues as a DSCP field corresponds to 64 values? Behavior aggregate (BA) classification is used to resolve this problem.

BA Classification (Mapping and Reverse Mapping)

Traffic classification consists of behavior aggregate (BA) classification and multi-field (MF) classification. BA classification enables a device to simply identify the traffic that has the specific priority or service class for mapping between external and internal priorities.

For example, BA classification enables a device to classify packets based on the DSCP values of IP packets, EXP values of MPLS packets, or 802.1p values of VLAN frames. MF classification has a more complex classification rule and enables a device to classify packets in a finely granular way based on fields other than priority identifiers, such as 5-tuple, MAC address, protocol number, label, or TTL information.

As stated before, in the DiffServ model, packets are classified and marked, and PHBs are implemented for classified packets. Regardless of whether BA or MF classification is implemented, packets are classified based on packet headers' fields, which are obtained by parsing packet headers. It is impossible for a device to parse packet headers every time a QoS operation is implemented, such as placing packets in queues, dropping packets, and sending packets out of queues.

To resolve this problem, designers use two internal markers: service class and color, which are also called scheduling precedence and drop precedence, respectively. When a device parses a packet header, the device sets these two internal markers for the packet based on the packet header priority. In this manner, the device only needs to read these two markers before implementing any QoS operation. To be specific, a device implements a QoS operation based on the service class and color of packets.

The default PHB on an IP network is BE. Therefore, the initial values of the two internal markers are BE and Green. If the trust upstream command is run on an inbound interface, the interface maps the external priorities (802.1p, EXP, and DSCP) of packets to the internal priorities (service class and color). This process is called mapping.

If re-marking or re-marking after CAR is configured on a device, the device re-marks the service class and color of packets, regardless of whether the inbound or outbound interface receives the packets. After that, the device implements QoS operations for packets based on the service class and color. After QoS operations are complete, the downstream board (outbound interface) maps the internal priorities of packets to the external priorities.

This process is called reverse mapping. Reverse mapping is an optional configuration and is unnecessary if the external priorities of packets must remain unchanged.

MF Classification (Traffic Policy)

Multi-field (MF) classification enables a device to classify packets based on complex rules, such as 5-tuple. After traffic classification is complete, various behaviors must be implemented for classified packets (traffic classifiers). Therefore, a traffic policy is used to associate traffic behaviors with traffic classifiers. A traffic policy is configured in a profile which supports batch modification and reduces configuration workloads.

A traffic policy profile covers the following concepts:

·         Traffic classifier: defines if-match clauses to match packets.

·         Traffic behavior: defines actions for specific traffic classifiers, such as re-marking, redirecting, balancing, fragmenting, rate limiting, and traffic statistics collecting.

·         Traffic policy: associates traffic classifiers with traffic behaviors. The traffic policy takes effect after being applied to an inbound or outbound interface.

Congestion Management (Queuing)

In addition to its traffic classification and marking features, DiffServ has a queuing mechanism. When network congestion occurs on a device, the device buffers packets in queues and sends the packets from those queues when network congestion is relieved. While queues in everyday life are an inconvenience, the queuing mechanism in DiffServ is highly efficient, with each interface on a Huawei router possessing eight queues, a situation comparable to having eight registration windows at a hospital.

Scheduling Algorithms

First In First Out (FIFO) allows packets that come earlier to enter the queue first. However, a router interface can process only one of the eight queues at a time. The scheduling algorithm determines which queue the interface will preferentially process.

Strict Priority (SP) schedules packets based on queue priorities. Packets in low-priority queues can be scheduled only after all packets in high-priority queues have been scheduled. To prevent low-priority queues from being neglected, rate limiting is generally implemented for high-priority queues.

Round Robin (RR) schedules multiple queues in ring mode. If the queue on which RR is performed is not empty, the scheduler sends one packet out of the queue. If the queue is empty, it is simply skipped. Because of this, a lot of time may elapse before high-priority queues can be scheduled. To address this, designers introduced Weighted Fair Queuing (WFQ). For example, let us say there are three non-VIP queues with the weight rate being 5:3:1. The scheduler will send five packets out of the queue with a weight value of 5 at a time, three with a weight value of 3, and one with a weight value of 1.

Numerous scheduling algorithms not described in this document have been formulated for the queuing mechanism. This is why the queuing mechanism is more efficient than the process of registering at a hospital.

Congestion Avoidance (Drop Policy)

In everyday life, doctors do not see any more patients after the number of registered patients reaches a maximum threshold, say, for example, 200 registrations, or outside of normal working hours that extend from 7 a.m. to 11 a.m. and from 2 p.m. to 4 p.m.. Similarly on a router, when traffic congestion intensifies and queues that buffer packets are almost full, a router will use a drop policy to counteract the effects of congestion.

Currently two drop policies exist: tail drop and Weighted Random Early Detection (WRED). Tail drop is the traditional congestion avoidance mechanism used to drop all newly arriving packets when congestion occurs. With tail drop mechanisms, all newly arriving packets are dropped when congestion occurs, causing all Transmission Control Protocol (TCP) sessions to simultaneously enter the slow start state and packet transmission to slow down. Then all TCP sessions restart their transmission at roughly the same time and when congestion occurs again, another burst of packet drops is triggered, whereupon all TCP sessions enter the slow start state once more. This cycle repeats itself again and again. This phenomenon is called TCP global synchronization. In short, tail drop is not the optimum solution for either TCP or User Datagram Protocol (UDP).

To better serve TCP and UDP, WRED is used. WRED sets two lines for each queue, as shown in the following figure.

When the length of a queue is lower than the threshold marked by the yellow line, no packets are dropped. When the length of a queue exceeds the threshold marked by the yellow line, newly arriving packets are randomly dropped at a rate increasing with the queue length. When the length of a queue exceeds the threshold marked by the red line, all newly arriving packets are dropped.

Tail drop applies to SP queues for services that have high real-time performance demands. Tail drop drops packets only when the queue overflows and therefore it provides the highest bandwidth for real-time services when traffic congestion occurs. WRED is generally applied to WFQ queues. WFQ queues share bandwidth based on weight and are prone to traffic congestion. Using WRED for WFQ queues effectively resolves TCP global synchronization when traffic congestion occurs.

Some users, however may still feel hard done by. For example, let us say Jerry and Tom are surfing the net. Jerry sends packets at a rate of 2 Mbit/s, and Tom sends packets at a rate of 200 Mbit/s. If traffic congestion occurs, Jerry thinks that Tom's packets should have been dropped first as Tom sends more packets and thus contributing more to traffic congestion. To resolve this, designers introduced drop precedence. The Internet Engineering Task Force (IETF) defines three types of drop precedence: red, yellow, and green, indicating the order in which packets buffered in queues are dropped during traffic congestion. In the case of Jerry and Tom surfing the net at rates of 2 Mbit/s and 200 Mbit/s respectively, you can set an upper limit of 100 Mbit/s. If Tom sends packets at a rate lower than 100 Mbit/s, Tom's packets will be colored green and thus will not be dropped. If Jerry sends packets at a rate higher than 100 Mbit/s, Jerry's excess packets will be colored red and will therefore be dropped preferentially.

Rate Limiting (CAR and Traffic Shaping)

Rate limiting is one of the most important QoS mechanisms. Rate limiting restricts the rate at which packets are sent to or from a router.

Both CAR and traffic shaping are used to limit traffic rate.

CAR

First of all, CAR is used to control the rate of traffic as it enters the network.

·         No speeding, green card, uninterrupted running (forwarded).

·         Slight speeding, yellow card, degraded (forwarded after being re-marked).

·         Severe speeding, red card, prohibited from passing (dropped).

So, cars go on the green light, wait on the yellow light, and stop on the red light.

CAR kind of sounds like CUT, which indicates that we cut off packets that do not conform to our specifications.

How do we judge which packets are speeding? The answer is, using a token bucket.

Token Bucket

What is a token bucket? As the name implies, a token bucket is a container used to store tokens.

How does a token bucket measure the traffic rate though? There are three different token bucket mechanisms:

·         Single rate single bucket

·         Single rate two buckets

·         Two rates two buckets

With single rate single bucket, tokens are put into the token bucket at the Committed Information Rate (CIR) rate.

With token bucket mechanisms, packets can only be forwarded when they have been allocated enough tokens, like a car being given a pass card when passing through a tollgate.

As an analogy, think of an unmanned tollgate that uses a card machine to collect the toll. A bucket, called bucket C, is placed under the card machine, and the card machine drops cards into bucket C at a fixed rate. In this analogy, these cards represent tokens, and drivers each take a card on their way through the tollgate.

To maintain a 100-meter distance between cars, the card machine provides pass cards at 3.6-second intervals.

If an average of more than one car arrives at the tollgate every 3.6 seconds, the pass cards in bucket C are quickly exhausted, triggering a red light. As a result, subsequent cars are denied access to the highway. This is how the rate limit is implemented.

If an average of less than one car arrives at the tollgate every 3.6 seconds, cards will accumulate in bucket C.

If pass cards accumulate, a very long car (possibly hundreds of meters long) will be able to pass through the tollgate.

As a rule, one pass card is required for every 100 meters of car length because at most one car is permitted every 100 meters. Thus, a very long car, hundreds of meters long, is equal to several shorter-length cars.

Suppose that a 600-meter car arrives at the tollgate. If only five pass cards are left in bucket C, the car cannot pass until the sixth card is dropped into bucket C.

So, what is the maximum length of a car that is allowed to pass through the tollgate? It depends on the number of tokens that bucket C can store. The capacity of bucket C is called the Committed Burst Size (CBS).

What if the card machine keeps providing pass cards but no cars arrive? Are the cards wasted when the bucket overflows? Yes! That is a shortcoming of the single rate single bucket mechanism. To prevent cards from being wasted, single rate two buckets was developed.

Now, with single rate two buckets, suppose that two buckets, C and E, are used to store pass cards. The card machine first drops pass cards into bucket C. When bucket C becomes full, the overflowing cards fall into bucket E.

As a rule, cards from bucket C are preferentially provided for drivers. That is, cards from bucket E are only distributed once the cards in bucket C are insufficient for a car to pass through. In this case, a driver must return the insufficient number of cards to bucket C first before picking up the required number of cards from bucket E. A driver is not permitted to pick up cards from both buckets.  

·         If the number of cards in bucket C is sufficient, the green light is on, the car is allowed to pass, and no points are deducted from the driver’s credit.  

·         If the number of cards in bucket E are sufficient, but the number of cards in bucket C are not, the yellow light is on, and one point is deducted from the driver’s credit.

·         If neither bucket C nor E have enough cards, the red light is on, and 12 points are deducted from the driver’s credit. In addition, the car is not allowed to pass, and the driver must return all cards.

When a car arrives, the driver picks up pass cards from bucket C first. If the number of cards in bucket C is insufficient for a car to pass, the driver returns the cards to bucket C and picks up the required number of cards from bucket E. Remember: One card is required for every 100 meters of car length.

Is the capacity of bucket E the same as the capacity of bucket C? Not necessarily. The capacity of bucket E is called the Extended Burst Size (EBS), and can be set to a different number than the CBS.

In fact, the capacity of bucket E cannot be too large. If the capacity of bucket E is too large, an overly long car may be allowed to pass, increasing the risk of pileup accidents.

The CBS cannot be too large, either. Otherwise, we have the same problem. An overly long car may be allowed to pass, again increasing the risk of pileup accidents. In terms of network packets and tokens, if the CBS is set very large, packets will not encounter a “pileup accident”. However, if the CBS is set too large, rate limit will not take effect. For example, let’s say the traffic rate is required to be lower than 100 bit/s. If the CBS is set to 3600 MB and several packets arrive within one hour and consume all those tokens, the traffic rate within the hour reaches up to 1 Mbit/s (8000000 bit/s), far exceeding the intended 100 bit/s.

The CBS cannot be set too small, either, though. For example, let’s say the traffic rate is again required to be lower than 100 bit/s. If the CBS is set to 1000 bytes and several packets longer than 1000 bytes arrive within one hour, no packets will be able to obtain sufficient tokens. As a result, all packets are dropped, and the traffic rate within the hour drops to 0 instead of the intended 100 bit/s.

So, if the CBS cannot be too large or too small, how can we determine the optimal CBS? First, the CBS cannot be smaller than the maximum transmission unit (MTU). Second, the CBS cannot be smaller than the burst traffic volume on the live network. Since the burst traffic volume on the live network is hard to determine, Huawei engineers have developed a formula to help us estimate it.

Formula:

·         If the CIR ≤ 100 Mbit/s, CBS (bytes) = CIR (kbit/s) x 1.5 (s) / 8

·         If the CIR > 100 Mbit/s, CBS (bytes) = 100,000 (kbit/s) x 1.5 (s) / 8

How to set the CIR? The CIR is equal to the bandwidth purchased by subscribers. The Service Level Agreements (SLA) signed between operators and subscribers defines the CIR, along with other parameters like CBS, PIR, and PBS.

NOTE:

The SLA defines the services that the ISP promises to provide subscribers.

what are PIR and PBS? PIR and PBS are used in two rates two buckets.

With two rates two buckets, the card machine drops cards into two buckets, buckets C and P, at the rates of CIR and Peak Information Rate (PIR), respectively. The cards dropped into bucket C are pass cards, and the cards dropped into bucket P are called “souvenir cards”.

As a rule, souvenir cards are provided for drivers preferentially.  

·         If the number of souvenir cards is insufficient for the car to pass, the driver returns them to bucket P. In this case, the red light is on, the car is not allowed to pass, and the driver is fined 1000 dollars.

·         If the number of souvenir cards in bucket P is sufficient, the driver can pick up the necessary pass cards from bucket C. If the number of pass cards in bucket C is sufficient, the green light is on, the car is allowed to pass, and the driver can leave with both the souvenir cards and pass cards.

·         If the pass cards in bucket C are insufficient, the yellow light is on, and one point is deducted from the driver’s credit. The driver must also return the pass cards, but is allowed to keep the souvenir cards.

There is a quick summary of the two mechanisms, two rates two buckets and single rate two buckets:

Item	Two rates two buckets	Single rate single bucket
Bucket order	Bucket P followed by bucket C	Bucket C followed by bucket E
Green light	Pick up tokens from both buckets	Pick up tokens only from bucket C
Yellow light	Pick up tokens only from bucket P	Pick up tokens only from bucket E
Red light	Pick up no tokens	Pick up no tokens

Two rates two buckets tests not only whether a speeding event occurs but also whether that speeding event has broken the law. The rate at which the card machine drops cards into bucket P correlates with the maximum car speed permitted under the law.

Are overly long cars allowed to pass when two rates two buckets is used? Yes. The Peak Burst Size (PBS) functions the same as the EBS. But since bucket P is used, bucket E is unnecessary.

When should we use CAR? CAR is generally implemented at the network ingress, like a tollgate on a highway ingress. Can you imagine what a highway would look like without a tollgate deployed on the ingress? It would look more like a “slowway” or even a “noway”!

There are still so many choices though. When do we use each of the three token bucket mechanisms?

·         To restrict the traffic rate, we use single rate single bucket.

·         To restrict the traffic rate and distinguish burst traffic volumes that don’t conform to our specifications, we use single rate two buckets.  

·         To restrict the traffic rate, distinguish burst traffic volumes that don’t conform to our specifications, and identify whether the bandwidth exceeds our specifications, we use two rates two buckets.

Traffic Shaping

Both CAR and traffic shaping use the token bucket to measure the traffic rate, but differ in terms of packet processing. Traffic shaping is implemented based on the queuing mechanism, so it buffers excess packets in queues and sends them out of queues only when traffic congestion has been relieved. CAR is not implemented based on the queuing mechanism and simply drops excess packets without buffering them.

NOTE:

Traffic classification (BA and MF classification), rate limiting (CAR and traffic shaping), congestion management (queuing), and congestion avoidance (drop policy) constitute the four QoS components. Chapter 5 describes how these components process traffic.

QoS Processing Sequence

The four QoS components, traffic classification (BA and MF classification), rate limiting (CAR and traffic shaping), congestion management (queuing), and congestion avoidance (drop policy), process packets in a specific order.

PICs on some LPUs are equipped with egress Traffic Managers (eTMs), while those on other LPUs are not. The eTM-equipped PIC and non-eTM-equipped PIC differ only in terms of queue scheduling for downstream packets. To be specific, queue scheduling is implemented on the eTM when the PIC is equipped with an eTM and is implemented on the TM when the PIC is not equipped with an eTM.

Figure 6-1  QoS processing when the PIC is not equipped with an eTM

Figure 6-2  QoS processing when the PIC is equipped with an eTM

Traffic classification and marking provide a basis for DiffServ, and traffic policing, traffic shaping, congestion management, and congestion avoidance are implemented to provide DiffServ. As stated in QoS Basics, Huawei routers set two internal markers for each packet: service class and color, which correspond to the scheduling precedence and drop precedence, respectively. QoS operations are performed for packets based on those two internal markers.

The process in detail is as follows:

1. The upstream PFE initializes the internal priority of packets (service class as BE and color as green).

2.    The upstream PFE implements BA classification based on the inbound interface configuration. BA classification requires the upstream PFE to obtain the priority field value (802.1p, DSCP, or MPLS EXP) for traffic classification and reconfigure the internal priority of packets (service class and color).

3. The upstream PFE obtains packets' field information, classifies packets based on the field information, and performs behaviors, such as filter, re-mark, and re-direct, for packets based on the classification results. If the behavior is re-mark, the upstream PFE reconfigures the internal priority of packets (service class and color).
4. The upstream PFE obtains the outbound interface and next hop of the packets.
5. The upstream PFE implements CAR for packets based on the inbound interface configuration or MF classification configuration. If both interface-based CAR and MF classification-based CAR are configured, MF classification-based CAR takes effect. In a CAR operation, a pass, drop, or pass+re-mark behavior can be performed for incoming traffic. If the behavior is pass+re-mark, the upstream PFE reconfigures the internal priority of packets (service class and color).
6. Packets enter queues on the upstream TM for scheduling, and WRED is implemented for packets based on the color if configured.
7. Packets are switched to the downstream TM through the SFU.
8. (This step is skipped if the downstream PIC is equipped with an eTM) Packets enter queues on the downstream TM for scheduling, and WRED is implemented for packets based on the color if configured.
9. Packets enter the downstream PFE, and the downstream PFE obtains the encapsulation information of the packets.
10. The downstream PFE obtains packets' field information, classifies packets based on the field information, and performs behaviors, such as filter, re-mark, and re-direct, for packets based on the classification results. If the behavior is re-mark, the downstream PFE reconfigures the internal priority of packets (service class and color).

11.  The downstream PFE implements CAR for packets based on the outbound interface configuration or MF traffic classification configuration. If both interface-based CAR and MF traffic classification-based CAR are configured, MF traffic classification-based CAR takes effect. In a CAR operation, a pass, drop, or pass+re-mark behavior can be performed for incoming traffic. If the behavior is pass+re-mark, the downstream PFE reconfigures the internal priority of packets (service class and color).

12.  The priorities of outgoing packets are set based on service class and color for newly added packet headers and are modified for existing packet headers.

13.  After processed by the downstream PFE, packets enter the downstream PIC.

• On a PIC not equipped with an eTM, the link layer interframe gap, preamble, start-frame delimiter, and Frame Check Sequence (FCS) are added to the packets so that the packets are forwarded to the physical links.
• On a PIC equipped with an eTM, after the link layer interframe gap, preamble, start-frame delimiter, and FCS are added to the packets, the PIC implements queue scheduling by placing packets in queues on the downstream eTM based on service class and implementing WRED for the packets based on the color if WRED is configured.

FAQs

Q: When Does the Priority Field Value of a Packet Change?

A: As stated before, downstream reverse mapping is implemented for packets based on the service class and color to add a new priority field or modify the existing priority field. Service class and color, however, are prone to change during the QoS process. You can determine whether the priority field value of a packet has been changed as follows:

1. Check whether service class and color have changed during the QoS process.
2. Check whether the mapping and reverse mapping rules are consistent. For example, if DSCP value 12 is mapped to service class AF1 and color yellow in mapping, check whether service class AF1 and color yellow are mapped to DSCP value 12 in reverse mapping.

3.    Check whether reverse mapping is implemented for outgoing packets.

On most boards, if the remark command is run in a traffic policy that is applied to incoming or outgoing packets, the priorities of incoming or outgoing packets are reconfigured based on command configuration. On an LPUF-21/40, however, if the remark command is run in a traffic policy applied to incoming packets, the priorities of incoming packets are not reconfigured, but the priorities of outgoing packets are reconfigured if this command is run in a traffic policy for outgoing packets.

Q: How Do I Check Whether Reverse Mapping Is Implemented for Outgoing Packets?

A: A device sets two markers on each interface to determine whether to implement reverse mapping for outgoing packets.

• Marker 1: BA on the inbound interface. BA is carried in internally added packet headers and transmitted to the outbound interface through the SFU.
• Marker 2: PHB on the outbound interface. Reverse mapping is implemented for packets only when both BA and PHB are enabled (on an LPUF-41/100, reverse mapping is implemented for packets when PHB is enabled, regardless of whether BA is enabled).

By default, BA is disabled, and PHB is enabled in V600R002 or earlier and is disabled in V600R003 or later.

• To enable BA, run the trust upstream, remark, service-class, diffserv-mode pipe, or diffserv-mode short-pipe command. The diffserv-mode pipe and diffserv-mode short-pipe commands apply only to ingress and egress PEs in MPLS scenarios.
• To disable BA, run the service-class class-value color color-value no-remark command on the inbound interface, or delete the preceding four commands stated above.
• To enable PHB, run the trust upstream or qos phb enable command on the outbound interface.
• To disable PHB, run the qos phb disable or undo trust upstream command on the outbound interface.

Q: Which Priority Is Used for Mapping If DSCP, 802.1p, and EXP Values Are Carried in Packets?

A: It depends on the inbound interface configuration.

• If the trust upstream command is not run on the inbound interface, the external priorities of packets are not trusted and mapped to the default internal priority BE and green.
• If both the trust upstream and trust 802.1p commands are run on the inbound interface, priority mapping is implemented for VLAN-tagged packets based on their 802.1p values in the outer VLAN tags, and the external priorities of non-VLAN-tagged packets are mapped to the default internal priority BE and green.
• If only the trust upstream command is run on the inbound interface, priority mapping is implemented based on EXP values for MPLS packets and based on DSCP values for non-MPLS packets. For the other packets, if the device identifies a protocol packet, it maps the external priority of the protocol packet to the internal priority CS6 and green; if the device does not identify a protocol packet, it maps the external priority of the protocol packet to the internal priority BE and green.

Q: Which Priority Is Reconfigured During Reverse Mapping If DSCP, 802.1p, and EXP Values Are Carried in a Packet?

A: It depends on the type of the downlink LPU and the inbound interface configuration.

• If not both BA and PHB are enabled, the priorities of packets are not reconfigured.
• If both BA and PHB are enabled and the trust upstream and trust 802.1p commands are run on the inbound interface, 802.1p and EXP values are reconfigured for MPLS packets, and only 802.1p values are reconfigured for non-MPLS packets.
• If both BA and PHB are enabled but the trust 802.1p command is not run on the inbound interface, the priority reconfiguration varies according to board types.

Q: How Is the Priority Field Set for a Newly Added Packet Header?

A: The settings vary according to board types.

 

Related subjects:

[IP Adventure] A Packet's Adventures on Routers - 02

[IP Adventure] A Packet's Adventures on Routers - 01

[IP Adventure] A Packet's Adventures on Routers - Introduction

Good tutorial with helpful examples

very very nice tutorial

Highly recommended illustration of packets's journey, i loved it indeed. Thanks for sharing.

Good information

QoS basics and process explained here

Good information