Extensions de système de signalisation de réseau privé numérique (DPNSS)/système n° 2 de signalisation d'accès numérique (DASS 2) au protocole IUA

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 mécanisme pour ramener les messages du système n° 1 de signalisation de réseau privé numérique (DPNSS 1, Digital Private Network Signaling System 1) et du système n° 2 de signalisation d'accès numérique (DASS 2, Digital Access Signaling System 2) sur IP en étendant le protocole de couche 1 d'adaptation d'utilisateur RNIS (IUA, ISDN User Adaptation) défini dans la RFC 3057. DPNSS 1, spécifié dans ND1301:2001/03 (anciennement BTNR 188) est utilisé pour interconnecter les commutateurs privés (PBX, Private Branch Exchange) dans un réseau privé. DASS 2, spécifié dans BTNR 190, est utilisé pour connecter des PBX au RTPC. Le présent document vise à devenir un appendice à IUA et à être la base de la mise en œuvre de l'adaptation d'utilisateur DPNSS 1/DASS 2 (DUA, DPNSS 1/DASS 2 User Adaptation).

1. Introduction

Le présent document décrit une méthode de mise en œuvre de renvoi des messages du système n° 1 de signalisation de réseau prive numérique (DPNSS 1, Digital Private Network Signaling System 1) [DPNSS] (appelé ici simplement DPNSS) et du système n° 2 de signalisation d'accès numérique (DASS 2, Digital Access Signaling System 2) [BTNR] sur IP en utilisant une version modifiée du protocole d'adaptation d'utilisateur RNIS (IUAP, ISDN User Adaptation Protocol) [RFC3057]. L'adaptation d'utilisateur DPNSS/DASS 2 (DUA, DPNSS/DASS 2 User Adaptation) se place par dessus IUA en définissant les extensions nécessaires à IUA pour la mise en œuvre de DPNSS/DASS2.

1.1 Domaine d'application

Il y a besoin d'une livraison du protocole de signalisation de réseau à commutation de circuits (SCN, Switched Circuit Network) provenant d'une passerelle de signalisation (SG, Signaling Gateway) DPNSS à un contrôleur de passerelle de supports (MGC, Media Gateway Controller). Le mécanisme de livraison devrait prendre en charge les protocoles suivants :

- DPNSS (système de signalisation de réseau prive numérique) [DPNSS]

