As per Relevance of the word addresses, we have this rfc below:
Network Working Group S.E. Hardcastle-
Requests for Comments 1277 University College
November 1991
Encoding Network
to support operation over non-OSI lower
Status of this
This RFC specifies an IAB standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the ``
Official Protocol Standards'' for the standardization state
status of this protocol. Distribution of this memo is unlimited
The OSI Directory specifies an encoding of Presentation Address
which utilises OSI Network Addresses as defined in the
Network Layer standards [CCI88] [ISO87a]. The OSI Directory,
any OSI application utilising the OSI Directory must be able
these Network Addresses to identify end systems. Currently,
applications are often run over lower layers other than the
Network Service. It is neither reasonable nor desirable
groups wishing to investigate and use OSI Applications
conjunction with the OSI Directory to be dependent on a
OSI Network Service. This document defines a new network
format, and rules for using some existing network
formats. The scope of this document is
1. Any TCP/IP network supporting COTS using RFC 1006.
2. Any mapping of COTS onto X.25 (usually X.25(80)), where X.25
not used to provide CONS (i.e., only DTE and not Network
is carried).
The approach could also be extended to use with other means
providing COTS (or CLTS). It is not appropriate for use
CONS or CLNS is used to provide COTS (or CLTS).
RFC 1277 Encoding Network Addresses November 1991
1
The OSI Directory specifies an encoding of Presentation Address,
utilises OSI Network Addresses as defined in the OSI Network
standards [CCI88] [ISO87a]. The OSI Directory, and any
application utilising the OSI Directory must be able use these
Addresses to identify end systems
Currently, OSI applications are often run over lower layers other
the OSI Network Service. It is neither reasonable nor desirable
groups wishing to investigate and use OSI Applications in
with the OSI Directory to be dependent on a global OSI
Service. This RFCdefines mechanisms to encode addressing
within Network Addresses, in order to support this type of working
In particular, support is defined for RFC 1006 mapping of COTS
TCP/IP and COTS mapped onto X.25(1980) [RC87, CCI80].
Where an OSI application is run over CLNS on the internet, the
Guidelines of RFC 1237 should be followed [CGC91].
This document must be read in the context of ISO 8348 Addendum 2
[ISO87b]. It will not be meaningful on its own
1.1 Historical
This document was originally published as UCL Research Note RN/89/13
and as a project THORN internal document [Kil89]. It was devised
response to two projects which faced this requirement, and was
as a common approach. The projects were
o The THORN project, which is an Esprit Project building an
Directory [SA88].
o The ISODE project [Ros90], and in particular the QUIPU
being developed at UCL [Kil88].
The proposal has been implemented, and the viability of the
demonstrated
Hardcastle-Kille Page 1
RFC 1277 Encoding Network Addresses November 1991
2 Problem
When utilising the OSI Directory, the OSI location of an End
will be determined by a Network Address, which is taken from
Presentation Address, looked up in the OSI Directory
OSI applications are currently operated over the following
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
X.25(84) and will carry Network Addresses as user data.
Transport is mapped onto the variant of X.25 which is available
o Large private X.25 networks, which do not have DNICs, but
otherwise similar to the previous (in particular Janet).
o Isolated networks running Connection Oriented Network
(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
Transport Service[RC87].
o The DARPA/NSF Internet, using RFC 1006.
In general, these systems need to be interconnected by the use
transport bridging or application relaying. Operation of
bridges causes a number of problems which it is desirable to avoid
Only some applications can support relaying, and this is not
satisfactory
2.1 The ``Right Solution''
It is worth noting briefly what the intended (OSI) solution is.
is a single global network service. Network Addresses are
allocated, and do not imply anything about routing or location.
Hardcastle-Kille Page 2
RFC 1277 Encoding Network Addresses November 1991
End System is attached to one or more subnetworks at Subnetwork
of Attachment (SNPAs). Intermediate Systems join subnetworks,
being attached at SNPAs. Routing is achieved by repeated binding
Network Address to SNPA (initially at the Originating End System,
then at each Intermediate System). This binding is achieved
network level routing mechanisms
This can only work in a pure OSI environment with a single
network service (either connectionless or connection-oriented), and
is not sufficient for the problem being addressed by this note
2.2 General
This section describes the use of network addresses, and gives
functional overview of the problem being takceled. The means
connecting to a remote Application Entity is broadly as follows
1. Look up the Application Entity in the OSI Directory to obtain
Presentation Address 1.
2. Extract each Network Address from the Presentation Address,
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
implications on the third. There is currently no directory service
provide step 2, and so this (interim) approach must be algorithmic
All addressing information required for the network must be
from the network address
This note describes the use of Network Addresses for networks which
not provide the OSI Network Service (CLNS or CONS), and
constraints on the use of X.121 form network addresses when used
an OSI Network Service. The following types of Network Address
discussed in this note
----------------------------
1. Strictly an Application Entity should have only
Presentation Address. In practice it may have several, and
network addresses of each Presentation Address should be considered
Hardcastle-Kille Page 3
RFC 1277 Encoding Network Addresses November 1991
o Use of X.121 form Network Addresses
o A special encoding of Telex form Network Addresses
3 Network addresses with X.121
This note defines an approach for use of network addresses with
X.121 AFI
The IDP of network addresses is used to allow worldwide
of the NSAP address space. As such, not all values of the IDP will
practice have topological significance (which implies that in
cases the IDP will not be sufficient for network layer routing).
However, it is recommended that any End System using the
Oriented Network Service and with access to the international X.25
service uses the X.121 form of NSAP address relative to its
point. This allows routing across the worldwide X.25 based
data networks to be based on the X.121 addresses. Allocation of
(Domain Specific Part) within this form of address is a private issue
The IDP is primarily an allocation mechanism, and the user (
system) cannot in principle assume any implied routing. However,
to the lack of a network directory service, it is recommended that
End System with Connection Oriented Network Service and access to
international X.25 service uses X.121 form relative to its
point. Allocation of DSP (Domain Specific Part) is a private issue
Conversely it is recommended that if an X.121 IDP (Initial
Part) form Network Address is interpreted, then the X.121 address
provide a route (by defining an SNPA on the international X.25
network). There may be additional and perhaps preferable routes
can be determined by private means
If the DSP is absent, the form should be interpreted as implying
mapping of Transport onto X.25(80).
4 New Network Address
This section defines a new network address format. The scope of
format is currently
1. Any TCP/IP network supporting COTS using RFC 1006.
Hardcastle-Kille Page 4
RFC 1277 Encoding Network Addresses November 1991
2. Any mapping of COTS onto X.25 (usually X.25(80)), where X.25
not used to provide CONS (i.e., only DTE and not Network
is carried), except where the international X.25 service is
and no PID or CUDF is required
These exceptions are the cases which are handled by use of X.121
AFI (Section 3). The intention is to use the X.121 AFI
possible, and the formats defined in this section are for
remaining cases
The approach could also be extended to use with other means
providing COTS (or CLTS). It is not appropriate for use where CONS
CLNS is used to provide COTS (or CLTS).
4.1
The requirements for use of OSI over existing networks not
CONS or CLNS, when using the OSI Directory are
1. The information for the layers below Transport must be
from the Network Address. This is essential, because we wish
use the OSI Directory in a standard manner, and the
Address is the information available
2. The Network Addresses must be globally unique, as they can
looked up by anyone with access to the Directory
3. The Network Address should be allocated so that confusion with
``real'' Network Address (i.e., one which defines an NSAP
CONS or CLNS as opposed to X.25(80) or RFC 1006) is unlikely
4. Network Addresses must be interpretable on the basis of a
known information, or on information which can be obtained
the (application level) OSI Directory. (This RFConly uses
known information).
5. The identity of the network in question must be deducible from
Network
6. All network specific addressing information (including the SNPA
must be deducible from the Network
Hardcastle-Kille Page 5
RFC 1277 Encoding Network Addresses November 1991
4.2 IDP
The IDP is used with Telex AFI. The Telex AFI is used because
o It gives the largest
o It is less likely than other forms to be used for ``real''
The following AFIs might have been chosen, but are not used for
reasons given
o Local (the values must be globally unique
o X.121 (because it may be confused with other uses of OSI
addresses
o DCC and ICD (because it may be confused with other uses of
network addresses
The IDI should be assigned in a manner appropriate to the use of
encoding. For example, for operation on a private network within
organisation, the telex number of that organisation would be a
choice. Some well known networks are given assignments in Appendix A
4.3 The DSP
The network address is used as follows
o A (sub)network is identified by the IDP and a small part of
DSP
o The remainder of the DSP encodes network specific
The DSP format is now defined. The top level format is independent
the means used to provde COTS. Two formats for the remainder of
DSP are then defined, for specific means of providing COTS
A decimal abstract encoding is defined for the DSP. The ECMA 117
format might have been used, but it is not suitable. [TC386]. Use
a binary encoding, with the DSP structured in ASN.1 would have been
Hardcastle-Kille Page 6
RFC 1277 Encoding Network Addresses November 1991
very attractive approach. However, there is insufficient space in
Network Address for this to be feasible
The following structure is defined
____________________________________
|_Digit___||1-2__|______3-27_______|_
|_Meaning_||PrefixN|etwork_Specific_|
2 digits Prefix. This allows for multiple usage of the same DSP,
not consuming it all. It also allows for the DSP to be used
different encodings
Network Specific The network specific allocation should be less
20 digits if this DSP structure is to be used with any IDI format
This is increased to 27 for the Telex format
The IDP + 2 digit prefix identify a subnetwork in which the value
the remainder of the DSP (Network Specific Part) is to be interpreted
4.4 X.25(80) Network Specific
The IDP/Prefix identifies an X.25(80) subnetwork. There is a need
represent a DTE Number, and optionally an X.25 Protocol ID or
(many implementations require these due to shortage of X.121
space) in the DSP. This is structured in one of two possible ways
________________________
|_Digit___||1R|emainder_|
|_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
Type This has the following
0 DTE
1 DTE +
Hardcastle-Kille Page 7
RFC 1277 Encoding Network Addresses November 1991
2 DTE +
3-9
PID/CUDF Length The length of the PID/CUDF in
PID/CUDF The PID/CUDF takes as many digits as indicated by 3
octet 2. Each octet of the PID/CUDF is encoded as three
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''
be encoded in the following way. The first lines describe
abstract notation. Note that where the IDI is not of maximum length
that the translation to concrete decimal is not
_______________________________________________________________________________
|Part___|_|_____IDP_________|_______________________DSP_______________________|_
|Comp___|_|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____|__
|Ct_Dec_|_|54___|007_28722__|__02___|___2_____|_2_|____049050_000005111600____|_
|Ct_Bin_|_|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.
is the syntax most likely to be used in practice. The CUDF
represented by two octets 049 and 050 (decimal), which map to
digits
4.5 TCP/IP (RFC 1006) Network Specific
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
insufficient bits to fit in a domain. It is structured as follows
__________________________________________________________
|_Digit___||_1-12____|13-17_(optional)_|18-22_(optional)_|_
|_Meaning_||IP_Address_|____port_______|__Transport_Set__|_
Hardcastle-Kille Page 8
RFC 1277 Encoding Network Addresses November 1991
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 up
65535, and needs 5 digits (this is optional, and is defaulted
defined in RFC 1006). Finally, there is a third part to the address
which is defined here as ``transport set'' that indicates what kind
IP-based transport protocols is used. This is a decimal number
0-65535 which is really a 16-bit flag word. 1 is TCP, 2 is UDP
Further values of this code are assigned by the IANA. If the
set is not there or no bits are set, it means ``default'' which
TCP. This is encoded in 5 digits
For example, the IP Address 10.0.0.6 with port 9 over UDP is
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__|__
|Cncrt_Dec_|_|54___|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__|_
|Cncrt_Bin_|_|54___|00_72_87_22_|_03___|01_00_00_00_00_06_|00_00_9|0_00_02_|_
5
This document describes allocation of Network Addresses, with the
considered in Abstract Decimal. The encoding of this for use
protocols (typically as Concrete Binary) is described in ISO 8348
Addendum 2 [ISO87a].
6
[CCI80] CCITT. Recommendation X.25, interface between DTE and
for packet mode terminals, 1980.
[CCI88] The Directory --- overview of concepts, models and services
December 1988. CCITT X.500 Series Recommendations
[CGC91] R. Colella, E. Gardner, and R. Callon. Guidelines for
NSAP Allocation in the Internet. Request for Comments 1237,
Hardcastle-Kille Page 9
RFC 1277 Encoding Network Addresses November 1991
NIST, July 1991.
[ISO87a] Information processing systems - data communications -
network services definition: Addendum 2 - network
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
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.
[RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport
on top of the TCP. Request for Comments 1006,
Corporation Technology Center, May 1987.
[Ros90] M.T. Rose. The ISO development environment: User's
(version 6.0), January 1990.
[SA88] F. Sirovich and M. Antonellini. The THORN X.500
directory environment. In Esprit Conference Week,
1988.
[TC386] ECMA TC32. Domain specific part of network layer addresses
ECMA Standard 117, ECMA, June 1986.
7 Security
Security considerations are not discussed in this memo
8 Author's
Steve Hardcastle-
Department of Computer
University College
Hardcastle-Kille Page 10
RFC 1277 Encoding Network Addresses November 1991
Gower
WC1E 6
Phone: +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.
Hardcastle-Kille Page 11
RFC 1277 Encoding Network Addresses November 1991
A Allocations for well known
A.1
This appendix gives an allocation for three well known networks.
are allocated on the basis of the supposed Telex number 00728722.
This number is being used in pilot operations, and so is
here
_______________________________________
|_________Net__________Telex____Prefix_|
| International X.25 |007 28722 01 |
| Janet |007 28722 02 |
| Darpa/NSF Internet |007 28722 03 |
|_IXI________________|007_28722_06_____|
The international X.25 allocation is only used where a CUDF or PID
needed. In other cases, an X.121 form Network Address with no
should be used
A.2
The values assigned in this document are now in widespread use.
the number is arbitrary, it would be undesirable to change the
without a sound technical reason. However, it is important
guarantee that the numbers are stable
This Internet Draft commits UCL not to reassign the portions of
number space allocated here
The DARPA/NSF Internet space (Prefix 03) is delegated to the IANA
Hardcastle-Kille Page 12
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
