Scrigroup - Documente si articole

     

HomeDocumenteUploadResurseAlte limbi doc
BulgaraCeha slovacaCroataEnglezaEstonaFinlandezaFranceza
GermanaItalianaLetonaLituanianaMaghiaraOlandezaPoloneza
SarbaSlovenaSpaniolaSuedezaTurcaUcraineana

AdministrationAnimauxArtComptabilitéDiversesDroitéducationélectronique
FilmsL'économieL'histoireL'informatiqueLa biologieLa géographieLa grammaireLa littérature
La médecineLa musiqueLa politiqueLa psychologieLa sociologieLe tourismeLes mathématiquesManagement
PersonnalitésPhysiqueRecettesSportTechnique

RESEAU SNA

l'informatique



+ Font mai mare | - Font mai mic



DOCUMENTE SIMILARE

Réseau SNA

Introduction



L’architecture SNA (Systems Network Architecture) à été développée par IBM en 1974 pour l’inter fonctionnement des produits matériels et logiciels.

SNA est à l’origine de plusieurs concepts en matiÈre de réseau et de télécommunication dont deux principaux :

Architecture de réseau

Cette notion comprend la superposition d’un réseau logique au réseau physique et procure une valeur ajoutée aux fonctions de communication rudimentaires du niveau physique.

Organisation des fonctions de communication en niveaux fonctionnels ou couches

Chacune des couches est faite d’entités communicantes dont les interactions sont régies par des protocoles spécifiques et sont nécessaires à la réalisation des services fournis à la couche supérieure adjacente.

Ces deux concepts ont depuis été repris par OSI qui utilise le mÊme nombre de couches. Cependant il existe certaines différences entre OSI et SNA : les trois couches supérieures présentent des différences bien que leurs fonctions soient identiques. D’autres différences seront mentionnées dans la suite de la description de SNA.

Architecture de réseau SNA

SNA présente une structure en couches fonctionnelles séparées, ainsi qu’un ensemble de rÈgles pour communiquer au sein de cette structure :

Les couches fonctionnelles : la couche « application » constituée d’usagers (programmes, opérateurs humains, unités d’entrée-sortie) et la couche « services de présentation » structurant les données selon le format approprié, afin de les présenter aux couches inférieures pour la transmission vers le réseau, ou à la couche « application » pour le traitement

Des rÈgles : le contrôle du flux d’échanges entre les entités logiques situées dans la couche précédente et représentant les usagers, le contrôle des services de session (ouverture, fermeture et contrôle du déroulement) , le contrôle d’acheminement des messages selon des itinéraires définis et adaptation physique de ces messages, le contrôle de liaison assurant le mouvement des messages à travers une liaison physique et la jonction physique assurant l’interface nécessaire pour la connexion avec un autre ETTD ou un ETCD.

Les modÈles en couches OSI et SNA

ModÈle OSI

ModÈle SNA

END-USERS (Utilisateurs finaux)

Application

NAU Services Manager

Présentation

FMD (Function Management Data)

NAU

Session

DFC (Data Flow Control)

Transport

TC (Transmission Protocole)

Réseau

PC (Path Control)

Réseau ou

Liaison

DLC (Data Link Control)

sous-systÈme

Physique

Physical

de transport

Noeud SNA

Organisation d’un réseau SNA

Un réseau est un ensemble de composants physiques : processeurs, contrôleurs de communication, contrôleurs de grappes de terminaux, terminaux, liens d’interconnexion. L’architecture associe à cet ensemble de composants physiques un ensemble de composants logiques définis en deux catégories principales :

- les unités de réseau adressables (« Network Adressable Units » ou NAU),

- les composants de transport de l’information qui forment ce qu’on appelle le réseau transport SNA ou sous-systÈme de transport SNA (« transportation network » ou « transportation subsystem »)

Les NAU

Ce sont des composants logiques qui permettent aux utilisateurs du réseau d’accéder aux divers services qu’il fournit. Les utilisateurs peuvent Être des opérateurs humains ou des programmes. On distingue deux types :

les utilisateurs finaux utilisant les services du réseau : utilisateurs humains des terminaux connectés au réseau et programmes d’application,

Ceux qui utilisent les services du réseau à des fins de contrôle des opérations et de gestion du réseau, ces sont les utilisateurs gestionnaires : opérateurs humains se servant de terminaux spécialisés et logiciels de contrôle et de gestion du réseau.

On distingue trois types de NAU : les « Logical Unit » ou LU représentant vis-à-vis de l’ensemble du réseau un ou plusieurs utilisateurs du type utilisateurs finaux, les PU et les SSCP présentés par la suite.

Les noeuds SNA

Un autre élément d’organisation de l’architecture est le noeud SNA. Un réseau SNA est formé de noeuds interconnectés deux à deux. Chaque noeud contient un nombre variable de NAU ainsi que les composants de réseau de transport nécessaires pour les faire communiquer entre elles, ou avec les NAU d’un autre noeud au travers des interconnexions de noeud à noeud. Les noeuds sont constitués de PU (Physical Unit) telles que le processeur, le contrôleur ou le terminal ainsi qu’une version réduite d’un SSCP (System Services Control Point) appelée PUCP (Physical Unit Control Point) permettant aux opérateurs réseaux et aux logiciels de contrôle, de gérer les ressources physiques et logiques d’une partie ou de la totalité du réseau. De plus, les noeuds contiennent des composants de réseau de transport. On distingue deux catégories de noeuds : les noeuds « subarea » avec SSCP communément appelés « Physical Unit Type 5 » (PU5) ou sans SSCP communément appelés « Physical Unit Type 4 » (PU4) et les noeuds périphériques qui n’ont pas de SSCP mais une PUCP se subdivisent en PU2 et PU1. En plus des composants SSCP ou PUCP, PU et LU déjà cités, les noeuds subarea peuvent contenir un composant d’un cinquiÈme type appelé « Boundary Network Node » ou BNN, dont les fonctions seront précisées ultérieurement. Les structures des divers types de noeuds SNA seront détaillées par la suite.

