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

1.1     ! root        1: % run this through LaTeX with the appropriate wrapper
        !             2: 
        !             3: \section      {Migration Strategies}
        !             4: Let us now consider the larger question of how a migration
        !             5: strategy based on the approach we've suggested might be devised.
        !             6: In practice,
        !             7: successful migration strategies are based on careful planning and a
        !             8: step-by-step progression toward the final goal,
        !             9: wherein each step consists of changing only one logical portion of the
        !            10: environment.
        !            11: This tends to isolate the effect of unexpected consequences,
        !            12: and also to minimize the degree of ``culture shock'' suffered by users of the
        !            13: system.
        !            14: In our approach,
        !            15: we suggest three phases which are not clearly distinct.
        !            16: We imagine all three to be on-going projects in which the first phase enjoys
        !            17: the most emphasis initially,
        !            18: and as time progresses,
        !            19: emphasis shifts to later phases.
        !            20: 
        !            21: An interesting exception to our strategy should be briefly mentioned.
        !            22: Although there is little utility in having a host support both the DDN and
        !            23: OSI protocols for virtual terminal applications or file transfer applications,
        !            24: the store-and-forward nature of electronic mail suggests that a gateway
        !            25: between MHS and DDN mail is essential during a transition period.
        !            26: Fortunately,
        !            27: work is proceeding in this area along a separate line
        !            28: (interested readers should consult \cite{ARPA.MHS}).
        !            29: 
        !            30: Finally,
        !            31: note that an underlying assumption of our migration strategy,
        !            32: is that any new hosts introduced into our internet must support TCP/IP
        !            33: until the end of the final phase.
        !            34: Although it is preferable that these hosts also support the OSI protocol suite,
        !            35: this is not mandatory.
        !            36: 
        !            37: \subsection    {Phase One: Development Environment for OSI Applications}
        !            38: Phase one of our migration strategy has the goal of building an OSI
        !            39: application development environment on a DDN foundation.
        !            40: Our intention is then to build OSI applications and gain experience using them,
        !            41: and to do so within the robust and mature DDN network community.
        !            42: 
        !            43: To accomplish this,
        !            44: we make use of the OSI TSAP on top of the TCP.
        !            45: We will also need
        !            46: implementations of the OSI session layer\cite{ISO.SP.Protocol,ISO.SP.Service},
        !            47: and the OSI presentation layer\cite{ISO.PP.Syntax,ISO.PP.Encoding},
        !            48: and the common Application Service Elements Kernel
        !            49: (CASE)\cite{ISO.CASE.Service}.
        !            50: During the integration of this software,
        !            51: it will be important to track the work currently being done in the area
        !            52: of programming language interfaces,
        !            53: in order to utilize these applications in later phases.
        !            54: 
        !            55: Finally,
        !            56: as new applications are developed during this phase,
        !            57: we will also need to develop user agents.
        !            58: As an application and its corresponding user agent software is brought
        !            59: on-line,
        !            60: users of applications in the DDN protocol suite will be encouraged to try the
        !            61: new OSI equivalents instead.
        !            62: Although progress will be slow at first,
        !            63: this has several advantages:
        !            64: first, it helps prepare users for the final phase,
        !            65: in which only OSI applications are available;
        !            66: second, it allows us to make use of the vast wealth of application and user
        !            67: experience to be found in the many existing communities that use the DDN
        !            68: protocol suite.
        !            69: 
        !            70: Of course,
        !            71: there is an important side-effect that this phase introduces:
        !            72: properly designed user-interfaces for network services
        !            73: (e.g., file transfer) should be able to distinguish between the DDN and OSI
        !            74: services which could be offered by the remote host.
        !            75: For example,
        !            76: a user-interface to a file transfer facility,
        !            77: could select either an FTAM or FTP client,
        !            78: depending on the protocols supported by the service host.
        !            79: In either case,
        !            80: a TCP/IP underpinning is used to support these services,
        !            81: and the user is naive with respect to the actual application protocols used.
        !            82: 
        !            83: \subsection    {Phase Two: Experiment with Migration Engines}
        !            84: Phase two of our migration strategy consists of putting in the field several
        !            85: computers which have both the DDN and the OSI protocol suites implemented in
        !            86: them.
        !            87: We term these hosts {\em migration engines}.%
        !            88: \footnote{Readers should not be misled by the use of this colorful term.
        !            89: A migration engine is simply any host having both the DDN and OSI protocol
        !            90: suites resident.
        !            91: In many cases,
        !            92: installing additional software in the host operating system is sufficient to
        !            93: meet this criterion.}
        !            94: Although it is tempting to consider these migration engines as potential
        !            95: gateways, particularly application gateways,
        !            96: between the DDN and OSI protocol suites,
        !            97: considering the many reasons previously discussed,
        !            98: this is highly undesirable.
        !            99: Rather,
        !           100: we use these migration engines to test whether the applications developed in
        !           101: our DDN-style environment will function correctly in an OSI-style environment.
        !           102: 
        !           103: Of course,
        !           104: once a migration engine is in place,
        !           105: it allows us to experiment with performing gatewaying at the internet layer
        !           106: (e.g., as suggested by \cite{TCP.convert.ISO}).
        !           107: This has the potential of permitting additional connectivity between networks
        !           108: using the DDN protocols and those using the OSI protocols.
        !           109: Although this will not achieve interoperability between the DDN and OSI
        !           110: applications (as was discussed in the previous section),
        !           111: it does achieve interoperability between OSI applications running in DDN-style
        !           112: networks and OSI-style networks.
        !           113: 
        !           114: Initially,
        !           115: the number of migration engines available from different vendors
        !           116: will be rather small, and the implementations of the OSI protocols on them
        !           117: will be immature and most likely inefficient.
        !           118: This is to be expected.
        !           119: As the expertise with the technology is gained,
        !           120: we can expect these deficiencies to be lessened.
        !           121: As the OSI implementations improve,
        !           122: more and more OSI applications developed in phase one can be migrated.
        !           123: 
        !           124: \subsection    {Phase Three: Deploy Migration Engines}
        !           125: Phase three of our migration strategy consists of an upgrade or replacement
        !           126: of existing computers with hosts speaking both protocol suites.
        !           127: Once we find that vendors are able to supply OSI capability with robust and
        !           128: mature characteristics,
        !           129: then we can begin to field the migration engines throughout our DDN-style
        !           130: network.
        !           131: During phase three,
        !           132: the majority of users will employ user agents for OSI instead of DDN
        !           133: applications,
        !           134: since all hosts will be supporting the OSI user agents
        !           135: (even those which only support the DDN protocol suite).
        !           136: 
        !           137: Finally,
        !           138: at the end of phase three,
        !           139: the ratio of hosts speaking only the DDN protocol suite to hosts speaking at
        !           140: least the OSI protocol suite will be very low,
        !           141: and the requirement that hosts speak the DDN protocol suite can be lifted.
        !           142: It is critical to a smooth transition however,
        !           143: that this requirement not be lifted prematurely.
        !           144: Recall that,
        !           145: given the wide range of OSI applications now implemented
        !           146: and the availability of the software developed during phase one,
        !           147: it will be relatively inexpensive to maintain support of the DDN protocol
        !           148: suite.
        !           149: 
        !           150: \subsection    {Work To Date}
        !           151: We have implemented an ISO Development Environment (ISODE) at the Northrop
        !           152: Research and Technology Center.
        !           153: The version~1.0 distribution was released in September, {\oldstyle 1986}.
        !           154: Although ISODE is not proprietary,
        !           155: it was not placed in the public domain in order to include a ``hold
        !           156: harmless'' clause in the release.
        !           157: However, for all intents and purposes, the release is openly available.
        !           158: 
        !           159: ISODE currently runs on native Berkeley 4.2~\unix/,
        !           160: and on AT\&T SVR2~\unix/ with an Excelan \exos/ card
        !           161: (a board-level that implements the TCP).
        !           162: Current modules in the release include the TSAP described in the previous
        !           163: section, an OSI Basic Combined Subset (BCS) session,
        !           164: an ASN.1 encoding mechansism,
        !           165: a parser which takes an ASN.1 specification and produces a program fragment
        !           166: which recognizes the corresponding APDUs,
        !           167: and an implementation of the ECMA Remote Operations Services
        !           168: (ROS)\cite{ECMA.ROS}.
        !           169: 
        !           170: For information on receiving a copy of the ISODE distribution,
        !           171: consult Appendix~\ref{distribution}.

unix.superglobalmegacorp.com

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.