Service de transport ISO par dessus TCP, version 3

Statut du présent mémoire

Le présent mémoire spécifie une norme pour la communauté de l’Internet. Les hôtes qui, sur l’Internet, choisissent de mettre en œuvre les services de transport ISO par dessus TCP sont invités à adopter et mettre en œuvre la présente norme. L’accès TCP 102 est réservé aux hôtes qui mettent en œuvre la présente norme. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent mémoire spécifie la version 3 du protocole et se substitue à la [RFC-983]. Les changements entre le protocole décrit dans la RFC 983 et le présent mémoire sont mineurs, mais malheureusement incompatibles.

1 Introduction et philosophie

La communauté de l’Internet possède un ensemble de protocoles de transport et d’inter-réseautage (TCP/IP) bien développé et parvenu à maturité, qui réussissent assez bien à offrir à l’usager final des services réseau et de transport. Le CCITT et l’ISO ont défini diverses recommandations de session, présentation, et application qui ont été adoptées par la communauté internationale et de nombreux fabricants. Dans la plus large mesure possible, il est souhaitable d’offrir directement ces couches supérieures dans l’ARPA Internet, sans interruption des facilités existantes. Cela permet aux utilisateurs de développer leur expertise avec des applications ISO et CCITT qui n’étaient précédemment pas disponibles dans l’ARPA Internet. Cela permet aussi une convergence et une stratégie de transition plus harmonieuses des réseaux fondés sur TCP/IP vers les réseaux fondés sur ISO à moyen et long terme.

Il y a deux approches de base qui sont possibles lors du "portage" d’une application ISO ou CCITT dans un environnement TCP/IP. Une de ces approches est de porter chaque application individuelle séparément, en développant des protocoles locaux au dessus de TCP. Bien que cela soit utile à court terme (dans la mesure où des interfaces spécifiques à TCP peuvent être développées rapidement), cela manque de vision d’ensemble.

Une seconde approche est fondée sur l’observation que la suite de protocoles ARPA Internet et la suite de protocoles ISO sont toutes deux des systèmes en couches (bien que la première utilise la mise en couche dans une perspective plus pragmatique). Un aspect clé du principe de mise en couche est celui de l’indépendance d’une couche. Bien que cette section semble redondante pour la plupart des lecteurs, un petit rappel des fondamentaux est nécessaire pour introduire ce concept.

En externe, une couche est définie de deux façons :

une définition par le service offert, qui décrit les services fournis par la couche et les interfaces qu’elle fournit pour accéder à ces services ;

une définition par le service exigé, qui décrit les services utilisés par la couche et les interfaces qu’elle utilise pour accéder à ces services.

Collectivement, toutes les entités du réseau qui coopèrent pour fournir le service sont désignées comme le fournisseur de service. Individuellement, chacune de ces entités est appelé un homologue de service.

En interne, une couche est définie d’une seule façon :

une définition de protocole, qui décrit les règles qu’utilise chaque homologue de service lorsqu’il communique avec les autres homologues de service.

Lorsque l’on met tout cela ensemble, le fournisseur de service utilise le protocole et les services de la couche en dessous pour offrir son service à la couche au-dessus. La vérification de protocole, par exemple, traite de la preuve que ceci se produit bien dans la réalité (et est aussi un champ fertile pour de nombreuses thèses de doctorat en informatique).

Le concept de l’indépendance de couche est tout simplement : SI on préserve les services offerts par le fournisseur de service, ALORS l’utilisateur du service est complètement lié par rapport au protocole utilisé par l’homologue de service.

Pour les besoins du présent mémoire, nous utiliserons le concept d’indépendance de couche pour définir un point d’accès au service de transport (TSAP, Transport Service Access Point) qui apparaît comme étant identique aux services et interfaces offerts par le TSAP ISO/CCITT (tel que défini dans [ISO 8072]), mais nous allons en fait mettre en œuvre le protocole ISO TP0 par dessus TCP/IP (tel que défini dans les [RFC 793, RFC 791]), et non par dessus le protocole réseau ISO/CCITT. Comme le protocole de classe de transport 0 est utilisé sur la connexion TCP/IP, il réalise une fonctionnalité identique à la classe de transport 4. Et donc, les couches ISO/CCITT de niveau supérieur (toutes les entités de session, présentation, et application) peuvent pleinement fonctionner sans rien savoir du fait qu’elles fonctionnent sur un inter-réseau TCP/IP.