Les sessions entre utilisateurs, ou sessions LU-LU, ne peuvent Être établies à travers le réseau qu’entre noeuds subarea, ou de noeud périphérique à noeud subarea. Dans la pratique, ces sessions permettent soit des interactions entre programmes d’application, soit des interactions entre terminal et programme d’application. Du fait de restrictions de mise en oeuvre, des échanges entre noeuds périphériques, c’est à dire entre terminaux, ne sont possibles que par des moyens non formalisés par l’architecture et non fournis par les produits IBM qui le mettent en oeuvre, par exemple des programmes d’application intermédiaires développés par les clients.

Des rÈgles précises régissent l’interconnexion physique des noeuds entre eux deux à deux :

de PU5 à PU5 par liaison canal ou SDLC (pour les processeurs munis d’un adaptateur de communication intégré);

de PU5 à PU4 par liaison canal ou liaison SDLC spécialisée point à point (quand le processeur est muni d’un adaptateur de communication intégré);

de PU4 à PU4 par liaison SDLC spécialisée point à point multiple (liaison parallÈle);

de noeud périphérique à noeud subarea :

- par liaison canal de PU2 à PU5;

- par liaison spécialisée SDLC (point à point ou multipoint), ou commutée, de PU2 ou PU1 à PU4 ou PU5 (avec adaptateur de communication intégré).

Dans la plupart des cas oÙ des liaisons SDLC sont utilisées, elles peuvent Être remplacées par des liaisons X21 ou par des liaisons X25. Dans ce dernier cas, des circuits virtuels commutés se substituent aux liaisons SDLC commutées, et des circuits virtuels permanents se substituent aux liaisons spécialisées SDLC.

Le réseau ou sous-systÈme de transport SNA

Il véhicule l’information échangée entre les NAU. Les fonctions de réseau de transport SNA sont réparties sur les trois premiÈres basses couches : la couche physique, la couche contenant les fonctions de gestion des divers types de liaisons de données, dites fonctions de « Data Link Control » ou DLC et la couche dite « Path Control » ou PC contenant les fonctions de contrôle d’acheminement ou de routage des messages échangés par les NAU. Le routage SNA est fondé sur une structure d’adressage et sur la définition de chemins logiques se superposant aux chemins physiques empruntés par les « Path Information Units » ou PIU formant l’information qui circule dans le réseau. En effet, chaque composant logique SNA ou NAU se voit affecter une adresse composée de deux parties : une partie dite adresse de « subarea » commune à toutes les NAU situées dans une mÊme « subarea » et une partie dite adresse d’élément identifiant de maniÈre unique une NAU dans sa « subarea ». De plus on distingue deux logiques de routage :

La premiÈre s’applique au routage entre deux noeuds « subarea » appelée routage de « subarea ». Dans chacun des noeuds subarea, les fonctions de routage sont mises en oeuvre au sein d’un ensemble de composants de contrôle d’acheminement appelé INN (« Intermediary Network Node »). Le maillage du réseau des noeuds subarea permet l’existence en général de plusieurs chemins physiques entre deux noeuds, chacun de ces chemins étant une suite de noeuds intermédiaires et de liaisons. Le routage de subarea leur superpose des chemins logiques, selon une architecture sur trois niveaux fonctionnels : le niveau « Transmission Group » ou TG qui d’une part fournit et module la bande passante entre deux noeuds et d’autre part assure un certain degré de fiabilité aux connexions logiques établies entre ces deux noeuds. Le niveau « Explicit Route » ou ER est une suite ordonnée de noeuds subarea et de TG déterminant un chemin logique unidirectionnel entre un noeud origine et un noeud destination. Enfin, le niveau « Virtual Route » ou VR est une connexion logique bidirectionnelle établie entre deux noeuds subarea. Ce niveau ajoute des fonctions de contrôle de flux de deux types : les niveaux de priorité de transmission des « Path Information Unit » ou PIU qui sont les messages échangés par les NAU et les mécanismes de régulation de flux.

La seconde s’applique au routage entre un noeud périphérique et le noeud subarea auquel il est directement connecté et est appelée « routage périphérique ». Chaque noeud subarea peut aussi servir de point d’accÈs au réseau pour les noeuds périphériques, l’acheminement des informations entre un noeud périphérique et un noeud subarea auquel il est connecté est assuré par des fonctions de routage périphérique. Ces fonctions sont mises en oeuvre dans les noeuds subarea sous la forme d’éléments de contrôle d’acheminement distinct des éléments INN, au sein d’un composant fonctionnel appelé « Boundary Network Node » ou BNN. Outre ces fonctions de routage périphérique, le BNN remplit des fonctions de contrôle logique des noeuds périphériques (plus précisément, de contrôle des sessions établies pour des NAU de noeuds périphériques au travers des noeuds subarea leur servant de point d’accÈs au réseau). Les fonctions du BNN sont donc distribuée sur l’ensemble des sept couches de SNA, et il peut Être considéré lui-mÊme comme comprenant deux composants : le premier fournissant une variante BNN des fonctions appartenant aux trois couches du réseau de transport et le second composant appelé « BNN Connection Point Manager » ou BNN CPMGR, fournissant une variante des fonctions appartenant aux quatre couches supérieures.

