RFC3331 SS7 MTP2 – couche d’adaptation d’utilisateur Morneault & autres

Groupe de travail Réseau

K. Morneault, Cisco Systems

Request for Comments : 3331

R. Dantu, NetRake

Catégorie : En cours de normalisation

G. Sidebottom, Signatus Technologies

septembre 2002

B. Bidulock, OpenSS7

Traduction Claude Brière de L’Isle

J. Heitz, Lucent



Système de signalisation n°7 (SS7) Transfert de message partie 2 (MTP2) – couche d’adaptation d’utilisateur



Statut de ce mémoire

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

(La présente traduction incorpore les errata 1425 et 1426 du 16/05/2008)


Notice de copyright

Copyright (C) The Internet Society (2002). Tous droits réservés


Résumé

Le présent document définit un protocole pour la prise en charge sur IP des messages de signalisation d’utilisateur de partie 2 du transfert de message du système de signalisation n° 7 (SS7 MTP2, Signaling System 7 Message Transfer Part 2) en utilisant le protocole de transmission de contrôle de flux (SCTP, Stream Control Transmission Protocol). Ce protocole sera utilisé entre une passerelle de signalisation (SG, Signalling Gateway) et un contrôleur de passerelle de supports (MGC, Media Gateway Controller). On suppose que la SG reçoit la signalisation SS7 sur une interface SS7 standard en utilisant la partie transfert de message SS7 (MTP, Message Transfer Part) pour fournir le transport. La passerelle de signalisation va agir comme un terminal de liaison de signalisation.


Table des Matières

1. Introduction 2

1.1 Domaine d’application 2

1.2 Terminologie 2

1.3 Généralités sur M2UA 3

1.4 Services fournis par la couche d’adaptation M2UA 5

1.5 Fonctions fournies par la couche M2UA 6

1.6 Définition des limites de M2UA 8

2. Conventions 10

3. Éléments du protocole 10

3.1 En-tête commun de message 10

3.2 En-tête de message M2UA 13

3.3 Messages M2UA 14

4. Procédures 37

4.1 Procédures pour la prise en charge de la couche d’utilisateur M2UA 37

4.2 Réception de primitives de la gestion de couches 38

4.3 Maintenance d’état d’AS et d’ASP 39

4.4 Procédures de gestion de clé de liaison 46

5. Exemples de procédure d’adaptation d’utilisateur MTP2 (M2UA) 47

5.1 Exemples d’établissement d’associations entre SGP et MGC 47

5.2 Exemples de reprise de trafic d’ASP sur échec 48

5.3 Procédures frontières de SGP à MGC, MTP niveau 2 à MTP niveau 3 49

6. Valeur des temporisateurs 52

7. Considérations pour la sécurité 52

7.1 Menaces 52

7.2 Protéger la confidentialité 52

8. Considérations relatives à l’IANA 52

8.1 Identifiant de protocole de charge utile SCTP 52

8.2 Extensions au protocole M2UA 53

9. Remerciements 53

10. Références 54

10.1 Normatives 54

10.2 Informatives 54

Appendice A Architecture de réseau de signalisation 54

11. Adresse des auteurs 55

Déclaration complète de droits de reproduction 56



1. Introduction


Le présent document définit un protocole pour la prise en charge des messages de signalisation d’utilisateur MTP2 [Q.701], [GR-246], [T1.111], [GR-246] (c’est-à-dire, MTP3) du SS7 [Q.700] sur IP en utilisant le protocole de transmission de contrôle de flux (SCTP, Stream Control Transmission Protocol) [RFC2960]. Ce protocole sera utilisé entre une passerelle de signalisation (SG) et un contrôleur de passerelle support (MGC).


    1. 1.1 Domaine d’application


On a besoin d’un protocole de signalisation de réseau à commutation de circuit (SCN, Switched Circuit Network) d’une passerelle de signalisation (SG, Signalling Gateway) à un contrôleur de passerelle support (MGC, Media Gateway Controller) [RFC2719]. Le mécanisme de livraison vise les objectifs suivants :

* prise en charge de la frontière d’interface entre MTP niveau 2 / MTP niveau 3,

* prise en charge de la communication entre modules de gestion de couches sur la SG et le MGC,

* prise en charge de la gestion des associations actives de SCTP entre la SG et le MGC.


La SG termine au niveau 2 de MTP et le MGC termine au niveau 3 de MTP et au dessus. En d’autre termes, la SG va transporter des messages de niveau 3 MTP sur un réseau IP jusqu’à un MGC.


    1. 1.2 Terminologie


Serveur d’application (AS) – entité logique qui sert une instance d’application spécifique. Un exemple de serveur d’application est un MGC traitant le MTP niveau 3 et le traitement d’appel pour des liaisons SS7 terminées par des routeurs de signalisation. En pratique, un AS est modélisé au SG comme une liste ordonnée d’un ou plusieurs processus serveur en rapport avec l’application (par exemple, primaire, secondaire, tertiaire, ...).


Processus de serveur d’application (ASP, Application Server Process) – instance de processus d’un serveur d’application. Des exemples de processus de serveur d’application sont des instances de MGC actives ou en attente.


Association – une association se réfère à une association SCTP. L’association va assurer le transport pour la livraison des unités de données de protocole pour une ou plusieurs interfaces.


Transport arrière (backhaul) – se réfère au transport de signaux depuis le point d’interface du flux de données associé (c’est-à-dire la fonction SG dans le MGU) jusqu’au point de traitement de l’appel (c’est-à-dire le MGCU) si ce n’est pas local [RFC2719].


Reprise sur défaillance (Fail-over) – capacité de réacheminer du trafic de signalisation en tant que de besoin sur un processus de serveur d’application de remplacement au sein d’un serveur d’application en cas de défaillance ou d’indisponibilité d’un processus de serveur d’application actuellement utilisé. Reprise sur défaillance PEUT s’appliquer au retour en service d’un processus de serveur d’application précédemment indisponible.


Hôte – plateforme de calcul sur laquelle fonctionne le processus ASP.


Interface – pour les besoins du présent document, une interface est une liaison de signalisation SS7.


Identifiant d’interface – il identifie l’interface physique à la SG pour laquelle les messages de signalisation sont envoyés/reçus. Le format du paramètre Identifiant d’interface peut être du texte ou un entier, dont les valeurs sont allouées conformément à la politique de l’opérateur de réseau. Les valeurs utilisées n’ont qu’une signification locale, coordonnée entre la SG et l’ASP.


Gestion de couche – c’est une fonction nodale dans une SG ou ASP qui traite les entrées et sorties entre la couche M2UA et une entité de gestion locale.


Clé de liaison – c’est une valeur localement unique (entre un ASP et une SG) qui identifie une demande d’enregistrement d’une paire particulière de liaison de données de signalisation et d’un terminal de signalisation.


MTP (Message Transfer Part) – sous système de transfert de message du protocole SS7.


MTP2 – MTP niveau 2, couche de liaison des données de signalisation de SS7.


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


MTP2-Usager – protocole qui utilise les services de MTP niveau 2 (c’est-à-dire, MTP3).


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


Liaison de données de signalisation (SDL, Signalling Data Link) – se réfère à une facilité de communications spécifique qui connecte deux terminaux de liaison de signalisation.


Passerelle de signalisation (SG, Signalling Gateway) – c’est un agent de signalisation à la bordure du réseau IP. Une SG apparaît au SS7 comme un ou plusieurs terminaux de liaison de signalisation qui sont connectés à une ou plusieurs liaisons de données de signalisation dans le réseau SS7. Une SG contient un ensemble d’un ou plusieurs processus de passerelle de signalisation uniques, sur lesquels un ou plusieurs traitent normalement activement le trafic. Lorsque une SG contient plus d’un SGP, la SG est une entité logique.


Processus de passerelle de signalisation (SGP, Signalling Gateway Process) – c’est une instance de traitement qui utilise M2UA pour communiquer avec un terminal de liaison de signalisation. Il sert de processus actif de secours ou de partage de tâche d’une passerelle de signalisation.


Terminal de liaison de signalisation (SLT, Signalling Link Terminal) – cela se réfère aux moyens d’effectuer toutes les fonctions définies au niveau 2 de MTP sans considération de leur mise en œuvre [Q.701-5], [T1.111].


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


    1. 1.3 Généralités sur M2UA


Le cadre architectural qui a été défini pour le transport de signalisation de SCN sur IP [RFC2719] utilise deux composants : un protocole commun de transport de signalisation et un module d’adaptation pour prendre en charge les services attendus par un protocole de signalisation de SCN particulier à partir de sa couche de protocole sous-jacente.


Au sein de ce cadre architectural, le présent document définit un module d’adaptation de SCN qui convient pour le transport des messages d’utilisateur MTP2 du SS7. Le seul utilisateur MTP2 du SS7 est MTP3. Le M2UA utilise les services du protocole de transmission de contrôle de flux de la [RFC2960] comme protocole sous-jacent fiable de transport commun de signalisation.


Dans une passerelle de signalisation, on s’attend à ce que la signalisation d’utilisateur MTP2 SS7 soit transmise et reçue du RTPC (réseau téléphonique public commuté) sur une interface réseau SS7 standard, utilisant les niveaux 1 et 2 du sous-système de transfert de message de SS7 [Q.701-5], [T1.111], [GR-246] pour fournir un transport fiable des messages de signalisation d’utilisateur MTP3 de et vers le point d’extrémité de signalisation (SEP, Signalling End Point) ou le point de transfert de signalisation (STP, Signalling Transfer Point) SS7. La SG fournit alors un inter fonctionnement des fonctions de transport avec le transport IP, afin de transférer les messages de signalisation d’utilisateur MTP2 de et vers un processus de serveur d’application où la couche de protocole d’utilisateur MTP2 homologue existe.


      1. 1.3.1 Exemple - SG à MGC


Dans une passerelle de signalisation, on s’attend à ce que la signalisation SS7 soit reçue sur une terminaison de réseau SS7 standard, utilisant le sous-système de transfert de message SS7 (MTP) pour fournir le transport des messages de signalisation SS7 de et vers un point d’extrémité de signalisation SS7 (SEP) ou un point de transfert de signalisation SS7 (STP). En d’autres termes, la SG agit comme un terminal de liaison de signalisation (SLT, Signalling Link Terminal) [Q.701-5], [T1.111]. La SG fournit alors un inter fonctionnement des fonctions de transport avec le transport de signalisation IP, afin de transporter les messages de signalisation MTP3 au MGC où existe la couche de protocole MTP3 homologue, comme le montre la figure ci-dessous.


****** SS7 ****** IP *******

*SEP *-----------* SG *-------------* MGC *

****** ****** *******

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

|S7UP| |S7UP|

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

|MTP + |MTP |

| L3 | (NIF) |L3 |

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

|MTP | |MTP |M2UA| |M2UA|

| | | +----+ +----+

|L2 | |L2 |SCTP| |SCTP|

|L1 | |L1 +----+ +----+

| | | |IP | |IP |

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

L1-L2 – couche 1, couche 2

NIF – Fonction d’inter fonctionnement nodal

SEP – Point d’extrémité de signalisation SS7

IP – Protocole Internet

SCTP – Protocole de transmission de contrôle de flux [RFC2960])


Figure 1 : M2UA dans l’application de SG à MGC


Note : Les STP PEUVENT être présents dans le chemin SS7 entre le SEP et la SG.


Il est recommandé que le M2UA utilise les services du protocole de transmission de contrôle de flux (SCTP, Stream Control Transmission Protocol) [RFC2960] comme protocole sous-jacent de transport de signalisation commune fiable. L’utilisation de SCTP fournit les caractéristiques suivantes :

- livraison explicite en mode paquet (pas en mode flux)

- livraison en séquence des messages d’utilisateur au sein de plusieurs flux, avec une option pour la livraison dans l’ordre d’arrivée des messages individuels d’utilisateur,

- multiplexage facultatif des messages d’utilisateur dans des datagrammes SCTP,

- tolérance au fautes au niveau réseau à travers la prise en charge du multi-rattachement à l’une et/ou l’autre extrémité d’une association,

- résistance aux attaques par inondation et usurpation d’identité,

- segmentation des données pour se conformer à la taille de MTU du chemin découverte.


Il y a des scénarios sans exigences de redondance et des scénarios dans lesquels la redondance est prise en charge en dessous de la couche transport. Dans ces cas, les fonctions de SCTP ci-dessus NE PEUVENT PAS être une exigence et TCP peut être utilisé comme protocole de transport commun sous-jacent.


      1. 1.3.2 Modèle et terminologie de reprise sur défaillance d’ASP

La couche M2UA prend en charge les fonctions de reprise sur défaillance d’ASP afin d’obtenir une plus grande disponibilité de la capacité de traitement d’appel et de transaction. Tous les messages MTP2-usager entrant sur un SGP en provenance du réseau SS7 sont alloués au serveur d’application unique, sur la base de l’identifiant d’interface du message.


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


      1. 1.3.3 Modèle client/serveur

Il est recommandé que le SGP et l’ASP soient capables de prendre en charge le fonctionnement à la fois de client et de serveur. Les points d’extrémité homologues qui utilisent M2UA DEVRAIENT être configurés de façon à ce que l’un prenne toujours le rôle de client et l’autre le rôle de serveur pour initier les associations SCTP. L’orientation par défaut serait que le SGP prenne le rôle de serveur et l’ASP celui de client. Dans ce cas, les ASP DEVRAIENT initier l’association SCTP avec le SGP.


Le numéro alloué enregistré d’utilisateur SCTP et TCP pour M2UA est 2904.


    1. 1.4 Services fournis par la couche d’adaptation M2UA


L’interface SS7 MTP3/MTP2 (MTP2-usager) est conservée au point de terminaison dans le réseau IP, de sorte que la couche de protocole M2UA est nécessaire pour fournir à ses usagers l’ensemble de services équivalent à celui fourni par le niveau 2 de MTP au niveau 3 MTP.


      1. 1.4.1 Prise en charge de la limite d’interface MTP niveau 2 / niveau 3

Le M2UA prend en charge une limite d’interface MTP niveau 2 / MTP niveau 3 qui permet un fonctionnement sans coupure, ou aussi sans coupure que possible, des homologues MTP2-usager dans le SS7 et les domaines IP. Un exemple des primitives qui doivent être prises en charge se trouve dans [Q.2140].


      1. 1.4.2 Prise en charge de la communication entre modules de gestion de couche sur SG et MGC

La couche M2UA a besoin de fournir des messages qui vont faciliter la communication entre les modules de gestion de couche sur la SG et le MGC. Pour faciliter le rapport des erreurs qui surviennent à cause du scénario de transport arrière de MTP niveau 3, on définit la primitive suivante :


M-ERROR


Le message M-ERROR est utilisé pour indiquer une erreur dans un message M2UA reçu (par exemple, une valeur d’identifiant d’interface n’est pas connue de la SG).


      1. 1.4.3 Prise en charge de la gestion d’associations actives entre SG et MGC

La couche M2UA sur la SG conserve l’état des ASP configurés. On définit ci-dessous un ensemble de primitives entre la couche M2UA et la gestion de couche pour aider la gestion de couche à gérer la ou les associations entre la SG et le MGC. La couche M2UA peut être informée par la gestion de couche d’avoir à établir une association SCTP avec un nœud M2UA homologue. Cette procédure peut être réalisée en utilisant la primitive M-SCTP ESTABLISH.


M-SCTP_ESTABLISH

La primitive M-SCTP_ESTABLISH est utilisée pour demander, indiquer et confirmer l’établissement d’une association SCTP avec un nœud M2UA homologue.


M-SCTP_RELEASE

La primitive M-SCTP_RELEASE est utilisée pour demander, indiquer, et confirmer la libération d’une association SCTP avec un nœud M2UA homologue.


La couche M2UA PEUT aussi avoir besoin d’informer la gestion de couche de l’état de la ou des associations SCTP. Cela peut être réalisé en utilisant la primitive suivante.


M-SCTP_STATUS

La primitive M-SCTP_STATUS est utilisée pour demander et indiquer l’état de la ou des associations SCTP sous-jacentes.


La gestion de couche PEUT avoir besoin d’informer la couche M2UA d’un état d’AS/ASP (c’est-à-dire, échec, actif, etc.) afin que des messages puissent être échangés entre les homologues de couche M2UA pour arrêter le trafic pour l’utilisateur local M2UA. Cela peut être réalisé en utilisant la primitive suivante.


M-ASP_STATUS

L’état d’ASP est mémorisé à l’intérieur de la couche M2UA sur les deux côtés SG et MGC. La primitive M-ASP_STATUS peut être utilisée par la gestion de couche pour demander l’état du processus de serveur d’application à la couche M2UA. Cette primitive peut aussi être utilisée pour indiquer l’état du processus de serveur d’application.


M-ASP_MODIFY

La primitive M-ASP_MODIFY peut être utilisée par la gestion de couche pour modifier l’état du processus de serveur d’application. En d’autres termes, la gestion de couche sur le côté ASP utilise cette primitive pour initier les procédures d’ASPM (maintenance d’ASP).


M-AS_STATUS

La primitive M-AS_STATUS peut être utilisée par la gestion de couche pour demander l’état du serveur d’application. Cette primitive peut aussi être utilisée pour indiquer l’état du serveur d’application.


    1. 1.5 Fonctions fournies par la couche M2UA

      1. 1.5.1 Transposition

La couche M2UA DOIT conserver une transposition d’un identifiant d’interface en interface physique sur la passerelle de signalisation. Une interface physique serait une ligne V.35, un intervalle de temps de ligne T1, un intervalle de temps de ligne E1, etc. La couche M2UA DOIT aussi entretenir une transposition de l’identifiant d’interface en association SCTP et avec le flux en rapport au sein de l’association.


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


Noter que seulement un SGP DEVRAIT fournir des services de terminal de liaison de signalisation à une liaison SS7. Donc, au sein d’une SG, un serveur d’application DEVRAIT être actif pour un seul SGP à un instant donné.


Un exemple de l’aspect logique de la relation entre une liaison SS7, un identifiant d’interface, un AS et un ASP dans un SGP est montré ci-dessous:


/-------------------------------------------------+

/ /----------------------------------------------|--+

/ / v |

/ / +----+ act+-----+ +-------+ -+--+|-+-

