QoS Implementation During Packet Forwarding

As shown in Figure 5-1, the QoS implementation during packet forwarding is as follows:

Figure 5-1 QoS implementation during packet forwarding

• On the upstream PFE:
  1. The upstream PFE initializes the internal priority of packets (service class as BE and color as green).
  2. The upstream PFE implements BA traffic classification based on the inbound interface configuration. BA traffic classification requires the upstream PFE to obtain the priority field value (802.1p, DSCP or MPLS EXP) for traffic classification and modify the internal priority of packets (service class and color).
  3. The upstream PFE implements MF traffic classification based on the inbound interface configuration. MF traffic classification modifies the upstream PFE to obtain multiple field information for traffic classification. After that, the upstream PFE implements related behaviors (such as filter, re-mark, or redirect). If the behavior is re-mark, the upstream PFE modifies the internal priority of packets (service class and color).
  4. The upstream PFE searches the routing table for an outbound interface of a packet based on its destination IP address.
  5. The upstream PFE implements CAR for packets based on the inbound interface configuration or MF traffic classification profile. 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 upstream PFE modifies the internal priority of packets (service class and color).
  6. Then, packets are sent to the upstream TM.
• On the upstream TM:
  1. The upstream TM processes flow queues based on the inbound interface configuration or MF traffic classification configuration. If both interface-based user-queue and MF traffic classification-based user-queue are configured, MF traffic classification-based user-queue takes effect. Packets are put into different flow queues based on the service class, and WRED drop policy is implemented for flow queues based on the color if needed.
  2. The upstream TM processes VOQs. VOQs are classified based on the destination board. The information about the destination board is obtained based on the outbound interface of packets. Then, packets are put into different VOQs based on the service class.
  3. After being scheduled in VOQs, packets are sent to the switched network and then forwarded to the destination board on which the outbound interface is located.
  4. Then, packets are sent to the downstream TM.
• On the downstream TM
  1. (This step is skipped when the downstream PIC is equipped with an eTM subcard) The downstream TM processes flow queues based on the user-queue configuration on the outbound interface. Packets are put into different flow queues based on the service class, and WRED drop policy is implemented for flow queues based on the color if needed.
  2. (This step is skipped when the downstream PIC is equipped with an eTM subcard) The downstream TM processes port queues (CQs). Packets are put into different CQs based on the service class, and WRED drop policy is implemented for CQs based on the color if WRED is configured.
  3. Then, packets are sent to the downstream PFE.
• On the downstream PFE:
  1. The downstream PFE implements MF traffic classification based on the outbound interface configuration. MF traffic classification requires the downstream PFE to obtain multiple field information for traffic classification. Behaviors, such as filter and re-mark, are performed based on traffic classification results. If the behavior is re-mark, the downstream PFE modifies the internal priority of packets (service class and color).
  2. 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 modifies the internal priority of packets (service class and color).
  3. The priorities of outgoing packets are set for newly added packet headers and are modified for existing packet headers, based on the service class and color.
  4. Then, packets are sent to the downstream PIC.
     • When the PIC is not equipped with an eTM subcard, the PIC adds the link-layer CRC to the packets before sending them to the physical link.
     • When the PIC is equipped with an eTM subcard, the PIC adds the link-layer CRC to the packets and performs a round of flow queue scheduling before sending the packets to the physical link. Downstream flow queues are processed based on the user-queue configuration on the outbound interface. Packets are put into different FQs based on the service class, and WRED drop policy is implemented for FQs based on the color if WRED is configured. When the PIC is equipped with an eTM subcard, downstream packets are not scheduled on the downstream TM.

Packet Field Changes During Packet Forwarding

After CAR and traffic shaping are performed for packets, the bandwidth calculation is closely related to the packet length. Therefore, the packet field changes during packet forwarding require attention.

For example, packet field changes in some common scenarios are described in the following part.

Figure 5-2 Incoming packet in sub-interface accessing L3VPN networking

