Groupe de travail Réseau	A. Malis,Tellabs	
Request for Comments : 4720	D. Allan, Nortel Networks	
Catégorie : Sur la voie de la normalisation	N. Del Regno, MCI	
Traduction Claude Brière de L'Isle	01/11/06	

Rétention de séquence de vérification de trame 
d'émulation bord à bord pseudo filaire (PWE3)

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.

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

Résumé
Le présent document définit un mécanisme pour préserver la séquence de vérification de trame (FCS, Frame Check Sequence) sur les pseudo filaires Ethernet, de relais de trame, de commande de liaison des données de haut niveau (HDLC, High-Level Data Link Control), et de PPP.
Table des matières
1. Vue d'ensemble	1
2. Spécification des exigences	2
3. Signalisation de rétention de FCS avec des pseudo filaires fondés sur MPLS	2
4. Signalisation de rétention de FCS avec des pseudo filaires fondés sur L2TPv3	3
5. Considérations sur la sécurité	3
6. Déclaration d'applicabilité	4
7. Considérations relatives à l'IANA	4
8. Remerciements	4
9. Références normatives	4
Adresse des auteurs	5
Déclaration complète de droits de reproduction	5

 	1.	Vue d'ensemble

Les spécifications pour l'encapsulation de pseudo filaire Ethernet, de relais de trame, de HDLC, et de PPP [RFC4448], [RFC4619], [RFC4618], [RFC4719], [RFC4591] et [RFC4349] incluent un mode d'utilisation par lequel les trames sont livrées de façon transparente à travers le pseudo filaire sans aucun en-tête ni autre altération par l'entrée de pseudo filaire ou la sortie côté fournisseur (PE, Provider Edge). (Noter que ce mode est inhérent pour les pseudo filaires HDLC et PPP.)

Cependant, ces spécifications mentionnent toutes que la séquence de vérification de trame (FCS, Frame Check Sequence) originale va être supprimée à l'entrée et régénérée à la sortie, ce qui signifie que les trames peuvent être soumises à une altération involontaire durant leur traversée du pseudo filaire de l'entrée au PE de sortie. Donc, le pseudo filaire ne peut absolument pas être garanti d'être "transparent" par nature.

Pour être plus précis, les pseudo filaires, comme ils sont courramment définis, laissent la charge utile vulnérable à une modification involontaire se produisant lors du transit dans le réseau encapsulant. Non seulement un appareil à capacité de PW peut corrompre en interne une charge utile encapsulée, mais TOUT LSR ou routeur sur le chemin peut corrompre la charge utile encapsulée. En cas d'une telle corruption, il n'y a pas de moyen de détecter la corruption sur le chemin du pseudo filaire. De plus, parce que la FCS est calculée à la sortie du réseau, toute corruption va passer de façon transparente à travers les commutateurs ALL de couche 2 (Ethernet et relais de trame) par lesquels voyagent les paquets. C'est seulement au point d'extrémité, en supposant que le paquet corrompu atteigne jamais le point d'extrémité correct, que le paquet peut être éliminé, et selon le contenu du paquet, la corruption peut n'être jamais détectée.

Non seulement la technique d'encapsulation laisse la charge utile sans protection, mais elle écrase aussi les mécanismes de vérification d'erreur déjà en place dans les réseaux de fournisseur de service et de consommateur en calculant la FCS sur des donnnées discutables.

Dans un réseau parfait comportant des équipements parfaits, ceci n'est pas un problème. Cependant, comme cela n'existe pas, c'est un problème. Les fournisseurs de service devraient avoir l'option d'économiser des frais généraux en donnant la possibilité de détecter les fautes. De même, les fournisseurs de services devraient avoir l'option de sacrifier les frais généraux du transport de la FCS d'origine de bout en bout pour assurer la capacité de détecter les fautes dans le réseau encapsulant.

Le présent document définit un tel mécanisme pour permettre au PE d'entrée de conserver la FCS de trame originale à l'entrée du réseau, et en libérant le PE de sortie de la tâche de régénérer la FCS.

Ceci est un mécanisme facultatif pour les mises en œuvre de pseudo filaires. Pour l'interopérabilité avec les systèmes qui ne mettent pas en œuvre le présent document, le comportement par défaut est que la FCS est retirée au PE d'entrée et régénérée au PE de sortie, comme spécifé dans les [RFC4448], [RFC4619], et [RFC4618].

Cette capacité peut être utilisé seulement avec les pseudo filaires Ethernet qui utilisent le "mode brut" de la [RFC4448], les pseudo filaires qui utilisent le "mode accès" [RFC4619] [RFC4618], et les pseudo filaires HDLC et PPP [RFC4618].

