Groupe de travail Réseau	M. Perez, ISI	
Request for Comments : 1755	F. Liaw, FORE Systems, Inc.	
Catégorie : Sur la voie de la normalisation	A. Mankin, ISI	
Traduction Claude Brière de L'Isle	E. Hoffman, ISI	
	D. Grossman, Motorola Codex	
	A. Malis, Ascom Timeplex, Inc.	
	février 1995	
Prise en charge de la signalisation ATM pour IP sur ATM

Statut de ce mémoire
Le présent document spécifie un protocole en cours de normalisation de l’Internet 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 mémoire décrit les échanges de signalisation de contrôle d'appel ATM nécessaires pour la prise en charge des mises en œuvre classiques de IP sur ATM décrites dans la [RFC1577]. Les points d'extrémité ATM vont incorporer les services de signalisation ATM spécifiés dans la version 3.1 de la spécification d'interface usager-réseau (UNI, User-Network Interface) [ATMF94] de l'ATM Forum. Les mises en œuvre de IP sur ATM utilisent les services des entités locales de signalisation ATM pour établir et libérer les connexions ATM. Le présent mémoire devrait être utilisé pour définir la prise en charge requise par les mises en œuvre de IP sur ATM à partir de leurs entités locales de signalisation ATM.

Le présent document est un guide de mise en œuvre destiné à nourrir l'interopérabilité entre les RFC 1577, RFC 1483, et la signalisation UNI ATM. Il s'applique aux hôtes et routeurs IP qui sont aussi des systèmes d'extrémité ATM et suppose des réseaux ATM qui mettent complètement en œuvre la spécification UNI version 3.1 de l'ATM Forum. Sauf mention explicite, aucune distinction n'est faite entre UNI privé et public.

UNI 3.1 est considéré comme un erratum à la spécification UNI 3.0. Il a été produit par le ATM Forum, largement pour s'aligner sur la Recommandation Q.2931. Bien que UNI 3.1 soit fondé sur UNI 3.0, il y a plusieurs changements qui rendent les deux versions incompatibles. Une description de la prise en charge de IP sur ATM en utilisant UNI 3.0 est donnée à l'Appendice B.
Table des matières
1. Conventions	2
2. Vue d'ensemble	2
3. Utilisation des procédures de protocole	3
3.1 Établissement de VC	3
3.2 Prise en charge multi protocoles sur les VC	3
3.3 Prise en charge de plusieurs VC	3
3.4 Suppression de VC	4
4. Bref tableau des procédures et messages de signalisation d'établissement d'appel UNI	4
5. Contenu du message d'établissement d'appel	4
6. Éléments d'information qui ont une signification de EP à EP	5
6.1 Paramètres de couche d'adaptation ATM	5
6.2 Information de couche inférieure de large bande	6
7. Éléments d'information significatifs pour le réseau ATM	7
7.1 Descripteur de trafic ATM	7
7.2 Capacité de prise en charge large bande	8
7.3 Paramètre de qualité de service	9
7.4 Informations d'adressage ATM	9
8. Traitement de l'échec d'établissement d'appel	10
9. Considérations de sécurité	11
10. Questions ouvertes	11
11. Remerciements	11
Références	11
Adresse des auteurs	12
Appendice A. Échantillons de messages de signalisation	12
A.1 Messages SETUP et CONNECT 	12
A.2 Conseils pour l'utilisation du message CALL PROCEEDING	14
Appendice B. IP sur ATM avec signalisation UNI 3.0	14
B.1 Paramètres AAL	14
B.2 Éléments d'information relatifs à la gestion du trafic	14
B.3 Informations d'adressage ATM	14
B.4 Échec de l'établissement d'appel	14
Appendice C. Combinaisons de paramètres de trafic acceptées dans le message SETUP	15
Appendice D. Inter fonctionnement de relais de trame	15
D.1 RFC 1490 sur FR-SSCS contre RFC 1483 sur SSCS nulle	15
D.2 Scénarios d'inter fonctionnement	16
D.3 Solutions de remplacement possibles	17
D.4 Négociation d'encapsulation	17

 	1.	Conventions

Les conventions de langage suivantes sont utilisées dans les éléments de spécification de ce document :
o	DOIT, DEVRA, ou OBLIGATOIRE – l'élément est une exigence absolue de la spécification.
o	DEVRAIT ou RECOMMANDÉ – cet élément DEVRAIT généralement être suivi sauf circonstances exceptionnelles.
o	PEUT ou FACULTATIF – l'élément est vraiment facultatif et PEUT être suivi ou ignoré selon les besoins de mise en œuvre.

 	2.	Vue d'ensemble

Dans un environnement de connexion virtuelle commutée (SVC, Switched Virtual Connection) les connexions de canal virtuel (VCC, Virtual Channel Connection) ATM sont établies dynamiquement et libérées comme nécessaire. Ceci est accompli en utilisant le protocole ATM de signalisation de contrôle d'appel/connexion, qui opère entre les systèmes d'extrémité ATM et le réseau ATM. Les entités de signalisation utilisent le protocole de signalisation pour établir et libérer les appels (association entre les points d'extrémité ATM) et les connexions (VCC). Les procédures de signalisation incluent l'utilisation de l' adressage pour localiser les points d'extrémité ATM et l'allocation de ressources dans le réseau pour la connexion. Elles fournissent aussi des indications et une négociation entre les points d'extrémité ATM pour le choix des protocoles de bout en bout et leurs paramètres. Le présent mémoire décrit comment le protocole de signalisation est utilisé pour la prise en charge de IP sur ATM, et en particulier, les informations échangées dans le protocole de signalisation pour  effectuer cette prise en charge.

Les questions de résolution d'adresse IP en adresse ATM et d'acheminement sortent du domaine d'application du présent mémoire, et sont traitées au titre de IP dans la Figure 1.

              +--------------+     +------+     +----------+
              |              |     |      |<--->| IP / ARP |
              | Signalisation|<--->| Ce   |     | RFC 1577 |
              |    ATM       |     | mémo.|     +----------+
              |              |     |      |<--->| RFC 1483 |
              |              |     +------+     +----------+
              |              | ---------------> |  AAL 5   |
              |              |                  +----------+
              |              | ---------------> |   ATM    |
              +--------------+                  +----------+

Figure 1. Relations de ce mémo avec IP, la RFC 1483, la signalisation ATM, ATM et AAL5

 	3.	Utilisation des procédures de protocole

Le motif des exigences suivantes est de fournir des lignes directrices de mise en œuvre sur la façon dont plusieurs connexions ATM entre des systèmes homologues DEVRAIENT être gérées, pour prévenir les défaillances de connexion et les problèmes qui s'y rapportent.

 	3.1	Établissement de VC
Le possesseur d'un VCC existant est défini comme étant l'entité au sein du système d'extrémité ATM qui établit la connexion. Un système d'extrémité ATM PEUT établir un appel ATM quand il a un datagramme à envoyer et que soit il n'y a pas de VCC existant qu'il puisse utiliser à cette fin, soit qu'il choisit de ne pas utiliser un VCC existant (par exemple, pour des raisons d'optimisation de chemin ou de qualité de service) soit que le possesseur du VCC ne permet pas le partage.

Pour réduire la latence de la procédure de résolution d'adresse à la station appelée, la procédure suivante PEUT être utilisée :

Si un VCC est établi en utilisant l'encapsulation de protocole de contrôle logique de liaison de données (LLC data link logical control protocol)/point de rattachement de sous-réseau (SNAP, Subnetwork Attachment Point) la station d'extrémité appelante du VCC PEUT envoyer une InARP_REQUEST (demande ARP inverse) à la station d'extrémité appelée après que la connexion est établie (c'est-à-dire qu'un message CONNECT est reçu) et avant que la station d'extrémité appelante envoie le premier paquet de données. De plus, la station d'extrémité appelante PEUT envoyer ses paquets de données sans attendre la InARP_REPLY (réponse ARP inverse). Une station d'extrémité PEUT répondre, générer, et gérer son tableau ATMARP en accord avec les procédures spécifiées dans la [RFC1293], Section 7, "Fonctionnement du protocole", pendant la durée de vie du VCC.

