Groupe de travail Réseau	A. Vainshtein, ECI Telecom
Request for Comments : 5287	Y(J). Stein, RAD Data Communications
Catégorie : Sur la voie de la normalisation	août 2008
Traduction Claude Brière de L'Isle	

Extensions de protocole de commande pour l’établissement de pseudo-filaires de multiplexage à division dans le temps (TDM) dans les réseaux MPLS

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la 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.

Résumé
Le présent document définit des extensions au protocole de commande d’émulation de pseudo-filaire de bord à bord (PWE3, Pseudowire Emulation Edge-to-Edge) de la RFC 4447 et aux allocations de l’IANA à PWE3 de la RFC 4446 requises pour l’établissement de pseudo-filaires en multiplexage par répartition dans le temps (TDM, Time-Division Multiplexing) dans les réseaux MPLS.
Table des matières
1. Introduction	1
2. FEC de PW pour l’établissement des pseudo-filaires TDM	2
3. Paramètres d’interface pour les pseudo-filaires TDM	3
3.1 Vue d’ensemble	3
3.2 Octets de charge utile CEP/TDM	3
3.3 Débit binaire CEP/TDM (0x07)	4
3.4 Nombre de cellules AAL1 TDMoIP par paquet	4
3.5 Mode AAL1 TDMoIP	4
3.6 Options AAL2 TDMoIP	4
3.7 Indicateur de fragmentation	5
3.8 Options TDM 	5
4. Extension des services NxDS0 de base CESoPSN avec la signalisation d’application CE	6
5. Codes d’état de LDP	7
6. Utilisation de la TLV État de PW	7
7. Considérations relatives à l’IANA	8
8. Considérations sur la sécurité	8
9. Remerciements	8
10. Références	8
10.1 Références normatives	8
10.2 Références pour information	9
Adresse des auteurs	9
Déclaration complète de droits de reproduction	9

 	1.	Introduction

Le présent document définit une extension au protocole de commande PWE3 [RFC4447] et les allocations de l’IANA à PWE3 [RFC4446] requises pour l’établissement de pseudo-filaires TDM dans les réseaux MPLS.

Les pseudo-filaires TDM ignorants de la structure ont été spécifiés dans la [RFC4553], et ceux sensibles à la structure ont été spécifiés dans les [RFC5086] et [RFC5087].

La [RFC4447] définit des extensions au protocole de distribution d’étiquettes (LDP, Label Distribution Protocol) [RFC5036] qui exigent de changer les étiquettes de pseudo-filaires pour les PW qui émulent divers services  de couche 2 (Ethernet, relais de trame (FR, Frame Relay), mode de transfert asynchrone (ATM, Asynchronous Transfer Mode), commande de liaison de données de haut niveau (HDLC, High-Level Data Link Control), etc.). L’établissement de pseudo-filaires TDM exige à la fois l’interprétation des éléments d’information existants de ces extensions et l’échange d’informations supplémentaires.

L’établissement des PW TDM utilisant L2TPv3 sera défini dans un document distinct.

L’état des circuits de rattachement des PW TDM peut être échangé entre les extrémités de fournisseur (PE, Provider Edge) de terminaison en utilisant le mécanisme d’état de pseudo-filaire défini dans la [RFC4447] sans aucun changement. Cependant, l’usage de ce mécanisme N’EST PAS RECOMMANDÉ pour les PW TDM car l’indication de l’état des circuits de rattachement TDM est porté dans la bande dans le plan des données.

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.	FEC de PW pour l’établissement des pseudo-filaires TDM

La [RFC4447] utilise le message de transposition d’étiquette LDP [RFC5036] pour annoncer le lien d’étiquette de FEC à PW, et définit deux types de classes d’équivalence de transmission (FEC, Forwarding Equivalence Class) de pseudo-filaires qui peuvent êtte utilisées pour cela :

1. FEC PWId (FEC 128). Cette FEC contient :
a) le type de PW
b) le bit Contrôle (qui indique la présence du mot de commande)
c) l’identifiant de groupe
d) l’identifiant de PW
e) le sous TLV Paramètres d’interface

