Groupe de travail Réseau	A. Vainshtein, ECI Telecom	
Request for Comments: 5611	S. Galtzur, Rebellion	
Catégorie : Sur la voie de la normalisation	août 2009	
Traduction Claude Brière de L'Isle		

Protocole de tunnelage de couche 2 version 3 - établissement de pseudo filaires en multiplexage à répartition dans le temps (TDM)

Résumé
Le présent document définit des extensions au protocole de tunnelage de couche 2 version 3 (L2TPv3, Layer Two Tunneling Protocol version 3) pour la prise en charge de pseudo-filaires ignorants de la structure et sensibles à la structure (de style du service d'émulation de circuit sur réseau de commutation de paquets (CESoPSN, Circuit Emulation Service over Packet Switched Network)) en multiplexage à répartition dans le temps (TDM, Time-Division Multiplexing). La prise en charge de pseudo-filaires sensibles à la structure (de style de multiplexage à répartition dans le temps sur IP (TDMoIP, Time-Division Multiplexing over IP)) sur L2TPv3 fera l'objet d'une étude ultérieure.

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. 

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.
Table des matières
1. Introduction	2
1.1 Conventions utilisée dans le document	2
2. Extensions à L2TPv3	2
2.1 Paire d'attribut-valeur de pseudo filaire TDM (ICRQ, OCRQ)	2
2.2 Paire d'attribut-valeur (AVP) RTP (ICRQ, OCRQ, ICRP, OCRP)	4
2.3 Changements dans les AVP de gestion de connexion de contrôle	4
2.4 Changements dans les AVP de gestion de session	4
3. Création de la session de pseudo filaire TDM	5
4. Considérations relatives à l'IANA	5
5. Contrôle d'encombrement	6
6. Considérations sur la sécurité	6
7. Remerciements	6
8. Références	6
8.1 Références normatives	6
8.2 Références pour information	7
Adresse des auteurs	7

 	1.	Introduction

Le présent document définit des extensions au protocole de tunnelage de couche 2, version 3 (L2TPv3, Layer Two Tunneling Protocol Version 3) pour la prise en charge de pseudo-filaires en multiplexage à répartition dans le temps (TDM, Time-Division Multiplexing) ignorants de la structure [RFC4553] et tenant compte de la structure (de style CESoPSN, voir la [RFC5086]). L'encapsulation ignorante de la structure de flux binaires en TDM sur L2TPv3 est décrite dans la [RFC4553], Figure 2b ; l'encapsulation tenant compte de la structure de service d'émulation de circuit sur réseaux à commutation de paquets (CESoPSN, Circuit Emulation Service over Packet Switched Network) est décrite dans la [RFC5086], Figures 1c (paquets de données en TDM) et 4a (paquets de signalisation d'application CE). Cependant, l'ordre du mot de contrôle (CW, Control Word) CESoPSN et de l'en-tête RTP (si il est utilisé) DOIT correspondre entre les données en TDM et les paquets de signalisation d'émulation de circuit (CE, Circuit Emulation).

L'établissement de pseudo-filaires tenant compte de la structure en TDM utilisant les encapsulations décrites dans la [RFC5087] a été laissé pour étude ultérieure.

L'établissement et la maintenance de pseudo filaires (PW) en TDM dans les réseaux MPLS utilisant LDP est décrite dans la [RFC5287].

 	1.1	Conventions utilisée dans le document
Dans le présent document, on se réfère au "plan de contrôle" comme signifiant les paquets qui contiennent des informations de contrôle (via des paires Attribut-Valeur (AVP)) et le mécanisme qui traite ces paquets. On se réfère aussi au "plan des données" comme signifiant les paquets qui contiennent des données d'utilisateur transportées.

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.	Extensions à L2TPv3

La connexion de contrôle L2TPv3 est responsable de trois opérations principales :
1. Établissement et validation d'une session de pseudo filaires (PW).
2. Terminaison (suppression) d'une session de pseudo filaires.
3. Transfert de l'état de point d'extrémité.

Supprimer une session pour un pseudo filaire en TDM est effectué suivant les opérations de suppression de L2TPv3 décrites au paragraphe 3.4.3 de la [RFC3931].

