Groupe de travail Réseau	P. Calhoun, Black Storm Networks	
Request for Comments : 3308	W. Luo, Cisco Systems, Inc.	
Catégorie : En cours de normalisation	D. McPherson, TCB	
	K. Peirce, Malibu Networks, Inc.	
Traduction Claude Brière de L’Isle	novembre 2002	

Extension Services différenciés au protocole de tunnelage de couche 2 (L2TP)

Statut de ce mémoire
Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître 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 (2002). Tous droits réservés.

Résumé
Le présent document décrit les mécanismes qui permettent au protocole de tunnelage de couche 2 (L2TP, Layer Two Tunneling Protocol) de négocier le code de comportement par bond (PHB, Per Hop Behavior) désiré pour la connexion de contrôle L2TP, ainsi que pour les sessions individuelles au sein d’un tunnel L2TP.

L2TP fournit une méthode standard pour tunneler les paquets PPP. La spécification actuelle ne comporte aucune disposition pour la prise en charge des services différenciés (diffserv, DS) sur la connexion de contrôle L2TP ou sur les sessions de données suivantes. Il en résulte qu’aucun mécanisme standard n’existe actuellement au sein de L2TP pour assurer les négociations de protocole L2TP pour la discrimination de service.

Table des Matières
1. Spécification des exigences	1
2. Introduction	2
3. Fonctionnement de la connexion de contrôle	2
3.1 AVP Connexion de contrôle DS (SCCRQ, SCCRP)	2
4. Fonctionnement de la session	3
4.1 AVP DS de session (ICRQ, ICRP, OCRQ, OCRP)	3
5. Corrélation des AVP DS	4
6. Codage PHB	4
7. Choix de DSCP	4
8. Réarrangement de paquet et numéros de séquence	4
9. Franchissement des frontières de services différenciés	5
10. Considérations en rapport avec l’IANA	5
11. Considérations pour la sécurité	5
12. Remerciements	5
13. Références	5
14. Adresse des auteurs	6
15. Déclaration complète de droits de reproduction	6

1.	Spécification des exigences

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC2119].

2.	Introduction

La spécification L2TP ne fournit pas actuellement de mécanisme pour la prise en charge des services différenciés (diffserv, DS). Le présent document décrit les mécanismes qui permettent à L2TP d’indiquer le code de PHB désiré, comme défini dans la [RFC3140], à associer à une connexion de contrôle L2TP, ainsi que comme sessions individuelles au sein d’un tunnel L2TP.
L’interprétation réelle du bit DS sort du domaine d’application du présent document, et est délibérément omise. Le présent document n’est concerné que par la définition d’un mécanisme d’échange uniforme et de la transposition subséquente pour les paires de valeurs d'attributs (AVP, attribute value pair) DS.

3.	Fonctionnement de la connexion de contrôle

Comme défini dans la [RFC2661], une connexion de contrôle fonctionne dans la bande sur un tunnel pour contrôler l’établissement, la libération et la maintenance des sessions et du tunnel lui-même. À ce titre, le présent document fournit un mécanisme pour permettre la discrimination des messages de contrôle L2TP des autres paquets. À cette fin, on introduit la paire de valeurs d’attribut (AVP, Attribute Values Pair) Connexion de contrôle de services différenciés (CCDS, Control Connection DS).

La présence de l’AVP CCDS sert d’indication à l’homologue (LAC ou LNS) que l’initiateur du tunnel souhaite que l’initiateur et la terminaison du tunnel utilisent tous deux le ou les comportements par bond (PHB, per-hop behavior) indiqués par le code PHB de l’AVP pour tous les paquets au sein de la connexion de contrôle du tunnel. Un PHB est une description du comportement de transmission observable en externe d’un nœud DS appliqué à un agrégat de comportement DS particulier, comme défini dans la [RFC2475]. L’exemple le plus simple de PHB est celui qui garantit une allocation minimale de bande passante d’une liaison à un agrégat de comportement.

À réception d’une demande de début de connexion de contrôle (SCCRQ, Start-Control-Connection-Request) qui contient l’AVP CCDS, si la terminaison de tunnel n’assure pas la prise en charge de l’AVP CCDS  ; elle DOIT ignorer l’AVP et envoyer une réponse SCCRP (Start-Control-Connection-Reply) à l’initiateur du tunnel sans l’AVP CCDS. L’initiateur du tunnel interprète l’absence de l’AVP CCDS dans la SCCRP comme l’indication que la terminaison de tunnel est incapable d’accepter la CCDS.