2. FEC généralisée de PW (FEC 129). Cette FEC contient seulement :
a) le type de PW
b) le bit Contrôle (qui indique la présence du mot de commande)
c) l’identifiant de groupe de rattachement (AGI, Attachment Group Identifier), l’identifiant individuel de rattachement de source (SAII, Source Attachment Individual Identifier), et l’identifiant individuel de rattachement de cible (TAII, Target Attachment Individual Identifier) qui remplacent l’identifiant de pseudo-filaire.

L’identifiant de groupe et les paramètres d’interface sont contenus dans des TLV séparés, appelés le TLV de groupement de PW et le TLV de paramètres d’interface.

L’un et l’autre de ces types de FEC de PW PEUT être utilisé pour l’établissement des PW TDM avec le choix approprié de types de PW et de paramètres d’interface.

Les types de PW pour les PW TDM sont alloués dans la [RFC4446] comme suit :
o  0x0011  E1 ignorant de la structure sur paquet [RFC4553]
o  0x0012  T1 (DS1) ignorant de la structure sur paquet [RFC4553]
o  0x0013  E3 ignorant de la structure sur paquet [RFC4553]
o  0x0014  T3 (DS3) ignorant de la structure sur paquet [RFC4553]
o  0x0015  Mode de base CESoPSN [RFC5086]
o  0x0016  Mode AAL1 TDMoIP [RFC5087]
o  0x0017  TDM CESoPSN avec signalisation associée au canal (CAS, Channel Associated Signalling) [RFC5086]
o  0x0018  Mode AAL2 TDMoIP [RFC5087]

Les deux points d’extrémité DOIVENT s’accorder sur le type de PW, car il est obligatoire que les deux directions du PW soient du même type.

Le bit Contrôle DOIT toujours être établi pour les PW TDM car toutes les encapsulations de PW TDM utilisent toujours un mot de commande.

Le type de PW 0x0012 DOIT aussi être utilisé pour l’établissement de PW TDM ignorants de la structure entre une paire de circuits de rattachement J1 (voir la [RFC4805]).

 	3.	Paramètres d’interface pour les pseudo-filaires TDM
 	3.1	Vue d’ensemble
Les paramètres d’interface pertinents pour l’établissement des PW TDM sont les suivants .

Paramètre d’interface	Identifiant de sous TLV	Longueur	Description
Octets de charge utile CEP/TDM	0x04	4	paragraphe 3.2
Débit binaire CEP/TDM	0x07	6	paragraphe 3.3
Nombre de cellules AAL1 TDMoIP par paquet	0x0E	4	paragraphe 3.4
Mode AAL1 TDMoIP	0x10	4	paragraphe 3.5
Options AAL2 TDMoIP	0x11	8 ou plus, voir note	paragraphe 3.6
Indicateur de fragmentation	0x09	4	paragraphe 3.7
Options TDM	0x0B	4, 8, ou 12	paragraphe 3.8

Si elle n’est pas explicitement indiquée autrement dans la description appropriée, la valeur du paramètre d’interface est interprétée comme un entier non signé de la taille appropriée (16 ou 32 bits).

Note : la longueur du paramètre d’interface Options AAL2 TDMoIP de base est 8 octets, et quand la transposition facultative du champ Identifiant de canal (CID, Channel ID) est utilisée, il y a un octet supplémentaire pour chaque circuit transporté. Donc, si un circuit est pris en charge, ce message occupe 9 octets. Comme il ne peut pas y avoir plus de 248 CID dans un PW, cela ne peut jamais excéder 256 (quand chaque canal vient d’un circuit différent). 248 canaux se traduisent en moins de 9 E1, et donc, pour ce cas, la longueur ne fait pas plus de 17 octets. Un seul PE n’est pas obligé de prendre en charge plus de 10 PW AAL2 (c’est-à-dire, jusqu’à 2480 canaux individuels, ce qui est plus que ce qui est porté par un STM1 complètement rempli). Donc, la mémoire requise pour mémoriser toutes les informations de transposition AAL2 est normalement entre 80 et 170 octets par PE.

 	3.2	Octets de charge utile CEP/TDM
