Agile Entwicklungsmethoden haben die Industrie im Sturm erobert. Das liegt hauptsächlich daran, das es einfach funktioniert: höhere Erfolgsraten, bessere Qualität, gesteigerte Kundenzufriedenheit, besseres ROI (Return On Investment) und schnellere Markteinführung (Time To Market).

In diesem Artikel beginnen wir mit einer allgemeinen Betrachtung des Agilen Prozessmodells um die unterschiedlichen Ansätze in den richtigen Kontext setzen zu können. Anschießend betrachten wir das vorgestellte dreistufige Modell genauer und erfahren wie die drei aufeinander aufsetzen. Zum Abschluß wenden wir das Modell beispielhaft auf die Entwicklung einer Software an und enden mit einigen Hinweisen für eine erfolgreiche Einführung agiler Softwareentwicklung.

Das agile Prozessmodell

Im Zusammenhang mit Softwareprojekten und damit verbundenen Prozessen wird immer wieder von Maturity gesprochen. Daß es sich dabei um einen inzwischen überladenen Begriff handelt ist nicht Verdienst der exzellenten Arbeit des Software Engineering Istitute (SEI) der Carnegie Mellon University, die das Capability Maturity Model Integrated (CMMI) entwickelt hat und eine Abwandlung speziell für die Durchführung von Softwareprojekten CMMI-DEV hervorbrachte. Vielmehr wurde der Begriff Maturity auf die Prozessoptimierung angewandt, während das hier vorgestellte Agile Process Maturity Model (APMM) vielmehr bemüht ist, einen Rahmen für die agile Softwarenentwicklung zu stellen, so daß die unterschiedlichen Methoden in den richtigen Kontext gesetzt werden können. Wir könnten auch sagen: das APMM ist das schlanke Geschwister vom CMMI.

Wie angedeutet ist APMM ein dreistufiges Modell dessen Ebenen aufeinander aufsetzen:

Abbildung 1

Die drei Stufen sind folgendermaßen zu verstehen:

Level 3: Scaling Agility

Stufe 3 konzentriert sich auf einen wichtigen Skalierungsfaktor in agilen Prozessen, beispielsweise Teamgröße oder der Grad der geographischen Verteilung des Teams. Es muß sich dabei aber nicht immer um eine quantitative Größe handeln, denn auch der Einfluß von Regulatorien oder der Grad der Einhaltung von Standards sind skalierend Faktoren in agilen Entwicklungsprozessen.

Level 2: Disciplined Agility

In Stufe 2 schauen wir über den Tellerrand hinaus und decken den gesamten Software Delivery Life Cyle (SDLC) ab. Beispiele sind Dynamic System Development Method (DSDM) und OpenUP (Open Unified Process).

Level 1: Agile Software Development

Stufe 1 betrachtet nur einen kleinen Teil des gesamten Entwicklungsprozesses, da nur die agilen Aspekte des Manifestos von Bedeutung sind. Beispiele sind Scrum oder XP.

Das Modell mag zum jetzigen Zeitpunkt noch nicht besonders einleuchtend sein. In den folgenden Abschnitten beleuchten wir jede Stufe genauer und gehen immer wieder auf die Bedeutung im APMM ein.

Stufe 1: Agile Software Development

Die agilen Methoden auf Stufe 1 decken nicht den gesamten SDLC ab, sondern orientieren sich an den Werten des Agile Manifesto und vestehen sich als eine ganzheitliche Sammlung von empfohlenen Vorgehensweisen. Beispiele für die Implementierung der Stufe 1 sind die bekannten Vertreter:

Scrum

Projekt- und Anforderungsmanagement sind die Stützpfeiler von Scrum. Mittels Iterationen (Scrum spricht von Sprints) werden Zyklen zur Produktreifung definiert. Gepaart mit diversen Praktiken wie täglichen Stand-Up Meetings, Verwendung von Product Backlogs und klaren Rollen wie beispielsweise ScrumMaster und Product Owner entsteht ein Planungsgerüst, welches ganz nach Definition durch das Manifesto auf die Erstellung lauffähiger Software ausgerichtet ist. Abbildung 2 zeigt den Scrum Life Cycle.

Extreme Programming (XP)

XP ist eine Sammlung von Praktiken für die Softwareentwicklung, mit Fokus auf Programmiertechniken. Beispielsweise sind Pair Programming (zwei Entwickler an einem Modul gleichzeitig), Test-First Design (erst der Unit Test, dann die Implementierung) und Continuous Integration einige der propagierten Techniken für die Softwareentwicklung mit XP. Darüber hinaus bekennt sich auch XP zu Dingen wie Collective Ownership um die Bedeutung selbstorganisierender Teams herauszustellen.

Agile Data

Datenlastige Anwendungen erfordern oftmals andere Herangehensweisen als beispielsweise Steuerungssysteme. Für solche Fälle eignet sich Agile Data sehr gut, da hier nicht nur die Organisation und Entwicklungstechniken betrachtet werden, sondern auch die Modellierung, Datenbanktest und Database Refactoring.

Abbildung 2

Stufe 2: Disciplined Agility

Auf Ebene zwei wird der agile Prozess von Stufe 1 erweitert und berücksichtigt den gesamten SDLC. Der wesentliche Unterschied zu Stufe 1 ist die Berücksichtigung einzelner Aspekte des Prozesses (nicht der Techniken oder Technologien), beispielsweise Testing oder Process Improvement. Ganz typisch handelt es sich bei Discplined Agility auch um einen evolutionären, iterativen Entwicklungsansatz zur Produktion hochqualitativer Software, der sich durch den Einsatz von Risiko- und Value-Driven Management { Value-driven Managment bedeutet in diesem Zusammenhang, die aktuellen Marktentwicklungen während des gesamten SDLC immer wieder zu bewerten um sicherzustellen, daß ein gewinnbringendes Produkt entsteht, welches auf dem Markt bestehen kann. } auszeichnet.

Disciplined Agility vertraut auf qualifizierte und selbstorganisierende Teams, die von einer frühzeitigen und starken Einbindung der Auftraggeber profitieren. Auf diese Weise kann das Team die Anforderungen des Auftraggebers besser verstehen und auf Veränderungen schneller reagieren. Auf der anderen Seite ist der Entwicklungsprozess transparent und kann jederzeit vom Auftraggeber durch aktive Mitwirkung, beispielsweise in Form häufigen Feedbacks, korrigiert werden.

Beispiele für agile Prozesse der Stufe 2 sind:

Open Unified Process (OpenUP)

OpenUP erweitert und kombiniert bekannte Praktiken aus Scrum, XP, AD und RUP für die Anwendung auf verteilte, virtuelle Teams. Dabei werden Methoden wie Whole Team, Stand-Up Meetings, Risikomanagement, TDD, aktive Einbindung der Auftraggeber und Continuous Integration angewandt. OpenUP ist ein Open Source Framework, das Teil des Eclipse Process Framework ist.

Rational Unified Process (RUP)

RUP ist ein umfassendes Rahmenwerk für Prozesse in der Softwareentwicklung, das unterschiedlich ausgeprägt werden kann, je nachdem wie die es die aktuelle Situation erfordert. Eignet sich für sehr agile wie auch traditionelle Ansätze gleichermaßen. Es deckt die Praktiken Risk Management, Whole Team, TDD, Business Process Sketching und Continuous Integration ab.

Dynamic System Development Method (DSDM)

DSDM eignet sich besonders für Applikationen mit komplexen Benutzeroberflächen. Es ist ein agiler Ansatz, der von Rapid Application Development abgeleitet wurde und sehr stark auf Rapid Prototyping, Testing, Machbarkeitsstudien und Reversible Changes setzt.

Feature-Driven Development (FDD)

FDD zeichnet sich durch den Einsatz von Modellierungstechniken und kurzen Iterationen aus. Zu den typischen FDD-Praktiken gehören Class Ownership (PDF), Domain Object Modeling, Development by Feature, Feature Teams und regelmäßige Übersetzungen der Software (Regular Builds). Eine ausgezeichnete Kurzbeschreibung von FDD findest Du unter The Coad Letter: Issue 70.

Eine akstrahierte Darstellung eines vollständigen SDLC wird in Abbildung 3 dargestellt. Als Beispiel erweitern wir Scrum um wichtige Aspekte des SDLC, denn zum ersten wird eine explizite Projektgründungsphase (Project Inception) allen anderen Aktivitäten vorangestellt, in der wir erste Modelle konstruieren, das Team bilden und die finanzielle wie auch institutionelle Unterstützung des Auftraggebers sichern. Zum zweiten integrieren wir unabhängige Tests, um sicherzustellen, daß Fehler nicht durchs Raster fallen, was insbesondere auf nicht-funktionale Merkmale und Integrationstest zutreffen kann. Die nächste Erweiterung von Scrum betrifft das Product Backlog, das nicht nur priorisierte Aufgabenelemente berücksichtigt, sondern auch Tätigkeiten wie die Teilnahme an Trainings (auch zu fachfremden Disziplinen), Feedback zu Arbeiten anderer Teams und die Bewertung von Fehlern sowie deren Einordnung in das Backlog. Das letzte Merkmal des beschriebenen agilen SDLC ist die ausdrückliche Einführung einer Übergangs- und Produktionsphase (Release to Manufacturing).

Abbildung 3

Stufe 3: Berücksichtigung von spezifischen Faktoren

Zu Beginn der agilen Bewegung wurden die Praktiken zunächst auf kleinere überschaubare Projekte angewandt und relativ pragmatisch angegangen. Heutzutage wenden Organisationen agile Methoden auf ein weitaus größeres Wirkungsspektrum an. Agilität der Stufe 3 berücksichtigt die Komplexität der Projekts in Bezug auf bestimmte Faktoren, die wie Skalierungen angewandt werden können. Folgende Tabelle faßt einige Faktoren zusammen, die Auswirkung auf die Komplexität eines Projekts haben.

Jedem Faktor ist eine Komplexitätsskala zugeordnet und jedes Team wird eine andere Kombination aufweisen, so daß der Prozess, die Teamstruktur und die Werkzeuge den Rahmenbedingungen angepaßt werden müssen. Agile Prozesse der Stufe 1 im APMM funktionieren am besten wenn alle Faktoren in der Skala auf der linken Seite liegen (eine geringe Komplexität aufweisen.) Prozesse der Stufe 2 zeichnen sich durch einen oder mehrere Faktoren aus, deren Komplexität entweder in der Mitte oder auf der rechten Seite der Skala liegen. Liegen fast alle Faktoren auf der rechten Seite wird der Entwicklungsprozess extrem komplex und bedarf spezieller Werkzeuge zur Koordinierung verteilter Teams, Metriken zur Überwachung der Compliance und Berater, die auf beispielsweise auf Risikomangement und andere geschäftsspezifische Disziplinen spezialisert sind.

Während Stufe 1 und Stufe 2 tatsächlich als eigenständige Prozesse charakterisiert werden können, ist die Stufe 3 als Leitfaden für die Bewertung der Projektkomplexität mittels einer einfachen Skala gedacht. Letzendlich wirken sich die Erkenntnisse aus Stufe 3 auf den Prozess der Stufe 2 dahingehend aus, daß bestimmte Schritte/Abläufe unterschiedlich gewichtet sind und einer eigenen internen Analyse unterzogen werden, um dem identifizierten Komplexitätsgrad in diesem Bereich gerecht zu werden.

Was bedeutet das für die Praxis?

In der Praxis wird in fast allen agilen Methoden aus Stufe 1 eine Projektinitiierung durchgeführt, allerdings nicht immer explizit mit der klaren Zielsetzung, die Finanzierung des Projekts zu sichern und ausführlich Zeit für eine Definition der initialen Anforderungen und der gewünschten Vorgehensweise einzuplanen (Länge der Iterationen, Zusammenstellung des/der Teams, Wahl des Prozessmodells, etc.). Es ist nicht unüblich zwischen ein bis zwei Wochen dafür anzusetzen.

Im Idealfall nehmen daran Teil:

• die Auftraggeber: Product Manager/Owner, Business Owner und Process Owner
• die Auftragnehmer: Key Account Manager und Business Consultant, Senior Developers, CTO

An der Zusammensetzung sehen wir schon, daß wir nicht nur das Ziel haben, die Anforderungen zu verstehen, sondern auch Risiken zu minimieren, was primär durch die Vertreter der Auftraggeber garantiert wird, die in diesem Beispiel teilweise redundant sind, dadurch aber jeweils eine eigene Sicht auf mögliche Risiken ermöglichen.

Parallel dazu entwerfen CTO und die Senior Developers eine vorläufige, grobe Architekture, identifizieren Subsysteme und Schnittstellen und tragen wichtige Informationen zur Aufteilung der Arbeit auf das oder die Teams zusammen. Je nach Schwerpunkt des Produkts sind die Business Consultant beispielsweise auf Compliance in regulierten Umgebungen spezialisiert oder sind externe Berater zum Thema Baurecht, weil das Endprodukt eine Software für Ausschreibungen in der Baubranche ist.

Der Product Owner (erfahrungsgemäß oftmals Product Manager des Auftraggebers) priorisiert die Anforderungen und versorgt die Teammitglieder mit Details über Geschäftsprozesse. Er/Sie wird dabei von den Business Ownern und/oder Process Ownern unterstützt.

Nachdem die erste Iteration (Inception) vorbei ist, wird in der zweiten der Fokus auf die Entwicklung eines Proof of Concepts gelegt um zu zeigen, daß die gewählte Architektur tatsächlich funktioniert. Am Ende der Iteration wird dem Auftraggeber das Ergebnis präsentiert, wobei sich das Team hier ausschließlich auf die Demonstration der kritischen Systemeigenschaften konzentriert. Beispielsweise könnte eine kritische Anforderung sein, daß eine Anwendung 5.000 Transaktionen pro Minute bei durchschnittlich zehn angemeldeten Benutzern für mindestens 24 Stunden verarbeiten können muß.

Durch die richtige Wahl der Teammitglieder und einer ausführlichen Projektgründungsphase konnte das Gesamtrisiko des Projekts drastisch reduziert werden, weil zum einen die Anforderungen richtig verstanden wurden und demonstriert werden konnte, daß die kritischste Komponente den ersten Test bestanden hat.

Was die Projektkommunikation betrifft, ist es stets empfehlenswerte eine Single Point of Communication Strategie zu verfolgen. In Bezug auf Projektkoordination, Ressourcenplanung usw. kommunizieren zwischen Auftragnehmer und Auftraggeber lediglich Key Account Manager (Auftragnehmer) und Product Manger (Auftraggeber). Fachspezifische Themen koordiniert die Teamleitung mit den Business Consultants auf Auftragnehmerseite und den Business und Process Ownern auf Auftraggeberseite. Idealerweise, aber praktisch leider kaum durchführbar, sind die Business und Process Owner stets verfügbar und nehmen an täglichen Meetings teil. Besonders in komplexen Projekten mit hohem Risiko ist dieser Punkt obligatorisch.

Technische Fragen beantwortet die Senior Developer und der CTO in täglichen Meetings.

Abschließende Gedanken

Viele Organisationen konnten ihre agilen Prozesse erfolgreich skalieren (Stufe 3) und Du kannst es auch. Wenn Du Dir treu bleibst und nicht der Rhetorik der Vertreter aus Stufe 1 erliegst ist das schon ein wichtiger Schritt. Du solltest versuchen, mindestens einen agilen Prozess der Stufe 2 zu etablieren, da der gesamte SDLC berücksichtigt wird und nicht nur ein Teil davon (nur die Konstruktionsphase). Sei darauf vorbereitet, daß Du Dich über kurz oder lang in einer Situation befinden wirst, in der Dein Prozess skalieren muß (Stufe 3) und das viele Teams unterschiedlich skaliert werden müssen. Mit einem realistischen, maßgeschneiderten Ansatz kann der ROI gesteigert, die Qualität erhöht und die Kundenzufriedenheit maximiert werden.

Der Übergang zu agilen Methoden fordert unsere eingeschliffene Wahrnehmung von der Disziplin des Software Engineering, und damit verbunden auch Managementmethoden und Führungsstile, heraus. Agilität wirkt sich auf alle Rollen eines Teams unterschiedlich aus und eröffnet die Gelegenheit auf völlig neue Art und Weise zusammenzuarbeiten.

Besonders für Projektmanager ändert sich die Methodik im agilen Umfeld. Agilität erfordert ein völlig neues Framework für das Zeitmanagement, Kostenberechnung und Anforderungsmanagement. Zusätzlich wird des Projektmanagers Liebling, die Vorhersehbarkeit des Projektablaufs, stark strapaziert, denn nun heißt es: Embrace Change! {Ron Jeffries}. Risikomanagement wird nun unmittelbar von der Auslieferung lauffähiger Software bestimmt. Zusammenarbeit, Förderung individueller Stärken, ein serviceorientierter Führungsstil, Coaching und die Teamzusammenstellung sind essenzielle Fähigkeiten, die Projektmanagern helfen, agile Teams effektiv und zielgerichtet zu führen.

Mit diesen zusätzlichen Fähigkeiten ausgestattet, lernen agile Projektmanager wie sie in einer ungewissen und sich ständig ändernden Welt noch besser zur Wertschöpfung beitragen können.

Traditionelles Projektmanagement

Die meisten traditionellen Projekte betrachten den Gültigkeitsbereich (engl. Scope) als wichtigstes Abgrenzungskriterium eines Projektes. Oftmals tritt der Scope in Form einer langen List mit Produktanforderungen in Erscheinung.

Projektmanager arbeiten evtl. mit Ressource Managers zusammen um Abschätzungen für jeden funktionalen Bereich zu ermitteln, der von den Anforderungen betroffen ist. Diese Abschätzungen werden in der Regel in Arbeitsstunden oder -tagen dokumentiert, ohne genaue Informationen über die eigentliche Implementierung der Anforderungen. Anschließend werden daraus die notwendigen Personentage, Ressourcen und andere Faktoren abgeleitet, so dass davon wiederum eine Kostenschätzung hergeleitet werden kann. Das wir davon aber weit entfernt sind, wird in den folgenden Ausführungen deutlich.

Am Anfang des Projekts verfügt das Team über wenig verwertbare Informationen über die Quantität der notwendigen Arbeit. Gleichermaßen weiß auch das Projektmanagement nicht genau, welche Teammitglieder welche Aufgaben erledigen werden oder wie die Ressourcen allgemein auf das Projekt optimal verteilt werden können.

Mit nur sehr wenigen Informationen über die tatsächliche Lösung (das Produkt) und über die Arbeitsaufteilung ist es fast unmöglich eine zuverlässige Aussage über ein Fertigstellungsdatum zu treffen. Projektmanager erstellen Projektpläne auf diesen unvollständigen Informationen und geben ihr bestes, das Projekt nach diesem vom Auftraggeber abgesegneten Plan abzuwickeln.

Diese Herangehensweise hat sich in der Vergangenheit nicht als zuverlässige Methodik zur Abschätzung von Projektdauer, -größe und -kosten bewiesen. Was die Sache noch schlimmer macht ist die Tatsache, dass von der Annahme einer absoluten Sicherheit über die Vollständigkeit, Korrektheit und Unveränderlichkeit der Anforderungen ausgegangen wird und die Methodik Veränderungen gar nicht vorsieht.

Agiles Projektmanagement kurz und knapp

Agiles Projektmanagement geht von der Prämisse aus, das Softwareprojekte unvorhersehbar sind und dass Marktveränderungen zu unmittelbaren Korrekturen der Anforderungen an das Produkt führen. Die Ungewissheit über Marktentwicklungen führt automatisch zu veränderten Anforderungen während der gesamten Laufzeit des Projekts, und je unsicherer die Entwicklungen sind, desto besser muss das Team darauf eingestellt werden.