2 Motifs

En migrant de l’utilisation des protocoles TCP/IP aux protocoles ISO, on a le choix entre plusieurs stratégies. Le présent mémoire a été rédigé en visant une stratégie de migration particulière. La stratégie de migration utilisée par le présent mémoire se fonde sur la notion de passerelle entre les suites de protocoles TCP/IP et ISO à la couche transport. Deux forts arguments militent en faveur de cette approche :

1. L’expérience nous enseigne qu’il prend aussi longtemps pour avoir de bonnes mises en œuvre des protocoles de niveau inférieur qu’il en faut pour en obtenir du niveau supérieur. En particulier, on a observé qu’il reste encore pas mal de travail à faire sur les couches ISO réseau et transport. Il en résulte que les mises en œuvre de protocoles au-dessus de ces couches ne peuvent être entreprises qu’avec prudence. Et donc, quelque chose doit être fait "maintenant" pour fournir un support sur lequel les protocoles de niveau supérieur puissent être développés. Comme TCP/IP est arrivé à maturité, et fournit essentiellement des fonctionnalités identiques, c’est un support idéal pour prendre ce développement en charge.

2. La mise en œuvre de passerelles aux couches IP et ISO IP ne sera probablement pas d’utilisation générale à long terme. En effet, cela exigerait que chaque hôte Internet prenne en charge à la fois TP4 et TCP. À ce titre, une meilleure stratégie est de mettre en œuvre un chemin de migration en douceur des protocoles TCP/IP vers ISO pour l’ARPA Internet lorsque les protocoles ISO seront suffisamment mûrs.

Ces deux arguments indiquent que la constitution de passerelles devrait intervenir au niveau du point d’accès de service de couche transport ou au-dessus. De plus, le premier argument suggère que la meilleure approche est d’effectuer la constitution de passerelles exactement AU point d’accès de service de transport pour maximiser le nombre de couches ISO qui peuvent être développées.

Note : Le présent mémoire n’a pas l’intention d’agir comme un document de migration ou d’interception. Il est destiné SEULEMENT à satisfaire les besoins exposés ci-dessus. Cependant, il ne serait pas inattendu que le protocole décrit dans le présent mémoire puisse faire partie d’un plan de transition global. La description d’un tel plan est cependant totalement en dehors des objectifs du présent mémoire.

Finalement, en général, la construction de passerelles entre les autres couches des suites de protocoles TCP/IP et ISO est problématique, au mieux.

Pour résumer, la principale motivation de la norme décrite dans le présent mémoire est de faciliter le processus d’acquisition d’expérience avec les protocoles ISO des couches supérieures (session, présentation, et application). La stabilité et la maturité de TCP/IP sont idéales pour fournir de solides services de transport indépendants des mises en œuvre réelles.

3 Modèle

La norme [ISO8072] décrit la définition du service de transport ISO, appelée plus loin TP.

Note : Le présent mémoire fait référence aux spécifications ISO plutôt qu’aux Recommandations du CCITT. Les différences entre ces normes parallèles sont assez minimes, et peuvent être ignorées, pour ce qui concerne le présent mémoire, sans perte de substance. Le lecteur trouvera ci-après un tableau de correspondance :

Service de transport [ISO8072] [X.214]

Protocole de transport [ISO8073] [X.224]

Protocole de session [ISO8327] [X.225]

La définition ISO du service de transport décrit les services offerts par le fournisseur de service de transport (TS) et les interfaces utilisées pour accéder à ces services. Le présent mémoire se focalise sur la façon dont le protocole de commande de transmission (TCP, Transmission Control Protocol) [RFC793] de l’ARPA peut être utilisé pour offrir les services et fournir les interfaces.

+-----------+ +-----------+

| usager-TS | | usager-TS|

+-----------+ +-----------+

| |

| interface TSAP interface TSAP |

| [ISO8072] |

| |