Noter que ce mécanisme n'est pas destiné à porter des trames erronées à travers le pseudo filaire ; comme d'habitude, la FCS DOIT être examinée au PE d'entrée, et les trames erronées DOIVENT être éliminées. La FCS PEUT aussi être examinée par le PE de sortie ; si c'est fait, les trames erronées DOIVENT être éliminées. Le PE de sortie PEUT aussi souhaiter générer une alarme ou compter le nombre de trames erroné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.	Signalisation de rétention de FCS avec des pseudo filaires fondés sur MPLS

Quand on utilise les procédures de signalisation de la [RFC4447], il y a un type de sous TLV Paramètre d'interface de pseudo filaire qui est utilisé pour signaler le désir de conserver la FCS quand on annonce une étiquette de circuit virtuel [RFC4446] :

Paramètre	Longueur	Description
     0x0A	4	Indicateur de rétention de FCS

La présence de ce paramètre indique que le PE de sortie demande que le PE d'entrée conserve la FCS pour l'étiquette de circuit virtuel qui est annoncée. Elle n'oblige pas le PE d'entrée à conserver la FCS ; il est simplement une indication que le PE d'entrée PEUT conserver la FCS. L'envoyeur NE DOIT PAS conserver la FCS si ce paramètre n'est pas présent dans l'élément FEC de VC.

Le paramètre inclut un champ Longueur de FCS de 16 bits, qui indique la longueur de la FCS originale qui est conservée. Pour les pseudo filaires Ethernet, cette longueur va toujours être réglée à 4. Pour les pseudo filaires HDLC, PPP, et de relais de trame, cette longueur va être réglée à 2 ou 4. Comme la longueur de FCS sur ces interfaces est un réglage local, conserver la FCS n'a de sens que si la longueur de FCS est identique sur les deux extrémités du pseudo filaire. Inclure la longueur de FCS dans ce paramètre permet aux PE de s'asnsurer que la FCS est seulement conservée quand cela a un sens.

Comme les paramètres inconnnus sont ignorés en silence [RFC4447], la rétro compatibilité avec les systèmes qui ne mettent pas en œuvre le présent document est fournie en exigeant que la FCS ne soit conservée QUE si l'indicateur de rétention de FCS avec un réglage identique pour la Longueur de FCS a été inclus dans les annonces pour les deux directions d'un pseudo filaire.

Si le PE d'entrée reconnaît le paramètre Indicateur de rétention de FCS mais ne souhaite pas conserver la FCS avec la longueur indiquée, il doit seulement produire son propre message de transposition d'étiquette pour la direction opposée sans inclure l'indicateur de rétention de FCS. Cela va empêcher la rétention de FCS dans l'une ou l'autre direction.

Si la signalisation PWE3 [RFC4447] n'est pas utilisée pour un pseudo filaire, alors si la FCS est à conserver DOIT être provisionné de façon identique dans les deux PE aux points d'extrémité du pseudo filaire. Si il n'y a pas de prise en charge du provisionnement pour cette option, le comportement par défaut est de supprimer la FCS.

 	4.	Signalisation de rétention de FCS avec des pseudo filaires fondés sur L2TPv3

Cette Section utilise les termes suivants comme défini dans la [RFC3931] :
ICRQ (Incoming-Call-Request) : demande d'appel entrant
ICRP (Incoming-Call-Reply) : réponse d'appel entrant
ICCN (Incoming-Call-Connected) : appel entrant connecté
AVP (Attribute Value Pair) : paire d'attribut/valeur
LCCE (L2TP Control Connection Endpoint) : point d'extrémité de connexion de contrôle L2TP

Quand on utilise les procédures de signalisation de la [RFC3931], l'AVP Rétention de FCS, type d'attribut 92, est utilisé.

Le champ Valeur d'attribut pour cette AVP a le format suivant :

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Longueur de FCS           |
+---------------+---------------+

Longueur de FCS est un entier non signé de deux octets.

La présence de cette AVP dans un message ICRQ ou ICRP indique qu'un LCCE (PE) demande que son homologue conserve la FCS pour la session L2TP établie. Si le LCCE receveur reconnaît l'AVP et se conforme à la demande de rétention de FCS, il DOIT inclure une AVP Rétention de FCS comme accusé de réception dans un message ICRP ou ICCN  correspondant. La rétention de FCS est toujours bidirectionnelle ; donc, la FCS est seulement conservée si les deux LCCE envoient une AVP Rétention de FCS durant l'établissement de session.

La valeur d'attribut est un champ Longueur de FCS de 16 bits, qui indique la longueur d'origine de la FCS à conserver. Pour les pseudo filaires Ethernet, cette longueur va toujours être réglée à 4. Pour les pseudo filaires HDLC, PPP, et de relais de trame, cette longueur va être réglée à 2 ou 4. Comme la longueur de FCS sur ces interfaces est un réglage local, conserver la FCS n'a de sens que si la longueur de FCS est identique sur les deux extrtémités du pseudo filaire. Inclure la longueur de FCS dans cette AVP permet aux PE de s'assurer que la FCS est seulement conservée quand le faire a du sens.

