--- mohta@necom830.hpcl.titech.ac.jp wrote: From: Masataka Ohta <mohta@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