Aus diesen Gründen ist der Scope eines Projekts ein denkbar schlechter Ausgangspunkt für die Planung von Softwareprojekten und Erhebung von Leistungskennzahlen eines solchen. Stattdessen geht die Planung agiler Projekte von den beiden Faktoren Zeit und Kosten aus, da diese beiden Rahmenbedingungen meist zu Beginn des Projekts feststehen. Die Auftraggeber wissen in der Regel wie viel Geld sie in das Projekt investieren möchten und wann es spätestens einsatzbereit sein muss.

Anforderungen werden in agilen Projekten in kleine Häppchen des antizipierten Endprodukts aufgeteilt, und möglichst unabhängig voneinander herausgelöst, so dass sie einzeln priorisiert und implementiert werden können, ohne sich an eine bestimmte Reihenfolge halten zu müssen. Kleine überschaubare, unabhängige Module sind kritisch für die Fähigkeit mit Veränderungen im Projektverlauf fertig zu werden, ohne dass sie besondere Auswirkungen auf das Projektteam nach sich ziehen.

Innerhalb von zuvor vereinbarten Iterationen, meist in einer länge zwischen zwei und vier Wochen, werden immer wieder Häppchen aus dem Backlog realisiert, so dass nach einer Iteration andere Features nachrücken und ggf. wieder neu priorisiert werden können.

Agile Teams stellen nun langsam fest, wie viele dieser Fragmente sie innerhalb einer Iteration fertigstellen können und verstehen dadurch wie viele der Anforderungen des Projekts sie innerhalb des Budgets und Zeitplans realisieren können.

Agile Projektplanung

Projektmanager agiler Teams befassen sich primär mit zwei Leistungsindikatoren: die Größe des Backlogs und Velocity. Das Product Backlog ist die Liste der Anforderungen an das Endprodukt. Es besteht meist aus einer priorisierten Ansammlung von Features, die das Team sofort umsetzen kann. Die einzelnen Positionen eines Backlogs wurden entweder in Stunden, Tagen oder abstrakten Maßeinheiten, wie Story Points, abgeschätzt. Die Zahl aller Elemente ist die Gesamtgröße des Product Backlogs.

Velocity beschreibt wie viele Elemente des Backlogs vom Team innerhalb einer Iteration erledigt werden konnten. Diese Größe kann über ein festgelegten Zeitraum gemessen werden und repräsentiert den Durchsatz des Teams oder die Geschwindigkeit in der das gesamte Backlog abgearbeitet werden kann. Das Fertigstellungsdatum wird durch eine einfache Formel berechnet:

Iterationen bis zur Fertigstellung = Größe des Backlog / Dauer einer Iteration

Die ideale Geschwindigkeit (ideal Velocity) ist der Durchsatz welcher notwendig ist, um das Backlog vollständig innerhalb des vorgegebenen Zeitraums und der angesetzten Kosten umzusetzen. Die eigentliche Geschwindigkeit ist der wahre Durchsatz des Teams in jeder Iteration. Die Differenz zwischen der idealen und der eigentlichen Geschwindigkeit ist der wichtigste Indikator über den Projektfortschritt in Relation zu den Erwartungen des Auftraggebers. Je dichter die beiden Größen bei einander liegen umso wahrscheinlicher ist es, dass das gesamte Product Backlog termingerecht realisiert werden kann.

Teams mit vorhersagbarem Durchsatz können eine durchaus fundierte Vermutung über einen möglichen Fertigstellungstermin anstellen. Wenn Zeit und Kosten unveränderliche Größen sind, kann die Anzahl der umgesetzten Features innerhalb dieser Grenzen abgeschätzt werden.

Teams mit schwankendem Durchsatz sind nicht vorhersehbar und führen in der Regel zu unterschiedlichen Ergebnissen bei der Projektabwicklung. Das konstante Beobachten des Durchsatzes erlaubt Projektmanagern viel über das Team zu lernen und zu erfahren wie bestimmte Ergebnisse bei der Projektabwicklung zustande kommen.

Agile Teams führen

In agilen Projekten übernimmt das Team die Verantwortung für die Auslieferung und sollte daher die notwendigen Freiheiten erhalten, dies es benötigt um sich selbst bestmöglich zu organisieren. Das Team kann autonom entscheiden wie es die Arbeit erledigen möchte. Agile Projektmanager können das Team unterstützen indem Sie die Entscheidungen neutral bewerten und dem Team mitteilen, ob es mit diesem Ansatz erfolgreich ist oder eher nicht.

Um die Wahrscheinlichkeit einer erfolgreichen Projektabwicklung zu unterstützen können Projektmanager den Kontext des Projektes aktiv gestalten. Sie können die Umgebung des Teams verändern, die Entscheidungsfindung im Team fördern und Autonomie zusagen wann immer möglich. Agile Projektmanager gehen von den besten Qualitäten der Teammitglieder aus, gehen auf individuelle Stärken ein und respektieren das Team als gleichwertiger Partner. Sie helfen die Kultur zu verändern und fördern ein gesundes Arbeitsklima.

Die Autonomie kommt mit einem Preisschild und das heißt häufige Produktveröffentlichungen. Das Team bekennt sich am Beginn einer jeden Iteration zu einem gemeinsamen Ziel und ist auch selbst verantwortlich für die Einhaltung desselben. Es ist für agile Projektmanager unabdingbar im Team eine Kultur der Selbstverantwortung zu bilden und mit dem Team kontinuierlich daran zu arbeiten. In diesem Aspekt ist der Projektmanager verantwortlich, Policies, Prozeduren und Metriken zu etablieren, die die Gesamtleistung der Projektabwicklung steigern.

Zusammenarbeit mit agilen Teams

Nicht jedes Team wird einen dedizierten Projektmanager benötigen. Viele agile Teams tragen einem oder mehreren Teammitgliedern diese Rolle an, sofern sie qualifiziert sind und über ausreichend Kapazitäten zur Wahrnehmung der Doppelrolle verfügen. Ein Mitglied der Entwickler oder ein Product Owner kann als PM für kleine Teams fungieren.

Ein Projektmanager wird nicht selten beauftragt die Lücke zwischen dem Team und dem Auftraggeber auszufüllen oder Aktivitäten außerhalb des Teams zu organisieren und zu verwalten. Desweiteren werden sie häufig in agilen Teams benötigt, um Kommunikationspläne zu erstellen oder die Zusammenarbeit zwischen mehreren agilen Teams zu koordinieren.

Der Projektmanager muss immer bemüht sein, ein gleichwertiges Mitglied des Teams zu sein und andere Mitglieder bei der Erstellung von Plänen und anderen Tätigkeiten einzubinden. Auf diese Weise wird eine solide Basis für eine vertrauensvolle Zusammenarbeit und hohe Integrität des Teams geschaffen.

Jede Iteration beginnt mit intensiven Sitzungen gefolgt von ad-hoc-Interaktionen zwischen Teammitgliedern. Projektmanager können das Team bei der Selbstfindung unterstützen in dem sie es bei der Planung der Ziele einer Iteration konstruktiv beraten, so dass sie realistisch sind und auf Basis eines vertretbaren Durchsatzes eingestuft wurden. Die Übernahme der Leistungsüberwachung innerhalb und zwischen den Iterationen ist eine weitere Tätigkeit für Projektmanager, damit das Team mehr Zeit für die Abarbeitung des Product Backlog hat.

Die meisten agilen Ansätze definieren eine Rolle des Projektmanagers nicht explizit. In Scrum, beispielsweise, werden viele typtische Zuständigkeiten eines Projektmanagers auf den ScrumMaster und den Product Owner verteilt. Die Rollen innerhalb des Projektteams zu identifizieren und Verantwortlichkeiten zu definieren ist die wichtigste Aufgabe des Projektmanagers, insbesondere wenn er sich in ein bestehendes Team integrieren muss.

Neue Fähigkeiten für Projektmanager

Ein agiler Projektmanager muss viel mehr Führungsqualitäten aufweisen als in traditionellen Projekten. Seine Aufgabe ist es, die Kommunikation zwischen den Teammitgliedern zu fördern, die Motivation zu steigern, und organisatorische Hindernisse zu beseitigen, die einer erfolgreichen Projektabwicklung im Wege stehen könnten. Dazu gehört auch, das Team einfach Team sein zulassen, es autonom im eigenen Interesse entscheiden zu lassen. Neben diesen Soft Skills müssen Projektmanager den gesamten Prozess der Softwareentwicklung in einem neuen Licht betrachten.

Agilität erlaubt dem Projektmanager, sich von den ganzen vielen kleinen Details der Produktlösung wie beispielsweise Implementierungsdetails zu entfernen und sich auf Techniken wie rollierende Planung{zeitlich nahe Fakten sind deutlicher erkennbar als weit entfernte Fakten; die Planung kann somit nur über ein paar Wochen, höchstens zwei Monate erfolgen} und progressive Elaboration {Arbeitspakete werden im Laufe der Zeit immer weiter verfeinert, so dass wir bei der Planung von zunächst grob abgezeichneten Arbeitspaketen ausgehen} konzentrieren um Projektpläne zu definieren. Auf Seite des Auftraggebers führt das oft zu Irritationen, da sie in der Regel gewohnt sind, bereits zu Projektbeginn über alle Details, wie Kosten, Zeit und Umfang, vollständig informiert zu sein. Projektmanager müssen lernen wie progressive Elaboration Risiken minimieren und die Erfolgschancen eines Projekts steigern kann. Ein solides Verständnis über die agile Softwareentwicklung hilft Projektmanagern zu verstehen, wie agile Teams optimal organisiert, welche Fähigkeiten benötigt werden und welche Besonderheiten agile Teams auszeichnen.

Die Dynamik und kollaborative Entscheidungsfindung agiler Teams zu verstehen ist wichtig, den agiles Projektmanagement heißt sich selbstorganisierende Teams zu führen. Projektmanager nehmen hier in erster Linie die Rolle eines Dienstleisters und Mediatoren an und müssen in der Lage sein, das Team zu motivieren eigene Entschlüsse zu fassen. Mit diesen Fähigkeiten sind Projektmanager in der Lage, Anregungen aus dem Team und anderer Beteiligter zu akzeptieren und gleichzeitig das Bekenntnis zum Projekt zu steigern.

Traditionelle Projekte in neuem Gewand

Zwar ist der Übergang zu agilen Methoden nur selten einer Entscheidung des Projektmanagers zu verdanken, allerdings gibt es vieles was er beisteuern kann, um dem Unternehmen zu zeigen wie wertvoll agile Methoden sein können.

In traditionellen Projekten erstellt der Projektmanager einen Projektplan, der beschreibt, wie das Projekt abgewickelt wird. Oftmals geschieht das nach dem Vorbild des PMBOK (PMI Project Management Body of Knowledge) oder anderen PM-Frameworks. Auch wenn es sich bisher nicht so angehört hat, kann vieles in agilen Projekten anhand traditioneller Frameworks beschrieben werden. Diese Ansätze können oftmals in den Kontext einer traditionellen Projektplanung integrierte werden.

Oftmals sind Projektmanager mit der Aufgabe betraut, spezifische Aktivitäten während des Projektablaufs zu beobachten und zu beurteilen. Work Breakdowns, beispielsweise, sollen in der Regel auf Ergebnissen und nicht auf Aktivitäten beruhen. PMs können diese Breakdowns einfließen lassen in dem sie einfach die Features des Product Backlog berücksichtigen. Auf diese Weise können traditionelle Methoden zur Abschätzung beibehalten werden.

Desweiteren sind Gantt-Diagramme des traditionellen Projektmanager’s Liebling. Manche Organisationen setzen die Erstellung eines Gantt-Diagramms als Teil des Projektplans bereits vor Projektstart voraus. Iteratives Planen mit dem Projektteam hilft, den Projektplan mit dem Team zu synchronisieren. Die Erkenntnisse aus der Iteration können in den nächsten Planungsworkshop einfließen und den Projektplan weiter verfeinern.

Tägliche Projektmeetings sind in agilen und traditionellen Projekten gleichermaßen etabliert, besonders wenn Projekte mit außerordentlich hohem Risiko realisiert werden. Diese täglichen Prüfpunkte erhöhen die Sichtbarkeit zwischen Teammitgliedern und erlauben dem Projektmanagement einen Echtzeiteinblick in den Projektfortschritt. Diese Meetings können die Bindung im Team fördern und die Übernahme einer gemeinsamen Verantwortung für das Projekt bewirken.

Fazit

Die richtigen Produkte schneller auf den Markt zu bringen als die Konkurrenz ist kritischer als je zu vor. Traditionelle PM-Frameworks sind nicht flexibel genug, um mit sich ständig ändernden Rahmenbedingungen zu Recht zukommen. Die Agile Projektabwicklung erlaubt Teams Produkte auszuliefern, die innerhalb des Budgets und des Zeitrahmens liegen und die wichtigsten Features des Auftraggebers beinhalten.

Die Projektmanager können dabei eine Schlüsselrolle spielen. Allerdings müssen sie ihre Denkweise hinsichtlich der Zeit-, Kosten- und Ressourcenplanung ändern um mit Ungewissheit, Veränderungen und Risiken fertig zu werden. Sie müssen neue Fähigkeiten verinnerlichen und neue Ansätze zur Planung, Überwachung und zum Controlling von Projekten erlernen. Gut ausgebildete Projektmanager setzen den Rahmen für erfolgreiche Projekte und Teams liefern sie.

Für eine erfolgreiche Umsetzung müssen Service Provider:

• Dienste schneller auf den Markt bringen und dabei die Flexibilität erhöhen.
• Quality-of-Service für IPTV und VoIP etablieren
• hohen Multicast-Durchsatz für IPTV

Glücklicherweise halten diverse Techniken, wie Hochgeschwindigkeits-Ethernet, Aggregation und Management-Plattformen Einzug in das Portfolio der Betreiber, so daß FTTH-Dienste (Fiber to the Home) leichter zugänglich werden.

In diesem Artikel beleuchte ich die neuen Anforderungen an die Ethernet-Technologie und zeige wie sie verarbeitet werden.

Was ist Tripple-Play?

Tripple-Play sind multimediale Dienste, die von Netzbetreibern, Telekom-Gesellschaften, Kabelnetz-Betreibern und Internet-Providern angeboten werden. Es handelt sich um das kombinierte Angebot von Telefon, Fernsehen und Internet, basierend auf dem Internet-Protokoll (IP), unter Benutzung breitbandiger Zugangsnetze.

Bandbreitenanforderung im Zugangsnetz, nach DSL-Forum und MPEG Industry Forum.

Durch die größere Bandbreite der DSL-Verfahren, insbesondere von ADSL2+ und VDSL2, und durch die rückkanalfähigen Kabelverteilnetze, setzen die Provider zunehmend auf Double- und Triple-Play-Angebote. Zu diesem gebündelten Dienstangebot gehören die Internet-Telefonie mit VoIP, das Internet-Fernsehen (IP-TV) mit interaktivem Fernsehen und interaktiven Videodiensten wie Video-on-Demand, Videokonferenzen und Telearbeit sowie der Internet-Zugang.

Je nach Dienstnutzung sind für Triple-Play-Dienste im Downstream Datenraten zwischen 10 Mbit/s und 28 Mbit/s erforderlich und im Upstream etwa 3 Mbit/s.

Tripple-Play bezeichnet im Kern den Einsatz einer Zugangstechnologie für drei Geschäftsbereiche: das Wohnungswesen, MANs (Metropolitan Area Networks) und Service Provider.

Im Wohnungswesen

• Attraktivitätsgewinn des Wohnraumes
• langfristige Steigerung des Wohnwertes
• Bedarfsgerechte und innovative Technik für die jüngere Klientel
• nachhaltige Verringerung des Leerbestandes
• Dienstleistungserbringung für z.B. betreutes Wohnen
• Sicherheit und Objektschutz steigern bzw. gewährleisten
• Kostenreduzierung der eigenen Aufgaben und Leistungen
• Schnelles Return of Invest

Für Metropolitan & Service Provider

• Hochverfügbare Backbone-Ringstruktur (Core) mit fehlertolerantem EAPS
• Basierend auf Standard Ethernet-Architektur (zukunftssicher und skalierbar)
• Aufbau eigener Infrastruktur
• Alle Dienste wie Video, Daten und VoIP?aus einer Hand
• Technologische Vorteile im Verdrängungswettbewerb
• Provisioning & Mediation (Zentrale Konfiguration und Schnittstelle zum Abrechnungssystem)

Anforderungen an FTTH Tripple Play

Die Anwender von Tripple-Play-Diensten werden hohe Anforderungen an die Qualität stellen. Gary Holland, Carrier Ethernet Marketing für Lucent Technologies, spricht von dem Kunden als Netzwerkmonitor:

Wenn ein Netzwerkproblem ein kleines Darstellungsproblem während eines Fußballspiels verursacht, mag das ein Konsument eher lästig finden. Doch wenn ein Netzwerk ausfällt oder gar heftige Darstellungsprobleme auftreten und der Fußballfan deshalb das entscheidende Tor verpaßt, laufen die Telefone der Service Provider heiß und der Konsument wendet sich im schlimmsten Fall ab.

Das bedeutet, ein Netzwerk muss fehlerfrei laufen, daß sich aber im Fehlerfall schnell und zuverlässig korrigiert. Auf Seiten der Service Provider steht die Steigerung des Gewinns pro Benutzer im Vordergrund, da die Betriebskosten mit steigender Benutzerzahl wachsen. Aus dieser Sicht kristalisieren sich vier Schlüsselanforderungen heraus:

• Interaktive Dienste und voluminöse Inhalte führen zu neuen Anforderungen im Bereich der Netzwerkzugänge und der Netzinfrastrukturen. Dazu gehört unter anderem die Bereitstellung von mehr Bandbreite, Ausprägung differenzierter Dienste für unterschiedliche Angebote und eine hohe Innovationskraft und damit auch die schnelle Markteinführung derselben.
• Belastbare Kontrollstrukturen und ausgereiftes Netzwerkmanagement wird benötigt.
• Zuverlässiges Quality of Service (QoS), ein hohes Maß an Skalierbarkeit und Sicherheit müssen auf Aggregationsebene eingeführt werden.
• Netzbetreiber benötigen mehrere Netzwerkzugangsoptionen wie beispielsweise PON (Passive Optical Networks) und aktives Ethernet.

Anforderungen an Tripple-Play aus Sicht der Abonnenten und der Service Provider.

Grundlage zur Erfüllung dieser Anforderungen ist die Verfügbarkeit ausreichender Bandbreite. Die Frage ist nun: wieviel ist ausreichend? Die Frage ist eine Schlüsselfrage für Tripple-Play-Dienste, da unterschiedliche Technologien jeweils nur begrenzte Bandbreiten verarbeiten können.

Momentan kann über diese Frage kaum eine zuverlässige Aussage getroffen werden, da nicht klar ist, wie viele Gigabits pro Sekunde für zukünftige Anwendungen, wie etwa 3D-Holoprojektionen, benötigt wird. Bei Tripple-Play geht man von einer geschätzten Gesamtbandbreite von etwa 34 bis 38 Mbps für den Downstream und etwa 3 Mbps für den Upstream aus.

Aktives und Passives FTTH-Ethernet

Tripple-Play über Ethernet-FTTH kann über mehrere Zugriffstechnologien abgewickelt werden, allerdings scheinen aktives Ethernet und eine der Formen von PONs prädestiniert zu sein. Obwohl PONs ihre Wurzeln in ATM haben, basieren neuere Entwicklungen auf Ethernet. Abbildung 3 illustriert beide Ansätze.