Le routage périphérique fournit une extension de route qui prolonge le chemin logique jusqu’au noeud périphérique dans le cas d’une session entre une NAU située dans un noeud périphérique et une NAU située dans l’un des noeuds subarea comme par exemple dans le cas d’une session entre un terminal et un programme d’application dans l’un des processeurs du réseau. Dans un tel cas, le chemin logique se compose d’une VR entre la NAU subarea et le composant BNN d’une subarea auquel est connecté le noeud périphérique (le composant BNN représentant en quelque sorte la NAU périphérique vis-à-vis du réseau subarea) ainsi que d’une extension de route entre ce mÊme composant BNN et la NAU périphérique (le composant BNN représentant la NAU subarea vis-à-vis du réseau périphérique).

D’autres services de routage sont assurés par le réseau de transport SNA :

Affectation des routes aux sessions : une des routes définie dans le réseau (une VR entre deux noeuds subarea, ou une VR et une extension de route entre un noeud subarea et un noeud périphérique) est affectée automatiquement à toute session au moment de son établissement. Cette route sera utilisée par la session pendant toute sa durée. Une mÊme VR peut Être affectée à plusieurs sessions différentes. Des processus d’activation et de désactivation des routes sont déclenchées par les SSCP en relation avec les processus d’établissement et de terminaison de session. Une VR est désactivée dÈs qu’elle n’est plus utilisée par aucune session; elle sera activée dÈs qu’elle sera affectée à une session. Une ER est désactivée dÈs que toutes les VR auxquelles elle est sous-jacente deviennent inactives; elle sera réactivée dÈs qu’une de ces VR le sera.

Traitement des erreurs de routage : un certain nombre d’erreurs de nature physique ou logique peut affecter les divers composants d’une route. Une mÊme erreur peut affecter plusieurs routes. Des processus de traitement d’erreur peuvent dans certains cas permettre une reprise de l’élément affecté sans interrompre le fonctionnement des routes qui l’utilisent. Lorsque ce n’est pas possible, la ou les routes sont interrompues, et ceci provoque l’interruption des sessions auxquelles ces routes étaient affectés. Le ou les noeuds subarea ayant détecté l’erreur génÈrent alors des notifications qui se propagent dans le réseau à l’intention des SSCP, qui peuvent ainsi identifier les routes et les sessions interrompues, et à l’intention des partenaires de ces sessions, pour les avertir de leur interruption. Lorsque l’erreur se produit dans le réseau subarea, l’existence de plusieurs routes entre deux noeuds subarea permet d’établir immédiatement les sessions interrompues sur d’autres routes en état de fonctionnement correct. Cette reprise des sessions consiste en leur réinitialisation. Elle est effectuée par l’intermédiaire des SSCP à l’initiative des utilisateurs et sous le contrôle des opérateurs. Elle peut Être rendue automatique au moyen d’opérateurs programmés.

En plus des fonctions de routage proprement dite, le sous-systÈme ou réseau de transport fournit d’autres services tels que :

- la supervision de la non duplication des PIU durant leur retransmission;

- la traduction entre les formats différents attribués à une PIU selon qu’elle circule dans le réseau subarea ou un réseau périphérique;

- le groupage (blocking) de plusieurs PIU au sein d’une mÊme unité de retransmission pour optimiser l’utilisation des liaisons et leur dégroupage une fois rendus à destination;

Leur fragmentation (segmenting) en plusieurs unités de transmission pour adapter celle-ci aux capacités réduites de mémorisation d’un noeud périphérique récepteur, et leur réassemblage une fois parvenues à destination.

L’une des vues possibles d’un réseau SNA pour ce qui est du transport de l’information est celle qui est illustrée par la figure 1. Les noeuds subarea PU5 et PU4, dans la pratique processeurs d’application et contrôleurs de communication, forment un réseau de transport appelé parfois « Backbone Network », qu’il est possible de mailler à volonté en interconnectant ces noeuds deux à deux, et au sein duquel le routage de subarea permet l’acheminement des informations entre deux quelconques parmi les noeuds, qu’ils soient adjacents ou distants.


PU2

 

PU2

 
Subarea de PU5

(Processeur)


Subarea de PU4

(Contrôleur de

Communication)

Liaison canal

Liaison SDLC

Fig. 1. Réseau de noeuds subarea et sous-réseaux périphériques

Structure et fonctions des NAU

Trois grandes catégories de fonctions ou services sont présentes dans toute NAU quelque soit son type, qui sont arrangées en niveaux fonctionnels ou couches. Une NAU peut en général établir plusieurs sessions avec d’autres NAU. Chaque session se voit affecter de façon dynamique dans la NAU un élément dans chacune des couches TC, DFC et FMD, l’ensemble des trois éléments formant un composant appelé demi session (« half-session »). Un quatriÈme niveau couronne, celui du contrôle des services de NAU (« NAU Services Manager »), qui d’une part coordonne le fonctionnement des composants demi session assurant les divers services de la NAU, et qui d’autre part permet aux utilisateurs d’accéder à ces services. Les différents services ou couches sont :

Services de contrôle de transmission (« Transmission Control » ou TC). D’une façon générale, ces services complÈtent ceux de connectivité globale que fournit le réseau de transport par des fonctions de connectivité point à point pour chacune des sessions dans lesquelles la NAU est engagée. Ces différents types de services sont :

