Roaming et Handoff sur un reseau existant

Bonjour,

Dominique Blas a écrit :

Premier point : il ne faut pas confondre handoff et roaming que l'on
pourrait traduire, respectivement, par itinérance microscopique (ou
intercellulaire) et itinérance macroscopique (ou interopérateur).

Et bien parlons du roaming :-)

Comment ca se passe si tu passes d'une borne d'un opérateur a un autre ?
Reauthentification ? Changement d'IP ?

--
« Le travail est probablement ce qu'il y a sur cette terre de plus bas et
de plus ignoble. Il n'est pas possible de regarder un travailleur sans
maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager,
dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. »
Boris VIAN

Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<

Bonjour,

Je vais rentrer plus en détails.
Le réseau dont je parle n'est pas un réseau d'AP pur. Il s'agit bien
d'un réseau relié par un réseau filaire (docsis) nécéssitant un
cable modem (intégré au Linksys WCG200).
Aujourd'hui, les AP sont configurés en élément de niveau 2 (pas de
routage). Ceci permet donc en théorie du handoff. Mais le problème
est de savoir si l'IAPP est bien implémenté (oui je sais : les tests
sont la meilleure façon de le savoir). Si l'IAPP est indispensable
pour le handoff, et si quelqu'un connait le protocole utilisé par
linksys dans ses AP pour remplacer ce protocole qui je vous rappel
n'est pas encore standardisé.

Comme je l'ai expliqué (tu as lu ?) on peut très bien faire du handoff
sans IAPP : pontage simple. Toutefois cela reste valable pour des
organisations simples également. Au-delà, et avec le nombre de nomades
qui va avec et surtout avec des nomades windows, le broadcast y va bon
train. Une voie plus << canonique >> étant effectivement tout système de
communication d'info d'état de liaison/session AP-stations entre AP
(dont l'IAPP qui n'est toujours pas RFCisé, il est vrai). Mais bon, je
trouve cela complqué et partiellement ingérable et, surtout, ça
renchérit le prix de l'AP ce qui devient vite ingérable également
budgétairement parlant si on en a des dizaines.

J'ai ausi vérifié, il n'existe à ce

jour pas de firmware en GPL pour ce type d'AP :( . Ceci m'interdit donc
tout ajout/modification du fonctionnement de l'AP.

Ah, navré. Mais j'ai eu tellement l'habitude de faire tout moi-même
(pour éviter ce genre de désagrément notamment : être dans les ténèbres)
que je pensais que TOUTE la gamme Linksys était linuxée :-)
Faut assumer quand on achète hein ?

Existe-il certains outils de gestion en amont pour le handoff? Faut-il
avoir une politique particuliere d'adressage IP?

Si les AP sont configurés en pont l'adressage importe peu.

existe-il des

méthodes de tunning suplémentaire pour le handoff?

On peut aller relatvivement loin mais à condition d'obtenir des infos
natives de la part des AP.

Il me faut aussi

d'autres informations que je suis sûr que vous connaissez, mais chaque
chose en sont temps :)

Punaise, on est partis jusqu'en septembre :-)

db

PS : en ce qui concerne les algorithmes de prédiction de déplacement,
Linksys n'a rien à voir là-dedans ce sont des logiciels à implanter sur
le serveur de localisation (bref, une machine quoi) et à développer
soi-même (pas trop compliqué si on dispose des infos des APs) ou à
acheter ... avec l'infra qui va avec (cf. Aruba, Avaya, etc).





--

Courriel : usenet blas net

Bonjour,

Dominique Blas a écrit :

Premier point : il ne faut pas confondre handoff et roaming que l'on
pourrait traduire, respectivement, par itinérance microscopique (ou
intercellulaire) et itinérance macroscopique (ou interopérateur).

Et bien parlons du roaming :-)
Parlons-en alors !

Comment ca se passe si tu passes d'une borne d'un opérateur a un autre ?
Le roaming n'est pas conçu pour ce cas de figure. En fait, l'itinérance

macroscopique est plutôt passive ou d'arrière-plan aujourd'hui et
absolument pas dynamique.
Par roaming on entend la possibilité d'utiliser les accès de différents
FAI en utilisant le même compte utilisateur et non de se promener d'une
borne à l'autre appartenant à différents fournisseurs tout en conservant
ses sessions fonctionnelles.
Le roaming existe depuis que l'Internet est public soit depuis, en gros,
1994 avec l'initiative IPass. IPass s'appuyant sur des fournisseurs
locaux géographiquement on obtient forcément une adresse public
appartenant au fournisseur dont on dépend à l'instant t.

Reauthentification ? Changement d'IP ?
Déjà tu as de très fortes chances de changer d'IP.

Ce serait en effet étonnant que différents fournisseurs possèdent
le même plan d'adressage (je parle de privé là) sur un lieu donné et,
qui plus est, attribuent la même adresse à une même adresse MAC.

