Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Quality of Service: Rewrite and Marking for QoS

SUMMARY CN2 release 23.4 supports Quality of Service (QoS) marking and rewrite capabilities for MPLS encapsulation types (MPLSoUDP, MPLSoGRE) for IPv4 and IPV6.

QoS for Primary Use Cases in CN2 Deployments

In CN2 deployments, pod-to-pod traffic originates at a pod associated with a Cloud-native Network Function (CNF), traverses the fabric, and terminates at a different network or pod associated with an egress device, such as a vRouter or SDN gateway. A vRouter receives an ingress packet and prepares it for differential treatment on a downstream device. The vRouter does not impement any differentiated scheduling. Instead, CN2 implements the marking and rewriting of packets for network devices downstream to perform qeuing and scheduling of differentiated traffic.

QoS for CN2 addresses two primary use cases:

Use Case 1: Packet Consumed by a Pod at Tunnel Endpoint

This use case occurs when a packet, originating from a pod associated with a CNF, reaches an ingress vRouter. The vRouter references QoS settings in the VMI or VN configuration associated with the vRouter, with the VN configuration taking priority. If QoS settings exist, the vRouter performs a rewrite function on the incoming QoS bits. This rewrite function ensures that incoming QoS values are rewritten into equivalent QoS values designated in the configuration, and marks these values in the packet's inner header.

The vRouter then prepares the packet's outer header for downstream tunneling. In a process called propagation, the vRouter references the QoS values in the packet's inner header and translates these values into the packet's outer header. This process is necessary because tunnel interfaces only reference a packet's outer header during QoS realization. For example, incoming DSCP values might be translated into MPLS values in the packet's outer header, depending on the configuration specifications.

The packet then undergoes encapsulation, either through MPLSoUDP or MPLSoGRE, for tunneling. A pod connected to the tunnel endpoint/vRouter consumes the packet. When the packet is consumed by a pod connected to the egress vRouter or SDN gateway, QoS realization (differential service), determined by QoS values in the outer header, takes place at the downstream device.

Note that in this use case, since the packet traverses an MPLS tunnel and is consumed at the tunnel endpoint, the packet's inner header is ignored.

Use Case 2: Packet Forwarded by SDN Gateway

This use case is similar to the first use case above. However in this case, the device at the tunnel endpoint does not consume the packet. Instead, it routes the packet to an SDN gateway, which further forwards it to another network. In this use case, the ingress vRouter also rewrites (overwrites) the QoS values in the packet's inner header according to the VMI or VN QoS configuration and propagates these values to the outer header for tunneling. The packet is subsequently encapsulated and the egress device forwards it to a device in another network through the SDN gateway. The SDN gateway decapsulates the packet's outer header, accesses the inner header, and forwards the packet downstream with the modified QoS values.

Given these two primary use cases, rewrite is best understood as the process of overwriting incoming QoS values into equivalent QoS values designated in the QoS configuration. Propagation is best understood as the process of ensuring a packet's QoS values are either translated or replicated for downstream devices to perform consistent QoS realization. In the case of CN2, propagation occurs in a packet's outer header for MPLS tunnel interfaces.

Rewrite and Marking

As previously mentioned, the mechanisms to handle QoS bits are known as rewrite (one specific implementation called marking), and propagation (one specific implementation called translation). This section provides information about rewrite and a form of rewrite called marking.

It is possible for an incoming packet to not contain any QoS value. In other words, a default value of DSCP zero (0) exists in the packet. Packets with a QoS DSCP value of 0 typically receive best-effort treatment. If a configuration specifies a value to map to a value of 0, this overwrite operation is known as marking. In other words, marking occurs when a DSCP value of 0 exists. When this happens, CN2 overwrites the 0 ingress QoS DSCP value in a packet's inner header and creates a QoS value in the outer header, based on the config. Additionally, a QoS value within range [1-63] may also need to be changed as per the config, which is known as rewrite.

Packet rewrite policies include:

  • From DSCP to DSCP (only applicable for IP when the downstream network could also be standard IP, wanting a DSCP value)

  • From EXP to EXP (only applicable for MPLS packets)

Propagation and Translation