À réception d’une SCCRP qui ne contient pas d’AVP CCDS en réponse à une SCCRQ qui contenait une AVP CCDS, si l’initiateur du tunnel veut continuer l’établissement du tunnel, il envoie un Début de connexion de contrôle connectée (SCCCN, Start-Control-Connection-Connected). Autrement, il envoie un StopCCN à la terminaison de tunnel pour fermer la connexion. Le message de contrôle StopCCN DOIT contenir le code de résultat 8 qui indique la valeur d’AVP CCDS (47) comme raison de l’envoi du StopCCN.

Si la terminaison de tunnel fournit la prise en charge de CCDS, elle DEVRAIT utiliser l’AVP Nom d’hôte incorporée dans la SCCRQ pour consulter sa politique locale, et pour déterminer si celle-ci permet que soit utilisé le code de PHB demandé sur cette connexion de contrôle. Si elle ne veut pas ou ne peut pas prendre en charge le code de PHB demandé après consultation de la politique locale, la terminaison de tunnel DOIT envoyer un message de contrôle SCCRP contenant une AVP CCDS indiquant la valeur qu’elle veut utiliser. Si la valeur de l’AVP CCDS est la même que celle de la SCCRQ, elle signale l’acceptation du code de PHB demandé. Si la valeur est différente, elle sert de contre offre de la part de la terminaison de tunnel.

Si l’initiateur du tunnel reçoit une SCCRP qui contient une AVP CCDS avec une valeur autre que celle demandée dans la SCCRQ, l’initiateur du tunnel DEVRAIT vérifier le code de PHB à l’égard de sa propre politique. Si il ne veut pas utiliser la valeur, l’initiateur du tunnel DOIT envoyer un message de contrôle StopCCN contenant le code de résultat 8 qui indique la valeur d’AVP CCDS (47) comme raison de l’envoi du StopCCN.

3.1	AVP Connexion de contrôle DS (SCCRQ, SCCRP)

L’AVP CCDS est codée comme identifiant de fabricant 0, et le type d’attribut est 47.
Chaque AVP CCDS est codé comme suit :
Identifiant de fabricant = 0
Attribut = 47

    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|0|0|0|0|    Longueur       |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              47               |         Code de PHB           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Cette AVP PEUT être présente dans les types de message suivants : SCCRQ et SCCRP. Cette AVP PEUT être cachée (le bit H réglé à 0 ou 1) et est facultatif (le bit M à zéro). La longueur de cette AVP (avant de la cacher) DOIT être 8 octets. Le codage du code de PHB est décrit à la Section 6.

4.	Fonctionnement de la session

Comme défini dans la [RFC2661], une session L2TP est en mode connexion. Le LAC et le LNS conservent les états pour chaque appel qui est initié ou auquel répond un LAC. Une session L2TP est créée entre le LAC et le LNS lorsque est établie une connexion de bout en bout entre un système distant et le LNS. Les datagrammes qui se rapportent à la connexion sont envoyés sur le tunnel entre le LAC et le LNS. À ce titre, le présent document fournit un mécanisme pour permettre la discrimination des paquets au sein d’une session particulière de ceux d’autres sessions. À cette fin, on introduit l’AVP Session DS (SDS).

La présence de l’AVP SDS sert d’indication à l’homologue (LAC ou LNS) que l’initiateur de la session souhaite que l’initiateur et la terminaison de la session utilisent tous deux le ou les comportements bond par bond (PHB) indiqués par le code de PHB de l’AVP pour tous les paquets de la session.

À réception d’une demande d’appel entrant (ICRQ, Incoming-Call-Request) ou d’une demande d’appel sortant (OCRQ, Outgoing-Call-Request) contenant l’AVP SDS, si la terminaison de session ne prend pas en charge le code de PHB demandé, la terminaison de session DOIT ignorer l’AVP SDS et envoyer une ICRP ou OCRP à l’initiateur de la session sans l’AVP SDS. L’initiateur de la session interprètera l’absence de l’AVP SDS dans l’ICRP ou OCRP comme une indication que l’initiateur de la session est incapable de prendre SDS en charge.

À réception d’une ICRP ou OCRP qui ne contient pas d’AVP SDS en réponse à une ICRQ ou OCRQ qui en contenait une, si l’initiateur de la session veut omettre l’emploi de l’AVP SDS, il va continuer l’établissement de session comme défini dans la [RFC2661]. Autrement, il enverra une notification d'appel déconnecté (CDN, Call Disconnect Notification) à la terminaison de session pour mettre un terme à la connexion. Le message de contrôle CDN DOIT contenir le code de résultat 12 qui indique la valeur d’AVP SDS (48) comme raison de l’envoi de la CDN.