- DASS 2 (système n° 2 de signalisation d'accès numérique) [BTNR]

Sauf mention spécifique, les détails de ce document s'appliquent à DPNSS et à DASS 2.

1.2 Terminologie

Canal de données (D-channel, Data channel) – intervalle de temps de 64 kbit/s qui fonctionne comme un canal de signalisation commun sur une interface à 2048 kbits/s ou une interface à 1544 kbits/s provisionnée pour porter la signalisation DPNSS.

Canal DPNSS – les intervalles de temps 1 à 15 et 17 à 31 sur une interface à 2048 kbits/s ou les intervalles de temps 1 à 23 sur une interface à 1544 kbits/s interface sont appelés des canaux DPNSS. Ce sont les canaux de trafic qui portent la voix ou le trafic de données.

- DPNSS prend en charge 60 canaux (30 réels et 30 virtuels)

- DASS2 prend en charge 30 canaux (tous réels)

Connexion de liaison de données (DLC, Data Link Connection) – processus de niveau 2 qui contrôle le transfert des messages de niveau 3 au nom d'un canal DPNSS. Une DLC identifie de façon univoque un canal DPNSS.

- DPNSS prend en charge 60 DLC (30 réelles et 30 virtuelles)

- DASS2 prend en charge 30 DLC (toutes réelles)

Liaison DPNSS – la collection logique de canaux de données et des canaux DPNSS associés dans une interface à 2048 kbits/s ou une interface à 1544 kbits/s est appelée une "liaison DPNSS".

Canal réel – canal de signalisation avec un canal de trafic associé.

Canal virtuel – canal de signalisation sans canal de trafic associé.

NT1 – période minimum de retransmission DPNSS.

NT2 – délai minimum d'accusé de réception post retransmission DPNSS.

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.3 Vue d'ensemble de DPNSS

DPNSS est une interface standard de l'industrie (ref. ND1301:2001/03) [DPNSS], qui est définie entre un PBX et un réseau d'accès (AN, Access Network). DPNSS étend des facilités qui ne sont normalement disponibles qu'entre des extensions sur un seul PBX à toutes les extensions sur des PBX qui sont connectés dans un réseau privé. DPNSS était à l'origine dérivé du système n° 1 de signalisation d'accès numérique de British Telecom (DASS I) et a été amélioré lorsque il a été nécessaire de satisfaire aux exigences des réseaux privés. Certaines de ces améliorations ont été incorporées dans DASS 2 [BTNR]. DPNSS utilise une interface de système de transmission numérique à 2048 kbits/s ou 1544 kbits/s, comme le montre la Figure 1.

---------- ---------- o--o

| | 2048 kbits/s | |------- /\

| |--------------| | --

| PBX | 1544 kbits/s | AN |

| |--------------| | o--o

| | | |------- /\

---------- ---------- --

Figure 1

Le canal 16 est sur une interface à 2048 kbits/s (E1) et le canal 24 est sur une interface à 1544 kbits/s (T1) et est réservé aux communications de données entre LE et AN. Les canaux réservés aux données sont appelés "canaux de données" ou "canaux-D".

Les canaux-D sont le support physique utilisé pour échanger des données entre les entités homologues du protocole DPNSS. Une collection logique de canaux-D et les canaux DPNSS associés est appelée une "liaison DPNSS".

1.4 Architecture proposée de retour DPNSS

****** DPNSS ****** IP *******

*PBX *---------------* SG *--------------* MGC *

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

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

|DPNSS| (NIF) |DPNSS|

| L3 | | L3 |

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

| | | | DUA| | DUA |

|DPNSS| |DPNSS+----+ +-----+

| L2 | | L2 |SCTP| |SCTP |

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

| | | | IP + | IP |

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

NIF (Nodal Interworking function) fonction d'interfonctionnement nodale

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

DUA (DPNSS User Adaptation Layer Protocol) protocole de couche d'adaptation d'utilisateur DPNSS

2. Changements par rapport à IUA

Cette section précise les différences entre DUA et IUA.

2.1 Nouvelle classe de messages pour DUA

Les primitives de couche 2 à couche 3 DPNSS/DASS2 [DPNSS], [BTNR] doivent être identifiables à partir des messages de transport de primitive de frontière IUA et les messages de transport de primitive des autres extensions IUA (c'est-à-dire, V5 ou GR-303). Donc, il est nécessaire d'utiliser un paramètre de classe de message différent pour les messages DUA.

Pour toutes les primitives de frontière d'interface DPNSS/DASS2, une nouvelle classe de messages est introduite :

13 : message de transport de primitives de frontière DPNSS/DASS2 (DPTM, DPNSS/DASS2 Boundary Primitives Transport Message)

Comme dans IUA, les autres classes de messages valides pour DUA sont :

0 : message de gestion (MGMT, Management)

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

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

2.2 En-tête de message

L'en-tête de message IUA [RFC3057] DOIT être utilisé avec les messages DPTM, mais le champ DLCI dans le paramètre DLCI est formaté différemment. La Figure 2 montre l'en-tête de message IUA avec identifiant d'interface entier.

0 1 2 3

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

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

| Étiquette (0x1) | Longueur |

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

| Identifiant d'interface (entier) |

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

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

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

| DLCI | réservé |

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

Figure 2 : En-tête de message IUA (identifiant d'interface entier)

Dans DUA, le champ DLCI a un format différent, conformément à ND1301:2001/03 (anciennement BTNR 188) [DPNSS].

0 1

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

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

| Réservé |V|0|N° de canal|1|

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

Réservé : 7 bits. Devrait être réglé tout à "0" et ignoré à réception.

Bit V : 1 bit. Le bit V est utilisé pour déterminer si le message est pour une DLC particulière ou si il s'applique pour toutes les DLC de la porteuse. Les valeurs possibles du bit V sont données ci-dessous.

Cette valeur du bit V n'est utilisée que par les messages Établir et Libérer. Les messages de données devraient ignorer cette valeur. Cet indicateur est fourni pour qu'une seule commande puisse être produite pour établir ou libérer toutes les DLC dans une liaison DPNSS.

Pour le numéro de canal (N° de canal) les valeurs valides sont de 0 à 63 pour DPNSS et de 0 à 31 pour DASS 2. Parce que DASS 2 ne prend pas en charge les DLC virtuelles et n'a donc que 32 DLC.

2.3 Message Unit Data

La couche 2 de DPNSS n'a pas de primitive unit data, et donc, les messages Unit Data (Demande, Indication) sont invalides pour une application DUA. Les messages Data Request et Indication (messages de types 1 et 2, respectivement) seront utilisés avec DUA.

2.4 Message État de DLC

Pour DUA, un nouveau message est nécessaire pour porter l'état des DLC. Ce message sera un message de gestion (c'est-à-dire, cette classe de messages sera une valeur de 0 pour Gestion). Les types de messages suivants seront utilisés pour ces messages :

5 : Demande d'état de DLC

6 : Confirmation d'état de DLC

7 : Indication d'état de DLC

Les messages État de DLC sont échangés entre les couches DUA homologues pour demander, confirmer, et indiquer l'état des DLC. Les messages État de DLC contiennent l'en-tête de message commun, suivi par l'en-tête de message IUA, comme décrit au paragraphe 2.2.

De plus, les messages Confirmation d'état de DLC et Indication d'état de DLC vont contenir le nouveau paramètre, appelé Paramètre d'état de DLC. Ce paramètre a le format suivant pour une interface E1 :

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

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

| NA| D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15|

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

| NA|D17|D18|D19|D20|D21|D22|D23|D24|D25|D26|D27|D28|D29|D30|D31|

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

| NA|D33|D34|D35|D36|D37|D38|D39|D40|D41|D42|D43|D44|D45|D46|D47|

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

| NA|D49|D50|D51|D52|D53|D54|D55|D56|D57|D58|D59|D60|D61|D62|D63|

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

NA signifie Non applicable. D0 et D16 ne sont pas applicables pour une interface E1 parce que l'intervalle de temps 0 est utilisé pour le tramage E1 et les bits de synchronisation et l'intervalle de temps 16 sont utilisés pour la signalisation. Pour DPNSS, il y aura un total maximum de 60 DLC (30 réelles + 30 virtuelles) et dans le cas de DASS2 il y aura un total de 30 DLC (pas de virtuelles).

Ce paramètre a le format suivant pour une interface T1 :

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

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

| D0| D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15|

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

|D16|D17|D18|D19|D20|D21|D22| NA|D24|D25|D26|D27|D28|D29|D30|D31|

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

| NA|D33|D34|D35|D36|D37|D38|D39|D40|D41|D42|D43|D44|D45|D46| NA|

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

D23 n'est pas applicable à une interface T1 parce que l'intervalle de temps 23 est utilisée pour la signalisation. Pour DPNSS, il va y avoir un total maximum de 46 DLC (23 réelles + 23 virtuelles) et en cas de DASS2 il y aura un total de 23 DLC (pas de virtuelles).

Le paramètre porte l'état des DLC en utilisant deux bits pour chaque DLC. Les valeurs possibles pour les deux bits sont :

Pour DASS 2, la valeur 00 (Hors service) est invalide parce que la DLC DASS 2 n'a pas cet état. De plus, l'état Repos est un état transitoire local à la DLC, donc, une valeur ne lui est pas allouée.

Pour DASS 2, il n'y a pas de DLC virtuelles et donc, les informations doivent être portées sur seulement 32 DLC. Donc, le message d'état aura une longueur de 12 pour un message d'état de DLC DASS 2.

2.5 Messages de gestion (MGMT)

Seuls les messages Notifier et Erreur sont valides pour DUA. Les messages d'état TEI ne sont pas utilisés.

2.5.1 Message d'erreur

Le message ERR est envoyé quand une valeur invalide ou un message non reconnue est trouvé dans un message entrant.

Le paramètre Code d'erreur indique la raison du message Erreur. Voici les valeurs acceptées dans IUA.

Dans DUA, les codes d'erreur 0x0a, 0x0b, et 0x0c sont invalides, car ils sont spécifiques du RNIS.

Les codes d'erreur supplémentaires suivants sont pris en charge dans DUA:

L'erreur "Numéro de canal hors gamme" est envoyée si un message est reçu avec un numéro de canal supérieur à 63 pour DPNSS ou 31 pour DASS 2.

L'erreur "Numéro de canal non configuré" est envoyée si un message est reçu avec un numéro de canal qui n'est pas configuré.

3. Considérations relatives à l'IANA

L'IANA a alloué une valeur de DUA au champ Identifiant de protocole de charge utile SCTP qui est utilisée dans les tronçons de données de charge utile SCTP. La valeur suivante DEVRAIT être utilisée pour le champ Identifiant de protocole de charge utile SCTP pour DUA :

Identifiant de protocole de charge utile SCTP = "10"

4. Utilisation de l'identifiant de protocole de charge utile SCTP

En option, la valeur IUA pour l'identifiant de protocole de charge utile SCTP PEUT aussi être utilisée pour DUA, par exemple, si on veut ramener RNIS et DPNSS sur la même association SCTP. Cependant, il est recommandé d'utiliser des identifiant de protocole de charge utile SCTP séparés (10 pour DUA et 1 pour IUA) comme option principale, même dans des scénarios où RNIS et DPNSS sont portés sur la même association SCTP.

L'identifiant de protocole de charge utile SCTP de "10" DEVRAIT être utilisé pour DUA si seul DPNSS est ramené sur une association SCTP (c'est-à-dire, dans des scénarios où le portage simultané de RNIS et de DPNSS sur la même association N'EST PAS exigé).

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

5. Séquence de messages en DUA

On donne ici un exemple de flux de messages pour l'établissement d'une liaison de données sur un canal de signalisation, passant des PDU et libérant une liaison de données sur un canal DPNSS. Une association active entre MGC et SG est établie avant les flux de message suivants.

5.1 Réinitialisation d'une seule DLC

i) Réussie

ii) Échec (défaillance de liaison)

