QoS in Ethernet: 802.1p CoS in Metro/Access sauber nutzen

QoS in Ethernet wird in Metro- und Access-Netzen häufig über 802.1p CoS (Class of Service) umgesetzt – und genau dort entscheidet sich oft, ob Voice & Video stabil laufen oder bei Peak-Last ruckeln und knacken. Viele Provider haben ein sauberes DiffServ-Konzept mit DSCP (EF/AF), aber im Ethernet-Teil der Strecke – zum Beispiel bei Carrier Ethernet, FTTH-Aggregation, HFC-Backhaul, Business-Ethernet oder in Metro-Ringen – wird primär auf Layer 2 gequeued. Dann zählt nicht das DSCP im IP-Header, sondern die 802.1p-Priorität im VLAN-Tag. Wenn CoS an der Netzgrenze falsch gesetzt, überschrieben oder nicht konsistent gemappt wird, entsteht ein „QoS-Loch“: Voice wird plötzlich wie Best Effort behandelt, Video bekommt keine garantierten Anteile, und Microbursts führen zu Drop-Clustern. Professionelles QoS in Ethernet bedeutet deshalb: ein klares CoS-Klassenmodell definieren, Trust Boundaries am UNI/NNI festlegen, DSCP-to-CoS und CoS-to-DSCP sauber mappen, Profile pro Klasse durchsetzen (Remarking, Policing, Shaping) und die Hardware-Queues in Access/Metro konsistent betreiben. Dieser Artikel erklärt 802.1p CoS im Telco-Kontext verständlich und praxisnah – inklusive typischer Einsatzszenarien, Designregeln, häufiger Fehler und einer Blaupause, wie Sie CoS in Metro/Access sauber nutzen, ohne Ihr Netz operativ zu überfrachten.

802.1p CoS kurz erklärt: Wo steckt die Priorität im Ethernet?

802.1p CoS ist Teil des VLAN-Taggings nach 802.1Q. Im VLAN-Tag gibt es ein 3-Bit-Feld (PCP – Priority Code Point), das Werte von 0 bis 7 annehmen kann. Diese Werte signalisieren auf Layer 2 eine Priorität, die Switches und Carrier-Ethernet-Plattformen typischerweise direkt auf Hardware-Queues und Scheduler abbilden.

• PCP/CoS (0–7): Layer-2-Priorität im VLAN-Tag.
• Wirksamkeit: besonders hoch in Metro/Access, weil viele Geräte dort L2-zentriert queuen.
• Abhängigkeit: CoS wirkt nur, wenn Frames getaggt sind; bei untagged Traffic existiert kein PCP.

Wichtig: CoS ist keine „Magie“, sondern ein Signal. Erst wenn Ihr Netz PCP-Werte in echte Queues, Scheduling und Drop-Profile umsetzt, entsteht ein QoS-Effekt.

Warum CoS in Metro/Access so wichtig ist – selbst wenn Sie DSCP nutzen

In Telco-Netzen ist der Transport oft mehrstufig: Access/Metro läuft als Carrier Ethernet (L2), Core läuft als IP/MPLS oder SR. In L2-Segmenten kann das Underlay DSCP gar nicht „sehen“, wenn nur Ethernet-Frames betrachtet werden. Selbst wenn DSCP im IP-Paket steht, entscheidet am Metro-Switch häufig PCP über die Queue.

• L2-Queuing: Viele Metro-Switches queuen nach PCP, nicht nach DSCP.
• Bridging-Abschnitte: In reinem Bridging wird IP nicht interpretiert.
• Aggregation: Viele Kundenströme treffen auf wenige Uplinks; Microbursts sind typisch – hier entscheidet die L2-Queue-Strategie.

Das führt zu einem zentralen Prinzip: Wenn Sie end-to-end QoS wollen, müssen DSCP und CoS konsistent zusammenpassen. Sonst entsteht eine Strecke, in der Markierungen „zwar da sind“, aber nicht wirken.

Typische Ethernet-Szenarien im Telco-Umfeld

