Groupe de travail Réseau	Y. Pouffary, Digital Equipment Corporation	
Request for Comments : 2126	A. Young, ISODE Consortium	
Catégorie : En cours de normalisation	mars 1997	
Traduction Claude Brière de L'Isle		

Service de transport ISO par dessus TCP (ITOT)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Résumé
Le présent document est une révision du STD35, RFC1006 rédigé par Marshall T. Rose et Dwight E. Cass. Depuis la publication de la RFC1006 en mai 1987, beaucoup d'expérience a été accumulée dans l'utilisation de services de transport ISO par dessus TCP. Le présent document raffine le protocole et va finalement supplanter la RFC1006.

Le présent document décrit le mécanisme qui permet aux services de transport ISO de fonctionner sur TCP avec IPv4 ou IPv6. Il définit aussi un certain nombre de nouvelles caractéristiques qui n'étaient pas prévues dans la RC1006.

Le but de cette version est de minimiser le nombre de changements aux définitions de protocole de transport de la RFC1006 et de la norme ISO 8073, tout en maximisant les performances, en étendant son applicabilité et en protégeant la base installée d'utilisateurs de la RFC1006.

Table des matières
1. Introduction, motivations	1
2. Le modèle	2
2.1 Modèle de transport ISO	2
2.2 Modèle de transport ISO sur TCP (ITOT)	3
2.3 Vue générale du protocole et du service	3
3 Définition du service	3
3.1 Définition du service de transport	3
3.2 Définition du service réseau	4
4. Spécification du protocole de transport	6
4.1 Classe 0 sur TCP	7
4.2 Classe 2 sur TCP	7
4.3 Format de paquet TPKT	10
5. Représentations d'adresse	10
5.1 Représentation de chaîne des adresses de point d'accès ITOT	10
5.2 Codage d'adresse réseau OSI	11
6. Notes pour la mise en œuvre	11
6.1 Établissement de connexion TCP	11
6.2 Transfert de données TCP	11
6.3 Négociation de classe	11
6.4 Taille maximum de TPDU par défaut	11
6.5 Codage du bit de TPDU de classe 0	11
6.6 Options de classe 2	12
6.7 Accusé de réception de données expédiées de classe 2	12
6.8 Traitement des données de classe 2 normales et expédiées	13
6.9 Procédure de connexion de transmission de classe 2	13
6.10 TPKT	13
7. Raisons – interopérabilité avec la RFC1006	13
8. Considérations pour la sécurité	14

1.	Introduction, motivations

Deux approches de base peuvent être suivies pour "porter" des applications ISO dans des environnements TCP/IP ([RFC793], [RFC791]) et IPv6 [RFC1883]. Une approche est de porter chaque application individuelle séparément, en développant des protocoles locaux par dessus TCP. Une seconde approche se fonde sur la notion de mise en couches du service de transport ISO sur TCP/IP. Cette approche résout le problème pour toutes les applications qui utilisent le service de transport ISO. Le présent document décrit cette seconde approche.

Le protocole décrit dans le présent mémoire se fonde sur l'observation que la suite des protocoles de l'Internet et la suite de protocoles ISO sont toutes deux des systèmes en couches. Un aspect clé du principe de mise en couches est l'indépendance des couches. Le concept d'indépendance des couches signifie que si on préserve les services offerts par une couche particulière (le fournisseur de service) l'utilisateur de service à cette couche n'est alors pas du tout affecté par les changements dans les couches sous-jacentes ou par le protocole utilisé au sein de la couche.

Le présent document définit un service de transport qui apparaît comme identique aux services et interfaces offerts par la définition de service de transport ISO [ISO8072], mais qui va en fait mettre en œuvre le protocole de transport ISO [ISO8073] par dessus TCP/IP (IPv4 ou IPv6) plutôt que le service réseau ISO [ISO8348].

La base du présent document est le STD35, [RFC1006] rédigé par Marshall T. Rose et Dwight E. Cass et il définit deux classes de service de transport. La classe de transport 0 précise et se substitue au protocole de la RFC1006 et vise à préserver la base installée de la RFC1006. La classe de transport 2 définit un certain nombre de nouvelles caractéristiques qui ne sont pas fournies dans la RFC1006, comme l'indépendance des canaux de données normales et expédiées et la déconnexion explicite du transport. Ces nouvelles caractéristiques se fondent largement sur la [RFC1859] et étendent l'applicabilité de la RFC1006 à de nouveaux groupes d'applications.

Le présent document spécifie des changements aux normes mentionnées ci-dessus et il doit être lu dans le contexte des normes susmentionnées. Il n'a pas de signification par lui-même.

L'accès TCP "bien connu" 102 est réservé pour les hôtes qui mettent en œuvre le protocole décrit dans le présent document. Noter que le protocole ne rend pas obligatoire l'utilisation de l'accès TCP 102 pour toutes les connexions.

2.	Le modèle
Cette section décrit les différences entre le modèle utilisé par le transport ISO et celui décrit dans le présent document.

2.1	Modèle de transport ISO
La norme ISO 8072 décrit la définition du service de transport ISO (TS). La définition du service de transport ISO décrit les services offerts par le fournisseur du service de transport et les interfaces utilisées pour accéder à ces services.

La norme ISO 8073 décrit la spécification du protocole de transport ISO (TP). Le protocole de transport ISO spécifie les règles de codage communes et un certain nombre de classes de procédure de protocole de transport qui peuvent être utilisées avec différentes qualités de service réseau.

