Groupe de travail Réseau

Protocole de tunnelage de couche 2 (L2TP) :
extensions réseau pour l’accès ATM

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.

Le présent document augmente les procédures décrites dans la RFC2661 pour la prise en charge des réseaux d’accès fondés sur des circuits virtuels commutés (SVC, Switched Virtual Circuit) ou des circuits virtuels permanents (PVC, Permanent Virtual Circuit) ATM. Le protocole de tunnelage de couche 2 (L2TP, Layer 2 Tunneling Protocol) spécifie un protocole pour tunneler les paquets PPP sur des réseaux fondés sur le paquet et sur des réseaux IP en particulier. L2TP prend en charge l’accès distant des réseaux RNIS et RTPC. Les extensions définies dans ce document permettent l’établissement d’appel asymétrique bidirectionnel et la sélection de service dans le réseau d’accès ATM.

Table des Matières

1. Introduction 1

1.1 Conventions 2

2. Hypothèses 2

2.1 Topologie 2

2.2 Établissement de connexion 2

2.3 Négociation LCP 2

3. Procédures améliorées d’accès ATM 2

3.1 Connexité ATM 3

3.2 Établissement de tunnel 3

3.3 Établissement d’appel 3

3.4 Tramage 4

4. Problèmes du modèle de service 4

4.1 Authentification 4

4.2 Autorisation 4

5. AVP nouveaux et étendus 5

5.1 Résumé des nouveaux AVP 5

5.2 Nouvelle définition d’AVP 5

5.3 AVP à définition changée 7

6. Considérations en rapport avec l’IANA 10

7. Considérations pour la sécurité 10

8. Remerciements 10

9. Références 10

10. Adresse des auteurs 11

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

L2TP [RFC2661] définit les procédures pour tunneler les sessions PPP entre ce qu’on appelle un concentrateur d’accès L2TP (LAC, L2TP Access Concentrator) et un serveur de réseau L2TP (LNS, L2TP Network Server). Le principal objet de la [RFC2661] est la prise en charge de réseaux d’accès HDLC fondés sur le RNIS/RTPC.

Le présent document augmente les procédures décrites dans la [RFC2661] pour prendre aussi en charge les réseaux d’accès ATM fondés sur le SVC ou PVC. La prise en charge des réseaux d’accès ATM exige des extensions aux procédures L2TP présentes afin de traiter :

(a) les aspects de gestion de trafic des connexions ATM (par exemple, les capacités d’allocation asymétrique de bande passante et de sélection de catégorie de service),

(c) les limitations imposées à la négociation de LCP par le transport de PPP sur AAL5 sur le segment de réseau d’accès de la connexion PPP [RFC2364].

Au sein de ce document, les extensions nécessaires à la [RFC2661] sont définies de façon à régler les questions (a) et (b), la question (c) qui n’est pas spécifique d’ATM peut se résoudre comme décrit dans la [RFC3437].

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

Dans cette section, on décrit les hypothèses qui ont conduit aux extensions décrites dans le présent document.

Les procédures décrites dans la [RFC2661] s’appliquent principalement à la technologie d’accès au réseau comme le RTPC et le RNIS, qui peuvent être respectivement fondées sur le HDLC asynchrone et synchrone. Le but de ce document est d’étendre la prise en charge de L2TP à permettre la communication d’usager/LAC fondée sur la technologie de réseau d’accès ATM.

Du fait de la grande variété des protocoles de signalisation existants et des catégories de service ATM, et de leur prise en charge ou non au sein des réseaux d’accès fondés sur ATM, le présent document prend l’approche de fournir une identification souple des caractéristiques de la connexion ATM tout en établissant des appels L2TP sortants et entrants. La procédure telle que définie au sein du présent document permet l’allocation de bande passante asymétrique et le choix de catégories de service en termes d’exigences de temps réel ou de différé sur la portion ATM du réseau d’accès.

À ce titre, les éléments d’information spécifiques du protocole de signalisation détaillés qui sont nécessaires pour le service de circuits virtuels commutés sont explicitement non négociés durant l’établissement d’appel sur le tunnel L2TP.

