Extensions de classe pour PPP sur couche 2 d’adaptation en 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) sur la couche 2 d’adaptation du mode de transfert asynchrone (ATM, Asynchronous Transfer Mode) définit l’encapsulation qui permet qu’une session PPP soit transportée sur un circuit virtuel ATM en utilisant la couche d’adaptation ATM n° 2 (AAL2, ATM Adaptation Layer 2). Le présent document définit un ensemble d’extensions de classe à PPP sur AAL2 qui mettent en œuvre une fonctionnalité équivalente à PPP multi classe multi liaison sur un seul circuit virtuel ATM. Au lieu d’utiliser le PPP multi liaison comme base de la fonction de fragmentation, le présent document utilise la fonction de la sous couche de convergence spécifique du service de segmentation et réassemblage qui est déjà exigée comme format d’encapsulation de base de PPP sur AAL2.

1. Introduction

Utiliser AAL2 comme couche d’adaptation pour le transport PPP sur ATM donne un transport efficace en bande passante pour les applications IP qui génèrent de petits paquets. Un exemple d’application IP qui génère de petits paquets est la voix encapsulée dans RTP (Voix sur IP).

En plus de l’efficacité de la bande passante, les applications en temps réel telles que la voix exigent une faible latence. La [RFC2689] décrit une architecture pour fournir des services de transport pour des applications en temps réel sur des liaisons à faible débit binaire. Les principaux composants de l’architecture sont un format d’encapsulation de temps réel pour les liaisons asynchrones et synchrones à faible débit, une architecture de compression d’en-tête optimisée pour les flux en temps réel, des éléments de protocole de négociation utilisés entre les routeurs (ou entre les hôtes et les routeurs) et les protocoles d’annonce utilisés par les applications pour permettre que cette négociation ait lieu.

PPP multi classe multi liaison [RFC2686] définit une solution en mode fragment pour la partie format d’encapsulation en temps réel de l’architecture définie dans la [RFC2689], c’est-à-dire, pour l’envoyeur de type fragments en file d’attente. Comme décrit plus en détails dans le document d’architecture, un format d’encapsulation en temps réel est exigé pour garantir une faible latence en présence de grands paquets qui ne sont pas en temps réel. Par exemple, un paquet de 1500 octets sur un circuit virtuel ATM à 128 kbit/s rend cette liaison indisponible pour la transmission d’informations en temps réel pendant environ 100 ms. Cela ajoute un cas de pire délai qui est cause que les applications en temps réel fonctionnent avec des délais d’aller-retour qui sont trop élevés pour de nombreuses tâches interactives. PPP multi classe multi liaison définit un ensemble d’extensions à PPP multi liaison [RFC1990] qui permettent à l’envoyeur de fragmenter les paquets de diverses priorités en plusieurs classes de fragments, permettant aux paquets de priorité élevée d’être envoyés entre les fragments de priorités inférieures.

Le présent document définit un ensemble d’extensions de classes à PPP sur AAL2 [RFC3336] qui met en œuvre une fonctionnalité équivalente à celle de PPP multi classe multi liaison sur un seul circuit virtuel ATM. Au lieu d’utiliser PPP multi liaison comme base de la fonction de fragmentation, le présent document utilise la fonctionnalité de la sous couche de segmentation et réassemblage spécifique de service (SSSAR) [I.366.1] qui est déjà exigée comme format de base d’encapsulation de PPP sur AAL2.

En plus d’assurer la fragmentation, le service de transport en temps réel doit permettre que des fragments de priorité élevée soient envoyés entre des fragments de priorités inférieures. Cela peut être réalisé dans PPP sur AAL2 en permettant qu’une seule session PPP s’étende sur plusieurs identifiants de canal de CPS AAL2 [I.363.2]. Une fois qu’une session PPP s’étend sur plusieurs identifiants de canal AAL2, l’ID de canal peut être utilisé pour identifier la classe à laquelle appartient un fragment. Les fragments qui appartiennent à une classe de priorité élevés peuvent être envoyés en utilisant un identifiant de canal AAL2 particulier. Les fragments de classes de priorité inférieures peuvent être envoyés en utilisant des identifiants de canal AAL2 différents. Une fois que plusieurs classes de fragments sont identifiées en utilisant des identifiants de canal AAL2 différents, la couche CPS AAL2 peut être utilisée pour envoyer des fragments qui appartiennent à une classe de priorité élevée entre des fragments de priorités inférieures.