+----------+ Services transport ISO sur TCP +----------+

| client |-----------------------------------------| serveur |

+----------+ (le présent mémoire) +----------+

| |

| interface TCP interface TCP |

| [RFC793] |

| |

Pour les besoins de l’exposé, on utilise les abréviations suivantes :

homologue-TS processus qui met en œuvre le protocole décrit dans le présent mémoire

usager-TS processus parlant qui utilise les services d’un homologue TS

fournisseur-TS l’entité de boîte noire qui met en œuvre le protocole décrit par le présent mémoire

Pour les besoins du présent mémoire, qui décrit la version 2 du protocole TSAP, tous les aspects de [ISO8072] sont pris en charge à l’exception des paramètres de qualité de service.

Dans l’esprit du CCITT, ceci est laissé "pour étude ultérieure". Une version future du protocole prendra très vraisemblablement en charge les paramètres de QS pour TP en les transposant en divers paramètres TCP.

Les normes ISO ne spécifient pas le format d’un accès de session (appelé un identifiant de TSAP). Le présent mémoire rend obligatoire l’utilisation de la spécification GOSIP [GOSIP86] pour l’interprétation de ce champ. (Prière de se référer au paragraphe 5.2, intitulé "Adressage des couches supérieures".)

Finalement, le TSAP ISO est fondamentalement symétrique par son comportement. Il n’y a pas de modèle client/serveur sous-jacent. Au lieu d’un serveur qui écoute sur un accès bien connu, lorsqu’une connexion est établie, le fournisseur-TS génère un événement INDICATION que, on le suppose, l’utilisateur-TS attrape et sur lequel il agit. Bien que cela puisse être mis en œuvre en ayant un serveur qui "écoute" en s’accrochant à l’événement INDICATION, du point de vue du TSAP ISO, tous les utilisateurs-TS se tiennent autour dans l’état Inactif jusqu’à ce qu’ils génèrent une Demande ou acceptent une Indication.

4 Primitives

Le protocole suppose que le TCP de la [RFC 793] offre les primitives de service suivantes :

	Événements
connecté	- ouverture réussie (ACTIVE ou PASSIVE)
échec de connexion	- échec d’ouverture ACTIVE
données prêtes	- les données peuvent être lues sur la connexion
erroné	- la connexion a fait une erreur et est maintenant close
clos	- une déconnexion ordonnée a commencé
	Actions
écoute sur l’accès	- ouverture PASSIVE sur l’accès donné
accès ouvert	- ouverture ACTIVE sur l’accès donné
lire les données	- les données sont lues sur la connexion
envoyer les données	- les données sont envoyées sur la connexion
clore	- la connexion est close (les données en cours sont envoyées)

Le présent mémoire décrit comment utiliser ces services pour émuler les primitives de service suivantes, qui sont exigées par la norme [ISO8073] :

Le protocole offre les primitives de service suivantes, telles que définies dans [ISO8072], à l’usager-TS :

5 Protocole

Le protocole spécifié par le présent mémoire est identique au protocole pour la classe de transport 0 de l’ISO, avec les exceptions suivantes :

- pour les besoin des essais, les données initiales peuvent être échangées durant l’établissement de la connexion

- pour les besoins des essais, la prise en charge d’un service de données expédiées est assurée

- pour des raisons de performance, une taille de TSDU beaucoup plus grande est prise en charge

- le service réseau utilisé par le protocole est fourni par le TCP

Le protocole de transport ISO échange des informations entre homologues en unités discrètes d’information appelées des unités de données de protocole de transport (TPDU, transport protocol data unit). Le protocole défini dans le présent mémoire encapsule ces TPDU dans des unités discrètes appelées TPKT. La structure de ces TPKT et leurs relations avec les TPDU sont exposées dans la section suivante.

PRIMITIVES

La transposition entre les primitives du service TCP et les primitives de services attendues de la classe de transport 0 est presque directe :

La transposition des paramètres est aussi directe :

ÉTABLISSEMENT DE CONNEXION

Les éléments de procédure utilisés durant l’établissement de la connexion sont identiques à ceux présentés dans la norme [ISO8073], avec trois exceptions.

