Return to section3.tex CVS log

Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / cn-isdn

Annotation of 43BSDReno/contrib/isode-beta/doc/cn-isdn/section3.tex, revision 1.1

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.