Abhängige LUs und DLUR/DLUS
Inhalt
Einführung
Abbildung 1 
Anfänglich unterstützte Advanced Peer-to-Peer Networking (APPN) nur Peer-to-Peer-Verbindungen??-Sitzungen, bei denen Logical Unit (LU) 6.2-Verbindungen verwendet wurden. APPN ist jedoch auch dann sinnvoll, wenn das Netzwerk den Legacy Systems Network Architecture (SNA)-Datenverkehr (z. B. LUs 0, 1, 2) unterstützen kann.
In APPN gibt es nicht mehr das Konzept des primären und sekundären Endes einer Sitzung. Welcher Endpunkt die Sitzung initiiert, wird zum primären und sendet das BIND. Bei veraltetem SNA-Datenverkehr fordert das sekundäre Ende jedoch die Virtual Telecommunications Access Method (VTAM) zum Initiieren der Sitzung auf. Es gibt kein Konzept für einen Knoten, der das BIND in APPN nicht senden kann. Aus diesem Grund ist eine spezielle Unterstützung für ältere sekundäre LUs erforderlich, die kein BIND ausgeben können.
Der abhängige LU-Antragsteller/Server (DLUR/DLUS) löst das Problem für die abhängigen LUs in APPN-Netzwerken, bei denen der Server in VTAM 4.2 implementiert ist und der Antragsteller sich in einem Netzwerkknoten (NN) oder Endknoten (EN) im Netzwerk befinden kann.
Voraussetzungen
Anforderungen
Für dieses Dokument bestehen keine speziellen Anforderungen.
Verwendete Komponenten
Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.
Konventionen
Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.
DLUR/DLUS-Grundlagen
Abbildung 2 
Zwischen den DLUR- und DLUS-Kontrollflüssen (z. B. "LU aktivieren", "LU deaktivieren", "Physische Einheit aktivieren" (PU), "PU deaktivieren", "LOGON", "INITIATE") werden zwei LU 6.2-Sitzungen zwischen DLUS und DLUR eingerichtet. Der DLUR leitet die Meldungen an die entsprechenden Ressourcen weiter.
Sekundäre abhängige LUs (DLUs) können Sitzungen initiieren, indem sie eine initiierte Anfrage an den DLUR senden, der diese dann auf einem der LU 6.2-Leitungen ablegt.
Sobald die Sitzungsanfrage gesendet wurde, sind die DLUS- und DLUR-Kommunikation abgeschlossen.
DLUR/DLUS-Sitzungsserviceerweiterungen
Abbildung 3 
Sobald VTAM/DLUS die Sitzungsanfrage empfängt, bestimmt das VTAM, wo sich die Anwendung befindet, und sendet eine CDINIT-LOCATE-Anfrage an den Anwendungshost, in der eine BIND an die sekundäre Anwendung gesendet werden soll.
Diese Unterstützung in APPN VTAM wird als Session Services Extensions (Sitzungsdiensterweiterungen) bezeichnet. Dies bedeutet, dass die bisherigen SNA Session Services in APPN veröffentlicht wurden.
Session Service Extensions unterstützen auch Sitzungsinitiationen und Warteschlangenverwaltung von Drittanbietern, bis ein Sitzungspartner verfügbar ist, zusätzlich zu einer sekundär initiierten Sitzung.
DLUR-/DLUS-Routing-Services
Abbildung 4 
Sobald die Anwendung benachrichtigt wird, dass sie das BIND an ein Legacy-LU senden soll, wird das BIND über das APPN-Netzwerk gesendet. Es ist nicht gekapselt. Der Legacy-SNA-Datenverkehr und der APPN-Datenverkehr verwenden denselben SNA-Header und können gleichzeitig im APPN-Netzwerk vorhanden sein.
Obwohl VTAM die Initiierung von Sitzungen erkennt, muss der Sitzungsverkehr nicht über VTAM oder den angeschlossenen CIP-Router (Channel Interface Processor) geleitet werden. Mithilfe von APPN-Algorithmen wählt das NN, das dem Anwendungshost Netzwerkserverfunktionen bereitstellt, den besten Pfad durch das Netzwerk aus, der die entsprechende Class of Service (CoS) bereitstellt.
SvD/DLUS-Beispielproduktaktivierung
Abbildung 5
Wenn eine Exchange Identification (XID) empfangen wird, signalisiert DLUR den System Services Control Points (SSCP), dass seine Services benötigt werden, indem eine Anforderung zur Aktivierung einer physischen Einheit (REQACTPU) an den DLUS gesendet wird. Anschließend gibt DLUS die ACTPU-Anforderung aus.
Abbildung 6 
In diesem Datenfluss hat Branch Network Node/DLUR (BrNN/DLUR) eine XID von der Downstream-PU erhalten, die DLUR signalisiert, SSCP-Services vom DLUS anzufordern. In allen XID02 oder XID32 hat ACTPU Anfrage Bit gesetzt dann REQACTPU gesendet. Wenn kein "Pipe" aktiv ist, wird zuerst 'Suchen' und nach einer BIND-Anfrage gesendet, um das Pipe zu starten.
DLUS gibt dann die positive Antwort +RSP REQACTPU zurück, gefolgt von der ACTPU-Anforderung.
Automatische Netzwerkabschaltung
DLUR bietet eine ANS-Unterstützung (Auto Network Shutdown), ähnlich der ANS-Unterstützung durch das Network Control Program (NCP). Wenn eine PU mit ANS = CONT aktiviert wurde, werden alle vorhandenen LU-LU-Sitzungen erhalten, wenn die Leitung beendet wird.
DLUR lehnt jeglichen SSCP-PU/LU-Datenverkehr vom abhängigen Gerät ab.
Abhängig von der nachfolgenden Aktivierung des abhängigen Geräts kann DLUR die LU-LU-Sitzung beenden.
SSCP-Übernahme - Steady State
Abbildung 7 
In Abbildung 7 wurden alle Sitzungen (SSCP-PU, SSCP-LU und LU-LU) eingerichtet, und die Daten fließen über die LU-LU-Sitzung.
SSCP-Übernahme - Ausfall tritt ein
Abbildung 8 
In Abbildung 8 ist ein Netzwerkausfall aufgetreten, der die DLUs-DLUR-Leitungen und damit die SSCP-PU- und SSCP-LU-Sitzung unterbricht.
Die LU-LU-Sitzung wird fortgesetzt, da sie nicht über den betroffenen Cisco CIP NN-Router verläuft.
Übernahme von SSCP - Übernahme erfolgt
Abbildung 9 
In Abbildung 9 beginnen die Übernahme des Backup-DLUS, Pipes werden eingerichtet, Ressourcen werden aktiviert (ACTPU, eine aktivierte logische Einheit [ACTLU]), und DLUR sendet Sitzungsinformationen (primäre logische Einheit [PLU], LU1) auf eine ACTLU-Antwort.
Die Sitzungen werden jetzt mithilfe des neuen SSCP wiederhergestellt. Spätere LU-LU-Sitzungen führen zu einer Sitzungserkennung von DLUR an VTAM3.
Wenn in VTAM1 eine Wiederherstellung stattfindet, können giveback auftreten, und SSCP-PU- und SSCP-LU-Sitzungen können von VTAM3 deaktiviert und von VTAM1 reaktiviert werden. Dadurch wird die ursprüngliche Konfiguration wiederhergestellt, ohne dass eine LU-LU-Sitzung unterbrochen wird.
Feedback