PPP sur AAL5 d'ATM (PPPoA)

(PPP over AAL5)

Statut de ce mémo

Ce mémo procure une norme de protocole à la communauté internet et admet discussions et suggestions pour son amélioration. Consultez l'édition courante des « Normes officielles de protocoles internet » (N.D.T. RFC 2800) pour connaitre l'état de standardisation  et le statut de ce protocole. La distribution de ce mémo est libre.

Copyright

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

Notes de traduction

Le texte original est traduit aussi fidèlement que possible, Les acronymes issus de mots anglais sont conservés tel quels mais généralement explicités à leur première occurrence. Des notes de traduction (N.D.T.) peuvent préciser des concepts qui se décrivent en anglais avec un seul mot ainsi que des caractéristiques ou exceptions françaises.

Généralités

Le protocole Point à Point (PPP) [1] fourni une méthode standard de transport multi-protocoles sur un lien point à point.
Ce document décrit l'utilisation d' AAL5 (Couche d'adaptation 5) de ATM (Réseau de transport asynchrone) pour la mise en trames de paquets PPP encapsulés.

Application

Cette spécification est fournie pour les implémenteurs qui souhaitent utiliser les facilitées de PPP telles que le protocole de contrôle de lien, les protocoles de contrôle de la couche réseau, l'authentification et la compression. Ces fonctionnalitées nécessitent une relation point à point entre les extrémités et ne sont pas conçues pour les relations multi-points d'ATM ou d'autres environnement multi-accés.

Table des matières

1. Introduction
2. Conventions
4. Encapsulation multi-protocoles
5.Multiplexage PPP sur circuit virtuel pour PPP sur AAL5
6. Encapsulation LLC pour PPP sur AAL5
7. Signaux de contrôle hors bande.
8. Détection et récupération des transitions non sollicitées d'encapsulations PPP .
9. Options de configuration LCP
10. Considérations de sécurité
11. Remerciements
12. Références
13. Adresses des auteurs
14. Copyright intégral

1. Introduction

Le protocole AAL5 d'ATM est conçu pour fournir des connexions virtuelles entre des stations terminales reliées à un même réseau. Ces connexions offrent un service de transport de paquets incluant la détection des erreurs mais pas leur correction.
La plupart des implémentations de PPP sont basées sur l'utilisation de l'ISO 3309 HDLC pour la mise en trames [3].
Quand un réseau ATM est configuré avec des connexions point à point, PPP peut utiliser AAL5 comme mécanisme de mise en trames.

2. Conventions

Les mots clés « DOIT », « NE DOIT PAS », « NECESSAIRE », « RECOMMANDE », « PEUT » et « OPTIONNEL », lorsqu'ils apparaissent dans ce document, doivent être interprétés comme décrit en [10].

3. Interface des services de la couche AAL5

La couche PPP traite la couche ATM AAL5 sous-jacente comme un lien point à point synchrone. Dans ce contexte, le lien PPP correspond à une connexion virtuelle ATM AAL5. La connexion virtuelle DOIT être en duplex intégral, point à point et PEUT être dédiée (C.A.D. permanente, déjà établie) ou commutée (Etablie à la demande). De plus l'interface PPP/AAL5 DOIT répondre aux critères suivants :

- Format d'interface. L'interface PPP/AAL5 présente un service d'octet à la couche AAL5. Il n'est pas prévu de fournir ou d'accepter des sous-octets.

- Vitesse de transmission. La couche PPP ne DOIT PAS imposer de restrictions quand à la vitesse de transmission ou aux paramètres de trafic de la couche ATM sous-jacente.

- Signaux de contrôles. La couche AAL5 DOIT fournir des signaux de contrôle à la couche PPP indiquant le début de connexion ou la déconnexion du circuit virtuel. Cela provoque les évenements LCP (Protocole de contrôle de lien de PPP) « Couche inférieure prête (UP) » et « Couche inférieure non prête (DOWN) » sur la machine [1] fournissant la couche PPP.

4. Encapsulation multi-protocoles

Cette spécification utilise les principes, la terminologie et les structures de trame décrits dans « Encapsulation multi-protocoles sur la couche d'adaptation 5 d'ATM » [4].
La fonction de cette spécification n'est pas de documenter ce qui est déjà standardisé en [4], mais de spécifier comment les mécanismes décrits en [4] sont utilisés pour intégrer PPP sur un réseau basé sur AAL5 d'ATM.
La section 1 de [4] définie les deux mécanismes pour identifier le type de protocole du champ « charge utile » du PDU (Paquet de données du protocole) : multiplexage par circuits virtuels, et encapsulation LLC (Lien logique de contôle). Dans la première technique, le type de protocole de la charge utile est implicitement connu par les extrémités de chaque circuit virtuel grâce aux procédures de contrôle. Dans la technique d'encapsulation LLC, le type de protocole de la charge utile est explicitement identifié dans un PDU donné par un en-tête LLC, suivi de la charge utile des données.
Quand une charge PPP est transporté sur AAL5, une implémentation :

1. DOIT supporter le multiplexage des charges PPP par circuit virtuel, tel que décrit plus loin en section 5, par configuration mutuelle ou négociation de chaque extrémité. Cette technique est connue sous le nom de « Multiplexage PPP par circuit virtuel ».

2. DOIT supporter les charges PPP avec encapsulation LLC sur les circuits virtuels permanents (PVC), tel que décrit plus loin en section 6, par configuration mutuelle ou négociation de chaque extrémité. Cette technique est connue sous le nom de « Encapsulation LLC pour PPP ».

3. DOIT, pour l'initialisation des circuits virtuels commutés (SVC), négocier avec la procédure Q.2931 [9] (Annexe C), et encoder les élements de l'interface de la couche inférieure (B-LLI) pour signaler soit le multiplexage de PPP par circuits virtuels, soit l'encapsulation LLC. Les détails de cette procédure de contrôle sont décris en section 7.

Si une implémentation se connecte à travers un service à relais de trame ATM FRF.8 [7] à une extrémité RFC 1973 [6], elle DOIT utiliser l'encapsulation LLC. Les relais de trame ATM FRF.8 ne sont pas obligés de supporter le multiplexage par circuits virtuels. Cette exception permet au FR/ATM IWU de rester compatible avec FRF.8 quand l'extrémité PPP sur AAL5 travaille avec une extrémité RFC 1973.

5. Multiplexage PPP sur circuit virtuel pour PPP sur AAL5

Le format du PDU d'AAL5 est le suivant :

Le champ « charge utile » de la sous-couche « Convergence - Partie commune » (CPCS-PDU) contient les données de l'utilisateur à concurrence de 2 ^ 16 - 1 octets.
Le champ « PAD » remplit le CPCS-PDU pour le faire correspondre exactement aux cellules ATM de manière à ce que la dernière cellule de 48 octets créée par la sous-couche SAR (Segmentation et Réassemblage) ait le suffixe du CPCS-PDU justifié à droite dans la cellule.
Le champ CPCS-UU (Information utilisateur) est utilisé pour transférer de manière transparente des informations d'utilisateur à utilisateur. Ce champ n'a pas de fonction dans l'encapsulation multi-protocole ATM décrite dans ce mémo et peut contenir n'importe quelle valeur.
Le champ CPI (Indicateur partie commune) aligne le suffixe du CPCS-PDU sur 64 bits. La possibilité de futures fonctions additionnelles est à l'étude à l'IYU-T. Quand on n'utilise que la fonction d'alignement sur 64 bits, ce champ doit contenir 0x00.
Le champ « Longueur » indique la longueur, en octets, du champ « charge utile ». La valeur maximale pour le champ « longueur » est de 65535 octets. Un champ « longueur » positionné à 0x00 est utilisé pour la fonction d'abandon.
Le champ CRC protège tout le CPCS-PDU excepté le champ CRC lui-même.
Une trame « Multiplexage PPP par circuit virtuel » DOIT constituer la charge utile du CPCS-PDU et est définie comme suit :

Identificateur de protocole - 8/16 bits

Information

Bourrage

Chacun de ces champs est spécifiquement défini en [1].

6. Encapsulation LLC pour PPP sur AAL5

L' « Encapsulation LLC pour PPP » sur AAL5 est une technique alternative au « Multiplexage PPP par circuit virtuel » sur AAL5.
Le champ « charge utile » du CPCS-PDU d'AAL5 est codé selon le croquis ci-dessous. Les champs importants dans ce diagramme sont :

1/ En-tête LLC : 2 octets codés pour spécifier une source SAP et une destination SAP du PDU OSI routé (Valeurs 0xFE 0xFE), suivi par une information non-numérique (UI) de type de trame (Valeur 0x03).

2/ Identificateur du protocole de la couche réseau (NLPID) représentant PPP (valeur 0xCF).

3/ Le champ identificateur de protocole PPP, qui peut être de 1 ou 2 octets. Voir référence [1].

4/ Suivi par le champ d'information PPP tel que sur la figure ci-dessus.

Les extrémités PEUVENT être bilatérallement configurées pour envoyer d'autres protocoles avec encapsulation LLC parallèlement à PPP dans la même connexion virtuelle. Cependant, elles ne DOIVENT PAS envoyer de paquets appartenant à un protocole qui a un NCP actif dans la session PPP.

Les implémentations DEVRAIENT traiter les paquets pour réduire au minimum l'impact sur la qualité des engagements de service liés à l'écoulement des protocoles PPP encapsulé LLC et non PPP.

7. Signaux de contrôle hors bande.

L'appellant à l'origine d'une connection AAL5 par circuit virtuel commuté DOIT demander dans le message d'initialisation soit un multiplexage par circuit virtuel, soit une encapsulation LLC ou encore les deux à la fois. Quand un appellant offre les deux techniques, les deux IEs B-LLI sont codés avec un IE d'indication de répétition dans l'ordre de préférence. L'implémentation appellée DOIT être capable d'accepter un appel entrant qui offre l'encapsulation LLC dans la requête d'appel. L'implémentation appellée DOIT rejeter une requête d'initialisation d'appel qui n'offre qu'une encapsulation qu'elle ne supporte pas. Les implémentations à l'origine d'appels offrant les deux techniques d'encapsulation du protocole DOIVENT être capable de négocier l'utilisation de l'encapsulation LLC.

Quand un appel crée un circuit virtuel multiplexé qui doit transporter une charge utile PPP, l'élement  d'information utilisateur ITU Q.2931 [9] B-LLI de la couche 3 du protocole est codé pour sélectionner ISO/IEC TR 9577 [5] dans l'octet 7. Les octets d'extension spécifient une valeur IPI de PPP (0xCF). Par définition, les premier octets du champ « charge utile » d'une trame AAL5 contiennent toujours un en-tête PPP suivi d'un paquet.

Quand un appel crée une encapsulation LLC qui doit transporter une charge utile PPP, l'élement  d'information utilisateur ITU Q.2931 B-LLI de la couche 2 du protocole est codé pour sélectionner un contrôle de lien logique LAN (ISO/IEC8802-2) dans l'octet 6. Voir la RFC 1755 [8] appendice A pour un exemple. Par définition, les premier octets du champ « charge utile » d'une trame AAL5 contiennent un en-tête LLC suivi d'un NLPID et de la charge utile PPP.

8. Détection et récupération des transitions non sollicitées d'encapsulations PPP .

Quand la connexion virtuelle est en perdition, la technique d'encapsulation de PPP peut unilatéralement et inopinément changer lors de telles transitions. La détection et les procédures de reprise sont définies pour les transitions d'état suivantes :  

* « Multiplexage PPP par circuit virtuel » devient « Encapsulation LLC pour PPP »
* « Encapsulation LLC pour PPP » devient « Multiplexage PPP par circuit virtuel »

Quand l'encapsulation LLC pour PPP est utilisée, les 6 octets du paquet LCP (Protocole de contrôle de lien PPP) initial contiennent : fe-fe-03-cf-c0-21. Cette séquence constitue les 6 premiers octets d'une trame AAL5. Dans le cas du multiplexage PPP par circuit virtuel, les paquets LCP contiennent la séquence c0-21. Cette séquence constitue les 2 premiers octets d'une trame AAL5. Quand un paquet LCP « Demande de configuration » est reçu et reconnu, le lien PPP entre dans l'état « Etablissement de liaison »

Si, après que PPP soit entré dans l'état « Protocoles de la couche réseau » et ait négocié avec succès un NCP (Protocole de contrôle réseau PPP) particulier, une trame arrive en utilisant une encapsulation des données alternative mais équivalente tel que défini en [4], le lien PPP DOIT :

* Pour un SVC (Circuit virtuel commuté), immédiatement stopper l'appel avec le code motif 111, « Erreur de protocole, non spécifié ».
* Pour un PVC (Circuit virtuel permanent), mettre fin aux NCPs actifs, DOIT générer un message d'erreur, passer en état « Terminé » et rejeter discrétement tous les paquets qu'il reçoit.

Ces règles empêchent les « trous noirs » qui se produisent quand une extrémité est en perdition. Une implémentation qui nécessite une configuration du lien PPP et d'autres fonctionnalités négociées de PPP (Telle que l'authentification), PEUT passer en état « Terminé » quand la configuration n'aboutit pas.

