genovese@LANCE.TIS.LLNL.GOV (Tony Genovese) (04/22/89)
I have been told that the DDN has been working on the development of prototype OSI IP routers. These routers would allow the coexistence of OSI and DOD IP packets. Does anyone know about the status of this work and possible dates this service would be available. Thanks Tony Lawrence Livermore Natnl Lab genovese@tis.llnl.gov
kmont@hpindda.HP.COM (Kevin Montgomery) (04/27/89)
/ hpindda:comp.protocols.iso / genovese@LANCE.TIS.LLNL.GOV (Tony Genovese) / 3:05 pm Apr 21, 1989 / > development of prototype OSI IP routers. These routers > would allow the coexistence of OSI and DOD IP packets. also, would someone explain the parsing? Do ISO IP packets have protocol IDs larger than 64 to avoid colliding with ARPA IP packets? (ISO IP has the protocol ID in the first octet, whereas ARPA IP uses the first nybble- if ISO IP had a protocol ID field less than 64, it would look like an old version ARPA IP packet with confused length and checksums). Are the checksums and length fields parsed in a "i'll try to parse it ARPA and see if it works" strategy? kevin BTW- this was just the topic of one of my questions on a final I just turned in yesterday, so I'm interested!
barns@GATEWAY.MITRE.ORG (Bill Barns) (04/28/89)
Disambiguation of ISO CLNP ("ISO IP") and DOD IP is done using next lower
layer information. In the DDN backbones this would specifically mean
the Call User Data field of the X.25 Call Request. For IP, the first
octet is agreed to be set to hex CC. For ISO CLNP the dust has not yet
settled in the DDN world, because there was a sort of interim decision at
one point to use hex CD, but since then the ISO standards have specified
hex 81 for this use. I tend to think DDN will eventually officially
adopt 81 because that would fit in with the general trend of policy
nowadays. The CC and CD values are taken from the "bilateral agreement"
range specified in X.224, and thus there is no guarantee in principle
that different subscribers won't assign the same values to different
protocols. So the use of CC for DOD IP is really an agreement among
some subscribers rather than a recognized CCITT/ISO/etc. assigned value.
The DDN also has a notion of Basic and Standard service. Basic is like
commercial X.25 and is specified by DOD policy to be used for OSI
services in DDN. Standard is really a somewhat special mode with
defined semantics for interoperation with AHIP (1822) interfaced
hosts. (Among other things, the X.25 CUD protocol identification is
mapped to an AHIP "link number" via a table.) DOD IP on DDN is run
using Standard service. The distinction between the DDN-private "Type
of Service" selection facility and the Call User Data protocol
designation I mentioned above is that the Standard Service facility is
considered a signal from a subscriber to the network, whereas the Call
User Data is a signal from a subscriber to another subscriber. That's
why I said that you disambiguate based on the CUD, *NOT* on the Type of
Service facility. Implementations running DOD IP on generic X.25
networks such as public data networks will use the CC CUD, but not the
DDN TOS facility.
For other types of network technology the details of protocol selection
vary, but the same general idea holds; there are Ethernet types, IEEE
802.x SAPs (or are they SNAPs), and so forth, and distinct values are
used to distinguish the next higher layer as IP, CLNP, ARP, ES-IS, or
whatever.
Bill Barns / MITRE-Washington / barns@gateway.mitre.orghagens@CS.WISC.EDU (04/28/89)
> also, would someone explain the parsing? Do ISO IP > packets have protocol IDs larger than 64 to avoid > colliding with ARPA IP packets? (ISO IP has the > protocol ID in the first octet, whereas ARPA IP > uses the first nybble- if ISO IP had a protocol ID > field less than 64, it would look like an old version > ARPA IP packet with confused length and checksums). > Are the checksums and length fields parsed in a "i'll > try to parse it ARPA and see if it works" strategy? ISO 8473 is 10000001b I don't have my ESIS spec handy to see what it uses. rob hagens
dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) (04/28/89)
Sanity check, for me, in case I am missing something: Should the issue of colliding Protocol ID values be a non-issue, given that the two address spaces of id fields already are separated? That is, the processing software already knows that it has OSI vs. TCP environments, so it can consult different tables. Yes? Dave
barns@GATEWAY.MITRE.ORG (Bill Barns) (04/28/89)
My highly esteemed senior colleague Paul Tsuchiya points out that I improperly painted with too broad a brush in the last sentence of my previous reply when I said: > [...] distinct values are used to distinguish the next higher layer > as IP, CLNP, ARP, ES-IS, or whatever. I SHOULD have said "IP, ARP, OSI, or whatever." The difference between the two is small but quite significant. You disambiguate OSI network layer things from non-OSI network layer things at the lower layer or fraction of a layer (although you may be able to fake it for now from the first octet). You disambiguate between various OSI network layer things such as CLNP and ES-IS within the OSI network layer, using the protocol identification there. To be completely general, it is necessary to play both of these games correctly. Bill Barns / MITRE-Washington / barns@gateway.mitre.org
kmont%hpinddm@HP-SDE.SDE.HP.COM (Kevin Montgomery) (04/29/89)
> Should the issue of colliding Protocol ID values be a non-issue, given > that the two address spaces of id fields already are separated? Yes, it looks like I didn't explain the conditions I was imposing on the problem very well. My point was that you couldn't build a single network layer (with only one NSAP/IP address) to handle both types (ISO and ARPA) transparently to the upper layers (either ISO or TCP). If you have the same network address for both types (ISO or ARPA) and you receive a packet and must determine what type of packet it is, then comes the problem of colliding values of the ARPA version bits and ISO protocol ID. (the problem is similar to if the 802.3/ethernet length and type fields weren't well chosen to not conflict) Looks like I was unfortunately thinking in the context of the problem my final had posed, instead of the conditions implied by the basenote... kevin Ps: under those conditions, I'd think you'd assume it to be an ARPA packet, check what should be the length field with the length (or similarly use the checksum) and if it succeeds, assume an ARPA packet, else it's to be parsed in the ISO context.
kre@cs.mu.oz.au (Robert Elz) (04/30/89)
In article <8904282330.AA29812@hpinddm.HP.COM>, kmont%hpinddm@HP-SDE.SDE.HP.COM (Kevin Montgomery) writes: > > My point was that you couldn't build a single > network layer (with only one NSAP/IP address) to handle both types > (ISO and ARPA) transparently to the upper layers (either ISO or TCP). But why would one want to? One of the standard requirements of any lower level protocol is that it provide protocol differentiation for higher layer protocols layered upon it. That's used all the time. Consider how you would differentiate TCP UDP ICMP (etc) if you weren't allowed to look at the IP header (that is, if there was none). Those protocols use a protocol IS in the IP header, IP (and ISO IP, etc) use protocol ID provided in the next lower level (ethernet, X.25, whatever). 1822 is going to be a problem, but that's on the way out isn't it? kre
kmont@hpindda.HP.COM (Kevin Montgomery) (05/02/89)
/ hpindda:comp.protocols.iso / kre@cs.mu.oz.au (Robert Elz) / 12:49 pm Apr 29, 1989 / > But why would one want to? One of the standard requirements of any > lower level protocol is that it provide protocol differentiation for > higher layer protocols layered upon it. That's used all the time. because it was the question posed on an exam. And yes, everyone is true that the lower layer(s) should handle muxing such things. (gee, and I had thought this notesgroup was pretty dead!) -k