Von Petra Borowka*

Das von SNA-Gurus lange verschmaehte TCP wird aller Voraussicht nach der Standard zur SNA-Integration in WAN- und teilweise in LAN-Backbones werden. Data Link Switching (DLSw) ist eine als Request for Comment (RFC) offengelegte Spezifikation, die wie SNA- und Netbios-Verkehr in TCP enkapsuliert und so im WAN dynamisch reroutbar wird.

Den ersten proprietaeren Implementierungen von TCP-Encapsulation fuer SNA folgte eine spezielle von IBM fuer ihren Multiprotokoll- Router IBM 6611. Um anderen Herstellern eine kompatible Integration zu ermoeglichen, wurde die Spezifikation von Big Blue im RFC 1434 veroeffentlicht. Damit war DLS geboren. Obwohl das Dokument noch den Status "informal" hat, wurde DLS nach RFC 1434 von einer Reihe etablierter Hersteller uebernommen. Der Nachfolger DLSw - gefuehrt als RFC 1795 - ist fuer eine groessere Verbreitung noch zu jung, ganz zu schweigen von herstelleruebergreifender Kompatibilitaet. Eine der ersten Implementierungen wurde von der Firma Cisco auf den Markt gebracht, die entscheidend am RFC 1795 mitgearbeitet hat. Allerdings ist die Version von Cisco um einige Funktionen erweitert und wird als DLSw+ verkauft.

TCP-Enkapsulierung mit DLSw wird alternativ zur SDLC-LLC- Konvertierung fuer SNA-Verkehr eingesetzt, darueber hinaus fuer SNA LLC (DLC) und Netbios. Ein Ziel der DLSw-Spezifikation war, SNA routbar zu machen, ohne die Data-Link-Software in den Endgeraeten aendern zu muessen. DLSw terminiert die LLC-Session am LAN-WAN- Uebergang durch beidseitige lokale Polls und Acknowledgements wie beim SDLC-Poll-Spoofing.

Data Link Switching unterstuetzt SNA PU Typ 2, Typ 4, Typ 2.1 und optional Netbios auf 802.2-Netzen. Ebenso werden SNA PU Typ 2 primary oder secondary und PU 2.1 ueber SDLC unterstuetzt. Sie werden in DLSw wie LAN-Systeme behandelt: Jede PU wird mit einer Data Link Adresse (MAC-Adresse, LSAP) belegt.

Data Link Switch gaukelt dem LAN einen Partner vor

IEEE 802.2 LLC Typ 2 wurde unter der Annahme entwickelt, dass die Antwortzeit im Netz sehr kurz und deterministisch ist - typisch fuer LAN-Anwendungen. Die LLC-Prozedur verwendet dementsprechend einen festen Timer, um einen eventuellen Paketverlust festzustellen. Wird das Protokoll fuer WAN-Betrieb ueber Brueckenverbindungen veraendert, treffen die Annahmen nicht mehr zu: Die Antwortzeit wird zu hoch, und sie ist nicht mehr deterministisch, sondern bei Ueberlast auf dem WAN-Link variabel. Der LLC-Timer laeuft ab, eine Paketwiederholung wird angestossen. Ist der urspruengliche Frame jedoch nicht verlorengegangen, sondern nur verzoegert worden, bricht in der LLC-Typ-2-Prozedur unter Umstaenden grosse Verwirrung aus, es kommt zum Protokollfehler und schlimmstenfalls zum Link-Abbruch.

RFC 1434 beschreibt eine einfache Enkapsulierung von SNA und Netbios in TCP als Backbone-Protokoll. Die Router, die die Enkapsulierung vornehmen, heissen Data Link Switches. Es wird kein eigener Routing-Mechanismus definiert, sondern als Ersatz fuer LLC beziehungsweise DLC eine reine Ebene-2-Verbindung, die zwischen die Data Link Switches geschaltet ist. Geroutet wird mit den bekannten IP-Verfahren (RIP, OSPF, etc.) Das DLS-Verfahren adressiert folgende LLC-Schwachpunkte:

- DLC Time-outs;