Liaison1 SS7-------->|IID |-+ +-->| ASP |-->| Assoc | v

/ +----+ | +----+ | +-----+ +-------+ -+--+--+-

/ +->| AS |--+ Flux

/ +----+ | +----+ att+-----+

Liaison2 SS7-------->|IID |-+ | ASP |

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

IID = Identifiant d’interface

att = en attente

Un SGP PEUT prendre en charge plus d’un AS. Un AS PEUT prendre en charge plus d’un identifiant d’interface.


      1. 1.5.2 Prise en charge de la gestion d’associations SCTP entre les SGP et les ASP

La couche M2UA à la SG entretient l’état de disponibilité de tous les ASP configurés, afin de gérer les associations de SCTP et le trafic entre la SG et les ASP. De même, l’état actif/inactif du ou des ASP distants est aussi entretenu. Le ou les ASP actifs sont ceux qui reçoivent actuellement du trafic du SG.


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


La couche M2UA PEUT aussi avoir besoin d’informer la gestion locale de l’état des associations SCTP sous-jacentes en utilisant la demande M-SCTP_STATUS et la primitive d’indication. Par exemple, le M2UA PEUT informer la gestion locale de la raison de la libération d’une association SCTP, déterminée localement au sein de la couche M2UA ou par une primitive provenant de SCTP.


Aussi, la couche M2UA peut avoir besoin d’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. 1.5.3 État des ASP

La couche M2UA sur la SG DOIT entretenir l’état des ASP qu’elle prend en charge. L’état d’un ASP change à cause de la réception de messages d’homologue à homologue (messages ASPM comme décrit au paragraphe 3.3.2) ou de la réception d’indications de la part de l’association SCTP locale. Les procédures de transition d’état d’ASP sont décrites au paragraphe 4.3.1.


À un SGP, une liste de serveurs d’application PEUT contenir des ASP actifs et inactifs pour prendre en charge les procédures de récupération d’ASP. Lorsque, par exemple, un ASP principal et un ASP de secours sont tous deux disponibles, le protocole d’homologue M2UA est obligé de contrôler quel ASP est actuellement actif. La liste ordonnée des ASP au sein d’un serveur d’application logique est gardée à jour dans le SGP pour refléter le processus de serveur d’application actif.


Aussi, la couche M2UA PEUT avoir besoin d’informer la gestion locale de changement d’état d’un ASP ou AS. Cela peut être réalisé en utilisant les primitives M-ASP_STATUS ou M-AS_STATUS.


      1. 1.5.4 Spécificités de SCTP

        1. 1.5.4.1 Gestion de flux SCTP

SCTP permet d’ouvrir un nombre de flux spécifié par l’utilisateur durant l’initialisation de l’association. Il est de la responsabilité de la couche M2UA de s’assurer de la gestion appropriée de ces flux. À cause de la nature unidirectionnelle des flux, une couche M2UA ne connaît pas les informations de flux de la couche M2UA de son homologue. Pour cette raison, l’identifiant d’interface est dans l’en-tête de message M2UA.


L’utilisation de flux SCTP au sein de M2UA est recommandée afin de minimiser les délais de transmission et de mise en mémoire tampon, améliorant par là les performances globales et la fiabilité des éléments de signalisation. Un flux SCTP séparé peut être utilisé pour chaque liaison SS7. Ou, une mise en œuvre peut choisir de partager la liaison SS7 sur plusieurs flux sur la base du sélecteur de liaison de signalisation (SLS, Signalling Link Selecior). Cette méthode peut être particulièrement intéressante pour les liaisons SS7 à grande vitesse (MTP3b) car elles ont un numéro de séquence de 24 bits et le numéro de séquence de flux est de 16 bits.


Le flux SCTP '0' NE DEVRAIT PAS être utilisé pour les messages d’adaptation d’utilisateur MTP2 (MAUP, MTP2 User Adaptation) (voir la Section 3) car le flux '0' DEVRAIT être utilisé seulement pour les messages de gestion d’ASP (ASPM, ASP Management) (voir le paragraphe 4.3.3).


      1. 1.5.5 Inter fonctionnement transparent de la gestion de réseau SS7

La couche M2UA sur le SGP DEVRAIT passer une indication d’indisponibilité à l’utilisateur M2UA (MTP3) à la gestion de couche locale, si l’ASP actuellement actif vient de l’état ACTIF. Les actions effectuées par M2UA sur le SGP par rapport au niveau 2 de MTP devraient être conformes aux spécifications MTP appropriées.


      1. 1.5.6 Contrôle de flux / encombrement

Il est possible que la couche M2UA soit informée du début et de la suppression de l’encombrement du réseau IP au moyen d’une fonction dépendante de la mise en œuvre (c’est-à-dire, une indication provenant du SCTP). Le traitement de cette indication d’encombrement par la couche M2UA dépend de la mise en œuvre. Cependant, les actions entreprises par la SG devraient être conformes à la spécification MTP appropriée et devraient permettre que la fonction SS7 (par exemple, le contrôle de flux) soit correctement entretenue.


      1. 1.5.7 Examen de l’état de la liaison SS7

Après une reprise sur défaillance d’un ASP à un autre ASP, il peut être nécessaire que la M2UA sur l’ASP examine l’état réel de la liaison SS7 actuelle pour s’assurer de la cohérence. La M2UA sur le SGP va répondre à la demande d’examen par des informations concernant l’état actuel de la liaison SS7 (c’est-à-dire en service, hors service, état encombré, état LPO/RPO).


    1. 1.6 Définition des limites de M2UA

      1. 1.6.1 Définition de la limite M2UA / MTP niveau 3

DATA (données)

ESTABLISH (établir)

RELEASE (libérer)

STATE (état)

DATA RETRIEVAL (restitution des données)

DATA RETRIEVAL COMPLETE (achèvement de la restitution des données)


      1. 1.6.2 Définition de la limite M2UA / MTP niveau 2

DATA

ESTABLISH

RELEASE

STATE

DATA RETRIEVAL

DATA RETRIEVAL COMPLETE


      1. 1.6.3 Définition de la limite de couche inférieure entre M2UA et SCTP

Les primitives de couche supérieure et de couche de gestion sont fournies dans la [RFC2960].


      1. 1.6.4 Définition de la limite gestion de couche / M2UA

Demande M-SCTP_ESTABLISH

Direction : LM -> M2UA

Objet : La gestion de couches (LM) demande à l’ASP d’établir une association SCTP avec un SGP.


Confirmation M-SCTP_ESTABLISH

Direction : M2UA -> LM

Objet : ASP confirme à LM qu’il a établi une association SCTP avec un SGP.


Indication M-SCTP_ESTABLISH

Direction : M2UA -> LM

Objet : SGP informe la LM qu’un ASP a établi une association SCTP.


Demande M-SCTP_RELEASE

Direction : LM -> M2UA

Objet : LM demande à l’ASP de libérer une association SCTP avec le SGP.


Confirmation M-SCTP_RELEASE

Direction : M2UA -> LM

Objet : L’ASP confirme à la LM qu’il a libéré l’association SCTP avec le SGP.


Indication M-SCTP_RELEASE

Direction : M2UA -> LM

Objet : Le SGP informe la LM que l’ASP a libéré une association SCTP.


Indication M-SCTP_RESTART

Direction : M2UA -> LM

Objet : M2UA informe la LM qu’une indication Redémarrage SCTP a été reçue.


Demande M-SCTP_STATUS

Direction : LM -> M2UA

Objet : La LM demande à la M2UA de faire rapport de l’état de l’association SCTP.


Indication M-SCTP_STATUS

Direction : M2UA -> LM

Objet : La M2UA fait rapport de l’état de l’association SCTP.


Demande M-ASP_STATUS

Direction : LM -> M2UA

Objet : La LM demande au SGP de faire rapport de l’état de l’ASP distant.


Indication M-ASP_STATUS

Direction : M2UA -> LM

Objet : Le SGP fait rapport de l’état de l’ASP distant.


Demande M-AS_STATUS

Direction : LM -> M2UA

Objet : La LM demande à la SG de faire rapport de l’état de l’AS.


Indication M-AS_STATUS

Direction : M2UA -> LM

Objet : La SG fait rapport de l’état de l’AS.


Indication M-NOTIFY

Direction : M2UA -> LM

Objet : L’ASP fait rapport de la réception d’un message NOTIFY de son homologue.


Indication M-ERROR

Direction : M2UA -> LM

Objet : L’ASP ou le SGP fait rapport de la réception d’un message ERROR de son homologue.


Demande M-ASP_UP

Direction : LM -> M2UA

Objet : La LM demande à l’ASP de commencer son opération et d’envoyer un message ASP UP (éveillé) au SGP.


Confirmation M-ASP_UP

Direction : M2UA -> LM

Objet : L’ASP rapporte qu’il a reçu un message d’accusé de réception de ASP UP du SGP.


Demande M-ASP_DOWN

Direction : LM -> M2UA

Objet : La LM demande à l’ASP d’arrêter son opération et d’envoyer un message ASP DOWN (mort) au SGP.


Confirmation M-ASP_DOWN

Direction : M2UA -> LM

Objet : L’ASP rapporte qu’il a reçu un message d’accusé de réception ASP DOWN du SGP.


Demande M-ASP_ACTIVE

Direction : LM -> M2UA

Objet : La LM demande à l’ASP d’envoyer un message ASP ACTIVE au SGP.


Confirmation M-ASP_ACTIVE

Direction : M2UA -> LM

Objet : L’ASP rapporte qu’il a reçu un message d’accusé de réception ASP ACTIVE du SGP.


Demande M-ASP_INACTIVE

Direction : LM -> M2UA

Objet : La LM demande à l’ASP d’envoyer un message ASP INACTIVE au SGP.


Confirmation M-ASP_INACTIVE

Direction : M2UA -> LM

Objet : L’ASP rapporte qu’il a reçu un message d’accusé de réception ASP INACTIVE du SGP.


Demande M-LINK_KEY_REG

Direction : LM -> M2UA

Objet : La LM demande à l’ASP d’enregistrer la clé de liaison auprès de la SG en envoyant un message REG REQ (demande d’enregistrement).


Confirmation M-LINK_KEY_REG

Direction : M2UA -> LM

Objet : L’ASP rapporte à la LM qu’il a bien reçu un message REG RSP (réponse d’enregistrement) de la SG.


Indication M-LINK_KEY_REG

Direction : M2UA -> LM

Objet : La SG rapporte à la LM qu’elle a bien traité un message REG REQ entrant provenant de l’ASP.


Demande M-LINK_KEY_DEREG

Direction : LM -> M2UA

Objet : La LM demande à l’ASP de désenregistrer la clé de liaison auprès de la SG en envoyant un message DEREG REQ.


Confirmation M-LINK_KEY_DEREG

Direction : M2UA -> LM

Objet : L’ASP rapporte à la LM qu’il a bien reçu un message DEREG RSP de la SG.


Indication M-LINK_KEY_DEREG

Direction : M2UA -> LM

Objet : La SG rapporte à la LM qu’elle a bien traité un message DEREG REQ entrant provenant de l’ASP.


2. Conventions

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMETE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC2119].


3. Éléments du protocole


La présente section décrit le format de divers messages utilisés dans ce protocole.


    1. 3.1 En-tête commun de message


Les messages de protocole pour la couche d’adaptation MTP2-Usager exigent une structure de message qui contienne une version, une classe de message, un type de message, une longueur de message, et un contenu de message. Cet en-tête de message est commun à toutes les couches d’adaptation de protocole de signalisation:


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 message| Type message |

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

| Longueur de message |

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


Figure 2 : En-tête commun de message


Tous les champs d’un message M2UA DOIVENT être transmis dans l’ordre des octets du réseau, sauf indication contraire.


      1. 3.1.1 Version

Le champ version contient la version de la couche d’adaptation M2UA. Les versions acceptées sont :


Valeur Version

1 Livraison 1.0


      1. 3.1.2 Réservé

Le champ Réservé est de 8 bits. Il DEVRAIT être rempli de '0' par l’envoyeur et ignoré par le receveur.


      1. 3.1.3 Classe de message

La liste suivante contient les classes de message valides :


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

0 Message de gestion (MGMT) [IUA/M2UA/M3UA/SUA]

1 Messages de transfert [M3UA]

2 Messages de gestion de réseau de signalisation SS7 (SSNM) [M3UA/SUA]

3 Messages de maintenance d’état d’ASP (ASPSM) [IUA/M2UA/M3UA/SUA]

4 Messages de maintenance de trafic d’ASP (ASPTM) [IUA/M2UA/M3UA/SUA]

5 Messages de transport de primitives de limites Q.921/Q.931 (QPTM) [IUA]

6 Messages d’adaptation MTP2 usager (MAUP) [M2UA]

7 Messages sans connexion [SUA]

8 Messages en mode connexion [SUA]

9 Messages de gestion de clé d’acheminement (RKM) (M3UA)

10 Messages de gestion d’identifiant d’interface (IIM) (M2UA)

11 à 127 Réservé par l’IETF

128 à 255 Réservé pour des extensions de classe de message définies par l’IETF


      1. 3.1.4 Type de message

La liste suivante contient les types de message pour les classes de message valides :


Messages d’adaptation d’utilisateur MTP2 (MAUP, MTP2 User Adaptation)

0 Réservé

1 Données

2 Demande d’établissement

3 Confirmation d’établissement

4 Demande de libération

5 Confirmation de libération

6 Indication de libération

7 Demande d’état

8 Confirmation d’état

9 Indication d’état

10 Demande de restitution de données

11 Confirmation de restitution de données

12 Indication de restitution de données

13 Indication de l’achèvement de la restitution des données

14 Indication d’encombrement

15 Accusé de réception de données

16 à 127 Réservé par l’IETF

128 à 255 Réservé pour des extensions MAUP définies par l’IETF


Messages de maintenance d’état du processus de serveur d’application (ASPSM, ASP State Maintenance)

0 Réservé

1 ASP actif (UP)

2 ASP arrêté (DOWN)

3 En vie (Heartbeat) (BEAT)

4 accusé de réception d’ASP UP (UP ACK)

5 accusé de réception d’ASP DOWN (DOWN ACK)

6 accusé de réception de En vie (BEAT ACK)

7 à 127 Réservé par l’IETF

128 à 255 Réservé pour des extensions d’ASPSM définies par l’IETF


Messages de maintenance de trafic du processus de serveur d’application (ASPTM, ASP Traffic Maintenance)

0 Réservé

1 ASP actif (ACTIVE)

2 ASP inactif (INACTIVE)

3 Accusé de réception d’ASP actif (ACTIVE ACK)

4 Accusé de réception d’ASP inactif (INACTIVE ACK)

5 à 127 Réservé par l’IETF

128 à 255 Réservé pour des extensions à ASPTM définies par l’IETF


Messages de gestion (MGMT)

0 Erreur (ERR)

1 Notifier (NTFY)

2 à 127 Réservé par l’IETF

128 à 255 Réservé pour des extensions à MGMT définies par l’IETF


Messages de gestion d’identifiant d’interface (IIM, Interface Identifier Management)

0 Réservé

1 Demande d’enregistrement (REG REQ)

2 Réponse d’enregistrement (REG RSP)

3 Demande de désenregistrement (DEREG REQ)

4 Réponse de désenregistrement (DEREG RSP)

5 à 127 Réservé par l’IETF

128 à 255 Réservé pour des extensions à IIM définies par l’IETF


      1. 3.1.5 Longueur de message

Longueur de message définit la longueur du message en octets, y compris l’en-tête. Longueur de message DOIT inclure les octets de bourrage de paramètre, s’il y en a. Longueur de message NE DOIT PAS être plus long qu’un message MTP3 [Q.701-5], [T1.111], [GR-246], [Q704] plus la longueur des en-têtes communs et de message M2UA.


      1. 3.1.6 Format de paramètre de longueur variable

Les messages M2UA consistent en un en-tête commun suivi par zéro, un ou plusieurs paramètres de longueur variable, comme défini par le type de message. Les paramètres de longueur variable contenus dans un message sont définis dans un format Étiquette-Longueur-Valeur montré ci-dessous.


0 1 2 3

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

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

| Étiquette de paramètre | Longueur de paramètre |

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

\ \

/ Valeur de paramètre /

\ \

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


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


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

Le champ Type est un identifiant de 16 bits du type de paramètre. Il prend une valeur de 0 à 65 534. Les paramètres communs utilisés par les couches d’adaptation sont dans la gamme de 0x00 à 0xff. Les paramètres spécifiques de M2UA ont des étiquettes dans la gamme de 0x300 à 0x3ff.


Les étiquettes de paramètre commun (utilisées par toutes les couches d’adaptation d’utilisateur) qu’utilise M2UA sont définies ci-dessous :


Valeur du paramètre Nom du paramètre

0 (0x00) Réservé

1 (0x01) Identifiant d’interface (entier)

2 (0x02) Inutilisé

3 (0x03) Identifiant d’interface (Texte)

4 (0x04) Chaîne d’informations

5 (0x05) Inutilisé

6 (0x06) Inutilisé

7 (0x07) Informations de diagnostic

8 (0x08) Identifiant d’interface (gamme d’entiers)

9 (0x09) Données de vie

10 (0x0a) Inutilisé

11 (0x0b) Type de mode de trafic

12 (0x0c) Code d’erreur

13 (0x0d) Type/informations d’état

14 (0x0e) Inutilisé

15 (0x0f) Inutilisé

16 (0x10) Inutilisé

17 (0x11) Identifiant d’ASP

18 (0x12) Inutilisé

19 (0x13) Identifiant de corrélation

18-255 Réservé


Les étiquettes de paramètre spécifiques de M2UA sont définies comme suit :

Valeur du paramètre Nom du paramètre

768 (0x0300) Données de protocole 1

769 (0x0301) Données de protocole 2 (TTC)

770 (0x0302) Demande d’état

771 (0x0303) Événement d’état

772 (0x0304) État d’encombrement

773 (0x0305) État éliminé

774 (0x0306) Action

775 (0x0307) Numéro de séquence

776 (0x0308) Résultat de restitution

777 (0x0309) Clé de liaison

778 (0x030a) Identifiant de liaison locale