802.1p CoS spielt besonders in diesen Umgebungen eine Rolle:

• Carrier Ethernet / Business Ethernet: E-Line/E-LAN, EVC-basierte Services, häufig mit SLAs.
• Metro-Ringe: Aggregationsringe mit Schutzmechanismen, Oversubscription und Burst-Spitzen.
• FTTH-Aggregation: L2-Abschnitte zwischen OLT/Access und Metro-Core.
• Mobile Backhaul Ethernet: Transport von RAN/Backhaul über Ethernet, teils mit strengen QoS-Anforderungen.
• Wholesale/NNI: Übergabe zwischen Netzen über VLAN- oder Q-in-Q-Mechanismen.

In all diesen Szenarien ist CoS oft der „erste“ QoS-Hebel – und gleichzeitig die häufigste Fehlerquelle, wenn Markierungen unklar sind.

CoS-Klassenmodell: Wie viele PCP-Werte sind sinnvoll?

PCP bietet 8 Werte, aber das heißt nicht, dass Sie 8 Klassen betreiben sollten. Im Providerbetrieb ist ein kompaktes Modell meist stabiler. Ein praxistauglicher Ansatz nutzt 4 bis 6 CoS-Klassen, die klaren Serviceklassen entsprechen:

• CoS für Voice Media: höchste Echtzeitklasse (Low Latency), strict priority mit Limit.
• CoS für Control/Signaling: hoch priorisiert, aber gewichtet.
• CoS für interaktives Video: bevorzugt, gewichtet, garantierte Anteile.
• CoS für Best Effort: Standardklasse.
• CoS für Background: niedrig priorisiert.

Je weniger Klassen Sie nutzen, desto leichter wird konsistentes Mapping über Access, Metro und Core. Zu viele CoS-Stufen führen häufig zu Drift und schwerer Troubleshooting-Arbeit.

Trust Boundary im Ethernet: Wer darf PCP setzen?

CoS ist besonders missbrauchsanfällig, weil PCP direkt auf Hardware-Queues wirkt. Ein Kunde, der alles auf PCP „hoch“ setzt, kann im schlimmsten Fall Premium-Queues aufblasen. Deshalb ist die Trust Boundary im Ethernet essenziell – vor allem am UNI.

• Untrusted UNI: Kunden-PCP wird ignoriert oder auf Default gesetzt; Provider setzt PCP basierend auf Produktprofil.
• Trusted UNI: nur bei managed CPE oder streng kontrollierten Quellen.
• Conditional Trust: PCP wird akzeptiert, aber normalisiert und profiliert; Überschuss wird remarkt.

In Metro/Access ist Conditional Trust oft der beste Kompromiss: Premium bleibt möglich, ohne Premium-Inflation zu riskieren.

Q-in-Q und Wholesale: CoS über mehrere VLAN-Tags richtig behandeln

Im Wholesale/Resale und in vielen Carrier-Ethernet-Setups werden VLAN-Tags gestapelt (Q-in-Q). Dabei können PCP-Werte auf verschiedenen Tag-Ebenen existieren. Damit QoS funktioniert, müssen Sie definieren, welche PCP-Ebene maßgeblich ist.

• Customer Tag (C-Tag): PCP aus Kundendomäne, meist untrusted oder conditional trust.
• Service Tag (S-Tag): Provider-Tag, häufig die operative QoS-Basis im Metro-Netz.
• Regel: PCP auf dem Tag, nach dem Ihre Metro-Switches queuen, muss korrekt gesetzt sein – meist der S-Tag.

In vielen Netzen wird PCP vom C-Tag in den S-Tag gemappt (oder überschrieben), um Providerklassen stabil zu halten. Ohne diese Regel entstehen QoS-Löcher an Übergängen.

DSCP-to-CoS: Die wichtigste Übersetzung für End-to-End QoS