La norme ISO 8348 décrit la définition de service réseau ISO (NS). La définition de service réseau ISO décrit les services offerts par le fournisseur de service réseau et les interfaces utilisées pour accéder à ces services.
Le service réseau ISO spécifie deux types de service :
-	service réseau en mode connexion (CONS, Connection Oriented Network Service)
-	service réseau sans connexion (CLNS, ConnectionLess Network Service)

Le protocole de transport ISO spécifie cinq classes de procédures lors du fonctionnement sur CONS et une classe de procédure en fonctionnement sur CLNS.
Les relations entre ces normes ISO sont illustrées ci-dessous :

        Utilisateur du service  de transport
              |
              |-Définition du service de transport [ISO8072]
              |
         +--------------------------------------------------+
         |  Fournisseur du service de transport             |
         | Spécification du protocole de transport [ISO8073]|
         +--------------------------------------------------+
              |
              |-Définition du service réseau ISO [ISO8348]
              |
2.2	Modèle de transport ISO sur TCP (ITOT)
Le présent document définit un modèle pour la fourniture du service de transport ISO, avec des extensions mineures, qui fonctionne sur TCP.

Le service de transport ISO 8072 est pris en charge avec des modifications. Voir au paragraphe 3.1.

Le protocole de transport ISO 8073 est utilisé avec quelques modifications pour fournir le service de transport modifié.

Le protocole de contrôle de transmission est utilisé à la place de la norme ISO 8348 pour fournir un service de type CONS. Voir à la section 4.

Le présent document spécifie un mécanisme de simple encapsulation entre le protocole de transport ISO 8073 modifié et TCP.

Le protocole de transport ISO 8073 spécifie cinq classes en fonctionnement sur CONS ISO 8348. Le présent document spécifie comment fonctionnent les classes 0 et 2 sur TCP. Le présent document n'empêche pas l'utilisation des autres classes sur TCP, mais leur spécification sort du domaine d'application du présent document.

Les relations de ces normes sont illustrées ci-dessous :

        Utilisateur de service transport
              |
              |-Service transport ISO (modifié)
              |
         +--------------------------------------------------------+
         |  Fournisseur de service Transport                      |
         |  Spécification du protocole de transport ISO (modifié) |
         +--------------------------------------------------------+
              |
              |-TCP comme service réseau en mode connexion 
              |
2.3	Vue générale du protocole et du service
Le présent document définit l'usage du protocole de transport ISO (avec des extensions) qui fonctionne sur TCP. Deux variantes du protocole sont définies, "Classe 0 sur TCP" et "Classe 2 sur TCP", qui sont étroitement liées au protocole de transport ISO de classe 0 et 2.

La Section 3 définit le service offert à l'utilisateur de transport par ce protocole, et montre les différences avec le service transport ISO. La transposition entre les primitives du service dans le service réseau ISO et TCP est définie. La Section 4 définit le protocole de transport.

3	Définition du service

Cette section décrit le service transport offert à l'utilisateur du transport. Elle définit aussi la transposition entre la définition de service réseau et la définition de service TCP.

3.1	Définition du service de transport
Le service de transport ISO 8072 est pris en charge avec les extensions suivantes :
-	L'utilisation e du paramètre Qualité de service n'est pas définie.
-	Accès à la déconnexion sans interruption du transport.

3.1.1	Primitives de définition du service de transport
Les informations sont transférées de et vers l'utilisateur TS dans les primitives du service transport dont la liste figure ci-dessous :

Actions

T-CONNECT.REQUEST
-	un utilisateur TS indique qu'il veut établir une connexion de transport

T-CONNECT.RESPONSE
-	un utilisateur TS indique qu'il va satisfaire la demande

T-DISCONNECT.REQUEST
-	un utilisateur TS indique que la connexion de transport va être fermée

T-DATA.REQUEST
-	un utilisateur TS envoie des données

T-EXPEDITED DATA.REQUEST
-	un utilisateur TS envoie des données "expédiées"

Événements

T-CONNECT.INDICATION
-	un utilisateur TS est notifié de l'établissement en cours d'une connexion de transport

T-CONNECT.CONFIRMATION
-	un utilisateur TS est notifié de l'établissement de la connexion de transport.

T-DISCONNECT.INDICATION
-	un utilisateur TS est notifié de la fermeture de la connexion de transport.

T-DATA.INDICATION
-	un utilisateur TS est notifié de la possibilité de lecture des données à partir de la connexion de transport.

T-EXPEDITED_DATA.INDICATION
-	un utilisateur TS est notifié de la possibilité de lecture des données expédiées à partir de la connexion de transport.

3.2	Définition du service réseau
Ce paragraphe décrit comment TCP est utilisé pour fournir CONS ISO 8348.

3.2.1	Primitives CONS ISO 8348
Les informations sont  transférées de et vers le fournisseur NS dans les primitives du service réseau dont la liste figure ci-dessous :

Actions

N-CONNECT.REQUEST
-	un utilisateur NS indique qu'il veut établir une connexion réseau.

N-CONNECT.RESPONSE
-	un utilisateur NS indique qu'il va satisfaire la demande.

N-DISCONNECT.REQUEST
- 	un utilisateur NS indique que la connexion réseau va être fermée.

N-DATA.REQUEST
-	un utilisateur NS envoie des données.

N-EXPEDITED_DATA.REQUEST
-	un utilisateur NS envoie des données "expédiées".

Événements

N-CONNECT.INDICATION
-	un utilisateur NS est notifié de l'établissement en cours d'une connexion réseau.

