RFC3336 PPP sur couche AAL2 Thomson & autres

Groupe de travail Réseau

B. Thompson, T. Koren, Cisco Systems

Request for Comments : 3336

B. Buffam, Seaway Networks

Catégorie : En cours de normalisation


Traduction Claude Brière de L’Isle

décembre 2002



PPP sur la couche 2 d'adaptation du mode de transfert asynchrone (AAL2)


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 protocole point à point (PPP) donne une méthode standard pour le transport de datagrammes multi protocoles sur des liaisons point à point.


Le présent document décrit l’utilisation de la couche 2 d’adaptation ATM (AAL2, ATM Adaptation Layer 2) pour le tramage de paquets encapsulés dans PPP.


Applicabilité

Le présente spécification est destinée aux mises en œuvre qui désirent utiliser les facilités qui sont définies pour PPP, telles que le protocole de contrôle de liaison, les protocoles de contrôle de couche réseau, l’authentification, et la compression. Ces capacités exigent une relation point à point entre les homologues, et ne sont pas conçues pour les relations multipoints qui sont disponibles en ATM et dans d’autres environnements multi-accès.

Table des Matières

1. Introduction 1

2. Conventions 2

3. Interface de service de couche AAL2 2

4. Fonctionnement de PPP avec AAL2 2

5. Comparaison de PPP sur AAL2 avec les encapsulations existantes 2

5.1 Comparaison avec PPP sur AAL5 3

5.2 Comparaison avec PPPMUX sur AAL5 3

6. Description détaillée du fonctionnement du protocole 4

6.1 Fondements 4

6.2 Encapsulation PPP sur AAL2 5

6.3 Utilisation des CID AAL2 CPS-PKT 6

6.4 Fonctionnement de PPP sur AAL2 6

7. Exemple de mise en œuvre de PPP/AAL2 6

8. Options de configuration LCP 7

9. Considérations pour la sécurité 8

10. Remerciements 8

11. Références 8

12. Adresse des auteurs 9

13. Déclaration complète de droits de reproduction 9


1. Introduction


PPP sur AAL5 [RFC2364] décrit le format d’encapsulation et le fonctionnement de PPP lorsque il est utilisé avec la couche d’adaptation AAL5 ATM. Alors que ce format d’encapsulation convient bien pour le transport de IP en PPP, il est inefficace en bande passante lorsque utilisé pour le transport de petites charges utiles telles que la voix. PPP sur AAL5 est particulièrement inefficace en bande passante lorsque utilisé avec la compression d’en-tête RTP [RFC2508].


PPP sur AAL2 traite les questions d’efficacité de la bande passante de PPP sur AAL5 pour le transport de petits paquets en faisant usage de la sous couche de partie commune (CPS, Common Part Sublayer) AAL2 [I.363.2] pour permettre que plusieurs charges utiles PPP soient multiplexées dans un ensemble de cellules ATM.


2. Conventions


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


3. Interface de service de couche AAL2


La couche PPP traite le service de couche ATM AAL2 sous-jacent comme une liaison point à point binaire synchrone. Dans ce contexte, la liaison PPP correspond à une connexion ATM AAL2 virtuelle. Cette connexion virtuelle DOIT être complètement bidirectionnelle, point à point, et elle PEUT être soit dédiée (c’est-à-dire, permanente, établie par provision) ou commutée (établie à la demande). De plus, la limite d’interface de service PPP/AAL2 DOIT satisfaire aux exigences suivantes.


Format d’interface – la limite de couche PPP/AAL2 présente une interface de service d’octet à la couche AAL2. Il n’y a aucune disposition pour que des sous-octets soient fournis ou acceptés.


Taux de transmission – la couche PPP n’impose aucune restriction concernant le taux de transmission sur les paramètres de descripteur de trafic de couche ATM sous-jacente.


Signaux de contrôle – la couche AAL2 DOIT fournir des signaux de contrôle à la couche PPP qui indiquent quand la connexion virtuelle devient connectée ou déconnectée. Ils fournissent les événements "Up" et "Down" à l’automate à états LCP [RFC1661] au sein de la couche PPP.


Dans le cas de PPP sur AAL2, l’état de la liaison peut être déduit des paquets de gestion de fautes de type 3 portés dans la bande au sein d’un certain flux de CID AAL2.


4. Fonctionnement de PPP avec AAL2