Aktives Ethernet verfügt über dedizierte Bandbreiten und ein ausgelagertes aktives Gerät, welches aus Low-Cost-Elementen aufgebaut ist. Der Abonnent verbindet sich in der Regel über eine 100-Mbps-Verbindung mit einem Ethernet-Aggregations-Switch, der wiederum über Gigabit-Ethernet an einen Ethernet-Router angebunden ist.

Im Gegensatz dazu verwendet ein PON passive optische Splitter (passiv, da ohne Stromversorgung), die es erlauben eine einzige Glasfaser an mehrere Abnehmer zu verteilen, in der Regel nicht mehr als 32 aber auch bis zu 64. Dieser Broadcast-ähnliche Betriebsmodus hat zur Folge, daß die Bandbreite unter den Abnehmern verteilt werden muß, so daß tatsächliche Bandbreiten pro Abnehmer von etwa 19 bis 35 Mbps möglich wären. Das Glasfasersegment wird normalerweise von einer Optical Network Unit (ONU), die sich am Standort des Kunden befindet, terminiert. Verbunden ist das Segment allerdings durch einen optischen Splitter mit einem optischen Line Terminator (OLT), der an einen Switch, wahlweise ATM oder Ethernet, angeschlossen ist. Dieser liefert letztendlich den Zugang zum aktiven Netzwerk des Service Providers.

Beide Anwendungen haben Vor- und Nachteile. Beispielsweise benötigt aktives Ethernet ein zusätzliches, externes Gerät mit Stromversorgung, wie etwa lokale Aggregations-Switches, die in kleinen Telefonzellen-artigen Gehäusen das Stadtbild prägen. Diese Switches müssen auch aktiv gewartet werden. Andererseits weisen sie alle Eigenschaften eines Carrier-Ethernets auf: Bandbreitenanpassung, hohe Reichweiten, Fehlerisolierung, Sicherheit, etc. Momentan werden einige Anstrengungen unternommen, um die Anforderungen an die Stromversorgung zu verringern.

Der große Vorteil von PONs ist das passive externe Gerät, allerdings wird die Einzeltrennung der Abnehmer dadurch nahezu aufgehoben. Desweiteren sind Reichweitenbeschränkungen, Sicherheitsfragen und problematische Fehlerisolation und das Management der passiven Komponenten wichtige Nachteile, die gegen PONs sprechen.

Aggregation, VLANs und MPLS

Geht ein Service Provider den Ethernet-Weg, so stellt sich ihm eine interessante Frage: Sollte MPLS vom Kernnetzwerk in das Zugangsnetzwerk beispielsweise bis zum Abnehmer selbst erweitert werden? Prinzipiell würde das zu einer einheitlichen Basis für QoS, das Traffic Management, Redundanz und Skalierbarkeit über weite Teile der Infrastruktur führen.

Die meisten Service Provider setzen auf VLANs, mit all den bekannten Einschränkungen. Der Grund dafür sind die Kosten, doch scheinen es die gefühlten Kosten für die Einführung von MPLS sein, die die Provider daran hindert MPLS einzuführen, allerdings macht MPLS, eingesetzt in der gesamten Infrastruktur des Providers, weitaus mehr Sinn. Tabelle 1 vergleicht einige MPLS- und VLAN-Charakteristika.

Andererseits muß es gar nicht mal notwendig sein, MPLS in diesem Maße zu verwenden, gerade im Hinblick auf die ansteigende Komplexität. Es kann schon genügen, die neuesten Erweiterungen der Ethernet-Technologie auszuschöpfen. Ethernet-Switches sind heutzutage weitmehr als nur einfache Layer-2-Switches. Sie kombinieren QoS-Fähigkeiten mit Aggregationsfunktionen sodaß ein Aufsetzen auf Ethernet weitaus ökonomischer sein kann als die Einführung von MPLS.

Im Endeffekt kommt es aber auf die Bedürfnisse des Service Providers an. Wurde bereits schwer in MPLS für das Kernnetzwerk investiert, so ist die Ausdehnung der Technologie auf weitere Teile des Netzwerkes durchaus eine kluge Option. Für Betreiber jedoch, die noch keine MPLS-Investitionen getätigt haben eignet sich eine neue Herangehensweise, die als MAC in MAC genannt wird. Dabei handelt es sich um den 802.1ah-Standard mit der Bezeichnung Provider Backbone Bridges Standard, der es erlaubt Ethernet-Netzwerke auf bis zu mehrere Millionen VPNs zu skalieren während alle Vorzüge des Ethernets bestehen bleiben. Das Prinzip wird in Abbildung 4 dargestellt.

Ethernet-Netzwerke mit MAC in MAC skalieren

FTTH Ethernet-Dienste

Unabhängig davon, ob ein Service Provider auf aktives oder passives Ethernet setzt, FTTH wirft einige ernste Probleme beim Handling der Dienste beim Abhnehmer, beispielsweise IPTV, VOIP und Hochgeschwindigkeits-Internet auf. Wie bereits eingangs bereits erwähnt, schlagen folgende Punkte auf:

• Steigende komplexität und erhöhte Kosten
• Sicherstellung der Kontinuität der Dienste
• Fehlersuche im Fall einer Störung

Steigende komplexität und erhöhte Kosten

Mehrere Dienste über ein und dasselbe Netzwerk abzuwickeln geht einher mit steigender Komplexität auf Seiten des Service Providers und führt damit auch zu nicht unerheblichen Kostensteigerungen. In einer offenen Umgebung oder in einer solchen, in der mehrere Provider Komplettpakete anbieten, ist die Integration der jeweiligen Dienste in ein Netzwerk noch schwieriger. Das alles macht die Sache nicht einfacher und sieht nicht nach Kostenminimierung aus. Ergo: Netzwerke müssen klüger werden.

Automatisierung ist der Schlüssel auf dem Weg zur Kosteneffizienz. Beispielsweise müssen Anderungen der Service-Profile an einer Stelle auf mehreren Instanzen repliziert werden können, und das bitte schön automatisch. Für Ethernet FTTH bedeutet das:

• Automatisierte Bereitstellung (Replikation) geänderter Dienstprofile.
• Automatische Upgrades von Netzwerksoftware und Konfigurationsdaten. Damit wird vermieden, teuer geschulte Fachkräfte zu beschäftigen Routine-Aufgaben zu erledigen. Stattdessen werden die erforderlichen Daten von zentraler Stelle verteilt und automatisch eingepflegt.
• Kosteneffiziente Dienstregistrierung, die automatisch an Netzwerkgeräte übermittelt wird. Auf diese Weise kann ein Kunde Dienste über Web-Portal anfordern und die Geräte setzen die notwendigen Konfigurationen automatisch um.
• Ein flexibles QoS-Management und erweiterte Filter für die TV-Verteilung.
• Automatische Benutzerauthorisierung sobald ein Client in das Netzwerk eintritt. Das ist besonders in offenen Zugangsnetzwerken wichtig, da mehrere Provider die gleiche Infrastruktur nutzen können und die Anwender nicht jedesmal die Dienste manuell auswählen wollen.

Sicherstellung der Kontinuität der Dienste

Wir gehen davon aus, daß ein Provider ein Geschäftsmodell basierend auf flexiblen, konkurrenzfähigen kombinierten Dienstpaketen wählt. Da die Durchsetzung eines Preises sehr stark von der Qualität der Dienste und deren Zuverlässugkeit abhängt, besteht ein Wettbewerb gerade im QoS-Bereich, und das für jedes Element im Paket des Anbieters, denn Kunden neigen zur Ablehnung des gesamten Pakets durch das Versagen eines Dienstes.

Die Sicherstellung von Diensten beginnt mit der Überwachung von Netzwerk- und Dienst-Performance auf dem MPLS-Layer und dem IP-Kernnetz. Diese Überwachung beginnt am Netzzugang und hört an der Türschwelle des Abnehmers auf. Nur so erhält der Netzbetreiber eine nützliche und exakte Einsicht in Leistungsdaten und kann so richtige Entscheidungen im Hinblick auf QoS-Metriken des betreffenden Dienstes treffen.

Fehlersuche im Fall einer Störung

Besteht ein Problem im Netzwerk selbst, kommen die Fähigkeiten des Troubleshootings von Ethernet ins Spiel, was früher noch undenkbar war. Inzwischen hat sich auch Ethernet weiter entwickelt und die 802.1ag Configuration Fault Management Standards bieten inzwischen Ethernet-Ping- und -Traceroute-Fähigkeiten mit, die eine Fehlersuche auf Layer 2 erheblich vereinfachen.

Abbildung 5 listet die unterschiedlichen Verwaltungsdomänen (Maintenance Domains) der Standards auf. Darin enthalten sind Ende-zu-Ende-Prüfungen enthalten, die mittels Ping und Traceroute auch von Kundenseite aus initiiert werden können. Weiterhin gibt es eine Provider-Domäne, die mehrere Betreiber umfassen kannund es gibt eine Betreiberdomäne für die Fehlersuche in großen Layer-2-Netzwerken erleichtert.

Fehlersuche in Ethernet-Netzwerken

FTTH Ethernet-Architekturen

Versuchen wir einige der vorangegangenen Erkenntnisse zusammenzufassen. Abbildung 6 zeigt eine typische aktive Ethernet FTTH-Architektur, die für die Auslegung von Tripple-Play-Diensten konzipiert wurde. Links sind die Abnehmer mit Gateways, die mit 100 Mbps Ethernet über Glasfaser an einen Access-Router des Netzbetreibers verbunden sind. Dieser Router befindet sich normalerweise in unmittelbarer Nachbarschaft zu den Abnehmern. Der Access-Router, welcher an ein Ethernet-Aggregation-Netzwerk anschließt, wird mit einem oder mehreren Gbps angebunden. Das Ethernet-Aggregation-Netzwerk kann über ein MPLS-Kern auf einen zentralen POP (Point of Presence) geschaltet werden, der rechts in Abbildung 6 gezeigt wird.

Tripple-Play-Architekturen

Gigabit-Ethernet-Aggregation bedeutet, daß auch relativ große Entfernungen überbrückt werden können, teilweise Ausdehnungen über mehrere Städte. Ein prominentes Beispiel dafür ist UTOPIA, die Utah Telecommunication Open Infrastructure Agency, deren Netzwerk mehr als 14 Städte in Utah mit einer Nordsüdausdehnung von etwa 100km umfaßt.

In der Zentrale befinden sich B-RAS, Radius DHCP-Server und mehrere Router, die den Zugang ins Internet und anderen Netzwerken ermöglichen (dargestellt durch die braunen und orangen Linien, die zu ISP A und zu ISP B verbinden). Auf diese Weise haben Kunden zugriffe auf Dienste und Netzwerke anderer Betreiber.

Innerhalb der Architektur werden Anfragen der Abnehmer normalerweise auf VLANs gemappt, aber immer nur ein VLAN für jeden Dienst. Jedem VLAN ist außerdem eine Dienstklasse für QoS zugeordnet, do daß die entsprechende Bandbreite zur Verfügung gestellt werden kann. All das wird durch das zugrundeliegende MPLS-Netzwerk möglich.

Jedes dieser VLANs (eines pro Dienst) wird anschließend in eine VPLS-Instanz (Virtual Private LAN Service) mittels eines Ethernet-Routers des Betreibers am POP aufgeschaltet. Diese VPLS-Instanz wird über den MPLS-Kern in den Ethernet-Access-Router im FTTH-Netzwerk geschaltet, der sie zum entsprechenden Abnehmer transportiert. VPLS basiert auf MPLS, so daß die gewünschten Ende-zu-Ende-Charakteristika auch für FTTH-Dienste zur Verfügung stehen.

In dieser Art Netzwerk spielt Multicasting eine herausragende Rolle und es gibt verschiedene Architekturen zur Auslieferung von Multicast-Diensten. In diesem Beispiel behandeln die Ethernet-Router des Betreibers den Multicast-Traffic um den Dienst an den Abnehmer zu übermitteln. In anderen Netzwerken ist es durchaus möglich, Layer-2-Netzwerke zur Auslieferung der Daten zu wählen um sie dann auf Layer-3-Multicasting umzulegen. In beiden Szenarien ist die Infrastruktur auf MPLS angewiesen, damit QoS usw. implementiert werden können.

Differences Between Processors

Good news for consumers are often bad news for system developers. The introduction of a new processor architecture or a completely new programming model is usually of great benefit to users but will most likely require large amounts of work for a successful transition to a new technology, especially for developers. They are faced with problems and obstacles that are directly associated with the computer processor design such as storage requirements (e.g. data alignment, byte order, etc.). In this section we will take a brief look at some crucial issues we will encounter when moving to another processor or computing architecture.

Alignment of Data

Almost every processor requires a certain alignment of data in memory. When accessing n bytes of data in memory the starting address of the memory location must be a multiple of n. Unfortunately, processors have different requirements for memory access. Intel’s x86 architecture allows unaligned access which results in a significant performance penalty. RISC processors on the other hand do usually not allow unaligned memory access. They answer with a processor fault to such an operation that is either handled by a software trap or simply causes a system crash. (Sometimes unaligned access is handled completely by software and is therefore extremely slow.)

Byte Order

Depending on the architecture two ways of data representation are in use indicating the byte order within the data type: little endian and big endian. Little endian architectures (like Intel’s x86) place the least significant bytes (LSB) at a lower address while big endian architectures (e.g. Alpha and PowerPC) place the most significant bytes (MSB) first. Normally byte order (also called endianess) is hard coded in to the processors by its designers, but some processors are able to support both data representations like SGI’s MIPS. This is known as bi-endianess. For some reason the PDP-11 stored 32-bit values as two big-endian shorts with the least significant short placed at the lower address.

Host Byte Order

To find out what endianess your current processor is using you can write a simple C program that detects the byte order and prints the result:

#include <stdio.h>
 
int is_little_endian(void);
 
int main(void) {
	printf("%sn", (is_little_endian() ? "Little endian" : "Big endian"));
	return (0);
}
 
int is_little_endian(void) {
	short int word = 0x0001;
	char *byte = (char *)&word;
 
	return (byte[0] ? 1 : 0);
}

A common problem for programmers is portability. Exchanging data between architectures with different byte order is a problem. Consider the following code snippet that illustrates a common but bad practice:

void write_long(FILE *f, long l) {
	/* Oops! Storing in byte order of current processor. */
	fwrite(&l, sizeof(l), 1, f);
}
 
unsigned long read_long(FILE *fp) {
	long l;
	/* Oops! Assuming same byte order as written to disk. */
	fread(&l, sizeof(l), 1, fp);
 
	return (l);
}

Of course, it is fairly legal to write code like this but the application is limited to the platform the code was written on. A very popular solution to overcome this limitation is to introduce a header for a binray file that contains enough information to allow applications to discover the byte order of the file. The application must then convert the bytes into the appropriate byte order if necessary.

Network Byte Order

Besides the byte order of processors there exists a fixed byte order for network communication. The TCP/IP protocol suite requires big-endian byte order for data transfer. It is provided by the network layer and not by the application data being transmitted. A very common example is the internal representation of IPv4 address and the port associated with a socket. Both are part of the sockaddr structure that must be converted into network byte order before transmission. Unexperienced programmers often write code like this:

struct sockaddr_in server;
server.sin_port = 80; /* non-portable */

Little endian architectures will not behave as expected, although everything looks correct. The standard C library provides for functions to convert to network byte order automatically. Even if we know what byte order we are currently working on we must make use of theses functions to maximize portability of our code. The correct version of the previous code snippet would then look like this:

struct sockaddr_in server;
server.sin_port = htons(80); /* this is portable */

Here the function htons (host to network short) converts a short to network byte order. The reverse can be achieved with ntohs (network to host short) that converts to byte order of the host system.

Size of Native Types

The processor’s size of its registers designates its natural word size. For many 32-bit systems the natural word size is four Bytes (sizeof(int) == 4), although Intel’s x86 can switch to two bytes to retain backward compatibility.

With the advent of 64-bit processors it became clear that this assumption can not be held. What is the new natural word size of this processor generation? Still four bytes or eight bytes? Or both? As a result a lot of data models have been developed with different goals in mind. Some of them emphasized on portability, others on compatibility to 32-bit processors. Until now, five models have been introduced, two of which are currently used for 32-bit processing: LP64, ILP64, LLP64, ILP32, and LP32. The next section describes each model and explains why LP64 is the model of choice.

Data Models

A data model specifies the size of data types imposed by the underlying architecture. It is usually implemented by the operating systems so that multiple data models can be used on the same processor. The following subsections describe the most popular data models used in 32-bit and 64-bit computing environments.

ILP32 and LP32

Todays programmers are familiar with the traditional 32-bit data model ILP32, where integers, longs and pointers are 32 bits in size. LP32 is an even simpler specification designed for Intel’s processors to implement backward compatibility to its 8086 processor family. Here, only longs and pointers are of 32 and integers are of 16 bits in size.

Obviously ILP32 lacks true 64-bit data types and is therfore inappropriate for use on 64-bit processors, that are able to address large amounts of memory way beyond the 4 GB boundary of 32-bit systems.

The following table summarizes the size of data types for both, ILP32 and LP32:

Datatype	ILP32	LP32
char	8	8
short	16	16
int	32	16
long	32	32
pointer	32	32

LP64, ILP64 and LLP64

One of the key benefits of 64-bit processors is the larger address space. Computer industry vendors are now able to develop software systems that allow addressing of up to 512 Terrabytes of storage without circumventing the 4 GB barrier presented by 32-bit processors. This capability is very significant for new high performance applications like database systems or full-motion video. In conjunction with decreasing prices for memory and storage and with continuously increasing computing power new data models have been developed to address these new requirements.

Technical Background

Adding new data types to the C programming language is not possible per se. With the introduction of 64-bit addressing and new arithmetic capabilities, application developers are forced to change mappings or bindings of existing types or to add new data types to the language.

The most popular data models are LP64, ILP64 and LLP64. The nomenclature describes the size of the three basic types: long, int and pointer types. The size of each type of a particular data model is summarized in the following table:

LLP64 Data Model

As we can see from the table above the relationship between long and int is preserved by specifying a size of 32 bits for both. So, data objects not containing pointers will have the same size as found in the ILP32 data model found in almost every 32-bit computing environment.

To support new 64-bit scalar types a new, non-portable data type has been introduced. One can say LLP64 is a true 32-bit data model working with 64-bit addresses. Therein, potential runtime problems are buried regarding the assumption of the size of data types. A pointer will not fit into an int as opposed to a real 32-bit data model like ILP32. To overcome this problem int and long variables in source codes are changed to long long.

This leads directly to another problem with respect to the system APIs. It would require either a change of data type definition of the APIs or the introduction of a new set of 64-bit interfaces. As we can see, LLP64 is far from optimal, since it forces major changes to API specifications where support for 64-bit wide types is not naturally required.

ILP64 Data Model

In contrast to LLP64 the ILP64 data model tries to mimic the relationship between all three basic types ILP32 developers are used to by making int, long and pointer types the same size. Converting or assigning pointers to int or long does not result in data truncation. The major disadvantage of this model is that it is either non-portable or requires the addition of 32-bit data types, int32 for example. This would break with existing typedefs and does not reflect the fundamental spirit of C, which has avoided integration of size descriptions into basic types ever since. Also, system software that depends on data alignment and size may be rendered non-portable, since it is forced to introduce non-standard data types.

As already seen with the LLP64 data model ILP64 requires frequent changes to source codes to allow interchange of data between 32-bit and 64-bit computing environments. The introduction of non-standard data types for sake of interoperability and binary compatibility would be an option but breaks with the basic industry demand for portability.

LP64 Data Model

