QoS classification
Scope
This domain tests how Nokia IP routers inspect packets, assign forwarding class and profile, and how those decisions are expressed in SAP ingress and network QoS policies.
Core rules
- SAP ingress QoS policy match criteria can include IP criteria (DSCP, IP 5-tuple), MAC criteria (802.1p, source/destination MAC), and default. A match assigns an FC and optionally a profile (in/out).
- On network interfaces, the network QoS policy maps incoming DSCP to FC and profile; the same policy maps FC/profile to outgoing DSCP.
- Meters create the in/out profile. A colour-blind meter ignores pre-existing colour; a colour-aware meter respects it. Single-rate (srTCM) and two-rate (trTCM) meters are supported.
- Reclassification can re-mark DSCP at ingress before queuing; rewrite/remark sets DSCP or EXP on egress.
- Untrusted access ports should use default classification and mark at the edge; trusted ports classify on DSCP.
- MPLS uses EXP/TC bits for classification, not DSCP, so an IP-to-MPLS mapping is needed.
Worked example
An access SAP receives untrusted PC traffic with DSCP 46. The SAP ingress policy matches default and assigns FC be plus profile out, then a meter limits it. A trusted IPTV SAP matches DSCP AF31 and assigns FC af, profile in. On egress the network QoS policy rewrites FC af to DSCP AF31 and FC be to 0 before the packet enters MPLS, where EXP 5 is used for voice.
Traps
- Applying DSCP classification to an untrusted access port, letting users self-mark EF.
- Forgetting that the profile (in/out) drives WRED treatment; same FC with out profile can be dropped earlier.
- Mixing up ingress classification with egress marking: both are needed for end-to-end treatment.
- Assuming 802.1p is preserved across an IP/MPLS core.