Return to section2.tex CVS log

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

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

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.