Groupe de travail Réseau

T. George & B. Bidulock, OpenSS7

Request for Comments : 4165

R. Dantu, University of North Texas

Catégorie : Sur la voie de la normalisation

H. Schwarzbauer, Siemens


K. Morneault, Cisco Systems

Traduction Claude Brière de L'Isle

septembre 2005



Sous-système n° 2 de transfert de messages (SSTM2) du système de signalisation n° 7 (SS7) – Couche d'adaptation d'homologue à homologue d'utilisateur (M2PA)



Statut de ce mémoire

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


Notice de copyright

Copyright (C) The Internet Society (2005).


Résumé

Le présent document définit un protocole qui prend en charge le transport des messages de signalisation de niveau 3 du sous système de transfert de message (MTP, Transfert de messages Part) du système de signalisation numéro 7 (SS7, Signaling System Number 7) sur le protocole Internet (IP, Internet Protocol) en utilisant les services du protocole de transmission de contrôle de flux (SCTP, Stream Control Transmission Protocol). Ce protocole sera utilisé entre les points de signalisation SS7 qui utilisent le protocole MTP de niveau 3. Les points de signalisation SS7 peuvent aussi utiliser des liaisons SS7 standard avec le SS7 MTP de niveau 2 pour fournir le transport de messages de signalisation MTP de niveau 3. Le protocole opère d'une manière similaire au MTP de niveau 2 afin de fournir une communication d'homologue à


Table des Matières

1. Introduction

1.1 Domaine d'application

1.2 Terminologie

1.3 Abréviations

1.4 Conventions

1.5 Architecture de transport de signalisation

1.6 Services fournis par M2PA

1.7 Fonctions fournies par M2PA

1.8 Définition des frontières M2PA

1.9 Différences entre M2PA et M2UA

2. Éléments du protocole

2.1 En-tête de message commun

2.2 En-tête M2PA

2.3 Messages M2PA

3. Contrôle d'état

3.1 Contrôle d'état d'association SCTP

3.2 Contrôle d'état de liaison M2PA

4. Procédures

4.1 Procédures pour prendre en charge les caractéristiques de MTP2

4.2 Procédures de prise en charge de l'interface MTP3/MTP2

4.3 Considérations sur SCTP

5. Exemples de procédures M2PA

5.1 Initialisation (alignement) de liaison

5.2 Transmission et réception de message

5.3 Indication d'état de liaison

5.4 Message d'état de liaison (panne de processeur)

5.5 Contrôle de flux de niveau 2

5.6 Signalisation d'encombrement de liaison à MTP3

5.7 Désactivation de liaison

5.8 Remplacement de liaison

6. Considérations sur la sécurité

7. Considérations relatives à l'IANA

7.1 Identifiant de protocole de charge utile SCTP

7.2 Extensions de protocole M2PA

8. Remerciements

9. Références

9.1 Références normatives

9.2 Références pour information

Adresse des auteurs

Déclaration complète de droits de reproduction

1. Introduction

1.1 Domaine d'application

Il y a besoin d'un moyen d e livraison du protocole de signalisation pour le réseau à commutation de circuits (SCN, Switched Circuit Network) sur un réseau IP. Cela inclut les transferts de messages entre :

- une passerelle de signalisation (SG, Signaling Gateway) et un contrôleur de passerelle de supports (MGC, Media Gateway Controller) [RFC2719]

- une SG et un point de signalisation IP (IPSP, IP Signaling Point)

- un IPSP et un IPSP.


Cela pourrait permettre la convergence de certains réseaux de signalisation et de données. Les nœuds de signalisation SCN auraient accès à des bases de données et autres appareils dans le domaine des réseaux qui n'utilisent pas les liaisons de signalisation SS7. De même, les applications de téléphonie IP auraient accès aux services SS7. Il peut aussi y avoir des avantages de coût de fonctionnement et de performances quand les liaisons de signalisation traditionnelles sont remplacées par des "connexions" de réseau IP .


Le mécanisme de livraison décrit dans ce document permet un traitement complet des messages MTP3 et des capacités de gestion de réseau entre deux nœuds SS7 quelconques qui communiquent sur un réseau IP. Un nœud SS7 équipé d'une connexion au réseau IP est appelé un point de signalisation IP (IPSP). Les IPSP fonctionnent comme les nœuds SS7 traditionnels en utilisant le réseau IP à la place des liaisons SS7.


Le mécanisme de livraison devrait :

- prendre en charge un fonctionnement sans coupure des homologues de protocole MTP3 sur une connexion au réseau IP,

- prendre en charge la limite d'interface MTP niveau 2 / MTP niveau 3,

- prendre en charge la gestion des associations de transport et de trafic SCTP à la place des liaisons MTP2,

- prendre en charge le rapport asynchrone des changements d'état à la gestion.


1.2 Terminologie

MTP : sous système de transfert de messages du protocole SS7 [Q.700] [Q.701] [Q.702] [Q.703] [Q.704] [Q.705] [T1.111].

MTP2 : MTP niveau 2, la couche liaison de signalisation de MTP.

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

Utilisateur MTP2 : protocole qui utilise normalement les services de MTP niveau 2. Le seul utilisateur MTP2 est MTP3. L'utilisateur MTP2 est équivalent à l'utilisateur M2PA.

Point d'extrémité de signalisation (SEP, Signaling End Point) : point de signalisation SS7 qui est à l'origine ou la terminaison des messages de signalisation. Un exemple est un commutateur central. [RFC2719]

Point de signalisation IP (IPSP, IP Signaling Point) : point de signalisation SS7 avec une connexion au réseau IP utilisée pour SS7 sur IP.

Passerelle de signalisation (SG, Signaling Gateway) : agent de signalisation qui reçoit/envoie de la signalisation SCN native à la bordure du réseau IP [RFC2719]. Dans ce contexte, une SG est un point de signalisation SS7 qui a à la fois une connexion au réseau IP utilisée pour SS7 sur IP, et une liaison traditionnelle (non IP) à un réseau SS7.

Point de transfert de signal (STP, Signal Transfer Point) : comme défini par les normes MTP, par exemple, [Q.700].

Point de signalisation (SP, Signaling Point) : comme défini par les normes MTP, par exemple, [Q.700].

Association : se réfère à une association SCTP [RFC2960]. L'association fournit le transport pour les unités de données de protocole MTP3 et les messages d'homologues de couche d'adaptation M2PA.

Ordre des octets du réseau : octet de poids fort en premier, aussi appelé "gros boutien". Voir dans la [RFC0791], l'appendice B "Ordre de transmission des données".

Flux : un flux se réfère à un flux SCTP [RFC2960].


1.3 Abréviations

BSNT (Backward Sequence Number to be Transmitted) = numéro de séquence arrière à transmettre

FSNC (Forward Sequence Number) numéro de séquence vers l'avant du dernier message accepté par le niveau 2 distant

LI (Length Indicator) = indicateur de longueur

MSU (Message Signal Unit) = unité de signal de message

SCCP (Signaling Connection Control Part) = sous système de contrôle de connexion de signalisation

SCN (Switched Circuit Network) = réseau à commutation de circuits

SCTP (Stream Control Transmission Protocol) = protocole de transmission des commandes de flux

SIF (Signaling Information Field) = champ d'informations de signalisation

SIO (Service Information Octet) = octet d'informations de service

SLC (Signaling Link Code) = code de liaison de signalisation

SS7 (Signaling System Number 7) = système de signalisation numéro 7

SSN (Stream Sequence Number) = numéro de séquence de flux

STP (Signal Transfer Point) = point de transfert de signal


1.4 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].


1.5 Architecture de transport de signalisation

L'architecture qui a été définie [RFC2719] pour le transport de signalisation du réseau à commutation de circuits (SCN) sur IP utilise plusieurs composants, incluant un protocole de transport IP, le protocole de transmission de commandes de flux (SCTP) et un module d'adaptation pour prendre en charge les services attendus par un protocole de signalisation SCN particulier à partir de sa couche de protocole sous jacente.


Au sein de ce cadre architectural, le présent document définit un module d'adaptation de SCN qui convient pour le transport des messages MTP3 SS7. La couche d'adaptation, appelée la couche d'adaptation d'utilisateur MTP2 d'homologue à homologue (M2PA, MTP2 User Peer-to-peer Adaptation Layer) fournit à MTP3 une interface et des services similaires à MTP2. En effet, MTP2 et les couches inférieures de la pile de protocoles SS7 traditionnelle sont remplacés par un équivalent IP.


La Figure 1 montre l'interfonctionnement sans coupure à la couche MTP3. MTP3 est adapté à la couche SCTP en utilisant la couche d'adaptation d'utilisateur MTP2 d'homologue à homologue (M2PA). Toutes les primitives entre MTP3 et MTP2 sont prises en charge par M2PA. L'association SCTP agit comme une liaison SS7 entre les IPSP. Un IPSP peut avoir le sous système de contrôle de connexion de signalisation (SCCP) et les autres couches SS7 par dessus MTP3.


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

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

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

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

| TCAP | | TCAP |

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

| SCCP | | SCCP |

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

| MTP3 | | MTP3 |

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

| M2PA | | M2PA |

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

| SCTP | | SCTP |

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

| IP | | IP |

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


IP : protocole Internet

IPSP : point de signalisation IP

SCTP : protocole de transmission de commandes de flux [RFC2960]


Figure 1. Architecture M2PA symétrique d'homologue à homologue


La Figure 2 montre un exemple de M2PA utilisé dans une passerelle de signalisation (SG). La SG est un IPSP qui est équipé à la fois de connexions SS7 traditionnelles et de connexions au réseau IP.


Le SEP et la SG communiquent à travers une liaison SS7 traditionnelle, qui suit un protocole comme [Q.702]. La SG et l'IPSP communiquent à travers une liaison IP en utilisant le protocole M2PA. Les messages envoyés du SEP à l'IPSP (et vice versa) sont acheminés par la SG.