N-CONNECT.CONFIRMATION
-	un utilisateur NS est notifié de la réussite de l'établissement de la connexion réseau.

N-DISCONNECT.INDICATION
-	un utilisateur NS est notifié de la clôture de la connexion réseau.

N-DATA.INDICATION
-	un utilisateur NS est notifié de la possibilité de lecture des données à partir de la connexion réseau.

N-EXPEDITED_DATA.INDICATION
-	un utilisateur NS est notifié de la possibilité de lecture des données expédiées à partir de la connexion.

3.2.2	Primitives de service TCP
La transposition entre les primitives CONS ISO 8348 et les primitives du service TCP, définie dans le présent document, suppose que le TCP offre les primitives de service suivantes :

Actions

TCP-LISTEN_PORT
-	ouverture PASSIVE sur l'accès donné.

TCP-OPEN_PORT
-	ouverture ACTIVE sur l'accès donné.

TCP-READ_DATA
-	les données sont lues à partir de la connexion.
TCP-SEND_DATA
-	les données sont envoyées sur la connexion.

TCP-CLOSE
-	la connexion est fermée (les données en cours sont envoyées).

Événements

TCP-CONNECTED
-	ouverture réussie (ACTIVE ou PASSIVE).

TCP-CONNECT_FAIL
-	échec de l'ouverture ACTIVE

TCP-DATA_READY
-	les données peuvent être lues à partir de la connexion.

TCP-ERRORED
-	la connexion a une erreur et est maintenant close.

TCP-CLOSED
-	une déconnexion ordonnée a commencé.

3.2.3	Transposition de TCP en fournisseur d'accès réseau
3.2.3.1	Établissement de connexion réseau
Afin de réaliser l'action N-CONNECT.REQUEST, le fournisseur TS effectue une TCP-OPEN_PORT sur l'adresse IPv4 ou IPv6 en utilisant l'accès TCP choisi. Lorsque le TCP signalé la réussite ou l'échec, il en résulte une action N-CONNECT.INDICATION.

Afin d'attendre un événement N-CONNECT.INDICATION, un serveur effectue un TCP-LISTEN_PORT sur l'accès TCP choisi. Lorsque un client réussit à se connecter à cet accès, l'événement TCP-CONNECTED survient et une action N-CONNECT.RESPONSE implicite est effectuée.

La transposition des paramètres entre le service TCP et le service CONS ISO 8348 est faite comme suit :

Service réseau	Établissement de connexion TCP
Adresse appelée	adresse IPv4 ou IPv6 et numéro d'accès TCP du serveur.
Adresse appelante	adresse IPv4 ou IPv6 du client
Tous les autres paramètres	ignorés

Prière de se reporter aux "Notes pour la mise en œuvre" au paragraphe 6.1.

L'accès TCP 102 est réservé aux mises en œuvre qui se conforment à la présente spécification. L'utilisation de tout accès TCP est conforme à la présente spécification.

3.2.3.2	Transfert de données réseau
Pour effectuer une action N-DATA.REQUEST, le fournisseur TS construit l'unité de données de protocole de transport désiré (TPDU, transport protocol data unit), encapsule la TPDU dans une unité discrète appelée TPKT et utilise la primitive TCP-SEND_DATA. Prière de se référer aussi aux "Notes de mise en œuvre" du paragraphe 6.2.

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

La transposition des paramètres entre le service TCP et le service CONS ISO 8348 est faite comme suit :

Service réseau	Transfert de données TCP
Données d'utilisateur NS (NSDU)	Données

3.2.3.3	Libération de la connexion réseau
Pour effectuer une action N-DISCONNECT.REQUEST, le fournisseur TS ferme simplement la connexion TCP par une primitive TCP-CLOSE.

Pour déclancher une N-DISCONNECT.INDICATION, le TCP indique que la connexion a été close par un événement TCP-CLOSE. Si la connexion TCP a échoué, le TCP indique que la connexion a été close par un événement TCP-ERRORED, cela déclanche une N-DISCONNECT.INDICATION.

La transposition des paramètres entre le service TCP et le service CONS ISO 8348 est faite comme suit :

Service réseau	TCP
Libération de connexion
Tous les paramètres	ignorés

4.	Spécification du protocole de transport

Les classes 0 et 2 du protocole de transport ISO 8073 sont prises en charge avec les extensions définies dans les paragraphes ci-dessous.

Une classe de protocole de transport est choisie pour une connexion de transport particulière sur la base des exigences de l'utilisateur TS.

Le protocole de transport ISO 8073 échange des informations entre homologues dans des unités d'information discrètes appelées unités de données de protocole de transport (TPDU, transport protocol data unit). Le protocole défini dans le présent document encapsule ces TPDU dans des unités discrètes appelées paquets de transport (TPKT).

Le présent document rend obligatoire la mise en œuvre de la négociation des options du protocole de transport ISO 8073 (qui inclut la négociation de classe).

Prière de se référer aux "Notes pour la mise en œuvre" du paragraphe 6.3 pour la négociation de classe et à la section 7 "Raisons" pour l'interopérabilité avec la RFC1006.

4.1	Classe 0 sur TCP
La classe 0 apporte les fonctions nécessaires pour l'établissement de la connexion avec négociation, au transfert de données avec segmentation, et au rapport d'erreurs de protocole. Elle fournit la connexion de transport avec contrôle de flux sur la base de celle du fournisseur NS (TCP). Elle fournit la déconnexion du transport sur la base de la déconnexion du fournisseur NS.

La classe 0 convient pour le transfert de données sans déconnexion explicite du transport.

