RFC2686 page - 7 - Bormann

Groupe de travail Réseau

C. Bormann

Request for Comments : 2686

Universitaet Bremen TZI

Catégorie : En cours de normalisation

septembre 1999

Traduction Claude Brière de L'Isle





Extension multi-classe au protocole PPP multi-liaison




Statut du présent mémoire

Le présent mémo définit un protocole expérimental pour la communauté Internet. Il ne spécifie en aucune façon une norme Internet. Il réclame une discussion et des suggestions pour son amélioration. La distribution de ce mémoire n’est soumise à aucune restriction.

 

Notice de copyright

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

 

Résumé

Un document voisin décrit une architecture pour la fourniture de services intégrés sur des liaisons à faible débit binaire, telles que des lignes de modem, des canaux B du RNIS, et des liaisons sous T1 [1]. Les principaux composants de l’architecture sont : un format d’incorporation en temps réel pour les liaisons à bas débit asynchrones et synchrones, une architecture de compression d’en-tête optimisée pour les flux en temps réel, des éléments de protocoles de négociation utilisés entre les routeurs (ou entre hôtes et routeurs), et des protocoles d’annonce utilisés entre les applications pour permettre cette négociation. Le présent document propose la solution orientée fragment pour la partie format d’incorporation en temps réel de l’architecture. L’approche générale est de commencer par le protocole PPP de fragmentation multi liaison [2] et de fournir un petit nombre d’extensions pour ajouter des fonctionnalités et réduire la redondance.

1. Introduction

À titre d’extension aux services "au mieux" pour lesquels l’Internet est bien connu, des types de services supplémentaires ("services intégrés") qui prennent en charge le transport d’informations multimédia en temps réel ont été développés et déployés dans l’Internet. Le présent document définit la solution orientée fragment pour la partie format d’incorporation en temps réel de l’architecture, c’est-à-dire pour l’envoyeur du type file d’attentes de fragments [1]. Comme décrit plus en détails dans le document d’architecture, un format d’incorporation en temps réel est nécessaire car, par exemple, un paquet de 1500 octets sur une liaison modem à 28,8 kbit/s rend cette liaison indisponible pour la transmission d’informations en temps réel pendant environ 400 ms. Cela ajoute un délai dans le plus mauvais cas qui amène les applications en temps réel à fonctionner avec des délais d’aller–retour de l’ordre d’au moins une seconde -- inacceptable pour une conversation en temps réel. Les extensions au protocole PPP définies dans le présent document permettent à un expéditeur 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. Un document voisin fondé sur ces extensions [5] définit une solution orientée suspension/reprise pour ces cas où le meilleur délai possible est nécessaire et où les envoyeurs sont du type 1 [1].  

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", "RECOMMANDE", "PEUT", et "FACULTATIF" doivent être interprétés comme décrit par la RFC 2119 [8].

 

2. Exigences

Le principal objectif de conception pour les composants d’une architecture qui traite des flux multimédia en temps réel sur des liaisons à faible débit binaire est de minimiser le délai de bout en bout. Plus précisément, le plus mauvais cas de délai (après retrait des possibles points aberrants, qui sont équivalent à des pertes de paquet du point de vue d’une application) est ce qui détermine les points hors-jeu choisis par les applications et donc le délai réellement perçu par l’utilisateur.