Ce paramètre est utilisé pour l’établissement de tous les PW SAToP et CESoPSN (c’est-à-dire, les types de PW 0x0011, 0x0012, 0x0013, 0x0014, 0x0015, et 0x0017) et a la sémantique suivante :

1.	Les deux points d’extrémité d’un PW TDM DOIVENT s’accorder sur la même valeur de ce paramètre pour que le PW soit établi avec succès.

2.	La présence de ce paramètre dans la FEC de PWId ou dans le TLV Champ de paramètres d’interface est FACULTATIF. Si ce paramètre est omis, les tailles de charge utile par défaut définies pour le service correspondant (voir les [RFC4553], [RFC5086]) DOIVENT être supposées.

3.	Pour l’émulation ignorante de la structure, toute valeur cohérente avec la MTU du PSN sous-jacent PEUT être spécifiée.

4.	Pour les PW CESoPSN :
a) La valeur spécifiée P DOIT être un entier multiple de N, où N est le nombre d’intervalles de temps dans le circuit de rattachement.
b) Pour NxDS0 spécifique du circuit avec CAS :
i) (P/N) DOIT être un facteur entier du nombre de trames par circuit multi-trames correspondant (c’est-à-dire, 16 pour un circuit E1 et 24 pour un circuit T1 ou J1).
ii) La taille de la sous-structure de signalisation n’est pas prise en compte pour la valeur P spécifiée.

5. Ce paramètre NE DOIT PAS être utilisé pour l’établissement des PW TDMoIP (c’est-à-dire, les PW de type 0x0016 et 0x0018).

 	3.3	Débit binaire CEP/TDM (0x07)
Ce paramètre d'interface représente le débit binaire du service TDM dans les multiples du débit "de base" de 64 kbit/s. Son usage pour tous les types de PW TDM suppose la sémantique suivante :

1.	Ce paramètre d'interface PEUT être omis si le débit du circuit de rattachement peut être déduit sans ambiguïté du type de PW (c’est-à-dire, pour une émulation ignorante de la structure de circuits E1, E3, et T3). Si cette valeur est omise pour les émulations ignorantes de la structure de type de PW T1, le mode d’émulation de base DOIT être supposé.

2.	Si il est présent, seules les valeurs suivantes DOIVENT être spécifiées pour l’émulation ignorante de la structure (voir la [RFC4553] :
a) émulation ignorante de la structure E1 - 32
b) émulation ignorante de la structure T1 :
i) DOIT être réglée à 24 dans le mode d’émulation de base,
ii) DOIT être réglée à 25 pour le mode d’émulation "T1 aligné sur l’octet",
c) émulation ignorante de la structure E3 - 535
d) émulation ignorante de la structure T3 - 699

3.	Pour toutes les sortes d’émulations ignorantes de la structure, ce paramètre DOIT être réglé à N, où N est le nombre de canaux DS0 dans le circuit de rattachement correspondant.

Note : la valeur 24 ne représente pas le débit binaire réel du circuit T1 ou J1 (1,544 Mbit/s) en unités de 64 kbit/s. Les valeurs mentionnées ci-dessus sont utilisées par convention.

Note : Un espace de 4 octets est réservé pour ce paramètre pour la compatibilité avec la [RFC4842].

 	3.4	Nombre de cellules AAL1 TDMoIP par paquet
Ce paramètre PEUT être présent pour les PW en mode AAL1 TDMoIP (type de PW 0x0016) et spécifie le nombre de PDU  AAL1 de 48 octets par paquet MPLS. Toutes les valeurs cohérentes avec la MTU du PSN sous-jacent PEUVENT être spécifiées. Si ce paramètre n’est pas spécifié, sa valeur par défaut est de 1 PDU par paquet pour les faibles débits binaires (débits binaires CEP/TDM inférieurs ou égaux à 32) et de 5 pour les débits binaires élevés (débit binaire CEP/TDM de 535 ou 699).

 	3.5	Mode AAL1 TDMoIP
