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

Trames de contrôle de liaison de données à haut niveau (HDLC) sur la version 3 du protocole de tunnelage de couche 2 (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 pour tunneler divers protocoles de liaisons de données sur les réseaux IP. Le présent document décrit les spécificités du tunnelage de trames de contrôle de liaison de données de haut niveau (HDLC, High-Level Data Link Control) sur L2TPv3.
Table des matières
1. Introduction	1
1.1 Abréviations	2
2. Établissement de connexion de contrôle	2
3. Notification d'état de liaison HDLC 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 HDLC	4
4. Encapsulation	4
4.1 Encapsulation de paquet de données	4
4.2 Séquençage de paquet de données	4
4.3 Considérations de MTU	5
5. Déclaration d'applicabilité	5
6. Considérations sur la sécurité	5
7 Considérations relatives à l'IANA	6
7.1 Type pseudo filaire	6
7.2 Valeurs d'AVP de code de résultat	6
8. Remerciements	6
9. Références	6
9.1 Références normatives	6
9.2 Références pour information	6
Adresse des auteurs	6
Déclaration complète de droits de reproduction	7

 	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 au tunnelage des trames HDLC sur L2TPv3. De telles émulations de circuits sont appelées des pseudo filaires HDLC (HDLCPW).

Les spécificités de protocole définies dans le présent document pour les HDLCPW L2TPv3 incluent celles nécessaires pour l'encapsulation de trame en simple point à point (par exemple, entre deux nœuds L2TPv3) et pour des notifications simples d'interface active et inactive.

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

 	1.1	Abréviations
CDN (Call-Disconnect-Notify)  : notification d'appel déconnecté
FCS (Frame Check Sequence)  : séquence de contrôle de trame
ICCN (Incoming-Call-ConNected)  : appel entrant connecté
ICRP (Incoming-Call-RePly)  : réponse d'appel entrant
ICRQ (Incoming-Call-ReQuest)  : demande d'appel entrant
HDLC (High-Level Data Link Control)  : contrôle de liaison de données de haut niveau
HDLCPW (HDLC Pseudowire)  :  pseudo filaire HDLC
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])
SLI (Set-Link-Info)  : informations sur l'établissement de la liaison
PW (PseudoWire)  : pseudo filaire

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" dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119] quand, et seulement quand ils apparaissent tout en majuscules, comme montré ci-dessus.

 	2.	Établissement de connexion de contrôle

Afin de tunneler une liaison HDLC sur IP en utilisant L2TPv3, une connexion de contrôle L2TPv3 DOIT d'abord être établie comme décrit dans la [RFC3931]. Le message SCCRQ L2TPv3 et le message de contrôle SCCRP correspondant DOIVENT inclure le type pseudo filaire HDLC de 0x0006 (voir la Section 7, "Considérations relatives à l'IANA") dans la liste des capacités pseudo filaires 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 HDLC (HDLCPW).

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 Identifiant de routeur structuré [RFC3931], bien que l'AVP Nom d'hôte non structuré [RFC3931] PUISSE aussi être utilisé pour identifier les LCCE.

 	3.	Notification d'état de liaison HDLC et établissement de session

Cette Section spécifie comment l'état d'une interface HDLC est rapporté entre deux LCCE, et la création et suppression de session L2TP associée qui se produit.

 	3.1	Établissement de session L2TPv3
Associer une interface HDLC de série à un PW et sa transition à l'état "prêt" ou "actif" résulte en l'établissement d'une session L2TP via la prise de contact standard à trois phases décrite au paragraphe 3.4.1 de la [RFC3931]. Pour les besoins de cette discussion, l'action d'association locale d'une interface faisant fonctionner HDLC avec un PW par configuration locale ou autrement est appelée le "provisionnement" de l'interface HDLC. La transition de l'interface à l'état "prêt" ou "actif" va être mentionnée comme l'interface devenant ACTIVE. La transition de l'interface à l'état "pas prêt" ou "inactif" va être mentionnée comme l'interface devenant INACTIVE.