Afin de faciliter les essais, les TPDU de demande de connexion et de confirmation de connexion peuvent échanger des données initiales d’usager, en utilisant les champs données d’usager de ces TPDU.

Afin d’expérimenter les services de données expédiées, les TPDU de demande de connexion et de confirmation de connexion peuvent négocier l’utilisation du transfert des données expédiées en utilisant le mécanisme de négociation spécifié dans la norme [ISO8073] (par exemple, en mettant à un le bit "utiliser le service de transfert de données de transport expédiées" dans la partie variable "Choix d’options supplémentaires"). La valeur par défaut est de ne pas utiliser le service de transfert de données de transport expédiées.

Afin de réaliser de bonnes performances, la taille de TPDU est par défaut de 65 531 octets, au lieu de 128 octets. Afin de négocier une taille de TPDU plus petite (standard), le mécanisme de négociation spécifié dans la norme [ISO8073] est utilisé (par exemple, en réglant à un le bit désiré dans la partie variable "taille de TPDU").

Pour effectuer une action N-CONNECT.REQUEST, l’homologue-TS effectue une ouverture active à l’adresse IP désirée en utilisant l’accès TCP 102. Quand le TCP signale succès ou échec, il en résulte une action N-CONNECT.INDICATION.

Pour attendre un événement N-CONNECT.INDICATION, un serveur écoute sur l’accès TCP 102. Quand un client réussit à se connecter à cet accès, l’événement survient, et une action implicite N-CONNECT.RESPONSE est effectuée.

Note : Dans la plupart des mises en œuvre, un seul serveur va écouter en permanence sur l’accès 102, prenant les communications au fur et à mesure qu’elles sont établies.

TRANSFERT DES DONNÉES

Les éléments de procédure utilisés durant le transfert des données sont identiques à ceux présentés dans la norme [ISO8073], avec une exception : les données expédiées peuvent être prises en charge (si cela a été négocié durant l’établissement de la connexion) par l’envoi d’un TPDU ED modifié (décrit ci-dessous). Le TPDU est envoyé sur la même connexion TCP que celle des autres TPDU. Cette méthode, bien qu’elle trahisse l’esprit de la norme [ISO8072], est conforme à la lettre de la spécification.

Pour effectuer une action N-DATA.REQUEST, l’homologue-TS construit le TPKT désiré et utilise la primitive send data de TCP.

Pour déclancher une action N-DATA.INDICATION, le TCP indique que les données sont prêtes et un TPKT est lu en utilisant la primitive read data de TCP.

LIBÉRATION DE LA CONNEXION

Pour effectuer une action N-DISCONNECT.REQUEST, l’homologue-TS clôt simplement la connexion TCP.

Si le TCP informe l’homologue-TS que la connexion a été close ou a eu une erreur, cela indique un événement N-DISCONNECT.INDICATION.

6 Format de paquet

Une différence fondamentale entre le TCP et le service réseau attendu par TP0 est que le TCP gère un flux d’octets continu, sans limites explicites. Le TP0 attend que des informations soient envoyées et livrées dans des objets discrets appelés unités de données de service réseau NSDU, network service data unit). Bien que d’autres classes de transport puissent combiner plus d’une TPDU à l’intérieur d’un seul NSDU, le transport de classe 0 n’utilise pas cette facilité. Et donc, une NSDU est identique à une TPDU pour les besoins de notre exposé.

Le protocole décrit par le présent mémoire utilise un simple schéma de mise en paquet afin de délimiter les TPDU. Chaque paquet, appelé un TPKT, est vu comme un objet composé d’un nombre entier d’octets, de longueur variable.

Note : Pour les besoins de la présentation, ces objets sont montrés comme étant de 4 octets (32 bits de long). Cette représentation est un artifice de style du présent mémoire et ne devrait pas être interprété comme l’exigence que la longueur d’un TPKT soit un multiple de 4 octets.

Un TPKT comporte deux parties : un en-tête de paquet et une TPDU. Le format de l’en-tête est constant sans considération du type du paquet. Le format de l’en-tête de paquet est le suivant :

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| version | réservé | longueur de paquet |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

où :

version 8 bits

