This is myproposal. In short: TARA routing,see
http://www.igi-global.com/chapter/topology-aggregating-routing-architecture-tara/77501
In long:
Addressing:
- 6480 x2^32 additional IPv4 Unicast addresses by DNS-mapping FQDN to
{TARA-Locator; IPv4 address} withunique IPv4 addr. per respective geopatch#}
- 6480 x2^16 Multicast addresses
- 6480 x2^16 Anycast addresses, incl. several reasonable proposals for the
neededscoping.
Method toensure unique address assignment by the per geopatch distributed
administrators for all threeaddress types.
The TARA-Locatoris deduced from the geographical coordinates.
Routing:
Instead ofany RIB the topologies of 5 zooms of theinter- AND intra-domain
internet are recognized and maintained. New forms fora) Unicast-FIB, b)
Multicast/Anycast-FIB will be built. Next hop determinationis done by
offsetting 4 tables. Neither caching nor binary search across a 500000 entries
sized (classic) FIB is required.
Shortest-pathmeans least number of hops: E.g. a 2-hops route from New York to
Chigaco viaSan Francisco might be selected in case there is one hop (MPLS-LSP)
from NY toSF and another one from SF to Chicago – how would stratium routing
achieve that ?!
Neither“Istanbul-effect” nor stretch-factor > 1 as with other hierarchical
routing concepts
Constraintbased Unicast forwarding is enabled such that any shortest route or
shortestdetour due to sudden blockage is found and adequate directives would
guide theforwarding during the detour.
Trafficoverload & traffic congestion is conceived as a networking problem
ratherthan a user/TCP issue: Well-scoped advertisement of traffic load
informationfor avoiding/resolving congestions will support the routers in order
togradually bypass the spot of overload/congestion.
State-less,world-wide Multicast to millions and millions of receivers such that
both thesender and the receivers can be mobile all the time. It also means
thegeneration of a first Multicast-FIB ever.
Mobility:
ALL usercan be mobile all the time, i.e. can exist without any home agent
orcare-of-address server; while roaming the user is identified by its
homegeopatch number and its IPv4 address.
Incrementaldeployability is guaranteed. Prefix building is only required during
thetransformation phase with respect to classic routers attached users.
While { 5octets TARA-Locator ; 4 octets Ipv4 addr} easily fits into a 16 octets
sizedIPv6 address and while all TARA routing capabilities are independent from
theused address type,
it is yet acommitment pro IPv4, due to lack of belief (based on good reasons
outside ofTARA) that IPv6 will ever fly.
Heiner
-----Ursprüngliche Mitteilung-----
Von: Tony Li <tony...@tony.li>
An: rrg <rrg@irtf.org>
Verschickt: Mi, 27 Nov 2013 9:59 am
Betreff: Re: [rrg] Rebooting the RRG
Dear volunteers,
Thanks for offering to help out and contribute to the workshop program.
I'm very pleased to report that Dmitri Krioukov has tentatively agreed to
present.
Let's keep adding to the list.
So far, the topics that folks have mentioned look like:
- The intersection of naming and routing
- Problems with centralizing control planes
- Network programmability
- Routing in ICN (information-centric networking)
- Multi-layer routing
- SDN routing, including multi-domain SDN
- (Ab)use of BGP
- Mesh routing
- DTN routing
- Privacy
- Compact routing
- Routing for more generalized addressing
- Software defined Internet exchange
And some obvious sources of papers to pursue:
- ANRP
- Routing from SIGCOMM
For those of you have volunteered to help out, could you please:
- Add other topics to the lists above
- Add other specific authors that we should invite
- Reach out and invite speakers
We rely on your help to make this into a successful workshop.
Thanks,
Tony
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
