Groupe de travail Réseau	K. Morneault, Cisco Systems	
Request for Comments : 4233	S. Rengasami, Tridea Works	
RFC rendue obsolète : 3057 ; mise à jour par RFC 5133	M. Kalla, Telcordia Technologies	
Catégorie : Sur la voie de la normalisation	G. Sidebottom, Signatus Technologies	
Traduction Claude Brière de L'Isle	janvier 2006	

Réseau numérique à intégration de services (RNIS) 
Couche d'adaptation d'utilisateur Q.921

Statut de ce 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.

Notice de copyright
Copyright (C) The Internet Society (2006).

Résumé
Le présent document définit un protocole pour remorquer les messages d'utilisateur Q.921 de réseau numérique à intégration de service (RNIS) sur IP en utilisant le protocole de transmission de commandes de flux (SCTP, Stream Control Transmission Protocol). Ce protocole va être utilisé entre une passerelle de signalisation (SG, Signaling Gateway) et un contrôleur de passerelle de supports (MGC, Media Gateway Controller). On suppose que la SG reçoit la signalisation RNIS sur une interface RNIS standard.

Le présent document rend obsolète la RFC 3057.
Table des matières
1. Introduction	2
1.1 Domaine d'application	2
1.2 Terminologie	2
1.3 Vue d'ensemble de l'IUA	3
1.4 Services fournis par la couche IUA	4
1.5 Fonctions mises en œuvre par la couche IUA	6
1.6 Définition des limites de IUA	7
2. Conventions	9
3. Éléments de protocole	9
3.1 En-tête de message commun	9
3.2 En-tête de message IUA	12
3.3 Messages IUA	13
4. Procédures	27
4.1 Procédures pour la prise en charge du service du paragraphe 1.4.1	27
4.2 Procédures pour la prise en charge du service du paragraphe 1.4.2	27
4.3 Procédures de prise en charge de service du paragraphe 1.4.3	28
5. Exemples	34
5.1 Établissement d'association et de trafic entre les SG et les ASP	34
5.2 Exemples de reprise sur défaillance du trafic d'ASP	36
5.3 Exemples de primitives de remorquage Q.921/Q.931	37
5.4 Exemples de communication de gestion de couche	38
6. Considérations sur la sécurité	38
7. Considérations relatives à l'IANA	38
7.1 Identifiant de protocole de charge utile SCTP	38
7.2 Extensions de protocole IUA 	38
8. Valeurs de temporisateurs	39
9. Remerciements	39
10. Références	39
10.1 Références normatives	39
10.2 Références pour information	39
11. Changements effectués	40
Appendice A	40
A.1 Architecture de réseau de signalisation	40
A.2 Redondance de processus de serveur d'application	41
Adresse des auteurs	41
Déclaration complète de droits de reproduction	41

 	1.	Introduction

Dans le présent document, le terme "utilisateur Q.921" se réfère à une couche supérieure qui utilise les services de Q.921, et non le côté utilisateur de l'interface RNIS [Q.920]. Des exemples de la couche supérieure seraient Q.931 et QSIG.

Cette section décrit le besoin du protocole de couche d'adaptation d'utilisateur RNIS Q,921 (IUA, ISDN Q.921-User Adaptation) ainsi que comment ce protocole devra être mis en œuvre.

 	1.1	Domaine d'application
Il y a besoin d'une livraison de protocole de signalisation de réseau à commutation de circuits (SCN, Switched Circuit Network) d'une passerelle de signalisation RNIS (SG, Signaling Gateway) à un contrôleur de passerelle de supports (MGC, Media Gateway Controller) comme décrit dans le cadre d'architecture pour le transport de signalisation [RFC2719]. Le mécanisme de livraison DEVRAIT satisfaire les critères suivants :
* prendre en charge le transport des primitives de limite Q.921/Q.931,
* prendre en charge la communication entre modules de gestion de couche SG et MGC,
* prendre en charge la gestion d'associations actives SCTP entre SG et MGC.

Le présent document prend en charge aussi bien l'accès RNIS au débit principal (PRA, Primary Rate Access) que l'accès de base (BRA, Basic Rate Access) incluant la prise en charge des deux modes de communication en point à point et en point à multipoint. Cette prise en charge inclut la signalisation service par service (FAS, Facility Associated Signaling) la signalisation autre que service par service (NFAS, Non-Facility Associated Signaling) et NFAS avec canal D de secours. Les exigences de couche d'adaptation QSIG ne diffèrent pas de celles de la couche d'adaptation Q.931 ; donc, les procédures décrites dans le présent document sont aussi applicables pour une couche d'adaptation QSIG. Pour simplifier, seul Q.931 sera mentionné dans le reste du présent document.

 	1.2	Terminologie
serveur d'application (AS, Application Server) - entité logique desservant une instance d'application spécifique. Un exemple de serveur d'application est un MGC qui traite le Q.931 et le traitement d'appel pour les canaux D terminés par les passerelles de signalisation. En pratique, un AS est modélisé à la SG comme une liste ordonnée d'un ou plusieurs processus de serveur d'application en rapport (par exemple, primaire, secondaire, tertiaire).

processus de serveur d'application (ASP, Application Server Process) - instance de processus d'un serveur d'application. Des exemples de processus de serveur d'application sont les instances de MGC primaire ou de secours.

association - une association se réfère à une association SCTP. L'association va fournir le transport pour la livraison des unités de données de protocole d'utilisateur Q.921 et des messages d'homologue de couche d'adaptation IUA.

remorque (backhaul) - une SG termine les couches inférieures d'un protocole de SCN et remorque la ou les couches supérieures au MGC pour le traitement d'appel. Pour les besoins du présent document, la SG termine Q.921 et remorque Q.931 au MGC.

reprise sur défaillance - capacité de réacheminer le trafic de signalisation comme nécessaire entre les ASP concernés en cas de défaillance ou d'indisponibilité de l'ASP actuellement utilisé (par exemple, du MGC primaire au MGC de secours). La reprise sur défaillance s'applique aussi au retour en service d'un processus précédemment indisponible.

Hôte - plate-forme de calcul sur laquelle fonctionne l'ASP.

Interface - pour les besoins du présent document, une interface prend en charge le canal de signalisation RNIS pertinent. Ce canal de signalisation PEUT être un canal D à 16 kbit/s pour un BRA RNIS ou un canal primaire ou de secours à 64  kbit/s pour un PRA RNIS. Pour QSIG, le canal de signalisation est un canal Qc.

Identifiant d'interface - l'identifiant d'interface identifie l'interface physique à la SG pour laquelle les messages de signalisation sont envoyés/reçus. Le format du paramètre Identifiant d'interface peut être du texte ou un entier, dont les valeurs sont allouées conformément à la politique de l'opérateur du réseau. Les valeurs utilisées n'ont de signification que locale, coordonnée entre la SG et l'ASP. La signification n'est pas impliquée à travers les SG desservies par un AS.

gestion de couches - c'est une fonction nodale qui traite les entrées et les sorties entre la couche IUA et une entité de gestion locale.

Ordre des octets du réseau - octet de poids fort en premier, autrement dit, gros boutien.

flux - un flux se réfère à un flux SCTP : un canal unidirectionnel logique établi d'un point d'extrémité SCTP à un autre point d'extrémité SCTP associé, au sein duquel tous les messages d'utilisateur sont livrés en séquence excepté ceux soumis à un service de livraison non ordonné.

Utilisateur Q.921 - tout protocole utilisant normalement les services du RNIS Q.921 (par exemple, Q.931, QSIG, etc.).

 	1.3	Vue d'ensemble de l'IUA
L'architecture qui a été définie dans la [RFC2719] pour le transport de la signalisation de SCN sur IP utilise plusieurs composants, incluant un protocole de transport IP, un protocole de signalisation commun, et un module d'adaptation pour la prise en charge des services attendus d'un protocole de signalisation de SCN particulier à partir de sa couche de protocole sous-jacente.

Le présent document définit un module d'adaptation qui convient pour le transport des messages d'utilisateur RNIS Q.921 (par exemple, Q.931).

 	1.3.1	Exemple : de SG à MGC
Dans une passerelle de signalisation (SG), on s'attend à ce que la signalisation RNIS soit reçue sur une terminaison de réseau RNIS standard. La SG fournit alors l'interfonctionnement des fonctions de transport avec le transport de signalisation IP, afin de transporter les messages de signalisation Q.931 au MGC où existe la couche de protocole Q.931 homologue, comme le montre la figure ci-dessous.

******   RNIS        ******      IP      *******
* EP *---------------* SG *--------------* MGC *
******               ******              *******
+-----+                                  +-----+
|Q.931|              (NIF)               |Q.931|
+-----+           +----------+           +-----+
|     |           |     | IUA|           | IUA |
|     |           |     +----+           +-----+
|Q.921|           |Q.921|SCTP|           |SCTP |
|     |           |     +----+           +-----+
|     |           |     | IP |           | IP  |
+-----+           +-----+----+           +-----+

NIF - Fonction d'interfonctionnement nodal
EP - Point d'extrémité RNIS
SCTP - Protocole de transmission de commandes de flux (voir [RFC2960], [RFC3309])
IUA - (ISDN User Adaptation Layer Protocol) protocole de couche d'adaptation d'utilisateur RNIS

Figure 1. IUA dans l'application de SG à MGC

Il est recommandé que l'IUA utilise les services du protocole de transmission de commandes de flux (SCTP) comme protocole sous-jacent fiable de transport commun de signalisation. L'utilisation de SCTP fournit les caractéristiques suivantes :
-	livraison explicite en mode paquet (pas en mode flux)
-	livraison en séquence des messages d'utilisateur au sein de flux multiples, avec l'option de livraison dans l'ordre d'arrivée des messages d'utilisateur individuels,
-	multiplexage facultatif des messages d'utilisateur dans les datagrammes SCTP,
-	tolérance de fautes au niveau réseau par la prise en charge du multi rattachement à l'une ou l'autre, ou aux deux extrémités d'une association,
-	résistance aux attaques d'inondation et d'usurpation d'identité,
-	segmentation des données pour se conformer à la taille de la MTU de chemin découverte.

Il y a des scénarios sans exigence de redondance et des scénarios dans lesquels la redondance est acceptée en dessous de la couche transport. Dans ce cas, les fonctions SCTP ci-dessus PEUVENT être déterminées comme non exigées et TCP PEUT être utilisé comme protocole sous-jacent de transport commun.

 	1.3.2	Prise en charge de la gestion des associations SCTP entre la SG et les ASP
La couche IUA à la SG maintient l'état de disponibilité de tous les ASP distants enregistrés de façon dynamique, afin de gérer les associations SCTP et le trafic entre la SG et les ASP. De même, les états actifs/inactifs des ASP distants sont maintenus. Les ASP actifs sont ceux qui reçoivent actuellement du trafic de la SG.

La couche IUA PEUT recevoir de la gestion locale l'instruction d'établir une association SCTP avec un nœud IUA homologue. Cela peut être fait en utilisant la primitive M-SCTP ESTABLISH pour demander, indiquer, et confirmer l'établissement d'une association SCTP avec un nœud IUA homologue.

La couche IUA PEUT aussi avoir besoin d'informer la gestion locale de l'état des associations SCTP sous-jacentes en utilisant la primitive de demande et d'indication M-SCTP STATUS. Par exemple, l'IUA PEUT informer la gestion locale de la raison de la libération d'une association SCTP, déterminée soit en local au sein de la couche IUA, soit par une primitive provenant de SCTP.

 	1.3.3	Modèle et terminologie de reprise sur défaillance d'ASP
La couche IUA prend en charge les fonctions de reprise sur défaillance d'ASP afin d'assurer une forte disponibilité de la capacité de traitement d'appel. Tous les messages d'utilisateur Q.921 qui entrent à une SG sont alloués à un unique serveur d'application, sur la base de l'identifiant d'interface du message.

Le serveur d'application est, en pratique, une liste de tous les ASP configurés pour traiter les messages d'utilisateur Q.921 provenant de certains identifiants d'interface. Un ou plusieurs ASP de la liste sont normalement actifs (c'est-à-dire, ils traitent du trafic) tandis que d'autres PEUVENT être indisponibles ou inactifs, pour être éventuellement utilisés en cas de défaillance ou d'indisponibilité du ou des ASP actifs.

La couche IUA prend en charge un modèle de redondance n+k (actif-en attente, partage de charge, diffusion) où n est le nombre minimum d'ASP redondants requis pour traiter le trafic et k ASP sont disponibles pour prendre le relais d'un ASP défaillant ou indisponible. Noter que une redondance 1+1 actif/en attente est un sous ensemble de ce modèle. Un modèle simplex 1+0 est aussi pris en charge comme sous ensemble, sans redondance d'ASP.

 	1.3.4	Modèle client/serveur
Il est recommandé que la SG et l'ASP soient capables de prendre en charge le fonctionnement du client comme du serveur. Les points d'extrémité homologues qui utilisent l'IUA DEVRAIENT être configurés de façon à ce que l'un prenne toujours le rôle de client et l'autre prenne toujours le rôle de serveur pour initier les associations SCTP. L'orientation par défaut serait que la SG prenne le rôle de serveur tandis que l'ASP serait le client. Dans ce cas, les ASP DEVRAIENT initier l'association SCTP à la SG.

Le numéro d'accès d'utilisateur enregistré SCTP et TCP alloué pour IUA est 9900.

 	1.4	Services fournis par la couche IUA
 	1.4.1.	Prise en charge du transport des primitives de limite Q.921/Q.931
Dans le scénario de remorquage, les primitives de limite Q.921/Q.931 sont exposées. La couche IUA a besoin de prendre en charge toutes les primitives de cette limite pour réussir à remorquer Q.931.

Cela inclut les primitives suivantes [Q.920] :

DL-ESTABLISH : elles sont utilisées pour demander, indiquer, et confirmer le résultat des procédures pour établir une opération sur plusieurs trames.

DL-RELEASE : elles sont utilisées pour demander, indiquer, et confirmer le résultat des procédures pour terminer une opération antérieurement établie sur plusieurs trames, ou pour rapporter l’échec d'une tentative d'établissement.

DL-DATA : elles sont utilisées pour demander et indiquer des messages de couche 3 (Q.931) qui sont à transmettre, ou ont été reçus, par la couche Q.921 en utilisant le service de transfert d'informations acquittées.

DL-UNIT DATA : elles sont utilisées pour demander et indiquer des messages de couche 3 (Q.931) qui sont à transmettre, par la couche Q.921 en utilisant le service de transfert d'informations non acquittées.

 	1.4.2.	Prise en charge des communications entre modules de gestion de couches aux SG et MGC
Il est envisagé que la couche IUA ait besoin de fournir des services qui facilitent la communication entre les modules de gestion de couche sur la SG et le MGC. Ces primitives sont :

M-TEI STATUS : elles sont utilisées pour demander, confirmer, et indique l'état (alloué/non alloué) d'un identifiant de point d'extrémité terminal RNIS (TEI, Terminal Endpoint Identifier).

M-ERROR : elle est utilisée pour indiquer une erreur dans un message IUA reçu (par exemple, la valeur de l'identifiant d'interface n'est pas connue de la SG).

 	1.4.3	Prise en charge de la gestion des associations actives entre SG et MGC
Un ensemble de primitives entre la couche IUA et la gestion de couches est défini ci-dessous pour aider la gestion de couches à gérer les associations SCTP entre la SG et le MGC. La gestion de couches peut ordonner à la couche IUA d'établir une association SCTP avec un nœud IUA homologue. Cette procédure peut être réalisée en utilisant la primitive M-SCTP ESTABLISH.

M-SCTP ESTABLISH : elles sont utilisées pour demander, indiquer, et confirmer l'établissement d'une association SCTP avec un nœud IUA homologue.

M-SCTP RELEASE : elles sont utilisées pour demander, indiquer, et confirmer la libération d'une association SCTP avec un nœud IUA homologue.

La couche IUA PEUT aussi avoir besoin d'informer la gestion de couches de l'état des associations SCTP. Cela peut être  réalisé en utilisant la primitive M-SCTP STATUS.

M-SCTP STATUS : elles sont utilisées pour demander et indiquer l'état des associations SCTP sous-jacentes.

La gestion de couches PEUT avoir besoin d'informer la couche IUA d'un état d'AS/ASP (c'est-à-dire, défaillance, actif, etc.) afin que les messages puissent être échangés entre homologues de couche IUA pour arrêter le trafic chez l'utilisateur IUA local. Cela peut se faire en utilisant la primitive M-ASP STATUS.

