Groupe de travail Réseau	L. Martini, Cisco Systems Inc.	
Request for Comments : 4446		
BCP 116	avril 2006	
Catégorie : Bonnes pratiques actuelles	Traduction Claude Brière de L'Isle	

Allocations par l'IANA pour l'émulation de pseudo-filaire bord à bord (PWE3)

Statut du présent mémoire
Ce document spécifie les bonnes pratiques actuelles sur l'Internet pour la communauté de l'Internet, et demande des discussions et suggestions pour son amélioration. La diffusion du présent mémoire n'est soumise à aucune restriction.

Notice de Copyright
Copyright (C) The Internet Society (2006).

Résumé
Le présent document alloue les valeurs fixées d'identifiant de pseudo-filaire et autres valeurs fixées pour les protocoles qui ont été définis dans le groupe de travail Émulation de pseudo-filaire bord à bord (PWE3). Des instructions d'allocation détaillées à l'IANA sont aussi incluses dans ce document.
Table des matières
1. Introduction	1
2. Spécification des exigences	1
3. Considérations relatives à l'IANA	2
3.1 Directives de revue par expert	2
3.2 Type de pseudo-filaire MPLS	2
3.3 Type de sous TLV Paramètres d'interface	3
3.4 Identifiants de rattachement	3
3.5 État de pseudo-filaire	4
3.6 Type de canal associé au PW	4
4. Considérations sur la sécurité	4
5. Références	4
5.1 Références normatives	4
5.2 Références pour information	5
Adresse de l'auteur	5
Déclaration complète de droits de reproduction	6

 	1.	Introduction

On trouvera dans le présent document la plupart des nouveaux registres de l'IANA et les processus d'allocation respectifs de l'IANA pour les protocoles définis dans le groupe de travail PWE3 de l'IETF. Les registres de l'IANA définis ici sont en général subdivisés en trois gammes principales : une gamme allouée par consensus de l'IETF en accord avec la [RFC2434], une gamme à allouer selon le processus de revue d'expert en accord avec la [RFC2434], et une gamme à allouer au premier arrivé, premier servi qui est réservée pour les allocations propriétaires de fabricants. Noter que les types propriétaires de fabricant NE DOIVENT PAS être enregistrés pour les normes de l'IETF ou leurs extensions, qu'elles soient encore en développement ou déjà achevées.

 	2.	Spécification des exigences

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

 	3.	Considérations relatives à l'IANA

L'IANA a créé plusieurs registres décrits dans les paragraphes qui suivent. Chacun de ces registres contient des valeurs numériques utilisées pour identifier les types de données. Dans chacun de ces registres, la valeur de 0 est réservée et NE DOIT PAS être utilisée.

 	3.1	Directives de revue par expert
Dans le présent document, des procédures d'allocation pour plusieurs registres invoquent un processus de revue par un expert conformément à la [RFC2434]. L'expert devrait examiner les points suivants :
*	La duplication d'allocations de codets devrait être évitée.
*	Une description brève et claire de l'allocation de codet demandée devrait être fournie.
*	L'allocation de type demandée devrait être appropriée pour la gamme particulière de valeurs demandées dans le registre.

L'expert qui revoit la demande DOIT approuver ou désapprouver la demande dans les dix jours ouvrables de la réception de la demande de revue par expert.

 	3.2	Type de pseudo-filaire MPLS
L'IANA a établi le registre des "Types de pseudo-filaires MPLS". Ce type a des valeurs de 15 bits. Les valeurs de type de PW de 1 à 30 sont spécifiées dans ce document, et les valeurs de type de PW de 31 à 1024 sont à allouer par l'IANA, en utilisant la politique de "revue par expert" définie dans la [RFC2434]. Les valeurs de type de PW de 1025 à 4096 et 32767 sont à allouer en utilisant la politique de consensus de l'IETF définie dans la [RFC2434]. Les valeurs de type de PW de 4097 à 32766 sont réservées pour des extensions propriétaires de fabricant et sont à allouer par l'IANA, en utilisant la politique du "premier arrivé, premier servi" définie dans la [RFC2434]. Une description du type de pseudo-filaire est exigée pour toute allocation dans ce registre. De plus, pour la gamme des extensions propriétaires de fabricant, la mention du nom d'une personne ou entreprise est aussi exigée. Un document de référence devrait aussi être fourni.

