mobility (and multicast...)
Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk> Tue, 19 January 1993 11:46 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00662;
19 Jan 93 6:46 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00658;
19 Jan 93 6:46 EST
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa00606;
19 Jan 93 4:40 EST
Received: by thumper.bellcore.com (4.1/4.7)
id <AA22363> for mma@pegasus.bellcore.com; Tue, 19 Jan 93 04:01:57 EST
Received: from bells.cs.ucl.ac.uk by thumper.bellcore.com (4.1/4.7)
id <AA22359> for /usr/lib/sendmail -oi -fowner-pip X-pip;
Tue, 19 Jan 93 04:01:54 EST
Message-Id: <9301190901.AA22359@thumper.bellcore.com>
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.20350-0@bells.cs.ucl.ac.uk>; Tue, 19 Jan 1993 09:01:34 +0000
To: pip@thumper.bellcore.com, tuba@lanl.gov
Subject: mobility (and multicast...)
Date: Tue, 19 Jan 93 09:01:29 +0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
there was this really cute idea way back in the mid 80s from cheriton and deering that you could use multicast groups of one and multicast routing to achieve mobile hosts, which leads me to respond to yakov's posting of the mobile document to the tuba list recently with the following... VAMPIRE = Vicinity Addressing, Mobility Path, Intedrnet Routing Extension unlike the cell based beakon based approach a lot of mobile IP 9or isogram) approach has taken, this is based on 2 assumptions. 1. Vicinity Based Addresses - an address i nthe future can be assigned with hierarchical georgraphic centered assignment, and we can direct a cast to roughly the right place (a la landmark routing and other similar approaches). If we have vicinity based multicast (i.e. remove the TTL type scoping, and put it in addresses as it should be, we can address groups in a vicinity - a group could be a mobile host (groupo of one) or mobile LAN) 2. mobility paths: mobile hosts _know_ wheere they are going, so new schemes like PIP permit us to efficiently source route a packet to the vicinity, then track the local moves....a mobile host or designated mobile router on a mobile lan could use scoped multicast to advertise its moving vicinity-ness... 3. i believe mobility should be _integral_ in routers and not involve more processes/servers etc....if hierarchical multicast addressing and routeing are in place, i think something could evolve that is very clean.... anyhow, sorry to cross post, just thinking out loud... jon
- mobility (and multicast...) Jon Crowcroft
- mobility (and multicast...) Jon Crowcroft
- Re: mobility (and multicast...) Paul Tsuchiya