Ethernet in Telekommunikationsnetzen erlebt in den letzten Jahren einen wahren Hype. Service Provider benötigen stets günstige Lösungen, um Kosten zu senken, die Bandbreite zu erhöhen, Benutzerschnittstellen zu vereinfachen und neue Plattformen zu entwickeln, die auf erprobten Standards basieren. Immerhin hat sich der Verkauf von Ethernet-Switches und -Routern im Carrier-Segment in den letzten Jahren verdreifacht von $194 Millionen im Jahr 2004 auf $637 Millionen im Jahr 2005 (Quelle).

Es gibt viele Möglichkeiten, Ethernet-Dienste anzubieten, doch die größte Aufmerksamkeit wurde Ethernet über Multiprotocol Label Switching (MPLS) zu Teil, zum einen weil es unterschiedliche Topologien unterstützt, wie etwa vermaschte, vollvermaschte Netzwerke und VPNs, und zum anderen weil es einige sehr nützliche Features bereit hält, wie etwa Traffic Engineering und Quality of Service (QoS).

Allerdings hat Ethernet über MPLS auch Nachteile, die zwei wichtigsten Kosten und Komplexität. Diese beiden wiederum werfen andere Probleme auf, die MPLS oftmals für den Ausbau bis ins Kundennetzwerk disqualifizieren.

Momentan sind Service Provider in der mißlichen Lage, unangenehme Kompromisse machen zu müssen, oftmals im Zusammenhang mit MPLS und Service Management. Einerseits müssen sie Geduld beweisen, in dem sie auf Standards warten, die sich in diesem Bereich durchsetzen, und andererseits sehen sie sich einer großen Nachfrage ausgesetzt, die befriedigt werden möchte. Die größeren Carrier sind besonders mangels aktiver Standards besorgt, daß sie in eine Kostenfalle geraten können, während sie ihre Netzwerke für eine größere Kundenzahl skalieren.

Ein weiterer Schwerpunkt ist die Standardisierung von Diensten über Netzwerkgrenzen hinweg. Auf diese Weise könnte beispielsweise ein Betreiber ein VPN über Ethernet mit Netzwerken anderer Betreiber, die auf anderen Technologien wie Frame Relay oder ATM basieren, etablieren und damit eine Option zur schrittweisen Migration auf Ethernet anbieten.

In diesem Artikel möchte ich die Schlüsselprobleme für Service Provider und Carrier in diesem Marktsegment beleuchten und erläutern, wie diese Probleme bei der Entwicklung von Standards berücksichtigt werden.

Anforderungen der Carrier an Ethernet-Dienste

Die meisten Carrier, die heute Frame Relay oder ATM einsetzen sind vor allem von der Flexibilität und Innovationskraft von Ethernet angetan. Dennoch wollen sie so viel wie möglich von ihren immernoch gewinnbringenden Diensten einsetzen. Das bedeutet für Ethernet im Carrier-Segment, daß es:

• Ende-zu-Ende-Dienste bieten muß
• reibungslos Dienste in andere Netzwerk integriert (Service Interworking)
• garantierte Service Level Agreements (SLA) für jeden Kunden über jedes Protokoll bieten muß
• Netzbetreiber miteinander verbinden kann (Carrier-to-Carrier Interconnection)
• Ende-zu-Ende-Verwaltung und schnelle Bereitstellung für On-Demand bietet

Und, als wenn das nicht schon genug wäre, muß Carrier-Ethernet auch noch eine breite Palette unterschiedlichster Zugangsnetzwerke unterstützen und für zukünftige Entwicklungen in diesem Bereich gewadmet sein. Ein Beispiel: Netzbetreiber verwenden als Zugangsschnittstelle für Endkunden IEEE 802.1ad (Provider Bridges) und in Metronetzen wird zunehmend auf Ethernet über SONET/SDH (X.86) oder Ethernet über MPLS gesetzt. Im Kern aber, werden Ethernet-Dienste im allgemeinen per Ethernet-Pseudowires über MPLS abgewickelt.

