beach@DDNUVAX.AF.MIL (darrel beach) (07/16/90)
Thanks to everyone who responded to my last inquiry on GOSIP. I'm still not very knowledgeable about the OSI suite. I have a couple more simple (I hope) questions. The first one has to do with X.25. Is it possible or practical to run both TCP/IP and the GOSIP suite over a single X.25 interface into a network?? and ditto for ethernets?? I suppose ether is easy relative to X.25. I'm most familiar with the milnet (standard) brand of TCP/IP over X.25, where CC is the first byte of call user data in call request packets, and where datagrams are sent as complete packet sequences, etc. It would seem that in order to support BOTH suites over a single X.25 interface, then it would be necessary ti parse which protocol is being used, IP or ISO8473, after the PDU is received. That doesn't seem too practical. Would a host now have to maintain a virtual circuit table that includes info on what kinds of PDUs can be sent on that vc (IP or 8473). This assumes the X.121 addresses for a dual protocol hosts is the same regardless of which suite is being called. In the case of Milnet, does anybody know how to address OSI suite hosts? Right now it looks like I just build a table of X.121 addresses. Will there ever be an algorithmic derivation to get the X.121 addresses?? Seems to be a knotty little topic, but maybe its easier than it seems. Darrel Beach
malis@BBN.COM (Andy Malis) (07/17/90)
Darrel, > Thanks to everyone who responded to my last inquiry on GOSIP. I'm > still not very knowledgeable about the OSI suite. I have a couple more > simple (I hope) questions. I think I can help. > The first one has to do with X.25. Is it possible or practical to > run both TCP/IP and the GOSIP suite over a single X.25 interface into a > network?? and ditto for ethernets?? I suppose ether is easy relative > to X.25. X.25 is actually easy, at least on the DDN. I can't speak for ether. > I'm most familiar with the milnet (standard) brand of TCP/IP > over X.25, where CC is the first byte of call user data in call request > packets, and where datagrams are sent as complete packet sequences, > etc. It would seem that in order to support BOTH suites over a single > X.25 interface, then it would be necessary to parse which protocol is > being used, IP or ISO8473, after the PDU is received. That doesn't > seem too practical. You're right, that's not the best way to do it. If you check RFC 1060, p. 48 (X.25 type numbers), you'll see that ISO IP has its own protocol ID (first byte of CUD in Call Request packets), CD. So, to use ISO-IP, you just open an X.25 VC to another consenting host using the ISO IP protocol ID. You can even run IP and ISO-IP in parallel between two hosts, over separate VCs of course. I have the impression that on the Milnet, ISO-IP usually runs over Basic X.25, rather than Standard X.25, since there is no need to interoperate with AHIP (1822) hosts, but either should work as long as the two hosts agree. > Would a host now have to maintain a virtual > circuit table that includes info on what kinds of PDUs can be sent on > that vc (IP or 8473). This assumes the X.121 addresses for a > dual protocol hosts is the same regardless of which suite is being > called. Yes, you should keep a VC table that lists the X.121 address on the other end of the VC, and the protocol being used on the VC. But you really have to do that anyway. Yes, on the DDN (Milnet), at least, the X.121 address is independent of the protocol, since the PSNs don't care what protocol you're running above X.25; they just need the address to get the data to the right place. The physical address is the same. > In the case of Milnet, does anybody know how to address OSI suite > hosts? Right now it looks like I just build a table of X.121 > addresses. Will there ever be an algorithmic derivation to get the > X.121 addresses?? Seems to be a knotty little topic, but maybe its > easier than it seems. If I understand your question correctly, I think the answer lies in RFC 1069, which defines ISO-IP addresses for use in the Internet. Figure 3, on p. 7, shows the regular IP address residing in octets 16-19 of the ISO-IP address. Once you have the regular IP address, you can use the regular algorithmic derivation to get the Milnet X.121 address. Andy Malis BBN Communications
barns@GATEWAY.MITRE.ORG (07/18/90)
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.