Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema) (01/16/90)
In your message dated Sat, 13 Jan 90 11:11:22 -0800, you state that: >Forgive me for seeming high-and-mighty, but there's no point in >continuing the flow of misinformation. >... Still, I will dare adding my two bits, and comment on one of your assumptions, i.e. that several different ``TS stacks dont interwork'' and that ``you're not going to carry it in NSAP form''... It is very clear that several implementations have focused on the transport service as ``the ultimate interface'', and that once a reasonable transport service emulation has been provided over technology X, then all OSI application can be used over that technology. And that is a good thing. However, it should be clear that considering the transmission control technologies as ivory towers that will not intercommunicate is definitely not such a good thing. Yourself, among many others, tried to obviate this inconveniency by providing ``transport gateways''. In fact, the matter is obscured by the political decision to describe RFC-1006 as ``an emulation of TP-4 over TCP'', in order to keep the NIST happy.. In fact, a close look at RFC-1006 shows that it provides an emulation of the X.25 network service over TCP, and then stack TP-0 over it. Which is a good thing, for it makes the realisation of gateways between RFC-1006 and TP0 over X.25 much easier. But, lets come to my point. Suppose that the general requirement of the transport service provision over an existing transmission control technology (TCP, SNA, you name it) is to provide an emulation of the CONS and to stack TP-0 over it. Then, the design of gateways between that TS-Stack and others (including X.25) becomes very straightforward: NSAPs are passed end to end, and are used in the intermediate gateways to select a route. The gateways, and only them, will need to know the principle of the coding of the NSAP addresses; the other systems will only use the NSAP for routing, and one could even incorporate an address resolution protocol (CONS ES-IS in OSI lingo) in the ``revised RFC-1006'' in order to make that routing easier. Indeed, we will be left with the "CO/CL mess". But, even here, things are changing, and instead of blaming "the other side of the Atlantic", transparent gateways are designed which do use the NSAP addressing. In short, if we want to perform global OSI networking, we should concentrate: * on the revision of RFC-1006, so that it could at least carry the requested NSAP addresses in the initial exchange. If it could incorporate an ARP, it would be much better. * on the provision of CONS relays between RFC-1006 and X.25 or other CONS subnets. * on the provision of ``transparent'' NSAP based gateways between TP-0 over CONS and TP-4 over CLNS. Apart from that, your lecture was a reasonable statement of the (deplorable) state of the art -).. Christian Huitema
S.Kille@CS.UCL.AC.UK (Steve Kille) (01/18/90)
Nothing like NSAPs to produce a lot of messages! On the choice of Prefix for use of RFC-1006 over Internet TCP/IP. My note proposed TELEX AFI (54) + UCL Telex + 03 . Rob suggests 47 (I assume that this is ICD AFI??). It doesn't matter much which number is chosen. There is no technical reason to change, althogh there may be some emotive ones. A change would not be that big a deal if it was done soon. It would cause MTR and the ISODE crew a fair amount of short term grief, and it would break some directory pilot activities for a bit. I would certainly recommend against changing if it can be avoided. If it will help, I am very happy to delgate the .....03 namespace to an appropriate body. If you'd like it to be more formal, I'm sure that Prof. Kirstein will be happy to write this on UCL headed notepaper to an appropriate Internet person or body. There are a number of reasons why the TELEX (54) namespace makes sense: - My encoding needs quite a bit of space, mainly to make it easy to handle and to proivde sufficienct flexibility. The Telex form gives you a lot of space easily. It might be hard to argue for a large enough chunk of the 47 namespace. - This is a non-(OSI)-standard use of NSAPs. Using a suitably bizarre part of the NSAP-space will emphasise this. It can be easily dropped out at a later stage. - You do not want real NS systems to get confused by this. Separating these "special" addresses as far away from real NS addresses (which I assume is mainly what will be under 47) is likely to promote robustness. This was the orignal aside which I made, and did not explain properly then (apologies). Of course, real NSAPs could use the Telex Namespace, but this is not going to be a common option. I hope that this helps you to sort things out Steve
S.Kille@CS.UCL.AC.UK (Steve Kille) (01/18/90)
Marshall, Can I add my voice to Christian's, in support of adding in the NSAP to a modified version of RFC 1006. This will help the addressing problem significantly when real CONS/CLNS are available. I believe this to be an important hook. Adding in an ARP-like feature seems inappropriate. Steve
S.Kille@CS.UCL.AC.UK (Steve Kille) (01/19/90)
Fine. Lets leave 1006 alone for now. Steve