🚀 go-pugleaf

In article <9910@megaron.arizona.edu> jms@mis.arizona.edu (Joel M. Snyder) writes:
>In article <Mar.26.16.30.50.1989.18182@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) writes:
>>An IP address does not imply a
>>route.  Given an address and nothing more, one cannot determine a
>>route.  Never-the-less, in order for an Internet to be well connected,
>>routing information about an address must be kept, if nowhere else, at
>>the entrance points to an internet (in the simplest case).  I see
>>things from the DARPA Internet point of view.  How is routing done
>>with ISO IP?

>In IP, an address does imply a route.  For example,  the address of
>a hypothetical CPU is 128.196.3.12.  This is a class B address, so
>the Internet knows that it has to know where 128.196.x.x is, and
>the routing is hierarchically dealt with from there.

I understood the original routing scheme of the Arpa Internet to be
flat-routing between networks.  Later, as a need developed for more
structure within a local administration (in particular how to handle
multiple physical networks within one class B network), subnetting
techniques were introduced kludge to permit multiple physical networks
within one administrative networks.  I guess this is hierarchical in
that routing is handled first among networks and then is handled
within networks.  Still this was not part of the original design, and
subnetting is hardly obligatory. If some network authority wanted to
develop their own non-hierarchical system, nothing stops them which
seems utterly reasonable because I want complete and total control
over how packets are routed within my network and for security I don't
want anyone outside of my network to have any idea how I might be
doing it.

>If I move that CPU to some other campus, the address must change, because
>the address implies a route (note that the NAME doesn't have to
>change; just the address).

Which does not seem horrible but is wrong within the domain system in
that if I take my portable PC (lower_slobovia) and plug it into an MIT
LCS network, its name is lower_slobovia.LCS.MIT.EDU.  When I use my
network at clearpoint its name is
lower_slobovia.RESEARCH.CLEARPOINT.COM while at my home office its
name is lower_slobovia.AOR.COM.  By the way, I expect to have so
many portable PCs within the next year or so that the only real
solution is dynamic assignment of IP addresses, so that I would
expect the addresses of the machines to change everytime I turn
them on.  I really have no idea what Snyder is worrying about here.

>More subtly, given a campus 128.196.x.x, where there are multiple
>routes from that campus to the "world,"  the IP addressing/routing
>schemes require that one manually insert any routing information
>which isn't "fewest hops" in nature, and even then, the autonomous
>system aspect of IP doesn't necessarily allow that minimal information
>to flow from a campus to some other site.  As an example, again,
>given that Arizona is connected to Purdue, Utah, and JVNC, it is
>pretty obvious that Purdue knows not to go through either Utah or
>JVNC to get to Arizona.  However, the next stop from Purdue, let's
>say Indiana (hypothetically), has to manually be taught the Internet
>topology, and can't learn the best way to get from here to there.

So the gateways at Indiana don't talk EGP and they don't listen to
ICMP redirects.  That seems to be their problem not the addressing
scheme of IP.

>In any case, it's the addressing scheme which restricts the
>routing scheme.

Now Snyder seems to be implying that the absense of routing
information and not the implied routing in the IP address is the
problem?

>Some regional networks (like NSFNET) use a scheme where the entire
>topology of the network is learned by routers.  

Now I am really puzzled.  I could be wrong but I thought NSFNET was a
high-speed replacement for the ARPANET in which clusters of RTPCs
connected by 16Mbs token rings acted as packet-switches and replaced
IMPs (PSNs) and where the 56Kbs leased lines were replaced by T1 lines
so that there are issues of routing here between communications subnet
switches but this is orthogonal to internetwork routing and should be
totally transparent to hosts connected to the ARPA Internet of which
NSFNET is one piece.

>						 This is OK as long
>as you have enough memory to keep your entire topology in core, AND
>as long as you're willing to not allow any granularity of routing 
>beyond that which IP addresses give you. 

I thought the PCRT clusters kept topology of interswitch connectivity
in memory and each cluster knew what hosts were directly connected to
it but that they did not necessarily know the whole network topology.

