Home
ATM Addressing

ATM Addressing

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 U.S., the correct sanctioning body would probably be ANSI. ANSI sanctioned ATM addresses use the DCC subdomain. The U. S. Government uses the ICD subdomain.

 

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.

Presentation: Implications of Memory Consistency (or Lack of It) Models for Java, C++, and C Developers (more)

Seminar Review: Jack Ganssle, Better Firmware Faster, 2006 (more)

Article: Vaster than Empires and More Slow: The Dimensions of Scalability (more)

Article: In Praise of do-while (false) (more)

Book Review: Joel Spolsky, Best Software Writing I, Apress, 2005 (more)

Presentation: Robert Austin, Measuring and Managing Performance in Organizations, Dorset House, 1996 (more)

Book Review: Joel Spolsky, Joel on Software, Apress, 2004 (more)

Presentation: James Surowiecki, The Wisdom of Crowds, Doubleday, 2004 (more)

Travelogue: China Journal: Dancing with a Sleeping Giant (more)

Unless otherwise specified, all contents Copyright © 1995-2015 by the Digital Aggregates Corporation, Colorado, USA.
Such copyrighted content is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.