![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to tsaptalk.tex CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / tsaptalk|
Return to tsaptalk.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / tsaptalk |
1.1 root 1: % Use LaTeX to process this file
2:
3: \documentstyle[11pt]{article}
4:
5: \begin{document}
6:
7: \title{A MODEST PROPOSAL}
8: \author{Dwight E. Cass\\
9: Automation Sciences Laboratory\\
10: Northrop Research and Technology Center}
11: \date{May 15, 1986}
12: \maketitle
13:
14: \begin{quote}\em
15: This is a transcript of the talk presented to the MAP/TOP Users' Group Meeting
16: on May 15, 1986 in Seattle, Washington.
17: \end{quote}
18:
19: \bigskip
20:
21: I am going to limit my comments today to one particular project which is
22: going on at the Corporate Research and Technology Center. That is not to
23: say that Northrop is not doing other MAP and TOP related projects. There
24: are a number of other opportunities currently being explored, including
25: an RFI which was recently released by our Aircraft Division looking to
26: vendor support headed to MAP and TOP.
27:
28: At the Research Center, we are looking towards long range solutions to
29: Northrop, which is an aerospace vendor. We have a number of unique problems
30: which General Motors doesn't directly address.
31:
32: We have identified two specific problems that we are trying to address. The
33: first problem is a lack of application protocols. This lack has been
34: identified and is being addressed within the MAP and TOP community but is
35: not being addressed quickly enough. The biggest problem that we have seen
36: is that history has shown that the application level protocol development
37: takes as long or significantly longer than the lower level protocols.
38:
39: The second problem that we have seen is that currently we do not have MAP
40: and TOP for all the machines we have throughout the corporation. One of
41: the biggest problems we have is with IBM right now. Over 50\% of the
42: machines that we have in house are IBM equipment. It is not adequate
43: to put Series Ones talking to SNA. ({\em Applause\/}) Our customers
44: are the Department of Defense. He wants us to talk electronically, TODAY!
45: He is not willing to wait.
46:
47: The cause of these problems --- first, MAP/TOP, while unbelievably
48: successfully is still very very young. There is quite a bit more work
49: to be done. All the work that is going on right now that the standards
50: committees are developing must be embodied. We have to continue this
51: level of effort. But, Northrop has its requirements NOW! We need to
52: be able to communicate with the participants electronically. We need to
53: have factory and division-wide networking installed and operational in
54: the '88 to '89 timeframe. We cannot consider continuing to make large
55: investments in SNA. And it is simply not acceptable for Northrop to
56: shutdown its factory for a large period of time to replace existing
57: equipment and throw it out. Finally, any solution that we take, if we
58: choose to do something other than a pure MAP/TOP solution must be
59: consistent with the directions of this body.
60:
61: Two observations to be made at this point. The first is that many of
62: these problems have been solved in the past, though definitely in
63: different environments. There are several other proprietary and research
64: based protocol suites, which address many of these problems. The second
65: observation is that MAP/TOP is a highly layered protocol, and indeed is
66: a subset of ISO. As a matter of fact, it is a walk-through the tree
67: of the ISO protocols. The key here is that layered protocols allow mixing
68: and matching of layers as necessary. We are trying to emphasize here
69: services provided by each layer, not necessarily the implementation
70: of those services at the low level. So the question that we have to ask is,
71: How does Northrop get communications now that would be consistent with
72: MAP/TOP and that would communicate electronically with the DoD?
73:
74: Now, we have to look to the DoD for the solution, and the solution seems
75: to be TCP/IP. This is a protocol suite installed in 1980 on the ARPAnet
76: worldwide internet. It has been mandated for use for all DoD
77: internetworking. It has a high emphasis on reliability and security.
78: It supplies currently virtual terminal service, electronic mail, file
79: transfer services, and a number of other less advertised capabilities.
80: It has wide, wide vendor support. I can go out today and buy TCP for
81: every machine that I have in house, off the shelf, install it easily,
82: and specifically, I can buy TCP/IP for every piece of IBM hardware that I
83: have.
84:
85: TCP/IP specifically supports a very robust transport service, as documented
86: in the National Research Council report comparing TCP/IP to ISO, the
87: functionality of these two protocols are pretty much identical. The other
88: observation here is that TCP/IP, due to it's vendor support and it's
89: openness, has been implemented in board level products. This allows us
90: to place TCP/IP in existing pieces of hardware that are fully loaded,
91: without making major impacts on the CPU capabilities that we have in house.
92:
93: So, how do we construct this solution and stay with where MAP/TOP is going?
94: The only solution seems to be complementary coexistence. We need the
95: best of both worlds. This will give us the opportunity to run today,
96: to run tomorrow, and by the time that the Department of Defense has met
97: ISO, we'll be already there. It is important to emphasize that Northrop
98: is looking for an evolutionary migration path to its communications problems.
99: It is not willing to accept throwing away and starting again.
100:
101: If you are going to talk about coexistence, you are going to have to decide
102: where you are going to join the two protocols. Several places come to
103: mind. One of the earliest proposals was to join at the IP layer. To do
104: this, of course, would require that we implement a full TP4. It didn't
105: seem practical, and it didn't seem to be cost effective, besides the fact
106: that it prohibits us from using board level products. We looked at
107: implementing at the Session layer, but the problem is that above Transport,
108: we start dealing with the problems of the symmetric ISO model versus the
109: client/server ARPA model. The only obvious point was at the Transport
110: Service Access Point. This gave us the capability of using the robust
111: TCP transport service while still allowing MAP freedom to do whatever
112: was necessary at the higher layers, isolating the applications from
113: the reality of whatever they were running.
114:
115: Where are we headed today? At the Research Center we published a
116: proposed Transfer Service Access Point. We then implemented this proposal
117: on a Berkeley 4.2 UNIX system, and have since published this proposal
118: within the ARPA internet community as RFC983. RFC983 fully describes
119: a TP4/TSAP implementation on top of TCP. Everything except for, of course,
120: quality of service is supported within the implementation, because as you
121: know, quality of service is not defined yet. For addressing we have to take
122: TCP/IP-based addressing, however we would be more than happy to start dealing
123: with the addressing issue as the Standards Committees do, and currently
124: we have an implicit maximum TSDU size of 65 Kbytes, but that will be
125: relaxed in the next version. I do have with me today, copies of the RFC
126: and I can get a hold of the source code for you. This is all public
127: domain work. You are all welcome to take it and if you need, work with it.
128:
129: Our next step. What we need next is to put an implementation of Session, FTAM,
130: and CASE on this TSAP. One of the important things here is we can go
131: off and write it, but it would invalidate any hopes of compatibility between
132: MAP and what we're doing. As such, we must find a version of Session, FTAM
133: and CASE intended for a functional MAP system --- hopefully public domain,
134: so we can distribute it to the ARPA internet community. The other thing
135: that we will be doing is implementing this RFC on the other machines
136: currently within Northrop.
137:
138: As a migration strategy to ISO, RFC983 is not planned solely as a migration,
139: but could easily form the backbone for a full migration plan. What we are
140: hoping to do is to fully track what the Department of Defense does over the
141: next several years to yet bring us to ISO when our customers have.
142:
143: In summary, what we think we found is the best of all worlds. We can talk
144: to our customer today with such a capability. We can install and perform
145: research, today. We can develop MAP/TOP applications, today. We can migrate
146: to ISO as our customer does. We solved the security problem for our
147: communications, and reaped the benefit of all the researchers within the
148: Department of Defense internet community.
149:
150: Thank you very much. ({\em Applause\/})
151:
152: \end{document}
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.