Groupe de travail Réseau	L. Berger, Movaz Networks	
Request for Comments : 4003	février 2005	
RFC mise à jour : 3473		
Catégorie : En cours de normalisation	Traduction Claude Brière de L'Isle	

Procédure GMPLS de signalisation pour le contrôle de sortie

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

Notice de copyright
Copyright (C) The Internet Society (2005). Tous droits réservés

Résumé
Le présent document précise les procédures pour le contrôle de l'étiquette utilisée sur une interface de sortie/vers l'aval du nœud de sortie d'un chemin de commutation d'étiquette (LSP, Label Switched Path). Ce contrôle est aussi appelé "Contrôle de sortie". La prise en charge du contrôle de sortie est implicite dans la signalisation de commutation d'étiquettes multi protocoles généralisée (GMPLS, Generalized Multi-Protocol Label Switching). Le présent document précise la spécification de la signalisation GMPLS et ne modifie pas les mécanismes et procédures de signalisation GMPLS.

1.	Fondements

La capacité de contrôler l'étiquette utilisée sur l'interface de sortie/vers l'aval d'un nœud de sortie était une des premières exigences de GMPLS. Dans les documents initiaux de GMPLS, c'était appelé "Contrôle de sortie". Avec la progression des documents GMPLS, la capacité de contrôler une étiquette sur une interface de sortie a été généralisée pour prendre en charge le contrôle d'une étiquette sur toute interface. Cette généralisation est vue à la Section 6 de la [RFC3471] et au paragraphe 5.1 de la [RFC3473]. Quand cette fonctionnalité a été généralisée, les procédures de prise en charge du contrôle d'une étiquette à la sortie ont été aussi généralisées. Bien que le résultat ait été destiné à couvrir le contrôle de sortie, cette intention n'est pas claire du tout. La présente note réitère les procédures pour couvrir le contrôle d'une étiquette utilisée sur une interface de sortie en sortie/vers l'aval.

Pour le contexte, le texte qui suit est tiré du document de signalisation GMPLS daté de juin 2000 sur la façon dont un objet de chemin explicite (ERO, Explicit Route Object) se comporte pour le contrôle de sortie :

"6.	Contrôle de sortie

Le LSR à l'extrémité de tête d'un LSP peut contrôler la terminaison du LSP en utilisant l'ERO. Pour terminer un LSP sur une interface sortante particulière du LSR de sortie, l'extrémité de tête peut spécifier l'adresse IP de cette interface comme dernier élément de l'ERO, pourvu que cette interface ait une adresse IP associée.

Il y a des cas où l'utilisation d'adresse IP ne fournit pas assez d'informations pour identifier de façon univoque la terminaison de sortie. Un cas est celui où l'interface de sortie sur le LSR de sortie est une liaison composante d'un faisceau de liaisons. Un autre cas est quand il est souhaitable "d'épissurer" deux LSP, c'est-à-dire que la queue du premier LSP sera "collée" à la tête du second LSP. Ce dernier cas sera plus vraisemblablement utilisé dans les classes non PSC de liaisons.

6.2	Procédures
Le sous objet Étiquette de sortie ne peut apparaître que comme dernier sous objet dans le ERO/ER. L'apparition de ce sous objet n'importe où ailleurs dans le ERO/ER est traitée comme une erreur "Mauvais nœud strict".

Durant un établissement de LSP, lorsque un nœud traitant le ERO/RR effectue le choix de prochain bond et trouve que le second sous objet est un sous objet Étiquette de sortie, le nœud utilise les informations portées dans ce sous objet pour déterminer le traitement des données reçues sur ce LSP. Précisément, si le champ Identifiant de liaison du sous objet n'est pas zéro, ce champ identifie alors une liaison (sortante) spécifique du nœud qui devrait être utilisée pour envoyer toutes les données reçues sur le LSP. Si le champ Étiquette du sous objet n'est pas l'étiquette NUL implicite, ce champ spécifie l'étiquette qui devrait être utilisée comme étiquette sortante sur les données reçues sur le LSP.

