Multiplexage en PPP

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 d’amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) 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.

Copyright

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

Résumé

Le présent document décrit une méthode pour réduire la redondance de tramage PPP (protocole point à point) utilisée pour transporter de petits paquets sur des liaisons lentes.

1. Description

La méthode, multiplexage PPP, envoie plusieurs paquets PPP encapsulés dans une seule trame PPP. Il en résulte que la redondance PPP par paquet est réduite. L’encapsulation PPP (par exemple avec PPP dans un tramage HDLC) ajoute plusieurs octets de redondance : un fanion HDLC (au moins un pour séparer les paquets adjacents) les octets des champs Adresse (0xFF) et Contrôle (0x03) un identifiant de protocole PPP de deux octets, et les deux octets du champs de CRC. Même si on négocie la suppression des champs Adresse et Contrôle et si l’identifiant de protocole PPP est compressé, chaque trame PPP encapsulée va comporter quatre octets de redondance. Lorsque les trames PPP sont tunnelées, comme dans L2TP [RFC2661], la redondance L2TP par trame PPP est significative.

L’idée clé est d’enchaîner plusieurs trames PPP encapsulées dans une seule trame PPP multiplexée en insérant un délimiteur avant le début de chaque trame. La description des délimiteurs est donnée au paragraphe 1.1. Les délimiteurs sont utilisés par le démultiplexeur pour séparer les trames PPP dans la trame multiplexée. Chaque trame PPP encapsulée dans la trame multiplexée est appelée une sous-trame PPP.

Durant la phase NCP de négociation PPP, un receveur peut offrir de recevoir des trames multiplexées en utilisant le protocole PPP de contrôle de multiplexage (PPPMuxCP) décrit à la Section 2. Une fois que PPPMuxCP a été négocié, l’émetteur peut choisir quelles trames PPP multiplexer. Les trames ne devraient pas être réordonnées, ni par le transmetteur, ni par le receveur sans considération de si elles arrivent au titre d’une trame PPP multiplexée ou par elles-mêmes.

Le schéma proposé est similaire à celui de l’option de tramage enchaîné [RFC1550]. Les différences clés sont que le multiplexage PPP est plus efficace et qu’il permet l’enchaînement de trames de taille variable. C’est différent du tramage enchaîné qui se restreint à des trames qui sont toutes de longueur fixe.

Comme avec tout schéma d’enchaînement, la mise en œuvre doit considérer le compromis entre un délai accru pour le multiplexage/démultiplexage et une redondance de paquet réduite lorsque la longueur de la trame multiplexée augmente.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119].

1.1 Format de charge utile

Le format de la trame PPP complète ainsi qu’avec plusieurs sous-trames pour PPP dans un tramage de style HDLC [RFC1662] est présenté à la Figure 1. Noter que sans considération de l’ordre dans lequel sont transmis les bits individuels, c’est-à-dire, bit de poids fort (MSB) en premier ou bit de moindre poids (LSB) en premier, le bit PFF sera vu comme étant le bit de moindre poids d’un octet qui contient à la fois le fanion de champ Protocole (PFF, Protocol Field Flag) et le champ de longueur de la sous-trame.

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

| En- +P|L| + + + +P|L| + + + |

| tête +F|X|Lon1 + Champ + + +F|X|LonN + Champ + + |

| PPP/ +F|T| + Prot. +Info1+ ~ +F|T| + Prot. +InfoN+ CRC |

| HDLC + | | + PPP 1 + + + | | + PPP N + + |

| (2-5) + (1-2 ) + (0-2) + + + (1-2) + (0-2) + + (2) |

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

Figure 1 : Sous-trames de multiplexage dans une trame PPP

En-tête PPP : L’en-tête PPP contient le champ Protocole PPP pour une trame PPP multiplexée (0x0059). Les options de compression d’en-tête PPP (ACFC et PFC) peuvent être négociées dans le protocole de contrôle des liaisons (LCP, Link Control Protocol) et pourraient donc affecter le format de cet en-tête.