De plus , chaque tentative devrait se fixer visiblement pour objectif de maximiser la bande passante réellement disponible pour les données de support ; les redondances doivent être minimisées.  La solution ne devrait pas faire peser une charge inutile sur les flux en différé. En particulier, les MTU habituels devraient être disponibles pour ces flux.  L’approche la plus générale devrait fournir la capacité de suspendre tout paquet (en temps réel ou non) au profit d’un paquet en temps réel plus urgent, jusqu’à un nombre infini de niveau de fragmentation. D’un autre côté, il est vraisemblable qu’il y aura rarement une exigence qu’un paquet en temps réel suspende un autre paquet en temps réel qui ne serait pas au moins deux fois aussi long. Normalement, la plus grande taille de paquet à laquelle on peut s’attendre sur une liaison PPP est le MTU par défaut de 1500 octets. Les plus petites tailles de paquets de priorité élevée seront vraisemblablement de l’ordre de 22 octets (paquets RTP/G.723.1 compressés). On peut s’attendre à un gamme de tailles de paquets dans un rapport de 1 à 72, ce qui se traduit par une exigence maximale de huit niveaux de suspension (incluant un niveau où des paquets longs en temps réel suspendent des paquets longs en différé). Sur les modems à 28,8 kbit/s, il semble y avoir une exigence pratique d’au moins deux niveaux de suspension (c’est-à-dire, l’audio suspend tout paquet plus long y compris la vidéo, la vidéo suspend d’autres paquets très longs).  Au niveau architectural, il y a plusieurs exigences supplémentaires pour le schéma de fragmentation :  

a)   Le schéma doit être suffisamment prévisible pour que le contrôle d’admission puisse prendre des décisions fondées sur ses caractéristiques. Comme expliqué en [1], cela ne sera souvent le cas que lorsque des indication supplémentaires sur les caractéristiques du flux lui-même sont disponibles (conseils d’application).

b)   Le schéma doit être résistant aux erreurs, au moins au même niveau de détection d’erreurs que PPP.

c)   Le schéma doit en général coopérer harmonieusement avec PPP. En particulier, il devrait être aussi compatible que possible avec les normes PPP existantes. Sur une liaison qui (sur la base de la négociation PPP) fait usage du schéma, il devrait toujours être possible de retomber sans ambiguïté sur le protocole LCP standard (Protocole de commande de liaison PPP [6, 7]).

d)   Le schéma doit bien fonctionner avec les microprocesseurs et systèmes de routeur existants. (Voir en [1] une discussion plus approfondie des modèles de mise en oeuvre.) Pour les liaisons synchrones cela signifie d’utiliser un tramage HDLC ; avec beaucoup de matériels existants, il est aussi difficile de déconnecter le CRC HDLC par trame. Pour les liaisons asynchrones, il y a beaucoup plus de liberté de conception ; d’un autre côté, une conception qui les traite de façon très différente des liaisons synchrones perdrait un grand nombre des propriétés attractives de PPP.

e)   Le schéma doit être à l’épreuve du futur. En particulier, l’émergence de modems fondés sur V.80 peut changer de façon significative la façon dont PPP est utilisé avec les modems.


Le présent document ne vise pas des exigences supplémentaires qui peuvent être pertinentes avec le relais de trame ; cependant, il semble n’y avoir que peu de problèmes à appliquer les principes du présent document au "PPP en relais de trame" [3].  

3. Utilisation de PPP multi-liaison en l’état

 Transmettre seulement une partie d’un paquet pour permettre à du trafic de priorité plus élevée de passer et reprendre sa transmission plus tard est une sorte de fragmentation. Le protocole PPP Multilink existant (MP, [2]) fournit une numérotation de séquence et des bits de début/fin, ce qui permet de découper les paquets en fragments (Figure 1).

Figure 1 : Format de fragment court de numéro de séquence multi liaison [2]

 

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

en-tête PPP : | Adresse 0xff | Contrôle 0x03 |

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

| PID(H) 0x00 | PID(L) 0x3d |

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

en-tête MP : |B|E|0|0| numéro de séquence |

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

| données de fragment |

| . |

| . |

| . |

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

FCS PPP : | FCS |

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


(Noter que les octets adresse, contrôle, et PID de plus fort poids sont souvent négociés pour être compressés.)



L’accroissement monotone des numéros de séquence du protocole MP (des numéros contigus sont nécessaires pour tous les fragments d’un paquet) ne permet pas la suspension de l’envoi d’une séquence de fragments d’un paquet afin d’envoyer un autre paquet. Il est, cependant, possible d’envoyer des paquets intervenants qui ne sont pas incorporés dans des en-têtes multi-liaison ; et don, le protocole MP accepte deux niveaux de priorité.  L’approche multiliaison telle quelle peut être construite en utilisant les normes existantes ; la capacité multiliaison est maintenant largement répandue et seul le côté envoyeur a besoin de savoir qu’on est en train de l’utiliser pour donner une priorité aux paquets en temps réel.  

