As per Relevance of the word september, we have this rfc below:
RFC 875 September 1982
M82-51
Gateways, Architectures, and
M.A.
THE MITRE
Bedford, Massachusetts
The growth of autonomous intercomputer networks has led to
desire on the part of their respective proprietors to "gateway
from one to the other. Unfortunately, however, the
and shortcomings of gateways which must translate or map
differing protocol suites are not widely understood.
protocol sets have such severe functionality mismatches
proper T/MG's cannot be generated for them; all attempts to
heterogeneous suites are subject to numerous problems,
the introduction of "singularity points" on logical
which would otherwise be able to enjoy the advantages
communications subnetwork alternate routing, loss
functionality, difficulty of Flow Control resolution, higher
than non-translating/mapping Gateways, and the necessity
re-creating T/MG's when a given suite changes. The
of a protocol-compatible internet is also touched upon, as is
psychology of those soi-disant architects who posit T/MG's
i
Gateways, Architectures, and
M. A.
In our collective zeal to remain (or become) abreast of
State of the Art, we sometimes fall into one or the other (
both) of a couple of pitfalls. Only one of these pitfalls
particularly well-known: "Buzzwords" -- and even here
knowing the name doesn't necessarily effect a
solution. The other deserves more attention:
familiarity with The Relevant Literature
The key is the notion of what's really relevant. Often
it's the Oral Tradition that matters; published papers, in
attempts to seem scholarly, offer the wrong levels of
or, because of the backgrounds of their authors, are
ill-written as to fail to communicate well. Sometimes, however
that which is truly relevant turns out to be unfindable by
conventional literature searcher because it isn't "in" the
of search
I wandered into an instructive case in point recently,
it took me over an hour to convince a neophyte to the
of intercomputer networking (who is quite highly regarded in
least one other area of computer science, and is by no means
dummy) that a particular Local Area Network architecture
which casually appealed to the notion of "gatewaying" to three
four other networks it didn't have protocols in common with was
Very Bad Thing. "Gateways" is, of course, another one of
bloody buzzwords, and in some contexts it might have been
just to so label it. But this was a conversation with a
professional who'd recently been reading up on networks and
wanted really to understand what was so terrible
So I started by appealing to the Oral Tradition,
out that in the ARPA internetworking research community (
which we probably got the term "Gateway" in the first place --
and from which we certainly get the proof of concept
internets) it had been explicitly decided that it would be
hard to deal with connecting autonomous networks whose
sets differed "above" the level
Host-to-Communications-Subnetwork-Processor protocol. That is
the kind of Gateway we know how to build -- and, indeed,
one might call a Gateway -- attaches to two (or more)
subnets as if it were a Host on each, by
interpreting their respective H-CSNP protocols and doing
right things in hardware (see Figure 1), but for ARPA
Gateways each net attached to is assumed to have the
Host-Host Protocol (TCP/IP, in
1
RFC 875 September 1982
or, anyway, IP and either TCP or some other common-to-both-
protocol above it), and the same process level protocols (e.g.,
Telnet, FTP, or whatever). The reason for this assuming
protocol set homogeneity is that they "knew" the alternative
undesirable, because it would involve the translation or
between different protocol sets in the Gateways and such T/MG'
were obviously to be avoided
Well, that didn't do the trick. "Why is a T/MG a
Thing?" he wanted to know. "Because of the possibility
irreconcilable mismatches in functionality." "For instance?"
"Addressing is the most commonly cited." "Addressing?"
Assuming the reader is as bored as I am with the
bit, I'll try to step through some specifics of the sorts
incompatibility one can find between protocol sets in a
theatric manner. Note that the premise of it all is that
don't want to change either pre-existing protocol set. Let'
assume for convenience that we are trying to attach just two
together with a T/MG, and further assume that one of the
uses the original ARPANET "NCP" -- which consists,
speaking, of the unnamed original ARPANET Host-Host Protocol
the unfortunately named "1822", or ARPANET Host-IMP Protocol --
and the other uses TCP/IP
Host addressing is the most significant problem. NCP-
hosts have "one-dimensional" addresses. That is, there's a
in the Host-IMP "leader" where the Host number goes. When you'
assigned all the available values in that field, your net is
until and unless you go back and change all the IMP's and NCP'
to deal with a bigger field. Using IP, on the other hand
addresses of Hosts are "two-dimensional". That is, there's an
header field in which to designate the foreign network
another field in which to designate the foreign Host. (
foregoing is a deliberate oversimplification, by the way.) So
you wanted a Host on an NCP-based net to communicate with a
on another, TCP-based net you'd have a terrible time of it if
also didn't want to go mucking around inside of all the
NCP implementations, because you don't have a way of
the foreign address within your current complement of
mechanisms
There are various tricks available, of course. You
find enough spare bits in the Host-IMP leader or Host-Host
perhaps, and put the needed internet address there. Or you
change the Initial Connection Protocol, or even make the
address be the first thing transmitted as "data" by the User
of each process-level protocol. The common failing of all
ploys is that you're changing the pre-existing protocols, though
and
2
RFC 875 September 1982
that sort of thing were viewed with equanimity by
proprietors you might as well go the whole hog and change over
the new protocol set across the board. Granted, that's a
jump; but it must be realized that this is just the first
several problems
(It is the case that you could get around the
problem by having the T/MG become more nearly a real Host
terminate the NCP-based side in an application program
would "ask" the user what foreign Host he wants to talk to on
TCP-based side -- at least for Telnet connections. When there'
no user around, though, as would be the case in most
transfers, you lose again, unless you fiddle your FTP.
general, this sort of "Janus Host" -- after the Roman deity
two faces, who was according to some sources the god of
(!) -- confers extremely limited functionality anyway; but
some practical cases it can be better than trying for
functionality and coming up empty.)
Then there's the question of what to do about RFNM's.
is, NCP's follow the discipline of waiting until the foreign
indicates a Ready for Next Message state exists before
more data on a given logical connection, but if you're talking
a T/MG, its IMP is the one you'll get the RFNM from (the
foreign Host might not even be attached to an IMP). Now, I'
actually seen a proposal that suggested solving this problem
altering the T/MG's IMP to withhold RFNM's, but that doesn't
me think it's a viable solution. At the very least, the T/MG
going to have to go in for buffering in a big way (see Figure 2).
In a possible worst case, the foreign net might not even let
know your last transmission got through without changing
protocols
Going beyond the NCP-TCP example, a generic topic
with the peril of functionality mismatch is that of
Out-of-Band Signal. (There are some who claim it's also
NCP-TCP problem.) The point is that although "any good Host-
protocol" should have some means of communicating aside
normal messages "on" logical connections, the mechanizations
indeed the semantics of such Out-of-Band Signals often differ
The fear is that the differences may lead to incompatibilities
For example, in NCP the OOBS is an Interrupt command "on"
control link, whereas in TCP it's an Urgent bit in the header
a message "on" the socket. If you want Urgent to be usable
order to have a "virtual quit button", the semantics of
protocol must make it very clear that Urgent is not merely
sort of thing the NBS/ECMA Host-Host protocol calls "
Data". If, that is, the intent of the mechanism is to cause
associated process/job/task to take special action rather
merely the associated protocol interpreter (which need not
3
RFC 875 September 1982
part of the process), you'd better say so -- and none of
ISO-derived protocols I've seen yet does so. And there's
much a T/MG can do if it gets an NCP Interrupt on a
link, notices a Telnet Interrupt Process control code on
associated socket, and doesn't have anything other
Expediting Data to do with it on its other side. (
Data, it may be noted, bears a striking resemblance to taking
SST across the Atlantic, only to find no one on duty in
Customs shed -- and the door locked from the other side.)
Functionality mismatch is not, of course, limited
Host-Host protocols. Indeed, the following interesting
was observed at University College London: In their "
Gateway", which translates/maps ARPANET Telnet and "Triple X
(CCITT X.25, X.28, X.29), they were able to get data across,
might be expected, but only one option (echoing), which is
worse than might be expected. (And the UCL people are
competent, so the problem almost certainly doesn't have to
with inadequate ingenuity.)
It could be argued that the real problem with Expedite
and Triple X is that some protocol sets are a lot worse
others. I wouldn't dispute that. But it's still the case,
re-use a Great Network One-liner, that
sometimes, when you try to turn an apple into
orange, you get back a lemon
Nor is the likelihood of encountering
functionality mismatches the only technical shortcoming
Translating/Mapping Gateways. A somewhat subtle but
fascinating point arises if we ask what happens when traffic
heavy enough to warrant more than one T/MG between a given
of protocol-incompatible nets (or even if we'd like to add
reliability, regardless of traffic). What happens, if we
about it a little, is a big problem. Suppose you actually
figure out a way to translate/map between two given sets
protocols. That would mean that for each logical connection
had open, you'd have a wealth of state information about it
each net you were gatewaying. But "you" now stand revealed as
single T/MG -- and your clone next door doesn't have that
information, so any logical connection that started its life
you has to spend its life with you, in a state of
monogamy, as it were. Naturally, this epoxied pair-bonding
perhaps be dealt with by still another new protocol
T/MG's, but it's abundantly clear that there will be no
analogue to no-fault divorce. That is, to put it
metophorically, it becomes at best extremely complex to
translating/mapping at
4
RFC 875 September 1982
than one T/MG for the same logical connection. As with
broader issue of reconciling given protocol sets at all, doing
at multiple loci of control may or may not turn out to
feasible in practice and certainly will be a delicate and
design task
One more NCP/TCP problem: When sending mail on an NCP-
net, the mail (actually, File Transfer) protocol currently
uses the addressee's name, because the Host was determined by
Host-Host Protocol. If you're trying to get mail from
NCP-based net to a TCP-based net, though, you're back in the
addressing bind already discussed. If you don't want to
NCP (which, after all, is being phased out), you have to
something at the process level. You can, but the "Simple
Transfer Protocol" to do it takes 62 pages to specify in
Request for Comments 788.
If things get that complicated when going from NCP to TCP
where there's a close evolutionary link between the Host-
protocols, and the process-level protocols are nominally
same, what happens when you want to go from DECNET, or from SNA
or from the as-yet incomplete NBS or ISO protocol sets?
may or may not turn out to be any aspects that no amount
ingenuity can reconcile, but it's abundantly clear
Translating/Mapping Gateways are going to have to be far
powerful systems than IP Gateways (which are what you use if
nets use the same protocol sets above the Host to Comm
Processor protocol). And you're going to need a different T/
for each pair of protocol sets. And you may have to tinker
CSNP internals.... An analogy to the kids' game of Telephone (
Gossip) comes to mind: How much do you lose each time
whisper to your neighbor who in turn whispers to the
neighbor? What, for that matter, if we transplant the game
the United Nations and have the whisperers be translators
have speakers of different languages on each side
Other problem areas could be adduced. For example, it'
clear that interpreting two protocol sets rather than one
take more time, even if it could be done. Also, it should
noted that the RFNM's Problem generalizes into a concern
resolving Flow Control mismatches for any pair of protocol sets
and could lead to the necessity of having more memory for
on the T/MG than on any given Host even for those cases
it's doable in principle. But only one other problem area
particularly major, and that is the old Moving Target bugaboo
For when any protocol changes, so must all the T/MG's
it, and as there have already been three versions of SNA
presumably a like number of versions of DECNET, and as there
at least two additional levels which ISO should be
the existence of, the fear of having to re-do T/MG's should
as a considerable deterrent to doing
5
RFC 875 September 1982
in the first place. (This apparent contravention of
Padlipsky's Law to the effect that Implemented Protocols
Barely Finite Inertia Of Rest is explained by a brand-
Padlipsky's Law: To The Technologically Naive, Change
Progress; To Vendors, Change Equals Profit.)
At any rate, it's just not clear that a given Translating
Mapping Gateway can even be built; you have to look very
at the protocol sets in question to determine even that. It'
abundantly clear that if a given one can be built it won't
easy to do (see Figure 3). Yet "system architect" after "
architect", apparently in good faith, toss such things into
block diagrams. Assuming that the architectural issue isn'
resolved by a fondness for the Gothic in preference to the
modern view that form should follow function, let's pause
to visualize an immense, turreted, crenellated, gargoyled ...
microprocessor, and return to the question of why this sort
thing happens
It's clear that buzzwording is a factor. After all, "
architects" in our context are usually employees of
and their real role in life is not to build more stately
but to get contracts, so it's not surprising to find appeal
the sort of salesmanship that relies more heavily on fast
than precision. Another good analogy: I once went to one of
big chain electronics stores in response to an ad for a
recorder that "ran on batteries or house current" for $18,
to find that they wanted an additional $9 for the (outboard)
adaptor. Given the complexities of T/MG's, however, in our
it's more like an $18 recorder and a $36 adaptor
But is buzzwording all there is? Clearly not, for
mentioned earlier there's also ignorance of the Oral Tradition
play. Whether the ignorance is willful or not is probably
left unexamined, but if we're willing to entertain the
that it's not all a bait-and-switch job akin to
separately-priced AC adaptor, we see that those who
propose T/MG's haven't done enough homework as to the real
of the art
6
RFC 875 September 1982
What ever became of that early reference to The
Literature, though? Surely you didn't think I'd never ask.
answers are both implied in the assertion that
Gateways are
as you'll plainly see once you've been reminded of
Heffalumps are. Dipping into The Relevant Literature, then
let's reproduce the opening of the Heffalumps story
One day, when Christopher Robin and Winnie-the-
and Piglet were all talking together, Christopher
finished the mouthful he was eating and said carelessly
"I saw a Heffalump today, Piglet."
"What was it doing?" asked Piglet
"Just lumping along," said Christopher Robin
"I don't think it saw me."
"I saw one once," said Piglet. "At least, I
I did," he said. "Only perhaps it wasn't."
"So did I," said Pooh, wondering what a
was like
"You don't often see them," said Christopher
carelessly
"Not now," said Piglet
"Not at this time of year," said Pooh
Then they all talked about something else, until
was time for Pooh and Piglet to go home together
(To satisfy the lazy reader -- who'd actually be better
searching for it in both -- it's from Winnie-the Pooh, not The House
Pooh Corner.)
Pooh, in case you still don't recall, decides to make a
Trap. (Piglet is sorry he didn't think of it first.) He baits it
a jar of honey, after making sure that it really was honey all the
to the bottom, naturally. In the middle of the night, he goes to
Trap to get what's left of the honey and gets his head stuck in the jar
Along comes Piglet, who sees this strange creature with a jar-like
making frightful noises, and, having known no more than Pooh
Heffalumps really were, assumes that a Heffalump has indeed been
and is duly terrified
7
RFC 875 September 1982
It would probably be too moralistic to wonder how much
Robin actually knew about Heffalumps in the first place.
"Decorator", based on the picture on page 60 of my edition,
thinks C.R. thought they were elephants, but I still wonder. At best
though, he knew no more about them than the contractor did
Gateways in the proposal that started this whole tirade off
NOTE: FIGURE 1. Defining Characteristic of All Flavors
Gateways, FIGURE 2. Gateway and Translating/Mapping Gateway
Approximately to Scale, and FIGURE 3. Respective Internals Schematics
may be obtained by writing to: Mike Padlipsky, MITRE Corporation, P.O
Box 208, Bedford, Massachusetts, 01730, or sending computer mail
Padlipsky@ISIA
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