Les [RFC5086] et [RFC4553] décrivent comment transférer l'état de circuit de rattachement (AC, Attachment Circuit) via le plan des données. Donc, le message Set-Link-Info (SLI) décrit dans la [RFC3931] NE DEVRAIT PAS être utilisé pour porter cet état pour les PW en question.

La [RFC3931] spécifie que la paire d'attribut valeur (AVP) État de circuit DOIT être présente dans les messages de demande d'appel entrant/réponse d'appel entrant (ICRQ/ICRP, Incoming-Call-Request / Incoming-Call-Reply). Elle spécifie aussi que le bit N bit dans cette AVP devrait être établi durant l'établissement de PW, même si l'AC spécifique ne fournit aucun moyen de porter l'indication de "nouvel AC". En conséquence, l'AVP État de circuit pour les PW en question, quand il est utilisé dans les messages ICRQ/ICRP, DOIT toujours avoir les deux bits N et A établis.

Les paragraphes qui suivent décrivent les extensions à L2TPv3 pour l'établissement et la validation des sessions de pseudo filaires en TDM.

Il y a deux nouvelles AVP pour les messages Gestion de session. Une AVP décrit les attributs de pseudo filaires en TDM. La seconde AVP décrit les attributs de RTP pour ce pseudo fialire en TDM.

 	2.1	Paire d'attribut-valeur de pseudo filaire TDM (ICRQ, OCRQ)
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|réservé|     Longueur      |Identifiant de fabricant (IETF)|
+-+-+-------+---+---------------+---------------+---------------+
| Type d'attribut (99)          |         Réservé       |SP |CAS|
+---------------+---------------+---------------+-------+---+---+
|       Débit binaire           |   Octets de charge utile      |
+---------------+---------------+---------------+---------------+

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. La longueur (avant de cacher) de cette AVP est 12.

Le champ débit binaire contient la valeur qui représente le débit binaire de l'AC local en unités de 64 kbit/s, codé comme un entier non signé de 16 bits. Son usage pour tous les types de PW en TDM utilise la sémantique suivante :

1)	Pour l'émulation ignorante de la structure, ce paramètre DOIT être réglé à une des valeurs suivantes (voir la [RFC4553]) :
a) émulation ignorante de la structure E1 - 32
b) émulation ignorante de la structure T1 :
i) DOIT être réglé à 24 pour le mode de base
ii) DOIT être réglé à 25 pour le mode "T1 aligné sur l'octet".
c) émulation ignorante de la structure E3 - 535
d) émulation ignorante de la structure T3 - 699
2)	Pour les PW CESoPSN, ce paramètre DOIT être réglé au nombre de canaux DS0 dans le circuit de rattachement correspondant.

Note : Pour l'émulation ignorante de la structure T1, les valeurs 24 et 25 ne reflètent pas le débit binaire exact et sont utilisé seulement par facilité.

Note : La signification du champ Débit binaire définie ci-dessus est cohérente avec celle du paramètre d'interface Débit binaire CEP/TDM définie dans la [RFC5287].

Le champ Octets de charge utile contient la valeur qui représente le nombre d'octets de charge utile en TDM dans le paquet de PW et est utilisé avec la signification suivante :

1)	Pour l'émulation ignorante de la structure, toute valeur de Octets de charge utile peut être spécifiée.

2)	Pour les PW CESoPSN :
a)	La valeur spécifiée DOIT être un entier multiple du nombre de canaux DS0 dans le circuit de rattachement correspondant.
b)	En plus de cela, pour NxDS0 spécifique de jonction avec signalisation du canal associé (CAS, Channel-Associated Signaling) le nombre de trames de jonction par fragment multi-trames (valeur résultant de la division des octets de charge utile par le nombre de canaux DS0) DOIT être un diviseur entier du nombre de trames par jonction multi-trames correspondante.

Les bits Réservés DOIVENT être réglés à 0 à l'émission et DOIVENT être ignorés à réception.

Les bits SP définissent la prise en charge des paquets de signalisation d'application CESoPSN (voir la [RFC5086]) et DOIVENT être utilisés comme suit :