Les procédures par lesquelles un LSR à l'extrémité de tête d'un LSP obtient les informations nécessaires pour construire le sous objet Étiquette de sortie sortent du domaine d'application du présent document."

2.	Procédures de contrôle de sortie

Cette section est destinée à compléter les paragraphes 5.1.1 et 5.2.1 de la [RFC3473]. Les procédures décrites dans ces paragraphes ne sont pas modifiées. Cette section précise les procédures relatives à l'étiquette utilisée sur une interface de sortie en sortie/vers l'aval.

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

2.1	Procédures ERO
Le contrôle de sortie survient lorsque le nœud qui traite un ERO est celui de sortie et que l'ERO contient un ou plusieurs sous objets relatifs à l'interface de sortie/vers l'aval. Dans ce cas, l'interface de sortie/vers l'aval est indiquée dans l'ERO comme la dernière interface locale mentionnée. Noter qu'une interface peut être numérotée ou non numérotée.

Pour prendre en charge le contrôle de sortie, une sortie vérifie si l'ERO reçu contient une interface de sortie/vers l'aval. Si oui, le type du ou des sous objets qui suivent l'interface est examiné. Si le LSP associé est unidirectionnel, un sous objet est examiné. Deux sous objets sont examinés pour les LSP bidirectionnels. Si le bit U du sous objet examiné est à zéro (0), la valeur de l'étiquette DOIT être utilisée pour transmettre le trafic associé au LSP sur l'interface de sortie/vers l'aval indiquée.

Si le bit U du sous objet examiné est établi (à 1) la valeur de l'étiquette est alors utilisée pour le trafic vers l'amont associé au LSP bidirectionnel. Précisément, la valeur de l'étiquette sera utilisée pour le trafic associé au LSP qui sera reçu sur l'interface de sortie/vers l'aval indiquée.

Selon la [RFC3473], toutes les erreurs rencontrées lors du traitement de l'ERO, incluant si la ou les étiquettes mentionnées ne sont pas acceptables ou ne peuvent pas être prises en charge dans la transmission, DEVRAIENT résulter en la génération d'un message PathErr (erreur de chemin) avec le code d'erreur "Erreur d'acheminement" et une valeur d'erreur de "Mauvais objet de chemin explicite".

2.2	Procédures RRO
Si un ERO est utilisé pour spécifier des informations d'interface sortante à la sortie et si l'enregistrement d'étiquette est indiqué pour le LSP, la sortie devrait inclure les informations d'interface spécifiées et la ou les étiquettes spécifiées dans l'objet d'enregistrement de chemin (RRO, Route Record Object) correspondant.

3.	Considérations sur la sécurité

Le présent document précise les procédures définies dans la [RFC3473] mais ne définit aucune nouvelle procédure. À ce titre, aucune nouvelle considération sur la sécurité n'est introduite.

4.	Remerciements

Des commentaires et apports précieux ont été reçus de Adrian Farrel, Alan Kullberg, et Dimitri Papadimitriou.

5.	Références normatives

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

[RFC3471]	L. Berger, éd., "Commutation d'étiquettes multi-protocoles généralisée (GMPLS) : description fonctionnelle de la signalisation", janvier 2003. (MàJ par RFC4201, RFC4328, RFC4872) (P.S.)

[RFC3473]	L. Berger, "Extensions d'ingénierie de protocole - trafic de signalisation de réservation de ressource (RSVP-TE) de commutation d'étiquettes multi-protocoles généralisée (GMPLS)", janvier 2003. (P.S., MàJ par les RFC 4003, 4201, 4420, 4783, 4784, 4873, 4974, 5063, 5151, et 6780))

Adresse de l'auteur

Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
USA
téléphone :  +1 703 847-1801
mél :  lberger@movaz.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 fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci-encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

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

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

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

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