Groupe de travail Réseau	L. Martini, Cisco Systems, Inc.
Request for Comments : 4863	G. Swallow, Cisco Systems, Inc.
Catégorie : Sur la voie de la normalisation	mai 2007
Traduction Claude Brière de L'Isle

Type de pseudo filaire générique

Statut du présent 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 "Protocoles officiels de l’Internet" (STD 1) pour voir 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 IETF Trust (2007).

Résumé
La signalisation de pseudo filaire exige que le type de pseudo filaire soit identique dans les deux directions. Pour certaines applications, la configuration du type de pseudo filaire est accomplie très facilement en configurant cette information seulement à un point d'extrémité du pseudo filaire. Dans toute forme de signalisation fondée sur le protocole de distribution d’étiquettes (LDP, Label Distribution Protocol) chaque point d'extrémité de pseudo filaire doit initier la création d'un chemin commuté par étiquettes (LSP, Label Switched Path) unidirectionnel. Afin de permettre que l'initialisation de ces deux LSP reste indépendante, un moyen est nécessaire pour permettre au point d'extrémité de pseudo filaire (qui n'a pas de connaissance a priori du type de pseudo filaire) d'initier la création d'un LSP. Le présent document définit un type de pseudo filaire générique pour satisfaire ce besoin.
Table des matières
1. Introduction	1
1.1 Conventions et terminologie	2
2. Type de pseudo filaire générique	2
3. Procédures	2
3.1 Procédures à l'envoi de la classe d'équivalence de transmission (FEC) générique	2
3.2 Procédures à la réception de la FEC générique	2
4. Considérations sur la sécurité	3
5. Considérations relatives à l'IANA	3
6. Références	3
6.1 Références normatives	3
6.1 Références pour information	3
Adresse des auteurs	3
Déclaration complète de droits de reproduction	4
 	1.	Introduction

La signalisation de pseudo filaire exige que le type de pseudo filaire soit identique dans les deux directions. Pour certaines applications, la configuration du type de pseudo filaire est très facilement réalisée en configurant cette information à un seul des points d'extrémité du pseudo filaire. Dans toute forme de signalisation fondée sur LDP, chaque point d'extrémité de pseudo filaire doit initier la création d'un LSP unidirectionnel.

Par les procédures de la [RFC4447], les deux messages de transposition d'étiquette doivent porter le type de pseudo filaire, et les deux messages de transposition unidirectionnels doivent être en accord. Donc, dans les procédures actuelles, le point d'extrémité de pseudo filaire qui n'a pas la configuration doit attendre de recevoir un message de transposition d'étiquette afin d'apprendre le type de pseudo filaire, avant de signaler son LSP unidirectionnel.

Pour certaines applications, ceci peut devenir particulièrement onéreux. Par exemple, supposons qu'un appareil d'entrée côté fournisseur (PE, Provider Edge) serve au titre d'une fonction de passerelle entre un réseau de couche 2 et des circuits de rattachement de couche 2 sur des PE distants. Supposons de plus que l'établissement initial ait besoin d'être initialisé à partir du réseau de couche 2 , mais que la signalisation de couche 2 ne contienne pas d'informations suffisantes pour déterminer le type de pseudo filaire. Cependant, cette information est connue au PE qui prend en charge le circuit de rattachement ciblé.

Dans cette situation, il est souvent désirable de permettre que l'initialisation des deux LSP qui composent un pseudo filaire reste indépendante. Un moyen est nécessaire pour permettre à un point d'extrémité de pseudo filaire (qui n'a pas de connaissance a priori du type de pseudo filaire) d'initier la création d'un LSP. Le présent document définit un type de pseudo filaire de caractère générique pour satisfaire ce besoin.

 	1.1	Conventions et terminologie
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].

Le présent document n'introduit pas de nouvelle terminologie. Cependant, il suppose que le lecteur est familiarisé avec la terminologie de la [RFC4447] et de la [RFC3985], "Architecture d'émulation bord à bord de pseudo filaire (PWE3)".

 	2.	Type de pseudo filaire générique

Afin de permettre à un PE d'initier l'échange de signalisation pour un pseudo filaire (PW, PseudoWire) sans connaître son type, un nouveau type de pseudo filaire est défini. Son codet est 0x7FFF. Sa sémantique est la suivante :

