Groupe de travail Réseau	K. Morneault, éd., Cisco Systems
Request for Comments : 4666	J. Pastor-Balbas, éd., Ericsson
RFC rendue obsolète : 3332	septembre 2006
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Partie 3 du transfert de message (MTP3) du système de 
signalisation n° 7 (SS7) – Couche d'adaptation 
d'utilisateur (M3UA)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de 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). Tous droits réservés.

Résumé
Le présent mémoire définit un protocole pour prendre en charge le transport de toute signalisation SS7 d'utilisateur MTP3 (par exemple, les messages ISUP et SCCP) sur IP en utilisant les services du protocole de transmission de contrôle de flux.  Aussi, des dispositions sont prises pour les éléments de protocole qui permettent un fonctionnement sans coupure des homologues utilisateurs MTP3 dans les domaines SS7 et IP. Ce protocole va être utilisé entre une passerelle de signalisation (SG, Signalling Gateway) et un contrôleur de passerelle de supports (MGC, Media Gateway Controller) ou une base de données résidente de IP, ou entre deux applications fondées sur IP. On suppose que la SG reçoit la signalisation SS7 sur une interface SS7 standard en utilisant la partie transfert de message (MTP, Message Transfer Part) du SS7 pour fournir le transport. Le présent document rend obsolète la RFC 3332.
Table des matières
1. Introduction	3
1.1 Domaine d'application	3
1.2 Terminologie	4
1.3 Vue d'ensemble de M3UA	5
1.3.1 Architecture du protocole	5
1.3.2 Services fournis par la couche M3UA	6
1.4 Zones fonctionnelles	7
1.4.1 Représentation de codet de signalisation	7
1.4.2 Contextes et clés d'acheminement	8
1.4.3 Inter fonctionnement SS7 et M3UA	10
1.4.4 Modèles de redondance	11
1.4.5 Contrôle de flux	11
1.4.6 Gestion de l'encombrement	11
1.4.7 Transposition de flux SCTP	12
1.4.8 Modèle client/serveur SCTP	12
1.5 Exemple de configuration	12
1.5.1 Exemple 1 : Transport de message ISUP	12
1.5.2 Exemple 2 : Transport SCCP entre des IPSP	13
1.5.3 Exemple 3 : SGP résident à la couche SCCP, avec ASP distant	13
1.6 Définition des frontières de M3UA	14
1.6.1 Définition de la frontière entre M3UA et un utilisateur MTP3	14
1.6.2. Définition de la frontière entre M3UA et SCTP	14
1.6.3 Définition de la frontière entre M3UA et gestion de couche	14
2. Conventions	17
3. Éléments du protocole M3UA	17
3.1 En-tête de message commun	17
3.1.1 Version de protocole M3UA	18
3.1.2 Classes et types de message	18
3.1.3 Réservé : 8 Bits	19
3.1.4 Longueur de message : 32 bits (entier non signé)	19
3.2 Format de paramètre de longueur variable	19
3.3 Messages Transfert	21
3.3.1 Message de données de charge utile (DATA)	21
3.4 Messages de gestion de réseau de signalisation SS7	23
3.4.1 Destination indisponible (DUNA)	23
3.4.2 Destination disponible (DAVA)	24
3.4.3 Examen d'état de destination (DAUD)	25
3.4.4 Encombrement de signalisation (SCON)	25
3.4.5 Sous système Utilisateur de destination indisponible (DUPU)	26
3.4.6 Destination interdite (DRST)	28
3.5 Messages de maintenance d'état d'ASP (ASPSM)	28
3.5.1 ASP Up	28
3.5.2 Accusé de réception de ASP Up (ASP Up Ack)	29
3.5.3 ASP Down	29
3.5.4 Accusé de réception de ASP Down (ASP Down Ack)	30
3.5.5 Battement de cœur (BEAT)	30
3.5.6 Accusé de réception de battement de cœur (BEAT Ack)	30
3.6 Messages de gestion de clé d'acheminement (RKM) (facultatif)	31
3.6.1 Demande d'enregistrement (REG REQ)	31
3.6.2 Réponse d'enregistrement (REG RSP)	33
3.6.3 Demande de désenregistrement (DEREG REQ)	35
3.6.4 Réponse de désenregistrement (DEREG RSP)	35
3.7 Messages de maintenance du trafic d'ASP (ASPTM)	36
3.7.1 ASP Actif	36
3.7.2 Accusé de réception de ASP actif (ASP Active Ack)	37
3.7.3 ASP Inactif	38
3.7.4 Accusé de réception d'ASP inactif (ASP Inactive Ack)	38
3.8 Messages de gestion (MGMT)	39
3.8.1 Erreur	39
3.8.2 Notify	41
4. Procédures	43
4.1 Procédures pour la prise en charge de l'utilisateur M3UA	43
4.1.1 Réception des primitives provenant de l'utilisateur M3UA	43
4.2 Réception des primitives de la gestion de couche	43
4.2.1 Réception des messages de gestion d'homologue M3UA	44
4.3 Gestion d'état d'AS et d'ASP/IPSP	44
4.3.1 États d'ASP/IPSP	45
4.3.2 États d'AS	46
4.3.3 Procédures de gestion M3UA pour les primitives	48
4.3.4 Procédures d'ASPM pour les messages d'homologue à homologue	48
4.4. Procédures de gestion de clé d'acheminement (facultative)	54
4.4.1 Enregistrement	54
4.4.2 Désenregistrement	56
4.4.3 Considérations d'IPSP (REG/DEREG)	56
4.5 Procédures de prise en charge de l'état de disponibilité ou d'encombrement de la destination SS7	56
4.5.1 Au SGP	56
4.5.2 À un ASP	57
4.5.3 Vérification d'ASP	57
4.6. Redémarrage de MTP3	58
4.7 NIF non disponible	58
4.8 Contrôle de version M3UA	59
4.9 Terminaison de M3UA	59
5. Exemples de procédures M3UA	59
5.1 Établissement d'association et de trafic entre les SGP et les ASP	59
5.1.1 Un seul ASP dans un serveur d'application ("1+0" restreint) pas d'enregistrement	59
5.1.1.2 Un seul ASP dans le serveur d'application ("1+0" restreint), enregistrement dynamique	60
5.1.1.4 Un seul ASP dans plusieurs serveurs d'application (chacun avec "1+0" restreint) enregistrement dynamique	61
5.1.2 Deux ASP dans un serveur d'application ("1+1" restreint)	61
5.1.3 Deux ASP dans un serveur d'application ("1+1" restreint, cas de partage de charge)	62
5.1.4. Trois ASP dans un serveur d'application ("n+k" restreint, cas de partage de charge)	62
5.2 Exemple de reprise sur défaillance du trafic d'ASP	63
5.2.1 1+1 restreint, retrait d'ASP, outrepassement de sauvegarde	63
5.2.2  1+1 restreint, outrepassement de sauvegarde	63
5.2.3 n+k restreint, cas de partage de charge, retrait d'ASP	63
5.3 Retrait normal d'un ASP d'un serveur d'application et suppression d'une association	64
5.4 Exemples de vérification	64
5.4.1 État de SG : non encombré/disponible	64
5.4.2 État de SG : encombré (niveau d'encombrement = 2) / disponible	64
5.4.3 État de SG : Inconnu/Disponible	65
5.4.4 État de SG : Indisponible	65
5.5 Exemples de limited'utilisateur M3UA/MTP3	65
5.5.1 À un ASP	65
5.5.2 À une SGP	66
5.6 Exemples de communication IPSP	67
5.6.1 Un seul échange	67
5.6.2 Double échange	68
6. Considérations sur la sécurité	68
7. Considérations relatives à l'IANA	68
7.1 Identifiant de protocole de charge utile SCTP	68
7.2 Numéro d'accès M3UA	69
7.3 Extensions de protocole M3UA	69
7.3.1 Classes de message définies par l'IETF	69
7.3.2 Types de message définis par l'IETF	69
7.3.3 Extension de paramètre définie par l'IETF	69
8. Remerciements	69
9. Contributeurs au document	70
10. Références	70
10.1 Références normatives	70
10.2 Références pour information	70
Appendices	71
A.1 Architecture de réseau de signalisation	71
A.2. Modèles de redondance	73
A.2.1 Redondance de serveur d'application	73
A.2.2 Redondance de passerelle de signalisation	73
Adresse des éditeurs	74
Déclaration complète de droits de reproduction	74
 	1.	Introduction

Le présent mémoire définit un protocole pour la prise en charge du transport de toute signalisation SS7 d’utilisateur MTP3 (par exemple, messages ISUP et SCCP ) sur IP en utilisant les services du protocole de transmission de contrôle de flux (SCTP, Stream Control Transmission Protocol) [RFC2960]. Des dispositions sont aussi prises pour les éléments de protocole qui permettent un fonctionnement transparent des homologues utilisateurs de MTP3 dans les domaines SS7 et IP.  Ce protocole sera utilisé entre une passerelle de signalisation (SG, Signaling Gateway) et un contrôleur de passerelle de supports (MGC, Media Gateway Controller) ou une base de données résidente sur IP [RFC2719], ou entre deux applications fondées sur IP.

 	1.1	Domaine d'application
Il y a un besoin de livraison de protocole de signalisation de réseau à commutation de circuit (SCN, Switched Circuit Network ) d'une passerelle de signalisation (SG, signalling gateway) SS7 à un contrôleur de passerelle de supports (MGC, Media Gateway Controller) ou une base de données résidente sur IP, 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 transfert de tous les messages du sous système SS7 d'utilisateur MTP3 (par exemple, [ISUP], [Q.76x], [ETS300356-1], SCCP [Q.711-715], [T1.112], [ETS300009-1], TUP [Q.720], etc.) ;
*	prendre en charge le fonctionnement transparent des utilisateurs du protocole d'utilisateur MTP3 ;
*	prendre en charge la gestion des associations de transport SCTP et du trafic entre une SG et un ou plusieurs MGC ou bases de données résidentes ;
*	prendre en charge la reprise sur défaillance du processus de base de données de MGC ou résidente sur IP et le partage de charge ;
*	prendre en charge le rapport asynchrone des changements d'état à la gestion.

Dans les termes de transport les plus simples, la SG termine les couches de protocole SS7 MTP2 et MTP3 [Q.700-705], [T1.111], [ETS300008-1] et livre les messages de protocole ISUP, SCCP, et/ou tous autres d'utilisateur MTP3, ainsi que certains événements de gestion de réseau MTP, sur les associations de transport SCTP aux homologues d'utilisateur MTP3 dans les MGC ou les bases de données résidentes sur IP.

 	1.2	Terminologie
Apparition de réseau – c'est une référence locale M3UA partagée par la SG et l'AS (normalement un entier) qui, avec un codet de signalisation, identifie de façon univoque un nœud SS7 en indiquant le réseau SS7 spécifique auquel il appartient. Cela peut être utilisé pour distinguer le trafic de signalisation associé à différents réseaux envoyé entre la SG et l'ASP sur une association SCTP commune. Un exemple de scénario est quand une SG apparaît comme un élément dans plusieurs réseaux SS7 nationaux séparés et que la même valeur de codet de signalisation peut être réutilisée dans les différents réseaux.

Association : une association se réfère à une association SCTP. L'association fournit le transport pour la livraison des unités de données de protocole d'utilisateur MTP3 et des messages d'homologues de couche d'adaptation M3UA.

Clé d'acheminement – elle décrit un ensemble de paramètres SS7 et de valeurs de paramètres qui définissent de façon univoque la gamme de trafic de signalisation à traiter par un serveur d'application particulier. Les paramètres au sein de la clé d'acheminement ne peuvent pas s'étendre à travers plus d'une seule grappe de gestion de point de signalisation.

Contexte d'acheminement – valeur qui identifie de façon univoque une clé d'acheminement. Les valeurs de contexte d'acheminement sont configurées soit en utilisant une interface de gestion de configuration, soit en utilisant les procédures de gestion de clé d'acheminement définies dans ce document.

Ensemble de liaisons : un certain nombre de liaisons de signalisation qui interconnectent directement deux points de signalisation, qui sont utilisés comme un module.

Flux - un flux SCTP ; canal logique unidirectionnel é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 sauf ceux soumis au service de livraison en désordre. S'applique aussi au retour en service d'un processus de serveur d'application précédemment indisponible.

Gestion de couche : fonction nodale qui traite les entrées et sorties entre la couche M3UA et une entité de gestion locale.

Grappe de gestion de point de signalisation (SPMC, Signalling Point Management Cluster) - ensemble complet des serveurs d'application représentés au réseau SS7 sous une seule entité MTP (point de signalisation) dans une apparition de réseau spécifique. Les SPMC sont utilisés pour agréger l'état de disponibilité, d'encombrement, et du sous système utilisateur d'une entité MTP (point de signalisation) qui est distribué dans le domaine IP, pour les besoins de la prise en charge des procédures de gestion MTP3 à l'égard du réseau SS7. Dans certains cas, la SG elle-même peut aussi être un membre de la SPMC. Dans ce cas, l'état de disponibilité/encombrement/sous système utilisateur de la SG devrait aussi être pris en compte quand on considère des actions de prise en charge de gestion MTP3.

Hôte : plate-forme de calcul sur laquelle le processus (SGP, ASP ou IPSP) fonctionne.

MTP : sous système de transfert de messages du protocole SS7.

MTP3 : MTP de niveau 3, couche de réseau de signalisation de SS7.

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

Passerelle de signalisation (SG, Signaling Gateway) - c'est un agent de signalisation qui reçoit/envoie de la signalisation native de SCN à la bordure du réseau IP [RFC2719]. Une SG apparaît au réseau SS7 comme un point de signalisation SS7. Une SG contient un ensemble de un ou plusieurs processus uniques de passerelle de signalisation, dont un ou plusieurs sont normalement actifs dans le traitement du trafic. Lorsque une SG contient plus d'un SGP, la SG est une entité logique, et les SGP contenus sont supposés être coordonnés dans une seule vue de gestion du réseau SS7 et des serveurs d'application pris en charge.

Point d'extrémité de signalisation (SEP, Signaling End Point) - nœud dans le réseau SS7 associé au commutateur local d'origine ou de terminaison ou à un commutateur passerelle.

Point de transfert de signalisation (STP, Signaling Transfer Point) - nœud dans le réseau SS7 qui fournit l'accès réseau et effectue l'acheminement de message, l'examen et le transfert des messages de signalisation.

Processus de serveur d'application (ASP, Application Server Process) : instance de processus d'un serveur d'application. Un processus de serveur d'application sert de processus actif ou de secours d'un serveur d'application (par exemple, une partie du commutateur ou base de données virtuelle répartie). Des exemples d'ASP sont des processus (ou instances de processus) de MGC, de SCP IP, ou de HLR IP. Un ASP contient un point d'extrémité SCTP et peut être configuré à traiter le trafic de signalisation au sein de plus d'un serveur d'application.

Processus de serveur IP (IPSP, IP Server Process) : instance de traitement d'une application fondée sur IP. Un IPSP est essentiellement la même chose qu'un ASP, sauf qu'il utilise M3UA en point à point. Conceptuellement, un IPSP n'utilise pas les services d'un nœud de passerelle de signalisation.

Processus de passerelle de signalisation (SGP, Signalling Gateway Process) - instance de traitement d'une passerelle de signalisation. Il sert de processus actif, de secours, de partage de charge, ou de diffusion d'une passerelle de signalisation.

Processus de signalisation - instance de traitement qui utilise M3UA pour communiquer avec les autres processus de signalisation. Un ASP, un SGP, et un IPSP sont tous des processus de signalisation.

Reprise sur défaillance (Failover) : capacité de réacheminer le trafic de signalisation comme nécessaire pour un processus de serveur d'application de remplacement, ou groupe d'ASP, au sein d'un serveur d'application dans le cas d'une défaillance ou d'indisponibilité d'un processus de serveur d'application couramment utilisé. La reprise sur défaillance s'applique aussi au retour en service d'un processus de serveur d'application précédemment indisponible .

Serveur d'application (AS, Application Server) : entité logique servant une clé d'acheminement spécifique. Un exemple de serveur d'application est un élément de commutation virtuel qui traite tout le traitement d'appel pour une relation de signalisation, identifié par un DPC/OPC SS7. Un autre exemple est un élément de base de données virtuel, traitant toutes les transactions HLR pour une combinaison particulière de SIO/DPC/OPC SS7. L'AS contient un ensemble d'un ou plusieurs processus uniques de serveur d'application, dont un ou plusieurs traitent normalement activement du trafic. Noter qu'il y a une relation biunivoque entre un AS et une clé d'acheminement.

Utilisateur MTP3 : tout protocole qui utilise normalement les services de MTP3 SS7 (par exemple, ISUP, SCCP, TUP, etc.).

 	1.3	Vue d'ensemble de M3UA
 	1.3.1	Architecture du protocole
Le cadre architectural défini pour le transport de la signalisation de SCN sur IP [RFC2719] utilise plusieurs composants, incluant un protocole commun de transport de la signalisation et un module d'adaptation pour prendre en charge les services attendus par un protocole de signalisation de SCN particulier en provenance de sa couche de protocole sous-jacente.

Au sein du cadre architectural, le présent document définit un module d'adaptation d'utilisateur MTP3 convenable pour la prise en charge du transfert de messages de toute couche de protocole qui est identifiée au niveau MTP3 comme un utilisateur MTP. La liste de ces couches de protocole inclut mais ne se limite pas au sous système Utilisateur RNIS (ISUP, ISDN User Part) [Q.76x], [T1.113], [ETS300356-1], sous système contrôle de connexion de signalisation (SCCP, Signalling Connection Control Part) [Q.711-715], [T1.112], [ETS300009-1], et sous système Utilisateur téléphonique  (TUP, Telephone User Part) [Q.720]. Les messages TCAP [Q.771-775], [T1.114], [ETS300287-1] ou RANAP [ETS300287-1] sont transférés de façon transparente par le protocole M3UA comme charge utile SCCP, car ils sont des protocoles d'utilisateur SCCP.

Il est recommandé que M3UA utilise les services du protocole de transmission de contrôle de flux (SCTP, Stream Control Transmission Protocol) [RFC2960] comme protocole commun sous-jacent fiable de transport de la signalisation. C'est pour tirer parti de diverses caractéristiques de SCTP, telles que :
-	La livraison explicite en mode paquet (pas en mode flux).
-	La livraison en séquence des messages d'utilisateur au sein de flux multiples, avec une option pour une livraison dans l'ordre d'arrivée des messages d'utilisateur individuels.
-	Le multiplexage facultatif des messages d'utilisateur dans des datagrammes SCTP.
-	La tolérance aux fautes au niveau réseau par la prise en charge du multi rattachements à une ou aux deux extrémités d'une association.
-	La résistance aux attaques d'inondation et d'usurpation d'identité.
-	La segmentation des données pour se conformer à la taille de MTU de chemin découverte.

Dans certains scénarios, comme ceux de connexions de boucle locale à boucle locale sans exigence de redondance, les fonctions SCTP ci-dessus pourraient ne pas être exigées, et TCP PEUT être utilisé comme protocole de transport commun sous-jacent.

 	1.3.2	Services fournis par la couche M3UA
La couche M3UA chez un ASP ou IPSP fournit l'ensemble équivalent de primitives à sa couche supérieure aux utilisateurs MTP3 que fourni par le niveau 3 de MTP à ses utilisateurs locaux MTP3 à un SEP SS7. De cette façon, la couche ISUP et/ou SCCP à un ASP ou IPSP est ignorante des services MTP3 qui sont offerts à distance à partir d'une couche MTP3 à un SGP, et pas par une couche MTP3 locale. La couche MTP3 à un SGP peut aussi ignorer que ses utilisateurs locaux sont en fait des systèmes d'utilisateurs distants sur M3UA. En effet, le M3UA étend l'accès aux services de couche MTP3 à une application distante fondée sur IP. La couche M3UA ne fournit pas elle-même les services MTP3. Cependant, dans le cas où un ASP est connecté à plus d'une SG, la couche M3UA chez un ASP devrait conserver l'état des destinations SS7 configurées et acheminer les messages en accord avec la disponibilité et l'état d'encombrement des chemins pour ces destinations via chaque SG.

La couche M3UA peut aussi être utilisée pour la signalisation point à point entre deux processus de serveur IP (IPSP, IP Server Process). Dans ce cas, la couche M3UA fournit le même ensemble de primitives et services à sa couche supérieure que MTP3. Cependant dans ce cas, les services MTP3 attendus ne sont pas offerts à distance à partir d'un SGP. Les services MTP3 sont fournis, mais les procédures pour prendre en charge ces services sont un sous ensemble des procédures MTP3, du fait de la nature point à point simplifiée de la relation d'IPSP à IPSP.

 	1.3.2.1	Prise en charge du transport des messages d'utilisateur MTP3
La couche M3UA fournit le transport de primitives MTP-TRANSFER à travers une association SCTP établie entre un SGP et un ASP ou entre IPSP.

Chez un ASP, dans le cas où une destination est accessible via plusieurs SGP, la couche M3UA doit aussi choisir via quel SGP le message va être acheminé ou va prendre en charge l'équilibrage de charge à travers les SGP, minimisant par là le dérangement de séquence.

La couche M3UA n'impose pas la limite de longueur de 272 octets du champ Informations de signalisation (SIF) spécifiée par le protocole SS7 MTP de niveau 2 [Q.700-705], [T1.111], [ETS300008-1]. De plus grands blocs d'information peuvent être accommodés directement par M3UA/SCTP, sans besoin d'une procédure de couche supérieure de segmentation/réassemblage spécifiée dans les versions récentes de SCCP ou ISUP. Cependant, dans le contexte d'une SG, la taille maximum de bloc de 272 octets doit être respectée quand il y a interfonctionnement avec un réseau SS7 qui ne prend pas en charge le transfert de plus grands blocs d'information à la destination finale. Cela évite de potentielles exigences de fragmentation ISUP ou SCCP chez les SGP. Le provisionnement et la configuration du réseau SS7 détermine les restrictions de la taille maximum de bloc. Certaines configurations (par exemple, MTP large bande [Q.2140], [Q.2110], [Q.2210]) peuvent permettre de plus grandes tailles de bloc.

 	1.3.2.2	Fonctions de gestion natives
La couche M3UA fournit la capacité d'indiquer les erreurs associées aux messages M3UA reçus et de les notifier, comme approprié, à la gestion locale et/ou à l'homologue M3UA.

 	1.3.2.3	Inter fonctionnement avec les fonctions de gestion de réseau MTP3
Au SGP, la couche M3UA fournit l'interfonctionnement avec les fonctions de gestion MTP3 pour prendre en charge un fonctionnement transparent des applications de signalisation de SCN dans les domaines SS7 et IP. Cela inclut de :
-	fournir une indication aux utilisateurs MTP3 à un ASP qu'une destination dans le réseau SS7 n'est pas accessible ;
-	fournir une indication aux utilisateurs MTP3 à un ASP qu'une destination dans le réseau SS7 est maintenant accessible ;
-	fournir une indication aux utilisateurs MTP3 à un ASP que les messages pour une destination dans le réseau SS7 subissent un encombrement SS7 ;
-	fournir une indication à la couche M3UA à un ASP que les chemins pour une destination dans le réseau SS7 sont interdits ; et
-	fournir une indication aux utilisateurs MTP3 à un ASP que un homologue utilisateur MTP3 est indisponible.

La couche M3UA à un ASP garde l'état des chemins pour les destinations SS7 distantes et peut initier un examen de la disponibilité et de l'état interdit ou encombré des destinations SS7 distantes. Ces informations sont exigées de la couche M3UA chez le SGP.

La couche M3UA à un ASP peut aussi indiquer à la SG que la couche M3UA elle-même, ou l'ASP, ou l'hôte de ASP, est encombré.

 	1.3.2.4	Prise en charge de la gestion des associations SCTP entre le SGP et les ASP
La couche M3UA au SGP maintient l'état de disponibilité de tous les ASP configurés à distance, pour gérer les associations SCTP et le trafic entre les homologues M3UA. Aussi, l'état actif/inactif et d'encombrement des ASP distants est conservé.

La couche M3UA PEUT recevoir de la gestion locale l'instruction d'établir une association SCTP avec un nœud M3UA homologue. Cela peut être réalisé en utilisant les primitives M-SCTP_ESTABLISH (voir au paragraphe 1.6.3 une description des primitives de gestion) pour demander, indiquer, et confirmer l'établissement d'une association SCTP avec un nœud M3UA homologue. Afin d'éviter des associations SCTP redondantes entre deux homologues M3UA, un côté (client) DEVRAIT être désigné pour établir l'association SCTP, ou les informations de configuration M3UA maintenues pour détecter des associations redondantes (par exemple, via la connaissance des adresses attendues des points d’extrémité SCTP local et distant).

La gestion locale PEUT demander à la couche M3UA l'état des associations SCTP sous-jacentes en utilisant les primitives M-SCTP_STATUS de demande et confirmation. Aussi, le M3UA PEUT informer de façon autonome la gestion locale de la raison de la libération d'une association SCTP, déterminée en local au sein de la couche M3UA ou par une primitive provenant du SCTP.

Aussi, la couche M3UA PEUT informer la gestion locale du changement d'état d'un ASP ou AS. Cela PEUT être réalisé en utilisant les primitives de demande M-ASP_STATUS ou M-AS_STATUS.

 	1.3.2.5	Prise en charge de la gestion des connexions à plusieurs SGP
Comme le montre la Figure 1, un ASP peut être connecté à plusieurs SGP. Dans ce cas, une destination SS7 particulière peut être accessible via plus d'une SGP et/ou SG; c'est-à-dire, via plus d'un chemin. Comme les utilisateurs MTP3 conservent seulement l'état sur la base d'une destination et non d'un chemin, la couche M3UA doit maintenir l'état (disponibilité, restriction, et/ou encombrement du chemin à la destination) des chemins individuels, et déduire l'état global de disponibilité ou d'encombrement de la destination d'après l'état des chemins individuels, et informer les utilisateurs MTP3 de cet état déduit chaque fois qu'il change.

 	1.4	Zones fonctionnelles
 	1.4.1	Représentation de codet de signalisation
Par exemple, au sein d'un réseau SS7, une passerelle de signalisation pourrait être chargée de représenter un ensemble de nœuds du domaine IP dans le réseau SS7 pour les besoins de l'acheminement. La SG elle-même, comme point de signalisation dans le réseau SS7, pourrait aussi être adressable avec un codet SS7 pour les besoins de la gestion de MTP3. Le codet SG pourrait aussi être utilisé pour l'adressage de tout utilisateur local MTP3 à la SG comme une couche locale SCCP.

Une SG peut être logiquement partitionnée pour fonctionner dans plusieurs apparitions de réseau SS7. Dans ce cas, la SG pourrait être adressable avec un codet dans chaque apparition de réseau, et cela représente un ensemble de nœuds dans le domaine IP dans chaque réseau SS7. Des alias de codets [T1.111] peuvent aussi être utilisés au sein d'une SG d'apparition de réseau.

Lorsque une SG contient plus d'un SGP, l'ensemble de chemins MTP3, le SPMC, et les états d'AS/ASP distants de chaque SGP DEVRAIENT être coordonnés à travers tous les SGP. Le réacheminement du trafic entre les SGP PEUT aussi être pris en charge.

Les serveurs d'application peuvent être représentés sous le même codet de la SG, sous leurs propres codets individuels, ou groupés avec d'autres serveurs d'application pour les besoins de la préservation du codet. Un seul codet peut être utilisé pour représenter la SG et tous les serveurs d'application ensemble, si c'est désiré.

Si un ASP ou groupe d'ASP est disponible au réseau SS7 via plus d'une SG, chacune avec son propre codet, le ou les ASP vont normalement être représentés par un codet qui est distinct de tout codet de SG. Cela permet, par exemple, que ces SG soient vues du réseau SS7 comme des "STP", chacune ayant un "chemin" pour le ou les mêmes ASP. En cas de défaillance où le ou les ASP deviennent indisponibles à partir d'une des SG, cette approche permet d'échanger des messages de gestion d'acheminement MTP3 entre la SG et le réseau SS7, permettant un simple réacheminement SS7 par une SG de remplacement sans changer l'adresse du codet de destination du trafic SS7 pour le ou les ASP.

Lorsque un AS particulier peut être joint via plus d'un SGP, les clés d'acheminement correspondantes dans les SGP devraient être identiques. (Note : Il est possible que les données de configuration de clé d'acheminement SGP soient temporairement désynchronisées durant les mises à jour de configuration).

                                 +--------+
                                 |        |
                    +------------+  SG 1  +--------------+
        +-------+   | liaisons   | "STP"  |  réseau IP   |     ----
        |  SEP  +---+    SS7     +--------+              +---/      \
        |   ou  |                    |*                      | ASP   |
        |  STP  +---+            +--------+              +---\      /
        +-------+   |            |        |              |     ----
                    +------------+  SG 2  +--------------+
                                 | "STP"  |
                                 +--------+

Figure 1. Exemple avec SG accouplées

Note : la communication de SG à SG (c'est-à-dire, "liaisons C") est recommandée pour les réseaux de niveau opérateur, en utilisant une liaison MTP3 ou un équivalent, pour permettre le réacheminement entre les SG en cas de défaillance du chemin. Lorsque des SGP sont utilisés, la communication inter SGP pourrait être utilisée. Le protocole inter SGP sort du domaine d'application du présent document.

L'exemple suivant montre une passerelle de signalisation partitionnée en deux apparitions de réseau.

                                     SG
        +-------+              +---------------+
        |  SEP  +--------------| Réseau   |M3UA|              ----
        +-------+  liaisons    | SS7 "A"  |    |            /      \
                    SS7        |__________|    +-----------+  ASP  |
                               |          |    |            \      /
        +-------+              | Réseau   |    |              ----
        |  SEP  +--------------+ SS7 "B"  |    |
        +-------+              +---------------+

Figure 2.  Exemple avec réseaux multiples

 	1.4.2	Contextes et clés d'acheminement
 	1.4.2.1	Vue d'ensemble
La distribution des paramètres SS7 entre le SGP et les serveurs d'application est déterminée par les clés d'acheminement et leurs contextes d'acheminement associés. Une clé d'acheminement est essentiellement un ensemble de paramètres SS7 utilisé pour filtrer les paramètres SS7, tandis que le paramètre Contexte d'acheminement est une valeur de 4 octets (entier) qui est associée à cette clé d'acheminement dans une relation biunivoque. Le contexte d'acheminement peut donc être vu comme un indice dans le tableau de distribution de messages d'un nœud envoyeur contenant les entrées de clé d'acheminement.

Les informations d'adresse/acheminement SS7 possibles qui comportent une entrée de clé d'acheminement incluent, par exemple, le OPC, DPC, et SIO trouvés dans l'étiquette d'acheminement MTP3. Des exemples de clés d'acheminement sont : le DPC seul, la combinaison DPC/OPC, ou la combinaison DPC/OPC/SI. Les informations particulières utilisées pour définir une clé d'acheminement M3UA dépendent de l'application et du réseau, et aucun des exemples ci-dessus n'est obligatoire.

Un processus de serveur d'application peut être configuré à traiter le trafic de signalisation relatif à plus d'un serveur d'application, sur une seule association SCTP. Dans les messages de gestion ASP Actif et ASP Inactif, le trafic de signalisation à commencer ou arrêter est distingué par le paramètre Contexte d'acheminement. À un ASP, le paramètre Contexte d'acheminement identifie de façon univoque la gamme de trafic de signalisation associée à chaque serveur d'application que l'ASP est configuré à recevoir.

 	1.4.2.2	Limitations des clés d'acheminement
Les clés d'acheminement DEVRAIENT être uniques au sens où chaque message de signalisation SS7 reçu DEVRAIT avoir une correspondance complète ou partielle à un seul résultat d'acheminement. Un exemple de correspondance partielle serait une clé d'acheminement par défaut qui sera le résultat si il n'y a pas d'autre clé d'acheminement à laquelle appartient le message. Il n'est pas nécessaire que les valeurs du paramètre soient contiguës dans une clé d'acheminement particulière.

 	1.4.2.3	Gestion des contextes et clés d'acheminement
Il y a deux façons de provisionner une clé d'acheminement à un SGP. Une clé d'acheminement peut être configurée de façon statique en utilisant une interface de gestion dépendant de la mise en œuvre, ou de façon dynamique en utilisant la procédure d'enregistrement de clé d'acheminement M3UA.

Quand on utilise une interface de gestion pour configurer les clés d'acheminement, la fonction de distribution de message au sein du SGP n'est pas limitée à l'ensemble de paramètres défini dans le présent document. D'autres algorithmes de distribution dépendants de la mise en œuvre peuvent être utilisés.

 	1.4.2.4	Distribution de message  au SGP
Pour diriger les messages reçus du réseau SS7 MTP3 sur la destination IP appropriée, le SGP doit effectuer une fonction de distribution de message en utilisant les informations du message d'utilisateur MTP3 reçu.

Pour prendre en charge cette distribution de messages, le SGP pourrait, par exemple, maintenir l'équivalent d'un tableau de traduction d'adresses réseau, transposant les informations de message SS7 entrant à un serveur d'application pour une application et gamme de trafic particulières. Cela pourrait être accompli en comparant les éléments du message SS7 entrant aux clés d'acheminement actuellement définies dans le SGP.

Ces clés d'acheminement pourraient à leur tour se transposer directement à un serveur d'application activé par un ou plusieurs ASP. Ces ASP fournissent des informations d'état dynamiques concernant leur disponibilité, leur capacité de traitement du trafic et l'encombrement au SGP en utilisant divers messages de gestion définis dans le protocole M3UA.

La liste des ASP dans un AS est supposée être dynamique, en prenant en compte la disponibilité, la capacité de traitement du trafic, et l'état d'encombrement des ASP individuels dans la liste, ainsi que les changements de configuration et de possibles mécanismes de reprise sur défaillance.

Normalement, un ou plusieurs ASP sont actifs (c'est-à-dire, traitent actuellement du trafic) dans l'AS, mais dans certains cas de défaillance et de transition, il est possible qu'il n'y ait pas d'ASP actif disponible. Les scénarios de diffusion, de partage de charge, et de sauvegarde sont pris en charge.

Quand il n'y a pas d'entrée de clé d'acheminement correspondante pour un message SS7 entrant, un traitement par défaut PEUT être spécifié. Les solutions possibles sont de fournir un serveur d'application par défaut au SGP qui dirige tout le trafic non alloué sur des (un ensemble de) ASP par défaut, ou d'éliminer le message et en donner notification à la gestion de couche. Le traitement du trafic non alloué dépend de la mise en œuvre.

 	1.4.2.5	Distribution de message à l'ASP
L'ASP doit choisir un SGP pour diriger un message sur le réseau SS7. Ceci se fait en observant le codet de destination (et éventuellement les autres éléments du message sortant, comme la valeur du code de sélection de liaison de signalisation (SLS, Signalling Link Selection)). L'ASP doit aussi tenir compte de si le contexte d'acheminement est actif ou non (voir au paragraphe 4.3.4.3).

Note de mise en œuvre : Lorsque plus d'un chemin (ou SGP) est possible pour l'acheminement au réseau SS7, l'ASP pourrait, par exemple, tenir un tableau dynamique des chemins de SGP disponibles pour les destinations SS7, tenant compte de l'état de disponibilité/restriction/encombrement de la destination SS7 reçu du ou des SGP, de l'état de disponibilité des SGP individuels, des changements de configuration et des mécanismes de reprise sur défaillance. Il n'y a cependant pas de messagerie M3UA pour gérer l'état d'un SGP (par exemple, d'échange de messages SGP-Up/Down/Active/Inactive).

Chaque fois qu'existe une association SCTP à un SGP, le SGP est supposé être prêt à répondre aux messages ASPSM de M3UA (voir la Section 3).

 	1.4.3	Inter fonctionnement SS7 et M3UA
Dans le cas d'interfonctionnement SS7 et M3UA, la couche d'adaptation M3UA est conçue pour fournir une extension des primitives d'utilisateur définies par MTP3.

 	1.4.3.1	Passerelles de signalisation des couches SS7
La SG est chargée de terminer le niveau 3 MTP du protocole SS7, et d'offrir une extension fondée sur IP à ses utilisateurs.

Du point de vue de SS7, on s'attend à ce que la passerelle de signalisation transmette et reçoive les unités de signalisation de message (MSU, Message Signalling Unit) SS7 sur une interface de réseau SS7 standard, en utilisant le sous-système de transfert de message (MTP, Message Transfer Part) SS7 [Q.700-705], [T1.111], [ETS300008-1].

Comme interface réseau SS7 standard, l'utilisation de liaisons de signalisation MTP de niveau 2 n'est pas la seule possibilité. Des liaisons à haut débit fondées sur ATM peuvent aussi être utilisées avec les services de la couche d'adaptation de signalisation ATM (SAAL, Signalling ATM Adaptation Layer) [Q.2140], [Q.2110].

Note : Il est aussi possible que des interfaces fondées sur IP soient présentes, en utilisant les services de la couche d'adaptation d'utilisateur MTP2 (M2UA, MTP2-User Adaptation Layer) [RFC3331] ou M2PA [RFC4165]. 

Elles pourraient être terminées à un point de transfert de signalisation (STP, Signalling Transfer Point) ou à un point d'extrémité de signalisation (SEP, Signalling End Point). En utilisant les services de MTP3, la SG pourrait être capable de communiquer avec les SEP SS7 distants de façon quasi associée, lorsque des STP peuvent être présents dans le chemin SS7  entre le SEP et la SG.

 	1.4.3.2.	Inter fonctionnement SS7 et M3UA au SG
Le SGP fournit un inter fonctionnement fonctionnel des fonctions de transport entre le réseau SS7 et le réseau IP en prenant aussi en charge la couche d'adaptation M3UA. Cela permet le transfert des messages de signalisation d'utilisateur MTP3 de et vers les processus de serveur d'application fondés sur IP lorsque existe la couche de protocole d'utilisateur MTP3 de l'homologue.

Pour la gestion du sous système utilisateur SS7, il est exigé que les protocoles d'utilisateur MTP3 aux ASP reçoivent les indications de disponibilité de point de signalisation SS7, d'encombrement du réseau SS7, et de l'indisponibilité du sous système d'utilisateur distant, comme on l'attendrait dans un nœud SEP SS7. Pour accomplir cela, les primitives d'indication MTP-PAUSE, MTP-RESUME, et MTP-STATUS reçues à l'interface MTP3 de couche supérieure à la SG doivent être propagées à l'interface de couche inférieure d'utilisateur MTP3 distant à l'ASP.

Les messages de gestion MTP3 (comme les TFP ou TFA reçus du réseau SS7) NE DOIVENT PAS être encapsulés comme données de charge utile de message de données et envoyés de la SG à l'ASP ou de l'ASP à la SG. La SG DOIT terminer ces messages et générer des messages M3UA, comme approprié.

 	1.4.3.3	Serveur d'application
Une grappe de serveurs d'application est chargée de fournir la prise en charge globale d'une ou plusieurs couches supérieures SS7. Du point de vue de SS7, une grappe de gestion de point de signalisation (SPMC, Signalling Point Management Cluster) fournit une prise en charge complète du service de couche supérieure pour un certain codet.

Par exemple, une SPMC fournissant des capacités de MGC pourrait fournir une prise en charge complète de ISUP (et de tout autre utilisateur MTP3 situé au codet du SPMC) pour un codet donné.

Dans le cas où un ASP est connecté à plus d'un SGP, la couche M3UA doit conserver l'état des destinations SS7 configurées et acheminer les messages conformément à l'état de disponibilité/encombrement/restriction des chemins pour ces destinations SS7.

 	1.4.3.4	Considérations d'IPSP
Comme les IPSP utilisent M3UA en point à point, il n'y a pas de concept d'acheminement des messages au delà de l'extrémité distante. Donc, l'inter fonctionnement SS7 et M3UA n'est pas nécessaire pour ce modèle.

 	1.4.4	Modèles de redondance
 	1.4.4.1	Redondance de serveur d'application
Tous les messages d'utilisateur MTP3 (par exemple, ISUP, SCCP) qui correspondent à une clé d'acheminement provisionnée à un SGP sont transposés à un serveur d'application.

Le serveur d'application est l'ensemble de tous les ASP associés à une clé d'acheminement spécifique. Chaque ASP dans cet ensemble peut être actif, inactif, ou indisponible. Les ASP actifs traitent le trafic ; les ASP inactifs pourraient être utilisés quand les ASP actifs deviennent indisponibles.

Le modèle de reprise sur défaillance prend en charge un modèle de redondance "n+k", où "n" ASP est le nombre minimum d'ASP redondants exigé pour traiter le trafic et "k" ASP sont disponibles pour prendre le relais d'un ASP défaillant ou indisponible. Le trafic DEVRAIT être envoyé après que "n" ASP sont actifs. "k" ASP PEUVENT être actifs au même moment que "n" ou laissés inactifs jusqu'à ce qu'ils soient nécessaires du fait d'un ASP défaillant ou indisponible.

Une redondance "1+1" actif/secours est un sous ensemble de ce modèle. Un modèle simple "1+0" est aussi pris en charge comme sous ensemble, sans redondance d'ASP.

 	1.4.5	Contrôle de flux
La gestion locale à un ASP peut souhaiter arrêter le trafic à travers une association SCTP pour retirer temporairement l'association du service ou pour effectuer une activité de vérification et de maintenance. La fonction pourrait facultativement être utilisée pour contrôler le début du trafic sur une association SCTP nouvellement disponible.

 	1.4.6	Gestion de l'encombrement
La couche M3UA est informée de l'encombrement local et du réseau IP au moyen d'une fonction qui dépend de la mise en œuvre (par exemple, une indication dépendant de la mise en œuvre provenant du SCTP sur l'encombrement du réseau IP).

À un ASP ou IPSP, la couche M3UA indique l'encombrement du réseau IP aux utilisateurs MTP3 locaux au moyen d'une primitive MTP-STATUS, selon les procédures MTP3 courantes, pour invoquer les réponses appropriées de couche supérieure.

Quand une SG détermine que le transport de paramètres SS7 à une grappe de gestion de point de signalisation (SPMC) rencontre de l'encombrement du réseau IP, la SG PEUT déclencher des messages de gestion SS7 de transfert contrôlé MTP3 aux nœuds SS7 d'origine, selon les procédures d'encombrement de la norme MTP3 pertinente. Le déclenchement des messages de gestion MTP3 de SS7 à partir d'une SG est une fonction qui dépend de la mise en œuvre.

La couche M3UA à un ASP ou IPSP PEUT indiquer un encombrement local à un homologue M3UA avec un message SCON. Quand une SG reçoit un message d'encombrement (SCON) d'un ASP et que la SG détermine qu'un SPMC rencontre maintenant de l'encombrement, elle PEUT déclencher des messages de gestion SS7 de transfert contrôlé MTP3 aux destinations SS7 concernées conformément aux procédures d'encombrement de la norme MTP3 pertinente.

 	1.4.7	Transposition de flux SCTP
La couche M3UA au SGP et à l'ASP prend aussi en charge l'allocation du trafic de signalisation à des flux au sein d'une association SCTP. Le trafic qui exige un séquençage DEVRAIT être alloué au même flux. Pour faire cela, le trafic d'utilisateur MTP3 peut être alloué aux flux individuels sur la base, par exemple, de la valeur de SLS dans l'étiquette d'acheminement MTP3, sous réserve bien sûr du nombre maximum de flux supportés par l'association SCTP sous-jacente.

Les règles suivantes s'appliquent (voir au paragraphe 3.1.2) :
1.	Le message DATA NE DOIT PAS être envoyé sur le flux 0.
2.	Les classes ASPSM, MGMT, RKM DEVRAIENT être envoyées sur le flux 0 (autres que les messages BEAT, BEAT ACK et NTFY).
3.	Les classes SSNM, ASPTM et les messages BEAT, BEAT ACK et NTFY peuvent être envoyés sur tout flux.

 	1.4.8	Modèle client/serveur SCTP
Il est recommandé que le SGP et l'ASP soient capables de prendre en charge les opérations de client et de serveur. Les points d'extrémité homologues pour utiliser M3UA DEVRAIENT être configurés de telle façon que l'un prenne toujours le rôle de client et l'autre le rôle de serveur pour initier des associations SCTP. L'orientation par défaut serait que le SGP prenne le rôle de serveur tandis que l'ASP serait le client. Dans ce cas, les ASP DEVRAIENT initier l'association SCTP avec le SGP.

Dans le cas de communication de IPSP à IPSP, les points d'extrémité homologues pour utiliser M3UA DEVRAIENT être configurés de telle façon que l'un prenne toujours le rôle de client et l'autre le rôle de serveur pour initier des associations SCTP.

L'allocation de numéro d'accès d'utilisateur SCTP et TCP enregistré pour M3UA est 2905.

 	1.5	Exemple de configuration
 	1.5.1	Exemple 1 : Transport de message ISUP
  ********   SS7   *****************   IP   ********
  * SEP  *---------*      SGP      *--------* ASP  *
  ********         *****************        ********
  +------+         +---------------+        +------+
  | ISUP |         |     (NIF)     |        | ISUP |
  +------+         +------+ +------+        +------+
  | MTP3 |         | MTP3 | | M3UA |        | M3UA |
  +------|         +------+-+------+        +------+
  | MTP2 |         | MTP2 | | SCTP |        | SCTP |
  +------+         +------+ +------+        +------+
  |  L1  |         |  L1  | |  IP  |        |  IP  |
  +------+         +------+ +------+        +------+
      |_______________|         |______________|

SEP : point d'extrémité de signalisation SS7
SCTP : protocole de transmission de contrôle de flux
NIF : fonction d'interfonctionnement nodale (Nodal Interworking Function)

Dans cet exemple, le SGP fournit une fonction d'inter fonctionnement nodale dépendante de la mise en œuvre qui permet au MGC d'échanger des paramètres SS7 de signalisation avec le SEP fondé sur SS7. La NIF au sein du SGP sert d'interface au sein du SGP entre MTP3 et M3UA. Cette fonction d'interfonctionnement nodale n'a pas de protocole d'homologue visible avec le MGC ou le SEP. Elle fournit aussi des informations d'état de réseau à un des côtés du réseau ou aux deux.

Pour les besoins de la modélisation interne de SGP, au niveau NIF, les paramètres SS7 de signalisation qui sont destinés au MGC sont reçus comme des primitives d'indication MTP-TRANSFER de l'interface de couche supérieure de niveau 3 de MTP, traduits en primitives de demande MTP-TRANSFER, et envoyés à la fonction de distribution de message résidente sur la M3UA locale pour l'acheminement en cours sur la destination IP finale. Les messages reçus de la fonction locale de traduction et transposition d'adresse réseau M3UA comme primitives d'indication MTP-TRANSFER sont envoyés à l'interface de couche supérieure de niveau 3 MTP comme des primitives de demande MTP-TRANSFER pour l'acheminement MTP de niveau 3 en cours à un SEP SS7. Dans le but de fournir des informations d'état de réseau SS7, la NIF livre aussi des primitives d'indication MTP-PAUSE, MTP-RESUME, et MTP-STATUS reçues de l'interface de couche supérieure MTP de niveau 3 à la fonction de gestion locale résidente de M3UA. De plus, comme option de mise en œuvre et de réseau, les destinations interdites sont communiquées de la gestion de réseau MTP à la fonction de gestion locale résidente de M3UA.

 	1.5.2	Exemple 2 : Transport SCCP entre des IPSP
               ********    IP    ********
               * IPSP *          * IPSP *
               ********          ********
               +------+          +------+
               |Usager|          |Usager|
               | SCCP |          | SCCP |
               +------+          +------+
               | SCCP |          | SCCP |
               +------+          +------+
               | M3UA |          | M3UA |
               +------+          +------+
               | SCTP |          | SCTP |
               +------+          +------+
               |  IP  |          |  IP  |
               +------+          +------+
                   |________________|

Cet exemple montre une architecture où aucune passerelle de signalisation n'est utilisée. Dans cet exemple, les messages SCCP sont échangés directement entre deux IPSP résidents IP avec des instances de protocole d'utilisateur SCCP résidentes, telles que RANAP ou TCAP. L'inter fonctionnement du réseau SS7 n'est pas exigé ; donc, il n'y a pas d'informations d'état de gestion réseau MTP3 à prendre en compte par les protocoles SCCP et d'utilisateur SCCP. Toutes les indications MTP-PAUSE, MTP-RESUME, ou MTP-STATUS provenant de la couche M3UA pour la couche SCCP devraient considérer l'état de l'association SCTP et du réseau IP sous-jacent et toutes les informations d'encombrement reçues du site distant.

 	1.5.3	Exemple 3 : SGP résident à la couche SCCP, avec ASP distant
         ********   SS7   *****************   IP   ********
         * SEP  *---------*               *--------*      *
         *  ou  *         *      SGP      *        * ASP  *
         * STP  *         *               *        *      *
         ********         *****************        ********
         +------+         +---------------+        +------+
         |Usager|         |     SCCP      |        |Usager|
         | SCCP |         +---------------+        | SCCP |
         +------+           |   _____   |          +------+
         | SCCP |           |  |     |  |          | SCCP |
         +------+         +------+-+------+        +------+
         | MTP3 |         | MTP3 | | M3UA |        | M3UA |
         +------|         +------+ +------+        +------+
         | MTP2 |         | MTP2 | | SCTP |        | SCTP |
         +------+         +------+ +------+        +------+
         |  L1  |         |  L1  | |  IP  |        |  IP  |
         +------+         +------+ +------+        +------+
             |_______________|         |______________|

Point de transfert de signalisation STP - SS7

Dans cet exemple, le SGP contient une instance de la couche de protocole SS7 SCCP qui peut, par exemple, effectuer la fonction de traduction de titre mondial (GTT, Global Title Translation) SCCP pour les messages adressés logiquement à la SG SCCP. Si le résultat d'une GTT pour un message SCCP donne une adresse DPC ou DPC/SSN SS7 d'un homologue SCCP situé dans le domaine IP, la primitive de demande MTP-TRANSFER résultante est envoyée à la fonction de traduction et transposition d'adresse réseau résidente M3UA locale pour l'acheminement en cours à la destination IP finale.

Similairement, l'instance SCCP dans un SGP peut effectuer le service GTT de SCCP pour les messages qui lui sont adressés logiquement des homologues SCCP dans le domaine IP. Dans ce cas, les primitives d'indication MTP-TRANSFER sont envoyées de la fonction de traduction et transposition d'adresse réseau résidente M3UA locale au SCCP pour GTT. Si le résultat de GTT donne l'adresse d'un homologue SCCP dans le réseau SS7, alors la primitive de demande MTP-TRANSFER résultante est donnée à MTP3 pour livraison à un nœud résident SS7.

Il est possible que le GTT SCCP ci-dessus au SGP puisse donner l'adresse d'un homologue SCCP dans le domaine IP, et que la primitive de demande MTP-TRANSFER résultante soit renvoyée à la couche M3UA pour livraison à une destination IP.

Pour les besoins internes de modélisation SGP, ceci peut être accompli avec l'utilisation d'une fonction d'inter fonctionnement nodale dépendante de la mise en œuvre au sein du SGP qui se tient effectivement en dessous de SCCP et achemine les messages de demande/indication MTP-TRANSFER de et vers le MTP3 et la couche M3UA, sur la base des informations d'adresse DPC ou DPC/SI du SS7. Cette fonction d'inter fonctionnement nodale n'a pas de protocole homologue visible avec l'ASP ou le SEP.

Noter que les services et interfaces fournis par la couche M3UA sont les mêmes que dans l'exemple 1 et que les fonctions prenant place dans l'entité SCCP sont transparentes à la couche M3UA. Les fonctions de protocole SCCP ne sont pas reproduites dans le protocole M3UA.

 	1.6	Définition des frontières de M3UA
Cette section donne une définition des frontières du protocole M3UA. Elles consistent en un SCTP, une gestion de couches, et l'utilisateur MTP3.

           +----------------+
           |Utilisateur MTP3|
           +----------------+
                 |
                 |
           +-----------+     +-----------------+
           |    M3UA   |-----|Gestion de couche|
           +-----------+     +-----------------+
                 |
                 |
           +-----------+
           |    SCTP   |
           +-----------+

 	1.6.1	Définition de la frontière entre M3UA et un utilisateur MTP3
D'après [Q.700-705] :
Demande MTP-TRANSFER
Indication MTP-TRANSFER
Indication MTP-PAUSE
Indication MTP-RESUME
Indication MTP-STATUS

 	1.6.2.	Définition de la frontière entre M3UA et SCTP
Un exemple des primitives de couche supérieure fournies par SCTP est donné à la Section 10 de la [RFC2960].

 	1.6.3	Définition de la frontière entre M3UA et gestion de couche
Demande M-SCTP_ESTABLISH
Direction : LM -> M3UA
Objet : la gestion de couche (LM, gestion de couche) demande que l'ASP établisse une association SCTP avec son homologue.

Confirmation M-SCTP_ESTABLISH
Direction : M3UA -> LM
Objet : l'ASP confirme à la LM qu'il a établi une association SCTP avec son homologue.

Indication M-SCTP_ESTABLISH
Direction : M3UA -> LM
Objet : M3UA informe la LM qu'un ASP distant a établi une association SCTP.

Demande M-SCTP_RELEASE
Direction : LM -> M3UA
Objet : la LM demande que l'ASP libère une association SCTP avec son homologue.

Confirmation M-SCTP_RELEASE
Direction : M3UA -> LM
Objet : l'ASP confirme à la LM qu'il a libéré l'association SCTP avec son homologue.

Indication M-SCTP_RELEASE
Direction : M3UA -> LM
Objet : M3UA informe la LM qu'un ASP distant a libéré une association SCTP ou que l'association SCTP a échoué.

Indication M-SCTP_RESTART
Direction: M3UA -> LM
Objet : M3UA informe la LM qu'une indication de redémarrage de SCTP a été reçue.

Demande M-SCTP_STATUS
Direction: LM -> M3UA
Objet : la LM demande que M3UA rapporte l'état d'une association SCTP.

Confirmation M-SCTP_STATUS
Direction: M3UA -> LM
Objet : M3UA répond avec l'état d'une association SCTP.

Indication M-SCTP STATUS
Direction: M3UA -> LM
Objet : M3UA rapporte l'état d'une association SCTP.

Demande M-ASP_STATUS
Direction: LM -> M3UA
Objet : la LM demande que M3UA rapporte l'état d'un ASP local ou distant.

Confirmation M-ASP_STATUS
Direction: M3UA -> LM
Objet : M3UA rapporte l'état de l'ASP local ou distant.

Demande M-AS_STATUS
Direction: LM -> M3UA
Objet : la LM demande que MUA rapporte l'état d'un AS.

Confirmation M-AS_STATUS
Direction: M3UA -> LM
Objet : M3UA rapporte l'état d'un AS.

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

Indication M-ERROR
Direction: M3UA -> LM
Objet : M3UA rapporte qu'il a reçu un message d'erreur de son homologue ou qu'une opération locale a échoué.

Demande M-ASP_UP
Direction: LM -> M3UA
Objet : la LM demande que l'ASP démarre son opération et envoie un message ASP Up à son homologue.

Confirmation M-ASP_UP
Direction: M3UA -> LM
Objet : l'ASP rapporte qu'il a reçu un message ASP UP Ack de son homologue.

Indication M-ASP_UP
Direction: M3UA -> LM
Objet : M3UA rapporte qu'il a traité avec succès un message ASP Up entrant de son homologue.

Demande M-ASP_DOWN
Direction: LM -> M3UA
Objet : la LM demande que l'ASP arrête son opération et envoie un message ASP Down à son homologue.

Confirmation M-ASP_DOWN
Direction: M3UA -> LM
Objet : l'ASP rapporte qu'il a reçu un message ASP Down Ack de son homologue.

Indication M-ASP_DOWN
Direction: M3UA -> LM
Objet : M3UA rapporte qu'il a traité avec succès un message ASP Down entrant de son homologue, ou que l'association SCTP a été perdue/réinitialisée.

Demande M-ASP_ACTIVE
Direction: LM -> M3UA
Objet : LM demande que l'ASP envoie un message ASP actif à son homologue.

Confirmation M-ASP_ACTIVE
Direction: M3UA -> LM
Objet : l'ASP rapporte qu'il a reçu un message ASP Active Ack de son homologue.

Indication M-ASP_ACTIVE
Direction: M3UA -> LM
Objet : M3UA rapporte qu'il a traité avec succès un message ASP actif entrant de son homologue.

Demande M-ASP_INACTIVE
Direction: LM -> M3UA
Objet : la LM demande que l'ASP envoie un message ASP Inactive à son homologue.

Confirmation M-ASP_INACTIVE
Direction: LM -> M3UA
Objet : l'ASP rapporte qu'il a reçu un message ASP Inactive Ack de son homologue.

Indication M-ASP_INACTIVE
Direction: M3UA -> LM
Objet : M3UA rapporte qu'il a traité avec succès un message ASP Inactive entrant de son homologue.

Indication M-AS_ACTIVE
Direction: M3UA -> LM
Objet : M3UA rapporte qu'un AS est passé à l'état AS-ACTIVE.

Indication M-AS_INACTIVE
Direction: M3UA -> LM
Objet : M3UA rapporte qu'un AS est passé à l'état AS-INACTIVE.

Indication M-AS_DOWN
Direction: M3UA -> LM
Objet : M3UA rapporte qu'un AS est passé à l'état AS-DOWN.

Si l'enregistrement dynamique de RK est pris en charge par la couche M3UA, la couche PEUT prendre en charge les primitives supplémentaires suivantes :

Demande M-RK_REG
Direction: LM -> M3UA
Objet : la LM demande que l'ASP enregistre la ou les RK avec son homologue en envoyant un message REG REQ.

Confirmation M-RK_REG
Direction: M3UA -> LM
Objet : l'ASP rapporte qu'il a reçu un message REG RSP avec un état d'enregistrement de succès de son homologue.

Indication M-RK_REG
Direction: M3UA -> LM
Objet : M3UA informe la LM qu'il a traité avec succès un message REG REQ entrant.

Demande M-RK_DEREG
Direction: LM -> M3UA
Objet : la LM demande que l'ASP désenregistre la ou les RK avec son homologue par l'envoi d'un message DEREG REQ.

Confirmation M-RK_DEREG
Direction: M3UA -> LM
Objet : l'ASP rapporte qu'il a reçu un message DEREG REQ avec l'état de désenregistrement de succès de son homologue.

Indication M-RK_DEREG
Direction: M3UA -> LM
Objet : M3UA informe la LM qu'il a traité avec succès une DEREG REQ entrante de son homologue.

 	2.	Conventions

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

 	3.	Éléments du protocole M3UA

Le format général de message M3UA inclut un en-tête de message commun suivi par zéro, un ou plusieurs paramètres comme défini par le type de message. Pour la compatibilité future, tous les types de messages peuvent avoir des paramètres rattachés même si aucun n'est spécifié dans cette version.

 	3.1	En-tête de message commun
Les messages de protocole pour l'adaptation d'utilisateur MTP3 exigent un en-tête de message qui contienne 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                    |
+---------------+---------------+---------------+---------------+
\                                                               \
/                                                               /

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

 	3.1.1	Version de protocole M3UA
Entier non signé de 8 bits. Le champ version contient la version de la couche d'adaptation M3UA.
Les versions prises en charge sont comme suit :

         1      Release 1.0

 	3.1.2	Classes et types de message
Classe de message : 8 bits (entier non signé)

La liste suivante contient les classes de message valides :
0 	Messages de gestion (MGMT)
1 	Messages de transfert
2 	Messages de gestion de réseau de signalisation SS7 (SSNM)
3 	Messages de maintenance d'état d'ASP (ASPSM)
4 	Messages de maintenance de trafic d'ASP (ASPTM)
5 	Réservé pour d'autres couches d'adaptation SIGTRAN
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 	Messages de gestion de clé d'acheminement (RKM)
10 à 127	Réservé par l'IETF
128 à 255	Réservé pour des extensions de classe de message définies par l'IETF

Type de message : 8 bits (entier non signé)

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

Messages de gestion (MGMT, Management) (voir le paragraphe 3.8)
0	Erreur (ERR)
1	Notifie (NTFY)
2 à 127	Réservé par l'IETF
128 à 255	Réservé pour des extensions MGMT définies par l'IETF

Messages de transfert (voir le paragraphe 3.3)
0	Réservé
1	Données de charge utile (DATA)
2 à 127	Réservé par l'IETF
128 à 255	Réservé pour des extensions de transfert définies par l'IETF

Messages de gestion de réseau de signalisation SS7 (SSNM) (voir le paragraphe 3.4)
0	Réservé
1	Destination injoignable (DUNA)
2	Destination disponible (DAVA)
3	Examen d'état de destination (DAUD)
4	Signalement d'encombrement (SCON)
5	Système d'utilisateur de destination indisponible (DUPU)
6	Destination interdite (DRST)
7 à 127	Réservé par l'IETF
128 à 255	Réservé pour des extensions SSNM définies par l'IETF

Messages de maintenance d'état d'ASP (ASPSM, ASP State Maintenance) (voir le paragraphe 3.5)
0 	Réservé
1	ASP ouvert (ASPUP, ASP Up)
2	ASP fermé (ASPDN, ASP Down)
3	Battement de cœur (BEAT, Heartbeat)
4	Accusé de réception de ASP ouvert (ASPUP ACK, ASP Up Acknowledgement)
5	Accusé de réception de ASP fermé (ASPDN ACK, ASP Down Acknowledgement)
6	Accusé de réception de battement de cœur  (BEAT ACK, Heartbeat Acknowledgement)
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 d'ASP (ASPTM, ASP Traffic Maintenance) (voir le paragraphe 3.7)
0	Réservé
1	ASP Actif (ASPAC)
2 	ASP Inactif (ASPIA)
3 	Accusé de réception de ASP Actif (ASPAC ACK, ASP Active Acknowledgement)
4 	Accusé de réception de ASP Inactif (ASPIA ACK, ASP Inactive Acknowledgement)
5 à 127	Réservé par l'IETF
128 à 255	Réservé pour des extensions ASPTM définies par l'IETF

Messages de gestion de clé d'acheminement (RKM) (voir le paragraphe 3.6)
0	Réservé
1	Demande d'enregistrement (REG REQ, Registration Request)
2	Réponse d'enregistrement (REG RSP, Registration Response)
3	Demande de désenregistrement (DEREG REQ, Deregistration Request)
4	Réponse de désenregistrement (DEREG RSP, Deregistration Response)
5 à 127	Réservé par l'IETF
128 à 255	Réservé pour les extensions RKM définies par l'IETF

 	3.1.3	Réservé : 8 Bits
Le champ Réservé DEVRAIT être réglé tout à '0' et ignoré par le receveur.

 	3.1.4	Longueur de message : 32 bits (entier non signé)
La longueur de message définit la longueur du message en octets, incluant l'en-tête commun. La longueur du message DOIT inclure les octets de bourrage de paramètres, si il en est.

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

 	3.2	Format de paramètre de longueur variable
Les messages M3UA 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. Tous les paramètres contenus dans un message sont définis dans un format Étiquette Longueur Valeur, 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                     /
\                                                               \
+---------------+---------------+---------------+---------------+

Lorsque plus d'un paramètre est inclus dans un message, les paramètres peuvent être dans n'importe quel ordre, sauf lorsque il est explicitement rendu obligatoire. Un receveur DEVRAIT accepter les paramètres dans n'importe quel ordre.

Sauf déclaré explicitement ou montré dans un diagramme de format de message, un seul paramètre de même type est permis dans un message.

Étiquette de paramètre : 16 bits (entier non signé)
Le champ Étiquette 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 paramètres spécifiques de M3UA ont des étiquettes dans la gamme de 0x0200 à 0x02ff.  Les étiquettes de paramètre définies sont comme suit :

Paramètres communs. Ces TLV de paramètres sont communs aux différentes couches d'adaptation :

Nom de paramètre	Identifiant de paramètre
Réservé	0x0000
Non utilisé dans M3UA	0x0001
Non utilisé dans M3UA	0x0002
Non utilisé dans M3UA	0x0003
Chaîne d'INFO	0x0004
Non utilisé dans M3UA	0x0005
Contexte d'acheminement 	0x0006
Informations de diagnostic	0x0007
Non utilisé dans M3UA	0x0008
Données de battement de cœur	0x0009
Non utilisé dans M3UA	0x000a
Type de mode de trafic	0x000b
Code d'erreur	0x000c
État	0x000d
Non utilisé dans M3UA	0x000e
Non utilisé dans M3UA	0x000f
Non utilisé dans M3UA	0x0010
Identifiant d'ASP	0x0011
Codet affecté	0x0012
Identifiant de corrélation	0x0013

Paramètres spécifiques de M3UA. Ces TLV de paramètres sont spécifiques du protocole M3UA :

Apparition de réseau	0x0200
Réservé	0x0201
Réservé	0x0202
Réservé	0x0203
Usager/Cause	0x0204
Indications d'encombrement	0x0205
Destination concernée 	0x0206
Clé d'acheminement	0x0207
Résultat d'enregistrement	0x0208
Résultat de désenregistrement	0x0209
Identifiant de clé d'acheminement locale	0x020a
Codet de destination	0x020b
Indicateurs de service 	0x020c
Réservé	0x020d
Liste des codets d'origine	0x020e
Réservé	0x020f
Données de protocole	0x0210
Réservé	0x0211
État d'enregistrement	0x0212
État de désenregistrement	0x0213
Réservé par l'IETF	0x0214 à 0xffff

La valeur de 65535 est réservée aux extensions définies par l'IETF. Les valeurs autres que définies dans les descriptions spécifiques de paramètre sont réservées à l'usage de l'IETF. Une RFC est exigé pour l'utilisation des valeurs de paramètre "Réservé par 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 de paramètre. Donc, un paramètre avec un champ Valeur de paramètre de longueur zéro aurait un champ Longueur de 4. La longueur de paramètre n'inclut aucun octet de bourrage. Si le paramètre contient des sous paramètres, le champ Longueur de paramètre va inclure tous les octets de chaque sous paramètre, incluant les octets de bourrage de sous paramètre (si il y en a).

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 de paramètre, 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 de paramètre) avec des octets tout à zéro. La longueur du bourrage N'EST PAS incluse dans le champ Longueur de paramètre. Un envoyeur NE DOIT PAS bourrer avec plus de 3 octets. Le receveur DOIT ignorer les octets de bourrage.

 	3.3	Messages Transfert
Cette section décrit les messages Transfert et le contenu des paramètres.

 	3.3.1	Message de données de charge utile (DATA)
Le message DATA contient les données de protocole d'utilisateur MTP3 SS7, qui est une primitive MTP-TRANSFER, incluant l'étiquette d'acheminement MTP3 complète. Le message DATA contient les paramètres de longueur variable suivants :
Apparition de réseau : facultatif
Contexte d'acheminement : conditionnel
Données de protocole : obligatoires
Identifiant de corrélation : facultatif

Le format suivant DOIT être utilisé pour le message Data :

 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 = 0x0200           |         Longueur = 8          |
+---------------+---------------+---------------+---------------+
|                       Apparition de réseau                    |
+---------------+---------------+---------------+---------------+
|  Étiquette = 0x0006           |          Longueur = 8         |
+---------------+---------------+---------------+---------------+
|                        Contexte d'acheminement                |
+---------------+---------------+---------------+---------------+
|  Étiquette = 0x0210           |             Longueur          |
+---------------+---------------+---------------+---------------+
\                                                               \
/                      Données de protocole                     /
\                                                               \
+---------------+---------------+---------------+---------------+
|  Étiquette = 0x0013           |          Longueur = 8         |
+---------------+---------------+---------------+---------------+
|                   Identifiant de corrélation                  |
+---------------+---------------+---------------+---------------+

Apparition de réseau : 32 bits (entier non signé)
Le paramètre Apparition de réseau identifie le contexte de réseau SS7 pour le message et identifie implicitement le format de codet SS7 utilisé, la valeur d'indicateur de réseau SS7, et le MTP3 et éventuellement le type/variante/version de protocole d'utilisateur MTP3 utilisé au sein du réseau SS7 spécifique. Lorsque une SG opère dans le contexte d'un seul réseau SS7, ou si des associations SCTP individuelles sont dédiées à chaque contexte de réseau SS7, le paramètre Apparition de réseau n'est pas exigé. Dans d'autres cas, le paramètre peut être configuré à être présent pour l'usage du receveur.
La valeur du paramètre Apparition de réseau a seulement une signification locale, coordonnée entre le SGP et l'ASP. Donc, dans le cas où un ASP est connecté à plus d'un SGP, le même contexte de réseau SS7 peut être identifié par différentes valeurs d'apparition de réseau, selon le SGP sur lequel un message est transmis/reçu.
Lorsque le paramètre facultatif Apparition de réseau est présent, il DOIT être le premier paramètre du message, car il définit le format du champ Données de protocole.

Note de mise en œuvre : pour la simplicité de la configuration, il peut être désirable d'utiliser la même valeur de NA sur tous les nœuds qui partagent un contexte de réseau particulier.

Contexte d'acheminement : 32 bits (entier non signé)
Le paramètre Contexte d'acheminement contient la valeur du contexte d'acheminement associé au message DATA. Lorsque une clé d'acheminement n'a pas été coordonnée entre le SGP et l'ASP, l'envoi d'un contexte d'acheminement n'est pas exigé. Lorsque plusieurs clés d'acheminement et contextes d'acheminement sont utilisés sur une association commune, le contexte d'acheminement DOIT être envoyé pour identifier le flux de trafic, aidant à la distribution interne des messages Data.

Données de protocole : longueur variable
Le paramètre Données de protocole contient le message original SS7 MTP3, incluant l'octet Informations de service et l'étiquette d'acheminement. Le paramètre Données de protocole contient les champs suivants :
Indicateur de service
Indicateur de réseau
Priorité de message
Codet de destination
Codet d'origine
Code de sélection de liaison de signalisation (SLS, Signalling Link Selection)
Données de protocole d'utilisateur, qui incluent des éléments de protocole d'utilisateur MTP3 (par exemple, paramètres ISUP, SCCP, ou TUP)

Le paramètre Données de protocole est codé comme suit :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Codet d'origine                      |
+---------------+---------------+---------------+---------------+
|                    Codet de destination                       |
+---------------+---------------+---------------+---------------+
|       SI      |       NI      |      MP       |      SLS      |
+---------------+---------------+---------------+---------------+
\                                                               \
/                   Données de protocole d'utilisateur          /
\                                                               \
+---------------+---------------+---------------+---------------+

Codet d'origine : 32 bits (entier non signé)
Codet de destination : 32 bits (entier non signé)
Les champs Codet d'origine et Codet de destination contiennent le OPC et DPC provenant de l'étiquette d'acheminement du message SS7 original dans l'ordre des octets du réseau, justifié sur le bit de moindre poids. Les bits inutilisés sont codés `0'.

Indicateur de service : 8 bits (entier non signé). Le champ Indicateur de service contient le champ SI provenant du message SS7 original justifié sur le bit de moindre poids. Les bits inutilisés sont codés `0'.

Indicateur de réseau : 8 bits (entier non signé). L'indicateur de réseau contient le champ NI provenant du message SS7 original justifié sur le bit de moindre poids. Les bits inutilisés sont codés `0'.

Priorité de message : 8 bits (entier non signé). Le champ Priorité de message contient les bits MP (si il en est) provenant du message SS7 original, aussi bien pour les bits de priorité de message de style ANSI que de style TTC [JT.Q704]. Les bits MP sont alignés sur le bit de moindre poids. Les bits inutilisés sont codés `0'.

Sélection de liaison de signalisation : 8 bits (entier non signé). Le champ Sélection de liaison de signalisation contient les bits de SLS provenant de l'étiquette d'acheminement du message SS7 original justifié sur le bit de moindre poids et dans l'ordre des octets du réseau. Les bits inutilisés sont codés `0'.

Données de protocole d'utilisateur : chaîne d'octets de longueur variable. Le champ Données de protocole d'utilisateur contient une chaîne d'octets d'informations d'utilisateur MTP provenant du message SS7 original, en commençant par le premier octet du message SS7 original qui suit l'étiquette d'acheminement [Q.700-705], [T1.111], [JT.Q704].

Identifiant de corrélation : 32 bits (entier non signé). Le paramètre Identifiant de corrélation identifie de façon univoque la MSU portée dans les données de protocole au sein d'un AS. Ce paramètre Identifiant de corrélation est alloué par le M3UA envoyeur.

 	3.4	Messages de gestion de réseau de signalisation SS7
 	3.4.1	Destination indisponible (DUNA)
Le message DUNA est envoyé d'un SGP dans une SG à tous les ASP concernés pour indiquer que la SG a déterminé que une ou plusieurs destinations SS7 sont injoignables. Il est aussi envoyé par un SGP en réponse à un message provenant de l'ASP à une destination SS7 injoignable. Comme option de mise en œuvre, la SG peut supprimer l'envoi des messages "réponse" DUNA suivants concernant une certaine destination SS7 injoignable pendant un certain temps pour donner au côté distant le temps de réagir. Si il n'y a pas de chemin de remplacement via une autre SG, l'utilisateur MTP3 à l'ASP est supposé arrêter le trafic pour la destination affectée via la SG conformément aux procédures définies d'utilisateur MTP3.

Le message DUNA contient les paramètres suivants :
Apparition de réseau (facultatif)
Contexte d'acheminement (conditionnel)
Codet affecté (obligatoire)
Chaîne d'INFO (facultatif)

Le format des paramètre de message DUNA est comme suit :

 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 = 0x0200           |          Longueur = 8         |
+---------------+---------------+---------------+---------------+
|                      Apparition de réseau                     |
+---------------+---------------+---------------+---------------+
|  Étiquette = 0x0006           |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                       Contexte d'acheminement                 /
\                                                               \
+---------------+---------------+---------------+---------------+
|   Étiquette = 0x0012          |           Longueur            |
+---------------+---------------+---------------+---------------+
|   Gabarit     |              Codet affecté 1                  |
+---------------+---------------+---------------+---------------+
\                                                               \
/                              ...                              /
\                                                               \
+---------------+---------------+---------------+---------------+
|   Gabarit     |               Codet affecté n                 |
+---------------+---------------+---------------+---------------+
|     Étiquette = 0x0004        |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                        Chaîne d'INFO                          /
\                                                               \
+---------------+---------------+---------------+---------------+

Apparition de réseau : entier de 32 bits non signé. La description de l'apparition de réseau du paragraphe 3.3.1 s'applique, avec l'exception que l'apparition de réseau n'a pas à être le premier paramètre dans ce message.

Contexte d'acheminement : n x 32 bits (entier non signé). Le paramètre conditionnel Contexte d'acheminement contient les valeurs de contexte d'acheminement associées au message DUNA. Lorsque une clé d'acheminement n'a pas été coordonnée entre le SGP et l'ASP, l'envoi du contexte d'acheminement n'est pas exigé. Lorsque plusieurs clés d'acheminement et contextes d'acheminement sont utilisés sur une association commune, le ou les contextes d'acheminement DOIVENT être envoyés pour identifier les flux de trafic concernés pour lesquels le message DUNA s'applique, aidant la gestion du trafic sortant et la distribution interne des indications MTP-PAUSE aux utilisateurs MTP3 chez le receveur.

Codet affecté : n x 32 bits. Le paramètre Codet affecté contient une liste des champs Codet de destination affecté (DPC, Destination Point Code) chaque paramètre de trois octets permettant des codets SS7 formatés en binaire de 14, 16, et 24 bits. Les codets affectés qui font moins de 24 bits sont bourrés à gauche jusqu'à la imite de 24 bits. Le codage est montré ci-dessous pour des exemples de codets ANSI et UIT.

Codet ANSI de 24 bits
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Gabarit     |   Réseau      |   Grappe      |     Membre    |
+---------------+---------------+---------------+---------------+
                |MSB-----------------------------------------LSB|

Codet UIT de 14 bits

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Gabarit   |0 0 0 0 0 0 0 0 0 0|Zone |     Région    | SP  |
+---------------+---------------+---------------+---------------+
                                    |MSB---------------------LSB|

Il est facultatif d'envoyer un paramètre Codet affecté avec plus d'un codet affecté, mais il est obligatoire de le recevoir. Inclure plusieurs codets affectés peut être utile quand la réception d'un message de gestion MTP3 ou d'un événement liaison établie affecte simultanément l'état de disponibilité d'une liste de destinations à une SG.

Gabarit : 8 bits (entier non signé). Le champ Gabarit peut être utilisé pour identifier une gamme contiguë de codets de destination affectés. Identifier une gamme contiguë de codets de destination affectés peut être utile quand la réception d'un message de gestion MTP3 ou d'un événement d'établissement de liaison affecte simultanément l'état de disponibilité d'une série de destinations à une SG. Le paramètre Gabarit est un entier représentant un gabarit binaire qui peut être appliqué au champ Codet affecté en rapport. Le gabarit binaire identifie combien de bits du champ Codet affecté sont significatifs et lesquels sont effectivement des "caractères génériques". Par exemple, un gabarit de "8" indique que les huit derniers bits du codet sont des "caractères génériques". Pour un codet affecté ANSI de 24 bits, ceci est équivalent à signaler que tous les codets dans une grappe ANSI sont indisponibles. Un gabarit de "3" indique que les trois derniers bits du codet sont des "caractères génériques". Pour un codet affecté UIT de 14 bits, ceci est équivalent à signaler qu'une région UIT est indisponible. Une valeur de gabarit égale (ou supérieure) au nombre de bits dans le codet indique que l'apparition de réseau entière est affectée ; ceci est utilisé pour indiquer un isolement de réseau à l'ASP.

Chaîne d'INFO : longueur variable. Le paramètre facultatif Chaîne d'INFO peut porter toute chaîne de caractère UTF-8 [RFC3629] significative avec le message. La longueur du paramètre Chaîne d'INFO est de 0 à 255 octets. Aucune procédure n'est présentement identifiée pour son utilisation, mais la chaîne INFO PEUT être utilisée à des fins de débogage. Une chaîne d'INFO avec un paramètre de longueur zéro n'est pas considérée comme une erreur (un paramètre de longueur zéro a le champ Longueur dans le TLV qui va être réglé à 4).

 	3.4.2	Destination disponible (DAVA)
Le message DAVA est envoyé d'un SGP à tous les ASP concernés pour indiquer que la SG a déterminé qu'une ou plusieurs destinations SS7 sont maintenant accessibles (et non interdites) ou en réponse à un message DAUD, si c'est approprié. Si la couche M3UA de l'ASP n'avait précédemment pas de chemin pour les destinations affectées, le protocole d'utilisateur MTP3 de l'ASP est informé et peut maintenant reprendre le trafic sur la destination affectée. La couche M3UA de l'ASP achemine maintenant le trafic d'utilisateur MTP3 à travers la SG qui a initié le message DAVA.

Le message DAVA contient les paramètres suivants :
Apparition de réseau (facultatif)
Contexte d'acheminement (conditionnel)
Codet affecté (obligatoire)
Chaîne d'INFO (facultatif)

Le format et la description des paramètres Apparition de réseau, Contexte d'acheminement, Codet affecté, et chaîne d'INFO sont les mêmes que pour le message DUNA (paragraphe 3.4.1).

 	3.4.3	Examen d'état de destination (DAUD)
Le message DAUD PEUT être envoyé de l'ASP à la SGP pour examiner l'état de disponibilité/encombrement des chemins SS7 de la SG à une ou plusieurs destinations affectées.

Le message DAUD contient les paramètres suivants :
Apparition de réseau (facultatif)
Contexte d'acheminement (conditionnel)
Codet affecté (obligatoire)
Chaîne d'INFO (facultatif)

Le format et la description des paramètres du message DAUD sont les mêmes que pour le message DUNA (paragraphe  3.4.1).

Il est recommandé que durant le fonctionnement normal (traitement du trafic) le champ Gabarit du paramètre Codet affecté dans le message DAUD reste à la valeur de zéro afin d'éviter une surcharge de la SG.

 	3.4.4	Encombrement de signalisation (SCON)
Le message SCON peut être envoyé d'un SGP à tous les ASP concernés pour indiquer qu'une SG a déterminé qu'il y a de l'encombrement dans le réseau SS7 pour une ou plusieurs destinations, ou à un ASP en réponse à un message DATA ou DAUD, comme approprié. Pour certaines variantes du protocole MTP (par exemple, MTP ANSI) le message SCON peut être envoyé quand le niveau d'encombrement SS7 change. Le message SCON PEUT aussi être envoyé de la couche M3UA d'un ASP à un homologue M3UA, indiquant que le niveau d'encombrement de la couche M3UA ou de l'ASP a changé.

Note de mise en œuvre : un nœud M3UA peut tenir un temporisateur pour contrôler la validité des notifications d'encombrement, si désiré. Ce temporisateur va être utile dans des cas où le nœud homologue échoue à indiquer l'affaiblissement de l'encombrement.

Le message SCON contient les paramètres suivants :
Apparition de réseau (facultatif)
Contexte d'acheminement (conditionnel)
Codet affecté (obligatoire)
Destination concernée (facultatif)
Indications d'encombrement (facultatif)
Chaîne d'INFO (facultatif)

Le format pour les paramètres de message SCON est comme suit :

 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 = 0x0200          |         Longueur = 8          |
+---------------+---------------+---------------+---------------+
|                       Apparition de réseau                    |
+---------------+---------------+---------------+---------------+
|  Étiquette = 0x0006           |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                       Contexte d'acheminement                 /
\                                                               \
+---------------+---------------+---------------+---------------+
|   Étiquette = 0x0012          |           Longueur            |
+---------------+---------------+---------------+---------------+
|    Gabarit    |              Codet affecté 1                  |
+---------------+---------------+---------------+---------------+
\                                                               \
/                              ...                              /
\                                                               \
+---------------+---------------+---------------+---------------+
|    Gabarit    |              Codet affecté n                  |
+---------------+---------------+---------------+---------------+
|   Étiquette = 0x0206          |           Longueur = 8        |
+---------------+---------------+---------------+---------------+
|    Réservé    |          Codet de destination concerné        |
+---------------+---------------+---------------+---------------+
|   Étiquette = 0x0205          |           Longueur = 8        |
+---------------+---------------+---------------+---------------+
|                   Réservé                     | Niveau encombr|
+---------------+---------------+---------------+---------------+
|      Étiquette = 0x0004       |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                        Chaîne d'INFO                          /
\                                                               \
+---------------+---------------+---------------+---------------+

Le format et la description des paramètres Apparition de réseau, Contexte d'acheminement, Codet affecté, et Chaîne d'INFO sont les mêmes que pour le message DUNA (voir au paragraphe 3.4.1).

Le paramètre Codet affecté peut être utilisé pour indiquer l'encombrement de plusieurs destinations ou gammes de destinations.

Destination concernée : 32 bits. Le paramètre facultatif Destination concernée est seulement utilisé si le message SCON est envoyé d'un ASP au SGP. Il contient le codet de l'origine du message qui a déclenché le message SCON. Le paramètre Destination concernée contient un champ Codet de destination concernée, un paramètre de trois octets permettant des codets SS7 formatés en binaire de 14, 16, et 24 bits. Un codet concerné qui fait moins de 24 bits est bourré à gauche jusqu'à la limite de 24 bits. Tout message résultant de transfert contrôlé (TFC, Transfer Controlled) provenant de la SG est envoyé au codet concerné en utilisant le seul DPC affecté contenu dans le message SCON pour remplir le champ Destination (affectée) du message TFC.

Indications d'encombrement : 32 bits. Le paramètre facultatif Indications d'encombrement contient un champ Niveau d'encombrement. Ce paramètre facultatif est utilisé pour communiquer les niveaux d'encombrement dans les réseaux MTP nationaux avec plusieurs seuils d'encombrement, comme dans ANSI MTP3. Pour les méthodes d'encombrement MTP sans niveau d'encombrement (par exemple, la méthode internationale de l'UIT) le paramètre n'est pas inclus.

Champ Niveau d'encombrement : 8 bits (entier non signé). Le champ Niveau d'encombrement, associé à tous les DPC affectés dans le paramètre Destinations affectées, contient une des valeurs suivantes :
0 : Pas d'encombrement ou indéfini
1 : Niveau d'encombrement 1
2 : Niveau d'encombrement 2
3 : Niveau d'encombrement 3

Les niveaux d'encombrement sont définis dans la méthode d'encombrement de la recommandation nationale MTP appropriée [Q.700-705], [T1.111].

 	3.4.5	Sous système Utilisateur de destination indisponible (DUPU)
Le message DUPU (Destination User Part Unavailable) est utilisé par un SGP pour informer les ASP concernés qu'un sous système utilisateur MTP3 de l'homologue distant (par exemple, ISUP ou SCCP) à un nœud SS7 est indisponible.

Le message DUPU contient les paramètres suivants :
Apparition de réseau (facultatif)
Contexte d'acheminement  (conditionnel)
Codet affecté (obligatoire)
Utilisateur/Cause (obligatoire)
Chaîne d'INFO (facultatif)

Le format des paramètres du message DUPU est comme suit :

 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 = 0x0200          |           Longueur = 8        |
+---------------+---------------+---------------+---------------+
|                      Apparition de réseau                     |
+---------------+---------------+---------------+---------------+
|  Étiquette = 0x0006           |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                       Contexte d'acheminement                 /
\                                                               \
+---------------+---------------+---------------+---------------+
|   Étiquette = 0x0012          |          Longueur = 8         |
+---------------+---------------+---------------+---------------+
|  Gabarit = 0  |                Codet affecté                  |
+---------------+---------------+---------------+---------------+
|   Étiquette = 0x0204          |         Longueur = 8          |
+---------------+---------------+---------------+---------------+
|             Cause             |            Utilisateur        |
+---------------+---------------+---------------+---------------+
|   Étiquette = 0x0004          |             Longueur          |
+---------------+---------------+---------------+---------------+
\                                                               \
/                         Chaîne d'INFO                         /
\                                                               \
+---------------+---------------+---------------+---------------+

Utilisateur/Cause : 32 bits. Les champs Cause d'indisponibilité et Identité de l'utilisateur MTP3, associés au codet affecté dans le paramètre Codet affecté, sont codés comme suit :

Champ Cause d'indisponibilité : 16 bits (entier non signé). Le paramètre Cause d'indisponibilité fournit la raison de l'indisponibilité de l'utilisateur MTP3. Les valeurs valides pour le paramètre Cause d'indisponibilité sont données ci dessous. Les valeurs sont en accord avec celles fournies dans le message Indisponible du sous système d'utilisateur MTP3 du SS7. Selon le protocole MTP3 utilisé dans l'apparition de réseau, des valeurs supplémentaires peuvent être utilisées ; la spécification de la recommandation de variante/version pertinente de protocole MTP3 est définitive.
0 : inconnu
1 : utilisateur distant non équipé
2 : utilisateur distant inaccessible

Champ Identité de l'utilisateur MTP3 : 16 bits (entier non signé). L'identité de l'utilisateur MTP3 décrit l'utilisateur MTP3 spécifique qui est indisponible (par exemple, ISUP, SCCP, etc.). Certaines des valeurs valides pour l'identité d'utilisateur MTP3 sont montrées ci-dessous. Ces valeurs sont alignées sur celles fournies dans le message Indisponible et l'indicateur de service du sous système d'utilisateur MTP3 du SS7. Selon la variante/version du protocole MTP3 utilisé dans l'apparition de réseau, des valeurs supplémentaires peuvent être utilisées. La recommandation de variante/version pertinente de protocole MTP3 est définitive.

0 à 2 : Réservé
3 : SCCP
4 : TUP
5 : ISUP
6 à 8 : Réservé
9 : ISUP large bande
10 : ISUP par satellite 
11 : Réservé
12 : Signalisation AAL type 2
13 : Contrôle d'appel indépendant du support (BICC, Bearer Independent Call Control)
14 : Protocole de contrôle de passerelle
15 : Réservé

Le format et la description du paramètre Codet affecté sont les mêmes que pour le message DUNA (voir au paragraphe  3.4.1.) sauf que le champ Gabarit n'est pas utilisé et qu'un seul codet de destination affecté est inclus. Les gammes et listes de DPC affectés ne peuvent pas être signalées dans un message DUPU, mais ceci est cohérent avec l'opération UPU dans le réseau SS7. Le paramètre Destinations affectées dans un message Indisponible du sous système d'utilisateur MTP3 (UPU, User Part Unavailable) reçu par un SGP du réseau SS7 contient seulement une destination.

Le format et la description des paramètres Apparition de réseau, Contexte d'acheminement, et Chaîne d'INFO sont les mêmes que pour le message DUNA (voir au paragraphe 3.4.1).

 	3.4.6	Destination interdite (DRST)
Le message Destination interdite (DRST, Destination Restricted) est facultativement envoyé du SGP à tous les ASP concernés pour indiquer que la SG a déterminé qu'une ou plusieurs destinations SS7 sont maintenant interdites du point de vue de la SG, ou en réponse à un message DAUD, si c'est approprié. La couche M3UA à l'ASP est supposée envoyer du trafic à la destination affectée via une autre SG avec un chemin de priorité égale, mais seulement si un tel chemin de remplacement existe et est disponible. Si la destination affectée est actuellement considérée comme indisponible par l'ASP, l'utilisateur MTP3 devrait être informé que le trafic pour la destination affectée peut être repris. Dans ce cas, la couche M3UA devrait acheminer le trafic à travers la SG qui a initié le message DRST.

L'envoi de ce message est facultatif pour la SG, et il est facultatif pour l'ASP d'agir sur toute information reçue dans le message. Il est à l'usage du cas "STP" décrit au paragraphe 1.4.1.

Le message DRST contient les paramètres suivants :
Apparition de réseau (facultatif)
Contexte d'acheminement (conditionnel)
Codet affecté (obligatoire)
Chaîne d'INFO (facultatif)

Le format et la description des paramètres Apparition de réseau, Contexte d'acheminement, Codet affecté, et Chaîne d'INFO sont les mêmes que pour le message DUNA (voir au paragraphe 3.4.1).

 	3.5	Messages de maintenance d'état d'ASP (ASPSM)
 	3.5.1	ASP Up
Le message ASP Up est utilisé pour indiquer à un homologue M3UA distant que la couche d'adaptation est prête à recevoir tout message ASPSM/ASPTM pour toutes les clés d'acheminement que l'ASP est configuré à servir.

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

Le format des paramètres de message ASP Up est comme suit :

 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 : 32-bit entier non signé. Le paramètre facultatif Identifiant d'ASP contient une valeur unique qui est significative localement parmi les ASP qui prennent en charge un AS. Le SGP devrait sauvegarder l'identifiant d'ASP à utiliser, si nécessaire, avec le message Notify (voir au paragraphe 3.8.2).

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

 	3.5.2	Accusé de réception de ASP Up (ASP Up Ack)
Le message ASP UP Ack est utilisé pour accuser réception d'un message ASP Up reçu d'un homologue M3UA distant.

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

Le format pour les paramètres du message ASP Up Ack est comme suit :

 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                         /
\                                                               \
+---------------+---------------+---------------+---------------+

Le paramètre facultatif Identifiant d'ASP est spécifiquement utile pour la communication IPSP. Dans ce cas, l'IPSP qui répond au message ASP Up PEUT inclure sa propre valeur d'identifiant d'ASP.

Le format et la description du paramètre facultatif Chaîne d'INFO sont les mêmes que pour le message DUNA (voir au paragraphe 3.4.1). La chaîne d'INFO dans un message ASP Up Ack est indépendante de la chaîne d'INFO dans le message ASP Up (c'est-à-dire, elle n'a pas à faire écho à la chaîne d'INFO reçue).

 	3.5.3	ASP Down
Le message ASP Down est utilisé pour indiquer à un homologue M3UA distant que la couche d'adaptation N'est PAS prête à recevoir les messages DATA, SSNM, RKM, ou ASPTM.

Le message ASP Down contient le paramètre suivant :
Chaîne d'INFO (facultatif)
Le format pour les paramètres du message ASP Down est comme suit :

 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 DUNA (voir au paragraphe 3.4.1).

 	3.5.4	Accusé de réception de ASP Down (ASP Down Ack)
Le message ASP Down Ack est utilisé pour accuser réception d'un message ASP Down reçu d'un homologue M3UA distant.

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

Le format des paramètres du message ASP Down Ack est comme suit :

 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 DUNA (paragraphe  3.4.1).

La chaîne d'INFO dans un message ASP Down Ack est indépendante de la chaîne d'INFO dans le message ASP Down (c'est-à-dire, elle n'a pas à faire écho à la chaîne d'INFO reçue).

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

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

Le format pour le message BEAT est comme suit :

 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 BEAT ne traite pas ce champ, car il n'a de signification que pour l'envoyeur. Le receveur DOIT répondre par un message BEAT Ack.

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

 	3.6	Messages de gestion de clé d'acheminement (RKM) (facultatif)
 	3.6.1	Demande d'enregistrement (REG REQ)
Le message REG REQ est envoyé par un ASP pour indiquer à un homologue M3UA distant qu'il souhaite enregistrer une ou plusieurs clés d'acheminement (RK, Routing Key) données avec l'homologue distant. Normalement, un ASP va envoyer ce message à un SGP et s'attendre à recevoir un message REG RSP en retour avec une valeur associée de contexte d'acheminement.

Le message REG REQ contient le paramètre suivant :
Clé d'acheminement (obligatoire)

Un ou plusieurs paramètres Clé d'acheminement PEUVENT être inclus. Le format du message REG REQ est comme suit :

 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 = 0x0207          |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                         Clé d'acheminement 1                  /
\                                                               \
+---------------+---------------+---------------+---------------+
\                                                               \
/                              ...                              /
\                                                               \
+---------------+---------------+---------------+---------------+
|    Étiquette = 0x0207         |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                         Clé d'acheminement n                  /
\                                                               \
+---------------+---------------+---------------+---------------+

Clé d'acheminement : longueur variable. Le paramètre Clé d'acheminement est obligatoire. L'envoyeur de ce message s'attend à ce que le receveur de ce message crée une entrée de clé d'acheminement et lui alloue une unique valeur de contexte d'acheminement, si l'entrée de clé d'acheminement n'existe pas déjà.

Le paramètre Clé d'acheminement peut être présent plusieurs fois dans le même message. C'est utilisé pour permettre l'enregistrement de plusieurs clés d'acheminement dans un seul message.

Le format du paramètre Clé d'acheminement est comme suit :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Identifiant-RK-Local                    |
+---------------+---------------+---------------+---------------+
|                   Contexte d'acheminement (facultatif)        |
+---------------+---------------+---------------+---------------+
|                  Type de mode de trafic (facultatif)          |
+---------------+---------------+---------------+---------------+
|                    Codet de destination                       |
+---------------+---------------+---------------+---------------+
|                  Apparition de réseau (facultatif)            |
+---------------+---------------+---------------+---------------+
|                Indicateurs de service (facultatif)            |
+---------------+---------------+---------------+---------------+
|             Liste des codets d'origine (facultatif)           |
+---------------+---------------+---------------+---------------+
\                                                               \
/                              ...                              /
\                                                               \
+---------------+---------------+---------------+---------------+
|                    Codet de destination                       |
+---------------+---------------+---------------+---------------+
|                 Indicateurs de service (facultatif)           |
+---------------+---------------+---------------+---------------+
|             Liste des codets d'origine (facultatif)           |
+---------------+---------------+---------------+---------------+

Note : les paramètres Codet de destination, Indicateurs de service, et Liste des codets d'origine PEUVENT être répétés comme un groupement dans le paramètre Clé d'acheminement, dans la structure montrée ci-dessus.

Identifiant-RK-Local : entier non signé de 32 bits. Le champ obligatoire Identifiant-RK-Local est utilisé pour identifier de façon univoque la demande d'enregistrement. La valeur de l'identifiant est allouée par l'ASP et utilisée pour corréler la réponse dans un message REG RSP avec la demande d'enregistrement originale. La valeur d'identifiant doit rester unique jusqu'à la réception du message REG RSP.

Le format du champ Identifiant-RK-Local est comme suit :

 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 = 0x020a          |       Longueur = 8            |
+---------------+---------------+---------------+---------------+
|                 Valeur d'identifiant-RK-local                 |
+---------------+---------------+---------------+---------------+

Type de mode de trafic : 32 bits (entier non signé). Le paramètre facultatif Type de mode de trafic identifie le mode de fonctionnement du trafic de ou des ASP au sein d'un serveur d'application. Le format de l'identifiant de type de mode de trafic est comme suit :

 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                  |
+---------------+---------------+---------------+---------------+

Les valeurs valides de type de mode de trafic sont :
1 : Outrepasse
2 : Partage de charge
3 : Diffusion

Codet de destination : le paramètre Codet de destination est obligatoire, et il identifie le codet de destination du trafic SS7 entrant pour lequel l'ASP s'enregistre. Pour la configuration d'un alias de codet, le paramètre DPC serait répété pour chaque codet. Le format est le même que décrit pour le paramètre Destination affectée dans le message DUNA (voir au paragraphe  3.4.1). Son format 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 = 0x020b          |       Longueur = 8            |
+---------------+---------------+---------------+---------------+
|  Gabarit = 0  |           Codet de destination                |
+---------------+---------------+---------------+---------------+

Apparition de réseau : le champ facultatif de paramètre Apparition de réseau identifie le contexte de réseau SS7 pour la clé d'acheminement, et il a le même format que dans le message DATA (voir au paragraphe 3.3.1) sauf qu'il n'a pas à être le premier paramètre dans le message. Si Apparition de réseau n'est pas spécifié et si la clé d'acheminement s'applique à toutes les apparitions de réseau, cette clé d'acheminement DOIT alors être la seule enregistrée pour l'association ; c'est-à-dire, le contexte d'acheminement est implicite, et les messages DATA et SSNM sont discriminés sur l'apparition de réseau plutôt que sur le contexte d'acheminement. Lorsque l'apparition de réseau n'est pas spécifiée et qu'il y a seulement une apparition de réseau, l'apparition de réseau est implicite. Son format 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 = 0x0200          |         Longueur = 8          |
+---------------+---------------+---------------+---------------+
|                     Apparition de réseau                      |
+---------------+---------------+---------------+---------------+

Indicateurs de service (SI, Service Indicator) : n entiers de 8 bits. Le champ facultatif SI [T1.111], [Q.700-705] contient un ou plusieurs indicateurs de service à partir des valeurs décrites dans le champ Identité d'utilisateur MTP3 du message DUPU. L'absence du paramètre SI dans la clé d'acheminement indique l'utilisation de n'importe quelle valeur de SI, à l'exclusion bien sûr de gestion MTP. Lorsque un paramètre SI ne contient pas un multiple de quatre SI, le paramètre est bourré jusqu'à une limite de 32 octets.

Le format de SI 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 = 0x020c          |           Longueur            |
+---------------+---------------+---------------+---------------+
|      SI n° 1  |     SI n° 2   |    SI n° 3    |    SI n° 4    |
+---------------+---------------+---------------+---------------+
/                              ...                              /
+---------------+---------------+---------------+---------------+
|      SI n° n  |        Bourrage de 0, si nécessaire           |
+---------------+---------------+---------------+---------------+

Liste d'OPC : le paramètre Liste de codets d'origine (OPC, Originating Point Code List) contient une ou plusieurs entrées d'OPC SS7, et son format est le même que pour le paramètre Codet de destination. L'absence du paramètre Liste d'OPC dans la clé d'acheminement indique l'utilisation de n'importe quelle valeur d'OPC.

 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 = 0x020e          |           Longueur            |
+---------------+---------------+---------------+---------------+
|    Gabarit    |         Codet d'origine n° 1                  |
+---------------+---------------+---------------+---------------+
|    Gabarit    |         Codet d'origine n° 2                  |
+---------------+---------------+---------------+---------------+
/                              ...                              /
+---------------+---------------+---------------+---------------+
|    Gabarit    |         Codet d'origine n° n                  |
+---------------+---------------+---------------+---------------+

 	3.6.2	Réponse d'enregistrement (REG RSP)
Le message REG RSP est utilisé comme réponse au message REG REQ provenant d'un homologue M3UA distant. Il contient des indications de succès/échec de la demande d'enregistrement et retourne une valeur unique de contexte d'acheminement pour une demande d'enregistrement réussie, à utiliser dans un protocole suivant de gestion de trafic M3UA.

Le message REG RSP contient le paramètre suivant :
Résultat d'enregistrement (obligatoire)

Un ou plusieurs paramètres Résultat d'enregistrement DOIVENT être inclus. Le format du message REG RSP est comme suit :

 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 = 0x0208          |            Longueur           |
+---------------+---------------+---------------+---------------+
|                    Résultat d'enregistrement 1                |
+---------------+---------------+---------------+---------------+
\                                                               \
/                              ...                              /
\                                                               \
+---------------+---------------+---------------+---------------+
|   Étiquette = 0x0208          |          Longueur             |
+---------------+---------------+---------------+---------------+
|                    Résultat d'enregistrement n                |
+---------------+---------------+---------------+---------------+

Résultat d'enregistrement : le paramètre Résultat d'enregistrement contient le résultat de l'enregistrement pour une seule clé d'acheminement dans un message REG REQ. Le nombre de résultats dans un seul message REG RSP DOIT être entre un et le nombre total de paramètres de clé d'acheminement trouvés dans le message REG REQ correspondant. Lorsque plusieurs messages REG RSP sont utilisés en réponse au message REG REQ, un résultat spécifique DEVRAIT être dans seulement un message REG RSP. Le format de chaque résultat est comme suit :

 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 = 0x020a         |      Longueur = 8             |
+---------------+---------------+---------------+---------------+
|                Valeur de l'identifiant de RK locale           |
+---------------+---------------+---------------+---------------+
|     Étiquette = 0x0212        |      Longueur = 8             |
+---------------+---------------+---------------+---------------+
|                      État d'enregistrement                    |
+---------------+---------------+---------------+---------------+
|     Étiquette = 0x0006        |      Longueur = 8             |
+---------------+---------------+---------------+---------------+
|                        Contexte d'acheminement                |
+---------------+---------------+---------------+---------------+

Identifiant de RK locale : entier de 32 bits. L'identifiant de RK locale contient la même valeur que trouvée dans le paramètre Clé d'acheminement correspondant trouvé dans le message REG REQ (paragraphe 3.6.1).

État d'enregistrement : entier de 32 bits. Le champ État d'enregistrement indique le succès ou la raison de l'échec d'une demande d'enregistrement.

Ses valeurs peuvent être :
0 : Enregistrement réussi
1 : Erreur - inconnue
2 : Erreur – DPC invalide
3 : Erreur – apparition de réseau invalide
4 : Erreur – clé d'acheminement invalide
5 : Erreur – permission refusée
6 : Erreur – ne peut pas prendre en charge un acheminement unique
7 : Erreur – clé d'acheminement non provisionnée actuellement
8 : Erreur – ressources insuffisantes
9 : Erreur – champ de paramètre de RK non pris en charge
10 : Erreur – mode de traitement du trafic non pris en charge/invalide
11 : Erreur – changement de clé d'acheminement refusé
12 : Erreur – clé d'acheminement déjà enregistrée

Contexte d'acheminement : entier de 32 bits. Le champ Contexte d'acheminement contient la valeur du contexte d'acheminement pour la clé d'acheminement associée si l'enregistrement a réussi. Il est réglé à "0" si l'enregistrement n'a pas réussi.

 	3.6.3	Demande de désenregistrement (DEREG REQ)
Le message DEREG REQ est envoyé par un ASP pour indiquer à un homologue M3UA distant qu'il souhaite désenregistrer une certaine clé d'acheminement. Normalement, un ASP enverrait ce message à un SGP et s'attendrait à recevoir un message DEREG RSP en retour avec la valeur de contexte d'acheminement associée.

Le message DEREG REQ contient les paramètres suivants :
Contexte d'acheminement (obligatoire)
Le format du message DEREG REQ est comme suit :

 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 = 0x0006          |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                       Contexte d'acheminement                 /
\                                                               \
+---------------+---------------+---------------+---------------+

Contexte d'acheminement : n entiers de 32 bits. Le paramètre Contexte d'acheminement contient (une liste) des entiers qui indexent le trafic de serveur d'application que l'ASP envoyeur est actuellement enregistré à recevoir du SGP mais souhaite maintenant désenregistrer.

 	3.6.4	Réponse de désenregistrement (DEREG RSP)
Le message DEREG RSP est utilisé comme réponse au message DEREG REQ provenant d'un homologue M3UA distant.
Le message DEREG RSP contient le paramètre suivant :
Résultat de désenregistrement (obligatoire)
Un ou plusieurs paramètres Résultat de désenregistrement DOIVENT être inclus. Le format du message DEREG RSP est comme suit :

 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 = 0x0209          |             Longueur          |
+---------------+---------------+---------------+---------------+
|                   Résultat de désenregistrement 1             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                              ...                              /
\                                                               \
+---------------+---------------+---------------+---------------+
|    Étiquette = 0x0209         |          Longueur             |
+---------------+---------------+---------------+---------------+
|                   Résultat de désenregistrement n             |
+---------------+---------------+---------------+---------------+

Résultat de désenregistrement : le paramètre Résultat de désenregistrement contient l'état de désenregistrement pour un seul contexte d'acheminement dans un message DEREG REQ. Le nombre de résultats dans un seul message DEREG RSP PEUT être de un jusqu'au nombre total de valeurs de contexte d'acheminement trouvées dans le message DEREG REQ correspondant.

Lorsque plusieurs messages DEREG RSP sont utilisés en réponse au message DEREG REQ, un résultat spécifique DEVRAIT être dans seulement un message DEREG RSP. Le format de chaque résultat est comme suit :

 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 = 0x0006          |          Longueur = 8         |
+---------------+---------------+---------------+---------------+
|                        Contexte d'acheminement                |
+---------------+---------------+---------------+---------------+
|   Étiquette = 0x0213          |          Longueur = 8         |
+---------------+---------------+---------------+---------------+
|                    État de désenregistrement                  |
+---------------+---------------+---------------+---------------+

Contexte d'acheminement : entier de 32 bits. Le champ Contexte d'acheminement contient la valeur du contexte d'acheminement de la clé d'acheminement correspondante à désenregistrer, comme elle se trouve dans le message DEREG REQ.

État de désenregistrement : entier de 32 bits

Le champ État de résultat de désenregistrement indique le succès ou la raison de l'échec du désenregistrement.

Ses valeurs peuvent être :
0 : désenregistrement réussi
1 : erreur – inconnu
2 : erreur - contexte d'acheminement invalide
3 : erreur - permission refusée
4 : erreur - non enregistré
5 : erreur - ASP actuellement actif pour le contexte d'acheminement

 	3.7	Messages de maintenance du trafic d'ASP (ASPTM)
 	3.7.1	ASP Actif
Le message ASP actif est envoyé par un ASP pour indiquer à un homologue M3UA distant qu'il est prêt à traiter le trafic de signalisation pour un serveur d'application particulier. Le message ASP actif affecte seulement l'état de l'ASP pour les clés d'acheminement identifiées par les contextes d'acheminement, si il en est de présents.

Le message ASP actif contient les paramètres suivants :
Type de mode de trafic (facultatif)
Contexte d'acheminement (facultatif)
Chaîne d'INFO (facultatif)

Le format du message ASP actif est comme suit :

 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 = 0x0006          |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                       Contexte d'acheminement                 /
\                                                               \
+---------------+---------------+---------------+---------------+
|   Étiquette = 0x0004          |           Longueur            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                          Chaîne d'INFO                        /
\                                                               \
+---------------+---------------+---------------+---------------+

Type de mode de trafic : 32 bits (entier non signé). 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 le type de mode de trafic sont les suivantes :
1 : outrepasse
2 : partage de charge
3 : diffusion

Dans un contexte d'acheminement particulier, Outrepasse, Partage de charge, et Diffusion NE DEVRAIENT PAS être mélangés. La valeur Outrepasse indique que l'ASP fonctionne en mode Outrepasser, 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. En mode Diffusion, l'ASP va recevoir les mêmes messages que tous les autres ASP actuellement actifs.

Contexte d'acheminement : n entiers de 32 bits. Le paramètre facultatif Contexte d'acheminement contient (une liste) des entiers qui indexent le trafic du serveur d'application que l'ASP envoyeur est configuré/enregistré à recevoir. Il y a une relation biunivoque entre une entrée d'index et une clé d'acheminement de SGP ou un nom d'AS. Parce qu'un AS peut seulement apparaître dans une apparition de réseau, le paramètre Apparition de réseau n'est pas exigé dans le message ASP actif. Un processus de serveur d'application peut être configuré à traiter le trafic pour plus d'un serveur d'application logique. Du point de vue d'un ASP, un contexte d'acheminement définit une gamme de trafic de signalisation que l'ASP est actuellement configuré à recevoir du SGP. Par exemple, un ASP pourrait être configuré pour prendre en charge la signalisation pour plusieurs utilisateurs MTP3, identifiés par des gammes séparées de DPC/OPC/SI SS7.

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

 	3.7.2	Accusé de réception de ASP actif (ASP Active Ack)
Le message ASP Active Ack est utilisé pour accuser réception d'un message ASP actif reçu d'un homologue M3UA distant.
Le message ASP Active Ack contient les paramètres suivants :
Type de mode de trafic (facultatif)
Contexte d'acheminement  (facultatif)
Chaîne d'INFO (facultatif)
Le format du message ASP Active Ack est comme suit :

 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 = 0x0006         |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                       Contexte d'acheminement                 /
\                                                               \
+---------------+---------------+---------------+---------------+
|     É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 DUNA (voir au paragraphe 3.4.1).

La chaîne d'INFO dans un message ASP Active Ack est indépendante de la chaîne d'INFO dans le message ASP actif (c'est-à-dire, elle n'a pas à faire écho de la chaîne d'INFO reçue).

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

 	3.7.3	ASP Inactif
Le message ASP Inactif est envoyé par un ASP pour indiquer à un homologue M3UA distant qu'il n'est plus un ASP actif à utiliser dans la liste des ASP. Le message ASP Inactif affecte seulement l'état de l'ASP dans les clés d'acheminement identifiées par les contextes d'acheminement, si il en est de présents.

Le message ASP Inactif contient les paramètres suivants :
Contexte d'acheminement (facultatif)
Chaîne d'INFO (facultatif)

Le format pour les paramètres de message ASP Inactif est comme suit :

 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 = 0x0006          |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                       Contexte d'acheminement                 /
\                                                               \
+---------------+---------------+---------------+---------------+
|   Étiquette = 0x0004          |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                          Chaîne d'INFO                        /
\                                                               \
+---------------+---------------+---------------+---------------+

Le format et la description des paramètres facultatifs Contexte d'acheminement et Chaîne d'INFO sont les mêmes que pour le message ASP actif (voir au paragraphe 3.5.5.)

 	3.7.4	Accusé de réception d'ASP inactif (ASP Inactive Ack)
Le message ASP Inactif Ack est utilisé pour accuser réception d'un message ASP inactif reçu d'un homologue M3UA distant.

Le message ASP Inactif Ack contient les paramètres suivants :
Contexte d'acheminement (facultatif)
Chaîne d'INFO (facultatif)

Le format pour le message ASP Inactif Ack est comme suit :

 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 = 0x0006          |            Longueur           |
+---------------+---------------+---------------+---------------+
\                                                               \
/                       Contexte d'acheminement                 /
\                                                               \
+---------------+---------------+---------------+---------------+
|   É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 DUNA (voir au paragraphe 3.4.1).

La chaîne d'INFO dans un message ASP Inactif Ack est indépendante de la chaîne d'INFO dans le message ASP Inactif (c'est-à-dire, elle n'a pas à faire écho de la chaîne d'INFO reçue).

Le format du paramètre Contexte d'acheminement est le même que pour le message ASP Inactif (voir au paragraphe 3.7.3.)

 	3.8	Messages de gestion (MGMT)
 	3.8.1	Erreur
Le message d'erreur est utilisé pour notifier à un homologue un événement d'erreur associé à un message entrant. Par exemple, le type de message pourrait être inattendu dans l'état actuel, ou une valeur de paramètre pourrait être invalide. Les messages d'erreur NE DOIVENT PAS être générés en réponse à d'autres messages d'erreur.

Le message d'erreur contient les paramètres suivants :
Code d'erreur (obligatoire)
Contexte d'acheminement (obligatoire)*
Apparition de réseau (obligatoire)*
Codet affecté (obligatoire)*
Informations de diagnostic (conditionnel)

* Seulement obligatoire pour des codes d'erreur spécifiques.

Le format du message d'erreur est comme suit :

 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 = 0x0006         |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                        Contexte d'acheminement                /
\                                                               \
+---------------+---------------+---------------+---------------+
|    Étiquette - 0x0012         |          Longueur             |
+---------------+---------------+---------------+---------------+
|    Gabarit    |                   Codet affecté  1            |
+---------------+---------------+---------------+---------------+
\                                                               \
/                                ...                            /
\                                                               \
+---------------+---------------+---------------+---------------+
|    Gabarit    |             Codet affecté  n                  |
+---------------+---------------+---------------+---------------+
|    Étiquette = 0x0200         |         Longueur = 8          |
+---------------+---------------+---------------+---------------+
|                      Apparition de réseau                     |
+---------------+---------------+---------------+---------------+
|    Étiquette = 0x0007         |          Longueur             |
+---------------+---------------+---------------+---------------+
\                                                               \
/                    Informations de diagnostic                 /
\                                                               \
+---------------+---------------+---------------+---------------+

Code d'erreur : 32 bits (entier non signé). Le paramètre Code d'erreur indique la raison du message d'erreur. La valeur du paramètre d'erreur peut être une des suivantes :

0x01 : Version invalide
0x02 : Non utilisé dans M3UA
0x03 : Classe de message non prise en charge
0x04 : Type de message non pris en charge
0x05 : Type de mode de trafic non pris en charge
0x06 : Message inattendu
0x07 : Erreur de protocole
0x08 : Non utilisé dans M3UA
0x09 : Identifiant de flux invalide
0x0a : Non utilisé dans M3UA
0x0b : Non utilisé dans M3UA
0x0c : Non utilisé dans M3UA
0x0d : Refusé – blocage de gestion
0x0e : Identifiant d'ASP exigé
0x0f : Identifiant d'ASP invalide
0x10 : Non utilisé dans M3UA
0x11 : Valeur de paramètre invalide
0x12 : Erreur de champ de paramètre
0x13 : Paramètre inattendu
0x14 : État de destination inconnu
0x15 : Apparition de réseau invalide
0x16 : Paramètre manquant
0x17 : Non utilisé dans M3UA
0x18 : Non utilisé dans M3UA
0x19 : Contexte d'acheminement invalide
0x1a : Pas d'AS configuré pour l'ASP

L'erreur "Version invalide" est envoyée si un message avec une version non prise en charge est reçu. L'extrémité receveuse répond avec un message d'erreur, indiquant la version que le nœud receveur prend en charge, et le notifie à la gestion de couche.

L'erreur "Classe de message non prise en charge" est envoyée si un message avec une classe de message inattendue ou non prise en charge est reçu. Pour cette erreur, le paramètre Informations de diagnostic DOIT être inclus avec les 40  premiers octets du message en cause.

L'erreur "Type de message non pris en charge" est envoyée si un message avec un type de message inattendu ou non pris en charge est reçu. Pour cette erreur, le paramètre Informations de diagnostic DOIT être inclus avec les 40 premiers octets du message en cause.

L'erreur "Type de mode de trafic non pris en charge" est envoyé par un SGP si un ASP envoie un message ASP actif avec un type de mode de trafic non pris en charge ou un type de mode de trafic incohérent avec le mode présentement configuré pour le serveur d'application. Un exemple serait le cas où le SGP n'accepte pas le partage de charge.

L'erreur "Message inattendu" PEUT être envoyée si un message défini et reconnu est reçu qui n'est pas attendu dans l'état actuel (dans certains cas, l'ASP peut facultativement éliminer en silence le message et ne pas envoyer de message d'erreur). Par exemple, l'élimination en silence est utilisée par un ASP si il reçoit un message DATA d'un SGP alors qu'il est dans l'état ASP-INACTIVE. Si le message inattendu contient des contextes d'acheminement, les contextes d'acheminement DEVRAIENT être inclus dans le message d'erreur.

L'erreur "Erreur de protocole" est envoyée pour toute anomalie de protocole (c'est-à-dire, la réception d'un paramètre qui est syntaxiquement correct mais inattendu dans la situation actuelle).

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

L'erreur "Refusé – blocage de gestion" est envoyée quand un message ASP Up ASP actif est reçu et que la demande est refusée pour des raisons de gestion (par exemple, verrouillage de la gestion). Si cette erreur est en réponse à un message ASP actif, le ou les contextes d'acheminement dans le message ASP actif DEVRAIENT être inclus dans le message d'erreur.

L'erreur "Identifiant d'ASP exigé" est envoyée par un SGP en réponse à un message ASP Up qui ne contient pas de paramètre Identifiant d'ASP quand le SGP en exige un. L'ASP DEVRAIT renvoyer le message ASP Up avec un identifiant d'ASP.

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

L'erreur "Valeur de paramètre invalide" est envoyée si un message est reçu avec une valeur de paramètre invalide (par exemple, un message DUPU reçu avec une valeur de gabarit autre que "0".

Une "Erreur de champ de paramètre" serait envoyée si un message est reçu avec un paramètre ayant une mauvaise longueur de champ.

L'erreur "Paramètre inattendu" serait envoyée si un message contient un paramètre invalide.

L'erreur "État de destination inconnu" PEUT être envoyée si un DAUD est reçu à une SG s'enquérant de l'état de disponibilité/encombrement d'une destination et si la SG ne souhaite pas fournir l'état (par exemple, l'envoyeur n'est pas autorisé à connaître l'état). Pour cette erreur, le ou les codets invalides ou non autorisés DOIVENT être inclus avec l'apparition de réseau et/ou le contexte d'acheminement associés à ce ou ces codets.

L'erreur "Apparition de réseau invalide" est envoyée par un SGP si un ASP envoie un message avec une valeur d'apparition de réseau invalide (non configurée). Pour cette erreur, l'apparition de réseau invalide (non configurée) DOIT être incluse dans le paramètre Apparition de réseau.

L'erreur "Paramètre manquant" serait envoyée si un paramètre obligatoire n'était pas inclus dans un message. Cette erreur est aussi envoyée si un paramètre conditionnel n'est pas inclus dans le message mais est exigé dans le contexte du message reçu.

L'erreur "Contexte d'acheminement invalide" est envoyée si un message est reçu d'un homologue avec une valeur de contexte d'acheminement invalide (non configurée). Pour cette erreur, le ou les contextes d'acheminement invalides DOIVENT être inclus dans le message d'erreur.

L'erreur "Pas d'AS configuré pour l'ASP" est envoyée si un message est reçu d'un homologue sans un paramètre Contexte d'acheminement et que quels serveurs d'application sont référencés n'est pas connu par les données de configuration.

Informations de diagnostic : longueur variable. Quand elles sont incluses, les informations facultatives de diagnostic peuvent être toute information relevant de la condition d'erreur, pour aider à l'identification de la condition d'erreur. Les informations de diagnostic DEVRAIENT contenir le message en cause. Un paramètre Informations de diagnostic avec un paramètre de longueur zéro n'est pas considéré comme une erreur (cela signifie que le champ Longueur dans le TLV va être réglé à 4).

 	3.8.2	Notify
Le message Notify est utilisé pour fournir une indication autonome des événements M3UA à un homologue M3UA.

Le message Notify contient les paramètres suivants :
État (obligatoire)
Identifiant d'ASP (conditionnel)
Contexte d'acheminement (facultatif)
Chaîne d'INFO (facultatif)

Le format pour le message Notify est comme suit :

 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      |
+---------------+---------------+---------------+---------------+
|                       Identifiant d'ASP                       |
+---------------+---------------+---------------+---------------+
|   Étiquette = 0x0006          |             Longueur          |
+---------------+---------------+---------------+---------------+
\                                                               \
/                       Contexte d'acheminement                 /
\                                                               \
+---------------+---------------+---------------+---------------+
|   É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 Notify. Les valeurs valides sont :
1 : Changement d'état du serveur d'application (AS-State_Change)
2 : Autre

Informations d'état : 16 bits (entier non signé). Le paramètre Informations d'état contient des informations plus détaillées pour la notification, fondées sur la valeur du type d'état. Si le type d'état est AS-State_Change les valeurs d'informations d'état utilisées sont :
1 : Réservé
2 : Serveur d'application inactif (AS-INACTIVE)
3 : Serveur d'application actif (AS-ACTIVE)
4 : Serveur d'application en instance (AS-PENDING)

Ces notifications sont envoyées d'un SGP à un ASP lors d'un changement de l'é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, alors les valeurs d'informations d'état suivantes sont définies :
1 : Ressources d'ASP actives insuffisantes dans l'AS
2 : Autre ASP actif
3 : Défaillance d'ASP

Ces notifications ne sont pas fondées sur les rapports du SGP sur les changements d'état d'un ASP ou AS. Dans le cas de ressources d'ASP insuffisantes, le SGP indique à un ASP inactif dans l'AS qu'un autre ASP est exigé pour traiter la charge de l'AS (mode partage de charge ou diffusion). Pour le cas d'un autre ASP actif, un ASP est informé quand un autre ASP passe à l'état ASP-ACTIVE dans le mode Outrepasser. L'identifiant d'ASP (si disponible) de l'autre ASP DOIT être placé dans le message. Pour le cas de défaillance d'ASP, le SGP indique aux ASP de l'AS qu'un des ASP est défaillant. L'identifiant d'ASP (si il est disponible) de l'ASP défaillant DOIT être placé dans le message.

Le format et la description de l'identifiant d'ASP conditionnel sont les mêmes que pour le message ASP Up (voir au paragraphe 3.5.1). Le format et la description des paramètres Contexte d'acheminement et Chaîne d'INFO sont les mêmes que pour le message ASP actif (paragraphe 3.7.1)

 	4.	Procédures

La couche M3UA doit répondre aux diverses primitives locales qu'elle reçoit des autres couches, ainsi qu'aux messages qu'elle reçoit de la couche M3UA homologue. Cette Section décrit les procédures de M3UA en réponse à ces événements.

 	4.1	Procédures pour la prise en charge de l'utilisateur M3UA
 	4.1.1	Réception des primitives provenant de l'utilisateur M3UA
À réception à un ASP/IPSP d'une primitive de demande MTP-TRANSFER d'une couche supérieure, ou d'une fonction nodale d'inter fonctionnement à un SGP, la couche M3UA envoie un message DATA correspondant (voir la Section 3) à sa M3UA homologue. La M3UA homologue qui reçoit le message DATA envoie une primitive d'indication MTP-TRANSFER à la couche supérieure.

La fonction M3UA de distribution de message (voir au paragraphe 1.4.2.1) détermine le serveur d'application (AS) en comparant les informations dans la primitive de demande MTP-TRANSFER avec une clé d'acheminement provisionnée.

À partir de la liste des ASP dans le tableau d'AS, un ASP dans l'état ASP-ACTIVE est choisi et un message DATA est construit et produit sur l'association SCTP correspondante. Si plus d'un ASP est dans l'état ASP-ACTIVE (c'est-à-dire, que le trafic est à partage de charge à travers plus d'un ASP) un des ASP dans l'état ASP-ACTIVE est choisi dans la liste. Si les ASP sont en mode diffusion, tous les ASP actifs vont être sélectionnés, et le message va être envoyé à chaque ASP actif. L'algorithme de choix est selon la mise en œuvre mais pourrait, par exemple, être fondé sur un round robin ou sur le SLS CIC ou ISUP. L'algorithme de choix approprié doit être retenu, car il dépend des hypothèses de l'application et de la compréhension du degré de coordination d'état entre les ASP dans l'état ASP-ACTIVE dans l'AS.

De plus, le message doit être envoyé sur le flux SCTP approprié, là encore en prenant soin de satisfaire les besoins de séquençage de messages de l'application de signalisation. Les messages DATA DOIVENT être envoyés sur un flux SCTP autre qu'un flux '0'.

Quand il n'y a pas de correspondance de clé d'acheminement, ou seulement une correspondance partielle, pour un message SS7 entrant, un traitement par défaut PEUT être spécifié. Les solutions possibles sont de fournir un serveur d'application par défaut au SGP qui dirige tout le trafic non alloué à un (un ensemble) d'ASP par défaut, ou d'éliminer le message et donner une notification à la gestion de couche dans une primitive d'indication M-ERROR. Le traitement du trafic non alloué dépend de la mise en œuvre.

 	4.2	Réception des primitives de la gestion de couche
À réception de primitives de la gestion de couche locale, la couche M3UA va effectuer l'action demandée et fournir une primitive de réponse appropriée à la gestion de couche.

Une primitive de demande M-SCTP_ESTABLISH provenant de la gestion de couche à un ASP ou IPSP va initier l'établissement d'une association SCTP. La couche M3UA va tenter d'établir une association SCTP avec l'homologue M3UA distant par l'envoi d'une primitive SCTP-ASSOCIATE à la couche locale SCTP.

Quand une association SCTP a été établie avec succès, le SCTP va envoyer une primitive de notification SCTP-COMMUNICATION_UP à la couche locale M3UA. Au SGP ou IPSP qui a initié la demande, la couche M3UA va envoyer une primitive de confirmation M-SCTP_ESTABLISH à la gestion de couche quand l'établissement de l'association est achevé. À la couche M3UA homologue, une primitive d'indication M-SCTP_ESTABLISH est envoyée à la gestion de couche à l'achèvement réussi de l'établissement d'une association SCTP entrante.

Une primitive de demande M-SCTP_RELEASE provenant de la gestion de couche initie la suppression d'une association SCTP. La couche M3UA accomplit une suppression en douceur de l'association SCTP en envoyant une primitive SCTP-SHUTDOWN à la couche SCTP.

Quand la fermeture en douceur de l'association SCTP a été réalisée, la couche SCTP retourne une primitive de notification SCTP-SHUTDOWN_COMPLETE à la couche M3UA locale. À la couche M3UA qui a initié la demande, la couche M3UA va envoyer une primitive de confirmation M-SCTP_RELEASE à la gestion de couche quand la fermeture de l'association est achevée. À la couche M3UA homologue, une primitive d'indication M- SCTP_RELEASE est envoyée à la gestion de couche à l'interruption ou la fermeture réussie d'une association SCTP.

Une primitive de demande M-SCTP_STATUS prend en charge une interrogation de gestion de couche sur l’état local d'une association SCTP particulière. La couche M3UA transpose simplement la primitive de demande M-SCTP_STATUS en une primitive SCTP-STATUS à la couche SCTP. Quand le SCTP répond, la couche M3UA transpose les informations d'état de l'association dans une primitive de confirmation M-SCTP_STATUS. Aucun protocole d'homologue n'est invoqué.

Des transposition similaires de primitive de LM en M3UA en SCTP et/ou de SCTP en M3UA en LM peuvent être décrites pour les diverses autres primitives de couche supérieure SCTP dans la [RFC2960], comme INITIALIZE, SET PRIMARY, CHANGE HEARTBEAT, REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD, SET PROTOCOL PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, et NETWORK STATUS CHANGE.  Autrement, ces primitives SCTP de couche supérieure (et aussi d'état) peuvent être considérées, pour des besoins de modélisation, comme une interaction de gestion de couche directement avec la couche SCTP.

Les primitives d'indication M-NOTIFY et M-ERROR indiquent à la gestion de couche les informations de notification ou d'erreur contenues dans, respectivement, un Notify M3UA ou un message d'erreur reçu. Ces indications peuvent aussi être générées par des événement M3UA locaux.

Une primitive de demande M-ASP_STATUS prend en charge une interrogation de la gestion de couche sur l'état d'un ASP particulier local ou distant. La couche M3UA répond avec l'état dans une primitive de confirmation M-ASP_STATUS. Aucun protocole M3UA homologue n'est invoqué.

Une demande M-AS_STATUS prend en charge une interrogation de gestion de couche sur l'état d'un AS particulier. Le M3UA répond avec une primitive de confirmation M-AS_STATUS. Aucun protocole M3UA homologue n'est invoqué.

Les primitives de demande M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE, et M-ASP_INACTIVE permettent à la gestion de couche à un ASP d'initier des changements d'état. Lorsque ils sont achevés avec succès, une primitive de confirmation correspondante est fournie par la couche M3UA à la gestion de couche. Si une invocation est un échec, une primitive d'indication d'erreur est fournie dans la primitive. Cette demande résulte en des messages ASP Up, ASP Down, ASP Active, et ASP Inactive sortants pour l'homologue M3UA distant à un SGP ou IPSP.

 	4.2.1	Réception des messages de gestion d'homologue M3UA
Lors de changements d'état réussis résultant de la réception de messages ASP Up, ASP Down, ASP Active, et ASP Inactive provenant d'un homologue M3UA, la couche M3UA PEUT invoquer les primitives d'indications M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE, M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, et M-AS_DOWN correspondantes à la gestion de couche locale.

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

Tous les messages non de transfert et non SSNM, sauf BEAT et BEAT Ack, DEVRAIENT être envoyés avec une livraison en séquence pour assurer la conservation de leur ordre. Les messages ASPTM PEUVENT être envoyés sur un des flux utilisés pour porter le trafic de données relatif au ou aux contextes d'acheminement, pour minimiser les possibles pertes de message. Les messages BEAT et BEAT Ack PEUVENT être envoyés en utilisant une livraison dans le désordre et PEUVENT être envoyés sur tous les flux.

 	4.3	Gestion d'état d'AS et d'ASP/IPSP
La couche M3UA sur le SGP conserve l'état de chaque ASP distant, dans chaque serveur d'application dont l'ASP est configuré à recevoir le trafic, comme entrée à la fonction M3UA de distribution de message. De même, lorsque les IPSP utilisent M3UA en point à point, la couche M3UA dans un IPSP conserve l'état des IPSP distants.

Deux modèles d'IPSP sont définis comme suit :

1.	Modèle IPSP d'un seul échange (SE, Single Exchange). Un seul échange de messages ASPTM et ASPSM est nécessaire pour changer les états de IPSP. Cela signifie qu'un ensemble de demandes d'une extrémité et d'accusé de réception de l'autre côté vont suffire. La RK doit définir les deux côtés du flux de trafic. Chaque échange de messages ASPTM ou ASPSM peut être initié par l'un ou l'autre IPSP. Pour cet échange, l'IPSP initiateur suit les procédures décrites au paragraphe 4.3.1.

2.	Modèle de double échange IPSP (DE, Double Exchange). Un double échange de messages ASPTM et ASPSM est normalement nécessaire (le simple échange d'ASPM est facultatif comme simplification). Chaque échange de messages ASPTM ou ASPSM peut être initié par l'un ou l'autre IPSP. Les RK définissent le trafic à diriger sur l'homologue comme dans le modèle AS-SG. Donc, deux RK différentes sont généralement utilisées, une installée sur chaque homologue.
Quand on utilise le double échange pour les messages ASPSM, la gestion de la connexion dans les deux directions est considérée comme indépendante. Cela signifie que les connexions de l'IPSP-A à l'IPSP-B sont traitées indépendamment des connexions de l'IPSP-B à l'IPSP-A. Donc, il pourrait arriver qu'une seule des deux directions soit activée ou close, tandis que l'autre reste dans l'état où elle était.
Quand on utilise un seul échange d'ASPSM, ce qui est vu comme une simplification, seule la phase d'activation (messages ASPTM) est indépendante pour chacune des deux directions. Dans ce cas, il pourrait arriver que l'envoi de l'ASPSM de l'IPSP-A ou l'IPSP-B ait un effet sur toute la communication, comme il est défini dans la communication standard SG-AS.
À cause de ces différences, il devrait y avoir un accord sur la façon dont les messages ASPSM sont traités avant de commencer une communication DE-IPSP.

Afin d'assurer l'interopérabilité, une mise en œuvre de M3UA qui prend en charge la communication d'IPSP DOIT prendre en charge le modèle SE IPSP SE et PEUT mettre en œuvre le modèle DE IPSP.

Les états d'ASP/IPSP sont décrits au paragraphe 4.3.1.

Le paragraphe 4.3.2 décrit seulement le scénario SGP-ASP. Toutes les procédures qui se réfèrent à un AS desservi par des ASP sont aussi applicables aux AS desservis par des IPSP.

Le paragraphe 4.3.3 décrit seulement les procédures de gestion pour le scénario SGP-ASP. Les procédures de gestion correspondantes pour les IPSP sont directement impliquées.

Les paragraphes restants contiennent des considérations spécifiques d'IPSP.

 	4.3.1	États d'ASP/IPSP
L'état de chaque ASP/IPSP distant, dans chaque AS où il est configuré à fonctionner, est conservé dans la couche M3UA homologue (c'est-à-dire, respectivement dans le SGP ou IPSP homologue). L'état d'un ASP/IPSP particulier dans un AS particulier change à cause des événements. Les événements incluent :
* la réception de messages de la couche M3UA homologue à l'ASP/IPSP ;
* la réception de messages provenant de la couche M3UA homologue à d'autres ASP/IPSP dans l'AS (par exemple, un message ASP actif indiquant "Outrepasser") 
* la réception d'indications de la couche SCTP ; et
* une intervention de la gestion locale.

Le diagramme de transitions d'état ASP/C-IPSP/D-IPSP est montré à la Figure 3. Les états possibles d'un ASP/D-IPSP/C-IPSP sont :

ASP-DOWN : l'homologue M3UA distant à l'ASP/IPSP est indisponible, et/ou l'association SCTP qui s'y rapporte est hors service. Initialement, tous les ASP/IPSP vont être dans cet état. Il NE DEVRAIT PAS être envoyé de message M3UA à un ASP/IPSP dans cet état, à l'exception des messages Heartbeat, ASP Down Ack, et Error.

ASP-INACTIVE : l'homologue M3UA distant à l'ASP/IPSP est disponible (et l'association SCTP qui s'y rapporte est ouverte) mais le trafic d'application est arrêté. Dans cet état, aucun message DATA ou SSNM NE DEVRAIT être envoyé à l'ASP/IPSP pour l'AS pour laquelle le ASP/IPSP est inactif.

ASP-ACTIVE : l'homologue M3UA distant à l'ASP/IPSP est disponible et le trafic d'application est actif (pour un contexte d'acheminement ou ensemble de contextes d'acheminement particuliers).

SCTP CDI : le SCTP CDI note l'indication de communication morte (CDI, Communication Down Indication) de la couche SCTP locale au protocole de couche supérieure (M3UA) sur un SGP. La couche SCTP locale va envoyer cette indication quand elle détecte la perte de connexité à la couche SCTP homologue de l'ASP. La SCTP CDI est comprise comme une notification SHUTDOWN_COMPLETE ou comme une notification COMMUNICATION_LOST provenant de la couche SCTP.

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

                                         +--------------+
               +-------------------------|  ASP-ACTIVE  |
               | Les autres ASP/ +-------|              |
               |  IPSP dans l'AS |       +--------------+
               |  outrepassent   |           ^     |
               |                 |    ASPAC/ |     | ASPIA/[ASPIA-Ack]
               |                 |[ASPAC-Ack]|     |
               |                 |           |     v
               |                 |       +--------------+
               |                 +------>| ASP-INACTIVE |
               |                         |              |
               |                         +--------------+
               |                             ^     |
        ASPDN/ |                             |     | ASPDN/[ASPDN-Ack /]
   [ASPDN-Ack/]|                      ASPUP/ |     | 
     SCTP CDI/ |                 [ASPUP-Ack] |     | SCTP CDI/SCTP RI
     SCTP RI   |                             |     | 
               |                             |     v
               |                         +--------------+
               +------------------------>|   ASP-DOWN   |
                                         |              |
                                         +--------------+

Figure 3 : Diagramme de transition d'état d'ASP, par AS

Les transitions sont décrites comme résultat de la réception de messages ASP*M ou autres événements. Dans certaines transitions, il y a des messages entre crochets. Cela signifie que pour un certain nœud la transition d'état va être différente, selon son rôle, si il génère ou non le message de demande ASP*M (c'est-à-dire, ASPUP, ASPAC, ASPIA ou ASPDN) ou si il le reçoit simplement. Dans une architecture d'homologue à homologue (IPSP) ce rôle peut changer entre les homologues.

Les transitions qui ne sont pas entre crochets sont valides pour retracer les états des ASP et IPSP qui envoient le message  de demande ASP*M au nœud homologue.

La transition entre crochets peut être utilisée dans un ASP ou dans l'IPSP qui reçoit une demande ASP*M pour retracer les états respectivement de SGP/IPSP. Il peut y avoir un automate à états de SGP par AS aux ASP.

Ensuite, les transitions entre crochets peuvent être utilisées pour la communication dans le modèle IPSP DE (DE-IPSP) et sont relatives aux cas particuliers quand juste un échange de messages ASP*M est nécessaire, comme suit :

-	Messages ASPSM. Quand des messages ASPSM sont échangés en utilisant seulement un échange (une seule demande et un accusé de réception). Exemple (voir au paragraphe 5.6.2) : chaque fois qu'un DE-IPSP prend le rôle directeur pour commencer la communication avec un homologue DE-IPSP, il envoie un message ASP Up au DE-IPSP homologue. L'homologue PEUT considérer les DE-IPSP initiateurs comme étant dans l'état ASP-INACTIVE, car il a déjà envoyé un message, et répond avec ASP Up Ack. À réception de cette réponse du DE-IPSP initiateur, il PEUT aussi considérer que l'homologue est dans l'état ASP-INACTIVE, car il a bien répondu. Donc, un second échange de message ASP Up débuté par le DE-IPSP homologue pourrait être évité. Dans ce cas, la réception du ASP Up Ack va donner lieu à un changement d'état.

-	Messages ASPTM. Lors de l'envoi de messages ASPTM pour activer/désactiver tout le trafic indépendamment des clés d'acheminement en ne spécifiant aucune RC, un seul échange pourrait être suffisant.

 	4.3.2	États d'AS
L'état de l'AS est conservé dans la couche M3UA sur les SGP. L'état d'un AS change avec les événements. Ces événements incluent :
* les transitions d'état d'ASP
* les déclenchements de temporisateur de récupération

Les états possibles d'un AS sont :

AS-DOWN : le serveur d'application est indisponible. Cet état implique que tous les ASP concernés sont dans l'état ASP-DOWN pour cet AS. Initialement l'AS va être dans cet état. Un serveur d'application est dans l'état AS-DOWN quand il est retiré d'une configuration.

AS-INACTIVE : le serveur d'application est disponible, mais aucun trafic d'application n'est actif. Un ou plusieurs ASP en rapports sont dans l'état ASP-INACTIVE, et/ou le nombre d'ASP en rapports dans l'état ASP-ACTIVE n'a pas atteint n (n est le nombre d'ASP dont il est exigé qu'ils soient dans l'état ASP-ACTIVE avant que l'AS puisse passer à AS-ACTIVE ; n = 1 pour le mode de trafic Outrepasser) pour cet AS. Le temporisateur de récupération T(r) ne fonctionne pas ou a expiré.

AS-ACTIVE : le serveur d'application est disponible et le trafic d'application est actif. L'AS passe à cet état après AS- INACTIVE et avoir n ASP (n est le nombre d'ASP exigés dans l'état ASP-ACTIVE avant que l'AS puisse passer à AS-ACTIVE ; n = 1 pour le mode de trafic Outrepasser) dans l'état ASP-ACTIVE ou après avoir atteint AS-ACTIVE et gardé un ou plusieurs ASP dans l'état ASP-ACTIVE. Quand un ASP est considéré comme suffisant pour traiter le trafic (démarrage en douceur) l'AS dans l'état AS-INACTIVE PEUT passer à AS-ACTIVE aussitôt que le premier ASP passe à l'état ASP-ACTIVE.

AS-PENDING : un ASP actif est passé à ASP-INACTIVE ou ASP DOWN et il était le dernier ASP actif restant dans l'AS. Un temporisateur de récupération T(r) DEVRAIT être démarré, et tous les messages de signalisation entrants DEVRAIENT être mis en file d'attente par le SGP. Si un ASP devient ASP-ACTIVE avant l'expiration de T(r), l'AS passe à l'état AS-ACTIVE, et tous les messages de la file d'attente vont être envoyés à l'ASP. Si T(r) expire avant qu'un ASP passe à ASP-ACTIVE, et si le SGP n'a pas de solution de remplacement, le SGP peut arrêter de mettre les messages en file d'attente et éliminer tous les messages mis précédemment en file d'attente. L'AS va passer à l'état AS-INACTIVE si au moins un ASP est dans l'état ASP-INACTIVE ; autrement, il va passer à l'état AS-DOWN.

La Figure 4 montre un exemple d'automate à états d'AS pour le cas où les données d'AS/ASP sont préconfigurées et c'est un modèle de redondance n+k. Dans d'autres cas où les données de configuration d'AS/ASP sont créées dynamiquement, il y aurait des différences dans l'automate à états, en particulier à la création de l'AS.

        +----------+          IA2AC              +-------------+
        |    AS-   |---------------------------->|     AS-     |
        | INACTIVE |                             |   ACTIVE    |
        |          |<-----------                 |             |
        +----------+            \                +-------------+
           ^   |                 \                    ^   |
           |   | IA2DN            \ PN2IA             |   | AC2PN
           |   |                   \                  |   |
     DN2IA |   |                    \          PN2AC  |   |
           |   v                     \                |   v
        +----------+                  \          +-------------+
        |          |                   ----------|             |
        | AS-DOWN  |                             | AS-PENDING  |
        |          |                  PN2DN      | (en file    |
        |          |<----------------------------|  d'attente) |
        +----------+                             +-------------+

Figure 4 : Diagramme de transitions d'état d'AS 

DN2IA : un ASP passe de l'état ASP-DOWN à l'état ASP-INACTIVE.

IA2DN : le dernier ASP en ASP-INACTIVE passe à ASP-DOWN, faisant que tous les ASP sont dans l'état ASP-DOWN.

IA2AC : un ASP passe à ASP-ACTIVE, faisant passer le nombre d'ASP dans l'état ASP-ACTIVE à n. Dans un cas particulier de démarrage en douceur, cette transition PEUT être faite quand le premier ASP passe à l'état ASP-ACTIVE.

AC2PN : le dernier ASP dans l'état ASP-ACTIVE passe à l'état ASP-INACTIVE ou ASP-DOWN, causant la chute du nombre d'ASP dans l'état ASP-ACTIVE en dessous de 1.

PN2AC : un ASP passe à ASP-ACTIVE.

PN2IA : expiration de T(r) ; un ASP est dans l'état ASP-INACTIVE mais aucun ASP n'est dans l'état ASP-ACTIVE.

PN2DN : expiration de T(r) ; tous les ASP sont dans l'état ASP-DOWN.

Un AS devient AS-ACTIVE juste après que n ASP atteignent l'état ASP-ACTIVE durant la phase de démarrage (sauf cas de démarrage en douceur). Une fois que le trafic s'écoule, un AS garde l'état AS-ACTIVE jusqu'à ce que le dernier ASP passe à un autre état différent de ASP-ACTIVE, évitant des perturbations inutiles du trafic tant qu'il y a des ASP disponibles (cela suppose que le système ne va pas toujours être exposé à la charge maximum).

Il y a d'autres cas où les données de configuration d'AS/ASP sont créées de façon dynamique. Dans ces cas, il va y avoir des différences dans l'automate à états, en particulier à la création de l'AS. Par exemple, lorsque les données de configuration d'AS/ASP ne sont pas créées avant l'enregistrement du premier ASP, l'état AS-INACTIVE est entré directement au énième REG REQ réussi à partir d'un ASP appartenant à cet AS. Un autre exemple est lorsque les données de configuration d'AS/ASP ne sont pas créées jusqu'à ce que le énième ASP réussisse à entrer dans l'état ASP-ACTIVE. Dans ce dernier cas, il entre directement dans l'état AS-ACTIVE.

 	4.3.3	Procédures de gestion M3UA pour les primitives
Avant l'établissement d'une association SCTP, l'état de l'ASP au SGP et à l'ASP est supposé être ASP-DOWN.

Une fois que l'association SCTP est établie (voir au paragraphe 4.2) en supposant que l'utilisateur local M3UA est prêt, la fonction locale de maintenance d'ASP M3UA (ASPM, ASP Maintenance) va initier les procédures pertinentes, en utilisant les messages ASP Up/ASP Down/ASP Active/ASP Inactive pour porter l'état de l'ASP au SGP (voir au paragraphe 4.3.4).

Si la couche M3UA reçoit ensuite une primitive d'indication SCTP-COMMUNICATION_DOWN ou SCTP-RESTART de la couche SCTP sous-jacente, elle va informer la gestion de couche en invoquant la primitive d'indication M-SCTP_STATUS. L'état de l'ASP va passer à ASP-DOWN. À un ASP, l'utilisateur MTP3 va être informé de l'indisponibilité de toute destination SS7 affectée par l'utilisation des primitives d'indication MTP-PAUSE.

Dans le cas de SCTP-COMMUNICATION_DOWN, le client SCTP PEUT essayer de rétablir l'association SCTP. Cela PEUT être fait automatiquement par la couche M3UA, ou la gestion de couche PEUT la rétablir 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é être dans l'état ASP-DOWN par ses homologues M3UA. L'ASP, si il doit récupérer, doit commencer toute récupération avec la procédure ASP-Up.

 	4.3.4	Procédures d'ASPM pour les messages d'homologue à homologue
 	4.3.4.1	Procédures d'ASP Up
Après qu'un ASP a réussi à établir une association SCTP avec un SGP, le SGP attend que l'ASP envoie un message ASP Up, indiquant que l'ASP M3UA homologue est disponible. L'ASP est toujours l'initiateur du message ASP Up. Cette action PEUT être initié à l'ASP par une primitive de demande M-ASP_UP provenant de la gestion de couche ou PEUT être initiée automatiquement par une fonction de gestion M3UA.

Quand un message ASP Up est reçu à un SGP et, qu'en interne, l'ASP distant est dans l'état ASP-DOWN et n'est pas considéré comme verrouillé pour des raisons de gestion locale, le SGP marque l'ASP distant dans l'état ASP-INACTIVE et informe la gestion de couche avec une primitive d'indication M-ASP_Up. Si le SGP a connaissance, via les données de configuration courantes, des serveurs d'application avec lesquels l'ASP est configuré à fonctionner, le SGP met à jour l'état de l'ASP à ASP-INACTIVE dans chaque AS dont il est membre.

Autrement, le SGP peut déplacer l'ASP dans un réservoir d'ASP inactifs disponibles pour une future configuration au sein des serveurs d'application, déterminée dans une procédure ultérieure de demande d'enregistrement ou d'ASP actif. Si le message ASP Up contient un identifiant d'ASP, le SGP devrait sauvegarder l'identifiant d'ASP pour cet ASP. Le SGP DOIT envoyer un message ASP Up Ack en réponse à un message ASP Up reçu même si l'ASP est déjà marqué comme ASP-INACTIVE au SGP.

Si pour une raison locale (par exemple, un verrouillage de gestion) le SGP ne peut pas répondre avec un message ASP Up Ack, le SGP répond à un message ASP Up avec un message d'erreur avec la raison "Refusé – blocage de gestion".

À l'ASP, le message ASP Up Ack reçu n'est pas acquitté. La gestion de couche est informée avec une primitive de confirmation M-ASP_UP.

Quand l'ASP envoie un message ASP Up, il lance le temporisateur T(ack). Si l'ASP ne reçoit pas de réponse à un message ASP Up dans le délai de T(ack), l'ASP PEUT relancer T(ack) et renvoyer des messages ASP Up jusqu'à ce qu'il reçoive un message ASP Up Ack. T(ack) est provisionnable, avec par défaut 2 secondes. Autrement, la retransmission des messages ASP Up PEUT être mise sous le contrôle de la gestion de couche. 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 ASP Up Ack avant d'envoyer tout autre message M3UA (par exemple, ASP Active ou REG REQ). Si le SGP reçoit un autre message M3UA avant de recevoir un message ASP Up (autre que ASP Down ; voir au paragraphe 4.3.4.2) le SGP PEUT les éliminer.

Si un message ASP Up est reçu et, qu'en interne, l'ASP distant est dans l'état ASP-ACTIVE, un message ASP Up Ack est retourné, ainsi qu'un message d'erreur ("Message inattendu"). De plus, l'état de l'ASP distant est changé en ASP-INACTIVE dans tous les serveurs d'application pertinents, et toutes les clés d'acheminement enregistrées sont considérées comme désenregistrées.

Si un message ASP Up est reçu et, qu'en interne, l'ASP distant est déjà dans l'état ASP-INACTIVE, un message ASP Up Ack est retourné, et aucune autre action n'est entreprise.

Si l'ASP reçoit un message ASP Up Ack inattendu, l'ASP devrait se considérer comme étant dans l'état ASP-INACTIVE. Si l'ASP n'était pas dans l'état ASP-INACTIVE, il DEVRAIT envoyer un message d'erreur et ensuite initier les procédures pour revenir lui-même à son état antérieur.

 	4.3.4.1.1	Contrôle de version M3UA et ASP Up
Si un message ASP Up avec une version non prise en charge est reçu, l'extrémité receveuse répond avec un message d'erreur, indiquant la version que le nœud receveur prend en charge et le notifie à la gestion de couche. Voir des développements sur cette question au paragraphe 4.8.

 	4.3.4.1.2	Considérations d'IPSP (ASP Up)
Un IPSP peut être considéré dans l'état ASP-INACTIVE après la réception d'un ASP Up ou ASP Up Ack provenant de lui. Un IPSP peut être considéré dans l'état ASP-DOWN après qu'il a reçu de lui un ASP Down ou ASP Down Ack. L'IPSP peut informer la gestion de couche du changement d'état de l'IPSP distant en utilisant l'indication M-ASP_UP ou M-ASP_DN ou des primitives de confirmation.

Autrement, quand on utilise le modèle IPSP DE, un échange de messages ASP Up provenant de chaque extrémité DOIT être effectué. Quatre messages sont nécessaires pour l'achever.

Si pour une raison locale (par exemple, un verrouillage de gestion) un IPSP ne peut pas répondre à un message ASP Up avec un message ASP Up Ack, il répond à un message ASP Up par un message d'erreur avec la raison "Refusé – blocage de gestion" et laisse l'IPSP distant dans l'état ASP-DOWN.

 	4.3.4.2	Procédures d'ASP-Down
L'ASP va envoyer un message ASP Down à un SGP quand l'ASP souhaite être retiré du service dans tous les serveurs d'application dont il est membre et ne plus recevoir de messages DATA, SSNM ou ASPTM. Cette action PEUT être initiée à l'ASP par une primitive de demande M-ASP_DOWN provenant de la gestion de couche ou PEUT être initiée automatiquement par une fonction de gestion M3UA.

Si l'ASP est retiré de façon permanente de tous les AS est une fonction de la gestion de configuration. Dans le cas où l'ASP avait précédemment utilisé les procédures d'enregistrement (voir au paragraphe 4.4.1) pour s'enregistrer dans les serveurs d'application mais ne s'est pas désenregistré de tous avant d'envoyer le message ASP Down, le SGP DOIT considérer que l'ASP est désenregistré de tous les serveurs d'application dont il est encore membre.

Le SGP marque l'ASP comme ASP-DOWN, informe la gestion de couche avec une primitive d'indication M-ASP_Down, et retourne un message ASP Down Ack à l'ASP.

Le SGP DOIT envoyer un message ASP Down Ack en réponse à un message ASP Down reçu de l'ASP même si l'ASP est déjà marqué comme ASP-DOWN au SGP.

À l'ASP, le message ASP Down Ack reçu n'est pas acquitté. La gestion de couche est informée avec une primitive de confirmation M-ASP_DOWN. Si l'ASP reçoit un ASP Down Ack sans avoir envoyé un message ASP Down, l'ASP devrait maintenant se considérer comme étant dans l'état ASP-DOWN.

Si l'ASP était précédemment dans l'état ASP-ACTIVE ou ASP-INACTIVE, il devrait alors initier les procédures pour retourner dans son état précédent.

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

 	4.3.4.3	Procédures d'ASP Active 
À tout moment après la réception par l'ASP d'un message ASP Up Ack du SGP ou IPSP, l'ASP PEUT envoyer un message ASP Active au SGP, indiquant que l'ASP est prêt à commencer le traitement du trafic. Cette action PEUT être initiée à l'ASP par une primitive de demande M-ASP_ACTIVE de la gestion de couche ou PEUT être initiée automatiquement par une fonction de gestion M3UA. Dans le cas où un ASP souhaite traiter le trafic pour plus d'un serveur d'application à travers une association SCTP commune, le message ASP actif DEVRAIT contenir une liste d'un ou plusieurs contextes d'acheminement pour indiquer à quels serveurs d'application le message ASP actif s'applique. Il n'est pas nécessaire que l'ASP inclue tous les contextes d'acheminement qui l’intéressent dans un seul message ASP actif, demandant donc de devenir actif dans tous les contextes d'acheminement au même moment. Plusieurs messages ASP Actif PEUVENT être utilisés pour s'activer au sein des serveurs d'application de façon indépendante, ou dans des ensembles de ces serveurs.

Dans le cas où un message ASP actif ne contient pas de paramètre Contexte d'acheminement, le receveur doit savoir, via les données de configuration, de quels serveurs d'application l'ASP est membre.

Pour les serveurs d'application pour lesquels l'ASP peut être activé avec succès, le SGP ou IPSP répond avec un ou plusieurs messages ASP Active Ack, incluant le ou les contextes d'acheminement associés et reflétant toute valeur de type de mode de trafic présente dans le message ASP actif qui s'y rapporte. Le paramètre Contexte d'acheminement DOIT être inclus dans le ou les messages ASP Active Ack si le message ASP actif reçu contenait des contextes d'acheminement. Selon la demande de type de mode de trafic dans le message ASP actif, ou les données de configuration locales si il n'y a pas de demande, le SGP passe l'ASP à l'état de trafic d'ASP correct au sein du ou des serveurs d'application associés. La gestion de couche est informée avec une indication M-ASP_Active. Si le SGP ou IPSP reçoit des messages Data avant qu'un message ASP actif soit reçu, le SGP ou IPSP PEUT les éliminer. En envoyant un message ASP Active Ack, le SGP ou IPSP est maintenant prêt à recevoir et envoyer du trafic pour le ou les contextes d'acheminement concernés. L'ASP NE DEVRAIT PAS envoyer de messages Data ou SSNM pour le ou les contextes d'acheminement concernés avant d'avoir reçu un message ASP Active Ack, ou il va risquer la perte du message.

Plusieurs messages ASP Active Ack PEUVENT être utilisés en réponse à un message ASP actif contenant plusieurs contextes d'acheminement, ce qui permet au SGP ou IPSP d'accuser réception indépendamment du message ASP actif pour les différents (ensembles de) contextes d'acheminement.

Le message ASP actif va avoir une réponse de la façon suivante en fonction de la présence/besoin du paramètre RC :

-	Si le paramètre RC est inclus dans le message ASP actif et si la RK correspondante a été définie précédemment (par configuration statique ou par enregistrement dynamique) le nœud homologue DOIT répondra avec un message ASP Active Ack. Si pour une raison locale (par exemple, verrouillage de gestion) le SGP répond à un message ASP actif par un message d'erreur avec la raison "Refusé – blocage de gestion".

-	Si le paramètre RC est inclus dans le message ASP actif et si une RK correspondante n'a pas été définie précédemment (par configuration statique ou par enregistrement dynamique) l'homologue DOIT répondre avec un message ERROR avec le code d'erreur "Pas d'AS configuré pour l'ASP".

-	Si (1) le paramètre RC n'est pas inclus dans le message ASP actif, (2) si il y a des RK définies (par configuration statique ou par enregistrement dynamique) et (3) si le RC n'est pas obligatoire, le nœud homologue DEVRAIT répondre avec un message ASP Active Ack et activer toutes les RK qu'il a définies pour cet ASP spécifique.

-	Si (1) le paramètre RC n'est pas inclus dans le message ASP actif, (2) il y a des RK définies (par configuration statique ou par enregistrement dynamique), (3) et RC est obligatoire, le nœud homologue DOIT répondre avec un message ERROR avec le code d'erreur "Paramètre manquant".

-	Si (1) le paramètre RC n'est pas inclus dans le message ASP actif, (2) il y a des RK définies (par configuration statique ou par enregistrement dynamique) et (3) RC n'est pas obligatoire, le nœud homologue DOIT répondre avec un message ASP Active Ack si il est prêt à traiter le trafic ; autrement, il va envoyer un message ERROR avec le code d'erreur "Pas d'AS configuré pour l'ASP" (ce qui signifie qu'il n'est pas prêt à devenir actif).

-	Si le paramètre RC n'est pas inclus dans le message ASP actif et si il n'y a pas de RK définie, le nœud homologue DEVRAIT répondre avec un message d'erreur avec le code d'erreur "Contexte d'acheminement invalide".

Indépendamment du RC, le SGP DOIT envoyer un message ASP Active Ack en réponse à un message ASP actif reçu de l'ASP, si l'ASP est déjà marqué dans l'état APS-ACTIVE.

À l'ASP, le message ASP Active Ack reçu n'est pas acquitté. La gestion de couche est informée avec une primitive de confirmation M-ASP_ACTIVE. Il est possible que l'ASP reçoive des messages Data avant le message ASP Active Ack car les messages ASP Active Ack et Data d'une SG ou d'un IPSP peuvent être envoyés sur des flux SCTP différents. Une perte de message est possible, car l'ASP ne se considère pas comme étant dans l'état ASP-ACTIVE avant d'avoir reçu le message ASP Active Ack.

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

Il y a trois modes de traitement de trafic de serveur d'application dans la couche M3UA SGP : Outrepasser, Partage de charge et Diffusion. Quand il est inclus, le paramètre Type de mode de trafic dans le message ASP actif indique le mode de traitement du trafic à utiliser dans un serveur d'application particulier. Si le SGP détermine que le mode indiqué dans un message ASP actif n'est pas pris en charge ou est incompatible avec le mode actuellement configuré pour l'AS, le SGP répond avec un message d'erreur ("Non pris en charge - mode de traitement du trafic invalide"). Si le mode de traitement du trafic du serveur d'application n'est pas toujours connu via les données de configuration, alors le mode de traitement du trafic indiqué dans le premier message ASP actif causant la transition de l'état du serveur d'application à AS-ACTIVE PEUT être utilisé pour établir le mode.

Dans le cas d'un AS en mode Outrepasser, la réception d'un message ASP actif à un SGP cause la (re)direction de tout le trafic pour l'AS à l'ASP qui a envoyé le message ASP actif. Tout AS précédemment actif dans l'AS est maintenant considéré comme étant dans l'état ASP-INACTIVE et NE DEVRAIT PLUS recevoir de trafic provenant du SGP au sein de l'AS. Le SGP ou IPSP DOIT alors envoyer un message Notify ("Autre ASP_Active") à l'ASP précédemment actif dans l'AS et DEVRAIT arrêter le trafic de/vers cet ASP. L'ASP qui reçoit ce Notify DOIT se considérer maintenant dans l'état ASP-INACTIVE, si il ne le sait pas déjà via la communication inter-ASP avec l'ASP outrepassant.

Dans le cas d'un AS en mode de partage de charge, la réception d'un message ASP actif à un SGP ou IPSP cause la direction du trafic sur l'ASP qui envoie le message ASP actif, en plus de tous les autres ASP qui sont actuellement actifs dans l'AS. L'algorithme au SGP 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 fondé sur un round-robin ou sur des informations dans le message Data (par exemple, la valeur du SLS, SCCP SSN, ou ISUP CIC). Un SGP ou IPSP, à réception d'un message ASP actif pour le premier ASP dans un AS en partage de charge, PEUT choisir de ne pas diriger le trafic sur un ASP nouvellement actif avant qu'il ait déterminé qu'il y a des ressources suffisantes pour traiter la charge attendue (par exemple, jusqu'à ce qu'il y ait "n" ASP dans l'état ASP-ACTIVE dans l'AS). Dans ce cas, le SGP ou l'IPSP DEVRAIT retarder le Notify (AS-ACTIVE) jusqu'à ce qu'il y ait des ressources suffisantes.

Pour le cas de redondance n+k, les ASP qui sont dans cet AS devraient coordonner entre eux le nombre d'ASP actifs dans l'AS et devraient ne commencer à envoyer du trafic qu'après que n ASP sont actifs. Tous les ASP au sein d'un AS en mode partage de charge doivent être capables de traiter tout message Data reçu pour l'AS, pour traiter toute reprise sur défaillance potentielle ou rééquilibrage de la charge offerte.

Dans le cas d'un AS en mode Diffusion, la réception d'un message ASP actif à un SGP ou IPSP cause la direction du trafic sur l'ASP qui envoie le message ASP actif, en plus de tous les autres ASP qui sont actuellement actifs dans l'AS. L'algorithme au SGP pour la diffusion du trafic au sein d'un AS à tous les ASP actifs est un simple algorithme de diffusion, où chaque message est envoyé à chaque ASP actif.

Dans les phases de démarrage ou de redémarrage, un SGP ou IPSP, à réception d'un message ASP actif pour le premier ASP dans un AS en partage de charge, NE DEVRAIT PAS diriger le trafic sur un ASP nouvellement actif avant d'avoir déterminé si il y a des ressources suffisantes pour traiter la charge attendue (par exemple, jusqu'à ce qu'il y ait "n" ASP dans l'état ASP-ACTIVE dans l'AS). Dans ce cas, le SGP ou IPSP DEVRAIT retarder le Notify (AS-ACTIVE) jusqu'à ce qu'il y ait des ressources suffisantes.

Un SGP ou IPSP, à réception d'un message ASP actif pour le premier ASP dans un AS en diffusion, PEUT choisir de ne pas diriger le trafic sur un ASP nouvellement actif jusqu'à ce qu'il ait déterminé qu'il y a des ressources suffisantes pour traiter la charge attendue (par exemple, jusqu'à ce qu'il y ait "n" ASP dans l'état ASP-ACTIVE dans l'AS). Dans ce cas, le SGP ou IPSP DEVRAIT retarder le Notify (AS-ACTIVE) jusqu'à ce qu'il y ait des ressources suffisantes.

Pour le cas de redondance n+k , les ASP qui sont dans cet AS devraient coordonner entre eux le nombre d'ASP actifs dans l'AS et devraient ne commencer d'envoyer du trafic qu'après que n ASP sont actifs.

Chaque fois qu'un ASP dans un AS en mode diffusion devient ASP-ACTIVE, le SGP DOIT étiqueter le premier message DATA en diffusion dans chaque flux de trafic avec un paramètre Identifiant de corrélation univoque. L'objet de cet identifiant est de permettre à l'ASP nouvellement actif de synchroniser son traitement du trafic dans chaque flux de trafic avec les autres ASP dans le groupe de diffusion.

 	4.3.4.3.1	Considérations d'IPSP (ASP Active)
N'importe lequel des IPSP peut initier la communication. Quand un IPSP reçoit un ASP Active, il devrait marquer l'homologue comme ASP-ACTIVE et retourner un message ASP Active Ack. Un ASP qui reçoit un message ASP Active Ack peut marquer l'homologue comme ASP-Active, si il n'est pas déjà dans l'état ASP-ACTIVE.

Autrement, quand on utilise le modèle IPSP DE, un échange de messages ASP Active entre chaque extrémité DOIT être effectué. Quatre messages sont nécessaires pour son achèvement.

 	4.3.4.4	Procédures d'ASP Inactive
Quand un ASP souhaite cesser de recevoir du trafic au sein d'un AS ou veut initier le processus de désactivation, il envoie un message ASP Inactive au SGP ou IPSP.

Un message ASP Inactive DOIT toujours recevoir une réponse de la part de l'homologue (bien que d'autres messages puissent être envoyés entre temps) de la façon suivante :

-	Si le message ASP Inactive reçu contient un paramètre RC et si la RK correspondante est définie (par configuration statique ou par enregistrement dynamique) le SGP/IPSP DOIT répondre avec un message ASP Inactive Ack.

-	Si le message ASP Inactive reçu contient un paramètre RC qui n'est pas défini (par configuration statique ou par enregistrement dynamique) le SGP/IPSP DOIT répondre avec un message ERROR avec le code d’erreur "Contexte d'acheminement invalide".

-	Si le message ASP Inactive reçu ne contient pas de paramètre RC et si la RK est définie (par configuration statique ou par enregistrement dynamique) le SGP/IPSP doit changer l'état de l'ASP/IPSP en ASP-INACTIVE dans tous les AS qu'il dessert et DOIT répondre avec un message ASP Inactive Ack.

-	Si le message ASP Inactive reçu ne contient pas de paramètre RC et si la RK n'est pas définie (par configuration statique ou par enregistrement dynamique) le SGP/IPSP DOIT répondre avec un message ERROR avec le code d'erreur "Pas d'AS configuré pour l'ASP".

L'action d'envoi du message ASP Inactive PEUT être initié à l'ASP par une primitive de demande M-ASP_INACTIVE provenant de la gestion de couche ou PEUT être initié automatiquement par une fonction de gestion M3UA. Dans le cas où un ASP traite le trafic pour plus d'un serveur d'application à travers une association SCTP commune, le message ASP Inactive contient un ou plusieurs contextes d'acheminement pour indiquer pour quels serveurs d'application s'applique le message ASP Inactive.

Dans le cas où un message ASP Inactive ne contient pas un paramètre Contexte d'acheminement, le receveur doit savoir, via les données de configuration, de quels serveurs d'application l'ASP est membre et faire ensuite passer l'ASP à l'état ASP-INACTIVE dans tous les serveurs d'application.

Dans le cas d'un AS en mode Outrepasser, où un autre ASP a déjà préempté le trafic au sein de l'AS avec un message ASP Active ("Outrepasser") l'ASP qui envoie le message ASP Inactive est déjà considéré comme étant dans l'état ASP-INACTIVE par le SGP. Un message ASP Inactive Ack est envoyé à l'ASP, après s'être assuré que tout le trafic est arrêté à l'ASP.

Dans le cas d'un AS en mode Partage de charge, le SGP passe l'ASP à l'état ASP-INACTIVE, et le trafic de l'AS est réalloué à travers les ASP restants dans l'état ASP-ACTIVE, comme selon l'algorithme de partage de charge utilisé alors dans l'AS. Un message Notify ("Ressources d'ASP actifs insuffisantes dans l'AS") PEUT être envoyé à tous les ASP inactifs, si exigé. Un message ASP Inactive Ack est envoyé à l'ASP après que tout le trafic est arrêté, et la gestion de couche est informée avec une primitive d'indication M-ASP_INACTIVE.

Dans le cas d'un AS en mode Diffusion, le SGP passe l'ASP à l'état ASP-INACTIVE, et le trafic de l'AS est diffusé seulement aux ASP restants dans l'état ASP-ACTIVE. Un message Notify ("Ressources d'ASP actifs insuffisantes dans l'AS") PEUT être envoyé à tous les ASP inactifs, si exigé. Un message ASP Inactive Ack est envoyé à l'ASP après que tout le trafic est arrêté, et la gestion de couche est informée avec une primitive d'indication M-ASP_INACTIVE.

Plusieurs messages ASP Inactive Ack PEUVENT être utilisés en réponse à un message ASP Inactive contenant plusieurs contextes d'acheminement, ce qui permet au SGP ou IPSP d'accuser indépendamment réception de différents (ensembles de) contextes d'acheminement. Le SGP ou IPSP envoie un message d'erreur ("Contexte d'acheminement invalide") pour chaque valeur de contexte d'acheminement invalide ou non configurée dans un message ASP Inactive reçu.

Le SGP DOIT envoyer un message ASP Inactive Ack en réponse à un message ASP Inactive reçu de l'ASP ; l'ASP est déjà marqué comme ASP-INACTIVE au SGP.

À l'ASP, le message ASP Inactive Ack reçu n'est pas acquitté. La gestion de couche est informée avec une primitive de confirmation M-ASP_INACTIVE. Si l'ASP reçoit un ASP Inactive Ack sans avoir envoyé un message ASP Inactive, l'ASP devrait maintenant se considérer comme étant dans l'état ASP-INACTIVE. Si l'ASP était précédemment dans l'état ASP-ACTIVE, l'ASP devrait alors initier les procédures pour retourner à son état précédent.

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

Si aucun autre ASP dans le serveur d'application n'est dans l'état ASP-ACTIVE, le SGP DOIT envoyer un message Notify ("AS en instance") à tous les ASP dans l'AS qui sont dans l'état ASP-INACTIVE. Le SGP DEVRAIT commencer à mettre en mémoire tampon les messages entrants pendant T(r) secondes, après quoi les messages PEUVENT être éliminés. T(r) est configurable par l'opérateur du réseau. Si le SGP reçoit un message ASP actif d'un ASP dans 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-INACTIVE.

 	4.3.4.4.1	Considérations d'IPSP (ASP Inactive)
Un IPSP peut être considéré comme étant dans l'état ASP-INACTIVE par un IPSP distant après qu'un message ASP Inactive ou ASP Inactive a été reçu de lui.

Autrement, quand on utilise le modèle IPSP DE, un échange de messages ASP Inactive entre chaque extrémité DOIT être effectué. Quatre messages sont nécessaires pour l'achever.

 	4.3.4.5	Procédures de Notify
Un message Notify reflétant un changement d'état de l'AS DOIT être envoyé à tous les ASP de l'AS, sauf ceux dans l'état ASP-DOWN, avec les informations d'état appropriées et tout identifiant d'ASP de l'ASP défaillant. À l'ASP, la gestion de couche 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 d'ASP ou de la réception d'un message Gestion d'état d'ASP (ASPSM, ASP State management) / Gestion de trafic d'ASP (ASPTM, ASP Traffic Management). Dans le second cas, le message Notify DOIT être envoyé après les messages d'accusé de réception qui s'y rapportent (par exemple, ASP Up Ack, ASP Down Ack, ASP Active Ack, ou ASP Inactive Ack).

Quand un ASP passe de l'état ASP-DOWN à ASP-INACTIVE dans un AS particulier, un message Notify DEVRAIT être envoyé, par l'ASP-UP receveur, après l'envoi du ASP-UP-ACK, afin d'informer l'ASP de l'état actuel de l'AS.

Dans le cas où un message Notify ("AS-PENDING") est envoyé par un SGP qui maintenant n'a pas d'ASP actifs à desservir, ou lorsque un message Notify ("Ressources insuffisantes d'ASP actifs dans l'AS") est envoyé dans le mode partage de charge ou diffusion, le message Notify n'oblige pas explicitement le ou les ASP qui reçoivent le message à devenir actifs. Les ASP restent au contrôle de quelle (et quand) action de trafic est entreprise.

Dans le cas où un message Notify ne contient pas de paramètre Contexte d'acheminement, le receveur doit savoir, via les données de configuration, de quels serveurs d'application l'ASP est membre et prendre l'action appropriée dans chaque AS.

 	4.3.4.5.1	Considérations d'IPSP (NTFY)
Le Notify fonctionne de la même manière que dans le cas SG-AS. Un des IPSP peut envoyer ce message à tour IPSP distant qui n'est pas dans l'état ASP-DOWN.

 	4.3.4.6	Procédures de battement de cœur
Les procédures facultatives de battement de cœur (Heartbeat) PEUVENT être utilisées dans le 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 SCTP). L'un ou l'autre homologue M3UA peut facultativement envoyer périodiquement des messages Heartbeat, sous le contrôle d'un temporisateur provisionnable, T(beat). À réception d'un message Heartbeat, l'homologue M3UA DOIT répondre avec un message Heartbeat Ack.

Si aucun message Heartbeat Ack (ou un autre message M3UA) n'est reçu de l'homologue M3UA dans le délai de 2*T(beat), l'homologue M3UA distant est considéré comme indisponible. La transmission des messages Heartbeat 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 M3UA déconnecté.

Le message Heartbeat peut facultativement contenir un paramètre opaque Heartbeat Data qui DOIT être renvoyé en écho inchangé dans le message Heartbeat Ack qui s'y rapporte. L'envoyeur, en examinant le contenu du message Heartbeat Ack retourné, PEUT choisir de considérer l'homologue M3UA distant comme indisponible. Le contenu/format du paramètre Heartbeat Data dépend de la mise en œuvre et seulement d'intérêt local pour l'envoyeur d'origine. Le contenu peut être utilisé, par exemple, pour prendre en charge un algorithme de séquence de battement de cœur (pour détecter des battements de cœur manquants) et/ou un mécanisme d'horodatage (pour évaluer les délais).

Note : les événements relatifs au battement de cœur ne sont pas montrés dans la Figure 3 "Diagramme de transition d'état d'ASP".

 	4.4.	Procédures de gestion de clé d'acheminement (facultative)
 	4.4.1	Enregistrement
Un ASP PEUT s'enregistrer de façon dynamique auprès d'un SGP comme ASP au sein d'un serveur d'application en utilisant le message REG REQ. Un paramètre Clé d'acheminement dans le message REG REQ spécifie les paramètres associés à la clé d'acheminement.

Le SGP examine le contenu du paramètre Clé d'acheminement reçu et le compare avec les clés d'acheminement actuellement provisionnées. Si la clé d'acheminement reçue correspond à une entrée existante de clé d'acheminement SGP et si l'ASP n'est pas actuellement inclus dans la liste des ASP pour le serveur d'application concerné, le SGP PEUT autoriser l'ASP à s'ajouter à l'AS. Ou, si la clé d'acheminement n'existe pas actuellement et si les données de clé d'acheminement reçues sont valides et univoques, un SGP qui prend en charge la configuration dynamique PEUT autoriser la création d'une nouvelle clé d'acheminement et son serveur d'application et ajouter l'ASP au nouvel AS. Dans l'un et l'autre cas, le SGP retourne un message Réponse d'enregistrement à l'ASP, contenant le même identifiant de RK locale que fourni dans la demande initiale, et un résultat d'enregistrement "Enregistrement réussi". Une valeur unique de contexte d'acheminement allouée à la clé d'acheminement SGP est incluse. La méthode d'allocation de la valeur de contexte d'acheminement au SGP dépend de la mise en œuvre mais il doit être garanti qu'elle est unique pour chaque serveur d'application ou clé d'acheminement pris en charge par le SGP.

Si le SGP ne prend pas en charge la procédure d'enregistrement, le SGP retourne un message d'erreur à l'ASP, avec un code d'erreur de "Classe de message non prise en charge".

Si le SGP détermine que les données de clé d'acheminement reçues sont invalides, ou contiennent des valeurs de paramètre invalides, il retourne un message Réponse d'enregistrement à l'ASP, contenant un résultat d'enregistrement "Erreur - clé d'acheminement invalide", "Erreur - DPC invalide", ou "Erreur - Apparition de réseau invalide", comme approprié.

Si le SGP détermine que la RK demandée correspond partiellement, mais pas exactement, à une RK existante, et qu'un message de signalisation entrant reçu à un SGP pourrait éventuellement correspondre à la fois à la RK demandée et à celle existante, le SGP retourne un message Réponse d'enregistrement à l'ASP, avec un état d'enregistrement de "Erreur – ne peut pas prendre en charge un acheminement unique". Un message de signalisation entrant reçu à un SGP ne devrait pas correspondre à plus d'une clé d'acheminement.

Si le SGP détermine que la RK reçue était déjà enregistrée, pleinement et exactement, statiquement ou dynamiquement, par l'ASP envoyeur, le SGP retourne un message Réponse d'enregistrement à l'ASP, contenant un Résultat d'enregistrement "Erreur - clé d'acheminement déjà enregistrée". Cette erreur s'applique que l'ASP/IPSP envoyeur soit dans l'état ASP-ACTIVE ou ASP-INACTIVE pour l'AS correspondant. Pour ce code d'erreur, le champ RC dans le message Réponse d'enregistrement DOIT être rempli avec la valeur actuelle de RC dans le SGP correspondant à la RK spécifiée dans le message Demande d'enregistrement.

Un ASP PEUT demande la modification d'une clé d'acheminement existante en incluant un paramètre Contexte d'acheminement dans un message Demande d'enregistrement. À réception d'un message Demande d'enregistrement contenant un contexte d'acheminement, si le SGP détermine que le contexte d'acheminement s'applique à une clé d'acheminement existante, le SGP PEUT ajuster la clé d'acheminement existante pour correspondre aux nouvelles informations fournies dans le paramètre Clé d'acheminement. Une réponse d'enregistrement "ERREUR – changement de clé d'acheminement refusé" est retournée si le SGP ne prend pas en charge cette procédure de réenregistrement ou si la RC n'existe pas. Autrement, une réponse d'enregistrement "Enregistrement réussi" est retournée.

Si le SGP n'autorise pas une demande d'enregistrement par ailleurs valide, il retourne un message REG RSP à l'ASP contenant le résultat d'enregistrement "Erreur - Permission refusée".

Si un SGP détermine qu'une clé d'acheminement reçue n'existe pas actuellement, et si le SGP ne prend pas en charge la configuration dynamique, il retourne un message Réponse d'enregistrement à l'ASP, contenant un résultat d'enregistrement "Erreur - clé d'acheminement non provisionnée actuellement".

Si un SGP détermine qu'une clé d'acheminement reçue n'existe pas actuellement, et si le SGP prend en charge la configuration dynamique mais n'a pas la capacité d'ajouter de nouvelle clé d'acheminement et de nouvelles entrées de serveur d'application, le SGP retourne un message Réponse d'enregistrement à l'ASP, contenant le résultat d'enregistrement "Erreur – ressources insuffisantes".

Si un SGP détermine qu'une clé d'acheminement reçue n'existe pas actuellement, et si le SGP prend en charge la configuration dynamique mais exige que la clé d'acheminement soit d'abord provisionnée manuellement au SGP, le SGP retourne un message Réponse d'enregistrement à l'ASP, contenant le résultat d'enregistrement "Erreur - clé d'acheminement non provisionnée actuellement".

Si un SGP détermine qu'un ou plusieurs des paramètres de clé d'acheminement ne sont pas pris en charge pour les besoins de la création de nouvelles entrées de clé d'acheminement, le SGP retourne un message Réponse d'enregistrement à l'ASP, contenant le résultat d'enregistrement "Erreur- champ paramètre de RK non pris en charge".

Une réponse d'enregistrement "Erreur – mode de traitement du trafic non pris en charge" est retournée si la clé d'acheminement dans la REG REQ contient un mode de traitement du trafic qui n'est pas cohérent avec le mode présentement configuré pour le serveur d'application correspondant.

Un ASP PEUT enregistrer plusieurs clés d'acheminement en une fois en incluant un certain nombre de paramètres de clé d'acheminement dans un seul message REG REQ. Le SGP PEUT répondre à chaque demande d’enregistrement dans un seul  message REG RSP, indiquant le résultat de succès ou d'échec pour chaque clé d'acheminement dans un paramètre séparé de résultat d'enregistrement. Autrement, le SGP PEUT répondre avec plusieurs messages REG RSP, chacun avec un ou plusieurs paramètres de résultat d'enregistrement. L'ASP utilise le paramètre Identifiant de RK locale pour corréler la demande avec les réponses.

L'enregistrement d'un ASP dans un AS ayant réussi, le SGP peut maintenant envoyer les messages de gestion de réseau de signalisation SS7 en rapport, si cela n'a pas commencé précédemment lorsque l'ASP est passé à l'état ASP-INACTIVE.

 	4.4.2	Désenregistrement
Un ASP PEUT se désenregistrer de façon dynamique d'avec un SGP comme d'un ASP au sein d'un serveur d'application en utilisant le message DEREG REQ. Un paramètre Contexte d'acheminement dans le message DEREG REQ spécifie quelles clés d'acheminement désenregistrer. Un ASP DEVRAIT passer à l'état ASP-INACTIVE pour un serveur d'application avant de tenter de désenregistrer la clé d'acheminement (c'est-à-dire, de désenregistrer après avoir reçu un ASP Inactive Ack). Aussi, un ASP DEVRAIT se désenregistrer de tous les serveurs d'application dont il est membre avant de tenter de passer à l'état ASP-Down.

Le SGP examine le contenu du paramètre Contexte d'acheminement reçu et valide que l'ASP est actuellement enregistré chez le ou les serveurs d'application en rapport avec le ou les contextes d'acheminement inclus. Si il est validé, l'ASP est désenregistré comme ASP dans le serveur d'application concerné.

La procédure de désenregistrement n'implique pas nécessairement la suppression des données de configuration de clé d'acheminement et de serveur d'application à la SG.

D'autres ASP peuvent continuer d'être associés au serveur d'application, et dans ce cas les données de clé d'acheminement NE DEVRAIENT PAS être supprimées. Si un désenregistrement a pour résultat qu'il n'y a plus d'ASP dans un serveur d'application, une SG PEUT supprimer les données de clé d'acheminement.

Le SGP accuse réception de la demande de désenregistrement en retournant un message DEREG RSP à l'ASP demandeur. Le résultat du désenregistrement se trouve dans le paramètre Résultat de désenregistrement, indiquant le succès ou l'échec avec sa cause.

Un ASP PEUT désenregistrer plusieurs contextes d'acheminement en une fois en incluant un certain nombre de contextes d'acheminement dans un seul message DEREG REQ. Le SGP PEUT répondre à chaque demande de désenregistrement dans un seul message DEREG RSP, indiquant le résultat de succès ou d'échec pour chaque contexte d'acheminement dans un paramètre Résultat de désenregistrement séparé.

 	4.4.3	Considérations d'IPSP (REG/DEREG)
Les procédures d’enregistrement/désenregistrement fonctionnent dans le cas d'IPSP de la même façon que dans celui d'AS-SG. Un IPSP peut enregistrer une RK dans l'IPSP distant. Un IPSP est responsable du désenregistrement des clés d'acheminement qu'il a enregistrées.

 	4.5	Procédures de prise en charge de l'état de disponibilité ou d'encombrement de la destination SS7
 	4.5.1	Au SGP
À réception d'une primitive d'indication MTP-PAUSE, MTP-RESUME ou MTP-STATUS de la fonction d'interfonctionnement nodale à un SGP, la couche M3UA du SGP va envoyer un message de gestion de réseau de signalisation SS7 (SSNM, SS7 Signalling Network Management) correspondant DUNA, DAVA, SCON, ou DUPU (voir au paragraphe 3.4) aux homologues M3UA aux ASP concernés. La couche M3UA doit remplir divers champs des messages SSNM en accord avec les informations reçues dans les primitives.

La couche M3UA du SGP détermine l'ensemble des ASP concernés à informer sur la base du réseau SS7 spécifique pour lequel l'indication de primitive est pertinente. De cette façon, tous les ASP configurés à envoyer/recevoir le trafic au sein d'une apparition de réseau particulière sont informés. Si le SGP opère au sein d'une seule apparition de réseau SS7, alors tous les ASP sont informés.

Pour le cas particulier où un ASP devient actif pour un AS et où des destinations normalement accessibles à l'AS sont inaccessibles, interdites, ou encombrées, la SG PEUT envoyer des messages DUNA, DRST, ou SCON pour les destinations inaccessibles, interdites, ou encombrées à l'ASP nouvellement actif pour l'AS pour empêcher l'ASP d'envoyer du trafic pour des destinations dont il pourrait ne pas savoir par ailleurs qu'elles sont inaccessibles, interdites, ou encombrées. Pour l'ASP nouvellement activé duquel le SGP a reçu un message ASP actif, ces messages DUNA, DRST, et SCON PEUVENT être envoyés avant le ASP Active Ack qui achève la procédure d'activation.

Les messages DUNA, DAVA, SCON, et DRST peuvent être envoyés à la suite et traités chez le receveur dans l'ordre d'envoi.

Le séquencement n'est pas exigé pour les messages DUPU ou DAUD, qui PEUVENT être envoyé sans séquencement.

 	4.5.2	À un ASP
 	4.5.2.1	Configurations d'une seule SG
À un ASP, à réception d'un message de gestion de réseau de signalisation SS7 (SSNM) de l'homologue M3UA distant, la couche M3UA invoque les indications de primitive appropriées aux utilisateurs M3UA résidents. La gestion locale est informée.

Dans le cas où un événement local a causé l'état d'indisponibilité ou d'encombrement de destinations SS7, la couche M3UA à l'ASP DEVRAIT passer les indications appropriées dans les primitives à l'utilisateur M3UA, comme si les messages SSNM équivalents étaient reçus. Par exemple, la perte d'une association SCTP à un SGP peut causer l'indisponibilité d'un ensemble de destinations SS7. Des primitives d'indication MTP-PAUSE à l'utilisateur M3UA sont appropriées.

 	4.5.2.2	Configurations à plusieurs SG
À un ASP, à réception d'un message de gestion de réseau de signalisation provenant de l'homologue M3UA distant, la couche M3UA met à jour l'état des chemins affectés via la SG d'origine et détermine si l'état global d'indisponibilité ou d'encombrement de la ou des destinations affectées a changé. Si il en est ainsi, la couche M3UA invoque les primitives d'indication appropriées aux utilisateurs M3UA résidents. La gestion locale est informée.

Note de mise en œuvre : pour faire cela, la couche M3UA à un ASP conserve l'état des chemins via la SG, un peu comme une couche MTP3 conserve l'état de l'ensemble de chemins.

 	4.5.3	Vérification d'ASP
Un ASP peut facultativement initier une procédure d'audit pour enquêter sur l'état de disponibilité et (si la méthode nationale d'encombrement avec multiples niveaux d'encombrement et priorités de message est utilisée) d'encombrement d'une destination ou ensemble de destinations SS7 dans un SGP. Un message Audit de destination (DAUD, Destination Audit) est envoyé de l'ASP au SGP, demandant l'état actuel de disponibilité et d'encombrement d'un ou plusieurs codets de destination SS7.

Le message DAUD PEUT être envoyé sans séquencement. Le DAUD PEUT être envoyé par l'ASP dans les cas suivants :

-	Périodique. Un temporisateur établi à l'origine à réception d'un message DUNA, SCON, ou DRST est arrivé à expiration sans qu'un message DAVA, DUNA, SCON, ou DRST suivant ne mette à jour l'état de disponibilité/encombrement des codets de destination affectés. Le temporisateur est réinitialisé à la production d'un DAUD. Dans ce cas, le DAUD est envoyé au SGP qui a à l'origine envoyé le message SSNM.

-	Isolation. L'ASP vient de passer à ASP-ACTIVE ou a été isolé d'un SGP pendant une longue période. L'ASP PEUT demander l'état de disponibilité/encombrement d'une ou plusieurs destinations SS7 avec lesquelles il s'attend à communiquer.

Note de mise en œuvre : dans le premier des cas ci-dessus, la procédure de vérification ne doit pas être invoquée pour le cas d'un message SCON reçu contenant une valeur de niveau d'encombrement de "pas d'encombrement" ou "indéfini" (c'est-à-dire, niveau d'encombrement = "0").

Le SGP DEVRAIT répondre à un message DAUD avec l'état de disponibilité/encombrement MTP3 de l'ensemble de chemins associé à chaque codet de destination dans le message DAUD. L'état de chaque destination SS7 demandée est indiqué dans un message DUNA (si indisponible) un message DAVA (si disponible) ou un message DRST (si interdit et si le SGP prend en charge cette caractéristique dans les réseaux nationaux). Pour les réseaux nationaux, le SGP DEVRAIT de plus répondre avec un message SCON (si la destination est encombrée) avant le DAVA ou DRST.

Lorsque le SGP ne conserve pas l'état d'encombrement de la destination SS7, la réponse à un message DAUD devrait toujours être seulement un message DAVA, DRST, ou DUNA, comme approprié.

Tout message DUNA ou DAVA en réponse à un message DAUD PEUT contenir une liste de codets affectés.

Une SG PEUT refuser de fournir l'état de disponibilité ou d'encombrement d'une destination si, par exemple, l'ASP n'est pas autorisé à savoir l'état de la destination. La SG PEUT répondre avec un message d'erreur (Code d'erreur = "État de destination inconnu").

Une SG DEVRAIT répondre avec un message DUNA quand un DAUD a été reçu avec un codet de signalisation inconnu.

 	4.6.	Redémarrage de MTP3
Dans le cas où la couche MTP3 dans la SG subit un redémarrage de MTP, la communication de l'événement DEVRAIT être traitée comme suit :

Quand la SG découvre l'isolation du réseau SS7, les SGP envoient une indication à tous les ASP disponibles concernés (c'est-à-dire, les ASP dans l'état ASP-ACTIVE) en utilisant des messages DUNA pour les destinations concernées.

Quand la SG a achevé les procédures de redémarrage MTP, les couches M3UA aux SGP informent tous les ASP concernés dans l’état ASP-ACTIVE de toutes les destinations SS7 disponibles/interdites, en utilisant les messages DAVA/DRST. Aucun message n'est nécessaire pour les destinations encore indisponibles après la procédure de redémarrage.

Quand la couche M3UA à un ASP reçoit un message DUNA indiquant l'indisponibilité de la destination SS7 à une SG, les utilisateurs MTP vont recevoir une indication MTP-PAUSE et vont arrêter tout le trafic affecté pour cette destination. Quand la couche M3UA reçoit un message DAVA/DRST, les utilisateurs MTP vont recevoir une indication MTP-RESUME et peuvent reprendre le trafic vers la destination SS7 nouvellement disponible, pourvu que l'ASP soit dans l'état ASP-ACTIVE à l'égard ce ce SGP.

L'ASP PEUT choisir d'examiner la disponibilité des destinations indisponibles en envoyant des messages DAUD. Ce serait le cas quand, par exemple, un AS devient actif à un ASP et n'a pas les états des destinations actuelles. Si le redémarrage MTP est en cours à la SG, le SGP retourne un message DUNA pour cette destination, même si il a reçu une indication que la destination est devenue disponible ou interdite.

Quand un ASP devient actif pour un AS et que la SG subit un isolement de réseau SS7 ou est en train d'effectuer la procédure de redémarrage MTP pour l'AS, la SG PEUT envoyer un message DUNA pour les destinations concernées à l'ASP nouvellement actif pour empêcher l'ASP d'envoyer du trafic. Ces messages peuvent être envoyés après la réception du ASP Active, et avant l'envoi du ASP Active Ack, pour s'assurer que du trafic n'est pas initié par l'ASP à ces destinations avant que des SSNM soient reçus. En plus des messages DUNA, des messages SCON, DRST, et DAVA peuvent aussi être envoyés.

Dans le cas de IPSP, le redémarrage MTP pourrait être envisagé si l'IPSP a aussi une connexion à un réseau SS7. Dans ce cas, le même comportement que décrit ci-dessus pour le SGP s'appliquerait à l'IPSP qui redémarre. Ce serait aussi le cas si les IPSP étaient perçus comme échangeant des PDU d'homologue MTP, au lieu de primitives MTP entre utilisateur MTP et fournisseur MTP. En d'autres termes, M3UA ne fournit pas d'équivalent aux messages Redémarrage de trafic permis indiquant la fin de la procédure de redémarrage entre homologues IPSP qui seraient aussi connectés à un réseau SS7.

 	4.7	NIF non disponible
Note de mise en œuvre : bien que la NIF soit décidée comme étant une fonction dépendante de la mise en œuvre, voici quelques lignes directrices qu'il peut être utile de suivre :
-	Si un SGP est isolé entièrement de la NIF, il devrait envoyer l'ASP Down Ack à tous les ASP auxquels il est connecté. À réception d'un message ASP Up alors qu'il est isolé de la NIF, le SGP devrait répondre avec une erreur ("Refusé – Blocage de gestion").
-	Si un SGP subit une défaillance partielle (où un SGP peut continuer de desservir un ou plusieurs AS actifs mais du fait de la défaillance partielle il est incapable de desservir un ou plusieurs autres AS actifs) le SGP devrait envoyer le ASP Inactive Ack à tous les ASP auxquels il est connecté pour l'AS affecté. À réception d'un message ASP actif pour un AS affecté alors qu'il est encore partiellement isolé de la NIF, le SGP devrait répondre avec une erreur ("Refusé – Blocage de gestion").
-	Si la SG est isolée de la NIF, cela signifie que chaque SGP au sein d'une SG devrait suivre la procédure mentionnée ci-dessus.

 	4.8	Contrôle de version M3UA
Si un message avec une version non prise en charge est reçu, l'extrémité receveuse répond avec un message d'erreur indiquant la version que le nœud receveur prend en charge et le notifie à la gestion de couche.

Ceci est utile quand une mise à niveau de version de protocole est effectuée sur un réseau. Un nœud mis à niveau à 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 Up, il est probable que le message qui a une version non prise en charge est un message ASP Up et donc que le message d'erreur va normalement provenir du SGP.

 	4.9	Terminaison de M3UA
Chaque fois qu'un nœud M3UA veut arrêter la communication avec le nœud homologue, il PEUT utiliser une des procédures suivantes :
a)	Envoyer la séquence de messages ASP-INACTIVE, DEREG (facultativement chaque fois qu'un enregistrement dynamique est utilisé) et ASP-DOWN et effectuer la procédure Fermeture SCTP après cela.
b)	Juste faire la procédure Fermeture SCTP.

 	5.	Exemples de procédures M3UA
 	5.1	Établissement d'association et de trafic entre les SGP et les ASP
