RFC 1277 (rfc1277) - Page 2 of 12
Encoding Network Addresses to Support Operation over Non-OSI Lower Layers
Alternative Format: Original Text Document
RFC 1277 Encoding Network Addresses November 1991
2 Problem Statement
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.
OSI applications are currently operated over the following lower
layers.
o An international X.25 network, which routes on the basis of 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 available.
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 The Connectionless Network Service Protocol (CLNP) pilot,
currently taking place in the NSFNet and NORDUNet communities.
o Isolated TCP/IP LANs, utilising RFC 1006 to support the OSI
Transport Service[RC87].
o The DARPA/NSF Internet, using RFC 1006.
In general, these systems need to be interconnected by the use of
transport bridging or application relaying. Operation of transport
bridges causes a number of problems which it is desirable to avoid.
Only some applications can support relaying, and this is not always
satisfactory.
2.1 The ``Right Solution''
It is worth noting briefly what the intended (OSI) solution is. There
is a single global network service. Network Addresses are globally
allocated, and do not imply anything about routing or location. An
Hardcastle-Kille