Echtzeitdienste sind keine Fiktion

Reservierung mit Cops prüfen

Ein Router erkennt einen Datenstrom (Flow) anhand der IP-Adresse und des IP-Protokolls sowie der TCP/UDP-Portnummern, bei IPv6 auch anhand des Flow-Labels. RSVP überprüft jedoch nicht, ob eine Reservierung zulässig ist. Für diese Aufgabe ist das "Common-Open-Policy-Server"-Protokoll (Cops) zuständig, ein spezielles Policy-Protokoll.

Kommt Int-Serv zum Zuge, sollte das Netzwerk unterscheiden können, ob eine rechtmäßige Reservierungsanfrage vorliegt, etwa für eine geschäftskritische Anwendung, oder ob sich ein Mitarbeiter in der Mittagspause bei einem Multi-User-Spiel entspannt. Solche Policy-Entscheidungen werden nicht nur bei Int-Serv benötigt; deshalb hat die Arbeitsgruppe "Resource Admission Policy" (RAP) der IETF ein Policy-Modell entwickelt: den "Common Open Policy Server".

Ein Netzwerkgerät übernimmt dabei die Rolle eines "Policy Enforcement Point" (PEP). Über eine TCP-Verbindung wird bei einem "Policy Decision Point" (PDP) geprüft, ob die gewünschte Aktion überhaupt durchführbar ist. Mit Hilfe von Cops können PDPs und PEPs beliebige Policy- und Konfigurationsinformationen austauschen. Ein PDP bezieht seine Informationen beispielsweise aus einem LDAP-Verzeichnisdienst.

Obwohl die Int-Serv-Struktur seit 1994 dokumentiert ist und auch RSVP bereits seit 1997 vorliegt, wird Int-Serv kaum eingesetzt. Das liegt zum einen an der lange Zeit mangelhaften Unterstützung in den Endsystemen. So sind nur die aktuellen Windows-Versionen 98 und 2000 für RSVP ausgelegt; ähnlich sieht es im Unix-Bereich aus. Hinzu kommt, dass die Netzbetreiber die mangelnde Skalierbarkeit fürchteten. Außerdem fehlte lange Zeit ein Policy-Server. Die Router dagegen sind in der Lage, mehrere tausend RSVP-Datenströme zu unterstützen.