Résumé

Ce modèle de référence de recommandation X.200 fournit une base commune pour la coordination de l’établissement des normes en matière d’interconnexion de systèmes ouverts, tout en permettant de situer les normes existantes dans le cadre du modèle de référence global. Il identifie également les domaines appelant un développement et une amélioration de la normalisation et fournit une référence commune pour préserver l’homogénéité des différentes normes concernées. Le texte a été mis au point conjointement avec l’ISO/CEI, l’objet principal de cette révision étant de produire le texte conjoint, qui introduit le concept de transmission en mode sans connexion et incorpore un certain nombre d’améliorations supplémentaires d’ordre technique ou rédactionnel.

1 – Domaine d’application X.200

1.1 – L’objectif du modèle de référence d’interconnexion de systèmes ouverts est de fournir une base commune de coordination pour l’élaboration de normes portant sur l’interconnexion de systèmes, tout en permettant de situer les normes existantes par rapport au modèle de référence dans son ensemble.

1.2 – L’expression interconnexion de systèmes ouverts (OSI) qualifie une famille de normes d’échange d’informations entre systèmes qui sont «ouverts» aux échanges entre eux du fait de l’adoption par les uns et les autres des normes appropriées.

1.3 – Le fait qu’un système soit ouvert n’implique aucune réalisation ou technologie particulières de systèmes, ni des moyens d’interconnexion particuliers, mais exprime l’acceptation et l’application mutuelles des normes appropriées.

1.4 – L’objectif du modèle de référence d’interconnexion de systèmes ouverts est également d’indiquer les domaines où il importe d’élaborer ou d’améliorer des normes et de fournir une référence commune permettant d’assurer la cohérence de toutes les normes relatives à l’interconnexion de systèmes ouverts. Le modèle de référence d’interconnexion de systèmes ouverts n’est prévu ni pour servir de spécification de réalisation, ni pour fournir une base d’évaluation de la conformité de réalisations réelles, ni pour offrir un niveau de détail suffisant permettant de définir avec précision les services et protocoles de l’architecture d’interconnexion. L’idée est plutôt de définir un cadre conceptuel et fonctionnel permettant aux équipes internationales d’experts de travailler de manière productive et indépendante à l’élaboration de normes pour chacune des couches du modèle de référence d’interconnexion de systèmes ouverts.

1.5 – Le modèle de référence est suffisamment souple pour s’adapter aux progrès technologiques et à l’extension des demandes des utilisateurs. Cette souplesse devra également permettre aux réalisations actuelles d’évoluer par étapes vers les normes OSI.

1.6 – Bien que le domaine d’application des principes généraux d’architecture impliqués par l’OSI soit très vaste, le modèle de référence d’interconnexion de systèmes ouverts concerne essentiellement les systèmes comprenant des terminaux, des ordinateurs et périphériques associés et les moyens de transfert d’information entre de tels systèmes. D’autres aspects de l’OSI méritant d’être considérés sont décrits succinctement (voir 4.2).

1.7 – La description du modèle de référence OSI de base est présentée par étapes successives:

1.8 – L’article 4 établit l’intérêt de l’interconnexion de systèmes ouverts, définition de ce qui est connecté, domaine d’application de l’interconnexion, description des principes de modélisation appliqués dans l’OSI.

1.9 – L’article 5 décrit les aspects généraux de l’architecture du modèle de référence: structuration en couches, signification de cette stratification et principes de description des couches.

1.10 – L’article 6 mentionne l’identification et la présentation des différentes couches de l’architecture.

1.11 – L’article 7 fournit la description des différentes couches.

1.12 – L’article 8 fournit la description des aspects gestion de l’OSI.

1.13 – L’article 9 précise la spécification de la conformité au modèle de référence OSI.

1.14 – Une indication sur la façon dont les couches ont été choisies est donnée en Annexe A de ce modèle de référence de base.

1.15 – Les autres aspects du modèle de référence sont décrits dans différentes parties. La première décrit le modèle de référence de base. La seconde décrit l’architecture de sécurité OSI. La troisième décrit la dénomination et l’adressage OSI. La quatrième enfin décrit la gestion système OSI.

1.16 – Le modèle de référence de base sert de cadre à la définition des services et protocoles qui s’inscrivent dans les limites établies par le modèle de référence.

1.17 – Dans les quelques cas pour lesquels une caractéristique est explicitement qualifiée comme étant «optionnelle» dans le modèle de référence de base, cette caractéristique devrait être également optionnelle dans le service ou le protocole correspondant (même si à un instant donné, les deux possibilités de l’option ne sont pas encore étayées par des documents).

1.18 – Ce modèle de référence ne spécifie ni services ni protocoles OSI. Il ne s’agit ni d’une spécification de réalisation de systèmes, ni d’une base pour l’appréciation de la conformité des réalisations.

1.19 – Pour les normes qui répondent aux spécifications OSI, les fonctions optionnelles ont été organisées en un petit nombre de sous-ensembles pratiques afin d’en faciliter la mise en oeuvre et l’appréciation de la compatibilité des réalisations.

2 – Définitions de la recommandation X.200

On trouvera des définitions de termes au début de certains articles et paragraphes. Afin d’y faciliter l’accès, un index est fourni en Annexe B.

3 – Notations de la recommandation X.200

3.1 – Les couches sont présentées à l’article 5. La notation (N), (N+1) et (N-1) sert à identifier les couches et à les situer par rapport aux couches adjacentes:

• couche (N): une couche quelconque;
• couche (N+1): la couche immédiatement supérieure;
• couche (N-1): la couche immédiatement inférieure.

Cette notation s’applique également à d’autres concepts du modèle relatifs à ces couches; par exemple: protocole (N), service (N+1).

3.2 – Le nom de chacune des couches est indiqué à l’article 6. Quand on se réfère à ces couches par leur nom, on remplace les épithètes (N), (N+1) et (N-1) par le nom des couches, précédé, le cas échéant, par l’article «de»; exemples: protocole de transport, entité de session, service de réseau.

4 – Introduction à l’interconnexion de systèmes ouverts (OSI)

NOTE – Les principes généraux de la recommandation X.200 décrits aux articles 4 et 5 sont valables pour toutes les couches du modèle de référence, sauf indications contraires spécifiques à une couche, et formulées aux articles 6 et 7.

4.1 – Définitions

4.1.1 – système réel: Ensemble comprenant un ou plusieurs ordinateurs, le logiciel associé, des périphériques, des terminaux, des opérateurs humains, des processus physiques, des moyens de transfert d’information, etc. et constituant un tout autonome capable d’effectuer des traitements et/ou des transferts d’information.

4.1.2 – système ouvert réel: Système réel dont les communications avec d’autres systèmes réels sont effectuées conformément aux normes OSI.

4.1.3 – système ouvert: Représentation, dans le cadre du modèle de référence, des aspects d’un système ouvert réel qui relèvent de l’OSI.

4.1.4 – processus d’application: Elément d’un système ouvert réel effectuant un traitement d’information pour une application particulière.

4.1.5 – environnement d’interconnexion de systèmes ouverts (OSIE) (open system interconnection environment): Représentation abstraite de l’ensemble des concepts, éléments, fonctions, services, protocoles, etc., tels qu’ils sont définis dans le modèle de référence OSI et dans les normes dérivées dont l’application permet la communication entre systèmes ouverts.

4.1.6 – environnement local de système (LSE) (local system environment): Représentation abstraite de la partie du système réel qui ne relève pas de l’OSI.
NOTE – Le LSE peut inclure des fonctions nécessaires aux communications non OSI.

4.1.7 – invocation de processus d’application: Utilisation spécifique d’une partie ou de toutes les capacités d’un processus d’application dans un cas spécifique de traitement de l’information.

4.1.8 – type de processus d’application: Description d’une classe de processus d’application en termes de capacités de traitement de l’information.

4.2 – Environnement de l’interconnexion de systèmes ouverts

4.2.1 – Dans le cadre conceptuel de l’OSI, un système réel est un ensemble comprenant un ou plusieurs ordinateurs, le logiciel associé, des périphériques, des terminaux, des opérateurs humains, des processus physiques, des moyens de transfert d’information, etc. constituant un tout autonome capable d’effectuer des traitements et/ou des transferts d’information.

4.2.2 – Un processus applicatif est un élément de système ouvert réel effectuant un traitement d’information pour une application particulière.

4.2.3 – Les processus applicatifs peuvent représenter des processus manuels, des processus informatisés ou des processus physiques.

4.2.4 – Les exemples suivants sont des processus applicatifs obéissant à la précédente définition d’un système ouvert:

    a) une personne utilisant un terminal bancaire est un processus applicatif manuel;
    
    b) un programme FORTRAN s’exécutant dans un centre informatique et accédant à une base de données distante est un processus applicatif informatisé; le serveur du système de gestion de la base de données distante est également un processus applicatif;

    c) un programme de contrôle de processus s’exécutant sur un calculateur dédié connecté à un équipement industriel et en liaison avec un système de contrôle de production est un processus applicatif physique.

4.2.5 – Un processus applicatif représente un ensemble de ressources, y compris les ressources de traitement, dans un système ouvert réel, qui peuvent servir à mener une activité particulière de traitement de l’information. Un processus applicatif peut organiser ses interactions avec d’autres processus applicatifs de toute manière utile pour atteindre un objectif particulier de traitement de l’information: le présent modèle de référence n’impose aucune contrainte ni sur la forme de ces interactions ni sur les relations possibles pouvant exister entre elles.

4.2.6 – L’activité d’un processus applicatif donné est représentée par une ou plusieurs invocations de processus applicatifs. La coopération entre processus applicatifs se réalise via les relations établies entre invocations de processus d’activité. A un instant donné, un processus applicatif peut être représenté par zéro, une ou plusieurs invocations de processus applicatifs. Une invocation de processus applicatif est responsable de la coordination de ses interactions avec d’autres invocations de processus applicatifs. Cette coordination sort du cadre du présent modèle de référence.

4.2.7 – L’OSI concerne les échanges d’information entre systèmes ouverts (et non le fonctionnement interne de chacun des systèmes ouverts réels).

4.2.8 – Comme le montre la Figure 1, le support physique d’interconnexion de systèmes ouverts constitue le moyen de transférer l’information entre systèmes ouverts.

4.2.9 – L’OSI ne concerne que l’interconnexion de systèmes. Les autres aspects des systèmes qui ne sont pas liés à leur interconnexion ne sont pas du domaine de l’OSI.

4.2.10 – L’OSI ne concerne pas seulement le transfert d’information entre systèmes, c’est-à-dire la transmission, mais également l’aptitude de ces systèmes à interfonctionner pour réaliser une tâche commune (répartie). En d’autres termes, l’OSI concerne les aspects interactifs de la coopération1) entre systèmes, ce qui découle de l’expression «interconnexion de systèmes».

4.2.11 – L’objectif de l’OSI est de définir un ensemble de normes permettant la coopération des systèmes ouverts réels. Un système qui respecte les normes applicables de l’OSI pour coopérer avec d’autres systèmes est appelé un système ouvert réel.

4.2.12 – L’objectif des normes OSI est de rendre possible la communication entre systèmes autonomes. Tout équipement qui communique conformément aux protocoles OSI applicables est l’équivalent, dans l’univers réel, du concept de «système ouvert» défini dans le présent modèle de référence. Un équipement appartenant à la catégorie des «terminaux», c’est-à-dire un équipement nécessitant une intervention humaine dans les phases principales du traitement, peut satisfaire aux conditions énoncées dans la phase précédente quand les normes OSI appropriées sont utilisées dans la communication avec d’autres systèmes.

4.3 – Modélisation de l’environnement OSI

4.3.1 – L’élaboration de normes OSI, c’est-à-dire de normes pour l’interconnexion de systèmes ouverts réels, s’appuie sur l’utilisation de modèles abstraits. Afin de spécifier le comportement externe des systèmes ouverts réels interconnectés, chaque système ouvert réel est remplacé par un modèle abstrait fonctionnellement équivalent appelé système ouvert. En toute rigueur, seuls les aspects relatifs à l’interconnexion de ces systèmes ouverts auraient besoin d’être décrits. Pour y parvenir, il est toutefois nécessaire de décrire à la fois les comportements interne et externe de ces systèmes ouverts. Seul le comportement externe des systèmes ouverts est retenu pour la définition des normes des systèmes ouverts réels. Dans le modèle de référence de base, le fonctionnement interne des systèmes ouverts n’est décrit qu’à seule fin de permettre la définition des aspects relatifs à l’interconnexion. Tout système réel ayant le comportement externe d’un système ouvert peut être considéré comme un système ouvert réel.

4.3.2 – Cette modélisation abstraite s’effectue en deux étapes.

4.3.3 – On détermine d’abord les éléments de base des systèmes ouverts et certaines décisions clés sont prises quant à leur organisation et à leur fonctionnement. On aboutit ainsi au modèle de référence de base d’interconnexion de systèmes ouverts décrit dans la présente Recommandation | partie de Norme internationale.

4.3.4 – On donne ensuite une description détaillée et précise du fonctionnement du système ouvert, dans le cadre défini par le modèle de référence de base. On aboutit ainsi aux services et protocoles d’interconnexion de systèmes ouverts, qui font l’objet d’autres Recommandations | Normes internationales.

4.3.5 – Il convient de souligner que le modèle de référence de base, ne spécifiant pas par lui-même le fonctionnement détaillé et précis des systèmes ouverts, ne saurait spécifier le comportement externe des systèmes ouverts réels ni imposer une structure de réalisation quelconque pour un système ouvert réel.

4.3.6 – L’attention du lecteur non familier des techniques de modélisation abstraite est attirée sur le fait qu’en dépit d’une similitude apparente avec des concepts couramment rencontrés dans les systèmes réels, les concepts introduits dans la description des systèmes ouverts constituent une abstraction. Il n’est donc pas nécessaire que les systèmes ouverts réels soient réalisés selon la description du modèle.

4.3.7 – Dans la suite de ce modèle de référence de base, seuls sont considérés les aspects des systèmes réels et des processus applicatifs relevant de l’environnement OSI. Leur interconnexion y sera représentée comme à la Figure 2.

4.3.8 – L’application du concept d’environnement OSI (OSIE), via l’utilisation de normes OSI, peut entraîner la partition de l’OSIE en sous-ensembles correspondant à des ensembles partiellement disjoints de systèmes ouverts réels qui n’ont pas la capacité physique de communication OSI.

5 – Concepts d’une architecture en couches

5.1 – Introduction

5.1.1 – L’article 5 définit les concepts architecturaux utilisés pour élaborer le modèle de référence OSI. Dans une première étape, il décrit le concept d’architecture en couches (couches, entités, points d’accès aux services, protocoles, connexions, etc.). Dans une deuxième étape, il présente les identificateurs d’entités, de points d’accès aux services, et de connexions. Dans une troisième étape, il décrit les points d’accès aux services et les unités de données. Dans une quatrième étape, il décrit les éléments de fonctionnement de couche, y compris les connexions, la transmission de données et les fonctions d’erreurs. Puis il présente les aspects relatifs à l’acheminement et traite enfin des aspects relatifs à la gestion.

5.1.2 – Les concepts décrits à l’article 5 sont ceux qui sont nécessaires à la description du modèle de référence OSI. Cependant, ces concepts ne sont pas tous utilisés dans chacune des couches du modèle de référence.

5.1.3 – Quatre éléments fondamentaux interviennent dans le modèle de référence (voir la Figure 2):

    a) les systèmes ouverts;

    b) les entités d’application se trouvant dans l’environnement d’OSI (voir 7.1);

    c) les associations (voir 5.3) reliant les entités d’application et leur permettant d’échanger de l’information;

    d) le support physique pour l’OSI.

NOTE – Les aspects relatifs à la sécurité, qui sont également des éléments généraux de l’architecture des protocoles, sont traités dans la Rec. X.800 du CCITT | ISO 7498-2.

5.2 – Principe de la structuration en couches

5.2.1 – Définitions

5.2.1.1 – sous-système (N): Elément d’une division hiérarchique d’un système ouvert qui n’interagit directement qu’avec les éléments du niveau immédiatement supérieur ou inférieur de cette division.

5.2.1.2 – couche (N): Subdivision de l’architecture OSI, constituée des sous-systèmes de rang (N).

5.2.1.3 – entités (N) homologues: Entités appartenant à la même couche (N).

5.2.1.4 – sous-couche: Subdivision d’une couche.

5.2.1.5 – service (N): Capacité fondamentale de la couche (N) et des couches inférieures à celle-ci, offerte aux entités (N+1) à la frontière entre la couche (N) et la couche (N+1).

5.2.1.6 – fonctionnalité (N): Elément d’un service (N).

5.2.1.7 – fonction (N): Elément de l’activité d’entités (N).

5.2.1.8 – point d’accès au service (N), SAP (service access point) (N): Point où les services (N) sont fournis par une entité (N) à une entité (N+1).

5.2.1.9 – protocole (N): Ensemble de règles et de formats (sémantiques et syntaxiques) déterminant le comportement de communication des entités (N) lorsqu’elles exécutent les fonctions (N).

5.2.1.10 – type d’entité (N): Description d’une classe d’entités (N) en termes d’ensemble de capacités définies pour la couche (N).

5.2.1.11 – entité (N): Elément actif dans un sous-système (N) comportant un ensemble de capacités définies pour la couche (N) et correspondant à un type donné d’entité (N) (sans que soient utilisées d’autres capacités).

5.2.1.12 – invocation d’entité (N): Utilisation particulière d’une partie ou de l’ensemble des capacités d’une entité (N) donnée (sans que soient utilisées d’autres capacités).

5.2.2 – Description

5.2.2.1 – La technique de structuration de base du modèle de référence OSI est la structuration en couches. Selon cette technique, on considère que chaque système ouvert est logiquement composé d’un ensemble ordonné de sous-systèmes qu’on représente par commodité dans l’ordre vertical comme le montre la Figure 3. Les sous-systèmes adjacents 
communiquent à travers leur frontière commune. L’ensemble des sous-systèmes de même rang (N) constitue la couche (N) du modèle de référence OSI. Dans un système ouvert, il existe un et un seul sous-système (N) pour la couche (N). Un sous-système (N) est constitué d’une ou de plusieurs entités (N). Il y a des entités dans chacune des couches. Les entités d’une même couche (N) sont appelées entités (N) homologues. A noter que la couche de niveau le plus élevé n’a pas de couche (N+1) au-dessus d’elle et que la couche de niveau le plus bas n’a pas de couche (N-1) au-dessous d’elle.

5.2.2.2 – Les entités (N) homologues n’ont pas toutes le besoin ou même la capacité de communiquer. Dans certaines conditions, cette communication peut être impossible (lorsque par exemple les entités homologues ne se trouvent pas dans des systèmes ouverts interconnectés, ou bien lorsqu’elles ne mettent pas en oeuvre les mêmes sous-ensembles de protocoles). La communication entre entités (N) homologues résidant dans le même sous-système (N) est assurée par l’environnement de système local et ne relève donc pas de l’OSI.

NOTES

1 – La distinction entre le type d’un objet et une instance de cet objet est pertinente dans le cadre de l’OSI. Un type est la description d’une classe d’objets. Une instance de ce type est un quelconque objet conforme à cette description. Les instances d’un même type constituent une classe. On peut faire référence à un type et à une instance quelconque de ce type par un nom qui leur est propre. Chaque instance dénommable et le type auquel cette instance appartient doivent porter des noms distinctifs.
Par exemple, lorsqu’un programmeur écrit un logiciel, il crée un type de quelque chose dont les instances seront créées chaque fois que ce programme sera appelé pour être exécuté sur un ordinateur. Ainsi, un compilateur FORTRAN est un type, et chaque fois qu’une copie de ce programme est appelée sur un équipement de traitement de données, on génère une instance de ce programme.
Le concept général d’instanciation s’applique à l’intérieur de l’OSI. Considérons ainsi une entité (N) dans le contexte OSI; là aussi cette entité a deux aspects: un type et un ensemble d’instances. Le type d’une entité (N) est défini par l’énumération de l’ensemble des fonctions de la couche (N) qu’elle est capable d’exécuter. Une instance de ce type d’entité (N) est une instance particulière de quelque chose qui, dans le système ouvert considéré et à l’occasion d’une communication donnée, effectue les fonctions de couche (N) auxquelles le type d’entité (N) fait appel. De ceci il découle que les entités (N) ont trait seulement aux propriétés d’une association entre entités (N) homologues, alors qu’une instance d’entité (N) a trait aux aspects dynamiques particuliers d’un échange effectif d’information.
Il est important de noter que, dans toutes les couches, il n’y a de communication effective qu’entre instances d’entités (N). En mode connexion (voir 5.3.3), c’est seulement au moment de l’établissement de la connexion (ou au moment équivalent lors d’une procédure de reprise) que des entités (N) interviennent explicitement. Une connexion réelle est toujours établie avec une instance spécifique d’entité (N), bien que la demande de connexion soit souvent adressée à une quelconque entité (N) (de type donné). Si une instance d’entité (N) connaît le nom de son instance d’entité (N) homologue, elle pourra demander une autre connexion avec cette instance d’entité (N).

2 – Il peut s’avérer nécessaire d’aller plus loin en divisant une couche en sous-structures limitées appelées sous-couches, et d’étendre la technique de stratification à d’autres aspects de l’OSI. Une sous-couche est définie comme un groupement des fonctions de couche pouvant être court-circuitées. Le court-circuitage de toutes les sous-couches d’une couche n’est pas autorisé. Une sous-couche utilise les entités et services de communication de sa couche. La définition détaillée et les caractéristiques additionnelles des sous-couches appellent un complément d’étude.

5.2.2.3 – Sauf pour la couche la plus élevée, chaque couche (N) fournit aux entités (N+1) de la couche (N+1) un service (N) au point SAP (N). Les propriétés des points SAP (N) sont décrites au 5.5. La couche la plus élevée est supposée représenter toutes les utilisations possibles des services fournis par les couches inférieures.
NOTE – Certains systèmes ouverts ne constituent ni la source initiale ni la destination finale des données. De tels systèmes ouverts n’ont pas besoin de comporter les couches supérieures de l’architecture (voir la Figure 12).

5.2.2.4 – Il est possible d’adapter chaque service fourni par une couche (N) par le choix d’une ou plusieurs fonctionnalités (N) qui en déterminent les attributs. Quand une entité (N) ne peut à elle seule assurer complètement un service demandé par une entité (N+1), elle fait appel à la coopération d’autres entités (N) pour l’aider à fournir le service demandé. Pour coopérer, les entités d’une couche (N) quelconque (sauf celles de la couche la plus basse) communiquent au moyen de l’ensemble des services fournis par la couche (N-1) (voir la Figure 4). On suppose que les entités de la couche la plus basse communiquent directement via le support physique qui les interconnecte.

5.2.2.5 – Les services d’une couche (N) sont fournis à la couche (N+1) grâce aux fonctions (N) effectuées à l’intérieur de la couche (N) et, si besoin est, à l’aide des services offerts par la couche (N-1).
NOTE – Ceci n’exclut pas le cas où aucune action de protocole n’est requise dans la couche (N) pour prendre en charge une fonctionnalité (N) donnée du fait que celle-ci est déjà disponible à la frontière de service (N-1). Cependant, une fonction nulle du protocole (N) complet n’est pas autorisée.

5.2.2.6 – Une entité (N) peut fournir des services à une ou plusieurs entités (N+1) et utiliser les services d’une ou de plusieurs entités (N-1). Un point d’accès aux services (N) est le point où deux entités situées dans des couches adjacentes, utilisent ou fournissent des services (voir la Figure 7).

