mark@cbosgd.UUCP (Mark Horton) (03/27/84)
I just read the March 1984 issue of Systems and Software. They have 50 pages or so about different networking suites, with a LOT of information about the ISO suite. From what I can tell, the ISO suite has come a LONG way in the last year. It's starting to look pretty good! I haven't seen any discussion of this stuff on net.lan. Is it a well kept secret or is my ear to the wrong ground? Is this info largely accurate? (I notice some glaring errors elsewhere in the magazine, which makes me wonder. But then the press is never noted for getting the technical details right. For example, check out the story about how UNIX on an IBM PC has to be slow because there is no memory management hardware.) Apparently the major remaining problem with the ISO suite is that the standards are still incomplete. But most of them are at least to the draft standard stage, and there are claims of some kludged implementations to be demoed soon. The major delay is that there won't be a virtual terminal protocol draft proposal until Feb 1985. (I wonder what's wrong with ANSI X3.64, which seems to be equivalent to what they have in mind.) They have recently added a "connectionless mode" to the ISO model (which, in my interpretation, already covered it), and now apparently DOD is seriously considering adopting it as their standard. (I don't know where this leaves TCP/IP, probably on an equal footing, although we all know that with networks, standardization is everything.) One section puzzled me: "The addendum to the referenc model rules out any cross mode operation above the transport level. This means that the three layers above a transport connectionless service must also be connectionless while the three layers above a connection-oriented service must be connection-oriented." Huh? Aside from keeping those datagram weirdos off in their own corner :-), what possible use is this restriction? How can it be enforced? There is an obvious advantage to building virtual circuits ala TCP on top of datagrams ala IP - you only have to solve the internet problems once for IP. Is the above paragraph correct? Can someone motivate it? Expecially since the end of the same page suggests that one way to internetwork is to "build a connection in the network layer (such as an X.25 virtual circuit) on top of a connectionless network." Another point of interest: "The most important of the differences is the addressing scheme for nodes. IS specifies a much larger address space that can accomodate many networks and network nodes. ISO also ues a heirarchical addressing structure that allows for incorporation of existig networks. The structure is easy to use and administer from within any subnetwork. An ISO heirarchical address begins with an internationally standardized segment that is broken into two domains. One is controlled by CCITT. The secod is controlled by ISO. These address segments are further broken down into zones such as country codes. When the breakdown reaches the finer levels of detail, where one authority administrates one or a collection of ntworks, then that authority determines the addressing structure within that subdomain. ISO has pointed out the addressing inadequacies in the Internet protocol to the DOD. The DOD is taking steps to modify Internet along the lins ISO suggested. This brings the IP even closer to ISO." Fascinating. Does someone have details of this address structure? Size, fields, etc? I remember a 14 decimal digit plan for international host numbering, but that didn't divide the world between ISO and CCITT (which is a pretty strange division.) More discussion, opinions, flames, and more detailed information about the ISO suite are invited. Can reasonable implementations exist? Even in a PC? (TCP/IP can be done on an IBM PC or less.) Is there a mailing list on the ARPANET somewhere talking about this? (Is INFO-TCP/IP still dead?)
mccallum@opus.UUCP (03/28/84)
The ISO suite is getting close. NBS is specifying the US version and is
developing a test bed for the protocols. The transport layer is in draft
stage and several implementations exist. NBS has one that is available
as part of the transport testbed. It was done at BBN for NBS and is written
in C. The transport is going to be demoed at this years NCC by a number
of vendors. This demo is being organized by NBS. There will actually be
two booths - a CSMA/CD (IEEE 802.3) and a token bus (IEEE 802.4). The
vendors also include at least one European vendor. (a version of the
transport protocol was published as an ARPA RFC [RFC892]).
The NBS transport testbed is up and running. An article about it appears in
the March 84 issue of Data Communications. A fairly complete set of tests
exists. I've seen the testbed in operation.
The ISO session layer is in draft stage as well as the IP protocol. A
followup demo of with the internet will probably be done if the NCC
demo goes well. The NBS CBMS (Computer Based Messaging System) protocol
is now a FIPS (see FIPS pub 98 or RFC841)
I personally don't see any need for the restriction about keeping datagram
service separate from connection based service, but since it took a long
time to even get datagrams (unit data in NBS) it is probably
political. There is a lot of resistance to datagrams in general.
The 802 standards specify fully connected virtual circuits at the link
level. Connectionless use is still available.
Addressing should be in draft proposal stage this month.
I'm not sure which addressing proposal is being adopted, but there have been
several proposed. At one point NBS had an IP proposal with 64 bit addresses
(16 network id, 48 host id). ECMA has proposed variable length addresses.
Given the comment about hierarchical addresses, I would assume that addresses
have a variable length with each part interpreted by the domain it references.
The ISO protocols have a lot of options. A minimal subset should be fairly
small. The NBS testbed runs on a PDP-11/70. The code is in C but was
generated by a protocol compiler that doesn't do any optimizations of the
finite state machine. I think a subset could be implemented that would run
on a PC class machine. There will most likely be a number of controllers
that implement the protocol directly.
Doug McCallum
NBI, Inc.
{ucbvax, allegra, hao}!nbires!mccallumhd@kvvax4.UUCP (H}kon Dahle) (03/29/84)
<> Agree, where are the articles discussing protocol architecture, specifications, services and implementations? There is a lot of stuff on things like Ethernet cable lengths etc., but what about the remaing six layers of ISO OSI reference model? Now : >There is an obvious advantage to building virtual circuits ala TCP >on top of datagrams ala IP - you only have to solve the internet >problems once for IP. Is the above paragraph correct? As far as I can see it is. The TCP belongs to layer four, and is not subject to the restrictions for the layers 5-7. The same counts for X.25 on top of a datagram network service, it is an enhancement of the network service only. Sorry to say, this obvious advantage is not so obvious for everybody, not in Europe and inside ISO anyway. Let us only hope more people realise this is the way to go. As I see it, the future is computers interconnected via LANs, using the datagram type of network service. Haakon Dahle {decvax,philabs}!mcvax!kvport!kvvax4!hd A/S Kongsberg Vaapenfabrikk, Dept CTG4, PO Box 25, N3601 Kongsberg, Norway Tel. + 47-3-738284 Tlx. 71491 vaapn n
julian@deepthot.UUCP (Julian Davies) (04/02/84)
References to ISO protocol suite: There is a whole series of survey papers in the Dec 1983 Proceedings of the IEEE. Mostly invited papers. They give varying amounts of detail. A (the?) draft ISO Transport Protocol was reprinted in full in ACM Computer Communication Review, vol 12, Nos. 3,4 (July/Oct 82). "Computer Communications" has sometimes printed articles in this topic area; I haven't checked just recently though (must do so!). "Computer Networks" carries news reports etc for CCITT and IFIP activities, but these do not usually get down to the bit level from what I've seen. Anyone know of other public sources? CCITT and ISO recommendations etc are available from various official sources, but often only after considerable delays. Julian Davies