Afin d’aider la terminaison de session à distinguer une session d’une autre lorsque elle consulte la politique locale du code de PHB, l’initiateur de la session PEUT utiliser l’identifiant ou une combinaison d’identifiants incorporés dans les AVP comme une AVP Nom de mandataire authentifié, AVP Numéro d’appelant, AVP Numéro d’appelé et AVP de sous-adresse. Lorsque l’AVP Nom de mandataire authentifié est utilisée pour la distinction, elle DEVRAIT être présente dans l’ICRQ ou l’OCRQ. Le ou les identifiants DS désignés utilisés pour rechercher le code de PHB DEVRAIENT être configurables.

Si la terminaison de session fournit la prise en charge de SDS, elle DEVRAIT utiliser l’AVP Identification DS désignée (via un accord hors bande entre les administrateurs du LAC et du LNS) pour consulter la politique locale et déterminer si elle permet d’utiliser le code de PHB demandé sur cette session. Si elle ne veut pas ou n’est pas capable de prendre en charge le code de PHB demandé, la terminaison de session DOIT faire une des actions suivantes :
1)	envoyer un message CDN contenant le code de résultat 12 qui indique la valeur d’AVP SDS (48) comme raison de l’envoi de la CDN  :.
2)	envoyer un message Réponse d’appel entrant (ICRP) ou réponse d’appel sortant (OCRP) contenant une AVP SDS indiquant le code de PHB que la terminaison veut utiliser pour la session.

Si la terminaison de session prend en charge le code de PHB dans l’AVP SDS, l’établissement de session DOIT continuer comme défini dans la [RFC2661].

Si l’initiateur de session reçoit une ICRP ou OCRP qui contient une AVP SDS avec une valeur autre que celle demandée dans l’ICRQ ou l’OCRQ, et si l’initiateur de la session ne veut pas utiliser cette valeur, l’initiateur de la session DOIT envoyer un message CDN contenant le code de résultat 12 qui indique la valeur de l’AVP SDS (48) comme raison de l’envoi de la CDN. Si l’initiateur de la session reçoit une ICRP ou OCRP qui contient une AVP SDS avec une valeur autre que celle demandée dans l’ICRQ ou l’OCRQ, et si l’initiateur de la session veut utiliser cette valeur, l’initiateur de la session DOIT procéder comme indiqué dans la [RFC 2661].

4.1	AVP DS de session (ICRQ, ICRP, OCRQ, OCRP)

L’AVP SDS est codé comme Identifiant de fabricant 0, et la valeur d’attribut est 48.

Chaque AVP SDS est codé comme suit :
Identifiant de fabricant = 0
Attribut = 48

    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|0|0|0|0|    Longueur       |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              48               |       Code de PHB             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Cette AVP PEUT être présente dans les types de message suivants : ICRQ, ICRP, OCRQ et OCRP. Cette AVP PEUT être cachée (le bit H réglé à 0 ou 1) et est facultative (le bit M n’est pas réglé à 0). La longueur de cette AVP (avant d’être cachée) DOIT être 8 octets. Le codage du code de PHB est décrit à la Section 6.

5.	Corrélation des AVP DS

Les AVP CCDS et SDS sont indépendantes l’une de l’autre. L’AVP CCDS est utilisée pour signaler diffserv pour la connexion de contrôle entre deux homologues L2TP, tandis que l’AVP SDS est utilisée pour la connexion des données. Le code de PHB signalé dans une AVP NE DEVRAIT PAS avoir d’implication sur le code de PHB signalé dans l’autre AVP. Les mises en œuvre PEUVENT choisir d’appliquer soit l’une ou l’autre AVP DS, soit les deux, et le fonctionnement PEUT choisir d’activer diffserv sur l’une ou l’autre, soit sur les deux types de connexions.

6.	Codage PHB

Le code de PHB est un champ de 16 bits justifié à gauche qui utilise le codage de comportement par bond (PHB) défini dans la [RFC3140]. Noter que la [RFC3140] et ses successeurs sont l’autorité ultime pour définir le codage de PHB.

À la réussite de l’établissement d’une connexion de contrôle de tunnel L2TP ou d’une session individuelle L2TP employant l’AVP DS appropriée définie dans le présent document, le LAC et le LNS DOIVENT tous deux utiliser leurs propres transposition de PHB en DSCP de leurs domaines DS présents pour transposer le PHB en un DSCP et le placer dans le champ DS de l’en-tête IP externe des paquets transmis sur la connexion.

7.	Choix de DSCP

Les exigences ou règles de chaque service et la transposition en DSCP sont établies par des mécanismes de politique administrative qui sortent du domaine d’application du présent document.

8.	Réarrangement de paquet et numéros de séquence

La [RFC2474] RECOMMANDE que les mises en œuvre de PHB ne causent pas de réarrangement des paquets au sein d’une connexion individuelle. La [RFC3140] exige qu’un ensemble de PHB signalé comme utilisant un seul identifiant de PHB NE DOIT PAS causer de réarrangement de paquet supplémentaire au sein d’une connexion individuelle par rapport à l’utilisation d’un seul PHB. Comme les AVP CCDS et SDS contiennent un identifiant de PHB, l’utilisation de PHB diffserv conformément à la présente spécification ne devrait pas causer de réarrangement de paquet supplémentaire au sein d’une connexion de contrôle ou de données L2TP.