La longeur de cette AVP est 8. Le bit M pour cette AVP DOIT être réglé à 0 (zéro). Cette AVP PEUT être cachée (le bit H PEUT être 1 ou 0).

 	5.	Considérations sur la sécurité

Ce mécanisme améliore l'intégrité des données des pseudo filaires transparents Ethernet, en relais de trame, et HDLC, parce que la FCS originale, telle que générée par le côté consommsateur (CE, Consumer Edge) est incluse dans l'encapsulation. Quand la charge utile encapsulée passe la vérification de FCS au CE de destination, il est clair que la charge utile n'a pas été altérée durant sa transmission à travers le réseau (ou au moins la précision de la FCS originale ; mais c'est évidemment mieux que pas de FCS du tout).

Bien sûr, rien n'est gratuit ; cela exige les frais généraux supplémentaires du transport de la FCS originale (en général, deux ou quatre octets par paquet de charge utile).

Cette signalisation est rétro compatible et interopérable avec les systèmes qui ne mettent pas en œuvre le présent document.

 	6.	Déclaration d'applicabilité

En général, le présent document est destiné à étendre l'applicabilité des services définis par les [RFC4448], [RFC4619], et [RFC4618] pour les rendre plus convenables à l'utilisation dans des déploiements où l'intégrité des données pose problème (ou au moins est autant un problème que dans les services d'origine qui définissaient l'usage de la FCS en premier lieu). Il y a des situations où cette extension n'est pas nécessaire, comme lorsque les charges utiles internes ont leur propre capacité de correction d'erreur (comme TCP). Mais pour les charges utiles internes qui ne s'appuient pas sur les capacités de détection d'erreur de la couche de liaison (comme SNA) cette protection supplémentaire peut être précieuse.

Quand des pseudo filaires sont utilisés pour connecter des ponts 802.1, le présent document permet que les pseudo filaires se conforment à l'exigence que tous les supports qui interconnectent des ponts 802.1 aient (au moins) une protection de FCS de 32 bits.

Noter que le présent document est une des solutions possibles pour qu'un fournisseur de services améliore l'intégrité de bout en bout des données des pseudo filaires. D'autres mécanismes peuvent inclure l'utilisation de bout en bout de IPsec entre les PE, ou des mécanismes internes dans les routeurs IP pour assurer l'intégrité des paquets comme lorsque ils sont commutés entre les interfaces d'entrée et de sortie. Les fournisseurs de services peuvent souhaiter comparer les forces relatives de chaque approche quand il programment leurs déploiements de pseudo filaires ; cependant, un argument peut être avancé qu'il peut être une perte d'énergie pour un fournisseur de service d'utiliser un mécanisme d'intégrité de bout en bout qui est PLUS FORT que la FCS générée par le CE de source et vérifiée par le CE de destination.

 	7.	Considérations relatives à l'IANA

Le présent document ne spécifie aucun nouveau registre à tenir par l'IANA.

Noter que la [RFC4446] alloue le paramètre d'interface Indicateur de rétention de FCS ; donc, aucune autre action de l'IANA n'est demandée.

L'IANA a alloué une valeur dans la section "Paires de valeur/attribut de message de contrôle" de L2TP conformément à la [RFC3438]. La nouvelle AVP est 92 et est référencée dans le registre IANA des paramètres L2TP comme "Rétention de FCS".

 	8.	Remerciements

Les auteurs tiennent à remercier Mark Townsley pour le texte de la Section 4.

 	9.	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)

[RFC3438]	W. Townsley, "Mise à jour des considérations de l'IANA sur le protocole de tunnelage de couche deux (L2TP)", décembre 2002. (BCP0068)  

[RFC3931]	J. Lau et autres, "Protocole de tunnelage de couche deux - version 3 (L2TPv3)", mars 2005. (P.S.)

[RFC4349]	C. Pignataro, M. Townsley, "Trames de contrôle de liaison de données à haut niveau (HDLC) sur la version 3 du protocole de tunnelage de couche 2 (L2TPv3)", février 2006. (P.S.)

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

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

[RFC4591]	M. Townsley et autres, "Relais de trame sur la version 3 du protocole de tunnelage de couche 2 (L2TPv3)", août 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.)

[RFC4719]	R. Aggarwal et autres, "Transport de trames Ethernet sur la version 2 du protocole de tunnelage de couche 2 (L2TPv3)", novembre 2006. (P.S. ; MàJ par 5641)

 	Adresse des auteurs

Andrew G. Malis	David Allan	Nick Del Regno	
Tellabs	Nortel Networks	MCI	
90 Rio Robles Dr.	3500 Carling Ave.	400 International Parkway	
San Jose, CA 95134	Ottawa, Ontario, CANADA	Richardson, TX 75081	
mél : Andy.Malis@tellabs.com 	mél : dallan@nortel.com 	mél : nick.delregno@mci.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 sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations 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, 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.