🚀 go-pugleaf

/ hpindda:comp.protocols.iso / huitema@JERRY.INRIA.FR (Christian Huitema) / 12:47 am  May 16, 1989 /
Dave,

>You cite three situations.  The first has OSI, down to CLNP, running in
>an IP network.  You put in a TSB to allow CLNP to run over OSI Transport
>and then have it translated to run over TCP.  This sounds strange, to say
>the least.  Running CLNP encapsulated over IP, directly, where CLNP views
>IP as a link-level protocol, is far cleaner.

>This is a very valid point. I am a bit surprised that nobody proposed a
>``standard'' way to ferry CLNP segments as IP datagrams. I know that
>there is a big strategic plan to make all the NSFNET a ``dual
>protocol'' network; however, it may take some time to fulfill it...

There is an RFC proposal, RFC 1070. However, it is only experimental
and has a few problems. The largest problem is that it attempts to
view IP as a broadcast subnetwork rather than a general topology subnetwork.
This leads to some non-nice code to simulate multi-casting.

It also allows CLNP to run over IP or UDP.


>It is clean and transparent from an OSI point of view; several gateways
>may be used in parallel to the same local net; routing is strictly
>based on NSAP addresses, and not on some mysterious transport address
>rewriting; flow control and retransmissions are performed end to end..
>All these are straightforward advantages over the ``transport gateways''.

>Then, why not? For it is even easier to set up a datagram router than a
>transport gateway -- much less CPU is needed! Also, the spec is quite
>easy to write -- would not need much more than a single page; we only
>need to agree on:

>1- The particular datagram protocol to be used, i.e. either IP or UDP;
>2- If CLNP is run directly over IP, the ``protocol id'' for CLNP;
>3- If CLNP is run over UDP, a ``standard port'' for CLNP;

The above 3 points they have already.

>4- Some miscellaneous details on how much to decrement the TTL, and the
>maximum size of the CLNP segments;
>5- If we want to move that to a grand scale, an ARP protocol for the
>projection of NSAPs to IP subaddresses.

>What do we wait to have all that written dow in some RFC?

I would hope that they are taking another look at RFC 1070 and trying
to make it "production quality".  In order to do this, though a few 
problems must be solved:

1) RFC1070 presently supports only a subclass of CLNP addresses
   (i.e. those with AFI=47, IDI=6) and therefore may only be used to
   access systems which reside on the Internet. The NSAP-to-IP address
   resolution procedures (item 5) needs to be fleshed out some more.
   The multi-cast option used in 1070 seems insufficient.

2) RFC1070 treats IP as a broadcast subnetwork. Multi-casting and static
   routing tables are the predominate way to handle NSAP-to-IP address
   resolution. IP should be considered a general topology subnetwork,
   and as such, not use multi-casting as the prescribed method for 
   address resolution. 

3) use of ES-IS protocol and IS-IS protocol over IP will need to be
   standardized. Since the IETF is moving towards adopting the ANSI
   Intra-domain routing protocol, this shoud be extended to include
   IP subnetworks (the draft I read seems as if it could support an
   IP subnetwork, but it should be formally verified).

4) supporting both IP and UDP will need to be investigated more
   completely. In RFC1070 static tables determine whether to use
   IP or UDP. In a real implementation it would be up the the 
   CLNP route() function. This is because CLNP would actually view
   these as two separate subnetwork types. So a method would have to
   be in place for the user to determine not only that IP should be
   used for the first/next hop, but whether IP or UDP/IP should be 
   used: yet more complexity for the routing layers.

Care should be taken in adopting CLNP/IP. The addressing and routing
(i.e. those parts of the OSI internet layer which are not well defined)
portions of the ISO internet are shaky at best. Adding an SNDCP for IP
will not automatically get you ISO and TCP/IP co-existance. 

		  bob tausworthe
		  tozz@hpda.hp.com