Return to section1.tex CVS log

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

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

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.