Groupe de travail Réseau

B. Foster

Request for Comments : 3992

F. Andreasen

Catégorie : Informationnel

Cisco Systems

Février 2005

 

 

Protocole de commande de passerelle de support (MGCP) – Mécanisme de rapport de l’état Lockstep (indéfini)

 

Statut du présent mémo

Le présent mémo fournit des informations destinées à la communauté Internet. Il ne spécifie aucune sorte de norme Internet. La distribution du présent mémo n’est soumise à aucune restriction.

 

Déclaration de copyright

Copyright (C) The Internet Society (2005).

Note de l’IESG

Le présent document est publié pour l’information de la communauté Internet. Il décrit un protocole non-IETF qui est en cours de développement dans un certain nombre de produits. Les développeurs doivent avoir connaissance de la RFC 3015, qui a été développée par le Groupe de travail Megaco de l’IETF et la Commission 16 de l’UIT-T, et qui est considéré par l’IETF et l’UIT-T comme la façon normalisée (y compris les considérations révisées sur la sécurité) de satisfaire les besoins que MGCP était destiné à prendre en compte.

Résumé

Un point d’extrémité du protocole de commande de passerelle de support (MGCP, Media Gateway Control Protocol) qui se trouve confronté à une situation de défaillance (comme de se trouver engagé dans un appel en transit lorsque survient une défaillance de l’Agent d’appel) pourrait être laissé dans un état indéfini dans lequel les événements sont mis de côté sans être notifiés. Le paquetage MGCP décrit dans le présent document fournit un mécanisme pour faire rapport de ces situations de sorte que le nouvel Agent d’appel puisse suivre les procédures de récupération de faute nécessaires.

1 Introduction

Dans le protocole de commande de passerelle de support (MGCP) [2], lorsqu’un point d’extrémité fonctionnant en mode "step" génère une commande Notify, il va entrer dans l’état notification, où il attend une réponse à Notify. De plus, le point d’extrémité doit attendre une nouvelle NotificationRequest avant qu’il ne puisse se remettre à traiter les événements. Tant que le point d’extrémité attend cette NotificationRequest, nous disons qu’il est dans cet état indéfini (lockstep).

Un point d’extrémité qui est dans l’état indéfini ne peut effectuer aucun traitement d’événement et donc ne peut pas non plus générer un nouveau Notify. Les points d’extrémité ne devraient être dans l’état indéfini que pour un très court instant. Cependant, dans des conditions difficiles, un point d’extrémité pourrait finir dans l’état indéfini sans que l’Agent d’appel s’en rende compte. Cela pourrait avoir de très graves conséquences sur la fourniture du service.

Le paquetage Lockstep défini dans le présent document définit des extensions aux commandes EndpointConfiguration et RestartInProgress qui permettent à un Agent d’appel de demander à un point d’extrémité de lui communiquer qu’il se trouve dans l’état indéfini depuis un temps spécifié.

1.1. Conventions utilisées dans le présent document

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" doivent être interprétés comme décrit par la [RFC2119].

2. Paquetage Lockstep

Nom du paquetage : LCK

Version : 0

Description du paquetage : L’objet du paquetage est la fourniture d’un mécanisme de rapport d’une condition dans laquelle un point d’extrémité a été en "état indéfini" pendant une durée déterminée spécifiée.

Ce paquetage présente deux aspects :

* La capacité pour un Agent d’appel de demander aux points d’extrémité de faire rapport lorsqu’ils se trouvent dans l’état indéfini pendant une durée spécifiée. Ceci est fait par la commande EndpointConfiguration, comme décrit au paragraphe 2.1.

* Le mécanisme de rapport lui-même qui est fait par une nouvelle RestartMethod "lockstep" pour la commande RSIP comme décrit au paragraphe 2.2.

2.1. Demande de rapport de l’état Lockstep

Le nouveau paramètre de configuration de point d’extrémité "LCK/LST" est utilisé par l’Agent d’appel pour demander qu’il soit fait rapport de l’état "lockstep". Il utilise l’ABNF suivant :

"LCK/LST:" 0*WSP LSTIME

LSTIME = 1*(4CHIFFRES)

