Groupe de travail Réseau	M. Townsley, Cisco Systems	
Request for Comments : 4591	G. Wilkie, Cisco Systems	
Catégorie : Sur la voie de la normalisation	S. Booth, Cisco Systems	
	S. Bryant, Cisco Systems	
	J. Lau	
Traduction Claude Brière de L'Isle	juillet 2006	

Relais de trame 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) définit un protocole pour tunneler divers protocoles de liaison de données sur les réseaux IP. Le présent document décrit les spécificités du tunnelage de relais de trame sur L2TPv3, incluant l'encapsulation de trame, la création et la suppression du circuit virtuel, et la notification de changement d'état.
Table des matières
1. Introduction	1
1.1 Abréviations	2
1.2 Spécification des exigences	2
2. Établissement de la connexion de contrôle	2
3. Notification d'état de PVC et établissement de session	2
3.1 Établissement de session L2TPv3	2
3.2 Suppression de session L2TPv3	3
3.3 Maintenance de session L2TPv3	3
3.4 Utilisation de l'AVP État de circuit pour le relais de trame	4
3.5 AVP Longueur d'en-tête de relais de trame	4
4. Encapsulation	5
4.1 Encapsulation de paquet de données	5
4.2 Séquençage de paquet de données	6
4.3 Considérations de MTU	6
5. Déclaration d'applicabilité	6
6. Considérations sur la sécurité	7
7 Considérations relatives à l'IANA	7
7.1 Type pseudo filaire	7
7.2 Valeurs d'AVP de code de résultat	7
7.3 Paires d'attribut-valeur de message de contrôle	7
8. Remerciements	7
9. Références	7
9.1 Références normatives	7
9.2 Références pour information	8
Adresse des auteurs	8
Déclaration complète de droits de reproduction	8

 	1.	Introduction

La [RFC3931] définit un protocole de base pour le tunnelage de couche 2 sur les réseaux IP. Le présent document définit les spécificités nécessaires pour tunneler le relais de trame sur L2TPv3. De tels circuits émulés sont appelés des pseudo filaires de relais de trame (FRPW, Frame Relay Pseudowire).

Les spécificités de protocole définies dans le présent document pour les FRPW L2TPv3 fonctionnant en mode de "circuit virtuel à circuit virtuel" incluent celles nécessaires à l'encapsulation de trame, à la création et la suppression des circuits virtuels permanents, et à la notification des changements d'état. Le trafic de relais de trame peut aussi être transporté "d'accès à accès" ou "d'interface à interface" en utilisant les pseudo filaires de contrôle de liaison de données de haut niveau (HDLC, High-Level Data Link Control) comme défini dans la [RFC4349]. La prise en charge des circuits virtuels commutés (SVC, Switched Virtual Circuit) et des circuits virtuels permanents commutés/mous (SPVC, Switched/Soft Permanent Virtual Circuits) sort du domaine d'application du présent document.

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

 	1.1	Abréviations
FR (Frame Relay)  : relais de trame
FRPW (Frame Relay Pseudowire)  : pseudofilaire de relais de trame
LCCE (L2TP Control Connection Endpoint)  : point d'extrémité de connexion de contrôle L2TP (voir la [RFC3931])
PVC (Permanent Virtual Circuit)  : circuit virtuel permanent
PW (Pseudowire)  : pseudofilaire
VC (Virtual Circuit)  : circuit virtuel

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

 	2.	Établissement de la connexion de contrôle

