RFC 2684 (anciennement RFC 1483)

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. 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.

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.

NetBEUI n'est pas un protocole routable, donc pas de routage non plus
avec lui. Et pourtant, il utilise le format routé. La particularité de
PPP par rapport aux autres protocoles cités est que c'est un protocole
de niveau 2. Et parler de "routé" dans ces conditions, ça choque !

Je fais bien une distinction (quand je n'écris pas rapidement) entre format
routé, fonction routage, et équipement routeur.
Un même équipement routeur, pour le trafic ATM entrant, peut avoir une
fonction de routage sur une interface, et une fonction de pont sur une autre
interface, ceci avec une trame AAL-5 de format routé.

Vous pourrez faire l'essai, la RFC 2364 PPPoA n'emploie jamais le terme
routé ou ponté (exception faite d'une seule fois pour parler des sections
physiques, ce qui est un autre sujet).

RFC 2684 = 4 formats
RFC 2364 = 2 formats

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.

Non, évidemment, ce n'est pas la même chose vu d'en haut. Mais à mon
avis, vu d'en bas, c'est-à-dire de la couche AAL5, ça ne fait aucune
différence : contrairement au format ponté où il faut insérer/extraire
les informations de couche MAC spécifiques au protocole ponté, en format
routé le contenu est directement pris en charge par la couche
supérieure. Et à mon avis toujours, le terme de format "routé" dans ce
cadre n'a pas grand chose à voir avec le routage de niveau 3.

Supposons que l'on mélange PPPoA-VCmux avec RFC2684-VCmux-format routé au
sein d'un même VCC. Les cellules arrivent dans la couche ATM et sont passées
par le SAP ATM à la couche AAL-5.

L'ennui est que AAL-5 n'est pas multiconnexion, je ne pense pas qu'AAL-5
puisse aiguiller vers des SAP AAL-5 différents, à la manière d'AAL-2.

La solution serait d'avoir une connection VCC pour PPPoA-VCmux et une autre
connection VCC pour RFC2684-VCmux-format routé. Dans le premier cas, les
trames AAL-5 sont passées au SAP AAL-5 qui arrive dans une couche PPP. Dans
le deuxième cas les trames AAL-5 sont passées au SAP AAL-5 sur lequel on a
monté une couche IP par exemple.

Cordialement,
Angelot

J'acquiesce plus !

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?

J'acquiesce !

Je suis en ADSL avec PPPoA-VCmux et je vois passer avec Ethereal des ARP
request vers le réseau, avec EtherType = 0x0800 (celui d'IP et non pas ARP).

(1) J'ai dû louper une marche, l'EtherType n'est pas 0x0806

(2) Etant en point à point, tel que tu as rappelé, je ne vois pas ce que
viennent faire ces ARP. Finalement, j'acquiesce plus ! Mais le réseau s'en
moque, je ne vois pas passer les ARP reply, ce qui ne dérange pas mon PC.

Cordialement,
Angelot

Je n'en sais pas plus, ce qu'il a écrit dans son dernier article me
paraît cohérent et plausible. Le protocole ATMARP du CIP qu'il décrit
permettrait à la Freebox lors de l'initialisation de la connexion ADSL
de récupérer les paramètres IP destinés à l'équipement de l'abonné
(adresse, masque, passerelle) qu'elle lui communique par DHCP (proxy
DHCP) si celui-ci est en ethernet.

IPCP de PPP pourrait bien aussi faire cela

Ensuite, la Freebox surveille les
requêtes ARP de l'équipement de l'abonné et répond avec sa propre
adresse MAC pour les adresses de son sous-réseau (proxy ARP). Mais tout
ceci n'est que spéculation.

Je comprends mieux cette fois-ci.

Cordialement,
Angelot

Angelot wrote:

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.

NetBEUI n'est pas un protocole routable, donc pas de routage non plus
avec lui. Et pourtant, il utilise le format routé. La particularité de
PPP par rapport aux autres protocoles cités est que c'est un protocole
de niveau 2. Et parler de "routé" dans ces conditions, ça choque !

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.

Non, évidemment, ce n'est pas la même chose vu d'en haut. Mais à mon
avis, vu d'en bas, c'est-à-dire de la couche AAL5, ça ne fait aucune
différence : contrairement au format ponté où il faut insérer/extraire
les informations de couche MAC spécifiques au protocole ponté, en format
routé le contenu est directement pris en charge par la couche
supérieure. Et à mon avis toujours, le terme de format "routé" dans ce
cadre n'a pas grand chose à voir avec le routage de niveau 3.

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.

Comme je viens de l'écrire, je pense que le format "routé" d'AAL5 n'a
rien à voir avec la fonction routage. Si l'équipement est configuré pour
une encapsulation PPPoA, il interprète les trames reçues comme du PPP,
décapsule le protocole de niveau 3 transporté dessus et route en
fonction de celui-ci. S'il est configuré pour une encapsulation directe
IPoA par exemple, il interprète les trames reçues comme de l'IP et route
en fonction.

Angelot wrote:

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 ?

Ethernet ou USB. J'ignore comment l'interface USB fonctionne ; émulation
ethernet, ATM, autre ?

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.

Je ne sais pas. Il y a des chances que la Freebox ait une adresse
ethernet propre, mais devoir la déclarer statiquement au routeur me
paraît contraignant : si je me souviens bien, les sous-réseaux IP
définis sont des /24, donc il faudrait définir en statique cette adresse
MAC pour les 254 adresses IP du sous-réseau.

Autrement, comme Laurent l'indique, est-ce du
Classical-IP, dont je connais pas encore le détail ?

Je n'en sais pas plus, ce qu'il a écrit dans son dernier article me
paraît cohérent et plausible. Le protocole ATMARP du CIP qu'il décrit
permettrait à la Freebox lors de l'initialisation de la connexion ADSL
de récupérer les paramètres IP destinés à l'équipement de l'abonné
(adresse, masque, passerelle) qu'elle lui communique par DHCP (proxy
DHCP) si celui-ci est en ethernet. Ensuite, la Freebox surveille les
requêtes ARP de l'équipement de l'abonné et répond avec sa propre
adresse MAC pour les adresses de son sous-réseau (proxy ARP). Mais tout
ceci n'est que spéculation.

