Von: Petra Schlatter
Die Internet Engineering Task Force (IETF) hat sich der Aufgabe verschrieben, das Internet und die ihm zugrundeliegenden Techniken weiterzuentwickeln. Auf dem letzten Treffen des Gremiums in Oslo, an dem über 1700 Fachleute teilnahmen, standen folgende Themen im Mittelpunkt:
- IP mit Dienstequalität (Quality of Service, QoS),
- "Differentiated Services",
- "Policies" und Zugangskontrolle (Access Control),
- Multiprotocol Label Switching (MPLS),
- Authentifizierung, Autorisierung und Accounting,
- Multicast-Verkehr, Internet-Telefonie und Audio/Video über IP sowie
- das Internet-Protokoll der nächsten Generation (IP Next Generation).
Um in IP-Netzen eine bestimmte Dienstequalität garantieren zu können, sind Erweiterungen des Protokolls notwendig. Die Grundlagen dazu schuf die IETF mit zwei Modellen: dem "Integrated Services"-Modell (Intserv; RFC2210 bis RFC2212) und dem "Differentiated Services"-Modell (Diffserv; RFC2474 und 2475). Die Aufgabe der Intserve-Arbeitsgruppe bestand darin, die IP-Architektur für "Quality of Service" (QoS) fit zu machen. Eine Working Group entwickelte dazu das Signalisierungsprotokoll "Resource Reservation Protocol" (RSVP). Diese Arbeitsgruppe trat in Oslo zum letzten Mal zusammen. Obwohl die Standardisierung von RSVP noch nicht abgeschlossen ist, fiel die Entscheidung, Erweiterungen des Protokolls künftig nur noch im Rahmen von E-Mail-Foren zu diskutieren.
Diffserv: Dienste über Bitmuster definieren
Während die Arbeitsgruppen Intserv und RSVP technologieunabhängige Spezifikationen erarbeiten, befaßt sich die Gruppe ISSLL (Integrated Services over Specific Link Layer Architectur) damit, diese Vorgaben auf spezielle Subnetz-Techniken abzubilden, insbesondere IEEE 802.x für Ethernet, ATM sowie serielle Verbindungen.
Bei Intserv ist es notwendig, in allem Netzknoten für jeden einzelnen IP-Flow Ressourcen zu reservieren. Wesentlicher einfacher lassen sich QoS-Eigenschaften bei Diffserv realisieren: Ein Bit-Muster im Differentiated-Services-Feld (DS Field) des Paketkopfes legt fest, welche Dienstequalität einem IP-Paket zugeordnet wird. Dieses Muster definiert, auf welche Weise ein Netzknoten das Paket zu behandeln hat, ihm also beispielsweise Vorrang vor anderen Daten einräumen muß.
Für den Einsatz von Diffserv zwischen administrativen Bereichen (Interdomains) ist eine Übereinkunft darüber erforderlich, wie dieses Bit-Muster zu interpretieren ist. Aus Gründen der Interoperabilität legte die Diffserv-Gruppe den Gebrauch von Bits innerhalb des DS-Feldes fest.
Auf dem IETF-Meeting wurde vereinbart, ein Modell für Netzelemente an den Grenzen eines administrativen Bereichs (Boundary Devices) zu erarbeiten. Es soll insbesondere Details zu Verkehrsparametern sowie Konfigurations- und Monitoring-Einstellungen enthalten. Ein weiteres Ziel ist, spezifische Per-Hop-Verhaltensmuster zu definieren, inklusive der Empfehlung spezieller Bitmuster beziehungsweise Codepoints.
Policies und Access Control: Regeln für den Zugang
Der Einsatz von "Policies" (Regeln) zur effizienten Verwaltung von Netzelementen ist ein Konzept, mit dem sich die IETF-Mitglieder seit kurzem beschäftigen. Mehrere Arbeitsgruppen bekundeten Interesse an dieser Technologie. Das Policy-Konzept findet sich bereits in einzelnen Protokollen, etwa RSVP und dem "Border Gateway Protocol" (BGP).
Die Policy-Framework-Arbeitsgruppe entstand aus der Notwendigkeit heraus, solche Verfahrensregeln in einer skalierbaren, herstellerunabhängigen und interoperablen Weise darzustellen. Ein Vorteil von Policies ist, daß sich mit ihrer Hilfe Schnittstellen in Gruppen einteilen lassen, deren Mitglieder sich gleich verhalten.
Um Policy-Informationen in Netzen auf Basis von RSVP auszutauschen, entwickelte die Arbeitsgruppe "Resource Allocation Protocol" (RAP) das Protokoll Cops (Common Open Policy Service). Damit lassen sich regelbasierte Entscheidungen über Zugangsrechte zu Intserv-Diensten definieren. Auf dem Treffen in Oslo wurde die Erweiterung COPS-PR zum Austausch von Policy-Informationen aus der Policy Information Base (PIB) für Diffserv vorgestellt.
Multiprotocol Label Switching: Noch viele Fragen offen
Die Working Group "Multiprotocol Label Switching" (MPLS) ist gegenwärtig dabei, eine Spezifikation für Protokolle zu entwickeln, die beim Transport (Forwarding) unter Einsatz von "Label Swapping" Verwendung finden soll. MPLS wird in IP-Netzen als eine der Nachfolgetechnologien von ATM gehandelt. Das Verfahren ermöglicht den Einsatz von Routing-Hierarchien zur besseren Skalierbarkeit, ist unabhängig von Routing-Protokollen und unterstützt unterschiedliche Layer-2-Techniken.
Die MPLS-Arbeitsgruppe hat jedoch noch viele Teilproblemen zu lösen, was sich unter anderem in der großen Zahl von 23 Internet-Drafts zu diesem Themenkomplex widerspiegelt. Ein Problem ist die Bildung von Schleifen im Forwarding-Pfad. Dazu kann es beim Einsatz von Routing-Protokollen mit verteilter Berechnung kommen. Die Fachleute stellten unterschiedliche Mechanismen vor, die solche Schleifen entweder komplett eliminieren oder zumindest deren Bedarf an Netzwerkressourcen begrenzen.
Zusätzlich wurde eine Methode vorgestellt, mit der sich ein alternativer Label-Switching-Pfad (Label Switching Path, LSP) setzen läßt. Das Verfahren erlaubt ein schnelles Rerouting, indem im Fehlerfall der Datenfluß über einen parallelen LSP zwischen Quell- und Ziel-Switch gelenkt wird.
Multicasting: Suche nach einfacheren Lösungen
Erst zum zweiten Mal seit ihrer Gründung trat in Oslo die "Authentication, Authorization and Accounting"-Arbeitsgruppe (AAA) zusammen. Sie will eine Architektur für die Authentifizierung, Autorisierung und Abrechnung (Accounting) im Internet definieren. Dahinter steht die Absicht, Basisprotokolle für Applikationen wie IP-Telefonie, Bandbreiten-Broker oder Network-Access-Server zu entwickeln.
Einen Standard für IP-Multicast zu erarbeiten, erwies sich als wesentlich schwieriger als ursprünglich angenommen. Obwohl die Grundlagen bereits vor zehn Jahren gelegt wurden (RFC1075, RFC1112), sind die zuständigen Gruppen weiterhin aktiv. So beschäftigen sich die Teams "Protocol Independent Multicast" (PIM), "Interdomain Multicast Routing" (IDMR) und "Multicast Source Discovery Protocol" (MSDP) mit dem Routing von Multicast-Verkehr. Die Gruppe "Multicast Address Allocation" (Malloc) arbeitet an einer Architektur zur dynamischen Zuteilung von Multicast-Adressen, und die Working Group "MBONE Deployment" (MBONED) widmet sich dem Einsatz von Multicast-Protokollen.
Ein Manko der IP-Multicast-Architektur ist ihre Komplexität. Deshalb fand in Oslo ein initiales Treffen statt - das "Maestro Bird of a Feather". Das Ziel der Initiative ist, IP-Multicasting einfacher zu machen. Einige Teilnehmer schlugen zu diesem Zweck Änderungen am Adressierungsverfahren vor. Außerdem wurde darüber debattiert, welche Vereinfachungen im Fall eines einzelnen Senders möglich sind. Die Entscheidung, ob zu diesem Thema eine eigene Arbeitsgruppe gebildet wird, vertagten die IETF-Mitglieder bis zum nächsten Meeting, das im November in Washington stattfindet.
Internet-Telefonie und Audio/Video über IP
Die Arbeitsgruppen, die sich mit IP-Telefonie befassen - in erster Linie "Internet Telephony" (Iptel), "Media Gateway Control" (Megaco) und "Signaling Transport" (Sigtran) - fanden vor allem aufgrund der wachsenden wirtschaftlichen Bedeutung der Technik große Aufmerksamkeit. Außerdem gab es zahlreiche Diskussionen zu Erweiterungen für das "Session Initiation Protocol" (SIP). Damit lassen sich künftig zahlreiche Telefonfunktionen, die heute aufwendige TK-Anlagen erfordern, etwa intelligentes Weiterleiten, mit preiswerten IP-Systemen realisieren. (re)