Groupe de travail Réseau	S. Singh, Cisco Systems	
Request for Comments : 4454	M. Townsley, Cisco Systems	
Catégorie : Sur la voie de la normalisation	C. Pignataro, Cisco Systems	
Traduction Claude Brière de L'Isle	mai 2006	

Mode de transfert asynchrone (ATM) sur le protocole de tunnelage de couche 2, version 3 (L2TPv3)

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 Internet Society (2006).

Résumé
Le protocole de tunnelage de couche 2, version 3  (L2TPv3, Layer 2 Tunneling Protocol, Version 3) définit un protocole de tunnelage extensible pour transporter les services de couche 2 sur les réseaux IP. Le présent document décrit les spécificités de l'utilisation du plan de contrôle L2TP pour les pseudo filaires en mode de transfert asynchrone (ATM, Asynchronous Transfer Mode ) et fournit des lignes directrices pour le transport de divers services ATM sur un réseau IP.
Table des matières
1. Introduction	2
1.1 Abréviations	2
1.2 Spécification des exigences	2
2. Établissement de connexion de contrôle	2
3. Établissement de session et notification d'état de circuit ATM	3
3.1 Établissement de session L2TPv3	3
3.2 Suppression de session L2TPv3	4
3.3 Maintenance de session L2TPv3	4
4. Encapsulation	4
4.1 Sous couche spécifique d'ATM	5
4.2 Séquençage	6
5. Transport ATM	6
5.1 Mode ATM AAL5-SDU	6
5.2 Mode cellule ATM	6
5.3 Prise en charge de cellule OAM	8
6. AVP Maximum de cellules ATM enchaînées	8
7. AVP Émulation OAM requise	9
8. Transposition de défaut ATM et notification d'état	9
8.1 AVP État d'alarme ATM	9
9. Déclaration d'applicabilité	10
9.1 Mode ATM AAL5-SDU	10
9.2 Mode de relais de cellule ATM	11
10. Contrôle d'encombrement	12
11. Considérations sur la sécurité	13
12. Considérations relatives à l'IANA	13
12.1 Type de sous couche spécifique de couche 2	13
12.2 Paires attribut/valeur de message de contrôle	13
12.3 Valeurs d'AVP de code de résultat	13
12.4 Valeurs d'AVP d'état d'alarme ATM	14
12.5 Bits de sous couche spécifique ATM	14
13. Remerciements	14
14. Références	15
14.1 Références normatives	15
14.2 Références pour information	15
Adresse des auteurs	15
Déclaration complète de droits de reproduction	15

 	1.	Introduction

Le présent document décrit les spécificités de l'utilisation du protocole de tunnelage de couche 2 (L2TP) pour les pseudo filaires en mode de transfert asynchrone (ATM) incluant l'encapsulation, le portage de divers services ATM, tels que AAL5 SDU, le relais de cellule ATM VCC/VPC/accès sur L2TP, et la transposition de défauts ATM en messages d'information de réglage de liaison (SLI, Set-Link-Info) L2TP pour les notifier au point d'extrémité de connexion de contrôle (LCCE Control Connection Endpoint) de l'homologue L2TP.

Toutes les AVP spécifiques d'ATM ou autres constructions L2TP pour la prise en charge des pseudo filaires ATM (ATMPW, pseudo filaire ATM) sont aussi définies ici. La prise en charge des chemins/connexions virtuels commutés (SVP/SVC, Switched Virtual Path/Connection) et chemins/connexions virtuels permanents mous (SPVP/SPVC, Soft Permanent Virtual Path/Connection) ATM sortent du domaine d'application de ce document.

Le lecteur est supposé être familiarisé avec la terminologie et les constructions de protocole définies dans la [RFC3931].

 	1.1	Abréviations
AIS (Alarm Indication Signal)  : signal d'indication d'alarme
ATMPW (ATM PseudoWire)  : pseudo filaire ATM
AVP (Attribute Value Pair)  : paire attribut/valeur
CC (Continuity Check OAM Cell)  : vérification de continuité de cellule OAM
CE (Customer Edge)  : côté consommateur
HEC (Header Error Checksum)  : somme de contrôle d'erreur d'en-tête
LAC (L2TP Access Concentrator)  : concentrateur d'accès L2TP (voir la [RFC3931])
LCCE (L2TP Control Connection Endpoint)  : point d'extrémité de connexion de contrôle L2TP (voir la [RFC3931])
MSB (Most Significant Byte)  : octet de poids fort
OAM (Operation, Administration, et Maintenance)  :opération, administration et maintenance
PE (Provider Edge)  : côté fournisseur
PSN (Packet Switched Network)  : réseau à commutation de paquets
PWE3 (Pseudowire Emulation Edge to Edge)  : émulation de pseudo filaire de bord à bord
RDI (Remote Defect Indicator)  : indicateur de défaut distant
SAR (Segmentation et Reassembly)  : segmentation et réassemblage
SDU (Service Data Unit)  : unité de données de service
SLI (Set-Link-Info)  : informations de réglage de liaison (un message de contrôle L2TP)
SPVC (Soft Permanent Virtual Connection)  : connexion virtuelle permanente molle
SPVP (Soft Permanent Virtual Path)  : chemin virtuel permanent mou
SVC (Switched Virtual Connection)  : connexion virtuelle commutée
SVP (Switched Virtual Path)  : chemin virtuel commuté
VC (Virtual Circuit) : circuit virtuel
VCC (Virtual Channel Connection)  : connexion de canal virtuel
VCI (Virtual Channel Identifier)  : identifiant de canal virtuel
VPC (Virtual Path Connection)  : connexion de chemin virtuel
VPI (Virtual Path Identifier)  : identifiant de chemin virtuel

 	1.2	Spécification des exigences
Dans le présent document, plusieurs mots sont utilisés pour signifier les exigences de la spécification. Ces mots sont souvent en majuscules. 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.	Établissement de connexion de contrôle

Pour émuler des pseudo filaires ATM en utilisant L2TP, une connexion de contrôle L2TP comme décrit au paragraphe 3.3 de la [RFC3931] DOIT être établie.

La demande de commencer la connexion de contrôle (SCCRQ, Start-Control-Connection-Request) et la réponse de commencer la connexion de contrôle (SCCRP, Start-Control-Connection-Reply) correspondante DOIT inclure les types de pseudo filaire ATM pris en charge (voir au paragraphe 3.1) dans la liste des capacités de pseudo filaires définie au paragraphe 5.4.3 de la [RFC3931]. Cela identifie la connexion de contrôle comme capable d'établir des sessions L2TP en support des pseudo filaires ATM.

Un LCCE DOIT être capable de s'identifier de façon univoque dans les messages SCCRQ et SCCRP via une valeur unique au monde. Par défaut, ceci est annoncé via l'AVP structurée Identifiant de routeur [RFC3931], bien que l'AVP non structurée Nom d'hôte [RFC3931] PUISSE aussi être utilisée pour identifier les LCCE.

 	3.	Établissement de session et notification d'état de circuit ATM