Ce paramètre PEUT être présent pour les PW en mode AAL1 TDMoIP (type de PW 0x0016) et spécifie le mode AAL1. Si ce paramètre n’est pas présent, le mode AAL1 par défaut est "structuré". Quand il est spécifié, les valeurs ont la signification suivante :
0 – AAL1 non structuré
2 - AAL1 structuré
3 - AAL1 structuré avec CAS

Les deux points d’extrémité DOIVENT s’accorder sur le mode AAL1 TDMoIP.

 	3.6	Options AAL2 TDMoIP
Ce paramètre DOIT être présent pour les PW en mode AAL2 TDMoIP (type de PW  0x0018) et a le format suivant :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    0x11       |    Longueur   | V |      Codage               |
+---------------+---------------+---+-----------+---------------+
|                     Durée maximum                             |
+---------------+---------------+---------------+---------------+
|                    Bases de transposition de CID              |
+---------------+---------------+---------------+---------------+

Les champs de ce paramètre sont définis comme suit  :

V définit les capacités de détection d’activité vocale (VAD, Voice Activity Detection). Ses valeurs ont la signification suivante :
0 signifie que l’activité est seulement indiquée par la signalisation.
1 signifie que la détection d’activité vocale est employée.
3 signifie que ce canal est toujours actif. En particulier, ce canal PEUT être utilisé pour la récupération de la synchronisation.

Codage spécifie le traitement natif du signal effectué sur la charge utile. Quand aucun traitement natif du signal n’est effectué (c’est-à-dire, le codage G.711) ce champ DOIT être à zéro. Les autres valeurs spécifiques qui peuvent être utilisées dans ce champ sortent du domaine d’application de la présente spécification, mais les deux directions DOIVENT correspondre pour que l’établissement du PW réussisse.

Durée maximum spécifie le maximum de temps permis pour remplir une PDU AAL2, en unités de 125 microsecondes. Pour les canaux non codés à 64 kbit/s, cela équivaut numériquement au nombre maximum d’octets par PDU et DOIT être moins de 64. Pour les autres paramètres de codage, de plus grandes valeurs PEUT être atteintes.

Bases de transposition de CID est un paramètre FACULTATIF ; son existence et sa longueur sont déterminées par le champ Longueur. Si la transposition des valeurs de CID AAL2 en une interface physique et un intervalle de temps est configurée de façon statique, ou si la commutation à AAL2 [Q.2630.1] est employée, ce paramètre NE DOIT PAS apparaître. Quand il est présent, et que les canaux appartiennent à des interfaces physiques N (c’est-à-dire, des E1 ou T1 N) il DOIT avoir une longueur de N octets. Chaque octet représente un nombre à soustraire du CID pour obtenir le nombre d’intervalles de temps pour chaque interface physique. Par exemple, si le paramètre de bases de transposition de CID consiste en les octets 20 et 60, cela signifie que l’intervalle de temps 1 du circuit 1 correspond au CID 21, et l’intervalle de temps 1 du circuit 2 est appelé 61.

 	3.7	Indicateur de fragmentation
Ce paramètre d'interface est spécifié dans la [RFC4446], et son utilisation est expliquée dans la [RFC4623]. Il DOIT être omis dans la FEC de tous les PW TDM sauf des services NxDS0 spécifiques de circuits avec le CAS utilisant l’encapsulation CESoPSN. Dans le cas de ces services, il DOIT être présent dans la FEC de PW si la valeur P de la taille de charge utile spécifiée diffère de Nx(nombre de trames par circuit de multi-trames).

 	3.8	Options TDM
C’est un nouveau paramètre d'interface. Son identifiant de paramètre d'interface (0x0B) a été alloué par l’IANA, et son format est montré dans la Figure 1 :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ID de paramètre|  Longueur     |R|D|F|X|SP |CAS|   RSVD-1      |
+---------------+---------------+-+-+-+-+-+-+---+---------------+
|0|     PT      |   RSVD-2      |               FREQ            |
+-+-------------+---------------+---------------+---------------+
|                         SSRC                                  |
+---------------+---------------+---------------+---------------+

