Unités logiques (LU) dépendantes et DLUR/DLUS
Contenu
Introduction
Figure 1 
Initialement, la mise en réseau APPN (Advanced Peer-to-Peer Networking) prenait en charge uniquement les connexions peer-to-peer ? ? ? sessions utilisant des connexions LU (Logical Unit) 6.2. Cependant, APPN est également viable si le réseau peut prendre en charge le trafic SNA (Systems Network Architecture) existant (par exemple, LU 0, 1, 2).
Dans APPN, il n'existe plus le concept de fin primaire et secondaire d'une session. Quel que soit le point de terminaison choisi pour lancer la session, il devient le point principal et envoie le BIND. Cependant, avec le trafic SNA hérité, l'extrémité secondaire demande à la méthode d'accès aux télécommunications virtuelles (VTAM) d'initier la session. Il n'existe aucun concept de noeud qui ne peut pas envoyer le BIND dans APPN. Pour cette raison, une assistance spéciale est requise pour les unités logiques secondaires héritées qui ne peuvent pas émettre de BIND.
Le demandeur/serveur d'unité logique dépendant (DLUR/DLUS) résout le problème des unités logiques dépendantes dans les réseaux APPN, où le serveur est mis en oeuvre dans VTAM 4.2 et le demandeur peut se trouver dans un noeud réseau (NN) ou un noeud d'extrémité (EN) du réseau.
Conditions préalables
Conditions requises
Aucune spécification déterminée n'est requise pour ce document.
Components Used
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
Conventions
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Principes fondamentaux de DLUR/DLUS
Figure 2 
Une paire de sessions LU 6.2 est établie entre les flux de contrôle DLUR et DLUS (tels que Activate LU, Deactivate LU, Activate Physical Unit (PU), Deactivate PU, LOGON, INITIATE) sur ces sessions entre DLUS et DLUR. Le DLUR transmet les messages aux ressources appropriées.
Les unités logiques dépendantes secondaires (DLU) peuvent initier des sessions en envoyant une requête d'ouverture au DLUR, qui la place ensuite sur l'un des canaux LU 6.2.
Une fois la demande de session traitée, les communications DLUS et DLUR sont terminées.
Extensions de service de session DLUR/DLUS
Figure 3 
Une fois que VTAM/DLUS reçoit la demande de session, le VTAM détermine où se trouve l'application et envoie une requête CDINIT-LOCATE à l'hôte de l'application, demandant qu'un BIND soit envoyé au secondaire.
Cette prise en charge dans APPN VTAM est connue sous le nom de Session Services Extensions, ce qui implique que les services de session SNA hérités ont été publiés dans APPN.
Les extensions de service de session prennent également en charge les initiations de session tierces et la mise en file d'attente jusqu'à ce qu'un partenaire de session devienne disponible, en plus d'une session secondaire initiée.
Services de routage DLUR/DLUS
Figure 4 
Une fois que l'application est informée qu'elle doit envoyer la BIND à une unité logique héritée, la BIND est envoyée sur le réseau APPN. Il n'est pas encapsulé. Le trafic SNA existant et le trafic APPN utilisent le même en-tête SNA et peuvent coexister sur le réseau APPN.
Bien que VTAM soit au courant de l'ouverture de session, le trafic de session n'a pas besoin de passer par VTAM ou son routeur CIP (Channel Interface Processor) connecté. À l'aide des algorithmes APPN, le réseau qui fournit la fonctionnalité du serveur réseau à l'hôte d'application sélectionne le meilleur chemin à travers le réseau, qui fournit la classe de service (CoS) appropriée.
Activation du tuyau d'exemple DLUR/DLUS
Figure 5
Lorsqu'une identification d'échange (XID) est reçue, DLUR signale aux points de contrôle des services système (SSCP) que ses services sont requis en envoyant une demande d'activation d'une unité physique (REQACTPU) au DLUS. Par la suite, DLUS émet la demande ACTPU.
Figure 6 
Dans ce flux, le noeud de réseau de filiale/DLUR (BrNN/DLUR) a reçu un XID du PU en aval, qui indique à DLUR de demander des services SSCP à DLUS. Dans tous les XID02 ou XID32, le bit de demande ACTPU est défini puis REQACTPU envoyé. Si aucun « canal » n'est actif, le premier 'Localiser' et suivant une requête BIND est envoyé pour démarrer le canal.
DLUS renvoie ensuite la réponse positive +RSP REQACTPU suivie de la demande ACTPU.
Arrêt automatique du réseau
DLUR fournit la prise en charge de l'arrêt automatique du réseau (ANS), similaire à la prise en charge des ANS fournie par le programme de contrôle de réseau (NCP). Si un PU a été activé avec ANS = CONT spécifié, toutes les sessions LU-LU existantes sont conservées lorsque le canal se termine.
DLUR rejette tout trafic SSCP-PU/LU provenant du périphérique dépendant.
En fonction de l'activation ultérieure du périphérique dépendant, DLUR peut mettre fin à la session LU-LU.
Prise en charge SSCP - État stable
Figure 7 
Dans la Figure 7, toutes les sessions (SSCP-PU, SSCP-LU et LU-LU) ont été établies et les données circulent sur la session LU-LU.
Reprise SSCP - Interruption
Figure 8 
Dans la Figure 8, une panne de réseau s'est produite qui brise les canaux DLU-DLUR et, par conséquent, les sessions SSCP-PU et SSCP-LU.
La session LU-LU se poursuit, car elle ne passe pas par le routeur Cisco CIP NN affecté.
Prise en charge SSCP - Prise en charge
Figure 9 
Dans la Figure 9, le DLUS de sauvegarde commence à prendre le relais, les tuyaux sont établis, les ressources sont activées (ACTPU, une unité logique d'activation [ACTLU]) et DLUR envoie des informations de session (unité logique principale [PLU], LU1) sur une réponse ACTLU.
Les sessions sont maintenant rétablies par le nouveau SSCP. Les sessions LU-LU suivantes donneront lieu à une prise de conscience des sessions de DLUR à VTAM3.
Lorsque la récupération se produit dans VTAM1, le retour arrière peut se produire et les sessions SSCP-PU et SSCP-LU peuvent être désactivées par VTAM3 et réactivées par VTAM1, restaurez la configuration d'origine sans perturber les sessions LU-LU.
Commentaires