5.2 Réinitialistion de toutes les DLC d'une liaison

Si une ou plusieurs DLC restent hors service après cette procédure (par exemple, à cause de la gestion de couche 2) le MGC peut soit réessayer cette DLC avec une Est Req(Ind=1) indiquant la DLC spécifique, soit avec une Est Req(Ind=0) et le SG va réessayer la DLC appropriée qui est hors service (HS).

5.3 Transfert d'informations sur un DLC

5.4 Libération de liaison (une seule DLC)

5.5 Libération de liaison (toutes les DLC)

5.6 Obtention de l'état de la liaison

5.7 Conditions d'erreur

6. Considérations sur la sécurité

Les considérations sur la sécurité pour le protocole d'adaptation d'utilisateur RNIS (IUAP, ISDN User Adaptation Protocol) [RFC3057] (Section 6) et les considérations sur la sécurité pour le document des protocoles SIGTRAN [RFC3788] s'appliquent aussi au présent document.

7. Références normatives

[BTNR] BTNR (British Telecom Network Requirements) 190 Issue 2 "Digital Access Signaling System No 2".

[DPNSS] Ofcom/NICC ND1301:2001/03, DPNSS [188], "Digital Private Signalling System No 1 (DPNSS 1)" (anciennement BTNR 188).

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

[RFC3057] K. Morneault et autres, "Couche d'adaptation RNIS Q.921-utilisateur", février 2001. (Obsolète, voir RFC4233) (MàJ par RFC3807) (P.S.)

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

8. Remerciements

Les auteurs tiennent à remercier Shashi Kumar et Venkatesh Seshasayee de Wipro Technologies de leurs utiles suggestions et commentaires.

Adresse des auteurs

Toute correspondence relative au présent document devrait être envoyée aux adresses suivantes :

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.