Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Layer-3 Class of Service (CoS)

Juniper Cloud-Native Router supports Layer 3 Class of Service (CoS), also known as L3 Quality of Service (QoS). This topic provides an overview of the supports CoS mechanisms followed by configuration and verification examples.

L3 CoS Overview

When a network experiences congestion and delay, some packets must be prioritized to avoid random loss of data. Class of service (CoS), also known as Quality of Service (QoS) accomplishes this prioritization by dividing similar types of traffic, such as e-mail, streaming video, voice, large document file transfer, into classes. You then apply different levels of priority, such as those for throughput and packet loss, to each group, and thereby control traffic behavior. Juniper Cloud-Native Router supports CoS, enabling it to differentiate or classify traffic. It can either drop traffic or lower the priority of the traffic as per the rules configured. You can read more about Class of Service in the Junos documentation.

The Cloud-Native Router CoS application supports DiffServ, which uses a 6-bit differentiated services code point (DSCP) in the differentiated services field of the IPv4 and IPv6 packet header. For IPv6, DSCP is referred to as traffic class. The configuration uses DSCP values to decide the CoS treatment for the incoming packet. The DSCP field is also used to notify the modified priority of a packet to the next hop.

Cloud-Native Router Supported CoS Mechanisms

Cloud-Native Router supports Classifier, Policer and Rewrite/Marker CoS mechanisms. Let us look at the Cloud-Native Router CoS implementations in detail in the sections below.

Forwarding Classes and Loss Priority

The forwarding classes affect the forwarding and marking policies applied to packets as they transit JCNR. By default Cloud-Native Router has no forwarding classes defined. You can define up to 16 custom forwarding classes mapped to 8 queues.

In Cloud-Native Router CoS implementation forwarding class along with the loss priority is used for rewrite rules and policer. Loss priority is set by the classifier as low, medium low, medium high and high. Here are some of the ways loss priority is used in the Cloud-Native Router CoS implementation:

Table 1: Using Forwarding Class and Loss Priority
QoS Block

How Loss priority is used

Classifier

Forwarding class and loss priority are set by the classifier.

Rewrite

Loss priority is used as an index along with the Traffic Class (Forwarding Class) to obtain a new DSCP value.

Policer

Only color aware policer uses loss priority. Loss priority maps to traffic colors as follows:

  • Loss priority Low is mapped to Green
  • Loss priority Medium High and Medium Low are mapped to Yellow
  • Loss priority High is mapped to Red
Scheduler Forwarding class and loss priority are inputs to the scheduler for queuing the traffic based on strict priority.

Classifiers

Packet classification refers to the examination of an incoming packet. This function associates the packet with a particular CoS servicing level. Classifiers associate incoming packets with a forwarding class and loss priority and, based on the associated forwarding class, assign packets to output queues. Two general types of classifiers are supported:

  • Behavior Aggregate Classifier—Behavior aggregate (BA) is a method of classification that operates on a packet as it enters JCNR. The CoS value in the packet header is examined, and this single field determines the CoS settings applied to the packet. BA classifiers allow you to set the forwarding class and loss priority of a packet based on the Differentiated Services code point (DSCP) value and DSCP IPv6 value. BA classifier is configured at the interface level. You can read more about Behavior Aggregate Classifer in the Junos documentation.

  • Multifield Traffic Classifier—A multifield (MF) classifier can examine multiple fields in the packet, such as the source and destination address of the packet as well as the source and destination port numbers. With multifield classifiers, you set the forwarding class and loss priority of a packet based on firewall filter (ACL) rules. If a packet matches both BA and MF classifiers, MF classifier takes precedence. You can read more about the Multified Traffic Classifier in the Junos documentation.

Policers