1)	Réglé à "01" pour les PW CESoPSN portant des paquets de données en TDM et attendant des paquets de signalisation d'application CE dans un PW séparé.

2)	Réglé à "10" pour un PW portant des paquets de signalisation d'application CE avec les paquets de données dans un PX séparé.

3)	Réglé à "11' pour un PW CESoPSN portant à la fois des paquets de données en TDM et des paquets de signalisation.

4)	Réglé à "00' pour les PW de multiplexage sur paquets à répartition dans le temps ignorant de la structure (SAToP, Structure Agnostic Time-Division Multiplexing over Packet) et pour les PW CESoPSN qui n'utilisent pas de paquets de signalisation séparés.

Les bits de CAS définissent le type de jonctions pour les services de CESoPSN spécifiques de jonction avec CAS. Ces bits DOIVENT être réglés à :
1)	Pour CESoPSN spécifique de jonction avec CAS :
a) "01" dans le cas d'une jonction E1,
b) "10" dans le cas d'une jonction T1/ESF,
c) "11" dans le cas d'une jonction T1/SF.
2)	"00" pour tous les autres types de pseudo-filaire en TDM.

 	2.2	Paire d'attribut-valeur RTP (ICRQ, OCRQ, ICRP, OCRP)
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|réservé|     Longueur      |Identifiant de fabricant (IETF)|
+-+-+-------+---+---------------+---------------+---------------+
|    Type d'attribut  (100)     |D|     PT      |C|  Réservé    |
+---------------+---------------+-+-------------+-+-------------+
|         Réservé               | Fréqu. d'horloge d'horodatage |
+---------------+---------------+---------------+---------------+
|                              SSRC                             |
+---------------+---------------+-------------------------------+

La présence de cette AVP indique que l'en-tête RTP est utilisé dans l'encapsulation de pseudo-filaire TDM. L'utilisation ou la non utilisation de l'en-tête RTP DOIT correspondre pour les deux directions d'un PW en TDM. 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. La longueur (avant de cacher) de cette AVP est 16.

Le bit D indique le mode d'horodatage (absolu ou différentiel) dans l'en-tête RTP. Ces modes sont décrits, par exemple, au paragraphe 4.3.2 de la [RFC4553]. Si le bit D est réglé à 1, alors le mode d'horodatage différentiel est utilisé ; autrement, le mode d'horodatage absolu est utilisé. Les modes d'horodatage peuvent être utilisés indépendamment pour les deux directions d'un PW TDM.

Le bit C indique l'ordre de l'en-tête RTP et le mot de contrôle comme suit :
o	Si le bit C est réglé à 1, l'en-tête RTP apparaît après le mot de contrôle dans le canal de données du pseudo-filaire en TDM. Ce mode est décrit dans les [RFC4553] et [RFC5086] comme encapsulation SAToP/CESoPSN sur PSN IPv4/IPv6 avec démultiplexage L2TPv3, respectivement.
o	Si le bit C est réglé à 0, l'en-tête RTP apparaît avant le mot de contrôle. Ce mode est décrit comme vieux mode d'encapsulation SAToP/CESoPSN sur L2TPv3 dans l'Appendice A de la [RFC4553] et l'Appendice C de la [RFC5086], respectivement.

PT est le type de charge utile attendu dans l'en-tête RTP. Une valeur de 0 indique que le receveur ne devra pas vérifier le type de charge utile pour détecter des paquets mal formés.

La Fréquence d'horloge d'horodatage est la fréquence d'horloge utilisée pour l'horodatage en unités de 8 kHz.

SSRC indique la valeur attendue de l'identifiant de source de synchronisation (SSRC) dans l'en-tête RTP. Un 0 dans ce champ signifie que l'identifiant de SSRC ne va pas être utilisé pour détecter des mauvaises connexions. Comme L2TP fournit un autre mécanisme de sécurité qui utilise des mouchards, si la longueur de mouchard est supérieure à 0, le SSRC DEVRAIT être 0.

 	2.3	Changements dans les AVP de gestion de connexion de contrôle
