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 to be assigned a required service level.

Supported platforms

Dot1p classification and marking is supported on the following platforms:

7220 IXR-D2/D2L/D3/D3L
7220 IXR-D4/D5

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 supported	Used if no explicit dscp-policy	Used
Routed, untagged	IPv4/IPv6 priority-tagged	—	—	—	Not supported	Used if no explicit dscp-policy	Used
Routed, single-tagged	IPv4/IPv6 single-tagged	—	—	—	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

To reference a forwarding-class in any QoS policy, the forwarding-class must first be explicitly mapped to an output queue. For information about mapping the named forwarding classes to named queues, see Named queues and forwarding classes.

To configure a dot1p classifier policy, map one or more incoming dot1p values to custom forwarding-class and drop-probability values using the qos classifiers dot1p-policy command.

Note: The dot1p-policy name can be any name string other than default.

The following example creates a dot1p classifier policy:

Create a dot1p classifier policy

--{ candidate shared default }--[  ]--
# info qos classifiers  
    qos {
        classifiers {
            dot1p-policy new-dot1p-policy {
                dot1p 0 {
                    forwarding-class forwarding-class-0
                    drop-probability high
                }
                dot1p 7 {
                    forwarding-class forwarding-class-7
                    drop-probability low
                }
            }
        }
    }

Applying a dot1p policy to a subinterface

To apply a dot1p policy to input traffic on a subinterface, specify the policy using the qos interfaces interface input classifiers command.

The following example applies a dot1p policy to inbound traffic on a subinterface:

Apply a dot1p policy to a subinterface


--{ * candidate shared default }--[ ]--
# info qos interfaces interface ethernet-1/2
    qos {
        interfaces {
            interface ethernet-1/2 {
                interface-ref {
                    interface ethernet-1/2
                    subinterface 1
                }
                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. On 7220 IXR-D2/D2L/D3/D3L, does not modify the PCP of VLAN tags in the payload. On 7220 IXR-D4/D5, also modifies 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

To configure dot1p rewrite rules, map internal forwarding classes (and optionally drop-probability) to the required dot1p values using the qos rewrite-rules dot1p-policy command.

The following example creates a dot1p rewrite-rule policy:

Configure a dot1p rewrite rule

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

Applying a dot1p rewrite rule to a subinterface

To apply a dot1p rewrite rule to output traffic on a subinterface, specify the required policy using the qos interfaces interface output rewrite-rules command.

The following example applies a dot1p rewrite-rule policy to outbound traffic on a subinterface:

--{ * candidate shared default }--[ ]--
# info qos interfaces interface ethernet-1/2
    qos {
        interfaces {
            interface ethernet-1/2 {
                interface-ref {
                    interface ethernet-1/2
                    subinterface 1
                }
                output {
                    rewrite-rules {
                        dot1p-policy rewrite-dot1p-example
                    }
                }
            }
        }
    }