Since downstream tunneling interfaces only access a packet's outer header, the packet's QoS values located in the inner header are either translated or copied to the outer header so that consistent QoS realization is maintained during tunneling. Propagation works with next-hop to write QoS bits in a packet's outer header for QoS realization of downstream devices during tunneling. QoS values are propagated either through the copying of existing values or translation.

A DSCP value is not meaningful for a device that only understands EXP values. To address this, the configuration designates equivalent DSCP and EXP values, enabling understanding across both value types. Note that although values are equivalent, they belong to different types. For example, a configuration might specify a DSCP value and it's equivalent QoS value, but although these values are technically equivalent, they are of different bit types. In the context of propagation, translation implies converting QoS values from the inner header to alternative types situated in the outer header. For instance, at a downstream device, DSCP values might undergo translation into EXP values, or vice versa, ensuring consistent QoS downstream.

Packet propagation policies are specified in the config and are attached to tunnels and interfaces. The policies for propagation include:

  • From DSCP to EXP (only applicable for IP)

  • From EXP to DSCP (only applicable for MPLS packets)

Packet Treatment Based on Traffic Patterns

Since packets in CN2 deployments travel through MPLSoUDP or MPLSoGRE tunnels, the majority of traffic is IP to IP.

Given this traffic pattern, traffic policies must be configured and implemented at the following levels:

  1. VN level (all ingress interfaces associated with that VN)

  2. Virtual machine interface (VMI)

CN2 supports packet rewrite/marking and propagation to manage and implement packet policies, QoS settings, and protocols as a packet travels from source to destination address.

Configure QoS

Configure Global and Namespace QoS settings, and associate the configuration with a VN or VMI. Apply the configuration using a series of YAML files, applied in a specific order. Apply the following YAML files in the order specified below. Note that these files are example configurations.

  1. GlobalQoSConfig
  2. ForwardingClass
  3. QoS-Map Index
  4. Attach the QoS Config to a VN
  5. Attach the QoS Config to a VMI

GlobalQoSConfig

This file creates a global QoS object that enables the creation of a hierarchical setup for subsequent config objects.

ForwardingClass

This file shows an example of two forwarding classes (fc-1, fc-2). Specific DSCP and MPLS EXP values are associated with these classes. These values dictate QoS impementation and determine how the traffic associated with these classes is handled.

QoS-Map Index

The following file shows a QoS-map index defined within a Namespace. Overwriting the QoS bits in a packet's inner header or translating QoS bits to the outer header requires the establishment of a QoS-map index. The QoS-map index specifies the mapping from the incoming QoS value to another value required by downstream devices. This mapping is defined in the forwarding class. The configuration for specifying how QoS bits are rewritten is referred to as the QoS-Map index.

In other words, the QoS-Map index and forwarding class defines the transformation of QoS values during packet traversal. Note the dscpEntries and mplsExpEntries fields. The nested key and forwardingClassId fields let you associate DSCP and MPLS EXP values with specific forwarding classes. Differential treatment of traffic within this Namespace is implemented based on these settings.

Attach the QoS Config to a VN

The file creates an example VN object (zone-1). Note the qosConfigReference field. This VN and all interfaces within this VN are associated with the QoS config specified in test-qos-config.

Atach the QoS Config to a VMI

This file creates a VMI object within the example Namespace (contrail). Note the qosConfigReference field. This VMI (virtualmachineinterface-create-test) referenced the QoS config from test-qos-translation.

Verify the QoS Config

Use the following commands to verify that the QoS config and it's associated objects are created:

  • qosmap --dump-fc: Display configured FCs (Forwarding Classes) and their mapped DSCP values. For example, in the Namespace QoS Config, the DSCP value of 24 is mapped to the FC 100.

  • qosmap --dump-qos: Display configured QoS values and their mapped Forwarding Classes. For example, in the Namespace QoS Config, the EXP value of 6 is mapped to the FC 100.

QoS Traffic Behavior

Incoming QoS packets are handled as follows: the last two QoS bits of the associated incoming packet are ignored. For example, when translated to binary, the hexadecimal value of 0x60 reads 0110 0000. The last two bits are ignored, leaving 011000, which translates to decimal 24. Decimal 24 is then mapped to a DSCP value that determines QoS realization. This mapping process occurs across downstream devices in the network.