779 (0x030b) Identifiant de terminal de données de signalisation (SDT, Signalling Data Terminal)

780 (0x030c) Identifiant de liaison de données de signalisation (SDL, Signalling Data Link)

781 (0x030d) Résultat d’enregistrement

782 (0x030e) État d’enregistrement

783 (0x030f) Résultat de désenregistrement

784 (0x0310) État de désenregistrement


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 d’une longueur zéro aurait un champ Longueur de 4. La longueur du paramètre n’inclut pas d’octets de bourrage.

Valeur de paramètre : longueur variable.

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

La longueur totale d’un paramètre (incluant les champs Étiquette, Longueur 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 la fin du paramètre (c’est-à-dire, après le champ Valeur du paramètre) avec des octets tout à zéro. La longueur du bourrage N’EST PAS incluse dans le champ Longueur du paramètre. Un envoyeur NE DOIT PAS bourrer avec plus de 3 octets. Le receveur DOIT ignorer les octets de bourrage.


    1. 3.2 En-tête de message M2UA


En plus de l’en-tête commun de message, il y a aura un en-tête de message spécifique de M2UA. Il va suivre immédiatement l’en-tête commun de message, mais ne sera utilisé que avec les messages MAUP.

Cet en-tête de message va contenir l’identifiant d’interface. Celui-ci identifie l’interface physique au SG pour lequel les messages de signalisation sont envoyés/reçus. Le format du paramètre Identifiant d’interface peut être du texte ou un entier, dont les valeurs sont allouées selon la politique de l’opérateur réseau. Les valeurs utilisées n’ont qu’une signification locale, coordonnée entre la SG et l’ASP.

L’identifiant d’interface formaté en entier DOIT être pris en charge. L’identifiant d’interface formaté en texte PEUT facultativement être pris en charge.


0 1 2 3

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

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

| Étiquette (0x1) | Longueur = 8 |

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

| Identifiant d’interface (entier) |

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


Figure 3 : En-tête de message M2UA (Identifiant d’interface exprimé par un entier)


La valeur de l’étiquette pour l’identifiant d’interface fondé sur l’entier est 0x1. La longueur est toujours réglée à une valeur de 8.


0 1 2 3

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

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

| Étiquette (0x3) | Longueur |

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

/ \

\ Identifiant d’interface (texte) /

/ \

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


Figure 4 : En-tête de message M2UA (Identifiant d’interface exprimé par un texte)


La valeur d’étiquette pour l’identifiant fondé sur le texte est 0x3. Le codage de l’identifiant est ANSI X3.4-1986 [ANSI X3.4]. La longueur maximum de la chaîne de l’identifiant d’interface fondé sur le texte est de 255 octets. La longueur de l’étiquette est égale à la longueur de la chaîne du nom de l’identifiant d’interface plus quatre octets pour les champs Étiquette et Longueur.


    1. 3.3 Messages M2UA


Les paragraphes qui suivent définissent les contenus des messages et des paramètres. Les messages M2UA vont utiliser l’en-tête commun de message (Figure 2) et l’en-tête de message M2UA (Figure 3 et Figure 4).


      1. 3.3.1 Messages d’adaptation d’utilisateur MTP2

        1. 3.3.1.1 Données

Le message Données contient une unité de données de protocole (PDU, Protocol Data Unit) MTP2-usager SS7. Le message Données contient les paramètres suivants :

Données de protocole (obligatoire)

Identifiant de corrélation (facultatif)


Le format des paramètres du message Données est le suivant :


0 1 2 3

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

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

| Étiquette (0x300) | Longueur |

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

/ \

\ Données de protocole /

/ \

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

| Étiquette (0x13) | Longueur = 8 |

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

| Identifiant de corrélation |

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


Le champ Données de protocole contient le message d’application MTP2-usager dans l’ordre des octets du réseau en commençant par l’octet Informations de signalisation (SIO). Le paramètre Identifiant de corrélation identifie de façon univoque la MSU portée dans le champ Données de protocole au sein d’un AS. Ce paramètre Identifiant de corrélation est alloué par le M2UA envoyeur. L’objet de l’identifiant de corrélation est de permettre à un ASP nouvellement actif de synchroniser son traitement du trafic dans chaque flux ordonné avec les autres ASP dans le groupe de diffusion.


Le format d’un message Données avec les paramètres de PDU TTC est le suivant :


0 1 2 3

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

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

| Étiquette (0x301) | Longueur |

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

/ \

\ Données de protocole TTC /

/ \

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

| Étiquette (0x13) | Longueur = 8 |

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

| Identifiant de corrélation |

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


Le champ Données de protocole contient le message d’application MTP2-usager dans l’ordre des octets du réseau en commençant par l’octet Indicateur de longueur (LI). La variante japonaise de TTC utilise les bits inutilisés de l’octet LI pour la priorité.


La longueur de Données de protocole et de Données de protocole TTC NE DOIT PAS excéder la longueur d’un message d’application MTP2-usager [Q.701-5], [T1.111], [Q704].


        1. 3.3.1.2 Message Accusé de réception de données

Le message Accusé de réception de données contient l’identifiant de corrélation du message Données dont le M2UA envoyeur accuse la réception comme ayant été traitée avec succès chez l’homologue M2UA.


Le message Accusé de réception de données contient le paramètre suivant :

Identifiant de corrélation (Obligatoire)


Le format suivant DOIT être utilisé pour le message Accusé de réception de données :


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 (0x13) | Longueur = 8 |

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

| Identifiant de corrélation |

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


Le paramètre Identifiant de corrélation du message Données et le message Accusé de réception de données donnent un mécanisme, pour les mises en œuvre de SG qui sont capables d’en tirer parti, pour obtenir un accusé de réception que la MSU a été bien transférée au M2UA homologue avant d’accuser réception de la MSU à l’homologue SS7, supprimant le risque de perte de messages due à l’échec d’association ou à l’encombrement du SCTP.


Le message Accusé de réception de données DOIT être envoyé si un paramètre Identifiant de corrélation est reçu de l’homologue. Autrement, le message Accusé de réception de données NE DOIT PAS être envoyé.


Si l’accusé de réception de données n’est pas envoyé pour le ou les identifiants de corrélation ou si il est envoyé avec des identifiants de corrélation invalides, la liaison SS7 va finalement échouer à cause du manque d’accusés de réception MTP de niveau 2 des MSU de l’homologue SS7.


        1. 3.3.1.3 Établir (demande, confirmation)

Le message de demande Établir est utilisé pour établir la liaison SS7 ou pour indiquer que le canal a été établi. Le MGC contrôle l’état de la liaison SS7. Lorsque le MGC désire que la liaison SS7 soit en service, il va envoyer le message Demande d’établissement. Noter que le SGP PEUT déjà avoir la liaison SS7 établie à sa couche. Si il en est ainsi, à réception d’une demande Établir, le SGP ne fait rien sauf envoyer un Établissement confirmé.


Lorsque le MGC envoie un message M2UA Demande d’établissement, le MGC PEUT lancer un temporisateur. Ce temporisateur va s’arrêter à réception d’un Établissement confirmé M2UA. Si le temporisateur arrive à expiration, le MGC va renvoyer le message M2UA Demande d’établissement et relancer le temporisateur. En d’autres termes, le MGC PEUT continuer de demander l’établissement de la liaison de données sur une base périodique jusqu’à ce que l’état désiré soit réalisé ou que quelque autre action soit effectuée (notifier la couche gestion).


Le mode (normal ou urgence) pour mettre la liaison SS7 en service est normal par défaut. La demande d’état (décrite au paragraphe 3.3.1.5) peut être utilisée pour changer le mode en urgence.


        1. 3.3.1.4 Libération (demande, indication, confirmation)

Ce message Demande de libération est utilisé pour libérer le canal. Les messages Confirmation de libération et Indication de libération sont utilisés pour indiquer que le canal a été libéré.


        1. 3.3.1.5 Demande d’état

Le message Demande d’état peut être envoyé d’un MGC pour causer une action sur une liaison SS7 particulière prise en charge par le processus de passerelle de signalisation. Le SGP envoie une Confirmation d’état au MGC si l’action a été bien achevée. Confirmation d’état reflète la valeur d’état reçue dans le message Demande d’état.


Le message Demande d’état contient le paramètre suivant :

État (obligatoire)


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 (0x302) | Longueur = 8 |

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

| État |

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


Les valeurs valides pour État sont données dans le tableau suivant :


Nom Valeur Description

STATUS_LPO_SET 0x0 Demande Panne du processeur local

STATUS_LPO_CLEAR 0x1 Demande Panne du processeur local réparée

STATUS_EMER_SET 0x2 Demande Alignement d’urgence

STATUS_EMER_CLEAR 0x3 Demande Alignement normal (annule l’urgence)

STATUS_FLUSH_BUFFERS 0x4 Purger ou libérer les files d’attentes de réception, émission et retransmission

STATUS_CONTINUE 0x5 Continuer ou reprendre

STATUS_CLEAR_RTB 0x6 Libérer la file d’attente de retransmission

STATUS_AUDIT 0x7 État d’audit de la liaison

STATUS_CONG_CLEAR 0x8 Encombrement résorbé

STATUS_CONG_ACCEPT 0x9 Encombrement accepté

STATUS_CONG_DISCARD 0xa Élimination pour encombrement


        1. 3.3.1.6 Confirmation d’état

Le message Confirmation d’état (State Confirm) va être envoyé par le SGP en réponse à une demande d'état de la part du MGC. Confirmation d’état reflète la valeur d'état reçue dans le message Demande d'état.


Le message Confirmation d’état contient le paramètre suivant :

État (obligatoire)


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 (0x302) | Longueur = 8 |7

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

| État |

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


Les valeurs valides pour État sont montrées dans le tableau suivant. La valeur du champ État DEVRAIT refléter la valeur reçue dans le message Demande d'état.


Nom Valeur Description

STATUS_LPO_SET 0x0 Demande Panne du processeur local

STATUS_LPO_CLEAR 0x1 Demande Panne du processeur local réparée

STATUS_EMER_SET 0x2 Demande Alignement d’urgence

STATUS_EMER_CLEAR 0x3 Demande Alignement normal (annule l’urgence)

STATUS_FLUSH_BUFFERS 0x4 Purger ou libérer les files d’attentes de réception, émission et retransmission

STATUS_CONTINUE 0x5 Continuer ou reprendre

STATUS_CLEAR_RTB 0x6 Libérer la file d’attente de retransmission

STATUS_AUDIT 0x7 État d’audit de la liaison

STATUS_CONG_CLEAR 0x8 Encombrement résorbé

STATUS_CONG_ACCEPT 0x9 Encombrement accepté

STATUS_CONG_DISCARD 0xa Élimination pour encombrement


        1. 3.3.1.7 Indication d'état

Le message MTP2 Indication d'état peut être envoyé d'un SGP à un ASP pour indiquer une condition sur une liaison SS7.


Le message Indication d'état contient le paramètre suivant :

Événement (obligatoire)


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 (0x303) | Longueur = 8 |

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

| Événement |

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


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


Nom Valeur Description

EVENT_RPO_ENTER 0x1 Panne du processeur d’entrée distant

EVENT_RPO_EXIT 0x2 Panne du processeur de sortie distant

EVENT_LPO_ENTER 0x3 Panne du processeur de liaison d’entrée

EVENT_LPO_EXIT 0x4 Panne du processeur de liaison de sortie


        1. 3.3.1.8 Indication d'encombrement

Le message Indication d'encombrement peut être envoyé d'un processus de passerelle de signalisation à un ASP pour indiquer l'état d'encombrement et l'état Éliminé d'une liaison SS7. Lorsque le remplissage de la mémoire tampon de MSU augmente au dessus d'un seuil Onset ou diminue en dessous d'un seuil Abattement ou franchit un seuil Éliminé (Discard) dans l'une ou l'autre direction, le SGP DEVRA envoyer un message Indication d'encombrement lorsque il prend en charge les variantes MTP2 de SS7 qui acceptent plusieurs niveaux d'encombrement.


Le SGP ne DEVRA envoyer le message que lorsque il y a réellement un changement dans le niveau Éliminé ou dans le niveau Encombrement à rapporter, ce qui signifie qu'il est différent du message envoyé précédemment. De plus, le SGP DEVRA utiliser un algorithme dépendant de la mise en œuvre pour limiter la fréquence des messages d'indication d'encombrement.


Une mise en œuvre peut facultativement envoyer des messages Indication d'encombrement sur un flux de "haute priorité" afin de potentiellement réduire le délai.


Le message Indication d'encombrement contient les paramètres suivants :

État Encombrement (obligatoire)

État Éliminé (facultatif)


0 1 2 3

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

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

| Étiquette (0x304) | Longueur = 8 |

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

| État Encombrement |

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

| Étiquette (0x305) | Longueur = 8 |

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

| État Discard |

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


Les valeurs valides pour l’état Encombrement et l’état Éliminé sont montrées dans le tableau suivant .


Nom Valeur Description

LEVEL_NONE 0x0 Pas d’encombrement

LEVEL_1 0x1 Niveau d’encombrement 1

LEVEL_2 0x2 Niveau d’encombrement 2

LEVEL_3 0x3 Niveau d’encombrement 3


Pour les réseaux SS7 qui n’acceptent pas plusieurs niveaux d’encombrement, seules les valeurs de LEVEL_NONE et LEVEL_3 seront utilisées. Pour les réseaux SS7 qui acceptent plusieurs niveaux d’encombrement, il est possible d’utiliser toutes les valeurs. Se reporter à [Q.701-5], [T1.111] et [Q.751.1] pour les détails sur les états Encombrement et Éliminé des liaisons de signalisation SS7.


        1. 3.3.1.9 Demande de restitution (Retrieval)

Le message MTP2 Demande de restitution est utilisé durant la procédure de changement MTP de niveau 3 pour demander au BSN de restituer les PDU des files d’attentes d’émission et de retransmission ou de purger les PDU de la file d’attente de retransmission. Des exemples de l’utilisation de Demande de restitution pour le changement de liaison SS7 sont fournis au paragraphe 5.3.6.


Le message Demande de restitution contient les paramètres suivants :

Action (obligatoire)

Numéro de séquence (facultatif)


0 1 2 3

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

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

| Étiquette (0x306) | Longueur = 8 |

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

| Action |

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

| Étiquette (0x307) | Longueur = 8 |

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

| Numéro de séquence |

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


Les valeurs valides pour Action figurent dans le tableau suivant.


Nom Valeur Description

ACTION_RTRV_BSN 0x1 Restituer les numéros de séquence antérieurs

ACTION_RTRV_MSGS 0x2 Restituer les PDU des files d’attente d’émission et de retransmission


Dans le message Demande de restitution, le champ Numéro de séquence NE DEVRAIT PAS être présent si le champ Action est ACTION_RTRV_BSN. Le champ Numéro de séquence contient le Numéro de séquence antérieur (FSN, Forward Sequence Number) de l’extrémité distante si l’action est ACTION_RTRV_MSGS.


        1. 3.3.1.10 Restitution confirmée

Le message MTP2 Restitution confirmée (Retrieval Confirm) est envoyé par la passerelle de signalisation en réponse à un message Demande de restitution. Des exemples d’utilisation de la confirmation de restitution pour les changements de liaison SS7 sont fournis au paragraphe 5.3.6.


Le message Restitution confirmée contient les paramètres suivants :

Action (obligatoire)

Résultat (obligatoire)

Numéro de séquence (facultatif)


0 1 2 3

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

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

| Étiquette(0x306) | Longueur = 8 |

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

| Action |

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

| Étiquette (0x308) | Longueur = 8 |

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

| Résultat |

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

| Étiquette (0x307) | Longueur = 8 |

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

| Numéro de séquence |

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


Les valeurs valides pour Action sont les mêmes que dans une Demande de restitution.


Les valeurs pour Résultat sont les suivantes :

Nom Valeur Description

RESULT_SUCCESS 0x0 Action réussie

RESULT_FAILURE 0x1 Échec de l’action


Lorsque le processus de passerelle de signalisation envoie une confirmation de restitution à une demande de restitution, il fait écho au champ Action. Si l’action était ACTION_RTRV_BSN et si le SGP a bien restitué le BSN, le SGP va mettre le numéro de séquence antérieur (BSN, backward sequence number) dans le champ Numéro de séquence et va indiquer la réussite dans le champ Résultat. Si le BSN n’a pas pu être restitué, le champ Numéro de séquence ne sera pas inclus et le champ Résultat va indiquer l’échec.


Pour une confirmation de restitution avec une action de ACTION_RTRV_MSGS, la valeur du champ Résultat va indiquer la réussite ou l’échec. Un échec signifie que les mémoires tampon n’ont pas pu être récupérées. Le champ Numéro de séquence n’est pas utilisé avec ACTION_RTRV_MSGS.


        1. 3.3.1.11 Indication de restitution


Le message Indication de restitution (Retrieval Indication) est envoyé par la passerelle de signalisation avec une PDU provenant de la file d’attente d’émission ou de retransmission. Le message Indication de restitution ne contient pas de champ Action ou Numéro de séquence, mais juste une unité de données de protocole (PDU) MTP3 provenant de la file d’attente d’émission ou de retransmission. Des exemples d’utilisation de l’indication de restitution pour le changement de liaison SS7 sont fournis au paragraphe 5.3.6.


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 (0x300) | Longueur |

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

/ \

\ Données de protocole /

/ \

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


Pour les messages Données TTC, le paramètre suivant sera utilisé pour indiquer une PDU TTC qui commence à LI.


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 (0x301) | Longueur |

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

/ \

\ Données de protocole TTC /

/ \

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


La mise en œuvre de M2UA PEUT considérer l’utilisation du dispositif de mise en faisceau de SCTP pour les messages Indication de restitution.


        1. 3.3.1.12 Indication d’achèvement de restitution

Le message MTP2 Indication d’achèvement de restitution est exactement le même que le message MTP2 Indication de restitution, sauf qu’il indique aussi que la restitution est achevée. De plus, il PEUT contenir une PDU (qui DOIT être la dernière PDU) provenant de la file d’attente d’émission ou de retransmission.


      1. 3.3.2 Messages de maintenance de processus de serveur d’application (ASPM)

Les messages de maintenance de processus de serveur d’application (ASPM, Application Server Process Maintenance) vont seulement utiliser l’en-tête de message commun.


        1. 3.3.2.1 ASP actif (ASPUP)

Le message ASP actif (ASPUP) est utilisé pour indiquer à un homologue M2UA distant que la couche Adaptation est prête à recevoir du trafic ou des messages de maintenance.


Le message ASPUP contient les paramètres suivants :

Identifiant d’ASP (facultatif)

Chaîne d’informations (facultatif)


Note: L’identifiant d’ASP DOIT être utilisé lorsque le SGP ne peut pas identifier l’ASP par des informations d’adresse ou numéro d’accès préconfigurées (par exemple, lorsque un ASP est résident sur un hôte en utilisant l’allocation dynamique d’adresse/numéro d’accès).


Le format des paramètres du message ASPUP est le suivant :


0 1 2 3

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

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

| Étiquette (0x11) | Longueur = 8 |

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

| Identifiant d’ASP*e |

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

| Étiquette (0x4) | Longueur |

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

/ \

\ Chaîne d’informations /

/ \

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


Le paramètre facultatif Identifiant d’ASP va contenir une valeur unique qui est significative localement parmi les ASP qui prennent en charge un serveur d’application. Le SGP devrait sauvegarder l’identifiant d’ASP à utiliser, si nécessaire avec le message Notifier (voir au paragraphe 3.3.3.2).


Le paramètre facultatif Chaîne d’informations peut porter toute chaîne significative de caractères UTF-8 [RFC2279] avec le message. La longueur du paramètres Chaîne d’informations est de 0 à 255 octets. Aucune procédure n’est à présent identifiée pour son utilisation mais la chaîne d’informations PEUT être utilisée pour des besoins de débogage.


        1. 3.3.2.2 Accusé de réception d’ASPUP

Le message Accusé de réception d’ASPUP est utilisé pour reconnaître qu’un message ASPUP a été reçu d’un homologue M2UA distant.


Le message Accusé de réception d’ASPUP contient le paramètre suivant :

Chaîne d’informations (facultatif)


Le format du paramètre de message Accusé de réception d’ASPUP est le suivant :


0 1 2 3

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

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

| Étiquette (0x4) | Longueur |

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

/ \

\ Chaîne d’informations /

/ \

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


Le format et la description du paramètre facultatif Chaîne d’informations est le même que pour le message ASPUP (voir au paragraphe 3.3.2.1).


        1. 3.3.2.3 ASP arrêté (ASPDN)

Le message ASP arrêté (ASPDN) est utilisé pour indiquer à un homologue M2UA distant que la couche d’adaptation n’est pas prête à recevoir du trafic ou des messages de maintenance.

Le message ASPDN contient le paramètre suivant :

Chaîne d’informations (facultatif)

Le format du paramètre de message ASPDN est le suivant :


0 1 2 3

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

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

| Étiquette (0x4) | Longueur |

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

/ \

\ Chaîne d’informations /

/ \

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


Le format et la description du paramètre facultatif Chaîne d’informations est le même que pour le message ASPUP (voir au paragraphe 3.3.2.1).


        1. 3.3.2.4 Accusé de réception d’ASPDN

Le message Accusé de réception d’ASPDN est utilisé pour reconnaître qu’un message ASP arrêté a été reçu d’un homologue M2UA distant.

Le message Accusé de réception d’ASPDN contient le paramètre suivant :

Chaîne d’informations (facultatif)

Le format du paramètre de message Accusé de réception d’ASPDN est le suivant :

0 1 2 3

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

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

| Étiquette (0x4) | Longueur |

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

/ \

\ Chaîne d’informations /

/ \

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


Le format et la description du paramètre facultatif Chaîne d’informations est le même que pour le message ASPUP (voir au paragraphe 3.3.2.1).


        1. 3.3.2.5 En vie (BEAT)

Le message En vie est utilisé facultativement pour s’assurer que les homologues M2UA sont toujours disponibles les uns pour les autres.


Le message BEAT contient le paramètre suivant :

Données En vie (facultatif)


Le format du message BEAT est le suivant :


0 1 2 3

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

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

| Étiquette = 0x0009 | Longueur |

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

/ Données En vie /

\ \

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


Le nœud d’envoi définit le contenu du champ Données En vie. Il peut inclure un numéro de séquence de vie et /ou un horodatage, ou d’autres détails spécifiques de la mise en œuvre.


Le receveur d’un message En vie ne traite pas ce champ car il n’a de signification que pour l’envoyeur. Le receveur fait écho au contenu des Données En vie dans un message BEAT ACK.


        1. 3.3.2.6 Accusé de réception de En vie (BEAT ACK)

Le message Accusé de réception de En vie est envoyé en réponse à un message BEAT. Un homologue DOIT envoyer un BEAT ACK en réponse à un message BEAT. Il inclut tous les paramètres du message En vie reçu, sans aucun changement.


Le message BEAT ACK contient le paramètre suivant :

Données de En vie (facultatif)


Le format du message Accusé de réception de En vie est le suivant :


0 1 2 3

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

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

| Étiquette = 0x0009 | Longueur |

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

/ Données de En vie /

\ \

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


Le receveur d’un message Accusé de réception de En vie fait écho au contenu du champ Données de En vie sans autre traitement dans le champ Données de En vie du message d’accusé de réception de En vie.


        1. 3.3.2.7 ASP Actif (ASPAC)

Le message ASPAC est envoyé par un ASP pour indiquer à un SGP qu’il est actif et prêt à être utilisé.


Le message ASPAC contient les paramètres suivants :

Type de mode de trafic (facultatif)

Identifiant d’interface (facultatif)

- combinaison d’entier et de gammes d’entiers, OU

- chaîne (texte formaté)

Chaîne d’informations (facultatif)


Le format du message ASPAC qui utilise des identifiants d’interface formatés en entiers est le suivant :

0 1 2 3

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

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

| Étiquette (0xb) | Longueur = 8 |

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

| Type de mode de trafic |

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

| Étiquette (0x1=entier) | Longueur |

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

/ \

\ Interface Identifiers* /

/ \

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

| Étiquette (0x8=gamme d’entier)| Longueur |

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

| Début d’identifiant d’interface1* |

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

| Fin d’identifiant d’interface1* |

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

| Début d’identifiant d’interface2* |

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

| Fin d’identifiant d’interface2* |

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

. .

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

| Début d’identifiant d’interfaceN* |

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

| Fin d’identifiant d’interfaceN* |

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

\ Identifiants d’interface supplémentaires /

/ de type d’étiquette 0x1 ou 0x8 \

\ /

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

| Étiquette (0x4) | Longueur |

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

/ \

\ Chaîne d’informations /

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


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


0 1 2 3

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

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

| Étiquette (0xb) | Longueur = 8 |

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

| Type de mode de trafic |

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

| Étiquette (0x3=chaîne) | Longueur |

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

/ \

\ Identifiant d’interface* /

/ \

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

/ \

\ Identifiants d’interface supplémentaires /

/ de type d’étiquette 0x3 \

\ /

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

| Étiquette (0x4) | Longueur |

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

\ Chaîne d’informations /

/ \

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


Le paramètre Type de mode de trafic identifie le mode de trafic du fonctionnement de l’ASP au sein d’un AS. Les valeurs valides pour le type figurent dans le tableau suivant :


Valeur Description

0x1 Outrepasser

0x2 Partage de charge

0x3 Diffusion


Au sein d’un AS particulier, un seul type de mode de trafic peut être utilisé. La valeur Outrepasser indique que l’ASP fonctionne en mode Outrepasser, où l’ASP prend le contrôle de tout le trafic dans un serveur d’application (c’est-à-dire, le fonctionnement principal et de sauvegarde) outrepassant tous les ASP actuellement actifs dans l’AS. En mode de partage de charge, l’ASP va partager la distribution du trafic avec tout ASP actuellement actif. En mode diffusion, tous les ASP actifs reçoivent tous le trafic de messages dans le serveur d’application.


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


Si aucun identifiant d’interface n’est inclus, le message est pour tous les identifiants d’interface approvisionnés dans le ou les AS dans lesquels l’ASP est provisionné. Si seulement un sous ensemble des identifiants d’interface est inclus pour un AS, l’ASP est noté comme Actif pour tous les identifiants d’interface provisionnés pour cet AS.


Note : Si le paramètre facultatif Identifiant d’interface est présent, l’identifiant d’interface formaté comme entier DOIT être accepté, tandis que celui formaté en texte PEUT être accepté.


Un SGP qui reçoit un ASPAC avec un type de mode de trafic incorrect ou non accepté pour un certain identifiant d’interface va répondre par un message d’erreur (Cause : Mode de traitement du trafic non accepté).


Le format et la description du paramètre facultatif Chaîne d’informations sont les mêmes que pour le message ASPUP (voir au paragraphe 3.3.2.1).


        1. 3.3.2.8 Accusé de réception ASP Actif

Le message d’accusé de réception d’ASP Actif (ASPAC) est utilisé pour reconnaître qu’un message ASP a été reçu d’un homologue M2UA distant.

Le message d’accusé de réception d’ASPAC contient les paramètres suivants :

Type de mode de trafic (facultatif)

Identifiant d’interface (facultatif)

- combinaison d’entier et de gammes d’entiers, OU

- chaîne (format de texte)

Chaîne d’informations (facultatif)


Le format du message d’accusé de réception d’ASPAC avec des identifiants d’interface en format d’entiers est le suivant :


0 1 2 3

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

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

| Étiquette (0xb) | Longueur = 8 |

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

| Type de mode de trafic |

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

| Étiquette (0x1=entier) | Longueur |

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

/ \

\ Identifiants d’interface* /

/ \

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

| Étiquette (0x8=gamme d’entiers)| Longueur |

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

| Début d’identifiant d’interface1* |

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

| Fin d’identifiant d’interface1* |

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

| Début d’identifiant d’interface2* |

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

| Fin d’identifiant d’interface2* |

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

. .

. .

. .

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

| Début d’identifiant d’interfaceN* |

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

| Fin d’identifiant d’interfaceN* |

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

/ \

\ Identifiants d’interface supplémentaires /

/ de type d’étiquette 0x1 ou 0x8 \

\ /

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

| Étiquette (0x4) | Longueur |

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

/ \

\ Chaîne d’informations* /

/ \

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


Le format pour le message d’accusé de réception d’ASPAC avec des identifiants d’interface en format texte (chaîne) est le suivant :


0 1 2 3

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

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

| Étiquette (0xb) | Longueur |

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

| Type de mode de trafic |

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

| Étiquette (0x3=chaîne) | Longueur |

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

/ \

\ Identifiant d’interface* /

/ \

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

/ \

\ Identifiants d’interface supplémentaires /

/ de type d’étiquette 0x3 \

\ /

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

| Étiquette (0x4) | Longueur |

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

/ \

\ Chaîne d’informations* /

/ \

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


Le format et la description du paramètre facultatif Chaîne d’informations sont les mêmes que pour le message ASPUP (voir au paragraphe 3.3.2.1).


Le format du paramètre facultatif Identifiant d’interface est la même que pour le message ASP Actif (voir au paragraphe .3.2.7).


        1. 3.3.2.9 ASP Inactif (ASPIA)

Le message ASP Inactif (ASPIA) est envoyé par un ASP pour indiquer à un SGP qu’il n’a plus un ASP actif à utiliser parmi une liste des ASP. Le SGP va répondre par un messages Accusé de réception de ASPIA et soit éliminer les messages entrants, soit les mettre en mémoire tampon pendant un temps déterminé et en les éliminant ensuite.


Le message ASPIA contient les paramètres suivants :

Identifiants d’interface (facultatif)

- combinaison d’entier et de gammes d’entiers, OUR

- chaîne (format de texte)

Chaîne d’informations (facultatif)


Le format des paramètres du message ASP Inactif qui utilise les identifiants d’interface en format d’entier est le suivant :


0 1 2 3

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

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

| Étiquette (0x1=entier) | Longueur |

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

/ \

\ Identifiants d’interface* /

/ \

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

|Étiquette (0x8=gamme d’entier) | Longueur |

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

| Début d’identifiant d’interface1* |

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

| Fin d’identifiant d’interface1* |

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

| Début d’identifiant d’interface2* |

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

| Fin d’identifiant d’interface2* |

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

. .

. .

. .

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

| Début d’identifiant d’interfaceN* |

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

| Fin d’identifiant d’interfaceN* |

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

/ \

\ Identifiants d’interface supplémentaires /

/ de type d’étiquette 0x1 ou 0x8 \

\ /

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

| Étiquette (0x4) | Longueur |

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

/ \

\ Chaîne d’informations* /

/ \

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


Le format pour le message ASP Inactif qui utilise les identifiants d’interface en format de texte (chaîne) est le suivant :


0 1 2 3

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

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

| Étiquette (0x3=chaîne) | Longueur |

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

/ \

\ Identifiant d’interface* /

/ \

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

/ \

\ Identifiants d’interface supplémentaires /

/ de type d’étiquette 0x8 \

\ /

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

| Étiquette (0x4) | Longueur |

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

/ \

\ Chaîne d’informations* /

/ \

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


Le format du paramètre facultatif Identifiant d’interface est le même que pour le message ASP Actif (voir au paragraphe 3.3.2.7).


Le format et la description du paramètre facultatif Chaîne de paramètres est le même que pour le message ASPUP (voir au paragraphe 3.3.2.1).


Le paramètre facultatif Identifiants d’interface contient une liste d’entiers représentant des identifiants d’interface qui indexent le trafic de serveur d’application que l’ASP d’envoi est configuré/enregistré à recevoir, mais ne veut pas recevoir pour le moment.


        1. 3.3.2.10 Accusé de réception d’ASP Inactif

Le message Accusé de réception d’ASP Inactif (ASPIA) est utilisé pour reconnaître qu’un message ASP Inactif a été reçu d’un homologue M2UA distant.


Le message Accusé de réception d’ASPIA contient les paramètres suivants :

Identifiants d’interface (facultatif)

- combinaison d’entier et de gammes d’entiers, OUR

- chaîne (format de texte)

Chaîne d’informations (facultatif)


Le format du message Accusé de réception d’ASPIA est le suivant :


0 1 2 3

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

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

| Étiquette (0x1=entier) | Longueur |

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

/ \

\ Identifiants d’interface* /

/ \

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

|Étiquette (0x8=gamme d’entier) | Longueur |

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

| Début d’identifiant d’interface1* |

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

| Fin d’identifiant d’interface1* |

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

| Début d’identifiant d’interface2* |

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

| Fin d’identifiant d’interface2* |

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

. .

. .

. .

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

| Début d’identifiant d’interfaceN* |

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

| Fin d’identifiant d’interfaceN* |

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

/ \

\ Identifiants d’interface supplémentaires /

/ de type d’étiquette 0x1 ou 0x8 \

\ /

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

| Étiquette (0x4) | Longueur |

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

/ \

\ Chaîne d’informations* /

/ \

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


Le format du message Accusé de réception d’ASP Inactif utilisant des identifiants d’interface en format texte (chaîne) est le suivant :


0 1 2 3

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

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

| Étiquette (0x3=chaîne) | Longueur |

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

/ \

\ Interface Identifier* /

/ \

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

/ \

\ Identifiants d’interface supplémentaires /

/ de type d’étiquette 0x8 \

\ /

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

| Étiquette (0x4) | Longueur |

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

/ \

\ Chaîne d’informations* /

/ \

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


Le format du paramètre facultatif Identifiant d’interface est le même que pour le message ASP Actif (voir au paragraphe 3.3.2.7).


Le format et la description du paramètre facultatif Chaîne d’informations est le même que pour le message ASPUP (voir au paragraphe 3.3.2.1).


      1. 3.3.3 Messages de gestion de couche (MGMT)

        1. 3.3.3.1 Erreur (ERR)

Le message Erreur (ERR) 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.


Un message Erreur NE DOIT PAS être généré en réponse à d’autres messages Erreurs.


Le message ERR contient les paramètres suivants :

Code d’erreur (obligatoire)

Identifiant d’interface (facultatif)

Informations de diagnostic (facultatif)


Le format du message ERR est le suivant :


0 1 2 3

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

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

| Étiquette (0xc) | Longueur = 8 |

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

| Code d’erreur |

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

| Étiquette (0x1, 0x3, ou 0x8) | Longueur |

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

/ \

\ Identifiant(s) d’interface* /

/ \

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

| Étiquette (0x7) | Longueur |

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

/ \

\ Informations de diagnostic* /

/ \

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


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

Version invalide 0x1

Identifier d’interface invalide 0x2

Classe de message non acceptée 0x3

Type de message non acceptée 0x4

Mode de traitement du trafic non accepté 0x5

Message inattendu 0x6

Erreur de protocole 0x7

Type d’identifiant d’interface non accepté 0x8

Identifiant de flux invalide 0x9

Non utilisé dans M2UA 0xa

Non utilisé dans M2UA 0xb

Non utilisé dans M2UA 0xc

Refusé – Blocage de gestion 0xd

Identifiant d’ASP exigé 0xe

Identifiant d’ASP invalide 0xf

ASP Actif pour identifiant(s) d’interface 0x10

Valeur de paramètre invalide 0x11

Erreur du champ Paramètre 0x12

Paramètre inattendu 0x13

Non utilisé dans M2UA 0x14

Non utilisé dans M2UA 0x15

Paramètre manquant 0x16


L’erreur "Version invalide" sera envoyée si un message a été reçu avec une version invalide ou non acceptée. Le message Erreur va contenir la version acceptée dans l’en-tête commun. Le message Erreur pourrait facultativement fournir la version acceptée dans la zone des informations de diagnostic.


L’erreur "Identifiant d’interface invalide" sera envoyée par un SGP si un ASP envoie un message (c’est-à-dire un message ASP Actif) avec une valeur invalide (non configurée) d’identifiant d’interface. Un des paramètres facultatifs de l’identifiant d’interface (fondé sur un entier, sur du texte ou sur une gamme d’entiers) DOIT être utilisé avec ce code d’erreur pour identifier le ou les identifiants d’interface invalides reçus.


L’erreur "Mode de traitement du trafic non accepté" sera envoyée par un SGP si un ASP envoie un ASP Actif avec un Mode de traitement du trafic non accepté. Un exemple serait le cas où le SGP n’acceptait pas le partage de charge. Un des para mètres facultatifs d’identifiant d’interface (fondé sur un entier, sur du texte ou sur une gamme d’entiers) PEUT être utilisé avec ce code d’erreur pour identifier le ou les identifiants d’interface.


L’erreur "Message inattendu" sera envoyé par un ASP si il a reçu un message MAUP d’un SGP alors qu’il était dans l’état Inactif.


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


L’erreur "Identifiant de flux invalide" sera envoyée si un message a été reçu sur un flux SCTP inattendu (c’est-à-dire si un message MGMT a été reçu sur un flux autre que "0").


L’erreur "Type d’identifiant d’interface non accepté" sera envoyée par un SGP si un ASP envoie un identifiant d’interface en format texte et si le SGP n’accepte que les identifiants d’interface en format d’entier. Lorsque l’ASP reçoit cette erreur, il va avoir besoin de renvoyer son message avec un identifiant d’interface en format d’entier.


L’erreur "Classe de message non acceptée" sera envoyée si un message est reçu avec une classe de message non attendue ou non acceptée.


L’erreur "Refusé – blocage de gestion" est envoyé lorsque un message ASPUP ou ASPAC est reçu et que la demande est refusée pour des raisons de gestion (par exemple, gestion "bloquée").


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


L’erreur "Identifiant d’ASP invalide" est envoyée par un SGP en réponse à un message ASPUP qui a un identifiant d’ASP invalide (c’est-à-dire non unique).


L’erreur "ASP actuellement actif pour les identifiants d’interface" est envoyée par un SGP lorsque une demande de désenregistrement est reçue d’un ASP qui est actif pour le ou les identifiants d’interface spécifiés dans la demande de désenregistrement. Un des paramètres facultatifs d’identifiant d’interface (fondé sur un entier, fondé sur le texte ou la gamme d’entiers) PEUT être utilisé avec ce code d’erreur pour identifier le ou les identifiants d’interface.


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, une demande d’état avec un état indéfini).