5.2.2.7 – La coopération entre entités (N) est régie par un ou plusieurs protocoles (N). La Figure 5 représente les entités et protocoles d’une couche.

5.3 – Communication entre entités homologues

5.3.1 – Définitions

5.3.1.1 – association (N): Relation de coopération entre invocations d’entités (N).

5.3.1.2 – connexion (N): Association demandée par une entité (N+1) pour le transfert de données entre deux entités (N+1) ou plus. L’association est établie par la couche (N); elle identifie explicitement une série de transmissions de données (N) et fixe l’accord concernant les services de transmission de données (N) à fournir pour cette série.

5.3.1.3 – extrémité de connexion (N): Terminaison d’une connexion (N) en un point d’accès aux services (N).

5.3.1.4 – connexion multipoint: Connexion comportant plus de deux extrémités de connexion.

5.3.1.5 – entités (N) correspondantes: Entités (N) reliées par une connexion (N-1).

5.3.1.6 – relais (N): Fonction (N) au moyen de laquelle une entité (N) retransmet à une autre entité homologue (N) les données reçues d’une entité homologue (N).

5.3.1.7 – source de données (N): Entité (N) qui envoie des unités de données de service (N-1) (voir 5.1.6.7) sur une connexion (N-1).2)

5.3.1.8 – puits de données (N): Entité (N) recevant des unités de données de service (N-1) sur une connexion (N-1).2)

5.3.1.9 – transmission de données (N): Fonctionnalité (N) transportant des unités de données de service (N) d’une entité (N+1) à une ou plusieurs entités (N+1).

5.3.1.10 – transmission duplex (N): Transmission de données (N) simultanément dans les deux sens.2)

5.3.1.11 – transmission semi-duplex (N): Transmission de données (N) dans un sens ou dans l’autre alternativement, le sens de transmission étant contrôlé par une entité (N+1).2)

5.3.1.12 – transmission simplex (N): Transmission de données (N) dans un seul sens fixé à l’avance.2)

5.3.1.13 – communication de données (N): Fonction (N) transférant des unités de données de protocole (N) (voir 5.6.1.3) conformément à un protocole (N) sur une ou plusieurs connexions (N-1).2)

5.3.1.14 – communication bilatérale simultanée (N): Communication de données (N) dans les deux sens à la fois.

5.3.1.15 – communication bilatérale à l’alternat (N): Communication de données (N) dans un sens ou dans l’autre, alternativement.

5.3.1.16 – communication unilatérale (N): Communication de données (N) dans un seul sens fixé à l’avance.

5.3.1.17 – transmission en mode connexion (N): Transmission de données (N) dans le contexte d’une connexion (N).

5.3.1.18 – transmission en mode sans connexion (N): Transmission de données (N) hors du contexte d’une connexion (N) et qui n’est pas tenue de maintenir une quelconque relation logique entre les unités de données de service (N).

5.3.2 – Description

5.3.2.1 – Pour pouvoir échanger des informations entre deux entités (N+1) ou plus, il faut établir entre elles une association dans la couche (N) à l’aide d’un protocole (N).
NOTE – Des classes de protocoles peuvent être définies au sein des protocoles (N).

5.3.2.2 – Les règles et les formats d’un protocole (N) sont instanciés dans un sous-système (N) par une entité (N). Une entité (N) peut prendre en charge un ou plusieurs protocoles (N). Des entités (N) peuvent prendre en charge des protocoles (N) en mode connexion, en mode sans connexion, ou les deux. Les entités (N) prenant en charge le mode connexion maintiennent les connexions (N) avec les entités (N+1) appropriées aux points d’accès aux services (N) correspondants. Les entités (N) prenant en charge le mode sans connexion maintiennent un lien avec les points d’accès aux services (N) appropriés pour remettre les données en mode sans connexion aux entités (N+1).

5.3.2.3 – Les entités (N+1) ne peuvent communiquer qu’en se servant des services de la couche (N). Dans certaines circonstances, les services fournis par la couche (N) ne permettent pas des liaisons directes entre toutes les entités (N+1) ayant à communiquer. Dans ce cas, la communication peut néanmoins avoir lieu si d’autres entités (N+1) peuvent remplir la fonction de relais entre elles (voir la Figure 6).

5.3.2.4 – Le fait qu’une communication soit relayée par une chaîne d’entités (N+1) n’est connu ni de la couche (N), ni de la couche (N+2).

5.3.3 – Modes de communication

5.3.3.1 – Introduction

5.3.3.1.1 – Une couche (N) peut offrir à la couche (N+1) un service en mode connexion, un service en mode sans connexion, ou les deux, en utilisant le ou les services fournis par la couche (N-1). Toute instance de transmission entre entités (N+1) doit utiliser un même mode de service (N).

5.3.3.1.2 – Les services (N) en mode connexion et en mode sans connexion se caractérisent tous deux par les fonctionnalités qu’ils offrent aux entités (N+1) et par la qualité de service perçue par celles-ci. Tant en mode connexion qu’en mode sans connexion, la couche (N) peut fournir des fonctions destinées à améliorer les fonctionnalités offertes aux entités (N+1) et la qualité de service perçue par celles-ci par rapport aux fonctionnalités offertes à la couche (N) par la couche (N-1) et, si nécessaire, pour passer d’un mode de service à l’autre.

5.3.3.1.3 – Etant donné que les concepts de transmission en mode sans connexion et en mode connexion sont complémentaires, on les comprend mieux en les juxtaposant, surtout que la transmission en mode sans connexion est plus facilement définie par référence au concept de connexion.

5.3.3.1.4 – Afin que des entités (N+1) puissent communiquer au moyen d’un service (N) en mode connexion ou en mode sans connexion, il est essentiel qu’existe entre elles une association prédéterminée consistant en une connaissance préalable que chaque entité (N+1) doit impérativement avoir des autres afin d’être au moins en mesure d’initialiser l’utilisation du service. Cette association, qui est établie d’une manière qui n’est pas explicitée dans ce modèle de référence de base, comprend quatre éléments:

    a) la connaissance des adresses des entités (N) homologues concernées;

    b) la connaissance d’un protocole agréé par les entités (N) homologues afin de l’utiliser au moins pour l’établissement de la communication;

    c) la connaissance de la disponibilité des entités (N) homologues pour la communication;

    d) la connaissance de la qualité de service offerte par le service (N).

NOTE – On peut acquérir de plusieurs façons cette connaissance préalable qui constitue une association prédéterminée entre entités; on trouvera ci-dessous quelques exemples:

    a) à partir d’informations acquises manuellement à la passation des contrats avec un fournisseur de service;

    b) à partir d’informations qu’une administration de réseau peut fournir dans un annuaire ou une base de données consultable;

    c) à partir d’informations apprises au cours d’instances de communication antérieures;

    d) à partir d’informations fournies dynamiquement par la mise en oeuvre de protocoles de gestion-système.

La connaissance globale préalable correspondant à une association prédéterminée entre entités sera vraisemblablement acquise par une combinaison des moyens ci-dessus.

5.3.3.2 – Mode connexion

5.3.3.2.1 – Une connexion est une association établie pour le transfert de données entre deux entités (N) homologues ou plus. Cette association lie les entités (N) homologues aux entités (N-1) de la couche immédiatement inférieure. La capacité d’établir et de libérer une connexion et de transférer des données sur elle est conférée aux entités (N) dans une couche (N) donnée par la couche qui lui est immédiatement inférieure en tant que service en mode connexion. 

L’utilisation d’un service en mode connexion par des entités (N) homologues passe par trois phases distinctes:

    a) l’établissement de la connexion;

    b) le transfert de données; et

    c) la libération de la connexion.

5.3.3.2.2 – Outre la durée clairement délimitée par ces phases, une connexion possède les caractéristiques fondamentales suivantes:

    a) elle implique l’établissement et le maintien d’un accord à deux parties ou plus relatif à la transmission de données entre les entités (N) homologues concernées, en utilisant le fournisseur de service (N-1);

    b) elle permet la négociation, entre toutes les parties concernées, des paramètres et options qui régiront la transmission de données;

    c) elle assure l’identification de la connexion, ce qui permet d’éviter, dans les transferts de données, les surplus de traitement correspondant à la transmission des adresses et à leur résolution;

    d) elle fournit un contexte dans lequel les unités de données successives transmises entre entités homologues sont rattachées logiquement, ce qui permet d’en préserver l’ordre de succession et d’en contrôler le flux.

5.3.3.2.3 – Les caractéristiques de la transmission en mode connexion sont particulièrement intéressantes pour les applications qui nécessitent des interactions d’une durée relativement longue et en mode flux entre entités en configuration stable. On citera en exemple l’utilisation en temps réel d’un ordinateur distant à partir d’un terminal, le transfert de fichiers et le raccordement permanent de stations de télétraitement. Dans ces cas-là, les entités concernées discutent d’abord de leurs exigences et s’accordent sur les termes de leur interaction, réservent toutes les ressources dont elles pourront avoir besoin, transfèrent une série d’unités de données nécessaires pour atteindre leur objectif commun, mettent fin explicitement à leur interaction et libèrent les ressources préalablement réservées. Les propriétés de la transmission en mode connexion s’appliquent également à toute une gamme d’autres applications.

5.3.3.2.4 – La transmission en mode connexion est réalisée par l’utilisation de connexions (N). Les connexions (N) sont établies par la couche (N) entre deux points d’accès aux services (N) ou plus. La terminaison d’une connexion (N) à un point d’accès aux services (N) est appelée extrémité de connexion (N). Une connexion (N) est établie par la couche (N) entre deux points d’accès aux services (N) ou plus à la demande d’une entité (N+1) appelante assurant le support des entités (N+1) attachées aux points d’accès aux services (N) impliqués dans la connexion (N). Une connexion (N) comportant plus de deux extrémités est appelée connexion multipoint. Les entités (N) connectées entre elles sont appelées entités (N) correspondantes.

NOTE – Le transfert de données par un service (N) en mode connexion implique préalablement l’établissement d’une connexion (N). Celle-ci met en place dynamiquement une association entre les entités (N+1) et le service (N) en mode connexion en plus de l’association décrite au 5.3.2. Cette association met en jeu des éléments qui ne font pas partie de l’association prédéterminée décrite au 5.3.3.1.4, en particulier:

    a) la connaissance de l’intention de la ou des entités (N) homologues d’établir une communication donnée et de l’intention du service sous-jacent d’en assurer la prise en charge;

    b) la capacité des entités (N) homologues à négocier et renégocier les caractéristiques de la communication.

5.3.3.3 – Mode sans connexion

5.3.3.3.1 – La transmission en mode sans connexion est la transmission d’une seule unité de données d’un point d’accès au service source vers un ou plusieurs points d’accès au service destination sans établir de connexion. Un service en mode sans connexion permet à une entité de déclencher une telle transmission en utilisant un seul accès au service.

5.3.3.3.2 – Contrairement à une connexion, une instance d’utilisation d’un service en mode sans connexion n’a pas de durée de vie clairement établie. Elle possède en outre les caractéristiques fondamentales suivantes:

    a) elle nécessite uniquement une association prédéterminée entre les entités (N) homologues concernées qui détermine les caractéristiques des données à transmettre, et ne fait intervenir aucun accord dynamique;

    b) toutes les informations requises pour remettre une unité de données – adresse de destination, sélection de la qualité de service, options, etc. – sont présentées à la couche qui fournit le service en mode sans connexion, en même temps que l’unité de données à transmettre, dans un accès unique au service. La couche qui fournit le service en mode sans connexion n’est pas tenue de mettre en relation cet accès avec un quelconque autre accès.

5.3.3.3.3 – Compte tenu de ces caractéristiques fondamentales, il peut également s’avérer que:

    a) chaque unité de données transmise est acheminée indépendamment par la couche qui fournit le service en mode sans connexion;

    b) des copies d’une unité de données peuvent être transmises vers plusieurs adresses de destination.

5.3.3.3.4 – Ces caractéristiques de transmission en mode sans connexion n’excluent pas de mettre à la disposition de l’utilisateur du service des informations sur la nature et la qualité du service correspondant à une seule instance du service ou observable sur une succession d’instances du service entre deux points d’accès au service (N) ou un ensemble de ces points.

5.3.3.3.5 – Pour chaque couche, les paragraphes de l’article 7 identifient les éléments relevant du service en mode sans connexion fourni par cette couche.

5.3.3.3.6 – Le service (N) de base en mode sans connexion est un service qui remplit les conditions suivantes:

    a) aucune contrainte de seuil minimal n’est imposée en matière de mesure de qualité de service; en particulier il n’est pas nécessaire de préserver l’ordonnancement des unités de données de service (N);

    b) aucune capacité de contrôle de flux homologue n’est imposée.

5.3.3.3.7 – Toute définition d’un service (N) en mode sans connexion doit permettre d’assurer ce service de base.

5.3.3.3.8 – Comme le service de base n’est pas tenu de préserver le séquencement des unités de données de service (N), aucune couche (N) n’est tenue d’assurer des fonctions de séquencement. Cependant, dans les réalisations pratiques, les caractéristiques du support sous-jacent ou des sous-réseaux réels peuvent offrir une forte probabilité de remise des unités en séquence, ce qui peut se refléter dans les caractéristiques des services en mode sans connexion offerts par les couches supérieures.

5.3.3.3.9 – Une entité (N+1) ne fournit au fournisseur d’un service (N) en mode sans connexion aucune information concernant les relations logiques entre les unités de données de service (N), à part les adresses des points d’accès au service (N) source et de destination.

5.3.3.3.10 – Du point de vue de l’entité (N+1), cela signifie qu’elle ne peut pas demander au service (N) d’appliquer une fonction particulière à une séquence d’unités de données de service (N) qu’elle envoie. Cependant, du point de vue de la couche (N), cela n’implique aucune contrainte sur les fonctions qui assurent le support du service.

5.3.3.3.11 – Les entités (N+1) peuvent communiquer en utilisant un service (N) en mode sans connexion à condition qu’il y ait une association prédéterminée entre elles leur fournissant une connaissance les unes des autres et leur permettant de réaliser une telle communication. Cette connaissance doit permettre de localiser les entités (N+1), de déterminer l’interprétation correcte des unités de données de service (N) par l’entité (N+1) destinataire, et peut également définir les vitesses de transfert, les vitesses de réponse et le protocole d’échange utilisé. La connaissance peut provenir d’un accord préalable entre les entités (N+1) sur les paramètres, formats et options à utiliser.

5.3.3.3.12 – Afin de choisir un protocole (N+1) de communication sur un service (N) en mode sans connexion, les entités (N+1) peuvent nécessiter une connaissance préalable des fonctionnalités offertes par ce service et la qualité de service qu’elles peuvent en attendre.

5.3.4 – Relation entre services assurés aux limites de couches adjacentes

5.3.4.1 – Aucune contrainte architecturale n’est imposée quant aux combinaisons verticales possibles d’une couche (N) fournissant un service (N) d’un type donné (mode connexion ou mode sans connexion) et s’appuyant sur un service
(N-1) d’un type quelconque. En principe, les services aux limites inférieure et supérieure d’une couche peuvent être:

    a) tous deux en mode connexion;

    b) tous deux en mode sans connexion;

    c) le service (N) en mode connexion et le service (N-1) en mode sans connexion;

    d) le service (N) en mode sans connexion et le service (N-1) en mode connexion.

5.3.4.2 – Afin de permettre les combinaisons c) et d) ci-dessus, deux éléments architecturaux sont nécessaires:

    a) une fonction pour fournir un service (N) en mode connexion en utilisant un service (N-1) en mode sans connexion;

    b) une fonction pour fournir un service (N) en mode sans connexion en utilisant un service (N-1) en mode connexion.

Ces fonctions sont des fonctions de conversion de mode.

NOTE – Parmi ces deux fonctions, la fonction a) nécessite des informations de contrôle protocolaires significatives. Par 
exemple, il est nécessaire d’identifier la connexion qui est établie, d’en commander l’état et d’assurer le séquencement des unités de données de service. La fonction b) nécessite peu ou pas d’information additionnelle de contrôle de protocole; par contre, elle impose des contraintes sur la façon d’utiliser le service en mode connexion.

5.3.5 – Application des fonctions de conversion de mode

5.3.5.1 – Les fonctions de conversion peuvent être utilisées dans des systèmes OSI d’extrémité ou de relais (voir 6.5). Dans le dernier cas, les fonctions de conversion de mode peuvent: 

    a) soit relier un protocole (N) utilisant le service (N-1) en mode sans connexion, et un protocole (N) utilisant le service (N-1) en mode connexion, pour assurer un service (N) en mode connexion;

    b) soit relier un protocole (N) utilisant le service (N-1) en mode sans connexion, et un protocole (N) utilisant le service (N-1) en mode connexion, pour assurer un service (N) en mode sans connexion.

5.3.5.2 – L’utilisation des conversions de mode entre services (N-1) dans une couche n’est pas soumise à des contraintes explicites par le modèle de référence mais, lorsque plusieurs services (N-1) sont connectés en cascade, l’utilisation des conversions de mode devra être organisée de manière à minimiser le nombre de conversions de mode nécessaires à la réalisation du service (N) composite donné.

5.3.5.3 – Lorsqu’un service (N-1) en mode sans connexion est utilisé pour fournir un service (N) en mode connexion, un certain nombre de connexions (N) peuvent être prises en charge par la transmission (N-1) en mode sans connexion entre les mêmes points d’accès au service (N-1).

5.3.5.4 – Lorsqu’un service (N-1) en mode connexion est utilisé pour fournir un service (N) en mode sans connexion, la transmission (N) en mode sans connexion entre un certain nombre de points d’accès au service (N) différents peut être prise en charge par la même connexion (N-1).

5.4 – Identificateurs

5.4.1 – Définitions

5.4.1.1 – adresse (N): Nom non ambigu dans l’environnement OSI, utilisé pour identifier un ensemble de points d’accès aux services (N) tous situés à la frontière entre un sous-système (N) et un sous-système (N+1) d’un même système ouvert.

NOTE – Un nom est non ambigu dans un domaine de visibilité donné quand il identifie un et un seul objet dans ce domaine. La non-ambiguïté d’un nom n’interdit pas l’existence de synonymes.

5.4.1.2 – adresse de point d’accès au service (N); adresse de SAP (N): Adresse (N) utilisée pour identifier un seul SAP (N).

5.4.1.3 – correspondance d’adresse (N): Fonction (N) mettant en correspondance les adresses (N) et les adresses
(N-1) associées à une entité (N).

5.4.1.4 – acheminement: Fonction d’une couche traduisant le titre d’une entité ou l’adresse du point d’accès au service auquel l’entité est rattachée en un chemin permettant d’atteindre l’entité.

5.4.1.5 – identificateur d’extrémité de connexion (N): Identificateur de l’extrémité d’une connexion (N) destiné à identifier, en un point d’accès aux services (N), la connexion (N) correspondante.

5.4.1.6 – suffixe d’extrémité de connexion (N): Elément d’identificateur d’extrémité de connexion (N), unique dans le contexte d’un point d’accès aux services (N).

5.4.1.7 – identificateur d’extrémité de connexion multipoint: Identificateur spécifiant l’extrémité d’une connexion multipoint qui doit accepter les données transférées.

5.4.1.8 – identificateur de connexion de service (N): Identificateur spécifiant de manière unique une connexion (N) dans le contexte des entités (N+1) correspondantes.

5.4.1.9 – identificateur de connexion de protocole (N): Identificateur spécifiant de manière unique une connexion (N) dans le contexte d’une connexion (N-1) multiplexée.

5.4.1.10 – titre d’entité (N): Nom utilisé pour identifier sans ambigüité une entité (N).

5.4.2 – Description

5.4.2.1 – Une adresse de point d’accès aux services (N) identifie le point particulier d’accès au service (N) auquel une entité (N+1) est rattachée (voir la Figure 7). Quand cette entité (N+1) est détachée du point d’accès aux services (N), l’adresse SAP (N) ne donne plus accès à l’entité (N+1). Si le point d’accès aux services (N) est rattaché ensuite à une autre entité (N+1), alors l’adresse SAP (N) identifie la nouvelle entité (N+1) et non plus l’ancienne.

5.4.2.2 – L’utilisation d’une adresse SAP (N) pour identifier une entité (N+1) est le mécanisme le plus efficace si la permanence du lien entre l’entité (N+1) et le point d’accès aux services (N) peut être assurée.

5.4.2.3 – L’interprétation de la correspondance entre les adresses (N) desservies par une entité (N) et les adresses (N-1) qu’elle utilise pour accéder aux services (N-1) est assurée par une fonction de correspondance d’adresses (N).

5.4.2.4 – La structure d’une adresse (N) est connue de l’entité (N) reliée au point d’accès aux services (N) identifié. Mais l’entité (N+1) n’a pas connaissance de cette structure.

5.4.2.5 – Si une entité (N+1) accède par deux points d’accès aux services (N) ou plus à une même entité (N) ou à différentes entités (N), les entités (N) n’en ont pas connaissance. Vu des entités (N), chaque point d’accès aux services (N) est considéré comme identifiant une entité (N+1) différente.

5.4.2.6 – Une fonction d’acheminement traduit l’adresse (N) d’une entité (N+1) en un chemin, ou route, permettant d’atteindre l’entité (N+1).

5.4.2.7 – Une entité (N+1) peut établir une connexion (N) avec une autre entité (N+1) à l’aide d’un service (N). Quand une entité (N+1) établit une connexion (N) avec une autre entité (N+1), chaque entité (N+1) se voit attribuer un identificateur d’extrémité de connexion (N) par l’entité (N) qui la sert. L’entité (N+1) peut ainsi distinguer la nouvelle connexion de toutes les autres connexions (N) accessibles à partir du point d’accès aux services (N) qu’elle utilise. Cet identificateur d’extrémité de connexion (N) doit être unique dans le contexte de l’entité (N+1) utilisatrice de la connexion (N).

5.4.2.8 – L’identificateur d’extrémité de connexion (N) comporte deux parties:

    a) l’adresse du point d’accès aux services (N) associée à la connexion (N);

    b) un suffixe d’extrémité de connexion (N), unique dans le contexte du point d’accès aux services (N).

5.4.2.9 – Une connexion multipoint nécessite des identificateurs d’extrémités de connexion multipoint. Chacun de ces identificateurs sert à désigner l’extrémité de connexion qui devra accepter les données transférées. Un identificateur d’extrémité de connexion multipoint sera unique dans le contexte de la connexion pour laquelle il est utilisé.

5.4.2.10 – La couche (N) peut fournir aux entités (N+1) un identificateur de connexion de service (N) spécifiant de manière unique la connexion (N) dans le contexte des entités (N+1) correspondantes.

5.5 – Propriétés des points d’accès aux services

5.5.1 – Une entité (N+1) demande un service (N) via un point d’accès aux services (N) qui permet à cette entité (N+1) d’interagir avec une entité (N).

5.5.2 – Les entités (N) et (N+1) rattachées à un même point d’accès aux services (N) appartiennent au même système.

5.5.3 – Une entité (N+1) peut être en même temps rattachée à un ou plusieurs points d’accès aux services (N) reliés à une même entité (N) ou à des entités (N) différentes.

5.5.4 – Une entité (N) peut être rattachée en même temps à une ou plusieurs entités (N+1) via des points d’accès aux services (N).

5.5.5 – Un point d’accès aux services (N) est relié à une seule entité (N) et à une seule entité (N+1) à la fois.