9. Options de configuration LCP

L'option de configuration du numéro magique LCP est RECOMMANDEE alors que l'option de compression des champs (PFC) n'est PAS RECOMMANDEE. Une implémentation ne DOIT PAS avoir recours à l'une des options suivantes, et DOIT rejeter une demande pour de telles options :

- Vérification du séquencement des champs (FCS)
- Compression des champs adresse et contrôle (ACFD);
- Table des caractères de contrôle asynchrones (ACCM).

L'option « Unité de réception maximale » (MRU) ne DOIT PAS être négociée à une taille supérieure à la taille maximum du CPCS-PDU spécifiée dans le contrat de trafic de la connexion virtuelle associée à cette direction.

Bien qu'étant point à point, un lien PPP peut être ponté sur plusieurs sections de la couche physique. Pour chacune de ces section AAL5, les options de trames LCP DOIVENT être activement négociées par le pont convertisseur indépendamment des options de trames LCP utilisées par d'autres sections de la couche physique.

Note d'implémentation :
Quand un PVC ATM-AAL5 est dans l'état « Arrêté », il est RECOMMANDE à l'implémentation d'attendre une requête de configuration. Voir l'option d'implémentation dans la référence [1] section 4.2, la sous-section « Etat arrêté ».

10. Considérations de sécurité