Champ Longueur : Le champ Longueur consiste en trois sous-champs :

1. Fanion de champ Protocole (PFF) :

Le PFF se réfère au bit de poids fort du premier octet de chaque sous-trame. Ce champ d’un bit indique si l’identifiant de protocole PPP de la sous-trame suit le champ Longueur de la sous-trame. Pour la première sous-trame, le bit PFF pourrait être réglé à zéro si l’identifiant de protocole PPP de la première sous-trame est égal à la valeur de PID par défaut négociée dans le PPPMuxCP. PFF = 1 indique que le champ Protocole est présent (et suit le champ Longueur) pour cette sous-trame. PFF = 0 indique que le champ Protocole est absent pour cette sous-trame. Si PFF = 0, alors l’identifiant de protocole PPP est le même que celui de la sous-trame précédente avec PFF = 1, ou il est égal à la valeur de PID par défaut de l’option PPPMuxCP pour la première sous-trame. L’émetteur n’est obligé de retirer l’identifiant de protocole PPP pour aucune sous-trame.

2. Extension de longueur (LXT, Length Extension)

Ce champ de un bit indique si le champ Longueur fait un ou deux octets. Si le bit LXT est à un, le champ Longueur fait alors deux octets (un bit PFF, un bit d’extension de longueur, et 14 bits de longueur de sous-trame). Si le bit LXT est à zéro, le champ Longueur fait alors un seul octet (un bit PFF, un bit extension de longueur, et 6 bits de longueur de sous-trame).

3. Longueur de sous-trame (LON) :

C’est la longueur de la sous-trame en octets, champ Longueur non inclus. Cependant, il inclut bien l’identifiant de protocole PPP s’il est présent (c’est-à-dire, si PFF = 1). Si la longueur de la sous-trame est inférieure à 64 octets (inférieure ou égale à 63 octets) LXT est réglé à zéro et les six derniers bits du champ Longueur donnent la longueur de la sous-trame. Si la longueur de la sous-trame est supérieure à 63 octets, LXT est réglé à un et les 14 derniers bits du champ Longueur donnent la longueur de la sous-trame. La longueur maximale d’une sous-trame est de 16 383 octets. Les paquets PPP qui font plus de 16 383 octets vont devoir être envoyés dans leur propre trame PPP. Un émetteur n’est pas obligé de multiplexer toutes les trames de moins de 16 383 octets. Il peut choisir de ne multiplexer que les trames inférieures à une taille configurable dans une trame PPP multiplexée.

Champ Protocole : Ce champ contient la valeur du champ Protocole pour la sous-trame. Ce champ est facultatif. Si PFF = 1 pour une sous-trame, le champ Protocole est présent dans la sous-trame, autrement, il est déduit à la réception.

Le receveur DOIT prendre en charge la compression du champ de protocole (PFC, Protocol-Field-Compression) à un ou deux octets. L’émetteur DEVRAIT compresser les identifiants de protocole PPP dans ce champ qui ont un octet de poids fort de zéro (c’est-à-dire, des identifiants de protocole de 0x21 à 0xFD). Cette compression du champ Protocole dans chaque sous-trame PPP n’a pas de rapport avec la négociation de la PFC durant la négociation LCP qui affecte la longueur de l’identifiant de protocole des trames PPP multiplexées.

Champ Information : Ce champ contient le paquet réel à encapsuler. Toute trame peut être incluse ici à l’exception de la demande de configuration LCP, des trames ACK, NAK et Rejet et des trames PPP multiplexées. Si LCP est renégocié, le multiplexage PPP DOIT alors être désactivé jusqu’à ce que le protocole de contrôle de multiplexage PPP soit négocié.

1.2 Procédure chez l’émetteur