L’erreur "Erreur du champ Paramètre" serait envoyé si un message avec un paramètre avait un champ de longueur erroné.


L’erreur "Paramètre inattendu" serait envoyé si un message contenait un paramètre invalide.


L’erreur "Paramètre manquant" serait envoyée si un paramètre obligatoire n’était pas inclus dans un message.


Les informations facultatives de diagnostic peuvent être toutes informations en rapport avec la condition d’erreur, pour aider à l’identification de la condition d’erreur. Dans le cas d’un code d’erreur Version invalide, les informations de diagnostic incluent le paramètre de version accepté. Dans les autres cas, les informations de diagnostic DEVRAIENT être les 40 premiers octets du message en cause.


        1. 3.3.3.2 Notifier (NTFY)

Le message Notifier est utilisé pour fournir une indication autonome des événements M2UA à un homologue M2UA.


Le message NTFY contient les paramètres suivants:

Type d’état (obligatoire)

Informations d’état (obligatoire)

Identifiant d’ASP (facultatif)

Identifiants d’interface (facultatif)

Chaîne d’informations (facultatif)


Le format pour le message Notify avec des identifiants d’interface en format d’entiers est le suivant :


0 1 2 3

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

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

| Étiquette (0xd) | Longueur 8 |

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

| Type d’état | Informations d’état |

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

