Typo: - IDR operates only on AS numbers or Domain addresses. (Node) addresses are used only in inter-domain routing.
>> - ..... only in intra-domain routing. On Sun, May 23, 2010 at 3:11 PM, Dae Young KIM <[email protected]> wrote: > Resemblance to CLNP ends with that my one uses node address; > > - Node addresses are local with me while it is global with CNLP. > - I don't carry subnet locators. > > In my model, packets are not routed on the subnet locator (which is missing > in my model). Rather, > > - Each subnet router keeps track of the membership of nodes inside its > subnet. > > - Whenever there's differential in the membership, by either a new > incoming node or a leaving node, this change of membership would be > broadcast to other subnet routers in the same domain(AS). > > - Assuming the an LS routing is used inside a domain, such differential > can also be distributed as an addendum to normal LS update packets. > > - So, each router will know where any node should reside in a subnet > managed by which router. > > - Since the routing is still LS, each router keeps knowledge of the > whole network topology so that shortest paths can be determined, which will > then indicate what will be the next hop router for a destination node from > the current router. > > - All this can be done without padding locators (or addr of subnet > router) to each packets. Packets carry only node address and AS numbers > instead, the latter not being used within an AS but only to be used for IDR. > > - The whole intra-domain routing operation might look similar to bridge > operations. Not totally, however. Just similar. > > - The penalty is that we deal with flat node addresses. > > - The gain is that mobility is provided directly by routers as part of > inherent operations of routing. No extra infrastructure like HA / FA or > ID/Loc mapping servers. This way, faster mobility can be provided since it > is done directly by routers. > > - The whole structure is much friendlier to mobility. Mobility is an > inherent feature, not as added/patched-on function. > > The whole point is: > > - In contrast to common belief that you need ID and Locator separately > to provide seamless mobility, > > - the same can be done only with an identifier of a node (now I call > node address), without extra bothering about locators. > > This description is more from the mobility perspective, but also renders > consequences of routing in general: > > - Address is local, name is global. > - IDR operates only on AS numbers or Domain addresses. (Node) addresses > are used only in inter-domain routing. > - In a sense, IDR is quite symmetrical to intra-domain routing, with > migrating(multi-homing) domains seen as network nodes. > - So, any routing can be used for IDR. People might still prefer policy > routing and hence BGP4-modified. > - Size of the routing table is limited by the AS# space. Too big? Then, > split in multi-tiers. > - No Internet governance since address are local. (Although that for AS > will still in place. But much less political.) > > > On Sun, May 23, 2010 at 1:54 PM, Joel M. Halpern <[email protected]>wrote: > >> Note that although CLNP use Node Identifiers, these were coupled to subnet >> locators. That is, the NSAP specifically identified the subnet to reach the >> host on. Further, out expectation was that a preamble to the NSAP would be >> the service provider providing connectivity. SO that the NSAP was a >> topologically sensitive address, with a NODE identifier as the last portion. >> (Yes, there are parallels to some of the other ideas this research group >> has discussed. We did not take that work anywhere near there at the time.) >> >> Yours, >> Joel >> >> >> Dae Young KIM wrote: >> >>> On Sun, May 23, 2010 at 2:06 AM, Noel Chiappa <[email protected]> >>> wrote: >>> >>>> > From: Dae Young KIM <[email protected]> >>>> >>>> > the role of PoA is already served by MAC address, and not has to be >>>> > duplicated by extra 'Locator'. >>>> >>>> i) Not all networks have a MAC (although most do, now). >>>> >>>> ii) A MAC serves to globally _identify_ an interface, but it is not >>>> enough to >>>> _locate_ it (i.e. to be useful to the path selection). It will be >>>> necessary >>>> to add some extra information, such as a structured name of the network >>>> the >>>> interface is connected to, to make it an interface name which the path >>>> selection (routing) can use. After all, if you do not have that extra >>>> information, you basically have a world-wide bridged network. >>>> >>> >>> Not necessarily. I think I can build a sound network topology only >>> with node addresses. CLNP, for example, didn't need interface address >>> to do routing. >>> >>> Remember, my question was in the context of a node which has _two_ >>>> interfaces, to widely separated (in network connectivity terms) >>>> networks, >>>> such as i) a particular wireless LAN, and ii) a 3G cellular network. >>>> >>> >>> Why should it be a problem in my picture?: >>> >>> - At inter-net level, my node will have two links each pointing to a >>> remote router at the other surface of either LAN or 3G. >>> >>> - LAN will identify one of the interface with its MAC address while >>> 3G will do the other with its L2 address(whatever it is). >>> >>> > mobility is inherently supported by routers without resorting to >>>> extra >>>> > mapping (ID>Loc) or agent(HA/FA) infrastructure. >>>> >>>> Only within an AS. What happens if the node leaves the AS (perhaps to a >>>> different wireless LAN)? >>>> >>> >>> Moving across LANs within an AS won't affect its fast mobility. >>> >>> There'll surely be a problem in fast mobility when a node leaves an AS >>> for another AS: >>> >>> o In its most primitive fashion, the TCP connection would break. >>> You have to reconnect. >>> >>> o A fast inter-AS context-switching mechanism might be devised. >>> >>> o DNS should be updated with a new mapping, name > (addr, AS-new). >>> This, of course, is a challenge; DNS synchronization is slow. How to >>> work around this? >>> >>> I have yet to work on these inter-AS mobility issues. Hope I won't >>> totally fail. >>> >>> Noel >>>> >>>> >>> >>> >>> > > > -- > DY > -- DY
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