5.5.6 – Un point d’accès aux services (N) peut être détaché d’une entité (N+1) pour être rattaché ensuite à la même entité (N+1) ou à une autre entité (N+1).

5.5.7 – Un point d’accès aux services (N) peut être détaché d’une entité (N) pour être rattaché ensuite à la même entité (N) ou à une autre entité (N).

5.5.8 – Un point d’accès aux services (N) est localisé par son adresse SAP (N). Une entité (N+1) se sert d’une adresse SAP (N) pour demander une instance de communication.

5.5.9 – Un point d’accès au service (N) peut prendre en charge:

    a) des services (N) en mode connexion uniquement;

    b) des services (N) en mode sans connexion uniquement;

    c) des services (N) en mode connexion et des services (N) en mode sans connexion en même temps.

5.5.10 – Une même entité (N+1) peut utiliser simultanément plusieurs connexions (N) et un service (N) en mode sans connexion via un ou plusieurs points d’accès au service (N) auxquels elle est rattachée.

5.5.11 – Les entités (N+1) distinguent les instances de service (N) en mode sans connexion des instances de service (N) en mode connexion proposées en même temps via le même point d’accès au service (N) grâce à l’unicité des interactions prescrites pour ces services.

5.6 – Unités de données

5.6.1 – Définitions

5.6.1.1 – information de contrôle protocolaire (N): Information échangée entre entités (N), pour coordonner leur travail commun.

5.6.1.2 – données d’utilisateur (N): Données transférées entre entités (N) pour le compte d’entités (N+1) qu’elles desservent.

5.6.1.3 – unité de données de protocole (N): Unité de données spécifiée dans un protocole (N) et comportant des informations de contrôle protocolaires (N) et, éventuellement, des données d’utilisateur (N).

5.6.1.4 – unité de données de service (N): Informations dont l’identité est préservée pendant leur transfert entre entités (N+1) homologues, et qui ne sont pas interprétées par les entités (N).

5.6.1.5 – unité de données exprès de service (N); unité de données exprès (N): Petite unité de données de service (N) dont le transfert est effectué en exprès. La couche (N) veille à ce qu’une unité de données exprès ne soit pas remise après une autre unité de données de service, ni après une autre unité exprès envoyée ultérieurement sur la même connexion.

5.6.2 – Description

5.6.2.1 – L’information est transférée entre entités (N) homologues sous forme d’unités de données de divers types. Ces unités de données sont définies au 5.6, et les relations existant entre elles sont représentées aux Figures 8 et 9.

5.6.2.2 – Sauf en ce qui concerne les relations définies aux Figures 8 et 9, l’architecture n’impose aucune limitation générale à la taille des unités de données. Mais des limitations de taille peuvent exister dans des couches particulières.

5.6.2.3 – Les données peuvent être conservées dans une connexion jusqu’à ce que la totalité d’une unité de données de service ait été émise sur cette connexion.

5.7 – Nature du service (N)

5.7.1 – Un service (N) n’impose pas nécessairement de limite à la taille des SDU (N). Par contre, la spécification du protocole (N) peut imposer une limite à la taille des PDU (N). Le groupage, la segmentation et la concaténation sont utilisés pour compenser les différences de taille limite entre les unités SDU et les unités PDU correspondantes.

5.8 – Eléments de fonctionnement d’une couche

5.8.1 – Définitions

5.8.1.1 – identificateur de protocole (N): Identificateur utilisé entre entités (N) correspondantes pour sélectionner un protocole (N) particulier.

5.8.1.2 – connexion multipoint centralisée: Connexion multipoint dans laquelle les données envoyées par l’entité associée à l’extrémité centrale de la connexion sont reçues par toutes les autres unités, alors que les données envoyées par une entité périphérique ne sont reçues que par l’entité centrale.

5.8.1.3 – connexion multipoint décentralisée: Connexion multipoint dans laquelle les données envoyées par une entité associée à n’importe quelle extrémité de la connexion sont reçues par toutes les autres entités.

5.8.1.4 – multiplexage: Fonction accomplie par une entité (N) permettant à une seule connexion (N-1) de prendre en charge plusieurs connexions (N).

NOTE – Le terme multiplexage est également utilisé dans un sens plus restrictif pour désigner la fonction accomplie par l’entité (N) expéditrice, alors que le terme démultiplexage sert à désigner la fonction accomplie par l’entité (N) destinataire.

5.8.1.5 – démultiplexage: Fonction accomplie par une entité (N) qui identifie les unités de données de protocole (N) correspondant à plusieurs connexions (N) parmi les unités de données de service (N-1) reçues sur une même connexion (N-1). C’est la fonction inverse de la fonction de multiplexage accomplie par l’entité (N) qui envoie les unités de données de service (N-1).

5.8.1.6 – éclatement: Fonction de la couche (N) permettant d’utiliser plusieurs connexions (N-1) pour prendre en charge une connexion (N).

NOTE – Le terme éclatement est également utilisé dans un sens plus restrictif pour désigner la fonction accomplie par l’entité (N) expéditrice, le terme recombinaison servant à désigner la fonction accomplie par l’entité (N) destinataire.

5.8.1.7 – recombinaison: Fonction accomplie par une entité (N) identifiant des unités de données de protocole (N) correspondant à une même connexion (N) parmi des unités de données de service (N-1) reçues sur plusieurs connexions (N-1). C’est la fonction inverse de la fonction d’éclatement accomplie par l’entité (N) qui envoie les unités de données de service (N-1).

5.8.1.8 – contrôle de flux: Fonction contrôlant le flux des données au sein d’une couche ou entre couches adjacentes.

5.8.1.9 – segmentation: Fonction accomplie par une entité (N) pour projeter une unité de données de service (N) sur plusieurs unités de données de protocole (N).

5.8.1.10 – réassemblage: Fonction accomplie par une entité (N) pour projeter plusieurs unités de données de protocole (N) sur une unité de données de service (N). C’est la fonction inverse de la fonction de segmentation.

5.8.1.11 – groupage: Fonction accomplie par une entité (N) pour projeter plusieurs unités de données de service (N) sur une unité de données de protocole (N).

5.8.1.12 – dégroupage: Fonction accomplie par une entité (N) pour identifier plusieurs unités de données de service (N) contenues dans une unité de données de protocole (N). C’est la fonction inverse de la fonction de groupage.

5.8.1.13 – concaténation: Fonction accomplie par une entité (N) pour projeter plusieurs unités de données de protocole (N) sur une unité de données de service (N-1).

NOTE – Le groupage et la concaténation, bien que similaires (ils permettent tous deux de grouper des unités de données) servent à des fins différentes. Par exemple, la concaténation permet à la couche (N) de grouper une ou plusieurs unités PDU (N) d’accusé de réception avec une ou plusieurs unités PDU (N) contenant des données d’utilisateur, ce que la fonction de groupage ne peut pas réaliser. A noter que ces deux fonctions peuvent être combinées permettant à la couche (N) d’effectuer des groupages et des concaténations.

5.8.1.14 – séparation: Fonction accomplie par une entité (N) pour identifier plusieurs unités de données de protocole (N) contenues dans une unité de données de service (N-1). C’est la fonction inverse de la fonction de concaténation.

5.8.1.15 – séquencement: Fonction assurée par la couche (N) pour conserver l’ordre des unités de données de service (N) remises à la couche (N).

5.8.1.16 – accusé de réception: Fonction de la couche (N) permettant à une entité (N) réceptrice d’informer l’entité (N) expéditrice de la réception d’une unité de données de protocole (N).

5.8.1.17 – réinitialisation: Fonction mettant les entités (N) correspondantes à un état prédéfini, avec possibilité de perte ou de duplication de données.

5.8.1.18 – identificateur de version de protocole (N): Identificateur véhiculé entre entités (N) correspondantes permettant de sélectionner la version d’un protocole (N).

NOTE – La définition d’un nouvel identificateur de version de protocole (N) suppose une connaissance minimale commune du protocole (N) identifié par le précédent identificateur de version de protocole. Quand cette connaissance minimale commune ne peut être obtenue, les protocoles (N) sont considérés comme étant différents et indépendants.

5.8.2 – Sélection et identification du protocole

5.8.2.1 – L’identification d’un protocole est le processus de détermination du type de protocole utilisé.

5.8.2.2 – Un ou plusieurs protocoles (N) peuvent être définis pour la couche (N). Une entité (N) peut utiliser un ou plusieurs protocoles (N).

5.8.2.3 – Pour qu’une communication entre entités (N) ait un sens, il faut qu’elles s’accordent sur le choix d’un protocole (N).

5.8.2.4 – Les identificateurs de protocoles (N) désignent les différents protocoles (N) définis. Un identificateur de protocole (N+1) ne peut faire partie d’une information de commande protocolaire PCI (N). Ainsi, un service (N) utilise des adresses (N) pour identifier un protocole (N+1) comme le décrit la Rec. X.650 | ISO 7498-3.

5.8.2.5 – Puisque les protocoles (OSI ou non OSI) ne sont pas tous censés porter un identificateur de protocole (N), un tel identificateur ne peut pas être utilisé pour distinguer les protocoles OSI des protocoles non OSI. Le mécanisme approprié dans ce cas est d’utiliser une adresse (N).

5.8.3 – Sélection et identification des versions de protocole

5.8.3.1 – Identification de la version de protocole

5.8.3.1.1 – L’identification de la version de protocole est un mécanisme qui permet d’identifier le niveau du protocole utilisé. L’identification de la version de protocole suppose que le protocole lui-même a été identifié soit implicitement soit au moyen de mécanismes approuvés.

5.8.3.1.2 – Dans de nombreux cas, il peut être commode de disposer d’un identificateur de sous-version à véhiculer sur une information PCI (N) avec l’identificateur de la version de protocole (N). Ceci permet de garder la trace des évolutions mineures d’une version de protocole donnée (afin de déterminer par exemple la prise en compte des rapports de défectuosités, etc.). La décision d’introduire ou non un tel identificateur de sous-version relève des normes propres à la couche (N). Toutefois, seul l’identificateur de version de protocole (N) est pris en compte pour déterminer si la communication est possible ou non entre entités (N) homologues, et ce, indépendamment de tout identificateur complémentaire de sous-version.

5.8.3.2 – Besoin d’une nouvelle version de protocole

5.8.3.2.1 – Le besoin d’une nouvelle version de protocole découle de modifications apportées au protocole. Ces modifications peuvent être: 

    a) un ajout de nouvelles fonctions (c’est-à-dire: de fonctions qui ne sont pas définies dans les spécifications de protocole existantes);

    b) une suppression de fonctions existantes (c’est-à-dire: de fonctions qui étaient définies dans les spécifications de protocole existantes);

    c) une modification de fonctions existantes;

    d) une substitution permettant d’assurer des fonctions existantes par d’autres moyens.

5.8.3.2.2 – Les modifications apportées à un protocole ne signifieront pas toujours qu’il faille le considérer comme une nouvelle version (ou un nouveau protocole). Une nouvelle version de protocole (ou un nouveau protocole) devient nécessaire lorsque ces modifications conduisent à un changement fonctionnel significatif dont la compatibilité ne peut pas être négociée dans le cadre des spécifications de protocole existantes, de sorte qu’un système ouvert réel qui utiliserait les fonctions protocolaires nouvelles ne pourrait pas communiquer avec un système ouvert réel utilisant les anciennes.

5.8.3.2.3 – Dans ce cas, si les deux ensembles de fonctions protocolaires reconnaissent les mêmes mécanismes d’identification de versions de protocole (par exemple: transfert, codage, négociation des identificateurs de versions de protocole), on considère qu’il s’agit de deux versions différentes du même protocole; sinon, ce sont deux protocoles différents.

NOTES

    1 Il est important de noter que des modifications fonctionnelles significatives ne sont pas toujours associées à la modification des éléments de protocoles échangés par un couple d’entités [par exemple, modification du comportement d’une entité (N) suite à l’introduction de services transparents].
    2 A noter également que les nouvelles versions de protocole ne sont pas directement liées au processus administratif de révision des normes existantes. Un tel processus peut conduire ou non à une nouvelle version de protocole selon l’importance des modifications apportées.

5.8.3.3 – Mécanismes de négociation

5.8.3.3.1 – La négociation de la version de protocole ne peut avoir lieu que dans une communication en mode connexion. Un champ d’identificateur de version du protocole (N) doit être inclus dans les unités PDU d’établissement de connexion. Le mécanisme permettant l’identification de versions de protocole consiste à déterminer, grâce à l’identificateur de version de protocole (N), quelle version doit être invoquée sur une connexion spécifique entre les entités (N) appelante et appelée.

5.8.3.3.2 – Une entité (N) appelante informe l’entité (N) appelée de toutes les versions qu’elle prend en charge. L’entité (N) appelée regarde s’il y en a qui sont communes aux entités (N) appelante et appelée. S’il existe plus d’une version commune, c’est la plus récente qui est choisie. S’il n’y a pas de version commune, la demande d’établissement de connexion est refusée.

5.8.3.3.3 – S’il est présent, l’identificateur de sous-version n’est pas utilisé par les mécanismes de négociation.

5.8.3.3.4 – Dans les protocoles en mode sans connexion, il n’est pas prévu de mécanisme de négociation. L’identification de la version de protocole est soit implicite (connue a priori par exemple), soit explicitement véhiculée par les unités PDU.

5.8.4 – Propriétés de la transmission en mode sans connexion

5.8.4.1 – Toutes les informations requises par un service (N) en mode sans connexion pour remettre une unité de données de service (N) (adresse de destination, qualité de service requise, options, etc.) lui sont présentées avec l’unité de données de service (N) au cours d’un accès logique unique au service par l’entité (N+1) émettrice.

5.8.4.2 – Toutes les informations portant sur une unité de données de service (N), ainsi que l’unité de données de service (N) elle-même, sont reçues du service (N) au cours d’un accès logique unique au service par l’entité (N+1) destinataire.

5.8.4.3 – Pour fournir le service (N) en mode sans connexion, la couche (N) effectue les fonctions décrites au 5.3.3.3. Ces fonctions sont prises en charge par des protocoles (N).

5.8.4.4 – Si une entité (N+1) ne peut accepter une unité de données de service (N) au moment où celle-ci parvient à un point d’accès au service (N), elle peut activer le contrôle de flux à la frontière du service (voir 5.8.8.4). Il pourra s’ensuivre l’élimination de l’unité de données de service (N) par le fournisseur du service (N), ou bien, lorsqu’il existe un contrôle de flux, l’activation de celui-ci à la frontière de service, au niveau du point d’accès au service (N) émetteur par le fournisseur de service (N).

5.8.4.5 – Un service (N) en mode sans connexion peut permettre la transmission de copies d’une unité de données de service (N) à plusieurs points d’accès au service (N) destinataires. Les unités de données de service (N) transmises à partir de plusieurs points d’accès au service (N) sources peuvent être reçues sur un point d’accès au service (N) destinataire. La couche (N) ne suppose aucune relation logique entre ces unités de données de service (N).

5.8.4.6 – Les entités (N) n’échangent aucune information de contrôle protocolaire (N) relative à l’intention des entités (N+1) d’utiliser un service (N) en mode sans connexion pour échanger des données.

NOTES

    1 Le mécanisme spécifique employé à l’interface par une réalisation particulière de service en mode sans connexion peut faire intervenir plus d’un échange à l’interface pour accomplir l’accès logique unique au service, nécessaire pour mettre en oeuvre une transmission en mode sans connexion; cependant, ceci est un détail de réalisation pratique locale.
    2 La transmission de chaque unité de données de service (N) par un service (N) en mode sans connexion doit être entièrement autonome. Toutes les informations d’adressage et autres demandées par la couche (N) pour remettre l’unité de données de service (N) à sa destination doivent être incluses dans l’accès au service pour chaque transmission.
    3 Un service en mode sans connexion a pour caractéristique fondamentale de ne comporter aucune négociation de paramètres de transmission au moment de l’accès au service, et de n’établir aucune association dynamique entre les parties concernées. Une liberté de choix considérable peut cependant être conservée en permettant de ne spécifier la plupart des valeurs de paramètres et des options (vitesse de transfert, taux d’erreur acceptable, etc.) qu’au moment de l’accès au service. Dans une réalisation pratique donnée, si le sous-système (N) local constate immédiatement (à partir des informations qui lui sont localement accessibles) que la transmission requise ne peut s’effectuer dans les conditions spécifiées, il peut couper la transmission en renvoyant un message d’erreur propre à la réalisation. Si cette même constatation est faite plus tard, après que l’accès au service a été obtenu, la transmission est abandonnée, car la couche (N) est supposée ne pas disposer des informations nécessaires pour engager une autre action.

5.8.5 – Propriétés de la transmission en mode connexion

5.8.5.1 – Une connexion (N) est une association établie pour assurer la communication entre deux entités (N+1) ou plus identifiées par leurs adresses (N). Une connexion (N) est un service offert par la couche (N), permettant l’échange d’informations entre les entités (N+1).

5.8.5.2 – Une entité (N+1) peut avoir simultanément une ou plusieurs connexions (N) la reliant à plusieurs entités (N+1) distinctes, à une même entité (N+1), ou à elle-même.

5.8.5.3 – Une connexion (N) est établie en spécifiant explicitement ou implicitement une adresse (N) pour l’entité (N+1) source et une adresse (N) pour l’entité ou chacune des entités (N+1) destinataires.

NOTE – Le mécanisme spécifique employé à l’interface par une réalisation particulière de service en mode connexion peut faire intervenir plus d’un échange à l’interface pour accomplir l’accès logique unique au service nécessaire pour mettre en oeuvre une transmission en mode connexion. Cependant, ceci est un détail de réalisation pratique locale.

5.8.5.4 – L’adresse (N) source et une ou plusieurs des adresses (N) destinataires peuvent être identiques. Plusieurs des adresses (N) destinataires peuvent être identiques entre elles et distinctes de l’adresse (N) source. Les adresses (N) peuvent être toutes distinctes.

5.8.5.5 – Une extrémité de connexion (N) est mise en place pour chacune des adresses SAP (N) explicitement ou implicitement spécifiées au moment de l’établissement d’une connexion (N).

5.8.5.6 – Une entité (N+1) accède à une connexion (N) via un point d’accès aux services (N).

5.8.5.7 – Une connexion (N) possède deux extrémités de connexion (N) ou plus.

5.8.5.8 – Une extrémité de connexion (N) ne peut être partagée par plusieurs entités (N+1) ou par plusieurs connexions (N).

5.8.5.9 – Une extrémité de connexion (N) associe trois éléments:

    a) une entité (N+1);

    b) une entité (N);

    c) une connexion (N).

5.8.5.10 – L’entité (N) et l’entité (N+1) associées par une extrémité de connexion (N) sont celles qui sont désignées par l’adresse SAP (N) spécifiée au moment de l’établissement de la connexion (N).

5.8.5.11 – Une extrémité de connexion (N) possède un identificateur, appelé identificateur d’extrémité de connexion (N), unique dans le contexte de l’entité (N+1) rattachée à l’extrémité de connexion (N).

5.8.5.12 – Un identificateur d’extrémité de connexion (N) est différent d’une adresse SAP (N).

5.8.5.13 – Une entité (N+1) désigne une connexion (N) par son identificateur d’extrémité de connexion (N).

5.8.5.14 – Les connexions multipoints sont des connexions ayant au moins trois extrémités de connexion; deux types sont définis3):

    a) la connexion multipoint centralisée;

    b) la connexion multipoint décentralisée.

5.8.5.15 – Une connexion multipoint centralisée possède une extrémité de connexion centrale. Les données envoyées par l’entité associée à l’extrémité centrale sont reçues par les entités associées à toutes les extrémités périphériques. Les données envoyées par une entité associée à une extrémité périphérique quelconque sont reçues uniquement par l’entité associée à l’extrémité centrale.

5.8.5.16 – Sur une connexion multipoint décentralisée, les données envoyées par une entité (N) associée à n’importe quelle extrémité de connexion sont reçues par les entités (N) associées à toutes les autres extrémités de connexion.

5.8.6 – Etablissement et libération de connexion

5.8.6.1 – Introduction

5.8.6.1.1 – Les connexions (N) nécessitent toutes des procédures d’établissement et de libération. Ces procédures peuvent:

    – être conçues pour envoyer les informations de contrôle protocolaires PCI (N) sur la même connexion (N) que les données d’utilisateur (N) (procédures dites «dans la bande»),
    – être conçues pour envoyer les PCI (N) sur une connexion (N) autre que celle qui est utilisée pour les données d’utilisateur (N) (procédures dites «hors bande»),
    – être des procédures a priori.

Les procédures a priori ne relèvent pas de l’OSI. Toutes ces procédures peuvent être normalisées ou non. Dans tous les cas, leurs propriétés de base sont les mêmes, et des informations équivalentes sont échangées pour initialiser et synchroniser l’état des entités (N) correspondantes. Seules relèvent de l’OSI les procédures normalisées d’établissement et de libération dans la bande et hors bande.

5.8.6.1.2 – Des protocoles OSI fonctionnant indépendamment d’un ensemble donné d’instances de communication peuvent servir à contrôler les ressources nécessaires à ces instances. On peut employer ces protocoles, souvent qualifiés de «hors bande», pour aider à établir par exemple des connexions (N). Les informations nécessaires à l’établissement d’une connexion (N) peuvent être véhiculées non seulement au moyen du protocole (N) direct (appelé «dans la bande») mais aussi en tant qu’élément d’un autre protocole de la couche (N) commun à plusieurs instances de communication.

5.8.6.1.3 – Il est possible d’admettre l’utilisation simultanée de procédures non normalisées sans que cela n’affecte le fonctionnement du protocole (N) ou du protocole (N+1). Ces procédures ne doivent pas affecter l’adressage, la qualité de service, les primitives de service, la gestion OSI, etc.

5.8.6.1.4 – Certains protocoles (N) peuvent combiner les échanges protocolaires d’établissement et de libération de connexion.

5.8.6.2 – Etablissement de connexion

5.8.6.2.1 – L’établissement d’une connexion (N) par des entités (N) homologues d’une couche (N) exige:

    a) que les entités (N) disposent entre elles d’un service (N-1);

    b) que les deux entités (N) soient dans un état dans lequel elles puissent procéder aux échanges protocolaires d’établissement de connexion.

5.8.6.2.2 – S’il n’est pas déjà disponible, le service (N-1) doit être établi par les entités (N-1) homologues de la couche (N-1). Ceci requiert pour la couche (N-1) les mêmes conditions que celles qui sont décrites ci-dessus pour la couche (N).

5.8.6.2.3 – Ces considérations sont réitérées vers le bas jusqu’à rencontrer soit un service disponible, soit le support physique de l’OSI.

5.8.6.2.4 – Selon les caractéristiques du service (N-1) et de l’échange protocolaire d’établissement de connexion, l’établissement d’une connexion (N) peut s’effectuer ou non conjointement à l’établissement de la connexion (N-1).

5.8.6.2.5 – Les caractéristiques du service (N) relatives à l’établissement de la connexion (N) varient selon la possibilité pour le protocole d’établissement de connexion de transférer ou non des données d’utilisateur (N) dans chacun des sens de la connexion (N).

5.8.6.2.6 – Quand des données d’utilisateur (N) sont transférées par l’échange protocolaire d’établissement de connexion (N), le protocole (N+1) peut en profiter pour permettre l’établissement de la connexion (N+1) conjointement à l’établissement de la connexion (N). Ceci est appelé «imbrication d’établissements de connexion». Si l’imbrication devait être autorisée à toutes les couches, la longueur du paramètre «données d’utilisateur» d’une PDU d’établissement de connexion devrait être indéfinie.

