Generic Framing Procedure als Transportprotokoll
Bündel für das Metro-Netz
Im Metrobereich ist ein Verfahren gefordert, das den effizienten Transport unterschiedlicher Protokolle über dasselbe Transportmedium zulässt. Mit der Generic Framing Procedure (GFP) steht eine Technik zur Verfügung, die Paketdaten über ein TDM-Netzwerk (Time Division Multiplex) wie Sonet/SDH bewegen kann.
Der Metro-Data-over-Sonet/SDH-Markt gewinnt nach Einschätzung von Experten an Volumen, offenbar
um so mehr, je häufiger auch die Endkunden die Option fordern, Daten über weite Strecken zu
übertragen. Die Generic Framing Procedure (GFP) ist ein Transportprotokoll, mit dem sich Paketdaten
über ein TDM-Netzwerk (Time Division Multiplex) wie Sonet/SDH transportieren lassen. GFP soll
mehrere Vorteile bieten:
Hohe Betriebssicherheit, da der gesamte Inhalt einschließlich des Overheads
mit einem CRC-Code geschützt werden kann,
kurze Latenzzeiten bei Verwendung des transparenten GFP-Modus (GFP-T),
eine transparente Layer-2-Verbindung mit GFP-T,
eine deterministische Bandbreite,
Multiprotokollunterstützung und
geringen Overhead.
Transportprobleme im Metrobereich
Im Metrobereich bewährt sich ein Verfahren, das den effizienten Transport unterschiedlicher
Protokolle über dasselbe Transportmedium zulässt. Während bestimmte Transportprotokolle (etwa ATM)
den Nachteil eines hohen Overhead-Anteils haben, leiden andere Methoden für den Datentransport per
Sonet (zum Beispiel HDLC) unter dem Mangel, dass sie nur für ein bestimmtes Client-Protokoll (in
diesem Fall Ethernet) gedacht sind. Hinzu kommen weitere Einschränkungen wie etwa die nicht
deterministische Bandbreite von HDLC durch das Character Remapping, wenn die Nutzdaten ein
0x7E-Zeichen enthalten.
Erforderlich ist zudem eine effektive Möglichkeit zum Bündeln mehrer Client-Streams zu einem
einzigen Sonet/SDH-Kanal. Zum Beispiel beträgt die Nutzdatenrate von Escon 160 MBit/s im
8-Bit-Bereich (Escon ist 8B/10B-codiert). Ein VC4- oder STS-3C-Container bietet eine
Transportkapazität von 155,52 MBit/s, den Transport- oder Nutzdaten-Overhead nicht eingerechnet.
Die effizienteste Zuordnung von Escon zu Sonet/SDH-Nutzdaten erfordert deshalb das Zusammenfassen
mehrerer Escon-Streams zu einer Sonet/SDH-Payload höherer Ordnung. Systemdesigner wünschen sich
außerdem die Möglichkeit zur einfachen Einbeziehung von Feature-Upgrades in ihre Systeme, wenn sich
die Technik weiterentwickelt. Dazu gehört zum Beispiel eine Client-spezifische kanalweise
Überwachung oder ein kanalweises Traffic-Shaping in einer Transportbox. Diese Forderungen
resultieren aus der Ausweitung von Ethernet auf die Transportkarte, wo ein PDH-Billing nicht mehr
ausreicht, sondern die Kunden mehr und mehr nach Ethernet-Billing verlangen.
GFP im Überblick
Die Skizze unten zeigt die grundlegende Struktur eines GFP-Frames. Die Felder PLI (Payload
Length Indicator) und cHEC (Core Header Error Correction) dienen als Mechanismus zur Abgrenzung der
Frames untereinander. Das PLI-Feld hat eine Länge von zwei Bytes und gibt die Länge des
Payload-Bereichs an. Unter der Payload (Nutzdaten) versteht man all jene Teile des GFP-Frames, die
nicht zum Core Header gehören. Bei cHEC handelt es sich um den CRC-Code (Cyclic Redundancy Check)
des PLIs. Die Felder PLI und cHEC können sich von einem Frame zum anderen unterscheiden. Das
cHEC-Feld ermöglicht der sendenden GFP-Engine, Einzelbitfehler im Core Header zu korrigieren und
Mehrbitfehler zu erkennen. Die Beziehung zwischen PLI und cHEC erlaubt es der empfangenden GFP
Engine wiederum, sich nach dem Einschalten oder nach einer Betriebstörung mit dem ankommenden
GFP-Daten-Stream zu synchronisieren und bildet damit die Grundlage für die zuvor angeführte
Betriebssicherheit von GFP.
Im Fall von Framed GFP (GFP-F) enthält das Datenfeld die Nutzdaten des Clients. Es erfolgt kein
Remapping der Zeichen, obwohl auch ein optionales Scrambling-Polynom definiert ist. Im Falle von
Transparent GFP (GFP-T) führt das System ein 64B/65B-Mapping mit den Client-Daten durch, doch ist
dieses Mapping deterministisch und resultiert nicht in einer Erweiterung eines Datenzeichens auf
zwei Datenzeichen.
Das in der Skizze eingezeichnete Typfeld besteht aus zwei Bytes und gibt an, ob es sich bei dem
GFP-Frame um einen Client Data Frame oder um einen Client Management Frame handelt. Es signalisiert
ferner, ob sich am Ende des GFP-Frames das optionale FCS-Feld befindet, welcher Art der Extension
Header ist und von welchem Datentyp das Payload-Information-Feld. Das Feld tHEC erfüllt für das
Typ-Feld denselben Zweck wie das cHEC-Feld für das PLI-Feld. Der Extension Header enthält
zusätzliche Angaben über den GFP-Stream.
Im Fall von GFP-T enthält der Payload-Information-Bereich keine unmodifizierten Client-Daten. Im
Payload-Information-Bereich sind 64B/65B-codierte Zeichen enthalten. Die GFP-Spezifikation
definiert das 64B/65B-Mapping, das in der Abbildung auf Seite XX illustriert ist: GFP-T unterstützt
8B/10B-Protokolle. Das Mapping beginnt mit der konventionellen 10B-8B-Umwandlung. Ein Control Code
Remapper verarbeitet daraufhin einen 8-Byte-Stream aus Daten und Steuerzeichen und ordnet die
8-Bit-Steuerzeichen einem neuen, in GFP-T spezifizierten 3-Bit-Steuercode zu. Die 8 Bytes werden
dabei so umgestellt, dass die Steuercodes am Beginn des 8-Byte-Blocks platziert werden. Außerdem
wird eine 4 Bit umfassende Längenkennung an den 3-Bit-Steuercode angehängt. Ein ebenfalls
hinzugefügtes Flag-Bit signalisiert, ob das nächste Byte ein Daten- oder Steuerzeichen ist.
Abschließend wird der Beginn des 8-Byte-Blocks mit einem Flag-Bit versehen, das angibt, ob das
erste Bit ein Daten- oder Steuerzeichen ist. Diese Art des Mappings richtet eine transparente
L2-Verbindung ein, da der Client-Daten-Stream, der am Ausgang von der sendenden GFP-Engine wieder
zusammengefügt wird, dem an der empfangenden GFP-Engine ankommenden Daten-Stream entspricht, und
zwar mit der einzigen Ausnahme, dass vom Client-Protokoll Idle-Zeichen hinzugefügt oder gelöscht
werden, um die Datenrate anzupassen.
Sobald acht 64B/65B-codierte Codegruppen aus je 8 Bytes vorliegen, werden sie wie in Bild 3
dargestellt zu einem Superblock zusammengefügt. Der Payload-Bereich eines jeden transparenten
GFP-Frames enthält einen oder mehrere Superblöcke. Ein solcher Superblock entsteht durch
Zusammenfügen der Bytes aller 8-Byte-Codeblöcke hintereinander, Anhängen der Flag-Bits aller
Codeblöcke und Anfügen eines CRC-16-Codes. Im Fall von GFP-T kann die Anzahl der Superblöcke von
einem Frame zum anderen grundsätzlich variieren. Es ist jedoch üblich, in einem bestimmten
GFP-T-Kanal eine bestimmte Anzahl Superblöcke pro Kanal festzulegen und diese beizubehalten.
Der Superblock kann – unabhängig von der Zahl der Superblöcke pro Frame – die empfangende
GFP-Engine "verlassen", sobald acht Client-Code-Gruppen vorliegen. Die GFP-Engine muss nicht
abwarten, bis ein kompletter transparenter GFP-Frame zusammengefügt ist. Das Gleiche gilt für den
abgehenden Pfad, sofern das optionale FCS-Feld nicht vorhanden ist. Dieses Feld wird bei GFP-T
nicht benötigt, denn hier werden alle Payload-Bytes durch den CRC-16-Code in jedem Superblock
geprüft. Da seitens der Architektur kein Zwang besteht, mehr als einen Superblock gleichzeitig zu
verarbeiten, bietet sich die transparente GFP als Transportmechanismus mit kurzen Latenzzeiten an.
ITU und ANSI haben die Generic Framing Procedure (GFP) als ein effizientes Mittel für den Transport
mehrerer Client-Protokolle mithilfe einer gemeinsamen Protokoll-Engine definiert. Als Option bietet
GFP die Möglichkeit, einen GFP-Frame mithilfe des zum Linear Extension Header gehörenden
Channel-ID-Felds (CID) einem bestimmten Kanal zuzuordnen. Ein intelligenter GFP-Protokollprozessor
kann die Channel ID auswerten und ankommende GFP-Frames einem bestimmten virtuellen Tributary
zuordnen. In umgekehrter Richtung hat der GFP-Protokollprozessor die Möglichkeit, die Nutzdaten
abgehender GFP-Frames auf einen bestimmten Client-Protokoll-Port zu switchen.
Nun resultiert allein aus der Fähigkeit, ein bestimmtes Feature zu nutzen, nicht unbedingt
sofort ein Vorteil. In diesem Beitrag geht es daher im Folgenden um die Verwendung des CID-Felds
für das Switching und um bestimmte Situationen, in denen sich die Verwendung des CID-Felds für
Switching-Zwecke als günstig erweist.
Data-over-Sonet/SDH-Applikationen
Das Bild oben skizziert eine typische GFP Data-over-Sonet/SDH-Anwendung. Man erkennt, dass die
Darstellung nach Funktionen geordnet ist. Die einzelnen Blöcke können entweder in je einem
unabhängigen Baustein implementiert oder gemeinsam in ein großes Bauelement integriert sein. Es ist
möglich, dass die Daten in unterschiedlichen Protokollen ankommen, denn GFP unterstützt derzeit die
in der Abbildung wiedergegebenen Protokolle 10/100/1000-Ethernet, Ficon, Escon, Fibre Channel und
DVB-ASI. Nach der Seriell-Parallel-Umwandlung durch den Serdes (Serialiser/Deserialiser) gelangen
die Daten an den GFP-Mapper, der aus den ankommenden Daten die entsprechenden GFP-Frames generiert.
Dies geschieht eins zu eins, das heißt ein Client-Daten-Stream wird einem Kanal im Framer
zugeordnet. Der Framer, der Unterstützung für Virtual Concatenation (VC) bietet, erzeugt den
Sonet/SDH-Frame, der daraufhin an den Sonet/SDH-Serdes gelangt. Virtual Concatenation und GFP sind
oft im Verbund mit dem Sonet/SDH-Serdes anzutreffen und kommen vielfach in Sonet/SDH-Lösungen der
nächsten Generation zum Einsatz.
Die Grenzen von GFP-T mit konstanter Bandbreite
Im ersten Beispiel für das GFP-Switching geht es um Anwendungen, in denen das Client-Protokoll
konstante Bandbreite hat und keine Überbuchung erfolgt (zum Beispiel GFP-T-Mapped Escon und
GFP-T-Mapped Fibre Channel). Die folgenden Aussagen gelten deshalb für alle GFP-T-Applikationen,
die das WAN mit einer konstanten Datenrate belegen. Es werden zwei elementare VC1-Payload-Raten
behandelt, nämlich VC3-basierende Kanäle, deren Nutzdatenrate ungefähr der STS-1-Rate (rund 50
MBit/s) entspricht, und VC4-basierende Kanäle mit einer Payload-Datenrate ungefähr auf dem Niveau
von STM-1 (etwa 150 MBit/s). Nach der Standard-SDH-Benennung geben die letzten Zahlen der
Kanalbezeichnung stets die Zahl der Tributarys an, die dem jeweiligen Kanal zugeordnet sind. Somit
steht VC3-4v für einen Kanal mit vier Tributarys zu 50 MBit/s (Gesamtdatenrate somit zirka 200
MBit/s), während VC4-2v einen einzelnen Kanal mit zwei Tributarys zu 150 MBit/s (insgesamt also
etwa 300 MBit/s) kennzeichnet.
Wenn der gezeigte GFP-Mapper mit 1:1-Mapping arbeitet, ist ein bestimmtes Client-Interface stets
einem bestimmten Transportkanal zugeordnet. Angenommen sei nun, eine VC-Applikation bilde zwölf
GFP-T-gemappte Escon-Daten-Streams auf eine OC-48/STM-16-Pipe ab. Da jeder einzelne Escon-Kanal im
8-Bit-Bereich eine Datenrate von 160 MBit/s aufweist, passt ein solcher Kanal nicht in einen
VC4-1v-Kanal, der nur etwa 150 MBit/s bietet, doch würde ein VC3-4v-Kanal mit seinen ungefähr 200
MBit/s ausreichen. Da in jeder OC-48/STM-16-Pipe 48 VC3-Tributarys zur Verfügung stehen, wäre eine
solche Implementierung zulässig, und alle zwölf Escon-Streams würden erfolgreich transportiert.
Ältere SDH-Systeme unterstützen allerdings keine auf VC3-Datenraten abgestufte Bereitstellung.
Hieraus resultiert somit eine künstliche Beschränkung: Zwar existiert genügend Transportkapazität
für zwölf Escon-Streams, doch angesichts der praktischen Beschränkung der akzeptablen
Transportformate (fehlender VC-3nv-Support) ist die Zuordnung der zwölf Escon-Streams mit je 160
MBit/s zu der OC-48/STM-16-Pipe nicht möglich. Dazu eine Nebenbemerkung: Die
Payload-DatenratenVC3-nv und VC4-nv sind in ITU G.707 definiert.
Der Einsatz des GFP Linear Extension Headers ergibt allerdings eine bisher von
Multiprotokolltransportsystemen nicht gebotene Fähigkeit, nämlich das Switching eines einzelnen
GFP-Frames an Hand des Inhalts des CID-Felds (Channel ID) im GFP Linear Extension Header. So wäre
beispielsweise die Bündelung aller drei GFP-T-gemappten Escon-Streams (160 MBit/s × 3 = 480 MBit/s)
zu einem VC4-4v-Kanal (rund 150 MBit/s × 4 = rund 600 MBit/s) möglich. Eine solche Bündelung ist
allerdings nur dann sinnvoll, wenn die Streams in der abgehenden Richtung separiert werden können.
Da das Mapping transparent erfolgt, hat der empfangende GFP-Mapper keinen Zugang zu den "höheren
Ebenen" des Client-Protokoll-Streams. Das CID-Feld muss deshalb benutzt werden, um die einzelnen
GFP-Streams empfangsseitig zu kennzeichnen. Ebenso lässt sich das CID-Feld verwenden, um die
einzelnen GFP-Streams ausgangsseitig zu separieren. Dank der Möglichkeit zum Switchen des Traffics
an Hand des CID-Felds werden auch Applikationen unterstützt, die sonst nicht möglich sind. Auf
diese Weise lassen sich Beschränkungen aufheben, die sich aus Konfigurationen mit anderen
Client-Protokollen (Fibre Channel, DVB-ASI etc.) und anderen Transportkapazitäten (OC-12/STM-4,
OC-192/ STM-64) ergeben. Ein Kriterium, das für die Verwendung des CID-Felds zum Bündeln spricht,
ist die Forderung, dass die gebündelten Client-Protokoll-Streams von einem Kunden stammen müssen.
Meist wünschen die Kunden nämlich keine gemeinsame Nutzung einer Synchronous Payload Envelope (SPE)
oder eines Virtual Containers mit anderen Kunden.
GFP-T-Applikationen mit variabler Bandbreite
Der logisch nächste Schritt in der Verwendung des CID-Felds für Switching-Zwecke ist sein
Einsatz für Anwendungen mit variabler Bandbreite. Dies gilt für Applikationen auf GFP-F-Basis
(Framed GFP). Die Datenrate, mit der das WAN belegt wird, ist hierbei nicht konstant, sondern von
der Client-Datenrate abhängig. Findet auf der Client-Verbindung kein Datenverkehr statt, besteht
der Transportkanal ausschließlich aus GFP-Idle-Frames. Ist die Client-Verbindung dagegen stark
ausgelastet, enthalten SPE und Virtual Container des Transportkanals ausschließlich
GFP-Daten-Frames und keine GFP-Idle-Frames (vorausgesetzt der GFP-Mapper kann die Verbindung
korrekt verwalten). Zurzeit sind Ethernet, IP/PPP und FC-BBW die einzigen für den GFP-F-Transport
definierten Protokolle (siehe ITU G.7041). Da die meisten gängigen GFP-F-Applikationen in naher
Zukunft auf Ethernet basieren werden, konzentrieren sich die folgenden Aussagen auf
Ethernet-over-GFP-F: Es gibt zwei große Anwendungsgebiete, in denen der GFP-Transport mit variabler
Bandbreite per VC erforderlich ist:1:1-Überbuchung und N:1- oder N:N-Überbuchung.
Bei 1:1-Überbuchung ist ein einziger Client-Protokollkanal einer Sonet/SDH VC-Gruppe zugeordnet,
doch ist die Transportkanalbandbreite, die dem Client-Protokollkanal zur Verfügung steht, geringer
als der maximal ankommende Traffic. Ein Beispiel ist die Zuordnung eines
Gigabit-Ethernet-Client-Ports (1000 MBit/s) zu einem VC4-4v-Kanal (etwa 600 MBit/s).
Solche Mechanismen können beispielsweise mit Ethernet-Pause-Frames arbeiten oder Ethernet-Pakete
verwerfen (wobei sich das System auf die TCP-Retransmission-Funktionalität stützt, damit ein
ordnungsgemäßer Datentransfer gewährleistet ist). Da in diesem Fall ein 1:1-Mapping erfolgt, ist
ein GFP-CID-Switching nicht erforderlich. Bei 1:N- oder N:N-Überbuchung werden mehrere Client-Ports
mit variabler Bandbreite einem oder mehreren Sonet/SDH-Kanälen zugeordnet. Bild 7 illustriert den
Fall einer Applikation mit 4:1-Überbuchung/Bündelung. Im Diagramm sind vier
Gigabit-Ethernet-Streams zu einer einzigen VC4-4v-Payload gebündelt. Da der Kunde häufig den Wunsch
hat, dass sein Traffic in einem eigenen Sonet/SDH-SPE/Virtual-Container transportiert wird, kommt
der skizzierte Fall nur dann in Frage, wenn der gesamte Client-Verkehr von einem einzigen Kunden
stammt. Der Traffic kann sich dabei aus Voice-over-IP-Datenverkehr (VoIP),
Multi-Protocol-Label-Switching-Traffic (MPLS), einer Erweiterung des Kunden-LANs und Fibre Channel
over IP (FCIP) zusammensetzen.
In allen Fällen muss der GFP-Mapper jedoch entscheiden, wie viel Bandbreite den einzelnen
Client-Ports zuzuweisen ist. Das GFP-Device muss deshalb die Quality of Service (QoS)
implementieren, da die Transportkanäle durch das Client-Protokoll überbucht sind. Dementsprechend
fordert man vom GFP-Mapper die Fähigkeit, auf die höheren Ebenen der Client-Ports (IP, und TCP)
zuzugreifen. Obwohl sich die Industrie noch nicht vollständig auf einheitliche
QoS-Implementierungen geeinigt hat, ist sicher, dass die Realisierungen auf den höheren
Ethernet-Ebenen erfolgen wird. Da das GFP-Device auf die dritte und vierte Schicht des
Client-Traffics zugreifen muss, ist es unnötig, die Übertragung von GFP-F-Ethernet-Daten durch
unabhängige GFP-Kanal-IDs zu komplizieren. Da für eine N:1- oder N:N-Applikation mit variabler
Bandbreite die GFP-Mapper vor Ort und an der Gegenstelle auf die höheren Schichten der
Client-Ethernet-Frames zugreifen müssen, ist ein Switching auf der Basis des GFP CID-Felds
überflüssig.
Lesen Sie mehr zum Thema