où LSTIME est exprimé en secondes, avec une valeur dans la gamme de 0 à 9999. Une valeur supérieure à 2*T-HIST (voir en [2]) est RECOMMANDÉE.

LSTIME est la quantité de temps pendant laquelle le point d’extrémité est dans l’état indéfini avant le rapport. Le temporisateur débute lorsque le point d’extrémité entre dans l’état indéfini et il est annulé si le point d’extrémité quitte l’état indéfini avant la fin de la temporisation. La valeur fournie reste en vigueur jusqu’à ce qu’elle soit explicitement changée (ou qu’un redémarrage survienne). Si le point d’extrémité est déjà dans l’état indéfini lorsqu’une valeur de temporisateur différente de zéro est fournie, le temporisateur lockstep débute simplement avec la valeur fournie, et tout temporisateur lockstep existant est annulé. La valeur zéro est utilisée pour fermer l’émission de rapport.

Ce paramètre peut être vérifié en utilisant la commande AuditEndpoint. La valeur retournée est la dernière valeur configurée, ou la valeur zéro lorsque aucune autre valeur n’a été configurée.

2.2. Methode de redémarrage de Lockstep

Une nouvelle méthode de redémarrage "lockstep" est définie dans le paquetage "LCK". Un RestartInProgress (RSIP, redémarrage en cours) sera envoyé avec cette RestartMethod si le point d’extrémité a été configuré avec une valeur différente de zéro pour LSTIME et si le temporisateur est arrivé à expiration. Noter qu’une fois que le temporisateur lockstep a été établi, il ne peut se dérouler qu’une seule fois par commande Notify ; cependant il est possible d’établir le temporisateur plus d’une fois tandis que le point d’extrémité est dans l’état indéfini (et donc de le réarmer pour ce Notify particulier). La syntaxe de la méthode de redémarrage est conforme à celle de [2] :

"RM" ":" 0*(WSP) "LCK/lockstep"

RestartDelay (voir en [2]) n’est pas utilisée avec la RestartMethod "lockstep". Aussi, la RestartMethod "lockstep" ne définit pas un état de service, et donc elle ne sera jamais retournée lors de la vérification de RestartMethod.

3. C onsidérations sur l’IANA

Le titre du paquetage MGCP "Lockstep" avec le nom "LCK" et le numéro de version zéro a été enregistré auprès de l’IANA comme indiqué dans l’Appendice C.1 de [2].

4. Considérations sur la sécurité

La section 5 de la spécification MGCPde base [2] discute des exigences de sécurité pour le protocole MGCP de base qui s’appliquent également au paquetage défini dans le présent document. L’utilisation d’un protocole de sécurité tel que IPsec (RFC 2401, RFC 2406) qui fournit des services d’authentification et d’intégrité message par message est nécessaire pour garantir que les demandes et les réponses sont obtenues auprès de sources authentifiées et que les messages n’ont pas été modifiés. Sans ces services, les passerelles et Agents d’appel sont désarmés face aux attaques.

5. Références normatives

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels" (Mots clé à utiliser dans les RFC pour indiquer les niveaux d’exigence), BCP 14, RFC 2119, March 1997.

[2] Andreasen, F. et B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0" (Protocole de commande de passerelle de support), RFC 3435, January 2003.

Adresse des auteurs

Flemming Andreasen

Bill Foster

Cisco Systems

Cisco Systems

499 Thornall Street, 8th Floor

 

Edison, NJ 08837

Phone: +1 250 758 9418

email : fandreas@cisco.com

email : bfoster@cisco.com

Déclaration de copyright

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 y contenues sont fournies sur une base "EN L’ÉTAT" et LE CONTRIBUTEUR, L’ORGANISATION QU’IL OU ELLE REPRÉSENTE OU QUI LE/LA FINANCE (S’IL EN EST), LA INTERNET SOCIETY ET LA INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTES GARANTIES, EXPRIMÉES OU IMPLICITES, Y COMPRIS MAIS NON LIMITÉES À TOUTE GARANTIE QUE L’UTILISATION DES INFORMATIONS CI-ENCLOSES NE VIOLENT AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D’APTITUDE À UN OBJET PARTICULIER.

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 pourrait ê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 Internet Society.