>In both instances, the simplifying assumption which makes the
>Internet work (and it's a miracle that it does) is that IP addresses
>imply hierarchical routing. 

I thought the simplifying assumption was that gateways only
worry about routing between networks.  Since this reduces the
routing problem by several orders of magnitude in difficulty
it is no miracle at all that this works.  Is there a networking
system out there which works better?

>(I reference Paul Tsuchiya's work "Landmark Routing" for an excellent
>solution to this and my own expansion on Paul's work, "Traveler Routing")

>Finally, to answer your question, ISO IP doesn't imply routing; the
>OSI model divides the network layer into a variety of sublayers, and
>routing and IP are completely separate.  The framework for OSI-style
>routing has been created, but the actual protocols and algorithms
>are still a matter for discussion.

I think you are saying that ISO IP addresses don't identify to which
network within a catenet a host is connected.  I can think of some
security reasons for this but lack of identification might actually
create some security holes.  But the bottom line is the IP means
internetwork protocol and some where in the sublayers the ISO IP
address has to be converted to an (network, host id) identifier (i.e.
internetwork address) so all you have really done is interpose yet
another layer of CPU cycle burning software in any network
communications problem.  This seems to be a useless partitioning of
the problem into an internetwork datagram piece and an internetwork
addressing piece. 

>Joel Snyder
>U Arizona MIS Dep't

In any case the ISO CLNP is not obligatory this discussion is all
relatively academic (as well as the discussion of fragmentation).  The
major characteristic of an internetwork protocol is that it must be
obligatory.  ISO IP is not.  UK GOSIP excludes the use of ISO IP so
that if I am at BTR-USA and trying to connect from my machine
(conformant to US GOSIP) to a machine at BTR-UK via OSI, I won't be
able to succeed.  But if both machines implement TCP/IP and my
company has ARPA Internet connectivity I have no problem.

Of course, my company spent less than $1000 per machine for the
TCP/IP implementation while it spent somewhere between $50,000 and
$500,000 per machine for the OSI implementation.  Seems like
a big waste of money.  This is even more distressing because
now state governments as well as the federal are mandating
next-to-useless OSI implementations for new machines.  Well, I pay
for that major give away to companies like Unisys, and I don't
like supporting this sort of welfare.  In a period of economic
retrenchment there are a lot better uses for that federal money
which comes from the US taxpayer.

Anyway, I updated the FTAM section of my document and here it
is if you are interested:

                                B. FTAM is Dangerous

            The  "greater   richness"  of  FTAM,  specified  in  ISO/DIS
            8571/1,2,3,4 (Information Processing Systems -- Open Systems
            Interconnection --  File Transfer,  Access and Management --
            Part 1:  General Introduction, Part 2: The Virtual Filestore
            Definition, Part 3:  The File Service Definition and Part 4:
            The File Protocol Specification) seems to lie in the ability
            to transmit  single records  and in  the ability  to restart
            aborted file transfer sessions through the use of obligatory
            checkpointing (ISO/DIS  8571/1 C.2.1 & C.2.4).  Transmission
            of single  records seems  fairly useless in the general case
            since operating  systems like Unix and DOS do not base their
            file systems  on records  while the  records of file systems
            like  those   of  Primos  and  VMS    have  no  relationship
            whatsoever to one another.

            The  obligatory  ability  to  restart  aborted  simple  file
            transfers,  which   actually  is   available  in   the   FTP
            specification as  an option  for block  or  compressed  file
            transfers, is  more dangerous than helpful.  If the transfer
            were aborted  in an  OSI network, it could have been aborted
            because one  or both  of the  end hosts died or because some
            piece  of  the  network  died.    If  the  network  died,  a
            checkpointed file  transfer can probably be restarted.  If a
            host died  on the  other hand,  it may  have gradually  gone
            insane and  the checkpoints may be useless.  The checkpoints
            could only  be guaranteed  if end  hosts have  special self-
            diagnosing hardware (which is expensive).  In the absence of
            special hardware  and ways of determining exactly why a file
            transfer aborted,  the file  transfer must be restarted from
            the beginning.   Even  with the greater richness of FTAM, it
            is not  clear to me that a file could be transferred by FTAM
            from IBM PC A to a Prime Series 50 to IBM PC B in such a way
            that the  file on PC A and on PC B could be guaranteed to be
            identical because  of the  16-bit word  orientation  of  the
            Prime file system.

            Including single  record or  partial file  transfer  in  the
            remote transfer  utility seems  is a  good  example  of  bad
            partitioning of the problem.  This capability really belongs
            in a  separate network  file system  or  remote  transaction
            processing system.  A network file system should be separate
            from the  remote file  transfer system or remote transaction
            processing because  the  major  issues  in  fault  recovery,
            security, performance,  data  encoding  translation,  object
            location and  object interpretation  are different  in major
            ways for each of the thee cases.  Applying ISO/DIS 8571/1 to
            remote file  service for  a  diskless  workstation  will  be
            interesting to  say  the  least.  Section  D.4  specifically

                                                                        19
            states "[s]ince  the LAN  communications are  not liable  to
            error,  the  recovery  procedures  are  not  needed."    The
            document  actually   considers  the   case  of   the  client
            workstation failing but ignores failures of the file server.
            Since the  virtual filestore  has state,  probably  all  the
            client systems become completely "hosed."

            The goal of the virtual file store itself, as defined by ISO
            in ISO/DIS  8571/2, is  unclear, probably  constricting  and
            probably performance limiting because of the way objects are
            typed within  the virtual  file store.   A  Unix device is a
            file within  the Unix computational model.  Even if a remote
            device file  made sense within the ISO virtual filestore, it
            is totally  unclear what might happen when a process on some
            client machine  writes on  a device file in the virtual file
            store.   If the  process writes  the console device which is
            instantiated in  the remote  file system,  should  the  data
            appear on  the local  console or  on the remote console?  If
            the endpoint  machine is  a diskless  Unix workstation,  the
            data better  appear on  the local  workstation, but  such  a
            necessity raises  serious naming  and location issues, which
            seem intractable  within  the  framework  of  FTAM,  in  the
            mapping of  objects in  the virtual file store to objects in
            real file  stores or  real file  systems.     The  issue  of
            diskless workstations  is simply inadequately handled in the
            FTAM documents,  and really  belongs in  a separate  set  of
            standards.   Unless the  class of  diskless workstations  is
            extremely restricted, a remote file system  without a remote
            paging or  swapping system,  which  are  often  remote  file
            system or remote disk system issues, is fairly useless.

            The main  problem with  the virtual  filestore is that it is
            not a  remote file  system.   In a  genuine resource sharing
            environment, a  Unix machine  should be  able to  serve as a
            remote file  server for  a VMS  machine, and  a Unix machine
            should be  able to  serve as  remote file  server for  a VMS
            machine.   A fairly simple, robust, stateless protocol which
            used a general handle into a data stream would be the proper
            approach,   A VMS  application might  wish  to  access  some
            record in  a file  which appears  in  a  structured  record-
            oriented VMS  file.   The remote  file system  client module
            running on  the VMS  system would  translate  this  into  an
            appropriate request  for data  which the  server on the Unix
            machine would  get from  the unstructured Unix file.  When a
            Unix application wishes to access a data contained in a data
            file actually residing on a VMS server, the Unix application
            would view  this file  as a  sequence of  fixed or  variable
            length records  contained in an apparently unstructured Unix
            file even  though the actual VMS file is a structured record
            oriented  file.     The  Unix  client  code  would  send  an
                                                                        20
            appropriate request,  which the VMS remote file server would
            extract as a record from the VMS file system and transmit as
            a stream  of bytes  to the  client Unix  machine.  With  the
            fairly strong  file typing  employed in the OSI virtual file
            store,  such   client-server  relationships   would  not  be
            possible unless the remote file system were implemented with
            the virtual  filestore as  the virtual  server machine.  But
            such a remote file system architecture does not simplify the
            problem  at   all  because   the  software   must  still  be
            implemented to  make files  from real file systems available
            to the  virtual filestore.  FTAM only adds one more layer of
            performance-killing software complexity.

            The virtual  filestore would  also add a similar superfluous
            software  layer   to  remote  transaction  processing  while
            hindering the  efficient implementation  of data  integrity,
            data  security,   data  access   and  transaction   ordering
            procedures  specific   to  remote   transaction   processing
            problem.   Trying to  lump the remote transaction processing
            system with simple file transfer and network file systems at
            best threatens  the performance  and data  integrity of  the
            distributed system  whether the system is executing a simple
            file transfer,  providing a remote file system or processing
            remote transactions.