Les allocations initiales de type de pseudo-filaire sont spécifiées comme suit :

Description de type de PW	Référence
0x0001  DLCI en relais de trame (mode Martini)	[RFC4619]
0x0002  Transport de SDU de VCC AAL5 ATM	[RFC4717]
0x0003  Transport de cellule transparente ATM	[RFC4717]
0x0004  Mode Ethernet étiqueté	[RFC4448]
0x0005  Ethernet	[RFC4448]
0x0006  HDLC	[RFC4618]
0x0007  PPP	[RFC4618]
0x0008  Service d'émulation de circuit SONET/SDH sur MPLS	[RFC4842]
0x0009  Transport de cellule de VCC n à une en ATM	[RFC4717]
0x000A  Transport de cellule de VPC n à une en ATM	[RFC4717]
0x000B  Transport IP de couche 2	[RFC3032]
0x000C  Mode cellule VCC une à une en ATM	[RFC4717]
0x000D  Mode cellule VPC une à une en ATM	[RFC4717]
0x000E  Transport de PDU de VCC AAL5 ATM	[RFC4717]
0x000F  Mode accès de relais de trame	[RFC4619]
0x0010  Émulation de circuit SONET/SDH sur paquet	[RFC4842]
0x0011  E1 sur paquet ignorant de la structure	[RFC4553]
0x0012  T1 (DS1) sur paquet ignorant de la structure	[RFC4553]
0x0013  E3 sur paquet ignorant de la structure	[RFC4553]
0x0014  T3 (DS3) sur paquet ignorant de la structure	[RFC4553]
0x0015  Mode CESoPSN de base	[RFC5086]
0x0016  Mode AAL1 TDMoIP	[RFC5087]
0x0017  TDM CESoPSN avec CAS	[RFC5086]
0x0018  Mode AAL2 TDMoIP	[RFC5087]
0x0019  DLCI en relais de trame	[RFC4619]

 	3.3	Type de sous TLV Paramètres d'interface
L'IANA a établi le registre des "types de sous TLV de paramètre d'interface de pseudo-filaire". Ce type a des valeurs de 8  bits. Les types de sous TLV de 1 à 12 sont spécifiés dans ce document. Les types de sous TLV de 13 à 64 sont à allouer par l'IANA, en utilisant la politique de "revue par expert" définie dans la [RFC2434]. Les types de sous TLV de 65 à 127 et 255 sont à allouer en utilisant la politique de consensus de l'IETF définie dans la [RFC2434]. Les valeurs de types de sous TLV de 128 à 254 sont réservées pour des extensions de fabricant-propriétaires et seront allouées par l'IANA, en utilisant la politique du "premier arrivé, premier servi" définie dans la [RFC2434].

Toutes les allocations demandées sur ce registre exigent une description de jusqu'à 54 caractères.

Pour chaque allocation, un champ Longueur DOIT aussi être spécifié dans un des formats suivants :
-	Texte comme suit :"jusqu'à X", où X est un entier décimal.
-	Jusqu'à 3 entiers décimaux différents.
Le texte "jusqu'à X" signifie jusqu'à X inclus.

De plus, pour la gamme des extensions de fabricant-propriétaires, la mention du nom d'une personne ou entreprise est aussi exigée. Un document de référence devrait aussi être fourni.

Les allocations initiales de type sous TLV de paramètre d'interface de pseudo-filaire sont spécifiées ci-dessous :

Identifiant de paramètre	Longueur	Description	Référence
0x01	4	MTU d'interface en octets	[RFC4447]
0x02	4	Nombre maximum de cellules ATM enchaînées	[RFC4717]
0x03	≤ 82	Chaîne facultative de description d'interface	[RFC4447] [RFC2277]
0x04	4	Octets de charge utile CEP/TDM	[RFC4842] [RFC5087]
0x05	4	Options de CEP	[RFC4842]
0x06	4	Identifiant de VLAN demandé	[RFC4448]
0x07	6	Débit binaire CEP/TDM	[RFC4842] [RFC5087]
0x08	4	Longueur de DLCI de relais de trame	[RFC4619]
0x09	4	Indicateur de fragmentation	[RFC4623]
0x0A	4	Indicateur de rétention de FCS	[RFC4720]
0x0B	4/8/12	Options de TDM	[RFC5087]
0x0C	4	Paramètre de VCCV	[RFC5085]

