Couches OSI et protocoles

Pierre LALET <lalet@enseirb.fr> writes:

OSI dont tu parles est mort ! (si j'ai bien compris, il y a eu un
moment ou on a du choisir entre OSI et TCP/IP pour les communications,
et OSI coutait trop cher [désolé si je dis une connerie])

Euh ouais, c'est pas vraiment ca.
La pile IP a ete faite.
Puis des gens on modelise la notion de reseau sous la forme du modele
OSI. Mais IP s'est rependu assez vite et tout le monde s'est mis a
utiliser ca.
Donc OSI est plus beau comme modele, mais il n'a pas ete mis en
pratique a l'echelle mondiale, car il a ete supplante par IP qui avait
deja pris de l'importance.
OSI est mort-né, donc. Mais il me semble qu'il existe des protocoles
developpes entierement sur OSI. Faudra que je fasse des recherches.

Tout ce qu'il en reste, c'est un modèle conceptuel, et c'est tout. Et
ce modèle, il me va *très* bien pour décrire les encapsulations. Je ne
lui demande *rien* de plus.

Mais dans ce cas je te signale que tu as le modele IP (4 couches),
donc pourquoi ne pas l'utiliser a la place ? :-)
En plus il est fait pour.

C'est pour cela que ca me choque un peu le fait de ramner du ssh a du
niveau 3 alors qu'il est deja transporte par TCP/IP.

Mais je ne ramène rien du tout !

Transposition du modele IP vers modele OSI, oui.
Alors que tu parles essentiellement des composantes IP.
Bon il y a encore ce probleme de tranpsport de couches inferieures,
mais deja si on utilise le modele IP pour decrire... IP, c'est plus
logique.

Mais alors comparer au modele OSI n'est plus possible.
Ou alors on cree un modele completement different avec un nombre de
macro-couches infinies, chaques couches etant divisees en 7 couches
assimilees aux couches du modeles OSI. Où changer de "point de vue"
revient à changer de macro-couche.

Si tu veux, mais cela complique le modèle sans rendre plus facile la
compréhension, donc c'est pour le moins inutile, à mon sens.

Ca ne complique pas, ca le generalise.

Mais je suis quand même obligé de mettre un "X-Troll: no" pour que les
gens comprennent que ce n'est *pas* un troll ;-)

Je sais pas troller :-p

"Annie D." <annie.demur@free.fr> writes:

Si je comprends bien votre terminologie,
"point de vue réseau" = vu de la couche de dessous (qui transporte)
"point de vue applicatif" = vu de la couche de dessus (transportée) ?

Oui. Terminologie personnelle, hein, formellement parlant je ne sais
pas si des termes existes pour.

Ah non, stop ! PPPoE et PPP sont transportés physiquement par les mêmes
fils (sur un bout de chemin), mais sans suivre le même protocole, et ils
ne s'empiètent pas l'un sur l'autre. Ils sont *à côté*.

Donc PPPoE niveau 2, avec comme niveau 1 Ethernet, puis le réseau
téléphonique (mais avec des fraquences distinctes de celles utilisées
par le premier PPP). Tiens, au passage, ce PPPoE circule pendant un
moment au dessus d'ethernet, lui même de niveau 2.

Au-delà de la modulation électrique, l'ADSL, à la base, c'est de l'ATM
(couche ?), avec au-dessus AAL5 (ATM Adaptation Layer 5, donc couche 5
déjà), qui permet d'encapsuler tout un tas de protocoles. Si on utilise
PPPoE, le protocole encapsulé sur AAL5 est ethernet. Ensuite, PPPoE est
transporté sur cet ethernet, mais le modem, lui, n'est pas concerné par
PPPoE : il transforme de l'ethernet "physique" en ethernet encapsulé sur
AAL5 et vice versa. On pourrait aussi bien transporter directement de
l'IP au lieu de PPPoE, ou tout autre protocole passant sur ethernet.
Mais il se trouve qu'à l'autre bout, l'équipement ne comprend que PPPoE.

Donc, accès internet en ADSL, c'est :

IP sur PPPoE sur ethernet sur AAL5 sur ATM sur ADSL. Ouf !

Et notez bien que l'existence des trames ethernet, sous forme physique
ou encapsulée, perdure tout le long du lien ADSL, et même au-delà :
jusqu'à l'AC (Access Concentrator), c'est-à-dire le BAS chez FT.

PPP -> PPPoE

Non, ils sont *à côté* l'un de l'autre. La preuve, si tu en coupes un,
tu n'affectes pas l'autre.

Ça dépend si on parle du PPP passant par le modem RTC ou du PPP
transporté par PPPoE. PPPoE est une version modifiée de PPP pour lui
permettre de passer par une liaison ethernet. Sous Linux, pppd se sert
de rp-pppoe pour gérer cette particularité, mais c'est toujours pppd qui
gère la partie PPP classique (LCP, NCP...)

