diff options
Diffstat (limited to 'doc/rfc/rfc928.txt')
| -rw-r--r-- | doc/rfc/rfc928.txt | 1197 |
1 files changed, 1197 insertions, 0 deletions
diff --git a/doc/rfc/rfc928.txt b/doc/rfc/rfc928.txt new file mode 100644 index 0000000..c8ea953 --- /dev/null +++ b/doc/rfc/rfc928.txt @@ -0,0 +1,1197 @@ + + +Network Working Group M. A. Padlipsky +Request for Comments: 928 Mitre Corp. + December 1984 + + INTRODUCTION TO PROPOSED DOD STANDARD H-FP + + +Status Of This Memo + + This RFC suggests a proposed protocol for the ARPA-Internet + community, and requests discussion and suggestions for improvements. + Distribution of this memo is unlimited. + +Important Prefatory Note + + The broad outline of the Host-Front End Protocol introduced here and + described in RFC 929 is the result of the deliberations of a number + of experienced H-FP designers, who sat as a committee of the DoD + Protocol Standards Technical Panel under the author's chairmanship. + The particular protocol to be described is, however, the result of + the deliberations of a small, ad hoc group, who sat as a de facto + subcommittee of the H-FP committee, also under the author's + chairmanship. The protocol, then, follows the consensus of the full + group as to what the new H-FP should "look like," but has not + benefitted from painstaking study by a large number of experienced + H-FP designers and implementers. (It has been looked at before + release as an RFC by several of them, though.) Even if that were not + the case, it would still be the intent of the designers that the + protocol be subjected to multiple test implementations and probable + iteration before being agreed upon as any sort of "standard". + Therefore, the first order of business is to declare that THIS IS A + PROPOSAL, NOT A FINAL STANDARD, and the second order of business is + to request that any readers of these documents who are able to do + test implementations (a) do so and (b) coordinate their efforts with + the author (617-271-2978 or Padlipsky@USC-ISI.ARPA.). + +Historical/Philosophical Context + + Late in May of 1971, the author was presenting a status report on + whether the Multics ARPANET implementation would be ready by the + July 1 deadline declared by the sponsor earlier that month. Some + controversy developed over the fact that the Multics "NCP" (Network + Control Program--actually a blanket term covering the Host-Host and + Host-IMP protocol interpreters) did not queue requests for + connections. As the specification explicitly declared the topic to + be one of implementors' choice, the author attempted to avoid the + argument by asking the interrogator what he was up to these days. + The answer was, "Oh, I'm working on the High-Speed Modular IMP now" + (later the Pluribus IMP). And the proverbial coin dropped: The + author replied, "I've got a great idea. Now that we've got some + space to program in the IMP, why don't we separate out most of the + + +Padlipsky [Page 1] + + + +RFC 928 December 1984 +Introduction to H-FP + + + NCP and do it outboard: the only thing that really matters in the + Host is associating sockets with processes, and if we had common + implementations of all the bit-diddling stuff in the IMPs, we + wouldn't have disputes over the interpretation of the spec and we'd + also save a lot of Host CPU cycles!" + + As far as the author knows, that incident was the beginning of what + came to be called "Network Front-Ends" and, more recently, "Outboard + Processing Environments." (The name change, by the way, was + motivated by a desire to prevent further confusion between NETWORK + Front Ends--always conceived of as distributed processing mechanisms + for the offloading of intercomputer networking protocols from + Hosts--and traditional communications front-ends, which have no + connotation of bearing protocol interpreters invokable by Host-side + programs.) At least, the idea was original to him and he later was a + principal designer and the primary author of the first Host-Front End + Protocol. So, on the one hand, the present document might be marred + for some readers by undertones of parental pride, but on the other + hand, if you like primary sources.... + + The evolution of the outboard processing idea has been dealt with + elsewhere [1]. For present purposes, it should suffice to observe + that some half-a-dozen implementors of "NFE's" of various sorts are + known to the author to have met with success. The topic of why use + an explicit protocol in the first place (as opposed to emulating a + device, or devices, already known to the Host/operating system) + deserves a word or two here, however. ([2] deals with it in more + general terms.) The crucial consideration is that in the general + case you wind up "not doing real networking" if you attach a Host to + a network by known device emulation, where real networking is taken + to mean what has been called "resource sharing" in the ARPANET + literature, and what appears to be dubbed "open system + interconnection" in the ISO literature: Operating systems' built-in + assumptions about known devices--whether terminals, terminal + controllers, or RJE stations--tend to get in the way of the sort of + process-process and eventually procedure-procedure communications + that serve as the basis for applications more interesting than simple + remote login. To those unfamiliar with the outboard processing + approach, the premise that the way to attach is via an explicit + protocol may be difficult to accept, but to those who have done it, + it makes almost perfect sense. + + To those, by the way, who have worked in intercomputer networking + from the perspective of inboard (Host-side) implementations of + protocol suites, the outboard processing idea often seems to lead to + less than optimal results, especially as to maximizing throughput. + And it is difficult to argue that if a given Host were well and truly + + +Padlipsky [Page 2] + + + +RFC 928 December 1984 +Introduction to H-FP + + + fine-tuned to "do networking" the insertion of an extra processor + could somehow lead to better networking. However, for Hosts where + conservation of CPU cycles is an issue, or even where memory is + scarce (i.e., where it's desirable to conserve the resources being + shared), outboarding is clearly the way to go. For that matter, + viewing outboard processing aright (as a form of distributed + processing) it can be argued that even for extremely powerful + "intelligent work stations"/"personal computers" which have the + resources to spare it still makes sense to outboard in order not to + have to do new implementations of entire protocol suites for each new + such system--always assuming, of course, that the Host-Front End + protocol in play is noticeably less complex than the offloaded + protocols. + + None of this is meant to imply that outboard processing is the ONLY + way to do intercomputer networking, of course. It is, however, meant + to suggest that outboard processing can be advantageous in a number + of contexts. Indeed, given the joint advents of microprocessors and + Local Area Networks, a generic bus interface unit which also plays + the role of a NFE (that is, is an Outboard Processing Environment) + even allows for the original intent of "offloading to the IMP" to be + realized, so that a free-standing, possibly fairly expensive NFE need + not be interposed between Host and net. Note, by the way, that + nothing in the OPE approach requires that ALL Hosts employ OPEs. That + is, the only protocols "seen" beyond the Comm Subnet Processor are + the common intercomputer networking protocols (e.g., all DDN IMPs see + and read IP datagrams). H-FP is strictly a matter between a Host and + its OPE. + + It is also important to be aware that, given the advent of several + different suites of protocols in the networking world, it might well + be the case that the only reasonable way to achieve + "interoperability" might well be to use a suitable H-FP (such as the + one to be presented in the companion RFC) and an Outboard Processing + Environment which is capable of parallel invocation of protcol suites + (with the choice of suite for a given connection being dependent, of + course, on the native suite of the desired target Host and/or + application). + + The unquestionable advantages, then, of the approach, based on ten or + more years of experience and analysis, would seem to be as + follows--always recalling the assumption that the work to implement + and execute the H-FP in play is small compared to the full protocol + suite in question: As noted, common implementation of a protocol + suite has the automatic advantage of mutual consistency; further, + particularly in the DOD context, it's far easier to procure common + + + +Padlipsky [Page 3] + + + +RFC 928 December 1984 +Introduction to H-FP + + + implementations of standard protocols than to procure different ones + on a per-Host type basis. Also as noted, if the resources to be + shared are viewed as being the participating Hosts' + + CPU cycles and memories, these resources are conserved by doing as + much as possible of the networking protocols in an OPE rather than in + the mainframe. Another, less evident advantage is that having an OPE + effectively insulates a Host against changes in the + outboarded/offloaded protocols--or even changes of the protocols, + should the nascent international protocol standards ever mature + sufficiently to supplant the in-place DOD standards. (That is, given + an abstract enough interface--in the spirit of the Principle of + Layering--a Host could, for example, go from doing TCP as its + "Host-Host" protocol to, say, ECMA Class 4 as its "Transport" + protocol without taking any particular cognizance of the change, + however unattractive such a change would be to advocates of the + APRANET Reference Model such as the author. See [3] for more on the + implied "Reference Model" issues.) Finally, although a few rather + specialized points could also be adduced, it should be noted that for + network security architectures which are predicated on the ability to + control all means of egress from and ingress to "the net", uniform + use of OPEs is clearly desirable. + + If we can stipulate that an OPE is/can be a good thing, then the + remaining problem is just what the protocol interpreted by a Host and + its OPE ought to be, once it's observed that a standard protocol is + desirable in order to allow for as much commonality as possible among + Host-side interpreters of the protocol. That is, we envision the + evolution of paradigmatic H-FP PIs which can more or less + straightforwardly be integrated with various operating systems, on + the one hand, and the ability simply to transplant an H-FP PI from + one instance of a given operating system to other instances of the + same system, much as is currently being attempted in the DODIIS NFE + program. Again, the major motivation in the DOD context is the + minimizing of procurement problems. + +Technical Context + + As noted, some half-a-dozen Host-Front End protocols have been seen + by the author. Indeed, in December of 1982, a meeting was convened + to allow the developers of those H-FPs to compare their experiences, + with an eye to coming up with a proposal for a DOD standard H-FP; + this paper is a direct result of that meeting. In the current + section, we present the consensus of the meeting as to the broad + outline of the protocol; in the accompanying document, the current + version of the proposed protocol will be presented, as detailed by + the author and Richard Mandell and Joel Lilienkamp (both of SDC). + + +Padlipsky [Page 4] + + + +RFC 928 December 1984 +Introduction to H-FP + + + Note, by the way, that in some sense we should probably have changed + the name from H-FP to H-OPEP (or something), but the habit of saying + "H-FP" seems too deeply engrained, despite the fact that it does seem + worthwhile to stop saying "NFE" and start saying "OPE." (Besides, + H-OPEP looks rather silly.) + + A final preliminary: all the designers and implementors of H-FPs + present at the December meeting concurred that the true test of any + protocol is how well it implements. Therefore, until several + implementations of the "new" protocol have been performed and + assessed, it must be understood that the proposed protocol is + precisely that: a proposal, not a standard. + + Not too surprisingly, the first point on which consensus was reached + is that there are three separable aspects (or "layers") to an H-FP: + At bottom, there must be some physical means for conveying bits from + Host to OPE and from OPE to Host. As it has always been a premise of + outboard processing that the Host's convenience is paramount, just + what this physical layer is can vary: typically, a bit-serial + interface is customary, but parallel/DMA interfaces, if available for + the Host and interfaceable to a given OPE, are fair game. (So would + teleporting the bits be, for that matter.) + + In the middle, there must be a layer to manage the multiplexing of + network "connections" and the control of the flow between Host and + OPE. If we agree to call the lowest layer the Link and the middle + layer the Channel, one thing which must be noted is that between the + two of them, the Link and Channel layers must be responsible for + reliably conveying the bits between Host and OPE. After all, an OPE'd + Host should not be "weaker" than one with an inboard implementation + of a robust Host-Host protocol such as TCP. It should be noted that + any Host which "comes with" a suitable implementation of the X.25 + interface protocol (where the definition of "suitable" is rather too + complex to deal with here) could, given an OPE conditioned to accept + it, quite cheerfully satisfy the requirements of the lower two + layers. This is not to say that X.25 "is" the mechanization of H-FP's + Link and Channel layers, however; merely that it could be used. The + protocol spec itself will detail an alternative, less cumbersome + channel layer for Hosts which don't have or want X.25. + + The top layer of H-FP is the most important: we refer to it as the + Command layer. Here is where the peer H-FP modules in a given Host + and OPE communicate with each other. Indeed, the segregation of JUST + multiplexing and flow control (plus reliability) into the Channel + Layer is done--in addition to making it easier for Hosts that possess + preexisting software/hardware which could be turned to the + purpose--so as to clarify "what the H-FP is": it's the commands and + + +Padlipsky [Page 5] + + + +RFC 928 December 1984 +Introduction to H-FP + + + responses of the Command layer wherewith the Host's processes are + able to manipulate the outboard implementations of the members of a + protocol suite. The use of the phrase "commands and responses" is + rather significant, as it happens. For in the protocol to be proposed + for DOD standardization, unlike all but one of its predecessors, + binary encoded "headers" are not employed; rather, the H-FP commands + are indeed ASCII strings, and the responses (following the practice + of ARPANET FTP) ASCII-encoded numbers. + + There are various reasons for this departure, which initially stemmed + from a desire to have the same NFE be usable for terminal traffic as + well as Host offloading, but the one that seemed to dominate when + consensus was arrived on it as the basis for the new standard is that + it is very much in the original spirit of H-FP. That is, if you want + to "make things as easy as possible for the Host", it makes a great + deal of sense to offload in a fashion that only requires some sort of + scenario or script ("exec-com"/"command file"/"shell command" are + approximations on some systems) in the Host, rather than requiring a + program, possibly of more complexity than we would like. This is not + to say that we envision all--or even most--Hosts will take the + scenario approach to H-FP mechanization, but rather that the command + orientation chosen allows for the possibility. (It would be useful to + recall that the Channel layer does all the necessary + multiplexing/demultiplexing, so that each channel's metaphorical + state machine--at least on the Host side--really has very little to + worry about other than "doing its thing.") + + It should be noted that the proposed protocol provides a mechanism + for offloading "all" protocols. That is, although most "first + generation NFEs" only handled ARPANET Reference Model Layers II and I + (Host-Host and Network Interface--approximately ISO levels 4-1, with + some of L5's functionality included when it comes to service + identifications being handled via Well-Known Sockets in L II), it is + assumed that OPEs will be evolved to handle L III offloading as well + (ISO 5-7). Indeed, it should also be noted that what is being + addressed here is "the protocol", not "the" OPE. More will be said + on this topic below, and in the protocol spec itself, but it is + important to realize from the outset that the H-FP being proposed is + intended to be implementable by any number of OPE suppliers/vendors, + so "an" OPE may or may not choose to implement, say, a given file + transfer protocol, but provided it says so in proper H-FP terms and + does offload some other protocols it's still an OPE in our sense of + the term. (Cf. "Issues" and "Non-Issues", below.) + + + + + + +Padlipsky [Page 6] + + + +RFC 928 December 1984 +Introduction to H-FP + + +Issues + + The following items are either in some sense still open issues or + bear special emphasis: + + Command Approach + + The most striking feature of the new H-FP, especially to those who + have seen older H-FPs, is the decision to employ + character-oriented commands rather than the more conventional + binary-oriented headers at the Command Layer. As noted, the + primary motivation was the report that the approach worked well + when it was employed in an H-FP for the Platform Network called + NAP (Network Access Protocol) [4]. In discussions with NAP's + originator, Gerry Bailey, the author was convinced of the + fundamental reasonableness of the approach, but of course that + doesn't have to convince others. Additional rationales emerged in + discussions with Gary Grossman, the originator of the DCA/DTI + H-FP [5], which is probably the best-known current H-FP and which + furnished the default Channel Layer for the new one: In the first + place, the text approach makes parsing for the ends of + variable-length parameters easier. In the second place, it allows + for the possibility of creating a terminal-supporting OPE in a + very straightforward fashion should any OPE developer elect to do + so. (See below for more on the distinction between OPE developers + and H-FP implementors.) Finally, there's nothing sacred about + binary headers anyway, and just because the text approach is + different doesn't make it "wrong". So, although it's not out of + the question that the new protocol should back off from the text + approach if reviewers and/or implementors come up with compelling + reasons for doing so, the already frequently encountered reaction + of "it feels funny" isn't compelling. (It was, indeed, the + author's own initial reaction.) Besides, "nobody" (not even Gary) + really liked the top layer of the DCA/DTI H-FP. + + X.25 Appropriateness + + Of more concern than how text "feels" is whether X.25 "works". + That is, we understand that many system proprietors would greatly + prefer being able to use "off-the-shelf" software and hardware to + the greatest extent feasible and still be able to do intercomputer + networking according to DOD Standards, which is a major reason why + we decided to take the H-FP commands out of the Channel Layer of + the DCA/DTI H-FP even before we decided to encode them as text. + However, it is by no means clear that any old vendor supplied + "X.25" will automatically be usable as a new H-FP Channel and Link + layer mechanization. As noted, it all depends upon how Host + + +Padlipsky [Page 7] + + + +RFC 928 December 1984 +Introduction to H-FP + + + programs (the Command Layer/H-FP Protocol Interpreter in + particular) are able to invoke X.25 on particular systems. Also, + there might be peculiarities in the handling of some constructs + (the Group and Member fields--or whatever they're called--are a + strong candidate) which could militate against getting JUST + demultiplexing and flow control out of X.25-as-Channel + Link/Layers. For that matter, it's conceivable that on some + systems only one process can "own" the presumed DCE, but there's + no interprocess communication available between it and the + processes that want to use H-FP. What that all amounts to, then, + is that we don't pretend to be sufficiently versed in the vagaries + of vendor-idiosyncratic X.25 implementations to claim more than + that we THINK the new H-FP Command Layer should fit "on top of" + X.25 in a Host such that a suitably crafted OPE could look like a + DCE to the low-level Host software and still be an OPE in our + sense of the term. Finally, some reports on bit-transfer rates + attainable through typical X.25 interfaces give rise to concern as + to whether such a lash-up would be "good" even if it were + feasible. + + DCA/DTI Channel Layer Appropriateness + + The Channel Layer of the DCA/DTI H-FP has been implemented for a + few Host types already, and is being implemented for others (in + particular, as part of the DODIIS NFE project). A delicate + decision is whether to alter the header structure (e.g.--and + perhaps i.e.--to remove the now-superfluous command and response + fields). On the "con" side are the considerations that + implementations DO exist, and that it's well specified. On the + "pro" side are that keeping the header as it is is in some sense + "wasteful" and that somebody's going to have to go over the spec + again anyway, to remove that which no longer applies. (It should + be noted that Gary Grossman was initially tempted to scuttle the + Group and Member trick, but the presence of a similar + dichotomizing in X.25 seems to rule that out.) One of the + interesting issues during the review phase of the new H-FP, then, + will be the decision about which way to go on the Channel Layer + header in its non-X.25 version. (NOBODY considers going X.25 + only, be it noted.) By the time the protocol is finalized, it + will, of course, be made clear in the protocol spec, but I'll + probably leave this in the final version of the Introduction just + for historical interest anyway. + + Syntax + + Another point which probably needs close scrutiny during the + review process is the "syntax" of the command lines. Basically, + + +Padlipsky [Page 8] + + + +RFC 928 December 1984 +Introduction to H-FP + + + we just took our best shot, but without any claims that it's the + best possible way to express things. So comments and/or + alternatives are earnestly solicited on this one. + + L III Offloading + + Contrary to the expectations of some, we are allowing for the + offloading of Process/Applications Layer (ARPANET Reference Model + L III) protocols. Both Bailey and Grossman reported favorably on + the feasibility of this. Two points should be made, however: It's + perfectly fair for a GIVEN OPE implementation not to offload a + given L III protocol, although it would presumably not sell as + well as ones which did. That is, we're not claiming that by + inventing a mechanization of the feature in the spec we levy a + constraint on everybody who implements "the protocol", (Cf. + Fabrication under Non-Issues, below). Just as we were feeling our + way on syntax in general, we're really feeling our way when it + comes to the L III stuff. (I'm not even sure I managed to convey + what I meant for "mediation level" to Joel and Dick.) Again, + suggestions are solicited. + + Security + + During the detailed design pass, we had an intensive discussion + with some of the Blacker design team on the interplay between the + new H-FP and a meant-to-be multilevel-secure OPE such as Blacker. + The conclusion was that by and large "Security" is to be an aspect + of an enhanced H-FP, rather than the standard one. The reasoning + was rather involved, but seems to amount to the following: Hosts + that are NOT MLS (or "Compartmented") have two significant + properties in our context: They're in the vast majority of + present-day systems. They have no legitimate need even to tell + their OPEs what they "think" their current System High or + Dedicated Mode level is; that information should be furnished by + some trusted portion of a network security architecture (e.g., a + security enhanced OPE, or a table in a "secure" comm subnet + processor). + + Thus, even having the optional security label/level field in the + Begin command is in some sense overkill, because we're not sure of + any sensible circumstances in which it would be useful, but we put + it in "just in case". On the other hand, Hosts that ARE + MLS/Compartmented by definition can be permitted to assert what + the level of a given transmission (or perhaps of a given + connection) should be, and their OPEs need to have a mechanism for + learning this. But it is by no means clear that a given Host (or + even a given OPE) will be so structured as to make the H-FP PI, + + +Padlipsky [Page 9] + + + +RFC 928 December 1984 +Introduction to H-FP + + + the Channel PI, and the Link PI ALL trustworthy--as they'd have to + be if the security labeling were part of H-FP. So, we envision + the labeling's being handled by trusted code in both Host and OPE + that will be inserted into the normal processing route at the + appropriate point for the given architecture (presumably "at the + very bottom" of the Host, and "the very top" of the OPE), and that + will place the label in a convenient, known position in the + Host-OPE transmission "chunk" (block/packet/data unit) as the + circumstances dictate. (It's likely--but we wouldn't swear to + it--that a good place would be just before the H-FP command, and + if that's the case then semi-clearly the security enhanced H-FP + PIs would have to "make room" for it in the sense of handing the + Channel Layer a suitably lengthened "chunk".) + + The Host and its OPE should be viewed as a single entity with + regard to labeling requirements in the non-MLS/C case, and either + the OPE will be conditioned to emit the right label or the CSNP + will "know" anyway; in the MLS/C Host and OPE case (and it should + be noted that it's just about impossible to envision a MLS/C Host + which IS outboarded which DOESN'T have a MLS/C OPE) it will depend + on the given security architectures as to whether each "chunk" + needs labeling (i.e., there COULD be trusted H-FP, Channel, and + Link PIs, so that only at channel establishment time does the + label need to be passed), but it seems likely each "chunk" would + need labeling, and we can see how that would happen (as sketched + above). + + This is all, of course, subject to reappraisal when the full-time + Security folks get in the act, but for now, H-FP per se is viewed + as playing no direct role in "Security"--except indirectly, as + noted below under the Symmetric Begins Non-Issue. (In case + anybody's worrying about the case where the OPE is physically + remote from its Host, by the way, that line would have to be + protected anyway, so the Host/OPE-asa-single-unit view should hold + up.) + + How It Implements + + The final issue to take note of is that one of the central + premises of the Outboard Processing approach has always been that + H-FPs can be invented which implement more compactly on the Host + side than the code they're allowing to be offloaded. We certainly + think the new H-FP will fulfill that condition, but we'd certainly + like to hear of any evidence to the contrary. + + + + + +Padlipsky [Page 10] + + + +RFC 928 December 1984 +Introduction to H-FP + + +Non-Issues + + The following items are declared to be non-issues, in the sense that + even though some people have expressed concern over them we believe + that they are either "not part of the protocol" or resolved already + for reasons that were overlooked by those worried about them: + + Fabrication + + Who builds OPEs isn't within our purview, except to the extent of + hoping a few volunteers come forward to do testcase + implementations of what is, at present, only a paper protocol. + However, beyond agreeing that a few points should be marked as + "Notes to Entrepreneurs" in the spec, we didn't attempt to dictate + how an OPE vendor would behave, beyond the explicit and implicit + dictates of the protocol per se. For example, if a given OPE + doesn't offload SMTP, it jolly well ought to respond with the + appropriate "Function not implemented" code, and if a vendor + claims to accept X.25 for Channel and Link disagreements over what + X.25 "is" are the province of the vendor and the customer, not of + the H-FP spec. As OPE'S are supposed to be offloading COMMON + protocols in a COMMON fashion, a given OPE should be able to + interoperate with another Host irrespective of whether that Host + even has an OPE, much less whose OPE it is if it's there. Thus, + for example, even though you'd expect to find OPEs that "come + with" their own LANs as a fairly frequent product, we don't appeal + to the notion in the conceptual model; nor do we attempt to + dictate "chunk" sizes at the Channel level. A protocol spec isn't + an implementation spec. + + Symmetric Begins + + For almost as long as there have been H-FPs, there has been + disagreement over whether only the Host can begin a connection or + if the OPE can also take the initiative. I am delighted to be + able to resolve this one finally: It turns out there IS a + compelling reason for insisting that THE PROTOCOL include + provision for OPE --> Host Begins, so it's "in" the protocol--but + any Host that doesn't need to deal with them doesn't have to (just + "spell" the "Function not implemented" response code correctly). + + (In case anybody cares, the compelling reason is that if you HAD + an MLS OPE which happened to use a security kernel and a process + per level, you'd need IT to be listening for incoming connection + requests "from the net" rather than having the Host tell it to do + so, for various esoteric reasons--but in order to cater to the + possibility, we want the function in the protocol from the + + +Padlipsky [Page 11] + + + +RFC 928 December 1984 +Introduction to H-FP + + + beginning, on the grounds that we can envision SOME other uses for + it even in non-MLS environments [unlike the security labeling + trick discussed above, which only seems to make sense for MLS + Hosts/OPEs--that is, it doesn't burden the Host to reject a Begin + every once in a while but it would to go around labeling "chunks" + unnecessarily all the time].) + + Routing + + Concern has been voiced over the issue of what provisions the + protocol should make to deal with the situation where a Host, + probably for traffic/load reasons, has multiple OPEs and the + question arises of which OPE to use/route to. I claim this is a + non-issue at the protocol level. If the Host-side H-FP PI gets a + "No resources" response to a Begin, it can go off to another OPE + if it wants to. "Not our department". The conceptual model is + that of a Host and AN OPE--which "ought to" be expandable to carry + more load at some level. If you want multiple links for some + reason, the simplest solution would seem to be to have multiple + Channel Layers as well, but the whole thing just gets too iffy to + have anything sensible to prescribe in the protocol. In other + words, extending the concept to deal with discrete multiple OPEs + is either a Fabrication sort of thing, or a Notes to Host-side + Implementors sort of thing on a per specific OPE basis. + + Operator Interface + + It's probably implicit in the foregoing, but it might be worth + saying explicitly that the operator interface to a specific OPE is + a non-issue in terms of the protocol, beyond the provision we're + made for "Shutdown coming" responses as a reflection of a probable + operator interface action we imagine most operator interfaces + would provide. (It might also be worth noting that if your Host + does "color changes", your OPE had better have a trustworthy way + of being told to change the label it plops on all IP datagrams it + emits, but that comes under the heading of an Aside to Specialized + Implementors.) + + + + + + + + + + + + +Padlipsky [Page 12] + + + +RFC 928 December 1984 +Introduction to H-FP + + +Fine Points + + There are a couple of known "loose ends" which are exceedingly fine + points in some sense that do bear separate mention: + + The Allocate Event + + While mentally testing to see if the new H-FP would indeed + off-load TCP, we came up against an interesting question: Viewing + H-FP as "just an interface at a distance" to a TCP PI, what about + the Allocate "Interface Event" in the TCP spec? As far as I'm + concerned, this could be classed as a non-issue, because I submit + that the spec is wrong in declaring that there is such a thing as + a MANDATORY Interface Event whereby the user of a TCP PI lets the + PI know how much data it can take. Granted, you might find such a + thing in most implementations, but what if you were in a virtual + memory environment with segment sharing (or a distributed + supervisor) and you wanted to avoid copies, so all that passed at + the interface to the PI (or even at the interface from the PI) was + a pointer? That is, the "DOD version" of the TCP spec has fallen + into the trap of assuming things about the execution environment + that it shouldn't have. + + One moral of this is that + + AN INTERFACE TO AN INTERPRETER OF A PROTOCOL IS N*O*T "THE + PROTOCOL". + + Another moral is that the interface to the Host-side H-FP PI is + hard to say much about, but is where the equivalent functionality + will be found if you've offloaded TCP. That is, it's reasonable + to let the user "tell" the outboard PI at Begin time if big or + small buffers are expected to be in play "net-ward" as part of the + protocol, but the outboard PI is expected to deliver bits to the + Host as they come unless throttled by the Channel Layer, or by + some to-be-invented other discipline to force the OPE to buffer. + (For present purposes, we envision letting the Channel Layer + handle it, but nifty mechanizations of encouraging the OPE to + "make like a buffer" would be at least looked at.) As a + Fabrication issue, it is the case that "equity" has to be dealt + with with regard to the use of the OPE's resources (especially + buffers) across H-FP connections/channels, but that's a different + issue anyway, touched upon in the final fine point. + + + + + + +Padlipsky [Page 13] + + + +RFC 928 December 1984 +Introduction to H-FP + + + Precedence + + Clearly, the existence of a notion of Precedence in DOD protocols + has to get reflected in the outboard PI's implementations. Just + what, if any, role it has in the H-FP, per se, is, however, by no + means clear. That is, if the Host doesn't take Begins from the + OPE and is "full up" on the number of Server Telnet connections + it's willing to handle, what should happen if a high precedence + SYN comes in on the Telnet Well-Known Socket (in present day + terms)? Probably the OPE should arbitrarily close a low + precedence connection to make room for the new one, and signal the + Host, but even that assumes the Host will always hurry to be + prepared to do a new passive Begin. Perhaps we've stumbled across + still another argument in favor of "Symmetric Begins".... At any + rate, Precedence does need further study--although it shouldn't + deter us from making "the rest" of the protocol work while we're + waiting for inspiration on how to handle Precedence too. + +A Note on Host Integration + + The most important thing about Hosts in any intercomputer network is + that they furnish the resources to be shared. The most significant + obstacle to sharing those resources, however, is the fact that almost + invariably they were designed under the assumption that the Host was + a fully autonomous entity. That is, few operating systems currently + deployed "expect" to be members of a heterogeneous community of + operating systems. In many cases, this built-in insularity goes so + far as to have applications programs cognizant of the particular type + of terminal from which they will be invoked. + + Intercomputer networking protocols attempt to resolve the problems of + heterogeneity by virtue of presenting appropriate common intermediate + representations (or "virtualizations") of the constructs and concepts + necessary to do resource sharing. A Host-Host protocol such as TCP + "is" a virtual interprocess communication mechanism; a virtual + terminal protocol such as Telnet obviously is a mechanism for + defining and dealing with virtual terminals; FTP offers common + representations of files; and so on. It cannot be stressed strongly + enough, though, that this entire approach to intercomputer networking + is predicated on the assumption that the modules which interpret the + protocols (PIs, as we'll refer to them often) will be PROPERLY + integrated into the various participating operating systems. Even in + the presence of powerful OPEs, wherein the bulk of the work of the + various PIs is performed outboard of the Host, the inboard "hooks" + which serve to interface the outboard PIs to the native system must + not only be present, they must be "right". The argument parallels + the analysis of the flexible vs. rigid front-ending attachment + + +Padlipsky [Page 14] + + + +RFC 928 December 1984 +Introduction to H-FP + + + strategy issue of [1]; to borrow an example, if you attempt to + integrate FTP by "looking like" a native terminal user and the + operator forces a message to all terminals, you've got an undetected + pollution of your data stream. So the key issue in attaching Hosts to + networks is not what sort of hardware is required or what sort of + protocol is interpreted by the Host and the OPE (or comm subnet + processor, for that matter), but how the PIs (full or partial) are + made to interrelate with the pre-existing environment. + + It would be well beyond the scope of this document to attempt even to + sketch (much less specify) how to integrate H-FP PIs into each type + of operating system which will be found in the DoD. An example, + though, should be of use and interest. Therefore, because it is the + implementation with which we are most intimately familiar, even + though it's been several years, we propose to sketch the Multics + operating system integration of the original ARPANET Network Control + Program (NCP)--which is functionally equivalent to an H-FP PI for + offloading ARM L II and L I--and Telnet. (A few comments will also + be made about FTP.) Note, by the way, that the sketch is for a + "full-blown" H-FP; that is, shortcuts along the lines of the + scenario-driven approach mentioned above are not dealt with here. + + One of the particularly interesting features of Multics is the fact + that each process possesses an extremely large "segmented virtual + memory". That is, memory references other than to the segment at + hand (which can itself be up to 256K 36-bit words long) indirect + through a descriptor segment, which is in principle "just another + segment", by segment number and offset within the segment, so that a + single process--or "scheduling and access control entity"--can + contain rather impressive amounts of code and data. Given that the + code is "pure procedure" (or "re-entrant"), a "distributed + supervisor" approach is natural; each process, then, appears to have + in its address space a copy of each procedure segment (with + system-wide and process-specific data segments handled + appropriately). Without going too far afield, the distributed + supervisor approach allows interrupts to be processed by whichever + process happens to be running at a given time, although, of course, + interprocess communication may well be a consequence of processing a + particular interrupt. + + A few other necessary background points: A distinguished process, + called the Answering Service, exists, originally to field interrupts + from terminals and in general to create processes after + authenticating them. Other shared resources such as line printers + are also managed by distinguished processes, generically known as + "Daemons". Device driver code, as is customary on many operating + systems, resides at least in part in the supervisor (or hard core + + +Padlipsky [Page 15] + + + +RFC 928 December 1984 +Introduction to H-FP + + + operating system). Finally (for our purposes, at least), within a + process all interfaces are by closed subroutine calls and all I/O is + done by generic function calls on symbolically named streams; also, + all system commands (and, of course, user written programs which need + to) use the streams "user_input" and "user_output" for the obvious + purposes. (At normal process creation time, both user I/O streams + are "attached" to the user's terminal, but either or both can be + attached to any other I/O system interface module instead--including + to one which reads and writes files, which is handy for consoleless + processes.) + + All that almost assuredly doesn't do justice to Multics, but equally + likely is more than most readers of this document want to know, so + let's hope it's enough to make the following integration sketch + comprehensible. (There will be some conscious omissions in the + sketch, and doubtless some unconscious ones, but if memory serves, no + known lies have been included.) + + Recalling that NCP is functionally equivalent to H-FP, let's start + with it. In the first place, the device driver for the 1822 spec + hardware interface resides in the supervisor. (For most systems, the + PI for H-FP's link protocol probably would too.) In Multics, + interrupt time processing can only be performed by supervisor + segments, so in the interests of efficiency, both the IMP-Host (1822 + software) Protocol PI and the multiplexing/demultiplexing aspects of + the Host-Host Protocol PI also reside in the supervisor. (An H-FP PI + would probably also have its multiplexing/demultiplexing there; that + is, that portion of the Channel Layer code which mediates access to + the OPE and/or decides what process a given message is to be sent to + might well be in the supervisor for efficiency reasons. It is not, + however, a hard and fast rule that it would be so. The system's + native interprocess communications mechanism's characteristics might + allow all the Channel Layer to reside outside of the supervisor.) + + Even with a very large virtual memory, though, there are + administrative biases against putting too much in the supervisor, so + "everything else" lives outside the supervisor. In fact, there are + two places where the rest of the Host-Host Protocol is interpreted on + Multics, although it is not necessarily the case that an H-FP PI + would follow the same partitioning even on Multics, much less on some + other operating system. However, with NCP, because there is a + distinguished "control link" over which Host-Host commands are sent + in the NCP's Host-Host protocol, the Multics IMP-Host Protocol PI + relegates such traffic to a Network Daemon process, which naturally + is a key element in the architecture. (Things would be more + efficient, though, if there weren't a separate Daemon, because other + processes then have to get involved with interprocess communication + + +Padlipsky [Page 16] + + + +RFC 928 December 1984 +Introduction to H-FP + + + to it; H-FP PI designers take note.) To avoid traversing the Daemon + for all traffic, though, normal reads and writes (i.e., noncontrol + link traffic) are done by the appropriate user process. By virtue of + the distributed supervisor approach, then, there is a supervisor call + interface to "the NCP" available to procedures (programs) within user + processes. (The Daemon process uses the same interface, but by virtue + of its ID has the ability to exercise certain privileged primitives + as well.) + + If a native process (perhaps one meaning to do "User Telnet", but not + limited to that) wanted to use the network, it would call the open + primitive of "the NCP", do reads and writes, and so on. An + interesting point has to do with just how this interface works: The + reads are inherently asynchronous; that is, you don't know just when + the data from the net are going to be available. In Multics, there's + an "event" mechanism that's used in the NCP interface that allows the + calling process to decide whether or not it will go blocked waiting + for input when it reads the net (it might want to stay active in + order to keep outputting, but need to be prepared for input as well), + so asynchrony can be dealt with. In the version of Unix (tm) on + which an early NFE was based, however, native I/O was always + synchronous; so in order to deal with both input from the terminal + and input from the net, that system's User Telnet had to consist of + two processes (which is not very efficient of system resources). + Similar considerations might apply to other operating systems + integrating H-FP; native I/O and interprocess communication + disciplines have to be taken into account in designing. (Nor can one + simply posit a brand new approach for "the network", because Telnet + will prove to rely even more heavily on native mode assumptions.) + + The other aspect of NCP integration which we should at least touch + on--especially because process-level protocols make no sense without + it--is how "Well-Known Sockets" (WKSs) work. In broad terms, on + Multics the Network Daemon initially "owns" all sockets. For + Well-Known Sockets, where a particular process-level protocol will be + in effect after a successful connection to a given WKS, code is added + to the Answering Service to call upon the NCP at system + initialization time to be the process "listening" on the WKSs. (This + is a consequence of the fact that the Answering Service is/was the + only Multics process which can create processes; strategies on other + systems would differ according to their native process creation + disciplines.) How to get the "right kind of process" will be + sketched in the discussions of the process level protocols, but the + significant notion for now is that typically SOME sort of prior + arrangement would be done by any networked Host to associate the + right kind of process with a WKS. + + + +Padlipsky [Page 17] + + + +RFC 928 December 1984 +Introduction to H-FP + + + Now, we don't expect that the foregoing will enable even the world's + greatest system jock to go out and design the integration of an H-FP + PI for a system that had never been networked (in the ARPANET style + of networking) before. But we propose to stop there and turn to some + comments on process level protocols, for two reasons: In the first + place, it would take us much too far afield to go into significantly + greater detail; and in the second place, because of the functional + equivalence of H-FP and NCP combined with the number of operating + systems which have integrated NCP and, for that matter, TCP/IP, which + are also functionally equivalent to H-FP (used for offloading L II + and L I), models are available in the ARPANET community and concerned + H-FP PI implementors can follow them. + + Turning to Telnet integration, and returning to Multics as an + example, we note that "User Telnet" is straightforward. "All you + need" (for small values of "all") from an INBOARD User Telnet is a + command that gives the user some sort of interface, converts between + the native Multics character set and terminal discipline and the + Network Virtual Terminal equivalents (and as Multics is very generic + when it comes to I/O, that's not hard), and writes and reads "the + net" (more accurately, calls upon the Host-Host protocol PI--or upon + the H-FP PI to get at the H-HP--appropriately). (One point that's + not obvious: make the Well-Known Socket "on the other side" a + parameter, defaulting to the Telnet WKS, because you'll want to use + the same command to get at other process-level protocols.) If + there's an OPE in play which offloads User Telnet, however, things + can be even simpler: the inboard command just reads and writes the + terminal and lets the OUTBOARD User Telnet PI handle the conversion + to and from the Virtual Terminal form (presumably, from and to the + desired local form). + + When it comes to the incoming ("Server") aspects of Telnet, life can + get complicated on some systems for an inboard implementation. + However, fortunately for our purposes, + + Multics' native mechanisms lend themselves readily to integration; an + awareness of the inboard issues will be useful even if in response to + a connection attempt on the Telnet WKS, the (Server) Host is + obligated to associate the connection (the actual logic is somewhat + more complex under the ARPANET Host-Host Protocol, which employs + paired simplex connections) with a process that is prepared to + translate between Telnet and native mode representations and + otherwise "look like" a local user process--that is, in particular + the connection becomes an I/O source/sink to the native command + processor on time-sharing systems. As indicated, process creation is + taken care of in Multics by having the Answering Service process + listen on the WKS. Because the Answering Service is in some sense + + +Padlipsky [Page 18] + + + +RFC 928 December 1984 +Introduction to H-FP + + + just another Multics process, it too does user I/O through the normal + system mechanisms. So while for local terminals the user I/O streams + are attached through a module called "ttydim" (where "dim" stands for + "device interface module"), NVTs are attached through a functionally + equivalent and identically invoked module called "nttydim" (the + Answering Service knows which DIM to use based on the symbolic + designator of the "line" on which it received the interrupt, as it + happens). + + [The notion of "attaching" the streams bears a bit more explanation: + Attach is a primitive of the Multics generic I/O mechanism which + associates a stream name and a particular DIM (or I/O system + interface module in later terminology); the other I/O primitives + (read, write, etc.) are invoked with the stream name as a parameter + and an I/O "switch" causes the entry point corresponding to the + primitive to be invoked in whichever DIM the stream is currently + attached to. So a Server Telnet process starts life attached + through nttydim to a particular network connection, while a local + process starts life attached through ttydim to a particular physical + line, and both processes proceed indistinguishably (viewed from + outside the I/O switch, anyway).] + + The pre-existing orderliness that makes things easy on Multics does + not, unfortunately, appear in all operating systems. Indeed, + delicate choices occasionally have to be made as to WHICH native + terminal to map to on systems that don't do generic I/O in native + mode, and it is likely that for some systems the particular mapping + to bring into play in Server Telnet might be determined by the + particular application program invoked. This issue can become very + touchy when the application "expects" a "data entry terminal", say. + The Server Telnet for such a system would naturally attempt to + negotiate the "DET" option with the corresponding User Telnet. But + the user might be at a physical terminal that isn't a member of the + DET class, so that User Telnet must either refuse to negotiate the + option or--and we would recommend this alternative strongly, as it + seems to be within the "spirit" of the protocol--offer some sort of + simulation, however crude, of the behavior of a DET. Also, + something sensible has to be done on systems where there is no clear + analog of the command processor expected to be managing the Server + process. (Say, when a "menu" of applications is always displayed on + an available terminal in native mode.) + + A final Telnet integration issue (although other points could be + noted, we're not pretending to be exhaustive and this should be + enough to "give the flavor"): The Telnet Interrupt Process generic + function calls for particularly careful integration. Here, the + intent of the function is to virtualize what is called the "quit + + +Padlipsky [Page 19] + + + +RFC 928 December 1984 +Introduction to H-FP + + + button" on some systems. That is, the user wants the system to + interrupt his process (which may, for example, be in a loop) and get + back to the command processor (or "the system" itself). On native + character-at-a-time systems, the native mechanism is usually the + entering of a particular "control character"; on native + line-at-a-time systems, the native mechanism is usually the striking + of the "ATTN" or Interrupt button or the "Break" key (sometimes more + than once, to distinguish it from a communication to the executing + program). But the native mechanisms typically involve interrupt time + code, and Server Telnet typically wouldn't be executing at that + level, so the solution (omitting the intricacies of the interaction + with the NCP or the H-FP PI, which also get into the act) would be to + make use of--in the Multics case--a pre-existing INTRAprocess signal, + or to add such a mechanism (unless the architecture chosen has a + Server Telnet Daemon of some sort, in which case an INTERprocess + signal would be needed). + + The extension of the foregoing to an outboard Server Telnet may not + be obvious, but we won't expend a great deal of time on it here. + Even if "the protocol" is being handled in an OPE, the Host-side + software must be able to associate an H-FP connection with the + command language interpreter of a user process and to respond + appropriately to an H-FP Signal command if it arrives, and the OPE + must know not only the desired character set but also the local + equivalents of Erase and Kill, at the minimum. + + We'll skip FTP integration, on the grounds that this note is already + too lengthy, except to mention that in the OUTBOARD case it's still + going to be necessary to convey the name of the appropriate file and + directory to/from some appropriate Host-side code. (Similar problems + must be dealt with for outboard handling of "mail" if it's not part + of FTP.) + + One other "integration" issue, which has been hinted at earlier and + about which not much can be said beyond some general guidelines: The + "top edge" of a Host-side H-FP protocol interpreter (i.e., the Host + user program interface, for + + Hosts that are "doing real networking" rather than just using the OPE + to get at User Telnet and/or FTP and to offer Server Telnet and/or + FTP [and maybe "mail"], presumably in the "scenario-driven" fashion + sketched earlier) MUST BE APPROPRIATE TO THE HOST. In other words, + on Multics, where "everything" is closed subroutines, there would + presumably be a closed subroutine interface with event channels for + reads, pointers to buffers, and all that sort of thing, but on some + other style of operating system, the interface to the H-FP PI might + turn out to be "all" interprocess communication, or to "look like" a + + +Padlipsky [Page 20] + + + +RFC 928 December 1984 +Introduction to H-FP + + + device of some special class, or "all" system + calls/JSYSs/EOTs/Whatevers. We can't be much more specific, but we'd + be remiss to convey any impression that H-FP is a "free lunch". As + noted, an H-FP PI requires the same kind of integration as a generic + NCP--it's just smaller, and serves as insulation against changes (in + the offloaded protocols in general, or in the proximate comm subnet + in particular). + +References + + (References [1]-[3] will be available in M. A. Padlipsky's "The + Elements of Networking Style", Prentice Hall, 1985.) + + [1] Padlipsky, M. A., "The Host-Front End Protocol Approach", MTR + 3996, Vol. III, MITRE Corp., 1980. + + [2] Padlipsky, M. A., "The Elements of Networking Style", M81-41, + MITRE Corp., 1981. + + [3] Padlipsky, M. A., "A Perspective on the ARPANET Reference Model", + M82-47, MITRE Corp., 1982. + + [4] Bailey, G., "Network Access Protocol", S-216,718, National + Security Agency Central Security Service, 1982. + + [5] Day, J. D., G. R. Grossman, and R. H. Howe, "WWMCCS Host to Front + End Protocol", 78012.C-INFE.14, Digital Technology Incorporated, + 1979. + + + + + + + + + + + + + + + + + + + + + +Padlipsky [Page 21] + |