--- mo...@necom830.hpcl.titech.ac.jp wrote:
From: Masataka Ohta <mo...@necom830.hpcl.titech.ac.jp>
Scott Weeks wrote:
> I have been reading your posts on IETF and here regarding the
> above and I'm curious as to your thoughts on John Day's RINA.
As you give no reference, let's rely on wikipedia
https://en.wikipedia.org/wiki/Recursive_Internetwork_Architecture
--------------------------------------------------------
Yes, my apologies for no reference. Further, I have no URL to
point to as I read the book. (actual book; no e-something)
Here's something: http://pouzinsociety.org
Like the book, in the Wikipedia article you have to get through
or skip the first part. In the book, that's the first 5 or so
chapters. He just describes why, in his opinion, previous things
have failed and the way he does it turns a lot of folks off.
Likewise, I skipped the last 1-2 chapters. So in the Wikipedia
article skip to the Introduction" section.
A couple more things:
---------------
E2E (end-to-end principle) is not relevant
IPv6 is/was a waste of time
The RINA's fundamental principles are that computer
networking is just Inter-Process Communication or IPC,
and that layering should be done based on scope/scale,
with a single recurring set of protocols, rather than
function, with specialized protocols.
---------------
------------ more from Wikipedia ----------------
The IPC model of RINA concretizes distributed applications in
Distributed Application Facilities or DAFs, as illustrated in
Figure 2. A DAF is composed of two or more Distributed Application
or DAPs, which collaborate to perform a task. These DAPs
communicate using a single application protocol called Common
Distributed Application Protocol or CDAP, which enables two DAPs
to exchange structured data in the form of objects. All of the
DAP's externally visible information is represented by objects and
structured in a Resource Information Base or RIB, which provides a
naming schema and a logical organization to the objects known by
the DAP (for example a naming tree). CDAP allows the DAPs to
perform six remote operations on the peer's objects: create, delete,
read, write, start and stop.
In order to exchange information, DAPs need an underlying facility
that provides communication services to them. This facility is
another DAF whose task is to provide and manage Inter Process
Communication services over a certain scope, and is called a
Distributed IPC Facility or DIF. A DIF can be thought of as a layer,
and enables a DAP to allocate flows to one or more DAPs, by just
providing the names of the targeted DAPs and the characteristics
required for the flow such as bounds on data loss and delay,
in-order delivery of data, reliability, etc.
DIFs, being DAFs, can in turn use other underlying DIFs themselves.
This is the recursion of the RINA.
scott
and restrict scope only for multihoming.
Then, it is true that:
> 1972. Multi-homing not supported by the ARPANET.
which means current specifications do not support multihoming very well.
but, the statement
> The solution was obvious: as in operating systems, a logical address
> space naming the nodes (hosts and routers) was required on top of the
> physical interface address space.
is wrong, because it is enough to let transport layer identify
connections based on a set of physical interface addresses of
all the interfaces, which is what draft-ohta-e2e-multihoming-*
proposes.
That is, he misunderstand restrictions by the current specification
something inevitably required by layering.
> It tosses all this on its head.
If you have some text of RINA denying the E2E argument, quote it
with URLs please.
Masataka Ohta
