Re: [rrg] Constraints due to the need for widespread voluntary adoption

[Dae Young KIM <[e-mail]>]

One supplementary not before you attack me. In 4.2a, link-state is just an
example. Also, domain means here any administrative authority in one layer.
You can call it enterprise if you will.

You'll ask 'what about Interdomain-routing'?, which is the real issue here.

To me, it's all the same. Binding/mapping/routing among gateways works the
same way. And whenever you have to cross the admin/authority boundary where
name/address lose their context, you do horizontal binding.

In fact, I'm not a native English speaker and by now am not sure whether I
chose right terms; binding, mapping, routing. Or should they be 'mapping,
binding, routing'?

At least what I'm saying is

       There's only one thing A.
       If A is done vertically, we call it B.
       If A is done horizontally, we call it C(=routing).

If my model is of any value, please help me choose right terms.

On Sun, Dec 6, 2009 at 12:05 AM, Dae Young KIM <[e-mail]> wrote:

> Hi, Noel,
>
> I had a look the two renowned papers you recommended, which happened to be
> know also to me (by author name, not by doc #), and my conclusion is,
> they're almost there, but the model is wrong (more humbly, different) to me.
> Even with Saltzer, it's still confusing enough as he already suggests at the
> latter part of document.
>
> So, rather than responding to your comments piece by piece, let me try to
> phrase my model, hopefully, briefly.
>
> 1. Pre-positioned fundamentals: (, rationales for which being provided at
> the end)
>
>     1.1  Name, id, address are one and the same thing
>     1.2  There's no such thing as hierarchical. Every thing(name, id, addr)
> is, in fact, flat in its ultimate nature. 'Hierarchical' is just temporary
> illusion.
>     1.3  Distinction between location-independence and location-dependence
> is not really there, meaningless. Only (network) graphical significance is
> there.
>     1.4  Nothing needs to be global. being unambiguous within a domain of
> interest is enough; usually called 'local'. Cascaded horizontal mappings
> ensures global uniqueness/unambiguity.
>
> So, before taking off, clean your brain, please. Clean slate. :-)
>
> 2. Fundamentals of networking
>
>     2.1. In networking, there's only one atomic function, which is BINDING.
>     2.2. If the binding is between two entities in adjacent layers, it is
> called MAPPING.
>     2.3. If the binding is between two entities in the same layer, it is
> called ROUTING.
>
> 3. Corollaries
>
>     3.1. Picturing there are only three things to identify, i.e., Name, ID,
> PoA, is an illusion. Depending on how deep you dig into the internal
> structure of any specific layer, there can be much more things to identify.
> Think of overlays, and think of, for example, the internal structure of
> network layers, data-link layers, ATM layers, etc.
>     3.2. There is, in the interest of networking, only incremental
> bi-lateral relationship between two immediate neighboring entities; either
> two being in the same layer or each being in adjacent layers.
>     3.3. Entity, name, ID, address all be used interchangeably.
>     3.4. Relaying (between two adjacent-hop nodes) can be considered as a
> degenerate case of routing.
>     3.5. Relations among entities in the same layer are represented by a
> (network) graph. Routing is executed through a cascade of binding between
> adjacent nodes.
>
> 4. Re-describing the usual ID/Loc Separation model:
>
>     4.1. Application layer mapping (possibly with the help of DNS) binds an
> application name to a node ID. Data is down-streamed through this binding.
>     4.2a. A node acquires knowledge of the network graph consisting of
> nodes in the same layer in the same domain, by use of a given routing
> algorithm, e.g., link-state.
>     4.2b. The source node selects the next-hop node from the graph in an
> attempt to reach its destination node, and so binds, in the routing table,
> its own ID with that of the next-hop node. (The destination node ID in the
> packet header remains intact all through the routing, in this example
> scenario.)
>     4.2c. All referencing to nodes are done by node IDs. Therefore, it can
> be said that routing is done by use of IDs. (In this context, you might
> prefer to use the synonymous term 'address'.)
>     4.2d. Nodes acquire, through a separate protocol like ARP, mapping
> information between node ID to sub-network address (e.g., MAC address) of
> all nodes attached to the same sub-network.
>     4.2e. The source node consults this mapper constructed like above to
> bind the next-hop node ID with the MAC address at which the next-hop node is
> attached to. (In this picture, PoA is, in fact, about the binding of these
> two.)
>     4.2f. The source node passed the packet down to the MAC layer with the
> information, (my MAC addr, next-hop MAC addr)-imbedding-(my node ID,
> destination node ID).  [*Note: The destination node ID doesn't change.]
>     4.2g. The next-hop node receives whatever frames pointing to its
> associated MAC address. Upon opening the frame, if the destination ID
> matches its own, it absorbs the packet. Otherwise, it does it turn of
> routing-binding, and repeats the same procedure as the previous-hop node.
>     4.2h. A node can have multiple PoAs, or put in my terminology, multiple
> mappings of node-ID-to-MAC-address. Selection of a specific mapping out of
> these multiples have already effectively be done in selecting the next hop
> in 4.2b above.
>     4.3. The sub-network layer (or MAC layer) repeats the same or
> equivalent processes described in 4.2.
>
> 5. Consequences
>
>     5.1. The procedures of 4.1, 4.2, 4.3 are all, in fact, equivalent. That
> is, the same procedure can, if necessary, repeats over and over. So,
> overlaying is inherent.
>     5.2. Multi-homing and mobility are all done by the mapping procedure.
> The ID may not change, but the sub-network address can change by ISP
> switching and/or node moving. Engineering challenge is how to make this
> mapping fast enough for given purposes.
>     5.3. There is no need to have ID and Locator separately. Just node ID
> is enough. There's no need for locator, i.e., identifier for PoA. Location
> (so called) information comes from the underlying layer. Locating my
> next-hop node is the job of the underlying layer.
>     5.4. You may say node ID is static or global. But if your application
> should be ported onto another device/node/handset, the node ID might have
> too change, too. Then, you can say ID is local. That is to say, everything
> is relative.
>     5.5. You may say sub-network address (or locator in your term) is
> location-dependent, bears location information. But your network also can
> move; NEMO. Are you going to renumber your moving network every time you
> move to different part of the global network so that your network address
> bear location context? Trying to distinguish whether a address (locator, ID,
> name) is location-dependent or location-independent is meaningless. Only
> contextual significance of entities in the graph of peers in the same layer
> and under same administrative authority (domain...?) is what counts.
>     5.6. It may now seem obvious also to you that hierarchical
> naming/addressing bears only partial significance. Even if you have your
> locators (PoAs) hierarchical, it loses its location imbedded location
> context if your network also moves around like in NEMO. Hierarchy though is
> useful in table look-up in your mapping data base. However, memory can also
> be virtual. So, after all, everything ultimately is 'flat'; at least in the
> sense of 'location'. Again, where you are in the network graph is important;
> you who may be moving. After all, the term 'location' is only causing
> unnecessary confusion. We don't need locators.
>
> 6. Conclusion.
>
> Now I did my exercise. Please tell me where I did my homework wrong.
>
>
> --
> Regards,
>
> DY
> http://cnu.kr/~dykim <http://cnu.kr/%7Edykim>
>



-- 
Regards,

DY
http://cnu.kr/~dykim