- Les services du type gestion de connexion assurent la coordination de tous les flux de messages pour une session de NAU. Ils sont fournis par un composant TC appelé « Connection Point Manager » ou CPMGR. On distingue quatre services pour la gestion de connexion : l’interfaçage entre la NAU et le réseau transport avec manipulation d’unités d’informations (« Basic Information Unit » ou BIU) et rajout d’informations de contrôle pour former les PIU (« Path Information Unit »), le contrôle de flux de bout en bout de type priorité de transmission ou « pacing » s’appliquent respectivement pour la transmission entre RU (« Request/Response Unit ») et pour celle entre LU, le séquencement des messages assurant le contrôle des messages reçus ainsi que le service de cryptographie assurant le chiffrement des messages en émission et leur déchiffrement en réception.

- Les services du type contrôle de session (« Session Control » ou SC) contrôlent l’activation et la désactivation des sessions. Pour chaque session, ils maintiennent des états caractérisant la phase dans laquelle elle se trouve, et assurent un contrôle des messages échangés tenant compte de ces états. Ils permettent de démarrer le trafic sur une session ou au contraire de l’interrompre. Ils permettent enfin la re synchronisation du séquencement des messages dans les situations de reprise de session.

- Les services du type contrôle de réseau (« Network Control » ou NC) propagent, dans le réseau, des notifications décrivant l’état des ressources physiques contrôlées par les PU, en particulier l’état des liens de communication, dans les situations de défaillance de ces ressources.

Services de contrôle d’échange de données (« Data Flow Control » ou DFC). Leur rôle est de fournir aux NAU les moyens d’organiser et de synchroniser leur dialogue, et de gérer leur échange de données. Les services DFC sont :