5.8.6.2.7 – La complexité qu’il y a à prévoir des champs de données d’utilisateur arbitrairement longs dans les primitives d’établissement de connexion dans certaines couches peut annuler les gains espérés d’une telle imbrication.

5.8.6.2.8 – L’imbrication entre couches adjacentes entre lesquelles interviennent des fonctions de multiplexage, de réutilisation, ou d’amélioration de la qualité de service, entraîne une complexité et une redondance des mécanismes. Ce surcroît de complexité et de redondance n’annule pas nécessairement tous les avantages potentiels de l’imbrication. C’est à la couche de décider si les éléments de protocole doivent être transmis dans la demande de connexion ou dans la première demande de transfert de données, pourvu que des protocoles appropriés autorisant ce choix soient définis.

5.8.6.2.9 – Si l’imbrication est utilisée, l’échec de l’établissement d’une connexion entraînera l’échec des établissements de connexion imbriqués.

5.8.6.3 – Libération de connexion

5.8.6.3.1 – La libération d’une connexion (N) est en général déclenchée par une des entités (N+1) qui lui sont associées.

5.8.6.3.2 – La libération d’une connexion (N) peut également être déclenchée par une des entités (N) supports à la suite d’une anomalie dans la couche (N) ou dans les couches inférieures.

5.8.6.3.3 – Selon les circonstances, la libération d’une connexion (N) peut entraîner l’élimination de données d’utilisateur (N).

5.8.6.3.4 – La libération en bon ordre d’une connexion (N) nécessite l’existence soit d’une connexion (N-1), soit d’une référence temporelle commune [par exemple: l’instant de la défaillance de la connexion (N-1) plus un délai de temporisation commun]. En outre, les deux entités (N) doivent être dans un état dans lequel elles peuvent exécuter les échanges protocolaires de libération de connexion. Cependant, il importe de noter que la libération d’une connexion
(N-1) ne provoque pas nécessairement la libération de la ou des connexions (N) qui l’utilisent. La connexion (N-1) peut en effet être rétablie ou remplacée par une autre connexion (N-1).

NOTE – La référence temporelle commune est déterminée par l’expiration d’une temporisation déterminée par une instance de service ou liée à elle.

5.8.6.3.5 – Le service (N) se caractérise par deux modes de libération des connexions (N):

    a) libération immédiate des connexions (N) dès que les échanges protocolaires de libération sont entamés [les données d’utilisateur (N) qui n’auront pas encore été remises pourront être éliminées];

    b) libération différée jusqu’à la remise de toutes les données d’utilisateur (N) expédiées avant le début des échanges protocolaires de libération (c’est-à-dire jusqu’à réception d’une confirmation de remise).

5.8.6.3.6 – Des données d’utilisateur (N) peuvent être transférées au cours des échanges protocolaires de libération de la connexion.

5.8.6.4 – Fonction de suspension

La suspension est une fonction OSI assurée par la couche (N) permettant de libérer une connexion (N-1) tout en préservant la connexion (N). La fonction de suspension dans une couche (N), peut être appelée à la demande explicite d’une couche supérieure, quand une entité de couche supérieure estime, par la connaissance qu’elle a de l’activité future, que la libération de la connexion (N-1) pourrait être bénéfique; cette fonction peut aussi être appelée spontanément dans le cadre du fonctionnement de la couche (N), suite à la réunion de certaines conditions (écoulement d’un certain laps de temps sans transfert de données par exemple) qui rendent avantageuse la libération de la connexion (N-1).

5.8.6.5 – Fonction de reprise

Le fonctionnement normal reprendra dès que l’une ou l’autre des parties aura besoin de la connexion (N-1) suspendue pour communiquer. Pour effectuer cette reprise, la couche (N) devra réétablir la connexion (N-1).

5.8.7 – Multiplexage et éclatement

5.8.7.1 – Dans la couche (N), les connexions (N) sont mises en correspondance avec des connexions (N-1). Cette correspondance peut être de l’un des trois types suivants:

    a) 1 à 1 (biunivoque);

    b) plusieurs connexions (N) avec une connexion (N-1) (multiplexage);

    c) une connexion (N) avec plusieurs connexions (N-1) (éclatement).

5.8.7.2 – Le multiplexage peut être nécessaire pour:

    a) rendre l’utilisation du service (N-1) plus efficace ou plus économique;

    b) fournir plusieurs connexions (N) dans un environnement où il n’existe qu’une seule connexion (N-1).

5.8.7.3 – L’éclatement peut être nécessaire pour:

    a) améliorer la fiabilité, lorsque plusieurs connexions (N-1) sont disponibles;

    b) assurer le niveau de performance requis, par l’utilisation de plusieurs connexions;

    c) obtenir une réduction des coûts par l’utilisation de plusieurs connexions (N-1) de coût réduit présentant chacune un niveau de performance inférieur au niveau requis.

5.8.7.4 – Multiplexage et éclatement peuvent faire intervenir chacun plusieurs fonctions associées, qui peuvent ne pas être nécessaires pour une correspondance biunivoque des connexions.

5.8.7.5 – Les fonctions associées au multiplexage sont les suivantes:

    a) identification de la connexion (N) pour chaque unité de données de protocole (N) transférée sur la connexion (N-1), afin que les données d’utilisateur (N) provenant des diverses connexions (N) multiplexées ne se mélangent pas. Cette identification, qui est distincte des identificateurs d’extrémité de connexion (N), est appelée identificateur de connexion de protocole (N);

    b) contrôle de flux sur chaque connexion (N), afin de partager la capacité de la connexion (N-1) (voir 5.8.8.3);

    c) sélection de la prochaine connexion (N) à desservir sur la connexion (N-1), quand plusieurs connexions (N) sont prêtes à émettre des données.

5.8.7.6 – Les fonctions associées à l’éclatement sont les suivantes:

    a) ordonnancement de l’utilisation des différentes connexions (N-1) servant à l’éclatement d’une seule connexion (N);

    b) reséquencement des unités de données de protocole (N) associées à une connexion (N). Ces données peuvent en effet arriver en désordre, même si chacune des connexions (N-1) garantit le maintien en séquence (voir 5.8.8.6).

5.8.8 – Transfert de données

5.8.8.1 – Transfert de données normales

5.8.8.1.1 – Les informations de contrôle et les données d’utilisateur sont transférées entre entités (N) dans des unités de données de protocole (N). Une unité de données de protocole (N) est une unité de données spécifiée dans un protocole (N) qui contient des informations de contrôle protocolaires (N) et éventuellement des données d’utilisateur (N).

5.8.8.1.2 – Les informations de contrôle protocolaires (N) sont transférées entre entités (N) au moyen du service (N-1). Une information de contrôle protocolaire (N) est toute information utile au fonctionnement commun d’entités (N). Les données d’utilisateur (N) sont transmises en transparence entre entités (N) au moyen du service (N-1).

5.8.8.1.3 – Une unité de données de protocole (N) a une taille finie qui peut être limitée par la taille des unités de données de protocole (N-1) et par les capacités du protocole (N). Les unités de données de protocole (N) sont projetées dans des unités de données de service (N-1). L’interprétation d’une unité de données de protocole (N) est définie par le protocole (N) utilisé pour le service (N).

5.8.8.1.4 – Une unité de données de service (N) est transférée entre une entité (N+1) et une entité (N) via un point d’accès aux services (N). Chaque unité de données de service (N) est transférée sous forme de données d’utilisateur (N) dans une ou plusieurs unités de données de protocole (N).

5.8.8.1.5 – L’échange des données selon un protocole (N) ne peut s’effectuer que s’il existe une instance du service (N-1). Si une telle instance n’existe pas, elle devra être établie avant que l’échange de données puisse s’effectuer (voir 5.8.6).

5.8.8.1.6 – La qualité de service négociée à l’établissement de la connexion se rapporte au flux d’unités de données de service passant par les points d’accès au service.

5.8.8.1.7 – Même quand il y a groupage, il reste toujours dans les limites de qualité de service négociée à l’établissement de la connexion. Il n’existe pas de cas où les données puissent être indéfiniment différées.

5.8.8.2 – Transfert de données au cours de l’établissement et de la libération d’une connexion

5.8.8.2.1 – Des données d’utilisateur (N) peuvent être transférées au cours des échanges protocolaires d’établissement et de libération de connexion (N).

5.8.8.2.2 – L’échange protocolaire de libération de connexion peut être combiné avec l’échange protocolaire d’établissement de la connexion (voir 5.8.6) pour permettre le transfert d’une unité de données d’utilisateur (N) unique entre entités (N+1) correspondantes avec confirmation de réception.

5.8.8.3 – Contrôle de flux

5.8.8.3.1 – Si les fonctions de contrôle de flux sont assurées en mode sans connexion, elles ne peuvent agir que sur des unités de données de protocole et des unités de données de service.

5.8.8.3.2 – On distingue deux types de contrôle de flux:

    a) le contrôle de flux entre homologues qui détermine la cadence d’émission d’unités de données de protocole (N) entre entités (N) assurant une transmission en mode connexion ou en mode sans connexion. Le contrôle de flux entre homologues doit être défini dans le protocole; il se base sur la taille des unités de données de protocole;

    b) le contrôle de flux à la frontière de service qui régule la cadence de transfert d’unités de données de service (N) entre une entité (N+1) et une entité (N) assurant une transmission en mode connexion ou en mode sans connexion. Le contrôle de flux à la frontière de service se base sur la taille des unités de données de service (N).

5.8.8.3.3 – Dans une transmission en mode sans connexion, le contrôle de flux entre homologues peut agir sur des PDU (N) à l’intérieur d’une SDU (N) mais pas à travers les limites des SDU (N).
NOTE – Il peut arriver toutefois qu’un contrôle de flux entraîne de facto une action à travers les limites des SDU (N). C’est le cas lorsqu’une sous-couche utilisant un protocole en mode sans connexion fonctionne par-dessus une sous-couche mettant en oeuvre un protocole en mode connexion. Les SDU (N) successives seront véhiculées dans des PDU en mode sans connexion, qui seront elles-mêmes transportées dans des PDU du protocole en mode connexion. Tout contrôle de flux homologue agissant sur ces PDU générera donc une action à travers les limites des SDU (N).

5.8.8.3.4 – Le multiplexage dans une couche peut nécessiter une fonction de contrôle de flux d’homologue pour chacun de ces flux (voir 5.8.7.5).

5.8.8.3.5 – Les fonctions de contrôle de flux d’homologue nécessitent l’insertion d’informations de contrôle de flux dans les informations de contrôle protocolaires (N) d’une unité de données de protocole (N).

5.8.8.3.6 – Si la taille des unités de données de service dépasse la taille maximale de la portion données d’utilisateur (N) de l’unité de données de protocole (N), une première segmentation sera appliquée à l’unité de données de service (N) pour la faire tenir dans les unités de données de protocole (N). Un contrôle de flux d’homologue pourra alors être appliqué aux unités de données de protocole (N).

5.8.8.4 – Transfert de données exprès

5.8.8.4.1 – Une unité de données exprès est une unité de données de service qui est transférée ou traitée en priorité par rapport aux unités de données de service normales. Un service de transfert de données exprès peut servir à des fins de signalisation et d’interruption. Il n’existe qu’en mode connexion.

5.8.8.4.2 – Le flux des données exprès est indépendant des états et du fonctionnement du flux des données normales, bien qu’il puisse exister une relation logique entre les données des deux flux. D’un point de vue conceptuel, une connexion qui admet les flux de données exprès peut être considérée comme ayant deux sous-canaux, l’un pour les données normales, l’autre pour les données exprès. Les données envoyées sur le canal exprès sont supposées avoir priorité sur les données normales.

5.8.8.4.3 – Le transfert garantit qu’une unité de données exprès ne sera pas remise après une unité de données de service normale ou exprès envoyée après elle sur la connexion.

5.8.8.4.4 – Le flux exprès étant supposé servir au transfert d’unités de données peu fréquentes et en petites quantités, des mécanismes de contrôle de flux simplifiés peuvent lui être appliqués.

5.8.8.4.5 – Une unité de données de service exprès (N) est destinée à être traitée par l’entité (N+1) destinataire en priorité sur les unités de données de service (N) normales.

5.8.8.4.6 – Une unité de données de service exprès (N) est associée à une connexion (N) particulière. Une donnée exprès est définie par rapport au flux de données normales de la connexion (N) associée. Elle n’est pas nécessairement une donnée exprès par rapport aux autres connexions (N) ou aux connexions dans les couches supérieures ou inférieures. Une donnée exprès dans la couche (N) ne sera pas nécessairement exprès dans une couche inférieure.

5.8.8.4.7 – Une donnée exprès n’est pas destructive et ne doit pas être confondue avec la réinitialisation. L’entité réceptrice peut décider de répondre par une action quelconque à caractère destructif, une coupure par exemple, mais il s’agit là d’un phénomène indépendant. De plus, le transfert de données exprès n’est pas prévu comme une méthode permettant d’assurer deux flux de données à niveaux de priorité différents. Le transfert de données exprès est prévu pour les cas exceptionnels et non pour le transfert de données normales.

5.8.8.4.8 – En mode sans connexion, il n’y a pas de transfert de données exprès tel qu’il est défini ici. Bien qu’un résultat similaire puisse être obtenu en faisant varier les paramètres de qualité de service demandés (en demandant par exemple un délai inférieur ou une priorité supérieure), il est impossible de garantir par ce moyen la remise des données avant «toute unité de données de service normale ultérieure».

5.8.8.4.9 – Les contraintes suivantes découlent de ce qui précède: 

    1) taille limitée des données exprès;

    2) soumission des données exprès à des mécanismes distincts de contrôle de flux dans chaque couche (N).

5.8.8.4.10 – Cette dernière contrainte signifie que le nombre d’unités de données exprès pouvant être en attente à un instant donné sera petit (une, en général).

5.8.8.4.11 – Ces contraintes imposent la prudence lorsqu’on met en correspondance un service (N) de données exprès avec un service (N-1) de données exprès:

    1) La limitation de taille peut nécessiter une dépendance entre les couches afin d’assurer la concordance des tailles, ou imposer la segmentation et le groupage des unités de données exprès du service (N) dans la couche (N-1).

NOTE – Si l’expéditeur assure la correspondance d’un service exprès à travers plusieurs couches, de la couche application à la couche session par exemple, et si les limites de taille sont uniformes dans toutes les couches, rendant inutile la segmentation, le destinataire peut alors prendre en charge le service exprès couche par couche, qu’il puisse ou non assurer la même correspondance de service exprès quand il est l’expéditeur. Les limites de taille peuvent donc ne pas être formellement spécifiées dans une norme.

    2) Il est vraisemblable que des problèmes de gestion de l’utilisation du service exprès (N-1) surgiront si ce service est utilisé par la couche (N) dans le fonctionnement du protocole (N) et pour fournir le service exprès (N).

    3) Une telle correspondance ne doit pas être effectuée si la couche (N) effectue un multiplexage sur des connexions (N-1). Le contrôle de flux de données exprès dans la couche (N-1) pourrait en effet perturber ou inhiber le service exprès sur les connexions (N) multiplexées sur la connexion (N-1).

5.8.8.4.12 – Par conséquent, il est préférable que les unités de données exprès du service (N) soient entièrement traitées par les fonctions (N) et n’utilisent que les fonctions de transfert de données (N-1) de base, et non pas les services spéciaux de la couche (N-1) tels que le service exprès (N-1). Quand le protocole (N) n’utilise pas le service exprès
(N-1) et qu’une anomalie surgit, l’unité de données exprès de service (N) peut être passée directement au service exprès (N-1).

5.8.8.4.13 – Bien qu’il soit faisable, dans les quelques cas bien délimités mentionnés ci-dessus, de projeter une unité de données exprès du service (N) dans une unité de données exprès du service (N-1), une telle correspondance doit être si possible évitée. En effet, des couches peuvent parfois être tenues d’assurer un service exprès plus complexe tel qu’un service exprès sûr ou un contrôle de flux plus flexible, etc. De tels services nécessitent alors des mécanismes plus élaborés, comme une connexion (N-1) distincte. Une telle complexité et de tels mécanismes incitent à recommander d’éviter la projection de données exprès (N) sur des données exprès (N-1).

5.8.8.4.14 – Il convient de noter que le service exprès ne garantit pas que l’on puisse court-circuiter les mécanismes de contrôle de flux des couches de niveau inférieur. Le message exprès peut être bloqué en permanence.

5.8.8.5 – Segmentation, groupage et concaténation

5.8.8.5.1 – Les unités de données des différentes couches ne sont pas obligatoirement de tailles compatibles. Il peut être nécessaire d’effectuer une segmentation, c’est-à-dire de projeter une unité de données de service (N) dans plusieurs unités de données de protocole (N). De même, une segmentation peut s’imposer lorsque des unités de données de protocole (N) sont projetées sur des unités de données de service (N-1). Comme il est nécessaire de préserver l’identité des unités de données de service (N) sur une connexion (N), il faut disposer de fonctions pour identifier les différents segments d’une même unité de données de service (N) et permettre ainsi aux entités (N) correspondantes de la réassembler.

5.8.8.5.2 – La segmentation peut nécessiter l’insertion d’informations dans l’information de contrôle protocolaire PCI (N) d’une unité de données de protocole (N). A l’intérieur d’une couche, l’information de contrôle protocolaire (N) est ajoutée à l’unité de données de service (N) pour constituer une unité de données de protocole (N) en l’absence de segmentation et de groupage [voir la Figure 10a)]. Si une segmentation est effectuée, une même unité de données de service (N) est projetée sur plusieurs unités de données de protocole (N) en y ajoutant l’information de contrôle protocolaire (N) [voir la Figure 10b)].

5.8.8.5.3 – Inversement, il peut être nécessaire d’effectuer un groupage. Ce mécanisme consiste à réunir plusieurs unités de données de service (N) avec leur information de contrôle protocolaire (N) pour constituer une seule unité de données de protocole (N) [voir la Figure 10c)].

5.8.8.5.4 – Le modèle de référence permet également la concaténation, par laquelle plusieurs unités de données de protocole (N) sont concaténées en une seule unité de données de service (N-1) [voir la Figure 10d)].

5.8.8.5.5 – En mode sans connexion, les fonctions de segmentation et de concaténation peuvent être utilisées, mais les fonctions de groupage et de dégroupage sont interdites.

5.8.8.6 – Séquencement

5.8.8.6.1 – Les services (N-1) fournis par la couche (N-1) de l’architecture OSI peuvent ne pas garantir la remise des unités de données de service (N-1) dans l’ordre où elles leur ont été remises par la couche (N). Si dans une telle situation, la couche (N) a besoin de préserver l’ordre des unités de données de service (N-1) transférées à travers la couche (N-1), elle devra comporter des mécanismes de séquencement. Le séquencement peut nécessiter des informations de contrôle protocolaires (N) additionnelles.

5.8.8.6.2 – En mode sans connexion, le séquencement n’intervient qu’indirectement au réassemblage des unités SDU (N).

5.8.9 – Fonctions d’erreurs

5.8.9.1 – Accusé de réception

5.8.9.1.1 – Les entités (N) mettant en oeuvre un protocole (N) peuvent se servir d’une fonction d’accusé de réception pour obtenir une probabilité de détection de perte d’unité de données de protocole plus élevée que celle qui est assurée dans la couche (N-1). Chaque unité de données de protocole (N) transférée entre entités (N) correspondantes est rendue identifiable de façon unique de telle sorte que le destinataire puisse informer l’expéditeur de sa réception. Une fonction d’accusé de réception est également capable d’inférer la non-réception d’unités de données de protocole (N) et de prendre les mesures correctives appropriées.

5.8.9.1.2 – Une fonction d’accusé de réception peut nécessiter l’insertion d’informations dans les informations de contrôle protocolaires PCI (N) des unités de données de protocole (N).

5.8.9.1.3 – Le schéma d’identification unique des unités de données de protocole (N) peut également servir à réaliser d’autres fonctions telles que la détection d’unités de données dupliquées, la segmentation ou le séquencement.

5.8.9.1.4 – En mode sans connexion, l’accusé de réception ne peut agir que sur des unités PDU (N) et non sur des unités SDU (N).

NOTE – D’autres formes d’accusé de réception, comme la confirmation de remise et la confirmation d’accomplissement d’une action, appellent un complément d’étude.

5.8.9.2 – Détection et notification d’erreurs

5.8.9.2.1 – Un protocole (N) peut utiliser des fonctions de détection et de notification d’erreurs pour améliorer la probabilité de détection d’erreur sur les unités de données de protocole et d’altération des données par rapport à celle qui est assurée par le service (N-).

5.8.9.2.2 – La détection et la notification d’erreurs peuvent nécessiter l’insertion d’informations additionnelles dans l’information de contrôle protocolaire (N) de l’unité de données de protocole (N).

5.8.9.2.3 – En mode sans connexion, si le fournisseur de service (N) peut essayer de signaler la détection de données altérées ou d’unité de données de protocole perdue, incorrectement remise, etc., il ne faut pas compter sur sa capacité à le faire chaque fois qu’un tel événement survient.

5.8.9.3 – Réinitialisation

5.8.9.3.1 – Certains services nécessitent une réinitialisation pour se rétablir après une perte de synchronisation entre entités (N) correspondantes. La fonction de réinitialisation ramène les entités (N) correspondantes dans un état prédéfini, avec possibilité de perte ou de duplication de données.

NOTE – Des fonctions additionnelles peuvent s’avérer nécessaires pour déterminer en quel point le transfert de données fiable a été interrompu.

5.8.9.3.2 – Une certaine quantité de données de l’utilisateur (N) peut être transférée en association avec l’exécution de la fonction de réinitialisation (N).

5.8.9.3.3 – La fonction de réinitialisation peut nécessiter l’insertion d’informations additionnelles dans l’information de contrôle protocolaire (N) de l’unité de données de protocole (N).

5.8.9.3.4 – La fonction de réinitialisation ne s’applique pas au mode sans connexion.

5.9 – Acheminement

Une fonction d’acheminement à l’intérieur de la couche (N) permet le relayage des communications à l’aide d’une chaîne d’entités (N). Le fait qu’une communication soit acheminée par des entités (N) intermédiaires n’est pas connu des couches situées au-dessous ou au-dessus de la couche (N). Une entité (N) qui participe à une fonction d’acheminement peut comporter une table d’acheminement.

5.10 – Qualité de service

5.10.1 – Introduction

5.10.1.1 – Le terme qualité de service (QOS) est le nom collectif donné à un ensemble de paramètres associés à une transmission de données (N) entre points d’accès aux services (N).

5.10.1.2 – Il existe deux catégories de paramètres de qualité de service. La première s’applique à la fois au mode connexion et au mode sans connexion. La seconde ne s’applique qu’au service en mode connexion. Les paramètres énumérés ci-dessous ne sont donnés qu’à titre d’exemple. Chaque couche se voit définir des paramètres propres.

5.10.2 – Paramètres des modes avec et sans connexion.

5.10.2.1 – Ces paramètres s’appliquent à la fourniture des services (N) tant en mode connexion qu’en mode sans connexion.

5.10.2.2 – Paramètres liés à une transmission unique

5.10.2.2.1 – Les paramètres du service (N) en mode connexion sont négociés à l’établissement de la connexion (N). En mode sans connexion, les paramètres sont définis entièrement par le comportement d’une seule transmission de données (N) et sont les mêmes que ceux qui sont définis pour le service (N) en mode connexion. Parmi ces paramètres, peuvent figurer:

    a) le délai de transmission attendu;

    b) la probabilité d’altération des données;

    c) la probabilité de perte ou de duplication;

    d) la probabilité de remise erronée;

    e) le coût;

    f) la protection contre l’accès non autorisé;

    g) la priorité.