Afin de tunneler un circuit en relais de trame sur IP en utilisant L2TPv3, une connexion de contrôle L2TPv3 DOIT d'abord être établie comme décrit dans la [RFC3931]. Le message de contrôle SCCRQ de L2TPv3 et le message de contrôle SCCRP correspondant DOIVENT inclure le type de PW de 0x0001 d'identifiant de connexion de liaison de données (DLCI, Data Link Connection Identifier) en relais de trame (voir les Considérations relatives à l'IANA) dans la liste des capacités de pseudo filaire, comme défini au paragraphe 5.4.3 de la [RFC3931]. Cela identifie la connexion de contrôle comme capable d'établir des sessions L2TP pour prendre en charge les pseudo filaires de relais de trame (FRPW, Frame Relay Pseudowire).

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, c'est annoncé via les paires d'attribut-valeur (AVP) Identifiant de routeur structuré [RFC3931], bien que l'AVP Nom d'hôte non structuré [RFC3931] PUISSE aussi être utilisée pour identifier les LCCE.

 	3.	Notification d'état de PVC et établissement de session

Cette Section spécifie comment l'état d'un PVC est rapporté entre deux LCCE. Cela inclut ce qui devrait arriver quand un PVC est créé, supprimé ou quand il change d'état entre ACTIF et INACTIF. Quand il émule un service de relais de trame, si les procédures pour la gestion de l'état de PVC définies dans [Q933] Annexe A sont utilisées entre un LCCE et le système distant rattaché, un LCCE DOIT y participer (voir au paragraphe 3.3).

 	3.1	Établissement de session L2TPv3
La création (provisionnement) de PVC résulte en l'établissement d'une session L2TP via la prise de contact standard en trois phases décrite au paragraphe 3.4.1 de la [RFC3931]. Un LCCE PEUT initier la session immédiatement à la création du PVC ou attendre jusqu'à ce que l'état du PVC passe à ACTIF avant de tenter d'établir une session pour le PVC. Attendre jusqu'à ce que le PVC passe à ACTIF peut être préféré car cela retarde l'allocation des ressource de L2TP jusqu'à ce que cela soit absolument nécessaire.

L'AVP Type de pseudofilaire définie au paragraphe 5.4.4 de la [RFC3931], type d'attribut 68, DOIT être présente dans les messages de demande d'appel entrant (ICRQ, Incoming-Call-Request) et DOIT inclure le type de PW DLCI en relais de trame de 0x0001 pour les FRPW.

L'AVP État de circuit (voir au paragraphe 3.4) DOIT être présente dans les messages ICRQ et et ICRP (Incoming-Call-Reply, réponse d'appel entrant) et PEUT être présente dans le message d'informations sur l'établissement de la liaison (SLI, Set Link Info) pour les FRPW.

L'AVP Longueur d'en-tête de relais de trame (voir le pararaphe 3.5) PEUT être présente dans les messages ICRQ et ICRP.

Voici un exemple des messages L2TP échangés pour un FRPW qui est initié après qu'un nouveau PVC est provisionné et devient ACTIF.

         LCCE (LAC) A                     LCCE (LAC) B
 PVC FR provisionné
                                       FR PVC provisionné
PVC FR ACTIF
              ICRQ (état = 0x03) ---->
                                       PVC FR ACTIF
                        <---- ICRP (état = 0x03)
 session L2TP établie, OK pour envoyer les données dans le tunnel
                       ICCN ----->
                                     session L2TP établie, OK pour envoyer les données dans le tunnel