On propose une mise en œuvre simple de l’émetteur. Durant la transmission d’une trame PPP multiplexée, l’émetteur a un état variable, Last_PID, qui est utilisé pour détenir la valeur la plus récente du champ Protocole dans une sous-trame avec PFF=1. Au début du processus de multiplexage, Last_PID est réglé égal à la valeur de PID par défaut négociée dans PPPMuxCP. On utilise aussi un paramètre configurable par l’usager, la longueur maximale de sous-trame (MAX_SF_LEN) pour déterminer la taille maximale d’une trame PPP qui peut être multiplexée. La valeur de MAX_SF_LEN devrait être inférieure ou égale au minimum de MRU-2(taille maximum du champ Longueur) et de 16 383 (14 bits).

Après l’émission d’une trame PPP (multiplexée ou non) sur le canal, la logique de multiplexage PPP examine les mémoires tampons qui détiennent les trames PPP à transmettre. Dans le cas où il y a plusieurs trames, la logique de multiplexage PPP vérifie si la longueur de la première trame dans la mémoire tampon est inférieure ou égale à MAX_SF_LEN octets. Si c’est le cas, l’émetteur commence à compiler une trame PPP multiplexée avec la valeur du champ Protocole correspondant à Trame PPP multiplexée (0x59). Pour chaque sous-trame, le test pour décider d’ajouter le champ Protocole à une sous-trame est de comparer la valeur du champ Protocole de la sous-trame avec Last_PID. Si ils sont égaux, PFF est réglé à 0 et le champ Protocole est supprimé. Sinon, PFF est réglé à 1, le champ Protocole est inclus, après PFC, dans la sous-trame et Last_PID est réglé à la valeur du champ Protocole de la sous-trame actuelle. Les critères d’arrêt dans le processus d’enchaînement sont (i) lorsque la longueur de la prochaine sous-trame est supérieure à MAX_SF_LEN octets, ou (ii) la longueur de la trame PPP entière en incluant la nouvelle sous-trame excède le paramètre Unité maximum de réception (MRU) négocié durant LCP [RFC1661], ou (iii) qu’il n’y a plus d’autre sous-trame à enchaîner.

Les mises en œuvre peuvent choisir de plus d’utiliser des temporisateurs. Dans un pareil cas, la fin de temporisation s’ajoute aux conditions mentionnées ci-dessus comme critère d’arrêt du processus de multiplexage. De plus, il peut être désirable de limiter la taille maximum d’un paquet multiplexé à une quantité considérablement inférieure à la MRU en raison de la latence de multiplexage et des considérations d’erreur de paquet.

1.3 Procédure chez le receveur

Si est reçue une trame multiplexée, c’est-à-dire une trame avec une valeur de champ Protocole égale à Trame PPP multiplexée (0x0059), la trame est démultiplexée dans l’ordre en utilisant la logique de démultiplexage des entrées. De même qu’un émetteur, le receveur a une variable d’état appelée Last_rcvd_PID, qui est la valeur du champ Protocole dans la sous-trame la plus récemment démultiplexée avec PFF = 1. Last_rcvd_PID est initialisé à la valeur de PID par défaut négociée par PPPMuxCP. Si PFF = 0 pour une sous-trame, Last_rcvd_PID est ajouté au début de la sous-trame avant traitement, comme déterminé par le champ Longueur, à la logique PPP. Si PFF = 1 pour une sous-trame, Last_rcvd_PID est réglé à cette valeur et la sous-trame, comme déterminé par le champ Longueur, est passé à la logique PPP. Le reste de la trame est retourné au démultiplexeur. Chaque sous-trame successive est traitée de la même façon. Ce traitement s’achève lorsque le reste de la trame est vide, ou lorsque le champ Taille d’une sous-trame excède la quantité de données restante dans un paquet. Dans ce dernier cas, il y a une erreur soit dans le champ Longueur de la dernière sous-trame, soit dans le champ Longueur d’une des sous-trames précédentes. Dans l’un et l’autre cas, la dernière sous-trame doit être éliminée par la logique de démultiplexage.

Il est illégal de mettre une trame multiplexée dans une trame multiplexée.