Ces scénarios montrent des exemples de flux de messages M3UA pour l'établissement du trafic entre un SGP et un ASP ou entre deux IPSP. Dans tous les cas, on suppose que l'association SCTP est déjà établie.

 	5.1.1	Un seul ASP dans un serveur d'application ("1+0" restreint) pas d'enregistrement
Ces scénarios montrent des exemples de flux de messages M3UA pour l'établissement du trafic entre un SGP et un ASP où seulement un ASP est configuré dans un AS (pas de secours).

 	5.1.1.1	Un seul ASP dans un serveur d'application ("1+0" restreint) pas d'enregistrement
                 SGP                             ASP1
                  |                               |
                  |<-------------ASP Up-----------|
                  |-----------ASP Up Ack--------->|
                  |                               |
                  |-----NTFY(AS-INACTIVE)(RCn)--->|
                  |                               |
                  |<------- ASP Active(RCn)-------| RC : contexte d'acheminement
                  |-----ASP Active Ack (RCn)----->|      (facultatif)
                  |                               |
                  |-----NTFY(AS-ACTIVE)(RCn)----->|
                  |                               |

Note : Si le message ASP actif contient un paramètre facultatif Contexte d'acheminement, le message ASP actif s'applique seulement aux valeurs de RC spécifiées. Pour une valeur de RC inconnue, le SGP répond avec un message d'erreur.

 	5.1.1.2	Un seul ASP dans le serveur d'application ("1+0" restreint), enregistrement dynamique