Les extensions fondées sur la classe à PPP sur AAL2 utilisent les services existants des couches SSCS et CPS AAL2 déjà spécifiés dans PPP sur AAL2. À cause de cela, les extensions décrites dans le présent document peuvent être vues comme une solution de remplacement souhaitable à PPP multi classe multi liaison en fournissant un service de transport fondé sur la classe avec PPP sur AAL2.

1.1 Langage de spécification

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

2. Exigences

Le présent document suppose les mêmes exigences de service que définies dans PPP multi classe multi liaison [RFC2689]. Le lecteur se reportera à la Section 2 de PPP multi classe multi liaison pour les exigences générale d’un service de fragmentation/préemption multi classe.

3. Extensions de classe pour PPP sur AAL2

PPP sur AAL2 utilise la sous couche segmentation et réassemblage spécifique de service (SSSAR, Service Specific Segmentation and Reassembly Sublayer) [I.366.1] pour le type 2 AAL. La sous couche SSSAR est utilisée pour segmenter les paquet PPP en trames qui peuvent être transportées en utilisant CPS AAL2. La sous couche SSSAR utilise des codets UUI AAL2 différents pour indiquer si un segment est le dernier segment d’un paquet ou non. SSSAR donne la fonction de fragmentation de base pour tous les paquets encapsulés en utilisant PPP sur AAL2. La couche SSSAR fragmente tous les paquets en fragments de 64 octets.

La couche CPS AAL2 définit un identifiant de canal qui est utilisé pour identifier plusieurs flux de paquets au sein d’un seul circuit virtuel ATM. Dans le présent document, l’identifiant de canal CPS AAL2 est utilisé pour identifier la classe de préemption à laquelle appartient un fragment de paquet. Comme l’identifiant de canal est utilisé pour identifier différentes classes de préemption, les fragments de paquets provenant de chaque classe de trafic DOIVENT recevoir des identifiants de canal différents. De plus, chaque session PPP DOIT avoir au moins autant d’identifiants de canal alloués qu’il y a de classes de trafic préemptable différentes.

Pour permettre que les paquets PPP soit affectés à des classes de préemption différentes, les paquets PPP doivent être classés en plusieurs classes de préemption lorsque ils sont fragmentés en utilisant SSSAR. De nombreuses méthodes de classement peuvent être utilisées pour déterminer la classe à laquelle appartient un paquet PPP particulier. Le document d’architecture [RFC2689] décrit les solutions de remplacement possibles qui PEUVENT être utilisées pour mettre en œuvre un schéma de classement en temps réel.

Une fois que les paquets ont été classés dans les différentes classes de préemption, chaque classe de trafic est alors affectée à un identifiant de canal différent. Comme les fragments provenant de chaque classe de trafic sont maintenant transmis en utilisant un identifiant de canal distinct, la couche CPS AAL2 peut être utilisée pour programmer des fragments provenant de classes différentes. La spécification CPS AAL2 [I.363.2] ne spécifie pas une méthode pour programmer les charges utiles CPS AAL2 provenant d’identifiants de canal différents. La méthode de programmation exige que la couche CPS AAL2 dépende des exigences de temps réel des applications qui utilisent ce service. Certaines applications en temps réel PEUVENT exiger l’utilisation d’un programmeur de CID fondé sur la priorité. D’autres applications PEUVENT n’exiger qu’un programmeur équitable ou pondéré de CID. Les mises en œuvre des extensions de transport en temps réel de PPP sur AAL2 DEVRAIENT mettre en œuvre des programmeurs de CID de CPS AAL2 qui satisfont aux exigences des applications multi classe en temps réel.

