Dot1p classification and marking

SR Linux supports IEEE 802.1p (dot1p) classification and marking using the Priority Code Point (PCP) field. When one or more IEEE 802.1Q VLAN tags are added to an Ethernet frame, the Class of Service (CoS) of the frame can be set using the PCP field in the outermost VLAN tag. The 3-bit PCP field can specify eight different classes of service, allowing Ethernet frames that carry non-IP or non-MPLS payloads to be assigned a required service level.

Supported platforms

Dot1p classification and marking is supported on the following platforms:

  • 7220 IXR-D2/D2L: R22.6.3 (targeted release)
  • 7220 IXR-D3/D3L: R22.6.3 (targeted release)

Dot1p classification

Dot1p classification refers to classification of a frame based on the PCP field in the outermost VLAN. The system assigns a forwarding-class and drop-probability to every packet at an early point in the packet forwarding pipeline. These assignments determine which packets to schedule or drop first when congestion occurs.

Each dot1p classifier policy can contain up to eight mapping rules. Each rule binds one of the eight possible PCP values (0 to 7) to a forwarding-class (fc0 to fc7) and to a drop-probability level (low, medium, or high).

For a dot1p classifier policy to take effect, you must apply the policy to at least one bridged subinterface. SR Linux supports dot1p classifier policies on any bridged subinterface of any Ethernet port or LAG. No limit exists on the number of bridged subinterfaces that can apply the same policy. (Routed subinterfaces are not supported.) Dot1p classification is applicable for non-IP packets only.

When a dot1p classifier policy is applied to a subinterface, if the PCP value for an incoming Ethernet frame does not match any configured dot1p rule, the frame is classified as fc0 and drop-probability low.

Default dot1p classifier policy

SR Linux supports a default dot1p classifier policy, which always exists and is not modifiable. It is invisibly applied to all bridged subinterfaces that do not have a configured dot1p classifier policy applied. The following table describes the rules of the default policy.

Table 1. Default dot1p classifier policy
Dot1p FC Drop probability
0 fc0 low
1 fc1 low
2 fc2 low
3 fc3 low
4 fc4 low
5 fc5 low
6 fc6 low
7 fc7 low

Dot1p classifier policy effects

The following table describes the effects of applying the dot1p classifier policy in relation to other configuration.

Table 2. Effect of dot1p classifier policy in relation to other configuration
Ingress sub-interface type Ingress packet type default fc of ingress sub-interface default drop-probability of ingress subif default dot1p-policy explicit dot1p-policy (bound to ingress sub-interface) default dscp-policy explicit dscp-policy (bound to ingress sub-interface)
routed, untagged IPv4/IPv6 untagged not applicable not supported used if no explicit dscp-policy used
routed, untagged IPv4/IPv6 priority-tagged not applicable not supported used if no explicit dscp-policy used
routed, single-tagged IPv4/IPv6 single-tagged not applicable not supported used if no explicit dscp-policy used
bridged, untagged IPv4/IPv6 untagged used if no explicit dscp-policy used
bridged, untagged IPv4/IPv6 priority-tagged used if no explicit dscp-policy used
bridged, single-tagged IPv4/IPv6 single-tagged used if no explicit dscp-policy used
bridged, untagged non-IP untagged used used
bridged, untagged non-IP priority-tagged used if no explicit dot1p-policy used
bridged, single-tagged non-IP single-tagged used if no explicit dot1p-policy used
bridged, single-tagged non-IP double-tagged used if no explicit dot1p-policy used

Configuring dot1p classifiers for input traffic

The following example creates a dot1p classifier policy:

Note: The dot1p-policy name can be any name string other than default.
--{ candidate shared default }--[  ]--
# info qos classifiers
 qos {
        classifiers {
            dot1p-policy new-dot1p-policy {
                dot1p 0 {
                    forwarding-class fc0
                    drop-probability high
                }
                dot1p 7 {
                    forwarding-class fc7
                    drop-probability low
                }
            }
        }
    }

Applying a dot1p policy to a subinterface

The following example applies a dot1p policy to inbound traffic on a subinterface:
# info interface ethernet-1/1 subinterface 1 qos input classifiers
    interface ethernet-1/1 {
        subinterface 1 {
            qos {
                input {
                    classifiers {
                        dot1p-policy new-dot1p-policy
                    }
                }
            }
        }
    }

Dot1p marking