3.1 Limitations du multi-liaison tel quel

 Le multi-liaison tel quel n’est pas une solution finale pour un certain nombre de raisons. D’abord, à cause du seul numéro de série à croissance monotone, il n’y a qu’un seul niveau de suspension : les "gros" paquets qui sont envoyés via multi-liaison peuvent être suspendus par des "petits" paquets envoyés en-dehors du multi-liaison ; ces derniers ne sont pas fragmentables (et donc, le contenu d’un paquet ne peut pas être envoyé en parallèle sur plusieurs liaisons ; si les paquets sont envoyés en boucles sur plusieurs liaisons, leur ordre de traitement à réception peut différer de leur ordre d’envoi).  Un problème non résolu par cette spécification est que l’en-tête multi-liaison est relativement grand ; lorsque les limites du délai deviennent petites (pour des mises en œuvre du type file d’attente de fragments ) la redondance peut devenir significative.


4. Extension du multi-liaison PPP à plusieurs classes


L’approche évidente pour fournir plu d’un niveau de avec le multi-liaison PPP est de faire tourner Multilink plusieurs fois sur une liaison. Comme il est défini, Multilink ne donne aucun moyen d’avoir plus d’une instance active. Heureusement, un certain nombre de bits sont inutilisés dans l’en-tête multilink : deux bits dans le format court de numéro de séquence (comme on peut le voir à la Figure 1), six dans le format long de numéro de séquence.  Le présent document définit les bits (certains des bits) précédemment inutilisés comme un numéro de classe :


Figure 2 : Format court de fragment de numéro de séquence avec classes

 

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

en-tête PPP : | Adresse 0xff | Contrôle 0x03 |

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

| PID(H) 0x00 | PID(L) 0x3d |

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

en-tête MP : |B|E|cls| numéro de séquence |

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

| données de fragment |

| . |

| . |

| . |

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

FCS PPP : | FCS |

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


Chaque classe marche avec une copie distincte du mécanisme défini dans [2], c’est-à-dire, utilise un espace séparé de numéro de séquence et de mémoire tampon de réassemblage.


De même, pour le format long de numéro de séquence :








Figure 3 : Format long de fragment de numéro de séquence avec classes


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

en-tête PPP : | Adresse 0xff | Contrôle 0x03 |

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

| PID(H) 0x00 | PID(L) 0x3d |

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

en-tête MP : |B|E| class |0|0|numéro de séqu.|

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

| numéro de séquence (L) |

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

| données de fragment |

| . |

| . |

| . |

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

FCS PPP : | FCS |

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


Conjointement avec la capacité à envoyer des paquets sans en-tête multi-liaison, cela procure quatre niveaux de suspension avec des en-têtes de 12 bits (probablement suffisant pour beaucoup d’applications pratiques) et seize niveaux avec des en-têtes de 24 bits (seuls quatre des six bits libres sont utilisés dans ce cas – sur la base de l’explication donnée ci-dessus, seize niveaux devraient normalement être plus que suffisant).

5. Elision de préfixe : compression des octets d’en-tête communs

Pour certaines applications, tous les paquets d’une certaine classe auront un identifiant de protocole commun (ou même plus d’un octet de préfixe commun). Dans ce cas, l’optimisation suivante est possible : le numéro de classe peut être associé à un préfixe d’octets qui sont retirés de chaque paquet avant transmission et qui sont implicitement réaffectés au paquet ré assemblé après réception.


Noter que si seulement quelques uns des paquets à transmettre à un certain niveau de priorité ont le préfixe commun, il peut quand même être possible d’utiliser cette méthode en allouant deux numéros de classe et d’associer seulement un d’entre eux au préfixe. (C’est la raison pour laquelle quatre des bits inutilisés dans le format long de numéro de séquence ont été alloués au numéro de classe au lieu des trois qui devraient suffire normalement.)  L’liaison de préfixe n’est pas un remplacement de la compression d’en-tête ou de données : elle permet aux mises en œuvre de comprimer des préfixes qui souvent ne peuvent être atteints par les méthodes de compression d’en-tête ou de données.  