| Étiquette (0x11) | Longueur |

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

| Identifiant d’ASP* |

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

| Étiquette (0x1=entier) | Longueur |

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

/ \

\ Identifiants d’interface* /

/ \

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

| Étiquette (0x8=gamme d’entier)| Longueur |

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

| Début d’identifiant d’interface1* |

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

| Fin d’identifiant d’interface1* |

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

| Début d’identifiant d’interface2* |

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

| Fin d’identifiant d’interface2* |

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

. .

. .

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

| Début d’identifiant d’interfaceN* |

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

| Fin d’identifiant d’interfaceN* |

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

/ \

\ Identifiants d’interface supplémentaires /

/ de type d’étiquette 0x1 ou 0x8 \

\ /

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

| Étiquette (0x4) | Longueur |

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

/ \

\ Chaîne d’informations* /

/ \

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


Le format pour le message Notifier avec des identifiants d’interface en format texte est le suivant :

0 1 2 3

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

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

| Étiquette (0xd) | Longueur = 8 |

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

| Type d’état | Informations d’état |

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

| Étiquette (0x11) | Longueur |

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

| Identifiant d’ASP* |

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

| Étiquette (0x3=chaîne) | Longueur |

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

\ Identifiant d’interface* /

/ \

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

/ \

\ Identifiants d’interface supplémentaires /

/ de type d’étiquette 0x3 \

\ /

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

| Étiquette (0x4) | Longueur |

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

\ Chaîne d’informations /

/ \

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


Le paramètre Type d’état identifie le type du message Notifier. Les valeurs valides de Type d’état sont :


Valeur Description

0x1 Changement d’état du serveur d’application (AS_State_Change)

0x2 Autre


Le paramètre Informations d’état contient des informations plus détaillées pour la notification, sur la base de la valeur du type d’état. Si le type d’état est AS_State_Change, les valeurs d’informations d’état suivantes sont utilisées :


Valeur Description

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 sur un changement d’état d’un certain serveur d’application. La valeur reflète le nouvel état du serveur d’application. Les identifiants d’interface de l’AS PEUVENT être placés dans le message si désiré.


Si le type d’état est Autre, les valeurs d’informations d’état suivantes sont alors définies :


Valeur Description

1 ressources actives d’ASP insuffisantes dans l’AS

2 autre ASP actif

3 échec d’ASP


Dans le cas de ressources d’ASP insuffisantes, le SGP indique à un ou des ASP ASP-INACTIVE dans l’AS qu’un autre ASP est nécessaire pour traiter la charge de l’AS (mode de partage de charge). Pour le cas d’autre ASP actif, l’ASP anciennement actif est informé lorsque un ASP de remplacement passe de l’état ASP Actif au mode Outrepasser. L’identifiant d’ASP (si disponible) de l’ASP de remplacement DOIT être placé dans le message. Dans le cas de l’échec d’ASP, le SGP indique aux ASP de l’AS qu’un des ASP est passé à l’état ASP-DOWN. L’identifiant d’ASP (s’il est disponible) de l’ASP en échec DOIT être placé dans le message.


Pour chaque valeur des informations d’état dans le type d’état Autre, les identifiants d’interface de l’AS affecté PEUVENT être placées dans le message si désiré.


Le format du paramètre facultatif Identifiant d’interface est le même que pour le message ASP Actif (voir au paragraphe 3.3.2.7).


Le format et la description du paramètre facultatif Chaîne d’informations est le même que pour le message ASPUP (voir au paragraphe 3.3.2.1).


      1. 3.3.4 Messages de gestion d’identifiant d’interface (IIM)

Les messages de gestion d’identifiant d’interface (IIM, Interface Identifier Management) sont facultatifs. Ils sont utilisés pour prendre en charge l’allocation automatique des terminaux de signalisation ou des liaisons de données de signalisation [Q.701-5], [T1.111].


        1. 3.3.4.1 Demande d’enregistrement (REG REQ)

Le message REG REQ est envoyé par un ASP pour indiquer à un homologue M2UA distant qu’il souhaite enregistrer une ou plusieurs clés de liaison auprès de l’homologue distant. Normalement, un ASP va envoyer ce message à un SGP, et s’attendre à recevoir une REG RSP en retour avec une valeur d’identifiant d’interface associée.


Le message REG REQ contient le paramètre suivant :

Clé de liaison (obligatoire)


Le format du message REG REQ est le suivant :


0 1 2 3

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

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

| Étiquette = 0x0309 | Longueur |

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

\ \

/ Clé de liaison 1 /

\ \

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

\ \

/ ... /

\ \

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

| Étiquette = 0x0309 | Longueur |

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

\ \

/ Clé de liaison n /

\ \

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


Clé de liaison : longueur fixe

Le paramètre Clé de liaison est obligatoire. L’envoyeur de ce message s’attend à ce que le receveur de ce message crée une entrée Clé de liaison et lui alloue une valeur univoque d’identifiant d’interface, si l’entrée Clé de liaison n’existe pas encore.


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


Le format du paramètre Clé de liaison est le suivant :


0 1 2 3

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

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

| Identifiant de liaison locale |

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

| Identifiant de terminal de données de signalisation |

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

| Identifiant de liaison de données de signalisation |

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


Identifiant de liaison locale : entier de 32 bits

Le champ obligatoire Identifiant de liaison locale est utilisé pour identifier de façon univoque (entre ASP et SGP) la demande d’enregistrement. La valeur d’identifiant est allouée par l’ASP, et est utilisée pour corréler la réponse dans un message REG RSP avec la demande d’enregistrement d’origine. La valeur de l’identifiant DOIT rester unique jusqu’à la réception de la REG RSP.


Le format du champ Identifiant de liaison locale est le suivant :


0 1 2 3

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

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

| Étiquette = 0x030a | Longueur = 8 |

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

| valeur d’Identifiant de liaison locale |

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


Identifiant de terminal de données de signalisation

Le paramètre Identifiant de terminal de données de signalisation est obligatoire. Il identifie le terminal de données de signalisation (SDT, Signalling Data Terminal) associé à la liaison SS7 pour laquelle l’ASP enregistre. Son format est le suivant :


0 1 2 3

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

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

| Étiquette = 0x030b | Longueur = 8 |

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

| Réservé | Identifiant de SDT |

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


L’identifiant de SDT est une valeur de 16 bits non signée qui peut n’être significative que sur 12 ou 14 bits selon la variante du SS7 qui est prise en charge par le niveau 3 de MTP chez l’ASP. Les bits non significatifs d’identifiant de SDT sont à 0.


Identifiant de liaison de données de signalisation

Le paramètre Identifiant de liaison de données de signalisation est obligatoire. Il identifie l’identifiant de liaison de données de signalisation (SDL, Signalling Data Link) associé à la liaison SS7 pour laquelle l’ASP enregistre. Son format est le suivant :


0 1 2 3

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

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

| Étiquette = 0x030c | Longueur = 8 |

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

| Réservé | Identifiant de SDL |

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


L’identifiant de SDL est une valeur non signée de 16 bits qui peut n’être significative que sur 12 ou 14 bits selon la variante de SS7 qui est prise en charge par le niveau 3 de MTP chez l’ASP. Les bits non significatifs de SDLI sont codés à 0.


        1. 3.3.4.2 Réponse d’enregistrement (REG RSP)

Le message Réponse d’enregistrement (REG RSP) est utilisé comme réponse au message REG REQ provenant d’un homologue M2UA distant. Il contient des indications de réussite/échec pour les demandes d’enregistrement et retourne une valeur univoque d’identifiant d’interface pour les demandes d’enregistrement réussies, à utiliser dans la suite du protocole de gestion de trafic M2UA.


Le message REG RSP contient le paramètre suivant :

Résultat d’enregistrement (obligatoire)


Le format du message REG RSP est le suivant :


0 1 2 3

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

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

| Étiquette = 0x030d | Longueur |

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

\ \

/ Résultat d’enregistrement 1 /

\ \

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

\ \

/ ... /

\ \

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

| Étiquette = 0x030d | Longueur |

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

\ \

/ Résultat d’enregistrement n /

\ \

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


Résultat d’enregistrement : longueur fixe

Le paramètre Résultat d’enregistrement contient un ou plusieurs résultats, contenant chacun l’état d’enregistrement pour une seule clé de liaison dans le message REG REQ. Le nombre de résultats dans un seul message REG RSP PEUT correspondre au nombre de paramètres Clé de liaison qui se trouvent dans le message REG REQ correspondant. Le format de chaque résultat est le suivant :


0 1 2 3

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

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

| Identifiant de liaison locale |

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

| État d’enregistrement |

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

| Identifiant d’interface |

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


Identifiant de liaison locale : entier de 32 bits

L’identifiant de liaison locale contient la même valeur que celle trouvée dans le paramètre Clé de liaison correspondant trouvé dans le message REG REQ. Le format de l’identifiant de liaison locale est donné au paragraphe 3.3.4.1.


État d’enregistrement : entier de 32 bits


Le champ État de résultat d’enregistrement indique la réussite ou la raison de l’échec d’une demande d’enregistrement.


Valeur Signification

0 Enregistrement réussi

1 Erreur - Inconnue

2 Erreur – SDLI invalide

3 Erreur – SDTI invalide

4 Erreur – Clé de liaison invalide

5 Erreur - Permission refusée

6 Erreur – Chevauchement de clé de liaison (non unique)

7 Erreur – Clé de liaison non fournie

8 Erreur – Ressources insuffisantes


Le format du champ État d’enregistrement est le suivant :


0 1 2 3

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

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

| Étiquette = 0x030e | Longueur = 8 |

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

| État d’enregistrement |

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


Identifiant d’interface : entier de 32 bits


Le champ Identifiant d’interface contient l’identifiant d’interface pour la clé de liaison associée si l’enregistrement est réussi. Il est réglé à "0" si l’enregistrement n’a pas réussi. Le format des paramètres Identifiant d’interface fondé sur l’entier et fondé sur le texte est donné au paragraphe 3.2.


        1. 3.3.4.3 Demande de désenregistrement (DEREG REQ)

Le message DEREG REQ est envoyé par un ASP pour indiquer à un homologue M2UA distant qu’il souhaite désenregistrer un certain identifiant d’interface. Normalement, un ASP va envoyer ce message à un SGP, et s’attendre à recevoir un DEREG RSP en retour qui reflète l’identifiant d’interface et contient un état de désenregistrement.


Le message DEREG REQ contient le paramètre suivant :

Identifiant d’interface (obligatoire)


Le format pour le message DEREG REQ est le suivant :


0 1 2 3

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

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

| Étiquette = 0x1 or 0x3 | Longueur |

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

\ \

/ Identifiant d’interface 1 /

\ \

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

\ \

/ ... /

\ \

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

| Étiquette = 0x1 or 0x3 | Longueur |

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

\ \

/ Identifiant d’interface n /

\ \

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


Identifiant d’interface

Le paramètre Identifiant d’interface contient un identifiant d’interface qui indexe le trafic du serveur d’application que l’ASP envoyeur est actuellement enregistré à recevoir du SGP mais qu’il souhaite maintenant désenregistrer. Le format des paramètres Identifiant d’interface fondés sur l’entier et sur le texte figure au paragraphe 3.2.


        1. 3.3.4.4 Réponse de désenregistrement (DEREG RSP)

Le message DEREG RSP est utilisé comme réponse au message DEREG REQ de la part d’un homologue M2UA distant.


Le message DEREG RSP contient le paramètre suivant :

Résultat de désenregistrement (obligatoire)


Le format pour le message DEREG RSP est le suivant :


0 1 2 3

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

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

| Étiquette = 0x030f | Longueur |

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

\ \

/ Résultat de désenregistrement 1 /

\ \

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

\ \

/ ... /

\ \

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

| Étiquette = 0x030f | Longueur |

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

\ \

/ Résultat de désenregistrement n /

\ \

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


Résultat de désenregistrement : longueur fixe

Le paramètre Résultat de désenregistrement contient un ou plusieurs résultats, chacun contenant l’état de désenregistrement pour un seul identifiant d’interface dans le message DEREG REQ. Le nombre de résultats dans un seul message DEREG RSP PEUT correspondre au nombre de paramètres Identifiant d’interface trouvé dans le message DEREG REQ correspondant.


Le format de chaque résultat est le suivant :


0 1 2 3

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

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

| Identifiant d’interface |

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

| État de désenregistrement |

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


Identifiant d’interface : entier de 32 bits

Le champ Identifiant d’interface contient la valeur d’identifiant d’interface de la clé de liaison correspondant au désenregistrement, tel que trouvé dans le DEREG REQ. Le format des paramètres Identifiant d’interface fondés sur l’entier et sur le texte figure au paragraphe 3.2.


État de désenregistrement : entier de 32 bits

Le champ Résultat de désenregistrement indique la réussite ou la raison de l’échec du désenregistrement.


Valeur Signification

0 Désenregistrement réussi

1 Erreur - inconnue

2 Erreur - identifiant d’interface invalide

3 Erreur - permission refusée

4 Erreur - non enregistré


Le format du champ État de désenregistrement est le suivant :


0 1 2 3

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

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

| Étiquette = 0x0310 | Longueur = 8 |

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

| État de désenregistrement |

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


4. Procédures


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


    1. 4.1 Procédures pour la prise en charge de la couche d’utilisateur M2UA


Ces procédures réalisent le service de couche "Transport de niveau 2 MTP/ limite de niveau 3 MTP" M2UA.


      1. 4.1.1 Procédures de limite de MTP nuveau 2 / MTP niveau 3


À réception d’une primitive de la couche supérieure locale, la couche M2UA va envoyer le message MAUP correspondant (voir la Section 3) à son homologue. La couche M2UA DOIT remplir correctement divers champs des en-têtes commun et spécifiques. De plus, le message DEVRAIT être envoyé sur le flux SCTP qui correspond à la liaison SS7.


      1. 4.1.2 Procédures de message MAUP


À réception de messages MAUP d’une couche M2UA homologue, la couche M2UA sur un SG ou MGC doit invoquer les primitives de couche correspondantes aux couches de MTP niveau 2 ou 3 local.


    1. 4.2 Réception de primitives de la gestion de couches


À réception de primitives de la gestion de couche locale, la couche M2UA va effectuer l’action requise et fournir une primitive de réponse appropriée à la gestion de couches.


Une primitive de demande M-SCTP_ESTABLISH provenant de la gestion de couches adressée à un ASP va initier l’établissement d’une association SCTP. La couche M2UA va tenter d’établir une association SCTP avec l’homologue M2UA distant en envoyant une primitive SCTP-ASSOCIATE à la couche SCTP locale.


Lorsque une association SCTP a été bien établie, le SCTP va envoyer une primitive de notification SCTP-COMMUNICATION_UP à la couche M2UA locale. Au SGP qui a initié la demande, la couche M2UA va envoyer une primitive de confirmation M-SCTP_ESTABLISH à la gestion de couches lorsque l’établissement de l’association est achevé. À la couche M2UA homologue, une primitive d’indication M-SCTP_ESTABLISH est envoyée à la gestion de couches à la réussite de l’achèvement d’un établissement d’association SCTP entrante.