PPP sur AAL2 définit une encapsulation qui utilise la sous couche segmentation et réassemblage spécifique du service (SSSAR, Service Specific Segmentation and Reassembly) [I.366.1] pour AAL type 2. La sous couche SSSAR est utilisée pour segmenter les paquets PPP en trames qui peuvent être transportées en utilisant la CPS AAL2. La sous couche SSSAR utilise différents codets UUI AAL2 pour indiquer si un segment est le dernier segment d’un paquet ou non.


L’encapsulation de PPP sur AAL2 fournit un CRC de 16 bits pour les charges utiles PPP. Il y a deux codets UUI alloués par la SSSAR pour indiquer les fragments intermédiaires d’un paquet et le dernier fragment d’un paquet. Le codet 27 indique les trames intermédiaires d’un paquet fragmenté et un codet 26 indique la dernière trame d’un paquet. Le format d’encapsulation est décrit plus complètement au paragraphe 6.2.1.


Une mise en œuvre de PPP sur AAL2 PEUT utiliser un ou plusieurs identifiants de canal (CID, Channel Identifier) AAL2 pour le transport des paquets PPP associés à chaque session PPP. Plusieurs CID pourraient être utilisés pour mettre en œuvre un service de transport en temps réel à plusieurs classes pour PPP en utilisant la couche AAL2 pour la fragmentation et l’entrelacement de liaisons. Un document d’accompagnement [RFC3337] décrit les extensions de classes pour PPP sur AAL2 avec plusieurs CID AAL2.


5. Comparaison de PPP sur AAL2 avec les encapsulations existantes


Le présent document propose la substitution du transport AAL2 pour PPP dans les scénarios où de petits paquets sont transportés sur un réseau ATM. Ceci est très critique dans des applications telles que le transport vocal avec RTP [RFC1889] où la compression d’en-tête RTP [RFC2508] est utilisée. Dans des applications telles que le transport de la voix, l’efficacité de la bande passante et de faibles délais sont tous deux très importants.


La présente section donne des justifications pour le service PPP sur AAL2 pour le transport ATM comparé aux formats d’encapsulation PPP existants utilisés pour le transport sur ATM. Deux formats d’encapsulation seront examinés ici : PPP sur AAL5 [RFC2364], et PPP avec PPPMUX [RFC3153] sur AAL5.


5.1 Comparaison avec PPP sur AAL5

La présente proposition utilise ATM AAL2 [I.363.2] plutôt que AAL5 comme transport pour PPP. La SSSAR avec la CPS AAL2 génère moins de redondance d’encapsulation ATM par charge utile PPP. L’encapsulation de charge utile consiste en un CRC de deux octets. L’en-tête de la CPS AAL2 consiste en trois octets, et le champ Start (STF, Start Field) AAL2 fait un octet. Cela fait une redondance totale d’encapsulation de six octets. Cela se compare aux 8 octets de redondance pour l’en-queue AAL5 utilisé pour PPP sur AAL5.


La fonction de multiplexage de la couche CPS AAL2 permet un transport plus efficace en bande passante des trames PPP en multiplexant plusieurs trames PPP dans une ou plusieurs cellules ATM en utilisant la fonction de CPS d’AAL2. Cela retire la redondance de bourrage de AAL5 lorsque elle est utilisée pour le transport de trames courtes.


5.2 Comparaison avec PPPMUX sur AAL5

Le multiplexage PPP (PPPMUX) [RFC3153] est une nouvelle méthode pour faire du multiplexage dans la couche PPP. PPPMUX donne une fonctionnalité similaire à celle de la fonction de multiplexage fondée sur la CPS de AAL2. En utilisant le multiplexage PPP, une pile PPP ressemblerait à PPP/PPPMUX/AAL5.


PPP/PPPMUX/AAL5 et PPP/AAL2 utilisent toutes deux le multiplexage pour réduire la redondance du bourrage de cellules lorsque des trames sont envoyées sur un circuit virtuel ATM. Cependant, l’utilisation de la bande passante par PPP/AAL2 va normalement être meilleure que la bande passante utilisée par PPP/PPPMUX/AAL5. Cela parce que les trames multiplexées dans PPP/PPPMUX/AAL5 doivent toujours être encapsulées au sein d’une trame AAL5 avant d’être envoyées. Cette encapsulation cause l’ajout de huit octets supplémentaires d’en-queue AAL5 à l’encapsulation PPPMUX. En plus des huit octets de l’en-queue AAL5, PPPMUX va causer en moyenne l’ajout de 24 octets supplémentaires de PAD (bourrage ) AAL5. Ces deux facteurs vont finir par réduire l’efficacité de PPPMUX lorsque elle est utilisée sur AAL5.