6. Options négociables

Les options LCP PPP suivantes sont déjà définies par le protocole MP :

- Unité reconstruite reçue maximum multi-liaison

- Format court d’en-tête de numéro de séquence multi-liaison

- Séparateur de point d’extrémité


Le présent document définit deux nouvelles options LCP :

- Format d’en-tête multi-liaison

- Elision de préfixe

 

6.1 Option de format d’en-tête multi-liaison

 Ci-dessous figure un résumé du format de l’option de format d’en-tête multi-liaison. Les champs sont transmis de gauche à droite.







Figure 4 :


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 = 27 | Longueur = 4 | Code |n° classe de sp|

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


Cette option LCP informe l’homologue de ce que la mise en œuvre souhaite recevoir des fragments avec un format donné par le numéro de code, avec le nombre maximum de classes de suspension (voir ci-dessous) donné.  Lorsque cette option est négociée, la mise en œuvre qui accepte DOIT soit transmettre tous les paquets multi-liaison suivants sur toutes les liaisons du faisceau avec le format d’en-tête multi-liaison donné, soit faire un Configure-Nak ou un Configure-Reject pour l’option. (Noter qu’une mise en oeuvre PEUT continuer d’envoyer des paquets en-dehors de la multi-liaison dans tous les cas.) Si cette option est offerte sur une liaison qui est destinée à se joindre à un faisceau existant, un système DOIT offrir la même valeur d’option de format d’en-tête multi-liaison que celle qui a été précédemment négociée pour le faisceau, ou aucune si aucune n’a été négocié précédemment.  Les valeurs définies dans le présent document pour les besoins de cette option sont :

- Code = 2 : format long de fragment de numéro de séquence avec classes

- Code = 6 : format court de fragment de numéro de séquence avec classes


L’option de format d’en-tête multi-liaison NE DOIT PAS survenir plus d’une fois dans une Demande de configuration ou Accusé de réception de configuration, et si elle est présente, l’option de format court de numéro de séquence ([2]) NE DOIT PAS être aussi présente.  Si aucune instance de cette option ou de l‘option de format court de numéro de séquence n’est présente, mais qu’une option MRRU [2] est présente, par défaut, seuls les en-tête multi-liaison de numéro de séquence avec la classe 0 sont alors utilisés, ce qui est équivalent au code 2 et au numéro de classe de suspension 1. Une instance de l’option de format court d’en-tête de numéro de séquence est équivalente à une instance de cette option avec un code égal à 6 et un numéro de classe de suspension égal à 1.  Le nombre de classes de suspension limite le nombre de classes permises : seuls les numéros de classe inférieurs à cette limite peuvent être utilisés pour les classes de suspension . Les mises en œuvre PEUVENT vouloir négocier un nombre plus petit que le format de paquet ne le permet pour limiter les exigences d’espace de mémoire tampon de réassemblage. Les mises en œuvre DEVRAIENT au moins prendre en charge la valeur de 4 pour le format court de fragment de numéro de séquence, et la valeur 8 pour le format long de fragment de numéro de séquence, à moins d’une configuration différente. Les combinaisons binaires qui indiqueraient des numéros de classe en dehors de la gamme négociée PEUVENT être utilisés pour une autre sémantique si elle est négociée par des moyens qui sortent du domaine d’application du présent document (par exemple, [6]).  

6.2 Option d’élision de préfixe