Les connexions de contrôle qui prennent en charge les PW en TDM DOIVENT ajouter la ou les valeurs de type de PW appropriées à la liste de l'AVP Capacités de pseudo-filaire. Les valeurs valides sont énumérées au paragraphe suivant.

 	2.4	Changements dans les AVP de gestion de session
L'AVP Type de PW devrait être réglé à une des valeurs suivantes :

1.	Émulation ignorante de la structure [RFC4553] de :
a. circuits E1 - 0x0011
b. circuits T1 (DS1) - 0x0012
c. circuits E3 - 0x0013
d. circuits T3 (DS3) - 0x0014

2.	Émulation tenant compte de la structure [RFC5086] de :
a. CESoPSN en mode de base - 0x0015
b. service CESoPSN spécifique de jonction avec CAS - 0x0017

Les pseudo-filaires en TDM utilisent leur propre mot de contrôle. Donc, l'AVP Spécifique de sous couche de L2 DOIT être omise ou réglée à 0.

Les pseudo-filaires en TDM utilisent leur propre séquençage. Donc, l'AVP Séquençage des données DOIT être omise ou réglée à 0.

Note : Le mot de contrôle (CW, Control Word) utilisé dans les encapsulations SAToP et CESoPSN sur L2TPv3 représente effectivement une sous couche dédiée spécifique de couche 2.

 	3.	Création de la session de pseudo-filaire en TDM

Quand un point d'extrémité de connexion de contrôle L2TP (LCCE, L2TP Control Connection Endpoint) veut ouvrir une session pour un PW en TDM, il DOIT inclure l'AVP PW en TDM (dans tous les cas) et l'AVP RTP (si et seulement si l'en-tête RTP est utilisé) dans le message ICRQ ou OCRQ (Outgoing-Call-Request, demande d'appel sortant). L'homologue LCCE doit valider l'AVP PW en TDM et s'assurer qu'il peut satisfaire les exigences déduites de l'AVP RTP (si elle existe).  Si l'homologue est d'accord avec l'AVP TDM, il va envoyer un message approprié ICRP ou OCRP (Outgoing-Call-Reply, réponse d'appel sortant) avec l'AVP RTP correspondante (si nécessaire). L'initiateur doit valider qu'il peut soutenir les exigences déduites de l'AVP RTP reçue.

Les deux homologues DOIVENT s'accorder sur les valeurs dans l'AVP PW en TDM :

1.	Les valeurs de débit binaire DOIVENT être égales des deux côtés. Si elles sont différentes, la connexion va être rejetée avec le code de résultat 30 et le code d'erreur 1.

2.	Dans le cas de CESoPSN spécifique de jonction avec CAS, le type de jonction (comme codé dans les bits de CAS de l'AVP TDM) DOIT être le même pour les deux côtés. Autrement, la connexion va être rejetée avec le code de résultat de 30 et le code d'erreur de 2.

3.	Si un des côtés ne prend pas en charge la valeur d'octets de charge utile proposée par l'autre, la connexion va être rejetée avec le code de résultat de 30 et le code d'erreur de 3.

4.	Si un côté ne peut pas envoyer l'en-tête RTP comme demandé par l'autre côté, la connexion va être rejetée avec le code de résultat de 30 et le code d'erreur de 4.

5.	Si un côté peut envoyer l'en-tête RTP mais pas avec la fréquence d'horloge d'horodatage demandée, la connexion va être rejetée avec le code de résultat de 30 et le code d'erreur de 5.

Si la signalisation CE pour un PW CESoPSN de base est transportée dans une instance séparée de PW, alors, les deux instances de PW :
1.	DOIVENT utiliser le même type de PW.
2.	DOIVENT utiliser les mêmes valeurs dans tous les champs de l'AVP TDM à l'exclusion du champ SP, qui doit être réglé à "01" pour le PW de données en TDM et à "10" pour le PW portant la signalisation d'application de CE.
3.	DOIVENT tous deux utiliser ou ne pas utiliser l'en-tête RTP (et, en conséquence, inclure ou ne pas inclure l'AVP RTP).

 	4.	Considérations relatives à l'IANA

L'IANA a alloué les valeurs suivantes conformément au présent document :