3) Il se trouve que j'ai mis en place sur mon serveur linux un service
PPTP. PPTP = VPN Windows 2000.

Pas uniquement Windows 2000, mais passons.

Ici c'est le démon PPTP qui va lancer PPP (cette fois ci en tant que
"serveur" je suppose)...

J'ai donc :
PPTP -> PPP -> PPPoE ???

non. Au sens strict, tu as PPTP (niveau 2) au dessus de TCP (il me
semble -- niveau 4,

La connexion TCP mise en place dans le protocole PPTP ne sert que pour
le contrôle, pas pour le transport. Le transport est assuré par un
tunnel GRE (protocole IP 47).

mais vu comme une simple liaison série, niveau 1,
par le PPP de PPTP). TCP est lui même au dessus d'IP (niveau 3), lui
même au dessus du PPP (ou PPPoE, ça dépend si tu utilises ton lien RTC
ou ADSL pour cette connexion -- niveau 2).

PS: je poste cet article à travers une connexion NNTP sur TCP relayée
par SSH passant par un accès ADSL avec PPPoE ;o)

Pierre LALET <lalet@enseirb.fr> writes:

Non, ce n'est pas ce que tu dis, c'est le contraire

Grmmmbl, exact.
Encore une fois, tout depend si on se place du point de vue reseau,
ou applicatif.

Ouf, j'ai failli réagir.

Si je comprends bien votre terminologie,
"point de vue réseau" = vu de la couche de dessous (qui transporte)
"point de vue applicatif" = vu de la couche de dessus (transportée) ?

"Annie D." <annie.demur@free.fr> writes:

Au-delà de la modulation électrique, l'ADSL, à la base, c'est de l'ATM
(couche ?), avec au-dessus AAL5 (ATM Adaptation Layer 5, donc couche 5
déjà), qui permet d'encapsuler tout un tas de protocoles.

Non non non.
AAL5 != couche 5
Alors deja on est dans le modele ATM, couche 3 ATM pour AAL.

On peut utiliser *a la place* de AAL5 du AAL1, AAL2, 3 ou 4.
On reparti les protocoles suivant certains criteres, et on utilise un
type de couche ou un autre en fonction de ca, mais on a pas du AAL5
sur du AAL4, ca n'a rien a voir.

AAL5 signifie qu'on transporte des donnes en mode connecte a debit
variable (en gros).
AAL2 sert pour des flux videos (donc debit variables, pas besoin de
mode connecte).
AAL est une couche d'ATM.

ATM correspond en gros a des couches 1-2-3 du modele OSI.
Mais les couches internes de ATM sont plus complexes que celle de OSI
est encore plus difficilement, a mon sens, transposable.

PS: je poste cet article à travers une connexion NNTP sur TCP relayée
par SSH passant par un accès ADSL avec PPPoE ;o)

Rah. J'ai que des trames tcp encapsulees dans le protole socks
transporte par du tcp/ip sur de l'ethernet. Je me sens tout petit.

Dans sa prose, Vincent Hiribarren nous ecrivait :

Comme ssh qui est en fait transporte par du TCP et donc ssh ne remplace
pas la couche 4, point.
Une fois desemcapsule on retombe sur le modele classique : j'enleve
l'enveloppe de l'autre enveloppe, et elle devient une enveloppe timbree a
part entiere, meme si elle a ete transportee bizzarrement jusque la.
Le modele OSI n'est qu'un *modele*, et pas la Verite. On pourrait creer
des modeles speciaux pour ces cas particuliers.

Elle m'a bien fait sourire votre discussion.
En fait, dès que tu encapsules une service, tu peux te recréer un
morceaux que pile OSI à côté et recommencer.

7 SSH