Pour éviter d'établir plusieurs VCC avec la même station d'extrémité, une station d'extrémité appelée PEUT associer le numéro de la partie appelante dans le message SETUP au VCC établi. Ce VCC PEUT être utilisé pour transmettre les paquets de données destinés à une station d'extrémité dont la résolution ATMARP résulte en une adresse ATM qui est la même que le numéro associé de la partie appelante. Le partage de VCC est soumis aux politiques configurées à la station d'extrémité comme décrit au paragraphe 4.3 du présent document.

 	3.2	Prise en charge multi protocoles sur les VC
Quand deux systèmes d'extrémité ATM fonctionnent avec plusieurs protocoles, une connexion ATM PEUT être partagée entre deux entités de protocole de datagramme ou plus, pour autant que le possesseur du VCC permette le partage et que l'encapsulation permette un multiplexage et démultiplexage approprié (c'est-à-dire l'encapsulation LLC/SNAP). Cette indication de partage d'un VCC PEUT être par configuration ou via une API. De même, la couche Internet prend en charge le multiplexage de plusieurs sessions de transport de bout en bout. Pour détecter correctement les connexions inactives lors du partage d'un VCC entre plus d'une entité de protocole de couche supérieure, le système d'extrémité ATM DOIT surveiller le trafic à la couche de multiplexage la plus basse.

 	3.3	Prise en charge de plusieurs VC
Un serveur ou client ATMARP PEUT établir un appel ATM quand il a un datagramme à envoyer et que soit il n'y a pas de VCC existant qu'il puisse utiliser à cette fin, soit qu'il choisit de ne pas utiliser un VCC existant, soit que le possesseur du VCC ne permet pas le partage. Noter qu'il pourrait y avoir des VCC pour la destination qui sont utilisés pour IP, mais un serveur ARP pourrait préférer utiliser un VCC séparé pour ARP seulement. Le serveur ou client ATMARP PEUT maintenir ou libérer l'appel comme spécifié dans la RFC 1577. Cependant, si le VCC est partagé entre plusieurs entités de protocole, le client ou serveur ATMARP NE DEVRA PAS déconnecter l'appel comme suggéré dans la RFC 1577.

Les systèmes DOIVENT être capables de prendre en charge plusieurs connexions entre des système homologues (sans égard au système homologue qui a initié chaque connexion). Ils PEUVENT être configurés à ne permettre qu'une seule de ces connexions à la fois.

Si un receveur accepte plus d'un appel d'une seule source, ce receveur DOIT alors accepter les PDU entrantes sur la ou les connexions supplémentaires, et PEUT transmettre sur les connexions supplémentaires. Les receveurs NE DEVRAIENT PAS accepter l'appel entrant, seulement pour clore la connexion ou ignorer les PDU provenant de la connexion.

Parce que ouvrir plusieurs connexions est spécifiquement permis, les algorithmes pour empêcher la collision d'appel de connexion, comme celui du paragraphe 8.4.3.5 de [ISO8473], NE DOIVENT PAS être mis en œuvre.

Bien que permettre plusieurs connexions soit spécifiquement désiré et permis, les mises en œuvre PEUVENT choisir (par configuration) de permettre une seule connexion pour certaines destinations. Seulement dans ce cas, si un appel entrant est reçu en collision alors qu'une demande d'appel est en instance, l'appel entrant DOIT être rejeté. Noter que ceci PEUT résulter en un échec d'établissement d'une connexion. Dans ce cas, chaque système DOIT attendre au moins un temps configurable de réessai après collision dans la gamme de 1 à 10 secondes avant de réessayer. Les systèmes DOIVENT ajouter un incrément aléatoire, avec retard exponentiel.

 	3.4	Suppression de VC
L'un ou l'autre système d'extrémité PEUT clore une connexion. Si la connexion est close ou réinitialisée alors qu'un datagramme est en cours de transmission, le datagramme est perdu. Les systèmes DEVRAIENT être capables de configurer un temps de garde minimum pour que les connexions restent ouvertes tant que les points d'extrémité sont ouverts. (Noter que le temps de garde et le temps pendant lequel la connexion a été ouverte diffèrent du temps d'inactivité.) Une valeur par défaut suggérée pour le temps de garde minimum est de 60 secondes.

Parce que certains réseaux publics PEUVENT facturer le temps de garde de connexion, et que les connexions PEUVENT être une ressource rare dans certains réseaux ou systèmes d'extrémité, chaque système qui met en œuvre une interface ATM UNI publique DOIT prendre en charge l'utilisation d'un temporisateur configurable d'inactivité pour libérer les connexions qui sont inactives pendant un certain temps. La gamme du temporisateur DEVRAIT inclure une gamme allant d'un petit nombre de minutes à "infini". Une valeur par défaut de 20 minutes est RECOMMANDÉE. Les systèmes qui mettent seulement en œuvre une interface ATM UNI privée DEVRAIT prendre en charge le temporisateur d'inactivité. Si il est mis en œuvre, le temporisateur d'inactivité DOIT surveiller le trafic dans les deux directions de la connexion.

 	4.	Bref tableau des procédures et messages de signalisation d'établissement d'appel UNI

Cette Section donne un sommaire des procédures de signalisation en point à point. Le lecteur se reportera à [ATMF93].

Les messages de signalisation UNI utilisés pour le contrôle d'appel/connexion point à point sont les suivants :

Établissement d'appel	Libération d'appel
SETUP 	RELEASE
CALL PROCEEDING	RELEASE COMPLETE
CONNECT
CONNECT ACKNOWLEDGE

Un point d'extrémité ATM initie une demande d'appel en envoyant un message SETUP au réseau. Le réseau traite la demande d'appel pour déterminer si l'appel peut être accepté. Si oui, le réseau indique la valeur du nouveau VPCI/VCI alloué dans sa première réponse au message SETUP, qui est un message soit CALL PROCEEDING, soit CONNECT. Si un appel ne peut pas être accepté, par le réseau ou le point d'extrémité ATM de destination, un message RELEASE COMPLETE est envoyé. Au point d'extrémité ATM de destination, le réseau offre l'appel en utilisant le message SETUP. Si le point d'extrémité de destination est capable d'accepter l'appel, il répond par un message CONNECT (qui PEUT être précédé par un CALL PROCEEDING) ; autrement, il envoie un message RELEASE COMPLETE. Voir à l'Appendice A2 des conseils sur l'utilisation du message CALL PROCEEDING.

La libération d'appel peut être initiée par l'un ou l'autre point d'extrémité ou (rarement) par le réseau. Quand un point d'extrémité souhaite libérer un appel, il envoie un message RELEASE au réseau. Le réseau répond avec un message RELEASE COMPLETE, libère les ressources associées à l'appel, et initie la libération à l'égard de l'autre point d'extrémité. Le réseau initie la libération en envoyant un message RELEASE au point d'extrémité ATM, qui répond en envoyant un message RELEASE COMPLETE. À réception du message RELEASE COMPLETE, le réseau libère toutes les ressources associées à l'appel.

 	5.	Contenu du message d'établissement d'appel

Les messages de signalisation sont structurés pour contenir des éléments d'information (IE, Information Element) obligatoires et facultatifs de longueur variable. Les IE sont de plus subdivisés en groupes d'octets, qui à leur tour sont divisés en champs. Les IE contiennent des informations relatives à l'appel, qui sont pertinentes pour le réseau, le point d'extrémité homologue ou les deux. Le choix des IE facultatifs et le contenu des IE obligatoires et facultatifs dans un message d'établissement d'appel détermine les parties à la communication et la nature de la communication sur la connexion ATM. Par exemple, le message d'établissement d'appel pour un appel qui va être utilisé pour une vidéo à débit binaire constant sur AAL 1 va avoir un contenu différent d'un appel qui va être utilisé pour IP sur AAL 5.

Un message SETUP qui établit une connexion ATM à utiliser pour des appels IP et une interconnexion multi protocoles DOIT contenir les IE suivants :
Paramètres AAL
Descripteur de trafic ATM
Capacité de support haut débit
Informations de couche basse haut débit
Paramètre de qualité de service
Numéro de la partie appelée
Numéro de la partie appelante 
et PEUT, dans certaines circonstance contenir les IE suivantes :
Sous adresse de la partie appelante
Sous adresse de la partie appelée
Choix du réseau de transit

