![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to section3.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 section3.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 {The Approach}
4: From the viewpoint of OSI-applications development,
5: we should note that the best of all solutions to the problem sketched earlier
6: requires a complementary co-existence:
7: \begin{itemize}
8: \item we want to utilize mature TCP/IP functionality and stability which is
9: not currently present in the immature OSI protocol suite;
10:
11: \item we want to utilize new OSI functionality as it becomes available;
12: and,
13:
14: \item we want to develop OSI-based applications now in an {\em evolutionary},
15: not {\em revolutionary} fashion.
16: \end{itemize}
17: These criteria suggest motivations for a migration strategy.
18: In migrating from the DDN protocol suite to the OSI protocol suite,
19: there are several strategic choices to be made.
20:
21: For the lack of a better term,
22: we will call the object which joins the two protocol suites a {\em magic box}.
23: We favor the use of this term instead of {\em gateway},
24: since the former term invokes less inference on the part of the reader.
25: To choose where the magic box should ``live'',
26: we make three observations:
27: \begin{enumerate}
28: \item Joining at the session layer (or above) introduces too much
29: dependency on the ARPAnet client/server model, as discussed in the
30: introduction.
31: This argues for the magic box to live no higher than the transport
32: level.
33:
34: \item Joining at the network layer (or below) foregoes use of the TCP and
35: requires complete implementation of the TP on top of the \dod/ IP.
36: It also prevents the use of the efficient board-level products which
37: implement the TCP.
38: This argues for the magic box to live no lower than the service
39: access points at the top of the transport layer.
40:
41: \item In general,
42: the construction of magic boxes at any location other than the transport
43: layer is problematic at best;
44: this will be illustrated later on
45: (in Section~\ref{comparison} on page~\pageref{comparison}).
46: \end{enumerate}
47: Given these arguments,
48: the OSI Transport Service Access Point (TSAP) is the ideal place for the magic
49: box to be constructed:
50: it allows us to take advantages of the main strengths of the DDN protocol
51: suite while providing OSI defined services at the layers above.
52: Figure~\ref{tsap.model} outlines the relationships we propose.
53: \tagfigure{3-1}{OSI Transport Services on top of the TCP}{tsap.model}
54:
55: Our approach is to utilize exactly one TCP port (number~102) with
56: TS-peers running on this port to interpret the protocol data units (PDUs)
57: on the connection and dispatch them accordingly.
58: This is not nearly as difficult as it sounds,
59: since the TCP performs all the multiplexing,
60: and provides each client/server pair with exactly one connection to manage.
61: As a result, the dispatch function is trivial (i.e., null).
62: Currently,
63: we use a very simple mapping between TSAP IDs and services
64: (a shortcoming described later).
65:
66: \subsection {Summary of the Protocol}\label{protocol}
67: The external behavior of our magic box is to use the services offered by the
68: TCP
69: and co-operate with other magic boxes,
70: to provide the services defined for the TP.
71: For our purposes,
72: we define the {\em services offered\/} by a protocol
73: as its service primitives.
74: The services offered by the TCP and the TP are summarized in
75: Tables~\ref{tcp.services} and~\ref{tp.services} respectively
76: (readers should consult the authoritative works \cite{TCP} and
77: \cite{ISO.TP.Service} for more detailed information).
78: For purposes of exposition,
79: we use the term {\em TS-user\/} to denote an entity utilizing the transport
80: services,
81: and {\em TS-provider\/} to denote an entity providing those services.
82: \tagtable{3-1}{TCP Service Primitives Offered}{tcp.services}
83: \tagtable{3-2}{TP Service Primitives Offered}{tp.services}
84:
85: Since both the TCP and the TP primarily offer a virtual-circuit service,
86: it is not surprising that
87: all the ``hard parts'' of the TP are also done by the TCP
88: (e.g., three-way handshake, choice of initial sequence number, windowing,
89: multiplexing, and so on).
90: This leaves us with the task of devising a protocol,
91: running above the TCP,
92: which performs whatever tasks are necessary to map one flavor of service
93: primitives into the other.
94:
95: Despite the symmetry of the TP,
96: it is useful to consider the magic-box protocol with the perspective of a
97: client/server model.
98: We view two entities, denoted {\em TS-peers}, as implementing this protocol.
99: One of these TS-peers,
100: the TSAP server, begins by LISTENing on TCP port~102.
101: When the other peer, the TSAP client, successfully connects to this port,
102: the protocol begins.
103:
104: A client TS-peer decides to connect to the TCP port on the service host
105: when the client's TS-user issues the {\sf T-CONNECT.REQUEST\/} action.
106: One of the parameters to this action specifies the TSAP ID (identifier) of
107: the remote TS-user.
108: The client uses the TSAP ID to ascertain the IP address of the server,
109: and attempts to open a connection to TCP port~102 at that IP address.
110: If not successful,
111: the client fires the {\sf T-DISCONNECT.INDICATION\/} event for the TS-user.
112:
113: Although the TCP offers a byte-stream,
114: the magic-box protocol packetizes the bytes into units which have the
115: identical syntax (format) as data units in the TP (TPDUs).
116: These packets are termed TPKTs to avoid any confusion with the term TPDU.
117: When the connection is opened,
118: the client fills in a request-connection TPKT, sends it to the server, and
119: awaits a response.
120:
121: The server, upon receipt of the TPKT,
122: validates the contents of the TPKT
123: (checking the version number, verifying the type code, and so on).
124: If the packet is invalid,
125: the server sends a request-disconnection TPKT,
126: closes the connection, and goes back to the listen state.
127: Otherwise,
128: the server examines the TSAP ID of the TS-user with which the remote TS-user
129: wants to communicate.
130: If the specified TS-user can be located and started,
131: the server starts this TS-user by firing the {\sf T-CONNECT.INDICATION\/}
132: event.
133: Otherwise a request-disconnection TPKT is sent
134: (and the server closes the connection and goes back to the LISTEN state).
135:
136: The TS-user receiving the event will now respond with one of two actions,
137: either {\sf T-CONNECT.RESPONSE\/} or {\sf T-DISCONNECT.REQUEST}.
138: Depending on the response,
139: the server sends either a request-disconnection or a confirm-connection
140: TPKT back to the client.
141: The server then enters the SYMMETRIC PEER state.
142:
143: When the client receives the reply TPKT from the server,
144: it performs the usual validation.
145: If the packet received was a request-disconnection TPKT,
146: the client fires the {\sf T-DISCONNECT.INDICATION\/} event,
147: and closes the connection.
148: Otherwise,
149: it fires the {\sf T-CONNECT.CONFIRMATION\/} event
150: and enters the SYMMETRIC PEER state.
151:
152: Once both sides have reached the SYMMETRIC PEER state,
153: the protocol is completely symmetric and the notion of whether the TS-peer
154: started as a client or server is lost.
155: Both TS-peers act in the following fashion:
156: if the TCP indicates that data can be read,
157: the TS-peer reads the TPKT, and validates the contents.
158: \begin{itemize}
159: \item A request-disconnection TPKT results in the
160: {\sf T-DISCONNECT.INDICATION\/} event being fired, and the TCP connection
161: being closed.
162:
163: \item A data TPKT or expedited data TPKT results in {\sf T-DATA.INDICATION\/}
164: or {\sf T-EXPEDITED DATA.INDICATION\/} event (respectively) being fired.
165:
166: \item Invalid TPKTs result in the {\sf T-DISCONNECT.INDICATION\/} event
167: being fired for the TS-user,
168: a request-disconnection TPKT being sent,
169: and the connection being gracefully closed.
170:
171: \item An error on the TCP connection also results in the
172: {\sf T-DISCONNECT.INDICATION\/} event being fired.
173: \end{itemize}
174: As expected,
175: the {\sf T-DATA.REQUEST}, the {\sf T-EXPEDITED DATA.REQUEST},
176: and the {\sf T-DISCONNECT.REQUEST\/} actions on the part of the TS-user
177: result in the appropriate TPKT being sent to the remote TS-peer.
178:
179: In the interests of brevity,
180: many parts of the protocol were simplified or omitted from the discussion
181: above.
182: For example,
183: when a request-disconnect TPKT is sent,
184: it contains a code indicating why the disconnect was initiated.
185: The precise protocol (including state machines) is presented in
186: \cite{TSAP.on.TCP.old}.
187:
188: \subsection {Design Decisions}
189: The previous section discussed the protocol in simplistic detail.
190: We should now consider certain nuances in the protocol's design and behavior.
191:
192: \subsubsection {Packet Format}
193: The choice of packet format for the magic box protocol was made rather arbitrarily:
194: the TP format for TPDUs was chosen as it was suitable for our needs.
195: Although a few fields are ignored,
196: this introduces a very small amount of additional overhead.
197: For example,
198: on a request-connection TPKT (the worse case),
199: there are 6 octets of ``zero on output, ignore on input'' fields.
200: Considering that the packet overhead is fixed,
201: requiring that implementations allocate an additional 6 octets is not
202: unreasonable.
203: As experience is gained,
204: some of these fields (e.g., the class field) may be used in future versions
205: of the protocol.
206:
207: \subsubsection {Quality of Service}
208: In our proposal, this is left ``for further study''.
209: We expect a future version of the protocol to attempt to map the TP QOS
210: parameters into the DDN IP precedence and security parameters.
211:
212: \subsubsection {Administration of Address Space}
213: It is tempting to define a straight-forward mapping between the OSI and
214: TCP/IP addressing domains.
215: For example,
216: the OSI network service access point identifier (NSAP ID) could be mapped
217: into a DDN IP address,
218: and a combination of the service access point selectors of the higher layers
219: could be mapped into a TCP port number.
220: Unfortunately there is no straight-forward mapping for
221: the OSI session and presentation service access point selectors,
222: as each application in the DDN protocol suite has its own implicit session
223: and presentation mechanism.
224: One solution is to view the mappings as:
225: \[\begin{tabular}{rlc}
226: $<$NSAP ID$>$&
227: $\longleftrightarrow$& $<$IP address$>$\\
228: $<$TSAP selector, SSAP selector, PSAP selector$>$&
229: $\longleftrightarrow$& $<$TCP port$>$
230: \end{tabular}\]
231: This approach is particularly interesting because it suggests that the
232: TP can be run directly above the DDN IP protocol.
233: However, this suggestion is not necessarily a benefit
234: (again see Section~\ref{comparison}).
235:
236: However,
237: the TCP port space cannot accommodate the space of OSI higher layer selectors.
238: The TCP supports a port space denoted by small integers,
239: represented as unsigned 16--bit quantities.
240: Further, any port larger than~1023 is reserved for the use of clients,
241: and ports larger than ~511 are reserved for the use of local servers.
242: This leaves about 510~ports for well-known (pre-assigned) services,
243: most of which are already in use by existing services.
244:
245: \subsubsection {Expedited Data}
246: The largest difference between the services offered by the TCP and the TP is
247: the expedited data service offered by the TP.
248: We initially experimented with three approaches which could be used in
249: implementing expedited data with the TCP:
250: \begin{itemize}
251: \item Use a single connection without the TCP URGENT\\[0.1in]
252: All data TPKTs and expedited data TPKTs are placed on the same TCP connection.
253: As a result,
254: there is no actual ``priority'' associated with the
255: {\sf EXPEDITED DATA.REQUEST\/} action other than it
256: eventually resulting in the {\sf EXPEDITED DATA.INDICATION} event occuring in
257: the future.
258: Furthermore,
259: we are guaranteed that once any expedited data is sent,
260: it will arrive before any data sent in the future arrives.
261: This is true to the letter, though perhaps not to the spirit of the TP.
262:
263: \item Use a single connection with the TCP URGENT\\[0.1in]
264: All data TPKTs and expedited data TPKTs are placed on the same TCP connection.
265: However,
266: expedited data TPKTs are sent with the URGENT bit set.
267: The receiving TCP could signal the TS-provider that URGENT information was
268: available on the connection.
269: The TS-provider could then buffer all further TPKTs until the TPKT
270: containing the URGENT pointer was received.
271: After this TPKT had been handled,
272: the buffered (non-expedited) data could be acted upon.
273: Although this is more true to the spirit of the TP,
274: it requires some complex buffer management and may not be implementable on
275: single-thread implementations of the TCP
276: (e.g., some implementations for \msdos/ on the PC).
277:
278: \item Use two connections\\[0.1in]
279: A third approach is to open two connections.
280: During connection establishment,
281: after making a TCP connection to the server,
282: the client starts a PASSIVE, non-blocking TCP open.
283: The address of a TCP port associated with the open is then passed
284: in the TSAP ID of the request-connection TPKT.
285: Immediately before the server sends the confirm-connection TPKT,
286: it connects to the indicated port.
287: Upon success,
288: it passes in the confirm-connection TPKT the TCP port it used to make
289: the second connection (thus introducing a secondary correctness check).
290: This requires no buffer management on the part of the TS-provider,
291: and can be implemented even in single-thread implementations of the TCP.
292: The disadvantage of our approach is that it may violate the letter of the TP!
293: Since two connections are used,
294: the paths in the subnet taken by the packets may differ,
295: and it is possible that non-expedited data sent after expedited data may
296: actually arrive earlier.
297: \end{itemize}
298: Version~1 of the protocol used the third approach to implement the expedited
299: data service.
300: However, in order to guarantee the semantics of the service,
301: it became apparent that a complicated buffering scheme was required.
302: Rather than introduce additional complexity,
303: in version~2 of the protocol we opted for the first approach.
304: This requires no buffering and implements the semantics correctly,
305: albeit at the boundaries of the service specification.
306:
307: \subsection {Work To Date}
308: Work to date has reached two milestones:
309:
310: \subsubsection {RFC983}
311: In April of {\oldstyle 1986},
312: the DDN Network Information Center issued RFC983,
313: entitled {\it ISO Transport Services on top of the TCP\/}\cite{TSAP.on.TCP.old}.%
314: \footnote{\cite{TSAP.on.TCP.old} specifies version~1 of the protocol.
315: Based on our experiences,
316: we are currently running version~2,
317: which consists of four minor changes to the original protocol.
318: A new RFC, describing these changes, is undergoing review.
319: Appendix~\ref{changes} summarizes these changes.}
320: This document presents our model of operation and gives a formal description
321: of the protocol described in the Section~\ref{protocol}.
322:
323: It is important to understand exactly what RFC983 intends.
324: RFC983 does not specify how one constructs an interface to the OSI TSAP.
325: It indicates how one might build such an interface on top of the TCP.
326: That is,
327: given the abstract service definitions for the TP,
328: instructions are given as to how those can be mapped on to the services
329: provided by the TCP.
330: From our perspective, a proper implementation of RFC983 exhibits the
331: following properties:
332: \begin{enumerate}
333: \item it has the TSAP interface that you want on your host;
334: and,
335: \item it uses the protocol defined in RFC983.
336: \end{enumerate}
337: RFC983 has no intention of specifying an ``OSI protocol''.
338: Rather it specifies a DDN-style protocol which provides OSI services.
339: It is the intent of RFC983 to permit standard OSI protocols to run on top of
340: the TCP.
341: It is not the intent to build OSI-like protocols for the DDN.
342:
343: From our experience, we agree with John Leong of CMU that:
344: \begin{quote}\em
345: ``In general,
346: it is important for one to produce good generic protocol interface design so
347: that a particular protocol implementation or even the protocol itself can
348: easily be replaced without affecting the code in the upper or lower layer.''
349: \end{quote}
350: It is the intent of RFC983 to be true to this tenet.
351:
352: \subsubsection {Prototype Implementation}
353: To test our ideas,
354: we constructed a prototype implementation of RFC983 under Berkeley \unix/.
355: The implementation supports both OSI-style asynchronous {\sf INDICATION}
356: events,
357: and also DDN-style synchronous events.
358: We intend this software to play a key role in the migration strategy which is
359: discussed in the next section.
360:
361: \subsection {Comparison to Other Approaches}\label{comparison}
362: \cite{Protocol.Conversion} makes a thorough investigation of the many
363: issues involved in protocol conversion and complementing,
364: and it is unnecessary for us to summarize those findings here.
365: Instead, let us concentrate on previous work devoted to implementing the magic
366: boxes between two different protocol suites,
367: and in particular between the DDN and OSI protocols.
368: Further,
369: it has been our claim throughout this paper that building a magic box at any
370: location other than the transport layer is not particularly useful.
371: In this section,
372: we will consider this argument.
373:
374: In \cite{TCP.convert.ISO}
375: it is proposed that conversion between the DDN and OSI protocol suites
376: occur inside the transport layer instead of at the transport service access
377: point.
378: After an analysis of the state machines associated with the TCP and the TP,
379: and the identification of a common subset of services,
380: a state machine for a gateway between the two is derived.
381: The resulting gateway algorithm is no more complicated than the most
382: complicated of the two original machines.
383: It is then suggested that this approach is practical as a short-term solution
384: to the TCP/IP and OSI interoperability problem.
385:
386: \subsubsection {Our Analysis of this Work}
387: Unfortunately,
388: in our opinion,
389: the existence of such a gateway is of limited {\em practical\/} value.
390: Although the gateway does achieve an end-to-end transport capability,
391: with one TS-user utilizing a TP interface and the other TS-user utilizing a
392: TCP interface,
393: there is no common session, presentation, and application layer.
394: That is,
395: although entities above the transport layer can have the potential to
396: communicate between the two suites,
397: no useful work can occur
398: until the DDN ``world'' implements the higher-layer OSI protocols,
399: or the OSI ``world'' implements the higher-layer DDN protocols,
400: or both.
401: \cite{TCP.convert.ISO} suggests that the DDN domain immediately implement
402: the FTAM on top of the TCP, and so on.
403: In the authors opinion,
404: this is not a practical short-term solution.
405: Furthermore,
406: it appears to violate the widely-held notion of separation of knowledge
407: between layers.
408:
409: It does however illustrate a recurring theme in work wherein conversion
410: between different protocol suites is reported
411: (e.g., \cite{SNA.convert.XNS},
412: which discusses the interconnection of SNA and XNS networks).
413: The theme, of course, is that general utility requires that
414: protocol conversion occur at every layer in which the two suites can be
415: connected.
416: For example,
417: when considering the application of electronic mail,
418: building a TCP/TP gateway is not useful unless there is either:
419: \begin{itemize}
420: \item an SMTP implementation running in both the TCP and TP domains;
421: or,
422: \item an X.400 implementation running in both the TCP and TP domains;
423: or,
424: \item an SMTP/X.400 (or more precisely SMTP/P1\cite{MHS.P1}) gateway
425: running in the TCP/TP gateway.
426: \end{itemize}
427: Each of these three alternatives is expensive to implement,
428: and in addition, the first two are politically unacceptable to the parties doing
429: the implementing.
430: All three require that everything above the transport layer,
431: except for the application itself (i.e., session and presentation),
432: be implemented as well.
433:
434: In comparing our approach with previous work,
435: we see that ultimately both approaches have the same end-result:
436: the same transport service is offered.
437: However,
438: our approach is significantly easier to implement.
439: Neither approach makes the problem of achieving interoperability between
440: applications in the two protocol suites any easier:
441: the only way to achieve interoperability is to implement special-purpose
442: gateways for each pair of related applications.
443: However,
444: the approach we suggest has two important advantages over the protocol
445: translation approach, once we are willing to acknowledge that we intend to
446: migrate to one of the protocol suites (i.e., from the DDN to the OSI protocol
447: suite):
448: first, we can develop and gain experience with OSI applications now;
449: and, second,
450: any new applications we develop can run in either environment.
451: This has the important implication that from this point on,
452: that any future applications we develop will be guaranteed to run in the
453: protocol suites available to us
454: (that is, no new work will have to be done when we migrate from one protocol
455: suite to the other).
456:
457: In the next section,
458: we will consider the value of our approach in the medium-term,
459: when we want to transition from the DDN protocol suite to the OSI protocol
460: suite.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.