Network Working Group E

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

Le présent document définit un mécanisme pour le transport de messages V5.2 sur IP en utilisant le protocole de transmission de contrôle de flux (SCTP, Stream Control Transmission Protocol). Ce protocole peut être utilisé entre une passerelle de signalisation (SG, Signaling Gateway) et un contrôleur de passerelle de supports (MGC, Media Gateway controller). On suppose que la SG reçoit de la signalisation V5.2 sur une interface V5.2 standard.

Le présent document s'appuie sur le protocole de couche d'adaptation d'utilisateur RNIS de la [RFC3057]. Il définit toutes les extensions nécessaires au protocole IUA pour la mise en œuvre du protocole V5UA.

Table des Matières

1. Introduction

1.1 Domaine d'application

1.2 Terminologie

1.3 Vue d'ensemble de V5.2

1.4 Distribution des responsabilités entre MGC et SG

1.5 Modèle client/serveur

1.6 Ajout aux primitives de frontière

2. Conventions

3. Gestion de flux SCTP

4. Architecture proposée de transport V5.2

4.1 En-tête de message V5UA

4.2 Conventions V5 de dénomination des identifiants d'interface

4.3 Ajouts V5 aux primitives IUA de frontière

4.4 Messages d'état de liaison (Début de rapport, Fin de rapport, Indication)