Im Zusammenhang mit Ethernet-Diensten hielt schnell das Buzz Word Hard QoS Einzug. Die meisten Profis in diesem Carrier-Segment die Ausarbeitung eines Hard QoS-Mechanismus für am dringensten halten. Hard QoS ist für SLAs und die Unterstützung kritischer Anwendungen. von ganz zentraler Bedeutung.

Backbone Convergence ist eine weitere Schlüsselanforderung. Netzbetreiber bieten ihren Kunden eine ganze Reihe unterschiedlicher Dienste an, darunter IP, ATM, Frame Relay, VoIP, TDM und Ethernet, jeder mit unterschiedlichen Anforderungen an das Netzwerk. Es ist extrem kostenintensiv, diese Anforderungen mit jeweils verschiedenen Netzwerken zu erfüllen.

Einige Beispiele für variierende Anforderungen:

• TDM (Time Division Multiplexing) Mietleitungen
• Unterstützung für Sprachqualität
• Schutz durch Redundanz und Elastizität.
• IP-Netzwerke
• Layer-3-Redundanz
• Protokolle wie OSPF, IS-IS, BGP und MPLS
• Inter-Provider Peering
• ATM/Frame Relay
• Cell Relay
• SVC, SPVC, PNNI, Interworking
• Inter-Provider Trunks
• VOIP/VOATM (Voice over ATM)
• Intra-LATA Sprachdienste
• Distributed Voice Switching
• Beibehaltung aktueller Sprachqualität für Legacy-Dienste
• Ethernet-Dienste
• Link-Aggregation und Vermeidung von Loops
• Point-to-Point und Layer-2 -thernet VPNs (Virtual Private LAN Service, VPLS)

In der Lage zu sein, all diese Anforderungen in einem einzigen Netzwerk zu erfüllen, anstatt mehrere parallel zu pflegen ist von unschätzbarem Wert für Netzbetreiber.

Carrier-Ethernet für die Konvergenz

Es existieren zwei fundamental unterschiedliche Wege ein konvergiertes packet-vermitteltes Netzwerk zu erschaffen:

• Das Paket verändern: Hinzufügen eines Transport-Interfaces zu paket-basierter Hardware
• Den Transport verändern: Hinzufügen eines zusätzlichen schlanken MAC-Layers zwischen die Sonet/SDH-Transportschicht, wie wir es von der Generic Framing Procedure, der Virtual Concatenation, und dem Link Capacity Adjustment Scheme kennen.

Was ist LCAS?
Das Link Capacity Adjustment Scheme (LCAS) ist ein Protokoll, das zur Anpassung von asynchronen Daten an die SDH-Hierarchie in NG-SDH eingesetzt wird. Das LCAS-Protokoll arbeitet zwischen zwei Netzelementen an der Kundenschnittstelle und bestimmt welche Gruppenmitglieder einer Virtual Concatenation Group (VCG) zur Übertragung herangezogen werden. Dieses Protokoll unterstützt eine dynamische Anpassung der Übertragungskapazität an den aktuellen Bedarf. Es erlaubt den Carriern individuelle Virtual Concatenation (VC) in einer Virtual Concatenation Group (VCG) hinzuzufügen oder zu entfernen. Damit kann die Payload einer VCG feinstufig an die tatsächlich verfügbare Bandbreite angepasst werden. Die Anpassung erfolgt für den Kunden der Trägergesellschaft unterbrechungsfrei.
LCAS ist in der ITU-Empfehlung G.7042 definiert und enthält alle nötigen Signalisierungsmechanismen und Pfadinformationen, die den Endpunkten der Verbindung mitgeteilt werden.

Das Metro Ethernet Forum (MEF) schreibt den Paketansatz vor und das meiste Equipment der Ethernet-Carrier faßt Legacy-Schnittstellen zusammen und transportiert sie über Sonet/SDH oder Ethernet/MPLS zurück. Tabelle 1 vergleicht Anforderungen der Netzbetreiber an Carrier-Ethernet mit Enterprise-Ethernet und NG-SONET/SDH.