En principe, les réseaux ATM reposent sur des circuits virtuels, et la sécurité est implicite dans l'administration des circuits virtuels permanents (PVCs) sur les réseaux de données publics jusqu'à leurs limites. La probabilité d'une brèche de sécurité provoquée par le mauvais acheminement d'une cellule ATM est considérée comme négligeable.

Quand un réseau public ATM supporte les circuits virtuels commutés, le modèle de protocole devient analogue à celui d'une traditionnelle numérotation par un modem vocal sur le réseau téléphonique commuté (PTSN). Les mêmes protocoles d'authentification qui sont déjà largement utilisés pour l'accès internet par numérotation conviennent. En conséquence, la sécurité de PPP sur AAL5 est équivalente à celle existant sur l'infrastructure internet existante.

Les applications qui nécessitent une sécurité renforcée sont invitées à utiliser des en-têtes d'authentification, ou des charges utiles cryptées, et / ou les services de sécurité de la couche ATM.

Lors de l'utilisation de l'encapsulation LLC pour PPP sur une connexion virtuelle, une extrémité ne peut pas considérer que l'authentification de la session PPP et les mécanismes de sécurité qui s'y rapportent assurent aussi la sécurité des autres flux « LLC encapsulé » de la même connexion virtuelle.

11. Remerciements