- DLC Acknowledgements ueber WAN;

- Flusskontrolle und Ueberlastkontrolle;

- Broadcast-Kontrolle fuer Verbindungsaufbau;

- Restriktion des Hop-Count-Limit beim Source Route Bridging auf sieben Hops sowie

- fehlendes dynamisches Rerouting im Fehlerfall.

Wie funktioniert aber ein Data Link Switch? Vereinfacht ausgedrueckt, gaukelt er dem LAN vor, er sei der Kommunikationspartner. Zum WAN hin sorgt er zusammen mit seinem DLS-Partner am anderen Ende des LAN-WAN-LAN-Verbunds zuverlaessig dafuer, dass Verbindungsaufbau, Datenaustausch und automatisches Rerouting im Fehlerfall funktionieren. Wie stets in solchen Faellen, wurde ein Protokoll definiert, das die notwendigen Verbindungen ermoeglicht: das SSP. Ein einzelner Data Link Switch mit mehreren Interfaces kann Verbindungen zwischen diesen Interfaces intern schalten. Hierfuer benutzt er natuerlich kein TCP, das fuehrt nur zu einem unsinnigen internen Overhead. Das Prinzip Switch-interner und Switch-uebergreifender DLSw-Verbindungen zeigt Abbildung 1.

Der prinzipielle Unterschied zwischen DLSw und SRB liegt darin, dass DLS die LLC-Verbindung lokal terminiert und somit auch den Hop-Count-Limit beendet. Ganz anders hingegen SRB (vgl. Abbildung 2). Die LLC-Verbindung wird im WAN durch eine TCP-Verbindung ersetzt. Dabei lassen sich mehrere LLC-Verbindungen auf eine TCP- Verbindung zwischen Data Link Switches multiplexen.

Das Ausblenden der LLC-Verbindungen im WAN fuehrt dazu, dass die lokalen Reste der LLC-Verbindung auf beiden Seiten voellig unabhaengig voneinander arbeiten. Die zentrale Aufgabe des beteiligten DLS-Paars ist es, die beiden isolierten LLC-Teile synchronisiert zu halten und Pakete ordentlich abzuliefern. Aus diesem Grund wird im WAN die hohe Verbindungsqualitaet des TCP- Dienstes (verbindungsorientiert, fehlertolerant, Flusskontrolle) und nicht nur IP genutzt.

LLC Acknowledgements (RR) werden nicht ins WAN weitergeleitet, sondern gespooft: Der remote DLS sendet RRs in sein angebundenes LAN und schafft so fuer die remote Partnerstation die Illusion, sie wuerde die RRs ihres Kommunikationspartners empfangen. Das gleiche gilt fuer SDLC: Polling und Poll Response werden hier lokal abgehandelt.

Sobald ein Data Link Switch gelernt hat, wo ein bestimmtes Zielsystem zu finden ist, leitet er Broadcasts, die einen Verbindungsaufbauwunsch fuer dieses Zielsystem enthalten, nicht mehr an alle Ports weiter, sondern nur noch gezielt an den Switch, hinter dem das Zielsystem angebunden ist (MAC-Adressen-Caching).

Beim Aufbau von Netbios-Sessions benutzen DLS die Netbios-Namen, um Pakete gezielt weiterzuleiten. Netbios-Pakete verwenden den LSAP 0x'F0'. Beim Aufbau einer SNA-Session werden Test- oder XID- Pakete weitergeleitet. Sie benutzen den SAP 0x'04', 0x'08' und 0x'0C'. Somit sind SNA- und Netbios-Pakete unterscheidbar. Ein Data Link Switch merkt sich erreichbare Netbios-Systeme, indem er den Namen in eine Tabelle eintraegt (Netbios Name Caching). SNA- Stationen werden lokal ueber Route Discovery gelernt, remote ueber Antworten von anderen Switches. SDLC-Endgeraete werden wie LAN- Stationen behandelt: Sie erhalten im Switch eine MAC/SAP-Adresse, die auf die PU gemappt wird.

Switches praesentieren sich als Source Routing Bridges

