Zusammenfassung

  • RFC 3496 ergänzte PATH um ein optionales Objekt, mit dem ein MPLS-LSP UBR, VBR-NRT, VBR-RT oder CBR anfordern konnte.
  • Das Objekt implementierte die Behandlung nicht. Verstehen, Zustand, Reservierung, Labels, Queue, Scheduler, Messung und Anwendung blieben getrennte Belege.

Die Erweiterung sollte ATM-Zellen über MPLS tragen und dabei ihre Dienstklassen unterscheiden. Der Weg durfte Ethernet, Packet over SONET oder ATM nutzen. Übertragen wurde eine gemeinsame Anforderung, nicht eine identische Datenpfadmaschine.

Klasse 227 und C-Type 1 bezeichneten das Objekt. 29 reservierte Bits gingen als Null und wurden empfangsseitig ignoriert. Drei Bits wählten UBR, nicht-echtzeitfähiges VBR, Echtzeit-VBR oder CBR; vier Werte blieben reserviert.

Das Feld enthielt keine Queuetiefe, keinen Algorithmus, Puffer, Gewicht, Policer oder Messgrenzwert. Die RFC regelte ausdrücklich nicht, wie LSRs die ATM-Klassen durch Queuing und Scheduling emulieren sollten. Das Signal benannte ein Soll.

Es stand in PATH mit IPv4-LSP-Sitzung und Labelanforderung. DIFFSERV konnte daneben stehen, ohne gleichbedeutend zu sein. Der Anwendungsbereich blieb Unicast.

Bewusste LSRs speicherten das Objekt im Pfadzustand. Das belegte eine Kontrollabsicht, nicht die Datenbehandlung. Bei mehreren Objekten galt nur das erste; weitere wurden verworfen und nicht weitergereicht.

RESV kam stets ohne Klassenobjekt zurück. Eine erfolgreiche Reservierung spiegelte den SC-Wert daher nicht. PATH, Hopzustand, Zulassung, Labels und Scheduler mussten korreliert werden.

Ein LSR ohne Kenntnis von 227 ignorierte und transportierte das Objekt nach der RSVP-Regel für 11-Klassen unverändert. Bytekontinuität war kein Verständnis. Bei bekanntem Klassencode und unbekanntem C-Type folgte PathErr.

Nichtunterstützung ließ den Aufbau scheitern. Der Sender sollte das Management informieren und konnte ohne Objekt erneut versuchen. Erfolg dieses Versuchs bewies nur einen allgemeinen LSP nach Entfernung der Anforderung.

RFC 3270, 3564 und 4124 behandelten Diffserv und DS-TE; RFC 5127 die Aggregation. RFC 3496 betraf das Schicksal einer einzelnen ATM-Klassenanforderung und ihren möglichen Verlust beim Fallback.

Die Beweiskette lautet PATH, Parsing, SC, Hopzustand, Zulassung, RESV, Labels, Queue und Scheduler, Messung, Anwendung. Kryptografischer Schutz und Protokollerfolg springen über keine dieser Stufen.

Quellen