Policers allow you to limit traffic of a certain class to a specified bandwidth and burst size. Policer meters (measures) each packet against traffic rates and burst sizes configured. It then passes the packet and the metering result to the marker (rewrite rules), which assigns a packet loss priority that corresponds to the metering result. Based on the particular set of traffic limits configured, a policer identifies a traffic flow as belonging to one of either two or three categories that are similar to the colors of a traffic light used to control automobile traffic. Policers can be applied per packet or per traffic class. Cloud-Native Router CoS implementation supports 16 policer profiles. You can read more about Policer Implementation in Junos documentation. In Cloud-Native Router CoS implementation policers work in Single-rate three color marker (srTCM) or Two-rate three-color marker (trTCM) mode. Policers can perform traffic color marking in color aware or color blind modes. In color aware mode, the policer considers the packet’s color as derived by classifier as additional input. In color blind mode the policer does not take into consideration packet’s color while determining the new color. We will look at the different considerations for each of the modes in the tables provided hereafter.

  • Single-rate three-color—A Single Rate Three Color Marker (srTCM) meters traffic based on the configured committed information rate (CIR), committed burst size (CBS), and the peak burst size (PBS). A single-rate three-color policer is most useful when a service is structured according to packet length and not peak arrival rate. Traffic is marked as belonging to one of three categories—green, yellow, or red based on the following considerations:

    Table 2: Color Aware srTCM
    Incoming Color

    Packet Metered Against

    Possible Cases

    New Color

    Action on the packet

    Green

    CIR, CBS, PBS

    Below CBS

    Green

    Not dropped

    Above CBS but below PBS

    Yellow

    Change the traffic class using the rewrite rules.

    Above PBS

    Red

    Discard

    Yellow

    PBS

    Below PBS

    Yellow

    Change the traffic class using the rewrite rules.

    Above PBS

    Red

    Discard
    Red Not metered NA Red Discard
    Table 3: Color Blind srTCM

    Packet Metered Against

    Possible Cases

    New Color

    Action on the packet

    CIR, CBS, PBS

    Below CBS

    Green

    Not dropped

    Above CBS but below PBS

    Yellow

    Change the traffic class using the rewrite rules.

    Above PBS

    Red

    Discard

  • Two-rate three-color—A Two Rate Three Color Marker (trTCM) meters traffic based on the configured CIR and peak information rate (PIR). A two-rate three-color policer is most useful when a service is structured according to arrival rates and not necessarily packet length. Traffic is marked as belonging to one of three categories based on the following considerations:

    Table 4: Color Aware trTCM
    Incoming Color

    Packet Metered Against

    Possible Cases

    New Color

    Action on the packet

    Green

    CIR, PIR

    Below CIR

    Green

    Not dropped

    Above CIR but below PIR

    Yellow

    Change the traffic class using the rewrite rules.

    Above PIR

    Red

    Discard

    Yellow

    PIR

    Below PIR

    Yellow

    Change the traffic class using the rewrite rules.

    Above PIR

    Red

    Discard
    Red Not metered NA Red Discard
    Table 5: Color Blind trTCM

    Packet Metered Against

    Possible Cases

    New Color

    Action on the packet

    CIR, PIR

    Below CIR

    Green

    Not dropped

    Above CIR but below PIR

    Yellow

    Change the traffic class using the rewrite rules.

    Above PIR

    Red

    Discard

The colors marked by Policer are mapped to loss priority as follows:

Table 6: Mapping Colors to Loss Priority

Color

Loss Priority

Green

Low

Yellow

Medium-Low (Medium-High is not used while mapping color to loss priority)

Red

High

Rewrite/Marker

A rewrite rule or marker sets the appropriate CoS bits in the outgoing packet. This allows the next downstream routing device to classify the packet into the appropriate service group. Rewriting, or marking, outbound packets is useful when the routing device is at the border of a network and must alter the CoS values to meet the policies of the targeted peer. A rewrite profile is applied to the interface and is based on the forwarding class and loss priority derived by the classifier and/or the metering results of the policer. Cloud-Native Router rewrite rules supports copying outer IPv4/IPv6 DSCP marking to inner IP header DSCP field as well as MPLS EXP bit marking. Cloud-Native Router supports 16 rewrite profiles. You can read more about Rewrite rules in Junos documentation.

Note:

Cloud-Native Router CoS implementation does not support implicit best effort treatment for traffic that does not match any CoS block. An explicit catch-all rule must be configured for best effort treatment.

Note:

Cloud-Native Router CoS implementation modifies the DSCP value of the outer IP header only for tunneled packets (MPLSoUDP and VXLAN).