5.10.2.3 – Paramètres liés à plusieurs transmissions

5.10.2.3.1 – Ces paramètres s’appliquent à plusieurs transmissions de données (N) entre deux points d’accès aux services (N). Parmi ces paramètres, peuvent figurer:

    a) le débit attendu;

    b) la probabilité de remise des données en désordre.

5.10.3 – Paramètres du mode connexion

5.10.3.1 – Ces paramètres ne s’appliquent qu’au service (N) en mode connexion et sont négociés par le protocole (N) à l’établissement de la connexion (N).

5.10.3.2 – Parmi ces paramètres, figurent: 

    a) le délai d’établissement de la connexion;

    b) la probabilité d’échec d’établissement de la connexion;

    c) le délai de libération de la connexion;

    d) la probabilité d’échec de libération de la connexion;

    e) la fragilité de la connexion.

6 – Les couches OSI – Introduction

ISO/CEI 7498-1 : 1994 (F)
Rec. UIT-T X.200 (1994 F)

6.1 – Les différentes couches

6.1.1 – La structure générale de l’architecture OSI, décrite à l’article 5 en référence à la recommandation X.200, fournit les concepts architecturaux à partir desquels le modèle de référence OSI a été dérivé en effectuant des choix concernant la définition des couches et de leur contenu.

6.1.2 – Le modèle de référence comporte sept couches:

    a) la couche application (couche 7);

    b) la couche présentation (couche 6);

    c) la couche session (couche 5);

    d) la couche transport (couche 4);

    e) la couche réseau (couche 3);

    f) la couche liaison de données (couche 2); et

    g) la couche physique (couche 1).

6.1.3 – Ces couches sont représentées à la Figure 11.

6.1.4 – La couche de niveau le plus élevé est la couche application. Elle contient les entités d’application qui coopèrent dans l’environnement OSI. Les couches des niveaux inférieurs fournissent les services par l’intermédiaire desquels les entités d’application coopèrent.

6.1.5 – Les couches 1 à 6, avec le support physique de l’OSI, correspondent à une élaboration des services de communication par enrichissements successifs niveau par niveau. A chacune des frontières séparant deux couches successives, correspond un niveau d’élaboration des services pour lequel est définie une norme de services OSI. Le fonctionnement des couches est, quant à lui, régi par des normes de protocoles OSI.

6.1.6 – Les systèmes ouverts ne constituent pas tous la source initiale ou la destination finale des données. Quand les systèmes ouverts ne sont pas tous directement reliés par le support physique de l’OSI, certains d’entre eux n’ont qu’un rôle de système ouvert relais, retransmettant les données à d’autres systèmes ouverts. Les fonctions et protocoles assurant la retransmission des données sont fournis par les couches des niveaux inférieurs. La Figure 12 représente une telle structure.

6.2 – Principes appliqués pour déterminer les sept couches du modèle de référence

6.2.1 – Les principes suivants, ayant servi à déterminer les sept couches du modèle de référence, semblent également utiles pour orienter des décisions futures dans l’élaboration de normes OSI:
NOTE – Il peut s’avérer difficile de prouver qu’une stratification particulière est la meilleure des solutions possibles. Toutefois, il existe des principes généraux qui s’appliquent à la détermination du nombre et de l’emplacement des frontières à créer.

    a) ne pas créer un nombre de couches tel qu’il introduise des difficultés inutiles dans la tâche d’ingénierie de description et d’intégration des couches;

    b) créer une frontière en un endroit où la description des services puisse être limitée et le nombre d’interactions à travers cette frontière réduit au minimum;

    c) créer des couches séparées pour prendre en charge des fonctions qui diffèrent manifestement par le traitement effectué ou la technologie mise en jeu;

    d) regrouper les fonctions similaires dans une même couche;

    e) choisir des frontières là où l’expérience passée a prouvé qu’un tel choix donnait de bon résultats;

    f) créer une couche avec des fonctions faciles à localiser, de telle sorte que la conception de la couche puisse être entièrement revue et ses protocoles profondément remaniés pour profiter des derniers progrès des techniques architecturales, matérielles ou logicielles sans avoir à modifier les services attendus des couches adjacentes ou fournis à celles-ci;

    g) créer une frontière là où il peut s’avérer utile à un moment ou à un autre de normaliser l’interface correspondante;

NOTES

    1 Les avantages et inconvénients de la normalisation des interfaces internes des systèmes ouverts ne sont pas abordés dans la présente Recommandation | Norme internationale. En particulier, on ne devra pas interpréter une mention ou une référence au principe g) comme impliquant l’utilité de la normalisation de telles interfaces internes.

    2 Il importe de noter que le système OSI en lui même n’impose pas la normalisation des interfaces internes aux systèmes ouverts. Qui plus est, lorsque de telles interfaces sont normalisées, la conformité à ces normes ne saurait en aucune façon être considérée comme une condition d’ouverture.

    h) créer une couche là où il est nécessaire de disposer d’un autre niveau d’abstraction pour la manipulation des données, par exemple, le niveau morphologique, syntaxique ou sémantique;

    j) permettre la modification de fonctions ou de protocoles à l’intérieur d’une couche sans que les autres couches en soient affectées; et

    k) pour chaque couche, ne créer des frontières qu’avec les couches des niveaux immédiatement supérieur et inférieur.
Des principes similaires ont été appliqués à la structuration en sous-couches:

    m) créer des regroupements et organisations fonctionnels pour former des sous-couches à l’intérieur d’une couche, lorsque des services de communication distincts le nécessitent;

    n) créer là où cela est nécessaire deux sous-couches ou plus, remplissant chacune une fonction commune et donc minimale, pour assurer l’interfaçage avec les couches adjacentes;

    p) permettre de court-circuiter les sous-couches.

6.3 – Description des couches

6.3.1 – Pour chacune des sept couches identifiées ci-dessus, l’article 7 donne:

    a) une brève description du rôle de la couche;

    b) une description des services offerts par la couche à la couche immédiatement supérieure; et

    c) une description des fonctions assurées dans la couche et de l’usage fait des services fournis par la couche immédiatement inférieure.

Ces descriptions ne constituent pas en elles-mêmes une définition complète des services et protocoles de chaque couche; de telles définitions font l’objet de normes séparées.

6.3.2 – Les fonctionnalités et fonctions énumérées à l’article 7 pour chacune des couches représentent l’ensemble des possibilités architecturales. Une définition de service dérivée de cet ensemble pour une couche particulière peut inclure tout ou partie de ces fonctionnalités, et être caractérisée par zéro, quelques uns ou l’ensemble des paramètres de qualité de service définis pour la couche à l’article 7 et en 5.10. Un protocole dérivé de cet ensemble pour une couche particulière peut invoquer toutes les fonctions définies pour la couche ou certaines d’entre elles. Un tel service ou protocole ne doit pas utiliser ou invoquer des fonctionnalités ou des fonctions n’appartenant pas à l’ensemble énuméré.

6.4 – Combinaison de services en mode connexion et en mode sans connexion

6.4.1 – La fourniture de services en mode connexion et en mode sans connexion dans des couches données du modèle de référence et les caractéristiques de ces services, ainsi que la fourniture de fonctions de conversion d’un mode à l’autre dans une couche, doivent être telles qu’elles garantissent la possibilité de déterminer si l’interfonctionnement entre systèmes ouverts est possible ou non. Pour maximiser les possibilités d’interfonctionnement et limiter la complexité des protocoles, une restriction est imposée au nombre de couches dans lesquelles une conversion d’un mode de service à un autre peut avoir lieu. Cette restriction s’applique aux couches comme suit:

    a) les couches physique et liaison de données appellent des considérations particulières. Les services en mode connexion et en mode sans connexion ne sont pas différenciés pour la couche physique. Ils sont déterminés par les caractéristiques du support sous-jacent et sont trop variés pour pouvoir être catégorisés comme fonctionnant en mode connexion ou en mode sans connexion. Les fonctions de la couche liaison de données doivent assurer la conversion entre les services offerts par la couche physique et le type de service de liaison de données requis;

    b) une conversion peut être effectuée dans la couche réseau pour prendre en charge un service de réseau d’un mode donné par-dessus un service de liaison de données ou un service de sous-couche de réseau de l’autre mode. Cette capacité, avec le relayage, assure un service de réseau de bout en bout d’un mode donné par-dessus des sous-réseaux concaténés et/ou des services de liaison de données de l’un ou l’autre mode (voir 5.3.4). Les normes OSI requièrent la prise en charge de ces conversions lorsqu’elles sont nécessaires pour assurer un mode donné de service réseau;

    c) une conversion peut être effectuée dans la couche transport à condition que celle-ci n’utilise qu’un nombre limité de fonctions protocolaires additionnelles en plus de celles qui sont requises pour prendre en charge un mode donné de service de transport par-dessus un service réseau du même mode. Etant donné que le relayage n’est pas admis dans la couche transport, ces conversions ne peuvent s’appliquer qu’entre systèmes d’extrémité. Les normes OSI ne requièrent pas la prise en charge de ces conversions;

    d) les conversions ne sont pas permises dans la couche session et dans la couche présentation ;

    e) aucune restriction de conversion n’est imposée dans la couche application.

NOTE – Puisqu’un protocole de transport agit entre deux systèmes d’extrémité, il ne peut pas fournir le service de transport entre deux systèmes d’extrémité utilisant, dans une instance de communication donnée, des services de réseau de modes différents.

6.4.2 – De ces restrictions, il découle:

    a) qu’un système ouvert réel comme définit en 4.1.2, prendra en charge un service transport d’un mode donné par-dessus un service réseau du même mode (en utilisant si nécessaire la conversion dans la couche réseau); un tel système peut en outre effectuer une conversion dans la couche transport;

    b) qu’un système réel qui ne prend en charge un service transport d’un mode donné qu’en effectuant la conversion dans la couche transport à partir d’un service réseau de l’autre mode n’est pas entièrement ouvert au sens défini en 4.1.2, puisqu’un tel système serait incapable de communiquer avec un système qui n’assure le service transport du mode donné que par-dessus un service réseau du même mode.

NOTE – La restriction voulant qu’un mode donné de service transport doit fonctionner sur le même mode de service réseau est imposée pour que les systèmes puissent communiquer sans qu’ils aient besoin de s’accorder au préalable sur le mode de service réseau à utiliser. S’il y a accord préalable, cette restriction n’est plus nécessaire bien que, pour être entièrement ouverts, les systèmes doivent remplir les conditions spécifiées à l’alinéa a) ci-dessus.

6.5 – Configuration des systèmes ouverts OSI

6.5.1 – Définitions en référence à la recommandation X.200

6.5.1.1 – système OSI d’extrémité: Système ouvert qui, pour une instance donnée de communication, est la source ou la destination ultime des données.

6.5.1.2 – système OSI relais (N): Système ouvert qui, pour une instance donnée de communication, utilise les fonctions OSI jusques et y compris celles de la couche (N), et qui assure une fonction de relais dans la couche (N).

6.5.2 – Propriétés

6.5.2.1 – Le modèle de référence OSI ne se limite pas aux configurations dans lesquelles seuls deux systèmes ouverts réels participent à une instance de communication, ni à celles où les systèmes ouverts réels participant à la communication sont tous connectés les uns aux autres par le même support physique, mais il recouvre aussi les configurations où la communication entre systèmes ouverts réels fait intervenir d’autres systèmes ouverts réels assurant des fonctions de relayage (voir 5.3).

6.5.2.2 – Pour distinguer les rôles des systèmes ouverts réels intervenant dans une instance de communication, on appelle système OSI d’extrémité, un système ouvert réel comportant un processus d’application agissant comme source ou comme destination ultime des données pour cette instance de communication, et on appelle système OSI relais (N) un système ouvert réel assurant une fonction de relayage dans la couche (N) pour cette instance de communication.

6.5.2.3 – Dans une instance donnée de communication, un système ouvert réel peut être soit un système OSI d’extrémité, soit un système OSI relais (N), mais ne tient pas nécessairement le même rôle dans toutes les instances de communication auxquelles il participe. Ces différents rôles du même système ouvert peuvent être tenus successivement, ou même simultanément quand le système ouvert participe à plusieurs communications avec différents systèmes ouverts ou avec le même.

6.5.2.4 – Dans les configurations faisant intervenir des systèmes OSI relais (N), le modèle de référence OSI prend en compte le cas où plusieurs sous-réseaux (voir 7.5.1) sont utilisés en cascade ou en parallèle (voir 7.5.2.3). Ces configurations mettent en jeu des fonctions d’acheminement et de relayage pour établir les connexions à travers ces réseaux de systèmes OSI relais (N). Ces fonctions, qui effectuent la retransmission des données à travers les systèmes OSI relais (N), sont assurées par les trois couches inférieures (voir 6.1) ou par la couche application.

6.5.2.5 – Dans le contexte d’applications réparties, des fonctions de relais peuvent être assurées par les entités d’application.

6.5.2.6 – Une entité de transport n’intervient donc que dans les instances de communication où le système OSI tient le rôle de système d’extrémité, ou alors le rôle de système relais (N) quand la fonction de relayage est assurée par la couche application.

7 – Description détaillée de l’architecture OSI

7.1 – Couche application

7.1.1 – Définitions

7.1.1.1 – entité d’application: Élément actif, à l’intérieur d’un processus d’application, comprenant un ensemble de capacités relatives à l’OSI et définies pour la couche application; cet ensemble correspond à un type d’entité d’application donné (sans autres capacités utilisées).

7.1.1.2 – syntaxe abstraite: Spécification d’unités de données de protocole d’application à l’aide de règles de notation indépendantes de la technique de codage utilisée pour les représenter.

7.1.2 – Rôle

7.1.2.1 – En tant que couche la plus élevée du modèle de référence OSI, la couche application constitue le seul moyen pour le processus applicatif d’accéder à l’environnement OSI. La couche application n’a donc pas de limite commune avec une couche de niveau supérieur.

7.1.2.2 – Les aspects d’un processus applicatif qui sont à prendre en compte pour l’OSI sont représentés par une ou plusieurs entités d’application.

7.1.2.3 – Une entité d’application représente un processus applicatif et un seul dans l’environnement OSI. Différents processus applicatifs peuvent être représentés par des entités d’application de même type. Un processus applicatif peut être représenté par un ensemble d’entités d’application: les entités d’application de cet ensemble peuvent être de différents types, mais ce n’est pas obligatoire.

7.1.3 – Services fournis par les entités d’application

7.1.3.1 – Considérations générales

7.1.3.1.1 – Les processus d’application échangent des informations par l’intermédiaire des entités d’application, qui utilisent des protocoles d’application et les services de présentation.

7.1.3.1.2 – En tant que seule couche du modèle de référence fournissant directement des services aux processus d’application, la couche application fournit nécessairement tous les services OSI directement utilisables par les processus d’application.

7.1.3.1.3 – Il n’y a pas de service de couche application au sens de service de couche (N) parce qu’il n’y a pas de service général fourni à une couche supérieure ni de point d’accès au service associé.

NOTE – Le concept associé de service OSI, défini dans ISO/CEI 10731, s’applique dans la couche application.

7.1.3.2 – Fonctionnalités en mode connexion
Outre le transfert d’informations, ces fonctionnalités peuvent inclure les éléments suivants sans s’y limiter:

    a) identification des correspondants prévus (par le nom, l’adresse, la description spécifique ou la description générique par exemple);

    b) détermination de la qualité de service acceptable (par exemple, temps de réponse, taux d’erreur acceptable et les coûts associés à ces éléments);

    c) synchronisation des applications coopérantes;

    d) accord sur la responsabilité pour la correction d’erreur;

    e) accord sur les aspects de sécurité (par exemple: authentification, contrôle d’accès, intégrité des données);

    f) sélection du mode de dialogue; et

    g) identification des syntaxes abstraites.

7.1.3.3 – Fonctionnalités en mode sans connexion

7.1.3.3.1 – Lorsqu’elles s’appliquent au mode sans connexion, des fonctionnalités équivalentes à celles du mode connexion sont offertes par la couche application aux processus applicatifs.

7.1.3.3.2 – Outre le transfert d’informations, ces fonctionnalités peuvent inclure les éléments suivants sans s’y limiter: 

    a) identification des correspondants prévus;

    b) détermination de l’habilitation à communiquer;

    c) autorisation des partenaires prévus;

    d) détermination de la qualité de service acceptable; et

    e) identification des syntaxes abstraites.

7.1.4 – Fonctions de la couche application

7.1.4.1 – La couche application contient toutes les fonctions nécessitant une communication en mode connexion ou en mode sans connexion entre systèmes ouverts, et qui ne sont pas déjà assurées par les couches inférieures. Ces fonctions peuvent être assurées tant par des logiciels que par des opérateurs humains.

7.1.4.2 – En particulier, dans le cadre des connaissances préalables requises à la communication, les entités d’application gardent des informations (ou accèdent à de telles informations via un service d’annuaire) indiquant si les entités homologues avec lesquelles elles peuvent avoir besoin de communiquer utilisent en transmission le mode avec et/ou sans connexion.

7.1.4.3 – Regroupement de fonctions dans la couche application
Une entité d’application peut être intérieurement structurée en objets de la couche application représentant des groupes de fonctions. L’utilisation d’un groupe de fonctions peut dépendre de celle de certaines autres fonctions, et les fonctions actives peuvent changer pendant la durée de vie d’une association d’application.

7.2 – Couche présentation

7.2.1 – Définitions

7.2.1.1 – syntaxe concrète: Aspects des règles utilisées dans la description formelle des données qui recouvrent une représentation spécifique de ces données.

7.2.1.2 – syntaxe de transfert: Syntaxe abstraite et concrète utilisée dans le transfert des données entre systèmes ouverts.

7.2.1.3 – contexte de présentation: Association d’une syntaxe abstraite et d’une syntaxe de transfert.

7.2.2 – Rôle

7.2.2.1 – La couche présentation se charge de la présentation des informations que des entités d’application se communiquent, ou auxquelles elles se réfèrent en cours de communication.

7.2.2.2 – La couche présentation assure une présentation commune des informations transférées entre entités d’application. Cela décharge les entités d’application de tout problème de présentation «commune» des informations; en d’autres termes, la couche présentation assure à ces entités une indépendance syntaxique.

7.2.2.3 – La couche présentation garantit la préservation du contenu informationnel des données de la couche application au cours du transfert. Les entités d’application coopérantes sont responsables de la détermination de l’ensemble des syntaxes abstraites qu’elles utilisent en communication et en informent la couche présentation. Connaissant l’ensemble des syntaxes abstraites utilisables par les entités d’application, la couche présentation est responsable du choix des syntaxes de transfert mutuellement acceptables.

NOTE – Les entités de présentation ne jouent aucun rôle dans la détermination de l’ensemble des syntaxes abstraites utilisables par les entités d’application.

7.2.3 – Services fournis à la couche application

7.2.3.1 – La couche présentation assure les fonctionnalités suivantes:

    a) identification d’un ensemble de syntaxes de transfert;

    b) choix de la syntaxe de transfert; et

    c) accès aux services de la couche session.

7.2.3.2 – L’identification d’un ensemble de syntaxes de transfert fournit un ou plusieurs moyens de représenter une syntaxe abstraite. Le choix de la syntaxe de transfert consiste à fournir le moyen de choisir une syntaxe de transfert de départ et de modifier ce choix par la suite.

7.2.3.3 – Les services de session sont fournis aux entités d’application sous la forme de services de présentation.

7.2.3.4 – En mode sans connexion, la segmentation et le réassemblage ne sont pas assurés par la couche présentation. La taille des unités de données de service (SDU) de présentation est donc limitée par la taille des unités de données de protocole (PDU) de présentation et des informations de contrôle protocolaires (PCI) de présentation.

7.2.4 – Fonctions de la couche présentation

Dans le cadre des prestations qu’elle offre, la couche présentation effectue les fonctions suivantes:

    a) négociation et rénégociation de la syntaxe de transfert;

    b) représentation de la syntaxe abstraite choisie par les entités d’application, en syntaxe de transfert négociée ou renégociée, y compris le format et les transformations spéciales (la compression des données par exemple);

    c) suite à certains événements, restauration de syntaxes précédemment adoptées;

    d) utilisation des services de session.

7.2.4.1 – Représentation de la syntaxe abstraite

7.2.4.1.1 – Les entités d’application s’accordent sur les syntaxes abstraites qu’elles utiliseront dans la communication. Pour que cette communication puisse avoir lieu, il faut représenter ces syntaxes abstraites en syntaxes de transfert appropriées.

NOTE – Les données définies en termes de syntaxe abstraite dans un système ouvert réel seront représentées dans l’environnement du système local par une syntaxe concrète locale. La transformation de la syntaxe concrète locale en syntaxe de transfert peut s’avérer ensuite nécessaire. Dans une communication entre systèmes ouverts réels, il y a donc trois versions de syntaxe concrète des données: la syntaxe concrète utilisée par l’entité d’application émettrice; celle qui est utilisée par l’entité d’application réceptrice, et celle qui est utilisée entre les entités de présentation (la syntaxe de transfert). Il est évidemment possible que ces diverses syntaxes ou plusieurs d’entre elles soient identiques. Les syntaxes concrètes locales ne sont pas visibles dans l’environnement OSI.

7.2.4.1.2 – Le fait qu’il y ait ou non transformation effective de la syntaxe concrète n’a pas d’effet sur le protocole de présentation.

7.2.4.1.3 – Il n’y a pas de syntaxe de transfert unique prédéterminée pour tout l’OSI. En mode connexion, la syntaxe de transfert à utiliser sur une connexion de présentation est négociée entre les entités de présentation correspondantes.

7.2.4.1.4 – En mode sans connexion, la syntaxe de transfert est choisie mais ne peut être négociée.

7.2.4.2 – Négociation de la syntaxe de transfert

7.2.4.2.1 – La négociation (ou la sélection) de la syntaxe de transfert a lieu entre deux entités de présentation quand une entité d’application fournit le nom d’une syntaxe abstraite pour laquelle une syntaxe de transfert est requise.

7.2.4.2.2 – En général, il peut y avoir plus d’une combinaison de syntaxe abstraite et de syntaxe de transfert. Il est possible de représenter une même syntaxe abstraite par une ou plusieurs syntaxes de transfert; il est aussi possible d’utiliser une seule syntaxe de transfert pour représenter plus d’une syntaxe abstraite. Chaque combinaison de syntaxe abstraite et de syntaxe de transfert est appelée contexte de présentation. Du point de vue de l’entité d’application, un contexte de présentation représente une utilisation distincte particulière d’une syntaxe abstraite.

7.2.4.3 – Adressage et multiplexage
Il n’y a ni multiplexage ni éclatement dans la couche présentation.

7.3 – Couche session

7.3.1 – Définitions

7.3.1.1 – gestion de jeton: Fonctionnalité du service de session permettant à des entités de présentation correspondantes de contrôler explicitement l’attribution de tour pour l’utilisation de certains services de session.

7.3.1.2 – mode duplex: Mode d’interaction dans lequel les deux entités de présentation peuvent simultanément envoyer et recevoir des données normales.

7.3.1.3 – mode semi-duplex: Mode d’interaction dans lequel, à un moment donné, une seule des deux entités de présentation correspondantes est autorisée à envoyer des données normales.

7.3.1.4 – synchronisation de connexion de session: Fonctionnalité du service de session permettant à des entités de présentation de définir et d’identifier des points de synchronisation, de réinitialiser une connexion de session à un état prédéfini et de convenir d’un point de resynchronisation.