Dans UNI 3.1, les éléments d'information Paramètres AAL et Information de couche basse haut débit sont facultatifs dans un message SETUP. Cependant, dans la prise en charge de IP sur ATM ces deux IE DOIVENT être inclus. L'Appendice A donne un exemple de message SETUP codé de la manière indiqué dans le présent mémoire.

 	6.	Éléments d'information qui ont une signification de EP à EP

Cette Section décrit le codage, et les procédures associées des éléments d'information dans un message SETUP n'ayant de signification que pour les points d'extrémité (EP, EndPoint) d'un appel ATM prenant en charge IP.

 	6.1	Paramètres de couche d'adaptation ATM
L'IE Paramètres AAL (voir le paragraphe 5.4.5.5 et l'Annexe F de [ATMF93]) porte des informations sur la couche d'adaptation ATM (AAL) à utiliser sur la connexion. La RFC1483 spécifie l'encapsulation de IP sur AAL 5. Donc, AAL 5 DOIT être indiqué dans le champ "Type AAL".

Le codage et la procédure relative aux champs Taille maximum de CPCS-SDU en transmission et Taille maximum de CPCS-SDU de retour sont discutés dans la [RFC1626]. Les valeurs peuvent aller de zéro à 65  535. Bien que la valeur par défaut de IP sur AAL 5/ATM soit de 9188 octets, les stations d'extrémité sont invitées à prendre en charge des tailles de MTU allant jusqu'à 64 k inclus.

Ordinairement, aucune sous couche de convergence spécifique de service (SSCS, Service Specific Convergence Sublayer) ne va être utilisée pour l'inter connexion multi protocoles sur AAL5. Donc, le champ Type SSCS DEVRAIT être absent ou, si il est présent, codé en SSCS nulle.

Format et valeurs de champs de l'IE Paramètres AAL

aal_parameters	Valeur	Format
aal_type	       5	(AAL 5)
fwd_max_sdu_size_identifier	    140
fwd_max_sdu_size	65 535	(MTU IP désirée)
bkw_max_sdu_size_identifier	     129
bkw_max_sdu_size	65 535	(MTU IP désirée)
sscs_type_identifier	     132
sscs_type	          0	(SSCS nulle)

 	6.2	Information de couche inférieure de large bande
Le choix d'une encapsulation pour prendre en charge IP sur un VCC ATM est fait en utilisant l'IE Informations de couche basse haut débit (B-LLI, Broadband Low Layer Information) ainsi que l'IE Paramètres AAL, et la procédure de négociation de B-LLI.

La RFC 1577 spécifie LLC/SNAP comme encapsulation par défaut. Cette encapsulation DOIT être mise en œuvre par toutes les stations d'extrémité. L'encapsulation LLC DOIT être signalée dans le B-LLI comme montré ci-dessous. L'indication de la signalisation d'autres encapsulations est discutée dans l'Appendice D4. Noter que seul LLC est indiqué dans le B-LLI. Il appartient à la couche LLC de regarder dans l'en-tête d'encapsulation des paquets suivant l'établissement d'appel. Un B-LLI spécifiant à la fois LLC et une ccouche SNAP layer_3_id n'est pas recommandé. Si dans ces paquets, l'en-tête SNAP indique IP, il appartient à la couche LLC de porter les paquets jusqu'à IP.

Format de l'IE B-LLI indiquant l'encapsulation LLC/SNAP

bb_low_layer_information	Valeur	Format
layer_2_id	 2	
user_information_layer	12	(lan_llc - ISO 8802/2) |

 	6.2.1	Cadre de mise en couches de protocoles
La prise en charge de services sans connexion par une connexion en mode couche de liaison expose aux problèmes généraux de gestion de connexion, spécifiquement aux problèmes d'acceptation de connexion, d'allocation de qualité de service, et de fermeture de connexion. Pour qu'une connexion soit associée au protocole correct sur l'hôte appelé, il est nécessaire que les informations sur une ou plusieurs identifications de couche de protocole soient associées à une "entité de gestion" ou "point d'extrémité" de connexion. Cette association est ce qu'on appelle un lien dans le présent mémoire. Dans ce paragraphe, on tente de décrire un cadre pour une architecture utilisable de lien ou service étant donnés les IE disponibles dans les messages de contrôle d'appel ATM.

Il est important de distinguer entre deux utilisations de base des éléments d'identification de protocole présents dans le message d'établissement UNI. La première est la description de l'encapsulation de protocole qui va être utilisée sur le paquet de données sur la connexion virtuelle ; la seconde est l'entité qui va être responsable de gérer l'appel. Tous les protocoles présents dans les divers IE DOIVENT être utilisés pour encapsuler l'appel, mais la couche la plus spécifique, ou la plus haute spécifiée DEVRAIT gérer l'appel. Cela définit une hiérarchie de services et fournit un cadre pour les applications, incluant LLC et IP, pour terminer les appels. Cette hiérarchie donne un mécanisme clair pour la prise en charge de liens de protocole et application de niveau supérieur, quand leur utilisation et spécification sera définie par les organismes de normalisation appropriés.

En général, il serait souhaitable de permettre que les paquets de données soient mémorisés directement dans un espace d'adresses de l'application après que la connexion est établie. Ceci n'est possible que si on a les indications de l'entité d'encapsulation et de gestion dans le message de signalisation.

Le B-LLI est le seul élément d'information actuellement disponible dans UNI 3.1 pour désigner les points d'extrémité de protocole. Il contient les codets qui décrivent les entités de protocole de couche 2 et 3 associées à l'appel. D'autres éléments d'information sont examinés à l'ATM Forum et à l'UIT-T, qui pourraient jouer un rôle significatif dans la description du lien entre application et connexion, mais leur utilisation n'est pas encore définie, et ils ne font pas partie du cadre décrit par la RFC 1577. Ils incluent B-HLI, pour contenir les informations pour qu'un protocole de couche supérieure, Informations de couche réseau (NLI, Network Layer Information) contienne des information pour la couche réseau, et UUI, qui est destiné à porter des informations à l'usage de l'application de niveau supérieur.

La figure suivante montre un B-LLI qui PEUT être utilisé pour spécifier dans l'établissement d'appel que IP va gérer l'appel et que ce VC va être utilisé seulement pour du trafic IP. Les appelants DOIVENT accepter ce B-LLI. L'appelant qui utilise un VC DOIT utiliser l'encapsulation LLC-SNAP sur tous les datagrammes IP, en dépit du fait que l'appelant voit le VC comme dédié à IP. La raison de cette exigence est que alors qu'on exige des receveurs qu'ils acceptent cette forme d'établissement d'appel, ils peuvent choisir de multiplexer ou non l'appel à travers LLC ; en d'autres termes, d'ignorer les informations de couche 3. Ce choix dépend de l'architecture de protocole de la mise en œuvre de receveur et est locale pour le receveur.