Dans l'exemple ci-dessus, une ICRQ est envoyée après que le PVC est créé et devient ACTIF. L'AVP État de circuit indique que ce PVC est ACTIF et Nouveau (0x03). L'AVP Identifiant d'extrémité distante, définie dans la [RFC3931], DOIT être présente dans la ICRQ afin d'identifier le PVC (ainsi que le LCCE lui-même, comme défini à la Section 2) pour y associer la session L2TP. L'AVP Identifiant d'extrémité distante est de forme opaque et de longueur variable, bien qu'on DOIVE au minimum prendre en charge l'utilisation d'une valeur non structurée de quatre octets connues des deux LCCE (par configuration directe, ou par d'autres moyens). La méthode exacte de configuration, restitution, découverte, ou autre de détermination de cette valeur à 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 PVC FR est passé aussi à ACTIF. Si le LCCE B n'a pas été provisionné pour le PVC identifié dans la ICRQ, un message Notification d'appel déconnecté (CDN, Call-Disconnect-Notify) serait immédiatement retourné, indiquant que le circuit n'était pas provisionné ou disponible à ce LCCE. Le LCCE A DEVRAIT alors présenter un mécanisme de réessai 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 PVC est INACTIF et un message SLI est envoyé quand le PVC devient ACTIF (voir au paragraphe 3.3).

Le message Appel entrant connecté (ICCN, Incoming-Call-Connected) est l'étape finale de l'établissement de session, confirmant la réception de l'ICRP avec des paramètres acceptables pour permettre un trafic bidirectionnel.

 	3.2	Suppression de session L2TPv3
Dans le cas de suppression d'un PVC (déprovisionné) chez l'un ou l'autre des LCCE, la session L2TP associée DOIT être supprimée via le message CDN défini au paragraphe 6.12 de la [RFC3931].

Les codes de résultat généraux concernant l'établissement de session L2TP sont définis dans la [RFC3931]. Des codes de résultat de relais de trame supplémentaires sont définis comme suit :

17 : suppression permanente du PVC FR (plus provisionné)
18 : le PVC FR a été INACTIF pendant une longue période
19 : discordance de longueur d'en-tête FR

 	3.3	Maintenance de session L2TPv3
FRPW sur L2TP utilise le message de contrôle SLI défini dans la [RFC3931] pour signaler les notifications d'état de liaison de relais de trame entre les LCCE. Cela inclut les notifications ACTIVE ou INACTIVE du circuit virtuel, et de tous les autres paramètres qui peuvent devoir être partagés entre les points d'extrémité du tunnel ou les LCCE afin de fournit une émulation de pseudo filaire appropriée. Le message SLI est un seul message qui est envoyé sur le canal de contrôle L2TP pour signaler le changement d'état. Comme la livraison du message est fiable, il n'y a pas de réponse ou action supplémentaire requise du sous système de PW pour s'assurer que la notification de changement d'état a été reçue par l'homologure du tunnel.

Le message SLI DOIT être envoyé chaque fois qu'il y a un changement d'état de circuit qui peut être rapporté par une des valeurs identifiées dans l'AVP État de circuit. Les seules exceptions à cela sont les messages initiaux ICRQ, ICRP, et CDN, qui établissent et suppriment la session L2TP elle-même quand le PVC est créé ou supprimé. Le message SLI peut être envoyé de l'un ou l'autre LCCE à tout moment après l'envoi du premier message ICRQ (et peut-être avant la réception d'une ICRP, exigeant que l'homologue effectue une recherche inverse d'identifiant de session).

Un LCCE qui participe aux procédures de gestion d'état de PVC définies dans [Q933], Annexe A, DOIT transmettre un message SLI incluant l'AVP État de circuit (voir au paragraphe 3.4) quand il détecte un changement d'état pour un PVC FR local particulier (c'est-à-dire, quand il détecte une condition qui affecte le service ou la suppression d'une telle condition). Un LCCE qui reçoit un message SLI qui indique un changement de l'état d'un certain FRPW DEVRAIT générer les mises à jour correspondantes pour le PVC FR au système distant, comme défini dans [Q933], Annexe A.

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 le maintien en vie de la session. Cela donne à toutes les sessions la détection de base d'homologue mort et de chemin entre les LCCE.

 	3.4	Utilisation de l'AVP État de circuit pour le relais de trame
L'état de circuit de relais de trame est rapporté via l'AVP État de circuit défini dans la [RFC3931], type d'attribut 71. Pour référence, cette AVP est montrée 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 dont les deux bits de moindre poids sont 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 par l'envoyeur et ignorés par le receveur.

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

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

 	3.5	AVP Longueur d'en-tête de relais de trame
L'AVP Longueur d'en-tête de relais de trame, type d'attribut 85, indique le nombre d'octets dans l'en-tête de relais de trame.  Les deux LCCE homologues DOIVENT s'accorder sur la longueur de l'en-tête de relais de trame.

Cette AVP est échangée durant la négociation de session (dans ICRQ, ICRP). Si l'autre LCCE prend en charge une longueur d'en-tête de relais de trame différente, la session L2TP associée DOIT être supprimée via un message CDN avec le code de résultat 19 (voir le paragraphe 3.2).

Si l'AVP Longueur d'en-tête de relais de trame n'est pas signalée, il DOIT être supposé que l'homologue utilise un en-tête de relais de trame de 2 octets.

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

Longueur d'en-tête de relais de trame (ICRQ, ICRP)

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Long. en-tête relais de trame |
+---------------+---------------+

Le type Longueur d'en-tête de relais de trame est un entier non signé de 2 octets avec les valeurs suivantes définies dans ce document :
2 : en-tête de relais de trame de deux octets
4 : en-tête de relais de trame de quatre octets

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 de cette AVP (avant de la cacher) est 8.

 	4.	Encapsulation
 	4.1	Encapsulation de paquet de données
La PDU FR est transportée dans sa totalité, excluant les fanions d'ouverture et de fermeture de contrôle de liaison de données de haut niveau (HDLC, High Level Data Link Control) et la séquence de vérification de trame (FCS, frame check sequence). Le bourrage de bits est défait. L'en-tête de session L2TPv3 est celui défini dans la [RFC3931]. Si le séquençage ou d'autres caractéristiques requièrent la présence d'une sous couche spécifique de couche 2, le format par défaut défini au paragraphe 4.6 de la [RFC3931] DOIT être utilisé.

L'en-tête FR est défini dans [Q922] ; cependant, la notation utilisée diffère de celle utilisée dans les spécifications de l'IETF. Pour référence, l'en-tête FR (appelé champ Adresse dans [Q922]) est dans la notation de l'IETF  :

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hi dlci   |C|0|lo dlci|F|B|D|1|
+-----------+-+-+-------+-+-+-+-+

pour l'en-tête FR de deux octets

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hi dlci   |C|0| dlci  |F|B|D|0|   dlci      |0| dlci_lo   |0|1|
+-----------+-+-+-------+-+-+-+-+-------------+-+-----------+-+-+

pour l'en-tête FR de quatre octets.

C/R (bit 6) bit trame FR C/R (commande/réponse) [Q922].

F (FECN) (bit 12) : bit FR de notification d'encombrement explicite vers l'avant (FECN, Forward Explicit Congestion Notification) [Q922].

B (BECN) (bit 13) : bit FR de notification d'encombrement explicite vers l'arrière (BECN, Backward Explicit Congestion Notification) [Q922].

D (DE) (bit 14)  : le bi DEt FR indique l'éligibilité à l'élimination [Q922].

L'usage des bits C/R, FECN, BECN, et DE est comme spécifié dans [Q922].

Le bit C/R est transporté de façon transparente. Sa valeur NE DOIT PAS être changée par le LCCE.

Le bit FECN PEUT être établi par le LCCE pour notifier à l'utilisateur d'extrémité receveuse que les trames qu'il reçoit ont rencontré de l'encombrement. L'utilisateur final peut utiliser cette indication pour l'ajustement du débit de transmission contrôlé par la destination. Le bit ne doit jamais être mis à zéro par le LCCE. Si le LCCE ne prend pas en charge la FECN, il devra passer le bit inchangé.

Le bit BECN PEUT être établi par le LCCE pour notifier à l'utilisateur d'extrémité receveuse que les trames qu'il transmet peuvent rencontrer de l'encombrement. L'utilisateur final peut utiliser cette indication pour l'ajustement de son débit de transmission. Le bit ne doit jamais être mis à zéro par le LCCE. Si le LCCE ne prend pas en charge BECN, il devra passer le bit inchangé.

Le bit DE PEUT être établi par une fonction de régulation sur le LCCE pour indiquer que cette trame DEVRAIT être éliminée de préférence à d'autres trames dans une situation d'encombrement. Le bit ne doit jamais être mis à zéro par le LCCE. Si le LCCE ne prend pas en charge DE, il devra passer le bit inchangé.

L'encapsulation de trames de relais de trame avec l'en-tête FR de deux octets est EXIGÉE. L'encapsulation de trames de relais de trame avec l'en-tête de quatre octets est FACULTATIVE. L'encapsulation de trames de relais de trame avec l'en-tête FR de trois octets sort du domaine d'application de ce document.

 	4.2	Séquençage de paquet de données
Le séquençage de paquet de données PEUT être activé pour les FRPW. 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. Un FRPW sur L2TP DOIT demander la présence de la sous couche spécifique de couche 2 L2TPv3 par défaut quand le séquençage est activé et PEUT demander sa présence à tout moment.

Si il est connu que le FRPW porte des données qui n'exigent pas que l'ordre des paquets soit strictement conservé (comme IP) le séquençage de paquets pour le FRPW NE DEVRAIT PAS être activé.

 	4.3	Considérations de MTU
Avec L2TPv3 comme protocole de tunnelage, le paquet résultant de l'encapsulation est plus long de N octets que la trame de relais de trame sans les fanions d'ouverture et fermeture de HDLC ou de FCS. La valeur de N dépend des champs suivants :

En-tête de session L2TP :
Fanions, Ver, Res  : 4 octets (seulement pour L2TPv3 sur UDP)
Identifiant de session  : 4 octets
Taille de mouchard  : 0, 4, ou 8 octets
Sous couche spécifique de couche 2  : 0 ou 4 octets (c'est-à-dire, avec séquençage)

Donc, la gamme pour N en octets est :
N = 4 à 16  : les messages de données L2TPv3 sont sur IP
N = 16 à 28 : les messages de données L2TPv3 sont sur UDP 
(N n'inclut pas l'en-tête IP)

Les implications de MTU et de fragmentation résultantes sont discutées au paragraphe 4.1.4 de la [RFC3931].

 	5.	Déclaration d'applicabilité

L'émulation de PW en relais de trame décrite dans ce document permet à un fournisseur de service d'offrir un service de relais de trame fondé sur le PVC à travers un réseau IP de commutation de paquets (PSN, packet switching network). Un service de relais de trame fondé sur l'accès peut être offert en utilisant la [RFC4349].

L'émulation de FRPW a les caractéristiques suivantes en relation avec le service natif :

o	Il y a une transposition biunivoque entre un PVC de relais de trame et un FRPW, prenant en charge le transport bidirectionnel de trames de longueur variable. La trame de relais de trame est transportée dans sa totalité, incluant le DLCI et les bits C/R, FECN, BECN, et DE, mais excluant les fanions d'ouveture et de fermeture et la FCS. Le LCCE de sortie réécrit le DLCI et génère à nouveau la FCS.

o	Des champs d'adresse de deux et quatre octets sont acceptés. La longueur est négociée entre les LCCE durant l'établissement de la session (paragraphe 3.5).

o	La disponibilité ou l'indisponibilité du PVC est signalée entre les LCCE en utilisant l'AVP État de circuit (paragraphe  3.4). La perte de connexité entre les LCCE peut être détectée par le mécanisme de maintien en vie de L2TPv3 (paragraphe 4.4 de la [RFC3931]). Ces indications peuvent être utilisées pour déterminer l'état du PVC à signaler par les procédures de [Q933] à l'interface de relais de trame.

o	La taille maximum de trame qui peut être supportée est limitée par la MTU du PSN, sauf si la fragmentation et le réassemblage sont utilisés (paragraphe 4.1.4 de la [RFC3931]).

o	Le séquençage peut être activé sur le FRPW pour assurer que les trames sont livrées dans l'ordre (paragraphe 4.2).

o	Les caractéristiques de qualité de service, comme le débit, la taille de salve promise (bc), la taille de salve en excès (be), et la priorité, peuvent être fournies par l'application des caractéristiques de qualité de service des LCCE et du PSN sous-jacent.

 	6.	Considérations sur la sécurité

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

 	7	Considérations relatives à l'IANA
 	7.1	Type pseudo filaire
La valeur suivante pour le type de PW DLCI en relais de trame (voir la liste des 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]) est allouée par l'IANA (dans l'espace de numéros déjà créé au titre de la publication de la [RFC3931]) :

Types de pseudo filaires L2TPv3
0x0001 : Type de pseudo filaire DLCI en relais de trame

 	7.2	Valeurs d'AVP de code de résultat
Cet espace de numéros est géré par l'IANA comme décrit au paragraphe 2.3 de la [RFC3438]. Trois nouveaux codes de résultat L2TP pour le message CDN apparaissent au paragraphe 3.2. Ils sont repris ici :

Valeurs d'AVP de code de résultat (type d'attribut)
17 : suppression permanente du PVC FR (plus provisionné)
18 : le PVC FR a été INACTIF pendant une longue période
19 : discordance de longueur d'en-tête FR

 	7.3	Paires d'attribut-valeur de message de contrôle
