Institut national des sciences appliquees de lyon

8 RELATIONS SNA -OSI

Alors que l'architecture OSI est une architecture logique standard multi-vendeurs, SNA est une architecture constructeur qui comporte des protocoles spécifiques.

En analysant l'architecture fonctionnelle de SNA, nous avons pu voir que les fonctions traitées sont très équivalentes à celle du modèle OSI (ce qui est normal, les concepteurs des standards OSI connaissant en général bien SNA et l'architecture INET ...). Cependant la répartition des fonctions dans les couches est différente. Cependant on obtient des services voisins aux niveaux Réseau (3/OSI) et Session (5/OSI) ce qui facilite la réalisation de passerelles.
Ainsi IBM a pu fournir des services OSI sur certains équipement, sans développer à l'époque, toute l'architecture :
OSNS (Open System Network Support) offrait un service réseau en commutation de paquets permettant d'utiliser les réseaux publics comme Transpac sur certains matériels. Sur certains systèmes OSNS remplace le service PC et supporte directement le service TC de SNA, pour permettre à SNA d'utiliser les réseaux en commutation de paquets publics comme système de transmission.

Dans d'autres cas, cet accès est réalisé par des systèmes externes ou des logiciels spécifiques; alors les circuits virtuels permanents sont vus comme des liaisons spécialisées et les circuits virtuels commutés comme des liaisons téléphoniques commutées.

OTSS (Open System Transport and Session Support) fournissait un service session OSI.
Cette architecture a préfiguré l'architecture OSI/CS (OSI/Communication Subsystem) fournie actuellement. Cette architecture OSI complète est disponible en concurrence avec SNA et fournit la même interface utilisateur aux applications dans le cadre de l'architecture unifiée d'applications ( SAA). Dans le cadre de OSI/CS, le niveau Application contient le service de fichiers FTAM et la messagerie X400, l'administration de réseau OSI: CMISE et l'annuaire X500, qui utilisent ACSE et le noyau de présentation.
Le logiciel de gestion de fichiers FTAM, placé au dessus de OSI/CS, fournit le service OSI/FS (OSI File Service).
La passerelle avec SNA est réalisée par GTMOSI.
Une interface programmatique (API) permet l'accès au niveau session, présentation et ACSE, par des appels de procédures Cobol ou C.
Pour l'administration de réseau SNA, OSI/CS est vu comme un "point de service" pour Netview.

INTRODUCTION à la SPECIFICATION FORMELLE

Description des protocoles par automates d'états étendus (automates à prédicats )

Les protocoles de communication sont décrits par des automates d'états finis à prédicats ( automates étendus ). Les services sont souvent modélisés de la même manière. La description formelle de ces automates d'états finis à prédicats peut prendre trois formes de précision croissante qui présentent chacune leur intérêt. La conception voire la compréhension d'un tel automate nécessite d'utiliser ces trois formes. Pour chaque forme il existe plusieurs notations parfois éloignées l'une de l'autre.

1 Description par graphe

Nous ne donnerons ici qu'un exemple de description par graphe sous une forme simple. D'autres formes sont souvent utilisées. En particulier, le langage LDS (Langage de description et de spécification fonctionnelle) du CCITT (Recommandation Z.100 et annexes) fournit une syntaxe plus détaillée. Les standards ECMA utilisent aussi une autre notation. Les schémas ci-dessous montre l'évolution d'un tel graphe au cours de la conception d'un protocole élémentaire.

On utilise une notation LDS graphique en n'en gardant que les éléments de base.

Les primitives sont codées par les suffixes: req, ind, rsp+, rsp-, cnf+ et cnf-.

Les Préfixes CON, LIB et DATA correspondent respectivement à des événements de connexion, libération et données.

Le contenu des primitives de données vaut :

CR demande de connexion

DT données utilisateur

CC acceptation de connexion

LR demande de libération

LC acceptation de libération

Dans le premier automate ci-dessous on suppose le service N - 1 déjà connecté et on s'intéresse essentiellement aux phases de connexion et de libération. Le transfert de données est juste amorcé pour montrer quand et comment il est initialisé.

Si le service N-1 n'est pas toujours prêt, il est nécessaire, sur la requête de connexion venant de la couche N + 1, de demander l'établissement d'une connexion à ce service et d'en attendre la confirmation. Nous noterons par le prédicat P1 la préconnexion du service N - 1.
Le second automate tient compte de cette initialisation du service N-1 .
Cet automate est complété pour traiter (sommairement ici ...) le transfert de données et aussi prendre en compte les défauts en introduisant un état " Erreur " supplémentaire activé soit sur un événement entrant ERRind (Indication d'erreur), soit sur un événement interne. On pourrait aussi le compléter en dédoublant l'état 2 Transfert en deux états : " Prêt " et " Occupé " pour gérer la fonction de contrôle de flux. Parfois, par exemple pour cette fonction, on lance un sous-automate qui n'est actif que dans l'état " Transfert ".

42 Description par table ou liste de transitions

Nous donnerons la forme classique de ce type de description, utilisée dans la plupart des standards de l'O.S.I.

Nous utilisons les conventions ci-dessous :

	Evénement entrant
Etat actuel	P1: Etat suivant Action et/ou événement sortant P2: X Y = yyyy EVEreq Défaut :

Pi : Prédicat testé dans l'ordre de la liste

Evt entrant tEtat	CONreq	LIBind	CONcnf	LIBreq	DATreq	DATind (CC)	DATind (DT)	DATind (LC)
Rrepos 0	P1 : 1 DATreq (CR) Def: 4 CONreq			0 défaut			0 défaut
Connex 1		0 CONcnf-				2 CONcnf+ +
Transfert 1 1				3 DATreq (LR)	2 DATreq (DT)		2 DATind (dat)
Deconex 3 3		0 LIBcnf		ignorer				0 LIBcnf
Attente 4 4			1 DATreq (CR)
Défaut 5 5				0 xxxx

Pour traiter de manière automatique ces tables de transitions, par exemple dans des outils de simulation ou de validation des protocoles représentés, il est plus commode de les coder sous la forme de listes de quintuplets :

< Evénement, Etat , Prédicat, Etat , Action ou >

entrant actuel suivant liste d'actions

Chaque quintuplet représente une transition élémentaire. Il est souhaitable que l'ordre des transitions dans la liste soit indifférent. Cependant ceci implique que les fonctions logiques exprimant les prédicats soient plus complexes. En pratique, on tiendra donc souvent compte, pour trouver la transition tirable à un instant donné, du rang de cette transition. La liste suivante donne un exemple de cette représentation.
< CONreq , Repos , P1 , Attente , CONreq >

< CONreq , Repos , Def, Connex , DATreq(CR) >

< CONcnf , Attente , , Connex , DATreq(CR) >

< IND_Don(LR) , Connex , , Repos , CONcnf- >

< CONind(CC) , Connex , , Transfert , CONcnf+ >

< DATreq(dat) , Transfert, , Transfert , DATreq(DT) >

< DATind(DT) , Transfert, , Deconex , DATreq(LR) >

< DATind(LC) , Deconex, , Repos , LIBcnf >
Nota : Parfois les paramètres apparaissant dans un événement entrant "Indication de données " sont traités comme des prédicats.

3.