4.1.1	Établissement de la connexion
Les principes utilisés pour l'établissement de la connexion se fondent sur ceux qui sont décrits dans la norme ISO 8073, avec les extensions suivantes :

-	Les données de connexion peuvent être échangées en utilisant les champs de données d'utilisateur des TPDU des demandes de connexion (CR, Connect Request) et des confirmations de connexion (CC, Connect Confirm).

-	L'utilisation du "service de transfert de données expédiées" peut être négocié en utilisant le mécanisme de négociation spécifié dans la norme ISO 8073. La valeur par défaut est la non utilisation du "service de transfert de données expédiées".

-	Une taille de TPDU non standard peut être négociée en utilisant le mécanisme de négociation spécifié dans la norme ISO 8073. La taille maximum de TPDU est de 65 531 octets. La taille maximum de TPDU par défaut est de 65 531 octets. Prière de se référer aux "Notes de mise en œuvre" du paragraphe 6.4.

4.1.2	Transfert des données
Les éléments de procédure utilisés durant le transfert sont fondés sur ceux présentés dans la norme ISO 8073, avec l'extension suivante :

-	Les données expédiées peuvent être prises en charge (si elles sont négociées durant l'établissement de la connexion) en envoyant la TPDU de données expédiées (ED, Expedited Data) définie.

La TPDU d'ES est envoyée dans la bande sur la même connexion TCP que toutes les autres TPDU.

Une TPDU non standard est définie pour prendre en charge les donnés expédiées. Le format utilisé pour la TPDU ED est presque identique au format pour la TPDU de données normales (DT). La seule différence entre les TPDU ED et DT est que la valeur utilisée pour le code de TPDU est ED et non DT. La taille d'un champ de données d'utilisateur Données expédiées est de 1 à 16 octets.

Pour le codage du bit de TPDU, prière de se référer aux "Notes de mise en œuvre" du paragraphe 6.5.

4.1.3	Libération de connexion
Les éléments de procédure utilisés durant une libération de connexion sont identiques à ceux présentés dans la norme ISO 8073.

La déconnexion du transport se fonde sur la déconnexion du fournisseur NS (TCP) et elle provoque donc l'interruption.

4.2	Classe 2 sur TCP
La classe 2 fournit les fonctions nécessaires pour l'établissement de la connexion avec négociation, transfert des données avec segmentation, et rapport des erreurs du protocole. Elle fournit la connexion du transport avec contrôle de flux fondé sur celui du fournisseur NS (TCP). Elle fournit la déconnexion explicite du transport.

La classe 2 convient lorsque est exigée l'indépendance des canaux de données normales et expédiées, ou quand est nécessaire la déconnexion explicite du transport.

4.2.1	Établissement de la connexion
Les principes utilisés dans l'établissement de la connexion se fondent sur ceux décrits dans la norme ISO 8073, avec les extensions suivantes :

-	Les TPDU de demande de connexion et de confirmation de connexion peuvent négocier l'usage du service de "Transfert de données en transport expédié". Le service de "Transfert de données en transport expédié" est sélectionné en établissant le bit 1 du paramètre "Option supplémentaire", et est négocié en utilisant le mécanisme spécifié dans la norme ISO 8073.

La valeur par défaut est de ne pas utiliser le service "Transfert de données en transport expédié".

-	Les TPDU de demande de connexion et de confirmation de connexion peuvent négocier l'usage de "Accusé de réception de données expédiées". "Accusé de réception de données expédiées" est sélectionné en établissant le bit 6 du paramètre "Option supplémentaire", et il est négocié en utilisant le mécanisme spécifié dans la norme ISO 8073.
La valeur par défaut est de ne pas utiliser "Accusé de réception de données expédiées" pour le transfert de données expédiées.

-	Les TPDU de demande de connexion et de confirmation de connexion peuvent négocier l'usage du service "Non blocage de données expédiées". "Non blocage de données expédiées" est sélectionné en établissant le bit 7 du paramètre "Option supplémentaire", et est négocié en utilisant le mécanisme spécifié dans la norme ISO 8073.

La valeur par défaut est de ne pas utiliser le service "Non blocage de données expédiées".

-	Les TPDU de demande de connexion et de confirmation de connexion peuvent négocier l'usage de la procédure "Connexion vers l'avant (partage et recombinaison)" ou de "Connexion inverse" pour le transfert des données expédiées.

L'utilisation de la procédure de "Connexion vers l'avant" ou de "Connexion inverse" est sélectionnée en établissant le bit 4 du paramètre "Option supplémentaire", et elle est négociée en utilisant le mécanisme spécifié dans la norme ISO 8073.

La valeur par défaut est d'utiliser la procédure "Connexion vers l'avant" pour le transfert de données expédiées.

-	Les TPDU de demande de connexion et de confirmation de connexion ne doivent pas négocier l'utilisation du "contrôle explicite de flux".

-	Une taille non standard de TPDU peut être négociée en utilisant le mécanisme de négociation spécifié dans la norme ISO 8073. La taille maximum de TPDU est de 65 531 octets. La taille maximum de TPDU par défaut est de 65 531 octets. Prière de se référer aux "Notes de mise en œuvre" du paragraphe 6.4.

En l'absence d'une politique de contrôle de flux, l'utilisation de la procédure de multiplexage de la norme ISO 8073 conduit à une dégradation de la qualité de service. Le protocole défini dans le présent document ne prend pas en charge le multiplexage.
Pour les valeurs du paramètre "Option supplémentaire", prière de se référer aux "Notes de mise en œuvre" du paragraphe 6.6.

Pour le profil d'options de classe 2, prière de se référer aussi aux "Notes de mise en œuvre" du paragraphe 6.6.

4.2.2	Transfert des données
Les éléments de procédure utilisés durant le transfert se fondent sur ceux présentés dans la norme ISO 8073, avec les extensions suivantes :

-	Les données expédiées peuvent être prises en charge (si elles sont négociées durant l'établissement de la connexion) par l'envoi du TPDU de données expédiées (ED, Expedited Data).

-	"Accusé de réception de données expédiées" peut être pris en charge (si il est négocié durant l'établissement de la connexion) par l'envoi du TPDU d'accusé de réception de données expédiées (EA, Expedited Data Acknowledgement).

Lors de l'utilisation d'un "Accusé de réception de données expédiées", les TPDU ED exigent un accusé de réception, et une fois qu'une TPDU ED a été émise, aucune autre TPDU DT/ED ne peut être envoyée tant que la TPDU ED en instance n'a pas été acquittée.

Lorsque la non utilisation des "accusés de réception de données expédiées" a été négociée, les TPDU ED n'exigent aucun acquittement, et d'autres TPDU DT/ED peuvent être envoyés immédiatement.

Prière de se référer aux "Notes des mise en œuvre" des paragraphes 6.7 et 6.8.

-	Le service de "non blocage des données expédiées" peut être pris en charge (si il est négocié durant l'établissement de la connexion).

Quand le service "non blocage des données expédiées" est utilisé, l'envoyeur d'un TPDU ES devra envoyer le TPDU ED sur les deux connexions TCP de données normales et de données expédiées. La transmission de TPDU DT ultérieures ne sera pas interrompue. Le receveur de TPDU ED compte combien il a vu de TPDU ED sur chaque connexion TCP, et ne va délivrer à l'utilisateur TS que la TPDU ED provenant de la connexion TCP qui a le compte le plus élevé.

Quand la non utilisation de "non blocage des données expédiées" a été négocié, les TPDU ED ne seront pas dupliqués.

Prière de se référer aux "Notes de mise en œuvre" des paragraphes 6.7 et 6.8.

-	Pour un transfert de données expédiées, il y a deux procédures possibles pour l'établissement et l'allocation de connexion TCP de données expédiées. Celle qui est utilisée est négociée durant l'établissement de la connexion.

Les deux procédures de "Connexion vers l'avant" et de "Connexion inverse" garantissent l'indépendance de la connexion TCP de données normales à l'égard de la connexion TCP de données expédiées. Elles assurent aussi que l'occupation d'une connexion TCP de données normales ne peut pas bloquer une connexion TCP de données expédiées.

La connexion TCP de données expédiées créée par l'une ou l'autre procédure doit être entre la même paire d'hôtes que la connexion TCP de données normales, elle ne doit pas être partagée entre des connexions de transport, et doit rester établie jusqu'à ce que la connexion de transport soit terminée, moment auquel elle doit être close.

Les connexions TCP créées pour le transfert de données expédiées devraient aussi utiliser les primitives TCP définies dans le présent document.

La procédure de connexion vers l'avant (partage et recombinaison) est définie dans la norme ISO 8073. Cette procédure permet à une connexion de transport d'utiliser plusieurs connexions TCP. Prière de se référer aux "Notes de mise en œuvre" du paragraphe 6.9.

La procédure de connexion inverse n'est pas définie dans la norme ISO 8073. Quand on utilise la procédure de connexion inverse, l'initiateur d'une connexion de transport crée une connexion TCP de données normales en utilisant un accès TCP local "x" choisi arbitrairement et un accès TCP distant connu (soit l'accès bien connu ITOT, soit un autre accès). L'initiateur écoute une connexion TCP entrante sur l'accès TCP "x". Le répondant de la connexion de transport doit créer une seconde connexion TCP (à utiliser pour les données expédiées) en utilisant un accès TCP "y" arbitrairement choisi et l'accès TCP distant "x", avant qu'il puisse produire une TPDU CC sur la connexion TCP de données normales. L'initiateur n'a pas besoin d'écouter d'autres connexions TCP sur l'accès "x" après l'établissement de la connexion TCP de données expédiées.

4.2.3	Libération de la connexion
Les éléments de procédure utilisés durant une libération de connexion se fondent sur ceux décrits dans la norme ISO 8073. Une connexion peut être terminée par l'utilisateur TS d'une des deux façons suivantes :
-	Déconnexion interruptive
-	Déconnexion non interruptive

Les TPDU de demande de déconnexion (DR, Disconnect Request) et de confirmation de déconnexion (DC, Disconnect Confirm) sont échangés dans les deux cas. La TPDU DR porte un code de cause qui indique la raison de la déconnexion.

Une déconnexion interruptive spécifie que toutes les TPDU qui sont encore à la source ne sont pas nécessairement envoyées à la destination avant la déconnexion de la connexion. Le code de cause DR est normal (80 hex).

La déconnexion non interruptive spécifie que toutes les TPDU déjà données au fournisseur TS local doivent être livrées à l'utilisateur TS distant avant que la connexion soit déconnectée. Le code de cause DR est normal (80 hex) avec le paramètre Informations supplémentaires réglé à 80 hex.

4.3	Format de paquet TPKT
Une différence fondamentale entre TCP et le service réseau ISO attendu par le transport ISO est que TCP gère un flux d'octets continu, sans frontières explicites.

Le transport ISO 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 Units). Bien que le transport ISO permette une combinaison de plus d'une TPDU à l'intérieur d'une seule NSDU, pour les besoins de cet exposé, une NSDU est identique à une TPDU. Prière de se référer à la norme ISO 8073 pour voir l'ensemble valide des TPDU concaténés.

Le protocole décrit dans le présent mémoire utilise un simple schéma de mise en paquets afin de délimiter une TPDU. Chaque paquet (TPKT), est vu comme un objet de longueur variable, composé d'un nombre entier d'octets.

Un TPKT comporte deux parties :
-	un en-tête de paquet
-	une TPDU.

Le format de l'en-tête de paquet est constant sans considération du type de TPDU. Le format de l'en-tête de paquet est le suivant :

   +--------+--------+----------------+-----------....---------------+
   |version |réservé |longueur de pqt |             TPDU             |
   +----------------------------------------------....---------------+
   <8 bits> <8 bits> <   16 bits    > <    longueur variable        >

où :
-	Numéro de version du protocole
longueur : 8 bits
Valeur :  3

-	Réservé
longueur : 8 bits
Valeur :  0 - (Voir les "Notes de mise en œuvre" au paragraphe 6.10)

-	Longueur de paquet
longueur : 16 bits
Valeur :  Longueur du TPKT entier en octets, y compris l'en-tête de paquet

-	TPDU
C'est la TPDU du transport ISO telle que définie dans la norme ISO 8073 et telle que définie dans le présent document.

5.	Représentations d'adresse

Il est désirable d'être capable de représenter les adresses de point d'accès ITOT sous la forme :
-	de chaîne imprimables,
-	d'adresses réseau OSI (souvent appelées adresses NSAP ou simplement NSAPA)

La présente section définit les formats qui DOIVENT être utilisés dans chaque cas.

5.1	Représentation de chaîne des adresses de point d'accès ITOT
La [RFC1278] définit une représentation générale de chaîne pour les adresses de présentation OSI, y compris une référence spécifique aux adresses de la RFC1006 qui encapsule les adresses IPv4. La RFC1278 est aussi applicable aux adresses ITOT qui encapsulent des adresses IPv4.

La présente RFC fait actuellement l'objet d'une mise à jour pour définir une représentation de chaîne pour les adresses ITOT qui encapsulent des adresses IPv6.

La représentation de chaîne d'adresse de point d'accès ITOT spécifie une adresse IP (IPv4 ou IPv6) et un numéro d'accès TCP facultatif.

5.2	Codage d'adresse réseau OSI
La [RFC1277] définit un mécanisme général pour coder les informations d'adressage au sein des adresses réseau OSI (NSAPA), y compris une référence spécifique à la RFC1006 utilisant IPv4. La RFC1277 est aussi applicable aux adresses ITOT qui utilisent IPv4.

La [RFC1883] sur les adresses IPv6 à l'intérieur d'un NSAPA définit un mécanisme général pour la prise en charge de l'adressage NSAP dans un réseau IPv6. Elle définit aussi comment incorporer une adresse IPv6 dans une adresse OSI NSAP.

La présente RFC est applicable aux adresses ITOT qui utilisent IPv6. Pour les adresses ITOT, le sélecteur par défaut de la NSAPA est défini comme ayant la valeur '10000000'B.

On notera qu'étant donné que les adresses IPv6 peuvent coder les adresses IPv4, ce format peut aussi coder les adresses ITOT qui utilisent IPv4.

6.	Notes pour la mise en œuvre
6.1	Établissement de connexion TCP
Les développeurs devraient être conscients de ce que les protocoles de transport ISO supposent que le fournisseur de service réseau (dans la cas présent, TCP/IP) leur dira quand la connexion réseau utilisée pour transmettre leurs TPDU se termine de façon inattendue. Il est donc fortement suggéré que le TCP garde en vie le mécanisme qui est choisi pour ce faire, car il assure le rapport des pertes de connexion réseau.

6.2	Transfert de données TCP
Il est suggéré pour des raisons de performances que l'algorithme de Nagle de la [RFC0896] soit désactivé (en utilisant l'option de prise TCP_NODELAY). Cette caractéristique permet aux données TPKT d'être envoyées sans délai.

6.3	Négociation de classe
Le principe utilisé dans la négociation de classe est identique à ceux décrits dans la norme ISO 8073. La classe et les options sont négociées durant l'établissement de la connexion. Le choix fait par le transport va dépendre des exigences de l'utilisateur TS, telles qu'exprimées via les primitives de service T-CONNECT.

L'initiateur de la connexion de transport propose une classe préférée et peut proposer une classe de remplacement.

Le répondant choisit une classe définie dans le tableau ci-dessous.

Si la classe préférée n'est pas choisie, alors à réception de la TPDU de confirmation de connexion, l'initiateur ajuste son fonctionnement en fonction de la classe choisie.

Proposé dans le TPDU CR	
Classe préférée	Classe de remplacement	
classe 0	aucune	
classe 2	classe 0	
classe 2	aucune	

6.4	Taille maximum de TPDU par défaut
La valeur par défaut de taille maximum de TPDU spécifiée dans le présent document rompt avec la règle de négociation du transport ISO qui déclare que la taille maximum de TPDU spécifiée ou par défaut par la TPDU CC ne peut pas être supérieure à la taille maximum de TPDU proposée par la TPDU CR.

Pour éviter les conséquences de cela, il est vivement recommandé que la TPDU CC spécifie toujours la valeur maximum de taille de TPDU.

6.5	Codage du bit de TPDU de classe 0
Le présent protocole ne permet plus que les champs crédit et TPDU-NR (bits 0 à 6) soient ignorés en entrée, ce qui est conforme aux règles de codage de la norme ISO 8073. Le codage de TPDU de la RFC1006 définissait des règles de codage non cohérentes.

6.6	Options de classe 2
Valeur du paramètre Option supplémentaire de classe 2 

Bit	Option	
8	Non applicable	
7	= 1 Utilisation de données expédiées non bloquantes
= 0 Non utilisation de données expédiées non bloquantes (valeur par défaut)	
6 (*)	= 1 Utilisation d'acquittement de données expédiées
= 0 Non utilisation d'acquittement de données expédiées (valeur par défaut)	
5	Non applicable	
4 (*)	= 1 Utilisation de la procédure de connexion inverse
= 0 Utilisation de la procédure de connexion vers l'avant (valeur par défaut)	
3	Non applicable	
2	Non applicable	
1	= 1 Utilisation du service de données expédiées de transport
= 0 Non utilisation du service de données expédiées de transport (valeur par défaut)	

(*)	Dans la norme ISO 8073, le bit 4 est défini comme l'utilisation de "Expédié par le réseau" et le bit 6 est défini comme "Accusé de réception de demande".

Profil des options de classe 2

Bits 1 4 6 7	Service choisi
       0 x x x	Non utilisation du service de données expédiées de transport
	Les bits 4 6 7 ne sont pas applicables (*) 
      1 x x x	Utilisation du service de données expédiées de transport
      1 0 x x	Utilisation du service de données expédiées avec connexion vers l'avant
      1 0 1 0	Connexion vers l'avant avec acquittement des données expédiées
      1 0 1 1	Connexion vers l'avant avec acquittement des données expédiées et usage de données expédiées non bloquantes (**)
      1 0 0 0	Connexion vers l'avant avec non utilisation de l'acquittement des données expédiées (***)
      1 0 0 1	Connexion vers l'avant avec non utilisation de l'acquittement des données expédiées et usage de données expédiées non bloquantes
      1 1 x x	Usage du service de données expédiées avec connexion inverse|
      1 1 1 0	Connexion inverse avec acquittement des données expédiées
      1 1 1 1	Connexion inverse avec acquittement des données expédiées et usage de données expédiées non bloquantes (**)
      1 1 0 0	Connexion inverse avec non utilisation de l'acquittement des données expédiées (***)
      1 1 0 1	Connexion inverse avec non utilisation de l'acquittement des données expédiées et usage de données expédiées non bloquantes

(*)	Noter que la valeur par défaut (0000) donne un service du style de celui de la RFC1006 avec déconnexion explicite du transport.
(**)	Noter que dans ce cas, l'utilisation de l'acquittement des données expédiées avec usage de données expédiées non bloquantes est un pur gaspillage (Voir au paragraphe 6.5)
(***)	Noter que dans ce cas les TPDU de données normales et expédiées ne sont pas synchronisées. (Voir au paragraphe 6.6)

6.7	Accusé de réception de données expédiées de classe 2
Le protocole spécifié dans le présent document ne définit aucune relation entre l'utilisation de l'option "Acquittement des données expédiées" et l'utilisation du service "Données expédiées non bloquantes".

On est cependant prié de noter que c'est un pur gaspillage d'utiliser le service "Données expédiées non bloquantes" avec un "Accusé de réception de données expédiées", car les TPDU ED sont dupliqués et envoyés sur les deux connexions TCP de données normales et expédiées.

6.8	Traitement des données de classe 2 normales et expédiées
Il existe deux exigences d'application séparées pour l'utilisation des données expédiées :
1-	Synchronisation de l'ordre de livraison entre TPDU de données normales et expédiées.
2-	Indépendance des canaux de données normales et expédiées. Un canal de données normales occupé ne devrait pas bloquer un canal de données expédiées.

Le protocole décrit dans le présent document peut s'accommoder des deux exigences, séparément ou en combinaison.

Synchronisation :
Si la synchronisation de l'ordre de livraison entre les TPDU de données normales et expédiées est exigée, l'utilisation de la TPDU d'acquittement de données expédiées ou du service de données expédiées non bloquantes doit être négociée durant l'établissement de la connexion.

Si la synchronisation de l'ordre de livraison entre les TPDU de données normales et expédiées n'est pas exigée, il n'est pas nécessaire de négocier durant l'établissement de la connexion la non utilisation d'un "acquittement de données expédiées".

Indépendance :
Si l'indépendance des canaux de données normales et expédiées est exigée, la connexion vers l'avant ou inverse doit être négociée durant l'établissement de la connexion. La TPDU de données expédiées doit être envoyée sur le canal de données expédiées.

Si l'indépendance des canaux de données normales et expédiées n'est pas exigée, la connexion vers l'avant devrait alors être négociée durant l'établissement de la connexion et les canaux de données expédiées ne devraient jamais être établis. La TPDU de données expédiées est alors envoyée dans la bande sur le canal des données normales.

Prière finalement de noter que l'indépendance des canaux de données normales et expédiées sans synchronisation assouplit la définition du service de transport des données expédiées et n'est pas cohérente avec celle de la norme ISO 8072.

6.9	Procédure de connexion de transmission de classe 2
Comme défini dans la norme ISO 8073, lorsque la procédure de "connexion vers l'avant" (partage et recombinaison) est utilisée pour la transmission de données expédiées, la TPDU ED ne doit être envoyée que sur une connexion TCP sortante  de fournisseur de service réseau.

Comme défini dans la norme ISO 8073, le présent document ne rend pas obligatoire l'utilisation de la procédure de partage pour la transmission des données expédiées. On doit appliquer la procédure de recombinaison, qui associe les TPDU de données (normales et expédiées) qui arrivent pour une connexion de transport sur deux connexions TCP.

Il est légal d'envoyer dans la bande la TPDU de données expédiées sur la connexion TCP de données normales.

Prière de noter que le protocole spécifié dans le présent document ne définit pas quand devrait être établie une connexion TCP de données expédiées. Ce choix relève de la mise en œuvre.

Lorsque on utilise le service "données expédiées non bloquantes", il est recommandé de ne pas retarder l'établissement de la connexion TCP de données expédiées.

6.10	TPKT
Le présent document spécifie la valeur du champ réservé TPKT.

Les mises en œuvre ne devraient pas interpréter et agir sur une valeur d'un champ réservé. Pour éviter des problèmes d'interopérabilité avec la RFC1006, ce champ devrait être ignoré en entrée.

7.	Raisons – interopérabilité avec la RFC1006

On a choisi de conserver la même version du protocole TPKT dans ITOT que dans la RFC1006 (version 3). La raison de cette décision est que les changements introduits par le présent document n'entrent pas en conflit avec la RFC1006. Si on avait changé la version du protocole, cela aurait empêché les mises en œuvre existantes de la RFC1006 qui rendent obligatoire la version 3 d'interopérer avec le protocole défini dans ce document.

Une conséquence de cette décision se rapporte à la négociation de classe. Le protocole décrit dans le présent document introduit la classe 2 sur TCP, et il introduit donc la nécessité d'être capable d'effectuer la négociation de classes entre la classe 2 et la classe 0. Bien que toutes les mises en œuvre de transport doivent être capables de traiter la négociation de classe, on reconnaît que certaines mises en œuvre de la RFC1006 ne le peuvent pas. Donc les mises en œuvre devraient savoir que la demande Connect de classe 2 (sans classe de remplacement) pourrait être acceptée avec un Connect Confirm de classe 0, auquel cas le Connect Confirm devrait être rejeté, comme spécifié dans ISO 8073.

8.	Considérations pour la sécurité

Les questions de sécurité ne sont pas abordées spécifiquement dans le présent document. Le fonctionnement de ce protocole n'est ni plus ni moins sûr que le fonctionnement des protocoles TCP et ISO 8073. Le lecteur est invité à se reporter à eux pour en savoir plus.

Remerciements

Les auteurs remercient de leurs suggestions et commentaires Harald T. Alvestrand, Jim Bound, John Day, Mike Dyer, Peter Furniss, Dan Harrington, Steve Kille, Keith G. Knightson, Keith Sklower, Matt Thomas, Robert Watson et beaucoup d'autres membres de la liste de diffusion TOSI de l'IETF. Le soutien de Allison Mankin de l'IESG a été essentiel à la réalisation de ce travail.

Références

[ISO8072]	ISO. Norme internationale 8072. "Systèmes de traitement de l'information – Interconnexion des systèmes ouverts : définition du service de transport".

[ISO8073]	ISO.Norme internationale  8073. "Systèmes de traitement de l'information – Interconnexion des systèmes ouverts : Spécification du protocole de transport". 1992 et Amendement 5:1995.

[ISO8348]	ISO. Norme internationale 8348. "Systèmes de traitement de l'information – Interconnexion des systèmes ouverts : Définition du service réseau".

[RFC0791]	J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet", STD 5, septembre 1981.

[RFC0793]	J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", (STD 7), septembre 1981.

[RFC0896]	J. Nagle, "Contrôle de l'encombrement dans l'inter réseau IP/TCP", janvier 1984.

[RFC1006]	M. Rose et D. Cass, "Services de transport ISO par dessus TCP, version 3", STD 35, mai 1987. (Remplace RFC983, MàJ par RFC2126) 

[RFC1277]	S. Hardcastle-Kille, "Codage des adresses réseau pour prendre en charge le fonctionnement sur des couches inférieures non OSI", novembre 1991. (PS)

[RFC1278]	S. Hardcastle-Kille, "Codage de chaîne d'adresse de présentation", novembre 1991. (Information) . Un codage de chaîne d'adresse de présentation pour mettre à jour la RFC1278 est en cours de préparation.

[RFC1859]	Y. Pouffary, "Extension à la RFC 1006 pour la non utilisation de contrôle de flux explicite pour la classe 2 de transport ISO sur TCP", octobre 1995. (Information)

[RFC1883]	S. Deering, R. Hinden, "Spécification du protocole Internet, version 6 (IPv6)", décembre 1995. (Obsolète, voir RFC2460) (P.S.)

[RFC1884]	R. Hinden, S. Deering, éditeurs, "Architecture d'adressage d'IP version 6", décembre 1995. (Obsolète, voir RFC2373) (Historique)

[RFC1888]	J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd, "NSAP OSI et IPv6", août 1996. (Obsolète, voir RFC4048) (MàJ par RFC4548) (Historique)

Adresse des auteurs

Yanick Pouffary	Alan Young	
End Systems Networking	ISODE Consortium	
Digital Equipment Corporation	The Dome	
Centre Technique (Europe)	The Square	
B.P. 027	Richmond, UK	
950 Routes des colles	téléphone : +44 181 332 9091	
06901 Sophia antipolis, France	fax :   +44 181 332 9019	
téléphone : +33 92-95-62-85	mél : A.Young@isode.com 	
fax :   +33 92-95-62-35		
mél : pouffary@taec.enet.dec.com