The last data model is LP64. It takes the best from both worlds by preserving the size of char, short and int as known from ILP32. System software relying on data alignment and size is uneffected and can be used on 32-bit systems without problems. Additionally, a real 64-bit data type is introduced to take full advantage of arithmetic capabilities (especially with regard to pointer arithmetic). For this reason, programs that are made 64-bit clean by changing assignment of addresses to scalar types from int to long can be recompiled and run on 32-bit computing environments without awkward changes as described with LLP64 and ILP64.

Summary

To make meaningful statements about the superiority of a particular model one must perform thorough investigations and evaluate the results, which is far beyond my technical capabilities in terms of hardware equipment. But from the comments made above and the rationales of each data model, we can deduce that LP64 is the model of choice for the following reasons:

• Portability is maximized through LP64 and common problems associated with this criteria can be detected automatically.
• As a matter of fact, interoperability is enhanced by the ability to incorporate standard data types and structures that can be used in both, 32-bit and 64-bit environments.
• The transition from one computing environment to another is easy and has been proven to be smooth by experience and success of real-world projects.

Besides all that, the natural use of C data types to accommodate all the widths needed in a 64-bit environment is the strongest argument for the proliferation of the LP64 data model.

1. Introduction
2. SCTP Core Features: Multi-streaming
3. SCTP Core Features: Multi-homing
4. Other SCTP Features
5. Features of the SCTP Initiation Procedure
1. Cookie Mechanism
2. INIT Collision Resolution
6. SCTP DATA Exchange Features
7. SCTP Shutdown Features
8. SCTP Message Format
9. Error Cases – Retransmission
10. Error Cases – Path Failure
11. Error Cases – Endpoint Failure
12. API
13. Security
14. Extensions

Introduction

The Stream Control Transmission Protocol (SCTP) is a new IP transport protocol, existing at an equivalent level as UDP (User Datagram Protocol) and TCP (Transmission Control Protocol), which currently provide transport layer functions to all of the main Internet applications. SCTP has been approved by the IETF as a Proposed Standard.

Like TCP, SCTP provides a reliable transport service, ensuring that data is transported across the network without error and in sequence. Like TCP, SCTP is a connection-oriented mechanism, meaning that an relationship is created between the endpoints of an SCTP session prior to data being transmitted, and this relationship is maintained until all data transmission has been successfully completed.

Unlike TCP, SCTP provides a number of functions that are considered critical for signaling transport, and which at the same time can provide transport benefits to other applications requiring additional performance and reliability.

The core features of SCTP are multi-streaming and multi-homing.

SCTP Core Features: Multi-streaming

The name Stream Control Transmission Protocol is derived from the multi-streaming function provided by SCTP. This feature allows data to be partitioned into multiple streams that have the property of being delivered independently, so that message loss in any of the streams will only affect delivery within that stream, and not in other streams.

In contrast, TCP provides a single stream of data and ensures that delivery of that stream takes place with perfect sequence preservation. While this is desirable for delivery of a file or record, it causes additional delay when message loss or sequence error occurs within the network. When this happens, TCP must delay delivery of data until the correct sequencing is restored, either by receipt of an out-of-sequence message, or by retransmission of a lost message.

For a number of applications, this characteristic of strict sequence preservation is not truly necessary. In signaling, for example, it is only necessary to maintain sequencing of messages that affect the same resource (e.g., the same call, or the same channel). Other messages are only loosely correlated and can be delivered without having to maintain overall sequence integrity.

Another application having this property is delivery of web page objects, if done over a single session. It is generally not necessary to maintain sequence between the presentation of objects, and in some cases (esp. some types of graphic images) it may be possible to present parts of a single object out of sequence. Eventually the goal is to deliver all objects, however the ability to deliver objects out of sequence may result in at least better perceived performance, as parts of the web page can be displayed rather than waiting for all of the information to be received before displaying it.

SCTP accomplishes multi-streaming by creating independence between data transmission and data delivery. In particular, each DATA “chunk” (or PDU) in the protocol uses two sets of sequence numbers, a Transmission Sequence Number that governs the transmission of messages and the detection of message loss, and the Stream ID/Stream Sequence Number pair, which is used to determine the sequence of delivery of received data.

This independence of mechanisms allows the receiver to determine immediately when a gap in the transmission sequence occurs (e.g., due to message loss), and also whether or not messages received following the gap are within an affected stream or not. If a message is received within the affected stream, there will be a corresponding gap in the Stream Sequence Number, while messages from other streams will not show a gap. The receiver can therefore continue to deliver messages to the unaffected streams while buffering messages in the affected stream until retransmission occurs.

SCTP Core Features: Multi-homing

The other core feature of SCTP is multi-homing, or the ability for a single SCTP endpoint to support multiple IP addresses. The benefit of multi-homing is potentially greater survivability of the session in the presence of network failures. In a conventional single-homed session, the failure of a local LAN access can isolate the end system, while failures within the core network can cause temporary unavailability of transport until the IP routing protocols can reconverge around the point of failure. Using multi-homed SCTP, redundant LANs can be used to reinforce the local access, while various options are possible in the core network to reduce the dependency of failures for different addresses. Use of addresses with different prefixes can force routing to go through different carriers, for example, while route-pinning techniques or even redundant core networks can also be used if there is control over the network architecture and protocols.

In its current form, SCTP does not do load-sharing, that is, multi-homing is used for redundancy purposes only. A single address is chosen as the “primary” address and is used as the destination for all DATA chunks for normal transmission. Retransmitted DATA chunks use the alternate address(es) to improve the probability of reaching the remote endpoint, while continued failure to send to the primary address ultimately results in the decision to transmit all DATA chunks to the alternate until heartbeats can reestablish the reachability of the primary.

To support multi-homing, SCTP endpoints can exchange lists of addresses during initiation of the association. Each endpoint must be able to receive messages from any of the addresses associated with the remote endpoint; in practice, certain operating systems will utilize available source addresses in round robin fashion, in which case receipt of messages from different source addresses will be the normal case. A single port number is used across the entire address list at an endpoint for a specific session.

In order to reduce the potential for security problems, it is required that some response messages be sent specifically to the source address in the message that caused the response. For example, when the server receives an INIT chunk from a client to initiate an SCTP association, the server always sends the response INIT ACK chunk to the source address that was in the IP header of the INIT.

Other SCTP Features

SCTP is a unicast protocol, and supports data exchange between exactly 2 endpoints, although these may be represented by multiple IP addresses.

SCTP provides reliable transmission, detecting when data is discarded, reordered, duplicated or corrupted, and retransmitting damaged data as necessary. SCTP transmission is full duplex.

SCTP is message oriented and supports framing of individual message boundaries. In comparison, TCP is stream oriented and does not preserve any implicit structure within a transmitted byte stream.

SCTP is rate adaptive similar to TCP, and will scale back data transfer to the prevailing load conditions in the network. It is designed to behave cooperatively with TCP sessions attempting to use the same bandwidth.

Features of the SCTP Initiation Procedure

The SCTP Initiation Procedure relies on a 4 message sequence, where DATA can be included on the 3^rd and 4^th messages of the sequence, as these messages are sent when the association has already been validated. A “cookie” mechanism has been incorporated into the sequence to guard against some types of denial of service attacks.

1. Cookie Mechanism
   The “cookie” mechanism guards specifically against a blind attacker generating false INIT chunks to try to overload the resources of an SCTP server by causing it to use up memory and resources handling new INIT requests. Rather than allocating memory for a Transmission Control Block (TCB), the server instead encrypts enough information to build its TCB an internal key and sends this as a Cookie parameter in the INIT ACK. Since the INIT ACK always goes back to the source address of the INIT, the blind attacker will not get the Cookie. A valid SCTP client will get the Cookie and return it in the COOKIE ECHO chunk, where the SCTP server can decrypt the Cookie and verify that it is valid – note that the SCTP client never has to understand the Cookie, so that no exchange of keys is required. Otherwise, the SCTP Initiation Procedure follows many TCP functions, so that the endpoints exchange receiver windows, initial sequence numbers, etc. In addition to this, the endpoints may exchange address lists as discussed above, and also mutually confirm the number of streams to be opened on each side.
2. INIT Collision Resolution
   Multi-homing adds to the potential that messages will be received out of sequence or with different address pairs. This is a particular concern during initiation of the association, where without procedures for resolving collision of messages, you may easily end up with multiple parallel associations between the same endpoints. To avoid this, SCTP incorporates a number of procedures to resolve parallel initiation attempts into a single association.

SCTP DATA Exchange Features

DATA chunk exchange in SCTP follows TCP’s Selective ACK procedure. Receipt of DATA chunks is acknowledged by sending SACK chunks, which indicate not only the cumulative Transmission Sequence Number (TSN) range received, but also any non-cumulative TSNs, implying gaps in the received TSN sequence. Following TCP procedures, SACKs are sent using the “delayed ack” method, normally one SACK per every other received packet, but with an upper limit on the delay between SACKs and an increase to once per received packet when there are gaps detected.

Flow and Congestion Control follow TCP algorithms. The advertised receive window indicates buffer occupancy at the receiver, while a per-path congestion window is maintained to manage the packets in flight. Slow start, Congestion avoidance, Fast recovery and Fast retransmit are incorporated into the procedures as described in RFC2581, with the one change being that the endpoints must manage the conversion between bytes sent and received and TSNs sent and received, since TSN is per chunk rather than per byte.

The application can specify a lifetime for data to be transmitted, so that if the lifetime has expired and the data has not yet been transmitted, it can be discarded (e.g., time-sensitive signaling messages). If the data has been transmitted, it must continue to be delivered to avoid creating a hole in the TSN sequence.

SCTP Shutdown Features

SCTP Shutdown uses a 3 message procedure to allow graceful shutdown, where each endpoint has confirmation of the DATA chunks received by the remote endpoint prior to completion of the shutdown. An Abort procedure is also provided for error cases when an immediate shutdown must take place.

Note that SCTP does not support the function of a “half-open” connection as can occur in TCP, when one side indicates that it has no more data to send, but the other side can continue to send data indefinitely. SCTP assumes that once the shutdown procedure begins, both sides will stop sending new data across the association, and only need to clear up acknowledgements of previously sent data.

SCTP Message Format

The SCTP Message includes a common header plus one or more chunks, which can be control or data. The common header has source and destination port numbers to allow multiplexing of different SCTP associations at the same address, a 32-bit verification tag that guards against insertion of an out-of-date or false message into the SCTP association, and a 32-bit checksum (the Adler checksum, described in RFC1950) for end-to-end error detection.

Each chunk includes chunk type, flag field, length and value. Control chunks incorporate different flags and parameters depending on the chunk type. DATA chunks in particular incorporate flags for control of segmentation and reassembly, and parameters for the TSN, Stream ID and Stream Sequence Number, and a Payload Protocol Identifier.

The Payload Protocol ID has been included for future flexibility. Initially, values will reflect the adaptation layer protocol running over SCTP, and will match the registered port number assignments for adaptation layers. In future, it is envisioned that the functions of protocol identification and port number multiplexing will not be as closely linked so that the port number significance is not so much overloaded as it is now.

The SCTP message format naturally allows support of bundling of multiple DATA and control chunks in a single message, to improve transport efficiency. Use of bundling is controllable by the application, so that bundling of initial transmission can be prohibited. Bundling will naturally occur on retransmission of DATA chunks, to further reduce any chance of congestion.

Error Cases – Retransmission

Retransmission of DATA chunks occurs from either (a) timeout of the retransmission timer; or (b) receipt of SACKs indicating the DATA chunk has not been received. To reduce the potential for congestion, the rate of retransmission of DATA chunks is limited. The retransmission timeout (RTO) is adjusted based on estimates of the round trip delay and backs off exponentially as message loss increases.

In an active association with fairly constant DATA transmission, SACKs are more likely to cause retransmission than the timeout. To reduce the chance of an unnecessary retransmission, a 4 SACK rule is used, so that retransmission only occurs on receipt of the 4^th SACK that indicates that the chunk is missing. This is intended to avoid retransmits due to normal occurrences such as packets received out of sequence.

Error Cases – Path Failure

A count is maintained of the number of retransmissions to a particular destination address without successful acknowledgement. When this count exceeds a configured maximum, the address is declared inactive, notification is given to the application, and the SCTP begins to use an alternate address for sending of DATA chunks.

Also, Heartbeat chunks are sent periodically to all idle destinations (i.e., alternate addresses), and a counter is maintained on the number of Heartbeats sent to an inactive destination without receipt of a corresponding Heartbeat Ack. When this counter exceeds a configured maximum, that destination address is also declared inactive.

Heartbeats continue to be sent to inactive destination addresses until an Ack is received, at which point the address can be made active again. The rate of sending of Heartbeats is tied to the RTO estimation plus an additional delay, to allow Heartbeat traffic to be tailored to the needs of the application.

Error Cases – Endpoint Failure

A count is maintained across all destination addresses on the number of retransmits or Heartbeats send to the remote endpoint without successful Ack. When this exceeds a configured maximum, the endpoint is delared unreachable, and the SCTP association is closed.

API

The specification includes a model of the primitives exchanged between the application and the SCTP layer, intended as informational material rather than a formal API statement. A follow-on document will provide a socket-like API to simplify any migration of TCP or UDP applications to the use of SCTP.

Security

In addition to the verification tag and cookie mechanisms, SCTP specifies the use of IPSec if strong security and integrity protection is required. The SCTP specification does not itself define any new security protocols or procedures.

Extensions

The SCTP format allows new chunk types, flags and parameter fields to be defined as extensions to the protocol. Any extensions must be based on standard agreements within IETF, as no vendor-specific extensions are supported in the protocol.

Chunk Type values are organized into four ranges to allow extensions to be made with a pre-defined procedure for responding if the a new Chunk Type is not recognized at the remote endpoint. Responses include: whole packet discard; packet discard with reporting; ignoring the chunk; ignoring with reporting. Similar pre-defined responses are specified for unrecognized Parameter Type values.

Grundlagen

Ausgehend vom Routing, ist das Internet in zwei Hierarchien gegliedert: Domains, die eine eigene interne Routing-Architektur aufweisen (und jeweils unterschiedliche Routing-Protokolle verwenden können) und autonome Systeme, die eine homogene Routing-Architektur für das Routing zwischen autonomen Systemen ermöglichen. Domains verwenden ein Routing-Protokoll, daß speziell an die Anforderungen für das interne Routing angepaßt ist. Es existieren verschiedene Protokolle für solche Anwendungen, die als Interior Gateway Protocols (IGP) zusammgefaßt werden. Sie verwalten eine vollständige Topologie ihrer Routing-Domain und sind in der Lage, optimale Pfade zwischen zwei Punkten innerhalb der Domain zu errechnen. Zwar ist diese Technik auch für sehr große Domains geeignet, allerdings übersteigt die Dimension des Internets die Fähigkeiten solcher Protokolle, so daß für das Routing zwischen autonomen Systemen andere Technologien zum Einsatz kommen. Bekannte Vertreter der IGPs sind beispielsweise OSPF (Open Shortest Path First) und IS-IS (Intermediate System to Intermediate System).

Routing zwischen autonomen Systemen wird als Inter-Domain Routing bezeichnet und beschreibt, wie zwischen Domains geroutet werden kann, ohne jedoch Pfade durch autonome Systeme festzulegen. Ein Pfad zwischen Domains wird durch die Kennungen aller Domains definiert, die zu durchqueren sind, um die Ziel-Domain mit dem entsprechenden Adresspräfix zu erreichen. Diese Funktionalität übernimmt das in der Version 4 vorliegende Border Gateway Protocol (BGP).

Wir bezeichnen einzelne Routing-Domains als autonome Systeme, weil sie zum einen durch eine Instanz verwaltet werden und zum anderen völlig unabhängig von anderen Routing Domains sind. Damit ist eine Routing-Domain eine autonome Einheit innerhalb des Internets und aus diesem Grund ein autonomes System. Jedes AS wird durch eine sog. Autonomous System Number (ASN, autonome Systemnummer) eindeutig identifiziert. ASNs sind als 16-bittige Ganzzahlen definiert, die eine Adressierung von insgesamt 65536 autonomen Systemen erlauben. ASN 0 ist reserviert und wird beispielsweise zur Bezeichnung nicht gerouteter Netzwerke genutzt. Das gleiche gilt für die größte ASN. Die Aufteilung des ASN-Raums zeigt folgende Tabelle:

ASNs zusammen mit den Adresspräfixen der Domains entsteht ein Interdomain-Routing Space. Die Routing-Informationen werden verbreitet indem das ursprüngliche AS sein Adresspräfix und seine ASN angibt, so daß alle empfangenden autonomen Systeme einen Pfad zu diesem Usprungs-As ermitteln können. Immer wenn ein AS erreicht wird fügt es seine ASN und das Adresspräfix hinzu. Auf diese Weise kann an jeder Stelle im Pfad zwischen den autonomen Systemen die Sequenz der durchschrittenen autonomen Systeme genau ermittelt werden. Abbildung 1 zeigt ein einfaches Netzwerk bestehend aus 5 AS. AS 14 mit dem Präfix 10.1.2.0/24 sendet ein sog. Prrefix Advertisment (Präfixbekanntmachung) aus, daß irgendwann alle autonomen Systeme durchlaufen ist und schließlich in AS 10 mündet.

Ermittlung von Pfaden zwischen autonomen Systemen

Jedes AS fügt neben seinem Adresspräfix auch seine ASN hinzu. AS 10 empfängt nun zwei Advertisments: eines für den Pfad (12, 14) und ein weiteres für den Pfad (11, 13, 14). AS 10 kann jetzt drei Dinge feststellen:

• Da es nur mit AS 12 und AS 11 verbunden ist, von beidem jedoch ein Advertisment empfangen hat, ist es nicht nötig, das Advertisment weiterzuleiten.
• Die beiden Pfade der Advertisments sind unterschiedlich lang, so daß leicht eine Metrik aufgebaut werden kann.
• Durch die Pfadinformationen kann das AS leicht erkennen, ob eine Schleife entstanden ist.

Die Metrik eines Pfades sagt aus, wie viele autonome Systeme durchlaufen werden müssen, um ein bestimmtes Adresspräfix zu erreichen. Sind mehrere Pfade für das gleiche Adresspräfix vorhanden, wählt der Algorithmus des BGP automatisch den kürzeren Pfad aus; in unserem Beispiel wäre das der Weg über AS 11, der nur ein As durchquert. Nur durch das explizite Aufzählen der autonoment System im Pfad verhindert Loops, denn wenn ein AS Advertisments empfängt, das die eigene AS enthält wird das Präfix einfach verworfen.

Nicht jedes Netzwerk im Internet benötigt eine ASN. Eine ASN wird nur benötigt, wenn das Netzwerk eigene Routing-Richtlinien erfordert, beispielsweise jene von ISPs. Ein privates Netzwerk, das im Internet geroutet werden soll, aber über eine Anbindung an einen Provider verfügt, unterliegt damit den gleichen Routing-Richtlinien wie denen des Providers, auch wenn das Netzwerk BGP für das Routing zu diesem Provider verwendet. Bei einer solchen Konstellation spricht man in der Regel von einem Upstream Provider, der nicht notwendigerweise ein ISP, sondern auch ein Betreiber eines periphären Netzwerkes mit einer öffentlichen ASN sein kann. Das private Netzwerk verwendet stattdessen eine private ASN aus dem Bereich von 64.512 – 65.534 um eine BGP-Sitzung zu ermöglichen, die beim Advertisment der Route durch den Upstream Provider entfernt wird. Anschließend tritt das Netzwerk des Upstream Providers als Ursprungs-AS des Advertisments auf. Abbildung 2 verdeutlicht diesen Vorgang:

Verwendung privater ASNs