- Le contrôle du mode d’échange des messages (le mode bidirectionnel simultané ou « full-duplex mode », le mode bidirectionnel à alternat avec droit initial d’émission prédéterminé ou « half-duplex mode » et le mode bidirectionnel à alternat avec droit initial d’émission déterminé par un protocole de gestion de contention (« half-duplex contention mode »).

- Le chainage des messages permet à l’utilisateur d’une LU de regrouper de façon logique plusieurs requÊtes émises dans la mÊme direction et de les envoyer comme une seule entité. Il peut Être utilisé pour fractionner un long message en une chaine de RU pour adapter l’envoi de ce message aux capacités de réception et de mémorisation de l’utilisateur destinataire, ou pour permettre au traitement du message par ce dernier de commencer sans attendre que la totalité du message ait été reçue (un exemple classique est l’envoi d’une page d’écran par un programme d’application à un terminal).

- Le service d’accusé de réception permet à l’utilisateur d’une NAU de contrôler la réception par son interlocuteur des messages qu’il lui adresse, de façon à détecter les défaillances éventuelles qui peuvent se produire dans leur transmission et dans leur réception, et de façon à invoquer des procédures de reprise appropriées.

- Le « Bracketing » permet aux utilisateurs en session de regrouper de façon logique une suite de messages qui sont corrélés dans la logique de leur dialogue ou, en d’autres termes, qu’ils échangent en vue de réaliser une unité de traitement bien déterminée appelée « Logical Unit of Work » ou LUW. Ce service est par exemple utilisé par des applications de type transactionnel pour séparer les uns des autres les traitements de transaction.

- D’autres services DFC tels que le rejet de part et d ’autre des messages entachés d’erreurs, la réduction des pauses dans le dialogue, la coordination de l’arrÊt du trafic, la demande de l’inversion du droit d’émission en mode à l’alternat ainsi que l’échange des informations d’état.

Services de traitement des données de contrôle des fonctions (« Function Management Data ») ou services FMD. Eux mÊme se partagent en:

- Services réseau (« Network Services ») :

Les services d’opérateur réseau (« Network Operator Services ») permettent aux opérateurs réseau, qui peuvent Être des opérateurs programmés, de communiquer avec les SSCP pour avoir accÈs aux services de contrôle de configuration et aux services de maintenance et de gestion.

Les services de contrôle de configuration (« Configuration Services ») sont distribués dans les SSCP, PU et LU et leur mise en oeuvre se fait au travers des sessions SSCP-PU et SSCP-LU. Ils permettent aux opérateurs réseau de gérer l’ensemble des ressources physiques et logiques du réseau qui concourent à rendre celui-ci utilisable pour l’établissement de sessions LU-LU (activation ou désactivation des liaisons et des noeuds, chargement à distance de logiciels dans les contrôleurs de communication et de terminaux,, réactivation de parties du réseau ayant été désactivées à la suite de la défaillance d’un noeud ou d’une liaison).

Les services de maintenance et de gestion (« Maintenance and Management Services ») dont distribués dans les SSCP et les PU et leur mise en oeuvre se fait au travers des sessions SSCP-LU. Ils sont utilisés par les opérateurs réseau dans les cas de défaillance dont l’origine n’a pas pu Être clairement identifiée par les mécanismes de détection et de notification d’erreurs. Ils consistent en différentes vérifications effectuées par des logiciels spécialisés permettant de déterminer les causes des défaillances et en particulier leur localisation dans les noeuds ou dans les liaisons.

Les services de contrôle de session (« Session Services ») sont distribués seulement dans les SSCP et les LU et leur mise en oeuvre se fait au travers des sessions SSCP-LU et SSCP-SSCP et permet l’activation ou la désactivation des sessions LU-LU. L’établissement d’une session LU-LU se fait à la demande de l’utilisateur de l’une ou l’autre des deux LU, ou à celle d’un troisiÈme intervenant qui peut Être soit un utilisateur d’une troisiÈme LU, soit un opérateur réseau (humain ou programmé). Le processus mettant fin à une session LU-LU s’effectue de maniÈre similaire. Il est déclenché à l’initiative de l’un des deux utilisateurs ou d’un opérateur réseau.

- Services utilisateur (« End-User Services ») :

Ils sont distribués dans les LU. Certains d’entre eux sont basés sur l’utilisation d’en-tÊtes structurant l’information contenue dans les RU.

Les services de présentation (« Presentation Services ») sont divisés en deux catégories. La premiÈre comprend les services de « data compression » et « data compaction », dont le but est de minimiser le volume des données échangées. La compression consiste à reconnaitre les séquences de caractÈres répétés, à les remplacer en émission par un code indiquant le caractÈre répété et le nombre de répétitions, et à restituer en réception la séquence originale. La « compaction » s’applique aux caractÈres les plus fréquemment utilisés, et consiste en un recodage spécial permettant d’en placer deux dans un octet. Une autre catégorie comprend les services de type terminal virtuel pour les sessions entre terminaux et programmes d’application. SNA définit des protocoles de présentation permettant de réaliser ces services, par l’intermédiaire de flux de données structurés mixant ces données et des codes permettant de contrôler leur présentation (« SNA Character String » ou SCS et « 3270 Data Stream » utilisé par la famille des terminaux IBM 3270).

Les services d’inter fonctionnement de programmes d’application permettent de réaliser des applications distribuées, c’est-à-dire de répartir le traitement d’une telle application entre plusieurs processeurs faisant partie d’un mÊme réseau. D’une façon générale un traitement distribué consiste en interactions deux à deux entre les divers programmes qui coopÈrent pour réaliser l’application distribuée. On distingue deux types d’applications distribuées : Le traitement par lots distribué (« Distributed Batch Processing » ou « Job Networking ») permet de distribuer les fonctions d’entrée, de traitement, de sortie pour les travaux ou « jobs » demandés par les utilisateurs et le traitement de transactions distribué ou transactionnel distribué (« Distributed Transaction Processing ») consiste à traiter concurremment et en temps réel plusieurs demandes de service généralement soumises par des opérateurs humains au moyen de terminaux. Les exemples les plus classiques sont les applications bancaires ou la réservation de siÈges auprÈs de compagnies aériennes. De telles applications impliquent en général la consultation et la modification de bases de données, et des traitements nombreux exécutés par des programmes de traitement de transaction (« Transaction Processing Programs » ou TPP).

Dans l’environnement SNA, des logiciels systÈme, ou sous-systÈmes SNA, appelés « Transaction Processing Systems » ou TPS, fournissent un environnement opérationnel aux programmes d’application. Cet environnement se compose d’une part de facilités de traitement et de gestion d’ensembles de données (bases de données, fichiers, files d’attente, ), et d’autre part, de facilités de communication de données fournies par un type de LU appelé LU6, dont la version la plus avancée et la LU6.2 est communément appelée « Advanced Program-to-Program Communication » ou APPC. Les services de LU6.2 assurent la conversation et l’établissement en parallÈle de plusieurs sessions entre deux utilisateurs.

Sessions LU-LU

Parmi les services de session LU-LU, tous ne sont pas requis pour une session particuliÈre, mais seulement un sous-ensemble d’entre eux qui dépend de l’application utilisatrice. Dans chacune des couches TC, DFC et DFC, des sous-ensembles de services ont été définis, chacun contenant ceux susceptibles de satisfaire les besoins des applications. Ces sous-ensembles sont appelés profils (« function profiles ») et sont définis comme suit :

- des « Presentation Services profiles » ou « PS-profiles » dans la couche FMD,

- des « Function Management profiles » ou « FM-profiles » dans la couche DFC,

- des « Transmission Subsystem profiles » ou « TS-profiles » dans la couche TC.

A chacun des types de session LU-LU ou, plus simplement, types de LU correspond un choix de profils parmi ceux définis pour chacune des trois couche TC, DFC, FMD. Le tableau ci-dessous donne la liste des types de LU existant à ce jour et pour chacun le type d’application utilisant ce type de LU. Un mÊme produit peut avoir à supporter plusieurs types de LU :

Type de LU

Type d’application

Principales caractéristiques

Programme-à-programme

Menu des services non fixé par profil prédéfini mais défini par la mise en oeuvre

Terminal-à-programme

Terminaux fonctionnant en mode ligne et utilisant le service de présentation SCS (imprimante, clavier, )

Terminal-à-programme

Terminaux fonctionnant en mode page et utilisant le service de présentation 3270 data stream (écran-clavier, imprimante, )

Terminal-à-programme

Imprimantes utilisant le service de présentation 3270 data stream

Terminal-à-programme ou programme-à-programme

Terminaux et/ou processeurs effectuant du traitement de données ou du traitement de texte, et utilisant le service de présentation SCS

Programme-à-programme

voir « FMD : services utilisateurs » et « LU6.2 »

Terminal-à-programme

Terminaux de bureautique utilisant le service de présentation 5520 data stream

Une notion importante à retenir est celle de l’asymétrie existant entre les deux côtés d’une session LU-LU. En effet, on distingue deux types UUUde LU : LU primaire (« Primary LU » ou PLU) et LU secondaire (« Secondary LU » ou SLU). La PLU a d’une façon générale un rôle prépondérant dans le contrôle de l’interaction. Pou chaque type de LU, sauf le type 6, il y a donc une variante PLU et une variante SLU, et lorsqu’un produit met en oeuvre un type de LU, il réalise en fait l’une ou l’autre des deux variantes. Par exemple, les fonctions d’un terminal 3270 sont celles de LU2 secondaire ou SLU2, alors que celles des méthodes d’accÈs et TPS qui supportent ce type de terminal réalisent les fonctions LU2 primaire ou PLU2.

Il y a évidemment une différence notable avec des architectures qui, comme OSI par exemple, mettent en pratique une symétrie totale dans les interactions entre entités homologues dans chacune de leurs couches, et qui résolvent les problÈmes inhérents à cette pratique, soit au moyen de jetons relatifs à certains services, que les entités peuvent échanger, et dont la possession à un instant donné confÈre le droit de contrôle sur les interactions correspondant à ces services. Cette différence résulte en fait des objectifs différents assignés aux deux architectures. Dans le cas de SNA, architecture « privée » pour environnements homogÈnes, il n’y a aucune raison d’introduire plus de symétrie que nécessaire, par exemple dans les interactions entre processeurs et terminaux. Dans celui d’OSI, architecture « publique » pour environnement hétérogÈne, on ne peut rien préjuger à propos des systÈmes qu’elle se propose d’interconnecter, et une telle symétrie est obligatoire.

Avec l’apparition et l’importance croissante des applications impliquant des interactions de type programme-à-programme, en particulier le transactionnel distribué, une évolution notable s’est manifestée en SNA, qui s’est traduite par le développement des LU de type 6, et de façon encore plus affirmée dans sa version 6.2 qui est la plus avancée. Comme on l’a déjà vu, la LU6.2 fournit deux niveaux d’association entre deux partenaires :

- un niveau session, fournissant des services d’association en quelque sorte permanente entre TPS,

- un niveau « conversation », fournissant des services d’association temporaire entre TPP et utilisant le niveau session pour ses besoins de communication (on peut considérer que les « conversations » sont multiplexées dans le temps sur les sessions).

Une LU 6.2 possÈde la double capacité primaire/secondaire, elle peut trÈs bien assumer le rôle de PLU pour l’une de ses sessions parallÈles et celui de SLU pour une autre et est utilisée entre les anciens processeurs de la famille 370.

Noeud SNA et noeud-produits

Un réseau SNA est décrit par l’architecture comme un ensemble de noeuds SNA interconnectés, dont elle définit les composant et dont elle spécifie les fonctions ou services ainsi que les interactions, et ceci en principe sans préjuger de la façon dont les produits implémentent ces divers composants. ConcrÈtement, un réseau SNA apparait comme un ensemble de produits interconnectés, ou noeud-produits, qui sont des processeurs, des contrôleurs de communications, des contrôleurs de terminaux et des terminaux, qui offrent, à côté des fonctions SNA, des fonctions non SNA. On distingue trois grands types de noeuds SNA.

Noeud subarea avec SSCP

Pour lequel le noeud produit est un processeur. Excepté les fonctions de la couche physique et une partie des fonctions DLC, réalisées par des adaptateurs de communication (adaptateur canal ou adaptateur intégré pour les liaisons SDLC et X25), les fonctions de noeud SNA sont réalisées au moyen de logiciels de communication qui opÈrent sous le contrôle du systÈme d’exploitation du processeur. La méthode d’accÈs la plus représentative est le logiciel ACF/VTAM ( Advanced Communication Function / Virtual Teleprocessing Access Method ), assure la totalité des fonctions de SSCP, PU et BNN, et les fonctions d’un réseau de transport de bout en bout. Elles délivrent une interface de programmation ou API au-dessus de laquelle les utilisateurs peuvent développer des programmes d’application dits programmes « Roll Your Own » ou RYO. D’autre part, des logiciels appelés sous-systÈmes sont proposés par IBM pour compléter les fonctions LU des méthodes d’accÈs et fournir en combinaison avec elles la totalité des fonctions d’un noeud subarea avec SSCP. De plus, avant l’introduction de SNA, il existait des sous-systÈmes tel que BTAM (Basic Telecommunication Access Method ) qui opéraient au dessus des méthodes d’accÈs pré-SNA. L’introduction des fonctions SNA dans les sous-systÈmes a été pratiquée en général de façon à offrir aux applications préexistantes des solutions de migration à l’environnement SNA. Enfin, les méthodes d’accÈs SNA offrent également une interface de programmation spéciale utilisable pour développer des logiciels de gestion de réseau qui fonctionnellement se situent au-dessus du SSCP et de la PU et en constituent des extensions. Les applications de gestion de réseau sont regroupées sous le nom d’applications CNM (« Communication Network Management »). L’ensemble des fonctions CNM sont mises en oeuvre dans les processeurs au travers du logiciel de base NCCF (« Network Communication Control Facility »), qui opÈre au-dessus de la méthode d’accÈs SNA et utilise l’interface de programmation définie par CNM à cet effet (« Communication Network Management Interface » ou CNMI). NCCF fournit principalement :

- d’une part, un accÈs généralisé aux divers services de gestion pour des opérateurs réseau humains programmés,

- d’autre part, une interface de programmation au-dessus de laquelle des logiciels d’application de gestion spécialisés peuvent Être développés.

Noeud subarea sans SSCP

Pour lequel le noeud-produit est un contrôleur de communication de type 3725 ou 3705. Les fonctions de communication sont fournies au moyen de logiciels de contrôle, dont le plus important est ACF/NCP ( Advanced Communication Function / Network Control Program ) qui fournit les fonctions SNA de noeud subarea sans SSCP. Les contrôleurs de communication tels que les 3725 font appel à un processeur de service intégré, le « Maintenance Operator Subsystem » ou MOSS pour la gestion de réseau. Il joue un rôle important dans l’application CNM chargée de la détection et de la gestion des problÈmes de nature physique, en relation avec le logiciel d’application CNM NPDA ( Network Problem Determination Aid ). Cette application est chargée de collecter les messages « alert » comportant l’identification et l’adresse du noeud, l’identification du composant défaillant, la nature et la cause probable de l’erreur. Puis range ces « alerts » dans une base de données maintenue avec l’aide de NCCF. Le logiciel ACF/NCP fournit un support SNA de deux types pour les noeuds sans SSCP :

- Un premier type fournit un support d’attachement pour certains terminaux IBM pré-SNA ou compatibles utilisant comme discipline de ligne la procédure BSC ( Binary Synchronous Communication ) soit la procédure asynchrone S/S (Start / Stop ), et permet de leur faire accéder à l’environnement et aux applications SNA.

- Un deuxiÈme type consiste en une interface de programmation permettant aux utilisateurs de développer des logiciels modifiant le support des disciplines de ligne non SNA mises en oeuvre par ACF/NCP, et d ’en supporter ainsi les des variantes non IBM. De tels logiciels permettent aux utilisateurs de faire accéder à l’environnement SNA des terminaux non IBM et non SNA.

Par exemple, on peut disposer d’un support d’attachement réseau X25 proposé pour les liaisons INN et BNN. Ce support n’est pas directement incorporé dans ACF / NCP, mais fait l’objet d’un logiciel additionnel et optionnel : X25 NPSI (NCP Packet Switching Interface ). NPSI comporte d’une part un support des fonctions de ETTD X25, et d’autre part les facilités suivantes :

- support des liaisons BNN, en d’autres termes rattachement des terminaux SNA aux processeurs SNA à travers un réseau X25 (par exemple Transpac), un adaptateur externe étant fourni côté terminal;

- support des liaisons INN, en d’autre termes interconnexion des contrôleurs de communication par liaisons X25 permettant aux processeurs SNA de dialoguer à travers les réseaux X25;

- attachement des terminaux X25 natif aux contrôleurs de communication. Dans ce dernier cas, on distingue plusieurs solutions telle que GATE ( Generated Access X25 Transport Extension ) permettant de prolonger les circuits virtuels au travers de sessions SNA jusque dans un processeur muni de la méthode d’accÈs ACF/VTAM, de maniÈre à rendre accessibles les services réseau X25 à des logiciels de type RYO.

- Noeud périphérique, pour lequel le noeud-produit est le plus généralement un contrôleur de terminaux auquel peuvent se connecter plusieurs terminaux. Il existe toutefois des noeud-produits qui intÈgrent les fonctions de noeud SNA périphérique et de terminal proprement dit. Un exemple de noeud produit est l’unité de contrôle 3724 qui sert à raccorder aux réseaux SNA les terminaux de la famille 3270 qui lui sont connectés par cable coaxial, et qui donne à ces terminaux l’apparence de SLU2.

Interconnexion de réseaux SNA

Une extension de SNA appelée SNI (SNA Network Interconnect ) permet l’interconnexion de réseaux SNA indépendants. Le concept de base consiste à utiliser une PU4 dont les fonctions sont enrichies de celles d’un composant supplémentaire, appelé « gateway component » ou composant passerelle, permettant à cette PU4 d’opérer comme une passerelle entre les deux réseaux. Le but est de pouvoir établir des sessions entre LU des deux réseaux, ou sessions SNI. L’établissement d’une session SNI se fait au travers du composant passerelle de PU4 en aboutant deux pseudo-sessions, une dans chacun des réseaux, établies entre chacune des deux LU et le composant passerelle. En plus d’une PU4 munie d’un composant passerelle, ou PU4 passerelle, l’interconnexion de deux réseau requiert également le concours d’une PU5 passerelle. Dans la pratique, la logique SNI est mise en oeuvre par des extensions aux logiciels ACF/VTAM et ACF/NCP. ConcrÈtement, une PU4 passerelle est un contrôleur de communication de la famille des 37xx exécutant le logiciel ACF/NCP muni de son option SNI, et une PU5 passerelle est un processeur exécutant le logiciel ACF/VTAM muni de son option SNI. La figure 2 illustre l’interconnexion de deux réseaux SNA via une passerelle constituée d’une PU4 et d’une PU5.


Interconnexion de deux réseaux SNA via une passerelle PU5/PU4

Architectures évoluées SNADS, DIA, DCA

Les architectures DCA (Document Content Architecture) et DIA (Document Interchange Architecture) ont été développées pour la mise en oeuvre de services bureautique dans l’environnement SNA. Ces services ont été conçus comme ceux d’une application distribuée dont les composants communiquent en utilisant les services d’un réseau SNA et apparaissent comme les utilisateurs finaux ou « end-users » de ce réseau. En d’autres termes, bien que de DCA et DIA soient présentées chacune comme une architecture en soi, leur ensemble fournit un exemple d’architecture d’application SNA distribuée communément appelé « Office Interchange Architecture » ou OIA.

L’architecture SNADS

(SNA Distribution Services)

Définit des composants appelés « Distribution Service Units » ou DSU qui forment un réseau de communication asynchrone construit au-dessus du réseau synchrone SNA. Avec SNADS un composant émetteur OIA peut remettre son envoi, appelé « Distribution Interchange Unit » ou DIU, à la DSU dont il utilise les services, ceci sans que le composant émetteur destinataire soit nécessairement actif. Sa DSU enverra la DIU au travers du réseau SNADS jusqu’à la DSU desservant le composant OIA destinataire. D’une façon générale, l’ensemble des services de SNADS sont des services de distribution différée. Bien qu’ayant été à l’origine conçue pour compléter et améliorer les fonctions de bureautique de l’architecture OIA, l’architecture SNADS a des objectifs plus généraux, qui sont de fournir des services de communication asynchrone pour tout type d’application distribuée requérant ce type de service. Elle superpose au réseau SNA/LU6.2 un réseau du type « store-and-forward » dont les DSU sont les noeuds. Ce réseau possÈde sa propre structure d’adressage, ses propres formats de données et sa propre logique d’acheminement. La structure d’adressage fait appel à des noms plutôt qu’à des adresses du fait que les DSU et leurs utilisateurs sont en fait les utilisateurs d’un réseau SNA sous-jacent. Deux structures d’affectation de noms sont définies, l’une pour les DSU et l’autre pour leurs utilisateurs.

Les utilisateurs sont considérés comme répartis en groupes. Chacun est identifié par un nom (« Distribution User Name » ou DUN), lui-mÊme composé d’un nom de groupe unique dans le réseau (« Distribution Group Name » ou DGN) et d’un nom d’élément de groupe (« Distribution Element Name » ou DEN) unique dans le groupe.

De mÊme, les DSU sont réparties en groupes et chacune est identifiée par un nom ( Distribution Service Unit Name  ou DSUN) composé d’un nom de groupe unique ( Routing Group Name  ou RGN) et d’un nom d’élément unique dans le groupe ( Routing Element Name  ou REN).

Un service d’annuaire associe à chaque nom d’utilisateur destinataire de l’envoi émis ou ré émis par la DSU un nom de DSU destinataire. Dans chaque DSU, une table de routage détermine la connexion à utiliser pour transmettre la DIU à la DSU désignée par le service d’annuaire.

L’architecture DIA

Les services DIA sont fournis par un réseau de composants ou noeuds logiques OIA se superposant à un réseau SNA muni de préférence d’une extension SNADS. DIA définit l’organisation de ce réseau de noeuds logiques dont elle distingue deux types principaux :

Un premier type est celui de noeud d’utilisateurs, qui offre l’interface permettant aux utilisateurs d’accéder aux services OIA. Un noeud d’utilisateurs peut Être soit un noeud émetteur (« Source Node » ou SN), soit un noeud récepteur (« Recipient Node » ou RN), soit les deux simultanément (noeud SN/RN).

Le second type est celui de noeud systÈme (« Office System Node » ou OSN) dont le rôle sera précisé par la suite.

La dépendance des noeuds SN, RN et SN/RN vis-à-vis des noeuds OSN se manifeste également aux niveaux de trois des quatre catégories de services définies par DIA :

Services de session DIA (Session Services). Ce sont des services d’association logique entre noeuds OIA propres à la couche DIA. Deux noeuds OIA quelque soit leur type peuvent établir une session DIA et échanger directement de l’information au travers de cette session.

Services de distribution de document (Document Distribution Services). Ils obligent les noeuds SN/RN à recourir à des services de librairie ou de traitement d’application résidant dans les noeuds OSN.

Services de « bibliothÈque » (Document Library Services). Ils réalisent la transposition au courrier électronique des activités classiques de classement et de constitution de dossiers.

Services de traitement d’application (Application Processing Services). Ces services comprennent des fonctions additionnelles fournies dans les noeuds OSN par les processus de traitement de document ainsi que les commandes permettant aux utilisateurs de demander des modifications de format de document et l’exécution de programmes d’application au moyen de diverses commandes.

L’architecture DCA

(Document Content Architecture)

Définit les moyens d’organiser le contenu ou le texte des documents en vue de leur distribution et de leur présentation aux utilisateurs destinataires. Lorsque les documents circulent dans le réseau, leur contenu peut revÊtir deux formes différentes définies par DCA : une forme révisable et une forme finale. Le contenu d’un document sous forme révisable (« Revisable Form-Text document » ou document RFT) peut Être modifié par tout utilisateur autorisé à retirer ce document d’une librairie. Par contre, le contenu d’un document sous forme finale ( Final-Form-Text document  ou document FFT) a été formaté en vue de sa présentation et ne peut plus Être modifié. Il y a donc en fait une architecture DCA RFT et une architecture DCA FFT :

DCA RFT spécifie la structure de la séquence de données qui représente un document RFT dans le réseau OIA. Une séquence RFT est organisée de façon classique en champs de données de texte et champs de données de contrôle. Ces derniers contiennent des instructions de formatage général pour tout ou une partie du document (dimensions de page, emplacement des marges, ), ou des instructions de formatage ponctuel (saut de page, retour à la ligne, ).

DCA FFT spécifie la structure de la séquence de données qui représente un document FFT dans le réseau OIA. A la différence d’une séquence RFT, une séquence FFT ne contient pas d’instructions de formatage général. Elle contient donc le texte original du document, du texte généré inséré dans le texte original, et les instructions de contrôle interprétées par l’équipement de sortie pour présenter le document sur un écran ou pour l’imprimer dans le format voulu.

La figure suivante illustre la structure générale d’un systÈme de bureautique mettant en oeuvre les architectures SNADS, DIA, DCA. Un tel systÈme apparait comme un réseau construit au-dessus d’un réseau SNA, et dont les noeuds sont les composants DSU, définis par SNADS, et les composants SN/RN et OSN, définis par DIA.



Politica de confidentialitate | Termeni si conditii de utilizare



DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 671
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved