ATM Addressing
ATM Address Formats
Each ATM-attached end station has a unique 20-byte ATM
address. Part of this address is the network portion or prefix, which uniquely
identifies a particular ATM switch in the ATM network. There are two different
basic formats for ATM addresses: Network Service Access Point (NSAP), which is
derived from OSI data network standards, and E.164, which is derived from ITU
public switched telephone network standards. Within NSAP, there are three
different standardized address formats used by ATM:
- Data Country Code or DCC
(ISO3166), a 20-byte address consisting of (from high to low order) an
initial 1-byte Authority and Format Identifier or AFI (hex 39 for DCC), a
2-byte Data Country Code or DCC, a 10-byte High Order-Domain Specific Part
or HO-DSP, a 6-byte End System Identifier ESI, and a 1-byte Selector;
- International Code Designator
or ICD (ISO6523), a 20-byte address consisting of (from high to low order)
an initial 1-byte AFI (hex 47 for ICD), a 2-byte International Code Designator
or ICD, 10-byte HO-DSP, a 6-byte ESI, and a 1-byte Selector;
- E.164 (ITU-T Recommendation
E.164), a 20-byte address consisting of (from high to low order) an
initial 1-byte AFI (hex 45 for E.164), an 8-byte E.164 address, 4-byte
HO-DSP, a 6-byte ESI, and a 1-byte Selector. Note that this use of an
e.164 address in an OSI NSAP format is different from using the PSTN
"native" E.164 address mentioned above.
Note in all three formats, the Address Format Identifier
(AFI), End System Identifier (ESI), and Selector fields have the same
alignment.
The AFI identifies the address format. The first 13-bytes of
each format, consisting of the AFI, the DCC or ICD or E.164 portion, and the
High-Order Domain Specific Part (HO-DSP), is the network portion or prefix or
the address, and uniquely identifies the particular ATM switch. The ESI
uniquely identifies each end station within the same ATM switch. This field is
typically (but not required to be) the IEEE Media Access Control (MAC) address
programmed into the end station device during its manufacture. The Selector is
used by some protocols layers on top of ATM to uniquely identify logical
sub-channels within a single ATM end station. For all of the ATM applications I
have ever dealt with, the Selector byte is zero. Generally, ATM connection
setups are routed based on the ATM address minus the Selector byte.
An ATM network may use any of these address formats. It may
use a different format for different switches. A single switch may use
different formats for different end stations.
E.164 prefixes are 15-digit numbers. Because the 15-digits
are encoded in BCD, they only take up 7.5-bytes (7-bytes plus the leading
nibble of the eighth byte). The trailing nibble of the eighth byte must be
encoded as a hex F, as shown in the example below, to pad the number out to
8-bytes. E.164 numbers shorter than 15-digits are padded on the left with
zeros. These 8-bytes immediately follow the initial hex 45 AFI. The next 4
bytes of the prefix are the HO-DSP. The E.164 address format was derived from
the PSTN, so if you are thinking of the E.164 portion of the address as a
telephone number including country code, area code, and exchange, you have the
right idea. For example, an E.164 number of 13035551212 and an HO-DSP of all
zeros would have a 13-byte ATM network prefix of hexadecimal
45000013035381053F00000000.
There is some evidence in the ATM Forum UNI 3.1 and ILMI 4.0
specifications that if you use E.164 addresses in the standard NSAP format on
the public UNI, the ESI and selector bytes must both be zero, and any
other combination of E.164 network prefix, ESI and selector byte is invalid.
This is because the address carried in (for example) a SETUP message may have
to be routed via public networks which only support native E.164 and don't
understand ESIs. In the private UNI, you can use the
E.164 address as a network prefix in the NSAP format along with a conventional
ESI. One approach to using native E.164 addressing in a public ATM network
might be by assigning a specific PNNI route for each port, with an E.164-format
network prefix and zero ESI and selector byte. This means that every ATM end
station (and for that matter, the ATM switch itself) would have its own unique
E.164 address, and every ESI and Selector would be zero.
What really happens, is that all private ATM networks use
NSAP addressing. At the boundary of the private to the public ATM network there
is a translation function that converts the NSAP address (whether ICD, DCC or
E.164 format) into a native E.164 address (like an actual phone number). The
CALLED PARTY information element, which up to this point contained the NSAP
address, now contains the native E.164 address. The NSAP address is moved into
the CALLED PARTY SUBADDRESS IE. The opposite conversion happens on the other
end. As the SETUP crosses the boundary from public to private, the NSAP address
is restored to the CALLED PARTY IE for routing to the final end point. While I
don't know the details of this conversion, it might not be that hard since
presumably it need only be done using some subset of the NSAP network prefix to
identify a particular attachment point to the public network. At least one WAN
ATM service service provider has told us that they
expect NSAP addresses. So this translation to E.164 (if it happens at all) may
be significantly inboard of the edge of the public network. Of course, since
the use of native E.164 addresses should be transparent to folks like us in the
private UNI, it may well be that the typical WAN ATM service provider uses NSAP
end to end.
The ATM network prefix, the network portion of the address,
must be administered on the ATM switch if the default ATM network prefix (if
any) established for the ATM switch during manufacture cannot be used. Like
internet addresses, the ATM prefix will be provided by the customer and will
depend on addressing in their existing ATM LAN and on the ATM WAN addressing
provided by their ATM service provider. The ATM switch must also be adminstered with the ESI of each attached ATM end station. If
there is no existing ATM networking at the customer premises, then the default
ATM prefix may be used, but be forewarned that, just as with internet
addresses, as the customer's ATM infrastructure grows, it may become necessary
to readminister the ATM switch, perhaps each end
station, and probably the customer application, with new globally unique
standardized addresses. This can be a lengthy and disruptive process.
ATM routing is extremely sensitive to how ATM addresses are
formatted and used. See the discussion on ATM routing elsewhere
The final issue is the selection of the ESI to uniquely
identify each end station attached to a particular ATM switch. On typical ATM
end station devices, the IEEE MAC address established for the board during
manufacture is used as the ESI. Using an IEEE MAC address insures that the ESI
is (literally) globally unique. However, any ESI that is unique within a
particular ATM switch can technically be used, as long as it is administered
identically on the ATM switch, the end station if necessary, and the customer
application.
Establishing Unique Network Prefixes
There are several standards for the 13-byte ATM network
prefix, depending on what authority is being used to sanction the addresses.
The first four bytes of the network prefix are the Authority and Format
Identifier or AFI (one byte), the Initial Domain Identifier or IDI (two bytes),
and the DSP (Domain Specific Part) Format Identifier or DFI (one byte). These
four bytes together identify the organization which is sanctioning the ATM
address. Generally this is the British Standards Institute, the American
National Standards Institute (ANSI), or the U. S. Government. For a corporation
in the
The next three bytes (24 bits) of the ATM network prefix is
the numeric organization name. $1000 gets you a perpetually globally unique
organization name from ANSI. Three bytes provides ANSI with 2^24-1 (more than
16 million) different organization identifiers.
The next two bytes of the ATM network prefix are reserved
and are always zero.
The last four bytes of the ATM network prefix is the Routing
Domain Identifier or RD -- not RDI which means something else in the ATM world
-- (two bytes) and the Area Identifier (two bytes). These are assigned by
whoever owns the organization identifier. For example, in a typical large
organization is a group that issues a unique (within organization) RD to each
group within the organization that manages an ATM network. Then within that
network that group would assign a unique Area Identifier to each ATM switch.
This would create a unique network prefix for each ATM switch. The exact values
of the RD and Area might depend on how routing was implemented among the ATM
switches in the organization.
RFC1629 has information on how to contact ANSI for a numeric
organization identifier.
As an example, take the network prefix AFI=39 (DCC),
IDI=840, DFI=128, ORG=113778, RES=0. In hexadecimal notation, according to the
standards established by the ATM Forum, this would read as 39 840F 80 01BC72
0000. Note that some of the fields are encoded in BCD (like the AFI and the
IDI), and some are encoded in binary (like the DFI and the ORG). I'm pretty
sure this is done just to confuse people like me (which it did).
Using MAC Addresses for ESIs
IEEE MAC (Media Access Control) addresses are six bytes (six
octets, 48 bits) in length. They are used for lots of things, like hardcoded Ethernet addresses on NIC cards, not just ATM ESIs. They are constructed such that each MAC address is perpetually
globally unique.
The first three bytes (three octets, 24 bits) is an
Organizationally Unique Identifier (OUI). These are assigned by the IEEE. It
costs $1250.00 to get an OUI. 24 bits gives the IEEE 2^24-1 (more than 16
million) different OUIs. (Note that the OUI serves
much the same purpose as the organization idenfitier
used in the ATM network prefix, but is a completely seperate
thing issued by a completely seperate organization,
and extends in function far beyond its uses in ATM.)
Once you've got your OUI, you have to set about forming a
MAC address. You do that by taking whatever additional three bytes strike your
fancy. The range of 16 million possible MAC addresses formable with a given OUI
is yours to do with as your wish. Cool? Oui!
The IEEE has a web page, ftp://ftp.ieee.org/info/stds/info.stds.oui, that has information on how to apply for an OUI.
IEEE will not assign an additional OUI to your company until
you've used at least 90-95% of your existing range. Seems
fair.
If each end station is assigned a unique MAC address, then
the board can safely self-register with the ATM switch to which it is
connected. It can use its MAC address as an ESI, secure in the knowledge that
this ESI will not conflict with any other MAC-based ESI registered by any other
device of any type. The complete ATM address for that end station would be the
ATM switch's network prefix (the first 13 bytes) plus the board's
own MAC address (the next 6 bytes) plus a selector byte of zero, for a total of
20 bytes.
As an example, take the MAC address hexadecimal 00601D053340.
(Don’t look for it; it’s resting inside a tiny memory device in the
palm of my hand.) The OUI of the organization issuing this MAC address is
hexadecimal 00601D, and the unique device number within that organization is
hexadecimal 053340.
Note that the unique organization identifier of the network
prefix and the OUI of the MAC address are not redundant. Your ATM service
provider (which could be your own organization if you have a large internal ATM
network) establishes the organization identifier of your network prefix, while
your ATM end station vendor establishes the OUI in the MAC address.
Suppose we had an ATM switch with the network prefix from
the prior example, with an RD of 009A and an AI of 0C15. When we attached our
end station with the MAC address above, its complete twenty byte ATM address
would be hexadecimal 39 840F 80 01BC72 0000 009A 0C15 00601D053340 00. This
address is guaranteed unique no matter to which ATM network you eventually
interconnected and regardless of how many end stations it has on it.
References
Information Processing Systems -
Data Communications Network Service Definition -Addendum 2: Network Layer
Addressing, International Standards
Organization, ISO 8348/AD2, March 1988
A. McKenzie, Addendum to the Network Service
Definition Covering Network Layer Addressing, IETF, RFC941,
April 1985
R. Colella, et al., Guidelines
for OSI NSAP Allocation in the Internet, IETF RFC1629, May
1994
ATM User-Network Interface Specification Version 3.1,
ATM Forum, af-uni-0010.002, September 1994
Integrated Local Management
Interface (ILMI) Specification Version 4.0,
ATM Forum, af-ilmi-0065.000, September 1996
Data Communications
- Structure and Semantics of the Domain Specific Part (DSP) of the OSI Network
Service Access Point (NSAP) Address,
American National Standards Institute, X3.216-1992, July 1992
Author
J. L. Sloan jsloan@diag.com 2005-08-16
© 2005 by the Digital
Aggregates Corporation. All rights reserved.