Der Einsatz einer eigenen öffentlichen ASN macht für Netzwerke mit zwei oder mehr Transit-Verbindungen Sinn, allerdings nur, wenn sich die Routing-Richtlinien von denen des Upstream-Netzwerks unterscheiden.

Da viele autonome Systeme der gleichen Organisation oftmals räumlich voneinander getrennt sind, aber in der Regel auch von dieser administriert werden, verfügen sie gleichzeitig über die gleiche ASN. Abbildung 3 zeigt eine Beispieltopologie mit der gleichen ASN in zwei getrennten Subdomains eines autonomen Systems.

Eine ASN für zwei Subdomains eines autonomen Systems

AS 10a mit der Netzwerkadresse 10.0.1.0/25 gibt seine ASN bekannt und AS 11 und 12 leiten das Advertisment weiter. Sobal AS 10b das Advertisment (12, 11, 10) von AS 12 empfängt, sieht es seine eigene ASN und verwirft das Advertisment, denn es hat ja bereits AS 10 durchlaufen. Das gleiche passiert in umgekehrter Richtung, wenn AS 10b mit der Netzwerkadresse 10.0.1.128/25 seine ASN bekanntgibt. AS 10a auf der anderen Seite lehnt das empfangene Advertisment von AS 11 (11,12,10) ab. Damit entsteht allerdings eine Lücke, denn AS 10a weiß nicht, wie es zu AS 10b routen soll. Wenn AS 10a eine statische Route zu AS 10b über AS 11 einrichtet und AS 10b eine statische Route zu AS 10a über AS 12 können sich die beiden Subdomains wieder erreichen.

ASNs werden knapp