7.3.2 – Rôle

7.3.2.1 – Le rôle de la couche session est de fournir aux entités de présentation coopérantes les moyens nécessaires pour organiser et synchroniser leur dialogue et pour gérer leur échange de données. A cet effet, la couche session fournit les services nécessaires à l’établissement d’une connexion de session entre deux entités de présentation, à la prise en charge des interactions ordonnées d’échange de données et à la libération normale de la connexion.

7.3.2.2 – La seule fonction de la couche session en mode sans connexion est de fournir une correspondance des adresses de transport avec les adresses de session.

7.3.2.3 – Une connexion de session est créée à la demande d’une entité de présentation, formulée à un point d’accès au service session. La connexion de session est maintenue jusqu’à sa libération par les entités de présentation ou par les entités de session.

7.3.2.4 – L’entité de présentation initiatrice désigne l’entité de présentation destinataire par une adresse de session. En général, il existe une correspondance n à 1 entre les adresses de session et les adresses de transport. Ceci ne signifie pas le multiplexage des connexions de session sur les connexions de transport, mais indique qu’au moment de l’établissement d’une connexion de session, plusieurs entités de présentation peuvent servir de cible à une même demande d’établissement de connexion de session arrivant sur une connexion de transport donnée. Cependant, si cela est nécessaire, il peut y avoir une correspondance biunivoque entre les adresses de session et les adresses de transport.

7.3.3 – Services fournis à la couche présentation

7.3.3.1 – Considérations générales

7.3.3.1.1 – En mode connexion, la couche session fournit les services suivants:

    a) établissement de connexion de session;

    b) libération de connexion de session;

    c) transfert de données normales;

    d) transfert de données exprès;

    e) gestion de jeton;

    f) synchronisation de la connexion de session;

    g) rapport d’anomalies;

    h) gestion d’activité;

    j) transfert de données typées; et

    k) resynchronisation.

7.3.3.1.2 – En mode sans connexion, la couche session fournit les services suivants:

    a) transmission en mode sans connexion utilisant le service de transport en mode sans connexion;

    b) rapport d’anomalies.

7.3.3.1.3 – En mode sans connexion, la segmentation et le réassemblage ne sont pas assurés par la couche session. La taille des unités de données de service (SDU) de session est donc limitée par la taille des unités de données de protocole (PDU) de session et des informations de contrôle protocolaires (PCI) de session.

7.3.3.2 – Etablissement de connexion de session

7.3.3.2.1 – Le service d’établissement de connexion de session permet à deux entités de présentation d’établir entre elles une connexion de session. Les entités de présentation sont identifiées par des adresses de session, utilisées pour demander l’établissement de la connexion de session.

7.3.3.2.2 – Le service d’établissement de connexion de session permet aux entités de présentation de déterminer ensemble, au moment de l’établissement de la connexion de session, les valeurs uniques des paramètres de cette connexion.

7.3.3.2.3 – Le service d’établissement de connexion de session fournit un identificateur de connexion qui permet aux entités de présentation d’identifier la connexion de session.

7.3.3.3 – Libération de connexion de session

7.3.3.3.1 – Le service de libération de connexion de session permet aux entités de présentation de libérer en bon ordre une connexion de session, sans perte de données. Il permet également à l’une ou l’autre des entités de présentation de demander à tout moment l’abandon d’une connexion de session; dans ce dernier cas, il peut y avoir perte de données.

7.3.3.3.2 – Une connexion de session peut également être coupée par l’une des entités de session qui en assurent le support.

7.3.3.4 – Transfert de données normales

Le service de transfert de données normales permet à une entité de présentation expéditrice de transférer une unité de données de service de session à une entité de présentation réceptrice.

7.3.3.5 – Transfert de données exprès

Le service de transfert de données exprès assure le traitement en exprès du transfert d’unités de données exprès du service de session. La taille des unités de données exprès du service de session est soumise à des restrictions spécifiques.

7.3.3.6 – Gestion de jeton

Le service de gestion de jeton permet aux entités de présentation de contrôler explicitement l’attribution de tour pour l’exercice de certaines fonctions de contrôle.

7.3.3.7 – Synchronisation de connexion de session

7.3.3.7.1 Le service de synchronisation de connexion de session permet aux entités de présentation:

    a) de définir et d’identifier des points de synchronisation;

    b) de réinitialiser la connexion de session à un état prédéfini et de convenir d’un point de resynchronisation, avec un risque potentiel de perte de données.

7.3.3.7.2 – La sémantique attachée aux points de synchronisation par les utilisateurs du service de session est transparente pour le fournisseur du service de session.

7.3.3.7.3 – La couche session n’est pas responsable d’éventuelles actions de vérification ou de validation associées à la synchronisation.

7.3.3.7.4 – La synchronisation symétrique permet de régler les points de synchronisation indépendamment dans les deux sens du flux de données.

7.3.3.8 – Rapport d’anomalies

Le service de rapport d’anomalies permet aux entités de présentation d’être averties de situations exceptionnelles.

7.3.3.9 – Gestion d’activité

Le concept d’activité permet aux utilisateurs du service de session de distinguer différentes unités logiques de travail appelées activités. Chaque activité consiste en une ou plusieurs unités de dialogue. Une seule activité à la fois est autorisée sur une connexion de session, mais plusieurs activités peuvent se succéder au cours d’une même connexion de session. Une activité peut aussi se prolonger sur plusieurs connexions de session. Une activité peut également être interrompue puis reprise sur la même connexion de session ou sur une connexion de session ultérieure.

7.3.3.10 – Transfert de données typées

Le service de transfert de données typées permet à une entité de présentation expéditrice de transférer une unité de données de service de session à une entité de présentation réceptrice sans que ce transfert ne soit soumis aux dispositions relatives à la gestion des jetons.

7.3.3.11 – Resynchronisation

La resynchronisation peut être déclenchée par l’un ou l’autre des utilisateurs du service de session. Ce service ramène la connexion de session à un état déterminé; il comporte donc une réaffectation des jetons et l’attribution d’une nouvelle valeur au numéro de série du point de synchronisation. La resynchronisation peut provoquer l’élimination des données non remises.

7.3.4 – Fonctions internes de la couche session

7.3.4.1 – Les fonctions internes de la couche session sont celles qui seront exécutées par les entités de session pour assurer les services de session. En mode sans connexion, la couche session fournit une correspondance biunivoque des transmissions de session en mode sans connexion avec les transmissions de transport en mode sans connexion.

7.3.4.2 – La plupart des fonctions requises découlent directement des services fournis. Les fonctions additionnelles suivantes sont décrites ci-dessous:

    a) mise en correspondance des connexions de session avec les connexions de transport; et

    b) contrôle de flux des connexions de session.

7.3.4.3 – Mise en correspondance des connexions de session avec les connexions de transport
A un instant donné, il existe une correspondance biunivoque entre les connexions de session et les connexions de transport. Toutefois, la durée de vie d’une connexion de transport et celle de la connexion de session associée peuvent différer, si bien qu’une même connexion de transport peut prendre en charge plusieurs connexions de session successives.

7.3.4.4 – Contrôle de flux de connexion de session

Il n’y a pas de contrôle de flux entre homologues dans la couche session. Pour empêcher l’entité de présentation réceptrice d’être surchargée de données, l’entité de session réceptrice génère une contre-pression à travers la connexion de transport en tirant parti du contrôle de flux de la couche transport.

7.4 – Couche transport

7.4.1 – Définitions

Aucun terme spécifique à la couche transport n’a été identifié.

7.4.2 – Rôle

7.4.2.1 – Le service de transport assure le transfert des données en transparence entre entités de session en les déchargeant de tout souci quant à la manière de rendre ce transfert fiable et économiquement efficace.

7.4.2.2 – La couche transport optimise l’utilisation des services de réseau disponibles afin d’assurer au moindre coût les performances requises par chacune des entités de session. Cette optimisation est effectuée par rapport aux contraintes imposées par la demande de l’ensemble des entités de session concurrentes et par la qualité et la capacité globales du service de réseau dont dispose la couche transport.

7.4.2.3 – Tous les protocoles définis dans la couche transport ont une signification de bout en bout, les extrémités étant définies comme les entités de transport liées à des associations de transport. La couche transport se rapporte donc aux systèmes ouverts OSI d’extrémité et les protocoles de transport ne fonctionnent qu’entre systèmes ouverts OSI d’extrémité.

7.4.2.4 – La couche transport est libérée de tout souci d’acheminement et de relayage, le service de réseau assurant le transfert de données de toute entité de transport à n’importe quelle autre, y compris dans le cas de sous-réseaux en cascade (voir 7.5.1).

7.4.2.5 – Les fonctions de transport auxquelles il est fait appel dans la couche transport pour assurer la qualité de service requise dépendent de la qualité du service de réseau, qui dépend elle-même de la manière dont le service de réseau est réalisé (voir 7.5.3).

7.4.3 – Services fournis à la couche session

7.4.3.1 – Introduction

7.4.3.1.1 – La couche transport identifie de manière unique chaque entité de session par son adresse de transport. En mode sans connexion, la couche transport fournit un service en mode sans connexion qui traduit une demande de transmission d’une unité de données de service de transport en une demande de service de réseau en mode sans connexion. En mode connexion, le service de transport fournit les moyens d’établir, de maintenir et de libérer des connexions de transport. Les connexions de transport assurent une transmission duplex entre un couple d’entités de session (via des points d’accès au service de transport).

7.4.3.1.2 – Plusieurs connexions de transport peuvent être établies entre un même couple d’adresses de transport. Une entité de session se sert des identificateurs d’extrémités de connexion de transport fournis par la couche transport pour distinguer les extrémités de connexion de transport les unes des autres.

7.4.3.1.3 – Les connexions de transport fonctionnent indépendamment les unes des autres, mis à part les limites qu’imposent les ressources nécessairement finies de la couche transport.

7.4.3.1.4 – La qualité de service assurée sur une connexion de transport dépend de la classe de service demandée par les entités de session à l’établissement de la connexion de transport. La qualité de service choisie est maintenue pendant toute la durée de vie de la connexion de transport. Toute défaillance dans le maintien de la qualité de service choisie pour une connexion de transport donnée est notifiée à l’entité de session.

7.4.3.1.5 – En mode connexion, la couche transport assure les fonctionnalités suivantes:

    a) établissement de connexion de transport;

    b) libération de connexion de transport;

    c) transfert de données;

    d) transfert de données exprès; et

    e) suspension.

7.4.3.1.6 – En mode sans connexion, la segmentation et le réassemblage ne sont pas assurés par la couche transport. Ainsi, la taille des unités de données de service (SDU) de transport est limitée par la taille des unités de données de protocole (PDU) de transport et des informations de contrôle protocolaires (PCI) de transport.

7.4.3.2 – Etablissement de connexion de transport

7.4.3.2.1 – Les connexions de transport sont établies entre entités de session identifiées par leurs adresses de transport. La qualité de service de la connexion de transport est négociée entre les entités de session et le service de transport.

7.4.3.2.2 – Au moment de l’établissement d’une connexion de transport, la classe de service de transport à assurer peut être choisie dans un ensemble défini de classes de service disponibles.

7.4.3.2.3 – Ces classes de service sont caractérisées par des combinaisons de valeurs choisies de paramètres tels que le débit, le délai de transit et le délai d’établissement de la connexion, ainsi que par des valeurs garanties d’autres paramètres tels que le taux d’erreurs résiduel et la disponibilité du service.

7.4.3.2.4 – Ces classes de services représentent des combinaisons prédéfinies de l’ensemble des paramètres agissant sur la qualité de service; elles sont prévues pour satisfaire les demandes de service de transport correspondant aux divers types de trafic engendrés par les entités de session.

7.4.3.3 – Libération de connexion de transport
Cette fonctionnalité fournit les moyens à l’une ou l’autre des entités de session de libérer une connexion de transport et d’informer l’entité de session correspondante de cette libération.

7.4.3.4 – Transfert de données
Cette fonctionnalité assure le transfert des données avec la qualité de service convenue. Quand la qualité de service ne peut pas être maintenue et que toutes les tentatives possibles de reprise ont échoué, la connexion de transport est interrompue et les entités de session en sont avisées.

    a) le service de transfert d’unités de données de service (SDU) de transport fournit les moyens de délimiter des SDU de transport de longueur arbitraire et de les transférer en séquence et en transparence sur une connexion de transport depuis le point d’accès au service de transport expéditeur jusqu’au point d’accès au service de transport destinataire. Ce service est soumis à un contrôle de flux;

    b) le service de transfert d’unités de données exprès du service de transport fournit un moyen additionnel d’échanger des informations sur une connexion de transport. Le service de transport et le contrôle de flux des unités de données exprès du service de transport ont leurs propres caractéristiques. La taille maximale des unités de données exprès du service de transport est limitée.

7.4.3.5 – Transfert de données exprès
Un service de transfert de données exprès est fourni par la couche transport. Il doit être toutefois utilisé en respectant les contraintes indiquées en 5.8.8.3.

7.4.4 – Fonctions intervenant dans la couche transport

7.4.4.1 – Considérations générales

7.4.4.1.1 – En mode connexion, la couche transport peut comporter les fonctions suivantes:

    a) mise en correspondance des adresses de transport avec les adresses de réseau;

    b) multiplexage (de bout en bout) de connexions de transport sur des connexions de réseau;

    c) établissement et libération de connexions de transport;

    d) contrôle de séquencement de bout en bout sur chacune des connexions;

    e) détection d’erreurs de bout en bout et toute action nécessaire de surveillance de la qualité de service;

    f) reprise sur erreur de bout en bout;

    g) segmentation, groupage et concaténation de bout en bout;

    h) contrôle de flux de bout en bout sur chacune des connexions;

    j) fonctions de supervision;

    k) transfert d’unités de données exprès du service de transport; et

    l) suspension/reprise.

7.4.4.1.2 – En mode sans connexion, la couche transport assure les fonctions suivantes:

    a) mise en correspondance des adresses de transport avec les adresses de réseau;

    b) mise en correspondance des transmissions de transport de bout en bout en mode sans connexion avec des transmissions de réseau en mode sans connexion;

NOTE – Il est possible d’imaginer des situations particulières dans lesquelles la conversion du mode connexion en mode sans connexion dans la couche transport peut se justifier et peut donc être admise à condition que cela ne nécessite qu’une extension limitée des protocoles existants. En pareils cas, il est admis qu’une communication utilisant ces conversions ne puisse avoir lieu qu’entre les systèmes OSI d’extrémité qui les prennent en charge (voir 6.4).

    c) détection d’erreurs de bout en bout et surveillance de la qualité de service;

    d) délimitation des unités de données de service de transport; et

    e) fonctions de supervision.

7.4.4.2 – Adressage

7.4.4.2.1 – Quand une entité de session demande à la couche transport d’établir une connexion de transport avec une autre entité de session identifiée par son adresse de transport, la couche transport détermine l’adresse de réseau identifiant l’entité de transport qui dessert l’entité de session correspondante.

7.4.4.2.2 – Comme les entités de transport assurent des services de bout en bout, aucune entité de transport intermédiaire n’intervient en relais entre les entités de transport d’extrémité. La couche transport met donc en correspondance les adresses de transport avec les adresses de réseau qui identifient les entités de transport d’extrémité (voir la Figure 13).

7.4.4.2.3 – Une entité de transport peut desservir plusieurs entités de session. Dans le contexte d’une même entité de transport, plusieurs adresses de transport peuvent être associées à une même adresse de réseau. Ces associations nécessitent des fonctions de correspondance qui sont assurées par les entités de transport (voir la Figure 14).

7.4.4.3 – Multiplexage et éclatement de connexions
Afin d’optimiser l’utilisation des connexions de réseau, les connexions de transport peuvent ne pas être en correspondance biunivoque avec les connexions de réseau. Dans le souci d’optimiser les coûts d’utilisation du service de réseau, il est possible d’éclater ou de multiplexer les communications.

7.4.4.4 – Phases de fonctionnement

En mode connexion, le fonctionnement de la couche transport comporte les phases suivantes:

    a) établissement;

    b) transfert de données; et

    c) libération.

Le passage d’une phase à l’autre est spécifié en détail par le protocole de la couche transport.

7.4.4.5 – Phase d’établissement

Au cours de la phase d’établissement, la couche transport établit une connexion de transport entre deux entités de session. Pendant cette phase, les fonctions de la couche transport construisent la classe de service demandée en fonction des services fournis par la couche réseau. Au cours de cette phase, les fonctions suivantes peuvent être exécutées:

    a) obtenir une connexion de réseau répondant au mieux aux spécifications de l’entité de session, compte tenu de la qualité et du coût des services;

    b) décider de l’opportunité d’un multiplexage ou d’un éclatement pour optimiser l’utilisation des connexions de réseau;

    c) déterminer la taille optimale des unités de données de protocole de transport;

    d) choisir les fonctions qui devront être opérationnelles au début de la phase de transfert de données;

    e) traduire les adresses de transport en adresses de réseau;

    f) assurer l’identification des différentes connexions de transport établies entre un même couple de points d’accès aux services de transport (fonction d’identification de connexion);

    g) transfert de données.

7.4.4.6 – Phase de transfert de données

La phase de transfert de données vise à transférer des unités de données de service (SDU) de transport entre les deux entités de session connectées par la connexion de transport. Ceci est réalisé par la transmission d’unités de données de protocole (PDU) de transport ainsi que par les fonctions suivantes, l’utilisation de chacune de ces fonctions étant déterminée par la classe de services choisie au cours de la phase d’établissement:

    a) séquencement;

    b) groupage;

    c) concaténation;

    d) segmentation;

    e) multiplexage ou éclatement;

    f) contrôle de flux;

    g) détection d’erreurs;

    h) reprise sur erreur;

    j) transfert de données exprès;

    k) délimitation des unités de données de service de transport; et

    m) identification des connexions de transport.

7.4.4.7 – Phase de libération

La phase de libération vise à libérer la connexion de transport. Elle peut comprendre les fonctions suivantes:

    a) notification du motif de la libération;

    b) identification de la connexion de transport libérée; et

    c) transfert de données.

7.4.4.8 – Gestion de la couche transport

Les protocoles de la couche transport traitent de certaines activités de gestion de la couche (comme l’activation et le contrôle d’erreurs). Voir l’article 8 et la Rec. UIT-T X.700 | ISO 7498 4 pour la relation avec les autres aspects de gestion.

7.5 – Couche réseau

7.5.1 – Définitions

7.5.1.1 – sous-réseau réel: Ensemble d’équipements et de supports physiques formant un tout autonome qui peut être utilisé pour interconnecter des systèmes réels à des fins de transfert de données.

7.5.1.2 – sous-réseau: Abstraction d’un sous-réseau réel.

NOTES 

    1 Un sous-réseau est la représentation dans le modèle de référence OSI d’un réseau réel tel qu’un réseau public, un réseau privé ou un réseau local.

    2 Un sous-réseau peut être lui-même un système ouvert bien que ce ne soit pas nécessairement toujours le cas (voir ISO 8648 – Organisation interne de la couche réseau).

7.5.1.3 – connexion de sous-réseau: Chemin de communication à travers un sous-réseau utilisé par des entités de la couche réseau pour assurer une connexion de réseau.

7.5.2 – Rôle

7.5.2.1 – La couche réseau fournit les moyens fonctionnels et procéduraux de transmission en mode connexion ou en mode sans connexion entre entités de transport, et assure donc l’indépendance des entités de transport par rapport aux considérations d’acheminement et de relayage.

7.5.2.2 – La couche réseau fournit, d’une part les moyens d’établir, de maintenir et de libérer des connexions de réseau entre des systèmes ouverts contenant des entités d’application communicantes, et d’autre part les moyens fonctionnels et procéduraux d’échanger entre entités de transport des unités de données de service de réseau sur des connexions de réseau.

7.5.2.3 – Elle assure l’indépendance des entités de transport par rapport aux considérations d’acheminement et de relayage associés à l’établissement et au fonctionnement d’une connexion de réseau donnée, y compris dans le cas où plusieurs sous-réseaux sont utilisés en cascade (voir 7.5.4.2) ou en parallèle. Elle masque aux entités de transport la façon dont des ressources des couches sous-jacentes, les connexions de liaison de données par exemple, sont utilisées pour assurer des connexions de réseau.

7.5.2.4 – Toutes les fonctions de relais et tous les protocoles d’amélioration de services en cascade utilisés pour assurer le service de réseau entre systèmes ouverts OSI d’extrémité sont mis en oeuvre en dessous de la couche transport, c’est à dire dans la couche réseau ou les couches sous-jacentes.

7.5.3 – Services fournis à la couche transport

7.5.3.1 – Introduction

7.5.3.1.1 – Le service de base de la couche réseau consiste à assurer le transfert en transparence de données entre entités de transport. Ce service permet que les couches se trouvant au-dessus de la couche réseau soient seules à déterminer la structure et le contenu détaillé des données qui lui sont soumises.

7.5.3.1.2 – Tous les services sont fournis à la couche transport à un coût connu.

7.5.3.1.3 – La couche réseau contient les fonctions nécessaires pour constituer une solide frontière de couche réseau/transport, indépendante en tout des moyens de communication sous-jacents sauf pour ce qui est de la qualité du service. Ainsi, la couche réseau contient les fonctions nécessaires pour masquer les différences de caractéristiques des diverses technologies de transmission et de sous-réseaux et les fondre en un service de réseau homogène.

7.5.3.1.4 – Le service fourni est le même à chacune des extrémités d’une connexion de réseau, même quand une connexion de réseau emprunte plusieurs sous-réseaux offrant chacun des services différents (voir 7.5.4.2).

NOTE – Il importe de distinguer l’emploi particulier du terme «service» dans le modèle de référence OSI de son emploi courant dans le cadre des prestations offertes par les fournisseurs de réseaux publics et privés.

7.5.3.1.5 – La qualité de service est négociée entre les entités de transport et le service de réseau au moment de l’établissement d’une connexion de réseau. Si cette qualité de service peut varier d’une connexion de réseau à une autre, elle est choisie d’un commun accord pour une connexion donnée, et est la même aux deux extrémités de cette connexion.

7.5.3.1.6 – En mode connexion, les fonctionnalités offertes par la couche réseau sont les suivantes:

    a) adresses réseau;

    b) connexions de réseau;

    c) identificateurs d’extrémités de connexion de réseau;

    d) transfert d’unités de données de service de réseau;

    e) paramètres de qualité de service;

    f) notification d’erreur;

    g) transfert exprès d’unités de données de service de réseau;

    h) réinitialisation;

    j) libération; et

    k) réception de la confirmation.

7.5.3.1.7 – Certaines de ces fonctionnalités sont optionnelles, ce qui signifie que: 

    a) l’utilisateur doit demander à en disposer; et

    b) le fournisseur du service de réseau peut honorer la demande ou indiquer que le service n’est pas disponible.

7.5.3.1.8 – En mode sans connexion, la couche réseau, opérant entre plusieurs points d’accès au service de réseau, offre les fonctionnalités suivantes:

    a) transmission d’unités de données de service de réseau de taille maximale définie;

    b) paramètres de qualité de service; et

    c) notification d’erreur locale.

7.5.3.2 – Adresses réseau

Les entités de transport sont connues de la couche réseau par des adresses réseau. Les adresses réseau sont fournies par la couche réseau et peuvent être utilisées par les entités de transport pour identifier de manière unique d’autres entités de transport; les adresses réseau sont donc nécessaires aux entités de transport pour communiquer à l’aide du service réseau. La couche réseau identifie de manière unique chacun des systèmes ouverts d’extrémité (représentés par des entités de transport) par son adresse réseau. Cet adressage peut être indépendant de celui qui est nécessité par les couches sous-jacentes.