Afin d’identifier le point d’extrémité de la connexion ATM au sein du réseau d’accès ATM, les SVC peuvent être établis sur la base du format d’adressage de système d’extrémité ATM (AESA, ATM end system addressing format) [AESA]. Pour les services fondés sur le PVC, on peut se référer à celui-ci en utilisant la procédure d’adressage de système d’extrémité ATM (numéro appelé/appelant) ou en utilisant un nom textuel (nom de service). Ce dernier est inspiré par les procédures définies dans [Auto_PVC].

Les procédures décrites dans ce document peuvent être combinées avec les procédures décrites dans la [RFC3437] pour limiter la négociation de LCP entre LNS et usager, afin de mettre en application la négociation de LCP spécifique de PPP sur AAL5 [RFC2364].

Pour illustrer les procédures spécifiées dans le présent document, cette section donne une description du fonctionnement de l’accès virtuel par numérotation à travers un réseau d’accès fondé sur ATM (par exemple, ADSL).

Noter que l’accent est mis sur les changements proposés dans le présent document par rapport à la [RFC2661].

Avant d’initier la couche de protocole PPP, une connexion virtuelle (VC, Virtual Connection) DOIT être établie entre l’usager et le serveur d’accès réseau (LAC, Network Access Server). Cette connexion virtuelle PEUT être un circuit virtuel préconfiguré permanent (PVC, preconfigured Permanent VC) où le fournisseur de réseau d’accès, le NAS et l’usager s’accordent à l’avance sur les caractéristiques du PVC, ou PEUT être un circuit virtuel commuté (SVC, switched VC) à la demande où la négociation entre usager, réseau et NAS a lieu au moyen d’un protocole de signalisation ATM. Noter que pour établir des PVC, une autre utilisation peut être faite des procédures comme décrit dans [Auto_PVC].

Dans les deux cas, l’usager est désigné comme appelant virtuel (virtual dial-in user).

Avant d’accepter la connexion commutée provenant de l’appelant virtuel, le LAC PEUT vérifier avec le LNS si l’appel devrait être accepté. Dans cette dernière situation, le LAC PEUT déterminer sur la base des paramètres disponibles dans le message d’établissement d’appel que cela concerne un appelant virtuel, ou il PEUT entreprendre une authentification partielle du système/usager d’extrémité, afin de lier le système/usager d’extrémité avec un LNS spécifique.

Pour les usagers fondés sur le PVC, le LAC PEUT être déclanché par l’arrivée d’un message Demande de configuration de LCP, ou Demande d’authentification PPP provenant de l’appelant virtuel pour initier la conversation avec le LNS. Noter que le moment exact du déclanchement de la communication entre le LAC et le LNS sort du domaine d’application de ce document.

Si aucun tunnel de connexion n’existe actuellement pour le LNS désiré, il en est initié un. Durant l’établissement du tunnel, LNS et LAC indiquent les capacités de support et de tramage de l’un et de l’autre, conformément aux procédures normales.

La prise en charge de capacité est étendue pour permettre au LAC d’indiquer sa prise en charge des appareils support d’ATM. La réception de cette indication positive permet au LAC et au LNS d’utiliser tous deux les extensions comme défini dans le présent document pour prendre en charge les appels entrants et sortants fondés sur ATM.

Si il n’existe aucune compatibilité entre LNS et LAC selon les extensions définies dans ce document, aucun établissement de tunnel ne peut avoir lieu. Cela serait parce que le LAC ne prend pas en charge de capacité support qui soit attendue par le LNS (par exemple, un LAC fondé sur ATM qui ne signale que la capacité support "large bande") ou vice versa. Il est cependant encouragé que les mises en œuvre de LAC ou de LNS permettent un inter fonctionnement en douceur avec les appareils homologues qui ne mettent pas en œuvre les extensions définies dans ce document. Cela pourrait être mis en œuvre en permettant un retour en douceur à la capacité support numérique.

Durant l’établissement d’un appel large bande entrant et sortant, les extensions suivantes aux procédures existantes sont définies.

La connexion ATM entre l’appelant virtuel et le LAC PEUT être établie de façon dynamique ou statique. Lorsque la connexion de VC est établie dynamiquement (VC commuté) le LAC va recevoir un message SETUP sur l’interface qui le connecte au réseau ATM. La présente spécification ne suppose aucun type spécifique d’interface (UNI ou NNI). Les connexions de VC permanent PEUVENT être configurées manuellement, ou en utilisant les extensions à la procédure ILMI définies par [Auto_PVC].