Un LCCE PEUT initier la session immédiatement au moment de l'association à une interface HDLC ou attendre jusqu'à ce que l'interface devienne ACTIVE avant de tenter d'établir une session L2TP. Attendre que l'interface transite à ACTIVE peut être préféré, car cela retarde l'allocation de ressources jusqu'à ce qu'elles soient absolument nécessaires.

L'AVP Type de pseudo filaire définie 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 pseudo filaire de 0x0006 pour les HDLCPW.

L'AVP État de circuit (voir au paragraphe 3.4) DOIT être présente dans les messages ICRQ et ICRP et PEUT être présente dans le message SLI pour les HDLCPW.

Voici un exemple de messages L2TP échangés pour un HDLCPW qui est initié après le provisionnement d'une interface HDLC et qui est devenue ACTIVE.

      LCCE (LAC) A                          LCCE (LAC) B
HDLC provisionnée
                                                Interface HDLC provisionnée
Interface HDLC ACTIVE
              ICRQ (état = 0x03) ---->
                                               Interface HDLC ACTIVE
                                           <---- 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 interface est provisionnée et devient ACTIVE. L'AVP État de circuit indique que cette liaison est ACTIVE et nouvelle (0x03). L'AVP Identifiant d'extrémité distante [RFC3931] DOIT être présente dans la ICRQ afin d'identifier la liaison HDLC (ainsi que l'identité du LCCE lui-même comme défini dans la Section 2) à laquelle associer la session L2TP. L'AVP Identifiant d'extrémité distante définie dans la [RFC3931] est de forme opaque et de longueur variable, bien qu'on DOIVE au minimum prendre en charge l'utilisation d'une valeur de quatre octets non structurée 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 l'interface HDLC associée transite aussi à l'état ACTIVE. Si le LCCE B n'avait pas été provisionné pour l'interface identifiée dans la ICRQ, un message CDN aurait été immédiatement retourné pour indiquer que la liaison associée n'était pas provisionnée ou disponible à ce LCCE. Le LCCE A DEVRAIT alors présenter un mécanisme périodique de réessai. Si il en est ainsi, la période et le nombre maximum de réessais DOIVENT être configurables.

Une mise en œuvre PEUT envoyer une ICRQ ou ICRP avant qu'une interface HDLC soit ACTIVE, pour autant que l'AVP État de circuit reflète que la liaison est INACTIVE et qu'un message SLI soit envoyé quand l'interface HDLC devient ACTIVE (voir au paragraphe 3.3).

Le ICCN est le stade final de l'établissement de session, confirmant la réception de la ICRP avec des paramètres acceptables pour permettre un trafic bidirectionnel.

 	3.2	Suppression de session L2TPv3
Lorsque une liaison est supprimée (déprovisionnée) chez l'un ou l'autre 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 HDLC supplémentaires sont définis comme suit :

20 – suppression permanente de la liaison HDLC (plus provisionnée)
21 – liaison HDLC INACTIVE pendant une longue période

 	3.3	Maintenance de session L2TPv3
Les HDLCPW sur L2TP utilisent le message de contrôle d'informations sur l'établissement de la liaison (SLI, Set Link Info) défini dans la [RFC3931] pour signaler les notifications d'état de liaison HDLC entre les points d'extrémité. Le message SLI est un seul message qui est envoyé sur le canal de contrôle L2TP pour signaler le changement d'état de l'interface.

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

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

 	3.4	Utilisation de l'AVP État de circuit pour HDLC
HDLC rapporte l'état de circuit avec l'AVP État de circuit définie 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 à l'envoi, et ignorés à réception.

Le bit N (Nouveau) DEVRAIT être réglé à un (1) si l'indication d'état de circuit est pour un nouveau circuit HDLC ; à zéro (0) autrement.

Le bit A (Actif) indique si l'interface HDLC est ACTIVE (1) ou INACTIVE (0).

 	4.	Encapsulation
 	4.1	Encapsulation de paquet de données
Les HDLCPW utilisent les encapsulations par défaut définies dans la [RFC3931] pour démultiplexer, séquencer, et pour les fanions. Le type HDLCPW sur L2TP est destiné à fonctionner en mode "d'interface à interface" ou "d'accès à accès", passant toutes les données HDLC et les PDU de contrôle sur le PW. La PDU HDLC est supprimée des fanions et de la FCS de queue, ainsi que le bourrage de bits/octets, et les données restantes, incluant les champs d'adresse, de contrôle, et de protocole, sont transportées sur le PW.

Comme tous les paquets sont passés de façon largement transparente sur le HDLCPW, tout protocole qui a le tramage de type HDLC peut utiliser le mode HDLCPW, incluant PPP, le relais de trame (transport en relais de trame "d'accès à accès"), X.25 (LAPB), etc. Dans ces cas, les négociations et la signalisation des protocoles spécifiques transportés sur le HDLCPW ont lieu entre les systèmes distants. Une liste non exhaustive d'exemples et considérations de cette nature transparente inclut :

o	Quand le HDLCPW transporte du trafic du protocole point à point (PPP) les négociations PPP (protocole de commande de liaison, authentification facultative, et protocoles de contrôle réseau) sont effectués entre les systèmes distants, et les LCCE ne participent pas à ces négociations.

o	Quand le HDLCPW transporte du trafic de relais de trame, les procédures de gestion d'état de circuit virtuel permanent (interface de gestion locale) ont lieu entre les systèmes distants, et les LCCE ne participent pas à l'interface de gestion locale. De plus, les circuits virtuels individuels de relais de trame ne sont pas visibles aux LCCE, et les bits FECN, BECN, et DE sont transportés de façon transparente.

o	Quand le HDLCPW transporte du trafic X.25 (LAPB) les LCCE ne fonctionnent pas comme des appareils LAPB DCE ou DTE.

Par ailleurs, les exceptions incluent les cas où un accès direct à l'interface HDLC est exigé, ou les modes qui opèrent sur les fanions, la FCS, ou quand la suppression du bourrage de bits/octets est effectuée avant l'envoi de la PDU HDLC sur le PW. Un exemple de cela est la négociation PPP ACCM.

 	4.2	Séquençage de paquet de données
Le séquençage de paquet de données PEUT être activé pour les HDLCPW. Les mécanismes de séquençage décrits au paragraphe 4.6.1 de la [RFC3931] DOIVENT être utilisés pour la prise en charge du séquençage de signalisation. Les HDLCPW sur L2TP DOIVENT demander la présence de la sous couche L2TPv3 spécifique de couche 2 par défaut définie au paragraphe 4.6 de la [RFC3931] quand le séquençage est activé, et PEUVENT demander sa présence à tout moment.

 	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 HDLC sans les fanions ou la FCS. La valeur de N dépend des champs suivants :

En-tête de session L2TP :
Fanions, Ver, Res  : 4 octets (seulement 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, en utilisant le séquençage)

Donc, la gamme pour N en octets est :
N = 4 à 16, messages de données L2TPv3 sont sur IP ;
N = 16 à 28, 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ésultant de cela sont discutées au paragraphe 4.1.4 de la [RFC3931].

 	5.	Déclaration d'applicabilité

Les pseudo filaires HDLC prennent en charge un modèle de déploiement "d'accès à accès" ou "d'interface à interface" fonctionnant en point à point. En plus du transport de trames HDLC, une application naturelle des HDLCPW permet le transport de tout protocole qui utilise un tramage de style HDLC.

L'émulation de HDLCPW sur un réseau à commutation de paquets (PSN, Packet-Switched Network) a les caractéristiques suivantes en relations avec le service natif :
o	Les données HDLC et les champs de contrôle sont transportés de façon transparente (voir au paragraphe 4.1). Les négociations spécifiques et la signalisation du protocole transporté sont effectuées en transparence entre les systèmes distants, et les LCCE n'y participent pas.
o	La FCS en queue contenant un contrôle de redondance cyclique (CRC, Cyclic Redundancy Check) est supprimée au LCCE d'entrée et n'est pas transportée sur les HDLCPW. Elle est donc regénérée au LCCE de sortie (voir au paragraphe  4.1). Cela signifie que la FCS ne peut pas refléter avec précision les erreurs sur la liaison HDLC de bout en bout. Les erreurs ou la corruption introduites dans la charge utile de HDLCPW durant l'encapsulation ou le transit à travers le PSN ne peuvent pas être détectées. Ce manque de transparence de vérification d'intégrité peut n'être pas un problème si il est connu que les charges utiles internes ou supérieures des protocoles transportés effectuent leur propre vérification d'erreur et d'identité. Pour permettre la transparence de vérification d'intégrité de charge utile sur les HDLCPW 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	La notification d'état de liaison HDLC est fournie avec l'AVP État de circuit dans le message SLI (paragraphe 3.4).
o	La longueur du paquet L2TPv3 résultant est supérieure à celle de la trame HDLC encapsulée sans fanions ni FCS (paragraphe 4.3) les implications résultantes de MTU et de fragmentation étant discutées au paragraphe 4.1.4 de la [RFC3931].
o	Le PSN peut réordonner, dupliquer, ou éliminer en silence des paquets. Le séquençage peut être activé dans le HDLCPW pour certains ou tous les paquets pour détecter la perte, duplication, ou le décalage de paquets sur la base de la session (voir au paragraphe 4.2).
o	La fiabilité d'un HDLCPW peut être accrue en incorporant des caractéristiques de qualité de service aux LCCE et dans le PSN sous-jacent.

 	6.	Considérations sur la sécurité

HDLC sur L2TPv3 est soumis aux considérations de sécurité définies dans la [RFC3931]. Au delà des considérations sur le portage d'autres types de liaisons de données, il n'y a pas de considérations supplémentaires spécifique de HDLC.

 	7	Considérations relatives à l'IANA
 	7.1	Type pseudo filaire
Les mécanismes de signalisation définis dans le présent document s'appuient sur l'allocation d'un type Pseudo filaire HDLC (voir la liste des capacités de pseudo filaire définie au paragraphe 5.4.3 de la [RFC3931] et des types de pseudo filaires L2TPv3 au paragraphe 10.6 de la [RFC3931]) par l'IANA (espace de numéros créé au titre de la publication de la [RFC3931]). Le type Pseudo filaire HDLC est défini dans la Section 2 de la présente spécification:

Types Pseudo filaires L2TPv3
0x0006 - type Pseudo filaire HDLC

 	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]. Deux nouveaux codes de résultat L2TP pour le message CDN apparaissent au paragraphe 3.2. Ce sont :

Valeurs d'AVP de code de résultat (type d'attribut 1)  :
20 – suppression permanente de la liaison HDLC (plus provisionnée)
21 – liaison HDLC INACTIVE pendant une longue période

 	8.	Remerciements

Merci à Sudhir Rustogi et George Wilkie de leurs précieux apports. Maria Alice Dos Santos a effectué une utile relecture et des commentaires. Tous nos remerciements à Mark Lewis qui a fourni des commentaires durant le dernier appel de l'IETF.

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

 	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)

 	Adresse des auteurs
Carlos Pignataro	W. Mark Townsley	
Cisco Systems	Cisco Systems	
7025 Kit Creek Road	7025 Kit Creek Road	
PO Box 14987	PO Box 14987	
Research Triangle Park, NC 27709	Research Triangle Park, NC 27709	
USA	USA	
mél : cpignata@cisco.com 	mél : mark@townsley.net 	

 	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.