4. Exemple de mise en œuvre : extensions fondées sur la classe pour le service vocal

Lorsque PPP sur AAL2 est utilisé pour transporter à la fois des paquets de voix et des paquets qui n’en sont pas sur des circuits virtuels ATM à faible bande passante, il peut être nécessaire de préempter la transmission de gros paquets de données afin de transmettre un paquet de voix avec un retard minimal. L’exemple de mise en œuvre décrit ci-dessous montre comment les extensions de classes pour PPP sur AAL2 peuvent être utilisées pour prendre en charge le service de transport de voix en temps réel sur des circuits virtuels ATM à faible bande passante. Pour garantir une faible latence et peu de pertes pour le transport de la voix, le circuit virtuel ATM de cet exemple doit être fourni en utilisant une classe de trafic en temps réel comme VBRnrt ou VBRrt.

Pour le simple service vocal décrit ci-dessus, deux classes suffisent pour garantir une faible latence aux paquets vocaux. La session PPP sur AAL2 peut dans ce cas être configurée de façon à fonctionner à travers deux identifiants de CPS AAL2. Un identifiant de canal est utilisé pour transporter les grands paquets de données tandis que l’autre identifiant de canal est utilisé pour transporter les paquets vocaux en temps réel.

Les paquets qui arrivent à l’interface PPP doivent d’abord être classés soit comme appartenant à la classe en temps réel, soit comme appartenant à la classe de données. Un classeur simple qui peut être utilisé pour classer les paquets à cette couche est la taille du paquet.

Les grands paquets sont alloués à la classe de trafic non en temps réel (ou de données) et les petits paquets le sont à la classe de trafic en temps réel. La taille de paquet utilisée pour discriminer entre paquets en temps réel et ceux qui ne le sont pas peut varier selon l’application et le taux de transmission du circuit virtuel.

Une fois que les paquets ont été classés, ils sont maintenant fragmentés en utilisant la couche SSSAR de PPP sur AAL2. Des instances distinctes de la fonction de fragmentation de SSSAR fonctionnent sur chacun des deux identifiants de canal alloués à la session PPP.

Les fragments qui viennent des fonctions de SSSAR sont maintenant programmés sur le circuit virtuel AAL2 en utilisant la couche CPS AAL2. La plupart des mises en œuvre de SAR AAL2 utilisent actuellement la programmation équitable à travers plusieurs identifiants de canal AAL2. Comme le programmateur CPS AAL2 met en œuvre la programmation équitable, les fragments en temps réel vont attendre au plus pendant la transmission d’un seul fragment qui n’est pas en temps réel sur le circuit virtuel AAL2 avant d’être programmés.

5. Considérations pour la sécurité

On estime que le fonctionnement de ce protocole n’est ni plus ni moins sûr que le fonctionnement de PPP sur AAL2 [RFC3336].

6. Remerciements

Les auteurs remercient James Carlson de ses contributions à la présente proposition.

7. Références

[I.366.1] Recommandation UIT-T I.366.1, "Sous-couche de convergence spécifique du service de segmentation et de réassemblage pour le type 2 AAL", juin 1998.

[I.363.2] Recommandation UIT-T I.363.2, "Spécification de la couche d’adaptation ATM RNIS-LB : Type 2 AAL (AAL2)", septembre 1997.

[RFC1990] K. Sklower et autres, "Protocole multiliaison en PPP (MP)", août 1996. (Remplace RFC1717) (D.S.)

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

[RFC2686] C. Bormann, "Extension Multi-classe à PPP multi-liaison", septembre 1999. (P.S.)

[RFC2689] C. Bormann, "Fourniture de services intégrés sur liaisons à faible débit", septembre 1999, (Information)

[RFC3336] B. Thompson et autres, "PPP sur la couche 2 d'adaptation du mode de transfert asynchrone (AAL2)", décembre 2002. (P.S.)

8. Adresse des auteurs

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