Es stehen insgesamt etwa 64.510 ASNs zur Verfügung (siehe Tabelle 1) und bereits jetzt sind etwa 40.000 allokiert worden (weiterführende Statistiken finden Sie hier: http://www.ripe.net/docs/ripe-353.html). Ganz klar, daß wir bald eine extreme Verknappung der ASNs erleben werden, wenn nichts unternommen wird.

Aktuelle Aufstellung des ASN-Pools

Auch wenn es den Anschein haben mag, gibt es keine Korrelation zwischen der Anzahl der Internet Service Providers (ISPs) und der Anzahl der allokierten ASNs. Pro Jahr werden etwa 3.500 ASNs vergeben (siehe http://www.potaroo.net/tools/asns/), so daß bei bestehender Praxis spätestens 2010 alle RIRs ihre ASN-Pools vollständig ausgeschöpft haben werden. Ein wichtiger Faktor für das Auslaufen der ASNs ist steigende Bedarf an hochverfügbaren Verbindungen für geschäftskritische Anwendungen. Dazu bemühen Betreiber von Netzwerken oftmals mehrere Upstream-Provider und definieren mit Hilfe von eigenen ASNs und BGP unterschiedliche Routing-Richtlinien für jeden Upstream. Welche weiteren Faktoren größeren Einfluß auf die Entwicklung haben werden ist schwer vorherzusagen.

Von den 64.510 verfügbaren ASNs sind etwa 40.000 von der IANA in 1.024er-Blöcken an die Regional Internet Registries (RIRs) vergeben worden, die ihrerseits die ASNs an ISPs und Endbenutzer-Netzwerke weitergeben. Einige der vergebenen ISP-ASNs sind im Internet nicht sichtbar und werden damit auch bekanntgegeben (advertised). Auch dazu liefert http://www.potaroo.net/tools/asns/ interessante Statistiken.

Der Übergang von 16-Bit zu 32-Bit ASNs

Aktuellen Projektionen zufolge, sind 2010 keine ASNs für ISPs mehr verfügbar. Die logische Schlußfolgerung ist, daß bis dahin ein neues Interdomain-Routing-Protokoll etabliert wurde (welches vollkommen ohne ASNs auskommt) oder von 16-bittigen ASNs auf 32-Bit-ASNs umgeschwenkt wird. Letzere Option scheint die bessere Wahl zu sein, auch wenn es einige Zeit dauern wird, bis sie Verbreitung finden und die Anzahl der Netzwerke wächst weiter von Tag zu Tag.

Der Übergang zu längeren ASNs erfordert einen wohldurchdachten Plan: (a) zunächst müssen die erforderlichen Standards und Best Practices geschaffen werden. Anschließend (b) muß stablier Code für den Produktiveinsatz entwickelt werden, der die neuen Standards implementiert. Stabil heißt in diesem Zusammenhang auch, daß die neuen Spezifikation uneingeschränkt (c) rückwärtskompatibel sind, so daß 16-Bit- und 32-Bit-ASNs für eine sehr lange Zeit koexistieren können. Und letztendlich wäre es wünschenswert, wenn der Einsatz der neuen Technik beginnt, bevor (d) die ASNs vollständig aufgebraucht sind.

Der neue Weg

Im Oktober 2005 tauchte der bereits in der 12. Version befindliche Internet Draft (I-D) in den Archiven des IETF Internet Draft Repositories auf, der genau diese Problematik betrachtete: draft-ietf-idr-as4bytes-12.txt. Bei Erweiterung des ASN-Feldes in BGP-Nachrichten würde eine theoretische maximale Anzahl von 4,294,967,296 ASNs zur Verfügung stehen. Die wichtigste Frage, die sich stellt, ist: wie schaffen wir es, das alte Format bestehend aus 2 Oktetten mit dem neuen Format aus 4 Oktetten zu kombinieren?

Der Ansatz sieht vor, daß neue BGP-Speaker (im weiteren Verlauf NEW BGP genannt) über BGP Capability Advertisments in OPEN Messages (RFC2842) ihren Peers mitteilen, über welche Fähigkeiten (engl. capabilities) sie verfügen. Unterstützt ein Router die neue 4-Byte-ASN-Semantik, so wird er das NEW_AS_PATH-Attribut verwenden, das die gleiche Semantik aufweist wie das klassische AS_PATH-Attribut, mit dem Unterschied, daß die ASN als 4 Oktette kodiert ist. Von Bedeutung ist nur ein Szenario: die Kommunikation zwischen NEW BGP und OLD BGP, und zwar in beide Richtungen.

Die längere 4-Byte-ASN wird von jetzt an mit einer neuen Syntax beschrieben: .. Folglich können wir nun theoretisch ASNs von 0.0 bis 65535:65535 vergeben. Mit Hilfe dieser Notation wird der Übergang zur neuen 4-Byte-ASN erleichtert, aber die Kompatibilität zur alten Notation bewahrt, wie wir gleich sehen werden.

Während die Kommunikation zwischen zwei NEW BGP-Geräten relativ einfach ist, denn beide unterstützen 32-Bit-ASNs, bedürfen die Übergänge von OLD BGP zu NEW BGP und umgekehrt besonderer Aufmerksamkeit. Wenn ein NEW_AS_PATH-Attribut durch eine AS_PATH-Zone geleitet werden muß ist die Frage, wie wir (a) die 32-Bit-Semantik von NEW BGP durch die AS_PATH-Zone bringen und (b) wie wir Pfade rekonstruieren, wenn sie aus einer OLD BGP-Umgebung in eine NEW BGP-Umgebung überführt werden müssen. Abbildung 4 zeigt, wie es geht:

Zusammenarbeit von OLD BGP mit NEW BGP

Auf der linken und rechten Seite befinden sich autonome Systeme mit Unterstützung für NEW BGP und in der Mitte finden wir zwei AS, die als Transit-Netzwerke dienen sollen. AS 0:2 sendet ein BGP Advertisment aus, AS 1:5 verarbeitet es wie gewohnt und leitet es an AS 11 weiter. AS kennt 32-Bit-ASNs nicht und antwortet mit einem Fehler auf das Capability Advertisment von AS 1:5. Dennoch nimmt es das BGP Advertisment an, denn AS 1:5 kodiert die NEW BGP-Daten als NEW_AS_PATH-Attribut und die alten Daten in das AS_PATH-Attribut. Dazu werden die NEW BGP ASNs folgendermaßen in 16-Bit-Daten übersetzt: ist die Ziffer vor dem Doppelpunkt eine 0, wird sie einfach gestrichen. Aus AS 0:2 wird beispielsweise AS 2. Ist es keine 0, wandert sie in das AS_PATH-Attribut, wird aber durch eine vordefinierte 16-Bit-ASN 23456 ersetzt, wie wir beim Übergang von AS 1:5 zu AS 11 sehen können. Der 32-Bit-ASN-Pfad bleibt erhalten, aber 2-Oktett-ASNs werden hier nicht eingetragen. Sobald das BGP Advertisment eine 16-Bit-Zone verläßt wird der ursprüngliche Pfad wieder zusammengesetzt.

Der beschriebene Ansatz ist relativ einfach umzusetzen und kann auf unbestimmte Zeit parallel mit OLD BGP-Geräten eingesetzt werden. Außerdem sichert er die Loop-Detection und die Auswahl des kürzesten AS-Pfades auch über AS_PATH- und NEW_AS_PATH-Zohnen ohne Eingriffe in bestehende Strukturen gleichermaßen zu. Die einzige Vorraussetzung dafür ist, daß sie bereitwillig die NEW_AS_PATH-Updates verbreiten, die von 32-Bit-AS emittiert werden.

Hintergründe

Die Prägung des Begriffs Network Neutrality geht wahrscheinlich auf Professor Tim Wu der Columbia-Universität zurück, der die These aufstellte, daß der Ausschluß von bestimmten Internet-Anwendungen zur Innovationsbremse für neue technologische Entwicklungen führen würde. Erst kürzlich haben einige größere ISPs und Netzwerkbetreiber Pläne veröffentlicht, die eine Erhebung von Gebühren für die Durchleitung und Bereitstellung von Infrastrukturen qualitativ höherwertiger Inhalte vorsehen. Befürworter der Netzwerkneutralität befürchten, daß auf diese Weise ganze Teile des Internets nur noch sehr langsam oder gar nicht mehr ohne die Entrichtung eines Entgeldes verfügbar sind und somit finanzschwache Teilnehmer des Internets kaum noch Inhalte einbringen oder abrufen können.

Inzwischen hat die Debatte auch die Politik erreicht. In den USA wird momentan über einen Entwurf zur Einschränkung der Berechnung von Gebühren für Dienste, die über die Netzwerke von Providern angeboten werden, beraten. Dabei geht es zum einen um die Abschirmung von Inhalten, was als Zensur verstanden wird, und zum anderen um das Tiering von Breitbandanwendungen mit dem Verkauf von kostenpflichtigen Sprach- und Datendiensten mit QoS-vereinbarungen.

Prominenteste Fürsprecher der Netzwerkneutralität sind unter anderem Google, Yahoo!, Microsoft und einige prominente Persönlichkeiten. Die genannten Unternehmen fürchten mit dem Verlust der Netzwerkneutralität einen immensen Rückgang der Anwender ihrer Dienste und damit erhebliche Gewinneinbußen, beispielseweise bei den Werbeeinnahmen. Gegner der NN, wie etwa Verizon, AT&T und Comcast, haben allerdings starke Partner an ihrer Seite, darunter die US Handelskammer (US Chamber of Commerce), die National Black Chamber of Commerce und die League of Latin American Citizens. In der Debatte um NN prallen gänzlich unterschiedliche Visionen der Zukunft des Internets aufeinander und offenbar auch unterschiedliche Wahrnehmungen der Vergangenheit des globalen Netzwerkes.

Konzeptionelle Überlegungen

Die Netzwerkneutralität kann aus technischer und kommerzieller Sichtweise betrachtet werden. Wu machte mit seiner These klar, daß das Internet selbst kein neutrales Netzwerk ist, da allein die technischen Ausprägungen eine Netzwerkanwendung keine echte Neutralität zulassen. Beispielsweise gibt es zeitkritische Anwendungen wie etwa VoIP und Video, die oftmals eine bevorzugte Behandlung bei der Durchleitung erfordern, und weniger zeitkritische wie Email oder HTTP. Schon deshalb sei die Internet Protocol Suite nicht wirklich neutral. Weiter denkt Wu, daß Betreiber von Breitbandnetzen in der Lage sein sollten, sinnvolle Unterscheidungen zwischen den Anforderungen verschiedener Anwendungen vornehmen zu dürfen und damit auch entscheiden können, wie der Verkehr solcher Anwendungen durch eigene Netzwerke geleitet werden sollte.

Dem gegenüber steht die Meinung der angesehenen Professoren der Rechtswissenschaften Susan Crawford, die einen uneingeschränkten, nicht regulierten Zugang zu Netzwerken zur Durchsetzung der Netzwerkneutralität unterstützt. Netzwerke sollten nicht auf Basis der Inhalte regulieren, sondern lediglich den richtigen Transportmechanismus für eine Anwendung bereitstellen. Ihrer Meinung nach geht es lediglich um die Gleichbehandlung von Bits in Datennetzen, derren gleichberechtigte Weiterleitung einen wichtigen Schutz des gemeinschaftlichen Gutes der Menschheit darstellt, das nicht unter die Kontrolle von Unternehmen gestellt werden darf. Für sie ist das Internet ein Bedürfnis, ähnlich wie Elektrizität, und sollte wenn möglich von der Regierung bereitgestellt und geschützt werden.

Der Begriff Netzwerkneutralität wird trotz der starken teschnischen Ausrichtung in nicht einem der technischen Spezifikationen (beispielsweise RFCs) erwähnt. Dennoch gibt es einige Punkte, die auf eine gewisse regulatorische Natur der verwendeten Technologien, angefangen von der Hardware bis hin zu Anwendungsprotokollen, schließen lassen. Zwar sind die meisten Netzwerke und deren Anwendungen weitgehend transparent, greifen jedoch durch die verwendeten Algorithmen und Technologien bereits auf dieser Ebene in den Netzwerkverkehr ein, der streng genommen, nicht mehr neutral behandelt wird. Beispielsweise sind packetorientierte Netzwerke nicht wirklich neutral, sondern fertigen den Verkehr unter verschiedenen Gesichtspunkten, wie Congestion Control ("Staukontrolle"), Resourcenverbrauch und der Möglichkeit des Queuings ab. Desweiteren spielen auch Techniken wie Forwarding-Algorithmen und Queue-Management in die Abwicklung des weltweiten Datenverkehrs ein. Sie sind alle auf ihre Weise bereits diskrimatorisch.

Argumente und Bedenken

Weitgehend unbekannt ist die Tatsache, daß die Netzwerkneutralität eng mit dem Ende-zu-Ende-Prinzip (end-to-end principle) verwoben ist. Diesem Prinzip nach besitzt ein Netzwerk keine, oder kaum, Intelligenz, sondern leitet einfach nur Datenpakete weiter. Es hat keinerlei Kenntnis über Inhalte und die Anwendungen, die die Datenpakete konsumieren oder emittieren. Ein wichtiger Vorzug der Netzwerkneutralität ist, daß ein "dummes" Netzwerk die Entwicklung und Ausbreitung von Innovationen fördert. Demnach sollten Netzwerkbetreiber, ob Telekommunikationsunternehmen oder ISP, nicht bestimmen, wie ihre Netzwerke genutzt werden sollen.

Viele setzen Netzwerkneutralität mit der Neutralität des Internets gleich, obwohl keines der technischen Beschreibungen in Bezug auf Internet-Technologien diesen Begriff jemals aufgreift. In vielen Abhandlungen über die Geschichte des Internets, beispielsweise in Manuel Castells’ "The Internet Galaxy: Reflections on the Internet, Business, and Society" aus dem Jahr 2001 wird das Internet in den historischen und soziologischen Hintergrund gesetzt, jedoch ohne auf das Phänomen Netzwerkneutralität einzugehen. Erst Prof. Lawrence Lessig’s "The Future of Ideas" von 2001 wird den Begriff erstmals aufgreifen. Viele Argumente für eine Regulierung des Internets stammen zum einen aus dem akademischen Bereich mit Prof. Tim Wu als prominentesten Vertreter, Lawrence Lessig und dem FCC-Vorsitzenden Michael Powell, der als einer der ersten Offiziellen Stellung zur Netzwerkneutralität bezog. Allerdings sollten wir nicht vergessen, daß die Ideen, welche in der Netzwerkneutralität wiederzufinden sind, eine lange Geschichte haben, denn bereits mit der Einführung des Kabelfernsehens wurden Gegner der Regulierung des Mediums auf den Plan gerufen.

Befürworter der Netzneutralität stammen erstaunlicherweise aus allen Branchen und akademischen Kreisen. So sehen nicht nur Netzwerkexperten und -ingeneure einen gravierenden Rückschlag in der Aufgabe der Netzwerkneutralität sondern auch TV-Stationen, einige Telekommunikationsunternehmen und Gelehrte Nachteile in diesem Vorhaben. Es lassen sich vier Argumente aus der bisherigen Debatte ausmachen:

1. Die meisten Vorhaben, den Zugang zu Netzwerken zu regulieren, schränken den Nutzen des gesamten Internets erheblich ein.
2. Jede Regulierung ist auch gleichzeitig ein Prezedenzfall für weitere einschneidende Regulierungsverfahren.
3. Eine Regulierung würde Investitionen in konkurrierende Netzwerktechnologien wie etwa WLAN reduzieren und Netzwerkbetreiber gleichzeitig daran hindern, ihre Dienste investionssicher zu differenzieren.
4. Die Aufgabe der Netzwerkneutralität des unregulierten Internets würde zu Verunsicherungen führen, da es schwierig wird die Regularien mit denen der Telefon- und Kabelnetze abzustimmen.

Während das Internet sich aufgrund seiner Deregulierung steigender Beliebtheit erfreut, sehen Kritiker der Netzwerkneutralität ohnehin bereits ein reguliertes Internet und verweisen auf das ToS-Feld (Type of Service) im IP-Header oder das Aktive Queuing nach RFC2309. Ihrer Meinung nach ist das Internet weit von einer geeigneten Plattform für Echtzeit- und Multimediaanwendungen entfernt, weil solche Regulierungen fehlen und damit das evolutionäre Wachstum des Internets grundlegend gehemmt sei.

Netzwerkneutralität im Zeichen der freien Marktwirtschaft

Eines der Hauptargumente für Netzwerkneutralität ist, daß ein diskriminatorisches Netzwerk den Märkte, die von dem Internent abhängig sind, stören, und damit letztendlich das Wirtschaftswachstum nachhaltig hemmen würde. Dadurch wäre es möglich, daß Unternehmen A einen Markt dominiert, obwohl die Technologie von Unternehmen B besser ist. Ermöglicht wird das durch die stärkere Finanzkraft von A, das sich den schnellen Zugang zu Netzwerken erkaufen kann. Auf die gleiche Weise kann auch der Einzug einer neuen Technologie erschwert oder gar unmöglich gemacht werden, weil das diskriminatorische Netzwerk eine andere zeitgenössische Technologie bevorzugt (behandelt). Was das mit ökonomischen Wachstum zu tun hat, läßt sich folgendermaßen umreißen: die Innovationskraft eines Landes ist ein wichtiger Motor ökonomischen Wachstums. Führt nun die Abschaffung der Netzwerkneutralität zu einer geringeren Innovationskraft, wirkt sich das unmittelbar auf das wirtschaftliche Wachstum eines Landes aus. Demgegenüber stehen Kritiker, die eine Vernachlässigung grundlegender Anforderungen an Netzwerktechnologien befürchten, denn ein neutrales Netzwerk wäre gegenüber zeitkritischer und bandbreitenkritischer Anwendungen blind, was einen ähnlichen Effekt auf die wirtschaftliche Entwicklung haben würde.

Argumente gegen Netzwerkneutralität sind vielfältiger Natur, unter anderem deshalb, weil der Begriff selbst unterschiedliche definiert ist:

1. Paket-basierte Unterscheidung (Diskriminierung) ist zwingen erforderlich, um QoS-Lösungen zu implementieren, was mit Netzwerkneutralität unmöglich sei.
2. Sevice-Bundeling ist notwendig, um Investitionen zu ermöglichen, denn wenn ein Anbieter für einen höherpriorisierten Dienst mehr Gebühren verlangen kann als ein Mitbewerber, der den gleichen Dienst bei Standardpriorität anbietet, profitiert der Kunde, weil der Dienst besser ist und der Anbieter weil seine Einnahmen steigen und steigende Investitionen nach sich zieht. Ein Gegenargument hinterfragt die Notwendigkeit dieser Maßnahmen, denn schließlich könnte ein Anbieter einen Flaschenhals im Netzwerk ausnutzen und damit den Zugang für Mitbewerber quasi abkoppeln und gleichzeitig ein Monopol einrichten.
3. Da ein neutrales Netzwerk wie ein Gemeingut funktionieren würde, müsse ein Provider in der Lage sein, die Bandbreitennutzung bestimmter Anwender gezielt einzuschränken, um für alle Anwender dieses Netzes maximale Leistung zu gewährleisten.

Service Provider in den USA haben sich bisher gegen diese Argumentation ausgesprochen und planen keine Änderung ihrer Preispolitik. Gründe dafür sind zum einen aufwendige Abrechnungsverfahren und der erhebliche technische Aufwand zur Implementierung solcher Mechanismen, und zum anderen der Preiskampf zwischen Mitbewerbern, die weniger stark regulieren und daher abwandernde Kunden gewinnen könnten. Stattdessen schlagen sie vor, Content Provider stärker für hochwertige Inhalte zu belasten und die Kosten an die Kunden weiterzugeben. Dabei vergessen sie offenbar, daß die Service Provider bereits jetzt Mehrkosten für das Hosting von Daten der Content Provider abrechnen.

Befürworter und Gegner

Bisher haben mehr als eine Million Menschen die Petition für die Aufrechterhaltung der Netzwerkneutralität unterzeichnet. Desweiteren sind mehrere namhafte Unternehmen starke Verbündete für den Kampf um Netzwerkneutralität, darunter IAC/InterActiveCorp, Ebay, Amazon, Yahoo!, Earthlink und vor allem Google. Auf Seiten der gemeinnützigen Organisationen haben Moveon.org, Consumer Federation of America, AARP, American Library Association, Gun Owners of America, Public Knowledge, the Media Access Project, Free Press, the Christian Coalition (PDF) und TechNet eine Allianz für Netzwerkneutralität gebildet und schließlich hat sich auch Tim Berners-Lee zu Wort gemeldet.

Natürlich müssen wir auch nicht lange nach starken Gegnern der Netzwerkneutralität suchen. So sind die Unternehmen der Bell-Gruppe ganz vorn mit dabei. Sie und große Kabelnetzbetreiber sehen in der De-Regulierung eine auferzwungene Pflicht zur Unterstützung des ersten Verfassungszusatzes, der freie Meinungsäußerung zusichert, aber Gerichtsverfahren wie FCC gegen Turner zeigten, daß sie selbst nicht verpflichtet sind, Inhalte, wenn auch nur passiv, zu unterstützen, wenn sie nicht mit ihnen konform gehen. Auch die gemeinnützigen Organisationen Freedom Works Foundation, National Black Chamber of Commerce, Progress and Freedom Foundation und der einflußreiche Think Tank New American Century (PNAC) sprechen sich gegen ein neutrales Netzwerk aus.

Interessanterweise hat sich der Finanzsektor sehr zurückgehalten, doch Beobachter hoffen, daß insbesondere die stark vom Internet abhängigen Banken bald in die Debatte eingreifen sobald sie beide Seiten genau abgewogen haben.

Beispiele für regulative Eingriffe durch ISPs

Die Bewegung SaveTheInternet.com hat einige Beispiele für diskriminatorische Eingriffe durch ISPs auf ihrer Website:

• Im Jahr 2004 hat der ISP Madison River aus North Carolina Kunden den Zugang zu ihrem Netz mittels eines rivalisierenden Web-basierten Telefondienst untersagt.
• Im Jahr 2005 hat Kanada’s Telefonriese Telus Kunden den Zugriff auf eine Website untersagt, die die Gewerkschaft der Telekommangestellten während eines Arbeitskampfes unterstützte.
• Der Kanadische Dienstanbieter Shaw reduziert gezielt die Qualität und Zuverlässigkeit konkurierender Anbieter von Internet-Telefonie. Auf diese Weise zieht das Unternehmen die Kunden auf ihre Seite, aber nicht weil der Dienst besser ist, sondern weil er die Konkurrenten einfach schlecht aussehen läßt.
• Im April diesen Jahres hat AOL den Zugang zur Website www.dearaol.com untersagt, die AOL’s Absicht ein sog. Pay-to-send-Email-Schema einzurichten, bei dem Anwender für jede Email einen Obulus zu entrichten hätten.

Resourcen im Internet

Einige Links zu ausgewählten Informationsquellen zum Thema Netzwerkneutralität:

Wissenschaftliche Abhandlungen

• Network Neutrality, Broadband Discrimination by Tim Wu, original paper on Network Neutrality
• Broadband Debate, a User’s Guide’ by Tim Wu
• Would Mandating Broadband Network Neutrality Help or Hurt Competition? A Comment on the End-to-End Debate by Christopher Yoo, Vanderbilt University School of Law
• Toward an Economic Framework for Network Neutrality by Barbara van Schewick

Offizielle Dokumente, Ansprachen und Aussagen

• U.S. House Record of the Roll Call Vote on the Markey Amendment
• Lessig’s testimony to the Senate Committee on Commerce, Science and Transportation, February 7, 2006
• Tim Wu & Lawrence Lessig Letter to the FCC
• Michael Powell Speech
• Net Neutrality: Let’s Look Before We Leap: Remarks of Assistant Secretary of Commerce Nancy J. Victory to the Progress and Freedom Foundation Conference
• The FCC’s Net Neutrality guidelines

Nachrichten und Artikel

• "House Rejects Net Neutrality" by John Nichols, The Nation, June 9, 2006
• "Defeat for Net Neutrality Backers" by Tom Lasseter, BBC, June 9, 2006.

Abhandlungen von politischen Organisationen

• A Comprehensive Study of the Effects of Net Neutrality on Consumer Choice, from Freedom Works (PDF)
• "Whose Property is it?" From the Center for Global Economic Growth
• Cato Institute Paper on Network Neutrality
• (PDF) Network Neutrality: A Broadband Wild West?, Sandvine.com (network equipment company)
• (PDF) The Economics of Network Neutrality, Robert Hahn and Scott Wallsten, AEI-Brookings Joint Center for Regulatory Studies

Artikel und Webseiten von Befürwortern der Netzwerkneutralität

• A Note to Google Users on Net Neutrality – Google CEO Eric Schmidt’s open letter to Google users
• It’s Our Net – a pro-regulation campaign financed by service providers Google, Yahoo, Microsoft, eBay and Amazon
• SaveTheInternet.com – a pro-network neutrality coalition financed by Free Press and several political actions groups such as Moveon.org and the Christian Coalition of America
• NYCwireless’ Network Neutrality Broadband Challenge

Artikel und Webseiten von Gegnern der Netzwerkneutralität

• Choose Your Cable
• DontRegulate.org – an anti-regulation campaign financed by telecommunication companies, using a cartoon created by Odd Todd
• The Future Faster Net Neutrality Campaign – an anti-regulation coalition of communications and high-tech industry leaders, civic groups and other associations.

Kommentare und Blogs

• Essay on net neutrality from comtechnews.net blog
• Neutrality of the Net, Tim Berners-Lee
• Network Neutrality Wireless Community blog
• Network Neutrality James Seng, CircleID
• You’ve Already Paid $2,000 For A Fiber Connection You’ll Never Get, techdirt.com

Auflistungen von Artikeln

• List of anti-regulation articles and editorials from Mises Institute blog
• Center for Digital Democracy, The Assault on Network Neutrality
• The Net Neutrality Debate, voip-news.com An early article on the current network neutrality debate

Einführung

Zu Beginn möchte ich kurz auf die Gundlagen eingehen. Muß ein DWDM-Netzwerk manuell rekonfiguriert werden, kann diese Aufgabe schnell mal Wochen oder gar Monate in Anspruch nehmen. Mit den wachsenden Anforderungen an das Netzwerk, wird das nicht gerade erleichtert und reicht heute nicht mehr aus.

Die Lösung liegt in ROADMs. Geräte, die Netzwerkbetreibern erlauben, einzelnen optischen Switches mitzuteilen, welche Wellenlängen in das Netzwerk aufgenommen und welche daraus entfern werden sollen. Diese Technik könnte Carriern eine ganze Menge Geld sparen, da die gefürchtete Rolle auf dem LKW nicht mehr benötigt wird und damit schneller Gewinn aus den Investitionen zurückfließen kann.

Der Markt für ROADMs könnte bald in neue Höhen aufsteigen. Eine Infonetics-Studie von 27 bedeutenden Telekommunikationsnetzbetreibern (Carriern) hat gezeigt, das fast alle (26 von 27) in den nächsten Jahren auf ROADM setzen werden. Rund 25 Prozent der befragten Unternehmen, planen die Einführung erster ROADMs sogar in den nächsten zwölf Monaten. Erste Schätzungen ergeben einen Markt für 2004 von rund 85 Millionen Dollar, so Michael Howard, Präsident von Infonetics Research, Inc. und Hauptauthor dieses Berichtes.

Viele prominente Unternehmen sind derzeit entweder in Vertragsverhandlungen oder haben bereits Verträge mit Herstellern von ROADMs geschlossen, darunter AT&T , SBC Communications Inc. und Verizon Communications Inc. . Natürlich dürfen offene Bekenntnisse zur ROADM-Technologie von namhaften Herstellern nicht fehlen. So ließ sich auch Cisco Systems Inc. nicht lumpen und kündigte neue Produkte mit ROADM-Fähigkeiten an.

"Jeder Mensch und sogar sein Hund werden in kurzer Zeit eine ROADM-Geschichte zu erzählen haben", scherzt Rob Lane, Vizepräsident der Marketing und Business Development Unit beim ROADM-Startup Tropic Networks. "Nun da Service Provider gezeigt haben, daß ROADM tatsächlich Wirklichkeit ist, beeilen sich alle, den Vorsprung aufzuholen".

An dieser Stelle entfaltet der Infonetics-Bericht seinen Nutzen, denn er hilft Entscheidern, den schnell wachsenden Markt leichter verfolgen zu können, indem die Hersteller von ROADM-Bauteilen, sowie deren Komponentenzulieferer (wie etwa Wellenlängenblockierer und einstellbare Filter) genannt werden.

ROADM-Architekturen

Momentan existieren zwei Kernarchitekturen für rekonfigurierbare optische Add/Drop Multiplexer:

• Broadcast and Select
• Demultiplexing, Switching, Multiplexing

Broadcast and Select

Diese Art des ROADM-Designs hat sich als sehr populär herausgestellt und bereits früh von Herstellern wie Marconi, Ciena und anderen aufgegriffen.

Broadcast and Select

Doch wie funktioniert das? Obige Abbildung zeigt den schematischen Ablauf. Das optische Signal tritt auf der linken Seite ein und wird durch einen Splitter gleichmäßig auf zwei Pfade aufgeteilt. Der untere Pfad ist für den Drop-Kanal, die durch einstellbare Filter (tunable filters) ausgewählt werden. Im anderen Pfad werden Kanäle, die bereits "gedropt" wurden aus der Ausgabe des Switches ausgeschlossen. Das erledigt der sogenannte Wellenlängenblocker (wavelength blocker, WB). Anschließend werden die Kanäle durch einen anderen Kuppler für die Ausgabe zusammengeführt. Um vollständige Konfigurierbarkeit zu gewährleisten, könnten die neuen Kanäle durch einstellbare Laser eingefügt werden.

Ein Grund warum Hersteller diese Architektur so bereitwillig aufgriffen ist der geringe Verlust beim Einfügen neuer Wellenlängen im Gegensatz zu herkömmlichen Switch-Fabrics wie beispielsweise MEMS (micro-electro-mechanical Switches). Dieser Vorteil wird nur solange bestehen, bis andere Techniken verbessert werden und mit ähnlichen, wenn nicht sogar besseren Werten aufwarten können.

Ein zweiter Grund könnte in der geringeren Anzahl benötigter Komponenten im Vergleich zu Alternativen liegen. Schließlich reduzieren das die Kosten weiter und erhöht die Chancen auf dem Markt.

Demux, Switch, Mux

Eine weitaus traditionellere Architektur basiert auf Multiplexern und Schalungsgeflechten (switching fabrics). Alle eintreffenden Wellenlängen müssen aufgesplittet (demultiplexing) werden, auf den entsprechenden Pfad geschaltet (switching) und anschließend weider kombiniert (multiplexing) werden. Die Funktionalität entspricht also der eines einfachen optischen Standardswitches, wobei nur ein paar Extras auf Seiten des Netzwerkmanagements hinzugefügt wurden. Der Vorgang wird in folgender Abbildung dargestellt.

Demultiplexing, Switching, Multiplexing.

Komponentenhersteller sind ein wichtiger Schlüssel für die ROADM-Architekturen. Aus diesem Grund finden Sie nun im übrigen Teil des Artikels eine Auflistung der wichtigsten Lieferanten und Hersteller von Komponenten und Bauteilen, wie etwa Switching Fabrics, Wellenlängenblocker oder einstellbare Filter.

Hersteller von ROADM-Komponenten

Alcatel SA (NYSE: ALA, Paris: CGEP:PA)

• Produktbezeichnung: nicht verfügbar

Ciena Corp. (Nasdaq: CIEN)

• Produktbezeichnung: Corestream Agility
• Produktinformationen:
  www.ciena.com

Cisco Systems Inc. (Nasdaq: CSCO)

• Produktbezeichnung: ONS 15454 Multiservice Transport Platform
• Produktinformationen: www.cisco.com

Cisco führte ein ROADM-Feature bei seinen ONS 15454er bei der Supercomm Im Juni. Cisco’s ROADM verarbeitet 32 Wellenlängen und erlaubt somit das Aufsschalten oder Ausgliedern bei jeder beliebigen Permutation. Es ist in zwei Teile gegliedert: eine Karte mit doppelter Länge für den Wellenlängen-sensitiven Switch und einer Karte für den Demultiplexer. Angeblich ist stammt die Technologie nicht aus eigenem Hause, aber Cisco sagt nicht, wer der Entwicklungspartner ist.

Fujitsu Network Communications Inc. (FNC)

• Produktbezeichnung: Flashwave 7500
• Produktinformationen: www.fujitsu.com

Fujitsu hat mehrere ROADMs auf den Markt gebracht: erst kürzlich veröffentlichten sie eine Erweiterung für den Flashware 7500 DWDM das es um ROADM-Funktionalität ergänzt. Momentan bietet Fujitsu filterbasierte OADMs in Dünnfilmtechnologie an, die Teil ihrer Metro-DWDM-Produktpalette sind.

Marconi Corp. plc (Nasdaq: MRCIY, London: MONI)

• Produktbezeichnung: PMA32
• Produktinformationen: www.marconi.com

Marconi hat 1998 mit dem PMA8 das erste ROADM-Produkt überhaupt auf den Markt gebracht. Sein Nachfolger, PMA32, war das mit Abstand das erfolgreichste Produkt von Marconi, das gleich mehrere der Geräte an die British Telecom verkaufen konnte. Die ROADMs verwenden die Broadcast-and-Select-Architektur. Ursprünglich kamen flüssigkristallbasierte Wellenlängenblocker des Unternehmens Corning zum Einsatz, das die Produktion allerdings einstellte.

Meriton Networks Inc.

• Produktbezeichnung: 7200 Optical Add/Drop Switch (OADX)
• Produktinformationen: www.meriton.com

Auf der Supercomm gab Meriton bekannt, daß von nun an alle Geräte der Serie 7200 OADX rein optisch konfigurierbar sein. Das Subsystem wird von Capella Photonics Inc. geliefert.

Movaz Networks Inc.

• Produktbezeichnung: RAYROADM
• Produktinformationen: Noch nicht auf Movaz’s Website vorhanden.

Auch Movaz gab auf der Supercomm die Aufnahme von ROADM-Produkten in das Portfolio bekannt. Das RAYROADM getaufte Kind ist eine Metro-Box, die jede Wellenlänge und jede Kombination von bis zu 40 Wellenlängen rekonfigurieren kann. Sie kann entweder als eigenständiges Produkt oder als Upgrade erworben werden. Desweiteren gab das Unternehmen bekannt, eine Partnerschaft mit Lucent Technologies und Motorola Inc. eingegangen zu sein.

Nortel Networks Ltd. (NYSE/Toronto: NT)

• Produktbezeichnung: Common Photonic Layer
• Produktinformationen: www.nortelnetworks.com

Nortel integriert die ROADM-Funktionalität im Common Photonic Layer, einer DWDM-Plattform, die ebenfalls auf der Supercomm vorgestellt wurde. Weitere Informationen sind mir noch nicht bekannt.

OpVista Inc.

• Produktbezeichnung: MetroVista 100 and 2000. WaveMaster element management system.
• Produktinformationen: www.opvista.com

OpVista taufte ihr Product MetroVista, das sich hauptsächlich an Kabelnetzbetreiber richtet und bereits im May 2003 erstmalig vorgestellt wurde. Es setzt eine Technik ein, die jeden Einsatz optischer Switches überflüssig macht, indem alle Wellenlängen in alle Verteiler des Netzwerkes eingespeist werden. Der Empfänger an jedem Hub wird auf die jeweilige Wellenlänge feineingestellt; natürlich über remote.

Siemens AG (NYSE: SI, Frankfurt: SIE)

• Produktbezeichnung: Surpass HiT 7500
• Produktinformationen: www.siemens.com

Tropic Networks Inc.

keine Infos verfügbar.

Hersteller von ROADM-Komponenten:

Switches

Schlüsselkomponenten für Mux/SW/Demux-ROADMs sind optische Switches und Wellenlängen-Demultiplexer. Einige Switching-Technolgien können in Multiplexing-Technologien integriert werden um vollständige ROADM-Subsysteme auf einem Chip zu entwickeln.

Kleine Switches (1×2, 2×2, etc.)

• Accelink Technologies Co. Ltd.
• AC Photonics Inc.
• Agiltron Inc.
• Alliance Fiber Optic Products Inc.
• AOC Technologies Inc.
• Civcom Inc.
• DiCon Fiberoptics Inc.
• DuPont Photonics Technologies LLC
• JDS Uniphase Corp. (Nasdaq: JDSU, Toronto: JDU)
• Oplink Communications Inc. (Nasdaq: OPLK)
• SK Opto-Electronics Inc. (SKOE)
• SpectraSwitch Inc.

Matrix-Switches (8×8 und größer)

• Advanced Optical MEMS Inc. (AOMEMS)
• Calient Networks Inc.
• Chromux Technologies Inc.
• Continuum Photonics Inc.
• DuPont Photonics Technologies LLC
• Fujitsu Ltd.
• Lynx Photonic Networks
• Polatis Ltd.

Rekonfigurierbare OADMs

• Active Optical Networks, Inc. (Produkte geplant)
• Alliance Fiber Optic Products Inc. (Nasdaq: AFOP)
• Avanex Corp. (Nasdaq: AVNX)
• Capella Photonics Inc.
• CoAdna Photonics Inc.
• DuPont Photonics Technologies LLC
• LightConnect Inc.
• NeoPhotonics Corp.

ROADM-Komponentenhersteller

Blocker und Filter Broadcast and Select erfordert Wellenlängenblocker und einstellbare Filter.

Wellenlängenblocker

• Avanex Corp. (Nasdaq: AVNX)
• Bookham Technology plc
• Chromux Technologies Inc.
• CoAdna Photonics Inc.
• JDS Uniphase Corp.
• LightConnect Inc.
• Polychromix Inc.
• Xtellus Inc.

Einstellbare (tunable) Filter

• Aegis Semiconductor Inc.
• Auxora Inc.
• Avanex Corp.
• Axsun Technologies Inc.
• Chromux Technologies Inc. (partnered with NP Photonics Inc.)
• DiCon Fiberoptics Inc.
• Engana Pty Ltd.
• Iolon Inc.
• JDS Uniphase Corp.
• Lambda Crossing Ltd.
• Little Optics Inc.
• Micron Optics Inc.
• Ondax Inc.
• Oplink Communications Inc.
• Optoplex Corp.
• OZ Optics Ltd.
• Primanex Corp.
• Santec Corp.

Grundlagen

So ein Switch hat einen ziemlich einfachen Job. Er nimmt den eintreffenden Verkehr vom Eingangsport entgegen und leitet ihn über eine Geflecht oder eine Backplane weiter zum Ausgangsport (folgende Abbildung). Elektronische Switches, die Pakete mit variablen Längen, Zellen mit festen Längen und synchrone Zeitschlitze (time slots) behandeln können, existieren bereits.

Arbeitsweise eines elektronischen Switches

Ein optischer Switch auf der anderen Seite arbeitet mit Licht. Er befördert eine Wellenlänge oder einen Bereich von Wellenlängen vom Eingangsport zum Ausgangsport (nächste Abbildung).

Arbeitsweise eines optischen Switches

Damit die Switches wissen, wie sie die Entscheidungen, welches Paket, welche Zelle oder welche Wellenlänge(n) wohin weiterzuleiten ist, treffen können, bedienen sie sich unterschiedlicher Konzepte. Elektronische Switches entscheiden aufgrund der Information, die in den zu befördernden Paketen enthalten ist (folgende Abbildung).

Elektronische Switches lesen die Paketinformationen aus

Ein Ethernet-Switch ließt die Ziel-MAC-Adresse aus und weiß somit, auf welchem Port das jeweilige Paket weiterzuleiten ist. Ein IP-Switch oder -Router benutzt dazu die IP-Adresse des Empfängers. Ganz ähnlich geht auch ein MPLS-Router (Multi-Protocol Label Switching) oder -Switch vor, denn er ließt das äußerste Label des Pakets aus, nachdem ein Label Switch Path (LSP) innerhalb des Netzwerkes etabliert wurde.

Ein optischer Switch funktioniert wie ein analoges Gerät. Es erkennt keine Bits und schert sich auch nicht um Pakete oder Frames. Die einzige Grundlage zur Entscheidungsfindung ist die Wellenlänge des eintreffenden Lichts (siehe vorherige Abbildung).

Optische Switches nutzen die Wellenlängen zur Weiterleitung

Da die meisten optischen Switches in DWDM-Installationen (Dense Wave Division Multiplexing) eingesetzt werden, müssen wir uns überlegen, wie die einzelnen Wellenlängen aufgespaltet werden können, um anhand einer Wellenlänge eine Entscheidung treffen zu können. Aus der vorherigen Abbildung geht hervor, wie die eintreffende Wellenlänge von einem Detektor erkannt und in ein elektronisches Signal (also in Elektronen) umgewandelt wird, um hinterher wieder ein Paket, einen Rahmen, eine Zelle oder einen Zeitschlitz zu formen.

Die Empfänger sind breitbandig. Das bedeutet, wenn zwei oder mehr Wellenlängen auf einen spezifischen Empfänger treffen, wird das resultierende Signal eine verstümmelte Kombination aller Wellenlängen aller Kanäle sein.

OEO oder OOO?

In den Monaten unmittelbar vor dem vermeintlichen technologischen Zusammenbruch des Jahres 2000, konnte das Hinzufügen des Wortes "optisch" zu den Produktnamen dafür sorgen, daß der Aktienwert des Unternehmens beachtliche Steigerungen verzeichnete. Dadurch erfuhren auch die Marketing-Abteilungen einen neuen Höhenflug und warteten mit sehr kreativen Bezeichnungen von Technologien und Produkten auf.

Eine der amüsantesten Versuche, ein bestimmtes Thema zu pushen, war der Begriff "OEO", der für Optical-Electrical-Optical steht. Bei dieser Art von Switch traten die Eingangssignale als optische Signale (Photonen) auf, wurden durch eine interne Logik in elektrische Signale umgewandelt, um über die interne elektrische Backplane an den Ausgangsport geleitet zu werden, wo sie vor der Ausgabe erneut in optische Signale konvertiert wurden.

Wenn Ihnen diese Technik bekannt vorkommt, müssen Sie nicht überrascht sein, denn genau diese Vorgehensweise liegt FDDI, SONET/SDH-Crossconnects, ATM, Ethernet-Switches und Routern mit ATM/FDDI/POS-Schnittstellen zu Grunde und haben sich nun seit mehr als eine Dekade bewährt. Dennoch wurde der Term OEO den "neuen" SONET/SDH-Geräten mit auf den Weg gegeben.

Der Vorteil von OEO war die wohl erprobte Technologie. Wir erhalten als Bonus quasi eine vollständige Digitale Regenerierung des Signals (Reshaping, Retiming und Synchronisierung) durch die optisch/elektrische Konvertierung. Die Kehrseite ist, daß die Elektronik nicht dauerhaft mit der wachsenden Kapazität optischer Mechanismen Schritt halten kann.

Als digitale Geräte sind OEO-Switches außerdem auch abhängig von der Bitrate und benötigen einen passenden Protokollstapel (protocol stack), damit bestimmte Protokolle überhaupt geroutet werden können. Beispiele sind sicherlich IP in POS (Packet over SONET), ESCON (IBM’s Enterprise System Connection Protocol) oder Fibre Channel.

Die Abkürzung OOO ist aus einer relativ jungen Entwicklung hervorgegangen. Dabei handelt es sich um ein vollständig analoges Gerät, bei dem beide E/A-Module und die Backplane optisch sind. Der größte Vorteil dieser Technik ist die bessere Skalierbarkeit gegenüber OEO-Geräten. Tatsächlich sind solche all-optical Switches nicht bitratenabhängig und vollständig protokolltransparent.

Dennoch müssen wir beachten, daß die meisten Technologien vollständig optischer Switches sich noch immer entwickeln und momentan nur in einer "sub-optimalen" Form vorliegen. Aktuell haben wir "nur" eine Granularität auf Ebene von Wellenlängen (Lambda-Level Granularity) und können nicht weiter differenzieren. Als reines analoges Gerät haben wir keinen Überblick über die Fehlerbitrate (Bit Error Rate, BER), was Monitoring und Festlegung auf Service-Level Agreements zu einer Herausforderung macht. Außerdem müssen wir Verstärkung im Gegensatz zur Regenerierung zur Erneuerung bzw. Auffrischung der Signal einsetzen. Das mag vielleicht aus Kostengründen ein Vorteil sein, doch wirft es völlig neue Aspekte im Netzwerkdesign auf.

Um die Verwirrung noch weiter auf die Spitze zu treiben, brachten findige Experten den Begriff OEO-O-OEO ins Spiel. Das ist ein interessanter Kompromiss aus den beiden anderen Techniken. Anstatt eine elektronische Backplane zu verwenden, findet die elektronische Konvertierung innerhalb der E/A-Module statt. Damit wird etwas Druck von dem Argument Skalierung genommen, da die Kapazität eines einzelnen E/A-Moduls immer geringer sein wird, als die Gesamtkapazität einer optischen Backplane.

Durch die Verlagerung der elektronischen Stufe in die E/A-Module erhalten wir eine 3R-Regenerierung (Reshaping, Retiming und Resynchronisierung) und die Fähigkeit, Wellenlängenübersetzungen vorzunehmen. Somit steht auch der Erfassung einer BER nichts mehr im Wege und wir können außerdem ein OEO- oder ein OOO-Modul auf Portbasis einsetzen, je nachdem, was unser Netzwerk erfordert.

Nachteilig wirkt sich allerdings die steigende Komplexität dieses Designs gegenüber eines OEO- oder OOO-Switches aus. Desweiteren sind die elektronischen Stufen in den E/A-Modulen isoliert und erschweren damit das Multiplexing und Grooming (im Sinne von Verwalten).

Optisches Routing mit GMPLS

Die IETF (Internet Engineering Task Force) arbeitete bis etwa Ende Juni 2004 an einem Standard, der eine vereinheitlichte MPLS-Architektur darstellen sollte. Das ganze läuft auch heute noch unter der Bezeichnung Generalized MPLS" (GMPLS).

Multi-Protocol Label Switching stellt einen einfachen Weg dar, logische Verbindungen über paketbasierte Netzwerke aufzusetzen. GMPLS wird die in MPLS definierten Kontrollprotokolle ausweiten, so daß sie zur dynamischen Kontrolle der SONET/SDH- und DWDM-Ausrüstung eingesetzt werden können.

Der GMPLS-Draft definiert eine neue Taxanomie, zur Etablierung einer Vereinheitlichung der Fähigkeiten eines "älteren" SONET/SDH- und DWDM-Switches. Der Draft spricht von vier Interface-Varianten: PSC, TDM, LSC und FSC.

Packet Switch Capable Interfaces

Ein PSC-Interface kann Bits erkennen und damit auch Pakete und Zellen in einem Bitstrom. Der Switch kann daher Entscheidungen zur Weiterleitung basierend auf dem Inhalt der Adressfelder tätigen, wie zuvor im Abschnitt 1 "Grundlagen" beschrieben.

Eine wichtige Annahme ist, daß diese Art der Schnittstelle außerdem in der Lage ist, Kontrollnachrichten (wie etwa Routing und Signalisierungsnachrichten) zu verarbeiten, die quasi In-Band mit den Daten übertragen werden. Aus diesem Grund werden die meisten PSC-Schnittstellen in konventionellen Ethernet-, IP- und ATM-Switches zu finden sein.

Time-Division Multiplexing Interfaces

TDM-Schnittstellen erkennen ebenso wie PSC-Interfaces Bits. Doch in diesem Fall basiert die Erkennung auf einer wiederkehrenden, regelmäßigen Rahmenstruktur, die in einem synchronen Bitstrom vorhanden ist. Somit können TDM-Switches Daten weiterleiten oder andere Operationen auf Basis der aktuellen Position im Zeitschlitz (time slot) ausführen.

Wie PSC-Schnittstellen, ist ein TDM-Interface in der Lage, Routing- und Signalisierungsnachrichten (control plane messages) zu verarbeiten. Beispiele für TDM-Anwendungen sind SONET/SDH-ADMs, Digital Crossconnects (DCX) oder Optical Crossconnects (OXC).

Lambda-Switch Capable Interfaces

Eine LSC-Schnittstelle arbeitet vollständig analog. Diese Schnittstellen sind naturgemäß nicht in der Lage, Bits oder andere hochwertigere Strukturen, wie etwa Rahmen oder Pakete zu erkennen. Die Weiterleitung geschieht durch das Aufschalten eines Lichtstromes auf Basis seiner Wellenlänge oder eines Bereichs von Wellenlängen (Bänder bestehend aus zwei oder mehr Kanälen).

Im Gegensatz zu den beiden vorangegangenen Varianten sind vollständig analoge Geräte nicht in der Lage, Control Plane Messages auszuwerten. Beispiele für den Einsatz von LSC-Schnittstellen sind vollständig optische ADMs oder optische Crossconnects (OXC).

Fiber Switch Capable Interfaces

FSC-Schnittstellen bilden die vierte Gruppe der GMPLS-Schnittstellen. Auch diese Variante erkennt keine Bits oder gar Rahmen oder Pakete. Außerdem ist es nicht für die Auswertung von Wellenlängen oder Wellenbändern ausgelegt. Die Daten werden zu den Ports auf Basis ihrer tatsächlichen physikalischen Position in der realen Welt weitergeleitet. Schließlich, wie sollte es auch anders sein, sind FSC-Schnittstellen nicht in der Lage Control Plane Messages zu verarbeiten.

Schlussfolgerung

Verbindungen in einem GMPLS-basierten Netzwerk werden als LSPs (Label Switched Paths) bezeichnet. Dieser Begriff schließt folgende Fakten ein:

• Virtuelle Kreise (circuits) oder Pfade in paket-/zellgeschalteten Netzwerken können LSPs sein.
• Kreise (circuits) oder Kanäle in SONET/SDH-Netzwerken.
• Ketten von Wellenlängen, werden in DWDM-Netzen als optical channel trails bezeichnet.
• Ketten von Fibern, die als Fiber Paths im PHY-Layer von Telekommunikationsnetzwerken vorliegen.

Während eine Vereinfachung der Terminologie vorteilhaft ist, so können wir die Tatsache nicht verbergen, das ein Pfad von einem LSC- zu einem PSC-Interface nicht gültig ist. Die Definition der IETF sieht vor, daß ein LSP in dem Interfacetyp enden muß, von dem er gestartet ist.

Anwendungen vollständig optischer Switches

Die Hauptanwendungsbereiche von vollständig optischen Geräten liegt in der Anbindung von optischen Kernnetzwerken an beispielsweise Metro-Networks oder der Absicherung von Verbindung innerhalb oder zwischen zwei optische Netzwerken. Für diese Aufgaben stehen uns unterschiedliche Geräte zur Verfügung.

• Protection Switches: weit verbreitet. Normalerweise als 1×2-Einheit verfügbar. Werden als Sicherung gegen den Totalausfall einzelner Glasfaserleitungen, wie etwa der Bruch einer solchen oder dem Ausfall eines Verbinders.
• Optische Add/Drop Multiplexer (OADMs): sie fungieren meist als Zugangspunkte von optischen Netzwerken. Hier werden einzelne Wellenlängen aufgeschaltet oder umgeleitet, wobei das Signal sowohl von einer PSC- oder TDM-Schnittstelle innerhalb des OADMs stammen kann.
• Optische Crossconnects (OXCs): dienen als Kreuzungen optischer Netzwerke. Sie nehmen im Wesentlichen die Aufgaben von Routern oder ATM-Switches an.

In naher Zukunft könnten auch noch folgende Varianten das Tageslicht erblicken:

• Optical Burst Switches: erlauben Telekommunikationsnetzbetreiber (carrier) einzelne Ketten von Wellenlängen über einzelne Netzwerke hinaus zu etablieren, so wie es OXCs bereits heute anbieten.
• Optische Packet Switches: Verarbeiten Pakete auf optischer Basis auf die gleiche Weise, wie es heutzutage die elektronischen Switches tun.

Herausforderungen

Optisches Switching ruft viele neue Herausforderungen auf den Plan, doch zwei von ihnen sind wirklich schwer lösbar: Lesen und Verarbeiten der Bits bei extrem hohen Geschwindigkeiten und optische Pakete zu Puffern um sie Multiplexen (Aufschalten auf andere Kanäle) zu können.

Lesen und verarbeiten der Informationen

Mit traditionellen elektronischen Switches, wie beispielsweise IP-Routern oder ATM-Switches, agiert das Gerät im so genannten Store-and-Forward-Modus. Das Verfahren wird anhand folgender Abbildung illustriert (folgende Abbildung).

Store and Forward elektronischer Switches

Wenn Daten am Eingangsinterface eintreffen (1), wird die gesamte Dateneinheit zunächst in einem Input Buffer zwischengespeichert (2). Noch in diesem Buffer wird die Adresse oder das Label ausgewertet (3), so das der Router oder Switch eine Weiterleitung zum Ausgangsport vornehmen kann (4).

Die schnellsten heute verfügbaren Geräte arbeiten mit bis zu 10 Gbps, auch wenn bereits seit geraumer Zeit 40-Gbps-Schnittstellen für SONET/SDH verfügbar sind. Dennoch sind 10 Gbps das derzeitige Limit, da die Prozessoren die Routing-Informationen nicht schneller verarbeiten können.

Die Entwicklung zum vollständig optischen Switchings geht mit der Überwindung dieser Grenzen einher. Doch optische Switches benötigen noch immer die Fähigkeit, Lambda-Pfade durch das Netzwerk aufzusetzen, was die Notwendigkeit, Routing- und Signalisierungsnachrichten zu verarbeiten, einschließt.

Buffering optischer Pakete

In elektronischen Switches ist die Situation alltäglich: eine Dateneinheit erreicht den Eingangsport und muß sich in die Reihe bereits auf Verarbeitung wartender Pakete einreihen. Große Zwischenspeicher vereinfachen die Auflösung solcher Engpässe und erlauben statistisches Multiplexing (d.h. Verbindungen werden nach Wahrscheinlichkeit des tatsächlichen Nutzens hergestellt) und die Kapazitätsüberbuchung (z.B. wenn mehrere Dateneinheiten gleichzeitig an verschiedenen Ports eintreffen, aber den gleichen Ausgangsport passieren müssen).

Bei ATM-Switches ist der Mechanismus sogar noch ausgefeilter. Diese Geräte verfügen über intelligente Output Buffer, die es ihnen erlauben, unterschiedliche Warteschlangen (queues) pro Verbindung zu verwalten. Somit können diese Warteschlangen unterschiedlich abgearbeitet werden, je nach garantierter Bandbreite, Priorität oder anderer Kriterien. Aus diesem Grund sind ATM-Switches die einzigen ihrer Art, die ein netzwerkweites QoS-Schema etablieren können.

Die Kernfrage in Sachen optischen Switchings ist nun: wie speichere ich Photonen zwischen? Mal abgesehen von Laborexperimenten, bei denen einzelne Photonen mit Hilfe flüssigen Sauerstoffs "eingefroren" wurden, besteht die einzig praktikable Lösung in der Verwendung einer Glasfaserwarteschleife (Fiber Delay Line). Da sich Photonen zwar schnell aber mit einer begrenzten Geschwindigkeit in dem Silikatglas fortbewegen (ungefähr mit 200.000 km/s), sollte es doch möglich sein, eine bestimmte Anzahl von Photonen für einen ausreichend langen Zeitraum in dieser Warteschleife zu halten (vorausgesetzt natürlich, diese Schleife ist selbst auch lang genug). Eine kurze Überlegung sollte uns einen Überblick über die zugrunde liegenden Zeiten für solche Operationen geben. Ein Ethernet-Rahmen ist im Schnitt 10 Kb lang (manchmal länger, manchmal kürzer, 10 Kb rechnet sich aber recht gut). Wenn wir einen Rahmen mit 10 Gbps transportieren, sollte dieser Rahmen also etwa 200 Meter Glasfaser für sich beanspruchen. Bei 40 Gbps sind es sogar nur 50 Meter. Das Prinzip der Fiber Delay Lines ist eine direkte Analogie zum Delay Line Memory der ersten Computergenerationen und bringen leider auch die gleichen Nachteile mit. Sobald ein Paket in diese Warteschleife eingespeist wurde, müssen wir genau so lange warten, bis es wieder austritt. Wir haben es also nicht mit einer zufälligen Zugriffsmethode zu tun. Zwar können die Warteschlangen mit Hilfe hierarchischer Bäume und schnellen Switchingelementen aufgebaut werden um eine inkrementelle Verzögerung zu etablieren, doch ist diese Technik extrem komplex und erfordert einen gehörigen hardware- und softwaretechnischen Mehraufwand für jede Warteschleife.

Lambda-Switching

Manual Wavelength Provisioning

Die folgende Abbildung zeigt ein stark vereinfachtes Lambda-Netzwerk aus heutiger Zeit.

Manual Wavelength Provisioning

Ziel ist die Etablierung eines Wellenlängenpfades von einem MPLS-LSR (Label Switch Router) zum anderen. An jedem der nummerierten Punkte muß ein Operator (also ein menschliches Wesen) einen Lambda-Pfad zwischen den beiden angrenzenden Geräten einrichten. Dazu bedient er sich einer Network Management Station (NMS). Nachdem alle Geräte eines Pfades konfiguriert wurden, verfügen wir über einen vollständigen Pfad und die LSRs können ihre Arbeit aufnehmen und Verbindungen zueinander herstellen.

Diese Art der Bereitstellung bietet dem Betreiber eines solchen Netzwerkes volle Kontrolle über seine Netzwerkresourcen, doch erfordert sie einen enormen Aufwand in der Wartung und Überwachung, denn auch Backup-Pfade müssen für jeden erdenklichen Ausfallpunkt eingerichtet werden. Normalerweise wird für diese Zwecke ein Offline-Paket über den Pfad geschickt, um die Pfade neu zu berechnen und zu optimieren. Dennoch ist es immer der Operator, der die Änderungen vornehmen muß.

Es wurden eine Menge Versuche unternommen, die Konfigurationsprozesse zu automatisieren. Die einfachste Möglichkeit besteht im Einsatz eines 1×2 Protection Switches. Indem ein Signalerkennungskreis in den Switch integriert wird, kann der Failover bei Ausfall der Hauptleitung automatisch geschehen. Ausgefeiltere Designs sehen den Einsatz einer Monitoreinheit vor, die mit einem oder mehreren Protection Switches verbunden ist, um die Bitfehlerraten (Bit Error Rates) aufzuzeichnen und bei Bedarf auf den sekundären Pfad auszuweichen.

Im Gegensatz zu den Herausforderungen aus dem vorherigen Abschnitt "Herausforderungen" treten diese Probleme beim Lamda-Switching nicht auf, da wir mit den Wellenlängen arbeiten und quasi die Photonen selbst Weiterleiten und keine Interpretation (Auslesen von Adressinformationen, etc.) der Daten vornehmen. Das Statistische Multiplexing findet hier keine Anwendung, da sobald eine Wellenlänge eingerichtet wurde, sie exklusiv für einen Eingabestrom genutzt wird und damit kein statistisches Multiplexing eingerichtet werden kann.

Automatische Wellenlängenbereitstellung (Automatic Wavelength Provisioning)

Die manuelle Einrichtung von Pfaden ist nicht gerade fortschrittlich und trägt der schnellen Entwicklung der Netzwerke Rechnung. Die Industrie hat daher ein Verfahren zur dynamischen Konfiguration von Lambda-Pfaden entwickelt, bei dem ein generalisiertes MPLS-Protokoll (GMPLS) zum Einsatz kommt. In einem solchen GMPLS-Netzwerk verbinden sich die elektronischen Geräte über eine optische Benutzernetzwerkschnittstelle (O-UNI, optical User Network Interface) miteinander. Die Kontrollinformationen, welche In-Band übertragen werden, werden durch das O-UNI geleitet (folgende Abbildung).

Automatic Wavelength Provisioning

Innerhalb der optischen Abschnitte sind nur LSC-Switches enthalten und daher nicht in der Lage, Control Plane Messages zu verarbeiten. Die erste Lösung dieses Problems liegt in der Verwendung von Out-of-Band-Signalen zur Verbindung der LSC-Geräte, normalerweise über Fast Ethernet auf dem PHY-Layer.

In einem GMPLS-Netzwerk brauchen wir uns keine Gedanken über die Auswertung er Bits machen denn wie verwenden für die Control Planes Out-of-Band-Signale. Desweiteren müssen wir auch nicht auf das Buffering achten, denn die Wellenlängen werden nicht statistisch aufgeschaltet, wenn sie erst einmal etabliert wurden.

Mit Lambda-Switching wird die Wellenlänge als einzige Information zur Weiterleitung der Ströme verwendet. Das bedeutet, daß die Wellenlänge irgendwie gemessen werden muß. Wenn wir also die Photonen eines gewissen optischen Stromes an irgendeinem Punkt in elektronische Signale umwandeln wollen, müssen wir den betreffenden Strom isolieren, denn alle heute eingesetzten Receiver sind Breitbandempfänger. Die meisten Verfahren zu Wellenlängenseparation basieren auf den unterschiedlichen Geschwindigkeiten, mit denen die jeweiligen Wellenlängen das Medium durchwandern. Diese Eigenschaft erlaubt uns, verschiedene Techniken zur spatialen Wellenlängenseparation anzuwenden. Beispielsweise können wir die Separation, die durch den Winkel beschrieben wird, mit Hilfe eine sog. Refracting Devices vorhersagen, wenn wir die Wellenlänge eines bestimmten Kanals kennen, sobald er in das Netzwerk eingespeist wird. Geräte mit diesen Fähigkeiten setzen dazu Prismen, Filter und Gitter ein. Diese Bauteile sind naturgemäß statisch und bedürfen eines Eingriffs durch einen Fachmann, der sie auf neue Wellenlängen justiert.

Optical Burst Switching

Schnell wurde eine Schwachstelle des Lamdba-Switching ausgemacht. Wurde eine Wellenlänge erst einmal zugewiesen, war sie exklusiv belegt. Kommt es also nicht zu einer dauerhaften 100-prozentigen Auslastung der Kapazität durch den Besitzer/Nutzer, so wird ein großer Teil verschwendet. Ganz klar eine ineffiziente Nutzung des Netzwerkes.

Eine Lösung des Problems liegt in der Anforderung einer Wellenlänge für die Dauer der Nutzung, genannt: Optical Burst Switching (OBS). Das wurde früher als große Herausforderung betrachtet, da, verglichen mit der Geschwindigkeit der Übertragung, der Auf- und Abbau einer Verbindung ein recht langwieriger Prozess ist. Das liegt daran, daß in traditionellen Übertragungssystemen wie ATM oder X.25 stets ein Mehrwege-Handshake für den Auf- und Abbau von Verbindungen nötig war. Überträgt man diese Herangehensweise auf das Optical Burst Switching, wird schnell klar, warum das kein vernünftiger Ansatz ist.

Aus diesem Grund wurde ein Mechanismus entwickelt, der momentan als die optimale Lösung dieses Problems angesehen wird. Wichtig ist dabei, daß es keine explizite Bestätigung des Verbindungsaufbaus gibt, bevor Daten übertragen werden. Bisher ist dieses Verfahren nur simuliert worden und es gibt noch keine verlässlichen Aussagen über die Auswirkung auf die Netzwerkleistung, wenn ein solches unzuverlässiges Verfahren zum Einsatz kommt.

In einem Lambda-Switch, welcher auch als LSC-Interface mit GMPLS Control Plane beschrieben werden kann, ist das Ziel, die Zeit für eine Etablierung eines optischen Pfads von Wochen auf Minuten reduzieren. Ist der Pfad bereitgestellt worden, bleibt er meist für Monate oder gar Jahre aktiv. In diesen Zeitrahmen ist es durchaus akzeptabel, traditionelle, verlässliche Signalisierungsmechanismen zu verwenden, beispielsweise RVSP (Resource Reservation Protocol) oder CR-LDP (Constraint-Based Routing-Label Distribution Protocol), die für die Verwendung mit GMPLS erweitert wurden. Die Signalisierung selbst kann hier auch Out-of-Band geschehen, wie etwa über Fast Ethernet.

Für OBS gilt es, die Lambda-Switches so zu konfigurieren, das nur ein kurzer Strom (burst) übertragen werden muß. Dieser muß durch ein OEO-Gerät gepuffert werden während das Lambda-Gerät konfiguriert wird. Überträgt man eine Datei von der Größe eines Megabytes über 10 Gbps bleibt für die Konfiguration des Lambda-Switches nur eine Millisekunde. Somit muß die Signalisierung sehr schnell sein; traditionelle Handshake-Verfahren sind nicht geeignet.

Die Signalisierung kann Out-of-Band geschehen, muß aber den Pfad folgen, der für den Burst vorgesehen ist. Auf den ersten Blick erscheint das merkwürdig, denkt man an Basic Rate ISDN (BRI). In dieser Topologie kann ein einziger D-Kanal (übernimmt die Steuerung) zur Verwaltung von bis zu 30 B-Kanälen (sie übertragen die Nutzdaten) genutzt werden. Die B- und D-Kanäle werden über das gleiche Kabel ausgeliefert und laufen deshalb über die gleiche Topologie. Im optischen Kontext würde eine Wellenlänge für die Signalisierung aufwenden und sie mit der Geschwindigkeit betreiben, die für eine vernünftige Auslastung der Netzwerkprozessoren geeignet ist, z.B Gigabit-Ethernet.

Derzeit gibt es noch einige ungeklärte Punkte bei OBS, insbesondere was den Aufbau eines verlässlichen und einfachen Signalisierungsmechanismus angeht. Doch die Vorzüge liegen auf der Hand. Dadurch daß der LSP nur für die Dauer des Bursts offen ist, können wir statistisches Mutliplexing in einer angemessenen Zeit anbieten. Das steigert die Effizienz des Netzwerkes im Vergleich zu Lambda-Switching.

Optisches Packet Switching

Das optische Packet Switching (OPS) ist ein echtes Äquivalent des elektronischen Packet Switching. Das eingebettete Label wird gelesen und eine Entscheidung über die Weiterleitung anhand der enthaltenen Informationen getroffen. Das OPS-Gerät könnte zum einen in einem verbindungslosen Modus operieren, beispielsweise durch Nutzung der IP-Adresse des Ziels. Andererseits wäre auch ein verbindungsorientierter Modus möglich,indem GMPLS-Protokolle zur Signalisierung der Pfadeinstellungen genutzt werden, wobei die eingebetteten Labels normales Switching zulassen würden.

Es sollte sich den LeserInnen die Frage aufdrängen, ob hier nicht auch das Lesen von Paketinformationen bei hohen Geschwindigkeiten zu den gleichen Problemen führen würde, wie sie bereits besprochen wurden. Ist das nicht eigentlich unvermeidlich?

Ein praktische OPS-Experiment wurde in dieser Hinsicht bereits unternommen. Es ist unter dem Titel Keys of Optical Packet Switching (KEOPS) (http://www.aramis-research.ch/d/6089.html) bekannt. Dabei handelt es sich um ein Europäisches Projekt einiger Forschungsanstalten, die von Alcatel angeführt werden.

KEOPS-Signalisierung

Eine Zeichenkette, der ein L vorangestellt wurde, ist immer eine Wide Character Constant. Intern wird zur Ablage von WC-Konstanten ein Integer-Typ verwendet, der entweder in oder definiert ist. Ebenso wie normale Zeichen mit oktalen oder hexdezimalen Escape-Sequenzen versehen werden können, funktioniert das auch mit WC-Konstanten, solange ein L vorangestellt wird.

Die Definition von Wide Character Constants unterscheidet sich nicht von der schmaler Zeichen:

wchar_t wc = L'Z';
wchar_t wmc = L'XYZ';
wchar_t *wstring = L"Hello World!";
wchar_t *x = L"Hello World";
wchar_t z[] = L"Hello World";

Im Gegensatz zur NUL-Terminierung schmaler Zeichenketten ist die Terminierung hier 32 Bit lang.

Zwar lassen sich WC-Konstanten ebenso einfach deklarieren, wie ihre schmalen Pendants, allerdings müssen wir bei der Arbeit mit breiten Zeichen auf Besonderheiten einstellen.

Nicht mallocieren

Viele Programmierer gehen bei der Arbeit mit Wide Characters vor, wie Sie es mit schmalen Zeichen gewohnt sind. Folgender Code ist in der schmalen Zeichenbreite durchaus üblich:

char* wc = (char *)malloc(4);
strcpy(wc, "abc");

Übertragen auf die breite Zeichenwelt ergeben die beiden obigen Ausdrücke nur wenig Sinn:

wchar_t* wc = (wchar_t *)malloc(4);
wcscpy(wc, "abc");

Während der erste Ausdrück zwar syntaktisch richtig ist, wird nur Speicherplatz für 1 breites Zeichen reserviert (da wchar_t als unsigned int repräsentiert wird), weil malloc nur n Bytes reserviert, in diesem Fall also 4. Desweiteren beschwehrt sich der Compiler über den Versuch eine schmale Zeichenkonstante in einen breiten Datentyp zu kopieren. Besser wäre wcscpy(wc, L"abc")

Die libc-Bibliothek sieht für die Konvertierung von schmalen Zeichenkonstanten in ihr breites Pendant die Funktion mbstowcs vor:

wchar_t* wc = (wchar_t *)malloc(8 * (sizeof(wchar_t)));
mbstowcs(wc, "abc", 4);

Breite Zeichen lesen und schreiben

Um breite Zeichen von einem Stream zu lesen, bietet sich die Bibliotheksfunktion fgetwc(3) an, die genauso verwendet wird, wir wir es von fgetwc(3) kennen:

#include <stdio.h>
#include <locale.h>
#include <stdlib.h>
 
int main(int argc, char **argv) {
    wint_t  retval;
    FILE    *fp;
    wchar_t *pwcs;
 
    setlocale(LC_ALL, "");
 
    if ((fp = fopen("file", "r")) == NULL) {
        /* Error handling */
    } else {
        /* pwcs points to a wide character buffer of BUFSIZ. */
        while ((retval = fgetwc(fp)) != WEOF){
            *pwcs++ = (wchar_t)retval;
            /* break when buffer is full */
        }
    }
    /*  Process the wide characters in the buffer  */
    return (0);
}

Das gleiche läßt sich auch über getwchar(3) sagen:

#include <stdio.h>
#include <locale.h>
#include <stdlib.h>
 
int main(int argc, char **argv) {
    wint_t  retval;
    FILE    *fp;
    wchar_t *pwcs;
 
    setlocale(LC_ALL, "");
 
    while((retval = getwchar()) != WEOF){
        /* pwcs points to a wide character buffer of BUFSIZ. */
        *pwcs++ = (wchar_t)retval;
        /* break on buffer full */
    }
    /* Process the wide characters in the buffer */
    return (0);
}

Zum zeilenweisen Einlesen von Dateien verwenden wir fgetws(3):

#include <stdio.h>
#include <locale.h>
#include <stdlib.h>
int main(int argc, char **argv) {
    FILE    *fp;
    wchar_t *pwcs;
 
    setlocale(LC_ALL, "");
 
    /* Error Handling if fopen was not successful. */
    if((fp = fopen("file", "r")) == NULL) {
        /*  Error handling  */
    } else {
        /* pwcs points to wide character buffer of BUFSIZ.  */
        while(fgetws(pwcs, BUFSIZ, fp) != (wchar_t *)NULL){
           /*
            * pwcs contains wide characters with null
            * termination.
            */
        }
    }
}

Schließlich sehen wir uns noch an, wie fputwc(3) und fputws(3) arbeiten:

#include <stdio.h>
#include <locale.h>
#include <stdlib.h>
 
int main(int argc, char **argv) {
    int     index, len;
    wint_t  retval;
    FILE    *fp;
    wchar_t *pwcs;
 
    setlocale(LC_ALL, "");
 
    /* Error Handling if fopen was not successful. */
    if((fp = fopen("file", "w")) == NULL){
        /* Error handling */
    } else {
       /*
        * Let len indicate number of wide chars to output.
        * pwcs points to a wide character buffer of BUFSIZ.
        */
        for (index = 0; index &lt; len; index++){
            if ((retval = fputwc(*pwcs++, fp)) == WEOF)
            /* write error occurred */
            break; /* errno is set to indicate the error. */
        }
    }
}

#include <stdio.h>
#include <locale.h>
#include <stdlib.h>
 
int main(int argc, char **argv) {
	int     retval;
	FILE    *fp;
	wchar_t *pwcs;
 
	setlocale(LC_ALL, "");
 
	/* Error Handling if fopen was not successful. */
	if((fp = fopen("file", "w")) == NULL){
		/*  Error handler  */
	} else {
		if ((retval = fputws(pwcs, fp)) == -1) {
			/* Write error occurred                */
			/*  errno is set to indicate the error  */
		}
	}
}

Manipulation breiter Zeichen

Folgende Bibliotheksfunktionen sind für die Verarbeitung von Wide Character Strings vorgesehen:

• wcrtomb() – Konvertiert eine WC-Konstante in ein Zeichen (wcrtomb.c)
• wcscat() – Verbindet zwei WC-Konstanten(wcscat.c)
• wcschr() – Lokalisiert ein Zeichen in einer WC-Konstante(wcschr.c)
• wcscmp() – Vergleicht zwei WC-Konstanten(wcscmp.c)
• wcscoll() – Vergleicht zwei WC-Konstanten unter Berücksichtigung der Werte in LC_COLLATE (wcscoll.c)
• wcscpy() – Kopiert eine WC-Konstante in einen breiten Speicherbereich (wcscpy.c)
• wcscspn() – Bestimmt die Länge eines komplementären Substrings (wcscspn.c)
• wcsftime() – Konvertiert Datum und Zeit in eine breite Zeichenkonstante
• wcslen() – Bestimmt die Länge einer WC-Konstante
• wcsncat() – Verbindet einen Teil einer WC-Konstante mit einer anderen
• wcsncmp() – Vergleicht einen Teil einer WC-Konstante mit einer anderen
• wcsncpy() – Kopiert einen Teil einer WC-Konstante in einen breiten Speicherbereich
• wcspbrk() – Lokalisiert eine Zeichenkette in einer WC-Konstante (wcspbrk.c)
• wcsrchr() – Lokalisiert die letzte Position eines Zeichens in einer WC-Konstante (wcsrchr.c)
• wcsrtombs() – Konvertiert eine WC-Konstante in ihr schmales Pendant
• wcsspn() – Gibt die Länge eines Substrings in einer WC-Konstante aus (wcsspn.c)
• wcsstr() – Lokalisiert eine Zeichenkette in einer WC-Konstante (exkl. NUL-Terminierung) (wcsstr.c)
• wcstod() – Konvertiert eine WC-Konstante in einen Wert mit doppelter Präzision (wcstod.c)
• wcstof() – Konvertiert eine WC-Konstante in einen Wert mit doppelter Präzision
• wcstoimax() – Konvertiert eine WC-Konstante in einen Integerwert
• wcstok() – Teilt eine WC-Konstante in Einzelteile (wcstok.c)
• wcstol() – Konvertiert eine WC-Konstante in einen long int (wcstol.c)
• wcstold() – Konvertiert eine WC-Konstante in einen Wert mit doppelter Präzision
• wcstoll() – Konvertiert eine WC-Konstante in einen long int
• wcstombs() – Konvertiert eine WC-Konstante in eine Zeichenkonstante (wcstombs.c)
• wcstoul() – Konvertiert eine WC-Konstante in einen unsigned long (wcstoul.c)
• wcstoull() – Konvertiert eine WC-Konstante in einen unsigned long
• wcstoumax() – Konvertiert eine WC-Konstante in einen Integer
• wcswcs() – Findet eine WC-Konstante (obsolet) (wcswcs.c)
• wcswidth() – Anzahl der Spaltenpositionen einer WC-Konstante (wcswidth.c)
• wcsxfrm() – Transformiert eine WC-Konstante (wcsxfrm.c)
• wctob() – Konvertiert eine WC-Konstante in ein Einzelbytezeichen
• wctomb() – Konvertiert eine WC-Konstante in eine schmale Zeichenkette (wctomb.c)
• wctrans() – Definiert das Mapping von Zeichen
• wctype() – Definiert eine Zeichenklasse
• wcwidth() – Anzahl der Spaltenpositionen eines WC-Codes (wcwidth.c)