Der entscheidende Punkt ist, daß Enterprise-Ethernet einfach nicht für Carrier-Ethernet ausgelegt ist und Sonet/SDH wichtige Eigenschaften, wie Kosten nicht aufweist, die es qualifizieren würden. Carrier-Ethernet jedoch vereint die gewünschten Eigenschaften von Enterprise-Ethernet und NG-Sonet/SDH.

Ethernet über MPLS hat für Carrier den größten Vorteil, wenn er Punkt-zu-Mehrpunkt-Dienste, beispielsweise bei einer hohen Anzahl von POPs (Point of Presence), oder wenn er viel Ethernet-Verkehr transportieren muß. NG-Sonet/SDH hingegen ist nur vorteilhaft, wenn Hub and Spoke-Dienste angeboten werden oder nur wenige POPs in Betrieb sind. EOMPLS ist also für Shared Services kosteneffektiver, während EOSonet/SDH für teure Premium-Dienste geeignet ist.

Reibungsloses Zusammenspiel?

Große Teile der Standardisierung des Multiprotocol Networking fand im MFA Forum (MPLS, Frame Relay, Alliance) statt, das ihr Augenmerk auf zwei unterschiedliche Arten der Zusammenarbeit von Ethernet mit Legacy-Diensten richtete, nämlich: Frame Relay und ATM, jeweils als Bridged Service Interworking and Routed Service Interworking. Es ist für Service Provider von extremer Wichtigkeit, daß sie beim Ausrollen ihrer Ethernet-Dienste, auf ihre existierenden Frame Relay und ATM-Infrastrukturen zurückgreifen können.

Bridged Interworking unterstützt alle Protokolle, sowohl IP als auch IP-fremd (wie etwa IPX, SNA oder jedes andere Ethernet-basierte Protokoll im Unternehmen). Damit sind Carrier in der Lage, native Ethernet-Ports mit anderen zu verbinden, sofern sie Ethernet-Frames gekapselt über Frame Relay oder ATM verwenden. Konfigurationen können hier Punkt-zu-Punkt oder Mehrpunkt-zu-Mehrpunkt sein.

Routed Interworking verbindet IP über Frame Relay oder ATM, oder mit IP über Ethernet. Da es sich dabei um einen Punkt-zu-Punkt-Dienst handelt ist er lediglich für IP geeignet.

Abbildung 1 zeigt einige zur Zeit standardisierte Methoden zur Zusammenarbeit von ATM, Frame Relay, TDM, IP und Ethernet. Für Ethernet sind die primären Interfaces 10/100/1000 Mbps und 10 GE, VLANs mittels Q-in-Q oder VPLS, und Ethernet über Sonet X.86

Abbildungen 2 und 3 zeigen einige Vorteile, die ein Netzbetreiber erzielen kann, wenn er ein konvergierten Backbone und verschiedene Protokolle verwendet. Abbildung 2 ist das, was die meisten Carrier zur Zeit betreiben und Service Provider nutzen. Es zeigt einige verschiedene Overlay-Netzwerke die verwendet werden, um alle links gezeigten Dienste zu transportieren. Da gibt es ein IP-Netzwerk, das typischerweise über ein ATM-Netzwerk abgewickelt wird, das selbst wiederum auf ein Sonet/SDH-Transportnetz umgelegt wird.

All diese Dienste werden über besonderes Equipment für Zugriffsnetze eingebracht und schließlich für den Transport über den Backbone per Aggregation zusammengefaßt. Das ist eine sehr teure Prämisse für den Servie Provider, denn die ganze unterschiedliche Netzwerkausrüstung muß gewartet und versorgt werden. Außerdem gibt es hier kein Service Interworking, da die Backbones unterschiedlichen Netzwerken angehören.

Abbildung 3 zeigt, wie die gleichen Dienste aus Abbildung 2 über ein konvergiertes MPLS-Netzwerk und ein IP-Netzwerk im Kern abgewickelt werden. ATM, Frame Relay, Ethernet und TDM werden Transport durch den Backbone auf MPLS-basierte Pseudoleitungen umgelegt.

