Groupe de travail Réseau

J. Loughney, éditeur, Nokia

Request for Comments : 3868

G. Sidebottom, Signatus Technologies

Catégorie : En cours de normalisation

L. Coene & G. Verwimp, Siemens n.v.

octobre 2004

J. Keller, Tekelec

Traduction Claude Brière de L'Isle

B. Bidulock, OpenSS7 Corporation



Couche d'adaptation d'utilisateur
du sous-ensemble de contrôle de connexion de signalisation (SUA)



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.


Notice de copyright

Copyright (C) The Internet Society (2004).


Résumé

Le présent document définit un protocole pour le transport de toute signalisation sur le sous système utilisateur de commande de connexion de signalisation en utilisant le protocole de transmission de commande de flux (SCTP, Stream Control Transmission Protocol). Le protocole est conçu comme modulaire et symétrique, pour lui permettre de travailler dans diverses architectures, comme celle de passerelles de signalisation à des points d'extrémité de signalisation IP ainsi que celle d'une architecture de points d'extrémité de signalisation IP d'homologue à homologue.


Table des Matières

1. Introduction 2

1.1 Domaine d'application 2

1.2 Abréviations et terminologie 2

1.3 Architecture de transport de signalisation 4

1.4 Services fournis par la couche SUA 6

1.5 Fonctions internes fournies dans la couche SUA 7

1.6 Définition des frontières de SUA 9

2. Conventions 12

3. Éléments du protocole 12

3.1 En-tête commun de message 12

3.2 Messages SUA sans connexion 14

3.3 Messages en mode connexion 17

3.4 Messages de gestion de réseau de signalisation (SNM, Signalling Network Management) 25

3.5 Messages de maintenance d'état de processus de serveur d'application 29

3.6 Messages de maintenance de trafic d'ASP 31

3.7 Messages de gestion de SUA 33

3.8 Messages de gestion de clé d'acheminement (RKM, Routing Key Management) 35

3.9 Paramètres communs 37

3.10 Paramètres spécifiques de SUA 45

4. Procédures 56

4.1 Procédures de prise en charge de la couche utilisateur SUA 56

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

4.3 Maintenance d'état d'AS et d'ASP 58

4.4 Procédures de gestion de clé d'acheminement 65

4.5 État de disponibilité et/ou d'encombrement du SS7 Destination Support 67

4.6 Redémarrage MTP3 68

4.7. Interfonctionnement SCCP - SUA à la SG 69

5. Exemples de procédures SUA 70

5.1 Architecture de SG 70

5.2 Exemples IPSP 71

6. Considérations sur la sécurité 72

7. Considérations relatives à l'IANA 72

7.1 Identifiant de protocole de charge utile SCTP 72

7.2 Numéro d'accès 72

7.3 Extensions de protocole 73

8. Valeur des temporisateurs 73

9. Remerciements 73

10. Références 73

10.1 Références normatives 73

10.2 Références pour information 74

Appendice A Architecture de réseau de signalisation 74

A.1 Architecture de réseau d'homologue à homologue généralisé 74

A.2 Passerelle de signalisation Network Architecture 75

A.3 Recommandations pour la distribution de message aux passerelles de signalisation 76

Adresse des auteurs 77

Déclaration complète de droits de reproduction 77


1. Introduction


L'intégration des réseaux à commutation de circuits et des réseaux IP est en cours. Les fournisseurs de service réseau conçoivent des architectures de signalisation fondées sur IP qui ont besoin de prendre en charge des protocoles de signalisation pour le SS7 et équivalents. de fournit un moyen efficace pour transporter les données d'utilisateur et pour que les opérateurs étendent leurs réseaux et construisent de nouveaux services. Dans ces réseaux, il y a besoin d'un interfonctionnement entre les domaines SS7 et IP [RFC2719].


Le présent document définit un protocole pour le transport des protocoles SS7 d'utilisateur SCCP [ANSI SCCP], [ITU SCCP], tels que TCAP et RANAP, sur IP en utilisant le protocole de transmission de contrôle de flux (SCTP, Stream Control Transmission Protocol) [RFC2960].


1.1 Domaine d'application


Le présent document détaille la livraison des messages d'utilisateur SCCP (MAP & CAP sur TCAP [ANSI TCAP], [ITU TCAP], [RANAP], etc.) sur IP entre deux points d'extrémité de signalisation. On prend en considération le transport d'une passerelle de signalisation à un nœud de signalisation IP (comme une base de données résidant sur IP) comme décrit dans le cadre architectural de transport de signalisation [RFC2719]. Le présent protocole peut aussi prendre en charge le transport de messages d'utilisateur SCCP entre deux points d'extrémité entièrement contenus dans un réseau IP.


Le mécanisme de livraison concerne les critères suivants :

* la prise en charge du transfert de messages du sous système utilisateur SCCP,

* la prise en charge du service SCCP sans connexion,

* la prise en charge du service SCCP en mode connexion,

* la prise en charge du fonctionnement des homologues du protocole d'utilisateur SCCP,

* la prise en charge de la gestion des associations de transport SCTP entre des passerelles de signalisation et des nœuds de signalisation fondés sur IP,

* la prise en charge de nœuds de signalisation fondés sur IP répartis,

* la prise en charge de rapports asynchrones des changements d'état à des fonctions de gestion.


1.2 Abréviations et terminologie

1.2.1 Abréviations

CAP (CAMEL Application Protocol) protocole d'application CAMEL

GTT (Global Title Translation) traduction de titre global.

MAP (Mobile Application Protocol) protocole d'application mobile

MTP (Message Transfer Part) sous-système de transfert de messages

PC (Signalling System no. 7 Point Code) codet du système de signalisation n° 7

RANAP (Radio Access Network Application Protocol) protocole d'application de réseau d'accès radio

SCTP (Stream Control Transmission Protocol) protocole de transmission de contrôle de flux

SS7 (Signalling System no. 7) système de signalisation n° 7

TCAP (Transaction Capabilities Application Protocol) protocole d'application des capacités de transaction


1.2.2 Terminologie

Passerelle de signalisation (SG, Signalling Gateway) : élément de réseau qui termine les réseaux à commutation de circuit et transporte la signalisation d'utilisateur SCCP sur IP à un point d'extrémité de signalisation IP. Une passerelle de signalisation pourrait être modélisée comme un ou plusieurs processus de passerelle de signalisation, qui sont localisés à la bordure des réseaux SS7 et IP. Lorsque une SG contient plus d'un SGP, la SG est une entité logique et les SGP contenus sont supposés être coordonnés dans une seule perspective de gestion au réseau SS7 et aux serveurs d'application pris en charge.


Serveur d'application (AS, Application Server) : entité logique qui sert une clé d'acheminement spécifique. Un exemple de serveur d'application est un élément de base de données IP virtuelle qui traite toutes les demandes pour un utilisateur SCCP. L'AS contient un ensemble d'un ou plusieurs processus de serveur d'application uniques, dont normalement un ou plusieurs traitent activement le trafic.


Processus de serveur d'application (ASP, Application Server Process) : il sert de processus actif ou de secours d'un serveur d'application (par exemple, une partie d'un nœud de signalisation réparti ou un élément de base de données). Des exemples d'ASP sont des MGC, des SCP IP, ou des HLR fondés sur IP. Un ASP contient un point d'extrémité SCTP et peut être configuré à traiter du trafic au sein de plus d'un serveur d'application.


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


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


Processus de signalisation : instance de traitement qui utilise une SUA pour communiquer avec d'autres processus de signalisation. Un ASP, un SGP et un IPSP sont tous des processus de signalisation.


Association : cela se réfère ici à une association SCTP. L'association fournit le transport pour la livraison des unités de données de protocole d'utilisateur SCCP et des messages d'homologue de couche SUA.


Clé d'acheminement : cela décrit un ensemble de paramètres SS7 et/ou de gammes de paramètres qui définit de façon univoque la gamme de trafic de signalisation configuré pour être traité par un serveur d'application particulier. Un exemple serait une clé d'acheminement consistant en un SSN SCCP SS7 particulier plus un identifiant pour marquer de façon univoque le réseau auquel appartient le SSN, pour lequel tout le trafic sera dirigé sur un serveur d'application particulier. Les clés d'acheminement sont mutuellement exclusives en ce sens qu'un message de signalisation SS7 reçu ne peut pas être dirigé sur plus d'une clé d'acheminement. Les clés d'acheminement peuvent être provisionnées, par exemple, par une MIB ou enregistrées en utilisant les procédures dynamiques d'enregistrement de SUA. Les clés d'acheminement NE DOIVENT PAS s'étendre sur plusieurs apparences de réseau.


Contexte d'acheminement : un processus de serveur d'application peut être configuré à traiter le trafic au sein de plus d'un serveur d'application. Dans ce cas, le paramètre Contexte d'acheminement est échangé entre le SGP et l'ASP (ou entre deux ASP) identifiant le serveur d'application pertinent. Du point de vue d'un SGP/ASP, le contexte d'acheminement identifie de façon univoque la gamme de trafic, associée à un certain serveur d'application, que l'ASP est configuré à recevoir. Il y a une relation biunivoque entre une valeur de contexte d'acheminement et une clé d'acheminement au sein d'un AS. Donc, le contexte d'acheminement peut être vu comme un indice dans un tableau d'AS contenant les clés d'acheminement de l'AS.


Fonction de transposition d'adresse (AMF, Address Mapping Function) – c'est une fonction qui dépend de la mise en œuvre et est responsable de la résolution de l'adresse présentée dans le message SCCP/SUA entrant pour corriger l'association SCTP pour le point d'extrémité désiré. L'AMF PEUT utiliser les informations de contexte d'acheminement / clé d'acheminement comme critère de choix de l'association SCTP appropriée.


Repli (Fail-over) : capacité de réacheminer le trafic de signalisation en tant que de besoin sur un autre processus de serveur d'application, ou groupe d'ASP, au sein d'un serveur d'application en cas de défaillance ou d'indisponibilité du processus de serveur d'application actuellement utilisé. Le repli peut s'appliquer au retour en service d'un processus de serveur d'application antérieurement indisponible.


Hôte : plate-forme de calcul sur laquelle fonctionne le processus de SGP ou d'ASP.


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


Apparence de réseau : c'est une référence locale de SUA (normalement un entier) partagée par une SG et un AS qui avec un codet de signalisation identifie de façon univoque un nœud SS7 en indiquant le réseau SS7 spécifique auquel il appartient.


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


Flux : un flux se réfère à un flux SCTP ; un canal logique unidirectionnel établi à partir d'un point d'extrémité SCTP avec 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é.


Adresse de transport : adresse qui sert de source ou de destination pour le service de transport de paquets non fiable utilisé par SCTP. Dans les réseaux IP, une adresse de transport est définie par la combinaison d'une adresse IP et le numéro d'accès SCTP. Noter qu'un seul accès SCTP peut être défini pour chaque point d'extrémité, mais chaque point d'extrémité SCTP peut avoir plusieurs adresses IP.


1.3 Architecture de transport de signalisation

Le cadre architectural qui a été défini pour le transport de signalisation des réseaux à commutation de circuit sur IP [RFC2719] utilise plusieurs composants, incluant un protocole de transport IP, un protocole de transport commun de signalisation et un module d'adaptation pour prendre en charge les services attendus par un protocole de signalisation particulier de réseaux à commutation de circuit à partir de sa couche de protocole sous-jacente.


En termes généraux, l'architecture de SUA peut être modélisée comme architecture d'homologue à homologue. La première section considère les architectures d'interfonctionnement de SS7 à IP pour les transports sans connexion et en mode connexion. Pour ce cas, on suppose que l'ASP initie l'établissement de l'association SCTP avec la SG.


1.3.1 Architecture du protocole pour le transport sans connexion

Dans cette architecture, les couches SCCP et SUA s'interfacent dans la SG. L'interfonctionnement entre les couches SCCP et SUA est nécessaire pour assurer le transfert des messages d'utilisateur ainsi que des messages de gestion.


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

* SEP *---------* *--------* *

* ou * * SG * * ASP *

* STP * * * * *

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

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

| SUAP | | SUAP |

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

| SCCP | | SCCP | SUA | | SUA |

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

| MTP3 | | MTP3 | | | |

+------+ +------+ SCTP | | SCTP |

| MTP2 | | MTP2 | | | |

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

| L1 | | L1 | IP | | IP |

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

| | | |

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


SUAP : protocole d'utilisateur SCCP/SUA (TCAP, par exemple)

STP (SS7 Signalling Transfer Point) : point de transfert de signalisation SS7

Voir à l'Appendice A.3.1 les recommandations de fonctionnement.


1.3.1.1 SG comme point d'extrémité

Dans ce cas, les messages SCCP sans connexion sont acheminés sur le codet (PC, point code) et le numéro de sous système (SSN, subsystem number). Le sous système identifié par le SSN et le contexte d'acheminement est considéré comme local pour la SG. Cela signifie du point de vue SS7, que l'utilisateur SCCP est situé à la SG.


1.3.1.2 Passerelle de signalisation comme point de relais

Une traduction de titre global est exécutée à la passerelle de signalisation, avant que la destination du message puisse être déterminée. La situation réelle de l'utilisateur SCCP n'est pas pertinente pour le réseau SS7. La traduction de titre global donne un "ensemble d'entités SCCP", à partir duquel un serveur d'application peut être déduit. Le choix du serveur d'application se fonde sur l'adresse de l'appelant SCCP (et éventuellement d'autres paramètres SS7 qui dépendent de la mise en œuvre).


1.3.2 Architecture du protocole pour le transport en mode connexion

Dans cette architecture, les couches SCCP et SUA partagent une interface dans le processus de passerelle de signalisation pour associer les deux sections de connexion nécessaires pour le transfert de données en mode connexion entre le SEP et l'ASP. Les deux sections de connexion sont établies lors de l'acheminement des messages de demande de connexion provenant du point d'extrémité de signalisation via le processus de passerelle de signalisation vers l'ASP et vice versa. L'acheminement du message de demande de connexion est effectué de la même façon que décrit au paragraphe 1.3.1.


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

* SEP/ *---------* SG *--------* ASP *

* STP * * * * *

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

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

| SUAP | | SUAP |

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

| SCCP | | SCCP | SUA | | SUA |

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

| MTP3 | | MTP3 | | | |

+------| +------+ SCTP | | SCTP |

| MTP2 | | MTP2 | | | |

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

| L1 | | L1 | IP | | IP |

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

| | | |

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


SUAP (SCCP/SUA Application Protocol) protocole d'application SCCP/SUA (par exemple, - RANAP/RNSAP)

STP (SS7 Signalling Transfer Point) : point de transfert de signalisation SS7

Voir à l'Appendice A.3.2 les recommandations de fonctionnement.


1.3.3 Architecture tout IP

Cette architecture peut être utilisée pour porter un protocole qui utilise les services de transport de SCCP au sein d'un réseau IP. Cela donne de la souplesse pour développer des réseaux, en particulier lorsque l'interaction avec la signalisation traditionnelle n'est pas nécessaire. L'architecture supprime le besoin de la fonction de passerelle de signalisation.


******** IP ********

* IPSP *--------* IPSP *

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

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

| SUAP | | SUAP |

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

| SUA | | SUA |

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

| SCTP | | SCTP |

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

| IP | | IP |

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

| |

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


SUAP (SCCP/SUA Application Protocol) protocole d'application SCCP/SUA (par exemple, - RANAP/RNSAP)


1.3.4 Modèle et terminologie d'ASP de repli

Le protocole SUA prend en charge des fonctions d'ASP de repli pour assurer une forte disponibilité de capacité de traitement de transactions.


Un serveur d'application peut être considéré comme une liste de tous les ASP configurés/enregistrés pour traiter les messages d'utilisateur SCCP au sein d'une certaine gamme d'informations d'acheminement, appelée une clé d'acheminement. Un ou plusieurs ASP dans la liste peuvent normalement être actifs pour traiter le trafic, tandis que d'autres peuvent être inactifs mais disponibles dans le cas de défaillance ou d'indisponibilité du ou des ASP actifs.

Voir à l'Appendice A les recommandations de fonctionnement.


1.4 Services fournis par la couche SUA

1.4.1 Prise en charge du transport des messages d'utilisateur SCCP

Le SUA prend en charge le transfert des messages d'utilisateur SCCP. La couche SUA à la passerelle de signalisation et à l'ASP prend en charge le transport transparent des messages d'utilisateur entre la passerelle de signalisation et l'ASP.


1.4.2 Prise en charge des classes de protocole SCCP

Selon les utilisateurs SCCP pris en charge, le SUA supporte de façon transparente les quatre classes possibles de protocole SCCP. Les classes de protocole SCCP sont définies comme suit :

* La classe de protocole 0 fournit le transfert non ordonné des messages d'utilisateur SCCP de manière sans connexion.

* La classe de protocole 1 permet à l'utilisateur SCCP de choisir la livraison séquentielle des messages d'utilisateur SCCP de manière sans connexion.

* La classe de protocole 2 permet le transfert bidirectionnel des messages d'utilisateur SCCP en établissant une connexion de signalisation temporaire ou permanente.

* La classe de protocole 3 permet les caractéristiques du protocole de classe 2 avec l'inclusion du contrôle de flux. La détection de la perte de message ou du déséquencement est incluse.


Les classes de protocole 0 et 1 constituent le service SCCP sans connexion. Les protocoles des classes 2 et 3 constituent le service SCCP en mode connexion.


1.4.3 Fonctions de gestion natives

La couche SUA fournit la capacité d'indiquer les erreurs associées aux messages de protocole SUA et de fournir la notification à la gestion locale et à l'homologue distant comme nécessaire.


1.4.4 Interfonctionnement avec les fonctions de gestion de réseau de SCCP

SUA utilise les messages de gestion d'ASP existants ou le traitement d'état d'ASP. L'inter fonctionnement avec les messages SCCP de gestion consiste en les messages DUNA, DAVA, DAUD, DRST, DUPU ou SCON (définis à la Section 3) à réception de SSP, SSA, SST ou SSC (définis par SCCP) aux ASP appropriés. Voir aussi le paragraphe 1.4.5. Les primitives ci-dessous sont envoyées entre le SCCP et les fonctions de gestion de SUA dans la SG pour déclencher des événements dans le domaine IP et SS7.


Nom générique

Nom spécifique

Référence ANSI/UIT

N-State

Indication de demande

UIT-Q.711 $ 6.3.2.3.2 (Tab 16/Q.711)
ANSI-T1.112 $ 2.3.2.3.2 (Tab 8E/T1.112.1)

N-PCstate

Indication

UIT-Q.711 $ 6.3.2.3.3 (Tab 1/Q.711)
ANSI-T1.112 $ 2.3.2.3.4 (Tab 8G/T1.112.1)

N-Coord

Confirmation de réponse à indication de demande

UIT-Q.711 $ 6.3.2.3.1 (Tab 15/Q.711)
ANSI-T1.112 $ 2.3.2.3.3 (Tab 8F/T1.112.1)


1.4.5 Prise en charge de la gestion entre le SGP et l'ASP

La couche SUA fournit l'inter fonctionnement avec les fonctions de gestion SCCP à la SG pour le fonctionnement entre les réseaux à commutation de circuits et le réseau IP. Elle devrait :

* Fournir l'indication à l'utilisateur SCCP à un ASP qu'un point d'extrémité/homologue SS7 est injoignable.

* Fournir l'indication à l'utilisateur SCCP à un ASP qu'un point d'extrémité/homologue SS7 est joignable.

* Fournir une indication d'encombrement à l'utilisateur SCCP à un ASP.

* Fournir l'initialisation d'un audit des points d'extrémité SS7 à la SG.


1.4.6 Fonction de relais

Pour les besoins de l'adaptabilité du réseau, la SUA peut être améliorée avec une fonction de relais pour déterminer l'association SCTP de prochain bond vers le point d'extrémité de SUA de destination.


La détermination du prochain bond peut se fonder sur des informations de titre global (par exemple, un numéro E.164) par analogie avec le GTT SCCP dans les réseaux SS7, modélisées dans [ITU SCCP]. Elle peut aussi se fonder sur des information de nom d'hôte, une adresse IP ou un codet contenu dans l'adresse du demandé.


Cela permet une plus grande adaptabilité, fiabilité et souplesse dans les déploiements à grande échelle de SUA. L'usage d'une fonction de relais est une décision de la mise en œuvre.


1.5 Fonctions internes fournies dans la couche SUA

Pour mettre en œuvre ses capacités d'adressage et de relais, la SUA utilise une fonction de transposition d'adresse (AMF, Address Mapping Function). Cette fonction est considérée comme faisant partie de SUA, mais la façon dont elle est réalisée est laissée à la mise en œuvre (tableaux locaux, DNS [RFC3761], LDAP, etc.)


L'AMF est invoquée lorsque un message est reçu à l'interface d'entrée. L'AMF est responsable de la résolution de l'adresse présentée dans le message SCCP/SUA entrant aux associations SCTP aux destinations au sein du réseau IP. L'AMF va choisir l'association SCTP appropriée sur la base du contexte d'acheminement et des informations de clé d'acheminement disponibles. La destination peut être le nœud SUA terminal ou un nœud SUA relais. Les clés d'acheminement font référence au serveur d'application, qui va avoir un ou plusieurs ASP qui traitent le trafic pour l'AS. La disponibilité et l'état des ASP sont traités par des messages de gestion d'ASP de SUA.


Les informations possibles d'adresse/acheminement SS7 qui comportent une entrée de clé d'acheminement incluent, par exemple, OPC, DPC, SIO trouvées dans l'étiquette d'acheminement MTP3, un numéro de sous système SCCP, ou un identifiant de transaction. Des adresses IP et des noms d'hôtes peuvent aussi être utilisés comme informations de clé d'acheminement.


Il est prévu que les clés d'acheminement soient provisionnées via une MIB, un enregistrement dynamique ou un processus externe, comme une base de données.


1.5.1 Transposition d'adresse à la SG

Normalement, un ou plusieurs ASP sont actifs dans l'AS (c'est-à-dire, traitant actuellement le trafic) mais dans certains cas d'échec et de transition, il est possible qu'il n'y ait pas d'ASP actif disponible. Le SGP va mettre le message destiné à cet AS en mémoire tampon pendant un temps T(r) ou jusqu'à ce qu'un ASP devienne disponible. Lorsque aucun ASP ne devient disponible avant l'expiration de T(r), le SGP va purger les messages en mémoire tampon et initier les procédures appropriées de retour ou de refus.


Si il n'y a pas de transposition d'adresse correspondante pour un message entrant, un traitement par défaut PEUT être spécifié. Les solutions possibles sont de fournir un serveur d'application par défaut pour diriger tout le trafic non alloué à un (ensemble de) ASP par défaut, ou d'éliminer les messages et fournir une notification à la gestion. Le traitement du trafic non alloué dépend de la mise en œuvre.