Tous les nœuds du diagramme pourraient avoir SCCP ou d'autres couches SS7 par dessus MTP3. La passerelle de signalisation agit comme un point de transfert de signal (STP). D'autres STP PEUVENT être présents dans le chemin SS7 entre le SEP et la SG.


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

* SEP *--------* SG *--------* IPSP *

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

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

| TCAP | | TCAP |

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

| SCCP | | SCCP |

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

| MTP3 | | MTP3 | | MTP3 |

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

| MTP2 | | MTP2 | M2PA | | M2PA |

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

| | | | SCTP | | SCTP |

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

| MTP1 | | MTP1 | IP | | IP |

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


SEP : point d'extrémité de signalisation SS7


Figure 2. M2PA dans une passerelle de signalisation IP


La Figure 2 est seulement un exemple. D'autres configurations sont possibles. En bref, M2PA utilise l'association SCTP comme liaison SS7. La pile M2PA/SCTP/IP peut être utilisée à la place d'une pile MTP2/MTP1.


1.5.1 Représentation de codets

MTP exige que chaque nœud avec une couche MTP3 soit identifié par un codet SS7. En particulier, chaque IPSP DOIT avoir son propre codet SS7.


1.6 Services fournis par M2PA

L'interface SS7 MTP3/MTP2 (MTP2-User) est conservée dans l'IPSP. La couche de protocole M2PA est obligée de fournir à son utilisateur un ensemble de services équivalent à celui fourni par MTP niveau 2 à MTP niveau 3.


Ces services sont décrits dans les paragraphes suivants.


1.6.1 Prise en charge de la frontière d'interface MTP niveau 2/MTP niveau 3

Cette interface est la même que l'interface MTP2/MTP3 décrite dans les normes SS7 applicables [Q.703] [Q.704] [T1.111] [Q.2140], avec l'ajout de la prise en charge des plus grands numéros de séquence qui se trouvent dans [T1.111] et [Q.2210].


M2PA reçoit les primitives envoyées de MTP3 à sa couche inférieurs. M2PA traite ces primitives ou les transpose en les primitives appropriées à l'interface M2PA/SCTP. De même, M2PA envoie des primitives à MTP3 similaires à celles utilisées dans l'interface MTP3/MTP2.


Parce que M2PA utilise de plus grands numéros de séquence que MTP2, la procédure de changement MTP3 DOIT utiliser les messages Extended Changeover Order (ordre de changement étendu) et Extended Changeover Acknowledgement (accusé de réception de changement étendu) décrits dans [Q.2210] et [T1.111].


Aussi, les primitives MTP3/MTP2 suivantes doivent utiliser les plus grands numéros de séquence :

- Confirmation BSNT

- Demande de restitution et FSNC


1.6.2 Prise en charge de la communication d'homologue à homologue

Dans SS7, MTP niveau 2 envoie trois types de messages, appelés unités de signal : unités de signal de message (MSU, Message Signal Unit) unités de signal d'état de liaison (LSSU, Link Status Signal Unit), et unités de signal de remplissage (FTSU, Fill-In Signal Unit).


Les MSU ont leur origine à un niveau supérieur à MTP2, et sont destinées à un homologue à un autre nœud. De même, M2PA passe ces messages de MTP3 à SCTP comme données à transporter à travers une liaison. Ils sont appelés des messages de données d'utilisateur (User Data) dans M2PA.


Les LSSU permettent aux couches MTP2 homologues d'échanger des informations d'état. Des messages analogues sont nécessaires pour M2PA. Le message État de liaison (Link Status) sert à cela.


Les FISU sont transmis en continu quand aucune autre unité de signal n'attend d'être envoyée. Les FISU portent aussi les accusés de réception des messages. Comme un réseau IP est une ressource partagée, il ne serait pas souhaitable d'avoir un type de message envoyé en continu comme c'est le cas avec les FISU. De plus, SCTP n'exige pas que sa couche supérieure transmette des messages en continu. Donc, M2PA ne fournit pas d'unité de données de protocole comme la FISU. Le message Données d'utilisateur de M2PA est utilisé pour porter les accusés de réception des messages. Si M2PA a besoin d'accuser réception d'un message, et qu'il n'a pas de message MTP3 de son cru à envoyer, un message User Data vide peut être envoyé.


1.7 Fonctions fournies par M2PA

1.7.1 Fonctionnalité MTP2

M2PA fournit à MTP2 une fonctionnalité que ne fournissait pas SCTP ; donc, ensemble M2PA et SCTP fournissent une fonctionnalité similaire à celle de MTP2.


SCTP fournit une livraison fiable, en séquence des messages.


Les fonctionnalités de M2PA incluent :

- la restitution des données pour la prise en charge de la procédure de changement MTP3

- le rapport des changements d'état de liaison à MTP3

- la procédure de panne de processeur

- la procédure d'alignement de liaison


1.7.2 Transposition de SS7 et des entités IP

La couche M2PA doit conserver une transposition de chacune de ses liaisons SS7 à l'association SCTP correspondante.


1.7.3 Gestion d'association SCTP

SCTP permet à un nombre de flux spécifié par l'utilisateur d'être ouvert durant l'initialisation. Il est de la responsabilité de la couche M2PA d'assurer une gestion appropriée des flux permis au sein de chaque association.


M2PA utilise deux flux dans chaque direction pour chaque association. Le flux 0 dans chaque direction est réservé aux messages État de liaison (Link Status). Le flux 1 est destiné aux messages Données d'utilisateur (User Data) ainsi qu'aux messages Link Status qui doivent rester en séquence avec les messages User Data. Séparer les messages Link Status et User Datas en des flux distincts permet à M2PA de donner aux messages des priorités d'une manière similaire à MTP2.


Les notifications reçues de SCTP sont traités par M2PA ou traduites dans une notification appropriée à envoyer à la couche supérieure MTP3.


1.7.4 Rétention de MTP3 dans le réseau SS7

M2PA permet à MTP3 d'effectuer toutes ses fonctions de traitement de message et de gestion de réseau avec des IPSP comme il le fait avec les autres nœuds SS7.


1.8 Définition des frontières M2PA

1.8.1 Définition de la frontière M2PA/MTP niveau 3

Les primitives de couche supérieure fournies par M2PA sont les mêmes que celles fournies par MTP2 à MTP3. Ces primitives sont décrites dans les normes SS7 applicables [Q.703] [Q.704] [T1.111] [Q.2140].


1.8.2 Définition de la frontière de couche inférieure entre M2PA et SCTP

Les primitives de couche supérieure fournies par SCTP sont décrites à la Section 10 de la [RFC2960] "Interface avec la couche supérieure".


1.9 Différences entre M2PA et M2UA

La couche d'adaptation d'utilisateur MTP2 (M2UA) [RFC3331] adapte aussi la couche MTP3 à la pile SCTP/IP. Elle fait cela à travers une architecture de transport arrière [RFC2719]. Ce paragraphe est destiné à clarifier certaines des différences entre les approches de M2PA et de M2UA.

Une architecture possible de M2PA est montrée à la Figure 3. Ici, le MTP3 de l'IPSP utilise sa M2PA sous jacente comme remplacement de MTP2. La communication entre les deux couches MTP3/M2PA est définie par les mêmes primitives que dans le SS7 MTP3/MTP2. M2PA effectue des fonctions similaires à MTP2.


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

* SEP *--------* SG *--------* IPSP *

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

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

| SCCP | | SCCP | | SCCP |

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

| MTP3 | | MTP3 | | MTP3 |

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

| MTP2 | | MTP2 | M2PA | | M2PA |

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

| | | | SCTP | | SCTP |

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

| MTP1 | | MTP1 | IP | | IP |

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


Figure 3. M2PA dans une passerelle de signalisation IP


Une architecture comparable pour M2UA est montrée à la Figure 4. Dans M2UA, le MTP3 de la MGC utilise le MTP2 de la SG comme sa couche SS7 inférieure. De même, le MTP2 de la SG utilise le MTP3 du MGC comme sa couche SS7 supérieure. Dans le SS7, la communication entre les couches MTP3 et MTP2 est définie par des primitives. Dans M2UA, la communication MTP3/MTP2 est définie comme des messages M2UA et est envoyée sur la connexion IP.


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

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

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

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

| SCCP | | SCCP |

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

| MTP3 | (NIF) | MTP3 |

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

| MTP2 | | MTP2 | M2UA | | M2UA |

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

| | | | SCTP | | SCTP |

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

| MTP1 | | MTP1 | IP | | IP |

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


NIF (Nodal Interworking Function) : fonction d'interfonctionnement nodal


Figure 4. M2UA dans une passerelle de signalisation IP

M2PA et M2UA sont similaires en ce que :

a. toutes deux transportent les messages de données MTP3,

b. toutes deux présentent une interface supérieure MTP2 avec MTP3.


Les différences entre M2PA et M2UA incluent :

a. M2PA : l'IPSP traite les primitives MTP3/MTP2. M2UA : le MGC transporte les primitives MTP3/MTP2 entre le MTP2 de la SG et le MTP3 du MGC (via la NIF) pour le traitement.

b. M2PA : la connexion SG-IPSP est une liaison SS7. M2UA : la connexion SG-MGC n'est pas une liaison SS7. C'est une extension de MTP à une entité distante.

c. M2PA : la SG est un nœud SS7 avec un codet. M2UA : la SG n'est pas un nœud SS7 et n'a pas de codet.

d. M2PA : la SG peut avoir des couches SS7 supérieures, par exemple, SCCP. M2UA : la SG n'a pas de couche supérieure SS7 car elle n'a pas de MTP3.

e. M2PA : s'appuie sur MTP3 pour les procédures de gestion. M2UA : utilise les procédures de gestion de M2UA.


Les utilisateurs potentiels de M2PA et M2UA devraient connaître ces différences pour décider comment les utiliser pour le transport de signalisation SS7 sur les réseaux IP.


2. Éléments du protocole


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

Tous les champs dans un message M2PA doivent être transmis dans l'ordre des octets du réseau, c'est-à-dire, l'octet de poids fort en premier, sauf mention contraire.


2.1 En-tête de message commun

