# Communicating DSCP markers to other network equipment to prioritize traffic

DSCP (DiffServ type of service field) markers in the traffic are a standard way to indicate priorities in network traffic. You and your ISP might have routers that decide how to handle packets based on the priority of the traffic.

It is possible to read or write DSCP markers for a particular type of traffic without configuring Access rules to apply a QoS Class to the traffic. The matching is done based on the QoS Policy. When a packet that matches a particular protocol comes in, the Security Engine reads the DSCP markers and assigns a QoS Class according to the DSCP Match/Mark rules of the QoS Policy. When the packet is sent out, the Security Engine writes a DSCP mark in the packets. The marking is based on the QoS Class according to the DSCP Match/Mark rules of the QoS Policy on the interface through which the traffic leaves the Security Engine.
Important:

- If a value is specified in the DSCP Match cell, the engine considers all incoming traffic matching the DSCP Match cell to belong to the QoS Class that is mentioned in the QoS Class cell.
- If a value is specified in the DSCP Mark cell, the engine marks all traffic matching the defined QoS Class with the value specified in the DSCP Mark cell.

The markers allow you to:

- Communicate the priority of this traffic to other devices that support QoS.
- Convert the packet to use a different classification scheme, if the QoS Class was originally assigned to matching traffic by a DSCP match in the source interface’s QoS Policy.
- Remove the DSCP classification set by other devices by entering 0 as the value (shown in the policy as 0x00).

Two QoS Policies on two Physical Interfaces can be used together to translate between two different DSCP schemes as shown in the illustration.

Figure: Translating between two DSCP schemes

In the illustration, the packets arrive at Physical Interface 1. The engine reads the existing DSCP value and compares it to the QoS Policy assigned to Physical Interface 1. The policy has a DSCP Match rule for the DSCP marker with an associated QoS Class, which is then assigned to this traffic.

Note: The same traffic must not match any engine Access rule with a QoS Class definition. The QoS Class in the Access rule overrides the QoS Class that is assigned based on the DSCP marker.

When the packets are sent out through Physical Interface 2, the Engine checks the QoS Policy assigned to this Physical Interface. In this QoS Policy, a DSCP Match/Mark rule defines that traffic with the assigned QoS Class is marked with a DSCP marker specified in the rule. The engine overwrites the original DSCP marker before sending the packets onwards.

- By default, the DSCP mark for the encrypted ESP packet in VPN traffic is inherited from the plaintext packet. Selecting a QoS Policy in the properties of the policy-based VPN makes it possible to mark the ESP packet after encryption.
- Priorities, limits, and guarantees are applied. DSCP codes are written to outgoing packets on the interface that the traffic uses to exit the Security Engine according to the QoS Policy and interface speed defined for that interface.
- For packets entering the Security Engine, the QoS Policy on that interface is only used for reading DSCP codes and matching them to QoS Classes for further use. It is the only QoS operation that is done on the interface that the traffic uses to enter the Security Engine.

  Example: A new packet enters a Engine through interface A and leaves the Engine through interface B. The priorities, guarantees, and limits configured on interface A are ignored for packets in this direction. Any priorities, guarantees, and limits are configured and applied on interface B. If the packet contains a DSCP code when entering the Engine, the DSCP code is read and matched to a QoS Class on interface A. If a new DSCP code is (over)written in the packet, the new code is written on interface B.