![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to section4.tex CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / cn-isdn|
Return to section4.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / cn-isdn |
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.