4.5 Messages de bit Sa (Demande d'établissement, Confirmation d'établissement, Demande/Indication d'état)

4.6 Message d'indication d'erreur

5. Procédures

5.1 Défaillance de la couche V5

5.2 Perte de l'homologue V5UA

5.3 Surcharge du canal C sur SG

6. Exemples

6.1 Procédure (réussie) d'identification de liaison

7. Considérations sur la sécurité

8. Considérations relatives à l'IANA

8.1 Identifiants de protocole de charge utile SCTP

8.2 Numéro d'accès V5UA

9. Remerciements

10. Références

10.1 Références normatives

10.2 Références pour information

11. Adresse des auteurs

12. Déclaration complète de droits de reproduction

Le présent document décrit une méthode de mise en œuvre de retour de messagerie V5.2 sur IP en utilisant une version modifiée du protocole de couche d'adaptation d'utilisateur RNIS (IUAP, ISDN User Adaptation Layer Protocol) [RFC3057]. V5UA s'établit par dessus IUA, définissant les extensions nécessaires à IUA pour une mise en œuvre de V5.2.

Comme V5UA est destiné à être une extension de IUAP, tout ce qui est défini dans la [RFC3057] est aussi valide pour V5UA sauf mention contraire dans le présent document.

Le présent document ne décrit pas la norme V5 elle-même. Le protocole V5 est défini par les normes ETSI [300324-1], [300347-1]. Toute description du protocole V5 dans le présent document est destinée à faciliter la compréhension du texte.

On a besoin d'un protocole de signalisation de réseau à commutation de circuits (SCN, Switched Circuit Network) entre une passerelle de signalisation (SG, Signaling Gateway) V5.2 et un contrôleur de passerelle de support (MGC, Media Gateway Controller) analogue à la mise en œuvre de la couche d'adaptation d'utilisateur RNIS (IUA, ISDN User Adaptation Layer) Q.921 comme décrit dans la [RFC3057].

Le présent document prend en charge l'accès téléphonique analogique, l'accès RNIS au débit de base, et l'accès RNIS au débit primaire sur une interface V5.2.

Comme la couche 2 de V5.2, et particulièrement la couche 3, diffèrent de la couche d'adaptation Q.921 [300125] et Q.931, la norme IUA doit être étendue pour satisfaire aux besoins de la prise en charge de V5.2.

Protocole de connexion de canal support (BCC, Bearer Channel Connection) – protocole qui permet au commutateur local (LE, Local Exchange) de donner pour instruction au réseau d'accès (AN, Access Network) d'allouer des canaux de support, soit singuliers, soit en multiples, à la demande.

Canal de communication (Canal C) – intervalle de temps de 64 kbit/s sur une interface V5.2 provisionnée pour porter des chemins de communication.

- liaison de données de couche 2 qui porte le protocole de contrôle de liaison

- chacune des liaisons de données de couche 2 portant le protocole de protection

- toutes les données RNIS de type Ds provenant d'un ou plusieurs accès d'utilisateur

- toutes les données RNIS de type p provenant d'un ou plusieurs accès d'utilisateur

- toutes les données RNIS de type t provenant d'un ou plusieurs accès d'utilisateur

Note : Cette définition inclut la possibilité qu'il puisse y avoir plus d'un chemin C du même type d'informations, alloué chacun à un canal C logique différent.

Adresse de fonction d'enveloppe (EFA, Envelope Function Address) – nombre de 13 bits, allant de 0 à 8191 (décimal). Une EFA identifie de façon univoque un des cinq protocoles V5.2, ou un agent RNIS rattaché à un AN. La liste suivante contient les valeurs possibles pour l'EFA :

Automate à états fonctionnels de couche 1 (L1 FSM, Layer 1 Functional State Machine) – automate à états fonctionnels dans la gestion de système V5 qui suit et contrôle les états des liaisons physiques E1 sur l'interface.

Canal de communication logique (Logical C-channel, Logical Communication channel) – groupe d'un ou plusieurs chemins C, tous de types différents, mais excluant le chemin C pour le protocole de protection.

Multi-liaison - collection de plus d'une liaison à 2048 kbit/s qui ensemble constituent une interface V5.2.

Multi-intervalles – groupe de plus d'un canal à 64 kbit/s fournissant 8 kHz et l'intégrité de séquence d'intervalle de temps, généralement utilisés ensemble au sein d'un accès d'utilisateur RNIS au débit primaire (ISDN-PRA) afin de fournir un service de débit supérieur.

Canal de communication physique (Physical C-channel, Physical Communication Channel) – intervalle de temps de 64 kbit/s sur une interface V5.2 qui a été alloué pour porter des canaux C logiques. Un canal C physique ne peut pas être utilisé pour porter des canaux de supports.

Liaison primaire – liaison à 2048 kbit/s (E1) dans une interface V5.2 multi liaisons dont le canal C physique porte dans l'intervalle de temps 16 un chemin C pour le protocole de protection et, à l'initialisation de V5.2, aussi le chemin C pour le protocole de contrôle, le protocole de contrôle de liaison, et le protocole BCC. D'autres chemins C peuvent aussi être portés dans l'intervalle de temps 16.

Liaison secondaire – liaison à 2048 kbit/s (E1) dans une interface multi liaison V5.2 dont l'intervalle de temps 16 porte un chemin C pour le protocole de protection, et, à l'initialisation V5.2, agit comme canal C de remplacement pour le protocole de contrôle, le protocole de contrôle de liaison, et le protocole BCC et tout autre chemin C initialement porté dans l'intervalle de temps 16 de la liaison primaire.

Liaison V5 – liaison à 2048 kbit/s E1 (PCM30) utilisée sur une interface V5. Une interface V5 peut utiliser jusqu'à 16 liaisons V5.

V5.2 est une interface ETSI de norme industrielle (référence ETS 300 347-1 [300347-1]) définie entre un commutateur local (LE, Local Exchange) et un réseau d'accès (AN, Access Network) qui fournit l'accès aux types suivants :- accès de téléphone analogique

- autres accès analogiques ou numériques pour des connexions semi permanentes sans informations de signalisation hors bande associées

La spécification V5 d'origine (V5.1 [300324-1]) utilise des liaisons à 2048 kbit/s de façon non concentratrice. À l'opposé, V5.2 peut utiliser jusqu'à 16 de ces liaisons d'interface et prend en charge la concentration.

Le LE et l'AN sont connectés avec jusqu'à 16 liaisons E1 (MIC30). Les canaux 16, 15 et 31 sur toute liaison E1 peuvent être réservés pour les communications de données entre LE et AN. Les canaux réservés pour les données sont appelés "canaux de communication" ou "canaux C".

Les canaux C sont le support physique des échanges de données entre les entités homologues du protocole V5.2, ainsi que du transfert des messages BRI de canal D RNIS entre les terminaux et le LE. Un chemin de communication logique entre deux entités homologues pour un protocole est appelé un "chemin C".

- messages de protocole RNIS transposés en trames LAPD, qui sont portées au moyen de la sous couche LAPV5-EF (L2)

- messages de protocole V5 transposés en trames LAPV5-DL, qui sont portées au moyen de la sous couche LAPV5-EF (L2)

Afin de prendre en charge plus de trafic et d'allocations dynamiques de canaux support, le protocole V5.2 a plusieurs ajouts :

- un protocole de connexion de canal support installe et désinstalle les connexions support à la demande, comme déterminé par les informations de signalisation, sous le contrôle du commutateur local.

- un protocole de contrôle de liaison est défini pour la gestion multi liaison pour contrôler l'identification de liaison, le blocage de liaison et les conditions d'échec de liaison.

- un protocole de protection, qui fonctionne sur deux liaisons de données V5 séparées est défini pour gérer la commutation de protection des canaux de communication en cas de défaillance d'une liaison.

Dans l'architecture de transport V5UA, les entités de protocole V5 DEVRONT être distribuées sur la SG et le MGC comme montré ci-dessous .

La gestion de système V5 DEVRA être située sur le MGC. L'automate à états fonctionnels (FSM, Functional State Machine) V5 L1 DEVRA être situé sur la SG.

La gestion dynamique de TEI pour le BRI V5 sur V5UA DEVRA être situé sur le MGC.

Le numéro d'accès d'utilisateur alloué pour SCTP [RFC2960] (et UDP/TCP) pour V5UA est enregistré comme 5675.

L'extension de IUAP à V5UA pour prendre en charge le transport V5.2 exige l'introduction de nouvelles primitives frontières pour la frontière Q.921/Q.931, conformément aux définitions des normes V5.

V5UA réutilise certaines primitives IUA provenant de la frontière Q.921/Q.931 : la primitive DL-DATA et la primitive DL-UNIT DATA. La primitive DL-DATA est utilisée pour le transport des messages V5 de couche 3 et pour les messages V5 RNIS de couche 3. La primitive DL-UNIT DATA est seulement utilisée pour les messages V5 RNIS et elle est utilisée et définie comme décrit pour IUAP.

Dans les normes V5, la gestion de système V5 est chargée de l'établissement et de la libération des liaisons de données. Donc, pour V5UA les primitives DL-Establish et DL-Release définies dans IUAP sont remplacées par de nouvelles primitives entre la gestion de système et la couche de liaison des données conformément aux définitions de [300324-1] :

Les primitives MDL-Establish sont utilisées pour demander, indiquer et confirmer le résultat des procédures d'établissement du fonctionnement en trames multiples.

La primitive MDL-Release est utilisée pour indiquer le résultat des procédures pour terminer le fonctionnement en trames multiples.

À la différence du RNIS les normes V5 demandent que la gestion de système V5.2 interagisse directement avec la couche 1 de V5.2. Comme la couche 1 de V5.2 (y compris la FSM L1) et les parties de la gestion de système V5 sont physiquement séparés dans un scénario de transport V5, V5UA doit prendre en charge certains services pour la communication entre ces deux entités. Précisément, ces services incluent une indication de l'état d'une liaison spécifique, et des messages pour prendre en charge la procédure d'identification de liaison définie par les normes V5.

La primitive MPH-LINK STATUS START REPORTING est utilisée par la gestion de système V5 pour demander qu'une liaison soit mise en service pour être utilisée dans une interface V5. À réception de ce message, le FSM L1 sur la SG DEVRA commencer à faire rapport de l'état de la liaison V5 au MGC. Cette primitive est utilisée de façon similaire à la primitive MPH-proceed définie par V5.2, mais elle a une signification plus étendue que MPH-proceed.

La primitive MPH-LINK STATUS STOP REPORTING est utilisée par la gestion de système V5 pour demander qu'une liaison soit mise hors service sur une interface V5. À réception de ce message, le FSM L1 sur la SG DEVRA arrêter de faire rapport de l'état de la liaison V5 au GWC. Cette primitive est utilisée de façon similaire à la primitive MPH-stop définie par V5.2, mais elle a une signification plus étendue que MPH-stop.

La primitive MPH-LINK STATUS INDICATION est utilisée par le FSM L1 sur la passerelle de signalisation pour faire rapport à la gestion de système V5 de l'état (fonctionnement/non fonctionnement) d'une liaison V5. Cette primitive est équivalente aux primitives MPH-AI et MPH-DI dans V5.2.

La primitive MPH-SA-BIT SET est utilisée par la gestion de système pour demander que le FSM L1 dans la SG établisse ou rétablisse la valeur d'un bit Sa spécifié sur la liaison demandée. La SG l'utilise pour faire rapport à la gestion de système de la réussite de l'établissement ou rétablissement de ce bit. Pour V5, ce message est utilisé pour la procédure d'identification de liaison spécifique de V5 pour établir/rétablir la valeur du bit Sa7, ou pour confirmer la réussite de l'établissement du bit Sa. La demande MPH-SA BIT SET REQUEST est équivalente aux primitives MPH-ID et MPH-NOR dans V5.2.

La primitive MPH-SA-BIT STATUS est utilisée par la gestion de système au MGC pour demander que le FSM L1 à la SG fasse rapport de l'état d'un bit Sa spécifié sur la liaison demandée. La SG l'utilise pour faire rapport (indiquer) l'état de ce bit à la gestion de système. Pour V5, ces messages sont utilisés pour la procédure d'identification de liaison spécifique de V5 pour demander ou faire rapport de l'état du bit Sa7. Ceci est équivalent aux primitives MPH-IDR, MPH-IDI ou MPH-Elg dans V5.2.

Du fait de la séparation de la gestion de système V5 et de V5 couche1/couche2 dans l'architecture de transport V5UA, il peut être nécessaire de faire rapport des conditions d'erreur de la pile V5 de la SG à la gestion de système V5. À cette fin, une nouvelle primitive est définie :

La primitive MDL-ERROR INDICATION est utilisée pour indiquer une condition d'erreur à la gestion de système V5. La seule raison valide de cette primitive est "Overload", qui indique une condition de surcharge du canal C sur la SG. Cette raison n'est pas définie dans les normes V5/Q.921.

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

Un seul flux SCTP DEVRAIT être utilisé pour grouper ensemble tous les protocoles suivants : BCC, contrôle d'accès, protocole de contrôle et protocole RTPC sur un canal C spécifique. Un flux SCTP séparé DEVRAIT être utilisé pour le protocole de protection sur un canal C spécifique. Un flux SCTP DEVRAIT être utilisé pour tous les accès d'utilisateur RNIS sur un canal C spécifique. Un seul flux NE DEVRAIT PAS être utilisé pour porter les données de plus d'un canal C.

De plus, un flux SCTP séparé DEVRAIT être utilisé pour tous les messages MPH (en rapport avec la liaison).

SCTP (Stream Control Transmission Protocol) : protocole de transmission de commande de flux

L'en-tête original de message IUA doit être modifié pour V5UA. L'en-tête original pour l'identifiant d'interface formaté en entier est montré ci-dessous :

V5UA étend l'en-tête de message IUA en incluant l'adresse de fonction d'enveloppe (EFA, Envelope Function Address) dans le champ Réservé. Le format V5UA pour l'identifiant d'interface formaté en entier est montré ci-dessous :

Figure 3 : En-tête de message V5UA (Identifiant d'interface fondé sur un entier)

La EFA est définie par la norme V5. Elle identifie un chemin C, qui est un nombre de 13 bits, allant de 0 à 8191 (décimal). Une EFA identifie de façon univoque un des cinq protocoles V5.2, ou un agent RNIS rattaché à un AN. La liste suivante contient les valeurs possibles pour l'EFA comme définies par V5 :

Pour les messages MPH qui n'utilisent pas DLCI et EFA, SAPI, TEI et EFA DEVRONT être réglés à zéro et DEVRONT être ignorés par le receveur. Pour tout autre message, le DLCI DEVRA être réglé comme défini dans la norme V5.2 [300324-1].

L'identifiant d'interface DEVRA suivre les conventions de désignation d'interface d'identifiant définies ci-dessous.

La norme V5 exige que la gestion de système V5 garde trace des états de toutes les liaisons sur une interface V5. Pour effectuer des tâches comme la commutation de protection et l'allocation de canal support sur les liaisons V5, il est nécessaire que la gestion de système ait un tableau complet de la signalisation et des canaux supports situés sur chaque liaison.

Le protocole IUA identifie les canaux C par points d'extrémité sans association définie avec une liaison spécifique. Comme il n'existe pas de convention de dénomination, il n'est pas garanti qu'un canal C soit réellement situé sur la liaison que laquelle il prétend être. De plus, la norme V5 exige que le MGC reçoive des rapports sur l'état de toutes les liaisons, et il définit la procédure d'identification de liaison pour assurer qu'AN et LE font référence à la même liaison lorsque ils s'adressent à une liaison avec un message de protocole de contrôle de liaison.

Il irait à l'encontre du concept de V5.2 qu'il n'y ait pas de claire association entre liaison E1 et canal. Pour résoudre ce problème, une convention de dénomination DOIT être utilisée pour V5UA.

Le format de l'identifiant d'interface en format d'entier est montré ci-dessous :

Identifiant de liaison – Identifiant d'une liaison E1 sur la SG (27 bits). DOIT être unique sur la SG. Cet identifiant de liaison DOIT correspondre à l'identifiant de liaison utilisé dans les messages de gestion de liaison définis plus loin.

ID canal, identifiant de canal (5 bits). Il est égal au numéro d'intervalle de temps (time slot) de l'intervalle de temps adressé. Les valeurs possibles sont 15, 16 et 31 qui représentent les intervalles de temps possibles pour les canaux C sur une interface V5. Pour les messages de gestion de liaison, l'identifiant de canal DOIT être réglé à 0. Toutes les autres valeurs sont réservées pour une utilisation future.

Si il est utilisé, l'identifiant d'interface formaté en texte DEVRA être codé en représentation hexadécimale de l'identifiant d'interface formaté en entier, écrit sous forme d'une chaîne de longueur variable.

Certaines primitives pour les frontières d'interface V5 sont similaires aux messages de primitives de frontière Q.921/Q.931 définis dans IUA, mais elles doivent être traitées d'une façon différente. Donc il est nécessaire de distinguer ces deux types de message au moyen du paramètre Classe de message.

Pour toutes les primitives de frontière d'interface V5, une nouvelle classe de message est introduite :

14 : message de transport de primitive de frontière V5 (V5PTM, V5 Boundary Primitives Transport Message)

Les autres classes de message valides pour V5UA, qui sont aussi utilisées par IUA, sont :

Les messages de primitive de frontière Q.921/Q.931 réutilisés par V5.2 comme messages V5PTM sont :

Tous ces messages sont définis de façon similaire à celle des messages QPTM. En plus, de nouveaux messages de primitive de frontière sont définis :

4.4 Messages d'état de liaison (Début de rapport, Fin de rapport, Indication)

Les messages d'état de liaison sont utilisés entre la gestion de système V5 sur le MGC et le FSM L1 sur la SG pour retracer l'état d'une liaison E1 particulière. Ceci est exigé que la liaison E1 porte ou non des canaux C.

Tous les messages d'état de liaison contiennent l'en-tête de message V5UA. La portion Identifiant de liaison de l'identifiant d'interface identifie la liaison physique sur la SG à laquelle s'adresse le message. Pour tous les messages d'état de liaison, l'identifiant de canal DEVRA être réglé à '0' et DEVRA être ignoré par le receveur.

La valeur d'entier utilisée pour l'identifiant de liaison n'a de signification que locale, et est coordonné entre la SG et le MGC. Elle DOIT être unique pour chaque liaison V5 sur la SG.

Comme défini par les normes V5, la gestion de système V5 doit connaître l'état des liaisons sur toutes les interfaces V5 actives. message de début de rapport d'état de liaison est utilisé par la gestion de système V5 sur le MGC pour demander que le FSM L1 sur la SG commence à faire rapport de l'état d'une certaine liaison.

À l'activation d'interface, la gestion de système V5 DEVRA envoyer ce message pour toutes les liaisons sur l'interface. La SG DEVRA répondre immédiatement à cette demande par un message Indication d'état de liaison, et elle DEVRA ensuite envoyer un message Indication d'état de liaison sur tout changement ultérieur de l'état de la liaison. Comme la SG n'a pas d'autre moyen de déterminer si une liaison est sur une interface active ou non, ce message DEVRA toujours être envoyé au démarrage d'une interface.

Si le FSM L1 dans la SG reçoit un message Début de rapport d'état de liaison pour une liaison qui est déjà active (l'état de la liaison est rapporté à la gestion de système) la SG DEVRA immédiatement faire rapport de l'état réel de cette liaison en envoyant un message Indication d'état de liaison. La SG DEVRA alors procéder au rapport automatique d'état de liaison comme décrit ci-dessus.

Pour arrêter ces rapports d'état d'une liaison, par exemple, à la désactivation de l'interface, la gestion de système envoie un message Fin de rapport d'état de liaison au FSM L1. La SG va ensuite arrêter immédiatement de faire rapport de l'état de cette liaison et va supposer que la liaison est hors service. Elle NE DOIT répondre d'aucune façon à ce message.

Comme il n'y a pas d'autre moyen pour que la SG sache qu'une interface a été désactivée, ce message DEVRA être envoyé lors de la désactivation de l'interface pour toutes les liaisons sur l'interface. À réception de ce message, la SG DEVRA mettre la couche 2 en sommeil sur cette liaison.

Si le FSM L1 à la SG reçoit un message Fin de rapport d'état de liaison pour une liaison qui n'est pas active (l'état de la liaison n'est pas rapporté à la gestion de système) la SG DEVRA ignorer le message.

Les messages Début/Fin de rapport d'état de liaison contiennent l'en-tête commun de message suivi par l'en-tête de message V5UA. Ils ne contiennent aucun paramètre supplémentaire.

Le message Indication d'état de liaison est utilisé par le FSM L1 dans la SG en réponse à un message Début de rapport d'état de liaison pour indiquer l'état de cette liaison. Après la réception d'un message Indication d'état de liaison par le FSM L1, celui-ci DEVRA automatiquement envoyer un message Indication d'état de liaison chaque fois que l'état de cette liaison change. Il NE DEVRA PAS arrêter ces rapports jusqu'à ce qu'il reçoive un message Fin de rapport d'état de liaison de la gestion de système.

Le message Indication d'état de liaison contient l'en-tête commun de message suivi par l'en-tête de message V5UA. De plus, il contient le paramètre d'état de liaison suivant :

Les valeurs valides pour l'état de liaison sont montrées dans le tableau suivant :

4.5 Messages de bit Sa (Demande d'établissement, Confirmation d'établissement, Demande/Indication d'état)

Les messages de bit Sa sont utilisés entre la gestion de système V5 dans le MGC et le FSM L1 dans la SG pour établir et lire l'état des bits Sa sur les liaisons E1. Pour V5, il est seulement exigé pour établir et lire l'état du bit Sa7 qui est utilisé pour la procédure d'identification de liaison comme décrit dans les normes V5 [300347-1].

Tous les messages de bit Sa DEVRONT contenir l'en-tête de message V5UA. La portion Identifiant de liaison de l'identifiant d'interface identifie la liaison physique sur la SG à laquelle s'adresse le message. Pour tous les messages d'état de liaison, l'identifiant de canal DEVRA être réglé à '0' et DEVRA être ignoré par le receveur.

L'identifiant de liaison DOIT être le même que celui utilisé dans l'identifiant d'interface pour identifier sur quelle liaison est situé un canal C.

Le message Demande d'établissement du bit Sa est utilisé pour régler la valeur du bit Sa spécifié sur la liaison définie. La valeur du bit Sa7 en fonctionnement normal est UN. Pour la procédure d'identification de liaison, il est réglé à ZÉRO.

Le message Demande d'établissement du bit Sa pour le bit Sa7 avec la valeur de bit ZÉRO correspond à la primitive MPH-ID définie pour V5. Le message Demande d'établissement du bit Sa pour le bit Sa7 avec la valeur de bit UN correspond à la primitive MPH-NOR définie pour V5.

La SG DOIT répondre au message Demande d'établissement du bit Sa par un message Confirmation d'établissement du bit Sa lorsque l'établissement du bit est achevé. Ce message ne correspond pas à une primitive définie de V5

Le message Demande d'état du bit Sa est utilisé par la gestion de système pour demander au FSM L1 l'état du bit Sa spécifié sur la liaison définie. Le message Demande d'état du bit Sa pour le bit Sa7 correspond à la primitive MPH-IDR définie par V5.

Le FSM L1 répond au message Demande d'état du bit Sa par un message Indication d'état du bit SA dans lequel le réglage actuel du bit sera rapporté. Le message Indication d'état du bit SA pou le bit Sa7 avec la valeur de bit de ZÉRO correspond à la primitive MPH-IDI définie dans V5. Le message Indication d'état du bit SA pour le bit Sa7 avec la valeur de bit de UN correspond à la primitive MPH-Elg définie dans V5.

Les valeurs valides pour la valeur du bit sont montrées dans le tableau suivant :

Il n'y a pas d'autre valeur valide pour V5UA. Toutes les autres valeurs sont réservées pour une utilisation future.

Pour les messages Demande d'état du bit Sa et Confirmation d'établissement, la valeur du bit DEVRA être réglée à '0' par l'envoyeur et DEVRA être ignorée par le receveur.

Le message Indication d'erreur est utilisé entre la pile V5 sur la SG et la gestion de système V5 dans le MGC pour indiquer une condition d'erreur à la SG. La seule raison valide du message Indication d'erreur est la surcharge. La SG DEVRAIT produire une telle indication d'erreur avec la cause Surcharge pour un canal C si elle n'est pas capable de traiter tous les messages de couche 3 sur ce canal C en temps utile (condition de surcharge du canal C).

L'identifiant d'interface indique le canal C affecté. SAPI, TEI et EFA DEVRONT être réglés à '0' et DEVRONT être ignorés par le receveur.

Il n'y a pas d'autre valeur valide pour V5UA. Toutes les autres valeurs sont réservées pour une utilisation future.

La façon normale de traiter une défaillance V5 couche 1 est décrite dans les normes V5 [300324-1], [300347-1] comme suit :

- Le FSM L1 détecte la défaillance V5 couche 1. Il en fait rapport à la gestion de système V5 en envoyant une primitive MPH-DI pour la liaison affectée.

- La gestion de système V5 notifie la couche 2 V5 de la panne de la couche 1 V5 en envoyant une primitive MPH-Layer_1 d'indication de défaillance.

Comme les couches 1/2 V5 et la gestion de système V5 ne sont plus colocalisées dans l'architecture de transport, il n'y a pas de sens à notifier à la couche 2 V5 une défaillance de couche 1 V5 via la gestion de système V5. À la place, la couche 2 V5 DEVRA être notifiée directement par la couche 1 V5 sur la SG. La couche 1 V5 DEVRA faire rapport de la panne à la gestion de système V5 en envoyant un message Indication d'état de liaison avec l'état NON OPÉRATIONNEL, correspondant à une primitive MPH-DI comme défini par la norme V5.2. La gestion de système V5 NE DEVRA PAS envoyer la primitive MPH-Layer_1 d'indication de défaillance à la couche 2 V5 en réponse à ce message.

Si une défaillance SCTP est détectée ou si le rythme est perdu, la procédure suivante DEVRA être suivie :

Lorsque la perte de l'homologue V5UA est rapportée à la couche V5UA, l'ASP DEVRA se comporter comme si il avait reçu une Indication d'état de liaison (non opérationnelle) pour toutes les liaisons sur cette SG.

L'ASP DEVRA tenter de rétablir la connexion de façon continuelle. Lorsque la connexion sera rétablie, l'ASP DEVRA envoyer un message Début de rapport d'état de liaison à la SG pour toutes les liaisons sur les interfaces V5 actives sur la SG.

Un exemple du flux de messages pour le rétablissement de la connexion est montré ci-dessous pour une liaison active sur la SG:

Si l'association peut être rétablie avant que la couche V5UA soit notifiée, la communication DEVRA se poursuivre normalement et aucune autre action NE DEVRA être effectuée à l'ASP.

Si la SG détecte une condition de surcharge sur un canal C, elle DEVRAIT l'indiquer en envoyant un message Indication d'erreur, avec la cause Surcharge au MGC. Le MGC DEVRAIT alors effectuer les actions appropriées pour supprimer cette condition de surcharge.

La SG DEVRA renvoyer le message Indication d'erreur avec la cause Surcharge tant que la condition persiste. Un intervalle de 120 secondes entre les envois de ce message est RECOMMANDÉ.

Les procédures d'identification de liaison elles-mêmes sont décrites dans la norme V5.2 [300347-1].

Un exemple de flux de messages pour une procédure d'identification de liaison initiée par le commutateur local sur V5UA est présentée ci-dessous. Une association active entre ASP et SG est établie avant les flux de messages suivants, et l'interface V5 est déjà en service:

L'exemple suivant montre aussi une procédure d'identification de liaison, mais cette fois elle est initiée par l'AN. Là encore, l'association ASP et l'interface V sont déjà en service:

Les considérations sur la sécurité discutées pour le document "Considérations sur la sécurité des protocoles SIGTRAN" [RFC3788] s'appliquent au présent document.

L'IANA a alloué une valeur de V5UA pour l'identifiant de protocole de charge utile dans le tronçon DATA SCTP. L'identifiant de protocole de charge utile SCTP suivant est enregistré :

La valeur d'identifiant de charge utile SCTP "6" DEVRAIT être incluse dans chaque tronçon DATA SCTP pour indiquer que le SCTP porte le protocole V5UA. La valeur "0" (non spécifié) est aussi permise mais toutes les autres valeurs NE DOIVENT PAS être utilisées. 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 DATA.

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

Les auteurs tiennent à remercier Fahir Ergincan, Milos Pujic, Graeme Currie, Berthold Jaekle, Ken Morneault et Lyndon Ong de leurs précieux commentaires et suggestions.

[300324-1] ETSI EN 300 324-1 (1999), "V interfaces at the digital Local Exchange (LE); V5.1 interface for the support of Access Network (AN); Part 1: V5.1 interface specification".

[300347-1] ETSI EN 300 347-1 (1999), "V interfaces at the digital Local Exchange (LE); V5.2 interface for the support of Access Network (AN); Part 1: V5.2 interface specification".

[300125] ETSI ETS 300 125 (1991), "DSS1 protocol; User-Network interface data link layer specification". (La norme se fonde sur les Recommandations UIT-T Q.920, Q.921).

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

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

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

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

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

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

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

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

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

Groupe de travail Réseau	E. Weilandt, Nortel Networks
Request for Comments : 3807	N. Khanchandani, Nortel Networks
RFC mise à jour : 3057	S. Rao, Nortel Networks
Catégorie : En cours de normalisation	juin 2004
Traduction Claude Brière de L'Isle

Définition	Valeur
Protocole RNIS	0 - 8175
Protocole RTPC	8176
Protocole de contrôle	8177
Protocole BCC	8178
Protocole PROTECTION	8179
Protocole de commande de liaison	8180
Réservé	8181 - 8191

Définition	Valeur
PROTOCOLE RNIS	0 - 8175
PROTOCOLE RTPC	8176
PROTOCOLE DE CONTROLE	8177
PROTOCOLE BCC	8178
PROTOCOLE DE PROTECTION	8179
PROTOCOLE DE CONTRÔLE DE LIAISON	8180
RÉSERVÉ	8181 - 8191

Intitulé	Valeur	Description
OPERATIONNEL	0x0	Liaison opérationnelle
NON OPERATIONNEL	0x1	Liaison non opérationnelle

Intitulé	Valeur	Description
ZÉRO	0x0	Valeur de bit de zéro
UN	0x1	Valeur de bit de un

Dr. Eva Weilandt	Sanjay Rao	Neeraj Khanchandani
Conti Temic microelectronic GmbH	Nortel Networks	Nortel Networks
An der B31	35 Davis Drive	35 Davis Drive
88090 Immenstaad	Research Triangle Park, NC 27709	Research Triangle Park, NC 27709
Germany	USA	USA
téléphone : +49 7545 8-2917	téléphone : +1-919-991-2251	téléphone : +1-919-991-2274
mél : eva.weilandt@temic.com	mél : rsanjay@nortelnetworks.com	mél : neerajk@nortelnetworks.com