![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to nsap.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 / interim|
Return to nsap.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / interim |
1.1 root 1: \documentstyle [ucl-rn] {article}
2: \rnnumber{RN/89/13}
3: \author {S.E. Kille}
4: \date {February 1989}
5: \title {An interim approach to use of Network Addresses}
6: \begin {document}
7: \bibliographystyle {alpha}
8: \maketitle
9: \begin {abstract} The OSI Directory specifies an encoding of
10: Presentation Address, which utilises OSI Network Addresses as
11: defined in the OSI Network Layer standards \cite{CCITT.Directory}
12: \cite{ISO.Network.Naming}.
13: The OSI Directory, and any OSI application
14: utilising the OSI Directory must be able to deal with these Network
15: Addresses. Currently, most environments cannot cope with them. It
16: is not reasonable or desirable for groups wishing to investigate and
17: use OSI Applications in conjunction with the OSI Directory to have
18: to wait for the lower layers to sort out. This note is a proposal
19: for mechanisms to utilise Network Addresses in the context of
20: existing networks, and is agreed for use in the THORN and ISODE projects.
21: This document is also THORN document UCL-58.
22:
23: \end {abstract}
24:
25: \section {Scope}
26:
27: The Author is working on two projects with an immediate need for a
28: solution to this problem:
29:
30: \begin {itemize}
31: \item The THORN project, which is an Esprit Project building an OSI
32: Directory \cite{THORN.ECW88}.
33:
34: \item The ISODE project \cite{ISODE.Manual}, and in particular the
35: QUIPU directory being developed at UCL \cite{QUIPU.IFIP}.
36: \end {itemize}
37:
38: The initial aim of the note is to specify a solution for these two
39: projects. As full interworking between these systems is seen as
40: essential (to the author at least!), the same solution should be
41: adopted by both projects.
42:
43: It is likely that other groups will encounter the same problem, and
44: so it may be useful for this proposal to be adopted in a wider
45: forum.
46:
47: \begin {description}
48: \item[NOTE:] This document must be read in the context of ISO 8348 Addendum 2
49: \cite{ISO.Naming}.
50: \end {description}
51:
52:
53: \section {The Problem}
54:
55: When utilising the OSI Directory, the OSI location of an End System
56: will be determined by a Network Address, which is taken from a
57: Presentation Address, looked up in the OSI Directory.
58:
59: The ``real world'' of OSI (at least the one the author is in) consists of:
60:
61: \begin {itemize}
62: \item An international X.25 network, which routes on the basis of
63: X.121 addresses. By and large this is X.25(80), but some parts are
64: now X.25(84) and will carry Network Addresses as user data. OSI
65: Transport is mapped onto the variant of X.25 which is to hand.
66:
67: \item Large private X.25 networks, which do not have DNICs, but are
68: otherwise similar to the previous (in particular Janet).
69:
70: \item Isolated networks running Connection Oriented Network Service
71: (e.g., Pink Book Ethernets).
72:
73: \item Isolated networks running Connectionless Network Service
74: (e.g., MAP LANs).
75:
76: \item Isolated TCP/IP LANs, utilising RFC 1006 to
77: support the OSI Transport Service\cite{RFC-1006}.
78:
79: \item The DARPA/NSF Internet, also using RFC 1006.
80: \end {itemize}
81:
82: In general, these systems need to be interconnected by the
83: unfortunate mechanisms of transport bridging --- but this is another
84: story. It is hoped that the mechanisms described in this note will
85: reduce the need for Transport Bridging, and make more of these
86: networks behave as subnetworks (OSI Terminology).
87:
88: Where End Systems do have access to Network Service, there is no
89: general mechanism for Network Address to SNPA binding (local table
90: lookup is the norm).
91:
92: \section {The ``Right Solution''}
93:
94: Before diving into ugliness, it is worth noting briefly what the
95: intended solution is. Network Addresses are globally allocated, and
96: do not imply anything about routing or location. An End System is
97: attached to one or more subnetworks at Subnetwork Points of
98: Attachment (SNPAs). Intermediate Systems join subnetworks, again
99: being attached at SNPAs. Routing is achieved by repeated binding of
100: Network Address to SNPA (initially at the Originating End System,
101: and then at each Intermediate System). This binding is achieved by
102: use of a directory service\footnote{The OSI Directory is almost
103: certainly inappropriate for this function --- a special purpose
104: network directory is needed.}.
105:
106: The rest of this section is a polemic --- mainly to make the author
107: feel better. Network Addresses have been designed for general
108: purpose allocation. Whilst this is one important characteristic of
109: a Network Address, others have been entirely neglected. The
110: practicalities of routing and lookup in directory service appear to
111: have been ignored in the design. The issue of building the
112: mechanisms for routing are being discussed as some sort of
113: afterthought. This is sad, and it seems to the author that the
114: network address specification will need to be entirely rewritten
115: before large scale OSI can become a reality.
116:
117: \section {The General Approach Proposed}
118:
119: The means of connecting to a remote Application Entity is broadly as
120: follows.
121:
122: \begin {enumerate}
123: \item Look up the Application Entity in the OSI Directory to obtain
124: the Presentation Address \footnote{Strictly an Application Entity
125: should have only one Presentation Address. In practice it may have
126: several, and the network addresses of each Presentation Address
127: should be considered.}.
128:
129: \item Take each Network Address, and determine if it can be used
130: (and how).
131:
132: \item Determine an order of preference for the Network Addresses.
133:
134: \item Attempt to connect to one or more of the Network Addresses.
135: \end {enumerate}
136:
137: This note is concerned with the second step, and will probably have
138: implications on the third. The following mechanisms for Network
139: Address are discussed in this note:
140:
141: \begin {itemize}
142: \item X.121 form
143: \item A special encoding for networks which do not provide Network
144: Service.
145: \item Other forms
146: \end {itemize}
147:
148: \section {X.121 Form}
149:
150: In principle, the IDP is only an allocation mechanism, and has no
151: routing implications. However, due to the lack of a network
152: directory service, it is recommended that any End System with
153: Connection Oriented Network Service and access to the international
154: X.25 service uses X.121 form relative to its access point.
155: Allocation of DSP is a private issue.
156:
157: Conversely it is recommended that if an X.121 IDP form Network
158: Address is interpreted, then the X.121 address will provide a route (by
159: defining an SNPA on the international X.25 network).
160: There may be additional and perhaps preferable routes which can be
161: determined by private means.
162:
163: If the DSP is absent, the form should be interpreted as implying a mapping
164: of Transport onto X.25(80).
165:
166: \section {Requirements}
167:
168: The requirements for use of OSI over existing networks, when using the
169: OSI Directory are:
170:
171: \begin {enumerate}
172: \item The information for the layers below Transport must be
173: obtained from the Network Address. This is essential, because we
174: wish to use the OSI Directory in a standard manner, and the Network
175: Address is the information available.
176:
177: \item The Network Addresses must be globally unique, as they can be
178: looked up by anyone with access to the Directory.
179:
180: \item The Network Address should be allocated so that confusion with
181: a ``real'' Network Address is minimal.
182:
183: \item Network Addresses must be interpretable on the basis of a
184: well known information, or on information which can be obtained from
185: the (application level) OSI Directory.
186:
187: \item The identity of the network in question must be deduceable from
188: the Network Address
189:
190: \item All network specific addressing information (including the
191: SNPA) must be deducible
192: from the Network Address
193: \end {enumerate}
194:
195: \section {Proposal}
196:
197: The following approach is proposed.
198:
199: \begin {itemize}
200: \item A (sub)network is identified by the IDP and a {\em small} part of
201: the DSP.
202:
203: \item The remainder of the DSP encodes network specific information
204:
205: \item It is suggested that the following IDPs are not used:
206: \begin {itemize}
207: \item Local (the values must be globally unique)
208: \item X.121 (because it will be confused with real Network Addresses)
209: \item DCC (because it seems like a bad move)
210: \end {itemize}
211:
212: \item It is suggested that a Telex form IDP is used because:
213: \begin {itemize}
214: \item It gives the largest DSP
215: \item It is less likely than other forms to be used for ``real''
216: Network Addresses
217: \end {itemize}
218:
219: \end {itemize}
220:
221: The scope of the proposed encoding is where:
222:
223: \begin {itemize}
224: \item The value of the IDP is recognised
225: \item The encoding of the DSP is abstract decimal
226: \item The first two digits of the DSP are recognised
227: \end {itemize}
228:
229: In these cases, the IDP + 2 digit prefix identify a subnetwork in which the
230: value of the DSP is to be interpreted.
231:
232: \section {The DSP Encoding}
233:
234: It is proposed to use a decimal abstract encoding for the DSP. This
235: is a new encoding, as the only alternative on the table (ECMA 117)
236: \cite{ECMA.117},
237: is not entirely suitable. Use of a binary
238: encoding, with the DSP structured in ASN.1 would have been a very
239: attractive approach. However, it appears that there is insufficient
240: space in the Network Address for this to be feasible.
241:
242: The following structure is proposed:
243:
244: \begin {center}
245: \begin {tabular}{|l||c|c|}
246: \hline
247: Digit & 1-2 & 3-27 \\
248: \hline
249: Meaning & Prefix & Network Specific \\
250: \hline
251: \end {tabular}
252: \end {center}
253:
254: \begin {description}
255: \item [2 digits] Prefix. This allows for multiple usage of the same DSP, by
256: not consuming it all. It also allows for the DSP to be used with different
257: encodings.
258:
259: \item [Network Specific]
260:
261: The network specific allocation should be less than 20 digits if
262: this DSP structure is to be used with any IDI format. This is
263: increased to 27 for the Telex format.
264:
265:
266: \end {description}
267:
268: \subsection {X.25(80) Allocation}
269:
270: The IDP/Prefix identifies an X.25(80) subnetwork.
271: There is a need to represent a DTE Number, and optionally an X.25
272: Protocol ID or CUDF (many implementations require these due
273: to shortage of X.121 address space) in the DSP.
274: This is structured in one of two possible ways:
275:
276: \begin {center}
277: \begin {tabular}{|l||c|c|}
278: \hline
279: Digit & 1 & Remainder \\
280: \hline
281: Meaning & 0 & DTE \\
282: \hline
283: \end {tabular}
284: \end {center}
285:
286:
287: \begin {center}
288: \begin {tabular}{|l||c|c|c|c|}
289: \hline
290: Digit & 1 & 2 & 3 -- (n*3)+2 & Remainder \\
291: \hline
292: Meaning & 1 or 2 & n & PID or CUDF & DTE \\
293: \hline
294: \end {tabular}
295: \end {center}
296:
297: The network specific part is structured as follows:
298:
299: \begin {description}
300: \item [1] This has the following values
301: \begin {description}
302: \item [0] DTE only
303: \item [1] DTE + PID
304: \item [2] DTE + CUDF
305: \item [3-9] Reserved
306: \end {description}
307:
308: \item[2]
309:
310: The length of the PID/CUDF in octets
311:
312: \item [Remainder] The PID/CUDF takes as many digits as indicated by
313: 3 times octet 2, and the DTE is terminated by the end of the Network Address.
314: Each octet of the PID/CUDF is encoded as three decimal digits, representing
315: the decimal value of the octet.
316:
317: \item
318: \end {description}
319:
320: For example, the JANET DTE 000005111600 with ASCII CUDF ``12'' would be
321: encoded in the following way. The first lines describe the abstract
322: notation. Note that where the IDI is not of maximum length, that the
323: translation to concrete decimal is not mechanical
324:
325: \begin {center}
326: \begin {small}
327: \begin {tabular}{|l||c|c|c|c|c|c|}
328: \hline
329: Part & \multicolumn{2}{c|}{IDP} & \multicolumn{4}{c|}{DSP} \\
330: \hline
331: Component & AFI & IDI & Prefix & Dte+Cudf & Len & CUDF + DTE \\
332: \hline
333: Octet & & & 1-2 & 3 & 4 & 5-20 \\
334: \hline
335: Value & Telex & 007 28722 & 02 & 2 & 2 & 049050 000005111600 \\
336: \hline
337: \hline
338: Cncrt Decimal & 54 & 007 28722 & 02 & 2 & 2 & 049050 000005111600 \\
339: \hline
340: Cncrt Binary & 54 & 00 72 87 22 & 02 & \multicolumn{2}{c|}{22} & 04 90 50
341: 00 00 51 11 60 0f \\
342: \hline
343: \end {tabular}
344: \end {small}
345: \end {center}
346:
347: Note that concrete binary is representing octets in hexadecimal. This is
348: the syntax most likely to be used in practice.
349:
350: \subsection {TCP/IP (RFC 1006) Allocation}
351:
352:
353: The IDP and 2 digit prefix identifies a TCP/IP network here RFC 1006 is
354: applied.
355: It is necessary to use an IP Address, as there are insufficient bits
356: to fit in a domain. It is structured as follows:
357:
358: \begin {center}
359: \begin {tabular}{|l||c|c|c|}
360: \hline
361: Digit & 1-12 & 13-17 (optional) & 18-22 (optional) \\
362: \hline
363: Meaning & IP Address & port & Transport Set \\
364: \hline
365: \end {tabular}
366: \end {center}
367:
368:
369: For TCP/IP there shall be a 20 digit long network-specific part. First
370: 12 digits are for the IP address. The port number can be upto 65535, and
371: needs 5 digits (this is optional, and is defaulted as defined in RFC 1006).
372: Finally,
373: there is a third part to the address, which is defined here as
374: ``transport set''
375: that indicates what kind of IP-based transport protocols is used.
376: This is a decimal number from 0-65535 which is really a 16-bit flag
377: word. 1 is TCP, 2 is UDP. If the transport set is not there or
378: no bits are set, it means ``default'' which is TCP. This is
379: encoded in 5 digits.
380:
381:
382:
383: Note that RFC 986 is not appropriate \cite{RFC-986}, as this currently applies to a
384: different architecture (we are considering RFC 1006 here).
385:
386:
387: For example, the IP Address 10.0.0.6 with port 9 over UDP is
388: encoded as:
389:
390: \begin {center}
391: \begin {small}
392: \begin {tabular}{|l||c|c|c|c|c|c|}
393: \hline
394: Part & \multicolumn{2}{c|}{IDP} & \multicolumn{4}{c|}{DSP} \\
395: \hline
396: Component & AFI & IDI & Prefix & IP Address & Port & T Set \\
397: \hline
398: Octet & & & 1-2 & 3-14 & 15-19 & 20-24 \\
399: \hline
400: Value & Telex & 007 28722 & 03 & 010 000 000 006 & 00009 & 00002 \\
401: \hline
402: \hline
403: Concrete Decimal & 54 & 007 28722 & 03 & 010 000 000 006 & 00009 & 00002 \\
404: \hline
405: Concrete Binary & 54 & 00 72 87 22 & 03 & 01 00 00 00 00 06 & 00 00 9 & 0 00 02 \\
406: \hline
407: \end {tabular}
408: \end {small}
409: \end {center}
410:
411:
412: \section {Other Forms}
413:
414: Recognition of other forms of address is a local matter.
415:
416: \section {Transport Bridges}
417:
418: The provision of this form of Network Address encoding will
419: facilitate the transparent use of Transport Bridges. Whenever a
420: protocol is used which can carry the Network Address, this can be
421: used to contact a transport bridge as if it was the end system
422: \footnote{This suggests that it would be beneficial to extend RFC
423: 1006 to carry Network Addresses.}.
424: The hex (concrete) form of network address should be used.
425:
426: \section {Encoding}
427:
428: This document describes allocation of Network Addresses, with the DSP
429: considered in Abstract Decimal. The encoding of this for use in protocols
430: (typically as Concrete Binary) is
431: described in
432: ISO 8348 Addendum 2
433: \cite{ISO.Network.Naming}.
434:
435: \section {Conclusions}
436:
437: This is all pretty horrible, but there do not appear to be any
438: better choices.
439:
440: \section {References}
441:
442: \bibliography {../../../bib/sek}
443: \pagebreak
444: \appendix
445: \section {Some initial Allocations}
446:
447: This appendix gives some allocations for a few well known networks.
448: All are allocated on the basis of Telex numbers.
449:
450: \begin {center}
451: \begin {tabular}{|l| ll|}
452: \hline
453: \multicolumn{1}{|c}{Net} &
454: \multicolumn{1}{c}{Telex} &
455: \multicolumn{1}{c|}{Prefix} \\
456: \hline
457: International X.25 & 007 28722 & 01 \\
458: Janet & 007 28722 & 02 \\
459: Darpa/NSF Internet & 007 28722 & 03 \\
460: \hline
461: \end {tabular}
462: \end {center}
463:
464: The international X.25 allocation is only used where a CUDF or PID is needed.
465: In other cases, an X.121 form Network Address with no DSP may be used.
466:
467: \end {document}
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.