Ce champ est toujours 3 pour la version du protocole décrite dans le présent mémoire.

longueur de paquet 16 bits (min=7, max=65 535)

Ce champ contient la longueur du paquet entier en octets, y compris l’en-tête du paquet. Cela permets une taille maximum de TPDU de 65 531 octets. Sur la base de la taille du TPDU de transfert de données (DT), cela permet une taille maximum de TSDU de 65 524 octets.

Le format de la TPDU est défini dans la norme [ISO8073]. Noter que seuls les TPDU formatés pour le transport de classe 0 sont échangés (des classes de transport différentes peuvent utiliser des formats légèrement différents).

Pour la prise en charge des données expédiées, un format de TPDU non standard est permis. Le format utilisé pour le TPDU ED est presque identique au format pour les données normales, DT, TPDU. La seule différence est que la valeur utilisée pour le code de TPDU est ED, et non DT :

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|long. d'en-tête| code |crédit |TPDU-NR et EOT |données d’usgr |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ... | ... | ... | ... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ... | ... | ... | ... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ... | ... | ... | ... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Après le champ crédit (qui est toujours ZERO en sortie et ignoré en entrée) il y a un champ supplémentaire avant les données d’usager.

TPDU-NR et EOT 8 bits

Le bit 7 (le bit de plus fort poids, gabarit binaire 1000 0000) indique la fin d’une TSDU. Tous les autres bits devraient être ZERO en sortie et ignorés en entrée.

Noter que la spécification TP limite la taille d’une unité de données de service de transport expédié (XSDU, expedited transport service data unit) à 16 octets.

7 Commentaires

Depuis la publication de la RFC 983 en avril 1986, a été acquise une grande expérience de l’utilisation des services de transport ISO au dessus de TCP. En septembre 1986 a été introduite l’utilisation de la version 2 du protocole, principalement fondée sur les commentaires issus de la communauté de l’Internet.

En janvier 1987, on a observé que les différences entre la version 2 du protocole et la définition réelle de la classe 0 de transport étaient réellement très faibles. En regardant en arrière, on se rend compte que cette réalisation a pris beaucoup plus de temps qu’elle n’aurait dû : TP0 est destiné à fonctionner sur un service réseau fiable, par exemple, X.25. Le protocole TCP peut être utilisé pour fournir un service de ce type, et, si personne ne se plaint trop fort, on pourrait déclarer que le présent mémoire décrit simplement une méthode d’encapsulation de TP0 à l’intérieur de TCP !

Les changements pour passer de la version 1 à la version 2 du protocole puis à la version 3 sont tous relativement minces. Au départ, dans la description de la version 1, on avait décidé d’utiliser les formats de TPDU tirés du protocole de transport ISO. Cela a naturellement conduit à l’évolution décrite ci-dessus.

8 Références

[GOSIP86] The U.S. Government OSI User's Committee. "Government Open Systems Interconnection Procurement (GOSIP) Specification for Fiscal years 1987 and 1988." (décembre 1986) [en projet]

[ISO8072] ISO. International Standard 8072. "Information Processing Systems -- Open Systems Interconnection: Transport Service Definition." juin 1984

[ISO8073] ISO. International Standard 8073. "Information Processing Systems -- Open Systems Interconnection: Transport Protocol Specification." juin 1984

[ISO8327] ISO. International Standard 8327. "Information Processing Systems -- Open Systems Interconnection: Session Protocol Specification." juin 1984

[RFC791] "Protocole Internet" RFC 791 (MILSTD 1777) septembre 1981.

[RFC793] "Protocole de commande de transmission" RFC 793 (MILSTD 1778) septembre 1981.

[RFC983] "Services de transport ISO au-dessus de TCP". avril 1986

[X.214] CCITT. Recommandation X.214. "Transport Service Definitions for Open Systems Interconnection (OSI) for CCITT Applications." octobre 1984.

[X.224] CCITT. Recommandation X.224. "Transport Protocol Specification for Open Systems Interconnection (OSI) for CCITT Applications." octobre 1984.

[X.225] CCITT. Recommandation X.225. "Session Protocol Specification for Open Systems Interconnection (OSI) for CCITT Applications." octobre 1984.