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
7220 IXR-D3/D3L

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
                    }
                }
            }
        }
    }