M-ASP STATUS : l'état de l'ASP est mémorisé dans la couche IUA des deux côtés SG et MGC. La primitive M-ASP STATUS peut être utilisée par la gestion de couches pour demander l'état du processus de serveur d'application à la couche IUA. Cette primitive peut aussi être utilisée pour indiquer l'état du processus de serveur d'application.

M-ASP-UP : elle peut être utilisée par la gestion de couches pour envoyer un message ASP Up (ASP vif) au processus de serveur d'application. Elle peut aussi être utilisée pour générer un accusé de réception de "ASP Up".

M-ASP-DOWN : elle peut être utilisée par la gestion de couches pour envoyer un message ASP Down (ASP mort) au processus de serveur d'application. Elle peut aussi être utilisée pour générer un accusé de réception de ASP Down.

M-ASP-ACTIVE ; elle peut être utilisée par la gestion de couches pour envoyer un message ASP actif au processus de serveur d'application. Elle peut aussi être utilisée pour générer un accusé de réception d'ASP actif.

M-ASP-INACTIVE : Elle peut être utilisée par la gestion de couches pour envoyer un message ASP inactif pour le processus de serveur d'application. Elle peut aussi être utilisée pour générer un accusé de réception d'ASP inactif.

M-AS STATUS : elle peut être utilisée par la gestion de couches pour demander l'état du serveur d'application. Cette primitive peut aussi être utilisée pour indiquer l'état du serveur d'application.

 	1.5	Fonctions mises en œuvre par la couche IUA
 	1.5.1	Transposition
La couche IUA DOIT conserver une transposition de l'identifiant d'interface à une interface physique sur la passerelle de signalisation. Une interface physique sera une ligne T1, une ligne E1, etc., et pourrait inclure l'intervalle de temps du mutiplexage par répartition dans le temps (TDM, Time-Division Multiplexing). De plus, pour une certaine interface la SG DOIT être capable d'identifier le canal de signalisation associé. Les couches IUA de la SG et du MGC PEUVENT maintenir l'état des identifiants de point d'extrémité de terminal (TEI, Terminal Endpoint Identifier) RNIS et des identifiants de point d'accès de service (SAPI, Service Access Point Identifier).

La SG ne transpose un identifiant d'interface en une association/flux SCTP que lorsque un ASP envoie un message ASP actif pour un identifiant d'interface particulier. On DOIT noter, cependant, que cette transposition est dynamique et pourrait changer à tout moment à cause d'un changement de l'état de l'ASP. Cette transposition pourrait même être temporairement invalide, par exemple, durant une reprise sur défaillance d'un ASP à un autre. Donc, la SG DOIT conserver les états d'AS/ASP et les référencer durant l’acheminement d'un message à un AS/ASP.

La figure ci-dessous montre un exemple de la vue logique des relations entre canal D, identifiant d'interface, AS, et ASP dans la SG :

          /---------------------------------------------------+
         /   /------------------------------------------------|--+
        /   /                                                 v  |
       /   /    +----+             act+-----+    +-------+ -+--+-|+--+-
Canal D1------->|IID |-+          +-->| ASP |--->| Assoc |       v
         /      +----+ |  +----+  |   +-----+    +-------+ -+--+--+--+-
        /              +->| AS |--+                           Flux
       /        +----+ |  +----+   stb+-----+
Canal D2------->|IID |-+              | ASP |
                +----+                +-----+

où IID = identifiant d'interface

Noter qu'un ASP peut être dans plus d'un AS.

 	1.5.2	État des ASP
La couche IUA sur la SG DOIT conserver l'état des ASP qu'elle prend en charge. L'état d'un ASP change à cause de la réception de messages d'homologue à homologue (les messages ASPM sont décrits au paragraphe 3.3.2) ou de la réception d'indications provenant de l'association SCTP locale. Les procédures de transition d'état d'ASP sont décrites au paragraphe  4.3.1.

À une SG, une liste de serveurs d'application PEUT contenir les ASP actifs et inactifs pour prendre en charge les procédures de partage de charge et de reprise sur défaillance d'ASP. Quand, par exemple, un ASP principal et un ASP de secours sont tous deux disponibles, le protocole d'IUA de l'homologue doit contrôler quel ASP est actuellement actif. La liste ordonnée des ASP au sein d'un serveur d'application logique est tenue à jour à la SG pour refléter le ou les procès actifs de serveur d'application.

Aussi la couche IUA PEUT devoir informer la gestion locale du changement d'état d'un ASP ou AS. Cela peut se faire en utilisant les primitives M-ASP STATUS ou M-AS STATUS.

 	1.5.3	Gestion de flux SCTP
SCTP permet qu'un nombre de flux spécifique de l'utilisateur soient ouverts durant l'initialisation. Il est de la responsabilité de la couche IUA de s'assurer de la gestion appropriée de ces flux. À cause de la nature unidirectionnelle des flux, une couche IUA ne connaît pas la transposition du nombre de flux en identifiant d'interface de la couche IUA de son homologue. L'identifiant d'interface est plutôt dans l'en-tête de message IUA.

L'utilisation des flux SCTP au sein de IUA est recommandée afin de minimiser le délai de transmission et de mise en mémoire tampon, donc améliore les performances et la fiabilité globale des éléments de signalisation. Il est recommandé qu'un flux SCTP séparé soit utilisé pour chaque canal D.

 	1.5.4	Interfonctionnement de gestion de réseau sans à-coups
La couche IUA sur la SG DEVRAIT passer une indication d'indisponibilité de l'utilisateur IUA (Q.931) à la gestion de couches locale, si l'ASP actuellement actif quitte l'état ACTIF. La gestion de couches pourrait dire à Q.921 de prendre des mesures, si cela semble approprié.

De même, si une association SCTP a une défaillance, la couche IUA des deux côtés SG et ASP PEUT générer des primitives de libération pour mettre les liaisons de données hors service.

 	1.5.5	Gestion d'encombrement
Si la couche IUA devient encombrée (selon la mise en œuvre) elle PEUT arrêter de lire à partir de l'association SCTP vers le contrôle de flux de l'IUA homologue.

 	1.6	Définition des limites de IUA
 	1.6.1	Définition de limite IUA/Q.921
DL-ESTABLISH (établir la liaison de données)
DL-RELEASE (libérer la liaison de données)
DL-DATA
DL-UNIT DATA

 	1.6.2	Définition de limite IUA/Q.931
DL-ESTABLISH
DL-RELEASE
DL-DATA
DL-UNIT DATA

 	1.6.3	Définition de limite SCTP/IUA
Un exemple de primitives de couche supérieure fournies par SCTP est disponible à la Section 10 de la [RFC2960].

 	1.6.4	Définition de limite IUA/Gestion de couche (LM, layer management)
Demande M-SCTP ESTABLISH
Direction : LM -> IUA
Objet : la LM demande à l'ASP d’établir une association SCTP avec une SG.

Confirmation de M-STCP ESTABLISH
Direction : IUA -> LM
Objet : l'ASP confirme à la LM qu'il a établi une association SCTP avec une SG.

Indication M-SCTP ESTABLISH
Direction : IUA -> LM
Objet : la SG informe la LM qu'un ASP a établi une association SCTP.

Demande M-SCTP RELEASE
Direction : LM -> IUA
Objet : la LM demande à l'ASP de libérer une association SCTP avec la SG.

Confirmation de M-SCTP RELEASE
Direction : IUA -> LM
Objet : l'ASP confirme à la LM qu'il a libéré une association SCTP avec la SG.

Indication M-SCTP RELEASE
Direction : IUA -> LM
Objet : la SG informe la LM que l'ASP a libéré une association SCTP.

Demande M-SCTP STATUS
Direction : LM -> IUA
Objet : la LM demande à IUA de rapporter l'état d'une association SCTP.

Indication M-SCTP STATUS
Direction : IUA -> LM
Objet : l'IUA rapporte l'état de l'association SCTP.

Demande M-ASP STATUS
Direction : LM -> IUA
Objet : la LM demande à la SG de rapporter l'état de l'ASP distant.

Indication M-ASP STATUS
Direction : IUA -> LM
Objet : la SG rapporte l'état de l'ASP distant.

Demande M-AS-STATUS
Direction : LM -> IUA
Objet : la LM demande à la SG de rapporter l'état de l'AS.

Indication M-AS-STATUS
Direction : IUA -> LM
Objet : la SG rapporte l'état de l'AS.

Indication M-NOTIFY
Direction : IUA -> LM
Objet : l'ASP rapporte qu'il a reçu un message NOTIFY de son homologue.

Indication M-ERROR
Direction : IUA -> LM
Objet : l'ASP ou la SG rapporte que le message ERROR de son homologue a été reçu.

Demande M-ASP-UP
Direction : LM -> IUA
Objet : la LM demande à l'ASP de commencer le fonctionnement et envoie un message ASP VIF à la SG.

Confirmation de M-ASP-UP
Direction : IUA -> LM
Objet : l'ASP rapporte qu'il a reçu un message d'accusé de réception d'ASP VIF de la SG.

Demande M-ASP-DOWN
Direction : LM -> IUA
Objet : la LM demande à l'ASP d'arrêter son fonctionnement et envoie un message ASP MORT à la SG.

Confirmation de M-ASP-DOWN
Direction : IUA -> LM
Objet : l'ASP rapporte qu'il a reçu un message d'accusé de réception d'ASP MORT de la SG.

Demande M-ASP-ACTIVE
Direction : LM -> IUA
Objet : la LM demande à l'ASP d'envoyer un message ASP ACTIF à la SG.

Confirmation de M-ASP-ACTIVE
Direction : IUA -> LM
Objet : l'ASP rapporte qu'il a reçu un message d'accusé de réception d'ASP ACTIF de la SG.

Demande M-ASP-INACTIVE
Direction : LM -> IUA
Objet : la LM demande à l'ASP d'envoyer un message ASP INACTIF à la SG.

Confirmation de M-ASP-INACTIVE
Direction : IUA -> LM
Objet : l'ASP rapporte qu'il a reçu un message d'accusé de réception d'ASP INACTIF de la SG.

Demande M-TEI STATUS
Direction : LM -> IUA
Objet : la LM demande à l'ASP d'envoyer une demande d'état de TEI à la SG.

Indication M-TEI STATUS
Direction : IUA -> LM
Objet : l'ASP rapporte qu'il a reçu une indication d'état de TEI de la SG.

Confirmation de M-TEI STATUS
Direction : IUA -> LM
Objet : l'ASP rapporte qu'il a reçu une confirmation d'état de TEI de la SG.

 	2.	Conventions

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "NON RECOMMANDÉ", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	3.	Éléments de protocole

Cette section décrit le format des divers messages utilisés dans ce protocole.

 	3.1	En-tête de message commun
Les messages du protocole pour l'adaptation d'utilisateur Q.921 exigent un en-tête de message qui contient la version de la couche d'adaptation, le type de message, et la longueur du message.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    |   Réservé     | Classe de msg |  Type de msg  |
+---------------+---------------+---------------+---------------+
|                        Longueur de message                    |
+---------------+---------------+---------------+---------------+

Figure 2. Format d'en-tête commun

Tous les champs d'un message IUA DOIVENT être transmis dans l'ordre des octets du réseau, sauf mention contraire.

 	3.1.1	Version
Le champ Version contient le numéro de version de la couche d'adaptation IUA. Les versions acceptées sont :

Valeur	Version
1	Livraison 1.0

 	3.1.2	Classes et types de message
La liste suivante contient les classes de message valides :

Classe de message : 8 bits (entier non signé)
0 : Message de gestion (MGMT)
1 : réservé pour d'autres couches d'adaptation SIGTRAN
2 : réservé pour d'autres couches d'adaptation SIGTRAN
3 : Messages de maintenance d'état d'ASP (ASPSM)
4 : Messages de maintenance  de trafic d'ASP (ASPTM)
5 : Messages de transport de primitives de limite Q.921/Q.931 (QPTM)
6 : réservé pour d’autres couches d'adaptation SIGTRAN
7 : réservé pour d'autres couches d'adaptation SIGTRAN
8 : réservé pour d'autres couches d'adaptation SIGTRAN
9 à 127 : réservé par l'IETF
128 à255 : réservé pour des extensions de classe de message définies par l'IETF

La liste suivante contient les noms de message pour les messages définis.

Messages de transport de primitives de limite Q.921/Q.931 (QPTM)
0 : réservé
1 : Message de demande de données
2 : Message d'indication de données
3 : Message de demande d'unité de données
4 : Message d'indication d'unité de données
5 : Demande d'établissement
6 : Confirmation d'établissement
7 : Indication d'établissement
8 : Demande de libération
9 : Confirmation de libération
10 : Indication de libération
11 à 127 : réservé par l'IETF
128 à 255 : réservé pour des extensions QPTM définies par l'IETF

Messages de maintenance d'état de processus de serveur d'application (ASPSM)
0 : réservé
1 : ASP vif (UP)
2 : ASP mort (DOWN)
3 : Battement de cœur (BEAT)
4 : Accusé de réception d'ASP vif (UP ACK)
5 : Accusé de réception d'ASP mort (DOWN ACK)
6 : Accusé de réception de battement de cœur (BEAT ACK)
7 à 127 : réservé par l'IETF
128 à 255 : réservé pour des extensions ASPSM définies par l'IETF

Messages de maintenance de trafic de processus de serveur d'application (ASPTM)
0 : réservé
1 : ASP actif (ACTIVE)
2 : ASP inactif (INACTIVE)
3 : Accusé de réception d'ASP actif (ACTIVE ACK)
4 : Accusé de réception d'ASP inactif (INACTIVE ACK)
5 à 127 : réservé par l'IETF
128 à 255 : Réservé pour des extensions ASPTM définies par l'IETF

Messages de gestion (MGMT)
0 : Erreur (ERR)
1 : Notification (NTFY)
2 : Demande d'état de TEI
3 : Confirmation d'état de TEI
4 : Indication d'état de TEI
5 : Demande d'interrogation de TEI
6 à 127 : réservé par l'IETF
128 à 255 : réservé pour les extensions MGMT définies par l'IETF

 	3.1.3	Réservé
Le champ Réservé fait 8 bits. Il DEVRAIT être réglé tout à "0" et ignoré par le receveur.

 	3.1.4	Longueur de message
La longueur de message définit la longueur du message en octets, incluant l'en-tête commun. La longueur de message DOIT inclure les octets de bourrage de paramètre, s'il en est.

Note : un receveur DEVRAIT accepter le message que le bourrage final de paramètre soit inclus ou non dans la longueur du message.

 	3.1.5	Format de paramètre de longueur variable
Les messages IUA consistent en un en-tête commun suivi par zéro, un ou plusieurs paramètres de longueur variable, comme défini par le type de message. Les paramètres de longueur variable contenus dans un message sont définis dans un format Type-Longueur-Valeur (TLV) comme montré ci-dessous.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Étiquette de paramètre     |   Longueur de paramètre       |
+---------------+---------------+---------------+---------------+
\                                                               \
/                     Valeur de paramètre                       /
\                                                               \
+---------------+---------------+---------------+---------------+