Cette Section décrit comment les ATMPW ou sessions L2TP sont établis entre deux LCCE. Cela inclut ce qui va se passer quand un circuit ATM (par exemple, PVC AAL5) est créé, supprimé, ou change d'état quand l'état de circuit est en alarme.

 	3.1	Établissement de session L2TPv3
La création de circuit ATM (par exemple, un PVC AAL5) déclenche l'établissement d'une session L2TP en utilisant une prise de contact en trois étapes décrite au paragraphe 3.4.1 de la [RFC3931]. Un LCCE PEUT initier la session immédiatement à la création du circuit ATM, ou attendre jusqu'à ce que l'état de circuit passe à ACTIF avant de tenter d'établir une session pour le circuit ATM. On PEUT préférer attendre que l'état du circuit transite à ACTIF afin de retarder l'allocation de ressources jusqu'à ce qu'elle soit absolument nécessaire.

L'AVP État de circuit (voir la Section 8) DOIT être présente dans les messages Demande d'appel entrant (ICRQ, Incoming-Call-Request) et Réponse d'appel entrant (ICRP, Incoming-Call-Reply) et PEUT être présente dans le message SLI pour les ATMPW.

La figure suivante montre comment les messages L2TP sont échangés pour établie un ATMPW après que le circuit ATM (par exemple, un PVC AAL5) devient ACTIF.

          LCCE (LAC) A                                  LCCE (LAC) B
Circuit ATM provisionné
                                                          Circuit ATM provisionné
      Circuit ATM ACTIF
                ICRQ (état = 0x03) ---->
	Circuit ATM ACTIF
                                            <----- ICRP (état = 0x03)
 Session L2TP établie, OK pour envoyer des données dans le PW
                       ICCN ----->
	Session L2TP établie, OK pour envoyer des données dans le PW

Les éléments de signalisation suivants sont exigés pour l'établissement de ATMPW.

a.	Type de pseudo-filaire : une des types de PW relatifs à ATM devrait être présent dans l'AVP Type de pseudo-filaire de la [RFC3931].
0x0002  : transport de VCC SDU AAL5 ATM
0x0003  : mode d'accès de transport de cellule ATM
0x0009  : mode VCC de transport de cellule ATM
0x000A : mode VPC de transport de cellule ATM

Les modes de relais de cellule ci-dessus peuvent aussi signaler l'AVP Maximum de cellules enchaînées ATM comme décrit à la Section 6.

b.	Identifiant d'extrémité distante : chaque PW est associé à un identifiant d'extrémité distante aussi appelé VC-ID dans la [RFC4619]. Deux LCCE d'un PW vont avoir le même identifiant d'extrémité distante, et son format est décrit au paragraphe 5.4.4 de la [RFC3931].

Cette AVP Identifiant d'extrémité distante DOIT être présente dans la ICRQ afin que le LCCE distant associe la session au circuit ATM. L'AVP Identifiant d'extrémité distante définie dans la [RFC3931] est de forme opaque, bien que les mises en œuvre de ATMPW PUISSENT simplement utiliser une valeur de 4 octets qui est connue des deux LCCE (soit par configuration directe, soit par d'autres moyens). La méthode exacte par laquelle cette valeur est configurée, restituée, découverte, ou autrement déterminée à chaque LCCE sort du domaine d'application du présent document.

Comme avec l'ICRQ, l'ICRP n'est envoyée qu'après que le circuit ATM transite à ACTIF. Si le LCCE B n'a pas encore été provisionné pour le circuit ATM identifié dans l'ICRQ, une Notification de déconnexion d'appel (CDN, Call-Disconnect-Notify) aurait été immédiatement retournée pour indiquer que le circuit n'a pas été provisionné ou n'est pas disponible à ce LCCE. Le LCCE A DEVRAIT alors posséder un mécanisme de répétition périodique. Si il en est ainsi, la période et le nombre maximum d'essais DOIVENT être configurables.

Une mise en œuvre PEUT envoyer une ICRQ ou ICRP avant qu'un PVC soit ACTIF, pour autant que l'AVP État de circuit  reflète que le circuit ATM est INACTIF et qu'une SLI soit envoyée quand le circuit ATM devient ACTIF (voir la Section  8).

La ICCN est l'étape finale de l'établissement de session. Elle confirme la réception de la ICRP avec des paramètres acceptables pour permettre du trafic bidirectionnel.

 	3.2	Suppression de session L2TPv3
Quand un circuit ATM est déprovisionné (supprimé) à l'un ou l'autre LCCE, la session L2TP associée DOIT être supprimée via le message CDN défini au paragraphe 3.4.3 de la [RFC3931].

 	3.3	Maintenance de session L2TPv3
Toutes les sessions établies par une certaine connexion de contrôle utilisent la facilité de Hello L2TP définie au paragraphe  4.4 de la [RFC3931] pour garder la session en vie. Cela donne à toutes les sessions la détection de base d'homologue et de chemin mort entre les LCCE.

Si le canal de contrôle qui utilise le message Hello n'est pas dans la bande avec le trafic de données sur le PSN, d'autres méthodes PEUVENT alors être utilisées pour détecter la défaillance de la session, et cela fera l'objet d'études futures.

Les ATMPW sur L2TP utilisent le message de contrôle Informations de réglage de liaison (SLI, Set-Link-Info) comme défini dans la [RFC3931] pour signaler l'état du circuit ATM entre les LCCE après l'établissement initial de session. Cela inclut des notifications ACTIF ou INACTIF du circuit ATM, ou de tous les autres paramètres qui peuvent devoir être partagés entre les LCCE afin de fournir une émulation de PW appropriée.

Le message SLI DOIT être envoyé chaque fois qu'un changement d'état peut être rapporté par des valeurs identifiées dans l'AVP État de circuit.