Cette description est basée sur le travail effectué par le groupe « Mode paquet » du forum ADSL. Il est inspiré par « PPP dans les relais de trames », RFC 1973, de William Simpson. Un remerciement particulier à Phil Rakity de Flowpoint, Tim Kwok de Microsoft et David Allan de Nortel pour leurs remarques et commentaires constructifs.

12. Références

[1] Simpson, W., Editor, « The Point-to-Point Protocol (PPP) », STD 51, RFC 1661, Juillet 1994.

[2] The ATM Forum, « Frame based User-to-Network Interface (FUNI) Specification v2 », af-saa-0088.000, Mai 1997.

[3] Simpson, W., Editor, « PPP in HDLC-like Framing », STD 51, RFC 1662, Juillet 1994.

[4] Heinanen, J., « Multiprotocol Interconnect over AAL5 », RFC 1483, Juillet 1993.

[5] ISO/IEC DTR 9577.2, « Information technology - Telecommunications and Information exchange between systems - Protocol Identification in the network layer », 16-08-1995.

[6] Simpson, W., « PPP in Frame Relay », RFC 1973, Juin 1996.

[7] The Frame Relay Forum, « Frame Relay/ATM PVC Service Inter- working Implementation Agreement », FRF.8, Avril 1995.

[8] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D., and A. Malis, « ATM Signaling Support for IP over ATM », RFC 1755, Février 1995.