Format de l'IE B-LLI indiquant la possession du VC par IP
(Note : l'encapsulation LLC/SNAP est toujours utilisée)

bb_low_layer_information
layer_2_id	  2
user_information_layer	 12	(lan_llc - ISO 8802/2) |
layer_3_id	   3
ISO/IEC TR 9577 IPI	204 (0xCC)

Des VC à encapsulation nulle sont décrits dans la RFC 1483. Un tel VC résulterait en la forme la plus directe de lien d'un VC à IP. Cependant, la méthode de signalisation de ce type de VC n'a pas encore été intégrée dans le contexte IP sur ATM. Pour être complet, on mentionne que la signalisation utiliserait un B-LLI contenant un identifiant de couche 3 avec le codet de protocole ISO/CEI TR-9577 et en omettant l'identifiant de couche 2 [ATMF93]. Comme aucune couche 2 n'est spécifiée, les trames produites par le traitement AAL seraient données directement à IP. Le traitement de ce B-LLI n'est pas exigé pour l'instant.

 	7.	Éléments d'information significatifs pour le réseau ATM

Cette Section décrit le codage, et les procédures qui l'entourent, des éléments d'information significatifs pour le réseau ATM, ainsi que les points d'extrémité d'un appel ATM qui prend en charge le fonctionnement multi protocoles.

Les normes, accords de mise en œuvre, recherches et expériences qui concernent des questions comme la gestion du trafic, la qualité de service et la description du service support sont encore en évolution. Beaucoup de ces matériaux sont destinés à donner la plus grande latitude possible aux mises en œuvre de réseau et offres de service ATM. Les systèmes d'extrémité ATM ont besoin de correspondre au contrat de trafic et au service support qu'ils demandent au réseau pour les capacités offertes par le réseau. Donc, le présent mémoire peut seulement offrir ce qui, pour l'instant, sont les règles de codage les plus appropriées et efficaces pour suivre l'établissement de VCC IP et ATMARP. De futures révisions du présent mémoire pourront tirer parti de services et capacités ATM qui ne sont pas encore disponibles.

 	7.1	Descripteur de trafic ATM
Le descripteur de trafic ATM caractérise la connexion virtuelle ATM en termes de débit de cellules maximum (PCR, peak cell rate), débit de cellules soutenable (SCR, sustainable cell rate), et taille de salve maximum. Ces informations sont utilisées pour allouer les ressources (par exemple, la bande passante, la mémoire tampon) dans le réseau. En général, le descripteur de trafic ATM pour prendre en charge l'interconnexion multi protocoles sur ATM va être soumis à des facteurs tels que la capacité du réseau, la définition de conformité acceptée par le réseau, les performances du système d'extrémité ATM et (pour les réseaux publics) le coût des services.

Le modèle le plus convenable de comportement IP correspond à la capacité au mieux (Best Effort Capability) (voir le paragraphe 3.6.2.4 de [ATMF93]). Si cette capacité est offerte par le ou les réseaux ATM, elle PEUT être demandée en incluant les champs Indicateur au mieux, Débit de cellule maximum en transmission(CLP=0+1) et Débit de cellule maximum de retour (CLP=0+1) dans l'IE Descripteur de trafic ATM. Quand la capacité au mieux est utilisée, aucune garantie n'est fournie par le réseau, et en fait, le débit peut être zéro à tout moment. Ce type de comportement est aussi décrit par la [RFC1633].

Format et valeurs du champ IE Descripteur de trafic ATM

traffic_descriptor
fwd_peak_cell_rate_0+1_identifier	132
fwd_peak_cell_rate_0+1	(débit de liaison)
bkw_peak_cell_rate_0+1_identifier	133
bkw_peak_cell_rate_0+1	(débit de liaison)
best_effort_indication	190

Quand le réseau ne prend pas en charge la capacité au mieux ou si un service ATM plus prévisible est désiré pour IP, des paramètres de trafic plus spécifiques PEUVENT être spécifiés et la capacité au mieux n'être pas utilisée. Le faire inclut d'utiliser les deux autres IE relatifs au trafic et est discuté dans les paragraphes suivants.

L'IE Descripteur de trafic est accompagné par l'IE Capacité de support large bande et l'IE Paramètre de qualité de service. Ensemble, ils définissent la signalisation vue par la gestion de trafic ATM. Dans le présent mémoire, on présente un sous ensemble accepté exigé des capacités de gestion du trafic, comme spécifié en utilisant les trois IE. La figure immédiatement ci-dessous montre l'ensemble de combinaisons admises de paramètres de trafic ATM que tous le systèmes d'extrémité IP sur ATM DOIVENT prendre en charge dans leur signalisation ATM. Le sous ensemble inclut au mieux sous la forme d'une combinaison de débits binaires non garantis (la colonne de droite du tableau ci-dessous) ; une description de type de trafic qui est destinée aux "tuyaux" ATM, par exemple entre deux routeurs (la colonne du milieu) ; et une description de type de trafic qui va permettre l'utilisation initiale de caractérisations de type baquet de jetons de la source, comme présenté dans la [RFC1363] et la [RFC1633], par exemple (la colonne de gauche).

Combinaisons des paramètres relatifs au trafic qui DOIVENT être pris en charge dans le message SETUP

Capacité de support large bande
Support large bande	C	X	X
Type de trafic (CBR,VBR)		CBR	&
Temporisation exigée		OUI	&&
Paramètre Descripteur de trafic
PCR (CLP=0)			
PCR (CLP=0+1)	S	S	S
SCR (CLP=0)			
SCR (CLP=0+1)	S		
MBS (CLP=0)			
MBS (CLP=0+1)	S		
Au mieux			S
Étiquetage	NON	NON	NON
Classes de QS	0	0	0

S = Spécifié
& = le paramètre est codé comme "pas d'indication" ou VBR ou l'octet 5a (Type de trafic/Temporisation exigée) est absent ; ces trois codages sont traités comme équivalents.
&& = le paramètre est codé comme "pas d'indication" ou "Non" ou l'octet 5a est absent ; ces trois codages sont traités comme équivalents.

L'utilisation d'autres combinaisons permissibles des paramètres de trafic mentionnées dans le grand tableau de l'Appendice  C peut fonctionner, car elles sont permises par [ATMF94], mais cela va dépendre du système d'extrémité appelant, du réseau, et du système d'extrémité appelé.

Si le service au mieux n'est pas utilisé, le débit de liaison NE DEVRAIT PAS être demandé comme débit de cellules maximum. Sans aucune connaissance de l'application, il est RECOMMANDÉ qu'une fraction, comme 1/10, de la bande passante de liaison soit demandée.

[ATMF93] ne fournit aucune capacité de négociation des paramètres de descripteur de trafic ATM. Cela signifie que :

a)	le système d'extrémité appelant DEVRAIT avoir une connaissance a priori du contrat de trafic qui va être acceptable pour le système d'extrémité appelé et le réseau.

b)	si, en réponse à un message SETUP, un système d'extrémité appelant reçoit un message RELEASE COMPLETE, ou un message CALL PROCEEDING suivi par un message RELEASE COMPLETE, avec la cause n° 37, Débit de cellules d'utilisateur indisponible, il PEUT examiner le champ diagnostic de l'IE Cause et tenter à nouveau l'appel après avoir choisi de plus petites valeurs pour le ou les paramètres indiqués. Si le message RELEASE COMPLETE ou RELEASE est reçu avec la cause n° 73, Combinaison de paramètres de trafic non acceptée, il PEUT essayer d'autres combinaisons des tableaux 5-7 et 5-8 de [ATMF93].

c)	le système d'extrémité appelé DEVRAIT examiner l'IE Descripteur de trafic ATM dans le message SETUP. Si il n'est pas capable de traiter les cellules au PCR de transmission indiqué, il DEVRAIT supprimer l'appel avec la cause n° 37, Débit de cellules d'utilisateur indisponible.

 	7.2	Capacité de prise en charge large bande
Le type X de service en mode connexion de support large bande (BCOB-X, Broadband Bearer Connection Oriented Service Type X) ou le type C (BCOB-C) sont tous ceux applicables à l'interconnexion multi protocoles, selon le ou les services fournis par le réseau ATM et les capacités (par exemple, pour le formatage du trafic) du système d'extrémité ATM. Le tableau du paragraphe précédent montrait l'utilisation de BCOB-X et BCOB-C avec d'autres paramètres. La figure ci-dessous montre le format et les valeurs des champs pour BCOB-X quand l'IE Descripteur de trafic indique "au mieux".

Format et valeurs de champs de l'IE Capacité de support large bande

bb_bearer_capability
spare	0
bearer_class	16	(BCOC-X)
spare	0
traffic_type	0	(pas d'indication)
timing_reqs	0	(pas d'indication)
susceptibility_to_clipping	0	(pas susceptible)
spare	0
user_plane_configuration	0	(point à point)

La signalisation IP sur ATM DOIT permettre BCOB-C et BCOB-X, dans les combinaisons montrées au paragraphe précédent. Elle PEUT aussi permettre une des combinaisons permissibles montrées à l'Appendice C.

Actuellement, il n'y a pas de capacité de négociation de la prise en charge de la capacité large bande. Cela signifie que :
a)	le système d'extrémité appelant DEVRAIT avoir une connaissance a priori de la prise en charge de la capacité large bande qui va être acceptable au système d'extrémité appelé et au réseau.
b)	 si, en réponse à un message SETUP, un système d'extrémité appelant reçoit un message RELEASE COMPLETE, ou un message CALL PROCEEDING suivi par un message RELEASE COMPLETE, avec la cause n° 57, Capacité prise en charge non autorisée ou n° 58 Capacité prise en charge non actuellement disponible, il PEUT tenter l'appel à nouveau après avoir choisi une autre prise en charge de capacité.

 	7.3	Paramètre de qualité de service
