As per Relevance of the word specific, we have this rfc below:
Network Working Group R.
Request for Comments: 1069
Obsoletes: RFC 986 H.W.
February 1989
Guidelines for the use of Internet-IP addresses in
ISO Connectionless-Mode Network
Status of This
This RFC suggests an addressing scheme for use with the
Connectionless Network Protocol (CLNP) in the Internet. This is
solution to one of the problems inherent in the use of "ISO-grams"
the Internet. This RFC suggests a proposed protocol for the
community, and requests discussion and suggestions for improvements
Distribution of this memo is unlimited
This memo is a revision of RFC 986. Changes were made in order
allow the addressing used in the CLNP in the Internet to
potentially useful for routing in the context of new inter-
intra-domain routing protocols, and in the context of large
of networks and routing domains. The addressing scheme proposed
this RFC allows individual routing domains to make use of
routing algorithms utilizing a variety of addressing formats,
still providing for a common addressing approach for use by inter
domain routing. These features are important due to the rapid
currently being experienced in the Internet
1.
The data communications protocols currently emerging out of
international standardization efforts warrant an early
into the existing extensive Internet network infrastructure. The
possible approaches are a top-down one, where ISO applications
FTAM, X.400 and VTP are integrated on top of the transport
of the IP protocol suite, or a bottom-up approach where the whole
tower gets integrated without merging the two suites. The bottom-
approach may make use of the fact that the ISO-CLNP and the IP
very similar in function. This implies that it is reasonable
implement a multiprotocol function in some or all of the
gateways (potentially including part or all of the
environment). The result would be that at least large portions
the Internet, in particular the backbones, can become usable for
implementations of the ISO protocol stack
A major problem with this approach is that there are open issues
Callon & Braun [Page 1]
RFC 1069 IP ISO Addressing February 1989
regard to the ISO addressing within the CLNP. In particular, the
network layer addressing standard allows a great deal of
in the assignment of addresses, and a particular address format
be chosen. A further problem is the need for implementation
integration of routing facilities for the ISO-compatible subset
the Internet environment
This paper proposed to use addresses which are considerably
flexible than the addresses used in the current IP
environment. This flexibility is necessary in order to allow
routing domains to base their internal routing protocol on
derived from the current IP addresses, to allow other routing
to base routing on addresses in accordance to the intra-
routing protocol being developed by ANSI and ISO [6], and to
generality for a future inter-domain routing protocol
The addressing scheme proposed here makes use of the concept
"routing domains" as used in ANSI and ISO. This concept is
to, but not identical with, the concept of "Autonomous System"
in the Internet. Routing domains include a combination of gateways
networks, and end systems (not just gateways), and routing
boundaries may be used to define associated access control and
routing constraints. Like autonomous systems, routing domains may
assumed to be topologically contiguous. There is no a priori
why routing domains assigned for use with the ISO IP need to have
particular relation with existing autonomous systems which have
assigned for use with the IP. The assignment of specific
domain identifiers is an "assigned numbers" function which
necessary for use of the ISO IP in the Internet, but is beyond
scope of this document
It is expected that this addressing scheme will be appropriate
long term use with the ISO IP in the Internet. However, it is
expected that in the long term, the Internet will be
with other routing domains making use of other schemes, such
addresses assigned to commercial internets through ANSI,
addresses assigned by national standards organizations in
countries. This implies that, in the long term, gateways in
Internet will need to be able to route datagrams to destinations
other routing domains not conforming to the addressing
proposed here. This is discussed in greater detail in section 6.
2.
The CLNP is documented in [1], but for matters of completeness
following illustration of the CLNP header is included here as
1.
Callon & Braun [Page 2]
RFC 1069 IP ISO Addressing February 1989
The addressing part of the header is the subject of this RFC, i.e.,
the source and the destination address, respectively.
addresses are generally discussed in [2] and [3], with this
presenting a specific method for addressing in the
environment, consistent with the international standardized
addresses
+--------------------------------------+ +--------
| Network Layer Protocol Identifier | 1 :
|--------------------------------------| :
| Length Indicator | 2 :
|--------------------------------------| :
| Version/Protocol Id Extension | 3 :
|--------------------------------------| :
| Lifetime | 4 :
|--------------------------------------| :
|SP|MS|E/R| Type | 5 :
|--------------------------------------| :
| Segment Length | 6,7 :
|--------------------------------------| :
| Checksum | 8,9 :
|--------------------------------------| +--------
| Destination Address Length Indicator | 10 :
|--------------------------------------| :
| Destination Address | 11 through m-1 :
|--------------------------------------| :
| Source Address Length Indicator | m :
|--------------------------------------| :
| Source Address | m+1 through n-1 :
|--------------------------------------| +--------
| Data Unit Identifier | n,n+1 :
|--------------------------------------| :
| Segment Offset | n+2,n+3 :
|--------------------------------------| :
| Total Length | n+4,n+5 :
|--------------------------------------| +--------
| Options | n+6 through p :
|--------------------------------------| +--------
| Data | p+1 through z :
+--------------------------------------+ +--------
Figure 1: PDU Header
Callon & Braun [Page 3]
RFC 1069 IP ISO Addressing February 1989
3. Addresses for Use in the
This section describes the addresses used to address NSAPs in
Internet
The appropriate Authority and Format Identifier (AFI) is one octet
length. It specifies an ISO-6523-ICD assignment, and also that
Domain Specific Part (DSP) of the address is based on binary.
AFI octet uses the value "47". The ISO-6523-ICD format is used
emphasize that this is an administrative assignment. The usage of
ISO DCC (Data Country Code) would be possible, but could
misleading due to the fairly far spread geographical extent of
Internet
As required by the ISO addressing standard, the next two octets
the address, in this case, specify the Initial Domain Identifier
This two octet value is the International Code Designator (ICD
assigned to the Internet, "0006".
The remainder of the NSAP address is the Domain Specific Part (DSP).
This is assigned by the Internet administration, which is
to be an addressing domain. Note that there is no
relationship required between addressing domains and routing domains
In this case, although the Internet is considered to be a
addressing domain, it is expected that it will consist of
routing domains
The DSP of the address specifies a one octet version number, a
octet global area number, a two octet routing domain number,
variable length padding field, a variable length IGP specific part
and a one octet selector field
The version number is provided to allow for future extensions,
must contain the value "02".
The global area number and routing domain number are provided
allow for inter-domain routing. Initially, the global area number
reserved and must be set to zero. The routing domain number may
set to the routing domain number of any gateway by which
associated host address is directly reachable
The IGP specific part of the address may contain whatever
format is used in the routing domain. Two particular formats
expected to be used initially, and are presented in section 4.
Padding is used so that the entire address will always be 20
in length
The selector field performs the same function as the user
Callon & Braun [Page 4]
RFC 1069 IP ISO Addressing February 1989
field in the IP header. This is necessary because the ISO
considers identification of the user protocol to be an
issue, and therefore does not allow for the user protocol to
specified in the protocol header independently from the address
The assignment of specific routing domain identifiers to
routing domains, and the assignment of values for use in the
field, are functions for the Assigned Numbers authority for
Internet [4]. The specific values to be used are outside of
scope of this document
In summary, a source or destination address within the
Connectionless Protocol, when used in the Internet, looks as follows
+------------------------+
| AFI | 1
+------------------------+
| IDI / ICD | 2
+-- --+
|(specifies DoD Internet)| 3
+------------------------+
| Version Number | 4
+------------------------+
| Global Area | 5
+--- ---+
| Number | 6
+------------------------+
| Routing | 7
+--- ---+
| Domain | 8
+------------------------+
| | 9
: Padding : :
: : :
| |
+------------------------+
| IGP | n+1
: : :
: : :
| Specific | 19
+------------------------+
| Selector | 20
+------------------------+
Figure 2: ISO IP address
Callon & Braun [Page 5]
RFC 1069 IP ISO Addressing February 1989
The Authority and Format Identifier (AFI) is "47" (BCD). The
Domain Identifier (IDI) consists of the International Code
(ICD) assigned to the Internet, and must contain the value "0006".
The Version Number must contain the value "02". The Global
Number must contains the value "00". The Padding field is
variable length, but must contain the value zero
4. Specific Values for use with the IGP specific
In general, a particular routing domain may specify any
scheme for use with the IGP specific part of the address, up to 11
octets in length (consistent with the maximum address length of 20
octets). However, it is expected that initially addresses used
this field will consist of either the current IP addresses,
addresses conformant with those specified in the draft ANSI
for intra-domain routing
For end systems which are members of routing domains using the
addresses for internal routing, the addresses will look as follows
Callon & Braun [Page 6]
RFC 1069 IP ISO Addressing February 1989
+------------------------+
| AFI | 1
+------------------------+
| IDI / ICD | 2
+-- --+
|(specifies DoD Internet)| 3
+------------------------+
| Version Number | 4
+------------------------+
| Global Area | 5
+--- ---+
| Number | 6
+------------------------+
| Routing | 7
+--- ---+
| Domain | 8
+------------------------+
| | 9
: Padding : :
: : :
| | 15
+------------------------+
| Four Octet | 16
+--- ---+
| Internet | 17
+--- ---+
| DoD | 18
+--- ---+
| Address | 19
+------------------------+
| Selector | 20
+------------------------+
Figure 3: ISO IP Address with Encoded DoD IP
For end systems which are members of routing domains using
address format specified in the draft ANSI proposal for intra-
routing [6], the addresses will look as follows
Callon & Braun [Page 7]
RFC 1069 IP ISO Addressing February 1989
+------------------------+
| AFI | 1
+------------------------+
| IDI / ICD | 2
+-- --+
|(specifies DOD Internet)| 3
+------------------------+
| Version Number | 4
+------------------------+
| Global Area | 5
+--- ---+
| Number | 6
+------------------------+
| Routing | 7
+--- ---+
| Domain | 8
+------------------------+
| | 9
+--- ---+
| Padding | 10
+--- ---+
| | 11
+------------------------+
| | 12
+--- LOC-AREA ---+
| | 13
+------------------------+
| | 14
: ID : :
: : :
| | 19
+------------------------+
| Selector | 20
+------------------------+
Figure 4: ISO IP Address with Encoded ANSI-format
5. Devices Attached to
Otherwise isolated end systems, which are attached to the
only indirectly via public data networks, and simple LANs which
similarly attached only via Public Data Networks, may make use of
separate address format based on their X.121 address. Such
may, for example, use the ISO-X.121 address format discussed in [3].
These addresses will need to be handled for routing purposes in
the same way as addresses in routing domains which have
Callon & Braun [Page 8]
RFC 1069 IP ISO Addressing February 1989
interconnected to the Internet, but which use other address formats
such as those specified by national standards bodies
6. Migration to Future Routing
Initially, routing of ISO datagrams in the Internet may make use
the first 8 octets of the address (AFI, ICD, version, global
number, and routing domain number) as a flat field identifying
routing domain. This implies that if EGP is initially used
routing between routing domains, a new version of EGP may be
to carry 8 octet routing domain numbers instead of 3 octet
numbers
There are currently several efforts underway to determine
requirements for inter-autonomous system routing, and to define a
protocol. One of the requirements of inter-autonomous system
is the need to be able to deal with a very large Internet. It
anticipated that during the lifetime of the addressing
described in this RFC the number of networks in the Internet
grow to the point where it is no longer feasible for any gateway
maintain separate routes to every network in the Internet.
inter-domain routing to be done by routing domain number instead
network number is therefore a necessary step in the long term
It is difficult to anticipate the rate at which the number of
domains may grow. For example, during a period of time in which
number of networks grows by a factor of 100, it is not clear
the number of routing domains may also be expected to grow by
factor of 100, or by some lesser amount. It is possible that
number of routing domains will also grow to a point where it is
feasible for a single gateway to maintain separate routes to each
In order to prepare for this eventuality, we have provided for
"global area" field
In the long term, it will be necessary for gateways to route
destinations which are in routing domains utilizing other
formats, specified by other organizations such as ANSI, ECMA, etc
In this case, it will not be possible to ensure that the first 8
octets of the address specifies the routing domain. In the
term, it will therefore be necessary to route based on
length routing domain identifiers. It may be assumed that
inter-domain routing protocols will allow for specification of
(1) an address mask, specifying which part of an address is
for specifying those destinations which are reachable via
particular domain; or (2) a length field, specifying how many
octets in a particular address are relevant. Specification of
details of such a routing protocol is beyond the scope of
document
Callon & Braun [Page 9]
RFC 1069 IP ISO Addressing February 1989
[1] ISO, "Protocol for Providing the Connectionless-Mode
Services", RFC-926, ISO, December 1984.
[2] ANSI, "Guidelines for the Specification of the Structure of
Domain Specific Part (DSP) of the ISO Standard NSAP Address",
RFC-982, ANSI Working Document X3S3.3/85-258, April 1986.
[3] ISO, Draft International Standard 8348/DAD2, "
Processing Systems -- Data Communications -- Network
Definition, Addendum 2 Covering Network Layer Addressing", RFC
941, April 1985.
[4] Reynolds, J. and J. Postel, "Assigned Numbers", RFC-1010,
USC/Information Sciences Institute, May 1987.
[5] Callon, R. and H. W. Braun, "Working Draft -- Guidelines for
use of Internet-IP addresses in the ISO Connectionless-
Network Protocol," RFC-986, June 1986.
[6] ISO TC97/SC6/WG2 working document, "Intermediate System
Intermediate System Intra-Domain Routing Exchange Protocol".
Callon & Braun [Page 10]
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