Les seules exceptions à cela sont les messages ICRQ, ICRP, et CDN initiaux, qui établissent et suppriment la session L2TP elle-même quand le circuit ATM est créé ou supprimé. Le message SLI peut être envoyé de l'un ou l'autre LCCE à tout moment après que la première ICRQ est envoyée (et peut-être avant qu'une ICRP soit reçue, exigeant que l'homologue effectue une recherche inverse d'identifiant de session).

L'autre application du message SLI est de transposer les alarmes de couche OAM ou physique ATM en AVP État de circuit comme décrit à la Section 8.

 	4.	Encapsulation

Cette Section décrite le format général d'encapsulation pour les services ATM sur L2TP.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                En-tête de transport PSN                       |
+---------------+---------------+---------------+---------------+
|                   En-tête de session                          |
+---------------+---------------+---------------+---------------+
|                Sous couche spécifique ATM                     |
+---------------+---------------+---------------+---------------+
|                                                               |
|                Charge utile de service ATM                    |
|                                                               |
+---------------+---------------+---------------+---------------+

Figure 1 : Format général pour encapsulation ATM sur L2TPv3 sur IP

L'en-tête de transport PSN est spécifique de IP et son en-tête de transport sous-jacent. Cet en-tête est utilisé pour transporter la charge utile ATM encapsulée à travers le réseau IP.

L'en-tête de session est un identifiant de session non zéro de 32 bits avec un mouchard facultatif de jusqu'à 64 bits. Cet identifiant de session est échangé durant l'établissement de session.

La sous couche spécifique ATM est EXIGÉE pour le mode SDU AAL5 et FACULTATIVE pour le mode cellule ATM. Voir les détails au paragraphe 4.1.

 	4.1	Sous couche spécifique d'ATM
Ce paragraphe définit une nouvelle sous couche spécifique ATM, une solution de remplacement à la sous couche de couche  2 par défaut mentionnée au paragraphe 4.6 de la [RFC3931]. Quatre nouveaux bits fanions (T, G, C, et U) sont définis qui sont en concurrence avec ceux du paragraphe 7.2 de la [RFC4619].

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|B|E|T|G|C|U|          Numéro de séquence                   |
+-+-+-+-+-+-+-+-+---------------+---------------+---------------+

Figure 2 : Format de la sous couche spécifique ATM

La signification des champs de la sous couche spécifique ATM est comme suit :

* Bit S : La définition de ce bit est conforme au paragraphe 4.6 de la [RFC3931].

*	Bits B et E : La définition de ces bits est conforme au paragraphe 5.5 de la [RFC4623]. Si ces bits ne sont pas utilisés conformément à la [RFC4623], ils DOIVENT être réglés à 0 à l'émission et ignorés à réception.

*	Bit T (Type de transport ) : le bit (T) de la sous couche spécifique ATM indique si le paquet contient une cellule administrative ATM ou une charge utile AAL5. Si T = 1, le paquet contient une cellule administrative ATM, encapsulée selon l'encapsulation de relais de cellule VCC du paragraphe 5.2. Si il est à zéro, la PDU contient une charge utile AAL5. La capacité de transport d'une cellule ATM dans le mode SDU AAL5 est destiné à donner un moyen d'activer une fonction administrative sur le VCC AAL5 (bien qu'il n’entreprenne pas de préserver l'ordre d'arrivée/transport de cellule d'utilisateur et de cellule administrative, comme décrit au paragraphe 9.1).

*	Bit G (EFCI) : L'appareil LCCE d'entrée DEVRAIT régler ce bit à 1 si le bit Indication explicite d'encombrement vers l'avant (EFCI, Explicit Forward Congestion Indication) de la cellule finale de la charge utile AAL5 entrante est réglé à 1, ou si le bit EFCI de la seule cellule ATM à être transportée dans le paquet est réglé à 1. Autrement, ce bit DEVRAIT être réglé à 0. L'appareil LCCE de sortie DEVRAIT établir le bit EFCI de toutes les cellules sortantes qui transportent la charge utile AAL5 à la valeur contenue dans ce champ.

*	Bit C (CLP) : L'appareil LCCE d'entrée DEVRAIT régler ce bit à 1 si le bit Priorité de perte de cellule (CLP, Cell Loss Priority) d'une des cellules ATM entrantes de la charge utile AAL5 est réglé à 1, ou si le bit CLP de la seule cellule ATM transportée dans le paquet est réglé à 1. Autrement ce bit DEVRAIT être réglé à 0. L'appareil LCCE de sortie DEVRAIT établir le bit CLP de toutes les cellules sortantes qui transportent la CPCS-PDU AAL5 à la valeur contenue dans ce champ.

*	Bit U (Commande/réponse) : Quand du trafic FRF.8.1 de relais de trame / interfonctionnement de service ATM sur PVC (voir [FRF8.1]) est transporté, le bit de moindre poids CPCS-UU de la CPCS-PDU AAL5 peut contenir le bit C/R de relais de trame. L'appareil LCCE d'entrée DEVRAIT copier ce bit au bit U de la sous couche spécifique ATM. L'appareil LCCE de sortie DEVRAIT copier le bit U au bit de moindre poids de la CPCS-UU de la charge utile AAL5.

Le champ Numéro de séquence est utilisé pour le séquençage, comme décrit au paragraphe 4.2.

En cas de fin de temporisation de réassemblage, le LCCE encapsulant devrait éliminer toutes les cellules composantes de la trame AAL5.

Une énumération supplémentaire est ajoutée à l'AVP Sous couche spécifique de couche 2 pour identifier la sous couche spécifique ATM :
0 – Il n'y a pas de sous couche spécifique de couche 2 présente.
1 – La sous couche spécifique de couche 2 par défaut (définie au paragraphe 4.6 de la [RFC3931]) est utilisée.
2 - La sous couche spécifique ATM est utilisée.

Les deux premières valeurs sont déjà définie dans la spécification L2TPv3 de base [RFC3931].

 	4.2	Séquençage
Le séquençage de paquet de données PEUT être activé pour les ATMPW. Les mécanismes de séquençage décrits dans la [RFC3931] DOIVENT être utilisés pour signaler la prise en charge du séquençage. Les ATMPW sur L2TPv3 DOIVENT demander la présence de la sous couche spécifique ATM quand le séquençage est activé, et PEUVENT demander sa présence à tout moment.

 	5.	Transport ATM

Deux encapsulations décrites ci-dessous sont prises en charge pour le transport ATM.

La sous couche spécifique ATM est ajoutée devant la SDU AAL5. L'autre encapsulation de mode cellule consiste en la sous couche spécifique ATM FACULTATIVE, suivie par un en-tête de cellule ATM de 4 octets et une charge utile de cellule ATM de 48 octets.

 	5.1	Mode ATM AAL5-SDU
Dans ce mode, chaque VC AAL5 est transposé en session L2TP. Le LCCE d'entrée ré-assemble la CPCS-SDU AAL5 sans l'en-queue AAL5 ni aucun octet de bourrage. Les EFCI, CLP, et C/R (si présents) entrants sont portés dans une sous couche spécifique ATM à travers les ATMPW au LCCE de sortie. Le traitement de ces bits aux LCCE d'entrée et de sortie est défini au paragraphe 4.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x|T|G|C|U|             Numéro de séquence                |
+-+-+-+-+-+-+-+-+---------------+---------------+---------------+
|                                                               |
|                                                               |
|                         CPCS-SDU AAL5                         |
|                                                               |
+---------------+---------------+---------------+---------------+

Figure 3 : Encapsulation de mode ATM AAL5-SDU

Si le LCCE d'entrée détermine qu'une SDU encapsulée AAL5 excède la taille de MTU de la session L2TPv3, la SDU AAL5 peut alors être fragmentée conformément à la [RFC4623] ou en dessous de la couche transport (IP, etc.). Les cellules F5 OAM qui arrivent durant le réassemblage d'une SDU AAL5 sont envoyées immédiatement sur le PW suivies par la charge utile de SDU AAL5. Dans ce cas, l'ordre relatif des cellules OAM par rapport aux cellules de données d'utilisateur n'est pas conservé.

Les cellules de surveillance de performances d'OAM, comme spécifié dans les Recommandations UIT-T [I610-1], [I610-2], [I610-3] et les cellules de sécurité OAM comme spécifié dans [ATMSEC], ne devraient pas être utilisées en combinaison avec le mode SDU AAL5. Ces cellules PEUVENT être éliminées au LCCE d'entrée parce que l'intégrité de la séquence de cellules n'est pas maintenue.

L'AVP Type de pseudo-filaire défini au paragraphe 5.4.4 de la [RFC3931], type d'attribut 68, DOIT être présente dans les messages ICRQ et DOIT inclure le type de PW de transport de VCC de SDU AAL5 ATM de 0x0002.

 	5.2	Mode cellule ATM
Dans ce mode, les cellules ATM sautent le processus de réassemblage au LCCE d'entrée. Ces cellules sont transportées sur une session L2TP, soit comme une seule cellule, soit comme cellules enchaînées, dans un seul paquet. Chaque cellule ATM consiste en un en-tête de cellule ATM de 4 octets et une charge utile de cellule ATM de 48 octets ; le HEC n'est pas inclus.

Dans l'encapsulation en mode cellule ATM, la sous couche spécifique ATM est FACULTATIVE. Elle peut être incluse, si la prise en charge du séquençage est requise. Il appartient à la mise en œuvre de choisir de signaler la sous couche spécifique de couche 2 par défaut ou la sous couche spécifique ATM.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x|x|x|x|x|       Numéro de séquence (facultatif)         |
+-+-+-+-+-+-+-+-+-------+-------+---------------+-------+-----+-+
|        VPI            |           VCI                 |PTI  |C|
+---------------+-------+-------+---------------+-------+-----+-+
|                                                               |
|            Charge utile de cellule ATM (48 octets)            |
|                                                               |
+---------------+---------------+---------------+---------------+
                            "
                            "
+---------------+-------+-------+---------------+-------+-----+-+
|        VPI            |           VCI                 |PTI  |C|
+---------------+-------+-------+---------------+-------+-----+-+
|                                                               |
|            Charge utile de cellule ATM (48 octets)            |
|                                                               |
+---------------+---------------+---------------+---------------+

Figure 4 : Encapsulation en mode cellule ATM

Dans le cas le plus simple, cette encapsulation peut être utilisée pour transmettre une seule cellule ATM par PDU de pseudo filaire. Cependant, afin de fournir une meilleure efficacité de bande passante de pseudo filaire, plusieurs cellules ATM peut être facultativement encapsulées dans une seule PDU de pseudo filaire.

Le nombre maximum de cellules enchaînées dans un paquet est limité par la taille de MTU de la session et aussi par la capacité du LCCE de sortie de les traiter. Voir à la Section 6 plus de détails sur le maximum de cellules ATM enchaînées.

 	5.2.1	Service de relais de cellule VCC ATM
Un service de VCC de relais de cellules peut être fourni en transposant une connexion de canal virtuel ATM en un seul pseudo filaire en utilisant l'encapsulation de mode cellule défini au paragraphe 5.2.

Un LCCE peut transposer un ou plusieurs VCC en un seul PW. Cependant, un fournisseur de services peut souhaiter provisionner un seul VCC sur un PW afin de satisfaire des exigences de QS ou de restauration.

L'AVP Type de pseudo-filaire défini au paragraphe 5.4.4 de la [RFC3931], type d'attribut 68, DOIT être présente dans les messages ICRQ et DOIT inclure le type de PW en mode VCC de transport de cellule ATM de 0x0009.

 	5.2.2	Service de relais de cellule VPC ATM
Un service de relais de cellule de connexion de chemin virtuel peut être fourni en transposant une connexion de chemin virtuel ATM en un seul pseudo filaire en utilisant l'encapsulation de mode cellule défini au paragraphe 5.2.

Un LCCE peut transposer un ou plusieurs VPC en un seul pseudo-filaire.

L'AVP Type de pseudo-filaire défini au paragraphe 5.4.4 de la [RFC3931], type d'attribut 68, DOIT être présente dans les messages ICRQ et DOIT inclure le type de PW en mode VPC de transport de cellule ATM de 0x000A.

 	5.2.3	Service de relais de cellule d'accès ATM
Le service de relais de cellule d'accès ATM permet à un accès ATM d'être connecté à un autre accès ATM. Toutes les cellules ATM qui sont reçues à l'accès d'entrée ATM sur le LCCE sont encapsulées conformément au paragraphe 5.2, dans la PDU pseudo filaire et envoyées au LCCE homologue.

Chaque LCCE DOIT éliminer toutes les cellules inactives/non allouées reçues sur un accès ATM associé à des ATMPW.

L'AVP Type de pseudo-filaire AVP défini au paragraphe 5.4.4 de la [RFC3931], type d'attribut 68, DOIT être présente dans les messages ICRQ et DOIT inclure le type de PW en mode accès de transport de cellule ATM de 0x0003.

 	5.3	Prise en charge de cellule OAM
Les cellules OAM sont définies dans [I.610-1], [I.610-2], [I.610-3] et [ATMSEC] peuvent être catégorisées comme suit :
a. Gestion de fautes
b. Surveillance et rapport de performances
c. Activation/désactivation
d. Gestion de système (par exemple, cellules OAM de sécurité)

Les cellules OAM sont toujours encapsulées en utilisant l’encapsulation de mode cellule, sans considération du format d'encapsulation utilisé pour les données d'utilisateur.

 	5.3.1	Commutation de VCC
Les LCCE DEVRAIENT être capables de passer le segment F5 et les cellules OAM de gestion de faute de bout en bout, de gestion de ressources (cellules RM), de gestion des performances, d'activation/désactivation, et gestion de système.

Les cellules OAM F4 sont insérées ou extraites à la terminaison de liaison VC. Ces cellules OAM ne sont pas vues à la terminaison de liaison VC et ne sont donc pas envoyées à travers le PW.

 	5.3.2	Commutation de VPC
Les LCCE DOIVENT être capables de passer les cellules OAM de segment F4 et de gestion de faute de bout en bout, de gestion de ressource (cellules RM), de gestion de performances, d'activation/désactivation, et de gestion de système de façon transparente conformément à [I.610-1].

Les cellules OAM F5 ne sont pas insérées ou extraites à l'interconnexion de VP. Les LCCE DOIVENT être capables de passer de façon transparente les cellules OAM F5 OAM à travers le PW.

 	6.	AVP Maximum de cellules ATM enchaînées

L'AVP Maximum de cellules ATM enchaînées, type d'attribut 86, indique que le nœud LCCE de sortie peut traiter une seule PDU avec des cellules enchaînées jusqu'à un nombre de cellules spécifié. Un nœud LCCE qui transmet des cellules enchaînées sur ce PW NE DOIT PAS excéder le nombre maximum de cellules spécifié dans cette AVP. Cette AVP n'est applicable qu'aux types de PW de relais de cellule ATM (VCC, VPC, relais de cellule d'accès). Cette valeur d'attribut peut n'être pas la même dans les deux directions du PW spécifique.