Avec PPP/AAL2, la couche AAL2 CPS traite les trames PPP individuelles comme une série de charges utiles CPS qui peuvent être multiplexées. Tant que les trames PPP arrivent à la couche CPS avant que le TIMER_CU CPS expire, toutes les cellules ATM qui viennent de la couche CPS seront remplies. Dans ces conditions, PPP/AAL2 n’aura pas de PAD associé. Lorsque la fonction CPS d’AAL2 ne cause pas de génération de PAD, PPP/AAL2 sera plus efficace en bande passante que PPP/PPPMUX/AAL5.


Dans PPP/PPPMUX/AAL5, la sous-couche de segmentation et de réassemblage (SAR, Segmentation and Reassembly Sublayer) AAL5 et la MUX/DEMUX PPP sont effectuées dans deux couches différentes. Donc, le receveur PPPMUX/AAL5 doit réassembler une pleine trame AAL5 pour la couche ATM avant que la couche PPPMUX puisse extraire les charges utiles PPP. Pour obtenir l’efficacité maximum du multiplexage PPP, de nombreuses charges utiles PPP peuvent être multiplexées ensemble. Cela augmente la taille de la trame multiplexée en nombreuses cellules ATM. Si une de ces cellules ATM est perdue, tout le paquet PPPMUX sera éliminé. Aussi, un délai significatif peut être subi alors que la couche AAL5 attend que de nombreuses cellules ATM arrivent jusqu’à ce qu’une trame complète ait été assemblée avant que la trame complète soit passée à la couche Multiplexage PPP où le démultiplexage PPP inverse se fait alors. Ce même problème s’applique aussi aux trames PPPMUX/AAL5 qui progressent vers le bas de la pile.


Avec AAL2, les deux fonctions de segmentation et réassemblage et de multiplexage sont effectuées dans la couche CPS AAL2. À cause de la définition de la fonction CPS AAL2, une charge utile multiplexée sera extraite aussitôt qu’elle est reçue. Le receveur CPS n’attend pas que de nombreuses charges utiles d’une trame AAL2 multiplexée soient reçues avant de retirer les charges utiles du flux multiplexé. Le même avantage s’applique aussi aux mises en œuvre d’envoyeur CPS AAL2. Aussi, la perte d’une cellule ATM cause seulement la perte des paquets qui sont inclus dans cette cellule.


La fonction CPS AAL2 assure le multiplexage dans AAL2. Cette fonction a souvent besoin d’être mise en œuvre dans le matériel pour des raisons de performances. À cause de cela, une mise en œuvre de PPP/AAL2 qui tire parti d’un SAR AAL2 mis en œuvre dans le matériel aura un avantage de performances significatif sur une mise en œuvre PPP/PPPMUX/AAL5 où PPPMUX est mis en œuvre dans le logiciel. Aussi, la spécification AAL2 est disponible depuis bien plus longtemps que la spécification du multiplexage PPP et à cause de cela, des mises en œuvre optimisées de logiciels et de matériel de la fonction CPS AAL2 sont plus en cours de développement que des mises en œuvre de multiplexage PPP.


6. Description détaillée du fonctionnement du protocole

6.1 Fondements

6.1.1 Multiplexage AAL2


La Recommandation UIT-T I.363.2 spécifie la couche Adaptation ATM de type 2. Ce type AAL assure une transmission efficace en bande passante de paquets à bas débit, de longueur courte et variable dans des applications sensibles au délai. Plus d’un flux d’informations d’utilisateur de AAL type 2 peut être pris en charge sur une seule connexion ATM. Il y a seulement une définition pour la sous couche parce que elle met en œuvre l’interface à la couche ATM et est partagée par plus d’une couche SSCS.


6.1.2 Sous couches de convergence spécifiques du service AAL2


Les recommandations UIT-T [I.366.1] et [I.366.2] définissent les sous couches de convergence spécifiques du service (SSCS, Service Specific Convergence Sub-layer) qui fonctionnent par dessus la sous couche Partie commune définie dans I.363.2. Cette couche spécifie les formats et procédures de paquets pour coder les différents flux d’informations dans un transport efficace en bande passante. Comme son nom l’implique, cette sous couche met en œuvre les éléments du transport spécifiques du service. Alors qu’il y a seulement une définition de la sous couche Partie commune pour AAL2, il peut y avoir plusieurs fonctions SSCS définies pour fonctionner sur cette couche CPS. Différents CID au sein d’un circuit virtuel AAL2 peuvent faire fonctionner différentes SSCS.