Les messages de protocole pour M2PA exigent une structure d'en-tête de message qui contienne une version, une classe de message, un type de message, et une longueur de message. La structure d'en-tête est montrée à la Figure 5.


0 1 2 3

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

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

| Version | Réservé | Classe message| Type message |

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

| Longueur de message |

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


Figure 5. En-tête de message commun


2.1.1 Version

Le champ Version contient la version de M2PA. La version prise en charge est 1 : version 1.0 du protocole M2PA


2.1.2 Réservé

Le champ Réservé DEVRAIT être réglé tout à zéro (0) par l'envoyeur et ignoré par le receveur. Le champ Réservé NE DEVRAIT PAS être utilisé pour des informations propriétaires.


2.1.3 Classe de message

La seule classe de message valide est 11 : Message M2PA

Les autres valeurs sont invalides pour M2PA.


2.1.4 Type de message

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


Valeur (décimal)

Type de message

1

Données d'utilisateur

2

État de liaison

Les autres valeurs sont invalides.


2.1.5 Longueur de message

La longueur de message est en octets, incluant l'en-tête commun.


2.2 En-tête M2PA

Tous les messages de protocole pour M2PA exigent un en-tête spécifique de M2PA. La structure d'en-tête est montrée à la Figure 6.


0 1 2 3

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

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

| non utilisé | BSN |

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

| non utilisé | FSN |

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


Figure 6. En-tête de message spécifique de M2PA


2.2.1 Numéro de séquence vers l'arrière (BSN)

C'est le FSN du dernier message reçu de l'homologue.


2.2.2 Numéro de séquence vers l'avant (FSN)

C'est le numéro de séquence M2PA du message Données d'utilisateur envoyé.

Les valeurs de FSN et BSN sont dans la gamme 0 à 16 777 215.


2.3 Messages M2PA

Le paragraphe suivant définit le contenu et les paramètres des messages. Un message M2PA consiste en un en-tête de message commun et un en-tête M2PA, suivis par les données appropriées au message.


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

\ \

/ En-tête de message commun /

\ \

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

\ \

/ En-tête de message spécifique de M2PA /

\ \

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

\ \

/ Données du message /

\ \

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


Le champ "Données du message" contient soit :

- un message Données d'utilisateur (paragraphe 2.3.1) soit

- un message État de liaison (paragraphe 2.3.2)


2.3.1 Données d'utilisateur

Les données d'utilisateur sont les données envoyées de MTP3. Données d'utilisateur est un champ facultatif. Il n'est pas nécessaire qu'il soit inclus dans un message seulement d'accusé de réception.


Le format du message Données d'utilisateur est comme suit :


0 1 2 3

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

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

\ \

/ Données /

\ \

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


Le champ Données contient les champs suivants de l'unité de signal de message (MSU) MTP :

- le champ Priorité de message (PRI)

- l'octet Informations de service (SIO)

- le champ Informations de signalisation (SIF)


La MSU MTP est décrite au paragraphe 2.2 de [Q.703], "Format d'unité de signal", et au paragraphe 2.2 de [T1.111], "Format d'unité de signal". La norme japonaise TTC utilise le champ PRI comme champ de priorité de message MTP3 [JT-Q703] [JT-Q704]. Pour les versions de MTP qui n'utilisent pas ces deux bits, le premier octet du champ Données est tout entier réservé.

Le format du premier octet du champ Données est :


0 1 2 3 4 5 6 7

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

|PRI| réservé | (suivi par SIO, SIF)

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


PRI - Priorité utilisée seulement dans le MTP national défini dans [JT-Q703] et [JT-Q704]. Ces bits sont réservés pour les autres versions MTP.


Noter que le champ Données NE DEVRA PAS contenir d'autres composants du format de MSU MTP :

- Fanions

- Numéro de séquence arrière (BSN, Backward Sequence Number)

- bit d'indicateur vers l'arrière (BIB, Backward Indicator Bit)

- Numéro de séquence vers l'avant (FSN, Forward Sequence Number)

- bit d'indicateur vers l'avant (FIB, Forward Indicator Bit)

- indicateur de longueur (LI, Length Indicator)

- bits de vérification (CK, Check bit)

Le champ Données DEVRA être transmis dans l'ordre des octets défini par MTP3.

M2PA NE DEVRA PAS ajouter de bourrage au message MTP3.


Note : dans les Recommandations SS7, le format des messages et champs au sein des messages se fonde sur l'ordre de transmission des bits. Dans ces recommandations, le bit de moindre poids (LSB, Least Significant Bit) de chaque champ est positionné à droite. Les champs SS7 reçus sont remplis octet par octet comme reçus dans le monde à 4 octets, comme montré ci-dessous.


Par exemple, dans le protocole MTP de ANSI, le format du champ Données est :


|MSB---------------------------------------------------------LSB|

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

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

|PRI| réservé | SIO | octet SIF | ... |

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

\ \

/ : /

\ \

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

| ... | ... | ... | octet SIF |

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


Au sein de chaque octet, le bit de moindre poids (LSB) selon les Recommandations SS7 est à droite (par exemple, le bit 15 du SIO est le LSB).


2.3.2 État de liaison

Le message État de liaison MTP2 peut être envoyé entre homologues M2PA pour indiquer l'état de liaison. Ce message effectue une fonction similaire à celle de l'unité de signal d'état de liaison dans MTP2. Le format du message État de liaison est comme suit :


0 1 2 3

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

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

| État |

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


Les valeurs valides pour État sont :


Valeur (décimal)

Description

1

Alignement

2

Épreuve normale

3

Épreuve d'urgence

4

Prêt

5

Panne de processeur

6

Processeur réparé

7

Occupé

8

Fin d'occupation

9

Hors service (OOS)


2.3.2.1 Vérification d'état de liaison

Le message Épreuve d'état de liaison peut facultativement porter des octets supplémentaires. Si des octets facultatifs sont utilisés, le format du message est comme suit :

0 1 2 3

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

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

| État |

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

\ \

/ Remplissage /

\ \

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


Il est RECOMMANDÉ que la longueur du message État de liaison soit similaire à la taille des messages Données d'utilisateur qui seront portés sur la liaison.


Il est RECOMMANDÉ que le champ de remplissage contienne un schéma de nombre qui varie avec les messages Épreuve d'état de liaison, et qui permette d'utiliser la somme de contrôle SCTP [RFC3309] pour vérifier la précision de la transmission.


3. Contrôle d'état

3.1 Contrôle d'état d'association SCTP

La Figure 7 illustre les changements d'état dans la gestion M2PA de l'association SCTP, avec les événements qui les causent. Noter que certaines des conditions d'erreur ne sont pas montrées dans le diagramme d'états.


Voici une liste des états d'association M2PA et leur description :


IDLE (Repos) état de l'association durant l'initialisation de la mise sous tension.