Ensuite, aujourd'hui, oui il y a resignature
(identification/authentification) complète : c'est un autre système, un
autre serveur DHCP, une autre politique de tarification, une autre
méthode d'identification, etc.
C'est exactement comme lorsqu'on change d'opérateur via une liaison
téléphonique : on se retape toute la procédure.
On peut dire : dommage ! Car, en effet, lorsqu'on change de prise de
téléphone on agit mécaniquement alors que lorsqu'on change de borne on
ne manipule rien.

Bien entendu, au niveau technique, on pourrait faire bien mieux. Entre
partenaires d'itinérance on peut très bien imaginer que, puisque les
serveurs RADIUS (ou LDAP, ou ce qu'on veut) communiquent entre eux, le
serveur de localisation du FAI accueillant active la préauthentification
sur l'AP et le serveur DHCP de cetta accueillant réattribue la même
adresse afin d'éviter toute rupture de flux.
Mais en amont, de toute manière chaque FAI dispose de son propre plan
d'adressage public forcément différent et donc la rupture de flux sera
consommée de toute manière.
On se heurte ensuite aux politiques techniques propres à chaque FAI :
chacun conserve son pré carré.

Enfin, commercialement parlant, il n'y a pas d'intérêt réel à l'heure
actuel de travailler dans ce sens : le marché des hotpots n'est pas
suffisant.


Toutefois, le standard HMIP favorise ce genre de roaming dynamique inter
opérateur à condition, bien évidemment qu'il y ait un opérateur de
collecte unique
pour les différents opérateurs concernés (afin de disposer d'une adresse
publique réutilisable).
ET c'est plus simple en IPv6 du coup.

On peut très bien envisager le scénario suivant (qui existe peut-être du
reste maintenant [mes contributions au sujet remontent à 1 an], voir
IPAss, GIAC, PicoPoint, etc) :
un serveur de localisation HMIP situé chez le collecteur (qui dispose
de son propre plan d'adressage).
les abonnés ont la possiblité de contracter avec un FAI un compte
roaming statique uniquement ou un compte mobile (compte roaming
dynamique : un flag dans la schéma RADIUS indique qu'il s'agit d'un
compte mobile et la tarification est alors différente).
Dans le cas d'un compte mobile donc c'est le collecteur qui fournit
l'adresse et son serveur HMIP (ou autre chose pourvu que tout le monde
se comprenne mais les standards c'est mieux pour se comprendre) dialogue
alors avec le réseau partanire sur lequel le nomade est raccordé à
l'instant t afin de lui attribuer une adresse, jouer avec la
préauthentification de l'AP, etc.
au-delà on peut très bien imaginer que les algorithmes de calcul
de déplacement dont j'ai parlé soient situés sur le serveur
de localitation du collecteur. C'est assez simple : coordonnées
géographiques de tous les AP des partenaires, quelques
considérations de propagation locale, la remontée d'info
nécessaire depuis les AP concernées (niveau de réception
notamment) et le tour est ... presque joué.




db



--

Courriel : usenet blas net

Comme je l'ai expliqué (tu as lu ?) on peut très bien faire du
handoff sans IAPP : pontage simple. Toutefois cela reste
valable pour des organisation simple également. Au-delà, et
avec le nombre de nomades qui va avec et surtout avec des nomades
windows, le broadcast y va bon train. La voie pro étant
effectivement tout système de communication d'info d'état de
liaison/session AP-stations entre AP (dont l'IAPP qui n'est
toujours pas RFCisé, il est vrai).

J'ai bien lu, mais le handoff doit être de qualité là ou je
travail... L'IAPP reste donc obligatoire. J'ai entendu parlé de
tap-dance développé par Atmel. Le labo ou je travail semble
s'orienter vers une telle solution. Qu'en penses tu (vous?)? C'est une
solution proprietaire mais elle apporte une latence très faible (de
l'ordre de 20~40ms). En ce qui me concerne je ne sais pas trop, c'est
sur qu'un reseau d'AP avec des firmware sous GPL serait un plus. Mais
est-il possible d'avoir une telle latence? (eventuellement grâce à
ces fameux algorithmes).
Mon labo en est donc arrivé à la conclusion que les AP choisis (les
WCG200) risquent de ne pas suffir. Je peux donner mon avis sur les
prochains modèles, mais je dois être sûr de ce que j'avance côté
latence. J'en appelle donc aux personnes ayant déjà eu la chance de
manipuler ces materiels.

Punaise, on est partis jusqu'en septembre :-)

Quand on aime... ;)

PS : en ce qui concerne les algorithmes de prédiction de
déplacement, Linksys n'a rien à voir là-dedans ce sont des
logiciels à implanter sur le serveur de localisation (bref, une
machine quoi) et à développer soi-même (pas trop compliqué si on
dispose des infos des APs)

c'est à dire? quels types d'infos?

En tout cas merci déjà pour toutes ces infos. Elles me sont fortes
utiles!

--
R1