Noter que le champ Longueur est défini comme longueur de la sous TLV, incluant le type de sous TLV et le champ Longueur lui-même.

 	3.4	Identifiants de rattachement
 	3.4.1	Type d'identifiant individuel de rattachement
L'IANA a établi le registre de "Type d'identifiant de rattachement individuel (AII)". Ce type a des valeurs de 8 bits. La valeur 1 du type AII est définie dans ce document. Les valeurs de type AII de 2 à 64 seront allouées par l'IANA, en utilisant la politique de "revue par expert" définie dans la [RFC2434]. Les valeurs de type AII de 65 à 127 et 255 seront allouées en utilisant la politique de consensus de l'IETF définie dans la [RFC2434]. Les valeurs de type AII de 128 à 254 sont réservées pour des extensions de fabricant-propriétaires et seront allouées par l'IANA, en utilisant la politique du "premier arrivé, premier servi" définie dans la [RFC2434].

Toutes les allocations demandées sur ce registre exigent une description de jusqu'à 54 caractères.
Pour chaque allocation, un champ Longueur DOIT aussi être spécifié comme entier décimal.
De plus, pour la gamme des extensions de fabricant-propriétaires, une mention de nom de personne ou entreprise est aussi exigé. Un document de référence devrait aussi être fourni.

Les allocations initiales de type d'identifiant individuel de rattachement (AII, Attachment Individual Identifier) sont spécifiées ci-dessous :

Type AII	Longueur	Description	Référence
0x01	4	Nombre de 32 bits non signé d'identifiant local.	[RFC6074]

 	3.4.2	Type d'identifiant de groupe de rattachement (AGI)
L'IANA a établi le registre de "Type d'identifiant de groupe de rattachement (AGI, Attachment Group Identifier)". Ce type a des valeurs de 8 bits. La valeur de type d'AGI 1 est définie dans ce document. Les valeurs de type d'AGI de 2 à 64 seront allouées par l'IANA en utilisant la politique de "revue d'expert" définie dans la [RFC2434]. Les valeurs de type d'AGI de 65 à 127 et 255 seront allouées en utilisant la politique de consensus de l'IETF définie dans la [RFC2434]. Les valeurs de type d'AGI de 128 à 254 sont réservées pour des extensions de fabricant-propriétaires et seront allouées par l'IANA, en utilisant la politique du "premier arrivé, premier servi" définie dans la [RFC2434].

Toutes les allocations demandées sur ce registre exigent une description de jusqu'à 54 caractères.
Pour chaque allocation, un champ Longueur DOIT aussi être spécifié comme entier décimal.
De plus, pour la gamme des extensions de fabricant-propriétaires, une mention de nom de personne ou entreprise est aussi exigée. Un document de référence devrait aussi être fourni.

Les allocations initiales du type Identifiant de groupe de rattachement (AGI) sont spécifiées ci-dessous :

Type d'AGI	Longueur	Description	Référence
0x01	8	AGI codé comme différenciateur de chemin	[RFC6074]

 	3.5	État de pseudo-filaire
L'IANA a établi un registre des "Codes d'état de pseudo-filaire". Ce sont des chaînes binaires de 32 octets. Les bits d'état de 0 à 4 sont définis dans ce document. Les bits d'état de 5 à 31 seront alloués par l'IANA en utilisant la politique de "revue par expert" définie dans la [RFC2434].

Toute demande d'allocation dans ce registre exige une description de jusqu'à 65 caractères.

Les allocations initiales de valeur de code d'état de pseudo filaire sont les suivantes :

