Return to nsap.tex CVS log

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

Annotation of 43BSDReno/contrib/isode-beta/doc/interim/nsap.tex, revision 1.1

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.