OVH Cloud OVH Cloud

RFC 2684 (anciennement RFC 1483)

45 réponses
Avatar
Angelot
Bonjour,

Il semble que l'utilisation de cette RFC (encapsulation multiprotocoles sur
AAL-5) est en décroissance.

Néanmoins, dans les utilisations que j'observe la méthode de "multiplexage
par circuit virtuel" qui permet de gagner 8 octets par envoi de datagrammes
IP soit beaucoup moins utilisée que la méthode "LLC/SNAP encapsulation".

Quelqu'un partagerait-il cet avis ?
Cordialement,
Angelot

10 réponses

1 2 3 4 5
Avatar
Jacques Caron
Salut,

On Thu, 20 May 2004 21:47:32 +0200, Angelot
wrote:

Dans le format routé, il serait bien délicat d'utiliser la méthode VCmux
(multiplexage par cicuit virtuel) car il faudrait 2 connections VCC,
l'une pour IP (avec EtherType 0x0800), l'autre pour ARP (0x0806).


Euh... Ca fait un bail que je ne me suis pas plongé là-dedans, mais je ne
vois pas bien pourquoi on aurait besoin d'ARP sur une liaison
point-à-point routée, sur laquelle ne circule aucune adresse MAC?

Ceci dit, en regardant comment je faisais à l'époque, je vois que je n'ai
toujours utilisé que du routed IPv4 avec LLC/SNAP (aka aal5snap chez
cisco), aussi bien pour des liaisons ISP/client (sur Turbo DSL) que pour
des liaisons internes (sur notre réseau ATM privé). Mais je n'ai aucune
idée de pourquoi :-( J'ai le sentiment qu'au moins dans un cas c'était une
limite imposée par le matériel (le routeur mis chez le client), et que
dans l'autre c'était nécessaire pour l'interworking FR/ATM, mais j'avoue
que j'ai un peu la flemme de m'y replonger...

Remarque : il ne sert finalement pas à grand chose de dire que l'on gagne
quelques octets, compte tenu :
(1) avec PPPoA : du bourrage pour obtenir une charge utile PPP de
longueur MRU,


Hu?

(2) avec PPPoA ou RFC 1483 : du padding dans CPCS-PDU pour obtenir une
découpe entière en n fois 48 octets.


Ben si, justement, les octets LLC/SNAP supplémentaires au début risquent
de faire passer à un multiple de 48 supplémentaire.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Avatar
Angelot
Merci Laurent,

Dans le cas des offres Free dégroupées avec Freebox, il s'agit d'IP routé
sur ATM donc "Classical IP" (RFC 2225)


Le "donc" me gêne. IP routé sur ATM c'est aussi par PPPoE, PPPoA et RFC 2684
qui sont au moins 3 méthodes différentes.

Je ne connais pas "Classical IP".
Quelles sont vos références constructeurs pour indiquer que Free utilise
CLIP ?

Cordialement,
Angelot

Avatar
Annie D.
Angelot wrote:

A ma connaissance, tous les opérateurs ADSL grand public en France
utilisent l'encapsulation sur AAL5 selon RFC 1483 ou plutôt son
successeur 2684. En mode routé chez Free dégroupé et en mode ethernet
ponté couplé à PPPoE chez tous les autres.


PPPoA et RFC 2684 sont 2 encapsulations sur AAL-5, mais le format est
suffisamment différent pour que l'un ne soit pas compatible avec l'autre.
PPPoA est ponté (un format routé n'aurait pas de signification)


Ce n'est pas vraiment ce qui ressort de cet article de R. Moulin :
<news:403bcff4$0$5909$
(le reste du fil devrait aussi vous intéresser)

En résumé : PPPoA utilise le format routé de RFC 2684, les deux ne sont
donc pas incompatibles. A titre personnel, je ne vois pas en quoi PPP
serait plus ponté que routé ou l'inverse, mais bon.

et RFC 2684 ponté n'utilise pas PPP.


Si l'un devait utiliser l'autre, ce serait plutôt dans l'autre sens :
PPP utilisant RFC 2684 comme support.

Maintenant, je dirais que PPPoE sur AAL-5 serait équivalent à RFC 2684 ponté
(avec Ethernet)


Ça, c'est une lapalissade.

PPPoE sur AAL-5, mode routé, ne me semble pas avoir de signification : c'est
contradictoire.


Evident aussi : PPPoE est transporté par ethernet, et ethernet est
transporté par AAL5 en mode ponté.


Avatar
Annie D.
Angelot wrote:

Je ne sais ce qu'il en est chez les opérateurs utilisant un mode VCMUX
routé, mais ARP n'est pas utile sur les liens point à point dont l'ADSL
fait partie. Chez Free, la Freebox fait proxy DHCP, elle peut bien faire
aussi proxy ARP pour la connexion en ethernet. Quelqu'un a des infos ?


Le POP réalise éventuellement son ARP pour l'acheminement dans son propre
réseau, mais pas pour le compte du client. Il n'aurait même pas besoin
d'être proxy ARP, il déroule sa propre mécanique de routage et acheminement
pour tout ce qu'il reçoit.


Je ne parle pas du PoP (le DSLAM chez Free) mais du "modem" chez le
client. S'il n'y a pas besoin d'ARP sur le lien ADSL, ARP n'en reste pas
moins nécessaire sur le lien ethernet entre le modem et la station du
client pour que cette dernière sache à quelle adresse MAC destination
envoyer les paquets IP.


Avatar
Laurent MARTIN
Salut,

"ATMARP and InATMARP packets are to be encoded in AAL5 PDUs using
LLC/SNAP


encapsulation."


On ne parle pas de classic IP mais, en ADSL, de PPPoE, PPPoA et RFC 2684.
Dans le cas des offres Free dégroupées avec Freebox, il s'agit d'IP routé

sur ATM donc "Classical IP" (RFC 2225) qui peut utiliser les deux méthodes
d'encapsulation définies dans la RFC 2684 : LLC/SNAP ou VC-multiplexed. Les
deux documents recommandent formellement l'utilisation de l'encapsulation
LLC/SNAP pour l'IP, bien qu'ils laissent la possibilité de négocier autre
chose (VC-mux) par configuration manuelle (PVC) ou par signalisation B-LLI
(pour les SVC).
Les modems Alcatel Speed Touch Pro non modifiés ne savent faire que du
Classical IP routé encapsulé LLC/SNAP, d'où les travaux des développeurs du
site www.forpage.com pour permettre d'utiliser l'encapsulation VC-mux sur
ces équipements.

Dans le cas des PVC (tous les FAI ADSL utilisent des circuits virtuels
permanents), le protocole ATMARP/InATMARP permettent d'obtenir l'adresse IP
de l'extrémité distante lorsque son adresse ATM ("ATM Forum NSAPA format" ou
"1 E.164 format") est connue.
Pour moi, ces requêtes ATM doivent être encapsulées LLC/SNAP même si l'IP
routé est VC-mux sur le même canal.
Il me semble qu'il y a un seul PVC (8*36 ?) pour les offres Free dégroupées
dans lequel passent : l'IP routé VC-mux et un échange de paquets
ATMARP/InATMARP lors de la mise en route de la Freebox pour apprendre les
adresses IP (qui peuvent aussi être configurées manuellement parce qu'elles
sont fixes).


Avatar
Angelot

http://www.google.fr/groups?%240%245909%247a628cd7%40news.cl

ub-internet.fr

Ok, cela fonctionne

A priori, mon avis diverge

Considérons la trame AAL-5 (unité CPCS-PDU non découpée)

Dans le format VCCmux routé de RFC2684, la trame débute directement par
l'en-tête IP.


IP est le seul protocole supporté par VCMUX routé ? Ce serait étonnant.


Non évidemment, ce peut être AppleTalk, IPX, Netbeui.
PPP est en point à point, donc pas de routage.

Dans le format VCCmux de PPoA la trame débute par l'identificateur de
protocole, qui peut être IP, LCP, IPCP, CHAP...


C'est l'en-tête PPP. Dans les deux cas, la trame commence par l'en-tête
du protocole transporté, comme c'est le cas avec bien d'autres méthodes
de transport.


J'acquiesce !

Donc PPPoA-VCmux débute par l'en-tête PPP (niveau 2), et
RFC2684-VCmux-format routé débute par l'en-tête d'un protocole de niveau 3
de mode non connecté. Ce n'est pas tout à fait la même chose.

Sinon une cacahuète est équivalente à un chameau, les 2 ont 2 bosses.

A partir du moment ou les deux extrémités savent à quoi s'attendre, je
ne vois pas où est l'incompatibilité.


La configuration et le paramétrage ne sont pas les mêmes. Si le routeur
(équipement) doit router (fonction routage) sur un format routé (structure
de trame), en présentant PPPoA, il reste coi.

PS: Z'êtes sûr que votre horloge est à l'heure ?


Elle dérive seule d'une demi-heure par 48 heures. C'est gênant au bout d'une
semaine, quand je crois me coucher tôt vers 1 heure du matin.

Cordialement,
Angelot


Avatar
Angelot
Merci,

Je ne parle pas du PoP (le DSLAM chez Free) mais du "modem" chez le
client. S'il n'y a pas besoin d'ARP sur le lien ADSL, ARP n'en reste
pas



moins nécessaire sur le lien ethernet entre le modem et la station du
client pour que cette dernière sache à quelle adresse MAC destination
envoyer les paquets IP.


Pour sortir le datagramme hors du LAN, l'ARP est faite normalement sur
l'interface du routeur, rien n'est modifié de ce côté.


Dans le cas où l'interface ATM est sur un routeur, oui. Le problème,
c'est que la Freebox n'est pas un routeur. C'est juste un modem un peu
particulier. Si routeur il y a, il est situé derrière la Freebox, en
ethernet.


Je présume que l'on a un lien Ethernet entre le routeur éventuel et la
Freebox avec son interface ATM. Est-ce bien le cas ?

Si la Freebox ne traite pas le niveau 3 sur l'interface Ethernet,
dispose-t-elle d'une adresse Ethernet qui pourrait être déclarée
statiquement au routeur. Autrement, comme Laurent l'indique, est-ce du
Classical-IP, dont je connais pas encore le détail ?

Cordialement,
Angelot



Avatar
Annie D.
Angelot wrote:

<news:403bcff4$0$5909$
(le reste du fil devrait aussi vous intéresser)


Je n'ai pas accès, le lien ne fonctionne pas chez moi.


L'article a dû expixer sur le serveur de news que vous utilisez s'il n'a
pas une durée de rétention qui remonte jusqu'au mois de février (héhé).
Dans ces cas, il reste les archiveurs comme Google Groups :

http://www.google.fr/groups?%240%245909%247a628cd7%40news.club-internet.fr

En résumé : PPPoA utilise le format routé de RFC 2684, les deux ne sont
donc pas incompatibles.


A priori, mon avis diverge

Considérons la trame AAL-5 (unité CPCS-PDU non découpée)

Dans le format VCCmux routé de RFC2684, la trame débute directement par
l'en-tête IP.


IP est le seul protocole supporté par VCMUX routé ? Ce serait étonnant.

Dans le format VCCmux de PPoA la trame débute par l'identificateur de
protocole, qui peut être IP, LCP, IPCP, CHAP...


C'est l'en-tête PPP. Dans les deux cas, la trame commence par l'en-tête
du protocole transporté, comme c'est le cas avec bien d'autres méthodes
de transport.

A partir du moment ou les deux extrémités savent à quoi s'attendre, je
ne vois pas où est l'incompatibilité.

PS: Z'êtes sûr que votre horloge est à l'heure ?


Avatar
Annie D.
Angelot wrote:

Je ne parle pas du PoP (le DSLAM chez Free) mais du "modem" chez le
client. S'il n'y a pas besoin d'ARP sur le lien ADSL, ARP n'en reste pas
moins nécessaire sur le lien ethernet entre le modem et la station du
client pour que cette dernière sache à quelle adresse MAC destination
envoyer les paquets IP.


Pour sortir le datagramme hors du LAN, l'ARP est faite normalement sur
l'interface du routeur, rien n'est modifié de ce côté.


Dans le cas où l'interface ATM est sur un routeur, oui. Le problème,
c'est que la Freebox n'est pas un routeur. C'est juste un modem un peu
particulier. Si routeur il y a, il est situé derrière la Freebox, en
ethernet.

Les notions VCmux / LLC / format ponté / format routé ne concernent que
l'interface ATM.


Je ne dis pas le contraire.

Le datagramme étant remis au routeur par l'interface Ethernet, le routeur
l'encapsule dans AAL-5 pour le transmettre, par exemple en VCmux/format
routé.


La Freebox n'est pas un routeur.


Avatar
Angelot
"Annie D." a écrit dans le message de news:

Angelot wrote:

IP routé sur ATM c'est aussi par PPPoE, PPPoA


Si je ne m'abuse, on dit IP sur ATM (IPoA) seulement quand IP est
transporté directement sur AAL5 sans encapsulation intermédiaire.


J'ai l'impression que c'est plus générique. Dans un petit ouvrage de Pierre
Rolin, assez succinct malheureusement, dans le chapitre IP sur ATM, l'auteur
Hossam Afifi montre le format ponté RFC1483 avec trame MAC. Ce format est
directement recopié de la norme, sans plus-value.

J'ai un exemple patent d'enfarinage : IP sur SDH. Dans de nombreux articles
l'expression est si bien employée qu'on croit les datagrammes mis
directement dans les conteneurs SDH. Non, ce n'est pas cela, il faut une
couche 2 d'arrivée au multiplexeur SDH et de départ de celui-ci.

IP sur ATM signifierait d'ailleurs IP sur le modèle ATM (par AAL-5 avec SSCS
vide) et non pas IP sur le protocole ATM, car ATM n'est qu'un des protocoles
du modèle ATM.

Et IP sur AAL-5 peut donc être directe ou par intermédiaire d'autres
protocoles.

Comme
on dit PPP sur ATM (PPPoA) quand PPP est directement transporté sur
AAL5. Je ne crois pas qu'il viendrait à l'idée de quiconque de dire que
PPPoE c'est du PPPoA juste parce qu'en haut il y a PPP et en bas AAL5.


J'opterais plutôt pour le fait que l'on dit PPPoA pour se référer à la RFC
2364 dont c'est le titre. Et, dans ce cas, les possibilités sont bien
délimitées.
De la même façon on dit PPPoE pour désigner ce qui est écrit dans RFC 2516.

Avouez, c'est plus sympathique de parler PPPoA que de RFC 2364, c'est plus
doux à l'oreille !!!!

Cordialement,
Angelot


1 2 3 4 5