Dot1p marking refers to rewriting of the PCP value in the outermost VLAN tag. The node rewrites the value in the PCP field before a packet is transmitted out an egress interface. Downstream nodes handle the remarked traffic based on the updated code point. SR Linux implements dot1p marking using dot1p rewrite policies.

Each dot1p rewrite policy contains up to eight mapping rules, and each rule associates one of the eight possible internal forwarding classes (fc0 to fc7) to a PCP value (0 to 7).

Unless explicitly configured otherwise, a new mapping rule applies to all drop-probability levels. You can optionally configure a mapping rule for a specific forwarding class and drop probability combination, as required.

For a dot1p rewrite policy to take effect, you must apply the policy to at least one subinterface. SR Linux supports rewrite policies on any bridged or routed subinterface of any Ethernet port or LAG. No limit exists on the number of subinterfaces that can apply the same policy.

When a dot1p rewrite policy is applied to a subinterface, if the forwarding class of an outgoing packet does not match any configured dot1p rewrite rule, all pushed 802.1Q VLAN tags on the outgoing frame are marked with a PCP value of 0.

If a dot1p rewrite policy is not applied to a subinterface:

  • For a routed subinterface, the dot1p value is taken from the forwarding class
  • For bridged subinterface, the dot1p value is 0

No default dot1p rewrite policy

No default dot1p rewrite policy exists.

Effect of dot1p rewrite policy

Table 3. Effect of dot1p rewrite policy in relation to other configuration
Egress sub-interface type Egress packet type Behavior with dot1p-policy applied to egress sub-interface Behavior without dot1p-policy applied to egress sub-interface
Untagged Any None, can be blocked
Routed, single-tagged Non-originated, forwarded IPv4/IPv6

Rewrites the PCP in the VLAN tag pushed at egress by the subinterface definition.

PCP = fc in the VLAN tag pushed at egress when no policy attached.
Routed, single-tagged Self-originated IPv4/IPv6 None, ignored for self-originated traffic.
Routed, single-tagged Non-originated, forwarded after VXLAN encapsulation, Ethernet untagged payload PCP = fc in the VLAN tag pushed at egress by the subinterface definition. PCP = fc in the VLAN tag pushed at egress when no policy attached.
Bridged, single-tagged Non-originated, L2 forwarded Rewrites the PCP in the VLAN tag pushed at egress by the subinterface definition. Does not modify the PCP of VLAN tags in the payload. A VLAN tag is carried as payload when the ingress subinterface is configured with vlan-tagging = true and vlan-id = any. PCP = 0 in the VLAN tag pushed at egress when no policy attached. Does not modify the PCP of VLAN tags in the payload. A VLAN tag is carried as payload when the ingress subinterface is configured with vlan-tagging = true and vlan-id = any.
Bridged, single-tagged Self-originated IPv4/IPv6 None, ignored for self-originated traffic.
Bridged, single-tagged Non-originated, L3 forwarded (IRB) Rewrites the PCP in the VLAN tag pushed at egress by the subinterface definition. PCP = fc in the VLAN tag pushed at egress when no policy attached.
Bridged, single-tagged Non-originated, forwarded after VXLAN decapsulation, Ethernet untagged payload Rewrites the PCP in the VLAN tag pushed at egress by the subinterface definition. PCP = fc in the VLAN tag pushed at egress when no policy attached.

Configuring dot1p rewrite rules for output traffic

The following example creates a dot1p rewrite-rule policy:

--{ candidate shared default }--[  ]--
# info qos rewrite-rules
    qos {
        rewrite-rules {
            dot1p-policy rewrite-dot1p-example {
                map fc0 {
                    dot1p 0
                }
                map fc1 {
                    dot1p 3
                    drop-probability low {
                        dot1p 1
                    }
                    drop-probability high {
                        dot1p 2
                    }
                }
                map fc3 {
                    dot1p 3
                }
                map fc7 {
                    dot1p 7
                }
            }
        }
    }

Applying a dot1p rewrite rule to a subinterface

The following example applies a dot1p rewrite-rule policy to outbound traffic on a subinterface:
# info interface ethernet-1/1 subinterface 1 qos output rewrite-rules
    interface ethernet-1/1 {
        subinterface 1 {
            qos {
                output {
                    rewrite-rules {
                        dot1p-policy rewrite-dot1p-example
                    }
                }
            }
        }
    }