6 SSL -------------------- --
|
5 -- | --
|
4 TCP | TCP
|
3 IP | IP
|
2 Ethernet (MAC) `-> PPP
1 Ethernet (phys)


Je continue ?

Et tout de suite, comme ça, je trouve que ça devient plus clair. La
couche OSI définit des _services_, pas un modèle d'encapsulation à
suivre.

--
in fr.bio.canauxioniques:
LC> y a quelqu'un ?
LC> encore un site voué a la destruction!
-+- in : GNU - Le silence des espaces infinis m'effraie -+-

Zouplaz <pouet@pouet.com> writes:

Je pense que je vais suivre ton conseil (si je l'ai bien compris) : avoir
une vision claire du modèle OSI (ça ça va à peu près) et en apprendre assez
sur les différents protocoles, surtout les "bas niveau" (PPPx, GRE et cie)
car ce sont ceux là que je connais le plus mal (s'en servir est une chose
savoir en parler en est une autre)...

Tout depend de ce qu'on te demande d'apprendre.
Mais en gros voila.

Apres si tu n'arrives pas a caser un protocole dans une des cases du
modele OSI, c'est normal. A toi de dire pourquoi c'est a cheval entre
deux couches.

OSI est un beau modele. Mais dans la realité, personne ne le
respecte. IP en premier, puisqu'il a ete cree avant OSI.
Donc il est interessant de voir comment on peut rapprocher les
differents procotoles vers le modele OSI, mais il est normal que les
points de vues divergent concernant divers point.

Pierre LALET wrote:

Euh, pierre, je te signale que l'implication "protocole de niveau 4,
donc ne transporte que du 5" est de toi...

oui, précédé d'un "si on suit ton raisonnement", je disais ça pour
essayer de te montrer que tu avais tort, pas parce que je le pensais,
puisque c'est le contraire que je dis.

Je n'ai jamais dit ca,
juste que ssh etait transporte par IP donc il ne pouvait pas etre de
niveau 3. Le raisonnement que tu en tirais etait le mien, pas le tien.

"ssh est transporté par IP, donc ne peut pas être de niveau 3". C'est
bien ce que tu dis ?

Eh bien, c'est le contraire de ce que dit Annie : "tous les PPP sur
quelque chose (oE, oA, PPTP, tunnel L2TP...) sont de couche 2, même
s'ils sont encapsulés dans un protocole de couche 2, 3 ou plus",
puisqu'elle dit qu'un PPP, même encapsulé dans IP (lui même
éventuellement encapsulé dans un autre PPP), est de niveau 2.

Bonjour a tous,

Belle empoignade !! oui tous les protocoles "point a point" sont de niveau 2
pour ce qui concerne l'encapsulation de links ppp sous tcp, ca devient alors
des "datas" encapsules sous tcp (tcp = couche 4) , la desencapsulation
rendant la fonctionalite ppp a l'autre bout (couche 2) ..
POur ma part ssh c'est de l'aplicatif tout comme telnet et donc couche 7
OSI ou mieux couche 5 tcpip ..
Faut rappeler que le modele OSI est ne apres la creation des suites de
protocoles tcp/ip d'ou certaines zones d'ombre et recouvrement entre tcp/ip
et le modele OSI ..

Amicalement

Tu as sans doute raison. Donc on peut dire alors que ssh fait le
travail d'une partie de TCP sur un bout du chemin (et ce même s'il
fonctionne lui même au dessus de TCP).

Pas du tout !
Ssh repose sur du TCP et c'est TCP qui fait ce travail sur un bout du
chemin. Les mecanismes qui permettent de s'assurer que le paquet est
arrivé à bon port, c'est toujours TCP, et pas SSH.

Et alors ? Est-ce là tout le travail de la couche 4 ? UDP n'est donc pas
de niveau 4. Ce n'est pas parce que TCP fait une partie du travail de la
couche 4, que ssh ne peut pas faire le reste.

Tu regardes trop haut et tu oublies que SSH est lui-meme transporte
par du TCP/IP. Il faut se placer du point de vue reseau et pas du
point de vue paquet, le modele OSI est un modele reseau.

Mais je m'en fous, de savoir par quoi est transporté ssh. Tiens,
d'ailleurs, si dans ssh je remplace le socket TCP par une liaison série
comprenant un mécanisme d'aquitement, ssh n'est *plus* au dessus de TCP,
et pourtant ça ne change *rien*.

Ce paquet SSH, quelle est sa raison d'etre ? Etre envoye a un client
ou un serveur SSH. Par une connexion TCP/IP.
Ce paquet arrive au client ou au serveur SSH. Il est arrivé a sa
destination finale puisque c'etait un paquet ssh devant arriver a un
terminal SSH. Il est trituré pour en sortir un autre paquet qui n'a
plus rien a voir avec l'ancien et que l'on peut a nouveau inscrire
dans le modele OSI. En oubliant l'ancien paquet.

Bein je ne vois pas pourquoi. Quand tu crées un tunnel ppp au dessus de
n'importe quoi, tu crées aussi une interface. Ce n'est pas parce qu'elle
n'est pas physque qu'elle n'existe pas.

Je modifie donc mon assertion en : "ssh fait le travail d'une partie
de TCP sur un bout du chemin et fournit donc des services de niveau
4". Exactement comme SSL, qui bien qu'encapsulé dans du TCP, fournit
des services de niveau 4.

SSL n'assure pas du tout des services de niveau 4, il me semble.
Le cryptage de donnees, c'est pas du niveau 4.

http://javarome.free.fr/net/Protocole.html par exemple. Toutes les docs
que j'ai trouvé disent que SSL est un protocole de niveau 4.

Le niveau 4 s'occupe surtout du bon acheminement des donnees (les ACK
et autres dans le cas de TCP/IP, la notion de ports...).

Et UDP : il ne s'occupe pas du bon acheminement des données. Est-il de
niveau 4 ?

Si on le place au niveau 4 c'est par abus, car il transporte des
données de niveau 5.
Pour moi SSL offre un service de Session, donc niveau 5.

Mais non. Au dessus de SSL, on a *exactement* la même chose qu'au dessus
de TCP. En dessous, ça se passe différemment, mais on s'en fout.

Mais n'oublions pas que Internet a son propre modele DoD a 4 couches !
C'est pas pour rien qu'il est difficile d'avoir un calque parfait sur
le modele OSI, et que donc on bricole des couches intermediaires.

Pareil pour SSH : SSH ne propose pas des fonctionnalites de couche 4.
Ce n'est pas lui qui s'assure du bon acheminement du paquet, mais la
couche TCP en dessous. C'est cette couche qui decidera de la viabilite
du paquet, pas SSH.

"S'assure du bon acheminement du paquet" n'est pas le seul rôle de la
couche 4, sinon quid de UDP ?

pierre

--
Patrick
Dept 91

Pierre LALET wrote:

Desole j'ai foire le post precedent !!

Pareil pour SSH : SSH ne propose pas des fonctionnalites de couche 4.
Ce n'est pas lui qui s'assure du bon acheminement du paquet, mais la
couche TCP en dessous. C'est cette couche qui decidera de la viabilite
du paquet, pas SSH.

Absolument l'application (ssh et ses datas) sont transportes par tcp couche
4 .

"S'assure du bon acheminement du paquet" n'est pas le seul rôle de la
couche 4, sinon quid de UDP ?

UDP c'est couche 4 aussi mais sans securite d'acheminement, il faut que
l'application previenne les aleas possibles en prevoyant un mecanisme de
retransmission.

Amicalement

pierre

--
Patrick
Dept 91

On part des basses couches pour aller vers les plus hautes.
On s'interesse aux couches qui transportent, et non pas à ce qui est
transporté.

Moi je m'intéresse aux deux.

On monte dans les couches. On ne stagne pas.

Parfois on monte, et parfois, au détour d'une encapsulation ou d'un
tunnel, on redescend. C'est la vie d'un paquet balloté sur le réseau.

Je vois Ethernet.
Je vois IP.
Je vois TCP.
Je vois SSH.

Alors c'est que vous êtes un câble RJ45, ou une carte ethernet ;o)
Et si vous étiez le gestionnaire de la couche IP, vous ne verriez pas
ethernet. Et si vous étiez l'application SSH, vous ne verriez rien
d'autre que les octets que vous émettez ou recevez, sans savoir sur quoi
ils sont passés. De même que si cet ethernet était encapsulé (dans de
l'AAL5/ATM/ADSL par exemple), vous ne le verriez pas. Mais qu'est-ce que
ça change ? Rien. Question de point de vue.

SSH est la destination, le paquet est traité par le serveur ou le
client car c'est la destination finale du paquet sur un poste
informatique apres passage par le reseau. SSH elabore un nouveau
paquet a renvoyer sur le reseau, un nouveau cycle recommence.

Non, SSH, comme toute application basée sur TCP ne traite pas de paquets
mais un flux d'octets. C'est la couche TCP qui découpe ce flux en
paquets.

Je vois PPP.
Je vois IP.
Je vois TCP.
Je vois SSH.

Bien, alors cette fois vous êtes le câble téléphonique ou le modem. A
moins que vous soyez la couche AAL5 d'un lien ADSL, ou le tunnel GRE
d'une connexion PPTP, ou encore un tunnel L2TP en UDP. Ou pourquoi pas
un SSH ? Sans importance encore, puisque tous, bien que basés sur des
couches inférieures de niveaux différentes, fournissent ici le même
service : transporter le même PPP.

Voyez, par exemple, le cheminement de mes paquets IP entre mon FAI et
mon PC:

(PC)
LAN : IP/ethernet
(routeur)
lien routeur-modem : IP/PPPoE/ethernet
(modem ADSL)
ligne téléphonique : IP/PPPoE/ethernet/AAL5/ATM/ADSL
(DSLAM FT)
liaison ATM : IP/PPPoE/ethernet/AAL5/ATM/?
(BAS FT)
réseau de collecte IP/ADSL FT : IP/PPP/L2TP/IP/?
(LNS FAI)
réseau FAI : IP/ethernet

Pour un équipement IP de FT qui participe à la collecte IP/ADSL, mon
petit paquet IP à moi encapsulé x fois n'a qu'une existence toute
relative. Pourtant, il a bien un existence réelle aux deux extrémités du
chemin. De même que pour moi, le réseau IP de collecte reste plutôt
abstrait. Par exemple, il est invisible au traceroute, à l'exception de
la latence qu'il entraîne. Mais dans les deux cas, il s'agit de réseau,
pas d'applicatif.