![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to section2.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 section2.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 {Background}
4: Having suggested that the use of TCP/IP is beneficial in the short- and
5: medium-term for the development of OSI-based application protocols,
6: and further,
7: that a strategy utilizing the DDN protocols towards these ends can also prove
8: to be a valuable tool during the transition from TCP/IP-based networks to
9: OSI-based networks,
10: it behooves us to present a terse definition of these terms.
11:
12: \subsection {The DDN Protocol Suite}
13: The \dod/ Transmission Control Protocol (TCP)\cite{TCP} provides
14: end-to-end transport services for \dod/ military standard networking
15: applications.
16: The TCP presents a full-duplex connection service to two end-peers,
17: while addressing the issues of reliability when using a non-reliable datagram
18: service.
19: The TCP implements a three-way handshake for connection establishment,
20: uses a windowing scheme for flow-control purposes,
21: and has a graceful termination phase.
22: To access the underlying network,
23: the TCP utilizes the services of the \dod/ Internet Protocol (IP)\cite{IP}.
24:
25: The IP is a datagram, or connectionless, service and includes provision for
26: service specification, fragmentation/reassembly, and security information.
27: The IP makes no assumption regarding the reliability of the communications
28: subnet, and uses a simple checksum mechanism.
29: This requires the higher layer protocols (e.g., the TCP) to handle end-to-end
30: reliability.
31: This degree of freedom permits the IP an unprecedented amount of flexibility
32: in dealing with different subnetwork technologies,
33: and in connecting those subnetworks efficiently.
34:
35: The DDN protocol suite is based on the ARPAnet Reference Model (ARM).
36: Interested readers should consult \cite{Internet.Architecture,ARM} for a
37: perspective on this model.
38: For our purposes,
39: it is instructive to note that there is an underlying {\em client/server\/}
40: paradigm for services.
41: Speaking in broad generalities:
42: a {\em server\/} listens on a well-known {\em port\/}
43: (e.g., file transfer activities occur over TCP port~21),
44: awaiting a connection.
45: At some later time,
46: a {\em client\/} will connect to the server.
47: After some application-specific negotiations,
48: the client begins to make requests of the server,
49: which in turn makes various responses.
50: These transactions
51: continue until either the client or server determine that no further
52: transactions remain and the connection should be closed.
53:
54: Further,
55: servers in the ARPAnet Reference Model tend to be stateless in nature.
56: That is,
57: there is no inherent state information retained between connection sessions.
58: As a result,
59: connections can and generally do exist in parallel between several clients and
60: several servers
61: (each of the latter being instantiated when a client connects to the
62: well-known port).
63: Of course,
64: there may be side-effects between different instantiations
65: (e.g., when one file server removes a file,
66: this usually results in other servers being unable to retrieve that file),
67: but there is no state information which ``lives'' between instantiations of a
68: given server.
69:
70: Finally,
71: the ARM is not a seven-layer architecture:
72: applications reside directly above the TCP
73: and have implicit session and presentation mechanisms
74: (i.e., they are application-specific).
75:
76: The DDN protocol suite is quite mature,
77: having stabilized about {\oldstyle 1980}
78: (the fundamental work leading to TCP/IP having been done since the early
79: {\oldstyle 1970\/}'s).
80: TCP/IP enjoys a wide vendor support base and user population.
81: Typically, vendor support from TCP/IP to other technologies
82: (e.g., IBM's SNA\cite{SNA}) is available,
83: and many vendors offer board-level implementations at the transport layer.
84: As of April, {\oldstyle 1986},
85: in the ARPA Internet,
86: most probably the largest unclassified TCP/IP internetwork,
87: it was estimated that there were 2400~hosts residing on 400~networks
88: connected via 120~gateways.
89: The same source\cite{IP.Requirements} estimates that the ARPA Internet is
90: growing at the rate of approximately 10\% a month.
91:
92: The services available in the DDN protocol suite are wide and varied,
93: supporting everything from cross-network debugging,
94: to network measurement and host measurement,
95: to voice protocols,
96: and so on (consult \cite{Assigned.Numbers} for a full list).
97: Perhaps the three most notable services are:
98: SMTP\cite{SMTP}, the Simple Mail Transfer Protocol,
99: which provides store-and-forward service for text messages;
100: FTP\cite{FTP}, the File Transfer Protocol,
101: which provides remote file access;
102: and,
103: TELNET\cite{TELNET}, which provides network virtual terminal access.
104:
105: \subsection {The OSI Protocol Suite}
106: Offering services similar to the TCP is the OSI Transport
107: Service\cite{ISO.TP.Service},
108: henceforth called TP,
109: which addresses the same general issues.%
110: \footnote{This paper references the ISO specifications rather than
111: the CCITT recommendations.
112: The differences between these parallel standards are quite small,
113: and can be ignored, with respect to this paper, without loss of generality.
114: To provide the reader with the relationships:
115: \[\begin{tabular}{lll}
116: Session protocol& \cite{ISO.SP.Protocol}&
117: \cite{CCITT.SP.Protocol}\\
118: Transport protocol& \cite{ISO.TP.Protocol}&
119: \cite{CCITT.TP.Protocol}\\
120: Transport service& \cite{ISO.TP.Service}&
121: \cite{CCITT.TP.Service}
122: \end{tabular}\]}
123: In contrast though,
124: the reference model for Open Systems Interconnection (OSI)\cite{OSI},
125: is based on a {\em user/provider\/} paradigm for services.
126: That is,
127: instead of viewing an asymmetric horizontal relationship between peers
128: (as with the servers and clients in the ARM),
129: the peers are viewed as being completely symmetric in behavior.
130: Instead of a server listening on a well-known port
131: when a connection is established,
132: the {\em provider\/} fires an {\sf INDICATION\/} event for the entity at the
133: next highest layer.
134: This entity, called the {\em user}, catches the event and acts accordingly.
135: Although this might be implemented by having a user acting as a server
136: ``listen'' by hanging on the {\sf INDICATION\/} event,
137: from the perspective of the OSI reference model,
138: all users remain in the {\sf IDLE\/} state until they generate a
139: {\sf REQUEST\/} or accept an {\sf INDICATION}.
140:
141: The services under consideration and being implemented for the OSI protocol
142: suite are also wide and varied.
143: Perhaps the most notable services are:
144: FTAM\cite{ISO.FTAM}, the File Transfer, Access, and Management Protocol;
145: and,
146: MHS\cite{MHS}, the suite of protocols for Message Handling Systems,
147: originally developed by IFIP in {\oldstyle 1979}.
148:
149: \subsection {Comparison of Services}
150: Several studies have been performed comparing the DDN and OSI protocol
151: suites
152: (e.g., \cite{NRC.Report}, which concluded that the TCP and the TP were
153: functionally equivalent).
154: As discussed by \cite{TCP.convert.ISO},
155: the services offered by the two protocols can be divided into three areas:
156: connection establishment, data transfer, and connection release.
157: Although we disagree with the bias with which the comparison is presented,
158: the results are essentially correct:
159: the two protocols offer services of functional equivalence with very few
160: differences.
161: For our purposes,
162: it is important to note:
163: \begin{itemize}
164: \item Simultaneous connection requests by both ends of the connection
165: result in two connections being established in the TP,
166: while in the TCP a single connection is established.
167: Experience shows this difference to be of little practical value in
168: a large number of applications using a connection-oriented transport service.
169:
170: \item The TCP does not have an expedited data transfer mechanism,
171: although an urgent pointer is available.
172: This paper will suggest a method for implementing an expedited data stream on
173: top of the TCP so that OSI-based applications can naively utilize this
174: mechanism.
175:
176: \item The TP does not have a graceful ``drain-and-close'' mechanism for
177: connection release.
178: Most user profiles of the TP
179: (e.g., the National Bureau of Standards profile of TP4\cite{NBS.TP})
180: require the inclusion of an orderly release facility in the TP,
181: based on the corresponding session-level mechanism.
182: As will be made clear later,
183: this lack of functionality in TP is unimportant.
184: \end{itemize}
185:
186: \subsection {A Digression on the Interoperability of Applications}
187: Ideally,
188: in order to preserve our investment in existing tools
189: we would like to do one of two things:
190: \begin{enumerate}
191: \item achieve interoperability between similar applications in each protocol
192: suite;
193: or,
194: \item migrate an existing application from one protocol suite to the other.
195: \end{enumerate}
196: In practice,
197: neither of these goals can be realized without a significant investment.
198:
199: In the first case,
200: although both the DDN protocol suite and the OSI protocol suite have,
201: for example,
202: a``mail'' application,
203: they are quite different.
204: That is, they provide electronic mail services,
205: but the type of services available and the implementation of those services
206: is vastly different.
207: Hence,
208: in order to make mail in the DDN protocol suite interoperate with mail in the
209: OSI protocol suite,
210: a special-purpose gateway is required.
211: (To grasp the complexity of this issue,
212: interested readers should consult \cite{ARPA.MHS} which describes the
213: operation of such a gateway for mail applications.)
214:
215: Given that the first alternative is not practical,
216: what about the second?
217: Unfortunately,
218: this too is not straight-forward.
219: As a brief review,
220: let us compare the two {\em protocol stacks\/} which comprise the
221: DDN and OSI protocol suites.
222: These are presented in Figure~\ref{stacks}.
223: \tagfigure{2-1}{Comparison of the Protocol Stacks}{stacks}
224:
225: Although there is great similarly until we reach the the transport layer,
226: at this point,
227: the stacks diverge.
228: The figure emphasizes that
229: each application in the DDN protocol suite has its own implicit session and
230: presentation mechanisms,
231: whereas in the OSI protocol suite these exist explicitly as layers.
232: In short,
233: in the DDN protocol suite,
234: the services required by the applications are exactly those which are offered
235: by the transport service;
236: but,
237: in the OSI protocol suite,
238: the services required by the applications and those provided by the transport
239: service are not the same.
240: Hence,
241: although the {\em services offered by the transport layer\/} are quite similar
242: between the two stacks,
243: the {\em services required by the applications\/} are quite different.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.