Les paramètres obligatoires DOIVENT être placés avant les paramètres facultatifs dans un message.

Étiquette de paramètre : 16 bits (entier non signé)

Le champ Étiquette de paramètre est un identifiant de 16 bits du type de paramètre. Il prend une valeur de 0 à 65534. Les paramètres courants utilisés par les couches d'adaptation sont dans la gamme de 0x00 à 0x3f. Les étiquettes de paramètre définies sont les suivantes :

Paramètres courants : ces paramètres TLV sont communs entre les différentes couches d'adaptation :

Identifiant de paramètre	Nom du paramètre	
0x0000	réservé	
0x0001	Identifiant d'interface (entier)	
0x0002	non utilisé dans IUA	
0x0003	Identifiant d'interface (texte)	
0x0004	Chaîne INFO	
0x0005	DLCI	
0x0006	non utilisé dans IUA	
0x0007	Informations de diagnostic	
0x0008	Gamme d'identifiants d'interface	
0x0009	Données de battement de cœur	
0x000a	non utilisé dans IUA	
0x000b	Type de mode de trafic	
0x000c	Code d'erreur	
0x000d	État	
0x000e	Données de protocole	
0x000f	Raison de libération	
0x0010	État de TEI	
0x0011	Identifiant d'ASP	
0x0012 - 0x003f	non utilisés dans IUA	

La valeur de 65535 est réservée pour des extensions qui seront définies par l'IETF. Les valeurs autres que définies dans des descriptions de paramètres spécifiques sont réservées pour l'usage de l'IETF.

Longueur de paramètre : 16 bits (entier non signé). Le champ Longueur de paramètre contient la taille du paramètre en octets, incluant les champs Étiquette de paramètre, Longueur de paramètre, et Valeur du paramètre. Longueur de paramètre n'inclut pas les octets de bourrage.

Valeur de paramètre : longueur variable. Le champ Valeur de paramètre contient les informations réelles à transférer dans le paramètre.

La longueur totale d'un paramètre (incluant les champs Étiquette, Longueur, et Valeur) DOIT être un multiple de 4 octets. Si la longueur du paramètre n'est pas un multiple de 4 octets, l'envoyeur bourre le paramètre à la fin (c'est-à-dire, après le champ Valeur du paramètre) avec des octets tout de zéros. La longueur du bourrage N'EST PAS incluse dans le champ Longueur de paramètre. Un envoyeur NE DEVRAIT jamais bourrer avec plus de trois octets. Le receveur DOIT ignorer les octets de bourrage.

 	3.2	En-tête de message IUA
En plus de l'en-tête commun de message, il va y avoir un en-tête de message spécifique pour les messages QPTM et MGMT d'état de TEI. L'en-tête de message IUA va suivre immédiatement l'en-tête commun dans ces messages.

Cet en-tête de message va contenir l'identifiant d'interface et l'identifiant de connexion de liaison de données (DLCI, Data Link Connection Identifier). L'identifiant d'interface identifie l'interface physique qui termine le canal de signalisation à la SG pour laquelle les messages de signalisation sont envoyés/reçus. Le format du paramètre Identifiant d'interface peut être texte ou entier. Les identifiants d'interface sont alloués selon la politique de l'opérateur du réseau. Les valeurs d'entier utilisées n'ont de signification que locale, coordonnée entre la SG et l'ASP.

Les identifiants d'interface de format entier DOIVENT être acceptés. Les identifiants d'interface de format texte PEUVENT être acceptés, facultativement.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Étiquette (0x1)          |           Longueur            |
+---------------+---------------+---------------+---------------+
|                 Identifiant d'interface (entier)              |
+---------------+---------------+---------------+---------------+
|     Étiquette (0x5)           |           Longueur=8          |
+---------------+---------------+---------------+---------------+
|            DLCI               |             réservé           |
+---------------+---------------+---------------+---------------+

Figure 3. En-tête de message IUA (Identifiant d'interface en format d'entier)

La valeur de l'étiquette pour l'identifiant d'interface en format d'entier est 0x1. La longueur est toujours d'une valeur de 8.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Étiquette (0x3)          |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               /
/                   Identifiant d'interface (texte)             \
\                                                               /
+---------------+---------------+---------------+---------------+
|     Étiquette (0x5)           |           Longueur=8          |
+---------------+---------------+---------------+---------------+
|            DLCI               |           réservé             |
+---------------+---------------+---------------+---------------+