7.5.3.3 – Connexions de réseau

7.5.3.3.1 – Une connexion de réseau fournit les moyens de transférer des données entre entités de transport identifiées par leurs adresses de points d’accès au service de réseau. La couche réseau fournit les moyens d’établir, de maintenir et de libérer les connexions de réseau.

7.5.3.3.2 – Une connexion de réseau est une connexion point à point.

7.5.3.3.3 – Il peut exister plusieurs connexions de réseau entre deux entités de transport données (définies par leurs adresses de points d’accès au service réseau).

7.5.3.4 – Identificateurs d’extrémités de connexion de réseau
La couche réseau fournit à l’entité de transport un identificateur d’extrémité de connexion de réseau qui, avec l’adresse du point d’accès au service réseau associé, identifie de manière unique l’extrémité de connexion de réseau.

7.5.3.5 – Transfert d’unités de données de service de réseau

7.5.3.5.1 – La couche réseau assure la transmission des unités de données de service de réseau sur une connexion de réseau. Le début et la fin de ces unités sont distincts et la couche réseau assure l’intégrité de leur contenu.

7.5.3.5.2 – En mode connexion, aucune limite n’est imposée quant à la taille maximale des unités de données de service de réseau.

7.5.3.5.3 – Les unités de données de service de réseau sont transférées en transparence entre entités de transport.

7.5.3.6 – Paramètres de qualité de service

7.5.3.6.1 – La couche réseau établit et maintient pendant la durée de la connexion de réseau la qualité de service choisie.

7.5.3.6.2 – Les paramètres de qualité de service comprennent: le taux d’erreurs résiduel, la disponibilité du service, la fiabilité, le débit, le délai de transit (et ses variations) et le délai d’établissement d’une connexion de réseau.

7.5.3.7 – Notification d’erreur

7.5.3.7.1 – Les erreurs non récupérables détectées par la couche réseau sont notifiées aux entités de transport.

7.5.3.7.2 – La notification d’erreur peut conduire ou non à la libération de la connexion de réseau, selon les spécifications particulières du service de réseau.

7.5.3.8 – Transfert exprès d’unités de données de service de réseau

7.5.3.8.1 – Le transfert exprès d’unités de données de service de réseau est optionnel. Il fournit un moyen additionnel d’échange d’informations sur une connexion de réseau. Le transfert d’unités de données exprès du service de réseau possède ses propres caractéristiques de service réseau et un contrôle de flux distinct.

7.5.3.8.2 – La taille maximale des unités de données exprès du service de réseau est limitée.

7.5.3.8.3 – Ce service est optionnel et n’est pas nécessairement toujours fourni.

7.5.3.9 – Réinitialisation

La fonctionnalité de réinitialisation est optionnelle. Quand elle est invoquée, elle provoque l’élimination par la couche réseau de toutes les unités de données de service de réseau en transit et la notification à l’entité de transport située à l’autre extrémité de la connexion de réseau qu’une réinitialisation a eu lieu.

7.5.3.10 – Libération

7.5.3.10.1 – Une entité de transport peut demander la libération d’une connexion de réseau. Le service de réseau ne garantit pas la remise des données envoyées avant la demande de libération et se trouvant toujours en transit. La connexion de réseau est libérée quelle que soit la réaction de l’entité de transport correspondante.

7.5.3.10.2 – Cette fonctionnalité est optionnelle et peut ne pas être toujours disponible.

7.5.3.11 – Confirmation de remise

7.5.3.11.1 – Une entité de transport peut confirmer la remise de données sur une connexion de réseau. L’utilisation du service de confirmation de remise doit faire l’objet d’un accord entre les deux utilisateurs de la connexion de réseau au moment de l’établissement de celle-ci.

7.5.3.11.2 – Ce service est optionnel et peut ne pas être toujours disponible4).

7.5.4 – Fonctions de la couche réseau

7.5.4.1 – Introduction

7.5.4.1.1 – Les fonctions de la couche réseau prennent en compte une grande variété de configurations supports des connexions de réseau, allant des connexions s’appuyant sur une liaison point à point, jusqu’aux connexions mettant en jeu des combinaisons complexes de sous-réseaux aux caractéristiques différentes.

NOTE – Pour répondre à cette grande variété de cas, les fonctions de réseau devraient être structurées en sous-couches. Mais la couche réseau ne doit être subdivisée que lorsque cela est utile. En particulier, la structuration en sous-couches ne s’impose pas lorsque le protocole d’accès au sous-réseau assure la totalité des fonctionnalités du service réseau OSI.

7.5.4.1.2 – Les fonctions suivantes sont assurées par la couche réseau:

    a) acheminement et relayage;

    b) connexions de réseau;

    c) multiplexage des connexions de réseau;

    d) segmentation et groupage;

    e) détection d’erreurs;

    f) reprise sur erreur;

    g) séquencement;

    h) contrôle de flux;

    j) transfert de données exprès;

    k) réinitialisation;

    m) sélection du service;

    n) mise en correspondance des adresses de réseau avec les adresses de liaisons de données;

    o) mise en correspondance des transmissions de réseau en mode sans connexion avec les transmissions de liaison de données en mode sans connexion;

    p) conversion du service de liaison de données en mode connexion en service de réseau en mode sans connexion;

    q) amélioration d’un service de liaison de données en mode sans connexion pour fournir un service de réseau en mode connexion;

    r) gestion de la couche réseau.

7.5.4.2 – Acheminement et relayage

7.5.4.2.1 – Les connexions de réseau sont assurées par les entités de réseau qui se trouvent dans les systèmes ouverts d’extrémité, et par des systèmes ouverts intermédiaires agissant en relais. Ces systèmes ouverts intermédiaires peuvent interconnecter des connexions de sous-réseau, des connexions de liaison de données, et des circuits de données (voir 7.7). Les fonctions de routage déterminent un itinéraire approprié entre adresses de réseau. Pour établir la communication désirée, la couche réseau peut avoir à utiliser les services de la couche liaison de données pour commander l’interconnexion des circuits de données (voir 7.6.4.10 et 7.7.3.1).

7.5.4.2.2 – La commande de l’interconnexion des circuits de données (qui se trouvent dans la couche physique) depuis la couche réseau nécessite une interaction entre une entité de réseau et une entité physique du même système ouvert. Comme le Modèle de Référence ne permet d’interaction directe qu’entre couches adjacentes, l’entité de réseau ne peut pas interagir directement avec l’entité physique. Cette interaction est donc décrite à travers la couche liaison de données qui intervient de façon transparente pour véhiculer l’interaction entre la couche réseau et la couche physique.

7.5.4.2.3 – Cette représentation de la commande d’interconnexion d’un circuit de données est une représentation abstraite d’un événement intérieur à un système ouvert. Elle ne modélise pas le fonctionnement de systèmes ouverts réels et n’a, à ce titre, aucune influence sur la normalisation des protocoles OSI.

NOTE – Quand des fonctions de la couche réseau sont réalisées en combinant différents sous-réseaux, la spécification des fonctions d’acheminement et de relayage peut être simplifiée par l’utilisation de sous-couches, isolant les fonctions d’acheminement et de relayage des différents sous-réseaux des fonctions d’acheminement et de relayage inter-réseaux. Toutefois, lorsque les sous-réseaux ont des protocoles d’accès qui assurent la totalité des fonctionnalités du service réseau OSI, il n’est pas nécessaire de structurer la couche réseau en sous-couches.

7.5.4.3 – Connexions de réseau

7.5.4.3.1 – Cette fonction assure des connexions de réseau entre entités de transport, au moyen de connexions de liaison de données fournies par la couche liaison de données.

7.5.4.3.2 – Une connexion de réseau peut également être assurée sous forme de connexions de sous-réseaux en cascade, c’est-à-dire en aboutant plusieurs sous-réseaux distincts. Les sous-réseaux distincts ainsi interconnectés peuvent avoir des capacités de service identiques ou différentes. Chaque extrémité d’une connexion de sous-réseau peut fonctionner avec un protocole de sous-réseau différent.

7.5.4.3.3 – L’interconnexion de deux sous-réseaux de qualités différentes peut être réalisée de deux façons. A titre d’illustration, considérons deux sous-réseaux, l’un de haute qualité et l’autre de faible qualité:

    a) les deux sous-réseaux sont interconnectés tels quels. La qualité de la connexion de réseau résultante n’est pas meilleure que celle du sous-réseau de qualité la plus faible (voir la Figure 15);

    b) on commence par améliorer le sous-réseau de faible qualité pour le mettre au niveau du sous-réseau de haute qualité, puis on interconnecte les sous-réseaux. La qualité de la connexion de réseau résultante est approximativement celle du sous-réseau de haute qualité (voir la Figure 16).

Le choix entre ces deux solutions dépend de l’importance de la différence de qualité, du coût de l’amélioration et d’autres facteurs économiques.

7.5.4.4 – Multiplexage de connexions de réseau

7.5.4.4.1 – Cette fonction peut être utilisée pour multiplexer des connexions de réseau sur des connexions de liaison de données pour en optimiser l’utilisation.

7.5.4.4.2 – Dans le cas des connexions de sous-réseaux en cascade, il est également possible de multiplexer les différentes connexions de sous-réseaux pour en optimiser l’utilisation.

7.5.4.5 – Segmentation et groupage
La couche réseau peut segmenter ou grouper des unités de données de service de réseau afin d’en faciliter le transfert. Néanmoins, les délimiteurs des unités de données de service de réseau seront préservés le long de la connexion de réseau.

7.5.4.6 – Détection d’erreurs

Les fonctions de détection d’erreurs servent à vérifier le maintien de la qualité de service sur une connexion de réseau. Dans la couche réseau, la détection d’erreurs utilise les notifications d’erreurs fournies par la couche liaison de données. Des capacités additionnelles de détection d’erreurs peuvent être nécessaires pour assurer la qualité de service requise.

7.5.4.7 – Reprise sur erreur

Cette fonction permet la reprise sur une erreur détectée. Cette fonction peut varier selon la qualité du service de réseau fournie.

7.5.4.8 – Séquencement

Cette fonction assure, sur une connexion de réseau donnée et à la demande des entités de transport, la remise dans le bon ordre des unités de données de service de réseau.

7.5.4.9 – Contrôle de flux

Cette fonction peut devoir être mise en oeuvre si le contrôle de flux est requis.

7.5.4.10 – Transfert de données exprès

Cette fonction assure le service de transfert de données exprès.

7.5.4.11 – Réinitialisation

Cette fonction assure le service de réinitialisation.

7.5.4.12 – Sélection du service

Cette fonction permet de sélectionner le service voulu pour garantir un même service aux deux extrémités d’une connexion de réseau quand celle-ci emprunte plusieurs sous-réseaux de qualités différentes.

7.5.4.13 – Gestion de la couche réseau

Les protocoles de la couche réseau portent sur certaines activités de gestion de cette couche (comme l’activation et le contrôle d’erreurs). Voir l’article 8 et la Rec. UIT T X.700 | ISO 7498-4, pour ce qui a trait aux autres aspects de la gestion.

7.6 – Couche liaison de données

7.6.1 – Définitions

Aucun terme spécifique à la couche liaison de données n’a été identifié.

7.6.2 – Rôle

7.6.2.1 – La couche liaison de données fournit les moyens fonctionnels et procéduraux nécessaires d’une part à la transmission en mode sans connexion entre entités de réseau et, d’autre part, en mode connexion, à l’établissement, au maintien et à la libération des connexions de liaison de données entre entités de réseau, ainsi qu’au transfert des unités de données de service de liaison de données. Une connexion de liaison de données est construite à partir d’une ou plusieurs connexions physiques.

7.6.2.2 – La couche liaison de données détecte et éventuellement corrige les erreurs pouvant se produire dans la couche physique.

7.6.2.3 – En outre, la couche liaison de données permet à la couche réseau de contrôler l’interconnexion des circuits de données dans la couche physique.

7.6.3 – Service fournis à la couche réseau

7.6.3.1 – En mode connexion, les fonctionnalités assurées par la couche liaison de données sont les suivantes:

    a) adresses de liaison de données;

    b) connexion de liaison de données;

    c) unités de données de service de liaison de données;

    d) identificateurs d’extrémités de connexion de liaison de données;

    e) notification d’erreurs;

    f) paramètres de qualité de service; et

    g) réinitialisation.

7.6.3.2 – En mode sans connexion, les facilités fournies par la couche liaison de données sont:

    a) adresses de liaison de données; 

    b) transmission d’unités de données de service de liaison de données avec une taille maximale définie;

    c) paramètres de qualité de service.

7.6.3.3 – Adresses de liaison de données

Les entités de réseau sont connues de la couche liaison de données par des adresses de liaison de données. Les adresses de liaison de données sont fournies par la couche liaison de données et peuvent être utilisées par des entités de réseau pour identifier d’autres entités de réseau qui communiquent en utilisant le service de liaison de données. Une adresse de liaison de données est unique dans le contexte de l’ensemble de systèmes ouverts attachés à une même couche liaison de données. La notion d’adresse de liaison de données est différente de celle d’adresse de point d’accès au service de liaison de données (adresse de DLSAP).

7.6.3.4 – Connexion de liaison de données

Une connexion de liaison de données fournit le moyen de transférer des données entre entités de réseau identifiées par leur adresse de liaison de données. Une connexion de liaison de données s’établit et se libère dynamiquement.

7.6.3.5 – Unités de données de service de liaison de données

7.6.3.5.1 – La couche liaison de données permet d’échanger des unités de données de service de liaison de données sur une connexion de liaison de données, ou d’échanger des unités de données de service de liaison de données (non liées à d’autres unités de données de service de liaison de données) en utilisant le service de liaison de données en mode sans connexion.

7.6.3.5.2 – La taille des unités de données de service de liaison de données peut être limitée par la relation entre le taux d’erreurs de la connexion physique et la capacité de détection d’erreurs de la couche liaison de données.

7.6.3.6 – Identificateurs d’extrémités de connexion de liaison de données
Si nécessaire, la couche liaison de données fournit des identificateurs d’extrémités de connexion de liaison de données, dont l’entité de réseau peut se servir pour identifier une entité de réseau correspondante.

7.6.3.7 – Notification d’erreurs

La couche liaison de données notifie à l’entité de réseau toute erreur détectée qu’elle ne peut corriger.

7.6.3.8 – Paramètres de qualité de service

Les paramètres de qualité de service peuvent être optionnels. La couche liaison de données établit et maintient pendant toute la durée de la connexion de liaison de données la qualité de service choisie. Les paramètres de qualité de service comprennent: le temps moyen entre erreurs détectées mais non récupérables, le taux d’erreurs résiduel (les erreurs pouvant être dues à l’altération, la perte, la duplication, l’intervertissement, la remise erronée d’une unité de données de service de liaison de données, ou à une quelconque autre cause), la disponibilité du service, le délai de transit et le débit.

7.6.3.9 – Réinitialisation

L’entité de réseau peut forcer le retour de l’entité de liaison de données à un état connu en faisant appel à la fonctionnalité de réinitialisation.

7.6.4 – Fonctions de la couche liaison de données

Les fonctions réalisées par la couche liaison de données en mode connexion et en mode sans connexion sont les suivantes:

    a) projection des unités de données de service de liaison de données sur des unités de données de protocole de liaison de données;

    b) identification et échange de paramètres;

    c) contrôle de l’interconnexion de circuits de données;

    d) détection d’erreurs;

    e) acheminement et relayage;

    f) gestion de la couche liaison de données.

En mode connexion, les fonctions suivantes sont également exécutées par la couche liaison de données:

    a) établissement et libération des connexions de liaison de données;

    b) transmission de données sur liaison de données en mode connexion;

    c) éclatement de connexion de liaison de données;

    d) contrôle de séquencement;

    e) délimitation et synchronisation;

    f) contrôle de flux;

    g) reprise sur erreur; et

    h) réinitialisation.

En mode sans connexion, la fonction suivante est également exécutée par la couche liaison de données:

    a) transmission de données sur liaison de données en mode sans connexion.

7.6.4.1 – Etablissement et libération de connexions de liaison de données

Cette fonction établit et libère les connexions de liaison de données sur des connexions physiques préalablement activées. Quand une connexion physique comporte plus de deux extrémités (une connexion multipoint par exemple), la couche liaison de données doit comporter une fonction particulière pour identifier les connexions de liaison de données utilisant cette connexion physique.

7.6.4.2 – Transmission de données de liaison de données en mode sans connexion

La transmission de données de liaison de données en mode sans connexion fournit le moyen de transmettre des unités de données de service de liaison de données entre points d’accès au service de liaison de données sans établir de connexion de liaison de données.

7.6.4.3 – Projection des unités de données de service de liaison de données

Cette fonction projette de manière biunivoque des unités de données de service de liaison de données sur des unités de données de protocole de liaison de données.

NOTE – Les projections plus générales appellent un complément d’étude.

7.6.4.4 – Eclatement de connexion de liaison de données

Cette fonction effectue l’éclatement d’une connexion de liaison de données sur plusieurs connexions physiques.

7.6.4.5 – Délimitation et synchronisation

Ces fonctions permettent de reconnaître qu’une séquence d’unités de données de service physique (c’est-à-dire une séquence de bits, voir 7.7.3.2) transmises sur la connexion physique forme unité de données de protocole de liaison de données.

NOTE – Ces fonctions sont parfois désignées sous le nom de fonctions de verrouillage de trame.

7.6.4.6 – Contrôle de séquencement

Cette fonction maintient l’ordre séquentiel des unités de données de service de liaison de données sur une connexion de liaison de données.

7.6.4.7 – Détection d’erreurs

Cette fonction détecte les erreurs de transmission, de formatage et d’exploitation qui peuvent se produire sur la connexion physique ou résulter d’un mauvais fonctionnement de l’entité de liaison de données correspondante.

7.6.4.8 – Reprise sur erreur

Cette fonction effectue une tentative de reprise après la détection d’une erreur de transmission, de formatage ou d’exploitation et notifie aux entités de réseau les erreurs qui ne sont pas récupérables.

7.6.4.9 – Contrôle de flux

En mode connexion, chaque entité de réseau peut contrôler dynamiquement la cadence (jusqu’à une valeur maximale convenue) à laquelle elle reçoit des unités de données de service de liaison de données sur une connexion de liaison de données. Ce contrôle peut se répercuter sur la cadence à laquelle la couche liaison de données accepte les unités de données de service de liaison de données à l’extrémité de connexion de liaison de données correspondante. En mode sans connexion, il y a un contrôle de flux à la frontière de service, mais pas de contrôle de flux entre homologues.

7.6.4.10 – Identification et échange de paramètres

Cette fonction assure l’identification des entités de liaison de données et l’échange de paramètres.

7.6.4.11 – Réinitialisation

Cette fonction réinitialise une liaison de données en forçant l’entité de liaison de données à passer à un état prédéterminé.

7.6.4.12 – Contrôle de l’interconnexion de circuits de données

Cette fonction transmet aux entités de réseau la capacité de commander l’interconnexion de circuits de données dans la couche physique.

NOTE – Cette fonction est utilisée en particulier quand une connexion physique est établie ou libérée à travers un sous réseau à commutation de circuits, un système intermédiaire servant de relais entre les circuits de données. Ces circuits de données sont des éléments du chemin de bout en bout. Une entité de réseau, implantée dans le système intermédiaire, prend les décisions d’acheminement appropriées en fonction des spécifications de trajet dérivées des protocoles de signalisation de réseau.

7.6.4.13 – Acheminement et relayage

Pour certains sous-réseaux, en particulier certains types de réseaux locaux, l’acheminement et le relayage entre réseaux locaux doivent s’effectuer dans la couche liaison de données.

7.6.4.14 – Gestion de la couche liaison de données

Les protocoles de la couche liaison de données portent sur certaines activités de gestion de cette couche (comme le contrôle d’erreurs et l’activation). Voir l’article 8 et la Rec. UIT-T X.700 | ISO 7498-4, pour ce qui a trait aux autres aspects de la gestion.

7.7 – La couche physique

7.7.1 – Définitions

7.7.1.1 – circuit de données: Trajet de communication dans le support physique de l’OSI, entre deux entités physiques ou plus, avec les fonctionnalités nécessaires à la couche physique pour transmettre des bits sur ce trajet.

7.7.2 – Rôle

La couche physique fournit les moyens mécaniques, électriques, fonctionnels et procéduraux nécessaires à l’activation au maintien et à la désactivation des connexions physiques destinées à la transmission de bits entre entités de liaison de données. Une connexion physique peut mettre en jeu plusieurs systèmes ouverts intermédiaires, relayant chacun la transmission des bits dans la couche physique. Les entités de la couche physique sont interconnectées au moyen d’un support physique.

7.7.3 – Services fournis à la couche liaison de données

7.7.3.1 – Les services fournis par la couche physique sont déterminés par les caractéristiques du support sous-jacent et sont trop variés pour permettre une classification en mode connexion et en mode sans connexion.

7.7.3.2 – Les services ou éléments de service fournis par la couche physique sont:

    a) connexions physiques;

    b) unités de données de service physique;

    c) extrémités de connexion physique;

    d) identification de circuits de données;

    e) séquencement;

    f) notification d’anomalies; et

    g) paramètres de qualité de service.

7.7.3.3 – Connexions physiques

7.7.3.3.1 – La couche physique assure la transmission en transparence de trains binaires entre entités de liaison de données sur des connexions physiques.

7.7.3.3.2 – Un circuit de données est un trajet de communication entre deux entités physiques ou plus dans le support physique de l’OSI, avec les fonctionnalités de la couche physique nécessaires à la transmission de bits sur ce trajet.

7.7.3.3.3 – Une connexion physique peut être assurée par l’interconnexion de circuits de données au moyen des fonctions de relayage de la couche physique. La Figure 17 représente la réalisation d’une connexion physique au moyen d’un tel assemblage de circuits de données.

7.7.3.3.4 – La commande de l’interconnexion des circuits de données fait partie des services offerts aux entités de liaison de données.

7.7.3.4 – Unités de données de service physique

7.7.3.4.1 – Une unité de données de service physique est constituée d’un seul bit ou d’une chaîne binaire.

NOTE – La transmission en série ou en parallèle peut être couverte par le protocole de la couche physique.

7.7.3.4.2 – Une connexion physique peut autoriser la transmission duplex ou semi-duplex des trains binaires.

7.7.3.5 – Extrémités de connexion physique

7.7.3.5.1 – La couche physique fournit des identificateurs d’extrémité de connexion physique qui peuvent être utilisés par une entité de liaison de données pour identifier des extrémités de connexion physique.

7.7.3.5.2 – Une connexion physique peut avoir deux extrémités de connexion physique (point à point) ou plusieurs (multipoint) (voir la Figure 18).

7.7.3.6 – Identification de circuit de données

La couche physique fournit des identificateurs qui désignent de manière unique les circuits de données reliant deux systèmes ouverts adjacents.

NOTE – Ces identificateurs sont utilisés par les entités de réseau des systèmes ouverts adjacents pour faire référence à des circuits de données au cours de leur dialogue.

7.7.3.7 – Séquencement

La couche physique restitue les bits dans l’ordre où ils lui ont été remis.

7.7.3.8 – Notification d’anomalie

Les anomalies détectées dans la couche physique sont notifiées aux entités de liaison de données.

7.7.3.9 – Paramètres de qualité de service

