Compare commits
2 commits
6b13b3cdb4
...
eda9fc8abd
Author | SHA1 | Date | |
---|---|---|---|
eda9fc8abd | |||
5c5aba4871 |
2 changed files with 418 additions and 19 deletions
|
@ -1,57 +1,241 @@
|
|||
---
|
||||
title: "PdP: Architecture loficielle"
|
||||
title: "PdP: Architecture logicielle"
|
||||
date: 2024-03-14
|
||||
tags: ["besoins", "UML", "developpement logiciel"]
|
||||
categories: ["Projet de programmation", "Cours"]
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
une architecture logicielle est une structure composite basée sur une
|
||||
décomposition de composants distincts et une ensemble de dépendance et/ou
|
||||
d'interaction entre ces composants.
|
||||
|
||||
La finalité est de répondre un ensemble de besoins logiciels et d'offrir un
|
||||
ensemble de services.
|
||||
|
||||
> Engineering is all about breaking down big problems into smaller ones
|
||||
> and putting the solutions for those problems back together
|
||||
|
||||
Boswell and Fouchet, 2011
|
||||
|
||||
Il est donc question ici de maitriser la taille et la complexité pour assurer le
|
||||
**passage à l'échelle** : décomposer pour maîtriser et faire évoluer. En effet
|
||||
les architectures logicielles doivent aussi être modifiables, extensible et
|
||||
évolutives. Les composants et leurs dépendances doivent **permetttre et
|
||||
faciliter le changement**.
|
||||
|
||||
## Dépendances et composants
|
||||
|
||||
Un composant, aussi appelé aussi *bloc de construction* est tout élément
|
||||
syntaxique qui participe à la structure de son architecture : les intructions,
|
||||
les expressions, fonctions, classes, modules, paquetages, etc.
|
||||
|
||||
Un composant \\(C_1\\) est dépendant de \\(C_2\\) si \\(C_1\\) utilise \\(C_2\\)
|
||||
dans sa définition ou implémentation.
|
||||
|
||||

|
||||
|
||||
Voici comment représenter les dépendances entre deux classes, notez le sens de
|
||||
la flèche, elle pointe vers \\(C_2\\) : *"dépends de".
|
||||
|
||||
Nous avons trois grande famille de dépendances:
|
||||
|
||||
* Les **utilisations simples** d'éléments de composants. Par exemple une
|
||||
fonction \\(f_1\\) appelle une autre fonction \\(f_2\\);
|
||||
* Les **associations** entre composants par imbrications. Par exemple une
|
||||
classe \\(C_1\\) inclut un attribut de la classe \\(C_2\\);
|
||||
* Les **inclusions** ou **héritages** entre composants par réutilisation. Par
|
||||
exemple un sources C \\(s_1\\) inclut via `#include` un autre fichier
|
||||
\\(s_2\\).
|
||||
|
||||
### Taille -- flux et débit -- des dépendances
|
||||
|
||||
Les dépendances d'une architecture doivent être utilisable, utilisées et utiles.
|
||||
Elles doivent transmettre que le stricte minimum d'informations et de qualité
|
||||
suffisante (contrôle et maîtrise).
|
||||
|
||||
La **taille** d'une dépendance entre \\(c_{1}\\) et \\(c_{2}\\) reflète la
|
||||
quantité d'information qu'elle peut faire transiter ce qui inclus:
|
||||
|
||||
* Le nombre d'éléments distincts transmis à \\(c_{1}\\) par \\(c_{2}\\);
|
||||
* Le volume des éléments distincts transmis à \\(c_{1}\\) par \\(c_{2}\\);
|
||||
* La complexité des éléments distincts transmis à \\(c_{1}\\) par \\(c_{2}\\).
|
||||
|
||||
Cette mesure n'as pas vocation être précise.
|
||||
|
||||
Dasn une architecture logicielle, il faut favoriser la définition d'une
|
||||
dependance **avec une taille minimale**
|
||||
|
||||
### Diffusion des changements
|
||||
|
||||
Une architecture où les changements dasn les composants sont diffusés aux
|
||||
autres composants n'est qu'une *architecture factice*.
|
||||
|
||||
Nous devons donc introduire la notion de **force d'une dépendance** entre deux
|
||||
composants \\(c_{1}\\) et \\(c_{2}\\):
|
||||
|
||||
* Elle est **forte** si une modification dans \\(c_{2}\\) entraine une
|
||||
modification dans \\(c_{1}\\).
|
||||
* Elle est faible dans le cas contraire.
|
||||
|
||||
La diffusion des changement va toujours dans le *sens inverse* des dépendances.
|
||||
|
||||
Dans une architecture logicielle, il faut limiter les dépendances forte pour les
|
||||
changements les plus probables dans cette architecture. On est obligé de se
|
||||
concentrer sur les changements les plus probables (on ne pourra considérer tous
|
||||
les changements). Il faut identifier ces changement possibles par le contexte,
|
||||
les besoins non fonctionnels, l'expérience, etc.
|
||||
|
||||
Plusieurs techniques d'implémentation sont disponible pour appliquer le principe
|
||||
de diffusion minimisée des changements comme:
|
||||
|
||||
* Les mécanismes de cloisonnement des langages (expression du privée / public);
|
||||
* En appliquant le principe de *taille minimisé*;
|
||||
* En utilisant les moyens d'expression d'abstration des langages comme *les
|
||||
interfaces*.
|
||||
|
||||
### Dépendances et utilisation des interfaces
|
||||
|
||||
spécification d'un composant -> description abstraite et rigoureuse de ses
|
||||
qualités, de sa manière de se comporter, des services qu'il est censé rendre.
|
||||
Un composant qui satisfait une spécification S est dit réaliser S
|
||||
La spécification d'un composant représente la description abstraite et rigoureuse de
|
||||
ses qualités, de sa manière de se comporter, des services qu'il est censé
|
||||
rendre. Un composant qui satisfait une spécification \\(S\\) est dit *réaliser*
|
||||
\\(S\\)
|
||||
|
||||
Utilisation de l'interface au lieu d'une classe
|
||||
|
||||
```c++
|
||||
class C2 {
|
||||
IC1 obj;
|
||||
// ...
|
||||
// This is a simple class
|
||||
}
|
||||
|
||||
interface IC1 {
|
||||
|
||||
// Interface - kind of specification
|
||||
}
|
||||
|
||||
class C1 implement IC1 {
|
||||
// ...
|
||||
// then iplementation.
|
||||
}
|
||||
```
|
||||
|
||||

