Egress marking and remarking: dot1p, MPLS traffic-class, and DSCP
At egress, packet marking and remarking allow 7730 SXR platforms to signal the per-hop-behavior (forwarding class and profile combinations) to the downstream node.
7730 SXR platforms perform egress marking and remarking based on rewrite-rule policies applied at the subinterface level. These platforms support three types of rewrite-rule policies, which are applied in the following order:
- Dot1p policy (including inner dot1p, outer dot1p, and discard eligibility bit)
- MPLS traffic-class policy (including optional profile settings)
- DSCP policy (including optional profile settings)
Service edge – ingress
The following figure shows the supported packet marking capabilities at service edge ingress.
There are two options, depending on the type of service (Layer 2 or Layer 3). In both cases, the service related encapsulation is pushed on the packet and marking is indicated by arrows. Only the outer label is marked according to the MPLS traffic-class policy, and all inner labels pushed are marked with the EXP bit set to 0.
Network core – transit
The following figure shows the supported packet marking capabilities in a network core transit scenario.
There are two types of packets to be expected:
- MPLS encapsulated packets
- plain IP packets
The preceding figure indicates which encapsulation levels are subject to marking and remarking.
Service edge – egress
The following figure shows the supported packet remarking capabilities at service edge egress.
Dot1p rewrite-rule policy
The dot1p rewrite-rule policy maps a forwarding class and optionally profile to a dot1p value and discard-eligibility setting. Marking of inner and outer dot1p values is also supported for relevant cases. In addition, the policy can also specify marking of the discard-eligibility bit.
Dot1p marking refers to rewriting of the PCP value in the inner and outer VLAN tags. 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 16 possible internal forwarding classes to a PCP value (0 to 7) and profile.
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.
Default dot1p rewrite-rule policy
The following output shows the default dot1p rewrite-rule policy, with system-reserved name of default. This policy is assigned by default to any newly created subinterface.
qos {
rewrite-rules {
dot1p-policy default {
map fc0 {
inner-dot1p 0
outer-dot1p 0
}
map fc1 {
inner-dot1p 1
outer-dot1p 1
}
map fc2 {
inner-dot1p 2
outer-dot1p 2
}
map fc3 {
inner-dot1p 3
outer-dot1p 3
}
map fc4 {
inner-dot1p 4
outer-dot1p 4
}
map fc5 {
inner-dot1p 5
outer-dot1p 5
}
map fc6 {
inner-dot1p 6
outer-dot1p 6
}
map fc7 {
inner-dot1p 7
outer-dot1p 7
}
map fc8 {
inner-dot1p 0
outer-dot1p 0
}
map fc9 {
inner-dot1p 0
outer-dot1p 0
}
map fc10 {
inner-dot1p 0
outer-dot1p 0
}
map fc11 {
inner-dot1p 0
outer-dot1p 0
}
map fc12 {
inner-dot1p 0
outer-dot1p 0
}
map fc13 {
inner-dot1p 0
outer-dot1p 0
}
map fc14 {
inner-dot1p 0
outer-dot1p 0
}
map fc15 {
inner-dot1p 0
outer-dot1p 0
}
}
}
}
Configuring dot1p rewrite-rule policies
To configure dot1p rewrite-rule policies, use the qos rewrite-rules dot1p-policy command to map a forwarding class and optionally profile values to inner dot1p, outer dot1p, and discard-eligibility settings.
Configure dot1p rewrite-rule policies
--{ + candidate shared default }--[ ]--
# info qos rewrite-rules dot1p-policy dot1p-rewrite-name
qos {
rewrite-rules {
dot1p-policy dot1p-rewrite-name {
map fc0 {
inner-dot1p 0
outer-dot1p 0
inner-de true
outer-de false
profile in {
}
}
}
}
}
Applying a dot1p rewrite-rule policy to a subinterface
To apply a dot1p rewrite-rule policy to a subinterface, use the qos interfaces interface output rewrite-rules command.
Apply a dot1p rewrite-rule policy to a subinterface
In this example, the qinq-rewrite-outer-only parameter is set to true, which restricts remarking to only the outer dot1p bits on the subinterface.
--{ + candidate shared default }--[ ]--
# info qos interfaces interface ethernet-1/2.1 output rewrite-rules dot1p-policy
qos {
interfaces {
interface ethernet-1/2.1 {
interface-ref {
interface ethernet-1/2
subinterface 1
}
output {
rewrite-rules {
dot1p-policy dot1p-rewrite-name
qinq-rewrite-outer-only true
}
}
}
}
}
MPLS traffic-class rewrite-rule policy
The MPLS traffic-class rewrite-rule policy maps a packet's forwarding class and optionally profile settings to a traffic class (EXP) value. The policy applies in the following scenarios:
- Service edge ingress scenario: the marking is applied only for the outer label. All inner labels are marked with the EXP bit set to 0.
- Core transit scenario: only the outer label EXP bits are remarked.
The policy can specify one traffic class that applies for all packets matching an FC, or it can map multiple traffic classes to one or more profiles associated with an FC.
Default MPLS traffic-class rewrite-rule policy
The following output shows the default MPLS traffic-class rewrite-rule policy, with system-reserved name of default. This policy is assigned by default to any newly created subinterface.
qos {
rewrite-rules {
mpls-traffic-class-policy default {
map fc0 {
traffic-class 0
}
map fc1 {
traffic-class 1
}
map fc2 {
traffic-class 2
profile in {
traffic-class 3
}
profile in-plus {
traffic-class 3
}
}
map fc3 {
traffic-class 2
profile in {
traffic-class 3
}
profile in-plus {
traffic-class 3
}
}
map fc4 {
traffic-class 4
}
map fc5 {
traffic-class 5
}
map fc6 {
traffic-class 6
}
map fc7 {
traffic-class 7
}
map fc8 {
traffic-class 0
}
map fc9 {
traffic-class 0
}
map fc10 {
traffic-class 0
}
map fc11 {
traffic-class 0
}
map fc12 {
traffic-class 0
}
map fc13 {
traffic-class 0
}
map fc14 {
traffic-class 0
}
map fc15 {
traffic-class 0
}
}
}
}
Configuring MPLS traffic-class rewrite-rule policies
To configure MPLS traffic-class rewrite-rule policies, use the qos rewrite-rules mpls-traffic-class-policy command to map forwarding classes, and optionally profiles, to an MPLS traffic class.
Configure MPLS traffic-class rewrite-rule policies
--{ candidate shared default }--[ ]--
# info qos rewrite-rules mpls-traffic-class-policy exp-rewrite-name
qos {
rewrite-rules {
mpls-traffic-class-policy mpls-traffic-class-policy-name {
map fc0 {
traffic-class 1
profile in-plus {
traffic-class 1
}
}
}
}
}
Applying an MPLS traffic-class rewrite-rule policy to a subinterface
To apply an MPLS traffic-class rewrite-rule policy to a subinterface, use the qos interfaces interface output rewrite-rules command.
Apply an MPLS traffic-class rewrite-rule policy to a subinterface (7730 SXR)
--{ + candidate shared default }--[ ]--
# info qos interfaces interface ethernet-1/2.1 output rewrite-rules mpls-traffic-class-policy
qos {
interfaces {
interface ethernet-1/2.1 {
interface-ref {
interface ethernet-1/2
subinterface 1
}
output {
rewrite-rules {
mpls-traffic-class-policy mpls-traffic-class-policy-name
}
}
}
}
}
DSCP rewrite-rule policy
The DSCP rewrite-rule policy maps a forwarding class and optionally profile to a DSCP value.
When a DSCP rewrite-rule policy is applied to a subinterface, the policy attempts to match the forwarding class (and optionally the profile) of outbound packets to one of its entries. If there is a match, the DSCP value of the outbound packet is changed to the value specified by the policy.
-
Assign a DSCP rewrite-rule policy to the subinterface, using the following command:
qos interfaces interface <name> output rewrite-rules dscp-policy <name>
-
If the input subinterface is trusted (the default setting), enable the force-rewrite-trusted option using the following command:
qos interfaces interface <name> output rewrite-rules dscp-rewrite force-rewrite-trusted
If the input subinterface is untrusted, force-rewrite-trusted has no effect, and remarking is applied as defined by the rewrite-rules dscp-policy command.
The following table describes the rewrite-rule behavior based on the policy configuration and subinterface flag.
Trusted at input | force-rewrite-trusted setting at output | DSCP action |
---|---|---|
false | false | remark |
true | false | preserve |
false | true | remark |
true | true | remark |
Default DSCP rewrite-rule policy
The following output shows the default DSCP rewrite-rule policy, with system-reserved name of default. This default policy is assigned to any subinterface at creation time.
qos {
rewrite-rules {
dscp-policy default {
map fc0 {
dscp LE
}
map fc1 {
dscp CS1
}
map fc2 {
dscp AF12
profile in {
dscp AF11
}
profile in-plus {
dscp AF11
}
}
map fc3 {
dscp AF22
profile in {
dscp AF21
}
profile in-plus {
dscp AF21
}
}
map fc4 {
dscp AF42
profile in {
dscp AF41
}
profile in-plus {
dscp AF41
}
}
map fc5 {
dscp EF
}
map fc6 {
dscp CS6
}
map fc7 {
dscp CS7
}
map fc8 {
dscp LE
}
map fc9 {
dscp LE
}
map fc10 {
dscp LE
}
map fc11 {
dscp LE
}
map fc12 {
dscp LE
}
map fc13 {
dscp LE
}
map fc14 {
dscp LE
}
map fc15 {
dscp LE
}
}
}
}
Configuring DSCP rewrite-rule policies
To configure DSCP rewrite-rule policies, use the qos rewrite-rules dscp-policy command to map forwarding classes, and optionally profiles, to a DSCP value.
Configure DSCP rewrite-rule policies
--{ + candidate shared default }--[ ]--
# info qos rewrite-rules dscp-policy dscp-policy-name
qos {
rewrite-rules {
dscp-policy dscp-policy-name {
map fc0 {
dscp AF11
profile out {
dscp AF11
}
}
}
}
}
Applying a DSCP rewrite-rule policy to a subinterface
To apply a DSCP rewrite-rule policy to a subinterface, use the qos interfaces interface output rewrite-rules command.
When the input subinterface is trusted (the default setting), remarking is only applied if the output rewrite-rules dscp-rewrite force-rewrite-trusted parameter is set to true on the output subinterface. When the input subinterface is untrusted, remarking is applied regardless of the force-rewrite-trusted setting. (To configure an input subinterface as trusted or untrusted, use the qos interfaces interface input classifiers tos-rewrite-state command.)
Apply a DSCP rewrite-rule policy to a subinterface
--{ + candidate shared default }--[ ]--
# info qos interfaces interface ethernet-1/2.1
qos {
interfaces {
interface ethernet-1/2.1 {
interface-ref {
interface ethernet-1/2
subinterface 1
}
output {
rewrite-rules {
dscp-policy dscp-policy-name
dscp-rewrite {
force-rewrite-trusted true
}
}
}
}
}
}