![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to section1.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 / cn-isdn|
Return to section1.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / cn-isdn |
1.1 root 1: % run this through LaTeX with the appropriate wrapper
2:
3: \section {Introduction and Motivation}
4: To promote the use of open systems environments in the office,
5: technical, and manufacturing environments,
6: two influential user groups were formed,
7: the Manufacturing Automation Protocol group (MAP),
8: sponsored by General Motors Corporation,
9: and, the Technical and Office Protocols group (TOP),
10: sponsored by Boeing Computer Services.
11: In order to act more effectively,
12: the Society of Manufacturing Engineers (SME)
13: consolidated the two user groups into MAP/TOP under SME sponsorship.
14: MAP/TOP is championing the use of open systems interconnection (OSI),
15: primarily in the United States.
16: The widespread adoption of open standards is not a new idea,
17: for example,
18: the Department of the Defense has,
19: since the mid-{\oldstyle 70\/}'s been mandating the use of what is now called
20: the Defense Data Network (DDN) protocol suite for its computer-communication
21: applications.
22:
23: MAP/TOP has received support from both the public and private sectors,
24: particularly from users who have suffered for years with myriads of
25: computer-based systems which simply do not talk to each other
26: (even if all those systems are purchased from a single vendor).
27: This has influenced the Department of Defense to clearly state,
28: through a number of recent programs and proposals,
29: that successful contractors must be able to communicate electronically,
30: not only internally, but also with the customer (\dod/),
31: preferably using the OSI protocols.
32:
33: This leaves most defense contractors and many others in the following
34: situation:
35: With the use of open standards, many benefits can be achieved.
36: For example,
37: the use of open standards makes it possible to solve the so-called
38: {\em islands of automation\/} problem as described above.
39: However,
40: although the work currently being done in the MAP/TOP community promises a
41: major breakthrough in electronic communications,
42: MAP/TOP is generally not expected to achieve widespread use for at least
43: five years.%
44: \footnote{This problem can not be understated:
45: for example,
46: in the international committees,
47: there is no consensus to the routing issues at the network layer.
48: Some insiders suggest that three years of work will be required before
49: the non-trivial routing problems are resolved (at the committee level).}
50: Contractors planning to do business with the Department of Defense cannot
51: afford the luxury of waiting five years before starting to solve their
52: communications problems.
53: Nor can they simply ``scrap'' everything and start from ``scratch'' when
54: MAP/TOP has materialized.
55: Hence, we find ourselves in a dilemma.
56:
57: \subsection {Understanding the Problems}
58: Thus far,
59: we have isolated two problems:
60: first, we want to be running MAP/TOP applications now;
61: and,
62: second, if we are using other computer-communication technologies now,
63: it would be advantageous to migrate from our current approaches to the
64: MAP/TOP approach.
65:
66: A key point in understanding the thrust of MAP/TOP,
67: is that MAP/TOP bases itself on the OSI protocol suite.
68: In many senses,
69: MAP/TOP represents an effort to ``prune the OSI tree'' in order to provide
70: vendors with a subset of the protocols which can be implemented in a timely
71: manner.
72: For example,
73: MAP/TOP currently limits itself to local area networking.
74: Further,
75: as new needs arise,
76: MAP/TOP influences the OSI community towards the development of protocols to
77: meet those needs.
78: Hence,
79: for the remainder of this paper,
80: we will use the term ``OSI protocol suite'',
81: understanding that it includes MAP/TOP,
82: without any loss in generality.
83:
84: While the last several years of work in OSI have resulted in a
85: consensus regarding the transport layer and below,
86: application protocols have not enjoyed this degree of attention
87: (with perhaps the notable exception of MHS\cite{MHS}).
88: Further,
89: experience in the field repeatedly demonstrates that the development of
90: standard application protocols takes as long, or {\em much longer},
91: than protocols at other layers.
92: Finally,
93: considering that there is still a great deal of basic research to be
94: done in a number of application protocols areas,
95: such as distributed information bases and distributed robotic control,
96: it becomes apparent that the problem of application protocol development
97: is significant.
98:
99: \subsection {Finding the Solutions}
100: To solve these problems,
101: we begin by considering two observations.
102: First,
103: many of these problems have been solved in the past by others.
104: There are several other proprietary and open protocol suites,
105: which address many of these problems.
106: Indeed,
107: the last 15~years of the literature describe several successful attempts
108: at application (and other) protocols.
109: Second,
110: we note that MAP/TOP is based on the OSI protocol suite,
111: which in turn is based on a layered architecture.
112: The key here is that layered architectures allow us to
113: ``mix and match'' modules with similar requirements at a given layer as
114: necessary to achieve an optimal solution.
115: In all cases,
116: the layered approach emphasizes the {\em services\/} provided at a layer,
117: not the {\em implementation\/} of those services.
118:
119: Let us now continue with the problem at hand:
120: how can we achieve a communications strategy consistent with the
121: direction of MAP/TOP,
122: {\em and\/} allow us to communicate electronically with the Department of
123: Defense?
124: In this paper,
125: we suggest using the Defense Data Network (DDN) protocol suite,
126: commonly referred to as TCP/IP,
127: as the solution of choice.
128:
129: During the course of this paper,
130: it will become clear that the approach we suggest is not limited to
131: defense contractors only.
132: Quite the contrary,
133: we present several arguments which suggest that the
134: immediate adoption of the DDN protocol suite as a migration path
135: towards MAP/TOP and OSI is an optimal strategy.
136: We base these arguments in part on the maturity and stability of the DDN
137: protocols;
138: on the multi-vendor support that TCP/IP enjoys;
139: and on
140: the widespread use of TCP/IP as an interconnection method among various
141: proprietary solutions.
142:
143: In using the notion of layering to solve the problems,
144: we observe that there are two fundamental approaches which can be used:
145: \begin{itemize}
146: \item A {\em protocol translation\/} approach, as suggested by
147: Groenbaek\cite{TCP.convert.ISO} and others;
148: and,
149:
150: \item an {\em interface translation\/} approach, which we suggest in this
151: paper.
152: \end{itemize}
153: We argue that our approach is superior since it accomplishes the same
154: end-results as the protocol translation approach,
155: but is much simpler and less expensive to implement.
156: Further,
157: our approach has two important advantages:
158: it allows us to develop OSI standard applications directly on hosts using the
159: DDN protocols,
160: and any such applications will be able to ``run'' in either environment.
161:
162: \subsection {What's in a Name?}
163: Before proceeding,
164: the authors feel it important to clarify some terminology used in this paper.
165: Throughout this work,
166: we refer to both ``DDN'' and ``OSI'' as different protocol suites.
167: Although this is currently the dominant interpretation,
168: there is an alternate perspective, which the authors and others subscribe to.
169:
170: This alternate view considers OSI as a technique for describing a
171: com\-put\-er-com\-mun\-i\-cat\-ions architecture in terms of abstractions
172: (e.g., layering, entities, services, protocols, access points, and so on).
173: As such, it follows that there are varying interpretations of OSI,
174: each with a reference model described in terms of these abstractions.
175: For example,
176: the Defense Data Network (DDN) protocol suite can be thought of as one
177: interpretation of OSI;
178: similarly,
179: the protocols developed by the International Standards Organization (ISO),
180: can be thought of as an alternate interpretation of OSI.
181: That is,
182: it is sensible for one to discuss
183: the difference between the DDN and ISO protocol suites,
184: even though the two suites are based on different reference models.
185: The commonality the two protocol suites share is derived from the abstraction
186: technique used to construct their respective models.
187:
188: In order to maximize the readability of this work,
189: we have used the consensus interpretation throughout the paper.
190: It is the opinion of the authors however that the alternate perspective is
191: more powerful.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.