Scheduler

Scheduler is the last block in Cloud-Native Router's CoS implementation and computes the priority of the packets. Cloud-Native Router implements a strict priority 8-queue scheduler, with priority order high to low. The forwarding class is directly mapped to scheduler priority. The Cloud-Native Router supports a maximum of 4 scheduler profiles in the deployment helm chart and a maximum of 16 scheduler maps and forwarding classes. You can read more about Scheduler in Junos documentation. You can configure a scheduler with one of 8 priorities as provided in the below table. Note that the scheduler priorities are already mapped to interface queues (8 queues).

Table 7: Scheduler Priorities

Priority

Scheduling Priority (Queue)

high

Scheduling priority 1

low

Scheduling priority 7 (Least)

low-high

Scheduling priority 5

low-latency

Scheduling priority 4

low-medium

Scheduling priority 6

medium-high

Scheduling priority 2

medium-low

Scheduling priority 3

strict-high

Scheduling priority 0 (Highest)

Supported Interfaces

Cloud-Native Router supports the following interfaces for CoS implementation:

Table 8: Support Interfaces for CoS Implementation
CoS Component/Interface Type

Pod Interface

Fabric Interface

IRB Interface

Classifier

Supported

Supported

Supported

Policer

Supported

Supported

Supported

Marker

Supported

Supported

Supported

Scheduler Not Supported Supported Not Supported

L3 CoS Configuration

You must configure a CoS scheduler profile per interface in the helm chart that defines the number of scheduler lcores and bandwidth. Review Helm Chart customization for more details.
You must perform CoS configuration on the Cloud-Native Router control plane using a Configlet. Review Customize Cloud-Native Router Configuration for more details. Sample configlets are provided below:

Configure Forwarding Classes

Cloud-Native Router does not have any forwarding classes configured by default. You can configure upto 16 forwarding classes, mapped to 8 queues. The user-defined queue mapping is ignored since queue numbers are derived from the priority defined in the scheduler configuration, mapped one-on-one with the queue number:

Configure Classifiers

You can configure a BA classifier and apply it on an interface:

You can configure MF classifier as a firewall filter:

Configure Policers

You can configure the policer with the action type three-color-policer as follows:

Single Rate Three Color Meter (srTCM) Policer:

Two Rate Three Color Meter (trTCM) Policer:

You can configure classifiers with policers.

BA classifier with policer:

MF classifier as a firewall filter with policer:

Note: When the same policer is configured for multiple firewall filter terms, multiple policer instances are created, one per term.

Configure Rewrite/Marker

You can configure the rewrite/marker as follows:

MPLS Exp Rewrite for tunnel packets:

Configure Schedulers

You can configure the schedulers to one of 8 priorities. The scheduler map configures the forwarding class to scheduler mapping and is applied at the interface level.

Note: The CoS configuration is valid only if the fabric interface is mapped to a qos-scheduler-profile in the helm chart. The scheduler profile must be configured with CPU and bandwidth allocation. Please see Helm Chart customization for more details.

L3 CoS Verification

CLI commands to verify L3 CoS configuration

Verify Classifier Configuration on cRPD

You can verify the L3 CoS configuration using the following commands on the cRPD shell:

  • Verify the classifier configuration using the show class-of-service classifier command. An example output is provided below:
  • Verify the code-point-alisases configuration using the show class-of-service code-point-aliases command. An example output is provided below:
  • Verify the CoS configuration on an interface using the show class-of-service interface command. An example output is provided below:
  • Verify the rewrite rule configuration using the show class-of-service rewrite-rule command. Example outputs are provided below:

Verify CoS Classifiers on vRouter

Verify Rewrite Rules

Verify ACLs for MF Classifier

Note: Each term has its own policer instance, for example Term 1 for family inet has policer instance V4MCFF_31trTCM_2 and Term 2 has policer instance V4MCFF_32trTCM_2 for the same policer srTCM_2.

Verify Policer Statistics

Verify Scheduler Statistics

Verify interface rate statistics:

Verify scheduler port statistics:

Verify scheduler port rate statistics:

Clear scheduler port statistics:

Verify CoS Features Applied on an Interface