Network Working Group S.E. Kille
INTERNET--DRAFT University College London
January 1991
An interim approach to use of Network Addresses
Status of this Memo
The OSI Directory specifies an encoding of Presentation Address,
which utilises OSI Network Addresses as defined in the OSI Network
Layer standards [CCI88] [ISO87a]. The OSI Directory, and any OSI
application utilising the OSI Directory must be able to deal with
these Network Addresses. Currently, most environments cannot cope
with them. It is not reasonable or desirable for groups wishing to
investigate and use OSI Applications in conjunction with the OSI
Directory to have to wait for the lower layers to sort out. This
note is a proposal for mechanisms to utilise Network Addresses.
This draft document will be submitted to the RFC editor as a
protocol specification. Distribution of this memo is unlimited.
Please send comments to the author or to the discussion group
<osi-ds@CS.UCL.AC.UK>.
INTERNET--DRAFT Interim Network Addresses January 1991
1 Introduction
The OSI Directory specifies an encoding of Presentation Address,
which utilises OSI Network Addresses as defined in the OSI Network
Layer standards [CCI88] [ISO87a]. The OSI Directory, and any OSI
application utilising the OSI Directory must be able to deal with
these Network Addresses. Currently, most environments cannot cope
with them. It is not reasonable or desirable for groups wishing to
investigate and use OSI Applications in conjunction with the OSI
Directory to have to wait for the lower layers to sort out. This
note is a proposal for mechanisms to utilise Network Addresses. It
defines, in Appendix A, some allocated values.
This document must be read in the context of ISO 8348 Addendum 2
[ISO87b]. It will not be meaningful on its own.
2 Historical Note
This document was originally published as UCL Research Note
RN/89/13 and as a project THORN internal document [Kil89]. It was
devised in response to two projects which faced this requirement,
and was agreed as a common approach. The projects were:
o The THORN project, which is an Esprit Project building an OSI
Directory [SA88].
o The ISODE project [Ros90], and in particular the QUIPU
directory being developed at UCL [Kil88].
The proposal has been implemented, and the viablity of the solution
demonstrated.
3 The Problem
When utilising the OSI Directory, the OSI location of an End System
will be determined by a Network Address, which is taken from a
Presentation Address, looked up in the OSI Directory.
The ``real world'' of OSI (at least the one the author is in)
consists of:
o An international X.25 network, which routes on the basis of
Kille Page 1
INTERNET--DRAFT Interim Network Addresses January 1991
X.121 addresses. By and large this is X.25(80), but some parts
are now X.25(84) and will carry Network Addresses as user data.
OSI Transport is mapped onto the variant of X.25 which is to
hand.
o Large private X.25 networks, which do not have DNICs, but are
otherwise similar to the previous (in particular Janet).
o Isolated networks running Connection Oriented Network Service
(e.g., Pink Book Ethernets).
o Isolated networks running Connectionless Network Service (e.g.,
MAP LANs).
o Isolated TCP/IP LANs, utilising RFC 1006 to support the OSI
Transport Service[RC87].
o The DARPA/NSF Internet, also using RFC 1006.
In general, these systems need to be interconnected by the
unfortunate mechanisms of transport bridging --- but this is
another story. It is hoped that the mechanisms described in this
note will reduce the need for Transport Bridging, and make more of
these networks behave as subnetworks (OSI Terminology).
Where End Systems do have access to Network Service, there is no
general mechanism for Network Address to SNPA binding (local table
lookup is the norm)(1).
4 The ``Right Solution''
Before diving into ugliness, it is worth noting briefly what the
intended solution is. Network Addresses are globally allocated,
and do not imply anything about routing or location. An End System
is attached to one or more subnetworks at Subnetwork Points of
Attachment (SNPAs). Intermediate Systems join subnetworks, again
being attached at SNPAs. Routing is achieved by repeated binding
of Network Address to SNPA (initially at the Originating End
System, and then at each Intermediate System). This binding is
___________________________
(1)The current ES-IS work does solve some aspects of this, but it
is only applicable to CLNS and makes restrictions as to how Network
Addresses are structured. These are sensible restrictions, but the
mechanism is no longer general purpose.
Kille Page 2
INTERNET--DRAFT Interim Network Addresses January 1991
achieved by use of a directory service(2).
The rest of this section is a polemic --- mainly to make the author
feel better. Network Addresses have been designed for general
purpose allocation. Whilst this is one important characteristic of
a Network Address, others have been entirely neglected. The
practicalities of routing and lookup in directory service appear to
have been ignored in the design. The issue of building the
mechanisms for routing are being discussed as some sort of
afterthought. This is sad, and it seems to the author that the
network address specification will need to be entirely rewritten
before large scale OSI can become a reality(3).
5 The General Approach Proposed
The means of connecting to a remote Application Entity is broadly
as follows.
1. Look up the Application Entity in the OSI Directory to obtain
the Presentation Address (4).
2. Extract each Network Address from the Presentation Address, and
determine if it can be used (and how).
3. Determine an order of preference for the Network Addresses.
4. Attempt to connect to one or more of the Network Addresses.
This note is concerned with the second step, and will probably have
implications on the third. The following mechanisms for Network
Address are discussed in this note:
__o_X.121_form_____________
(2)The OSI Directory is almost certainly inappropriate for this
function --- a special purpose network directory is needed.
(3)Restrictions on use of network addresses within the ES-IS work
may be an initial basis for this rewrite.
(4)Strictly an Application Entity should have only one
Presentation Address. In practice
it may have several, and the network addresses of each Presentation
Address should be considered.
Kille Page 3
INTERNET--DRAFT Interim Network Addresses January 1991
o A special encoding for networks which do not provide Network
Service.
o Other forms
6 X.121 Form
In principle, the IDP is only an allocation mechanism, and has no
routing implications. However, due to the lack of a network
directory service, it is recommended that any End System with
Connection Oriented Network Service and access to the international
X.25 service uses X.121 form relative to its access point.
Allocation of DSP (Domain Specific Part) is a private issue.
Conversely it is recommended that if an X.121 IDP (Initial Domain
Part) form Network Address is interpreted, then the X.121 address
will provide a route (by defining an SNPA on the international X.25
network). There may be additional and perhaps preferable routes
which can be determined by private means.
If the DSP is absent, the form should be interpreted as implying a
mapping of Transport onto X.25(80).
7 Requirements
The requirements for use of OSI over existing networks not
supporting CONS or CLNS, when using the OSI Directory are:
1. The information for the layers below Transport must be obtained
from the Network Address. This is essential, because we wish
to use the OSI Directory in a standard manner, and the Network
Address is the information available.
2. The Network Addresses must be globally unique, as they can be
looked up by anyone with access to the Directory.
3. The Network Address should be allocated so that confusion with
a ``real'' Network Address (i.e., one which defines an NSAP
using CONS or CLNS as opposed to X.25(80) or RFC 1006) is
minimal.
4. Network Addresses must be interpretable on the basis of a well
known information, or on information which can be obtained from
the (application level) OSI Directory.
Kille Page 4
INTERNET--DRAFT Interim Network Addresses January 1991
5. The identity of the network in question must be deduceable from
the Network Address
6. All network specific addressing information (including the
SNPA) must be deducible from the Network Address
8 Proposal
The following approach is proposed.
o A (sub)network is identified by the IDP and a small part of the
DSP.
o The remainder of the DSP encodes network specific information
o It is suggested that the following IDPs are not used:
-- Local (the values must be globally unique)
-- X.121 (because it will be confused with real Network
Addresses)
-- DCC and ICD (because they are very likely to be confused
with real Network Addresses)
o It is suggested that a Telex form IDP is used because:
-- It gives the largest DSP
-- It is less likely than other forms to be used for ``real''
Network Addresses
The scope of the proposed encoding is where:
o The value of the IDP is recognised
o The encoding of the DSP is abstract decimal
o The first two digits of the DSP are recognised
In these cases, the IDP + 2 digit prefix identify a subnetwork in
which the value of the DSP is to be interpreted.
Kille Page 5
INTERNET--DRAFT Interim Network Addresses January 1991
9 The DSP Encoding
It is proposed to use a decimal abstract encoding for the DSP. This
is a new encoding, as the only alternative on the table (ECMA 117)
[TC386], is not entirely suitable. Use of a binary encoding, with
the DSP structured in ASN.1 would have been a very attractive
approach. However, it appears that there is insufficient space in
the Network Address for this to be feasible.
The following structure is proposed:
____________________________________
|_Digit___|_|1-2___|_____3-27_______|
|_Meaning_|P|refix_|Network_Specific_|
2 digits Prefix. This allows for multiple usage of the same DSP,
by not consuming it all. It also allows for the DSP to be used
with different encodings.
Network Specific The network specific allocation should be less
than 20 digits if this DSP structure is to be used with any IDI
format. This is increased to 27 for the Telex format.
9.1 X.25(80) Allocation
The IDP/Prefix identifies an X.25(80) subnetwork. There is a need
to represent a DTE Number, and optionally an X.25 Protocol ID or
CUDF (many implementations require these due to shortage of X.121
address space) in the DSP. This is structured in one of two
possible ways:
________________________
|_Digit___|1||Remainder_|
|_Meaning_|0||___DTE____|
____________________________________________________________
|_Digit___|_|1____|_______2________|3_--_(n*3)+2_|Remainder|_
|_Meaning_|_|Type__|PID/CUDF_Length_|_PID/CUDF___|___DTE___|_
|_Values__|1|or_2_|_______n________|_____________|_________|_
The network specific part is structured as follows:
Kille Page 6
INTERNET--DRAFT Interim Network Addresses January 1991
Type This has the following values
0 DTE only
1 DTE + PID
2 DTE + CUDF
3-9 Reserved
PID/CUDF Length The length of the PID/CUDF in octets
PID/CUDF The PID/CUDF takes as many digits as indicated by 3 times
octet 2. Each octet of the PID/CUDF is encoded as three
decimal digits, representing the decimal value of the octet.
DTE The DTE is terminated by the end of the Network Address.
For example, the JANET DTE 000005111600 with ASCII CUDF ``12''
would be encoded in the following way. The first lines describe
the abstract notation. Note that where the IDI is not of maximum
length, that the translation to concrete decimal is not mechanical
______________________________________________________________________________________
|Part__________|_|_____IDP_________|_______________________DSP_______________________|_
|Component_____|_|AFI__|___IDI_____|Prefix_|Dte+Cudf_|Len|________CUDF_+_DTE_________|_
|Octet_________|_|____|____________|_1-2___|___3_____|_4_|___________5-20____________|_
|Value_________|T|elex_|007_28722__|__02___|___2_____|_2_|____049050_000005111600____|__
|Cncrt_Decimal_|_|54___|007_28722__|__02___|___2_____|_2_|____049050_000005111600____|_
|Cncrt_Binary__|_|54___|00_72_87_22_|_02___|_____22______|04_90_50_00_00_51_11_60_0f_|_
Note that concrete binary is representing octets in hexadecimal.
This is the syntax most likely to be used in practice. The CUDF is
represented by two octets 049 and 050 (decimal), which map to six
digits.
9.2 TCP/IP (RFC 1006) Allocation
The IDP and 2 digit prefix identifies a TCP/IP network where RFC
1006 is applied. It is necessary to use an IP Address, as there
are insufficient bits to fit in a domain. It is structured as
follows:
Kille Page 7
INTERNET--DRAFT Interim Network Addresses January 1991
__________________________________________________________
|_Digit___|_|_1-12____|13-17_(optional)_|18-22_(optional)_|
|_Meaning_|I|P_Address_|_____port_______|_Transport_Set___|
For TCP/IP there shall be a 20 digit long network-specific part.
First 12 digits are for the IP address. The port number can be
upto 65535, and needs 5 digits (this is optional, and is defaulted
as defined in RFC 1006). Finally, there is a third part to the
address, which is defined here as ``transport set'' that indicates
what kind of IP-based transport protocols is used. This is a
decimal number from 0-65535 which is really a 16-bit flag word. 1
is TCP, 2 is UDP. If the transport set is not there or no bits are
set, it means ``default'' which is TCP. This is encoded in 5
digits.
Note that RFC 986 is not appropriate [CB87], as this currently
applies to a different architecture (we are considering RFC 1006
here).
For example, the IP Address 10.0.0.6 with port 9 over UDP is
encoded as:
___________________________________________________________________________________
|Part_____________|_|_____IDP_________|____________________DSP____________________|_
|Component________|_|AFI__|___IDI_____|Prefix_|___IP_Address_____|_Port__|_T_Set__|_
|Octet____________|_|____|____________|_1-2___|______3-14________|_15-19_|_20-24__|_
|Value____________|T|elex_|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__|__
|Concrete_Decimal_|_|54___|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__|_
|Concrete_Binary__|_|54___|00_72_87_22_|_03___|01_00_00_00_00_06_|00_00_9|0_00_02_|_
10 Other Forms
Recognition of other forms of address is a local matter.
11 Transport Bridges
The provision of this form of Network Address encoding will
facilitate the transparent use of Transport Bridges. Whenever a
protocol is used which can carry the Network Address, this can be
used to contact a transport bridge as if it was the end system (5).
___________________________
(5)This suggests that it would be beneficial to extend RFC 1006 to
carry Network Addresses.
Kille Page 8
INTERNET--DRAFT Interim Network Addresses January 1991
The hex (concrete) form of network address should be used.
12 Encoding
This document describes allocation of Network Addresses, with the
DSP considered in Abstract Decimal. The encoding of this for use
in protocols (typically as Concrete Binary) is described in ISO
8348 Addendum 2 [ISO87a].
13 Conclusions
This is all pretty horrible, but there do not appear to be any
better choices.
14 References
References
[CB87] R. Callon and H. Braun. Guidelines for the use of
internet-ip addresses in the iso connectionless-mode
network protocol. Request for Comments 986, DDN Network
Information Center, SRI International, November 1987.
[CCI88] The directory - overview of concepts, models and services,
December 1988. CCITT X.500 Series Recommendations.
[ISO87a] Information processing systems - data communications -
network services definition: Addendum 2 - network layer
addressing, March 1987. ISO TC 97/SC 6.
[ISO87b] ISO DIS 7498-3 on naming and addressing, May 1987.
ISO/IEC/JTC-1/SC 21.
[Kil88] S.E. Kille. The QUIPU directory service. In IFIP WG 6.5
Conference on Message Handling Systems and Distributed
Applications, pages 173--186. North Holland Publishing,
October 1988.
[Kil89] S.E. Kille. An interim approach to use of network
addresses. Research Note RN/89/13, Department of Computer
Science, University College London, February 1989.
Internet Draft: DRAFT-UCL-KILLE-NETWORKADDRESSES-00.PS.1.
[RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport
Services on top of the TCP. Request for Comments 1006,
DDN Network Information Center, SRI International, May
1987.
Kille Page 9
INTERNET--DRAFT Interim Network Addresses January 1991
[Ros90] M.T. Rose. The ISO development environment: User's
manual (version 6.0), January 1990.
[SA88] F. Sirovich and M. Antonellini. The THORN X.500
distributed directory environment. In Esprit Conference
Week, November 1988.
[TC386] ECMA TC32. Domain specific part of network layer
addresses. ECMA Standard 117, ECMA, June 1986.
15 Security Considerations
Security considerations are not discussed in this INTERNET--DRAFT .
16 Author's Address
Steve Kille
Department of Computer Science
University College London
Gower Street
WC1E 6BT
England
Phone: +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.UK
Kille Page 10
INTERNET--DRAFT Interim Network Addresses January 1991
A Allocations for well known networks
A.1 Values
This appendix gives an allocation for three well known networks.
All are allocated on the basis of the supposed Telex number
00728722. This might be the University College London Telex
number, dependent on whether the UK Telex code is 007, 51, or 051.
This number is being used in pilot operations, and so is retained
here.
_______________________________________
|________Net___________Telex___Prefix_|_
| International X.25|007 28722 01 |
| Janet |007 28722 02 |
|_Darpa/NSF_Internet|007_28722_03_____|_
The international X.25 allocation is only used where a CUDF or PID
is needed. In other cases, an X.121 form Network Address with no
DSP should be used.
A.2 Delegation
The values assigned in this document are now in widespread use. As
the number is arbitrary, it would be undesirable to change the
numbers without a sound technical reason. However, it is important
to guarantee that the numbers are stable.
This Internet Draft comits UCL not to reassign the portions of the
number space allocated here.
The DARPA/NSF Internet space (Prefix 03) is delegated to
appropriate Internet body.
Kille Page 11