1.5.2 Transposition d'adresse à l'ASP

Pour diriger les messages sur le réseau SS7, l'ASP PEUT effectuer une transposition d'adresse pour choisir le SGP approprié pour un certain message. Cela se fait en observant le codet de destination et les autres éléments du message sortant, l'état du réseau SS7, la disponibilité de SGP, et les tableaux de configuration de contexte d'acheminement.


Une passerelle de signalisation peut être composée d'un ou plusieurs SGP. Il n'y a cependant pas de messagerie SUA pour gérer l'état d'un SGP. Chaque fois qu'existe une association SCTP à un SGP, on suppose qu'elle est disponible. Aussi, chaque SGP d'une SG communiquant avec un ASP concernant un AS fournit une connexité SS7 identique à cet ASP.


Un ASP achemine les réponses au SGP d'où il a reçu des messages au sein du contexte d'acheminement où il est actuellement actif et reçoit du trafic.


1.5.3 Fonction de transposition d'adresse à un nœud relais

La fonction relais est invoquée lorsque :

- l'acheminement est sur titre global

- l'acheminement est sur nom d'hôte

- l'acheminement est sur SSN et PC ou SSN et adresse IP et l'adresse présentée n'est pas celle du nœud relais.


La traduction/résolution des informations d'adresse ci-dessus donne un des cas suivants :

- Acheminement sur SSN : identifiant d'association SCTP vers le nœud de destination, SSN et facultativement contexte d'acheminement et/ou adresse IP.

- Acheminement sur titre global : identifiant d'association SCTP vers le prochain nœud relais, titre global (nouveau) et facultativement SSN et/ou contexte d'acheminement.

- Acheminement sur nom d'hôte : identifiant d'association SCTP vers le prochain nœud relais, nom d'hôte (nouveau) et facultativement SSN et/ou contexte d'acheminement.