6.1.3 Format de paquet CPS AAL2 (CPS-PKT)


Le format CPS-PKT sur AAL2 tel que défini dans I.363.2 est :


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| + + + + |

| CID + LI + UUI + HEC + CPS-INFO |

| + + + + |

| + + + + |

| (8) + (6) + (5) + (5) + (45/64 * 8) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Note : La taille des champs note le nombre de bits.


L’identifiant de canal (CID) identifie le sous flux au sein de la connexion AAL2. L’indication de longueur (LI) indique la longueur de la charge utile CPS-INFO. Le champ UUI (User-to-User Indication) porte les informations entre la SSCS/Application qui fonctionne par dessus le CPS. La sous couche SSSAR telle que définie dans [I.366.1] utilise les codets suivants :


Codet UUI Contenu du paquet

0-26 données en mode tramé, paquet final.

27 données en mode tramé, encore à venir.


Cette proposition utilise deux codets UUI comme suit :


Codet UUI Contenu du paquet

27 paquet non final.

26 paquet final.


6.1.4 Format CPS-PDU AAL2


Le format de CPS-PDU sur AAL2 comme défini dans I.363.2 est :





+-+-+-+~+~+-+-+

|CPS| CPS-INFO|

|PKT| |

|HDR| |

+-+-+-+~+~+-+-+

| CPS-PKT |

| +-+-+-+~+~+-+-+

|CPS| CPS-INFO|

| |PKT| |

|HDR| |

| +-+-+-+~+~+-+-+

CPS-PKT

| | +-+-+-+~+~+-+-+

|CPS| CPS-INFO|

| | |PKT| |

|HDR| |

| | +-+-+-+~+~+-+-+

CPS-PKT

V V V V

+-+-+-+-+-+-+-+~+~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

En-tête | | | |

de | STF | Charge utile CPS-PDU | PAD |

cellule | | | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+

CPS PKT HDR = en-tête de paquet de CPS

PAD = bourrage


Note : La taille des champs donne le nombre de bits qu’ils utilisent.


Le format de CPS-PDU est utilisé pour porter un ou plusieurs paquets CPS multiplexés sur un seul CPS-PDU. L’en-tête CPS contient assez d’informations pour identifier les paquets CPS au sein d’une CPS-PDU. En cas de perte de cellules, le champ STF est utilisé pour trouver le premier paquet CPS dans la cellule en cours.


6.2 Encapsulation PPP sur AAL2

L’encapsulation de PPP sur AAL2 utilise la CPS AAL2 sans changement.


Certains protocoles PPP encapsulés tels que la compression d’en-tête RTP exigent que la couche liaison fournisse la détection d’erreur de paquet. À cause de cela, PPP sur AAL2 définit un CRC de 16 bits qui est utilisé avec la sous couche SSSAR de I.366.1 pour fournir la détection d’erreur de paquet. Le format d’encapsulation est décrit ci-dessous.


6.2.1 Encapsulation de charge utile PPP sur AAL2 avec CRC de 16 bits (CRC-16).

L’encapsulation de charge utile de PPP ajoute un CRC de deux octets à chaque trame PPP avant d’utiliser la couche SSSAR pour envoyer la paquet PPP comme une série de trames AAL2.


Le format d’un paquet PPP sur AAL2 est montré dans le diagramme ci-dessous. Noter que ce diagramme montre l’encapsulation de charge utile lorsque le paquet n’est pas segmenté (UUI = 26). Lorsque le paquet PPP est segmenté, les champs Identifiant de protocole PPP, Information, et CRC-16 seront répartis à travers plusieurs trames SSSAR. Dans ce cas, le champ UUI sera réglé à 27 pour toutes les trames sauf la dernière. Dans la dernière trame, le champ UUI sera réglé à 26.


Encapsulation de charge utile

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| + + + + + + |

| CID + LI + UUI + HEC +Identifiant+ + |

| + + + + de + Information + CRC-16 |

| + + + + protocole + + |

| (8) + (6) + (5) + (5) + (8/16) + + (16) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Note : La taille des champs indique le nombre de bits.