Une primitive de demande M-SCTP_RELEASE de la gestion de couches initie la fermeture d’une association SCTP. La couche M2UA accomplit une fermeture en douceur de l’association SCTP en envoyant une primitive SCTP-SHUTDOWN à la couche SCTP.


Lorsque 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 M2UA locale. À la couche M2UA qui a initié la demande, la couche M2UA va envoyer une primitive de confirmation M-SCTP_RELEASE pour la gestion de couches lorsque la fermeture d’association est achevée. Chez la couche M2UA homologue, une primitive d’indication M-SCTP_RELEASE est envoyée à la gestion de couches en cas d’interruption ou de réussite de fermeture d’une association SCTP.


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


Des transpositions similaires de primitive de LM à M2UA à SCTP et/ou de SCTP à M2UA à LM peuvent être décrites pour les diverses autres primitives SCTP de couche supérieure dans la [RFC2960] telles que 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 (ainsi que les états) SCTP de couche supérieure peuvent être considérés 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 couches la notification ou les informations d’erreur contenues dans un message M2UA reçu respectivement de Notifier ou Erreur. Ces indications peuvent aussi être générées sur la base d’événements M2UA locaux.


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


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


Les primitives de demande M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE et M-ASP_INACTIVE permettent à la gestion de couches d’un ASP d’initier des changements d’état. En cas d’achèvement réussi, une primitive de confirmation correspondante est fournie par la couche M2UA à la gestion de couches. Si une invocation ne réussit pas, une primitive d’indication d’erreur est fournie dans la primitive. Ces demandes résultent en messages ASP Up, ASP Down, ASP Active et ASP Inactive sortants destinés à l’homologue M2UA distant chez un SGP.


      1. 4.2.1 Réception de messages de gestion d’homologue M2UA

Après un changement d’état réussi résultant de la réception d’un message ASP Up, ASP Down, ASP Active et ASP Inactive d’un M2UA homologue, la couche M2UA DEVRAIT invoquer les primitives d’indication correspondantes M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE et M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, et M-AS_DOWN à la gestion de couches locale.


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


Tous les messages MGMT, sauf BEAT et BEAT Ack, DEVRAIENT être envoyés avec une livraison en séquence pour assurer le bon ordre. Tous les messages MGMT, à l’exception de ASPTM, BEAT et BEAT Ack, DEVRAIENT être envoyés sur le flux SCTP '0'. Tous les messages ASPTM DEVRAIENT être envoyés sur le flux qui porte normalement le trafic de données auquel le message s’applique. Les messages BEAT et BEAT Ack PEUVENT être envoyés en utilisant une livraison dans le désordre, et PEUVENT être envoyés sur n’importe quel flux.


    1. 4.3 Maintenance d’état d’AS et d’ASP


La couche M2UA chez le SGP maintient l’état de chaque ASP distant, dans chaque serveur d’application où l’ASP est configuré à recevoir du trafic, comme entrée à la fonction de distribution de message M2UA.


      1. 4.3.1 États d’ASP

L’état de chaque ASP distant, dans chaque AS configuré pour fonctionner, est conservé dans la couche M2UA chez le SGP. L’état d’un ASP particulier dans un AS particulier change selon les événements. Les événements incluent :

* réception de messages provenant de la couche M2UA homologue à l’ASP ;

* réception de messages provenant de la couche M2UA homologue chez d’autres ASP dans l’AS (par exemple, message ASP Actif indiquant "Outrepasser") ;

* réception d’indications provenant de la couche SCTP ; ou

* intervention de la gestion locale.


Le diagramme de transition d’état d’ASP de la Figure 5 donne les états possibles d’un ASP :


ASP-DOWN : L’homologue M2UA distant à l’ASP est indisponible et/ou l’association SCTP qui s’y rapporte est morte. Au début, tous les ASP seront dans cet état. On NE DEVRAIT PAS envoyer de message M2UA à un ASP dans cet état, à l’exception des messages Heartbeat, ASP Down Ack et Erreur.


ASP-INACTIVE : L’homologue M2UA distant à l’ASP est disponible (et l’association SCTP qui s’y rapporte est debout) mais le trafic d’application est arrêté. Dans cet état, on PEUT envoyer à l’ASP tout message M2UA non MAUP.


ASP-ACTIVE : L’homologue M2UA distant à l’ASP est disponible et le trafic d’application est actif (pour un identifiant d’interface ou ensemble d’identifiants d’interface particulier).


Figure 5 : Diagramme de transition d’état d’ASP


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

| ASP-ACTIVE |

+----------------------| |

| Un autre +-------| |

| ASP dans l’AS| +--------------+

| outrepasse | ^ |

| | ASP | | ASP

| | actif | | inactif

| | | v

| | +--------------+

| | | |

| +------>| ASP-INACTIVE |

| +--------------+

| ^ |

ASP mort/ | ASP | | ASP mort /

SCTP CDI/ | debout | | SCTP CDI/

SCTP RI | | v SCTP RI

| +--------------+

| | |

+--------------------->| ASP-DOWN |

| |

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


SCTP CDI : SCTP CDI note l’indication d’échec de communication (CDI, Communication Down Indication) de la couche SCTP locale au protocole de couche supérieure (M2UA) 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. SCTP CDI est compris soit comme une notification de SHUTDOWN_COMPLETE, soit comme une notification de COMMUNICATION_LOST de la part de la couche SCTP.


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


      1. 4.3.2 États d’AS


L’état de l’AS est conservé dans la couche M2UA sur le SGP. L’état d’un AS change à cause d’événements. Ces événements incluent :

* des transitions d’état d’ASP

* des déclanchements 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 en rapport soient dans l’état ASP-DOWN pour cet AS. L’AS sera initialement dans cet état. Un serveur d’application DOIT être dans l’état AS-DOWN avant qu’il puisse être retiré d’une configuration.


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


AS-ACTIVE : Le serveur d’application est disponible et du trafic d’application est actif. Cet état implique qu’au moins un ASP est dans 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 lancé et tous les messages de signalisation entrants DEVRAIENT être mis en file d’attente par le SGP. Si un ASP passe en ASP-ACTIVE avant l’arrivée à expiration de T(r), l’AS est passé à l’état AS-ACTIVE et tous les messages en file d’attente sont envoyés à l’ASP.


Si T(r) arrive à expiration avant qu’un ASP devienne ASP-ACTIVE, le SGP arrête de mettre les messages en file d’attente et élimine 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 passe à l’état AS-DOWN.


La Figure 6 donne un exemple d’automate à état d’AS pour le cas où les données d’AS/ASP sont préconfigurées. Pour les autres cas où les données de configuration d’AS/ASP sont créées dynamiquement, il y aura des différences dans l’automate à états, en particulier à la création de l’AS.


Par exemple, si les données de configuration de l’AS/ASP ne sont pas créées avant l’enregistrement du premier ASP, l’état AS-INACTIVE est atteint directement à la première REG REQ réussie d’un ASP. Un autre exemple est lorsque les données de configuration d’AS/ASP ne sont pas créées tant que le premier ASP n’est pas entré dans l’état ASP-ACTIVE. Dans ce cas, l’état AS-ACTIVE est atteint directement.


Figure 6 : Diagramme de transition d’état d’AS


+----------+ un ASP passe à ACTIVE +-------------+

| AS- |---------------------------->| AS- |

| INACTIVE | | ACTIVE |

| |<--- | |

+----------+ \ +-------------+

^ | \ Expiration de Tr, ^ |

| | \ au moins un ASP | |

| | \ dans ASP-INACTIVE | |

| | \ | |

| | \ | |

| | \ | |

un ASP | | tous les ASP \ un ASP | | Le dernier ASP actif

passe | | passent à \ passe à | | passe à

à | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE

ASP- | | \ ACTIVE | | ou à ASP-DOWN

INACTIVE| | \ | | (début de Tr)

| | \ | |

| | \ | |

| v \ | v

+----------+ \ +-------------+

| | --| |

| AS-DOWN | | AS-PENDING |

| | |(mise en file|

| |<----------------------------| d’attente) |

+----------+ Expiration de Tr et aucun +-------------+

ASP dans l’état ASP-INACTIVE

Tr = temporisateur de récupération


      1. 4.3.3 Procédures de gestion de M2UA pour les primitives

Avant l’établissement d’une association SCTP, l’état d’ASP chez le SGP et l’ASP est supposé être ASP-DOWN.


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


Si la couche M2UA reçoit ultérieurement une primitive d’indication SCTP-COMMUNICATION_DOWN ou SCTP-RESTART provenant de la couche SCTP sous-jacente, elle va informer la gestion de couches en invoquant la primitive d’indication M-SCTP_STATUS. L’état de l’ASP va passer à ASP-DOWN.


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 M2UA, ou la gestion de couches PEUT se rétablir en utilisant la primitive de demande M-SCTP_ESTABLISH.


Dans le cas d’une indication SCTP-RESTART chez un ASP, l’ASP est maintenant considéré par son homologue M2UA comme étant dans l’état ASP-DOWN. L’ASP, si il doit récupérer, doit commencer toute récupération par la procédure ASP-Up.


      1. 4.3.4 Procédures ASPM pour les messages d’homologue à homologue

        1. 4.3.4.1 Procédures ASP Up

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


Lorsque un message ASP Up est reçu chez 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 couches avec une primitive d’indication M-ASP_Up. Si le SGP est au courant, via les données de configuration courantes, des serveurs d’application sur lesquels l’ASP est configuré à fonctionner, le SGP met à jour l’état de l’ASP à ASP-INACTIVE dans chaque AS qui en est membre.


Autrement, le SGP peut passer l’ASP dans un réservoir d’ASP inactifs disponibles pour une future configuration au sein du ou des serveurs d’application, déterminé dans une procédure de demande d’enregistrement ou d’ASP Active. 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 chez le SGP.


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


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


Lorsque 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 Accusé de réception d’ASP Up. T(ack) est configurable, avec une valeur par défaut de 2 secondes. Autrement, la retransmission des messages ASP Up PEUT être mise sous contrôle de la gestion de couches. Dans cette méthode, l’expiration de T(ack) résulte en une primitive de confirmation M-ASP_UP portant une indication négative.


L’ASP DOIT attendre le message Accusé de réception d’ASP Up avant d’envoyer d’autres messages M2UA (par exemple, ASP Active ou REG REQ). Si le SGP reçoit d’autres messages M2UA avant que soit reçu un message ASP Up (autre que ASP Down - voir au paragraphe 4.3.4.2), le SGP PEUT les éliminer.


Si un messages ASP Up est reçu et si en interne l’ASP distant est dans l’état ASP-ACTIVE, un message Accusé de réception d’ASP Up est retourné, ainsi qu’un message Erreur ("Message inattendu") et l’état de l’ASP distant est changé en ASP-INACTIVE dans tous les serveurs d’application pertinents.


Si un message ASP Up est reçu et si en interne l’ASP distant est déjà dans l’état ASP-INACTIVE, un message Accusé de réception d’ASP Up est retourné et aucune autre action n’a lieu.


        1. 4.3.4.1.1 Contrôle de version M2UA

Si un message ASP Up contenant une version non acceptée est reçu, l’extrémité receveuse répond par un message d’erreur qui indique la version qu’accepte le nœud receveur et le notifie à la gestion de couches.


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


        1. 4.3.4.2 Procédures d’ASP Down

L’ASP va envoyer un message ASP Down à un SGP lorsque l’ASP souhaite être retiré du service dans tous les serveurs d’application qui sont membres et ne reçoivent plus de messages MAUP ou ASPTM. Cette action PEUT être initiée chez l’ASP par une primitive de demande M-ASP_DOWN provenant de la gestion de couches ou PEUT être initiée automatiquement par une fonction de gestion M2UA.


Il relève des fonctions de la gestion de configuration de décider du caractère plus ou moins permanent du retrait de l’ASP d’un AS. Dans le cas où l’ASP a utilisé précédemment les procédures d’enregistrement (voir au paragraphe 4.4) pour s’enregistrer au sein de serveurs d’application mais ne s’est pas désenregistré de tous avant d’envoyer le message ASP Down, le SGP DOIT considérer l’ASP comme non enregistré dans tous les serveurs d’application dont il est toujours membre.


Le SGP marque l’ASP comme ASP-DOWN, informe la gestion de couches avec une primitive d’indication M-ASP_Down, et retourne un message Accusé de réception d’ASP Down à l’ASP.


Le SGP DOIT envoyer un message Accusé de réception d’ASP Down en réponse à un message ASP Down reçu de l’ASP même si l’ASP est déjà marqué comme ASP-DOWN chez le SGP.


Chez l’ASP, le message Accusé de réception d’ASP Down reçu n’est pas acquitté. La gestion de couches est informée par une primitive de confirmation M-ASP_DOWN. Si l’ASP reçoit un Accusé de réception d’ASP Down sans avoir envoyé un message ASP Down, l’ASP DEVRAIT alors 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, l’ASP DEVRAIT alors initier des procédures pour retourner lui-même à l’état précédent.


Lorsque 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 T(ack), l’ASP PEUT relancer T(ack) et renvoyer des messages ASP Down jusqu’à ce qu’il reçoive un message Accusé de réception d’ASP Down. T(ack) est configurable, avec une valeur par défaut de 2 secondes. Autrement, la retransmission des messages ASP Down PEUT être mise sous le contrôle de la gestion de couches. Dans cette méthode, l’expiration de T(ack) résulte en une primitive de confirmation M-ASP_DOWN portant une indication négative.


        1. 4.3.4.3 Procédures d’ASP Active

Chaque fois que l’ASP a reçu un message Accusé de réception d’ASP Up du SGP, l’ASP PEUT envoyer un message ASP Active du SGP pour indiquer que l’ASP est prêt à commencer à traiter du trafic. Cette action PEUT être initiée à l’ASP par une primitive de demande M-ASP_ACTIVE provenant de la gestion de couche ou PEUT être initiée automatiquement par la fonction de gestion M2UA. Dans le cas où un ASP souhaite traiter le trafic de plus d’un serveur d’application à travers une association SCTP commune, le ou les messages ASP Active DEVRAIENT contenir une liste d’un ou plusieurs identifiants d’interface pour indiquer à quels serveurs d’application le messages ASP Active s’applique. Il n’est pas nécessaire que l’ASP inclue d’identifiant d’interface intéressant un seul message ASP Active, demandant donc de devenir actif dans tous les identifiants d’interface en même temps. Plusieurs messages ASP Active PEUVENT être utilisés pour activer indépendamment au sein des serveurs d’application, ou dans des ensembles. Dans le cas où un message ASP Active ne contient pas de paramètre d’identifiant d’interface, le receveur doit savoir, via les données de configuration, de quels serveurs d’application l’ASP est membre.


Pour les serveurs d’application que l’ASP peut réussir à activer, le SGP répond par un ou plusieurs messages Accusé de réception d’ASP Active, incluant le ou les identifiants d’interface associés et en reflétant toute valeur de type de mode de trafic présente dans le message ASP Active en question. Le paramètre identifiant d’interface DOIT être inclus dans le ou les messages Accusé de réception d’ASP Active si le message ASP Active reçu contenait un ou des identifiants d’interface. Selon la demande de type de mode de trafic dans le messages ASP Active ou des 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 couches est informée avec une indication M-ASP_Active. Si le SGP reçoit des messages Données avant qu’un message ASP Active soit reçu, le SGP PEUT les éliminer. En envoyant un message Accusé de réception d’ASP Active, le SGP est maintenant prêt à recevoir et envoyer du trafic pour le ou les identifiants d’interface pertinents. L’ASP NE DEVRAIT PAS envoyer de message MAUP pour le ou les identifiants d’interface concernés avant de recevoir un message Accusé de réception d’ASP Active, ou il va risquer de perdre des messages.


Plusieurs messages Accusé de réception d’ASP Active PEUVENT être utilisés en réponse à un message ASP Active contenant plusieurs identifiants d’interface, ce qui permet au SGP d’acquitter indépendamment le message ASP Active pour différents (ensembles d’) identifiants d’interface. Le SGP DOIT envoyer un message d’erreur ("Identifiant d’interface invalide") pour chaque valeur d’identifiant d’interface qui ne peut pas être activée.


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


Le SGP DOIT envoyer un message Accusé de réception d’ASP Active en réponse à un message ASP Active reçu de l’ASP, si l’ASP est déjà marqué dans l’état ASP-ACTIVE au SGP.


À l’ASP, le message Accusé de réception d’ASP Active reçu n’est pas acquitté. La gestion de couches est informée par une primitive de confirmation M-ASP_ACTIVE. Il est possible à l’ASP de recevoir un ou des messages Données avant le message Accusé de réception d’ASP Active car les messages Accusé de réception d’ASP Active et Données provenant d’une SG peuvent être envoyés sur des flux SCTP différents. La perte de message est possible car l’ASP ne se considère pas lui-même comme étant dans l’état ASP-ACTIVE jusqu’à la réception du message Accusé de réception d’ASP Active.


Lorsque l’ASP envoie un message ASP Active, il lance le temporisateur T(ack). Si l’ASP ne reçoit pas une réponse à un message ASP Active dans le délai de T(ack), l’ASP PEUT relancer T(ack) et renvoyer des messages ASP Active jusqu’à ce qu’il reçoive un message Accusé de réception d’ASP Active. T(ack) est configurable, 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 couches. 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 du trafic de serveur d’application dans la couche M2UA de SGP : Outrepasser (Override), Partage de charge (Load share) et Diffusion (Broadcast). Lorsque il est inclus dans le message ASP Active, le paramètre Type de mode de trafic indique le mode de traitement du trafic à utiliser dans un certain serveur d’application. Si le SGP détermine que le mode indiqué dans un message ASP Active n’est pas accepté ou est incompatible avec le mode actuellement configuré pour l’AS, le SGP répond par un message d’erreur ("Non accepté / Mode de traitement du trafic invalide"). Si le mode de traitement du trafic du serveur d’application n’est pas déjà connu via les données de configuration, le mode de traitement du trafic indiqué dans le premier message ASP Active qui cause la transition de l’état du serveur d’application à AS-ACTIVE PEUT être utilisé pour régler le mode.