Bevor ueberhaupt ein Datenpaket zwischen Kommunikationspartnern ausgetauscht werden kann, muessen die zwischengeschalteten Router beziehungsweise Data Link Switches eine TCP-Verbindung von Router zu Router aufgebaut haben. Zu diesem Zweck haelt ein DLS eine Liste mit allen weiteren ihm bekannten DLS vor. Jeder Switch-Eintrag wird mit der Statusinformation aktiv/inaktiv versehen. Fuer die Endsysteme, die an den LANs angebunden sind, praesentieren sich die Switches wie Source-Routing-Bruecken. Deshalb erhaelt ein Switch intern eine virtuelle Ringnummer: die Ringnummer des LANs. Die Kommunikation ueber ein Switch-Paar stellt sich dann fuer ein Endsystem so dar, als ob es ueber SRB mit dem Nachbar-Ring kommunizieren wuerde.

Der RFC 1434 von IBM fuehrte zu einer herstelleruebergreifenden Initiative, zusammen mit dem APPN Implementors Workshop einen umfassenderen Standard zu entwickeln. Ein erstes Dokument liegt mit RFC 1795 seit April dieses Jahres vor. Er ersetzt den RFC 1434, schliesst einige von dessen Spezifikationsluecken und enthaelt darueber hinaus eine Reihe von Erweiterungen. Insbesondere sind dies die folgenden Merkmale:

- Frame-Format;

- Message-Typen;

- Verbindungsaufbau;

- Aufbau des Caches fuer MAC-Adressen und Netbios-Namen;

- Uebernahme der Largest Frame Size;

- Prioritaeten fuer Circuits;

- Session-Numerierung fuer Netbios;

- Austausch der unterstuetzten Parameter bei Verbindungsaufbau DLS- DLS (Pacing, Fenstergroessen, Netbios Name Caching, MAC-Adresslisten, SAP-Listen) sowie

- Flusskontrolle.

Hinsichtlich RFC 1434 legte man leider keine explizite Abwaertskompatibilitaet fest, da groessere Neuerungen vorgenommen wurden. Entsprechend aeussert sich der RFC 1795 nur sehr halbherzig an einigen Stellen zu der aelteren Spezifikation, wo Formate beschrieben sind, die im RFC 1434 vorkommen und nun nicht mehr genutzt werden. Zukuenftige Weiterentwicklungen, zum Beispiel die Enkapsulierung in APPN statt TCP, sind denkbar. Eine naehere Beschreibung aller Erweiterungen wuerde allerdings den Rahmen dieses Beitrags sprengen.

Steht eine TCP-Verbindung zwischen zwei Switches, benutzen sie das Switch-to-switch-Protocol, um End-to-end, das heisst LAN zu LAN, sogenannte Circuits aufzubauen. Der Overhead des SSP ist nicht gering: Kontrollpakete (beim Circuit- und Verbindungsaufbau) haben 72-Byte- Header, Datenpakete 16-Byte-Header. Steht der Circuit, kann end-to-end LLC Typ 1 realisiert werden. Nach dem Circuit- Aufbau laesst sich eine End-to-end-Verbindung des LLC Typ 2 zwischen Kommunikationspartnern einrichten.

Eine Link-Verbindung wird als logische Assoziation zwischen zwei Endstationen definiert. Die Link-Verbindung wird mit einer 14 Byte langen Data-Link-ID belegt, die aus je einer 7 Byte grossen Ziel- und Quell-Verbindungsadresse besteht (6 Byte MAC-Adresse, 1 Byte LSAP). Der Circuit zwischen den betroffenen Switches erhaelt je beteiligten DLS eine 64-Bit-Nummer (4 Byte DLC-Port-ID, 4 Byte Data Link Correlator). Jeder DLS kann also unabhaengig von den anderen DLS fuer neue Verbindungen eine beliebige Circuit-Nummer vergeben, die er gerade frei verfuegbar hat (Analogie: X.25 VCs). Die Circuit-ID muss innerhalb eines DLS eindeutig sein. Zusammen mit den DLS-IDs der beteiligten Start- und Zielstation ergibt sich eine eindeutige Kennung fuer einen End-to-end-Circuits. Jeder DLS haelt eine Tabelle mit den Circuit-ID-Paaren fuer den lokalen und remoten Endpunkt eines Circuit. Der Switch, der einen Circuit- Aufbau initiiert, wird Origin Switch genannt, sein remoter Partner Target Switch.