"Annie D." <annie.demur@free.fr> a écrit dans le message de news:
40AE06B9.D7CFFDAC@free.fr...

"Angelot" wrote:

Je suis en ADSL avec PPPoA-VCmux et je vois passer avec Ethereal des ARP
request vers le réseau, avec EtherType = 0x0800 (celui d'IP et non pas
ARP).

(1) J'ai dû louper une marche, l'EtherType n'est pas 0x0806

Alors comment savez-vous que c'est de l'ARP ?

Je n'ai pas les yeux en face des trous. Le numéro de protocole IP que j'ai
lu est celui à l'intérieur de la charge utile de l'ARP, lequel est bien
repéré dans la pseudo-trame Ethernet comme EtherType 0x0806.

(2) Etant en point à point, tel que tu as rappelé, je ne vois pas ce que
viennent faire ces ARP.

On peut s'interroger sur l'existence et l'utilité d'ARP en IPoA, mais il
n'y a aucun doute en PPPoA : il n'y en a pas et ça ne servirait à rien.
Si vous avez Windows, méfiez-vous : cet OS attribue une adresse MAC aux
interfaces PPP.

Oui, je suis avec Windows.

Et je me pose cette question : l'ARP part du PC vers le modem, mais il est
possible que le modem ne le transmette pas. sur ATM. En tout cas, ça ne gêne
pas le PC de ne pas recevoir de réponse.

Cordialement,
Angelot

Merci Laurent,

Quelques précisions, en attendant que l'ATM-forum préconise une méthode
particulière pour encapsulé l'IP sur ATM/AAL, il existe :

A ma connaissance, l'ATM Forum ne s'occupe pas d'IP, ça ne risque pas
d'arriver.

* LAN Emulation qui offre les fonctions d'un réseau local d'entreprise sur
support ATM : IP dans trames MAC (Ethernet, IEEE 802.x.) pontées sur ATM,
encapsulation VC-mux (les premiers octets de PAD ayant une fonction
d'entête

ne sont pas 0x00).

LANE est spécifié par l'ATM Forum et il me semble anachronique de parler de
VCmux, terme de l'IETF.
D'autre part, on a MAC sur AAL-5 avec LANE, c'est verrouillé. Donc pas de
possibilité de faire autre chose, l'équivalence VCmux ne me semble pas
appropriée.

Un autre point, on a IP / LLC/SNAP / MAC de manière traditionnelle, ce n'est
pas un PAD au sens RFC 2684.

* On peut aussi faire passer et configurer de l'IP dans une liaison PPPoA
(RFC 2364) encapsulation VC-mux (standard de facto) ou LLC/NLPID. Cette
méthode est utilisée dans les offres ADSL résidentielles de France-Telecom
avec en plus le PPPoE (qui est en fait de l'Ethernet ponté sur AAL5
encapsulé LLC/SNAP).

Précision sur votre précision.

Relisez la RFC de PPPoE, on ne parle pas d'AAL-5. C'est uniquement PPP sur
Ethernet, libre à chacun de transporter l'Ethernet comme il veut. Donc,
PPPoE n'est pas ce que vous dites.

Il faudrait dire PPPoE + RFC 2684 soit VCmux, soit LLC (le terme ponté est
superflu puisque évident).

Cordialement,
Angelot

Quelques précisions, en attendant que l'ATM-forum préconise une méthode
particulière pour encapsulé l'IP sur ATM/AAL, il existe :

* Classical IP over ATM : IP routé sur ATM (selon la terminologie RFC 2684),
encapsulation par défaut : LLC/SNAP (Free dégroupé utilise VC-mux d'après ce
que j'ai appris dans ce groupe de news, notamment les difficultés pour faire
fonctionner certains modems à la place de la free-box).

* LAN Emulation qui offre les fonctions d'un réseau local d'entreprise sur
support ATM : IP dans trames MAC (Ethernet, IEEE 802.x.) pontées sur ATM,
encapsulation VC-mux (les premiers octets de PAD ayant une fonction d'entête
ne sont pas 0x00).

* On peut aussi faire passer et configurer de l'IP dans une liaison PPPoA
(RFC 2364) encapsulation VC-mux (standard de facto) ou LLC/NLPID. Cette
méthode est utilisée dans les offres ADSL résidentielles de France-Telecom
avec en plus le PPPoE (qui est en fait de l'Ethernet ponté sur AAL5
encapsulé LLC/SNAP).

Laurent,

"Angelot" wrote:

Je suis en ADSL avec PPPoA-VCmux et je vois passer avec Ethereal des ARP
request vers le réseau, avec EtherType = 0x0800 (celui d'IP et non pas ARP).

(1) J'ai dû louper une marche, l'EtherType n'est pas 0x0806

Alors comment savez-vous que c'est de l'ARP ?

(2) Etant en point à point, tel que tu as rappelé, je ne vois pas ce que
viennent faire ces ARP.

On peut s'interroger sur l'existence et l'utilité d'ARP en IPoA, mais il
n'y a aucun doute en PPPoA : il n'y en a pas et ça ne servirait à rien.
Si vous avez Windows, méfiez-vous : cet OS attribue une adresse MAC aux
interfaces PPP.