oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) (11/14/87)
Caveat: Since this is idle chatter (see Subject:) the words martian, bogon, fuzzball, and playpen will not appear in the body of this message. My office-mate just received a colorful poster from CMC comparing a seven-layer DoD Internet reference model to the seven-layer ISORM. I've attatched a little chart comparing those two RMs to the old four-layer ARM [1] for the idly curious. The most glaring oddity (aside from typos and a cute phone number) is the depiction of EGP, GGP and HMP as Transport layer protocols. When I expressed my surprise at this to my office-mate he wanted to know where they did belong (magic-marker in hand). My instinctive answer was that EGP and GGP belonged in the Internetwork layer and that HMP belonged in Massachusetts. Since I'm just a hanger-on in this field, I was wondering to which layer the protocol police would assign EGP and GGP (and their descendants). I would also like to know if the aforementioned ARM has ever been supplanted. Mike 1. While displaying an affinity for M. Padlipsky's naming scheme (RFC871), the four-layer model to which I refer is the one described by B. Leiner, et. al. in "The DARPA Internet Protocol Suite". -------------------------------------------------------- ISORM CMCRM ARM -------------------------------------------------------- Application Application Application -------------------------------- Presentation Utility Session -------------------------------------------------------- Transport Transport Service -------------------------------------------------------- Internetwork Internetwork ------------------------ Network Network Network -------------------------------- Data Link Data Link -------------------------------- Physical Physical --------------------------------------------------------
craig@NNSC.NSF.NET (Craig Partridge) (11/18/87)
Mike,
I'd say HMP belonged at the transport layer. It can be reasonably
neatly dropped into a binary bsd kernel as a transport protocol, and
it has the usual transport functions (transport user addressing, sequence
numbers, etc).
As for the four level ARM -- I recently argued to someone that we're
approaching five levels:
Application
[Presentation]
Transport
Internetwork
Network
The argument being that while we have no standard Presentation layer,
we are certainly using presentation schemes (XDR, Courier, ASN.1, multimedia
formats, etc.)
CraigLAWS@rsre.mod.UK.UUCP (11/19/87)
Mike, I view EGP, GGP and HMP as Management protocols - for which await the Management Addendum etc to the OSI model now nearing draft standard status. The OSI model deals with issues for host-to-host open interworking. 10 years ago network providers were seen to be large public utilities that would resolve their internetworking problems in their private club (=CCITT). The world and technology has moved on, other (many) network providers are a reality. Hence the OSI model must now enbrace the concepts of management in a more public way. Your diagram might mislead the reader into thinking that internetworking is not an issue in ISORM. The network service is the Global Network Service and contains all conforming interconnected ISORM subnets. I do not consider it a sensible question to ask which layer a specific management protocol is in. Rather it stands off to one side as an application (maybe using the full stack of protocols for some part of its job - access to a directory service?) while supporting a layer in providing its service. ISORM may be applied recursively, direct or indirect. In my own work I have used the X25 VC service as a point-to-point link to connect an IP gateway to a host. The usage as an on-demand point-to-point link has considerable economic and time savings when that usage is infrequent. John
CERF@A.ISI.EDU.UUCP (11/19/87)
The inter-gateway routing algorithms really do sit above the Internet Layer and thus occupy the same space as the Transport Layer - though their function is not specifically transport - that is one reason that I have always been a little uncomfortable with the ISO model with its apparently rigid specification of functionality at each layer. Vint
hinden@PARK-STREET.BBN.COM.UUCP (11/20/87)
Mike, I enjoyed you reference to HMP being in the "Massachusetts" layer. It might be more accurate to say that it is in the Massachusetts "stack" :-). I do think it is correct that is should be shown as a transport layer protocol. EGP, GGP, and other similar internet protocols provide services normally thought of as in the transport [, presentation ?] and application layers. The output of these protocols are used to provide routing data for the internet layer. I don't think that this puts them in the internet layer. Bob
haverty@CCV.BBN.COM.UUCP (11/20/87)
To throw mny two cents in... I think HMP isn't "in the stack" at all, in the sense that it is NOT part of a user data communications activity. HMP is an application top level protocol, between an entity at one end, i.e., the monitoring/management operation, and an entity at the other end, i.e., the piece of code down within some computer somewhere that is watching the activity within that computer and interacting with the management site. IN other words, the participants in HMP are just like any other network users such as FTP or a data query and retrieval system; it just happens to be the case that their activity is associated with the operational management of a communications system. Consider for example if an HMP-like protocol were used to monitor the CPU-load and disk-activity of a distributed collection of Unix systems, i.e., like a constantly running remote "dpy" or "ps". In this case it's pretty clear that the protocol between the players is an application in itself; HMP differs only in that it is looking at the operation of components of a data communications system. Jack PS to Dave Mills -- I do "read the mail" on the list all the time, just a little slow in diving in.
LAWS@rsre.mod.UK.UUCP (11/20/87)
Vint, I have a different view about the ISO model. Its apparent rigid specification of functionality is only on issues that were seen to be needed to have open systems - any vendor host to any vendor host via any network provider. That said there is in fact enough protocol choice in the layers that communities of interest are selecting 'protocol stacks' to limit the number of protocols required in a single host. When networks were seen by the standards makers as being just the public utility of CCITT there was no need to make ISO standards for how to build or manage the network. CCITT would do that. It is now accepted that other network providers will exist in great number (well at least in the UK and US). Hence public standards must be stated for the management of this internet. Note: the assumption is still that a single vendor will provide the subnet and hence we do not require public standards for that internal issue. I agree its probably the case that my view is not the common one stated by ISO experts. But look at the selling problem they had. If you and I are to have choice in our vendors and still communicate then standards are required. The scale on which this has/had to be done is very large relative to run-of-the-mill standards. (By-the-by I happen to think the OSI work has been done in double quick time; checkout the timescale for standards on slings and hooks.) Just as in politics, large market, complex issues, limited time = keep the message simple. Now there are two sorts of OSI experts - those who really are and often have dirty hands and scars from past experience, and those who have read the 'books' from their armchair. The first may cut corners to put the message across in a few minutes but know its more complex. The second only know what is in the 'books'. My experience of standards committees UK BSI and ISO is that most members working on OSI are the first. And just so that there is no mis-understanding between us I do see you as being dead centre (center - I'm bilingual) in the first. (That goes for Mike Padlipsky as well - who if on form is composing a refutation of all I've said.) (To all you other readers - this makes a change to reading how the Internet is being RIPped apart.) Does the US State Dept read this list? Will my A-2 VISA be revoked? John
radia@XX.LCS.MIT.EDU (Radia Perlman) (11/20/87)
The Network Layer in ISO already has lots of sublayers, with catchy names like "Subnetwork Independent Convergence Protocol". With hierarchical routing, there's really a Network Layer sublayer dealing with each level of hierarchy. When you (according to ARPA terminology, I think) interconnect networks into an internetwork, I'd say you're just forming another layer of hierarchy on your network. That extra layer does involve adding a protocol layer onto what used to be your Network Layer. But it certainly doesn't go into the Transport Layer. It just makes your Network Layer fatter (makes a Network Layer that used to have k sublayers now have k+1 sublayers.) In general I agree that trying to take the ISO Reference Model too seriously leads to nonproductive metaphysical discussions, but I don't think hierarchical routing at the ISO Network layer breaks the model. Radia -------
LAWS@rsre.mod.UK.UUCP (11/21/87)
---- Start of forwarded message.
To: haverty%com.bbn.ccv@NSS
Cc: "Michael J. O'Connor" <oconnor%com.scc.sccgate@NSS>,haverty%com.bbn.ccv@NSSRobert Hinden <hinden%com.bbn.park-street@NSS>
tcp-ip%arpa.sri-nic@NSS,,
From: John Laws (on UK.MOD.RSRE) <LAWS@RSRE>
Date: Fri, 20 Nov 87 17:04
Message-Id: <20 NOV 1987 17:04:24 LAWS@RSRE>
Subject: Re: Idle chatter about reference models
Jack,
It must be clear from my previous msgs that you and I are as one on this.
I defer to your clearer statement of where HMP is.
John
---- End of forwarded message.leiner@riacs.EDU (11/24/87)
Vint, I thought ISO viewed the management protocols (including gateway routing algorithms) as kind of a blob sitting off to the side of the "stack". Did I get it wrong (again)? Barry
CERF@A.ISI.EDU (11/24/87)
Barry, ISO does put the management protocols off to the side with comb-like projections into the various layers - rather like DECNET in that regard. The gateway routing protocols all showed up just above IP in the DoD Internet. At other layers, there was network management, too, but not integrated into a common architecture. There were network level management systems (e.g. ARPANET NOC), Internet management systems (INOC, HMP - host monitoring protocol, GGP/IGP,EGP, etc.). It still isn't entirely clear to me how integrated you can get and still deal with separation of administrative control, etc. Vint
gross@GATEWAY.MITRE.ORG (Phill Gross) (11/24/87)
Vint, Couldn't GGP and EGP be viewed as application (or management or somesuch) protocols that just happen to have transport functionality built into them? Using such a view in Mike's diagram, GGP/EGP might be vertical rectangles that spanned several of the corresponding layers in the ISO model. My own favorite is to view them as management protocols of the IP layer (that happen to provide their own transport). After all, their purpose is to update an IP MIB (that's ISOese for routing table). Phill
tcp-ip-RELAY@SRI-NIC.ARPA ("tcp-ip-RELAY%SRI-NIC.ARPA") (11/24/87)
Vint, Couldn't GGP and EGP be viewed as application (or management or somesuch) protocols that just happen to have transport functionality built into them? Using such a view in Mike's diagram, GGP/EGP might be vertical rectangles that spanned several of the corresponding layers in the ISO model. My own favorite is to view them as management protocols of the IP layer (that happen to provide their own transport). After all, their purpose is to update an IP MIB (that's ISOese for routing table). Phill
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (11/24/87)
Sorry to have kept you waiting; I have been off form as it happens, and off to the Left Coast to boot. Rather than succumb to the temptation of trying to see how many epicycles the ISORM has these days (though I must confess I had been convinced at one point in time that the party line was that each layer could/did have a management sublayer--but never found out if that also applied to each sublayer, so wasn't sure if L3 was four or six epicycles deep), let's go back to the initiating question. As I recall, it was something like where things like GGP, EGP, and HMP went in the layering. Although I have a great deal of sympathy for those who didn't bite and in essence placed such things orthogonal to the layering, I would like to observe that there's an alternative for those who find that view unsatisfying: If you believe that the layers are Applications/Process, Host-Host, and Network (Interface)--i.e., the old simple as I, II, III ARM I've always espoused--then the answer ought to be easy to derive for any of the three (or other, like protocols). If they have to do with doing things in common for the users' processes to get the bits to go from Host to Host, then they're L II is one approach. If they're clearly not part of the interface to the proximate comm subnet processor and also fairly clearly not directly germane to the Applications/Process Layer, then they're L II is the other approach. (Note to the original question- raiser: you're of course welcome to use my Form, but it works better if you use my Content too.) (Note to John Laws: as you well know, my main problem with the ISORMites is that they seem to me to be attempting to substitute Form for Content almost all the time.) Hope that's not too characteristically cryptic; if it is, I'll cop a plea based on an imminent cold on top of the jetlag. cheers, map -------
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (11/24/87)
Ooops. More off form than I'd realized [/realised]: Belatedly occurred to me that the Layer, Layer, Who's Got the Layer context is a good one for remembering that even if the ISORMites still think you've got to traverse every layer every time, I never did (and they might not any more, if one thinks things like "MAP" [which, of course, should be "MAPS" to begin with, since it's a Suite, not just A protocol] are ISORMitic, since it blithely skips a layer or two on its way). So I'd refine my answer to the original question to include something like "They sure seem to me to be operating at L II WHEN THEY'RE OPERATING." That might somehow subsume the notion that a few people had that they're not really "in" the "stack"--or perhaps subvert it, if not subsume it. (And I guess it's also worth pointing out that is assumes HMP, which I haven't looked at, doesn't muddy the waters and operate over TCP connections, which would almost make it have to be L III by my insistently non-rigorous definitions.) fuzzy cheers, map p.s. So as not to generate a new Glossary call, for the benefit of those who haven't been around long enough, "ISORM" = ISO Reference Model; ISORMite = follower of the ISORM who I feel is of dubious worth (as opp. to ISORMist, which is one I feel to be sound in other respects but wrong about the RM issue). (The reason why I don't use "OSI" is that I feel it begs the question; i.e., they may say they're doing Open System Interconnection in their name, but are they in their RM ... or their standard protocols? Besides, I like the sound of ISORM.) te: 2ybo