2. Protocole de contrôle de réseau PPP pour multiplexage PPP (PPPMuxCP)

Un receveur va offrir sa capacité à recevoir des trames multiplexées en négociant NCP pour le multiplexage PPP, PPPMuxCP. La valeur du champ Protocole pour des trames PPPMuxCP est 0x8059. PPPMuxCP est similaire aux autres NCP tels que IPCP [RFC1332]. Un émetteur peut ne pas envoyer de trame multiplexée tant que l’homologue n’a pas offert de recevoir des trames multiplexées. La prise en charge de la réception de trame multiplexée est négociée indépendamment dans chaque direction. La réussite de la négociation de PPPMuxCP n’oblige pas un homologue à transmettre des trames multiplexées.

Au titre de la négociation de PPPMuxCP, une option 'PID par défaut' est toujours négociée. Cela permet à l’émetteur de transmettre la première sous-trame d’une trame PPP multiplexée sans un PID (PFF = 0), résultant donc en l’économie d’un ou deux octets. Noter que la négociation d’un PID par défaut n’exige pas que l’émetteur envoie la première sous-trame avec PFF = 0 même si le faire optimiserait la transmission. Et, comme toujours, l’option (et donc le PID par défaut) est négocié par le receveur, c’est-à-dire que le receveur va interpréter un paquet PPPmux reçu en utilisant le PID par défaut qu’il a offert.

Les trames LCP NE DOIVENT PAS être envoyées dans des trames multiplexées. La seule option dans PPPMuxCP est la négociation de PID par défaut, qui est montrée ci-dessous

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

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

| Type = 1 | Longueur = 4 | PID par défaut |

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

Figure 2 : Option PID par défaut pour PPPMuxCP

3. Interaction avec le protocole multi liaison PPP (MP)

L’option PPP de trame multiplexée est négociée par un NCP. LCP est négocié sur chaque liaison membre d’un faisceau multi liaisons et non sur le faisceau lui-même [RFC1990]. Donc, en cas de MP, PPPmux ne peut pas être négocié pour les liaisons individuelles, mais seulement pour le faisceau.

Donc, du côté émetteur, le multiplexage PPP survient toujours avant l’encapsulation PPP multi liaisons. Sur une liaison, un en-tête MP (si présent) DOIT être en dehors d’un en-tête PPPmux (si présent). Les trames multi liaisons NE DOIVENT PAS être envoyées dans des trames multiplexées.

4. Interaction avec CCP et ECP

Le multiplexage PPP doit être effectué en dessous (après) de tout CCP et/ou ECP de niveau faisceau, et au dessus (avant) de MP et de tout CCP et/ou ECP par liaison. Donc, pour négocier une hypothétique séquence de chemin de transmission CCP -> PPPMux -> ECP, la version niveau faisceau de CCP (80fd) et la version par liaison de ECP (8055) sont négociées avec l’option PPPMux.

Une mise en œuvre qui ne peut pas effectuer le multiplexage PPP par dessus CCP ou ECP DOIT produire un Rejet de protocole pour les formes par liaison de CCP et ECP si PPPMux a été négocié.

5. Considérations pour la sécurité

Le présent document n’impose aucune considération supplémentaire sur la sécurité au delà de celles qui s’appliquent aux schémas PPP et compression d’en-tête sur PPP.

6. Remerciements

Les auteurs tiennent à remercier les contributeurs de la liste de diffusion PPPext, et en particulier James Carlson, pour ses précieux apports au présent document.

7. Références

[RFC1332] G. McGregor, "Protocole de contrôle de protocole Internet point à point (IPCP)", mai 1992. (MàJ 3241)

[RFC1550] S. Bradner et A. Mankin, "Prochaine génération IP (IPng) appel à contributions", décembre  1993. (Info.)

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

[RFC1662] W. Simpson, éditeur, "PPP en trames de style HDLC", STD 51, juillet 1994. (Remplace la RFC1549)

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

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

8. Adresse des auteurs

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2001). 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.