|
|
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}.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.