Um Overhead zu sparen, kann ein Switch versuchen, ein MAC/

SAP-Ziel zu finden, ohne erst lange eine Verbindung zum Partner- Switch aufzubauen. Erst wenn die Adresse gefunden ist, wird ein Verbindungsaufbau gestartet. Ein DLS, der das gesuchte Ziel in seinem Cache hat, kann auch direkt antworten, ohne vorher eine LLC-Verbindung zur gewuenschten Zielstation (per Test-Frame an den Null-SAP) aufzubauen. Er kann aber auch die lokale LLC-Verbindung zur Zielstation sofort aktivieren. Die Aktionen, die unter dem Switch-Symbol angeordnet sind, laufen Switch-intern zwischen DLC und DLSw ab: beispielsweise ein LAN-seitig empfangener Test fuehrt zu einem Switch-internen Resolve Request, der in das DLSw-Netz weitergeleitet wird.

Verschiedene DLSw-Verbindungen (Circuits) koennen mit unterschiedlicher Prioritaet (CP) belegt werden. Der RFC sagt jedoch nichts ueber den zu verwendenden Prioritaetsalgorithmus aus. Der Algorithmus bleibt der Implementierung ueberlassen. Die Prioritaet wird bei Verbindungsaufbau festgelegt und darf danach bis zum Verbindungsabbau nicht mehr geaendert werden.

In DLSw nach RFC 1795 gibt es eine Reihe Funktionen, ueber die sich die beteiligten Switches einigen muessen, da sie nur optional unterstuetzt werden oder es verschiedene Wertebereiche gibt, die ausgetauscht und zum Teil ausgewaehlt werden muessen. Hierzu gehoeren etwa:

- Hersteller-ID (3 Byte, von IEEE vergebene OUI);

- Versionsnummer des DLSw-Standard (aktuell Version 1, Release 0);

- Versionsnummer der Herstellersoftware;

- Anzahl unterstuetzter TCP-Verbindungen;

- Start-Fenstergroesse fuer Pacing sowie

- Filterlisten fuer MAC-Adressen, Netbios-Namen und LLC-SAPs.

Der Austausch unterstuetzter Parameter ist stets die erste Aktion auf einer neu eingerichteten SSP-Verbindung zwischen zwei Switches. Werden alle angegebenen Parameter unterstuetzt, erfolgt eine positive Antwort. Ungueltige Capability-Pakete oder solche mit Parametern, die der Empfaenger-Switch nicht unterstuetzt, werden negativ beantwortet. Als Reaktion sollte der initiierende Switch die TCP-Verbindung abbrechen. RFC-1434-Implementierungen werden daran erkannt, dass sie die Capability-Exchange-Pakete gar nicht beantworten, da sie sie nicht kennen. Fuer diesen Fall legt der RFC 1795 nicht fest, dass die TCP-Verbindung abgebrochen werden muss.

Nach dem Motto: "Der Ansatz allein ist loeblich" beschreibt der Standard eine Datenflusssteuerung zwischen den beteiligten Switches. Leider laesst er offen, wie denn die implementierte Flusskontrolle auf die DLC-Flusskontrolle der an die Switches angebundenen LANs umgesetzt wird. Die Verfasser selbst bezeichnen ihre Aeusserungen zum Thema Flusskontrolle eher als "philosophische Allgemeinsicht". Die gute Absicht ist es jedenfalls, Ueberlastsituationen innerhalb der DLSw-Wolke bis an die DLSw- Zugangspunkte zurueckzudraengen und sie so an das Verursacher-LAN zurueckzugeben. Dadurch wird solchen LANs, die keine Ueberlasten produzieren, ein vernuenftiger Durchsatz durch das DLSw-Netz garantiert.