Nouveaux types de pseudo-filaires L2TPv3 :
0x0011 - circuit E1 ignorant de la structure
0x0012 - circuit T1 (DS1) ignorant de la structure
0x0013 - circuit E3 ignorant de la structure
0x0014 - circuit T3 (DS3) ignorant de la structure
0x0015 - mode de base CESoPSN
0x0017 - CESoPSN en TDM avec CAS

Noter que les valeurs mentionnées correspondent aux valeurs définies dans la [RFC4446] pour les types de pseudo-filaire MPLS.

Nouveaux identifiants de paire d'attribut-valeur :
  99 - AVP Pseudo-filaire en TDM
100 - AVP RTP

Nouveaux codes de résultat pour le message CDN :

30 - code de résultat pour indiquer que la connexion a été refusée à cause des paramètres de PW en TDM. Le code d'erreur indique le problème.

Nouveaux codes d'erreur spécifiques de PW en TDM, à utiliser avec le code de résultat 30 pour le message CDN :

C'est un nouveau registre à tenir par l'IANA dans les valeurs d'AVP Code de résultat (type d'attribut 1). Des valeurs supplémentaires peuvent être allouées sur revue d'expert [RFC5226].

0 - Réservé.
1 - Valeur de débit binaire en désaccord.
2 - Types de jonction différents dans le cas de CESoPSN spécifique de jonction avec CAS.
3 - Taille de charge utile demandée trop grosse ou trop petite.
4 - L'en-tête RTP ne peut pas être généré.
5 - La fréquence d'horloge d'horodatage demandée ne peut pas être générée.

 	5.	Contrôle d'encombrement

Les considérations d'encombrement provenant des [RFC4553] et [RFC5086] s'appliquent respectivement aux modes ignorant de la structure et CESoPSN de la présente spécification.

 	6.	Considérations sur la sécurité

Le présent document spécifie seulement le plan de contrôle fondé sur L2TPv3 pour l'établissement de pseudo-filaires en TDM. Dans ces limites, il n'y a pas de considérations de sécurité supplémentaires à celles discutées dans la [RFC3931].

Les considérations de sécurité de plan des données communes pour les PW en TDM on été discutées dans un certain détail dans les [RFC4553] et [RFC5086]. Par dessus cela, le plan de données fondé sur L2TPv3 fournit des mécanismes de sécurité supplémentaires fondés sur l'usage de mouchards.

 	7.	Remerciements

Les auteurs tiennent à remercier Carlos Pignataro, Ignacio Goyret, et Yaakov Stein de leur relecture attentive et de leurs utiles suggestions.

 	8.	Références
 	8.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. DOI 10.17487/RFC2119, (MàJ par RFC8174)

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

[RFC4553]	A. Vainshtein et autres, "Multiplexage de paquet à répartition dans le temps ignorant la structure (SAToP)", juin 2006. (P.S.)

[RFC5086]	A. Vainshtein et autres, "Service d'émulation de circuit multiplexé par répartition dans le temps (MRT) en fonction de la structure sur un réseau à commutation de paquets (CESoPSN)", décembre 2007. (Information)

 	8.2	Références pour information

[RFC4446]	L. Martini, "Allocations de l'IANA pour l'émulation de bord à bord pseudo filaire (PWE3)", avril 2006. (BCP0116)

[RFC5087]	Y(J). Stein et autres, "Multiplexage à répartition dans le temps sur IP (TDMoIP)", décembre 2007. (Information)

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

[RFC5287]	A. Vainshtein, Y(J). Stein, "Extensions au protocole de contrôle pour l'établissement de pseudo filaires à multiplexage à répartition dans le temps (MRT) dans les réseaux MPLS", août 2008. (P.S.)

 	Adresse des auteurs

Alexander Vainshtein	Sharon Galtzur	
ECI Telecom	Rebellion Inc.	
30 ha-Sivim St. PO Box 500	29 The Chilterns, Gloucester Green,	
Petah-Tiqva 49517	Oxford, OX1 2DF, UK	
Israel	mél : sharon.galtzur@rebellion.co.uk	
mél : Alexander.Vainshtein@ecitele.com