Cette option LCP informe l’homologue de ce que, dans chacune des classes données, la mise en œuvre s’attend à ne recevoir que des paquet avec un certain préfixe ; ce préfixe n’est pas envoyé au titre des informations du ou des fragments de cette classe. Par défaut, ce préfixe commun est vide pour toutes les classes. Lorsque cette option est négociée, les mises en, œuvre qui l’acceptent DOIVENT transmettre tous les paquets multi-liaison suivants de chacune des classes données avec le préfixe donné retiré du début du paquet ou faire Configure-Nak ou Configure-Reject pour l’option. Si aucun format n’a été négocié avec les classes, la classe numéro 0 peut être utilisée pour indiquer un préfixe commun pour tous les paquets envoyés avec des fragments multi-liaison.  A part les octets de type et de longueur communs à toutes les options LCP, l’option contient une séquence de zéro ou plus séquences d’un numéro de classe à un seul octet, d’une longueur à un seul octet du préfixe pour cette classe, et les octets dans ce préfixe :

Figure 5 :

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 = 26 |Longueur option| Classe |Longueur préf. |

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

| Préfixe.. | Classe |

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

|Longueur préf. | Préfixe...

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


L’option d’élision de préfixe NE DOIT PAS survenir plus d’une fois dans une Demande de configuration ou Non accusé de configuration. Si cette option est offerte sur une liaison qui est destinée à se joindre à un faisceau multi-liaison existant, un système DOIT offrir la même valeur d’option d’élision de préfixe que celle précédemment négociée pour le faisceau, ou aucune si aucune n’a été négociée précédemment.  NOTE POUR LA MISE EN ŒUVRE : comme avec la plupart des options PPP qui indique les capacités du récepteur à l’expéditeur, le sens de cette option est une indication du récepteur à l’expéditeur sur les paquets concernés. Souvent, seuls les expéditeurs ont un contrôle suffisant sur l’utilisation des classes pour être capable de fournir des valeurs utiles pour cette option. Un récepteur qui veut accepter des paquets à élision de préfixe DEVRAIT demander cette option avec un contenu vide ; l’expéditeur peut alors utiliser le Non accusé de configuration pour proposer la transposition de class à préfixe désirée.

7. Considérations sur la sécurité

Le fonctionnement de ce protocole est supposé n’être ni plus ni moins sûr que le fonctionnement du protocole multi-liaison PPP [2].  


8. Références

[1] Bormann, C., "Fourniture de services intégrés sur les liaisons à faible débit binaire", RFC 2689, septembre 1999.

[2] Sklower, K., Lloyd, B., McGregor, G., Carr, D. et T. Coradetti, "Protocole multi-liaison point à point", RFC 1990, août 1996.

[3] Simpson, W., "Protocole point à point en relais de trame", RFC 1973, juin 1996.

[4] Andrades, R. et F. Burg, "Extensions de tramage QOSPPP pour le protocole point à point", Travail en cours.

[5] Bormann, C., "PPP dans un tramage de type HDLC orienté temps réel", RFC 2687, septembre 1999.

[6] Simpson, W., éditoreu, "Protocole point à point (PPP)", STD 51, RFC 1661, juillet 1994.

[7] Simpson, W., éditeur, "PPP dans un tramage de type HDLC", STD 51, RFC 1662, juillet 1994.

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

9. Adresse de l’auteur

Carsten Bormann

Universitaet Bremen

FB3 TZI Postfach 330440

D-28334 Bremen,

GERMANY

Téléphone : +49.421.218-7024

Fax : +49.421.218-7000

mél : cabo@tzi.org


10. Remerciements

David Oran a suggéré d’utiliser PPP Multilink pour le tramage en temps réel et a rappelé à l’auteur ses tentatives antérieures pour rendre le multi-liaison plus utile à cette fin. Les participants à un déjeuner BOF à l’IETF 1996 à Montréal ont donné des indications utiles sur les option de conception dans des environnements variés. Les membres du sous-groupe ISSLL sur les liaisons à faible débit binaire (ISSLOW) ont aidé à réduire le grand ensemble d’options qu’avaient les versions initiales de cette spécification.


11. Déclaration de copyright

Copyright (C) The Internet Society (1999). 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 copyright ci-dessus et le présent et 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 copyright 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 copyright définies dans les procédures des ormes 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 successeurs ou ayant droits.


Le présent document et les informations qu’il contient 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 Internet Society.