NOTE:

• CAR calculates the bandwidth of packets based on the entire packet. For example, CAR counts the length of the frame header and CRC field but not the preamble, inter frame gap, or SFD of an Ethernet frame in the bandwidth. The following figure illustrates a complete Ethernet frame (bytes).

  
  
  

  The bandwidth covers the CRC field but not the IFG field.

• The upstream PFE adds a Frame Header, which is removed by the downstream PFE. The Frame header is used to transfer information between chips. NPtoTM and TMtoNP fields are used to transfer information between the NP and TM.
• When the PIC is not equipped with an eTM subcard, the length of a packet scheduled on the downstream TM is different from that of the packet sent to the link. To perform traffic shaping accurately, you must run the network-header-length command to compensate the packet with a specific length.

On the downstream interface on the network side:

• when the downstream TM implements traffic shaping for packets, the TNtoNP and Frame Header field values of the packets are not calculated. Therefore, the packet scheduled on the downstream TM does not contain the IFG, L2 Header (14 bytes), two MPLS Labels, or CRC fields, compared with the packet sent to the link. A +26-byte compensation (including the L2 header, two MPLS labels, and CRC field, but not including the IFG field) or a +46-byte compensation (including the IFG field) can be performed for the packet.
• When the PIC is equipped with an eTM subcard, no packet length compensation is required.

Figure 5-3 Outgoing packet in sub-interface accessing L3VPN networking

NOTE:

On the downstream interface on the user side:

when the downstream TM implements traffic shaping for packets, the TNtoNP and Frame Header field values of the packets are not calculated. Therefore, the packet scheduled on the downstream TM does not contain the IFG, L2 Header (14 bytes), VLAN tag, or CRC fields, compared with the packet sent to the link. A +22-byte compensation (including the L2 header, VLAN tag, and CRC field, but not including the IFG field) or a +42-byte compensation (including the IFG field) can be performed for the packet.

For more details, see Incoming packet in sub-interface accessing L3VPN networking.

Figure 5-4 Incoming packet in sub-interface accessing VPLS networking

NOTE:

On the downstream interface on the network side:

• when the downstream TM implements traffic shaping for packets, the TNtoNP and Frame Header field values of the packets are not calculated. Therefore, the packet scheduled on the downstream TM does not contain the IFG, L2 Header (14 bytes), two MPLS Labels, or CRC fields, compared with the packet sent to the link. A +26-byte compensation (including the L2 header, two MPLS labels, and CRC field, but not including the IFG field) or a +46-byte compensation (including the IFG field) can be performed for the packet.

For more details, see Incoming packet in sub-interface accessing L3VPN networking.

Figure 5-5 Outgoing packet in sub-interface accessing VPLS networking

NOTE:

On the downstream interface on the network side:

when the downstream TM implements traffic shaping for packets, the TNtoNP and Frame Header field values of the packets are not calculated. Therefore, the packet scheduled on the downstream TM does not contain the IFG, VLAN tag, or CRC fields, compared with the packet sent to the link. A +8-byte compensation (including the VLAN tag (4 bytes) and CRC (4 bytes) field, but not including the IFG field) or a +28-byte compensation (including the IFG field) can be performed for the packet.

For more details, see Incoming packet in sub-interface accessing L3VPN networking.

Figure 5-6 Packet in Layer 2 Ethernet forwarding scenarios

NOTE:

In Layer Ethernet forwarding scenarios, a data frame can be a VLAN-tagged, QinQ-tagged, or untagged frame. Use a VLAN-tagged frame as an example. In Layer 2 forwarding, both the Layer 2 Ethernet frame header and the VLAN tag of a packet are forwarded to the downstream TM, and only the CRC field is removed. when the downstream TM implements traffic shaping for packets, the TNtoNP and Frame Header field values of the packets are not calculated. Therefore, the packet scheduled on the downstream TM does not contain the CRC field, compared with the packet sent to the link. A +4-byte compensation (not including the IFG field) or a +24-byte compensation (including the IFG field) can be performed for the packet.