Gabarit binaire	Description	Référence
0x00000000 	Transmission de pseudo-filaire (supprime toutes défaillances)	[RFC4447]
0x00000001 	Pseudo-filaire non transmetteur 	[RFC4447]
0x00000002 	Circuit local de rattachement (entrée) faute de réception 	[RFC4447]
0x00000004 	Circuit local de rattachement (sortie) faute d'émission	[RFC4447]
0x00000008 	PW local côté PSN (entrée) faute de réception	[RFC4447]
0x00000010 	PW local côté PSN (sortie) faute d'émission	[RFC4447]

 	3.6	Type de canal associé au PW
Pour la définition de "type de canal associé de PW", voir la [RFC4385].

 	4.	Considérations sur la sécurité

Le présent document spécifie seulement des identifiants fixés, et non les protocoles utilisés pour porter les paquets encapsulés à travers le réseau. Chacun de ces protocoles peut avoir son propre ensemble de problèmes de sécurité, mais ces problèmes ne sont pas affectés par les identifiants spécifiés ici.

 	5.	Références
 	5.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)

[RFC2277]	H. Alvestrand, "Politique de l'IETF en matière de jeux de caractères et de langages", BCP 18, janvier   1998.

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre 1998. (Rendue obsolète par la RFC5226)

 	5.2	Références pour information

[RFC3032]	E. Rosen et autres, "Codage de pile d'étiquettes MPLS", janvier 2001.

[RFC4385]	S. Bryant et autres, "Mot de contrôle d'émulation bord à bord pseudo filaire (PWE3) à utiliser sur un PSN MPLS", février 2006. (P.S.)

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

[RFC4448]	L. Martini et autres, "Méthodes d'encapsulation pour le transport d'Ethernet sur des réseaux MPLS", avril 2006. (P.S. ; MàJ par RFC8469)

[RFC4553]	A. Vainshtein et autres, "Multiplexage de paquet à répartition dans le temps ignorant la structure (SAToP)", juin 2006. (P.S.)

[RFC4618]	L. Martini et autres, "Méthodes d'encapsulation pour le transport du contrôle de liaisons de données en PPP/haut-niveau (HDLC) sur réseaux MPLS", septembre 2006. (P.S.)

[RFC4619]	L. Martini et autres, "Méthodes d'encapsulation pour le transport de relais de trame sur les réseaux de commutation d'étiquettes multiprotocoles (MPLS)", septembre 2006. (P.S.)

[RFC4623]	A. Malis, M. Townsley, "Fragmentation et réassemblage d'émulation bord à bord pseudo filaire (PWE3)", août 2006. (P.S.)

[RFC4717]	L. Martini et autres, "Méthodes d'encapsulation pour le transport de mode de transfert asynchrone (ATM) sur réseaux MPLS", décembre 2006. (P.S.)

[RFC4720]	A. Malis et autres, "Rétention de séquence de vérification de trame d'émulation bord à bord pseudo filaire (PWE3)", novembre 2006. (P.S.)

[RFC4842]	A. Malis et autres, "Émulation de circuit sur paquet (CEP) en réseau optique synchrone/hiérarchie numérique synchrone (SONET/SDH)", avril 2007. (Remplacé par RFC5143) (P.S.)

[RFC5085]	T. Nadeau et C. Pignataro, éditeurs, "Vérification de connexité de circuit virtuel pseudo filaire (VCCV) : un canal de contrôle pour les pseudo filaires", décembre 2007. (MàJ par RFC5586) 

[RFC5086]	A. Vainshtein et autres, "Service d'émulation de circuit multiplexé par répartition dans le temps (MRT) en fonction de la structure sur un réseau à commutation de paquets (CESoPSN)", décembre 2007. (Information)

[RFC5087]	Y(J). Stein et autres, "Multiplexage à répartition dans le temps sur IP (TDMoIP)", décembre 2007. (Information)

[RFC6074]	E. Rosen, B. Davie, V. Radoaca et W. Luo, "Approvisionnement, auto découverte et signalisation dans les réseaux privés virtuels de couche 2 'L2VPN)", janvier 2011. (P.S.)

 	Adresse de l'auteur
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
USA
mél : lmartini@cisco.com 

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2006).

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 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 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 fourni par l'activité de soutien administatif (IASA) de l'IETF.