Institut national des sciences appliquees de lyon

3.8. Service Liaison de Données

La couche Liaison de données permet de transférer des unités de données (trames) entre entités de réseau par l'intermédiaire d'une ou plusieurs connexions physiques. Elle permet aussi d'établir, de maintenir ou de libérer une connexion entre ces entités.

Dans la mesure du possible, elle doit assurer un transfert fiable de données. Pour cela, elle détecte et corrige les erreurs pouvant se produire dans la couche physique, assure un maintient en séquence des données et un contrôle de flux sur la liaison. En pratique une liaison de données permet un transfert d'information entre deux systèmes, ou plus, partageant le même circuit physique, ou entre un système et un point d'entrée d'un réseau de télécommunications.
Lorsque le Service Physique est un service multipoint, il offre une ressource partagée sur laquelle un seul système peut émettre à un instant donné. Dans le cas d'une architecture dissymétrique (maître-esclave) l'accès peut être géré par le protocole de Commande de la liaison logique (LLC: Logical Link Control).

Sur un réseau local, où le contrôle est réparti entre les systèmes, un service de Commande d'accès au médium (MAC: Method Acces Control) gère le partage de ressource. Dans ce cas la détection d'erreur (par code cyclique) est descendue à ce sous-niveau.

3.9. Service Physique

La couche Physique fournit les moyens mécaniques, électriques, fonctionnels et procéduraux nécessaires à l'activation, au maintient et à la désactivation des connexions physiques destinées à la transmission transparente des bits entre les entités de liaison de données.

Une connexion physique peut mettre en jeu plusieurs systèmes ouverts intermédiaires. Les entités de la couche Physique sont interconnectées au moyen d'un support physique de communication : câble, fibre optique, onde hertzienne. Le composant de base au niveau physique est le "circuit de données", chemin de communication dans le support physique d'interconnexion de systèmes ouverts, muni des moyens nécessaires à la transmission des bits sur ce chemin.
Une connexion physique est assurée par un ou plusieurs circuits de données (interconnectés par des systèmes relais). Les moyens à mettre en oeuvre comportent notamment les modems, les coupleurs de communication et les interfaces entres ces composants. Sur une connexion physique, il n'est pas possible de garantir une transmission sans erreurs du flux d'information.
L'apparition des réseaux à très haut débit (FDDI: Fiber Distributed Data Interface, ATM: Asynchronous Transfert Mode) a induit une structuration de ce service en 2 ou 3 sous-couches, en particulier pour traiter l'adressage dans les réseaux en commutation de cellules (ATM).

4. FONCTIONNEMENT DU MODELE DE REFERENCE

4.1. Services et Interfaces entre couches :

D'après le modèle d'Interconnexion des Systèmes Ouverts de l'OSI, la description des services est fonctionnelle. Dans les standards décrivant les services, on trouve essentiellement une description des fonctions traitées dans le sous-ensemble concerné, les primitives permettant de le mettre en oeuvre, et l'enchaînement entre ces primitives.

L'accès à un service se fait par un point d'accès au service : SAP (Service Acces Point) . Celui-ci peut regrouper plusieurs "connexions" . Celles-ci sont vues au niveau du SAP comme un ensemble de "points d'extrémité de connexion" : CEP (Connection End Point). Le service N+1, adjacent supérieur au service de niveau N, émet vers lui des Requètes pour initier des fonctions rendues par le service N. Celui-ci avertit le service N+1, coté accepteur, qu'il a reçu un "message" pour lui par une indication. A la suite d'une Indication, le service N+1 peut fournir une Réponse positive ou négative. Cette Réponse est transmise, par le service N, au service N+1 initiateur sous la forme d'une Confirmation.
Ces échanges de primitives de service sont illustrées sur les schémas ci-dessous:

Les schémas suivants montrent les différentes classes de services : simple, confirmé, confirmé localement. Un service confirmé garantit que la fonction demandée à bien été traitée par le service accepteur (positivement ou négativement). Un service confirmé localement garantit seulement que la demande a été envoyée au service accepteur et que le service N local peut accepter une nouvelle requète.

Les interfaces entre sous-systèmes sont laissés à l'initiative des personnes chargées de l'implantation.

Toutefois, on trouvera souvent une spécification minimale de l'interface avec le sous-ensemble utilisateur ( adjacent supérieur ) et parfois de l'interface avec la couche "fournisseur" ( adjacente inférieure ). Cette description fournit uniquement la liste et la nature des paramètres à passer dans les primitives du service pour en permettre l'utilisation complète. Le concepteur peut introduire d'autres primitives, ajouter des paramètres ou les présenter sous la forme la plus efficace pour son implantation.
Cependant, ce Modèle de Référence contient implicitement les mécanismes d'enchaînement des primitives à travers toutes les couches pour permettre le fonctionnement du système complet. En effet, lorsque le système de communication doit être utilisé par plusieurs applications simultanément, les entités gérant des sous-ensembles des protocoles ou les ressources nécessaires à chaque connexion ("contextes" ) ne peuvent chargées et activées en permanence.

4.2. Structures de données

A la structure imbriquée des services ( assemblage hiérarchisé des composants), correspond une structure des données échangées en " pelure d'oignon ".
On appelle :
* PDU (Protocol Data Unit) les unités de données de protocoles échangées entre entités paires des systèmes communicants.
* SDU (Service Data Unit) les unités de données de service échangées entre les entités adjacentes d'un système.
* PCI (Protocol Control Information) les informations de contrôle du protocole ajoutées par une entité à une SDU, une fraction de SDU ou un groupe de SDU pour former une PDU. Ces informations sont les seules qui sont générées ou analysées par l'entité.
Pour un système sans fragmentation ni regroupement ces structures de données sont construites selon le schéma de principe ci-dessous :

A l'interface les SDU sont passées en paramètres dans les requêtes (coté initiateur) ou des indications (coté répondeur) de données : DATAReq ou DATAInd.

La partie droite du schéma montre la formation d'une PDU dans une entité de niveau N ne comportant pas de données utilisateur.

Les schémas suivants illustrent les fonctions de fragmentation-regroupement : segmentation / réassemblage , concaténation / séparation et groupage / dégroupage.

Segmentation - réassemblage

Concaténation - séparation

Groupage - dégroupage

Données d'interface

Les tailles des structures de données de part et d'autre d'un interface ne sont pas toujours identiques ou multiples l'une de l'autre. Le passage se fait à l'aide d'une Unité de données d'interface : IDU (Interface Data Unit). La taille de l'IDU doit être choisie pour optimiser les interactions. A l'interface, la taille de buffer, exprimée en nombre d'IDU, doit être calculée pour ne pas bloquer la communication. Ceci est illustré sur les schémas suivants.

La taille de l'IDU est le PGCD des tailles de la SDU et de la PDU. La taille des files à une interface doit tenir compte :

du nombre d'interactions pouvant se trouver simultanément dans cette interface. On est souvent obligé de limiter le nombre de primitives de données. de la taille de la plus longue interaction.

Le schéma ci-dessous illustre un cas de blocage et un cas de fonctionnement correct.

Exemple : Structuration des données sur les 7 niveaux