For more details, see Incoming packet in sub-interface accessing L3VPN networking.

Figure 5-7 IP-to-802.1Q packet conversion on the outbound interface in IP forwarding scenarios

NOTE:

On the downstream interface on the user side:

when the downstream TM implements traffic shaping for packets, the TNtoNP and Frame Header field values of the packets are not calculated. Therefore, the packet scheduled on the downstream TM does not contain the IFG, L2 Header, VLAN tag, or CRC fields, compared with the packet sent to the link. A +22-byte compensation (including the L2 header, VLAN tag, and CRC field, but not including the IFG field) or a +42-byte compensation (including the IFG field) can be performed for the packet.

For more details, see Incoming packet in sub-interface accessing L3VPN networking.

Figure 5-8 IP-to-QinQ packet conversion on the outbound interface in IP forwarding scenarios

NOTE:

On the downstream interface on the user side:

when the downstream TM implements traffic shaping for packets, the TNtoNP and Frame Header field values of the packets are not calculated. Therefore, the packet scheduled on the downstream TM does not contain the IFG, L2 Header, two VLAN tags, or CRC fields, compared with the packet sent to the link. A +26-byte compensation (including the L2 header, two VLAN tags, and CRC field, but not including the IFG field) or a +46-byte compensation (including the IFG field) can be performed for the packet.

For more details, see Incoming packet in sub-interface accessing L3VPN networking.

Figure 5-9 Outgoing IP packet on the POS interface in IP forwarding scenarios

NOTE:

On the downstream interface:

• when the downstream TM implements traffic shaping for packets, the TNtoNP and Frame Header field values of the packets are not calculated. Therefore, the packet scheduled on the downstream TM does not contain the PPP header, compared with the packet sent to the link. A +8-byte compensation can be performed for the packet.
• When the PIC is equipped with an eTM subcard, no packet length compensation is required.

Figure 5-10 Outgoing L3VPN packet on the user side of the PE in QinQ interface accessing L3VPN networking

NOTE:

On the downstream interface on the user side:

when the downstream TM implements traffic shaping for packets, the TNtoNP and Frame Header field values of the packets are not calculated. Therefore, the packet scheduled on the downstream TM does not contain the IFG, L2 Header (14 bytes), two VLAN tags, or CRC fields, compared with the packet sent to the link. A +26-byte compensation (including the L2 header, two VLAN tags, and CRC field, but not including the IFG field) or a +46-byte compensation (including the IFG field) can be performed for the packet.

For the , the packet scheduled on the downstream TM does not contain a Frame Header. Therefore, a +26-byte compensation (not including the 20-byte IFG field) or a +46-byte compensation (including the IFG field) can be performed for the packet.

Figure 5-11 Outgoing L3VPN packet on the user side of the PE in POS interface accessing L3VPN networking

NOTE:

On the downstream interface on the user side:

• when the downstream TM implements traffic shaping for packets, the TNtoNP and Frame Header field values of the packets are not calculated. Therefore, the packet scheduled on the downstream TM does not contain the PPP header (8 bytes), compared with the packet sent to the link. A +8-byte compensation can be performed for the packet.
• When the PIC is equipped with an eTM subcard, no packet length compensation is required.

Figure 5-12 Outgoing packet in VLAN mapping scenarios

NOTE:

In VLAN mapping scenarios, both the Layer 2 Ethernet frame header and the VLAN tag of a packet are forwarded to the downstream TM, and only the CRC field is removed. The VLAN tag value is replaced with a new VLAN tag value.

when the downstream TM implements traffic shaping for packets, the TNtoNP and Frame Header field values of the packets are not calculated. Therefore, the packet scheduled on the downstream TM does not contain the CRC field, compared with the packet sent to the link. A +4-byte compensation (not including the IFG field) or a +24-byte compensation (including the IFG field) can be performed for the packet.

For more details, see Incoming packet in sub-interface accessing L3VPN networking.

Figure 5-13 Outgoing packet in POS interface accessing VLL heterogeneous interworking scenarios

NOTE:

In VLL heterogeneous interworking scenarios, both the L2 header and MPLS label of a packets are removed on the upstream TM.

• when the downstream TM implements traffic shaping for packets, the TNtoNP and Frame Header field values of the packets are not calculated. Therefore, the packet scheduled on the downstream TM does not contain the PPP header, compared with the packet sent to the link. A +8-byte compensation can be performed for the packet.
• When the PIC is equipped with an eTM subcard, no packet length compensation is required.

Figure 5-14 Outgoing packet in POS interface accessing VLL homogeneous interworking scenarios

NOTE:

In VLL heterogeneous interworking scenarios, both the L2 header and MPLS label of a packets are removed on the upstream TM.

when the downstream TM implements traffic shaping for packets, the TNtoNP and Frame Header field values of the packets are not calculated. Therefore, the packet scheduled on the downstream TM does not contain the PPP header, compared with the packet sent to the link. A +8-byte compensation can be performed for the packet.

Supplement to Packet Length Compensation

The network-header-length command used to configure packet length compensation is configured in the service template. Certain service templates have been predefined on NE20Es. Using these service templates, you do not need to calculate the length required in a compensation

To manually configure the compensation length, you can run the display interface command to view statistics on the outbound interface and calculate the length of the packet sent to the link (L1), and run the display port-queue command to view statistics about the queues and calculate the length of the packet scheduled on the downstream TM (L2). The compensation length is obtained in this formula: Length compensation = L1 - L2. For example:

<HUAWEI> display interface gigabitethernet 0/1/0
……
Statistics last cleared:2017-06-08 11:25:55                                     
    Last 300 seconds input rate: 13848728 bits/sec, 10856 packets/sec           
    Last 300 seconds output rate: 13183454 bits/sec, 9111 packets/sec           
    Input peak rate 14347000 bits/sec, Record time: 2017-06-08 11:27:31         
    Output peak rate 13271131 bits/sec, Record time: 2017-06-08 11:30:05        
    Input: 1304984264 bytes, 9341140 packets                                    
    Output: 1256201849 bytes, 7740964 packets
……
<HUAWEI> display port-queue statistics interface gigabitethernet 0/1/0 outbound
GigabitEthernet0/1/0 outbound traffic statistics:                                                                
[be]                                                        
Current usage percentage of queue: 0   
   Total pass:                                                                  
                             411,963 packets,                335,927,398 bytes
…… 
[af1]                        
 Current usage percentage of queue: 0                          
   Total pass:                                                                  
                             172,616 packets,                141,875,765 bytes
…… 
[af2]                   
 Current usage percentage of queue: 0                       
   Total pass:                                                                  
                              54,516 packets,                 45,592,293 bytes
…… 
[af3]                  
 Current usage percentage of queue: 0                           
   Total pass:                                                                  
                              53,650 packets,                 44,916,566 bytes
…… 
[af4]                    
 Current usage percentage of queue: 0                           
   Total pass:                                                                  
                              53,650 packets,                 44,915,912 bytes
…… 
[ef]                
 Current usage percentage of queue: 0                    
 Total pass:                
                              54,516 packets,                 45,598,519 bytes
…… 
[cs6]
 Current usage percentage of queue: 0
 Total pass:                    
                               63,288 packets,                 47,061,713 bytes
…… 
[cs7]                 
 Current usage percentage of queue: 0                         
 Total pass:                    
                             6,895,327 packets,                551,385,377 bytes
……

In the preceding information, L1 = 1256201849 bytes/7740964 packets= 162bytes/packet.

L2= sum of forwarded bytes in eight queues/sum of forwarded packets in eight queues = 1257273543bytes/7759526packet=162bytes/packet.

Therefore, the compensation value can be calculated using the formula of compensation value = L1–L2 = 0.