Il est exigé que des numéros de séquence soient présents dans tous les messages de contrôle et qu’ils soient utilisés pour fournir une livraison fiable sur la connexion de contrôle, comme défini dans la [RFC2661]. Bien que le réarrangement des paquets soit inévitablement une fonction du réseau beaucoup plus que du conditionnement du trafic local, la probabilité qu’il se produise lorsque on emploie l’AVP CCDS est la même que lorsque on n’emploie pas l’AVP. Les messages de données PEUVENT utiliser des numéros de séquence pour réordonner les paquets et détecter les paquets perdus.

9.	Franchissement des frontières de services différenciés

Avec l’éventualité qu’une connexion L2TP traverse un nombre arbitraire de domaines DS, la signalisation des PHB via L2TP est plus appropriée que la signalisation DSCP, parce qu’elle maintient un service différencié cohérent de bout en bout pour la connexion L2TP. Selon la [RFC2983], les PHB négociés sont transposés en DSCP définis localement du domaine DS en cours au nœud de sortie du tunnel. Au nœuds frontières du domaine DS, les DSCP peuvent être réécrits dans le champ DS de l’en-tête IP externe, de sorte que les DSCP sont toujours en relation avec le domaine dans lequel le paquet se trouve être.

Il en résulte qu’il est parfaitement acceptable que le champ DS le plus externe des paquets qui arrivent sur une certaine connexion ou session de contrôle ne soient pas marqués avec la même valeur de DSCP que celle utilisée par le nœud d’entrée du tunnel.

10.	Considérations en rapport avec l’IANA

Le présent document définit deux AVP d’extension de service différencié L2TP. L’IANA a alloué la valeur de 47 à l’AVP CCDS définie au paragraphe 5.1 et la valeur de 48 à l’AVP SDS définie au paragraphe 6.1.

L’IANA a aussi alloué les valeurs de code de résultat L2TP de 8 aux déconnexions de connexion de contrôle dues aux discordances de valeur de CCDS (StopCCN), et 12 aux déconnexions d’appel dues aux discordances de valeur de SDS (CDN).

11.	Considérations pour la sécurité

Ce codage ne soulève par lui-même aucun problème de sécurité. Cependant, les utilisateurs de ce codage devraient considérer que modifier un DSCP PEUT constituer un vol ou un déni de service, de sorte que les protocoles qui utilisent ce codage DOIVENT être adéquatement protégés. Aucun autre problème de sécurité au delà de ceux exposés dans la [RFC2474] et la [RFC2475] n’est introduit ici.

12.	Remerciements

Merci à David Black, W. Mark Townsley, Nishit Vasavada, Andy Koscinski et John Shriver pour leur relecture et leurs remarques pertinentes.

13.	Références

[RFC1661]	W. Simpson, éditeur, "Protocole point à point (PPP)", STD 51, juillet 1994. (MàJ par la RFC2153)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2474]	K. Nichols, S. Blake, F. Baker et D. Black, "Définition du champ Services différenciés (DS) dans les en-têtes IPv4 et IPv6", décembre 1998. (MàJ par RFC3168, RFC3260) (P.S.)

[RFC2475]	S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang et W. Weiss, "Architecture pour services différenciés", décembre  1998. (MàJ par RFC3260)

[RFC2661]	W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn et B. Palter, "Protocole de tunnelage de couche 2 "L2TP"", (P.S.)

[RFC2983]	D. Black, "Services différenciés et tunnels", octobre 2000. (Information)

[RFC3140]	D. Black et autres, "Codes d'identification de comportement par bond", juin 2001. (P.S.)

14.	Adresse des auteurs

Pat R. Calhoun	Danny McPherson	
110 Nortech Parkway	TCB	
San Jose, CA 95134-2307	téléphone : +1 303.470.9257	
téléphone : +1 408.941.0500	mél : danny@tcb.net 	
mél : pcalhoun@bstormnetworks.com 		

Wei Luo	Ken Peirce	
Cisco Systems, Inc.	Malibu Networks, Inc.	
170 West Tasman Drive	1107 Investment Blvd, Suite 250	
San Jose, CA 95134	El Dorado Hills, CA 95762	
téléphone : +1 408.525.6906	téléphone : +1 916.941.8814	
mél : luo@cisco.com 	mél : Ken@malibunetworks.com 	

15.	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2002). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Remerciement
Le financement de la fonction d’éditeur des RFC est actuellement fourni par la Internet Society.