Page
d’accueil 1- Qu’est ce que MLPPP 2-
MLPP en pratique 3- Liens utiles 4- Présentation MLPPP (ppt) 5- Glossaire
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Qu’est ce que le MLPPP ? 1) Introduction De façon simple MLPPP permet
de combiner plusieurs liaisons physiques existantes en une seule voie logique
entre deux sites communicant via Internet. Le but étant d'augmenter
le débit entre deux points A et B lors d'échanges. Et de revenir à la
situation initiale une fois l'objectif
atteint lors des communications. MLPPP s'appuie sur le PPP
( Point to Point Protocole ) afin d'arriver à cette optimisation du débit. MLPPP et PPP sont des RFC
(Request For Comment) autrement dit des protocoles standards qui
émanent de l' I.E.T.F ( Internet Engineering Task Force ) dont le site est: http://www.ietf.org L'I.E.T.F a pour
instance supérieure l'I.A.B ( Internet Architecture Board ). Les RFC sont
l'aboutissement de propositions de la part des groupes de travail de
l'I.E.T.F. Ces propositions ont pour objectif d'apporter des évolutions
techniques au sein de l'internet en tenant compte des solutions des
constructeurs, des opérateurs et de la recherche. Nous vous proposons une
explication simplifiée des protocoles PPP et MLPPP et vous proposons de vous
reporter aux explications exhaustives des RFC en vous connectant sur :
http://www.ietf.org/rfc/rfc1990.txt?number=1990
http://www.ietf.org/rfc/rfc1661.txt?number=1661 2) Définition
du PPP ou Point to Point Protocol Ce protocole est de
niveau 2 pour le modèle OSI ( Open Systems Interconnection http://www.iso.ch/iso/en/ISOOnline.frontpage).
Il s'agit ici d'un modèle qui sert de référence pour
l’harmonisation de l'interconnexion des systèmes ouverts. Voici un schéma donnant
les différents niveaux ou couches du modèle OSI. Cette représentation est
somme toute conceptuelle mais permet de se faire une idée de la gestion des
données entre deux machines. Remarque, pour la pile TCP/IP les couches ou
niveaux 5, 6 et 7 sont fondues en une. Le modèle TCP/IP n'émane pas
directement de l'O.S.I mais il s'en inspire.
PPP comme le schéma
l'indique se trouve au niveau 2 ou sur la couche 2. Afin de ne pas faire de
mauvaises redites nous vous proposons quelques extraits du paragraphe 3.6.2 tirés
de l'ouvrage d'Andrew Tanenbaum "Réseaux" 3éme édition chez Dunod. " ....Que ce soit
pour les connexions sur liaison louée point à point ou pour les connexions
par réseau téléphonique, il est nécessaire de disposer d'un protocole de
liaison de données pour réaliser toutes les fonctions de délimitations de
trames, de contrôles d'erreurs et autres... On utilise à cet effet dans
Internet essentiellement deux protocoles: SLIP ( Serial Line IP) et
PPP..." "Slip est le plus
ancien de ces deux protocoles. Il a été conçu par Rick Adams en 1984 dans le
but de relier des stations Sun à Internet en utilisant un modem et le réseau
téléphonique. Ce protocole, décrit dans le RFC 1055, est très
simple..." " PPP (Point-to-Point Protocol) .......C'est ainsi qu'est
né PPP, défini dans le RFC 1661 et complété
ultérieurement ( RFC 1662
et 1663). PPP
gère la détection des erreurs, traite différents protocoles, permet la
négociation des adresses IP à la connexion ainsi que l'authentification et se
révèle ainsi bien supérieur à SLIP...." "PPP fournit trois
choses : 1. une méthode qui
délimite de façon non ambiguë la fin d'une trame et le début de la suivante.
Le format de la trame permet également la détection des erreurs; 2. un protocole de
contrôle de liaison qui active une ligne, la teste, négocie les options et la
désactive proprement lorsqu'on n'en a plus besoin. On l'appelle le protocole LCP
(Link Control Protocol) ; 3. une façon de négocier
les options de la couche réseau indépendamment du protocole de couche réseau
à utiliser. La méthode choisie consiste à avoir un NCP (Network
Control Protocol) différent pour chaque couche réseau supportée." L'authentification est
une des phases qui est intégrée dans le LCP. PPP étant positionné dans
la couche 2, il procède à l'encapsulation des datagrammes de la couche 3.
Voici donc la trame que véhicule PPP:
Pour conclure
sur PPP, voici ce qu'en dit en fin de résumé Andrew Tanenbaum: "... Nombreux sont
les réseaux qui utilisent au niveau de la couche liaison de données des
protocoles orientés bits suivants : SDLC, HDLC, ADCCP ou LAPB. Tous ces
protocoles font usages de fanions pour délimiter les trames et de bits de
transparence pour éviter l'apparition du fanion dans les données. Tous
également recourent au mécanisme de fenêtre pour le contrôle de flux. Dans
Internet, on utilise comme protocoles de liaison de données SLIP et PPP. Les
systèmes ATM ont, quant à eux, leur propre protocole, un protocole tout
simple qui ne fait qu'un minimum de contrôle d'erreur et pas du tout de
contrôle de flux."
3) LE MLPPP La RFC 1990 précise que
le but de l'opération du " Multilinkage " est la mise en oeuvre de
la coordination de plusieurs liens afin d'obtenir une bande passante qui est
la somme de celles des liens coordonnés pour le Multilink. Ceci se traduit par la
capacité de chaque machine communicant via le MLPPP à recevoir des paquets de
tailles importantes fragmentés durant leur passage dans les liens physiques
du lien virtuel. Par la suite nous
désignerons MP comme étant le Multilink Protocol La force du MP c'est
qu'il peut combiner des liens des technologies suivantes :
* Lignes téléphoniques
* RNIS
* X 25, circuits virtuels
* Frame Relay.... MP peut aussi associer
des liens de différents types ex: asynchrones et synchrones Voici les premiers
paragraphes du RFC 1990
qui donnent les motivations de la création du MP au sein de l'I.E.T.F
. " Ce document
propose une méthode pour diviser, recombiner et séquencer les datagrammes à travers
des liens logiques de données. Ce travail était originellement motiver par le
désire d'exploiter de multiples canaux porteurs dans le RNIS (Réseau
Numérique à Intégration de Services), mais est également aussi applicable à
toutes situations dans lesquelles les multiples liens PPP relient deux
systèmes, comprenant les liens asynchrones... Les vitesses de base et
primaire du RNIS offrent ensemble la possibilité d'ouvrir simultanément des
canaux entre systèmes, donnant aux utilisateurs une largeur de bande
additionnelle (pour un coût additionnel). Les propositions précédentes pour
la transmission des protocoles Internet sur le RNIS avaient fixé comme
objectif l'aptitude à faire utiliser cette capacité..." Le MP est donc un
protocole de demande de largeur de bande. Il permet d'augmenter la largeur de
bande entre deux systèmes qui communiquent. Il faut entendre ici une
augmentation du débit entre les deux machines communicantes. Un lien logique est
configuré par l'association de plusieurs liens physiques. La technique employée
s'appelle l'agrégation de lien ou le Bonding. Par exemple, il est
possible de combiner deux canaux RNIS à 64 kbits/s pour en faire un à 128
kbits/s. Les 2 canaux à 64 kbits/s donnent un
débit
Un des canal est libéré pour permettre un appel et à 128 kbits/s une fois liés en un lien
logique.
fait redescendre le débit à 64 kbits/s
Schéma d'explication du MLPPP tiré d'un
modem de chez 3Com 4) Les phases
du protocole du MP
4.1) La négociation Le MP est négocié durant
la négociation des options du LCP entre deux machines. Par la suite les
négociations LCP ne sont plus permises sur l'agrégat que forme les liens en
configuration Multilink. La négociation indique
trois choses: 1) Le système offrant l'option
est capable de combiner de multiples liens physiques en un lien logique. 2) Le système est capable de
recevoir les PDU fragmentées des couches hautes (TCP à Applications) utilisant
l'entête multilink et de ré assembler les fragments suivant le PDU original. 3) Le système est capable de
recevoir les PDU de taille de N octets ou N est spécifié comme une partie de
l'option même si N est plus grand que le maximum d'unités recevables
pour un lien physique seul. Ce qui veut dire de plus
que les phases d'authentification de type CHAP ( Challenge Handshake
Authentication Protocol, Protocole d’authentification par tests) et PAP ( Password
Authentication Protocol, Protocole d’authentification de mot de passe ) sont respectées et que les
négociations sur les liens procèdent du PPP. Une fois que le multilink
a été négocié avec succès, le système faisant l'envoi est libre d'envoyer les
PDU encapsulées et/ou fragmentées avec l'entête multilink.
4.2) Préparation des paquets
4.2.1) Configuration Les paquets transmis et
utilisant le MP sont encapsulés selon les règles du PPP ou les options
suivantes devront être manuellement configurées :
* Pas de schéma de contrôle de caractères asynchrones
* Pas de numéro magique
* Pas de contrôle de qualité de lien
* Adresse et compression de champs de contrôle
* Protocole de compression des champs
* Pas de trames composées
* Pas de bourrage auto-décrit Une fois donc les
machines configurées, il est possible d'opter pour différentes stratégies de
transmissions des paquets. En effet, chaque lien va transporter des paquets
selon le MP pour optimiser le multiplexage qui va s'opérer. Hors, la
sérialisation sur chaque lien peut-être différente les uns des autres, les
paquets issu du MP n'ont pas forcément besoin d'être fragmentés s'ils sont
suffisamment petits etc... Deux stratégies peuvent
être envisagées et employées durant la transmission :
1_ S'il y a fragmentation on distribue les paquets proportionnellement à la
sérialisation de chaque
lien. Autrement dit, distribution des fragments du paquet en fonction du
débit de chaque lien.
2_ S'il n'y a pas fragmentation, les paquets sont distribués en fonction de
leur taille sur les liens,
en tenant compte là aussi de la vitesse des liens.
4.2.2) Schéma des fragments Comment concrètement va
se réaliser cette augmentation de débit ? Le système configuré pour
le MP connaît grâce à la phase d'initialisation du LCP, le nombre de liens,
leurs vitesses, leurs types etc... Il va donc procéder ,selon les stratégies
vu au-dessus, au multiplexage. Bien sûr cette transmission en parallèle va
nécessité de reconnaître chaque fragment MP car ceux-ci sont transporter via
le PPP. Donc nos fragments ou paquets auront simultanément un entête MP et un
entête PPP. Les paquets de protocole de
réseaux sont en premier encapsulés (mais pas encadrés) selon les procédures
normales PPP et les grands paquets sont divisés en de multiples segments
taillés de façon appropriée pour les multiples liens physiques. Les implémentations ne doivent
pas inclure les adresses et les champs de contrôle dans l'entité logique qui
sera fragmentée. Un nouvel entête PPP consistant à un identifiant de
protocoles Multilink, et l'entête Multilink sont insérés avant chaque
section. Ainsi le premier fragment de paquet multilink dans PPP aura deux
entêtes, une pour le fragment, suivie par l'entête pour le paquet lui-même. Il est distingué deux
types de format des fragments ou paquets selon que l'on ait un séquencement
court ou long :
Fragment PPP multilink
à numéro de séquence long
Fragment PPP multilink à numéro de
séquence court E :bit de fin de fragment se met
à 1 pour le
dernier fragment Sequence number : N° de Séquence 12 ou 24 bits, par défaut 24 bits O :Champs réservés
4.3) Les échanges entre les machines Les fragments peuvent
donc circuler sur l'ensemble des liens et être réassemblés à chaque extrémité
ou interface du lien logique formé par les différents liens physiques.
4.4) Autres points du MP La RFC 1990 aborde de nombreux points dont :
4.4.1)Le Bourrage
Les systèmes qui supportent le MP devraient implémenter le Self-Describing-Padding. Un système qui implémente le Self-Describing-Padding par définition sera dans les deux cas suivant : Inclure l'option de bourrage dans ses demandes de configuration LCP ou Pour éviter le retard du rejet de configuration, Inclure l'option de bourrage après réception d'un Non Acquittement contenant l'option. Le choix du bourrage dépendra du choix des longueurs des fragments qui est attendu. Par contre un système ne doit pas ajouter du bourrage à chaque paquet qui ne peut pas être reconnu comme "bourré" par le système le réceptionnant. Si nécessaire, le système qui ajoute du bourrage doit utiliser la configuration NAK du LCP pour obtenir une requête de configuration pour le bourrage Self-Describing-Padding du vis à vis. Des demandes de configuration LCP peuvent être envoyées à tout moment sur tout lien.
4.4.2) Espace mémoire
négocié contrant la perte de fragments Dans une procédure MP un canal peut-être retardé sans altérés les autres canaux du lien virtuel. Ceci peut amener à une réception dans le désordre des fragments ce qui aura pour effet de rendre plus difficile la détection de perte de fragments. La tâche ici consiste à estimer la création du BUFFER sur le récepteur. Cette dernière deviendra plus complexe en cas de déséquencement.
4.4.3) La détection de fragments
perdus Sur chaque lien composant le lien virtuel, l'envoyeur doit transmettre des fragments avec exactement l'augmentation des numéros de séquences (modulo la taille de l'espace de séquence). Cette exigence permet au récepteur de détecter la perte de fragments. Ceci est basé sur la comparaison des nombres des séquences. Le nombre de séquence n'est pas remis à zéro sur chaque nouveau paquet PPP. Le récepteur garde trace des numéros de séquence entrant sur chaque lien et en maintient un minimum en cours récemment reçu sur tout les lien du lien virtuel. Le récepteur détecte la fin d'un paquet quand il reçoit le bit de fin porté par un fragment. Le réassemblement des paquets est complet si tous les numéros de séquence de tous les fragments ont été reçus. Tenant compte du déséquencement, un fragment est détecté comme perdu lorsque le dernier fragment avec le bit de fin arrive avant un fragment à numéro de séquence inférieure au sien. Si un fragment arrive avec un bit de début avant le fragment attendu ayant un bit de fin, les fragments de la séquence s-1 sont détruits. Les fragments peuvent être perdus en raison de l'altération des paquets ou d'une perte physique d'un lien. Cette version du MP n'oblige pas à l'application de procédures spécifiques pour la détection de liens en échec. Afin de maximiser la détection de fragments perdus les liens les moins actifs sont sollicités à tour de rôle. L'envoi de fragment null permet de drainer une entête MP de fin et de début ce qui a pour effet d'augmenter la probabilité de détection de perte. Il n’y a pas de quantité de "Bufferage" qui puisse garantir la détection de fragments perdus. Pour le cas habituel ou tous les canaux du lien virtuel sont en activité de transmission, il existe une quantité minimum au dessous de laquelle on ne peut pas détecter des paquets perdus. Des envois de paquets en echo reply et la détermination du temps d'aller retour entre machines sont des paramètres du protocole MP aidant à la détection d'erreur.
4.4.4) Extension du LCP sur PPP Si une opération de MP fiable est désirée, la transmission fiable PPP (essentiellement l'utilisation du LAPB ISO) doit être négociée avant l'utilisation du MP sur chaque lien physique. Que la distribution soit ou pas fiable, elle est employée sur les liens physiques, une implémentation doit présenter un signal au NCP courrant sur l'arrangement "Multilink" ou une perte s'est produit. La compression devrait être utilisée séparément sur
chaque lien, ou sur l'ensemble du lien virtuel. L'usage de compression
répartie sous le lien virtuel est indiqué par le fonctionnement du protocole
de contrôle de compression mais avec un protocole d'identification PPP alternatif. Le MP introduit l'usage d'options de configurations
LCP additionnelles : * Maximum d'unités reçues et reconstituées sur "Multilink" ou MRRU * Format d'entête du numéro de séquence court Multilink * Discriminateur de fin de point La MRRU a un champ de 2 octets et spécifie le nombre maximum d'octets dans les champs d'information des paquets réassemblés. Un système doit être capable de recevoir un champ d'information plein de 1500 octets. Le nombre de 1500 ici vient de la spécification pour l'option LCP MRU dans PPP. Un système doit inclure l'option MRRU du LCP dans chaque négociation voulue pour instantier ou joindre un agrégat de lien physique donnant le lien virtuel. L'option de format d'entête du numéro de séquence court recommande que la machine doit implémenter le souhait de recevoir des fragments court. 12 bits pour définir le Numéro de séquence. Une implémentation souhaitant transmettre des fragments multiliens avec des numéros de séquence court pourrait inclure ces dernier dans une configuration NAK pour demander que la machine distante réponde avec une demande à recevoir des numéros de séquence court. La machine distante n'est pas contrainte de répondre avec l'option. L'option de discriminateur de fin de point
représente l'identification du système transmettant le paquet. Quatre
scénarios sont possibles : * Pas d'authentification, pas de discriminateur * Pas d'authentification, discriminateur * Authentification, pas de discriminateur * Authentification, discriminateur Chaque fin de point pourrait choisir une classe d'identifiant sans restriction. Bien qu'aucune classe soit recommandée, les classes qui ont universellement des valeurs uniques sont préférées. Une implémentation devrait utiliser le discriminateur de fin de point pour localiser l'administration ou l'authentification dans la base de données locales. Le champ de classe est d'un octet et indique l'espace d'adresse de l'identifiant.
Les points les plus importants pour comprendre ce qu'est le MLPPP ont été abordés ci-dessus. La RFC 1990 aborde de façon plus concise et sous forme de généralités les points suivant que nous en détailleront pas :
* Fermeture des liens formant le multilink : Closing Member links * Interactions avec d'autres protocols : Interactions with Other Protocols * La sécurité : Security Considerations * Différence entre la RFC 1990 et la 1717 (obsolète) : Differences from RFC 1717
5) MLPPP dans l’avenir Dans les grandes évolutions avenir de l’Internet, il
y a bien sûr l’IPV6, et à ce titre comme tout protocole MLPPP va devoir être
adapté. En effet, il faudra tenir compte de la volonté des constructeurs qui
seront partie prenante de l’intégration d’IPV6. Au vu du succès du MLPPP
l’avis des constructeurs comme CISCO, LUCENT et autres sera une des
composantes de l’évolution du MLPPP. Dans ce cadre, il faudra être attentif à
la mise en œuvre des recommandations futures de l’IETF et des stratégies des
Géants des télécommunications. 6) Conclusion La page MLPPP en pratique présente des documents précis sur l'utilisation concrète du PPP en langue française et sur celles du MLPPP en langue anglaise des systèmes CISCO. Ce MP aurait pu s'appeler si l'on y prenait garde "Multiplexage Pour l'Internet". Or, il s'agit précisément d'améliorer son usage du point de vue de la bande passante. Ce qui va bien plus loin qu'un simple multiplexage car il faut tenir compte de l'hétérogénéité des systèmes qui composent le NET, des politiques de sécurités, de sa disponibilité, de sa complexité etc.... Le MLPPP est bien un service à part entière
qui vous pourrez le voir à bien des applications concrètes au quotidien. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
