huitema@JERRY.INRIA.FR (Christian Huitema) (05/16/89)
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... Lets imagine a scenario of the form: 1- Local net runs OSI > TP4 > CLNP over LLC1 over (Ethernet, FDDi, what else..); 2- Local gateway encapsulate CLNP segments of adequate size > IP, sends them to target gateway; 3- Remote gateway extract CLNP segments, sends them over LLC1 to target machine, which processes CLNP, TP4, and OSI applications.. 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; 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? Christian Huitema
tozz@hpindda.HP.COM (Bob Tausworthe) (05/17/89)
/ 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
hagens@CS.WISC.EDU (05/18/89)
> This is a very valid point. I am a bit surprised that nobody proposed a > ``standard'' way to ferry CLNP segments as IP datagrams. > ... > > 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; > 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? > Christian Huitema Christian, RFC1070 defines much of what you suggested (except parts of #4). However, the intended use of RFC1070 is for experimenting. Our solution to #5 was to use ES-IS (Internet-wide multicast). This clearly does not scale! The IETF-OSI WG is working on a "production" version of 1070 that would include some kind of routing protocol to run between the encapsulation- gateways. Rob Hagens UW Madison Computer Science