Le champ Attribut/Valeur 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Maximum cellules ATM enchaînées|
+---------------+---------------+

Cette AVP PEUT être cachée (le bit H PEUT être 0 ou 1). Le bit M pour cette AVP PEUT être réglé à 0, mais PEUT varier (voir au paragraphe 5.2 de la [RFC3931]). La longueur (avant de cacher) de cette AVP est 8.

Cette AVP est envoyée dans une ICRQ, ICRP durant la négociation de session ou via des messages de contrôle SLI quand le LCCE change la configuration du nombre maximum de cellules enchaînées pour un certain circuit de relais de cellule ATM.

Cette AVP est FACULTATIVE. Si le LCCE de sortie est configuré avec un nombre maximum de cellules à enchaîner par le LCCE d'entrée, il DEVRAIT signaler cette valeur au LCCE d'entrée.

 	7.	AVP Émulation OAM requise

Dans l'AVP "Émulation OAM requise", type d'attribut 87, il PEUT être nécessaire de signaler l'émulation OAM dans le mode SDU AAL5, si un LCCE ne peut pas prendre en charge le transport de cellules OAM à travers les sessions L2TP. Si l'émulation de cellule OAM est configurée ou détectée via d'autres moyens sur un côté, l'autre LCCE DOIT aussi prendre en charge l'émulation de cellules OAM.