[9] International Telecommunication Union, « Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signaling System No.2 (DSS2) User Network Interface Layer 3 Specification for Basic Call/Connection Control », ITU-T Recommendation Q.2931, (International Telecommunication Union: Geneva, 2/95)

[10] Bradner, S., « Key words for use in RFCs to Indicate Requirement Levels », BCP 14, RFC 2119, Mars 1997.

13. Adresses des auteurs

Le groupe de travail peut être contacté via l'actuel responsable :

Karl Fox
Ascend Communications
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
émail: karl@ascend.com

Les questions à propos de ce mémo peuvent aussi être directement adressées aux auteurs :

George Gross
Lucent Technologies, Inc
184 Liberty Corner Road
Warren, NJ 07059
téléphone:   +1.908.580.4589
émail: gmgross@lucent.com

Manu Kaycee
Paradyne Corporation
21 Bear Meadow Road
Londonderry, NH 03053-2168
téléphone: +1.603.434.6088
émail: mjk@nj.paradyne.com

Arthur Lin
Shasta Networks Inc.
249 Humboldt Court
Sunnyvale, CA 94089-1300
téléphone: +1.408.747.5051
émail: alin@shastanets.com

Andrew Malis
Ascend Communications, Inc.
1 Robbins Road
Westford, MA 01886
téléphone: +1.978.952.7414
émail: malis@ascend.com

John Stephens
Cayman Systems, Inc.
100 Maple Street
Stoneham, MA 02180
téléphone: +1.617.279.1101
émail: john@cayman.com

14. Copyright intégral

Copyright © The Internet Society (1998). Tous Droits Réservés.

Le document anglais original et les traductions de celui-ci peuvent être copiés et fournis à d'autres, et les travaux dérivés qui le commente ou l'explique ou facilite son implémentation peuvent être préparés, copiés, publiés ou distribués, en totalité ou en partie, sans aucunes restrictions tant que les observations ci-dessus sur le copyright et ce paragraphe sont inclus dans tous ces types de copies ou de travaux dérivés. Cependant, le document anglais original lui-même ne peut être modifié de quelque façon que ce soit, comme par exemple en retirant les observations de copyright ou les références à la Internet Society ou aux autres organismes de l'Internet, excepté comme l'exige le but du développement des standards Internet où dans un tel cas les procédures pour les copyrights définis dans le processus des Standards Internet doivent être suivies, ou alors comme l'exige une traduction dans une langue autre que l'Anglais.

Les autorisations limitées accordées ci-dessus sont éternelles et ne pourrons être révoquées par la Internet Society, ses successeurs ou ses repreneurs.

Ce document et les informations contenues ici sont fournis de façon « TELS QUELS « et les traducteurs, la Internet Society et la Internet Engineering Task Force déclinent toute garantie, explicites ou implicites, y compris mais pas seulement toute garantie que l'utilisation des informations de ce document ne violera pas des réglementations ou des garanties implicites commerciales ou physiques pour une application particulière.

Commentaires/Questions à propos de ce document ? Envoyez un émail (N.D.T. en anglais !) à rfc-admin@faqs.org