Hi Heiner, you might find Portland and VL2 research studies interesting though these are not related to Internet scalability - instead trying to create better scalability for very large L2 networks. It seems that both proposals are influenced by locator/identifier studies - one is network centric and the other is host centric.
http://cseweb.ucsd.edu/~vahdat/papers/portland-sigcomm09.pdf http://research.microsoft.com/apps/pubs/default.aspx?id=80693 -- patte On Tue, Aug 25, 2009 at 10:21 AM, <[email protected]> wrote: > Toni, > I think locator means something very specific inside a specific protocol > (which is LISP). It is not used in other architectures like OSPF, BGP. My > general understanding of a network is that it consists of nodes and links > which have identifiers and attributes. A nodal attribute may be its > reachability info but as well some geo-location information which can both > be used for determining the next hop (as is done by OSPF,BGP resp. would be > done by TARA). So there is no stringent need for a locator, its only > model-specific. > I write this to leash myself, because in a first second I intended to write > about "mobile locators". > > Well, on the LISP-mailinglist the issue "mobile node" was raised (and then > forgotten) which I think is a very important aspect: You may treat it like > an exotic service, but you may also treat it as if every single node is > potentially mobile. However then there is no doubt: you have to have a > stable anchor for mastering the relative distances which can only be the > grid of the geographical coordinates. > > But those are just imaginary locators (no one has ever stumbled over these > longitude and/or latitude ropes:-) and don't need to be sent messages from > and to- neither with nor without checksum. > Heiner > > > > In einer eMail vom 24.08.2009 07:37:48 Westeuropäische Normalzeit schreibt > [email protected]: > > Noel, Scott, Heiner, thank you for engaging. > > Scott Brim wrote: >> Your local router doesn't have to solve this problem. It's >> end-to-end, > > So should an end be engaged with remote end's local link interfaces, like > sending packets with destination an interface locator, and why? > >> and each of those flows may have a different solution. >> Some like the weather map may be solved in the application. > > If a problem is left intact in the routing, multiple working groups are > needed to solve its effects. > >> You might >> find this interesting: >> >> http://www.ietf.org/mail-archive/web/multipathtcp/current/maillist.html >> >> (for multipath SCTP see the TSVarea list) > > Toni Stoev wrote: >> "Why should it be simple when it can be complex?" -- Folklore >> >> You are reading your email off your portable computer and you have a >> constantly updated weather map on your desktop. You may be chatting through >> an instant messaging service and may be listening to live-streamed audio, >> and may start talking on the computer videophone. >> You move to a different room, so you unplug your network cable, and you >> know a wireless link will keep those communications running. > > That is the easy case. What if you are in a public place and get public > globally routable locators, should the locators be bound to interfaces and > should the remote servers take care therefor of your local connectivity? > >> Your local router has to realize the situation and stop transmitting >> communications packets to the cable interface and start transmitting them to >> the computer's wireless interface, and any broken sessions have to be >> re-established with remote servers. >> You are the same person using the same network services on your same >> computer through your same router, but you experience service slowdown or >> even need to reinitiate some of the communications. Why? >> >> (Re)searcher Toni > > The same > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg > > > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg > > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