Les algorithmes utilisés pour calculer et vérifier le champ CRC-16 sont identiques à ceux spécifiés pour le champ Séquence de vérification de trame (FCS, Frame Check Sequence) dans Q.921 [Q.921]. Les algorithmes provenant de Q.921 sont inclus ici pour en faciliter l’accès.


Le champ CRC-16 est rempli avec la valeur d’un calcul de CRC qui est effectué sur le contenu du paquet PPP, incluant l’identifiant de protocole PPP et le champ Information. Le champ CRC devra contenir le complément à un de la somme (modulo 2) :

1) du reste de x^k (x^15 + x^14 + ... + x + 1) divisé (modulo 2) par le générateur polynomial, où k est le nombre de bits des informations sur lesquelles le CRC est calculé,

2) du reste de la division (modulo 2) par le générateur polynomial du produit de x^16 par les informations sur lesquelles le CRC est calculé.


Le générateur polynomial du CRC-16 est : G(x) = x^16 + x^12 + x^5 + 1


Le résultat du calcul du CRC est placé avec le bit de moindre poids justifié à droite dans le champ CRC.


Dans une mise en œuvre normale chez l’émetteur, le contenu initial du registre de l’appareil qui calcule le reste de la division est préréglé tout à "1" et est ensuite modifié en le divisant par le générateur polynomial (comme décrit ci-dessus) sur les informations sur lesquelles le CRC doit être calculé ; le complément à un du reste résultant est mis dans le champ CRC.


Dans une mise en œuvre normale chez le receveur, le contenu initial du registre de l’appareil qui calcule le reste de la division est préréglé tout à "1". Le reste final, après multiplication par x^16 et ensuite division (modulo 2) par le générateur polynomial du paquet PPP de série entrant (y compris l’identifiant de protocole, les informations et le CRC) sera 0001110100001111 (de x^15 à x^0, respectivement) en l’absence d’erreur de transmission.


6.3 Utilisation des CID AAL2 CPS-PKT


Une mise en œuvre de PPP sur AAL2 PEUT utiliser un seul identifiant de canal (CID) AAL2 ou plusieurs CID pour le transport de tous les paquets PPP. Afin que les points d’extrémité d’une session PPP travaillent avec AAL2, ils DOIVENT se mettre d’accord sur le nombre, la transposition de SSCS, et les valeurs des CID AAL2 qui seront utilisés pour une session PPP. Les valeurs des CID AAL2 à utiliser pour une session PPP PEUVENT être obtenues d’un approvisionnement statique dans le cas d’une connexion AAL2 dédiée (PVC) ou de la signalisation [Q.2630.2] dans le cas d’un circuit virtuel commuté AAL2 (SPVC ou SVC).


En utilisant cette proposition, il est possible de prendre en charge l’utilisation d’AAL2 conventionnelle dans des CID qui ne sont pas utilisés pour prendre en charge PPP sur AAL2. Cette proposition permet la coexistence de plusieurs types de fonctions SSCS au sein du même VCC AAL2.


6.4 Fonctionnement de PPP sur AAL2


Le fonctionnement de PPP avec AAL2 va effectuer une encapsulation PPP de base avec l’identifiant de protocole PPP. Un CRC de 16 bits est calculé comme décrit ci-dessus et ajouté à la charge utile. La sous-couche SSSAR de AAL2 est utilisée pour le transport.


Les applications qui mettent en œuvre PPP sur AAL2 DOIVENT satisfaire à toutes les exigences de PPP [RFC1661].


7. Exemple de mise en œuvre de PPP/AAL2


La présente section décrit un exemple de mise en œuvre de la façon dont PPP peut être encapsulé sur AAL2. L’exemple montre deux piles d’applications qui génèrent des paquets IP qui sont envoyés à la même interface fonctionnant avec PPP/AAL2. Une pile d’application génère des paquets RTP et une autre application génère des datagrammes IP. L’interface PPP/AAL2 montrée dans le présent exemple fonctionne avec une version compatible avec la [RFC2508] de la compression d’en-tête RTP.


Voici les chemins que peut prendre un paquet d’application dans cette mise en œuvre :




+---+---+---+---+--+ +

| Application A | |

+---+---+---+---+--+ |

| RTP | |

+---+---+---+---+--+ +---+---+---+---+---+ Application

| UDP | | Application B | |

+---+---+---+---+--+ +---+---+---+---+---+ |