Figure 1 : Format du sous TLV Options de paramètre d'interface TDM

Les champs de ce diagramme sont utilisés comme suit :

ID de paramètre : identifie les options de paramètre d'interface de PW TDM, 0x0B.

Longueur  : 4, 8, ou 12 (voir ci-dessous).

R : bit Usage d’en-tête RTP : si il est établi, il indique que le point d’extrémité de PW qui distribue cette FEC s’attend à recevoir un en-tête RTP dans l’encapsulation. L’en-tête RTP va seulement être utilisé si les deux points d’extrémité s’attendent à le recevoir. Si ce bit est à zéro, Longueur DOIT être réglé à 4 ; autrement, il DOIT être 8 ou 12 (voir ci-dessous). Si le point d’extrémité de PW ne peut pas satisfaire cette exigence, le message Transposition d’étiquette contenant la FEC en question DOIT être rejeté avec le code d’état approprié (voir la Section 4).

D : bit d’horodatage différentiel : si il est établi, il indique que le point d’extrémité de PW qui distribue cette FEC s’attend à ce que l’homologue utilise le mode d’horodatage différentiel dans les paquets qui lui sont envoyés. Si le PW homologue ne peut pas satisfaire cette exigence, le message Transposition d’étiquette contenant la FEC en question DOIT être rejeté avec le code d’état approprié (voir la Section 4).

F, X  : réservé pour de futures extensions. DOIT être à zéro lorsque distribué et DOIT être ignoré à réception.

SP  : code la prise en charge des paquets de signalisation CESoPSN (voir la [RFC5086]) :
o	'00' pour les PW qui n’utilisent pas de paquets de signalisation
o	'01' pour les PW CESoPSN qui portent des paquets de données TDM et attendent des paquets de signalisation d’application côté consommateur (CE, Customer Edge) dans un PW séparé
o	'10' pour un PW portant des paquets CE de signalisation d’application avec les paquets de données dans un PW séparé
o	'11' pour les PW CESoPSN portant des données TDM et de signalisation d’application CE sur le même PW.

CAS  : DOIT être à zéro pour tous les types de PW TDM sauf les services NxDS0 spécifiques de circuit avec CAS. Pour ces services, il code le tramage de circuit comme suit :
o	'01' - circuit E1
o	'10' - circuit T1/ESF
o	'11' - circuit T1 SF

RSVD-1 et RSVD-2  : bits réservés, qui DOIVENT être réglés à 0 par le point d’extrémité de PW qui distribue cette FEC et DOIVENT être ignorés par le receveur.

PT  : Indique la valeur du type de charge utile dans l’en-tête RTP attendu par le point d’extrémité du PW qui distribue cette FEC. Une valeur de 0 signifie que la vérification de la valeur de PT ne va pas être utilisée pour détecter les paquets mal formés.

FREQ  : Fréquence de l’horloge d’horodatage en unités de 8 kHz.

SSRC  : Indique la valeur de l’identifiant de source de synchronisation (SSRC ID) dans l’en-tête RTP attendu par le point d’extrémité de PW qui distribue cette FEC. Une valeur de 0 signifie que la vérification de la valeur de SSRC ID ne va pas être utilisée pour détecter les mauvaises connexions. Autrement, Longueur peut être réglé à 8 dans ce cas.

Notes :
1. Ce paramètre d'interface PEUT être omis dans les cas suivants :
a) PW SAToP qui n’utilisent pas d’en-tête RTP [RFC4553].
b) Services de base CESoPSN NxDS0 sans signalisation d’application CE [RFC5086].
c) PW en mode 0 ou 2 AAL1 TDMoIP qui n’utilisent pas RTP.
d) PW AAL2 TDMoIP qui ne relayent pas la signalisation CAS et n’utilisent pas RTP.