|
||||
|
||||
Ainsi `C2` ne dépends pas de `C1` mais de l'interface `IC1`. En plus de décrire
|
||||
abstraitement les composants à implémenter, elles servent d'intermédiaire dans
|
||||
les dépendances.
|
||||
|
||||
Les interfaces contrôlent une part des dépendances fortes, on y spécifie les
|
||||
éléments les moins susceptibles de changer. Les interfaces ont deux rôles
|
||||
important dans une architecture logicielle:
|
||||
|
||||
* Décrire de manière abstraite les composants à implémenter;
|
||||
* Servir d'intermédiaire dans les dépendances et ainsi contrôler la force ou la
|
||||
faiblesse des dépendances.
|
||||
|
||||
#### Principe d'inversion des dépendances.
|
||||
|
||||
**Une dependance implicite** est une dépendance qui ne se voit pas directement
|
||||
dans le source d'un programme pas ses appels et ses annotations. Elle est
|
||||
toujours forte par rapport au changement qui la détermine.
|
||||
|
||||
> Dans une architecture logicielle, il est préférable de faire dépendre les
|
||||
> ocmposants d'interfaces et non les composants implémentés.
|
||||
> composants d'interfaces et non les composants implémentés.
|
||||
|
||||
Principe d'inversion des dépendances.
|
||||
si nous reprenons le schéma précédent, alors \\(IC_{1}\\) a été écrite par
|
||||
rapport à l'usage de \\(C_{2}\\) par \\(C_{1}\\), nous pouvons alors en déduire
|
||||
que \\(C_{2}\\) dépends de la paire \\((C_{1},IC_{1})\\). C'est notre
|
||||
**inversion de dépendance**
|
||||
|
||||
Une dependance implicite -> qui ne se voit pas directement dans le source d;un
|
||||
programme pas ses appels et ses annotations. Elle est toujours forte par rapport
|
||||
au chamgement qui la détermine.
|
||||
### Notion étendue des dépendances
|
||||
|
||||
Nous avons vu des *dépendances explicites* qui se matérialise par les appels de
|
||||
méthodes, les classes etc. Mais il existe aussi les **dépendances implicite**:
|
||||
c'est une dépendance qui ne se voit pas directement dans le code source.
|
||||
|
||||
Elles peuvent prendre des formes très différentes des dépendances explicite par
|
||||
|
||||
* la duplication de code
|
||||
* les similarité de services
|
||||
* <cf slide>
|
||||
* La duplication de code;
|
||||
* les similarité de services offerts par des composants distincts;
|
||||
* les similarité de structure entre composants distincts.
|
||||
|
||||
Les dépendances implicites sont toujours des dépendances fortes car se sont les
|
||||
changements qui les définissent. Il est donc préférable de minimiser leur
|
||||
apparition. (on minimise alors la duplication de code et les similarité par
|
||||
des techniques de factorisation de code)
|
||||
|
||||
LEs archilogicielles sont généralement des structures hiérarchisées.
|
||||
|
||||
## Granularité de structure, cohésion et couplage
|
||||
|
||||
niveau de granularité défini par
|
||||
Les architecture logicielles sont généralement des structures hiérarchisées de
|
||||
composants, c'est une conséquence naturelle du *décomposer pour maîtriser*.
|
||||
Cette hiérarchisation est généralement simplifiée car elle peut être constituée
|
||||
essentiellement de niveaux homogène de structure de composants.
|
||||
|
||||
Gq et G2 deux niveau de granilarité alirs couplage : ensemble des dépendances
|
||||
entre les composants de G2
|
||||
Son niveau de granularité est déterminé par des composants de même espèce
|
||||
capable d'inclure des composants du niveau inférieur (s'il y en a). Les niveaux
|
||||
habituels de granularité offerts par les langages de programmation sont:
|
||||
|
||||
* Les valeurs, données, instructions;
|
||||
* Les variables, attributs, fonctions (ou méthodes);
|
||||
* Les modules, classes, objets,
|
||||
* Les paquetages, clusters, namespace
|
||||
* Les super-paquetages;
|
||||
* Les couches.
|
||||
|
||||
Pour des raison de simplification et d'intelligibilité, les dépendances peuvent
|
||||
se restreindre à ne s'énoncer qu'au sein de chaque niveau de granularité : un
|
||||
composant \\(C1\\) est explicitement dépendant de \\(C2\\) si \\(C1\\) utilise
|
||||
\\(C2\\) dans sa définition ou son implémentation et si tous les deux sont au
|
||||
même niveau de granularité. Les dépendances sont donc à considérer entre
|
||||
fonctions, entre classes, entre paquetages, etc.
|
||||
|
||||
### Graphes de dépendances
|
||||
|
||||
Les dépendances dans une granularité fixée induisent des **graphes** dont les
|
||||
sommets sont d'une seule espèce de composants et les arcs des dépendances
|
||||
explicites.
|
||||
|
||||
Dans la mesure du possible, il faut favoriser la construction de niveau de
|
||||
granularité homogènes donnant lieu à des graphe de dépendances distincts. C'est
|
||||
un principe de simplification et d'intelligibilité des architectures logicielles
|
||||
mais qui n;est pas applicable tout le temps (et c'est parfois souhaitable). Les
|
||||
langages permettent souvent des moyens de déroger à ce principe (*nested
|
||||
classes* en Java, lambda expression ...).
|
||||
|
||||
### Suites de granularités, consécutivité
|
||||
|
||||
Les granularités peuvent donc former des suites constitués des éléments que nous
|
||||
avons évoqué plus haut (données, variables, fonctions etc.). Deux **granularité
|
||||
consécutives** sont deux granularité qui se suivent dans cette liste, elles
|
||||
engendre des **graphes consécutifs de dépendances**.
|
||||
|
||||
Il faut veiller à ce que chaque graphes de consécutivité soit plus simple que le
|
||||
précédent, ils dessinent alors **une pyramide**. Chaque niveaux est une
|
||||
opportunité de simplifier, synthétiser la description d'une architecture. Bien
|
||||
entendu il existe des contre-exemples, comme **les classes qui ne contiennent
|
||||
qu'une seule méthode**.
|
||||
|
||||
Il serait naturel de regrouper un ensemble de méthodes très dépendantes en elles
|
||||
dans une seule classe, ou encore des classes très dépendances dans un
|
||||
paquetage. C'est le principe **de simplification min-max**: il faut en sorte
|
||||
que les composants du niveau de granularité \\(G2\\) englobent le **maximum** de
|
||||
dépendances de \\(G1\\) tel qu'il reste un **minimum** de dépendances en
|
||||
composants de \\(G2\\).
|
||||
|
||||
### Couplage et cohésion
|
||||
|
||||
Le couplage représente l'ensemble des dépendances entre composants de \\(G2\\),
|
||||
la cohésion celles au sein de chacun des composants de \\(G2\\) entre les
|
||||
éléments de \\(G1\\).
|
||||
|
||||
Si \\(G2\\) est un ensemble de classes et \\(G1\\) un ensemble d'attributs et de
|
||||
méthodes de ces classes alors:
|
||||
|
||||
* le couplage correspond à l'ensemble des dépendances entre classe de \\(G2\\);
|
||||
* la cohésion définie pour chaque classe de \\(G2\\) correspond à l'ensemble
|
||||
des dépendances entre ses attributs et méthodes.
|
||||
|
||||
Pour reprendre notre **principe min-max**: dans une architecture logicielle, pour
|
||||
toute paire de niveau de granularité, il faut privilégier à la fois **la
|
||||
cohésion la plus forte** et **le couplage le plus faible**
|
||||
|
|
215
content/reseaux_protocoles/5_couche_liaison/index.md
Normal file
215
content/reseaux_protocoles/5_couche_liaison/index.md
Normal file
|
@ -0,0 +1,215 @@
|
|||
---
|
||||
title: "Réseaux et Protocole: couche liaison"
|
||||
date: 2024-03-29
|
||||
tags: ["OSI", "ethernet"]
|
||||
categories: ["Réseaux et protocoles", "Cours"]
|
||||
mathjax: true
|
||||
---
|
||||
|
||||
Commençons déjà par la terminologie:
|
||||
|
||||
* *nœuds* : équipement (routeur, host)
|
||||
* *canal de communication* : lien adjacent entre nœuds;
|
||||
* *frame* : paquet de la couche liaison (niveau 2)
|
||||
|
||||
La couche 2 transmet une frame entre deux **nœuds ajacents**. Il existe les
|
||||
liaisons **filaires** (ethernet) et **sans-fils** (wifi, LTE). Chaque protocole
|
||||
propose des caratéristiques différentes (fiabilité, rapidité etc.)
|
||||
|
||||
Comme pour les autres couches étudiée jusqu'à maintenant, celle-ci encapsule les
|
||||
éléments de celle au dessus en y ajoute son entête. La couche liason ajoute
|
||||
ainsi les propres mécanismes de contrôles de flux entre les nœuds adjacent ou
|
||||
encore la détection voire la correction d'erreur. Le mode de communication peut
|
||||
être *half-duplex* ou *full-duplex*
|
||||
|
||||
La couche liason est implémentée sur chacun des nœuds, elle peut l'être
|
||||
directement sur le contrôleur réseau de façon matérielle mais aussi logicielle.
|
||||
|
||||
## Détection d'erreur
|
||||
|
||||
Elle se fait par l'ajout d'un champs *EDC* pour *Error Detection Code* dans la
|
||||
frame. C'est un simple ajout de bits de parité. Cependant ajouter un seul bit de
|
||||
parité **n'est pas assez fiable**. Il est alors préférable d'utiliser le *two
|
||||
dimentionnal parity*, un tableau à deux dimensions pour faire du *calcul de
|
||||
parité* permettant non seulement **la correction** mais aussi la **correction**.
|
||||
|
||||
## Multiple access link
|
||||
|
||||
Nous avons d'abors des protocole utilisé pour la communication entre deux nœuds :
|
||||
*PPP* pour *Point to Point Protocol* ou encore *ethernet*. Mais d'autres sont
|
||||
fait poue la diffusion (*broadcast*), la communication entre plusieurs nœuds
|
||||
comme le *Wifi* ou les communications par *Satellite*
|
||||
|
||||
Dans le second cas, il nous faut un algorithme pour déterminer **l'ordre de
|
||||
transmisson** : à quel moment un équipement peut envoyer des données sur le
|
||||
canal partagé entre tous. Il n'y a pas de canal auxiliaire ( *out of band* )
|
||||
pour organiser le partage de la ressource, il faut alors organiser le
|
||||
partitionnement
|
||||
|
||||
### MAC Protocol
|
||||
|
||||
Le canal est divisé en plus petites pièces à l'exclusivité de nœuds. Les accès
|
||||
sont aléatoires et au tour par tour.
|
||||
|
||||
#### partitionnement en fonction du temps
|
||||
|
||||
Chaque station a un slot de temps fixe permettant la transmission, si la station
|
||||
n'a pas de donnée à transmettre, alors le slot passe en IDLE.
|
||||
|
||||
#### Frequencie division multiple access *FDMA*
|
||||
|
||||
Le canal est divisé sur plusieurs fréquences, chaque nœud se voit attribuer une
|
||||
fréquence et peut transmettre sur celle-ci en continue.
|
||||
|
||||
#### accès aléatoire
|
||||
|
||||
Lorqu'un nœud veut émettre, il prend la communication sur l'ensemble du canal,
|
||||
il n'y a pas de gestion de la coordination. Donc si deux nœuds ou plus émettent
|
||||
en même temps alors il y a **collision**.
|
||||
|
||||
Ces types de protocoles définissent alors comment détecter les collisions et ce
|
||||
qu'il faut faire dans ce cas.
|
||||
|
||||
Vopici des exemples de protocoles de type accès aléatoires: ALOHA, Slotter
|
||||
ALOHA, CSMA, CSMA/CD, CSMA/CA
|
||||
|
||||
##### Slotted ALOHA
|
||||
|
||||
Le temps est divisé en intervalle régulier (intervalle de temps) correspondant au
|
||||
temps nécessaire pour la transmission d'une trame. L'émetteur attend donc le
|
||||
début d'une intervalle de temps pour transmettre sa trame.
|
||||
|
||||
En cas de collision, le nœud retransmet son paquet après avoir attendu un temps
|
||||
aléatoire. Au mieux, 37% d'efficacité.
|
||||
|
||||
##### Carrier Sense Multiple Access
|
||||
|
||||
C'est un protocole simple : écouter avant de transmettre :
|
||||
|
||||
* Si le canal est libre alors on transmet **la trame entière**;
|
||||
* sinon on repousse la transmission
|
||||
|
||||
##### Carrier Sense Multiple Access with Collision Detection (CSMA/CD)
|
||||
|
||||
Les collision sont possible avec CSMA, à cause du délais de propagation de la
|
||||
trame. La probabilité d'une collision est déterminée par la distance et le
|
||||
délais de propagation.
|
||||
|
||||
Avec CSMA/CD, un hôte annule la transmission d'une trame à l'instant de la
|
||||
détection d'une collision. Dans le cadre d'Ethernet par exemple:
|
||||
|
||||
* Vérification du canal;
|
||||
* Envoi d'une trame entière si le canal est libre;
|
||||
* Si aucune collision détectée : fin!
|
||||
* Sinon annule la transmission et envoie le *signal jam*;
|
||||
* Entre dans le *binary exponential backoff* : choisi un nombre \\(K\\) entre
|
||||
\\([1..2^{m-1}]\\) et attend \\(K x 512 \\)temps / bit et relance les étapes
|
||||
à partir de la vérification du canal.
|
||||
|
||||
#### à tour de rôle
|
||||
|
||||
C'est un protocole reprenant le meilleur de l'accès aléatoire et du partage de
|
||||
canal
|
||||
|
||||
Deux façons de faire :
|
||||
|
||||
* Un contrôleur décide du partage de la ressource et invite les équipement.
|
||||
C'est le fonctionnent du **Bluetooth** par exemple.
|
||||
* Un jeton donne le droit à transmission et passe d'hôte en hôte. Cette façon
|
||||
de procéder donne lieu à un peu *d'overhead*, de plus que faire si le jeton
|
||||
se perd?
|
||||
|
||||
## LAN
|
||||
|
||||
### Adressage
|
||||
|
||||
La base de cette des LAN est l'adresse MAC inscrite en dur dans le matériel --
|
||||
mais parfois dans le logiciel, pensez aux machines virtuelles par exemple -- sur
|
||||
48 bits. Les 3 premiers octets de cette adresse sont alloués par l'IEE en
|
||||
fonction du fabricat du périphérique.
|
||||
|
||||
### Le protocole ARP
|
||||
|
||||
Il fait le lien entre l'adresse Ethernet (couche liaison) et l'adresse IP
|
||||
(couche réseau). La **table ARP** présent sur tous les hôtes connecte au reseau
|
||||
permet de faire le lien entre les adresses MAC et IP en y associant aussi une
|
||||
durée de vie , le `TTL`.
|
||||
|
||||
Des message de broadcast sont envoyés par les hôtes afin de connaitre l'adresse
|
||||
MAC des autres si l'entrée n'est pas disponible dans la table (encapsulé dans
|
||||
une trame Ethernet).
|
||||
|
||||
### Ethernet
|
||||
|
||||
C'est la technologie dominante sur les réseaux locaux depuis les années 90.
|
||||
Plusieurs implémentation sont disponibles :
|
||||
|
||||
* **bus** pour les réseaux coaxiaux avec un seul domaine de collision;
|
||||
* **switch** pour les réseaux avec connecteur RJ45, ici un domaine de collision
|
||||
par machine.
|
||||
|
||||
D;abors il y a le préambules : une série de 8 octets dont les 7 presiers sont
|
||||
`1010101010` puis le dernier à `1010101011`. Son rôle est de synchroniser les
|
||||
hôtes et de délimiter le début de la transmission.
|
||||
|
||||
Viens ensuite la *trame* composées de :
|
||||
|
||||
* l'adresse *MAC* de destination;
|
||||
* l'adresse *MAC* source;
|
||||
* le *type* indiquant le protocole de la couche supérieure;
|
||||
* la *charge utile*
|
||||
* le contrôle d'intégrité (*CRC* pour **Cyclic Redundancy Check*).
|
||||
|
||||
Ethernet est un protocole sans connexion : il n'y a pas de *handshake*, pas de
|
||||
mécanisme d'*ACK*, pas de retransmission. On laisse ça **à la couche supérieure.
|
||||
|
||||
Il existe aussi plusieurs standards Ethernet en fonction du type de liaison.
|
||||
|
||||
### Les switches
|
||||
|
||||
C'est un équipement de la **couche liaison** qui stocket te retransmet les
|
||||
trames Ethernet. Il examine les adresse MAC dans les entêtes et envoie les
|
||||
trames vers les hôtes concernés. Il est transparent et ne nécessite pas de
|
||||
configuration pour un *switching* basique.
|
||||
|
||||
Les switches possèdent une **table de transfert** qui contient les tuples
|
||||
`MAC:Port:TTL` mis a jour en fonction des trames qu'il voit passer. Le switch
|
||||
modifie dynamiquement cette table en fonction des trames qu'il voit passer sur
|
||||
ses différents ports. Lorqu'il doit envoyer des trames vers une adresse qu'il ne
|
||||
connait pas, alors il va emmetre une demande ARP sur **l'ensemble de ses
|
||||
ports**. Cette auto-apprentissage peur fonctionner même un fois les *switches*
|
||||
brachés les un aux autres.
|
||||
|
||||
Il est capable de communiquer sur plusieurs canaux simultaniement sans
|
||||
collisions par exemple, communication A <---> B et C <---> D ( mais A <---> B et
|
||||
A <--> C ne peut se faire en simultané )
|
||||
|
||||
### VLAN
|
||||
|
||||
Ils permettent de reduire le domaine de broadcast (ARP, DHCP) pour plusieurs
|
||||
éventuels objectifs:
|
||||
|
||||
* attacher logiquement des utilisateurs à leur machines / réseau;
|
||||
* faciliter la gestion du réseau
|
||||
* séparer les utilisateurs (sécurité, vie privée)
|
||||
|
||||
Mais pour celà il faut des équipement compatibles et de la **configuration**.
|
||||
Par exemple avec les *ports based VLAN* il est possible d'affecter
|
||||
dynamiquement les ports à des VLAN.
|
||||
|
||||
L'échange de messages entre les VLANs doivent se faire via un **routeur** ou un
|
||||
**switch de niveau 3**. Les connexions entre les différents switches doivent se
|
||||
faire va un **lien trunk** permettant de transmettre les informations relatives
|
||||
aux VLAN.
|
||||
|
||||
Ces information son positionnées dans l'entête Ethernet au format *802,1q*. elle
|
||||
se comporte du *tag protocol* et du *vlan id*.
|
||||
|
||||
### MPLS
|
||||
|
||||
Ce protocole permet d'assurer un routage et un forwarding plus rapide des
|
||||
paquets. Il s'intercale entre les couches 2 et 3 et se base sut l'ajout de
|
||||
labels de taille fixe entre l'entête Ethernet et la charge utile.
|
||||
|
||||
Le routeur MPSL regarde donc le label pour décider quoi faire avec le paquet: le
|
||||
routage est plus rapide (pas de décapsulation) et plus flexible.
|
Loading…
Add table
Add a link
Reference in a new issue