- Un usager SUA local (nœud relais/d'extrémité combiné).


Pour empêcher la formation de boucles, un compteur de bonds SS7 est utilisé. Le nœud d'extrémité d'origine (qu'il soit un nœud SS7 ou IP) règle la valeur du compteur de bonds SS7 à la valeur maximum (15 ou moins). Chaque fois que la fonction relais est invoquée au sein d'un nœud intermédiaire (relais) le compteur de bonds SS7 est décrémenté. Lorsque sa valeur atteint zéro, la procédure de retour ou de refus est invoquée avec la cause "Violation du compteur de bonds".


1.5.4 Transposition de flux SCTP

La couche SUA prend en charge les flux SCTP. La passerelle de signalisation et le serveur d'applications doivent tenir une liste des utilisateurs de SCTP et de SUA pour les besoins de la transposition. Les utilisateurs SCCP qui exigent le transfert des messages en conservant la séquence des messages ont besoin qu'ils soient envoyés sur un flux qui livre en séquence.


La SUA utilise le flux 0 pour les messages de gestion SUA. Il est FACULTATIF que la livraison en séquence soit utilisée pour préserver l'ordre de livraison des messages de gestion.


Choix de flux fondé sur la classe de protocole :

- Classe de protocole 0 : la SUA PEUT choisir la livraison non ordonnée. Le flux est choisi sur la base des informations de trafic disponibles au SGP ou ASP.

- Classe de protocole 1 : la SUA DOIT choisir la livraison ordonnée. Le flux est choisi sur la base du paramètre de séquence donné par la couche supérieure sur l'interface primitive et les autres informations de trafic disponibles au SGP ou ASP.

- Classes de protocole 2 et 3 : la SUA DOIT choisir la livraison ordonnée. Le flux est choisi sur la base de la référence de source locale de la connexion et des autres informations de trafic disponibles au SGP ou ASP.


1.5.5 Contrôle de flux

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


1.5.6 Gestion d'encombrement

La couche SUA est informée de l'encombrement du réseau local et IP au moyen d'une fonction qui dépend de la mise en œuvre (par exemple, l'indication dépendante de la mise en œuvre de la part de SCTP que le réseau IP est encombré).


À un ASP ou IPSP, la couche SUA indique l'encombrement aux usagers SCCP locaux au moyen d'une primitive SCCP appropriée (par exemple, N-INFORM, N-NOTICE) conformément aux procédures courantes, pour invoquer les réponses appropriées des couches supérieures. Lorsque une SG détermine que le transport de messages SS7 rencontre de l'encombrement, la SG PEUT déclencher des messages SS7 d'encombrement SCCP aux nœuds SS7 générateurs, selon les procédures d'encombrement de la norme SCCP pertinente. Le déclenchement des messages SS7 de gestion SCCP à partir d'une SG est une fonction qui dépend de la mise en œuvre.


La couche SUA à un ASP ou IPSP PEUT indiquer l'encombrement local à une SUA homologue par un message SCON. Lorsque une SG reçoit un message d'encombrement (SCON) d'un ASP, et que la SG détermine qu'un point d'extrémité rencontre maintenant l'encombrement, elle PEUT déclencher les procédures d'encombrement de la norme SCCP pertinente.


1.6 Définition des frontières de SUA

1.6.1 Définition de la frontière supérieure

Les primitives suivantes sont prises en charge entre la SUA et un utilisateur SCCP (une référence aux paragraphes de l'UIT et de l'ANSI où sont ces primitives et les paramètres correspondants est aussi donnée) :


Nom générique

Nom spécifique

Référence ANSI/UIT

N-CONNECT

Confirmation de réponse à indication de demande

UIT Q.711 § 6.1.1.2.2 (Tab 2/Q.711)
ANSI-T1.112 § 2.1.1.2.2 (Tab 2/T1.112.1)

N-DATA

Indication de demande

UIT Q.711 § 6.1.1.2.3 (Tab 3/Q.711)
ANSI-T1.112 § 2.1.1.2.3 (Tab 3/T1.112.1)

N-EXPEDITED DATA

Indication de demande

UIT Q.711 § 6.1.1.2.3 (Tab 4/Q.711)
ANSI-T1.112 § 2.1.1.2.3 (Tab 4/T1.112.1)

N-RESET

Confirmation de réponse à indication de demande

UIT Q.711 § 6.1.1.2.3 (Tab 5/Q.711)
ANSI-T1.112 § 2.1.1.2.3 (Tab 5/T1.112.1)

N-DISCONNECT

Indication de demande

UIT Q.711 § 6.1.1.2.4 (Tab 6/Q.711)
ANSI-T1.112 § 2.1.1.2.4 (Tab 6/T1.112.1)

N-INFORM

Indication de demande

UIT Q.711 § 6.1.1.3.2 (Tab 8/Q.711)
ANSI-T1.112 § 2.1.1.2.5 (Tab 6A/T1.112.1)

N-UNITDATA

Indication de demande

UIT Q.711 § 6.2.2.3.1 (Tab 12/Q.711)
ANSI-T1.112 § 2.2.2.3.1 (Tab 8A/T1.112.1)

N-NOTICE

Indication

UIT Q.711 § 6.2.2.3.2 (Tab 13/Q.711)
ANSI-T1.112 § 2.2.2.3.2 (Tab 8B/T1.112.1)

N-STATE

Indication de demande

UIT Q.711 § 6.3.2.3.2 (Tab 16/Q.711)
ANSI-T1.112 § 2.3.2.3.2 (Tab 8E/T1.112.1)

N-PCSTATE

Indication

UIT Q.711 § 6.3.2.3.3 (Tab 17/Q.711)
ANSI-T1.112 § 2.3.2.3.4 (Tab 8G/T1.112.1)

N-COORD

Confirmation de réponse à indication de demande

UIT Q.711 § 6.3.2.3.1 (Tab 15/Q.711)
ANSI-T1.112 § 2.3.2.3.3 (Tab 8F/T1.112.1)


1.6.2 Définition de la frontière inférieure

Les primitives de couche supérieure fournies par le SCTP sont données dans la [RFC2960].


1.6.3 Définition de la frontière entre SUA et la couche de gestion (LM, Layer Management)

Demande M-SCTP_ESTABLISH

Direction : LM -> SUA

Objet : La couche de gestion (LM) demande à l'ASP d'établir une association SCTP avec son homologue.


Confirmation M-SCTP_ESTABLISH

Direction : SUA -> LM

Objet : L'ASP confirme à la LM qu'il a établi une association SCTP avec son homologue.


Indication M-SCTP_ESTABLISH

Direction : SUA -> LM

Objet : La SUA informe la LM qu'un ASP distant a établi une association SCTP.


Demande M-SCTP_RELEASE

Direction : LM -> SUA

Objet : La LM demande à l'ASP de libérer une association SCTP avec son homologue.


Confirmation M-SCTP_RELEASE

Direction : SUA -> LM

Objet : Un ASP confirme à la LM qu'il a libéré une association SCTP avec son homologue.


Indication M-SCTP_RELEASE

Direction : SUA -> LM

Objet : La SUA informe la LM qu'un ASP distant a libéré une association SCTP ou que l'association SCTP a échoué.


Indication M-SCTP RESTART

Direction : SUA -> LM

Objet : La SUA informe la LM qu'une indication de redémarrage SCTP a été reçue.


Demande M-SCTP_STATUS

Direction : LM -> SUA

Objet : La LM demande à la SUA de faire rapport de l'état d'une association SCTP.


Confirmation M-SCTP_STATUS

Direction : SUA -> LM

Objet :La SUA répond par l'état d'une association SCTP.


Indication M-SCTP STATUS

Direction : SUA -> LM

Objet : La SUA fait rapport de l'état d'une association SCTP.


Demande M-ASP_STATUS

Direction : LM -> SUA

Objet : La LM demande à la SUA de faire rapport de l'état d'un ASP local ou distant.


Confirmation M-ASP_STATUS

Direction : SUA -> LM

Objet : La SUA fait rapport de l'état de l'ASP local ou distant.


Demande M-AS_STATUS

Direction : LM -> SUA

Objet : La LM demande à la SUA de faire rapport de l'état d'un AS.


Confirmation M-AS_STATUS

Direction : SUA -> LM

Objet : La SUA fait rapport de l'état d'un AS.


Indication M-NOTIFY

Direction : SUA -> LM

Objet :La SUA rapporte qu'elle a reçu un message Notify de son homologue.


Indication M-ERROR

Direction : SUA -> LM

Objet : La SUA rapporte qu'elle a reçu un message Erreur de son homologue ou qu'une opération locale a échoué.


Demande M-ASP_UP

Direction : LM -> SUA

Objet : La LM demande à l'ASP de commencer son fonctionnement et d'envoyer un message ASP UP à son homologue.


Confirmation M-ASP_UP

Direction : SUA -> LM

Objet : L'ASP rapporte qu'il a reçu un message d'accusé de réception de ASP UP de son homologue.


Indication M-ASP_UP

Direction : SUA -> LM

Objet : La SUA rapporte qu'elle a traité avec succès un message entrant ASP UP de son homologue.


Demande M-ASP_DOWN

Direction : LM -> SUA

Objet : La LM demande à l'ASP d'arrêter son fonctionnement et d'envoyer un message ASP Down à son homologue.


Confirmation M-ASP_DOWN

Direction : SUA -> LM

Objet : L'ASP rapporte qu'il a reçu un message d'accusé de réception de ASP Down de son homologue.


Indication M-ASP_DOWN

Direction : SUA -> LM

Objet : La SUA rapporte qu'elle a traité avec succès un message entrant ASP Down de son homologue, ou que l'association SCTP a été perdue/rétablie.


Demande M-ASP_ACTIVE

Direction : LM -> SUA

Objet : La LM demande à l'ASP d'envoyer un message ASP Active à son homologue.


Confirmation M-ASP_ACTIVE

Direction : SUA -> LM

Objet : L'ASP rapporte qu'elle a reçu un message d'accusé de réception de ASP Active de son homologue.


Indication M-ASP_ACTIVE

Direction : SUA -> LM

Objet : La SUA rapporte qu'elle a réussi à traiter un message entrant ASP Active de son homologue.


Demande M-ASP_INACTIVE

Direction : LM -> SUA

Objet : La LM demande à l'ASP d'envoyer un message ASP Inactive à son homologue.


Confirmation M-ASP_INACTIVE

Direction : LM -> SUA

Objet : L'ASP rapporte qu'il a reçu un message d'accusé de réception de ASP Inactive de son homologue.


Indication M-ASP_INACTIVE

Direction : SUA -> LM

Objet : La SUA rapporte qu'elle a traité avec succès un messages entrant ASP Inactive de son homologue.


Indication M-AS_ACTIVE

Direction : SUA -> LM

Objet : La SUA rapporte qu'un AS est passé à l'état AS-ACTIVE.


Indication M-AS_INACTIVE

Direction : SUA -> LM

Objet : La SUA rapporte qu'un AS est passé à l'état AS-INACTIVE.


Indication M-AS_DOWN

Direction : SUA -> LMObjet : La SUA rapporte qu'un AS est passé à l'état AS-DOWN.


Si la couche SUA supporte l'enregistrement dynamique de clé d'acheminement (RK, registration key), la couche PEUT prendre en charge les primitives supplémentaires suivantes :


Demande M-RK_REG

Direction : LM -> SUA

Objet : La LM demande à l'ASP d'enregistrer la ou les RK chez son homologue en envoyant un message REG REQ.


Confirmation M-RK_REG

Direction : SUA -> LM

Objet : L'ASP rapporte qu'il a reçu le message REG RSP avec l'état d'enregistrement réussi de son homologue.


Indication M-RK_REG

Direction : SUA -> LM

Objet : La SUA informe la LM qu'elle a traité avec succès un message REG REQ entrant.


Demande M-RK_DEREG

Direction : LM -> SUA

Objet : La LM demande à l'ASP de désenregistrer une ou des RK de son homologue en envoyant un message DEREG REQ.


Confirmation M-RK_DEREG

Direction : SUA -> LM

Objet : L'ASP rapporte qu'il a reçu un message DEREG RESP avec l'état de désenregistrement réussi de son homologue.


Indication M-RK_DEREG

Direction : SUA -> LM

Objet : La SUA informe la LM qu'elle a traité avec succès une DEREG REQ entrante provenant de son homologue.


2. Conventions


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


3. Éléments du protocole


Le format de message général inclut un en-tête de message commun avec une liste de zéro, un ou plusieurs paramètres, comme défini par le type de message.


Pour la compatibilité à l'avenir, tous les types de message peuvent avoir des paramètres rattachés même si aucun n'est spécifié dans la présente version.


Le champ Réservé est réglé à 0 dans les messages envoyés et n'est pas examiné dans les messages reçus.


3.1 En-tête commun de message

Les messages de protocole pour le protocole de couche d'adaptation d'utilisateur SCCP exigent une structure de message qui contient une version, une classe de message, un type de message, la longueur du message et le contenu du 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 du message |

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

| Données du message ~

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


Noter que la portion "données" des messages de SUA DEVRA contenir les données d'utilisateur SCCP, et non le message SCCP encapsulé.


Des paramètres facultatifs ne peuvent survenir qu'une seule fois dans un message de SUA.


3.1.1 Version du protocole SUA

Le champ Version contient la version de la couche d'adaptation SUA. Les versions acceptées sont :


1 : SUA version 1.0


3.1.2 Classes de message

0 : message de gestion de SUA (MGMT, Management)

1 : réservé

2 : message de gestion de signalisation de réseau (SNM, Signalling Network Management)

3 : message de gestion d'état d'ASP (ASPSM, ASP State Maintenance)

4 : message de maintenance de trafic d'ASP (ASPTM, ASP Traffic Maintenance)

5 : réservé

6 : réservé

7 : message sans connexion

8 : message en mode connexion

9 : message de gestion de clé d'acheminement (RKM, Registration Key Management).

10 - 127 : réservé par l'IETF

128 - 255 : réservé pour les extensions de classes de message définies par l'IETF.


3.1.3 Types de message

Messages de gestion SUA

0 : Erreur (ERR)

1 : Notification (NTFY)

2 – 127 : réservé par l'IETF

128- 255 : réservé pour les extensions de types de message définies par l'IETF.


Messages de gestion de signalisation du réseau (SNM, Signalling Network Management)

0 : réservé

1 : destination indisponible (DUNA, Destination Unavailable)

2 : destination disponible (DAVA, Destination Available)

3 : audit d'état de destination (DAUD, Destination State Audit)

4 : encombrement de signalisation (SCON, Signalling Congestion)

5 : sous système utilisateur de destination indisponible (DUPU, Destination User Part Unavailable)

6 : destination interdite (DRST, Destination Restricted)

7 – 127 : réservé par l'IETF

128 – 255 : réservé pour les extensions de types de message définies par l'IETF.


Messages de maintenance d'état de processus de serveur d'application (ASPSM, ASP State Maintenance

0 : réservé

1 : ASP Up (UP) : ASP actif

2 : ASP Down (DOWN) : ASP arrêté

3 : Heartbeat (BEAT) : battement de cœur

4 : ASP Up Ack (UP ACK) : accusé de réception de ASP actif

5 : ASP Down Ack (DOWN ACK) : accusé de réception de ASP arrêté

6 : Heartbeat Ack (BEAT ACK) : accusé de réception de battement de cœur

7 - 127 : réservé par l'IETF

128 - 255 : réservé pour les extensions de types de message définies par l'IETF.


Messages maintenance de trafic d'ASP (ASPTM, ASP Traffic Maintenance)

0 : réservé

1 : ASP Active (ACTIVE) : ASP actif

2 : ASP Inactive (INACTIVE) : ASP inactif

3 : ASP Active Ack (ACTIVE ACK) : accusé de réception d'ASP actif

4 : ASP Inactive Ack (INACTIVE ACK) : accusé de réception d'ASP inactif

5 - 127 : réservé par l'IETF

128 - 255 : réservé pour les extensions de types de message définies par l'IETF.


Messages de gestion de clé d'acheminement (RKM, Registration Key Management)

0 : réservé

1 : Registration Request (REG REQ) : demande d'enregistrement

2 : Registration Response (REG RSP) : réponse d'enregistrement

3 : Deregistration Request (DEREG REQ) : demande de désenregistrement

4 : Deregistration Response (DEREG RSP) : réponse de désenregistrement

5 - 127 : réservé par l'IETF

128 - 255 : réservé pour les extensions de types de message définies par l'IETF.


Messages sans connexion (CL, Connectionless)

0 : réservé

1 : transfert de données sans connexion (CLDT, Connectionless Data Transfer)

2 : réponse de données sans connexion (CLDR, Connectionless Data Response)

3 - 127 : réservé par l'IETF

128 - 255 : réservé pour les extensions de types de message définies par l'IETF.


Messages en mode connexion (CO, Connection-Oriented)

0 : réservé

1 : demande de connexion (CORE, Connection Request)

2 : accusé de réception de connexion (COAK, Connection Acknowledge)

3 : connexion refusée (COREF, Connection Refused)

4 : demande de libération (RELRE, Release Request)

5 : libération achevée (RELCO, Release Complete)

6 : confirmation de rétablissement (RESCO, Reset Confirm)

7 : demande de rétablissement (RESRE, Reset Request)

8 : transfert de données en mode connexion (CODT, Connection Oriented Data Transfer)

9 : accusé de réception de données en mode connexion (CODA, Connection Oriented Data Acknowledge)

10 : erreur en mode connexion (COERR, Connection Oriented Error)

11 :essai d'inactivité (COIT, Inactivity Test)

12 - 127 : réservé par l'IETF

128 - 255 : réservé pour les extensions de types de message définies par l'IETF.


3.1.4 Longueur de message

La longueur de message définit la longueur du message en octets, incluant l'en-tête et incluant tous les octets de bourrage. Longueur de message est un identifiant de 32 bits.


3.1.5 Format de TLV

Les messages de SUA consistent en un en-tête commun suivi par zéro, un ou plusieurs paramètres, comme défini par le type de message. Les paramètres Étiquette-Longueur-Valeur (TLV, Tag-Lengthe-Value) contenus dans un message sont définis dans le 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 /

\ \

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


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

Le champ Étiquette est un identifiant de 16 bits du type de paramètre. Il prend une valeur de 0 à 65 535.


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. Longueur de paramètre n'inclut aucun octet de bourrage. Cependant, des paramètres composites vont contenir tous les octets de bourrage, car tous les paramètres contenus dans ce paramètre composite seront considérés comme des multiples de 4 octets.


Valeur de paramètre : longueur variable.

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


Note de mise en œuvre : en principe l'utilisation de TLV permet de placer les paramètres dans un ordre aléatoire dans le message. Cependant, ces directives devraient être prises en considération pour faciliter le traitement dans l'ordre suivant :

- les paramètres nécessaires pour traiter correctement les paramètres d'autres messages, devraient de préférence précéder ces paramètres (comme Contexte d'acheminement) ;

- les paramètres obligatoires DEVRAIENT de préférence précéder tout paramètre facultatif ;

- les paramètres de données vont normalement être ceux de la fin du message ;

- le receveur DEVRAIT accepter les paramètres dans tout ordre, sauf lorsque il est explicitement obligatoire.


3.2 Messages SUA sans connexion

Ce paragraphe décrit le transfert sans connexion à la SUA de contenus de messages et de paramètres. Le format de message général inclut un en-tête de message commun ainsi qu'une liste de zéro, un ou plusieurs paramètres comme défini par le type de message. Tous les types de messages peuvent avoir des paramètres rattachés.


3.2.1 Transfert de données sans connexion (CLDT)

Ce message transfère les données entre une SUA et une autre .


0 1 2 3

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

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0115 | Longueur |

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

| Classe de protocole |

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

| Étiquette = 0x0102 | Longueur |

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

/ Adresse de source /

\ \

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

| Étiquette = 0x0103 | Longueur |

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

/ Adresse de destination /

\ \

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

| Étiquette = 0x0116 | Longueur |

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

| Contrôle de séquence |

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

| Étiquette = 0x0101 | Longueur |

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

| Compte de bonds SS7 |

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

| Étiquette = 0x0113 | Longueur |

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

| Importance |

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

| Étiquette = 0x0114 | Longueur |

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

| Priorité du message |

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

| Étiquette = 0x0013 | Longueur |

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

| Identifiant de corrélation |

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

| Étiquette = 0x0117 | Longueur |

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

| Segmentation |

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

| Étiquette = 0x010B | Longueur |

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

/ Données /

\ \

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


Paramètres

Contexte d'acheminement : Obligatoire

Classe de protocole : Obligatoire

Adresse de source : Obligatoire

Adresse de destination : Obligatoire

Contrôle de séquence : Obligatoire

Compte de bonds SS7 : Facultatif

Importance : Facultatif

Priorité de message : Facultatif

Identifiant de corrélation : Facultatif

Segmentation : Facultatif

Données : Obligatoire


Note de mise en œuvre : ce message couvre les messages SCCP suivants : données d'unités (UDT, unitdata), données d'unités étendues (XUDT, extended unitdata), unités de données longues (LUDT, long unitdata).


3.2.2 Réponse de données sans connexion (CLDR)

Ce message est utilisé comme message de réponse de l'homologue pour faire rapport d'erreurs dans le message CLDT reçu, lorsque l'option retour sur erreur est établie.


0 1 2 3

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

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0106 | Longueur |

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

| Cause SCCP |

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

| Étiquette = 0x0102 | Longueur |

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

/ Adresse de source /

\ \

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

| Étiquette = 0x0103 | Longueur |

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

/ Adresse de destination /

\ \

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

| Étiquette = 0x0101 | Longueur |

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

| Compte de bonds SS7 |

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

| Étiquette = 0x0113 | Longueur |

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

| Importance |

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

| Étiquette = 0x0114 | Longueur |

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

| Priorité de message |

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

| Étiquette = 0x0013 | Longueur |

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

| Identifiant de corrélation |

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

| Étiquette = 0x0117 | Longueur |

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

| Segmentation |

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

| Étiquette = 0x010b | Longueur |

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

/ Données /

\ \

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


Paramètres

Contexte d'acheminement : Obligatoire

Cause SCCP : Obligatoire

Adresse de source : Obligatoire

Adresse de destination : Obligatoire

Compte de bonds SS7 : Facultatif

Importance : Facultatif

Priorité de message : Facultatif

Identifiant de corrélation : Facultatif

Segmentation : Facultatif

Données : Facultatif


Note de mise en œuvre : ce message couvre les messages SCCP suivants : service de données d'unités (UDTS, unitdata service), service d'unités de données étendu (XUDTS) et service d'unités de données longues (LUDTS).


3.3 Messages en mode connexion

3.3.1 Transfert de données en mode connexion (CODT)

Ce message transfère les données entre une SUA et une autre pour le service en mode connexion.


0 1 2 3

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

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0107 | Longueur |

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

| Numéro de séquence |

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

| Étiquette = 0x0105 | Longueur |

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

| Numéro de référence de destination |

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

| Étiquette = 0x0114 | Longueur |

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

| Priorité de message |

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

| Étiquette = 0x0013 | Longueur |

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

| Identifiant de corrélation |

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

| Étiquette = 0x010b | Longueur |

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

/ Données /

\ \

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


Paramètres

Contexte d'acheminement : Obligatoire

Numéro de séquence : Facultatif (note)

Numéro de référence de destination : Obligatoire

Priorité de message : Facultatif

Identifiant de corrélation : Facultatif

Données : Obligatoire


Note : ce paramètre n'est pas présent en cas de données expédiées (ED, expedited data).


Note de mise en œuvre : pour que le CODT représente les messages DT1, DT2 et ED, les conditions suivantes DOIVENT être satisfaites :

DT1 est représenté par un CODT quand le paramètre Numéro de séquence est présent (contient l'indicateur "more").

DT2 est représenté par un CODT quand le paramètre Numéro de séquence est présent (contient P(S), P(R) et l'indicateur "more").

ED est représenté par un CODT avec le paramètre Numéro de séquence non présent.


3.3.2 Accusé de réception de données en mode connexion (CODA)

L'homologue utilise ce message pour accuser réception des données. Ce message n'est utilisé qu'avec la classe de protocole 3.


0 1 2 3

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

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0105 | Longueur |

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

| Numéro de référence de destination |

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

| Étiquette = 0x0108 | Longueur |

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

| Numéro de séquence reçu |

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

| Étiquette = 0x010A | Longueur |

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

| Crédit |

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


Paramètres

Contexte d'acheminement : Obligatoire

Numéro de référence de destination : Obligatoire

Numéro de séquence reçu : Facultatif (note)

Crédit : Obligatoire (note)


Note : obligatoire quand il représente un accusé de réception de données (AK).


Note de mise en œuvre : pour que CODA représente les messages DA et EA, les conditions suivantes DOIVENT être remplies:

DA est représenté par un CODA lorsque le paramètre Numéro de séquence reçu est présent (contient P(S), P(R) et l'indicateur "more").

EA est représenté par un CODA lorsque le paramètre Numéro de séquence reçu n'est pas présent.


3.3.3 Demande de connexion (CORE)

Ce message est utilisé pour établir une connexion de signalisation entre deux points d'extrémité homologues.


0 1 2 3

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

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0115 | Longueur |

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

| Classe de protocole |

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

| Étiquette = 0x0104 | Longueur |

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

| Numéro de référence de source |

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

| Étiquette = 0x0103 | Longueur |

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

/ Adresse de destination /

\ \

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

| Étiquette = 0x0116 | Longueur |

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

| Contrôle de séquence |

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

| Étiquette = 0x0107 | Longueur |

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

| Numéro de séquence |

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

| Étiquette = 0x0102 | Longueur |

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

/ Adresse de source /

\ \

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

| Étiquette = 0x0101 | Longueur |

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

| Compte de bonds SS7 |

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

| Étiquette = 0x0113 | Longueur |

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

| Importance |

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

| Étiquette = 0x0114 | Longueur |

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

| Priorité de message |

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

| Étiquette = 0x010A | Longueur |

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

| Crédit |

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

| Étiquette = 0x010b | Longueur |

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

/ Données /

\ \

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


Paramètres

Contexte d'acheminement : Obligatoire

Classe de protocole : Obligatoire

Numéro de référence de source : Obligatoire

Adresse de destination : Obligatoire

Contrôle de séquence : Obligatoire

Numéro de séquence : Facultatif (note)

Adresse de source : Facultatif

Compte de bonds SS7 : Facultatif

Importance : Facultatif

Priorité de message : Facultatif

Crédit : Facultatif (note)

Données : Facultatif


Note : Obligatoire seulement pour la classe 3 de protocole.


Note de mise en œuvre : ce message couvre le message SCCP Demande de connexion (CR).


3.3.4 Accusé de réception de connexion (COAK)

Ce message est utilisé pour accuser réception d'une demande de connexion provenant du point d'extrémité homologue.


0 1 2 3

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

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0115 | Longueur |

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

| Classe de protocole |

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

| Étiquette = 0x0105 | Longueur |

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

| Numéro de référence de destination |

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

| Étiquette = 0x0104 | Longueur |

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

| Numéro de référence de source |

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

| Étiquette = 0x01116 | Longueur |

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

| Contrôle de séquence |

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

| Étiquette = 0x010A | Longueur |

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

| Crédit |

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

| Étiquette = 0x0102 | Longueur |

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

/ Adresse de source /

\ \

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

| Étiquette = 0x0113 | Longueur |

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

| Importance |

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

| Étiquette = 0x0114 | Longueur |

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

| Priorité de message |

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

| Étiquette = 0x0103 | Longueur |

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

/ Adresse de destination /

\ \

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

| Étiquette = 0x010b | Longueur |

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

/ Données /

\ \

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


Paramètres

Contexte d'acheminement : Obligatoire

Classe de protocole : Obligatoire

Numéro de référence de destination : Obligatoire

Numéro de référence de source : Obligatoire

Contrôle de séquence : Obligatoire

Crédit : Obligatoire (note 2)

Adresse de source : Facultatif

Importance : Facultatif

Priorité de message : Facultatif

Adresse de destination : Facultatif (note 1)

Données : Facultatif


Note 1 : le paramètre Adresse de destination sera présent quand le message CORE reçu porte le paramètre Adresse de source.


Note 2 : n'est applicable que pour la classe 3 de protocole.


Note de mise en œuvre : ce message couvre le message SCCP Confirmation de connexion (CC).


3.3.5 Connexion refusée (COREF)

Ce message est utilisé pour refuser une demande de connexion entre deux points d'extrémité homologues.


0 1 2 3

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

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0105 | Longueur |

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

| Numéro de référence de destination |

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

| Étiquette = 0x0106 | Longueur |

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

| Cause SCCP |

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

| Étiquette = 0x0102 | Longueur |

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

/ Adresse de source /

\ \

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

| Étiquette = 0x0103 | Longueur |

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

/ Adresse de destination /

\ \

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

| Étiquette = 0x0113 | Longueur = 8 |

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

| Importance |

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

| Étiquette = 0x010B | Longueur |

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

/ Données /

\ \

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


Paramètres

Contexte d'acheminement : Obligatoire

Numéro de référence de destination : Obligatoire

Cause SCCP : Obligatoire

Adresse de source : Facultatif

Adresse de destination : Facultatif (note)

Importance : Facultatif

Données : Facultatif


Note : le paramètre Adresse de destination sera présent si le message CORE reçu porte le paramètre Adresse de source.


Note de mise en œuvre : ce message couvre le message SCCP Connexion refusée (CREF, Connection REFused).


3.3.6 Demande de libération (RELRE, Release Request)

Ce message est utilisé pour demander qu'une connexion de signalisation entre deux points d'extrémité homologues soit libérée. Toutes les ressources associées peuvent alors être libéré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 = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0105 | Longueur |

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

| Numéro de référence de destination |

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

| Étiquette = 0x0104 | Longueur |

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

| Numéro de référence de source |

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

| Étiquette = 0x0106 | Longueur |

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

| Cause SCCP |

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

| Étiquette = 0x0113 | Longueur = 8 |

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

| Importance |

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

| Étiquette = 0x010b | Longueur |

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

/ Données /

\ \

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


Paramètres

Contexte d'acheminement : Obligatoire

Numéro de référence de destination : Obligatoire

Numéro de référence de source : Obligatoire

Cause SCCP : Obligatoire

Importance : Facultatif

Données : Facultatif

Note de mise en œuvre : ce message couvre le message SCCP Connexion libérée (RLSD, connection ReLeaSeD).


3.3.7 Libération achevée (RELCO, Release Complete)

Ce message est utilisé pour accuser réception de la libération d'une connexion de signalisation entre deux points d'extrémité homologues. Toutes les ressources associées devraient être libéré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 = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0105 | Longueur |

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

| Numéro de référence de destination |

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

| Étiquette = 0x0104 | Longueur |

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

| Numéro de référence de source |

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

| Étiquette = 0x0113 | Longueur = 8 |

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

| Importance |

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


Paramètres

Contexte d'acheminement : Obligatoire

Numéro de référence de destination : Obligatoire

Numéro de référence de source : Obligatoire

Importance : Facultatif


Note de mise en œuvre : ce message couvre le message SCCP Libération achevée (RLC, ReLease Complete).


3.3.8 Demande de rétablissement (RESRE, Reset Request)

Ce message est utilisé pour indiquer que le SCCP/SUA envoyeur veut initier une procédure de rétablissement (réinitialisation des numéros de séquence) chez le point d'extrémité homologue.


0 1 2 3

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

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0105 | Longueur |

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

| Numéro de référence de destination |

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

| Étiquette = 0x0104 | Longueur |

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

| Numéro de référence de source |

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

| Étiquette = 0x0106 | Longueur |

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

| Cause SCCP |

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


Paramètres

Contexte d'acheminement : Obligatoire

Numéro de référence de destination : Obligatoire

Numéro de référence de source : Obligatoire

Cause SCCP : Obligatoire


Note de mise en œuvre : ce message couvre le message SCCP Demande de rétablissement (RSR, ReSet Request).


3.3.9 Confirmation de rétablissement (RESCO, Reset Confirm)

Ce message est utilisé pour confirmer la demande de rétablissement.


0 1 2 3

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

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0105 | Longueur |

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

| Numéro de référence de destination |

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

| Étiquette = 0x0104 | Longueur |

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

| Numéro de référence de source |

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


Paramètres

Contexte d'acheminement : Obligatoire

Numéro de référence de destination : Obligatoire

Numéro de référence de source : Obligatoire


Note de mise en œuvre : ce message couvre le message SCCP Confirmation de rétablissement (RSC, ReSet Confirmation).


3.3.10 Erreur en mode connexion (COERR, Connection Oriented Error)

Le message COERR est envoyé pour indiquer une erreur d'unités de données de protocole.


0 1 2 3

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

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0105 | Longueur |

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

| Numéro de référence de destination |

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

| Étiquette = 0x0106 | Longueur |

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

| Cause SCCP |

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


Paramètres

Contexte d'acheminement : Obligatoire

Numéro de référence de destination : Obligatoire

Cause SCCP : Obligatoire


Note de mise en œuvre : ce message couvre le message SCCP Erreur d'unité de données de protocole (ERR, Protocol Data Unit ERRor).


3.3.11 Essai d'inactivité en mode connexion (COIT, Connection Oriented Inactivity Test)

Ce message est utilisé pour examiner l'état de la connexion de signalisation et la cohérence des données de connexion aux deux extrémités de la connexion 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

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0115 | Longueur |

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

| Classe de protocole |

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

| Étiquette = 0x0104 | Longueur |

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

| Numéro de référence de source |

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

| Étiquette = 0x0105 | Longueur |

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

| Numéro de référence de destination |

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

| Étiquette = 0x0107 | Longueur |

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

| Numéro de séquence |

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

| Étiquette = 0x010A | Longueur |

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

| Crédit |

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


Paramètres

Contexte d'acheminement : Obligatoire

Classe de protocole : Obligatoire

Numéro de référence de source : Obligatoire

Numéro de référence de destination : Obligatoire

Numéro de séquence : Obligatoire (note)

Crédit : Obligatoire (note)


Note : les informations de ces champs de paramètres reflètent les valeurs envoyées dans le dernier formulaire de données 2 ou message d'accusé de réception de données. Elles sont ignorées si la classe de protocole indique la classe 2.


Note de mise en œuvre : ce message couvre le message SCCP Essai d'inactivité (IT, Inactivity Test).


3.4 Messages de gestion de réseau de signalisation (SNM, Signalling Network Management)

3.4.1 Destination indisponible (DUNA, Destination Unavailable)

Dans le domaine SUA, ce message est couvert par l'indication d'état PC- ou N passée entre SCCP et l'utilisateur SCCP local. Le message DUNA est envoyé de la SG ou du nœud relais à tous les ASP concernés (desservant des utilisateurs SCCP considérés comme locaux par la SG ou le nœud relais, voir le paragraphe 1.3.1.1) lorsque une destination ou un utilisateur SCCP est devenu injoignable. L'usager SUA à l'ASP est supposé arrêter le trafic pour la destination ou l'utilisateur SCCP affecté à travers la SG ou le nœud relais qui a initié le DUNA.


Le format des paramètres du message DUNA 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 = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0012 | Longueur |

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

/ Codet affecté /

\ \

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

| Étiquette = 0x8003 | Longueur |

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

| SSN |

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

| Étiquette = 0x0112 | Longueur |

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

| SMI |

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

| Étiquette = 0x0004 | Longueur |

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

/ Chaîne d'informations /

\ \

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


Paramètres

Contexte d'acheminement : Facultatif

Codet affecté : Obligatoire (note)

SSN : Facultatif (note)

SMI : Facultatif

Chaîne d'informations : Facultatif


Note : Lorsque le SSN est inclus, le message DUNA correspond à la primitive SCCP N-STATE. Lorsque SSN ne l'est pas, le message DUNA correspond à la primitive SCCP N-PCSTATE. Le paramètre Codet affecté ne peut contenir qu'un seul codet quand SSN est présent.


3.4.2 Destination disponible (DAVA, Destination Available)

Dans l'esprit de SUA, ce message est couvert par indication d'état PC et N passée entre SCCP et l'utilisateur local SCCP. Le message DAVA est envoyé de la SG ou du nœud relais à tous les ASP concernés (qui desservent des utilisateurs SCCP considérés comme locaux pour la SG ou le nœud relais, voir le paragraphe 1.3.1.1) pour indiquer qu'une destination (PC ou utilisateur SCCP) est maintenant joignable. On attend du protocole SUA-Usager d'ASP qu'il reprenne le trafic vers la destination affectée à travers la SG ou nœud relais qui a initié le message DAVA.


0 1 2 3

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

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0012 | Longueur |

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

/ Codet affecte /

\ \

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

| Étiquette = 0x8003 | Longueur |

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

| SSN |

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

| Étiquette = 0x0112 | Longueur |

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

| SMI |

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

| Étiquette = 0x0004 | Longueur |

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

/ Chaîne d'informations /

\ \

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


Paramètres

Contexte d'acheminement : Facultatif

Codet affecté : Obligatoire (note)

SSN : Facultatif (note)

SMI : Facultatif

Chaîne d'informations : Facultatif


Note : lorsque SSN est inclus, le message DAVA correspond à la primitive SCCP N-STATE. Lorsque SSN n'est pas inclus, le message DAVA correspond à la primitive SCCP N-PCSTATE. Le codet affecté ne peut contenir qu'un seul codet lorsque SSN est présent.


3.4.3 Examen d'état de destination (DAUD, Destination State Audit)


Le message DAUD peut être envoyé de l'ASP à la SG (ou nœud relais) pour interroger l'état de disponibilité des chemins pour une certaine destination. Un DAUD peut être envoyé périodiquement après que l'ASP a reçu un DUNA, jusqu'à ce qu'un DAVA soit reçu. Le DAUD peut aussi être envoyé lorsque un ASP récupère de son isolation de la SG (ou nœud relais).




0 1 2 3

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

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0012 | Longueur |

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

/ Codet affecté /

\ \

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

| Étiquette = 0x8003 | Longueur |

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

| SSN |

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

| Étiquette = 0x010C | Longueur |

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

| Usager / Cause |

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

| Étiquette = 0x0004 | Longueur |

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

/ Chaîne d'informations /

\ \

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


Paramètres

Contexte d'acheminement : Facultatif

Codet affecté : Obligatoire (note)

SSN : Facultatif (note)

Usager / Cause : Facultatif

Chaîne d'informations : Facultatif


Note : si le SSN est présent, le DAUD "sollicite" des primitives N-STATE, autrement , il "sollicite" des primitives N-PCSTATE.


3.4.4 Encombrement de signalisation (SCON, Signalling Congestion)

Le message SCON peut être envoyé de la SG ou nœud relais à tous les ASP concernés pour indiquer que le niveau d'encombrement dans le réseau SS7 a changé pour une destination spécifiée.


0 1 2 3

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

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0012 | Longueur |

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

/ Codet affecté /

\ \

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

| Étiquette = 0x8003 | Longueur |

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

| SSN |

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

| Étiquette = 0x0118 | Longueur |

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

| Niveau d'encombrement |

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

| Étiquette = 0x0112 | Longueur |

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

| SMI |

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

| Étiquette = 0x0004 | Longueur |

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

/ Chaîne d'informations /

\ \

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


Paramètres

Contexte d'acheminement : Facultatif

Codet affecté : Obligatoire (note)

SSN : Facultatif (note)

Niveau d'encombrement : Obligatoire

SMI : Facultatif

Chaîne d'informations : Facultatif


Note : Lorsque le SSN est inclus, le message SCON correspond à la primitive SCCP N-STATE. Lorsque le SSN n'est pas inclus, le message SCON correspond à la primitive SCCP N-PCSTATE qui fait rapport de l'état d'encombrement d'un point de signalisation ou d'un réseau.


3.4.5 Sous système utilisateur de destination indisponible (DUPU, Destination User Part Unavailable)

Le message DUPU est utilisé par une SG pour informer un ASP qu'un homologue distant à un nœud SS7 est indisponible.


Le format des paramètres du message DUPU 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 = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0012 | Longueur |

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

/ Codet affecté /

\ \

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

| Étiquette = 0x010C | Longueur |

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

| Usager / Cause |

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

| Étiquette = 0x0004 | Longueur |

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

\ \

/ Chaîne d'informations /

\ \

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


Paramètres

Contexte d'acheminement : Facultatif

Codet affecté : Obligatoire (note)

Usager/Cause : Obligatoire

Chaîne d'informations : Facultatif


Note : le message DUPU correspond à la primitive SCCP N-PCSTATE.


3.4.6 Destination interdite (DRST, Destination Restricted)

Le message DRST est facultativement envoyé de la SG à tous les ASP concernés pour indiquer que la SG a déterminé qu'une ou plusieurs destinations sont maintenant interdites du point de vue de la SG, ou en réponse à un message DAUD si approprié. On attend de la couche SUA à l'ASP qu'elle envoie du trafic à la destination affectée via une SG de remplacement de priorité égale, mais seulement si ce chemin de remplacement existe et est disponible. Si l'ASP considère actuellement la destination affectée comme indisponible, l'homologue devrait être informé que le trafic pour la destination affectée pourrait reprendre. Dans ce cas, la couche SUA devrait acheminer le trafic par la SG qui a initié le message DRST.


L'envoi de ce message est facultatif pour la SG et c'est une option de l'ASP d'agir sur des informations reçues dans le message.


0 1 2 3

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

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0012 | Longueur |

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

/ Codet affecté /

\ \

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

| Étiquette = 0x8003 | Longueur |

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

| SSN |

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

| Étiquette = 0x0112 | Longueur = 8 |

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

| Réservé | SMI |

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

| Étiquette = 0x0004 | Longueur |

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

/ Chaîne d'informations /

\ \

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


Paramètres

Contexte d'acheminement : Facultatif

Codet affecté : Obligatoire (note)

SSN : Facultatif (note)

SMI : Facultatif (note)

Chaîne d'informations : Facultatif


Note : Codet affecté se réfère au nœud qui devient interdit ou qui a demandé la mise en panne du service coordonné. Lorsque SSN est inclus dans le paramètre de message, le message DRST correspond à la primitive SCCP N-COORD. Si le paramètre SMI est aussi inclus dans le message, le message DRST correspond aux primitives Demande N-COORD et Indication N-COORD, autrement, le message DRST correspond aux primitives Réponse N-COORD et Confirmation N-COORD. Le Codet affecté ne peut contenir qu'un seul codet lorsque SSN est présent. Lorsque SSN n'est pas présent, DRST correspond à la primitive N-PCSTATE.


3.5 Messages de maintenance d'état de processus de serveur d'application

3.5.1 ASP ouvert (UP, ASP Up)

Le message ASP UP (UP) est utilisé pour indiquer à un homologue SUA distant que la couche Adaptation est ouverte et active.


0 1 2 3

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

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

| Étiquette = 0x0011 | Longueur |

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

| Identifiant d'ASP |

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

| Étiquette = 0x0004 | Longueur |

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

/ Chaîne d'informations /

\ \

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


Paramètres

Identifiant d'ASDP : Facultatif (note)

Chaîne d'informations : Facultatif


Note : l'identifiant d'ASP DOIT être utilisé lorsque le IPSP/SGP ne peut pas identifier l'ASP en provisionnant des informations d'adresse/numéro d'accès (par exemple, lorsque un ASP réside sur un hôte qui utilise l'allocation dynamique d'adresse/numéro d'accès).


3.5.2 Accusé de réception d'ASP ouvert (UP ACK, ASP Up Ack)

Le message ASP UP Ack est utilisé pour accuser réception d'un message ASP-Up reçu d'un homologue SUA distant.


0 1 2 3

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

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

| Étiquette = 0x0004 | Longueur |

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

/ Chaîne d'informations /

\ \

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


Paramètres

Chaîne d'informations : Facultatif


3.5.3 ASP fermé (DOWN, ASP Down)

Le message ASP Down (DOWN) est utilisé pour indiquer à un homologue SUA distant que la couche Adaptation ne fonctionne pas.


0 1 2 3

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

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

| Étiquette = 0x0004 | Longueur |

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

/ Chaîne d'informations /

\ \

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


Paramètres

Chaîne d'informations : Facultatif


3.5.4 Accusé de réception d'ASP fermé (DOWN ACK, ASP Down Ack)

Le message ASP DOWN Ack est utilisé pour accuser réception d'un message ASP-Down reçu d'un homologue SUA distant.


0 1 2 3

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

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

| Étiquette = 0x0004 | Longueur |

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

/ Chaîne d'informations /

\ \

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


Paramètres

Chaîne d'informations : Facultatif


Note : ASP DOWN ACK sera toujours envoyé pour accuser réception d'un ASP DOWN.


3.5.5 Battement de cœur (BEAT, Heartbeat)

Le message Heartbeat est utilisé facultativement pour s'assurer que les homologues SUA sont toujours disponibles les uns pour les autres.


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 de battement de cœur /

\ \

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


Paramètres

Données de battement de cœur : Facultatif


3.5.6 Accusé de réception de battement de cœur (BEAT ACK, Heartbeat Ack)

Le message Heartbeat ACK 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 Heartbeat reçu, sans aucun changement.


Le format du message BEAT ACK 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 battement de cœur /

\ \

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


Paramètres

Données de battement de cœur : Facultatif


3.6 Messages de maintenance de trafic d'ASP

3.6.1 ASP actif (ACTIVE, ASP Active, ASPAC)

Le message ASPAC est envoyé par un ASP pour indiquer à un homologue SUA distant qu'il est actif et prêt à traiter le trafic de signalisation pour un serveur d'application particulier.


Le format du message ACTIVE 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 = 0x000B | Longueur |

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

| Type de mode de trafic |

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0110 | Longueur |

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

| Étiquette d'identifiant de trafic (TID) |

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

| Étiquette = 0x010F | Longueur |

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

| Étiquette DRN |

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

| Étiquette = 0x0004 | Longueur |

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

/ Chaîne d'informations /

\ \

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


Paramètres

Type de mode de trafic : Facultatif

Contexte d'acheminement : Facultatif

Étiquette TID : Facultatif

Étiquette DRN : Facultatif

Chaîne d'informations : Facultatif


3.6.2 Accusé de réception d'ASP actif (ACTIVE ACK, ASP Active Ack)

Le message ASPAC Ack est utilisé pour accuser réception d'un message ASP-Active reçu d'un homologue SUA distant.


Le format du message ACTIVE Ack 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 = 0x000B | Longueur |

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

| Type de mode de trafic |

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0004 | Longueur |

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

/ Chaîne d'informations /

\ \

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


Paramètres

Type de mode de trafic : Facultatif

Contexte d'acheminement : Obligatoire

Chaîne d'informations : Facultatif


3.6.3 ASP inactif (INACTIVE, ASP Inactive, ASPIA )

Le message INACTIVE est envoyé par un ASP pour indiquer à un homologue SUA distant qu'il ne traite plus de trafic de signalisation avec un serveur d'application particulier


Le format des paramètres du message 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 = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0004 | Longueur |

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

/ Chaîne d'informations /

\ \

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


Paramètres

Contexte d'acheminement :Facultatif

Chaîne d'informations : Facultatif


3.6.4 Accusé de réception d'ASP inactif (INACTIVE ACK, ASP Inactive Ack)

Le message INACTIVE Ack est utilisé pour accuser réception d'un message ASP-Inactive reçu d'un homologue SUA distant.


Le format du message INACTIVE Ack 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 = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0004 | Longueur |

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

/ Chaîne d'informations /

\ \

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


Paramètres

Contexte d'acheminement : Facultatif

Chaîne d'informations : Facultatif


3.7 Messages de gestion de SUA

Ces messages sont utilisés pour gérer la SUA et les représentations des sous systèmes SCCP dans la couche SUA.


3.7.1 Erreur (ERR)

Le message ERR est envoyé entre deux homologues de SUA pour indiquer une situation d'erreur. Le paramètre Informations de diagnostic est facultatif, éventuellement utilisé pour des erreur de connexion et/ou le débogage.


0 1 2 3

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

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

| Étiquette = 0x000C | Longueur |

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

| Code d'erreur |

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0012 | Longueur |

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

| Gabarit | Codet affecté 1 |

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

/ ... /

\ \

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

| Gabarit | Codet affecté n |

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

| Étiquette = 0x010D | Longueur = 8 |

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

| Apparence du réseau |

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

| Étiquette = 0x0007 | Longueur |

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

/ Informations de diagnostic /

\ \

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


Paramètres

Code d'erreur : Obligatoire

Contexte d'acheminement : Obligatoire (note)

Apparence du réseau : Obligatoire (note)

Codet affecté : Obligatoire (note)

Informations de diagnostic : Facultatif


Note : Obligatoire seulement pour des codes d'erreur spécifiques.


3.7.2 Notification (NTFY, Notify)

Le message Notify est utilisé pour donner une indication autonome d'événements de SUA à un homologue de SUA.


0 1 2 3

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

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

| Étiquette = 0x000D | Longueur |

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

| État |

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

| Étiquette = 0x0011 | Longueur |

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

| Identifiant d'ASP |

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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

| Étiquette = 0x0004 | Longueur |

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

/ Chaîne d'informations /

\ \

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


Le message NTFY contient les paramètres suivants :


Paramètres

État : Obligatoire

Identifiant d'ASP : Facultatif (note)

Contexte d'acheminement : Facultatif

Chaîne d'informations : Facultatif


Note : l'identifiant d'ASP DOIT être utilisé lorsque le IPSP/SGP ne peut pas identifier l'ASP par des informations d'adresse/numéro d'accès provisionnées (par exemple, lorsque un ASP réside sur un hôte qui utilise l'allocation dynamique d'adresse/numéro d'accès).


3.8 Messages de gestion de clé d'acheminement (RKM, Routing Key Management)

3.8.1 Demande d'enregistrement (REG REQ, Registration Request)

Le message REG REQ est envoyé par un ASP pour indiquer à un homologue SUA distant qu'il souhaite enregistrer une ou plusieurs clés d'acheminements auprès de l'homologue distant. Normalement, un ASP va envoyer ce message à un SGP, et s'attend à recevoir un message REG RSP en retour avec une valeur associée de contexte d'acheminement.


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 = 0x010E | Longueur |

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

/ clé d'acheminement 1 /

\ \

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

/ ... /

\ \

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

| Étiquette = 0x010E | Longueur |

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

/ clé d'acheminement n /

\ \

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

| Étiquette = 0x0109 | Longueur |

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

| Capacités d'ASP |

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


Le message REG REQ contient les paramètres suivants :


Paramètres

Clé d'acheminement : Obligatoire (note)

Capacités d'ASP : Facultatif


Note : un ou plusieurs paramètres de clé d'acheminement supplémentaires PEUVENT être inclus dans un seul message REG REQ.


3.8.2 Réponse d'enregistrement (REG RSP, Registration Response)

Le message REG RSP envoyé par une SG à un ASP indique le résultat d'un REG REQ précédent d'un ASP. Il contient les indications de réussite/échec des demandes d'enregistrement et retourne une unique valeur de contexte d'acheminement pour les demandes d'enregistrement réussies, à utiliser dans les messages suivants du protocole de gestion de trafic de SUA.


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 = 0x0014 | Longueur |

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

| Résultat d'enregistrement 1 |

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

/ ... /

\ \

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

| Étiquette = 0x0014 | Longueur |

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

| Résultat d'enregistrement n |

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


Le message REG RSP contient les paramètres suivants :


Paramètres

Résultat d'enregistrement : Obligatoire (note)


Note : un ou plusieurs paramètres Résultat d'enregistrement PEUVENT être inclus dans un seul message REG RSP. Le nombre de résultats dans un seul message REG RSP peut être entre un et le nombre total de paramètres de clé d'acheminement trouvé dans le message REG REQ correspondant.


3.8.3 Demande de désenregistrement (DEREG REQ, Deregistration Request)

Le message DEREG REQ est envoyé par un ASP pour indiquer à un homologue SUA distant qu'il souhaite désenregistrer une certaine clé d'acheminement. Normalement, un ASP va envoyer ce message à un SGP, et s'attend à recevoir un message DEREG RSP en retour avec la valeur de contexte d'acheminement associée.


Le format du 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 = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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


Le message DEREG REQ contient les paramètres suivants :


Paramètre

Contexte d'acheminement : Obligatoire


3.8.4 Réponse de désenregistrement (DEREG RSP, Deregistration Response)

Le message DEREG RSP est utilisé comme réponse au message DEREG REQ d'un homologue SUA distant.


Le format du 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 = 0x0015 | Longueur |

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

| Résultat de désenregistrement 1 |

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

/ ... /

\ \

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

| Étiquette = 0x0015 | Longueur |

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

| Résultat de désenregistrement n |

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


Le message DEREG RSP contient les paramètres suivants :


Paramètre

Résultat de désenregistrement : Obligatoire (note)


Note : un ou plusieurs paramètres Résultat de désenregistrement PEUVENT être inclus dans un message DEREG RSP. Le nombre de résultats dans un seul message DEREG RSP peut aller de un au nombre total de paramètres Contexte d'acheminement trouvés dans le message DEREG REQ correspondant.


3.9 Paramètres communs

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


Identifiant du paramètre

Nom du paramètre

0x0000

Réservé

0x0001

Non utilisé dans SUA

0x0002

Non utilisé dans SUA

0x0003

Non utilisé dans SUA

0x0004

Chaîne d'informations

0x0005

Non utilisé dans SUA

0x0006

Contexte d'acheminement

0x0007

Informations de diagnostic

0x0008

Non utilisé dans SUA

0x0009

Données de battement de cœur

0x000A

Non utilisé dans SUA

0x000B

Type de mode de trafic

0x000C

Code d'erreur

0x000D

État

0x000E

Non utilisé dans SUA

0x000F

Non utilisé dans SUA

0x0010

Non utilisé dans SUA

0x0011

Identifiant d'ASP

0x0012

Codet affecté

0x0013

Identifiant de corrélation

0x0014

Résultat d'enregistrement

0x0015

Résultat de désenregistrement

0x0016

État d'enregistrement

0x0017

État de désenregistrement

0x0018

Identifiant local de clé d'acheminement


3.9.1 Non utilisé

L'utilisation de l'identifiant de paramètre 0x0001 dans les messages de SUA n'est pas acceptée.


3.9.2 Non utilisé

L'utilisation de l'identifiant de paramètre 0x0002 dans les messages de SUA n'est pas acceptée.


3.9.3 Non utilisé

L'utilisation de l'identifiant de paramètre 0x0003 dans les messages de SUA n'est pas acceptée.


3.9.4 Chaîne d'informations

Le paramètre facultatif INFO String peut porter toute chaîne significative de caractères UTF-8 [RFC3629] avec le message. La longueur du paramètre INFO String est de 0 à 255 octets. Aucune procédure n'est actuellement identifiée pour son utilisation mais les fournisseurs de service peuvent utiliser INFO String pour des besoins de débogage.


0 1 2 3

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

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

| Étiquette = 0x0004 | Longueur |

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

/ Chaîne d'informations /

\ \

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


3.9.5 Non utilisé in SUA

L'utilisation de l'identifiant de paramètre 0x0005 dans les messages de SUA n'est pas acceptée.


3.9.6 Contexte d'acheminement

0 1 2 3

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

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

| Étiquette = 0x0006 | Longueur |

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

/ Contexte d'acheminement /

\ \

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


Le paramètre Contexte d'acheminement contient (une liste de) des entiers non signés de 4 octets qui indexent le trafic du serveur d'application que l'ASP envoyeur est configuré/enregistré à recevoir. Il y a une relation biunivoque entre une entrée d'indice et une clé d'acheminement ou un nom d'AS.

Un processus de serveur d'application peut être configuré à traiter le trafic pour plus d'un serveur d'application logique. Du point de vue d'un ASP, un contexte d'acheminement définit une gamme de trafic de signalisation que l'ASP est actuellement configuré à recevoir de la SG.

De plus, le paramètre Contexte d'acheminement identifie le contexte de réseau SS7 pour le message, pour les besoins de la séparation logique du trafic de signalisation entre le SGP et le processus de serveur d'application sur une association SCTP commune, lorsque nécessaire. Un exemple est celui d'un SGP logiquement partitionné pour apparaître comme un élément dans plusieurs réseaux SS7 nationaux différents. Il définit implicitement le format de codet SS7 utilisé, la valeur d'indicateur de réseau SS7 et le type/variante/version de protocole SCCP utilisé au sein d'un réseau SS7 séparé. Il définit aussi le contexte réseau pour les valeurs de PC et SSN. Si un SGP opère dans le contexte d'un seul réseau SS7, ou si des associations SCTP individuelles sont dédiées à chaque contexte de réseau SS7, cette fonctionnalité n'est pas nécessaire.

Si le paramètre Contexte d'acheminement est présent, il DEVRAIT être le premier paramètre dans le message car il définit le format et/ou l'interprétation des paramètres qui contiennent une valeur PC ou SSN.


3.9.7 Informations de diagnostic

Les informations de diagnostic peuvent être utilisées pour porter toute information pertinente pour une condition d'erreur, pour aider à l'identification de la condition d'erreur. Dans le cas d'un identifiant de couche Adaptation ou de mode de traitement de trafic, les informations de diagnostic incluent les paramètres reçus. Dans les autres cas, les informations de diagnostic peuvent être les 40 premiers octets du message en faute.


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 = 0x0007 | Longueur |

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

/ Informations de diagnostic /

\ \

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


3.9.8 Non utilisé

L'identifiant de paramètre 0x0008 n'est pas utilisé dans SUA.


3.9.9 Données de battement de cœur (Heartbeat Data)

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

Le receveur d'un message Battement de cœur ne traite pas ce champ car il n'a de signification que pour l'envoyeur. Le receveur fait écho au contenu de Données de battement de cœur dans un message BEAT-Ack.


0 1 2 3

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

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

| Étiquette = 0x0009 | Longueur |

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

/ Données de battement de cœur /

\ \

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


Le champ de données peut être utilisé pour mémoriser des informations du message Battement de cœur utiles pour le nœud envoyeur (par exemple, le champ données peut contenir un horodatage, un numéro de séquence, etc.).


3.9.10 Non utilisé

L'identifiant de paramètre 0x000A n'est pas utilisé dans SUA.


3.9.11 Type de mode de trafic

Le paramètre Type de mode de trafic identifie le mode de fonctionnement du trafic de l'ASP au sein d'un AS.


0 1 2 3

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

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

| Étiquette = 0x000B | Longueur = 8 |

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

| Type de mode de trafic |

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


Les valeurs valides pour Type sont montrées dans le tableau suivant :

1 : Outrepasse

2 : Partage de charge

3 : Diffusion


Au sein d'un contexte d'acheminement, les types Outrepasse, Partage de charge et Diffusion ne peuvent pas être mêlés. La valeur Outrepasse indique que l'ASP fonctionne dans le mode Outrepasse, et l'ASP souhaite prendre tout le trafic pour un serveur d'application (c'est-à-dire, le fonctionnement principal/de sauvegarde) outrepassant tout ASP actuellement actif dans l'AS. En mode Partage de charge, l'ASP souhaite partager la distribution du trafic avec tous les autres ASP actuellement actifs. En mode Diffusion, l'ASP souhaite recevoir le même trafic que tout autre ASP actuellement actif. Lorsque il n'y a pas suffisamment d'ASP, l'envoyeur peut immédiatement faire passer des ASP à l'état Actif.


3.9.12 Code d'erreur

0 1 2 3

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

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

| Étiquette =0x000C | Longueur = 8 |

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

| Code d'erreur |

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


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

0x01 : Version invalide

0x02 : Non utilisé dans SUA

0x03 : Classe de message non prise en charge

0x04 : Type de message non pris en charge

0x05 : Mode de traitement du trafic non pris en charge

0x06 : Message non attendu

0x07 : Erreur de protocole

0x08 : Non utilisé dans SUA

0x09 : Identifiant de flux invalide

0x0a : Non utilisé dans SUA

0x0b : Non utilisé dans SUA

0x0c : Non utilisé dans SUA

0x0d : Refusé – blocage de gestion

0x0e : Identifiant d'ASP exigé

0x0f : Identifiant d'ASP invalide

0x10 : Non utilisé dans SUA

0x11 : Valeur de paramètre invalide

0x12 : Erreur du champ Paramètre

0x13 : Paramètre inattendu

0x14 : État de destination inconnu

0x15 : Apparence du réseau invalide

0x16 : Paramètre manquant

0x17 : Non utilisé dans SUA

0x18 : Non utilisé dans SUA

0x19 : Contexte d'acheminement invalide

0x1a : Pas d'AS configuré pour l'ASP

0x1b : État de sous système inconnu

0x1c : Étiquette de partage de charge invalide


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


Le message "Classe de message non prise en charge" est envoyé si est reçu un message avec une classe de message non attendue ou non prise en charge.


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


L'erreur "Mode de traitement de trafic non pris en charge" est envoyée par un SGP si un ASP envoie un message ASP Active avec un type de mode de trafic non pris en charge ou un type de mode de trafic non cohérent avec le mode présentement configuré pour le serveur d'application. Un exemple serait le cas d'un SGP qui n'accepte pas le partage de charge.


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


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


L'erreur "Identifiant de flux invalide" est envoyée si un message est reçu sur un flux SCTP inattendu.


L'erreur "Refusé – blocage de gestion" est envoyée lorsque un message ASP Up ou ASP Active est reçu et que la demande est refusée pour des raisons de gestion (par exemple, fermeture de gestion). Si l'erreur est en réponse à un message ASP Active, le contexte d'acheminement dans le message ASP Active DEVRAIT être inclus dans le message d'erreur.


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


L'erreur "Identifiant d'ASP invalide" est envoyée par un SGP en réponse à un message ASP Up avec un identifiant d'ASP invalide.


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


"Erreur du champ Paramètre" serait envoyé si un message est reçu avec un paramètre qui a un champ Longueur faux.


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


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

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


L'erreur "Contexte d'acheminement invalide" serait envoyée par une SG si un ASP envoie un message avec une valeur invalide (non configurée) de contexte d'acheminement. Pour cette erreur, le ou les contextes d'acheminement invalides (non configurés) DOIVENT être inclus dans le paramètre Contexte d'acheminement.


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


L'erreur "État de destination inconnu" PEUT être envoyée si un DAUD est reçu à une SG qui s'enquiert de la disponibilité ou de l'état d'encombrement d'une destination, et si la SG ne souhaite pas fournir cet état (par exemple, l'envoyeur n'est pas autorisé à connaître l'état). Pour cette erreur, le codet invalide ou non autorisé DOIT être inclus ainsi que l'apparence du réseau et le contexte d'acheminement associés au codet.


L'erreur "État de sous système inconnu" PEUT être envoyée si un DAUD est reçu à la SG qui s'enquiert de la disponibilité ou de l'état d'encombrement d'un sous système, et que la SG ne souhaite pas fournir l'état (par exemple, l'envoyeur n'est pas autorisé à connaître l'état). Pour cette erreur, le codet invalide ou non autorisé et le numéro de sous système DOIVENT être inclus ainsi que l'apparence du réseau et le contexte d'acheminement associés au codet et au numéro de sous système.


3.9.13 État

Le paramètre État identifie le type de l'état qui est notifié et l'identifiant d'état.


0 1 2 3

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

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

| Étiquette = 0x000D | Longueur = 8 |

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

| Type d'état | Identifiant d'état |

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


Les valeurs valides de Type d'état (entier non signé de 16 bits) sont :

1 : l'état du serveur d'application change (AS_State_Change)

2 : autre


Le paramètre Identifiant d'état contient plus d'informations détaillées pour la notification, fondées sur la valeur de Type d'état.


Si le type d'état est AS_STATE_CHANGE, les valeurs de l'identifiant d'état (entier non signé de 16 bits) sont :

1 : réservé

2 : serveur d'application inactif (AS-Inactive)

3 : serveur d'application actif (AS-Active)

4 : serveur d'application en cours (AS-Pending)


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


Si le type d'état est "autre", les valeurs d'informations d'état suivantes sont alors définies :

1 : Ressources d'ASP actives insuffisantes dans l'AS

2 : ASP actif de remplacement

3 : Défaillance d'ASP


Ces notifications ne se fondent pas sur le rapport par le SGP des changements d'état d'un ASP ou AS. Dans le cas de ressources d'ASP insuffisantes, le SGP indique à un ou des ASP "Inactifs" dans l'AS qu'un autre ASP est nécessaire pour traiter la charge de l'AS (en mode partage de charge ou en mode diffusion). Pour le cas de l'ASP actif de remplacement, un ASP est informé lorsque un ASP de remplacement passe à l'état ASP-Active en mode Outrepassement.


3.9.14 Non utilisé dans SUA

L'identifiant de paramètre 0x000E n'est pas utilisé dans SUA.


3.9.15 Non utilisé dans SUA

L'identifiant de paramètre 0x000F n'est pas utilisé dans SUA..


3.9.16 Non utilisé dans SUA

L'identifiant de paramètre 0x0010 n'est pas utilisé dans SUA..


3.9.17 Identifiant d'ASP

0 1 2 3

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

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

| Étiquette = 0x0011 | Longueur = 8 |

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

| Identifiant d'ASP |

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


Champ Identifiant d'ASP : 32 bits (entier non signé)


Le champ Identifiant d'ASP contient une valeur unique qui est de signification locale parmi les ASP qui prennent en charge un AS. Le SGP devrait sauvegarder l'identifiant d'ASP à utiliser, si nécessaire, avec le message Notify (voir le paragraphe 3.7.2).


3.9.18 Codet affecté

Le paramètre Destinations de codet affecté contient une liste des champs de codet affecté, dont chacun est un paramètre de trois octets pour permettre des codets SS7 formatés en binaire de 14, 16, et 24 bits. Les codets affectés qui font moins de 24 bits sont bourrés à gauche jusqu'à la limite des 24 bits.


0 1 2 3

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

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

| Étiquette = 0x0012 | Longueur |

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

| Gabarit | Codet affecté 1 |

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

/ . . . /

\ \

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


Le codage est montré ci-dessous pour les exemples de codets ANSI et UIT.


Codet ANSI de 24 bits :


0 1 2 3

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

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

| Gabarit | Réseau | Grappe | Membre |

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

|MSB-----------------------------------------LSB|


Codet UIT de 14 bits :


0 1 2 3

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

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

| Gabarit |0 0 0 0 0 0 0 0 0 0|Zone | Région | SP |

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

|MSB---------------------LSB|


Il est FACULTATIF pour une mise en œuvre de générer un paramètre Codet affecté avec plus d'un codet affecté, mais la mise en œuvre DOIT accepter et traiter un paramètre Codet affecté avec plus d'un codet affecté.


Gabarit : 8 bits

Le paramètre Gabarit peut être utilisé pour identifier une gamme contiguë de codets de destinations affectées, indépendamment du format du codet. L'identification d'une gamme contiguë de codets affectés peut être utile lorsque la réception d'un message de gestion MTP3 ou d'un événement de l'ensemble de liaisons affecte simultanément l'état de disponibilité d'une série de destinations à une SG.


Le paramètre Gabarit est un entier qui représente un gabarit binaire qui peut être appliqué au champ Codet affecté concerné. Le gabarit binaire identifie le nombre de bits du champ Codet affecté qui sont significatifs et lesquels sont effectivement "masqués". Par exemple, un gabarit de "8" indique que les huit derniers bits du codet sont "masqués". Pour un codet affecté ANSI de 24 bits, ceci est équivalent à signaler que tous les codets d'une grappe ANSI sont indisponibles. Un gabarit de "3" indique que les trois derniers bits du codet sont "masqués". Pour un codet affecté de 14 bits de l'UIT, ceci est équivalent à signaler qu'une région UIT est indisponible.


3.9.19 Identifiant de corrélation

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 = 0x0013 | Longueur = 8 |

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

| Identifiant de corrélation |

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


L'identifiant de corrélation est un identifiant de 32 bits qui est joint aux messages CLDT pour indiquer à un ASP nouvel entrant dans un AS Diffusion à quel point du flux de trafic de messages CLDT il se joint. Il est attaché au premier message CLDT envoyé à un ASP par une SG après l'envoi d'un ASP Active Ack ou autrement en commençant l'envoi de trafic à un ASP. L'identifiant de corrélation n'a de signification qu'au sein d'un contexte d'acheminement.


Note de mise en œuvre : le paramètre Identifiant de corrélation peut être utilisé pour des dispositifs comme la synchronisation des ASP/SGP dans un AS/SG en mode diffusion, pour éviter une duplication de message et un mauvais séquençage en cas de reprise sur échec d'une association d'un ASP/SGP à un autre ASP/SGP, etc.


3.9.20 Résultat d'enregistrement

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 = 0x0018 | Longueur |

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

| Identifiant de clé d'acheminement |

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

| Étiquette = 0x0016 | Longueur |

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

| État d'enregistrement |

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

| Étiquette = 0x0006 | Longueur |

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

| Contexte d'acheminement |

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


Le paramètre Identifiant de clé d'acheminement contient la même valeur de paramètre formatée en TLV qu'on a trouvé dans le paramètre correspondant de clé d'acheminement dans le message REG REQ.


Contexte d'acheminement contient le même paramètre de contexte d'acheminement formaté en TLV pour la clé d'acheminement associée si l'enregistrement a réussi. Il est réglé à "0" si l'enregistrement a échoué.


3.9.21 Résultat de désenregistrement

0 1 2 3

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

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

| Étiquette = 0x0006 | Longueur |

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

| Contexte d'acheminement |

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

| Étiquette = 0x0017 | Longueur |

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

| État de désenregistrement |

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


Contexte d'acheminement : entier de 32 bits

Contexte d'acheminement contient la valeur de contexte d'acheminement de la clé d'acheminement correspondante à désenregistrer, telle qu'elle se trouve dans le message DEREG REQ.


État de désenregistrement : entier de 32 bits

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


3.9.22 État d'enregistrement

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 = 0x0016 | Longueur = 8 |

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

| État d'enregistrement |

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


État d'enregistrement : 32 bits (entier non signé)


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

Ses valeurs peuvent être :

0 : Bien enregistré

1 : Erreur - inconnu

2 : Erreur – adresse de destination invalide

3 : Erreur – apparence du réseau invalide

4 : Erreur - clé d'acheminement invalide

5 : Erreur - permission refusée

6 : Erreur – ne peut pas prendre en charge l'acheminement unique

7 : Erreur - clé d'acheminement non provisionnée actuellement

8 : Erreur – ressources insuffisantes

9 : Erreur – champ Paramètre de clé d'acheminement non pris en charge

10 : Erreur – type de mode de trafic non pris en charge/invalide

11 : Erreur – changement de clé d'acheminement refusé


3.9.23 État de désenregistrement

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 = 0x0017 | Longueur = 8 |

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

| État de résultat de désenregistrement |

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


État de désenregistrement : entier de 32 bits

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

Ses valeurs peuvent être :

0 : Succès du désenregistrement

1 : Erreur - inconnue

2 : Erreur – contexte d'acheminement invalide

3 : Erreur - permission refusée

4 : Erreur - non enregistré

5 : Erreur - ASP actuellement actif pour le contexte d'acheminement


3.9.24 Identifiant de clé d'acheminement local

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 = 0x0018 | Longueur = 8 |

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

| Identifiant local de clé d'acheminement |

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


Le champ Identifiant local de clé d'acheminement est un entier non signé de 32 bits. 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 originale d'enregistrement. La valeur de l'identifiant doit rester unique jusqu'à la réception du message REG RSP.


3.10 Paramètres spécifiques de SUA

Ces TLV de paramètres sont spécifiques du protocole de SUA.


Identifiant du paramètre Nom du paramètre

0x0101

Compteur de bonds SS7

0x0102

Adresse de source

0x0103

Adresse de destination

0x0104

Numéro de référence de source

0x0105

Numéro de référence de destination

0x0106

Cause SCCP

0x0107

Numéro de séquence

0x0108

Numéro de séquence reçu

0x0109

Capacités d'ASP

0x010A

Crédit

0x010B

Données

0x010C

Usager/cause

0x010D

Apparence du réseau

0x010E

Clé d'acheminement

0x010F

Étiquette DRN

0x0110

Étiquette TID

0x0111

Gamme d'adresses

0x0112

SMI

0x0113

Importance

0x0114

Priorité de message

0x0115

Classe de protocole

0x0116

Contrôle de séquence

0x0117

Segmentation

0x0118

Niveau d'encombrement


Sous paramètres d'adresse de destination/source

0x8001

Titre global

0x8002

Codet

0x8003

Numéro de sous système

0x8004

Adresse IPv4

0x8005

Nom d'hôte

0x8006

Adresse IPv6


3.10.1 Compteur de bonds SS7


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 = 0x0101 | Longueur = 8 |

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

| Réservé |Compte bond SS7|

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


Compte bond SS7 (3.18/Q.713)

La valeur du compte de bonds SS7 est décrémentée avec chaque traduction de titre global et est dans la gamme de 15 à 1.


3.10.2 Adresse de source

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 = 0x0102 | Longueur de paramètre |

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

| Indicateur d'acheminement | Indicateur d'adresse |

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

/ Paramètres d'adresse /

\ \

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


Les combinaisons de paramètres d'adresse suivantes sont valides :

- Titre global (par exemple, numéro E.164) + codet facultatif et/ou SSN, SSN peut être zéro, quand l'acheminement est fait sur titre global

- SSN (non zéro) + codet facultatif et/ou titre global, lorsque l'acheminement est fait sur PC + SSN. Le codet est obligatoire dans l'adresse de source lors de l'envoi de SGP à ASP, et dans l'adresse de destination lors de l'envoi de l'ASP au SGP pour atteindre le SEP SS7.

- Nom d'hôte + SSN facultatif, lorsque l'acheminement est fait par nom d'hôte.

- SSN (non zéro) et adresse IP facultative (IPv4 ou IPv6) lorsque l'acheminement est fait sur l'adresse IP + SSN.


3.10.2.1 Indicateur d'acheminement

Les valeurs suivantes sont valides pour l'indicateur d'acheminement :

0

Réservé

1

Acheminement sur titre global

2

Acheminement sur SSN + PC

3

Acheminement sur nom d'hôte

4

Acheminement sur SSN + adresse IP


L'indicateur d'acheminement détermine quels paramètres d'adresses doivent être présents dans le champ Paramètres d'adresse.


3.10.2.2 Indicateur d'adresse

Ce paramètre est nécessaire pour l'inter fonctionnement avec les réseaux SS7. L'indicateur d'adresse spécifie quels paramètres d'adresses sont en fait reçus dans l'adresse SCCP provenant du réseau SS7, ou sont à remplir dans l'adresse SCCP lorsque le message est envoyé dans le réseau SS7. La valeur de l'indicateur d'acheminement doit être prise en compte. Elle est utilisée dans la direction de l'ASP vers la SG. Par exemple, le paramètre Codet est présent dans l'adresse de destination du CLDT envoyé de l'ASP->SG, mais le bit 2 est réglé à "0" ce qui signifie "ne pas remplir ceci dans l'adresse du demandé du SCCP". Son effet est que la SG utilise seulement le codet pour remplir le champ DPC d'étiquette d'acheminement du sous-système de transfert de messages (MTP, Message Transfer Part) mais ne l'inclut pas dans l'adresse du demandé de SCCP.


Dans la direction SG->ASP, le paramètre Codet d'adresse de source est présent (codet du SEP SS7). Cependant, ceci peut avoir été rempli à partir de l'OPC dans l'étiquette d'acheminement MTP reçue, et non du champ Codet dans l'adresse du demandeur SCCP. Dans ce cas, le bit 2 = "0" note cela. L'indicateur d'adresse donne des instructions supplémentaires à la SG sur comment et quand remplir les adresses SCCP ; dans la direction SG->ASP, l'indicateur d'adresse donne des informations à l'ASP sur ce qui était réellement présent dans les adresses SCCP reçues.


L'indicateur d'adresse est codé comme suit :


Le bit 1 est utilisé pour indiquer l'inclusion du SSN

0 : Ne pas inclure le SSN lorsque il est facultatif

1 : Inclure le SSN


Le bit 2 est utilisé pour indiquer l'inclusion du codet

0 : Ne pas inclure le codet, sans considération de la valeur de l'indicateur d'acheminement

1 : Inclure le codet


Le bit 3 est utilisé pour indiquer l'inclusion du titre global (GT)

0 : Ne pas inclure le GT lorsque il est facultatif (indicateur d'acheminement ≠ 1)

1 : Inclure le GT


Les bits restants sont réservés et DEVRAIENT être codés à zéro, et DOIVENT être ignorés par le receveur.


3.10.2.3 Titre global

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 = 0x8001 | Longueur |

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

| Réservé | GTI |

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

|Nmbr de chiffre| Type de trad. | Plan numérot. | Nature d'adres|

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

/ Chiffres du titre global /

\ \

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


Nombre de chiffres : c'est le nombre de chiffres contenus dans le titre global.


GTI (Global Title Indicator, indicateur de titre global, défini au paragraphe 3.4.2.3 de Q.713).

0000 : Invalide

0001 : Nature d'adresse est sauté. On suppose implicitement que Type de traduction = inconnu et Plan de numérotage = E.164 (valeur 1).

0010 : C'est ce qui est le plus couramment utilisé dans les réseaux d'Amérique du Nord. Le type de traduction détermine implicitement la nature d'adresse et le plan de numérotage. Ces données peuvent être configurées dans la SG. Le nombre de chiffres est toujours pair et est déterminé par la longueur d'adresse SCCP.

0011 : Plan de numérotage et type de traduction sont sautés. Il est implicitement supposé que Nature d'adresse = inconnu

0100 : Ce format est utilisé dans le réseau international et le plus couramment dans les réseaux hors d'Amérique du Nord. Toutes les informations pour remplir l'adresse de source sont présentes dans l'adresse SCCP.


Type de traduction :

0 : inconnu

1 - 63 : services internationaux

64 - 127 : réservé

128 - 254 : spécifique de réseau national

255 : réservé


Plan de numérotage :

0 : inconnu

1: plan de numérotage RNIS/téléphonie (Recommandations E.163 et E.164)

2 : plan de numérotage générique

3 : plan de numérotage de données (Recommandation X.121)

4 : plan de numérotage du télex (Recommandation F.69)

5 : plan de numérotage de mobile maritime (Recommandations E.210, E.211)

6 : plan de numérotage de mobile terrestre (Recommandation E.212)

7 : plan de numérotage de RNIS/mobile (Recommandation E.214)

8 - 13 : réservé

14 : plan de numérotage de réseau privé ou spécifique de réseau

15 - 126 : réservé

127 : réservé.


Nature de l'adresse :

0 : inconnue

1 : numéro d'abonné

2 : réservé pour usage national

3 : numéro à signification nationale

4 : numéro international

5 - 255 : réservé


Titre global :

Les octets contiennent un nombre de signaux d'adresse et éventuellement de boucheurs comme montré ci-dessous :


0 1 2 3

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

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

|2 sign.|1 sign.|4 sign.|3 sign.|6 sign.|5 sign.|8 sign.|7 sign.|

| d'adr.| d'adr.| d'adr.| d'adr.| d'adr.| d'adr.| d'adr.| d'adr.|

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

| ............. |bouchr.|N sign.| boucheur |

| |si néc.| d'adr.| |

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


Tous les bits de remplisseurs DEVRAIENT être réglés à 0.


Les signaux d'adresse sont codés comme défini au paragraphe 3.4.2.3.1 de la Recommandation UIT-T Q.713.


3.10.2.4 Codet

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 = 0x8002 | Longueur = 8 |

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

| Codet |

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

Voir au paragraphe 3.9.18 "Codet affecté" la disposition du champ Codet.


3.10.2.5 Numéro de sous système

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 = 0x8003 | Longueur = 8 |

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

| Réservé | Valeur SSN |

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

Les valeurs normalisées internationales de SSN sont décrites au paragraphe 3.4.2.2 de la Recommandation UIT-T Q.713.


3.10.2.6 Adresses de

Les formats d'adresse IP peuvent utiliser différentes étiquettes. On notera que si l'adresse de source est dans une certaine version IP, l'adresse de destination devrait aussi être dans la même version IP.


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 = 0x8004/0x8006 | Longueur |

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

/ Adresse IPv4 ou IPv6 /

\ \

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

Note : La valeur d'étiquette 0x8004 est pour une adresse IPv4 et 0x8006 est pour IPv6.


3.10.2.7 Nom d'hôte

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 = 0x8005 | Longueur |

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

/ Nom d'hôte /

\ \

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


Nom d'hôte : longueur variable

Ce champ contient un nom d'hôte selon la "syntaxe de nom d'hôte" décrite au paragraphe 2.1 de la [RFC1123]. La méthode de résolution de nom d'hôte sort du domaine d'application du présent document.


Note : au moins un terminateur nul est inclus dans la chaîne Nom d'hôte et doit être inclus dans la longueur.


3.10.3 Adresse de destination

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 = 0x0103 | Longueur de paramètre |

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

| Indicateur d'acheminement | Indicateur d'adresse |

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

/ Paramètres d'adresse /

\ \

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


Le format de ce paramètre est identique à celui du paramètre Adresse de source.


3.10.4 Numéro de référence de source

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 = 0x0104 | Longueur = 8 |

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

| Numéro de référence de source |

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


Le numéro de référence de source est un entier de 4 octets qui est alloué par l'instance de source SUA.


3.10.5 Numéro de référence de destination

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 = 0x0105 | Longueur = 8 |

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

| Numéro de référence de destination |

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


Le numéro de référence de destination est un entier de 4 octets qui est alloué par l'instance de destination SUA.


3.10.6 Cause SCCP

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 = 0x0106 | Longueur = 8 |

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

| Réservé | Type de cause |Valeur de cause|

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


Ce paramètre groupe les paramètres SCCP Cause de libération, Cause de retour, Cause de rétablissement, Cause d'erreur, et Cause de refus.


Type de cause peut avoir les valeurs suivantes :

0x1 : Cause de retour

0x2 : Cause de refus

0x3 : Cause de libération

0x4 : Cause de rétablissement

0x5 : Cause d'erreur


Valeur de cause contient la valeur de cause spécifique. On donne ci-dessous des exemples pour les valeurs SCCP de l'UIT-T. On trouvera les références ANSI dans ANSI T1.112.3


Valeur de cause dans le message SUA

Correspondance avec le paramètre SCCP

Référence

CLDR

Cause de retour

UIT-T Q.713 § 3.12

COREF

Cause de refus

UIT-T Q.713 § 3.15

RELRE

Cause de libération

UIT-T Q.713 § 3.11

RESRE

Cause de rétablissement

UIT-T Q.713 § 3.13

ERR

Cause d'erreur

UIT-T Q.713 § 3.14


3.10.7 Numéro de séquence

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 = 0x0107 | Longueur = 8 |

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

| Réservé | Num séq reçu|M| Num séq envoi |

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


Ce paramètre est utilisé pour indiquer si "plus" de données vont suivre dans les messages CODT suivants, et/ou pour numéroter chaque message CODT à la suite pour les besoins du contrôle de flux. Il contient le numéro de séquence reçu et celui d'envoi, P(R) et P(S) dans Q.713, paragraphes 3.7 et 3.9. À ce titre, il peut aussi être utilisé pour accuser réception de transferts de données depuis l'homologue en cas de protocole de classe 3.


Le numéro de séquence envoyé fait un octet et est codé comme suit :

Les bits 2 à 8 sont utilisés pour indiquer le numéro de séquence d'envoi (P(S).

Le bit 1 (LSB) de l'octet 1 est réservé.


Le numéro de séquence reçu fait un octet, et est codé comme suit :

Les bits 2 à 8 sont utilisés pour indiquer le numéro de séquence reçu P(R).

Le bit 1 (LSB) est utilisé pour l'indication de plus (M, more) de données, comme suit :

0 : pas plus de données

1 : plus de données


3.10.8 Numéro de séquence en réception

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 = 0x0108 | Longueur = 8 |

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

| Réservé | Num séq reçu |

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


Ce paramètre est utilisé exclusivement pour les protocoles de classe 3 dans le message d'accusé de réception des données pour indiquer le bord inférieur de la fenêtre de réception. Voir Q.713, § 3.9.


C'est un entier d'un octet codé comme suit :

Les bits 8 à 2 sont utilisés pour indiquer le numéro de séquence reçu P(R).

Le bit 1 est réservé.


3.10.9 Capacités d'ASP

Ce paramètre est utilisé pour que l'ASP puisse faire rapport de ses capacités en ce qui concerne SUA pour prendre en charge les différentes classes de protocole et scénarios d'inter fonctionnement.


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 = 0x0109 | Longueur = 8 |

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

| Réservé |0 0 0 0|a|b|c|d| Interfonction.|

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


Fanions

a - Protocole de classe 3

b - Protocole de classe 2

c - Protocole de classe 1

d - Protocole de classe 0


Il est obligatoire de prendre en charge au moins le protocole de classe 0.


Valeurs d'inter fonctionnement

0x0 indique qu'il n'y a pas d'inter fonctionnement avec les réseaux SS7.

0x1 indique un point d'extrémité de signalisation IP (ASP), inter fonctionnant avec les réseaux SS7.

0x2 indique une passerelle de signalisation.

0x3 indique la prise en charge d'un nœud relais.


3.10.10 Crédit

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 = 0x010A | Longueur = 8 |

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

| Réservé | Crédit |

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


La longueur du champ Crédit est d'un octet. Voir le paragraphe 3.10 de la Recommandation UIT-T Q.713. Ce paramètre est utilisé exclusivement pour les protocoles de classe 3.


3.10.11 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 = 0x010b | Longueur |

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

/ Données /

\ \

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


Le champ de paramètre Données contient le message d'application SS7 d'utilisateur SCCP, par exemple un message INAP/TCAP.


3.10.12 Usager/Cause

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 = 0x010c | Longueur = 8 |

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

| Cause | Usager |

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


"Usager" est codé à cette valeur SI de SCCP. Il peut y avoir plusieurs SCCP à un certain codet, chacun avec une valeur de SI différente, bien que normalement il y en ait seulement un avec SI = 3.


Cause peut prendre les valeurs suivantes :

0 : SCCP distant indisponible, raison inconnue ;

1 : SCCP distant non équipé ;

2 : SCCP distant inaccessible.


3.10.13 Apparence du réseau

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 = 0x010D | Longueur = 8 |

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

| Apparence du réseau |

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


Champ Apparence du réseau : 32bits (entier non signé)

Le champ Apparence du réseau identifie le contexte de réseau SS7 pour la clé d'acheminement. La valeur d'apparence du réseau n'a de signification que locale, coordonnée entre la SG et l'ASP. Donc, lorsque l'ASP est connecté à plus d'une SG, le même contexte de réseau SS7 peut être identifié par différentes valeurs d'apparence du réseau selon la SG auprès de laquelle l'ASP s'enregistré.


Dans la clé d'acheminement, Apparence du réseau identifie le codet SS7 et le format de type de traduction de titre global utilisé, et le protocole SCCP et éventuellement d'utilisateur SCCP (type, variante et version) utilisé dans le réseau SS7 spécifié.


3.10.14 Clé d'acheminement

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 = 0x010E | Longueur |

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

| Étiquette = 0x0018 | Longueur = 8 |

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

| Identifiant local de clé d'acheminement |

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

\ Paramètres de clé \

/ /

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


Champ Identifiant local de clé d'acheminement : 32 bits (entier non signé)


Champ Paramètres de clé : variable


Le champ Paramètres de clé contient les paramètres suivants :

Type de mode de trafic : Facultatif

Apparence de réseau : Facultatif (note)

Adresse de source : Facultatif

Adresse de destination : Facultatif

Gamme d'adresses : Facultatif


Note : le paramètre Apparence du réseau doit être inclus dans la clé d'acheminement lorsque l'ASP est capable de s'enregistrer dans plusieurs contextes de réseau SS7.


3.10.15 Étiquette DRN

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 = 0x010F | Longueur = 8 |

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

| Début | Fin | Valeur d'étiquette |

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


Le paramètre Début est la position de début de l'étiquette, entre 0 (LSB) et 23 (MSB).

Le paramètre Fin est la position de fin de l'étiquette, entre 0 (LSB) et 23 (MSB).

La valeur d'étiquette est un entier de 16 bits, qui est unique sur un AS.


3.10.16 Étiquette TID

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 = 0x0110 | Longueur = 8 |

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

| Début | Fin | Valeur d'étiquette |

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


Le paramètre Début est la position de début de l'étiquette, entre 0 (LSB) et 23 (MSB).

Le paramètre Fin est la position de fin de l'étiquette, entre 0 (LSB) et 31 (MSB).

La valeur d'étiquette est un entier de 16 bits, qui est unique sur un AS.


3.10.17 Gamme d'adresse

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 = 0x0111 | Longueur = 8 |

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

\ Paramètres d'adresse \

/ /

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


Le champ Paramètres d'adresse a les paramètres suivants :

Adresse de source : Facultatif (note)

Adresse de destination : Facultatif (note)


Note : Le champ Paramètres d'adresse doit contenir des paires d'adresses de source ou des paires d'adresses de destination mais NE DOIT PAS mêler des adresses de source et de destination dans le même champ.


3.10.18 SMI

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 = 0x0112 | Longueur = 8 |

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

| Réservé | SMI |

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


L'indicateur de sous systèmes multiples (SMI, Subsystem Multiplicity Indicator) peut avoir les valeurs suivantes :

0x00 : Réservé/inconnu

0x01 : Solitaire

0x02 : Dupliqué

0x03 : Triplé

0x04 : Quadruplé

0xff : Non spécifié


3.10.19 Importance

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 = 0x0113 | Longueur = 8 |

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

| Réservé | Importance |

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


Importance (3.19/Q.713) : Les valeurs possibles du paramètre Importance sont entre 0 et 7, où la valeur de 0 indique le moins important et 7 indique le plus important.


3.10.20 Priorité du message (ou Priorité)

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 = 0x0114 | Longueur = 8 |

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

| Réservé | Priorité msg. |

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


Priorité

Les valeurs de Priorité vont de 0 à 3. Si la valeur de Priorité n'a pas été spécifiée par l'utilisateur SCCP, elle devrait être réglée à 0xFF. La SG PEUT prendre la priorité en compte pour déterminer la priorité du message MTP. Dans le cas tout IP, ce paramètre PEUT être utilisé.

Le paramètre Priorité de message est facultatif dans les messages CLDT, CLDR, CORE, COAK et CODT. Cependant, pour les réseaux qui prennent en charge la priorité de message (par exemple, ANSI) ce paramètre DOIT être inclus mais il n'est pas exigé pour ceux qui ne le font pas (par exemple, International).


3.10.21 Classe de protocole

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 = 0x0115 | Longueur = 8 |

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

| Réservé | Cl. protocole |

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


Classe de protocole (3.6/Q.713)

Les bits 1-2 indiquent la classe du protocole.

Valeur Description

0 : Classe 0 (service sans connexion)

1 : Classe 1 (service sans connexion)

2 : Classe 2 (service en mode connexion)

3 : Classe 3 (service en mode connexion)


Le bit 8 indique l'utilisation de la procédure de retour sur erreur.

Valeur Description

0x0 : pas d'option particulière

0x1 : message de retour sur erreur


Les bits 3 à 7 sont réservés et DEVRAIENT être codés zéro, et DOIVENT être ignorés par le receveur.


3.10.22 Contrôle de séquence

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 = 0x0116 | Longueur = 8 |

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

| Contrôle de séquence |

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


Contrôle de séquence (6.2.2.2.2/Q.711)

Le champ est codé avec la valeur du paramètre de contrôle de séquence associé à un groupe de messages et il est choisi de façon à assurer un partage de charge approprié des groupes de messages sur les valeurs de SLS tout en assurant que les valeurs de contrôle de séquence au sein des groupes de messages ont la valeur de contrôle de séquence codée avec la même valeur que le message initial du groupe de messages.


3.10.23 Segmentation

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 = 0x0117 | Longueur = 32 |

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

| premier/reste | Référence de segmentation |

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


Le champ premier/segments restants est formaté comme suit :

le bit 8 (MSB) indique si c'est le premier segment (1) ou non (0)

les bits 1 à 7 indiquent le nombre de segments restants, d'une valeur entre 0 et 15

Le champ va donc être codé 1000 0000 (premier, pas de segment restant) pour un CLDT non segmenté.


Le champ Référence de segmentation est un entier de 3 octets, alloué par l'ASP.


3.10.24 Niveau d'encombrement

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 = 0x0118 | Longueur = 8 |

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

| Niveau d'encombrement |

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


Le champ Niveau d'encombrement est un entier non signé de 8 bits. Il contient le niveau auquel l'encombrement s'est produit.


Lorsque le paramètre Niveau d'encombrement est inclus dans un message SCON qui correspond à une primitive N-PCSTATE, le champ Niveau d'encombrement indique le niveau d'encombrement de MTP rencontré par le point de signalisation local ou affecté comme indiqué par le ou les codets affectés aussi dans le message SCON. Dans ce cas, les valeurs valides pour le champ Niveau d'encombrement sont les suivantes :

0 : pas d'encombrement ou indéfini

1 : niveau d'encombrement 12 : niveau d'encombrement 2

3 : niveau d'encombrement 3


Lorsque le paramètre Niveau d'encombrement est inclus dans un message SCON qui correspond à une primitive N-STATE, le champ Niveau d'encombrement indique le niveau d'importance SCCP restreint rencontré par le sous système local ou affecté comme indiqué par le codet affecté et le numéro de sous système qui est aussi dans le message SCON. Dans ce cas, les valeurs valides pour le champ Niveau d'encombrement vont de 0 à 7, où 0 indique le sous système le moins encombré et 7 le plus encombré.


4. Procédures


La couche SUA a besoin de répondre aux diverses primitives locales qu'elle reçoit des autres couches ainsi qu'aux messages qu'elle reçoit de la couche SUA homologue. La présente section décrit les procédures de SUA en réponse à ces événements.


4.1 Procédures de prise en charge de la couche utilisateur SUA

4.1.1 Réception des primitives de SCCP

Lorsque un message de gestion de sous système SCCP (SCMG, SCCP Subsystem Management) est reçu du réseau SS7, le SGP a besoin de déterminer si il y a des serveurs d'application concernés intéressés par les changements d'état de sous systèmes. La fonction de gestion SUA est informée avec les primitives N-State ou N-Coord sur lesquelles elle formate et transfère le message SNM applicable à la liste des ASP concernés en utilisant l'identifiant de flux "0".


Lorsque des indications de la gestion MTP-3 sont reçues (MTP-PAUSE, MTP-RESUME, MTP-STATUS) la gestion de sous système SCCP détermine si il y a des utilisateurs SCCP locaux concernés. Lorsque ces utilisateurs SCCP locaux sont en fait des serveurs d'applications, desservis par des ASP, la gestion SUA est informée avec la primitive d'indication N-PCSTATE sur laquelle elle formate et transfère le message SNM applicable (DUNA, DAVA, DRST ou SCON) à la liste des ASP concernés en utilisant l'identifiant de flux "0".


La fonction de distribution de message SUA détermine le serveur d'application (AS) sur la base de la comparaison des informations dans la primitive de demande N-UNITDATA avec une clé d'acheminement provisionnée.


À partir de la liste des ASP dans le tableau d'AS, un ASP dans l'état ASP-ACTIVE est choisi et un message DATA est construit et produit sur l'association SCTP correspondante. Si plus d'un ASP est dans l'état ASP-ACTIVE (c'est-à-dire, si le trafic doit être à charge partagée à travers plus d'un ASP) un des ASP dans l'état ASP_ACTIVE est choisi dans la liste. Si les ASP sont en mode Diffusion, tous les ASP actifs seront retenus et le message envoyé à chacun des ASP actifs. L'algorithme de choix dépend de la mise en œuvre mais pourrait par exemple être un round robin ou être fondé sur le SLS. L'algorithme de choix approprié doit être choisi avec soin car il dépend des hypothèses d'application et de la compréhension du degré de coordination d'état entre les ASP ASP_ACTIVE dans l'AS.


De plus, le message doit être envoyé sur le flux SCTP approprié, là encore en veillant à respecter les besoins de séquençage de message de l'application de signalisation. Les messages DATA DOIVENT être envoyés sur un flux SCTP autre qu'un flux '0' lorsque il y a plus d'un flux.


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


4.2 Réception de primitives de la gestion de couches

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


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


Lorsque une association SCTP a bien été établie, la SCTP va envoyer une primitive de notification SCTP-COMMUNICATION_UP à la couche SUA locale. À l'ASP ou IPSP qui a initié la demande, la couche SUA va envoyer une primitive de confirmation M-SCTP_ESTABLISH à la gestion de couche lorsque l'établissement de l'association est achevé. À la couche SUA homologue, une primitive d'indication M-SCTP_ESTABLISH est envoyée à la gestion de couche dès l'achèvement réussi d'un établissement d'association SCTP entrante.


Une primitive de demande M-SCTP_RELEASE de la gestion de couche initie la fermeture d'une association SCTP. La couche SUA réalise 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 SUA locale. À la couche SUA qui a initié la demande, la couche SUA va envoyer une primitive de confirmation M-SCTP_RELEASE à la gestion de couche à l'achèvement de la fermeture de l'association. À la couche SUA homologue, une primitive d'indication M-SCTP_RELEASE est envoyée à la gestion de couche lors de l'interruption ou de la réussite de la fermeture d'une association SCTP.


Une primitive de demande M-SCTP_STATUS prend en charge l'interrogation par la gestion de couche de l'état local d'une association SCTP particulière. La couche SUA transpose simplement la primitive de demande M-SCTP_STATUS en une primitive SCTP-STATUS à la couche SCTP. Lorsque SCTP répond, la couche SUA 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 primitives de LM à SUA à SCTP et/ou de SCTP à SUA à LM peuvent être décrites pour les diverses autres primitives de couche supérieure SCTP dans la [RFC2960] comme INITIALIZE, SET PRIMARY, CHANGE HEARTBEAT, REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD, SET PROTOCOL PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, et NETWORK STATUS CHANGE. Autrement, ces primitives de couche supérieure SCTP (et aussi l'état) peuvent être prises en compte pour des besoins de modélisation comme une interaction de gestion de couche directement avec la couche SCTP.


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


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


Les primitives de demande M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE et M-ASP_INACTIVE permettent à la gestion de couche à un ASP d'initier des changements d'état. À l'achèvement réussi, une primitive de confirmation correspondante est fournie par la couche SUA à la gestion de couche. Si une invocation est infructueuse, une primitive d'indication Error est fournie dans la primitive. Ces demandes résultent en les messages sortants ASP Up, ASP Down, ASP Active et ASP Inactive à l'homologue SUA distant à un SGP ou IPSP.


4.2.1 Réception des messages de gestion d'homologues SUA

Lors de changements d'états réussis résultant de la réception de messages ASP Up, ASP Down, ASP Active et ASP Inactive d'une SUA homologue, la couche SUA PEUT invoquer les primitives d'indication M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE et M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, et M-AS_DOWN correspondantes à la gestion de couche locale.


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


Tous les messages non transfert et non SSNM, sauf BEAT et BEAT Ack, DEVRAIENT être envoyés avec une livraison en séquence pour assurer leur ordre. Tous les messages non transfert, à l'exception des messages ASPTM, BEAT et BEAT Ack DEVRAIENT être envoyés sur le flux SCTP '0'. Les messages ASPTM PEUVENT être envoyés sur un des flux utilisés pour porter le trafic de données relatif au ou aux contextes d'acheminement, pour minimiser les possibles pertes de message. Les messages BEAT et BEAT Ack PEUVENT être envoyés en utilisant une livraison sans ordre, et PEUVENT être envoyés sur n'importe quel flux.


4.3 Maintenance d'état d'AS et d'ASP

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


Deux modèles d'IPSP sont définis à l'égard du nombre de messages nécessaires pour un changement d'état d'IPSP. Ils sont définis comme suit :


1. Modèle d'IPSP à un seul échange (SE, Single Exchange). Un seul échange de messages ASPTM ou ASPSM est nécessaire pour changer l'état d'IPSP. Cela signifie qu'un ensemble d'une demande d'une extrémité et un accusé de réception de l'autre suffira.


2. Modèle d'IPSP à double échange (DE, Double Exchange). Les deux IPSP doivent envoyer des messages de demande et les deux IPSP doivent accuser réception des messages de demande provenant de l'autre extrémité. Il en résulte un double échange de messages ASPTM et ASPSM, un de chaque extrémité. Cette configuration accepte des configurations dynamiques de clés d'acheminement en utilisant des messages RKM de la même façon que dans les scénarios ASP-SGP.


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


Au paragraphe 4.3.1 "États d'ASP/IPSP", seuls les scénarios SGP-ASP et IPSP SE sont décrits. Pour le modèle IPSP DE, les deux IPSP DOIVENT suivre le côté SGP de la procédure SGP-ASP.


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


Au paragraphe 4.3.3, seul le scénario des procédures de gestion pour le SGP-ASP est décrit. Les procédures de gestion correspondantes pour les IPSP sont déduites directement.


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


4.3.1 États d'ASP

L'état de chaque ASP/IPSP distant, dans chaque AS qui est configuré à fonctionner, est conservé dans la couche SUA homologue (c'est-à-dire respectivement, dans le SGP ou IPSP homologue). L'état d'un ASP/IPSP particulier dans un certain AS change à cause d'événements. Ces événements incluent :

* la réception de messages de la couche SUA homologue à l'ASP/IPSP ;

* la réception de certains messages de la couche SUA homologue à d'autres ASP/IPSP dans l'AS (par exemple, message ASP Active indiquant "Outrepasser") ;

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

* l'intervention de la gestion locale.


Le diagramme de transition d'état d'ASP/IPSP est présenté à la Figure 1. Les états possibles d'un ASP/IPSP sont :

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

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

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


Figure 1 : Diagramme de transition d'état d'ASP/IPSP, par AS


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

| |

+----------------------| ASP-ACTIVE |

| Autres ASP/ +-------| |

| IPSP dans AS | +--------------+

| Outrepasse | ^ |

| | ASPAC/ | | ASPIA/

| |[ASPAC-Ack]| | [ASPIA-Ack]

| | | v

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

| | | |

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

| | |

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

| ^ |

ASPDN/ | | | ASPDN /

[ASPDN-Ack/]| ASPUP/ | | [ASPDN-Ack /]

SCTP CDI/ | [ASPUP-Ack] | | SCTP CDI/

SCTP RI | | | SCTP RI

| | v

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

| | |

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

| |

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


Les transitions entre crochets sont seulement valides pour la communication au modèle IPSP SE tandis que le reste est valide pour les ASP et les IPSP.


SCTP CDI : Le SCTP CDI note l'indication d'arrêt de communication (CDI, Communication Down Indication) de la couche SCTP locale au protocole de couche supérieure (SUA) sur un SGP. La couche locale SCTP va envoyer cette indication quand elle détecte la perte de connexité avec la couche SCTP homologue de l'ASP. SCTP CDI se comprend comme une notification SHUTDOWN_COMPLETE ou comme une notification COMMUNICATION_LOST de la couche SCTP.


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


4.3.2 États d'AS

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

* les transitions d'état d'ASP

* les déclenchements de temporisateur de récupération.


Les états possibles d'un AS sont :

AS-DOWN : Le serveur d'application est indisponible. Cet état implique que tous les ASP en rapport sont dans l'état ASP-DOWN pour cet AS. Initialement, l'AS sera dans cet état. Un serveur d'application est 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 dans l'état ASP-ACTIVE). Le temporisateur de récupération T(r) ne cours pas ou est arrivé à expiration.

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

AS-PENDING : Un ASP actif est passé à l'état ASP-INACTIVE ou ASP-DOWN et c'é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 devient ASP-ACTIVE avant l'arrivée à expiration de T(r), l'AS passe à l'état AS-ACTIVE et tous les messages en file d'attente vont être envoyés à l'ASP.

Si T(r) expire avant qu'un ASP devienne ASP-ACTIVE, et si le SGP n'a pas de solution de remplacement, le SGP peut arrêter de mettre les messages en file d'attente et éliminer tous les messages mis précédemment en file d'attente. L'AS va passer à l'état AS-INACTIVE si au moins un ASP est dans l'état ASP-INACTIVE, autrement, il va passer à l'état AS-DOWN.

La Figure 2 donne un exemple d'automate à états d'AS pour le cas où des données d'AS/ASP sont provisionnées. Pour les autres cas où les données de configuration d'AS/ASP sont crées de façon dynamique, il y aurait des différences dans l'automate à états, en particulier à la création de l'AS.

Par exemple, si les données de configuration d'AS/ASP ne sont pas créées avant l'enregistrement du premier ASP, l'état AS-INACTIVE est pris directement au premier REG REQ réussi d'un ASP. Un autre exemple est celui où les données de configuration d'AS/ASP ne sont pas créées avant que le premier ASP réussisse à entrer dans l'état ASP-ACTIVE. Dans ce cas, l'état AS-ACTIVE est pris directement.


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


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

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

| INACTIVE | | ACTIVE |

| |<--- | |

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

^ | \ Expiration de Tr, ^ |

| | \ au moins un | |

| | \ ASP en ASP-INACTIVE | |

| | \ | |

| | \ | |

| | \ | |

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

passe à | | ASP passent \ passe à | | actif passe à

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

INACTIVE| | \ ACTIVE | | ou ASP-DOWN

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

| | \ | |

| v \ | v

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

| | --| |

| AS-DOWN | | AS-PENDING |

| | |(mise en file|

| |<---------------------------| d'attente) |

+----------+ Expiration de Tr et pas +-------------+

d'ASP dans l'état ASP-INACTIVE


Tr = Temporisateur de récupération


4.3.2.1 Considérations sur IPSP

Le diagramme d'état d'AS pour le cas AS-SG est applicable à la communication IPSP.


4.3.3 Procédures de gestion de SUA pour les primitives

Avant l'établissement d'une association SCTP, on suppose que l'état d'ASP au SGP et à l'ASP est ASP-DOWN.


Une fois l'association SCTP établie (voir le paragraphe 4.2.1) et en supposant que l'utilisateur SUA local est prêt, la fonction locale SUA 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 porter l'état d'ASP au SGP (voir le paragraphe 4.3.4).


Si la couche SUA reçoit ensuite une primitive d'indication SCTP-COMMUNICATION_DOWN ou SCTP-RESTART de la couche SCTP sous-jacente, elle va informer la gestion de couche en invoquant la primitive d'indication M-SCTP_STATUS. L'état de l'ASP va passer à ASP-DOWN.

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 SUA, ou la gestion de couche PEUT rétablir en utilisant la primitive de demande M-SCTP_ESTABLISH.


Dans le cas d'une indication SCTP-RESTART à un ASP, l'ASP est maintenant considéré par son homologue SUA comme étant dans l'état ASP-DOWN. Si l'ASP doit récupérer, il doit commencer par la procédure ASP-Up.


4.3.4 Procédures ASPM pour messages d'homologue à homologue

4.3.4.1 Procédures d'activation d'ASP

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


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


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


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


À l'ASP, le message ASP Up Ack reçu n'est pas acquitté. La gestion de couche est informée par 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), il PEUT relancer T(ack) et renvoyer des messages ASP Up jusqu'à ce qu'il reçoive un message ASP Up Ack. T(ack) est provisionné avec une durée par défaut de 2 secondes. Autrement, la retransmission des messages ASP Up PEUT être mise sous le contrôle de la gestion de couche. Dans cette méthode, l'expiration de T(ack) résulte en une primitive de confirmation M-ASP_UP qui porte une indication négative.


L'ASP doit attendre le message ASP Up Ack avant d'envoyer d'autres messages sur la SUA (par exemple, ASP Active ou REG REQ). Si le SGP reçoit d'autres messages de SUA avant la réception d'un message ASPUP (autre que ASPDN – voir au paragraphe 4.3.4.2), le SGP DEVRAIT les éliminer.


Si un message ASP Up est reçu et qu'en interne l'ASP distant est dans l'état ASP-ACTIVE, un message ASP Up Ack est retourné, ainsi qu'un message d'erreur ("Message inattendu) et l'état de l'ASP distant passe à ASP-INACTIVE dans tous les serveurs d'application pertinents.


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


4.3.4.1.1 Contrôle de version SUA

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


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 nouvelle version devrait accepter les versions plus anciennes utilisées sur les autres nœuds avec lesquels il communique. Comme les ASP sont supposés initier la procédure ASP Up, on suppose que le message d'erreur va normalement venir du SGP.


4.3.4.1.2 Considérations d'IPSP

Un IPSP peut être considéré être dans l'état ASP-INACTIVE après qu'un ASPUP ou un ASPUP Ack a été reçu de lui. Un IPSP peut être considéré être dans l'état ASP-DOWN après qu'un ASPDN ou ASPDN Ack a été reçu de lui. L'IPSP peut informer la gestion de couche du changement d'état de l'IPSP distant en utilisant les primitives d'indication ou de confirmation M-ASP_UP ou M-ASP_DN.


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


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


4.3.4.2 Procédures de désactivation d'ASP

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


Le retrait permanent de l'ASP de tout AS est une fonction de la gestion de configuration. Dans le cas où l'ASP a utilisé précédemment les procédures d'enregistrement (voir au paragraphe 4.4.1) pour s'enregistrer auprès du serveur d'applications mais ne s'est pas désenregistré de tous avant d'envoyer le message ASP Down, le SGP DOIT considérer l'ASP comme désenregistré de tous les serveurs d'applications dont il est encore membre.


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


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


À l'ASP, le message ASP Down Ack reçu n'est pas acquitté. La gestion de couche est informée par une primitive de confirmation M-ASP_DOWN. Si l'ASP reçoit un ASP Down Ack sans avoir envoyé un message ASP Down, l'ASP devrait maintenant se considérer comme étant dans l'état ASP-DOWN. Si l'ASP était précédemment dans l'état ASP-ACTIVE ou ASP_INACTIVE, l'ASP devrait alors initier les procédures pour retourner dans son é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 de T(ack), il PEUT relancer T(ack) et renvoyer des messages ASP Down jusqu'à ce qu'il reçoive un message ASP Down Ack. T(ack) est provisionné avec une valeur par défaut de 2 secondes. Autrement, les retransmissions du message ASP Down PEUVENT être mises sous le contrôle de la gestion de couche. Dans cette méthode, l'expiration de T(ack) résulte en une primitive de confirmation M-ASP_DOWN portant une indication négative.


4.3.4.3 Procédures de ASP Active

À tout moment après que l'ASP a reçu un message ASP Up Ack du SGP ou de l'IPSP, l'ASP PEUT envoyer un message ASP Active au SGP indiquant que l'ASP est prêt à commencer le traitement du trafic. Cette action PEUT être initiée à l'ASP par une primitive de demande M-ASP_ACTIVE provenant de la gestion de couche ou PEUT être initiée automatiquement par une fonction de gestion SUA. Dans le cas où un ASP souhaite traiter le trafic pour 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 contextes d'acheminement pour indiquer pour quels serveurs d'application s'applique le message ASP Active. Il n'est pas nécessaire que l'ASP inclue tous les contextes d'acheminement qui intéressent un seul message ASP Active, demandant donc de devenir actif dans tous les contextes d'acheminement au même moment. Plusieurs messages ASP Active PEUVENT être utilisés pour s'activer indépendamment au sein des serveurs d'applications, ou par ensembles. Dans le cas où un message ASP Active ne contient pas de paramètre Contexte d'acheminement, le receveur doit savoir, via les données de configuration, de quels serveurs d'applications l'ASP est membre.


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


Plusieurs messages ASP Active Ack PEUVENT être utilisés en réponse à un message ASP Active qui contient plusieurs contextes d'acheminement, permettant au SGP ou IPSP d'accuser réception indépendamment du message ASP Active pour les différents (ensembles de) contextes d'acheminement. Le SGP ou l'IPSP DOIT envoyer un message Error ("Contexte d'acheminement invalide") pour chaque valeur de contexte d'acheminement qui ne peut réussir à être activé.


Dans le cas où un message ASP Active "sortie de nulle part" est reçu (c'est-à-dire, l'ASP ne s'est pas enregistre auprès de la SG ou 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 ASP Active Ack 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 ASP Active Ack reçu n'est pas acquitté. La gestion de couche est informée par une primitive de confirmation M-ASP_ACTIVE. Il est possible que l'ASP reçoive un ou des messages Données avant le message ASP Active Ack car les messages ASP Active Ack et Données d'une SG ou IPSP peuvent être envoyés sur des flux SCTP différents. La perte de message est possible, car l'ASP ne se considère pas comme étant dans l'état ASP-ACTIVE jusqu'à la réception du message ASP Active Ack.


Lorsque l'ASP envoie un message ASP Active, il lance le temporisateur T(ack). Si l'ASP ne reçoit pas de 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 ASP Active Ack. T(ack) est provisionné avec une valeur par défaut de 2 secondes. Autrement, les retransmissions du message ASP Active PEUVENT être mises sous le contrôle de la gestion de couche. Dans cette méthode, l'expiration de T(ack) résulte en une primitive de confirmation M-ASP_ACTIVE qui porte une indication négative.


Il y a trois modes de traitement du trafic par les serveurs d'application dans la couche SUA du SGP : outrepasser (Override), partage de charge (Loadshare) 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 ("Mode de traitement du trafic non accepté/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 a causé la transition d'état du serveur d'application à AS-ACTIVE PEUT alors être utilisé pour régler le mode.


Dans le cas d'un AS en mode Outrepasser, la réception d'un message ASP Active au 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 du SGP au sein de l'AS. Le SGP ou IPSP DOIT alors envoyer un message Notify ("Autre ASP actif") à l'ASP précédemment actif dans l'AS, et DEVRAIT arrêter le trafic de/vers cet ASP. L'ASP qui reçoit ce Notify DOIT se considérer maintenant comme étant dans l'état ASP-INACTIVE, si il n'en est pas averti via la communication inter-ASP avec l'ASP qui outrepasse.


Dans le cas d'un AS en mode de partage de charge, la réception d'un message ASP Active à un SGP ou IPSP cause la direction 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 charge du trafic au SGP au sein d'un AS à tous les ASP actifs dépend de la mise en œuvre. L'algorithme pourrait, par exemple, être un round robin ou se fonder sur les informations du message Data (par exemple, le SLS ou SSN).


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


Tous les ASP au sein d' AS en mode partage de charge doivent être capables de traiter tout message Data reçu pour l'AS, pour s'accommoder de tout repli potentiel ou de rééquilibrage de la charge offerte.


Dans le cas d'un AS en mode Diffusion, la réception d'un message ASP Active à un SGP ou IPSP cause la direction 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 au SGP pour la diffusion du trafic au sein d'un AS sur tous les ASP actifs est un simple algorithme de diffusion, où tout message est envoyé à chacun des ASP actifs. Un SGP ou IPSP, à réception d'un message ASP Active pour le premier ASP dans un AS Broadcast, PEUT choisir de ne pas diriger le trafic sur un ASP nouvellement actif jusqu'à ce qu'il détermine qu'il y a des ressources suffisantes pour traiter la charge attendue (par exemple, jusqu'à ce qu'il y ait "n" ASP dans l'état ASP-ACTIVE dans l'AS).


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


4.3.4.3.1 Considérations d'IPSP

Chacun des IPSP peut initier la communication. Lorsque un IPSP reçoit un message ASP Active, il devrait marquer l'homologue comme ASP-ACTIVE et retourner un message ASP Active Ack. Un ASP qui reçoit un message ASP Active Ack peut marquer l'homologue comme ASP-Active, si il n'est pas déjà dans l'état ASP-ACTIVE.


Autrement, lorsque on utilise le modèle IPSP DE, un échange de messages ASP Active de chaque extrémité DOIT être effectué. Quatre messages sont nécessaires pour le réaliser.


4.3.4.4 Procédures d'ASP inactif

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


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

- Si la clé d'acheminement correspondante est enregistrée (de façon statique ou dynamique) l'homologue devrait répondre par un message ASP Inactive Ack.

- Si la clé d'acheminement n'est pas enregistrée, ou si les informations de contexte d'acheminement ne sont pas valides, l'homologue doit répondre par un message ERROR avec le code d'erreur de "Contexte d'acheminement invalide".

- Si le contexte d'acheminement manque et si sa spécification est nécessaire selon la configuration utilisée, l'homologue doit répondre par un message d'erreur avec le code d'erreur de "Pas d'AS configuré pour l'ASP".


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


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


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


Dans le cas d'un AS en mode Partage de charge, le SGP passe l'ASP à l'état ASP-INACTIVE et le trafic de l'AS est réalloué à travers les ASP restants dans l'état ASP-ACTIVE, selon l'algorithme de partage de charge actuellement utilisé au sein de l'AS. Un message Notify ("Ressources d'ASP actif insuffisantes dans l'AS") PEUT être envoyé à tous les ASP inactifs, si nécessaire. Un message ASP Inactive Ack est envoyé à l'ASP après que tout le trafic est arrêté et la gestion de couche est informée 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 est diffusé seulement aux ASP restants dans l'état ASP-ACTIVE. Un message Notify ("Ressources d'ASP actif insuffisantes dans l'AS") PEUT être envoyé à tous les ASP inactifs, si nécessaire. Un message ASP Inactive Ack est envoyé à l'ASP après que tout le trafic est arrêté et la gestion de couche est informée par une primitive d'indication M-ASP_INACTIVE.


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


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


À l'ASP, le message ASP Inactive Ack reçu n'est pas acquitté. La gestion de couche est informée par une primitive de confirmation M-ASP_INACTIVE. Si l'ASP reçoit un ASP Inactive Ack sans avoir envoyé de message ASP Inactive, l'ASP devrait alors se considérer comme étant dans l'état ASP-INACTIVE. Si l'ASP était précédemment dans l'état ASP-ACTIVE, il devrait alors initier les procédures pour revenir à son état précédent. Lorsque l'ASP envoie un message ASP Inactive, il lance le temporisateur T(ack). Si l'ASP ne reçoit pas de réponse à un message ASP Inactive dans le délai de T(ack), il PEUT relancer T(ack) et renvoyer des messages ASP Inactive jusqu'à ce qu'il reçoive un message ASP Inactive Ack. T(ack) est provisionné par défaut à 2 secondes. Autrement, les retransmissions de messages ASP Inactive PEUVENT être mises sous le contrôle de la gestion de couche. Dans cette méthode, l'expiration de T(ack) résulte en une primitive de confirmation M-ASP_Inactive portant une indication négative.


Si aucun autre ASP dans le serveur d'application n'est dans l'état ASP-ACTIVE, le SGP DOIT envoyer un message Notify ("AS en cours") à 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 Active d'un ASP de l'AS avant l'expiration de T(r), le trafic en mémoire tampon est dirigé sur cet ASP et le temporisateur est annulé. Si T(r) arrive à expiration, l'AS est passé à l'état AS-INACTIVE.


4.3.4.4.1 Considérations d'IPSP

Un IPSP peut être considéré être dans l'état ASP-INACTIVE par un IPSP distant après qu'un message ASP Inactive ou ASP Inactive Ack a été reçu de lui.


Autrement, dans le modèle IPSP DE, un échange de messages ASP Inactive provenant de chaque extrémité DOIT être effectué. Quatre messages sont nécessaires pour ce faire.


4.3.4.5 Procédures de Notify

Un message Notify qui reflète un changement d'é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 tous les identifiants d'ASP de l'ASP en échec. À l'ASP, la gestion de couche est informée avec une primitive d'indication M-NOTIFY. Le message Notify doit être envoyé que le changement de l'état de l'AS ait été le résultat d'un échec de l'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 Notify DOIT être envoyé après tout message d'accusé de réception relatif à l'état d'ASP ou à la gestion de trafic (par exemple, ASP Up Ack, ASP Down Ack, ASP Active Ack, ou ASP Inactive Ack).


Dans le cas où un message Notify ("AS-PENDING") est envoyé par un SGP qui n'a actuellement aucun ASP actif pour desservir le trafic, ou qu'un message Notify ("Ressources d'ASP actif insuffisantes dans l'AS") DOIT être envoyé dans le mode partage de charge ou diffusion, le message Notify n'oblige pas explicitement le ou les ASP qui reçoivent le message à devenir actifs. Les ASP restent au contrôle de l'action de trafic à prendre et quand elle doit l'être.


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


4.3.4.5.1 Considérations d'IPSP (NTFY)

Notify fonctionne de la même manière que dans le cas de SG-AS. Un des IPSP peut envoyer ce message à tout IPSP distant qui n'est pas dans l'état ASP-DOWN.


4.3.4.6 Procédures de Heartbeat

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


L'un ou l'autre des homologues SUA peut facultativement envoyer périodiquement des messages Heartbeat, sous réserve du provisionnement d'un temporisateur T(beat). À réception d'un message Heartbeat, l'homologue SUA DOIT répondre par un message Heartbeat Ack.


Si aucun message Heartbeat Ack (ou tout autre message SUA) n'est reçu de l'homologue SUA dans les 2*T(beat), l'homologue SUA distant est considéré comme indisponible. La transmission des messages Heartbeat est arrêtée et le processus de signalisation DEVRAIT tenter de rétablir la communication si il est configuré comme client pour l'homologue SUA déconnecté.


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


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


4.4 Procédures de gestion de clé d'acheminement

4.4.1 Enregistrement

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


Le SGP examine le contenu du paramètre Clé d'acheminement reçu et le compare aux clés d'acheminement actuellement provisionnées. Si la clé d'acheminement reçue correspond à une entrée existante de clé d'acheminement SGP, et si l'ASP n'est pas actuellement inclus dans la liste des ASP pour le serveur d'application concerné, le SGP PEUT autoriser l'ajout de l'ASP à l'AS. Ou, si la clé d'acheminement n'existe actuellement pas et si les données de la clé d'acheminement reçue sont valides et uniques, un SGP qui accepte la configuration dynamique PEUT autoriser la création d'une nouvelle clé d'acheminement et du serveur d'application qui s"y rapporte 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 local de clé d'enregistrement que fourni dans la demande initiale, et un résultat d'enregistrement "Enregistré avec succès". Y est incluse une valeur unique de contexte d'acheminement allouée à la clé d'acheminement de SGP. La méthode d'allocation de la valeur de contexte d'acheminement au SGP dépend de la mise en œuvre mais son unicité doit être garantie pour chaque serveur d'application ou clé d'acheminement prise en charge par le SGP. Si le SGP détermine que les données reçues de clé d'acheminement sont invalides, ou contiennent des valeurs de paramètres invalides, le SGP retourne un message Réponse d'enregistrement à l'ASP, contenant un Résultat d'enregistrement "Erreur - clé d'acheminement invalide", "Erreur – DPC invalide", "Erreur – apparence de réseau invalide" comme approprié.


Si le SGP n'accepte pas la procédure d'enregistrement, le SGP retourne un message d'erreur à l'ASP, avec un code d'erreur de "type de message non accepté".


Si le SGP détermine qu'on ne peut pas créer une clé d'acheminement unique, le SGP retourne un message Réponse d'enregistrement à l'ASP, avec un état d'enregistrement de "Erreur – ne peut pas prendre en charge l'acheminement unique". Un message de signalisation entrant reçu à un SGP ne devrait pas correspondre à plus d'une clé d'acheminement.


Si le SGP n'autorise pas la demande d'enregistrement, le SGP retourne un message REG RSP à l'ASP qui contient le résultat d'enregistrement "Erreur - permission refusée".


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


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


Si un SGP détermine qu'un ou plusieurs des paramètres de clé d'acheminement ne sont pas acceptés pour les besoins de la création de nouvelles entrées de clé d'acheminement, le SGP retourne un message Réponse d'enregistrement à l'ASP, contenant un résultat d'enregistrement "Erreur – champ Paramètre de clé d'acheminement non accepté". Ce résultat PEUT être utilisé si, par exemple, le SGP ne prend pas en charge le paramètre Adresse de clé d'acheminement.


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


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


Un ASP PEUT modifier une clé d'acheminement existante en incluant un paramètre Contexte d'acheminement dans la REG REQ. Si le SGP détermine que le contexte d'acheminement d'applique à une clé d'acheminement existante, le SG PEUT ajuster la clé d'acheminement existante pour qu'elle corresponde aux nouvelles informations fournies dans le paramètre de clé d'acheminement. Une réponse d'enregistrement "Changement de clé d'acheminement refusé" est retournée si le SGP n'accepte par la modification de la clé d'acheminement.


Lors de l'enregistrement réussi d'un ASP dans un AS, le SGP peut maintenant envoyer de la messagerie de gestion de réseau de signalisation SS7 en rapport si cela n'avait pas commencé précédemment lors su passage de l'ASP à l'état ASP-INACTIVE.


4.4.2 Désenregistrement

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


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


La procédure de désenregistrement n'implique pas nécessairement la suppression des données de configuration de clé d'acheminement et de serveur d'application au SGP. D'autres ASP peuvent continuer d'être associés au serveur d'application, et dans ce cas les données de clé d'acheminement NE DEVRAIENT PAS être supprimées. Si un résultat de 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é d'acheminement.


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


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


4.4.3 Considérations d'IPSP (REG/DEREG)

Les procédures d'enregistrement/désenregistrement fonctionnent dans les cas d'IPSP de la même façon que dans les cas d'AS-SG. Un IPSP peut enregistrer une RK dans l'IPSP distant. Un IPSP est responsable du désenregistrement des RK qu'il a enregistrées.


4.5 État de disponibilité et/ou d'encombrement du SS7 Destination Support

4.5.1 À un SGP

À réception d'une primitive d'indication N-STATE, N-PCSTATE et N-INFORM de la fonction nodale d'interfonctionnement à un SGP, la couche SUA du SGP va envoyer un message correspondant de gestion de réseau de signalisation (SNM, Signalling Network Management) SS7 DUNA, DAVA, SCON, ou DUPU (voir au paragraphe 3.4) aux homologues SUA aux ASP concernés. La couche SUA doit remplir de façon cohérente divers champs des messages SNM par rapport aux informations reçues dans les primitives.


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


Les messages DUNA, DAVA, SCON, et DRST sont envoyés en séquence et traités au receveur dans l'ordre d'envoi. Le flux SCTP 0 NE DEVRAIT PAS être utilisé. Le bit U (Unordered, sans ordre) dans le tronçon SCTP DATA PEUT être utilisé pour le message SCON.


Le séquençage n'est pas exigé pour les messages DUPU ou DAUD, qui PEUVENT être envoyés sans ordre. Le flux SCTP 0 est utilisé, avec l'usage facultatif du bit Unordered dans le tronçon SCTP DATA.


4.5.2 À un ASP

4.5.2.1 Configurations à une seule SG

À un ASP, à réception d'un message de gestion de réseau de signalisation SS7 (SSNM, SS7 Signalling Network Management) provenant de l'homologue SUA distante, la couche SUA invoque les primitives d'indication appropriées pour la SUA-usagers résidente. La gestion locale est informée.


Dans le cas où un événement local a causé l'état d'indisponibilité ou d'encombrement des destinations SS7, la couche SUA à l'ASP DEVRAIT passer les indications appropriées dans les primitives à l'utilisateur SUA, bien que des messages SSNM équivalents aient été reçus. Par exemple, la perte d'une association SCTP à un SGP peut causer l'indisponibilité d'un ensemble de destinations SS7. Les primitives d'indication N-PCSTATE à l'utilisateur SUA sont appropriées.


Note de mise en œuvre : pour accomplir cela, la couche SUA à un ASP tient l'état des chemins via la SG.


4.5.2.2 Configurations à plusieurs SG

À un ASP, à réception d'un message de gestion de réseau de signalisation provenant de l'homologue SUA distante, la couche SUA met à jour l'état du ou des chemins affectés via la SG d'origine et détermine si la disponibilité globale ou l'état d'encombrement de la ou des destinations affectées a ou non changé. Si c'est le cas, la couche SUA invoque les primitives d'indication appropriées aux usagers de SUA résidents. La gestion locale est informée.


4.5.3 Audit d'ASP

Un ASP peut facultativement initier une procédure d'audit pour enquêter sur la disponibilité d'un SGP et, si on utilise la méthode nationale d'encombrement avec plusieurs niveaux d'encombrement et des priorités de message, l'état d'encombrement d'une destination ou ensemble de destinations SS7. Un message Audit de destination (DAUD, Destination Audit) est envoyé de l'ASP au SGP qui demande l'état actuel de disponibilité et d'encombrement de une ou plusieurs destinations ou sous systèmes SS7.


Le message DAUD PEUT être envoyé sans ordre. L'ASP PEUT envoyer le DAUD dans les cas suivants :


- Périodique : un temporisateur établi à l'origine à réception d'un message DUNA, SCON ou DRST est arrivé à expiration sans qu'un message ultérieur DAVA, DUNA, SCON ou DRST mette à jour l'état de disponibilité/encombrement du codet Destination affectée. Le temporisateur est rétabli à la production d'un DAUD. Dans ce cas, le DAUD est envoyé au SGP qui a à l'origine envoyé le message SSNM.


- Isolation : l'ASP vient de passer à ASP-ACTIVE ou a été isolé d'un SGP pendant un délai significatif. L'ASP PEUT demander l'état de disponibilité/encombrement d'une ou plusieurs destinations SS7 auxquelles il s'attend à communiquer.


Note de mise en œuvre : dans le premier des cas ci-dessus, la procédure d'audit ne doit pas être invoquée pour le cas de la réception d'un message SCON contenant une valeur de niveau d'encombrement de "pas d'encombrement" ou "indéfini" (c'est-à-dire, niveau d'encombrement = "0"). Cela parce que la valeur indique soit une diminution d'encombrement , soit que la méthode d'encombrement internationale MTP3 de l'UIT est utilisée. Dans la méthode internationale d'encombrement, la couche MTP3 au SGP ne conserve l'état d'encombrement d'aucune destination et donc le SGP ne peut pas fournir d'informations d'encombrement en réponse au DAUD. Pour la même raison, dans le second des cas ci-dessus, un message DAUD ne peut pas révéler les destinations encombrées.


Le SGP DEVRAIT répondre à un message DAUD par l'état de disponibilité et d'encombrement du sous système. L'état de chaque destination ou sous système SS7 demandé est indiqué dans un message DUNA (si indisponible), un message DAVA (si disponible), ou DRST (si interdit et si le SGP prend ce dispositif en charge). Si la destination ou sous système SS7 est disponible et encombré, le SGP répond par un message SCON en plus du message DAVA. Si la destination ou sous système SS7 est interdit et encombré, le SGP répond par un message SCON en plus du DRST. Si le SGP n'a pas d'information sur l'état de disponibilité/encombrement de la destination ou sous système SS7, le SGP répond par un message DUNA, car il n'a pas d'information d'acheminement pour lui permettre d'acheminer le trafic à sa destination ou sous système.


Un SG PEUT refuser de fournir l'état de disponibilité ou encombrement d'une destination ou sous système si, par exemple, l'ASP n'est pas autorisé à connaître l'état de la destination ou sous système. La SG PEUT répondre par un message d'erreur "État de destination inconnu" ou le code d'erreur "État de sous système inconnu".


4.6 Redémarrage MTP3

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


Lorsque la SG découvre l'isolation du réseau SS7, elle envoie une indication à tous les ASP disponibles concernés (c'est-à-dire, les ASP dans l'état ASP-ACTIVE) en utilisant des messages DUNA pour les destinations concernées. Lorsque la SG a achevé la procédure de redémarrage MTP, la couche SUA aux SGP informe tous les ASP concernés dans l'état ASP-ACTIVE de toute destination SS7 disponible/interdite en utilisant le message DAVA/DRST. Aucun message n'est nécessaire pour les destinations qui sont encore indisponibles après la procédure de redémarrage.


Lorsque la couche SUA à un ASP reçoit un message DUNA qui indique l'indisponibilité d'une destination SS7 à une SG, les utilisateurs SCCP vont recevoir une indication N-PCSTATE et vont arrêter tout trafic affecté à cette destination. Lorsque la SUA reçoit un message DAVA/DRST, les utilisateurs SCCP vont recevoir une indication N-PCSTATE et peuvent reprendre le trafic pour la destination SS7 nouvellement disponible via cette SGP, pourvu que l'ASP soit dans l'état ASP-ACTIVE à l'égard de ce SGP.


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


4.7. Interfonctionnement SCCP - SUA à la SG

4.7.1 Segmentation / Réassemblage

Lorsque on s'attend à ce que les messages de signalisation ne tiennent pas dans une PDU des technologies de transport les plus restrictives utilisées (par exemple, 272-SIF de MTP3) la segmentation/réassemblement pourraient être effectué à la SG, l'ASP ou l'IPSP. Si la SG, l'ASP ou l'IPSP est incapable d'effectuer une segmentation/réassemblage nécessaire, il peut informer l'homologue de l'échec en utilisant l'erreur appropriée dans un message CLDR ou RESRE/COERR.


4.7.2 Prise en charge du partage de charge

Au sein d'un AS (identifié par les paramètres de RK/RC) plusieurs ASP en partage de charge peuvent être actifs.


Cependant, pour assurer le traitement correct des transactions TCAP ou des connexions SCCP, le schéma de partage de charge utilisé à la SG doit s'assurer que les messages qui continuent ou terminent les transactions/connexions arrivent à l'ASP d'où le message initial (TC_Query, TC_Begin, CR) a été envoyé/reçu.


Lorsque l'ASP peut être identifié de façon univoque sur la base des paramètres de RK (par exemple, DPC ou GT unique) le partage de charge n'est pas exigé. Lorsque les ASP de l'AS partagent l'état ou utilisent un mécanisme interne de distribution, la SG doit seulement prendre en compte l'exigence de livraison dans l'ordre (en séquence). En cas de trafic SCCP CO, lorsque on utilise l'approche couplée, le partage de charge des messages autres que CR n'est pas exigé.


Si ces hypothèses ne peuvent pas être faites, la SG et l'ASP devraient tous deux prendre en charge les procédures générales suivantes dans un environnement de partage de charge.


4.7.2.1 Établissement d'association, l'ASP devient actif

Après l'établissement et l'enregistrement d'une association, un ASP devient normalement actif pour chaque AS pour lequel il s'est enregistré. Dans le message ASPAC, l'ASP inclut un paramètre Étiquette de TID et/ou de DRN, si applicable pour l'AS en question. Tous les ASP au sein de l'AS doivent spécifier une étiquette unique à une certaine position fixe dans le paramètre TID ou DRN. Le même message ASPAC est envoyé à chaque SG utilisée pour inter fonctionner avec le réseau SS7.


La SG construit, par clé d'enregistrement, une liste des ASP qui se sont enregistrés pour elle. La SG peut maintenant construire et mettre à jour un tableau de distribution pour un certain contexte d'acheminement, chaque fois que l'association est établie (rétablie) et que l'ASP devient actif. La SG doit effectuer quelques vérifications triviales de plausibilité sur les paramètres :

- entre 0 et 31 pour TID,

- les valeurs des paramètres Début et Fin sont entre 0 et 23 pour DRN,

- 0 < (début - fin + 1) ≤ 16 (longueur maximum d'étiquette de 16 bits)

- les valeurs de début sont les mêmes pour chaque ASP au sein d'un contexte d'acheminement,

- les valeurs de fin sont les mêmes pour chaque ASP au sein d'un contexte d'acheminement,

- les valeurs d'étiquette TID et DRN doivent être uniques dans le contexte d'acheminement.


Si une de ces vérification échoue, la SG refuse la demande ASPAC, avec une erreur, "Étiquette de partage de charge invalide."


4.7.3 Acheminement et distribution de message à la SG

4.7.3.1 Trafic TCAP

Les messages qui ne contiennent pas de TID de destination (ou de "réponse"), c'est-à-dire, Query, Begin, Unidirectional, sont en charge partagée entre les ASP disponibles. Tout schéma qui permet une distribution de charge équitable entre les ASP est permis (par exemple, round robin).


Lorsque un TID de destination est présent, la SG extrait l'étiquette et choisit l'ASP qui y correspond.


Si un ASP n'est pas disponible, la SG peut générer un (X)UDTS "échec d'acheminement", si l'option de retour est utilisée.


4.7.3.2 Trafic SCCP en mode connexion

Les messages qui ne contiennent pas de numéro de référence de destination (DRN, destination reference number), c'est-à-dire, une demande de connexion, PEUVENT être en charge partagée entre les ASP disponibles. Le mécanisme de distribution de charge est une affaire de mise en œuvre. Lorsque un DRN est présent, la SG extrait l'étiquette et choisit l'ASP qui lui correspond. Si un ASP n'est pas disponible, la SG élimine le message.


4.7.4 SG multiples, fonction de relais de SUA

Il est important que chaque ASP envoie son étiquette unique (au sein de l'AS) à chaque SGP. Pour une meilleure robustesse contre les échecs d'association, les SG PEUVENT coopérer pour fournir des chemins de remplacement vers un ASP. Les mécanismes de coopération/coordination de SG sortent du domaine d'application du présent document.


5. Exemples de procédures SUA

Les diagrammes de séquences suivants donnent une vue d'ensemble des procédures de SUA. Ils sont donnés comme exemples, et n'imposent pas par eux-mêmes d'exigences supplémentaires aux instances de SUA.


5.1 Architecture de SG

Les séquences ci-dessous montrent les étapes logiques pour divers scénarios au sein de l'architecture de SG. Prière de noter que ces scénarios couvrent une configuration principale/de sauvegarde. Lorsque il y a une configuration de partage de charge, le SGP peut alors déclarer la disponibilité lorsque un ASP produit un ASPAC mais peut seulement déclarer l'indisponibilité lorsque tous les ASP ont produit l'ASPIA.


5.1.1 Établissement de la connexité de SUA

Ce qui suit est établi avant que le trafic puisse s'écouler.


Chaque nœud est configuré (via une MIB, par exemple) avec les connexions qui ont besoin d'être établies.


ASP-a1 ASP-a2 SG SEP

(Principal) (Sauvegarde)

|------Établit l'association SCTP------|

|--Étab. asso SCTP--|

|--Aligne liaisonSS7---|

+----------------ASP Up---------------->

<--------------ASP Up Ack--------------+

+------ASP Up------->

<---ASP Up Ack------+

+-------------ASP Active--------------->

<----------ASP Active Ack--------------+

<----------NTFY (ASP Active)-----------+

<-NTFY (ASP Active)-+

+--------SSA----------->

<--------SSA-----------+

<-----------------DAVA-----------------+

+-----------------CLDT----------------->

+--------UDT----------->


5.1.2. Scénarios de repli

Les séquences suivantes s'adressent au repli de SEP et ASP.


5.1.2.1 Repli SEP

Le SEP sait que le SGP est 'concerné' par la disponibilité. De même, le SGP sait qu'un ASP-a1 est concerné par la disponibilité des SEP.


ASP-a1 ASP-a2 SG SEP

(Principal) (Sauvegarde)

<--------SSP--------+

<-----------------DUNA-----------------+

+-----------------DAUD----------------->

+--------SST-------->


5.1.2.2 Scénario de repli d'ASP réussi

Voici un exemple de scénario de repli réussi, où il y a un repli de l'ASP-a1 à l'ASP-a2, c'est-à-dire, du principal à la sauvegarde. Durant le repli, le SGP met en mémoire tampon tous les messages de données entrants provenant du SEP, et les transmet lorsque la sauvegarde devient disponible.


ASP-a1 ASP-a2 SG SEP

(Principal) (Sauvegarde)

+-------------ASP Inactive------------->

<-----------ASP Inactive ACK-----------+

<--------------------NTFY (AS Pending)-+

<-NTFY (AS Pending)-+

+----ASP Active----->

<--ASP Active Ack---+

<-NTFY (AS Active)--+

<----------NTFY (AS Active)------------+



5.1.2.3 Scénario d'échec de repli d'ASP

ASP-a1 ASP-a2 SG SEP

(Principal) (Sauvegarde)

+-------------ASP Inactive------------->

<-----------ASP Inactive ACK-----------+

<--------------------NTFY (AS Pending)-+

<--NTFY (AS Pending)-+

Après l'écoulement d'un certain temps (c'est-à-dire, en fin de temporisation).

+--------SSP-------->

<--------SST--------+

<-------------------NTFY (AS Inactive)-+

<-NTFY (AS Inactive)-+


5.2 Exemples IPSP

Les séquences ci-dessous montrent les étapes logiques pour divers scénarios dans une architecture IP-IP. Prière de noter que ces scénarios couvrent une configuration de principal/sauvegarde. Lorsque il y a une configuration de partage de charge, l'AS peut alors déclarer la disponibilité lorsque un ASP produit un ASPAC mais peut seulement déclarer l'indisponibilité quand tous les ASP ont produit un ASPIA.


5.2.1 Établissement de la connexité SUA

Ce qui suit montre un exemple d'établissement de la connexité de SUA. Dans cet exemple, chaque IPSP consiste en un serveur d'application et deux ASP. Ce qui suit est établi avant que le trafic de SUA puisse s'écouler. Un flux sans connexion est montré pour plus de simplicité.

Établir la connexité SCTP – conformément à la RFC 2960. Noter que les connexions SCTP sont bidirectionnelles. Le point d'extrémité qui établit la connexité SCTP DOIT aussi établir la connexité UA (voir au paragraphe 5.2.1 de la [RFC2960] le traitement des collisions).


IP SEP A IP SEP B

AS A AS B

ASP-a1 ASP-a2 ASP-b2 ASP-b1

(Tous les ASP sont dans l'état ASP-DOWN)

+-------------------------------ASP Up-------------------------->

<-----------------------------ASP Up Ack------------------------+

+--------------ASP Up--------------->

<------------ASP Up Ack-------------+

+---------------------------ACTIVE------------------------------->

<-------------------------ACTIVE Ack-----------------------------+

(Le trafic peut maintenant s'écouler directement entre les ASP)

+-----------------------------CLDT------------------------------->


5.2.2 Scénarios de repli

Les séquences suivantes s'adressent au repli d'ASP.


5.2.2.1 Scénario réussi de repli d'ASP

Ce qui suit est un exemple de scénario réussi de repli, où il y a un repli de l'ASP-a1 sur ASP-a2, c'est-à-dire, du principal à la sauvegarde. Comme le transfert de données passe directement entre les ASP homologues, ASP-b1 est notifié du repli de ASP-a1 et met en mémoire tampon les messages de données sortants jusqu'à ce que ASP-a2 devienne disponible.


IP SEP A IP SEP B

ASP-a1 ASP-a2 ASP-b2 ASP-b1

+-----------------------------ASP Inact ------------------------>

<---------------------------ASP Inact Ack ----------------------+

<---------------NTFY (ASP-a1 Inactive)--------------+

+---------------------ASP Act----------------------->

<-------------------ASP Act Ack---------------------+


5.2.2.2 Scénario non réussi de repli d'ASP

La séquence est la même qu'au paragraphe 5.2.2.1 sauf que, comme le repli échoue à se faire, les messages Notify qui déclarent la disponibilité de la sauvegarde ne sont pas envoyés.


6. Considérations sur la sécurité


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


7. Considérations relatives à l'IANA

7.1 Identifiant de protocole de charge utile SCTP

L'IANA a alloué une valeur de SUA pour l'identifiant de protocole de charge utile dans le tronçon SCTP DATA. L'identifiant suivant de protocole de charge utile SCTP est enregistré : SUA "4"


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


L'homologue 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.


7.2 Numéro d'accès

L'IANA a enregistré le numéro d'accès SCTP 14001 pour SUA. Il est recommandé que les SGP utilisent ce numéro d'accès SCTP pour écouter les nouvelles connexions. Les SGP PEUVENT aussi utiliser à la place des numéros d'accès SCTP configurés de façon statique.


7.3 Extensions de protocole

Le présent protocole peut aussi être étendu par l'IANA de trois façons :

- par la définition de classes de message supplémentaires,

- par la définition de types de message supplémentaires,

- par la définition de paramètres de message supplémentaires.

La définition et l'utilisation de nouvelles classes, types et paramètres de messages 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 comme défini dans la [RFC2434]. L'extension proposée NE DOIT en aucune façon affecter le fonctionnement général du protocole.

Un nouveau registre a été créé par l'IANA pour permettre les extensions du protocole.


7.3.1 Classes de message définies par l'IETF

La documentation d'une nouvelle classe de messages DOIT inclure les informations suivantes :

(a) un nom long et un nom court pour la classe de messages ;

(b) une description détaillée de l'objet de la classe de messages.


7.3.2 Types de message définis par l'IETF

La documentation du type de messages DOIT contenir les informations suivantes :

(a) un nom long et un nom court pour le nouveau type de message ;

(b) une description détaillée de la structure du message,

(c) une définition et une description détaillées de l'utilisation prévue de chaque champ du message,

(d) une description détaillée des procédures d'utilisation du nouveau type de message au sein du fonctionnement du protocole,

(e) une description détaillée des conditions d'erreur à 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é.


7.3.4 Extension de paramètre de TLV définie par l'IETF

La documentation du paramètre de message DOIT contenir les informations suivantes :

(a) Nom du type de paramètre.

(b) Description détaillée de la structure du champ du paramètre. Cette structure DOIT se conformer au format général de type-longueur-valeur décrit plus haut dans le document.

(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 l'indication de si, et dans quelles circonstances, plusieurs instances de ce type de paramètre peuvent se trouver dans le même type de message.


8. Valeur des temporisateurs


Ta : 2 secondes

Tr : 2 secondes

T(ack) : 2 secondes

T(ias) temporisateur d'inactivité d'envoi : 7 minutes

T(iar) temporisateur d'inactivité de réception : 15 minutesT(beat) temporisateur de vie : 30 secondes


9. Remerciements

Les auteurs tiennent à remercier (par ordre alphabétique) Richard Adams, Javier Pastor-Balbas, Andrew Booth, Martin Booyens, F. Escobar, S. Furniss Klaus Gradischnig, Miguel A. Garcia, Marja-Liisa Hamalainen, Sherry Karl, S. Lorusso, Markus Maanoja, Sandeep Mahajan, Ken Morneault, Guy Mousseau, Chirayu Patel, Michael Purcell, W. Sully, Michael Tuexen, Al Varney, Tim Vetter, Antonio Villena, Ben Wilson, Michael Wright et James Yu pour leurs commentaires et suggestions.


10. Références

10.1 Références normatives


[RFC1123] R. Braden, éditeur, "Exigences pour les hôtes Internet – Application et prise en charge", STD 3, octobre 1989.


[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.


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


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


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


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


[ITU SCCP] Recommandations UIT-T Q.711-714, "Système de signalisation numéro 7 (SS7) – Sous système de connexion de signalisation (SCCP)". Genève (juillet 1996).


10.2 Références pour information


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


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


[RFC3761] P. Faltstrom, M. Mealling, "Application de E.164 au système de découverte dynamique de délégation (DDDS) d'identifiants de ressource uniformes (URI) (ENUM)", avril 2004. (P.S.) (Remplacée par la RFC6116)


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


[ITU TCAP] Recommandations UIT-T Q.771-775 "Système de signalisation numéro 7 – capacités de transaction (TCAP)".


[RANAP] 3G TS 25.413 V3.5.0 (2001-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; "UTRAN Iu Interface RANAP Signalling"


Appendice A Architecture de réseau de signalisation

A.1 Architecture de réseau d'homologue à homologue généralisé

La Figure 3 montre un exemple d'architecture de réseau qui peut prendre en charge un fonctionnement robuste et le repli. Il faut qu'il y ait des ressources de gestion à l'AS pour gérer le trafic.


***********

* AS1 *

* +-----+ * associations SCTP

* |ASP1 +-------------------+

* +-----+ * | ***********

* * | * AS3 *

* +-----+ * | * +-----+ *

* |ASP2 +-----------------------------------------+ASP1 | *

* +-----+ * | * +-----+ *

* * | * *

* +-----+ * | * +-----+ *

* |ASP3 | * +--------------------------+ASP2 | *

* +-----+ * | | * +-----+ *

*********** | | ***********

| |

*********** | | ***********

* AS2 * | | * AS4 *

* +-----+ * | | * +-----+ *

* |ASP1 +--------------+ +---------------------+ASP1 | *

* +-----+ * * +-----+ *

* * * *

* +-----+ * * +-----+ *

* |ASP2 +-----------------------------------------+ASP1 | *

* +-----+ * * +-----+ *

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

* +-----+ *

* |ASP3 | *

* +-----+ *

* *

***********

Figure 3: Architecture généralisée


Dans cet exemple, les serveurs d'applications qui sont montrés résident dans une boîte logique, avec les ASP à l'intérieur. En fait, un AS pourrait être réparti entre plusieurs hôtes. Dans un tel scénario, l'hôte devrait partager l'état pour se protéger en cas de défaillance. Ceci n'est pas l'objet du présent protocole. De plus, dans un système réparti, un ASP pourrait être enregistré auprès de plus d'un AS. Le présent document ne devrait pas interdire de tels systèmes – bien que ce cas ne soit pas spécifié.


A.2 Passerelle de signalisation Network Architecture

Lorsque l'inter fonctionnement entre SS7 et les domaines IP est nécessaire, le SGP agit comme nœud passerelle entre le réseau SS7 et le réseau IP. Le SGP va transporter le trafic de signalisation d'utilisateur SCCP du réseau SS7 aux nœuds de signalisation fondés sur IP (par exemple des bases de données résidentes sur IP). La passerelle de signalisation peut être considérée comme un groupe de serveurs d'applications avec des fonctionnalités supplémentaires d'interface avec un réseau SS7.


Le protocole de SUA devrait être assez souple pour permettre différentes configurations et technologies de transport permettant aux opérateurs de réseaux de satisfaire leurs exigences de fonctionnement, gestion et performances.


Un ASP peut être connecté à plusieurs SGP (figure 4). Dans ce cas, une destination SS7 particulière peut être joignable via plus d'une SG, donc plus d'une route. Étant donné que le choix approprié de SLS, le partage de charge, et le choix de la SG sur la base de la disponibilité du codet sont effectués à l'ASP, il sera nécessaire que l'ASP conserve l'état de chaque SGP distant avec lequel il communique sur la base de la SG à travers laquelle il peut acheminer.


Passerelle de signalisation

Associations SCTP

+----------+ **************

| SG1 | * AS3 *

| ******** | * ******** *

| * SGP11 +--------------------------------------------+ ASP1 * *

| ******** | / * ******** *

| ******** | | * ******** *

| * SGP12 +--------------------------------------------+ ASP2 * *

| ******** | \ / | * ******** *

+----------+ \ | | * . *

\ | | * . *

+----------+ \ | | * . *

| SG2 | \ | | * . *

| ******** | \ | | * ******** *

| * SGP21 +---------------------------------+-+ * * ASPN * *

| ******** | \ * ******** *

| ******** | \ **************

| * SGP22 +---+--+ \

| ******** | | | \ **************

+----------+ | | \ * AS4 *

| | \ * ******** *

| +-------------------------------------+ ASP1 * *

| * ******** *

| * . *

| * . *

| * *

| * ******** *

+----------------------------------------+ ASPn * *

* ******** *

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


Figure 4 : Architecture de passerelle de signalisation


La paire de SG peut fonctionner comme des points d'extrémité dupliqués ou comme des point relais dupliqués du point de vue du réseau SS7.


Points d'extrémité dupliqués : le couplage entre les SG et les ASP lorsque les SG agissent comme points d'extrémité dupliqués est une question de mise en œuvre.


Points relais dupliqués : dans des circonstances normales, le chemin de SEP à ASP va toujours passer via le même SGP lorsque la livraison en séquence est demandée. Cependant, des défaillances de l'ensemble de liaisons peuvent causer un reroutage du MTP sur une autre SG.


A.3 Recommandations pour la distribution de message aux passerelles de signalisation

A.3.1 Transport sans connexion

Par la configuration, la SG sait que l'utilisateur SCCP local est en fait représenté par un AS, et desservis par un ensemble d'ASP travaillant en mode de redondance n+k. Un ASP est choisi et un message CLDT est envoyé sur l'association/flux SCTP approprié.


Le critère de choix peut se fonder sur un mécanisme round robin, ou toute autre méthode qui garantit un partage de charge équitable entre les ASP actifs. Cependant, lorsque des messages TCAP sont transportés, le partage de charge n'est possible que pour le premier message dans un dialogue TCAP (TC_Begin, TC_Query, TC_Unidirectional). Tous les autres messages TCAP du même dialogue sont envoyés au même ASP qui a été choisi pour le premier message, sauf si les ASP sont capables de partager l'état et de conserver la livraison en séquence. À cette fin, le SGP a besoin de connaître la politique d'allocation des TID des ASP dans une AS :

- partage d'état,

- gamme fixe de TID par ASP dans l'AS.

Cette information peut être provisionnée dans la SG, ou peut être échangée de façon dynamique via le message ASP_Active.


Un exemple d'échange de messages INAP/TCAP entre SEP et ASP est donné ci-dessous.


Informations d'adresse dans un message CLDT (par exemple, TC_Query) du SGP à l'ASP, avec ID d'association = SG-ASP, ID de flux fondé sur le contrôle de séquence et éventuellement d'autres paramètres, par exemple, OPC :

- Contexte d'acheminement : fondés sur l'ID de réseau SS7 et les membres de l'AS, afin que le message puisse être transporté à l'ASP correct.

- Adresse de source : combinaison valide de SSN, PC et GT, comme nécessaire pour l'acheminement de retour au SEP.

- Adresse de destination : au moins SSN, pour choisir l'utilisateur SCCP/SUA à l'ASP.


Informations d'adresse dans un message CLDT (par exemple, TC_Response) de l'ASP à la SG, avec ID d'association = ASP-SG, ID de flux choisi par des moyens dépendants de la mise en œuvre par rapport à la livraison en séquence :

- Contexte d'acheminement : comme reçu dans le message précédent

- Adresse de source : adresse unique fournie de façon à ce que lorsque utilisée comme adresse de demandé SCCP dans le SEP, elle doit donner le même AS, le SSN peut être suffisant.

- Adresse de destination : copiée de l'adresse de source dans le message CLDT reçu.


Les autres messages provenant du SEP qui appartiennent à la même transaction TCAP vont maintenant atteindre le même ASP.


A.3.2 Transport en mode connexion

Les messages ultérieurs pour cette connexion sont acheminés sur DPC dans la section connexion SS7 (étiquette d'acheminement MTP) et sur l'adresse IP dans la section connexion IP (en-tête SCTP). Aucune autre information d'acheminement n'est présente dans les messages SCCP ou SUA eux-mêmes. Les ressources sont conservées au sein de la SG pour transmettre les messages d'une section à l'autre et pour remplir l'étiquette d'acheminement MTP ou l'en-tête SCTP sur la base de la référence locale de destination de ces messages (Connect Confirm, Data Transfer, etc.)

Cela signifie que dans la SG, deux références locales sont allouées, une valeur de 3 octets utilisée pour la section SS7 et une valeur de 4 octets pour la section IP. Est allouée aussi une ressource contenant les données de connexion pour les deux sections, et l'une ou l'autre des deux références locales peut être utilisée pour restituer ces données, par exemple, pour un DT1 ou CODT entrant.


Adresse des auteurs

John Loughney

Greg Sidebottom

Lode Coene

Nokia Research Center

Signatus Technologies

Siemens n.v.

PO Box 407

Kanata, Ontario

Atealaan 34

FIN-00045 Nokia Group

Canada

B-2200 Herentals

Finland

mél : greg@signatustechnologies.com

Belgium

mél : john.Loughney@nokia.com


mél : lode.coene@siemens.com


Gery Verwimp

Joe Keller

Brian Bidulock

Siemens n.v.

Tekelec

OpenSS7 Corporation

34 Atealaan

5200 Paramount Parkway

1469 Jeffreys Crescent

PO 2200

Morrisville, NC 27560

Edmonton, AB T6L 6T1

Herentals

USA

Canada

Belgium

mél : joe.keller@tekelec.com

mél : bidulock@openss7.org

mél : gery.verwimp@siemens.com




Déclaration complète de droits de reproduction


Copyright (C) The Internet Society (2004).


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


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


Propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.


Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .


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


Remerciement

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