Figure 4. En-tête de message IUA (identifiant d'interface en format texte)

La valeur de l'étiquette pour l'identifiant d'interface en format de texte [ANSI X3.4] est 0x3. La longueur est variable.

La figure 5 montre le format du DLCI.

  MSB                                       LSB
+-----+-----+-----+-----+-----+-----+-----+-----+
|            SAPI                   | SPR |  0  |
+-----------------------------------+-----+-----+
|            TEI                          |  1  |
+-----------------------------------------+-----+

Figure 5. Format du DLCI

SPR :  deuxième bit réservé dans l'octet 1 (1 bit)

SAPI : identifiant de point d'accès de service (6 bits)

TEI : identifiant de point d'extrémité de terminal (7 bits)

Par exemple, SAPI = 0, TEI = 64, SPR = 0 serait codé ainsi :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Étiquette (0x5)           |           Longueur=8          |
+---------------+---------------+---------------+---------------+
|      0x0      |      0x81     |               0x0             |
+---------------+---------------+---------------+---------------+

Le champ DLCI (incluant le SAPI et le TEI) est codé conformément à Q.921.

 	3.3	Messages IUA
Les paragraphes qui suivent définissent le contenu des messages et paramètres. Les messages IUA vont utiliser l'en-tête de message commun (Figure 2) et l'en-tête de message IUA (Figures 3 et 4).

 	3.3.1	Messages de transport de primitives de limite Q.921/Q.931 (QPTM)
 	3.3.1.1	Messages Établir (demande, confirmation, indication)
Les messages Établir sont utilisés pour établir une liaison de données sur le canal de signalisation ou pour confirmer qu'une liaison de données a bien été établie sur le canal de signalisation. Le MGC contrôle l'état du canal D. Quand le MGC désire que le canal D soit en service, il envoie le message Demande d'établissement.

Quand le MGC envoie un message Demande d'établissement IUA, le MGC PEUT lancer un temporisateur. Ce temporisateur va être arrêté par la réception d'un message Confirmation ou Indication d'établissement IUA. Si le temporisateur arrive à expiration, le MGC va renvoyer un message Demande d'établissement IUA et relancer le temporisateur. En d'autres termes, le MGC PEUT continuer de demander l'établissement de la liaison de données sur une base périodique jusqu'à ce que l'état désiré soit réalisé ou prendre d'autres mesures (notifier la couche de gestion).

Quand la SG reçoit une Demande d'établissement IUA provenant du MGC, la SG devra envoyer la primitive Q.921 Demande d'établissement à l'entité Q.921. De plus, la SG devra transposer toute réponse reçue de l'entité Q.921 en le message approprié au MGC. Par exemple, si l'entité Q.921 répond par une primitive Q.921 Confirmation d'établissement, la couche IUA devra transposer cela en un message IUA Confirmation d'établissement. Autre exemple, si la couche IUA reçoit une Confirmation de libération ou Indication de libération Q.921 comme réponse apparente à la primitive Q.921 Demande d'établissement, la couche IUA devra transposer cela en le message IUA Confirmation de libération ou Indication de libération correspondant.

Les messages Établir contiennent l'en-tête commun de message suivi par l'en-tête de message IUA. Ils ne contiennent aucun paramètre supplémentaire.

 	3.3.1.2	Messages Libération (demande, confirmation, indication
Le message Demande de libération est utilisé pour libérer la liaison de données sur le canal de signalisation. Les messages Confirmation de libération et Indication de libération sont utilisés pour indiquer que la liaison de données sur le canal de signalisation a été libérée.

Si il n'est pas reçu de réponse au message Demande de libération, le MGC PEUT envoyer à nouveau le message Demande de libération. Si aucune réponse n'est reçue, le MGC peut considérer que la liaison de données a été libérée. Dans ce cas, le trafic de signalisation provenant de la SG n'est plus attendu sur ce canal D, et du trafic de signalisation ne sera pas envoyé à la SG pour ce canal D.

Les messages Libération contiennent l'en-tête commun de message suivi par l'en-tête de message IUA. Le message Confirmation de libération est en réponse à un message Demande de libération et il ne contient aucun autre paramètre. Les messages Demande et Indication de libération contiennent les paramètres suivants :

Raison 

Le format pour les paramètres de demande de libération est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Étiquette (0xf)           |           Longueur            |
+---------------+---------------+---------------+---------------+
|                              Raison                           |
+---------------+---------------+---------------+---------------+

Les valeurs valides pour Raison sont :

Valeur	Définit	Description	
0x0	RELEASE_MGMT	Libération générée par la couche de gestion.	
0x1	RELEASE_PHYS	Libération générée par une alarme de la couche physique.	
0x2	RELEASE_DM	Spécifique d'une demande. Indique que la couche 2 DEVRAIT libérer et refuser toute demande de l'extrémité distante d'établir une liaison de données sur le canal de signalisation (c'est-à-dire, si SABME est reçu, elle renvoie un DM).	
0x3	RELEASE_OTHER	Autres raisons de libération	

Note : Seuls RELEASE_MGMT, RELEASE_DM, et RELEASE_OTHER sont des codes de raison valides pour un message Demande de libération.

 	3.3.1.3	Messages de données (demande, indication)
Le message de données contient une unité de données de protocole (PDU) d'utilisateur RNIS Q.921 qui correspond au service de transfert d'information avec accusé de réception.

Les messages de données contiennent l'en-tête commun de message suivi par l'en-tête de message IUA. Le message de données contient le paramètre suivant Données de protocole. Le format des paramètres du message de données est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Étiquette (0xe)        |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                      Données de protocole                     /
\                                                               \
+---------------+---------------+---------------+---------------+

Les données de protocole contiennent des messages de signalisation de couche supérieure, par exemple, Q.931, QSIG.

 	3.3.1.4	Messages Unité de données (demande, indication)
Le message Unité de données contient une unité de données de protocole (PDU, Protocol Data Unit) d'utilisateur RNIS Q.921 correspondant à un service de transfert d'informations sans accusé de réception.

Les messages Unité de données contiennent l'en-tête commun de message suivi de l'en-tête de message IUA. Le message Unité de données contient le paramètre Données de protocole. Le format des paramètres de message Unité de données est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Étiquette (0xe)        |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                      Données de protocole                     /
\                                                               \
+---------------+---------------+---------------+---------------+

 	3.3.2	Messages de maintenance de processus de serveur d'application (ASPM)
Les messages ASPM utilisent seulement l'en-tête commun de message.

 	3.3.2.1	ASP vif (ASPUP)
Le message ASP vif (ASPUP) est envoyé par un ASP pour indiquer à une SG qu'il est prêt à recevoir des messages de trafic ou de maintenance.

Le message ASPUP contient les paramètres suivants :
Identifiant d'ASP (facultatif)
Chaîne d'INFO (facultatif)

Le format des paramètres de message ASPUP est le suivant :
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Étiquette = 0x0011      |         Longueur = 8          |
+---------------+---------------+---------------+---------------+
|                         Identifiant d'ASP                     |
+---------------+---------------+---------------+---------------+
|       Étiquette = 0x0004      |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                      Chaîne d'INFO                            /
\                                                               \
+---------------+---------------+---------------+---------------+

Identifiant d'ASP : entier non signé de 32 bits. Le paramètre facultatif Identifiant d'ASP contient une unique valeur qui est de signification locale parmi les ASP qui prennent en charge un AS. La SG devrait sauvegarder l'identifiant d'ASP pour l'utiliser, si nécessaire, avec le message Notifier (voir le paragraphe 3.3.3.2).

Le paramètre facultatif Chaîne d'INFO peut porter toute chaîne significative de 8 bits en caractères ASCII [ANSI X3.4] avec le message. La longueur du paramètre Chaîne d'INFO est de 0 à 255 caractères. Aucune procédure n'est actuellement identifiée pour son utilisation, mais la chaîne INFO PEUT être utilisée à des fins de débogage.

 	3.3.2.2	Accusé de réception d'ASP vif
Le message Accusé de réception d'ASP vif est utilisé pour accuser réception d'un message ASP vif reçu d'un homologue IUA distant.

Le message Accusé de réception d'ASPUP contient le paramètre suivant : Chaîne d'INFO (facultatif).

Le format du paramètres de message Accusé de réception d'ASPUP est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Étiquette = 0x0004       |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                         Chaîne d'INFO                         /
\                                                               \
+---------------+---------------+---------------+---------------+

Le format et la description du paramètre facultatif Chaîne d'INFO sont les mêmes que pour le message ASP vif (paragraphe  3.3.2.1).

 	3.3.2.3	ASP mort (ASPDN)
Le message ASP mort (ASPDN) est envoyé par un ASP pour indiquer à une SG qu'il N'EST PAS prêt à recevoir des messages de trafic ou de maintenance.

Le message ASPDN contient le paramètre suivant : Chaîne d'INFO (facultatif)

Le format des paramètres de message ASPDN est :

 0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Étiquette = 0x0004       |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                         Chaîne d'INFO                         /
\                                                               \
+---------------+---------------+---------------+---------------+

Le format et la description du paramètre facultatif Chaîne d'INFO sont les mêmes que pour le message ASP vif (paragraphe  3.3.2.1).

 	3.3.2.4	Accusé de réception d'ASP mort
Le message Accusé de réception d'ASP mort est utilisé pour accuser réception d'un message ASP mort reçu d'un homologue IUA distant. Le message Accusé de réception d'ASP mort contient le paramètre suivant : Chaîne d'INFO (facultatif).

Le format pour les paramètres de message Accusé de réception d'ASP mort est :
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Étiquette = 0x0004       |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                        Chaîne d'INFO                          /
\                                                               \
+---------------+---------------+---------------+---------------+

Le format et la description du paramètre facultatif Chaîne d'INFO sont les mêmes que pour le message ASP vif (paragraphe  3.3.2.1).

 	3.3.2.5	ASP actif (ASPAC)
Le message ASPAC est envoyé par un ASP pour indiquer à une SG qu'il est actif et prêt à être utilisé.

Le message ASPAC contient les paramètres suivants :
Type de mode de trafic (obligatoire)
Identifiants d'interface (facultatif) :
- une combinaison d'entiers et de gammes d'entiers, OU
- une chaîne (format de texte)
Chaîne d'INFO (facultatif)

Le format pour le message ASPAC utilisant des identifiants d'interface en format d'entiers est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Étiquette = 0x000b       |         Longueur = 8          |
+---------------+---------------+---------------+---------------+
|                     Type de mode de trafic                    |
+---------------+---------------+---------------+---------------+
|    Étiquette (0x1=entier)     |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                     identifiants d'interface                  /
\                                                               \
+---------------+---------------+---------------+---------------+
|Étiquette (0x8=gamme d'entiers)|          Longueur             |
+---------------+---------------+---------------+---------------+
|                 Identifiant d'interface1 début*               |
+---------------+---------------+---------------+---------------+
|                  Identifiant d'interface1 fin*                |
+---------------+---------------+---------------+---------------+
|                 Identifiant d'interface2 début*               |
+---------------+---------------+---------------+---------------+
|                  Identifiant d'interface2 fin*                |
+---------------+---------------+---------------+---------------+
               .                                       .
+---------------+---------------+---------------+---------------+
|                 Identifiant d'interfaceN début*               |
+---------------+---------------+---------------+---------------+
|                  Identifiant d'interfaceN fin*                |
+---------------+---------------+---------------+---------------+
\                                                               \
/        Paramètres supplémentaires d'identifiant d'interface   /
\                  de type d'étiquette 0x1 ou 0x8               \
/                                                               /
+---------------+---------------+---------------+---------------+
|      Étiquette (0x4)          |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                        Chaîne d'INFO                          /
\                                                               \
+---------------+---------------+---------------+---------------+

Le format du message ASPAC qui utilise les identifiants d'interface en format texte (chaîne) est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Étiquette = 0x000b       |         Longueur = 8          |
+---------------+---------------+---------------+---------------+
|                     Type de mode de trafic                    |
+---------------+---------------+---------------+---------------+
|     Étiquette (0x3=chaîne)    |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                  Identifiants d'interface                     /
\                                                               \
+---------------+---------------+---------------+---------------+
\                                                               \
/       Paramètres supplémentaires d'identifiant d'interface    /
\                   de type d'étiquette 0x3                     \
/                                                               /
+---------------+---------------+---------------+---------------+
|      Étiquette (0x4)          |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                        Chaîne d'INFO                          /
\                                                               \
+---------------+---------------+---------------+---------------+

Le paramètre Type de mode de trafic identifie le mode de trafic de fonctionnement de l'ASP au sein d'un AS. Les valeurs valides pour Type sont :

Valeur	Description
0x1	Outrepasse
0x2	Partage de charge

Au sein d'un AS particulier, un seul type de mode de trafic peut être utilisé. La valeur Outrepasse indique que l'ASP fonctionne en mode outrepassement, dans lequel l'ASP prend tout le trafic dans un serveur d'application (c'est-à-dire, fonctionnement principal/de secours) outrepassant tous les ASP actuellement actifs dans l'AS. En mode partage de charge, l'ASP va partager la distribution du trafic avec tous les autres ASP actuellement actifs.

Le paramètre facultatif d'identifiant d'interface contient une liste d'identifiants d'interface entiers (type 0x1 ou type 0x8) ou de chaînes de texte (type 0x3) indexant le trafic de serveur d'application que l'ASP envoyeur est configuré/enregistré à recevoir. Si des identifiants d'interface en format d'entiers sont utilisés, l'ASP peut aussi envoyer des gammes d'identifiants d'interface (type 0x8). Les types d'identifiant d'interface d'entier (0x1) et de gamme d'entier (0x8) sont permis dans le même message. Les identifiants d'interface en format de texte (0x3) ne peuvent pas être utilisés avec des types d'entier (0x1) ou de gamme d'entier (0x8).

Si aucun identifiant d'interface n'est inclus, le message est pour tous les identifiants d'interface provisionnés au sein du ou des AS dans lesquels l'ASP est provisionné. Si seul un sous ensemble des identifiants d'interface est inclus, l'ASP est noté comme actif pour tous les identifiants d'interface provisionnés pour cet AS.

Note :  Si le paramètre Identifiant d'interface facultatif est présent, l'identifiant d'interface en format d'entier DOIT être pris en charge, tandis que l'identifiant d'interface en format de texte PEUT être pris en charge.

Le format et la description du paramètre facultatif Chaîne d'INFO sont les mêmes que pour le message ASP vif (paragraphe  3.3.2.1).

Une SG qui reçoit un ASPAC avec un type de mode de trafic incorrect pour un identifiant d'interface particulier va répondre par un message d'erreur (Cause : mode de traitement du trafic non accepté).

 	3.3.2.6	Accusé de réception d'ASP actif
Le message Accusé de réception d'ASPAC est utilisé pour accuser réception d'un message ASP actif reçu d'un homologue IUA distant.

Le message Accusé de réception d'ASPAC contient les paramètres suivants :
Type de mode de trafic (Obligatoire)
Identifiant d'interface (Facultatif) :
- Combinaison d'entiers et de gammes d'entiers, OU
- chaîne (en format texte)
Chaîne d'INFO (Facultatif)

Le format du message Accusé de réception d'ASPAC avec des identifiants d'interface en format d'entier est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Étiquette = 0x000b       |         Longueur = 8          |
+---------------+---------------+---------------+---------------+
|                     Type de mode de trafic                    |
+---------------+---------------+---------------+---------------+
|  Étiquette (0x1=entier)      |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                     Identifiants d'interface                  /
\                                                               \
+---------------+---------------+---------------+---------------+
| Étiquette (0x8=gamme d'entier)|          Longueur             |
+---------------+---------------+---------------+---------------+
|                 Identifiant d'interface1 début*               |
+---------------+---------------+---------------+---------------+
|                  Identifiant d'interface1 fin*                |
+---------------+---------------+---------------+---------------+
|                 Identifiant d'interface2 début*               |
+---------------+---------------+---------------+---------------+
|                  Identifiant d'interface2 fin*                |
+---------------+---------------+---------------+---------------+
        .                                       .
        .                                       .
        .                                       .
+---------------+---------------+---------------+---------------+
|                 Identifiant d'interfaceN début*               |
+---------------+---------------+---------------+---------------+
|                  Identifiant d'interfaceN fin*                |
+---------------+---------------+---------------+---------------+
\                                                               \
/         Paramètres supplémentaires d'identifiant d'interface  /
\              de type d'étiquette 0x1 ou 0x8                   \
/                                                               /
+---------------+---------------+---------------+---------------+
|      Étiquette (0x4)          |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                        Chaîne d'INFO                          /
\                                                               \
+---------------+---------------+---------------+---------------+

Le format du message Accusé de réception d'ASP Actif utilisant des identifiants d'interface de format texte (chaîne) est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Étiquette = 0x000b       |         Longueur = 8          |
+---------------+---------------+---------------+---------------+
|                     Type de mode de trafic                    |
+---------------+---------------+---------------+---------------+
|   Étiquette (0x3=string)      |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                     Identifiants d'interface                  /
\                                                               \
+---------------+---------------+---------------+---------------+
\                                                               \
/         Paramètres supplémentaires d'identifiant d'interface  /
\                 de type d'étiquette 0x3                       \
/                                                               /
+---------------+---------------+---------------+---------------+
|      Étiquette (0x4)          |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                        Chaîne d'INFO                          /
\                                                               \
+---------------+---------------+---------------+---------------+

Le format des paramètres Type de mode de trafic et Identifiant d'interface est le même que pour le message ASP actif (paragraphe  3.3.2.5).

Le format et la description du paramètre facultatif Chaîne d'INFO sont les mêmes que pour le message ASP vif (paragraphe  3.3.2.1).

 	3.3.2.7	ASP Inactif (ASPIA)
Le message ASPIA est envoyé par un ASP pour indiquer à une SG qu'il n'est plus un ASP actif pour être utilisé à partir d'une liste d'ASP. La SG va répondre avec un message Accusé de réception d'ASPIA et soit éliminer les messages entrants, soit les mettre en mémoire tampon pour une durée mesurée par un temporisateur puis les éliminer.

Le message ASPIA contient les paramètres suivants :
Identifiants d'interface (facultatif) :
- combinaison d'entiers et de gammes d'entiers, OU
- chaîne (format de texte)
Chaîne d'INFO (facultatif)

Le format des paramètres de message ASP inactif utilisant des identifiants d'interface en format d'entier est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Étiquette (0x1=entier)      |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                     Identifiants d'interface                  /
\                                                               \
+---------------+---------------+---------------+---------------+
| Étiquette (0x8=gamme d'entier)|          Longueur             |
+---------------+---------------+---------------+---------------+
|                 Identifiant d'interface1 début*               |
+---------------+---------------+---------------+---------------+
|                  Identifiant d'interface1 fin*                |
+---------------+---------------+---------------+---------------+
|                 Identifiant d'interface2 début2*              |
+---------------+---------------+---------------+---------------+
|                  Identifiant d'interface2 fin*                |
+---------------+---------------+---------------+---------------+
        .                                       .
        .                                       .
        .                                       .
+---------------+---------------+---------------+---------------+
|                 Identifiant d'interfaceN début*               |
+---------------+---------------+---------------+---------------+
|                  Identifiant d'interfaceN fin*                 |
+---------------+---------------+---------------+---------------+
\                                                               \
/         Paramètres supplémentaires d'identifiant d'interface  /
\              de type d'étiquette 0x1 ou 0x8                   \
/                                                               /
+---------------+---------------+---------------+---------------+
|      Étiquette (0x4)          |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                       Chaîne d'INFO                           /
\                                                               \
+---------------+---------------+---------------+---------------+

Le format des messages ASP inactif qui utilisent des identifiants d'interface en format de texte (chaîne) est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Étiquette (0x3=chaîne)     |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                     Identifiants d'interface                  /
\                                                               \
+---------------+---------------+---------------+---------------+0
\                                                               \
/         Paramètres supplémentaires d'identifiant d'interface  /
\                  de type d'étiquette 0x3                      \
/                                                               /
+---------------+---------------+---------------+---------------+
|      Étiquette (0x4)          |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                        Chaîne d'INFO                          /
\                                                               \
+---------------+---------------+---------------+---------------+

Le paramètre facultatif des identifiants d'interface contient une liste d'entiers ou de chaînes de texte d'identifiant d'interface qui indexent le trafic du serveur d'application que l'ASP envoyeur est configuré/enregistré à recevoir, mais qu'il ne veut pas recevoir pour l'instant.

Le format et la description du paramètre facultatif Chaîne d'INFO sont les mêmes que pour le message ASP actif (paragraphe  3.3.2.5).

 	3.3.2.8	Accusé de réception d'ASP inactif
Le message Accusé de réception d'ASP inactif (ASPIA) est utilisé pour accuser réception d'un message ASP inactif reçu d'un homologue IUA distant.

Le message Accusé de réception d'ASPIA contient les paramètres suivants :
Identifiants d'interface (facultatif) :
- combinaison d'entier et gammes d'entier, OU
- chaîne (format de texte)
Chaîne d'INFO (facultatif)

Le format du message Accusé de réception d'ASP inactif utilisant des identifiants d'interface en format d'entier est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Étiquette (0x1=entier)       |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                     Identifiants d'interface                  /
\                                                               \
+---------------+---------------+---------------+---------------+
| Étiquette (0x8=gamme d'entier)|          Longueur             |
+---------------+---------------+---------------+---------------+
|                 Identifiant d'interface1 début*               |
+---------------+---------------+---------------+---------------+
|                  Identifiant d'interface1 fin*                |
+---------------+---------------+---------------+---------------+
|                 Identifiant d'interface2 début*               |
+---------------+---------------+---------------+---------------+
|                  Identifiant d'interface2 fin*                |
+---------------+---------------+---------------+---------------+
        .                                       .
        .                                       .
        .                                       .
+---------------+---------------+---------------+---------------+
|                 Identifiant d'interfaceN début*               |
+---------------+---------------+---------------+---------------+
|                  Identifiant d'interfaceN fin*                |
+---------------+---------------+---------------+---------------+
\                                                               \
/         Paramètres supplémentaires d'identifiant d'interface  /
\                  de type d'étiquette 0x1 ou 0x8               \
/                                                               /
+---------------+---------------+---------------+---------------+
|         Étiquette (0x4)       |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                        Chaîne d'INFO                          /
\                                                               \
+---------------+---------------+---------------+---------------+

Le format pour le message Accusé de réception d'ASP inactif qui utilise des identifiants d'interface en format de texte (chaîne) est le suivant :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Étiquette (0x3=chaîne)     |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                     Identifiants d'interface                  /
\                                                               \
+---------------+---------------+---------------+---------------+
\                                                               \
/         Paramètres supplémentaires d'identifiant d'interface  /
\                  de type d'étiquette 0x3                      \
/                                                               /
+---------------+---------------+---------------+---------------+
|      Étiquette (0x4)          |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                        Chaîne d'INFO                          /
\                                                               \
+---------------+---------------+---------------+---------------+

Le format et la description des paramètres facultatif Identifiant d'interface et Chaîne d'INFO sont les mêmes que pour le message ASP actif (paragraphe  3.3.2.5).

 	3.3.2.9	Battement de cœur (BEAT)
Le message Battement de cœur est utilisé facultativement pour s'assurer que les homologues IUA sont toujours disponibles les uns pour les autres. Il est recommandé de l'utiliser quand l'IUA fonctionne sur une couche transport autre que SCTP, qui a son propre battement de cœur.

Le message BEAT contient le paramètre Données de battement de cœur (facultatif). Le format du message BEAT est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Étiquette = 0x0009       |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                     Données de battement de cœur              /
\                                                               \
+---------------+---------------+---------------+---------------+

Le contenu du paramètre Données de battement de cœur est défini par le nœud envoyeur. Les données de battement de cœur pourraient inclure, par exemple, un numéro de séquence de battement de cœur et/ou un horodatage. Le receveur d'un message Battement de cœur ne traite pas ce champ car il n'a de signification que pour l'envoyeur. Le receveur DOIT répondre par un message Accusé de réception de battement de cœur.

 	3.3.2.10	Accusé de réception de battement de cœur (BEAT-Ack)
Le message Accusé de réception de battement de cœur est envoyé en réponse à un message Battement de cœur reçu. Il inclut tous les paramètres du message Battement de cœur reçu, sans aucun changement.

 	3.3.3	Messages de gestion de couches (MGMT)
 	3.3.3.1	Erreur (ERR)
Le message Erreur est utilisé pour notifier à un homologue un événement d'erreur associé à un message entrant. Par exemple, le type de message peut être inattendu compte tenu de l'état actuel, ou une valeur de paramètre peut être invalide.

Le message Erreur aura seulement l'en-tête commun de message. Le message Erreur contient les paramètres suivants :
Code d'erreur
Informations de diagnostic (facultatif)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Étiquette = 0x000c      |        Longueur = 8           |
+---------------+---------------+---------------+---------------+
|                          Code d'erreur                        |
+---------------+---------------+---------------+---------------+
|       Étiquette = 0x0007      |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               /
/                   Informations de diagnostic                  \
\                                                               /
+---------------+---------------+---------------+---------------+

Le paramètre Code d'erreur indique la raison du message d'erreur. La valeur du paramètre Code d'erreur peut être une des suivantes :

0x01	Version invalide	
0x02	Identifiant d'interface invalide	
0x03	Classe de message non prise en charge	
0x04	Type de message non pris en charge	
0x05	Mode de traitement du trafic non pris en charge	
0x06	Message inattendu	
0x07	Erreur de protocole	
0x08	Type d'identifiant d'interface non pris en charge	
0x09	Identifiant de flux invalide	
0x0a	TEI non alloué	
0x0b	SAPI non reconnu	
0x0c	Combinaison de TEI - SAPI invalide	
0x0d	Refusé - blocage de gestion	
0x0e	Identifiant d'ASP exigé	
0x0f	Identifiant d'ASP invalide	

L'erreur "Version invalide" sera envoyée si un message est reçu avec une version invalide ou non prise en charge. Le message d'erreur va contenir la version prise en charge dans l'en-tête commun. Le message d'erreur pourrait facultativement fournir la version prise en charge dans la zone Informations de diagnostic.

L'erreur "Identifiant d'interface invalide" sera envoyée par une SG si un ASP envoie un message avec une valeur invalide (mal configurée) d'identifiant d'interface. Pour cette erreur, les informations de diagnostic DOIVENT contenir assez du message en cause pour identifier l'identifiant d'interface invalide. Par exemple, dans le cas des messages de gestion QPTM et État de TEI, au minimum, les en-têtes de message commun et IUA du message en cause seront placés dans les informations de diagnostic.

L'erreur "Mode de traitement du trafic non pris en charge" sera envoyée par une SG si un ASP envoie un ASP actif avec un mode de traitement du trafic non pris en charge. Un exemple serait le cas où la SG ne prendrait pas en charge le partage de charge.

L'erreur "Message inattendu" sera envoyée par un ASP si il a reçu un message QPTM d'une SG alors qu'il est dans l'état inactif (l'ASP pourrait facultativement éliminer le message et ne pas envoyer d'erreur). Elle pourrait aussi être envoyée par un ASP si il avait reçu un message défini et reconnu que la SG n'est pas supposée envoyer (par exemple, si le MGC reçoit un message Demande d'établissement IUA).

L'erreur "Erreur de protocole" sera envoyée pour toute anomalie de protocole (c'est-à-dire, un message bogué).

L'erreur "Identifiant de flux invalide" sera envoyée si un message a été reçu sur un flux SCTP inattendu (par exemple, un message MGMT reçu sur un flux autre que "0").

L'erreur "Type d'identifiant d'interface non pris en charge" sera envoyée par une SG si un ASP envoie un identifiant d'interface en format texte et que la SG ne prend en charge que les identifiants d'interface en format d'entier. Quand l'ASP reçoit cette erreur, il va devoir envoyer à nouveau ce message avec un Identifiant d'interface en format d'entier.

L'erreur "Type de message non pris en charge" sera envoyée si est reçu un message avec un type de message non pris en charge.

L'erreur "Classe de message non prise en charge" sera envoyée si est reçu un message avec une classe de message non attendue ou non prise en charge.

L'erreur "TEI non alloué" peut être utilisée quand la SG reçoit un message IUA qui inclut un TEI qui n'a pas été alloué ou dont l'utilisation n'est pas reconnue sur le canal D RNIS indiqué.

L'erreur "SAPI non reconnu" va traiter le cas de l'utilisation d'un SAPI qui n'est pas reconnu par la SG. L'erreur "Combinaison de TEI - SAPI invalide" identifie des erreurs où le TEI est alloué et le SAPI est reconnu, mais la combinaison n'est pas valide pour l'interface (par exemple, sur une interface au débit de base (BRI) le MGC essaye d'envoyer des messages de gestion Q.921 via IUA alors que c'est la gestion de couches chez la SG qui DEVRAIT effectuer cette fonction).

L'erreur "Refusé - blocage de gestion" est envoyée quand un message ASP vif ou ASP actif est reçu et que la demande est refusée pour des raisons de gestion (par exemple, fermeture de la gestion).

L'erreur "Identifiant d'ASP exigé" est envoyé par une SG en réponse à un message ASP vif qui ne contient pas de paramètre Identifiant d'ASP alors que la SG en exige un. L'ASP DEVRAIT envoyer à nouveau le message ASP vif avec un identifiant d'ASP.

L'erreur "Identifiant d'ASP invalide" est envoyée par une SG en réponse à un message ASP vif avec un identifiant d'ASP invalide (c'est-à-dire, non unique).

Informations de diagnostic : longueur variable. Lorsque incluses, les informations de diagnostic facultatives peuvent être toute information relative à la condition d'erreur, pour aider à l'identification de la condition d'erreur. Les informations de diagnostic DEVRAIENT contenir le message en cause.

Les messages d'erreur NE DOIVENT PAS être générés en réponse aux autres messages d'erreur.

 	3.3.3.2	Notification (NTFY)
Le message Notification est utilisé pour fournir une indication autonome des événements d'IUA à un homologue IUA.

Le message NTFY ne va utiliser que l'en-tête commun de message. Le message NTFY contient les paramètres suivants :
État (obligatoire)
Identifiant d'ASP (facultatif)
Identifiants d'interface (facultatif)
Chaîne d'INFO (facultatif)

Le format du message NTFY avec les identifiants d'interface en format d'entier est :
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Étiquette = 0x000d        |         Longueur = 8          |
+---------------+---------------+---------------+---------------+
|        Type d'état            |     Identification d'état     |
+---------------+---------------+---------------+---------------+
|     Étiquette = 0x0011        |         Longueur = 8          |
+---------------+---------------+---------------+---------------+
|                        Identifiant d'ASP                      |
+---------------+---------------+---------------+---------------+
|   Étiquette (0x1=entier)      |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                     identifiants d'interface                  /
\                                                               \
+---------------+---------------+---------------+---------------+
|Étiquette (0x8=gamme d'entier) |          Longueur             |
+---------------+---------------+---------------+---------------+
|                 Identifiant d'interface1 début*               |
+---------------+---------------+---------------+---------------+
|                  Identifiant d'interface1 fin*                |
+---------------+---------------+---------------+---------------+
|                 Identifiant d'interface2 début*               |
+---------------+---------------+---------------+---------------+
|                  Identifiant d'interface2 fin*                |
+---------------+---------------+---------------+---------------+
        .                                       .
        .                                       .
        .                                       .
+---------------+---------------+---------------+---------------+
|                 Identifiant d'interfaceN début*               |
+---------------+---------------+---------------+---------------+
|                  Identifiant d'interfaceN fin*                |
+---------------+---------------+---------------+---------------+
\                                                               \
/         Paramètres supplémentaires d'identifiant d'interface  /
\               du type d'étiquette 0x1 ou 0x8                  \
/                                                               /
+---------------+---------------+---------------+---------------+
|     Étiquette = 0x0004        |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                       Chaîne d'INFO                           /
\                                                               \
+---------------+---------------+---------------+---------------+

Le format du message NTFY avec des identifiants d'interface en format teste est :
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Étiquette = 0x000d         |         Longueur = 8          |
+---------------+---------------+---------------+---------------+
|        Type d'état            |      Informations d'état      |
+---------------+---------------+---------------+---------------+
|     Étiquette = 0x0011        |         Longueur = 8          |
+---------------+---------------+---------------+---------------+
|                       ASP Identifiant d'ASP                   |
+---------------+---------------+---------------+---------------+
|    Étiquette (0x3=chaîne)     |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                     identifiants d'interface                  /
\                                                               \
+---------------+---------------+---------------+---------------+
\                                                               \
/         Paramètres supplémentaires d'identifiant d'interface  /
\                 de type d'étiquette 0x3                       \
/                                                               /
+---------------+---------------+---------------+---------------+
|     Étiquette = 0x0004        |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                        Chaîne d'INFO                          /
\                                                               \
+---------------+---------------+---------------+---------------+

Type d'état : 16 bits (entier non signé). Le paramètre Type d'état identifie le type du message NTFY. Les valeurs suivantes sont valides :
1	Changement d'état du serveur d'application (AS-State_Change)
2	Autre

Informations d'état : 16 bits (entier non signé). Le paramètre État Informations d'état contient des informations plus détaillées pour la notification, sur la base de la valeur du type d'état. Si le type d'état est "AS-State_Change", les valeurs d'Informations d'état sont utilisées :
1	réservé
2	Serveur d'application inactif (AS-INACTIF)
3	Serveur d'application actif (AS-ACTIF)
4	Serveur d'application en instance (AS-EN-INSTANCE)

Ces notifications sont envoyées d'une SG à un ASP lors d'un changement d'état d'un serveur d'application particulier. La valeur reflète le nouvel état du serveur d'application.

Si le Type d'état est "Autre", les valeurs d'informations d'état sont :

Valeur	Description
1	Ressources actives d'ASP insuffisantes dans l'AS
2	Autre ASP actif
3	Défaillance d'ASP

Ces notifications ne se fondent pas sur le rapport de la SG du changement d'état d'un ASP ou AS. Dans le cas de ressources insuffisantes d'ASP, la SG indique à un ou des ASP inactifs dans l'AS qu'un autre ASP est exigé afin de traiter la charge de l'AS (mode de partage de charge). Pour le cas de "Autre ASP actif", un ASP est informé quand un autre ASP passe à l'état ASP-ACTIF en mode outrepassement. L'identifiant d'ASP (si disponible) de l'autre ASP DOIT être placé dans le message. Pour le cas de défaillance d'ASP, la SG indique à ou aux ASP dans l'AS qu’un des ASP est passé à l'état ASP-MORT. L'identifiant d'ASP (si disponible) de l'ASP défaillant DOIT être placé dans le message.

Le format et la description de l'identifiant facultatif d'ASP sont les même que pour le message ASP vif (paragraphe  3.3.2.1). Le format et la description des paramètres facultatifs Identifiants d'interface et Chaîne d'INFO sont les mêmes que pour le message ASP actif (paragraphe 3.3.2.5).

 	3.3.3.3	Messages État de TEI (demande, confirmation, et indication)
Les messages État de TEI sont échangés entre les homologues de couche IUA pour demander, confirmer, et indiquer l'état d'un TEI particulier.

Les messages État de TEI contiennent l'en-tête commun de message suivi par l'en-tête de message IUA. Le message Demande d'état de TEI ne contient aucun paramètre supplémentaire.

Dans le modèle de couche RNIS 2/3 intégrée (par exemple, dans les commutateurs RNIS traditionnels) il est supposé que la gestion de couches pour la couche Q.921 et la couche Q.931 sont co-localisées. Dans le remorquage RNIS, cette hypothèse n'est pas nécessairement valide. Les messages État de TEI permettent aux deux entités de gestion de couches de communiquer l'état du TEI. De plus, savoir qu'un TEI est en service permet à l'ASP de demander à la SG d'établir la liaison de données avec le terminal (via le message Établir IUA) pour signaler si l'ASP veut être aux commandes de l'établissement de la liaison de données. Une autre utilisation de la procédure État de TEI est quand la gestion de couches chez un ASP peut préparer la signalisation d'envoi/réception de/vers un certain TEI et confirmer/vérifier l'établissement d'une liaison de données avec ce TEI. Par exemple, si une liaison de données est établie pour un TEI dont l'ASP ne sait pas si il a été alloué, l'ASP peut vérifier pour voir si il a été alloué ou si il y a eu une erreur dans le message de signalisation. Aussi, sachant qu'un TEI est hors service, l'ASP n'a pas besoin de demander à la SG d'établir une liaison de données avec ce TEI.

Les messages Indication et Confirmation d'état de TEI contiennent le paramètre suivant : État

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Étiquette = 0x0010      |        Longueur = 8           |
+---------------+---------------+---------------+---------------+
|                              État                             |
+---------------+---------------+---------------+---------------+

Les valeurs valides pour État sont montrées dans le tableau suivant.

Valeur	Définit	Description
0x0	ALLOUÉ	le TEI est considéré comme alloué par Q.921
 0x1	NON ALLOUÉ	le TEI est considéré comme non alloué par Q.921

 	3.3.3.4	Message d'interrogation de TEI (demande)
Le message Interrogation de TEI est envoyé par l'ASP pour interroger le ou les TEI. Ce message consiste en l'en-tête commun et l'en-tête IUA. Le DLCI dans l'en-tête IUA DOIT être ignoré par la SG. La SG va répondre à ce message avec une ou des indications d'état de TEI.

 	4.	Procédures

La couche IUA a besoin de répondre aux diverses primitives qu'elle reçoit des autres couches ainsi qu’aux messages qu'elle reçoit de la couche IUA homologue. Cette section décrit les diverses procédures impliquées dans les réponse à ces événements.

 	4.1	Procédures pour la prise en charge du service du paragraphe 1.4.1
Ces procédures réalisent le service "Transport de primitives de limite Q.921/Q.931" de la couche IUA.

 	4.1.1	Procédures des primitives Q.921 ou Q.931
À réception de ces primitives de la couche locale, la couche IUA va envoyer le message QPTM correspondant (Données, Unité de données, Établir, Libérer) à son homologue. Quand elle fait cela, la couche IUA a besoin de remplir correctement les divers champs des en-têtes, commun et spécifiques. De plus, le message doit être envoyé sur le flux SCTP qui correspond au canal D (Identifiant d'interface).

 	4.1.2	Procédures des messages QPTM
À réception de messages QPTM d'une couche IUA homologue, la couche IUA sur une SG ou un MGC doit invoquer les primitives de couche correspondantes (DL-ESTABLISH, DL-DATA, DL-UNIT DATA, DL-RELEASE) à la couche locale Q.921 ou Q.931.

 	4.2	Procédures pour la prise en charge du service du paragraphe 1.4.2
Ces procédures réalisent le service "prise en charge de la communication entre gestions de couche" de la couche IUA.

 	4.2.1	Procédures des primitives de gestion de couches
À réception de ces primitives de la gestion de couches locale, la couche IUA va fournir la primitive de réponse appropriée à travers l'interface interne locale de gestion de couches.

Une demande M-SCTP ESTABLISH provenant de la gestion de couches va initier l'établissement d'une association SCTP.  Une confirmation M-SCTP ESTABLISH va être envoyée à la gestion de couches quand l'établissement d'association initié sera achevé. Une indication M-SCTP ESTABLISH est envoyée d'un nœud IUA homologue à la gestion de couches lorsque l'établissement réussi d'une association SCTP entrante est achevé.

Une demande M-SCTP RELEASE de la part de la gestion de couches va initier la suppression d'une association SCTP. Une confirmation M-SCTP RELEASE va être envoyée par la gestion de couches quand la suppression d'association est achevée. Une indication M-SCTP RELEASE est envoyée à la gestion de couches quand est réussie la suppression d'une association SCTP initiée par une IUA homologue.

Une demande et indication M-SCTP STATUS prend en charge une interrogation de la gestion de couches sur l'état local d'une association SCTP particulière.

 Une indication M-NOTIFY et une indication M-ERROR indiquent à la gestion de couches la notification ou les informations d'erreur contenues dans un message IUA reçu, respectivement Notification ou Erreur. Ces indications peuvent aussi être générées sur la base d’événements IUA locaux.

Une demande/indication M-ASP STATUS et M-AS-STATUS prend en charge une interrogation de la gestion de couches sur l'état local d'un ASP ou AS particulier. Aucun homologue de protocole IUA n'est invoqué.

Les demandes M-ASP-UP, M-ASP-DOWN, M-ASP-INACTIVE, et M-ASP-ACTIVE permettent à la gestion de couches chez un ASP d'initier les changements d'état. Ces demandes vont avoir pour résultat les messages IUA sortants : ASP VIF, ASP MORT, ASP INACTIF, et ASP ACTIF.

Les confirmations M-ASP-VIF, M-ASP-MORT, M-ASP-INACTIF, et M-ASP-ACTIF indiquent à la gestion de couches que la demande précédente a été confirmée.

À réception d'une primitive M-TEI STATUS de la gestion de couches, l'IUA va envoyer le message MGMT correspondant (État de TEI) à son homologue. Tout en faisant cela, la couche IUA doit remplir correctement divers champs des en-têtes, commun et spécifiques.

Tous les messages MGMT sont envoyés sur un flux en séquence pour garantir l'ordre. Le flux SCTP '0' DEVRAIT être utilisé.

 	4.2.2	Réception des messages de gestion de l'homologue IUA
À réception de messages de gestion IUA, la couche IUA DOIT invoquer les indications de primitives de gestion de couches correspondantes (par exemple, M-AS STATUS ind., M-ASP STATUS ind., M-ERROR ind., M-TEI STATUS) à la couche de gestion locale.

M-NOTIFY indication et M-ERROR indication indiquent à la gestion de couches les informations de notification ou d'erreur contenues dans un message IUA Notifier ou Erreur reçu. Ces indications peuvent aussi être générées sur la base d'événements IUA locaux.

Tous les messages de gestion sont envoyés sur un flux séquentiel pour assurer leur bon ordre. Le flux SCTP '0' DEVRAIT être utilisé.

 	4.3	Procédures de prise en charge de service du paragraphe 1.4.3
Ces procédures réalisent le service "Prise en charge de la gestion des associations actives entre SG et MGC" de la couche IUA.

 	4.3.1	Maintenance d'état d'AS et d'ASP
La couche IUA sur la SG doit conserves les états de chaque ASP ainsi que l'état de l'AS.

 	4.3.1.1	États d'ASP
L'état de chaque ASP, dans chaque AS qui est configuré, est conservé dans la couche IUA sur la SG. L'état d'un ASP change à cause des types d'événements suivants :

*	Réception de messages provenant de la couche IUA homologue à cet ASP ;
*	Réception de messages provenant de la couche IUA homologue chez d'autres ASP dans l'AS ;
*	Réception d'indications provenant de la couche SCTP ;
*	Intervention de la gestion locale. 

Le diagramme de transition d'état d'ASP est donné à la Figure 6. Les états possibles d'un ASP sont :

ASP-MORT : le processus de serveur d'application est indisponible et/ou l'association SCTP qui s'y rapporte est morte. Initialement, tous les ASP seront dans cet état. On NE DEVRAIT PAS envoyer de message IUA à un ASP dans cet état.

ASP-INACTIF : l'homologue IUA distant à l'ASP est disponible (et l'association SCTP qui s'y rapporte est vivante) mais le trafic d'application est arrêté. Dans cet état, on peut envoyer à l'ASP des messages IUA non QPTM (sauf les messages État de TEI).

ASP-ACTIF : l'homologue IUA distant à l'ASP est disponible et le trafic d'application est actif.

                                    +--------------+
             +----------------------|              |
             |   Prise de   +-------|  ASP-ACTIF   |
             |   contrôle   |       +--------------+
             |   d'un autre |           ^     |
             |   ASP        |    ASP    |     | ASP inactif /
             |              |    actif  |     | ASP vif
             |              |           |     v
             |              |       +--------------+
             |              |       |              |
             |              +------>| ASP-INACTIF  |
             |                      +--------------+
             |                          ^    |
   ASP mort/ |                     ASP  |    | ASP mort /
   SCTP CDI/ |                     vif  |    | SCTP CDI /
   SCTP RI   |                          |    v SCTP RI
             |                      +--------------+
             +--------------------->|              |
                                    |   ASP-MORT   |
                                    +--------------+

Figure 6. Diagramme de transition d'état d'ASP

SCTP CDI : L'indication Communication morte à la couche SCTP locale à la couche de protocole supérieure (IUA) sur une SG. Le SCTP local va envoyer cette indication quand il détecte la perte de connexité à la couche SCTP homologue de l'ASP. SCTP CDI est compris comme une notification de fermeture complète et comme une notification de communication perdue provenant de SCTP.

SCTP RI : L'indication de redémarrage de la couche SCTP locale à la couche supérieure de protocole (IUA) sur une SG. Le SCTP local va envoyer cette indication quand il détecte un redémarrage sur la couche SCTP homologue de l'ASP.

 	4.3.1.2	États d'AS
L'état de l'AS est conservé dans la couche IUA sur la SG. l'état d'un AS change à cause d'événements. Ces événements incluent :
*	les transitions d'état d'ASP,
*	les déclenchements de temporisateur de récupération.

Un AS peut être dans l'un des états suivants :

AS-MORT : le serveur d'application est indisponible. Cet état implique que tous les ASP en rapport sont dans l'état ASP-MORT pour cet AS. Initialement, l'AS sera dans cet état.

AS-INACTIF : le serveur d'application est disponible mais aucun trafic d'application n'est actif (c'est-à-dire, que un ou plusieurs ASP en rapport sont dans l'état ASP-INACTIF, mais aucun n'est dans l'état ASP-ACTIF). Le temporisateur de récupération T(r) ne court pas ou est arrivé à expiration.

AS-ACTIF : le serveur d'application est disponible et le trafic d'application est actif. Cet état implique qu'au moins un ASP est dans l'état ASP-ACTIF.

AS-EN-INSTANCE : un ASP actif est passé de l'état actif à inactif ou mort et il était le dernier ASP restant dans l'AS. Un temporisateur de récupération T(r) va être lancé et tous les messages SCN entrants seront mis en file d'attente par la SG. Si un ASP devient actif avant l'arrivée à expiration de T(r), l'AS va passer à l'état AS-ACTIF et tous les messages de la file d'attente vont être envoyés à l'ASP actif.

Si T(r) arrive à expiration avant qu’un ASP devienne actif, la SG arrête de mettre les messages en file d'attente et élimine tous les messages antérieurement mis en file d'attente. L'AS va passer à l'état AS-INACTIF si au moins un ASP est dans l'état ASP-INACTIF ; autrement, il va passer à l'état AS-MORT.

      +----------+   un ASP passe à ASP-ACTIF  +-------------+
      |    AS-   |---------------------------->|     AS-     |
      | INACTIF  |                             |   ACTIF     |
      |          |<---                         |             |
      +----------+    \                        +-------------+
         ^   |         \ expiration de Tr,         ^    |
         |   |          \ au moins un ASP          |    |
         |   |           \ en ASP-INACTIF          |    |
         |   |            \                        |    |
         |   |             \                       |    |
         |   |              \                      |    |
 un ASP  |   | tous les ASP  \            un ASP   |    | Le dernier
 passe   |   | passent à      \           passe à  |    | ASP actif passe à
 à ASP-  |   | ASP-MORT        -------\   ASP-     |    | ASP-INACTIF
 INACTIF |   |                         \  ACTIF    |    | ou ASP-MORT
        E|   |                          \          |    | (lancement de Tr)
         |   |                           \         |    |
         |   |                            \        |    |
         |   v                             \       |    v
      +----------+                          \  +-------------+
      |          |                           --|             |
      | AS-MORT  |                             | AS-EN-INST. |
      |          |                             |(mise en file|
      |          |<----------------------------|  d'attente) |
      +----------+   Expiration de Tr et aucun +-------------+
                    ASP dans l'état ASP-INACTIF

Tr = Temporisateur de récupération

Figure 7 : Diagramme de transition d'état d'AS

 	4.3.2	Procédures ASPM pour les primitives
Avant l'établissement d'une association SCTP, l'état d'ASP à la SG et l'ASP est supposé être ASP-MORT.

Comme l'ASP est chargé d'initier l'établissement d'une association SCTP avec une SG, la couche IUA à un ASP reçoit une primitive de demande M-SCTP ESTABLISH provenant de la gestion de couches, et va essayer d'établir une association SCTP avec l'homologue IUA distant à une SG. À réception d'une primitive de confirmation finale SCTP-Communication vive du SCTP, la couche IUA va invoquer la primitive confirmation de M-SCTP ESTABLISH à la gestion de couches.

À la SG, la couche IUA va recevoir une primitive d'indication SCTP Communication vive du SCTP. La couche IUA va alors invoquer la primitive d'indication M-SCTP ESTABLISH à la gestion de couches.

Une fois l'association SCTP établie et en supposant que l'utilisateur IUA local est prêt, la fonction locale de maintenance de processus de serveur d'application (ASPM, Application Server Process Maintenance) va initier les procédures d'ASPM, en utilisant les messages ASP vif/-mort/-actif/-inactif pour convoyer l'état d'ASP à la SG (paragraphe 4.3.3).

La gestion de couches et la couche IUA sur la SG peuvent communiquer l'état du serveur d'application en utilisant les primitives M-AS_STATUS. La gestion de couches et la couche IUA sur la SG et l'ASP peuvent communiquer l'état d'une association SCTP en utilisant les primitives M-SCTP_STATUS.

Si la gestion de couches sur la SG ou l'ASP veut terminer une association SCTP pour des raisons de gestion, elle va envoyer une primitive de demande M-SCTP RELEASE à la couche IUA locale. La couche IUA va libérer l'association SCTP et à réception de l'indication SCTP-COMMUNICATION_DOWN provenant de la couche SCTP sous-jacente, elle va informer la gestion de couches locale en utilisant la primitive de confirmation M-SCTP_RELEASE.

Si la couche IUA reçoit une indication SCTP-COMMUNICATION_DOWN provenant de la couche SCTP sous-jacente, elle va en informer la gestion de couches en invoquant la primitive d'indication M-SCTP RELEASE. L’état de l'ASP va passer à "mort" sur la SG et l'ASP.

À un ASP, la gestion de couches PEUT essayer de rétablir l'association SCTP en utilisant la primitive de demande M-SCTP_ESTABLISH.

Dans le cas d'une indication SCTP-RESTART à un ASP, l'ASP est maintenant considéré par son homologue IUA comme étant dans l'état ASP-MORT. L'ASP, si il récupère, doit commencer toute récupération par la procédure ASP vif.

 	4.3.3	Procédures d'ASPM pour messages d'homologue à homologue
Tous les messages ASPM sont envoyés sur un flux séquentiel pour assurer leur bon ordre. Le flux SCTP '0' DEVRAIT être utilisé.

 	4.3.3.1	Procédures de ASP Up
Après qu'un ASP a réussi à établir une association SCTP avec une SG, la SG attend que l'ASP envoie un message ASP vif, indiquant que l'ASP IUA homologue est disponible. L'ASP est toujours l'initiateur du message ASP vif.  Cette action PEUT être initiée chez l'ASP par une primitive de demande M-ASP_UP provenant de la gestion de couches ou PEUT être initiée automatiquement par une fonction de gestion IUA.

Quand un message ASP vif est reçu par une SG et qu'en interne l'ASP distant est dans l'état ASP-DOWN et n'est pas considéré comme interdit pour des raisons de gestion locale, la SG marque l'ASP distant dans l'état ASP-INACTIF et informe la gestion de couches avec une primitive d'indication M-ASP_Up. Si la SG sait, via les données de configuration courantes, avec quels serveurs d'application l'ASP est configuré pour fonctionner, la SG met à jour l'état d'ASP à ASP-INACTIF dans chaque AS dont elle est membre.

Autrement, la SG peut passer l'ASP dans un réservoir d'ASP inactifs disponibles pour une future configuration au sein du ou des serveurs d'application, déterminée dans une procédure ASP actif ultérieure. Si le message ASP vif contient un identifiant d'ASP, la SG devrait le sauvegarder pour cet ASP. La SG DOIT envoyer un message Accusé de réception d'ASP vif en réponse au message ASP vif reçu même si l'ASP est déjà marqué comme ASP-INACTIF à la SG.

Si pour une raison locale (par exemple, verrouillage de gestion) la SG ne peut pas répondre par un message Accusé de réception d'ASP vif, la SG répond à un message ASP vif par un message d'erreur avec la raison "Refusé - blocage de gestion".

À l'ASP, le message Accusé de réception d'ASP vif reçu n'est pas acquitté. La gestion de couches est informée par une primitive de confirmation M-ASP_UP.

Quand l'ASP envoie un message ASP vif, il lance le temporisateur T(ack). Si l'ASP ne reçoit pas une réponse à un message ASP vif dans le temps T(ack), l'ASP PEUT recommencer T(ack) et renvoyer des messages ASP vif jusqu'à ce qu'il reçoive un message Accusé de réception d'ASP vif. T(ack) est provisionnable, avec une valeur par défaut de 2 secondes. Autrement, la retransmission des messages ASP vif PEUT être mise sous le contrôle de la gestion de couches. Dans cette méthode, l'expiration de T(ack) résulte en une primitive de confirmation M-ASP_UP portant une indication négative.

L'ASP doit attendre le message Accusé de réception d'ASP vif avant d'envoyer tout autre message IUA (par exemple, ASP actif). Si la SG reçoit d'autres messages IUA avant qu'un message ASP vif soit reçu (autre que ASP mort; voir le paragraphe 4.3.3.2) la SG PEUT les éliminer.

Si un message ASP vif est reçu et qu'en interne, l'ASP distant est dans l'état ASP-ACTIF, un message Accusé de réception d'ASP vif est retourné, ainsi qu'un message d'erreur ("Message inattendu") et l'état d'ASP distant est changé en ASP-INACTIF dans tous les serveurs d'application pertinents.

Si un message ASP vif est reçu et si en interne l'ASP distant est déjà dans l'état ASP-INACTIF, un message Accusé de réception d'ASP vif est retourné et aucune autre action n'est entreprise.

 	4.3.3.2	Procédures de ASP mort
L'ASP va envoyer un message ASP mort à une SG quand l'ASP souhaite être retiré de la liste des ASP dans tous les serveurs d'application dont il est membre et ne plus recevoir de messages IUA QPTM ou ASPTM. Cette action PEUT être initiée à l'ASP par une primitive de demande M-ASP_DOWN provenant de la gestion de couches ou PEUT être initiée automatiquement par une fonction de gestion IUA.

Le retrait permanent d'un ASP d'un AS est une fonction de gestion de configuration.

La SG marque l'ASP comme ASP-MORT, informe la gestion de couches avec une primitive d'indication M-ASP_Down, et retourne un message Accusé de réception d'ASP mort à l'ASP.

La SG DOIT envoyer un message Accusé de réception d'ASP mort en réponse à un message ASP mort reçu de l'ASP même si l'ASP est déjà marqué comme ASP-MORT à la SG.

À l'ASP, le message Accusé de réception d'ASP mort reçu n'est pas acquitté. La gestion de couches est informée avec une primitive de confirmation M-ASP_DOWN. Si l'ASP reçoit un accusé de réception d'ASP mort sans avoir envoyé de message ASP mort, il devrait alors se considérer lui-même comme étant dans l'état ASP-MORT. Si l'ASP était précédemment dans l'état ASP-ACTIF ou ASP-INACTIF, il devrait alors initier les procédures pour retourner à son état antérieur.

Quand l'ASP envoie un message ASP mort, il lance le temporisateur T(ack). Si l'ASP ne reçoit pas de réponse à un message ASP mort dans le délai de T(ack), il PEUT relancer T(ack) et envoyer à nouveau des messages ASP mort jusqu'à ce qu'il reçoive un message Accusé de réception d'ASP mort. T(ack) est provisionnable, avec une valeur par défaut de 2  secondes. Autrement, la retransmission des messages ASP mort PEUT être mise sous le contrôle de la gestion de couches. Dans cette méthode, l'arrivée à expiration de T(ack) résulte en une primitive de confirmation M-ASP_DOWN portant une indication négative.

 	4.3.3.3	Contrôle de version IUA
Si un message ASP vif est reçu avec une version non prise en charge, l'extrémité qui reçoit répond par un message d'erreur, indiquant la version que le nœud receveur prend en charge et le notifie à la gestion de couches.

Ceci est utile quand des mises à niveau de version de protocole sont effectuées dans un réseau. Un nœud mis à niveau avec une version plus récente DEVRAIT prendre en charge les versions plus anciennes utilisées sur les autres nœuds avec lesquels il communique. Parce que les ASP initient la procédure ASP vif, on suppose que le message d'erreur va normalement venir de la SG.

 	4.3.3.4	Procédures de ASP actif
Après que l'ASP a reçu un accusé de réception d'ASP vif de la SG, l'ASP envoie un message ASP actif à la SG pour indiquer que l'ASP est prêt à commencer à traiter le trafic. Cette action PEUT être initiée à l'ASP par une primitive de demande M-ASP_ACTIVE provenant de la gestion de couches ou PEUT être initiée automatiquement par une fonction de gestion IUA. Dans le cas où un ASP est configuré/enregistré à traiter le trafic pour plus d'un serveur d'application à travers une association SCTP, le ASPAC contient un ou plusieurs identifiants d'interface pour indiquer à quels serveurs d'application l'ASPAC s'applique.

Si le serveur d'application peut être activé, la SG répond à l'ASP par un message d'accusé de réception d'ASPAC qui reconnaît que le message ASPAC a été reçu et commence à envoyer du trafic pour le serveur d'application à cet ASP.

Dans le cas où un message ASP actif "sorti de nulle part" est reçu (c'est-à-dire, l'ASP n'est pas enregistré auprès de la SG ou la SG n'a pas de données de configuration statique pour l'ASP) le message PEUT être éliminé en silence.

La SG DOIT envoyer un message Accusé de réception d'ASP actif en réponse à un message ASP actif reçu de l'ASP, si l'ASP est déjà marqué dans l'état ASP-ACTIF à la SG.

À l'ASP, le message Accusé de réception d'ASP actif reçu n'est pas acquitté. La gestion de couches est informée avec une primitive de confirmation M-ASP_ACTIF. Il est possible que l'ASP reçoive des messages de données avant que le message Accusé de réception d'ASP actif, comme les messages Accusé de réception d'ASP actif et Données provenant d'une SG, puissent être envoyés sur des flux SCTP différents. La perte de message est possible car l'ASP ne se considère pas lui-même comme dans l'état ASP-ACTIF jusqu'à la réception du message Accusé de réception d'ASP actif.

Quand l'ASP envoie un message ASP actif, il lance le temporisateur T(ack). Si l'ASP ne reçoit pas une réponse à un message ASP actif dans le délai de T(ack), il PEUT relancer T(ack) et envoyer de nouveaux messages ASP actif jusqu'à ce qu'il reçoive un message Accusé de réception d'ASP actif. T(ack) est provisionnable, avec une valeur par défaut de 2  secondes. Autrement, la retransmission des messages ASP actif PEUT être mise sous le contrôle de la gestion de couches. Dans cette méthode, l'arrivée à expiration de T(ack) résulte en une primitive de confirmation M-ASP_ACTIVE portant une indication négative.

L'ASP DOIT attendre le message Accusé de réception d'ASP actif provenant de la SG avant d'envoyer des messages Données ou il encourt des pertes de message. Si la SG reçoit des messages QPTM avant qu'un ASP actif soit reçu, la SG DEVRAIT les éliminer.

Il y a deux modes de traitement du trafic de serveur d'application dans la SG IUA : outrepassement et partage de charge. Le paramètre Type dans le message ASPAC indique le mode utilisé dans un certain serveur d'application. Si la SG détermine que le mode indiqué dans un ASPAC est incompatible avec le mode de traitement de trafic actuellement utilisé dans l'AS, la SG répond par un message d'erreur qui indique "Mode de traitement de trafic non pris en charge".

Dans le cas d'un AS en mode outrepassement, la réception d'un message ASPAC par une SG cause la redirection de tout le trafic pour l'AS sur l'ASP qui a envoyé l'ASPAC. La SG répond à l'ASPAC par un message Accusé de réception d'ASP actif à l'ASP. Tout ASP antérieurement actif dans l'AS est maintenant considéré comme inactif et ne va plus recevoir de trafic de la part de la SG au sein de l'AS. La SG envoie une notification (Autre ASP actif) à l'ASP précédemment actif dans l'AS, après l'arrêt de tout le trafic à cet ASP.

Dans le cas d'un AS en mode partage de charge, la réception d'un message ASPAC à une SG cause la direction du trafic sur l'ASP qui envoie l'ASPAC, en plus de tous les autres ASP qui sont actuellement actifs dans l'AS. L'algorithme à la SG pour le partage de la charge du trafic au sein d'un AS entre tous les ASP actifs dépend de la mise en œuvre. L'algorithme pourrait, par exemple, être un "round-robin" ou être fondé sur les informations du message Données, comme l'identifiant d'interface, selon les exigences de l'application et les hypothèses de traitement de l'état d'appel de la collection des ASP dans l'AS. La SG répond à l'ASPAC par un message Accusé de réception d'ASP actif à l'ASP.

 	4.3.3.5	Procédures de ASP inactif
Quand un ASP souhaite se retirer de la réception du trafic au sein d'un AS, il envoie un message ASP inactif à la SG. Cette action PEUT être initiée à l'ASP par une primitive de demande M-ASP_INACTIF provenant de la gestion de couches ou PEUT être initiée automatiquement par une fonction de gestion IUA. Dans le cas où un ASP est configuré/enregistré à traiter le trafic pour plus d'un serveur d'application à travers une association SCTP, le ASPIA contient un ou plusieurs identifiants d'interface pour indiquer pour quels serveurs d'application s'applique le message ASP inactif.

Il y a deux modes de traitement du trafic de serveur d'application dans la SG IUA quand on retire un ASP du service : l'outrepassement et le partage de charge. Dans le cas d'un AS en mode outrepassement, où normalement un autre ASP a déjà accaparé le trafic au sein de l'AS avec un message ASPAC d'outrepassement, l'ASP qui envoie le message ASPIA est déjà considéré par la SG comme étant un ASP inactif. Un message d'accusé de réception d'ASPIA est envoyé à l'ASP, après s'être assuré que tout le trafic est arrêté à l'ASP.

Dans le cas d'AS en mode partage de charge, la SG passe l'ASP à l'état ASP-INACTIF et le trafic de l'AS est réalloué entre les ASP actifs restants selon l'algorithme de partage de charge actuellement utilisé au sein de l'AS. Un message Accusé de réception ASPIA est envoyé à l'ASP après que tout le trafic a été arrêté pour l'ASP. Un message de notification (ASP insuffisants) PEUT être envoyé à tous les ASP inactifs, si nécessaire.

Quand l'ASP envoie un message ASP inactif, il lance le temporisateur T(ack). Si l'ASP ne reçoit pas une réponse à un message ASP inactif dans le délai de T(ack), il PEUT relancer T(ack) et renvoyer des messages ASP inactif jusqu'à ce qu'il reçoive un message d'accusé de réception d'ASP inactif. T(ack) est provisionnable, avec une valeur par défaut de 2  secondes. Autrement, la retransmission des messages ASP inactif PEUT être mise sous le contrôle de la gestion de couches. Dans cette méthode, l'arrivée à expiration de T(ack) résulte en une primitive de confirmation M-ASP_Inactif qui porte une indication négative.

Si aucun autre ASP dans le serveur d'application n'est dans l'état ASP-ACTIF, la SG DOIT envoyer un message Notifier ("AS en instance") à tous les ASP de l'AS qui sont dans l'état ASP-INACTIF. La SG DEVRAIT commencer à mettre en mémoire tampon les messages entrants pour T(r) secondes, après quoi les messages PEUVENT être éliminés. T(r) est configurable par l'opérateur du réseau. Si la SG reçoit un message ASP actif provenant d'un ASP de l'AS avant l'expiration de T(r), le trafic mis en mémoire tampon est dirigé sur cet ASP et le temporisateur est annulé. Si T(r) arrive à expiration, l'AS est passé à l'état AS-INACTIF.

À l'ASP, le message Accusé de réception d'ASP inactif reçu n'est pas acquitté. La gestion de couches est informée par une primitive de confirmation M-ASP_INACTIF. Si l'ASP reçoit un accusé de réception d'ASP inactif sans avoir envoyé de message ASP inactif, il devrait maintenant se considérer lui-même comme dans l'état ASP-INACTIF. Si l'ASP était précédemment dans l'état ASP-ACTIF, il devrait alors initier les procédures pour retourner à son état précédent.

 	4.3.3.6	Procédures de Notify
Un message Notify reflétant un changement de l'état de l'AS DOIT être envoyé à tous les ASP dans l'AS, excepté ceux qui sont dans l'état ASP-MORT, avec les informations d'état appropriées et tout identifiant d'ASP de l'ASP défaillant. À l'ASP, la gestion de couches est informée avec une primitive d'indication M-NOTIFY. Le message Notify doit être envoyé que le changement d'état de l'AS soit le résultat d'une défaillance de l'ASP ou de la réception d'un message de gestion d'état d'ASP (ASPSM) / gestion de trafic d'ASP (ASPTM). Dans ce dernier cas, le message Notify DOIT être envoyé après tout message d'accusé de réception en rapport (par exemple, accusé de réception d'ASP vif, accusé de réception d'ASP mort, accusé de réception d'ASP actif, ou accusé de réception d'ASP inactif).

Dans le cas où un message Notify ("AS en instance") est envoyé par une SG qui n'a actuellement pas d'ASP actif dont servir le trafic, ou qu'un message NTFY ("Pas assez d'ASP") est envoyé dans le mode partage de charge, le Notify n'oblige pas explicitement les ASP qui reçoivent ce message à devenir actifs. Les ASP restent au contrôle des actions qui sont engagées, et de quand elles le sont.

 	4.3.3.7	Battement de cœur (Heartbeat)
Les procédures facultatives de battement de cœur PEUVENT être utilisées lors du fonctionnement sur des couches de transport qui n'ont pas leur propre mécanisme de battement de cœur pour détecter la perte de l'association de transport (c'est-à-dire, autre que le SCTP).

L'un ou l'autre des homologues IUA peut facultativement envoyer des messages périodiques de battement de cœur, à condition d'avoir un temporisateur T(beat) réglable. À réception d'un message Battement de cœur, l'homologue IUA DOIT répondre par un message Accusé de réception de battement de cœur. Si aucun message Accusé de réception de battement de cœur (ou tout autre message IUA) n'est reçu de l'homologue IUA dans les 2*T(beat), l'homologue IUA distant est considéré comme indisponible. La transmission des messages Battement de cœur est arrêtée et le processus de signalisation DEVRAIT tenter de rétablir la communication si il est configuré comme client pour l'homologue IUA déconnecté.

Le message BEAT PEUT facultativement contenir un paramètre opaque Données de battement de cœur qui DOIT être renvoyé en écho inchangé dans le message Accusé de réception de battement de cœur qui s'y rapporte. L'ASP, en examinant le contenu du message Accusé de réception de battement de cœur retourné PEUT choisir de considérer l'ASP distant comme indisponible. Le contenu/format du paramètre Données de battement de cœur dépend de la mise en œuvre et n'est d'intérêt que local pour l'envoyeur original. Le contenu PEUT être utilisé, par exemple, pour la prise en charge d'un algorithme de séquence de battement de cœur (pour détecter les manquants) et/ou un mécanisme d'horodatage (pour évaluer le délai).

Note : Les événements relatifs au battement de cœur ne sont pas montrés à la Figure 6, "Diagramme de transition d'état d'ASP".

 	5.	Exemples
 	5.1	Établissement d'association et de trafic entre les SG et les ASP
 	5.1.1	Un seul ASP dans un serveur d'application (1+0 frugal)
Ce scénario donne l'exemple d'un flux de messages IUA pour l'établissement de trafic entre une SG et un ASP, où un seul ASP est configuré au sein d'un AS (pas de sauvegarde). On suppose que l'association SCTP est déjà établie.

SG                       ASP1
|<---------ASP vif---------|
|----Acc. d'ASP vif------->|
|-----NTFY(AS-INACTIF)---->|
|<-------ASP Actif---------|
|------ACC. ASP Actif----->|
|------NTFY(AS-ACTIF)----->|

Ce scénario donne l'exemple d'un flux de messages IUA pour l'établissement de trafic entre une SG et deux ASP dans le même serveur d'application, où ASP1 est configuré pour être actif et ASP2 en attente d'un événement de défaillance de communication ou de retrait de service de ASP1. ASP2 PEUT agir comme attente chaude, tiède, ou froide selon la mesure dont ASP1 et ASP2 partagent l'état d'appel ou peuvent communiquer l'état d'appel en cas d'événement de défaillance/retrait. L'exemple de flux de messages est le même, que les messages d'ASP actif soient en mode outrepassement ou partage de charge bien que normalement, cet exemple utiliserait le mode outrepassement.

SG                        ASP1                        ASP2
 |<--------ASP vif---------|                          |
 |----Acc. d'ASP vif------>|                          |
 |----NTFY(AS-INACTIF)---->|                          |
 |<-----------------------------ASP vif---------------|
 |---------Accusé de réception d'ASP vif------------->|
 |<-------ASP actif--------|                          |
 |-----ACC. ASP actif----->|                          |
 |-----NTFY(AS-ACTIF)----->|                          |
 |----------------------NTFY(AS-ACTIF)--------------->|

 	5.1.3	Deux ASP dans un serveur d'application (1+1 frugal, cas de partage de charge)
Ce scénario montre un cas similaire à celui du paragraphe 5.1.2 mais les deux ASP sont amenés à l'état actif et partagent la charge du trafic. Dans ce cas, un ASP est suffisant pour traiter la charge totale de trafic.

SG                       ASP1                       ASP2
 |<---------ASP vif--------|                          |
 |----Acc. d'ASP vif------>|                          |
 |----NTFY(AS-INACTIF)---->|                          |
 |<------------------------------ASP vif--------------|
 |----------Accusé de réception d'ASP vif------------>|
 |<--ASP Actif (ptg de ch.)|                          |
 |----ACC. ASP Actif------>|                          |
 |-----NTFY(AS-ACTIF)----->|                          |
 |                         |                          |
 |----------------------NTFY(AS-ACTIF)--------------->|
 |<--------------------------ASP Actif (ptg de ch.)---|
 |-----------------------------Acc. ASP Actif-------->|
 |                         |                          |

 	5.1.4	Trois ASP dans un serveur d'application (n+k frugal, cas de partage de charge)
Ce scénario montre l'exemple d'un flux de messages IUA pour l'établissement de trafic entre une SG et trois ASP dans le même serveur d'application, où deux des ASP sont aménés à l'état actif et partagent la charge. Dans ce cas, un minimum de deux ASP sont requis pour traiter la charge totale de trafic (2+1 frugal).

SG                  ASP1                ASP2                ASP3
 |                    |                   |                   |
 |<------ASP vif------|                   |                   |
 |--Acc. d'ASP vif--->|                   |                   |
 |                    |                   |                   |
 |-NTFY(AS-INACTIF)-->|                   |                   |
 |<--------------------------ASP vif------|                   |
 |---Acc. d'ASP vif-->|                   |                   |
 |                    |                   |                   |
 |<---------------------------------------------ASP vif-------|
 |-------------------------Accusé de réception d'ASP vif----->|
 |                    |                   |                   |
 |<-ASP Act (ptg ch.)-|                   |                   |
 |---Acc. ASP Actif-->|                   |                   |
 |                    |                   |                   |
 |<---------------------ASP Act (ptg ch.)-|                   |
 |----------------------ASP Act Ack------>|                   |
 |                    |                   |                   |
 |--NTFY(AS-ACTIF)--->|                   |                   |
 |---------------NTFY(AS-ACTIF)---------->|                   |
 |------------------------NTFY(AS-ACTIF)--------------------->|

 	5.1.5	Exemple de discordance de configuration d'identifiant d'interface
Ce scénario montre l'exemple d'un flux de messages IUA pour l'établissement de trafic entre une SG et un ASP dans lequel certains des identifiants d'interface ont été mal configurés côté ASP. La SG dans ce cas a les identifiants d'interface 1 à 5 configurés pour ASP1.

SG                               ASP1
 |                                |
 |<-----ASP actif (IID  1-10)-----|
 |---Acc. ASP actif (IID 1-5)---->|
 |-------Erreur (IID 6)---------->|
 |-------Erreur (IID 7)---------->|
 |-------Erreur (IID 8)---------->|
 |-------Erreur (IID 9)---------->|
 |-------Erreur (IID 10)--------->|
 |                                |

 	5.2	Exemples de reprise sur défaillance du trafic d'ASP
 	5.2.1	(1+1 frugal, retrait d'ASP, outrepasement de sauvegarde)
L'exemple suivant montre le cas où un ASP se retire du service :

SG                       ASP1                       ASP2
 |                         |                          |
 |<-----ASP inactif--------|                          |
 |----Acc. ASP inactif---->|                          |
 |                         |                          |
 |--NTFY(AS-en instance)-->|                          |
 |-------------------NTFY(AS-en instance)------------>|
 |                         |                          |
 |<------------------------------ ASP actif-----------|
 |-----------------------------Acc. ASP actif)------->|
 |                         |                          |
 |----NTFY(AS-ACTIF)------>|                          |
 |-------------------NTFY(AS-ACTIF)------------------>|

Dans ce cas, la SG notifie à ASP2 que l'AS est passé à l'état Mort. La SG aurait aussi pu (facultativement) envoyer un message Notifier quand l'AS est passé à l'état En instance.

Note : si la SG détecte la perte de l'homologue IUA (perte de battement de cœur IUA ou détection de défaillance SCTP) l'échange initial de message SG-ASP1 ASP inactif n'aurait pas eu lieu.

 	5.2.2	(1+1 frugal, outrepassement de sauvegarde)
L'exemple suivant montre le casoù ASP2 souhaite outrepasser ASP1 et prendre le contrôle du trafic :

SG                       ASP1                       ASP2
 |                         |                          |
 |<-------------------------------ASP actif-----------|
 |-----------------------------Acc. ASP actif-------->|
 |--NTFY(Autre ASP actif)->|                          |
 |                         |                          |

Dans ce cas, la SG notifie à ASP1 qu'un autre ASP l'a outrepassé.

 	5.2.3	(n+k frugal, partage de charge, retrait d'ASP)
Suivant l'exemple du paragraphe 5.1.4, et ASP1 se retire du service :

SG                  ASP1                 ASP2                 ASP3
 |                    |                   |                   |
 |<----ASP inactif----|                   |                   |
 |---Acc. ASP inact.->|                   |                   |
 |                    |                   |                   |
 |---------------------------------NTFY(ASP en inst.)-------->|
 |                    |                   |                   |
 |<-------------------------------------ASP act. (part chrg.)-|
 |----------------------------------------Acc. ASP actif----->|
 |                    |                   |                   |

Dans ce cas, la SG connait le minimum de resources d'ASP requises (selon la mise en œuvre) par exemple, si la SG sait que n+k = 2+1 pour un AS à charge partagée et n est actuellement égal à 1.

Note : si la SG détecte la perte de l'homologue IUA ASP1 (perte du battement de cœur IUA ou détection d'une défaillance SCTP) le premier échange de message SG-ASP1 ASP inactif ne se produirait pas.

 	5.3	Exemples de primitives de remorquage Q.921/Q.931
Quand la couche IUA sur l'ASP a un message QPTM à envoyer à la SG, elle va faire ce qui suit :
-  Déterminer la SG correcte,
-  Trouver l'association SCTP à la SG choisie,
-  Déterminer le flux correct dans l'association SCTP sur la base du canal D,
-  Remplir le message QPTM, remplir l'en-tête de message IUA, remplir l'en-tête commun,
- Envoyer le message QPTM à l'homologue IUA distant dans la SG, sur l'association SCTP.

Quand la couche IUA sur la SG a un message QPTM à envoyer à l'ASP, elle va faire ce qui suit :
-  Déterminer l'AS pour l'identifiant d'interface,
-  Déterminer l'ASP actif (association SCTP) au sein de l'AS,
-  Déterminer le flux correct dans l'association SCTP sur la base du canal D,
-  Remplir le message QPTM, remplir l'en-tête de message IUA, remplir l'en-tête commun,
-  Envoyer le message QPTM à l'homologue IUA distant dans l'ASP, sur l'association SCTP.

Un exemple de flux de messages pour établir une liaison de données sur un canal de signalisation, passant les PDU et libérant une liaison de données sur un canal de signalisation est montré ci-dessous. Une association active entre MGC et SG est établie (paragraphe 5.1) avant le flux de messages suivant.

            SG                                    ASP
                        <----------- Demande d'établissement
Confirmation d'établissement ------>
                        <----------- Demande de données
Indication de données --------------->
                        <----------- Demande de données
Indication de données --------------->
                        <----------- Demande de données
                        <----------- Demande de données
Indication de données --------------->
                        <----------- Demande de libération (RELEASE_MGMT)
Confirmation de libération  ---------->

Un exemple de flux de messages pour un échec de tentative d'établissement d'une liaison de données sur le canal de signalisation est montré ci-dessous. Dans ce cas, la passerelle a un problème avec sa connexion physique (par exemple, alarme rouge) de sorte qu'elle ne peut pas établir une liaison de données sur le canal de signalisation.

           SG                             ASP
                   <----------- Demande d'établissement (ESTABLISH_START)
      Indication de libération ---------->
      (RELEASE_PHYS)

 	5.4	Exemples de communication de gestion de couche
Un exemple de flux de messages pour une communication entre modules de gestion de couches entre SG et ASP est montré ci-dessous. Une association active entre ASP et SG est établie (paragraphe 5.1) avant le flux de messages suivant.

                  SG                          ASP
                        <----------- Demande de données
Indication d'erreur -------------->
  (INVALID_TEI)
                        <----------- Demande d'état de TEI
Confirmation d'état de TEI ----->
   (non alloué)

 	6.	Considérations sur la sécurité

Les considérations sur la sécurité discutées dans "Considérations sur la sécurité pour les protocoles SIGTRAN", [RFC3788], s'appliquent au présent document.

 	7.	Considérations relatives à l'IANA
 	7.1	Identifiant de protocole de charge utile SCTP
L'IANA a alloué une valeur d'IUA pour l'identifiant de protocole de charge utile dans le lot des données de charge utile SCTP. L'identifiant de protocole de charge utile SCTP a été enregistré : IUA :   "1"

L'identifiant de protocole de charge utile SCTP est inclus dans chaque tronçon de données SCTP, pour indiquer quel protocole porte le SCTP. Cet identifiant de protocole de charge utile n'est pas directement utilisé par SCTP mais PEUT être utilisé par certaines entités réseau pour identifier le type d'informations portées dans un tronçon de données.

L'homologue d'adaptation d'utilisateur PEUT utiliser l'identifiant de protocole de charge utile comme un moyen pour déterminer des informations supplémentaires sur les données qui lui sont présentées par SCTP.

 	7.2	Extensions de protocole IUA 
Ce protocole peut aussi être étendu à travers l'IANA de trois façons :
-- par la définition de classes de message supplémentaires,
-- par la définition de types de message supplémentaires, et
-- par la définition de paramètres de message supplémentaires.

La définition et l'usage de nouvelles classes, types, et paramètres de message font partie intégrante des couches d'adaptation SIGTRAN. Donc, ces extensions sont allouées par l'IANA par une action de consensus de l'IETF, comme défini dans la [RFC2434].

L'extension proposée ne doit en aucune manière affecter de façon contraire le fonctionnement général du protocole.

 	7.2.1	Classes de message définies par l'IETF
La documentation pour une nouvelle classe de message DOIT inclure les informations suivantes :
(a)	un nom long et un nom court pour la classe de message,
(b)	une description détaillé de l'objet de la classe de message.

 	7.2.2	Types de message définis par l'IETF
La documentation du type de message DOIT contenir les informations suivantes :
(a) un nom long et un nom court pour le nouveau type de message,
(b) une description détaillée de la structure du message,
(c) une définition et une description détaillée de l'utilisation prévue de chaque champ du message,
(d) une description détaillée des procédures d'utilisation du nouveau type de message au sein du fonctionnement du protocole,
(e) une description détaillée des conditions d'erreur lors de la réception de ce type de message.

Quand une mise en œuvre reçoit un type de message qu'elle ne prend pas en charge, elle DOIT répondre par un message d'erreur (ERR) avec un code d'erreur de "Type de message non pris en charge" (0x04).

 	7.2.3	Extension de paramètre TLV défini par l'IETF
La documentation du paramètre de message DOIT contenir les informations suivantes :
(a) Nom du type de paramètre,
(b) Description détaillée de la structure du champ de paramètre. Cette structure DOIT se conformer au format général type-longueur-valeur décrit au paragraphe 3.1.5.
(c) Définition détaillée de chaque composant de la valeur du paramètre.
(d) Description détaillée de l'utilisation prévue de ce type de paramètre, et une indication de si et sous quelles circonstances plusieurs instances de ce type de paramètre peuvent se trouver dans le même type de message.

 	8.	Valeurs de temporisateurs

Les valeurs suivantes sont suggérées comme valeur par défaut des temporisateurs :
T(r) temporisateur de récupération : 3-5 secondes
T(ack) temporisateur d'accusé de réception : 2-5 secondes
T(beat) temporisateur de battement de cœur : 30 secondes

 	9.	Remerciements
Les auteurs tiennent à remercier Alex Audu, Maria Sonia Vazquez Arevalillo, Ming-te Chao, Keith Drage, Norm Glaude, Nikhil Jain, Bernard Kuc, Ming Lin, Stephen Lorusso, John Loughney, Barry Nagelberg, Neil Olson, Lyndon Ong, Heinz Prantner, Jose Luis Jimenez Ramirez, Ian Rytina, Michael Tuexen, et Hank Wang de leurs précieux commentaires et suggestions.

 	10.	Références
 	10.1	Références normatives
[ANSI X3.4]	ANSI X3.4-1986. "Coded Character Set -- 7-Bit American Standard Code for Information Interchange",

[Q.920]	Recommandation UIT-T Q.920, "Système n° 1 de signalisation d'abonné numérique (DSS1) - couche Liaison des données d'interface usager-réseau RNIS - Aspects généraux".

[RFC3788]	J. Loughney et autres, "Considérations de sécurité pour les protocoles de transport de signalisation (SIGTRAN)", juin  2004. (P.S.)

 	10.2	Références pour information
[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre 1998. (Rendue obsolète par la RFC5226)

[RFC2719]	L. Ong et autres, "Cadre architectural pour le transport de la signalisation", octobre 1999. (Information)

[RFC2960]	R. Stewart et autres, "Protocole de transmission de commandes de flux", octobre 2000. (Obsolète, voir RFC4960) (P.S.)

[RFC3309]	J. Stone, R. Stewart, D. Otis, "Changement de somme de contrôle du protocole de transmission de commandes de flux (SCTP)". septembre 2002. (Obsolète, voir RFC4960) (P.S.)

 	11.	Changements effectués
Voici la liste des changements majeurs entre le présent document et la RFC 3057.
1.	Ajout du message Interrogation de TEI.
2.	Fourniture d'une explication du format DLCI (dans la Figure 6).
3.	Alignement des procédures d'ASP et d'AS à la Section 4 sur les RFC3331 et RFC3332.
4.	Alignement du format des messages ASPSM et ASPTM avec les RFC3331 et RFC3332. Ces changements incluent de supprimer le champ Raison des messages ASP actif et Accusé de réception d'ASP inactif et le champ Type de mode de trafic des messages ASP inactif et Accusé de réception d'ASP inactif.
5.	Les paragraphes 1.3.3 et 1.3.4 ont été déplacés à l'Appendice A. Un nouveau paragraphe a été ajouté à la place du paragraphe 1.3.3.
6.	Les références ont été partégées en normatives et pour information.
7.	Le nouveau document de sécurité Sigtran est référencé et la Section 6 a été mise à jour en conséquence.

 	Appendice A
 	A.1	Architecture de réseau de signalisation
Une passerelle de signalisation est utilisée pour la prise en charge du transport du trafic de signalisation d'utilisateur Q.921 sur un ou plusieurs ASP répartis (par exemple, des MGC). Il est clair que le protocole IUA n'est pas conçu pour satisfaire des exigences de performances et de fiabilité pour un tel transport par lui-même. Cependant, la conjonction de l'architecture répartie et des réseaux redondants permet un transport suffisamment fiable du trafic de signalisation sur IP. Le protocole IUA est assez souple pour permettre son fonctionnement et sa gestion dans diverses configurations physiques, permettant aux opérateurs de réseau de satisfaire leurs exigences de performances et de fiabilité.

Pour satisfaire les exigences de performances et de fiabilité de la signalisation RNIS pour les réseaux de grande qualité, les opérateurs réseau DEVRAIENT s'assurer qu'il n'y a pas un seul point de défaillance provisionné dans l'architecture de réseau de bout en bout entre un nœud RNIS et un ASP IP.

Selon bien sûr la fiabilité des éléments fonctionnels de SG et d'ASP, ceci peut normalement être satisfait par la fourniture de chemins redondants de réseaux IP à garantie de qualité de service pour les associations SCTP entre points d'extrémité SCTP, et des hôtes redondants, et des SG redondantes. La distribution des ASP au sein des hôtes disponibles est aussi importante. Pour un certain serveur d'application, les ASP qui s'y rapportent DEVRAIENT être répartis au moins sur deux hôtes.

Un exemple d'architecture de réseau logique pertinent pour un fonctionnement de niveau transporteur dans le domaine du réseau IP est montré dans la Figure 8 ci-dessous :

                                                          Hôte1
     ********                                         **************
     *      *_________________________________________*  ********  *
     *      *                                _________*  * ASP1 *  *
     *  SG1 *   Associations SCTP           |         *  ********  *
     *      *_______________________        |         *            *
     ********                       |       |         **************
                                    |       |
     ********                       |       |
     *      *_______________________________|
     *      *                       |
     *  SG2 *    Associations SCTP  |
     *      *____________           |
     *      *            |          |                     Hôte2
     ********            |          |                 **************
                         |          |_________________*  ********  *
                         |____________________________*  * ASP1 *  *
                                                      *  ********  *
                                                      *            *
                                                      **************
                                                              .

Figure 8. Exemple de modèle logique

Pour les réseaux de niveau trnsporteur, la défaillance ou l'isolation d'un ASP particulier NE DEVRAIT PAS causer l'abandon d'appels stables. Cela implique que les ASP ont besoin, dans certains cas, de partager l'état d'appel ou d'être capables de passer l'état d'appel entre eux. Cependant, le partage ou la communication des informations d'état d'appel sort du domaine d'application du présent document.

 	A.2	Redondance de processus de serveur d'application
Pour éviter un seul point de défaillance, il est recommandé qu'un minimum de deux ASP soient sur la liste, résidants dans des hôtes séparés et donc disponibles sur des associations SCTP différentes. Par exemple, dans le réseau de la Figure 8, tous les messages provenant d'un canal D particulier (identifiant d'interface) pourraient être envoyés à l'ASP1 dans l'Hôte1 ou à l'ASP1 dans l'Hôte2. La liste des AS à SG1 pourrait ressembler à ceci :

Identifiant d'interface(s) - serveur d'application n° 1
          ASP1/Hôte1  - État=vif, Actif
          ASP1/Hôte2  - État=vif, Inactif

Dans ce cas de redondance 1+1, l'ASP1 dans l'Hôte1 enverait tout message entrant pour les identifiants d'interface enregistrés. L'ASP1 dans Hôte2 serait normalement amené à l'état actif sur une défaillance, ou perte de connexité, de ASP1/Hôte1. Dans cet exemple, les deux ASP sont vifs, ce qui signifie que l'association SCTP qui s'y rapporte et l'homologue IUA distant sont prêts.

La liste d' AS à SG1 pourrait aussi être établie en mode de partage de charge comme on le montre ci-dessous :

Identifiant d'interface(s) - serveur d'application n° 1
          ASP1/Hôte1 - État=vif, Actif
          ASP1/Hôte2 - État=vif, Actif

Dans ce cas, les deux ASP vont recevoir une portion du trafic.

Dans le procès de reprise sur défaillance, il est recommandé que dans le cas d'ASP qui prennent en charge le traitement d'appels, les appels stables ne soient pas libérés. Il est possible que des appels en transition PUISSENT échouer, bien que des mesures de communication entre les ASP impliqués puissent être utilisées pour atténuer ce problème. Par exemple, les deux ASP PEUVENT partager l'état d'appel via une mémoire partagée, ou PEUVENT utiliser un protocole d'ASP à ASP pour passer les informations d'état d'appel. Le protocole d'ASP à ASP sort du domaine d'application du présent document.

 	Adresse des auteurs

Ken Morneault	Malleswar Kalla	Selvam Rengasami	Greg Sidebottom	
Cisco Systems Inc.	Telcordia Technologies	Tridea Works	Signatus Technologies	
13615 Dulles Tech. Drive	PYA 2J-341	téléphone : +1-732-512-0969	Kanata, Ontario, Canada	
Herndon, VA. 20171	3 Corporate Place	selvam@trideaworks.com 	greg@signatustechnologies.com	
USA	Piscataway, NJ 08854			
				
mél : kmorneau@cisco.com	mél : mkalla@telcordia.com 			

 	Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2006).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.
Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org .

Remerciement 
Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.