La qualité de service d’une connexion physique résulte de celle des circuits de données qui la constituent. La qualité de service peut être caractérisée par:

    a) le taux d’erreurs, les erreurs pouvant être dues à l’altération, la perte ou l’insertion d’un bit, ou à d’autres causes;

    b) la disponibilité du service;

    c) la vitesse de transmission; et

    d) le délai de transit.

7.7.4 – Fonctions de la couche physique

7.7.4.1 – Les fonctions de la couche physique sont déterminées par les caractéristiques du support sous-jacent et sont trop variées pour permettre une classification de leur fonctionnement en mode connexion et en mode sans connexion.

7.7.4.2 – Les fonctions assurées par la couche physique sont les suivantes:

    a) activation et désactivation de connexions physiques;

    b) transmission d’unités de données de service physique;

    c) multiplexage; et

    d) gestion de la couche physique.

7.7.4.3 – Activation et désactivation de connexions physiques

Ces fonctions assurent l’activation et la désactivation des connexions physiques entre deux entités de liaison de données, sur demande de la couche liaison de données. Elles comportent une fonction de relayage qui assure l’interconnexion de circuits de données.

7.7.4.4 – Transmission d’unités de données de service physique

La transmission des unités de données de service physique (c’est-à-dire de bits) peut être synchrone ou asynchrone. En option, cette fonction permet de reconnaître l’unité de données de protocole correspondant à une séquence convenue d’unités de données de service physique en cours de transmission.

7.7.4.5 – Multiplexage

Cette fonction permet de mettre deux connexions physiques ou plus sur un seul circuit de données. Elle assure la reconnaissance du verrouillage de trame, nécessaire pour pouvoir identifier les unités de données de protocole physiques véhiculées par les différentes connexions physiques sur l’unique circuit de données. La fonction de multiplexage est facultative.

NOTE – Un exemple particulier de multiplexage est donné par le partage d’un support de transmission en circuits de données pour prendre en charge les différents protocoles de liaison de données utilisés dans la phase de signalisation et dans la phase de transfert de données, lorsqu’on utilise des sous-réseaux à commutation de circuits. Dans cette utilisation du multiplexage, les flux de différente nature sont affectés en permanence aux différents éléments du groupe multiplexé.

7.7.4.6 – Gestion de la couche physique

7.7.4.6.1 – Les protocoles de la couche physique portent sur certaines activités de gestion de cette couche (comme le contrôle d’erreurs et l’activation). Voir l’article 8 et la Rec. UIT-T X.700 | ISO 7498-4, pour ce qui a trait aux autres aspects de la gestion.

NOTE – Le texte ci-dessus concerne une interconnexion entre systèmes ouverts, comme celle que représente la Figure 11. Les systèmes ouverts communicant dans un environnement réel nécessitent des connexions physiques réelles, comme celle de la Figure 19 a). Leur représentation logique est telle que sur la Figure 19 b) et est dénommée connexion de support physique. Les caractéristiques des connexions de support physique, qui dépendent de la nature mécanique, électromagnétique ou autre du support, sont définies à la frontière entre la couche physique et le support physique. Ces caractéristiques sont spécifiées par d’autres normes.

8 – Aspects gestion de l’OSI

8.1 – Définitions

8.1.1 – gestion d’application: Fonctions de la couche application (voir 6.1) ayant trait à la gestion des processus d’application OSI.

8.1.2 – entité d’application de gestion d’application: Entité d’application qui exécute des fonctions de gestion d’application.

8.1.3 – ressources OSI: Ressources de traitement de données et de communication de données relevant de l’OSI.

8.1.4 – gestion-système: Fonctions de la couche application relatives à la gestion des diverses ressources OSI et de leurs états dans toutes les couches de l’architecture OSI.

8.1.5 – entité d’application de gestion-système: Entité d’application utilisée pour les besoins de communication de la gestion-système.

8.1.6 – gestion de couche: Fonctions relatives à la gestion de la couche (N), effectuées en partie dans la couche (N) elle-même conformément au protocole (N) de la couche (activités telles que le contrôle d’erreurs et l’activation), et en partie par un sous-ensemble de la gestion-système.

8.2 – Introduction

8.2.1 – Dans le modèle de référence OSI, il est nécessaire de reconnaître la spécificité des problèmes posés par les actions consistant à lancer les activités et y mettre fin, les superviser, en assurer l’harmonie du déroulement, et à traiter les anomalies. Ces actions ont été regroupées dans ce qui est désigné collectivement comme les aspects gestion de l’architecture OSI. Ces concepts sont essentiels au fonctionnement des systèmes ouverts interconnectés.

8.2.2 – Les activités de gestion concernées sont celles qui supposent des échanges effectifs de données entre systèmes ouverts. Seuls les protocoles nécessaires pour régir de tels échanges peuvent faire l’objet d’une normalisation dans l’environnement OSI.

8.2.3 – Le présent article décrit les concepts clés relatifs aux aspects de gestion, en précisant les différentes catégories d’activités de gestion et la place de ces activités dans le modèle de référence OSI.

8.2.4 – Dans la gestion-système et la gestion de couche, une action d’initialisation est prévue pour établir le support d’un service de transmission en mode sans connexion entre systèmes.

8.2.5 – Des fonctionnalités de gestion peuvent être prévues pour permettre de transmettre les caractéristiques liées à la nature, à la qualité et au type de service en mode sans connexion offert par une couche à la couche immédiatement supérieure avant l’invocation de ce service. Ces fonctionnalités peuvent fournir cette information soit avant toute invocation du service, soit à tout moment durant lequel ce service est disponible.

8.3 – Catégories d’activités de gestion

8.3.1 – Introduction

8.3.1.1 – Seules les activités de gestion qui supposent des échanges effectifs d’informations entre entités de gestion distantes relèvent de l’architecture OSI. Les autres activités de gestion localisées dans des systèmes ouverts particuliers sortent du cadre de l’OSI.

8.3.1.2 – De même, toutes les ressources ne relèvent pas de l’OSI. La présente Norme internationale ne prend en considération que les ressources OSI, c’est-à-dire les ressources de traitement et de communication de données qui relèvent de l’OSI.

8.3.1.3 – Les différentes catégories suivantes d’activités de gestion ont été identifiées:

    a) gestion d’application;

    b) gestion-système; et

    c) gestion de couche.

8.3.2 – Gestion d’application

8.3.2.1 – La gestion d’application a trait à la gestion des processus d’application OSI. La liste suivante, non exhaustive, énumère des activités types relevant de cette catégorie:

    a) initialisation de paramètres représentant des processus d’application;

    b) déclenchement, entretien et terminaison de processus d’application;

    c) allocation de ressources OSI à des processus d’application et libération de ces ressources;

    d) détection et prévention d’interférences et d’interblocages entre ressources OSI;

    e) contrôles d’intégrité et d’engagement;

    f) contrôles de sécurité;

    g) pose de points de reprise et contrôles de reprise.

8.3.2.2 – Les protocoles de gestion d’application résident dans la couche application et sont mis en oeuvre par des entités d’application de gestion d’application.

8.3.3 – Gestion-système

8.3.3.1 – La gestion-système a trait à la gestion des ressources OSI et de leurs états dans toutes les couches du modèle de référence OSI. La liste suivante, non exhaustive, énumère des activités types relevant de cette catégorie:

    a) gestion des activations et désactivations, comprenant:

        1) activation, maintenance et libération des ressources OSI réparties entre les différents systèmes ouverts, y compris le support physique de l’OSI;

        2) certaines fonctions de chargement de logiciels;

        3) établissement, entretien et libération de connexions entre entités de gestion;

        4) initialisation et modification des paramètres des systèmes ouverts;

    b) surveillance, comprenant:

        1) rapports d’état ou de changement d’état, et

        2) rapport statistiques;

    c) contrôle d’erreurs, comprenant:

        1) détection d’erreurs et certaines des fonctions de diagnostic;

        2) reconfiguration et redémarrage.

8.3.3.2 – Les protocoles de gestion-système résident dans la couche application et sont mis en oeuvre par des entités d’application de gestion-système.

8.3.4 – Gestion de couche

8.3.4.1 – La gestion de couche présente deux aspects. Le premier a trait à des activités de la couche telles que l’activation des ressources et le contrôle d’erreur. C’est le protocole de la couche concernée qui règle cet aspect de la gestion.

8.3.4.2 – Le second aspect de la gestion de couche est un sous-ensemble de la gestion-système. Les protocoles qui régissent ces activités résident dans la couche application et sont mis en oeuvre par des entités d’application de gestion système.

8.4 – Principes généraux de localisation des fonctions de gestion

Plusieurs principes importants s’appliquent à la localisation des fonctions de gestion dans le modèle de référence OSI, notamment5):

    a) la centralisation et la décentralisation des fonctions de gestion sont toutes deux autorisées. Ainsi, le modèle de référence OSI n’impose aucun degré ou mode particulier de centralisation de ces fonctions. Ce principe implique donc une organisation dans laquelle chaque système ouvert peut inclure tout ou partie des fonctions de gestion-système et dans laquelle chaque sous-système peut inclure tout ou partie des fonctions de gestion de couche; 

    b) Des connexions entre entités de gestion sont établies si nécessaire lorsqu’un système ouvert, fonctionnant jusqu’alors isolément des autres systèmes ouverts, rejoint l’environnement OSI.

9 – Conformité et cohérence avec le présent modèle de référence X.200

9.1 – Définitions X.200

9.1.1 – cohérence: Une Recommandation UIT-T | Norme internationale «de référenciation» est dite cohérente avec une Recommandation UIT-T | Norme internationale «citée en référence» si le sens des deux n’est pas altéré par cette référence.

9.1.2 – conformité: Une Recommandation UIT-T | Norme internationale «de référenciation» est dite conforme aux spécifications applicables d’une Recommandation UIT-T | Norme internationale «citée en référence» si l’une des conditions suivantes est vraie:

    a) la Recommandation UIT-T | Norme internationale «citée en référence» impose (par le verbe «devoir») des spécifications applicables au type de Recommandation UIT-T | Norme internationale dont la Recommandation UIT-T | Norme internationale «de référenciation» est une instance;

    b) la Recommandation UIT-T | Norme internationale «citée en référence» comporte une clause de conformité précisant lesquelles des spécifications s’appliquent au type de Recommandation UIT-T | Norme internationale dont la Recommandation UIT-T | Norme internationale «de référenciation» est une instance;

    c) la Recommandation UIT-T | Norme internationale «de référenciation» contient une déclaration de conformité à la Recommandation UIT-T | Norme internationale «citée en référence»;

    d) il est possible en examinant la Recommandation UIT-T | Norme internationale «de référenciation», de vérifier que les spécifications applicables ont été observées.

9.2 – Application des spécifications de cohérence et de conformité X.200

9.2.1 – Les autres Recommandations UIT-T | Normes internationales de modélisation, qui étendent ou affinent le présent modèle de référence de base devront être cohérentes avec la présente Recommandation UIT-T | partie de Norme internationale.

9.2.2 – Les spécifications de conformité et de cohérence avec ce modèle de référence de base s’appliquent aussi aux Recommandations UIT-T, aux Normes internationales et aux rapports techniques qui décrivent ou spécifient des fonctions OSI. Ces Recommandations UIT-T, Normes internationales et rapports peuvent être des architectures, des modèles, des cadres généraux, des définitions de services ou des spécifications de protocoles.

9.2.3 – Cohérence

9.2.3.1 – Une architecture, un cadre général, un modèle multicouche, un modèle monocouche, une définition de service ou une spécification de protocole, cohérents avec le présent modèle de référence de base et avec les autres Recommandations UIT T | Normes internationales de modélisation qui étendent ou affinent ce modèle de référence de base, comportera la déclaration suivante:
«La présente architecture, le présent modèle multicouche, le présent modèle monocouche, la présente description de service ou la présente spécification de protocole:

    a) obéit aux principes architecturaux et aux prescriptions du modèle de référence de base OSI (Rec UIT T X.200 | ISO/CEI 7498-1);

    b) utilise les concepts établis par le modèle de référence de base OSI (Rec. UIT T X.200 | ISO/CEI 7498-1) avec les mêmes définitions et la même terminologie.»

9.2.4 – Conformité

9.2.4.1 – Conformité d’une architecture, d’un cadre général ou d’un modèle multicouche
Une architecture, un cadre général ou un modèle multicouche, conforme au présent modèle de référence de base et aux autres Recommandations UIT T | Normes internationales de modélisation associées à ce modèle et l’affinant, comportera la déclaration suivante:

«La présente architecture (ou cadre général ou modèle multicouche) est conforme au modèle de référence de base OSI (Rec. UIT T X.200 | ISO/CEI 7498 1) en ce sens qu’elle décrit des opérations et des mécanismes pouvant être affectés à des couches déterminées telles qu’elles sont spécifiées dans le modèle de référence de base OSI.»

9.2.4.2 – Conformité d’un modèle monocouche

Un modèle monocouche conforme au présent modèle de référence de base OSI comportera la déclaration suivante:

«La présente norme monocouche est conforme au modèle de référence de base OSI (Rec. UIT T X.200 | ISO/CEI 7498-1) en ce sens qu’elle décrit des opérations et mécanismes relatifs à une couche donnée telle qu’elle est spécifiée dans le paragraphe correspondant de l’article 7 du modèle de référence de base OSI.»

9.2.4.3 – Conformité d’une définition de service

Une définition de service conforme au modèle de référence de base OSI comportera la déclaration suivante:

«La présente définition de service est conforme au modèle de référence de base OSI (Rec. UIT T X.200 | ISO/CEI 7498-1) en ce sens qu’elle décrit les fonctionnalités relatives à une couche donnée telle qu’elle est spécifiée dans le paragraphe correspondant de l’article 7 du modèle de référence de base OSI.»

9.2.4.4 – Conformité d’une spécification de protocole

Une spécification de protocole conforme au modèle de référence de base OSI comportera la déclaration suivante:

«La présente spécification de protocole est conforme au modèle de référence de base OSI (Rec. UIT T X.200 | ISO/CEI 7498-1) en ce sens qu’elle décrit les fonctions relatives à une couche donnée telle qu’elle est spécifiée dans le paragraphe correspondant de l’article 7 du modèle de référence de base OSI.»

Annexe A – Brève explication sur la façon dont les couches ont été choisies

(Cette annexe ne fait pas partie intégrante de la présente Recommandation X.200 * Norme internationale.)

A.1 – La présente annexe fournit des éléments d’information venant compléter la présente Recommandation | Norme internationale.

A.2 – Ce qui suit est une brève explication sur la façon dont les couches ont été choisies:

A.2.1 – Il est essentiel que l’architecture permette l’utilisation d’une variété réaliste de supports physiques d’interconnexion associés à différentes procédures de contrôle (par exemple les procédures UIT T V.24, V.25, etc.). L’application des principes énoncés en 6.2 c), e) et h) conduit à identifier une couche physique, comme niveau de base de l’architecture.

A.2.2 – Certains supports physiques de communication (les lignes téléphoniques par exemple) nécessitent l’utilisation de techniques spécifiques pour transmettre des données entre systèmes malgré un taux d’erreurs relativement élevé (c’est à-dire un taux d’erreurs non acceptable pour la grande majorité des applications). Ces techniques spécifiques se traduisent par des procédures de contrôle de liaison de données qui sont étudiées et normalisées depuis plusieurs années. Il faut également savoir que les nouveaux supports physiques de communication (les fibres optiques par exemple) nécessiteront des procédures de contrôle de liaisons de données différentes. L’application des principes énoncés en 6.2 c), e) et h) conduit à identifier dans l’architecture une couche liaison de données par-dessus la couche physique.

A.2.3 – Dans l’architecture des systèmes ouverts, certains systèmes ouverts servent de destination finale des données, voir l’article 4. D’autres systèmes ouverts peuvent n’agir que comme noeuds intermédiaires [(retransmettant les données à d’autres systèmes ouverts) (voir la Figure 13)]. L’application des principes énoncés en 6.2 c), e) et g) conduit à identifier une couche réseau par-dessus la couche liaison de données. Les protocoles orientés réseau (les protocoles d’acheminement par exemple) seront regroupés dans cette couche. La couche réseau fournit ainsi un chemin de connexion (une connexion de réseau) entre une paire d’entités de transport, y compris dans les cas où il existe des noeuds intermédiaires (voir la Figure 12 ainsi que le 7.5.4.2).

A.2.4 – Le contrôle du transport des données d’un système ouvert d’extrémité source à un système ouvert d’extrémité destination est la dernière fonction à accomplir pour assurer la totalité du service de transport (ce contrôle n’est pas effectué dans les noeuds intermédiaires). La plus haute couche de la partie de l’architecture consacrée au service de transport est donc la couche transport, située par-dessus la couche réseau. Cette couche transport libère les entités des couches des niveaux supérieurs de tout souci de transport des données entre elles.

A.2.5 – Il est nécessaire d’organiser et de synchroniser le dialogue et de gérer l’échange des données. L’application des principes énoncés en 6.2 c) et d) conduit à identifier une couche session par-dessus la couche transport.

A.2.6 – Les fonctions d’intérêt général restantes sont celles qui ont trait à la représentation et à la manipulation de données structurées pour le compte des logiciels applicatifs. L’application des principes énoncés en 6.2 c) et d) conduit à identifier une couche présentation par-dessus la couche session.

A.2.7 – Enfin, on trouve des applications qui consistent en des processus applicatifs effectuant un traitement d’informations. La couche application, au plus haut niveau de l’architecture, qui constitue un des aspects de ces processus applicatifs, contient les protocoles qui leur servent à communiquer.

A.3 – L’architecture résultante à sept couches, représentée à la Figure 11, obéit aux principes énoncés en 6.2 a) et b).
Une description plus détaillée de chacune des sept couches identifiées ci-dessus est fournie à l’article 7 de la présente Recommandation | Norme internationale, en commençant par la couche application décrite en 7.1 et en descendant jusqu’à la couche physique décrite en 7.7.

Annexe B – Index alphabétique des définitions

(La présente annexe fait partie intégrante de la présente Recommandation X.200 * Norme internationale)

Terme Paragraphe

accusé de réception 5.8.1.16
acheminement 5.4.1.4
adresse (N) 5.4.1.1
adresse de point d’accès au service (N) 5.4.1.2
adresse de SAP (N) 5.4.1.2
association (N) 5.3.1.1
circuit de données 7.7.1.1
cohérence 9.1.1
communication bilatérale à l’alternat (N) 5.3.1.15
communication bilatérale simultanée (N) 5.3.1.14
communication de données (N) 5.3.1.13
communication unilatérale (N) 5.3.1.16
concaténation 5.8.1.13
conformité 9.1.2
connexion (N) 5.3.1.2
connexion de sous-réseau 7.5.1.3
connexion multipoint 5.3.1.4
connexion multipoint centralisée 5.8.1.2
connexion multipoint décentralisée 5.8.1.3
contexte de présentation 7.2.1.3
contrôle de flux 5.8.1.8
correspondance d’adresse (N) 5.4.1.3
couche (N) 5.2.1.2
dégroupage 5.8.1.12
démultiplexage 5.8.1.5
données d’utilisateur (N) 5.6.1.2
éclatement 5.8.1.6
entité (N) 5.2.1.11
entité d’application 7.1.1.1
entité d’application de gestion d’application 8.1.2
entité d’application de gestion-système 8.1.5
entités (N) correspondantes 5.3.1.5
entités (N) homologues 5.2.1.3
environnement d’interconnexion de systèmes ouverts (OSIE) 4.1.5
environnement local de système (LSE) 4.1.6
extrémité de connexion (N) 5.3.1.3
fonction (N) 5.2.1.7
fonctionnalité (N) 5.2.1.6
gestion d’application 8.1.1
gestion de couche 8.1.6
gestion de jeton 7.3.1.1
gestion-système 8.1.4
groupage 5.8.1.11
identificateur d’extrémité de connexion (N) 5.4.1.5
identificateur d’extrémité de connexion multipoint 5.4.1.7
identificateur de connexion de protocole (N) 5.4.1.9
identificateur de connexion de service (N) 5.4.1.8
identificateur de protocole (N) 5.8.1.1
identificateur de version de protocole (N) 5.8.1.18
information de contrôle protocolaire (N) 5.6.1.1
invocation d’entité (N) 5.2.1.12
invocation de processus d’application 4.1.7
mode duplex 7.3.1.2
mode semi-duplex 7.3.1.3
multiplexage 5.8.1.4
point d’accès au service (N) 5.2.18
processus d’application 4.1.1
protocole (N) 5.2.1.9
puits de données (N) 5.3.1.8
réassemblage 5.8.1.10
recombinaison 5.8.1.7
réinitialisation 5.8.1.17
relais (N) 5.3.1.6
ressources OSI 8.1.3
segmentation 5.8.1.9
séparation 5.8.1.14
séquencement 5.8.1.15
service (N) 5.2.1.5
source de données (N) 5.3.1.7
sous-couche 5.2.1.4
sous-réseau 7.5.1.2
sous-réseau réel 7.5.1.1
sous-système (N) 5.2.1.1
suffixe d’extrémité de connexion (N) 5.4.1.6
synchronisation de connexion de session 7.3.1.4
syntaxe abstraite 7.1.1.2
syntaxe concrète 7.2.1.1
syntaxe de transfert 7.2.1.2
système OSI d’extrémité 6.5.1.1
système OSI relais (N) 6.5.1.2
système ouvert 4.1.3
système ouvert réel 4.1.2
système réel 4.1.1
titre d’entité (N) 5.4.1.10
transmission de données (N) 5.3.1.9
transmission duplex (N) 5.3.1.10
transmission en mode connexion (N) 5.3.1.17
transmission en mode sans connexion (N) 5.3.1.18
transmission semi-duplex (N) 5.3.1.11
transmission simplex (N) 5.3.1.12
type d’entité (N) 5.2.1.10
type de processus d’application 4.1.8
unité de données de protocole (N) 5.6.1.3
unité de données de service (N) 5.6.1.4
unité de données exprès (N) 5.6.1.5
unité de données exprès de service (N) 5.6.1.5

10 – Les vidéos

11 – Suivi du document

L’UIT (Union internationale des télécommunications) est une institution spécialisée des Nations Unies dans le domaine des télécommunications. L’UIT-T (Secteur de la normalisation des télécommunications) est un organe permanent de l’UIT. Au sein de l’UIT-T, qui est l’entité qui établit les normes mondiales (Recommandations) sur les télécommunications, participent quelque 179 pays membres, 84 exploitations de télécommunications reconnues, 145 organisations scientifiques et industrielles et 38 organisations internationales.
L’approbation des Recommandations par les Membres de l’UIT-T s’effectue selon la procédure définie dans la Résolution no 1 de la Conférence mondiale de normalisation des télécommunications (CMNT), (Helsinki, 1993). De plus, la CMNT, qui se réunit tous les quatre ans, approuve les Recommandations qui lui sont soumises et établit le programme d’études pour la période suivante.
Dans certains secteurs de la technologie de l’information qui correspondent à la sphère de compétence de l’UIT-T, les normes nécessaires se préparent en collaboration avec l’ISO et la CEI. Le texte de la recommandation X.200 de l’UIT-T a été approuvé le 1er juillet 1994. Son texte est publié, sous forme identique, comme Norme internationale ISO/CEI 7498-1.

12 – Discussion autour de la recommandation X.200

Vous pouvez poser toutes vos questions, faire part de vos remarques et partager vos expériences à propos de la recommandation X.200. Pour cela, n’hésitez pas à laisser un commentaire ci-dessous :