Pour les connexions de VC commuté, le LAC PEUT choisir le LNS homologue sur la base des informations d’établissement de connexion, ou en permettant l’authentification PPP partielle de l’appelant virtuel. Les informations d’établissement de connexion qui peuvent être utilisées par le LAC incluent l’AESA d’appelé, la sous-adresse d’AESA d’appelé, l’AESA d’appelant ou la sous-adresse d’AESA d’appelant.

Pour les connexions de VC permanent, le LAC PEUT être déclanché par (a) l’établissement du PVC, (b) une demande de configuration de LCP, (c) l’authentification partielle de l’appelant virtuel, ou (d) des moyens sortant du domaine d’application de cette spécification.

Au sein de l’ICRQ (Demande d'appel entrant), le LAC DOIT indiquer un support large bande dans l’AVP Type de support (bit B réglé à 1), PEUT inclure l’AVP Catégorie de service, et PEUT inclure l’AVP Nom de service. Si le LNS ne prend pas en charge le bit B Support, il va retourner une erreur au message ICRQ. Dans un tel cas, la mise en œuvre PEUT décider de revenir à la capacité support numérique, et DEVRAIT s’empêcher d’utiliser les extensions définies dans ce document. De plus, le message ICRQ PEUT contenir l’AVP Identifiant de VPI/VCI. Cet identifiant peut encore être utilisé au LNS pour des besoins de gestion après ou en remplacement de l’AVP Identifiant de canal physique.

Dans l’ICCN (Appel entrant connecté), l’AVP Vitesse de connexion en émission et Vitesse de connexion en réception DEVRAIENT toutes deux être utilisées si une connexion asymétrique a été établie.

Au sein d’une OCRQ (Demande d'appel sortant), le LNS DOIT indiquer au LAC les vitesses minimum et maximum pour recevoir et transmettre le trafic (du point de vue du LAC). Ceci est destiné à permettre la nature bidirectionnelle asymétrique des contrats de trafic ATM. Noter qu’afin de prendre en charge des connexions UBR entre LAC et usager, le BPS (bits par seconde) minimum DOIT être réglé à zéro.

De plus, durant l’OCRQ, le LNS PEUT inclure l’AVP Catégorie de service requise, c’est-à-dire, qui indique les services de transport en temps réel (rt) ou en différé (nrt, non-real time). La combinaison des vitesses minimum et maximum de réception et de transmission, et l’indication de la catégorie de service requise permet au LAC d’établir une connexion ATM selon ses propres capacités, et les capacités du réseau d’accès ATM, dans les limites des exigences de service de la couche PPP.

La connexité en temps réel peut être fournie par les catégories de service ATM CBR ou rt-VBR, la connexité en différé peut être fournie par les catégories de service ATM UBR, nrt-VBR, ABR ou GFR.

De plus, le LNS DOIT indiquer au LAC dans le message OCRQ le numéro appelé selon le format décrit dans ce document (format de point d'accès au service réseau (NSAP, Network Service Access Point). Lorsque le numéro appelé porte une charge utile toute de zéros, le LAC DEVRAIT chercher l’AVP Nom de service pour lier l’appel en tunnel à une connexion de VC ATM.

Après les AVP normales, le message OCRP PEUT contenir l’AVP Identifiant de VPI/VCI. Cet identifiant peut encore être utilisé chez le LNS pour des besoins de gestion après ou en remplacement de l’AVP Identifiant de canal physique.

Dans le présent document, la PDU PPP se réfère à l’enchaînement des champs Identifiant de protocole PPP, Informations PPP et Bourrage PPP.

Dans la direction usager à LNS, la PDU PPP sera portée par dessus une connexion AAL5 entre l’usager et le LAC. Le LAC DOIT supprimer les champs spécifiques de AAL5 sur la base du mécanisme d’encapsulation utilisé sur la connexion ATM, c’est-à-dire du VC multiplexé ou LLC encapsulé [RFC2364], et DOIT encapsuler la PDU PPP avec les champs Adresse et Contrôle, conformément aux procédures HDLC, sur le tunnel L2TP.

Dans la direction LNS à usager, la PDU PPP sera portée par dessus une connexion AAL5 entre LAC et usager. Le LAC DOIT supprimer la PDU PPP des champs Adresse et Contrôle sur le tunnel L2TP, et insérer les champs spécifiques de AAL5 sur la base du mécanisme d’encapsulation utilisé sur la connexion ATM, c’est-à-dire VC multiplexé ou LLC encapsulé.

En cas d’établissement d’un VC commuté ATM, les informations sur le numéro de l’appelant peuvent être utilisées pour le premier niveau d’authentification tout à fait comme pour l’accès au RTPC ou au RNIS. Dans le cas d’établissement de VC permanent, l’authentification peut n’être pas un problème du côté du LAC, à cause du caractère permanent du VC. Un accord bilatéral entre les fournisseurs du LAC et du LNS peut éliminer la phase d’authentification dans ce dernier cas.

À cause de la souplesse de l’établissement des connexions ATM avec divers paramètres, une autorisation peut être nécessaire avant d’accepter l’établissement d’une connexion ATM commutée à l’usager avec certains paramètres de trafic ATM. Cette autorisation peut être effectuée à l’égard des informations d’authentification spécifiques d’ATM (par exemple, l’identifiant de la ligne appelante) ou peut être effectuée après l’authentification partielle de l’usager au niveau PPP. Les demandes d’accès non autorisées résultent en la libération de la connexion.

Le Tableau qui suit fait la liste des AVP supplémentaires qui sont définies dans ce document. La colonne "attribut" indique la valeur d’entier allouée à cet attribut. Noter que la valeur de l’attribut est relative par rapport à l’identifiant de fabricant. La colonne "M" indique le réglage du bit "Obligatoire" de l’en-tête d’AVP pour chaque attribut. La colonne "Longueur" indique la taille de l’AVP incluant l’en-tête d’AVP. Un "+" dans cette colonne indique que la longueur varie selon la longueur du contenu réel du champ de valeur.

La liste d’usage pour chaque entrée indique les types de message qui utilisent chaque AVP. Une abréviation en lettres majuscules ou un mélange de majuscules et minuscules indique que l’AVP correspondante DOIT être présente dans ce type de message. Une abréviation toute en minuscules indique que l’AVP PEUT facultativement apparaître dans ce type de message. Certaines AVP PEUVENT n’être présentes que lorsque est présente une AVP facultative correspondante ou un réglage spécifique au sein de l’AVP ; ces AVP sont aussi présentées en minuscules.

Entier de 32 bits indiquant la plus faible vitesse de ligne acceptable pour l’appel dans la direction réception. Rx indique la direction usager vers LAC.

Entier de 32 bits indiquant la plus forte vitesse de ligne acceptable pour l’appel dans la direction réception. Rx indique la direction usager vers LAC

La catégorie de service indique le service attendu pour l’appel, par exemple, temps réel ou différé.

Sous adresse NSAP de 20 octets codée en binaire qui indique la sous-adresse de l’appelant.

Identification de 10 octets codée en binaire des valeurs de VPI/VCI utilisées pour les appels entrants.

Voici la liste des nouvelles AVP définies dans le présent document, et la description des comportements attendus lorsque ces AVP sont présentes dans un message.

Type d’attribut 40, code la plus faible vitesse de ligne acceptable pour cet appel dans la direction réception, pour les cas où la transmission asymétrique est exigée.

Le BPS Minimum en réception est une valeur de 32 bits qui indique la vitesse en bits par seconde.

Cette AVP PEUT être incluse dans l’OCRQ, et DEVRAIT n’être incluse que lorsque le LAC a indiqué la prise en charge du support large bande dans l’AVP Capacités du support durant l’établissement du canal.

Cette AVP peut être cachée (le bit H peut être réglé à 0 ou 1). Le bit M pour cette AVP doit être réglé à 0. La longueur (avant de la cacher) de cette AVP est 10.

Type d’attribut 41, code la plus forte vitesse de ligne acceptable pour cet appel dans la direction réception, pour les cas où la transmission asymétrique est exigée.

Le BPS maximum en réception est une valeur de 32 bits qui indique la vitesse en bits par seconde.

Cette AVP PEUT être incluse dans l’OCRQ, et DEVRAIT n’être incluse que lorsque le LAC a indiqué la prise en charge d’un support large bande dans l’AVP Capacités du support durant l’établissement du tunnel.

Cette AVP peut être cachée (le bit H peut être réglé à 0 ou 1). Le bit M pour cette AVP doit être réglé à 0. La Longueur (avant d’être caché) de cette AVP est 10.

L’AVP Catégorie de service, de type d’attribut 42, indique des informations supplémentaires facultatives sur la qualité de service attendue pour l’établissement d’appel sur le support à large bande.

Le champ Valeur d’attribut est un gabarit de 16 bits, avec un seul bit défini. Le bit S bit indique l’exigence de service soit en différé (bit S réglé à 0) soit en temps réel (bit S à 1). Les autres champs de bits sont réservés pour une utilisation future.

L’AVP Catégorie de service PEUT être présente dans les messages OCRQ et ICRQ, et DEVRAIT n’être incluse que lorsque le LAC a indiqué la prise en charge du support en large bande dans l’AVP Capacités du support durant l’établissement du tunnel.

Cette AVP peut être cachée (le bit H peut être réglé à 0 ou 1). Le bit M pour cette AVP doit être réglé à 0. La longueur de cette AVP (avant d’être cachée) est 8.

L’AVP Nom de service, de type d’attribut 43, fournit à l’homologue un nom textuel pour se référer à une connexion de VC ATM.

Le nom de service a une longueur arbitraire, mais doit faire au moins 1 octet. Le nom de service est codé en UTF-8 [10646]

L’AVP Nom de service NE PEUT être fournie que lorsque le champ Numéro d’appelant est codé tout en zéros dans la OCRQ. L’AVP Nom de service PEUT être présente dans les messages OCRQ et ICRQ, et DEVRAIT n’être incluse que lorsque le LAC a indiqué la prise en charge d’un support large bande dans l’AVP Capacités du support durant l’établissement du tunnel.

Cette AVP peut être cachée (le bit H peut être réglé à 0 ou 1). Le bit M pour cette AVP doit être réglé à 0. La longueur de cet attribut est arbitraire, mais cependant d’au moins 7.

L’AVP Sous-adresse de l’appelant a le type d’attribut 44, et code des informations supplémentaires de sous-adresse de l’appelant.

L’AVP Sous-adresse de l’appelant DOIT être codée comme une adresse NSAP de 20 octets codée en binaire lorsque le bit B est établi dans l’AVP Type de support. L’adresse NSAP codée en binaire fournit une gamme plus large de méthodes d’encapsulation d’adresse qu’un champ ASCII. La structure de l’adresse NSAP (par exemple, E.164, ICD, DCC) est définie dans [AESA].

L’AVP Numéro de sous-adresse de l’appelant PEUT être présente dans l’ICRQ, et DEVRAIT n’être disponible que si le numéro de l’appelant est aussi dans le message.

Cette AVP peut être cachée (le bit H peut être réglé à 0 ou 1). Le bit M pour cette AVP doit être réglé à 0. La longueur de cette AVP (avant d’être cachée) est 26.

L’identifiant de VPI/VCI a le type d’attribut 45, et code la valeur de VPI/VCI utilisée à l’interface ATM du LAC.

L’identifiant de VPI/VCI est une valeur de 32 bits qui code la valeur du VPI (12 bits) et du VCI (16 bits).

Cette AVP PEUT être incluse dans l’ICRQ et l’OCRP, et DEVRAIT n’être incluse que lorsque le LAC a indiqué la prise en charge d’un support à large bande dans l’AVP Capacités de support durant l’établissement de tunnel.

Cette AVP peut être cachée (le bit H peut être réglé à 0 ou 1). Le bit M pour cette AVP doit être réglé à 0. La Longueur de cette AVP (avant d’être cachée) est 10.

Les AVP suivantes voient leur contenu changé par rapport à la [RFC2661] afin de prendre en charge les procédures décrites dans le présent document.

L’AVP Capacités du support au sein d’une SCCRQ ou SCCRP indique les capacités du support que l’envoyeur de ce message peut fournir pour les appels sortants. Le présent document étend les AVP existantes avec le bit B. Si le bit B est réglé à 1, l’accès large bande (ATM) est pris en charge.

Les tentatives d’établir un appel sortant avec le type de support réglé à B, alors que la capacité support n’indiquait pas cette capacité résulteront en rejet de l’appel avec le code de résultat 5 "Échec de l’appel à cause du manque de disponibilité des facilités appropriées (condition permanente)".

Dans les cas où le LAC ne prend en charge que le bit B, et où le LNS ne reconnaît pas le bit B, aucun appel sortant n’est possible. Noter que lorsque le LAC a seulement des appareils fondés sur ATM, il peut quand même opter pour un retour en douceur à des types de support numériques.

La présente spécification suppose un LNS non conforme pour catégoriser une AVP Capacités du support où le bit B est établi comme AVP non reconnue, ce qui va faire échouer l’établissement du tunnel. Cela doit être indiqué par un code de résultat "2 – Erreur générale – le code d’erreur indique le problème", Code d’erreur "3 – Le champ Réservé n’était pas à zéro".

L’AVP BPS minimum (en émission) code la plus faible vitesse de ligne acceptable pour cet appel dans la direction d’émission. L’AVP BPS minimum (en émission) PEUT être utilisée dans une OCRQ. Si l’AVP BPS minimum (en émission) telle que définie dans le présent document n’est pas disponible dans le message, la transmission symétrique est alors impliquée, avec les débits binaires minimum de réception et d’émission tous deux égaux au BPS minimum.

L’AVP BPS maximum (en émission) code la plus forte vitesse de ligne acceptable pour cet appel dans la direction d’émission. L’AVP BPS maximum (en émission) PEUT être utilisée dans une OCRQ. Si l’AVP BPS maximum (en émission) telle que définie dans le présent document n’est pas disponible dans le message, la transmission symétrique est alors impliquée, avec les débits binaires maximum de réception et d’émission tous deux égaux au BPS maximum.

L’AVP Type de support code le type de support pour l’appel demandé. Le présent document étend les types de support avec une indication de la prise en charge du support ATM (bit B). Si le bit B est réglé à 1, l’accès large bande (ATM) est demandé. Si le bit A est réglé à 1, l’accès analogique est demandé. Si le bit D est à 1, l’accès numérique est demandé.

Noter que dans une OCRQ, les trois bits (B, A, D) peuvent être réglés à un, ce qui indique que l’appel peut être de l’un ou l’autre type. Le bit B DEVRAIT n’être établi que si la capacité large bande a été indiquée durant l’établissement du tunnel.

Le code de cause n’est pas changé par rapport à la [RFC2661], excepté le fait qu’il peut aussi porter des codes de cause spécifiques des messages de signalisation ATM, ces codes de cause se trouvent dans ATM Forum UNI 4.0 [UNI] et les références qui s’y trouvent. Le code de cause devrait être interprété par rapport au type de support utilisé pour l’appel spécifique.

L’AVP Numéro appelé, type d’attribut 21, code le numéro AESA à appeler pour une OCRQ, et le numéro appelé chez le LAC pour une ICRQ.

Le champ Valeur d’attribut pour cette AVP a un codage changé par rapport à la [RFC2661] :

L’AVP Numéro appelé DOIT être codé comme une adresse NSAP de 20 octets codée en binaire lorsque le bit B est réglé à 1 dans l’AVP Type de support. L’adresse NSAP codée en binaire donne une gamme plus large de méthodes d’encapsulation d’adresse qu’un champ ASCII. La structure de l’adresse NSAP (par exemple, E.164, ICD, DCC) est définie dans [AESA].

L’AVP Numéro appelé DOIT être présente dans l’OCRQ, et PEUT être présente dans l’ICRQ.

Si l’AVP Numéro appelé dans une OCRQ porte une adresse NSAP toute de zéros, l’AVP Nom de service DEVRAIT fournir d’autres informations pour lier l’appel L2TP à une connexion de VC spécifique. Voir aussi [Auto_PVC].

Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être réglé à 0. La longueur de cette AVP (avant d’être cachée) est 26.

L’AVP Numéro appelant, de type d’attribut 22, code l’AESA Appelant comme il est reçu de l’usager virtuel appelant.

L’AVP Valeur d’attribut pour cette AVP a un codage qui est changé par rapport à la [RFC2661] :

L’AVP Numéro appelant DOIT être codée comme une adresse NSAP de 20 octets codée en binaire lorsque le bit B est établi dans l’AVP Type de support. L’adresse NSAP codée en binaire donne une plus large gamme de méthodes d’encapsulation d’adresses qu’un champ ASCII. La structure de l’adresse NSAP (par exemple, E.164, ICD, DCC) est définie dans [AESA].

Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être réglé à 0. La longueur de cette AVP (avant d’être cachée) est 26.

L’AVP Sous-adresse, de type d’attribut 23, code les informations supplémentaires de la sous-adresse de l’appelant.

Le champ Valeur d’attribut pour cette AVP a changé de codage par rapport à la [RFC2661] :

L’AVP Sous-adresse DOIT être codée comme une adresse NSAP de 20 octets codée en binaire lorsque le bit B est établi dans l’AVP Type de support. L’adresse NSAP codée en binaire donne une plus large gamme de méthodes d’encapsulation d’adresse qu’un champ ASCII. La structure de l’adresse NSAP (par exemple, E.164, ICD, DCC) est définie dans [AESA].

L’AVP Numéro de sous-adresse PEUT être présente dans l’ICRQ et l’OCRQ, et DEVRAIT n’être disponible que si le numéro de l’appelé est aussi dans le message.

Cette AVP peut être cachée (le bit H peut être 0 ou 1). Le bit M pour cette AVP DOIT être réglé à 0. La longueur de cette AVP (avant d’être cachée) est 26.

Le présent document demande à l’IANA d’allouer six nouvelles valeurs de type pour les AVP suivants (voir le paragraphe 5.2) :

Le présent document définit de plus un nouveau bit (B) dans les AVP de capacités de support et type de support (paragraphe 5.3).

Le présent document définit un champ de fanion dans l’AVP Catégorie de service, où seulement un bit de ce fanion a été alloué au sein de ce document (S). Les allocations ultérieures sont soumises à la règle de "Spécification exigée", c’est-à-dire que les valeurs et leur signification doivent être documentées dans une RFC ou autre référence permanente et directement disponible, avec des détails suffisants pour que l’interopérabilité entre des mises en œuvre indépendantes soit possible.

Aucun risque supplémentaire pour la sécurité n’est prévu en dehors de ceux spécifiés dans la [RFC2661].

Les auteurs tiennent à remercier Laurent Hermans de son travail sur les versions précédentes de ce document, Juha Heinanen (Telia) et David Allen (Nortel Networks) de leur discussion constructive sur le document durant la réunion de Minneapolis de l’IETF, Mark Townsley (cisco) de ses conseils sur l’utilisation de l’AVP d’identifiant de VPI/VCI.

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

[RFC2364] G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens, "PPP sur AAL5", juillet 1998. (P.S.)

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

[RFC3437] W. Palter, W. Townsley, "Extensions du protocole de tunnelage de couche deux pour la négociation du protocole de contrôle de liaison en PPP", décembre 2002. (P.S.)

[UNI] ATM Forum, "User-Network Interface (UNI) Specification, Version 4.0", juillet 1996.

[AESA] ATM Forum, "ATM Forum Addressing : Reference Guide, version 1.0", Final Ballot, janvier 1999.

[10646] ISO/IEC, "Information Technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture et Basic Multilingual Plane", mai 1993, avec ses amendements.

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.

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

Groupe de travail Réseau	Y. T'Joens & B. Sales, Alcatel
Request for Comments : 3301	P. Crivellari, Belgacom
Catégorie : En cours de normalisation	juin 2002

Yves T'joens	Paolo Crivellari	Bernard Sales
Alcatel Network Strategy Group	Belgacom	Alcatel Network Strategy Group
Francis Wellesplein 1,	Bd du Roi Albert II 27	Francis Wellesplein 1,
2018 Antwerp, Belgium	B-1030 Bruxelles	2018 Antwerp, Belgium
téléphone : +32 3 240 7890	téléphone : +32 2 202 9698	téléphone : +32 3 240 9574
mél : yves.tjoens@alcatel.be	mél : paolo.crivellari@belgacom.be	mél : bernard.sales@alcatel.be