Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!GATEWAY.MITRE.ORG!barns From: barns@GATEWAY.MITRE.ORG Newsgroups: comp.protocols.tcp-ip Subject: Re: GOSIP and X.25 Message-ID: <9007181353.AA25863@gateway.mitre.org> Date: 18 Jul 90 13:53:11 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 88 You probably saw Darrel B's message - What do you think of this set of answers? /Bill ------------------------------------------------------------------------- Guess I'll take a shot at this set of questions. 1. Is it possible or practical to run both TCP/IP and GOSIP protocols over a single X.25 interface? Over a single Ethernet interface? It is possible and practical if the implementor/vendor goes about it properly. This is very simple to do once one has gotten a firm grip on the idea that it ought to be done. There has been at least one case of a vendor creating TCP/IP and OSI products that discombobulate each other's X.25 interface, but I'm told that they know better now. Separate virtual calls/circuits should be used for IP and OSI-CLNS PDUs. In the (normal) case of switched virtual calls, the called end distinguishes calls on the basis of the protocol identifier as described by CCITT X.244 and ISO TR 9577. The OSI Network layer protocols have distinct protocol identifiers embedded in the PDUs (first octet) and further break-out of protocols within the family of CLNS protocols is supposed to be done on the basis of those protocol identifiers. So, if for example the traffic between points A and B consists of (DOD) IP, (OSI) CLNP, and (OSI) ES-IS, there should be one or more distinct VCs carrying DOD IP, and one or more other VCs carrying CLNP and ES-IS. Yes, CLNP and ES-IS can be mixed on a single VC, according to standards. There is an issue with this relating to military encryption gear which I'll discuss separately. If there were also OSI CONS communications going on, these would use one or more VCs of their own also. The Ethernet situation is convoluted to describe because of the variants of link frame formats ("Ethernet" vs "802.3") but the principle is the same. For full interoperation, both frame formats must be recognized, following which the protocol identification can be found in the right places. Since the VCs are "typed" to a higher-layer protocol (or family of them), it isn't necessary to parse the PDUs to tell DOD IP from OSI. The OSI implementation has to do the right thing about parsing the NPDU and processing it as CLNP, ES-IS, or whatever. Yes, a host using X.25 has to have some kind of VC data structure with upper-layer context information. This was needed anyway for a valid IP-over-X.25 implementation; it had to keep track of which VCs were connected to which destinations, and it was supposed to also keep track of the precedence level, and match up traffic accordingly. Adding one more matching criterion (protocol family) isn't a big deal in principle. Re military E3: There is a problem with ES-IS in an MLS environment because it doesn't carry a label. Therefore it isn't considered legitimate to put it on a "multilevel VC" to coin a phrase. Therefore the multiplexing rules in an MLS device must be different. Therefore the MLS crypto box has to know which set of rules you are playing by at a given moment. Therefore it is necessary to have a different protocol ID for the two cases if a single crypto box is to handle both kinds of attached device. After considerable discussion, it was concluded that the standard protocol ID for OSI CLNS should be used for the case where the normal OSI CLNS rules apply, and a different one to signal the case where non-labeled PDUs won't be passed. Hex 81=Normal, Hex CD=MLS. Phase I BFE supports neither, Phase II will support CD, Phase III will support both. (All BFEs support DOD IP using Hex CC.) I suspect there are still some issues to be sorted out with MLS routing in general. 2. MILNET addressing for OSI hosts There are really two questions here - NSAP addresses and NSAP/SNPA mapping. I don't think there has been a public pronouncement on NSAP address assignment but the general drift of the most recent discussions I know of was essentially a straight GOSIP Version 2 addressing situation. Regarding mapping, GOSIP requires that you be able to configure static routes based on left subsets of NSAPs. ES-IS is required to be available in the implementation, so you can presumably find or set up some IS with the right information and use that as a routing server for some set of ES's. OSI routing protocols are still not in concrete, but DP 10589 is probably a fairly safe bet for intra-domain routing. 3. Will there be an algorithmic derivation for X.121 addresses? This is subnetwork dependent. I don't think there is any expectation that MILNET will ever be based on that type of scheme for OSI purposes (unlike the IP case). I believe that you should plan on using OSI routing protocols to the extent available, and static mappings of left subsets of NSAPs otherwise.