| IP | | IP | |

+---+---+---+---+--+ +---+---+---+---+---+ +

| |

+---------------+------------+

|

+---+---+---+---+---+--+ +

|Filtre de compression | |

+---+---+---+---+---+--+ |

| |

+---------+-----------+ |

| | |

Paquets | | Paquets |

RTP V | non RTP |

+---+---+---+---+---+---+ | |

| CRTP | | |

+---+---+---+---+---+---+---+---+---+---+---+---+ Transport

| PPP | |

+---+---+---+---+---+---+---+---+---+---+---+---+ |

| |

+---+---+---+---+---+---+---+ +--+---+---+---+---+--+--+-+ |

| Segmentation (SSSAR) | |

+---+---+---+---+---+---+---+ +--+---+---+---+---+--+--+-+ |

+---+---+---+---+---+---+---+---+---+---+---+---+---+----+ |

| AAL2 CPS | |

+---+---+---+---+---+---+---+---+---+---+---+---+---+----+ |

| Couche ATM | |

+---+---+---+---+---+---+---+---+---+---+---+---+---+----+ +


Dans la figure ci-dessus, l’application A est une application RTP qui génère des paquets RTP. L’application B est une application IP qui génère des datagrammes IP. L’application A rassemble des données RTP et formate un paquet RTP. Les couches de niveau inférieur de l’application A ajoutent des en-têtes UDP et IP pour former un paquet IP complet. L’application B génère des datagrammes à la couche IP. Ces datagrammes peuvent ne pas avoir d’en-tête UDP ou RTP.


Dans la figure ci-dessus, une pile de protocole est configurée pour appliquer la compression CRTP/PPP/AAL2 sur une interface à l’hôte de destination. Tous les paquets qui son envoyés à cette interface seront vérifiés pour voir si ils peuvent être compressés en utilisant la compression d’en-tête RTP. Au fur et à mesure que les paquets apparaissent à l’interface, ils vont être vérifiés par un filtre de compression pour déterminer si ils sont candidats à la compression d’en-tête. Si le filtre de compression détermine que le paquet est candidat à la compression, le paquet va être envoyé au compresseur CRTP. Si le paquet n’est pas candidat à la compression, il va être envoyé directement à la couche PPP pour être encapsulé comme un paquet IP encapsulé dans PPP.


Le numéro d’accès UDP de destination et la longueur de paquet sont des exemples de critères qui peuvent être utilisés par le filtre de compression pour choisir l’interface.


Dans cet exemple, des paquets provenant de l’application A vont être passés au compresseur CRTP qui passe alors le paquet compressé à la couche PPP pour encapsulation comme un des types d’en-tête compressé de CRTP. La couche PPP va ajouter le type de charge utile CRTP approprié pour le paquet compressé.


Les paquets provenant de l’application B vont être envoyés directement à la couche PPP pour être encapsulés comme un paquet IP/PPP. La couche PPP va ajouter le type de charge utile PPP pour un paquet IP encapsulé dans PPP.

Les paquets PPP sont alors segmentés en utilisant la segmentation [I.366.1] avec SSSAR.


La PDU en mode trame AAL2 résultante est repassée comme une SDU CPS à la couche CPS pour le multiplexage accompagnée par le CPS-UUI et le CPS-CID. La couche CPS multiplexe le CPS-PKT sur une CPS-PDU. Les CPS-PDU sont passées à la couche ATM comme des SDU ATM à porter de bout en bout à travers le réseau ATM.


À l’extrémité receveuse, les SDU ATM arrivent et sont passés à la couche CPS AAL2. Lorsque la PDU de CPS AAL2 est accumulée, des paquets CPS complets sont rassemblés par la SSCS SSSAR. Les paquets réassemblés sont vérifiés à la recherche d’erreurs en utilisant l’algorithme de CRC.


À ce point, la couche PPP du côté receveur utilise le type de charge utile PPP pour livrer le paquet soit au décompresseur CRTP, soit à la couche IP, selon la valeur du type de charge utile PPP.


8. Options de configuration LCP


Par défaut, PPP sur AAL2 va utiliser une encapsulation de CRC de 16 bits pour tous les paquets.


L’unité de réception maximale (MRU, Maximum-Receive-Unit) par défaut est de 1500 octets.


9. Considérations pour la sécurité