Cet espace de numéros est géré par l'IANA comme décrit au paragraphe 2.2 de la [RFC3438]. Un attribut d'AVP supplémentaire, spécifié au paragraphe 3.5, a été alloué pour la présente spécification :

Paires d'attribut-valeur de message de contrôle  :
85 : Longueur d'en-tête de relais de trame

 	8.	Remerciements

Le premier document sur le relais de trame sur L2TP, "Type de service de relais de trame pour L2TP", a été publié en février 2001, par Nishit Vasavada, Jim Boyle, Chris Garner, Serge Maskalik, et Vijay Gill. Le présent document est substantiellement différent, mais le concept de base de porter le relais de trame sur L2TP est le même.
Merci à Lloyd Wood pour sa relecture impitoyable.
Carlos Pignataro nous aidé à relire et éditer le document.
Durant le dernier appel à l'IETF, Mark Lewis a fourni une relecture serrée et des commentaires.

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

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

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

[Q922]	Recommandation UIT-T Q.922, "Specification de la couche de liaison des données RNIS pour les services supports en mode trame", UIT, Genève, 1992.

[Q933]	Recommandation UIT-T Q.933, "Spécifications de signalisation pour contrôle de connexion virtuelle en mode trame commutée et permanente et surveillance de l'état", UIT, Genève, 2003.

 	Adresse des auteurs
W. Mark Townsley	George Wilkie	Skip Booth	
Cisco Systems	Cisco Systems	Cisco Systems	
7025 Kit Creek Road	96 Commercial Street	7025 Kit Creek Road	
PO Box 14987	Edinburgh, EH6 6LX	PO Box 14987	
Research Triangle Park, NC 27709	United Kingdom	Research Triangle Park, NC 27709	
mél : mark@townsley.net 	mél : gwilkie@cisco.com 	mél : ebooth@cisco.com 	

Stewart Bryant	Jed Lau	
Cisco Systems	mél : jedlau@gmail.com 	
250 Longwater Ave		
Green Park		
Reading RG2 6GB		
United Kingdom		
mél : stbryant@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.