Wenn Kunden DSCP markieren (Voice EF, Video AF), müssen Sie im Ethernet-Abschnitt diese Bedeutung in CoS übersetzen. DSCP-to-CoS-Mapping sollte standardisiert sein, sonst entstehen inkonsistente Klassen über verschiedene PEs und Metro-Knoten.

• Voice EF: wird auf die höchste Echtzeit-CoS gemappt (LLQ-fähig).
• Video AF: wird auf eine bevorzugte, gewichtete CoS gemappt.
• Control/Signaling: eigene CoS, hoch priorisiert, aber nicht strict priority.
• Best Effort: Default-CoS.
• Background: niedrige CoS.

Wichtig ist dabei weniger „welche Zahl genau“, sondern dass alle Domänen dieselbe Bedeutung nutzen und die Hardware-Queues dazu passen.

CoS-to-DSCP: Übergaben und Transparenz richtig gestalten

Am Ende eines Ethernet-Abschnitts steht häufig wieder ein IP-Abschnitt oder ein Übergabepunkt zum Kunden. Dort stellt sich die Frage: Soll DSCP beibehalten, wiederhergestellt oder neutralisiert werden?

• Restore: DSCP wird basierend auf CoS wieder gesetzt, um End-to-End-DiffServ zu ermöglichen.
• Preserve: DSCP wird durchgängig transportiert (wenn die Plattform IP-aware ist).
• Normalize: DSCP wird auf ein Providerprofil gesetzt, um unerwünschte Kundencodes zu vermeiden.

Für Business-SLAs ist Restore/Normalize häufig sinnvoll, weil es Übergaben konsistent macht und Missmarkierung nicht „durchschleift“.

Queueing und Scheduling in Ethernet: Voice braucht LLQ, Video braucht Gewichtung

CoS entfaltet seine Wirkung erst durch Queueing und Scheduling. In Metro/Access sollten Sie die Behandlung pro CoS-Klasse klar definieren:

• Voice-CoS: strict priority (LLQ) mit Limit, kleine Queue-Limits, praktisch keine Drops.
• Video-CoS: gewichtete Queue mit garantierten Anteilen, kontrollierte Puffer gegen Bufferbloat.
• Best Effort: fair, Puffer kontrollieren, optional Congestion Avoidance.
• Background: niedrige Gewichtung.

Die größte Gefahr ist, Video in die gleiche strict-priority Behandlung wie Voice zu stecken. Video ist variabel und kann Premium-Queues aufblasen. Deshalb: Audio strikt trennen, Video gewichtet behandeln.

Shaping und Policing in Metro/Access: Bursts sind der Normalfall

Metro- und Access-Netze sind bursty: Microbursts aus vielen Quellen treffen auf wenige Uplinks. Ohne Burst-Handling entstehen Drop-Cluster, die Voice und Video beschädigen – selbst wenn CoS korrekt ist.

• Egress-Shaping: glättet Bursts an rate-limitierten Links und reduziert Drop-Cluster.
• Policing: gut für Governance (Profile pro Kunde/Service), aber Drops sind für Echtzeit riskant.
• Remarking statt Drop: Überschuss wird in niedrigere CoS/Drop-Precedence überführt, statt hart zu droppen (besonders für Video).

Ein bewährtes Muster ist: Profilierung am Ingress (Governance) und Shaping am Egress (Stabilität), während Voice über LLQ schnell bevorzugt wird.

Buffer-Design: Warum falsche Queue-Größen CoS entwerten

Auch in Ethernet gilt: Zu große Buffers erzeugen Bufferbloat und Jitter, zu kleine Buffers erzeugen Drop-Cluster bei Bursts. Für CoS-Klassen bedeutet das:

• Voice-Queue: klein und schnell; hohe Queue-Depth ist bereits ein Warnsignal.
• Video-Queue: moderat, um Bursts abzufangen, aber nicht so groß, dass Latenz pendelt.
• Best Effort: kontrolliert, um Latenzspitzen zu vermeiden.

Wenn Voice trotz CoS knackt, ist die Ursache häufig nicht die Markierung, sondern Burst-Überlauf oder falsche Queue-Limits in einem Metro-Knoten.