Dans le cas d’un AS en mode Outrepasser, la réception d’un message ASP Active chez un SGP cause la redirection de tout le trafic pour l’AS sur l’ASP qui a envoyé le message ASP Active. Tout ASP précédemment actif dans l’AS est maintenant considéré comme étant dans l’état ASP-INACTIVE et DEVRAIT ne plus recevoir de trafic provenant du SGP au sein de l’AS. Le SGP DOIT alors envoyer un message Notifier ("Autre ASP actif") à l’ASP précédemment actif dans l’AS, et DEVRAIT arrêter le trafic de/vers cet ASP. L’ASP recevant ce Notifier DOIT se considérer maintenant comme étant dans l’état ASP-INACTIVE, si il n’est pas déjà au courant de cela via une communication inter-ASP avec l’ASP qui outrepasse.


Dans le cas d’un AS en mode partage de charge, la réception d’un message ASP Active chez un SGP cause la redirection du trafic sur l’ASP qui envoie le message ASP Active, en plus de tous les autres ASP qui sont actuellement actifs dans l’AS. L’algorithme de partage de trafic au SGP entre tous les ASO actifs au sein d’un AS dépend de la mise en œuvre. L’algorithme pourrait, par exemple être un round-robin ou être fondé sur des informations du message Données (par exemple, telles que le SLS dans l’étiquette Routing).


Un SGP, à réception d’un message ASP Active pour le premier ASP dans un AS à partage de charge, PEUT choisir de ne pas diriger le trafic sur un ASP nouvellement actif jusqu’à ce qu’il détermine 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).


Tous les ASP au sein d’un AS en mode de partage de charge doivent être capables de traiter tout message Données reçu pour l’AS, pour s’accommoder de toute reprise sur défaillance ou tout équilibrage potentiel de la charge offerte.


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


Un SGP, à réception d’un message ASP Active pour le premier ASP dans un AS en diffusion, PEUT choisir de ne pas diriger le trafic sur un ASP nouvellement actif tant qu’il n’a pas 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).


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


        1. 4.3.4.4 Procédures d’ASP Inactive

Lorsque un ASP souhaite se retirer de la réception du trafic au sein d’un AS, l’ASP envoie un message ASP Inactive au SGP. Cette action PEUT être initiée à l’ASP par une primitive de demande M-ASP_INACTIVE de la gestion de couches ou PEUT être initiée automatiquement par une fonction de gestion M2UA. 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 identifiants d’interface pour indiquer pour quels serveurs d’application s’applique le message ASP Inactive. Dans le cas où un message ASP Inactive ne contient pas de paramètre d’identifiant d’interface, le receveur doit savoir, via les données de configuration, de quels serveurs d’application l’ASP est membre et 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 est déjà en charge du 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é par le SGP comme étant dans l’état ASP-INACTIVE. Un message Accusé de réception d’ASP Inactive est envoyée à 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é entre les ASP restants dans l’état ASP-ACTIVE, selon l’algorithme de partage de charge actuellement utilisé au sein de l’AS. Un message Notifier ("Ressources actives d’ASP insuffisantes dans l’AS") PEUT être envoyé à tous les ASP inactifs, si nécessaire. Un message Accusé de réception d’ASP Inactif est envoyé à l’ASP après que tout le trafic est arrêté et la gestion de couches est informée par 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 n’est diffusé qu’aux ASP restants dans l’état ASP-ACTIVE. Un message Notifier ("Ressources actives d’ASP insuffisantes dans l’AS") PEUT être envoyé à tous les ASP inactifs, si nécessaire. Un message Accusé de réception d’ASP Inactif est envoyé à l’ASP après que tout le trafic est arrêté et la gestion de couches est informée par une primitive d’indication M-ASP_INACTIVE.


Plusieurs messages Accusé de réception d’ASP Inactif PEUVENT être utilisés en réponse à un message ASP Inactif contenant plusieurs identifiants d’interface, ce qui permet au SGP d’acquitter de façon indépendante différents (ensembles d’) identifiants d’interface. Le SGP envoie un message d’erreur ("Identifiant d’interface invalide") pour chaque valeur d’identifiant d’interface invalide ou non configurée dans un message ASP Inactif reçu.


Le SGP DOIT envoyer un message Accusé de réception d’ASP Inactif en réponse à un message ASP Inactif reçu de l’ASP et l’ASP est déjà marqué comme ASP-INACTIVE au SGP.


À l’ASP, le message Accusé de réception d’ASP Inactif reçu n’est pas acquitté. La gestion de couches est informée par une primitive de confirmation M-ASP_INACTIVE. Si l’ASP reçoit un accusé de réception d’ASP Inactif sans avoir envoyé un message ASP Inactif, l’ASP DEVRAIT maintenant se considérer lui-même 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 lui-même dans son état antérieur.


Lorsque l’ASP envoie un message ASP Inactif, il lance le temporisateur T(ack). Si l’ASP ne reçoit pas une réponse à un message ASP Inactif dans le délai de T(ack), l’ASP PEUT relancer T(ack) et renvoyer des messages ASP Inactif jusqu’à ce qu’il reçoive un message Accusé de réception d’ASP Inactif. T(ack) est configurable, avec une valeur par défaut de 2 secondes. Autrement, les retransmissions de messages ASP Inactif PEUVENT être mises sous le contrôle de la gestion de couches. Dans cette méthode, l’expiration de T(ack) résulte en une primitive de confirmation M-ASP_INACTIVE qui porte 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 Notifier ("AS-Pending") à tous les ASP de 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 de l’AS avant l’expiration de T(r), le trafic mis en mémoire tampon est dirigé sur cet ASP et le temporisateur est annulé. Si T(r) arrive à expiration, l’AS est passé dans l’état AS-INACTIVE.


        1. 4.3.4.5 Procédures de Notifier

Un message Notifier qui reflète un changement de l’état de l’AS DOIT être envoyé à tous les ASP dans l’AS, excepté ceux qui sont dans l’état ASP-DOWN, avec les informations d’état appropriées et tout identifiant d’ASP de l’ASP en échec. Chez l’ASP, la gestion de couches est informée par une primitive d’indication M-NOTIFY. Le message Notifier DOIT être envoyé que le changement d’état de l’AS ait résulté d’un échec d’ASP ou de la réception d’un message de gestion d’état d’ASP (ASPSM, ASP State Management) / gestion de trafic d’ASP (ASPTM, ASP Traffic Management). Dans le second cas, le message Notifier DOIT être envoyé après tous les messages d’accusé de réception pertinents (par exemple, ASP Up Ack, ASP Down Ack, ASP Active Ack, ou ASP Inactive Ack).


Dans le cas d’un message Notifier ("AS-PENDING") envoyé par un SGP qui n’a actuellement pas d’ASP actif pour desservir le trafic, ou d’un message Notifier ("Ressources actives d’ASP insuffisantes dans l’AS") qui DOIT être envoyé dans le mode charge partagée ou diffusion, le message Notifier n’oblige pas explicitement le ou les ASP receveurs du message à devenir actifs. Les ASP restent maîtres de l’action de trafic qui a lieu et du moment où elle est entreprise.


Dans le cas d’un message Notifier qui ne contient pas de paramètre d’identifiant d’interface, le receveur doit savoir, via les données de configuration, de quels serveurs d’application est membre l’ASP et prendre l’action appropriée dans chaque AS.


        1. 4.3.4.6 Procédures de En vie

Les procédures facultatives de En vie (Heartbeat) PEUVENT être utilisées lors d’un fonctionnement sur des couches de transport qui n’ont pas leur propre mécanisme de vérification de vie pour détecter la perte de l’association de transport (c’est-à-dire, autre que SCTP).


L’un ou l’autre des homologues M2UA a la faculté d’envoyer périodiquement des messages En vie, sous réserve d’un temporisateur configurable T(beat). À réception d’un message En vie, l’homologue M2UA DOIT répondre par un message Accusé de réception de En vie.


Si aucun message Accusé de réception de En vie (ou aucun autre message M2UA) n’est reçu de l’homologue M2UA dans les 2*T(beat), l’homologue M2UA distant est considéré comme indisponible. La transmission des messages En vie 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 M2UA déconnecté.


Le message En vie peut facultativement contenir un paramètre Données de En vie opaque auquel il DOIT être fait écho sans changement dans le message Accusé de réception de En vie qui s’y rapporte. L’envoyeur, à l’examen du contenu du message Accusé de réception de En vie retourné, PEUT choisir de considérer l’homologue M2UA distant comme indisponible. Le contenu/format du paramètre Données de En vie dépend de la mise en œuvre est ne présente d’intérêt qu’en local pour l’envoyeur d’origine. Le contenu peut être utilisé, par exemple, pour prendre en charge un algorithme de suivi des En vie (pour détecter les En vie manquants) et/ou un mécanisme d’horodatage (pour évaluer les délais).


Note : Les événements qui se rapportent au En vie ne sont pas montrés à la Figure 5 "Diagramme de transition d’état d’ASP".


    1. 4.4 Procédures de gestion de clé de liaison


Les procédures de gestion d’identifiant d’interface sont facultatives. Elles peuvent être utilisées pour prendre en charge l’allocation automatique des terminaux de signalisation ou les liaisons de données de signalisation [Q.701-5], [T1.111].


      1. 4.4.1 Enregistrement

Un ASP PEUT s’enregistrer de façon dynamique auprès d’un SGP en tant qu’ASP au sein d’un serveur d’application pour un ou des identifiants d’interface individuels en utilisant le message REG REQ. Un paramètre Clé de liaison (Link Key) dans le REG REQ spécifie les paramètres associés à la clé de liaison.


Le SGP examine le contenu des paramètres Clé de liaison reçus (SDLI et SDTI) et les compare aux identifiants d’interface actuellement provisionnés. Si la clé de liaison reçue correspond à une entrée existante de clé de liaison 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’ajout de l’ASP à l’AS. Ou, si la clé de liaison n’existe pas actuellement et si les données de clé de liaison reçues sont valides et univoques, un SGP qui prend en charge la configuration dynamique PEUT autoriser la création d’un nouvel identifiant d’interface et du serveur d’application concerné 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 liaison local que celui fourni dans la demande initiale, un résultat d’enregistrement "Enregistrement réussi" et l’identifiant d’interface. Une méthode unique d’allocation d’identifiant d’interface valide au SG/SGP relève de la mise en œuvre mais DOIT garantir le caractère univoque pour chaque serveur d’application ou clé de liaison servi par le SGP.


Si le SGP détermine que les données de clé de liaison reçues sont invalides, ou contiennent des valeurs de paramètre invalides, le SGP retourne un message Réponse d’enregistrement à l’ASP, contenant un résultat d’enregistrement "Erreur – Clé de liaison invalide", "Erreur – SDTI invalide", "Erreur – SDLI invalide" selon ce qui est approprié.


Si le SGP détermine que le paramètre Clé de liaison se chevauche avec une entrée existante de clé de liaison, le SGP retourne un message Réponse d’enregistrement à l’ASP, avec un état d’enregistrement de "Erreur – Chevauchement de clé de liaison (non unique)". Un message de signalisation entrant reçu par un SGP ne peut pas correspondre à plus d’une clé de liaison.


Si le SGP n’autorise pas la demande d’enregistrement, 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é de liaison reçue n’existe pas actuellement et si le SGP n’accepte pas la configuration dynamique, le SGP retourne un message Réponse d’enregistrement à l’ASP, contenant un résultat d’enregistrement de "Erreur – Clé de liaison non provisionnée".


Si un SGP détermine qu’une clé de liaison reçue n’existe pas actuellement et si le SGP accepte la reconfiguration dynamique mais n’a pas la capacité d’ajouter de nouvelles entrées de clé de liaison et de serveur d’application, le SGP retourne un message Réponse d’enregistrement à l’ASP, contenant un résultat d’enregistrement "Erreur – Ressources insuffisantes".


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


      1. 4.4.2 Désenregistrement

Un ASP PEUT se désenregistrer de façon dynamique d’un SGP comme un ASP au sein d’un serveur d’application pour le ou les identifiants d’interface individuels en utilisant le message DEREG REQ. Un paramètre Identifiant d’interface dans DEREG REQ spécifie quel identifiant d’interface désenregistrer.


Le SGP examine le contenu du paramètre Identifiant d’interface reçu et valide que l’ASP est actuellement enregistré dans le ou les serveurs d’application qui se rapportent aux identifiants d’interface 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 de la clé de liaison et des données de configuration de serveur d’application au SGP. D’autres ASP peuvent continuer d’être associés au serveur d’application, auquel cas les données de clé de liaison NE PEUVENT PAS être supprimées. Si un désenregistrement résulte en ce qu’il n’y a plus d’ASP dans un serveur d’application, un SGP PEUT supprimer les données de clé de liaison.


Le SGP accuse réception du désenregistrement demandé en retournant un 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 et la cause.


Un ASP PEUT désenregistrer plusieurs identifiants d’interface en une seule fois en incluant plusieurs identifiants d’interface dans un seul message DEREG REQ. Le SGP DOIT répondre à chaque demande de désenregistrement dans un seul message DEREG RSP, indiquant le succès ou l’échec pour chaque identifiant d’interface dans un paramètre Résultat de désenregistrement séparé.


5. Exemples de procédure d’adaptation d’utilisateur MTP2 (M2UA)

    1. 5.1 Exemples d’établissement d’associations entre SGP et MGC

      1. 5.1.1 ASP unique dans un serveur d’application (1+0 restreint)

Ce scénario montre l’exemple de flux de messages M2UA pour l’établissement du trafic entre un SGP et un ASP, où seulement un ASP est configuré au sein d’un AS (pas de sauvegarde). On suppose que l’association SCTP est déjà établie.


SGP ASP1

|<---------ASP Up----------|

|--------ASP Up Ack------->|

| |

|<-------ASP Active--------|

|------ASP Active Ack----->|

| |

|------NTFY(AS-ACTIVE)---->|


      1. 5.1.2 ASP unique dans un serveur d’application (1+0 restreint) avec enregistrement dynamique

Ce scénario est le même que celui du paragraphe 5.1.1 mais avec un enregistrement dynamique (allocation automatique) d’un identifiant d’interface(s).


SGP ASP1

|<---------ASP Up----------|

|--------ASP Up Ack------->|

| |

|<--------REG REQ----------|

|------REG REQ RESP------->|

| |

|<-------ASP Active--------|

|------ASP Active Ack----->|

| |

|------NTFY(AS-ACTIVE)---->|


      1. 5.1.3 Deux ASP dans un serveur d’application (1+1 restreint)

Ce scénario montre l’exemple de flux de messages M2UA pour l’établissement de trafic entre un SGP et deux ASP dans le même serveur d’application, où ASP1 est configuré pour être actif et ASP2 pour être en attente d’un événement d’échec de communication ou de retrait de service de ASP1. ASP2 PEUT agir comme remplaçant chaud, tiède, ou froid selon la mesure dans laquelle ASP1 et ASP2 partagent l’état d’appel/transaction ou peuvent communiquer l’état d’appel en cas d’événement d’échec/retrait.


SGP ASP1 ASP2

| | |

|<--------ASP Up----------| |

|-------ASP Up Ack------->| |

| | |

|<-----------------------------ASP Up----------------|

|----------------------------ASP Up Ack------------->|

| | |

| | |

|<-------ASP Active-------| |

|-----ASP Active Ack----->| |

| | |

| | |

|-----NTFY(AS-ACTIVE)---->| |

| | |

|------------------NTFY(AS-ACTIVE)------------------>|


    1. 5.2 Exemples de reprise de trafic d’ASP sur échec

      1. 5.2.1 (1+1 restreint, retrait d’ASP, outrepassement de sauvegarde)

À la suite de l’exemple du paragraphe 5.1.2, l’ASP 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)------------------>|

| | |

Dans ce cas, le SGP notifie à ASP2 que l’AS est passé à l’état AS-PENDING. ASP2 envoie ASP Active pour ramener l’AS à l’état AS-ACTIVE. Si ASP2 n’a pas envoyé le message ASP Active avant que T(r) expire, le SGP va envoyer un NOTIFY (AS-DOWN).


Note : Si le SGP détecte la perte de l’homologue M2UA (par une détection d’échec SCTP) l’échange initial de message SGP-ASP1 ASP Inactive ne va pas se produire .


SGP ASP1 ASP2

