As per Relevance of the word identifier, we have this rfc below:
Network Working Group D.
Request for Comments: 1526
Category: Informational September 1993
Assignment of System Identifiers for TUBA/CLNP
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
This document describes conventions whereby the system
portion of an RFC 1237 style NSAP address may be
uniqueness within a routing domain for the purpose
autoconfiguration in TUBA/CLNP internets. The mechanism is
and can provide a basis for assigning system identifiers in
globally unique fashion
This memo specifies methods for assigning a 6 octet system
portion of the OSI NSAP address formats described in "Guidelines
OSI NSAP Allocation in the Internet" [1], in a fashion that
that the ID is unique within a routing domain. It also
methods for assigning system identifiers having lengths other than 6
octets. The 6 octet system identifiers recommended in this RFC
assigned from 2 globally administered spaces (IEEE 802 or "Ethernet",
and IP numbers, administered by the Internet Assigned
Authority, IANA).
At this time, the primary purpose for assuring uniqueness of
identifiers is to aid in autoconfiguration of NSAP addresses
TUBA/CLNP internets [2]. The guidelines in this paper also
an initial framework within which globally unique system identifiers
also called endpoint identifiers, may be assigned
Many thanks to Radia Perlman, Allison Mankin, and Ross Callon of
their insights and assistance. Thanks also to the Ethernet
to my MAC, which conveniently and quite inobtrusively fell out
enabling me to get an entire day's worth of work done without
interruptions
Piscitello [Page 1]
RFC 1526 System Identifiers for TUBA September 1993
1.
The general format of OSI network service access point (NSAP
addresses is illustrated in Figure 1.
_______________________________________________
|____IDP_____|_______________DSP______________|
|__AFI_|_IDI_|_____HO-DSP______|___ID___|_SEL_|
IDP Initial Domain
AFI Authority and Format
IDI Initial Domain
DSP Domain Specific
HO-DSP High-order
ID System
SEL NSAP
Figure 1: OSI NSAP Address Structure
The recommended encoding and allocation of NSAP addresses in
Internet is specified in RFC 1237. RFC 1237 makes the
statements regarding the system identifier (ID) field of the NSAPA
1. the ID field may be from one to eight octets in
2. the ID must have a single known length in any
routing
3. the ID field must be unique within an area for ESs
level 1 ISs, and unique within the routing domain for
2 ISs
4. the ID field is assumed to be
RFC 1237 further indicates that, within a routing domain
conforms to the OSI intradomain routing protocol [3] the lower-
octets of the NSAP should be structured as the ID and SEL
shown in Figure 1 to take full advantage of intradomain IS-
routing. (End systems with addresses which do not conform may
additional manual configuration and be subject to inferior
performance.)
Both GOSIP Version 2 (under DFI-80h, see Figure 2a) and ANSI DCC
addressing (Figure 2b) define a common DSP structure in which
system identifier is assumed to be a fixed length of 6 octets
Piscitello [Page 2]
RFC 1526 System Identifiers for TUBA September 1993
_______________
|<--__IDP_-->_|___________________________________
|AFI_|__IDI___|___________<--_DSP_-->____________|
|_47_|__0005__|DFI_|AA_|Rsvd_|_RD_|Area_|ID_|Sel_|
octets |_1__|___2____|_1__|_3_|__2__|_2__|_2___|_6_|_1__|
Figure 2 (a): GOSIP Version 2 NSAP structure
______________
|<--_IDP_-->_|_____________________________________
|AFI_|__IDI__|____________<--_DSP_-->_____________|
|_39_|__840__|DFI_|_ORG_|Rsvd_|RD_|Area_|_ID_|Sel_|
octets |_1__|___2___|_1__|__3__|_2___|_2_|__2__|_6__|_1__|
IDP Initial Domain
AFI Authority and Format
IDI Initial Domain
DSP Domain Specific
DFI DSP Format
ORG Organization Name (numeric form
Rsvd
RD Routing Domain
Area Area
ID System
SEL NSAP
Figure 2(b): ANSI NSAP address format for DCC=840
2.
There are provisions in OSI for the autoconfiguration of
addresses. OSI end systems may learn their area
automatically by observing area address identified in the IS-
packets transmitted by routers using the ISO 9542 End System
Intermediate System Routing Protocol, and may then insert their
system identifier. (In particular, RFC 1237 explains that when the
portion of the address is assigned using IEEE style 48-
identifiers, an end system can reconfigure its entire NSAP
automatically without the need for manual intervention.) End
that have not been pre-configured with an NSAPA may also request
address from an intermediate system their area using [5].
2.1 Autoconfiguration and 48-bit
There is a general misassumption that the 6-octet system
must be a 48-bit IEEE assigned (ethernet) address.
speaking, autoconfiguration does not rely on the use of a 48-
ethernet style address; any system identifier that is
Piscitello [Page 3]
RFC 1526 System Identifiers for TUBA September 1993
administered and is unique will do. The use of 48-bit/6 octet
identifiers is "convenient...because it is the same length as an 802
address", but more importantly, choice of a single, uniform ID
allows for "efficient packet forwarding", since routers won't have
make on the fly decisions about ID length (see [6], pages 156-157).
Still, it is not a requirement that system identifiers be 6 octets
operate the the IS-IS protocol, and IS-IS allows for the use of
with lengths from 1 to 8 octets
3. System Identifiers for TUBA/
Autoconfiguration is a desirable feature for TUBA/CLNP, and is
by some as "essential if a network is to scale to a truly large size
[6].
For this purpose, and to accommodate communities who do not wish
use ethernet style addresses, a generalized format that satisfies
following criteria is desired
o the format is compatible with installed end
complying to RFC 1237
o the format accommodates 6 octet, globally unique
identifiers that do not come from the ethernet address
o the format accommodates globally unique system
having lengths other than 6
The format and encoding of a globally unique system identifier
meets these requirements is illustrated in Figure 3:
Octet 1 Octet 2 Octet 3 ... Octet LLL-1 Octet
+-----------+-----------+-----------+- ...-+-----------+-----------+
| xxxx TTGM | xxxx xxxx | xxxx xxxx | | xxxx xxxx | xxxx xxxx |
+-----------+-----------+-----------+- ...-+-----------+-----------+
Figure 3. General format of the system
3.1 IEEE 802 Form of System
The format is compatible with globally assigned IEEE 802 addresses
since it carefully preserves the semantics of the global/local
group/individual bits. Octet 1 identifies 2 qualifier bits, G and M
and a subtype (TT) field whose semantics are associated with
qualifier bits. When a globally assigned IEEE 802 address is used
a system identifier, the qualifier bit M, representing
multicast/unicast bit, must always be set to zero to denote a
address. The qualifier bit G may be either 0 or 1, depending
Piscitello [Page 4]
RFC 1526 System Identifiers for TUBA September 1993
whether the individual address is globally or locally assigned.
these circumstances, the subtype bits are "don't care", and
system identifier shall be interpreted as a 48-bit, globally
identifier assigned from the IEEE 802 committee (an
address). The remaining bits in octet 1, together with octets 2
3 are the vendor code or OUI (organizationally unique identifier),
illustrated in Figure 4. The ID is encoded in IEEE 802
form (low order bit of low order hex digit of leftmost octet is
first bit transmitted).
Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6
+-----------+-----------+-----------+-----------+-----------+-----------+
| VVVV VV00 | VVVV VVVV | VVVV VVVV | SSSS SSSS | SSSS SSSS | SSSS SSSS |
+-----------+-----------+-----------+-----------+-----------+-----------+
|------------vendor code -----------|--------station code---------------|
Figure 4. IEEE 802 form of system
4. Embedded IP Address as System
To distinguish 48-bit IEEE 802 addresses used as system
from other forms of globally admininistered system identifiers,
qualifer bit M shall be set to 1. The correct interpretation of the
bit set to 1 should be, "this can't be an IEEE 802 multicast address
since use of multicast addresses is by convention illegal, so it
be some other form of system identifier". The subtype (TT)
illustrated in Figure 3 thus become relevant
When the subtype bits (TT) are set to a value of 0, the
identifier contains an embedded IP address. The remainder of the 48-
bit system identifier is encoded as follows. The remaining nibble
octet 1 shall be set to zero. Octet 2 is reserved and shall be
to a pre-assigned value (see Figure 5). Octets 3 through 6
contain a valid IP address, assigned by IANA. Each octet of the
address is encoded in binary, in internet canonical form, i.e.,
leftmost bit of the network number first
Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6
+-----------+-----------+-----------+-----------+-----------+-----------+
| 0000 0001 | 1010 1010 | aaaa aaaa | bbbb bbbb | cccc cccc | dddd dddd |
+-----------+-----------+-----------+-----------+-----------+-----------+
|-len&Type--|--reserved-|---------IP address----------------------------|
Figure 5. Embedded IP address as system
Piscitello [Page 5]
RFC 1526 System Identifiers for TUBA September 1993
As an example, the host "eve.bellcore.com = 128.96.90.55" could
its IP address as a system identifier in a TUBA/CLNP network.
encoded ID is illustrated in Figure 6.
Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6
+-----------+-----------+-----------+-----------+-----------+-----------+
| 0000 0001 | 1010 1010 | 1000 0000 | 0110 0000 | 0101 1010 | 0011 0111 |
+-----------+-----------+-----------+-----------+-----------+-----------+
|-len&Type--|--reserved-|---------IP address----------------------------|
Figure 6. Example of IP address encoded as
H 2 "Other forms of System Identifiers
To allow for the future definition of additional 6-octet
identifiers, the remaining subtype values are reserved
It is also possible to identify system identifiers with lengths
than 6 octets. Communities who wish to use 8 octet identifiers (
example, embedded E.164 international numbers for the ISDN ERA)
use a GOSIP/ANSI DSP format that allows for the specification of 2
additional octets in the ID field, perhaps at the expense of
"Rsvd" fields; this document recommends that a separate Domain
Indicator value be assigned for such purposes; i.e., a DFI value
is interpreted as saying, among other things, "the system
encoded in this DSP is 64-bits/8 octets. The resulting ANSI/GOSIP
formats under such circumstances are illustrated in Figure 7:
Piscitello [Page 6]
RFC 1526 System Identifiers for TUBA September 1993
______________
|<--_IDP_-->_|______________________________
|AFI_|__IDI__|____________<--_DSP_-->_______|
|_39_|__840__|DFI_|_ORG_|RD_|Area_|_ID_|Sel_|
octets |_1__|___2___|_1__|__3__|_2_|__2__|_8__|_1__|
Figure 7a: ANSI NSAP address format for DCC=840, DFI=
_______________
|<--__IDP_-->_|___________________________________
|AFI_|__IDI___|___________<--_DSP_-->____________|
|_47_|__0005__|DFI_|AA_|_RD_|Area_|ID_|Sel_|
octets |_1__|___2____|_1__|_3_|_2__|_2___|_8_|_1__|
IDP Initial Domain
AFI Authority and Format
IDI Initial Domain
DSP Domain Specific
DFI DSP Format
AA Administrative
RD Routing Domain
Area Area
ID System
SEL NSAP
Figure 7b: GOSIP Version 2 NSAP structure, DFI=
Similar address engineering can be applied for those communities
wish to have shorter system identifiers; have another DFI assigned
and expand the reserved field
5.
This proposal should debunk the "if it's 48-bits, it's gotta be
ethernet address" myth. It demonstrates how IP addresses may
encoded within the 48-bit system identifier field in a
fashion with IEEE 802 addresses, and offers guidelines for those
wish to use system identifiers other than those enumerated here
Piscitello [Page 7]
RFC 1526 System Identifiers for TUBA September 1993
6.
[1] Callon, R., Gardner, E., and R. Colella, "Guidelines for OSI
Allocation in the Internet", RFC 1237, NIST, Mitre, DEC,
1991.
[2] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A
Proposal for Internet Addressing and Routing", RFC 1347, DEC
June 1992.
[3] ISO, "Intradomain routing protocol for use in conjunction
ISO 8473, Protocol for providing the OSI connectionless
service", ISO 10589.
[4] ISO, End-system and intermediate-system routing protocol for
in conjunction with ISO 8473, Protocol for providing the
connectionless network service, ISO 9542.
[5] ISO, "End-system and intermediate-system routing protocol for
in conjunction with ISO 8473, Protocol for providing the
connectionless network service. Amendment 1: Dynamic
of OSI NSAP Addresses End Systems", ISO 9542/DAM1.
[6] Perlman, R., "Interconnections: Bridges and Routers", Addison
Wesley Publishers, Reading, MA. 1992.
7. Security
Security issues are not discussed in this memo
8. Author's
David M.
Bell Communications
NVC 1C322
331 Newman Springs
Red Bank, NJ 07701
EMail: dave@mail.bellcore.
Piscitello [Page 8]
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