Typische Fehler bei 802.1p CoS in Metro/Access

• Untagged Traffic: PCP existiert nicht, QoS wirkt nicht wie erwartet; Lösung: klare Tagging-Policy oder DSCP-aware Queuing.
• Blindes Trust am UNI: Kunden markieren alles hoch, Premium-Inflation, LLQ wird überfüllt.
• Inkonsequentes DSCP-to-CoS Mapping: CoS-Klassen driften, QoS-Löcher entstehen.
• Falsche PCP-Ebene bei Q-in-Q: Metro queuet nach S-Tag, aber nur C-Tag ist korrekt markiert.
• Video in Voice-CoS: strict priority wird überfahren, Best Effort und sogar Control leiden.
• Keine Burst-Stabilisierung: Microbursts erzeugen Drop-Cluster trotz „richtiger“ CoS.

Monitoring: CoS im Betrieb nachweisbar machen

Damit CoS in Metro/Access nicht zur Blackbox wird, sollten Sie pro Interface und pro CoS-Klasse Sichtbarkeit haben:

• Traffic pro PCP: Volumen und Peaks, um Premium-Inflation zu erkennen.
• Queue-Drops pro CoS: Drops in Voice-CoS sind kritisch, Video-Drops deuten auf Gewichte/Bursts hin.
• Queue-Depth/Queueing Delay: zeigt Bufferbloat und Jitter-Risiko.
• Policer-Hits/Remarking: zeigt Profilverletzungen und Missmarkierung am UNI/NNI.
• QoE-Korrelation: MOS/R-Faktor, Audio-Interruptions, Video-Freeze-Events (bei managed Services).

Ein operativer Leitsatz ist: Drops in der Voice-CoS-Klasse sind ein Incident. CoS muss Echtzeit stabilisieren, nicht nur „etikettieren“.

Praxis-Blueprint: 802.1p CoS in Metro/Access sauber nutzen

• CoS-Klassenmodell definieren: 4–6 Klassen, klare Bedeutungen (Voice, Video, Control, BE, Background).
• Trust Boundary festlegen: am UNI meist conditional trust, am NNI vertraglich strikt.
• DSCP-to-CoS standardisieren: einheitliche Mapping-Tabellen, versioniert und getestet.
• Q-in-Q Regeln definieren: PCP auf S-Tag setzen, wenn Metro nach S-Tag queuet.
• Queueing/Scheduling standardisieren: Voice LLQ mit Limit, Video gewichtet, Best Effort fair.
• Burst-Handling integrieren: Shaping an Engpässen, Queue-Limits, Remarking statt Drop.
• Monitoring operationalisieren: PCP-Traffic, Drops, Queue-Depth, Policer-Hits in Dashboards.

Häufige Fragen zu QoS in Ethernet und 802.1p

Ist CoS oder DSCP „wichtiger“?

In Metro/Access ist CoS oft wichtiger, weil L2-Geräte häufig nach PCP queuen. Für End-to-End-QoS brauchen Sie jedoch beides: DSCP als dienstübergreifende Semantik und CoS als wirksame L2-Queue-Steuerung. Entscheidend ist das Mapping zwischen beiden.

Kann ich CoS auf untagged Ports nutzen?

PCP existiert nur in getaggten Frames. Auf untagged Ports müssen Sie entweder intern eine Priorität zuweisen (port-based QoS) oder DSCP-aware Queuing nutzen, sofern die Plattform das unterstützt. Für Provider-Services ist konsequentes Tagging in der Regel der sauberste Weg.

Was ist der häufigste Grund, warum Voice trotz CoS knackt?

Meist Burst-Probleme oder falsche Queue-Limits an Aggregationspunkten: Microbursts führen zu Drops in der Voice-Queue oder zu Delay-Spikes. Wenn Mapping und Trust Boundary stimmen, sind Shaping und Buffer-Design die nächsten Hebel, um Echtzeit stabil zu halten.