Groupe de travail Réseau	A. Malis, Verizon
Request for Comments : 4816	L. Martini, Cisco Systems
Catégorie : Sur la voie de la normalisation	J. Brayley, ECI Telecom
	T. Walsh, Juniper Networks
Traduction Claude Brière de L'Isle	février 2007

Service de transport de cellules transparent en mode de transfert asynchrone (ATM) d'émulation de bord à bord pseudo filaire (PWE3)

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é
Le document décrit un service de transport de cellules transparent qui utilise le mode de relais de cellule "N à une" pour l'encapsulation de cellule en mode de transfert asynchrone (ATM, Asynchronous Transfer-Mode) d'émulation de bord à bord pseudo filaire (PWE3, Pseudowire Emulation Edge-to-Edge).
Table des matières
1. Introduction	1
1.1 Spécification des exigences	1
2. Définition du transport de cellules transparent	1
3. Considérations sur la sécurité	2
4. Contrôle d'encombrement	2
5. Références normatives	2
Remerciements	3
Adresse des auteurs	3
Déclaration complète de droits de reproduction	4

 	1.	Introduction

Ce service de transport de cellules transparent permet la migration des services ATM sur un réseau à commutation de paquets (PSN, Packet-Switched Network) sans avoir à provisionner les appareils d'abonné ATM ou de côté consommateur (CE, customer edge). Les CE ATM vont voir le service de transport de cellules transparent ATM comme si ils étaient directement connectés via une ligne louée en multiplexage à division dans le temps (TDM, Time Division Multiplexer). Ce service sera très probablement utilisé comme fonction interne dans le réseau d'un fournisseur de service ATM comme moyen de connecter les commutateurs ATM existants via un PSN à plus grande vitesse, ou de fournir des services ATM "de transport arrière" pour l'accès distant aux réseaux ATM existants.

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

 	2.	Définition du transport de cellules transparent

Le service d'accès transparent est une application naturelle du mode de transport de cellule de "N à une" de connexion de circuit virtuel (VCC, Virtual Circuit Connection) pour l'encapsulation ATM PWE3 décrite dans la [RFC4717], et DOIT être utilisé avec les pseudo filaires de type 0x0003, "transport transparent de cellule ATM" [RFC4446].

Le service d'accès ATM transparent émule la connexité entre deux accès ATM distants. Ce service est utile quand on désire connecter deux CE sans traitement ou commutation à la couche de connexion de chemin virtuel (PVC, Virtual Path Connection) ou VCC. Le PE d'entrée élimine toutes les cellules inactives/non allouées reçues de l'accès ATM d'entrée, et transpose toutes les autres cellules reçues en un seul pseudo filaire.

Le PE de sortie ne change pas les bits d'identifiant de chemin virtuel (VPI, Virtual Path Identifier), d'identifiant de circuit virtuel (VCI, Virtual Circuit Identifier), d'identifiant de type de charge utile (PTI, Payload Type Identifier) ou de priorité de perte de cellule (CLP, Cell Loss Priority ) quand il envoie ces cellules sur l'accès ATM de sortie. Donc, le service d'accès transparent apparaît comme émulant une connexion de couche de convergence de transmission ATM entre deux accès. Cependant, comme le PE d'entrée élimine les cellules inactives/non allouées, ce service bénéficie d'économies de bande passante de multiplexage statistique.

En accord avec la [RFC4717], l'enchaînement de cellules PEUT être utilisé pour le transporr transparent de cellules relais afin d'économiser la bande passante du PSN. Si il est utilisé, il DOIT faire l'objet d'un accord entre les PE d'entrée et de sortie. En particulier, si le pseudo filaire a été établi en utilisant le protocole de contrôle PWE3 [RFC4447], le PE d'entrée NE DOIT PAS excéder la valeur du sous TLV Paramètre d'interface de pseudo filaire "Nombre maximum de cellules ATM enchaînées" (identifiant de paramètre d'interface = 0x02 [RFC4446]) reçu dans le message de transposition d'étiquette pour le pseudo filaire, et NE DOIT PAS utiliser l'enchaînement de cellules si ce paramètre a été omis par le PE de sortie.

Les cellules ATM d'opérations et gestion (OAM, Operations and Management) DOIVENT être transportées de façon transparente, et les PE n'agissent pas sur elles. Si les PE détectent une défaillance du PSN ou du pseudo filaire entre eux, ils ne génèrent pas de cellules OAM, mais plutôt arrêtent les interfaces ATM aux CE (par exemple, en générant un LOS sur l'accès ATM) tout comme si il y avait une défaillance de la couche de transmission.

De même, la signalisation ATM d'interface de gestion locale intégrée (ILMI, Integrated Local Management Interface) provenant des CE, si il en est, DOIT être transportée de façon transparente, et les PE n'agissent pas sur elle. Cependant, les PE doivent agir sur une défaillance d'interface physique en retirant les étiquettes de PW ou en utilisant la signalisation d'état de pseudo filaire pour indiquer la défaillance d'interface. Les procédures pour les deux solutions sont décrites dans la [RFC4447].

 	3.	Considérations sur la sécurité

Ce document n'introduit aucune nouvelle considération de sécurité au delà de celles des [RFC4717] et [RFC4447]. Le présent document définit une application qui utilise l'encapsulation spécifiée dans la [RFC4717], et ne spécifie pas les protocoles utilisés pour porter les paquets encapsulés à travers le PSN. 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 l'application qu'on spécifie ici. Noter que la sécurité du service ATM transporté sera seulement aussi bonne que la sécurité du PSN. Ce niveau de sécurité pourrait être moins rigoreux que celui d'un service ATM natif.

 	4.	Contrôle d'encombrement

Comme ce document discute une application du mode de transport de cellules VCC "de N en une" pour l'encapsulation ATM PWE3 décrite dans la [RFC4717], les considérations de contrôle d'encombrement sont identiques à celles discutées à la Section 15 de la [RFC4717]. Le groupe de travail PWE3 a entrepris des travaux supplémentaires sur les questions d'encombrement relatives à ATM, et les développeurs devraient prévoir qu'une RFC sera publiée pour décrire des techniques de contrôle d'encombrement supplémentaires qui devraient être appliquées à l'émulation ATM sur pseudo filaires.

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

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

 	Remerciements

Les auteurs tiennent à remercier les membres du groupe de travail PWE3 pour leur assistance à la rédaction de ce document, et Sasha Vainshtein de Axerra en particulier pour ses commentaires et suggestions.

 	Adresse des auteurs

Andrew G. Malis	Luca Martini	
Verizon Communications	Cisco Systems, Inc.	
40 Sylvan Road	9155 East Nichols Avenue, Suite 400	
Waltham, MA	Englewood, CO, 80112	
mél : andrew.g.malis@verizon.com 	mél : lmartini@cisco.com 	

Jeremy Brayley	Tom Walsh	
ECI Telecom	Juniper Networks	
Omega Corporate Center	1194 N Mathilda Ave	
1300 Omega Drive	Sunnyvale, CA 94089	
Pittsburgh, PA 15205	USA	
USA	mél : twalsh@juniper.net 	
mél : jeremy.brayley@ecitele.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 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 fourni par l'Internet Society.