La classe de qualité de service Inspécifiée (classe 0) est la seule classe de qualité de service qui doit être prise en charge par tous les réseaux et la seule classe de qualité de service permise quand on utilise le service au mieux. La classe QS spécifiée pour le transfert de données en mode connexion (classe 3) ou la classe QS spécifiée pour le transfert de données en mode sans connexion (classe 4) peut être applicable au multi protocoles sur ATM, mais leur utilisation doit être négociée avec le fournisseur du réseau. Les combinaisons de paramètres de qualité de service avec le descripteur de trafic ATM et la capacité de support large bande sont détaillées au paragraphe 7.1 (descripteur de trafic) et dans l'Appendice C.

Format et valeurs de champs de l'IE Paramètres de QS

qos_parameter
qos_class_fwd	0	(classe 0)
qos_class_bkw	0	(classe 0)

[ATMF93] ne fournit aucune capacité de négociation des paramètre de qualité de service. Cela signifie que :
a)	le système d'extrémité appelant DEVRAIT avoir une connaissance a priori des classes de qualité de service offertes par le réseau ATM en conjonction avec le service de support large bande et le descripteur de trafic offerts ;
b)	si, en réponse à un message SETUP, un système d'extrémité appelant reçoit un message RELEASE COMPLETE, ou un message CALL PROCEEDING suivi par un message RELEASE COMPLETE, avec la cause n° 49, Qualité de service indisponible, il PEUT tenter l'appel à nouveau après avoir choisi une autre classe de qualité de service.

Note : le champ de deux bits 'codage standard' de l'octet Informations générales dans l'en-tête de l'IE DEVRAIT être réglé à '00' maintenant que l'UIT-T a normalisé la classe de qualité de service 0. Les systèmes d'extrémité DEVRAIENT traiter les valeurs ('11' ou '00') comme demandant la classe de qualité de service UIT-T.

 	7.4	Informations d'adressage ATM
Les informations d'adressage ATM sont portées dans l'IE Numéro d'appelé, Numéro d'appelant, et, dans certaines circonstances, Sous adresse d'appelé , et Sous adresse d'appelant. Le paragraphe 5.8 de [ATMF93] donne la procédure pour qu'un système d'extrémité ATM apprenne sa propre adresse ATM du réseau ATM, pour l'utiliser à remplir l'IE Numéro d'appelant. Le paragraphe 5.4.5.14 de [ATMF94] décrit la syntaxe et la sémantique de l'IE Sous adresse d'appelant.

La RFC 1577 RECOMMANDE qu'un routeur soit capable de fournir plusieurs prises en charge de LIS avec une seule interface physique ATM qui peut avoir une ou plusieurs adresses de système d'extrémité ATM individuel. L'utilisation du champ Sélecteur dans les adresses NSAPA et E.164 (dans le format NSAP) est identifiée de façon à différencier jusqu'à 256 LIS différents pour le même ESI. Donc, un routeur IP PEUT associer les adresses IP des divers LIS qu'il prend en charge avec des adresses ATM distinctes différenciées seulement par le champ SEL. Si un routeur IP fait cette association, son entité de signalisation DOIT alors porter dans le message SETUP les adresses ATM correspondant à l'entité IP particulière qui demande l'appel, et l'entité IP à laquelle il demande l'appel. Ces adresses ATM sont portées respectivement dans les IE Numéro d'appelant et Numéro d'appelé. Les adresses E.164 natives ne prennent pas en charge de champ SEL. Pour les routeurs IP qui résident dans un UNI public où des adresses E.164 natives sont utilisées, il est RECOMMANDÉ que plusieurs adresses E.164 soient utilisées pour prendre en charge plusieurs LIS. Note : la prise en charge de plusieurs LIS est la seule utilisation recommandée du champ SEL. L'utilisation de ce champ n'est pas recommandée pour le choix d'applications de niveau supérieur.

La résolution des adresses IP en adresses ATM est exigée des hôtes et routeurs qui sont des systèmes d'extrémité ATM utilisant des SVC ATM. La RFC 1577 donne un mécanisme pour faire la résolution d'adresse IP en ATM dans le modèle IP classique.

Format et valeurs de champs des IE Numéro d'appelant et Numéro d'appelé