Ce scénario est le même qu'au paragraphe 5.1.1.1 mais avec les informations facultatives d'échange d'enregistrement. Dans ce cas, l'enregistrement est accepté par le SGP.

                SGP                             ASP1
                 |                               |
                 |<------------ASP Up------------|
                 |----------ASP Up Ack---------->|
                 |                               |
                 |                               |
                 |<----REGISTER REQ(LRCn,RKn)----| LRC : Identifiant local de clé 
                 |                               |       d'enregistrement
                 |----REGISTER RESP(LRCn,RCn)--->| RK : clé d'acheminement
                 |                               | RC : contexte d'acheminement
                 |----NTFY(AS-INACTIVE)(RCn)---->|
                 |                               |
                 |                               |
                 |<------- ASP Active(RCn)-------|
                 |-----ASP Active Ack (RCn)----->|
                 |                               |
                 |-----NTFY(AS-ACTIVE)(RCn)----->|
                 |                               |

Note : dans le cas d'un échec de tentative d'enregistrement (par exemple, RKn invalide) le message Réponse d'enregistrement va contenir une indication d'échec, et l'ASP ne va pas alors envoyer de message ASP actif.

 	5.1.1.3	Un seul ASP dans plusieurs serveurs d'application (chacun avec "1+0" restreint) enregistrement dynamique
