Interconnexion de systèmes ouverts - Modèle de référence de base
Recommandation UIT-T X.200

1 - Domaine d'application
2 - Définitions
3 - Notations
4 - Introduction à l'interconnexion de systèmes ouverts (OSI)
        4.1 - Définitions
        4.2 - Environnement de l'interconnexion de systèmes ouverts
        4.3 - Modélisation de l'environnement OSI
5 - Concepts d'une architecture en couches
        5.1 - Introduction
        5.2 - Principe de la structuration en couches
        5.3 - Communication entre entités homologues
        5.4 - Identificateurs
        5.5 - Propriétés des points d'accès aux services
        5.6 - Unités de données
        5.7 - Nature du service (N)
        5.8 - Eléments de fonctionnement d'une couche
        5.9 - Acheminement
        5.10 - Qualité de service
6 - Les couches OSI - Introduction
        6.1 - Les différentes couches
        6.2 - Principes appliqués pour déterminer les sept couches du modèle de référence
        6.3 - Description des couches
        6.4 - Combinaison de services en mode connexion et en mode sans connexion
        6.5 - Configuration des systèmes ouverts OSI
7 - Description détaillée de l'architecture OSI
        7.1 - Couche application
        7.2 - Couche présentation
        7.3 - Couche session
        7.4 - Couche transport
        7.5 - Couche réseau
        7.6 - Couche liaison de données
        7.7 - La couche physique
8 - Aspects gestion de l'OSI
        8.1 - Définitions
        8.2 - Introduction
        8.3 - Catégories d'activités de gestion
        8.4 - Principes généraux de localisation des fonctions de gestion
9 - Conformité et cohérence avec le présent modèle de référence
        9.1 - Définitions
        9.2 - Application des spécifications de cohérence et de conformité
Annexe A - Brève explication sur la façon dont les couches ont été choisies
Annexe B - Index alphabétique des définitions
10 - Discussion autour de la documentation
11 - Suivi du document

Résumé

Ce modèle de référence 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

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

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

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 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éal