ASSOCIATING (en cours d'association) M2PA tente d'établir une association SCTP.


ESTABLISHED (établie) l'association SCTP est établie.


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

| REPOS

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

|

| Associe (Produit SCTP associe)

|

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

| |(Produit SCTP associe)|

V V |

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

| ASSOCIE |----------------->+

+-------------+ Erreur com. SCTP |

| |

| |

| Com. SCTP active |

| |

V |

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

| ÉTABLIE |----------------->+

+-------------+ Erreur com. SCTP OU com. SCTP perdue


Figure 7. Diagramme de transition d'état d'association M2PA


3.2 Contrôle d'état de liaison M2PA

La liaison M2PA passe d'un état à un autre en réponse à divers événements. Les événements qui peuvent résulter en un changement d'état incluent :

- les demandes de primitive MTP3

- la réception de messages de l'homologue M2PA

- l'expiration de temporisateurs

- des notifications SCTP


Ces événements affectent l'état de la liaison M2PA d'une manière similaire à MTP2.


4. Procédures


Comme M2PA fournit à MTP3 une interface et des fonctionnalités comme MTP2, son fonctionnement interne est similaire à celui de MTP2. Sauf comme modifié par le présent document, M2PA DEVRAIT suivre les exigences de la spécification MTP2 applicable. Cela peut inclure [Q.703] ou [T1.111]. La même norme DOIT être suivie sur les deux extrémités de la liaison M2PA.


En particulier, la valeur par défaut du temporisateur correspondant applicable et sa gamme spécifiées dans les normes MTP2 applicables devraient être utilisées pour les temporisateurs M2PA.


Quand on se réfère à la terminologie MTP2 dans ce document, on utilise celle de [Q.703]. Cela n'implique pas que les exigences de [Q.703] doivent être suivies.


4.1 Procédures pour prendre en charge les caractéristiques de MTP2

4.1.1 Format, délimitation, acceptation d'unité de signal

Les messages à transmettre à travers le réseau doivent respecter le format décrit à la Section 2.


SCTP fournit une livraison fiable en séquence des messages d'utilisateur. Donc la fonctionnalité homologue de MTP2 n'est pas nécessaire. SCTP ne fournit pas de fonctions relatives au contrôle d'état de liaison dans MTP2. Ces fonctions doivent être fournies par M2PA.


Comme SCTP assure la livraison des messages, il n'est pas nécessaire que M2PA délimite ses messages avec un fanion, car c'est fait dans MTP2. De plus, M2PA n'a pas besoin d'effectuer l'insertion et la suppression du bit zéro sur ses messages.


Comme SCTP utilise une somme de contrôle pour détecter les erreurs de transmission, il n'y a pas besoin d'une somme de contrôle M2PA, comme c'est nécessaire dans MTP2. Cela élimine aussi le besoin de la surveillance de taux d'erreur de MTP2.


Comme SCTP fournit une livraison fiable et ordonnée, M2PA n'effectue pas de retransmissions. Cela élimine le besoin de bits indicateurs vers l'avant et vers l'arrière dans les unités de signal MTP2.


L'acceptation d'un message est indiquée par un récépissé du message de la part de SCTP.


4.1.2 Entités MTP et SCTP

Ce paragraphe décrit comment M2PA se rapporte aux entités MTP et SCTP.


Chaque liaison MTP correspond à une association SCTP. Pour empêcher l'établissement d'associations dupliquées, il est RECOMMANDÉ que chaque point d'extrémité connaisse l'adresse IP (ou les adresses IP, si le multi rattachement est utilisé) et le numéro d'accès des deux points d'extrémité. SCTP empêche l'établissement de deux associations avec la même adresse IP et numéro d'accès.


Il est nécessaire qu'au moins un des points d'extrémité écoute sur l'accès sur lequel l'autre point d'extrémité essaye d'établir l'association. Donc, au moins un des numéros d'accès DEVRAIT être l'accès enregistré M2PA.


Si seulement une association va être établie entre ces deux adresses IP, l'association DEVRAIT alors être établie en utilisant l'accès M2PA enregistré à chaque point d'extrémité.


Si on désire créer plusieurs associations (pour plusieurs liaisons) entre les deux adresses IP, des numéros d'accès différents peuvent être utilisés pour chaque association. Néanmoins, le numéro d'accès M2PA enregistré DEVRAIT être utilisé à une extrémité de chaque association.


Chaque combinaison d'adresse/accès IP pour les deux points d'extrémité (c'est-à-dire, chaque association) DOIT être transposée en le même code de liaison de signalisation (SLC, Signaling Link Code) à chaque point d'extrémité, afin que chaque point d'extrémité sache quelle liaison est en cours de création au moment de l'établissement de l'association SCTP. Cependant, M2PA ne fait aucun traitement sur la base du SLC.


Voici des exemples des relations entre associations et liaisons. Noter qu'une liaison est une association SCTP identifiée par deux points d'extrémité. Chaque point d'extrémité est identifié par une adresse IP et un numéro d'accès. Chaque association est transposée en un SLC.


La Figure 8 montre le cas de deux IPSP, dont chacun a deux adresses IP. Deux associations sont les liaisons qui connectent les deux IPSP. Comme ces liaisons sont dans le même ensemble de liaisons, elles DOIVENT avoir des SLC différents.


Le Tableau 1 montre les relations sous forme d'un tableau. Ce tableau est purement conceptuel. La méthode réelle pour transposer les associations SCTP en SLC dépend de la mise en œuvre.


IPSP X IPSP Y

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

| | SCTP | |

| IPA | association 1 | IPB |

| accès = PW +---------------+ accès = PW |

| SLC = a | | SLC = a |

| | | |

| | | |

| | SCTP | |

| IPC | association 2 | IPD |

| accès = PW +---------------+ accès = PW |

| SLC = b | | SLC = b |

| | | |

| | | |

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


IPx = adresse IP

PW = numéro d'accès enregistré pour M2PA


Figure 8. Deux IPSP avec deux adresses IP chacun


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

| Association | IPSP X | IPSP Y | SLC |

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

| | Adresse IP | Accès| Adresse IP | Accès| |

+=============+============+======+============+======+=====+

| 1 | IPA | PW | IPB | PW | a |

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

| 2 | IPC | PW | IPD | PW | b |

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


Tableau 1 : Deux IPSP avec deux adresses IP chacun


La Figure 9 et le Tableau 2 montrent un exemple avec trois IPSP. Noter que dans cet exemple, les deux liaisons sont dans des ensembles de liaisons différents. Donc, il est possible que les valeurs a et b de SLC PUISSENT être égales.


IPSP X IPSP Y

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

| | SCTP | |

| IPA | association 1 | IPB |

| accès = PW +---------------+ accès = PW |

| SLC = a | | SLC = a |

| | | |

| | SCTP | |

| IPC | association 2 | |

| accès = PW +-------+ | |

| SLC = b | | | |

| | | | |

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

|

|

| IPSP Z

|

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

| | |

| | IPD |

+-------+ accès = PW |

| SLC = b |

| |

| |

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


IPx = adresse IP

PW = numéro d'accès enregistré pour M2PA


Figure 9. Un IPSP connecté à deux IPSP


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

| Association | IPSP X | IPSP Y/Z | SLC |

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

| | Adresse IP |Accès | Adresse IP |Accès | |

+=============+============+======+============+======+=====+

| 1 | IPA | PW | IPB | PW | a |

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

| 2 | IPC | PW | IPD | PW | b |

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


Tableau 2 : Un IPSP connecté à deux IPSP


La Figure 10 et le Tableau 3 montrent deux associations entre les mêmes adresses IP. Cela se fait en utilisant des numéros d'accès différents pour chaque association à un point d'extrémité.


IPSP X IPSP Y

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

| | SCTP | |

| IPA | association 1 | IPB |

| accès = P1 +---------------+ accès = PW |

| SLC = a | | SLC = a |

| | | |

| | | |

| | SCTP | |

| IPA | association 2 | IPB |

| accès = PW +---------------+ accès = PW |

| SLC = b | | SLC = b |

| | | |

| | | |

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


IPx = adresse IP

P1 = numéro d'accès pré sélectionné

PW = numéro d'accès enregistré pour M2PA


Figure 10. Plusieurs associations entre deux adresses IP


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

| Association | IPSP X | IPSP Y | SLC |

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

| | Adresse IP |Accès | Adresse IP |Accès | |

+=============+============+======+============+======+=====+

| 1 | IPA | P1 | IPB | PW | a |

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

| 2 | IPA | PW | IPB | PW | b |

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


Tableau 3 : Plusieurs associations entre deux adresses IP


L'association DEVRA contenir deux flux dans chaque direction. Le flux 0 est destiné aux messages État de liaison. Le flux 1 est destiné aux messages Données d'utilisateur, ainsi qu'aux messages État de liaison qui doivent rester en séquence avec les messages Données d'utilisateur.


Les messages État de liaison suivants DEVRONT être envoyés sur le flux État de liaison (flux 0) :

- Alignement

- Épreuve normale

- Épreuve d'urgence

- Prêt (quand envoyé durant l'alignement)

- Occupé

- Fin d'occupation

- Hors service


Les messages État de liaison suivants DEVRONT être envoyés sur le flux de données d'utilisateur (flux 1) :

- Panne du processeur

- Récupération du processeur

- Prêt (quand envoyé à la fin d'une panne de processeur)


4.1.3 Alignement de liaison

L'objet de la procédure d'alignement est :

(1) de fournir une procédure de prise de contact afin que les deux points d'extrémité soient prêts à envoyer du trafic SS7, et d'empêcher le trafic d'être envoyé avant que l'autre extrémité ne soit prête ;

(2) de vérifier que l'association SCTP convient pour être utilisée comme liaison SS7.


L'alignement de liaison a lieu après l'établissement de l'association. Si SCTP échoue à établir l'association, et si M2PA a reçu une demande de démarrage (Start Request) de son MTP3, M2PA DEVRA alors rapporter à MTP3 que la liaison est hors service.


Le message État de liaison hors service (Link Status Out of Service) remplace le message SIOS de MTP2. À la différence de MTP2, le message NE DEVRAIT PAS être transmis en continu. Après l'établissement de l'association, M2PA DEVRA envoyer un message État de liaison hors service à son homologue. Avant de commencer l'alignement, M2PA PEUT envoyer des messages État de liaison hors service supplémentaires.


Le message Alignement d'état de liaison remplace le message SIO de MTP2. Ce message est envoyé pour signaler le début de la procédure d'alignement. Le message Alignement d'état de liaison NE DEVRAIT PAS être transmis en continu. M2PA PEUT envoyer des Alignement d'état de liaison supplémentaires jusqu'à ce qu'il reçoive un Alignement d'état de liaison, État de liaison Épreuve normale, ou État de liaison Épreuve d'urgence de l'homologue.


Le message État de liaison Épreuve normale remplace le message SIN de MTP2. Le message État de liaison Épreuve d'urgence remplace le message SIE de MTP2.


La période d'épreuve PEUT être omise si c'est permis par la norme MTP2 applicable (par exemple, [Q.2140]).


Si l'épreuve est effectuée, alors, durant la période d'épreuve (c'est-à-dire, après que M2PA lance le temporisateur T4 de période d'épreuve) M2PA DEVRA envoyer des messages Épreuve d'état de liaison (Link Status Proving) à son homologue à un intervalle défini par le paramètre de protocole Proving_Interval. Il est RECOMMANDÉ que Proving_Interval soit réglé de façon à ce que la charge de trafic générée par les messages Épreuve d'état de liaison durant la période d'épreuve soit comparable à la charge de trafic normal attendue quand la liaison est en service.


Le message État de liaison prêt remplace le FISU de MTP2 qui est envoyé à la fin de la période d'épreuve. Le message État de liaison prêt est utilisé pour vérifier que les deux extrémités ont achevé l'épreuve. Quand M2PA lance le temporisateur T1, il DEVRA envoyer un message État de liaison prêt à son homologue pour le cas où MTP2 enverrait un FISU après l'achèvement de l'épreuve. Si le message État de liaison prêt est envoyé, alors M2PA PEUT envoyer des messages État de liaison prêt supplémentaires pendant que le temporisateur T1 court. Ces messages État de liaison prêt sont envoyés sur le flux État de liaison.


Dans le cas où MTP2 envoie un message MSU ou SIPO à la fin de l'épreuve, M2PA DEVRA envoyer (respectivement) un message Données d'utilisateur ou État de liaison Panne de processeur.


4.1.4 Panne de processeur

Le message État de liaison Panne de processeur remplace le message SIPO de MTP2. À la différence de MTP2, le message NE DEVRAIT PAS être transmis en continu. M2PA DEVRA envoyer un message État de liaison Panne de processeur à son homologue au début de la condition de panne de processeur alors que MTP2 enverrait un SIPO. M2PA PEUT envoyer des messages État de liaison Panne de processeur supplémentaires tant que cette condition persiste. Le message État de liaison Panne de processeur DEVRA être envoyé sur le flux Données d'utilisateur.


Dans une condition de panne de processeur local (LPO, local processor outage) :

(a) Un message Données d'utilisateur reçu de l'homologue NE DOIT PAS être acquitté et DOIT être mis en mémoire tampon.

(b) M2PA DEVRAIT continuer d'accuser réception des messages Données d'utilisateur reçus et acceptés par MTP3 avant la panne de processeur local.

(c) M2PA DEVRAIT continuer de transmettre les messages qui ont été envoyés par sa couche supérieure MTP3.


Lorsque il y a une condition de panne du processeur distant (RPO, remote processor outage) :

(a) M2PA DEVRAIT continuer d'accuser réception des messages Données d'utilisateur reçus et acceptés par MTP3, sans considération de la panne de processeur distant.

(b) Si un message Données d'utilisateur reçu de l'homologue après l'État de liaison Panne de processeur ne peut pas être livré au MTP3, alors ce message NE DOIT PAS être acquitté et DOIT être mis en mémoire tampon.


Si M2PA reçoit une commande Flush (purger) de MTP3 :

(a) M2PA DEVRA éliminer tous les messages entrants qui ont été mis en file d'attente et n'ont pas été acquittés durant la condition de panne de processeur.

(b) M2PA DEVRA éliminer les messages dans les files d'attente de transmission et retransmission selon ce qui est exigé par MTP2.


Si M2PA reçoit une commande Continuer de MTP3, M2PA DEVRA commencer à traiter les messages entrants qui étaient en file d'attente et non acquittés durant la condition de panne du processeur.


Quand la condition de panne locale du processeur se termine, M2PA DEVRA envoyer un message État de liaison Processeur récupéré à son homologue sur le flux Données d'utilisateur. Ce message est utilisé pour signaler la fin de la condition de panne de processeur, au lieu d'un MSU ou FISU, comme utilisé dans MTP2. Le BSN dans le message État de liaison Processeur récupéré est réglé au FSN du dernier message Données d'utilisateur reçu (et non éliminé) de l'homologue M2PA. M2PA DEVRA cesser de transmettre le message Données d'utilisateur après l'envoi du message État de liaison Processeur récupéré, jusqu'à ce qu'il ait reçu le message État de liaison prêt (voir ci-dessous).


À réception du message État de liaison Processeur récupéré, le M2PA dans RPO DEVRA répondre avec un message État de liaison prêt sur le flux Données d'utilisateur. Le BSN dans le message État de liaison prêt est réglé au FSN du dernier message Données d'utilisateur reçu (et non éliminé) de l'homologue M2PA.


À réception du message État de liaison prêt, le M2PA anciennement en LPO DEVRA répondre par un message État de liaison prêt sur le flux Données d'utilisateur. Le BSN dans le message État de liaison prêt est réglé au FSN du dernier message Données d'utilisateur reçu (et non éliminé) de l'homologue M2PA.


M2PA (aux deux extrémités LPO et RPO) utilise la valeur du BSN dans le message État de liaison prêt reçu pour resynchroniser ses numéros de séquence, si c'est exigé par MTP2. M2PA NE DEVRA PAS recommencer à transmettre de messages Données d'utilisateur jusqu'à ce qu'il ait envoyé le message État de liaison prêt.


Durant la resynchronisation, M2PA NE DEVRA PAS éliminer les messages Données d'utilisateur reçus qui ont été envoyés après la fin de la panne de processeur.


Quand M2PA rencontre une panne de processeur locale, il PEUT mettre la liaison hors service en envoyant un message État de liaison Hors service, si c'est permis par les normes MTP2 applicables (par exemple, [Q.2140]).


Pour le reste, M2PA DEVRAIT suivre les mêmes procédures que MTP2 dans une panne de processeur.


4.1.5 Contrôle de flux de niveau 2

Le message État de liaison Occupé remplace le message SIB de MTP2. Ce message NE DEVRAIT PAS être transmis en continu. M2PA DEVRA envoyer un message État de liaison Occupé à son homologue au début d'une condition d'encombrement reçue où MTP2 enverrait un SIB. M2PA PEUT envoyer des messages État de liaison Occupé supplémentaires tant que la condition persiste. Quand la condition se termine, M2PA DEVRA envoyer un message État de liaison Occupé terminé à son homologue.


M2PA DEVRA continuer de transmettre les messages quand il est dans un encombrement de réception, mais NE DOIT PAS accuser réception du message qui déclenche l'envoi du message État de liaison Occupé, ni aucun message reçu avant l'envoi de État de liaison Occupé terminé.


Quand l'homologue M2PA reçoit le premier message État de liaison Occupé, il DEVRA lancer le temporisateur d'encombrement T6 si il y a des messages dans la mémoire tampon de retransmission qui attendent un accusé de réception (c'est-à-dire, si T7 court). M2PA DEVRA arrêter le temporisateur T7 si il court. Des messages État de liaison Occupé supplémentaires reçus pendant que T6 court ne causent pas la remise à zéro de T6 et ne causent pas le lancement de T7. Quand T6 court, T7 NE DEVRA PAS être lancé.


Quand l'homologue M2PA reçoit le message État de liaison Occupé et que T6 n'est pas encore arrivé à expiration, il DEVRA arrêter T6 (si T6 court) et lancer T7 (si il y a des messages qui attendent un accusé de réception dans l'antémémoire de retransmission).


L'homologue M2PA DEVRAIT continuer de recevoir et d'accuser réception des messages pendant que l'autre extrémité est occupée, mais NE DOIT PAS envoyer de messages Données d'utilisateur après avoir reçu un État de liaison Occupé et avant de recevoir un État de liaison Occupé terminé.


4.1.6 Liaison hors service

Le message État de liaison Hors service remplace le message SIOS de MTP2. À la différence de MTP2, le message NE DEVRAIT PAS être transmis en continu. M2PA DEVRA envoyer un message État de liaison Hors service à son homologue au début de la condition là où MTP2 aurait envoyé un SIOS. M2PA PEUT envoyer des messages État de liaison Hors service supplémentaires tant que cette condition persiste.


Quand M2PA place une liaison dans l'état HORS SERVICE, M2PA NE DEVRAIT PAS terminer l'association SCTP.


4.1.7 Problèmes d'association SCTP

L'association SCTP pour une liaison peut devenir inutilisable, quand une des choses suivantes se produit :

- SCTP envoie une notification Échec d'envoi (Send Failure) à M2PA.

- SCTP envoie une notification Perte de communication (Communication Lost) à M2PA.

- SCTP envoie une notification Erreur de communication (Communication Error) à M2PA.

- L'association SCTP est perdue.


Si l'association SCTP pour une liaison devient incapable de transmettre ou recevoir des messages, M2PA DEVRA rapporter à MTP3 que la liaison est hors service et entrer dans l'état HORS SERVICE.


4.1.8 Priorités de transmission et de réception

Dans MTP, les messages État de liaison ont la priorité sur les messages Données d'utilisateur ([Q.703], paragraphe 11.2). Pour réaliser cela dans M2PA, M2PA utilise des flux sépares dans son association SCTP pour les messages État de liaison et les messages Données d'utilisateur.


M2PA DEVRA envoyer tous les messages en utilisant l'option de livraison ordonnée de SCTP.


M2PA DEVRAIT donner une priorité plus élevée aux messages envoyés sur le flux État de liaison qu'aux messages envoyés sur le flux Données d'utilisateur lors de l'envoi de messages à SCTP.


M2PA DEVRAIT donner une priorité supérieure à la lecture du flux État de liaison qu'à celle du flux Données d'utilisateur.


M2PA DEVRAIT donner une priorité supérieure à la réception des notifications de SCTP qu'à la lecture des flux État de liaison ou Données d'utilisateur.


4.1.9 Contrôle de version M2PA

Un nœud mis à niveau d'une version plus récente de M2PA DEVRAIT prendre en charge les plus anciennes versions utilisées sur d'autres nœud avec lesquels il communique. Si c'est le cas, alors l'alignement peut se poursuivre normalement.

En particulier, il est recommandé que pour de futures modifications de ce protocole :

- Toute version plus récente DEVRAIT être capable de traiter les messages d'une version plus ancienne.

- Une version plus récente de M2PA DEVRAIT s'interdire d'envoyer à une version plus ancienne de M2PA des messages que cette plus ancienne version ne peut pas traiter.

- Si une ancienne version de M2PA reçoit un message qu'elle ne peut traiter, elle DEVRAIT éliminer le message.

- Dans les cas où un traitement différent est fait sur deux versions pour le même format d'un message, alors la version plus récente DEVRAIT contenir les procédures pour reconnaître et traiter cela de façon appropriée.


Dans le cas où une version plus récente de M2PA est incompatible avec une version plus ancienne, la nouvelle version DEVRAIT reconnaître cela et empêcher l'alignement de la liaison. Si un message État de liaison Alignement avec une version non prise en charge est reçu par la version plus récente, le M2PA de l'extrémité receveuse DEVRAIT répondre par un message État de liaison Hors service et ne pas achever la procédure d'alignement.


4.2 Procédures de prise en charge de l'interface MTP3/MTP2

4.2.1 Envoi et réception des messages

Quand MTP3 envoie un message à transmettre à M2PA, M2PA passe le message M2PA correspondant à SCTP en utilisant la primitive SEND. Les messages Données d'utilisateur DEVRONT être envoyés via le flux Données d'utilisateur (flux 1) de l'association. Les messages État de liaison M2PA sont passés à SCTP en utilisant la primitive SEND.


Les messages État de liaison suivants DEVRONT être envoyés sur le flux État de liaison (flux 0) :

- Alignement

- Épreuve normale

- Épreuve d'urgence

- prêt (quand envoyé durant l'alignement)

- Occupé

- Fin d'occupation

- Hors service


Les messages État de liaison suivants DEVRONT être envoyés sur le flux Données d'utilisateur (flux 1) :

- Panne de processeur

- Processeur récupéré

- Prêt (quand envoyé à la fin d'une panne de processeur)


Si M2PA reçoit un message de SCTP avec une classe de message invalide ou un type de message non pris en charge dans l'en-tête de message commun, M2PA DEVRA éliminer le message.


Pour des types de message autres que Données d'utilisateur, le numéro de séquence vers l'avant (FSN, Forward Sequence Number) est réglé au FSN du dernier message Données d'utilisateur envoyé.


Si M2PA reçoit un message Données d'utilisateur avec un FSN qui n'est pas dans l'ordre, M2PA DEVRA éliminer le message.


Note : dans tous les calculs qui impliquent FSN et BSN, le programmeur devrait savoir que la valeur revient à zéro après avoir atteint sa valeur maximum.


Quand il y a un message à acquitter, M2PA DOIT accuser réception du message avec le prochain message Données d'utilisateur envoyé. Si il n'y a pas de message Données d'utilisateur disponible à envoyer quand il y a un message à acquitter, M2PA DEVRAIT générer et envoyer, sans délai, un message Données d'utilisateur sans charge utile de données. (En d'autres termes, dans le cas où MTP2 accuserait réception d'un message avec un FISU, M2PA DEVRAIT accuser réception du message avec un message Données d'utilisateur vide.) Le FSN pour ce message Données d'utilisateur vide n'est pas incrémenté. Il DOIT contenir le même FSN que le message Données d'utilisateur le plus récemment envoyé qui contenait des données. Retarder les accusés de réception peut dégrader les performances de SS7.


Si M2PA reçoit un message Données d'utilisateur vide, il NE DEVRA PAS envoyer d'accusé de réception de ce message.


Noter qu'il n'y a pas de raison de placer les messages État de liaison ou les messages Données d'utilisateur vides dans la mémoire tampon de retransmission de M2PA, car ces messages ne sont pas restitués lors de changements de liaison et le temporisateur T7 ne s'applique pas à eux.


Noter que comme SCTP assure une livraison fiable et ordonnée au sein du flux, M2PA n'effectue pas de retransmission. Néanmoins, M2PA DEVRA conserver les messages Données d'utilisateur transmis dans une file d'attente de retransmission jusqu'à ce qu'ils soient acquittés. Ces messages sont nécessaires au cas où MTP3 effectue une restitution de données au titre d'une procédure de changement de liaison.


Parce que les délais de propagation dans les réseaux IP sont plus variables que dans les réseaux SS7 traditionnels, un seul temporisateur T7 (délai excessif d'accusé de réception) comme dans MTP2, est inadéquat. Si un message n'est pas acquitté après une période égale à la valeur de T7, le temporisateur T7 DEVRA expirer.


4.2.2 Encombrement de liaison de signalisation MTP3

M2PA DEVRA détecter l'encombrement de transmission dans ses mémoires tampon conformément aux exigences pour l'encombrement de transmission des liaisons de signalisation dans MTP3, par exemple, [Q.704], paragraphe 3.8.


4.2.3 Changement de liaison

L'objectif du changement de liaison est de s'assurer que le trafic de signalisation porté par la liaison de signalisation indisponible est renvoyé sur la ou les liaisons de signalisation de remplacement aussi rapidement que possible tout en évitant des pertes de messages, des duplications, ou un mauvais séquençage. À cette fin, la procédure de changement de liaison inclut la restitution des données, qui est effectuée avant l'ouverture des liaisons de signalisation de remplacement au trafic détourné. La restitution des données comporte les étapes suivantes :

(1) mise à jour des mémoires tampon, c'est-à-dire, identifier tous les messages Données d'utilisateur dans la mémoire tampon de retransmission de la liaison de signalisation indisponible qui n'ont pas été reçus par le M2PA de l'extrémité distante, ainsi que les messages non transmis, et

(2) transférer ces messages aux mémoires tampon de transmission des liaisons de remplacement.


Noter que seuls les messages Données d'utilisateur qui contiennent des données sont restitués et transmis sur les liaisons de remplacement. Les messages État de liaison et les messages Données d'utilisateur vides NE DEVRONT PAS être restitués et transmis sur les liaisons de remplacement.


Les numéros de séquence M2PA font 24 bits. Les numéros de séquence vers l'avant et vers l'arrière de MTP2 ne font que sept bits de long. Donc, il est nécessaire que MTP3 s'accommode de plus grands numéros de séquence. Cela se fait par l'utilisation des messages Ordre de changement étendu (XCO, Extended Changeover Order) et Accusé de réception de changement étendu (XCA, Extended Changeover Acknowledgement) au lieu des messages Changement d'ordre (COO, Changeover Order) et Accusé de réception de changement (COA, Changeover Acknowledgement). Les messages XCO et XCA sont spécifiés dans [Q.2210] paragraphe 9.8.1 et dans [T1.111], paragraphe 15.4. Seuls les messages XCO et XCA de [Q.2210] ou [T1.111] sont exigés. Le BSN est placé dans le message XCO/XCA comme expliqué dans [Q.2210] et [T1.111].


Les primitives MTP3/MTP2 suivantes DOIVENT aussi utiliser les plus grands numéros de séquence :

- Confirmation BSNT

- Demande de restitution et FSNC


Si M2PA reçoit une demande de restitution et une demande de FSNC de MTP3, M2PA DEVRA restituer à partir de ses mémoires tampon et livrer à MTP3 dans l'ordre :

(a) tous les message Données d'utilisateur transmis en commençant par le premier message non acquitté avec un FSN supérieur au FSNC.

(b) tous les messages Données d'utilisateur non transmis.


Pour un changement d'urgence, MTP3 restitue seulement les messages non envoyés pour transmission sur la ou les liaisons de remplacement. Si M2PA reçoit une demande de restitution et une demande de FSNC sans valeur de FSNC, ou avec un FSNC invalide, alors M2PA DEVRA restituer à partir de ses mémoires tampon et livrer à MTP3 dans l'ordre tous les messages Données d'utilisateur non transmis.


La version TTC japonaise de MTP définie dans [JT-Q703] et [JT-Q704] a une demande de restitution (ainsi qu'une demande de restitution et de FSNC). La Restitution permet à MTP3 de restituer les messages non envoyés et non acquittés pour transmission sur la ou les liaisons de remplacement. Dans cette version de MTP, si M2PA reçoit une demande de restitution, alors M2PA DEVRA restituer à partir de ses mémoires tampons et livrer à MTP3 dans l'ordre :

(a) tout message Données d'utilisateur transmis mais non acquitté,

(b) tout message Données d'utilisateur non transmis.


4.2.3.1 Flux Données d'utilisateur multiples et changement de liaison

La procédure de changement de liaison rend problématique pour M2PA d'avoir plusieurs flux de données d'utilisateur dans une direction pour une liaison. La mise à jour des mémoires tampon devrait être faite séparément pour chaque flux de données d'utilisateur pour éviter les duplications ou les pertes de messages. Mais MTP3 prévoit un seul message XCO/XCA pour l'envoi du dernier numéro de séquence reçu.


Même avec un numérotage de séquence des messages Données d'utilisateur à la couche M2PA, il est nécessaire d'effectuer une mise à jour des mémoires tampon sur chaque flux. Comme les messages M2PA seront livrés sur plusieurs flux, il pourrait y avoir un trou dans les numéros de séquence M2PA à l'extrémité de réception quand commence la procédure de changement de liaison. Si seul le numéro de séquence M2PA est utilisé dans le message XCO/XCA, il y a une possibilité de perte de messages dans le trou, ou une duplication de messages après le trou.


Les liaisons M2PA avec plusieurs flux de données d'utilisateur seraient possibles si un message BSNT XCO/XCA multiple est défini dans MTP3, ou si MTP3 permet que plusieurs messages XCO/XCA (un pour chaque flux de données d'utilisateur) soient envoyés durant un changement de liaison. Cela sort du domaine d'application du présent document.


4.3 Considérations sur SCTP

Certaines procédures de M2PA peuvent être affectées par l'utilisation de SCTP comme couche de transport. Ces considérations sont discutées dans ce paragraphe.


4.3.1 Démarrage lent SCTP

SCTP contient un algorithme de démarrage lent pour contrôler la quantité de données injectées dans le réseau. L'algorithme permet à SCTP de sonder le réseau pour déterminer la capacité disponible. L'algorithme est invoqué dans ces cas : quand la transmission commence sur une association, après une période d'inactivité suffisamment longue, ou après la réparation de pertes détectée par le temporisateur de retransmission SCTP.


Il est possible que la transmission de messages M2PA PUISSE être retardée par le démarrage lent SCTP sous certaines conditions, incluant les suivantes :

(a) Alignement de liaison. L'alignement de liaison a lieu après l'établissement d'une association. SCTP invoque l'algorithme de démarrage lent parce que la transmission commence sur l'association.

(b) Changement de liaison. Les messages sont restitués d'une liaison (association) et transférés à une autre pour transmission. Si la seconde liaison avait été précédemment inactive, ou est dans le cours d'un alignement de liaison, SCTP peut invoquer l'algorithme de démarrage lent.

(c) Défaillance de chemin (multi rattachement). Si SCTP commute d'un chemin défaillant à un nouveau chemin, et si le nouveau chemin avait été inactif précédemment, SCTP peut invoquer l'algorithme de démarrage lent.

(d) Volume de trafic réduit. Chaque fois que M2PA envoie un faible volume de trafic sur une liaison et que le volume augmente, SCTP peut invoquer l'algorithme de démarrage lent..


Les programmeurs devraient connaître cette condition et savoir comment elle peut affecter les performances de M2PA. Dans certains cas, il est possible d'éviter les effets négatifs du démarrage lent. Par exemple, les messages État de liaison Épreuve envoyés durant la période d'épreuve peuvent être utilisés pour achever le démarrage lent avant que la liaison soit mise en service.


5. Exemples de procédures M2PA


En général, les messages passés entre MTP3 et M2PA sont les mêmes que ceux passés entre MTP3 et MTP2. M2PA interprète les messages de MTP3 et envoie le message approprié à SCTP. De même, les messages de SCTP sont utilisés pour générer un message significatif à MTP3.


Noter que dans ce paragraphe, les primitives entre MTP3 et M2PA sont désignées en utilisant la terminologie de MTP [Q.700] [Q.701] [Q.702] [Q.703] [Q.704] [Q.705]. Les communications entre M2PA et SCTP sont désignées en utilisant la terminologie de SCTP.


5.1 Initialisation (alignement) de liaison

Un exemple du flux de messages utilisé pour mettre en service une liaison SS7 est donné dans les Figures 11 et 12. L'alignement est fait par les deux extrémités de la liaison. Pour simplifier le diagramme, l'alignement est montré seulement sur une extrémité. Certains messages de l'extrémité distante ne sont pas montrés. On suppose dans cet exemple que SCTP a été initialisé.


MTP3 M2PA SCTP SCTP M2PA MTP3

. . . . . .

. Associe . . . .

. ------------> . . .

. . . . . .

. . (procédure d'association SCTP) . .

. . . . . .

. Communication active Communication active .

. <------------ ------------> .

. . . . . .

. État de liaison Hors service . .

. ------------------------------------> .

. . . . . .

Urgence OU . . . .

Fin d'urgence . . . .

------------> . . . .

. . . . . .

Début . . . . .

------------> . . . .

. . . . . .

. . . . . .

. État liaison Alignement . . .

. ------------------------------------> .

. . . . . .

. Lance temporisateur T2 . . .

. . . . . .

. . . État de liaison Alignement .

. <------------------------------------ .

. . . . . .

. Arrêt temporisateur T2 . . .

. . . . . .


Début de la période d'épreuve


Figure 11. Exemple d'initialisation de liaison - alignement


MTP3 M2PA SCTP SCTP M2PA MTP3

. . . . . .

. Lance temporisateur T3 . . .

. État de liaison Épreuve . . .

. ------------------------------------> .

. . . . . .

. . . État de liaison Épreuve .

. <------------------------------------ .

. . . . . .

. Arrêt temporisateur T3 . . .

. . . . . .

. Lance temporisateur T4 . . .

. État de liaison Épreuve . . .

. ------------------------------------> .

. ------------------------------------> .

. ------------------------------------> .

. ------------------------------------> .

. ------------------------------------> .

. ------------------------------------> .

. . . . . .

. Temporisateur T4 expire . . .

. . . . . .

Envoie État de liaison prêt (un ou plusieurs) et attend que l'extrémité distante achève sa période d'épreuve.

. . . . . .

. Lance temporisateur T1 . . .

. . . . . .

. État de liaison prêt . . .

. ------------------------------------> .

. . . . . .

. . . . . .

. . . État de liaison prêt .

. <------------------------------------ .

. . . . . .

. Arrêt temporisateur T1 . . .

. . . . . .

En service . . En service

<------------ . . ------------>

. . . . . .


MTP3 PEUT commencer à envoyer des messages de données.


Figure 12. Exemple d'initialisation de liaison - vérification


5.2 Transmission et réception de message

Les messages sont transmis en utilisant la primitive Demande de données de MTP3 à M2PA. La Figure 13 montre le cas où la liaison est En service. Le message est passé du MTP3 de la source au MTP3 de la destination.


MTP3 M2PA SCTP SCTP M2PA MTP3

. . . . . .

Message à transmettre . . . .

------------> . . . .

. . . . . .

. Envoie . . . .

. (Message de données) . . .

. ------------> . . .

. . . . . .

. . (SCTP envoie un message) . .

. . . . . .

. . . Reçoit .

. . . ------------> .

. . . . . .

. . . . Message reçu

. . . . ------------>

. . . . . .


Figure 13. Exemple d'initialisation de liaison - en service


5.3 Indication d'état de liaison

La Figure 14 donne l'exemple d'un État de liaison Indication. Si SCTP envoie une primitive Communication perdue à M2PA, M2PA notifie à MTP3 que la liaison est hors service. MTP3 répond de la façon usuelle.


MTP3 M2PA SCTP SCTP M2PA MTP3

. . . . . .

. Communication perdue . . .

. <------------ . . .

. . . . . .

Hors service . . . .

<------------ . . . .

. . . . . .


Figure 14. Exemple d'indication d'état de liaison


5.4 Message d'état de liaison (panne de processeur)

La Figure 15 montre comment M2PA répond à une panne de processeur locale. M2PA envoie un message État de liaison à son homologue. L'homologue M2PA notifie la panne à MTP3. MTP3 peut alors suivre les procédures de panne de processeur de [Q.703].


MTP3 M2PA SCTP SCTP M2PA MTP3

. . . . . .

. M2PA détecte une panne de processeur local .

. . . . . .

. État de liaison Panne de processeur . .

. ------------------------------------> .

. . . . . .

. . . . Panne de processeur distant

. . . . ------------>

. . . . . .

. État de liaison Processeur récupéré . .

. ------------------------------------> .

. . . . . .

. . . . Fin de panne du processeur distant

. . . . ------------>

. . . . . .

. . . État de liaison prêt .

. <------------------------------------ .

. . . . . .

. État de liaison prêt . . .

. ------------------------------------> .

. . . . . .

Message à transmettre . . . .

------------> . . . .

. . . . . .

. Données d'utilisateur . . .

. ------------------------------------> .

. . . . . .


Figure 15. Exemple de message d'état de liaison – panne de processeur


La Figure 16 donne un exemple de panne de processeur plus en détail. Tous les messages M2PA de cet exemple sont envoyés sur le flux de données (flux 1).


A B

MTP3 M2PA SCTP SCTP M2PA MTP3

. . . . . .

6 Messages à transmettre. . . .

------------> . . 6 Messages à transmettre

. . . . <------------

. Données d'util. FSN=1 . . .

. ------------------------------------> .

. Données d'util. FSN=2 . . .

. ------------------------------------> .

. Données d'util. FSN=3 . . .

. ------------------------------------> .

. . . Données d'utilisateur FSN=11 .

. <------------------------------------ .

. . . Données d'utilisateur FSN=12 .

. <------------------------------------ .

. . . Données d'utilisateur FSN=13 .

. <------------------------------------ .

Le côté A détecte LPO.

. . . . . .

. . . Données d'utilis. FSN=14 BSN=3 .

. <------------------------------------ .

. . . Données d'utilis. FSN=15 BSN=3 .

. <------------------------------------ .

. . . Données d'utili. FSN=16 BSN=3 .

. <------------------------------------ .

. LS PO FSN=3 BSN=11 . . .

. ------------------------------------> .

. . . . Panne du processeur distant

. . . . ------------>

En LPO, A doit mettre en mémoire tampon les messages 14-16 sans accusé de réception. A peut continuer de transmettre les messages de MTP3, et accuser réception des messages qui ont été reçus avant le LPO.

. . . . . .

. Données d'utilisateur FSN=4 BSN=13 . .

. ------------------------------------> .

. Données d'utilisateur FSN=5 BSN=13 . .

. ------------------------------------> .

. Données d'utilisateur FSN=6 BSN=13 . .

. ------------------------------------> .

. . . . . .

En RPO, B peut continuer d'accuser réception des messages. Supposons que B reçoive les messages 4 et 5, mais n'ait pas encore traité 6.

. . . . . .

. (vide) Données d'utilisateur FSN=16 BSN=4 .

. <------------------------------------ .

. (vide) Données d'utilisateur FSN=16 BSN=5 .

. <------------------------------------ .


LPO se termine à A. A purge 14-16 (les messages en mémoire tampon sans accusé de réception).


. . . . . .

. LS PR FSN=6 BSN=13 . . .

. ------------------------------------> .

. . . . Fin de panne du processeur distant

. . . . ------------>

. . . . . .


Supposons que B ait traité le message 5, mais pas le message 6. B purge le message 6 de sa mémoire tampon de réception. B le notifie à A avec le message État de liaison prêt avec BSN=5, le dernier message qui a été traité en B.


. . . . . .

. . . . . .

. . . LS prêt FSN=13 BSN=5 . .

. <------------------------------------ .

. . . . . .


B a achevé la synchronisation des numéros de séquence et a envoyé un LS prêt, de sorte qu'il est capable de reprendre l'envoi de données à ce moment avec les nouveaux numéros de séquence (commençant par FSN=14).


. . . . . .

. . . . . Message à transmettre

. . . . <------------

. . . Données d'util. FSN=14 BSN=5 .

. <------------------------------------ .

. . . . . .


A peut utiliser l'information État de liaison prêt pour resynchroniser ses numéros de séquence à commencer avec FSN=6 dans le prochain message Données d'utilisateur.


. . . . . .

. LS prêt FSN=5 BSN=13 . . .

. ------------------------------------> .

. . . . . .

A a terminé la synchronisation de numéro de séquence et a reçu et envoyé un LS prêt ; il est capable de reprendre l'envoi de données dès ce moment avec les nouveaux numéros de séquence et à accuser réception des données reçues après avoir reçu LS prêt.


. . . . . .

. . . . . .

. Données d'utilisateur FSN=5 BSN=14 (vide) .

. ------------------------------------> .

. . . . . .

Message pour . . . Message pour

transmission . . transmission

------------> . . <------------

. Données d'utilisateur FSN=6 BSN=14 . .

. ------------------------------------> .

. . . Données d'util. FSN=15 BSN=5 .

. <------------------------------------ .

. . . . . .

. . (vide) Données d'utilisateur FSN=15 BSN=6 .

. <------------------------------------ .

. Données d'utilisateur FSN=6 BSN=15 (vide) .

. ------------------------------------> .

. . . . . .

. . . . . .

. . . . . .


Figure 16. Exemple de panne et récupération de processeur


5.5 Contrôle de flux de niveau 2

Les Figures 17 et 18 illustre la procédure de contrôle de flux de niveau 2. Dans la Figure 17, l'encombrement cesse avant l'arrivée à expiration du temporisateur. La Figure 18 montre le cas où T6 expire.


MTP3 M2PA SCTP SCTP M2PA MTP3

. . . . . .

. Selon la mise en œuvre . . .

. détermination du début . . .

. d'encombrement en réception . .

. . . . . .

. État de liaison Occupé . . .

. ------------------------------------> .

. . . . . .

. . . . Lance temporisateur T6

. . . . . .

. Selon la mise en œuvre . . .

. détermination ode la fin . . .

. d'encombrement en réception . .

. . . . . .

. État de liaison Fin d'occupation . .

. ------------------------------------> .

. . . . . .

. . . . Arrêt du temporisateur T6

. . . . . .


Figure 17. Exemple de commande de flux de niveau 2 – l'encombrement cesse


MTP3 M2PA SCTP SCTP M2PA MTP3

. . . . . .

. Selon la mise en œuvre . . .

. détermination du début . . .

. d'encombrement en réception . . .

. . . . . .

. État de liaison Occupé . . .

. ------------------------------------> .

. . . . . .

. . . . Lance temporisateur T6

. . . . : .

. . . . : .

. . . . T6 arrive à expiration

. . . . . .

. . État de liaison Hors service .

. <------------------------------------ .

. . . . . .

. . . . Hors service.

. . . . ------------>

. . . . . .


Figure 18. Exemple de commande de flux de niveau 2 – le temporisateur T6 expire


5.6 Signalisation d'encombrement de liaison à MTP3

Dans la Figure 19, M2PA notifie à MTP3 le début d'encombrement et sa fin. La notification inclut le niveau d'encombrement, si des niveaux d'encombrement sont définis.


MTP3 M2PA SCTP SCTP M2PA MTP3

. . . . . .

. Selon la mise en œuvre . . .

. détermination de M2PA . . .

. du début d'encombrement . . .

. de transmission (niveau). . .

. . . . . .

Indication d'encombrement . . .

(niveau) . . . . .

<------------ . . . .

. . . . . .

. Selon la mise en œuvre . . .

. détermination de M2PA . . .

. de la fin d'encombrement. . .

. de transmission (niveau). . .

. . . . . .

Indication d'encombrement . . .

(niveau) . . . . .

<------------ . . . .

. . . . . .


Figure 19. Exemple: Encombrement de liaison de signalisation MTP3


5.7 Désactivation de liaison

La Figure 20 montre un exemple de désactivation de liaison. MTP3 peut demander qu'une liaison soit mise hors service.


MTP3 M2PA SCTP SCTP M2PA MTP3

. . . . . .

Arrêt . . . . .

------------> . . . .

. . . . . .

. État de liaison Hors service . .

. .------------------------------------> . .

. . . . . .

Hors service . . . . .

<------------ . . . .

. . . . . .


Figure 20. Exemple de désactivation de liaison


5.8 Remplacement de liaison

Dans la Figure 21, MTP3 effectue un changement parce que la liaison est hors service. MTP3 choisit une liaison différente pour retransmettre les messages non acquittés et non envoyés.


MTP3 M2PA SCTP SCTP M2PA MTP3

. . . . . .

. Communication perdue . . .

. <------------ . . .

. . . . . .

Hors service . . . .

<------------ . . . .

. . . . . .

Restitution BSNT . . . .

------------> . . . .

. . . . . .

Confirmation BSNT . . . .

<------------ . . . .

. . . . . .

XCO (BSNT) sur autre liaison . . .

------------------------------------------------------------>

. . . . . .

. . . . Restitution BSNT

. . . . <------------

. . . . . .

. . . . Confirmation BSNT

. . . . ------------>

. . . . . .

. . . . . XCA (BSNT)

<------------------------------------------------------------

. . . . . .

Demande restitution . . . .

et FSNC . . . . .

------------> . . . .

. . . . . .

Message restitué . . . .

<------------ . . . .

. : . . . . .

. : . . . . .

<------------ . . . .

. . . . . .

Restitution achevée . . . .

<------------ . . . .

. . . . . .

Envoi des messages sur une autre liaison.


Figure 21. Exemple de remplacement de liaison


6. Considérations sur la sécurité


M2PA est conçu pour porter les messages de signalisation du service de téléphonie. À ce titre, M2PA DOIT englober les besoins de sécurité de plusieurs parties :

- l'utilisateur final des services

- le fournisseur de réseau

- les applications impliquées


Des exigences supplémentaires PEUVENT venir des règlementations locales.


Bien que les besoins de sécurité de ces parties puissent se recouper, ils peuvent n'être pas identiques. Toute solution de sécurité DEVRAIT satisfaire tous les besoins des différentes parties.


Consulter la [RFC3788] pour une discussion des exigences de sécurité et les lignes directrices sur l'utilisation des protocoles de sécurité. Les mises en œuvre de M2PA DOIVENT suivre les lignes directrices de la [RFC3788].


7. Considérations relatives à l'IANA

7.1 Identifiant de protocole de charge utile SCTP

L'allocation du numéro d'accès d'utilisateur enregistré SCTP pour M2PA est 3565. Le numéro d'accès d'utilisateur enregistré TCP 3565 est aussi alloué à M2PA, au cas où une spécification pour M2PA sur TCP serait créée.


La valeur allouée par l'IANA pour l'identifiant de protocole de charge utile dans le tronçon de données de charge utile SCTP est M2PA 5


L'identifiant de protocole de charge utile SCTP est inclus dans chaque tronçon de données SCTP, pour indiquer quel protocole porte SCTP. Cet identifiant de protocole de charge utile n'est pas utilisé directement 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 de données.


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


7.2 Extensions de protocole M2PA

Ce protocole peut être étendu par l'IANA de trois façons :

- par la définition de classes de message supplémentaires,

- par la définition de type de messages 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 message fait partie intégrante des couches d'adaptation SIGTRAN. Donc, ces extensions sont allouées par l'IANA par action de consensus de l'IETF comme défini dans la [RFC2434].


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


Les valeurs définies pour les classes, types et paramètres de message figurent dans le registre de la couche d'adaptation d'utilisateur de signalisation (sigtran-adapt).


7.2.1 Classes de message définies par l'IETF

La documentation pour une nouvelle classe de message DOIT inclure les informations suivantes :

(a) un nom long et un nom court pour la classe de message.

(b) une description détaillée de l'objet de la classe de message.


7.2.2 Types de message définis par l'IETF

La documentation du type de message DOIT contenir les informations suivantes :

(a) un nom long et un nom court pour le nouveau type de message,

(b) une description détaillée de la structure du message,

(c) une définition détaillée et une description de l'utilisation prévue de chaque champ du message,

(d) une description procédurale détaillée de l'utilisation du nouveau type de message dans le fonctionnement du protocole,

(e) une description détaillée des conditions d'erreur lors de la réception de ce type de message.


Quand une mise en œuvre reçoit ce type de message qu'elle NE PREND PAD en charge, elle DOIT éliminer le message.


7.2.3 Extension de paramètres définies par l'IETF

La documentation des paramètres de message DOIT contenir les informations suivantes :

(a) le nom du type de paramètre,

(b) une description détaillée de la structure du champ de paramètre,

(c) une définition détaillée de chaque composant de la valeur du paramètre,

(d) une description détaillée de l'utilisation prévue de ce type de paramètre, et une 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.


7.2.4 Valeurs définies

On donne ici la liste des valeurs définies dans ce document qui devraient être incluses dans le registre de couche d'adaptation d'utilisateur de signalisation (sigtran-adapt).


Les valeurs suivantes de classe de message sont définies dans ce document:

Valeur (décimal)

Classe de message

11

Messages M2PA


Les valeurs suivantes de type de message sont définies dans ce document:

Valeur (décimal)

Type de message

1

Données d'utilisateur

2

État de liaison


8. Remerciements


Les auteurs tiennent à remercier les personnes suivantes de leurs précieux commentaires et suggestions : Brian Tatum, Wayne Davis, Cliff Thomas, Jeff Copley, Monique Bernard, Malleswar Kalla, Ian Rytina, Greg Sidebottom, Al Varney, Jeff Craig, et Andrew Booth.


9. Références

9.1 Références normatives


[JT-Q703] Telecommunication Technology Committee (TTC), "Message Transfer Part Signalling Link," TTC Standard JT-Q703, version 3 (27 avril 1994).


[JT-Q704] Telecommunication Technology Committee (TTC), "Message Transfer Part Signalling Network Functions," TTC Standard JT-Q704, version 4 (30 mai 2002).


[Q.703] Recommandation UIT-T Q.703, "Système de signalisation n° 7 – Liaison de signalisation", juillet 1996.


[Q.704] Recommandation UIT-T Q.704, "Sous système de transfert de message - Fonctions et messages de réseau de signalisation", juillet 1996.


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


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


[RFC0791] J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet", STD 5, septembre 1981.


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


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


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


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


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


[T1.111] ANSI T1.111-2001, "American National Standard for Telecommunications - Signaling System Number 7 (SS7) - Message Transfer Part (MTP)", American National Standards Institute (février 2001).


9.2 Références pour information


[Q.700] Recommandation UIT-T Q.700, "Introduction au système de signalisation CCITT n° 7", mars 1993.


[Q.701] Recommandation UIT-T Q.701, "Description fonctionnelle du sous-système de transfert de message (MTP) du système de signalisation n° 7", mars 1993.


[Q.702] Recommandation UIT-T Q.702, "Liaison de données de signalisation", novembre 1988.


[Q.705] Recommandation UIT-T Q.705, "Système de signalisation n° 7 – Structure de réseau de signalisation", mars 1993).


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


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


Adresse des auteurs


Tom George

Brian Bidulock

Ram Dantu, Ph.D.

Plano, TX

OpenSS7 Corporation

Department of Computer Science

USA

1469 Jeffreys Crescent

University of North Texas

téléphone : +1-972-985-4594

Edmonton, AB T6L 6T1

Denton, TX 76203

mél : tgeorge_tx@verizon.net

Canada

USA


téléphone : +1-780-490-1141

téléphone : +1-940-565-2822


mél : bidulock@openss7.org

mél : rdantu@unt.edu


Hanns Juergen Schwarzbauer

Ken Morneault

SIEMENS AG

Cisco Systems Inc.

Hofmannstr. 51

13615 Dulles Technology Drive

81359 Munich

Herndon, VA 20171

Germany

USA

téléphone : +49-89-722-24236

téléphone : +1-703-484-3323

mél : HannsJuergen.Schwarzbauer@Siemens.com

mél : kmorneau@cisco.com


Déclaration complète de droits de reproduction


Copyright (C) The Internet Society (2005).


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


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


Propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

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


Remerciement

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