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

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

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