| (détecte l’échec SCTP | |

|------------------NTFY(AS-PENDING)----------------->|

| | |

|<------------------------------ ASP Active----------|

|-----------------------------ASP Active Ack-------->|

| | |

|------------------NTFY(AS-ACTIVE)------------------>|

| | |


      1. 5.2.2 (1+1 restreint, outrepassement de sauvegarde)

À la suite de l’exemple du paragraphe 5.1.2, et ASP2 souhaite outrepasser ASP1 et prendre le trafic:


SGP ASP1 ASP2

| | |

|<-------------------------------ASP Active----------|

|-----------------------------ASP Active Ack-------->|

|----NTFY(Alt ASP-Act)--->| |

| | |


Dans ce cas, le SGP notifie à ASP1 qu’un autre ASP de remplacement l’a outrepassé.


    1. 5.3 Procédures frontières de SGP à MGC, MTP niveau 2 à MTP niveau 3


Lorsque la couche M2UA sur l’ASP a un message MAUP à envoyer au SGP, elle va faire ce qui suit :

- déterminer le SGP correct

- trouver l’association SCTP au SGP choisi

- déterminer le flux correct dans l’association SCTP sur la base de la liaison SS7

- remplir le message MAUP, remplir l’en-tête de message M2UA, remplir l’en-tête commun

- envoyer le message MAUP à l’homologue M2UA distant dans le SGP, sur l’association SCTP


Lorsque la couche M2UA sur le SGP a un message MAUP à envoyer à l’ASP, elle va faire ce qui suit :

- déterminer l’AS pour l’identifiant d’interface

- déterminer l’ASP actif (association SCTP) au sein de l’AS

- déterminer le flux correct dans l’association SCTP sur la base de la liaison SS7

- remplir le message MAUP, remplir l’en-tête de message M2UA, remplir l’en-tête commun

- envoyer le message MAUP à l’homologue M2UA distant dans l’ASP, sur l’association SCTP


      1. 5.3.1 Alignement de liaison SS7

Le MGC peut demander qu’une liaison SS7 soit alignée en utilisant la procédure normale ou la procédure d’urgence [Q.701-5], [T1.111]. Un exemple du flux de message pour mettre en service une liaison SS7 en utilisant la procédure normale d’alignement est donné ci-dessous.


SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

<----Start Req---|<---Establish Req----|<----Start Req------

---In Serv Ind-->|----Establish Cfm--->|----In Serv Ind---->


Exemple du flux de message pour mettre en service une liaison SS7 en utilisant la procédure d’alignement d’urgence.


SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

<----Emer Req----|<--State Req (STATUS_EMER_SET)----|<----Emer Req---

-----Emer Cfm--->|---State Cfm (STATUS_EMER_SET)--->|----Emer Cfm---->

<---Start Req----|<-------Establish Req-------------|<---Start Req----

---In Serv Ind-->|--------Establish Cfm------------>|---In Serv Ind-->


      1. 5.3.2 Libération de liaison SS7

Le MGC peut demander qu’une liaison SS7 soit mise hors service. Il utilise le message Demande de libération (Release Request) comme montré ci-dessous.


SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

<-----Stop Req-----|<---Release Req------|<-----Stop Req------

--Out of Serv Ind->|----Release Cfm----->|--Out of Serv Ind-->


Le SGP peut indiquer de façon autonome qu’une liaison SS7 est passée hors service, comme montré ci-dessous.


SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

--Out of Serv->|----Release Ind----->|--Out of Serv-->


      1. 5.3.3 Établissement et libération d’une panne de processeur local

Le MGC peut établir une condition de panne de processeur local. Il utilise le message Demande d’état (State Request) comme on le montre ci-dessous.


SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

<----LPO Req----|<---State Req (STATUS_LPO_SET)----|<----LPO Req---

-----LPO Cfm--->|----State Cfm (STATUS_LPO_SET)--->|----LPO Cfm---->


Le MGC peut libérer une condition de panne de processeur local. Il utilise le message Demande d’état comme on le montre ci-dessous.


SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

<---LPO Req---|<---State Req (STATUS_LPO_CLEAR)----|<----LPO Req---

----LPO Cfm-->|----State Cfm (STATUS_LPO_CLEAR)--->|----LPO Cfm---->


      1. 5.3.4 Notification de panne de processeur distant

Le SGP peut indiquer que l’homologue distant est entré ou sorti de la condition de panne de processeur pour une liaison SS7. Il utilise le message Indication d’état comme on le montre ci-dessous.


SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

----RPO Ind---->|----State Ind (EVENT_RPO_ENTER)-->|-----RPO Ind---->

-RPO Rcvr Ind-->|----State Ind (EVENT_RPO_EXIT)--->|--RPO Rcvr Ind-->


      1. 5.3.5 Notification d’encombrement de liaison SS7

Le SGP peut indiquer qu’une liaison SS7 est devenue encombrée. Il utilise le message Indication d’encombrement comme on le montre ci-dessous.


SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

----Cong Ind---->|--------Cong Ind (STATUS)------->|----Cong Ind---->

-Cong Cease Ind->|--------Cong Ind (STATUS)------->|-Cong Cease Ind->


      1. 5.3.6 Changement de liaison SS7

Un exemple du flux de messages pour un changement sans erreur est montré ci-dessous. Dans cet exemple, il y a trois messages dans la file d’attente de retransmission qui doivent être restitués.

SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---

(seq_num = 0)

-Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm-->

(seq_num = BSN)

<-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req---

(seq_num = FSN)

-Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm-->

(seq_num = 0)

-Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind-->

-Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind-->

-Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind-->

-Rtrv Compl Ind->|----Retrieval Compl Ind ---->|-Rtrv Compl Ind-->


Note : Le nombre d’indications de restitution dépend du nombre de messages demandés dans la file d’attente de retransmission. Une seule indication Restitution achevée DEVRAIT être envoyée.


Un exemple de flux de messages avec une restitution d’erreur est montré ci-dessous.

SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---

-BSN Not Rtrv->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---BSN Not Rtrv-->

(seq_num = -1)


Un exemple de flux de messages avec une erreur restituant le messages est montré ci-dessous.


<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---

-Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm-->

(seq_num = BSN)

<-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req---

(seq_num = FSN)

-Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm-->

(seq_num = -1)


Un exemple de flux de messages pour une demande d’abandon de messages (vider les mémoires tampon de retransmission) est donné ci-dessous.

SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

-Clr RTB Req----|<-StateReq (STATUS_CLEAR_RTB)--|<--Clr RTB Req-----

-Clr RTB Req--->|-StateCfm (STATUS_CLEAR_RTB)-->|---Clr RTB Req---->


      1. 5.3.7 Purger et continuer

Le flux de messages suivant montre une demande de purge des mémoires tampon.

SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

<--Flush Req----|<-State Req (STATUS_FLUSH_BUFS)--|<---Flush Req--

---Flush Cfm--->|--State Cfm (STATUS_FLUSH_BUFS)->|---Flush Cfm-->


Le flux de messages suivant montre une demande de continuer.

SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

<---Cont Req----|<--State Req (STATUS_CONTINUE)---|<---Cont Req---

----Cont Cfm--->|---State Cfm (STATUS_CONTINUE)-->|----Cont Cfm-->


      1. 5.3.8 Audit de l’état de liaison SS7

Il peut être nécessaire que l’ASP examine l’état actuel d’une liaison SS7. Le flux ci-dessous montre un exemple de la demande et de toutes les réponses potentielles.


Voici un exemple dans lequel la liaison SS7 est hors service.

SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

|<----State Req (STATUS_AUDIT)----|<----Audit-------

|-----------Release Ind---------->|-Out of Serv Ind->

|-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm--->


Voici un exemple où la liaison SS7 est en service.


SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

|<----State Req (STATUS_AUDIT)----|<----Audit-------

|-----------Establish Cfm-------->|---In Serv Ind-->

|-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm--->


Voici un exemple où la liaison SS7 est en service, mais encombrée.


SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

|<----State Req (STATUS_AUDIT)----|<----Audit-------

|-----------Establish Cfm-------->|---In Serv Ind-->

|----------Congestion Ind-------->|---Cong Ind----->

|-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm--->


Voici un exemple où la liaison SS7 est en service, mais en panne de processeur distant.


SGP MTP2 SGP M2UA ASP M2UA ASP MTP3

|<----State Req (STATUS_AUDIT)----|<---Audit Req----

|-----------Establish Ind-------->|---In Serv Ind-->

|---State Ind (EVENT_RPO_ENTER)-->|----RPO Enter--->

|-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm--->


6. Valeur des temporisateurs


Les valeurs par défaut recommandées pour les temporisateurs M2UA sont :

T(r) 2 secondes

T(ack) 2 secondes

T(beat) 30 secondes


7. Considérations pour la sécurité


M2UA est conçu pour porter les messages de signalisation pour les services de téléphonie. À ce titre, M2UA DOIT inclure les besoins de sécurité de plusieurs parties : les utilisateurs finaux des services, les fournisseurs de réseaux et les applications en cause. Des exigences supplémentaires PEUVENT venir des réglementations locales. Bien que certains besoins de sécurité se recoupent, toute solution de sécurité DEVRAIT satisfaire aux besoins de toutes les différentes parties.


    1. 7.1 Menaces

Il n’y a pas de solution toute faite immédiatement applicable pour les problèmes de sécurité. En tant que protocole de transport, M2UA a les objectifs de sécurité suivants :

* disponibilité d’un transport de données d’utilisateur fiable et en temps opportun ;

* intégrité du transport des données d’utilisateur ;

* confidentialité des données d’utilisateur.


M2UA fonctionne par dessus SCTP. SCTP [RFC2960] fournit certaines caractéristiques de sécurité en rapport avec le transport, telles que :

* les attaques aveugles de déni de service

* l’inondation

* l’usurpation d’identité

* la monopolisation des services par un usager non approprié.


Lorsque M2UA fonctionne dans un réseau d’entreprise géré de façon professionnelle ou par un fournisseur de service, il est raisonnable de s’attendre à ce que ce réseau comporte un cadre de politique de sécurité approprié. Le "Manuel de la sécurité des sites" [RFC2196] DEVRAIT être consulté pour des lignes directrices.


Lorsque le réseau dans lequel fonctionne M2UA implique plus d’une partie, il NE PEUT PAS être raisonnable de s’attendre à ce que toutes les parties aient mis en œuvre une sécurité suffisante. Dans un tel cas, il est recommandé d’utiliser IPSEC pour assurer la confidentialité de la charge utile d’utilisateur. Consulter la [RFC2401] pour plus d’informations sur la configuration des services IPSEC.


    1. 7.2 Protéger la confidentialité

En particulier pour les utilisateurs mobiles, l’exigence de confidentialité PEUT inclure le masquage des adresses et accès IP. Dans ce cas, le chiffrement au niveau application n’est pas suffisant ; IPSEC ESP DEVRAIT plutôt être utilisé. Sans considération du niveau qui effectue le chiffrement, le service IPSEC ISAKMP DEVRAIT être utilisé pour la gestion de clés.


8. Considérations relatives à l’IANA

    1. 8.1 Identifiant de protocole de charge utile SCTP


Une demande sera adressée à l’IANA pour allouer une valeur M2UA à l’identifiant de protocole de charge utile dans le tronçon Données de charge utile SCTP. L’identifiant de protocole de charge utile SCTP a été enregistré :


M2UA : "2"


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


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


    1. 8.2 Extensions au protocole M2UA

Le présent protocole peut aussi être étendu de trois façons par l’IANA :

-- 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 nouveaux types, classes et paramètres de message fait partie intégrante des couches d’adaptation SIGTRAN. Donc, ces extensions sont allouées par l’IANA par une action de consensus de l’IETF telle que définie dans la [RFC2434].


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


      1. 8.2.1 Classes de message définies par l’IETF

La documentation pour une nouvelle classe de message DOIT inclure les informations suivantes :

(a) Un nom long et un nom court pour la classe de message.

(b) Une description détaillée de l’objet de la classe de message.


      1. 8.2.2 Types de message définis par l’IETF

La documentation du type de message DOIT contenir les informations suivantes :

(a) Un nom long et un nom court pour le nouveau type de message.

(b) Une description détaillée de la structure du message.

(c) Une définition détaillée et la description de l’utilisation prévue de chaque champ dans le message.

(d) Une description détaillée des procédures d’utilisation du nouveau type de message pendant le fonctionnement du protocole.

(e) Une description détaillée des conditions d’erreur lors de la réception de ce type de message.


Lorsque une mise en œuvre reçoit un type de message qu’elle ne prend pas en charge, elle DOIT répondre par un message d’erreur (ERR) avec un code d’erreur de Type de message non accepté.


      1. 8.2.3 Extension de paramètre de TLV défini par l’IETF

La documentation de 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 de type-longueur-valeur décrit au paragraphe 3.1.5.

(c) Définition détaillée de chaque composant de la valeur du paramètre.

(d) Description détaillée de l’utilisation prévue de ce type de paramètre, et indication des circonstances ou plusieurs instances de ce type de paramètre peuvent être trouvées dans le même type de message.


9. Remerciements


Les auteurs tiennent à remercier Tom George (Alcatel) de sa contribution au texte et au travail de spécification.


Les auteurs tiennent aussi à remercier John Loughney, Neil Olson, Michael Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Joe Keller, Heinz Prantner, Barry Nagelberg, Naoto Makinae, Joyce Archibald, Mark Kobine, Nitin Tomar, Harsh Bhondwe et Karen King de leurs précieux commentaires et suggestions.



10. Références

    1. 10.1 Normatives


[ANSI X3.4] ANSI X3.4-1986, "Coded Character Set -- 7-Bit American Standard Code for Information Interchange".


[GR-246] Bellcore GR-246-CORE "Bell Communications Research Specification of Signalling System Number 7", Volume 1, décembre 1995.


[Q.700] Recommandation UIT-T Q.700, "Introduction au système de signalisation n° 7 (SS7) de l’UIT-T"


[Q.701-5] Recommandation UIT-T Q.701-Q.705, "Système de signalisation n° 7 (SS7) – sous-système de transfert de message (MTP)"


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


[RFC2279] F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", janvier 1998. (Obsolète, voir RFC3629) (D.S.)


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


    1. 10.2 Informatives


[Q.751.1] Recommandation UIT-T Q.751.1, "Modèle d’information de gestion d’élément de réseau pour le sous-système de transfert de message", Genève, octobre 1995


[Q.2140] Recommandation UIT-T Q.2140, "Couche d’adaptation ATM pour le RNIS-LB", Genève, février 1995


[Q.2210] Recommandation UIT-T Q.2210, "Fonctions et messages de niveau 3 du sous-système de transfert de message utilisant les services de la Recommandation UIT-T Q.2140", Genève, août 1995


[RFC2196] B. Fraser, "Manuel de la sécurité des sites", septembre 1997. (FYI0008) (Information)


[RFC2401] S. Kent et R. Atkinson, "Architecture de sécurité pour le protocole Internet", novembre 1998. (Obsolète, voir RFC4301)


[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) (MàJ par RFC3309) (P.S.)


Appendice A Architecture de réseau de signalisation


Une passerelle de signalisation va prendre en charge le transport du trafic de signalisation MTP2-usager reçu du réseau SS7 jusqu’à un ou plusieurs ASP répartis (par exemple, des MGC). Il est clair que la description du protocole M2UA ne peut pas par elle-même satisfaire les exigences de performances et de fiabilité pour un tel transport. Une architecture de réseau physique est nécessaire, avec des données sur la disponibilité et les performances de transfert des nœuds physiques impliqués dans tout échange d’informations particulier. Cependant, le protocole M2UA est assez souple pour permettre son fonctionnement et sa gestion dans des configurations physiques diverses qui vont permettre aux opérateurs réseau de satisfaire leurs exigences de performance et de fiabilité.


Pour satisfaire aux exigences strictes de fiabilité et de performances de la signalisation SS7 pour les réseaux de classe professionnelle, ces opérateurs réseau devraient s’assurer qu’il n’y a pas un seul point de défaillance dans l’architecture réseau de bout en bout entre un nœud SS7 et un ASP IP.


En fonction bien sûr de la fiabilité des éléments fonctionnels SGP et ASP, cela peut normalement être satisfait en développant les liaisons SS7 dans un ensemble de liaisons (linkset) SS7 [Q.700] à travers les SGP ou les SG, en fournissant des chemins réseau IP redondants avec une QS garantie pour les associations SCTP entre les points d’extrémité SCTP, et des hôtes redondants. La distribution des ASP au sein des hôtes disponibles est aussi importante. Pour un serveur d’application particulier, les ASP concernés PEUVENT être distribués sur au moins deux hôtes.


Un exemple d’architecture de réseau logique pertinente pour un fonctionnement de niveau professionnel dans le domaine réseau IP est donné à la Figure 7 ci-dessous.


************** **************

* ********__*______________________________*__******** * Hôte1

SG1 * * SGP1 *__*________________ _______*__* ASP1 * *

* ******** * | | * ******** *

* . * | | * *

* . * | | **************

************** | |

| |

************** | |

* ********__*______________________|

SG2 * * SGP2 *__*________ |

* ******** * | |

* . * | |

* . * | |

************** | | **************

| |_____________*__******** * Hôte2

|_____________________*__* ASP2 * *

. * ******** *

. Associations SCTP * *

. **************

.

.


Figure 7 : Exemple de modèle logique


Pour éviter un seul point de défaillance, il est recommandé qu’un minimum de deux ASP soient configurés dans une liste d’AS, résidents dans des hôtes séparés, et donc disponibles sur des associations SCTP différentes. Par exemple, dans le réseau montré à la Figure 7, tous les messages pour les identifiants d’interface pourraient être envoyés à ASP1 dans Host1 ou à ASP2 dans Host2. La liste d’AS à SGP1 pourrait ressembler à :

identifiants d’interface – serveur d’application n°1

ASP1/Hôte1 - État = Actif

ASP2/Hôte2 - État = Inactif


Dans ce cas de redondance 1+1, ASP1 dans Hôte1 se verrait envoyer tout message entrant pour les identifiants d’interface enregistrés. ASP2 dans Hôte2 serait normalement amené à l’état actif sur défaillance de ASP1/Hôte1. Dans cet exemple, les deux ASP sont inactif ou actif, ce qui signifie que l’association SCTP et l’homologue M2UA de l’extrémité distante concernés sont prêts.

Pour les réseaux de classe professionnelle, les opérateurs devraient s’assurer qu’en cas de défaillance ou d’isolement d’un ASP particulier, des appels ou transactions stables ne sont pas perdus. Cela implique que les ASP ont besoin, dans certains cas, de partager l’état d’appel/-transaction ou d’être capables de passer l’état d’appel/transaction de l’un à l’autre. Aussi, dans le cas d’ASP qui effectuent du traitement d’appel, une coordination PEUT être requise avec la passerelle support concernée pour transférer le contrôle de MGC pour une terminaison réseau particulière. Cependant, ce partage ou cette communication sortent du domaine d’application du présent document.


11. Adresse des auteurs


Ken Morneault

Ram Dantu, Ph.D.

Greg Sidebottom

Cisco Systems Inc.

NetRake Corporation

Signatus Technologies

13615 Dulles Technology Drive

3000 Technology Drive

Kanata, Ontario,

Herndon, VA. 20171

Plano, TX 75074

Canada

USA

USA

mél : greg@signatustechnologies.com

téléphone : +1-703-484-3323

téléphone : +1-214-291-1111


mél : kmorneau@cisco.com

mél : rdantu@netrake.com




Brian Bidulock

Jacob Heitz

OpenSS7 Corporation

Lucent Technologies

1469 Jeffreys Crescent

1701 Harbor Bay Parkway

Edmonton, AB T6L 6T1

Alameda, CA, 94502

Canada

USA

téléphone : +1-780-490-1141

téléphone : +1-510-747-2917

mél : bidulock@openss7.org

mél : jheitz@lucent.com


Déclaration complète de droits de reproduction


Copyright (C) The Internet Society (2002). Tous droits réservés.


Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.


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


Remerciement

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

page - 56 -