2. Ce paramètre d'interface DOIT être présent dans les cas suivants :
a) Tous les PW TDM qui utilisent des en-têtes RTP.
b) Les PW CESoPSN qui portent des services de base NxDS0 et utilisent des paquets de signalisation CESoPSN pour porter la signalisation d’application CE. Ce cas est discuté en détails à la Section 4.
c) Les PW CESoPSN qui portent des services NxDS0 spécifiques du services avec CAS.
d) Les PW AAL1 TDMoIP de mode 1.
e) Les PW AAL2 TDMoIP qui relayent la signalisation CAS.

3. Si l’en-tête RTP et éventuellement le mode d’horodatage différentiel sont utilisés, la valeur du champ Longueur DOIT être réglée à 8 ou 12 afin de s’accommoder des champs Fréquence d’horloge d’horodatage et SSRC.

4. L’usage ou non de l’en-tête RTP DOIT correspondre pour les deux directions constituant le PW TDM. Cependant, il est possible d’utiliser le mode d’horodatage différentiel dans une seule direction.

 	4.	Extension des services NxDS0 de base CESoPSN avec la signalisation d’application CE

La [RFC5086] déclare que les services de base NxDS0 peuvent être étendus pour porter la signalisation d’application CE (par exemple, CAS) dans des paquets de signalisation spéciaux portés dans un PW séparé.

Les règles suivantes définissent l'établissement de paires correspondantes de PW CESoPSN utilisant la FEC PWId et les extensions définies ci-dessus :

1. Les deux PW DOIVENT :
a) avoir le même type de PW  ;
b) utiliser la même méthode d’établissement (c’est-à-dire, soit les deux utilisent la FEC PWId, soit les deux utilisent la FEC PW généralisé)  ;
c) avoir les mêmes valeurs de tous les paramètres d'interface mentionnés au paragraphe 3.1 à l’exception du codet dans le champ SP du paramètre Options TDM :
i) pour le PW portant des paquets de données TDM, les bits SP DOIVENT être réglés à '01'  ;
ii) pour le PW portant les paquets de signalisation, les bits SP DOIVENT être réglés à '10'.

2. Si la FEC PWId a été utilisée :
a) la valeur du PWId pour le PW CESoPSN portant les paquets de données TDM DOIT être paire  ;
b) la valeur du PWId pour le PW CESoPSN portant la signalisation d’application CE DOIT être la prochaine (impaire) valeur après le PWId (pair) du PW CESoPSN qui porte les paquets de données TDM.

Quand on utilise la FEC de PW généralisé pour l'établissement des deux PW, aucune règle spécifique pour faire correspondre les deux FEC n’est définie. Des mécanismes spécifiques de la mise en œuvre PEUVENT être employés pour vérifier la bonne correspondance du PW de données TDM avec son PW de signalisation CE associé.

Si un des deux PW associés a été établi et si l’établissement de l’autre a échoué, ou échoue pour une raison quelconque après avoir été établi, le PW établi DOIT être supprimé.

 	5.	Codes d’état de LDP

En plus des codes d'état définis aux paragraphes 5.1 et 7.2 de la [RFC4447], les codes d'état suivants définis dans la [RFC4446] DOIVENT être utilisés pour indiquer la raison de l’échec de l’établissement d’un PW TDM :

1. Débit binaire incompatible :
a) dans le cas d’une discordance des modes d’encapsulation T1 (basique contre aligné sur l’octet)  ;
b) dans le cas d’une discordance du nombre d’intervalles de temps pour les services de base NxDS0 ou les services NxDS0 spécifiques de circuit avec CAS.

2. Mauvaise configuration CEP/TDM :
a) dans le cas d’une discordance dans l’usage désiré de l’en-tête RTP,
b) dans le cas d’une discordance de la fréquence désirée de l’horloge d’horodatage,
c) dans le cas d’une discordance du comportement attendu des paquets de signalisation pour les services de base CESoPSN NxDS0 étendus pour porter la signalisation d’application CE dans des paquets de signalisation séparés,
d) dans le cas de services NxDS0 spécifiques de circuit avec CAS si les types de tramage des circuits sont différents,
e) dans le cas de PW AAL1 TDMoIP avec différents modes AAL1 spécifiés par les points d’extrémité.