Jeder abgewickelte Dienst benötigt ein Gerät zur Aggregation, daß nur für diesen Dienst bestimmt ist. Man spricht dann von First Level Aggregation Equipment. Anschließend werden die aggregierten Dienste an einen IP Edge Router für den Transport über den Backbone übergeben.

Garantierte Service Level Agreements?

Seit Endkunden verstärkt Echtzeitanwendungen wie VoIP oder Videoconferencing über Metro- und Weitverkehrsnetze per Ethernet abwickeln, ist es für Service Provider von höchster Wichtigkeit, Service Level Agreements (SLA) anzubieten, die als Hard QoS bezeichnet werden. Sie beschreiben den QoS, den eine Applikation erfordert, damit sie beispielsweise in Echtzeit arbeiten kann. Es existieren einige unterschiedliche Mechanismen in Netzwerkgeräten, wie Multiservice-Routern, zur Unterstützung von Hard QoS.

Dabei handelt es sich um:

• Hohe Anzahl von Queues für individualisierte SLAs pro Kunde, pro Anwendung, pro Service und pro Protokoll.
• Jedem Datenfluß wird eine eigene Klassifizierung assoziiert, unter Verwendung von Priority Queues, Policer und Shaper und Congestion Management.

Diese Techniken wurden zum Großteil von ATM abgeleitet, so daß ATM’s VC-Queuing (Virtual Channel) hier wieder als IP/MPLS-Flow Queuing auftaucht. Jedem Datenfluß seinen eigene Queue innerhalb eines Routers oder Switches zuzuordnen erlaubt jeder Applikation ihre eigene persönliche Queue für QoS führen. Ebenso erlaubt die Zuordnung einer Klassifikation auf Basis des Inhalts der Pakete (hier Datenprotokoll, Quell- und Zieladresse) eine Zuordnung in die entsprechende Priority Queue, die dann je nach SLA gesteuert wird (Policing). Falls notwendig, kann der Verkehr auch zusätzlich geshaped werden, um gewisse Lastspitzen abzufangen, was besonders für das Congestion Management von Bedeutung ist.

Das Resultat all dieser Techniken ist eine Verlässlichkeit und Vorhersagbarkeit, die wir nur von Circuit Switching kennen oder von ATM.

Aus praktischer Sicht besonders wichtig ist für den Transport über Kernnetzwerke die Aggregation von Datenflüssen gleicher QoS-Anforderungen, da nur so Datenfluß-basierte QoS auf mehrere hundert Millionen einzelner Datenflüsse skaliert werden kann.

Ebenso wichtig für die Transparenz von Diensten für die jeweilige Anwendung ist, in der Lage zu sein, die QoS-Charakteristika im Hinblick auf native Parameter zu definieren, um Konsistenz zu erreichen. Dazu werden in der Regel folgende native Parameter herangezogen:

• ATM: PCR (Peak Cell Rate), SCR (Sustained Cell Rate), MBS (Maximum Burst Size) und CDTV (Cell Delay Variation Tolerance)
• MPLS LSP: PDR (Peak Data Rate), CDR (Committed Data Rate und PBS (Peak Burst Size)
• Frame Relay: CIR (Committed Information rate) und Bc/Be (Committed/Excess Burst)
• Ethernet/Ethernet über Sonet/VLAN: Maximum und minimum rate und MBS (Maximum Burst Size)

Das Netzwerk muß in der Lage sein, zwischen diesen Parametern zu konvertieren, wenn echte Ende-zu-Ende-Dienste mit dem erforderlichen QoS bereitgestellt werden sollen.

Ethernet über MPLS verwenden

Viele aktuelle Ethernet-Dienste verwenden Punkt-zu-Punkt- (P2P) oder Punkt-zu-Mehrpunkt-Konfigurationen (P2MP) mittels VLANs, wie Abbildung 4 zeigt. P2MP wird oft auch als Hub and Spoke oder Sternkonfiguration bezeichnet. Obwohl relativ kosteneffektiv für ATM und Frame Relay, hat P2MP Nachteile. Der Hub representiert einen Single Point of Failure und jeder Versuch, diesen zu beseitigen kostet viel Geld und steigert die Komplexität. Spoke-to-Spoke-Pakete müssen durch den Hub, was die Latenz erhöht, ist aber Gegensätzlich zu aktuellen Any-to-Any-Applikationen wir VoIP oder Instant Messaging. Außerdem kann die Konfiguration ziemlich komplex werden, da ein CPE Router am Hub benötigt wird und VLAN-Tags zu Identifikation der einzelnen Spokes am Hub verwendet werden.

Ethernet-Dienste entwickeln sich weiter und bieten neue Optionen, insbesondere im Bereich Mehrpunkt-zu-Mehrpunkt (MP2MP) mittels VPLS, wie Abbildung 5 illustriert.

Ein Grund für die Attraktivität von MPLS für Service Provider liegt an der starken Vereinfachung der Konfigurationen, sowohl für den Service Provider als auch für den Endkunden. Das führt außerdem zu geringeren Kosten, steigert die Wettbewerbsfähigkeit und führt zu geringeren Preisen für Kunden, die jetzt lieber auf Peer-to-Peer-Konfigurationen setzen als auf ältere Hub-and-Spoke-Architekturen.

Herausforderungen in Betrieb und im Support

Carrier, die jetzt Ethernet- und MPLS-Dienste ausrollen, stellen fest, daß sie mehr für den Support und die operative Seite tun müssen, da MPLS sich nicht selbst verwaltet, zumindest noch nicht. Dazu gehören:

• Managment über Geschäftsprozesse hinweg
• Verwaltung der Dienste von Ende-zu-Ende
• Verwaltung aller Netzwerkschichten

Alle drei Punkte werden im folgenden ausführlich erläutert.

Managment über Geschäftsprozesse hinweg

Dienste, die über Ethernet und MPLS abgewickelt werden sind komplexer als andere und haben weitergehende Auswirkunden als traditionelle Dienste. Sie erlauben nämlich:

• On-Demand (z.B. Bandbreite) und Selbstbedienung für den Kunden (z.B. einzelne Dienste gezielt anfordern)
• Angereicherte IP-basierte Dienste wie Tripple-Play. Mehr zu Tripple-Play im Artikel Wie Funktionieren Ethernet FTTH Tripple Play Dienste? auf dieser Website.
• Kunden- und VPN-spezifisches SLA-Management

Selbstverständlich müssen solche Fähigkeiten mit den unterschiedlichen Geschäftsprozessen der Carrier funktionieren. Gleichermaßen muß der Kunde ein genauen Einblick in das Management und die Datenerhebung für die SLAs erhalten, um aktiv an der Verwaltung seiner Dienste (Selbstbedienung) teilzunehmen. Die hohen Bandbreiten erlauben das Konvergieren der neuen Dienste wie IPTV und VoIP auf Zugriffsebene, so daß neue Anforderungen an das Dienstmanagement und die Bereitstellung derselben gestellt werden.

All das zu verwalten, ist nicht einfach. Abbildung 6 zeigt den Mix aus Technologien, die ausgerollt wurden, um Ethernet über MPLS zu aktivieren. Aus Perspektive des Managements zeigt die obere Hälfte der Abbildung den funktionalen Teil, der benötigt wird, um eine integrierte Dienstverwaltung für die zugrundeliegende Technologie zu etablieren.

Die Erfüllung der Servicevereinbarungen betrifft sowohl die Aktivierung als auch Bereitstellung von Diensten, beispielsweise wenn der Kunde Bandbreite je nach Bedarf anfordert (On-Demand Bandwidth). Die Servicezusicherung wiederum betrifft die Dienstverwaltung und die Sicherstellung, daß der betreffende Dienst auch wirklich verfügbar ist. Dazu gehören die Behandlung von Problemen, Verwaltung der SLAs, Führung von Leistungsstatistiken und so weiter. Und aus Sicht des Carriers erscheint es essenziell, diese Dinge dem Kunden auch berechnen zu können. So dienen diese Daten zur Abrechnung und zur Geschäftsanalyse.

Verwaltung der Dienste von Ende-zu-Ende

Ganz klar, das die Ende-zu-Ende-Verwaltung der Dienste eine ganz offensichtliche Anforderung ist, allerdings bringt sie auch ihre Herausforderungen mit, den Netzwerke sind nicht homogen. Sie bestehen aus Segmenten, die aus Legacy-Technologien zusammengesetzt sind, und anderen, die auf neuen Technologien basieren, wie etwa MPLS VPNs, die selbst wiederum mittels unterschiedlicher Technologien implementiert werden können.

Typische Fragen bei der Ende-zu-Ende-Verwaltung sind: Wie kann ich die Dienste abrechnen? Wie kann ich diese unterschiedlichen Technologiedomänen in einer einzigen Rechnung unterbringen? Wie kann ein Dienst aktiviert werden, wenn er über mehrere unterschiedliche Technologien abgewickelt und von ebenso verschiedenen Verwaltungssystemen gemanaged wird? Außerdem muss Ende-zu-Ende-Management auch über unterschiedliche Service-Domänen hinweg gewährleistet sein.

Das ist der Schlüssel für Tripple-Play-Dienste, wie in Abbildung 7 illustriert wird. Das Management-System muß in der Lage sein, den Lebenszyklus mehrere Dienste zu verwalten und gleichzeitig die Interaktion zwischen Kunde, Netzwerk und Dienst sicherstellen. Das geschieht meist über einen einzigen Punkt im Netzwerk zur Service-Bereitstellung und zum Management der verschiedenen Anwendungen, wie Sprache, Video oder Inhalte.

Verwaltung aller Netzwerkschichten

Die letzte große Herausforderung ist die Kontrolle über das Heer von Schichten in einer EoMPLS-Architektur. Grundlegend haben Carrier es mit folgenden fünf Schichten zu tun:

• EoMPLS-VPN-Dienste
• Zugriffsnetze
• IP/MPLS Layer
• Sonet/SDH Transportnetzwerk
• Photonischer Layer

Das Problem ist nicht nur das Management der jeweiligen Layer, sondern auch die Interaktionen zwischen ihnen und welche Schichten für das SLA wichtig sind und der Kunde sehen kann.

Zum Beispiel: wenn ein Fehler im Sonet/SDH-Layer auftritt und ein OAM-Alarm (Operation, Administration and Management) ausgelöst wird, kommt es zu einer Kaskade, sowohl horizontal aus auch vertikal durch sämtliche Schichten. Ein Link-Fehler im PE-Router (Provider Edge Router) sorgt für einen Reachability Failure Alarm auf Seiten des Routers. Ebenso verursacht ein Sonet Link Failure einen LSP Failure im MPLS-Layer, der wiederum einen ähnlichen Alarm im Routing-Layer verursacht, der unter Umständen zum Kunden durchschlägt welcher evtl. das VPN verliert.

Die gute Nachricht für alle Carrier und Service Provider ist, daß langsam Technologien Einzug halten, die diese Probleme adressieren, beispielsweise für das Real-Time-Monitoring von Ereignissen im Routing- und MPLS-Layer, so daß Alarme erzeugt werden können, ohne auf die nächste Runde des Pollings oder auf SNMP-Traps zu warten.

Hilfreich sind in diesem Zusammenhang auch synthetische Testagenten, wie beispielsweise IP SOA oder Cisco’s SAA, mit deren Hilfe Tests für bestimmte Service-Level dürchgeführt werden können. Sie finden beispielsweise Anwendung bei der Ermittlung von Latenzzeiten zwischen den Endpunkten eines VPNs.

Was nutzt Real-Time-Monitoring, wenn die Zuständigkeiten nicht klar sind, oder zu viele Anlaufpunkte für das Fehlermanagement vorhanden sind? Es bietet sich also an, auch die Fehlerbearbeitung zu konsolidieren und eine einzige Verwaltungseinheit für diesen Zweck zu etablieren. Hier laufen alle Alarme und Ereignisse aller Schichten auf und werden den richtigen Werkzeugen zugeführt, um beispielsweise auf Leistungsengpässe und harte Fehler gleichermaßen reagieren zu können.