(Cas 1 – plusieurs demandes d'enregistrement)

                SGP                             ASP1
                 |<------------ASP Up------------|
                 |----------ASP Up Ack---------->|
                 |                               |
                 |<----REGISTER REQ(LRC1,RK1)----| LRC : Identifiant local de clé
                 |                               |       d'acheminement
                 |----REGISTER RESP(LRC1,RC1)--->| RK : clé d'acheminement
                 |                               | RC : contexte d'acheminement
                 |---NOTIFY(AS-INACTIVE)(RC1)--->|
                 |                               |
                 |<------- ASP Active(RC1)-------|
                 |-----ASP Active Ack (RC1)----->|
                 |                               |
                 |----NOTIFY(AS-ACTIVE)(RC1)---->|
                 ~                               ~
                 |<----REGISTER REQ(LRCn,RKn)----|
                 |                               |
                 |----REGISTER RESP(LRCn,RCn)--->|
                 |                               |
                 |---NOTIFY(AS-INACTIVE)(RCn)--->|
                 |                               |
                 |<------- ASP Active(RCn)-------|
                 |-----ASP Active Ack (RCn)----->|
                 |                               |
                 |----NOTIFY(AS-ACTIVE)(RCn)---->|
                 |                               |

Note : Dans le cas d'un échec de tentative d'enregistrement (par exemple, RKn invalide) le message Réponse d'enregistrement va contenir une indication d'échec, et l'ASP ne va pas envoyer ensuite un message ASP actif. Chaque enregistrement de paire LRC/RK est considéré indépendamment.

Il n'est pas nécessaire de faire suivre une paire de messages Demande/Réponse d'enregistrement par un message ASP actif avant d'envoyer la demande d'enregistrement suivante. Le message ASP actif peut être envoyé à tout moment après la réussite de l'enregistrement concerné.

 	5.1.1.4	Un seul ASP dans plusieurs serveurs d'application (chacun avec "1+0" restreint) enregistrement dynamique
(Cas 2 – Une seule demande d'enregistrement)

                  SGP                             ASP1
                   |                               |
                   |<------------ASP Up------------|
                   |----------ASP Up Ack---------->|
                   |                               |
                   |                               |
                   |<---REGISTER REQ({LRC1,RK1},   |
                   |                   ...,        |
                   |                 {LRCn,RKn}),--|
                   |                               |
                   |---REGISTER RESP({LRC1,RC1},-->|
                   |                  ...,         |
                   |                 (LRCn,RCn})   |
                   |                               |
                   |--NTFY(AS-INACTIVE)(RC1..RCn)->|
                   |                               |
                   |<------- ASP Active(RC1)-------|
                   |-----ASP Active Ack (RC1)----->|
                   |                               |
                   |----NOTIFY(AS-ACTIVE)(RC1)---->|
                   :                               :
                   :                               :
                   |                               |
                   |<------- ASP Active(RCn)-------|
                   |-----ASP Active Ack (RCn)----->|
                   |                               |
                   |----NOTIFY(AS-ACTIVE)(RCn)---->|
                   |                               |

Note : Dans le cas d'un échec de tentative d'enregistrement (par exemple, RKn invalide) le message Réponse d'enregistrement va contenir une indication d'échec, et l'ASP ne va pas ensuite envoyer un message ASP actif. Chaque enregistrement de paire LRC/RK est considéré indépendamment.

Le message ASP actif peut être envoyé à tout moment après la réussite de l'enregistrement concerné et peut avoir plus d'une RC.

 	5.1.2	Deux ASP dans un serveur d'application ("1+1" restreint)
Ce scénario montre l'exemple d'un flux de messages M3UA pour l'établissement du trafic entre un SGP et deux ASP dans le même serveur d'application, où ASP1 est configuré à être dans l'état ASP-ACTIVE et ASP2 est une "sauvegarde" dans le cas d'une défaillance de la communication ou du retrait de service de ASP1. ASP2 peut agir comme sauvegarde chaude, tiède ou froide, selon la mesure dans laquelle ASP1 et ASP2 partagent l'état d'appel/transaction ou peuvent communiquer l'état d'appel en cas de défaillance/retrait. L'exemple de flux de messages est le même, que les messages ASP Active indiquent le mode "Outrepasser", "Partage de charge" ou "Diffusion", bien que normalement, cet exemple utiliserait un mode Outrepasser.

         SGP                      ASP1                       ASP2
          |                        |                          |
          |<--------ASP Up---------|                          |
          |-------ASP Up Ack------>|                          |
          |                        |                          |
          |--NOTIFY(AS-INACTIVE)-->|                          |
          |                        |                          |
          |<----------------------------ASP Up----------------|
          |----------------------------ASP Up Ack------------>|
          |                        |                          |
          |--------------------------NOTIFY(AS-INACTIVE)----->|
          |                        |                          |
          |<-------ASP Active------|                          |
          |------ASP Active Ack--->|                          |
          |                        |                          |
          |---NOTIFY(AS-ACTIVE)--->|                          |
          |--------------------------NOTIFY(AS-ACTIVE)------->|
          |                        |                          |

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

         SGP                      ASP1                       ASP2
          |                        |                          |
          |<---------ASP Up--------|                          |
          |--------ASP Up Ack----->|                          |
          |                        |                          |
          |--NOTIFY(AS-INACTIVE)-->|                          |
          |                        |                          |
          |<-----------------------------ASP Up---------------|
          |----------------------------ASP Up Ack------------>|
          |                        |                          |
          |--------------------------NOTIFY(AS-INACTIVE)----->|
          |                        |                          |
          |<--ASP Active (Ldshr)---|                          |
          |-----ASP-Active Ack---->|                          |
          |                        |                          |
          |---NOTIFY (AS-ACTIVE)-->|                          |
          |-----------------------------NOTIFY(AS-ACTIVE)---->|
          |                        |                          |
          |<---------------------------ASP Active (Ldshr)-----|
          |------------------------------ASP Active Ack------>|
          |                        |                          |

 	5.1.4.	Trois ASP dans un serveur d'application ("n+k" restreint, cas de partage de charge)
Ce scénario montre l'exemple d'un flux de messages M3UA pour l'établissement du trafic entre un SGP et trois ASP dans le même serveur d'application, où deux des ASP sont amenés à l'état ASP-ACTIVE et ensuite partagent la charge. Dans ce cas, un minimum de deux ASP est exigé pour traiter la charge totale du trafic (2+1 restreint).

        SGP                 ASP1                ASP2                ASP3
          |                   |                   |                   |
          |<------ASP Up------|                   |                   |
          |-----ASP Up Ack--->|                   |                   |
          |                   |                   |                   |
          |NTFY(AS-INACTIVE)->|                   |                   |
          |                   |                   |                   |
          |<-------------------------ASP Up-------|                   |
          |------------------------ASP Up Ack---->|                   |
          |                   |                   |                   |
          |------------------NOTIFY(AS-INACTIVE)->|                   |
          |                   |                   |                   |
          |<--------------------------------------------ASP Up--------|
          |--------------------------------------------ASP Up Ack---->|
          |                   |                   |                   |
          |--------------------------------------NOTIFY(AS-INACTIVE)->|
          |                   |                   |                   |
          |<--ASP Act (Ldshr)-|                   |                   |
          |----ASP Act Ack--->|                   |                   |
          |                   |                   |                   |
          |<-------------------ASP Act. (Ldshr)---|                   |
          |----------------------ASP Act Ack----->|                   |
          |                   |                   |                   |
          |--NTFY(AS-ACTIVE)->|                   |                   |
          |--------------------NOTIFY(AS-ACTIVE)->|                   |
          |----------------------------------------NOTIFY(AS-ACTIVE)->|
          |                   |                   |                   |

 	5.2	Exemple de reprise sur défaillance du trafic d'ASP
 	5.2.1	1+1 restreint, retrait d'ASP, outrepassement de sauvegarde
Suivant l'exemple du paragraphe 5.1.2, l'ASP1 se retire du service:

               SGP                      ASP1                       ASP2
                |                        |                          |
                |<-----ASP Inactive------|                          |
                |----ASP Inactive Ack--->|                          |
                |                        |                          |
                |----NTFY(AS-PENDING)--->|                          |
                |-----------------------NTFY(AS-PENDING)----------->|
                |                        |                          |
                |<----------------------------- ASP Active----------|
                |-----------------------------ASP Active Ack------->|
                |                        |                          |
                |----NTFY(AS-ACTIVE)---->|                          |
                |-----------------------NTFY(AS-ACTIVE)------------>|

Note : Si la couche M3UA du SGP détecte la perte de l'homologue M3UA (par exemple, perte du battement de cœur M3UA ou détection de défaillance du SCTP) l'échange initial de message ASP Inactive (c'est-à-dire, de SGP à ASP1) ne va pas se produire.

 	5.2.2	 1+1 restreint, outrepassement de sauvegarde
Suite à l'exemple du paragraphe 5.1.2, ASP2 souhaite outrepasser ASP1 et prendre le trafic :

               SGP                      ASP1                       ASP2
                |                        |                          |
                |<----------------------------- ASP Active----------|
                |------------------------------ASP Active Ack------>|
                |----NTFY(Alt ASP-Act)-->|                          |
                |                        |                          |

 	5.2.3	n+k restreint, cas de partage de charge, retrait d'ASP
Suite à l'exemple du paragraphe 5.1.4, ASP1 se retire du service :

        SGP                 ASP1                ASP2                ASP3
          |                   |                   |                   |
          |<----ASP Inact.----|                   |                   |
          |---ASP Inact Ack-->|                   |                   |
          |                   |                   |                   |
          |--NTFY(Ins. ASPs)->|                   |                   |
          |---------------------------------------NOTIFY(Ins. ASPs)-->|
          |                   |                   |                   |
          |                   |                   |                   |
          |<----------------------------------------ASP Act (Ldshr)---|
          |------------------------------------------ASP Act (Ack)--->|
          |                   |                   |                   |
          |-NTFY(AS-ACTIVE)-->|                   |                   |
          |-------------------NOTIFY(AS-ACTIVE)-->|                   |
          |---------------------------------------NOTIFY(AS-ACTIVE)-->|
          |                   |                   |                   |

Pour que le message Notify soit envoyé, la SG conserve la connaissance des ressources minimum d'ASP exigées (par exemple, si la SG sait que "n+k" = "2+1" pour un AS en partage de charge et que "n" est actuellement égal à "1").

Note : Si le SGP détecte la perte de l'homologue ASP1 M3UA (par exemple, perte du battement de cœur M3UA ou détection de la défaillance de SCTP) l'échange initial de messages ASP Inactive (c'est-à-dire, SGP-ASP1) ne va pas se produire.

 	5.3	Retrait normal d'un ASP d'un serveur d'application et suppression d'une association
Un ASP qui est maintenant confirmé dans l'état ASP-INACTIVE (c'est-à-dire, l'ASP a reçu un message ASP Inactive Ack) peut alors passer à l'état ASP-DOWN, si il doit être retiré du service. Suivant le paragraphe 5.2.1 ou 5.2.3, où l'ASP1 est passé à l'état "Inactif" :

               SGP                            ASP1
                |                              |
                |<-----ASP Inactive (RCn)------| RC : contexte d'acheminement
                |----ASP Inactive Ack (RCn)--->|
                |                              |
                |<-----DEREGISTER REQ(RCn)-----| voir les notes
                |                              |
                |---DEREGISTER RESP(LRCn,RCn)->|
                :                              :
                |<-----------ASP Down----------|
                |---------ASP Down Ack-------->|
                |                              |

Note : la procédure de désenregistrement va normalement être utilisée si l'ASP a précédemment utilisé les procédures d'enregistrement pour la configuration dans le serveur d'application. Les échanges de messages ASP Inactive et Désenregistrement peuvent contenir plusieurs contextes d'acheminement.

L'ASP devrait être dans l'état ASP-INACTIVE et devrait s'être désenregistré de tous ses contextes d'acheminement avant de tenter de passer à l'état ASP-DOWN.

 	5.4	Exemples de vérification
 	5.4.1	État de SG : non encombré/disponible
          ASP                          SGP
           |  -------- DAUD --------->  |
           |  <------ SCON(0) --------  |
           |  <------- DAVA ----------  |

 	5.4.2	État de SG : encombré (niveau d'encombrement = 2) / disponible
          ASP                          SGP
           |  -------- DAUD --------->  |
           |  <------ SCON(2) --------  |
           |  <------- DAVA ----------  |

 	5.4.3	État de SG : Inconnu/Disponible
          ASP                          SGP
           |  -------- DAUD --------->  |
           |  <------- DAVA ----------  |

 	5.4.4	État de SG : Indisponible
          ASP                          SGP
           |  -------- DAUD --------->  |
           |  <------- DUNA ----------  |

 	5.5	Exemples de limite d’utilisateur M3UA/MTP3
 	5.5.1	À un ASP
Ce paragraphe décrit la transposition de primitive entre l'utilisateur MTP3 et la couche M3UA à un ASP.

 	5.5.1.1	Prise en charge des primitives MTP-TRANSFER chez l'ASP
 	5.5.1.1.1	Prise en charge de la primitive Demande MTP-TRANSFER
Quand l'utilisateur MTP3 sur l'ASP a des données à envoyer à un utilisateur MTP3 distant, il utilise la primitive de demande MTP-TRANSFER. La couche M3UA à l'ASP va faire ce qui suit quand elle reçoit une primitive de demande MTP-TRANSFER de l'utilisateur M3UA :
- Déterminer le SGP correct.
- Déterminer l'association correcte au SGP choisi.
- Déterminer le flux correct dans l'association (par exemple, sur la base du SLS).
- Déterminer si il faut compléter les champs facultatifs du message DATA.
- Transposer la primitive de demande MTP-TRANSFER en un champ Données de protocole d'un message DATA.
- Envoyer le message DATA à l'homologue M3UA distant au SGP, sur l'association SCTP.

            SGP                       ASP
             |                         |
             |<-----Message DATA ------|<--demande MTP-TRANSFER
             |                         |

 	5.5.1.1.2	Prise en charge de la primitive d'indication MTP-TRANSFER
Quand la couche M3UA sur l'ASP reçoit un message DATA de l'homologue M3UA au SGP distant, elle va faire ce qui suit  :
- Évaluer les champs facultatifs du message DATA, si il en est de présent.
- Transposer le champ Données de protocole d'un message DATA en la primitive d'indication MTP-TRANSFER.
- Passer la primitive d'indication MTP-TRANSFER au sous système utilisateur. En cas de sous systèmes utilisateur  multiples, les champs facultatifs du message Data sont utilisés pour déterminer le sous système concerné.

            SGP                       ASP
             |                         |
             |------Message DATA------>|-->Indication MTP-Transfer
             |                         |

 	5.5.1.1.3	Prise en charge des états de destination SS7 par l'ASP qui interroge
Il y a des situations comme une perte temporaire de connexité au SGP qui peuvent causer l'examen par la couche M3UA à l'ASP des états de disponibilité/encombrement de la destination SS7. Noter qu'il n'y a pas de primitive pour que l'utilisateur MTP3 demande cet examen à la couche M3UA, car c'est initié par une fonction interne de gestion M3UA.

            SGP                        ASP
             |                          |
             |<----------DAUD-----------|
             |<----------DAUD-----------|
             |<----------DAUD-----------|
             |                          |

 	5.5.2	À une SGP
Ce paragraphe décrit la transposition de primitive entre l'utilisateur MTP3 et la couche M3UA à un SGP.

 	5.5.2.1	Prise en charge de la primitive de demande MTP-TRANSFER au SGP
Quand la couche M3UA au SGP a reçu des messages DATA de son homologue destinés au réseau SS7, elle va faire ce qui suit :
- Évaluer les champs facultatifs du message DATA, si il est présent, pour déterminer l'apparition de réseau.
- Transposer le champ Données de protocole du message DATA en une primitive de demande MTP-TRANSFER.
- Passer la primitive de demande MTP-TRANSFER au MTP3 de l'apparition de réseau concernée.

                               SGP                        ASP
                                |                          |
        <---demande MTP-TRANSFER|<---------DATA -----------|
                                |                          |

 	5.5.2.2	Prise en charge de la primitive d'indication MTP-TRANSFER au SGP
Quand la couche MTP3 au SGP a des données à passer à son sous système utilisateur, elle va utiliser la primitive d'indication MTP-TRANSFER. La couche M3UA au SGP va faire ce qui suit quand elle reçoit une primitive d'indication MTP-TRANSFER :
- Déterminer l'AS correct, en utilisant la fonction de distribution ;
- Choisir un ASP dans l'état ASP-ACTIVE.
- Déterminer l'association correcte à l'ASP choisi.
- Déterminer le flux correct dans l'association SCTP (par exemple, sur la base du SLS).
- Déterminer si il faut compléter les champs facultatifs du message DATA.
- Transposer la primitive d'indication MTP-TRANSFER dans le champ Données de protocole d'un message DATA.
- Envoyer le message DATA à l'homologue M3UA distant dans l'ASP, sur l'association SCTP.

                              SGP                        ASP
                               |                          |
   --indication MTP-TRANSFER ->|-----------DATA --------->|
                               |                          |

 	5.5.2.3	Prise en charge des primitives d'indication MTP-PAUSE, MTP-RESUME, MTP-STATUS
Les primitives d'indication MTP-PAUSE, MTP-RESUME, et MTP-STATUS provenant de l'interface MTP3 de couche supérieure au SGP doivent être rendues disponibles à l'interface de couche inférieure de système d'utilisateur MTP3 distant à ou aux ASP concernés.

 	5.5.2.3.1	Destination indisponible
La couche MTP3 au SGP va générer une primitive d'indication MTP-PAUSE quand elle détermine localement qu'une destination SS7 est injoignable. La couche M3UA va transposer cette primitive en un message DUNA. La couche M3UA du SGP détermine l'ensemble d'ASP concernés à informer sur la base des informations internes du réseau SS7 associé à la primitive d'indication MTP-PAUSE.

                        SGP                       ASP
                         |                         |
--indication MTP-PAUSE-->|---------DUNA----------->|--indication MTP-PAUSE-->

 	5.5.2.3.2	Destination disponible
La couche MTP3 au SGP va générer une primitive d'indication MTP-RESUME quand elle détermine localement qu'une destination SS7 qui était précédemment injoignable est maintenant accessible. La couche M3UA va transposer cette primitive en un message DAVA. La M3UA du SGP détermine l’ensemble d'ASP concernés à informer sur la base des informations internes de réseau SS7 associées à la primitive d'indication MTP-RESUME.

                         SGP                       ASP
                          |                         |
--indication MTP-RESUME-->|-----------DAVA--------->|--indication MTP-RESUME-->
                          |                         |

 	5.5.2.3.3	Encombrement de réseau SS7
La couche MTP3 au SGP va générer une primitive d'indication MTP-STATUS quand elle détermine localement que le chemin pour une destination SS7 est encombré. La couche M3UA va transposer cette primitive en un message SCON. Elle va déterminer à quels ASP envoyer le message SCON sur la base du serveur d'application prévu.

                         SGP                       ASP
                          |                         |
--indication MTP-STATUS-->|-----------SCON--------->|--indication MTP-STATUS-->
                          |                         |

 	5.5.2.3.4	Sous système Utilisateur de destination indisponible
La couche MTP3 au SGP va générer une primitive d'indication MTP-STATUS quand elle reçoit un message DUPU du réseau SS7. La couche M3UA va transposer cette primitive en un message DUPU. Elle va déterminer à quels ASP envoyer le DUPU sur la base du serveur d'application prévu.

                         SGP                       ASP
                          |                         |
--indication MTP-STATUS-->|----------DUPU---------->|--indication MTP-STATUS-->
                          |                         |

 	5.6	Exemples de communication IPSP
Ces scénarios montrent un exemple basique de communication d'IPSP pour les trois phases de la connexion (établissement, échange de données, déconnexion). Il est supposé que l'association SCTP est déjà établie. Les deux comportements de simple échange et de double échange sont inclus à des fins d'illustration.

 	5.6.1	Un seul échange
               IPSP-A                           IPSP-B
                 |                                |
                 |-------------ASP Up------------>|
                 |<----------ASP Up Ack-----------|
                 |                                |
                 |<------- ASP Active(RCb)--------| RC : contexte d'acheminement
                 |-----ASP Active Ack (RCb)------>|      (facultatif)
                 |                                |
                 |<=========  DATA (RCb) ========>|
                 |                                |
                 |<-----ASP Inactive (RCb)--------| RC : contexte d'acheminement
                 |----ASP Inactive Ack (RCb)----->|      (facultatif)
                 |                                |
                 |<-----------ASP Down------------|
                 |---------ASP Down Ack---------->|
                 |                                |

Le contexte d'acheminement est le même dans les deux directions suite à un accord préalable.

 	5.6.2	Double échange
              IPSP-A                           IPSP-B
                 |                                |
                 |<-------------ASP Up------------|
                 |-----------ASP Up Ack---------->|
                 |                                |
                 |-------------ASP Up------------>|  (facultatif)
                 |<----------ASP Up Ack-----------|  (facultatif)
                 |                                |
                 |<------- ASP Active(RCb)--------| RC : contexte d'acheminement
                 |-----ASP Active Ack (RCb)------>|      (facultatif)
                 |                                |
                 |------- ASP Active(RCa)-------->| RC : contexte d'acheminement
                 |<-----ASP Active Ack (RCa)------|      (facultatif)
                 |                                |
                 |<=========  DATA (RCa) =========|
                 |==========  DATA (RCb) ========>|
                 |                                |
                 |<-----ASP Inactive (RCb)--------| RC : contexte d'acheminement
                 |----ASP Inactive Ack (RCb)----->|
                 |                                |
                 |------ASP Inactive (RCa)------->| RC : contexte d'acheminement
                 |<----ASP Inactive Ack (RCa)-----|
                 |                                |
                 |<-----------ASP Down------------|
                 |---------ASP Down Ack---------->|
                 |                                |
                 |------------ASP Down----------->|  (facultatif)
                 |<--------ASP Down Ack-----------|  (facultatif)
                 |                                |

Dans cette approche, un seul échange de messages ASP Up peut être considéré comme suffisant car la réponse de l'autre homologue peut être considérée comme indication qu'il est dans l'état ASP_UP.

Pour la même raison, un seul message ASP Down est nécessaire, car une fois qu'un IPSP reçoit le message d'accusé de réception d'ASP_Down, il est lui-même considéré comme étant dans l'état ASP_Down et non autorisé à recevoir des messages ASPSM.

 	6.	Considérations sur la sécurité

Les mises en œuvre DOIVENT suivre les lignes directrices normatives de la [RFC3788] sur l'intégration et l'usage des mécanismes de sécurité dans les protocoles SIGTRAN.

 	7.	Considérations relatives à l'IANA

Le présent document ne contient pas de nouvelle action pour l'IANA. Les paragraphes qui suivent sont conservés pour des raisons historiques.

 	7.1	Identifiant de protocole de charge utile SCTP
L'IANA a alloué une valeur de M3UA pour l'identifiant de protocole de charge utile dans le tronçon Données SCTP. L'identifiant de protocole de charge utile SCTP a été enregistré : M3UA    "3"

La valeur d'identifiant de protocole de charge utile SCTP "3" DEVRAIT être incluse dans chaque tronçon SCTP DATA pour indiquer que le SCTP porte le protocole M3UA. La valeur "0" (non spécifiée) est aussi admise mais aucune autre valeur NE DOIT être utilisée. Cet identifiant de protocole de charge utile n'est pas directement utilisé par SCTP mais PEUT être utilisé par certaines entités de réseau pour identifier le type d'informations portées dans un tronçon DATA.

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

 	7.2	Numéro d'accès M3UA
L'IANA a enregistré le numéro d'accès SCTP (et UDP/TCP) 2905 pour M3UA. Il est recommandé que les SGP utilisent ce numéro d'accès SCTP pour l'écoute de nouvelles connexions. Les SGP PEUVENT aussi utiliser à la place des numéros d'accès SCTP configurés statiquement.

 	7.3	Extensions de protocole M3UA
Ce protocole peut aussi être étendu par 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,
- par la définition de paramètres de message supplémentaires,

La définition et l'utilisation de classes, types, et paramètres nouveaux de message fait partie intégrante des couches d'adaptation SIGTRAN. Donc, ces extensions sont allouées par l'IANA par action de consensus de l'IETF comme défini dans les lignes directrices pour la réaction d'une section Considérations relatives à l'IANA dans les RFC [RFC2434].

L'extension proposée ne doit en aucune façon contrecarrer le fonctionnement général du protocole.

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

 	7.3.2	Types de message définis par l'IETF
La documentation pour un nouveau type de message DOIT inclure les informations suivantes :

(a) Un nom long et un nom court pour le nouveau type de message.
(b) Une description de la structure du message.
(c) Une définition et description détaillées de l'utilisation prévue de chaque champ du message.
(d) Une description procédurale détaillée de l'utilisation du nouveau type de message dans le fonctionnement du protocole.
(e) Une description détaillée des conditions d'erreur à 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 avec un message d'erreur (ERR) ("Type de message non pris en charge").

 	7.3.3	Extension de paramètre définie 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.2.
(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 dans quelle circonstances plusieurs instances de ce type de paramètre peuvent se trouver dans le même message.

 	8.	Remerciements
Les auteurs tiennent à remercier Antonio Roque Alvarez, Joyce Archibald, Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes, Antonio Canete, Nikhil Jain, Roland Jesske, Joe Keller, Kurt Kite, Ming Lin, Steve Lorusso, Naoto Makinae, Howard May, Francois Mouillaud, Barry Nagelberg, Neil Olson, Heinz Prantner, Shyamal Prasad, Mukesh Punhani, Selvam Rengasami, John Schantz, Ray Singh, Michael Tuexen, Nitin Tomar, Gery Verwimp, Tim Vetter, Kazuo Watanabe, Ben Wilson, et beaucoup d'autres de leurs précieux commentaires et suggestions.

 	9.	Contributeurs au document
Ian Rytina - Ericsson
Guy Mousseau - Nortel Networks
Lyndon Ong - Ciena
Hanns Juergen Schwarzbauer - Siemens
Klaus Gradischnig - Detecon Inc.
Mallesh Kalla - Telcordia
Normand Glaude - Performance Technologies
Brian Bidulock - OpenSS7
John Loughney - Nokia
Greg Sidebottom - Signatus Technologies

 	10.	Références
 	10.1	Références normatives

[ETS300356-1]	ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services"

[ETS300008-1]	ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN); Signalling System No.7; Message Transfer Part (MTP) to support international interconnection; Part 1: Protocol specification"

[ETS300009-1]	ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN); Signalling System No.7; Signalling Connection Control Part (SCCP) (connectionless and connection-oriented class 2) to support international interconnection; Part 1: Protocol specification"

[ISUP]	ANSI T1.113 - "Signaling System Number 7 - ISDN User Part"

[Q.700-705]	Recommandations UIT-T Q.700 à Q.705, "Système de signalisation n° 7 (SS7) – sous système transfert de message (STM)".

[Q.711-715]	Recommandations UIT-T Q.711 à Q.715, "Système de signalisation n° 7 (SS7) – sous système de contrôle de connexion de signalisation (SCCP)"

[Q.76x]	Recommandations UIT-T Q.761 à Q.767, "Système de signalisation n° 7 (SS7) – sous système utilisateur RNIS (ISUP)"

[RFC3629]	F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", STD 63, novembre 2003.

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

[T1.111]	ANSI T1.111 "Signaling System Number 7 - Message Transfer Part".

[T1.112]	ANSI T1.112 "Signaling System Number 7 - Signaling Connection Control Part".

[T1.113]	ANSI T1.113 - "Signaling System Number 7 - ISDN User Part".

 	10.2	Références pour information

[ETS300287-1]	ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN); Signalling System No.7; Transaction Capabilities (TC) version 2; Part 1: Protocol specification".

[JT.Q704]	Telecommunication Technology Committee (TTC) Standard JT-Q704, "Message Transfer Part Signaling Network Functions", 28 avril 1992.

[Q.720]	Recommandation UIT-T Q.720, "Sous système utilisateur téléphoniqque".

[Q.771-775]	Recommandations UIT-T Q.771 à Q.775, "Système de signalisation n° 7 (SS7) – capacités de transaction (TCAP)".

[Q.2110]	Recommandation UIT-T Q.2110, "Couche d'adaptation ATM pour le RNIS-LB - protocole en mode connexion spécifique du service (SSCOP)".

[Q.2140]	Recommandation UIT-T Q.2140, "Couche d'adaptation ATM pour le RNIS-LB – Fonction de coordination spécifique du service - Fonction de signalisation à l'interface de nœud de réseau (SSCF à NNI)".

[Q.2210]	Recommandation UIT-T Q.2210 "Fonctions de niveau 3 du sous sytème de transfert de message et messages utilisant les services de la Recommandation UIT-T Q.2140".

[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.)

[RFC3331]	K. Morneault et autres, "Sous-système de transfert de message (SSTM2) du système de signalisation n° 7 (SS7) – Couche d'adaptation d'usager", septembre 2002. (P.S.)

[RFC4165]	T. George et autres, "Sous-système n° 2 de transfert de messages (SSTM2) du système de signalisation n° 7 (SS7) – Couche d'adaptation d'homologue à homologue d'utilisateur (M2PA)", septembre 2005. (P.S.)

[T1.114]	ANSI T1.114 "Signaling System Number 7 - Transaction Capabilities Application Part".

[TS325.410]	3GPP TS 25.410 V4.0.0 (2001-04) "Technical Specification - 3rd Generation partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu Interface: General Aspects et Principles".

 	Appendices
 	A.1	Architecture de réseau de signalisation
Une passerelle de signalisation est utilisée pour prendre en charge le transport du trafic de signalisation d'utilisateur MTP3 reçu du réseau SS7 à plusieurs ASP répartis (par exemple, des MGC et des bases de données IP). Il est clair que le protocole M3UA n'est pas destiné à satisfaire des exigences de performances et de fiabilité pour un tel transport par lui même. Cependant, la conjonction d'une architecture répartie et de réseaux redondants fournit un support pour un transport fiable du trafic de signalisation sur IP. Le protocole M3UA 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 aux exigences les plus contraignantes de fiabilité et de performances de la signalisation SS7 pour les réseaux de niveau opérateur, les opérateurs de réseau pourraient exiger qu'aucun point de défaillance ne soit présent dans l'architecture de réseau de bout en bout entre un nœud SS7 et une application fondée sur IP. Cela peut normalement être réalisé par l'utilisation de SGP ou SG redondants, d'hôtes redondants, et la fourniture de chemins de réseau IP redondants à qualité de service encadrée pour les associations SCTP entre points d'extrémité SCTP. Visiblement, la fiabilité de la SG, du MGC, et autres éléments fonctionnels fondés sur IP doit aussi être prise en compte. La distribution des ASP et SGP au sein des hôtes disponibles PEUT aussi être considérée. Par exemple, pour un serveur d'application particulier, les ASP concernés pourraient être répartis sur au moins deux hôtes.

Un exemple d'architecture de réseau physique pertinente pour le fonctionnement au niveau opérateur SS7 dans le domaine de réseau IP est montré à la Figure A-1 ci-dessous :

          SG                                      MGC
   Hôte n°1*************                          ************** Hôte n° 3
          *  ********__*__________________________*__********  *   =
          *  *SGP1.1*__*_____      _______________*__* ASP1 *  *  MGC1
          *  ********  *     \    /               *  ********  *
          *  ********__*______\__/________________*__********  *
          *  *SGP2.1*__*_______\/______      _____*__* ASP2 *  *
          *  ********  *       /\      |    |     *  ********  *
          *      :     *      /  \     |    |     *      :     *
          *  ********  *     /    \    |    |     *  ********  *
          *  * SGPn *  *     |    |    |    |     *  * ASPn *  *
          *  ********  *     |    |    |    |     *  ********  *
          **************     |    |    |    |     **************
                             |    |    \    /
  Hôte n°2**************     |    |     \  /      ************** Hôte n°4
          *  ********__*_____|    |______\/_______*__********  *   =
          *  *SGP1.2*__*_________________/\_______*__* ASP1 *  *  MGC2
          *  ********  *                /  \      *  ********  *
          *  ********__*_______________/    \_____*__********  *
          *  *SGP2.2*__*__________________________*__* ASP2 *  *
          *  ********  *                          *  ********  *
          *      :     *     associations SCTP    *      :     *
          *  ********  *                          *  ********  *
          *  * SGPn *  *                          *  * ASPn *  *
          *  ********  *                          *  ********  *
          **************                          **************

SGP1.1 et SGP1.2 font partie de SG1
SGP2.1 et SGP2.2 font partie de SG2

Figure A-1 - Modèle physique

Dans ce modèle, chaque hôte peut avoir de nombreux processus d'application. Dans le cas du MGC, un ASP peut fournir le service à un ou plusieurs serveurs d'application, et est identifié comme un point d'extrémité SCTP. Un ou plusieurs processus de passerelle de signalisation constituent une seule passerelle de signalisation.

Cet exemple de modèle peut aussi être appliqué à la signalisation de IPSP à IPSP. Dans ce cas, chaque IPSP peut avoir ses services distribués à travers deux hôtes ou plus et peut avoir plusieurs processus de serveur sur chaque hôte.

Dans l'exemple ci-dessus, chaque processus de signalisation (SGP, ASP, ou IPSP) est le point d'extrémité de plus d'une association SCTP, conduisant à plus d'un autre processus de signalisation. Pour effectuer cela, un processus de signalisation doit être capable de prendre en charge la distribution des messages M3UA à de nombreuses associations simultanément actives. Cette fonction de distribution de message est fondée sur l'état des clés d'acheminement provisionnées, l'état des chemins de signalisation aux points de signalisation dans le réseau SS7, et le modèle de redondance (actif-en attente, partage de charge, diffusion, n+k) du processus de signalisation distant.

Pour les réseaux de niveau opérateur, la défaillance ou l’isolation d’un processus de signalisation particulier ne devrait pas causer la perte d'appels ou transactions stables. Cela implique que les processus de signalisation doivent, dans certains cas, partager l'état d'appel/transaction ou être capables de passer les informations d'état d'appel entre chacun d'eux. Dans le cas d'ASP qui effectuent le traitement d'appel, la coordination peut aussi être exigée avec la passerelle de supports concernée pour transférer le contrôle du MGC pour une terminaison de circuit particulière. Cependant, ce partage ou communication des informations d'état d'appel/transaction sort du domaine d'application du présent document.

Ce modèle sert d'exemple. M3UA n'impose pas de restrictions sur l'affichage exact des éléments de réseau, les algorithmes de distribution de messages, et la distribution des processus de signalisation. Il fournit plutôt un cadre et un ensemble de messages qui permettent une architecture de réseau de signalisation souple et adaptable, visant à assurer la fiabilité et les performances.

 	A.2.	Modèles de redondance
 	A.2.1	Redondance de serveur d'application
Au SGP, une liste de serveurs d'application contient les ASP actifs et inactifs pour prendre en charge la diffusion des ASP, le partage de charge, et les procédures de reprise sur défaillance. La liste des ASP au sein de la logique de serveur d'application est mise à jour dans le SGP pour refléter le ou les processus de serveur d'application actifs.

Par exemple, dans le réseau montré à la Figure 1, tous les messages au DPC x pourraient être envoyés à l'ASP1 dans l'hôte  3 ou à l'ASP1 dans l'hôte 4. La liste des AS au SGP1 dans l'hôte Hôte 1 pourrait ressembler à ce qui suit :

clé d'acheminement {DPC=x) - "serveur d'application n° 1"
         ASP1/hôte3  - État = Actif
         ASP1/hôte4  - État = Inactif

Dans ce cas de redondance "1+1", l'ASP1 dans l'Hôte 3 va envoyer tous les messages entrants avec DPC=x. L'ASP1 dans l'Hôte 4 va normalement être amené à l'état "actif" en cas de défaillance, ou perte de connexité de ASP1/Hôte1.

La liste des AS au SGP1 dans l'Hôte 1 pourrait aussi être établie en mode partage de charge :

clé d'acheminement {DPC=x) - "serveur d'application n° 1"
         ASP1/hôte3  - État = Actif
         ASP1/hôte4  - État = Inactif

Dans ce cas, les deux ASP vont envoyer une portion du trafic. Par exemple, les deux ASP pourraient ensemble former une base de données, où les interrogations entrantes peuvent être envoyées à tout ASP actif.

Un opérateur réseau pourrait devoir faire attention au choix des informations d'acheminement à utiliser comme clé d'acheminement pour un AS particulier.

Dans le processus de reprise sur défaillance, il est recommandé que, dans le cas d'ASP qui prennent en charge le traitement d'appel, les appels stables n'échouent pas. Il est possible que les appels en "transition" puissent échouer, bien que des mesures de communication entre les ASP impliqués puissent être utilisées pour atténuer cela.

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. Tout protocole d'ASP à ASP pour prendre en charge cette fonction sort du domaine d'application du présent document.

 	A.2.2	Redondance de passerelle de signalisation
Les passerelles de signalisation peuvent aussi être réparties sur plusieurs hôtes. Un peu comme le modèle d'AS, les SG peuvent comporter un ou plusieurs processus de SG (SGP), répartis sur un ou plusieurs hôtes, en utilisant un modèle actif/sauvegarde ou de partage de charge. Si un SGP perd toute la connexité SS7, ou une partie, et que d'autres SGP existent, le SGP peut terminer les associations SCTP avec les ASP concernés.

Il est donc possible à un ASP d'acheminer les messages de signalisation destinés au réseau SS7 en utilisant plus d'un SGP. Dans ce modèle, une passerelle de signalisation est déployée comme une grappe d'hôtes agissant comme une seule SG. Un modèle de redondance principal/sauvegarde est possible, où l'indisponibilité de l'association SCTP à un SGP principal pourrait être utilisée pour réacheminer le trafic affecté sur un SGP de remplacement. Un modèle de partage de charge est possible, où les messages de signalisation sont à charge partagée entre plusieurs SGP. Un modèle de diffusion est aussi possible, où les messages de signalisation sont envoyés à chaque SGP actif dans la SG. La distribution des messages d'utilisateur MTP3 sur les SGP devrait être faite de façon à minimiser la rupture de séquence des messages, comme exigé par le sous système utilisateur SS7.

Il peut aussi être possible à un ASP d'utiliser plus d'une SG pour accéder à un point d'extrémité SS7 spécifique, dans un modèle qui ressemble à une paire de STP SS7 conjoints. Normalement, les STP SS7 sont déployés en paires conjointes, avec partage de la charge de trafic entre elles. D'autres modèles sont aussi possibles, sous réserve des limitations des lignes directrices de provisionnement du réseau SS7 local.

Du point de vue de la couche M3UA à un ASP, une SG particulière est capable de transférer le trafic à une destination X provisionnée SS7 si une association SCTP avec au moins un SGP de la SG est établie, le SGP a retourné un accusé de réception à l'ASP pour indiquer que l'ASP traite activement le trafic pour cette destination X, le SGP n'a pas indiqué que la destination X est inaccessible, et le SGP n'a pas indiqué de redémarrage MTP. Quand un ASP est configuré à utiliser plusieurs SGP pour transférer du trafic au réseau SS7, l'ASP doit conserver la connaissance de la capacité actuelle des SGP à traiter le trafic pour les destinations intéressantes. Ces informations sont cruciales pour la fiabilité globale du service, pour les modèles actif/sauvegarde, de partage de charge, et de diffusion, dans le cas de défaillances et récupération et d'activités de maintenance. L'ASP M3UA peut aussi utiliser ces informations pour les besoins d'évitement d'encombrement. La distribution des messages d'utilisateur MTP3 sur les SGP devrait être faite de façon à minimiser la rupture de séquence des messages, comme exigé par le sous système utilisateur SS7.

 	Adresse des éditeurs
Ken Morneault	Javier Pastor-Balbas	
Cisco Systems Inc.	Ericsson Espana S.A.	
13615 Dulles Technology Drive	C/ Retama 1	
Herndon, VA  20171 	28045 Madrid 	
USA	Espagne	
mél : kmorneau@cisco.com 	mél : j.javier.pastor@ericsson.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 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, le IETF TRUST 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 encloses ne viole 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 le 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 fourni par l'activité de soutien administratif de l'IETF (IASA).