3. L’erreur générique Mauvaise configuration PEUT être utilisée pour indiquer toute défaillance d’établissement non couverte ci-dessus.

Dans les cas 2a, 2b, 2c, et 2e ci-dessus, l’utilisateur PEUT reconfigurer les points d’extrémité et tenter d’établir à nouveau le PW.

Dans le cas de 2d, la défaillance est fatale.

Noter que régler le bit Contrôle (voir à la Section 2) à zéro DOIT résulter en un état LDP de "Bit C illégal".

 	6.	Utilisation de la TLV État de PW

Le mot de commande PW TDM porte des indications d’état pour les circuits de rattachement (champs L et M) et l’indication de PSN (champ R ) (voir les [RFC4553], [RFC5086], et [RFC5087]). Une fonction similaire est disponible via l’utilisation du TLV État de PW (voir le paragraphe 5.4.2 de la [RFC4447]). Si ce dernier mécanisme est employé, le PE qui signale envoie à son homologue un TLV État de PW pour ce pseudo-filaire, en établissant les bits appropriés (voir le paragraphe 3.5 de la [RFC4446]) :
o	Pseudo-filaire non transmetteur
o	Circuit local de rattachement (entrée) faute de réception
o	Circuit local de rattachement (sortie) faute d'émission
o	PW local côté PSN (entrée) faute de réception
o	PW local côté PSN (sortie) faute d'émission

Tant que la fonction d’interfonctionnement de PW TDM est opérationnelle, l’usage du TLV État de PW N’EST PAS RECOMMANDÉ afin d’éviter les conflits entre les indications d’état rapportées par le plan des données et le plan de contrôle. Cependant, si la fonction d’interfonctionnement (IWF, interworking function) de PW TDM est elle-même défaillante alors que le plan de contrôle PWE3 reste opérationnel, un TLV État avec tous les bits ci-dessus établis DEVRAIT être envoyé.

 	7.	Considérations relatives à l’IANA

La plupart des allocations de l’IANA demandées par le présent document sont déjà mentionnées dans la [RFC4446]. Des allocations supplémentaires ont été faites pour quatre types de sous TLV de paramètre d’interface (voir le paragraphe 3.1) :
o	Options TDM (0x0B)
o	Nombre de cellules AAL1 TDMoIP par paquet (0x0E)
o	Mode AAL1 TDMoIP (0x10)
o	Options AAL2 TDMoIP (0x11)

 	8.	Considérations sur la sécurité

Le présent document n’a aucun impact supplémentaire sur la sécurité des pseudo filaires au delà de l’établissement de base fondé sur LDP des pseudo filaires spécifié dans la [RFC4447].

 	9.	Remerciements

Sharon Galtzur a relu une des précédentes versions de ce document. Y. (J.) Stein tient à remercier Barak Schlosser des utiles discussions sur le sujet.

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

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

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

[RFC5036]	L. Andersson, I. Minei et B. Thomas, éditeurs, "Spécification de LDP", janvier 2001. (Remplace RFC3036) (MàJ par les RFC6720 , RFC6790, RFC7552,) (D.S)

 	10.2	Références pour information

[Q.2630.1]	Recommandation UIT-T Q.2630.1, "Ensemble de capacités n°  1 de protocole de signalisation AAL type 2", (Union Internationale des Télécommunications, Genève, décembre 1999).

[RFC4805]	O. Nicklass, éd., "Définitions des objets gérés pour les type d'interface DS1, J1, E1, DS2, et E2", mars 2007. (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.)

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

 	Adresse des auteurs
Alexander ("Sasha") Vainshtein	Yaakov (Jonathan) Stein	
ECI Telecom	RAD Data Communications	
30 ha-Sivim St.,	24 Raoul Wallenberg St., Bldg C	
PO Box 500 Petah-Tiqva, 49517 Israel	Tel Aviv  69719 Israel	
mél : Alexander.Vainshtein@ecitele.com	mél : yaakov_s@rad.com	

 	Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2008)

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