Flusskontrolle findet fuer jede Verbindung (Circuit) statt, in beiden Richtungen unabhaengig. Wie bei jeder ordentlichen Flusskontrolle gibt zwischen zwei Switches jeder dem anderen die Sendeberechtigung fuer eine Anzahl von Paketen. Hierzu zaehlen nur DLSw-Datenpakete, Kontrollpakete werden nicht mitgerechnet.

Das Format ist in Abbildung 3 ersichtlich. FCI ist das Flag fuer eine Flusskontrollaktion (Flow Control Indication), FCA das Flag fuer ein Acknowledgement. FCO codiert die Aktion und hat folgende Werte:

000 - Repeat Window Operator (Rpt)

001 - Increment Window Operator (Inc)

010 - Decrement Window Operator (Dec)

011 - Reset Window Operator (Rst)

100 - Halve Window Operator (Hlv)

101 bis 111 reserviert

Repeat steht fuer eine Sendeberechtigung fuer weitere W-Pakete, wobei W die aktuelle Fenstergroesse ist, etwa W=3). Increment erhoeht die Fenstergroesse um 1 (W=3+1) und gibt eine Sendeberechtigung fuer weitere W-Pakete. Decrement reduziert die Fenstergroesse um 1 (W=3-1) und gibt eine Sendeberechtigung fuer weitere W-Pakete. Reset schliesst das Sendefenster. Halve halbiert die Fenstergroesse, falls sie vorher groesser als 1 war (W=int[3/2]), und gibt eine Sendeberechtigung fuer weitere W-Pakete. Die maximale Fenstergroesse ist auf 0x'FFFF' begrenzt. Die so erreichbare Datenflusssteuerung ist an das Pacing in SNA angelehnt.

Falls ein Switch Pufferplatz frei hat, wird er den Increment- Operator anwenden. Falls der Pufferplatz knapp wird, wird er den Decrement-Operator oder gegebenenfalls den Halve-Operator anwenden. Das Reset ist der absolute Nothalt: Es schliesst das Sendefenster, sobald es empfangen ist, auch wenn noch nicht alle vorher erlaubten Pakete gesendet wurden.

Fazit: Trotz einiger Holprigkeiten in der Spezifikation zeichnet sich DLSw als offener Standardansatz ab, um SNA und Netbios in LAN- und WAN-Verbundnetzen ueber TCP/IP zu betreiben. Es wird von Herstellern wie Bay Networks, Cisco (nicht 1434), 3Com, IBM und Proteon unterstuetzt. Entgegen frueherer Ankuendigungen wurde die Implementierung von RFC 1434 teilweise vor die Implementierung von APPN gestellt, was fuer steigende Akzeptanz im Markt spricht. Die Einfuehrung einer Reihe optionaler Parameter in der Erweiterung RFC 1795 kann allerdings wieder zu unterschiedlichen Implementierungen fuehren. Kompatibilitaet wird dann nur ueber ein gemeinsames Funktions-Subset erreicht, das alle beteiligten Router/Data Link Switches unterstuetzt.

Abkuerzungen

APPN - Advanced Peer-to-peer Networking

CP - Circuit Priority

DLC - Data Link Control (IBM)

DLS - Data Link Switch

DLSw - Data Link Switching

FCA - Flow Control Acknowledgement

FCI - Flow Control Indication

FCO - Flow Control Operator

LLC - Logical Link Control

LSAP - Logical Link Service Access Point

LU - Logical Unit

MAC - Media Access Control

OSPF - Open Shortest Path First

OUI - Organizational Unit Identifier

PU - Physical Unit

RFC - Request for Comment

RIP - Routing Information Protocol

RNR - Receive Not Ready

RR - Receive Ready

SABME - Set Asynchronous Balanced Mode Extended

SAP - Service Access Point (ISO OSI)

SNA - SystemsNetwork Architecture

SDLC - Synchronous Data Link Control

SRB - Source Route Bridging

SSP - Switch-to-switch Protocol

TCP - Transmission Control Protocol

UA - Unnumbered Acknowledgement

* Petra Borowka ist unabhaengige Beraterin fuer Netzwerke in Aachen.