called_party_number
type_of_number	(numéro international/inconnu)
addr_plan_ident	(adresse de système d'extrémité RNIS/ATM)
addr_number	(adresse de système d'extrémité E.164/ATM)

calling_party_number
type_of_number		(numéro international/inconnu)
addr_plan_ident		(adresse de système d'extrémité RNIS/ATM)
presentation_indic		(présentation permise)
spare	0
screening_indic		(fournie, vérifiee & passée par l'utilisateur)
addr_number		(adresse de système d'extrémité E.164/ATM)

 	8.	Traitement de l'échec d'établissement d'appel

Si une tentative d'appel ATM échoue avec une des causes suivantes, la situation DEVRAIT être traitée comme Réseau injoignable (si le système d'extrémité ATM appelé est un routeur) ou Hôte injoignable (si le système d'extrémité ATM appelé est un hôte). Voir le traitement des conditions Réseau et Hôte injoignable dans la [RFC1122].

N° 1  numéro non alloué 
N° 3  pas de chemin pour la destination
N° 17  utilisateur occupé
N° 18  pas de réponse
N° 27  destination en dérangement
N° 38  réseau en dérangement
N° 41  défaillance temporaire
N° 47  ressource indisponible, non spécifié

Si une tentative d'appel ATM échoue avec une des causes suivantes, le système d'extrémité ATM PEUT réessayer l'appel, en changeant (ou ajoutant) la ou les IE indiquées par le code de cause et le diagnostic.

N° 2  pas de chemin pour le réseau de transit spécifié
N° 21  appel rejeté
N° 22  le numéro a changé
N° 23  l'utilisateur rejette l'appel avec CLIR
N° 37  débit de cellules d'utilisateur indisponible
N° 49  qualité de service indisponible
N° 57  prise en charge de capacité non autorisée
N° 58  prise en charge de capacité non disponible actuellement
N° 65  prise en charge de capacité non mise en œuvre
N° 73  combinaison de paramètre de trafic non acceptée
N° 88  destination incompatible
N° 91  choix de réseau d'émission invalide
N° 78  les paramètres AAL ne peuvent pas être pris en charge

 	9.	Considérations de sécurité

Toutes les questions de sécurité relatives à IP sur ATM ne sont pas clairement comprises pour l'instant, dues à l'état fluide des spécifications ATM, à la nouveauté de la technologie, et d'autres facteurs. De futures révisions de cette spécification traiteront les capacités de sécurité que les futures normes de signalisation peuvent offrir à la signalisation de IP sur ATM.

 	10.	Questions ouvertes

Cette version du document est spécifiquement un document de mise en œuvre des RFC1577/RFC1483. Bien que les RFC1577 et RFC1483 spécifient une encapsulation LLC/SNAP, qui est par essence une encapsulation multi protocoles, il sort du domaine d'application du présent document d'entrer dans les spécifications de multi protocoles autrement qu'en mentionnant quelques exemples (voir à l'Appendice D un exemple d' encapsulation NLPID).

 	11.	Remerciements

Les auteurs souhaitent remercier de leur travail leur collègues qui ont participé au groupe de travail IP sur ATM, au comité technique ATM Forum, au sous groupe de signalisation ATM accrédité par l'ANSI T1S1, aux experts du groupe d'études 11 Signalisation d'accès ATM de l'UIT-T (anciennement CCITT). Rao Cherukuri (IBM) et Jeff Kiel (anciennement de Bellcore, actuellement BellSouth) ont apporté une aide particulièrement précieuse en coordonnant T1S1, UIT-T et l'ATM Forum pour s'assurer que les besoins de multi protocoles sur ATM seraient exprimés dans le protocole de signalisation ATM.

 	Références

[ATMF93] ATM Forum, "ATM User-Network Interface Specification Version 3.0", (Englewood Cliffs, NJ: Prentice Hall, 1993).

[ATMF94] ATM Forum, "ATM User-Network Interface Specification Version 3.1", 1994.

[ISO8473]	ISO/CEI 8473, "Systèmes de traitement de l'information – Communications de données - Protocole pour fournir le service réseau en mode sans connexion", 1988.

[ISO9577]	ISO/CEI TR9577, "Technologie de l'information - Télécommunications et échanges d'informations entre systèmes - Identification de protocole dans la couche réseau", International Standards Organization, Genève, 1990.

[Q.2931]	Recommandation UIT-T Q.2931, "Réseau numérique large bande à intégration de service (B-RNIS) – Système n°  2 de signalisation d'abonné numérique (DSS2) - Spécification de l'interface usager-réseau de couche 3 pour le contrôle d'appel/connexion de base". (Union Internationale des Télécommunications, Genève, 1994)

[RFC1122]	R. Braden, "Exigences pour les hôtes Internet – couches de communication", STD 3, octobre 1989. (MàJ par RFC6633, 8029)

[RFC1293]	T. Bradley et C. Brown, "Protocole de résolution inverse d'adresse", janvier 1992. (Remplacée par RFC2390)

[RFC1363]	C. Partridge, "Proposition de spécification de flux", septembre 1992. (Info.)

[RFC1483]	Juha Heinanen, "Encapsulation multi protocoles sur couche 5 d'adaptation ATM", juillet 1993. (Remplacée par 2684)

[RFC1577]	M. Laubach, "IP classique et ARP sur ATM", janvier 1994. (Remplacée par la RFC2225)

[RFC1626]	R. Atkinson, "MTU IP par défaut à utiliser sur AAL5 en ATM", mai 1994. (P.S., remplacée par 2225)

[RFC1633]	R. Braden, D. Clark et S. Shenker, "Intégration de services dans l'architecture l'Internet : généralités", juin 1994. (Info.)

 	Adresse des auteurs

Maryann Perez Maher	Fong-Ching Liaw	Allison Mankin	
USC/Information Sciences Institute	FORE Systems, Inc.	USC/Information Sciences Institute	
4350 N. Fairfax Drive Suite 400	174 Thorn Hill Road	4350 N. Fairfax Drive Suite 400	
Arlington, VA 22203	Warrendale, PA 15086-7535	Arlington, VA 22203	
USA	USA	USA	
téléphone : 703-807-0132	téléphone : (412) 772-8668	téléphone :  703-807-0132	
mél : perez@isi.edu 	mél : fong@fore.com 	mél : mankin@isi.edu 	

Eric Hoffman	Dan Grossman	Andrew G. Malis	
USC/Information Sciences Institute	Motorola Codex	Ascom Timeplex, Inc.	
4350 N. Fairfax Drive Suite 400	téléphone : 617-821-7333	289 Great Road   Suite 205	
Arlington, VA 22203	mél : dan@merlin.dev.cdx.mot.com 	Acton, MA  01720	
USA		USA	
téléphone : 703-807-0132		téléphone : (508) 266-4522	
mél : hoffman@isi.edu 		mél : malis@maelstrom.timeplex.com 	

 	Appendice A.	Échantillons de messages de signalisation
 	A.1	Messages SETUP et CONNECT 
Cet appendice donne des échantillons de codages des messages de signalisation SETUP et CONNECT. Les champs de l'en-tête d'IE ne sont pas montrés.

SETUP

Champs d'éléments d'information	Valeur/signification
aal_parameters
      aal_type	    5        (AAL 5)
      fwd_max_sdu_size_ident	140
      fwd_max_sdu_size	(valeur de MTU IP en envoi)
      bkw_max_sdu_size_ident	129
      bkw_max_sdu_size	(valeur de MTU IP en réception)
      sscs_type identifier 	132
      sscs_type 	     0      (SSCS nulle)

user_cell_rate
      fwd_peak_cell_rate_0_1_ident	132
      fwd_peak_cell_rate_0_1	         (débit de liaison)
      bkw_peak_cell_rate_0_1_ident	133
      bkw_peak_cell_rate_0_1	         (débit de liaison)
      best_effort_indication	190

bb_bearer_capability
      spare	0
      bearer_class	16       (BCOC-X)
      spare	0
      traffic_type	0        (pas d'indication)
      timing_reqs	0        (pas d'indication)
      susceptibility_to_clipping	0        (non susceptible de coupure)
      spare	0
      user_plane_configuration	0	(point à point)

bb_low_layer_information
      layer_2_id	2
      user_information_layer	12       (lan_llc (ISO 8802/2)

qos_parameter
      qos_class_fwd	0        (classe 0)
      qos_class_bkw	0        (classe 0)

called_party_number
      type_of_number	(numéro international/inconnu)
      addr_plan_ident	(adresse de système d'extrémité RNIS/ATM)
      number	(adresse de système d'extrémité E.164/ATM)

calling_party_number
      type_of_number	(numéro international/inconnu)
      addr_plan_ident	(adresse de système d'extrémité RNIS/ATM)
      presentation_indic	(présentation permise)
      spare	0
      screening_indic	(fournie, vérifiée et passée par l'utilisateur)
      number	(adresse de système d'extrémité E.164/ATM)

Figure 1. Échantillons de contenus de message SETUP

* : facultatif, ignoré si présent

Dans les environnements IP sur ATM, l'inclusion de l'IE "Paramètres AAL" IE est *obligatoire* pour permettre la négociation de taille de MTU entre la source et la destination. L'IE "Informations de couche inférieure large bande" est aussi obligatoire pour spécifier le schéma d'encapsulation IP.

CONNECT

Champs d'éléments d'information	Valeur/signification
aal_parameters
      aal_type	    5        (AAL 5)
      fwd_max_sdu_size_ident	140
      fwd_max_sdu_size	(send IP MTU value)
      bkw_max_sdu_size_ident	129
      bkw_max_sdu_size	(recv IP MTU value)
      sscs_type identifier	132
      sscs_type	     0        (null SSCS)

bb_low_layer_information
      layer_2_id	  2
      user_information_layer	12       (lan_llc (ISO 8802/2)

connection_identifier
      spare	0
      vp_assoc_signaling	1        (explicit indication of VPCI)
      preferred_exclusive	0        (exclusive vpci/vci)
      vpci	(assigned by réseau)
      vci	(assigned by réseau)

Figure 2. Échantillons de contenus de message CONNECT

Comme dans le message SETUP, les environnements IP sur ATM demandent l'inclusion de l'IE "Paramètres AAL" afin que la destination puisse spécifier la taille de MTU qu'elle veut recevoir.

 	A.2	Conseils pour l'utilisation du message CALL PROCEEDING
L'utilisation du message CALL PROCEEDING est bénéfique dans les mises en œuvre où l'entité de signalisation ATM et les utilisateurs ATM de l'appelé sont découplés. L'arrivée d'un SETUP peut résulter en une réponse CALL PROCEEDING  immédiate de la part de l'entité de signalisation ATM de l'appelé, alors qu'elle interroge en local l'entité IP-ATM appelée pour voir si les conditions du SETUP sont acceptables. L'acceptation des conditions du SETUP causeraient alors la production par l'entité de signalisation ATM d'un CONNECT en retour au commutateur. Les deux modes possible de refus chez l'appelé deviennent alors :
a)	l'appelé n'a pas d'entité IP-ATM résidente. Production d'un RELEASE COMPLETE en réponse au SETUP ;
b)	l'appelé a une entité IP-ATM résidente, un CALL PROCEEDING a été produit. L'entité IP-ATM rejette la demande d'appel, donc un RELEASE est produit à la place (pour être acquitté par le réseau avec RELEASE COMPLETE).

 	Appendice B.	IP sur ATM avec signalisation UNI 3.0

Cet appendice décrit comment prendre en charge IP sur ATM en utilisant la signalisation UNI 3.0. Il donne les différences de codage ou de sémantique de chaque IE pertinent.

 	B.1	Paramètres AAL
Les valeurs de taille maximum de SDU peuvent aller de un (pas zéro) à 64 k.

Un champ Mode est un champ admissible dans UNI 3.0. Néanmoins, ce champ Mode DEVRAIT être omis de l'IE Paramètres AAL et DOIT être ignoré par le système d'extrémité de destination.

 	B.2	Éléments d'information relatifs à la gestion du trafic
Dans UNI 3.0 les questions de gestion du trafic étaient moins bien comprises que dans UNI 3.1. UNI 3.0 ne contient pas de guide pour coordonner l'utilisation de l'IE Débit de cellules d'utilisateur (IE Descripteur de trafic dans UNI 3.1), de l'IE Capacité de support large bande, et de l'IE Paramètres de qualité de service. Donc, la recommandation de spécifier les paramètres dans ces IE est la même que celle donnée ci-dessus quand on utilise UNI 3.1. Le paragraphe suivant décrit simplement les différences de noms et valeurs de codes.

 	B.2.1	Débit de cellules d'utilisateur ATM (au lieu de Descripteur de trafic ATM)
L'IE Descripteur de trafic ATM est appelé IE "Débit de cellules d'utilisateur ATM" dans UNI 3.0. Aussi, la valeur de la cause "débit de cellule d'utilisateur indisponible" est n° 51.

 	B.2.3	Paramètres de qualité de service
Le champ de deux bits "codage standard" de l'octet Informations générales dans l'en-tête de IE devrait être réglé à "11" pour indiquer que l'IE est un standard défini pour le réseau (par opposition à une norme de l'UIT-T) présent sur le côté réseau de l'interface.

 	B.3	Informations d'adressage ATM
Dans UNI 3.1, le type "Adresse de système d'extrémité ATM" a été introduit pour différencier les adresses ATM de NSAP OSI. Dans UNI 3.0, "Adresse de système d'extrémité ATM" n'est pas un type valide. Donc, dans les IE Sous adresse d'appelé et Sous adresse d'appelant, le champ de trois bits "Type de sous adresse" DOIT spécifier "NSAP" (valeur = 001) quand on utilise l'IE Sous adresse pour porter les adresses ATM.

 	B.4	Échec de l'établissement d'appel
Dans UNI 3.0 certaines valeurs de cause sont différentes de UNI 3.1. Les deux différences sont les suivantes :
"les paramètres AAL ne peuvent pas être pris en charge" est n° 93 (n ° 78 dans UNI 3.1)
"débit de cellules d'utilisateur indisponible" est n ° 51 (n° 37 dans UNI 3.1).

 	Appendice C.	Combinaisons de paramètres de trafic acceptées dans le message SETUP

Capacité de support haut débit
Support haut débit	A,C	X	X	C	X	C	X	A,C	X	X	C	X
Type de trafic (CBR,VBR)	-	CBR	&	-	&	-	&	-	CBR	&	&	&
Temporisation exigée	-	O	&&	-	&&	-	&&	-	O	&&	-	&&
Paramètre Descripteur de trafic
PCR (CLP=0)	S	S	S	-	-	-	-	-	-	-	-	-
PCR (CLP=0+1)	S	S	S	S	S	S	S	S	S	S	S	S
SCR (CLP=0)	-	-	-	-	S	S	-	-	-	-	-	-
SCR (CLP=0+1)	-	-	-	-	-	-	S	S	-	-	-	-
MBS (CLP=0)	-	-	-	-	S	S	-	-	-	-	-	-
MBS (CLP=0+1)	-	-	-	-	-	-	S	S	-	-	-	-
Au mieux	-	-	-	-	-	-	-	-	-	-	S	S
Étiquetage	O/N	O/N	O/N	O/N	O/N	N	N	N	N	N	N	N
Classes de QS	*	*	*	*	*	*	*	*	*	*	0	0

Reproduction du Tableau F-1 de l'Appendice F de [ATMF 94]

PCR (Peak Cell Rate) = débit de cellules maximal, SCR (Sustainable Cell Rate) = débit de cellules soutenu,
MBS (Maximum Burst Size) = taille de salve maximum, CBR (Constant Bit Rate) = débit binaire constant
O = Oui, N = Non, S = Spécifiée
O/N = "Oui" ou "Non" est permis
* = les valeurs de classe de QS sont une option du réseau. La classe 0 est toujours acceptée pour l'alignement sur l'UIT-T.
& = le paramètre est codé comme "pas d'indication" ou VBR ou l'octet 5a (Type de trafic/Temporisation exigée) est absent ; ces trois codages sont traités comme équivalents.
&& = le paramètre est codé comme "pas d'indication" ou "Non" ou l'octet 5a (Type de trafic/Temporisation exigée) est absent ; ces trois codages sont traités comme équivalents.
Un tiret indique que le paramètre est absent.

 	Appendice D.	Inter fonctionnement de relais de trame
 	D.1	RFC 1490 sur FR-SSCS contre RFC 1483 sur SSCS nulle
Les procédures pour l'inter fonctionnement de la signalisation de relais de trame à ATM n'ont pas encore été spécifiées par l'UIT-T, l'ATM Forum, ou le Forum Relais de trame. Si un système d'extrémité ATM souhaite utiliser FR-SSCS, l'encapsulation FR-SSCS et de la RFC1490 doivent toutes deux être spécifiées dans le message SETUP. Néanmoins, comme ni l'encapsulation LLC ni le multiplexage de VC ne vont interopérer quand utilisés sur FR-SSCS, ces deux encapsulations ne peuvent pas être négociées comme des solutions de remplacement de l'encapsulation de la RFC 1490 (voir la Section 4, Négociation d'encapsulation).

Dans les environnements ATM la couche SSCS fait partie de la fonctionnalité AAL. La SSCS sert à coordonner les besoins d'un protocole supérieur avec les exigences de la prochaine couche inférieure, la sous couche de convergence de partie commune (CPCS, Common Part Convergence Sublayer). Par exemple, le protocole de signalisation d'UNI ATM fonctionne par dessus une SSCS de signalisation qui entre autres choses fournit un service de transfert assuré pour les messages de signalisation. Comme la SSCS est considérée comme une partie de AAL, le type SSCS est spécifié comme un des paramètres dans l'IE Paramètres AAL. Aujourd'hui, il n'y a pas de SSCS définie pour la transmission de données dans ATM et ce champ de type est généralement réglé à "nul".

Une exception se produit quand, dans l'inter fonctionnement avec FR, un système d'extrémité ATM peut choisir d'utiliser le FR-SSCS sur AAL 5 afin de communiquer avec un système d'extrémité FR. Dans ce cas, le type SSCS dans l'IE Paramètres AAL du message SETUP est réglé à "FR-SSCS".

Aussi incluse dans un message SETUP est une indication dans l'IE B-LLI des couches de protocole à utiliser au-dessus de AAL. En particulier, les connexions ATM établies pour porter du trafic d'interconnexion de réseau sans connexion exigent une couche au dessus de AAL pour multiplexer plusieurs protocoles sur un seul VC [RFC1483]. Comme mentionné précédemment, la RFC 1577 définit LLC comme couche de multiplexage par défaut pour IP sur AAL5.

La spécification de la SSCS restreint le protocole d'encapsulation utilisé sur elle, car la RFC 1483 (en plus des normes applicables de l' UIT-T) définit l'utilisation de l'encapsulation de la RFC 1490 sur la FR-SSCS, et l'encapsulation LLC ou nulle autrement. Le fait qu'il n'est pas possible, dans la spécification de signalisation UNI 3.0, de négocier entre FR-SSCS et SSCS nulle peut résulter en restrictions d'interopérabilité entre stations qui mettent en œuvre et souhaitent utiliser la FR-SSCS et celles qui ne le font pas, même si elles utilisent toutes deux IP. Les lignes directrices du paragraphe suivant ont été développées pour diminuer les chances de telles restrictions d'interopérabilité.

 	D.2	Scénarios d'inter fonctionnement
La discussion qui suit utilise les termes de "inter fonctionnement de réseau" et de "inter fonctionnement de service". L'inter fonctionnement de réseau utilise FR-SSCS sur AAL5 entre l'unité d'interfonctionnement (IWU, InterWorking Unit) et le système d'extrémité ATM, et le système d'extrémité ATM est informé de ce que l'autre point d'extrémité est une IWU de réseau FR/ATM. L'inter fonctionnement de service vise à rendre le fonctionnement transparent pour le système d'extrémité ATM en ajoutant la traduction d'encapsulation et les autres traitements de charge utile dans l'IWU de service FR/ATM pour permettre au système d'extrémité ATM de fonctionner comme si il parlait à un autre système d'extrémité ATM.

Le scénario le plus courant où FR-SSCS pourrait être négocié est entre un système d'extrémité ATM et un IWU de réseau FR/ATM pour permettre la connexité entre un système d'extrémité ATM et un système d'extrémité FR résidant derrière un IWU de réseau FR/ATM.

                     --------        -----------
      -------       |  IWU   |      |           |       -------
     |   A   |      | FR/ATM |      |Commutateur|      |   B   |
     |  (FR) |----->|        |----->|    ATM    |----->| (ATM) |
      -------       |        |      |           |       -------
                     --------        -----------
             |      |        |                         |
              ----->          ------------------------>
             appel FR                  appel ATM

Un IWU réseau peut passer un appel à un hôte ATM (au nom d'un hôte FR) en signalant la FR-SSCS et en supposant que le système d'extrémité ATM prend en charge FR-SSCS. L'IE B-LLI DEVRA être codé pour indiquer l'encapsulation RFC 1490, et le champ Type de SSCS de l'IE Paramètres AAL DEVRA être codé pour indiquer FR-SSCS. Si la négociation de FR-SSCS échoue parce que l'hôte ATM appelé ne prend pas en charge FR-SSCS, le IWU peut réessayer l'appel en négociant l'encapsulation LLC ou le multiplexage de VC.

Cependant, le IWU ne peut tenter de nouveaux essais que si il est capable de faire interfonctionner les services FR et ATM. Un tel interfonctionnement de service ajoute des frais généraux de traitement supplémentaires durant l'appel.

Un cas encore plus problématique se produit quand un appel est demandé dans la direction opposée, c'est-à-dire quand un hôte ATM passe un appel à un hôte qui réside derrière un IWU.

                     --------        -----------
      -------       |  IWU   |      |Commutateur|       -------
     |   B   |      | FR/ATM |      |    ATM    |      |   A   |
     |  (FR) |<-----|        |<-----|           |<-----| (ATM) |
      -------       |        |      |           |       -------
                     --------        -----------
             |      |        |                         |
              <-----          <------------------------
             FR call                 appel ATM

Ne sachant pas que la destination réside derrière un IWU, l'hôte appelant va négocier l'encapsulation LLC par défaut (demandant éventuellement le multiplexage de VC comme solution de remplacement). Dans cette situation, le IWU peut accepter l'appel et faire l'inter fonctionnement de service nécessaire ou rejeter l'appel en spécifiant "Paramètres AAL non pris en charge". Si le IWU rejette l'appel il risque que cet hôte appelant ne prenne pas en charge FR-SSCS ou simplement ne réessaye pas et l'appel ne va jamais être établi.

 	D.3	Solutions de remplacement possibles
Alors que l'inter fonctionnement avec le relais de trame est possible, il n'est pas possible de négocier FR-SSCS avec l'encapsulation LLC ou le multiplexage de VC, ce qui diminue les chances de réaliser un appel ATM. Cependant, l'inter opérabilité peut être augmentée en utilisant les solutions de remplacement suivantes :
1.	Conserver en externe la connaissance qu'une certaine destination utilise FR-SSCS. Elle peut être configurée, ou à l'avenir ajoutée à une base de données des hôtes du réseau.
2.	En l'absence d'une telle connaissance externe, un système d'extrémité ATM est obligé de négocier l'encapsulation LLC par défaut (demandant éventuellement le multiplexage de VC en remplacement). Il y a trois sous cas :
2a.	L'IWU prend en charge l'inter fonctionnement de service et l'inter fonctionnement de réseau, et préfère l'inter fonctionnement de service. L'IWU accepte simplement l'appel en utilisant l'encapsulation de LLC.
2b.	L'IWU prend en charge l'inter fonctionnement de service et l'inter fonctionnement de réseau, et préfère l'inter fonctionnement de réseau. L'IWU accepte simplement l'appel, mais tente d'ouvrir une connexion parallèle de retour au système d'extrémité ATM original. Si la connexion est acceptée, l'IWU clôt la connexion d'inter fonctionnement de service.
2c.	L'IWU prend seulement en charge l'inter fonctionnement de réseau. L'IWU rejette l'appel en spécifiant "Paramètres AAL non pris en charge", et tente ensuite d'ouvrir une connexion en retour au système d'extrémité ATM original en négociant l'utilisation de FR-SSCS.

 	D.4	Négociation d'encapsulation
Le protocole de signalisation de contrôle d'appel/connexion inclut un mécanisme de prise en charge de la négociation de l'encapsulation pour les systèmes d'extrémité qui en prennent en charge plus d'une. Ce paragraphe décrit les procédures de négociation d'une encapsulation.

Les procédures de négociation B-LLI (voir l'Annexe C de [ATMF93]) sont initiées par le système d'extrémité ATM appelant en incluant jusqu'à trois instances de l'IE B-LLI dans le message SETUP en ordre de préférence descendante (suivant les règles de répétition d'IE du paragraphe 5.4.5.1 de [ATMF93]).

Voici les trois combinaisons possibles d' d'IE B-LLI qui PEUVENT être incluses dans le message SETUP. Chaque instance est appelée par son nom d'encapsulation tel qu'il apparaît dans la RFC 1483, et le titre du paragraphe correspondant de l'Appendice D de la spécification UNI 3.0.
a)	Encapsulation LLC/SNAP (D.3.1)
Dans ce cas, le système d'extrémité ATM appelant peut seulement envoyer et recevoir des paquets précédés par un identifiant LLC/SNAP. Le présent mémoire exige que les hôtes et routeurs qui sont des systèmes d'extrémité ATM mettent en œuvre l'encapsulation LLC/SNAP.
b)	Multiplexage de VC (D.3.2) et LLC/SNAP (D.3.1)
Le système d'extrémité ATM appelant préfère utiliser le multiplexage de VC, mais accepte d'utiliser l'encapsulation LLC/SNAP à la place, si le système d'extrémité ATM appelé ne prend en charge que LLC/SNAP.
c)	Encapsulation de la RFC 1490 (multiplexage de NLPID) sur FR-SSCS (D.3.3, en omettant les octets 7a et 7b et DOIT avoir FR-SSCS dans le type de SSCS de l'IE Paramètres AAL.)
Le système d'extrémité ATM appelant peut seulement envoyer et recevoir des paquets en utilisant l'encapsulation de la RFC1490 (multiplexage de NLPID) sur FR-SSCS. L'utilisation de l'encapsulation de la RFC 1490 ne peut pas être actuellement négociée comme solution de remplacement de l'encapsulation de LLC ou de multiplexage de VC. Si l'IE B-LLI est codé à indiquer l'encapsulation de la RFC1490, le champ Type de SSCS de l'IE Paramètres AAL DEVRA être codé à indiquer FRSSCS. Noter que l'IE Paramètres AAL ne peut être pas codé à indiquer à la fois NUL et FR-SSCS et ni l'encapsulation de LLC, ni le multiplexage de VC ne vont interopérer quand utilisés sur FR-SSCS.

Le système d'extrémité ATM appelé DEVRA choisir la méthode d'encapsulation qu'il est capable de prendre en charge à partir de l'IE B-LLI présent dans le message SETUP. Si il prend en charge plus d'une des encapsulations indiquées dans le message SETUP, il DOIT choisir celle qui paraît en premier dans le message SETUP. Le système d'extrémité ATM appelé inclut alors le contenu de l'IE B-LLI correspondant à l'encapsulation choisie dans le message CONNECT. Si le système d'extrémité appelé ne prend en charge aucune des encapsulations indiquées dans le message SETUP entrant, il DEVRA libérer l'appel avec la cause n° 88, "destination incompatible". Si le message SETUP reçu n'inclut pas l'IE B-LLI, l'appel DEVRA être libéré avec la cause n° 21, "appel rejeté", et un diagnostic indiquant la raison du rejet : élément d'information manquant et l'identifiant d'IE B-LLI. Comme décrit à l'Annexe C de [ATMF93], si le point d'extrémité ATM appelant reçoit un message CONNECT qui ne contient pas d'IE B-LLI, il DEVRA supposer l'encapsulation indiquée dans le premier IE BLLI qui est inclus dans le message SETUP.