From: cmf851@huxley.anu.edu.au (Albert Langer)
Newsgroups: aus.aarnet,comp.protocols.iso
Subject: Re: Proposal: OSI Addressing on AARnet
Followup-To: aus.aarnet
Date: 12 Oct 1992 12:45:30 GMT
Organization: Australian National University
Distribution: world
NNTP-Posting-Host: 150.203.2.12

In article <mrp.718444347@sirius.ucs.adelaide.edu.au> 
mrp@sirius.ucs.adelaide.edu.au (Mark Prior) quotes Nick Andrew and writes:

>>I prefer IP numbers, not to mention domains!
>
>Well you are in for a shock when the new version of IP finally rolls
>out the door.

WILL it finally roll out the door? I only managed to glance through a
megabyte of so of the big-internet archives before giving up but I didn't
see anything that looked promising. Looked to me like the anti-OSI
prejudices were so intense they are going to come up with some sort of
new ersatz IP that still won't scale, or, almost as bad, the US (and 
Australian) GOSIP WAN approach of running CLNP over a WAN. 

GOSIP CLNP WAN works (badly) for medium sized private networks
but just doesn't scale for a large public Internet - as indicated by the
CCITT version of OSI ignoring CLNP completely since they deal with large
public WANs, and the mandatory ISO requirement for TP2 or TP0 over CONS
on any End System that uses a Connection Oriented Transport Service - i.e.
for all currently standardized OSI applications. (The ISO addendum
including TP4 over CLNS did not remove the mandatory requirement to ALSO
implement TP2 or TP0, which requires CONS, whenever implementing TP4 to
claim conformity to OSI transport).

>Comparing it to domains is not valid since that number is hidden by a
>directory service in OSI just like DNS hides it in the IP world.

I'm not sure whether you mean a layer 3 directory service, and whether
you are referring to higher level routing being "hidden" from lower level
Intermediate Systems as well as End Systems, but if so, I agree :-). 

Currently the "connectionless" Internet WAN is typically organized
on a "star topology" which has a single point of failure at every point. More
bandwidth is used by DNS lookups on the Australia-US link than by each of
email and news. In fact one in every 11 packets is DNS traffic (not counting
the month when failure of a single point of failure allowed DNS to take
over the whole link).

Why anyone would call that "connectionless" is beyond me. But the assembled
experts on the big-internet list seem grimly determined to continue ignoring 
the rather obvious fact that routing HAS to be separated from relaying once an 
Internetwork grows beyond a certain size, and therefore a Connection Oriented 
Network Service HAS to be used, so that the path can be setup before relaying 
each packet, and torn down afterwards, since it is physically impossible for 
all the relays to actually be "routers" and know IN ADVANCE, a meaningful 
route to the next hop relay when each packet comes along. (That of course
is the essential distinction between CONS and CLNS. With CONS a "connection"
is established first and then each data packet is handled in that context,
whereas each data packet is supposed to be routed and relayed independently
with no previous context for a CLNS. Consequently there has to be a common
protocol such as CLNP to provide CLNS whereas different protocols can be
used for each hop to provide CONS, so there is no standardized "CONP" -
likewise for standardized routing protocols. Other advantages of CONS such 
as flow control, throughput QOS specification, improved performance etc 
are merely consequences of being able to process each data packet within
a previously established context. 

CLNP is great for replacing bridges with brouters on LANS, but only a bit better
at that than IP, and almost equally bizarre for a big WAN Internetwork.
 
ONE way to separate routing from relaying is to use the initial N-CONNECTreq
packet to lookup a hierarchical network layer directory, such as something
like the ISO SNARE, but between Intermediate Systems in a hierarchy as well
as just between End Systems and Intermediate Systems. Other ways include
forwarding the N-CONNECTreq along all possible routes and evaluating
the N-CONNECTresp and N-DISCONNECTreq packets coming back, including any
redirection information included as user data, to choose the next hop
for a route. Then, AFTER having setup a route, it becomes possible to
relay each subsequent N-DATA packet within negotiated transit delay
paramaters. Pretending to be able to do that for the first packet simply
means abandoning any real attempt at maintaining any particular QOS.

If they don't come up with something plausible soon it looks like the
DNS WILL be the only thing glueing the current Internet together. It
could be adapted to lookup IP addresses from NSAP addresses within
an Internetwork that treats each IP LAN as a single OSI system with
multiple NSAP addresses - thus allowing the individual LANs to continue
using existing IP protocols. Or it could be used with the inactive subset
of CLNP just stripping off the IP headers and replacing them with a single
zero byte, since the NSAP address is uniquely associated with the MAC address. 
Or it could just be used for email, allowing the whole thing to become 
"connectionless" in the sense of "disconnected".

[Translation: Not just AARNET but also the Internet generally could do
with some research funds spent on how to upgrade and extend it and
increase its capacity. It won't happen without making use of the results
of research.]