1.	Pour le PE ciblé, cette valeur indique qu'il va déterminer le type de pseudo filaire (pour les deux directions) et le signaler dans un message Transposition d'étiquette en retour au PE initiateur.

2.	Pour les procédures de la [RFC4447], ce type de pseudo filaire est interprété comme correspondant à tout type de pseudo filaire autre que lui-même. C'est-à-dire que le PE ciblé peut répondre par tout type de PW valide autre que le type de PW générique.

 	3.	Procédures
 	3.1	Procédures à l'envoi de la classe d'équivalence de transmission (FEC) générique
Quand un PE qui n'est pas configuré à utiliser un type de PW spécifique pour un pseudo filaire particulier souhaite signaler un LSP pour ce pseudo filaire, il envoie le type de PW réglé à "wildcard". Cela indique que le PE cible devrait déterminer le type de PW pour ce pseudo filaire.

Quand un message Transposition d'étiquette (Label Mapping) est reçu pour le pseudo filaire, le PE vérifie le type de PW .

Si le type de PW peut être pris en charge, le PE l'utilise comme type de PW pour les deux directions.

Si le type de PW ne peut pas être pris en charge ou est "générique", il DOIT répondre à ce message avec un message Libération d'étiquette (Label Release) avec un code d'état LDP de "Erreur générique de mauvaise configuration". Les autres actions sortent du domaine d'application du présent document, mais pourraient inclure de le notifier à l'application associée (si il en est) ou de le notifier à la gestion de réseau.

 	3.2	Procédures à la réception de la FEC générique
Quand le PE ciblé reçoit un message Transposition d'étiquette indiquant le type de PW générique, il suit les procédures normales de vérification des valeurs d'identifiant de groupe de rattachement (AGI, Attachment Group Identifier (AGI) et d'identifiant de cible de rattachement individuelle (TAII, Target Attachment Individual Identifier). Si le PE ciblé n'est pas configuré à utiliser un type de PW spécifique non générique, il DOIT répondre à ce message par un message Libération d'étiquette avec un code d'état LDP de "Erreur générique de mauvaise configuration".

Autrement, il traite le message Transposition d'étiquette comme si il avait indiqué le type de PW qu'il est configuré à utiliser.

 	4.	Considérations sur la sécurité

Le présent document a peu d'impact sur les aspects de sécurité de la [RFC4447]. Les échanges de messages restent les mêmes. Cependant, un agent malveillant qui tenterait de se connecter à un circuit d'accès aurait besoin d'un élément d'information de moins. Pour contrer cela, une entité de contrôle de pseudo filaire qui reçoit une demande contenant le type de FEC de caractère générique DEVRAIT ne procéder à l'établissement que si elle est explicitement configurée à le faire pour l'identifiant de rattachement particulier dans le TAI. De plus, le lecteur devrait noter les considérations sur la sécurité de la [RFC4447], en général, et celles concernant l'élément de FEC PWid généralisé, en particulier.

 	5.	Considérations relatives à l'IANA

L'IANA a fait l'allocation suivante suite au consensus de l'IETF dans le registre "Types de pseudo filaires" comme défini dans la [RFC4446].

Type de pseudo filaire	Description
         0x7FFF 	caractère générique

 	6.	Références
 	6.1	Références normatives

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

[RFC4446]	L. Martini, "Allocations de l'IANA pour l'émulation de bord à bord pseudo filaire (PWE3)", avril 2006. (BCP0116)

[RFC4447]	L. Martini et autres, "Établissement et maintenance de pseudo filaires avec le protocole de distribution d'étiquettes", avril  2006. (MàJ par la RFC6723) (P.S. ; Remplacé par RFC8077 STD 84)

 	6.1	Références pour information

[RFC3985]	S. Bryant et autres, "Architecture d'émulation bord à bord pseudo-filaire (PWE3)", mars 2005. (Information)

 	Adresse des auteurs

Luca Martini	George Swallow	
Cisco Systems	Cisco Systems	
9155 East Nichols Avenue, Suite 400	1414 Massachusetts Ave,	
Englewood, CO, 80112	Boxborough, MA 01719	
mél : lmartini@cisco.com 	mél : swallow@cisco.com 	

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2007)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, 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, le IETF TRUST 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 encloses ne viole 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.

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