Le présent mémoire définit les mécanismes de l’encapsulation de PPP sur ATM. Il y a un élément de confiance dans tout protocole d’encapsulation : un receveur devrait être capable de faire confiance à l’envoyeur pour identifier correctement le protocole qui est encapsulé et pour que l’envoyeur n’ait pas été abusé ou compromis. Un receveur devrait aussi être capable de faire confiance quant au réseau de transport entre l’envoyeur et le receveur.


Une session PPP qui fonctionne sur un circuit virtuel ATM doit suivre le fonctionnement de l’automate à états de la liaison PPP décrit dans la [RFC1661]. Cet automate à état comporte la capacité de mettre en application l’utilisation d’une phase d’authentification avec les protocoles d’authentification PAP/CHAP avant qu’aucun paquet de couche réseau ne soit échangé. Avec l’authentification de niveau PPP, un receveur PPP peut authentifier un envoyeur PPP.


La sécurité d’un système peut aussi être compromise par les attaques du réseau de transport ATM lui-même. Le Forum ATM a publié un cadre de sécurité [ATM98] et une spécification de sécurité [ATM01] qui définissent les procédures pour se garder contre les menaces courantes contre un réseau de transport ATM.


L’authentification de niveau PPP ne protège pas contre les attaques par interposition. Ces attaques pourraient survenir si un attaquant était capable de compromettre l’infrastructure de sécurité d’un réseau de commutation ATM. Les applications qui exigent une protection contre les menaces sur un réseau de commutation ATM sont invitées à utiliser des en-têtes d’authentification, ou des charges utiles chiffrées, et/ou les services de sécurité de couche ATM décrits dans [ATM01].


Lorsque PPP sur AAL2 est utilisé sur un ensemble de CID dans une connexion virtuelle, il peut y avoir des CID AAL2 encapsulés non PPP qui fonctionnent sur la même connexion virtuelle. À cause de cela, un point d’extrémité ne peut pas supposer que l’authentification de session PPP et les mécanismes de sécurité qui s’y rapportent sécurisent aussi les CID encapsulés non PPP sur la même connexion virtuelle.


10. Remerciements


Les auteurs tiennent à remercier Rajesh Kumar, Mike Mclaughlin, Pietro Schicker, James Carlson et John O'Neil de leurs contributions à la présente proposition.


11. Références


[ATM98] The ATM Forum, "ATM Security Framework Version 1.0", af-sec- 0096.000, février 1998.


[ATM01] The ATM Forum, "ATM Security Specification v1.1", af-sec-0100.002, mars 2001.


[I.363.2] Recommandation UIT-T I.363.2, "BISDN ATM Adaptation layer specification: Type 2 AAL (AAL2)", septembre 1997.


[I.366.1] Recommandation UIT-T I.366.1, "Segmentation and Reassembly Service Specific Convergence Sublayer for the AAL type 2", juin 1998.


[Q.921] Recommandation UIT-T Q.921, "ISDN User-Network Interface-Data Link Layer Specification", mars 1993.


[Q.2630.2] Recommandation UIT-T Q.2630.2, décembre 2000.


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


[RFC1889] H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : protocole de transport pour applications en temps réel", janvier 1996. (Obsolète, voir RFC3550 STD64)


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


[RFC2508] S. Casner, V. Jacobson, "Compression d'en-têtes IP/UDP/RTP pour liaisons séries à bas débit", février 1999. (P.S.)


[RFC3153] R. Pazhyannur, I. Ali, C. Fox, "Multiplexage en PPP", août 2001. (P.S.)


[RFC3337] B. Thompson, T. Koren, B. Buffam, "Extensions de classes pour PPP sur la couche 2 d'adaptation du mode de transfert asynchrone", décembre 2002. (P.S.)


12. Adresse des auteurs


Bruce Thompson

Tmima Koren

Bruce Buffam

Cisco Systems, Inc.

Cisco Systems, Inc.

Seaway Networks

170 West Tasman Drive

170 West Tasman Drive

One Chrysalis Way, Suite 300,

San Jose, CA 95134

San Jose, CA 95134

Ottawa, Canada

USA

USA

K2G-6P9

téléphone : +1 408 527-0446

téléphone : +1 408 527-6169

téléphone: +1 613 723-9161

mél : brucet@cisco.com

mél : tmima@cisco.com

mél : bruce@seawaynetworks.com


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


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


Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.


Le présent document et les informations y contenues sont fournies 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 ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.


Remerciement

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

page - 9 -