Cette AVP est échangée durant la négociation de session (dans ICRQ et ICRP) ou durant la vie de la session via des messages de contrôle SLI. Si l'autre LCCE ne peut pas prendre en charge l'émulation de cellules OAM, la session L2TP associée DOIT être supprimée via un message CDN avec le code de résultat 22.

L'AVP Émulation OAM est une AVP booléenne, qui n'a pas de valeur d'attribut. Son absence est FAUX et sa présence est VRAI. Cette AVP PEUT être cachée (le bit H PEUT être 0 ou 1). Le bit M pour cette AVP DEVRAIT être réglé à 0, mais il PEUT varier (voir au paragraphe 5.2 de la [RFC3931]). La longueur (avant de cacher) de cette AVP est 6.

 	8.	Transposition de défaut ATM et notification d'état

Les alarmes OAM ou l'état de circuit ATM sont indiqués via l'AVP État de circuit comme défini au paragraphe 5.4.5 de la [RFC3931]. Pour référence, l'usage de cette AVP est montré ci-dessous.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Réservé         |N|A|
+---------------+-----------+-+-+

La valeur est un gabarit de 16 bits avec les deux bits de moindre poids définis, et les bits restants sont réservés pour une utilisation future. Les bits réservés DOIVENT être réglés à 0 à l'envoi et ignorés à réception.

Le bit A (Actif) indique si le circuit ATM est ACTIF (1) ou INACTIF (0).

Le bit N (Nouveau) indique si l'indication d'état de circuit ATM est pour un nouveau circuit ATM (1) ou pour un circuit ATM existant (0).

 	8.1	AVP État d'alarme ATM
Une AVP "État d'alarme ATM", type d'attribut 88, indique la raison de l'état de circuit ATM et le type d'alarme spécifique, si il en est une, au nœud LCCE homologue. Cette AVP FACULTATIVE PEUT être présente dans le message SLI avec l'AVP État de circuit.

Le champ Attribut/Valeur pour cette AVP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Raison de l'état de circuit  |            Alarme             |
+---------------+---------------+---------------+---------------+

La raison de l'état de circuit est un entier non signé de 2 octets, et le type d'alarme est aussi un entier non signé de 2 octets.

Cette AVP PEUT être cachée (le bit H PEUT être 0 ou 1). Le bit M pour cette AVP DEVRAIT être réglé à 0, mais PEUT varier (voir au paragraphe 5.2 de la [RFC3931]). La longueur (avant de cacher) de cette AVP est 10 octets.

Cette AVP est envoyée dans le message SLI pour indiquer des informations supplémentaires sur l'état du circuit ATM.

Les valeurs de raison de l'état de circuit pour le message SLI sont comme suit :

