Handbuch Netzwerk-Technologien - selfHOST · 2003-12-02 · 8 Inhaltsverzeichnis 9.4 Prioritäten-System 142 9.5 Mechanismen des Ausfall-Managements 143 9.6 Frame-Format 143 9.6.1

HandbuchNetzwerk-Technologien



CISCO DocumentationÜbersetzung:

Cosmos Consulting

Markt&Technik Buch-und Software-Verlag GmbH

Die Deutsche Bibliothek – CIP-Einheitsaufnahme

Handbuch Netzwerk-Technologien : komplettes Grundwissenfür Internetworking und Networking / Merilee Ford ... –Haar bei München : Markt und Technik, Buch- und Software-Verl.Einheitssacht.: Internetworking technologies handbook <dt.>

ISBN 3-8272-2034-3

Buch. 1998Gb.

Die Informationen in diesem Produkt werden ohne Rücksicht auf eineneventuellen Patentschutz veröffentlicht.Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt.Bei der Zusammenstellung von Texten und Abbildungen wurde mit größterSorgfalt vorgegangen.Trotzdem können Fehler nicht vollständig ausgeschlossen werden.Verlag, Herausgeber und Autoren können für fehlerhafte Angabenund deren Folgen weder eine juristische Verantwortung nochirgendeine Haftung übernehmen.Für Verbesserungsvorschläge und Hinweise auf Fehler sind Verlag undHerausgeber dankbar.

Autorisierte Übersetzung der amerikanischen Originalausgabe:Internetworking Technologies Handbook © 1998 Macmillan Technical Publishing

Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und derSpeicherung in elektronischen Medien.Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeitenist nicht zulässig.

Fast alle Hardware- und Softwarebezeichnungen, die in diesem Buch erwähnt werden,sind gleichzeitig auch eingetragene Warenzeichen oder sollten als solche betrachtetwerden.

Das Logo Cisco Press ist ein eingetragenes Warenzeichen von Cisco Systems, Inc., USA.

10 9 8 7 6 5 4 3 2 1

02 01 00 99 98

ISBN 3-8272-2034-3

© 1998 by Markt&Technik Buch- undSoftware-Verlag GmbH, Hans-Pinsel-Straße 9b,D-85540 Haar bei München/GermanyAlle Rechte vorbehaltenEinbandgestaltung: Helfer Grafik Design, MünchenProgrammleitung: Erik Franz, [email protected]Übersetzung und Lokalisierung: Cosmos Consulting GmbH/Systemhaus/ISP/Redaktion, [email protected]: Ralf Kothe, Cisco Systems GmbHHerstellung: Claudia Bäurle, [email protected]: text&form, FürstenfeldbruckDruck: Media-Print, PaderbornDieses Produkt wurde mit Desktop-Publishing-Programmen erstelltund auf chlorfrei gebleichtem Papier gedrucktPrinted in Germany

Inhaltsverzeichnis

Vorwort 19

Teil 1 Einführung in das Internetworking 25

1 Grundlagen des Internetworking 271.1 Was ist ein Internetwork? 271.1.1 Die Geschichte des Internetworking 281.1.2 Die Herausforderungen des Internetworking 291.2 Das OSI-Referenzmodell 301.2.1 Eigenschaften der OSI-Schichten 311.2.2 Protokolle 321.2.3 Das OSI-Modell und die Kommunikation zwischen

Systemen 331.2.4 Interaktion zwischen den Schichten des OSI-Modells 331.2.5 Dienste der OSI-Schichten 341.2.6 Schichten des OSI-Modells und der Datenaustausch 351.2.7 Die physische Schicht des OSI-Modells 371.2.8 Die Verbindungsschicht des OSI-Modells 381.2.9 Die Vermittlungsschicht des OSI-Modells 391.2.10 Die Transportschicht des OSI-Modells 391.2.11 Die Kommunikationsschicht des OSI-Modells 401.2.12 Die Darstellungsschicht des OSI-Modells 401.2.13 Die Anwendungsschicht des OSI-Modells 411.3 Datenformate 421.4 Die ISO-Hierarchie von Netzwerken 441.5 Verbindungsorientierte und verbindungslose

Netzwerk-Dienste 451.6 Adressierung im Internetwork 471.6.1 Verbindungsschicht 471.6.2 MAC-Adressen 481.6.3 Adressen der Vermittlungsschicht 51

Inhaltsverzeichnis

6 Inhaltsverzeichnis

1.6.4 Hierarchischer oder ebener Adreßraum 521.6.5 Adreßzuordnung 531.6.6 Adressen oder Namen 531.7 Grundlagen der Flußsteuerung 541.8 Grundlagen der Fehlerprüfung 551.9 Grundlagen des Multiplexing 551.10 Organisationen für Standardisierung 57

2 Einführung in die LAN-Protokolle 592.1 Was ist ein LAN? 602.2 LAN-Protokolle und das OSI-Referenzmodell 602.3 Medium-Zugriffsmethoden im LAN 612.4 Übertragungsverfahren im LAN 612.5 LAN-Topologien 622.6 LAN-Geräte 64

3 Einführung in die WAN-Technologien 673.1 Was ist ein WAN? 673.2 Punkt-zu-Punkt-Verbindungen 683.3 Leitungsvermittlung 693.4 Paketvermittlung 703.5 Virtuelle Verbindungen im WAN 703.6 WAN-Einwahldienste 713.7 WAN-Geräte 723.7.1 WAN-Switch 723.7.2 Zugriffsserver 723.7.3 Modem 733.7.4 CSU/DSU 733.7.5 ISDN-Terminal-Adapter 74

4 Grundlagen des Bridging und Switching 754.1 Was sind Bridges und Switches? 754.2 Überblick zu den Geräten der Verbindungsschicht 764.3 Bridge-Typen 784.4 Switch-Typen 804.4.1 ATM-Switch 804.4.2 LAN-Switch 81

5 Grundlagen des Routing 835.1 Was ist Routing? 835.2 Komponenten des Routing 845.2.1 Pfadermittlung 845.2.2 Switching 865.3 Routing-Algorithmen 875.3.1 Entwicklungsziele 885.3.2 Algorithmusarten 905.3.3 Routing-Meßparameter 935.4 Netzwerk-Protokolle 95

Inhaltsverzeichnis 7

6 Grundlagen des Netzwerk-Managements 976.1 Was ist Netzwerk-Management? 976.1.1 Ein geschichtlicher Rückblick 986.2 Netzwerk-Management-Architektur 986.3 ISO Netzwerk-Management-Modell 996.3.1 Performance-Management 1006.3.2 Konfigurations-Management 1016.3.3 Accounting-Management 1016.3.4 Fehler-Management 1026.3.5 Sicherheits-Management 102

Teil 2 LAN-Protokolle 105

7 Ethernet-Technologien 1077.1 Hintergrund 1077.2 Ethernet und IEEE 802.3 1087.2.1 Ethernet- und IEEE-802.3-Betrieb 1097.2.2 Ethernet und IEEE-802.3 – Service-Unterschiede 1107.2.3 Ethernet- und IEEE-802.3-Frame-Formate 1117.3 100-Mbit/s Ethernet 1137.3.1 100BaseT im Überblick 1147.3.2 100BaseT-Signalisierung 1147.3.3 100BaseT-Hardware 1157.3.4 100BaseT-Betrieb 1177.3.5 100BaseT-Mediumtypen 1187.4 100VG-AnyLAN 1217.4.1 100VG-AnyLAN-Betrieb 1237.5 Gigabit Ethernet 1237.5.1 Gigabit-Ethernet-Spezifikation 1247.5.2 Migrieren zum Gigabit Ethernet 125

8 Fiber Distributed Data Interface (FDDI) 1278.1 Hintergrund 1278.1.1 Standards 1288.2 FDDI-Übertragungsmedium 1288.3 FDDI-Spezifikationen 1308.4 FDDI-Station-Attachment-Typen 1318.5 FDDI-Fehlertoleranz 1338.5.1 Doppelring 1338.5.2 Optischer Bypass-Switch 1348.5.3 Dual-Homing 1358.6 FDDI-Frame-Format 1368.6.1 FDDI-Frame-Felder 1368.7 Copper-Distributed Data Interface (CDDI) 137

9 Token Ring/IEEE 802.5 1399.1 Hintergrund 1399.2 Physische Verbindungen 1409.3 Betrieb eines Token Ring 141


9.4 Prioritäten-System 1429.5 Mechanismen des Ausfall-Managements 1439.6 Frame-Format 1439.6.1 Felder des Token-Frames 1449.6.2 Felder des Daten-/Befehls-Frames 145

Teil 3 WAN-Technologien 147

10 Frame Relay 14910.1 Hintergrund 14910.1.1 Frame-Relay-Standardisierung 15010.2 Frame-Relay-Geräte 15110.3 Frame Relay Virtual Circuits 15210.3.1 Switched Virtual Circuits (SVC/GVV) 15310.3.2 Permanent Virtual Circuits (PVC/FVV) 15310.3.3 Data-Link Connection Identifier (DLCI) 15410.4 Congestion-Control-Mechanismen 15410.4.1 Frame Relay Discard Eligibility (DE) 15510.4.2 Frame-Relay-Fehlererkennung 15610.5 Frame Relay Local Management Interface (LMI) 15610.6 Frame-Relay-Netzwerk-Implementation 15710.6.1 Öffentliche Netzwerke 15810.6.2 Private Unternehmensnetze 15910.7 Frame-Formate des Frame-Relay 15910.7.1 Standard-Frame des Frame Relay 15910.7.2 LMI-Frame-Format 161

11 High-Speed Serial Interface 16311.1 Hintergrund 16311.2 Grundlagen zum HSSI 16311.3 HSSI-Betrieb 16411.3.1 Rückkopplungstests 165

12 Integrated Services Digital Network (ISDN) 16712.1 Hintergrund 16712.2 ISDN-Komponenten 16712.3 Dienste 16912.4 Schicht 1 17012.5 Schicht 2 17112.6 Schicht 3 172

13 Point-to-Point Protocol 17513.1 Background 17513.2 PPP-Komponenten 17513.3 Das Verfahren 17613.4 Anforderungen der physischen Schicht 17613.5 PPP-Verbindungsschicht 17713.5.1 PPP-Verbindungssteuerungs-Protokoll 178


14 Switched Multimegabit Data Service (SMDS) 18114.1 Hintergrund 18114.2 SMDS-Netzwerk-Komponenten 18114.3 SMDS Interface Protokoll (SIP) 18214.3.1 SIP-Stufen 18314.4 Distributed Queue Dual Bus (DQDB) 18414.5 SMDS-Zugriffsklassen 18614.6 Überblick zur SMDS-Adressierung 18614.7 SMDS-Referenz: SIP-Stufe-3-PDU-Format 18714.8 SMDS-Referenz: SIP-Stufe-2-Zellformat 189

15 ADSL – Asymmetric Digital Subscriber Line 19315.1 Hintergrund 19315.1.1 ADSL-Standardisierung 19315.2 Überblick zur ADSL-Technologie 19415.3 ADSL-Funktionen 19515.4 ADSL-Referenzmodell 197

16 Synchronous Data-Link Control und Derivate 20116.1 Hintergrund 20116.2 SDLC-Typen und Topologien 20216.3 SDLC-Frame-Format 20316.4 Abgeleitete Protokolle 20516.4.1 High-Level Data-Link Control (HDLC) 20516.4.2 Link-Access Procedure, Balanced (LAPB) 20616.4.3 IEEE 802.2 20716.4.4 Qualified Logical-Link Control (QLLC) 208

17 X.25 20917.1 Hintergrund 20917.2 X.25-Geräte und -Protokollfunktion 21017.2.1 Packet Assembler/Disassembler (PAD) 21017.2.2 X.25-Sitzung einrichten 21117.2.3 Virtuelle Verbindungen bei X.25 21117.3 X.25-Protokolle 21317.3.1 Packet-Layer Protocol (PLP) 21417.3.2 Link-Access Procedure, Balanced (LAPB) 21517.3.3 X.21bis-Protokoll 21617.4 LAPB-Frame-Format 21717.5 X.121-Adreß-Format 218

Teil 4 Bridging und Switching 221

18 Asynchronous Transfer Mode (ATM) 22318.1 Grundlagen 22318.1.1 Standards 22318.2 ATM-Geräte und Netzwerkumgebungen 22418.2.1 ATM-Zellen-Basisformat 224


18.2.2 ATM-Geräte 22518.2.3 ATM-Netzwerkschnittstellen 22618.3 ATM-Zellenkopf-Format 22718.3.1 Felder im ATM-Zellenkopf 22718.4 ATM-Dienste 22818.4.1 ATM Virtual Connections 22918.5 ATM-Switch-Betrieb 22918.6 ATM-Referenzmodell 23018.6.1 ATM, Physikalische Schicht 23118.6.2 ATM-Anpassungsschichten: AAL1 23218.6.3 ATM-Anpassungsschichten: AAL3/4 23318.6.4 ATM-Anpassungsschicht: AAL5 23418.7 ATM-Adressierung 23418.7.1 Sub-Netzwerk-Modell der Adressierung 23518.7.2 NSAP-Format-ATM-Adresse 23518.7.3 ATM-Adreßfelder 23618.8 ATM-Verbindungen 23718.9 ATM und Multicasting 23818.10 ATM Quality of Service (QoS) 23918.11 ATM-Signalisierung und Verbindungsaufbau 24018.11.1 ATM-Verbindungsaufbau 24118.11.2 Routing und Verhandlung der Verbindungsanforderung 24118.12 ATM-Meldungen für die Verbindungsverwaltung 24218.13 LAN-Emulation (LANE) 24218.13.1 LANE-Protokoll-Architektur 24418.13.2 Bestandteile des LANE 24518.13.3 Verbindungsarten der LAN-Emulation 24618.13.4 LANE im Betrieb 248

19 Data-Link Switching 25119.1 Grundlagen 25119.2 DLSw im Vergleich mit Source-Route-Bridging 25219.3 DLSw-SNA-Unterstützung 25419.4 DLSw-Switch-to-Switch Protocol (SSP) 25519.5 DLSw-Betrieb 25619.5.1 DLSw-Prozesse 25619.6 DLSw-Meldungsformate 260

20 LAN Switching 26720.1 Grundlagen 26720.1.1 Zur Geschichte 26820.2 Einsatz von LAN-Switches 26820.2.1 Vermittlung beim LAN-Switching 26920.2.2 Bandbreite des LAN-Switching 27020.3 LAN-Switch und das OSI-Modell 270


21 Tag Switching 27321.1 Grundlagen 27321.2 Die Tag-Switching-Architektur 27421.2.1 Die Forwarding-Komponente 27421.2.2 Steuerungskomponenten 27621.3 Destination-Based Routing (zielbasiertes Routing) 27621.3.1 Downstream-Tag-Zuweisung 27721.3.2 Downstream-Tag-Zuweisung auf Anforderung 27821.3.3 Upstream-Tag-Zuweisung 27821.4 Hierarchical-Routing 28021.5 Flexibles Routing durch explizite Routen 28121.6 Multicast-Routing 28221.7 Tag-Switching mit ATM 28321.8 Quality of Service 28421.9 IP-Switching 285

22 Mixed-Media-Bridging 28722.1 Grundlagen 28722.2 Übertragungsanforderungen 28822.3 Translational-Bridging 29022.4 Source-Route-Transparent-Bridging 293

23 Source-Route Bridging (SRB) 29523.1 Grundlagen 29523.2 SRB-Algorithmus 29523.3 Frame-Format 29723.3.1 Routing-Control-Feld 29823.3.2 Routing-Designator-Felder 299

24 Transparent-Bridging 30124.1 Grundlagen 30124.2 Transparent-Bridging-Betrieb 30124.2.1 Bridging-Loops 30224.2.2 Spanning-Tree-Algorithmus (STA) 30424.3 Frames-Format 307

Teil 5 Netzwerk-Protokolle 311

25 AppleTalk 31325.1 Background 31325.2 AppleTalk-Netzwerk-Komponenten 31425.2.1 Sockets 31525.2.2 Knoten 31525.2.3 Netzwerke 31625.2.4 Zonen 31725.3 Bitübertragungs- und Sicherungsschichten

von AppleTalk 31825.3.1 EtherTalk 31925.3.2 LocalTalk 320


25.3.3 TokenTalk 32225.3.4 FDDITalk 32325.4 Netzwerk-Adressen 32425.4.1 Zuweisung von Netzwerk-Adressen 32425.5 AppleTalk Address-Resolution Protocol (AARP) 32525.5.1 Address-Mapping Table 32625.5.2 Address Gleaning 32625.5.3 AARP-Operation 32725.6 Datagram-Delivery Protocol (DDP) im Überblick 32725.6.1 DDP-Übertragungsverfahren 32825.7 AppleTalk-Transportschicht 32925.7.1 Routing-Table Maintenance Protocol (RTMP) im

Überblick 32925.7.2 Name-Binding Protocol (NBP) im Überblick 33025.7.3 AppleTalk Update-Based Routing Protocol (AURP) 33225.7.4 AppleTalk Transaction Protocol (ATP) 33425.7.5 AppleTalk Echo Protocol (AEP) 33425.8 AppleTalk-Protokolle der oberen Schichten 33525.8.1 AppleTalk Data-Stream Protocol (ADSP) 33625.8.2 Zone Information Protocol (ZIP) 33625.8.3 AppleTalk Session Protocol (ASP) 33725.8.4 Printer-Access Protocol (PAP) im Überblick 33825.8.5 AppleTalk Filing Protocol (AFP) 33825.9 AppleTalk-Protokollreihe 33825.9.1 Format von DDP-Paketen 339

26 DECnet 34126.1 Background 34126.2 DECnet Phase IV Digital Network Architecture (DNA) 34226.2.1 Die Schichten von Phase-IV-DNA 34326.2.2 Phase-IV-DECnet-Adressierung 34426.3 DECnet/OSI Digital Network Architecture (DNA) 34526.3.1 DECnet/OSI-DNA-Implementierungen 34526.4 DECnet-Medienzugriff 34626.5 DECnet-Routing 34726.6 DECnet-Endkommunikationsschicht 34826.6.1 Network-Services Protocol 34826.7 DECnet/OSI-Transportschicht 34826.8 Die oberen Schichten von DECnet Phase IV 34926.8.1 Benutzerschicht 34926.8.2 Netzwerk-Managementschicht 35026.8.3 Netzwerk-Anwendungsschicht 35026.8.4 Verbindungskontrollschicht 35126.9 Die oberen Schichten von DECnet/OSI 35126.9.1 Anwendungsschicht 35126.9.2 Darstellungsschicht 35226.9.3 Verbindungskontrollschicht 352


27 IBM Systems Network Architecture (SNA) Protokolle 35527.1 Background 35527.2 Traditionelle SNA-Umgebungen 35627.2.1 IBM-SNA-Architektur 35627.2.2 Physische Entitäten von IBM SNA 35727.2.3 Datenübermittlungssteuerung von IBM SNA 35827.2.4 IBM Network-Addressable Units (NAUs) 36027.2.5 IBM SNA-Knoten 36127.3 IBM Peer-to-Peer-Netzwerke 36227.3.1 APPN-Komponenten 36227.3.2 Knotenarten von IBM APPN 36327.3.3 IBM APPN-Dienste 36427.4 Das Format der Basic Information Unit (BIU) 36927.4.1 Die Felder der BIU 36927.5 Das Format der Path Information Unit (PIU) 37127.5.1 Die Felder der PIU 371

28 Internet-Protokolle 37528.1 Background 37528.2 Internet-Protokoll (IP) 37728.2.1 Das Format des IP-Pakets 37728.2.2 IP-Adressierung 37928.2.3 IP-Adreßklassen 38028.3 Address-Resolution Protocol (ARP) im Überblick 38628.4 Internet-Routing 38628.4.1 IP-Routing 38728.5 Internet Control-Message Protocol (ICMP) 38828.5.1 ICMP-Nachrichten 38828.5.2 ICMP Router-Discovery Protocol (IDRP) 38928.6 Transmission-Control Protocol (TCP) 39028.6.1 TCP-Verbindungsaufbau 39128.6.2 Positive Acknowledgment and Retransmission (PAR) 39228.6.3 TCP Sliding Window 39228.6.4 TCP-Paketformat 39328.6.5 Beschreibung der TCP-Paketfelder 39328.7 User Datagram Protocol (UDP) 39428.8 Die Anwendungsschichtprotokolle der

Internet-Protokolle 395

29 NetWare-Protokolle 39729.1 Hintergrund 39729.2 NetWare Medienzugriff 39829.3 Internetwork Packet Exchange (IPX) im Überblick 39929.4 IPX-Kapselungsarten 40029.5 Service-Advertisement Protocol (SAP) 40129.5.1 SAP-Filter 40229.6 NetWare-Transportschicht 402


29.7 NetWare-Protokolle und Dienste der oberen Schichten 40229.7.1 NetWare-Dienste der Anwendungsschicht 40329.8 IPX-Paketformat 404

30 Protokolle der Open System Interconnection (OSI) 40730.1 Hintergrund 40730.2 OSI-Netzwerkprotokolle 40730.2.1 Physikalische Bitübertragungsschicht und

Datensicherungsschicht von OSI 40830.2.2 OSI-Netzwerkschicht 40930.2.3 OSI-Protokolle für die Transportschicht 41230.2.4 OSI-Protokolle für die Kommunikationsschicht 41430.2.5 OSI-Protokolle für die Darstellungsschicht 41530.2.6 OSI-Protokolle für die Anwendungsschicht 416

31 Banyan VINES 41931.1 Hintergrund 41931.2 Medienzugriff 42031.3 Netzwerkschicht 42031.3.1 VINES Internetwork Protocol (VIP) 42031.3.2 Routing Table Protocol (RTP) 42531.3.3 Address Resolution Protocol (ARP) 42631.3.4 Internet Control Protocol (ICP) 42731.4 Transportschicht 42731.5 Protokolle übergeordneter Schichten 428

32 Xerox Network Systems (XNS) 42932.1 Hintergrund 42932.2 Übersicht über die XNS-Hierarchie 43032.3 Medienzugriff 43132.4 Netzwerkschicht 43132.5 Transportschicht 43332.6 Protokolle übergeordneter Schichten 434

Teil 6 Routing-Protokolle 437

33 Border Gateway Protocol (BGP) 43933.1 Hintergrund 43933.2 BGP-Operationen 44033.3 BGP-Routing 44233.4 Nachrichtentypen von BGP 44333.5 BGP-Paketformate 44433.5.1 Header-Format 44433.5.2 Format der Open-Nachricht 44533.5.3 Format der Update-Nachricht 44633.5.4 Format der Notification-Nachricht 448

34 Enhanced IGRP 45134.1 Hintergrund 45134.2 Fähigkeiten und Attribute von Enhanced IGRP 452


34.3 Zugrundeliegende Prozesse und Techniken 45334.4 Begriffe zum Routing 45434.4.1 Nachbartabellen 45534.4.2 Topologietabellen 45534.4.3 Routenzustände 45634.4.4 Routenkennzeichnung 45634.5 Pakettypen von Enhanced IGRP 457

35 IBM Systems Network Architecture (SNA) Routing 45935.1 Hintergrund 45935.2 IBM-SNA-Sitzungsverbindungen 46035.3 IBM-SNA-Übertragungsgruppen 46035.4 IBM-SNA – explizite und virtuelle Routen 46135.5 IBM-SNA-Dienstklassen 46235.5.1 Dienstklassen beim Subarea Routing 46235.5.2 Dienstklassen beim APPN Routing 46335.6 IBM SNA – Subarea Routing 46535.7 IBM Advanced Peer-to-Peer Networking (APPN)

Routing 46635.7.1 IBM APPN – Node Type 2.1 Routing 46735.7.2 IBM APPN – DLUR/S Routing 47035.7.3 IBM-APPN-Verbindungsnetzwerk 47035.7.4 IBM APPN – Übergangsknoten 471

36 Interior Gateway Routing Protocol (IGRP) 47336.1 Hintergrund 47336.2 Eigenschaften von IGRP 47436.2.1 Stabilitätsmerkmale 47536.2.2 Timer 477

37 Internet Protocol (IP) Multicast 47937.1 Hintergrund 47937.2 Internet Group Membership Protocol (IGMP) 47937.3 Protokolle für das IP Multicast-Routing 48037.3.1 Protocol-Independent Multicast (PIM) 48137.3.2 Distance-Vector Multicast Routing Protocol (DVMRP) 48237.3.3 Multicast Open Shortest Path First (MOSPF) 482

38 NetWare Link Services Protocol (NLSP) 48538.1 Hintergrund 48538.2 NLSP – hierarchisches Routing 48638.2.1 Leistungen des hierarchischen Routing 48738.2.2 NLSP – angrenzende Umgebung 48738.2.3 Hello-Pakete im LAN verschicken 48938.3 NLSP – Vorgehen 48938.4 NLSP – hierarchische Adressierung 49038.5 NLSP – Hello-Pakete 49138.5.1 Hello-Pakete für WANs 49238.5.2 Hello-Pakete für LANs 494


39 Open Systems Interconnection (OSI) Routing-Protokoll 49739.1 Hintergrund 49739.1.1 OSI-Netzwerk-Terminologie 49839.2 Endsystem-zu-Zwischensystem (ES-IS) 49939.2.1 ES-IS-Konfiguration 49939.2.2 ES-IS-Adressierung 50039.3 Zwischensystem-zu-Zwischensystem (IS-IS) 50039.3.1 OSI – der Routing-Vorgang 50139.3.2 IS-IS – Metriken 50239.4 Integrated IS-IS 50439.5 Interdomain Routing Protocol (IDRP) 50539.5.1 IDRP – Terminologie 50539.5.2 IDRP-Routing 506

40 Open Shortest Path First (OSPF) 50740.1 Hintergrund 50740.2 Routing-Hierarchie 50840.3 SPF-Algorithmus 51140.4 Paketformat 51240.5 Weitere Eigenschaften von OSPF 513

41 Resource Reservation Protocol (RSVP) 51541.1 Hintergrund 51541.2 RSVP – Datenströme 51641.2.1 RSVP – Bearbeitung von Datenströmen 51841.3 RSVP – Dienstqualität 51941.4 RSVP – Hochfahren der Sitzung 51941.5 RSVP – Reservierungsmethode 51941.5.1 Wildcard-Filter-Methode (WF) 52041.5.2 Fixed-Filter-Methode (FF) 52041.5.3 Shared-Explicit-Methode (SE) 52141.5.4 Folgen der Reservierungsmethoden 52141.6 RSVP – Soft-State-Implementierung 52141.7 RSVP – Modell des Ablaufs 52341.7.1 Allgemeiner Protokollablauf von RSVP 52341.7.2 RSVP – Tunneln 52441.8 RSVP – Nachrichten 52641.8.1 Reservation-Request-Nachrichten 52641.8.2 Pfadnachrichten 52641.8.3 Fehler- und Acknowledgment-Nachrichten 52641.8.4 Abbaunachrichten 52741.9 RSVP – Paketformat 52841.9.1 Felder des Nachrichten-Headers für RSVP 52841.9.2 Objektfelder für RSVP 529

42 Routing Information Protocol (RIP) 53342.1 Hintergrund 53342.2 Routing-Updates 534


42.3 RIP – Routing-Metrik 53442.4 RIP – Stabilitätsmerkmale 53542.5 RIP – Timer 53542.6 Paketformate 53542.6.1 Paketformat von RIP 53642.6.2 Paketformat von RIP 2 537

43 Simple Multicast Routing Protocol (SMRP) 53943.1 Hintergrund 53943.2 SMRP – Multicast-Transportdienste 54043.2.1 SMRP – Verwaltung von Multicast-Adressen 54243.2.2 SMRP – Multicast-Transaktionsprotokoll (MTP) 54443.2.3 SMRP – Knotenverwaltung 54543.2.4 SMRP – Multicast-Routen 54743.2.5 SMRP – Verwaltung von Multicast-Gruppen 54843.2.6 Weiterleiten von Multicast-Datagrammen 54943.2.7 Umgang mit Topologieänderungen unter SMRP 55043.3 SMRP – Beispiel für eine Transaktion 55143.4 SMRP – Paketformat 552

Teil 7 Netzwerk-Verwaltung 555

44 IBM Netzwerk-Verwaltung 55744.1 Hintergrund 55744.2 IBM – Funktionale Bereiche der Netzwerk-Verwaltung 55844.2.1 IBM – Konfigurationsverwaltung 55844.2.2 IBM – Performance- und Accounting-Verwaltung 55944.2.3 IBM – Problemverwaltung 55944.2.4 IBM – Betriebsverwaltung 56044.2.5 IBM – Änderungsverwaltung 56044.3 IBM-Architekturen zur Netzwerk-Verwaltung 56144.3.1 Open Network Architecture (ONA) 56144.3.2 SystemView 56344.4 IBM – Plattformen zur Netzwerk-Verwaltung 56344.4.1 NetView 56344.4.2 LAN Network Manager (LNM) 56444.4.3 Simple Network Management Protocol (SNMP) 564

45 Remote Monitoring (RMON) 56545.1 Hintergrund 56545.2 RMON-Gruppen 566

46 Simple Network Management Protocol (SNMP) 56946.1 Hintergrund 56946.2 SNMP – Grundlegende Komponenten 57046.3 SNMP – Grundlegende Befehle 57146.4 SNMP – Management Information Base (MIB) 57246.5 SNMP und Datendarstellung 573


46.6 SNMP Version 1 (SNMPv1) 57446.6.1 SNMPv1 und Structure of Management Information

(SMI) 57446.6.2 SNMPv1 – Protokolloperationen 57646.7 SNMP Version 2 (SNMPv2) 57646.7.1 SNMPv2 und Structure of Management Information

(SMI) 57646.8 SNMP – Verwaltung 57846.9 SNMP – Sicherheit 57846.10 SNMP – Zusammenarbeit 57946.10.1 Proxy-Agenten 57946.10.2 »Zweisprachige« Netzwerk-Verwaltungssysteme 57946.11 SNMP-Referenz: SNMPv1 Nachrichtenformate 58046.11.1 SNMPv1 – Nachrichten-Header 58046.11.2 SNMPv1 – Protokolldateneinheit (PDU) 58046.11.3 Format von Trap PDU 58146.12 SNMP-Referenz: SNMPv2 Nachrichtenformate 58246.12.1 SNMPv2 – Nachrichten-Header 58246.12.2 SNMPv2 – Protokolldateneinheit (PDU) 583

Glossar 585

Stichwortverzeichnis 683

Vorwort

Die Technologien der Datenkommunikation entwickeln sichmit enormer Geschwindigkeit weiter. Die steigende Nachfragenach Internet-Zugriff und Internet-Dienstleistungen fördertden raschen technischen Wandel bei Anwendern und Herstel-lern. Unglücklicherweise führt dies bei der Erstellung einerInformationsquelle wie diesem vorliegenden Handbuch dazu,daß einige der Informationen bei Drucklegung bereits veraltetsind.

Der Ansatz der Autoren dieses Buches war es, den Lesern zuhelfen, auf der Grundlage der gebotenen Informationen tech-nologische Entscheidungen zu treffen und sich über das ge-nannte Dilemma im klaren zu sein. Wir hoffen, daß diese ersteAusgabe ein Schritt in die richtige Richtung ist und daß Sie zu-sammen mit den anderen Büchern der Cisco-Press-Reihe inder Lage sein werden, auch bei sich ändernden Anforderungendiejenigen Technologien auszuwählen, die funktionierendeNetzwerklösungen bereitstellen.

Ziele

Diese Publikation bietet technische Informationen zu Inter-networking-Technologien auf Cisco-Basis. Es kann in Verbin-dung mit anderen Cisco-Handbüchern oder als eigenständigeReferenz genutzt werden. Das Handbuch Netzwerktechno-logien (amerikanischer Originaltitel: Internetworking Techno-logies Handbook) kann nicht alle Informationen zu denerwähnten Technologien liefern. Eines der Hauptziele dieser

Vorwort

20 Vorwort

Publikation ist es, Netzwerk-Administratoren bei der Konfi-guration von Cisco-Produkten zu unterstützen. Daher legt dasBuch einen Schwerpunkt auf Cisco-unterstützte Systeme; dieerwähnten Technologien setzen eine Unterstützung durchCisco jedoch nicht voraus.

Zielgruppe

Dieser Band wurde für all diejenigen geschrieben, die dieFunktionsweise von Netzwerken verstehen wollen. Wir ver-muten, daß die meisten Leser die Informationen aus diesemBuch nutzen werden, um die Anwendbarkeit bestimmter Tech-nologien für ihre Netzwerkumgebungen zu bewerten.

Aufbau

Dieses Buch besteht aus sieben Teilen. Jeder Teil befaßt sichmit Grundlagen oder zentralen Bereichen der Netzwerk- undInternetworking-Technologien. Sie bestehen aus Kapiteln, dieentsprechende Aufgaben und Funktionen beschreiben.

Teil 1 – »Einführung in das Internetworking« – stellt die Kon-zepte dar, die grundlegend für das Verständnis des Internet-working und des Netzwerk-Managements sind.

Teil 2 – »LAN-Protokolle« – beschreibt die Standardproto-kolle, die für den Zugriff auf die physikalischen Medien desNetzwerks eingesetzt werden.

Teil 3 – »WAN-Technologien« – beschreibt die Standardpro-tokolle, die für die Einrichtung von WANs genutzt werden.

Teil 4 – »Bridging und Switching« – erläutert die Protokolleund Technologien, die für die Connectivity zwischen Subnetz-werken auf Schicht 2 genutzt werden.

Teil 5 – »Netzwerkprotokolle« – beschreibt die Standardnetz-werkprotokollstapel, die in einem Netzwerk geroutet werdenkönnen.

Teil 6 – »Routing-Protokolle« – erläutert die Protokolle, diefür das Routing von Informationen in einem Internetwork ge-nutzt werden.

Vorwort 21

Teil 7 – »Netzwerk-Verwaltung« – beschreibt die Architekturund den Betrieb von weit verbreiteten Implementierungen fürdas Netzwerk-Management.

Danksagung

Dieses Buch wurde im Team geschrieben. Es ist das Ergebnismehrerer Jahre der Informationssammlung und integriert di-verse Informationsquellen, die von den Entwicklern von CiscoKnowledge Products erstellt wurden. Die Hauptautoren dieserPublikation sind Merilee Ford, H. Kim Lew, Steve Spanier undTim Stevenson. In der letzten Überarbeitungsphase habenMargaret Young und Rick Fairweather bei der Integration desMaterials in dieses Buch einen wertvollen Beitrag geleistet.

Die Autoren möchten all den Cisco-Experten danken, die dasMaterial überarbeitet und darüber hinaus mit ihrem fun-dierten Wissen zu den dargestellten Technologien beigetragenhaben. Einen Beitrag leisteten Priscilla Oppenheimer, AvivaGarrett, Steve Lin, Manoj Leelanivas, Kent Leung, Dave Stine,Ronnie Kon, Dino Farinacci, Fred Baker, Kris Thompson,Jeffrey Johnson, George Abe, Yakov Rekhter, Abbas Masnavi,Alan Marcus, Laura Fay, Anthony Alles, David Benham,Debra Gotelli, Ed Chapman, Bill Erdman, Tom Keenan, SoniJiandani, Derek Yeung und viele mehr. Die Autoren möchtenallen danken, die ihre Zeit geopfert und wichtige Beiträgegeleistet haben, um dieses Buch zu einer wertvollen Informa-tionsquelle zu machen.

Diese Publikation bedient sich großzügig anderer Publikatio-nen und Schulungsprodukte, die von Cisco entwickelt wurden.Insbesondere die Publikation Internetworking TechnologyOverview und die Multimedia-CD-ROM Cisco ConnectionTraining bildeten die Grundlage für diese Informationssamm-lung.

22 Vorwort

Vorwort zur deutschen Übersetzung

Netzwerk-Planer und -Betreiber werden permanent mit denimmer komplizierter werdenden Anforderungen der eingesetz-ten Applikationen hinsichtlich deren Bedarf an Bandbreite undServices konfrontiert. Welche dieser Anforderungen stellt dieWeichen, mit welchen Technologien ein Backbone geplantbzw. betrieben wird? Was sind die Entscheidungsgrundlagenbei der Auswahl der Kommunikations- bzw. Routing-Proto-kolle? Welche Sicherheitsaspekte sollten berücksichtigt wer-den? Und wie integriert man Mainframes und ihre Groß-rechnerwelten in die Datenkommunikation von Enterprise-Netzen? Gerade die Skalierbarkeit von großen unternehmens-weiten Backbones stellt heute eines der größten Probleme immodernen Netzdesign dar. Speziell in diesem Bereich machendie heutigen Kommunikationsformen, Applikationen undServiceanforderungen den Einsatz völlig neuer Technologiennotwendig, um diesen Anforderungen gerecht zu werden.

Bisher war Cisco's Internetworking-Know-how hauptsächlichunseren Kunden zugänglich. Nun möchten wir mit der Grün-dung des Cisco Presse Forums neue Wege beschreiten, umunser Expertenwissen mit Ihnen zu teilen.

Unser Ziel ist es dabei, eine komplette Fachbibliothek vonPublikationen zum Thema Internetworking zu erstellen. Indiesen Veröffentlichungen sollen praxisorientierte, nützlicheTips über Design und Implementation von Routern, Switches,Access-Servern und netzübergreifenden Software-Lösungen imVordergrund stehen.

»Netzwerk-Technologien« ist das zweite Buch dieser Reihe.Darin möchten wir Ihnen einen tiefen Einblick in die Gesetzeund Grundlagen des Internetworking, die Anforderungen undEinsatzmöglichkeiten von Netzwerk-Protokollen und die Um-setzung von umfassenden Netzkonzepten geben. Es beschreibtausführlich die Grundlagen und Problematiken, mit denensich jeder Netzdesigner auseinandersetzen muß, der Netz-werke plant oder realisiert. Dabei fließen sowohl unsere lang-jährige Erfahrung als auch nützliche Tips aus der Praxis beiDesign- und Implementationsproblematiken von Netzstruk-turen ein.

Vorwort 23

»Netzwerk-Technologien« ist ein Buch, das Ihnen leicht ver-ständlich die wichtigsten Technologie-, Design- und Imple-mentationsrichtlinien des Internetworking erläutert. Es kanndurch seine übersichtliche Strukturierung jederzeit als Nach-schlagewerk für technologische Fachbegriffe und netzwerk-spezifische Fachfragen genutzt werden.

Wir hoffen, daß diese Publikation auch eine Bereicherung fürIhre Netzwerk-Bibliothek ist.

Ralf Kothe

Product Marketing ManagerCisco Systems GmbH

Kapitel 1: Grundlagen des InternetworkingKapitel 2: Einführung in die LAN-ProtokolleKapitel 3: Einführung in die WAN-TechnologienKapitel 4: Grundlagen des Bridging und SwitchingKapitel 5: Grundlagen des RoutingKapitel 6: Grundlagen des Netzwerk-Managements

Teil 1: Einführung in das Internetworking

Teil 1, »Einführung in das Internetworking«, gibt einen gro-ben Überblick zu den Technologien des Internetworking undzur Terminologie. In den einzelnen Kapiteln werden folgendeThemen besprochen:

Grundlagen des Internetworking – Im ersten Kapitel werdengrundlegende Dinge des Internetworking, einschließlich desOSI-Modells, der Adressierung, Netzwerk-Services behandelt.

Einführung zu den LAN-Protokollen – Dieses Kapitel bieteteinen Überblick zu den gängigen LAN-Protokollen der Siche-rungsschicht (auch Verbindungsschicht) und der physischenSchicht.

Einführung in die WAN-Technologien – In diesem Kapitelwerden WAN-Protokolle, -Geräte und -Implementationen imÜberblick dargestellt.

Grundlagen des Bridging und Switching – In diesem Kapitelwird ein Überblick zu den Bridging- und Switching-Technolo-gien gegeben.

Grundlagen des Routing – Eine Einführung in die Routing-Protokolle.

Grundlagen des Netzwerk-Management – Dieses Kapitel bie-tet einen groben Überblick über das Netzwerk-Managementund OSI-Netzwerk-Management-Modell.

TEIL 1Einführung in das Internetworking

1 Grundlagen des Internetworking

Dieses Kapitel stellt die grundlegenden Konzepte und Begriffeaus dem Bereich des Internetworking vor. So wie das Buch alsGanzes dem Verständnis der modernen Netzwerk-Technikdient, werden in diesem Kapitel einige Themen, die im allge-meinen bekannt sind, nur kurz behandelt. Dazu gehören dieFlußsteuerung, die Fehlerprüfung und das Multiplexing, je-doch wird der Schwerpunkt auf die Darstellung des OSI-Modells (Open System Interconnect) im Zusammenhang mitNetzwerk-/Internetworking-Funktionen gelegt. Es wird einÜberblick zu Adressierungsverfahren in Hinblick auf das OSI-Modell gegeben.

1.1 Was ist ein Internetwork?

Ein Internetwork besteht aus mehreren einzelnen Netzwerken,die über dazwischengeschaltete Netzwerk-Geräte miteinanderverbunden sind, so daß ein großes Netzwerk entsteht. Inter-networking bezieht sich auf die Industrie, Produkte und Ver-fahren, die es ermöglichen, ein Internetwork aufzubauen undzu administrieren. Bild 1.1 zeigt verschiedene Netzwerk-Tech-nologien, die über Router oder andere Netzwerk-Geräte mit-einander zu einem Internetwork verbunden werden können:

KAPITEL 1Grundlagen desInternetworking

28 Handbuch Netzwerk-Technologien

FDDI

TokenRing

WANEthernet

1.1.1 Die Geschichte des Internetworking

Die ersten Netzwerke waren Netzwerke im Teilnehmerbetrieb,bei denen Großrechner (Mainframes) mit angeschlossenenTerminals zum Einsatz kamen. Solche Umgebungen wurdenmit der System Network Architecture (SNA) von IBM und derNetzwerk-Architektur von Digital eingerichtet.

Anmerkung des Übersetzers: Hier scheint man sich auf dienordamerikanische Welt zu beschränken, denn Siemenshat/hatte mit seinem Großrechner-Betriebssystem BS2000und dem zugehörigen Transdata-Netz gleiches zu bieten.

Lokale Netzwerke (Local Area Network – LAN) entstandenwährend der PC-Revolution. In einem LAN können viele Be-nutzer, die räumlich nicht zu weit voneinander entfernt waren,Dateien und Nachrichten austauschen und auf Ressourcengemeinsam zugreifen, z.B. auf Datei-Server.

Weitverkehrsnetze (Wide Area Network – WAN) verbindenLANs miteinander über normale Telefonleitungen (oder an-dere Medien), wobei die Benutzer (resp. die LANs) räumlichweiter voneinander entfernt sind.

Heute sind Hochgeschwindigkeits-LANs und vermittelte Inter-networks weitverbreitet und häufig im Einsatz, weil die Über-tragungsgeschwindigkeiten sehr hoch sind und sehr Band-

Bild 1.1:Verschiedene

Netzwerk-Technologienkönnen zu ei-nem Internet-work verbun-

den werden

Kapitel 1 • Grundlagen des Internetworking 29

breite-intensive Anwendungen wie Telefon- und Video-Konfe-renzen unterstützt werden.

Das Internetworking entwickelte sich als Lösung der folgen-den drei Schlüsselprobleme: voneinander isolierte LANs, dop-pelte Haltung von Ressourcen und fehlende Netzwerk-Verwal-tung. Aufgrund der abgeschlossenen LANs war es unmöglich,daß verschiedene Büros oder Abteilungen elektronisch mitein-ander kommunizierten. Bei der doppelten Haltung von Res-sourcen mußte die gleiche Hard- bzw. Software in jedem Büround in jeder Abteilung vorhanden sein und vom eigenen Sup-port eingerichtet und verwaltet werden. Für die Netzwerk-Verwaltung gab es keine zentralisierte Verwaltung und Verfah-ren für die Fehlerbehebung.

1.1.2 Die Herausforderungen des Internetworking

Ein funktionierendes Internetwork zu implementieren, istkeine leichte Aufgabe. Dabei sind eine Vielzahl von Anforde-rungen zu berücksichtigen, insbesondere was die Connectivity,die Zuverlässigkeit, das Netzwerk-Management und die Flexi-bilität betrifft. Jeder dieser Bereiche ist ein Schlüssel für denAufbau eines effizienten und effektiven Internetwork.

Eine der Herausforderungen beim Verbinden verschiedenerSysteme stellt die Unterstützung der Kommunikation zwischenunterschiedlichen Technologien dar. So können in verschiede-nen Niederlassungen z.B. verschiedene Medien verwendetwerden, oder die Datenübertragung erfolgt in verschiedenenRaten.

Eine weitere wichtige Überlegung betrifft die Betriebszuver-lässigkeit eines Internetwork. Sowohl einzelne Benutzer alsauch ein Unternehmen benötigen konsistenten, zuverlässigenZugriff auf die Netzwerk-Ressourcen.

Des weiteren muß das Netzwerk-Management über einen zen-tralen Support und Möglichkeiten der Fehlerbeseitigung imInternetwork verfügen. Die Konfiguration, Sicherheit, Perfor-mance und weitere Anforderungen müssen entsprechend be-dient werden, um die Funktionalität eines Internetwork ge-währleisten zu können.


Flexibilität, als abschließende Überlegung, ist für den Fall derNetzwerk-Erweiterung, neuer Anwendungen und Dienste un-abdingbar.

1.2 Das OSI-Referenzmodell

Das OSI-Referenzmodell (Open System Interconnection –OSI) beschreibt den Weg, den Daten von einer Software-An-wendung auf einem Computer über das Netzwerk-Mediumbis zu einer Anwendung auf einem anderen Rechner nehmen.Das OSI-Referenzmodell ist ein Konzept, das diesen Weg insieben Schichten unterteilt, die jeweils eine einzelne Netzwerk-funktion spezifizieren. Dieses Modell wurde 1984 von der In-ternational Standardization Organization (ISO) entwickeltund wird heute als das primäre Architekturmodell für dieKommunikation zwischen Computern betrachtet. Das OSI-Modell unterteilt die Aufgaben, die beim Transport von Datenüber ein Netzwerk anfallen, in sieben kleinere, überschaubareGruppen. Dabei werden jeder der sieben OSI-Schichten eineAufgabe oder eine Gruppe von Aufgaben zugeordnet. JedeSchicht ist sinnvollerweise in sich abgeschlossen, so daß dieder Schicht zugeordnete Aufgabe unabhängig von anderenimplementiert werden kann. So kann die Implementation füreine Schicht aktualisiert werden, ohne daß andere Schichtendavon betroffen sind. Die folgende Liste nennt die siebenSchichten des OSI-Referenzmodells:

Schicht 7 application layer Anwendungsschicht (auch: Applika-tionsschicht)

Schicht 6 presentation layer Darstellungsschicht (auch: Datendar-stellungsschicht, Präsentationsschicht)

Schicht 5 session layer Kommunikationsschicht (auch:Kommunikationssteuerungsschicht,Sitzungsschicht)

Schicht 4 transport layer Transportschicht

Schicht 3 network layer Vermittlungsschicht (auch: Netzwerk-schicht)

Schicht 2 data link layer Sicherungsschicht (auch: Verbindungs-(sicherungs-)schicht)

Schicht 1 physical layer Physikalische Schicht (oft auch:physische Schicht)


Bild 1.2 stellt das siebenschichtige OSI-Referenzmodell gra-fisch dar.

Netzwork

Physikalisch

Anwendung

Darstellung

Kommunikation

Transport

Sicherung

3

1

7

6

5

4

2

1.2.1 Eigenschaften der OSI-Schichten

Die sieben Schichten des OSI-Referenzmodells können in zweiGruppen unterteilt werden: höhere bzw. obere Schichten undniedrige bzw. untere Schichten.

Die oberen Schichten des OSI-Modells betreffen Anwendun-gen und sind im allgemeinen nur als Software implementiert.Die höchste Schicht, die Anwendungsschicht, ist die dem Be-nutzer nächste Schicht. Sowohl die Benutzerschicht als auchdie Anwendungsschicht interagieren mit Software-Anwendun-gen, die eine Kommunikationskomponente enthalten. Wennvon höherer Schicht die Rede ist, dann wird damit manchmalauch nur die nächsthöhere Schicht im OSI-Modell bezeichnet.

Die unteren Schichten eines OSI-Modells betreffen den Da-tentransport. Die physische Schicht und die Verbindungs-schicht sind als Hard- und Software implementiert. Die restli-chen unteren Schichten sind nur als Software implementiert.Die unterste Schicht, die physische, ist dem physischen Netz-werk-Medium (z.B. der Netzwerk-Verkabelung) am nächstenund ist für das Absetzen der Daten auf das Medium zuständig.

Bild 1.3 zeigt die Unterteilung in untere und obere OSI-Schich-ten.

Bild 1.2:Das OSI-Refe-renzmodell be-steht aus siebenvoneinanderunabhängigenSchichten


Netzwerk

Physikalisch

Anwendung

Darstellung

Kommunikation

Transport

Sicherung

Datenübertragung

Anwendung

1.2.2 Protokolle

Das OSI-Modell bietet einen konzeptionellen Rahmen für dieKommunikation zwischen Computern, wobei das Modell ansich keine Methode für die Kommunikation ist. Die tatsächli-che Kommunikation wird erst durch den Einsatz von Proto-kollen möglich. Im Kontext von Datennetzwerken ist einProtokoll eine formale Zusammenstellung von Regeln undKonventionen, mit denen der Austausch von Daten zwischenComputern über ein Netzwerk-Medium geregelt wird. Miteinem Protokoll werden die Funktionen einer oder mehrererOSI-Schichten implementiert. Es gibt eine Vielzahl an Kom-munikationsprotokollen, die sich jedoch alle in eine der fol-genden Gruppen einordnen lassen: LAN-Protokolle, WAN-Protokolle, Netzwerk-Protokolle und Routing-Protokolle.LAN-Protokolle arbeiten auf der Ebene der physischen undder Verbindungsschicht des OSI-Modells und definieren dieKommunikation über verschiedene LAN-Medien. WAN-Pro-tokolle arbeiten auf der Ebene der drei untersten Schichten desOSI-Modells und definieren die Kommunikation über die ver-schiedenen Weitverkehrsmedien. Routing-Protokolle sindProtokolle der Vermittlungsschicht, die die Pfadfestlegung unddas Verkehrs-Switching regeln. Die Netzwerk-Protokolleschließlich sind verschiedene Protokolle der oberen Schichten,die zu einer bestimmten Protokollfamilie gehören.

Bild 1.3:Die OSI-

Schichten las-sen sich in zwei

Gruppen un-terteilen


1.2.3 Das OSI-Modell und die Kommunikationzwischen Systemen

Daten, die von einer Software-Anwendung des einen Compu-ters zur Software-Anwendung eines anderen Computers über-tragen werden sollen, müssen jede OSI-Schicht passieren.Wenn z.B. eine Anwendung auf System A Daten an eine An-wendung auf System B übertragen will, übergibt das Anwen-dungsprogramm auf System A diese Daten an die Anwen-dungsschicht (Schicht 7) des Systems A. Dann reicht dieAnwendungsschicht die Daten an die Darstellungsschicht(Schicht 6) weiter, die die Daten der Kommunikationsschicht(Schicht 5) übergibt usw. bis hinunter zur physischen Schicht(Schicht 1). Von der physischen Schicht werden die Daten indas physische Netzwerk-Medium eingespeist und darüber zumSystem B übertragen. Die physische Schicht des Systems B ent-fernt vom physischen Medium hinzugefügte Daten und gibtseine Daten an die Verbindungsschicht (Schicht 2) weiter, vonwo sie an die Vermittlungsschicht (Schicht 3) übergeben wer-den usw. bis hinauf zur Anwendungsschicht (Schicht 7) desSystems B. Die Anwendungsschicht des Systems B schließlichübergibt die Daten an das Programm, das als Empfänger be-stimmt ist, womit der Kommunikationsprozeß abgeschlossenist.

1.2.4 Interaktion zwischen den Schichten desOSI-Modells

Jede Schicht des OSI-Modells kommuniziert mit drei anderenOSI-Schichten: mit der nächsthöheren Schicht, mit der nächst-niedrigeren und mit der gleichen Schicht auf dem anderen,vernetzten Computer. So kommuniziert z.B. die Verbindungs-schicht des Systems A mit der Vermittlungs- und der physi-schen Schicht seines Systems und mit der Verbindungsschichtdes Systems B. Bild 1.4 veranschaulicht dieses Beispiel.


A BNetzwerk

Physikalisch

Anwendung

Darstellung

Kommunikation

Transport

Netzwerk

Physikalisch

Anwendung

Darstellung

Kommunikation

Transport

Sicherung Sicherung

1.2.5 Dienste der OSI-Schichten

Die aufeinanderfolgenden OSI-Schichten kommunizieren mit-einander, um ihre Dienste gegenseitig zu nutzen. Die Diensteder benachbarten Schichten dienen zur Kommunikation zwi-schen einer OSI-Schicht und der gleichen Schicht auf einemanderen Computer. Zu den Diensten der Schichten zählen dreigrundlegende Elemente: der Dienstbenutzer, der Dienstanbie-ter und der Dienstzugriffspunkt (Service Access Point – SAP).

In diesem Zusammenhang ist der Dienstbenutzer die OSI-Schicht, die von der benachbarten Schicht einen Dienst anfor-dert. Der Dienstanbieter ist die Schicht, die diesen Dienst demDienstbenutzer anbietet. OSI-Schichten können Dienste meh-reren Dienstbenutzern gleichzeitig anbieten. Beim SAP handeltes sich um einen konzeptionell bestimmten Ort, an dem eineOSI-Schicht den Dienst einer anderen Schicht anfordern kann.

Bild 1.5 stellt dar, wie diese drei Elemente auf der Vermitt-lungs- und Verbindungsschicht interagieren.

Bild 1.4:Die Schichten

des OSI-Modells kom-

munizieren mitanderen

Schichten


SAPs

DienstbenutzerProtokolle der Vermittlungsschicht

DienstanbieterProtokolle der Sicherungsschicht

Sicherungs-schicht

Vermittlungs-schicht

DienstbenutzerProtokolle der Vermittlungsschicht

1.2.6 Schichten des OSI-Modells und derDatenaustausch

Die sieben OSI-Schichten setzen verschiedene Formen vonSteuerdaten ein, um mit der gleichen Schicht auf einem ande-ren Computer zu kommunizieren. Diese Steuerdaten bestehenaus bestimmten Anforderungen und Anweisungen, die zwi-schen Partner-Schichten des OSI-Modells ausgetauscht wer-den.

Für Steuerdaten gibt es zwei Formen: den Header (Kopf) oderTrailer (Anhang). Der Header wird den von der höherenSchicht heruntergereichten Daten vorangestellt. Ein Trailerwird diesen Daten angehängt. Es ist allerdings nicht unbedingterforderlich, daß eine OSI-Schicht den heruntergereichtenDaten einen Header oder Trailer hinzufügt.

Die Bezeichnung Header, Trailer und Daten ist relativ zu ver-stehen, in Abhängigkeit von der Schicht, die die Informa-tionseinheit analysiert. Für die Vermittlungsschicht besteht dieInformationseinheit z.B. aus dem Header der Schicht 3 undden Daten. Auf Ebene der Verbindungsschicht wird jedochalles, was von der Vermittlungsschicht heruntergereicht wird,als Daten behandelt (also der Header der Schicht 3 und dieDaten).

Bild 1.5:Dienstbenutzer,-anbieter undSAPs interagie-ren auf Ebeneder Vermitt-lungs- undVerbindungs-schicht


Mit anderen Worten: Der Datenteil einer Informationseinheitauf Ebene einer bestimmten OSI-Schicht kann die Header,Trailer und Daten sämtlicher darüberliegenden Schichten ent-halten. Genau dies wird als Kapselung bezeichnet. Bild 1.6zeigt, wie Header und Daten einer Schicht vom Header derdarunterliegenden Schicht gekapselt werden.

Informationseinheit

7

6

5

4

3

2

1

7

6

5

4

3

2

1

System A System B

•

•

•

Netzwerk

Daten

Daten

Daten

DatenHeader 4

Header 2

Header 3

Verfahren des Datenaustauschs

Der Datenaustausch erfolgt zwischen den Partnerschichten desOSI-Modells. Jede Schicht des Quellsystems fügt den eigent-lichen Daten seine Steuerdaten hinzu. Jede Schicht des Ziel-systems analysiert die Steuerdaten und entfernt diese wieder.

Wenn System A Daten einer Anwendung an System B sendenwill, müssen die Daten an die Anwendungsschicht übergebenwerden. Die Anwendungsschicht des Systems A transportiertdann alle von der Anwendungsschicht des Systems B angefor-derten Steuerdaten, indem sie den Daten einen Header voran-stellt. Die sich daraus ergebende Informationseinheit (Header+ Daten) wird an die Darstellungsschicht weitergegeben, diewiederum ihren eigenen Header voranstellt, der Steuerinfor-mationen für die Darstellungsschicht des Systems B enthält.Die Informationseinheit wächst von Schicht zu Schicht mitSteuerdaten für die Partnerschichten im System B an, da jedeSchicht ihren Header anfügt (oder ihren Trailer). Von derphysischen Schicht wird die gesamte Informationseinheit indas Netzwerk-Medium eingespeist.

Die physische Schicht des Systems B empfängt die Informa-tionseinheit und reicht sie an die Verbindungsschicht. Diese

Bild 1.6:Header und

Daten könnenwährend des

Datenaus-tauschs gekap-

selt werden


liest die Steuerdaten aus dem Header, der von der Verbin-dungsschicht des Systems A hinzugefügt wurde. Der Headerwird entfernt und der Rest der Informationseinheit wird andie Vermittlungsschicht übergeben. Jede Schicht führt die glei-chen Aktionen aus: Sie liest den Header der Partnerschicht,entfernt diesen und übergibt den Rest der Informationseinheitan die nächsthöherliegende Schicht. Nachdem die Anwen-dungsschicht diese Aktionen ausgeführt hat, werden die Datenan die Anwendung des Systems B übergeben, für die die Datenbestimmt sind, und zwar genau in der Form, wie sie von derAnwendung des Systems A übertragen wurden.

1.2.7 Die physische Schicht des OSI-Modells

Die physische Schicht definiert die elektrische, mechanische,prozedurale und funktionale Spezifikation für die Aktivierung,Aufrechterhaltung und Deaktivierung der physischen Verbin-dung zwischen kommunizierenden Netzwerk-Systemen. DieSpezifikationen der physischen Schicht betreffen Eigenschaftenwie die Spannung, zeitliche Vorgaben für Spannungsänderun-gen, physische Übertragungsraten, die maximale Übertragungs-strecke und die Stecker und Buchsen. Die Implementationender physischen Schicht können unterteilt werden in LAN- oderWAN-Spezifikationen. Bild 1.7 zeigt einige der gängigstenLAN- und WAN-Implementationen der physischen Schicht.

Physikalische

Schicht

Eth

ern

et

IEE

E 8

02

.3

10

0B

ase

T

To

ken

Rin

g/

IEE

E 8

02

.5

FD

DI

EIA/TIA-232

EIA/TIA-449

V.24 V.35

HSSI G.703

EIA-530

X.21bis SIP

WANLAN

Implementation der physikalischen Schicht

OSI-Schicht

Sicherungs-

schicht

Bild 1.7:Implementa-tionen derphysischenSchicht könnenLAN- oderWAN-Spezifi-kationen sein


1.2.8 Die Verbindungsschicht des OSI-Modells

Die Verbindungsschicht sorgt für die zuverlässige Übertragungder Daten über eine physische Netzwerk-Verbindung. Die ver-schiedenen Spezifikationen der Verbindungsschicht definierenunterschiedliche Netzwerk- und Protokolleigenschaften, ein-schließlich der physischen Adressierung, Netzwerk-Topologie,Fehlererkennung, Frame-Abfolge und Flußsteuerung. Bei derphysischen Adressierung (im Gegensatz zur Netzwerk-Adres-sierung) wird definiert, wie Geräte auf Ebene der Verbin-dungsschicht adressiert werden. Die Netzwerk-Topologie wirdvon Spezifikationen der Verbindungsschicht bestimmt, diedefiniert, wie Geräte physisch miteinander verbunden werden,z.B. über einen Bus oder einen Ring. Die Fehlererkennungalarmiert die Protokolle der oberen Schichten, wenn ein Über-tragungsfehler auftritt, und die Sequenzierung der Daten-Frames sortiert Frames, falls diese nicht in der richtigenReihenfolge eingehen. Die Flußsteuerung schließlich regelt dieÜbertragung der Daten, so daß das empfangende Gerät nichtmit Daten überlastet wird.

Das Institute of Electrical and Electronics Engineers (IEEE)hat die Verbindungsschicht noch in zwei Subschichten aufge-teilt: die Logical Link Control (LLC – logische Verbindungs-steuerung) und die Media Access Control (MAC – Medium-Zugriffssteuerung). Bild 1.8 zeigt die IEEE-Subschichten derVerbindungsschicht.

LLC-

Subschicht

MAC-

Subschicht

Sicherungs-schicht

Die Subschicht Logical Link Control (LLC) verwaltet dieKommunikation zwischen Geräten eines Netzwerks, die übereine einzige Leitung läuft. LLC ist in der Spezifikation IEEE802.2 definiert und unterstützt sowohl die verbindungslosenals auch die verbindungsorientierten Dienste der Protokollehöherer Schichten. IEEE 802.2 definiert mehrere Felder inFrames der Verbindungsschicht, so daß es mehreren Protokol-

Bild 1.8:Die Verbin-

dungsschichtbesteht aus

zwei Sub-schichten


len der höheren Schichten möglich ist, eine einzige physischeDatenverbindung gemeinsam zu nutzen. Die Subschicht MediaAccess Control (MAC) verwaltet den Protokollzugriff auf dasphysische Netzwerk-Medium. Die IEEE MAC-Spezifikationdefiniert MAC-Adressen, anhand derer mehrere Geräte aufEbene der Verbindungsschicht eindeutig identifizierbar sind.

1.2.9 Die Vermittlungsschicht des OSI-Modells

Die Vermittlungsschicht bietet Routing- und ähnliche Funk-tionen, mit denen es möglich ist, mehrere Datenverbindungenin einem Internetwork zu kombinieren. Dies wird durch dielogische Adressierung der Geräte (im Gegensatz zur physi-schen Adressierung) erreicht. Die Vermittlungsschicht unter-stützt sowohl verbindungslose als auch verbindungsorientierteDienste der Protokolle höherer Schichten. Die Protokolle derVermittlungsschicht sind Routing-Protokolle; es werden aberauch andere Protokolle in dieser Schicht implementiert.

Einige der gängigsten Routing-Protokolle enthalten auch dasBorder Gateway Protocol (BGP), das ein Internet-Interdo-main-Routing-Protokoll ist; Open Shortest Path First (OSPF)ist ein verbindungsorientiertes inneres Gateway-Protokoll, dasfür den Einsatz in TCP/IP-Netzen entwickelt wurde; und dasRouting Information Protocol (RIP) ist ein Internet-Routing-Protokoll, das Sprungzähler (hop count) verwendet.

1.2.10 Die Transportschicht des OSI-Modells

Die Transportschicht implementiert Dienste für den zuverläs-sigen Datentransport im Internetwork, die für die höherenSchichten transparent sind. Zu den Funktionen der Transport-Schicht gehören die Flußsteuerung, das Multiplexing, die Ver-waltung der virtuellen Verbindungen und die Fehlerprüfungund -behebung.

Die Flußsteuerung verwaltet die Datenübertragung zwischenGeräten, so daß das sendende Gerät nicht mehr Daten über-mittelt als das empfangende Gerät verarbeiten kann. Mit demMultiplexing können mehrere Anwendungen ihre Daten übereine einzelne physische Verbindung übertragen. Virtuelle Ver-bindungen werden von der Transportschicht aufgebaut,aufrechterhalten und abgebaut. Zur Fehlerprüfung gehört das


Aufsetzen von Mechanismen zur Fehlererkennung in derDatenübertragung, während es Aufgabe der Fehlerbehebungist, daß fehlerhafte Daten ggf. erneut angefordert werden.

Manche Implementationen der Transportschicht umfassenauch das Transmission Control Protocol, Name Binding Pro-tocol und OSI-Transport-Protokolle. Das Transmission Con-trol Protocol (TCP) ist ein Protokoll der TCP/IP-Familie, diefür zuverlässige Datenübertragung sorgt. Das Name BindingProtocol (NBP) ist ein Protokoll, das AppleTalk-Namen mitAdressen verknüpft. OSI-Transport-Protokolle gehören zu ei-ner Familie von Transport-Protokollen aus der OSI-Protokoll-Familie.

1.2.11 Die Kommunikationsschicht des OSI-Modells

Diese baut Sitzungen zwischen Einheiten der Darstellungs-schicht Kommunikationsverbindungen auf, verwaltet und be-endet diese. Kommunikationsverbindungen bestehen ausDienstanforderungen und Dienstantworten, die zwischen An-wendungen in verschiedenen Netzwerk-Geräten ausgetauschtwerden. Diese Anforderungen und Antworten werden vonProtokollen koordiniert, die in der Kommunikationsschichtimplementiert sind. Einige Implementationen der Kommuni-kationsschicht enthalten das Zone Information Protocol (ZIP),das AppleTalk-Protokoll, das den Name-Binding-Prozeßkoordiniert, und das Session Control Protocol (SCP), das Ver-mittlungsschicht-Protokoll der DECnet Phase IV.

1.2.12 Die Darstellungsschicht des OSI-Modells

Die Darstellungsschicht bietet eine Vielzahl von Kodier- undKonvertier-Funktionen, die auf Daten der Anwendungsschichtangewandt werden. Diese Funktionen stellen sicher, daß dieDaten, die von der Anwendungsschicht des einen Systems vonder Anwendungsschicht eines anderen Systems gelesen werdenkönnen. Zu den Kodier- und Konvertier-Verfahren der Dar-stellungsschicht gehören z.B. die gängigen Datendarstellungs-formate, die Konvertierung von Zeichendarstellungsformaten,gängige Datenkompressionsverfahren und übliche Datenver-schlüsselungen.


Übliche Datendarstellungsformate oder der Einsatz von stan-dardisierten Bild-, Klang- und Videoformaten ermöglichen denAustausch von Anwendungsdaten zwischen verschieden-artigen Computersystemen. Konvertierungsverfahren werdendazu verwendet, Daten zwischen Systemen auszutauschen, diemit unterschiedlichen Text- und Datendarstellungen arbeiten,z.B. mit EBCDIC und ASCII. Mit Standard-Datenkompressio-nen können Daten, die an der Quelle komprimiert wurden,problemlos vom Zielgerät dekomprimiert werden. Gleichesgilt für den Einsatz von Verschlüsselungen.

Die Implementationen der Darstellungsschicht sind normaler-weise nicht mit einem bestimmten Protokoll-Stack verbunden.Zu den weitverbreiteten Standards für Video gehören Quick-Time und Motion (MPEG). Bei QuickTime handelt es sich umeine Spezifikation für Video- und Audiodaten am Apple Com-puter, während MPEG ein Standard für die Komprimierungund Kodierung von Videodaten ist.

Zu den bekanntesten Grafikformaten zählen Graphics In-terchange Format (GIF), Joint Photographic Experts Group(JPEG) und Tagged Image File Format (TIFF). GIF und JPEGsind ein Standard für die Komprimierung und Kodierung vonGrafikdaten, TIFF ist ein Standard-Kodierformat für Grafik-daten.

1.2.13 Die Anwendungsschicht des OSI-Modells

Die Anwendungsschicht des OSI-Modells ist dem Benutzer amnähesten, d.h., daß die Anwendungsschicht und der Benutzerdirekt mit der Software interagieren.

Diese Schicht interagiert mit Software-Anwendungen, die einekommunizierende Komponente implementieren. Solche An-wendungen gehören nicht mehr in den Rahmen des OSI-Mo-dells. Zu den Funktionen der Anwendungsschicht gehören dieIdentifizierung des Kommunikationspartners, das Ermittelnder Ressourcen-Verfügbarkeit und die Synchronisierung derKommunikation.

Beim Identifizieren der Kommunikationspartner ermittelt dieAnwendungsschicht für die Anwendung, die Daten übertragenwill, die Identität und Verfügbarkeit des Kommunikations-partners. Bei der Ermittlung der Ressourcen-Verfügbarkeit


muß die Anwendungsschicht entscheiden, ob ausreichendeNetzwerk-Ressourcen für die angeforderte Kommunikationvorhanden sind. Von der Synchronisierung ist jegliche Kom-munikation zwischen Anwendungen betroffen, die von derAnwendungsschicht koordiniert werden muß.

Zwei Arten von Implementierungen der Anwendungsschichtsind TCP/IP-Anwendungen und OSI-Anwendungen. TCP/IP-Anwendungen sind Protokolle (z.B. Telnet, File Transfer Pro-tocol (FTP), Simple Mail Transfer Protocol (SMTP)), die zurInternet-Protokoll-Familie zählen. OSI-Anwendungen sindProtokolle (z.B. File Transfer, Access und Management(FTAM), Virtual Terminal Protocol (VTP) und CommonManagement Information Protocol (CMIP)), die zur OSI-Familie zählen.

1.3 Datenformate

Die Daten und Steuerdaten, die in Internetworks übertragenwerden, können in den unterschiedlichsten Formaten vorlie-gen. Die Begriffe, mit denen diese Formate bezeichnet werden,sind nicht immer konsistent und können gegeneinander ausge-tauscht werden. Zu den gängigen Datenformaten gehörenFrame-, Paket-, Datagramm-, Segment-, Nachrichten-, Zell-und Dateneinheiten. Ein Frame ist eine Informationseinheit,deren Quelle und Ziel Entitäten der Verbindungsschicht sind.Ein Frame setzt sich aus dem Header der Verbindungsschicht(und ggf. einem Trailer) und den Daten der höheren Schichtzusammen. Header und Trailer enthalten Steuerdaten, die fürdie Verbindungsschicht des Zielsystems bestimmt sind. DieDaten der höheren Schicht werden vom Header und Trailerder Verbindungsschicht gekapselt. Bild 1.9 zeigt die grundle-genden Komponenten eines Frame der Verbindungsschicht.

LLC

Sublayer

Frame

Header der

Sicherungsschicht

Daten der

höheren Schicht

Trailer der

Sicherungsschicht

Bild 1.9:Die Daten der

höherenSchichten bil-

den den Frameder Verbin-

dungsschicht


Ein Paket ist eine Informationseinheit, deren Quelle und Zieldie Vermittlungsschicht ist. Ein Paket setzt sich aus dem Hea-der der Vermittlungsschicht (und ggf. einem Trailer) und denDaten der höheren Schicht zusammen. Header und Trailerenthalten Steuerdaten, die für die Vermittlungsschicht desZielsystems bestimmt sind. Die Daten der höheren Schichtensind vom Header und Trailer der Vermittlungsschicht gekap-selt. Bild 1.10 zeigt die grundlegenden Komponenten einesPakets der Vermittlungsschicht.

LLC

Sublayer

MAC

Sublayer

Paket

Header der

Netzwerkschicht

Daten der

höheren Schicht

Trailer der

Netzwerkschicht

Der Begriff Segment wird normalerweise auf Informationsein-heiten bezogen, deren Quelle und Ziel Entitäten der Trans-portschicht sind.

Eine Nachricht ist eine Informationseinheit, deren Quelle undZiel Entitäten sind, die oberhalb der Vermittlungsschicht lie-gen (oft die Anwendungsschicht).

Eine Zelle ist eine Informationseinheit mit fester Größe, derenQuelle und Ziel die Verbindungsschicht ist. Zellen werden invermittelten Umgebungen verwendet, z.B. in Netzen mitAsynchronous Transfer Mode (ATM) und Switched Multime-gabit Data Service (SDMS). Eine Zelle besteht aus einem Hea-der und den Nutzdaten. Der Header enthält Steuerdaten, diefür die Verbindungsschicht des Zielsystems bestimmt sind; derHeader ist 5 Byte lang. Zu den Nutzdaten gehören die Datender höheren Schicht (48 Byte), die vom Zell-Header gekapseltwerden.

Die Länge des Header- und Nutzdatenfelds ist für alle Zellenimmer gleich. Bild 1.11 zeigt die Komponenten einer typischenZelle.

Bild 1.10:Drei grundle-gende Kompo-nenten bildenein Paket derVermittlungs-schicht


Zelle

53 Byte

Zellen-Header(5 Byte)

Nutzdaten(48 Byte)

Dateneinheit ist ein Oberbegriff, der eine Vielzahl von Infor-mationseinheiten umfaßt. Zu den gängigen Dateneinheitengehören Service Data Units (SDUs), Protocol Data Units undBridge Protocol Data Units (BPDU). SDUs sind Informations-einheiten der Protokolle höherer Schichten, mit denen Dienst-anforderungen an die niedrigeren Schichten gestellt werden.PDU ist der OSI-Begriff für ein Paket. BPDUs werden vomSpanning-Tree-Algorithmus als Hallo-Nachricht verwendet.

1.4 Die ISO-Hierarchie von Netzwerken

Große Netzwerke sind normalerweise hierarchisch organisiert.Ein solcher Aufbau bietet verschiedene Vorteile: beim Mana-gement, der Flexibilität und der Reduzierung überflüssigenDatenverkehrs. Deshalb hat die International Organization forStandardization (ISO) eine Vielzahl terminologischer Konven-tionen für die adressierenden Einrichtungen eines Netzwerksangepaßt. Schlüsselwörter in diesem Abschnitt sind End-System (ES), intermediäres System (IS), Bereich und autono-mes System (AS).

Ein ES ist ein Netzwerk-Gerät, das keinerlei Routing- oderWeiterleitungsfunktion ausführt. Zu den ES gehören z.B.Terminals, Personal Computer und Drucker. Ein IS ist einNetzwerk-Gerät, das Routing- oder Weiterleitungsfunktionenausführt. Zu den IS gehören z.B. Router, Switches undBridges. IS-Netzwerke können in zwei Arten unterteiltwerden: Intradomain-IS und Interdomain-IS. Ein Intradomain-IS kommuniziert innerhalb eines einzigen autonomen Systems,während ein Interdomain-IS innerhalb und zwischenautonomen Systemen kommuniziert. Ein Bereich ist einelogische Gruppe von Netzwerk-Segmenten und den daranangeschlossenen Geräten. Bereiche sind unterteilt in autonomeSysteme. Ein AS sind mehrere Netzwerke, die gemeinsam

Bild 1.11:Eine typischeZelle besteht

aus zwei Kom-ponenten


administriert werden und eine gemeinsame Routing-Strategiehaben. Autonome Systeme lassen sich in Bereiche unterteilen,wobei ein AS manchmal als eine Domain bezeichnet wird. Bild1.12 zeigt ein hierarchisches Netzwerk mit seinen Kompo-nenten.

Autonomes System

Bereich

Bereich

Bereich

IS

IS

IS

ES

1.5 Verbindungsorientierte undverbindungslose Netzwerk-Dienste

Allgemein kann festgestellt werden, daß es sich bei Netzwerk-Protokollen und dem von ihnen unterstützten Datenverkehrentweder um verbindungsorientierte oder verbindungslosehandelt. Verbindungsorientierte Verfahren verwenden einenbestimmten Pfad (Leitungsweg), der für die Dauer einer (logi-schen) Verbindung besteht. Verbindungslose Verfahren über-tragen die Daten über eine fest aufgebaute (logische) Verbin-dung.

Verbindungsorientierte Dienste durchlaufen drei Phasen:Verbindungsaufbau, Datenübertragung und Verbindungs-beendigung.

In der Phase des Verbindungsaufbaus wird ein bestimmterPfad zwischen Ziel- und Quellsystem festgelegt. Netzwerk-Ressourcen werden zu diesem Zeitpunkt reserviert, um einen

Bild 1.12:Ein hierarchi-sches Netzwerkbesteht aus ei-ner Vielzahlvon Kompo-nenten


konsistenten Dienst sicherzustellen, z.B. eine garantierteDurchsatzrate.

In der Phase der Datenübertragung werden die Daten sequen-tiell über den aufgebauten Pfad übertragen. Die Daten errei-chen das Zielsystem in genau der Reihenfolge, in der sie ge-sendet wurden.

In der Phase der Verbindungsbeendigung wird die aufgebauteVerbindung, die nicht länger benötigt wird, abgebaut. Sollenzwischen Quell- und Zielsystem weitere Daten übertragenwerden, muß eine neue Verbindung aufgebaut werden.

Verbindungsorientierte Netzwerk-Dienste haben zwei be-trächtliche Nachteile gegenüber den verbindungslosen: denstatischen Pfad und die statische Reservierung von Netzwerk-Ressourcen. Beim statischen Pfad kann es zu Schwierigkeitenkommen, weil alle Daten über den gleichen, festen Pfad über-tragen werden müssen. Tritt irgendwo auf dieser Strecke einFehler auf, fällt die gesamte Verbindung aus. Die statische Re-servierung von Netzwerk-Ressourcen führt zu Schwierigkei-ten, da eine garantierte Übertragungsrate erforderlich ist, sodaß andere Netzwerk-Nutzer diese Ressource nicht mitbenut-zen können. Nur wenn die Verbindung unterbrechungsfreiDaten überträgt, wird die Bandbreite voll genutzt, ansonstenist die Effizienz gering.

Für Anwendungen, bei denen in der Datenübertragung eineVerzögerung oder Paketneuordnung nicht in Frage kommt, istder verbindungsorientierte Dienst das einzig sinnvolle Ver-fahren. Dazu gehören z.B. Anwendungen, die Sprach- undVideo-Daten übertragen.

Ein Nachteil des verbindungslosen Netzwerk-Dienstes ist, daßkein Pfad von der Quelle zum Ziel festgelegt wird, keinePaketreihenfolge, keine Übertragungsrate und andere Netz-werk-Ressourcen garantiert sind. Jedes Paket muß vollständigadressiert sein, da für jedes Paket ein anderer Pfad durch dasNetzwerk gewählt werden kann, abhängig von verschiedenenFaktoren. Jedes Paket wird vom Quellsystem einzeln gesendetund wird von den zwischengeschalteten Netzwerk-Gerätenunabhängig von allen anderen Paketen behandelt.


Der verbindungslose Dienst bietet jedoch zwei deutliche Vor-teile gegenüber dem verbindungsorientierten Dienst: dynami-sche Pfadwahl und dynamische Bandbreitenzuordnung. Mitder dynamischen Pfadwahl kann der Datenverkehr um ausge-fallene Netzwerk-Ressourcen herum geleitet werden, da derPfad für jedes Paket einzeln neu festgelegt wird. Bei derdynamischen Bandbreitenzuordnung kann die Bandbreite ins-gesamt effizienter genutzt werden, weil diese nicht unnötigbelegt wird.

Für Anwendungen, die gegenüber Übertragungsverzögerungenund Paketneuordnung tolerant sind, ist der verbindungsloseDienst geeignet. Dazu gehören z.B. datenbasierte Anwen-dungen.

1.6 Adressierung im Internetwork

Adressen in einem Internetwork kennzeichnen ein einzelnesGerät oder ein Gerät als ein Mitglied einer Gruppe. DieAdressierungsverfahren sind abhängig von der Protokollfami-lie und der OSI-Schicht. Die folgenden drei Adreßarten wer-den am häufigsten verwendet: Adressen der Verbindungs-schicht, Medium-Zugriffssteuerung-(MAC-)Adressen undAdressen der Vermittlungsschicht.

1.6.1 Verbindungsschicht

Die Adresse der Verbindungsschicht kennzeichnet jede physi-sche Netzwerkverbindung von Netzwerk-Geräten eindeutig.Diese Adressen werden manchmal auch als physische oderHardware-Adressen bezeichnet. Die Adressen der Verbin-dungsschicht liegen in einem ebenen Adreßraum und stehen invordefinierter und fester Beziehung zu einem bestimmtenGerät.

Endsysteme sind im allgemeinen mit nur einer physischenVerbindung an das Netzwerk angeschlossen, weshalb sie nureine Verbindungsschichtadresse benötigen. Router und andereInternetworking-Geräte verfügen normalerweise über mehrerephysische Netzwerk-Verbindungen und haben deshalb auchmehrere Verbindungsadressen. Bild 1.13 zeigt, wie jedeSchnittstelle eines Geräts anhand der Verbindungsschicht-adresse eindeutig identifiziert ist.


Netzwerk

Netzwerk

NetzwerkA

BC

A

A B

C D

A

Schnittstelle

Schnittstellen

End-System

1 Schnittstelle 1 Addresse der Sicherungsschicht

Router

4 Schnittstellen

4 Sicherungsschicht- schnittstellen

D

1.6.2 MAC-Adressen

Eine Media Access Control-Adresse (MAC – Medium-Zu-griffssteuerung) bildet einen Teil der Verbindungsschicht-adresse. MAC-Adressen kennzeichnen eine Netzwerk-Entitätin einem LAN, das die IEEE-MAC-Adressen der Verbindungs-schicht implementiert. Wie die meisten Adressen der Verbin-dungsschicht sind auch die MAC-Adressen für jede LAN-Schnittstelle eindeutig. Bild 1.14 zeigt den Zusammenhangzwischen MAC-Adresse, Verbindungsschichtadresse undIEEE-Subschichten der Verbindungsschicht.

LLC-Subschicht

Sicherungsschicht-Adressen

MAC-Adressen

MAC-Subschicht

MAC-Adressen sind 48 Bit lang und werden als zwölf hexa-dezimale Ziffern geschrieben. Die ersten sechs hexadezimalenZiffern, die vom IEEE festgelegt sind, kennzeichnen den Her-steller. Dabei handelt es sich um den Organizational UniqueIdentifier (OUI). Die letzten sechs hexadezimalen Ziffern

Bild 1.13:Jede Schnitt-

stelle einesGeräts ist

anhand derVerbindungs-

schichtadresseeindeutig

gekennzeichnet

Bild 1.14:Beziehung

zwischenMAC-Adresse,

Verbindungs-schichtadresse

und den IEEE-Subschichten

der Verbin-dungsschicht


geben die Seriennummer der Schnittstelle an oder einen ande-ren Wert, den der Hersteller festlegt. MAC-Adressen werdenauch als Burned-in Adresses (BIAs – eingebrannte Adressen)bezeichnet, da sie in das ROM gebrannt sind. Beim Initiali-sieren der Schnittstellenkarte wird die Adresse ausgelesen undins RAM kopiert. Bild 1.15 stellt das MAC-Adressenformatdar.

MAC-Adresse

24 Bit 24 Bit

OUIvom Hersteller

vergeben

Die verschiedenen Protokollfamilien verwenden unterschied-liche Verfahren, um die MAC-Adresse eines Geräts zu ermit-teln. Die folgenden drei Verfahren werden am häufigsten ein-gesetzt: Das Address Resolution Protocol (ARP – Adreßauflö-sungsprotokoll) bildet Netzwerk-Adressen auf MAC-Adressenab. Das Hello-Protokoll ermöglicht es Netzwerk-Geräten, dieMAC-Adressen anderer Netzwerk-Geräte zu ermitteln. MAC-Adressen sind entweder in die Adresse der Vermittlungsschichteingebettet oder werden von einem Algorithmus generiert.

Bei der Adreßauflösung wird die Netzwerk-Adresse auf dieMAC-Adresse abgebildet. Dazu wird das Address ResolutionProtocoll (ARP) verwendet, das in vielen Protokollfamilienimplementiert ist. Nachdem eine Netzwerk-Adresse erfolgreicheiner MAC-Adresse zugeordnet werden konnte, speichert dasNetzwerk-Gerät diese Information im ARP-Cache. Mit diesemARP-Cache wird unnötiger ARP-Datenverkehr vermieden, dadas sendende Gerät die MAC-Adresse bereits kennt und nichterst ermitteln muß.

Wie die Adreßauflösung genau erfolgt, hängt von der jeweili-gen Netzwerkumgebung ab. In einem einzelnen LAN beginntdie Adreßauflösung damit, daß ein End-System A eine ARP-

Bild 1.15:Die MAC-Adresse ist eineeindeutigeAdresse aushexadezimalenZiffern


Anforderung an alle Geräte im LAN sendet (Broadcast), umdie MAC-Adresse des Geräts B zu ermitteln. Die so gesendeteAnforderung wird von allen Geräten im LAN empfangen undverarbeitet, wenngleich nur das End-System B die ARP-Anfor-derung beantwortet, indem es eine ARP-Antwort an das End-System A sendet, die seine MAC-Adresse enthält. End-SystemA empfängt diese Antwort und speichert die MAC-Adressedes Systems B in seinem ARP-Cache (der ARP-Cache ist eineTabelle, in der die Netzwerk-Adressen den MAC-Adressen zu-geordnet werden). Jedesmal, wenn nun das End-System A mitdem End-System B kommunizieren soll, prüft es den ARP-Cache, findet darin die MAC-Adresse des Systems B und sen-det einen Frame, ohne zuvor eine ARP-Anforderung im LANabsetzen zu müssen.

Etwas anders läuft die Adreßauflösung ab, wenn Quell- undZielgerät in verschiedenen LANs eingebunden sind, die übereinen Router miteinander in Verbindung stehen. End-System Ysendet eine ARP-Anforderung ins LAN (Broadcast), um dieMAC-Adresse des End-Systems Z zu ermitteln. Die so gesen-dete Anforderung wird von allen Geräten des LAN einschließ-lich des Routers X empfangen und verarbeitet. Dabei fungiertder Router X als Stellvertreter (Proxy) für das End-System Z.Der Router durchsucht seine Routing-Tabelle, um festzustel-len, ob sich End-System Z in einem anderen LAN befindet. Ersendet dann eine ARP-Antwort an das End-System Y, die stattder MAC-Adresse des End-Systems Z seine MAC-Adresseenthält. End-System Y empfängt diese Antwort und trägt dieMAC-Adresse des Routers X als MAC-Adresse des End-Systems Z ein. Wenn End-System Y mit dem End-System Zkommunizieren soll, prüft es seinen ARP-Cache und findetdort für das End-System Z die MAC-Adresse des Routers X,so daß es ohne weitere ARP-Anforderung einen Frame sofortsenden kann. Der Router X empfängt die für End-System Zbestimmten Daten und leitet sie zum anderen LAN weiter.

Mit dem Hello-Protokoll (einem Protokoll der Vermittlungs-schicht) können sich Netzwerk-Geräte gegenseitig identifi-zieren und feststellen, ob der Partner noch in Betrieb ist. BeimEinschalten eines Geräts sendet dieses Hello-Nachrichten analle Geräte im Netzwerk (Broadcast). Die Netzwerk-Geräte


senden eine Hello-Antwort zurück. In bestimmten zeitlichenAbständen sendet jedes Gerät Hello-Nachrichten, um bekanntzu geben, daß es noch in Betrieb ist. Dabei können die Netz-werk-Geräte die MAC-Adressen anhand der Hello-Protokoll-Pakete ermitteln.

Von drei Protokollen werden berechenbare MAC-Adressenverwendet. In diesen Protokollfamilien sind die MAC-Adres-sen berechenbar, weil die Vermittlungsschicht entweder dieMAC-Adresse einbettet oder einen Algorithmus zur Bestim-mung verwendet. Diese drei Protokolle sind: Xerox NetworkSystems (XNS), Novell Internetwork Packet Exchange (IPX)und DECnet Phase IV.

1.6.3 Adressen der Vermittlungsschicht

Mit einer Adresse der Vermittlungsschicht wird eine Entität indieser Schicht des OSI-Referenzmodells identifiziert. Vermitt-lungsschichtadressen liegen in einem hierarchischen Adreß-raum und werden auch als virtuelle oder logische Adressenbezeichnet.

Die Beziehung zwischen einem Netzwerk-Gerät und einerNetzwerk-Adresse ist eine logische und keine feste. DieseAdresse basiert entweder auf den physischen Netzwerkeigen-schaften (das Gerät ist an ein bestimmtes Segment angeschlos-sen) oder auf Gruppierungen, die ohne physische Grundlagesind (das Gerät ist Teil einer AppleTalk-Zone). Die End-Systeme benötigen für jedes von ihnen unterstützte Protokollder Vermittlungsschicht eine eigene Adresse (wobei davon aus-gegangen wird, daß jedes Gerät nur über eine physische Ver-bindung zum Netzwerk verfügt). Router und andere Internet-working-Geräte benötigen für jede physische Netzwerkver-bindung eine Vermittlungsschichtadresse. Ein Router, der z.B.mit drei Schnittstellen ausgestattet ist, die jede mit AppleTalk,TCP/IP und OSI betrieben wird, muß für jede Schnittstelle dreiVermittlungsschichtadressen aufweisen. Daraus ergibt sich,daß dieser Router über neun Vermittlungsschichtadressen ver-fügt. Bild 1.16 illustriert, wie jeder Netzwerk-Schnittstelle eineVermittlungsschichtadresse für jedes unterstützte Protokollzugewiesen wird.


OSI-

Adresse

AppleTalk-

Adresse

End-System

Router

Eine physische Verbindung

MultipleNetwork Layer Addresses

Mehrerephysische Verbindungen

TCP/IP-

Adresse

OSI

IP

AT

OSI

IP

AT

OSI

IP

AT

AT

OSI

IP

AT

OSI

IP

AT

OSI

IP

AT

OSI

IP

1.6.4 Hierarchischer oder ebener Adreßraum

Der Internetworking-Adreßraum ist in einer der beiden fol-genden Formen abgebildet: hierarchisch oder eben.

Ein hierarchischer Adreßraum ist unterteilt in zahlreiche Un-tergruppen, mit denen die Adresse immer weiter angenähertwird, bis sie auf ein einziges Gerät weist (ähnlich einer An-schrift). Ein ebener Adreßraum besteht aus nur einer einzigenGruppe (ähnlich der Sozialversicherungnummer in den USA).

Die hierarchische Adressierung bietet gewisse Vorteile gegen-über dem ebenen Adreßschema. So kann die Adressensortie-rung und -wiederholung relativ einfach durch Vergleichsope-rationen erreicht werden. In Irland z.B. ist jede Straße eindeu-tig gekennzeichnet und kann in keinem anderen Land liegen.Bild 1.17 zeigt die Unterschiede zwischen hierarchischem undebenem Adreßraum.

Bild 1.16:Jeder Netz-

werk-Schnitt-stelle muß für

jedes unter-stützte Proto-koll eine Ver-

mittlungs-schichtadresse

zugewiesensein


Hierarchischer Adreßraum

Ebener Adreßraum

A F

E

DC

B

A

A.B

A.A

A.C

A.A.C.a

A.A.C.b A.A.C.c

A.A.A

A.A.B

1.6.5 Adreßzuordnung

Adressen können Geräten auf drei verschiedene Weisen zuge-ordnet werden: statisch, dynamisch oder als Server-Adresse.Statische Adressen werden von einem Netzwerk-Administra-tor nach einem vorgefertigten Adressierungsplan vergeben.Eine statische Adresse ändert sich nicht, es sei denn, derNetzwerk-Administrator nimmt eine manuelle Änderung vor.Dynamische Adressen werden Geräten anhand protokollspe-zifischer Verfahren zugeordnet, wenn sie an das Netzwerk an-geschlossen werden. Ein Gerät, das über eine dynamischeAdresse angesprochen wird, erhält meistens bei jeder neuenAnbindung an das Netzwerk (z.B. beim Einschalten) eine an-dere Adresse. Die Adreßzuordnung durch einen Server erfolgt,wenn ein Gerät an das Netzwerk angeschlossen wird. VomServer zugeordnete Adressen werden für andere Geräte weiterverwendet, wenn das Gerät die Verbindung zum Netzwerk be-endet. So kann ein Gerät bei jedem Anschluß an das Netzwerkeine andere Adresse erhalten.

1.6.6 Adressen oder Namen

An Internetworking-Geräte werden normalerweise sowohlAdressen als auch Namen vergeben. Der Name ist dabei mei-stens ortsunabhängig und bleibt dem Gerät auch bei einem

Bild 1.17:Unterschiedezwischen hier-archischemund ebenemAdreßraumzeigen sich beiVergleichsope-rationen


Standortwechsel zugeordnet. Hingegen sind die Internetwor-king-Adressen ortsgebunden; sie ändern sich, wenn ein Gerät»umgezogen« ist (wobei natürlich die MAC-Adresse eineAusnahme von dieser Regel bildet). Namen und Adressen stel-len logische Kennzeichnungen dar, die von einem Systemad-ministrator oder einer Organisation, z.B. der Internet AssignedNumbers Authority (IANA), vergeben werden.

1.7 Grundlagen der Flußsteuerung

Die Flußsteuerung ist eine Funktion, die dem Datenstau imNetzwerk vorbeugt, indem sie sicherstellt, daß ein sendendesGerät nicht mehr Daten übermittelt als das empfangende Ge-rät annehmen bzw. verarbeiten kann. Es gibt unzählige Ursa-chen für einen Datenstau. Wenn z.B. ein schneller Computermehr Daten auf das Netzwerk überträgt als dieses überhauptvermitteln kann, oder das empfangende Gerät mit diesem Da-tenschwall überschüttet wird, den es gar nicht abarbeitenkann. Drei Verfahren stehen zur Verfügung, um dem Daten-stau vorzubeugen: Pufferung, Drosselung der Datenquelle undWindowing.

Gepuffert wird von Netzwerk-Geräten, um Daten mit beson-ders hoher Übertragungsrate zwischenzuspeichern, bis dieseverarbeitet werden können. Gelegentlich hohe Übertragungs-raten können durch die Pufferung problemlos abgefangenwerden. Dauert dieser Zustand aber zu lange an, wird derSpeicher zu stark beansprucht, und alle weiterhin eingehendenDatagramme werden abgewiesen.

Nachrichten zur Drosselung der Datenquelle werden vomempfangenden Gerät gesendet, damit dessen Puffer nichtüberlaufen. Das empfangende Gerät sendet eine Drosselungs-nachricht an das sendende Gerät, damit dieses seine Übertra-gungsrate reduziert. Zuerst verweigert das empfangende Gerätweitere Daten, wenn die Puffer überlaufen. Dann sendet es andas sendende Gerät für jedes verweigerte Paket eine Drosse-lungsnachricht. Das sendende Gerät reduziert daraufhinschrittweise die Übertragungsrate, bis es keine Drosselungs-nachrichten mehr erhält. Schließlich steigert das sendende Ge-rät wieder nach und nach die Übertragungsrate, bis wiederDrosselungsnachrichten eingehen.


Windowing ist ein Verfahren zur Flußsteuerung, bei dem dasQuellgerät vom Zielgerät nach einer bestimmten Anzahl ge-sendeter Pakete eine Quittung anfordert. Bei einer Window-Größe von 3 fordert das Quellgerät eine Quittung an, nach-dem es drei Pakete gesendet hat. Zuerst sendet das Quellgerätdrei Pakete an das Zielgerät. Nach Eingang der drei Paketesendet das Zielgerät eine Quittung an das Quellgerät. Wenndas Quellgerät die Quittung empfängt, sendet es weitere dreiPakete. Erreichen das Zielgerät aus irgendeinem Grund nichtalle drei Pakete (z.B. Pufferüberlauf), sendet es keine Quit-tung. Vom Quellgerät werden dann die letzten drei Pakete miteiner niedrigeren Übertragungsrate erneut gesendet.

1.8 Grundlagen der Fehlerprüfung

Die Verfahren der Fehlerprüfung ermitteln, ob die Daten wäh-rend der Übertragung zerstört wurden. Die Fehlerprüfung istin vielen OSI-Schichten implementiert.

Eine der üblichen Fehlerprüfungen ist der Cyclic RedundancyCheck (CRC), der zerstörte Daten erkennt und ausscheidet.Funktionen zur Fehlerbehebung (z.B. wiederholte Übertra-gung) bleiben Protokollen der höheren Schichten vorbehalten.Vom Quellgerät wird ein CRC-Wert aus den zu übertragendenDaten berechnet. Das Zielgerät berechnet auf die gleicheWeise einen solchen Wert und vergleicht ihn mit den übertra-genen, um festzustellen, ob während der Übertragung einFehler auftrat. Sind die Werte gleich, wird das Paket als gültigbetrachtet. Sollten die Werte unterschiedlich sein, ist ein Fehlerwährend der Übertragung aufgetreten, und das Paket wirdausgeschieden.

1.9 Grundlagen des Multiplexing

Beim Multiplexing werden vom Quellgerät mehrere Datenka-näle auf einem Kanal oder auf einer physischen Leitung zu-sammen übertragen. Dieses Verfahren kann auf jeder Schichtdes OSI-Referenzmodells implementiert sein. Auf der Gegen-seite, beim Zielgerät, erfolgt das Demultiplexing, das dieDatenkanäle wieder separiert. Multiplexing findet z.B. statt,wenn Daten mehrerer Anwendungen auf ein einzelnes Daten-


paket der unteren Schichten multiplext wird. Bild 1.18 zeigtdieses Beispiel.

Quelle

Header der unteren Schicht

Anwendungsdaten

Anwendung

Kalkulation Text

Daten

Ein weiteres Beispiel für Multiplexing ist die Übertragung derDaten mehrerer Geräte über einen physischen Kanal (wobeiein als Multiplexer bezeichnetes Gerät zum Einsatz kommt).Bild 1.19 veranschaulicht dieses Beispiel.

Physischer Kanal

MultiplexerMultiplexer

Datenkanäle

A

B

C

Datenkanäle

A

B

C

Ein Multiplexer ist ein Gerät der physischen Schicht, das meh-rere Datenströme auf einem oder mehreren Ausgangskanälenam Quellgerät zusammenfaßt. Auf der Gegenseite multiplextein Multiplexer die Kanäle wieder und maximiert die Nutzungder Bandbreite des physischen Mediums, indem es für mehrereDatenquellen gleichzeitig zur Verfügung steht.

Es gibt verschiedene Multiplex-Verfahren: Zeitmultiplex(TDM – Time-Devision Multiplexing), asynchrones Zeitmul-tiplexing (ATDM – Asynchronous Time-Devision Multiple-xing), Frequenz-Multiplex (FDM – Frequency Multiplexing)und das statistische Multiplexing.

Beim TDM wird jedem Datenkanal anhand einer Zeitscheibedie Bandbreite zugeordnet, unabhängig davon, ob zu dieserZeit Daten zu übertragen sind oder nicht. Beim ATDM wirddie Bandbreite nach Bedarf über eine dynamische Zeitscheibezugewiesen. Beim FDM wird jedem Datenkanal in Abhängig-

Bild 1.18:Die Daten

mehrerer An-wendungen

können in einPaket der unte-

ren Schichtenmultiplext

werden

Bild 1.19:Die Daten

mehrerer Ge-räte können

auf einen phy-sischen Kanal

multiplextwerden


keit seiner Signalfrequenz die Bandbreite zugeordnet. Beimstatistischen Multiplexing wird die Bandbreite dynamisch je-dem Kanal zugeordnet, der Daten zu übertragen hat.

1.10 Organisationen für Standardisierung

Eine Vielzahl von Organisationen trägt zu Internetworking-Standards bei, indem sie Diskussionsforen anbieten, aus dieseninformellen Diskussionen formale Spezifikationen erstellenund für die Verbreitung dieser Spezifikationen sorgen, wenndiese zum Standard erklärt wurden.

Die meisten Standardisierungsorganisationen nutzen be-stimmte Vorgehensweisen, um einen formalen Standard zu er-stellen: Organisieren von Ideen, Diskussion der Umsetzung,Entwicklung eines Entwurfs, Abstimmung über den gesamtenStandard oder über Teile und schließlich die formelle Be-kanntgabe des vollständigen Standards.

Zu den bekanntesten Organisationen, die sich mit Internet-working-Standards befassen, zählen die folgenden:

− International Organization for Standardization (ISO) –ISO ist eine internationale Standardisierungsorganisation,die für einen weiten Bereich von Standards verantwortlichzeichnet, zu denen viele Standards gehören, die Netzwerkebetreffen. Am bekanntesten sind das OSI-Referenzmodellund die OSI-Protkollfamilie.

− American National Standards Institute (ANSI) – ANSI istein Mitglied der ISO und koordiniert freiwillige Gruppenin den USA. ANSI entwickelte das Fiber Distributed DataInterface (FDDI) und weitere Kommunikationsstandards.

− Electronic Industries Association (EIA) – EIA spezifiziertelektrische Übertragungsstandards, zu denen auch solcheaus dem Netzwerkbereich gehören. Von der EIA wurde dersehr häufig verwendete Standard EIA/TIA-232 (früher alsRS-232 bekannt) entwickelt.

− Institute of Electrical and Electronic Engineers (IEEE) –IEEE ist eine professionelle Organisation, die Netzwerk-Standards und weitere darüber hinaus definiert. Vom IEEE


wurden die sehr häufig eingesetzten LAN-Standards IEEE802.3 und IEEE 802.5 entwickelt.

− International Telecommunication Union Telecommunica-tion Standardization Sector (ITU-T) – Früher trug dieseOrganisation die Bezeichnung Committee for InternationalTelegraph and Telephone (CCITT). ITU-T ist heute eine in-ternationale Organisation, die Kommunikationsstandardsentwickelt. Unter anderem wurde von der ITU-T das X.25-Protokoll entwickelt.

− Internet Activities Board (IAB) – IAB ist eine Gruppe vonInternetworking-Forschern, die neue Aspekte zum Internetdiskutieren und Internet-Regeln verabschieden und Ar-beitsgruppen einsetzen. Einige Dokumente mit dem StatusRequest For Comments (RFC) wurden vom IAB als Inter-net-Standards herausgegeben, wozu auch das TransmissionControl Protocol/Internet Protocol (TCP/IP) und dasSimple Network Management Protocol (SNMP) gehören.

2 Einführung in die LAN-Protokolle

In diesem Kapitel werden die verschiedenen Medium-Zugriffs-methoden, Übertragungsmethoden, Topologien und Gerätevorgestellt, die in einem lokalen Netz (LAN – Local AreaNetwork) zum Einsatz kommen. Dabei wird der Schwerpunktauf Verfahren und Geräte gelegt, wie sie in Netzwerken mitEthernet/IEEE 802.3, Token Ring/IEEE 802.5 und FiberDistributed Data Interface (FDDI) vorkommen. Die Kapitel inTeil 2, »LAN-Protokolle«, gehen näher auf andere Protokolleein. Bild 2.1 stellt das grundlegende Layout der drei genanntenProtokolle dar.

FDDI

Token Ring/IEEE 802.5

Ethernet/IEEE 802.3100BaseT

KAPITEL 2Einführung in die LAN-Protokolle

Bild 2.1:Diese dreiLAN-Imple-mentationensind amhäufigsten imEinsatz


2.1 Was ist ein LAN?

Ein LAN ist ein räumlich kleines Netzwerk, in dem Daten mithoher Geschwindigkeit und fehlertolerant übertragen werden.Es verbindet zumeist Workstations, Personalcomputer, Druk-ker und weitere Geräte. LANs bieten ihren Anwendern vieleVorteile, u.a. den gemeinsamen Zugriff auf Geräte und An-wendungen, die Möglichkeit des Datenaustauschs zwischenAnwendern und die Kommunikation per elektronischer Post(E-Mail) oder anderen Anwendungen.

2.2 LAN-Protokolle und dasOSI-Referenzmodell

Die Funktion der LAN-Protokolle ist auf die untersten zweiSchichten des OSI-Referenzmodells (siehe Kapitel 1, »Grund-lagen des Internetworking«) beschränkt: auf die physischeSchicht und die Verbindungsschicht. Bild 2.2 veranschaulichtden Zusammenhang zwischen den gängigsten LAN-Protokol-len und dem OSI-Referenzmodell.

Eth

ern

et

IEE

E 8

02

.3

To

ken

Rin

g/I

EE

E 8

02

.5

FD

DI

LAN-SpezifikationOSI-Schichten

LLC-Subschicht IEEE 802.2

MAC-Subschicht

PhysikalischeSchicht

10

0B

ase

T

Sicherungs-schicht

Bild 2.2:Die gängigsten

LAN-Proto-kolle und das

OSI-Referenz-modell

Kapitel 2 • Einführung in die LAN-Protokolle 61

2.3 Medium-Zugriffsmethoden im LAN

Die LAN-Protokolle verwenden eine der beiden folgendenMethoden, um auf das physische Netzwerk-Medium zuzugrei-fen: Carrier Sense Multiple Access Collision Detect(CSMA/CD) und Token Passing.

Beim Medium-Zugriff per CSMA/CD »streiten« die Netz-werk-Geräte um den Zugriff auf das physische Netzwerk-Medium. CSMA/CD wird deshalb auch als Contention Accessbezeichnet. LANs, die den Medium-Zugriff per CSMA/CDregeln, sind z.B. Ethernet/IEEE-802.3-Netze, einschließlich100BaseT.

Beim Medium-Zugriff nach dem Token-Passing-Verfahrengreifen Netzwerk-Geräte auf das physische Medium zu, wennsie ein Token erhalten. Netze, die den Medium-Zugriff perToken-Passing regeln, sind z.B. Token Ring/IEEE 802.5 undFiber Distributed Data Interface (FDDI).

2.4 Übertragungsverfahren im LAN

Die Übertragung von Daten in einem LAN kann in drei Grup-pen unterteilt werden: an einzelne Stationen (Unicast), an eineGruppe von Stationen (Multicast) und an alle Stationen(Broadcast). Dabei wird immer nur ein Paket übertragen.

Bei der Unicast-Übertragung wird ein einzelnes Paket von ei-ner Quelle zu einem Ziel im Netzwerk gesendet. Zuerst ver-sieht der Quellknoten das Paket mit der Adresse des Zielkno-tens. Das Paket wird dann in das Netzwerk übertragen.Schließlich befördert das Netzwerk das Paket zum Ziel.

Bei der Multicast-Übertragung werden Kopien eines einzelnenPakets an eine bestimmte Gruppe von Knoten im Netzwerkgesendet. Zuerst versieht der Quellknoten das Paket mit derMulticast-Adresse für die Gruppe. Das Paket wird dann in dasNetzwerk übertragen, das eine entsprechende Anzahl Kopienanlegt und diese zu den entsprechenden Knoten im Netzwerkbefördert.


Bei der Broadcast-Übertragung wird ein einzelnes Datenpaketan alle Knoten im Netzwerk gesendet. In diesem Fall versiehtder Quellknoten das Paket mit der Broadcast-Adresse. DasPaket wird dann in das Netzwerk übertragen, das so vieleKopien des Pakets anlegt wie Knoten im Netzwerk vorhandensind, und überträgt diese an alle Knoten im Netzwerk.

2.5 LAN-Topologien

Die LAN-Topologie definiert die Weise, wie Netzwerk-Gerätemiteinander verbunden werden. Es gibt vier gängige LAN-Topologien: den Bus, den Ring, den Stern und den Baum.Dabei handelt es sich um logische Architekturen. Die Gerätemüssen physisch nicht so angeordnet sein. Die logischen Topo-logien Bus und Ring z.B. sind physisch meistens in Sternformrealisiert. Die Bus-Topologie ist eine lineare LAN-Architektur,in der sich die gesendeten Daten jeder Netzwerkstation überdas gesamte Medium ausbreiten und von allen Stationenempfangen werden. Von den am häufigsten eingesetzten LAN-Implementationen werden Ethernet/IEEE 802.3, einschließlich100BaseT, in Bus-Topologie realisiert, wie in Bild 2.3 darge-stellt.

Die Ring-Topologie ist eine LAN-Architektur mit mehrerenGeräten, die untereinander durch uni-direktionale Verbindun-gen einen geschlossenen Kreis bilden. Sowohl Token Ring/IEEE-802.5- als auch FDDI-Netzwerke implementieren dieseRing-Topologie. Bild 2.4 zeigt eine logische Ring-Topologie.

Bild 2.3:BestimmteNetzwerke

implementierendie lokale Bus-

Topologie


Die Stern-Topologie ist eine LAN-Architektur, in der die End-punkte eines Netzwerks über einen normalen zentralen Huboder Switch per dedizierten Verbindungen zusammenhängen.Die logischen Topologien Bus und Ring sind oft physisch alsStern-Topologien implementiert. Bild 2.5 veranschaulicht dies.

Hub

Die Baum-Topologie ist eine LAN-Architektur, die der Bus-Topologie entspricht, außer daß Abzweigungen mit mehrerenKnoten möglich sind. Bild 2.6 zeigt eine logische Baum-Topo-logie.

Bild 2.4:Andere Netz-werke imple-mentieren einelogische Ring-Topologie

Bild 2.5:Stern-Topologie


2.6 LAN-Geräte

Zu den in einem LAN eingesetzten Geräten gehören: Repeater,Hubs, LAN-Extender, Bridges, LAN-Switches und Router.

Auf Repeater, Hubs und LAN-Extender wird in diesem Ab-schnitt nur kurz eingegangen. Die Funktion und der Betriebvon Bridges, Switches und Router werden im Kapitel 4,»Grundlagen des Bridging und Switching«, und im Kapitel5, »Grundlagen des Routing«, erläutert.

Ein Repeater ist ein Gerät der physischen Schicht, das Me-dium-Segmente eines erweiterten Netzwerks miteinander ver-bindet. Die Hauptfunktion eines Repeater liegt darin, daßmehrere Kabelsegmente wie ein einzelnes Kabel gehandhabtwerden können. Repeater empfangen Signale von einemNetzwerk-Segment und senden sie verstärkt in ein anderesNetzwerk-Segment. Dieses Verfahren verhindert, daß sich dieSignale aufgrund der Kabellänge und der vielen angeschlosse-nen Geräte zu sehr verschlechtern. Repeater können keinekomplexe Filterung und andere Verarbeitung des Datenver-kehrs vornehmen. Es werden alle elektrischen Signale wieder-holt und verstärkt, auch elektrische Störungen und andereFehler. Wie viele Repeater eingesetzt und Netzwerk-Segmenteso verbunden werden können, hängt z.B. vom Zeitverhaltenab. Bild 2.7 zeigt einen Repeater, der zwei Netzwerk-Segmentemiteinander verbindet.

Bild 2.6:Eine logische

Baum-Topolo-gie kann meh-

rere Knotenenthalten


Repeater

Ein Hub ist ein Gerät der physischen Schicht, das mehrere Be-nutzerstationen miteinander verbindet, und zwar jede über einbestimmtes Kabel. Die elektrischen Verbindungen werden imHub hergestellt. Mit Hubs werden physische Stern-Netzwerkerealisiert, während es sich logisch um eine Bus- oder Ring-Konfiguration des LAN handelt. Unter bestimmten Bedin-gungen funktioniert ein Hub wie ein Multiport-Repeater.

Ein LAN Extender ist ein Remote-Access Multilayer Switch,der eine Verbindung zu einem Host-Router hat. LAN Exten-der leiten den Datenverkehr aller Standard-Protokolle derVermittlungsschicht weiter (z.B. von IP, IPX und AppleTalk)und können Datenverkehr anhand der MAC-Adresse oder desProtokolltyps filtern. LAN Extender arbeiten sehr effektiv, dader Host-Router alle unnötigen Broadcasts und Multicastsherausfiltert. Mit LAN Extendern kann der Datenverkehr al-lerdings nicht segmentiert werden, sie haben auch keine Fire-wall-Funktion. Bild 2.8 zeigt mehrere LAN Extender, die überein WAN mit einem Host-Router verbunden sind.

WAN LAN-

Extender

Bild 2.7:Ein Repeaterverbindet zweiNetzwerk-Segmente

Bild 2.8:Mehrere LANExtender kön-nen über einWAN miteinem Host-Router ver-bunden sein

3 Einführung in die WAN-Technologien

In diesem Kapitel werden die verschiedenen Protokolle undTechnologien vorgestellt, die in Weitverkehrsnetzen (WAN –Wide Area Network) eingesetzt werden. Zu den angespro-chenen Themen gehören Punkt-zu-Punkt-Verbindungen, Lei-tungsvermittlung, Paket-Switching, virtuelle Verbindungen,Einwahldienste und WAN-Geräte. Die Kapitel in Teil 3,»WAN-Technologien«, behandeln die einzelnen Technologienausführlich.

3.1 Was ist ein WAN?

Ein WAN ist ein Datenkommunikationsnetzwerk, das sichüber relativ große räumliche Entfernungen erstreckt und indem Übertragungseinrichtungen der gängigen Anbieter (z.B.Telefongesellschaften) benutzt werden. Die Funktion derWAN-Technologien ist auf die drei unteren Schichten des OSI-Referenzmodells beschränkt: auf die physische Schicht, dieVerbindungsschicht und die Vermittlungsschicht. Bild 3.1 zeigtden Zusammenhang zwischen den üblichen WAN-Technolo-gien und dem OSI-Referenzmodell.

KAPITEL 3Einführung in die WAN-Technologien


OSI-Schichten

MAC-Subschicht

WAN-Spezifikationen

SD

LC

LA

PB

X.2

5 P

LP

X.2

1b

is

PP

P

HD

LC

Fra

me

Re

lay

PhysikalischeSchicht

Netzwerk-schicht

EIA/TIA-232EIA/TIA-449V.24 V.35

HSSI G.703EIA-530

SM

DS

Sicherungsschicht

3.2 Punkt-zu-Punkt-Verbindungen

Eine Punkt-zu-Punkt-Verbindung stellt einen einzelnen, vorbe-reiteten WAN-Kommunikationspfad dar, der vom kundenei-genen Gerät über das Anbieternetzwerk (z.B. einer Telefon-gesellschaft) bis zum fernen Netzwerk reicht. Punkt-zu-Punkt-Verbindungen werden auch als »geleaste Leitungen« bezeich-net, da der eingerichtete Pfad über das Anbieternetzwerk zujedem fernen Netzwerk permanent und festgelegt ist. DerDienstanbieter reserviert eine Punkt-zu-Punkt-Verbindung fürdie private Nutzung durch den Kunden. Diese Verbindungeneignen sich für zwei Arten der Datenübertragung: für Data-gramme, die sich aus einzeln adressierten Frames zusammen-setzen, und für Datenströme, bei denen eine Adreßüberprü-fung nur einmal stattfindet. Bild 3.2 zeigt eine typische Punkt-zu-Punkt-Verbindung über ein WAN.

Bild 3.1:Die WAN-

Technologienarbeiten auf

den unterstenSchichten des

OSI-Referenz-modells

Kapitel 3 • Einführung in die WAN-Technologien 69

WAN

3.3 Leitungsvermittlung

Die Leitungsvermittlung ist ein WAN-Vermittlungsverfahren,bei dem eine dedizierte physische Verbindung für jede Kom-munikationssitzung über das Anbieternetzwerk aufgebaut,aufrechterhalten und beendet wird. Die Leitungsvermittlungeignet sich für zwei Arten der Datenübertragung: für Da-tagramme, die sich aus einzeln adressierten Frames zusam-mensetzen, und für Datenströme, bei denen eine Adreßüber-prüfung nur einmal stattfindet. Dieses Vermittlungsverfahrenwird besonders häufig von Telefongesellschaften genutzt, da esdem normalen Telefonieren sehr ähnlich ist. So ist z.B. ISDNeine leitungsvermittelte WAN-Technologie, wie in Bild 3.3dargestellt.

WAN

Anbieter-netzwerk

Switch

Kunden-seite

DCE DCE

DCE

Bild 3.2:Eine typischePunkt-zu-Punkt-Verbin-dung verläuftüber ein WANzu einem fer-nen Netzwerk

Bild 3.3:Ein leitungs-vermitteltesWAN funk-tioniert soähnlich wieein normalerTelefonanruf


3.4 Paketvermittlung

Die Paketvermittlung ist eine WAN-Switching-Methode, beider mehrere Netzwerk-Geräte eine einzige Punkt-zu-Punkt-Verbindung gemeinsam nutzen, um Pakete über ein Anbieter-netzwerk von der Quelle zum Ziel zu übertragen. Um die ge-meinsame Nutzung einer solchen Verbindung zu ermöglichen,wird das statistische Multiplexing verwendet. Zu den paket-vermittelten WAN-Technologien gehören die Protokolle Asyn-chronous Transfer Mode (ATM), Frame Relay, Switched Mul-timegabit Data Service (SMDS) und X.25 (siehe Bild 3.4).

WAN

Anbieter-netzwerk

Kunden-seite

Switch

Multiplexing

Demultiplexing

DCE DCE

3.5 Virtuelle Verbindungen im WAN

Eine virtuelle Verbindung ist eine logische Verbindung, die zursicheren Kommunikation zwischen zwei Netzwerk-Gerätenaufgebaut wird. Es gibt zwei Arten der virtuellen Verbindung:die gewählte virtuelle Verbindung (GVV – Switched VirtualCircuit [SVC]) und die feste virtuelle Verbindung (FVV – Per-manent Virtual Circuit [PVC]).

Bei SVC handelt es sich um dynamische, bei Bedarf aufzu-bauende Verbindungen, die nach Beendigung der Übertragungabgebaut werden. Die Kommunikation über einen SVCdurchläuft drei Zustände: Leitungsaufbau, Datenübertragungund Leitungsabbau. Zum Leitungsaufbau gehört, daß eine vir-tuelle Verbindung zwischen Quell- und Zielgerät hergestelltwird. Während der Datenübertragung tauschen die Geräte dieDaten über die virtuelle Verbindung aus. Beim Leitungsabbauwird die virtuelle Verbindung zwischen Quell- und Zielgerät

Bild 3.4:Bei der Paket-

vermittlungwerden die

Pakete über ein Anbieter-

netzwerkübertragen


beendet. SVCs werden oft dort eingesetzt, wo die Datenüber-tragung nur gelegentlich stattfindet, da von SVCs beim Ver-bindungsauf- und -abbau eine große Bandbreite beanspruchtwird, jedoch die Kosten – bei immer verfügbarer virtuellerVerbindung – gering sind.

Ein PVC ist eine ständig aufgebaute virtuelle Verbindung, dienur einen Zustand kennt: die Datenübertragung. PVCs kom-men immer dann zum Einsatz, wenn zwischen Geräten ständigDaten ausgetauscht werden. Da bei PVCs der Verbindungsauf-und -abbau wegfällt, benötigen diese Verbindungen eine ge-ringere Bandbreite, führen aber zu höheren Verbindungsko-sten, da die Leitung ständig geschaltet ist.

3.6 WAN-Einwahldienste

Einwahldienste stellen eine kostengünstige Variante der Ver-bindung über ein WAN dar. Die zwei bekanntesten Einwahl-implementationen sind Dial-on-Demand Routing (DDR) undDial Backup.

DDR ist eine Technik, bei der ein Router leitungsvermittelteSitzungen auf Anforderung von End-Stationen starten und be-enden kann. Der Router wird dazu so konfiguriert, daß er denentsprechenden Datenverkehr (z.B. eines bestimmten Proto-kolls) erkennen kann. Wenn der Router den entsprechendenDatenverkehr empfängt, der zu einem fernen Netzwerk über-tragen werden soll, baut der Router eine Verbindung auf undüberträgt die Daten über diese Verbindung. Parallel läuft einTimer, der immer wieder von neuem beginnt, wenn Datenüber diese Verbindung übertragen werden. Empfängt der Rou-ter keine zu übertragenden Daten, bevor der Timer abläuft,wird die Verbindung beendet. Falls wieder Daten zum fernenNetzwerk übertragen werden sollen, baut der Router eineneue Verbindung auf. DDR kann anstelle von Punkt-zu-Punkt-Verbindungen und vermittelten Mehrfachzugriffs-WAN-Diensten eingesetzt werden.

Dial Backup ist ein Dienst, der unter bestimmten Bedingungeneine serielle Sicherungsleitung aktiviert. Eine sekundäre serielleLeitung kann als Sicherungsverbindung fungieren, die genutztwird, wenn die primäre Verbindung ausfällt oder wenn zu-sätzliche Bandbreite erforderlich wird, weil die Last auf der


primären Leitung einen Grenzwert erreicht. Dial Backup bieteteine gewisse Vorsorge gegen Performance-Verluste im WANund Ausfallzeiten.

3.7 WAN-Geräte

In einem WAN kommen eine Vielzahl verschiedener Gerätezum Einsatz, die typisch für eine WAN-Umgebung sind. Imfolgenden Abschnitt werden diese Geräte vorgestellt, zu denenWAN-Switches, Zugriffs-Server, Modems, CSU/DSUs undISDN-Terminaladapter gehören. Andere Geräte sind spezielleWAN-Geräte wie Router, ATM-Switches und Multiplexer.

3.7.1 WAN-Switch

Ein WAN-Switch ist ein Internetworking-Gerät mit mehrerenPorts, das in Anbieternetzen zum Einsatz kommt. Von diesenGeräten wird zumeist Datenverkehr der Protokolle FrameRelay, X.25 und SMDS vermittelt. Diese Geräte gehören zurVerbindungsschicht des OSI-Referenzmodells. Bild 3.5 zeigtzwei Router an den Enden eines WAN, die über WAN-Swit-ches miteinander verbunden sind.

WAN-Switch

3.7.2 Zugriffsserver

Ein Zugriffsserver fungiert als Konzentrator für sich ein- undauswählende Verbindungen. Bild 3.6 zeigt einen Zugriffsser-ver, der aus einem WAN sich auswählende Verbindungen kon-zentriert.

Bild 3.5:Zwei Router

an den fernenEnden eines

WAN könnenüber WAN-

Switches mit-einander ver-

bunden werden


Zugriffs-server

WAN

3.7.3 Modem

Ein Modem ist ein Gerät, das digitale und analoge Signale in-terpretiert und so Daten über normale Telefonleitungen sen-den kann. Auf der ausgehenden Seite werden die digitalenSignale so konvertiert, daß sie über analoge Kommunikations-einrichtungen übertragen werden können. Am Ziel, auf dereingehenden Seite, werden die analogen Signale wieder in digi-tale umgewandelt. Bild 3.7 zeigt eine einfache Verbindungzweier Modems über ein WAN.

ModemModem

3.7.4 CSU/DSU

Eine Channel Service Unit/Data Service Unit (CSU/DSU – Ka-nal- und Datendiensteinheit) ist ein Gerät mit einer digitalenSchnittstelle (das manchmal aus zwei einzelnen digitalen Gerä-ten besteht), über das die physische Schnittstelle eines DTE-Geräts (z.B. eines Terminals) an die Schnittstelle eines DCE-Geräts (z.B. eines Switches), das zum vermittelten Anbieter-Netz gehört, angeschlossen wird. Die CSU/DSU bietet für dieKommunikation zwischen diesen Geräten auch das Signal-Timing. Bild 3.8 zeigt, wo sich die CSU/DSU in einer WAN-Implementation befindet.

Bild 3.6:Ein Zugriffs-server konzen-triert aus einemWAN sichauswählendeVerbindungen

Bild 3.7:Bei einerModem-Ver-bindung überein WAN wer-den analogeund digitaleSignale ver-arbeitet


CSU/DSU SwitchSwitch

3.7.5 ISDN-Terminal-Adapter

Der ISDN-Terminal-Adapter ist ein Gerät, mit dem an einenISDN-Basisanschluß (BRI) weitere Geräte z.B. über die Schnitt-stelle EIA/TIA-232 angeschlossen werden können. Im Grundehandelt es sich beim Terminal-Adapter um ein ISDN-Modem.Bild 3.9 zeigt, wo sich ein Terminal-Adapter in einer ISDN-Umgebung befindet.

ISDN-Terminal-

Adapter SwitchSwitch

Bild 3.8:Die CSU/DSU

befindet sichzwischen

Switch undTerminal

Bild 3.9:Über denTerminal-

Adapter kön-nen weitere

Geräte an dasISDN

angeschlossenwerden

4 Grundlagen des Bridging und Switching

In diesem Kapitel werden die Technologien vorgestellt, die mitden als Bridges und Switches bezeichneten Geräten in Zu-sammenhang stehen. Zu den behandelten Themen gehörengrundlegende Funktionen der Verbindungsschicht, das lokaleund das ferne Bridging, ATM-Switching und LAN-Switching.Die Kapitel des Teils 4, »Bridging und Switching«, behandelnbestimmte Technologien ausführlich.

4.1 Was sind Bridges und Switches?

Bridges und Switches sind Datenkommunikationsgeräte, die inder Schicht 2 des OSI-Referenzmodells eingesetzt werden.Deshalb werden sie oft auch als Verbindungsschichtgerätebezeichnet.

Bridges konnte man erstmals Anfang der 80er Jahre käuflicherwerben. Zu dieser Zeit dienten Bridges dazu, Pakete zwi-schen homogenen Netzen weiterzuleiten und diese so mitein-ander zu verbinden. In jüngerer Zeit wurde auch das Bridgingzwischen unterschiedlichen Netzwerken definiert und stan-dardisiert.

Viele verschiedene Arten des Bridging haben sich als wichtigeInternetworking-Geräte bewährt. Transparentes Bridging fin-det man eher in Ethernet-Umgebungen, während Source-Route-Bridging in Token-Ring-Umgebungen beheimatet ist.

Übersetzendes Bridging bietet die Umformung von Formatenund Übertragungsprinzipien verschiedener Medien (normaler-weise zwischen Ethernet und Token Ring). Das transparente

KAPITEL 4Grundlagen des Bridging und Switching


Source-Route-Bridging kombiniert die Algorithmen des trans-parenten Bridging und Source-Route-Bridging, um die Kom-munikation in gemischten Ethernet/Token-Ring-Umgebungenzu ermöglichen.

Heute hat sich die Switchting-Technologie zu einem evolutio-nären Erbe für Bridging-basierte Internetworking-Lösungenentwickelt. Switching-Implementationen dominieren Anwen-dungen, in denen Bridging-Technologien bei früherem Netz-werk-Design vorgesehen waren. Die erstklassige Performance,größere Port-Dichte, niedrigere Kosten je Port und die höhereFlexibilität haben dazu beigetragen, daß Switches die Briding-Technologie ersetzen und ein Komplement zur Routing-Tech-nologie bilden.

4.2 Überblick zu den Geräten derVerbindungsschicht

Bridging und Switching erfolgt auf Ebene der Verbindungs-schicht, die den Datenfluß steuert, Übertragungsfehler bear-beitet, physische (im Gegensatz zur logischen) Adressierungbietet und den Zugriff auf das physische Medium verwaltet.Beim Einsatz von Bridges kamen dafür verschiedene Verbin-dungsschichtprotokolle zum Einsatz, die eine bestimmte Fluß-kontrolle, Fehlerbehandlung, Adressierung und Medium-zugriff-Algorithmen vorschrieben. Zu den bekannten Proto-kollen der Verbindungsschicht gehören das Ethernet, TokenRing und FDDI.

Bridges und Switches sind keine komplizierten Geräte. Sieanalysieren eingehende Frames, entscheiden über die Weiterlei-tung anhand der in den Frames enthaltenen Informationenund übertragen die Frames zum Zielgerät. In bestimmten Fäl-len, z.B. beim Source-Route-Bridging, ist der gesamte Pfadzum Ziel im Frame enthalten. Beim transparenten Bridgingz.B. werden die Frames immer nur schrittweise zum Ziel wei-tergeleitet.

Der zuerst zu nennende Vorteil, den Bridging und Switchingbieten, ist die Transparenz für höhere Schichten. Da beide Ge-rätetypen auf der Ebene der Verbindungsschicht arbeiten,benötigen sie keine Informationen der höheren Schichten.D.h., daß von ihnen der Datenverkehr jedes beliebigen Ver-

Kapitel 4 • Grundlagen des Bridging und Switching 77

mittlungsschichtprotokolls zügig weitergeleitet wird. Für eineBridge ist es nicht ungewöhnlich, daß sie Datenverkehr derProtokolle AppleTalk, DECnet, TCP/IP, XNS usw. zwischenzwei oder mehr Netzwerken transportiert.

Bridges sind in der Lage, Frames anhand der Schicht-2-Felderzu filtern. So kann eine Bridge so programmiert werden, daßsie alle Frames eines bestimmten Netzwerks ablehnt (undnicht weiterleitet). Da die Informationen der Verbindungs-schicht oft auch auf Protokolle höherer Schichten bezugneh-men, können Bridges auch anhand dieser Parameter filtern.Gerade bei der Behandlung unerwünschter Broadcast- undMulticast-Pakete ist diese Funktion hilfreich.

Auch bei der Unterteilung großer Netzwerke in selbständigeEinheiten bieten Bridges und Switches verschiedene Vorteile.Weil nur ein bestimmter Prozentsatz des Datenverkehrs wei-tergeleitet wird, reduzieren Bridges und Switches das Ver-kehrsaufkommen in allen angeschlossenen Segmenten auf einMinimum. Bei einigen Netzwerkfehlern können Bridges undSwitches als Firewall dienen. Mit Bridges und Switches kön-nen wesentlich mehr Geräte verbunden werden, als dies beimAnschluß eines LAN an eine Bridge möglich ist. Bridges undSwitches erweitern die effektive Länge eines LAN, indem wei-ter entfernte Stationen angeschlossen werden können.

Zwar haben Bridges und Switches viele Eigenschaften gemein-sam, es gibt jedoch auch entscheidende Unterschiede. So sindSwitches wesentlich schneller, weil die Vermittlung auf derHardware geschieht, während Bridges dazu Software verwen-den. Switches sind in der Lage, LANs mit unterschiedlicherBandbreite zu verbinden. So können z.B. ein 10-Mbit/s-Ether-net-LAN und ein 100-Mbit/s-Ethernet-LAN über einen Switchmiteinander verbunden werden. Von Switches wird eine hö-here Port-Dichte unterstützt als von Bridges. Einige Switchesunterstützen das Cut-Through-Switching, was die Latenz undVerzögerungen in einem Netzwerk reduziert, während vonBridges nur ein Switching nach dem Speicher-und-Weiterleiten(Store and Forward) funktioniert. Schließlich helfen Switchesauch bei der Vermeidung von Kollisionen in Netzwerk-Seg-menten, da sie jedem Netzwerk-Segment eine bestimmte Band-breite zuordnen.


4.3 Bridge-Typen

Bridges lassen sich in anhand verschiedener Eigenschaftenkategorisieren. Eine der gängigsten Klassifikationen teiltBridges in lokale oder ferne (remote) Bridges ein. LokaleBridges verbinden mehrere, räumlich nahe LAN-Segmente.Remote Bridges verbinden mehrere, räumlich weit vonein-ander entfernte LAN-Segmente über Telefonleitungen. Bild 4.1zeigt diese beiden Konfigurationen.

TokenRing

Ethernet LokalesBridgingBridge

Bridge BridgeFernes Bridging

Remote Bridging sieht sich mehreren eindeutigen Internetwor-king-Anforderungen gegenüber, z.B. den unterschiedlichenÜbertragungsgeschwindigkeiten im LAN und WAN. Auchwenn sich zur Zeit einige schnelle WAN-Technologien inräumlich verteilten Internetworks etablieren, bleibt doch diebeträchtliche Differenz bei den Übertragungsgeschwindigkei-ten bestehen. Der große Unterschied der LAN- und WAN-Geschwindigkeiten hält die Benutzer davon ab, verzögerungs-empfindliche LAN-Anwendungen über ein WAN zu betreiben.

Remote Bridges können zwar die WAN-Geschwindigkeit nichterhöhen, jedoch die Geschwindigkeitsunterschiede wenigstensbei ausreichender Pufferung kompensieren. So muß z.B. einelokale Bridge den 3-Mbit/s-Datenstrom eines LAN-Geräts, dasmit einem Gerät in einem fernen LAN kommunizieren will, soregeln, daß die serielle 64-Kbit/s-Leitung nicht vollkommenüberlastet wird. Dazu puffert die Bridge die eingehendenDaten und sendet sie mit einer für die serielle Leitung verträg-lichen Geschwindigkeit. Diese Art der Pufferung funktioniertnur für kurzzeitig hohe Datenraten, die die Pufferkapazität derBridge nicht überschreiten.

Das Institute of Electrical and Electronic Engineers (IEEE)unterteilt die Verbindungsschicht des OSI-Referenzmodells in

Bild 4.1:Lokale und

ferne Bridgesverbinden

LAN-Segmentein unterschied-

licher räumli-cher Entfer-

nung


zwei einzelne Subschichten: die MAC-Subschicht (MediaAccess Control) und die LLC-Subschicht (Logical Link Con-trol). Die MAC-Subschicht erlaubt und organisiert denMediumzugriff, wie den Konkurrenzbetrieb und das Token-Passing, während die LLC-Subschicht das Framing, dieFlußsteuerung, die Fehlerbehandlung und die MAC-Sublayer-Adressierung verwaltet.

Einige Bridges sind MAC-Schicht-Bridges, die eine Verbindungzwischen homogenen Netzwerken (z.B. IEEE 802.3 und IEEE802.3) schaffen, andere Bridges können zwischen verschiede-nen Protokollen der Verbindungsschicht (z.B. IEEE 802.3 undIEE-802.5) übersetzen. Wie eine solche Übersetzung funktio-niert, veranschaulicht Bild 4.2.

Darstellung

Netzwerk

Transport

Sicherung

Physikalisch

Host A

Kommunikation

Anwendung

Darstellung

Netzwerk

Transport

Sicherung

Physikalisch

Host B

Kommunikation

Anwendung

802.3-Medium 802.5-Medium

802.3 802.5

802.5802.3

PKT

PKT PKT

PKT

PKTLLC

MACSicherung

Physikalisch

Bridge

In Bild 4.2 wird ein IEEE-802.3-Host (Host A) gezeigt, der einPaket mit Anwendungsdaten erstellt und es in einen IEEE-802.3-kompatiblen Frame kapselt, um es über ein IEEE-

Bild 4.2:Eine Bridge derMAC-Schichtverbindet einIEEE-802.3-und ein IEEE-802.5-Netz-werk


802.3-Medium zu einer Bridge zu übertragen. Die Bridgeentfernt den IEEE-802.3-Header auf Ebene der MAC-Sub-schicht und reicht den Frame zur Weiterverarbeitung an diedarüberliegende LLC-Subschicht. Danach wird das Paket andie IEEE-802.5-Implementation heruntergereicht, von der dasPaket mit einem IEEE-802.5-Header gekapselt wird, um esüber ein IEEE-802.5-Netzwerk zum IEEE-802.5-Host (HostB) zu übertragen.

Die Übersetzung zwischen Netzwerken verschiedener Artdurch eine Bridge kann nie vollständig geschehen, da einigeFrame-Felder und Protokoll-Funktionen des einen Netzwerksnicht vom anderen unterstützt werden.

4.4 Switch-Typen

Switches sind Geräte der Verbindungsschicht, die wie Bridgesmehrere physische LAN-Segmente zu einem großen Netzwerkverbinden. Ähnlich wie Bridges leiten Switches den Datenver-kehr anhand von MAC-Adressen weiter. Da aber das Swit-ching von der Hardware und nicht von einer Software ausge-führt wird, ist es bedeutend schneller. Switches setzen entwe-der die Technik des Zwischenspeicherns und Weiterleitens(store-and-forward) oder des Durchleitens (cut-through) ein.Switches gibt es in verschiedenen Ausführungen, als ATM-Switch, LAN-Switch und verschiedene WAN-Switches.

4.4.1 ATM-Switch

Ein ATM-Switch (Asynchronous Transfer Mode) bietet Hoch-geschwindigkeits-Switching und skalierbare Bandbreiten fürden Einsatz in Arbeitsgruppen, im unternehmensweiten Netz-werk-Backbone und in WANs. Von ATM-Switches werdenSprach-, Video- und Datenanwendungen unterstützt. DieseSwitches sind so ausgelegt, daß sie die bei der ATM-Kommu-nikation verwendeten Dateneinheiten fester Länge switchen,die als Zellen bezeichnet werden. Bild 4.3 zeigt ein Unterneh-mensnetzwerk, das aus mehreren LANs besteht, die über einenATM-Backbone miteinander verbunden sind.


ATM- Backbone

Entwicklung

Vertrieb Marketing

R&D

Sicherheit

4.4.2 LAN-Switch

LAN-Switches werden dazu eingesetzt, mehrere LAN-Seg-mente miteinander zu verbinden. Mit LAN-Switching werdendie Voraussetzungen für eine dedizierte, kollisionsfreie Kom-munikation zwischen Netzwerk-Geräten geschaffen, wobeimehrere Teilnehmer gleichzeitig aktiv sein können. LAN-Swit-ches sind so ausgelegt, daß sie Daten-Frames mit hoher Ge-schwindigkeit vermitteln können. Bild 4.4 zeigt ein einfachesNetzwerk, in dem ein LAN-Switch ein 10-Mbit/s- und ein100-Mbit/s-Ethernet-LAN verbindet.

LAN-Switch

10-MBit/s-Ethernet

100-MBit/s-Ethernet

Bild 4.3:Netzwerke ausmehrerenLANs könnenzum Vermittelnvon Zelleneinen ATM-basiertenBackboneverwenden

Bild 4.4:Ein LAN-Switch kannunterschiedlichschnelle Ether-net-Segmenteverbinden

5 Grundlagen des Routing

In diesem Kapitel werden die am häufigsten in Routing-Proto-kollen eingesetzten, grundlegenden Konzepte erläutert. Zu denbehandelten Themen gehören die Komponenten und Algo-rithmen der Routing-Protokolle. Außerdem wird kurz auf dieUnterschiede zwischen Routing-Protokollen und gerouteten,oder Netzwerk-, Protokollen eingegangen. Die Kapitel desTeils 6, »Routing-Protokolle«, behandeln bestimmte Routing-Protokolle ausführlich. Netzwerk-Protokolle, die Routing-Pro-tokolle verwenden, werden in Teil 5, »Netzwerk-Protokolle«besprochen.

5.1 Was ist Routing?

Routing ist der Vorgang, bei dem Daten über ein Internetworkvon einer Quelle zu einem Ziel übertragen werden. Auf diesemWeg befindet sich normalerweise mindestens ein dazwischengeschalteter Knoten. Routing wird oft dem Bridging gegen-übergestellt, was für den normalen Betrachter zunächst keinUnterschied ist. Der primäre Unterschied ist, daß Bridging inder Schicht 2 (der Verbindungsschicht) erfolgt, während Rou-ting in der Schicht 3 (der Vermittlungsschicht) stattfindet.Aufgrund dieses Unterschieds werden beim Routing undBridging verschiedene Daten für die Übertragung von derQuelle zum Ziel verwendet, so daß diese beiden Funktionenihre Aufgabe auf verschiedene Weise erfüllen.

KAPITEL 5Grundlagen des Routing


Das Thema Routing wurde zwar seit mehr als zwei Jahrzehn-ten in der wissenschaftlichen Computerliteratur behandelt,zum kommerziellen Einsatz kam das Routing aber erst Mitteder 80er Jahre. Der primäre Grund für diese Verzögerung istdarin zu sehen, daß die Netzwerke der 70er Jahre einfacheund homogene Umgebungen darstellten. Erst in jüngster Zeitwurde das Internetworking in großem Stil populär.

5.2 Komponenten des Routing

Zum Routing gehören zwei grundlegende Aktivitäten: dasErmitteln eines optimalen Routing-Pfads und die Übertragungvon Datengruppen (auch als Pakete bezeichnet) über einInternetwork. Dabei bezeichnet man letzteres als Switching.Selbst wenn das Switching relativ geradlinig zu sein scheint,kann die Pfadermittlung ein sehr komplexer Vorgang sein.

5.2.1 Pfadermittlung

Mit einem Meßparameter, z.B. der Pfadlänge, wird vom Rou-ting-Algorithmus der optimale Pfad zum Ziel ermittelt. Au-ßerdem werden von Routing-Algorithmen sog. Routing-Tabel-len angelegt und gepflegt, um den Prozeß der Pfadermittlungzu unterstützen. Die darin enthaltenen Route-Informationensind je nach Routing-Algorithmus verschieden.

Die Routing-Algorithmen füllen die Routing-Tabellen mit denverschiedensten Informationen. Die Kombinationen ausZiel/nächster Hop signalisieren dem Router, daß ein bestimm-tes Ziel am schnellsten erreicht wird, wenn das Paket zu einembestimmten Router gesendet wird, der den »nächsten Hop«auf dem Weg zum Ziel darstellt. Nachdem ein Router ein Pa-ket empfangen hat, prüft er die Zieladresse und versucht, dieseeinem nächsten Hop zuzuordnen. Bild 5.1 veranschaulichteine Routing-Tabelle, die nach dem Prinzip Ziel/nächster Hopaufgebaut ist.

Kapitel 5 • Grundlagen des Routing 85

Zielnetzwerk: Nächster Knoten:

27

57

17

24

52

16

26

.

.

.

Knoten A

Knoten B

Knoten C

Knoten A

Knoten B

Knoten A

Knoten A

.

.

.

Routing-Tabellen enthalten darüber hinaus Informationen,z.B. Daten über die Priorität eines Pfads. Router vergleichendie Meßparameter, um die optimalen Routen zu finden, wobeidiese Parameter in Abhängigkeit vom Routing-Algorithmusvariieren. Weiter unten in diesem Kapitel werden die verschie-denen, gebräuchlichen Meßparameter vorgestellt und be-schrieben.

Router kommunizieren miteinander und pflegen ihre Routing-Tabellen mit Hilfe einer Vielzahl von Nachrichten. Die Nach-richt Routing-Aktualisierung ist eine solche Nachricht, die diegesamte oder Teile der Routing-Tabelle enthält. Durch dieAnalyse der von anderen Routern gesendeten Routing-Aktua-lisierungen kann ein Router ein detailliertes Bild der Netz-werk-Topologie entwerfen. Ein weiteres Beispiel für Nachrich-ten, die zwischen Routern ausgetauscht werden, ist die Link-Status-Anzeige (Link-State Advertisement), die andere Routerüber den Status der Links des Senders informiert. Auch dieseLink-Informationen können dazu genutzt werden, ein voll-ständiges Bild der Netzwerk-Topologie zu entwerfen, um esden Routern zu ermöglichen, die optimalen Routen zum Netz-werk-Ziel zu ermitteln.

Bild 5.1:Die Kombi-nationen ausZiel/nächsterHop geben denoptimalen Pfadfür die Datenvor


5.2.2 Switching

Switching-Algorithmen sind relativ einfach aufgebaut und imPrinzip für die meisten Routing-Protokolle identisch. Meistensmuß ein Host ein Paket an einen anderen senden. Verfügt derQuell-Host über die Router-Adresse, sendet er das Paket di-rekt an die physische (MAC-)Adresse des Router und versiehtdas Paket mit der Protokolladresse (Vermittlungsschicht) desZiel-Hosts.

Der Router prüft die Ziel-Protokolladresse und stellt fest, obbekannt ist, wie das Paket weiter gesendet werden kann. Wennder Router nicht weiß, wie das Paket weiterzuleiten ist, wirddas Paket »fallengelassen«. Andernfalls ändert der Router diephysische Zieladresse auf die des nächsten Hop und sendetdas Paket.

Der nächste Hop kann tatsächlich der Ziel-Host sein. Ist diesnicht der Fall, handelt es sich beim nächsten Hop um einenweiteren Router, der den gleichen Switching-Entscheidungs-prozeß ausführt. Beim Weg des Pakets durch das Internetworkwird dessen physische Adresse mehrfach geändert, dieProtokolladresse jedoch bleibt gleich (siehe Bild 5.2).

Damit ist der Weg von einem Quell- zu einem Ziel-Endsystemper Switching beschrieben. Die International StandardizationOrganization (ISO) hat eine hierarchische Terminologie ent-wickelt, die zur Beschreibung dieses Prozesses hilfreich ist. Indieser Terminologie werden Netzwerk-Geräte, die keinePakete zwischen Sub-Netzwerken versenden können, als End-Systeme (ES) bezeichnet. Netzwerk-Geräte, die genau dieseFähigkeit aufweisen, werden als intermediäre Systeme (IS)bezeichnet. IS können unterteilt werden in Geräte, die inner-halb von Routing-Domänen kommunizieren können (intra-domäne IS), und solchen, die sowohl innerhalb als auch überihre Routing-Domäne hinaus kommunizieren können (inter-domäne IS). Eine Routing-Domäne ist ein Teil eines Internet-work, der normal administriert wird, aber bestimmten Admi-nistrationsregeln unterworfen ist. Routing-Domänen werdenauch als autonome Systeme bezeichnet. Mit Hilfe bestimmterProtokolle lassen sich Routing-Domänen in Routing-Bereicheunterteilen, wobei Intradomänen-Routing-Protokolle sowohl


für das Switching innerhalb als auch zwischen Bereichen ver-wendet wird.

Router 1

Router 2

Router 3

An: Ziel-HostRouter 1

(Protokoll-Adresse)(Physische Adresse)

PaketQuell-Host-

PC



Packet



Paket

An:

Ziel-HostZiel-Host


Ziel-Host-PC

Packet

5.3 Routing-Algorithmen

Routing-Algorithmen können anhand bestimmter Eigenschaf-ten unterschieden werden. Zuerst beeinflussen die Ziele des-jenigen, der den Algorithmus entworfen hat, die Funktion desdaraus entstandenen Routing-Protokolls. Zum zweiten steheneine Vielzahl von Routing-Algorithmen zur Verfügung, wovonjeder die Netzwerk- und Router-Ressourcen auf andere Weisebeeinflußt. Schließlich verwenden die Routing-Algorithmendie verschiedensten Meßparameter, die Einfluß auf die Berech-nung der optimalen Route haben. In den folgenden Abschnit-ten werden diese Eigenschaften der Routing-Algorithmenanalysiert.

Bild 5.2:Während desSwitching-Pro-zesses werdenmehrere Rou-ter angespro-chen


5.3.1 Entwicklungsziele

Routing-Algorithmen werden mit einem oder mehreren derfolgenden Ziele entwickelt:

− Optimierung

− Einfachheit und geringer Overhead

− Robustheit und Stabilität

− Schnelle Konvergenz

− Flexibilität

Optimierung bezieht sich auf die Eigenschaft des Routing-Algorithmus, die beste Route auszuwählen, was vom Meß-parameter und seinen Gewichtungen bei der Berechnungabhängt. So kann z.B. ein Algorithmus eine große Anzahl vonHops und Verzögerungen ermitteln, jedoch bei der Berech-nung der Route die Verzögerungen stärker berücksichtigen.Natürlich müssen die Routing-Protokolle die Berechnung inden Meßparametern der Algorithmen durchgängig definieren.

Routing-Algorithmen werden so einfach wie möglich entwor-fen. Das heißt, die Funktion des Algorithmus muß effektiverreicht werden, mit einem Minimum an Software- und Bedie-nungs-Overhead. Die Effektivität spielt eine besondere Rolle,wenn die Software, mit der der Routing-Algorithmus imple-mentiert wird, auf einem Computer mit beschränkten physi-schen Ressourcen läuft.

Bei der Robustheit eines Routing-Algorithmus kommt es dar-auf an, daß der Algorithmus auch in Ausnahmesituationenund unter unvorhersehbaren Bedingungen wie Hardware-Aus-fällen, Überlastung und Fehlimplementationen korrekt ab-läuft. Da Router an den Knotenpunkten von Netzwerken ein-gesetzt werden, kann deren Ausfall zu schwerwiegenden Pro-blemen führen. Die besten Routing-Algorithmen sind solche,die bereits länger im Einsatz sind und ihre Stabilität in einemNetzwerk unter den verschiedensten Bedingungen bewiesenhaben.

Ein Routing-Algorithmus muß schnell konvergieren können.Unter Konvergenz versteht man den Prozeß der Abstimmungaller Router zu einer optimalen Route. Bevor ein Router auf-


grund eines Ereignisses in einem Netzwerk heruntergefahrenwird oder nicht mehr verfügbar ist, sendet er Aktualisierungs-Nachrichten zum Routing, die nach und nach die Netzwerkeerreichen, so daß eine Neuberechnung der optimalen Routenerfolgt, der eventuell alle Router zustimmen. Zu langsam kon-vergierende Routing-Algorithmen können zu Routing-Schlei-fen und Netzwerk-Ausfällen führen.

In Bild 5.3 ist eine Routing-Schleife dargestellt: Zu einemZeitpunkt t1 geht ein Paket beim Router 1 ein. Router 1wurde bereits aktualisiert und hat erkannt, daß die optimaleRoute zum Ziel über Router 2 als nächstem Hop führt. Alsosendet Router 1 das Paket an Router 2 weiter. Da dieser Rou-ter jedoch noch nicht aktualisiert wurde, betrachtet er Rou-ter 1 als nächsten Hop auf dem optimalen Weg zum Ziel desPakets. Deshalb sendet Router 2 das Paket wieder an Rou-ter 1. Nun wird das Paket zwischen diesen beiden Routern hinund her geschickt, und zwar so lange, bis auch Router 2aktualisiert wurde oder das Paket die maximale Switch-Anzahl erreicht hat.

Router 2Router 1Paket anRouter X

t1

Routing-Tabelle

Ziel:

X

Senden an:

R2

Bereits aktualisiert

Routing-Tabelle

Ziel:

X

Senden an:

R1

Noch nicht aktualisiert

Routing-Algorithmen sollten auch flexibel sein, d.h., sie soll-ten sich schnell und genau an eine Vielzahl von Netzwerk-Um-ständen anpassen können. Wenn z.B. ein Netzwerk-Segmentausfällt und dies von den Routern bemerkt wird, wählen diemeisten Routing-Algorithmen den nächstbesten Pfad für alleRouter, die sonst dieses ausgefallene Segment benutzen. Rou-ting-Algorithmen können so programmiert werden, daß sieauf Änderungen in der Netzwerk-Bandbreite, den Umfang derRouter-Warteschlange und Netzwerk-Verzögerungen etc. rea-gieren.

Bild 5.3:LangsameKonvergenzund Routing-Schleifen kön-nen die Weiter-leitung behin-dern


5.3.2 Algorithmusarten

Routing-Algorithmen können im Hinblick auf die folgendenMerkmale klassifiziert werden:

− Statisch oder dynamisch

− Einzel-Pfad oder Multi-Pfad

− Eben oder hierarchisch

− Host-Intelligenz oder Router-Intelligenz

− Intradomän oder interdomän

− Link-Status oder Entfernungsvektor

Statisch oder dynamisch

Statische Routing-Algorithmen sind eigentlich keine Algo-rithmen, sondern genaugenommen tabellarische Zuordnun-gen, die ein Netzwerk-Administrator zu den Anfangszeiten desRouting eingerichtet hat. An diesen Zuordnungen ändert sichnichts, es sei denn, der Administrator nimmt eine Änderungvor. Algorithmen, die statische Router verwenden, sind einfachzu entwerfen und eignen sich gut für Umgebungen, in denender Datenverkehr im Netzwerk relativ vorhersehbar ist unddie Netzwerk-Struktur sich einfach gestaltet.

Da statische Routing-Systeme nicht auf Netzwerk-Verände-rungen reagieren können, sind sie im allgemeinen für heutige,große und sich ständig ändernde Netzwerke wenig geeignet.Die meisten der in den 90er Jahren vorherrschenden Algo-rithmen sind dynamische Routing-Algorithmen, die sich wech-selnden Netzwerk-Bedingungen anpassen, indem sie einge-hende Routing-Aktualisierungsnachrichten auswerten. Wenneine solche Nachricht eine Änderung am Netzwerk mitteilt,werden die Routen durch die Routing-Software erneut be-rechnet, und es werden neue Routing-Aktualisierungsnach-richten versendet. Diese Meldungen durchdringen nach undnach das gesamte Netzwerk, so daß alle Router dazu veran-laßt werden, ihre Algorithmen erneut zu starten und die Rou-ting-Tabellen entsprechend anzupassen.


Dynamische Routing-Algorithmen können dort, wo es geeig-net erscheint, mit statischen Routen versehen werden. DerRouter des letzten Auswegs (ein Router, an den alle nicht-rou-tingfähige Pakete gesendtet werden) z.B. kann als Aufbewah-rungsort für alle nicht-routingfähige Pakete eingerichtet wer-den, um sicherzustellen, daß alle Meldungen bearbeitet wer-den.

Einzel-Pfad oder Multi-Pfad

Einige ausgefeilte Routing-Protokolle unterstützen mehrerePfade zu ein und demselben Ziel. Anders als Einzel-Pfad-Algorithmen lassen diese Multi-Pfad-Algorithmen ein Multi-plexing über mehrere Leitungen zu. Die Vorteile der Multi-Pfad-Algorithmen liegen auf der Hand: Sie erreichen eindeutighöhere Durchsatzraten und sind zuverlässiger.

Eben oder hierarchisch

Einige Routing-Algorithmen arbeiten in einem ebenen Adreß-raum, während andere einen hierarchischen Adreßraum ver-wenden. In einem ebenen Routing-System sind alle Routergleichberechtigt. In einem hierarchischen Routing-System bil-den einige Router das, was man einen Routing-Backbonenennt. Dabei werden die Pakete von normalen Routern zu denBackbone-Routern gesendet, von wo aus sie über den Back-bone bis zum Zielbereich geschickt werden. Erst ab diesemPunkt werden die Pakete von einem Backbone-Router zu ei-nem oder mehreren normalen Routern bis zum Ziel gesendet.

In Routing-Systemen werden oft logische Gruppen von Kno-ten gebildet, die als Domänen, autonome Systeme oder Berei-che bezeichnet werden. In einem hierarchischen System kön-nen bestimmte Router einer Domäne mit Routern in anderenDomänen kommunizieren, während die anderen Router nurinnerhalb ihrer Domäne kommunizieren können. In sehr um-fangreichen Netzwerken können zusätzliche hierarchischeEbenen vorhanden sein, in denen die Router auf der höchstenHierarchie-Ebene den Routing-Backbone bilden.

Der primäre Vorteil des hierarchischen Routings liegt darin,daß dabei meistens die Organisationsstruktur einer Firmanachgebildet wird und damit deren Verkehrsaufkommen ambesten unterstützt wird. Der meiste Datenverkehr spielt sich


innerhalb kleiner Gruppen (Domänen) ab. Da interdomäneRouter nur die anderen Router der eigenen Domäne kennenmüssen, können deren Routing-Algorithmen vereinfacht wer-den. Abhängig vom verwendeten Routing-Algorithmus kanndamit der Anteil der Routing-Aktualisierungsnachrichten amDatenverkehr reduziert werden.

Host-Intelligenz oder Router-Intelligenz

Einige Routing-Algorithmen gehen davon aus, daß der Quell-Endknoten die gesamte Route festlegt. In diesem Fall sprichtman vom Quell-Routing. In Systemen mit Quell-Routingfungieren Router nur als Geräte, die zwischenspeichern undweiterleiten und Pakete einfach nur zum nächsten Router sen-den.

Andere Algorithmen arbeiten unter der Annahme, daß Hostsnichts von Routern wissen. In diesem Fall legen Router an-hand ihrer eigenen Berechnungen den gesamten Pfad eines Pa-kets durch das Netzwerk fest. Im erstgenannten System liegtdie Routing-Intelligenz bei den Hosts, im zweiten System beiden Routern.

Der wesentliche Unterschied zwischen Host-intelligentem undRouter-intelligentem Routing besteht in der Frage nach demoptimalen Pfad und nach dem Verkehrsaufkommen. Host-intelligente Systeme wählen öfter die bessere Route, da sie allemöglichen Routen zu einem Ziel ermitteln, bevor sie das Pakettatsächlich absenden. Dabei wählen sie den besten Pfad inAbhängigkeit davon, wie auf dem einzelnen System der»optimale« Pfad definiert ist. Allerdings fällt beim Ermittelnaller Routen eines Pakets ein nicht zu vernachlässigenderDatenverkehr an, abgesehen von der Zeit, die für dieses Unter-fangen benötigt wird.

Intradomän oder interdomän

Einige Routing-Algorithmen betrachten nur die eigene Do-mäne. Andere schauen über die eigene Domäne hinaus. DieNatur dieser beiden Algorithmentypen ist verschieden. Esleuchtet ein, daß ein optimaler intradomäner Routing-Algo-rithmus nicht unbedingt auch als interdomäner Algorithmusgeeignet ist.


Link-Status oder Distance-Vektor (Entfernungsvektor)

Link-Status-Algorithmen (auch bekannt als Algorithmen deskürzesten Pfads) reichen Routing-Informationen an alle Kno-ten des Internetwork. Dabei sendet jeder Router nur den Teilseiner Routing-Tabelle, die den Status seiner eigenen Links be-schreibt. Entfernungsvektor-Algorithmen (auch bekannt alsBellman-Ford-Algorithmen) fordern jeden Router auf, einenTeil oder seine gesamte Routing-Tabelle zu senden, und zwarnur an seine direkten Nachbarn. Kurz gesagt, senden Link-Status-Algorithmen kleine Aktualisierungen an alle, wohin-gegen Entfernungsvektor-Algorithmen umfangreichere Aktua-lisierungen nur an die benachbarten Router senden.

Weil sie schneller konvergieren, neigen Link-Status-Algorith-men weniger zu Routing-Schleifen als Entfernungsvektor-Algorithmen. Andererseits beanspruchen Link-Status-Algo-rithmen die CPU und den Arbeitsspeicher stärker, als dies beiEntfernungsvektor-Algorithmen der Fall ist. Deshalb könnenLink-Status-Algorithmen aufwendiger zu implementieren undzu warten sein. Abgesehen von den genannten Unterschiedenlaufen beide Algorithmen unter den meisten Umständen ein-wandfrei.

5.3.3 Routing-Meßparameter

Die Routing-Tabellen enthalten Informationen, die von derSwitching-Software verwendet werden, um die beste Route zuermitteln. Ausgefeilte Routing-Algorithmen können ihre Rou-ting-Auswahl nach mehreren Gesichtspunkten treffen, indemsie diese zu einem einzigen (hybriden) Meßparameter vereini-gen. Alle folgenden Parameter werden verwendet:

− Pfadlänge

− Zuverlässigkeit

− Verzögerung

− Bandbreite

− Auslastung

− Kommunikationskosten


Die Pfadlänge ist der gebräuchlichste Routing-Meßparameter.Einige Routing-Protokolle ermöglichen es den Netzwerk-Administratoren, jedem Netzwerk-Link willkürliche Kostenzuzuordnen. Dann errechnet sich die Pfadlänge als Summealler Kosten der verwendeten Links. Andere Routing-Proto-kolle definieren Hopcount (Sprungzähler), ein Meßparameter,der die Anzahl der passierten Internetworking-Produkte (z.B.Router) festlegt, die von einem Paket auf der Route zwischenQuelle und Ziel liegen müssen.

Von Zuverlässigkeit im Zusammenhang mit Routing-Algo-rithmen ist die Rede, wenn die Zuverlässigkeit jedes Netz-werk-Links (als Bit-Fehlerrate angegeben) betrachtet wird.Einige Netzwerk-Links fallen möglicherweise öfter aus als an-dere. Nach einem Netzwerk-Ausfall werden einige Netzwerk-Links einfacher oder schneller wieder instandgesetzt als an-dere. Alle Faktoren, die die Zuverlässigkeit beschreiben, kön-nen in die Zuordnung von Zuverlässigkeitsrängen eingehen.Dabei handelt es sich um willkürliche Zahlenwerte, die nor-malerweise vom Netzwerk-Administrator jedem Link zuge-wiesen werden.

Routing-Delay (Verzögerung) meint die Dauer einer Über-tragung durch ein Internetwork von der Quelle bis zum Ziel.In die Verzögerung gehen viele Faktoren ein, zu denen auchdie Bandbreite der zwischengeschalteten Netzwerk-Links, diePort-Warteschlange in jedem Router, Staus an den zwischenge-schalteten Netzwerk-Links und die zu überbrückende physi-sche Entfernung gehören. Da es sich bei der Verzögerung umein Konglomerat aus den verschiedensten, wichtigen Variablenhandelt, wird dieser Parameter oft verwendet.

Die Bandbreite bezieht sich auf die Kapazität hinsichtlich desDatenverkehrs auf einer Verbindung. Alles andere spielt keineRolle, wenn ein 10-Mbit/s-Ethernet-Link an eine 64-Kbit/s-Leitung angeschlossen wird, die geleast wird. Auch wenn dieBandbreite die Reihenfolge des höchsten Durchsatzes einesLinks bestimmt, müssen Routen über Links mit größererBandbreite nicht unbedingt die besseren Routen sein, als sol-che, die mit geringerer Bandbreite arbeiten. Wenn z.B. einschneller Link stärker belastet wird, kann die tatsächlich be-nötigte Zeit für die Übertragung eines Pakets größer sein.


Auslastung bezieht sich darauf, wie stark eine Netzwerk-Res-source, z.B. ein Router, beansprucht wird. Die Auslastungkann auf verschiedene Weise berechnet werden. So können dieCPU-Auslastung und die Anzahl der verarbeiteten Pakete proSekunde darin eingehen. Allein die kontinuierliche Überwa-chung dieser Parameter kann bereits sehr ressourcen-intensivsein.

Telefonkosten sind ein weiterer wichtiger Parameter, zumal esFirmen gibt, denen die Kostenseite wichtiger ist als die Per-formance. Selbst wenn die Verzögerung auf den eigenen Lei-tungen größer ist als bei der Übertragung über öffentlicheTelefonleitungen, werden die eigenen Leitungen bevorzugt,weil die öffentlichen Telefonleitungen Geld kosten.

5.4 Netzwerk-Protokolle

Geroutete Protokolle werden von Routing-Protokollen überdas Netzwerk übertragen. In diesem Kontext werden gerou-tete Protokolle auch als Netzwerk-Protokolle bezeichnet. Vondiesen Netzwerk-Protokollen werden eine Vielzahl an Funk-tionen ausgeführt, die für die Kommunikation zwischen Be-nutzer-Anwendungen in Quell- und Zielgeräten erforderlichsind. Dabei unterscheiden sich diese Funktionen zwischen denverschiedenen Protokollfamilien erheblich. Die Netzwerk-Pro-tokolle benützen die oberen vier Schichten des OSI-Referenz-modells: in der Transport-, der Sitzungs-, der Darstellungs-und der Anwendungsschicht.

Daß es zwischen den Begriffen geroutetes Protokoll und Rou-ting-Protokoll zu Verwechslungen kommt, ist normal. Gerou-tete Protokolle sind jene, die über ein Netzwerk geroutet wer-den. Zu diesen Protokollen gehören z.B. das Internet Protocol(IP), DECnet, AppleTalk, Novell NetWare, OSI, BanyanVINES und Xerox Network System (XNS). Routing-Proto-kolle sind jene, die die Routing-Algorithmen implementieren.Um es einfach zu sagen: Routing-Protokolle leiten Netzwerk-Protokolle durch ein Internetwork. Zu diesen Protokollen ge-hören z.B. das Interior Gateway Routing Protocol (IGRP), dasEnhanced Interior Gateway Routing Protocol (EnhancedIGRP), das Open Shortest Path First (OSPF), das ExteriorGateway Protocol (EGP), das Border Gateway Protocol


(BGP), das Intermediate System to Intermediate System (IS-IS)und das Routing Information Protocol (RIP). Geroutete undRouting-Protokolle werden weiter unten ausführlicher bespro-chen.

6 Grundlagen des Netzwerk-Managements

In diesem Kapitel werden die Funktionen beschrieben, die denmeisten Netzwerk-Management-Architekturen und -Protokol-len gemeinsam sind. Außerdem wird auf die fünf konzeptio-nellen Bereiche des Managements eingegangen, wie sie von derInternational Organization for Standardization (ISO) definiertwurden. In den nachfolgenden Kapiteln in Teil 7, »Netzwerk-verwaltung«, werden die spezifischen Netzwerk-Management-Technologien, Protokolle und Plattformen detaillierter bespro-chen.

6.1 Was ist Netzwerk-Management?

Netzwerk-Management hat für verschiedene Personen unter-schiedliche Bedeutung. In manchen Fällen meint man eineneinzelnen Netzwerk-Consultant, der mit einem veralteten Pro-tokoll-Analyzer die Netzwerk-Aktivitäten überwacht. In ande-ren Fällen gehören zum Netzwerk-Management eine verteilteDatenbank, selbständiges Pollen von Netzwerk-Geräten undHigh-End-Workstations, die mit Echtzeit-Grafiken Änderun-gen der Netzwerk-Topologie und den Datenverkehr darstellen.Ganz allgemein läßt sich sagen, daß Netzwerk-Managementeinen Service darstellt, der eine Vielzahl verschiedener Werk-zeuge, Anwendungen und Geräte umfaßt, die den Netzwerk-Manager bei der Überwachung und Verwaltung eines Netzesunterstützen.

KAPITEL 6Grundlagen des Netzwerk-Managements


6.1.1 Ein geschichtlicher Rückblick

In den frühen 80er Jahren kam es zu einer erschreckendenAusweitung des Personalbedarfs im Bereich Netzwerke. Zudieser Zeit wurde erkannt, welche Kostenvorteile und Pro-duktivitätsgewinne durch den Einsatz von Netzwerk-Techno-logie möglich waren. So wurden neue Netze aufgebaut und dievorhandenen erweitert, und zwar so schnell wie neue Netz-werk-Technologien und -Produkte am Markt eingeführt wur-den. Mitte der 80er Jahre machten einige Firmen leidvolleErfahrungen, weil sie viele verschiedene (und manchmalinkompatible) Netzwerk-Technologien im Einsatz hatten.

Die Probleme aus der Netzwerk-Erweiterung betrafen sowohldas tägliche Netzwerk-Management als auch die strategischeNetzwerk-Planung. Jede neue Netzwerk-Technologie erfor-derte ihre eigenen Experten. In den frühen 80er Jahren führteallein der Personalbedarf für die Verwaltung großer, heteroge-ner Netze zu einer Krise in vielen Firmen. So kam es zu einerdringenden Nachfrage nach automatisiertem Netzwerk-Management (einschließlich dessen, was man als Kapazitäts-planung für Netzwerke bezeichnet) über unterschiedlicheUmgebungen hinweg.

6.2 Netzwerk-Management-Architektur

Die meisten Management-Architekturen für Netzwerke ver-wenden die gleiche grundlegende Struktur und die gleichenBeziehungen. Auf Computern und anderen Netzwerk-Geräten(end stations oder managed devices) läuft eine Software, dieauftretende Probleme sofort meldet (z.B. wenn ein oder meh-rere benutzerabhängige Grenzwerte erreicht werden). Mana-gement-Einrichtungen sind so programmiert, daß sie beimEmpfang einer solchen Meldung eine, mehrere oder eineGruppe von Aktionen ausführen. Dazu gehören die Benach-richtigung des Operators, die Ereignis-Protokollierung, dieSystembeendigung und automatische Reparaturversuche.

Management-Einrichtungen können von Stationen im Netz(end station) Daten anfordern (poll), um die Werte bestimmterVariablen zu überprüfen. Das Polling kann automatisch erfol-gen oder von einem Benutzer angestoßen werden. Die Agentenin den verwalteten Geräten reagieren jedoch immer auf alle

Kapitel 6 • Grundlagen des Netzwerk-Managements 99

Polls. Agenten sind Software-Module, die zuerst die Daten desverwalteten Geräts kompilieren, diese dann in einer Mana-gement-Datenbank ablegen und schließlich den Management-Einrichtungen in Netzwerk-Management-Systemen (NMS)über ein Netzwerk-Management-Protokoll zur Verfügungstellen (pro-aktiv oder re-aktiv). Die bekannten Netzwerk-Management-Protokolle beinhalten das Simple Network Ma-nagement Protocol (SNMP) und Common Management In-formation Protocol (CMIP). Management-Proxies sind Ein-richtungen, die Management-Daten anstelle anderer Einrich-tungen zur Verfügung stellen. Bild 6.1 zeigt eine typischeNetzwerk-Management-Architektur.

Management-Datenbank

Netzwork

Agent


Agent


Agent

Proxy

Management-Einheit

Netzwerk-Management-

Protokoll

Verwaltete Geräte

Netzwerk-Management-System(NMS)

6.3 ISO Netzwerk-Management-Modell

Die ISO hat einen großen Beitrag zur Standardisierung vonNetzwerken geleistet. Das Netzwerk-Management-Modell derISO ist das beste Hilfsmittel, um die Grundfunktionen einesNetzwerk-Management-Systems zu verstehen. Dieses Modellbesteht aus fünf konzeptionellen Teilen:

− Performance-Management

− Konfiguration-Management

Bild 6.1:Eine typischeNetzwerk-Management-Architekturverwaltet vieleBeziehungen


− Accounting-Management

− Fehler-Management

− Sicherheits-Management

6.3.1 Performance-Management

Das Ziel des Performance-Managements ist es, die Netzwerk-Performance unter verschiedenen Aspekten zu messen undverfügbar zu machen, damit die gesamte Netzwerk-Perfor-mance (Internetwork performance) auf einem akzeptablen Ni-veau verwaltet werden kann. Zu den Performance-Variablen,die bereitgestellt werden sollten, gehören z.B. der Netzwerk-Durchsatz, Benutzer-Antwortzeiten und Leitungsnutzung.

Das Performance-Management umfaßt drei Hauptschritte. Alserstes werden Performance-Daten aus Variablen gesammelt,die für den Netzwerk-Administrator von Bedeutung sind. Alszweites wird analysiert, ob sich die Daten im normalen Be-reich bewegen. Schließlich werden geeignete Performance-Grenzwerte für jede wichtige Variable festgelegt, so daß beiÜberschreiten eines solchen Werts ein Netzwerk-Problem an-gezeigt wird.

Management-Einrichtungen überwachen die Performance-Va-riablen ständig. Wenn ein Grenzwert erreicht wird, wird eineMeldung generiert und an das Netzwerk-Management-Systemgesendet.

Jeder der soeben beschriebenen Schritte ist Teil des Prozesses,der ein reaktives System ausmacht. Wenn die Performance zustark absinkt, weil ein benutzerdefinierter Grenzwert erreichtwird, reagiert das System, indem es eine Meldung sendet. DasPerformance-Management läßt auch pro-aktive Methoden zu:So kann z.B. eine Netzwerk-Simulation dazu verwendet wer-den, herauszufinden, wie sich die Vergrößerung eines Netz-werks auf die Performance-Parameter auswirkt. Solche Simu-lationen können dem Administrator in Kürze auftretendeProbleme melden, so daß er Gegenmaßnahmen ergreifenkann.


6.3.2 Konfigurations-Management

Ziel des Konfigurations-Managements ist es, die Daten derNetzwerk- und Systemkonfiguration zu überwachen, so daßdie Auswirkungen verschiedenster Hard- und Software aufden Netzwerkbetrieb verfolgt und verwaltet werden können.

Zu jedem Netzwerk-Gerät gibt es unterschiedliche Versions-informationen. Eine Engineering-Workstation könnte z.B. wiefolgt konfiguriert sein:

− Betriebssystem, Version 3.2

− Ethernet-Interface, Version 5.4

− TCP/IP-Software, Version 2.0

− NetWare-Software, Version 4.1

− NFS-Software, Version 5.1

− Controller für serielle Kommunikation, Version 1.1

− X.25-Software, Version 1.0

− SNMP-Software, Version 3.1

Subsysteme des Konfigurations-Managements speichern dieseInformationen in einer Datenbank, damit darauf einfach zu-gegriffen werden kann. Bei auftretenden Problemen kann dieseDatenbank nach Hinweisen zur Problemlösung durchsuchtwerden.

6.3.3 Accounting-Management

Ziel des Accounting-Managements ist es, die Netzwerk-Nut-zung zu messen, um so die Belastung des Netzwerks durcheinzelne Anwender oder Gruppen entsprechend zu regulieren.Dies führt zu weniger Netzwerk-Problemen (da die Ressour-cen entsprechend ihrer Kapazitäten aufgeteilt werden können)und zu angemessener Verfügbarkeit des Netzwerks für alleBenutzer.

Wie beim Performance-Management ist der erste Schritt zueinem entsprechenden Accounting-Management, die Nutzungaller wichtigen Netzwerk-Ressourcen zu messen. Mit derAnalyse dieser Ergebnisse erhalten Sie einen Einblick in aktu-elle Nutzungsmuster, so daß bereits Nutzungsquoten einge-


stellt werden können. Im Laufe der Zeit werden Korrekturennötig sein, um einen optimalen Zugriff zu erreichen. Ausge-hend von diesen Überlegungen, führen fortgesetzte Ressour-cen-Messungen zu Abrechnungsdaten, mit denen außerdemeine faire und optimale Ressourcen-Nutzung zu verwirklichenist.

6.3.4 Fehler-Management

Ziel des Fehler-Managements ist es, Netzwerk-Fehler zu er-kennen, zu protokollieren, Benutzer darüber zu unterrichtenund (so weit möglich) die Fehler automatisch zu beheben,damit das Netz optimal nutzbar ist. Da Fehler zu Ausfallzeitenoder inakzeptablen Antwortzeiten führen können, gehört dasFehler-Management wahrscheinlich zu den am weitesten ver-breiteten Elementen des ISO-Netzwerk-Managements.

Zum Fehler-Management zählen in erster Linie das Erkennenvon Symptomen und die Isolierung von Problemen. Dannkann das Problem behoben und die Lösung auf allen wichti-gen Subsystemen getestet werden. Zuletzt müssen der gefun-dene Fehler und seine Beseitigung aufgezeichnet werden.

6.3.5 Sicherheits-Management

Ziel des Sicherheits-Managements ist es, den Zugriff aufNetzwerk-Ressourcen entsprechend den lokalen Regeln zusteuern, so daß das Netzwerk nicht sabotiert werden kann(versehentlich oder absichtlich) und sensitive Daten nicht vonUnbefugten einsehbar sind. So kann z.B. mit einem Subsystemdes Sicherheits-Managements das Anmelden der Benutzer aneine Netzwerk-Ressource überwacht werden. Und es könnendie Benutzer abgewiesen werden, die einen falschen Zugriffs-code eingeben.

Subsysteme des Sicherheits-Managements dienen der Partitio-nierung der Netzwerk-Ressourcen in autorisierte und nicht-autorisierte Bereiche. Bei bestimmten Anwendern, z.B. firmen-fremde Personen, ist der Zugriff auf Netzwerk-Ressourcenunerwünscht. Für andere (interne) Netzwerk-Benutzer sollte eskeine Zugriffsmöglichkeit auf Daten einer anderen Abteilung,z.B. der Personalverwaltung, geben.


Die Subsysteme des Sicherheits-Managements haben mehrereFunktionen. Sie legen sensitive Netzwerk-Ressourcen fest (ein-schließlich Systemen, Dateien und anderen Einrichtungen) undnehmen die Zuordnung von sensitiven Netzwerk-Ressourcenzu Benutzergruppen vor. Des weiteren überwachen sie Zu-griffspunkte sensitiver Netzwerk-Ressourcen und protokollie-ren bereits den Versuch eines unerlaubten Zugriffs.

Kapitel 7: Ethernet-TechnologienKapitel 8: Fiber Distributed Data Interface (FDDI)Kapitel 9: Token Ring/IEEE 802.5

Teil 2: LAN-Protokolle

Teil 2, »LAN-Protokolle«, bietet die Spezifikationen und ope-rationale Informationen zu den heute wichtigsten Bestand-teilen von lokalen Netzwerken (LAN – local area networking).In den einzelnen Kapiteln werden folgende Themen bespro-chen:

Ethernet-Technologien – In diesem Kapitel werden die Eigen-schaften, Komponenten und der Einsatz der Ethernet-Techno-logien beschrieben, einschließlich Ethernet und IEEE 802.3,100BaseT und 100VG-AnyLAN und Gigabit Ethernet.

Fiber Distributed Data Interface (FDDI) – Dieses Kapitel in-formiert über die FDDI-Architektur, Spezifikationen, Übertra-gungsmedien, Geräte, fehlertolerante Funktionen und dasFrame-Format.

Token Ring/IEEE 802.5 – Dieses Kapitel nennt die betriebs-notwendigen Komponenten von Token-Ring- und IEEE-802.5-Netzwerken. Den Abschluß bildet eine Zusammenfas-sung der grundlegenden Netzwerk-Bedienung.

TEIL 2LAN-Protokolle

7 Ethernet-Technologien

7.1 Hintergrund

Mit dem Begriff Ethernet wird eine Familie lokaler Netzwerk-Implementationen zusammengefaßt, zu der drei Kategoriengehören:

− Ethernet und IEEE 802.3 – LAN-Spezifikationen für eineÜbertragungsgeschwindigkeit von 10 Mbit/s auf Coaxial-Kabel.

− 100-Mbit/s Ethernet – Eine einzelne LAN-Spezifikation, dieauch als Fast Ethernet bekannt ist, für eine Übertra-gungsgeschwindigkeit von 100 Mbit/s auf Twisted-Pair-Kabel.

− 1000-Mbit/s Ethernet – Eine einzelne LAN-Spezifikation,die auch als Gigabit Ethernet bekannt ist, für eine Übertra-gungsgeschwindigkeit von 1000 Mbit/s (1 Gbps) auf Glas-faser- und Twisted-Pair-Kabel.

Dieses Kapitel bietet einen groben Überblick über jede Tech-nologievariante.

Das Ethernet hat als eine der wichtigsten Medium-Technolo-gien überlebt, weil es äußerst flexibel und relativ leicht zu im-plementieren und zu verstehen ist. Obwohl andere Technolo-gien als bester Ersatz angepriesen wurden, sind die Netzwerk-Administratoren beim Ethernet und seinen Derivaten geblie-ben, da sich ihnen hier eine effektive Lösung für eine Vielzahllokaler Implementationen bot. Die Begrenzungen des Ethernet

KAPITEL 7Ethernet-Technologien


wurden immer wieder durch innovative Entwickler (und Stan-dardisierungsgremien) mit ständig erweiterten Ethernet-Pipesüberwunden. Auch wenn Kritiker das Ethernet als eine nicht-skalierbare Technologie verwerfen, bleibt das zugrundelie-gende Übertragungsschema weiterhin eine der Übertragungs-methoden in heutigen lokalen Netzen. Dieses Kapitel be-schreibt die verschiedenen Ethernet-Technologien, die bisheute entwickelt wurden.

7.2 Ethernet und IEEE 802.3

Ethernet ist eine Basisband-LAN-Spezifikation, die von derXerox Corp. erfunden wurde. Ethernet arbeitet mit einerÜbertragungsgeschwindigkeit von 10 Mbit/s und verwendetdas Fehlerprotokoll CSMA/CD (Carrier Sense MultipleAccess/Collision Detect), um auf Coaxial-Kabel zu senden.Ethernet wurde in den 70er Jahren von Xerox entwickelt,wird heute aber oft als Oberbegriff für alle CSMA/CD-LANsverwendet. Ursprünglich wurde das Ethernet für Netzwerkemit sporadischem, gelegentlich hohem Datenverkehr entwor-fen. Die Spezifikation IEEE 802.3 wurde 1980 entwickelt undbasiert auf der originalen Ethernet-Technologie. Die EthernetVersion 2.0 wurde von Digital Equipment Corp., Intel Corp.und Xerox Corp. gemeinsam entwickelt. Sie ist mit IEEE802.3 kompatibel. Bild 7.1 zeigt ein Ethernet-Netzwerk.

Ethernet und IEEE 802.3 sind normalerweise in einer Schnitt-stellenkarte oder einer Schaltung der Hauptplatine implemen-tiert. Die Kabelkonvention für Ethernet gibt vor, daß das phy-sische Netzwerk-Medium über einen Transceiver angeschlos-sen wird. Der Transceiver führt eine Vielzahl der Funktionender physischen Schicht aus, einschließlich der Kollisionserken-nung. Mit einem Transceiver-Kabel werden Stationen an einenTransceiver angeschlossen.

IEEE 802.3 bietet verschiedene Verkabelungen, zu denen dieSpezifikation 10Base5 gehört. Diese Spezifikation kommt demEthernet am nächsten. Das Anschlußkabel wird als Anschalt-schnittstelle (AUI, Attachment Unit Interface) bezeichnet, dasGerät zur Netzwerk-Verbindung als Anschalteinrichtung(MAU, Media Attachment Unit), anstatt eines Transceivers.

Kapitel 7 • Ethernet-Technologien 109

Ethernet-Segment

7.2.1 Ethernet- und IEEE-802.3-Betrieb

In der Broadcast-basierten Umgebung des Ethernet sehen alleStationen sämtliche Frames, die im Netzwerk übertragen wer-den. Nach jeder Übertragung muß jede Station jeden Frameüberprüfen, ob er für sie bestimmt ist. Falls dies zutrifft, wirdder Frame an das Protokoll der nächsthöheren Schicht über-geben.

In einem CSMA/CD-LAN kann jede Station jederzeit auf dasNetzwerk zugreifen. Bevor Daten gesendet werden, hört eineCSMA/CD-Station das Netz auf Datenverkehr ab. Erst wennkeine Datenübertragung mehr stattfindet, beginnt die Station,ihre Daten zu senden.

Da es sich beim Ethernet um eine kollisionsfreie Umgebunghandelt, darf jede Station ihre Daten senden, wenn auf demNetzwerk »Funkstille« herrscht. Zu einer Kollision kommt esdann, wenn zwei Stationen feststellen, daß der Datenverkehrruht und nun beide gleichzeitig mit dem Senden beginnen.Dabei werden die Daten beider Stationen zerstört, so daßbeide Stationen zu einem späteren Zeitpunkt erneut die Datensenden müssen. Back-off-Algorithmen legen fest, wann mit dererneuten Übertragung der Daten begonnen wird.

Bild 7.1:Ein Ethernet-NetzwerkbetreibtCSMA/CDüber Coaxial-Kabel


7.2.2 Ethernet und IEEE-802.3 –Service-Unterschiede

Obwohl Ethernet und IEEE 802.3 sich in vielerlei Hinsichtsehr ähnlich sind, unterscheiden sich die beiden Spezifikatio-nen bei bestimmten Services. Ethernet bietet Services für dieSchichten 1 und 2 des OSI-Referenzmodells, während IEEE802.3 die physische Schicht (Schicht 1) und den Kanalzugriffder Verbindungsschicht (Schicht 2) spezifiziert. Außerdemdefiniert IEEE 802.3 kein logisches Verbindungssicherungs-protokoll, es spezifiziert jedoch mehrere verschiedene physi-sche Schichten, wohingegen Ethernet nur eine definiert. Bild7.2 verdeutlicht die Beziehung von Ethernet und IEEE802.3zum OSI-Referenzmodell.

IEEE 802.3Ethernet

Netzwerk

Data Link

Physikalisch

Anwendung

Darstellung

Kommunikation

Transport

Sicherung

Netzwerk

Data Link

Physikalisch

Anwendung

Darstellung

Kommunikation

Transport

Sicherung

Jedes IEEE-802.3-Protokoll zur physischen Schicht hat einendreiteiligen Namen, der seine Eigenschaften wiedergibt. Dabeisteht je ein Teil für die LAN-Geschwindigkeit, Signalisierungs-methode und den physischen Mediumtyp. Bild 7.3 veran-schaulicht diese Namenskonvention.

10Base5

Base = Basisband

LAN-Übertragungs-geschwindigkeit

in MBit/sTyp des physischen Mediums

Bild 7.2:Ethernet und

IEEE im OSI-Referenzmodell

Bild 7.3:IEEE-802.3-

Komponentensind den Kon-ventionen ent-

sprechendbenannt


Tabelle 7.1 faßt die Unterschiede zwischen Ethernet und IEEE802.3 und zwischen den verschiedenen Spezifikationen derphysischen Schichten der IEEE 802.3 zusammen.

-negiEtfahcs

-tenrehtEtreW

EEEI3.208etreW

5esaB01

2esaB01 TesaB01 LFesaB01 TesaB001

etarnetaD)s/tiBM(

01 01 01 01 010 01

-ilangiS-sgnureisnerhafrev

-sisaBdnab

-sisaBdnab

-sisaBdnab

-sisaBdnab

-sisaBdnab

-sisaBdnab

.xaM-tnemgeS

egnäl

005 005 581 001 000.2 001

muideM -imho05xaoCseg

)kciht(

-imho05xaoCseg

)kciht(

-imho05xaoCseg

)niht(

-egnUsetmrihcs

detsiwT-riaPlebaK)PTU(

ehcsitpOresaF

-egnUsetmrihcs

detsiwT-riaPlebaK)PTU(

eigolopoT suB suB suB nretS -uz-tknuPtknuP

suB

7.2.3 Ethernet- und IEEE-802.3-Frame-Formate

Bild 7.4 zeigt die Frame-Felder in ihrer Zuordnung sowohl inEthernet- als auch in IEEE-802.3-Frames.

Zieladresse

Ethernet

Quelladresse Daten

Frame-

Prüf-

summe

(FCS)

Feldlänge in Byte

8 6 2 46-1500 4

Typ

6

ZieladresseKopf Quelladresse

802.2-Header

und Daten

Frame-

Prüf-

summe

(FCS)

Feldlängein Byte

7 6 2 46-1500 4

Länge

6

S

O

F

1

SOF = Start-of-Frame Delimiter (Start-Kennzeichen)FCS = Frame Check Sequence (Frame-Prüfsumme)

Kopf

IEEE 802.3

Tabelle 7.1:VergleichverschiedenerSpezifikationenzur physischenSchicht beiIEEE 802.3

Bild 7.4:VerschiedeneFrame-Felderfür Ethernetund IEEE802.3


Die Frame-Felder des Ethernet und IEEE 802.3, welche in Bild7.4 illustriert sind, werden in der folgenden Übersicht be-schrieben:

− Kopf (Header) – Die wechselnden Muster von Einsen undNullen teilen der empfangenden Station mit, daß ein Framebeginnt (Ethernet oder IEEE 802.3). Der Ethernet-Frameenthält ein zusätzliches Byte, das dem Frame-Anfangsfeld(Start of Frame – SOF) des IEEE 802.3 entspricht.

− Frame-Anfang (Start-of-Frame – SOF) – Das Trenn-Bytebei IEEE 802.3 endet mit zwei aufeinanderfolgenden Bitsmit dem Wert 1, die der Synchronisation aller Stationen imLAN dienen. Der Frame-Anfang ist für das Ethernet expli-zit spezifiziert.

− − − − Ziel- und Quelladressen – Die ersten drei Byte sind vomIEEE herstellerabhängig definiert. Die letzten drei Bytewerden vom Ethernet- oder IEEE-802.3-Hersteller spezifi-ziert. Die Quelladresse ist immer eine Unicast-Adresse(Einzel-Knoten). Die Zieladresse kann eine Unicast- (an ei-nen einzelnen Knoten), Multicast- (an eine Gruppe) oderBroadcast-Adresse (an alle) sein.

− Typ (Ethernet) – Der Typ spezifiziert das Protokoll der hö-heren Schicht, an das die Daten weitergegeben werden,nachdem die Ethernet-Verarbeitung beendet wurde.

− Länge (IEEE 802.3) – Die Länge gibt die Anzahl der Da-ten-Byte an, die diesem Feld folgen.

− − − − Daten (Ethernet) – Nach der physischen und der Verbin-dungsschicht werden die Daten des Frame an ein Protokollder nächsthöheren Schicht weitergegeben, das im Typ-Feldbezeichnet wird. Obwohl Ethernet Version 2 keine Mustervorgibt (im Gegensatz zu IEEE 802.3), erwartet es dochmindestens 46 Byte mit Daten.

− Daten (IEEE 802.3) – Nach der physischen und der Ver-bindungsschicht werden die Daten des Frame an ein Proto-koll der nächsthöheren Schicht weitergegeben, das inner-halb der Frame-Daten definiert ist. Falls weniger als 64 Da-ten-Byte vorliegen, wird der Frame auf 64 Byte aufgefüllt.

− Frame-Prüfsumme (Frame Check Sequence [FCS]) – DieseByte-Folge enthält einen 4 Byte langen CRC-Wert (Cyclic


Redundancy Check), der vom sendenden Gerät erzeugt undvom empfangenden Gerät überprüft wird, um zerstörteFrames zu erkennen.

7.3 100-Mbit/s Ethernet

100-MBit/s Ethernet ist eine sehr schnelle LAN-Technologie,die sowohl dem Desktop-Benutzer im Netz als auch den Ser-vern und Server-Clustern (zuweilen als Server-Farmen be-zeichnet) in den Daten-Centern eine größere Bandbreite bietet.

Die Higher Speed Ethernet Study Group des IEEE sollte unter-suchen, ob es möglich ist, ein Ethernet mit 100 Mbit/s zu be-treiben. Zwar formulierte die Studiengruppe mehrere Ziele fürdieses Hochgeschwindigkeits-Ethernet, konnte sich aber beider Zugriffsmethode nicht einigen. Zur Debatte stand, ob die-ses neue schnellere Ethernet CSMA/CD den Zugriff auf dasNetzwerk-Medium unterstützen oder eine andere Methodedafür gewählt werden sollte. Über diesem Streit teilte sich dieStudiengruppe in zwei Lager: in die Fast-Ethernet-Allianz unddas 100VG-AnyLAN-Forum. Von jeder Gruppe wurde eineSpezifikation für den Betrieb eines schnellen Ethernet (bzw.Token Ring für das letztere) erstellt: 100BaseT und 100VG-AnyLAN.

100BaseT ist die IEEE-Spezifikation für die 100-Mbit/s-Ether-net-Implementation mit UTP- (unshielded twisted-pair – unge-schirmte Twisted-Pair-Kabel) und STP-Verkabelung (shieldedtwisted-pair). Die Schicht Media Access Control (MAC) istzur IEEE-802.3-MAC-Schicht kompatibel. Grand Junction,heute ein Unternehmen der Cisco Systems Workgroup Busi-ness Unit (WBU), entwickelte das Fast Ethernet, das vom IEEEmit der Spezifikation 802.3 zum Standard erklärt wurde.

100VG-AnyLAN ist die IEEE-Spezifikation für 100-Mbit/s-Implementationen von Token Ring und Ethernet mit vier-adrigem UTP. In diesem Fall ist die MAC-Schicht nichtkompatibel zur IEEE-802.3-MAC-Schicht. 100VG-AnyLANwurde von Hewlett-Packard (HP) entwickelt, um neuere, zeit-kritische Anwendungen wie Multimedia zu unterstützen. EineVersion der HP-Implementationen wurde vom IEEE mit derSpezifikation 802.12 zum Standard erklärt.


7.3.1 100BaseT im Überblick

100BaseT verwendet die bestehende Spezifikation IEEE 802.3CSMA/CD. Als ein Ergebnis behält 100BaseT das IEEE-802.3Frame-Format, die Frame-Größe und die Fehlererkennung bei.Zusätzlich unterstützt es alle Anwendungen und Netzwerk-Software, die gegenwärtig in 802.3-Netzwerken läuft. Mit100BaseT Fast Link Pulses (FLPs) unterstützt 100BaseT sowohl10 als auch 100 Mbit/s. 100BaseT-Hubs müssen die zweiÜbertragungsgeschwindigkeiten wie Token Ring 4/16-Hubs er-kennen. Netzwerk-Karten unterstützen 10 Mbit/s, 100 Mbit/soder beide Geschwindigkeiten. Bild 7.5 zeigt, wie die 802.3-MAC-Subschicht und höhere Schichten unverändert mit100BaseT betrieben werden können.

Protokolle der Anwendungs-Softwareund höhere Schichten

802.3-Media-Access-Control-Subschicht

100BaseT physikalische Schicht

7.3.2 100BaseT-Signalisierung

100BaseT unterstützt zwei Signalisierungsarten:

− 100BaseX

− 4T+

Beide Verfahren sind auf Ebene der Stationen und Hubs inter-operabel. Das Media Independend Interface (MII) – eine AUI-ähnliche Schnittstelle – bietet auf Stationsebene lnteroperabili-tät. Auf Hub-Ebene gilt gleiches.

Das Signalisierungsschema von 100BaseX verfügt über eineKonvergenz-Subschicht. Diese Schicht setzt die kontinuierlicheVoll-Duplex-Signalisierung auf der FDDI-Schicht (physicalmedium dependent – PMD) in die Halb-Duplex-Signalisierung(mit Start-Stop) für die Subschicht des Ethernet Media Access

Bild 7.5:802.3 MAC

und Protokollehöherer Schich-

ten werdenüber 100BaseT

betrieben


Control (MAC) um. Da 100BaseTX die vorhandene FDDI-Spezifikation verwendet, kamen die Produkte schnell auf denMarkt. 100BaseX ist die Signalisierung, die von den Medium-typen 100BaseTX und 100BaseFX eingesetzt wird. Bild 7.6zeigt, wie die Konvergenz-Subschicht des 100BaseX die beidenSignalisierungen umsetzt.

Konvergenz-Subschicht

Ethernet-MAC-Subschicht

FDDI-PMD-Schicht

Das Signalisierungsverfahren 4T+ nutzt ein Drahtpaar für dieKollisionserkennung und die anderen drei Drahtpaare für dieDatenübertragung. Somit kann 100BaseT auf einer Verkabelungder Kategorie 3 betrieben werden, wenn alle vier Drahtpaare amDesktop angeschlossen sind. 4T+ ist das Signalisierungsverfah-ren, das für 100BaseT4-Mediumtypen verwendet wird und nurden Halb-Duplex-Betrieb unterstützt. Bild 7.7 zeigt, wie die 4T+-Signalisierung alle vier Drahtpaare des UTP beansprucht.

7.3.3 100BaseT-Hardware

Folgende Komponenten gehören zu einer physischen100BaseT-Verbindung:

− Physisches Medium – Diese Komponente überträgt dieSignale zu den Computern und kann einer der drei100BaseT-Mediumtypen sein:

− 100BaseTX

− 100BaseFX

− 100BaseT4

Bild 7.6:Die 100BaseX-Konvergenz-Subschicht istdie Schnittstellezweier Signali-sierungs-verfahren


UTP

UTPÜbertragungs-

schaltung

UTPÜbertragungs-

schaltungDaten-

Verschlüsseler

UTPÜbertragungs-

schaltung

Daten-Splitter

Ethernet-MAC-

Subschicht

Träger-Erkennung Adernpaar 2

Adernpaar 1

Adernpaar 3

Adernpaar 4

− Medium-Dependent Interface (MDI) – Das MDI ist diemechanische und elektrische Schnittstelle zwischen demÜbertragungsmedium und dem Gerät der physischenSchicht (PHY).

− Gerät der physischen Schicht (PHY) – Das PHY kann mit10 Mbit/s oder 100 Mbit/s betrieben werden und bestehtaus integrierten Schaltungen (ICs) – oder einer eigenenKarte – mit einer Ethernet-Schnittstelle. Oder es handeltsich um ein externes Gerät mit einem MII-Kabel (MediumIndependent Interface), das an die MII-Schnittstelle eines100BaseT-Geräts (ähnlich einem 10-Mbit/s-Ethernet-Transceiver) angeschlossen wird.

− Medium Independent Interface (MII) – Das MII wird zu-sammen mit externen 100-Mbit/s-Transceivern eingesetzt,um ein 100-Mbit/s-Ethernet-Gerät an einen der drei Me-diumtypen anzuschließen. Das MII ist mit einem 40poligenStecker ausgestattet und bis zu 0,5 Meter lang.

Bild 7.8 zeigt die 100BaseT-Hardware-Komponenten.

DTE

40poliger Stecker

MII

Gerät derphysikalischen Schicht

MDI

PhysischesMedium

Für 100-MBit/s-Ethernet benötigte Komponenten

Bild 7.7:4T+ benötigt

vier UTP-Adernpaare

Bild 7.8:100BaseT

benötigtmehrere

Hardware-Komponenten


7.3.4 100BaseT-Betrieb

100BaseT und 10BaseT setzen beide die gleichen Verfahrennach IEEE 802.3 für den MAC-Zugriff und die Fehlererken-nung ein. Beide haben das gleiche Frame-Format und die glei-chen Längenanforderungen. Der eigentliche Unterschied zwi-schen 100BaseT und 10BaseT (außer dem offensichtlichen Ge-schwindigkeitsunterschied) ist der Netzwerk-Durchmesser. Für100BaseT liegt das Maximum dafür bei 205 Meter, was ca.um den Faktor 10 kleiner ist als beim 10-Mbit/s Ethernet.

Der Grund für die Verkleinerung des Netzwerk-Durchmessersbei 100BaseT liegt im Verfahren der Fehlererkennung, welchesdas gleiche ist wie bei 10BaseT. Die maximale Entfernungwurde für 10BaseT so definiert, daß eine Station noch beimÜbertragen des kürzesten zulässigen Frame (64 Byte) die Kolli-sion mit einer sendenden Station am entferntesten Punkt derDomäne erkennt.

Um den erhöhten Durchsatz von 100BaseT zu erreichen,mußte die Größe der Kollisionsdomäne verkleinert werden.Dies ist erforderlich, da die Ausbreitungsgeschwindigkeit desMediums sich nicht geändert hat. Daraus folgt, daß bei zehn-mal schnellerer Übertragung die maximale Entfernung nur einZehntel betragen kann. So erkennt jede Station bereits beimSenden der ersten 64 Byte, ob es zu einer Kollision mit eineranderen Station gekommen ist.

100BaseT Fast-Link Pulses (FLPs)

Die von 100BaseT verwendeten Signale werden als Fast-LinkPulses (FLPs) bezeichnet und dienen der Verbindungsintegritätzwischen einem Hub und 100BaseT-Gerät. FLPs sind abwärts-kompatibel mit den 10BaseT Normal-Link Pulses (NLPs). DieFLPs beinhalten mehr Informationen als NLPs und werdenbeim automatischen Abstimmungsprozeß zwischen Hub undeinem Gerät im 100BaseT-Netzwerk verwendet.


100BaseT Autonegotiation-Option

100BaseT-Netzwerke unterstützen eine optionale Funktion,die automatische Abstimmung, mit der ein Gerät und ein Hubin der Lage sind, Daten über ihre Eigenschaften auszutauschen(mit 100BaseT FLPs), wodurch eine optimale Kommunika-tionsumgebung geschaffen wird.

Die automatische Abstimmung unterstützt eine Vielzahl vonEigenschaften, einschließlich der Geschwindigkeitsabstim-mung für Geräte, die im 10- und 100-Mbit/s-Betrieb zum Ein-satz kommen. Außerdem wird der Voll-Duplex-Betrieb fürentsprechende Geräte und die automatische Signalisierungs-konfiguration für 100BaseT4- und 100BaseTX-Stationenunterstützt.

7.3.5 100BaseT-Mediumtypen

100BaseT unterstützt für die physische OSI-Schicht (Schicht 1)drei Mediumtypen: 100BaseTX, 100BaseFX und 100BaseT4.Diese drei Mediumtypen, die alle mit der MAC-Schicht derIEEE 802.3 kommunizieren können, sind in Bild 7.9 darge-stellt. Tabelle 7.2 vergleicht die Schlüsseleigenschaften der drei100BaseT-Mediumtypen.

Protokolle der Anwendungs-Softwareund höhere Schichten

802.3-Media-Access-Control-Subschicht

100BaseFX 100BaseT4100BaseTX100BaseT

Physikalische Schicht

Bild 7.9:Drei

100BaseT-Mediumtypenstehen in der

physischenSchicht zurVerfügung


Eigenschaften 100BaseTX 100BaseFX 100BaseT4Kabel Kategorie 5 UTP

oder Typ 1 und 2STP

62.5/125 Micron-Multi-Modus-Faser

Kategorie 3, 4oder 5 UTP

Anzahl der Adernbzw. Fasern

2adrig 2faserig 4adrig

Stecker ISO 8877 (RJ-45) Duplex Scmedia-interface connec-tor (MIC) ST

ISO 8877 (RJ-45)

Max. Segment-länge

100 m 400 m 100 m

Max. Netzwerk-Durchmesser

200 m 400 m 200 m

100BaseTX

100BaseTX basiert auf der Spezifikation Twisted Pair-PhysicalMedium Dependent (TP-PMD) des American National Stan-dards Institute (ANSI). Diese Spezifikation unterstützt unge-schirmte Twisted-Pair-Kabel (unshielded twisted-pair, UTP)und geschirmte Twisted-Pair-Kabel (shielded twisted-pair,STP). 100BaseTX verwendet das Signalisierungsverfahren von100BaseX auf 2adrigen Kabeln der Kategorie 5 UTP oder STP.

Die IEEE-802.3u-Spezifikation für 100BaseTX-Netze läßtmaximal zwei Repeater-(Hubs-)Netzwerke und einen gesam-ten Netzwerk-Durchmesser von ca. 200 Metern zu. Ein Link-Segment, das durch die Punkt-zu-Punkt-Verbindung zweierMII-Geräte (Medium Independent Interface) definiert ist,kann einen Durchmesser von bis zu 100 Metern haben. Bild7.10 illustriert diese Konfigurationsrichtlinien.

Maximale Netzwerk-Entfernung = 200 m

Maximale Link-Entfernung

= 100 m

Tabelle 7.2:Eigenschaftender 100BaseT-Mediumtypen

Bild 7.10:100BaseTX istauf eine Ver-bindungslängevon 100 Meterbeschränkt


100BaseFX

100BaseFX basiert auf der Spezifikation ANSI TP PMD(Twisted Pair-Physical Medium Dependent) X3T9.5 für FDDILANs. 100BaseFX verwendet das Signalisierungsverfahren100BaseX auf einem 2faserigen Multi-Modus-Glasfaser-Kabel(MMF). Die Spezifikation IEEE 802.3u für 100BaseFX-Netzeermöglicht DTE-zu-DTE-Verbindungen (Data Termial Equip-ment – Datenendeinrichtung, DDE) von bis zu 400 Meternoder ein Repeater-Netzwerk von ca. 300 Metern Länge. Bild7.11 illustriert diese Konfigurationsrichtlinien.

Hub

Maximale Entfernung = 300 m

Maximale Entfernung = 400 m

100BaseT4

100BaseT4 erlaubt den Betrieb von 100BaseT auf einer Ver-kabelung der Kategorie 3, wenn alle vier Kabelpaare an denDesktop angeschlossen sind. 100BaseT4 verwendet die Signa-lisierung Halb-Duplex 4T+. Die Spezifikation 802.3u für100BaseT4-Netzwerke läßt maximal zwei Repeater-Netz-werke (Hubs) und einen Gesamtdurchmesser von ca. 200 Me-tern zu. Ein Link-Segment, das durch eine Punkt-zu-Punkt-Verbindung von zwei MII-Geräten definiert ist, kann bis zu100 Meter weit reichen. Bild 7.12 illustriert diese Konfigura-tionsrichtlinien.

Bild 7.11:100BaseFX istauf eine DTE-zu-DTE-Ver-

bindungslängevon 400 Meter

beschränkt


Maximale Netzwerk-Entfernung = 200 m

Maximale Link-Entfernung

= 100 m

7.4 100VG-AnyLAN

100VG-AnyLAN wurde von Hewlett-Packard (HP) als Alter-native zu CSMA/CD für neuere, zeitkritische Anwendungen,z.B. Multimedia, entwickelt. Die Zugriffsmethode basiert aufStationsanfrage und wurde als Ausbau von Ethernet und 16-Mbit/s Token Ring entworfen. 100VG-AnyLAN unterstütztfolgende Kabeltypen:

− vieradrig, Kategorie 3, ungeschirmtes Twisted-Pair-Kabel(UTP)

− zweiadrig, Kategorie 4 oder 5, UTP

− geschirmtes Twisted-Pair-Kabel (STP)

− Glasfaser

Der Standard IEEE 802.12 100VG-AnyLAN spezifiziert diemaximale Link-Länge, Hub-Konfiguration und maximaleNetzwerk-Länge. Die Link-Länge zwischen Knoten und Hubbeträgt 100 Meter (Kategorie 3, UTP) oder 150 Meter (Kate-gorie 5, UTP). Bild 7.13 illustriert die maximalen Link-Längenfür 100VG-AnyLAN.

150 MeterKategorie 5 UTP


100VG-AnyLAN-Hubs sind hierarchisch angeordnet. JederHub hat mindestens einen aufwärtsgerichteten Port (uplink),während alle anderen Ports abwärtsgerichtet (downlink) sein

Bild 7.12:100BaseT4 istauf eine Ver-bindungslängevon 100 Meterbeschränkt

Bild 7.13:100VG-Any-LAN ist aufverschiedeneLängen fürKategorie 3und 5 UTPbeschränkt


können. Hubs können dreistufig kaskadiert werden, wenn sieeine Aufwärtsverbindung zu anderen Hubs haben. Die Kabel-länge zwischen kaskadierten Hubs kann maximal 100 Meter(Kategorie 3, UTP) bzw. 150 Meter (Kategorie 5, UTP) betra-gen. Bild 7.14 zeigt die 100VG-AnyLAN-Hub-Konfiguration.

Aufwärts-gerichteter

Port

Abwärts-gerichteter

Port

Die Entfernung der Enden im Netz ist auf 600 Meter (Kate-gorie 3, UTP) bzw. 900 Meter (Kategorie 5, UTP) beschränkt.Wenn Hubs im gleichen Verteilerraum stehen, sinkt diemaximale Entfernung auf 200 Meter (Kategorie 3, UTP) bzw.auf 300 Meter (Kategorie 5, UTP). Bild 7.15 zeigt die maxi-malen Entfernungen in 100VG-AnyLAN-Netzen.



900 Meter End-to-End

(Kategorie 5)

600 Meter End-to-End

(Kategorie 3)

Bild 7.14:100VG-Any-

LAN-Hubssind hierar-

chisch ange-ordnet

Bild 7.15:Entfernungs-beschränkun-gen für Ende-zu-Ende-Ver-bindungen im100VG-Any-LAN hängen

von der Imple-mentation ab


7.4.1 100VG-AnyLAN-Betrieb

100VG-AnyLAN verwendet die Demand-Priority Access Me-thod, die Kollisionen vermeidet und höher belastet werdenkann als 100BaseT. Diese Methode ist stärker deterministischals CSMA/CD, da der Hub den Zugriff auf das Netzwerksteuert.

Der 100VG-AnyLAN-Standard erfordert einen Level-One-Hub oder Repeater, der als Root arbeitet. Dieser Root-Repea-ter steuert den Betrieb der Priority Domain. Hubs können ineiner Sternverkabelung dreistufig kaskadiert werden. Mitein-ander verbundene Hubs arbeiten wie ein einzelner großer Re-peater, wobei der Root Repeater die Ports nacheinander ab-fragt.

In einem 100VG-AnyLAN-Netz mit Demand-Priority-Betriebsignalisiert ein Knoten, der Daten übertragen will, seine An-forderung dem Hub (oder Switch). Wenn auf dem Netz keineÜbertragung stattfindet, quittiert der Hub sofort die Anforde-rung, und der Knoten überträgt ein Paket an den Hub. Fallsmehrere Anforderungen gleichzeitg beim Hub eingehen, ver-wendet der Hub eine Round-Robin-Technik, um jede Anfor-derung zu quittieren. Anforderungen von hoher Priorität, z.B.von zeitkritischen Video-Konferenz-Programmen, werden alserste bedient. Um für alle Stationen eine Zugangsmöglichkeitoffenzuhalten, läßt ein Hub den priorisierten Zugriff für einenPort nur zweimal hintereinander zu.

7.5 Gigabit Ethernet

Gigabit Ethernet ist eine Erweiterung des IEEE-802.3-Ether-net-Standards. Gigabit Ethernet hat eine Bandbreite von1000 Mbit/s, wobei die Kompatibilität zu Ethernet- und Fast-Ethernet-Geräten gewahrt bleibt. Gigabit Ethernet bietet Voll-Duplex-Betrieb für die Verbindung Switch-zu-Switch undSwitch-zu-Endgerät. Halb-Duplex-Betrieb ist auf gemeinsamnutzbaren Verbindungen möglich, wenn Repeater undCSMA/CD eingesetzt werden. Des weiteren verwendet GigabitEthernet das gleiche Frame-Format, die gleiche Frame-Größeund die gleichen Management-Objekte wie vorhandene IEEE-802.4-Netze. Am ehesten ist Gigabit Ethernet für Glasfaser-


Verkabelung gedacht, es kann aber auch mit Kategorie 5, UTPund Coaxial-Kabel betrieben werden.

Die Gigabit-Ethernet-Allianz ist eine offene Vereinigung meh-rerer Hersteller, die Firmen bei der Entwicklung von GigabitEthernet unterstützt. Von dieser Allianz werden Aktivitätenzur Standardisierung von Gigabit Ethernet unterstützt, die vonder Arbeitsgruppe IEEE 802.3 geleitet werden. Außerdemstellt sie technische Ressourcen zur Verfügung, um Konver-genz und Konsens bei der technischen Spezifikation zu errei-chen. Ferner werden Ressourcen bereitgestellt, um die Pro-dukt-Interoperabilität einzuführen und zu demonstrieren unddie Kommunikation zwischen den potentiellen Anbietern undKäufern von Gigabit-Ethernet-Produkten zu fördern.

Die IEEE-802.3-Arbeitsgruppe hat eine Projektgruppe für das802.3z Gigabit Ethernet gebildet, die einen Standard entwik-keln soll, der eine Reihe von Anforderungen festschreibt. Die-ser Standard muß Voll- und Halb-Duplex-Betrieb bei1000 Mbit/s erlauben. Entsprechende Implementationen ver-wenden das Standard IEEE 802.3/Ethernet-Frame-Format unddie Medium-Zugriffsmethode CSMA/CD. Gigabit Ethernet-Implementationen werden ebenfalls abwärtskompatibel zu10BaseT und 100BaseT sein. Des weiteren soll der IEEE-Stan-dard die Unterstützung für Multi-Modus-Glasfaser-Verbin-dung mit einer maximalen Länge von 500 Metern festlegen;für Single-Modus-Glasfaser-Verbindung mit einer maximalenLänge von 2 km und bei einer Kupferverkabelung mit maxi-mal 25 Metern. Der Gigabit-Ethernet-Standard wird ein Anhangzum bereits vorhandenen Standard 802.3 Ethernet/Fast Ethernet.

7.5.1 Gigabit-Ethernet-Spezifikation

Die gegenwärtigen Bemühungen um einen Standard setzen aufFibre Channel und andere Netzwerk-Komponenten mit ho-hem Datendurchsatz. Die Gigabit-Ethernet-Implementationensind mit schnellen optischen Komponenten für 780 nm (kurz-wellige) Fibre Channels ausgestattet, die die optische Daten-übertragung übernehmen. 8B/10B-Ver- und Entschlüsselungs-verfahren werden für die Serialisierung und Deserialisierungeingesetzt. Für größere Entfernungen werden optische Kompo-nenten für 1300 nm (langwellig) spezifiziert. Um für dieEntwicklung bei Halbleitern und der digitalen Signalver-


arbeitung gewappnet zu sein, wird eine logische, medium-unabhängige Schnittstelle für die Schichten MAC und PHYspezifiziert, mit der das Gigabit Ethernet auf ungeschirmterTwisted-Pair-Verkabelung (UTP) betrieben werden kann. Dieselogische Schnittstelle wird dazu führen, daß Kodierungen, diefür UTP-Verkabelungen geeignet sind, unabhängig von derFibre-Channel-Kodierung implementiert werden. Bild 7.16illustriert die funktionalen Elemente des Gigabit Ethernet.

Media Access Control (MAC)Voll- und Halb-Duplex

Physikalische Schicht KupferCodierung

8B/10BCodierung

Logical Media Independent Interface

Halb-Duplex-Repeater

Voll-Duplex-Links

Single-Mode-Faser-Optik

Twisted-Pair-Transceiver

Fibre-Channel-Optik

Single-Mode-Faserkabel

Twisted-Pair-Kabel

Multi-ModeFaserkabel

7.5.2 Migrieren zum Gigabit Ethernet

Die Migration zum Gigabit Ethernet wird in kleinen Schrittenerfolgen, wobei mit den Backbones der vorhandenen Ethernet-LANs begonnen wird. Dann werden die Verbindungen zwi-schen den Servern umgestellt, und eventuell werden auch dieDesktops auf diesen Stand gebracht. Zu den voraussichtlichenAktionen einer Implementation gehören folgende:

− Ausbauen von Switch-zu-Switch-Verbindungen – 100-Mbit/s-Verbindungen zwischen Fast-Ethernet-Switchesoder Repeatern können durch 1000-Mbit/s-Verbindungen

Bild 7.16:FunktionaleElemente desGigabit Ether-net


ersetzt werden. Dadurch wird die Kommunikation zwi-schen Backbone-Switches beschleunigt, und die Switchessind in der Lage, eine größere Anzahl geswitchter und ge-meinsamer Fast-Ethernet-Segmente zu unterstützen.

− Ausbauen von Switch-zu-Server-Verbindungen – 1000-Mbit/s-Anbindungen können zwischen Switches undHochleistungs-Servern implementiert werden. Bei dieserAktion müssen die Server mit Gigabit-Ethernet-NICs aus-gestattet werden.

− Ausbauen eines Fast-Ethernet-Backbone – Ein Fast-Ether-net-Backbone-Switch, an dem 10/100-Mbit/s-Switches an-geschlossen sind, kann zu einem Gigabit-Ethernet-Switchausgebaut werden, der sowohl mehrere 100/1000-Mbit/s-Switches als auch Router und Hubs mit Gigabit-Ethernet-Schnittstelle und Gigabit-Repeater unterstützt.

Damit ist es möglich, die Server mit den Gigabit-Ethernet-NICs direkt an den Backbone anzuschließen, so daß für Be-nutzer mit sehr bandbreitenintensiven Anwendungen derDurchsatz zum Server vergrößert wird. Ein Gigabit-Ethernet-Netzwerk kann eine größere Anzahl von Segmenten, eine grö-ßere Bandbreite je Segment und somit eine größere AnzahlKnoten je Segment unterstützen.

− Ausbauen eines gemeinsam genutzten FDDI-Backbone –Ein FDDI-Backbone kann ausgebaut werden, indem derFDDI-Konzentrator, der Hub oder Ethernet-zu-FDDI-Rou-ter durch einen Gigabit-Ethernet-Switch oder -Repeater er-setzt wird. Ansonsten müssen nur noch die neuen Gigabit-Ethernet-Schnittstellen in den Routern, Switches oderRepeatern installiert werden.

− Ausbauen von Hochleistungs-Desktops – Mit Gigabit-Ethernet-NICs können Hochleistungs-Desktop-Computerfür das Gigabit Ethernet aufgerüstet werden. Diese Com-puter werden an Gigabit-Ethernet-Switches oder -Repeaterangeschlossen.

8 Fiber Distributed Data Interface (FDDI)

8.1 Hintergrund

Das Fiber Distributed Data Interface (FDDI) spezifiziert ein100-Mbps-Doppelring-LAN, das mit Token arbeitet und alsMedium eine optische Faser verwendet. FDDI wird am häu-figsten in Hochgeschwindigkeits-Backbones eingesetzt, da eseine größere Bandbreite und weitere Entfernungen erlaubt alsdas Kupferkabel. Es muß allerdings darauf hingewiesen wer-den, daß es eine relativ neue entsprechende Spezifikation fürKupferkabel gibt, die als Copper Distributed Data Interface(CDDI) bezeichnet wird und auf diesem Medium eine Über-tragungsrate von 100 Mbps ermöglicht. CDDI ist die Imple-mentation der FDDI-Protokolle für Twisted-Pair-Kupferkabel.In diesem Kapitel liegt der Schwerpunkt auf der FDDI-Spezifi-kation, wobei CDDI auch immer wieder zur Sprache kommt.

FDDI verwendet die Doppelring-Architektur mit Datenver-kehr auf beiden Ringen in entgegengesetzter Richtung (auchals gegenläufig bezeichnet). Der Doppelring besteht aus demprimären und dem sekundären Ring. Im normalen Betriebdient der primäre Ring der Datenübertragung, während aufdem sekundäre Ring der Datenverkehr ruht. Der eigentlicheZweck des Doppelrings ist eine hohe Zuverlässigkeit und Ro-bustheit des Netzes. Bild 8.1 zeigt die gegenläufigen primärenund sekundären FDDI-Ringe.

KAPITEL 8Fiber Distributed Data Interface (FDDI)


Secondär

Primär

FDDI

Konzentrator WAN

8.1.1 Standards

FDDI wurde Mitte der 80er Jahre vom X3T9.5-Standard-komitee des American National Standards Institute (ANSI)entwickelt. Zu dieser Zeit stellten schnelle Engineering-Workstations die Bandbreite der vorhandenen Ethernet- oderToken-Ring-LANs hart auf die Probe. Es wurde ein neuesLAN-Medium erforderlich, das diese Workstation und ihreneuen verteilten Anwendungen verkraftete. Gleichzeitig wuchsdie Bedeutung der Netzwerk-Zuverlässigkeit, da unterneh-menswichtige Anwendungen von Großrechnern auf Netz-werke migriert wurden. Um diese Anforderungen zu erfüllen,wurde FDDI entwickelt. Nachdem die FDDI-Spezifikationfertiggestellt war, wurde sie vom ANSI an die InternationalOrganization for Standardization (ISO) weitergeleitet. Dortwurde eine internationale Version von FDDI erstellt, die vollzur ANSI-Version kompatibel ist.

8.2 FDDI-Übertragungsmedium

Bei FDDI wird eine optische Faser (Glasfaser) als primäresÜbertragungsmedium verwendet. Es ist jedoch auch möglich,FDDI auf Kupferkabeln zu betreiben. Dies wird als Copper-Distributed Data Interface (CDDI) bezeichnet. Die optischeFaser hat viele Vorteile gegenüber dem Kupfer. Im einzelnenwerden die Sicherheit, Zuverlässigkeit und der Durchsatz beider optischen Faser verbessert, da keine elektrischen Signale

Bild 8.1:FDDI setzt

gegenläufigeprimäre und

sekundäreRinge ein

Kapitel 8 • Fiber Distributed Data Interface (FDDI) 129

emittiert werden. Ein Medium, das elektrische Signale emit-tiert, kann abgehört werden und erlaubt somit unbefugtenZugriff auf die übertragenen Daten. Außerdem kann die Über-tragung in der Faser nicht durch hochfrequente (RFI) oderelektromagnetische Interferenzen (EMI) gestört werden. Bisherkonnte die Faser eine wesentlich höhere Bandbreite (und da-mit Datendurchsatz) aufweisen als das Kupferkabel, jedocherlauben die neuesten Entwicklungen auch auf dem Kupfer-kabel eine Übertragung von 100 Mbps. Werden Multi-Mode-Fasern verwendet, kann mit FDDI eine Entfernung von zweiKilometern zwischen Stationen liegen, beim Einsatz vonSingle-Mode-Fasern können wesentlich weitere Distanzenüberbrückt werden.

FDDI definiert zwei Arten optischer Fasern: Single-Mode undMulti-Mode. Ein Mode ist eine Lichtwelle, die in die Faser un-ter einem bestimmten Winkel eintritt. Bei Multi-Mode-Faserndienen LEDs als Lichtquelle, bei Single-Mode-Fasern wird imallgemeinen ein Laser verwendet.

In Multi-Mode-Fasern werden mehrere Modes (Lichtwellen)gleichzeitig übertragen. Da diese Wellen in verschiedenenWinkeln in die Faser eingestrahlt werden, treten sie am Endeder Faser zu unterschiedlichen Zeitpunkten wieder aus. DieseEigenschaft wird als modale Dispersion bezeichnet. Die mo-dale Dispersion begrenzt die Bandbreite und die Entfernung,die mit Multi-Mode-Fasern erreicht werden können. Daherwird diese Technik zumeist für die Gebäudeverkabelung oderüber kurze Distanzen verwendet.

In Single-Mode-Fasern kann immer nur eine Welle übertragenwerden, so daß hier die modale Dispersion keine Rolle spielt.Dies führt zu höherem Durchsatz und der Überwindung grö-ßerer Entfernungen. Darum wird diese Technik für die Ver-bindung zwischen weit auseinander liegenden Gebäuden ver-wendet.

Bild 8.2 zeigt eine Single-Mode-Faser mit einem Laser alsLichtquelle und eine Multi-Mode-Faser mit Leuchtdioden(LED) als Lichtquelle.


Single-Mode

LichtquelleLaser

Multi-Mode

LichtquelleLED

8.3 FDDI-Spezifikationen

FDDI spezifiziert den physischen Teil und den des Medium-Zugriffs des OSI-Referenzmodells. FDDI ist tatsächlich keineeinzelne Spezifikation, sondern setzt sich aus vier einzelnenSpezifikationen mit bestimmten Funktionen zusammen. Zu-sammen bieten diese Spezifikationen die Hochgeschwindig-keits-Verbindung zwischen den Protokollen der höherenSchichten, z.B. TCP/IP und IPX, und dem Medium, hier dieoptische Faser.

Bei diesen vier FDDI-Spezifikationen handelt es sich um dieMedia Access Control (MAC), das Protokoll der physischenSchicht (PHY), das Physical-Medium Dependent (PMD) unddas Station Management (SMT). Die MAC-Spezifikationdefiniert, wie auf das Medium zugegriffen wird, einschließlichFrame-Format, Token-Handling, Adressierung, Algorithmenfür die Berechnung der CRC-Werte (cyclic redundancy check)und der Fehlerbeseitigungsmechanismen. Die PHY-Spezifika-tion definiert z.B. die Kodierungsverfahren, die Taktung unddas Framing. Die PMD-Spezifikation definiert die Eigenschaf-ten des Übertragungsmediums, einschließlich Faser-Links, Lei-stungsstufen, Bit-Fehlerraten, optische Komponenten und An-schlüsse. Die SMT-Spezifikation definiert die FDDI-Stations-Konfiguration, die Ring-Konfiguration und die Ring-Steuer-funktionen, einschließlich Stationseinfügung und -entfernung,Initialisierung, Fehlereingrenzung und -behebung, Planungund statistische Erhebung.

Bild 8.2:VerschiedeneLichtquellen

für Single-Mode- und

Multi-Mode-Fasern


Hinsichtlich des OSI-Modells sind sich FDDI, IEEE 802.3Ethernet und IEEE 802.5 Token Ring ähnlich. FDDI dient derVerbindung der oberen OSI-Schichten mit ihren gängigen Pro-tokollen und dem Medium, das die Geräte vernetzt. Bild 8.3zeigt die vier FDDI-Spezifikationen in ihren gegenseitigen Be-ziehungen und der Beziehung zur IEEE-definierten SubschichtLogical-Link Control (LLC). Diese ist eine Komponente derSchicht 2 (MAC) im OSI-Referenzmodell.

Logical Link Control

Media Access Control

Protokoll der physikalischen Schicht

Medium der physikalischen Schicht

Stations- Management

FDDI-Standards

8.4 FDDI-Station-Attachment-Typen

Eine der kennzeichnenden Eigenschaften von FDDI ist dieMöglichkeit, FDDI-Geräte auf verschiedene Weise anzuschlie-ßen. FDDI definiert drei Gerätetypen: Single-Attachment-Stationen (SAS), Dual-Attachment-Stationen (DAS) und denKonzentrator.

Eine SAS ist über einen Konzentrator nur an einen Ring (denprimären) angeschlossen. Einer der Vorteile dieser Anschlußartliegt darin, daß SAS einfach abgehängt oder ausgeschaltetwerden können, ohne daß dies Auswirkungen auf den FDDI-Ring hat (Konzentratoren werden weiter unten behandelt).

Jede FDDI-DAS verfügt über zwei Schnittstellen, die als A undB gekennzeichnet sind. Damit wird die DAS an den FDDI-Doppelring angeschlossen. Die beiden Schnittstellen sind fürden primären und den sekundären Ring bestimmt. Im folgen-

Bild 8.3:FDDI-Spezifi-kationen ent-sprechen demhierarchischenOSI-Modell


den Abschnitt wird erläutert, warum DAS den FDDI-Ringbeeinflussen, wenn sie abgehängt oder ausgeschaltet werden.Bild 8.4 zeigt, wie die Schnittstellen A und B einer FDDI-DASan den primären und sekundären Ring angeschlossen sind.

Port A Port B

FDDI DAS

Secondär

Primär

Secondär

Primär

Ein FDDI-Konzentrator (auch als Dual-Attachment-Concen-trator [DAC] bezeichnet) ist der grundlegende Baustein einesFDDI-Netzwerks. Er ist direkt mit dem primären und demsekundären Ring verbunden und stellt sicher, daß ein Fehleroder das Ausschalten einer SAS-Station den Ring nicht unter-bricht. Diese Funktion des DAC ist besonders sinnvoll, wennPCs oder andere Geräte am FDDI-Netz betrieben werden, dieöfter ein- und ausgeschaltet werden. Bild 8.5 zeigt die An-schlüsse von SAS-, DAS-Stationen und des Konzentrators.

FDDI

Konzentrator

SAS SAS

DAS

Bild 8.4:FDDI-DASsind an den

primären undden sekundä-

ren Ring ange-schlossen

Bild 8.5:Ein Connectorist an den pri-

mären und densekundärenRing ange-

schlossen


8.5 FDDI-Fehlertoleranz

FDDI ist mit mehreren Fehlertoleranzfunktionen ausgestattet.Dazu zählen der doppelte FDDI-Ring, die Implementationeines optischen Bypass-Switches und die Unterstützung desDual-Homing, die FDDI zu einer unverwüstlichen Medium-technologie machen.

8.5.1 Doppelring

Das primäre Feature der FDDI-Fehlertoleranz ist der Doppel-ring. Falls eine Station im Doppelring ausfällt oder ausgeschal-tet oder ein Kabel beschädigt wird, wird aus dem Doppelringautomatisch ein einfacher Ring (da der Ringe doppelt rückge-koppelt ist). Dabei wird aus der Doppelring-Topologie eineEinfach-Ring-Topologie. Währenddessen können die Datenohne Performance-Verlust weiter übertragen werden. Bild 8.6und Bild 8.7 zeigen die Auswirkung dieser Ring-Umleitung beiFDDI.

Station 4

Station 3

Station 2

Station 1

Ring-Rückkopplung

Ring-Rückkopplung

B

A

MAC

B

A

MAC

BA

B A

MAC

AusgefalleneStation

Bild 8.6:Ein Stations-ausfall wirdüberbrückt


Station 4

Station 3

Station 2

Station 1

Ring-Rückkopplung

B

A

MAC

B

A

MAC

BA

B A

MAC

MAC

Ring-RückkopplungAusgefallenes

Kabel

Wenn eine einzelne Station ausfällt oder ausgeschaltet wird,wie in Bild 8.6 dargestellt, erfolgt die Rückkopplung des Dop-pelrings zu einem Ring in den beiden benachbarten Stationen.Der Netzwerk-Betrieb wird für die anderen Stationen auf-rechterhalten. Gleiches gilt, wenn ein Kabel beschädigt wurde,wie in Bild 8.7 dargestellt, so daß für alle Stationen der Netz-werk-Betrieb weiterläuft.

Dabei ist zu beachten, daß die Fehlertoleranz nur für ein Feh-lerereignis gilt. Treten zwei oder mehr Fehler gleichzeitig auf,zerfällt der FDDI-Ring in zwei oder mehr Segmente, die nichtmiteinander kommunizieren können.

8.5.2 Optischer Bypass-Switch

Ein optischer Bypass-Switch stellt einen unterbrechungsfreienDoppelringbetrieb sicher, falls ein Gerät im Doppelring aus-fällt. Deshalb wird der Bypass-Switch dazu eingesetzt, einerRing-Segmentierung vorzubeugen und ausgefallene Stationenvom Ring zu isolieren. Um diese Aufgabe zu erfüllen, ist derBypass-Switch mit optischen Spiegeln ausgestattet, die dasLicht bei normalem Betrieb aus dem Ring direkt an die DASleiten. Im Fehlerfall aber, z.B. durch Ausschalten der DAS,wird das Licht durch den Bypass-Switch im Ring weitergelei-

Bild 8.7:Ring-Umlei-tung wegen

Kabelstörung


tet, so daß es zu keiner Unterbrechung des Doppelringskommt. Der Vorteil dieser Funktion liegt auf der Hand. Bild8.8 zeigt die Funktion eines optischen Bypass-Switches in ei-nem FDDI-Netzwerk.

Station 4

Station 3

Station 2

Station 1

BA

B

A

B

A

Optischer Bypass-Switch»normale Konfiguration«

A

B

Station 4

Station 3

Station 2

BA

B

A

B

A

AusgefalleneStation

Station 1

Optischer Bypass-Switch»Bypass-Konfiguration«

Keine Rückkopplung des Rings

AB

8.5.3 Dual-Homing

Bei kritischen Geräten, wie Routern oder Mainframes, kanneine fehlertolerante Technik zum Einsatz kommen, die alsDual-Homing bezeichnet wird und mit ihrer Redundanz zursicheren Verfügbarkeit beiträgt. Beim Dual-Homing ist einkritisches Gerät an zwei Konzentratoren angeschlossen. Bild8.9 zeigt eine Dual-Homing-Konfiguration für Geräte wieFile-Server und Router.

Datei-Server

KonzentratorKonzentrator

Router

Bild 8.8:Ein optischerBypass-Switchsetzt einge-baute Spiegelein, um dieNetzverfüg-barkeit sicher-zustellen

Bild 8.9:Dual-Home-Konfgurationstellt Betriebsicher


Ein Anschlußpaar am Konzentrator wird zum aktiven, dasandere zum passiven Anschluß erklärt. Der passive Anschlußläuft im Sicherungsmodus, bis erkannt wird, daß der primäreAnschluß (oder der Konzentrator, an den er angeschlossen ist)ausgefallen ist. In diesem Fall wird der passive Anschluß auto-matisch aktiviert.

8.6 FDDI-Frame-Format

Das Frame-Format im FDDI ist dem bei Token Ring sehr ähn-lich. Dies ist einer der Bereiche, in denen sich FDDI sehr starkan frühere LAN-Technologien wie Token Ring anlehnt. FDDI-Frames können bis zu 4500 Byte lang sein. Bild 8.10 zeigt dasFrame-Format eines FDDI-Daten-Frames und -Tokens.

Daten FCSZieladresse Quelladresse Frame-Status

Start-Kennzeichen

Ende-Kennzeichen

Frame-Steuerung

Daten-Frame

Token

Start-Kennzeichen

Kopf Frame-Steuerung

Ende-Kennzeichen

Kopf

8.6.1 FDDI-Frame-Felder

Die folgenden Beschreibungen fassen die in Bild 8.10 gezeigtenFelder der FDDI-Daten-Frames und -Tokens zusammen.

− Kopf (Header) – Eindeutige Sequenz, die eine Station aufeinen eingehenden Frame vorbereitet.

− Start-Kennzeichen – Kennzeichnet den Anfang eines Frameanhand eines bestimmten Signalmusters, das sich vomrestlichen Frame unterscheidet.

− Frame-Steuerung – Gibt die Größe (und weitere Steuer-Informationen) der Adreßfelder an und ob der Frame asyn-chrone oder synchrone Daten enthält.

− Zieladresse – Enthält eine Unicast- (einzelne), Multicast-(Gruppe) oder Broadcast-Adresse (alle Stationen). Wie die

Bild 8.10:Der FDDI-

Frame ist demToken-Ring-

Frame sehrähnlich


Adressen bei Ethernet und Token Ring sind die Zieladres-sen bei FDDI 6 Byte lang.

− Quelladresse – Gibt die Station an, die den Frame gesendethat. Wie die Adressen bei Ethernet und Token Ring sindQuelladressen bei FDDI 6 Byte lang.

− Daten – Enthält entweder Daten für eine höhere Protokoll-schicht oder Steuerdaten.

− Frame-Prüfsumme (Frame Check Sequence [FCS]) – Vonder sendenden Station in Abhängigkeit vom Frame-Inhaltberechneter CRC-Wert (wie bei Ethernet und Token Ring).Von der empfangenden Station wird dieser Wert zum Ver-gleich erneut berechnet, um so festzustellen, ob die Datenfehlerfrei übertragen wurden. Falls ein Fehler auftrat, wirdder Frame verworfen.

− Ende-Kennzeichen – Enthält eindeutige Symbole, die keineDaten darstellen können, um das Ende eines Frame zukennzeichnen.

− Frame-Status – Dient der sendenden Station dazu, einenFehler zu erkennen und festzustellen, ob der Frame erkanntund von der empfangenden Station kopiert wurde.

8.7 Copper-Distributed Data Interface (CDDI)

Copper-Distributed Data Interface (CDDI) ist die Implemen-tierung von FDDI-Protokollen für Twisted-Pair-Kupferleitun-gen. Wie FDDI kann mit CDDI eine Übertragungsrate von100 Mbps erreicht werden, und es wird auch mit einem Dop-pelring gearbeitet. Bei CDDI beträgt die maximale Entfernungzwischen Desktop und Konzentrator ca. 100 Meter.

CDDI wurde vom X3T9.5-Komitee des ANSI definiert. Dieoffizielle Bezeichnung für den CDDI-Standard lautet: Twisted-Pair Physical Medium Dependent (TP-PMD). Oft wird aberauch von Twisted-Pair Distributed Data Interface (TP-DDI)gesprochen, in Anlehnung an den Begriff Fiber-DistributedData Interface (FDDI). CDDI entspricht den ANSI-Standardsfür die physische Schicht und die Mediumzugriffssteuerungs-schicht.


Im ANSI-Standard sind nur zwei Kabelarten für CDDI vorge-sehen: geschirmtes Twisted Pair (STP) und ungeschirmtes Twi-sted Pair (UTP). Die Impedanz bei STP-Kabeln beträgt 150Ohm und orientiert sich an den Spezifikationen EIA/TIA 568(IBM Type 1). UTP ist eine für die Datenübertragung geeig-nete Verkabelung (Kategorie 5), bei der acht ungeschirmteDrähte zu je zwei verdrillt in einen speziell entwickeltenKunststoff (isolierende Polymere) eingegossen werden, so daßsie der Spezifikation EIA/TIA 568B entspricht.

Bild 8.11 zeigt die Spezifikation CDDI TP-PMD im Verhältniszu den übrigen FDDI-Spezifikationen.

Spezifikation für CDDI

FDDI Media Access Control (MAC)

Twisted-Pair-Wire PMD

Single-Mode-Faser PMD

Multi-Mode-Faser PMD

FDDI-Stations-Management

(SMT)FDDI Physikalische Schicht (PHY)

Bild 8.11:Die Spezifika-tionen CDDI-TP-PMD und

FDDI beziehensich auf ve-

schiedeneStandards

9 Token Ring/IEEE 802.5

9.1 Hintergrund

Das Token-Ring-Netzwerk wurde ursprünglich in den 70erJahren von IBM entwickelt. Es ist immer noch die wichtigsteLAN-Technologie von IBM und steht in der Popularität anzweiter Stelle nach Ethernet/IEEE 802.3. Die SpezifikationIEEE 802.5 ist weitestgehend identisch und vollständig kom-patibel zum Token-Ring-Netzwerk von IBM. Die IEE-802.5-Spezifikation lehnt sich sehr stark an jene von Token Ring anund wird weiterhin den Entwicklungen des Token Ring ange-paßt. Wenn von Token Ring gesprochen wird, bezeichnet mandamit sowohl das IBM-Token-Ring-Netzwerk als auch einIEEE-802.4-Netzwerk. In diesem Kapitel werden beide Spezi-fikationen behandelt.

Token-Ring- und IEEE-802.5-Netzwerke sind grundsätzlichkompatibel, wenngleich die Spezifikationen ein wenig vonein-ander abweichen. Von IBM wird bei Token Ring ein Sternspezifiziert, dessen End-Stationen alle an ein Gerät, die sog.Multistation Access Unit (MSAU), angeschlossen werden.IEEE 802.5 spezifiziert im Gegensatz dazu keine Topologie,wenn auch virtuell alle IEEE-802.5-Implementationen auf ei-nem Stern basieren. Weitere Unterschiede existieren hinsicht-lich des Mediumtyps (IEEE 802.5 spezifiziert keinen Medium-typ vor, von IBM wird für Token Ring eine Twisted-Pair-Verkabelung angegeben) und der Feldgröße bei den Routing-Informationen. Bild 9.1 faßt die Spezifikationen IBM TokenRing und IEEE 802.5 zusammen.

KAPITEL 9Token Ring/IEEE 802.5


IEEE 802.5

250

Nicht spezifiziert

Nicht spezifiziert

Stern

Twisted pair

260 (shielded twisted pair)

72 (unshielded twisted pair)

4.16 MBit/s 4.16 MBit/s

IBM-Token- Ring-Netzwerk

Baseband

Token passing

DifferentialManchester

Token passing

DifferentialManchester

Baseband

Datenrate

Stationen/Segment

Topologie

Medien

Signalisierung

Zugriffsmethode

Kodierung

9.2 Physische Verbindungen

Die Stationen in einem IBM-Token-Ring-Netzwerk werden di-rekt an MSAUs angeschlossen, die wiederum zu einem großenRing miteinander verbunden werden können (siehe Bild 9.2).Die benachbarten MSAUs werden dabei mit Patch-Kabelnverbunden, während die Stationen mit Lobe-Kabeln an dieMSAUs angeschlossen werden. In die MSAUs integriert sindBypass-Relais, mit denen Stationen vom Ring abgekoppeltwerden können.

Bild 9.1:Wenngleich ineinigen Punk-

ten verschie-den, so sind die

NetzwerkeIBM Token

Ring und IEEE802.5 im

allgemeinenkompatibel

Kapitel 9 • Token Ring/IEEE 802.5 141

MSAU

Ringin 1 2 3 4 5 6 7 8

Ringout

Stationen

MSAU

Ringin 1 2 3 4 5 6 7 8

Ringout

Stationen

MSAU

Ringin 1 2 3 4 5 6 7 8

Ringout

Stationen

MSAU

Ringin 1 2 3 4 5 6 7 8

Ringout

Stationen

Lobe-Kabel

Patch-Kabel

9.3 Betrieb eines Token Ring

Token Ring und IEEE 802.5 sind zwei Beispiele für Token-Passing-Netzwerke (FDDI ist ein weiteres). Token-Passing-Netzwerke senden einen kleinen Frame, das sog. Token, durchdas Netzwerk. Wer im Besitz des Token ist, der darf Datenübertragen. Wenn ein Knoten das Token erhält, jedoch keineDaten zu übertragen hat, reicht er das Token an die nächsteEnd-Station weiter. Jede Station kann das Token eine be-stimmte Zeit lang behalten.

Wenn eine Station, die gerade das Token besitzt, Daten zuübertragen hat, behält sie das Token, verändert darin ein Bit,so daß aus dem Token eine Frame-Anfang-Sequenz wird,hängt die zu übertragenden Daten an und sendet diese Datenan die nächste Station im Ring. Solange dieser Informations-Frame im Ring kreist, wird kein Token weitergereicht (es seidenn, daß der Ring Early Token Release unterstützt), so daßandere Stationen, die Daten übertragen wollen, warten müs-sen. Daraus ergibt sich, daß es in Token-Ring-Netzwerkennicht zu Kollisionen kommen kann. Wenn die frühe Token-Freigabe unterstützt wird, kann ein neues Token gesendetwerden, wenn die Frame-Übertragung beendet wurde.

Bild 9.2:In einem IBM-Token-Ring-Netzwerk kön-nen MSAUsmiteinander zueinem großenRing verbun-den werden


Der Informations-Frame durchläuft so lange den Ring, bis erdie Zielstation erreicht. Diese kopiert die Information für dieweitere Verarbeitung. Der Informations-Frame wird im Ringweitergereicht, bis er die sendende Station wieder erreicht, vonder er gelöscht wird. Die sendende Station kann den zurück-kehrenden Frame prüfen, ob er von der Zielstation erkanntund kopiert wurde.

Anders als CSMA/CD-Netzwerke (z.B. Ethernet) sind Token-Passing-Netzwerke deterministisch, d.h., daß es möglich ist,die maximale Zeitspanne zu berechnen, bis zu der jede End-Station einmal die Gelegenheit hatte Daten zu übertragen.Diese Funktion und viele Zuverlässigkeitsfunktionen machenToken-Ring-Netzwerke zum idealen Netz für Anwendungen,die eine vorhersagbare Verzögerung und robusten Netzwerk-betrieb benötigen. Auf diese Funktionen wird weiter unten imAbschnitt »Mechanismen des Ausfall-Managements« nähereingegangen. Ein Beispiel für solche Anwendungen stellt dieFertigungsautomatisierung dar.

9.4 Prioritäten-System

Von Token-Ring-Netzwerken wird ein ausgeklügeltes Prioritä-ten-System verwendet, das es bestimmten benutzerdefinierten,Stationen mit hoher Priorität erlaubt, das Netzwerk häufigerzu benutzen. Token-Ring-Frames enthalten zwei Felder, die diePriorität steuern: das Prioritätsfeld und das Reservierungsfeld.

Nur Stationen, deren Priorität genauso hoch oder höher ist alsdie im Token angegebene, können das Token halten. Nachdemdas Token gehalten und in einen Informations-Frame geändertwurde, können nur Stationen mit höherer Priorität als die ge-rade übertragende Station das Token für den nächsten Durch-lauf durch das Netzwerk für sich reservieren. Beim Generierendes nächsten Token wird in diesem eine höhere Prioritätgesetzt als die der reservierenden Station. Stationen, die diePriorität des Token erhöht haben, müssen nach Beendigungihrer Datenübertragung die Priorität wieder auf die Stufesetzen, die davor galt.


9.5 Mechanismen des Ausfall-Managements

Token-Ring-Netzwerke arbeiten mit mehreren Mechanismenfür die Erkennung und Kompensation von Netzwerk-Ausfäl-len. So wird z.B. eine Station in einem Token-Ring-Netzwerkals aktive Überwachungsstation (active monitor) bestimmt.Potentiell kommt dafür jede Station des Netzwerks in Frage.Diese Station ist die zentrale Quelle für Timing-Informationen,die für alle Stationen im Ring gelten. Außerdem führt dieseStation verschiedene Wartungsfunktionen im Ring aus, wiez.B. das Entfernen von endlos kreisenden Frames, die entste-hen können, wenn ein sendendes Gerät ausfällt. Eine solcheSituation kann dazu führen, daß andere Stationen mit derÜbertragung ihrer Frames warten und so das Netzwerk blok-kiert wird. Die aktive Überwachungsstation erkennt solcheFrames, entfernt sie vom Ring und generiert ein neues Token.

Die Stern-Topologie des IBM-Token-Ring-Netzwerks bieteteine umfassende Netzwerk-Zuverlässigkeit. Da sämtliche In-formationen von den aktiven MSAUs gelesen werden, könnendiese so programmiert werden, daß sie Problemlagen erkennenund ggf. einzelne Stationen vom Ring nehmen können.

Ein als Beaconing bezeichneter Algorithmus in Token Ring er-kennt bestimmte Netzwerk-Fehler und versucht, diese zu be-heben. Immer wenn eine Station einen schwerwiegenden Feh-ler erkennt (z.B. eine unterbrochene Leitung), sendet sie einenBeacon-Frame, der eine ausgefallene Domäne definiert. DieseDomäne enthält Angaben zur Station, die den Fehler meldet,deren nächstgelegenen aktiven Nachbarn (nearest active up-stream neighbor – NAUN) und alle anderen dazwischen. DasBeaconing startet einen Prozeß, der als Autorekonfigurationbezeichnet wird. Dabei führen die Knoten in der fehlerhaftenDomäne automatisch Diagnosen durch, um das Netzwerk umden ausgefallenen Bereich herum zu rekonfigurieren. EineMSAU kann diese Fehlerbehebung durch elektrische Rekonfi-guration erreichen.

9.6 Frame-Format

Token Ring und IEEE 802.5 unterstützen zwei grundlegendeFrame-Typen: Tokens und Daten-/Befehls-Frames. Tokens sind


drei Byte lang und beginnen mit einem Start-Kennzeichen, esfolgen ein Zugriffssteuerungs-Byte und ein Ende-Kennzeichen.Daten-/Befehls-Frames variieren in der Größe, wobei diesevom Umfang des Datenfelds abhängt. Daten-Frames enthaltenInformationen für die Protokolle der höheren Schichten,während Befehls-Frames nur Steuerinformationen enthalten.Beide Formate sind in Bild 9.3 dargestellt.

Frame-Steuerung

Quelladresse Daten FCS

Feldlänge, in Byte

11 6 01

Zieladresse

6 4 1 1

Data/Command Frame

≥

Anfangs-kennzeichen

Token

Anfangs-kennzeichen

Zugriff-steuerung

Ende-kennzeichen

Frame-Status

Ende-kennzeichen

Zugriff-steuerung

9.6.1 Felder des Token-Frames

Die Felder des Token-Frame, wie in Bild 9.3 dargestellt, wer-den im folgenden kurz erläutert:

− Anfangs-Kennzeichen – Informiert jede Station, daß einToken eingegangen ist (oder ein Daten-/Befehls-Frame).Dieses Feld enthält Signale, die dieses Byte von allen ande-ren im Frame unterscheidet, indem es gegen das Kodie-rungsschema für den restlichen Frame verstößt.

− Zugriffssteuerungs-Byte – Enthält das Prioritätsfeld (diedrei höherwertigen Bit) und das Reservierungsfeld (die dreiniederwertigen Bit), ein Token-Bit (zur Unterscheidungeines Token von einem Daten-/Befehls-Frame) und einÜberwachungsbit (das von der aktiven Überwachungs-station dazu verwendet wird, einen endlos kreisendenFrame zu erkennen).

− Ende-Kennzeichen – Kennzeichnet das Ende eines Tokenoder Daten-/Befehls-Frame. Außerdem enthält dieses FeldBits, die einen beschädigten Frame oder den Frame alsletzten in einer logischen Folge kennzeichnen.

Bild 9.3:IEEE 802.5und Token

Ring spezifizie-ren Tokens undDaten-/Befehls-

Frames


9.6.2 Felder des Daten-/Befehls-Frames

Daten-/Befehls-Frames enthalten auch die drei vorgenanntenFelder eines Token-Frame. Die weiteren Felder eines Daten-/Befehls-Frame, wie in Bild 9.3 dargestellt, werden im folgen-den kurz erläutert:

− Anfangs-Kennzeichen – Informiert jede Station, daß einToken eingegangen ist (oder ein Daten-/Befehls-Frame).Dieses Feld enthält Signale, die dieses Byte von allen ande-ren im Frame unterscheidet, indem es gegen das Kodie-rungsschema für den restlichen Frame verstößt.

− Zugriffssteuerungs-Byte – Enthält das Prioritätsfeld (die dreihöherwertigen Bit) und das Reservierungsfeld (die drei nie-derwertigen Bit), ein Token-Bit (zur Unterscheidung einesToken von einem Daten-/Befehls-Frame) und ein Überwa-chungsbit (wird von der aktiven Überwachungsstation ver-wendet, um einen endlos kreisenden Frame zu erkennen).

− Frame-Steuer-Byte – Gibt an, ob der Frame Daten oderSteuerinformationen enthält. Handelt es sich um einenSteuer-Frame, gibt dieses Byte an, um welche Art derSteuerinformation es sich handelt.

− Ziel- und Quelladresse – Zwei jeweils 6 Byte lange Feldergeben die Quell- und Zieladresse an.

− Daten – Die Länge dieses Felds ist begrenzt durch die Ring-Token-Verweildauer, die definiert, wie lange eine Stationdas Token halten darf.

− Frame-Prüfsumme (FCS) – Von der Quellstation durch Be-rechnung über den Frame-Inhalt erzeugter Wert. Die Ziel-station führt die gleiche Berechnung aus, um festzustellen,ob die Daten bei der Übertragung beschädigt wurden. Istdies der Fall, wird der Frame entwertet.

− Ende-Kennzeichen – Kennzeichnet das Ende eines Tokenoder Daten-/Befehls-Frame. Außerdem enthält dieses FeldBits, die einen beschädigten Frame oder den Frame alsletzten in einer logischen Folge kennzeichnen.

− Frame-Status – Dieses Feld ist ein Byte lang und beendeteinen Daten-/Befehls-Frame. Dieses Feld enthält die beidenKennzeichnungen für die Adressenerkennung und dafür,daß der Frame kopiert wurde.

Kapitel 10: Frame RelayKapitel 11: High-Speed Serial InterfaceKapitel 12: Integrated Services Digital Network (ISDN)Kapitel 13: Point-to-Point ProtocolKapitel 14: Switched Multimegabit Data Service (SMDS)Kapitel 15: ADSL – Asymmetric Digital Subscriber LineKapitel 16: Synchronous Data-Link Control und DerivateKapitel 17: X.25

Teil 3: WAN-Technologien

Teil 3, »WAN-Technologien«, faßt die Spezifikationen undoperationalen Eigenschaften der Schlüsseltechnologien undProtokolle für WAN (wide-area network) zusammen. In deneinzelnen Kapiteln werden folgende Themen behandelt:

Frame Relay – In diesem Kapitel werden der Betrieb und dieEigenschaften dieser Hochgeschwindigkeitstechnologie fürWAN beschrieben.

High-Speed Serial Interface (HSSI) – Hier wird HSSI definiertund der Einsatz der HSSI-Technologie in T3-WAN-Implemen-tationen zusammengefaßt.

Integrated Services Digital Network (ISDN) – Hier wirdISDN definiert und der Einsatz von ISDN als eine WAN-Tech-nologie zusammengefaßt.

Point-to-Point Protocol (PPP) – Hier wird PPP definiert undder Einsatz von PPP für den Fernzugriff in WAN-Umgebungenbeschrieben.

Switched Multimegabit Data Service (SMDS) – In diesemKapitel werden der Betrieb und die Eigenschaften von SMDSbeschrieben. Bei SMDS handelt es sich um eine Einwahl-Tech-nologie für WAN mit hoher Bandbreite.

Asymmetric Digital Subscriber Line (ADSL) – In diesem Kapi-tel werden der Betrieb und die Eigenschaften von ADSL be-schrieben. Bei ADSL handelt es sich um eine Hochgeschwin-digkeitsimplementation für WAN.

TEIL 3WAN-Technologien


Synchronous Data-Link Control and Derivatives (SDLC) – Indiesem Kapitel geht es um die Rolle von SDLC als ein Proto-koll der Verbindungssicherungsschicht in IBM-SNA-Netzenund einen Überblick davon abgeleiteter Protokolle.

X.25 – Dieses Kapitel behandelt den Betrieb und die Eigen-schaften von X.25.

10 Frame Relay

10.1 Hintergrund

Frame Relay ist ein Hochgeschwindigkeitsprotokoll für WAN,das sich auf die physische Schicht und die Sicherungsschichtdes OSI-Referenzmodells bezieht. Ursprünglich wurde FrameRelay für den Einsatz unter ISDN (Integrated Services DigitalNetwork) entwickelt. Heute wird es aber auch von vielenanderen Netzwerk-Schnittstellen verwendet. In diesem Kapitelgeht es hauptsächlich um die Frame-Relay-Spezifikationenund -Anwendungen im Zusammenhang mit WAN-Services.

Frame Relay ist ein Beispiel für eine paketvermittelte Techno-logie. Paketvermittelte Netzwerke ermöglichen es den End-Stationen, das Netzwerk-Medium und die verfügbare Band-breite dynamisch gemeinsam zu nutzen. Dabei werden Paketevariabler Länge versendet, so daß die Übertragung wesentlicheffizienter und flexibler erfolgt. Diese Pakete werden dann vonden verschiedenen Netzwerk-Segmenten weitervermittelt, bissie ihr Ziel erreichen. Statistische Multiplex-Techniken steuernden Netzwerk-Zugriff in paketvermittelten Netzen. Der Vor-teil dieser Technik besteht darin, daß die Bandbreite flexiblerund effizienter genutzt wird. Bei den heute gängigsten LANs,wie Ethernet und Token Ring, handelt es sich um paketvermit-telte Netzwerke.

Frame Relay wird oft als eine modernisierte Version von X.25bezeichnet, ohne einige robuste Eigenschaften von X.25, wieetwa das Windowing und die Wiederholung der letzten Daten.

KAPITEL 10Frame Relay


Dies hat seine Ursache darin, daß Frame Relay über WAN-Facilities betrieben wird, die wesentlich zuverlässigere Verbin-dungsservices und eine verbesserte Zuverlässigkeit bieten, alsdies in den späten 70er und frühen 80er Jahren bei Plattfor-men der Fall war, von denen X.25 für WANs unterstütztwurde. Wie bereits erwähnt, ist Frame Relay eine Protokoll-familie, die sich strikt auf die Schicht 2 bezieht, während X.25auch für die Schicht 3 (Vermittlungsschicht) Services anbietet.Deshalb ist mit Frame Relay eine höhere Performance undgrößere Übertragungseffektivität als mit X.25 möglich. Waswiederum der Grund ist, daß Frame Relay so gut für aktuelleWAN-Anwendungen (z.B. LAN Interconnection) geeignet ist.

10.1.1 Frame-Relay-Standardisierung

Die ersten Vorschläge für die Standardisierung von FrameRelay wurden dem Consultative Committee on InternationalTelephone and Telegraph (CCITT) 1984 unterbreitet. Auf-grund der fehlenden Interoperabilität und Standardisierungkam es zu keinem verstärkten Einsatz von Frame Relay bis indie späten 80er Jahre.

Zu wesentlichen Schritten in der Weiterentwicklung vonFrame Relay kam es 1990, als Cisco, Digital Equipment,Northern Telecom und StrataCom ein Konsortium bildeten,das sich Frame Relay auf die Fahnen geschrieben hatte. Vondiesem Konsortium wurde eine Spezifikation entworfen, diedem grundlegenden Frame-Relay-Protokoll entsprach undvom CCITT diskutiert wurde. Das CCITT erweiterte das Pro-tokoll mit Funktionen, die zusätzliche Eigenschaften fürkomplexe Internetworking-Umgebungen boten. Diese Frame-Relay-Erweiterungen werden zusammenfassend als LocalManagement Interface (LMI) bezeichnet.

Seit von dem Konsortium die Spezifikation entwickelt undveröffentlicht wurde, haben viele Anbieter dieser erweitertenFrame-Relay-Definition ihre Unterstützung zugesagt. ANSIund CCITT haben in der Zwischenzeit ihre eigenen Variantender ursprünglichen LMI-Spezifikation standardisiert. Diesekommen heute weit häufiger zum Einsatz als die Original-Version.

Kapitel 10 • Frame Relay 151

Auf internationaler Ebene wurde Frame Relay von der Inter-national Telecommunications Union – TelecommunicationsSector (ITU-T) standardisiert. In den USA ist Frame Relay einvom American National Standards Institute (ANSI) festgeleg-ter Standard.

10.2 Frame-Relay-Geräte

An ein Frame-Relay-WAN angeschlossene Geräte lassen sichin zwei große Kategorien unterteilen: Data Terminal Equip-ment (DTE – Datenendeinrichtung [DEE]) und Data Circuit-Terminating Equipment (DCE – Datenübertragungseinrich-tung [DÜE]). Bei DTEs handelt es sich im allgemeinen umEndeinrichtungen für ein bestimmtes Netzwerk. Die DTEssind normalerweise in den Räumlichkeiten des Kunden aufge-stellt, der sie ggf. gekauft hat. DTE-Geräte sind z.B. Terminals,Personalcomputer, Router und Bridges.

DCEs sind Internetworking-Geräte im Eigentum des Dienst-anbieters. DCE-Geräte werden zur Taktung und zum Swit-ching in einem Netzwerk eingesetzt. Dabei handelt es sich umdie Geräte, die die eigentliche Datenübertragung in einemWAN bewerkstelligen. In den meisten Fällen werden diesPaket-Switches sein. Bild 10.1 zeigt die Beziehung zwischendiesen beiden Gerätekategorien.

DTE DTE

Personal-computer

Netzwerk-Host

Terminal

DTE

Packet Switch

DCE

Frame Relay WAN

Die Verbindung zwischen DTE- und DCE-Gerät wird sowohlvon Komponenten der physischen Schicht als auch der Siche-rungsschicht getragen. Die physische Komponente spezifiziert

Bild 10.1:DCEs stehenim allgemeinenin WANs, dievon Dienst-anbieternbetriebenwerden


die mechanische, elektrische, funktionale und prozeduraleSeite einer Verbindung zwischen Geräten. Eine der gebräuch-lichsten Schnittstellen-Spezifikationen der physischen Schichtist der Recommended Standard (RS)-232. Die Komponenteder Sicherungsschicht definiert das Protokoll, das die Verbin-dung zwischen einem DTE-Gerät (z.B. einem Router) und ei-nem DCE-Gerät (z.B. einem Switch) herstellt. Dieses Kapitelbeschreibt eine oft in der WAN-Technologie eingesetzte Proto-koll-Spezifikation – das Frame-Relay-Protokoll.

10.3 Frame Relay Virtual Circuits

Frame Relay bietet verbindungsorientierte Sicherungsschicht-Kommunikation. Dies bedeutet, daß zwischen zwei Geräteneine definierte Kommunikation besteht, und daß diese Verbin-dungen einer Verbindungskennzeichnung zugeordnet sind.Dieser Service wird implementiert durch den Einsatz einesFrame Relay Virtual Circuit. Dieser stellt eine logische Verbin-dung dar, die zwischen zwei Datenendeinrichtungen(DTE/DEE) über ein paketvermitteltes Frame-Relay-Netzwerkerzeugt wurde.

Virtual Circuits (virtuelle Verbindungen) bieten einen bi-di-rektionalen Kommunikationspfad von einem DTE-Gerät zueinem anderen. Sie sind eindeutig gekennzeichnet anhand ei-nes Data-Link Connection Identifier (DLCI). Mehrere virtuelleVerbindungen können für die Übertragung im Netzwerk übereine physische Verbindung gemultiplext werden. Diese Eigen-schaft kann genutzt werden, um die Ausstattung und dieNetzwerk-Komplexität zu reduzieren, wenn mehrere DTE-Geräte verbunden werden sollen.

Eine virtuelle Verbindung kann über eine beliebige Anzahl da-zwischengeschalteter DCE-Geräte (Swichtes) im Frame RelayPSN geleitet werden.

Virtuelle Frame-Relay-Verbindungen lassen sich in zwei Kate-gorien unterteilen: Switched Virtual Circuits (SVC – gewähltevirtuelle Verbindungen [GVV]) und Permanent VirtualCircuits (PVC – feste virtuelle Verbindungen [FVV]).


10.3.1 Switched Virtual Circuits (SVC/GVV)

Switched Virtual Circuits (SVCs – gewählte virtuelle Verbin-dungen [GVV]) sind temporäre Verbindungen, die eingesetztwerden, wenn zwischen DTE-Geräten in einem Frame-Relay-Netzwerk nur gelegentliche Datenübertragungen stattfinden.Eine Kommunikationssitzung über einen SVC hat folgendeZustände:

− Anruf (Call Setup) – Die virtuelle Verbindung zwischen denbeiden Frame-Relay-DTE-Geräten wird aufgebaut.

− Datenübertragung – Daten werden zwischen den DTE-Geräten über die virtuelle Verbindung übertragen.

− Ruhezustand – Die Verbindung zwischen den DTE-Gerätenist noch aktiv, es werden aber keine Daten übertragen.Wenn ein SVC eine bestimmte Zeit lang in diesem Ruhezu-stand bleibt, kann die physische Verbindung unterbrochenwerden.

− Verbindungsbeendigung – Die virtuelle Verbindung zwi-schen den DTE-Geräten wird beendet.

Nachdem die virtuelle Verbindung beendet wurde, muß füreine weitere Datenübertragung zwischen den DTE-Gerätender SVC erneut aufgebaut werden. Es wird erwartet, daßSVCs mit den gleichen Signalisierungsprotokollen wie unterISDN aufgebaut, verwaltet und beendet werden. Es gibt je-doch Hersteller von Frame-Relay-DCE-Geräten, die gewähltevirtuelle Verbindungen unterstützen. In heutigen Frame-Relay-Netzwerken werden deren Produkte aber nur selten eingesetzt.

10.3.2 Permanent Virtual Circuits (PVC/FVV)

Permanent Virtual Circuits (PVCs – feste virtuelle Verbindun-gen [FVV]) sind fest eingerichtete Verbindungen, die eingesetztwerden, wenn über ein Frame-Relay-Netzwerk zwischen zweiDTE-Geräten häufige und möglichst fehlerfreie Datenübertra-gungen erfolgen sollen. Für die Kommunikation über einenPVC sind der Anruf und die Verbindungsbeendigung wie beieinem SVC nicht erforderlich. PVCs befinden sich immer ineinem der beiden folgenden operationalen Zustände:


− Datenübertragung – Daten werden über die virtuelle Ver-bindung zwischen den DTE-Geräten übertragen.

− Ruhezustand – Die Verbindung zwischen den DTE-Gerätenist aktiv, es werden jedoch keine Daten übertragen. Andersals bei SVCs werden PVCs unter keinen Umständen been-det, auch nicht im Ruhezustand.

DTE-Geräte können jederzeit mit der Datenübertragung be-ginnen, da die Verbindung ständig aufgebaut bleibt.

10.3.3 Data-Link Connection Identifier (DLCI)

Virtuelle Frame-Relay-Verbindungen sind gekennzeichnetdurch Data-Link Connection Identifiers (DLCIs). Normaler-weise nimmt der Dienstanbieter (z.B. die Telefongesellschaft)des Frame-Relay-Netzwerks die Zuordnung der DLCI-Wertevor. Frame-Relay-DLCIs sind lokal eindeutig, nicht jedoch ineinem Frame-Relay-WAN. So können z.B. zwei über eine vir-tuelle Verbindung kommunizierende DTE-Geräte verschiedeneDLCI-Werte verwenden, um die gleiche Verbindung zu ver-wenden. Bild 10.2 zeigt, wie einer einzelnen virtuellen Verbin-dung am jeweiligen Ende verschiedene DLCI-Werte zugeord-net werden.

Virtuelle Verbindung

Frame-Relay-

Netzwerk DTEDTE

DLCIDLCI

12

62

89

22

36

62

10.4 Congestion-Control-Mechanismen

Frame Relay reduziert den Netzwerk-Overhead, indem einfa-che Stau-Erkennungsmechanismen anstelle expliziter Fluß-steuerung für jede virtuelle Verbindung implementiert werden.Da Frame Relay auf zuverlässigen Netzwerk-Medien imple-mentiert wird, muß auf die Datenintegrität nicht verzichtet

Bild 10.2:Einer virtuellen

Frame-Relay-Verbindungkönnen an

jedem EndeverschiedeneDLCI-Werte

zugeordnetwerden


werden, weil die Flußsteuerung den Protokollen höhererSchichten überlassen werden kann. Frame Relay implemen-tiert zwei Stau-Erkennungsmechanismen:

− Forward-explicit Congestion Notification (FECN)

− Backward-Explicit Congestion Notification (BECN)

FECN und BECN werden durch ein einzelnes Bit gesteuert,das sich im Frame-Header befindet. Der Frame-Header beiFrame Relay enthält ein DE-Bit (DE – Discard Eligibility) ,mit dem weniger wichtiger Datenverkehr gekennzeichnetwird, der in Stau-Situationen nicht weiterübertragen wird.

Das FECN-Bit ist Teil des Adreßfelds im Frame-Header. DerFECN-Mechanismus wird gestartet, wenn ein DTE-GerätFrame-Relay-Frames in das Netzwerk sendet. Ist ein Netzwerküberlastet, setzen DCE-Geräte (Switches) den Wert des FECN-Bit eines Frame auf 1. Wenn der Frame sein Ziel erreicht, zeigtdas Adreßfeld (mit dem gesetzten FECN-Bit) an, daß derFrame auf der Strecke zwischen Quelle und Ziel in einen Staugeraten war. Das DTE-Gerät kann diese Information an dasProtokoll einer höheren Schicht zur Bearbeitung weitergeben.Abhängig von der Implementation wird dann die Flußsteue-rung aktiviert, oder die Meldung wird ignoriert.

Das BECN-Bit ist ein Teil des Adreßfelds im Frame-Header.DCE-Geräte setzen das BECN-Bit eines Frame auf 1, wenndieser in die entgegengesetzte Richtung übertragen wird, ausder Frames kommen, deren FECN-Bit gesetzt ist. Damit wirddas empfangende DTE-Gerät darüber informiert, daß ein be-stimmter Pfad im Netzwerk überlastet ist. Das DTE-Gerätkann diese Information an das Protokoll einer höheren Schichtzur Bearbeitung weitergeben. Abhängig von der Implementa-tion wird dann die Flußkontrolle aktiviert, oder die Meldungwird ignoriert.

10.4.1 Frame Relay Discard Eligibility (DE)

Das Discard Eligibility-Bit (DE) wird dazu verwendet, einenweniger wichtigen Frame zu kennzeichnen. Das DE-Bit ist Teildes Adreßfelds im Frame-Header.


DTE-Geräte können den Wert des DE-Bits eines Frame auf 1setzen, um den Frame als weniger wichtig zu kennzeichnen.Bei einer Überlastung des Netzwerkes leiten DCE-GeräteFrames mit gesetztem DE-Bit nicht weiter, bevor andereFrames nicht mehr bearbeitet werden. So wird die Wahr-scheinlichkeit reduziert, daß kritische Daten in Phasen derÜberlastung von DCE-Geräten nicht mehr bearbeitet werden.

10.4.2 Frame-Relay-Fehlererkennung

Frame Relay verwendet einen üblichen Fehlererkennungsme-chanismus, der als Cyclic Redundancy Check (CRC) bekanntist. Der CRC vergleicht zwei berechnete Werte, um festzustel-len, ob bei der Übertragung zwischen Quelle und Ziel einFehler aufgetreten ist. Frame Relay reduziert den Netzwerk-Overhead durch die Implementation einer Fehlererkennungstatt einer Fehlerkorrektur.

Da Frame Relay auf zuverlässigen Netzwerk-Medien imple-mentiert wird, muß auf die Daten-Integrität nicht verzichtetwerden, weil die Fehlerkorrektur den Protokollen höhererSchichten überlassen werden kann.

10.5 Frame Relay Local Management Interface(LMI)

Das Local Management Interface (LMI) ist ein Satz von Er-weiterungen der grundlegenden Frame-Relay-Spezifikation.Das LMI wurde 1990 von Cisco Systems, StrataCom, Nor-thern Telecom und Digital Equipment Corporation entwickelt.Es bietet eine Vielzahl an Eigenschaften (als Erweiterungenbezeichnet) für die Verwaltung komplexer Internetworks. Zuden wichtigen Frame-Relay-LMI-Erweiterungen gehören dieglobale Adressierung, Statusmeldungen virtueller Verbindun-gen und Multicasting.

Aufgrund der globalen Adressierungserweiterung des LMIsind die von Frame Relay für Data-Link Connection Identifier(DLCI) verwendeten Werte nicht nur lokal, sondern globaleindeutig. DLCI-Werte werden so zu DTE-Adressen, die in


einem Frame-Relay-WAN eindeutig sind. Mit der globalenAdressierungserweiterung wächst die Funktionalität und wirddie Verwaltung eines Frame-Relay-Internetwork verbessert. Sokönnen z.B. einzelne Netzwerk-Schnittstellen und die daranangeschlossenen Endknoten anhand einer Standard-Adreßauf-lösung und Suchtechnik identifiziert werden. Außerdem stelltsich für die Router das gesamte Frame-Relay-Netzwerk als eintypisches LAN dar.

Frame-Relay-DTE- und -DCE-Geräte kommunizieren undsynchronisieren sich über Statusmeldungen virtueller LMI-Verbindungen. Diese Meldungen dienen dazu, regelmäßig überden Status eines PVC zu berichten, um Daten nicht in»Schwarze Löcher« (d.h. über längst beendete PVCs) zu sen-den.

Mit der LMI-Multicast-Erweiterung können Multicast-Grup-pen eingerichtet werden. Multicasting hilft Ihnen, Bandbreitezu sparen, indem Routing-Aktualisierungen und Adreßauflö-sungsmeldungen nur an bestimmte Router-Gruppen gesendetwerden. Die Erweiterung überträgt in Aktualisierungsmeldun-gen auch Statusberichte von Multicast-Gruppen.

10.6 Frame-Relay-Netzwerk-Implementation

Für eine übliche, private Implementation eines Frame-Relay-Netzwerks müssen Sie lediglich einen T1-Multiplexer mit einerFrame-Relay- und einer anderen Schnittstelle ausstatten. DerFrame-Relay-Datenverkehr wird über die Frame-Relay-Schnittstelle gesendet und auf das Netzwerk gebracht. Der an-dere Datenverkehr geht an die entsprechende Anwendungoder einen geeigneten Service, z.B. eine Nebenstellenanlageoder eine Video-Telekonferenz-Anwendung.

Zu einem typischen Frame-Relay-Netzwerk gehören mehrereDTE-Geräte, z.B. Router, die an die Remote-Ports eines Mul-tiplexer über herkömmliche Punkt-zu-Punkt-Services wie T1,Fractional T1 oder 56K-Verbindungen angeschlossen sind. EinBeispiel für ein einfaches Frame-Relay-Netzwerk zeigt Bild10.3.


Router

T1 MUX

T1 MUX

PBX

TokenRing

Video-/Telekonferenz

Ethernet

Frame-Relay-Schnittstelle

Non-Frame-Relay-Schnittstelle

Frame-Relay-Schnittstelle

Non-Frame-Relay-Schnittstelle

Ethernet

TokenRing

WAN

Die meisten der heute betriebenen Frame-Relay-Netzwerkewerden von Dienstanbietern unterhalten, die damit ihrenKunden Übertragungsdienste anbieten, einen sogenannten öf-fentlichen Frame-Relay-Service. Frame Relay findet sich so-wohl in den Netzwerken öffentlicher Anbieter als auch in pri-vaten Unternehmensnetzen. Im folgenden Abschnitt werdendie zwei Möglichkeiten für den Einsatz von Frame Relaynäher beleuchtet.

10.6.1 Öffentliche Netzwerke

In öffentlichen Frame-Relay-Netzwerken befindet sich dieFrame-Relay-Switching-Ausrüstung in der zentralen Nieder-lassung eines Telekommunikationsanbieters. Die Kosten fürden Kunden richten sich nach der Nutzung des Netzwerks,wobei der Anbieter die Administration und Wartung der Aus-stattung und Services übernimmt.

Meistens bleiben die DCE-Geräte auch im Eigentum des Tele-kommunikationsanbieters, der dem Kunden damit einen wei-teren Service anbietet.

Bild 10.3:Ein einfachesFrame-Relay-

Netzwerk ver-bindet mehrereGeräte über ein

WAN mit ver-schiedenen

Services


Die meisten der heute betriebenen Frame-Relay-Netzwerkewerden von öffentlichen Anbietern unterhalten.

10.6.2 Private Unternehmensnetze

Immer häufiger unterhalten weltweite Unternehmen eigeneFrame-Relay-Netze. Bei solchen privaten Frame-Relay-Netz-werken ist das Unternehmen (eine private Firma) selbst für dieAdministration und Wartung verantwortlich. Die gesamteAusstattung, einschließlich der Switching-Geräte, gehört denKunden.

10.7 Frame-Formate des Frame-Relay

Um den gesamten Funktionsumfang von Frame Relay zu ver-stehen, ist es hilfreich, sich mit der Struktur des Frame-Relay-Frame vertraut zu machen. Bild 10.7 zeigt das Basisformateines Frame, Bild 10.9 dessen LMI-Version.

Flags markieren den Frame-Anfang und das Frame-Ende. DerFrame-Relay-Frame besteht aus drei Hauptkomponenten:Header- und Adreßbereich, Benutzerdaten-Bereich und Frame-Prüfsumme (FCS – Frame Check Sequence). Der Adreßbereichist 2 Byte lang, wobei 10 Bit für die Verbindungskennzeich-nung (circuit identifier) und 6 Bit für das Stau-Managementreserviert sind. Die Kennzeichnung wird gemeinhin als DLCI(Data-Link Connection Identifier) bezeichnet. Im folgendenAbschnitt wird näher auf diese Komponenten eingegangen.

10.7.1 Standard-Frame des Frame Relay

Die Standard-Frames bei Frame Relay bestehen aus den inBild 10.4 gezeigten Feldern.

8

Feldlänge in Byte

16 Variabel 16 8

DatenFlags Adresse FCS Flags

Bild 10.4:Ein Frame desRelay-Framebesteht ausfünf Feldern


Die folgenden Beschreibungen geben einen kurzen Überblickzu diesen grundlegenden Frame-Feldern.

− Flags – Begrenzen Anfang und Ende eines Frame. Der Wertdieses Felds ist immer gleich. Er kann hexadezimal als 7Eoder binär als 01111110 dargestellt werden.

− Adresse – Dieses Feld enthält folgende Informationen:

− DLCI: Der 10 Bit lange DLCI ist die Essenz des Frame-Relay-Headers. Dieser Wert gibt die virtuelle Verbin-dung zwischen einem DTE-Gerät und einem Switchwieder. Jede virtuelle Verbindung, die über einen physi-schen Kanal gemultiplext wird, wird mit einem eindeuti-gen DLCI dargestellt. Die DLCI-Werte haben nur lokaleBedeutung, d.h., daß sie nur für den physischen Kanaleindeutig sind. Deshalb können Geräte am anderenEnde der Verbindung einen anderen DLCI-Wert für diegleiche virtuelle Verbindung benutzen.

− Erweiterte Adresse (EA): Die EA dient dazu anzugeben,ob das Byte, in dem der EA-Wert 1 ist, das letzte Adreß-feld ist. Wenn der Wert 1 ist, ist das aktuelle Byte dasletzte DLCI-Oktett. Zur Zeit verwenden Frame-Relay-Implementationen nur einen zwei Oktett langen DLCI,aber auf die beschriebene Weise ist sichergestellt, daß inZukunft auch längere DLCIs genutzt werden können.Jeweils das achte Bit in einem Byte des Adreßfelds wirdfür die EA verwendet.

− C/R: Das C/R-Bit folgt dem höherwertigen DLCI-Byteim Adreßfeld. Zur Zeit ist dieses Bit noch nicht defi-niert.

− Stau-Steuerung: Dafür stehen drei Bits zur Verfügung,über die der Stau-Erkennungsmechanismus gesteuertwird. Das FECN-, BECN- und DE-Bit zählen dazu.Diese sind die letzten drei Bit im Adreßfeld.

FECN (Forward-Explicit Congestion Notification) istein Feld mit einem einzigen Bit, das von einem Switchauf 1 gesetzt werden kann, um dem End-DTE-Gerät(z.B. einem Router) anzuzeigen, daß es zu einer Überla-stung auf der Übertragungsstrecke von der Quelle zumZiel kam. Der primäre Vorteil der FECN- und BECN-


Felder ist die Fähigkeit von Protokollen höherer Schich-ten, auf diese Indikatoren intelligent zu reagieren. Zuden einzigen Protokollen höherer Schichten, in denendiese Funktionen implementiert sind, gehören DECnetund OSI.

BECN (Backward-Explicit Congestion Notification) istein Feld mit einem einzigen Bit, das von einem Switchauf 1 gesetzt werden kann, um anzuzeigen, daß es imNetzwerk zu einer Überlastung kam, und zwar in ent-gegengesetzter Richtung zur Übertragungsrichtung desFrame (von der Quelle zum Ziel).

Das DE-Bit (Discard Eligibility) wird von einem DTE-Gerät gesetzt, z.B. einem Router, um den Frame als we-niger wichtig zu kennzeichnen. So gekennzeichneteFrames werden in einem überlasteten Netzwerk ausge-schieden. Damit ist eine grundlegende Priorisierung ineinem Frame-Relay-Netzwerk möglich.

− Daten – Enthält die gekapselten Daten höherer Schichten.Jeder Frame in diesem Feld variabler Länge enthält ein Be-nutzerdaten- bzw. Nutzlast-Feld. Die Länge kann bis zu16000 Oktetts betragen. Dieses Feld dient dazu, das Pro-tokoll-Paket höherer Schichten (PDU) durch ein Frame-Relay-Netzwerk zu transportieren.

− Frame-Prüfsumme (FCS) – Stellt die Integrität der übertra-genen Daten sicher. Dieser Wert wurde vom Quellgerät be-rechnet und wird vom Empfänger überprüft, um die Inte-grität der Übertragung sicherzustellen.

10.7.2 LMI-Frame-Format

Frame-Relay-Frames, die der LMI-Spezifikation entsprechen,bestehen aus den in Bild 10.5 gezeigten Feldern.

1

Flag LMI DLCI Informations-elemente FCS Flag

2 1 1 1 1 Variabel 2 1

Meldungs-typ

NichtnumerierterInformations-

indikator

Protokoll-Diskriminator

Call Reference

Feldlänge in Byte Bild 10.5:

Ein Frame,der demLMI-Formatentspricht,besteht ausneun Feldern


Die folgenden Beschreibungen geben einen kurzen Überblickzu diesen Feldern.

− Flag – Begrenzt Anfang und Ende eines Frame.

− LMI DLCI – Kennzeichnet den Frame als LMI-Frame. DerLMI-spezifische DLCI-Wert, der vom LMI-Konsortiumfestgelegt wurde, lautet DLCI = 1023.

− Nicht numerierter Informationsindikator – Setzt das Poll-/Final-Bit auf Null.

− Protokoll-Diskriminator – Enthält immer einen Wert, deranzeigt, daß es sich um einen LMI-Frame handelt.

− Call Reference – Dieses Feld enthält nur Nullen. Es ist fürzukünftige Verwendung reserviert.

− Meldungstyp – Markiert den Frame mit einem der folgen-den Meldungstypen:

− Statusabfrage-Meldung: Erlaubt es einem Anwender-gerät, den Status des Netzwerks abzufragen.

− Status-Meldung: Antwort auf die Statusabfrage-Mel-dung. Status-Meldungen schließen Keep-Alives undPVC-Status-Meldungen ein.

− Informations-Elemente – Enthalten eine unterschiedlicheAnzahl einzelner Informations-Elemente (IEs). Diese setzensich aus folgenden Feldern zusammen:

− IE-Kennzeichnung: Kennzeichnet das IE eindeutig.

− IE-Länge: Gibt die Länge des IE an.

− Daten: Besteht aus einem oder mehr Byte mit gekapsel-ten Daten höherer Schichten.

− Frame-Prüfsumme (FCS) – Stellt die Integrität übertragenerDaten sicher.

11 High-Speed Serial Interface

11.1 Hintergrund

Das High-Speed Serial Interface (HSSI) ist eine DTE/DCE-Schnittstelle, die von Cisco Systems und T3plus Networkingentwickelt wurde, um den Anforderungen nach schnellerKommunikation über WAN-Verbindungen nachzukommmen.Die HSSI-Spezifikation steht jedermann/-frau zur Verfügung.

HSSI wird vom American National Standards Institute (ANSI)und dem Electronic Industries Association (EIA)/TIA TR30.2Komitee formal standardisiert. Kürzlich wurde HSSI vom In-ternational Telecommunication Union TelecommunicationStandardization Sector (ITU-T) (früher das ConsultativeCommittee for International Telegraph and Telephone[CCITT]) und der International Organization for Standar-dization (ISO) angenommen und wird wahrscheinlich von die-sen Einrichtungen standardisiert.

11.2 Grundlagen zum HSSI

HSSI definiert sowohl die elektrischen als auch die physischenDTE/DCE-Schnittstellen. Deshalb entspricht es der physischenSchicht des OSI-Referenzmodells. Die technischen Daten sindin der folgenden Tabelle 11.1 zusammengestellt.

KAPITEL 11High-Speed Serial Interface


Eigenschaft Wert

Übertragungsrate, max. 52 MBit/sKabellänge, max. 15,24 mStecker-Pole 50Schnittstelle DTE-DCEElektrik Differential ECLLeistungsaufnahme 610 mWTopologie Punkt-zu-PunktKabeltyp STP

Die maximale Übertragungsrate für HSSI beträgt 52 Mbit/s.Damit ist HSSI in der Lage, sowohl die T3-Geschwindigkeit(45 Mbit/s) vieler heutiger schneller WAN-Technologien zubedienen als auch die Geschwindigkeit nach Office Channel -1(OC-1) mit 52 Mbit/s in der Synchronous Digital Hierarchy(SDH). Außerdem kann HSSI auf einfache Weise schnelle Ver-bindungen zwischen LANs aufbauen, z.B. bei Token Ringoder Ethernet.

Der Einsatz differentieller Emitter-Coupled Logic (ECL) ver-hilft HSSI dazu, hohe Datenraten und niedriges Rauschen zuerreichen. ECL wird in Cray-Schnittstellen seit Jahren verwen-det und ist ebenfalls vom ANSI als KommunikationsstandardHigh-Performance Parallel Interface (HIPPI) für die Kommu-nikation von Supercomputern mit LAN spezifiziert. ECL isteine Standard-Technik, die hervorragendes Retiming auf demReceiver ermöglicht, so daß zuverlässige Latenzzeiten erreichtwerden.

HSSI verwendet einen sehr kleinen FCC-genehmigten 50poli-gen Stecker, der kleiner als sein V.35-Gegenstück ist. Um nichtständig mit Adaptern hantieren zu müssen, sind die HSSI-Kabel als Stecker ausgelegt. HSSI verwendet die gleiche An-zahl Pins und Leitungen wie das Small Computer SystemsInterface 2 (SCSI-2)-Kabel, jedoch ist beim HSSI die elektri-sche Spezifikation enger gefaßt.

11.3 HSSI-Betrieb

Die Flexibilität des HSSI-Takt- und Dtaenübertragungs-Proto-kolls ermöglicht die Zuordnung von Benutzer- (oder Lieferan-ten-)Bandbreiten. Das DCE steuert den Takt, indem es die

Tabelle 11.1:TechnischeDaten zum

HSSI

Kapitel 11 • High-Speed Serial Interface 165

Frequenz erhöht oder verringert. Auf diese Weise kann dasDCE einzelnen Anwendungen eine Bandbreite zuordnen. EinNebenstellenanlage z.B. benötigt eine gewisse Bandbreite,ebenso ein Router und ein Channel Extender. Die Zuordnungvon Bandbreiten ist der Schlüssel, der T3 und andere Breit-band-Services erschwinglich und beliebt gemacht hat.

HSSI geht von einer Peer-to-Peer-Intelligenz beim DCE undDTE aus. Das Steuerungs-Protokoll wurde vereinfacht, so daßes nur zwei Steuersignale erfordert (»DTE verfügbar« und»DCE verfügbar«). Beide Signale müssen eingehen, bevor dieDatenverbindung verfügbar ist. Bei den DCE und DTE wirddavon ausgegangen, daß sie in der Lage sind, die Netzwerkehinter ihren Schnittstellen zu verwalten. Durch die Reduzie-rung der Steuersignale wird die Zuverlässigkeit der Verbin-dung verbessert, da so die Anzahl der möglichen fehlerhaftenVerbindungen verringert wird.

11.3.1 Rückkopplungstests

HSSI bietet vier Rückkopplungstest an, die in Bild 11.1 dar-gestellt sind. Im ersten Test wird das lokale Kabel geprüft, in-dem das Signal, nachdem es den DTE-Port erreicht hat, zu-rückgeleitet wird. Beim zweiten Test läuft das Signal bis zumLeitungs-Port des lokalen DCE. Beim dritten Test läuft das Si-gnal bis zum Leitungs-Port des fernen DCE. Der vierte Testschließlich ist ein vom DCE initiierter Test des DCE-Port amDTE.

2

DTE

DTE

DTE

DTE Lokales DCE

Lokales DCE

Lokales DCE

Lokales DCE1

1

2

1

1

2

WAN

Fernes DCE

Leitungstest

DCE-Test

Telefonleitungstest

DTE-Test

2

Bild 11.1:HSSI unter-stützt vierRückkopp-lungstests

12 Integrated Services Digital Network (ISDN)

12.1 Hintergrund

Integrated Services Digital Network (ISDN – diensteintegrie-rendes digitales Telekommunikationsnetz) umfaßt digitalesTelefonieren und digitale Datenübertragung, das von Telefon-gesellschaften angeboten wird. ISDN ist die Digitalisierung desTelekommunikationsnetz, das die Übertragung von Sprache,Daten, Texten, Grafiken, Musik, Video usw. über vorhandeneTelefonleitungen ermöglicht. Die Notwendigkeit von ISDNzeigen die Bemühungen um Standardisierung der Teilnehmer-Services, Benutzer-/Netzwerk-Schnittstellen und der Netzwerk-und Internetwork-Fähigkeiten. Zu den ISDN-Anwendungengehören schnelle bildgebende Anwendungen (z.B. Gruppe IV-Fax), zusätzliche Telefonleitungen bei den Teilnehmern (für dieTelecommuting-Industrie), schnelle Dateiübertragung undVideokonferenzen. Die Sprachübermittlung zählt auch zu denAnwendungen des ISDN. In diesem Kapitel werden diegrundlegenden Technologien und Dienste des ISDN erläutert.

12.2 ISDN-Komponenten

Die ISDN-Komponenten umfassen Endgeräte, Terminal-Adap-ter (TAs), Netzwerk-Abschlußgeräte, Leitungsabschlußgeräteund Vermittlungsabschlußgeräte. Bei den ISDN-Endgerätenlassen sich zwei Typen unterscheiden. Spezielle ISDN-Endge-räte werden als Endgeräte vom Typ 1 (terminal equipmenttype 1 – TE1) bezeichnet. Nicht-ISDN-Engeräte, wie DTEs,

KAPITEL 12Integrated Services Digital Network (ISDN)


die es bereits vor der Entwicklung von ISDN gab, werden alsEndgeräte vom Typ 2 (terminal equipment type 2 – TE2) be-zeichnet. TE1-Geräte sind mit dem ISDN-Netz über einenvierdrahtigen, digitalen Twisted-Pair-Anschluß verbunden.TE2-Geräte werden an das ISDN über einen Terminal-Adapter(TA) angeschlossen. Dabei kann es sich um ein einzelnes Gerätoder eine eingebaute Karte im TE2-Gerät handeln. Wenn imTE2 kein TA eingebaut ist, erfolgt die Verbindung über eineStandardschnittstelle der physischen Schicht, wie EIA/TIA-232-C (früher RS-232-C), V.24 und V.35.

Der nächste Anschlußpunkt im ISDN-Netzwerk nach denTE1- und TE2-Geräten sind die Geräte des Netzwerk-Abschluß Typ 1 (network termination type 1 – NT1) oderNetzwerk-Abschluß Typ 2 (network termination type 2 –NT2). Mit diesen Geräten erfolgt der Anschluß der vierdrahti-gen Teilnehmerverkabelung an die zweidrahtige lokaleVerkabelung. In Nordamerika wird der NT1 als kunden-eigenes Gerät (customer premises equipment – CPE) bezeich-net. In den meisten Ländern ist der NT1 jedoch Teil des vomBetreiber bereitgestellten Netzwerks. Der NT2 ist ein kompli-zierteres Gerät, das in digitalen Nebenstellenanlagen eingesetztwird und Funktionen der Schicht-2- und -3-Protokolle undKonzentrator-Funktionen übernimmt. NT1 und NT2 könnenauch in einem Gerät, dem NT1/2, vereint werden.

ISDN spezifiziert mehrere Referenzpunkte, die logischeSchnittstellen zwischen funktionalen Gruppierungen definie-ren, z.B. zwischen TAs und NT1. Es gibt folgende Referenz-punkte:

− R – Der Referenzpunkt zwischen Nicht-ISDN-Geräten undeinem TA.

− S – Der Referenzpunkt zwischen Benutzer-Endgeräten undeinem NT2.

− T – Der Referenzpunkt zwischen NT1- und NT2-Geräten.

− U – Der Referenzpunkt zwischen NT1-Geräten und Lei-tungsabschlußgeräten im Betreiber-Netzwerk. Der U-Re-ferenzpunkt ist nur in Noramerika von Bedeutung, da dortder NT1 nicht vom Netzwerk-Betreiber zur Verfügung ge-stellt wird.

Kapitel 12 • Integrated Services Digital Network (ISDN) 169

Bild 12.1 zeigt eine Beispiel-Konfiguration für ISDN mit dreiGeräten, die an einen ISDN-Switch in der Zentrale ange-schlossen sind. Zwei dieser Geräte sind ISDN-kompatibel, sodaß sie über einen S-Referenzpunkt an ein NT2-Gerät ange-schlossen werden können. Das dritte Gerät (ein normales,nicht für ISDN ausgerüstetes Telefon) wird über den R-Refe-renzpunkt an einen TA angeschlossen. Alle diese Geräte könn-ten an ein NT1/2-Gerät angeschlossen werden, das die beidenNT1- und NT2-Geräte ersetzen würde. Weitere Geräte könn-ten an den rechts gezeigten ISDN-Switch angeschlossen wer-den.

T

NT2

S

TA

ISDN-SwitchNT1

U

NT1

U

T

NT2

S

R

NT1

UT

NT2

S

TE2-Gerät(Standard-Telefon)

TE1-Gerät(ISDN-Telefon)

TE1-Gerät(Computer)

ISDN-Switch

Paket-Netzwerk

GewähltesNetzwerk

Privatleitungs-Netzwerk

12.3 Dienste

Der ISDN-Basisanschluß (Basic Rate Interface – BRI) bietetzwei B-Kanäle und einen D-Kanal (2B+D). Der BRI B-Kanal-Service arbeitet mit einer Übertragungsrate von 64 Kbit/s undüberträgt die Benutzerdaten; der D-Kanal-Service arbeitet miteiner Übertragungsrate von 16 Kbit/s und überträgt Steuer-und Signalisierungsdaten, kann aber auch unter gewissen Um-ständen für Benutzerdaten verwendet werden. Das Signalisie-rungs-Protokoll für den D-Kanal umfaßt die Schichten 1 bis 3des OSI-Referenzmodells. BRI bietet auch Framing-Steuerungund anderen Overhead, wobei die Gesamtübertragungsrateauf 192 Kbit/s steigt. Die Spezifikation für die physischeSchicht des BRI ist der International Telecommunication

Bild 12.1:Die Beispiel-Konfigurationfür ISDN zeigtdie Beziehun-gen zwischenGeräten undReferenz-punkten


Union Telecommunication Standardization Sector (ITU-T)(früher Consultative Committee for International Telegraphand Telephone [CCITT]) I.430.

ISDN Primary Rate Interface (PRI) bietet 23 B-Kanäle undeinen D-Kanal in Nordamerika und Japan mit einer Ge-samtübertragungsrate von 1,544 Mbit/s (der PRI D-Kanal ar-beitet mit 64 Kbit/s). ISDN PRI wird in Europa, Australienund anderen Ländern/Kontinenten mit 30 B-Kanälen und ei-nem D-Kanal angeboten. Hier erreicht die Übertragungsrate2,048 Mbit/s. Die Spezifikation für die physische Schicht desISDN PRI ist die ITU-T I.431.

12.4 Schicht 1

Die Frame-Formate in der physischen Schicht des ISDN(Schicht 1) unterscheiden sich nach ausgehendem Frame (vomEndgerät zum Netzwerk) und eingehendem Frame (vomNetzwerk zum Endgerät). Beide Schnittstellen der physischenSchicht sind in Bild 12.2 dargestellt.

LF B1

Feldlänge in Bit 1 1

L D L F L B2 L D L B1 B2L D L

1 81

LF B1 E D A F F B2 E D S B1 E D S

NT-Frame (von Netzwerk zu Terminal)

TE frame (von Terminal zu Netzwerk)

A = Aktivierungs-BitB1 = B1-Kanal-BitB2 = B2-Kanal-BitD = D-Kanal (4 Bit x 4000 Frames/sec. = 16 KBit/s)E = Echo des vorherigen D-BitF = Framing-BitL = Load BalancingS = Spare-Bit

1 1 1 8 1 1 1 8 1 1 1 8

B2

Feldlänge in Bit 1 1 1 81 1 1 1 8 1 1 1 8 1 1 1 8

. . .

. . .

Die Frames sind 48 Bit lang, wovon 36 Bit Daten sind. DieBits für den Frame der physischen ISDN-Schicht werden wiefolgt verwendet:

− F – Dient der Synchronisation

− L – Reguliert den durchschnittlichen Bit-Wert

Bild 12.2:Die Frame-

Formate derphysischen

ISDN-Schichtunterscheidensich abhängig

von ihrerÜbertragungs-

richtung


− E – Stellt die Konfliktlösung sicher, wenn mehrere Endge-räte von einem passiven Bus gleichzeitig eine Kanal anfor-dern.

− A – Aktiviert Geräte

− S – Nicht belegt

− B1, B2 und D – Übertragen Benutzerdaten

Mehrere ISDN-Benutzergeräte können physisch an eine Lei-tung angeschlossen werden. Dabei kann es zu Kollisionenkommen, weshalb ISDN Funktionen bietet, die Verbindungs-konflikte feststellen. Wenn ein NT ein D-Bit von einem TEempfängt, liefert es dieses Bit an der nächsten E-Bit-Positionzurück. Das TE-Gerät erwartet, daß das nächste E-Bit mitdem von ihm zuletzt übertragenen D-Bit identisch ist.

Endgeräte können erst dann auf dem D-Kanal Daten übertra-gen, wenn sie zuvor eine bestimmte Anzahl Einsen empfangenhaben (was so viel bedeutet wie »Kein Signal«), entsprechendeiner voreingestellten Priorität. Wenn das TE-Gerät auf demEcho-(E-)Kanal ein anderes Bit als sein D-Bit empfängt, mußes die Übertragung sofort unterbrechen. Mit dieser einfachenTechnik ist sichergestellt, daß immer nur ein Endgerät seine D-Nachricht überträgt. Nachdem die D-Nachricht erfolgreichübertragen wurde, senkt das Endgerät seine Priorität, indem esmehrere aufeinanderfolgende Einsen erwartet, bevor es mitder Übertragung beginnt. Endgeräte können ihre Priorität erstdann erhöhen, nachdem alle anderen Geräte, die die gleicheLeitung benutzen, eine D-Nachricht senden konnten. Telefon-verbindungen haben eine höhere Priorität als andere Dienste,und Signalisierungsinformationen haben eine höhere Prioritätals andere Informationen.

12.5 Schicht 2

Die Schicht 2 des ISDN-Signalisierungs-Protokolls ist die LinkAccess Procedure, D-Kanal (LAPD). LAPD ähnelt der High-Level Data-Link Control (HDLC) und Link Access Proce-dure, Balanced (LAPB). (Weitere Informationen zu diesen Pro-tokollen finden Sie in den Kapiteln 16, »Synchronous Data-Link Control und Derivate« und 17, »X.25«.) Wie das ausge-schriebene Akronym LAPD sagt, wird diese Schicht vom D-


Kanal benutzt, um sicherzustellen, daß Steuer- und Signalisie-rungs-Informationen ungehindert übertragen und unbeschä-digt empfangen werden können. Das Frame-Format des LAPD(siehe Bild 12.3) lehnt sich stark an das von HDLC an undverwendet, wie auch HDLC, Steuer-, Informations- und nicht-numerierte Frames. Die formale Spezifikation des LAPD-Pro-tokolls ist festgelegt in ITU-T Q.920 und ITU-T Q.921.

AdresseFlag Steuer-Byte Daten FCS Flag

Feldlänge in Byte 1 2 1 1Variabel

TEIEAC/RSAPI

SAPI = Service access point identifier (6 Bit)C/R = Command/response-BitEA = Erweitertes Adressierungs-BitsTEI = Terminal endpoint identifier

EA

1

Die Flag- und Steuer-Felder in LAPD sind identisch mit denenin HDLC. Das Adreßfeld in LADP kann 1 oder 2 Byte langsein. Wenn das Bit für die erweiterte Adresse im ersten Bytegesetzt ist, ist die Adresse nur 1 Byte lang; ist das Bit nicht ge-setzt, ist die Adresse 2 Byte lang. Das erste Byte im Adreßfeldenthält den Service Access Point Identifier (SAPI – Dienstzu-gangspunkt), der den Zugangspunkt bezeichnet, an demLAPD-Dienste für die Schicht 3 angeboten werden. Das C/R-Bit gibt an, ob der Frame einen Befehl oder eine Antwort ent-hält. Das Feld Terminal End-Point Identifier (TEI) bezeichnetein einzelnes oder mehrere Endgeräte. Ein TEI, der nur Einsenenthält, ist ein Broadcast.

12.6 Schicht 3

Für die ISDN-Signalisierung werden zwei Schicht-3-Spezifika-tionen verwendet: ITU-T (früher CCITT) I.450 (auch bekanntunter ITU-T Q.930) und ITU-T I.451 (auch bekannt unterITU-T Q.931). Alle diese Protokolle zusammen unterstützenBenutzer-zu-Benutzer-, verbindungsvermittelte und paket-vermittelte Verbindungen. Eine Vielzahl von Anruf-Aufbau-,

Bild 12.3:Das Frame-Format von

LAPD istangelehnt anHDLC und

LAPB


Anruf-Beendigungs-, Informations- und verschiedene Nach-richten sind spezifiziert, einschließlich SETUP, CONNECT,RELEASE, USER INFORMATION, CANCEL, STATUS undDISCONNECT. Diese Nachrichten entsprechen funktionaldenen des X.25-Protokolls (weitere Informationen dazu findenSie in Kapitel 17). Bild 12.4, das der Spezifikation ITU-TI.451 entnommen wurde, zeigt die typischen Zustände einesverbindungsvermittelten ISDN-Anrufs.

AbhebenAufbauen

Läuten

Information

Aufbau-Bestätigung

Ruf fortsetzen

Verbindung

Benachrichtigen

Läuten beenden

LäutenBenachrichtigen

Verbindung

Aufbauen

Ab-

heben

Daten-fluß

Verbindungs-bestätigung

Daten- fluß

flußDaten-

fluß

Daten-

AuflegenAbbauen

Abbauen

VollständigFreigeben

VollständigFreigeben

FreigebenFreigeben

Router-Ruf

RufendeDTE

RufendeDCE

GerufeneDCE

GerufeneDTE

GerufenerRouter Bild 12.4:

Ein verbin-dungsvermit-telter ISDN-Anruf durch-läuft verschie-dene Zuständebis zu seinemZiel

13 Point-to-Point Protocol

13.1 Background

Das Point-to-Point Protocol (PPP – Punkt-zu-Punkt-Protokoll)kam ursprünglich als Kapselungs-Protokoll für die Übertra-gung von IP-Datenverkehr über Punkt-zu-Punkt-Verbindun-gen auf. Mit PPP wurde ein Standard gesetzt für die Zuord-nung und Verwaltung von IP-Adressen, asynchrone (Start/Stop) und bit-orientierte synchrone Kapselung, das Netzwerk-Protokoll-Multiplexing, die Verbindungskonfiguration, dasTesten der Verbindungsqualität, die Fehlererkennung und dieAushandlung von Optionen für z.B. Adressen in der Vermitt-lungsschicht und Datenkompression. PPP unterstützt dieseFunktionen, indem es das erweiterbare Link Control Protocol(LCP) und eine Familie von Network Control Protocols(NCPs) zur Verfügung stellt, mit denen optionale Konfigura-tionsparameter und -einrichtungen ausgehandelt werdenkönnen. Außer IP unterstützt PPP weitere Protokolle, ein-schließlich Novells Internetwork Packet Exchange (IPX) undDECnet. Dieses Kapitel gibt einen Überblick über die grundle-genden Protokollelemente und die Funktionen von PPP.

13.2 PPP-Komponenten

PPP bietet eine Methode zur Übertragung von Datagrammenüber serielle Punkt-zu-Punkt-Verbindungen. PPP umfaßt dreiHauptkomponenten:

KAPITEL 13Point-to-Point Protocol


− Eine Methode zur Kapselung von Datagrammen über se-rielle Verbindungen – PPP verwendet das Protokoll High-Level Data-Link Control (HDLC) als Basis für die Kapse-lung von Datagrammen über Punkt-zu-Punkt-Verbindun-gen (weitere Informationen zu HDLC finden Sie in Kapitel16, »Synchronous Data-Link Control und Derivate«).

− Ein erweiterbares LCP, um Datenverbindungen aufzu-bauen, zu konfigurieren und zu testen.

− Eine Familie von NCPs, um verschiedene Protokolle derVermittlungsschicht zu etablieren und zu konfigurieren –PPP wurde dazu entwickelt, die gleichzeitige Nutzung meh-rerer Protokolle der Vermittlungsschicht zu ermöglichen.

13.3 Das Verfahren

Um die Kommunikation über eine Punkt-zu-Punkt-Verbin-dung zu etablieren, sendet das Ursprungs-PPP zuerst LCP-Frames, um die Datenverbindung zu konfigurieren und zu te-sten (optional). Nachdem die Verbindung aufgebaut und op-tionale Einrichtungen entsprechend den Anforderungen derLCP ausgehandelt wurden, sendet das Ursprungs-PPP NCP-Frames, mit denen ein oder mehrere Protokolle der Vermitt-lungsschicht ausgewählt und konfiguriert werden. Wenn jedesder ausgewählten Protokolle der Vermittlungsschicht konfi-guriert ist, können Pakete von jedem Vermittlungsschicht-Pro-tokoll über die Verbindung gesendet werden. Die Verbindungbleibt so lange erhalten, bis sie von LCP- oder NCP-Framesexplizit geschlossen wird oder wenn ein externes Ereignis diesveranlaßt (z.B. wenn ein Timer abgelaufen ist oder ein Benut-zer eingreift).

13.4 Anforderungen der physischen Schicht

PPP kann über jede DTE/DCE-Schnittstelle betrieben werden.Dazu gehören z.B. EIA/TIA-232-C (früher RS-232-C),EIA/TIA-422 (früher RS-422), EIA/TIA-423 (früher RS-423)und International Telecommunication Union Telecommunica-tion Standardization Sector (ITU-T) (früher CCITT) V.35. Daseinzige absolute Muß für PPP ist eine Duplex-Verbindung:eine dedizierte oder geswitchte, die entweder im asynchronen

Kapitel 13 • Point-to-Point Protocol 177

oder synchronen bit-seriellen Modus betrieben werden kannund die für PPP-Frames der Verbindungsschicht transparentist. PPP gibt keine Beschränkungen hinsichtlich der Übertra-gungsrate vor, außer denen, die sich von den einzelnen benutz-ten DTE/DCE-Schnittstellen herleiten.

13.5 PPP-Verbindungsschicht

PPP verwendet die Prinzipien, Terminologie und Frame-Struk-tur wie sie vorgegeben sind in den HDLC-Prozeduren der In-ternational Organization for Standardization (ISO 3309-1979), modifiziert durch ISO 3309:1984/PDAD1 »Addendum1: Start/stop transmission«. ISO 3309-1979 spezifiziert dieHDLC-Frame-Struktur für den Einsatz in synchronen Umge-bungen. ISO 3309:1984/PDAD1 spezifiziert beantragte Modi-fikationen zu ISO 3309-1979, um den Einsatz auch in asyn-chronen Umgebungen zuzulassen. Die PPP-Steuerprozedurenverwenden die Kodierung von Definitionen und Steuerfeldernentsprechend ISO 4335-1979 und ISO 4335-1979/Addendum1-1979. Das PPP-Frame-Format zeigt Bild 13.1.

AdresseFlag Steuer-Byte Protokoll Daten FCS

Feldlänge in Byte 1 Variabel 2 oder 41 1 2

Im folgenden werden die PPP-Frame-Felder, wie in Bild 13.1dargestellt, kurz beschrieben:

− Flag – Ein einzelnes Byte, das Anfang und Ende des Framekennzeichnet. Dieses Feld enthält die Bit-Folge 01111110.

− Adresse – Ein einzelnes Byte mit der Bit-Folge 11111111,die die Standard-Broadcast-Adresse darstellt. PPP weistkeine individuellen Stations-Adressen zu.

− Steuer-Bit – Ein einzelnes Byte mit der Bit-Folge 00000011,das zur Übertragung von Benutzerdaten in einem Frameaußerhalb der Reihenfolge auffordert. Es wird ein verbin-dungsloser Link-Service angeboten, der dem der LogicalLink Control (LLC) Type 1 entspricht (weitere Informatio-nen zu LLC-Typen und Frame-Typen finden Sie in Kapitel16, »Synchronous Data-Link Control und Derivate«).

Bild 13.1:Der PPP-Frame bestehtaus sechs Fel-dern


− Protokoll – Zwei Byte, die das im Daten-Feld des Framegekapselte Protokoll bezeichnen. Die aktuellen Werte fürdas Protokollfeld sind in den neuesten Assigned NumbersRequest for Comments (RFC) definiert.

− Daten – Kein oder mehrere Byte, die das Datagramm fürdas im Protokollfeld spezifizierte Protokoll enthalten. DasEnde des Datenfelds wird ermittelt über das End-Flag plus2 Byte für das FCS-Feld. Die standardmäßige maximaleLänge des Datenfelds beträgt 1500 Byte. Aufgrund frühe-rer Vereinbarungen kann bei zustimmenden PPP-Imple-mentationen die maximale Länge dieses Felds von diesemWert abweichen.

− Frame-Prüfsequenz (FCS) – Normalerweise 16 Bit (2 Byte).Aufgrund früherer Vereinbarung kann bei zustimmendenPPP-Implementationen ein 32 Bit (4 Byte) langes FCS-Feldfür genauere Fehlererkennung verwendet werden.

Das LCP kann Modifikationen an der Standardstruktur desPPP-Frame aushandeln. Modifizierte Frames sind jedoch vonStandard-Frames eindeutig zu unterscheiden.

13.5.1 PPP-Verbindungssteuerungs-Protokoll

Das Verbindungssteuerungs-Protokoll (Link-Control Protocol– LCP) des PPP stellt eine Methode für die Etablierung, Konfi-gurierung, Verwaltung und Beendigung einer Punkt-zu-Punkt-Verbindung zur Verfügung. LCP durchläuft vier einzelne Pha-sen:

In der ersten Phase erfolgt der Verbindungsaufbau, und dieKonfiguration wird ausgehandelt. Bevor irgendwelche Da-tagramme der Vermittlungsschicht (z.B. IP) ausgetauscht wer-den können, muß LCP die Verbindung eröffnet und Konfigu-rationsparameter ausgehandelt haben. Diese Phase ist beendet,wenn sowohl ein Frame gesendet als auch einer empfangenwurde, der die Konfigurationsbestätigung enthält.

Dann wird die Verbindungsqualität ermittelt. Diese Phase istoptional. In dieser Phase wird die Verbindung getestet, umfestzustellen, ob die Qualität dafür ausreicht, daß die Proto-kolle der Vermittlungsschicht gestartet werden können. LCPkann die Übertragung von Protokoll-Informationen der Ver-

Kapitel 13 • Point-to-Point Protocol 179

mittlungsschicht so lange hinauszögern, bis diese Phase been-det ist.

Zu diesem Zeitpunkt erfolgt die Konfigurationsaushandlungdes Vermittlungschicht-Protokolls. Nachdem LCP die Phaseder Qualitätsprüfung beendet hat, können die Vermittlungs-schicht-Protokolle vom entsprechenden NCP einzeln konfigu-riert werden und jederzeit gestartet oder beendet werden.Wenn LCP die Verbindung beendet, informiert es die Proto-kolle der Vermittlungsschicht, damit diese entsprechendeSchritte einleiten.

Zuletzt erfolgt die Verbindungsbeendigung. LCP kann dieVerbindung jederzeit beenden. Eine Verbindung wird im all-gemeinen auf Anforderung eines Benutzers beendet, kann aberauch aufgrund eines physischen Ereignisses beendet werden,z.B. wenn das Trägersignal verloren geht oder ein Timer ab-läuft.

Es gibt drei Klassen von LCP-Frames. Verbindungsaufbau-Frames dienen dazu, eine Verbindung aufzubauen und zu kon-figurieren. Verbindungsbeendigungs-Frames dienen dazu, eineVerbindung zu beenden, während Verbindungverwaltungs-Frames eine Verbindung verwalten und debuggen.

Diese Frames werden für die Durchführung der einzelnenLCP-Phasen benötigt.

14 Switched Multimegabit Data Service (SMDS)

14.1 Hintergrund

Switched Multimegabit Data Service (SMDS) ist eine schnelle,paketvermittelte, datagrammbasierende WAN-Technologie,die für die Kommunikation über öffentliche Datennetze einge-setzt wird. SMDS kann über faser- oder kupferbasierte Me-dien betrieben werden und unterstützt eine Übertragungsge-schwindigkeit von 1,544 Mbit/s bei Übertragungseinrichtun-gen der Digitalen Signalstufe 1 (DS-1) oder 44,736 Mbit/s beiÜbertragungseinrichtungen der Digitalen Signalstufe 3 (DS-3).Außerdem sind SMDS-Dateneinheiten groß genug, um ganzeFrames der Spezifikationen IEEE 802.3, IEEE 802.5 undFiber-Distributed Data Interface (FDDI) zu kapseln. DiesesKapitel gibt einen Überblick zu den operationalen Elementender SMDS-Umgebung und behandelt das zugrundeliegendeProtokoll. Außerdem werden entsprechende Technologien dis-kutiert, z.B. der Distributed Queue Dual Bus (DQDB). DasKapitel schließt mit der Betrachtung der SMDS-Zugriffsklas-sen und -Zellformate.

14.2 SMDS-Netzwerk-Komponenten

SMDS-Netzwerke befähigen viele zugrundeliegende Einrich-tungen, Hochgeschwindigkeits-Daten-Service anzubieten. Dazugehören kundeneigene Geräte (customer premises equipment –CPE), Betreiber-Geräte und Teilnehmer-Netzschnittstellen (sub-scriber network interface – SNI). Zum CPE zählen Endgeräte,

KAPITEL 14Switched Multimegabit Data Service (SMDS)


die im Eigentum des Kunden sind und von diesem gewar-tet/verwaltet werden. Dies können Terminals, Personalcom-puter und Zwischenknoten (z.B. Router, Modems und Multi-plexer) sein. Zwischenknoten werden manchmal auch vomSMDS-Betreiber gestellt. Zu den Geräten des Betreibers ge-hören Hochgeschwindigkeits-WAN-Switches, die bestimmtenNetzwerkspezifikationen entsprechen müssen, z.B. denen vonBell Communications Research (Bellcore). Diese Spezifikatio-nen definieren Netzwerk-Operationen, die Schnittstelle zwi-schen dem örtlichen Netzwerk des Betreibers und dem Fern-verkehrs-Netzwerk eines anderen Betreibers, und die Schnitt-stelle zwischen zwei Switches im Netzwerk eines einzelnen Be-treibers.

Das SNI ist die Schnittstelle zwischen CPE und Betreiber-Geräten. An dieser Schnittstelle endet das Kunden-Netzwerk,und das Betreiber-Netzwerk beginnt. Das SNI hat die Funk-tion, die Technolgie und Arbeitsweise des SMDS-Betreiber-Netzwerks dem Kunden gegenüber transparent zu halten. Bild14.1 zeigt den Zusammenhang zwischen diesen drei Kompo-nenten eines SMDS-Netzwerks.

Router

Personal-computer

CPE

CPE

SNISNI

SMDS WAN

Geräte desBetreibers

Switch

14.3 SMDS Interface Protokoll (SIP)

Das SMDS-Interface-Protokoll (SIP) dient zur Kommunika-tion zwischen CPE und SMDS-Betreiber-Geräten. SIP bietetverbindungslosen Service über das Subscriber-Network Inter-face (SNI), so daß die CPE-Geräte auf das SMDS-Netzwerkzugreifen können. SIP basiert auf dem Standard IEEE 802.6Distributed Queue Dual Bus (DQDB) für Zell Relay über

Bild 14.1:Das SNI bietet

eine Schnitt-stelle zwischen

CPE und Be-treiber-Geräten

in einemSMDS-Netz

Kapitel 14 • Switched Multimegabit Data Service (SMDS) 183

Metropolitan-Area Networks (MANs). Der DQDB wurde alsBasis für SIP gewählt, da es sich um einen offenen Standardhandelt, der alle SMDS-Service-Funktionen unterstützt.Außerdem wurde der DQDB so entworfen, daß er mit denaktuellen Übertragungsstandards der Betreiber kompatibel ist.Des weiteren orientiert sich DQDB an zukünftigen Standardsfür Breitband-ISDN (BISDN), die es ermöglichen, mit Breit-band-Video und -Sprachdiensten zusammenzuarbeiten. Bild14.2 zeigt, an welchen Stellen im SMDS-Netzwerk SIP zumEinsatz kommt.

CPE CPE

SNISNI

SIPSMDS

Geräte desBetreibers

SIP

14.3.1 SIP-Stufen

SIP ist aus drei Stufen aufgebaut. SIP-Stufe 3 läuft auf derMAC-Subschicht (Media-Access Control) der Sicherungs-schicht. SIP-Stufe 2 läuft auf der MAC-Subschicht der Siche-rungsschicht. SIP-Stufe 1 läuft auf der physikalischen Schichtdes OSI-Referenzmodells. Bild 14.3 zeigt die Entsprechungenvon SIP im OSI-Referenzmodell, einschließlich der IEEE-Ver-bindungs-Subschichten.

OSI-Referenzmodell

Physikalisch

Logical Link Control

Media Access Control

Anwendung

Darstellung

Session

Transport

SIPSicherung

SIPVerbindungs-Subschichten

Netzwerk

Bild 14.2:SIP bietet einenverbindungs-losen Servicezwischen CPEund Betreiber-Geräten

Bild 14.3:SIP bietet Ser-vices, die denSchichten(physikalischeund Siche-rungsschicht)des OSI-Refe-renzmodellszugeordnetwerden können


SIP-Stufe 3 startet, wenn Benutzerdaten in Form von SMDSService Data Units (SDUs) eingehen. SMDS SDUs werdendann vom Header und Trailer der SIP-Stufe 3 gekapselt. Dersich daraus ergebende Frame wird als Stufe-3-Protocol-Data-Unit (PDU) bezeichnet. PDUs der SIP-Stufe 3 werden dann anSIP-Stufe 2 übergeben.

SIP-Stufe 2 läuft auf der MAC-Subschicht (Media Access Con-trol) der Sicherungsschicht. Diese Stufe startet, wenn SIP-Stufe-3-PDUs eingehen. Die PDUs werden in gleichgroßeStufe-2-PDUs (53-Oktetts) segmentiert, den sogenannten Zel-len. Die Zellen werden an SIP-Stufe 1 übergeben, damit sie aufdem physischen Medium übertragen werden.

SIP-Stufe 1 läuft auf der physikalischen (oder physischen)Schicht und bietet das physische Verbindungsprotokoll, dasmit Übertragungsraten von DS-1 oder DS-3 zwischen CPE-Geräten und dem Netzwerk arbeitet. SIP-Stufe 1 besteht ausdem Übertragungssystem und den Subschichten des Physical-Layer Convergency Protocol (PLCP). Die Transmission-System-Subschicht definiert die Eigenschaften und Methodefür den Anschluß an eine DS-1- oder DS-3-Übertragungsver-bindung. Das PLCP spezifiziert, wie Zellen der SIP-Stufe 2 inbezug zu DS-1- oder DS-3-Frames angeordnet werden sollen.PLCP definiert noch weitere Management-Informationen.

14.4 Distributed Queue Dual Bus (DQDB)

Der Distributed Queue Dual Bus (DQDB) ist ein Kommuni-kationsprotokoll der Sicherungsschicht, das für den Einsatz inMetropolitan-Area Networks (MANs) entworfen wurde.DQDB spezifiziert eine Netzwerk-Topologie, die sich aus zweiunidirektionalen logischen Bussen zusammensetzt, die mehrereSysteme miteinander verbinden. Definiert ist dieser Bus imStandard IEEE 802.6 DQDB.

Der Zugriffs-DQDB beschreibt genau die Funktionsweise desDQDB-Protokolls (in SMDS, SIP) über eine Benutzer/Netz-werk-Schnittstelle (in SMDS über SNI). Diese Funktionsweiseunterscheidet sich von der des DQDB-Protokolls in jederanderen Umgebung (z.B. zwischen Betreiber-Geräten inner-halb des SMDS PDN).


Der Zugriffs-DQDB setzt sich zusammmen aus den folgendengrundlegenden SMDS-Netzwerk-Komponenten:

− Betreiber-Geräte – Ein Switch im SMDS-Netzwerk wird alseine Station am Bus betrieben.

− CPE – Ein oder mehrere CPE-Geräte werden als Stationenam Bus betrieben.

− SNI – Das SNI fungiert als Schnittstelle zwischen CPE undBetreiber-Geräten.

Bild 14.4 zeigt einen einfachen Zugriffs-SQDB mit zwei CPE-Geräten und einem Switch (Betreiber-Gerät), die an einendoppelten Bus angeschlossen sind.

Ein SMDS-Zugriffs-DQDB wird normalerweise in einer Ein-zel-CPE- oder Multi-CPE-Konfiguration eingerichtet.

Ein Zugriffs-DQDB in einer Einzel-CPE-Konfiguration bestehtaus einem Switch im Betreiber-SMDS-Netz und einer CPE-Station auf Teilnehmerseite. Einzel-CPE-DQDB-Konfiguratio-nen ergeben ein zweiknotiges DQDB-Subnetzwerk. Die Kom-munikation erfolgt nur zwischen dem Switch und dem einenCPE-Gerät über das SNI. Auf diesem Bus kommt es zu keinenKonflikten, da kein anderes CPE-Gerät darauf zugreifen kann.

Eine Multi-CPE-Konfiguration besteht aus einem Switch imBetreiber-SMDS-Netz und mehreren miteinander verbundenenCPE-Geräten auf Teilnehmerseite (die alle zum gleichen Teil-nehmer gehören). In Multi-CPE-Konfigurationen ist die lokaleKommunikation zwischen CPE-Geräten möglich. Manchmalwird die lokale Kommunkation am Switch sichtbar, der dasSNI bedient.

SNI

SMDS

CPE

CPESwitch Bild 14.4:

Ein einfacherZugriffs-DQDB kannaus einemEndknoten,Router undeinem Switchbestehen


Konflikte auf dem Bus aufgrund mehrerer Geräte erfordernden Einsatz von DQDM-Algorithmen für verteilte Warte-schlangen, weshalb die Implementation einer Multi-CPE-Kon-figuration komplizierter ist als die einer Einzel-CPE-Konfigu-ration.

14.5 SMDS-Zugriffsklassen

SMDS-Zugriffsklassen ermöglichen es SMDS-Netzwerken,sich einem weiten Bereich von Datenverkehrsanforderungenund Geräteeigenschaften anzupassen. Zugriffsklassen erzwin-gen von den CPE-Geräten eine dauerhafte oder durchschnitt-liche Übertragungsrate, indem sie eine maximal dauerhafteDatenübertragungsrate und einen maximalen Grad an Ver-kehrs-Burstiness etablieren (Burstiness meint in diesem Zu-sammenhang die Neigung eines Netzwerks, eine plötzlicheErhöhung der angeforderten Bandbreite zu erfahren). SMDS-Zugriffsklassen sind manchmal so implementiert, daß sie einHaben-Management-Schema verwenden. In diesem Fall er-zeugt und verfolgt ein Haben-Management-Algorithmus dieHaben-Salden für jede Kunden-Schnittstelle. Wenn Pakete indas Netzwerk gesendet werden, verringert sich der Saldo.Neue Habenpunkte werden regelmäßig bis zu einem fest-gelegten Maximum zugewiesen. Ein Haben-Management wirdnur von SMDS-Schnittstellen mit DS-3-Übertragungsraten,nicht mit DS-1-Raten eingesetzt.

Für Zugriffe mit DS-3-Übertragungsraten (entsprechend dendauerhaften Datenraten) gibt es fünf Zugriffsklassen. Unter-stützt werden Datenraten von 4, 10, 16, 25 und 34 Mbit/s.

14.6 Überblick zur SMDS-Adressierung

Die Protocol Data Units (PDUs) von SMDS enthalten sowohldie Quell- als auch die Zieladresse. SMDS-Adressen sind zehn-stellige Werte, die an konventionelle Telefonnummern erin-nern.

Die SMDS-Adressierung bietet Gruppen-Adressierung undSicherheitsfunktionen.


Mit der SMDS-Gruppen-Adressierung können über eine ein-zelne Adresse mehrere CPE-Stationen angesprochen werden,die die Gruppenadresse im Ziel-Adreßfeld der PDU angeben.Das Netzwerk kopiert die PDU mehrfach und sendet die Ko-pien an alle Mitglieder der Gruppe. Die Gruppen-Adressie-rung reduziert die erfoderlichen Netzwerk-Ressourcen bei derVerteilung von Routing-Informationen, beim Auflösen vonAdressen und dem dynamischen Erkennen von Netzwerk-Res-sourcen. Die SMDS-Gruppen-Adressierung entspricht demMulticasting im LAN.

SMDS implementiert zwei Sicherheitsfunktionen: Quelladreß-Überprüfung und Adreßüberwachung. Die Quelladreß-Über-prüfung stellt sicher, daß die PDU-Quelladresse rechtmäßigder SNI zugeordnet ist, von der sie stammt. Quelladreß-Über-prüfung beugt dem Adreß-Spoofing vor, bei dem ein uner-wünschter Besucher die Quelladresse eines rechtmäßigen Ge-räts vorspiegelt. Adreß-Überwachung erlaubt es einem Teil-nehmer, ein privates virtuelles Netzwerk aufzubauen, dasunerwünschten Datenverkehr ausschließt. Wenn eine Adressenicht zugelassen ist, wird die Dateneinheit nicht ausgeliefert.

14.7 SMDS-Referenz: SIP-Stufe-3-PDU-Format

Bild 14.5 zeigt das Format einer Protocol Data Unit (PDU) desSMDS-Interface-Protokolls (SIP) der Stufe 3.

RSVD BEtag BAsize DA SAX+

HLPI X+ HEL X+ HEInfo+Pad RSVD BEtag

1

Feldlänge in Byte

1 2 8 8 1 4 Bit 4 Bit 2 12 9188 11 2

LängeCRC

0,4

RSVD = ReserviertBEtag = Anfangs-/EndemarkeBAsize = PufferreservierungDA = ZieladresseSA = QuelladresseHLPI = Kennzeichnung für Protokoll höherer SchichtenX+ = Unveränderte ÜbertragungHEL = Header-Erweiterung, LängeHE = Header-ErweiterungInfo+Pad = Daten + Aufüllung (um sicherzustellen, daß das Feld an einer 32-Bit-Grenze endet)CRC = Prüfsumme

Bild 14.5:Eine Data Unitder SIP-Stufe 3besteht aus 15Feldern


Die folgende Beschreibung faßt die Funktion der PDU-Felderder SIP-Stufe 3, wie in Bild 14.5 gezeigt, zusammen:

− X+ – Stellt sicher, daß das SIP-PDU-Format am DQDB-Format ausgerichtet wird. SMDS verarbeitet oder ändertdie Werte dieser Felder nicht, die von Systemen verwendetwerden können, die an das SMDS-Netz angeschlossen sind.

− RSVD – Besteht aus Nullen.

− BEtag – Bildet eine Zuordnung von erstem und letztemSegment der segmentierten SIP-Stufe-3-PDU. Beide Felderenthalten die gleichen Werte und werden dazu verwendet,festzustellen, ob das letzte Segment einer PDU und das er-ste Segment der folgenden PDU verloren gegangen sind.Dies hat den Empfang einer ungültigen PDU der Stufe 3zur Folge.

− BAsize – Enthält die Pufferzuordnungsgröße.

− Zieladresse (Destination Address – DA) – Besteht aus zweiTeilen:

− Adreßtyp: Belegt die vier höherwertigen Bit des Felds.Der Adreßtyp wird mit 1100 oder 1110 angegeben.Erstere bezeichnet eine 60 Bit lange Einzeladresse, letz-tere eine 60 Bit lange Gruppenadresse.

− Adresse: Die Einzel- oder Gruppen-SMDS-Adresse desZiels. Die SMDS-Adreßformate sind konsistent mit demNorth American Numbering Plan (NANP).

Die vier höherwertigen Bit des Zieladressen-Subfeldsenthalten den Wert 0001 (der internationale Landes-schlüssel für Nordamerika). Die folgenden 40 Bit ent-halten den binärkodierten Wert der zehnstelligenSMDS-Adresse. Die letzten 16 (niederwertigen) Bit wer-den mit Einsen aufgefüllt.

− Quelladresse (Source Address – SA) – Besteht aus zweiTeilen:

− Adreßtyp: Belegt die vier höherwertigen Bit des Felds.Das Feld des Quelladreßtyps kann nur eine Einzel-adresse enthalten.


− Adresse: Belegt die individuelle SMDS-Adresse derQuelle. Dieses Feld hat das gleiche Format wie dasAdressen-Subfeld des Zieladressen-Felds.

− Higher Layer Protocol Identifier (HLPI) – Bezeichnet denTyp des im Datenfeld gekapselten Protokolls. Der Wert istfür SMDS uninteressant, kann aber von Systemen, die andas Netz angeschlossen sind, verwendet werden.

− Header Extension Length (HEL) – Gibt die Anzahl der 32-Bit-Wörter im Header-Extension-Feld (HE) an. Zur Zeit istdie Feldgröße für SMDS auf 12 Byte beschränkt (weshalbder HEL-Wert immer 0011 lautet).

− Header Extension (HE) – Enthält die SMDS-Versions-nummer. Dieses Feld übermittelt auch den Betreiber-Aus-wahlwert, der dazu dient, einen bestimmten zwischenge-schalteten Betreiber zu wählen, der die SMDS-Daten voneinem lokalen Betreibernetz zum anderen überträgt.

− Daten- und Füll-Feld (Info + Pad) – Enthält eine gekapselteSMDS Service Data Unit (SDU) und Füllbits, so daß dasFeld immer an der 32-Bit-Grenze endet.

− Cyclic Redundancy Check (CRC) – Enthält einen Wert fürdie Fehlerprüfung.

− Länge – Gibt die Länge einer PDU an.

14.8 SMDS-Referenz: SIP-Stufe-2-Zellformat

Bild 14.6 zeigt das Zellformat für SMDS Interface Protocol(SIP) Stufe 2.

Zutritts-steuerung

Netzwerk-Steuerungsdaten Nachrichten-ID Segmentierungseinheit Nutzlänge Nutzlast

CRC

8 32 2 14 352 6 10

Feldlänge in Bit

TrailerHeader

Segmenttyp

Bild 14.6:Eine Zelle derSMDS-SIP-Stufe 2 bestehtaus sieben Fel-dern


Die folgenden Beschreibungen fassen die Funktionen der PDU-Felder der SIP-Stufe 2 zusammen, wie in Bild 14.6 gezeigt:

− Zugriffssteuerung – Enthält verschiedene Werte, die abhän-gig sind von der Übertragungsrichtung. Wenn die Zellevom Switch zum CPE-Gerät gesendet wurde, ist nur dieAngabe wichtig, ob die PDU der Stufe 3 Daten enthält.Wenn die Zelle vom CPE-Gerät an den Switch gesendetwurde und es sich um eine Multi-CPE-Konfiguration han-delt, dann kann dieses Feld Anforderungs-Bits enthalten,die Senderechtanforderungen für Zellen auf dem Bus ent-halten, die vom Switch zum CPE-Gerät übertragen werden.

− Netzwerk-Steuerungsdaten – Enthält einen Wert, der an-gibt, ob die PDU Daten enthält.

− Segment-Typ – Gibt an, ob die Zelle die erste, letzte odereine dazwischenliegende Zelle in einer segmentierten Stufe-3-PDU ist. Es gibt vier Segment-Typwerte:

− 00: Fortsetzung der Nachricht

− 01: Ende der Nachricht

− 10: Anfang der Nachricht

− 11: Einsegmentige Nachricht

− Nachrichten-ID – Ordnet Stufe-2-Zellen einer Stufe-3-PDUzu. Die Nachrichten-ID ist für alle Segmente einer Stufe-3-PDU gleich. In einer Multi-CPE-Konfiguration müssen dieStufe-3-PDUs, die von verschiedenen CPE-Geräten stam-men, eine unterschiedliche Nachrichten-ID aufweisen.Damit ist es dem SMDS-Netzwerk möglich, verschachtelteZellen von verschiedenen Stufe-3-PDUs jeder Stufe-2-Zelleder korrekten Stufe-3-PDU zuzuordnen.

− Segmentierungs-Einheit – Enthält die Daten einer Zelle.Wenn die Stufe-2-Zelle leer ist, wird dieses Feld mit Nullenaufgefüllt.

− Nutzlänge – Gibt an, wieviel Byte einer Stufe-3-PDU imSegmentierungs-Einheiten-Feld tatsächlich enthalten sind.Wenn die Stufe-2-Zelle leer ist, wird es mit Nullen aufge-füllt.


− Nutzlast Cyclic Redundancy Check (CRC) – Enthält denCRC-Wert, der dazu verwendet wird, Fehler in den folgen-den Feldern zu ermitteln:

− Segment-Typ

− Nachrichten-ID

− Segmentierungs-Einheit

− Nutzlänge

− Nutzlast-CRC

Der Nutzlast-CRC-Wert betrifft nicht die Felder der Zugriffs-steuerung oder Netzwerk-Steuerungsdaten.

15 ADSL – Asymmetric Digital Subscriber Line

15.1 Hintergrund

Asymmetric Digital Subscriber Line (ADSL) ist eine Modem-Technologie, die auf vorhandenen Twisted-Pair-Telefonleitun-gen hoch-bandbreite Daten, z.B. Multimedia- oder Videoda-ten, zu den Service-Teilnehmern überträgt. Diese Technologiegehört zu einer größeren Familie, die insgesamt als xDSL be-zeichnet wird. ADSL wird von Implementierern und Dienst-anbietern mit besonderem Interesse betrachtet (einschließlichder anderen xDSL-Technologien), da diese Technologie ver-spricht, hoch-bandbreite Datenraten in einem stark dispersenNetz zu übertragen, so daß an der vorhandenen Telekommu-nikationsstruktur nur wenige Änderungen erforderlich sind.Ziel von ADSL ist es, eine Übertragungsrate von mehr als 6Mbit/s je Teilnehmerleitung zu unterstützen. In diesem Kapitelwird ein Überblick zu den Eigenschaften und Funktionen vonADSL gegeben.

15.1.1 ADSL-Standardisierung

Die Arbeitsgruppe T1E1.4 des American National StandardsInstitute (ANSI) hat vor kurzem einen ADSL-Standard (ANSIStandard T1.413) herausgegeben, mit dem Übertragungsratenbis zu 6,1 Mbit/s möglich sind. Das European Technical Stan-dards Institute (ETSI) fügte dem noch einen Anhang hinzu,um europäische Anforderungen zu berücksichtigen. T1.413enthält zur Kundenseite eine Einzelterminal-Schnittstelle. Aus-

KAPITEL 15ADSL – Asymmetric DigitalSubscriber Line


gabe II befindet sich unter der Bezeichnung T1E1.4 in Ent-wicklung und soll den Standard u.a. um eine multiplexendeSchnittstelle auf der Kundenseite und Protokolle für die Kon-figuration und das Netzwerk-Management erweitern.

Das ATM-Forum und DAVIC erkennen ADSL als ein Über-tragungsprotokoll der physikalischen Schicht für UTP-Medienan.

Das ADSL-Forum wurde im Dezember 1994 gebildet, um dasADSL-Konzept zu fördern und die Entwicklung von ADSL-Systemarchitekturen, -Protokollen und -Schnittstellen fürwichtige ADSL-Anwendungen zu unterstützen.

15.2 Überblick zur ADSL-Technologie

Eine ADSL-Verbindung verbindet zwei Modems über einenormale Telefonleitung (Twisted-Pair-Kabel) und erzeugt dreiDatenkanäle: einen Hochgeschwindkeits-Downstream-Kanal,einen mittelschnellen Duplex-Kanal und einen POTS-Kanal(Plain Old Telephone Service – einfacher, alter Telefondienst).Der POTS-Kanal wird vom digitalen Modem über Filter abge-trennt, damit dieser Dienst immer verfügbar ist, auch wennADSL ausfällt. Der Hochgeschwindigkeits-Kanal arbeitet miteiner Übertragungsrate von 1,5 bis 6,1 Mbit/s, während derDuplex-Kanal 16 bis 640 Kbit/s überträgt. Jeder Kanal kanneigens gemultiplext werden, um mehrere, langsamere Kanälezu erzeugen.

Die von ADSL-Modems unterstützten Übertragungsge-schwindigkeiten sind konform zu den nordamerikanischenund europäischen digitalen Hierarchien (siehe Tabelle 15.1).Solche Modems sind erhältlich mit verschiedenen Übertra-gungsgeschwindigkeiten und -eigenschaften. Bei minimalerKonfiguration werden ein Downstream-Kanal mit 1,5 oder2,0 Mbit/s und ein Duplex-Kanal mit 16 Kbit/s unterstützt.Andere Konfigurationen unterstützen 6,1 Mbit/s und 64Kbit/s. Produkte mit Downstream-Raten von 9 Mbit/s und aufdem Duplex-Kanal mit bis zu 640 Kbit/s sind seit 1996 ver-fügbar. Wenn die ATM-Technologie und deren Marktanforde-rungen ausgereift sind, werden ADSL-Modems die ATM-Übertragung mit variablen Raten und Komprimierung für denATM-Overhead übernehmen können.

Kapitel 15 • ADSL – Asymmetric Digital Subscriber Line 195

Die Downstream-Datenraten hängen von einer Vielzahl vonFaktoren ab, wie der Länge der Kupferleitung, deren Durch-messer, vorhandenen Stichleitungen und Interferenzen. DieLeitungsdämpfung nimmt mit der Leitungslänge und höhererFrequenz zu. Je größer der Leitungsdurchmesser, um so niedri-ger die Dämpfung. Tabelle 15.1 faßt die angegebene Leistungvon ADSL für verschiedene physische Medien zusammen(entsprechend den Veröffentlichungen des ADSL-Forums).

Datenrate(Mbit/s)

Durchmesser(AWG)

Leitungs-durchmesser (mm)

Leitungslänge(km)

1,5 oder 2 24 0,5 5,51,5 oder 2 26 0,4 4,66,1 24 0,5 3,76,1 26 0,4 2,7

Viele der Anwendungen, die für ADSL vorgesehen sind, bear-beiten komprimierte digitale Videos. Da es sich bei digitalemVideo um Echtzeit-Signale handelt, können diese die norma-lerweise von Datenkommunikationssystemen verwendetenFehlerkontrollverfahren auf Verbindungs- oder Netzwerk-Ebene nicht einsetzen. ADSL-Modems arbeiten mit eingebau-ter Forward-Fehlerkorrektur, um Fehler, die durch Signalrau-schen entstehen, zu reduzieren. Symbolweise Fehlerkorrekturreduziert ebenfalls die Fehlerzahl, die von ständigem Leitungs-rauschen herrührt.

Zur Zeit bieten ADSL-Modelle die digitalen SchnittstellenT1/E1 und V.35 für Continuous Bit Rate (CBR)-Signale.

15.3 ADSL-Funktionen

Um mehrere Kanäle zu erzeugen, müssen ADSL-Modems dieverfügbare Bandbreite einer Telefonleitung aufteilen. Dazugibt es zwei Möglichkeiten: Frequency Division Multiplexing(FDM) oder Echo Cancellation. Bei FDM wird jeweils einBand für ausgehende (upstream) und eingehende (down-stream) Daten zugewiesen. Der eingehende Pfad wird dannper Zeitscheiben-Multiplexing in einen oder mehrere Hoch-geschwindigkeits-Kanäle und einen oder mehrere langsameKanäle zerlegt. Der ausgehende Pfad wird in entpsrechende

Tabelle 15.1:VorgegebeneLeistung vonADSL fürphysischeMedien


langsame Kanäle gemultiplext. Die Echo Cancellation ordnetdas Eingangsband so an, daß es das Ausgangsband überlappt.Dabei werden die beiden Bänder per lokaler Echo Cancella-tion getrennt – eine Technik, die bei V.32- und V.34-Modemseingeführt ist. Mit der Echo Cancellation wird die Bandbreiteeffektiver genutzt, jedoch mit einer höheren Komplexität undKosten. Mit beiden Techniken teilt ADSL einen 4 kHz-Bereichfür POTS am DC-Ende des Bands ab.

Ein ADSL-Modem organisiert den aggregierten Datenstrom,der beim Multiplexen der Downstream-, Duplex- und Verwal-tungskanäle entsteht, in Blöcke, denen es einen Fehlerkorrek-tur-Code anhängt. Der Empfänger berichtigt anschließendFehler, die bei der Übertragung zustande kamen, bis zu einemGrenzwert, der vom Code und der Blocklänge bestimmt wird.Ein Modem kann – aus Benutzersicht – Superblöcke erzeugen,indem es Daten in Subblöcke schachtelt, wodurch der Emp-fänger in die Lage versetzt wird, jede Kombination von Feh-lern innerhalb einer bestimmten Bit-Spanne zu berichtigen.

Bild 15.1 zeigt den Geschwindigkeitsbereich von ADSL fürden Downstream, wie er vom ADSL-Forum erklärt wurde.Die Geschwindigkeit für Upstreams reicht von 16 Kbit/s bis zu640 Kbit/s. Einzelne Produkte sind heute mit einer Vielzahleingebauter Geschwindigkeitskombinationen versehen, miteiner minimalen Geschwindigkeit von 1,544/2,048 Mbit/s(ausgehend) und 640 Kbit/s (eingehend). Alle diese Einrich-tungen werden in einem Frequenzband oberhalb POTS betrie-ben, wobei der POTS serviceunabhängig und -ungestörtbleibt, auch wenn ein ADSL-Modem auf Benutzerseite aus-fällt. Bild 15.1 zeigt eine grundlegende ADSL-Verbindung.

Server

Internet

ADSL ADSL

Vorhandene Kupferleitung

Core-Netzwerk

ADSL-Verbindung

1.5 bis 9 MBit/s

16 bis 640 KBit/s

Bild 15.1:Eine ADSL-

Verbindung er-reicht einen

Server oder dasInternet über

ein Core-Netzwerk


15.4 ADSL-Referenzmodell

Bild 15.2 und die folgenden Definitionen geben eine Überblicküber die Hauptelemente des ADSL-Referenzmodells.

U-C2 U-C U-R

Breitband-Netzwerk

Breitband-Netzwerk

Schmalband-Netzwerk

Netzwerk-Management

Zugriffs-knoten

PremisesDistribution

Network

TVC VA U-R2 T-SM

B

T.E.

T.E.

T.E.

T.E.POTS R

Verteiler

POTS C

Schleife

Telefon(e)PSTN

ATU-R

ATU-C

ATU-C

ATU-C

ATU-C

Die folgenden Beschreibungen fassen die Elemente des ADSL-Referenzmodells, wie in Bild 15.2 gezeigt, zusammen:

− ATU-C – ADSL-Übertragungseinheit am Netzwerk-Ende.Die ATU-C kann in einen Zugriffsknoten integriert sein.

− ATU-R – ADSL-Übertragungseinheit auf Seiten des Kun-den. Die ATU-R kann in ein SM integriert sein.

− Zugriffsknoten – Konzentrationspunkt für breit- undschmalbandige Daten. Ein Zugriffsknoten kann in der Zen-trale oder einer entfernten Niederlassung stehen. Ein fernerZugriffsknoten kann auch von einem zentralen Zugriffs-knoten mitverwaltet werden.

− B – Hilfsdaten-Eingang (z.B. Satelliten-Einspeisung) für einService-Modul (z.B. Top-Box).

− Broadcast – Breitband-Dateneingang im einfachen Modus(normalerweise Broadcast-Video).

− Breitband-Netzwerk – Switching-System für Datenratenüber 1,5/2,0 Mbit/s.

− Schleife – Twisted-Pair-Telefonleitung. Schleifen können inder Länge, im Durchmesser, Alter und den Übertragungsei-genschaften verschieden sein, abhängig vom Leitungsnetz.

Bild 15.2:Das ADSL-Referenzmodellenthält eineVielzahl mit-einander ver-bundenerKomponenten


− Schmalband-Netzwerk – Switching-System für Datenratenunter oder bis zu 1,5/2,0 Mbit/s.

− POTS – Plain Old Telephone Service (einfacher, alter Tele-fondienst).

− POTS-C – Schnittstelle zwischen PSTN- und POTS-Vertei-ler am Netzwerk-Ende.

− POTS-R – Schnittstelle zwischen Telefonen und POTS-Ver-teiler auf Kundenseite.

− Premises Distribution Network (PDN) – System für denAnschluß einer ATU-R an Service-Module. PDN kann einNetz mit Punkt-zu-Punkt-Verbindungen oder Mehrpunkt-Verbindungen sein, mit einer passiven Verkabelung odereinem aktiven Netzwerk. Mehrpunkt-Verbindungen kön-nen über einen Bus oder eine Stern-Verkabelung erfolgen.

− PSTN – Public Switched Telephone Network (ÖffentlichesTelefonnetz).

− Service-Modul (SM) – Geräte, die der Terminaladaptierungdienen. Zum Beispiel Set-Top-Boxen, PC-Schnittstellenoder LAN-Router.

− Verteiler – Filter, die hoch- (ADSL) und niederfrequente(POTS) Signale am Netzwerk-Ende und auf Kundenseitetrennen können. Ein Verteiler kann in die ATU integriertsein, physisch von ihr getrennt sein oder in Hoch- undTiefpass-Filter aufgeteilt sein, wobei der Tiefpass-Filterphysisch von der ATU getrennt ist. Die Bereitstellung vonPOTS-Verteilern und POTS-bezogener Funktionen ist op-tional.

− T-SM – Schnittstelle zwischen ATU-R und PDN, die wie Tausgelegt sein kann, wenn es sich bei dem Netzwerk umeine passive Punkt-zu-Punkt-Verkabelung handelt. EineATU-R kann mit mehr als einem Typ von T-SM-Schnittstel-len ausgestattet sein, z.B. für T1/E1-Verbindungen undEthernet-Verbindungen. Die T-SM-Schnittstelle kann in ei-nem Service-Modul integriert sein.

− T – Schnittstelle zwischen PDN und Service-Modulen, diemit T-SM identisch sein kann, wenn es sich bei demNetzwerk um eine passive Punkt-zu-Punkt-Verkabelung


handelt. Beachten Sie, daß T-Schnittstellen auf der physi-schen Ebene entfallen, wenn die ATU-R in einem Service-Modul integriert ist.

− U-C – Schnittstelle zwischen Schleife und POTS-Verteilerauf Netzwerk-Seite. Definiert die beiden Enden der Schlei-fenschnittstelle separat, aufgrund der Asymmetrie der Lei-tungssignale.

− U-C2 – Die Schnittstelle zwischen POTS-Verteiler undATU-C. Beachten Sie, daß z. Zt. ANSI T1.413 eine solcheSchnittstelle nicht definieren, so daß die Separierung einesPOTS-Verteilers von der ATU-C einige technische Schwie-rigkeiten hinsichtlich der Standardisierung bereitet.

− U-R – Die Schnittstelle zwischen der Leitungschleife unddem POTS-Verteiler auf Kundenseite.

− U-R2 – Die Schnittstelle zwischen POTS-Verteiler und derATU-R. Zu beachten ist dabei, daß gegenwärtig eine solcheSchnittstelle vom Standard ANSI T1.413 nicht definiertwird. Da der POTS-Verteiler vom ATU-R getrennt wird,ergeben sich einige technische Schwierigkeiten in Hinblickauf die Standardisierung der Schnittstelle.

− VA – Die logische Schnittstelle zwischen der ATU-C unddem Zugriffsknoten. Da diese Schnittstelle oft mit Schal-tungen auf einer normalen Karte realisiert ist, hat dasADSL-Forum von der Spezifizierung einer physischen VA-Schnittstelle abgesehen. Die V-Schnittstelle kann das Syn-chronous Transport Module (STM), ATM oder beide Über-tragungsmodi enthalten. Im einfachsten Fall der Punkt-zu-Punkt-Verbindung zwischen einem Switch-Port und einerATU-C (wenn es keine Konzentration oder kein Multi-plexing gibt) sind VA- und VC-Schnittstelle identisch (oderdie VA-Schnittstelle entfällt).

− VC – Die Schnittstelle zwischen Zugriffsknoten und demNetzwerk, das mit mehreren physischen Verbindungen an-geschlossen ist (wie in der Darstellung). Es ist auch mög-lich, daß ein Netzwerk mit nur einer physischen Leitungangeschlossen ist, über die alle Signale laufen. Eine digitaleEinrichtung des Betreibers, z.B. ein Synchronous OpticalNetwork (SONET) oder eine Synchronous Digital Hierar-chy (SDH)-Erweiterung, kann zwischen VC-Schnittstelle


und dem Zugriffsknoten geschaltet sein, wenn der Zu-griffsknoten und die ATU-Cs auf der fernen Kundenseitestehen. Die Schnittstelle zum PSTN kann eine universaleTip-Ring-Schnittstelle oder ein gemultiplextes Telefon-In-terface sein, z.B. wie es in Bellcore TR-08 bzw. TR-303spezifiziert ist. Beim Breitband-Segment der VC-Schnitt-stelle kann es sich um die Verbindungstypen STM-Switching, ATM-Switching oder Privatleitung handeln.

16 Synchronous Data-Link Control und Derivate

16.1 Hintergrund

Von IBM wurde Mitte der 70er Jahre das Protokoll Syn-chronous Data-Link Control (SDLC) für den Einsatz inSystems Network Architecture (SNA)-Umgebungen entwik-kelt. SDLC war das erste Protokoll der Verbindungssiche-rungsschicht, das auf synchronem, bit-orientiertem Verfahrenaufsetzt. Dieses Kapitel gibt einen kurzen Überblick über diegrundlegenden funktionalen Eigenschaften von SDLC und er-wähnt auch verschiedene davon abgeleitete Protokolle.

Nach der Entwicklung von SDLC legte IBM das Protokollmehreren Standardisierungs-Komitees vor. Die InternationalOrganization for Standardization (ISO) modifizierte SDLCzum Protokoll High-Level Data-Link Control (HDLC). DieInternational Telecommunication Union – TelecommunicationStandardization Sector (ITU-T) (früher CCITT) änderteHDLC, so daß daraus die Link-Access Procedure (LAP) wurdeund anschließend Link-Access Procedure, Balanced (LAPB).Das Institute of Electrical and Electronic Engineers (IEEE) än-derte HDLC in den Standard IEEE 802.2. Jedes dieser Proto-kolle wurde in seinem bestimmten Bereich wichtig, jedochblieb SDLC das primäre Protokoll der SNA-Verbindungs-schicht für WAN-Verbindungen.

KAPITEL 16Synchronous Data-Link Control und Derivate Statusbar


16.2 SDLC-Typen und Topologien

SDLC unterstützt eine Vielzahl von Verbindungstypen undTopologien. Es kann eingesetzt werden für Punkt-zu-Punkt-und Mehrpunkt-Verbindungen, auf begrenzten und unbe-grenzten Medien, mit Halb- und Vollduplex-Übertragungsein-richtungen und in verbindungsvermittelten und paketvermit-telten Netzwerken.

SDLC erkennt zwei Typen von Netzwerk-Knoten: primäreund sekundäre. Primäre Knoten steuern den Betrieb andererStationen, den sogenannten Sekundären. Die primären Statio-nen pollen die sekundären in einer vordefinierten Reihenfolge.Auf diese Anforderung hin können die sekundären Stationenihre Daten senden. Von den primären Stationen werden Ver-bindungen aufund abgebaut und verwaltet. Die sekundärenKnoten werden von den primären gesteuert, d.h., die sekundä-ren Knoten können nur dann Daten an die primären Knotensenden, wenn diese das zulassen.

Primäre und sekundäre SDLC-Knoten können auf vier Weisenmiteinander verbunden werden:

− Punkt-zu-Punkt – Es werden nur zwei Knoten verbunden,ein primärer und ein sekundärer.

− Mehrpunkt – Es werden an einen primären Knoten meh-rere sekundäre angeschlossen.

− Schleife – Schleifen-Topologie, in der an den primären Kno-ten die erste und letzte sekundäre Station angeschlossen ist.Die dazwischenliegenden sekundären Stationen reichen denDatenverkehr zueinander weiter, wie auch die Antwortenauf eine Anforderung des primären Knotens.

− Hub go-ahead – Eingangs- und Ausgangskanal. Die primä-ren Knoten kommunizieren über den Ausgangskanal mitden sekundären Stationen. Die sekundären Stationenkommunizieren dementsprechend über den Eingangskanalmit dem primären Knoten. Der Eingangskanal wird überjede sekundäre Station zum primären Knoten zurückge-schleift.

Kapitel 16 • Synchronous Data-Link Control und Derivate 203

16.3 SDLC-Frame-Format

Der SDLC-Frame ist in Bild 16.1 dargestellt.

Empfangs-Folge-

nummer

Sende-Folge-

nummer0Poll

final

Empfangs-Folge-

nummer

Funktion-code

1

Information-Frame-Format

Supervisory-Frame-Format

Unnumeriertes Frame-Format

0

Funktions-code

Funktions-code

11

AdresseFlag Steuerung Daten FCS Flag

Feldlänge in Byte 1 1 or 21 or 2 Variabel 2 1

Pollfinal

Pollfinal

Im folgenden werden die dargestellten Felder aus Bild 16.1kurz beschrieben.

− Flag – Kennzeichnet Anfang und Ende der Fehlerprüfung.

− Adresse – Enthält die SDLC-Adresse der sekundären Sta-tion, woran zu erkennen ist, ob der Frame von der primä-ren oder sekundären Station gesendet wurde. Diese Adressekann eine einzelne, eine Gruppen- oder eine Broadcast-Adresse sein. Die primäre Station ist immer entwederQuelle oder Ziel, weshalb deren Adresse nicht angegebenzu werden braucht.

− Steuerung – Verwendet drei verschiedene Formate abhän-gig vom SDLC-Frame-Typ:

− Information- (I-)Frame: Überträgt Informationen derhöheren Protokollschichten und bestimmte Steuerinfor-mationen.

Dieser Frame sendet und empfängt Folgenummern; dasPoll-Final-Bit (P/F) dient der Fluß- und Fehlersteuerung.Die Sende-Folgenummer bezieht sich auf die Nummerdes als nächsten zu sendenden Frame. Die Empfangs-

Bild 16.1:Der SDL-Frame setztsich aus sechsFeldern zu-sammen


Folgenummer stellt die Nummer für den Frame zur Ver-fügung, der als nächster empfangen werden soll.

Sowohl Sender als auch Empfänger verwalten Sende-und Empfangs-Folgenummern.

Eine primäre Station verwendet das P/F-Bit dazu, einersekundären Station mitzuteilen, ob eine sofortige Ant-wort erforderlich ist. Mit dem P/F-Bit teilt die sekundäreStation der primären mit, ob der aktuelle Frame derletzte seiner Antwort ist.

− Supervisory-(S-)Frame: Stellt Steuerinformationen zurVerfügung. Ein S-Frame kann die Übertragung anfor-dern und unterbrechen, gibt Auskunft über den Statusund bestätigt den Eingang von I-Frames. S-Frameshaben kein Informations-Feld.

− Unnumerierter-(U-)Frame: Dient zur Steuerung und istnicht an die Reihenfolge gebunden. Ein U-Frame kanndazu verwendet werden, eine sekundäre Station zu ini-tialisieren. Abhängig von der Funktion des U-Frame istdas Steuerungsfeld 1 oder 2 Byte lang. Manche U-Frames haben auch ein Informations-Feld.

− Daten – Enthält die Daten der Path-Information Unit (PIU)oder zur Exchange Identification (XID).

− Frame-Prüfsequenz (FCS) – Ist dem Ende-Flag vorange-stellt und ein Wert des Cyclic Redundancy Check (CRC).Die CRC-Berechnung erfolgt ein zweites Mal im Empfän-ger. Wenn das Ergebnis vom ursprünglichen Wert abweicht,wird von einem Fehler ausgegangen.

In Bild 16.2 wird eine typische SDLC-basierte Netzwerk-Kon-figuration dargestellt. Ein IBM-Establishment-Controller (frü-her bezeichnet als Cluster Controller) verbindet in der entfern-ten Niederlassung »dumme« Terminals mit einem Token-Ring-Netzwerk. In der lokalen Niederlassung ist ein IBM-Host (über Kanalanschluß-Techniken) an einen Vorrechner(FEP) angeschlossen, der auch in Verbindung stehen kann mitlokalen Token-Ring-LANs und einem SNA-Backbone. Diebeiden Niederlassungen sind über eine geleaste Leitung mit56-Kbit/s und SDLC miteinander verbunden.


TokenRing

Vorrechner

IBM-Mainframe

Terminals

Establishmentcontroller

Fern-Niederlassung

SDLC-Link

Lokale Niederlassung

16.4 Abgeleitete Protokolle

Obwohl HDLC einige Funktionen nicht aufweist, die in SDLCverwendet werden, wird HDLC immer als ein zu SDLC kom-patibles, umfangreicheres Protokoll betrachtet. LAP ist einSubset von HDLC und wurde entwickelt, um weiterhin dieKompatibilität mit HDLC sicherzustellen, das in den frühen80er Jahren modifiziert wurde. IEEE 802.2 ist eine für LAN-Umgebungen angepaßte Fassung von HDLC. Qualified Logi-cal Link Control (QLLC) ist ein Protokoll der Verbindungs-schicht, das von IBM definiert wurde, und das dazu dient,SNA-Daten über X.25-Netzwerke zu senden.

16.4.1 High-Level Data-Link Control (HDLC)

HDLC hat das gleiche Frame-Format wie SDLC, wobei dieHDLC-Felder die gleichen Funktionen bereitstellen wie die inSDLC. HDLC unterstützt ebenso synchronen Voll-Duplex-Betrieb.

HDLC unterscheidet sich jedoch geringfügig von SDLC. Alserstes bietet HDLC eine Option für eine 32-Bit-Prüfsumme.

Bild 16.2:Mit SDLC sindeine lokale undferne Nieder-lassung übereine serielleLeitung ver-bunden


Anders als bei SDLC werden von HDLC die Schleifen- undHub-go-ahead-Konfiguration nicht unterstützt.

Die Hauptdifferenz zwischen HDLC und SDLC ist, daß SDLCnur einen Übertragungsmodus unterstützt, während HDLCdrei Modi unterstützt:

− Normal response mode (NRM) – Dieser Übertragungsmo-dus wird auch von SDLC verwendet. In diesem Moduskönnen sekundäre Stationen mit der primären erst auf de-ren Anforderung kommunizieren.

− Asynchronous response mode (ARM) – In diesem Moduskönnen sekundäre Stationen selbst die Kommunikation mitder primären Station beginnen, ohne von dieser erst aufge-fordert werden zu müssen.

− Asynchronous balanced mode (ABM) – ABM führt denkombinierten Knoten ein, der sowohl primärer als auch se-kundärer Knoten sein kann, abhängig von der Situation.Die gesamte ABM-Kommunikation erfolgt zwischen meh-reren kombinierten Knoten. In einer IBM-Umgebung kannjede kombinierte Station die Datenübertragung starten,ohne dazu die Erlaubnis anderer Stationen einholen zumüssen.

16.4.2 Link-Access Procedure, Balanced (LAPB)

LAPB ist bekannt aufgrund seiner Präsenz im X.25-Protokoll-Stack. LAPB arbeitet mit dem gleichen Frame-Format, dengleichen Frame-Typen und Feldfunktionen wie SDLC undHDLC. Aufgrund seiner Unterschiede zu beiden Protokollenist LAPB jedoch beschränkt auf den ABM-Tranfer-Modus undnur für kombinierte Stationen sinnvoll. Ebenso können LAPB-Verbindungen vom Data Terminal Equipment (DTE) oderData Circuit-Terminating Equipment (DCE) aufgebaut wer-den. Die Station, die die Anforderung absetzt, wird als pri-märe Station festgelegt, während die antwortende Station alssekundäre Station läuft.

Schließlich ist die Behandlung des P/F-Bit etwas anders als beiden anderen Protokollen. Weitere Informationen zu LAPB fin-den Sie im Kapitel 17, »X.25«.


16.4.3 IEEE 802.2

IEEE 802.2 wird oft als Logical Link Control (LLC) bezeich-net. In LAN-Umgebungen ist es sehr weit verbreitet, wo es mitProtokollen wie IEEE 802.3, IEEE 802.4 und IEEE 802.5zusammenarbeitet. IEEE 802.2 bietet drei Service-Typen.

Typ 1 ist ein verbindungsloser Service, der ohne Bestätigungarbeitet. Das heißt, daß LLC Typ 1 die Datenübertragungnicht quittiert. Da viele Protokolle der höheren Schichten (z.B.Transmission Control Protocol/Internet Protocol – TCP/IP)eine zuverlässige Datenübertragung bieten, die sich nicht aufProtokolle der unteren Schichten stützt, ist Typ 1 ein oft ver-wendeter Service.

Typ 2 bietet einen verbindungsorientierten Service. Der ServiceLLC Typ 2 (oft als LLC2 bezeichnet) baut zwischen Senderund Empfänger eine logische Verbindung auf und ist deshalbverbindungsorientiert. LLC2 quittiert die Übertragung beimEmpfang und findet sich in Kommunikationssystemen vonIBM.

Type 3 arbeitet als verbindungsloser Service mit Quittung.Auch wenn LLC Typ 3 die Datenübertragung quittiert, baut erjedoch keine logischen Verbindungen auf. Als Kompromiß zuden anderen beiden LLC-Services kann LLC Typ 3 in der Au-tomatisierungstechnik eingesetzt werden, wo die Fehlererken-nung wichtig, der Speicherplatz (für virtuelle Verbindungen)aber sehr begrenzt ist.

End-Stationen können mehrere LLC-Service-Typen gleichzeitigunterstützen. Ein Gerät der Klassse I unterstützt aber nur denTyp-1-Service. Klasse-II-Geräte unterstützen die Typen 1 und2, Klasse-III-Geräte Typ 1 und 3, während Klasse-IV-Gerätealle drei Service-Typen unterstützen.

Prozesse der höheren Schichten greifen auf IEEE-802.2-Servi-ces über Service Access Points (SAPs) zu. Der IEEE-802.2-Header beginnt mit einem Destination Service Access Point(DSAP)-Feld, das den eingehenden Prozeß der höheren Schich-ten erkennt. In anderen Worten: Nachdem die IEEE-802.2-Implementation des empfangenden Knotens die Verarbeitungbeendet hat, werden die verbleibenden Daten an den imDSAP-Feld bezeichneten Prozeß weitergegeben. Der DSAP-


Adresse folgt die Adresse des Source Service Access Point(SSAP), die den sendenden Prozeß der höheren Schichten be-zeichnet.

16.4.4 Qualified Logical-Link Control (QLLC)

QLLC bietet die DLC-Fähigkeiten, die erforderlich sind, umSNA-Daten über ein X.25-Netzwerk zu übertragen. QLLCund X.25 ersetzen SDLC im SNA-Protokoll-Stack. QLLCverwendet die Packet-Level-Schicht (Schicht 3) des X.25-Pro-tokoll-Stack. Um QLLC mitzuteilen, daß ein X.25-Paket derSchicht 3 verarbeitet werden muß, wird ein spezielles Bit, dasQualifier Bit, im General Format Identifier (GFI) gesetzt, derzum X.25-Paket-Header der Schicht 3 gehört. Die SNA-Datenwerden in X.25-Paketen der Schicht 3 als Benutzerdaten über-tragen. Weitere Informationen zum X.25-Protokoll-Stack fin-den Sie in Kapitel 17, »X.25«.

17 X.25

17.1 Hintergrund

X.25 ist ein Protokoll-Standard für WAN-Kommunikation desInternational Telecommunication Union TelecommunicationStandardization Sector (ITU-T). In diesem Standard ist defi-niert, wie Verbindungen zwischen Benutzergeräten und Netz-werk-Geräten aufgebaut und verwaltet werden. X.25 ist soausgelegt, daß es effektiv arbeitet – unabhängig vom System,das an das Netz angeschlossen ist. Am häufigsten ist X.25 inden paketvermittelten Netzen (PSNs) der normalen Betreiberim Einsatz, z.B. bei den Telefongesellschaften. Den Teilneh-mern werden die Kosten für die Verwendung des Netzwerksberechnet. In den 70er Jahren veranlaßten die gängigen Betrei-ber die Entwicklung des X.25-Standards. Damals war dieAnforderung, ein WAN-Protokoll zu entwickeln, das Verbin-dungen über öffentliche Datennetze (PDNs) ermöglichte.Heute wird X.25 als ein internationaler Standard von derITU-T betreut. In diesem Kapitel werden die grundlegendenFunktionen und Komponenten von X.25 erläutert.

KAPITEL 17X.25


17.2 X.25-Geräte und -Protokollfunktion

Die X.25-Netzwerk-Geräte lassen sich in drei große Katego-rien einteilen: Datenendeinrichtungen (DEE/DTE), Datenüber-tragungseinrichtungen (DÜE/DCE) und paketvermittlendeDatenaustauscher (PSE). DTE-Geräte sind Endgeräte, die überdas X.25-Netzwerk miteinander kommunizieren. Dabei han-delt es sich meistens um Terminals, Personalcomputer oderNetzwerk-Hosts, die bei den Teilnehmern stehen. DCE-Gerätesind spezielle Kommunikationseinrichtungen, z.B. Modemsoder Paket-Switches. Sie bilden die Schnittstelle zwischen denDTE-Geräten und dem PSE und sind meistens in den Räum-lichkeiten des Netzbetreibers untergebracht. PSEs sind Swit-ches, die den eigentlichen Teil des Betreiber-Netzwerks ausma-chen. Sie übertragen die Daten von einem DTE-Gerät zu ei-nem anderen über das öffentliche X.25-Netz. Bild 17.1 zeigtden Zusammenhang dieser drei Gerätetypen im X.25-Netz.

Personal-computer

Netzwerk- Host

DTE

DTE PSE

X.25 WAN

DCE

SwitchModem

17.2.1 Packet Assembler/Disassembler (PAD)

Der Packet Assembler/Disassembler (PAD) ist ein in X.25-Netzen häufig anzutreffendes Gerät. PADs werden immerdann benötigt, wenn ein DTE-Gerät, z.B. ein zeichenorientier-tes Terminal, zu »dumm« ist, um die volle X.25-Funktionali-tät zu unterstützen. Der PAD ist zwischen DTE- und DCE-Gerät geschaltet und hat drei wichtige Aufgaben: Pufferung,Paketzusammenstellung (assembly), Paketzerlegung (dis-assembly). Der PAD puffert die Daten, die vom DTE-Gerätgesendet werden. Dann stellt er die ausgehenden Daten zu

Bild 17.1:DTEs, DCEs

und PSEsbilden das

X.25-Netzwerk

Kapitel 17 • X.25 211

Paketen zusammen und sendet sie an das DCE-Gerät (wobeiein X.25-Header dem Paket hinzugefügt wird). EingehendeDatenpakete werden vom PAD zerlegt, bevor die Daten an dasDTE-Gerät weitergeleitet werden (zuvor wird noch der X.25-Header entfernt). Bild 17.2 zeigt die Grundfunktion des PADbei eingehenden Paketen aus dem X.25-WAN.

Zusammenstellung/Zerlegung Puffer

DCE

X.25

Daten

Daten PAD

17.2.2 X.25-Sitzung einrichten

Eine X.25-Sitzung wird aufgebaut, wenn ein DTE-Gerät einanderes kontaktiert, um eine Kommunikationssitzung anzu-fordern. Das DTE-Gerät, bei dem diese Anforderung eingeht,kann die Verbindung annehmen oder ablehnen. Wenn es dieVerbindung annimmt, tauschen die beiden Geräte ihre Datenim Voll-Duplex-Betrieb aus. Die Verbindung kann von beidenGeräten beendet werden. Wurde eine Sitzung einmal beendet,muß für jede weitere Kommunikation eine neue Sitzung auf-gebaut werden.

17.2.3 Virtuelle Verbindungen bei X.25

Eine virtuelle Verbindung (virtual circuit) ist eine logische Ver-bindung, die dazu dient, eine zuverlässige Kommunikationzwischen zwei Netzwerk-Geräten sicherzustellen. Eine virtu-elle Verbindung setzt einen logischen, bidirektionalen Pfad voneinem DTE-Gerät über ein X.25-Netz zu einem anderen Gerät

Bild 17.2:Der PADpuffert, stelltzusammenund zerlegtDatenpakete


voraus. Physisch kann die Verbindung über eine beliebige An-zahl dazwischenliegender Knoten (z.B. DCE-Geräte und PSEs)geleitet werden. Mehrere virtuelle Verbindungen (d.h. logischeVerbindungen) können über eine physische Verbindung (eineLeitung) gemultiplext werden. Am anderen Ende der Leitungwerden die virtuellen Verbindungen wieder demultiplext, unddie Daten werden an das Ziel gesendet. Bild 17.3 zeigt viereinzelne virtuelle Verbindungen, die auf eine einzelne physi-sche Verbindung gemultiplext werden.

Quelle

Multiplexing

Ziel

Demultiplexing

Physikalische Verbindung

Virtual Circuits

Es gibt zwei Arten virtueller Verbindungen: gewählte und festeVerbindungen. Gewählte virtuelle Verbindungen (GVV – Swit-ched Virtual Connection [SVC]) sind temporäre Verbindun-gen, die für gelegentliche Datenübertragung gedacht sind.Dazu müssen zwei DTE-Geräte für jede Kommunikation eineSitzung aufbauen, verwalten und beenden. Feste virtuelleVerbindungen (FVV – Permanent Virtual Connection [PVC])sind dauerhaft aufgebaute Verbindungen, die für häufige undzuverlässige Datenübertragungen verwendet werden können.Bei PVCs müssen keine Verbindungen aufgebaut und abge-baut werden. So kann von DTE-Geräten jederzeit eine Daten-übertragung gestartet werden, da die Sitzung immer aktiv ist.

Der grundlegende Betrieb einer virtuellen X.25-Verbindungbeginnt, indem das sendende DTE-Gerät die virtuelle Verbin-dung (die im Paket-Header eingetragen wird) angibt, über dieDaten übertragen werden sollen. Dann sendet das DTE-Gerätseine Daten an das lokale DCE-Gerät. Jetzt überprüft das lo-kale DCE-Gerät den Paket-Header, um festzustellen, welchevirtuelle Verbindung genutzt werden soll, und sendet das Pa-ket zum nächstgelegenen PSE auf dem Pfad dieser virtuellenVerbindung. PSEs (Switches) leiten den Datenverkehr zum

Bild 17.3:Virtuelle Ver-

bindungenkönnen auf

eine einzelnephysische Ver-

bindung ge-multiplext

werden

Kapitel 17 • X.25 213

nächsten zwischengeschalteten Knoten, wobei es sich umeinen weiteren Switch oder das ferne DCE-Gerät handelnkann.

Gehen die Daten beim fernen DCE-Gerät ein, wird von diesemder Paket-Header überprüft und die Zieladresse bestimmt.Dann werden die Pakete zum entsprechenden DTE-Gerät ge-sendet. Wenn die Kommunikation über eine gewählte virtuelleVerbindung (SVC) erfolgt und keines der beiden Endgerätemehr Daten überträgt, wird die virtuelle Verbindung abge-baut.

17.3 X.25-Protokolle

Die von X.25 betriebenen Protokolle betreffen die unterendrei Schichten des OSI-Referenzmodells. Die folgenden Proto-kolle kommen bei X.25-Implementationen meistens zum Ein-satz: Packet-Layer Protocol (PLP), Link-Access Procedure,Balanced (LAPB) und neben anderen seriellen Schnittstellender physikalischen Schicht (z.B. EIA/TIA-232, EIA/TIA-449,EIA-530 und G.703) das Protokoll X.21bis. Bild 17.4 zeigt dieZuordnung der wichtigen X.25-Protokolle zu den Schichtendes OSI-Referenzmodells.

OSI-Referenzmodell

Netzwerk

Data Link

Physikalisch

Anwendung

Darstellung

Session

Transport

Sicherung

PLP

X.25-Protokoll-

FamilieX.21bis, EIA/TIA-232,EIA/TIA-449, EIA-530,

G.703

LAPB

Andere Dienste

Bild 17.4:Zuordnung derwichtigenX.25-Proto-kolle zu denunteren dreiSchichten desOSI-Referenz-modells


17.3.1 Packet-Layer Protocol (PLP)

Das Packet Layer Protocol (PLP) ist das X.25-Protokoll derVermittlungsschicht. PLP verwaltet den Paketaustausch zwi-schen DTE-Geräten über virtuelle Verbindungen. PLP-Verbin-dungen können auch über Logical-Link Control 2 (LLC2)-Implementationen in LANs geführt werden und über ISDN-Schnittstellen, die mit der Link-Access Procedure auf dem D-Kanal (LAPD) arbeiten.

PLP kennt fünf verschiedene Modi: Ruf-Aufbau, Datenüber-tragung, Ruhezustand, Ruf-Clearing und Neustart.

Der Modus Ruf-Aufbau dient dazu, einen SVC zwischenDTE-Geräten aufzubauen. Das PLP verwendet dafür dasX.121-Adressierungs-Schema. Der Modus Ruf-Aufbau wirdvon jeder virtuellen Verbindung durchlaufen, so daß sich einevirtuelle Verbindung in diesem Modus befindet, während eineandere sich im Datenübertragungs-Modus befindet. Der Mo-dus Ruf-Aufbau ist nur bei SVCs erforderlich (nicht beiPVCs).

Der Datenübertragungs-Modus dient der Datenübertragungzwischen zwei DTE-Geräten über eine virtuelle Verbindung. Indiesem Modus erfolgt durch das PLP die Segmentierung unddie Zusammenstellung, das Bit-Padding und die Fehler- undFlußsteuerung. Dieser Modus wird von jeder virtuellen Ver-bindung durchlaufen (PVC und SVC).

Der Modus Ruhezustand tritt ein, wenn eine virtuelle Verbin-dung aufgebaut ist, aber keine Datenübertragung stattfindet.Dieser Modus wird von jeder einzelnen virtuellen Verbindungdurchlaufen, allerdings nur von SVCs.

Der Modus Ruf-Clearing dient dazu, die Kommunikationssit-zung zwischen DTE-Geräten zu beenden und einen SVC ab-zubauen. Dieser Modus wird von jeder virtuellen Verbindungdurchlaufen, und zwar nur von SVCs.

Kapitel 17 • X.25 215

Der Modus Neustart dient dazu, die Übertragung zwischeneinem DTE-Gerät und einem lokal angeschlossenen DCE-Ge-rät zu synchronisieren. Dieser Modus wird nicht von jeder vir-tuellen Verbindung einzeln durchlaufen, sondern betrifft allevon DTE-Geräten aufgebaute virtuelle Verbindungen.

PLP kennt vier Paketfeld-Typen:

− General Format Identifier (GFI) – Kennzeichnet Paket-Pa-rameter, z.B. ob ein Paket Benutzerdaten oder Steuerdatenüberträgt, welche Art des Windowing verwendet wird undob eine Quittierung erforderlich ist.

− Logical Channel Identifier (LCI) – Kennzeichnet die vir-tuelle Verbindung über die lokale DTE/DCE-Schnittstelle.

− Packet Type Identifier (PTI) – Kennzeichnet ein Paket miteinem der 17 verschiedenen PLP-Pakettypen.

− Benutzerdaten – Enthält gekapselte Daten höherer Schich-ten. Dieses Feld ist nur in Datenpaketen enthalten. Anson-sten werden Felder mit Steuerdaten hinzugefügt.

17.3.2 Link-Access Procedure, Balanced (LAPB)

Bei Link-Access Procedure, Balanced (LAPB) handelt es sichum ein Protokoll der Verbindungssicherungsschicht, das dieKommunikation und das Paket-Framing zwischen DTE- undDCE-Geräten verwaltet. LAPB ist ein bit-orientiertes Proto-koll, das sicherstellt, daß Frames richtig geordnet werden undfehlerfrei sind.

Es gibt drei Arten von LAPB-Frames: Information, Supervi-sory und Unnumbered. Der Information-Frame (I-Frame) ent-hält Daten der höheren Schichten und einige Steuerdaten. Zuden Funktionen des I-Frame gehören die Folge-, Flußsteuerungund die Fehlererkennung und -behebung. I-Frames enthaltenSende- und Empfangsfolgenummern. Der Supervisory-Frame(S-Frame) überträgt Steuerdaten. Zu den Funktionen des S-Frame gehören das Anfordern und Unterbrechen von Übertra-gungen, die Bekanntgabe des Status und die Bestätigung ein-


gegangener I-Frames. S-Frames enthalten nur Empfangsfol-genummern. Der Unnumbered Frame (U-Frame) überträgtSteuerdaten. Zu den Funktionen des U-Frame gehören dasAufbauen und Beenden von Verbindungen und die Fehlermel-dung. U-Frames enthalten keine Folgenummern.

17.3.3 X.21bis-Protokoll

X.21bis ist ein Protokoll der physikalischen Schicht, das inX.25 verwendet wird. Es definiert die elektrischen und me-chanischen Verfahren für das physische Medium. X.21bis be-arbeitet die Aktivierung und Deaktivierung des physischenMediums, über das DTE- und DCE-Geräte verbunden sind. Esunterstützt Punkt-zu-Punkt-Verbindungen, Übertragungsratenbis zu 19,2 Kbit/s und synchrone Voll-Duplex-Übertragungüber Vierdraht-Medien. Bild 17.5 zeigt das Format eines LPL-Pakets im Zusammenhang mit einem LAPB-Frame und einemX.21bis-Frame.

Benutzerdaten

Benutzerdaten

4 12 Variabel8

PTILCIGFI

X.21bis-Frame Bit Stream

Frame

Paket

LAPB-Frame

PLP-Paket

Feldlängein Bit

Paket-Stufen-Header

Bild 17.5: Das PLP-Paket ist in den LAPB- und X.21bis-Frame gekapselt

Kapitel 17 • X.25 217

17.4 LAPB-Frame-Format

LAPB-Frames bestehen aus dem Header, gekapselten Datenund dem Trailer. Bild 17.6 zeigt das Format eines LAPB-Frames im Zusammenhang mit einem PLP-Paket und einemX.21bis-Frame.

FCS Flag

1

Feldlängein Byte

1 Variabel 2 11

DatenFlagSteuer-

ByteAdresse

X.21bis-Frame Bit Stream

Frame

Paket

LAPB- Frame

PLP-Paket

Im folgenden werden die in Bild 17.6 gezeigten Felder kurzbeschrieben:

− Flag-Frame-Feld – Kennzeichnet Anfang und Ende einesLAPB-Frame. Dabei besteht das Flag aus gleichen Bits, umsicherzustellen, daß das Bit-Muster des Flag nicht auch imInnern des Frame vorkommt.

− Adreßfeld – Gibt an, ob der Frame einen Befehl oder eineAntwort enthält.

− Steuerfeld – Kennzeichnet Befehls- und Antwort-Framesund gibt an, ob es sich bei dem Frame um einen I-Frame, S-Frame oder U-Frame handelt. Außerdem enthält dieses

Bild 17.6: Ein LAPB-Frame beinhaltet einen Header, einen Trailer undgekapselte Daten


Feld die Folgenummer des Frame und seine Funktion (z.B.empfangsbereit oder unterbrochen). Steuer-Frames sindunterschiedlich lang, was vom Frame-Typ abhängt.

− Datenfeld – Enthält Daten höherer Schichten in Form ge-kapselter PLP-Pakete.

− FCS – Bearbeitet die Fehlerprüfung und stellt die Integritätder Datenübertragung sicher.

17.5 X.121-Adreß-Format

X.121-Adressen werden vom X.25-PLP im Modus Ruf-Auf-bau verwendet, um SVCs aufzubauen. Bild 17.7 zeigt dasFormat der X.121-Adressen.

Bis zu 10 Stellen

IDN

4 Stellen

3 Stellen 1 Stelle

Land PSN

DNIC NTN

Das X.121-Adreßfeld besteht aus der International DataNumber (IDN), die sich aus zwei Feldern zusammensetzt: demData Network Identification Code (DNIC) und der NationalTerminal Number (NTN).

Der DNIC ist ein optionales Feld, das das PSN genau bezeich-net, in dem sich das Ziel-DTE-Gerät befindet. Bei Anrufen in-nerhalb eines PSN wird dieses Feld manchmal weggelassen.Der DNIC besteht aus zwei Unterfeldern: Land und PSN. MitLand wird das Land angegeben, in dem sich das Ziel-PSN be-

Bild 17.7:Eine X.121-

Adresse bestehtaus drei

IDN-Felder

Kapitel 17 • X.25 219

findet. Im PSN-Feld wird genau das PSN angegeben, in demsich das Ziel-DTE-Gerät befindet.

Mit der NTN wird das DTE-Gerät im PSN genau identifiziert,für das ein Paket bestimmt ist. Die Länge dieses Feldes istvariabel.

Kapitel 18: Asynchronous Transfer Mode (ATM)Kapitel 19: Data-Link SwitchingKapitel 20: LAN-SwitchingKapitel 21: Tag SwitchingKapitel 22: Mixed-Media-BridgingKapitel 23: Source-Route Bridging (SRB)Kapitel 24: Transparent-Bridging

Teil 4: Bridging und Switching

Teil 4, »Bridging und Switching«, behandelt die Schlüssel-Technologien, die das Bridging und Switching betreffen. Inden einzelnen Kapiteln werden folgende Themen behandelt:

Asynchronous Transfer Mode (ATM) Switching – Dieses Kapi-tel steigt in die ATM-Technologie, einschließlich der Kompo-nenten, Verbindungstypen, Adressierung, Multicasting-Anfor-derungen und LAN-Emulation (LANE), ein.

Data-Link Switching (DLSw) – In diesem Kapitel wird der Be-trieb von DLSw für die Implementation von SNA- und Net-BIOS-Verkehr über IP-WANs definiert und beschrieben.

LAN Switching – Dieses Kapitel behandelt Ursprünge, Vor-teile, Einsatz, Arten und Anwendungen des LAN-Switching.

Tag Switching – Dieses Kapitel betrifft das Tag-Switching, ein-schließlich TDP, Tag-Allocation-Methoden und die verschie-denen Routing-Module.

Mixed-Media Bridging – In diesem Kapitel werden das über-setzende Bridging und Source Route Transparent Bridging de-finiert und beschrieben. Ferner werden die Schlüsselanforde-rungen für die Implementation aufgezeigt.

Source-Route Bridging (SRB) – Dieses Kapitel beleuchtet SRB-Konzepte, -Standards, -Route-Discovery-Prozesse und dasFrame-Format RIF.

TEIL 4Bridging und Switching


Transparent Bridging – Diese Kapitel faßt den Betrieb trans-parenten Bridging, Bridging Loops und den Spanning-Tree-Algorithmus zusammen.

18 Asynchronous Transfer Mode (ATM)

18.1 Grundlagen

Der Asynchronous Transfer Mode (ATM) ist ein Standard derInternational Telecommunication Standardization Organiza-tion (ITU-T) für die Zellenvermittlung, wobei Informationenfür verschiedene Dienste, wie Sprache, Video und Daten inkleinen Paketen fester Größe übertragen werden. Dieses Kapi-tel gibt einen Überblick zu ATM-Protokollen, -Diensten und-Einsatz. Bild 18.1 zeigt ein abgeschlossenes Teilnehmernetzund ein öffentliches ATM-Netz zur Übertragung von Sprache,Video und Datenverkehr.

18.1.1 Standards

ATM beruht auf dem ITU-T »Broadband Integrated ServicesDigital Network«-Standard (BISDN). Es war ursprünglich alsHochgeschwindigkeits-Übertragungstechnologie für Sprache,Video und Daten über öffentliche Netze gedacht. Das ATM-Forum erweiterte den Vorschlag auf den Einsatz in öffent-lichen und privaten Netzwerken. Das ATM-Forum hat seineArbeiten in den folgenden Spezifikationen veröffentlicht:

− User-to-Network Interface (UNI) 2.0

− UNI 3.0

− UNI 3.1

− Public-Network Node Interface (P-NNI)

− LAN Emulation (LANE)

KAPITEL 18Asynchronous Transfer Mode (ATM)


ÖffentlichesATM-Netzwerk

Privates ATM-Network

ZumWAN

Router

Daten

Stimme

Video

ATM- Switch

gemeinsamgenutzter

Hub

18.2 ATM-Geräte und Netzwerkumgebungen

ATM ist eine Zellenvermittlungs- und Multiplex-Technologie,welche die Vorteile der Durchschaltevermittlung (garantierteQualität und konstante Durchlaufzeit) mit denen der Paket-vermittlung (Flexibilität und Effizienz des intermittierendenVerkehrs) verbindet. Es ermöglicht skalierbare Bandbreitenzwischen einigen Megabit pro Sekunde (Mbps) bis zu vielenGigabit pro Sekunde (Gbps). Als asynchrone Technologie istATM effizienter als synchrone Technologien, wie z.B. dasTime-Division Multiplexing (TDM). Bei TDM wird den Be-nutzern ein Zeitkanal zugewiesen, in dem keine andere Stationsenden kann. Wenn eine Station viele Daten zu versenden hat,kann sie nur dann senden, wenn ihr Zeitkanal an der Reiheist, auch dann, wenn alle anderen Zeitkanäle frei sind. Wenndagegen eine Station nichts zu verschicken hat, wenn ihr Zeit-kanal an der Reihe ist, dann wird er leer verschickt und ver-schwendet. Weil ATM ein asynchrones Verfahren ist, werdendie Zeitkanäle nach Bedarf bereitgestellt, wobei der Headerjeder ATM-Zelle die Informationen zur Quelle der Übertra-gung enthält.

18.2.1 ATM-Zellen-Basisformat

ATM überträgt Informationen in Einheiten fester Größe, dieals Zellen bezeichnet werden. Jede Zelle besteht aus 53 Ok-tetts oder Bytes. Die ersten fünf Bytes enthalten Zellenkopfin-

Bild 18.1:Sowohl einprivates als

auch einöffentlichesATM-Netz-

werk könnenSprache, Video

und Daten-verkehr

übertragen

Kapitel 18 • Asynchronous Transfer Mode (ATM) 225

formationen und die übrigen 48 die eigentlichen »Nutzdaten«(Anwenderinformation). Kleine Zellen mit fester Länge sindfür die Übertragung von Sprach- und Videoverkehr besser ge-eignet, weil diese Verkehrsarten u.a. Verzögerungen auf Grundder Wartezeit auf große Datenpakete nicht tolerieren. Bild18.2 zeigt das Basisformat einer ATM-Zelle.

Header

5

Feldlängein Byte

48

Nutzdaten

18.2.2 ATM-Geräte

Ein ATM-Netzwerk besteht aus ATM-Switch- und ATM-End-punkten. Ein ATM-Switch ist für die Übertragung aller Zellenim Netzwerk verantwortlich. Die Aufgabe eines ATM-Switchist klar definiert: Er nimmt die Zellen von einem ATM-End-punkt oder anderen ATM-Switch an. Anschließend liest undaktualisiert er die Informationen des Zellenkopfes und leitetdie Zelle an eine Ausgangsschnittstelle in Versandrichtungweiter. Ein ATM-Endpunkt (oder Endsystem) enthält einenATM-Netzwerk-Adapter. Beispiele für ATM-Endpunkte sindWorkstations, Router, Data-Service-Units (DSU), LAN-Swit-ches und Video-Koder/Dekoder (CODEXs). Bild 18.3 zeigt einATM-Netzwerk, das aus ATM-Switches und ATM-Endpunk-ten besteht.

ATM-Endpunkte

ATM-Switch

Router

LAN-Switch

Workstation

CSU/DSU

Bild 18.2:Eine ATM-Zelle bestehtaus einemHeader- undeinem Nutz-datenteil

Bild 18.3:Ein ATM-Netzwerkbesteht ausATM-Switchesund -End-punkten


18.2.3 ATM-Netzwerkschnittstellen

Ein ATM-Netzwerk besteht aus ATM-Switches, die durchPunkt-zu-Punkt-ATM-Verbindungen oder -Schnittstellen ver-bunden sind. ATM-Switches unterstützen zwei primäreSchnittstellentypen: User-Network-Interfaces (UNI) und Net-work-Node-Interfaces (NNI). Die UNI verbinden ATM-End-systeme (wie Hosts und Router) mit einem ATM-Switch. DieNNI verbinden zwei ATM-Switches.

Abhängig davon, ob der Switch im Besitz des Kunden ist undihm zur Verfügung steht, oder im öffentlichen Besitz ist unddurch eine Telefongesellschaft vertrieben wird, können UNIund NNI in weitere öffentliche oder private UNIs und NNIsaufgeteilt sein. Ein privates UNI verbindet einen ATM-End-punkt und einen privaten ATM-Switch. Sein öffentlichesÄquivalent verbindet einen ATM-Endpunkt oder privatenSwitch mit einem öffentlichen Switch. Ein NNI verbindet zweiATM-Switches innerhalb der gleichen privaten Organisation,ein öffentlicher verbindet dagegen zwei ATM-Switches inner-halb der gleichen öffentlichen Organisation.

Eine weitere Spezifikation, die Broadband Interexchange Car-rier Interconnect (B-ICI), verbindet zwei öffentliche Switchesunterschiedlicher Dienstanbieter. Bild 18.4 verdeutlicht dieATM-Schnittstellen-Spezifikationen für private und öffentlicheNetzwerke.

Privates ATM- Netzwerk

Öffentliches ATM- Netzwerk A

Öffentliches ATM- Netzwerk B

ÖffentlichesNNI B-ICI

ÖffentlichesUNI

Privates NNI

Privates UNIPrivates UNI

Bild 18.4:ATM-Schnitt-

stellen-Spezifi-kationen unter-

scheiden sichfür private und

öffentlicheNetzwerke


18.3 ATM-Zellenkopf-Format

Ein ATM-Zellenkopf kann eines der Formate UNI und NNIbesitzen. Der UNI-Header wird für die Kommunikation zwi-schen ATM-Endpunkten und ATM-Switches in privatenNetzwerken verwendet. Der NNI-Header dient zur Übertra-gung zwischen ATM-Switches. Bild 18.5 zeigt das grundle-gende ATM-Zellenformat, das ATM-UNI-Zellenkopfformatund das ATM-NNI-Zellenkopfformat.

Anders als bei UNI besitzt der NNI-Header kein General FlowControl-Feld (GFC). Außerdem beinhaltet der NNI-Headerein Feld Virtual Path Identifier (VPI), das die ersten 12 Biteinnimmt und größere Strecken zwischen öffentlichen ATM-Switches erlaubt.

ATM-UNI-ZelleATM-Zelle ATM-NNI-Zelle

Header (5 Byte)

Nutzdaten(48 Byte)

8 Bit

53Byte

GFC

VPI

VPI

PT

HEC

CLP

VCI

Nutzdaten(48 Byte)

PT

HEC

CLP

VCI

Nutzdaten(48 Byte)

VPI

18.3.1 Felder im ATM-Zellenkopf

Außer den Feldern GFC und VPI werden verschiedene weitereATM-Zellenkopffelder eingesetzt. Die folgenden Beschreibun-gen behandeln die Kopffelder in Bild 18.5:

− Generic Flow Control (GFC) – stellt lokale Funktionen be-reit, wie die Identifikation mehrerer Stationen, die sich eineeinzelne ATM-Schnittstelle teilen. Dieses Feld wird ge-wöhnlich nicht verwendet und ist mit einem Voreinstel-lungswert belegt.

Bild 18.5:ATM-Zellen-,ATM-UNI-Zellen- undATM-NNI-Zellen-Headermit jeweils 48Byte Nutz-daten


− Virtual Path Identifier (VPI) – identifiziert zusammen mitdem VCI das nächste Ziel einer Zelle, während diese aufdem Weg zum Ziel eine Reihe von ATM-Switches durch-läuft.

− Virtual Channel Identifier (VCI) – identifiziert zusammenmit dem VPI das nächste Ziel einer Zelle, während dieseauf dem Weg zum Ziel eine Reihe von ATM-Switchesdurchläuft.

− Payload Type (PT) – das erste Bit gibt an, ob die Zelle Be-nutzerdaten oder Steuerdaten enthält. Wenn die Zelle Be-nutzerdaten enthält, gibt Bit 2 die Blockierung an, Bit 3beinhaltet, ob die Zelle die letzte in einer Folge von Zellenist, die einen einzelnen AAL5-Frame bilden.

− Congestion Loss Priority (CLP) – gibt an, ob die Zelleverworfen werden soll, wenn sie im Verlauf der Übertra-gung durch das Netzwerk auf eine starke Blockierung trifft.Wenn das CLP-Bit gleich 1 ist, ist die Zelle eher zu verwer-fen als Zellen, deren CLP-Bit gleich 0 ist.

− Header Error Control – berechnet eine Prüfsumme desHeader selbst.

18.4 ATM-Dienste

Es gibt drei verschiedene ATM-Dienstarten: Permanent-Vir-tual-Connections (PVC), Switched-Virtual-Connections (SVC)und Connectionless-Services (ähnlich wie SMDS).

Eine PVC ermöglicht eine Direktverbindung zwischen Sites.Damit ist eine PVC mit einer Standleitung vergleichbar. Einerder Vorzüge der PVC ist die garantierte Verfügbarkeit einerVerbindung und daß sie keine Einrichtungsprozeduren zwi-schen Switches erfordert. Nachteil der PVC sind die statischeVerbindung und das manuelle Setup.

Eine SVC wird dynamisch aufund abgebaut und bleibt nurfür die Dauer der Datenverbindung bestehen. In diesem Sinneist sie einer Telefonverbindung sehr ähnlich. Die dynamischeAnrufsteuerung erfordert ein Signalprotokoll zwischen ATM-Endpunkt und dem ATM-Switch. Zu den Vorteilen der SVCgehört eine hohe Verbindungsflexibilität und die automatische


Konfigurierbarkeit über Netzwerk-Geräte. Nachteil sind u.a.Zeitaufwand und Überhang für die Einrichtung der Verbin-dung.

18.4.1 ATM Virtual Connections

ATM-Verbindungen sind grundsätzlich verbindungsorientiert.Das bedeutet, es muß erst ein virtueller Kanal (VC) durch dasNetzwerk eingerichtet werden, bevor Daten übertragen wer-den können. (Ein virtueller Kanal ist ungefähr mit einer vir-tuellen Schaltung vergleichbar.)

Es gibt zwei ATM-Verbindungstypen: virtuelle Pfade, diedurch virtuelle Pfadidentifikatoren gekennzeichnet sind, undvirtuelle Kanäle, die durch eine Kombination aus VPI und Vir-tual Channel Identifier (VCI) gekennzeichnet sind.

Ein virtueller Pfad ist ein Bündel virtueller Kanäle, die alle imATM-Netzwerk transparent auf Basis des gemeinsamen VPIvermittelt werden. Alle VCIs und VPIs haben aber in einerspeziellen Verbindung nur lokale Bedeutung und werdendurch jeden Switch nach Bedarf umgeordnet.

Der Übertragungspfad ist ein Bündel von VPs. Bild 18.6 zeigt,wie VCs zu VPs verbunden werden, welche ihrerseits einenÜbertragungspfad bilden.

VP

VP

VC

VC

VC VP

VC VP

Übertragungsweg

18.5 ATM-Switch-Betrieb

Die Hauptaufgabe von ATM ist einfach: Die Zelle wird inner-halb einer Verbindung mit einem bekannten VCI- oder VPI-Wert empfangen. Der Switch sucht den Verbindungswert ineiner lokalen Übersetzungstabelle, um den Ausgangsanschlußund den neuen VPI/VCI-Wert der Verbindung dieses Linkfestzustellen. Der Switch sendet die Zelle anschließend mit denentsprechenden Verbindungsidentifikatoren über diese Ver-bindung weiter. Weil alle VCIs und VPIs nur lokale Bedeutung

Bild 18.6:VCs bildenVPs


über eine spezielle Verbindung haben, werden diese Wertedurch jeden Switch nach Bedarf verändert.

18.6 ATM-Referenzmodell

Die ATM-Architektur verwendet ein lokales Modell zur Be-schreibung der unterstützten Funktionalität. ATM entsprichtseinen Funktionen nach der physikalischen und einem Teil derSicherungsschicht des OSI-Referenzmodells.

− Das ATM-Referenzmodell ist aus den folgenden Ebenenzusammengesetzt, die alle Schichten überspannen.

− Kontrolle – Diese Ebene ist für die Erstellung und Verwal-tung von Signalisierungsanforderungen zuständig.

− Benutzer – Diese Ebene ist für Verwaltung des Datenver-kehrs zuständig.

− Verwaltung – Diese besteht aus zwei Komponenten:

− Die Schichten-Verwaltung bearbeitet Ebenenfunktionenwie die Ausfallerkennung und Protokollprobleme.

− Die Ebenen-Verwaltung bearbeitet und koordiniertFunktionen des Gesamtsystems.

Das ATM-Referenzmodell besteht aus den folgenden ATM-Schichten:

− Physikalische Schicht – Analog zur physikalischen Schichtdes OSI-Referenzmodells verwaltet die physikalischeSchicht die medienabhängige Übertragung.

− ATM-Schicht – Ist in Verbindung mit der ATM-Anpas-sungsschicht der Sicherungsschicht des OSI-Referenzmo-dells vergleichbar. Die ATM-Schicht ist für die Einrichtungvon Verbindungen und die Weiterleitung von Zellen durchdas ATM-Netzwerk zuständig. Sie verwendet dafür die In-formationen des Zellenkopfes.

− ATM-Anpassungsschicht (AAL) – Ist in Verbindung mit derATM-Schicht der Sicherungsschicht des OSI-Referenzmo-dells vergleichbar. Der AAL ist zuständig für die Isolationder Protokolle höherer Schichten vom ATM-Prozeß.


Als Abschluß nehmen die höheren Schichten über dem AALBenutzerdaten entgegen, verpacken sie in Pakete und überge-ben diese an den AAL. Bild 18.7 zeigt das ATM-Referenzmo-dell.

Verwaltungsebene

OSI-Referenzmodell

Netzwerk

Anwendung

Darstellung

Kommunikation

Transport

Physical

HöhereSchichten

HöhereSchichten

Kontrollebene Benutzerebene

ATM-Anpassungsschicht

ATM-Schicht

ATM-Referenzmodell E

be

ne

n-M

an

ag

em

en

t

Sch

ichte

n-M

an

ag

em

en

t

Sicherung

Physikalische SchichtPhysikalisch

18.6.1 ATM, Physikalische Schicht

Die physikalische Schicht von ATM erfüllt vier Funktionen:Bits werden in Zellen konvertiert, Empfang und Senden derBits durch das physikalische Medium werden gesteuert, ATM-Zellenränder werden verfolgt, und die Zellen werden in denentsprechenden Frame-Typ des physikalischen Mediums ver-packt.

Die physikalische ATM-Schicht besteht aus zwei Teilen: demphysikalischen Physical Medium-Dependent Sublayer (PMD)und dem Transmission Convergence (TC) Sublayer.

Der PMD stellt zwei Schlüsselfunktionen bereit. Er synchro-nisiert den Empfang durch Versand und Empfang einesBitstroms mit zugehöriger Timing-Information. Zweitens gibter das verwendete physikalische Medium an (einschließlichAnschlüssen und Kabel). Beispiele für physikalische Medien-standards für ATM sind Synchronous Optical Network/Syn-chronous Digital Hierarchy (SONET/SDH), DS-3/E3, 155MBps oder Multimodefiber (MMF) unter Verwendung des8B/10B-Kodierungsschemas über geschirmte Twisted-Pair-Kabel (STP).

Bild 18.7:Das ATM-Re-ferenzmodellentspricht denuntersten bei-den Schichtendes OSI-Refe-renzmodells


Der TC-Sublayer erfüllt vier Funktionen: Zellendilineation,Header-Fehlerkontrolle (Folgengenerierung und -prüfung),Zellenfrequenzentkopplung und Senderahmenanpassung. DieZellendilineation verwaltet ATM-Zellengrenzen, so daß Ge-räte die Zellen in einem Bitstrom erkennen können. Die Hea-der-Fehlerkontrolle (Folgengenerierung und -prüfung) erstelltund prüft Header-Steuercodes zur Sicherung einer stabilenDatenübertragung. Die Zellenfrequenzentkopplung verwaltetdie Synchronisation und ergänzt oder unterdrückt leere ATM-Zellen zur Anpassung der Frequenz der gültigen ATM-Zellenan die Kapazität des Übertragungssystems. Die Senderahmen-anpassung verpackt ATM-Zellen in Frames, welche die jewei-lige physikalische Umsetzung der physikalischen Schicht über-tragen kann.

18.6.2 ATM-Anpassungsschichten: AAL1

AAL1 ist ein verbindungsorientiertes Gerät, das in der Lageist, Anwendungen mit Simulation einer Schaltung zu verwal-ten, wie z.B. Sprach- und Video-Konferenzen. Die Schaltungs-emulationsdienste bieten auch einen Anschluß von Ausrüstun-gen, die momentan Standleitungen zur Verbindung mit einemATM-Backbone-Netzwerk einsetzen. AAL1 benötigt eine Ti-ming-Synchronisation zwischen Quelle und Ziel. Deshalb istAAL1 von einem Medium wie SONET abhängig, das eineTaktung unterstützt. Der AAL1-Prozeß bereitet Zellen in dreiSchritten für die Übertragung vor. Zuerst werden synchroneSamples in das Nutzlastfeld eingefügt (1 Datenbyte mit einerSamplingrate von 125 µs). Zweitens werden die Felder Se-quence Number (SN) und Sequence Number Protection (SNP)ergänzt, so daß der empfangende AAL1 mit Hilfe der Zusatz-informationen die Richtigkeit der Reihenfolge überprüfenkann. Der Rest des Nutzdaten-Feldes wird mit einzelnen Bytesauf 48 Byte aufgefüllt. Bild 18.8 zeigt, wie AAL1 die Zelle fürdie Übertragung vorbereitet.


Hdr SN SNP …

.

.

.

53 Byte

ATM-Zelle

18.6.3 ATM-Anpassungsschichten: AAL3/4

AL3/4 unterstützt sowohl verbindungsorientierte als auch ver-bindungslose Daten. Es wurde für Netzwerk-Dienstanbieterentwickelt und steht in engem Zusammenhang mit demSwitched Multimegabit Data Service (SMDS). AAL3/4 wirdfür den Versand von SMDS-Paketen über ein ATM-Netzwerkeingesetzt.

AAL3/4 bereitet Zellen in drei Schritten für die Übertragungvor. Zuerst erzeugt der Convergence Sublayer eine ProtocolData Unit (PDU), indem er dem Frame einen Start/End-Tag-Header voranstellt und ein Längenfeld anhängt. Danach frag-mentiert der Segmentation and Reassembly Sublayer (SAR)die PDU und stellt ihr einen Header voran. Dann ergänzt derSAR-Sublayer einen CRC-10-Anhang zur Fehlerkontrolle anjedes PDU-Fragment. Abschließend erhält die komplette SAR-PDU das Nutzlast-Feld einer ATM-Zelle, welcher der ATM-Schicht den Standard-ATM-Header voranstellt.

Eine AAL-3/4-SAR-PDU-Header enthält Felder für Typ, Se-quenznummer und Multiplexing Identifier. Typ zeigt, ob eineZelle Anfang, Fortsetzung oder Ende einer Meldung enthält.Die Sequenznummer gibt die Reihenfolge an, in der die Zellenwieder zusammengesetzt werden sollen. Der MultiplexingIdentifier gibt an, welche Zellen aus unterschiedlichen Quellenam gleichen VCC verschachtelt sind, so daß am Ziel die rich-tigen Zellen wieder verbunden werden.

Bild 18.8:AAL1 bereitetdie Zelle fürdie Übertra-gung vor


18.6.4 ATM-Anpassungsschicht: AAL5

AAL5 ist der primäre AAL für Daten und unterstützt sowohlverbindungsorientierte als auch verbindungslose Daten. Erwird für die Übertragung der meisten Nicht-SMDS-Datenüber ATM und LAN-Emulation (LANE) verwendet, wie z.B.das klassische IP. AAL5 ist als eine einfache und effiziente An-passungsschicht bekannt (SEAL), weil der SAR-Sublayer dieCS-PDU einfach annimmt und ohne Ergänzung zusätzlicherFelder in 48-Byte-SAR-PDUs umwandelt.

AAL5 bereitet eine Zelle in fünf Schritten für die Übertragungvor. Als erstes ergänzt der CS-Sublayer den Frame mit einemPolster variabler Länge und einem 8 Byte langen Anhang. DasPolster stellt sicher, daß die entstandene PDU in die 48 Byteeiner ATM-Zelle paßt. Der Anhang enthält die Länge desFrame und einen 32-Bit-CRC, der aus der gesamten PDU be-rechnet wurde. Dies ermöglicht es dem AAL5-Empfänger,Bitfehler, verlorene Zellen und Zellen, die in der falschen Rei-henfolge ankommen, zu erkennen. Danach unterteilt der SAR-Sublayer die CS-PDU in 48 Byte lange Blöcke. Es wird keinHeader oder Anhang ergänzt (wie etwa in AAL3/4), so daßkeine Meldungen verschachtelt werden können. Abschließendverpackt die ATM-Schicht jeden Block in ein Nutzdaten-Feldeiner ATM-Zelle. Für alle Zellen, bis auf die letzte, wird einBit im Feld Nutzdaten-Typ auf Null gesetzt, um anzuzeigen,daß die Zelle nicht die letzte innerhalb einer Serie ist, die eineneinzelnen Frame darstellt. In der letzten Zelle ist dieses Bit auf1 gesetzt.

18.7 ATM-Adressierung

Der ITU-T-Standard basiert auf der Verwendung von E.164-Adressen (ähnlich wie Telefonnummern) für öffentliche ATM-(BISDN-)Netzwerke. Das ATM-Forum erweiterte die ATM-Adressierung um den Einsatz in privaten Netzwerken. Es ent-schied sich dabei für das Subnet oder Overlay-Modell derAdressierung, in dem die ATM-Schicht für die Zuordnung vonNetzwerk-Adressen zu ATM-Adressen verantwortlich ist. DasSub-Netzwerk ist eine Alternative zum Einsatz von Proto-kolladressen auf Netzwerk-Schicht-Ebene (wie bei IPX und IP)und zu bereits vorhandenen Routing-Protokollen (wie IGRP


und RIP). Das ATM-Forum definiert ein Adreßformat auf Ba-sis der Struktur von »Network Service Access Point«-Adressen(NSAP).

18.7.1 Sub-Netzwerk-Modell der Adressierung

Das Sub-Netzwerk-Modell der Adressierung entkoppelt dieATM-Schicht von anderen höheren Netzwerkschichten wiebeispielsweise IP oder IPX. Als solches benötigt es ein völligneues Adressierungsschema und Routing-Protokoll. AllenATM-Systemen muß zusätzlich zu den Adressen der oberenSchichten eine ATM-Adresse zugewiesen sein. Dies erfordertein ATM address resolution protocol (ATM-ARP), um dieAdressen der oberen Schichten mit ihren ATM-Adressen inVerbindung bringen zu können.

18.7.2 NSAP-Format-ATM-Adresse

Die 20-Byte-NASP-Format-ATM-Adressen sind für den Ge-brauch von privaten Netzwerken konzipiert, während in öf-fentlichen Netzwerken typischerweise E.164-Adressen ver-wendet werden, deren Formatierung von ITU-T definiert ist.Das ATM-Forum hat keine NSAP-Entschlüsselung für E.164-Adressen spezifiziert, was für die Entschlüsselung der E.164-Adressen in privaten Netzwerken benötigt wird.

Derartige private Netze können ihre eigene Adressierung imNSAP-Format auf Basis der E.164-Adresse des öffentlichenUser-Network Interface (UNI) bilden, mit dem sie verbundensind, und sie können ihr Adreßprefix aus der E.164-Nummerbilden, wobei lokale Knoten durch die niederwertigen Bitsidentifiziert werden.

Alle ATM-Adressen im NSAP-Format enthalten drei Bestand-teile, den Authoritiy and Format Identifier (AFI), den InitialDomain Identifier (IDI) und den Domain Specific Part (DSP).Der AFI gibt Typ und Format des IDI an, welcher wiederumdie Adreßzuordnung und Verwaltungsautorität angibt. DerDPS enthält aktuelle Routing-Informationen.

Die drei ATM-Adressierungsformate unterscheiden sich inAbhängigkeit von AFI und IDI. Im nach NSAP kodiertenE.164-Format ist der IDI eine Nummer. Im DCC-Format istder IDI ein Data Country Code (DCC), der bestimmte Länder


kennzeichnet, wie in der ISO 3166 festgelegt. Diese Adressenwerden durch den ISO-National Members Body jedes Landesverwaltet. Im ICD-Format ist der IDI ein International CodeDesignator (ICD), der von der ISO-6523-Registrierungsbe-hörde (dem British Standards Institute) zugeordnet wird. ICD-Codes identifizieren bestimmte nationale Organisationen.

Das ATM-Forum empfiehlt, daß Organisationen und Dienst-anbieter mit privaten Netzwerken entweder DCC oder ICDfür die Erstellung eines eigenen Numerierungsplans verwen-den.

Bild 18.9 zeigt die drei Formate für ATM-Adressen in privatenNetzwerken.

DCCAFI SELHO-DSP ESI

DCC-ATM-Format

ICDAFI SELHO-DSP ESI

ICD-ATM-Format

E.164AFI SELHO-DSP ESI

NASP-Format E.164

- - - IDP - - - -

- - IDI - -

- - - IDP - - - -

- - IDI - -

- - - - - - - - - - - IDP - - - - - - - - - - -

- - - - - - - - IDI - - - - - - - -

18.7.3 ATM-Adreßfelder

Die folgenden Beschreibungen geben einen Überblick zu denin Bild 18.9 gezeigten Feldern:

Authority and Format Identifier (AFI) – Identifiziert Typ undFormat der Adresse (E.164, ICD oder DCC).

Data Country Code (DCC) – Identifiziert bestimmte Länder.

Bild 18.9:In privaten

Netzwerkenwerden drei

Formate vonATM-Adressen

verwendet


High Order Domain Specific Part (HO-DSP) – Kombiniertdie Routing Domain (RD) und Area Identifier (AREA) derNSAP-Adresse. Das ATM-Forum kombiniert diese Felder zurUnterstützung einer flexiblen Adressierungshierarchie aufmehreren Ebenen für Prefix-basierte Routing-Protokolle.

End System Identifier (ESI) – Legt die 46 Bit lange MAC-Adresse entsprechend dem Institute of Electrical and Electro-nic Engineers (IEEE) fest.

Selector (SEI) – Wird für die lokale Verteilung in den Endsta-tionen verwendet und hat keine Bedeutung für das Netzwerk.

International Code Designator (ICD) – Gibt bestimmte inter-nationale Organisationen an.

E.164 – BISDN-E.164-Adresse.

18.8 ATM-Verbindungen

ATM unterstützt zwei Verbindungstypen: Point-to-Point undPoint-to-Multipoint.

Point-to-Point verbindet zwei ATM-Endsysteme und kannunidirektional (in einer Richtung) oder bidirektional (in bei-den Richtungen) sein. Point-to-Multipoint verbindet ein ein-zelnes Quell-Endsystem (als Root-Knoten bezeichnet) mitmehreren Ziel-Endsystemen (als Leaves [Blätter] bezeichnet).Solche Verbindungen sind immer unidirektional. Root-Knotenkönnen zu Leaves übertragen, aber Leaves können nicht mitdem Root oder miteinander über die gleiche Verbindungkommunizieren. Die Vervielfältigung der Zellen findet imATM-Netzwerk durch die ATM-Switches statt, wenn die Ver-bindung auf zwei oder mehr Zweige aufgeteilt wird.

Es wäre wünschenswert, in ATM-Netzen bidirektionale Multi-point-to-Multipoint-Verbindungen aufbauen zu können. Sol-che Verbindungen wären mit den Broadcasting- oder Mul-ticasting-Fähigkeiten von verteilten LANs, wie Ethernet undToken-Ring, vergleichbar. In verteilten LANs ist Broadcastingeinfach zu realisieren, weil alle Knoten eines LAN-Segmentsalle in diesem Segment versendeten Pakete bearbeiten müssen.Mit AAL5 (der verbreitetsten ATM-Anpassungsschicht) kanneine solche Lösung zur Multipoint-to-Multipoint-Übertragung


leider nicht realisiert werden. Anders als AAL3/4 mit seinemMessage Identifier Field, stellt AAL5 in seinem Zellenformatkeine Möglichkeit bereit, Zellen aus verschiedenen AAL5-Paketen in einer einzigen Verbindung zu verschachteln. Diesbedeutet, daß alle AAL5-Pakete, die über eine bestimmte Ver-bindung an ein bestimmtes Ziel gesendet werden, nacheinan-der empfangen werden müssen. Sonst ist der Wiederherstel-lungsprozeß am Ziel nicht in der Lage, die Pakete wieder zuverbinden. Deshalb können AAL5-Point-to-Multicast-Verbin-dungen nur unidirektional sein. Wenn ein Leaf-Knoten einAAL5-Packet in die Verbindung sendet, würde dieses bei-spielsweise von dem Root-Knoten und ebenso von den ande-ren Leaf-Knoten empfangen. Dabei würden sich Pakete, dievom Root-Knoten stammen, mit Paketen von anderen Leaf-Knoten überlagern, wodurch die Wiederherstellung aller ver-schachtelten Pakete unmöglich würde.

18.9 ATM und Multicasting

ATM benötigt eine Multicast-Fähigkeit. AAL5 (der verbreitet-ste Daten-AAL) unterstützt momentan keine verschachteltenPakete und somit auch kein Multicasting.

Wenn ein Leaf-Knoten ein Paket an eine AAL5-Verbindungschickt, kann es vorkommen, daß das Paket mit anderen Pake-ten vermischt wird und falsch wieder zusammengesetzt wird.Es wurden drei Methoden zur Lösung dieses Problems vorge-schlagen: VP-Multicasting, Multicast-Server und Overlaid-Point-to-Multipoint-Verbindung.

Bei der ersten Lösung verbindet ein Multipoint-to-Multipoint-VP alle Knoten der Multicast-Gruppe. Jedem Knoten wird einin diesem VP einmaliger Virtual Channel Identifier (VCI) zu-geordnet. Von nun an können verschachtelte Pakete eindeutignach dem VCI-Wert der Quelle identifiziert werden. Allerdingswürde dieser Mechanismus ein Protokoll zur eindeutigen Zu-ordnung von VCI-Codewerten erfordern, und ein solches Pro-tokoll existiert momentan nicht. Es ist auch unklar, ob vor-handene Segmentierungs- und Wiederherstellungsgeräte (SAR)einen solchen Betriebsmodus unterstützen könnten.

Ein Multicast-Server ist ein anderer Lösungsansatz für dasProblem des Multicasting über ein ATM-Netzwerk. In diesem


Fall stellen alle Knoten, die in einer Multicast-Gruppe sendenwollen, eine Verbindung zu einem externen Gerät, dem soge-nannten Multicast-Server, her (der besser als Serilisierer oderUmordner beschrieben werden kann). Der Multicast-Server istseinerseits an alle Knoten, die Multicast-Pakete empfangenwollen, über eine Point-to-Multicast-Verbindung angeschlos-sen. Der Multicast-Server empfängt Pakete über eine Point-to-Point-Verbindung und sendet diese anschließend über einePoint-to-Multipoint-Verbindung weiter, nachdem er sicherge-stellt hat, daß die Pakete serialisiert wurden (d.h. jedes Paketwird komplett übertragen, bevor das nächste gesendet wird).So wird eine Verschachtelung der Zellen ausgeschlossen.

Eine Overlaid-Point-to-Multipoint-Verbindung stellt die dritteLösung für das Problem des Multicasting über ein ATM-Netzwerk dar. In diesem Fall stellen alle Knoten einer Multi-cast-Gruppe eine Point-to-Multipoint-Verbindung zu jedemanderen Knoten der Gruppe her und werden damit Leaves(Blätter) in den entsprechenden Verbindungen der anderenKnoten. Damit können alle Knoten miteinander kommuni-zieren. Bei dieser Lösung muß jeder Knoten eine Verbindungmit jedem sendenden Mitglied der Gruppe aufbauen, währendder Multicast-Server-Mechanismus nur zwei Verbindungenerfordert. Es wäre außerdem ein Registrierungsprozeß erfor-derlich, der die Knoten informiert, die einer Gruppe von ande-ren Knoten beitreten, so daß die neuen Knoten die Point-to-Multipoint-Verbindung herstellen können. Die anderen Kno-ten müssen auch von dem neuen Knoten erfahren, so daß sieihn zu ihren Point-to-Multipoint-Verbindungen ergänzen kön-nen. Der Multicast-Server-Mechansimus ist im Sinne der Ver-bindungsresourcen besser skalierbar, benötigt aber einen zen-tralen Umordner, der sowohl ein möglicher Engpaß als auchein Punkt ist, dessen Ausfall einem Totalausfall gleichkommt.

18.10 ATM Quality of Service (QoS)

ATM unterstützt Garantien für die Qualität des Dienstes.Dazu gehört der Traffic-Contract, Traffic-Shaping und Traffic-Policing.

Ein Traffic-Contract legt einen Umschlag fest, der den geplan-ten Datenfluß beschreibt. Dazu gehört u.a. die maximale


Bandbreite, die mittlere ständige Bandbreite und die Burst-Größe. Wenn ein ATM-Endsystem eine Verbindung mit einemATM-Netz aufbaut, geht es einen auf den QoS-Parameternbasierenden Vertrag mit dem Netzwerk ein.

Als Traffic-Shaping bezeichnet man den Einsatz von Warte-schlangen zur Einschränkung von Daten-Bursts, Begrenzungder Spitzenübertragungsrate sowie Glättung von Jittern, sodaß der Verkehr die zugestandenen Rahmenbedingungen nichtüberschreitet. ATM-Geräte sind für die Einhaltung des Ver-trags im Sinne des Traffic-Shaping verantwortlich. ATM-Swit-ches können Traffic-Policing einsetzen, um die Einhaltung desVertrags zu erzwingen. Der Switch kann den Datenfluß mes-sen und mit dem bei Verbindungsaufbau verhandelten Wertdes Umschlags vergleichen. Stellt der Switch fest, daß der Da-tenfluß die abgesprochenen Parameter überschreitet, kann erdie Cell-Loss-Priority-Bits (CLP) der betroffenen Zellen setzen.Dadurch wird es legalisiert, die Zelle zu verwerfen, was jederfolgende Switch in Blockierungssituationen ausführen kann.

18.11 ATM-Signalisierung undVerbindungsaufbau

Wenn ein ATM-Gerät eine Verbindung zu einem anderenATM-Gerät aufbauen will, sendet es eine Signalisierungsan-forderung an seinen direkt angeschlossenen ATM-Switch.Diese Anforderung enthält die ATM-Adresse des gewünschtenATM-Endpunkts sowie einige für die Verbindung notwendigeQoS-Parameter.

ATM-Signalisierungsprotokolle sind vom Typ der ATM-Ver-bindung abhängig, es können User-Network-Interface-(UNI-)oder Network-Node-Interface-(NNI-)Signale sein. UNI wirdzwischen ATM-Endsystem und ATM-Switch über ATM-UNIverwendet, während NNI bei NNI-Verbindungen eingesetztwird.

Die UNI-3.1-Spezifikation des ATM-Forums ist der aktuelleStandard für ATM-UNI-Signalisierung. Die UNI-3.1-Spezifi-kation basiert auf dem Q.2931-Public-Network-Signaling-Protocol des ITU-T. UNI-Signalisierungsanforderungen wer-den mit der bekannten Standardverbindung übertragen:VPI=0, VPI=5.


Momentan existieren nur Standards für die ATM-UNI-Signa-lisierung, aber die Standardisierung wird mit NNI fortgesetzt.

18.11.1 ATM-Verbindungsaufbau

Die ATM-Signalisierung verwendet die One-Pass-Methode, diein allen modernen Telekommunikationsnetzen (wie dem Tele-fonnetz) eingesetzt wird. Ein ATM-Verbindungsaufbau läuftwie folgt ab. Als erstes sendet das Quell-Endsystem eine An-forderung in Form eines Verbindungssignals. Die Anforderungzum Verbindungsaufbau wird über das Netzwerk verbreitet.Infolgedessen wird über das Netzwerk eine Verbindungaufgebaut. Letztendlich erreicht die Anforderung das Ziel,welches die Verbindungsanforderung annehmen oder ableh-nen kann.

18.11.2 Routing und Verhandlung derVerbindungsanforderung

Das Routing der Verbindungsanforderung wird durch einATM-Routing-Protokoll geregelt (dieses vermittelt Verbindun-gen aufgrund der Ziel- und Quelladressen). Der Datenverkehrund die QoS-Parameter dafür werden durch das Quell-Endsy-stem bereitgestellt. Die Verhandlung einer Verbindungsanfor-derung ist nur eingeschränkt möglich, weil das Call-Routingvon den Anfangsparametern abhängig ist. Eine Änderung derParameter kann Rückwirkungen auf das Routing der Verbin-dung haben. Bild 18.10 erklärt die One-Pass-Methode für denATM-Verbindungsaufbau.

ATM- Switch 3

ATM- Switch 2

ATM- Switch 1

Verbindung zu B?

Ja

Verbindung zu B?

Ja

Verbindung zu B?Ja

Verbindung zu B?

Ja

Bild 18.10:ATM-Gerätebauen mitHilfe einerOne-Pass-Methode Ver-bindungen auf


18.12 ATM-Meldungen für dieVerbindungsverwaltung

Für den Aufbau und Abbruch einer ATM-Verbindung wirdeine Gruppe von Meldungen verwendet, zu der auch Setup,Call-Proceeding, Connect und Release gehört. Das Quell-End-system sendet eine Setup-Meldung (mit der Adresse des Ziel-endsystems und den QoS-Parametern), wenn es eine Verbin-dung aufbauen will. Der Anschluß-Switch aus dem Netz sen-det als Antwort auf diese Setup-Meldung eine Call-Procee-ding-Meldung zurück. Als nächstes sendet das Ziel-Endsystemeine Connect-Meldung, wenn die Verbindung angenommenwurde oder eine Release-Meldung, wenn die Verbindungabgelehnt wurde. Es gibt damit die Verbindung wieder frei.

Die Meldungen für die Verbindungsverwaltung werden wiefolgt für den Aufbau einer ATM-Verbindung verwendet: Alserstes sendet das Quell-Endsystem eine Setup-Meldung, wel-che an den ersten ATM-Switch (den Anschluß-Switch) desNetzwerks weitergeleitet wird. Dieser Switch sendet daraufhineine Call-Proceeding-Meldung und ruft ein ATM-Routing-Protokoll auf. Die Signalisierungsanforderung wird über dasNetz verbreitet. Der Ausgangs-Switch aus dem Netz (auch alsEgress-Switch bezeichnet), der mit dem Ziel-Endsystem ver-bunden ist, empfängt die Setup-Meldung. Der Egress-Switchleitet die Setup-Meldung über sein UNI an das Ziel-Endsystemweiter, worauf dieses eine Connect-Meldung sendet, wenn esdie Verbindung annimmt. Die Connect-Meldung durchquertdas Netz auf demselben Weg zurück zum Quell-Endsystem,welches eine Connect-Acknowledge-Meldung zurück an dasZiel sendet und damit die Verbindung bestätigt. Danach kanndie Datenübertragung beginnen.

18.13 LAN-Emulation (LANE)

Die LAN-Emulation ist ein Standard des ATM-Forums, derüber ATM verbundenen Stationen die gleichen Möglichkeitenbieten soll, wie die gewöhnlichen LANs (z.B. Ethernet undToken Ring). Wie der Name bereits andeutet, besteht die Auf-gabe des LANE-Protokolls in der Emulation eines LAN aufBasis eines ATM-Netzwerks. Das LANE-Protokoll stelltMechanismen zur Emulation eines »IEEE 802.3«-Ethernet


oder eines 802.5-Token-Ring-LAN bereit. Das aktuelle LANE-Protokoll sieht keine separate Kapselung für FDDI vor (d.h.,FDDI-Pakete müssen mit Hilfe von Translational-Bridges inEthernet oder Token-Ring-LAN umgewandelt werden). FastEthernet und IEEE 802.12 (100VG-AnyLAN) können beideohne Änderung abgebildet werden, weil sie das gleiche Paket-format verwenden. Bild 18.11 stellt echtes LAN und ELANgegenüber.

Das LANE-Protokoll legt eine Diensteschnittstelle für die hö-here Schicht fest (d.h. die Netzwerk-Schicht), welche identischmit der vorhandener LANs ist. Daten werden für den Versandüber das ATM-Netzwerk in das entsprechende LAN-MAC-Paketformat verpackt. Vereinfacht gesagt, das LANE-Protokoll läßt ein ATM-Netzwerk so aussehen und auftreten,wie ein Ethernet oder Token-Ring-Netzwerk, obwohl es we-sentlich schneller ist als aktuelle Ethernet oder Token-Ring-Netzwerke.

Emuliertes LAN

Physikalisches LAN

ATM-Netzwerk

Es ist wichtig zu verstehen, daß LANE nicht versucht, das je-weilige MAC-Protokoll des vorhandenen LAN zu emulieren(d.h. CSMA/CD für Ethernet oder Token-Passing für IEEE802.5). LANE verlangt keine Anpassung von Protokollen hö-herer Schichten für deren Betrieb über ein ATM-Netzwerk.Weil der LANE-Dienst der Netzwerk-Schicht die gleichenSchnittstellen wie die vorhandenen MAC-Protokolle bereit-stellt (wie NDIS- oder ODI-artige Treiberschnittstellen), sindan diesen Treibern keine Änderungen erforderlich.

Bild 18.11:ATM-Netz-werke könnenein echtes LANemulieren


18.13.1 LANE-Protokoll-Architektur

Die Hauptaufgabe des LANE-Protokolls ist die Umwandlungder MAC-Adressen in ATM-Adressen. Das Ziel dabei ist, dieAdressen so zuzuordnen, daß LANE-Endsysteme Direktver-bindungen für die Datenübertragung untereinander einrichtenkönnen, um dann die Daten weiterzuleiten. Das LANE-Proto-koll wird durch zwei an ATM angeschlossene Ausrüstungeneingesetzt: ATM-Netzwerkkarten (engl. network interfacecards, kurz NIC) und netzübergreifende und LAN-Switching-Technik.

ATM-NICs setzen das LANE-Protokoll und die Schnittstellezum ATM-Netz um, stellen dabei den angeschlossenen End-systemen die jeweilige LAN-Diensteschnittstelle zu Proto-kolltreibern für die höhere Schicht bereit. Die Netzwerk-Schicht-Protokolle der Endsysteme kommunizieren miteinan-der, als wären sie über ein gewohntes LAN unter Verwendungder gewohnten Prozeduren verbunden. Allerdings sind sie inder Lage, die wesentlich größere Bandbreite des ATM-Netz-werks auszunutzen.

Die zweite Klasse von Netzwerk-Ausrüstungen, die LANE ein-setzen, sind mit ATM verbundene LAN-Switches und Router.Diese Geräte werden im Verbund mit direkt angeschlossenenund mit ATM-NICs ausgerüsteten ATM-Hosts verwendet, umunabhängig vom wirklichen Ort einen virtuellen LAN-Dienstanzubieten, bei dem den Anschlüssen der LAN-Switches ein-zelne virtuelle LANs zugewiesen werden. Bild 18.12 zeigt dieLANE-Protokoll-Architektur, wie sie in ATM-Netzwerk-Aus-rüstungen eingesetzt wird.

Das LANE-Protokoll nimmt keinen Einfluß auf ATM-Swit-ches. LANE ist wie die meisten anderen ATM-Netzwerkpro-tokolle nach dem Overlay-Modell aufgebaut, d.h., dieLANE-Protokolle funktionieren transparent durch und überATM-Switches, wobei sie nur die standardisierten ATM-Signalisierungsprozeduren verwenden.


Phy

ATM

AAL 5

LANE

UNI-Signalisierung

NDIS/ODI

IP/IPX etc.

LANE

UNI-Signalisierung

Phy

ATM

Phy

ATM

Phy

ATM

Phy

MACAAL 5

ATM-Switch Schicht-2-LAN-Switch

LAN-HostATM-Host mitLANE-NIC

802.1D

Protokolle derhöheren Schichten

Phy

Protokolle derhöheren Schichten

MAC

NDIS/ODI

IP/IPX etc.

18.13.2 Bestandteile des LANE

Das LANE-Protokoll definiert die Funktion eines einzelnenemulierten LAN (ELAN). (Ein ELAN ist ein Äquivalent zumvirtual LAN [VLAN].) Obwohl in einem ATM-Netzwerkmehrere LANs vorhanden sein können, emuliert ein ELANentweder ein Ethernet oder ein Token-Ring-Netz. Es bestehtaus den folgenden Bestandteilen:

− LAN Emulation Client (LEC) – Der LEC ist ein Element einesSystems, das für die Datenweiterleitung, Adreßauflösung undRegistrierung von MAC-Adressen des LAN-Emulation-Server (LES) zuständig ist. Der LEC stellt gewöhnlichen LANsaußerdem eine LAN-Standardschnittstelle zu höheren Proto-kollebenen bereit. Ein ATM-Endsystem verwendet für dieVerbindung mit mehreren ELANs je einen LEC pro LAN.

− LAN-Emulation Server (LES) – der LES stellt den LECs ei-nen zentralen Steuerungspunkt zur Weiterleitung von Regi-strierungen und Steuerinformationen bereit. (Pro ELAN istnur ein LES vorhanden.)

− Broadcast and Unknown Server (BUS) – Der BUS ist einMulticast-Server, der für die Verteilung von Verkehr mit unbe-kannter Zieladresse sowie Multicast- und Broadcast-Verkehran die Clients eines bestimmten LAN zuständig ist.

− LAN Emulation and Configuration Server (LECS) – DerLECS verwaltet eine Datenbank von LECs und der LANs,

Bild 18.12:Die LANE-Protokoll-Architektur,kann in ATM-Netzwerk-Ausrüstungeneingesetztwerden


zu denen diese gehören. Der Server nimmt Anfragen vonLECs an und antwortet mit dem entsprechenden LAN-Identifikator, d.h. der ATM-Adresse des LES, der das ent-sprechende ELAN verwaltet. Ein LECS pro administrativerDomain verwaltet alle ELANs innerhalb dieser Domain.

LAN-Emulations-Clients LAN-Emulations-Server

LAN EmulationServer (LES)

ATM-Host

Schicht-2- LAN-Switch

Router

LAN Emulation ConfigurationServer (LECS)

Broadcast andUnknown

Server (BUS)

ATM-Netzwerk

18.13.3 Verbindungsarten der LAN-Emulation

Die LANE-Elemente der Phase 1 kommunizieren mit Hilfeeiner Gruppe von ATM-Virtual Circuit Connections (VCCs)miteinander. LECs verwalten die getrennten Verbindungen fürden Daten- und Steuerungsverkehr. Die LANE-Datenverbin-dungen sind Data-Direct-VCC, Multicast-Send-VCC undMulticast-Forward-VCC.

Data-Direct-VCC ist ein bidirektionaler Point-to-Point-VCC,der zwischen zwei LECs eingerichtet wird, die Daten austau-schen wollen. Zwei LECs verwenden üblicherweise den glei-chen Data-Direct-VCC zur Übertragung aller Pakete zwischenihnen, statt einen neuen VCC für jedes MAC-Adreßpaar zuöffnen. Diese Technik spart Ressourcen beim Verbindungs-aufbau und der Einrichtung.

Multicast-Send-VCC ist ein bidirektionaler Point-to-Point-VCC, der vom BUS für den LEC eingerichtet wird.

Multicast-Forward-VCC ist ein unidirektionaler VCC, dervom BUS für den LEC eingerichtet wird. Es handelt sich dabeiüblicherweise um eine Point-to-Multipoint-Verbindung, miteinem LEC als Leaf. Bild 18.14 zeigt die LANE-Datenverbin-dungen.

Bild 18.13:Ein ELANbesteht aus

Clients, Ser-vern und ver-

schiedenenZwischen-

knoten


LAN-Emulations-Datenverbindungen

Broadcast and Unknown Server (BUS)

Multicast ForwardVCC

Data Direct VCC

MulticastSend VCC

MulticastSend VCC

LAN-Switch

LANE-Client(LEC)

LANE-Client(LEC)

ATM-Host

Zu den Steuerungsverbindungen gehören Configuration-Direct-VCC, Control-Direct-VCC und Control-Distribute-VCC. Configuration-Direct-VCC ist ein bidirektionaler Point-to-Point-VCC, der vom LEC zum LECS eingerichtet wird.Control-Direct-VCC ist ein bidirektionaler VCC, der vomLEC zum LECS eingerichtet wird. Control-Distribute-VCC istein unidirektionaler VCC, der vom LES zurück zum LECführt (üblicherweise eine Point-to-Multipoint-Verbindung).Bild 18.15 zeigt die LANE-Steuerungsverbindungen.

LAN-Emulations-Steuerverbindungen

LANE-Server (LES)

LANE ConfigurationServer (LECS)

ConfigurationDirectVCC

ControlDistribute

VCC

ConfigurationDirectVCC

Control DirectVCC

ControlDirectVCC

LAN-Switch

LANE-Client(LEC)

LANE-Client(LEC)

ATM-Host

Bild 18.14:LANE-Daten-verbindungs-server verwen-den eineGruppe vir-tueller Schal-tungsverbin-dungen zurVerbindungvon LAN-Switch undATM-Hosts

Bild 18.15:LANE-Steue-rungsverbin-dungen ver-binden LES,LECS, LAN-Switch undATM-Host


18.13.4 LANE im Betrieb

Den Betrieb eines LANE-Systems und dessen einzelner Be-standteile versteht man am besten, wenn man die folgendenAbschnitte des LEC-Betriebs einzeln betrachtet: Initialisierungund Konfiguration, Beitritt und Registrierung beim LES,Suche und Beitritt zum BUS und Datenverkehr.

Initialisierung und Konfiguration

Nach der Initialisierung sucht ein LEC den LECS, um die be-nötigten Konfigurationsinformation zu erhalten. Es beginntmit diesem Vorgang, sobald der LEC seine eigene ATM-Adresse erhält, was üblicherweise während der Adreßregistrie-rung geschieht.

Dann muß der LEC den LECS finden. Dazu muß der LEC denLECS mit einer der folgenden Methoden suchen: mit Hilfe ei-ner vorgegebenen ILMI-Prozedur zur Bestimmung der LECS-Adresse, mit Hilfe einer bekannten LECS-Adresse oder übereine bekannte ständige Verbindung zum LECS (VPI=0,VCI=17).

Wenn der LECS gefunden ist, richtet der LEC einen Configu-ration-Direct-VCC zum LECS ein und sendet ein LE_CONFI-GURE_REQUEST. Wenn ein passender Eintrag gefundenwurde, antwortet der LECS dem LEC mit einem LE_CONFI-GURE_RESPONSE und den Konfigurationsinformationen,die dieser für die Verbindung zu seinem Ziel-ELAN benötigt.Dazu gehört: ATM-Adresse des LES, der Typ des zu emulie-renden LAN, die maximale Paketgröße im ELAN und derName des ELAN (ein Kurztext für Anzeigezwecke).

Beitritt und Registrierung beim LES

Wenn ein LEC dem LES beitritt und seine eigenen ATM- undMAC-Adressen registriert, geschieht dies wie folgt:

1. Nachdem der LEC die LES-Adresse erhalten hat, gibt erwahlweise die Verbindung zum LECS frei, richtet einenControl-Direct-VCC zum LES ein und sendet einenLE_JOIN_REQUEST an diesen VCC. Dies ermöglicht esdem LEC, seine eigenen ATM- und MAC-Adressen bei demLES zu registrieren und (wahlweise) weitere MAC-Adres-sen, für die er als Proxy läuft. Diese Informationen werden


so verwaltet, daß kein neuer LEC die gleichen MAC- oderATM-Adressen registriert.

2. Nach dem Empfang des LE_JOIN_REQUEST prüfen LECund LES die offene Verbindung, vergleichen die Anforde-rung und bestätigen die Mitgliedschaft des Client.

3. Nach einem erfolgreichen Vergleich fügt der LES den LECals Leaf seines Point-to-Multipoint-Control-Distribute-VCC ein und sendet dem LEC eine LE_JOIN_RESPONSEmit einer einmaligen LAN-Emulations-Client-ID (LECID).Die LECID wird vom LEC für die Filterung seiner eigenenBroadcasts aus dem BUS benötigt.

Suche und Beitritt zum BUS und Datenverkehr

Nachdem der LEC dem LECS beigetreten ist, besteht seine er-ste Aufgabe in der Suche der BUS-ATM-Adresse, um derBroadcast-Gruppe beizutreten und Mitglied des ELAN zuwerden. Als erstes erzeugt der LEC ein LE_ARP_REQUEST-Paket mit der MAC-Adresse 0xFFFFFFFF. Dann sendet derLEC dieses spezielle LE_ARP-Paket auf dem Control-Direct-VCC an den LES. Der LES erkennt, daß der LEC den BUSsucht, und antwortet mit der ATM-Adresse auf dem Control-Distribute-VCC.

Sobald der LEC die ATM-Adresse des BUS erhalten hat, tritter diesem BUS bei, indem er zuerst ein Signalpaket mit derAdresse des BUS erstellt und ein Multicast-Send-VCC mit demBUS aufbaut. Nach Empfang des Signals fügt der BUS denLEC als weiteres Leaf zu seiner Point-to-Multipoint-Multicast-Forward-VCC hinzu. Der LEC ist nun ein Mitglied des ELANund bereit für die Datenübertragung.

Datenübertragung

Das Endstadium, der Datentransfer, beinhaltet die Auflösungder ATM-Adresse des Ziel-LEC und die eigentliche Daten-übertragung, zu der auch die Flush-Prozedur gehören kann.

Wenn ein LEC ein Datenpaket an eine unbekannte Ziel-MAC-Adresse sendet, muß er die ATM-Adresse des Ziel-LEC her-ausfinden, über die diese spezielle Adresse erreicht werdenkann. Dazu sendet der LEC den Daten-Frame zuerst an denBUS (per Multicast-Send-VCC), damit dieser ihn per Multi-


cast-Forward-VCC an alle LECs des ELAN sendet. Dies ge-schieht, weil eine Auflösung der ATM-Adresse Zeit kostenwürde und viele Netzwerk-Protokolle keine Verzögerung tole-rieren.

Danach sendet der LEC einen Steuerungs-Frame mit einemLAN-Emulation Address Resolution Protocol Request(LE_ARP_Request) per Control-Direct-VCC an den LEC.

Wenn der LEC die Antwort hat, antwortet er mit der ATM-Adresse des LEC, der die gesuchte MAC-Adresse besitzt.Wenn der LEC die Antwort nicht kennt, gibt er die Anfrage aneinige oder auch alle LECs weiter (nach Regeln, die der Vertei-lung der jeweiligen Daten-Frames über den BUS ähnlich sind,aber per Control-Direct und Control-Distribute-VCCs, stattder Multicast-Send- und -Forward-VCCs des BUS). WennBridges/Switches mit LEC-Software im ELAN eingebundensind, dann übersetzen diese den ARP und leiten ihn an ihreLAN-Schnittstellen weiter.

Im Falle eines aktuellen Datentransfers richtet der LEC aufden Empfang eines LE_ARP eine Data-Direct-VCC zum Ziel-knoten ein und verwendet diese anstelle des Buspfads für dieDatenübertragung. Bevor dies geschehen kann, ist möglicher-weise die LANE-Flush-Prozedur auszuführen.

Die LANE-Flush-Prozedur stellt sicher, daß alle Pakete, dievorher an den BUS gesendet wurden, am Ziel abgeliefert wur-den, bevor der Data-Direct-VCC verwendet wird. Im Verlaufder Flush-Prozedur wird dem letzten Paket eine Steuerungs-zelle nachgeschickt. Der LEC wartet danach, bis das Ziel denEmpfang des Flush-Pakets bestätigt, bevor es den zweiten Pfadzum Senden der Pakete einsetzt.

19 Data-Link Switching

19.1 Grundlagen

Data-Link-Switching (DLSw) ist ein Hilfsmittel zur Übertra-gung von IBM Systems Network Architecture (SNA) undNetwork Basic Input/Output System (NetBIOS)-Datenverkehrüber ein IP-Netzwerk. Es dient als Alternative zum SourceRoute Bridging (SRB), einem Protokoll für die Übertragungvon SNA- und NetBIOS-Verkehr in Token-Ring-Umgebungen,das vor der Einführung von DLSw sehr verbreitet war. Grund-sätzlich dient DLSw zur Behebung einiger Fehler von SRB beibestimmten Übertragungsanforderungen – speziell bei An-wendung in WANs. Dieses Kapitel enthält eine Gegenüberstel-lung von DLSw und SRB sowie eine Zusammenfassung zu dendarunterliegenden Protokollen und stellt eine Übersichtgebräuchlicher Protokolloperationen bereit.

DLSw wurde als firmeneigene Lösung von IBM im Jahre 1992entwickelt. Es wurde dem IETF im Jahr 1993 erstmals alsRFC 1434 vorgelegt. Die detaillierte Dokumentation vonDLSw ist heute im IETF RFC 1795 festgelegt, der im April1995 vorgestellt wurde. DLSw ist eine gemeinsame Entwick-lung des Advanced Peer-to-Peer Networking (APPN), Imple-mentors Workshop (AIW) und der Data-Link Switching Rela-ted Interest Group (DLSw RIG).

KAPITEL 19Data-Link-Switching


RFC 1795 beschreibt die drei Primärfunktionen von DLSw:

− Das Switch-to-Switch Protocol (SSP) ist das Protokoll, daszwischen zwei DLSw-Knoten oder Routern ausgehandeltwird.

− Der Abschluß von SNA »Data-Link Control«-Verbindun-gen (DLC) führt zu einer Verringerung der Wahrscheinlich-keit von Timeouts innerhalb der Verbindungsschicht (engl.link-layer) von WANs.

− Die lokale Zuweisung von DLC-Verbindungen an eineDLSw-Schaltung.

− Alle diese Funktionen werden im folgenden Kapitel im De-tail behandelt.

Bild 19.1 zeigt eine verallgemeinerte DLSw-Umgebung.

TCP/IPWAN

19.2 DLSw im Vergleich mit Source-Route-Bridging

Der grundsätzliche Unterschied zwischen Source-Route-Brid-ging (SRB) und DLSw liegt in der Unterstützung des lokalenAbschlusses. Der SNA- und NetBIOS-Verkehr ist auf Emp-fangsbestätigungen und Meldungen zur Erhaltung der Verbin-dung in der Verbindungsschicht angewiesen, um die Integrität

Bild 19.1:Ein DLSw-

Kreis erleich-tert SNA-Con-nectivity überein IP-WAN

Kapitel 19 • Data-Link Switching 253

der Verbindung und Datenübertragung zu gewährleisten. Fürdie Verbindungsdaten schließt der lokale DLSw-Knoten oderRouter die Steuerung der Datenverbindung ab. Infolgedessenwird das WAN nicht durch Empfangsbestätigungen und Mel-dungen zur Erhaltung der Verbindung belastet. Im Gegensatzdazu funktioniert DLC für SRB auf einer Ende-zu-Ende-Basis,was die Wahrscheinlichkeit von DLC-Timeouts bei WAN-Verbindungen erhöht.

Obwohl Source-Route-Bridging in vielen Umgebungen einerealisierbare Lösung darstellt, ist der Nutzen von SRB für dieÜbertragung bei SNA und NetBIOS bei WAN-Anwendungenbeschränkt. Die folgenden Nachteile stechen dabei besondershervor:

− Einschränkung des SRB Hop-Counts auf 7 Hops (Sprünge)

− Punkt-zu-Mehrpunkt-Betriebs-Behandlung (von SRB Ex-plorer-Frames oder NetBIOS-Namensanfragen)

− Weiterleitung von überflüssigem Verkehr (Empfangsbestäti-gungen und Meldungen zur Erhaltung der Verbindung)

− Fehlende Flußsteuerung und Prioritätensetzung

Bild 19.2 zeigt eine SRB-Verbindung über ein WAN (Ende-zu-Ende).

TCP/IPWAN

Information

LLC-Typ-2-Empfangsbestätigung

End-to-End Data Link Control

Der lokale Abschluß von DLC-Verbindungen durch DLSw istin vielerlei Hinsicht vorteilhafter als SRB-basierte Umgebun-gen. Der lokale Abschluß von DLSw beseitigt die Notwendig-keit von Empfangsbestätigungen und Meldungen zur Erhal-

Bild 19.2:SRB bietet eineEnde-zu-Ende-Verbindungüber ein IP-WAN


tung der Verbindung innerhalb der Verbindungsschicht desWAN. Weiterhin verringert der lokale Abschluß die Wahr-scheinlichkeit von Timeouts. Außerdem stellt DLSw sicher,daß die Verbreitung von Explorer-Frames (Such-Frames)durch DLSw gesteuert wird, sobald das Zielsystem gefundenwurde. Bild 19.3 zeigt den Informationsfluß und die Verwen-dung lokaler Empfangsbestätigungen in einer DLSw-Umge-bung.

TCP/IPWAN

Information

Lokale LLC-Typ-2-Empfangsbestätigung

Lokale LLC-Typ-2-Empfangsbestätigun

19.3 DLSw-SNA-Unterstützung

Als weiteren Vorteil bringt DLSw eine breitere Geräte- undMedienunterstützung, als bisher mit SRB verfügbar war.DLSw schließt eine Reihe von typischen SNA-Umgebungenein und stellt eine LAN-Unterstützung nach IEEE 802.2 bereit,zu der auch die Unterstützung von SNA-»Physical Unit« (PU)2, PU 2.1 und PU-4-Systemen und NetBIOS-basierten Syste-men gehört.

DLSw unterstützt Synchronous Data-Link Control (SDLC)und deckt damit PU-2- (primary und secondary) und PU-2.1-Systeme ab. Bei SDLC-verbundenen Systemen stellt jede SDLC-PU für das DLSw-Switch-to-Switch-Protocol (SSP) ein einma-liges Media Access Control (MAC)/service access point (SAP)-Adreßpaar dar. In durch Token Ring verbundenen Systemenerscheinen DLSw-Knoten als Source-Route-Bridge. EntfernteToken-Ring-Systeme, auf die über einen DLSw-Knoten zu-gegriffen wird, werden als benachbarter Ring angesehen.Dieser Nachbarring wird als virtueller Ring bezeichnet und

Bild 19.3:DLSw verwen-

det lokaleEmpfangs-

bestätigungenzur Steuerung

des Daten-flusses


innerhalb jedes DLSw-Knotens erzeugt. Bild 19.4 zeigt ver-schiedene IBM-Knoten, die über ein TCP/IP-WAN mit DLSw-Geräten verbunden sind, wobei es sich in diesem Fall um Rou-ter handelt.

TCP/IPWAN

NetBIOS-System Typ-2-

Knoten

Typ-2.1-Knoten

19.4 DLSw-Switch-to-Switch Protocol (SSP)

Das Switch-to-Switch Protocol (SSP) wird als Protokoll zwi-schen DLSw-Knoten (Routern) für den Aufbau von Verbin-dungen, das Lokalisieren von Ressourcen, die Weiterleitungvon Daten sowie für Flußsteuerung und Fehlerkorrektur ver-wendet. Dies sind die wesentlichen Besonderheiten von DLSw.Im allgemeinen unterstützt SSP kein komplettes Routing zwi-schen Knoten, weil dies grundsätzlich durch allgemeine Rou-ting-Protokolle, wie RIP, OSPF oder IGRP/EIGRP abgedecktwird. Statt dessen vermittelt SSP Pakete auf der SNA-Siche-rungsschicht. Es verpackt außerdem Pakete per TCP/IP für dieÜbertragung in IP-basierten Netzwerken und verwendet TCPals Hilfsmittel für die zuverlässige Übertragung zwischenDLSw-Knoten. Bild 19.5 zeigt die Einordnung von SSP inner-halb der SNA-Architektur sowie im Verhältnis zum OSI-Refe-renzmodell.

Bild 19.4:Verbindungvon SNA-Kno-ten mit einemTCP/IP-WANüber DLSw


OSI

Netzwerk

Anwendung

Darstellung

Kommunikation

Transport

PhysicalBitübertragung

Datensicherung

SNA

Transaktionsdienste

Darstellungsdienste

Datenflußsteuerung

Übertragungssteuerung

Bitübertragung

Pfadkontrolle

Datenübertragungssteuerung

Switch-to-SwitchProtocol (SSP)

19.5 DLSw-Betrieb

DLSw beinhaltet verschiedene Betriebszustände. Zwei DLSw-Partner bauen zwei TCP-Verbindungen miteinander auf. DieseTCP-Verbindung ist die Grundlage der DLSw-Übertragung.Da TCP eine zuverlässige und garantierte Ankunft des IP-Ver-kehrs garantiert, stellt es auch die Übertragung und Integritätdes durch das IP-Protokoll gekapselten Datenverkehrs sicher,welcher in diesem Fall SNA- und NetBIOS-Verkehr ist. Nachdem Aufbau einer Verbindung tauschen die DLSw-Partnereine Liste der unterstützten Fähigkeiten aus. Dies ist besonderswichtig, wenn die DLSw-Partner von unterschiedlichen Her-stellern stammen. Als nächstes schalten die DLSw-Partner dieSNA- oder NetBIOS-Endsysteme durch, so daß der Informa-tionsfluß über die Durchschaltung hergestellt ist.

19.5.1 DLSw-Prozesse

Der gesamte DLSw-Betrieb kann in drei Grundkomponentenaufgeteilt werden: Austausch der Fähigkeiten, Herstellung derDurchschaltung und Flußsteuerung. Der Austausch der Fähig-keiten der DLSws schließt die Verhandlung von Informationenüber Fähigkeiten der DLSw-Sitzungen ein. Dieser Infor-mationsaustausch wird bei der Initialisierung der Sitzung undim Verlauf von Sitzungsoperationen ausgehandelt. Die Durch-schaltung der DLSws findet zwischen den Abschlußsystemenstatt. Dazu gehört die Zuordnung des Endsystems des Zielsund die Einrichtung der Datenübertragungssteuerung zwi-schen den Abschlußsystemen und deren lokalen Routern. DieDLSw-Flußsteuerung ermöglicht den Aufbau einer unabhän-

Bild 19.5:SSP wird den

Datensiche-rungskompo-

nenten vonSNA und OSI-

Referenzmodellzugeordnet


gigen, einseitigen Flußsteuerung zwischen den Partnern. Allediese Prozesse werden in den folgenden Abschnitten diskutiert.

Austausch der Fähigkeiten

Der Austausch der Fähigkeiten zwischen den DLSws basiertauf einer Switch-to-Switch-Steuerungsmeldung, welche dieFähigkeiten des sendenden Datenübertragungs-Switch be-schreibt. Steuerungsmeldungen mit den Fähigkeiten werdennach Aufbau der Switch-to-Switch-Verbindung oder zur Lauf-zeit ausgetauscht, wenn bestimmte Betriebsparameter verän-dert wurden, die an den Partner übergeben werden müssen.Im Verlauf des Austauschs der Fähigkeiten wird eine Anzahlvon Fähigkeiten ausgewiesen und verhandelt. Zu den zwi-schen den DLSw-Partnern ausgetauschten Fähigkeiten gehört:

− Die DLSw-Versionsnummer

− anfängliche Pacing-Fenstergröße (Empfangsfenstergröße)

− NetBIOS-Unterstützung

− Liste unterstützter Link-Service Access Points (SAPs)

− Anzahl der unterstützten TCP-Sitzungen

− MAC-Adreßliste

− NetBIOS-Namenslisten

− Suchrahmenunterstützung

DLSw-Verbindungsaufbau

Der Vorgang des Verbindungsaufbaus zwischen zwei Endsy-stemen schließt bei DLSw das Auffinden des Zielsystems unddie Einrichtung der Datenübertragungssteuerung zwischendem jeweiligen Endsystem und seinem lokalen Router ein. DerVerbindungsaufbau unterscheidet sich je nach Art des Daten-verkehrs.

Eine der DLSw-Hauptfunktionen besteht in der Bereitstellungvon Übertragungsmechanismen für SNA-Verkehr. Der SNA-Verbindungsaufbau durchläuft mehrere unabhängige Stadien.Als erstes suchen die Geräte eines LAN andere SNA-Geräte,indem sie einen Such-Frame mit der MAC-Adresse des SNA-Zielgeräts aussenden. Sobald ein DLSw-Internet-Knoten einen


Such-Frame empfängt, sendet dieser Knoten einen »canu-reach«-Frame an alle seine DLSw-Partner. Die Funktion diesesFrame besteht in der Abfrage aller DLSw-Partner, um fest-zustellen, ob das gesuchte Gerät gefunden werden kann. Wenneiner der DLSw-Partner die angegebene MAC-Adresse er-reicht, antwortet der Partner mit einem »icanreach«-Frame,der anzeigt, daß ein bestimmter DLSw-Partner einen Übertra-gungsweg zu dem gesuchten Gerät herstellen kann. Nachdemdie »canureach«- und »icanreach«-Frames ausgetauscht wur-den, stellen die beiden DLSw-Partner eine Verbindung her, dieaus einer Verbindung zur Datenübertragungssteuerung zwi-schen den Routern und dem lokal angeschlossenen SNA-End-system (für insgesamt zwei Verbindungen) und einer TCP-Ver-bindung zwischen den DLSw-Partnern besteht. Die ent-standene Schaltung wird durch die Quell- und Zielschaltungs-IDs eindeutig identifiziert. Jede SNA-DLSw-Schaltungs-ID be-inhaltet eine MAC-Adresse, einen Zugriffspunkt auf den Ver-bindungsservice (engl. link-service access point, kurz LSAP)und die Anschlußport-ID der Datenübertragungssteuerung(engl. data-link-control port ID). Die Priorität der Schaltungwird zum Zeitpunkt der Einrichtung der Schaltung verhandelt.

Der NetBIOS-Verbindungsaufbau läuft bis auf einige wenigeUnterschiede genauso ab wie der SNA-Verbindungsaufbau.Als erstes senden die DLSw-Knoten bei einem NetBIOS-Ver-bindungsaufbau eine Namensanfrage mit einem NetBIOS-Namen (statt eines »canureach«-Frame, der eine MAC-Adresse bestimmt). Weiterhin senden die DLSw-Knoten beimAufbau einer NetBIOS-Schaltung einen »name recognized«-Frame (statt eines »icanreach«-Frame).

DLSw-Flußsteuerung

DLSw-Flußsteuerung schließt adaptives Pacing zwischenDLSw-Routern ein. Im Verlauf der Verhandlung der Fluß-steuerung werden zwei unabhängige, einseitige Flußkontroll-mechanismen zwischen den DLSw-Partnern aufgebaut. Adap-tives Pacing nutzt einen Fenstersteuerungsmechanismus, dersich je nach Pufferverfügbarkeit dynamisch anpaßt. Fensterkönnen vergrößert, verkleinert, halbiert oder auf Null zurück-gesetzt werden. Dies ermöglicht es den DLSw-Knoten, dasDatenverkehrstempo durch das Netzwerk zu steuern undsomit die Integrität und Übergabe aller Daten zu sichern.


DLSw-Flußkontroll-Indikatoren

Die Anzahl der genehmigten Einheiten (Anzahl der Einheit,die der Absender senden darf) wird mit einer Flußkontrollan-zeige vom Empfänger erhöht (einer der verschiedenen mögli-chen Indikatoren). Die DLSw-Flußsteuerung stellt die folgen-den Indikatorfunktionen bereit:

− Repeat – (Wiederholen) erhöht die Anzahl der genehmigtenEinheiten um die aktuelle Fenstergröße.

− Increment – (Erhöhen) Vergrößert die Fenstergröße um 1und die Anzahl der genehmigten Einheiten um die neueFenstergröße.

− Decrement – (Verringern) Verkleinert die Fenstergröße um1 und die Anzahl der genehmigten Einheiten um die neueFenstergröße.

− Reset – (Zurücksetzen) Setzt das Fenster auf 0 und die ge-nehmigten Einheiten auf 0; dadurch wird die Übertragungin einer Richtung angehalten, bis ein Flußkontroll-Indika-tor »Erhöhen« gesendet wird.

− Half – (Halbieren) Halbiert die Fenstergröße und erhöhtdie Anzahl der genehmigten Einheiten um die neue Fen-stergröße.

Flußkontroll-Indikatoren und Flußkontroll-Empfangsbestäti-gungen können huckepack mit Informations-Frames oder alsunabhängige Flußsteuerung-Meldungen übertragen werden.Reset-Indikatoren werden immer als unabhängige Meldungenverschickt.

Beispiele für Adaptives Pacing

Beispiele für »Adaptive Pacing«-Kriterien sind u.a. Pufferver-fügbarkeit, Übertragungseffizienz, Länge der Sende-Warte-schlange und die Verkehrspriorität. Es folgen Beispiele dafür,wie diese im einzelnen auf das Pacing einwirken:

− Buffer availability – (Pufferverfügbarkeit) Wenn die ver-fügbaren Pufferspeicher eines Vermittlungsknotens einerDatenverbindung kritisch niedrig sind, kann der Knotendie Fenstergröße verringern, um den Datenfluß zu reduzie-ren. Mit der Vergrößerung der Pufferverfügbarkeit kann


der Knoten die Fenstergröße erhöhen, um den Datenflußzwischen den DLSw-Partnern zu beschleunigen.

− Transport utilization – (Übertragungseffizienz) Wenn dieVerbindung zwischen zwei DLSw-Partnern eine hohe Über-tragungseffizienz erreicht, kann die Fenstergröße zur Ver-ringerung der Ausnutzung verkleinert werden, um denVerlust von Paketen zwischen den Knoten zu verhindern.

− Outbound queue length – (Länge der Sende-Warte-schlange) Der von einem DLSw-Knoten weitergeleiteteVerkehr wird üblicherweise in eine Ausgangswarteschleifegeleitet, die durch einen Speicher gebildet wird, der für dieWeiterleitung des Verkehrs von einem Gerät zum anderenzuständig ist. Wenn diese Warteschlange einen bestimmtenSchwellwert erreicht oder sogar voll ist, kann die Anzahlder genehmigten Einheiten verringert werden, bis die Aus-nutzung der Warteschlange auf ein ausreichendes Niveaureduziert wurde.

− Trafficpriority – (Verkehrspriorität) Eine der speziellen Fä-higkeiten von SSP ist die Möglichkeit der Priorisierung desVerkehrs. Diese Prioritäten werden durch das »circuit-priority«-Feld im DLSw-Meldungs-Frame festgelegt. DurchFestlegung einer veränderlichen Anzahl von genehmigtenEinheiten für bestimmte DLSw-Schaltungen können dieKnoten die verschiedenen Prioritätsniveaus der einzelnenSchaltungen verwalten.

19.6 DLSw-Meldungsformate

Zwischen DLSw-Knoten werden zwei Formate für Meldungs-köpfe ausgetauscht:

− Control

− Information

Der Control-Meldungskopf wird für alle Meldungen, außerinformation frames (Iframes) und independent flow-controlmessages (IFCMs), verwendet, die im Informations-Formatverschickt werden.


Bild 19.6 zeigt das Format der DLSw-Control- und Informa-tion-Felder. Diese Felder werden in den folgenden Beschrei-bungen detailliert besprochen.

A

1

Feldlänge in Byte

B

1

C D

2 4

F G

2

E

4

P

6

P

6

X

4

Y

4

Z

4

AA

4

BB

4

CC

4

DD

4

H

1

L

1

M

1

N

1

O

1

I

1

J K

2

V

21

R

1

S

1

T

1

U W

211

DLSw-Control-Meldungsformat

DLSw-Control-Meldung (72 Byte)

DLSw-Informations- Meldung (16 Byte)

A = VersionsnummerB = Header-LängeC = MeldungslängeD = entfernter Datenübertragungs-

KorrelatorE = entfernte Anschluß-ID der

Datenübertragungssteuerung F = ReserviertG = MeldungstypH = Flußkontrolle-Byte

DLSw-Informations-Meldung (16 Byte)

A = VersionsnummerB = Header-LängeC = MeldungslängeD = entfernter Datenübertragungs- KorrelatorE = entfernte Anschluß-ID der

Datenübertragungssteuerung F = ReserviertG = MeldungstypH = Flußkontrolle-ByteI = Protokoll-IDJ = Header-NummerK = ReserviertL = Maximale Frame-GrößeM = SSP-FlagsN = VerbindugnsprioritätO = Meldungstyp

P = Ziel-MAC-AdresseQ = Ausgangs-MAC-AdresseR = Ausgangs-LSAPS = Ziel-LSAPT = Frame-RichtungU = ReserviertV = ReserviertW = Anschluß-ID der

DatenübertragungssteuerungY = Ursprungsanschluß-ID der

DatenübertragungssteuerungZ = Ursprungstransport-IDAA = Ziel-Datenübertragungs-

KorrelatorCC = Ziel-Transport-IDDD = 2 reservierte Felder

Der folgende Abschnitt ist eine Zusammenfassung der Felderaus Bild 19.6 (die Felder der ersten 16 Bytes aller DLSw-Mel-dungsköpfe sind gleich):

− Version Number – (Versionsnummer) Ein Wert von 0x31(ASCII 1) entspricht dem Dezimalwert 49 und gibt an, daßdas Gerät DLSw-Version 1 verwendet. Dies stellt die Kom-patibilität zwischen DLSw-Knoten mit verschiedenen Ver-sionen des DLSw-Standards für die Zukunft sicher. Mo-mentan nutzen alle Geräte DLSw-Version 1, weshalb diesesFeld immer den Dezimalwert 49 hat.

− Header-Länge – Ein Wert von 0x48 gibt bei Control-Mel-dungen einen Dezimalwert von 72 Byte an. Dieser Wertwird für Informations- und Independent-Flow-Control-

Bild 19.6: DLSw-Control- und -Informations-Frames haben die ersten 16 Bytesgemeinsam


Meldungen auf 0x10 gesetzt, was einem Dezimalwert von16 Bytes entspricht.

− Meldungslänge – Legt die Anzahl der Bytes fest, die imDatenfeld nach dem Header kommen.

− Entfernter Datenübertragungs-Korrelator – Bildet zusam-men mit der entfernten Anschluß-ID der Datenübertra-gungssteuerung eine 64 Bit lange Schaltungs-ID, welche dieDLC-Schaltung innerhalb eines DLSw-Knotens bestimmt.Die Schaltungs-ID wird lokal vergeben und ist innerhalbeines einzelnen DLSw-Knotens einmalig. Eine »end-to-end«-Schaltung wird durch ein Paar aus Schaltungs-IDs be-stimmt, welche eine einzelne »end-to-end«-Schaltung imVerbund mit den Datenübertragungs-IDs eindeutig be-stimmen. Jeder DLSw-Knoten besitzt eine Tabelle für dieseSchaltungs-ID-Paare: eine für das lokale Ende der Schal-tung und die andere für das entfernte Ende der Schaltung.Der entfernte Data-Link Correlator wird so wie der Data-Link Correlator des Ziels gesetzt, wenn das Frame-Direction-Feld gleich 0x01 ist. Er entspricht dem Data-Link Correlator der Quelle, wenn das Frame-Direction-Feld gleich 0x02 ist.

− Entfernte Anschluß-ID der Datenübertragungssteuerung –Bildet zusammen mit dem entfernten Correlator der Da-tenübertragungssteuerung eine 64 Bit lange Schaltungs-ID,welche die DLC-Schaltung innerhalb eines DLSw-Knotensbestimmt. Die Schaltungs-ID wird lokal vergeben und istinnerhalb eines einzelnen DLSw-Knotens einmalig. Eine»end-to-end«-Schaltung wird durch ein Paar aus Schal-tungs-IDs bestimmt, welche eine einzelne »end-to-end«-Schaltung im Verbund mit den Datenübertragungs-IDs ein-deutig bestimmen. Jedes DLSw-Gerät besitzt eine Tabellefür diese Schaltungs-ID-Paare: eine für das lokale Ende derSchaltung und die andere für das entfernte Ende der Schal-tung. Die entfernte DLC-Port-ID wird so wie die DLC-Port-ID des Ziels gesetzt, wenn das Frame-Direction-Feldgleich 0x01 ist. Sie entspricht der DLC-Port-ID der Quelle,wenn das Frame Direction-Feld gleich 0x02 ist.

− Meldungstyp – weist auf einen speziellen DLSw-Meldungs-typ hin. Der Wert wird in zwei verschiedenen Feldern(dezimaler Offset 14 und 23) des Control-Message-Kopfes


angegeben. Beim Empfang einer SSP-Meldung wird nur daserste Feld eingelesen. Das zweite Feld wird von neuen Rea-lisierungen empfangsseitig ignoriert, wurde aber der Rück-wärtskompatibilität zu Realisierungen nach RFC 1434wegen beibehalten und kann in zukünftigen Versionen beiBedarf verwendet werden.

− Flußkontrolle-Byte – Enthält den Flußkontrollindikator, dieEmpfangsbestätigung der Flußsteuerung und Operatorbitsder Flußsteuerung.

− Protokoll-ID – Gibt (falls auf sie 0x42 gesetzt ist) einenDezimalwert von 66 an.

− Header-Nummer – Gibt (falls auf sie 0x01 gesetzt ist) einenDezimalwert von 1 an.

− Maximale Frame-Größe – Überträgt die »MaximaleFrame-Größe«-Bits über die DLSw-Verbindung. DiesesFeld soll sicherstellen, daß die beiden Endstationen eineFrame-Größe für eine Verbindung verhandeln, die keineResegmentierung der Frames durch die DLSw-Partner er-forderlich macht.

− Switch-to-Switch Protocol (SSP)-Flags – Enthält zusätzlicheInformationen zur SSP-Meldung. Die Zuordnung der Flags(Bit 7 ist das hochwertigste und Bit 0 das niederwertigsteBit des Bytes) wird in der Tabelle 19.1 gezeigt.

Bit-Position Name Bedeutung

7 SSPex 1 = Suchmeldung (»canureach« oder»icanreach«)

6 bis 0 Reserviert Keine. Reservierte Felder werden bei Über-tragung auf 0 gesetzt und bei Empfangignoriert.

− Verbindungspriorität – Steht für nicht unterstützte, nied-rige, mittlere, hohe und höchste Verbindungspriorität inden drei niederwertigen Bits dieses Bytes. Zum Einrich-tungszeitpunkt der Schaltung stellt jeder Schaltungsend-punkt seinem Partner Prioritätsinformationen bereit. DerAuslöser der Verbindung legt fest, welche Priorität über dieExistenzdauer der Verbindung hinweg verwendet wird.

Tabelle 19.1:SSP-Flag-Definitionen


Wenn die Knoten diese Priorität nicht unterstützen, wirddie unterstützungslose Priorität verwendet.

− Ziel-MAC-Adresse – Wird mit der Zielverbindungs-SAP,der Ausgangs-MAC-Adresse und der Ausgangs-SAP zurFestlegung einer logischen End-To-End-Zuordnung, dersogenannten Data-Link-ID, kombiniert.

− Ausgangs-MAC-Adresse – Dient als MAC-Adresse der aus-lösenden Endstation.

− Ausgangs-LSAP (Link Service Access Point) – Dient alsSAP des Quellengeräts. Die SAP wird zur logischen Iden-tifikation des übertragenen Verkehrs verwendet.

− Ziel-LSAP (Link Service Access Point) – Dient als SAP desZielgeräts.

− Frame-Richtung – Enthält den Wert 0x01 für Frames, dievom Ursprungs-DLSw- zum Ziel-DLSw-Knoten, bzw. 0x02für Frames, die vom Ziel-DLSw- zum Ursprungs-DLSw-Knoten gesendet werden.

− Data-Link-Control (DLC) Header-Länge – Gibt mit derEinstellung 0 für SNA und 0x23 für NetBIOS-Datagrammeeine Länge von 35 Byte an. Der NetBIOS-Header beinhal-tet die folgenden Informationen:

− Access Control (AC)-Feld

− Frame Control (FC)-Feld

− Destination-MAC-Adresse (DA)

− Source-MAC-Adresse (SA)

− Routing Information (RI)-Feld (auf 18 Byte aufgefüllt)

− Destination Service Access Point (DSAP)

− Source SAP (SSAP)

− LLC-Steuerungsfeld (UI)

− Anschluß-ID der Datenübertragungssteuerung – Bildet zu-sammen mit dem Korrelator der Ursprungsdatenverbin-dung eine 64-Bit-Schaltungs-ID, welche die DLC-Schaltunginnerhalb eines einzelnen DLSw-Knoten definiert. Die


Schaltungs-ID wird lokal vergeben und ist innerhalb eineseinzelnen DLSw-Knotens einmalig. Die End-To-End-Schal-tung wird durch ein Paar von Schaltungs-IDs identifiziert,welche zusammen mit den Datenübertragungs-IDs eineeinzelne End-To-End-Schaltung eindeutig identifizieren. Je-der DLSw-Knoten besitzt eine Tabelle für diese Schaltungs-ID-Paare: eine für das lokale Ende der Schaltung und dieandere für das entfernte Ende der Schaltung.

− Ursprungs-Datenübertragungs-Korrelator – Bildet zusam-men mit der Ursprungsanschluß-ID der Datenübertra-gungssteuerung eine 64 Bit lange Schaltungs-ID, welche dieDLC-Schaltung innerhalb eines DLSw-Knotens bestimmt.Die Schaltungs-ID wird lokal vergeben und ist innerhalbeines einzelnen DLSw-Knotens einmalig. Die End-To-End-Schaltung wird durch ein Paar von Schaltungs-IDs identi-fiziert, welche zusammen mit den Datenübertragungs-IDseine einzelne End-To-End-Schaltung eindeutig identifizie-ren. Jeder DLSw-Knoten besitzt eine Tabelle für dieseSchaltungs-ID-Paare: eine für das lokale Ende der Schal-tung und die andere für das entfernte Ende der Schaltung.

− Ursprungs-Transport-ID – Identifiziert den jeweiligenTCP/IP-Anschluß eines DLSw-Knotens. Die Werte habennur eine lokale Bedeutung. Jeder DLSw-Knoten muß dieseWerte zusammen mit den zugehörigen Werten, der Daten-übertragungskontroll-(DLC-)Anschluß-ID und dem Daten-übertragungs-Korrelator bei der Rückgabe einer Meldungan den DLSw-Partner wiedergeben.

− Ziel-Anschluß-ID der Datenübertragungssteuerung – Bil-det zusammen mit dem Datenübertragungs-Korrelator desZiels eine 64 Bit lange Schaltungs-ID, welche die DLC-Schaltung innerhalb eines DLSw-Knotens bestimmt. DieSchaltungs-ID wird lokal vergeben und ist innerhalb eineseinzelnen DLSw-Knotens einmalig. Die End-To-End-Schal-tung wird durch ein Paar von Schaltungs-IDs identifiziert,welche zusammen mit den Datenübertragungs-IDs eineeinzelne End-To-End-Schaltung eindeutig identifizieren. Je-der DLSw-Knoten besitzt eine Tabelle für diese Schaltungs-ID-Paare: eine für das lokale Ende der Schaltung und dieandere für das entfernte Ende der Schaltung.


− Ziel-Datenübertragungs-Korrelator – Bildet zusammen mitder Ziel-Anschluß-ID der Datenübertragungssteuerung eine64-Bit lange Schaltungs-ID, welche die DLC-Schaltunginnerhalb eines DLSw-Knotens bestimmt. Die Schaltungs-ID wird lokal vergeben und ist innerhalb eines einzelnenDLSw-Knotens einmalig. Die End-To-End-Schaltung wirddurch ein Paar von Schaltungs-IDs identifiziert, welche zu-sammen mit den Datenübertragungs-IDs eine einzelne End-To-End-Schaltung eindeutig identifizieren. Jeder DLSw-Knoten besitzt eine Tabelle für diese Schaltungs-ID-Paare:eine für das lokale Ende der Schaltung und die andere fürdas entfernte Ende der Schaltung.

− Transport-ID – Identifiziert den jeweiligen TCP/IP-An-schluß an einem DLSw-Knoten. Die Werte haben nur einelokale Bedeutung. Jeder DLSw-Knoten muß diese Wertezusammen mit den zugehörigen Werten, der Datenübertra-gungskontroll-(DLC-)Anschluß-ID und dem Datenübertra-gungs-Korrelator bei der Rückgabe einer Meldung an denDLSw-Partner wiedergeben.

20 LAN Switching

20.1 Grundlagen

Ein LAN-Switch ist ein Gerät, das eine wesentlich höhere An-schlußdichte ermöglicht als herkömmliche Bridges. Deshalbkann man mit LAN-Switches Netzwerk-Entwürfe mit wenigerNutzern pro Segment realisieren und infolgedessen die mittlereverfügbare Bandbreite pro Benutzer vergrößern. Dieses Kapi-tel beinhaltet eine Zusammenfassung des allgemeinen LAN-Switch-Betriebs und ordnet das LAN-Switching den Schichtendes OSI-Referenzmodells zu.

Der Trend zu weniger Nutzern pro Segment wird als Micro-segmentation bezeichnet. Die Microsegmentation ermöglichtdas Erstellen von persönlichen oder zugeordneten Segmenten,d.h. einem Benutzer pro Segment. Jeder Benutzer hat unmittel-baren Zugriff auf die volle Bandbreite und muß diese nichtmit anderen Benutzern teilen. Infolgedessen können keine Kol-lisionen (ein übliches Phänomen in Netzwerken mit gemein-sam benutzten Medien und Hubs) auftreten. Ein LAN-Switchleitet Frames weiter, die entweder auf der Layer-2-Adresse(Layer-2-LAN-Switch) oder in manchen Fällen auf der Layer-3-Adresse des Frames basieren (Multi-Layer-LAN-Switch).LAN-Switches werden auch als Frame-Switches bezeichnet,weil sie Layer-2-Frames vermitteln, während ein ATM-SwitchZellen (engl. cells) weiterleitet. Trotz der hohen Verbreitungvon Ethernet-LAN-Switches gewinnen Token-Ring- undFDDI-LAN-Switches mit steigender Netzwerk-Auslastung anBedeutung.

KAPITEL 20LAN-Switching


Bild 20.1 zeigt einen LAN-Switch, der den Geräten die jeweili-gen dedizierten Bandbreiten zuweist, und verdeutlicht dasLayer-2-LAN-Switching im Verhältnis zur OSI-Sicherungs-schicht:

OSI-Referenzmodell

Netzwerk

Sicherung

Physikalisch

Anwendung

Darstellung

Kommunikation

Transport

LAN- Switch

20.1.1 Zur Geschichte

Die ersten LAN-Switches wurden 1990 entwickelt. Diese wa-ren Layer-2-Geräte und dienten der Lösung von Bandbreiten-problemen. Moderne LAN-Switches haben sich zu Multi-Layer-Geräten entwickelt, die in der Lage sind, Protokollauf-gaben in Anwendungen mit sehr hoher Bandbreite zu lösen,die vorher nur von Routern bewältigt werden konnten. Heutelösen LAN-Switches zunehmend die Hubs bei der Vermittlungab, weil die Benutzeranwendungen immer größere Bandbrei-ten erfordern.

20.2 Einsatz von LAN-Switches

LAN-Switches ähneln der Funktionsweise von transparentenBridges bei Funktionen, wie dem Erlernen der Topologie, derVermittlung und Filterung. Diese Switches beherrschen weitereneue und einmalige Leistungsmerkmale, wie dedizierte Kom-munikation zwischen Geräten, mehrere Verbindungen gleich-zeitig, Vollduplex-Übertragung und Anpassung an das Me-dium.

Die dedizierte, kollisionsfreie Übertragung zwischen Netz-werk-Geräten erhöht den Durchsatz bei der Dateiübertragung.Mehrere gleichzeitige Verbindungen können beim Weiterleiten

Bild 20.1:Ein LAN-

Switch ist einGerät der

Sicherungs-schicht

Kapitel 20 • LAN Switching 269

oder Switching mehrerer Pakete zur selben Zeit aufgebautwerden, wodurch die Netzwerkleistung um die Anzahl derVerbindungen erhöht wird. Eine Vollduplex-Übertragung ver-doppelt den Durchsatz, während die Anpassung an dasMedium dem LAN-Switch Übertragungen zwischen 10 und100 Mbps ermöglicht, wodurch die Bandbreite nach Bedarfzugeordnet werden kann.

Der Einsatz von LAN-Switches erfordert keine weiteren Ände-rungen an vorhandenen Hubs, Netzwerkkarten oder Verkabe-lungen.

20.2.1 Vermittlung beim LAN-Switching

LAN-Switches können durch die unterstützten Vermittlungs-methoden charakterisiert werden. Bei der Switching-Methodemit Speichern und Weiterleiten findet eine Fehlerprüfung statt,wonach fehlerhafte Frames abgelehnt werden. Bei der durch-gehenden Switching-Methode wird die Verzögerung durch denVerzicht auf die Fehlerprüfung verringert.

Bei der Switching-Methode mit Speichern und Weiterleitenkopiert der LAN-Switch den gesamten Frame in seine internenPufferspeicher und berechnet eine zyklische Blocksicherung(engl. cyclic redundancy check, CRC). Der Frame wird abge-lehnt, wenn er einen CRC-Fehler enthält bzw. ein Runt(weniger als 64 Byte inklusive CRC lang) oder ein Giant(mehr als 1518 Byte inklusive CRC lang) ist. Wenn der Framekeinerlei Fehler aufweist, sucht der LAN-Switch die Ziel-adresse in seiner Weiterleitungs- oder Switching-Tabelle undlegt die Ausgangsschnittstelle fest. Danach wird der Frame inRichtung des Ziels verschickt.

Bei der durchgehenden Switching-Methode kopiert der LAN-Switch nur die Zieladresse (die ersten 6 Byte nach dem Vor-spann) in seine internen Puffer. Anschließend sucht der LAN-Switch die Zieladresse in seiner Weiterleitungs- oder Swit-ching-Tabelle, legt die Ausgangsschnittstelle fest und ver-schickt den Frame in Richtung der Zieladresse. Ein durch-gehender Switch ermöglicht geringere Verzögerungen, weil erden Frame weiterleitet, sobald er die Zieladresse gelesen unddie Ausgangsschnittstelle festgelegt hat.


Einige Switches können so konfiguriert werden, daß sie so-lange durchgehendes Switching einsetzen, bis ein benutzerde-finierter Fehlerschwellwert erreicht wird, und dann automa-tisch mit der Switching-Methode mit Speichern und Weiterlei-ten fortsetzen. Wenn die Fehlerrate den Schwellwert wiederunterschreitet, wechselt der Anschluß automatisch zurück inden durchgehenden Modus.

20.2.2 Bandbreite des LAN-Switching

LAN-Switches können auch anhand der Bandbreite charakte-risiert werden, die jedem Anschluß zur Verfügung steht. Sym-metrisches Switching stellt jedem Anschluß die gleiche Band-breite zur Verfügung, während asymmetrisches Switching denAnschlüssen unterschiedliche Bandbreiten zuweist.

Ein asymmetrischer LAN-Switch ermöglicht vermittelte Ver-bindungen zwischen Anschlüssen mit unterschiedlicher Band-breite, wie Kombinationen aus 10BaseT und 100BaseT. DieseSwitching-Art wird auch als 10/100-Switching bezeichnet.Asymmetrisches Switching ist für Client-Server-Datenverkehroptimiert, bei dem mehrere Clients gleichzeitig mit einem Ser-ver kommunizieren, wobei am Server-Port eine größere Band-breite benötigt wird, um dort einen Engpaß zu vermeiden.

Ein symmetrischer Switch ermöglicht vermittelte Verbindun-gen zwischen Anschlüssen mit der gleichen Bandbreite, wiealle 10BaseT und 100BaseT. Symmetrisches Switching ist füreine zweckmäßig verteilte Datenverkehrsbelastung optimiert,z.B. für eine Peer-to-Peer-Desktop-Umgebung.

Der Netzwerk-Verwalter muß die benötigte Bandbreite fürVerbindungen zwischen den Geräten abschätzen, um den Be-darf für den Datenfluß netzwerkgestützter Anwendungen er-füllen zu können, und daraufhin entscheiden, ob ein asymme-trischer oder ein symmetrischer Switch benötigt wird.

20.3 LAN-Switch und das OSI-Modell

LAN-Switches können entsprechend der OSI-Schicht charak-terisiert werden, auf der sie Frames filtern und weiterleitenbzw. vermitteln (engl. switch). Diese Kategorien sind: Layer 2,Layer 2 mit Layer-3-Merkmalen oder Multi-Layer.

Kapitel 20 • LAN Switching 271

Ein Layer-2-LAN-Switch ist in seinen Betriebseigenschafteneiner Multiport-Bridge sehr ähnlich, verfügt aber über einewesentlich höhere Kapazität und besitzt viele neue Merkmale,wie z.B. den Vollduplex-Betrieb. Ein Layer-2-LAN-Switchvermittelt und filtert auf Grundlage der MAC-Adresse derOSI-Sicherungsschicht (Layer 2). Wie Bridges, ist er für Netz-werkprotokolle und Benutzeranwendungen vollständig trans-parent.

Ein Layer-2-LAN-Switch mit Layer-3-Merkmalen kann Swit-ching-Entscheidungen auf Grund weiterer Informationen alsnur der Layer-2-MAC-Adresse treffen. Ein solcher Switchkann einige Layer-3-Verkehrssteuerungsmöglichkeiten ein-schließen, wie Broadcast und Multicast-Verkehrsmanagement,Sicherheitsprüfungen über Zugriffslisten und IP-Fragmentie-rung.

Ein Multi-Layer-Switch trifft Switching- und Filterungsent-scheidungen auf Grundlage der OSI-Sicherungsschicht-Adres-sen (Layer 2) und OSI-Netzwerkschicht-Adressen (Layer 3).Dieser Switch-Typ entscheidet dynamisch, ob der eintreffendeVerkehr vermittelt (Layer 2) oder »geroutet« (Layer 3) wird.Ein Multi-Layer-LAN-Switch vermittelt (engl. switch) inner-halb von Arbeitsgruppen und routet zwischen unterschied-lichen Arbeitsgruppen.

21 Tag Switching

21.1 Grundlagen

Radikale Änderungen der Qualität (und Quantität) des überdas Internet abgewickelten Datenverkehrs und das explosiveAnsteigen der Anzahl der Internet-Benutzer belasten die Infra-struktur des Internet auf bisher nicht vorhersehbare Art undWeise. Diese Entwicklung sorgte für völlig neue Lösungen zurVerwaltung des Datenverkehrs. Tag-Switching zielt darauf ab,viele der Herausforderungen des in der Entwicklung begriffe-nen Internet und der Datenübertragung mit hoher Geschwin-digkeit im allgemeinen zu lösen. Dieses Kapitel gibt einenÜberblick zu den Grundlagen des Tag-Switching-Betriebs, derArchitektur und den Einsatzumgebungen. Tag-Switching liegtmomentan in Form einer Serie von Internet-Entwürfen vor. Zudiesen gehört u.a.:

− »Tag Distribution Protocol«, P. Doolan, B. Davie, D. Katz

− »Tag Switching Architecture Overview«, Y. Rekhter, B.Davie, D. Katz

− »Use of Flow Label for Tag Switching«, F. Baker, Y.Rekhter

− »Use of Tag Switching With ATM«, B. Davie, P. Doolan, J.Lawrence, K. McCloghrie

− »Tag Switching: Tag Stack Encoding«, E. Rosen, D. Tap-pan, D. Farinacci

KAPITEL 21Tag-Switching


21.2 Die Tag-Switching-Architektur

Tag-Switching verwendet zwei Grundkomponenten: Weiterlei-tung (engl. forwarding) und Steuerung (engl. control). DieForwarding-Komponente verwendet die Tag-Information(Tags), die mit Paketen übertragen wird, und die Tag-For-warding-Information, die von einem Tag-Switch verwaltetwird, für die Weiterleitung von Paketen. Die Control-Kompo-nente ist für die Handhabung der korrekten Tag-Forwarding-Information innerhalb einer Gruppe von verbundenen Tag-Switches zuständig. Weitere Einzelheiten zum Forwarding undSteuerungsmechanismen beim Tag-Switching finden Sie imweiteren Verlauf dieses Kapitels.

21.2.1 Die Forwarding-Komponente

Das beim Tag-Switching verwendete Forwarding-Paradigmabasiert auf der Idee des Label-Swapping. Beim Empfang einesPakets mit einem Tag durch einen Tag-Switch verwendet derSwitch das Tag als Index in seiner Tag Information Base (TIB).Jeder Eintrag in der TIB besteht aus einem Eingangs-Tag undeinem oder mehr Untereinträgen (in der Folge Ausgangs-Tag,Ausgangs-Schnittstelle, Ausgangs-Verbindungsschichtinforma-tion). Wenn der Switch einen Eintrag findet, dessen Eingangs-tag dem mit dem Paket übertragenen entspricht, ersetzt derSwitch für alle Bestandteile des Eintrags das Tag im Paketdurch das Ausgangs-Tag, die Informationen der Verbindungs-schicht (wie die MAC-Adresse) durch die Informationen derVerbindungsschicht am Ausgang und leitet das Paket über dieAusgangsschnittstelle weiter.

Anhand der oben gegebenen Beschreibung der Forwarding-Komponente, können wir verschiedene Betrachtungen anstel-len. Die Forwarding-Entscheidung basiert auf einem Algo-rithmus mit genauer Übereinstimmung mit einem relativ kur-zen Index-Tag fester Länge. Dies ermöglicht eine einfachereForwarding-Prozedur als mit der längsten Übereinstimmung,die in der Netzwerkschicht eingesetzt wird.

Dadurch wird die Forwarding-Geschwindigkeit vergrößert(eine höhere Menge von Paketen pro Sekunde). Die Forwar-ding-Prozedur ist einfach genug, um als Hardware realisiert zuwerden. Weiterhin von Bedeutung ist die Tatsache, daß die

Kapitel 21 • Tag Switching 275

Forwarding-Entscheidung unabhängig von der Forwarding-Granularität des Tag ist. Der gleiche Forwarding-Algorithmusverarbeitet sowohl Unicast als auch Multicast: ein Unicast-Eintrag hätte einen einzelnen Untereintrag (Ausgangs-Tag,Ausgangsschnittstelle, Ausgangs-Verbindungsschichtinforma-tion), während ein Multicast-Eintrag ein oder mehr Unterein-träge haben kann. Dies verdeutlicht, wie das gleiche Forwar-ding-Paradigma für das Tag-Switching mit Unterstützung ver-schiedener Routing-Funktionen verwendet werden kann.

Die einfache Forwarding-Prozedur ist somit von der Steue-rungskomponente des Tag-Switching völlig entkoppelt. NeueRouting-(Steuerung-)Funktionen können einfach eingesetztwerden, ohne das Forwarding-Paradigma zu stören. Dies be-deutet auch, daß bei Ergänzung neuer Funktionen keine Neu-optimierung der Forwarding-Leistung (durch Änderung vonHardware oder Software) notwendig ist.

Tag-Encapsulation

Tag-Informationen können in Paketen auf verschiedene Artund Weise übertragen werden:

− Als kleiner »Shim«-Tag-Kopf zwischen Layer 2 und denNetzwerkschicht-Kopfzeilen

− Als Teil des Layer-2-Kopfes, wenn der Layer-2-Kopf eineverwendbare Semantik besitzt (wie bei ATM)

− Als Teil des Netzwerkschicht-Kopfes (wie beim Einsatz desFlow-Label-Felds in IPv6 mit entsprechend modifizierterSemantik)

Infolgedessen kann Tag-Switching für beliebige Medientypenverwendet werden, für Point-To-Point-Verbindungen, Multi-Access-Verbindungen und ATM. Die Tag-Forwarding-Kom-ponente ist vom Netzwerkschicht-Protokoll unabhängig. DieVerwendung von spezifischen Steuerungskomponenten fürspezielle Netzwerkschicht-Protokolle ermöglicht den Einsatzdes Tag-Switching mit verschiedenen Netzwerkschicht-Proto-kollen.


21.2.2 Steuerungskomponenten

Eine Besonderheit des Tag-Switching liegt in der Idee der Ver-bindung zwischen einem Tag und dem Netzwerkschicht-Rou-ting (Routen). Um eine gute Skalierbarkeit zu gewährleistenund gleichzeitig verschiedene Routing-Funktionen umzuset-zen, unterstützt Tag-Switching eine Vielzahl von Forwarding-Granularitäten. Als Extremfall kann ein Tag einer Gruppe vonRouten zugewiesen werden (genauer die Reachability-Infor-mation der Netzwerkschicht der Routen dieser Gruppe). Derandere Extremfall wäre, daß ein Tag einem speziellen Anwen-dungsfluß (wie einem RSVP-Fluß) zugewiesen wird oder aneinen Multicast-Tree.

Die Control-Komponente ist für die Erstellung von Tag-Bin-dings und die anschließende Verteilung der Tag-Bindings andie Tag-Switches zuständig.

Die Steuerungskomponente ist als Modulsammlung organi-siert, von denen jede für die Unterstützung einer speziellenRouting-Funktion entworfen ist. Für die Unterstützung neuerRouting-Funktionen können neue Module ergänzt werden. ImFolgenden werden einige dieser Module beschrieben.

21.3 Destination-Based Routing(zielbasiertes Routing)

Beim Destination-Based-Routing entscheidet ein Router überdie Weiterleitung aufgrund der Zieladresse, die im Paket ent-halten ist, und der Informationen, die in der Forwarding In-formation Base (FIB) des Router enthalten sind. Ein Routerkonstruiert seine FIB mit Hilfe der Informationen, die er vonRouting-Protokollen wie OSPF und BGP empfängt.

Zur Unterstützung des Destination-Based-Routing durch dasTag-Switching nimmt ein Tag-Switch an den Routing-Proto-kollen teil und baut seine FIB mit Hilfe der Informationen auf,die er über diese Protokolle empfängt. Damit funktioniert erähnlich wie ein Router.


Es gibt drei zulässige Methoden für die Tag-Zuweisung undVerwaltung der Tag Information Base (TIB):

− Downstream-Tag-Zuweisung

− Downstream-Tag-Zuweisung auf Anforderung

− Upstream-Tag-Zuweisung

In alle Fällen sucht ein Tag-Switch Tags und weist diese denAdreßpräfixen in seiner FIB zu. Bei der Downstream-Zuwei-sung wird das Tag (welches in einem Paket übertragen wird)generiert und vom Switch einem Präfix am Downstream-Endeder Verbindung zugewiesen (unter Berücksichtigung der Rich-tung des Datenflusses). Bei der Upstream-Zuweisung werdendie Tags ausgelesen und dem Upstream-Ende der Verbindungzugewiesen. Zuweisung auf Anforderung bedeutet, daß dieTags nur auf Anforderung durch den Upstream-Switch ausge-lesen und verteilt werden.

Downstream- und Upstream-Tag-Zuweisung auf Anforderungsind besonders in ATM-Netzwerken sehr nützlich. Bei derDownstream-Zuweisung ist ein Switch für die Erstellung derTag-Zuordnungen zuständig, die den eingehenden Datenpake-ten zugeordnet werden, und außerdem für den Empfang vonTag-Zuordnungen für abgehende Pakete von seinen Nach-barn. Bei der Upstream-Zuweisung ist ein Switch für die Er-stellung der Tag-Zuordnungen der abgehenden Datenpaketezuständig und außerdem für den Empfang von Zuordnungenfür eingehende Tags von Nachbarn. Betriebsbedingte Unter-schiede werden in der folgenden Zusammenfassung heraus-gestellt.

21.3.1 Downstream-Tag-Zuweisung

Bei der Downstream-Tag-Zuweisung weist der Switch jederRoute einen Tag in seinem FIB zu, erstellt einen Eintrag in sei-ner TIB mit dem eingehenden Tag auf das zugeordnete Tag ge-setzt und gibt die Zuordnung zwischen dem (eingehenden) Tagund der Route den anderen benachbarten Tag-Switches be-kannt. Die Bekanntgabe kann durch Versand der Zuordnungmit den bestehenden Routing-Protokollen oder unter Verwen-dung eines getrennten Tag Distribution Protocol (TDP) erfol-gen. Wenn ein Tag-Switch Tag-Zuordnungsinformationen für


eine Route empfängt, und diese Information stammt vomnächsten Hop dieser Route, dann legt der Switch das Tag (dasals Teil der Zuordnungsinformation übertragen wird) als Aus-gangs-Tag des TIB-Eintrags ab, dem diese Route zugeordnetist. So wird die Zuordnung zwischen dem Ausgangs-Tag undder Route hergestellt.

21.3.2 Downstream-Tag-Zuweisung auf Anforderung

Für jede Route in seinem FIB identifiziert der Switch dennächsten Hop für diese Route. Anschließend löst er eine An-forderung (per TDP) an den nächsten Hop für eine Tag-Zu-ordnung für diese Route aus. Wenn der nächste Hop die An-forderung erhält, liest er ein Tag aus, erstellt einen Eintrag inseiner TIB mit dem eingehenden Tag auf das zugeordnete Taggesetzt und gibt die Zuordnung zwischen dem (eingehenden)Tag und der Route an den Switch zurück, welcher die Anfor-derung auslöste. Wenn der Switch eine Zuordnungsinforma-tion (engl. binding) empfängt, erstellt der Switch einen Eintragin seiner TIB und besetzt das Ausgangs-Tag des Eintrags aufden vom nächsten Hop empfangenen Wert.

21.3.3 Upstream-Tag-Zuweisung

Bei Upstream-Tag-Zuweisung erstellt ein Tag-Switch ein Tagfür jede Route in seinem FIB, deren nächster Hop über einedieser Schnittstellen erreichbar ist (wenn er eine oder mehrPoint-To-Point-Schnittstellen besitzt). Es erstellt einen Eintragin seiner TIB, dessen Ausgangs-Tag mit dem ausgelesenen Tagbelegt wird, und teilt die Zuordnung zwischen (Ausgangs-)Tagund der Route dem nächsten Hop mit (per TDP). Wenn derals nächster Hop fungierende Tag-Switch Tag-Zuordnungsin-formationen empfängt, dann legt der Switch das Tag (das alsTeil der Zuordnungsinformation übertragen wird) als Ein-gangs-Tag des TIB-Eintrags ab, dem diese Route zugeordnetist.

Nachdem ein TIB-Eintrag sowohl mit Eingangs- als auch Aus-gangs-Tags belegt wurde, kann der Tag-Switch mit Hilfe desWeiterleitungsalgorithmus für das Tag-Switching Pakete fürdie zugeordneten Routen weiterleiten.


Wenn ein Tag-Switch eine Zuordnungsinformation (engl.binding) zwischen einem Ausgangs-Tag und einer Route er-stellt, belegt er nicht nur seine TIB, sondern aktualisiert auchseine FIB mit der Zuordnungsinformation. Dies ermöglichtdem Switch eine Ergänzung von Tags bei bislang tag-losen Pa-keten. Beachten Sie, daß die Gesamtmenge der Tags die einTag-Switch verwaltet, nicht größer als die Anzahl der Routenin der FIB des Switch sein kann. Vielmehr ist in den meistenFällen ein einzelnes Tag einer Gruppe von Routen zugeordnet,statt nur einer einzelnen Route. So sind weniger Zustandsin-formationen notwendig als für den Fall, daß die Tags einzel-nen Routen zugeordnet sind.

Im allgemeinen versucht ein Tag-Switch, seine TIB mit eintref-fenden und ausgehenden Tags für alle erreichbaren Routen zufüllen, wonach alle Pakete per einfachem Label-Swapping wei-tergeleitet werden können. Tag-Zuweisung wird demzufolgedurch die Topologie (Routing) und nicht den Datenverkehrgeleitet. Das Vorhandensein eines FIB-Eintrags bewirkt dieTag-Zuweisung, nicht das Eintreffen von Datenpaketen.

Die Verwendung von Tags, welche Routen zugeordnet sindstatt Verbindungen, bedeutet auch, daß es nicht notwendig ist,Fluß-Klassifizierungsprozeduren für all die Verbindungen aus-zuführen, um festzustellen, ob einer Verbindung ein Tag zuzu-ordnen ist. Dies vereinfacht das allgemeine Routing-Schemaund erstellt eine robustere und stabilere Umgebung.

Beim Einsatz des Tag-Switching zur Unterstützung des Desti-nation-Based-Routing, bleibt das Forwarding auf der norma-len Netzwerkschicht weiterhin notwendig. Als erstes ist fürdas Ergänzen eines Tag zu einem vorher unmarkierten Paketnormales Netzwerkschicht-Forwarding erforderlich. DieseFunktion kann durch den ersten Hop-Router oder den erstenRouter im Pfad ausgeführt werden, der am Tag-Switching teil-nehmen kann. Immer dann, wenn ein Tag-Switch eine Gruppevon Routen zu einem einzigen Tag verbindet und die Routenkeinen gemeinsamen nächsten Hop besitzen, muß der Switchein Netzwerkschicht-Forwarding für die Pakete ausführen, diedas Tag übertragen. Allerdings ist die Anzahl der Stellen, andenen Routen zusammengefaßt werden, geringer als die Ge-samtanzahl der Stellen, an denen Forwarding-Entscheidungengetroffen werden müssen. Außerdem werden Untergruppen


von Routen, die von einem Tag-Switch bearbeitet werden, oftzusammengefaßt. Infolgedessen können Pakete gewöhnlichmit dem Tag-Switching-Algorithmus weitergeleitet werden.

21.4 Hierarchical-Routing

Die IP-Routing-Architektur modelliert ein Netzwerk alsSammlung von Routing-Domains. Innerhalb einer Domainwird das Routing als internes Routing realisiert (z.B. OSPF),während das Routing über Domains hinweg als externesRouting umgesetzt wird (z.B. BGP). Allerdings müssen alleRouter innerhalb einer Domain, die Transit-Datenverkehrübertragen (wie die Domains, die durch Internet Service Pro-vider gebildet werden) auch die Informationen verwalten, diedurch das externe Routing geliefert werden, und nicht nur dasinterne Routing.

Tag-Switching ermöglicht das Entkoppeln von internem undexternem Routing, so daß nur an den Grenzen der Domain-Tag-Switches für die Verwaltung der Routing-Information desexternen Routing benötigt werden. Alle anderen Switchesinnerhalb der Domain verwalten die Routing-Information, diedurch das interne Routing der Domain bereitgestellt wird.Deren Umfang ist gewöhnlich geringer als der des externenRouting. Dies verringert wiederum die Routing-Belastung dernicht an den Außengrenzen liegenden Switches und verkürztdie Konvergenzzeit des Routing.

Zur Unterstützung dieser Funktionalität erlaubt Tag-Swit-ching die Übertragung mehrerer als Stapelspeicher organisier-ter Tags in einem Paket. Ein Tag-Switch kann das Tag an dieSpitze des Stapelspeichers verlegen, den Stapelspeicher abhe-ben oder ein und mehr Tags auf den Stapelspeicher legen.Wenn ein Paket zwischen zwei (Außen-)Tag-Switches unter-schiedlicher Domains übertragen wird, enthält der Tag-Sta-pelspeicher in dem Paket nur ein Tag.

Bei der Weiterleitung eines Pakets innerhalb einer Domainenthält der Tag-Stapelspeicher in dem Paket allerdings zweiund nicht ein Tag (das zweite Tag wird durch den grenzüber-schreitenden Tag-Switch der Domain eingefügt). Das Tag ander Spitze des Stapelspeichers ermöglicht die Paketweiterlei-tung an einen passenden Domaingrenzen-Tag-Switch, wäh-


rend das nächste Tag auf dem Stapelspeicher für die korrekteWeiterleitung des Pakets durch diesen Switch sorgt. Der Sta-pelspeicher wird entweder durch den Grenz-Switch oder denvorletzten Switch (relativ zum Grenz-Switch) zurückgesetzt.

Die Steuerungskomponente in diesem Beispiel funktioniertähnlich der für Destination-Based-Routing verwendeten. Dereinzige wesentliche Unterschied ist, daß in diesem Beispiel dieTag-Binding-Information sowohl unter benachbarten Tag-Switches als auch unter Grenz-Tag-Switches innerhalb einereinzelnen Domain ausgetauscht wird.

21.5 Flexibles Routing durch explizite Routen

Eine der grundlegenden Eigenschaften des Destination-Based-Routing ist, daß die einzige von einem Paket für die Weiterlei-tung verwendete Information die Zieladresse ist. Obwohl diesein sehr gut skalierbares Routing ermöglicht, schränkt esgleichzeitig die Möglichkeiten zur Beeinflussung der durch diePakete zurückgelegten Pfade ein. Dies begrenzt die Verfügbar-keit eines gleichmäßig auf mehrere Verbindungen verteiltenDatenverkehrs, wobei die Belastung von stark ausgelastetenVerbindungen durch Verlagerung auf weniger ausgelasteteVerbindungen verringert würde. Für Internet Service Provider(ISPs), die unterschiedliche Serviceklassen anbieten, schränktDestination-Based-Routing deren Fähigkeiten zur Auftren-nung in unterschiedliche Klassen, unter Berücksichtigung dervon diesen Klassen verwendeten Verbindungen, ebenfalls ein.Einige ISPs verwenden heute bereits Frame Relay oder ATM,um die durch das Destination-Based-Routing verursachten Be-schränkungen zu vermeiden. Tag-Switching kann aufgrund derflexiblen Granularität der Tags diese Beschränkungenüberwinden, ohne Frame Relay oder ATM einzusetzen. Umeine Weiterleitung auf Pfaden zu ermöglichen, die sich von denper Destination-Based-Routing vorgegebenen unterscheiden,erlaubt die Steuerungskomponente des Tag-Switching die Ein-richtung von Tag-Bindings in Tag-Switches, die nicht zu denPfaden des Destination-Based-Routing gehören.


21.6 Multicast-Routing

In einer Multicast-Routing-Umgebung sind Multicast-Rou-ting-Prozeduren (wie das Protocol-Independent Multicast[PIM]) für die Erstellung von Spanning Trees mit den Emp-fängern als Leaves zuständig. Multicast-Forwarding ist für dieWeiterleitung von Multicast-Paketen über diese Bäume ver-antwortlich.

Tag-Switches unterstützen Multicast, indem sie die Multicast-Fähigkeiten der Daten-Verbindungsschicht nutzen, wie die vonEthernet. Alle Tag-Switches in einem vorgegebenen Multicast-Tree eines gemeinsamen Unternetzes müssen sich auf ein ge-meinsames Tag für das Forwarding eines Multicast-Pakets analle in Verteilungsrichtung liegenden Switches dieses Unternet-zes einigen. So wird das Paket über die Daten-Verbindungs-schicht auf das Unternetz verteilt. Tag-Switches, die zu einemgemeinsamen Multicast-Tree eines gemeinsamen Daten-Ver-bindungsunternetzes gehören, einigen sich auf einen Tag-Switch, der für die Bereitstellung eines Tag für diesen Baumzuständig ist. Der Tag-Raum wird in nicht überlappende Re-gionen für alle Tag-Switches eingeteilt, die mit einem gemein-samen Subnetz verbunden sind. Jeder Tag-Switch erhält eineRegion des Tag-Raums und gibt diese Region seinen Nach-barn bekannt. Konflikte werden auf Basis der IP-Adresse dereinbezogenen Switches gelöst. Multicast-Tags sind, statt einemgesamten Tag-Switch, den Schnittstellen eines Tag-Switch zu-geordnet. Deshalb verwaltet der Switch TIBs in Verbindungmit einzelnen Schnittstellen, statt eines einzelnen TIB für dengesamten Switch. Die Tags ermöglichen es dem empfangendenSwitch, sowohl bestimmte Multicast-Gruppen als auch denQuell-Tag-Switch (den vorherigen Hop), der das Paket gesen-det hat, zu erkennen.

Es gibt zwei Möglichkeiten zur Erstellung von Zuordnungenzwischen Tags und Multicast-Trees (Routen). In einer Gruppevon Tag-Switches, die ein gemeinsames Datensubnet teilen,weist der Tag-Switch, der relativ zu einem speziellen Multi-cast-Tree als Wurzel steht, einer Multicast-Route ein Tag zuund teilt diese Zuordnung anschließend allen Switches in derVerteilungsrichtung des Subnetzes mit. Diese Methode funk-tioniert ähnlich, wie die Destination-Based-Tag-Zuweisungentgegen der Verteilungsrichtung. Ein Tag-Switch, der relativ


zu einem speziellen Multicast-Tree als Root steht, weist einerMulticast-Route einen Tag zu und teilt diese Zuordnung an-schließend allen Switches in und entgegen der Verteilungsrich-tung des Subnetzes mit. Der erste Tag-Switch, der der Gruppebeitritt, ist gewöhnlich derjenige, der die Zuweisungvornimmt.

21.7 Tag-Switching mit ATM

Weil das Tag-Switching-Forwarding-Paradigma genau wieATM-Forwarding auf Label-Swapping beruht, kann die Tag-Switching-Technologie auf ATM-Switches angewendet wer-den, indem man die Steuerungskomponenten des Tag-Swit-ching einsetzt. Die für das Tag-Switching benötigte Tag-Infor-mation kann das ATM-VCI-Feld aufnehmen. Wenn zwei Tag-Ebenen benötigt werden, kann ebenfalls das ATM-VPI-Feldverwendet werden, allerdings schränkt die Größe des VPI-Felds die Größe eines Netzwerks in der Praxis ein. Das VCI-Feld ist für die meisten Anwendungen mit einer Tag-Ebeneausreichend.

Um die notwendigen Steuerungsinformationen zu erhalten,verhält sich der Switch wie ein Peer in Routing-Protokollender Netzwerk-Schicht, wie OSPF und BGP. Wenn der Switchaußerdem eine Sammlung der Routing-Information anlegt,führt er für einen Teil des Datenverkehrs auch Forwarding aufNetzwerk-Ebene aus, um ein zielbasiertes Unicast-Routing zurealisieren. Durch die Unterstützung der Destination-Based-Routing-Funktion mit Tag-Switching auf einem ATM-Switchmuß dieser u.U. nicht nur ein, sondern mehrere Tags zu einerRoute zuordnen (oder eine Gruppe von Routen mit demgleichen nächsten Hop). Dies ist notwendig, um die Ver-schachtelung von Paketen zu vermeiden, die von unterschied-lichen Tag-Switches eintreffen, aber gleichzeitig an den näch-sten Hop verschickt werden. Für die Tag-Zuweisung und TIB-Wartungsprozeduren mit ATM-Switches kann sowohl Tag-Zuweisung auf Anforderung (in Übertragungsrichtung) alsauch ein Tag-Zuweisungsschema entgegen der Übertragungs-richtung eingesetzt werden.

Deshalb kann ein ATM-Switch Tag-Switching unterstützen; ermuß dazu aber mindestens Routing-Protokolle auf Netzwerk-


Ebene und die Tag-Switching-Steuerungskomponente imSwitch unterstützen. Es kann auch notwendig werden, For-warding auf Ebene der Netzwerk-Schicht zu unterstützen.

Der Einsatz des Tag-Switching in einem ATM-Switch würdedie Integration von ATM-Switches und Routern stark verein-fachen. Ein ATM-Switch, der Tag-Switching beherrscht, er-scheint benachbarten Routern als Router. Dies ermöglicht eineskalierbare Alternative zum »Overlay«-Modell und beseitigtdie Notwendigkeit von ATM-Adressierungs-, Routing- undSignalsierungsschemata. Weil das Destination-Based-Forwar-ding durch die Topologie und nicht durch den Datenverkehrbestimmt wird, beinhaltet die Anwendung dieses Ansatzes aufATM-Switches keine hohen Ruf-Einrichtungsraten und istauch nicht von der Entfernung der Übertragung abhängig.

Die Einrichtung des Tag-Switching auf einem ATM-Switchstört die Fähigkeiten der traditionellen ATM-Control-Plane(z.B. PNNI) auf dem gleichen Switch nicht. Die beiden Kom-ponenten, Tag-Switching und die ATM-Control-Plane, funk-tionieren unabhängig voneinander mit aufgeteilten VPI/VCI-Räumen und anderen Ressourcen, so daß die Komponentennicht aufeinander einwirken.

21.8 Quality of Service

Ein wichtige Fähigkeit des Tag-Switching ist die Unterstützungvon Quality-of-Service (QoS). Zwei Mechanismen werden be-nötigt, um einen QoS-Bereich für Pakete bereitzustellen, die ei-nen Router oder Tag-Switch durchqueren:

− Zuordnung der Pakete zu verschiedenen Klassen

− Behandlung der Pakete über entsprechende QoS-Merkmale(wie Bandbreite und Verlust)

Tag-Switching stellt eine einfache Möglichkeit zur Markierungvon Paketen und damit zur Zuordnung zu einer bestimmtenKlasse nach deren erstmaliger Klassifizierung bereit.

Die Anfangsklassifizierung kann mit der in den Headern derNetzwerk-Schicht oder höherer Schichten übertragenen Infor-mation durchgeführt werden. Infolgedessen wird diesem Paketein der resultierenden Klasse entsprechendes Tag zugeordnet.


Markierte Pakete können auf ihrem weiteren Weg durch Tag-Switching-Router ohne eine Neuklassifizierung sehr effektivbearbeitet werden. Das jeweilige Paket-Scheduling undQueuing ist weitestgehend vergleichbar: Der Punkt dabei ist,daß Tag-Switching das Scheduling mit einer einfachen Logikermöglicht und so die Information gefunden wird, die festlegt,wie der zeitliche Versand des Pakets auszuführen ist.

Der korrekte Einsatz des Tag-Switching für QoS-Zwecke er-fordert genaue Kenntnisse über den Einsatz von QoS. Wennfür die Anforderung einer bestimmten QoS für eine Klasse vonPaketen RSVP verwendet wird, dann ist es notwendig, ein Tagfür jede RSVP-Sitzung zuzuweisen, für die auf einem Tag-Switch ein Status installiert ist. Dies kann per TDP oder miteiner Erweiterung des RSVP ausgeführt werden.

21.9 IP-Switching

IP-Switching ist eine ähnliche Technologie, die ATM-Layer-2-Switching mit Layer-3-Routing verbindet. Somit ist es eineandere Art des Multi-Layer-Switching. IP-Switching weistüblicherweise ein Label pro Quelle/Ziel-Paketfluß zu. Ein IP-Switch bearbeitet die Anfangspakete bei einer Übertragung,indem er sie an das Standard-Router-Modul weiterleitet, dasBestandteil des IP-Switch ist.

Wenn ein IP-Switch eine ausreichende Anzahl von Paketen voneiner Verbindung gesehen hat, um davon ausgehen zu können,daß dieses langfristig ist, richtet er Labels für diese Verbindungmit seinen benachbarten IP-Switches oder Edge-Routern ein,so daß weitere Pakete der Verbindung mit hoher Geschwin-digkeit nach dem Label vermittelt werden können (so wie eineATM-Vermittlungseinheit) und die langsameren Router-Mo-dule umgehen. IP-Switching-Gateways sind für die Umwand-lung von Paketen von Formaten ohne Labels in Formate mitLabels und von Paket-Medien in ATM zuständig.

22 Mixed-Media-Bridging

22.1 Grundlagen

Transparent Bridges werden hauptsächlich in Ethernet-Netz-werken eingesetzt. Source-Route-Bridges (SRBs) finden Sie da-gegen fast ausschließlich in Token-Ring-Netzwerken. Sowohltransparente Bridges als auch SRBs sind weit verbreitet. Des-halb ist es sinnvoll zu fragen, ob eine Methode existiert, diebeide vereint. Es wurden mehrere solche Lösungen entwickelt.

Translational-Bridging stellt eine relativ preiswerte Lösung füreinige der Probleme beim Bridging zwischen Transparent-Bridging- und SRB-Domains dar. Translational-Bridging er-schien erstmalig Mitte bis Ende der 80er Jahre, wurde aberbisher von keiner Standardisierungsorganisation favorisiert.Deshalb sind viele Aspekte des Translational-Bridging abhän-gig vom jeweiligen Einsatz.

Im Jahre 1990 löste IBM einige Schwächen des Translational-Bridging durch Einführung des Source-Route-Transparent(SRT). Bridging-SRT-Bridges können sowohl Datenverkehrvon Transparent als auch Source-Route-Endknoten weiterlei-ten und einen gemeinsamen Baum mit transparenten Bridgesbilden, und ermöglichen damit Endstationen jedes Typs, mitEndstationen des gleichen Typs, innerhalb eines Netzwerksmit beliebiger Topologie zu kommunizieren. SRT wurde in derIEEE 802.1d Anhang C spezifiziert.

Das Ziel der Verbindung von Transparent-Bridging und SRB-Domains ist, eine Übertragung zwischen transparenten Bridges

KAPITEL 22Mixed-Media-Bridging


und SRB-Endstationen zu ermöglichen. Dieses Kapitel be-schreibt die technischen Probleme, für die Algorithmen gefun-den werden müssen, und stellt zwei mögliche Lösungen vor:Translational-Bridging und SRT-Bridging.

22.2 Übertragungsanforderungen

Viele Anforderungen stehen in Zusammenhang mit der Not-wendigkeit, Endstationen einer Ethernet/Transparent-Bridging-Domain die Kommunikation mit Endstationen einerSRB/Token-Ring-Domain zu ermöglichen:

− Inkompatible Bitreihenfolge – Obwohl sowohl Ethernet alsauch Token-Ring 48-bit Media Access Control (MAC)-Adressen unterstützen, unterscheidet sich die interne Dar-stellung dieser Adressen in der Hardware. Im seriellenBitstrom einer Adresse versteht ein Token-Ring-Gerät daserste gefundene Bit als hochwertigstes Bit eines Byte.Ethernet sieht auf der anderen Seite das erste gefundene Bitals niederwertigstes Bit an.

− Eingebettete MAC-Adressen – In manchen Fällen werdenMAC-Adressen im Datenteil eines Frame übertragen. DasAddress Resolution Protocol (ARP) – ein verbreitetes Pro-tokoll in Transmission Control Protocol/Internet Protocol(TCP/IP)-Netzwerken, legt z.B. Hardware-Adressen imDatenteil des Sicherungsschicht-Frame ab. Die Umwand-lung von Adressen, die im Datenteil eines Frame auftau-chen können (oder auch nicht), ist kompliziert, weil sie vonFall zu Fall unterschiedlich behandelt werden.

− Inkompatible Maximum-Transfer-Unit-(MTU-)Größen –Token-Ring und Ethernet unterstützen eine unterschiedli-che maximale Frame-Größe. Die Ethernet-MTU ist etwa1500 Byte, während Token-Ring-Frames wesentlich größersein können. Weil Bridges nicht in der Lage sind, Frames zufragmentieren und wieder zusammenzusetzen, müssenPakete, welche die MTU eines Netzwerks überschreiten,verworfen werden.

− Behandlung von Frame-Statusbit-Aktionen – Token-Ring-Frames enthalten drei Frame-Statusbits: A, C und E. Sinndieser Bits ist die Mitteilung an die Frame-Quelle, ob das

Kapitel 22 • Mixed-Media-Bridging 289

Ziel den Frame erkannte (A-Bit gesetzt), den Frame ko-pierte (C-Bit gesetzt) oder Fehler im Frame fand (E-Bit ge-setzt). Weil Ethernet diese Bits nicht unterstützt, bleibt dieFrage nach deren Behandlung dem Hersteller von Ethernet-Token-Ring-Bridges überlassen.

− Behandlung ausschließlicher Token-Ring-Funktionen – Fürbestimmte Token-Ring-Bits gibt es kein Äquivalent imEthernet. Ethernet beinhaltet z.B. keinen Prioritätsmecha-nismus, während Token-Ring über einen solchen verfügt.Weitere Token-Ring-Bits, die bei der Umwandlung einesToken-Ring-Frame in einen Ethernet-Frame entfernt wer-den, sind das Token-Bit, das Monitor-Bit und das Reservie-rungsbit.

− Behandlung von Explorer-Frames – Transparente Bridgeswissen grundsätzlich nicht, wie sie SRB-Explorer-Framesbehandeln sollen. Transparente Bridges erlernen die Netz-werk-Topologie über eine Analyse der Quellenadressen dereintreffenden Frames. Sie besitzen keine Informationenüber den SRB-Route-Erkennungsprozeß.

− Behandlung von Routing Information Field (RIF)-Infor-mationen in Token-Ring-Frames – Der SRB-Algorithmuslegt Routing-Informationen im RIF-Feld ab. Der Transpa-rent-Bridging-Algorithmus besitzt kein RIF-Äquivalent,und der Gedanke, Routing-Informationen in einem Frameabzulegen, ist bei Transparent-Bridging völlig unbekannt.

− Inkompatible Spanning-Tree-Algorithmen – Transparent-Bridging und SRB verwenden den Spanning-Tree-Algo-rithmus, um Schleifen zu vermeiden, aber die jeweiligenAlgorithmen der beiden Bridging-Methoden sind nichtkompatibel.

− Behandlung von Frames ohne Route-Information – SRBerwartet von allen LAN-überschreitenden Frames, daß sieRoute-Informationen enthalten. Ein Frame ohne RIF-Feld(einschließlich Transparent-Bridging-Konfigurations- undTopologieänderungsmeldungen, ebenso wie MAC-Frames,die von einer Transparent-Bridging-Domain stammen), derin einer SRB-Bridge ankommt, wird ignoriert.


22.3 Translational-Bridging

Weil es keine wirkliche Standardisierung dazu gibt, wie dieÜbertragung zwischen zwei unterschiedlichen Medienartenstattfinden soll, kann keine einzige Translational-Bridging-Umsetzung als korrekt bezeichnet werden. Im Folgenden wer-den einige verbreitete Methoden der Umsetzung des Transla-tional-Bridging beschrieben.

Translational-Bridges ordnen Adreßbits von Quelle und Zielneu an, wenn sie Ethernet und Token-Ring-Frames übersetzen.Das Problem der eingebetteten MAC-Adressen kann gelöstwerden, indem man die Bridge so programmiert, daß sie nachverschiedenen MAC-Adreßtypen sucht, aber diese Lösungmuß an jeden neuen eingebetteten MAC-Adreßtyp angepaßtwerden. Einige Translational-Bridging-Lösungen prüfen ein-fach auf die verbreitetsten eingebetteten Adressen. WennTranslational-Bridging-Software auf einem Multiprotocol-Router läuft, kann der Router dieses Protokoll erfolgreichvermitteln und das Problem völlig vermeiden.

Das RIF-Feld besitzt ein Unterfeld, welches die maximaleFrame-Größe angibt, die eine spezielle SRB-Umsetzung ak-zeptiert. Translational Bridges setzen das MTU-Größenfeldgewöhnlich auf 1500 Byte, wenn sie Frames von Transparent-Bridging-Domains an SRB-Domains versenden, und beschrän-ken so die Größe von Token-Ring-Frames beim Übergang indie Transparent-Bridging-Domain. Manche Hosts können die-ses Feld nicht richtig verarbeiten, was dazu führt, daß Trans-lational-Bridges Frames verwerfen, die die Ethernet-MTU-Größe überschreiten.

Bits, die Token-Ring-Funktionen ohne Ethernet-Äquivalentdarstellen, werden üblicherweise von den Translational-Bridges entfernt. Token-Ring-Priorität-, Reservation- undMonitorbits (im Zugriffssteuerungs-Byte) werden z.B. verwor-fen. Statusbits aus Token-Ring-Frames (im Byte nach demEnding-Delimiter, der dem Datenfeldende folgt) werden vonverschiedenen Bridge-Herstellern unterschiedlich behandelt.Manche Bridge-Hersteller ignorieren diese Bits. AndereBridges setzen das C-Bit (und weisen damit darauf hin, daßder Frame kopiert wurde), aber nicht das A-Bit (welches an-zeigt, daß die Zielstation die Adresse anerkennt). In diesem


Fall stellt ein Token-Ring-Quellknoten fest, ob der gesendeteFrame verlorenging. Gegner dieses Ansatzes vertreten dieMeinung, daß Zuverlässigkeitsmechanismen, wie das Verfol-gen verlorengegangener Frames, in Schicht 4 des OSI-Modellsrealisiert werden sollten. Gegner des Ansatzes, das »C-Bit« zusetzen, argumentieren, daß dieses Bit zur Verfolgung verlore-ner Frames gesetzt werden muß, das A-Bit aber nicht gesetztwerden kann, weil die Bridge nicht das Endziel ist.

Translational-Bridges können einen Software-Gateway zwi-schen zwei Domains erstellen. Für SRB-Endstationen besitztdie Translational-Bridge eine Ring-Nummer und eine zuge-ordnete Bridge-Nummer und erscheint als Standard-SRB. DieRing-Nummer stellt in diesem Fall die gesamte Transparent-Bridging-Domain dar. Für die Transparent-Bridging-Domainist die Translational Bridge einfach eine andere TransparentBridge.

Beim Bridging von einer SRB-Domain zu einer Transparent-Bridging-Domain wird die SRB-Information entfernt. RIFswerden gewöhnlich zur Verwendung mit dem folgenden Ant-wortverkehr zwischengespeichert. Beim Bridging vom Trans-parent-Bridging zur SRB-Domain kann die TranslationalBridge den Frame auf ein Unicast-Ziel prüfen. Wenn derFrame ein Multicast- oder Broadcast-Ziel besitzt, wird er alsSpanning-Tree-Explorer in die SRB-Domain verschickt. Wennder Frame eine Unicast-Adresse besitzt, sucht die Translatio-nal-Bridge das Ziel im RIF-Cache. Wenn der Pfad gefundenwurde, wird er verwendet und die RIF-Information demFrame hinzugefügt; sonst wird der Frame als Spanning-Tree-Explorer verschickt. Weil die beiden Spanning-Tree-Umset-zungen inkompatibel sind, sind mehrere Pfade zwischen SRB-und Transparent-Bridging-Domains üblicherweise nicht zu-lässig. Bild 22.2 bis Bild 22.3 zeigen Frame-Umwandlungen,die beim Translational-Bridging stattfinden können.

Bild 22.1 verdeutlicht die Frame-Umwandlung zwischen IEEE802.3 und Token-Ring. Die Destination and Source Adresses(DASA), der Service-Access Point (SAP), die Logical-LinkControl (LLC)-Information und die Daten werden in die ent-sprechenden Felder des Ziel-Frame übertragen. Die Ziel- undQuelladreßbits werden umgestellt. Beim Bridging von IEEE802.3 zu Token-Ring wird das Längenfeld des IEEE-802.3-


Frame entfernt. Beim Bridging von Token-Ring zu IEEE 802.3werden Zugriffsteuerbyte und RIF entfernt. Der RIF kann inder Translational-Bridge zur Verwendung mit demAntwortverkehr zwischengespeichert werden.

DASA Länge SAP Steuerung Daten

DASA RIF SAP Steuerung DatenACFC

IEEE 802.3

Token Ring

Bild 22.2 verdeutlicht die Frame-Umwandlung zwischenEthernet-Typ II und Token-Ring Subnetwork Access Protocol(SNAP). (SNAP fügt Verteiler- und Typencodes zum Datenfelddes Token-Ring-Frame hinzu.) Die Ziel- und Quellenadres-sen, Typeninformation und Daten werden in die entsprechen-den Felder des Ziel-Frame übertragen, und die DASA-Bitswerden neu angeordnet. Beim Bridging von Token-Ring-SNAPzu Ethernet-Typ II werden RIF-Information, SAP, LLC-Infor-mation und Vendorcode entfernt. Der RIF kann in der Trans-lational-Bridge zur Verwendung mit dem Antwortverkehr zwi-schengespeichert werden. Beim Bridging von Ethernet-Typ IIzu Token-Ring-SNAP werden keine Informationen entfernt.

Ethernet-Typ II

Token RingSNAP-Format

DASA Typ

DASA RIF SAP TypSteuerungACFC Daten

Daten

Liefercode

Bild 22.3 verdeutlicht die Frame-Umwandlung zwischenEthernet-Typ-II-»0x80D5«-Format und Token Ring. (Ether-net-Typ II »0x80D5« überträgt IBM-SNA-Daten in Ethernet-Frames.) Die DASA-, SAP-, LLC-Informationen und Datenwerden in die entsprechenden Felder des Ziel-Frame über-tragen, und die DASA-Bits werden neu angeordnet. BeimBridging von Ethernet-Typ II »0x80D5« zu Token Ring wer-den die Typen- und 80D5-Headerfelder entfernt. Beim Brid-ging von Token Ring zu Ethernet-Typ II »0x80D5« wird der

Bild 22.1:Vier Felder

bleiben bei derFrame-Um-

wandlung zwi-schen IEEE

802.3 undToken Ring

gleich

Bild 22.2:Bei der Frame-Umwandlung

zwischenEthernet-Typ II

und Token-Ring-SNAPbleiben drei

Felder gleich


RIF entfernt. Der RIF kann in der Translational-Bridge zurVerwendung mit dem Antwortverkehr zwischengespeichertwerden.

Ethernet- Typ II

Token Ring

DASA Steuerung

DASA RIF SteuerungSAPACFC Daten

DatenSAP80D5Header

Typ =0x80D5

22.4 Source-Route-Transparent-Bridging

SRT-Bridges verbinden Realisierungen des Transparent-Brid-ging- und des SRB-Algorithmus. SRT-Bridges verwenden dasRouting-Information-Anzeige(RII)-Bit, um zwischen Framesauf SRB-Basis und Frames mit Transparent-Bridging zu unter-scheiden. Ist das RII-Bit gleich 1, ist ein RIF im Frame vor-handen, und die Bridge verwendet den SRB-Algorithmus. Istdas RII-Bit gleich 0, ist kein RIF im Frame vorhanden, und dieBridge verwendet Transparent-Bridging.

Wie bei den Translational-Bridges stellen SRT-Bridges keineperfekte Lösung für die Probleme des Bridging zwischen ver-schiedenen Medien dar. SRT-Bridges müssen immer noch dieEthernet/Token-Ring-Inkompatibilitäten lösen, die bereits be-schrieben wurden. SRT-Bridging erfordert wahrscheinlich eineAufrüstung der Hardware der SRBs, um die erhöhte Belastungdurch die Analyse jedes Pakets zu meistern. Es können auchSoftware-Upgrades von SRBs notwendig werden. Weiterhinmüssen in Umgebungen mit gemischten SRT-Bridges, transpa-rente Bridges, und SRBs die gewählten Source-Routen alle ver-fügbaren SRT-Bridges und SRBs überspannen. Die Ergebnis-pfade sind möglicherweise Spanning-Tree-Pfaden von transpa-renten Bridges wesentlich unterlegen. Letztendlich verlierengemischte SRB/SRT-Bridging-Netzwerke die Vorteile des SRT-Bridging, so daß die Benutzer sich gezwungen sehen, einekomplette Umstellung zum SRT-Bridging mit beträchtlichenKosten durchzuführen. Immerhin erlaubt SRT-Bridging dieKoexistenz zweier zueinander nicht kompatibler Umgebungenund die Kommunikation zwischen SRB- und Transparent-Bridging-Endknoten.

Bild 22.3:Bei der Frame-UmwandlungzwischenEthernet-Typ II»0x80D5« undToken Ringbleiben vierFelder gleich

23 Source-Route Bridging (SRB)

23.1 Grundlagen

Der Source-Route-Bridging-(SRB-)Algorithmus wurde vonIBM entwickelt und dem IEEE-802.5-Komitee als Mittel fürdas Bridging zwischen allen LANs vorgelegt. Seit der Erstvor-lage hat IBM dem IEEE-802-Komitee einen neuen Bridging-Standard vorgelegt: das Source-Route-Transparent-(SRT-)-Bridging. Das SRT-Bridging beseitigt Probleme reiner SRBsvollständig und schlägt vor, für die beiden LAN-Bridges-Typentransparente Bridges und SRT-Bridges zu verwenden. ObwohlSRT-Bridging unterstützt wurde, sind SRBs noch im breitenEinsatz. SRT wird in Kapitel 22, »Mixed-Media Bridging«behandelt. Dieses Kapitel behandelt den grundlegenden SRB-Frame-Forwarding-Algorithmus und beschreibt SRB-Frame-Felder.

23.2 SRB-Algorithmus

SRBs werden so bezeichnet, weil sie davon ausgehen, daß diekomplette Quelle-zu-Ziel-Route in allen LAN-übergreifendenFrames plaziert wird, die von der Quelle versendet werden.SRBs speichern die Frames und leiten sie so weiter, wie durchdie Route im entsprechenden Frame-Feld vorgegeben wurde.Bild 23.1 zeigt ein Beispiel für ein SRB-Netzwerk.

KAPITEL 23Source-Route-Bridging (SRB)


In Bild 23.1 ist davon auszugehen, daß Host X einen Framean Host Y senden will. Anfangs ist Host X nicht bekannt, obsich Host Y im gleichen oder in einem anderen LAN befindet.Host X sendet einen Test-Frame, um das festzustellen. Wenndieser Frame ohne ein positives Anzeichen dafür zu Host Xzurückkehrt, daß Host Y ihn erhalten hat, geht Host X davonaus, daß sich Host Y in einem entfernten Segment befindet.

LAN 1

Host Y

Bridge 1

Bridge 2

Bridge 3

LAN 4

LAN 2

Bridge 4

Host X

LAN 3

Host X sendet einen Explorer-Frame, um den genauen Ortvon Host Y zu bestimmen. Jede Bridge, die den Explorer-Frame erhält (in diesem Beispiel Bridges 1 und 2), kopiert denFrame zu allen ausgehenden Anschlüssen. Die Explorer-Frames werden mit der Routen-Information ergänzt, währendsie durch das Netzwerk reisen. Wenn die Explorer-Frames vonHost X Host Y erreichen, antwortet Host Y auf jeden einzelnund verwendet dabei die angesammelten Routen-Informatio-nen. Nach Empfang aller Antwort-Frames wählt Host X nachvorgegebenen Kriterien einen Pfad aus.

Im Beispiel in Bild 23.1 führt dieser Prozeß zu zwei Routen:

− LAN 1 zu Bridge 1 zu LAN 3 zu Bridge 3 zu LAN 2

− LAN 1 zu Bridge 2 zu LAN 4 zu Bridge 4 zu LAN 2

Bild 23.1:Ein SRB-Netzwerk

enthält LANsund Bridges

Kapitel 23 • Source-Route Bridging (SRB) 297

Host X muß eine dieser beiden Routen auswählen. Die IEEE-802.5-Spezifikation legt kein Kriterium für die Auswahl derRoute durch Host X fest, gibt aber einige Empfehlungen, zudenen auch die folgenden gehören:

− Erster empfangener Frame

− Mit minimaler Anzahl von Hops antworten

− Nach größter erlaubter Frame-Größe antworten

− Verschiedene Kombinationen der genannten Kriterien

In den meisten Fällen wird der Pfad aus dem ersten empfange-nen Frame verwendet.

Nach Auswahl einer Route wird diese in Frames verpackt, dieals Routing-Information-Field (RIF) an Host Y gehen. Ein RIFwird nur in die Frames eingefügt, die für andere LANs be-stimmt sind. Das Vorhandensein von Routing-Informationenim Frame wird durch Setzen des hochwertigsten Bit innerhalbdes Source-Adressenfelds angezeigt, welches als Routing In-formation Indicator (RII)-Bit bezeichnet wird.

23.3 Frame-Format

Die Struktur des IEEE-802.5-RIF wird in Bild 23.2 gezeigt.

Ziel-adresse

Quell-adresse

RII

RIF Daten FCS

Routing- Control

Routing-Designator

Routing-Designator

DLängeTyp größterFrame

nichtbenutzt

Ring-nummer

Bridge-Nummer

802.5 MAC-Frame

Der in Bild 23.2 gezeigte RIF enthält zwei Hauptfelder: Rou-ting Control und Routing Designator. Diese Felder werden inder folgenden Zusammenfassung beschrieben.

Bild 23.2:Ein IEEE-802.5-RIF


23.3.1 Routing-Control-Feld

Das Routing-Control-Feld enthält zwei Teilfelder: Typ, Länge,D-Bit und größter Frame. Die Felder werden in der folgendenListe zusammengefaßt:

− Typ – Enthält drei mögliche Typen von Routing-Controls:

− Specifically Routed – Wird verwendet, wenn der Quell-knoten die Route im RIF-Header vorgibt. Die Bridgesvermitteln den Frame entsprechend dem (den) Route-Designator-Feld(ern).

− All Paths Explorer – Wird verwendet, um einen entfern-ten Knoten zu finden. Die Route wird gesammelt, wäh-rend der Frame das Netzwerk durchquert. Bridges er-gänzen den Frame mit ihrer Bridge-Nummer und derRing-Nummer, an die der Frame weitergeleitet wird.(Die erste Bridge ergänzt auch die Ring-Nummer desersten Rings.) Das Ziel empfängt so viele Frames, wie esRouten zu diesem Ziel gibt.

− Spanning-Tree-Explorer – Wird verwendet, um einenentfernten Knoten zu finden. Nur Bridges im Spanning-Tree leiten den Frame weiter, wobei sie ihn mit ihrerBridge-Nummer und der angeschlossenen Ring-Num-mer ergänzen, an die er weitergeleitet wird. Der Span-ning-Tree-Explorer reduziert die Anzahl der Frames, dieim Verlauf des Suchprozesses versandt wurden.

− Länge – Gibt die Gesamtlänge des RIF in Byte an. DerWert kann zwischen 2 und 30 Byte liegen.

− D-Bit – Zeigt und steuert die Richtung (vorwärts oderrückwärts) der Übertragung des Frame. Das D-Bit legt fest,ob Bridges die Ring-Nummer/Bridge-Nummer-Kombina-tionen der Route-Designatoren von rechts nach links (vor-wärts) oder links nach rechts (rückwärts) lesen.

− Größter Frame – Gibt die maximale Frame-Größe an, dieauf einer festgelegten Route verarbeitet werden kann. DieQuelle setzt einen Anfangswert für die maximale Frame-Größe ein, den die Bridges verringern können, wenn sie dieangeforderte Größe nicht erreichen können.

Kapitel 23 • Source-Route Bridging (SRB) 299

23.3.2 Routing-Designator-Felder

Jedes Routing-Designator-Feld enthält zwei Teilfelder:

− Ring-Nummer (12 Bit) – Der zugeordnete Wert muß in-nerhalb des durch Bridges verbundenen Netzwerks einma-lig sein.

− Bridge-Nummer (4 Bit) – Der zugeordnete Wert folgt derRing-Nummer. Diese Nummer muß nicht einmalig sein,solange sie nicht parallel zu einer anderen Bridge liegt, diezwei Ringe verbindet.

Bridges ergänzen den Frame mit ihrer Bridge-Nummer undder Ring-Nummer, an die der Frame weitergeleitet wird. (Dieerste Bridge ergänzt auch die Ring-Nummer des ersten Rings.)

Routen sind wechselnde Folgen von Ring- und Bridge-Num-mern, die mit Ring-Nummern beginnen und enden. Ein ein-zelner RIF kann mehr als ein Routing-Designator-Feld enthal-ten. Das IEEE gibt ein Maximum von 14 Routing-Designator-Feldern vor (d.h. maximal 13 Bridges oder Hops, weil dieletzte Bridge-Nummer immer gleich 0 ist).

Bis vor kurzem legte IBM ein Maximum von acht Routing-Designator-Feldern fest (maximal sieben Bridges oder Hops),und die meisten Bridge-Hersteller folgten dieser Vorgabe.Neuere IBM-Bridge-Software kann auf neuen LAN-Adapternbis zu 13 Hops unterstützen.

24 Transparent-Bridging

24.1 Grundlagen

Transparent-Bridges wurden zuerst durch die Digital Equip-ment Corporation (Digital) in den frühen 80er Jahren entwik-kelt. Digital stellte diese Ausarbeitungen dem Institute ofElectrical and Electronic Engineers (IEEE) zur Verfügung, wel-ches diese in den Standard IEEE 802.1. aufnahm. Transpa-rente Bridges sind in Ethernet/IEEE-802.3-Netzwerken sehrverbreitet. Dieses Kapitel gibt einen Überblick über die Hand-habung des Verkehrs und von Protokoll-Komponenten durchTransparent-Bridges.

24.2 Transparent-Bridging-Betrieb

Transparente-Bridges werden so bezeichnet, weil ihr Vorhan-densein und ihr Betrieb für Netzwerk-Hosts transparent ist.Wenn transparente Bridges eingeschaltet werden, erlernen siedie Topologie des Netzwerks, indem sie die Quellenadressenaller eingehenden Frames der angeschlossenen Netzwerkeanalysieren. Wenn beispielsweise eine Bridge einen Frame er-kennt, der auf Leitung 1 von Host A ankommt, schließt dieBridge daraus, daß Host A über das Netzwerk erreicht werdenkann, das an Leitung 1 angeschlossen ist. Im Verlauf diesesVorgangs bauen transparente Bridges eine Tabelle auf, wieetwa die in Bild 24.1.

KAPITEL 24Transparent-Bridging


1

1

2

2

1

1

3

15

17

12

13

18

9

14

NetzwerknummerHost-Adresse

.

.

.

.

.

.

Die Bridge verwendet ihre Tabelle als Basis für die Weiterlei-tung des Datenverkehrs. Wenn die Bridge an einer ihrerSchnittstellen einen Frame empfängt, sucht sie dessen Ziel-adresse in ihrer internen Tabelle. Enthält die Tabelle eine Zu-ordnung zwischen der Zieladresse und einem anderen An-schluß als dem, von dem der Frame empfangen wurde, wirdder Frame über den angegebenen Anschluß weitergeleitet.Wird keine Zuordnung gefunden, wird der Frame an alle An-schlüsse außer dem Eingangsanschluß versandt. Broadcastsund Multicasts werden ebenfalls auf diese Art verteilt.

Transparente Bridges isolieren den Intrasegment-Datenverkehrsehr wirkungsvoll und reduzieren damit den Datenverkehr inden einzelnen Segmenten. Dadurch werden die Antwortzeitendes Netzwerks für den Benutzer sichtbar verbessert. Der Um-fang der Datenverkehrsreduzierung und Verbesserung derAntwortzeiten ist vom Volumen des Datenverkehrs zwischenden Segmenten im Verhältnis zum gesamten Datenverkehr ab-hängig sowie weiterhin vom Volumen des Broadcast- undMulticast-Datenverkehrs.

24.2.1 Bridging-Loops

Ohne die Existenz eines Bridge-to-Bridge-Protokolls versagtder Transparent-Bridge-Algorithmus für den Fall, daß mehrerePfade aus Bridges und Local Area Networks (LANs) zwischenzwei beliebigen LANs im Netzwerk existieren. Bild 24.2 stellteine solche Bridging-Loop dar.

Bild 24.1:Transparente

Bridges baueneine Tabelleauf, die die

Erreichbarkeitdes Host

angibt

Kapitel 24 • Transparent-Bridging 303

Gehen wir davon aus, daß Host A einen Frame an Host Bsendet. Beide Bridges empfangen den Frame und schließendaraus korrekterweise, daß Host A sich im Netzwerk 2 befin-det. Nachdem Host B zwei Kopien des Host-A-Frame emp-fangen hat, empfangen beide Bridges unglücklicherweise denFrame noch einmal an ihren Netzwerk-1-Schnittstellen, weil inBroadcast-LANs alle Hosts alle Meldungen empfangen. In ei-nigen Fällen ändern die Bridges ihre internen Tabellen, um an-zuzeigen, daß sich Host A im Netzwerk 1 befindet. Wenn demso ist, empfangen bei einer Antwort von Host B auf denFrame von Host A beide Bridges diese Antwort und verwerfensie, weil ihre Tabellen angeben, daß der Zielhost (Host A) sichim selben Netzwerksegment befindet, wie die Quelle desFrame.

Netzwerk 2

Netzwerk 1

Host B

Host A

Bridge ABridge B

Zusätzlich zu grundlegenden Verbindungsproblemen stellt dieMultiplizierung von Broadcast-Meldungen in Netzwerken mitSchleifen ein ernsthaftes, potentielles Netzwerk-Problem dar.Wir beziehen uns wieder auf Bild 24.2 und nehmen an, daßder erste Frame von Host A ein Broadcast ist. Beide Bridgesleiten die Frames immer wieder weiter, verwenden dabei diegesamte verfügbare Bandbreite des Netzwerks und blockierenso die Übertragung anderer Pakete in beiden Segmenten.

Bild 24.2:Bridging-Loops könnenzu ungenauerWeiterleitungund Informa-tionsaufnahmein Transparent-Bridging-Umgebungenführen


Eine Topologie mit Schleifen, wie in Bild 24.2 gezeigt, kannebenso nützlich wie potentiell gefährlich sein. Eine Schleifeermöglicht mehrere Pfade durch ein Netzwerk. Netzwerke mitmehreren Wegen von der Quelle zum Ziel können durch diehöhere Flexibilität der Topologie eine höhere gesamte Fehler-toleranz im Netzwerk erreichen.

24.2.2 Spanning-Tree-Algorithmus (STA)

Der Spanning-Tree-Algorithmus (STA) wurde durch die Digi-tal Equipment Corporation, ein Ethernet-Hersteller, entwik-kelt, um die Vorteile von Schleifen zu erhalten und die Pro-bleme zu umgehen. Der Digital-Algorithmus wurde späterdurch das IEEE-802-Komitee überarbeitet und in der IEEE-802.1d-Spezifikation veröffentlicht. Der Digital-Algorithmusund der Algorithmus nach IEEE 802.1d sind nicht kompati-bel.

Der STA legt eine schleifenfreie Untermenge der Netzwerk-Topologie fest, indem er die Bridge-Anschlüsse, die bei Akti-vierung Schleifen bilden würden, in einen Standby-(Blocking-)-Zustand versetzt. Gesperrte Bridge-Anschlüsse können imFalle eines primären Verbindungsausfalls aktiviert werden undso einen neuen Weg durch das Netzwerk bilden.

Der STA verwendet einen Ansatz aus der Graphentheorie alsGrundlage für die Herstellung von schleifenfreien Untermen-gen der Netzwerk-Topologie. Die Graphentheorie besagt u.a.folgendes:

Für jeden verbundenen Graphen aus Knoten und Kanten,die Knotenpaare verbinden, stellt ein Spanning tree aus Kan-ten die Verbindungen des Graphen her, er enthält aber keineSchleifen.

Bild 24.3 zeigt, wie der STA Schleifen entfernt. Der STA ruftjede Bridge für die Vergabe eines eindeutigen Identifikatorsauf. Üblicherweise besteht dieser Identifikator aus einer derMedia Access Control (MAC)-Adressen der Bridge und einer


Priorität. Allen Anschlüssen in allen Bridges wird weiterhin eineindeutiger Identifikator (innerhalb dieser Brücke), der übli-cherweise durch seine eigene MAC-Adresse gebildet wird,zugewiesen. Abschließend wird jedem Bridge-Anschluß einPfadkostenwert zugeordnet, der die Kosten für die Übertra-gung eines Frame in ein LAN über diesen Anschluß darstellt.In Bild 24.3 sind die Pfadkosten auf den Leitungen einge-tragen, die die Bridges verlassen. Pfadkosten werden üblicher-weise als Vorgabewerte gesetzt, können aber durch den Netz-werk-Administrator manuell verändert werden.

Als erster Schritt bei der Berechnung eines Spanning-Tree wirddie Root-Bridge (Wurzel-Bridge) ausgewählt, welche dieBridge mit dem Bridge-Identifikator mit dem kleinsten Wertist. In Bild 24.3 ist Bridge 1 die Root-Bridge. Als nächstes wirdder Root-Anschluß an allen anderen Bridges bestimmt. DerRoot-Anschluß einer Bridge ist der Anschluß, über den dieRoot-Bridge mit den geringsten Gesamtpfadkosten erreichtwerden kann. Dieser Wert wird als Root-Pfadkosten bezeich-net.

Z

D 10

1020

R

20

20

R

20

20

10

10

10

10

D

D

D

R

R

V

X

Y

D = Bezeichneter AnschlußR = Root-AnschlußV bis Z = LANs

W

Bridge 2

Bridge 1

Bridge 5

Bridge 3

Bridge 4

Abschließend werden bezeichnete Bridges und deren bezeich-nete Anschlüsse bestimmt. Eine bezeichnete Bridge ist dieBridge in jedem LAN, welche die minimalen Root-Pfadkostengewährleistet. Diese Bridge ist die einzige, welche Frames anund von dem LAN weiterleiten darf, für das sie als bezeich-nete Bridge eingesetzt ist. Ein bezeichneter Anschluß eines

Bild 24.3:STA-basierteBridgesverwendenbezeichneteund Root-Anschlüsse,um Loops zubeseitigen


LAN ist der Anschluß, welcher es mit der bezeichneten Bridgeverbindet.

In manchen Fällen können zwei oder mehr Bridges die glei-chen Root-Pfadkosten haben. In Bild 24.3 können z.B. sowohlBridge 4 als auch 5 Bridge 1 (die Root-Bridge) Pfadkosten von10 erreichen. In diesem Fall werden die Bridge-Identifikatorennoch einmal verwendet, diesmal zur Festlegung derbezeichneten Bridges. Der LAN-V-Anschluß von Bridge 4 wirdüber den LAN-V-Anschluß von Bridge 5 ausgewählt.

Mit dieser Methode werden alle Bridges bis auf eine direkt mitjedem LAN verbundene Bridge entfernt, wodurch alle Schlei-fen zwischen zwei LANs entfernt werden. Der STA entferntaußerdem Schleifen mit mehr als zwei LANs, erhält aber dabeidie Connectivity. Bild 24.4 zeigt das Ergebnis der Anwendungdes STA auf das Netzwerk aus Bild 24.3. Bild 24.4 erklärt dieBaum-Topologie. Ein Vergleich dieser Abbildung mit der Ab-bildung vor der Erstellung des Baums zeigt, daß der STA dieAnschlüsse von Bridge 3 und Bridge 5 an das LAN-V in denStandby-Modus versetzt hat.

Bridge 2

Z

Bridge 1

Bridge 5

Bridge 3

Y

Activer AnschlußGesperrter Anschluß

Bridge 4

V

V

W X

Diese Baumberechnung wird beim Einschalten der Bridge undbei Erkennung von Änderungen der Topologie ausgeführt. DieBerechnung erfordert eine Kommunikation zwischen denSpanning-Tree-Bridges, die mit Konfigurationsmeldungen rea-lisiert wird (diese werden gelegentlich als bridge protocol dataunits oder BPDUs bezeichnet). Konfigurationsmeldungen ent-

Bild 24.4:Erstellt eineLoop-freie

Baumtopo-logie. Ein

STA-basiertesTransparent-

Bridge-Netzwerk


halten Informationen, welche die Bridge identifizieren, die alsRoot angesehen wird (Root-Identifikator), und die Entfernungvon der sendenden Bridge zur Root-Bridge (Root-Pfadkosten).Konfigurationsmeldungen enthalten außerdem die Bridge- undAnschluß-Identifikatoren der sendenden Bridge sowie dasAlter der Informationen in der Konfigurationsmeldung.

Bridges tauschen in regelmäßigen Abständen Konfigurations-meldungen aus (üblich sind zwischen ein und vier Sekunden).Wenn eine Bridge ausfällt (wodurch sich die Topologie än-dert), stellen die benachbarten Bridges den Ausfall der Konfi-gurationsmeldungen fest und veranlassen eine Neuberechnungdes Baums.

Alle Entscheidungen zur Topologie der Transparent-Bridgesfallen lokal. Konfigurationsmeldungen werden zwischen be-nachbarten Bridges ausgetauscht. Innerhalb der Netzwerk-Topologie existiert keine zentrale Autorität oder Verwaltung.

24.3 Frames-Format

Transparente Bridges tauschen Konfigurationsmeldungen undTopologie-Änderungsmeldungen aus. Zum Einrichten einerNetzwerk-Topologie werden zwischen Bridges Konfigurations-meldungen ausgetauscht. Topologie-Änderungs-Meldungenwerden nach Änderungen der Topologie versendet, um einenAufruf des STA zu veranlassen.

Bild 24.5 verdeutlicht das IEEE-802.1d-Konfigurationsmel-dungsformat.

VersionProtokoll-

IDFlags Root-ID

Root-Pfad-kosten

Bridge-ID

Feldlänge in Byte 2 1 4 8

Meldungs-typ

1 1 8

Anschluß-ID

2

Meldungs-alter

2

MaximalesAlter

2

Hello-Zeit

2

Vorwärts-verzöge-

rung

2

Bild 24.5: Die Transparent-Bridge-Konfigurationsmeldung setzt sich aus zwölfFeldern zusammen


Es folgen die Felder der Konfigurationsmeldung der Transpa-rent-Bridge:

− Protokoll-ID – enthält den Wert Null.

− Version – enthält den Wert Null.

− Meldungstyp – enthält den Wert Null.

− Flag – enthält 1 Byte, von dem nur die ersten Bits verwen-det werden. Das Topology-Change-(TC-)Bit weist auf eineÄnderung der Topologie hin. Das Topology-Change-Acknowledgment-(TCA-)Bit wird als Anerkennung desEmpfangs einer Konfigurationsmeldung mit gesetztem TC-Bit gesetzt.

− Root-ID – Identifiziert die Root-Bridge durch Angabe ihrer2 Byte langen Priorität gefolgt von der 6-Byte langen ID.

− Root-Pfadkosten – Enthält die Pfadkosten der Bridge, wel-che die Konfigurationsmeldung an die Root-Bridge gesen-det hat.

− Bridge-ID – Identifiziert die Priorität und ID der Bridge,von der die Meldung stammt.

− Anschluß-ID – Identifiziert den Anschluß, von dem dieKonfigurationsmeldung stammt. Dieses Feld ermöglichtdas Auffinden und Behandeln von Schleifen, die durchmehrere angeschlossene Bridges gebildet werden.

− Meldungsalter – Gibt die Zeit seit Absenden der Konfigu-rationsmeldung, auf der diese Konfigurationsmeldungbasiert, durch die Root an.

− Max. Alter – Gibt an, wann die aktuelle Konfigurations-meldung gelöscht werden sollte.

− Hello-Zeit – Gibt die Zeitspanne zwischen Root-Bridge-Konfigurationsmeldungen an.

− Vorwärtsverzögerung – Gibt die Zeitdauer an, die Bridgesnach einer Änderung der Topologie warten sollen, bevor sieeinen neuen Zustand herstellen. Wenn eine Bridge zu frühwechselt, sind möglicherweise nicht alle Netzwerk-Verbin-dungen bereit, ihren Zustand zu ändern, was zu Schleifenführen kann.


Die Topologie-Änderungsmeldungen enthalten nur 4 Byte.Dazu gehört ein Protokoll-ID-Feld, das den Wert Null enthält,ein Version-Feld, das ebenfalls den Wert Null enthält, und einMeldungstyp-Feld, das den Wert 128 enthält.

Kapitel 25: AppleTalkKapitel 26: DECnetKapitel 27: IBM Systems Network Architecture (SNA) Kapitel 28: Internet-ProtokolleKapitel 29: NetWare-ProtokolleKapitel 30: Protokolle der Open System Interconnection Kapitel 30: (OSI)Kapitel 31: Banyan VINESKapitel 32: Xerox Network Systems (XNS)

Teil 5: Netzwerk-Protokolle

Teil 5, »Netzwerk-Protokolle«, gibt einen Überblick über diegrundlegenden Komponenten der heute am weitesten verbrei-teten Netzwerk-Protokolle. In den einzelnen Kapiteln werdenfolgende Themen behandelt:

AppleTalk – Dieses Kapitel behandelt die AppleTalk-Proto-kolle.

DECnet – Dieses Kapitel behandelt die Protokolle DECnetPhase IV und DECnet/OSI (DECnet Phase V).

IBM Systems Network Architectures (SNA) – Dieses Kapitelfaßt die Grundlagen des IBM-SNA-Protokolls hinsichtlich derKomponenten und der Funktionen einschließlich hierarchi-scher und Peer-basierter Umgebungen zusammen.

Internet Protocols – Dieses Kapitel beleuchtet die üblichen In-ternet-Protokolle, zu denen IP, TCP, UDP, ICMP und ARP ge-hören, und gibt einen Überblick zu bekannten Protokollen derAnwendungsschicht.

NetWare Protocols – Dieses Kapitel behandelt die NetWare-Protokolle, insbesondere von IPX und SAP.

Open Systems Interconnection (OSI) – Dieses Kapitelbeschreibt die Funktionen und Eigenschaften der ISO-OSI-Protokolle.

TEIL 5Netzwerk-Protokolle


Banyan VINES – In diesem Kapitel wird die Protokoll-FamilieBanyan VINES beschrieben.

Xerox Network Systems (XNS) – In diesem Kapitel werdendie XNS-Protokolle beschrieben.

25 AppleTalk

25.1 Background

AppleTalk besteht aus einer Reihe von Übertragungsprotokol-len, die in den frühen 80er Jahren von Apple Computer zu-sammen mit den Macintosh-Rechnern entwickelt wurden.Zweck von AppleTalk war es, vielen Benutzern die gemein-same Verwendung von Ressourcen wie Dateien und Druckernzu ermöglichen. Geräte, die Ressourcen zur Verfügung stellen,nennt man Server, während man bei Geräten, die diese Res-sourcen nutzen (wie etwa dem Macintosh-Rechner eines Be-nutzers) von Clients spricht. AppleTalk ist also eine der frühenImplementierungen einer verteilten Client-Server-Netzwerk-Architektur.

AppleTalk wurde mit einer transparenten Netzschnittstelleausgestattet. Das heißt, der Austausch zwischen Client-Rech-nern und Netzwerk-Servern erfordert wenig Aufwand von Sei-ten des Benutzers. Außerdem laufen die tatsächlichen Opera-tionen der AppleTalk-Protokolle für den Benutzer unsichtbarab. Er sieht also nur das Ergebnis dieser Vorgänge. Es gibtzwei Versionen von AppleTalk: AppleTalk Phase 1 und Apple-Talk Phase 2.

AppleTalk Phase 1, die erste Spezifikation von AppleTalk,wurde in den frühen 80er Jahren ausschließlich für den Ein-satz in lokalen Arbeitsgruppen entwickelt. Daher ist Phase 1in zweierlei Hinsicht eingeschränkt. Ihre Netzwerk-Segmentekönnen nicht mehr als 127 Hosts und 127 Server enthalten,

KAPITEL 25AppleTalk


und sie unterstützt nur nicht erweiterte Netzwerke. Erweiterteund nicht erweiterte Netzwerke werden später in diesem Kapi-tel noch ausführlich beschrieben.

AppleTalk Phase 2, die zweite, verbesserte Implementierungvon AppleTalk, wurde für den Gebrauch in größeren Ver-bundnetzen entwickelt. Phase 2 behebt die Einschränkungenvon Phase 1 und enthält darüber hinaus einige Verbesserun-gen. Mit Phase 2 können in einem einzigen AppleTalk-Netzwerk-Segment 253 Hosts oder Server miteinander kombi-niert werden. Außerdem werden sowohl nicht erweiterteNetzwerke als auch erweiterte Netzwerke unterstützt.

Netzwerk 1

Netzwerk 2

Netzwerk 3

Netzwerk 5

Zone A

Zone B

Zone C

Netzwerk 4

Socket

Socket

25.2 AppleTalk-Netzwerk-Komponenten

AppleTalk-Netzwerke sind hierarchisch aufgebaut. Die Basiseines AppleTalk-Netzwerks bilden vier Grundkomponenten:Sockets, Knoten, Netzwerke und Zonen. Bild 25.1 veran-

Bild 25.1:Das Apple-

Talk-Ver-bundnetz

besteht aushierarchisch

angeordnetenKomponenten

Kapitel 25 • AppleTalk 315

schaulicht den hierarchischen Aufbau dieser Komponenten ineinem AppleTalk-Verbundnetz. In den folgenden Abschnittenwerden sie im einzelnen erläutert.

25.2.1 Sockets

Ein AppleTalk-Socket ist eine einzelne, adressierbare Stelle in-nerhalb eines AppleTalk-Knotens. Er ist der logische Punkt, andem die AppleTalk-Software der oberen Schicht abläuft unddas Datagram Delivery Protocol (DDP) der Netzwerk-Schichtagiert. Diese Prozesse in der oberen Schicht nennt man SocketClients. Socket Clients bestehen aus einem oder mehrerenSockets, die dazu verwendet werden, Datenpakete zu sendenund zu empfangen. Sockets können statisch oder dynamischzugewiesen werden. Statisch zugewiesene Sockets sind für denGebrauch von Protokollen oder anderen Prozessen vorgese-hen. Dynamisch zugewiesene Sockets werden den SocketClients auf Anforderung von DDP zugewiesen. Ein AppleTalk-Knoten kann bis zu 254 verschiedene Socketnummern enthal-ten. Bild 25.2 zeigt das Verhältnis zwischen den Sockets ineinem AppleTalk-Knoten und DDP in der Netzwerk-Schicht.

AppleTalk-Knoten

Socket Socket

Netzwerkschicht (DDP)

SocketClient

SocketClient

25.2.2 Knoten

Ein AppleTalk-Knoten ist ein Gerät, das mit dem AppleTalk-Netzwerk verbunden ist. Dieses Gerät kann ein Macintosh-Rechner, ein Drucker, ein IBM-PC, ein Router oder ein ähnli-ches Gerät sein. In jedem AppleTalk-Knoten laufen zahlreicheSoftware-Prozesse ab, die man Sockets nennt. Wie vorher

Bild 25.2:Socket Clientssenden undempfangen mitSockets Daten-pakete


schon dargelegt, besteht die Funktion dieser Sockets darin, dieSoftware-Prozesse zu identifizieren, die in dem Gerät ablaufen.Jeder Knoten in einem AppleTalk-Netzwerk gehört zu einemeinzigen Netzwerk und einer bestimmten Zone.

25.2.3 Netzwerke

Ein AppleTalk-Netzwerk besteht aus einem einzelnen, logi-schen Kabel und mehreren angeschlossenen Knoten. Das logi-sche Kabel besteht entweder aus einem einzelnen oder mehre-ren physischen Kabeln, die über Bridges und Router verbun-den werden. AppleTalk-Netzwerke können erweitert odernicht erweitert sein. Beides wird in den folgenden Abschnittenkurz beschrieben.

Nicht erweiterte Netzwerke

Ein nicht erweitertes AppleTalk-Netzwerk ist ein physischesNetzwerk-Segment, dem nur eine einzige Netzwerk-Nummerzugewiesen wird, die zwischen 1 und 1024 liegen kann. Netz-werk 100 und Netzwerk 562 zum Beispiel sind beides gültigeNetzwerk-Nummern in einem nicht erweiterten Netzwerk.Jede Knotennummer in einem lokalen Netzwerk muß einmaligsein, und auf einem einzelnen nicht erweiterten Netzwerk-Seg-ment kann nicht mehr als eine AppleTalk-Zone konfiguriertsein. (Eine Zone ist eine logische Gruppe von Knoten undNetzwerken.) AppleTalk Phase 1 unterstützt nur nicht erwei-terte Netzwerke, aber in der Regel werden nicht erweiterteNetzwerk-Konfigurationen in modernen Netzwerken nichtmehr eingesetzt, weil sie durch erweiterte Netze ersetzt wur-den. Bild 25.3 zeigt ein lokales AppleTalk-Netzwerk.

Netzwerk100

Adresse100.3

Adresse100.14

Adresse100.110

Adresse100.135

C-Zone

Adresse100.204Bild 25.3:

Einem lokalenNetzwerk wirdnur eine Netz-werk-Nummer

zugewiesen


Erweiterte Netzwerke

Ein erweitertes AppleTalk-Netzwerk ist ein physisches Netz-werk-Segment, dem mehrere Netzwerk-Nummern zugewiesenwerden können. Diese Konfiguration wird Kabelbereich ge-nannt. AppleTalk-Kabelbereiche können eine einzige Netz-werk-Nummer anzeigen oder mehrere aufeinanderfolgende.Die Kabelbereiche Netzwerk 3-3 (unitär) und Netzwerk 3-6sind zum Beispiel beide in einem erweiterten Netzwerk gültig.Genau wie bei anderen Protokollarten, wie etwa TCP/IP undIPX, muß jede Kombination aus Netzwerk-Nummer und Kno-tennummer in einem erweiterten Netzwerk einmalig sein, so-wie auch ihre Adresse für die Identifizierung einmalig seinmuß. Bei erweiterten Netzwerken können mehrere AppleTalk-Zonen auf einem einzigen Netzwerk-Segment konfiguriertsein, und die Knoten eines erweiterten Netzwerks können zujeder Zone gehören, die an dieses Netz angeschlossen ist.Konfigurationen erweiterter Netze haben Konfigurationennicht erweiterter in der Regel ersetzt. Bild 25.4 zeigt einerweitertes Netz.

Netzwerk100-103

Adresse100.3

Adresse100.129

Adresse101.14

Adresse103.100

Adresse102.3

ZoneMarketing

ZoneEntwicklung

F-Zone

25.2.4 Zonen

Eine AppleTalk-Zone ist eine logische Gruppe von Knotenoder Netzwerken, die erstellt wird, wenn der Administratordas Netzwerk konfiguriert. Die Knoten und Netzwerke müs-sen physisch nicht zusammenliegen, um zur selben AppleTalk-Zone zu gehören. Bild 25.5 zeigt ein AppleTalk-Verbundnetz,das aus drei nicht benachbarten Zonen besteht.

Bild 25.4:Einem erwei-terten Netzkönnen meh-rere Netzwerk-Nummernzugewiesenwerden


Zone Marketing

Netzwerk 10–12

Netzwerk 100–105

Zone R&D

ZoneEntwicklung

25.3 Bitübertragungs- und Sicherungs-schichten von AppleTalk

Wie auch bei anderen gebräuchlichen Protokollarten, wie etwaTCP/IP und IPX, wird auch in der AppleTalk-Architektur derMedienzugriff durch Protokolle aus den unteren Schichten, wieEhernet, Token Ring und FDDI, bestimmt. Es gibt in der Apple-Talk-Protokollsuite vier Hauptimplementierungen für denMedienzugriff: EtherTalk, LocalTalk, TokenTalk und FDDITalk.

Diese Implementierungen der Sicherungsschicht übernehmenÜbersetzungen von Adressen und weitere Funktionen, die es denproprietären AppleTalk-Protokollen erlauben, über standard-mäßige Schnittstellen, wie IEEE 802.3 (mit Hilfe von EtherTalk),Token Ring/IEEE 802.5 (mit TokenTalk) und FDDI (mit FDDI-Talk), zu kommunizieren. Darüber hinaus implementiert Apple-Talk seine eigene Netzwerk-Schnittstelle, LocalTalk. Bild 25.6veranschaulicht, wie die Implementierungen für den Me-dienzugriff von AppleTalk mit dem OSI-Schichtenmodell zu-sammenhängen.

IEEE 802.3Hardware

LocalTalkHardware

Token Ring/IEEE 802.5Hardware

EtherTalkLink Access

Protocol(ELAP)

TokenTalkLink Access

Protocol(TLAP)

FDDITalkLink Access

Protocol(FLAP)

LocalTalkLink Access

Protocol (LLAP)

OSI-Referenzmodell

Netzwerk

Anwendung

Darstellung

Kommunikation

Transport

Bitübertragung

SicherungFDDI

Hardware

Bild 25.5:Knoten oder

Netzwerke der-selben Zonemüssen phy-

sisch nicht zu-sammenliegen

Bild 25.6:Der Medienzu-griff von Apple

Talk liegt inden unteren

beiden Schich-ten des OSI-

Schichten-modells


25.3.1 EtherTalk

EtherTalk erweitert die Sicherungsschicht, damit die Apple-Talk-Protokollsuite mit dem Standard IEEE 802.3 arbeitenkann. EtherTalk-Netzwerke sind genau wie IEEE-802.3-Netz-werke aufgebaut, unterstützen dieselben Geschwindigkeitenund Segmentlängen und auch dieselbe Anzahl von aktivenNetzwerk-Knoten. So kann AppleTalk in Tausenden vonEthernet-basierten Netzwerken implementiert werden, dieheute im Einsatz sind. Die Kommunikation zwischen denAppleTalk-Protokollen aus den oberen Schichten und denEthernet-Protokollen wird vom EtherTalk Link-Access Proto-col (ELAP) geregelt.

EtherTalk Link-Access Protocol

Das EtherTalk Link-Access Protocol (ELAP) regelt das Zu-sammenspiel zwischen den proprietären AppleTalk-Protokol-len und der standardmäßigen IEEE-802.3-Sicherungsschicht.Die AppleTalk-Protokolle der oberen Schichten erkennen diestandardmäßigen IEEE-802.3-Hardware-Adressen nicht, wes-halb ELAP die Address-Mapping Table (AMT), die vomAppleTalk Address-Resolution Protocol (AARP) erstellt wird,verwendet, um Übertragungen korrekt zu adressieren.

ELAP regelt das Zusammenspiel der AppleTalk-Protokolle deroberen Schichten und der Sicherungsschicht, indem es die Da-ten in die Protokolleinheiten der 802.3-Sicherungsschicht ein-kapselt. ELAP führt drei Stufen Kapselung durch, wenn esDDP-Pakete übermittelt:

− Subnetwork-Access Protocol (SNAP) Header

− IEEE 802.2 Logical Link-Control (LLC) Header

− IEEE 802.3 Header

Dieser Prozeß der Kapselung, den ELAP durchführt, wird inden folgenden Abschnitten genauer beschrieben.

Datenübermittlung mit ELAP

ELAP verwendet einen vorgegebenen Prozeß, um Daten überein physisches Medium zu übermitteln. Zunächst empfängtELAP ein DDP-Paket, das eine Übermittlung anfordert. Dannfindet es die Protokolladresse, die in dem DDP-Header spezi-


fiziert ist und überprüft die AMT, um die entsprechende IEEE-802.3-Hardware-Adresse zu finden. ELAP setzt daraufhin dreiverschiedene Header vor das DDP-Paket, beginnend mit denSNAP- und 802.2-LLC-Headern. Der dritte Header ist derIEEE-802.3-Header. Wenn der Header vor das Paket gesetztwird, wird die Hardware-Adresse aus der AMT in das Ziel-adreßfeld plaziert. Das Endergebnis, ein IEEE-802.3-Frame,wird an das physische Medium übergeben, damit er an seinZiel übertragen wird.

25.3.2 LocalTalk

LocalTalk, eine proprietäre Implementierung der Sicherungs-schicht, die von Apple Computer für die AppleTalk-Protokoll-suite entwickelt wurde, war als kostengünstige Netzwerk-Lösung konzipiert, mit der lokale Arbeitsgruppen verbundenwerden könnten. In Apple-Produkte ist LocalTalk-Hardwareeingebaut, die leicht über die preiswerten Twisted-Pair-Kabelvernetzt werden kann. LocalTalk-Netzwerke sind in einer Bus-typologie aufgebaut, das heißt, sie sind miteinander in Serieverbunden. Netzwerk-Segmente sind auf eine Reichweite von300 Metern mit maximal 32 aktiven Knoten beschränkt, undmehrere LocalTalk-Netzwerke können durch Router oder an-dere zwischengeschaltete Geräte verbunden werden. Für dieKommunikation zwischen dem Sicherungsschicht-ProtokollLocalTalk und den Protokollen der oberen Schichten sorgt dasLocalTalk Link-Access Protocol (LLAP).

LocalTalk Link-Access Protocol

Das LocalTalk Link-Access Protocol (LLAP) ist ein Protokollfür den Medienzugriff, das in LocalTalk-Netzwerken verwen-det wird, um bestmögliche und fehlerfreie Auslieferung vonFrames zwischen AppleTalk-Knoten zu gewährleisten. Das be-deutet, daß die Auslieferung von Datagrammen nicht von derLLAP garantiert wird. Diese Funktion wird nur von Protokol-len der höheren Schichten der AppleTalk-Architektur ausge-übt. LLAP regelt den Knotenzugriff zum physischen Mediumund erfaßt die Knotenadressen der Sicherungsschicht dyna-misch.


Regulierung des Knotenzugriffs zum physischen Medium

LLAP realisiert den Medienzugriff mit einer Methode, diecarrier-sense multiple access, collision avoidance (CSMA/CA)genannt wird, bei der Knoten die Verbindung daraufhin prü-fen, ob sie gerade benutzt wird. Die Verbindung muß für einengewissen Zeitraum frei sein, bevor der Knoten mit der Daten-übertragung beginnen kann. LLAP nutzt einen Datenaus-tausch namens Handshake, um Kollisionen zu vermeiden (alsogleichzeitige Übertragung von zwei oder mehr Knoten). Einerfolgreicher Handshake zwischen Knoten reserviert die Ver-bindung effektiv zu ihrem Gebrauch. Wenn zwei Knoten einenHandshake gleichzeitig übermitteln, kollidieren die Übertra-gungen. In diesem Fall werden beide Übertragungen beschä-digt, so daß die Pakete abgelegt werden. Der Handshake-Aus-tausch ist nicht vollendet, und die sendenden Knoten folgern,daß es eine Kollision gab. Wenn es zur Kollision kommt,bleibt das Gerät für einen willkürlichen Zeitraum außer Be-trieb und versucht dann die Übertragung erneut. Dieser Pro-zeß ähnelt dem Zugriffsmechanismus, der bei der Ethernet-Technologie verwendet wird.

Erfassung von Knotenadressen

LLAP erfaßt die Knotenadressen der Sicherungsschicht dy-namisch. Dieser Prozeß erlaubt es, daß der Sicherungsschichteine einzelne Adresse zugewiesen wird, ohne daß diese Adressedem Knoten permanent zugewiesen wird. Wenn ein Knotenhochgefahren wird, weist LLAP ihm ein zufällig ausgewähltesIdentifizierungszeichen (Knoten-ID) zu. Die Einmaligkeit die-ser Knoten-ID wird von der Übermittlung eines speziellen Pa-kets bestimmt, das an die zufällig gewählte Knoten-ID adres-siert ist. Wenn der Knoten eine Antwort auf dieses Paket er-hält, ist die Knoten-ID nicht einmalig. Also wird dem Knoteneine andere zufällig gewählte Knoten-ID zugewiesen, und ersendet ein weiteres Paket, das an diesen Knoten adressiert ist,bis keine Antwort mehr kommt. Erhält der erfaßte Knoten beider ersten Abfrage keine Antwort, führt er einige weitere Ver-suche durch. Gibt es nach diesen Versuchen immer noch keineAntwort, wird die Knoten-ID als einmalig angesehen, und derKnoten verwendet diese Knoten-ID als seine Sicherungs-schichtadresse.


25.3.3 TokenTalk

TokenTalk erweitert die Sicherungsschicht dahingehend, daßes der AppleTalk-Protokollsuite erlaubt wird, auf einer stan-dardmäßigen IEEE-802.5/Token-Ring-Implementierung zu ar-beiten. TokenTalk-Netzwerke sind genauso aufgebaut wieIEEE-802.5/Token-Ring-Netzwerke und unterstützen die glei-chen Geschwindigkeiten und die gleiche Anzahl von aktivenNetzwerk-Knoten. Für die Kommunikation zwischen den Pro-tokollen der Sicherungsschicht, die mit Token Ring verwendetwerden, und den Protokollen der oberen Schichten sorgt dasTokenTalk Link-Access Protocol (TLAP).

TokenTalk Link-Access Protocol

Das TokenTalk Link-Access Protocol (TLAP) regelt die Zu-sammenarbeit zwischen proprietären AppleTalk-Protokollenund der standardmäßigen IEEE-802.5-Sicherungsschicht. DieAppleTalk-Protokolle der oberen Schichten erkennen die stan-dardmäßigen IEEE-802.5-Hardware-Adressen nicht, weswe-gen TLAP die AMT, die von der AARP gepflegt wird, verwen-det, um Übermittlungen korrekt zu adressieren. TLAP führtdrei Stufen der Kapselung durch, wenn es DDP-Pakete über-mittelt.



− IEEE 802.5 Header

TLAP-Datenübertragungsprozeß

Die TLAP-Datenübertragung verwendet mehrere Schritte, umDaten über ein physisches Medium zu senden. Wenn TLAP einDDP-Paket empfängt, das eine Übermittlung anfordert, stelltes die Protokolladresse fest, die im DDP-Header spezifiziertist, um dann in der AMT nach der entsprechenden IEEE-802.5/Token-Ring-Hardware-Adresse zu suchen. Dann setztTLAP drei verschiedene Header vor das DDP-Paket, wobei esmit den SNAP- und 802.2-LLC-Headern beginnt. Wenn derdritte Header, IEEE 802.5/Token Ring, vor das Paket gesetztwird, wird die Hardware-Adresse aus der AMT in das Ziel-adreßfeld eingefügt. Das Endergebnis, ein IEEE-802.5/Token-


Ring-Frame, wird dem physischen Medium zur Übertragungan das Ziel übergeben.

25.3.4 FDDITalk

FDDITalk erweitert die Sicherungsschicht dahingehend, daßdie AppleTalk-Protokollsuite auf einer standardmäßigenANSI-FDDI-Implementierung arbeiten kann. FDDITalk-Netz-werke sind genau wie FDDI-Netzwerke aufgebaut und unter-stützen die gleichen Geschwindigkeiten und die gleiche Anzahlvon aktiven Netzwerk-Knoten.

FDDITalk Link-Access Protocol

Das FDDITalk Link-Access Protocol (FLAP) regelt die Zu-sammenarbeit zwischen den proprietären AppleTalk-Proto-kollen und der standardmäßigen FDDI-Sicherungsschicht. DieAppleTalk-Protokolle der oberen Schichten erkennen diestandardmäßigen FDDI-Hardware-Adressen nicht, weswegenFLAP die AMT, die von der AARP gepflegt wird, verwendet,um Übermittlungen korrekt zu adressieren. FLAP führt dreiStufen der Kapselung durch, wenn es DDP-Pakete übermittelt.



− FDDI Header

FLAP-Datenübertragungsprozeß

Wie TLAP führt auch FLAP einen mehrstufigen Prozeß durch,um Daten über ein physisches Medium zu übermitteln. WennFLAP ein DDP-Paket empfängt, das eine Übertragung anfor-dert, stellt es die Protokolladresse fest, die in dem DDP-Hea-der spezifiziert ist, und sucht dann in der AMT nach der ent-sprechenden FDDI-Hardware-Adresse. Dann setzt FLAP dreiverschiedene Header vor das DDP-Paket, wobei es mit denSNAP- und 802.2-LLC-Headern beginnt. Wenn der dritteHeader, der FDDI-Header, vor das Paket gesetzt wird, wird dieHardware-Adresse aus der AMT in das Zieladreßfeld einge-fügt. Das Endergebnis, ein FDDI-Frame, wird dem physischenMedium zur Übermittlung an das Ziel übergeben.


25.4 Netzwerk-Adressen

AppleTalk verwendet Adressen, um Geräte in einem Netzwerkzu identifizieren und zu finden, wie es ähnlich auch in jenenProzessen geschieht, die in so gängigen Protokollen wieTCP/IP und IPX ablaufen. Diese Adressen, die, wie im folgen-den Abschnitt beschrieben, dynamisch zugewiesen werden,setzen sich aus drei Elementen zusammen.

− Netzwerk-Nummer – Ein 16-Bit-Wert, der ein spezifiziertesAppleTalk-Netzwerk identifiziert (erweitert oder nicht er-weitert).

− Knotennummer – Ein 8-Bit-Wert, der einen bestimmtenAppleTalk-Knoten identifiziert, der an dem spezifiziertenNetzwerk hängt.

− Socketnummer – Eine 8-Bit-Zahl, die einen spezifischenSocket identifiziert, der auf einem Netzwerk-Knoten läuft.

AppleTalk-Adressen werden gewöhnlich als Dezimalwerte ge-schrieben, die durch Punkte getrennt sind. Zum Beispiel be-deutet 10.1.50 Netzwerk 10, Knoten 1, Socket 50. Dies kannauch mit 10.1, Socket 50 ausgedrückt werden. Bild 25.7 zeigtdas Adreßformat von AppleTalk-Netzwerken.

Netzwerk

AppleTalk-Network-Adresse

Knoten Socket

16 8 8

Feldlängein Bit:

25.4.1 Zuweisung von Netzwerk-Adressen

Eine der einzigartigen Eigenschaften von AppleTalk ist die dy-namische Natur der Geräteadressen. Es ist nicht nötig, einestatische Adresse für ein AppleTalk-Gerät zu definieren. DieAdressen werden AppleTalk-Knoten dynamisch zugewiesen,wenn sie erstmalig an ein Netzwerk angeschlossen werden.

Bild 25.7:Die Apple-Talk-Netz-

werk-Adressebesteht aus drei

Zahlen


Wenn der Knoten eines AppleTalk-Netzwerks hochgefahrenwird, erhält er eine provisorische Netzwerk-Schichtadresse.Der Netzwerk-Teil der provisorischen Adresse (die ersten 16Bit) wird dem Bootbereich entnommen, der aus reserviertenNetzwerk-Adressen besteht (Werte von 65280 bis 65534). DerKnotenteil (die nächsten 8 Bit) der provisorischen Adressewird zufällig ausgewählt.

Über das Zone-Information Protocol (ZIP) kommuniziert derKnoten mit einem Router, der an das Netzwerk angeschlossenist. Dieser Router stellt dem Netzwerk, mit dem der Knotenverbunden ist, den gültigen Kabelbereich zur Verfügung. Alsnächstes wählt der Knoten eine gültige Netzwerk-Nummeraus dem Kabelbereich, den der Router bereitstellt, und einezufällige Knotennummer. Durch einen Rundspruch wirdfestgestellt, ob die ausgewählte Adresse von einem anderenKnoten verwendet wird.

Wird die Adresse nicht verwendet (wenn also kein andererKnoten innerhalb eines vorgegebenen Zeitraums auf denRundspruch reagiert), ist dem Knoten erfolgreich eine Adressezugewiesen worden. Benutzt ein anderer Knoten die Adresse,beantwortet er die Anfrage mit der Meldung, daß die Adressein Gebrauch sei. Der neue Knoten muß eine andere Adressewählen und den Vorgang wiederholen, bis er eine Adressewählt, die nicht in Gebrauch ist.

25.5 AppleTalk Address-Resolution Protocol(AARP)

Das AppleTalk Address-Resolution Protocol (AARP) ist einNetzwerkschicht-Protokoll der AppleTalk-Protokollsuite, dasAppleTalk-Netzwerk-Adressen mit Hardware-Adressen ver-knüpft. AARP-Dienste werden auch von anderen AppleTalk-Protokollen verwendet. Wenn ein AppleTalk-Protokoll zumBeispiel Daten zu übermitteln hat, spezifiziert es eine Netz-werk-Adresse für das Ziel. Es ist Aufgabe von AARP, dieHardware-Adresse zu finden, die mit dem Gerät verbundenist, das diese Netzwerk-Adresse benutzt.

AARP verwendet einen Frage-Antwort-Prozeß, um die Hard-ware-Adressen von anderen Netzwerk-Knoten zu erfahren. Da


AARP ein medienabhängiges Protokoll ist, variiert die Me-thode, wie Hardware-Adressen abgefragt werden, je nachdem,welche Implementierung der Sicherungsschicht verwendetwird. Normalerweise wird ein Rundspruch an alle AppleTalk-Knoten im Netzwerk gesendet.

25.5.1 Address-Mapping Table

Jeder AppleTalk-Knoten enthält eine Address-Mapping Table(AMT/Adreßtabelle), in der Hardware-Adressen mit entspre-chenden Netzwerk-Adressen aufgelistet sind. Jedesmal, wenndas AARP eine Kombination von Netzwerk- und Hardware-Adresse zuweist, wird das in der AMT festgehalten.

Mit der Zeit steigt die Wahrscheinlichkeit, daß ein Eintrag inder AMT ungültig geworden ist. Deswegen wird jeder Eintragin der AMT mit einem Timer verknüpft. Wenn AARP ein Pa-ket empfängt, das den Eintrag vergleicht oder ändert, wird derTimer zurückgesetzt.

Läuft der Timer ab, wird der Eintrag aus der AMT gelöscht.Das nächste Mal, wenn ein AppleTalk-Protokoll mit diesemKnoten kommunizieren will, muß eine andere AARP-Abfrageübermittelt werden, um die Hardware-Adresse festzustellen.

25.5.2 Address Gleaning

In bestimmten Implementierungen werden eingehende DDP-Pakete auf die Hardware- und Netzwerk-Adressen des Aus-gangsknotens überprüft. DDP kann diese Information dann indie AMT eintragen. Dies ist eine Methode, mit der Geräte, wieRouter, Workstations oder Server, Hardware in einem Apple-Talk-Netzwerk finden können.

Dieses Verfahren, Adressen aus eingehenden Paketen zu erhal-ten, nennt man Address Gleaning. Address Gleaning wirdselten verwendet, aber in manchen Situationen kann es dieAnzahl von AARP-Abfragen, die übermittelt werden müssen,reduzieren.


25.5.3 AARP-Operation

Das AppleTalk-Address-Resolution Protocol (AARP) ordnetHardware-Adressen Netzwerk-Adressen zu. Muß ein Apple-Talk-Protokoll Daten senden, übergibt es die Netzwerk-Adresse des Empfangsknotens an das AARP. Es ist Aufgabedes AARP, die Hardware-Adresse zu liefern, die mit dieserNetzwerk-Adresse verknüpft ist.

Das AARP überprüft die AMT darauf, ob die Netzwerk-Adresse bereits mit einer Hardware-Adresse verknüpft ist.Sind die Adressen bereits verknüpft, wird die Hardware-Adresse dem anfragenden AppleTalk-Protokoll übergeben, dassie dazu benutzt, mit dem Empfänger zu kommunizieren. Sinddie Adressen nicht verknüpft, übermittelt AARP einen Rund-spruch, damit der Knoten, der die fragliche Netzwerk-Adressebenutzt, seine Hardware-Adresse liefert.

Wenn die Anfrage den Knoten, der die Netzwerk-Adresse be-nutzt, erreicht, antwortet er mit seiner Hardware-Adresse.Wenn es keinen Knoten mit dieser spezifischen Netzwerk-Adresse gibt, wird keine Antwort gesendet. Nach einer festge-legten Anzahl von weiteren Versuchen, nimmt das AARP an,daß die Protokolladresse nicht in Gebrauch ist, und sendeteine Fehlermeldung an das anfragende AppleTalk-Protokoll.Trifft eine Antwort ein, wird die Hardware-Adresse in derAMT mit der Netzwerk-Adresse verknüpft. Die Hardware-Adresse wird dann dem anfragenden AppleTalk-Protokollübergeben, das sie benutzt, um mit dem Empfangsknoten zukommunizieren.

25.6 Datagram-Delivery Protocol (DDP) imÜberblick

Das Datagram-Delivery Protocol (DDP) ist das primäre Netz-werkschicht-Routingprotokoll der AppleTalk-Protokollsuite,das einen leistungsstarken, verbindungsunabhängigen Data-gramm-Dienst zwischen AppleTalk-Sockets bietet. Wie auchbei Protokollen wie TCP werden keine virtuellen Schaltwegeoder Verbindungen zwischen zwei Geräten aufgebaut. DieFunktion der Ablieferung wird dagegen von Protokollen deroberen Schichten der AppleTalk-Protokollsuite gewährleistet.


Diese Protokolle der oberen Schichten werden später in die-sem Kapitel beschrieben.

DDP hat hauptsächlich zwei Funktionen: Übermittlung undEmpfang von Paketen.

− Übermittlung von Paketen – DDP erhält Daten von SocketClients, erstellt einen DDP-Header, indem es die passendenEmpfangsadressen verwendet, und leitet das Paket an dasProtokoll der Sicherungsschicht.

− Empfang von Paketen – DDP erhält Frames von der Siche-rungsschicht, überprüft den DDP-Header auf die Ziel-adresse, und leitet das Paket an den Zielsocket.

DDP pflegt den Kabelbereich des lokalen Netzwerks und dieNetzwerk-Adresse eines Routers, der mit dem lokalen Netz-werk über jeden AppleTalk-Knoten verbunden ist. Außer die-sen Informationen muß ein AppleTalk-Router mit Hilfe desRouting-Table Maintenance Protocol (RTMP) eine Routing-tabelle führen.

25.6.1 DDP-Übertragungsverfahren

DDP arbeitet ähnlich wie andere Routingprotokolle. Paketewerden an der Quelle adressiert, an die Sicherungsschicht ge-leitet und ans Ziel übermittelt. Wenn DDP Daten von einemProtokoll der oberen Schichten erhält, entscheidet es, obQuell- und Zielknoten im selben Netzwerk liegen, indem esdie Netzwerk-Nummer der Empfangsadresse überprüft. Liegtdie Netzwerk-Nummer des Ziels innerhalb des Kabelbereichsdes lokalen Netzwerks, wird das Paket in einen DDP-Headerverkapselt und zur Übermittlung an den Empfangsknoten andie Sicherungsschicht übergeben. Liegt die Netzwerk-Nummerdes Ziels nicht innerhalb des Kabelbereichs des lokalen Netz-werks, wird das Paket in einen DDP-Header verkapselt und andie Sicherungsschicht übergeben, damit sie es an einen Routerübermittelt. Zwischengeschaltete Router leiten die Pakete mitHilfe ihrer Routingtabellen an das Zielnetzwerk weiter. Wenndas Paket einen Router erreicht, der mit dem Zielnetzwerkverbunden ist, wird es an den Zielknoten übermittelt.


25.7 AppleTalk-Transportschicht

Die AppleTalk-Transportschicht implementiert zuverlässigeDatentransferdienste im Verbundnetz, die für die oberenSchichten transparent sind. Zu den Funktionen der Transport-schicht gehören typischerweise die Ablaufsteuerung, das Mul-tiplexing, die Verwaltung von virtuellen Schaltwegen, dieFehlerkontrolle und -beseitigung.

Es gibt fünf Hauptimplementierungen in der Transportschichtder AppleTalk-Protokollsuite:

− Routing-Table Maintenance Protocol (RTMP)

− Name-Binding Protocol (NBP)

− AppleTalk Update-Based Routing Protocol (AURP)

− AppleTalk Transaction Protocol (ATP)

− AppleTalk Echo Protocol (AEP)

Jede dieser Protokollimplementierungen wird im folgendenkurz vorgestellt.

25.7.1 Routing-Table Maintenance Protocol (RTMP) imÜberblick

Das Routing-Table Maintenance Protocol (RTMP) ist einTransportschicht-Protokoll der AppleTalk-Protokollreihe, dasdie Routingtabellen der AppleTalk-Router erstellt und pflegt.

RTMP basiert auf dem Routing-Information Protocol (RIP),und wie RIP benutzt RTMP den Hop-Zähler als Routinghilfe.Mit dem Hop-Zähler wird die Anzahl der Router oder sonsti-ger zwischengeschalteter Knoten festgestellt, die ein Paketdurchlaufen muß, um vom Quellnetzwerk zum Zielnetzwerkzu gelangen.

RTMP-Routingtabellen

RTMP erstellt und pflegt Routingtabellen der AppleTalk-Rou-ter. Diese Routingtabellen enthalten für jedes Netzwerk, dasein Paket erreichen kann, einen Eintrag.

Router tauschen regelmäßig Routinginformationen aus, umsicherzustellen, daß die Routingtabelle eines jeden Routers, die


wichtigsten Informationen enthält, und daß die Informationenim Verbundnetz übereinstimmen. Eine RTMP-Routingtabelleenthält folgende Informationen von den Zielnetzwerken, dieder Router kennt:

− Netzwerk-Kabelbereich des Zielnetzwerks

− Entfernung zum Zielnetzwerk in Hops

− Routerport, der zum Zielnetzwerk führt

− Adresse des nächsten Hop-Routers

− Aktueller Eintrag in der Routingtabelle (gut, zweifelhaftoder schlecht)

Bild 25.8 zeigt eine typische RTMP-Routingtabelle.

Router 1

Router 2

Router 3

RTMP-Routingtabelle

Entfernung

0

0

1

2

Port

1

2

3

3

nächsterHop

0

0

Router 2

Router 2

Status desEintrags

gut

gut

gut

gut

Port 1 Port 2

Port 3

Netzwerk 100 –103

Netzwerk 200

Netzwerk 15–20

Netzwerk-Kabelbereich

12

15–20

100–103

200

Netzwerk 12

25.7.2 Name-Binding Protocol (NBP) im Überblick

Das Name-Binding Protocol (NBP) ist ein Transportschicht-Protokoll der AppleTalk-Protokollsuite, das die Adressen, diein unteren Schichten verwendet werden, mit AppleTalk-Namen verknüpft. Socket Clients innerhalb der AppleTalk-

Bild 25.8:Eine RTMP-

Routingtabelleenthält Infor-

mationen überjedes Zielnetz-werk, das derRouter kennt


Knoten heißen Network-Visible Entities (NVEs). Eine NVE isteine adressierbare Ressource des Netzwerks, etwa ein Druk-kerdienst, die über das Verbundnetz zugänglich ist. NVEswerden Zeichenfolgen zugewiesen, die Entitätsnamen genanntwerden. NVEs haben auch eine Zone und verschiedene Attri-bute, die Entitätstypen, die mit ihnen verknüpft sind.

Es gibt zwei Hauptgründe dafür, Entitätsnamen statt Adressenin den oberen Schichten zu verwenden. Erstens werden dieNetzwerk-Adressen den Knoten dynamisch zugewiesen, än-dern sich also regelmäßig. Entitätsnamen erlauben dem Benut-zer, Netzwerk-Ressourcen und -Dienste, etwa Datenserver,immer auf die gleiche Weise anzusprechen. Zweitens sind Vor-gänge in den unteren Schichten für den Benutzer leichter ver-ständlich, wenn Namen statt Adressen verwendet werden, umRessourcen und Dienste anzusprechen.

Name Binding

Als Name Binding bezeichnet man den Vorgang, wenn NVE-Entitätsnamen mit Netzwerk-Adressen verknüpft werden. Je-der AppleTalk-Knoten verknüpft die Namen seiner NVEs mitihren Netzwerk-Adressen in einer Namentabelle. Die Gesamt-heit aller Namentabellen in den Verbundnetz-Knoten nenntman Namensverzeichnis, eine Datenbank aller Verknüpfungenzwischen Namen und Adressen. Name Binding wird durchge-führt, wenn ein Knoten erstmals hochgefahren wird, oder kurzbevor auf die genannte Entität zugegriffen wird (dynamisch).

NBP übt die folgenden vier Funktionen aus: Namensuche,Namenerkennung, Namenbestätigung und Namenlöschung.Die Namensuche wird verwendet, um die Netzwerk-Adresseeiner NVE zu erfahren, bevor auf die Dienste dieser NVE zu-gegriffen wird. NBP überprüft das Namenverzeichnis auf dieVerknüpfung zwischen Name und Adresse. Die Namenregi-strierung erlaubt es dem Knoten, seine Namentabelle zu erstel-len. NBP bestätigt, daß der Name nicht verwendet wird undfügt dann die Verknüpfung von Namen und Adresse in dieTabelle ein. Namenbestätigung wird verwendet, um abzuglei-chen, ob eine Verknüpfung, die durch die Namensuche zu-stande kam, noch zutrifft. Namenlöschung wird verwendet,um einen Eintrag aus der Namentabelle zu streichen, zum Bei-spiel, wenn der Knoten abgeschaltet wird.


25.7.3 AppleTalk Update-Based Routing Protocol(AURP)

Das AppleTalk Update-Based Routing Protocol (AURP) istein Transportschichtprotokoll der AppleTalk-Protokollsuite,mit dem zwei oder mehr AppleTalk-Verbundnetze über einTransmission-Control Protocol/Internet Protocol (TCP/IP)-Netzwerk verbunden werden können, damit ein AppleTalk-WAN entsteht. AURP verkapselt Pakete in einem User-Datagram-Protocol-(UDP-)Header und ermöglicht es, daß sietransparent über ein TCP/IP-Netzwerk gesendet werden. EineAURP-Implementierung besteht aus zwei Komponenten: ex-terne Router und AURP-Tunnel.

Externe Router verbinden ein lokales AppleTalk-Verbundnetzmit einem AURP-Tunnel. Sie wandeln AppleTalk-Daten undRoutinginformationen in AURP um und führen die Kapselungund Entkapselung des AppleTalk-Verkehrs durch. Ein externerRouter fungiert als AppleTalk-Router im lokalen Netzwerkund als Endknoten im TCP/IP-Netzwerk. Wenn externe Rou-ter sich erstmalig mit einem AURP-Tunnel verbinden, tau-schen sie mit anderen externen Routern Routinginformationenaus. Danach senden externe Router Routinginformationen nurunter den folgenden Umständen:

− Wenn ein Netzwerk der Routingtabelle hinzugefügt odergelöscht wird

− Wenn die Entfernung zu einem Netzwerk geändert wird

− Wenn eine Änderung im Pfad zu einem Netzwerk den ex-ternen Router veranlaßt, über sein lokales Verbundnetz an-statt über den Tunnel auf dieses Netzwerk zuzugreifen,oder über den Tunnel anstatt über das lokale Verbundnetz

Ein AURP-Tunnel fungiert als einzelne, virtuelle Datenverbin-dung zwischen entfernten AppleTalk-Verbundnetzen. Auf demWeg zwischen externen Routern kann jede Anzahl von physi-schen Knoten liegen, aber diese Knoten sind für die Apple-Talk-Netzwerke transparent. Es gibt zwei AURP-Tunnelarten:Point-to-Point-Tunnel und Mehrpunkttunnel. Ein Point-to-Point-AURP-Tunnel verbindet nur zwei externe Router. EinAURP-Mehrpunkttunnel verbindet drei oder mehr externeRouter. Auch gibt es zwei Arten von Mehrpunkttunnel. Ein


voll integrierter Mehrpunkttunnel ermöglicht es allen ange-schlossenen externen Routern, sich gegenseitig Pakete zuschicken. Bei einem partiell integrierten Mehrpunkttunnel, er-kennen ein oder mehr externe Router nur ein paar, aber nichtalle anderen externen Router. Bild 25.9 zeigt ein AppleTalk-LAN, das mit einem Point-to-Point-AURP-Tunnel verbundenist.

AppleTalk-Netzwerk

AppleTalk-Netzwerk

ExternerRouter

ExternerRouter

TCP/IP-Netzwerk

AURP-Tunnel

AURP-Kapselung

Beim Austausch von Routinginformationen oder Daten übereinen AURP-Tunnel müssen AppleTalk-Pakete von RTMP,ZIP und (in der Cisco-Implementierung) Enhanced IGRP inAURP umgewandelt werden. Die Pakete werden dann für denTransport durch das TCP/IP-Netzwerk in User-Datagram-Pro-tocol (UDP-)Header verkapselt. Umwandlung und Kapselungwerden von externern Routern vorgenommen, die die Apple-Talk-Routinginformationen oder Datenpakete erhalten, die anein entferntes AppleTalk-Verbundnetz gesendet werden müs-sen. Der externe Router wandelt die Pakete in AURP-Paketeum, die dann in UDP-Header verkapselt und in den Tunnel(also an das TCP/IP-Netzwerk) geschickt werden.

Das TCP/IP-Netzwerk behandelt die Pakete wie normalenUDP-Verkehr. Der entfernte externe Router empfängt dieUDP-Pakete und entnimmt dem UDP-Header Informationen.Die AURP-Pakete, egal ob Routinginformationen oder Daten-pakete, werden dann wieder in ihr ursprüngliches Format um-gewandelt. Enthalten die AppleTalk-Pakete Routinginforma-tionen, aktualisiert der externe Zielrouter seine Routingtabel-len entsprechend. Enthalten die Pakete Daten, die für einenAppleTalk-Knoten im lokalen Netzwerk bestimmt sind, wirdder Datenstrom an die entsprechende Schnittstelle gesendet.

Bild 25.9:Ein AURP-Tunnel ist einevirtuelle Ver-bindung zwi-schen entfern-ten Netzwer-ken


25.7.4 AppleTalk Transaction Protocol (ATP)

Das AppleTalk Transaction Protocol (ATP) ist ein Transport-schicht-Protokoll in der AppleTalk-Protokollsuite, das dieInteraktion zwischen zwei AppleTalk-Sockets regelt. EineInteraktion besteht aus Anfrage und Antwort, die zwischenden beteiligten Socket Clients ausgetauscht werden.

Der anfragende Socket Client sendet seine Anfrage, in der erden empfangenden Client auffordert, eine Aufgabe zu erledi-gen. Beim Empfang der Anfrage führt der Client die ge-wünschte Aufgabe aus und liefert in seiner Antwort die ange-forderte Information. Beim Übermitteln von Anfrage undAntwort übt ATP die wichtigsten Funktionen der Transport-schicht aus, einschließlich Bestätigung und erneute Übertra-gung, Sequentialisieren der Pakete, Segmentierung und neuZusammensetzen.

Verschiedene Protokolle der Kommunikationssteuerschichtlaufen über ATP, einschließlich des AppleTalk Session Protocol(ASP) und des Printer-Access Protocol (PAP). Diese beidenAppleTalk-Protokolle der oberen Schichten werden weiterunten in diesem Kapitel erläutert.

Antwortende Geräte verhalten sich unterschiedlich, je nach-dem, welcher von den beiden Interaktionsdiensten verwendetwird: At-Least-Once-(ALO-) oder Exactly-Once-(XO-)Inter-aktionen. ALO-Interaktionen werden verwendet, wenn dieAnfrage bei der Wiederholung unverändert bleibt. Wenn dieAnwort einer Interaktion verlorengeht, wird die Quelle ihreAnfrage wiederholen. Dies wirkt sich auf die Protokollopera-tionen nicht nachteilig aus, weil die Anfrage bei der Wiederho-lung unverändert bleibt. XO-Interaktionen werden verwendet,wenn die Wiederholung der Anfrage die Protokolloperationennegativ beeinflussen kann. Die empfangenden Geräte führeneine Liste jeder kürzlich erhaltenen Interaktion, so daß dop-pelte Anfragen nicht mehr als einmal bearbeitet werden.

25.7.5 AppleTalk Echo Protocol (AEP)

Das AppleTalk Echo Protocol (AEP) ist ein Transportschicht-Protokoll der AppleTalk-Protokollsuite, das Pakete erzeugt,die die Erreichbarkeit von Netzwerkknoten überprüfen. AEPkann in jeden AppleTalk-Knoten implementiert werden und


trägt die statisch zugewiesene Socketnummer 4 (der soge-nannte Echo Socket).

Um die Erreichbarkeit eines bestimmten Knotens zu prüfen,wird ein AEP-Anfragepaket an das DDP der Quelle überge-ben. DDP adressiert das Paket entsprechend und verzeichnetim Typenfeld, daß es sich bei dem Paket um eine AEP-Anfragehandelt. Erreicht das Paket das Ziel, prüft DDP das Typenfeldund merkt, daß eine AEP-Anfrage vorliegt. Das Paket wirdkopiert, in eine AEP-Antwort umgewandelt (durch die Verän-derung eines Felds) und an den Ausgangsknoten zurückge-schickt.

25.8 AppleTalk-Protokolle der oberenSchichten

AppleTalk implementiert Dienste in der Kommunikations-steuer-, der Darstellungs- und der Anwendungsschicht desOSI-Schichtenmodells. Vier Hauptimplementierungen derKommunikationssteuerschicht sind in der AppleTalk-Proto-kollreihe enthalten. (Die Kommunikationssteuerschicht er-stellt, verwaltet und beendet Kommunikationsvorgänge zwi-schen Einheiten der Darstellungsschicht).

Kommunikationsvorgänge bestehen aus Frage- und Antwort-diensten, die zwischen Anwendungen ablaufen, die sich aufverschiedenen Geräten des Netzwerks befinden. Diese Fragenund Antworten werden von Protokollen gesteuert, die in derKommunikationssteuerschicht implementiert sind.

Zu den Protokollimplementierungen der Kommunikations-steuerschicht, die von AppleTalk unterstützt werden, gehörendas AppleTalk Data-Stream Protocol (ADSP), das Zone-In-formation Protocol (ZIP), das AppleTalk Session Protocol(ASP) und das Printer-Access Protocol (PAP).

Das AppleTalk Filing Protocol (AFP) ist in den Darstellungs-und Anwendungsschichten der AppleTalk-Protokollsuite im-plementiert. Normalerweise bietet die Darstellungsschicht eineReihe von Kodierungs- und Umwandlungsfunktionen, die aufDaten der Anwendungsschicht bezogen werden. Die Anwen-dungsschicht interagiert mit Software-Anwendungen (die au-ßerhalb des OSI-Schichtenmodells liegen), die eine Kommuni-


kationskomponente einfügen. Zu den Funktionen der Anwen-dungsschicht gehören typischerweise die Erkennung vonKommunikationspartnern, das Feststellen, ob Ressourcen ver-fügbar sind, und die Synchronisierung der Kommunikation.Bild 25.10 veranschaulicht, wie die oberen Schichten derAppleTalk-Protokollreihe mit dem OSI-Schichtenmodell ver-knüpft sind.

Darstellung

Kommunikation

Anwendung

AppleTalk Data Stream

Protocol(ADSP)

Printer Access

Protocol (PAP)

Zone InformationProtocol

(ZIP)

AppleTalkSession Protocol(ASP)

AppleTalkFiling Protocol

(AFP)

25.8.1 AppleTalk Data-Stream Protocol (ADSP)

Das AppleTalk Data-Stream Protocol (ADSP) ist ein Protokollder Kommunikationssteuerschicht in der AppleTalk-Protokoll-suite, das die Vollduplex-Kommunikation zwischen zweiAppleTalk-Sockets aufbaut und aufrechterhält. ADSP stelltsicher, daß Daten korrekt aneinandergereiht und Pakete nichtdupliziert werden. ADSP implementiert ebenso einen Mecha-nismus der Ablaufsteuerung, der es dem Empfänger erlaubt,die Übermittlungen der Quelle zu verlangsamen, indem dieGröße des Empfangsfensters reduziert wird. ADSP setzt direktauf DDP auf.

25.8.2 Zone Information Protocol (ZIP)

Das Zone-Information Protocol (ZIP) ist ein Protokoll derKommunikationssteuerschicht der AppleTalk-Protokollsuite,das die Verknüpfungen zwischen Netzwerk-Nummer undZonennamen in AppleTalk-Routern pflegt. ZIP wird haupt-sächlich von AppleTalk-Routern verwendet. Aber auch andere

Bild 25.10:Apple-Talk-

Protokollebefinden sich

in drei deroberen Schich-

ten des OSI-Modells


Netzwerk-Knoten benutzen ZIP beim Hochfahren, um ihreZone auszuwählen. ZIP pflegt in jedem Router eine zone-in-formation table (ZIT). ZITs sind Listen, die spezifischen Netz-werk-Nummern einen oder mehr Zonennamen zuordnen. JedeZIT listet für jedes Netzwerk im Verbundnetz Netzwerk-Num-mern mit den entsprechenden Zonen auf. Bild 25.11 zeigt einegängige ZIT.

Zonen

Dokumentation,Schulung

Finanzen50

20-25

10 Marketing

Netzwerk-nummer

Entwicklung100-120

Administration100-120

25.8.3 AppleTalk Session Protocol (ASP)

Das AppleTalk Session Protocol (ASP) ist ein Protokoll derKommunikationssteuerschicht der AppleTalk-Protokollsuite,das Sitzungen zwischen AppleTalk-Clients und -Servern auf-baut und überwacht. ASP erlaubt es einem Client, eine Sitzungzu einem Server aufzubauen und ihm Befehle zu übermitteln.Es können mehrere Client-Sitzungen zu einem einzigen Servergleichzeitig bestehen. ASP nutzt viele der Dienste, die Proto-kolle der unteren Schichten, wie ATP und NBP, zur Verfügungstellen.

Bild 25.11:Die Zonenin-formations-tabelle hilft beider Identifika-tion von Zonen


25.8.4 Printer-Access Protocol (PAP) im Überblick

Das Printer-Access Protocol (PAP) ist ein Protokoll der Kom-munikationssteuerschicht in der AppleTalk-Protokollsuite, dases Client-Workstations erlaubt, Verbindungen mit Servern, vorallem Druckern, aufzubauen. Eine Sitzung zwischen derClient-Workstation und einem Server wird aufgebaut, wenndie Workstation eine Sitzung mit einem bestimmten Serveranfordert. PAP verwendet NBP, um die Netzwerk-Adresse desangeforderten Servers zu erfahren und öffnet dann dieVerbindung zwischen Client und Server. Daten werden mitHilfe von ATP zwischen Client und Server ausgetauscht. Wenndie Kommunikation vollendet ist, beendet PAP die Verbin-dung. Server mit PAP-Implementierung unterstützen mehrereVerbindungen mit Clients gleichzeitig. Dies ermöglicht eseinem Druckserver zum Beispiel, Aufgaben für verschiedeneWorkstations zur gleichen Zeit zu bearbeiten.

25.8.5 AppleTalk Filing Protocol (AFP)

Das AppleTalk Filing Protocol (AFP) ermöglicht es AppleTalk-Workstations, Dateien im Netzwerk gemeinsam zu benutzen.AFP erledigt Aufgaben in den Darstellungs- und Anwendungs-schichten der AppleTalk-Protokollsuite. Dieses Protokoll ge-währt die Transparenz im Netzwerk, indem es Benutzern er-laubt, entfernt gespeicherte Daten genauso zu handhaben wielokal gespeicherte. AFP verwendet die Dienste, die von ASP,ATP und AEP bereitgestellt werden.

25.9 AppleTalk-Protokollreihe

Bild 25.12 zeigt, wie die gesamte AppleTalk-Protokollsuite mitdem OSI-Schichtenmodell zusammenhängt.


IEEE 802.3Hardware

Token Ring/IEEE 802.5Hardware

FDDIHardware

Darstellung

Kommunikation

Transport

Netzwerk

Anwendung

Bitübertragung

Sicherung

OSI-Referenzmodell AppleTalk-Protokollsuite

LocalTalkHardware

EtherTalk Link Access

Protocol (ELAP)

TokenTalkLink Access

Protocol (TLAP)

FDDITalkLink Access

Protocol (FLAP)

Local TalkLink Access

Protocol (LLAP)

Routing TableMaintenance

Protocol (RTMP)

AppleTalkTransaction

Protocol (ATP)

AppleTalk DataStream Protocol

(ADSP)

Printer AccessProtocol

(PAP)

Zone InformationProtocol

(ZIP)

AppleTalkSession Protocol

(ASP)

AppleTalkFiling

Protocol (AFP)

Datagram Delivery Protocol (DDP)

AppleTalk Address Resolution Protocol (AARP)

AppleTalkEcho Protocol

(AEP)

Name BindingProtocol (NBP)

AppleTalkUpdate-Based

Routing Protocol(AURP)

25.9.1 Format von DDP-Paketen

Die folgenden Beschreibungen erläutern die Felder, aus denendie DDP-Pakete bestehen. Diese Pakete haben zwei möglicheFormen:

− Kleines DDP-Paket – Das kleine Format wird nur fürÜbertragungen zwischen zwei Knoten im selben Netzwerk-Segment eines lokalen Netzwerks verwendet. In neuartigenNetzwerken wird dieses Format selten benutzt.

− Erweitertes DDP-Paket – Das erweiterte Format wird fürÜbermittlungen zwischen Knoten mit verschiedenen Netz-werk-Nummern (in einem nicht erweiterten Netzwerk) undfür jegliche Übermittlung in einem erweiterten Netzwerkverwendet.

Bild 25.12:Die Apple-Talk-Protokoll-suite ist mit je-der Schicht desOSI-Modellsverknüpft


Bild 25.13 zeigt das Format des erweiterten DDP-Pakets:

DDP Header

0

1

Feldlängein Bit:

0

1

Hop- Zähler

4

Länge

10

Prüf-summe

16

Ziel-netzwerk

16

Quell-network

Ziel-knoten-

ID

16 8

Quell-knoten-

ID

8

Ziel-socket

8

Quell-socket

8

Daten

0-4688

Typ

8

Die Felder des erweiterten DDP-Pakets, die in Bild 25.13 ge-zeigt werden, werden im folgenden zusammengefaßt.

− Hop-Zähler – Zählt die Anzahl von zwischengeschaltetenGeräten, die das Paket durchlaufen hat. Am Ausgangs-punkt wird dieses Feld auf Null gesetzt. Jeder zwischenge-schaltete Knoten, den das Paket durchläuft, erhöht denWert um eins. Die maximale Anzahl von Hops ist 15.

− Länge – Zeigt die Gesamtlänge des DDP-Pakets in Byte.

− Prüfsumme – Enthält eine Prüfsumme, mit der Fehler auf-gespürt werden sollen. Wird keine Prüfsumme angegeben,werden die Bits in diesem optionalen Feld auf Null gesetzt.

− Zielnetzwerk – Zeigt die 16-Bit-Nummer des Zielnetz-werks an.

− Quellnetzwerk – Zeigt die 16-Bit-Nummer des Quellnetz-werks an.

− Zielknoten ID – Zeigt die 8-Bit-ID des Zielknotens an.

− Quellknoten ID – Zeigt die 8-Bit-ID des Quellknotens an.

− Zielsocket – Zeigt die 8-Bit-Nummer des Zielsocket an.

− Quellsocket – Zeigt die 8-Bit-Nummer des Quellsocket an.

− Typ – Zeigt das Protokoll der oberen Schichten an, zu demdie Informationen im Datenfeld gehören.

− Daten – Enthält Daten aus einem Protokoll der oberenSchichten.

Bild 25.13:Ein erweitertesDDP-Paket be-

steht aus 13Feldern

26 DECnet

26.1 Background

DECnet besteht aus einer Reihe von Kommunikationsproduk-ten, einschließlich einer Protokollsuite, die von der DigitalEquipment Corporation (Digital) entwickelt und gefördertwurde. Mit der ersten Version von DECnet, die 1975 heraus-kam, konnten zwei verbundene PDP-11-Minicomputer mit-einander kommunizieren. Digital ist in den darauffolgendenJahren dazu übergegangen, auch nicht proprietäre Protokollezu unterstützen, DECnet bleibt jedoch das wichtigste vonDigitals Netzwerk-Produkten. Dieses Kapitel liefert eine Über-sicht über die DECnet-Protokollsuite, Digitals Netzwerk-Architektur und die die Verwaltung des Datenverkehrs vonDECnet.

Bild 26.1 zeigt ein DECnet-Verbundnetz mit Routern, die zweiLANS verbinden, an die Workstations und VAXs angeschlos-sen sind:

DEC VAX

KAPITEL 26DECnet

Bild 26.1:In einem Ver-bundnetz, dasauf DECnetbasiert, verbin-den RouterWorkstationsund VAXs


Verschiedene Versionen von DECnet kamen auf den Markt.Die erste erlaubte es zwei direkt verbundenen Minicomputern,miteinander zu kommunizieren.

Die folgenden Versionen erweiterten die Funktionalität vonDECnet, indem die Unterstützung von zusätzlichen proprietä-ren und Standardprotokollen ermöglicht und gleichzeitig dieKompatibilität mit der jeweils vorhergehenden Version ge-währleistet wurde. Das bedeutet, daß die Protokolle abwärts-kompatibel sind. Vor allem zwei Versionen von DECnet befin-den sich heute im Einsatz: DECnet Phase IV und DECnet/OSI.

DECnet Phase IV ist die meistgebrauchte Version von DECnet.Die neueste ist aber DECnet/OSI. DECnet Phase IV basiert aufPhase IV der Digital Network Architecture (DNA) und unter-stützt proprietäre Digital-Protokolle und andere proprietäreund Standardprotokolle. DECnet Phase IV ist abwärtskompa-tibel zu DECnet Phase III, ihrer Vorgängerversion.

DECnet/OSI (auch DECnet Phase V genannt) ist abwärts-kompatibel zu DECnet Phase IV und die jüngste Version vonDECnet. Diese Version basiert auf DECnet/OSI DNA.DECnet/OSI unterstützt einige OSI-Protokolle, mehrere pro-prietäre DECnet-Protokolle und andere proprietäre und Stan-dardprotokolle.

26.2 DECnet Phase IV Digital NetworkArchitecture (DNA)

Die Digital Network Architecture (DNA) ist eine verständli-che, geschichtete Netzwerk-Architektur, die eine Vielzahl vonproprietären und Standardprotokollen unterstützt. Phase IVDNA ähnelt der Architektur, die im OSI-Schichtenmodell be-schrieben ist. Wie auch das OSI-Schichtenmodell, setzt sichPhase-IV-DNA aus Schichten zusammen, wobei spezifischeSchichtenfunktionen Dienste für die darüberliegenden Proto-kollschichten bereitstellen und von den darunterliegenden ab-hängen. Anders als das OSI-Modell besteht Phase-IV-DNAaber aus acht Schichten. Bild 26.2 zeigt, wie die acht Schichtenvon Phase-IV-DNA mit dem OSI-Schichtenmodell korrespon-dieren.

Kapitel 26 • DECnet 343

OSI-Referenzmodell DECnet Phase IV DNA

Routing

User

Verbindungskontrolle

Endkommunikation

Bitübertragung

Sicherung

Netzwerk

Darstellung

Anwendung

Kommunikation

Transport

Bitübertragung

Sicherung

Netzwerkanwendung

Netzwerk- management

Der folgende Abschnitt beschreibt Funktionalität und Aufgabejeder dieser Schichten und zeigt die Ähnlichkeiten zwischender Phase-IV-DNA-Architektur und dem OSI-Schichtenmodellauf.

26.2.1 Die Schichten von Phase-IV-DNA

Die DECnet Phase IV DNA definiert, wie in Bild 26.2 gezeigt,ein Acht-Schichten-Modell. Die Benutzerschicht ist die Netz-werkschnittstelle des Benutzers, die ihm über eine Kommuni-kationskomponente Dienste und Programme bereitstellt. DieBenutzerschicht entspricht ungefähr der OSI-Anwendungs-schicht. Die Netzwerk-Managementschicht ist die Benutzer-schnittstelle zu Informationen des Netzwerk-Managements.Diese Schicht arbeitet mit allen unteren Schichten von DNAzusammen und entspricht grob der OSI-Anwendungsschicht.Die Netzwerk-Anwendungsschicht stellt verschiedene Netz-werk-Anwendungen bereit, wie zum Beispiel den Fernzugriffauf Dateien und den Zugriff auf ein virtuelles Terminal. DieseSchicht entspricht ungefähr den Darstellungs- und Anwen-dungsschichten von OSI. Die Verbindungskontrollschicht re-

Bild 26.2:Phase IV be-steht aus achtSchichten, diesich am OSI-Modell orien-tieren


gelt logische Verbindungen zwischen Endknoten und ent-spricht ungefähr der OSI-Kommunikationssteuerschicht. DieEndkommunikationsschicht regelt die Ablaufsteuerung, dieSegmentierung und das Wiederzusammensetzen und ent-spricht ungefähr der OSI-Transportschicht. Die Routing-schicht erledigt das Routing und andere Funktionen und ent-spricht ungefähr der OSI-Netzwerk-Schicht. Die Sicherungs-schicht reguliert die physischen Netzwerk-Kanäle und ent-spricht der OSI-Sicherungsschicht. Die Bitübertragungschichtkontrolliert Hardware-Schnittstellen und entscheidet überelektrische und mechanische Funktionen des physischenMediums. Diese Schicht entspricht der OSI-Bitübertragungs-schicht.

26.2.2 Phase-IV-DECnet-Adressierung

DECnet-Adressen gehen nicht aus den physischen Netzwerkenhervor, mit denen die Knoten verbunden sind. Statt dessenfindet DECnet Hosts, indem es Adreßpaare aus Bereich undKnoten benutzt. Der Wert eines Bereichs liegt zwischen 1 undeinschließlich 63. Eine Knotenadresse kann zwischen 1 undeinschließlich 1023 liegen. Also kann jeder Bereich 1023Knoten haben, und es können ungefähr 65000 Knoten in ei-nem DECnet-Netzwerk adressiert werden. In einem Bereichkönnen viele Router liegen, und ein einziges Kabel kann eineVielzahl von Bereichen unterstützen. Wenn also ein Knotenverschiedene Netzschnittstellen hat, benutzt er dieselbe Be-reich/Knoten-Adresse für alle Schnittstellen. Bild 26.3 zeigt einDECnet-Netzwerk mit verschiedenen adressierbaren Entitäten.

Bereich 10

Bereichs-nummer

Knoten-nummer

Bereich 5

10.1

10.1

10.2

10.3

5.1

5.2

5.3

Bild 26.3:DECnet findet

Hosts durchBereich/Knoten-

Adreßpaare


DECnet-Hosts verwenden keine vom Hersteller zugewiesenenMedia Access Control (MAC)-Schichtenadressen. Statt dessenwerden die Netzwerk-Adressen in die MAC-Adressen nach ei-nem Algorithmus eingebettet, der die Bereichsnummern mit1024 multipliziert und dem Produkt die Knotennummer hin-zufügt. Die 16-Bit-Dezimaladresse, die daraus hervorgeht,wird in eine Hexadezimalzahl umgewandelt und an dieAdresse AA00.0400 in umgekehrter Reihenfolge angehängt,das niederstwertige Byte zuerst. Aus der DECnet-Adresse12.75 wird zum Beispiel 12363 (dezimal), was 304B ent-spricht (hexadezimal). Nachdem diese Adresse in umgekehrterReihenfolge an dem standardardmäßigen DECnet MAC-Adressenvorspann angehängt ist, lautet die AdresseAA00.0400.4B30.

26.3 DECnet/OSI Digital Network Architecture(DNA)

Die DECnet/OSI (DECnet Phase V) DNA ist der Architektur,die im OSI-Schichtenmodell festgelegt ist, sehr ähnlich.DECnet Phase V verwendet einen Schichtenansatz, der bei derUnterstützung von Protokollsuiten der oberen Schichten einhohes Maß an Flexibilität erreicht. Wie im folgenden Ab-schnitt beschrieben, kann DECnet OSI tatsächlich eine Viel-zahl von Protokollsuiten unterstützen.

26.3.1 DECnet/OSI-DNA-Implementierungen

Die DECnet/OSI-DNA definiert ein Schichtenmodell, das dreiProtokollsuiten implementiert: OSI, DECnet und TransmissionControl Protocol/Internet Protocol (TCP/IP). Die OSI-Imple-mentierung von DECnet/OSI entspricht dem OSI-Modell mitseinen sieben Schichten und unterstützt viele der standard-mäßigen OSI-Protokolle. Die Digital-Implementierung vonDECnet/OSI gewährt die Abwärtskompatibilität zu DECnetPhase IV und unterstützt viele proprietäre Digital-Protokolle.Die TCP/IP-Implementierung von DECnet/OSI unterstützt dieTCP/IP-Protokolle der unteren Schichten und ermöglicht dieÜbermittlung von DECnet-Daten über TCP-Transportproto-kolle. Bild 26.4 zeigt die drei DECnet/OSI-Implementierungen:


Netzwerk

Anwendung

Darstellung

Kommunikation

Höhere Schichtenvon DECnet

Phase IV

Transport

IP

TCP

PhysicalBitübertragung

Sicherung

DNA(DECnet/OSI)

OSI-Referenzmodell TCP/IP-Datenstapel

TCP/IP-Anwendung

DECnet over TCP

26.4 DECnet-Medienzugriff

DECnet Phase IV und DECnet/OSI unterstützen verschieden-ste Implementierungen des Medienzugriffs in der Bitübertra-gungs- und Sicherungsschicht. Dies führte zu einer relativ brei-ten Akzeptanz von DECnet in der Netzwerk-Industrie. Wie inden folgenden Abschnitten erläutert wird, unterstützen sowohlDECnet Phase IV als auch Phase V viele der heute gängigenTechnologien der Bitübertragungs- und Sicherungsschicht.

In der Bitübertragungsschicht unterstützen DECnet Phase IVund DECnet/OSI die populärsten physischen Implementierun-gen, wie etwa Ethernet/IEEE 802.3, Token Ring/IEEE 802.5,und Fiber-Distributed Data Interface (FDDI). Außerdem un-terstützt DECnet/OSI Frame Relay und X.21bis.

In der Sicherungsschicht unterstützen DECnet Phase IV undDECnet/OSI IEEE 802.2 Logical Link Control (LLC), Link-Access Procedure, Balanced (LAPB), Frame Relay und High-Level Data-Link Control (HDLC). Ebenso unterstützen so-wohl DECnet Phase IV als auch DECnet/OSI die proprietärenDigital-Sicherungsschichtprotokolle, Digital Data Communi-cations Message Protocol (DDCMP), die Point-to-Point- undKonferenzverbindungen, Voll- und Halbduplex-Kommunika-tion über synchrone und asynchrone Kanäle wie auch Fehler-behebung, Sequenzialisieren und Verwaltung.

Bild 26.4:OSI, DECnet

und TCPwerden

allesamt vonDECnet/OSIDNA unter-

stützt


26.5 DECnet-Routing

DECnet-Routing wird in der Routingschicht der DNA inDECnet Phase IV und in der Netzwerkschicht des OSI-Mo-dells in DECnet/OSI durchgeführt. Die Routingimplementie-rungen in DECnet Phase IV und DECnet/OSI sind ähnlich.

DECnet-Phase-IV-Routing ist durch das DECnet Routing Pro-tocol (DRP) implementiert, bei dem es sich um ein relativ ein-faches und effektives Protokoll handelt, dessen Hauptfunktiondarin besteht, die optimale Strecke durch ein DECnet-Phase-IV-Netzwerk zu finden. Bild 26.5 zeigt an einem DECnet-Netzwerk, wie das Routing in einem DECnet-Phase-IV-Netz-werk abläuft.

A D

E

C

Bester Pfad zum Ziel:

Quelle

2

2

2 3

3

3

64

5

4

7 8

A D Ziel

B

Quelle Ziel

Die Routingentscheidungen im DECnet basieren auf Kosten,eine beliebige Maßeinheit, die von Netzwerk-Administratorenzugewiesen wird und mit der verschiedene Pfade durch einVerbundnetz verglichen werden. Die Kosten hängen unter an-derem von der Etappenzählung und der Medienbandbreite ab.Je geringer die Kosten, desto besser der Pfad. Treten Netzfeh-ler auf, verwendet DRP den Kostenwert, um den besten Pfadzu jedem Ziel neu zu bestimmen.

Bild 26.5:Die DRP fin-det die opti-male Streckedurch einDECnet-Phase-IV-Netzwerk


DECnet/OSI-Routing ist von den standardmäßigen OSI-Rou-tingprotokollen (ISO 8473, ISO 9542 und ISO 10589) undDRP implementiert. Genaue Informationen zu den OSI-Rou-tingprotokollen finden Sie in Kapitel 39, »Open Systems Inter-connection (OSI) Routing Protocol«.

26.6 DECnet-Endkommunikationsschicht

DECnet Phase IV unterstützt ein einziges Transportprotokollin der DNA-Endkommunikationsschicht, das Network-Servi-ces Protocol (NSP).

26.6.1 Network-Services Protocol

Das Network-Services Protocol (NSP) ist ein proprietäres,verbindungsorientiertes Endkommunikationsprotokoll vonDigital, das Verbindungen zwischen Knoten aufbaut und be-endet, Nachrichten fragmentiert und wieder zusammensetztund Fehler behebt.

NSP regelt auch zwei Arten von Ablaufsteuerung: einenStart/Stop-Mechanismus, bei dem der Empfänger dem Sendermitteilt, wann er die Datenübermittlung beenden und wieder-aufnehmen soll, und ein komplexeres Verfahren, bei dem derEmpfänger dem Sender mitteilt, wie viele Nachrichten er an-nehmen kann.

26.7 DECnet/OSI-Transportschicht

DECnet/OSI unterstützt NSP, drei standardmäßige OSI-Trans-portprotokolle und das Transmission Control Protocol (TCP).

DECnet/OSI unterstützt die Transportprotokollklassen (TP) 0,TP2 und TP4. TP0 ist das einfachste verbindungsorientierteOSI-Transportprotokoll. Von den klassischen Funktionen derTransportschicht führt es nur die Segmentierung und dasWiederzusammensetzen durch. Das heißt, daß TP0 diemaximale Größe einer Protocol Data Unit (PDU) feststellt, dievon zugrundeliegenden Subnetzen unterstützt wird, und daszu transportierende Paket in kleinere Einheiten aufteilt, die fürdie Übertragung im Netzwerk nicht zu groß sind. TP2 kann


Datenströme über einen einzigen virtuellen Schaltkreis multi-plexen und demultiplexen. Durch diese Fähigkeit ist TP2 be-sonders geeignet für Public Data Networks (PDNs), wo jedervirtuelle Schaltkreis anderen Belastungen unterliegt. Wie TP0und TP1, segmentiert auch TP2 PDUs und setzt sie wieder zu-sammen, während TP3 die Funktionen von TP1 und TP2kombiniert. TP4, das populärste OSI-Transportprotokoll, istdem TP der Internet-Protokollsuite ähnlich und basiert auchtatsächlich auf diesem Modell. Zusätzlich zu den TP3-Funk-tionen bietet TP4 einen zuverlässigen Transportdienst undgeht von einem Netzwerk aus, in dem Probleme nicht erkanntwerden.

Request For Comments (RFC) 1006 und RFC 1006 Exten-sions definieren eine Implementierung der OSI-Transport-schichtprotokolle auf TCP. RFC 1006 definiert die Implemen-tierung des OSI Transport Protocol Klasse 0 (TP0) auf TCP.RFC 1006 Extensions definiert die Implementierung desTransport Protocol Klasse 2 (TP2) auf TCP.

26.8 Die oberen Schichten von DECnetPhase IV

Die DNA von DECnet Phase IV spezifiziert vier obere Schich-ten, in denen Interaktionsdienste, Netzwerk-Management-funktionen, Datentransfer und Verbindungskontrolle bereitge-stellt werden. Man spricht von Benutzer-, Netzwerk-Manage-ment-, Netzwerk-Anwendungs- und Verbindungskontroll-schicht. Die oberen Schichten der DECnet-Phase-IV-Archi-tektur werden in den folgenden Abschnitten genauer beschrie-ben.

26.8.1 Benutzerschicht

Die DNA-Benutzerschicht unterstützt Benutzerdienste undProgramme, die mit den Anwendungen des Benutzers intera-gieren. Der Endbenutzer arbeitet direkt mit diesen Anwen-dungen, und die Anwendungen benutzen die Dienste und Pro-gramme, die von der Benutzerschicht bereitgestellt werden.


26.8.2 Netzwerk-Managementschicht

Das Netzwerk-Managementprotokoll, das in DECnet-Netz-werken häufig verwendet wird, ist Digitals proprietäres Net-work Information and Control Exchange (NICE)-Protokoll.NICE ist ein Kommando/Antwort-Protokoll. Kommandos, dieeine Handlung verlangen, werden an einen verwalteten Kno-ten oder Prozeß ausgegeben. Antworten, in Form von Hand-lungen, werden von diesen Knoten oder Prozessen geliefert.NICE führt verschiedene Funktionen des Netzwerk-Manage-ments durch und kann dazu benutzt werden, das Betriebs-system eines lokalen Systems in ein Fernsystem umzuwandelnoder es einem unbedienten Fernsystem zu ermöglichen, seinenSpeicherinhalt an das lokale System zu übergeben. Protokolle,die NICE verwenden, können bestimmte Eigenschaften desNetzwerks untersuchen und ändern. NICE unterstützt eineProtokolleinrichtung, die automatisch wichtige Ereignisse imNetzwerk, wie etwa Änderungen der Anordnung oder des Zu-stands von Schaltkreisen, aufspürt. NICE unterstützt Funktio-nen, die das Testen von Hardware und Ringleitungen zwi-schen Knoten erleichtern.

Bestimmte Netzwerkmanagement-Funktionen können auf dasMaintenance Operations Protocol (MOP) zugreifen, einerSammlung von Funktionen, die unabhängig von den DNA-Schichten zwischen Netzwerk-Management- und Sicherungs-schicht arbeiten können. Dies erlaubt den Zugriff auf Knoten,die sich in einem Zustand befinden, in dem nur Dienste derSicherungsschicht erhältlich oder ausführbar sind.

26.8.3 Netzwerk-Anwendungsschicht

Das Data-Access Protocol (DAP), ein proprietäres Protokollvon Digital, wird von DECnet Phase IV in der Netzwerk-Anwendungsschicht verwendet. DAP unterstützt den Fernzu-griff auf Dateien und den Dateitransfer – Dienste also, die vonAnwendungen der Netzwerk-Management- und der Benutzer-schicht beansprucht werden. Andere proprietäre Digital-Pro-tokolle, die auf der Netzwerk-Anwendungsschicht operierensind MAIL, das den Austausch von Mailnachrichten erlaubt,und CTERM, das den Fernzugriff auf Terminals ermöglicht.


26.8.4 Verbindungskontrollschicht

Das Session-Control Protocol (SCP) ist ein Verbindungskon-trollschicht-Protokoll von DECnet Phase IV, das mehrereFunktionen ausübt. SCP fordert vor allem logische Verbin-dungen von Endgeräten an, erhält von Endgeräten Anfragennach logischen Verbindungen, übersetzt Namen in Adressenund beendet logische Verbindungen.

26.9 Die oberen Schichten von DECnet/OSI

Die DECnet/OSI DNA basiert auf dem OSI-Schichtenmodell.DECnet/OSI unterstützt in jeder der oberen Schichten zweiProtokollsuites: die OSI-Protokolle und die DECnet-Phase-IV-Protokolle (um die Abwärtskompatibilität zu gewährleisten).DECnet/OSI unterstützt Funktionalitäten in den Anwendungs-,Darstellungs- und Kommunikationssteuerschichten.

26.9.1 Anwendungsschicht

DECnet/OSI realisiert die standardmäßigen Implementierun-gen der OSI-Anwendungsschichten, so wie standardmäßigeProzesse der Anwendungsschicht wie Common Management-Information Protocol (CMIP) und File Transfer, Access andManagement (FTAM). DECnet/OSI unterstützt ebenso alleProtokolle, die von DECnet Phase IV in der Benutzer- undNetzwerk-Managementschicht der DNA implementiert sind,wie zum Beispiel das Network Information and ControlExchange (NICE)-Protokoll.

Die OSI-Anwendungsschicht enthält sowohl wirkliche An-wendungen als auch Application Service Elements (ASEs).ASEs ermöglichen einfache Kommunikation der Anwendun-gen mit den unteren Schichten. Die drei wichtigsten ASEs sindAssociation Control Service Element (ACSE), Remote Opera-tions Service Element (ROSE) und das Reliable Transfer Ser-vice Element (RTSE). ACSE verbindet Anwendungsnamenmiteinander, damit Anwendungen untereinander kommunizie-ren können. ROSE implementiert einen wählbaren Frage/Ant-wort-Mechanismus, der ähnliche Fernoperationen ermöglichtwie Remote Procedure Calls (RPCs). RTSE hilft bei der kor-


rekten Auslieferung, indem es die Handhabung der Kommuni-kationssteuerschicht vereinfacht.

26.9.2 Darstellungsschicht

DECnet/OSI realisiert alle standardmäßigen OSI-Implementie-rungen der Darstellungsschicht. DECnet/OSI unterstütztebenso alle Protokolle, die DECnet Phase IV in der Netzwerk-Anwendungsschicht der DNA implementiert. Das wichtigstedavon ist das Data-Access Protocol (DAP).

Die OSI-Darstellungsschicht ist gewöhnlich nur ein Durch-gangsprotokoll für Informationen benachbarter Schichten.Obwohl viele Leute glauben, Abstract Syntax Notation 1(ASN.1) sei das OSI-Protokoll der Darstellungsschicht, wirdASN.1 verwendet, um Datenformate in einem maschi-nenunabhängigen Format auszudrücken. Dies ermöglicht dieKommunikation zwischen Anwendungen verschiedener Com-putersysteme auf eine Weise, die für die Anwendungen trans-parent ist.

26.9.3 Verbindungskontrollschicht

DECnet/OSI realisiert alle Implementierungen der standard-mäßigen OSI-Kommunikationssteuerschicht. Ebenso unter-stützt DECnet/OSI alle Protokolle, die von DECnet Phase IVin der Verbindungskontrollschicht der DNA implementiertsind. Das primäre Verbindungskontrollschicht-Protokoll istdas Session-Control Protocol (SCP). Das OSI-Kommunika-tionssteuerschicht-Protokoll verwandelt die Datenströme, dievon den unteren vier Schichten geliefert werden, in Sitzungen,indem es verschiedene Kontrollmechanismen realisiert. Zudiesen Mechanismen gehören Berechnungen, Verbindungskon-trolle und das Aushandeln von Sitzungsparametern. Die Ver-bindungskontrolle wird durch ein Sendezeichen realisiert, daszum Kommunizieren berechtigt. Das Sendezeichen kann ange-fordert werden, und einem ES kann das Vorrecht eingeräumtwerden, das Sendezeichen unterschiedlich zu verwenden.

Bild 26.6 zeigt die vollständigen DECnet-Phase-IV- undDECnet/OSI-Protokollsuiten, der Implementierung vonDECnet/OSI auf TCP.


Darstellung

Anwendung

Kommunikation

Transport

Netzwerk

Sicherung

Bitübertragung

SCP

DRP

NSP

DRP

OSI-Referenzmodell

DECnetPhase IV

DECnet/OSI TCP/IP

DECnet-Anwendungen NICE NICE

OSI-Darstellung

OSI-Netzwerk

OSI-Anwendung

OSI-Kommunikation

TCP

IP

SCP

DECnet/OSINSP

DAP MAIL

CTERM

DAP MAIL

CTERM

TP2

EthernetHardware

DDCMP

Ethernet FDDIFrame Relay

LAPBMOPIEEE

802.2 LLCToken Ring

HDLC

Token RingHardware

FDDIHardware

X.21bis

TPOTP4

DECnet-AnwendungenNICE

Bild 26.6: DECnet Phase IV und DECnet/OSI unterstützen die gleichenSpezifikationen von Sicherungs- und Bitübertragungensschicht

27 IBM Systems Network Architecture (SNA) Protokolle

27.1 Background

IBM-Netzwerke bestehen heute im wesentlichen aus zwei ver-schiedenen Architekturen, die einen mehr oder weniger ge-meinsamen Ursprung haben. Bevor es die gegenwärtigen Netz-werke gab, bestimmte IBMs Systems Network Architecture(SNA) die Netzwerk-Landschaft, so daß man häufig von tradi-tioneller oder ursprünglicher SNA spricht.

Als PCs, Workstations und Client/Server-Architekturen auf-kamen, kam IBM dem Bedarf an einer Peer-to-Peer-Netzwerk-strategie mit der Entwicklung von Advanced Peer-to-PeerNetworking (APPN) und Advanced Program-to-ProgramComputing (APPC) entgegen.

Obwohl viele der ursprünglichen Technologien der auf Groß-rechnern basierenden SNA auf APPN-basierte Netzwerkeübertragen wurden, gibt es große Unterschiede. Dieses Kapitelbeschreibt die unterschiedlichen IBM-Netzwerk-Umgebungen.Zunächst werden die ursprünglichen SNA-Umgebungen auf-gezeigt, später die AAPN erläutert. Das Kapitel schließt mitder Beschreibung der Basic-Information Unit (BIU) und derPath-Information Unit (PIU) von IBM.

IBM-basierte Routingstrategien werden in einem eigenenKapitel behandelt. Einzelheiten über Routingprotokolle vonIBM finden Sie in Kapitel 35, »IBM Systems Network Archi-tecture (SNA) Routing«.

KAPITEL 27IBM Systems Network Architecture (SNA)


27.2 Traditionelle SNA-Umgebungen

SNA wurde in den 70er Jahren mit einer Gesamtstruktur ent-wickelt, die dem OSI-Schichtenmodell ähnelt. In der SNA dientein Großrechner, der mit der Advanced Communication Faci-lity/Virtual Telecommunication Access Method (ACF/VTAM)arbeitet, als Hub eines SNA-Netzwerks. ACF/VTAM baut alleVerbindungen auf und aktiviert oder deaktiviert Ressourcen.In dieser Umgebung sind Ressourcen explizit vordefiniert, sodaß kein Rundspruchverkehr benötigt und der Aufwand anHeadern minimiert wird. Die zugrundeliegende Architekturund die Hauptkomponenten der traditionellen SNA-Vernet-zung werden in den folgenden Abschnitten zusammengefaßt

27.2.1 IBM-SNA-Architektur

Die Bestandteile des IBM-SNA-Modells sind dem OSI-Schich-tenmodell sehr ähnlich. Die folgenden Beschreibungen zeigendie Rolle, die die einzelnen SNA-Komponenten beim Aufbauvon Verbindungen zwischen SNA-Entitäten spielen.

− Datenübermittlungssteuerung (DLC) – Definiert verschie-dene Protokolle, wie etwa das Synchronous Data-LinkControl (SDLC)-Protokoll für die hierarchische Kommuni-kation und das Token Ring Network Communication Pro-tocol für die LAN-Kommunikation zwischen Geräten.

− Pfadsteuerung – Führt viele Funktionen der OSI-Netzwerk-Schicht aus, einschließlich des Routing und der Segmenta-tion And Reassembly (SAR) von Datenpaketen.

− Übertragungssteuerung – Stellt einen zuverlässigen Dienstfür die Kommunikation zwischen Endpunkten bereit undermöglicht das Chiffrieren und Dechiffrieren.

− Datenflußsteuerung – Regelt Anfrage/Antwort-Prozesse,entscheidet, wer kommunizieren darf, faßt Nachrichten zu-sammen und unterbricht auf Anforderung den Datenfluß.

− Darstellungsdienste – Spezifiziert Algorithmen der Daten-umwandlung, die Daten von einem Format in ein anderesübersetzen, koordiniert die gemeinsame Verwendung vonRessourcen und synchronisiert Arbeitsvorgänge.

Kapitel 27 • IBM Systems Network Architecture (SNA) Protokolle 357

− Transaktionsdienste – Stellt Anwendungsdienste in Formvon Programmen bereit, die verteilte Prozeß- oder Mana-gementdienste realisieren.

SNA definiert für die Physikalische Schnittstelle keine spe-zifischen Protokolle. Es wird erwartet, daß die PhysikalischeSchnittstelle über andere Standards realisiert wird.

Bild 27.1 zeigt, wie diese Elemente von IBMs SNA-Modell mitdem ISO/OSI-Netzwerkmodell zusammenhängen.

OSI

Netzwerk

Anwendung

Darsellung

Kommunikation

Transport

PhysicalPhysikalisch

Datensicherung

SNA

Transaktionsdienste

Darstellungsdienste

Datenflußsteuerung

Übertragungssteuerung

Physikalisch

Datenübermittlungssteuerung

Pfadsteuerung

Eine Haupteinrichtung, die im SNA-Netzwerk-Modelldefiniert wird, ist das Path-Control Network, das Informatio-nen zwischen SNA-Knoten bewegen und die Kommunikationim Verbundnetz zwischen Knoten in verschiedenen Netzwer-ken erleichtern soll. Die Umgebung des Path-Control Networkverwendet Funktionen, die von der Wege- und Datenübermitt-lungsteuerung bereitgestellt werden. Das Path-Control Net-work ist eine Untereinheit von IBMs Transportnetzwerk.

27.2.2 Physische Entitäten von IBM SNA

Traditionelle physische Entitäten der SNA haben eine der vierfolgenden Formen: Hosts, Kommunikationssteuereinheiten,Aufbausteuereinheiten und Terminals. Die Hosts der SNA

Bild 27.1:IBM-SNA ent-spricht den sie-ben Stufen desOSI-Modells


kontrollieren das gesamte oder einen Teil des Netzwerks, füh-ren Berechnungen und Programme aus, ermöglichen den Da-tenbankzugriff und das Netzwerk-Management und stellenVerzeichnisdienste bereit. (Ein Beispiel für einen Host in einertraditionellen SNA-Umgebung ist ein S/370-Großrechner.) DieKommunikationssteuereinheiten verwalten das physischeNetzwerk und überwachen die Kommunikationsverbindun-gen. Insbesondere sollen die Kommunikationssteuereinheiten –auch Front-End Processors (FEPs) genannt – Daten durch eintraditionelles SNA-Netzwerk routen. (Ein Beispiel für eineKommunikationssteuereinheit ist ein 3745.) Aufbausteuerein-heiten werden gewöhnlich Clustercontroller genannt. DieseGeräte kontrollieren Input- und Output-Operationen ange-schlossener Geräte wie etwa Terminals. (Ein Beispiel für eineAufbausteuereinheit ist ein 3174.) Terminals, auch Work-stations genannt, stellen die Benutzerschnittstelle des Netz-werks dar. (Ein typisches Beispiel ist ein 3270). Abbil-dung 27.2 zeigt all diese physischen Entitäten eingebunden inein SNA-Netzwerk-Diagramm.

Mainframe-Kanal

Token Ring

SDLC

X.25

27.2.3 Datenübermittlungssteuerung von IBM SNA

Die SNA-Datenübermittlungssteuerungschicht unterstützt di-verse Medien, von denen jedes darauf ausgelegt ist, Zugriffauf Geräte und Benutzer mit unterschiedlichen Anforderungenbereitzustellen. Zu den von SNA unterstützten Medienarten

Bild 27.2:Physische Enti-täten der SNA

können vierFormen haben


gehören unter anderem Großrechnerkanäle, SDLC, X.25 undToken Ring.

Ein standardmäßiger SNA-Großrechnerkanal bietet einen par-allelen Datenkanal, der die Datenübertragungstechnik Direct-Memory-Access (DMA) verwendet. Ein Großrechnerkanalverbindet IBM-Hosts miteinander und über mehradrige Kabelmit Kommunikationscontrollern. Jedes Kabel kann dabei biszu mehreren 100 Metern lang sein. Ein standardmäßigerGroßrechnerkanal kann Daten mit Geschwindigkeiten zwi-schen 3 und 4,5 Mbyte/s übertragen.

IBMs Enterprise-Systems-Connection-Großrechnerumgebung(ESCON) erlaubt höhere Datendurchsätze und kann größerephysische Entfernungen überbrücken. Im allgemeinen über-mittelt ESCON Daten mit 18 Mbyte/s und unterstützt Stand-leitungen und Übermittlungen über mehrere Kilometer. Umhöhere Datenraten und größere Entfernungen zu ermöglichen,verwendet ESCON Lichtwellenleiter als Netzwerk-Medium.

SDLC wird häufig in SNA-Netzen angewandt, um Kommuni-kations- und Verbindungsaufbaucontroller zu verbinden undum Daten über Telefonleitungen zu versenden.

X.25-Netze wurden lange Zeit für WAN-Verbindungen im-plementiert. Im allgemeinen liegt ein X.25-Netz zwischen zweiSNA-Knoten und wird wie eine einzelne Leitung behandelt.SNA implementiert X.25 als Zugriffsprotokoll, und SNA-Knoten werden im X.25-Netz als benachbart betrachtet. UmSNA-Knoten über ein X.25-basiertes WAN zu verbinden, be-nötigt SNA die Funktionen des DLC-Protokolls, die X.25nicht bietet. Um die Lücke zu schließen, werden verschiedenespezielle DLC-Protokolle eingefügt, wie etwa der PhysicalServices Header, Qualified Logical Link Control (QLLC) undEnhanced Logical Link Control (ELLC).

Token-Ring-Netze sind die primäre SNA-DLC-Methode, umden Medienzugriff auf LAN-basierte Geräte zu gewähren. To-ken Ring, wie es von IBM unterstützt wird, ist praktisch iden-tisch mit dem IEEE-802.5-Verbindungszugriffs-Protokoll, dasunter IEEE 802.2 Logical Link Control Type 2 (LLC2) läuft.


Zusätzlich zu der Basisreihe von Medientypen fügte IBM dieUnterstützung für diverse andere weit verbreitete Medienhinzu, wie zum Beispiel IEEE 802.3/Ethernet, Fiber-Distribu-ted Data Interface (FDDI) und Frame Relay.

Abbildung 27.3 zeigt, wie die verschiedenen Medien im allge-meinen in ein SNA-Netz eingebunden sind.

Mainframe-Kanal

Token Ring

SDLC

X.25

27.2.4 IBM Network-Addressable Units (NAUs)

SNA definiert drei grundlegende Network-Addressable Units(NAUs): Logical Units, Physical Units und Control Points.Jede spielt eine wichtige Rolle beim Aufbau von Verbindungenzwischen Systemen in einem SNA-Netzwerk.

Logical Units (LUs) fungieren als Anbindungen für den End-benutzer in ein SNA-Netz. LUs stellen Benutzern den Zugriffauf Netzressourcen bereit und verwalten die Übermittlungenvon Informationen zwischen Endbenutzern.

Physical Units (PUs) überwachen und kontrollieren ange-schlossene Netzwerk-Verbindungen und andere Netzressour-cen, die mit einem bestimmten Knoten verbunden sind. PUswerden in Hosts mit SNA-Zugriffsmethoden implementiert,wie etwa der Virtual Telecommunication Access Method(VTAM). Auch werden PUs von Network Control Programs(NCPs) in Kommunikationscontroller implementiert.

Bild 27.3:SNA unter-

stützt mittler-weile eine

Vielzahl vonMedien


Control Points (CPs) verwalten SNA-Knoten und deren Res-sourcen. CPs unterscheiden sich gewöhnlich dadurch von PUs,daß sie entscheiden, welche Handlung durchgeführt werdenmuß, während PUs Handlungen bewirken. Ein Beispiel für einCP ist der System Services Control Point (SSCP) der SNA. EinSSCP kann der CP sein, der im PU-5-Knoten liegt, oder einSSCP, wie er unter einer SNA-Zugriffsmethode wie VTAMimplementiert ist.

27.2.5 IBM SNA-Knoten

Traditionelle SNA-Knoten gehören einer von zwei Kategorienan: Subareaknoten oder Peripherieknoten. SNA-Subareakno-ten bieten alle Netzwerk-Dienste, einschließlich Knotenroutingund das Zuordnen von lokalen und netzwerkweiten Adressen.Es besteht keine Beziehung zwischen SNA-Knotentypen undtatsächlichen physischen Geräten. Zwei Subareaknoten sindvon besonderem Interesse: Knotentyp 4 und Knotentyp 5.

Knotentyp 4 (T4) liegt normalerweise in einem Kommunika-tionscontroller, etwa einem 3745. Ein Beispiel für einen T4-Knoten ist ein NCP, der Daten routet und den Fluß zwischeneinem Front-End-Prozessor und anderen Netzressourcen kon-trolliert.

Knotentyp 5 (T5) liegt gewöhnlich in einem Host, etwa einemS/370-Großrechner. Ein Beispiel für einen T5-Knoten ist dieVTAM, die sich in einem IBM-Großrechner befindet. EineVTAM kontrolliert den logischen Datenfluß durch das Netz-werk, stellt die Schnittstelle zwischen Anwendungssystemenund einem Netzwerk zur Verfügung und schützt die Anwen-dungssysteme vor nicht autorisiertem Zugriff.

SNA-Peripherieknoten verwenden nur lokale Adressierungenund kommunizieren über Subareaknoten mit anderen Knoten.Knotentyp 2 (T2) ist gewöhnlich der interessanteste Periphe-rieknoten, obwohl SNA auch einen Peripherieknoten vomKnotentyp 1 spezifiziert. T2 liegt im allgemeinen in intelligen-ten Terminals (wie einem 3270) oder in Verbindungsauf-baucontrollern (wie einem 3174). Knotentyp 1 (T1) ist heuteveraltet, aber wenn er implementiert ist, liegt er in nicht intel-ligenten Terminals. Abbildung 27.4 zeigt die verschiedenenSNA-Knoten und ihre Beziehungen zueinander.


Hosts (PU-Typ-5-Knoten)

Terminals (PU-Typ-2- und -Typ-1-Knoten)

Kommunikations-steuereinheiten

(PU-Typ-4-Knoten)

Aufbau-steuereinheiten

(PU-Typ-2-Knoten)

Subarea-Knoten

Peripherie-knoten

27.3 IBM Peer-to-Peer-Netzwerke

Wechselnde Anforderungen an Netzwerke und an die Kom-munikation veranlaßten IBM, viele der Grundeigenschaftender SNA zu überprüfen und weiterzuentwickeln. Das Auf-kommen von neuen Einheiten (wie etwa Router) für Peer-to-Peer-Netzwerke bewirkte eine Reihe von weitreichenden Ver-änderungen der SNA. Der Betrieb von Netzwerken mit gleich-rangigen Geräten hängt innerhalb der SNA von verschiedenenNetzwerk-Komponenten ab, die von IBM entwickelt wurden.

Advanced Peer-to-Peer Networking (APPN) ist die zweite Ge-neration von IBMs SNA. Mit der Entwicklung von APPNwandelte IBM die SNA von einer hierarchischen, großrechner-zentrierten Umgebung in eine Netzwerk-Umgebung um, dieauf gleichrangigen Geräten beruht. Herzstück der APPN isteine IBM-Architektur, die die Kommunikation zwischengleichrangigen Geräten, Verzeichnisdienste und das Routingzwischen zwei oder mehr APPC-Systemen, die nicht direktverbunden sind, unterstützt.

27.3.1 APPN-Komponenten

Außer der APPN-Umgebung spezifiziert diese Art der SNAdrei zusätzliche wichtige Netzwerk-Konzepte: Logical Units(LUs), Advanced Program-to-Program Computing (APPC)und den Knotentyp 2.1. Jedes spielt eine bedeutende Rolle

Bild 27.4:Peripherie-

knoten kom-munizieren

über Subarea-Knoten mit

anderenKnoten


beim Kommunikationsaufbau zwischen SNA-Geräten inner-halb eines SNA-basierten Verbundnetzes, das aus gleichrangi-gen Geräten besteht.

Logical Unit (LU) 6.2 regelt die Kommunikation zwischengleichrangigen Geräten in einer SNA-Umgebung. Außerdemunterstützt LU 6.2 die allgemeine Kommunikation zwischenProgrammen in einer verteilten Verarbeitungsumgebung undzwischen ähnlichen und unähnlichen Knotentypen. APPC ver-setzt SNA-Anwendungen in die Lage, direkt mit SNA-Anwen-dungen gleichrangiger Geräte zu kommunizieren, und es stellteine Reihe von Programmiervereinbarungen und -protokollenzur Verfügung, die LU 6.2 implementieren. Knoten vom Typ2.1 (T2.1) sind logische Entitäten, die die direkte Kommuni-kation zwischen Peripherieknoten, die T2.1 unterstützen, er-möglichen. Die T2.1-Entität erleichtert die Kommunikationüber Punkt-zu-Punkt-Verbindungen, weil sie den Datentrans-port zwischen gleichrangigen Geräten unterstützt, der in derAPPC vorgesehen ist. Außerdem enthält ein T2.1 einen Peri-pheral Node Control Point (PNCP), der die traditionellenFunktionen von Physical Unit (PU) und Control Point (CP)verbindet.

27.3.2 Knotenarten von IBM APPN

Unter APPN findet die Kommunikation zwischen gleichrangi-gen Geräten über verschiedene exakt definierte Knotentypenstatt. Diese Knoten kann man in drei Grundtypen einteilen:Low-Entry Nodes (LENs), End Nodes (ENs) und NetworkNodes (NNs).

Der Low-Entry-Network-Knoten (LEN) ist ein Peer-to-Peer-Knoten aus der Zeit vor APPN. Ein LEN-Knoten nimmt in ei-nem APPN-Netz die Dienste eines benachbarten NetworkNode (NN) in Anspruch. Der CP des LEN-Knotens verwaltetlokale Ressourcen, baut mit dem benachbarten Knoten aberkeine CP-zu-CP-Sitzung auf. Bevor eine Sitzung aufgebautwerden kann, müssen die Sitzungspartner für den LEN-Kno-ten definiert werden, und der LEN-Knoten muß für den be-nachbarten NN, der ihm Dienste zur Verfügung stellt, defi-niert werden.


Ein End Node (EN) enthält einen Teil der vollen APPN-Unter-stützung. Ein End Node greift über einen benachbarten NNauf das Netz zu und benutzt die Routingdienste desselben be-nachbarten NN. Um im Netzwerk zu kommunizieren, bautein EN eine CP-zu-CP-Sitzung mit einem benachbarten NNauf und benutzt diese Sitzung, um Ressourcen zu registrieren,Verzeichnisdienste und Routinginformationen anzufordern.Ein Network Node (NN) enthält die vollständige APPN-Funktionalität. Der CP in einem NN verwaltet die Ressourcendes NN wie auch der angeschlossenen ENs und LENs. Außer-dem baut der CP in einem NN CP-zu-CP-Sitzungen mit be-nachbarten ENs und NNs auf und pflegt die Netzwerk-Topo-logie und die Verzeichnisdatenbanken, die erstellt und aktua-lisiert werden, indem Informationen benachbarter NNs undENs dynamisch gesammelt werden.

Abbildung 27.5 zeigt, wo diese Gerätetypen in einer APPN-Umgebung liegen könnten.

APPN-Netzwerk

End-knoten

End-knoten

Low-Entry-Netzwerk

Netzwerk-knoten

27.3.3 IBM APPN-Dienste

Die grundlegenden APPN-Dienste lassen sich in vier Gruppeneinteilen: Konfiguration, Verzeichnis, Topologie und Routing-und Verbindungsdienste. Jeder wird in den folgenden Ab-schnitten beschrieben.

Bild 27.5:APPN unter-

stützt verschie-dene genau

definierteKnotenarten


Die Konfigurationsdienste von IBM APPN

Die Konfigurationsdienste der APPN sind dafür zuständig,Verbindungen zum APPN-Netzwerk zu aktivieren. Zur Akti-vierung der Verbindung gehören der Aufbau einer Verbin-dung, der Aufbau einer Sitzung und die Auswahl einer An-grenzungsoption.

Die Anschlußphase einer Verbindungsaktivierung ermöglichtden erstmaligen Aufbau einer Kommunikation zwischen Kno-ten. Diese erstmalige Kommunikation beinhaltet den Aus-tausch von Charakteristika und das Aufbauen von Rollen, wieetwa primär im Gegensatz zu sekundär. Der Verbindungsauf-bau wird durch die Übermittlung von Exchange IdentificationTyp-3-Frames (XID3) zwischen Knoten erreicht.

Während des Sitzungsaufbaus werden CP-zu-CP-Sitzungenmit Hilfe eines benachbarten EN oder NN eingeleitet. JederKnoten muß mindestens ein Paar einer CP-zu-CP-Sitzung miteinem benachbarten Knoten aufbauen. Ein EN kann höch-stens ein Paar einer CP-zu-CP-Sitzung aufbauen, kann abermit mehr als einem NN verbunden werden. Zwischen NNskönnen Paare von CP-zu-CP-Sitzungen mit allen benachbartenKnoten oder einer Untermenge benachbarter Knoten aufge-baut werden. Die Mindestanforderung ist ein einzelnes Sit-zungspaar zu einem benachbarten Knoten, der eine korrekteAktualisierung der Topologie sichert.

Ob Knoten innerhalb der APPN benachbart sind, wird mitHilfe einer CP-zu-CP-Sitzung entschieden. Es gibt zwei konfi-gurierbare Optionen, mit denen entschieden wird, ob Knotenbenachbart sind. Ein Knoten kann als benachbart mit einemeinzelnen Knoten spezifiziert werden oder als logisch benach-bart mit jedem möglichen benachbarten Knoten. Welche An-grenzungsoption für eine bestimmte Situation ausgewähltwird, hängt von den gegebenen Verbindungsanforderungendes Netzwerks ab. Die Reduzierung von CP-zu-CP-Sitzungen,die einzelne benachbarte Knoten nach sich ziehen, kann denNetzwerk-Overhead, der durch Aktualisierungen der Topo-logie zustande kommt, wie auch die Anzahl der Puffer, diebenötigt werden, um diese Aktualisierungen zu verteilen, redu-zieren. Andererseits wird, wenn man die Anzahl benachbarterKnoten reduziert, mehr Zeit benötigt, um Router zu synchro-nisieren.


Die Verzeichnisdienste von IBM APPN

Verzeichnisdienste sollen Netzwerk-Geräten helfen, Dienstan-bieter ausfindig zu machen. Sie sind zwingend nötig, umSitzungen zwischen Endbenutzern aufzubauen. Die Ver-zeichnisdienste der APPN fordern jeden NN auf, ein Verzeich-nis der lokalen Ressourcen sowie ein Netzwerk-Verzeichnis zuführen, das Endbenutzer mit den NNs verbindet, die Dienstezur Verfügung stellen. Dann wird aus der Gesamtheit derindividuellen Netzwerk-Verzeichnisse der NNs ein verteilterVerzeichnisdienst zusammengestellt. Dieser Abschnitt erläutertdie APPN-Datenbanken, die Verwaltung der Knotenverzeich-nisdienste und die Rolle eines zentralen Verzeichnisdienstes.

Die lokalen und Netzwerk-Verzeichnis-Datenbanken unter-stützen drei Arten von Diensteinträgen: konfigurierte Ein-träge, registrierte Einträge und versteckte Einträge. Konfigu-rierte Datenbankeinträge sind gewöhnlich lokale Netzwerk-Knoten mit niedrigen Einträgen, die konfiguriert werden müs-sen, weil keine CP-zu-CP-Sitzung, über die Informationen aus-getauscht werden, aufgebaut werden kann. Andere Knotenkönnen konfiguriert werden, um den Rundspruchverkehr, derbeim Erkennungsprozeß entsteht, zu reduzieren. RegistrierteEinträge sind lokale Ressourceneinträge, über die ein End-knoten seinen entsprechenden Netzwerkknoten-Server infor-miert, wenn CP-zu-CP-Sitzungen aufgebaut werden. Ein NNfügt einen registrierten Eintrag in sein lokales Verzeichnis ein.Versteckte Datenbankeinträge sind Verzeichniseinträge, die alsSitzungsanforderungen gebildet und von einem NN empfan-gen werden. Der Benutzer kann die Gesamtzahl erlaubter ver-steckter Einträge vorgeben und somit die Speicheranforderun-gen regulieren.

Die Abwicklung des Endknoten-Verzeichnisdienstes umfaßtmehrere Schritte. Ein EN sendet zunächst eine LOCATE-An-forderung an den NN, der den Netzwerk-Dienst bereitstellt.Als nächstes werden die lokalen und Netzwerk-Verzeichnis-Datenbanken durchsucht, um festzustellen, ob der empfangen-de Endbenutzer bereits bekannt ist. Ist der empfangende End-benutzer bekannt, wird eine einzelne LOCATE-Anforderungverschickt, um sicherzustellen, daß er gegenwärtig erreichbarist. Wird der empfangende Endbenutzer in den existierendenDatenbanken nicht gefunden, sendet der NN eine LOCATE-


Anforderung an benachbarte ENs, um festzustellen, ob es sichbei dem empfangenden Endbenutzer um eine lokale Ressourcehandelt. Handelt es sich nicht um ein lokales Ziel, sendet derNN eine Rundspruch-LOCATE-Anforderung an alle benach-barten NNs zur Verbreitung über das Netzwerk. Wenn derNN, der Netzwerk-Dienste für den empfangenden Endbenut-zer bereitstellt, die Ressource des Endbenutzers lokalisiert,wird eine Nachricht, die anzeigt, daß das Ziel gefundenwurde, an den Ausgangs-NN zurückgeschickt. Zum Schlußcachen Ausgangs- und Empfangs-NN die Information.

Verzeichnisdienste für LEN-Knoten werden von einem Proxy-dienstprozeß durchgeführt. Zuerst sendet ein LEN-Knoteneine Verbindungssitzung-Anforderung (BIND) für angeschlos-sene Ressourcen. Diese unterscheidet sich von den LOCATE-Anforderungen, die von ENs gesendet werden. Um einen Ver-zeichnisdienst zu erhalten, muß ein NN einen Proxydienst füreinen LEN-Knoten leisten. Wenn ein Proxydienst-NN miteinem LEN-Knoten verbunden wird, sendet der NN eineRundspruch-LOCATE-Anforderung, die der LEN-Knoten be-nötigt.

Bei ACF/VTAM gibt es gewöhnlich einen zentralen Verzeich-nisdienst, der helfen soll, LOCATE-Rundsprüche zu reduzie-ren. Diese Art von Datenbank kann als zentrales Verzeichnisfür ein gesamtes Netzwerk dienen, da sie konfigurierte, regi-strierte und versteckte Einträge enthält. Bei einem zentralenVerzeichnisdienst sendet ein NN einen LOCATE-Rundspruchan den zentralen Verzeichnisserver, der dann die zentrale Da-tenbank durchsucht und bei Bedarf einen Rundspruch sendet.

Topologie- und Routingdienste von IBM APPN

In einer APPN-Netzwerk-Topologie, werden Netzwerk-Kno-ten über Transmission Groups (TGs) verbunden. Jede TG be-steht aus einer einzigen Verbindung, und alle NNs unterhalteneine Netzwerk-Topologie-Datenbank, in der alle NNs undTGs des Netzwerks verzeichnet sind. Transmission Groupswerden in Kapitel 35, »IBM Systems Network Architecture(SNA) Routing« behandelt.

Die Topologiedatenbank eines Netzwerks wird mit den Infor-mationen, die sie vom Topology-Database Update (TDU) er-hält, aktualisiert. Die Nachrichten des TDU fließen bei CP-zu-


CP-Sitzungen immer dann, wenn Änderungen im Netzwerkauftreten, wenn etwa ein Knoten oder eine Verbindung aktivoder inaktiv werden, wenn Überlastungen auftreten, oderwenn Ressourcen begrenzt sind.

Die Netzwerk-Topologie-Datenbank enthält Informationen,die zum Errechnen von Routen mit einer bestimmten Class ofService (COS) verwendet werden. Diese Informationen bein-halten Vernetzung und Zustand von NNs und TGs und NN-und TG-Eigenschaften, wie etwa die Kapazität von TGs.

Der APPN-Routingdienst verwendet Informationen aus Ver-zeichnis- und Topologiedatenbanken, um eine auf COS basie-rende Route festzulegen. Die Entscheidung über die Routebeginnt, wenn ein Endknoten zum ersten Mal eine Sitzungsan-forderung von einer logischen Einheit erhält. Eine LOCATE-Anforderung wird von dem EN an seinen NN geschickt, umZielinformationen einzuholen und eine Route durch dasNetzwerk zu erhalten. Der NN legt dann die Eigenschaftenfest, die mit der angeforderten Dienststufe einhergehen. Diefestgelegten Eigenschaften werden dann mit den Eigenschafteneiner jeden TG und eines jeden NN im Netzwerk verglichen,und alle Routen, die die spezifizierten Kriterien erfüllen, wer-den als geeignet versteckt. Jeder EN, NN und TG im Ver-bundnetz wird eine Wertigkeit zugewiesen, die auf COS-Eigen-schaften wie Kapazität, Kosten, Sicherheit und Verzögerungbasiert. Diese Eigenschaften können auch benutzerdefiniertsein. Schließlich wird ein Pfad mit geringen Kosten aus-gewählt, indem die Wertigkeiten summiert werden, die dieRoutingkriterien erfüllen.

Sitzungsdienste von IBM APPN

Auf die Routenerstellung folgt der APPN-Sitzungsaufbau, derje nach Knotentyp anders abläuft. Ist der Endbenutzer, vondem die Verbindung ausgeht, an einen EN angeschlossen,schickt der mit dem Ziel-EN benachbarte NN eine LOCATE-Antwort, die die Ortsbestimmung des Ziels und die Routeenthält, an den Quell-EN zurück. Der Quell-EN schickt einBIND an eine Sitzungsroute. Wenn die Verbindung von demEndbenutzer ausgeht, ist er mit einem LEN-Knoten verbun-den, der ein BIND an seinen benachbarten NN schickt. Der


benachbarte NN wandelt den LEN-BIND in ein APPN-BINDund schickt ein BIND an den Sitzungspfad.

Ein BIND ist ein spezifischer Typ von Anforderungsnach-richt, die eine LU einer anderen LU sendet. Ein BIND ent-hält die Route, die für eine Sitzung verwendet wird. Es spezi-fiziert NNs und TGs, einen einzelnen Sitzungsidentifier fürjede TG, die Übermittlungspriorität für die Sitzung und Fen-sterinformationen, die lernfähige Stufensteuerung unter-stützen, um den Verkehr im Netzwerk zu begrenzen.

27.4 Das Format der Basic Information Unit(BIU)

IBM-SNA-NAUs benutzen Basic Information Units (BIUs), umAnforderungen und Antworten auszutauschen. Abbil-dung 27.6 zeigt das Format der BIU.

Größe in Byte

3 Variabel

AnforderungseinheitAnforderungsheader

Größe in Byte

3 1 bis 7

AntworteinheitAntwortheader

27.4.1 Die Felder der BIU

Die folgenden Beschreibungen der Felder fassen den Inhalt derBIU, wie in Abbildung 27.6 gezeigt, zusammen:

− Anforderungsheader – Kennzeichnet den Datentyp in derentsprechenden Anforderungseinheit. Dieser Header ent-hält Informationen über das Datenformat und spezifiziert

Bild 27.6:Eine Basic In-formation Unit(BIU) kanneine Anforde-rung oder eineAntwort sein


das Protokoll für die Sitzung. Informationen von Anforde-rungsheadern benutzen nur NAUs.

− Anforderungseinheit – Enthält entweder Daten des Endbe-nutzers oder SNA-Kommandos. Daten von Endbenutzernwerden in Datenanforderungseinheiten versendet. SNA-Kommandos werden in Kommandoanforderungseinheitenversendet, die das Netzwerk kontrollieren und Informatio-nen enthalten, die unter Endbenutzern ausgetauscht wer-den.

− Antwortheader – Kennzeichnet den Datentyp der entspre-chenden Antworteinheit. Das Anforderung/Antwort-Indi-katorbit unterscheidet einen Antwortheader von einem An-forderungsheader. Eine empfangende NAU zeigt an, ob dieAntwort, die zum Sender der Anforderung zurückgeschicktwird, positiv oder negativ ist, wozu sie das Response-TypeIndicator-Bit (RTI) in den Antwortheader setzt.

− Antworteinheit – Enthält Informationen über die Anforde-rung und zeigt entweder eine positive oder eine negativeAntwort an. Positive Antworten auf Kommandoanforde-rungen enthalten gewöhnlich eine 1 bis 3 Byte große Ant-worteinheit, die die Kommandoanforderung identifiziert.Positive Antworten auf Datenanforderungen enthaltenAntwortheader, aber keine Antworteinheit

Negative Antworteinheiten sind zwischen 4 und 7 Bytelang und werden immer mit negativer Antwort zurückge-schickt. Eine empfangende NAU schickt eine negative Ant-wort immer an die anfordernde NAU zurück, wenn einedieser drei Bedingungen gegeben ist:

− Der Sender verletzt das SNA-Protokoll

− Der Empfänger versteht die Übermittlung nicht

− Etwas Unvorhergesehenes, zum Beispiel ein Pfadfehler,tritt ein

Wird eine negative Antwort übermittelt, enthalten dieersten vier Byte einer Antworteinheit Daten, die erklären,warum die Anforderung inakzeptabel ist. Die empfangendeNAU sendet bis zu drei zusätzliche Bytes, die die abge-lehnte Anforderung identifizieren.


27.5 Das Format der Path Information Unit(PIU)

Die Path Information Unit (PIU) ist eine SNA-Nachrichten-einheit, die von Pfadkontrollelementen gebildet wird, indemeiner BIU ein Übermittlungsheader hinzugefügt wird. Abbil-dung 27.7 zeigt das Format der PIU.

Größe in Byte

3 Variabel

AnforderungseinheitAnforderungsheader

Größe in Byte

3

Variabel

Variabel 1 bis 7

AntworteinheitAntwortheader

Übermittlungs-header

Übermittlungs-header

27.5.1 Die Felder der PIU

Die folgenden Felderbeschreibungen fassen den Inhalt der PIU,wie in Abbildung 27.7 gezeigt, zusammen:

− Übermittlungsheader – Routet Nachrichteneinheiten durchdas Netzwerk. Dieser Header enthält Routinginformatio-nen für die traditionelle SNA-Subareavernetzung. Formateder Übermittlungsheader werden durch den Typ der For-mat Identification (FID) unterschieden. Die Pfadkontrolleverwendet die FID-Typen, um Daten über SNA-Knoten zurouten.

Drei FID-Typen sind in PIUs implementiert:

− FID0 routet Daten zwischen benachbarten Subareakno-ten für nicht-SNA-Geräte. FID0 wurde durch den FID4-Bitsatz abgelöst, der anzeigt, ob es sich um ein SNA-Gerät handelt oder nicht.

− FID1 routet Daten zwischen benachbarten Subareakno-ten, wenn einer oder beide Knoten explizite oder virtu-elle Routingprotokolle nicht unterstützen.

Bild 27.7:Die Anforde-rungen undAntworten derPath Informa-tion Unit (PIU)bestehen aus jedrei Feldern


− FID2 routet Daten zwischen Subarea-Grenzknoten undeinem benachbarten Peripherieknoten oder zwischen be-nachbarten Knoten vom Typ 2.1.

Im allgemeinen wird der Übermittlungsheader verwendet,um Daten zwischen benachbarten Subareaknoten zu rou-ten, wenn beide Subareaknoten explizite und virtuelleRoutingprotokolle unterstützen.

− Anforderungsheader – Kennzeichnet den Datentyp in denentsprechenden Anforderungseinheiten. Dieser Header lie-fert Informationen über das Datenformat und spezifiziertdas Sitzungsprotokoll. Informationen aus dem Anforde-rungsheader verwenden nur NAUs.

− Anforderungseinheit – Enthält entweder Daten der Endbe-nutzer oder SNA-Kommandos. Daten der Endbenutzerwerden in Datenanforderungseinheiten versendet. SNA-Kommandos werden in Kommandoanforderungseinheitenversendet, die das Netzwerk kontrollieren und Informatio-nen enthalten, die zwischen Endbenutzern ausgetauschtwerden.

− Antwortheader – Kennzeichnet den Datentyp der entspre-chenden Antworteinheit. Das Anforderung/Antwort-Indi-katorbit unterscheidet einen Anforderungsheader von ei-nem Antwortheader. Eine empfangende NAU zeigt an, obdie Antwort, die zum Anforderungssender zurückgeschicktwird, positiv oder negativ ist, indem sie das RTI-Bit in denAntwortheader setzt.

− Antworteinheit – Enthält Informationen über die Anforde-rung und zeigt entweder eine positive oder negative Ant-wort an. Positive Anworten auf Kommandoanforderungenenthalten gewöhnlich eine 1 bis 3 Byte lange Antwortein-heit, die die Kommandoanforderung identifiziert. PositiveAntworten auf Datenanforderungen enthalten Antwort-header, aber keine Antworteinheit.

Negative Antworteinheiten sind 4 bis 7 Byte lang und wer-den immer mit negativer Antwort zurückgeschickt. Eineempfangende NAU schickt eine negative Antwort an dieanfordernde NAU zurück, wenn eine von drei Bedingungengegeben ist: Der Sender verletzt das SNA-Protokoll, ein


Empfänger versteht die Übermittlung nicht, oder etwasUnvorhergesehenes, ein Pfadfehler etwa, tritt ein.

Wird eine negative Antwort übermittelt, enthalten dieersten 4 Byte einer Antworteinheit Daten, die erklären,warum die Anforderung inakzeptabel ist. Die empfangendeNAU sendet bis zu 3 zusätzliche Bytes, die die abgelehnteAnforderung identifizieren.

28 Internet-Protokolle

28.1 Background

Die Internet-Protokolle sind die populärsten offenen (nichtproprietären) Protokollsuiten, da man mit ihnen über jeglicheArt von verbundenen Netzwerken kommunizieren kann undsie sich somit gleichermaßen für LAN- und WAN-Kommuni-kation eignen. Die Internet-Protokolle bestehen aus einerReihe von Kommunikationsprotokollen, von denen die beidenbekanntesten das Transmission Control Protocol (TCP) unddas Internet Protocol (IP) sind. Die Internet-Protokollsuiteenthält nicht nur Protokolle der unteren Schichten (wie TCPund IP), sondern sie spezifiziert auch gängige Anwendungen wieE-Mail, Terminalemulation und Dateiübertragung. DiesesKapitel bietet eine detaillierte Einführung in die Spezifikatio-nen, aus denen sich die Internet-Protokolle zusammensetzen.Es werden die IP-Adressierungen und die wichtigsten Proto-kolle der oberen Schichten besprochen, die das Internet ver-wendet. Die spezifischen Routingprotokolle werden im 6. Teil»Routingprotokolle« gesondert geschildert.

Internet-Protokolle wurden erstmalig Mitte der 70er Jahreentwickelt, als bei der Defense Advanced Research ProjectsAgency (DARPA) das Interesse an einem Paketvermittlungs-netz aufkam, das die Kommunikation zwischen unterschiedli-chen Computersystemen an Forschungseinrichtungen erleich-tern würde. Mit dem Ziel von heterogenen Verbindungen ver-anlaßte die DARPA die Forschung an der Stanford Universityund bei Bolt, Beranek und Newman (BBN). Ergebnis dieser

KAPITEL 28Internet-Protokolle


Bemühungen war die Internet-Protokollsuite, die in den späten70ern fertiggestellt wurde.

Später wurde TCP/IP Berkeley Software Distribution (BSD)-UNIX beigefügt. Es wurde schließlich die Grundlage, auf derdas Internet und das World Wide Web (WWW) basieren.

Die Dokumentation der Internet-Protokolle (einschließlichneuer oder überarbeiteter Protokolle) und ihre Grundsätzesind in technischen Berichten spezifiziert, die Request ForComments (RFCs) heißen. Sie werden publiziert und von derInternet-Gemeinde diskutiert und analysiert. Verbesserungender Protokolle werden in den neuen RFCs veröffentlicht. Umden Anwendungsbereich der Internet-Protokolle zu veran-schaulichen, stellt Bild 28.1 einige Protokolle aus der Internet-Protokollsuite ihren Entsprechungen der OSI-Schichten ge-genüber. Dieses Kapitel befaßt sich mit den grundlegendenElementen und Operationen dieser und anderer wichtigerInternet-Protokolle.

Darstellung

Anwendung

Netzwerk

Transport

Sicherung

Physikalisch

OSI- Referenzmodel Internetprotokoll-Suite

Kommunikation

NFS

XDR

RPC

FTP, Telnet, SMTP, SNMP

Nicht spezifiziert

ICMPIP

TCP, UDP

Routing-Protokolle

ARP, RARP

Bild 28.1:Internet-Proto-

kolle deckendie ganze

Bandbreite desOSI-Schich-

tenmodells ab

Kapitel 28 • Internet-Protokolle 377

28.2 Internet-Protokoll (IP)

Das Internet Protocol (IP) ist ein Netzwerkschichtprotokoll(Schicht 3), das Adressierungsinformationen sowie einige Kon-trollinformationen enthält, mit denen Pakete geroutet werdenkönnen. IP ist in RFC 791 dokumentiert und stellt das pri-märe Netzwerkschichtprotokoll der Internet-Protokollsuitedar. Zusammen mit dem Transmission Control Protocol (TCP)bildet IP das Herzstück der Internet-Protokolle. IP hat zweiHauptaufgaben: Es soll verbindungslose, effiziente Ausliefe-rung von Datagrammen über ein Verbundnetz gewähren so-wie die Fragmentierung und das Wiederzusammensetzen vonDatagrammen erledigen, damit Datenleitungen mit verschie-denen Größen der Maximum Transmission Units (MTU)unterstützt werden können.

28.2.1 Das Format des IP-Pakets

Ein IP-Paket enthält verschiedene Typen von Informationen,die in Bild 28.2 gezeigt werden.

Identification

Version

Empfangsadresse

Quelladresse

Optionen (+ Auffüllen)

Daten (Variabel)

32 Bit

Lebensdauer

Gesamtlänge

Fragment Offset

Header-Prüfsumme

IHL Type of Service

Protokoll

Flags

Bild 28.2:Ein IP-Paketumfaßt zehnFelder


Im folgenden werden die Felder des IP-Pakets, wie in Bild 28.2gezeigt, erläutert:

− Version – Gibt die Version von IP an, die verwendet wird.

− IP Header Length (IHL) – Gibt die Länge des Datagramm-header in 32-Bit-Worten an.

− Type-of-Service – Spezifiziert, wie ein Protokoll der oberenSchichten ein Datagramm behandelt wissen will, und weistDatagrammen verschiedene Dringlichkeitsstufen zu.

− Gesamtlänge – Spezifiziert die Länge des gesamten IP-Pakets, einschließlich der Daten und Header, in Byte.

− Identifizierung – Enthält eine ganze Zahl, die das Data-gramm identifiziert. Dieses Feld wird benutzt, um Data-grammfragmente zusammenzusetzen.

− Flags (Kennzeichen) – Besteht aus einem 3-Bit-Feld, vondem die beiden rechten Bits (die niederwertigsten) dieFragmentierung kontrollieren. Das rechte Bit legt fest, obdas Paket fragmentiert werden kann. Das mittlere Bit gibtan, ob es sich bei dem Paket um das letzte Fragment einerReihe fragmentierter Pakete handelt. Das dritte oderhöchstwertige Bit wird nicht verwendet.

− Fragment Offset – Gibt die Position der Daten des Frag-ments in bezug auf den Anfang der Daten im ursprüngli-chen Datagramm an, so daß es beim Empfänger möglichist, das Ausgangsdatagramm wieder richtig zusammenzu-setzen.

− Lebensdauer – Enthält einen Zähler, der herunterläuft, bisdas Paket bei Null schließlich abgelegt wird. So wird ver-hindert, daß das Paket endlos herumkreist.

− Protokoll – Gibt an, welches Protokoll der oberen Schich-ten das eingehende Paket erhält, sobald die IP-Prozesseausgeführt sind.

− Headerprüfsumme – Hilft, die Unversehrtheit des IP-Hea-der sicherzustellen.


− Quelladresse – Spezifiziert die sendenden Knoten.

− Empfangsadresse – Spezifiziert den empfangenden Knoten.

− Optionen – Erlaubt IP, verschiedene Optionen wie etwaSicherheit zu unterstützen.

− Daten – Enthält Informationen für obere Schichten.

28.2.2 IP-Adressierung

Wie bei jedem anderen Netzwerkschichtprotokoll, richtet sichauch das Schema der IP-Adressierung nach dem Prozeß, mitdem IP-Datagramme durch ein Verbundnetz geroutet werden.Jede IP-Adresse besteht aus spezifischen Komponenten undhat ein Grundformat. Diese IP-Adressen können unterteilt unddazu verwendet werden, Adressen für Subnetze zu erstellen,was später in diesem Kapitel noch ausführlicher beschriebenwird.

Jedem Host in einem TCP/IP-Netz wird eine eindeutige, logi-sche 32-Bit-Adresse zugewiesen, die aus zwei Hauptteilen be-steht: der Netzwerk-Nummer und der Host-Nmmer. Die Netz-werk-Nummer bezeichnet das Netzwerk und muß vom Inter-net Network Information Center (InterNIC) zugewiesen wer-den, sofern das Netzwerk ein Teil des Internet ist. Ein InternetService Provider (ISP) kann Blöcke von Netzwerk-Adressenvom InterNIC erwerben und diesen Adreßbereich nach Bedarfzuweisen. Die Rechnernummer kennzeichnet einen Rechner ineinem Netzwerk und wird vom lokalen Netzwerk-Administra-tor zugewiesen.

IP-Adreßformat

Die 32-Bit-IP-Adresse wird in Gruppen zu 8 Bits unterteilt,durch Punkte getrennt und im Dezimalformat (der sogenann-ten Punktnotation) dargestellt. Jedes Bit in dem Oktett hateine binäre Wertigkeit (128, 64, 32, 16, 8, 4, 2, 1). Der mini-male Wert für ein Oktett beträgt 0, der maximale Wert 255.Bild 28.3 zeigt das Grundformat einer IP-Adresse.


32 Bit

HostNetzwerk

8 Bit

172

Punkt-notation

• • •16 122 204

8 Bit 8 Bit 8 Bit

28.2.3 IP-Adreßklassen

Die IP-Adressierung unterstützt fünf verschiedene Adreßklas-sen: A, B, C, D und E. Nur die Klassen A, B und C sind fürden kommerziellen Gebrauch verfügbar. Die linken (höchst-wertigen) Bits geben die Netzwerk-Klasse an. Tabelle 28.1informiert über die fünf IP-Adreßklassen:

IP-Adreß-klasse

Format Zweck Höchst-wertige(s)Bit

Adreßbereich Anzahlder Bit fürNetzwerk/Host

Max.Hosts

A N.H.H.H WenigeGroßunter-nehmen

0 1.0.0.0 bis126.0.0.0

7/24 16777214²(224 – 2)

B N.N.H.H MittelgroßeOrganisa-tionen

1, 0 128.1.0.0 bis191.254.0.0

14/16 65543(216 – 2)

C N.N.N.H Relativkleine Or-ganisatio-nen

1, 0, 0 192.0.1.0 bis223.255.254.0

22/8 254(28 – 2)

D N/A Multicast-Gruppen

1, 1, 1, 0 224.0.0.0 bis239.255.255.255

N/A (nichtfür kom-merzielleZwecke)

N/A

E N/A Experimen-tell

1, 1, 1, 1 240.0.0.0 bis254.255.255.255

N/A N/A

Tabelle 28.1: Die wichtigsten Informationen über die fünf IP-Adreßklassen

Bild 28.3:Eine IP-

Adresse bestehtaus 32 Bits, diein vier Oktetteunterteilt sind


Klasse C

Klasse B

Klasse A

Netzwerk01

Netzwerk011

247Anzahl Bit

16 14

21 8

64 32 16 8 4 2 1 128

Netzwerk0 Host Host Host

Host HostNetzwerk

HostNetzwerk Netzwerk

Bild 28.4 zeigt das Format der kommerziellen IP-Adreßklas-sen. (Beachten Sie das linke Bit der jeweiligen Klasse.)

Die Adreßklasse kann leicht festgestellt werden, wenn mandas erste Oktett der Adresse betrachtet und den Wert einemKlassenbereich der folgenden Übersicht zuordnet. In der IP-Adresse 172.31.1.2 zum Beispiel ist das erste Oktett 172. Da172 zwischen 128 und 191 liegt, ist 172.31.1.2 eine Adresseder Klasse B. Bild 28.5 faßt den Bereich möglicher Werte fürdas erste Oktett einer jeden Adreßklasse zusammen.

Klasse A

Adreß-klasse

erstes Oktettin Dezimalnotation

höchstwertigesBis

1 – 126 0

Klasse B 128 – 191 10

Klasse C 192 – 223 110

Klasse D 224 – 239 1110

Klasse E 240 – 254 1111

IP Subnet-Adressierung

IP-Netzwerke können in kleinere Netzwerke unterteilt wer-den, die Subnetzwerke oder Subnetze heißen. Die Einteilung inSubnetze hat für den Administrator diverse Vorteile, wie mehrFlexibilität, effizienterer Gebrauch von Netzwerk-Adressen

Bild 28.4:Die IP-Adreß-formate A, B,und C sind fürkommerzielleZwecke ver-fügbar

Bild 28.5:Für das ersteOktett einerAdreßklassegibt es einenbestimmtenWertebereich


und die Möglichkeit, Rundspruchverkehr zu verwenden (einRundspruch durchläuft keinen Router).

Subnetze werden lokal verwaltet. So sieht die Außenwelt einUnternehmen als einzelnes Netzwerk und bekommt keine ge-nauen Einblicke in die interne Unternehmensstruktur.

Jede Netzwerk-Adresse kann auf viele Subnetze verteiltwerden. Zum Beispiel sind 172.16.1.0, 172.16.2.0, 172.16.3.0und 172.16.4.0 allesamt Subnetze im Netzwerk 171.16.0.0.(Jede 0 im Hostteil einer Adresse spezifiziert das gesamteNetzwerk.)

IP-Subnetzmasken

Eine Subnetzadresse wird gebildet, indem Bits aus dem Host-feld »geliehen« und dem Subnetzfeld zugeschrieben werden.Die Anzahl geliehener Bits variiert und wird von der Subnetz-maske spezifiziert. Bild 28.6 zeigt, wie Bits aus dem Host-adreßfeld geliehen werden, um ein Subnetzadreßfeld zu erstel-len.

Network Host Host

Network Subnetz HostNetwork

Klasse-B-Adresse: vor Einteilung in Subnetze

Klasse-B-Adresse: nach Einteilung in Subnetze

Network01

01

Subnetzmasken verwenden dasselbe Format und dieselbe Dar-stellungstechnik wie IP-Adressen. Die Subnetzmasken enthal-ten eine binäre 1 in jedem Bit, das das Netzwerk spezifiziert,und eine binäre 0 in jedem Bit, das das Host-Feld spezifiziert.Bild 28.7 zeigt ein Beispiel für eine Subnetzmaske.

Bild 28.6:Um das Sub-netzadreßfeld

zu erstellen,werden dem

Host-Adressen-feld Bits

entliehen


HostNetzwerk Netzwerk Subnetz

Beispiel für Subnetzmaske für Klasse-B-Adresse

255

BinäreDarstellung

Punktnotation • • •255 255 0

00000000111111111111111111111111

Die Bits der Subnetzmasken sollten den höchstwertigen (lin-ken) Bits des Host-Feldes entstammen, wie in Bild 28.8 ge-zeigt. Einzelheiten zu Subnetzmasken der Klassen B und C fol-gen. Adressen der Klasse A werden in diesem Kapitel nicht be-sprochen, weil sie im allgemeinen in Subnetzen auf 8 Bit be-grenzt sind.

1

1

1

1

1

1

1

1

0

1

1

1

1

1

1

1

0

0

1

1

1

1

1

1

0

0

0

1

1

1

1

1

0

0

0

0

1

1

1

1

0

0

0

0

0

1

1

1

0

0

0

0

0

0

1

1

0

0

0

0

0

0

0

1

128 64 32 16 8 4 2 1

=

=

=

=

=

=

=

=

128

192

224

240

248

252

254

255

Es gibt verschiedene Typen von Subnetzmasken für Subnetzeder Klassen B und C.

Die Standardsubnetzmaske für eine Adresse der Klasse B, diekein Subnetz hat, ist 255.255.0.0, während die Subnetzmaskefür die Klasse-B-Adresse 171.16.0.0, die 8 Bits eines Subnetzesspezifiziert, 255.255.255.0 ist. Das liegt daran, daß 8 Bits fürden Aufbau eines Subnetzes oder 28–2 (1 für die Netzwerk-Adresse und 1 für die Rundspruchadresse) = 254 möglicheSubnetze mit 28–2 = 254 Hosts pro Subnetz bedeuten.

Bild 28.7:Eine Subnetz-maske bestehtaus binärenNullen undEinsen

Bild 28.8:Die Bits derSubnetzmaskeentstammenden höchst-wertigen Bitsder Host-Felder


Die Subnetzmaske für eine Adresse der Klasse C 192.168.2.0,die fünf Bits für das Subnetz spezifiziert, ist 255.255.255.248.Mit fünf verfügbaren Bits sind 25–2 = 30 Subnetze mit 23–2 =6 Hosts pro Subnetz möglich.

Die Charts in Tabelle 28.2 und Tabelle 28.3 können bei derPlanung von Klasse-B- und Klasse-C-Netzen verwendet wer-den, um die erforderliche Anzahl von Subnetzen und Hostsund die geeignete Subnetzmaske herauszufinden.

Anzahl derBits

Subnetzmaske Anzahl derSubnetze

Anzahl derHosts

2 255.255.192.0 2 163823 255.255.224.0 6 81904 255.255.240.0 14 40945 255.255.248.0 30 20466 255.255.252.0 62 10227 255.255.254.0 126 5108 255.255.255.0 254 2549 255.255.255.128 510 12610 255.255.255.192 1022 6211 255.255.255.224 2046 3012 255.255.255.240 4094 1413 255.255.255.248 8190 614 255.255.255.252 16382 2

Anzahl derBits

Subnetzmaske Anzahl derSubnetze

Anzahl derHosts

2 255.255.255.192 2 623 255.255.255.224 6 304 255.255.255.240 14 145 255.255.255.248 30 66 255.255.255.252 62 2

Tabelle 28.2:Chart der

Subnetze derKlasse B

Tabelle 28.3:Chart für

Subnetze derKlasse C


Wie werden Subnetzmasken verwendet, um die Netzwerk-Nummer festzustellen?

Der Router führt einen bestimmten Prozeß durch, um dieNetzwerk-Adresse, oder genauer, die Subnetzadresse festzu-stellen. Als erstes entnimmt der Router dem eingehendenPaket die IP-Zieladresse und findet die interne Subnetzmaskeheraus. Dann führt er eine logische AND-Operation durch,um die Netzwerk-Nummer zu erhalten. Das bewirkt, daß derHost-Teil der IP-Zieladresse herausgenommen wird, währenddie Zielnetzwerk-Nummer bestehen bleibt. Dann schlägt derRouter die Zielnetzwerk-Nummer nach und verknüpft sie miteiner abgehenden Schnittstelle. Schließlich leitet er den Framean die IP-Zieladresse. Die Besonderheiten der logischen AND-Operationen werden in den folgenden Abschnitten bespro-chen.

Logische AND-Operationen

Drei Grundregeln bestimmen die AND-Verknüpfung zwischenzwei Binärzahlen. Erstens: Eine AND-Verknüpfung zwischen 1und 1 ergibt 1. Zweitens: Eine AND-Verknüpfung zwischen 1und 0 ergibt 0. Drittens: Eine AND-Verknüpfung zwischen 0und 0 ergibt 0. Tabelle 28.4 veranschaulicht die Regeln fürlogische AND-Operationen.

Input Input Output

1 1 11 0 00 1 00 0 0

Es gibt zwei einfache Merksätze für logische AND-Operatio-nen: AND-Verknüpfungen zwischen 1 und 1 ergeben denAusgangswert, und logische AND-Verknüpfungen von 0 mitirgendeiner anderen Zahl ergeben 0.

Bild 28.9 zeigt, was passiert, wenn die IP-Zieladresse und dieSubnetzmaske mit AND verknüpft werden: Die Subnetznum-mer, die der Router verwendet, um das Paket weiterzuleiten,bleibt bestehen.

Tabelle 28.4:Regeln fürlogische AND-Operatoren


Netzwerk Subnetz Host

171

171.16.1.2

255.255.255.0

Empfangs-IP-Adresse

Subnetzmaske

16 1 0

00000000111111111111111111111111

00000010000000010001000010101011

00000000000000010001000010101011

28.3 Address-Resolution Protocol (ARP) imÜberblick

Wenn zwei Maschinen in einem Netzwerk kommunizierensollen, müssen sie die physischen oder MAC-Adressen der an-deren Maschine kennen. Durch einen Rundspruch der Ad-dress-Resolution-Protokolle (ARPs) kann ein Host die MAC-Schichtenadressen, die einer bestimmten IP-Netzwerkschicht-adresse entsprechen, herausfinden.

Nach dem Erhalt einer MAC-Schichtenadresse erstellen IP-Geräte einen ARP-Cache, um kürzlich empfangene Verknüp-fungen zwischen IP- und MAC-Adressen zu speichern, wo-durch sie einen Rundspruch von ARPs vermeiden, wenn sieerneut mit einem Gerät Kontakt aufnehmen wollen. Antwor-tet das Gerät nicht innerhalb einer vorgegebenen Zeit, wirdder Cache-Eintrag versenkt.

Zusätzlich wird das Reverse Address-Resolution Protocol(RARP) verwendet, um MAC-Schichtenadressen IP-Adressenzuzuordnen. RARP, die logische Umkehrung von ARP, kannvon plattenlosen Workstations verwendet werden, die ihre IP-Adressen beim Booten nicht kennen. RARP wird von einemRARP-Server unterstützt, der Tabellen der Verknüpfungen vonMAC-Schichten- und IP-Adressen enthält.

28.4 Internet-Routing

Geräte für das Internet-Routing wurden traditionell Gatewaysgenannt. In der heutigen Terminologie bezieht sich der BegriffGateway besonders auf ein Gerät, das Übersetzungen von

Bild 28.9:Bei einer

AND-Verknüp-fung zwischen

der IP-Ziel-adresse und der

Subnetzmaskeergibt sich dieSubnetzwerk-

Nummer


Anwendungsschichtprotokollen zwischen Geräten durchführt.Interne Gateways sind Geräte, die diese Protokollfunktionenzwischen Maschinen und Netzwerken durchführen, die vonder gleichen Stelle verwaltet werden, wie es im internen Un-ternehmensnetzwerk der Fall ist. Hier spricht man von auto-nomen Systemen. Externe Gateways führen Protokollfunktio-nen zwischen unabhängigen Netzwerken aus.

Router im Internet sind hierarchisch organisiert. Router, diefür den Informationsaustausch in autonomen Systemen ver-wendet werden, nennt man interne Router. Sie benutzen eineReihe von Interior Gateway Protocols (IGPs), um ihren Zweckzu erfüllen. Ein Beispiel für ein IGP ist das Routing Informa-tion Protocol (RIP).

Router, die Informationen zwischen autonomen Systemen be-wegen, nennt man externe Router Sie verwenden externeGateway-Protokolle, um Informationen zwischen autonomenSystemen auszutauschen. Ein Beispiel für ein externes Gate-way-Protokoll ist das Border Gateway Protocol (BGP).

Bestimmte Routingprotokolle, einschließlich BGP und RIP,werden in eigenen Kapiteln im sechsten Teil dieses Buchesvorgestellt.

28.4.1 IP-Routing

IP-Routingprotokolle arbeiten dynamisch. Dynamisches Rou-ting verlangt, daß die Software in Routinggeräten Leitwege inregelmäßigen Abständen automatisch berechnet. Dies unter-scheidet sich vom statischen Routing, bei dem Router vomNetzwerk-Administrator eingerichtet werden und sich solange nicht verändern, bis der Administrator dies tut.

Eine IP-Routingtabelle, die aus Paaren von Zieladresse undder nächsten Etappe besteht, wird verwendet, um das dynami-sche Routing zu ermöglichen. Ein Eintrag in dieser Tabellewürde zum Beispiel wie folgt interpretiert: Um zum Netzwerk172.31.0.0 zu gelangen, sende das Paket über die Ethernet-schnittstelle 0 (E0) aus.

Das IP-Routing legt fest, daß Daten ein Verbundnetz etap-penweise durchqueren. Beim Beginn der Reise ist nicht die


ganze Route bekannt. Statt dessen wird bei jedem Halt dasnächste Ziel berechnet, indem die Zieladresse im Datagrammmit dem Eintrag in der Routingtabelle des aktuellen Knotensabgeglichen wird.

Der Einfluß des Knotens auf den Routingprozeß beschränktsich darauf, daß er das Paket aufgrund seiner internen Infor-mationen weiterleitet. Der Knoten überwacht nicht, ob dasPaket an sein Ziel gelangt, und IP sendet keine Fehlermeldungan den Ausgangspunkt zurück, wenn beim Routing etwasUngewöhnliches auftritt. Diese Aufgabe bleibt einem anderenInternet-Protokoll vorbehalten: dem Internet Control-MessageProtocol (ICMP), das im folgenden Abschnitt besprochenwird.

28.5 Internet Control-Message Protocol(ICMP)

Das Internet Control-Message Protocol (ICMP) ist ein Netz-werkschicht-Internet-Protokoll, das es Nachrichtenpaketen er-möglicht, dem Ausgangspunkt Fehler und andere Informatio-nen, die das IP-Paket betreffen, zu melden. ICMP ist in RFC792 dokumentiert.

28.5.1 ICMP-Nachrichten

ICMPs erstellen verschiedene Arten nützlicher Nachrichten,wie zum Beispiel »Ziel nicht erreichbar«, Echoanforderungund -antwort, »Umleiten«, »Zeit abgelaufen« und Routerbe-kanntgabe und -anfrage. Kann eine ICMP-Nachricht nichtausgeliefert werden, wird keine zweite erstellt. Dadurch wirdein endloser Fluß von ICMP-Nachrichten vermieden.

Wenn ein Router eine ICMP-Ziel nicht erreichbar«-Nachrichtsendet, bedeutet das, daß der Router nicht in der Lage ist, dasPaket an sein Ziel zu schicken. Der Router legt das Original-paket dann ab. Es gibt zwei Möglichkeiten, warum ein Zielnicht erreichbar ist. Meistens hat der Quellhost eine nicht exi-stierende Adresse angegeben. Manchmal hat aber auch derRouter keinen Leitweg zum Ziel.

Es gibt vier Arten von »Ziel nicht erreichbar«-Nachrichten:»Netzwerk nicht erreichbar«, »Host nicht erreichbar«,


»Protokoll nicht erreichbar« und »Port nicht erreichbar«.»Netzwerk nicht erreichbar« bedeutet zumeist, daß ein Fehlerbeim Routing oder der Adressierung eines Pakets aufgetretenist. »Host nicht erreichbar« weist gewöhnlich auf einen Fehlerbei der Auslieferung hin, wie etwa bei einer falschen Subnetz-maske. »Protokoll nicht erreichbar« geht im allgemeinen dar-auf zurück, daß das Ziel das Protokoll der oberen Schichten,das im Paket spezifiziert wurde, nicht unterstützt. »Port nichterreichbar« weist darauf hin, daß der TCP-Socket oder -Portnicht verfügbar ist.

Eine ICMP-Echoanforderung, die durch das Ping-Kommandoerstellt wird, wird von jedem Rechner geschickt, um die Er-reichbarkeit von Knoten im Verbundnetz zu prüfen. DieICMP-Echoantwortnachricht zeigt an, daß der Knoten er-reicht werden kann.

Eine ICMP-»Umleiten«-Nachricht wird von einem Routerzum Quellhost geschickt, um ein effizienteres Routen zu be-wirken. Dennoch leitet der Router das Originalpaket an dasZiel weiter. Durch das Umleiten von ICMP bleiben Routing-tabellen klein, weil es genügt, die Adresse von nur einem Rou-ter zu kennen, auch wenn dieser Router nicht den besten Pfadbietet. Auch nach dem Erhalt einer ICMP-»Umleiten«-Nach-richt benutzen manche Geräte weiterhin weniger effizienteRouten.

Eine ICMP-»Zeit abgelaufen«-Nachricht wird von dem Rou-ter geschickt, wenn das Lebensdauerfeld (angegeben in Hopsoder Sekunden) eines IP-Pakets Null erreicht. Das Lebens-dauerfeld verhindert, daß Pakete immer weiter durch das Ver-bundnetz kreisen, wenn das Verbundnetz eine Routingschleifeenthält.

28.5.2 ICMP Router-Discovery Protocol (IDRP)

IDRP verwendet Routerbekanntgabe- und Routeranfrage-Nachrichten, um die Adressen von Routern in direkt verbun-denen Subnetzen zu erfahren. Jeder Router sendet von jederseiner Schnittstellen in regelmäßigen Abständen Routerbe-kanntgaben. Die Hosts entdecken dann die Routeradressenvon den angeschlossenen Subnetzen, indem sie diese Nachrich-ten abhören. Hosts können Routeranfragen benutzen, um Be-


kanngaben unmittelbar abzufragen, anstatt auf eine nicht an-geforderte Nachricht zu warten.

Gegenüber anderen Methoden, Adressen benachbarter Routerzu finden, bietet IRDP verschiedene Vorteile. Vor allem benö-tigt es keine Hosts, um Routingprotokolle zu erkennen, und esmuß auch nicht manuell vom Netzwerk-Administrator konfi-guriert werden.

Routerbekanntgabe-Nachrichten ermöglichen es Hosts zwar,benachbarte Router zu finden, sagen aber nichts darüber aus,welcher Router sich am besten eignet, ein bestimmtes Ziel zuerreichen. Wenn ein Host einen einfachen First-Hop-Routerverwendet, um ein Ziel zu erreichen, erhält er eine »Umlei-ten«-Nachricht, die eine bessere Möglichkeit aufzeigt.

28.6 Transmission-Control Protocol (TCP)

TCP bietet die zuverlässige Datenübermittlung in einer IP-Umgebung. TCP entspricht der Transportschicht (Schicht 4)des OSI-Basisreferenzmodells. Zu den Diensten von TCP ge-hören Datenstromtransfer, Verläßlichkeit, effiziente Ablauf-steuerung, Vollduplexbetrieb und Multiplexing.

Mit dem Datenstromtransfer liefert TCP einen unstrukturier-ten Strom von Bytes, die durch Sequenznummern identifiziertwerden. Dieser Dienst kommt Anwendungen zugute, weil sieDaten nicht in Blöcke zerlegen müssen, bevor sie diese an TCPweiterreichen. Statt dessen gruppiert TCP die Bytes in Seg-mente und übergibt sie zur Auslieferung an IP.

TCP bietet Zuverlässigkeit durch eine verbindungsorientiertePaketauslieferung zwischen Endpunkten in einem Verbund-netz. Dabei werden Bytes mit einer Bestätigungsnummer ver-sehen, die dem Ziel das nächste Byte anzeigen, das die Quelleerwartet. Nicht bestätigte Bytes werden innerhalb eines gewis-sen Zeitraums erneut übermittelt. Der Zuverlässigkeitsme-chanismus von TCP erleichtert Geräten den Umgang mit ver-lorenen, verspäteten, doppelten oder falsch gelesenen Paketen.Über einen Zeitschaltmechanismus können Geräte verlorenePakete aufspüren und eine erneute Übermittlung anfordern.

TCP bietet effiziente Ablaufsteuerung. Das heißt, wenn die Be-stätigungen an die Quelle zurückgeschickt werden, gibt der


empfangende TCP-Prozeß die höchste Sequenznummer an, dieer empfangen kann, ohne daß seine internen Puffer über-laufen.

Vollduplex-Betrieb bedeutet, daß TCP-Prozesse gleichzeitigsenden und empfangen können.

Multiplexing bedeutet schließlich, daß bei TCP gleichzeitigzahlreiche Unterhaltungen in den oberen Schichten über eineeinzige Verbindung ablaufen können.

28.6.1 TCP-Verbindungsaufbau

Um einen zuverlässigen Transportdienst zu nutzen, müssenTCP-Hosts miteinander eine verbindungsorientierte Sitzungaufbauen. Die Verbindung wird durch den »three-way hand-shake« aufgebaut.

Ein three-way handshake synchronisiert die beiden Enden ei-ner Verbindung, wobei beide Seiten sich auf eine Anfangsse-quenznummer einigen können. Dieser Mechanismus garantiertauch, daß beide Seiten bereit sind, Daten zu übermitteln, undwissen, daß die andere Seite ebenfalls dazu bereit ist. Dies istnotwendig, damit keine Pakete während des Sitzungsaufbausoder nach der Beendigung der Sitzung übermittelt werden. Je-der Host wählt eine Sequenznummer nach dem Zufallsprinzipaus, die dazu verwendet wird, Bytes in dem Strom, die er sen-det und empfängt, aufzuspüren. Dann wird der three-wayhandshake auf die folgende Weise durchgeführt:

Der erste Host (Host A) leitet eine Verbindung ein, indem erein Paket mit der Anfangssequenznummer (X) und einemSYN-Bitsatz, der die Anforderung darstellt, sendet. Der zweiteHost (Host B) erhält die SYN, stellt die Sequenznummer Xfest und antwortet mit einer Bestätigung der SYN (mit ACK =X + 1). Host B fügt seine eigene Anfangssequenznummerhinzu (SEQ = Y). Ein ACK = 20 bedeutet, daß der Host dieBytes 0 bis 19 empfangen hat und als nächstes Byte 20 erwar-tet. Diese Technik wird Forward Acknowledgment genannt.Host A bestätigt alle Bytes, die Host B mit einer Übermitt-lungsbestätigung geschickt hat, die das nächste Byte zeigt, dasHost A erwartet (ACK = Y + 1).

Dann kann der Datentransfer beginnen.


28.6.2 Positive Acknowledgment and Retransmission(PAR)

Ein einfaches Transportprotokoll könnte Zuverlässigkeits-und Ablaufsteuerungstechniken realisieren, bei denen dieQuelle ein Paket sendet, einen Timer startet und auf eine Be-stätigung wartet, bevor ein neues Paket abgeschickt wird.Geht keine Bestätigung ein, bevor der Timer abläuft, sendetdie Quelle das Paket erneut. Solch eine Technik wird PositiveAcknowledgment And Retransmission genannt.

Indem PAR jedem Paket eine Sequenznummer zuordnet, ver-setzt es Hosts in die Lage, verlorene oder doppelte Pakete auf-zuspüren, welche durch Netzwerk-Verzögerungen verursachtwurden, die zu einer verfrühten Neuübermittlung führen. DieSequenznummern werden in den Bestätigungen, die dannüberprüft werden können, zurückgeschickt.

PAR gebraucht die Bandbreite wenig effizient, denn ein Hostmuß hier auf eine Bestätigung warten, bevor er ein neuesPaket sendet, und außerdem kann nur ein Paket auf einmalgesendet werden.

28.6.3 TCP Sliding Window

Ein TCP Sliding Window bietet einen effizienteren Gebrauchder Netzwerk-Bandbreite als PAR, weil es Hosts in die Lageversetzt, viele Bytes oder Pakete zu senden, ohne vorher aufeine Bestätigung zu warten.

Bei TCP gibt der Empfänger die aktuelle Fenstergröße einesjeden Pakets an. Da TCP eine Bytestromverbindung zur Ver-fügung stellt, werden Fenstergrößen in Byte angegeben. Dasheißt, ein Fenster ist die Anzahl von Datenbytes, die der Sen-der verschicken darf, bevor er auf eine Bestätigung wartenmuß. Die anfänglichen Fenstergrößen werden beim Verbin-dungsaufbau angezeigt, doch können sie während des Daten-transfers variieren, um die Ablaufsteuerung zu gewährleisten.Die Fenstergröße Null bedeutet zum Beispiel: »Sende keineDaten«.

Bei einem Sliding-Window-Vorgang in TCP kann der Senderzum Beispiel eine Bytesequenz (von 1 bis 10 numeriert) an ei-nen Empfänger verschicken, der die Fenstergröße 5 hat. Der


Sender würde dann ein Fenster um die ersten 5 Bytes erstellenund sie zusammen verschicken. Dann würde er auf eineBestätigung warten.

Der Empfänger würde mit ACK = 6 antworten und damit an-zeigen, daß er die Bytes 1 bis 5 erhalten hat und als nächstesByte 6 erwartet. Im selben Paket würde der Empfänger anzei-gen, daß seine Fenstergröße 5 beträgt. Dann würde der Sendersein Sliding Window fünf Bytes nach rechts versetzen und dieBytes 6 bis 10 übermitteln. Der Empfänger antwortet in die-sem Fall mit ACK = 11, was bedeutet, daß er als nächstes Byte11 erwartet. In diesem Paket könnte der Empfänger auch mit-teilen, daß seine Fenstergröße 0 beträgt (zum Beispiel, weilseine internen Puffer voll sind). In diesem Fall kann der Senderkeine Bytes mehr verschicken, bis der Empfänger ein anderesPaket mit einer Fenstergröße über 0 übermittelt.

28.6.4 TCP-Paketformat

Bild 28.10 zeigt die Felder und das Format eines TCP-Pakets.

Sequenznummer

Quellport

DringlichkeitszeigerPrüfsumme

Daten-Offset Reserviert Flags Fenster

Optionen (+ Auffüllen)

Daten (variabel)

32 Bit

Empfangsport

Bestätigungsnummer

28.6.5 Beschreibung der TCP-Paketfelder

Die folgenden Beschreibungen erläutern die TCP-Paketfelder,die in Bild 28.10 gezeigt werden:

− Quellport und Empfangsport – Gibt die Punkte an, an de-nen Quell- und Empfangsprozesse der oberen SchichtenTCP-Dienste erhalten.

Bild 28.10:Ein TCP-Paketwird aus zwölfFeldern gebil-det


− Sequenznummer – Gibt gewöhnlich die Nummer an, diedem ersten Datenbyte der Nachricht zugewiesen wurde. Inder Phase des Verbindungsaufbaus kann dieses Feld auchdazu benutzt werden, eine Anfangssequenznummer zukennzeichnen, die in der aufkommenden Übermittlungverwendet wird.

− Bestätigungsnummer – Enthält die Sequenznummer desnächsten Datenbytes, das der Sender des Pakets erwartet.

− Daten-Offset – Zeigt die Nummer eines 32-Bit-Worts imTCP-Header.

− Reserviert – Bleibt für zukünftigen Gebrauch reserviert.

− Flags – Trägt eine Vielzahl von Kontrollinformationen, ein-schließlich der SYN- und ACK-Bits, die zum Verbindungs-aufbau benutzt werden, und des FIN-Bits, das für die Be-endigung der Verbindung verwendet wird.

− Fenster – Spezifiziert die Größe des Empfangsfensters desSenders (das heißt, den Pufferbereich, der für eingehendeDaten verfügbar ist).

− Prüfsumme – Gibt an, ob der Header beim Transport be-schädigt wurde.

− Dringlichkeitszeiger – Zeigt auf das dringendste Datenbyteim Paket.

− Optionen – Spezifiziert verschiedene TCP-Optionen.

− Daten – Enthält Informationen der oberen Schichten.

28.7 User Datagram Protocol (UDP)

Das User Datagram Protocol (UDP) ist ein verbindungslosesTransportschichtprotokoll (Schicht 4), das zur Internet-Proto-kollfamilie gehört. UDP ist im Prinzip eine Schnittstelle zwi-schen IP und Prozessen der oberen Schichten. UDP-Protokoll-ports unterscheiden die vielen Anwendungen, die auf einemeinzigen Gerät laufen, voneinander.

Anders als TCP fügt UDP IP keine Funktionen wie Zuverläs-sigkeit, Ablaufsteuerung oder Fehlerbehebung hinzu. Da UDP


eine einfache Struktur hat, enthalten UDP-Header wenigerBytes und beanspruchen weniger Netzwerk-Overhead als TCP.

UDP ist nützlich in Situationen, in denen die Zuverlässig-keitsmechanismen von TCP nicht erforderlich sind, wenn alsoein Protokoll der höheren Schichten die Fehlerbehebung undAblaufsteuerung erledigen kann.

UDP ist das Transportprotokoll für verschiedene, sehr be-kannte Anwendungsschichtprotokolle wie etwa Network FileSystem (NFS), Simple Network-Management Protocol(SNMP), Domain Name System (DNS) und Trivial File-Transfer Protocol (TFTP).

Das Format des UDP-Pakets enthält vier Felder, die in Bild28.11 dargestellt sind. Es sind Quell- und Zielport-, Längen-und Prüfsummenfelder.

32 Bit

EmpfangsportQuellport

PrüfsummeLänge

Quell- und Empfangsport enthalten die 16 Bit langen UDP-Protokollportnummern, die verwendet werden, um Data-gramme zu demultiplexen, damit Anwendungsschichtprozesseempfangen werden können. Ein Längenfeld spezifiziert dieLänge des UDP-Headers und der Daten. Die Prüfsumme stellteine (optionale) Unversehrtheitskontrolle von UDP-Headernund Daten bereit.

28.8 Die Anwendungsschichtprotokolle derInternet-Protokolle

Die Internet-Protokollsuite beinhaltet zahlreiche Anwendungs-schichtprotokolle, die eine Vielzahl von Anwendungen, wieetwa die folgenden, repräsentieren:

− File Transfer Protocol (FTP) – Bewegt Dateien zwischenGeräten

Bild 28.11:Ein UDP-Paket bestehtaus vierFeldern


− Simple Network-Management Protocol (SNMP) – Meldetin der Hauptsache ungewöhnliche Netzwerk-Bedingungenund setzt Netzwerk-Schwellenwerte

− Telnet – Dient als Terminalemulationsprotokoll

− X Windows – Dient als verteiltes Fenstersystem und gra-fische Benutzeroberfläche, die für die Kommunikationzwischen X-Terminals und UNIX-Workstations verwendetwird

− Network File System (NFS), External Data Representation(XDR) und Remote Procedure Call (RPC) – Arbeiten ge-meinsam, um den transparenten Zugriff auf entfernte Netz-werk-Ressourcen zu gewähren

− Simple Mail Transfer Protocol (SMTP) – Stellt E-Mail-Dienste bereit

− Domain Name System (DNS) – Übersetzt die Namen derNetzwerk-Knoten in Netzwerk-Adressen

Tabelle 28.5 listet diese Protokolle der höheren Schichten mitden Anwendungen, die sie unterstützen, auf.

Anwendung Protokolle

Dateitransfer FTPNetzwerkmanagement SNMPTerminalemulation TelnetVerteiler Dateidienst NFS, XDR, RPC, X WindowsElektronische Post SMTPNamensvertriebsservice DNS

Tabelle 28.5:Protokolle

oberer Schich-ten und ihre

Anwendungen

29 NetWare-Protokolle

29.1 Hintergrund

NetWare ist ein Netzwerk-Betriebssystem, das transparentenFernzugriff auf Dateien und zahlreiche andere Netzwerk-Dien-ste bereitstellt, zum Beispiel die gemeinsame Nutzung vonDruckern und die Unterstützung verschiedener Anwendungenwie E-Mail und Datenbankzugriff. NetWare spezifiziert dieoberen fünf Schichten des OSI-Schichtenmodells und läuftsomit mit praktisch jedem Medienzugriffsprotokoll (Schicht2). Außerdem arbeitet NetWare quasi auf allen Computersy-stemen, vom PC bis zum Großrechner. Dieses Kapitel be-schreibt die wichtigsten Kommunikationsprotokolle, die Net-Ware unterstützen.

NetWare wurde in den frühen 80er Jahren von Novell, Inc.,entwickelt und eingeführt. Es ging aus dem Xerox NetworkSystem (XNS) hervor, das von der Xerox Corporation in denspäten 70ern geschaffen wurde. Clients (manchmal auchWorkstations genannt) rufen Dienste, wie etwa Datei- undDruckerzugriff von Servern ab.

NetWares Client-Server-Architektur unterstützt den Fernzu-griff, der den Benutzern durch Fernabfrage zugänglich ist.Eine Fernabfrage beginnt, wenn das lokale Computerpro-gramm, das auf dem Client läuft, eine Abfrage an den Remote

KAPITEL 29NetWare-Protokolle


Server sendet. Der Server bearbeitet dann die Fernabfrage undschickt die gewünschte Information an den lokalen Client.

Bild 29.1 zeigt die NetWare-Protokollsuite, die Medienzu-griffsprotokolle, auf denen NetWare läuft, und das Verhältniszwischen den NetWare-Protokollen und dem OSI-Schichten-modell. Dieses Kapitel erläutert die Elemente und Operationendieser Protokollkomponenten.

Darstellung

Anwendung

Netzwerk

Transport

Sicherung

Bitübertragung

OSI-Referenzmodell NetWare

Kommunikation RPC

NetBIOS-Emulator

NetWareCore

Protocol(NCP)

Anwendungen

NetWare-Shell

(Client)

RPC-basierte

Anwendung

LU 6.2-Unterstützung

Ethernet/IEEE 802.3

Token Ring/IEEE802.5

FDDI ARCnet PPP

IPX

SPX

29.2 NetWare Medienzugriff

Die NetWare-Protokollsuite unterstützt verschiedene Medien-zugriffsprotokolle (Schicht 2), wie etwa Ethernet/IEEE 802.3,Token Ring/IEEE 802.5, Fiber-Distributed Data Interface(FDDI) und das Point-to-Point-Protokoll (PPP). Bild 29.2 hebtdie Bandbreite von NetWares Medienzugriffsunterstützunghervor.

Bild 29.1:Die NetWare-Protokollsuite

liegt in allenOSI-Schichten

Kapitel 29 • NetWare-Protokolle 399

NetWare-Knoten

Ethernet

Token RingFDDI

NetWare-Knoten NetWare-Knoten

29.3 Internetwork Packet Exchange (IPX) imÜberblick

Das Internetwork Packet Exchange (IPX) ist das ursprünglicheNetzwerkschichtprotokoll (Schicht 3) von NetWare und wirdverwendet, um Pakete durch ein Verbundnetz zu routen. IPXist ein verbindungsloses, auf Datagrammen basierendes Netz-werk-Protokoll und ähnelt als solches dem Internet-Protokoll,das man in TCP/IP-Netzwerken findet.

IPX nutzt die Dienste eines dynamischen Vektorfernrou-tingprotokolls (Routing-Information Protocol [RIP]) oder ei-nes Verbindungszustandsroutingprotokolls (NetWare Link-State Protocol [NLSP]). IPX RIP sendet alle 60 SekundenRoutingaktualisierungen. Um über den besten Routingpfad zuentscheiden, verwendet IPX RIP ein »Tick« als Maß, das imPrinzip die Verzögerung ist, die bei der Verwendung einer be-stimmten Länge zustandekommt. Ein Tick ist ein Achtzehnteleiner Sekunde. Im Falle von zwei Pfaden mit gleicher Tickzäh-lung verwendet IPX RIP die Etappenzählung als entscheiden-des Kriterium. (Wenn ein Paket einen Router durchläuft, isteine Etappe vollendet.) IPXs RIP ist mit RIP-Implementierun-gen anderer Netzwerk-Umgebungen nicht kompatibel.

Wie sonstige Netzwerk-Adressen, müssen auch die Netzwerk-Adressen von Novell IPX einmalig sein. Diese Adressen wer-den hexadezimal angegeben und bestehen aus zwei Teilen: ei-ner Netzwerk-Nummer und einer Knotennummer. Die IPX-Netzwerk-Nummer, die vom Netzwerk-Administrator zuge-wiesen wird, ist 32 Bit lang. Die Knotennummer, die gewöhn-lich die Media-Access-Control-Adresse (MAC) für eine derNetzwerk-Interfacekarten (NIC) im System ist, ist 48 Bit lang.

Bild 29.2:NetWareunterstützt diegängigstenMedien-zugriffs-protokolle


Indem IPX MAC-Adressen als Knotennummern verwendet,ermöglicht es dem System, Knoten zu senden, um vorherzuse-hen, welche MAC-Adresse bei einer Datenverknüpfung be-nutzt werden muß. (Da der Host-Teil der IP-Netzwerk-Adresse nichts mit der MAC-Adresse zu tun hat, müssen IP-Knoten das Address-Resolution Protocol [ARP] anwenden,um die MAC-Adresse des Ziels festzustellen.)

29.4 IPX-Kapselungsarten

Novell NetWare IPX unterstützt mehrere Verfahren der Kap-selung auf einer einzigen Routerschnittstelle, vorausgesetzt, eswerden mehrere Netzwerknummern zugewiesen. Die Kapse-lung ist das Verfahren, bei dem Informationen aus oberenSchichten zusammen mit Daten in einen Frame gepackt wer-den. NetWare unterstützt die vier folgenden Arten der Kapse-lung:

− Novell Proprietary – Novell Proprietary, auch »802.3 raw«oder Novell Ethernet_802.3 genannt, ist das Grundverfah-ren, das Novell für die Kapselung benutzt. Es enthält einIEEE-802.3-Längenfeld, aber keinen IEEE-802.2-(LLC-)-Header. Der IPX-Header folgt unmittelbar auf das 802.3-Längenfeld.

− 802.3 – Ist das standardmäßige IEEE-802.3-Frameformat,auch Novell_802.2, 802.3 genannt.

− Ethernet Version 2 – Heißt auch Ethernet-II oder ARPA.Ethernet Version 2 beinhaltet den standardmäßigen Ether-net-Version-2-Header, der aus Ziel- und Quelladreßfelderngefolgt von einem EtherType-Feld besteht.

− SNAP – Wird auch als Ethernet-SNAP bezeichnet. SNAPerweitert den IEEE-802.2-Header, indem es einen Typen-code hinzufügt, der jenem ähnlich ist, der in der Ethernet-Version-2-Spezifizierung definiert wird.

Bild 29.3 veranschaulicht diese Arten der Kapselung.


Ethernet_802.3

IPX802.3

Ethernet_802.2

IPX

IPX

802.3 802.2 LLC

802.2 LLC

Ethernet_II

IPX

Ethernet_SNAP

802.3 SNAP

Ethernet

29.5 Service-Advertisement Protocol (SAP)

Das Service-Advertisement Protocol (SAP) ist ein IPX-Proto-koll, über das Netzwerk-Ressourcen wie Dateiserver- undPrintserver-Adressen und die Dienste bekannt gegeben wer-den. Alle 60 Sekunden werden Bekanntmachungen über SAPgesendet. Dienste werden mit einer Hexadezimalzahl gekenn-zeichnet, die SAP-Identifier genannt wird (zum Beispiel 4 =Dateiserver und 7 = Printserver).

Eine SAP-Operation beginnt, wenn Router SAPs anhören undeine Tabelle mit allen bekannten Diensten und den dazugehö-rigen Netzwerk-Adressen erstellen. Dann senden Router alle60 Sekunden ihre SAP-Tabelle aus. Novell-Clients können eineAnforderung abschicken, in der sie einen bestimmten Datei-,Print- oder Gateway-Dienst verlangen. Der lokale Routerantwortet auf die Anforderung mit der Netzwerk-Adresse desverlangten Dienstes, und der Client kann dann den Dienstdirekt ansprechen.

SAP hat die Vormachtstellung in heutigen Netzwerken, die aufNetWare 3.11 und früheren Versionen basieren. In Novell-4.0-Netzwerken kommt es jedoch seltener zum Einsatz, weil hierWorkstations Dienste über einen NetWare Directory Services(NDS)- Server in Anspruch nehmen können. Dennoch ist SAPfür die Workstations auch in NetWare-4.0-Netzen noch erfor-derlich, damit sie beim Booten einen NDS-Server finden.

Bild 29.3:Es gibt vierArten derKapselung


29.5.1 SAP-Filter

Mit den SAP-Identifiern können SAP-Bekanntmachungen indem Ein-/Ausgabe-Anschluß eines Routers oder einem spezifi-schen Router herausgefiltert werden. SAP-Filter sparen Band-breite des Netzwerks ein und sind besonders nützlich in gro-ßen Novell-Installationen, in denen es Hunderte von SAP-Diensten gibt.

Im allgemeinen ist der Gebrauch von SAP-Filtern für Diensteempfehlenswert, die nicht für ein bestimmtes Netzwerk reser-viert sind. Zum Beispiel brauchen entfernte Standorte wahr-scheinlich keine SAP-Bekanntmachungen über Printdienste,die sich an einer zentralen Stelle befinden. Ein SAP-Outputfil-ter an der zentralen Stelle (empfehlenswert) oder ein SAP-Inputfilter, der den SAP-Identifier für einen Printserver an dementlegenen Standort benutzt, hält den Router davon ab,Printdienste mit den SAP-Aktualisierungen zu verschicken.

29.6 NetWare-Transportschicht

Das Sequenced Packet-Exchange (SPX)-Protokoll ist das gän-gigste NetWare-Transportprotokoll in der Schicht 4 des OSI-Schichtenmodells. SPX setzt in der NetWare-Protokollsuite aufIPX auf. SPX ist ein verläßliches, verbindungsorientiertes Pro-tokoll, das den Datagrammdienst von IPX, NetWares Netz-werkschichtprotokoll (Schicht 3), ergänzt. SPX ging aus demSequenced Packet Protocol (SPP) von Xerox NetworkingSystems (XNS) hervor. Novell bietet auch die Unterstützungdes Internet-Protokolls in Form des User Datagram Protocol(UDP) an. IPX-Datagramme werden zum Transport durch einIP-basiertes Verbundnetz in UDP/IP-Köpfe verkapselt.

29.7 NetWare-Protokolle und Dienste deroberen Schichten

NetWare unterstützt eine Vielzahl von Protokollen der oberenSchichten, wie zum Beispiel NetWare Shell, NetWare RemoteProcedure Call, NetWare Core Protocol und Network BasicInput/Output System.


Die NetWare Shell steuert Clients (von der NetWare-Ge-meinde oft Workstations genannt) und fängt Input/Output(I/O)-Aufrufe von Anwendungen ab, um festzustellen, ob siezur Vollendung Netzwerk-Zugriff benötigen. Wenn die Anfor-derung der Anwendung den Netzwerk-Zugriff erfordert, ver-packt die NetWare Shell die Anforderung und sendet sie zurVerarbeitung und Netzwerk-Übermittlung an Software der un-teren Schichten. Erfordert die Anfrage der Anwendung keinenNetzwerk-Zugriff, wird die Anforderung an die lokalen I/O-Ressourcen geleitet. Client-Anwendungen wissen nicht, ob einNetzwerk-Zugriff erforderlich ist, um den Aufruf einerAnwendung zu vollenden.

NetWare Remote Procedure Call (NetWare RPC) ist ein weite-rer, allgemeinerer Nachsendemechanismus, der der NetWareShell von Novell vom Konzept her ähnelt.

Das NetWare Core Protocol (NCP) besteht aus einer Reihevon Serverroutinen, die den Zweck haben, Anfragen von An-wendungen zu bedienen, die zum Beispiel von der NetWareShell kommen. Zu den Diensten, die NCP bereitstellt, gehörenDateizugriff, Druckerzugriff, Namenverwaltung, Abrechnun-gen, Sicherheit und Dateisynchronisierung.

NetWare unterstützt auch das Network Basic Input/OutputSystem (NetBIOS), die Spezifizierung der Schnittstelle derKommunikationssteuerschicht von IBM und Microsoft. Net-Wares NetBIOS-Emulierungssoftware ermöglicht es, daß Pro-gramme, die für die standardmäßige NetBIOS-Schnittstelle ge-schrieben wurden, auf NetWare-Systemen laufen.

29.7.1 NetWare-Dienste der Anwendungsschicht

Zu den NetWare-Diensten der Anwendungsschicht gehörenNetWare Message-handling Service (NetWare MHS), Btrieve,NetWare Loadable Modules (NLMs), und IBM Logical Unit(LU) 6.2 Network-Addressable Units (NAUs). NetWare MHSist ein Nachrichtensystem, das den Transport von E-Mails er-möglicht. Btrieve ist Novells Implementierung des Binary-Tree-Datenbankzugriffmechanismus (btree). NLMs sind Add-on-Module, die an ein NetWare-System angeschlossen werden.NLMs, die es derzeit von Novell und Drittanbietern gibt, be-inhalten alternative Protokollstapel, Kommunikationsdienste


und Datenbankdienste. In Verbindung mit IBM LU 6.2 NAUerlaubt NetWare Peer-to-Peer-Verbindungen und den Infor-mationsaustausch über IBM-Netzwerke. NetWare-Pakete wer-den zum Transport durch ein IBM-Netzwerk in LU-6.2-Paketverkapselt.

29.8 IPX-Paketformat

Das IPX-Paket ist die Grundeinheit des Netzbetriebs von No-vell NetWare. Bild 29.4 zeigt das Format eines NetWare-IPX-Pakets.

IPX-Paketstruktur

Prüfsumme

Paketlänge

Transportkontrolle Pakettyp

Zielnetzwerk

Zielknoten

Zielsocket

Quellnetzwerk

Quellnode

Quellsocket

Daten der oberen Schichten

Die folgenden Definitionen erläutern die IPX-Paketfelder, diein Bild 29.4 gezeigt werden:

− Prüfsumme – Gibt an, daß die Prüfsumme nicht gebrauchtwird, wenn dieses 16-Bit-Feld auf 1s (FFFF) gesetzt wird.

− Paketlänge – Gibt die Länge eines kompletten IPX-Data-gramms in Byte an. IPX-Pakete können bis zur Größe derMedia Maximum Transmission Unit (MTU) jede Längehaben (es ist keine Paketfragmentierung erlaubt).

29.4:Ein NetWare-

IPX-Paketbesteht aus elf

Feldern


− Transportkontrolle – Zeigt die Anzahl von Routern, durchdie das Paket gelaufen ist. Erreicht dieser Wert 16, wird dasPaket abgelegt, weil davon ausgegangen wird, daß es zu ei-ner Routingschleife kommen könnte.

− Pakettyp – Bestimmt, welches Protokoll der oberen Schich-ten die Informationen des Pakets erhalten soll. Häufig ent-hält es einen dieser beiden Werte:

− 5: Gibt Sequenced Packet-Exchange (SPX) an.

− 17: Gibt NetWare Core Protocol (NCP) an.

− Zielnetzwerk, Zielknoten und Zielsocket – Spezifiziert dieZielinformationen.

− Quellnetzwerk, Quellknoten und Quellsocket – Spezifiziertdie Quellinformationen.

− Daten der oberen Schichten – Enthält Informationen überProzesse der oberen Schichten.

30 Protokolle der Open System Interconnection (OSI)

30.1 Hintergrund

Die Protokollsammlung für die Open System Interconnection(OSI) umfaßt eine Vielzahl von Standardprotokollen, die aufdem OSI-Referenzmodell basieren. Diese Protokolle sind Be-standteil eines internationalen Programms zur Entwicklungvon Datennetzwerkprotokollen und anderen Normen, die dasZusammenarbeiten von Geräten mehrerer Anbieter ermögli-chen. Das OSI-Programm erwuchs aus der Notwendigkeit fürinternationale Netzwerk-Normen und wurde entworfen, umdie Kommunikation zwischen Hardware- und Software-Systemen unabhängig von Unterschieden in der zugrunde-liegenden Architektur zu ermöglichen.

Die OSI-Spezifikationen wurden von zwei internationalenStandardisierungsorganisationen erdacht und umgesetzt: derInternational Organisation for Standardization (ISO) und derInternational Telecommunication Union-TelecommunicationStandardization Sector (ITU-T). Dieses Kapitel liefert eine Zu-sammenfassung der OSI-Protokollsammlung und veranschau-licht deren Zusammenhang mit dem allgemeinen OSI-Refe-renzmodell.

30.2 OSI-Netzwerkprotokolle

In der Bild 30.1 ist die gesamte OSI-Protokollsammlung sowiederen Beziehung zu den Schichten des OSI-Referenzmodellsdargestellt. Jede Komponente dieser Protokollsammlung wird

KAPITEL 30Protokolle der Open System Interconnection (OSI)


in diesem Kapitel kurz erläutert. Auf die OSI-Routing-Proto-kolle wird im Kapitel 39, »Routing-Protokolle für die OpenSystems Interconnection (OSI)«, genauer eingegangen.

Darstellung

Anwendung

Kommunikation

Transport

Datensicherung

Bitübertragung

OSI-Referenzmodell

OSI-Protokollsammlung

TPO TP1 TP2 TP4TP3

IEEE 802.3Hardware

Token RingHardware

FDDIHardware

X.25Hardware

Darstellungsdienst/Darstellungsprotokoll

IEEE802.2 IEEE 802.3

IEEE 802.5/Token Ring X.25 FDDI

Kommunikationsdienst/Kommunikationsprotokoll

CMIP DS FTAM MHS VTP

ACSE

ASES

ROSE RTSE CCRSE …

IS-ISNetzwerk

CONP/CMNS CLNP/CLNS

ES-IS

30.2.1 Physikalische Bitübertragungsschicht undDatensicherungsschicht von OSI

Die OSI-Protokollsammlung unterstützt zahlreiche Standard-protokolle für den Medienzugriff in der physikalischen Bit-übertragungsschicht und der Datensicherungsschicht. Diegroße Vielfalt der von der OSI-Protokollsammlung unterstütz-ten Protokolle für den Medienzugriff gestattet neben OSI eineinfaches Bestehen anderer Protokollsammlungen auf densel-ben Netzwerk-Medien. Zu den unterstützten Protokollen fürden Medienzugriff gehören IEEE 802.2 LLC, TokenRing/IEEE 802.5, Fiber Distributed Data Interface (FDDI)sowie X.25.

Bild 30.1:Die OSI-

Protokoll-sammlungführt eine

Abbildung aufjede Schicht

des OSI-Refe-renzmodells

durch

Kapitel 30 • Protokolle der Open System Interconnection (OSI) 409

30.2.2 OSI-Netzwerkschicht

Die OSI-Protokollsammlung bestimmt zwei Routing-Proto-kolle für die Netzwerkschicht: Endsystem-zu-Zwischensystem(ES-IS) und Zwischensystem-zu-Zwischensystem (IS-IS). Zu-sätzlich implementiert die OSI-Protokollsammlung zwei Artenvon Netzdiensten: den verbindungslosen sowie den verbin-dungsbezogenen Dienst.

Normen zu den OSI-Schichten

Zusätzlich zu den Normen, welche die Protokolle und Dienstefür die OSI-Netzwerkschicht festlegen, beschreiben folgendeDokumente andere Spezifikationen der OSI-Netzwerkschicht:

− ISO 8648 – Diese Norm definiert die interne Organisationder Netzwerkschicht (IONL), welche die Netzwerkschichtin drei voneinander getrennte Unterschichten unterteilt, umverschiedene Arten von Subnetzen zu unterstützen.

− ISO 8348 – Diese Norm definiert die Adressierung derNetzwerkschicht und beschreibt die von der OSI-Netz-werkschicht bereitgestellten verbindungsbezogenen undverbindungslosen Dienste.

− ISO TR 9575 – Diese Norm beschreibt den Rahmen, dieKonzepte und die Terminologie, die im Zusammenhang mitden OSI-Routing-Protokollen verwendet werden.

Verbindungsloser Netzdienst von OSI

Der verbindungslose Netzdienst von OSI ist mittels des Con-nectionless Network Protocol (CLNP) und des ConnectionlessNetwork Service (CLNS) implementiert. CLNP und CLNSsind in der ISO-Norm 8473 beschrieben.

Bei CLNP handelt es sich um ein OSI-Protokoll für die Netz-werkschicht, das Daten und Fehlerangaben aus darüberliegen-den Schichten über verbindungslose Anschlüsse überträgt.CLNP stellt die Schnittstelle zwischen dem ConnectionlessNetwork Service (CLNS) und den darüberliegenden Schichtenbereit.

CLNS stellt mittels CLNP Dienste der Netzwerkschicht für dieTransportschicht zur Verfügung.


CLNS baut weder eine Verbindung auf noch beendet er diese,da die Verbindungspfade für jedes über ein Netzwerk übermit-telte Paket unabhängig voneinander bestimmt werden. Damitsteht er im Gegensatz zum Connection-Mode Network Service(CMNS).

Außerdem sorgt CLNS für eine bestmögliche Zustellung, wasnichts anderes heißt, als daß es keine Garantie dafür gibt, daßDaten nicht verloren gehen, beschädigt, in die falsche Reihen-folge gebracht oder vervielfältigt werden. Für die Fehlererken-nung und -korrektur verläßt CLNS sich auf Protokolle für dieTransportschicht.

Verbindungsbezogener Netzdienst von OSI

Der verbindungsbezogene Netzdienst von OSI ist mittels desConnection-Oriented Network Protocol (CONP) und desConnection-Mode Network Service (CMNS) implementiert.

Bei CONP handelt es sich um ein OSI-Protokoll für die Netz-werkschicht, das Daten und Fehlerangaben aus darüberliegen-den Schichten über verbindungsbezogene Anschlüsse über-trägt. CONP basiert auf dem X.25 Packet-Layer Protocol(PLP) und ist in der ISO-Norm 8208, »X.25 Packet-LayerProtocol for DTE«, beschrieben.

CONP stellt die Schnittstelle zwischen CMNS und den dar-überliegenden Schichten bereit. Es handelt sich dabei um einenDienst der Netzwerkschicht, der als Schnittstelle zwischen derTransportschicht und CONP fungiert und in der ISO-Norm8878 beschrieben ist.

CMNS führt Funktionen durch, die mit der expliziten Einrich-tung von Verbindungspfaden zwischen kommunizierendenTransportschichteinheiten verbunden sind. Zu diesen Funk-tionen gehören der Aufbau, die Aufrechterhaltung und die Be-endigung der Verbindung. Weiterhin stellt CMNS im Gegen-satz zu CLNS einen Mechanismus bereit, der eine bestimmteDienstqualität (Quality of Service = QoS) anfordert.

Adressierung der Netzwerkschicht

Die Adressierung der OSI-Netzwerkschicht ist durch zweiArten von hierarchischen Adressen implementiert: Network


Service Access Point-Adressen (NSAP) und Network EntityTitles (NET).

Bei einem Network Service Access Point handelt es sich umeinen vorgestellten Punkt an der Grenze zwischen den Netz-werk- und Transportschichten. Der NSAP stellt denjenigenOrt dar, an dem der Transportschicht die OSI-Netzdienste zurVerfügung gestellt werden. Jeder Transportschichteinheit wirdein einzelner NSAP zugewiesen, der in einem OSI-Netzwerkmittels NSAP-Adressen individuell angesprochen wird.

Im Bild 30.2 ist der Aufbau der OSI-NSAP-Adresse darge-stellt, die einzelne NSAPs ausweist.

Selektor AFI

IDP DSP

StationIDI AreaAdreßverwaltung

NSAP-Adreßfelder

Es gibt zwei NSAP-Adreßfelder: den Initial Domain Part(IDP) und den Domain-Specific Part (DSP).

Das IDP-Feld ist in zwei Bestandteile unterteilt: den AuthorityFormat Identifier (AFI) und den Initial Domain Identifier(IDI). Der AFI stellt Informationen über den Aufbau und denInhalt des IDI- und des DSP-Felds bereit, beispielsweise dar-über, ob der IDI von variabler Länge ist und ob der DSP aufdie Dezimal- oder Binärnotation zurückgreift. Der IDI gibtdiejenige Einheit an, die dem DSP-Anteil der NSAP-AdresseWerte zuweisen kann.

Das Adreßfeld DSP ist von der für die Verwaltung zuständigenAuthority in vier Bestandteile unterteilt worden. Das Feld Ad-dress Administration ermöglicht eine weitergehende Verwal-tung der Adressierung, indem ein zweiter Authority-Identifierhinzugefügt und die Adreßverwaltung an eine Subauthoritydelegiert wird. Das Feld Area bezeichnet den spezifischen Be-reich innerhalb einer Domain und wird für Routingzweckeverwendet. Das Feld Station bezeichnet eine spezifische Sta-tion innerhalb eines Bereichs und wird ebenfalls für Routing-

Bild 30.2:Jeder Trans-portschicht-Einheit wirdeine OSI-NSAP-Adressezugewiesen


zwecke verwendet. Das Feld Selector stellt den spezifischen n-Selektor innerhalb einer Station bereit und wird wie schon dieübrigen Felder für Routingzwecke verwendet. Der reservierten-Selektor 00 bezeichnet die Adresse wie ein Network EntityTitle (NET).

NSAPs von Endsystemen

Ein OSI-Endsystem (ES) verfügt häufig über mehrere NSAP-Adressen; eine für jede der enthaltenen Transportschichtein-heiten. Ist dies der Fall, so unterscheidet sich die NSAP-Adresse jeder Transportschicht-Einheit üblicherweise nur imletzten Byte (n-Selektor genannt). Das Bild 30.3 stellt dieBeziehungen zwischen einer Transportschichteinheit, demNSAP und dem Netzdienst dar.

Transporteinheit

Netzdienst

Transportschicht

Netzwerkschicht

NSAP

Ein Network Entity Title (NET) wird verwendet, um dieNetzwerkschicht eines Systems zu identifizieren, ohne dasSystem mit einer bestimmten Transportschichteinheit zu ver-knüpfen (wie es eine NSAP-Adresse tut). NETs sind für dieAdressierung von Zwischensystemen (IS) wie beispielsweiseRouter hilfreich, die keine Schnittstelle mit der Transport-schicht besitzen. Ein IS kann über einen einzigen NET oderüber mehrere NETs verfügen, wenn es an mehreren Bereichenoder Domains beteiligt ist.

30.2.3 OSI-Protokolle für die Transportschicht

Die OSI-Protokollsammlung implementiert zwei Arten vonDiensten für die Transportschicht: verbindungsbezogeneTransportdienste und verbindungslose Transportdienste.

Bild 30.3:Der NSAP

stellt eine Ver-bindung zwi-

schen einerTransport-

schichteinheitund einemNetzdienst

bereit


In der OSI-Protokollsammlung gibt es fünf verbindungsbezo-gene Protokolle für die Transportschicht, und zwar vomTransportprotokoll der Klasse 0 (TP0) bis zum Transportpro-tokoll der Klasse 4 (TP4). Ein verbindungsloser Transport-dienst wird lediglich vom Transportprotokoll der Klasse 4 un-terstützt.

Das Transportprotokoll der Klasse 0 (TP0), das einfachsteOSI-Transportprotokoll, sorgt für eine Aufteilung und dasWiederzusammensetzen der Daten. Für TP0 ist ein verbin-dungsbezogener Netzdienst erforderlich.

Das Transportprotokoll der Klasse 1 (TP1) führt eine Auftei-lung und das Wiederzusammensetzen durch und bietet eineeinfache Fehlerbehebung. TP1 sorgt für eine Reihe von Proto-kolldateneinheiten (Protocol Data Unit = PDU) und überträgtdie PDUs erneut bzw. stellt erneut eine Verbindung her, fallseine übermäßige Anzahl von PDUs nicht bestätigt wird. FürTP1 ist ein verbindungsbezogener Netzdienst erforderlich.

Das Transportprotokoll der Klasse 2 (TP2) sorgt für eine Auf-teilung und das Wiederzusammensetzen sowie für das Multi-plexing und Demultiplexing der Datenströme über eine ein-zelne virtuelle Verbindung. Für TP2 ist ein verbindungsbezo-gener Netzdienst erforderlich.

Das Transportprotokoll der Klasse 3 (TP3) bietet eine einfacheFehlerbehebung, sorgt für eine Aufteilung und das Wiederzu-sammensetzen und führt weiterhin das Multiplexing undDemultiplexing der Datenströme über eine einzelne virtuelleVerbindung durch. TP3 sorgt für eine Reihe von PDUs undüberträgt diese erneut bzw. stellt erneut eine Verbindung her,falls eine übermäßige Anzahl nicht bestätigt wird. Für TP3 istein verbindungsbezogener Netzdienst erforderlich.

Das Transportprotokoll der Klasse 4 (TP4) bietet eine einfacheFehlerbehebung, sorgt für eine Aufteilung und das Wiederzu-sammensetzen und unterstützt das Multiplexing und Demul-tiplexing der Datenströme über eine einzelne virtuelle Verbin-dung. TP4 sorgt für eine Reihe von PDUs und überträgt dieseerneut bzw. stellt erneut eine Verbindung her, falls eine über-mäßige Anzahl nicht bestätigt wird. TP4 bietet sowohl verbin-dungsbezogenen als auch verbindungslosen Netzdiensten zu-verlässige Transportdienste und Funktionen. Es basiert auf


dem Transmission Control Protocol (TCP) der Sammlung vonInternet Protocols (IP) und stellt das einzige OSI-Protokoll dar,das verbindungslose Netzdienste unterstützt.

30.2.4 OSI-Protokolle für die Kommunikationsschicht

Die Implementierung der Kommunikationsschicht in der OSI-Protokollsammlung besteht aus einem Kommunikationspro-tokoll und einem Kommunikationsdienst (Session Service).Das Kommunikationsprotokoll ermöglicht es Benutzern desKommunikationsdienstes, sich mit dem Kommunikations-dienst zu verständigen. Bei dem Benutzer des Kommunika-tionsdienstes handelt es sich um eine Einheit, welche dieDienste der Kommunikationsschicht anfordert. Solche Anfor-derungen erfolgen an Session Service Access Points (SSAPs),die einen Zugriff auf den Kommunikationsdienst ermöglichen.Benutzer des Kommunikationsdienstes werden durch eineSSAP-Adresse eindeutig identifiziert. Im Bild 30.4 sind dieBeziehungen zwischen dem Benutzer des Kommunikations-dienstes, dem SSAP, dem Kommunikationsprotokoll und demKommunikationsdienst dargestellt.

Benutzer desKommunikationsdienst

Kommunikationsdienst

Kommunikationsprotokoll

Darstellungsschicht

Kommunikationsschicht

SSAP

Der Kommunikationsdienst stellt Benutzern des Dienstes viergrundlegende Dienste zur Verfügung. Erstens baut er Verbin-dungen zwischen Benutzern des Kommunikationsdienstes aufund ab und synchronisiert den Datenaustausch zwischen die-sen. Zweitens führt er verschiedene Verhandlungen für den

Bild 30.4:Funktionen der

Kommunika-tionsschicht

stellen denFunktionen der

Darstellungs-schicht ihre

Dienste übereinen SSAP zur

Verfügung


Einsatz von Tokens für die Kommunikationsschicht durch, dieder Benutzer des Kommunikationsdienstes besitzen muß, ummit dem Austausch beginnen zu können. Drittens fügt er Syn-chronisationsstellen in die übermittelten Daten ein, mit denenes möglich ist, die Arbeitssitzungen nach dem Auftreten vonFehlern oder Unterbrechungen wiederherzustellen. Undschließlich ermöglicht er es Benutzern des Kommunikations-dienstes, eine Arbeitssitzung zu unterbrechen und später zueinem bestimmten Zeitpunkt fortzusetzen.

Der Kommunikationsdienst ist in der ISO-Norm 8326 und derITU-T-Empfehlung X.215 definiert. Das Kommunikationspro-tokoll ist in der ISO-Norm 8327 und der ITU-T-EmpfehlungX.225 definiert. Eine verbindungslose Fassung des Kommuni-kationsprotokolls ist in der ISO-Norm 9548 definiert.

30.2.5 OSI-Protokolle für die Darstellungsschicht

Die Implementierung der Darstellungsschicht in der OSI-Pro-tokollsammlung besteht aus einem Darstellungsprotokoll undeinem Darstellungsdienst (Presentation Service). Das Darstel-lungsprotokoll ermöglicht es Benutzern des Darstellungsdien-stes, mit dem Darstellungsdienst zu kommunizieren.

Bei einem Benutzer des Darstellungsdienstes handelt es sichum eine Einheit, welche die Dienste der Darstellungsschichtanfordert. Solche Anforderungen finden an Presentation Ser-vice Access Points (PSAPs) statt, die einen Zugriff auf denDarstellungsdienst ermöglichen. Benutzer des Darstellungs-dienstes werden durch eine PSAP-Adresse eindeutig identifi-ziert.

Der Darstellungsdienst handelt die Übertragungssyntax ausund übersetzt die Daten in die bzw. aus der Übertragungssyn-tax für die Benutzer des Darstellungsdienstes, die die Daten inverschiedener Syntax darstellen. Der Darstellungsdienst wirdvon zwei Benutzern des Dienstes verwendet, um sich über diezu verwendende Übertragungssyntax zu verständigen. Sobaldman sich auf eine Übertragungssyntax geeinigt hat, müssen dieEinheiten des Darstellungsdienstes die vom Benutzer desDienstes stammenden Daten in die richtige Übertragungssyn-tax übersetzen.


Der Darstellungsdienst ist in der ISO-Norm 8822 und derITU-T-Empfehlung X.216 definiert. Das Darstellungsprotokollist in der ISO-Norm 8823 und der ITU-T-Empfehlung X.226definiert. Eine verbindungslose Fassung des Darstellungspro-tokolls ist in der ISO-Norm 9576 definiert.

30.2.6 OSI-Protokolle für die Anwendungsschicht

Die Implementierung der Anwendungsschicht in der OSI-Pro-tokollsammlung besteht aus verschiedenen Anwendungsein-heiten. Bei einer Anwendungseinheit handelt es sich um den-jenigen Teil eines Anwendungsprozesses, der für den Einsatzder OSI-Protokollsammlung von Bedeutung ist. Eine Anwen-dungseinheit setzt sich aus dem Benutzerelement und einemElement des Anwendungsdienstes (Application Service Ele-ment = ASE) zusammen.

Bei dem Benutzerelement handelt es sich um denjenigen Teil einerApplikationseinheit, der auf ASEs zurückgreift, um die für denAnwendungsprozeß notwendige Kommunikation zu betreiben.Bei dem ASE handelt es sich um denjenigen Teil einer Applika-tionseinheit, der Benutzerelementen – und somit auch Anwen-dungsprozessen – Dienste zur Verfügung stellt. ASEs stellenweiterhin Schnittstellen für die darunterliegenden OSI-Schichtenbereit. Im Bild 30.5 sind die Zusammensetzung eines einzelnenAnwendungsprozesses (bestehend aus der Anwendungseinheit,dem Benutzerelement und den ASEs) sowie dessen Beziehungenzum PSAP und dem Darstellungsdienst dargestellt.

Anwendungsschicht

Außerhalb derOSI-Umgebung

OSI-Umgebung

Darstellungsschicht

PSAP

Darstellungsdienst

CASEs

Benutzerelement

ASEs

Anwendungseinheit

Application Process

SASEs

Bild 30.5:Ein Anwen-

dungsprozeßberuht auf demPSAP und dem

Darstellungs-dienst


Ein ASE läßt sich einer der folgenden beiden Klassifizierungenzuordnen: Entweder handelt es sich um ein allgemeines(Common Application Service Element = CASE) oder um einbestimmtes Element eines Anwendungsdienstes (SpecificApplication Service Element = SASE). Beide können in einereinzigen Anwendungseinheit vorkommen.

Allgemeine Elemente eines Anwendungsdienstes (CASEs)

Bei CASEs handelt es sich um ASEs, die von einer großen Viel-falt von Anwendungsprozessen verwendete Dienste zur Verfü-gung stellen. Häufig macht eine einzige Anwendungseinheitvon mehreren CASEs Gebrauch. Die folgenden vier CASEssind in der OSI-Spezifikation definiert:

− Association Control Service Element (ACSE) – Erstellt alsVorbereitung für eine Kommunikation von Anwendung zuAnwendung Verknüpfungen zwischen zwei Anwendungs-einheiten.

− Remote Operations Service Element (ROSE) – Implemen-tiert einen Request-Response-Mechanismus, der verschie-dene entfernte Operationen über eine durch das ACSE auf-gebaute Anwendungsverknüpfung zuläßt.

− Reliable Transfer Service Element (RTSE) – Ermöglicht esASEs, Nachrichten zuverlässig zu übertragen, wobei dieTransparenz komplexer Einrichtungen tieferliegenderSchichten erhalten bleibt.

− Commitment, Concurrence and Recovery Service Elements(CCRSE) – Koordiniert Dialoge zwischen mehreren An-wendungseinheiten.

Bestimmte Elemente eines Anwendungsdienstes (SASEs)

Bei SASEs handelt es sich um ASEs, die Dienste zur Verfügungstellen, welche nur von einem bestimmten Anwendungsprozeßverwendet werden, beispielsweise bei der Dateiübertragung,beim Datenbankzugriff oder beim Befehlseingang.


OSI-Protokolle für Anwendungsprozesse

Bei einem Anwendungsprozeß handelt es sich um dasjenigeElement einer Anwendung, das die Schnittstelle zwischen derAnwendung selber und der OSI-Anwendungsschicht bereit-stellt. Zu den standardmäßigen OSI-Anwendungsprozessengehören folgende:

− Common Management Information Protocol (CMIP) –Führt Funktionen der Netzwerkverwaltung durch, die denAustausch von Verwaltungsinformationen zwischen Endsy-stemen (ES) und Verwaltungsrechnern ermöglichen. CMIPist in der ITU-T-Empfehlung X.700 spezifiziert und ähneltvon der Funktion her dem Simple Network ManagementProtocol (SNMP) und NetView.

− Directory Services (DS) – Dient als verteiltes Verzeichnis,das innerhalb von OSI-Netzwerken für die Identifikationund Adressierung von Knoten verwendet wird. DS ist inder ITU-T-Empfehlung X.500 spezifiziert.

− File Transfer, Access and Management (FTAM) – Stellt ei-nen Dateiübertragungsdienst und Einrichtungen für einenverteilten Dateizugriff bereit.

− Message Handling System (MHS) – Stellt unter Verwen-dung von ansammelnden und weiterleitenden Diensten ei-nen Übermittlungsmechanismus für elektronische Messa-ging-Anwendungen und andere Anwendungen bereit.

− Virtual Terminal Protocol (VTP) – Stellt eine Terminalemu-lation bereit, die es einem Computersystem ermöglicht, ei-nem entfernten Endsystem als direkt angebundenes Termi-nal zu erscheinen.

31 Banyan VINES

31.1 Hintergrund

Banyan Virtual Integrated Network Service (VINES) imple-mentiert ein verteiltes Netzwerkbetriebssystem, das auf einerproprietären Protokollfamilie basiert, die von den Protokollendes Xerox Network System (XNS) der Xerox Corporationabgeleitet ist. VINES greift auf eine Client-Server-Architekturzurück, in der die Clients bestimmte Dienste wie beispielsweiseden Zugriff auf Dateien und Drucker von den Servern anfor-dern. In diesem Kapitel erfolgt eine Zusammenfassung derVINES-Kommunikationsprotokolle. Der VINES-Protokoll-stack ist im Bild 31.1 dargestellt.

Dateidienste Druckerdienste StreetTalk AndereAnwendungen

RPC

IPC(Datagramm)

SPP(Stream)

VIP

ARP

RTP

ICP

VINES-Protokoll

OSI-Referenz-modell

7

5

4

3

6

21

Protokolle für den Medienzugriff

KAPITEL 31Banyan VINES

Bild 31.1:Der VINES-Protokollstacksetzt sich ausfünf voneinan-der getrenntenSchichten zu-sammen


31.2 Medienzugriff

Die unteren beiden Schichten des VINES-Stack sind durch eineVielzahl bekannter Mechanismen für den Zugriff auf Medienimplementiert, zu denen High Level Data Link Control(HDLC), X.25, Ethernet und Token-Ring zählen.

31.3 Netzwerkschicht

VINES verwendet das VINES Internetwork Protocol (VIP),um Schicht-3-Handlungen (einschließlich Netzwerkrouting)auszuführen. Weiterhin unterstützt VINES sein eigenes Ad-dress Resolution Protocol (ARP), seine eigene, Routing TableProtocol (RTP) genannte Fassung des Routing InformationProtocol (RIP) sowie das Internet Control Protocol (ICP), daseine Exceptionbehandlung und besondere Informationen fürden Aufwand beim Routing bereitstellt. ARP-, ICP- und RTP-Pakete werden in einem VIP-Header gekapselt.

31.3.1 VINES Internetwork Protocol (VIP)

Bei den Adressen der VINES-Netzwerkschicht handelt es sichum Einheiten zu 48 Bit, die sich auf Anteile für das Netzwerk(32 Bit) und das Subnetz (16 Bit) verteilen. Die Netzwerk-nummer wird besser als eine Server-Nummer bezeichnet, dasie direkt vom Schlüssel (einem Hardware-Modul, das eineeindeutige Nummer sowie die Software-Optionen für diesenServer ausweist) des Servers abgeleitet ist. Der Anteil einerVINES-Adresse für das Subnetz wird besser als eine Host-Nummer bezeichnet, da er für die Identifizierung von Hosts ineinem VINES-Netzwerk verwendet wird. Im Bild 31.2 ist dasVINES-Adreßformat dargestellt.

Netzwerknummer Subnetznummer

(Hostnummer)(Servernummer)

1 32 33 48

Die Netzwerk-Nummer identifiziert ein logisches VINES-Netzwerk, das als ein Baum mit zwei Ebenen dargestellt wird,wobei ein Dienstknoten die Wurzel bildet. Dienstknoten, bei

Bild 31.2:Eine VINES-Adresse setztsich aus einer

Netzwerk-Nummer und

einer Subnetz-nummer zu-

sammen

Kapitel 31 • Banyan VINES 421

denen es sich üblicherweise um Server handelt, stellen Dienstezum Auflösen von Adressen und zum Routing für Clients be-reit, welche die Blätter des Baums darstellen. Der Dienstkno-ten weist Clients VIP-Adressen zu.

Sobald ein Client eingeschaltet wird, überträgt er einenRequest an Server, und alle Server, die diesen Request mitbe-kommen, reagieren darauf. Der Client greift das erste Re-sponse-Paket (Antwort/Reaktion) auf und ersucht um eineSubnetz- bzw. Hostadresse von diesem Server. Der Server ant-wortet mit einer Adresse, die aus seiner eigenen (von seinemSchlüssel abgeleiteten) Netzwerk-Adresse zusammen mit einervon ihm gewählten Subnetzadresse besteht. Subnetzadressenfür Clients werden üblicherweise bei 80001H beginnend auf-einanderfolgend zugewiesen. Die Subnetzadresse des Serversist immer 1. Im Bild 31.3 ist der Vorgang der VINES-Adreß-ermittlung dargestellt.

Die dynamische Adreßzuweisung ist in der Wirtschaft nichteinzigartig (auch AppleTalk geht auf diese Weise vor), aber sieist sicherlich nicht so verbreitet wie die statische Adreßzuwei-sung.

Da Adressen exklusiv von einem bestimmten Server ausge-wählt werden (dessen Adresse aufgrund des Hardware-Schlüs-sels einzigartig ist), ist die Gefahr einer mehrfachen Adreßver-gabe äußerst gering. Hierbei kann man von Glück sprechen,weil eine mehrfache Adreßvergabe für das Internet Protocol(IP) und andere Netzwerke möglicherweise verheerende Fol-gen nach sich ziehen kann.

Im VINES-Netzwerk-Schema stellen alle Server mit mehrerenSchnittstellen im wesentlichen Router dar. Clients wählenimmer ihren eigenen Server als Router für den ersten Hop(Sprung), selbst dann, wenn ein anderer Server auf demselbenKabel eine bessere Route zum letztendlichen Ziel bereitstellt.Clients können von anderen Routern erfahren, indem sieRedirect-Nachrichten von ihrem eigenen Server erhalten. DaClients beim Routing für den ersten Hop auf ihren Serverangewiesen sind, unterhalten VINES-Server Routing-Tabellen,um ihnen beim Ausfindigmachen entfernter Knoten behilflichzu sein.


Client Server 1 Server 2




IrgendwelcheServer?

Ich bin da Ich bin da

Server 1: Bitteweise mir eine

Adresse zu

Deine Adresselautet:

Server 1, Node 8001

1

2

3

4

VINES-Routing-Tabellen bestehen aus Host/Aufwand-Paaren,wobei der Host einem erreichbaren Netzknoten und Aufwandeiner zum Erreichen des Knotens benötigten Verzögerung (inMillisekunden) entspricht. RTP unterstützt VINES-Server da-bei, benachbarte Clients, Server und Router ausfindig zu ma-chen.

Regelmäßig machen Clients sowohl die Adresse ihrer Netz-werkschicht als auch ihrer MAC-Schicht mit der Entsprechungeines Hello-Pakets bekannt, mit dem angezeigt wird, daß derClient noch immer in Betrieb ist und für das Netzwerk bereit-steht. Die Server wiederum verschicken regelmäßig Routing-Updates an andere Server, um andere Router auf geänderteKnotenadressen und Änderungen in der Netzwerk-Topologieaufmerksam zu machen.

Bild 31.3:VINES durch-

läuft für dieErmittlung

einer Adressevier Schritte


Wenn ein VINES-Server ein Paket erhält, prüft er nach, ob dasPaket für einen anderen Server bestimmt ist oder ob es sichum einen Broadcast handelt. Wenn der aktuelle Server das Zielist, behandelt der Server den Request entsprechend. Wenn einanderer Server das Ziel ist, schickt der Server das Paket ent-weder direkt weiter (wenn es sich bei dem Server um einenNachbarn handelt) oder er leitet es an den nächsten Serverweiter. Wenn es sich bei dem Paket um einen Broadcast han-delt, überprüft der Server, ob das Paket über die günstigsteRoute angekommen ist. Falls nicht, wird das Paket verworfen.Falls ja, wird das Paket über alle Schnittstellen außer derjeni-gen weitergeschickt, an der es angekommen ist. Dieses Vorge-hen hilft dabei, die Anzahl von Broadcaststürmen zu verrin-gern, die in anderen Netzwerk-Umgebungen ein übliches Pro-blem darstellen. Der VINES-Routing-Algorithmus ist im Bild31.4 dargestellt.

für den Nachbarbestimmt

VIP-Adresse des Ziels überprüfen

für die weitereBearbeitung an die

Transportschichtübergeben

Paket ist für diesen Server gedacht

Weder dieser Servernoch ein Broadcast

Broadcast-adresse

VIP-Adresse der Quelle nachsehen

Paket auf dem günstigstenWeg erhalten?

Nein

nächsten Hopin der Routing-

tabelle aus-findig machen

an den Nachbarnweiterschicken

an dennächsten Hopweiterschicken

Paketverwerfen

Ja

an die Transportschichtübergeben, den Hop-Countverringern und erneut überalle Schnittstellen außer

derjenigen versenden, von der das Paket kam

E N D E

Nein Ja

Bild 31.4:Der VINES-Routing-Algo-rithmus legtden geeignetenPfad zu einemZiel fest


In Bild 31.5 ist das Format des VIP-Pakets dargestellt.

Feldlänge in Byte

Trans-port-

kontrolle

Proto-koll-typ

Netzwerk-nummer

der Quelle

Prüf-summe

2 11 Variabel

Paket- länge

2

Netzwerk-nummerdes Ziels

4

Subnetz-nummerdes Ziels

4

Subnetz-nummer

der Quelle

2

Daten

2

Zu den Feldern eines VIP-Pakets gehören eine Prüfsumme,Paketlänge, Transportkontrolle, Protokollart, Netzwerknum-mer des Ziels, Subnetznummer des Ziels, Netzwerknummerder Quelle und die Subnetznummer der Quelle.

Das Feld Prüfsumme wird verwendet, um Beschädigungen amPaket festzustellen. Das Feld Paketlänge gibt den Umfang desgesamten VIP-Pakets an.

Das Feld Transportkontrolle setzt sich aus mehreren Teilfel-dern zusammen. Wenn es sich bei dem Paket um ein Broad-cast-Paket handelt, dann gibt es zwei Teilfelder: Klasse (Bit 1bis 3) und Hop-Count (Bit 4 bis 7). Wenn es sich nicht um einBroadcast-Paket handelt, dann stehen vier Teilfelder zur Ver-fügung: Fehler, Metrik, Redirect und Hop-Count. Das TeilfeldKlasse gibt die Art des Knotens an, der den Broadcast empfan-gen soll. Zu diesem Zweck werden Knoten entsprechend derArt des Knotens und der Verbindung, in welcher der Knotengefunden wurde, in verschiedene Kategorien unterteilt. Durchdie Angabe der Art von Knoten für den Empfang der Broad-casts reduziert das Teilfeld Klasse die durch Broadcasts ver-ursachten Störungen. Das Teilfeld Hop-Count steht für dieAnzahl von Hops (Routern), die das Paket durchlaufen mußte.Das Teilfeld Fehler gibt an, ob das ICP-Protokoll ein Excep-tion-Notification-Paket an die Paketquelle schicken soll, fallssich ein Paket als unzustellbar erweist. Das Teilfeld Metrikwird von einer Transporteinheit auf eins gesetzt, sofern sie et-was über den Routingaufwand für das Bewegen von Paketenzwischen einem Dienstknoten und einem Nachbarn erfahrenmuß. Das Teilfeld Redirect gibt an, ob der Router gegebenen-falls ein Redirect erzeugen soll.

Das Feld Protokollart gibt das Protokoll der Netzwerk- oderTransportschicht an, für welches das Metric- oder das Excep-tion-Notification-Paket bestimmt ist.

Bild 31.5:Ein VIP-Paket

setzt sich ausneun Einzel-

feldernzusammen


Schließlich stellen die Felder Netzwerknummer des Ziels, Sub-netznummer des Ziels, Netzwerknummer der Quelle undSubnetznummer der Quelle alle eine VIP-Adresse bereit.

31.3.2 Routing Table Protocol (RTP)

RTP stellt Informationen über die Netzwerk-Topologie zurVerfügung. Sowohl von Clients als auch von Dienstknotenwerden regelmäßig Routing-Update-Pakete übertragen. DiesePakete informieren Nachbarn über das Vorhandensein einesKnotens und zeigen außerdem an, ob es sich bei dem Knotenum einen Client oder einen Dienstknoten handelt. Dienstkno-ten schließen in jedem Routing-Update-Paket eine Auflistungsämtlicher bekannter Netzwerke sowie die Aufwandsfaktorenmit ein, die mit dem Erreichen jener Netzwerke verbundenensind.

Es werden zwei Tabellen geführt: eine Tabelle aller bekanntenNetzwerke und eine Nachbartabelle. Für Dienstknoten enthältdie Tabelle aller bekannten Netzwerke mit Ausnahme des ei-genen Netzwerks des Dienstknotens einen Eintrag für jedesbekannte Netzwerk. Jeder Eintrag besteht aus einer Netzwerk-nummer, einer Routing-Metrik und einem Zeiger auf denEintrag für den nächsten Hop im Netzwerk aus der Tabelleder Nachbarn. Die Tabelle der Nachbarn enthält für jeden be-nachbarten Dienstknoten und Clientknoten jeweils einen Ein-trag. Die Einträge bestehen aus einer Netzwerknummer, einerSubnetznummer, dem für das Erreichen dieses Knotens ver-wendeten Protokoll für den Medienzugriff (beispielsweiseEthernet), einer LAN-Adresse (sofern es sich bei dem denNachbar anbindenden Medium um ein Local Area Networkhandelt) und einer Metrik für den Nachbarn.

RTP spezifiziert vier Pakettypen: Routing-Update, Routing-Request, Routing-Response und Routing-Redirect. Routing-Updates werden regelmäßig abgesetzt, um das Vorhandenseinvon Nachbarn einer Einheit mitzubekommen. Routing-Requests werden von Einheiten ausgetauscht, wenn sie dieNetzwerk-Topologie schnell erfahren müssen. Routing-Response-Pakete enthalten Informationen über die Topologieund werden von Dienstknoten verwendet, um auf Routing-Request-Pakete zu reagieren. Ein Routing-Redirect-Paket stellt


Knoten, die ungünstige Routen verwenden, bessere Routenin-formationen zur Verfügung.

RTP-Pakete besitzen einen 4 Byte großen Header, der sich ausfolgenden Feldern zu je 1 Byte zusammensetzt: Das Feld Be-triebsart gibt den Pakettyp an; das Feld Knotenart gibt an, obdas Paket von einem Dienstknoten oder einem Nicht-Dienst-knoten stammt; das Feld Controllerart gibt an, ob der Con-troller des das RTP-Paket übermittelnden Knotens über einenMultibuffer-Controller verfügt; das Feld Rechnerart gibt an,ob der Prozessor des RTP-Senders schnell oder langsam ist.

Die Felder Controllerart und Rechnerart werden für dasPacing eingesetzt.

31.3.3 Address Resolution Protocol (ARP)

Das Address Resolution Protocol (ARP) verwendende Einhei-ten werden entweder als Adressen auflösende Clients oder alsAdressen auflösende Dienste klassifiziert. Adressen auflösendeClients sind üblicherweise auf Clientknoten implementiert,wohingegen Adressen auflösende Dienste typischerweise vonDienstknoten bereitgestellt werden.

ARP-Pakete besitzen einen 8 Byte großen Header, der sich auseinem 2 Byte großen Pakettyp, einer 4 Byte großen Netzwerk-nummer und einer 2 Byte großen Subnetznummer zusam-mensetzt. Es gibt vier Pakettypen: ein Query-Request forderteinen ARP-Dienst an; mit einer Service-Response wird aufeinen Query-Request reagiert; ein Assignment-Request wirdan einen ARP-Dienst geschickt, um eine VINES-Netzwerk-Adresse anzufordern; und eine Assignment-Response wirdvom ARP-Dienst als Reaktion auf den Assignment-Requestverschickt. Die Felder für die Netzwerk-Nummer und dieSubnetznummer sind nur in einem Assignment-Response-Paket von Bedeutung.

ARP-Clients und -Dienste implementieren folgenden Algo-rithmus beim Hochfahren eines Client. Zuerst überträgt derClient Query-Request-Pakete. Darauf reagiert jeder mit demClient benachbarte Dienst mit einem Service-Response-Paket.Anschließend setzt der Client ein Assignment-Request-Paketan den ersten Dienst ab, der auf sein Query-Request-Paket ge-


antwortet hat. Der Dienst reagiert mit einem Assignment-Re-sponse-Paket, das die zugewiesene Netzwerk-Adresse enthält.

31.3.4 Internet Control Protocol (ICP)

Das Internet Control Protocol (ICP) spezifiziert die Exception-Notification- und Metric-Notification-Pakete. Exception-Notification-Pakete stellen Informationen über Exceptions derNetzwerk-Schicht zur Verfügung; Metric-Notification-Paketeenthalten Informationen über die abschließende zum Errei-chen eines Client-Knotens verwendete Übermittlung.

Exception-Notifications werden verschickt, wenn ein VIP-Paket nicht richtig weitergeleitet werden kann und das TeilfeldFehler im Feld Transportkontrolle des VIP-Headers aktiviertist. Diese Pakete enthalten außerdem ein Feld, das die jeweiligeException mittels ihres Fehlercodes ausweist.

ICP-Einheiten in Dienstknoten erzeugen dann Metric-Notifi-cation-Nachrichten, wenn das Teilfeld Metrik im Feld Trans-portkontrolle des VIP-Header aktiviert ist und die Zieladresseim Paket des Dienstknotens einen Nachbarn des Dienstkno-tens angibt.

31.4 Transportschicht

VINES stellt drei Dienste für die Transportschicht zur Verfü-gung: den Unreliable Datagram Service, den Reliable MessageService und den Data Stream Service.

Der Unreliable Datagram Service (nicht zuverlässige Data-gramme versendender Dienst) verschickt Pakete, die so gutwie möglich weitergeleitet, am Ziel aber nicht bestätigt wer-den.

Beim Reliable Message Service (zuverlässige Nachrichten ver-sendender Dienst) handelt es sich um einen virtuellen Verbin-dungsdienst, der für eine zuverlässige und bestätigte Zustel-lung von Nachrichten zwischen Netzknoten sorgt. Eine zuver-lässige Nachricht kann in maximal vier VIP-Paketen übermit-telt werden.

Der Data Stream Service (Datenstrom versendender Dienst)unterstützt einen kontrollierten Datenfluß zwischen zwei Pro-


zessen. Beim Data Stream Service handelt es sich um einen be-stätigten virtuellen Verbindungsdienst, der die Übermittlungvon Nachrichten mit unbegrenztem Umfang unterstützt.

31.5 Protokolle übergeordneter Schichten

Als verteiltes Netzwerk greift VINES für die Kommunikationzwischen Clients und Servern auf das Remote Procedure Call-Protokoll (RPC) zurück. RPC ist die Grundlage von Umge-bungen mit verteilten Diensten. Das NetRPC Protocol(Schichten 5 und 6) stellt eine hochwertige Programmierspra-che zur Verfügung, die einen Zugriff auf entfernte Dienste ge-stattet, der sowohl für den Benutzer als auch für die Anwen-dung transparent ist.

Auf der Schicht 7 stellt VINES neben Anwendungen für denDateidienst und Druckerdienst auch StreetTalk zur Verfügung,das einen global konsistenten Namensdienst für ein vollstän-diges Internetzwerk bereitstellt.

VINES stellt außerdem für verschiedene Betriebssysteme wiebeispielsweise DOS und UNIX eine integrierte Entwicklungs-umgebung für Anwendungen zur Verfügung. Diese Entwick-lungsumgebung ermöglicht es Fremdanbietern, sowohl Clientsals auch Dienste zu entwickeln, die in der VINES-Umgebunglaufen.

32 Xerox Network Systems (XNS)

32.1 Hintergrund

Die Protokolle des Xerox Network Systems (XNS) wurden inden späten 1970er und frühen 1980er Jahren von der XeroxCorporation entwickelt. Sie wurden für den Einsatz mit einerVielzahl von Kommunikationsmedien, Prozessoren und Büro-anwendungen entworfen. Mehrere XNS-Protokolle ähnelndem Internet Protocol (IP) und dem Transmission ControlProtocol (TCP), die von der Defense Advanced Research Pro-jects Agency (DARPA) für das U.S. Department of Defenseentwickelt wurden.

Wegen seiner Verfügbarkeit und seiner frühen Markteinfüh-rung wurde XNS von den meisten der frühen LAN-Firmenwie beispielsweise Novell, Inc., Ungermann-Bass, Inc. (jetzt einTeil von Tandem Computers) und 3Com Corporation aufge-griffen. Seitdem hat jede dieser Firmen verschiedene Änderun-gen an den XNS-Protokollen vorgenommen. Novell fügte dasService Advertisement Protocol (SAP) hinzu, um Ressourcenbekanntmachen zu können und modifizierte die OSI-Proto-kolle der Schicht 3 (die Novell in IPX für Internetwork PacketExchange umbenannte), damit sie mit IEEE-802.3- stattEthernet-Netzwerken laufen. Ungermann-Bass modifizierteRIP, damit sowohl Verzögerung als auch Hop-Count unter-stützt werden, und führte weitere kleinere Änderungen durch.Mit der Zeit wurde die XNS-Implementierung für die Arbeitmit PC-Netzwerken beliebter als das XNS, wie es von Xeroxentworfen wurde. Dieses Kapitel liefert eine Zusammen-

KAPITEL 32Xerox Network Systems (XNS)


fassung des XNS-Protokollstacks im Zusammenhang mit demOSI-Referenzmodell.

32.2 Übersicht über die XNS-Hierarchie

Obwohl die Entwurfziele bei XNS mit denen des OSI-Refe-renzmodells übereinstimmen, unterscheidet sich das XNS-Konzept einer Protokollhierarchie doch etwas von der durchdas OSI-Referenzmodell bereitgestellten wie es Bild 32.1 ver-deutlicht.

Wie im Bild 32.1 dargestellt, liefert Xerox ein 5-Schichten-Modell der Paketkommunikation. Schicht 0 entspricht grobden OSI-Schichten 1 und 2, die für den Zugriff auf die Ver-bindung und die Beeinflussung des Bitstroms zuständig sind.Schicht 1 entspricht grob dem Anteil der OSI-Schicht 3, derden Netzwerkverkehr betrifft. Schicht 2 entspricht dem Anteilder OSI-Schicht 3, der das Routing im Internetzwerk betrifft,sowie der OSI-Schicht 4, die für die Kommunikation der Pro-zesse untereinander zuständig ist. Die Schichten 3 und 4 ent-sprechen grob den oberen beiden Schichten des OSI-Modells,die für die Strukturierung der Daten, die Interaktion von Pro-zeß zu Prozeß sowie die Anwendungen zuständig sind. XNSverfügt über kein Protokoll, das der OSI-Schicht 5 (die Kom-munikationsschicht) entspricht.

OSI

Anwendung

Darstellung

Kommunikation

Transport

Datensicherung

Bitübertragung

Internetworking

Netzwerk

Schicht 4+

Schicht 3

Schicht 2

Schicht 1

Schicht 0

XNS

7

6

5

4

3

2

1

Bild 32.1:Xerox ent-

schied sich fürein 5-Schich-

ten-Modell derPaketkom-munikation

Kapitel 32 • Xerox Network Systems (XNS) 431

32.3 Medienzugriff

Obwohl die XNS-Dokumentation X.25, Ethernet und HighLevel Data Link Control (HDLC) erwähnt, definiert XNSnicht ausdrücklich, auf welches Protokoll für die Schicht 0sich das System bezieht. Wie viele andere Protokollsammlun-gen auch, läßt XNS die Frage nach dem Medienzugriff offen,wobei implizit beliebige solcher Protokolle für den Transportvon XNS-Paketen über ein physikalisches Medium zugelassensind.

32.4 Netzwerkschicht

Das XNS-Protokoll für die Netzwerkschicht heißt InternetDatagram Protocol (IDP). IDP führt standardmäßige Schicht-3-Funktionen durch, wozu die logische Adressierung sowie dieDatagrammzustellung von Endsystem zu Endsystem über einInternetzwerk gehören. Im Bild 32.2 ist das Format für einIDP-Paket dargestellt.

A B C D E F G H I J Daten

2 2 1 1 4 6 2 4 6 2 0-546Feldlänge in Byte

ABCDEFGHIJ

= Prüfsumme= Länge= Transportkontrolle= Pakettyp= Netzwerknummer des Ziels= Hostnummer des Ziels= Socketnummer des Ziels= Netzwerknummer der Quelle= Hostnummer der Quelle= Socketnummer der Quelle

Im folgenden werden die im Bild 32.2 dargestellten Feldereines IDP-Pakets zusammenfassend beschrieben:

− Prüfsumme – Ein 16 Bit großes Feld, das beim Einschätzender Integrität des Pakets hilft, nachdem es das Internetz-werk durchquert hat.

− Länge – Ein 16 Bit großes Feld, das den Gesamtumfang(einschließlich der Prüfsumme) des aktuellen Datagrammsenthält.

Bild 32.2:Ein IDP-Paketbesteht aus elfFeldern


− Transportkontrolle – Ein 8 Bit großes Feld, das die Teilfel-der Hop-Count und maximale Paketlebensdauer (MPL)enthält. Das Teilfeld Hop-Count wird von der Quelle mit 0initialisiert und jedesmal um eins erhöht, wenn das Data-gramm einen Router durchläuft. Sobald das Feld Hop-Count den Wert 16 erreicht, wird das Datagramm in derAnnahme verworfen, daß eine Schleife beim Routing aufge-treten ist. Das Teilfeld MPL enthält die maximal zur Verfü-gung stehende Zeit (in Sekunden), die ein Paket im Inter-netzwerk verbleiben kann.

− Pakettyp – Ein 8 Bit großes Feld, welches das Format desDatenfelds angibt.

− Netzwerknummer des Ziels – Ein 32 Bit großes Feld, wel-ches das Zielnetzwerk in einem Internetzwerk eindeutigausweist.

− Hostnummer des Ziels – Ein 48 Bit großes Feld, welchesden Ziel-Host eindeutig ausweist.

− Socketnummer des Ziels – Ein 16 Bit großes Feld, welcheseinen Socket (Prozeß) innerhalb des Ziel-Host eindeutigausweist.

− Netzwerknummer der Quelle – Ein 32 Bit großes Feld,welches das Quellnetzwerk in einem Internetzwerk eindeu-tig ausweist.

− Hostnummer der Quelle – Ein 48 Bit großes Feld, welchesden Quell-Host eindeutig ausweist.

− Socketnummer der Quelle – Ein 16 Bit großes Feld, wel-ches einen Socket (Prozeß) innerhalb des Quell-Host ein-deutig ausweist.

IEEE-802-Adressen sind äquivalent zu Host-Nummern, sodaß Hosts, die an mehr als ein IEEE-802-Netzwerk angebun-den sind, über dieselbe Adresse in jedem Segment verfügen.Dadurch werden Netzwerknummern zwar redundant, sie blei-ben aber für das Routing hilfreich. Bestimmte Socketnummernsind bekannt, was zur Folge hat, daß der Dienst fest definiertist, der von der Software ausgeführt wird, die auf diese Num-mern zurückgreift. Alle weiteren Socketnummern sind wieder-verwendbar.


XNS unterstützt die Kapselung Ethernet Version 2.0 fürEthernet und drei Arten der Kapselung für Token Ring:3Com, SubNet Access Protocol (SNAP) und Ungermann-Bass.

XNS unterstützt Unicast-Pakete (Punkt-zu-Punkt), Multicast-Pakete (Mehrpunkt-zu-Mehrpunkt) und Broadcast-Pakete(Punkt-zu-Mehrpunkt). Multicast- und Broadcast-Adressenwerden weiterhin in gelenkte und globale Typen unterteilt.Gelenkte Multicasts stellen allen Mitgliedern einer Multicast-Gruppe in demjenigen Netzwerk Pakete zu, das in der Netz-werk-Adresse des Ziel-Multicast angegeben ist. GelenkteBroadcasts stellen allen Mitgliedern eines angegebenen Netz-werks Pakete zu. Globale Multicasts stellen allen Mitgliedernder Gruppe im gesamten Internetzwerk Pakete zu, währendglobale Broadcasts allen Internetzwerk-Adressen Pakete zu-stellen. Ein Bit in der Hostnummer unterscheidet eine Unicast-von einer Multicast-Adresse. Im Gegensatz dazu weist ein mitEinsen gefülltes Feld für die Host-Adresse auf eine Broadcast-Adresse hin.

Um Pakete in einem Internetzwerk zu routen, greift XNS aufdas dynamische Routing-Schema von RIP zurück. Derzeitstellt RIP das am häufigsten verwendete Interior GatewayProtocol (IGP) in der Internet-Gemeinschaft dar. Weitere In-formationen über das RIP finden Sie im Kapitel 42, »RoutingInformation Protocol (RIP)«.

32.5 Transportschicht

Die Funktionen der OSI-Transportschicht werden durch ver-schiedene Protokolle implementiert. Jedes der folgenden Pro-tokolle ist in der XNS-Spezifikation als ein Schicht-2-Proto-koll beschrieben.

Das Sequenced Packet Protocol (SPP) bietet eine zuverlässige,verbindungsorientierte, ablaufkontrollierte Paketübertragungim Auftrag von Client-Prozessen. Von der Funktionalität herähnelt es dem Transmission Control Protocol (TCP) der Inter-net-Protokollsammlung (IP) und dem Transport Protocol 4(TP4) der OSI-Protokollsammlung. Weitere Informationen zuTCP finden Sie in Kapitel 28, »Internet-Protokolle«. WeitereInformationen zu TP4 finden Sie in Kapitel 30, »Protokolleder Open System Interconnection (OSI)«.


Jedes SPP-Paket enthält eine Sequenznummer, die verwendetwird, um die Pakete zu sortieren und festzustellen, ob irgend-welche vervielfältigt worden oder verlorengegangen sind. SPP-Pakete enthalten weiterhin zwei 16 Bit große Verbindungs-IDs. Je eine Verbindungs-ID wird von jedem Ende der Verbin-dung angegeben, und zusammengenommen weisen diese bei-den Verbindungs-IDs eine logische Verbindung zwischenClient-Prozessen eindeutig aus.

SPP-Pakete können nicht mehr als 576 Byte umfassen. Client-Prozesse können während des Verbindungsaufbaus den Ein-satz einer anderen Paketgröße aushandeln, aber SPP definiertdie Art und Weise dieses Aushandelns nicht.

Bei dem Packet Exchange Protocol (PEP) handelt es sich umein Request-Response-Protokoll, das entworfen wurde, umzuverlässiger zu sein als ein einfacher Datagrammdienst (wieer beispielsweise von IDP bereitgestellt wird), aber wenigerzuverlässig zu sein als SPP. PEP ähnelt von der Funktionalitäther dem User Datagram Protocol (UDP) der Internet-Proto-kollsammlung. Weitere Informationen zu UDP finden Sie inKapitel 28. PEP basiert auf Einzelpaketen und stellt eine er-neute Übermittlung bereit, aber kein Erkennen vervielfältigterPakete. Somit ist es in Anwendungen von Nutzen, in denenRequest-Response-Transaktionen wiederholt werden können,ohne daß Daten beschädigt werden, oder in denen die zuver-lässige Übermittlung auf einer anderen Schicht ausgeführtwird.

Das Error Protocol (EP) kann von jedem Client-Prozeß ver-wendet werden, um einen anderen Client-Prozeß darauf hin-zuweisen, daß ein Netzwerkfehler aufgetreten ist. Dieses Pro-tokoll kommt beispielsweise in Situationen zum Einsatz, indenen eine SPP-Implementierung ein vervielfältigtes Paketfestgestellt hat.

32.6 Protokolle übergeordneter Schichten

XNS bietet mehrere Protokolle für die übergeordneten Schich-ten an. Das Printing Protocol stellt Druckerdienste, das FilingProtocol Dienste für den Dateizugriff und das ClearinghouseProtocol Namensdienste bereit. Jedes dieser drei Protokolleläuft auf dem Courier Protocol ab, das Konventionen für die


Strukturierung von Daten und für die Prozeßinteraktion be-reitstellt.

XNS definiert außerdem Schicht-4-Protokolle, bei denen essich um Anwendungsprotokolle handelt. Aber da sie nurwenig mit den eigentlichen Kommunikationsfunktionen zu tunhaben, umfaßt die XNS-Spezifikation keine sachgemäßenDefinitionen.

Das Echo Protocol der Schicht 2 wird verwendet, um dieErreichbarkeit von XNS Netzknoten zu überprüfen und umFunktionen zu unterstützen, wie sie beispielsweise von demBefehl PING in UNIX und anderen Umgebungen bereitgestelltwerden.

Kapitel 33: Border Gateway Protocol (BGP)Kapitel 34: Enhanced IGRPKapitel 35: IBM Systems Network Architecture (SNA) Kapitel 35: RoutingKapitel 36: Interior Gateway Routing Protocol (IGRP)Kapitel 37: Internet Protocol (IP) MulticastKapitel 38: NetWare Link Services Protocol (NLSP)Kapitel 39: Open Systems Interconnection (OSI) Kapitel 39: Routing-ProtokollKapitel 40: Open Shortest Path First (OSPF)Kapitel 41: Resource Reservation Protocol (RSVP)Kapitel 42: Routing Information Protocol (RIP)Kapitel 43: Simple Multicast Routing Protocol (SMRP)

Teil 6: Routing-Protokolle

Der Teil 6, »Routing-Protokolle«, faßt die Eigenschaften undOperationen geläufiger Routing-Protokolle zusammen. Fol-gende Themen werden in einzelnen Kapiteln besprochen:

Border Gateway Protocol (BGP) – Beschreibt die Operationenvon BGP, einem externen Gateway-Protokoll aus der InternetProtokollsammlung (IP).

Enhanced Interior Gateway Routing Protocol (EnhancedIGRP) – Beschreibt die Eigenschaften und Operationen vonEnhanced IGRP.

IBM Systems Network Architecture (SNA) Routing – LiefertBeschreibungen von Komponenten und Operationen des IBMSNA Routing in Subarea- und APPN-Routing-Umgebungen.

Interior Gateway Routing Protocol (IGRP) – Beschreibt dieEigenschaften und Operationen von IGRP.

Internet Protocol (IP) Multicast – Beschreibt das IP-Multicastund umreißt die grundlegenden Operationen verschiedenerunterstützender Protokolle.

NetWare Link Services Protocol (NLSP) – Beschreibt dieKomponenten, Eigenschaften und Operationen von NovellNLSP.

Open Systems Interconnection (OSI) Routing – Behandelt dieEigenschaften und Operationen der OSI-Routing-Protokolle:ES-IS, IS-IS, Integrated IS-IS und IDRP.

TEIL 6Routing-Protokolle


Open Shortest Path First (OSPF) – Behandelt die Kompo-nenten und Operationen dieses internen Gateway-Routing-Protokolls für Link-State Routing.

33 Border Gateway Protocol (BGP)

33.1 Hintergrund

Zum Routing gehören zwei grundlegende Tätigkeiten: dasErmitteln der optimalen Routingpfade und der Transport vonInformationsgruppen (typischerweise als Pakete bezeichnet)über ein Internet-Netzwerk. Der Transport von Paketen überein Internet-Netzwerk erfolgt verhältnismäßig direkt. DasErmitteln der Pfade kann andererseits sehr kompliziert sein.Eines der Protokolle, die sich in heutigen Netzwerken mit derAufgabe beschäftigen, Pfade zu ermitteln, ist das Border Gate-way Protocol (BGP). Dieses Kapitel liefert eine Zusammenfas-sung der grundlegenden Operationen von BGP und eine Be-schreibung der Komponenten des Protokolls.

BGP führt das Routing zwischen Domains eines TransmissionControl Protocol/Internet Protocol-Netzwerks (TCP/IP) durch.Bei BGP handelt es sich um ein Exterior Gateway Protocol(EGP); das heißt, es führt das Routing zwischen mehrerenautonomen Systemen oder Domains durch und tauscht Infor-mationen über das Routing und die Erreichbarkeit mit ande-ren BGP-Systemen aus.

BGP wurde entwickelt, um seinen Vorgänger, das mittlerweileüberholte Exterior Gateway Protocol (EGP), als das standard-mäßig im globalen Internet eingesetzte externe Gateway-Routing-Protokoll zu ersetzen. BGP löst schwerwiegende Pro-

KAPITEL 33Border Gateway Protocol (BGP)


bleme mit EGP und paßt sich dem Wachstum des Internet effi-zienter an.

Hinweis: Bei EGP handelt es sich um ein bestimmtes Beispielfür ein externes Gateway-Protokoll (ebenfalls mit EGP abge-kürzt) – die beiden sollten nicht durcheinander gebrachtwerden.

Im Bild 33.1 sind Core-Router dargestellt, die für das Routingdes Verkehrs zwischen verschiedenen autonomen Systemen aufBGP zurückgreifen.

BGP wird in mehreren Request For Comments (RFCs) spezi-fiziert:

− RFC 1771 – Beschreibt BGP4, die aktuelle Version vonBGP

− RFC 1654 – Beschreibt die erste BGP4-Spezifikation

− RFC 1105, RFC 1163 und RFC 1267 – Beschreiben dievor BGP4 liegenden Versionen von BGP

Core-Router

BGP BGP BGP

Autonome Systeme

BGP BGP BGP

Core-Router Core-Router

33.2 BGP-Operationen

BGP führt drei Arten von Routing durch: InterautonomousSystem Routing, Intra-Autonomous System Routing und Pass-Through Autonomous System Routing.

Interautonomous System Routing kommt zwischen zwei odermehr BGP-Routern aus verschiedenen autonomen Systemenvor. Peer-Router in diesem System verwenden BGP, um einekonsistente Ansicht der Topologie des Internetzwerks zu er-

Bild 33.1:Core-Router

können für dasRouting des

Verkehrs zwi-schen autono-men Systemen

auf BGP zu-rückgreifen

Kapitel 33 • Border Gateway Protocol (BGP) 441

halten. BGP-Nachbarn, bei denen eine Kommunikation zwi-schen autonomen Systemen stattfindet, müssen sich im glei-chen physikalischen Netzwerk befinden. Das Internet ist einBeispiel für eine auf diese Routing-Strategie zurückgreifendeEinheit, weil es aus autonomen Systemen oder Verwaltungs-domains besteht. Viele dieser Domains stehen für verschiedeneInstitutionen, Firmen und andere Existenzen, die gemeinsamdas Internet ausmachen. BGP wird häufig für die Ermittlungder Verbindungspfade eingesetzt, um für ein optimales Rou-ting innerhalb des Internet zu sorgen.

Intra-Autonomous System Routing kommt zwischen zweioder mehr BGP-Routern vor, die sich im selben autonomenSystem befinden. Peer-Router innerhalb desselben autonomenSystems verwenden BGP, um eine konsistente Ansicht der To-pologie des Systems zu erhalten. BGP wird außerdem einge-setzt, um zu ermitteln, welcher Router als Verbindungspunktfür bestimmte externe autonome Systeme dienen soll. Wie-derum stellt das Internet ein Beispiel für das Routing inner-halb eines autonomen Systems dar. Eine Organisation wie bei-spielsweise eine Universität kann von BGP Gebrauch machen,um für ein optimales Routing innerhalb ihrer eigenen Verwal-tungsdomain oder ihres eigenen autonomen Systems zu sor-gen. Das Protokoll BGP stellt Routingdienste sowohl zwischen(inter) autonomen Systemen als auch innerhalb (intra) einesautonomen Systems zur Verfügung.

Pass-Through Autonomous System Routing kommt zwischenzwei oder mehr BGP-Peer-Routern vor, die den Datenaus-tausch über ein autonomes System vornehmen, auf dem BGPnicht läuft. In einer Umgebung mit einem durchreichenden(pass-through) autonomen System stammt der BGP-Daten-verkehr nicht aus dem betroffenen autonomen System und istauch nicht für einen Knoten dieses autonomen Systems be-stimmt. BGP muß dazu mit einem beliebigen innerhalb desautonomen Systems verwendeten Routing-Protokoll interagie-ren, um den BGP-Datenverkehr erfolgreich durch das auto-nome System zu transportieren. Im Bild 33.2 ist eine Umge-bung mit einem durchreichenden autonomen System darge-stellt:


Quelle

Ziel

BGP

BGP

Durchreichendesautonomes System

Protokoll innerhalbdes autonomen

Systems

33.3 BGP-Routing

Wie jedes Routing-Protokoll unterhält BGP eine Routing-Tabelle, übermittelt Routing-Updates und gründet Entschei-dungen für das Routing auf Routing-Metriken. Die vorder-gründige Aufgabe eines BGP-Systems besteht darin, Informa-tionen über die Erreichbarkeit von Netzwerken, wozu auchInformationen über die Liste der Pfade zu autonomen Syste-men zählen, mit anderen BGP-Systemen auszutauschen. Mitdiesen Informationen läßt sich ein Diagramm der Verbin-dungen zwischen den autonomen Systemen erstellen, ausdenen Schleifen beim Routing entfernt werden können undmit denen grundsätzliche Entscheidungen der autonomenSystemebene durchgesetzt werden können.

Jeder BGP-Router unterhält eine Routing-Tabelle, die alledurchführbaren Pfade zu einem bestimmten Netzwerk auf-führt. Der Router erneuert die Routing-Tabelle jedoch nicht.Statt dessen werden von Peer-Routern erhaltene Routing-Informationen so lange zurückgehalten, bis ein inkrementellesUpdate erhalten wird.

BGP-Geräte tauschen ihre Routing-Informationen beim erstenDatenaustausch und nach inkrementellen Updates aus. Wennein Router sich zum ersten Mal an ein Netzwerk anbindet,tauschen BGP-Router ihre gesamten BGP-Routing-Tabellenmiteinander aus. Wenn Änderungen an Routing-Tabellen auf-treten, versenden Router entsprechend den Anteil ihrer Rou-ting-Tabelle, der sich verändert hat. BGP-Router versenden

Bild 33.2:Beim Routing

durch eindurchreichen-

des autonomesSystem arbeitetBGP mit einemanderen inner-halb des auto-

nomen Systemsverwendeten

Routing-Proto-koll zusammen


keine regelmäßig eingeplanten Routing-Updates, und BGP-Routing-Updates geben nur den optimalen Pfad zu einemNetzwerk bekannt.

BGP greift auf eine einzige Routing-Metrik zurück, um denbesten Pfad zu einem gegebenen Netzwerk zu ermitteln. DieseMetrik besteht aus einer beliebigen Einheitszahl, die den Gradder Vorliebe für eine bestimmte Verbindung angibt. Der einerVerbindung zugeordnete Wert kann auf einer beliebigen An-zahl von Kriterien basieren, zu denen u.a. die Anzahl der mitdem Verbindungspfad durchlaufenen autonomen Systeme, dieStabilität, Geschwindigkeit, Verzögerungszeit oder Kosten ge-hören.

33.4 Nachrichtentypen von BGP

In der RFC 1771, »A Border Gateway Protocol 4(BGP4)«,werden vier Nachrichtentypen für BGP spezifiziert: Open-Nachricht, Update-Nachricht, Notification-Nachricht undKeep-Alive-Nachricht.

Die Open-Nachricht eröffnet eine BGP-Kommunikationssit-zung zwischen Peers und ist die erste von jeder Seite nach demAufbau einer Verbindung durch ein Transportprotokoll gesen-dete Nachricht. Open-Nachrichten werden mittels einer vomPeer-Gerät verschickten Keep-Alive-Nachricht bestätigt, undsie müssen bestätigt worden sein, bevor Updates, Notificationsund Keep-Alives ausgetauscht werden können.

Eine Update-Nachricht wird verwendet, um anderen BGP-Systemen Routing-Updates bereitzustellen, wodurch Routerndas Erstellen einer konsistenten Ansicht der Netzwerk-Topo-logie ermöglicht wird. Updates werden mittels des Transmis-sion Control Protocol (TCP) verschickt, um eine zuverlässigeZustellung zu gewährleisten. Update-Nachrichten könneneinen oder mehrere undurchführbare Pfade aus der Routing-Tabelle entfernen und gleichzeitig einen anderen Pfad bekannt-geben.

Die Notification-Nachricht wird verschickt, wenn eine Fehler-bedingung entdeckt wird. Notifications werden verwendet,um aktive Arbeitssitzungen zu schließen und um alle ange-


bundenen Router darüber zu informieren, warum die Arbeits-sitzung geschlossen wird.

Die Keep-Alive-Nachricht teilt BGP-Peers mit, daß ein Gerätaktiv ist. Keep-Alives werden häufig genug verschickt, damitArbeitssitzungen nicht verfallen.

33.5 BGP-Paketformate

In den folgenden Abschnitten erfolgt eine Zusammenfassungder Nachrichtentypen Open, Update, Notification und Keep-Alive sowie des grundlegenden Header-Formats von BGP.Jedes Format wird durch eine Zeichnung erläutert, und diedargestellten Felder werden definiert.

33.5.1 Header-Format

Alle Nachrichtentypen von BGP greifen auf den zugrundelie-genden Paket-Header zurück. Open-, Update- und Notifica-tion-Nachrichten verfügen über zusätzliche Felder, währendfür Keep-Alive-Nachrichten nur der zugrundeliegende Paket-Header Verwendung findet. Im Bild 33.3 sind die im BGP-Header verwendeten Felder dargestellt. Im folgenden Ab-schnitt sind die Funktionen jedes Felds zusammengefaßt.

Felder des Paket-Headers von BGP

Jedes BGP-Paket enthält einen Header, dessen vordergründigeAufgabe darin besteht, die Funktion des fraglichen Pakets aus-zuweisen. In den folgenden Beschreibungen werden die Funk-tionen jedes Felds des in dem Bild 33.3 dargestellten BGP-Header zusammengefaßt.

Markierung Länge Daten

Feldlänge in Byte

16 2 Variabel

Typ

1

− Markierung – Enthält einen Authentifizierungswert, dender Nachrichtenempfänger voraussagen kann.

Bild 33.3:Ein BGP-

Paket-Headersetzt sich ausvier Feldernzusammen


− Länge – Gibt die Gesamtlänge der Nachricht in Byte an.

− Typ – Legt den Nachrichtentyp aus einer der folgendenMöglichkeiten fest:

− Open

− Update

− Notification

− Keep-Alive

− Daten – In diesem optionalen Feld sind Informationen fürübergeordnete Schichten enthalten.

33.5.2 Format der Open-Nachricht

Die Open-Nachrichten von BGP setzen sich aus einem BGP-Header und zusätzlichen Feldern zusammen. Im Bild 33.4 sinddie für Open-Nachrichten zusätzlich verwendeten Felder dar-gestellt.

VersionAutonomes

System

Feldlänge in Byte

1 2 2 4 1 4

Wartezeit BGP-IDOptionaleParameter

Länge deroptionalenParameter

Felder der Open-Nachricht von BGP

BGP-Pakete, deren Headerfeld Typ das Paket als eine Open-Nachricht ausweist, enthalten folgende Felder. Diese Felderstellen die Austauschkriterien für zwei BGP-Router bereit,damit diese eine Peer-Verbindung aufbauen können.

− Version – Stellt die Versionsnummer von BGP bereit, damitder Empfänger feststellen kann, ob auf ihm dieselbe Ver-sion läuft wie auf dem Sender.

− Autonomes System – Stellt die Nummer des sendendenautonomen Systems bereit.

− Wartezeit – Gibt die maximale Anzahl von Sekunden an,die ohne einen Empfang einer Nachricht verstreichen darf,bevor der Übermittler als außer Funktion betrachtet wird.

Bild 33.4:Eine Open-Nachricht vonBGP setzt sichaus sechs Fel-dern zusam-men


− BGP-ID – Stellt den BGP-Identifizierer des Senders bereit(eine IP-Adresse), der beim Hochfahren bestimmt wird undfür sämtliche lokalen Schnittstellen und BGP-Peers iden-tisch ist.

− Länge der optionalen Parameter – Gibt die Länge des Feldsfür die optionalen Parameter an (sofern vorhanden).

− Optionale Parameter – Enthält eine Auflistung optionalerParameter (sofern vorhanden). Derzeit ist nur der optionaleParametertyp Authentication Information definiert, dersich aus folgenden beiden Feldern zusammensetzt:

− Authentication Code: Gibt die Art der verwendetenAuthentifizierung an.

− Authentication Data: Enthält von der Authentifizierungverwendete Daten (sofern eine zum Einsatz gelangt).

33.5.3 Format der Update-Nachricht

Die Update-Nachrichten von BGP setzen sich aus einem BGP-Header und zusätzlichen Feldern zusammen. Im Bild 33.5 sinddie für Update-Nachrichten zusätzlich verwendeten Felderdargestellt.

ZurückgezogeneRouten

Feldlänge in Byte

2 Variabel 2 Variabel Variabel

PfadattributeInformationen zurErreichbarkeit vonNetzwerkschichten

Länge der nichtdurchführbaren

Routen

Gesamtlängeder Pfad-attribute

Felder der Update-Nachricht von BGP

BGP-Pakete, deren Headerfeld Typ das Paket als eine Update-Nachricht ausweist, enthalten folgende Felder. Durch dasEmpfangen eines Update-Pakets sind Router dazu in der Lage,bestimmte Einträge zu ihren Routing-Tabellen hinzuzufügenoder aus ihnen zu löschen, um dadurch für ein stimmiges Ab-bild zu sorgen. Update-Nachrichten setzen sich aus folgendenFeldern zusammen:

− Länge der nicht durchführbaren Routen – Zeigt entwederdie Gesamtlänge des Felds Zurückgezogene Routen oderdas Nichtvorhandensein des Felds an.

Bild 33.5:Eine Update-

Nachricht vonBGP setzt sich

aus fünf Fel-dern zusam-

men


− Zurückgezogene Routen – Enthält eine Auflistung der IP-Adreßpräfixe für außer Dienst gestellte Routen.

− Gesamtlänge der Pfadattribute – Zeigt die Gesamtlänge desFelds Pfadattribute oder das Nichtvorhandensein des Feldsan.

− Pfadattribute – Beschreibt die Charakteristik des mitgeteil-ten Pfads. Folgende Attribute sind für einen Pfad möglich:

− Origin: Vorgeschriebenes Attribut, das die Herkunft(Origin) der Pfadinformationen definiert.

− AS Path: Vorgeschriebenes Attribut, das sich aus einerReihe von Pfadsegmenten der autonomen Systeme (AS)zusammensetzt.

− Next Hop: Vorgeschriebenes Attribut, das die IP-Adresse desjenigen Übergangsrouter definiert, der fürden nächsten Hop zum Feld Informationen zur Erreich-barkeit von Netzwerk-Schichten aufgeführten Zielenverwendet werden soll.

− Mult Exit Disc: Optionales Attribut zum Unterscheiden(Discriminate) mehrerer Übergangspunkte (MultipleExitpoints) zu einem benachbarten autonomen System.

− Local Pref: Beliebiges Attribut zur Angabe des Gradsder Vorliebe (Preference) für eine mitgeteilte Route.

− Atomic Aggregate: Beliebiges Attribut zur Bekanntgabevon Informationen über die Auswahl von Routen.

− Aggregator: Optionales Attribut, das Informationenüber Gesamtrouten (aggregate Routes) enthält.

− Informationen zur Erreichbarkeit von Netzwerk-Schichten– Enthält eine Auflistung von IP-Adreßpräfixen für die mit-geteilten Routen.


33.5.4 Format der Notification-Nachricht

Im Bild 33.6 sind die für Notification-Nachrichten zusätzlichverwendeten Felder dargestellt.

Fehlercode Fehlersubcode

Feldlänge in Byte

1 1 Variabel

Fehlerdaten

Felder der Notification-Nachricht von BGP

BGP-Pakete, deren Headerfeld Typ das Paket als eine Notifi-cation-Nachricht ausweist, enthalten folgende Felder. DiesesPaket wird verwendet, um den Peers des Herkunftsrouterseine Art von Fehlerbedingung anzuzeigen.

− Fehlercode – Zeigt die Art des aufgetretenen Fehlers an.Folgende Fehlertypen sind durch das Feld definiert:

− Message Header Error: Zeigt ein Problem mit demHeader der Nachricht an wie beispielsweise eine unan-nehmbare Nachrichtenlänge, einen unannehmbarenWert im Feld Markierung oder einen unannehmbarenNachrichtentyp.

− Open Message Error: Zeigt ein Problem mit einerOpen-Nachricht an wie beispielsweise eine nicht unter-stützte Versionsnummer, eine unannehmbare Nummerfür das autonome System bzw. die IP-Adresse oder einnicht unterstützter Authentifizierungscode.

− Update Message Error: Zeigt ein Problem mit einerOpen-Nachricht an wie beispielsweise eine mißgebildeteAttributliste, ein Fehler in der Attributliste oder ein un-zulässiges Next Hop-Attribut.

− Hold Time Expired: Zeigt an, daß die Wartezeit abge-laufen ist, nach der ein BGP-Knoten als außer Funktionbetrachtet wird.

Bild 33.6:Eine Notifica-

tion-Nachrichtvon BGP setzt

sich aus dreiFeldern zu-

sammen


− Finite State Machine Error: Zeigt ein unberücksichtigtesEreignis an.

− Cease: Schließt eine BGP-Verbindung auf Anforderungeines BGP-Geräts bei Nichtvorhandensein schwerwie-gender Fehler.

− Fehlersubcode – Liefert genauere Informationen über dieArt des mitgeteilten Fehlers.

− Fehlerdaten – Enthält auf den Feldern Fehlercode undFehlersubcode beruhende Daten. Dieses Feld wird verwen-det, um die Ursache für die Notification-Nachricht festzu-stellen.

34 Enhanced IGRP

34.1 Hintergrund

Das Enhanced Internet Gateway Routing Protocol (IGRP)stellt eine Weiterentwicklung des Vorgängers IGRP dar (siehedazu Kapitel 36, »Internet Gateway Routing Protocol(IGRP)«). Diese Weiterentwicklung liegt in den Änderungender Netzwerk-Arbeit und den Anforderungen verschiedenerumfangreicher Internetzwerke begründet. Das Enhanced IGRPintegriert die Fähigkeiten von Link-State-Protokollen in Di-stance-Vector-Protokolle. Es baut auf dem bei SRI Internatio-nal von Dr. J. J. Garcia-Luna-Aceves entwickelten Diffusing-Update-Algorithmus (DUAL) auf.

Enhanced IGRP ist kompatibel zu IGRP-Routern und sorgtfür eine problemlose Zusammenarbeit. Ein automatischerUmwandlungsmechanismus ermöglicht die Übernahme vonIGRP-Routen in Enhanced IGRP und andersherum, so daßsich Enhanced IGRP nach und nach in ein bestehendes IGRP-Netzwerk einbinden läßt. Da sich die Metriken beider Proto-kolle direkt ineinander übertragen lassen, sind sie so leichtmiteinander zu vergleichen, als ob es sich bei ihnen um Rou-ten handelte, die aus ihren eigenen autonomen Systemen (AS)stammten. Außerdem behandelt Enhanced IGRP IGRP-Rou-ten als externe Routen und bietet dem Netzwerk-Administra-tor einen Weg, diese anzupassen.

KAPITEL 34Enhanced IGRP


In diesem Kapitel wird ein Überblick über die grundlegendenOperationen und Protokolleigenschaften von Enhanced IGRPgegeben.

34.2 Fähigkeiten und Attribute von EnhancedIGRP

Zu den Schlüsselfähigkeiten, die Enhanced IGRP von anderenRouting-Protokollen unterscheiden, gehören die schnelle Kon-vergenz, die Unterstützung von Subnetz-Masken mit variablerLänge, partiellen Updates sowie mehreren Protokollen für dieNetzwerk-Schicht.

Ein Router, auf dem Enhanced IGRP läuft, speichert alle Rou-ting-Tabellen seiner Nachbarn, so daß er sich schnell an an-dere Routen anpassen kann. Wenn keine geeignete Route vor-handen ist, fragt Enhanced IGRP seine Nachbarn ab, um eineandere Route zu ermitteln. Diese Abfragen setzen sich fort, biseine andere Route ausfindig gemacht wurde.

Die Unterstützung von Subnetz-Masken variabler Länge er-möglicht es, daß Routen automatisch nach einer Netzwerk-Nummerngrenze zusammengefaßt werden. Weiterhin läßt sichEnhanced IGRP so konfigurieren, daß eine Zusammenfassungnach jeder beliebigen Bitgrenze für jede beliebige Schnittstelleerfolgen kann.

Enhanced IGRP führt keine regelmäßigen Updates durch. Stattdessen verschickt es partielle Updates nur dann, wenn sich dieMetrik für eine Route ändert. Die Weiterleitung von partiellenUpdates ist automatisch begrenzt, so daß nur diejenigen Rou-ter aktualisiert werden, die diese Informationen benötigen. Alseine Folge dieser beiden Fähigkeiten verbraucht EnhancedIGRP bedeutend weniger Bandbreite als IGRP.

Enhanced IGRP unterstützt AppleTalk, IP und Novell Net-Ware. Die Implementierung von AppleTalk verbreitet aus demRouting Table Maintenance Protocol (RTMP) erfahrene Rou-ten weiter. Die IP-Implementierung verbreitet von OSPF, demRouting Information Protocol (RIP), IS-IS, dem ExteriorGateway Protocol (EGP) oder dem Border Gateway Protocol

Kapitel 34 • Enhanced IGRP 453

(BGP) erfahrene Routen weiter. Die Implementierung vonNovell verbreitet aus dem Novell RIP oder dem Service Adver-tisement Protocol (SAP) erfahrene Routen weiter.

34.3 Zugrundeliegende Prozesse und Techniken

Für eine bessere Leistung beim Routing setzt Enhanced IGRPvier Schlüsseltechniken ein, die gemeinsam für eine Unter-scheidung von anderen Routing-Techniken sorgen: NeighborDiscovery/Recovery, Reliable Transport Protocol (RTP),DUAL Finite-State Machine und protokollabhängige Module.

Das Neighbor Discovery/Recovery wird von Routern verwen-det, um dynamisch von anderen Routern aus den direkt ange-bundenen Netzwerken Kenntnis zu erlangen. Router müssenweiterhin feststellen können, daß ihre Nachbarn unerreichbarwerden oder nicht mehr in Betrieb sind. Dieser Vorgang wirdmit geringem Overhead durch das regelmäßige Verschickenkleiner Hello-Pakete erreicht. Solange ein Router diese Paketevon einem benachbarten Router empfängt, geht er davon aus,daß der Router funktioniert, und die beiden können Routing-Informationen austauschen.

Das Reliable Transport Protocol (RTP) ist für die garantierte,geordnete Zustellung von Enhanced-IGRP-Paketen an sämtli-che Nachbarn verantwortlich. Es unterstützt eine gemischteÜbertragung von Multicast- oder Unicast-Paketen. Aus Effi-zienzgründen werden nur bestimmte Enhanced-IGRP-Paketezuverlässig übertragen. In einem multicastfähigen Netzwerkmit Mehrfachzugriff wie beispielsweise Ethernet ist es nichterforderlich, Hello-Pakete zuverlässig an alle Nachbarn ein-zeln zu verschicken. Aus diesem Grund verschickt EnhancedIGRP ein einziges Multicast-Hello-Paket, das einen Indikatorenthält, der die Empfänger darüber informiert, daß das Paketnicht bestätigt zu werden braucht. Andere Pakettypen wie bei-spielsweise Updates weisen im Paket darauf hin, daß einAcknowledgement erforderlich ist. RTP verfügt über eine Vor-kehrung zum schnellen Verschicken von Multicast-Paketen,wenn unbestätigte Pakete anhängig sind, was bei Verbindun-gen mit sich verändernder Geschwindigkeit hilft, die Konver-genzzeit kurz zu halten


DUAL Finite-State Machine verkörpert den Entscheidungs-prozeß für alle Routenberechnungen durch das Verfolgensämtlicher durch die Nachbarn bekanntgemachten Routen.DUAL greift für die Auswahl effizienter, schleifenfreier Pfadeauf Entfernungsinformationen zurück und wählt Routen zumEinfügen in eine Routing-Tabelle basierend auf erreichbarenNachfolgern aus. Bei einem erreichbaren Nachfolger handeltes sich um einen für das Weiterleiten von Paketen verwendetenbenachbarten Router, der den günstigsten Pfad zu einem Zieldarstellt, das sich garantiert nicht in einer Routing-Schleifebefindet. Sobald ein Nachbar eine Metrik ändert oder eineÄnderung in der Topologie auftritt, führt DUAL eine Überprü-fung auf erreichbare Nachfolger durch. Wenn einer gefundenwird, verwendet DUAL diesen, um eine unnötige Neubestim-mung der Route zu vermeiden. Wenn kein erreichbarer Nach-folger vorhanden ist, Nachbarn das Ziel aber immer noch be-kanntmachen, muß eine Neubestimmung (was auch als ver-teilte Bestimmung bezeichnet wird) erfolgen, um einen neuenNachfolger festzulegen. Obwohl die Neubestimmung nichtprozessorintensiv ist, beeinflußt es die Konvergenzzeit, so daßes von Vorteil ist, unnötige Neubestimmungen zu vermeiden.

Protokollabhängige Module sind für diejenigen Anforderun-gen verantwortlich, welche die Protokolle der Netzwerk-Schicht betreffen. Das Modul IP-Enhanced IGRP ist beispiels-weise für das Verschicken und Empfangen von Enhanced-IGRP-Paketen verantwortlich, die in IP gekapselt sind. Zu-sätzlich zeichnet IP-Enhanced IGRP dafür verantwortlich, En-hanced-IGRP-Pakete zu parsen und DUAL die neuen Infor-mationen mitzuteilen, die empfangen worden sind. IP-Enhan-ced IGRP kümmert sich um das Neuverteilen der von anderenIP-Routing-Protokollen erfahrenen Routen.

34.4 Begriffe zum Routing

Enhanced IGRP beruht auf folgenden vier grundlegenden Be-griffen: Nachbartabellen, Topologietabellen, Routenzuständeund Routenkennzeichnungen. Jeder dieser Begriffe wird in denfolgenden Zusammenfassungen behandelt.


34.4.1 Nachbartabellen

Wenn ein Router einen neuen Nachbarn entdeckt, zeichnet erdie Adresse und die Schnittstelle des Nachbarn als Eintrag inder Nachbartabelle auf. Es gibt eine Nachbartabelle für jedesprotokollabhängige Modul. Wenn ein Nachbar ein Hello-Paket verschickt, gibt er eine Wartezeit bekannt, bei der es sichum die Zeitspanne handelt, für die ein Router einen Nachbarnals erreichbar und in Betrieb behandelt. Wenn innerhalb derWartezeit kein Hello-Paket empfangen wird, läuft die Warte-zeit ab, und DUAL wird über die Änderung in der Topologieinformiert.

Der Eintrag in der Nachbartabelle enthält außerdem von RTPbenötigte Informationen. Es werden Sequenznummern ver-wendet, um Acknowledgments mit Datenpaketen in Überein-stimmung zu bringen, und die letzte vom Nachbarn erhalteneSequenznummer wird aufgezeichnet, damit aus der Reihetanzende Pakete entdeckt werden. Es wird eine auf Nachbarnbezogene Übertragungsliste verwendet, um Pakete für einemögliche erneute Übertragung einzureihen. Im Tabelleneintragwerden Zeitmesser für den Hin- und Rückweg vorgehalten,um eine optimale Zeitspanne für die erneute Übertragung ab-zuschätzen.

34.4.2 Topologietabellen

Die Topologietabelle enthält alle von benachbarten Routernmitgeteilten Ziele. Die protokollabhängigen Module füllen dieTabelle auf, und die Tabelle wird von der DUAL Finite-StateMachine verwendet. Jeder Eintrag in der Topologietabelle ent-hält die Zieladresse mit einer Auflistung der Nachbarn, diedieses Ziel mitgeteilt haben. Für jeden Nachbarn zeichnet derEintrag die mitgeteilte Metrik auf, die der Nachbar in seinerRouting-Tabelle speichert. Distance-Vector-Protokolle müssendie wichtige Regel befolgen, daß, wenn ein Nachbar ein Zielbekannt macht, er die Route zum Weiterleiten von Paketenverwenden muß.

Die Metrik, die der Router zum Erreichen des Ziels verwen-det, ist ebenfalls mit dem Ziel verbunden. Die Metrik, die derRouter in der Routing-Tabelle verwendet und anderen Rou-tern mitteilt, ist die Summe der besten von allen Nachbarn


mitgeteilten Metriken plus dem Verbindungsaufwand zumbesten Nachbarn.

34.4.3 Routenzustände

Ein Eintrag für ein Ziel in der Topologietabelle kann in einemvon zwei Zuständen vorliegen: aktiv oder passiv. Ein Ziel be-findet sich im passiven Zustand, falls der Router keine Neube-stimmung durchführt, oder im aktiven Zustand, falls der Rou-ter eine Neubestimmung durchführt. Wenn erreichbare Nach-folger immer verfügbar sind, braucht ein Ziel niemals in denaktiven Zustand überzugehen, wodurch eine Neubestimmungvermieden wird.

Es kommt zu einer Neubestimmung, wenn ein Ziel nicht übererreichbare Nachfolger verfügt. Der Router stößt die Neube-stimmung an, indem er ein Query-Paket an jeden seiner be-nachbarten Router verschickt. Der benachbarte Router kannein Reply-Paket verschicken, mit dem angezeigt wird, daß erüber einen erreichbaren Nachfolger für das Ziel verfügt, oderer kann ein Query-Paket verschicken, mit dem angezeigt wird,daß er sich an der Neubestimmung beteiligt. Solange sich einZiel im aktiven Zustand befindet, kann ein Router die Infor-mationen der Routing-Tabelle des Ziels nicht ändern. Nach-dem der Router ein Reply von jedem benachbarten Router er-halten hat, geht der Eintrag für das Ziel in der Topologie-tabelle wieder in den passiven Zustand über, und der Routerkann einen Nachfolger auswählen.

34.4.4 Routenkennzeichnung

Enhanced IGRP unterstützt interne und externe Routen. In-terne Routen stammen aus einem Enhanced IGRP AS. Daherwird ein direkt angebundenes Netzwerk, das für den Betriebvon Enhanced IGRP konfiguriert ist, als interne Route be-trachtet und mit dieser Information durch das Enhanced IGRPAS weitergeleitet. Externe Routen werden von einem anderenRouting-Protokoll in Erfahrung gebracht oder befinden sichals statische Routen in der Routing-Tabelle. Diese Routenwerden individuell mit der Identität ihrer Herkunft gekenn-zeichnet.


Externe Routen werden mit folgenden Informationen gekenn-zeichnet:

− Router-ID des Enhanced-IGRP-Router, der die Route wei-terverteilt

− AS-Nummer des Ziels

− Konfigurierbare Administratorkennzeichnung

− ID des externen Protokolls

− Metrik aus dem externen Protokoll

− Bit-Flags für vorgegebenes Routing

Die Routenkennzeichnung ermöglicht es dem Netzwerk-Administrator, das Routing den Bedürfnissen anzupassen undeine flexible Sicherheitskontrolle zu erhalten. Die Routenkenn-zeichnung ist insbesondere beim Durchqueren von AS nütz-lich, wobei Enhanced IGRP typischerweise mit einem Rou-ting-Protokoll zwischen Domains interagiert, das umfassen-dere Sicherheitsmaßnahmen implementiert, die zu einem äu-ßerst skalierbaren, sicherheitsorientierten Routing führen.

34.5 Pakettypen von Enhanced IGRP

Enhanced IGRP greift auf folgende Pakettypen zurück: Hellound Acknowledgment, Update sowie Query und Reply.

Hello-Pakete werden für das Neighbor Discovery/Recovery alsMulticast verschickt und erfordern kein Acknowledgment. Beieinem Acknowledgment-Paket handelt es sich um ein daten-loses Hello-Paket. Acknowledgment-Pakete enthalten eineAcknowledgment-Nummer ungleich Null und werden immerunter Verwendung einer Unicast-Adresse verschickt.

Update-Pakete werden verwendet, um die Erreichbarkeit vonZielen zu übermitteln. Sobald ein neuer Nachbar entdecktwird, werden Unicast-Pakete verschickt, so daß der Nachbarseine Topologietabelle aufbauen kann. In anderen Fällen wiebeispielsweise bei Änderungen im Verbindungsaufwand erfol-gen Updates als Multicast. Updates werden immer zuverlässigübermittelt.


Query- und Reply-Pakete werden verschickt, sobald ein Zielüber keine erreichbaren Nachfolger verfügt. Query-Pakete er-folgen immer als Multicast. Reply-Pakete werden als Reaktionauf Query-Pakete verschickt, um den Urheber dazu zu brin-gen, die Route nicht neu zu bestimmen, da erreichbare Nach-folger vorhanden sind. Reply-Pakete erfolgen als Unicast anden Urheber des Query-Pakets. Sowohl Query- als auchReply-Pakete werden zuverlässig übertragen.

35 IBM Systems Network Architecture (SNA) Routing

35.1 Hintergrund

IBMs Netzwerk-Architektur hat sich beträchtlich weiterent-wickelt, da sich das Computerwesen im allgemeinen von derDominanz zentraler Rechnerlösungen hin zu gleichberechtig-ten Rechnern entwickelt hat. Heutzutage bezieht das IBMSystems Network Architecture (SNA) Routing zwei verschie-dene Umgebungsarten ein, obgleich eine Reihe von Schlüssel-begriffen für alle SNA-Routing-Situationen zentral sind. Indiesem Kapitel werden Funktionen und Dienste besprochen,die sowohl das SNA Subarea Routing als auch das AdvancedPeer-to-Peer Networking (APPN) Routing ermöglichen. Zuden behandelten Themen gehören Sitzungsverbindungen(Session Connections), Übertragungsgruppen (TransmissionGroups), explizite und virtuelle Routen sowie Dienstklassen(Classes Of Service = COS). Allgemeine Informationen zumtraditionellen IBM SNA und APPN finden Sie in Kapitel 27,»Protokolle der IBM Systems Network Architecture (SNA)«.Das Bild 35.1 verdeutlicht die in diesem Kapitel behandeltenBegriffe im Kontext einer herkömmlichen SNA-Umgebung.

KAPITEL 35IBM Systems Network Architecture (SNA)


Übertragungs-gruppe (ÜG) (ÜG)

Gateway Node

TG TG

Verbindung 2

Verbindung 4

Verbindung 5

Verbindung 3Verbindung 1

Subarea-Knoten

SessionConnector

Virtuelle Route

Explizite Route 1

Explizite Route 2

Virtuelle Route

Explizite Route 3

Explizite Route 4

Quell-Subarea

Ziel-Subarea

Subarea-Knoten

Host

(ÜG) (ÜG)

Aufbau-steuereinheit

35.2 IBM-SNA-Sitzungsverbindungen

IBM-SNA-Sitzungsverbindungen werden verwendet, umAdreßräume zu überbrücken, wenn Arbeitssitzungen mehrereAdreßräume durchqueren. Es gibt drei Arten von Sitzungs-verbindungen: Übergangsfunktionen, SNA Network Inter-connection (SNI) Gateways und zwischengeschaltete APPN-Routing-Funktionen. Übergangsfunktionen befinden sich inSubarea-Knoten und bilden die Adreßräume von Subareas undPeripherie aufeinander ab. SNI Gateways dienen als Brückezwischen SNA-Netzwerken und nehmen Daten aus dem einenNetzwerk entgegen, die sie an das entsprechende Ziel in einemanderen Netzwerk übertragen. SNI Gateways sind für amEndpunkt an das Netzwerk angehängte Einheiten transparent.Zwischengeschaltete APPN-Knoten führen das dazwischenlie-gende Routing in APPN-Netzwerken durch. Im Bild 35.1können Sie die Lage einer Sitzungsverbindung in einer her-kömmlichen SNA-Umgebung erkennen.

35.3 IBM-SNA-Übertragungsgruppen

Bei IBM-SNA-Übertragungsgruppen handelt es sich um logi-sche, zwischen benachbarten IBM-SNA-Knoten hergestellteVerbindungen, die verwendet werden, um den in einer Ar-beitssitzung anfallenden SNA-Datenverkehr zu übergeben.Übertragungsgruppen setzen sich aus einer oder mehrerenSNA-Verbindungen und den ihnen zugewiesenen Übertra-gungsprioritäten zusammen. Übertragungsgruppen mit mehre-

Bild 35.1:Das SNA

Routing stütztsich für dieVerbindung

von Subarea-Einheiten auf

Übertragungs-gruppen

Kapitel 35 • IBM Systems Network Architecture (SNA) Routing 461

ren Verbindungen, die eine höhere Zuverlässigkeit und Band-breite bieten, werden verwendet, um mehrere physikalischeVerbindungen in einer einzigen logischen SNA-Verbindung zubündeln. Derartige Übertragungsgruppen werden nur zwi-schen T4-Knoten unterstützt. Die Sequenznummern der Über-tragungsgruppen werden verwendet, um aus der Reihe tan-zende Nachrichten bei jedem Hop erneut einzureihen. Für jedeÜbertragungsgruppe werden vier Übertragungsprioritätenunterstützt: Low, Medium, High und Network-Service Traffic(die höchste Priorität). Im Bild 35.1 sind die Beziehungen derÜbertragungsgruppen hinsichtlich anderer Routing-Kompo-nenten im Kontext einer SNA-Subarea-Routing-Umgebung zusehen.

35.4 IBM-SNA – explizite und virtuelle Routen

Routen zwischen Subareas können entweder als explizite odervirtuelle Routen betrachtet werden. Explizite Routen sind diephysikalischen Verbindungen zwischen zwei Subarea-Knotenund dienen als geordnete Verkettung von Subareas und ver-bindende Übertragungsgruppen. Sie sind unidirektional, undes sind zwei explizite Routen erforderlich, um einen voll-duplex-fähigen Pfad einzurichten. Bei virtuellen Routen han-delt es sich um zwischen zwei Subarea-Knoten eingerichtetelogische Verbindungen in beide Richtungen. Eine virtuelleRoute bewegt sich sowohl auf einer expliziten Route als auchauf einer entgegengesetzten expliziten Route, die demselbenphysikalischen Pfad folgt. Virtuelle Routen überschreitenkeine Netzwerkgrenzen; statt dessen greifen sie auf eine netz-werkverbindende SNA-Sitzungsverbindung zurück, um zweivirtuelle Routen zu überbrücken. Virtuelle Routen enthaltenWerte, die die Übertragungspriorität und die globale Daten-flußkontrolle definieren, die durch Pacing bereitgestellt wer-den, wobei ein Empfänger mit ausreichendem Zwischenspei-cher Pacing-Fenster für den Sender bewilligt. Jedes Pacing-Fenster ermöglicht es dem Sender, eine bestimmte Informa-tionsmenge zu übertragen, bevor der Sender das nächstePacing-Fenster anfordern muß. Im Bild 35.1 können Sie dasVerhältnis zwischen expliziten und virtuellen Routen sowiederen Lage im Kontext einer SNA-Subarea-Routing-Umge-bung erkennen.


35.5 IBM-SNA-Dienstklassen

Die IBM-SNA-Dienstklassen (Classes Of Service = COS)kennzeichnen die Eigenschaften des übertragenden Netzwerkseiner gegebenen Arbeitssitzung. In Abhängigkeit von Benut-zerbedürfnissen können in einem SNA-Netzwerk verschiedeneDienstklassen angegeben werden. Die Dienstklasse stellt denMechanismus zum Ermitteln aller SNA-Routen bereit und be-schreibt annehmbare Dienstebenen für eine Arbeitssitzung.Die Dienstklasse gibt weiterhin die Eigenschaften des Dienstesan, zu denen Reaktionszeit, Sicherheit und Verfügbarkeit zäh-len. Außerdem kann die Dienstklasse automatisch beimAnmelden oder (vom Benutzer) manuell beim Einrichten derArbeitssitzung eingeführt werden. Jeder Dienstklassenname istmit einer Reihe von virtuellen Routen verknüpft, die der ge-wünschten Dienstebene entsprechen. Für eine gegebeneArbeitssitzung relevante Informationen werden in Subarea-und APPN-Tabellen der Dienstklasse aufbewahrt. Die Unter-schiede der Implementierung von Dienstklassen beim Subareaund APPN Routing sind in den folgenden Abschnittenzusammengefaßt.

35.5.1 Dienstklassen beim Subarea Routing

Beim Subarea Routing definiert der Benutzer die für eine be-stimmte Arbeitssitzung erforderliche Dienstklassenunterstüt-zung. Bestimmte virtuelle Routen werden auf bestimmte Dien-ste abgebildet, während die Eigenschaften der Dienstklasse mitden zugrundeliegenden expliziten Routen verknüpft werden.Der System Services Control Point (SSCP) greift auf dieDienstklassentabelle zurück, um der Pfadkontrollfunktion In-formationen über virtuelle Routen und die Übertragungsprio-rität bereitzustellen. Im Gegenzug wählt die Pfadkontrolle einevirtuelle Route und Übertragungspriorität (TransmissionPriority = TPRI) für den Einsatz in einer Arbeitssitzung aus.Das Format für einen Eintrag in der Dienstklassentabelle beimSubarea Routing ist im Bild 35.2 dargestellt.


TPRI

TPRI

TPRI

VRN

VRN

VRN

COS Name

Zeile 2

Zeile 3

Zeile 1

Einträge in der Dienstklassentabelle bestehen beim SubareaRouting aus dem Dienstklassenname, der Nummer der virtu-ellen Route (VRN) und der Übertragungspriorität in der Sub-area.

Der Dienstklassenname ist eine Standardbezeichnung wie bei-spielsweise SEC3, der durch Konventionen geregelt ist.

Die VRN weist eine bestimmte Route zwischen Subareas aus.Bis zu acht Nummern von virtuellen Routen können zwischenzwei Subarea-Knoten zugewiesen sein. Jede virtuelle Routekann bis zu drei verschiedenen Übertragungsprioritäten zu-gewiesen werden, und bis zu 24 virtuelle Routen sind zwi-schen zwei Subareas möglich.

TPRI weist die Priorität des Datenflusses für eine Arbeitssit-zung von einer logischen Einheit (Logical Unit = LU) zu eineranderen logischen Einheit über eine explizite Route aus. Be-nutzer können zwischen drei Prioritäten für jede virtuelleRoute wählen: 0 (niedrigste), 1 oder 2 (höchste).

35.5.2 Dienstklassen beim APPN Routing

Eine Dienstklasse ist beim APPN explizit mit Parametern derDienstklassentabelle definiert. Dienstklassen sind beim APPNfeiner aufgegliedert als beim Subarea SNA. Insbesondere er-möglichen Dienstklassen es beim APPN, eine Route auf Ka-pazität, Aufwand, Sicherheit, Weiterleitungsverzögerung undbenutzerdefinierten Eigenschaften basierend zu definieren. DerDienst wird auf Endknoten ausgeweitet und ist nicht aufKommunikationscontroller beschränkt wie beim SubareaSNA. Eine APPN-Dienstklasse gestattet es der Topologie-datenbank, einen Baum für jeden Dienst vorzuhalten, der alle

Bild 35.2:Eine Dienst-klassentabelleenthält beimSubarea Rou-ting Datenüber virtuelleRouten undÜbertragungs-prioritäten


Routen und den jeweiligen Aufwand verfolgt. Weiterhin bieteteine APPN-Dienstklasse eine Konfigurationsmöglichkeit fürdie Kontrolle des Dienstklassenbäumen zugeordneten Spei-chers. Das Format für einen Eintrag in der Dienstklassen-tabelle beim APPN Routing ist im Bild 35.3 dargestellt.

Einträge in der Dienstklassentabelle bestehen beim APPNRouting aus dem Dienstklassennamen (COS Name), einem In-dex, der APPN-Übertragungspriorität (TPRI), Charakteristika(C1…Cn) und einem Weight Field (WF) oder Gewichtungsfeldder APPN-Dienstklasse.

Der Dienstklassenname ist eine Standardbezeichnung wie bei-spielsweise SEC3, der durch Konventionen geregelt ist.

TPRI

TPRI

TPRI

VRN

Index

VRN

COS Name

C1

C1

C1

C2

C1

Charakteristika

C2

Cn

Cn

Cn

WF

WF

WF

Der Eintrag im Indexfeld ermöglicht das Speichern von undZugreifen auf berechnete Gewichtungswerte für Routenkom-ponenten. Dieser Eintrag zeigt auf den Eintrag im Gewich-tungsarray der Dienstklasse, in dem die Gewichtungen für dieDienstklasse gespeichert sind.

APPN TPRI weist die Priorität des Datenflusses für eine Ar-beitssitzung von einer logischen Einheit zu einer anderen logi-schen Einheit über eine explizite Route aus. Es wird nur einTPRI-Feld für jeden Eintrag in der Dienstklassentabelle ange-geben. APPN TPRI sorgt dafür, daß der über eine gegebeneArbeitssitzung mit derselben Dienstklasse erfolgende Daten-verkehr sich in einem bestimmten APPN-Netzwerk mit dersel-ben Übertragungspriorität bewegt.

Die Eigenschaften für Knoten und Übertragungsgruppe beste-hen aus einer benutzerdefinierten Auflistung von Charakteri-stika, die für eine ausgewiesene Dienstklasse geeignet sind.

Bild 35.3:Eine Dienst-

klassentabellekann beim

APPN Routingbesondere In-formationen

über Charak-teristiken und

Routengewich-tung enthalten


Jede Zeile definiert entweder eine Reihe von Eigenschaften füreinen Knoten oder für eine Übertragungsgruppe. Die Einträgekönnen Angaben zur Sicherheit, zu den Kosten pro Verbin-dungsdauer und zur verfügbaren Kapazität enthalten. Das eineCharakteristik repräsentierende Feld setzt sich aus einer Reihezulässiger Werte zusammen.

Das Gewichtungsfeld einer APPN-Dienstklasse ermöglicht esRoutes Selection Services (RSS), einer gegebenen möglichenRoutenkomponente (Knoten oder Übertragungsgruppe) eineGewichtung zuzuordnen. Ein RSS greift auf das Gewichtungs-feld zurück, um eine relative Vorliebe für eine bestimmte Rou-tenkomponente zu ermitteln. Das Gewichtungsfeld kann eineKonstante oder die Bezeichnung einer Funktion enthalten, aufdie der RSS bei der Gewichtungsberechnung zurückgreift.

35.6 IBM SNA – Subarea Routing

Die logischen SNA-Bereiche und die Knotenadressierung sindzwei zentrale Komponenten beim herkömmlichen Routing inSNA-Umgebungen. Dieser Abschnitt behandelt diese Themenim Kontext des herkömmlichen SNA-Netzwerk-Betriebs.

SNA-Netzwerke werden in logische Bereiche unterteilt: Sub-areas und Domains. Subareas bestehen aus einem Subarea-Knoten und der an diesem angebundenen Peripherie. Domainsbestehen aus einem System Services Control Point (SSCP) unddenjenigen Netzwerk-Ressourcen, die dieser kontrollierenkann. SSCPs aus unterschiedlichen Domains können miteinan-der kooperieren, um Ausfälle des Hostprozessors zu kompen-sieren. Im Bild 35.4 ist das Verhältnis zwischen Subareas undDomains im Kontext des SNA Subarea Routing dargestellt.

Knotenadressen werden als Adressen von Subarea- und Peri-pherieknoten kategorisiert. Adressen von Subarea-Knoten sindglobal und müssen im gesamten Netzwerk eindeutig sein.Diese Adressen werden einer an das Netzwerk angehängtenEinheit beim Aktivieren zugewiesen. Adressen von Subarea-Knoten setzen sich im allgemeinen aus einem Anteil für dieSubarea und einem Anteil für die Einheit zusammen. Alle andas Netzwerk angehängten Einheiten innerhalb einer gegebe-nen Subarea teilen sich dieselbe Subarea-Adresse, besitzenaber unterschiedliche Elementadressen.


Domain 1 Domain 2

Terminals

Aufbau-steuereinheit

Host

Subarea 1 Subarea 3

Subarea 2 Subarea 4

Adressen von Peripherieknoten, die als lokale Adressen be-trachtet werden, unterscheiden sich in Abhängigkeit davon, obes sich um einen T2- oder T2.1-Knoten handelt. T2-Adressenbeziehen sich auf an das Netzwerk angehängte Einheiten undwerden statisch zugewiesen, wohingegen T2.1-Adressen dyna-misch für die Dauer einer Arbeitssitzung zugewiesen werdenund die Arbeitssitzung statt der an das Netzwerk angehängtenEinheit ausweisen. Adressen von Peripherieknoten werdenauch als lokale Arbeitssitzungs-IDs bezeichnet.

35.7 IBM Advanced Peer-to-Peer Networking(APPN) Routing

Das APPN Routing erfolgt dynamisch und basiert auf einemaus den von allen APPN-Netzknoten erhaltenen Angaben be-rechneten Pfad mit der geringsten Gewichtung. Jeder APPN-Netzknoten ist für die Meldung von Änderungen in seinerlokalen Topologie (d.h. der Knoten selber und die angebunde-nen Verbindungen) verantwortlich. Topologieinformationenwerden so lange übergeben, bis alle APPN-Knoten sie erhal-ten. Wenn ein Knoten Daten erhält, über die er bereits verfügt,beendet er das Weiterleiten der Daten an andere Knoten.Vervielfältigte Informationen werden durch eine Überprüfung

Bild 35.4:Subareas be-stehen beim

SNA SubareaRouting inner-

halb vonDomains


der Update-Sequenznummer erkannt. Im Bild 35.5 ist darge-stellt, wie APPN-Netzknoten in das allgemeine Schema einerAPPN-Umgebung mit Endknoten und niederschwelligen Netz-knoten passen.

Das APPN Routing wird durch mehrere zugrundeliegendeFunktionen und Fähigkeiten ermöglicht. Dazu gehören dasNode Type 2.1 Routing, das Dependent Logical Unit Reque-ster/Server (DLUR/S) Routing, Verbindungsnetzwerke undÜbergangsknoten.

APPN-Netzwerk

End-knoten

niederschwelligerNetzwerkknoten

End-knoten

Netzwerk-knoten

35.7.1 IBM APPN – Node Type 2.1 Routing

Das Node Type 2.1 Routing betrifft den Routingverkehr voneinem oder mehreren APPN-Netzknoten. Es werden zweiNode-Type-2.1-Routingvorgänge unterstützt: das Inter-mediate Session Routing (ISR) und das High PerformanceRouting (HPR).

Intermediate Session Routing (ISR)

Der Vorgang des ISR bezieht BIND-Requests und -Responsesvon Verbindungssitzungen ein, die von Netzknoten zu Netz-knoten weitergeleitet werden. In dieser Umgebung werden Sy-stemverbindungen aufgebaut und anstelle von Routing-Tabel-len beim APPN verwendet. Mit ISR wird eine Karte mit der IDund dem Anschluß der Arbeitssitzung von einer Seite des Kno-

Bild 35.5:APPN-Netz-knoten stellenVerbindungenmit Endkno-ten, nieder-schwelligenund anderenNetzknoten her


tens zur anderen angelegt. Eine eindeutige Sitzungs-ID imHeader der Sitzungsverbindung wird mit einer ausgehendenID getauscht und anschließend vom passenden Anschluß ver-schickt.

Zu den von ISR unterstützten Eigenschaften der Subarea SNAgehören die Aufbereitung von Fehlern bei der Verbindung vonKnoten zu Knoten und der Datenflußkontrolle sowie dasUmlenken von Arbeitssitzungen um Netzwerk-Ausfälleherum. Die Aufbereitung von Fehlern bei der Verbindung vonKnoten zu Knoten und der Datenflußkontrolle werden alsredundant und unnötig angesehen, da diese Vorgänge denDurchsatz von Endsystem zu Endsystem verringern.

High Performance Routing (HPR)

Das Protokoll des High Performance Routing (HPR), einerAlternative zu ISR, basiert auf den beiden Schlüsselkomponen-ten Rapid Transport Protocol (RTP) und Automatic NetworkRouting (ANR). Bei RTP handelt es sich um ein zuverlässiges,verbindungsbezogenes Protokoll, das die Zustellung sicher-stellt und von Endsystem zu Endsystem auftretende Netzwerk-Fehler sowie die Datenflußkontrolle behandelt. RTP erzeugtneue Routen nach einem Netzwerk-Ausfall. Bei ANR handeltes sich um einen verbindungslosen Dienst, der für quellen-geleitete Dienste von Knoten zu Knoten verantwortlich ist.

Die RTP-Schicht wird nur an den Grenzen eines APPN-Netz-werks aufgerufen. Von dazwischenliegenden Knoten wird le-diglich die ANR-Schicht aufgerufen. RTP-Knoten richtenRTP-Verbindungen ein, um Sitzungsdaten weiterzuführen.Sämtlicher Datenverkehr für eine einzelne Sitzung bewegt sichüber dieselbe RTP-zu-RTP-Verbindung und wird im Multi-plex-Verfahren mit dem Datenverkehr aus anderen Arbeits-sitzungen übertragen, die dieselbe Verbindung verwenden. ImBild 35.6 ist die gesamte Architektur einer HPR-basiertenRoutingumgebung dargestellt.


APPN/HPR-Netzwerk

EK

EK

TokenRing

EK

Endknoten(EK)

TokenRing

EK

RTP

ANR

APPN-Netzwerk-

knoten

RTP

ANR

APPN-Netzwerk-

knoten

ANR

APPN-Netzwerk-

knoten

ANR

APPN-Netzwerk-

knoten

ANR

APPN-Netzwerk-

knoten

Ein typischer HPR-Routingvorgang umfaßt mehrere Schritte.Zuerst wird unter Einsatz von ISR eine Route ausgewählt. Umeine Verbindung zwischen den angrenzenden RTP-Knoten ein-zurichten, wird entweder auf eine bestehende RTP-zu-RTP-Verbindung zurückgegriffen, oder es wird ein Route ServicesRequest (RSR) verschickt. Die zurückgelieferte Route ServicesReply (RSP) enthält Informationen, die einen Hin- und einenRückpfad durch das Netzwerk anzeigen.

Pfade stellen die hinund zurückführenden Anschlußaufli-stungen dar und enthalten die in jedem ANR-Knoten verwen-dete Anschluß-ID. Diese Auflistungen werden von jederNachricht mitübertragen, wodurch die Notwendigkeit fürRouting-Tabellen oder Sitzungsverbindungen in den ANR-Knoten wegfällt.

HPR sorgt bei Verbindungsausfall für eine Wiederherstellung.Wenn eine Verbindung ausfällt und ein alternativer Pfad zwi-schen den RTP-Endpunkten für eine bestimmte Dienstklassevorhanden ist, kann eine neue RTP-zu-RTP-Verbindung aus-gewählt werden, und eine Sitzung kann ohne Unterbrechungumgeleitet werden. Wenn keine Verbindung über den neuenPfad besteht, werden RSR- und RSP-Nachrichten verschickt,um die neue Anschlußauflistung zu erhalten. Das erneute Sen-den eines BIND ist nicht erforderlich, da die Arbeitssitzungnicht unterbrochen wurde.

Bild 35.6:RTP wird nurvon an APPNgrenzendenNetzknotenunterstützt


Die Datenflußkontrolle greift in einer HRP-Umgebung aufeine Technik zurück, die als anpassungsfähige ratenbasierteDatenflußkontrolle bezeichnet wird. Die anpassungsfähigeratenbasierte Datenflußkontrolle überwacht und kontrolliertdas Aufkommen des in das Netzwerk übertragenen Datenver-kehrs. Unter ihr tauschen die sendenden und empfangendenRTP-Knoten in regelmäßigen Intervallen Nachrichten aus. Derin das Netzwerk übertragene Datenverkehr wird an die Netz-werk-Bedingungen angepaßt.

35.7.2 IBM APPN – DLUR/S Routing

Beim Dependent Logical Unit Requester/Server (DLUR/S)handelt es sich um eine APPN-Eigenschaft, die es gewährtemSNA-Datenverkehr ermöglicht, sich in einem APPN-Netzwerkfortzubewegen.

Unter DLUR/S wird eine Client-Server-Beziehung zwischeneinem Dependent Logical Unit Server (DLUS) und einemDependent Logical Unit Requester (DLUR) eingerichtet. Beieinem DLUS handelt es sich typischerweise um eineACF/UTAM4.2-Einheit, bei einem DLUR typischerweise umeinen Router. Ein Paar von LU-6.2-Sitzungen überträgt diegewährten SNA-Kontrollnachrichten. Die in einer APPN-Umgebung nicht identifizierten Nachrichten werden in derLU-6.2-Sitzung gekapselt. Die Nachrichten werden dann vonDLUR entkapselt und an die gewährte SNA LU übergeben.Die Aufnahme der DLU-Sitzung wird anschließend an denDLUS übergeben und von ihm als gewährter Datenverkehrbearbeitet. Der DLUS verschickt eine Nachricht an den An-wendungshost, und der Anwendungshost verschickt dasBIND. Schließlich bewegen sich die gewährten SNA-Datenganz natürlich mit dem APPN-Datenverkehr fort.

35.7.3 IBM-APPN-Verbindungsnetzwerk

Bei einem IBM-APPN-Verbindungsnetzwerk handelt es sichum ein logisches Konstrukt, auf das zurückgegriffen wird, umeine direkte Verbindung zwischen APPN-Endknoten ohne den


Konfigurationsoverhead beim Definieren von direkten Verbin-dungen zwischen jedem Paar von Endknoten bereitzustellen.Im allgemeinen beginnt der Vorgang des Erstellens eines Ver-bindungsnetzwerks, sobald ein LOCATE-Request von einemEndknoten empfangen wird.

Ein Netzknoten wird dann verwendet, um das im LOCATE-Request angegebene Ziel ausfindig zu machen. Wenn derNetzknoten feststellt, daß beide Endknoten (Quelle und Ziel)am gleichen Transportmedium hängen (beispielsweise TokenRing), kommt ein virtueller Knoten zum Einsatz, um die bei-den Endpunkte zu verbinden und ein Verbindungsnetzwerkherzustellen. Der Netzknoten definiert den Sitzungspfad alseine direkte Verbindung vom Endknoten 1 über den virtuellenKnoten zum Endknoten 2, und anschließend darf der Daten-verkehr fließen.

35.7.4 IBM APPN – Übergangsknoten

Bei einem Übergangsknoten handelt es sich um eine Einheit,die es ermöglicht, mehrere APPN-Netzwerke miteinander zuverbinden. Derzeit sind Übergangsknoten nur als ACF/VTAMund OS/400 implementiert. Übergangsknoten sind für das Zu-sammenknüpfen von Verzeichnis- und Topologiedatenbankenfür Verbindungsnetzwerke sowie für das Aufbauen von BIND-Requests zum Anzeigen gesonderter Routen in jedem Netz-werk verantwortlich.

Durch Übergangsknoten werden die Topologie- und Verzeich-nisdatenbanken auf Netzknoten auf den für einzelne Subnetzeanstelle des zusammengesetzten Netzwerks benötigten Um-fang reduziert. Weiterhin werden das Netzwerk durchlaufendeArbeitssitzungen über den Übergangsknoten geleitet. Das Bild35.7 verdeutlicht die Lage von Übergangsknoten (ACF/VTAMund OS/400) in einer APPN-Umgebung mit mehreren Netz-werken.


APPN-Netzwerk

APPN-Netzwerk

APPN-Netzwerk

OS/400

ACF/VTAM

Bild 35.7:Übergangs-

knoten(ACF/VTAMund OS/400)

können APPN-Netzwerkeverbinden

36 Interior Gateway Routing Protocol (IGRP)

36.1 Hintergrund

Beim Interior Gateway Routing Protocol (IGRP) handelt essich um ein Mitte der 1980er Jahre von Cisco Systems, Inc.entwickeltes Routing-Protokoll. Ciscos Hauptziel bei der Er-stellung von IGRP bestand darin, ein stabiles Protokoll für dasRouting innerhalb eines autonomen Systems (AS) bereitzustel-len.

Mitte der 1980er Jahre war das Routing Information Protocol(RIP) das beliebteste Routing-Protokoll zwischen autonomenSystemen. Obgleich RIP für das Routing in verhältnismäßighomogenen Internetzwerken, mit kleinem bis gemäßigtemUmfang ziemlich brauchbar war, wurden seine Grenzen durchdas Wachstum der Netzwerke erreicht. Insbesonderebeschränkte die niedrige Grenze des RIP für den Hop-Count(16) die Größe von Internetzwerken und seine einzige Metrik(Hop-Count) sorgte nicht gerade für eine große Flexibilitätbeim Routing in komplexen Umgebungen. Die Beliebtheit vonCisco-Routern und die Stabilität von IGRP brachten vieleOrganisationen mit großen Internetzwerken dazu, RIP durchIGRP zu ersetzen.

Ciscos erste Implementierung von IGRP lief in Netzwerkenmit dem Internet Protocol (IP). IGRP wurde allerdings so ent-worfen, daß es in jeder beliebigen Netzwerk-Umgebung funk-tioniert, und schon bald portierte Cisco es für Netzwerke mitdem OSI Connectionless Network Protocol (CLNP). Anfang

KAPITEL 36Interior Gateway Routing Protocol (IGRP)


der 1990er Jahre entwickelte Cisco das Enhanced IGRP, umdie Effizienz im Betrieb von IGRP zu verbessern. In diesemKapitel werden der grundlegende Entwurf und die Implemen-tierung von IGRP beschrieben. Enhanced IGRP wird im Kapi-tel 34, »Enhanced IGRP« behandelt.

36.2 Eigenschaften von IGRP

Bei IGRP handelt es sich um ein auf dem Distance-Vector-Ver-fahren beruhendes Interior-Gateway-Protokoll (IGP). Auf demDistance-Vector-Verfahren beruhende Routing-Protokolle for-dern jeden Router dazu auf, ihre gesamte oder einen Teil ihrerRouting-Tabelle in regelmäßigen Abständen in einer Routing-Update-Nachricht an jeden seiner benachbarten Router zuversenden. Da sich die Routing-Informationen durch dasNetzwerk hindurch stark vermehren, können Router Distan-zen zu sämtlichen Knoten innerhalb des Internetzwerks be-rechnen.

Routing-Protokolle nach dem Distance-Vector-Verfahren wer-den häufig Routing-Protokollen nach dem Link-State-Verfah-ren entgegengestellt, die lokale Verbindungsinformationen analle Knoten im Internetzwerk verschicken. Eine Besprechungvon Open Shortest Path First (OSPF) und Intermediate Sy-stem-to-Intermediate System (IS-IS), zwei beliebten Routing-Algorithmen für das Link-State-Verfahren, finden Sie in Kapi-tel 40, »Open Shortest Path First (OSPF)« bzw. Kapitel 39,»Open Systems Interconnection (OSI) Routing Protocol«.

IGRP verwendet eine Kombination (Vektor) von Metriken.Verzögerungszeit des Internetzwerks, Bandbreite, Zuverläs-sigkeit und Last gehen alle als Faktor in die Entscheidung fürdas Routing ein. Netzwerk-Administratoren können die Ge-wichtungsfaktoren für jede dieser Metriken festlegen. IGRPverwendet entweder die vom Administrator gesetzten oder dievorgegebenen Gewichtungen, um optimale Routen automa-tisch zu berechnen.

IGRP sieht einen großen Wertebereich für seine Metriken vor.Für Zuverlässigkeit und Last können beispielsweise Wertezwischen 1 und 255 angenommen werden; für Bandbreitekönnen Werte angenommen werden, die für Geschwindigkei-ten von 1200 bps bis zu 10 Gigabit pro Sekunde stehen, wäh-

Kapitel 36 • Interior Gateway Routing Protocol (IGRP) 475

rend für die Verzögerungszeit jeder beliebige Wert zwischen 1und 2 hoch 24 angenommen werden kann. Große Werteberei-che für Metriken ermöglichen eine angemessene Einstellungder Metriken in Internetzwerken mit stark schwankenden Per-formance-Eigenschaften. Am wichtigsten dabei ist dieTatsache, daß die Metrikkomponenten in einem vom Benutzerdefinierbaren Algorithmus vereint sind. Als eine Folge davonkönnen Netzwerk-Administratoren die Routenauswahl aufintuitive Weise beeinflussen.

Für eine größere Flexibilität gestattet IGRP das Routing übermehrere Pfade (Multipath). Zwei Leitungen mit gleicherBandbreite können einen einzelnen Verkehrsstrom in jeder-ge-gen-jeden-Manier betreiben, wobei automatisch auf die zweiteLeitung übergewechselt wird, wenn eine Leitung wegfällt.Mehrere Pfade können selbst dann verwendet werden, wennsich die Metriken der Pfade unterscheiden. Wenn ein Pfad bei-spielsweise dreimal besser ist als ein anderer, da seine Metrikum das Dreifache niedriger ist, wird der bessere Pfad dreimalso häufig verwendet. Für mehrfache Pfade werden nur Routenverwendet, deren Metriken innerhalb eines bestimmten Be-reichs der besten Route liegen.

36.2.1 Stabilitätsmerkmale

IGRP bietet eine Reihe von Merkmalen, die zu einer erhöhtenStabilität führen sollen: Hold-Downs, Split-Horizons und Poi-son-Reverse-Updates.

Hold-Downs werden eingesetzt, um reguläre Update-Nach-richten davon abzuhalten, eine Route wiedereinzusetzen, dieunbrauchbar geworden sein könnte. Wenn ein Router ausfällt,entdecken dies die angrenzenden Router durch das Fehlen re-gulär eingeplanter Update-Nachrichten. Diese Router bestim-men dann neue Routen und verschicken Routing-Update-Nachrichten, um ihren Nachbarn die Routenänderung mitzu-teilen. Diese Handlung löst eine Welle von Updates aus, diedurch das Netzwerk sickern. Diese ausgelösten Updates kom-men nicht sofort bei jedem Gerät im Netzwerk an; somit ist esmöglich, daß ein Gerät, dem der Netzwerk-Ausfall noch mit-geteilt werden muß, eine reguläre Update-Nachricht (die an-zeigt, daß eine gerade ausgefallene Route noch brauchbar ist)an ein Gerät verschickt, das den Netzwerk-Ausfall bereits mit-


bekommen hat. In diesem Fall würde das spätere Gerät falscheRouting-Informationen erhalten (und möglicherweise verbrei-ten). Hold-Downs teilen Routern mit, alle Änderungen füreinige Zeit zurückzuhalten, die sich auf Routen auswirkenkönnten. Die Zeitspanne für das Hold-Down ist üblicherweiseso berechnet, daß sie etwas größer ausfällt als die für eineAktualisierung des gesamten Netzwerks mit einer Routing-Änderung benötigte Zeit.

Split-Horizons ziehen ihren Nutzen aus der Annahme, daß esniemals sinnvoll ist, Routeninformationen in die Richtung zu-rückzuschicken, aus der sie kamen. Das Bild 36.1 veranschau-licht die Split-Horizon-Regel. Router 1 (R1) macht anfangsbekannt, daß er über eine Route zum Netzwerk A verfügt. Esgibt keinen Grund für Router 2 (R2), diese Route in sein anR1 zurückgeschicktes Update aufzunehmen, da sich R1 näheran Netzwerk A befindet. Die Split-Horizon-Regel besagt, daßR2 diese Route aus allen an R1 gesendeten Updates streichensoll. Diese Regel hilft dabei, Routing-Scheifen zu vermeiden.Nehmen wir beispielsweise an, die Schnittstelle von R1 zumNetzwerk A fällt aus. Ohne Split-Horizons fährt R2 damitfort, R1 darüber zu informieren, daß er das Netzwerk A (überR1) erreichen kann. Wenn R1 nicht intelligent genug ist, kanner tatsächlich die Route von R2 als Alternative zu seiner fehl-geschlagenen direkten Verbindung aufgreifen und eine Rou-ting-Schleife verursachen. Obgleich Hold-Downs solche Si-tuationen vermeiden sollten, sind Split-Horizons in IGRP im-plementiert, da sie für eine zusätzliche Stabilität des Algorith-mus sorgen.

Router 2Router 1

Netzwerk A Netzwerk B

Split-Horizons sollten Routing-Schleifen zwischen benachbar-ten Routern vermeiden, aber Poison-Reverse-Updates sindnotwendig, um größere Routing-Schleifen zu bekämpfen. DasAnwachsen von Routing-Metriken weist im allgemeinen aufRouting-Schleifen hin. Dann werden Poison-Reverse-Updates

Bild 36.1:Die Split-Hori-zon-Regel hilftbei der Vermei-dung von Rou-

ting-Schleifen

Kapitel 36 • Interior Gateway Routing Protocol (IGRP) 477

verschickt, um die Route zu entfernen und in den Hold-Down-Zustand zu versetzen. Bei der IGRP Implementierungdurch Cisco werden Poison-Reverse-Updates verschickt, fallseine Routenmetrik um den Faktor 1,1 oder größer angewach-sen ist.

36.2.2 Timer

IGRP unterhält eine Reihe von Timern und Variablen, dieZeitabschnitte enthalten. Dabei handelt es sich um einenUpdate-Timer, einen Invalid-Timer, einen Zeitabschnitt für dieHold-Time und einen Flush-Timer. Der Update-Timer gibt an,wie oft Routing-Update-Nachrichten verschickt werden sollen.Der von IGRP vorgegebene Wert für diese Variable beträgt 90Sekunden. Der Invalid-Timer gibt an, wie lange ein Routerbeim Fehlen von Routing-Update-Nachrichten für eine be-stimmte Route warten soll, bevor diese Route für unzulässigerklärt wird. IGRP gibt für diese Variable das Dreifache desUpdate-Zeitabschnitts vor. Die Variable Hold-Time gibt denZeitabschnitt für ein Hold-Down an. IGRP gibt für diese Va-riable das Dreifache des Update-Zeitabschnitts plus 10 Sekun-den vor. Schließlich zeigt der Flush-Timer an, wieviel Zeit ver-streichen soll, bevor eine Route aus der Routing-Tabellegelöscht werden soll. IGRP gibt hierfür das Siebenfache desUpdate-Zeitabschnitts vor.

37 Internet Protocol (IP) Multicast

37.1 Hintergrund

Beim Internet Protocol (IP) Multicast handelt es sich um eineTechnik, die es ermöglicht, den IP-Verkehr von einer odermehreren Quellen aus zu senden und ihn mehreren Zielen zu-zustellen. Anstatt einzelne Pakete an jedes Ziel zu schickenwird ein einzelnes Paket an eine Multicast-Gruppe geschickt,die durch eine einzige IP-Zielgruppenadresse ausgewiesen ist.Das IP Multicast-Routing kam auf, weil Unicast- und Broad-cast-Techniken den Anforderungen neuer Anwendungen nichtgewachsen sind. Die Adressierung beim Multicast unterstütztbeispielsweise die Übertragung eines einzelnen IP-Datagrammsan mehrere Hosts. Dieses Kapitel beschäftigt sich mit denwichtigsten Möglichkeiten beim Multicast-Routing. Im Bild37.1 ist der allgemeine Aufbau einer Multicast-Umgebungdargestellt.

37.2 Internet Group Membership Protocol(IGMP)

Eine wesentliche Komponente beim IP Multicast stellt das In-ternet Group Membership Protocol (IGMP) dar. IGMP greiftfür die Erzeugung von Multicast-Gruppen auf Class-D-IP-Adressen zurück und ist in der RFC 1112 definiert. IGMPwird eingesetzt, um einzelne Hosts in einer Multicast-Gruppedynamisch mit einer Class-D-Adresse zu registrieren. Hosts

KAPITEL 37Internet Protocol (IP) Multicast


Internet

stellen eine Gruppenmitgliedschaft fest, indem sie IGMP-Nachrichten verschicken, und der Datenverkehr wird an sämt-liche Mitglieder dieser Multicast-Gruppe weitergeleitet. UnterIGMP achten Router auf IGMP-Nachrichten und verschickenregelmäßig Query-Pakete, um festzustellen, welche Gruppenin bestimmten LANs aktiv oder inaktiv sind. Router kommu-nizieren miteinander, indem sie ein oder mehrere Protokollefür den Aufbau von Multicast-Routen für jede Gruppe einset-zen.

Protokoll NotwendigesUnicast-Protokoll

Verbreitungsalgorithmus

PIM (Dense-Modus) beliebig Reverse Path Flooding(RPF)

PIM (Sparse-Modus) beliebig RPFDVMRP internes, RIP-artiges

Routing-ProtokollRPF

MOSPF Open Shortest PathFirst (OSPF)

Shortest Path First (SPF)

37.3 Protokolle für das IP Multicast-Routing

Für das Entdecken von Multicast-Gruppen und den Aufbauvon Routen für jede Gruppe wird auf mehrere Routing-Proto-kolle zurückgegriffen. Bei diesen handelt es sich um: Protocol-Independent Multicast (PIM), Distance-Vector Multicast

Bild 37.1:IP Multicast

stellt ein Mittelzur Verfügung,

um mehrerenZielen Daten-verkehr zuzu-

stellen, der einehohe Band-

breite benötigt

Tabelle 37.1:Zusammenfas-sung der Mög-lichkeiten beim

Multicast-Routing

Kapitel 37 • Internet Protocol (IP) Multicast 481

Routing Protocol (DVMRP) und Multicast Open ShortestPath First (MOSPF). In der Tabelle 37.1 sind die Möglichkei-ten für das Multicast-Routing mit den notwendigen Anforde-rungen an Unicast und den Verteilungsalgorithmen zusam-mengefaßt.

37.3.1 Protocol-Independent Multicast (PIM)

Das Protocol-Independent Multicast (PIM) wird in einemRFC-Entwurf für das Internet behandelt (die Diskussionenfinden in der IETF Multicast Routing Working Group statt).Es umfaßt zwei unterschiedliche Verhaltensmodi für Umge-bungen mit dichtem (dense) und spärlichem (sparse) Verkehr:den Dense-Modus und den Sparse-Modus.

Der Dense-Modus von PIM greift auf einen Vorgang der um-gekehrten Pfadverteilung (Reverse Path Flooding = RPF) zu-rück, der dem DVMRP ähnelt. Es gibt allerdings dennoch Un-terschiede zwischen dem Dense-Modus von PIM und DVMRP.PIM benötigt beispielsweise kein bestimmtes Unicast-Proto-koll, um festzustellen, welche Schnittstelle zur Quelle einesDatenstroms zurückführt. DVMRP verwendet sein eigenesUnicast-Protokoll, während PIM auf jedes beliebige Unicast-Protokoll zurückgreift, das vom Internetzwerk verwendetwird.

Der Sparse-Modus von PIM wurde für Internetzwerke mitvielen Datenströmen und relativ wenigen LANs optimiert. Erdefiniert einen Treffpunkt, der anschließend als Registrie-rungsstelle verwendet wird, um das Routing von Paketen zuerleichtern.

Wenn ein Sender Daten übertragen will, schickt der Router-knoten des ersten Hop (hinsichtlich der Quelle) Daten an denTreffpunkt. Wenn ein Empfänger Daten erhalten will, regi-striert sich der Router des letzten Hop (hinsichtlich des Emp-fängers) beim Treffpunkt. Anschließend kann ein Datenstromvom Sender über den Treffpunkt weiter zum Empfänger flie-ßen. Auf dem Pfad befindliche Router optimieren den Pfadund beseitigen jeden unnötigen Hop automatisch, sogar amTreffpunkt.


37.3.2 Distance-Vector Multicast Routing Protocol(DVMRP)

Das Distance-Vector Multicast Routing Protocol (DVMRP)greift auf ein Verfahren mit umgekehrter Pfadverteilung(Reverse Path Flooding = RPF) zurück und wird als Basis fürden Multicast Backbone (MBONE) des Internet eingesetzt.DVMRP ist in der RFC 1075 definiert und bringt einigeNachteile mit sich. Insbesondere ist DVMRP für eine schlechteNetzwerkskalierung berüchtigt, die ihre Ursache in der erneu-ten Verteilung (Reflooding) hat; dies gilt ganz besonders fürVersionen, in denen kein Mechanismus implementiert ist, umsich streichen zu lassen (Pruning). Weiterhin wirkt sich dereinfache Mechanismus für das Unicast-Routing von DVMRPauf dessen Skalierungsfähigkeiten aus.

Bei der umgekehrten Pfadverteilung (Reverse Path Flooding)verschickt ein Router nach Erhalt eines Pakets über alle Pfade(außer dem zum Ursprung zurückführenden Pfad) eine Kopiedes Pakets. Anschließend verschicken Router eine Pruning-Nachricht an die Quelle zurück, um den Datenstrom anzuhal-ten, falls der Router an ein LAN angebunden ist, das eine be-stimmte Multicast-Gruppe nicht empfangen möchte.

Auf die erneute Verteilung und das DVMRP Unicast wird beiden DVMRP-Vorgängen zur Pfadverteilung zurückgegriffen.Bei der erneuten Verteilung beliefern DVMRP-Router ein an-gebundenes Netzwerk regelmäßig erneut, um neue Hosts zuerreichen. Der Verteilungsmechanismus greift auf einen Algo-rithmus zurück, der die Verteilungshäufigkeit und die von ei-nem neuen Multicast-Gruppenmitglied benötigte Zeit zumEmpfangen des Datenstroms berücksichtigt. Dieses Verfahrenist einzigartig für DVMRP, ähnelt RIP allerdings darin, daß esauf dem Zählen der Hops basiert. Die Unicast-Umgebung vonDVMRP gestattet die Verwendung eines anderen Pfads als denfür den Multicast-Datenverkehr verwendeten.

37.3.3 Multicast Open Shortest Path First (MOSPF)

Bei Multicast Open Shortest Path First (MOSPF) handelt essich um eine Erweiterung von OSPF. Allgemein gesagt, ver-wendet MOSPF ein Unicast-Routing-Protokoll, bei dem jedem

Kapitel 37 • Internet Protocol (IP) Multicast 483

Router sämtliche verfügbaren Verbindungen bekannt seinmüssen.

Ein MOSPF-Router bestimmt von der Quelle aus Routen zuallen möglichen Gruppenmitgliedern einer bestimmten Multi-cast-Gruppe. MOSPF-Router enthalten Multicast-Informatio-nen in den Verbindungszuständen von OSPF. MOSPF be-stimmt die Routen für jedes Quelle/Multicast-Gruppen-Paar,sobald der Router Verkehr für dieses Paar erhält. Dabei wer-den die Routen so lange im Zwischenspeicher gehalten, biseine Änderung in der Topologie auftritt. Dann bestimmtMOSPF die Topologie erneut.

Für MOSPF haben sich mehrere Themen für die Implementie-rung herausgeschält und verlangen eine nähere Betrachtung.Zuerst einmal funktioniert MOSPF ausschließlich in Inter-netzwerken, die OSPF einsetzen. Weiterhin ist MOSPF am be-sten für Umgebungen mit verhältnismäßig wenigen Quelle/Gruppe-Paaren geeignet. MOSPF kann in Umgebungen, dieüber viele aktive Quelle/Gruppe-Paare verfügen oder instabilsind, die Route r-CPU beträchtlich beanspruchen.

38 NetWare Link Services Protocol (NLSP)

38.1 Hintergrund

Beim NetWare Link Services Protocol (NLSP) handelt es sichum ein mit dem Link-State-Verfahren arbeitendes Routing-Protokoll von Novell, das entworfen wurde, um die mit demIPX Routing Information Protocol (RIP) und dem begleiten-den Service Advertisement Protocol (SAP) verbundenen Ein-schränkungen zu überwinden. NLSP basiert auf dem OSI-Intermediate-System-to-Intermediate-System-Protokoll (IS-IS)und wurde entworfen, um die ursprünglichen Routing-Proto-kolle RIP und SAP von Novell zu ersetzen, die entstanden sindals Internetzwerke lokal und verhältnismäßig klein waren.Solcherart sind RIP und SAP für die heutigen großen, globalenInternetzwerke nicht mehr geeignet. In diesem Kapitel erfolgteine Zusammenfassung der Vorgänge beim Routing sowie derProtokollkomponenten von NLSP.

Verglichen mit RIP und SAP bietet NLSP ein verbessertesRouting, eine höhere Effizienz und Skalierbarkeit. Außerdemsind NLSP-basierte Router abwärtskompatibel zu RIP-basier-ten Routern. NLSP-basierte Router verwenden ein zuverlässi-ges Zustellungsprotokoll, so daß für die Zustellung garantiertwird. Darüber hinaus erleichtert NLSP bessere Entscheidun-gen beim Routing, da NLSP-basierte Router eine vollständigeAbbildung des Netzwerks gespeichert haben und nicht nurInformationen über den nächsten Hop, wie sie RIP-basierteRouter verwenden. Die Routing-Informationen werden nurdann übertragen, wenn Änderungen in der Topologie aufgetre-

KAPITEL 38NetWare Link Services Protocol (NLSP)


ten sind und nicht alle 60 Sekunden, wie es bei RIP-basiertenRoutern unabhängig davon der Fall ist, ob sich die Topologiewirklich verändert hat. Weiterhin verschicken NLSP-basierteRouter Updates für Dienstinformationen nur dann, wenn sichDienste ändern und nicht alle 60 Sekunden, wie es unter SAPder Fall ist.

NLSP ist in mehrerlei Hinsicht brauchbar. Es ist insbesondereüber eine WAN-Verbindung von Nutzen, da die Unterstützungder Header-Komprimierung von IPX es möglich macht, denPaketumfang zu reduzieren. NLSP unterstützt außerdem dieMulticast-Adressierung, so daß Routing-Informationen nur anandere NLSP-Router geschickt werden und nicht an sämtlicheGeräte, wie es bei RIP der Fall ist.

Weiterhin unterstützt NLSP den Lastenausgleich über parallelePfade und verbessert die Verbindungsintegrität. Es überprüftregelmäßig Verbindungen auf ihre Unversehrtheit sowie dieDatenintegrität der Routing-Informationen. Wenn eine Ver-bindung ausfällt, wechselt NLSP auf eine andere Verbindungund aktualisiert die in jedem Knoten gespeicherten Datenban-ken für die Netzwerktopologie, sobald irgendwo in der Rou-ting-Area Änderungen bei den Verbindungen auftreten.

Hinsichtlich der Skalierbarkeit kann NLSP bis zu 127 Hopsunterstützen (RIP unterstützt bloß 15 Hops) und gestattet diehierarchische Adressierung von Netzknoten, wodurch Netz-werke Tausende von LANs und Servern enthalten können.

38.2 NLSP – hierarchisches Routing

NLSP unterstützt hierarchisches Routing mit Areas, Domainsund Komponenten des globalen Internetzwerks. Bei einer Areahandelt es sich um ein Ansammlung von verbundenen Netz-werken, die alle über dieselbe Area-Adresse verfügen. EineDomain ist eine Ansammlung von Areas, die zur gleichenOrganisation gehören. Ein globales Internetzwerk ist eine An-sammlung von Domains, die üblicherweise zu verschiedenenOrganisationen gehören, aber in einer engen Beziehung zuein-ander stehen. Areas können miteinander verbunden werden,um Routing-Domains zu bilden, und Domains können mitein-ander verbunden werden, um ein globales Internetzwerk zubilden.

Kapitel 38 • NetWare Link Services Protocol (NLSP) 487

Level 1 Routing

Level 2 Routing

Level 3 Routing

Area 1

Area 2

Routing Domain A

Routing Domain B

38.2.1 Leistungen des hierarchischen Routing

Das hierarchische Routing vereinfacht den Ausbau einesNetzwerks, da die von jedem Router für das Weiterleiten vonPaketen innerhalb einer Domain zu speichernde und zu bear-beitende Informationsmenge reduziert wird. Ein Level-1-Rou-ter braucht nur detaillierte Informationen über seine eigeneArea vorzuhalten, statt Informationen über den Verbindungs-zustand für jeden Router und jedes Netzwerksegment in seinerDomain zu speichern. Für den Austausch von Datenverkehrmit anderen Areas braucht ein Level-1-Router lediglich dennächsten Level-2-Router ausfindig zu machen. Den Areas ge-ben Level-2-Router bloß die Area-Adresse(n) der zu ihnen ge-hörenden Areas bekannt, nicht aber ihre gesamte Datenbankmit Verbindungszuständen. Level-3-Router agieren entspre-chend auf der Ebene von Domains.

38.2.2 NLSP – angrenzende Umgebung

Durch den Austausch von Hello-Paketen ermittelt ein Routerdie Erreichbarkeit seiner Nachbarn, und auf diese Informatio-nen greift er zurück, um seine angrenzende Umgebung aufzu-bauen. Bei der angrenzenden Umgebung handelt es sich umeine vom Router vorgehaltene Aufzeichnung über den Zu-stand seines Anschlusses mit einem Nachbarn und den Attri-buten des benachbarten Routers. Der Router speichert dieseDatensätze in seiner Umgebungsdatenbank.

Die Verfahren zum Aufbau der angrenzenden Umgebung vari-ieren in Abhängigkeit davon, ob der Router die angrenzendeUmgebung über ein WAN oder ein LAN aufbaut und wartet.

Bild 38.1:NLSP definiertdrei Ebenendes Routing


Für den Aufbau der angrenzenden Router-Umgebung über einWAN muß zuerst die zugrundeliegende vermittelnde Verbin-dung eingerichtet werden (weitere Einzelheiten hängen dabeivom Medium ab). Die Router tauschen anschließend mittelsdes IPX-WAN-Version-2-Protokolls Identitäten miteinanderaus und legen bestimmte operationale Eigenschaften der Ver-bindung fest. Es werden Hello-Pakete ausgetauscht, und dieRouter aktualisieren ihre Umgebungsdatenbanken. Anschlie-ßend tauschen die Router sowohl Link-State-Pakete (LSPs),die den Zustand ihrer Verbindungen beschreiben, als auchIPX-Datenpakete über die Verbindung aus. Um eine WAN-Verbindung aufrechtzuerhalten, greift der Router für jedeangrenzende Umgebung auf eine Zustandsvariable zurück, dieanzeigt, ob die Verbindung aktiv oder inaktiv ist bzw. initiali-siert wird. Wenn der Router innerhalb der von einem Hold-Timer angegebenen Zeit nichts von einem Nachbarn hört,generiert er eine die Inaktivität der Verbindung anzeigendeNachricht und streicht die angrenzende Umgebung.

Hello-Pakete im WAN ermöglichen es Routern, die Identitätenuntereinander auszumachen, zu entscheiden, ob sie sich inderselben Routing-Area befinden, und festzustellen, ob sichandere Router und Verbindungen in Betrieb befinden. EinRouter verschickt Hello-Pakete, wenn eine Strecke zum erstenMal eingerichtet wird, ein Timer abläuft oder sich die Inhaltedes nächsten zu übertragenden Hello-Pakets von denen deszuvor von diesem System übertragenen Hello-Pakets unter-scheiden (und eine oder mehrere Sekunden seit dem vorheri-gen Hello-Paket vergangen sind). Hello-Paket werden so langeverschickt wie eine Strecke besteht.

Aufbau einer neuen angrenzenden WAN-Umgebung

Ein typischer Anfangsvorgang zwischen zwei Routern (A undB) mit einer WAN-Verbindung beginnt mit einer inaktivenVerbindung. Router A schickt ein die Inaktivität der Verbin-dung anzeigendes Hello-Paket an Router B, der seinen Verbin-dungszustand auf initialisierend ändert. Router B schickt eindie Initialisierung anzeigendes Hello-Paket an Router A. Dar-aufhin ändert auch Router A seinen Verbindungszustand zuinitialisierend und schickt ein entsprechendes Hello-Paket anRouter B. Router B ändert seinen Verbindungszustand zuaktiv und verschickt ein Hello-Paket, das diesen neuen


Zustand anzeigt. Schließlich ändert auch der Router A seinenVerbindungszustand zu aktiv.

Die Wartung angrenzender Umgebungen in LANs

Wenn eine Broadcast-Strecke wie beispielsweise ein 802.3-Ethernet oder 802.5-Token-Ring auf einem Router aktiviertist, beginnt der Router damit, Hello-Pakete zu verschickenund von anderen Routern im LAN entgegenzunehmen sowiedas Auswahlverfahren für den designierten Router zu starten.

Der designierte Router stellt in der Datenbank für Verbin-dungszustände das LAN als Ganzes dar, trifft zugunsten desGanzen Entscheidungen zum Routing und verursacht Link-State-Pakete für das LAN. So wird sichergestellt, daß sich derUmfang der von jedem Router zu erstellenden und zu verwal-tenden Datenbank für Verbindungszustände in einem vertret-baren Rahmen hält.

Regelmäßig verschickt jeder Router ein Multicast-Hello-Paketüber das LAN. Der Router mit der höchsten Priorität (einkonfigurierbarer Parameter) wird zum designierten Level-1-Router im LAN. Im Falle eines Gleichstands gewinnt der Rou-ter mit der höheren MAC-Adresse.

38.2.3 Hello-Pakete im LAN verschicken

Hello-Pakete gestatten es Routern auf der Broadcast-Strecke,die Identität der anderen Level-1-Router in derselben Routing-Area auf dieser Strecke herauszufinden. Die Pakete werden so-fort, wenn irgendeine Strecke aktiviert worden ist, an eine be-sondere Multicast-Zieladresse verschickt. Router achten beiankommenden Hello-Paketen auf diese Adresse.

38.3 NLSP – Vorgehen

Ein NLSP-Router bezieht bestimmte Informationen aus derDatenbank für die angrenzende Umgebung und fügt ihnen vorOrt abgeleitete Informationen hinzu. Mit diesen Informatio-nen erstellt der Router ein Link-State-Paket (LSP), das dieVerbindungszustände zu dessen direkten Nachbarn beschreibt.Alle von allen Routern der Routing-Area erzeugten LSPs ma-


chen gemeinsam die Datenbank für Verbindungszustände derArea aus.

Die NLSP-Spezifikation sieht vor, daß jeder Router eine Kopieder Datenbank für Verbindungszustände betreibt und daßdiese Kopien miteinander abgeglichen werden. Die Datenbankwird durch zuverlässig weitergeleitete LSPs in der gesamtenRouting-Area synchronisiert, sobald ein Router eine Änderungin der Topologie ausmacht. Zwei Methoden sorgen für eineWeiterleitung genauer Informationen über Topologieänderun-gen: Verteilung (Flooding) und Empfangsbestätigung.

Die Verteilung wird angestoßen, sobald ein Router eine Ver-änderung in der Topologie feststellt. Wenn eine solche Ände-rung erkannt wird, erstellt der Router ein neues LSP und über-trägt es an alle seine Nachbarn. In einem WAN stellen solcheLSPs gerichtete Pakete, in einem LAN Multicast-Pakete dar.Beim Empfang eines LSP verwendet der Router die Sequenz-nummer im Paket, um zu entscheiden, ob das Paket neuer alsdie aktuell in seiner Datenbank gespeicherte Fassung ist. Wennes ein neueres LSP ist, überträgt der Router es an alle seineNachbarn (außer auf der Strecke, über die das LSP empfangenwurde).

Das Verfahren der Empfangsbestätigung unterscheidet sich fürLANs und WANs. In WANs antwortet ein LSP empfangenderRouter mit einem Acknowledgment-Paket. In LANs tritt keinexplizites Acknowledgment auf, sondern der designierte Rou-ter verschickt im Multicast-Verfahren regelmäßig ein Com-plete Sequence Number Packet (CSNP) genanntes Paket, dasalle IDs und Sequenznummern der LSPs enthält, die er in sei-ner Datenbank für die gesamte Area aufbewahrt. Damit wirdsichergestellt, daß andere Router feststellen können, ob sienoch mit dem designierten Router synchronisiert sind odernicht.

38.4 NLSP – hierarchische Adressierung

NLSP unterstützt ein hierarchisches Adressierungsschema.Jede Routing-Area wird von zwei 32-Bit-Größen identifiziert:einer Netzwerkadresse und einer Maske. Dieses Zahlenpaarwird als Area-Adresse bezeichnet. Es folgt ein Beispiel für einehexadezimal dargestellte Area-Adresse:


− 01234500 – Bei dieser Zahl handelt es sich um die Netz-werk-Adresse für diese Routing-Area. Jede Netzwerk-Nummer innerhalb jener Area beginnt mit dem Identifizie-rungscode 012345.

− FFFFFF00 – Bei dieser Zahl handelt es sich um die Maske,die angibt, wie groß der auf die Area selbst entfallende An-teil und wie groß der auf einzelne Netzwerke innerhalb derArea entfallende Anteil an der Netzwerk-Adresse ist.

Im obigen Beispiel weisen die ersten 24 Bit (012345) die Rou-ting-Area aus. Die übrigen 8 Bit werden verwendet,um einzelne Netzwerk-Nummern innerhalb der Routing-Areazu identifizieren (beispielsweise 012345AB, 012345C1,01234511). In der Abbildung 38.2 sind die vorstehendenAdressierungsbegriffe für drei unterschiedliche Netzwerke ineiner einzigen Area hervorgehoben.

0 1 2 3 4 5 0 0

F F F F F F 0 0

Area 0 1 2 3 4 5

Areanummer

Area-Adresse

Netzwerk innerhalb einer Area

0 1 2 3 4 5 C 1 0 1 2 3 4 5 A BNetzwerk 0 1 2 3 4 5 1 1

Eine Routing-Area kann bis zu drei verschiedene Area-Adres-sen mit unterschiedlichen Masken besitzen. Das Vorhanden-sein von mehr als einer Area-Adresse ermöglicht die Reorgani-sation der Routing-Area, ohne Operationen zu unterbrechen.Innerhalb einer Domain kann jede beliebige Kombination vonArea-Adressen verwendet werden.

38.5 NLSP – Hello-Pakete

Unter NLSP gibt es zwei Arten von Hello-Paketen: Hello-Pakete für WANs und Hello-Pakete für Level-1-LANs.

Bild 38.2:NLSP-Adres-sen setzen sichaus einer Netz-werk-Adresseund einerMaske zusam-men


38.5.1 Hello-Pakete für WANs

In der Abbildung 38.3 sind die Felder eines Hello-Pakets fürWANs dargestellt.

Protokoll-ID

Längenkennung

Minor-Version

Reserviert

Reserviert Pakettyp

Major-Version

Reserved

Reserviert Zustand Circuit-Typ

Quellen-ID

Wartezeit

Paketlänge

ID eines lokalen WAN

Felder variabler Länge

1

1

1

1

1

1

2

1

6

2

2

1

Variabel

Byte

WAN Hello

Felder des Hello-Pakets für WANs

Im folgenden werden alle in der Abbildung 38.3 dargestelltenFelder des Hello-Pakets für WANs kurz beschrieben:

− Protokoll-ID – Weist die Ebene des NLSP-Routing mit derHexadezimalzahl 0x83 aus.

− Längenkennung – Bestimmt die Anzahl von Bytes im festenAnteil des Headers.

− Minor-Version – Enthält einen möglichen Dezimalwert undwird beim Empfang ignoriert.

− Reserviert – Enthält keine Dezimalwerte und wird beimEmpfang ignoriert.

Bild 38.3:Ein Hello-Pa-ket für WANsbesteht aus 14

Feldern


− Pakettyp (5 Bit) – Enthält einen von 17 möglichen Dezi-malwerten.

− Major-Version – Enthält einen möglichen Dezimalwert.


− Zustand (2 Bit) – Verschickt den mit der Verbindung ver-knüpften Zustand des Routers (0 = Aktiv, 1 = Initialisie-rend, 2 = Inaktiv).

− Circuit-Typ – Besteht aus zwei Bits. Dieses Feld kann einender folgenden Werte enthalten:

− 0 = Reservierter Wert, das gesamte Paket ignorieren.

− 1 = Nur Level-1-Routing.

− 2 = Nur Level-2-Routing (der Sender verwendet dieseVerbindung für Level 2 Routing).

− 3 = Sowohl Level 1 als auch Level 2 (der Sender ist einLevel-2-Router und verwendet diese Verbindung fürLevel-1- und Level-2-Verkehr).

− Quellen-ID – Dient als System-ID für den sendenden Rou-ter.

− Wartezeit – Enthält die für den sendenden Router anzu-wendende Wartezeit in Sekunden.

− Paketlänge – Bestimmt die Gesamtlänge des Pakets inBytes, einschließlich des NLSP-Header.

− ID eines lokalen WAN – Dient als eindeutige, dieserStrecke beim Erstellen durch den Router zugewiesene ID.

− Felder variabler Länge – Besteht aus einer Reihe optionalerFelder.


38.5.2 Hello-Pakete für LANs

In der Abbildung 38.4 sind die Felder des Hello-Pakets fürLevel-1-LAN dargestellt.

Protokoll-ID

Längenkennung

Minor-Version

Reserviert

Major-Version

Reserviert

keinMulti-cast

PrioritätR

LAN-ID

Felder variabler Länge Variabel

1

1

1

1

1

1

2

1

6

2

2

1

7

Byte

LAN Level 1 Hello

Reserviert Pakettyp

Quellen-ID

Wartezeit

Paketlänge

Cicuit-TypReserviert Res.

Felder des Hello-Pakets für Level-1-LANs

Im folgenden werden alle in der Abbildung 38.4 dargestelltenFelder des Hello-Pakets für Level-1-LANs kurz beschrieben:

− Protokoll-ID – Weist die Ebene des NLSP Routing mit derHexadezimalzahl 0x83 aus.

− Längenkennung – Bestimmt die Anzahl von Bytes im festenAnteil des Headers (bis einschließlich des Felds LAN-ID).

− Minor-Version – Enthält einen möglichen Dezimalwert undwird beim Empfang ignoriert.

Bild 38.4:Ein Hello-Paket für

Level- 1-LANsbesteht aus 16

Feldern



− Pakettyp (5 Bit) – Enthält einen von 15 möglichen Dezi-malwerten.

− Major Version – Enthält einen möglichen Dezimalwert.


− Kein Multicast (1 Bit) – Zeigt an, falls auf 1 gesetzt, daßder Paketsender keinen an eine Multicast-Adresse gerichte-ten Datenverkehr empfangen kann. (Zukünftige Pakete indiesem LAN müssen an die Broadcast-Adresse geschicktwerden.)

− Circuit-Typ – Besteht aus zwei Bits. Dieses Feld kann einender folgenden Werte enthalten:

− 0 = Reservierter Wert, das gesamte Paket ignorieren.

− 1 = Nur Level-1-Routing.

− 2 = Nur Level-2-Routing (der Sender verwendet dieseVerbindung für Level-2-Routing).

− 3 = Sowohl Level 1 als auch Level 2 (der Sender ist einLevel-2-Router und verwendet diese Verbindung fürLevel-1- und Level-2-Verkehr).

− Quellen-ID – Enthält die System-ID des sendenden Router.

− Wartezeit – Enthält die für den sendenden Router anzu-wendende Wartezeit in Sekunden.

− Paketlänge – Bestimmt die Gesamtlänge des Pakets inBytes, einschließlich des NLSP-Headers.

− R – Enthält keine Dezimalwerte und wird beim Empfangignoriert.

− Priorität (7 Bit) – Dient als mit dem designierten Routerdes LAN Level 1 verknüpfte Priorität. (Höhere Zahlen be-deuten eine höhere Priorität.)


− LAN-ID – Enthält die System-ID (6 Bytes) des designiertenRouter des LAN Level 1, gefolgt von einem durch diesendesignierten Router zugewiesenen Feld.

− Felder variabler Länge – Besteht aus einer Reihe optionalerFelder.

39 Open Systems Interconnection (OSI) Routing-Protokoll

39.1 Hintergrund

Die International Organization for Standardization (ISO)entwickelte eine vollständige Sammlung von Routing-Proto-kollen für den Einsatz in der Open-Systems-Interconnection-Protokollsammlung (OSI). Zu diesen zählen Zwischensystem-zu-Zwischensystem (Intermediate System-to-Intermediate Sy-stem = IS-IS), Endsystem-zu-Zwischensystem (End System-to-Intermediate System = ES-IS) und das Interdomain RoutingProtocol (IDRP). In diesem Kapitel werden die grundlegendenOperationen jedes dieser Protokolle behandelt.

IS-IS basiert auf der Arbeit, die bei der Digital EquipmentCorporation (Digital) ursprünglich für DECnet/OSI (DECnetPhase V) erbracht wurde. IS-IS wurde ursprünglich entwickelt,um das Routing in ISO Connectionless-Network-Protocol-(CLNP-)Netzwerken vorzunehmen. Seither wurde eine Ver-sion entwickelt, die sowohl Netzwerke unter CLNP als auchunter dem Internet Protocol (IP) unterstützt. Diese Versionwird üblicherweise als Integrated IS-IS bezeichnet (wurde aberauch Dual IS-IS genannt).

Die OSI-Routing-Protokolle sind in mehreren ISO-Dokumen-ten zusammengefaßt, zu denen auch die ISO 10589 gehört, inder die Definition für IS-IS erfolgt. Das American NationalStandards Institute (ANSI) X3S3.3 (Netzwerk- und Transport-schichten) Komitee war die treibende Kraft hinter der ISO-

KAPITEL 39Open Systems Interconnection (OSI) Routing-Protokoll


Standardisierung von IS-IS. Andere ISO-Dokumente sind dieISO 9542 (die ES-IS definiert) und ISO 10747 (die IDRP defi-niert).

39.1.1 OSI-Netzwerk-Terminologie

In der Welt der OSI-Netzwerke werden einige bestimmte Be-griffe verwendet wie beispielsweise Endsystem (ES), womit je-der nicht weiterleitende Netzknoten gemeint ist, und Zwi-schensystem (Intermediate System = IS), womit ein Routergemeint ist. Diese Begriffe bilden die Grundlage für die OSI-Protokolle ES-IS und IS-IS. Das ES-IS-Protokoll ermöglicht esESs und IS, einander zu bemerken. Das IS-IS-Protokoll sorgtfür das Routing zwischen IS. Andere wichtige Begriffe fürOSI-Netzwerke sind: Area, Domain, Level-1-Routing undLevel-2-Routing. Bei einer Area handelt es sich um eineGruppe aneinandergrenzender Netzwerke und angebundenerHosts, die von einem Netzwerk-Administrator oder -Verwalterals Area festgelegt wurden. Bei einer Domain handelt es sichum eine Ansammlung miteinander verbundener Areas. Rou-ting Domains (RDs) bieten für alle in ihr befindlichen End-systeme eine vollständige Anbindung. Mit Level-1-Routingwird das Routing innerhalb einer Level-1-Area bezeichnet,wohingegen es sich beim Level-2-Routing um das Routingzwischen Level-1-Areas handelt. Im Bild 39.1 sind die Bezie-hungen zwischen Areas und Domains sowie die zwischen die-sen vorkommenden Routing-Level dargestellt.

Level-2-Routing

Area 1

IS

IS IS

IS

Area 2

Domain

Level-1- Routing

Level-1-Routing

ES ESBild 39.1:

Areas kommenin einer größe-

ren Domainvor und greifen

für die Kom-munikation un-tereinander auf

Level-2-Rou-ting zurück

Kapitel 39 • Open Systems Interconnection (OSI) Routing-Protokoll 499

39.2 Endsystem-zu-Zwischensystem (ES-IS)

Bei Endsystem-zu-Zwischensystem (ES-IS) handelt es sich umein OSI-Protokoll, mit dem definiert wird, wie Endsysteme(Hosts) und Zwischensysteme (Router) etwas voneinandermitbekommen, ein Vorgang, der als Konfiguration bezeichnetwird. Die Konfiguration muß stattfinden, bevor es ein Routingzwischen ES geben kann.

ES-IS ist eher ein Protokoll zum Entdecken als ein Routing-Protokoll. Es unterscheidet zwischen drei verschiedenen Artenvon Subnetzen: Punkt-zu-Punkt-Subnetzen, Broadcast-Subnet-zen und Subnetzen mit einer allgemeinen Topologie. Punkt-zu-Punkt-Subnetze wie beispielsweise serielle WAN-Verbindungenstellen eine Punkt-zu-Punkt-Verbindung zwischen zwei Syste-men bereit. Broadcast-Subnetze wie beispielsweise Ethernetoder IEEE 802.3 leiten eine einzelne physikalische Nachrichtan alle im Subnetz befindlichen Knoten weiter. Subnetze miteiner allgemeinen Topologie wie beispielsweise X.25 unter-stützen eine beliebige Anzahl von Systemen. Anders als beiBroadcast-Subnetzen wächst in einem Subnetz mit einer all-gemeinen Topologie jedoch der Aufwand für eine Übertragungüber n Wege direkt mit der Größe des Subnetzes.

WANseriell

Punkt-zu-Punkt

X.25

Allgemeine Topologie

Ethernet

Broadcast

39.2.1 ES-IS-Konfiguration

Bei der ES-IS-Konfiguration handelt es sich um denjenigenVorgang, bei dem ES und IS einander entdecken, so daß eszum Routing zwischen ES kommen kann. Die Konfigurati-onsinformationen werden in regelmäßigen Abständen durchzwei Nachrichtentypen übertragen: ES-Hello-Nachrichten(ESH) und IS-Hello-Nachrichten (ISH). ESH werden von

Bild 39.2:ES-IS kann inPunkt-zu-Punkt- undBroadcast-Subnetzen so-wie in Subnet-zen mit allge-meiner Topo-logie eingesetztwerden


ES generiert und an jedes IS im Subnetz geschickt. ISH werdenvon IS generiert und an jedes ES im Subnetz geschickt. DieseHello-Nachrichten dienen in erster Linie dazu, die Adressendes Subnetzes und der Netzwerk-Schicht der generierendenSysteme zu übermitteln. Soweit möglich, versucht ES-IS, dieKonfigurationsinformationen gleichzeitig an viele Systeme zuverschicken. In Broadcast-Subnetzen werden ES-IS Hello-Nachrichten über eine besondere, alle Endsysteme kenn-zeichnende Multicast-Adresse an alle IS geschickt. In Subnet-zen mit einer allgemeinen Topologie überträgt ES-IS wegen deshohen Aufwands bei Multicast-Übertragungen üblicherweisekeine Konfigurationsinformationen.

39.2.2 ES-IS-Adressierung

Das ES-IS-Konfigurationsprotokoll übermittelt sowohl dieAdresse der OSI-Netzwerkschicht als auch des OSI-Subnetzes.Die Adresse der OSI-Netzwerkschicht weist entweder denNetwork Service Access Point (NSAP), der die Schnittstellezwischen der OSI Schicht 3 und Schicht 4 darstellt, oder denNetwork Entity Title (NET) aus, bei dem es sich um die Ein-heit der Netzwerkschicht in einem OSI-IS handelt. Adressenvon OSI-Subnetzen bzw. Subnetwork Point Of AttachmentAddresses (SNPAs) sind die Stellen, an denen ein ES oder ISphysikalisch an ein Subnetz angebunden ist. Die SNPA weistjedes an das Subnetz angebundene System eindeutig aus. Ineinem Ethernet-Netzwerk ist die SNPA beispielsweise eine 48-Bit-Media-Access-Control-(MAC-)Adresse. Zu den von ES-ISübertragenen Konfigurationsinformationen gehört die NSAP-zu-SNPA- oder NET-zu-SNPA-Zuordnung.

39.3 Zwischensystem-zu-Zwischensystem(IS-IS)

Bei Zwischensystem-zu-Zwischensystem (Intermediate System-to-Intermediate System = IS-IS) handelt es sich um ein hierar-chisches Routing-Protokoll für Verbindungszustände von OSI,welches das Netzwerk mit Informationen über Verbindungs-zustände beliefert, um ein konsistentes Abbild der Netzwerk-Topologie zu erstellen. Um den Entwurf und Betrieb von Rou-tern zu vereinfachen, unterscheidet IS-IS zwischen Level-1-


und Level-2-IS. Level-1-IS kommunizieren mit anderen Level-1-ISs in derselben Area. Level-2-IS sind für das Routing zwi-schen Level-1-IS zuständig und bilden einen Routing-Back-bone zwischen den Domains. Das hierarchische Routing ver-einfacht den Entwurf des Backbone, da Level-1-IS nur zu wis-sen brauchen, wie sie zum nächsten Level-2-IS gelangen. DasRouting-Protokoll für den Backbone kann ohne Einfluß aufdas innerhalb der Area eingesetzte Routing-Protokoll ausge-tauscht werden.

39.3.1 OSI – der Routing-Vorgang

Jedes ES befindet sich in einer bestimmten Area. Das OSI-Routing beginnt, sobald die ES den nächstgelegenen IS ent-decken, indem sie auf ISH-Pakete achten. Wenn ein ES ein Pa-ket an ein anderes ES schicken will, schickt es das Paket an ei-nes der IS im direkt angebundenen Netzwerk. Der Routersieht dann nach der Zieladresse und leitet das Paket über diebeste Route weiter. Wenn sich das Ziel-ES im gleichen Subnetzbefindet, ist dies dem lokalen IS bekannt, da es auf ESHs ach-tet, so daß es das Paket entsprechend weiterleitet. Das IS kannauch eine Redirect-Nachricht (RD) an die Quelle zurück-schicken, um ihr mitzuteilen, daß es eine direktere Route gibt.Wenn es sich bei der Zieladresse um ein ES in einem anderenSubnetz in derselben Area handelt, ist dem IS die richtigeRoute bekannt, so daß es das Paket entsprechend weiterleitet.Wenn es sich bei der Zieladresse um ein ES in einer anderenArea handelt, schickt das Level-1-IS das Paket an das nächst-gelegene Level-2-IS. Das Weiterleiten über Level-2-IS setzt sichfort, bis das Paket ein Level-2-IS in der Ziel-Area erreicht. In-nerhalb der Ziel-Area leiten IS das Paket über den besten Pfadweiter, bis das Ziel-ES erreicht ist.

Update-Nachrichten für Verbindungszustände helfen IS dabei,etwas über die Netzwerktopologie zu erfahren. Zuerst ge-neriert jedes IS ein Update-Paket, das die ES und IS, mit denenes verbunden ist, sowie die zugehörigen Metriken angibt. DasUpdate wird dann an alle angrenzenden IS geschickt, die es anderen Nachbarn weiterleiten (Flooding) und so weiter(Sequenznummern beenden die Verbreitung und unterscheidenalte von neuen Updates). Mittels dieser Updates kann sichjedes IS eine vollständige Topologie des Netzwerks erstellen.


Wenn sich die Topologie ändert, werden neue Updates ver-schickt.

39.3.2 IS-IS – Metriken

IS-IS greift auf eine einzige vorgegebene Metrik mit einemmaximalen Pfadwert von 1024 zurück. Die beliebige Metrikwird typischerweise von einem Netzwerk-Administrator zuge-wiesen. Jede einzelne Verbindung kann maximal den Wert 64annehmen, und Pfadwerte werden durch Aufsummieren derVerbindungswerte berechnet. Maximale Metrikwerte werdenin dieser Höhe gesetzt, damit die Aufgliederung einerseits ver-schiedene Verbindungsarten unterstützen kann, währendgleichzeitig sichergestellt wird, daß der für die Bestimmungder Route eingesetzte Algorithmus für den kürzesten Pfad ef-fektiv genug ist. IS-IS definiert weiterhin drei optionale Metri-ken (Aufwand): Verzögerung, Kosten und Fehler. Die Metrikdes Verzögerungsaufwands steht für die auf einer Verbindunganfallende Verzögerungszeit. Die Metrik des Kostenaufwandssteht für die mit der Verwendung der Verbindung verbunde-nen Kommunikationskosten. Die Metrik des Fehleraufwandssteht für die Fehlerrate der Verbindung. IS-IS bildet diese vierMetriken auf die Dienstqualität-Option (Quality Of Service =QOS) im Header des CLNP-Pakets ab. IS-IS verwendet dieseZuordnung für die Berechnung von Routen durch das Inter-netzwerk.

IS-IS – Paketformate

IS-IS greift auf drei grundlegende Paketformate zurück: IS-ISHello-Pakete, Link-State-Pakete (LSPs) und Sequenznummer-Pakete (SNPs). Jedes dieser drei IS-IS-Pakete hat ein komple-xes Format mit folgenden drei unterschiedlichen logischen Be-standteilen. Der erste Teil besteht aus einem festen 8 Byte um-fassenden Header, den alle drei Pakettypen gemein haben. Derzweite Teil ist ein pakettypspezifischer Anteil mit einem festenFormat. Der dritte Teil ist ebenfalls pakettypspezifisch, abervon variabler Länge. Das Bild 39.3 veranschaulicht den logi-schen Aufbau von IS-IS-Paketen. Im Bild 39.4 sind die Felderdes gemeinsamen Header von IS-IS-Paketen dargestellt.


pakettypspezifischerfester Header

pakettypspezifischerHeader variabler Länge

gemeinsamerHeader

Feldlänge in Byte

Version ID-Länge

Paket-typ Version Max. Adressen

in AreaHeader-

längeProtokoll-ID

1 1 1 1 1 111

Reserviert

Im folgenden werden die im Bild 39.4 dargestellten Felderkurz beschrieben:

− Protokoll-ID – Weist das Protokoll IS-IS aus und enthältden Wert 131.

− Header-Länge – Enthält die feste Länge des Header. DieLänge ist immer 8 Byte, aber dennoch enthalten, damit sichIS-IS-Pakete nicht wesentlich von CLNP-Paketen unter-scheiden.

− Version – Enthält in der aktuellen IS-IS-Spezifikation denWert 1.

− ID-Länge – Gibt den Umfang des Anteils der ID an einerNSAP-Adresse an. Falls das Feld einen Wert von 1 bis 8(einschließlich) enthält, dann erstreckt sich der Anteil derID über diese Anzahl von Bytes. Falls das Feld den Wert 0enthält, dann erstreckt sich der Anteil der ID über 6 Bytes.Wenn das Feld den Wert 255 (alles Einsen) enthält, dannerstreckt sich der Anteil der ID an der NSAP-Adresse übernull Bytes.

− Pakettyp – Gibt den Typ des IS-IS-Pakets an (Hello, LSP,SNP).

− Version – Wird nach dem Feld Packet Type wiederholt.

Bild 39.3:IS-IS-Paketesetzen sich ausdrei logischenHeadern zu-sammen

Bild 39.4:IS-IS-Paketesetzen sich ausacht Feldernzusammen


− Reserviert – Wird vom Empfänger ignoriert und ist gleich0.

− Max. Adressen in Area – Gibt die Anzahl der in dieser Areagestatteten Adressen an.

Auf den gemeinsamen Header folgend verfügt jeder Pakettypüber einen unterschiedlichen zusätzlichen festen Anteil, aufden ein variabler Anteil folgt.

39.4 Integrated IS-IS

Bei Integrated IS-IS handelt es sich um eine Version des OSI-Routing-Protokolls IS-IS, die einen einzigen Routing-Algo-rithmus verwendet, um mehr Protokolle für die Netzwerk-Schicht als nur CLNP zu unterstützen. Integrated IS-IS wirdmanchmal auch nach einer für IP- und CLNP-Netzwerke ent-worfenen Version als Dual IS-IS bezeichnet. Den IS-IS-Paketenwerden mehrere Felder hinzugefügt, damit IS-IS zusätzlicheNetzwerk-Schichten unterstützen kann. Diese Felder informie-ren Router über die Erreichbarkeit von Netzwerk-Adressenaus anderen Protokollsammlungen und andere von einer be-stimmten Protokollsammlung benötigte Informationen. Imple-mentierungen von Integrated IS-IS verschicken nur einen SatzRouting-Updates, was effizienter ist als zwei getrennte Imple-mentierungen.

Integrated IS-IS stellt eine von zwei Möglichkeiten dar, meh-rere Protokolle für die Netzwerkschicht auf einem Router zuunterstützen; die andere Vorgehensweise wird als Ships-in-the-night bezeichnet. Das Ships-in-the-night-Routing unterstütztden Einsatz völlig unterschiedlicher und getrennter Routing-Protokolle für jedes Netzwerk-Protokoll, so daß die vielenRouting-Protokolle im wesentlichen unabhängig voneinanderbestehen. Dadurch ziehen die verschiedenen Arten von Rou-ting-Informationen wie Schiffe in der Nacht vorüber. Das In-tegrated Routing verfügt durch von einem einzigen Routing-Protokoll berechnete Tabellen über die Fähigkeit, mehrereProtokolle für die Netzwerk-Schicht weiterzuleiten, wodurchdie Mittel des Router geschont werden. Integrated IS-IS greiftauf dieses Vorgehen zurück.


39.5 Interdomain Routing Protocol (IDRP)

Beim Interdomain Routing Protocol (IDRP) handelt es sichum ein OSI-Protokoll, das angibt, wie Router mit Routern inanderen Domains kommunizieren. IDRP wurde für einenahtlose Zusammenarbeit mit CLNP, ES-IS und IS-IS entwor-fen. IDRP basiert auf dem Border Gateway Protocol (BGP),einem Protokoll für das Routing zwischen Domains, das sei-nen Ursprung in der IP-Gruppe hat. Zu den Eigenschaften vonIDRP gehören:

− Unterstützung der CLNP-Dienstqualität (Quality Of Ser-vice = QOS)

− Vermeidung von Schleifen durch Verfolgen aller von einerRoute durchquerten Routing Domains (RDs)

− Reduzierung von Routeninformationen und -bearbeitungdurch den Einsatz von Confederations (Bündnissen), dieKomprimierung von Informationen zu RD-Pfaden und an-deren Mitteln

− Zuverlässigkeit durch einen eingebauten zuverlässigenTransport

− Sicherheit durch den Einsatz von kryptographischen Signa-turen für jedes Paket

− Routenserver

39.5.1 IDRP – Terminologie

Mit IDRP werden einige umgebungsspezifische Begriffe einge-führt. Bei diesen handelt es sich um Border Intermediate Sy-stem (BIS), Routing Domain (RD), Routing Domain Identifier(RDI), Routing Information Base (RIB) und Confederation.Bei einem BIS handelt es sich um ein IS, das am Routing zwi-schen Domains beteiligt ist und somit IDRP einsetzt. Eine RDist eine Gruppe von ES und IS, die mit denselben Verwal-tungsregeln betrieben werden und sich einen gemeinsamenRouting-Plan teilen. Bei einer RDI handelt es sich um eineeindeutige ID für eine RD. Bei einer RIB handelt es sich umeine von IDRP verwendete Routing-Datenbank, die von jedemBIS mit aus der RD und von anderen BIS empfangenen In-formationen aufgebaut wird. Eine RIB enthält die von einer


bestimmten BIS für den Einsatz ausgewählten Routen. Bei ei-ner Confederation (Bündnis) handelt es sich um eine Gruppevon RD, die den RD außerhalb der Confederation als eineeinzige RD erscheint. Die Topologie der Confederation ist fürRD außerhalb der Confederation nicht erkennbar. Confede-rations müssen ineinander verschachtelt sein und helfen dabei,den Netzwerkverkehr zu reduzieren, indem sie im Internetz-werk als Firewalls agieren. Im Bild 39.5 ist die Beziehung zwi-schen IDRP-Einheiten dargestellt.

InterdomainRouting

Confederation (Bündnis)

Area Area

Area Area

BIS

Routing Domain Routing Domain

39.5.2 IDRP-Routing

Eine IDRP-Route besteht aus einer Folge von RDIs, von deneneinige Confederations sein können. Jedes BIS ist so konfigu-riert, daß es die RD und die Confederations kennt, zu denenes gehört. Von anderen BISs, RDs und Confederations erfährtes durch den Informationsaustausch mit jedem Nachbar. Wiebeim Distance-Vector-Routing häufen sich Routen zu einembestimmten Ziel vom Ziel ausgehend an. Nur Routen, die denlokalen Sicherheitsbestimmungen eines BIS genügen und fürden Einsatz ausgewählt wurden, werden an andere BIS über-geben. Die Neubestimmung von Routen erfolgt partiell beimAuftreten eines der folgenden drei Ereignisse: Ein inkremen-telles Routing-Update mit neuen Routen wird empfangen, einNachbar eines BIS wird deaktiviert, oder ein Nachbar einesBIS wird aktiviert.

Bild 39.5:Domains

kommunizierenmittels Border

IntermediateSystems (BIS)

miteinander

40 Open Shortest Path First (OSPF)

40.1 Hintergrund

Bei Open Shortest Path First (OSPF) handelt es sich um einRouting-Protokoll, das von der Interior-Gateway-Protocol-(IGP-)Arbeitsgruppe der Internet Engineering Task Force(IETF) für Internet-Protocol-(IP-)Netzwerke entwickelt wurde.Die Arbeitsgruppe kam 1988 zusammen, um ein auf demShortest-Path-First-(SPF-)Algorithmus basierendes IGP für denEinsatz im Internet zu entwerfen. Ähnlich wie das Interior Ga-teway Routing Protocol (IGRP) wurde OSPF entwickelt, weildas Routing Information Protocol (RIP) Mitte der 1980erJahre zusehends weniger in der Lage war, große, heterogeneInternetzwerke zu bedienen. In diesem Kapitel werden dieRouting-Umgebung OSPF, der zugrundeliegende Routing-Algorithmus sowie allgemeine Komponenten des Protokollsbehandelt.

OSPF wurde von verschiedenen Forschungsvorhaben abgelei-tet, zu denen der 1978 für das ARPANET (ein in den frühen1970er Jahren von BBN entwickeltes wegweisendes, auf demAustausch von Paketen basierendes Netzwerk) entwickelteSPF-Algorithmus nach Bolt, Beranek, Newman (BBN), Dr.Radia Perlmans Arbeit zur fehlertoleranten Verbreitung vonRouting-Informationen (1988), BBNs Arbeit zum Area-Rou-ting (1986) sowie eine frühe Fassung des OSI-Routing-Proto-kolls Intermediate-System-to-Intermediate-System (IS-IS) ge-hören.

KAPITEL 40Open Shortest Path First (OSPF)


OSPF verfügt über zwei wesentliche Eigenschaften. Erstens istdas Protokoll »offen«, was bedeutet, daß dessen Spezifikationzur Public Domain gehört. Die OSPF-Spezifikation wurde alsRequest For Comments (RFC) 1247 veröffentlicht. Zweitensbasiert OSPF auf dem SPF-Algorithmus, der manchmal auchnach seinem Erschaffer als Dijkstra-Algorithmus bezeichnetwird.

Bei OSPF handelt es sich um ein Routing-Protokoll für Ver-bindungszustände (Link-States), welches das Versenden vonLink-State Advertisements (LSAs) an alle anderen Router aufderselben Hierarchiestufe der Area erfordert. Informationenüber angebundene Schnittstellen, verwendete Metriken undandere Variablen werden in die LSAs von OSPF einbezogen.Während OSPF-Router Informationen über die Verbindungs-zustände sammeln, verwenden sie für die Berechnung des kür-zesten Pfads zum nächsten Knoten den SPF-Algorithmus.

Als Routing-Protokoll für Verbindungszustände unterscheidetsich OSPF von RIP und IGRP, bei denen es sich um Routing-Protokolle nach dem Distance-Vector-Verfahren handelt. Rou-ter, die den Distance-Vector-Algorithmus verwenden, verschik-ken ihre gesamten Routing-Tabellen oder Teile davon in Rou-ting-Update-Nachrichten an ihre Nachbarn.

40.2 Routing-Hierarchie

Anders als RIP kann OSPF innerhalb einer Hierarchie betrie-ben werden. Die größte Einheit in der Hierarchie ist das auto-nome System (AS), bei dem es sich um eine Ansammlung vonNetzwerken unter einer gemeinsamen Administration handelt,für die eine gemeinsame Routing-Strategie zum Einsatzkommt. Bei OSPF handelt es sich um ein innerhalb eines ASverwendetes (Interior Gateway) Routing-Protokoll, obgleiches dazu in der Lage ist, Routen von anderen AS zu empfangenoder an sie zu verschicken.

Ein AS kann in eine Anzahl von Areas unterteilt werden, beidenen es sich um Gruppen angrenzender Netzwerke und an-gebundener Hosts handelt. Router mit mehreren Schnittstellenkönnen an mehreren Areas beteiligt sein. Diese als Area Bor-der Router (Übergangsrouter) bezeichneten Router pflegen fürjede Area eine eigene Topologie-Datenbank.

Kapitel 40 • Open Shortest Path First (OSPF) 509

Eine Topologie-Datenbank stellt im wesentlichen eine Über-sicht über Netzwerke und deren Verhältnisse zu Routern dar.Die Topologie-Datenbank enthält die von allen Routern der-selben Area empfangene Ansammlung von LSAs. Da sichRouter einer Area dieselben Informationen teilen, verfügen sieüber identische Topologie-Datenbanken.

Der Begriff Domain wird manchmal verwendet, um einen Teildes Netzwerks zu bezeichnen, in dem alle Router über identi-sche Topologie-Datenbanken verfügen. Häufig wird Domainals Synonym für AS verwendet.

Die Topologie einer Area ist für Einheiten außerhalb der Areanicht sichtbar. Durch die Abtrennung der Area-Topologienverursacht OSPF weniger Routingverkehr, als wenn das ASnicht unterteilt wäre.

Die Unterteilung in Areas sorgt für zwei unterschiedliche Ar-ten von OSPF-Routing, die davon abhängig sind, ob sich dieQuelle und das Ziel in derselben Area oder in unterschiedli-chen Areas befinden. Zum Intra-Area-Routing kommt es,wenn sich Quelle und Ziel in derselben Area befinden; zumInter-Area-Routing, wenn sie in unterschiedlichen Areas lie-gen.

Ein OSPF-Backbone ist für das Verteilen von Routing-Infor-mationen zwischen Areas verantwortlich. Er setzt sich aus al-len Übergangsroutern der Area, nicht vollständig in einer Areaenthaltenen Netzwerken sowie deren angebundenen Routernzusammen. Im Bild 40.1 ist ein Beispiel für ein Internetzwerkmit mehreren Areas dargestellt.

In der Abbildung stellen die Router 4, 5, 6, 10, 11 und 12 denBackbone dar. Wenn der Host H1 in Area 3 ein Paket an denHost H2 in Area 2 schicken will, wird das Paket an den Rou-ter 13 gesendet, der es an den Router 12 weiterleitet, der dasPaket seinerseits an den Router 11 schickt. Der Router 11 lei-tet das Paket dann über den Backbone zum Area Border Rou-ter 10, der das Paket über zwei Intra-Area-Router (Router 9und 7) an den Host H2 weiterleitet.

Beim Backbone selber handelt es sich um eine OSPF-Area, sodaß alle Backbone-Router die gleichen Prozeduren und Algo-rithmen für die Wartung der Routing-Informationen innerhalbdes Backbone verwenden. Die Topologie des Backbone ist für


alle Intra-Area-Router ebenso unsichtbar, wie es die einzelnenArea-Topologien für den Backbone sind.

Areas können auf eine Weise definiert werden, daß der Back-bone nicht zusammenhängend ist. In diesem Fall muß die Ver-bundenheit des Backbone über virtuelle Verbindungen wie-derhergestellt werden. Virtuelle Verbindungen werden zwi-schen allen denjenigen Backbone-Routern konfiguriert, dieüber eine Verbindung zu einer nicht zum Backbone gehören-den Area verfügen; und sie wirken wie direkte Verbindungen.

Router 5

Router 4

Router 6

Router 13

Router 12

Router 11

Router 10

Router 9

Router 2Router 1

Router 3

H2

H1

Area 3

Area 1

Area 2

Autonomes System (AS)

Router 8

Router 7

Übergangsknoten eines AS, auf denen OSPF läuft, erfahrendurch Protokolle für externe Gateways (EGPs) wie beispiels-weise das Exterior Gateway Protocol (EGP) oder das BorderGateway Protocol (BGP), aber auch durch Konfigurationsin-formationen von außerhalb liegenden Routen. Weitere Infor-mationen zu diesen Protokollen finden Sie in Kapitel 33,»Border Gateway Protocol (BGP)«.

Bild 40.1:Ein OSPF-ASsetzt sich aus

mehrerendurch Router

miteinanderverbundenenAreas zusam-

men


40.3 SPF-Algorithmus

Der Routing-Algorithmus Shortest Path First (SPF) stellt dieBasis beim Vorgehen von OSPF dar. Sobald ein SPF-Routerangeschaltet wird, initialisiert er die Datenstrukturen seinesRouting-Protokolls und wartet anschließend auf Zeichen vonProtokollen darunterliegender Schichten, daß seine Schnittstel-len funktionieren.

Nachdem einem Router das Funktionieren seiner Schnittstel-len zugesichert worden ist, greift er auf das OSPF Hello Pro-tocol zurück, um sich Nachbarn zu verschaffen, bei denen essich um Router mit Schnittstellen zu einem gemeinsamenNetzwerk handelt. Der Router verschickt Hello-Pakete anseine Nachbarn und erhält deren Hello-Pakete. Daneben, daßHello-Pakete beim Verschaffen von Nachbarn behilflich sind,fungieren sie weiterhin als Keep-Alives, wodurch Router er-fahren, daß andere Router noch immer in Betrieb sind.

In Multiaccess-Netzwerken (Netzwerke, die mehr als zweiRouter unterstützen) wählt das Hello-Protokoll einendesignierten Router sowie einen designierten Reserve-Routeraus. Unter anderem zeichnet sich der designierte Router fürdie Generierung von LSAs für das gesamte Multiaccess-Netz-werk verantwortlich. Designierte Router ermöglichen eine Re-duktion des Netzwerk-Verkehrs und des Umfangs der Topolo-gie-Datenbank.

Wenn die Datenbanken für Verbindungszustände von zweibenachbarten Routern miteinander synchronisiert werden, gel-ten die Router als direkt benachbart (adjacent). In Multi-access-Netzwerken bestimmt der designierte Router, welcheRouter direkt benachbart sein sollen. Unter Paaren von direktbenachbarten Routern werden Topologie-Datenbanken mit-einander synchronisiert. Die jeweilige Nähe untereinandersteuert die Verteilung von Paketen des Routing-Protokolls, dienur aufgrund der Nachbarschaft verschickt und empfangenwerden.

Jeder Router verschickt regelmäßig ein LSA, um Informatio-nen über die direkten Nachbarn eines Routers zu liefern oderandere Router darüber zu informieren, wenn sich der Zustandeines Routers verändert. Durch einen Vergleich der eingeführ-ten direkten Nachbarn mit den Verbindungszuständen lassen


sich ausgefallene Router schnell entdecken und läßt sich dieNetzwerk-Topologie entsprechend ändern. Unter Rückgriffauf die aus LSAs generierte Topologie-Datenbank berechnetjeder Router einen Baum mit sich selber als Wurzel mit denkürzesten Wegen (Shortest Path). Dieser Baum bringt wie-derum eine Routing-Tabelle hervor.

40.4 Paketformat

Alle OSPF-Pakete beginnen mit einem 24-Byte-Header, wie erim Bild 40.2 dargestellt ist.

Versions-nummer

Typ Paket-länge

Prüf-summe

Authenti-fikations-

typAuthentifikation DatenRouter-ID Area-ID

Feldlänge in Byte 1 1 2 4 4 2 2 8 variabel

Die Felder des im Bild 40.2 dargestellten Headers werden imfolgenden kurz beschrieben:

− Versionsnummer – Weist die verwendete Version von OSPFaus.

− Typ – Enthält einen der folgenden Werte für den OSPF-Pa-kettyp:

− Hello: Richtet Beziehungen zu Nachbarn ein und wartetsie.

− Database-Description: Beschreibt den Inhalt der Topo-logie-Datenbank. Diese Nachrichten werden bei der Ini-tialisierung einer direkten Nachbarschaft ausgetauscht.

− Link-State-Request: Fordert Teile der Topologie-Daten-bank von benachbarten Routern an. Diese Nachrichtenwerden ausgetauscht, nachdem ein Router festgestellthat (durch das Untersuchen von Database-Description-Paketen), daß Teile seiner Topologie-Datenbank veraltetsind.

− Link-State-Update: Antwortet auf ein Link-State-Re-quest-Paket. Diese Nachrichten werden außerdem fürdas regelmäßige Streuen von LSAs eingesetzt. In einem

Bild 40.2:OSPF-Pakete

setzen sich ausneun Feldern

zusammen


einzigen Link-State-Update-Paket können mehrere LSAsenthalten sein.

− Link-State-Acknowledgment: Bestätigt Link-State-Up-date-Pakete.

− Paketlänge – Gibt die Länge des Pakets einschließlich desOSPF-Header in Bytes an.

− Router-ID – Weist die Quelle des Pakets aus.

− Area-ID – Weist die Area aus, zu der das Paket gehört. AlleOSPF-Pakete sind mit einer einzelnen Area verknüpft.

− Prüfsumme – Überprüft den gesamten Paketinhalt aufVerluste beim Übertragen.

− Authentifizierungstyp – Enthält die Art der Authentifizie-rung. Jeglicher Protokollaustausch unter OSPF ist authen-tifiziert. Die Art der Authentifizierung läßt sich für jedeArea konfigurieren.

− Authentifizierung – Enthält Informationen zur Authentifi-zierung.

− Daten – Enthält gekapselte Informationen übergeordneterSchichten.

40.5 Weitere Eigenschaften von OSPF

Zu den weiteren Eigenschaften von OSPF gehören Equal-Cost, Multipath-Routing sowie auf Type-Of-Service-(TOS-)-Requests basierendes Routing übergeordneter Schichten. DasTOS-basierende Routing unterstützt diejenigen Protokolleübergeordneter Schichten, die bestimmte Arten von Dienstenangeben können. Beispielsweise könnte eine Anwendung an-geben, daß gewisse Daten dringend sind. Wenn OSPF-Verbin-dungen mit hoher Priorität zur Verfügung stehen, dann kön-nen diese für den Transport des dringenden Datagramms ver-wendet werden.

OSPF unterstützt eine oder mehrere Metriken. Wenn nur eineMetrik zum Einsatz gelangt, wird sie als beliebig betrachtetund TOS nicht unterstützt. Wenn mehrere Metriken verwen-det werden, wird TOS optional durch den Einsatz einer eige-nen Metrik (und damit einer eigenen Routing-Tabelle) für jede


der acht möglichen Kombinationen mit den drei IP-TOS-Bits(die Bits für Verzögerung, Durchsatz und Zuverlässigkeit)unterstützt. Wenn die IP-TOS-Bits beispielsweise eine geringeVerzögerung, niedrigen Durchsatz und hohe Zuverlässigkeitangeben, dann berechnet OSPF Routen zu allen Zielen, die aufdiesen TOS-Angaben basieren.

IP-Subnetzmasken werden für jedes bekanntgemachte Zieleinbezogen, wodurch Subnetzmasken variabler Länge möglichsind. Mit Subnetzmasken variabler Länge kann ein IP-Netz-werk in viele Subnetze verschiedenen Umfangs aufgeteilt wer-den. Dies gibt Netzwerk-Administratoren zusätzliche Flexibili-tät bei der Konfiguration des Netzwerks.

41 Resource Reservation Protocol (RSVP)

41.1 Hintergrund

Beim Resource Reservation Protocol (RSVP) handelt es sichum ein netzwerksteuerndes Protokoll, das es Internet-Anwen-dungen ermöglicht, besondere Dienstqualitäten (QOS) fürihren Datenstrom zugewiesen zu bekommen. RSVP ist keinRouting-Protokoll, sondern arbeitet mit Routing-Protokollenzusammen und installiert so etwas wie dynamische Zugriffs-listen entlang der von Routing-Protokollen berechneten Rou-ten. RSVP nimmt den Platz eines Transport-Protokolls imOSI-Modell mit den sieben Protokollschichten ein. RSVPwurde ursprünglich von Forschern der University of SouthCalifornia (USC) Information Sciences Institute (ISI) undXerox Palo Alto Research Center erdacht. Die Internet Engi-neering Task Force (IETF) arbeitet mittlerweile an der Stan-dardisierung durch eine RSVP-Arbeitsgruppe. In diesem Kapi-tel werden folgende Themen zum Betrieb von RSVP bespro-chen: Datenstrom, Dienstqualität, Hochfahren einer Sitzung,Reservierungsmethode und Soft-State-Implementierung. ImBild 41.1 ist eine RSVP-Umgebung dargestellt.

KAPITEL 41Resource Reservation Protocol (RSVP)


Sendender Host

RSVP-Empfänger

RSVP-Tunnel

41.2 RSVP – Datenströme

Beim RSVP ist ein Datenstrom (Data Flow) eine Abfolge vonNachrichten, die über dieselbe Quelle, dasselbe Ziel (eins odermehrere) und dieselbe Dienstqualität verfügen. Die Anforde-rungen an die Dienstqualität werden durch das Netzwerk mit-tels einer Datenstrom-Spezifikation mitgeteilt, bei der es sichum eine von Hosts des Internetzwerks für das Anfordern be-sonderer Dienste vom Internetzwerk verwendete Datenstruk-tur handelt. Eine Datenstrom-Spezifikation garantiert häufigeine Umgangsmethode des Internetzwerks mit Teilen seinesHost-Verkehrs.

RSVP unterstützt drei Typen von Datenverkehr: best-effort (sogut es geht), rate-sensitive (der Übertragungsrate angepaßt)und delay-sensitive (der Verzögerungszeit angepaßt). Die Artdes zur Unterstützung dieser Typen von Datenverkehr ver-wendeten Datenstromdienstes hängt von der implementiertenDienstqualität ab. In den folgenden Absätzen werden diese Ar-ten von Datenverkehr sowie die zugehörigen Dienste behan-delt. Weitere Informationen hinsichtlich der Dienstqualitätfinden Sie im entsprechenden Abschnitt, der später in diesemKapitel folgt.

Der best-effort Verkehr ist der übliche IP-Verkehr. Zu denAnwendungen gehören der Dateitransfer wie beispielsweise

Bild 41.1:Beim RSVP

werden Infor-mationen vom

Host den Emp-fängern überDatenströme

zugestellt

Kapitel 41 • Resource Reservation Protocol (RSVP) 517

Mail-Übertragungen, das Mounten von Festplatten, interak-tive Anmeldungen und der Verkehr aufgrund von Transaktio-nen. Der den best-effort Verkehr unterstützende Dienst wirdals best-effort Service bezeichnet.

Der rate-sensitive Verkehr ist dazu bereit, für eine garantierteÜbertragungsrate auf bessere Zeiten zu verzichten. Beispiels-weise kann für den rate-sensitive Verkehr eine Bandbreite von100 Kbps gefordert sein. Wenn der Verkehr nun tatsächlichfür längere Zeit mit 200 Kbps erfolgt, kann ein Router denVerkehr verzögern. Der rate-sensitive Verkehr ist nicht fürSwitched-Circuit-Netzwerke gedacht, obgleich er in der Regelmit einer Anwendung verbunden ist, die von einem Switched-Circuit-Netzwerk (wie beispielsweise ISDN) portiert wurdeund in einem Datagramm-Netzwerk läuft (IP).

Ein Beispiel für eine solche Anwendung ist das H.323-Video-Conferencing, das entworfen wurde, um unter ISDN (H.320)oder ATM (H.310) zu laufen, aber im Internet zu finden ist.Die H.323-Kodierung erfolgt mit einer konstanten odernahezu konstanten Rate und erfordert eine konstante Übertra-gungsrate. Der den rate-sensitive Verkehr unterstützendeRSVP-Dienst wird als guaranteed bit-rate Service bezeichnet.

Beim delay-sensitive Verkehr handelt es sich um Datenverkehr,für den eine rechtzeitige Zustellung erforderlich ist und derseine Übertragungsrate entsprechend anpaßt. MPEG-II-Videoz.B. benötigt in Abhängigkeit von den Änderungen im Bildeine Bandbreite von durchschnittlich 3 bis 7 Mbps. 3 Mbpskönnten beispielsweise für ein Bild einer gestrichenen Wandausreichen, während 7 Mbps für ein Bild von Wellen auf demMeer erforderlich wären. Quellen für MPEG-II-Video ver-senden sogenannte Key- und Delta-Frames. Typischerweisebeschreiben ein oder zwei Key-Frames pro Sekunde das ge-samte Bild und 13 bzw. 28 Delta-Frames die Abweichungenvom Key-Frame. Delta-Frames fallen in der Regel erheblichkleiner aus als Key-Frames. Als eine Folge davon variieren dieÜbertragungsraten von Frame zu Frame ein wenig. Ein einzel-ner Frame muß jedoch innerhalb der Frame-Zeit zugestelltwerden, ansonsten kann der CODEC seine Aufgabe nicht er-füllen. Für den Datenverkehr mit Delta-Frames muß eine be-stimmte Priorität ausgehandelt werden. Der den delay-sensi-


tive Verkehr unterstützende RSVP-Dienst wird als controlled-delay Service (für Dienste in Nicht-Echtzeit) oder predictiveService (für Echtzeitdienste) bezeichnet.

41.2.1 RSVP – Bearbeitung von Datenströmen

RSVP-Datenströme sind üblicherweise durch Sitzungen ge-kennzeichnet, über die Datenpakete fließen. Eine Sitzung isteine Gruppe von Datenströmen mit demselben Unicast- oderMulticast-Ziel; und RSVP behandelt jede Sitzung unabhängigvoneinander. RSVP unterstützt sowohl Unicast- als auch Mul-ticast-Sitzungen (wobei eine Sitzung aus einer Anzahl vonSendern besteht, die mit einer Anzahl von Empfängern kom-munizieren), während ein Datenstrom immer von einem einzi-gen Sender stammt. Datenpakete in einer bestimmten Sitzungwerden an dieselbe IP-Zieladresse oder eine allgemeine Ziel-schnittstelle geleitet. Die IP-Zieladresse kann die Gruppen-adresse einer Multicast-Zustellung oder die Unicast-Adresseeines einzelnen Empfängers sein. Eine allgemeine Zielschnitt-stelle kann durch ein UDP/TCP-Feld für die Zielschnittstelle,ein entsprechendes Feld eines anderen Transport-Protokollsoder anwendungsspezifische Informationen definiert werden.

Die Datenverteilung erfolgt unter RSVP entweder durch Mul-ticasts oder Unicasts. Beim Multicast-Verkehr wird auf eineKopie jedes von einem Sender an mehrere Ziele weitergeleite-ten Datenpakets zurückgegriffen. Zum Unicast-Verkehrkommt es in einer Sitzung mit einem einzigen Empfänger.Auch wenn es sich um eine Unicast-Zieladresse handelt, kannes mehrere Empfänger geben, die von einer allgemeinenSchnittstelle unterschieden werden. Außerdem kann es auchmehrere Sender für ein Unicast-Ziel geben; in diesem Fallkann RSVP Reservierungen für eine Mehrpunkt-zu-Punkt-Übertragung vornehmen.

Jeder RSVP-Sender und -Empfänger kann einem eindeutigenInternet-Host entsprechen. Ein Host kann allerdings aus meh-reren logischen Sendern und Empfängern bestehen, die vonallgemeinen Schnittstellen unterschieden werden.


41.3 RSVP – Dienstqualität

Unter RSVP handelt es sich bei der Dienstqualität (Quality OfService = QOS) um ein in der Datenstrom-Spezifikation ange-gebenes Attribut, das verwendet wird, um die Art und Weisezu bestimmen, in welcher der Datenaustausch von den betei-ligten Einheiten (Router, Empfänger und Sender) behandeltwird. RSVP wird eingesetzt, um die Dienstqualität sowohl desHost als auch des Router anzugeben. Hosts verwenden RSVP,um für den Datenstrom einer Anwendung einen Grad derDienstqualität vom Netzwerk anzufordern. Router verwendenRSVP, um Anfragen nach einem Grad der Dienstqualität anandere Router entlang des Pfads oder der Pfade desDatenstroms weiterzuleiten. Dabei hält RSVP den Zustand desHosts und des Routers aufrecht, um den angeforderten Dienstbereitzustellen.

41.4 RSVP – Hochfahren der Sitzung

Um eine RSVP-Multicast-Sitzung einzuleiten, stellt ein Emp-fänger mittels des Internet Group Membership Protocol(IGMP) zuerst die durch eine IP-Zieladresse angegebene Mul-ticast-Gruppe zusammen. Im Falle einer Unicast-Sitzungübernimmt das Unicast-Routing die Rolle, die IGMP gemein-sam mit dem Protocol Independent Multicast (PIM) beimMulticasting spielt. Nachdem der Empfänger eine Gruppe zu-sammengestellt hat, beginnt ein potentieller Sender mit demSenden von RSVP-Pfadnachrichten an die IP-Zieladresse. Dieempfangende Anwendung erhält eine Pfadnachricht undbeginnt mit dem Senden einer entsprechenden Reservation-Request-Nachricht, welche die gewünschten Datenstrom-Deskriptoren mittels RSVP angibt. Nachdem die sendendeAnwendung eine Reservation-Request-Nachricht erhalten hat,beginnt der Sender mit dem Verschicken von Datenpaketen.

41.5 RSVP – Reservierungsmethode

Die Reservierungsmethode bezieht sich auf eine Menge vonKontrolloptionen, die einige unterstützte Parameter angeben.RSVP unterstützt zwei hauptsächliche Klassen von Reservie-rungen: getrennte Reservierungen (distinct) und gemeinsame


Reservierungen (shared). Getrennte Reservierungen richten injeder Sitzung einen Datenstrom für jeden relevanten Senderein. Eine gemeinsame Reservierung wird von einer Gruppevon Sendern benutzt, von denen bekannt ist, daß sie sich nichtgegenseitig stören. Im Bild 41.2 sind die Arten der getrenntenund gemeinsamen Reservierungsmethoden unter RSVP imKontext ihres Geltungsbereichs dargestellt. Jede unterstützteKombination aus Reservierungsmethode und Geltungsbereichwird entsprechend der Darstellung beschrieben.

getrennt gemeinsam

Shared-Explicit-Methode(SE-Methode)

Fixed-Filter-Methode(FF-Methode)

Geltungsbereich

Wildcard-Filter-Methode(WF-Methode)nicht definiert

Explizit

Wildcard

Reservierungen

41.5.1 Wildcard-Filter-Methode (WF)

Die Wildcard-Filter-Methode (WF) beschreibt eine gemein-same Reservierung mit einem beliebigen Geltungsbereich. Beieiner Reservierung mit der WF-Methode wird eine einzige Re-servierung erzeugt, in der Datenströme von allen auf dem Pfadliegenden Sendern zusammenkommen. Reservierungen lassensich als eine gemeinsame Röhre vorstellen, deren Umfang un-abhängig von der Anzahl der Sender der größten von allenEmpfängern für diese Verbindung angeforderten Ressourceentspricht. Die Reservierung verbreitet sich stromaufwärts zuallen sendenden Hosts und wird automatisch auf neue Senderausgedehnt, sobald diese erscheinen.

41.5.2 Fixed-Filter-Methode (FF)

Die Fixed-Filter-Methode (FF) beschreibt eine getrennte Re-servierung mit einem expliziten Geltungsbereich. Bei einer Re-servierung mit der FF-Methode wird ein eigenständiger Reser-vation-Request für Datenpakete von einem bestimmten Sendererzeugt. Der Geltungsbereich der Reservierung ist durch eineexplizite Auflistung von Sendern festgelegt. Die gesamte

Bild 41.2:RSVP unter-

stützt sowohlgetrennte alsauch gemein-

same Reservie-rungen


Reservierung für eine gegebene Sitzung auf einer Verbindungentspricht der Summe der FF-Reservierungen für alle ange-fragten Sender. FF-Reservierungen, die zwar von unterschied-lichen Empfängern angefordert wurden, aber den gleichenSender auswählen, müssen allerdings zusammengefaßt wer-den, um sich eine einzige Reservierung in einem gegebenenKnoten zu teilen.

41.5.3 Shared-Explicit-Methode (SE)

Die Shared-Explicit-Methode (SE) beschreibt eine gemeinsameReservierung mit einem expliziten Geltungsbereich. Die SE-Methode erzeugt eine einzige Reservierung, in der Daten-ströme von allen auf dem Pfad liegenden Sendern zusammen-kommen. Wie bei der FF-Reservierung werden die Sender (unddamit der Geltungsbereich) explizit angegeben, indem derEmpfänger die Reservierung vornimmt.

41.5.4 Folgen der Reservierungsmethoden

Sowohl bei der WF- als auch der SE-Methode handelt es sichum gemeinsame Reservierungen, die für Multicast-Anwen-dungen geeignet sind, in denen anwendungsspezifische Ein-schränkungen es unwahrscheinlich machen, daß mehrere Da-tenquellen gleichzeitig übertragen. Ein Beispiel hierfür ist dasAudio-Conferencing, bei dem eine begrenzte Anzahl von Leu-ten gleichzeitig spricht. Jeder Empfänger kann einen WF- oderSE-Reservation-Request zweimal für einen Audio-Kanal ab-setzen (um ein Übersprechen zu ermöglichen). Die FF-Methode erzeugt unabhängige Reservierungen für die Daten-ströme verschiedener Sender. Die FF-Methode ist besser fürVideosignale geeignet. Leider ist es nicht möglich, gemeinsamemit getrennten Reservierungen zusammenzufassen.

41.6 RSVP – Soft-State-Implementierung

Im Zusammenhang mit einem RSVP bezieht sich ein Soft-State(etwa: weicher Zustand) auf einen Zustand in Routern undEndknoten, der sich durch bestimmte RSVP-Nachrichten ak-tualisieren läßt. Die Soft-State-Eigenschaft ermöglicht es einemNetzwerk, dynamische Änderungen von Gruppenzugehörig-


keiten zu unterstützen und an Änderungen beim Routinganzupassen. Allgemein gesprochen wird der Soft-State voneinem auf RSVP basierendem Netzwerk eingesetzt, um demNetzwerk Änderungen des Zustands zu ermöglichen, ohneEndpunkte zu konsultieren. Dies steht im Gegensatz zu einerSwitched-Circuit-Architektur, in der ein Endpunkt einen Auf-ruf tätigt und im Falle eines Fehlschlags einen neuen Aufruftätigt.

Die Protokollmechanismen von RSVP stellen ein allgemeinesMittel für die Erstellung und Pflege eines verteilten Reservie-rungszustands über ein Netz von Multicast- und Unicast-Zu-stellungspfaden bereit.

Für die Wartung eines Reservierungszustands verfolgt RSVPeinen Soft-State in Router- und Host-Knoten. Der Soft-Statewird durch Pfad- und Reservation-Request-Nachrichten er-zeugt und regelmäßig aufgefrischt. Der Zustand wird gelöscht,wenn vor Ablauf eines Zeitintervalls bis zum Aufräumen keinepassenden Refresh-Nachrichten ankommen. Der Soft-Statekann außerdem als Folge einer expliziten Abbau-Nachricht(Teardown) gelöscht werden. RSVP überprüft den Soft-Stateregelmäßig, um Refresh-Nachrichten für Pfad- und Reserva-tion-Request-Nachrichten zu erstellen und an nachfolgendeHops weiterzuleiten.

Wenn sich eine Route ändert, initialisiert die nächste Pfad-nachricht den Zustand des Pfads auf der neuen Route. SpätereReservation-Requests richten einen Reservierungszustand ein.Der Soft-State im jetzt ungenutzten Segment läuft aus. (DieRSVP-Spezifikation fordert die Aufnahme von neuen Reser-vierungen durch das Netzwerk zwei Sekunden nach einerÄnderung der Topologie.)

Wenn es zu Zustandsänderungen kommt, verbreitet RSVPdiese Änderungen ohne Verzögerung vom einen zum anderenEnde eines RSVP-Netzwerks. Wenn sich der empfangene vomgespeicherten Zustand unterschiedet, wird der gespeicherteZustand aktualisiert. Wenn als Resultat Änderungen an denzu generierenden Refresh-Nachrichten auftreten, werden so-fort Refresh-Nachrichten generiert und weitergeleitet.


41.7 RSVP – Modell des Ablaufs

Unter RSVP sind Ressourcen für einfache Datenströme (d.h.unidirektionale Datenströme) reserviert. Jeder Sender istlogisch vom Empfänger getrennt, aber jede Anwendung kannals Sender und Empfänger agieren. Empfänger sind für dieRequests nach Reservierungen von Ressourcen zuständig. ImBild 41.3 ist diese allgemeine Betriebsumgebung dargestellt,während der nachfolgende Abschnitt eine Übersicht über diegenaue Abfolge von Ereignissen gibt.

Host

RSVP

RSVP-DämonAnwendung

Protokolle übergeordneter Schichten

Protokolle untergeordneter Schichten

Router

RSVP-Dämon

Routing-Protokoll-

Dämon

KlassifiziererPaket-planerKlassifizierer

Paket-planer

DatenDaten

RSVP

41.7.1 Allgemeiner Protokollablauf von RSVP

Der Vorgang der Ressourcenreservierung unter RSVP beginnt,sobald ein RSVP-Dämon auf lokale Routing-Protokolle zu-rückgreift, um Routen zu erhalten. Ein Host verschickt IGMP-Nachrichten, um eine Multicast-Gruppe zusammenzustellen,und RSVP-Nachrichten, um Ressourcen entlang des Pfadsbzw. der Pfade für die Zustellung von dieser Gruppe zu reser-vieren. Jeder Router, der sich an der Ressourcenreservierungbeteiligen kann, übergibt ankommende Datenpakete an einenPaketklassifizierer und reiht sie anschließend nach Bedarf ineinen Paketplaner (packet scheduler) ein. Der RSVP-Paket-klassifizierer legt die Route und die Klasse der Dienstqualitätfür jedes Paket fest. Der RSVP-Planer weist auf dem von jederSchnittstelle verwendeten Medium der VerbindungsschichtRessourcen für die Übertragung zu. Wenn das Medium derVerbindungsschicht die Dienstqualitäten selber verwaltenkann, ist der Paketplaner für die Aushandlung mit der Verbin-dungsschicht zuständig, um die von RSVP geforderte Dienst-qualität zu erhalten.

Bild 41.3:Die Betriebs-umgebung vonRSVP reser-viert Ressour-cen für unidi-rektionale Da-tenströme


Der Planer selbst teilt auf einem Medium mit passiver Dienst-qualität, wie beispielsweise einer gepachteten Leitung, Kapazi-täten für die Paketübertragung zu und kann weiterhin andereSystemressourcen wie beispielsweise CPU-Zeiten oder Zwi-schenspeicher zuweisen. Ein Request nach einer Dienstquali-tät, der typischerweise von einer Anwendung auf einem Emp-fänger-Host stammt, wird an die lokale RSVP-Implementie-rung als ein RSVP-Dämon übergeben.

Anschließend wird RSVP verwendet, um den Request an alleKnoten (Router und Hosts) entlang des/der umgekehrtenDatenpfade(s) an die Datenquelle(n) zu übergeben. In jedemKnoten wendet das RSVP-Programm eine als Zugangskon-trolle (admission control) bezeichnete lokale Entscheidungs-prozedur an, um zu bestimmen, ob er die angeforderte Dienst-qualität bieten kann. Wenn die Zugangskontrolle erfolgreichabsolviert wird, setzt das RSVP-Programm die Parameter desPaketklassifizierers und -planers entsprechend der gewünsch-ten Dienstqualität. Wenn die Zugangskontrolle an einem belie-bigen Knoten fehlschlägt, liefert das RSVP-Programm eineFehlernachricht an die Anwendung zurück, die den Requestausgelöst hat.

41.7.2 RSVP – Tunneln

Es ist unmöglich, RSVP oder ein anderes neues Protokoll zueinem Zeitpunkt im gesamten Internet einzusetzen. Tatsäch-lich kann es passieren, daß RSVP nie überall eingesetzt wird.RSVP muß daher auch dann für einen korrekten Protokollbe-trieb sorgen, wenn zwei RSVP-fähige Router über eine belie-bige Ansammlung von Nicht-RSVP-Routern verbunden sind.Eine dazwischenliegende Nicht-RSVP-Ansammlung kannkeine Ressourcenreservierungen vornehmen, so daß für einenDienst keine Garantien gegeben werden können. Wenn einederartige Ansammlung allerdings über eine ausreichendeKapazität verfügt, kann sie akzeptable und hilfreiche Echtzeit-dienste bereitstellen.

Um Verbindungen von RSVP-Netzwerken durch Nicht-RSVP-Netzwerke hindurch zu unterstützen, greift RSVP auf dasTunneln zurück, das bei Nicht-RSVP-Ansammlungen auto-matisch auftritt. Für das Tunneln ist es erforderlich, daßRSVP- und Nicht-RSVP-Router Pfadnachrichten an die Ziel-


adresse weiterleiten, indem sie eine lokale Routing-Tabelleverwenden. Wenn eine Pfadnachricht eine Nicht-RSVP-Ansammlung durchquert, tragen die Kopien der Nachricht dieIP-Adresse des letzten RSVP-fähigen Router. Request-Nach-richten für die Reservierung werden an den nächsten RSVP-fähigen Router weitergeleitet.

Zwei Argumente wurden gegen die Implementierung des Tun-nelns in einer RSVP-Umgebung vorgebracht. Erstens wirdRSVP eher vereinzelt als allgemein eingesetzt werden. Zwei-tens kann das Tunneln effektiver gestaltet werden, indem eineAndrangskontrolle (congestion control) in Situationen imple-mentiert wird, von denen bekannt ist, daß sie in hohem Maßegefordert sind.

Ein sporadischer oder vereinzelter Einsatz bedeutet, daß einigeTeile des Netzwerks RSVP vor anderen aktiv implementierthaben. Wenn RSVP von einem Ende zum anderen erforderlichist, gibt es keine Vorzüge ohne einen nahezu universellen Ein-satz, der aber unwahrscheinlich ist, solange ein frühzeitigerEinsatz keine wesentlichen Vorteile aufzeigt.

Eine Lösung: Weighted Fair-Queuing

Das Vorhandensein einer Technik zum Erzwingen einer effek-tiven Ressourcenreservierung (wie beispielsweise das WeightedFair-Queuing Schema von Cisco) an einer als Engpaß wirken-den Stelle kann sich positiv auswirken. Das Tunneln stellt nurdann eine Gefahr dar, wenn der Engpaß innerhalb einer Nicht-RSVP-Domain liegt und sich nicht vermeiden läßt. Im Bild41.4 ist eine RSVP-Umgebung mit einem Tunnel zwischenNetzwerken dargestellt, die auf RSVP basieren.

RSVP-Tunnel

Nicht-RSVP-Router

RSVP-Router

RSVP-Router

Bild 41.4:Eine RSVP-Umgebungkann einenTunnel zwi-schen Netz-werken aufwei-sen, dieauf RSVP ba-sieren


41.8 RSVP – Nachrichten

RSVP unterstützt vier grundlegende Nachrichtentypen: Reser-vation-Request-Nachrichten, Pfadnachrichten, Fehler- undAcknowledgment-Nachrichten sowie Abbaunachrichten. Die-se werden in den folgenden Abschnitten kurz beschrieben.

41.8.1 Reservation-Request-Nachrichten

Eine Reservation-Request-Nachricht wird von jedem empfan-genden Host an die Sender geschickt. Diese Nachricht folgtder von den Datenpaketen verwendeten Route in umgekehrterRichtung bis zu den sendenden Hosts. Ein Reservation-Request muß den sendenden Hosts zugestellt werden, damitsie für den ersten Hop geeignete Parameter zur Kontrolle desDatenverkehrs setzen können. RSVP verschickt keine positi-ven Acknowledgment-Nachrichten (Bestätigung).

41.8.2 Pfadnachrichten

Eine Pfadnachricht (Path) wird von jedem Sender auf denje-nigen Unicast- oder Multicast-Routen verschickt, die von ei-nem oder mehreren Routing-Protokollen bereitgestellt werden.Eine Pfad-Nachricht wird zum Speichern des Pfadzustands injedem Knoten verwendet. Der Pfadzustand wird verwendet,um Reservation-Requests in der umgekehrten Richtung wei-terzuleiten.

41.8.3 Fehler- und Acknowledgment-Nachrichten

Es gibt drei Arten von Fehler- und Acknowledgment-Nach-richten: Pfadfehlernachrichten, Reservation-Request-Fehler-nachrichten und Reservation-Request-Acknowledgment-Nachrichten.

Pfadfehlernachrichten resultieren aus Pfadnachrichten undbewegen sich auf Sender zu. Pfadfehlernachrichten werdenunter Rückgriff auf den Pfadzustand Hop für Hop weitergelei-tet. Bei jedem Hop stellt die IP-Zieladresse die Unicast-Adressedes vorangegangenen Hop dar.

Reservation-Request-Fehlernachrichten resultieren aus Reser-vation-Request-Nachrichten und bewegen sich auf den Emp-


fänger zu. Reservation-Request-Fehlernachrichten werdenunter Rückgriff auf den Reservierungszustand Hop für Hopweitergeleitet. Bei jedem Hop stellt die IP-Zieladresse die Uni-cast-Adresse des nächsten Hop-Knoten dar. In Fehlernachrich-ten können folgende Informationen enthalten sein:

− Admission failure (Zugang nicht geglückt)

− Bandwidth unavailable (Bandbreite ist nicht verfügbar)

− Service not supported (Dienst wird nicht unterstützt)

− Bad flow specification (Unzulässige Datenstrom-Spezifika-tion)

− Ambiguous path (Pfad nicht eindeutig)

Reservation-Request-Acknowledgment-Nachrichten werdenbeim Auftreten eines Reservation-Confirmation-Objekts in ei-ner Reservation-Request-Nachricht versendet. Diese Acknow-ledgment-Nachricht enthält eine Kopie der Reservierungsbe-stätigung (reservation confirmation). Eine Acknowledgment-Nachricht wird an die Unicast-Adresse eines empfangendenHost geschickt, und die Adresse wird dem Reservation-Con-firmation-Objekt entnommen. Eine Reservation-Request-Acknowledgment-Nachricht wird Hop für Hop an den Emp-fänger weitergeleitet (um den Mechanismus zum Überprüfender Hop-für-Hop-Vollständigkeit unterzubringen).

41.8.4 Abbaunachrichten

RSVP-Abbaunachrichten (Teardown) entfernen den Pfad- undReservierungszustand, ohne die Zeitspanne bis zum Auf-räumen abzuwarten. Abbaunachrichten können von einerAnwendung auf einem Endsystem (Sender oder Empfänger)oder einem Router als Resultat des Ablaufens eines Zustandsveranlaßt werden. RSVP unterstützt zwei Arten von Abbau-Nachrichten: Pfadabbaunachrichten und Reservation-Request-Abbaunachrichten. Pfadabbaunachrichten löschenden Pfadzustand (wodurch der Reservierungszustand gelöschtwird), wandern zu allen dem Ausgangspunkt nachfolgendenEmpfängern und werden wie Pfadnachrichten weitergeleitet.Reservation-Request-Abbaunachrichten löschen den Reser-vierungszustand, wandern zu allen vor dem Ausgangspunkt


liegenden passenden Sendern und werden wie entsprechendeReservation-Request-Nachrichten weitergeleitet.

41.9 RSVP – Paketformat

Im Bild 41.5 ist das Paketformat für RSVP dargestellt. In dennachfolgenden Zusammenfassungen wird eine Übersicht überdie in der Abbildung dargestellten Header- und Objektfeldergegeben.

Feldlänge in Bit

Felder des Nachrichten-Header für RSVP

Flags TypVersion MF Fragment-Offset

Prüfsumme Länge Reserviert Sende-TTL Message-ID

4 4 8 16 16 8 8

Reserviert

15 132 16

Feldlänge in Bit

RSVP Object Fields

Länge Klassen-Nr. K.-Typ Objektinhalt

16 8 8 variabel

41.9.1 Felder des Nachrichten-Headers für RSVP

Der Nachrichten-Header für RSVP umfaßt folgende Felder:

− Version – 4-Bit; gibt die Versionsnummer des Protokolls an(derzeit Version 1).

− Flags – 4-Bit; derzeit keine Flags definiert.

− Typ – 8-Bit; sechs mögliche (ganzzahlige) Werte, wie in derTabelle 41.1 dargestellt.

Wert Nachrichtentyp

1 Pfad 2 Reservation-Request 3 Pfadfehler 4 Reservation-Request-Fehler 5 Pfadabbau 6 Reservation-Abbau 7 Reservation-Request-Acknowledgment

Bild 41.5:Ein Paketfor-mat für RSVP

besteht ausNachrichten-Headern und

Objektfeldern

Tabelle 41.1:Werte des Felds

für den Nach-richtentyp


− Prüfsumme – 16-Bit; eine normale TCP/UDP-Prüfsummefür den Inhalt der RSVP-Nachricht, wobei das FeldChecksum durch Null ersetzt ist.

− Länge – 16-Bit; die Länge dieses RSVP-Pakets in Byte, ein-schließlich des allgemeinen Header und der nachfolgendenObjekte variabler Länge. Falls das Flag More Fragments(MF) gesetzt ist oder das Feld Fragment Offset ungleichNull ist, handelt es sich hierbei um die Länge des aktuellenFragments einer umfangreicheren Nachricht.

− Sende-TTL – 8-Bit; gibt den Wert für die IP-Lebensdauer(Time-To-Live = TTL) an, mit der die Nachricht übertragenwurde.

− Nachrichten-ID – 32-Bit; stellt einen Bezeichner bereit, denalle Fragmente einer Nachricht von einem gegebenen näch-sten bzw. vorhergegangenen RSVP-Hop gemein haben.

− More Fragments (MF) – Flag; niederwertigstes Bit eines 1-Byte-Word, dessen andere sieben höherwertigen Bits reser-viert sind. WF wird für alle Fragmente einer Nachrichtaußer dem letzten aktiviert.

− Fragment Offset – 24-Bit; gibt den Byte-Offset des Frag-ments in der Nachricht an.

41.9.2 Objektfelder für RSVP

Die Objektfelder für RSVP setzen sich folgendermaßen zu-sammen:

− Länge – 16-Bit; enthält die Gesamtlänge des Objekts inByte (muß immer mindestens 4 und ein Vielfaches von 4sein).

− Klassen-Nr. – Gibt die Objektklasse an. Jede Objektklasseträgt eine Bezeichnung. Eine RSVP-Implementierung mußdie in der Tabelle 41.2 aufgeführten Klassen erkennen.

Das hochwertigste Bit von Klassen-Nr. legt fest, welcheHandlung ein Knoten ausführen soll, wenn er die Klassen-Nr.eines Objekts nicht erkennt.

− K-Typ – Objekttyp, eindeutig innerhalb von Klassen-Nr.Die maximale Länge des Objektinhalts beträgt 65528 Byte.


Die Felder Class-Num und C-Type (zusammen mit demFlag-Bit) können gemeinsam als eine 16-Bit-Zahl ver-wendet werden, um einen eindeutigen Typ für jedes Objektzu definieren.

− Objektinhalt – Die Felder Länge, Klassen-Nr. und K-Typgeben die Form des Objektinhalts an. In der Tabelle 41.2finden Sie Definitionen der Objektklassen, die als Objekt-inhalt vorkommen können.

Objektklasse Beschreibung

Null Enthält die Klassen-Nr. Null und ihr K-Typ wirdignoriert. Ihre Länge muß mindestens 4 sein,kann aber auch ein Vielfaches von 4 sein. EinNull-Objekt kann überall in einer Abfolge vonObjekten auftreten, und der Inhalt wird vomEmpfänger ignoriert.

Session Enthält die IP-Zieladresse und möglicherweiseeine allgemeine Zielschnittstelle, um eine be-stimmte Sitzung für die weiteren nachfolgendenObjekte zu definieren (in jeder RSVP-Nachrichterforderlich).

RSVP Hop Trägt die IP-Adresse des RSVP-fähigen Knotens,der diese Nachricht verschickt hat.

Time Values Enthält, sofern vorhanden, Werte für die Zeit-spanne bis zum Aktualisieren und die Lebens-dauer (TTL) des Zustands, mit denen die Vor-gabewerte überschrieben werden.

Style Definiert die Reservierungsmethode und metho-denspezifischen Informationen, bei denen es sichnicht um eines der Objekte Flow Specificationoder Filter Specification handelt (in einer Reser-vation-Request-Nachricht enthalten).

Flow Specification Definiert eine gewünschte Dienstqualität (ineiner Reservation-Request-Nachricht enthalten).

Filter Specification Definiert eine Untermenge von Datenpaketenfür eine Sitzung, welche die gewünschte Dienst-qualität erhalten sollen (von einem Flow Speci-fication-Objekt innerhalb einer Reservation-Request-Nachricht angegeben).

Tabelle 41.2:Objektklassen

für RSVP


Objektklasse Beschreibung

Sender Template Enthält die IP-Adresse eines Senders und even-tuell einige zusätzliche Informationen zum De-multiplexen, um einen Sender zu identifizieren(in einer Pfadnachricht enthalten).

Sender TSPEC Definiert die Eigenschaften für den Verkehr desDatenstroms eines Senders (in einer Pfadnach-richt enthalten).

Adspec Enthält Bekanntmachungsdaten (advertisingdata) in einer Pfadnachricht.

Error Specification Gibt einen Fehler an (in einer Pfad-Fehler- oderReservation-Request-Fehlernachricht enthal-ten).

Policy Data Enthält Informationen, die es einem lokalen Si-cherheitsmodul ermöglichen, zu entscheiden, obeine verbundene Reservierung verwaltungs-gemäß zulässig ist (in einer Pfad- oder Reserva-tion-Request-Nachricht enthalten).

Integrity Enthält kryptographische Daten, um den Ur-sprungsknoten zu authentifizieren und mög-licherweise den Inhalt dieser Reservation-Request-Nachricht zu überprüfen.

Scope Eine explizite Angabe des Geltungsbereichs fürdas Weiterleiten einer Reservation-Request-Nachricht.

ReservationConfirmation

Enthält die IP-Adresse eines Empfängers, dereine Bestätigung angefordert hat. Kann ent-weder bei einem Reservation-Request odereinem Reservation-Request-Acknowledgementauftreten.

Tabelle 41.2:Objektklassenfür RSVP(Fortsetzung)

42 Routing Information Protocol (RIP)

42.1 Hintergrund

Beim Routing Information Protocol (RIP) handelt es sich umein Protokoll nach dem Distance-Vector-Verfahren, das alsMetrik auf den Hop-Count zurückgreift. RIP ist im globalenInternet weit verbreitet für den Einsatz beim Routing desDatenverkehrs und stellt ein Interior-Gateway-Protokoll (IGP)dar, das heißt, es führt das Routing innerhalb eines einzelnenautonomen Systems durch. Exterior-Gateway-Protokolle, wiebeispielsweise das Border Gateway Protocol (BGP), sind fürdas Routing zwischen verschiedenen autonomen Systemen zu-ständig. Ursprünglich erschien RIP als das Xerox-ProtokollGWINFO. Eine spätere, als routed (»Route De« gesprochen)bezeichnete Version, wurde 1982 mit dem Berkeley StandardDistribution (BSD) Unix ausgeliefert. RIP selber entwickeltesich zu einem Internet-Routing-Protokoll, und andere Proto-kollsammlungen greifen auf modifizierte Fassungen von RIPzurück. Das AppleTalk Routing Table Maintenance Protocol(RTMP) und das Banyan VINES Routing Table Protocol(RTP) basieren beispielsweise beide auf der RIP-Version desInternet Protocol (IP). Die letzten Erweiterungen zu RIP fin-den sich in der RIP-2-Spezifikation, die mehr Informationen inRIP-Paketen zuläßt und einen einfachen Mechanismus für dieAuthentifizierung bereitstellt.

IP-RIP wird in zwei Dokumenten formal definiert: RequestFor Comments (RFC) 1058 und 1723. Die RFC 1058 (1988)beschreibt die erste Implementierung von RIP, wohingegen die

KAPITEL 42Routing Information Protocol(RIP)


RFC 1723 (1994) die RFC 1058 aktualisiert. Die RFC 1058ermöglicht es RIP-Nachrichten, mehr Informationen undSicherheitsmerkmale aufzunehmen.

In diesem Kapitel werden die grundlegenden, mit RIP verbun-denen Fähigkeiten und Eigenschaften beschrieben. Zu den be-handelten Themen gehören der Vorgang des Routing-Update,die Routing-Metriken von RIP, die Stabilität des Routingsowie die Routing-Timer.

42.2 Routing-Updates

RIP verschickt Routing-Update-Nachrichten in regelmäßigenAbständen und wenn die Netzwerk-Topologie sich ändert. So-bald ein Router ein Routing-Update empfängt, das Änderun-gen für einen Eintrag enthält, aktualisiert er die neue Route inseiner Routing-Tabelle. Der Wert der Metrik für den Pfad wirdum eins erhöht, und auf den Sender wird als nächster Hopverwiesen. RIP-Router halten nur die beste Route (die Routemit dem niedrigsten Metrikwert) zu einem Ziel vor. Nach derAktualisierung der Routing-Tabelle beginnt der Router sofortdamit, Routing-Updates zu verschicken, um andere Netzwerk-Router über die Änderung zu informieren. Diese Updateswerden unabhängig von den regelmäßig geplanten Updatesder RIP-Router verschickt.

42.3 RIP – Routing-Metrik

RIP verwendet für die Entfernungsmessung zwischen demQuell- und einem Zielnetzwerk eine einzige Routing-Metrik(Hop-Count). Jedem Hop auf einem Pfad von der Quelle zumZiel wird ein Hop-Count zugewiesen, der üblicherweise 1 ist.Sobald ein Router ein Routing-Update empfängt, das einenneuen oder geänderten Eintrag für das Zielnetzwerk enthält,erhöht der Router den im Update angegebenen Metrikwertum eins und trägt das Netzwerk in die Routing-Tabelle ein.Die IP-Adresse des Senders wird als nächster Hop verwendet.

RIP schützt vor sich endlos fortsetzenden Routing-Schleifen,indem ein Grenzwert für die Anzahl der Hops auf einem Pfadvon der Quelle zu einem Ziel implementiert wird. Die maxi-male Anzahl von Hops auf einem Pfad beträgt 15. Wenn ein

Kapitel 42 • Routing Information Protocol (RIP) 535

Router ein Routing-Update empfängt, das einen neuen odergeänderten Eintrag enthält und wenn das Erhöhen des Me-trikwerts um eins dafür sorgen würde, daß die Metrik unend-lich (also 16) beträgt, dann wird das Zielnetzwerk als uner-reichbar angesehen.

42.4 RIP – Stabilitätsmerkmale

Für eine schnelle Anpassung an Änderungen in der Netzwerk-Topologie bringt RIP eine Reihe von Stabilitätsmerkmalenmit, die es mit vielen Routing-Protokollen gemein hat. Bei-spielsweise implementiert RIP die Split-Horizon- und Hold-Down-Mechanismen, um das Weiterleiten falscher Routing-Informationen zu vermeiden. Weiterhin bewahrt der Grenz-wert für den Hop-Count in RIP vor sich endlos fortsetzendenRouting-Schleifen.

42.5 RIP – Timer

RIP verwendet zur Ausführungsregulierung eine Vielzahl vonTimern. Hierzu zählen ein Routing-Update-Timer, ein Route-Timeout und ein Route-Flush-Timer. Der Routing-Update-Timer bemißt das Zeitintervall zwischen den regelmäßigenRouting-Updates. Üblicherweise ist er auf 30 Sekunden ge-stellt, wobei jedesmal eine geringe, zufällig bestimmte Anzahlvon Sekunden hinzugezählt wird, um Kollisionen zu vermei-den. Jeder Eintrag in der Routing-Tabelle verfügt über einenmit ihm verbundenen Timer für das Route-Timeout. Wenn dieZeit des Route-Timeout abgelaufen ist, wird die Route alsungültig markiert, aber noch so lange in der Tabelle aufbe-wahrt, bis der Route-Flush-Timer abläuft.

42.6 Paketformate

Die folgenden Abschnitte konzentrieren sich auf die Paket-formate von IP RIP und IP RIP 2, die im Bild 42.1 und Bild42.2 dargestellt sind. Jeder Abbildung folgt eine kurze Be-schreibung der dargestellten Felder.


42.6.1 Paketformat von RIP

Im Bild 42.1 ist das IP-RIP-Paketformat dargestellt.

Feldlänge in Byte

1

C D C E C C F

1 2 2 2 4 44

A = Befehl B = VersionsnummerC = NullD = Adreßfamilien-IDE = AdresseF = Metrik

BA

4

Die Felder des im Bild 42.1 dargestellten Paketformats für IPRIP werden im folgenden kurz beschrieben:

− Befehl – Zeigt an, ob es sich bei dem Paket um ein Request(Anforderung) oder um ein Response (Antwort) handelt.Ein Request fordert dazu auf, daß der Router seine ganzeRouting-Tabelle oder einen Teil davon senden soll. Bei ei-nem Response kann es sich um ein unaufgefordertes regel-mäßiges Routing-Update oder um eine Reaktion auf einenRequest handeln. Responses enthalten Einträge für Rou-ting-Tabellen. Für den Transport umfangreicher Routing-Tabellen werden mehrere RIP-Pakete verwendet.

− Versionnummer– Gibt die verwendete RIP-Version an. Die-ses Feld kann auf verschiedene, möglicherweise inkompa-tible Versionen hinweisen.

− Null – Nicht verwendet.

− Adreßfamilien-ID (AFI) – Gibt die verwendete Adreßfami-lie an. RIP wurde entworfen, um Routing-Informationenfür mehrere unterschiedliche Protokolle zu übertragen.Jeder Eintrag verfügt über eine ID für die Adreßfamilie, derdie Art der angegebenen Adresse kennzeichnet. Die AFI fürIP ist 2.

− Adresse – Gibt die IP-Adresse des Eintrags an.

− Metrik – Zeigt an, wie viele Hops (Router) des Internetz-werks auf dem Weg zum Ziel durchquert wurden. DieserWert liegt für eine gültige Route zwischen 1 und 15, oder16 für eine unerreichbare Route.

Bild 42.1:Ein IP-RIP-

Paket setzt sichaus neun Fel-dern zusam-

men

Kapitel 42 • Routing Information Protocol (RIP) 537

Die Felder AFI, Adresse und Metrik dürfen bis zu 25 Mal ineinem einzigen IP-RIP-Paket vorkommen. (Bis zu 25 Zielekönnen in einem einzigen RIP-Paket aufgeführt werden.)

42.6.2 Paketformat von RIP 2

Die RIP-2-Spezifikation (in der RFC 1723 beschrieben) er-möglicht weitere Informationen in RIP-Paketen und bietet ei-nen einfachen Mechanismus für die Authentifizierung. Im Bild42.2 ist das Paketformat von IP RIP 2 dargestellt.

Length of Field in Octets

1 1 1 2 2 4 4 4 4

Befehl Version Nichtverwendet

Adreß-familien-

ID

Routen-Tag

IP-Adresse

Subnetz-maske

NächsterHop

Metrik

Die Felder des im Bild 42.2 dargestellten Paketformats für IPRIP 2 werden im folgenden kurz beschrieben:

− Befehl – Zeigt an, ob es sich bei dem Paket um ein Request(Anforderung) oder um ein Response (Antwort) handelt.Ein Request fordert dazu auf, daß der Router seine ganzeRouting-Tabelle oder einen Teil davon senden soll. Bei ei-nem Response kann es sich um ein unaufgefordertes regel-mäßiges Routing-Update oder um eine Reaktion auf einenRequest handeln. Responses enthalten Einträge für Rou-ting-Tabellen. Für den Transport umfangreicher Routing-Tabellen werden mehrere RIP-Pakete verwendet.

− Version – Gibt die verwendete RIP-Version an. Bei der Im-plementierung eines beliebigen RIP-2-Felds in einem Paketfür RIP oder dem Einsatz der Authentifizierung wird diesesFeld auf 2 gesetzt.

− Nicht verwendet – Wert ist auf Null gesetzt.

− Adreßfamilien-ID (AFI) – Gibt die verwendete Adreßfami-lie an. RIP wurde entworfen, um Routing-Informationenfür mehrere unterschiedliche Protokolle zu übertragen. Je-der Eintrag verfügt über eine ID für die Adreßfamilie, derdie Art der angegebenen Adresse kennzeichnet. Die AFI fürIP ist 2. Falls die AFI für den ersten Eintrag der Nachricht

Bild 42.2:Ein IP-RIP-2-Paket setzt sichaus ähnlichenFeldern zusam-men wie einIP-RIP-Paket


0xFFFF ist, enthält der Rest des Eintrags Authentifizie-rungsinformationen. Derzeit stellt ein einfaches Kennwortden einzigen Authentifizierungstyp dar.

− Routen-Tag – Stellt eine Methode zum Unterscheiden voninternen Routen (von RIP erfahren) und externen Routen(von anderen Protokollen erfahren) bereit.

− IP-Adresse – Gibt die IP-Adresse des Eintrags an.

− Subnetzmaske – Enthält die Subnetzmaske für den Eintrag.Falls dieses Feld auf Null gesetzt ist, wurde für diesen Ein-trag keine Subnetzmaske angegeben.

− Nächster Hop – Gibt die IP-Adresse des nächsten Hop an,an den Pakete für den Eintrag weitergeleitet werden sollen.

− Metrik – Zeigt an, wie viele Hops (Router) des Internetz-werks auf dem Weg zum Ziel durchquert wurden. DieserWert liegt für eine zulässige Route zwischen 1 und 15, oder16 für eine unerreichbare Route.

Die Felder AFI, Adresse und Metrik dürfen bis zu 25 Mal ineinem einzigen IP-RIP-Paket vorkommen. Somit können biszu 25 Einträge für Routing-Tabellen in einem einzigen RIP-Paket aufgeführt werden. Falls die AFI eine authentifizierteNachricht kennzeichnet, können nur 24 Einträge für Rou-ting-Tabellen angegeben werden.

43 Simple Multicast Routing Protocol (SMRP)

43.1 Hintergrund

Beim Simple Multicast Routing Protocol (SMRP) handelt essich um ein Protokoll für die Transportschicht, das für dasWeiterleiten von Multimedia-Datenströmen über AppleTalk-Netzwerke entwickelt wurde. Es unterstützt das QuickTimeConferencing (QTC) von Apple. SMRP sorgt für eine verbin-dungslose und möglichst gute Zustellung von Multicast-Datagrammen und stützt sich für Dienste auf die zugrundelie-genden Protokolle für die Netzwerkschicht. Insbesondere er-leichtert SMRP die Übertragung von Daten von einer einzigenQuelle zu mehreren Zielen. Dieses Kapitel konzentriert sichauf die funktionalen Elemente und die Protokollausführungvon SMRP. Im Bild 43.1 ist eine verallgemeinerte SMRP-Umgebung dargestellt.

Bei der Schaffung von SMRP übernahm Apple einige Strate-gien und Konzepte von anderen Protokollen und Techniken.Dadurch erhielten viele Begriffe in Apples SMRP-Umgebungeine eigene Bedeutung. In der Tabelle 43.1 sind die SMRP-spezifischen Begriffe und deren Definitionen zusammengefaßt.In diesem Kapitel wird auf diese Begriffe zurückgegriffen.

KAPITEL 43Simple Multicast Routing Protocol (SMRP)


Knoten

Endpunkt

Multicast-Gruppe

Tunnel

43.2 SMRP – Multicast-Transportdienste

SMRP wurde entworfen, um Routern und Rechnern an End-punkten den Austausch von Multicast-Paketen über Proto-kolle der Netzwerkschicht zu ermöglichen. SMRP kann dieZuordnungen von Multicast-Adressen verwalten und macht eseiner einzelnen Quelle möglich, an eine eindeutige Multicast-Gruppenadresse gerichtete Daten zu verschicken. Empfängerschließen sich dieser Gruppe an, falls sie am Empfang von Da-ten für diese Gruppe interessiert sind. Zur Unterstützung die-ser Funktionen greift SMRP auf einige Dienste zurück. Diefolgenden Beschreibungen konzentrieren sich auf die wesentli-chen Vorgänge und Techniken, welche die SMRP-Dienste er-möglichen. Zu diesen zählen: die Adreßverwaltung, das Mul-ticast Transaction Protocol (MTP), die Knotenverwaltung, dieVerwaltung von Multicast-Routen, das Weiterleiten von Datensowie die Topologieverwaltung.

Bild 43.1:Eine allge-

meine SMRP-Umgebung er-

streckt sich voneiner Multi-cast-Gruppebis zu einem

Endpunkt

Kapitel 43 • Simple Multicast Routing Protocol (SMRP) 541

Begriff Definition

Direkt benach-barter Endpunkt

In bezug auf einen Knoten bzw. Endpunkt: einEndpunkt im gleichen lokalen Netzwerk bzw.ein durch einen Tunnel angebundener Knoten.

Direkt benach-barter Knoten

In bezug auf einen Knoten oder Endpunkt: einKnoten im gleichen lokalen Netzwerk.

Tochter-Endpunkt Ein direkt benachbarter Endpunkt, an den einKnoten Multicast-Daten schickt.

Tochterknoten In bezug auf einen Mitgliederknoten einerGruppe: ein weiter vom Erzeuger-Endpunkt ent-fernter Nachbarknoten.

Tochteranschluß In bezug auf eine Gruppe: ein Anschluß, der dieSchnittstelle zu einem oder mehreren Tochter-knoten darstellt.

Erzeuger-Endpunkt Der Endpunkt, der die Erzeugung der Gruppegefordert hat, und die Quelle der Daten, die andie Gruppe weitergeleitet werden.

Erzeugerknoten Der Primärknoten, der die Gruppe erzeugt hat.DesignierterKnoten

Ein SMRP-Router, der zum Primär- oder Sekun-därknoten ernannt worden ist.

Zielbaum Der in einem lokalen Netzwerk wurzelnde um-fassende Baum mit auf das lokale Netzwerk aus-gerichteten Pfaden.

Verteilungsbaum Die aktive Untermenge eines Quellbaums, diefür das Weiterleiten von Multicast-Daten füreine Gruppe verwendet wird.

Endpunkt Eine nicht weiterleitende Quelle oder ein nichtweiterleitendes Ziel von Multicast-Paketen.

Gruppe Eine Menge von empfangenden Endpunktenoder eine Multicast-Adresse.

Zusammenschluß Begriff für den Vorgang, Mitglied einer Gruppezu werden.

AnschließenderPfad

Ein Pfad im Zielbaum für ein lokales Netzwerk,der zum Erreichen eines Erzeugerknotens ver-wendet wird und der mittels des Distance-Vector-Algorithmus von SMRP erzeugt wurde.

Verlassen Begriff für den Vorgang, die Mitgliedschaft ineiner Gruppe aufzugeben.

Lokales Netz Eine Datenverbindung mit gemeinsamen Zugriffund das zugehörige Protokoll für die Netzwerk-schicht. Ein LAN kann mehr als ein lokales Netzunterstützen.

Mitglieder-Endpunkt

Ein Endpunkt, der Mitglied einer Gruppe ist.

Tabelle 43.1:SMRP-spezi-fische Begriffeund derenDefinition


Begriff Definition

Mitgliederknoten Ein Knoten, der sich im Verteilungsbaum einerGruppe befindet.

Nachbarknoten In bezug auf einen Mitgliederknoten einerGruppe: ein direkt benachbarter Knoten, dersich im Verteilungsbaum für die Gruppe befin-det.

Knoten Ein SMRP implementierender Router.Vateranschluß In bezug auf eine Gruppe: der Anschluß, der

die Schnittstelle zum Vaterknoten darstellt.Vaterknoten In bezug auf einen Mitgliederknoten einer

Gruppe: der näher am Erzeuger-Endpunkt be-findliche Nachbarknoten.

Anschluß Eine Schnittstelle eines SMRP-Routers zu einemlokalen Netzwerk oder einem Tunnel.

Urheberanschluß Die Adresse des Knotens, der für die Behand-lung von Gruppenanfragen verantwortlich ist.

Primärknoten Der in einem Lokalen Netzwerk für das Erstel-len von Gruppen zuständige Knoten.

Umgekehrter Pfad Die Umkehrung eines anschließenden Pfads, einPfad im Quellbaum für ein lokales Netz, derzum Weiterleiten von Multicast-Daten verwen-det wird.

Sekundärknoten Derjenige Knoten, der zur Übernahme der Auf-gaben eines verschwindenden Primärknotensbereit ist.

Quellbaum Der in einem lokalen Netzwerk wurzelnde um-fassende Baum mit vom lokalen Netzwerk wei-senden Pfaden.

Umfassender Baum Eine verbundene Menge von Pfaden, die lokaleNetzwerke zwischen allen Knoten eines Inter-netzwerks mit nur einem Pfad zwischen jeweilszwei Knoten verwendet.

Tunnel Eine Punkt-zu-Punkt-Verbindung zwischen Kno-ten nicht direkt benachbarter Netzwerke durchRouter, die kein SMRP implementieren.

43.2.1 SMRP – Verwaltung von Multicast-Adressen

Die Adressierung von SMRP basiert auf dem lokalen Netz-werk eines Erzeuger-Endpunkts. Eine SMRP-Adresse bestehtaus zwei Teilen: einer Netzwerk-Nummer mit einer Länge von3 Byte und einer Socketnummer mit einer Länge von 1 Byte.

Tabelle 43.1:SMRP-spezi-

fische Begriffeund derenDefinition

(Fortsetzung)


Jedes lokale Netzwerk wird mit einem Bereich eindeutigerNetzwerk-Nummern konfiguriert.

Bei der Zuordnung von Netzwerk-Nummern müssen dieNetzwerk-Nummern lokalen Netzen für SMRP zugewiesenwerden und im gesamten Internetzwerk eindeutig sein. Jedemlokalen Netz kann ein beliebiger fortlaufender Bereich von 3-Byte Netzwerk-Nummern zugewiesen werden. Die Anzahl derfür ein lokales Netz verfügbaren Multicast-Gruppen entsprichtdem 254-fachen der Anzahl zugewiesener Netzwerk-Num-mern. Netzwerk-Nummern können konfiguriert oder auf-grund der Netzwerk-Nummer zugrundeliegender Netzwerk-Protokolle zugeordnet werden. Bereiche eindeutiger Netz-werk-Nummern können für unterstützte Netzwerk-Protokollereserviert werden.

Im Falle der Zuordnung von Multicast-Adressen müssenMulticast-Adressen von SMRP auf Multicast-Adressen derNetzwerk-Schicht abgebildet werden, denen wiederum Multi-cast-Adressen der Verbindungsschicht zugeordnet sind. Fürjede Art von Netzwerk-Schicht muß für SMRP ein Block mitMulticast-Adressen vorgehalten werden. Günstigstenfalls er-folgt eine direkte Zuordnung der Adressen. Meistens ist einedirekte Zuordnung aber nicht möglich, und mehrere Multi-cast-Adressen von SMRP werden auf eine einzige Multicast-Adresse der Netzwerk-Schicht abgebildet.

Die Art und Weise, in der Multicast-Adressen auf Adressender Netzwerk-Schicht abgebildet werden, hängt von der Netz-werk-Schicht ab. Wenn Multicast-Adressen der SMRP-Trans-portschicht sich nicht direkt auf Multicast-Adressen der Netz-werk-Schicht abbilden lassen, ist eine Filterung der Multicast-Adressen von SMRP erforderlich. Wenn Multicast-Adressender Netzwerk-Schicht sich nicht direkt auf Multicast-Adressender Verbindungsschicht abbilden lassen, wird von der Netz-werk-Schicht erwartet, daß sie nicht unterstützte Multicast-Adressen ausfiltert.

Es gibt folgende Voreinstellungen für Multicast-Adressen derNetzwerk-Schicht: AllEndpoints, AllNodes und AllEntities.AllEndpoints-Nachrichten, die an diese Multicast-Adresse ge-schickt werden, werden an alle Endpunkte in einem Netzwerkübertragen. AllNodes-Nachrichten, die an diese Multicast-Adresse geschickt werden, werden an alle SMRP-Routingkno-


ten in einem Netzwerk übertragen. Und AllEntities-Nachrich-ten, die an diese Multicast-Adresse geschickt werden, werdenan alle Endpunkte und an alle SMRP-Routingknoten in einemNetzwerk übertragen.

43.2.2 SMRP – Multicast-Transaktionsprotokoll (MTP)

SMRP bezieht ein Multicast-Transaktionsprotokoll (MTP) mitein, das drei Transaktionstypen vorsieht: Knoten, Endpunktund gleichzeitig Knoten/Endpunkt. Die Kommunikation zwi-schen direkt benachbarten Knoten und zwischen Knoten undEndpunkten erfolgt mittels Request/Response-Transaktionen.

Responses erfolgen immer als Unicast. MTP sorgt beim Auf-treten von Netzwerkfehlern für eine erneute Übertragung vonRequests und/oder Responses. Nur Hello- und Designated-Node-Request-Pakete werden als Multicast-Nachrichten ver-schickt, alle übrigen als Unicasts. Requests von Endpunktenzu Knoten werden als Multicasts verschickt, während Re-quests von Knoten zu Endpunkten entweder als Unicasts oderals Multicasts verschickt werden.

Der grundlegende MTP-Entwurf, wie er auf SMRP-Routernimplementiert ist, setzt zwei Warteschlangen für alle Transak-tionen ein: eine Request-Warteschlange und eine Response-Warteschlange. Die Einträge der Request-Warteschlange wer-den gelöscht, sobald der Router das erhaltene Response bear-beitet hat. Das Response wird unter Zuhilfenahme einer imEintrag angegebenen Rücksendeadresse (callback) bearbeitet,sofern es zu einem Request paßt.

Nach der Bearbeitung des Response wird das Request ge-löscht. Wenn das Request unbeantwortet bleibt, wird einintern generiertes Reject-Response an die Rücksendeadressegeschickt. Requests können in Abhängigkeit vom Kontext aneine Unicast-Adresse oder an die Multicast-Adressen AllNodesoder AllEndpoints geschickt werden. Solange sie nicht explizitumadressiert werden, werden Requests an die Multicast-Adresse AllNodes geschickt.

Die Einträge der Response-Warteschlange werden bei Emp-fang eines Request-Pakets erzeugt. Auf den Eintrag wird wäh-rend der gesamten Bearbeitung des Request verwiesen, undder bearbeitete Eintrag bleibt so lange in der Warteschlange,


bis er abläuft und aus der Warteschlange gelöscht wird. Fallsein vervielfältigtes Request empfangen wird, wird es ignoriert,wenn der SMRP-Router das ursprüngliche Request noch be-arbeitet oder wenn ein vervielfältigtes Response nach Beendi-gung der Bearbeitung generiert wird. Für einige empfangeneRequests ist es erforderlich, daß ein SMRP-Routing-Knotenweitere Requests generiert. In diesem Fall wird das bzw. wer-den die ursprüngliche(n) Request(s) von der Bearbeitungspro-zedur für die Rücksendung bearbeitet, die zum Request-Eintrag des Routing-Knotens gehört.

43.2.3 SMRP – Knotenverwaltung

SMRP baut für die Transporterlaubnis von Multicast-Datagrammen auf einige Beziehungen zwischen Knoten auf,zu denen designierte Knoten, direkt benachbarte Knoten undTunnelknoten gehören.

Bei designierten Knoten handelt es sich um SMRP-Router, dieals Primär- oder Sekundärknoten angegeben sind. Ein desi-gnierter Primärknoten ist für die Zuteilung von Gruppen-adressen zuständig. Ein Primärknoten ist für jedes lokaleNetzwerk mit SMRP-Knoten erforderlich. Ein designierterSekundärknoten ist erforderlich, falls ein lokales Netzwerküber mehr als einen Knoten verfügt. Der Sekundärknoten wirdfür die Pflege einer Kopie der Gruppenerzeugungstabelle(Group Creation Table) verwendet und wird zum Primär-knoten, falls der Primärknoten für ein Netzwerk ausfällt.

Der wesentliche Vorgang beim Bestimmen des Primär- und Se-kundärknotens beginnt beim Hochfahren, wenn ein Knotenzuerst versucht, zum designierten Sekundärknoten in jedemlokalen Netz zu werden. Bei Erfolg versucht der Knoten an-schließend, zum designierten Primärknoten zu werden. Trans-aktionen werden entweder von einem Primärknoten-Requestoder einem Sekundärknoten-Request eingeleitet. Das Fehleneiner Antwort auf den Request zeigt an, daß die Aushandlungerfolgreich war, wohingegen eine positive Antwort anzeigt,daß die Aushandlung fehlschlug. Wenn zwei Knoten gleichzei-tig versuchen, zum designierten Primärknoten oder zum desi-gnierten Sekundärknoten zu werden, wird der Knoten mit derniedrigeren Unicast-Adresse für die Netzwerk-Schicht zumdesignierten Knoten. Ein Primärknoten verschickt anschlie-


ßend Add-Group-Entry-Pakete und Remove-Group-Entry-Pakete an den Sekundärknoten für ein lokales Netzwerk, umfür eine identische Gruppenerzeugungstabelle zu sorgen.

In bezug auf einen bestimmten Knoten oder Endpunkt exi-stiert ein direkt benachbarter Knoten im gleichen lokalenNetzwerk. Die Knoten verschicken über jeden Anschluß re-gelmäßig Hello-Pakete. Wenn von einem direkt benachbartenKnoten innerhalb einer bestimmten Zeitspanne kein Hello-Pa-ket empfangen wird, wird der Status für den direkten Nach-barn im Knoten auf »Außer Betrieb« gesetzt, und die zugehö-rigen Routen werden als unerreichbar markiert. Notify-Paketewerden an jeden direkt benachbarten Knoten geschickt, so-bald ein Anschlußzustand des Knotens in einen anderen Be-triebszustand übergeht. Jeder Knoten führt für jeden direktbenachbarten Knoten einen Eintrag in der Knotentabelle. DerTabelleneintrag wird erstellt, wenn zum ersten Mal ein Paketvom direkt benachbarten Knoten empfangen wird. Tabellen-einträge enthalten den Zeitpunkt des letzten Hello-Pakets unddessen Zustand.

Bei Tunnelknoten handelt es sich um Punkt-zu-Punkt-Verbin-dungen zwischen Knoten in nicht direkt benachbarten Netz-werken durch Router, die kein SMRP implementieren. Es gibtzwei verschiedene Arten von Tunnelknoten: Tunnel zwischenKnoten und Tunnel zwischen einem Knoten und einem End-punkt.

Tunnelknoten werden hinsichtlich der Verwendung von Hello-Paketen und Notify-Paketen von jedem Knoten auf dieselbeWeise als Einträge in der Tabelle für direkt benachbarte Kno-ten geführt wie andere benachbarte Knoten. Entsprechendermöglicht es SMRP Tunnelknoten, sich auf die gleiche Weisewie jeder andere direkt benachbarte Knoten Gruppenanzuschließen oder diese zu verlassen.

Cisco unterstützt keine Tunnelknoten. SMRP kann jedoch indie Lage versetzt werden, Tunnel in der Netzwerk-Schichtzwischen nicht direkt benachbarten Knoten zu betreiben.


43.2.4 SMRP – Multicast-Routen

SMRP stützt sich für die Ermittlung von Routen für Multi-cast-Verkehr auf ein Weiterleitungsschema, das auf einem um-fassenden Baum basiert. Dieses Verfahren der Routenermitt-lung beruht auf dem Einsatz eines Distance-Vector-Algorith-mus. Ein Knoten verschickt beim Hochfahren und bei Rou-tenänderungen Distance-Vector-Request-Pakete an direkt be-nachbarte Knoten. Die durch den Vektor angegebene Distanzentspricht der zum Erreichen eines bestimmten Bereichs vonNetzwerk-Nummern benötigten Anzahl von Hops. Knotenenthalten einen Vektor für jeden Eintrag in der Tabelle fürNetzwerk-Routen und verschicken so viele Pakete, wie für denVersand aller Vektoren erforderlich sind. Bei Routenänderun-gen verschickt jeder Knoten Distance-Vector-Request-Paketean jeden direkt benachbarten Knoten.

Wenn eine Route an einem Anschluß empfangen wird, mußdie Adresse des Urheberanschlusses für die Route für alle An-schlüsse gesetzt werden. Da die Gruppenadresse an die Netz-werk-Adresse gebunden ist, wird die Adresse des Urheberan-schlusses auch dann verwendet, wenn ein Knoten ein Requestfür bestimmte Gruppen bearbeiten muß. Wenn es sich bei derAdresse des Urheberanschlusses um die Knotenadresse selberhandelt, ist der Knoten für das Request zuständig. Bei Knotenmit demselben Pfad wird der für ein Request zuständige Kno-ten darüber bestimmt, welcher der Knoten über die höchsteNetzwerk-Adresse verfügt.

Wenn ein Knoten ein Distance-Vector-Request mit Einträgenfür unbekannte lokale Netzwerke empfängt, werden in derNetzwerk-Routentabelle für den Knoten Netzwerk-Bereichefür damit verbundene lokale Netzwerke hinzugefügt, wobeidie empfangene Distanz um eins erhöht wird. Der direktbenachbarte Knoten, der das Distance-Vector-Paket geschickthat, wird daraufhin zum Vaterknoten für das lokale Netz-werk. Ein Tabelleneintrag wird aktualisiert, wenn einDistance-Vector-Paket für bekannte lokale Netzwerke empfan-gen wird und die Distanz plus eins niedriger ausfällt als derEintrag in der Netzwerk-Routentabelle. Ein Tie-Break gelangtzum Einsatz, wenn ein Distance-Vector-Paket von einem direktbenachbarten Knoten mit derselben Distanz zu einem lokalenNetzwerk empfangen wird. Der Tie-Break wird als der direkt


benachbarte Knoten mit einer höheren Unicast-Adresse derNetzwerk-Schicht festgelegt. Dieser Knoten wird als der Vater-knoten für das lokale Netzwerk ausgewiesen.

43.2.5 SMRP – Verwaltung von Multicast-Gruppen

Die Teilnahme an einer Multicast-Gruppe wird unter SMRPdurch ein Verfahren geregelt, das Verhandlungen zwischenEndpunkten und Knoten miteinbezieht. Ein Endpunkt ver-sucht sich einer Gruppe anzuschließen, indem er einen Knotenin einem lokalen Netzwerk kontaktiert. Ein beliebig angespro-chener Knoten ist für das Anschließen des Verteilungsbaumsfür die Gruppe zuständig, indem er Pfade zu einem vorhande-nen Verteilungsbaum aktiviert. Knoten verlassen einen Vertei-lungsbaum für eine Gruppe, indem sie Pfade deaktivieren, so-bald keine Mitglieder-Endpunkte für die Gruppe auf diesenPfaden mehr vorhanden sind. Für die Verwaltung von SMRP-Gruppen sind vier grundlegende Vorgänge erforderlich: dasErzeugen (create), Anschließen (join), Verlassen (leave) undLöschen (delete).

Ein Endpunkt schickt ein Create-Group-Request an den desi-gnierten Primärknoten, sobald er mit dem Versenden von Da-ten an eine Gruppe beginnen will. Der Primärknoten weistdaraufhin eine unbenutzte Gruppenadresse zu und erstellt ei-nen Eintrag in der Gruppenerzeugungstabelle. Schließlich lie-fert der Primärknoten die Gruppenadresse an den Erzeuger-Endpunkt und schickt ein Add-Group-Request an den Sekun-därknoten, sofern dieser vorhanden ist.

Endpunkte verschicken Requests, um den Anschluß an eineMulticast-Gruppe einzuleiten. Der Vaterknoten für eineGruppe in einem lokalen Netzwerk reagiert auf Join-Group-Request-Pakete von Endpunkten. (Ein Knoten stellt fest, ob erder Vaterknoten ist, indem er die Netzwerk-Nummer in derGruppenadresse untersucht.) Wenn der Vaterknoten für eineGruppe ein Join-Group-Request erhält und der Knoten nochkein Mitglied der Gruppe ist, leitet der Knoten den Join-Group-Request an den Erzeugerknoten der Gruppe, weiter.Schließlich erreicht das Join-Group-Request-Paket einenMitgliederknoten oder den Erzeugerknoten der Gruppe undein Join-Group-Confirm-Paket wird über den umgekehrtenPfad zurückgeschickt. Der Mitglieder- oder Erzeugerknoten


fügt einen Tochteranschluß in der Gruppenweiterleitungsta-belle hinzu, falls das Join-Group-Request an diesem Anschlußempfangen wurde. Sobald Daten auf dem umgekehrten Pfadankommen, werden sie an alle Tochteranschlüsse weitergelei-tet. Wenn der Erzeugerknoten das erste Join-Request für eineGruppe erhält, leitet er das Request an den Erzeuger-End-punkt weiter, damit dieser mit dem Verschicken von Datenbeginnen kann.

Zum Verlassen einer Multicast-Gruppe verschicken End-punkte Leave-Group-Request-Pakete für ihr lokales Netz. DerVaterknoten der Gruppe in einem lokalen Netzwerk liefert einLeave-Group-Confirm-Paket an den Endpunkt zurück undverschickt ein Group-Member-Request-Paket für den Toch-teranschluß. Falls der Vaterknoten kein Group-Member-Con-firm-Paket für den Tochteranschluß von einem Mitgliederkno-ten oder Endpunkt erhält, entfernt der Vaterknoten diesen An-schluß aus dem Eintrag. Falls keine Tochteranschlüsse mehrim Eintrag des Vaterknotens vorhanden sind, setzt er den Sta-tus des Eintrags auf »Verlassen« und schickt ein Leave-Group-Request-Paket im Verteilungsbaum an seinen Vaterknoten.Jeder betroffene Vaterknoten entfernt bei Erhalt des Leave-Group-Confirm-Pakets den Eintrag aus seiner Gruppenweiter-leitungstabelle.

Der Endpunkt verschickt ein Delete-Group-Request, sobald ermit dem Senden von Daten an die Gruppe aufhören will. Nurder designierte Primärknoten antwortet auf dieses Request.

43.2.6 Weiterleiten von Multicast-Datagrammen

Das Weiterleiten von Daten unter SMRP betrifft Knoten, dieMulticast-Datagramme über aktive Pfade des Quellbaums füreine bestimmte Gruppe weiterleiten. Ein aktiver Pfad verfügtüber Mitglieder-Endpunkte für die Gruppe, oder es handeltsich um einen Pfad, der als Durchgangspfad benötigt wird, umandere aktive Pfade zu erreichen. Die Teilmenge der aktivenPfade für den Quellbaum stellt den Verteilungsbaum für dieGruppe dar. Zum Weiterleiten von Daten unter SMRP gehö-ren eine Reihe von Verhandlungen zwischen Endpunkten undKnoten. Im allgemeinen empfangen Knoten Multicast-Datagramme, wenn Endpunkte Daten an eine Gruppeschicken. Der Erzeuger-Endpunkt kann Datenpakete mit einer


Multicast-Adresse für die Netzwerk-Schicht an sein lokalesNetzwerk schicken, sobald er ein Join-Request vom Erzeuger-knoten empfangen hat. Vaterknoten im lokalen Netzwerkerhalten diesen Multicast und leiten das Paket an alle Toch-teranschlüsse in der Weiterleitungstabelle der Gruppe weiter.Ein Knoten verschickt ein Paket nur dann als Multicast für einlokales Netzwerk, wenn es sich bei ihm um den Vaterknotenfür die Gruppe dieses lokalen Netzwerks handelt und dieDaten auf dem Vateranschluß für die Gruppe empfangenwurden. Knoten leiten Daten außerdem an direkt benachbarteTunnelknoten weiter, die Mitglieder der Gruppe sind. Im Falleeines SMRP-Tunnels werden Multicast-Datagramme in einemUnicast-Paket der Netzwerk-Schicht gekapselt.

43.2.7 Umgang mit Topologieänderungen unter SMRP

SMRP-Einheiten legen Topologiekarten an, um Änderungenvon Pfaden oder Mitgliedschaften in einer SMRP-Umgebungzu verwalten. SMRP sind einige typische Topologieänderun-gen bekannt und definiert spezifische Techniken für deren Be-handlung.

Verschwundene Mitglieder-Endpunkte

Um verschwundene Mitglieder-Endpunkte zu entdecken,schicken Knoten regelmäßig ein Group-Member-Request-Pa-ket an jeden aktiven Tochteranschluß. Jeder Mitgliederknotenund Endpunkt liefert ein Group-Member-Confirmation-Paketan den Vaterknoten zurück. Wenn der Vaterknoten keineGroup-Member-Confirmation-Pakete erhält, schickt der Kno-ten ein Leave-Group-Request-Paket an seinen Vaterknotenund löscht anschließend den Gruppeneintrag.

Verlassene Gruppen

Um verlassene Gruppen aufzuspüren, schicken Erzeugerkno-ten regelmäßig ein Group-Creator-Request-Paket an den Er-zeuger-Endpunkt. Wenn der Erzeugerknoten nach einigen Ver-suchen keine Group-Creator-Confirm-Pakete empfängt, wirddie Gruppe gelöscht. Netzwerk-Routentabellen werden aufdem neuesten Stand gehalten, indem Knoten bei Routenände-rungen Distance-Vector-Pakete an ihre direkt benachbartenKnoten schicken. Damit wird es Knoten ermöglicht, das Rou-


ting von Multicast-Gruppen aufgrund von Änderungen in derTopologie zu ändern.

43.3 SMRP – Beispiel für eine Transaktion

Zu einer typischen Transaktionssitzung unter SMRP gehörtein die Gruppe erzeugender Macintosh-Arbeitsplatz, weiteresich der Gruppe anschließende Macintosh-Arbeitsplätze sowieDaten, die an die Gruppenmitglieder verschickt werden.

In einer typischen SMRP-Transaktionssitzung verschickt einMacintosch (nennen wir dieses System Erzeuger-Mac) zuerstein Create-Group-Request an alle Knoten in einem bestimm-ten Netzwerk. Der primäre Router für das lokale Netzwerkweist eine nicht verwendete Gruppenadresse zu und liefertdiese Adresse an den Erzeuger-Mac zurück. Ein Macintosh ineinem entfernten Netzwerk (nennen wir ihn Mitglieder-Mac)entdeckt den Erzeuger-Mac über das Name Binding Protocol(NBP).

Der Erzeuger-Mac antwortet dann mittels eines NBP-Re-sponse mit der Gruppenadresse. Der Mitglieder-Mac schicktein Join-Group-Request an alle Knoten. Ein entfernter Router(nennen wir ihn Router M) mit einer gültigen Route zu derGruppe und einem richtigen Urheberanschluß schickt ein Join-Group-Request an den primären Router.

Der primäre Router empfängt schließlich das Join-Group-Request und schickt es an den Erzeuger-Mac. Er fügt derGruppe in der Weiterleitungstabelle außerdem den ankom-menden Anschluß hinzu. Der Erzeuger-Mac bestätigt das Join-Group-Request und schickt Daten an die Gruppe. Der primäreRouter erhält die Daten und leitet sie an die Tochteranschlüsseder Gruppe weiter.

Schließlich gelangen die Daten zu Router M, der die Gruppein der Weiterleitungstabelle nachschlägt und die Multicast-Daten weiterleitet. Der Mitglieder-Mac empfängt daraufhinfür die Gruppe bestimmte Daten.


43.4 SMRP – Paketformat

Im Bild 43.2 ist das allgemeine Paketformat für SMRP darge-stellt.

Sequenz-nummer

Protokoll-version

Gruppen-adresse DatenTyp

Feldlänge in Byte

11 2 4 variabel

Die Felder des im Bild 43.2 dargestellten Paketformats fürSMRP werden im folgenden kurz beschrieben:

− Protokoll-Version – Zeigt die Version von SMRP an.

− Typ – Besteht aus zwei Teilfeldern. Die ersten 2 Bit modifi-zieren den von den hinteren 6 Bit angegebenen Pakettyp,um feststellen zu können, ob es sich bei einem Paket um einTransaktionspaket handelt und gegebenenfalls, um welcheArt von Transaktion es sich handelt.

− Sequenznummer – Ordnet in Transaktionen Response- undRequest-Pakete einander zu, um doppelte Requests undResponses zu vermeiden. Alle Pakettypen sind Transak-tionspakete und tragen eine Sequenznummer ungleich Null(mit Ausnahme von Multicast-Datenpaketen und Hello-Paketen, deren Sequenznummern auf Null gesetzt sind).

− Gruppenadresse – Dient als designierter Primärknoten undweist allen Multicast-Quellen im lokalen Netzwerk Grup-penadressen zu. Einem lokalen Netzwerk können mehrereNetzwerk-Nummern zugewiesen werden, die aber in einemfortlaufenden Bereich liegen müssen. Knoten müssen Netz-werk-Nummern derart konfigurieren, daß sie für jedes lo-kale Netzwerk und jeden Primärknoten eindeutig sind, umKonflikte mit Multicast-Adressen zu verhindern. Wenn einPrimärknoten eine neue Gruppenadresse zuweist, weist erder Netzwerk-Nummer willkürlich eine unbenutzte Grup-penadresse zu.

Bild 43.2:Ein allgemeines

SMRP-Paketsetzt sich ausfünf Feldern

zusammen


− Daten – Variiert in Abhängigkeit vom SMRP-Pakettyp. InTabelle 43.2 sind die Eigenschaften der auf den Pakettypenbasierenden Daten zusammengefaßt.

Pakettyp Übertragene Daten Größe

Multicast-Data Daten Variabel, abhängigvon der Datagramm-größe der Netzwerk-Schicht

Hello Anschlußzustand 2 ByteNotify Anschlußzustand 1 ByteDesignated Node Keine 0 ByteDistance-Vector Multicast-Vektor 8 ByteCreate Group Keine 0 ByteDelete Group Keine 0 ByteJoin Group Keine 0 ByteAdd Group Entry Unicast-Adresse einer

Netzwerk-SchichtVariabel, abhängigvom Adreßformat derNetzwerk-Schicht

Remove Group Entry Keine 0 ByteLeave Group Keine 0 ByteCreator Request Keine 0 ByteMember Request Keine 0 ByteReject Fehlerkennzeichnung Short Integer im

Bereich von –7700 bis–7710; abhängig vomFehler

Tabelle 43.2:Auf PakettypenbasierendeEigenschaftenvon Daten

Kapitel 44: IBM NetzwerkverwaltungKapitel 45: Remote Monitoring (RMON)Kapitel 46: Simple Network Management Protocol (SNMP)

Teil 7: Netzwerk-Verwaltung

Der Teil 7, »Netzwerk-Verwaltung«, umreißt die Funktionen,die von verschiedenen, weit verbreiteten Umgebungen zurNetzwerk-Verwaltung bereitgestellt werden. In jeweils eigenenKapiteln wird auf folgende Themen eingegangen:

IBM-Netzwerk-Verwaltung – Behandelt die Grundlagen derIBM-Netzwerk-Verwaltung für SNA und APPN.

Remote Monitoring (RMON) – Behandelt die Eigenschaftenund Funktionen dieser standardisierten Überwachungsspezifi-kation.

Simple Network Management Protocol (SNMP) – BehandeltSNMP, das weit verbreitete Internet-Protokoll zur Netzwerk-Verwaltung.

TEIL 7Netzwerk-Verwaltung

44 IBM Netzwerk-Verwaltung

44.1 Hintergrund

Die IBM-Netzwerk-Verwaltung bezieht sich auf jede Architek-tur, die für die Verwaltung von Netzwerken unter der IBM Sy-stems Network Architecture (SNA) oder dem Advanced Peer-to-Peer Networking (APPN) zum Einsatz kommt. Die IBM-Netzwerk-Verwaltung ist Teil der IBM Open-Network Archi-tecture (ONA) und wird hauptsächlich unter Einsatz vonVerwaltungsplattformen wie beispielsweise NetView durchge-führt. Sie unterteilt sich in fünf Funktionen, die den im Open-System-Interconnection-Modell (OSI) angegebenen Funktio-nen zur Netzwerk-Verwaltung ähneln. In diesem Kapitel erfol-gen kurze Beschreibungen der funktionalen Bereiche bei derIBM-Netzwerk-Verwaltung, der Netzwerk-Verwaltungsarchi-tektur ONA und von Verwaltungsplattformen. Im Bild 44.1ist ein einfaches verwaltetes IBM-Netzwerk dargestellt.

KAPITEL 44IBM-Netzwerk-Verwaltung


44.2 IBM – Funktionale Bereiche derNetzwerk-Verwaltung

IBM unterteilt die Netzwerk-Verwaltung in folgende fünf be-nutzerorientierte Aufgabenbereiche: Konfigurationsverwal-tung, Performance- und Accounting-Verwaltung, Problemver-waltung, Betriebsverwaltung und Änderungsverwaltung.

44.2.1 IBM – Konfigurationsverwaltung

Die Konfigurationsverwaltung (Configuration Management)von IBM überwacht Informationen, welche die physikalischenund logischen Eigenschaften von Netzwerk-Ressourcen sowiedie Beziehungen dieser Ressourcen untereinander beschreiben.Ein zentrales Verwaltungssystem speichert Daten in einer Da-tenbank zur Konfigurationsverwaltung und kann Informatio-nen wie beispielsweise Versionsnummern der Systemsoftwareoder des Microcode, Seriennummern von Hard- oder Soft-ware, physikalische Aufenthaltsorte von Geräten sowie Na-men, Adressen und Telefonnummern für Kontakte enthalten.Wie zu erwarten entspricht die Konfigurationsverwaltung vonIBM nahezu der OSI-Konfigurationsverwaltung.

Die Möglichkeiten der Konfigurationsverwaltung helfen beider Pflege einer Bestandsliste für die Netzwerk-Ressourcenund bei der Sicherstellung, daß sich Änderungen an der Netz-werk-Konfiguration in der Datenbank für die Netzwerk-Ver-waltung wiederfinden. Die Konfigurationsverwaltung stelltweiterhin Informationen bereit, die von den Systemen zur Pro-

Bild 44.1:Die IBM

Netzwerk-Verwaltung

geht mit SNA- oder

APPN-Netz-werken um

Kapitel 44 • IBM Netzwerk-Verwaltung 559

blemverwaltung und zur Änderungsverwaltung aufgegriffenwerden. Systeme zur Problemverwaltung verwenden dieseInformationen, um Versionsunterschiede zu vergleichen undum die Eigenschaften von Netzwerk-Ressourcen ausfindig zumachen, zu identifizieren und zu überprüfen. Systeme zurÄnderungsverwaltung verwenden diese Informationen, um dieAuswirkungen von Änderungen zu analysieren und um Ände-rungen in Zeiten minimaler Netzwerk-Belastung einzuplanen.

44.2.2 IBM – Performance- und Accounting-Verwaltung

Die Performance- und Accounting-Verwaltung von IBM stelltInformationen über die Leistungsdaten der Netzwerk-Ressour-cen bereit. Zu den Aufgaben der Performance- und Accoun-ting-Verwaltung gehören die Überwachung der Antwortzeitenvon Systemen, das Messen der Verfügbarkeit von Ressourcen,das Messen des Einsatzes von Ressourcen sowie das Optimie-ren, Verfolgen und Steuern der Netzwerk-Performance. Diedabei gesammelten Informationen sind hilfreich, um festzu-stellen, ob Ziele für die Netzwerk-Performance erreicht wur-den und ob aufgrund der Leistung Verfahren zur Ermittlungvon Schwachstellen eingeleitet werden sollten. Die Perfor-mance- und Accounting-Verwaltung von IBM erfüllt Aufga-ben, die denen der OSI-Performance-Verwaltung und der OSI-Accounting-Verwaltung ähneln.

44.2.3 IBM – Problemverwaltung

Die Problemverwaltung (Problem Management) von IBM äh-nelt der OSI-Fehlerverwaltung darin, daß sie Fehlerbedingun-gen behandelt, die für einen Benutzer zum Verlust der vollenFunktionalität einer Netzwerk-Ressource führen. Die Pro-blemverwaltung erfolgt in fünf Schritten: Problemermittlung,Problemdiagnose, Problemumgehung und -wiederherstellung,Problemlösung sowie Problemverfolgung und -kontrolle. DieProblemermittlung besteht im Entdecken eines Problems unddem Beenden der notwendigen Schritte (beispielsweise dasEingrenzen des Problems auf ein bestimmtes Teilsystem), ummit der Problemdiagnose beginnen zu können. Die Problem-diagnose besteht darin, die genaue Ursache des Problems unddie zu dessen Lösung benötigte Handlung zu ermitteln. Die


Problemumgehung und -wiederherstellung besteht aus Versu-chen, das Problem entweder teilweise oder vollständig zu um-gehen. Sie sorgt lediglich für eine vorübergehende Lösung undvertraut auf eine Problemlösung, die das Problem dauerhaftlöst. Die Problemlösung besteht aus Unternehmungen, dasProblem zu beseitigen. Sie beginnt üblicherweise nach der Be-endigung der Problemdiagnose und umfaßt häufig korrigie-rende Handlungen wie beispielsweise das Ersetzen von fehler-hafter Hard- oder Software. Die Problemverfolgung und -kon-trolle schließlich besteht aus der Verfolgung des Problems, biseine endgültige Lösung gefunden ist. Wichtige, das Problembeschreibende Informationen werden in einer Problemdaten-bank gespeichert.

44.2.4 IBM – Betriebsverwaltung

Die Betriebsverwaltung (Operations Management) von IBMbesteht aus der Verwaltung verteilter Netzwerk-Ressourcenvon einer zentralen Stelle aus, wobei zwei Arten von Funktio-nen eingesetzt werden: betriebsverwaltende Dienste und allge-meine Betriebsdienste. Betriebsverwaltende Dienste besitzendie Fähigkeit, entfernte Ressourcen mittels folgender Funktio-nen zentral zu kontrollieren: Ressourcenaktivierung und -de-aktivierung, Befehlsstreichung und Zeiteinstellung. Betriebs-verwaltende Dienste können automatisch als Reaktion auf be-stimmte Meldungen zu Systemproblemen eingeleitet werden.

Allgemeine Betriebsdienste ermöglichen die Verwaltung vonnicht explizit durch andere Verwaltungsbereiche angesproche-nen Ressourcen, wobei eine besondere Kommunikation durchneue, leistungsfähigere Anwendungen verwendet wird. Dieallgemeinen Betriebsdienste stellen zwei wichtige Dienste zurVerfügung: den Ausführungsbefehl und den Dienst zur Res-sourcenverwaltung. Der Ausführungsbefehl stellt ein standar-disiertes Mittel zum Ausführen entfernter Befehle dar. DerDienst zur Ressourcenverwaltung sorgt für eine Möglichkeit,Informationen in einer vom Kontext unabhängigen Weise zutransportieren.

44.2.5 IBM – Änderungsverwaltung

Die Änderungsverwaltung verfolgt Netzwerk-Änderungen undpflegt Änderungsdateien auf entfernten Knoten. Netzwerk-


Änderungen treten hauptsächlich aus zwei Gründen auf: sichändernde Anwenderbedürfnisse und das Umgehen von Proble-men. Zu den sich ändernden Anwenderbedürfnissen gehörendie Aktualisierung von Hard- und Software, neue Anwendun-gen und Dienste sowie weitere Faktoren, die ständig die Be-dürfnisse von Netzwerk-Benutzern verändern. Das Umgehenvon Problemen ist notwendig, um unerwartete Änderungenhandhaben zu können, die aus dem Ausfall von Hardware,Software oder anderen Netzwerk-Komponenten resultieren.Die Änderungsverwaltung versucht, Probleme zu minimieren,indem sie ein geordnetes Vorgehen bei Netzwerk-Änderungenfördert und Änderungsdateien verwaltet, die Netzwerk-Ände-rungen protokollieren.

44.3 IBM-Architekturen zur Netzwerk-Verwaltung

Zwei der bekanntesten Architekturen zur Netzwerk-Verwal-tung von IBM sind die Open Network Architecture (ONA)und SystemView.

44.3.1 Open Network Architecture (ONA)

Bei der Open Network Architecture (ONA) handelt es sich umeine allgemeine Architektur zur Netzwerk-Verwaltung, die vierwesentliche Verwaltungseinheiten definiert: Brennpunkt,Sammlungspunkt, Eintrittspunkt und Dienstpunkt.

Der Brennpunkt (Focal Point) ist eine Verwaltungseinheit, dieden Betrieb einer zentralisierten Netzwerk-Verwaltung unter-stützt. Er reagiert auf Alarmmeldungen von Endrechnern,pflegt Verwaltungsdatenbanken und stellt eine Benutzer-schnittstelle für den Netzwerk-Verwalter bereit. Es gibt dreiArten von Brennpunkten: primäre, sekundäre und verschach-telte. Der primäre Brennpunkt führt sämtliche Aufgaben einesBrennpunkts durch. Der sekundäre Brennpunkt dient als Re-serve für primäre Brennpunkte und wird eingesetzt, falls einprimärer Brennpunkt ausfällt. Der verschachtelte Brennpunktsorgt in umfangreichen Netzwerken für die Unterstützungeiner verteilten Verwaltung. Verschachtelte Brennpunkte sindfür die Weiterleitung wesentlicher Informationen an umfas-sendere Brennpunkte zuständig.


Sammelpunkte (Collection Points) tragen Informationen vonselbstenthaltenen SNA-Teilnetzwerken an Brennpunkte weiter.Üblicherweise werden sie eingesetzt, um Daten von IBM-Peer-to-Peer-Netzwerken in die ONA-Hierarchie weiterzuleiten.

Bei einem Eintrittspunkt (Entry Point) handelt es sich um einSNA-Gerät, das ONA für sich selber und andere Geräte im-plementieren kann. Die meisten standardmäßigen SNA-Gerätesind als Eintrittspunkte geeignet.

Bei einem Dienstpunkt (Service Point) handelt es sich um einSystem, das Nicht-SNA-Geräten den Zugriff auf ONA ermög-licht und das im wesentlichen ein Gateway zu ONA darstellt.Dienstpunkte sind dazu in der Lage, Brennpunkte mit Verwal-tungsinformationen über Nicht-SNA-Geräte zu versorgen, Be-fehle von Brennpunkten zu empfangen, Befehle in ein fürNicht-SNA-Geräte verständliches Format zu übersetzen sowieBefehle zur Ausführung an Nicht-SNA-Geräte weiterzuleiten.

Im Bild 44.2 sind die Beziehungen der verschiedenen Verwal-tungseinheiten von ONA zueinander dargestellt.

Dienst-punkt

Eintritts-punkt

Sammel-punkt

Eintritts-punkt

primärerBrennpunkt

sekundärerBrennpunkt

verschachtelterBrennpunkt

verschachtelterBrennpunkt

Dienst-punkt

Bild 44.2:Die vier Arten

von Brenn-punkten sindinnerhalb derONA-Umge-

bung mit-einander

verbunden


44.3.2 SystemView

SystemView stellt eine Entwurfsvorlage für das Erstellen vonverwaltenden Anwendungen dar, die in der Lage sind, Infor-mationssysteme für viele Anbieter zu verwalten. SystemViewbeschreibt, wie heterogene Netzwerke verwaltende Anwen-dungen mit anderen Verwaltungssystemen umgehen. Es han-delt sich hierbei um die offizielle Systemverwaltungsstrategieder IBM Systems Application Architecture (SAA).

44.4 IBM – Plattformen zur Netzwerk-Verwaltung

Die Netzwerk-Verwaltung von IBM ist auf mehreren Plattfor-men implementiert. Zu diesen gehören: NetView, LAN Net-work Manager (LAN) und Simple Network Management Pro-tocol (SNMP).

44.4.1 NetView

Bei NetView handelt es sich um eine umfassende IBM-Enter-prise-Netzwerk-Verwaltungsplattform, die zentralisierte SNANetzwerk-Verwaltungsdienste zur Verfügung stellt. Sie wirdauf IBM Mainframes eingesetzt und ist ein Bestandteil derONA. NetView setzt sich aus der Einrichtung zur Befehls-kontrolle, Hardware-Monitor, Session-Monitor, Hilfefunk-tion, Status-Monitor, Performance-Monitor und Distribution-Manager zusammen. Die Einrichtung zur Befehlskontrolle bie-tet die Möglichkeit zur Netzwerk-Kontrolle, indem grund-legende Befehle für den Verwalter und den Dateizugriff anAnwendungen, Controller, Betriebssysteme und NetView/PC(eine Schnittstelle zwischen NetView und Nicht-SNA-Geräten)aufgerufen werden, die auf der Virtual TelecommunicationsAccess Method (VTAM) aufbauen. Der Hardware-Monitorüberwacht das Netzwerk und warnt den Netzwerk-Verwalterbei Auftreten eines Hardware-Fehlers automatisch. DerSession-Monitor fungiert als VTAM-Performance-Monitorund sorgt für die Ermittlung von Software-Problemen und fürdie Konfigurationsverwaltung. Die Hilfefunktion dient Net-View-Benutzern als Hilfe und besteht aus einer Möglichkeitzum Blättern, einem Help-Desk und einer Bibliothek üblicher-weise auftretender Betriebssituationen eines Netzwerks. Der


Status-Monitor faßt die Statusinformationen des Netzwerkszusammen und stellt sie dar. Der Performance-Monitor über-wacht die Leistungsdaten der Frontend-Prozessoren (FEDs),des Network Control Program (NCP) und weiterer zuge-höriger Ressourcen. Der Distribution-Manager plant und ver-folgt die Verteilung von Daten, Software und Microcode inSNA-Umgebungen.

44.4.2 LAN Network Manager (LNM)

Beim LAN Network Manager (LNM) handelt es sich um eineIBM-Anwendung zur Netzwerk-Verwaltung, die Token-Ring-LANs von einer zentralen Stelle aus steuert. LNM ist ein Pro-dukt, das auf der OS/2 Extended Edition basiert und mit IBMNetView (das auf solche LNM-Aktivitäten wie beispielsweiseAlarmmeldungen achtet) sowie anderer Verwaltungssoftwarevon IBM zusammenarbeitet.

44.4.3 Simple Network Management Protocol (SNMP)

Die Netzwerk-Verwaltung von IBM kann mittels SNMP im-plementiert werden. In Kapitel 46, »Simple Network Mana-gement Protocol (SNMP)«, finden Sie nähere Informationenzur Implementierung von SNMP.

45 Remote Monitoring (RMON)

45.1 Hintergrund

Beim Remote Monitoring (RMON) handelt es sich um eineallgemeine Überwachungsspezifikation, die es verschiedenarti-gen Netzwerk-Monitoren und Konsolensystemen ermöglicht,Daten der Netzwerk-Überwachung auszutauschen. RMONversieht Netzwerk-Administratoren mit größeren Freiheitenbei der Auswahl von Meßsonden und Konsolen für die Netz-werk-Überwachungen mit zu ihren besonderen Netzwerk-Bedürfnissen passenden Eigenschaften. Dieses Kapitel lieferteinen kurzen Überblick über die RMON-Spezifikation, wobeidie RMON-Gruppen im Mittelpunkt stehen.

Die RMON-Spezifikation definiert eine Reihe von statisti-schen Werten und Funktionen, die RMON-gemäße Konsolen-Manager und Netzwerk-Meßsonden untereinander austau-schen können. Damit versorgt RMON Netzwerk-Administra-toren mit umfassenden Informationen für die Fehlerdiagnose,Planung und Leistungsoptimierung von Netzwerken.

RMON wurde von der Anwenderschaft mit Unterstützungdurch die Internet Engineering Task Force (IETF) definiert undwurde 1992 in Form der RFC 1271 (für Ethernet) als Stan-dard vorgeschlagen. Daraufhin wurde RMON 1995 in Formder RFC 1757 zum Standard im Entwurfsstadium erklärt,wodurch die RFC 1272 letztendlich überflüssig wurde.

KAPITEL 45Remote Monitoring (RMON)


Im Bild 45.1 ist eine RMON-Meßsonde dargestellt, die dazu inder Lage ist, ein Ethernet-Segment zu überwachen und statisti-sche Werte an eine RMON-gemäße Konsole zu übertragen.

RMON-gemäßerKonsolen-Manager

RMON-Meßsonde

45.2 RMON-Gruppen

RMON überbringt Informationen in neun aus Überwachungs-elementen bestehenden RMON-Gruppen, von denen jede für be-stimmte Arten von Daten sorgt, um allgemeine Bedingungen derNetzwerk-Überwachung zu erfüllen. Jede der Gruppen ist optio-nal, so daß Anbieter nicht alle Gruppen in der Management In-formation Base (MIB) zu unterstützen brauchen. In der Tabelle45.1 sind die neun in der RFC 1757 für Ethernet RMON MIB an-gegebenen Überwachungsgruppen zusammengestellt.

RMON-Gruppe

Funktion Elemente

Statistics Enthält statistische Werte, dievon der Meßsonde für jede über-wachte Schnittstelle dieses Gerätsgemessen werden.

Gelöschte Pakete,gesendete Pakete,gesendete Bytes(Oktett), Broad-cast-Pakete, Multi-cast-Pakete, CRC-Fehler, Runts,Giants, Fragmente,Jabbers, Konfliktesowie Zähler fürPakete, die 64–128,128–256, 256–512,512–1024 und1024–1518 Byteumfassen.

Bild 45.1:Eine RMON-

Meßsondekann statisti-

sche Werte aneine RMON-

Konsoleschicken

Tabelle 45.1:Überwachungs-

gruppen vonRMON

Kapitel 45 • Remote Monitoring (RMON) 567

RMON-Gruppe

Funktion Elemente

History Zeichnet regelmäßige statistischeMessungen in einem Netzwerkauf und speichert sie für die spä-tere Verwendung.

Meßzeitraum, An-zahl der Messun-gen, gemessene(s)Element(e).

Alarm Entnimmt Variablen der Meß-sonde regelmäßig statistischeMeßwerte und vergleicht sie mitzuvor konfigurierten Schwellen-werten. Falls die überwachte Va-riable einen Schwellenwert über-steigt, wird ein Event generiert.

Umfaßt die Alarm-Tabelle und erfor-dert die Implemen-tierung der Event-Gruppe. Alarmtyp,Intervall, Anfangs-schwelle, End-schwelle.

Host Enthält mit jedem im Netzwerkvorkommenden Host verbundenestatistische Werte.

Host-Adresse,empfangene undübertragene Paketeund Bytes sowieBroadcast-, Multi-cast- und Fehler-Pakete.

HostTopN Bereitet Tabellen vor, die diejeni-gen Hosts beschreiben, die einenach einem ihrer statistischenWerte sortierte Auflistung anfüh-ren. Bei den statistischen Wertenhandelt es sich um Messungeneines ihrer grundlegenden Erfas-sungswerte über einen vom ver-waltenden Rechner vorgegebenenZeitraum. Somit handelt es sichum ratenorientierte statistischeWerte

Statistische Werte,Host(s), Anfangs-und Endpunkteiner Messung,Ratengrundlage,Dauer.

Matrix Speichert statistische Werte fürKonversationen zwischen Paarenzweier Adressen. Sobald das Ge-rät eine neue Konversation fest-stellt, erzeugt es einen neuen Ein-trag in seiner Tabelle.

Adressenpaare fürQuelle und Zielsowie Pakete, Bytesund Fehler für jedesPaar.

Tabelle 45.1:Überwachungs-gruppen vonRMON


RMON-Gruppe

Funktion Elemente

Filters Ermöglicht das Überprüfen vonPaketen gemäß einer Filterglei-chung. Diese passenden Paketebilden einen Datenstrom, dererfaßt werden kann oder Eventserzeugen kann.

Bit-Filtertyp (mas-kiert oder nichtmaskiert), Filter-ausdruck (Bit-Ebene), Bedin-gungsausdruck(und, oder, nicht) inbezug auf andereFilter.

PacketCapture

Ermöglicht das Erfassen vonPaketen, nachdem sie über einenKanal geflossen sind.

Größe des Zwi-schenspeichers fürerfaßte Pakete,Füllstand (Alarm),Anzahl erfaßterPakete.

Events Steuert die Erzeugung und Mit-teilung von Ereignissen diesesGeräts.

Ereignistyp,Beschreibung,Zeitpunkt derletzten Ereignis-versendung.

Tabelle 45.1:Überwachungs-

gruppen vonRMON

KAPITEL 46Simple Network Management Protocol (SNMP)

46 Simple Network Management Protocol (SNMP)

46.1 Hintergrund

Beim Simple Network Management Protocol (SNMP) handeltes sich um ein Protokoll für die Anwendungsschicht, das denAustausch von Verwaltungsinformationen zwischen Netz-werk-Geräten erleichtert. Es ist ein Bestandteil der Protokoll-sammlung Transmission Control Protocol/Internet Protocol(TCP/IP). SNMP gestattet es Netzwerk-Administratoren, dieNetzwerk-Performance zu verwalten, Netzwerk-Probleme auf-zuspüren und zu lösen und das Wachstum des Netzwerks zuplanen.

Es gibt zwei Versionen von SNMP: SNMP Version 1(SNMPv1) und SNMP Version 2 (SNMPv2). Beide Versionenverfügen über einige gemeinsame Eigenschaften, SNMPv2 bie-tet allerdings auch einige Erweiterungen wie beispielsweise zu-sätzliche Protokolloperationen. Die Standardisierung einerweiteren Version von SNMP – SNMP Version 3 (SNMPv3) –ist anhängig. Dieses Kapitel beschreibt die Protokolloperatio-nen von SNMPv1 und SNMPv2. Im Bild 46.1 ist ein einfachesmit SNMP verwaltetes Netzwerk dargestellt.


46.2 SNMP – Grundlegende Komponenten

Ein mit SNMP verwaltetes Netzwerk setzt sich aus drei we-sentlichen Komponenten zusammen: verwaltete Geräte, Agen-ten und Netzwerk-Verwaltungssysteme (Network Manage-ment Systems = NMSs).

Bei einem verwalteten Gerät handelt es sich um einen Netz-werk-Knoten, der über einen SNMP-Agenten verfügt und dersich in einem verwalteten Netzwerk befindet. Verwaltete Ge-räte sammeln und speichern Verwaltungsinformationen undstellen diese Informationen mittels SNMP den NMSs zur Ver-fügung. Bei verwalteten Geräten, die manchmal auch alsNetzwerk-Elemente bezeichnet werden, kann es sich umRouter und Zugriffsserver, Switches und Bridges, Hubs,Hostcomputer oder Drucker handeln.

Bei einem Agenten handelt es sich um ein netzwerkverwalten-des Software-Modul, das sich auf einem verwalteten Gerät be-findet. Ein Agent verfügt über lokales Wissen von Verwal-tungsinformationen und übersetzt diese Informationen in eineForm, die zu SNMP kompatibel ist.

Ein NMS führt Anwendungen aus, die verwaltete Geräteüberwachen und steuern. NMSs stellen den Großteil der fürdie Netzwerk-Verwaltung erforderlichen Bearbeitungs- undSpeicherressourcen bereit. In jedem verwalteten Netzwerkmüssen ein oder mehrere NMSs vorhanden sein.

Im Bild 46.2 sind die Beziehungen zwischen diesen drei Kom-ponenten dargestellt.

Bild 46.1:SNMP ermög-licht den Aus-

tausch vonNetzwerk-

InformationenzwischenGeräten

Kapitel 46 • Simple Network Management Protocol (SNMP) 571

Verwaltungs-einheit

Agent

Verwaltungs-datenbank

Agent

NMS


verwaltete Geräte

Agent


46.3 SNMP – Grundlegende Befehle

Verwaltete Geräte werden mittels folgender vier grundlegen-den Befehle von SNMP überwacht und gesteuert: Read, Write,Trap und Traversal-Operationen.

Der Befehl Read wird von einem NMS verwendet, um verwal-tete Geräte zu überwachen. Das NMS untersucht verschiedeneVariablen, die von verwalteten Geräten vorgehalten werden.

Der Befehl Write wird von einem NMS verwendet, um verwal-tete Geräte zu steuern. Das NMS ändert die Werte von in ver-walteten Geräten gespeicherten Variablen.

Der Befehl Trap wird von verwalteten Geräten verwendet, umdem NMS asynchron Ereignisse mitzuteilen. Beim Auftretenbestimmter Arten von Ereignissen schickt ein verwaltetes Ge-rät einen Trap an das NMS.

Traversal-Operationen werden vom NMS verwendet, um zuermitteln, welche Variablen ein verwaltetes Gerät unterstütztund um der Reihe nach Informationen in Variablentabellenwie beispielsweise einer Routing-Tabelle zu sammeln.

Bild 46.2:Ein per SNMPverwaltetesNetzwerk setztsich aus ver-walteten Gerä-ten, Agentenund NMSszusammen


46.4 SNMP – Management Information Base(MIB)

Eine Management Information Base (MIB) ist eine Sammlungvon hierarchisch organisierten Informationen. Auf MIBs wirdmittels eines Protokolls zur Netzwerk-Verwaltung wie bei-spielsweise SNMP zugegriffen. Sie setzen sich aus verwaltetenObjekten zusammen und werden durch Objekt-IDs identifi-ziert.

Ein verwaltetes Objekt (manchmal auch als MIB-Objekt, Ob-jekt oder MIB bezeichnet) stellt eine von einer beliebigen An-zahl von Eigenschaften eines verwalteten Geräts dar. Verwal-tete Objekte bestehen aus einer oder mehreren Objektinstan-zen, bei denen es sich im wesentlichen um Variablen handelt.

Es gibt zwei Arten verwalteter Objekte: skalare und tabellari-sche. Skalare Objekte definieren eine einzige Objektinstanz.Tabellarische Objekte definieren mehrere zusammengehörigeObjektinstanzen, die in MIB-Tabellen zusammen gruppiertsind.

Ein Beispiel für ein verwaltetes Objekt ist atInput, bei dem essich um ein skalares Objekt handelt, das als einzige Objektin-stanz den ganzzahligen Wert enthält, der die Gesamtzahl deran einer Router-Schnittstelle eingegebenen AppleTalk-Paketeangibt.

Eine Objekt-ID weist ein verwaltetes Objekt in der MIB-Hier-archie eindeutig aus. Die MIB-Hierarchie kann als ein Baummit namenloser Wurzel betrachtet werden, dessen Ebenen vonunterschiedlichen Organisationen zugewiesen werden. Im Bild46.3 ist der MIB-Baum dargestellt.

Die Objekt-IDs der obersten MIB-Ebene gehören zu unter-schiedlichen Standardisierungsorganisationen, wohingegen dieObjekt-IDs der untergeordneten Ebenen von angeschlossenenOrganisationen belegt werden.

Anbieter können eigene Zweige definieren, die verwalteteObjekte für ihre eigenen Produkte enthalten. MIBs, die nichtstandardisiert wurden, befinden sich üblicherweise im Zweigexperimental.


ccitt (0)

…

…… …

iso (1) iso-ccitt (2)

registration-authority (1)

standard (0)

dod (6)…

member-body (2)

identified-organization (3)

mgmt (2)directory (1) experimental (3) private (4) security (5) snmpV2 (6)

internet (1)…

mib-2 (1) enterprise (1)

cisco (9)… …

…… …

…

…… temporary variables (3)

… … …

Apple Talk (3)

atForward (4)

Novell (3) VINES (4) Chassis (5)DECnet (1) XNS (2)

……

……

…

atBcastin (3)

atLocal (2)

atInput (1)……

……

……

Das verwaltete Objekt atInput kann entweder durch die Objekt-bezeichnung iso.identified-organization.dod.internet. private.enterprise.cisco.temporary variables.AppleTalk.atInput oderdurch den entsprechenden Objektdeskriptor 1.2.6.1.4.1.9.3.3.1eindeutig identifiziert werden.

46.5 SNMP und Datendarstellung

SNMP muß Inkompatibilitäten zwischen verwalteten Gerätenerklären und diese ausgleichen. Verschiedene Computer ver-wenden verschiedene Techniken zur Datendarstellung, wo-durch es zu Zugeständnissen für die Fähigkeit von SNMP zumInformationsaustausch zwischen verwalteten Geräten kom-men kann. SNMP setzt eine Teilmenge der Abstract SyntaxNotation One (ASN.1) ein, um sich auf die Kommunikationzwischen unterschiedlichen Systemen einzustellen.

Bild 46.3:Der MIB-Baum stellt dieverschiedenenHierarchiendar, die von un-terschiedlichenOrganisationenzugewiesenwurden


46.6 SNMP Version 1 (SNMPv1)

SNMP Version 1 (SNMPv1) ist die erste Implementierung desProtokolls SNMP. Es ist im Request For Comments (RFC)1157 beschrieben und funktioniert innerhalb der Spezifikatio-nen für die Structure of Management Information (SMI).SNMPv1 arbeitet mit Protokollen wie beispielsweise dem UserDatagram Protocol (UDP), Internet Protocol (IP), OSI Co-nectionless Network Service (CLNS), AppleTalk DatagramDelivery Protocol (DDP) und Novell Internet Paket Exchange(IPX). SNMPv1 wird häufig eingesetzt und stellt das Stan-dardprotokoll für die Netzwerk-Verwaltung im Internet dar.

46.6.1 SNMPv1 und Structure of ManagementInformation (SMI)

Die Structure of Management Information (SMI) definiert dieRegeln für das Beschreiben von Verwaltungsinformationenmittels der Abstract Syntax Notation One (ASN.1). Die SMIvon SNMPv1 ist in dem RFC 1155 definiert. Sie sorgt für dreiSchlüsselspezifikationen: ASN.1-Datentypen, SMI-spezifischeDatentypen und MIB-Tabellen von SNMP.

SNMPv1 und ASN.1-Datentypen

Die SMI von SNMPv1 gibt an, daß mit allen verwalteten Ob-jekten eine bestimmte Teilmenge von ASN.1-Datentypen ver-bunden ist. Drei ASN.1-Datentypen werden benötigt: Name,Syntax und Encoding. Der Name dient als Objekt-ID. DieSyntax definiert den Datentyp des Objekts (beispielsweiseGanzzahl oder Zeichenkette). Die SMI setzt eine Teilmenge fürASN.1-Syntaxdefinitionen ein. Die Encoding-Daten beschrei-ben, auf welche Weise mit einem verwalteten Objekt verbun-dene Informationen für die Übertragung über das Netzwerkals eine Reihe von Dateneinträgen formatiert werden.

SNMPv1 und SMI-spezifische Datentypen

Die SMI von SNMPv1 beschreibt den Einsatz einiger SMI-spezifischer Datentypen, die in zwei Kategorien eingeteilt wer-den: einfache Datentypen und anwendungsweite Datentypen.


Es werden drei einfache Datentypen in der SMI von SNMPv1definiert, die alle eindeutige Werte darstellen: Integers, OctetStrings und Object-IDs. Bei den Integern handelt es sichum vorzeichenbehaftete Ganzzahlen im Bereich von–2.147.483.648 bis 2.147.483.647. Bei den Octet Strings han-delt es sich um sortierte Abfolgen von null bis 65.535 Oktet-ten. Object-IDs stammen aus der Menge sämtlicher entspre-chend den ASN.1-Regeln erteilter Objekt-IDs.

In der SMI von SNMPv1 gibt es sieben anwendungsweite Da-tentypen: Network Addresses, Counter, Gauges, Time Ticks,Opaques, Integers und Unsigned Integers. Netzwerk-Adressenstehen für eine Adresse einer bestimmten Protokollfamilie.SNMPv1 unterstützt nur 32-Bit-IP-Adressen. Counter sindpositive Ganzzahlen, die erhöht werden, bis sie einen Maxi-malwert erreichen und dann wieder bei Null beginnen. InSNMPv1 sind 32 Bit für die Zählergröße vorgesehen. Gaugessind positive Ganzzahlen, die erhöht oder verringert werdenkönnen, aber den erreichten Maximalwert beibehalten. EinTime Tick steht für die Hundertstelsekunden nach irgendei-nem Ereignis. Ein Opaque steht für eine beliebige Kodierung,die für die Übergabe beliebiger Informationszeichenkettenverwendet wird, die nicht der von der SMI benutzten genauenDatentypisierung entsprechen. Ein Integer stellt Informationenmit vorzeichenbehafteten ganzzahligen Werten dar. Dieser Da-tentyp definiert den Datentyp Integer neu, der unter ASN.1über eine beliebige, unter SMI aber über eine begrenzte Ge-nauigkeit verfügt. Ein Unsigned Integer stellt Informationenmit vorzeichenlosen ganzzahligen Werten dar und ist nützlich,wenn Werte immer positiv ausfallen. Dieser Datentyp definiertden Datentyp Integer neu, der unter ASN.1 über eine belie-bige, unter SMI aber über eine begrenzte Genauigkeit verfügt.

SNMP – MIB-Tabellen

Die SMI von SNMPv1 definiert hochgradig strukturierte Ta-bellen, die für die Gruppierung der Instanzen eines tabellari-schen Objekts (also ein mehrere Variablen enthaltendes Ob-jekt) eingesetzt werden. Tabellen setzen sich aus keiner odermehreren Zeilen zusammen, die in einer Weise indiziert sind,die es SNMP gestattet, eine ganze Zeile mit einem einzigenGet-, GetNext- oder Set-Befehl zu ermitteln oder zu ändern.


46.6.2 SNMPv1 – Protokolloperationen

Bei SNMP handelt es sich um ein einfaches Request-Response-Protokoll. Das Netzwerk-Managementsystem (NMS) löst einRequest aus, und verwaltete Geräte liefern Responses zurück.Solches Verhalten wird durch den Einsatz einer der folgendenvier Protokolloperationen realisiert: Get, GetNext, Set undTrap. Die Get-Operation wird vom NMS verwendet, um denWert eines oder mehrerer Objektinstanzen von einem Agentenzu erhalten. Kann der auf die Get-Operation reagierendeAgent nicht für alle Objektinstanzen einer Auflistung Werteliefern, so stellt er gar keine Werte zur Verfügung. Die Get-Next-Operation wird vom NMS verwendet, um den Wert vonder nächsten Objektinstanz in einer Tabelle oder Auflistungeines Agenten zu erhalten. Die Set-Operation wird vom NMSverwendet, um die Werte von Objektinstanzen in einem Agen-ten zu setzen. Die Trap-Operation wird von Agenten verwen-det, um dem NMS asynchron wichtige Ereignisse mitzuteilen.

46.7 SNMP Version 2 (SNMPv2)

SNMP Version 2 (SNMPv2) ist eine Weiterentwicklung derersten Version, SNMPv1. Ursprünglich wurde SNMPv2 imJahre 1993 als eine Reihe von Vorschlägen für Internet-Stan-dards veröffentlicht; derzeit handelt es sich dabei um einenStandard in der Entwurfsphase. Wie bereits SNMPv1, funk-tioniert SNMPv2 innerhalb der Spezifikationen für die Struc-ture of Management Information (SMI). Theoretisch bringtSNMPv2 einige Verbesserungen gegenüber SNMPv1 mit sich,zu denen beispielsweise zusätzliche Protokolloperationen ge-hören.

46.7.1 SNMPv2 und Structure of ManagementInformation (SMI)

Die Structure of Management Information (SMI) definiert dieRegeln für das Beschreiben von Verwaltungsinformationenmittels der Abstract Syntax Notation One (ASN.1).

Die SMI von SNMPv2 ist in der RFC 1902 definiert undbringt einige Ergänzungen und Erweiterungen für SMI-spezifi-sche Datentypen mit; unter anderem für Bit Strings, Network


Addresses und Counter. Bit Strings sind nur in SNMPv2 defi-niert und umfassen keine oder mehrere bezeichnete Bits, dieeinen Wert angeben. Netzwerk-Adressen stehen für eineAdresse einer bestimmten Protokollfamilie. SNMPv1 unter-stützt nur 32-Bit-IP-Adressen, während SNMPv2 auch andereArten von Adressen unterstützt. Counter sind positive Ganz-zahlen, die erhöht werden, bis sie einen Maximalwert errei-chen, und dann wieder bei Null beginnen. In SNMPv1 sind 32Bit für die Zählergröße vorgesehen. In SNMPv2 sind Zählermit 32 und 64 Bit definiert.

SMI-Informationsmodule

Weiterhin beschreibt die SMI von SNMPv2 Informationsmo-dule, die eine Gruppe zusammengehöriger Definitionen ange-ben. Es gibt drei Arten von SMI-Informationsmodulen: MIB-Module, Compliance-Statements und Capability-Statements.MIB-Module enthalten Definitionen von sich aufeinander be-ziehenden verwalteten Objekten. Compliance-Statements stel-len eine systematische Methode zum Beschreiben einer Gruppevon verwalteten Objekten dar, die implementiert sein müssen,um einen Standard zu erfüllen. Capability-Statements werdeneingesetzt, um den genauen Grad an Unterstützung anzuzei-gen, den ein Agent hinsichtlich einer MIB-Gruppe fordert. EinNMS kann sein Verhalten gegenüber Agenten entsprechendder mit jedem Agenten verbundenen Compliance-Statementsanpassen.

SNMPv2 – Protokolloperationen

Die in SNMPv1 verwendeten Operationen Get, GetNext undSet stimmen mit den in SNMPv2 verwendeten überein. Aller-dings ergänzt und erweitert SNMPv2 einige Protokollopera-tionen. Beispielsweise erfüllt die SNMPv2-Operation Trap diegleiche Funktion wie in SNMPv1. Sie greift allerdings auf einanderes Nachrichtenformat zurück und soll das Trap vonSNMPv1 ersetzen.

SNMPv2 definiert weiterhin zwei neue Protokolloperationen:GetBulk und Inform. Die Operation GetBulk wird vom NMSverwendet, um umfangreiche Datenblöcke wie beispielsweisemehrere Zeilen einer Tabelle rationell zu erhalten. GetBulkfüllt eine Response-Nachricht mit so vielen der angeforderten


Daten wie möglich. Die Operation Inform gestattet es einemNMS, Trap-Informationen an ein anderes NMS zu senden undeine Antwort zu erhalten. Wenn der auf GetBulk-Operationenreagierende Agent unter SNMPv2 nicht für alle Variablen ei-ner Auflistung Werte liefern kann, stellt er Teilergebnisse zurVerfügung.

46.8 SNMP – Verwaltung

Bei SNMP handelt es sich um ein Protokoll für die verteilteVerwaltung. Ein System kann entweder ausschließlich alsNMS oder Agent fungieren oder aber beide Funktionen über-nehmen. Wenn eine System sowohl als NMS als auch alsAgent fungiert, kann ein anderes NMS verlangen, daß das Sy-stem verwaltete Geräte anfordert und eine Zusammenfassungder angeeigneten Informationen zur Verfügung stellt oder daßes lokal gespeicherte Verwaltungsinformationen mitteilt.

46.9 SNMP – Sicherheit

SNMP mangelt es an jeglicher Fähigkeit zur Authentifizierung,was zu einer Anfälligkeit für eine Vielzahl von Sicherheitsbe-drohungen führt. Zu diesen zählen die Täuschung, die Verän-derung von Informationen, die Veränderung der Abfolge unddes Timings von Nachrichten sowie die Preisgabe von Infor-mationen. Eine Täuschung liegt vor, wenn eine unautorisierteEinheit mit der mutmaßlichen Identität einer autorisiertenVerwaltungseinheit Verwaltungsoperationen durchzuführenversucht. Die Veränderung von Informationen bezieht sich aufeine unautorisierte Einheit, die eine von einer autorisiertenEinheit generierte Nachricht zu verändern versucht, so daß dieNachricht zu einer nicht autorisierten Verwaltungsoperationfür das Accounting oder die Konfiguration führt. Zu einerVeränderung der Abfolge und des Timings von Nachrichtenkommt es, wenn eine unautorisierte Einheit eine von einer au-torisierten Einheit generierte Nachricht erneut abruft, verzö-gert oder kopiert und später wiedergibt. Zu einer Preisgabevon Informationen kommt es, wenn eine unautorisierte Ein-heit in verwalteten Objekten gespeicherte Werte herausziehtoder durch die Überwachung des Datenaustauschs zwischenManagern und Agenten von meldepflichtigen Ereignissen er-


fährt. Da SNMP keine Authentifizierung implementiert, reali-sieren viele Anbieter die Set-Operation nicht und reduzierenSNMP damit auf ein reines Überwachungsmedium.

46.10 SNMP – Zusammenarbeit

In der gegenwärtigen Spezifikation ist SNMPv1 in zweiSchlüsselbereichen nicht kompatibel zu SNMPv2: Nachrich-tenformate und Protokolloperationen. SNMPv2-Nachrichtenverwenden im Vergleich zu SNMPv1 andere Formate für denHeader und die Protokolldateneinheiten (Protocol Data Units= PDUs). Außerdem verwendet SNMPv2 zwei Protokollope-rationen, die in SNMPv1 nicht beschrieben sind. Darüber hin-aus definiert die RFC 1908 zwei mögliche Strategien zurKoexistenz von SNMPv1/v2: Proxy-Agenten und »zweispra-chige« Netzwerk-Verwaltungssysteme.

46.10.1 Proxy-Agenten

Ein SNMPv2-Agent kann folgendermaßen als Proxy-Agent fürverwaltete Geräte von SNMPv1 agieren:

− Ein NMS von SNMPv2 ruft einen für einen SNMPv1-Agenten gedachten Befehl auf.

− Das NMS schickt die SNMP-Nachricht an den SNMPv2-Proxy-Agenten.

− Der Proxy-Agent leitet Get-, GetNext- und Set-Nachrichtenunverändert an den SNMPv1-Agenten weiter.

− GetBulk-Nachrichten werden vom Proxy-Agenten in Get-Next-Nachrichten umgewandelt und dann an den SNMPv1-Agenten weitergeleitet.

− Der Proxy-Agent bildet Trap-Nachrichten unter SNMPv1auf Trap-Nachrichten unter SNMPv2 ab und leitet diese andas NMS weiter.

46.10.2 »Zweisprachige« Netzwerk-Verwaltungssysteme

»Zweisprachige« Netzwerk-Verwaltungssysteme (NMS) unterSNMPv2 unterstützen sowohl SNMPv1 als auch SNMPv2.Um diese doppelte Verwaltungsumgebung zu unterstützen,


muß eine Verwaltungsanwendung im »zweisprachigen« NMSeine Verbindung zu einem Agenten aufbauen. Daraufhinuntersucht das NMS in einer lokalen Datenbank gespeicherteInformationen, um festzustellen, ob der Agent SNMPv1 oderSNMPv2 unterstützt. Entsprechend der Information in derDatenbank kommuniziert das NMS unter Verwendung dergeeigneten Version von SNMP mit dem Agenten.

46.11 SNMP-Referenz: SNMPv1Nachrichtenformate

Nachrichten unter SNMPv1 enthalten zwei Teile: einen Nach-richten-Header und eine Protocol Data Unit (PDU). Im Bild46.4 ist das grundlegende Format einer Nachricht unterSNMPv1 dargestellt.

PDUNachrichten-

Header

46.11.1 SNMPv1 – Nachrichten-Header

Nachrichten-Header unter SNMPv1 enthalten zwei Felder:Versionsnummer und Gemeinschaftsname. Im folgenden wer-den diese Felder kurz beschrieben:

− Versionsnummer – Gibt die Version des verwendetenSNMP an.

− Gemeinschaftsname – Definiert eine Zugriffsumgebung füreine Gruppe von NMSs. Von NMSs innerhalb der Gemein-schaft sagt man, daß sie sich in derselben Verwaltungsdo-main befinden. Gemeinschaftsnamen dienen als eine dürf-tige Form der Authentifizierung, da Geräte, die den richti-gen Gemeinschaftsnamen nicht kennen, von SNMP-Ope-rationen ausgeschlossen sind.

46.11.2 SNMPv1 – Protokolldateneinheit (PDU)

Protokolldateneinheiten (Protocol Data Units = PDUs) unterSNMPv1 enthalten einen bestimmten Befehl (Get, Set usw.)

Bild 46.4:Eine Nachrichtunter SNMPv1

setzt sich auseinem Header

und einer PDUzusammen


und Operanden, welche die in der Transaktion einbezogenenObjektinstanzen angeben. Die PDU-Felder sind unterSNMPv1 wie von ASN.1 vorgeschrieben von variabler Länge.Im Bild 46.5 sind die Felder für die Transaktionen Get,GetNext, Response und Set PDUs unter SNMPv1 dargestellt.

Fehler-status

Request-ID

PDU-Typ

Fehler-index

Objekt 1Wert 1

Objekt 2Wert 2

Objekt xWert x

variable Bindungen


− PDU-Typ – Gibt den Typ der übertragenen PDU an.

− Request-ID – Verbindet SNMP-Requests mit Responses.

− Fehlerstatus – Gibt einen von mehreren Fehlern und Fehler-typen an. Nur die Response-Operation setzt dieses Feld.Andere Operationen belegen dieses Feld mit dem Wert 0.

− Fehlerindex – Verbindet einen Fehler mit einer bestimmtenObjektinstanz. Nur die Response-Operation setzt diesesFeld. Andere Operationen belegen dieses Feld mit demWert 0.

− Variable Bindungen – Dient als Datenfeld der PDU unterSNMPv1. Jede Variablenbindung verknüpft eine bestimmteObjektinstanz mit dessen aktuellem Wert (mit Ausnahmevon Get- und GetNext-Requests, für die der Wert ignoriertwird).

46.11.3 Format von Trap PDU

Im Bild 46.6 sind die Felder von Trap PDU unter SNMPv1dargestellt.

SpezifischerTrapcode

GererischerTrapcode

Agent-AdresseEnterprise

Zeitproto-kollierung

Objekt 1Wert 1

Objekt 2Wert 2

Objekt xWert x

variable Bindungen

Bild 46.5:Get, GetNext,Response undSet PDUs ent-halten unterSNMPv1 die-selben Felder

Bild 46.6:Trap PDUsetzt sich unterSNMPv1 ausacht Feldernzusammen



− Enterprise – Gibt die Art des verwalteten Objekts an, dasden Trap generiert hat.

− Agent-Adresse – Stellt die Adresse des verwalteten Objektsbereit, das den Trap generiert hat.

− Generischer Traptyp – Gibt einen von mehreren generi-schen Traptypen an.

− Spezifischer Trapcode – Gibt einen von mehreren spezifi-schen Trapcodes an.

− Zeitprotokollierung – Stellt die seit der letzten Initialisie-rung des Netzwerks bis zum Erzeugen des Traps verstri-chene Zeit bereit.

− Variable Bindungen – Dient als Datenfeld der Trap PDUunter SNMPv1. Jede Variablenbindung verknüpft eine be-stimmte Objektinstanz mit dessen aktuellem Wert.

46.12 SNMP-Referenz: SNMPv2Nachrichtenformate

Nachrichten unter SNMPv1 setzen sich aus einem Header undeiner PDU zusammen. Im Bild 46.7 ist das grundlegende For-mat einer Nachricht unter SNMPv2 dargestellt.

PDUNachrichten-

Header

46.12.1 SNMPv2 – Nachrichten-Header

Nachrichten-Header unter SNMPv2 enthalten zwei Felder:Versionsnummer und Gemeinschaftsname. Im folgenden wer-den diese Felder kurz beschrieben:

− Versionsnummer – Gibt die Version des verwendetenSNMP an.

Bild 46.7:Nachrichten

unter SNMPv2setzen sich

ebenfalls auseinem Header

und einer PDUzusammen


− Gemeinschaftsname – Definiert eine Zugriffsumgebung füreine Gruppe von NMSs. Von NMSs innerhalb der Gemein-schaft sagt man, daß sie sich in derselben Verwaltungsdo-main befinden. Gemeinschaftsnamen dienen als eine dürf-tige Form der Authentifizierung, da Geräte, die den richti-gen Gemeinschaftsnamen nicht kennen, von SNMP-Ope-rationen ausgeschlossen sind.

46.12.2 SNMPv2 – Protokolldateneinheit (PDU)

SNMPv2 beschreibt zwei PDU-Formate, die von den SNMP-Protokolloperationen abhängen. Die Felder von PDU unterSNMPv2 verfügen wie von der ASN.1 vorgeschrieben übereine variable Länge.

Im Bild 46.8 sind die Felder von Get, GetNext, Inform,Response, Set und Trap PDUs unter SNMPv2 dargestellt.

Fehler-status

Request-ID

PDU-Typ

Fehler-index

Objekt 1Wert 1

Objekt 2Wert 2

Objekt xWert x

variable Bindungen


− PDU-Typ – Gibt den Typ der übertragenen PDU an (Get,GetNext, Inform, Response, Set oder Trap).


− Fehlerstatus – Gibt einen von mehreren Fehlern und Fehler-typen an. Nur die Response-Operation setzt dieses Feld.Andere Operationen belegen dieses Feld mit dem Wert 0.

− Fehlerindex – Verbindet einen Fehler mit einer bestimmtenObjektinstanz. Nur die Response-Operation setzt diesesFeld. Andere Operationen belegen dieses Feld mit demWert 0.


Bild 46.8:Get, GetNext,Inform, Re-sponse, Set undTrap PDUsenthalten unterSNMPv2 die-selben Felder


Format von GetBulk PDU

Im Bild 46.9 sind die Felder von GetBulk PDU unter SNMPv2dargestellt.

keineWiederholung

PDU-Typ

Max.Wiederholung

Objekt 1Wert 1

Objekt 2Wert 2

Objekt xWert x

variable Bindungen

Request-ID


− PDU-Typ – Weist die PDU als eine GetBulk-Operation aus.


− Keine Wiederholung – Gibt die Anzahl von Objektinstan-zen im Feld Variable Bindungen an, die von Beginn desRequest an nur einmal erhalten werden sollen. Dieses Feldwird verwendet, wenn es sich bei einigen der Instanzen umskalare Objekte mit nur einer Variable handelt.

− Max. Wiederholung – Definiert, wie oft andere als diedurch das Feld Keine Wiederholung angegebenen Variablenmaximal erhalten werden sollen.


Bild 46.9:GetBulk PDU

setzt sich unterSNMPv2 aus

sieben Feldernzusammen

Documents

Handbuch Netzwerk-Technologien - selfHOST · 2003-12-02 · 8 Inhaltsverzeichnis 9.4 Prioritäten-System 142 9.5 Mechanismen des Ausfall-Managements 143 9.6 Frame-Format 143 9.6.1