0 – Réservé
1 – Pas d'alarme ou alarme supprimée (par défaut pour l'état Actif)
2 – Non spécifié ou Alarme reçue inconnue (par défaut pour l'état Inactif)
3 – Le circuit ATM a reçu une alarme F1 sur le LCCE d'entrée
4 – Le circuit ATM a reçu une alarme F2 sur le LCCE d'entrée
5 – Le circuit ATM a reçu une alarme F3 sur le LCCE d'entrée
6 – Le circuit ATM a reçu une alarme F4 sur le LCCE d'entrée
7 – Le circuit ATM a reçu une alarme F5 sur le LCCE d'entrée
8 – Le circuit ATM est défaillant à cause de la fermeture de l'accès ATM sur le LCCE homologue
9 – Le circuit ATM est défaillant à cause d'une fin de temporisation de bouclage arrière sur le LCCE d'entrée

Les alarmes générales ATM de défaillances sont codées comme suit :
0 – Réservé
1 – Pas de type d'alarme spécifié (par défaut)
2 – Signal d'indication d'alarme (AIS, Alarm Indication Signal)
3 – Indicateur de défaut distant (RDI, Remote Defect Indicator)
4 – Perte du signal (LOS, Loss of Signal)
5 – Perte du pointeur  (LOP, Loss of Pointer)
6 – Perte de trameur (LOF, Loss of Framer)
7 – Cellules de rebouclage (LB, Loopback cells)
8 – Vérification de continuité (CC, Continuity Check)

 	9.	Déclaration d'applicabilité

L'émulation de pseudo filaire ATM décrite dans le présent document permet de porter divers services ATM à travers un réseau de commutation de paquets (PSN) IP. Ces services ATM peuvent être fondés sur le PVC, fondés sur le PVP, ou fondés sur l'accès. Dans tous les cas, les PW ATM opèrent dans un modèle de déploiement point à point.

Les PW ATM prennent en charge deux modes d'encapsulation : le mode ATM AAL5-SDU et le mode de relais de cellules ATM. Les paragraphes qui suivent font la liste de leurs caractéristiques respectives en relation avec le service natif.

 	9.1	Mode ATM AAL5-SDU
Les ATMPW qui opèrent en mode AAL5-SDU prennent seulement en charge le transport de services fondés sur le PVC. Dans ce mode, les CPCS-PDU AAL5 provenant d'un seul VCC sont réassemblés au LCCE d'entrée, et les CPCS-SDU AAL5 (c'est-à-dire, les CPCS-PDU AAL5 sans CPCS-PDU en queue ou octets PAD, aussi appelés charge utile de CPCS-PDU AAL5) sont transportés sur le pseudo filaire. Donc, les fonctions de segmentation et réassemblage (SAR) sont exigées aux LCCE. Il y a une transposition biunivoque entre un PVC ATM et un ATMPW opérant en mode AAL5-SDU, prenant en charge le transport bidirectionnel de trames de longueur variable. À l'exception du transport facultatif de cellules OAM, seules des trames de couche d'adaptation ATM (AAL) de type 5 sont portées dans ce mode, incluant des paquets multi protocoles sur AAL5 [RFC2684].

Les considérations suivantes découlent du fait que les pseudo-filaires ATM en mode AAL5-SDU ne transportent pas d'en-tête de cellule ATM et d'en-queues de CPCS-PDU AAL5 (voir au paragraphe 5.1):

o 	Un ATMPW opérant en mode AAL5-SDU porte les informations de EFCI et CLP en utilisant les bits G et C dans la sous couche spécifique ATM. En conséquence, les valeurs de EFCI et CLP des cellules ATM individuelles qui constituent la trame AAL5 peuvent être perdues à travers le ATMPW, et la transparence de CLP et EFCI peut n'être pas conservée. Le mode AAL5-SDU ne préserve pas les valeurs de EFCI et CLP pour chaque cellule ATM au sein de la PDU AAL5. Le traitement de ces bits à l'entrée et la sortie est défini au paragraphe 4.1.

o	Seul le bit de moindre poids du champ CPCS-UU (indication d'utilisateur à utilisateur) dans l'en-queue de CPCS-PDU est transporté en utilisant la sous couche spécifique ATM (voir au paragraphe 4.1). Ce bit contient le bit de relais de trame C/R quand l'interfonctionnement de service FRF.8.1 de relais de trame / PVC ATM [FRF8.1] est utilisé. Le champ CPCS-UU n'est pas utilisé en multi protocoles sur AAL5 [RFC2684]. Cependant, les applications qui transfèrent des informations d'utilisateur à utilisateur en utilisant l'octet CPCS-UU ne vont pas réussir à fonctionner.

o	Le champ CPI (Indicateur de partie commune) dans l'en-queue CPCS-PDU n'est pas transporté non plus à travers le ATMPW. Cela n'affecte pas les applications multi protocoles sur AAL5 car le champ est utilisé pour l'alignement et DOIT être codé comme 0x00 [RFC2684].

o	Le champ de CRC en queue de la CPCS-PDU est supprimé au LCCE d'entrée et n'est pas transporté sur le ATMPW fonctionnant en mode AAL5-SDU. Il est à son tour régénéré au LCCE de sortie. Comme le CRC a une signification de bout en bout, cela signifie que les erreurs introduites dans la charge utile ATMPW durant l'encapsulation ou le transit à travers le réseau de commutation de paquets peuvent n'être pas détectées. Pour permettre la transparence de la vérification de l'intégrité de la charge utile sur les ATMPW opérant en mode SDU AAL5 en utilisant L2TP sur IP ou L2TP sur UDP/IP, la session L2TPv3 peut utiliser IPsec comme spécifié au paragraphe 4.1.3 de la [RFC3931].

Des caractéristiques supplémentaires du mode AAL5-SDU sont les suivantes :

o	L'état du PVC ATM est signalé entre les LCCE en utilisant l'AVP État de circuit. Des valeurs de cause plus fines pour l'état du circuit ATM et des types spécifiques d'alarme ATM sont signalées en utilisant l'AVP État d'alarme ATM (voir au paragraphe 8.1). De plus, la perte de connexité entre les LCCE peut être détectée par le mécanisme de maintien en vie L2TPv3 (voir au paragraphe 4.4 de la [RFC3931]).

o	L'ordre relatif des cellules F5 OAM par rapport aux cellules de données d'utilisateur ne peut pas être conservé. Les cellules F5 OAM qui arrivent durant le réassemblage d'une SDU AAL5 sont envoyées immédiatement sur le PW et avant la charge utile de SDU AAL5. À la sortie, ces cellules OAM sont envoyées avant les cellules qui comprennent la SDU AAL5. Donc, les applications qui s'appuient sur l'intégrité de la séquence des cellules entre les cellules OAM et les cellules de données d'utilisateur ne peuvent pas fonctionner. Cela inclut les cellules OAM de surveillance de performances et de sécurité (voir au paragraphe 5.1). De plus, le service AAL5-SDU permet l'émulation OAM dans laquelle les cellules OAM ne sont pas transportées sur le ATMPW (voir la Section 7). Ceci est avantageux pour les mises en œuvre de ATMPW en mode AAL5-SDU qui ne prennent pas en charge le transport de cellule utilisant le bit T.

o	Les procédures de fragmentation et réassemblage PEUVENT être utilisées pour gérer les MTU discordantes, comme spécifié à la Section 5 de la [RFC4623] ou dans le PSN sous-jacent (IP, etc.) entre les points d'extrémité de tunnel comme discuté au paragraphe 4.1.4 de la [RFC3931]. Une seule de ces méthodes DEVRAIT être utilisée pour un ATLPW en mode AAL5-SDU donné. Les procédures décrites dans la [RFC4623] peuvent être utilisées pour prendre en charge la taille maximum d'une SDU AAL5, 2^16 - 1 (65535) octets. Cependant, s'appuyer sur la fragmentation du paquet L2TP/IPv4 entre les points d'extrémité de tunnel limite la taille maximum de la SDU AAL5 qui peut être transportée, parce que la longueur totale maximum d'un datagramme IPv4 est déjà de 65535 octets. Dans ce cas, la SDU maximum AAL5 qui peut être transportée est limitée à 65535 moins les en-têtes d'encapsulation, 24-36 octets pour L2TP sur IPv4 ou 36-48 octets pour L2TP sur UDP/IPv4. Quand la charge utile AAL5 est IPv4, une option supplémentaire est de fragmenter les paquets IP avant le tunnel d'encapsulation avec L2TP/IP (voir au paragraphe 4.1.4 de la [RFC3931]).

o	Le séquençage peut être activé sur le ATMPW en utilisant le champ Numéro de séquence de sous couche spécifique ATM, pour détecter la perte, duplication, ou décalage de trames sur la base de la session (voir au paragraphe 4.2).

o	Les caractéristiques de qualité de service comme le débit (de cellules), les tailles de salve et variation de délai peuvent être fournies en développant les caractéristiques de qualité de service des LCCE et du PSN sous-jacent pour augmenter la fiabilité des ATMPW. Cela inclut de transposer les catégories de service ATM en une classe de service de PSN  compatible.

 	9.2	Mode de relais de cellule ATM
Dans ce mode, aucun réassemblage n'a lieu au LCCE d'entrée. Il n'y a pas d'exigence de SAR pour les LCCE. À la place, les cellules de couche ATM sont transportées sur le ATMPW. Par conséquent, tous les types AAL peuvent être transportés sur les ATMPW qui opèrent en mode de relais de cellule. Les pseudo-filaires de relais de cellule ATM peuvent opérer dans trois modes différents (voir au paragraphe 5.2) : services de VCC ATM , de VPC ATM , et de relais de cellule d'accès ATM. Certaines de leurs caractéristiques sont :

o	Les cellules ATM transportées sur des ATMPW en mode relais de cellule consistent en un en-tête de cellule ATM de 4  octets et une charge utile de cellule ATM de 48 octets (voir au paragraphe 5.2). La charge utile de service ATM d'un ATMPW en mode relais de cellule  est un multiple de 52 octets. La somme de contrôle d'erreur d'en-tête (HEC, Header Error Checksum) dans l'en-tête de cellule ATM contenant un contrôle de redondance cyclique (CRC, Cyclic Redundancy Check) calculé sur les quatre premiers octets de l'en-tête de cellule ATM n'est pas transportée. En conséquence, le champ HEC ne peut pas refléter avec précision les erreurs de bout en bout ; les erreurs ou la corruption dans l'en-tête de cellule ATM de quatre octets introduite dans la charge utile ATMPW durant l'encapsulation ou le transit à travers le PSN ne peuvent pas être détectées. Pour permettre la transparence de la vérification d'intégrité de la charge utile sur les ATMPW fonctionnant en mode relais de cellule en utilisant L2TP sur IP ou L2TP sur UDP/IP, la session L2TPv3 peut utiliser IPsec comme spécifié au paragraphe 4.1.3 de la [RFC3931].

o	Les PW ATM qui opèrent en mode de relais de cellule peuvent transporter une seule cellule ATM ou plusieurs cellules enchaînées (voir la Section 6). L'enchaînement de cellules améliore l'efficacité de bande passante du ATMPW (en diminuant les frais généraux) mais introduit de la latence et une variation du délai.

o	L'état du PVC ATM est signalé entre les LCCE en utilisant l'AVP État de circuit. Des valeurs de cause d'une granularité plus fine pour l'état de circuit ATM et les types d'alarmes spécifiques d'ATM sont signalées en utilisant l'AVP État d'alarme ATM (voir au paragraphe 8.1). De plus, la perte de connexité entre les LCCE peut être détectée par le mécanisme de maintien en vie de L2TPv3 (voir au paragraphe 4.4 de la [RFC3931]).

o	Les cellules OAM ATM sont transportées de la même façon que les cellules d'utilisateur, et dans le même ordre que celui dans lequel elles sont reçues. Donc, les applications qui s'appuient sur l'intégrité de la séquence de cellules entre OAM et cellules de données d'utilisateur ne sont pas pénalisées. Cela inclut les applications de gestion de performances et de sécurité qui utilisent des cellules OAM (voir au paragraphe 5.3).

o	Le nombre maximum de cellules enchaînées est limité par la taille de MTU de la session (voir au paragraphe 5.2 et à la Section 6). Donc, les procédures de fragmentation et réassemblage ne sont pas utilisées pour les PW ATM de relais de cellules. Enchaîner des cellules puis fragmenter le paquet résultant irait à l'encontre de l'objet de l'enchaînement de cellules. L'enchaînement de cellules et la fragmentation sont des fonctions inverses, avec du traitement supplémentaire mais un effet net nul, et ne devraient pas être utilisés ensemble.

o	Le séquençage peut être activé sur le ATMPW pour détecter les paquets perdus, dupliqués, ou en désordre sur la base de la session (voir au paragraphe 4.2).

o	Les caractéristiques de qualité de service comme le débit (de cellules) les tailles de salve, et la variation de délai peuvent être fournies en déployant les caractéristiques de qualité de service des LCCE et du PSN sous-jacent, augmentant la fiabilité des ATMPW. Cela inclut de transposer les catégories de service ATM en une classe de service de PSN compatible, et de transposer les bits CLP et EFCI en classes de service de PSN. Par exemple, transposer un PVC de débit binaire constant (CBR, Constant Bit Rate) en une classe de service avec des caractéristiques strictes de perte et de délai, comme un comportement par bond (PHB, Per-Hop Behavior) de transmission assurée (EF, Expedited Forwarding) si le PSN est un domaine IP à capacité DiffServ. Les caractéristiques suivantes des ATMPW opérant en mode de relais de cellules incluent des considérations de qualité de service supplémentaires :
-	Les PW ATM VCC de transport de cellules permettent la transposition de plusieurs VCC ATM sur un seul PW ATM. Cependant, un usager peut souhaiter transposer un seul VCC ATM par PW ATM pour satisfaire les exigences de QS (voir au paragraphe 5.2.1).
-	Les PW ATM de relais de trame permettent l'enchaînement de plusieurs cellules dans une seule PDU de PW pour améliorer l'efficacité de la bande passante, mais peuvent introduire de la latence et de la variation de délai.

 	10.	Contrôle d'encombrement

Comme expliqué dans la [RFC3985], le PSN portant le PW peut être sujet à l'encombrement, les caractéristiques d'encombrement dépendant du type de PSN, de l'architecture de réseau, de la configuration, et de la charge. Durant l'encombrement le PSN peut subir une perte de paquets et une variation du délai de paquet qui vont impacter le rythme et l'intégrité des données du PW ATM. Durant les intervalles d'encombrement aigu, certains PW ATM en relais de cellule peuvent n'être pas capables de maintenir le service. La nature inélastique de certains services ATM réduit le risque d'encombrement parce que les débits ne vont pas s'étendre au point de consommer toute la bande passante disponible, mais par ailleurs, ces services ATM ne peuvent pas réduire arbitrairement leur charge sur le réseau pour éliminer l'encombrement lorsque il se produit.

Chaque fois que possible, les PW ATM en relais de cellule devraient fonctionner sur des PSN à ingénierie du trafic qui fournissent des mécanismes d'allocation de bande passante et de contrôle d'admission. Les domaines à capacité IntServ qui fournissent le service garanti ou les domaines à capacité DiffServ qui utilisent la transmission assurée (EF) sont des exemples de PSN à ingénierie du trafic. De tels PSN vont minimiser les pertes et le délai tout en fournissant un certain degré d'isolation des effets du PW ATM de relais de cellule sur les flux du voisinage.

Si le PSN fournit un service au mieux, les considérations suivantes sur l'évitement d'encombrement dans un service au mieux s'appliquent : les PW ATM qui portent des services à débit binaire constant (CBR) et à débit variable en temps réel (VBR-rt) à travers le PSN ne vont très probablement pas se comporter avec TCP de la manière amicale prescrite par la [RFC2914]. En présence de services qui réduisent le débit de transmission, les PW ATM qui portent du trafic CBR et VBR-rt DEVRAIENT être arrêtés quand un encombrement aigu est détecté, afin de permettre aux autres trafics ou à l'infrastructure de réseau elle-même de continuer. Des PW ATM qui portent du trafic à débit binaire non spécifié, qui est équivalent au service IP au mieux, n'ont pas besoin d'être arrêtés durant un encombrement aigu et PEUVENT avoir des cellules retardées ou éliminées par le PE d'entrée si nécessaire. Les PW ATM qui portent des services à débit binaire variable non en temps réel (VBR-nrt) peuvent ou non se comporter de manière amicale avec TCP, selon l'application de l'utilisateur final, mais sont très probablement sûres pour continuer de fonctionner, car l'application d'utilisateur final est supposée être insensible au délai et peut aussi être quelque peu insensible à la perte.

Les LCCE DEVRAIENT surveiller l'encombrement (par exemple, en mesurant la perte de paquet ou comme spécifié au paragraphe 6.5 de la [RFC3985]) afin de s'assurer que le service ATM peut être maintenu. Quand un encombrement sévère est détecté (par exemple, quand on active le séquençage et qu'on détecte que la perte de paquet est supérieure à un seuil) le service ATM DEVRAIT être terminé en supprimant la session L2TP via un message CDN. Le PW peut être redémarré par une intervention manuelle, ou par des moyens automatiques après un temps d'attente approprié.

 	11.	Considérations sur la sécurité

ATM sur L2TPv3 est soumis aux considérations de sécurité définies dans la [RFC3931]. Il n'y a pas de considérations supplémentaires spécifiques du portage de ATM qui ne soient pas déjà présentes dans le portage d'autres types de liaisons de données.

 	12.	Considérations relatives à l'IANA

Les mécanismes de signalisation définis dans le présent document s'appuient sur l'allocation des types de pseudo-filaire ATM suivants (voir la liste de capacités de pseudo-filaire définie au paragraphe 5.4.3 de la [RFC3931] et les types de pseudo-filaires L2TPv3 au paragraphe 10.6 de la [RFC3931]) par l'IANA (espace de nombres créé au titre de la publication de la [RFC3931]) :

Types de pseudo-filaire  :
0x0002  : transport de VCC SDU AAL5 ATM
0x0003  : mode d'accès transparent de cellule ATM
0x0009  : mode VCC de transport de cellule ATM
0x000A  : mode VPC de transport de cellule ATM

 	12.1	Type de sous couche spécifique de couche 2
Cet espace de nombres est créé et maintenu conformément à la [RFC3931].

Type de sous couche spécifique de couche 2  :
2 – sous couche ATM spécifique de couche 2 présente

 	12.2	Paires d'attribut/valeur de message de contrôle
Cet espace de nombres est géré par l'IANA conformément à la [RFC3438].

Les trois nouvelles AVP résumées sont :
Paires d'attribut/valeur de message de contrôle
Type d'attribut	Description
86	AVP Maximum de cellules enchaînées ATM
87	AVP Émulation OAM requise
88	AVP État d'alarme ATM

 	12.3	Valeurs d'AVP de code de résultat
Cet espace de nombres est géré par l'IANA conformément à la [RFC3438].

Une nouvelle valeur de code de résultat pour le message CDN est défini à la Section 7. En voici un résumé :

Valeurs d'AVP Code de résultat (type d'attribut 1)

Codes d'erreur générale
22 - Session non établie du à ce que l'autre LCCE ne peut pas prendre en charge l'émulation de cellule OAM

 	12.4	Valeurs d'AVP État d'alarme ATM
Ceci est un nouveau registre à tenir par l'IANA.

Les nouvelles valeurs d'attribut pour l'AVP État d'alarme ATM dans le message SLI sont définies au paragraphe 8.1. Des valeurs supplémentaires peuvent être allouées par revue d'expert [RFC2434]. Elles sont résumées ci-dessous :

Valeurs de l'AVP État d'alarme ATM (type d'attribut 88)

Les valeurs de Raison de l'état de circuit pour le message SLI sont comme suit :

0 - Réservé
1 – Pas d'alarme ou alarme supprimée (par défaut pour l'état Actif)
2 – Non spécifié ou Alarme reçue inconnue (par défaut pour l'état Inactif)
3 – Le circuit ATM a reçu une alarme F1 sur le LCCE d'entrée
4 - Le circuit ATM a reçu une alarme F2 sur le LCCE d'entrée
5 - Le circuit ATM a reçu une alarme F3 sur le LCCE d'entrée
6 - Le circuit ATM a reçu une alarme F4 sur le LCCE d'entrée
7 - Le circuit ATM a reçu une alarme F5 sur le LCCE d'entrée
8 - Le circuit ATM est défaillant à cause de la fermeture de l'accès ATM sur le LCCE homologue
9 - Le circuit ATM est défaillant à cause d'une fin de temporisation de bouclage arrière sur le LCCE d'entrée

Les alarmes générales ATM de défaillances sont codées comme suit :
0 - Réservé
1 – Pas de type d'alarme spécifié (par défaut)
2 – Signal d'indication d'alarme (AIS, Alarm Indication Signal)
3 – Indicateur de défaut distant (RDI, Remote Defect Indicator)
4 – Perte du signal (LOS, Loss of Signal)
5 – Perte du pointeur  (LOP, Loss of Pointer)
6 – Perte de trameur (LOF, Loss of Framer)
7 – Cellules de rebouclage (LB, Loopback cells)
8 – Vérification de continuité (CC, Continuity Check)

 	12.5	Bits de sous couche spécifique ATM
Ceci est un nouveau registre à tenir par l'IANA.

La sous couche spécifique ATM contient 8 bits dans la portion de moindre poids de l'en-tête. Les bits réservés peuvent être alloués par consensus de l'IETF [RFC2434].

Bit 0 - Réservé
Bit 1 – bit S (séquence)
Bit 2 - bit B (fragmentation)
Bit 3 - bit E (fragmentation)
Bit 4 - bit T (type de transport)
Bit 5 - bit G (EFCI)
Bit 6 - bit C (CLP)
Bit 7 - bit U (commande/réponse)

 	13.	Remerciements

Merci de leurs contributions à Jed Lau, Pony Zhu, Prasad Yaditi, Durai, et Jaya Kumar.
Un grand merci à Srinivas Kotamraju pour ses commentaires rédactionnels.
Merci à Shoou Yiu et Fred Shu qui ont donné leur précieux temps pour relire ce document.

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

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

 	14.2	Références pour information
[ATMSEC]	ATM Forum Specification, af-sec-0100.002 (2001) "ATM Security Specification version 1.1".

[FRF8.1]	Frame Relay Forum "Frame Relay / ATM PVC Service Interworking Implementation Agreement (FRF 8.1)", 2000.

[I.610-1]	Recommandation UIT-T I.610, "Principes et fonctions d'opération et de maintenance du RNIS-LB", 1999.

[I.610-2]	Recommandation UIT-T I.610 "Principes et fonctions d'opération et de maintenance du RNIS-LB (corrigendum  1)", 2000.

[I.610-3]	Recommandation UIT-T I.610 "Principes et fonctions d'opération et de maintenance du RNIS-LB (amendement  1)", 2000.

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

[RFC2684]	D. Grossman, J. Heinanen, "Encapsulation multiprotocole sur la couche 5 d'adaptation ATM", septembre 1999. (P.S.)

[RFC2914]	S. Floyd, "Principes du contrôle d'encombrement", BCP 41, septembre 2000.

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

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

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

 	Adresse des auteurs

Sanjeev Singh	W. Mark Townsley	Carlos Pignataro	
Cisco Systems	Cisco Systems	Cisco Systems	
170 W. Tasman Drive	7025 Kit Creek Road	7025 Kit Creek Road	
San Jose, CA  95134	PO Box 14987	PO Box 14987	
mél : sanjeevs@cisco.com 	Research Triangle Park, NC 27709	Research Triangle Park, NC 27709	
	mél : mark@townsley.net 	mél : cpignata@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.