Obtaining Globally Unique NSAP Addresses

The Internet is composed of many separate IP network domains, which collaborate by sharing routing information to form the Internet's gigantic multinational and intercontinental framework. Each constituent network of the Internet is considered an independent routing domain or an autonomous system ( AS ).

BGP has stood the test of time to emerge as the only viable protocol for exchanging routing information between the many ASs that form the Internet. In the early days of the Internet, an alternative routing protocol based on CLNP called Interdomain Routing Protocol ( IDRP ) was proposed, but it was not widely adopted because of the ubiquity of IP and its dominance over CLNP. BGP provides flexible routing policies for controlling routing information within an AS, as well as outbound and inbound routing information. IS-IS belongs to the class of routing protocols called Interior Gateway Protocols (IGPs), which work alongside BGP and provide supportive roles for routing in an AS. Typically, all the autonomous systems on the Internet run BGP and an IGP (IS-IS or OSPF). However, all the instances of IGPs running in the different network domains that constitute the Internet are isolated from each other. Only BGP is used for exchanging routing information between ASs. Therefore, a service provider can freely choose any type of IGP to use within its AS. When IS-IS is used as an IGP, the required NSAPs can be based on the simplified format because they do not need to be globally unique ”just as private IP addresses can be defined on the internal links in an AS without any significant external implications except breaking Traceroutes and Pings to and from remote networks. Globally unique NSAP addresses do make sense, however, for interconnected telecommunications systems, such as ATM switches, SONET/SDH Add Drop Multiplexers (ADM), and any devices that use CLNP-based applications for global connectivity. Besides OSPF, IS-IS is one of the most widely deployed IGPs in ISP networks. There are many reasons for this: historical reasons based on specific practical experience, troubleshooting simplicity, perceived robustness and fast convergence, or mere subjective convenience. As indicated, even though globally unique NSAP addresses are not required to run IS-IS in an Internet AS for the current application, most service providers have deployed 20-byte globally unique addresses.

ISO NSAP Addressing Authorities

An address registration authority oversees address assignments for each of the top-level addressing domains. For example, ISO 6523 specifies rules for allocation of ICD addresses (AFI 47) by an International Registration Authority (RA). Applications for addresses are processed through a sponsoring authority, such as a country's national standards body. The RA does not process any direct applications from organizations. As indicated in the previous section, IDI 0005 and 0006 are allocated to the U.S. National Institute of Standards (NIST) and subsequently reallocated to institutions and organizations of the U.S. federal government.

The British Standards Institute (BSI), which is the national standards body of the United Kingdom (UK), acts as the UK sponsor for ICD addresses. BSI also runs an independent ICD address allocation scheme through a business development group . The scheme called Identifiers for Organizations for Telecommunications Addressing ( IOTA ) was motivated by demand for Asynchronous Transfer Mode ( ATM ) End System Addresses ( AESA ) for use on ATM switches in coordination with the ATM forum. The IOTA scheme was introduced with a broader objective to provide ICD format identifiers for organizations, in any part of the world, and to supply globally unique addresses and identifiers for any kind of application. The IOTA IDI value is 0124 and goes with an AFI prefix of 47 at the beginning of the AESA. An example of an IOTA-based NSAP address is shown in Example 4-3. The reader is referred to the IOTA site listed in the "References" section for more information.

Example 4-3 IOTA-Based NSAP Address

 47. 0124. xxxxxx. yyyyyyyyyyyyyy .  AABBCCDDEEFF .00 --  ----  ------  --------------    ------------  --  ^    ^     ^           ^                ^         ^                                                AFI  IDI  OrgID    Org. Assigned       SysID      NSEL 

As shown in Example 4-3, the first three leftmost bytes of an IOTA-based NSAP are the IOTA organization ID (47.0124). The actual syntax of the DSP is binary, but it is represented in hexadecimal. Counting from left, octets 4 through 6 (Org ID) represent the organization identifier assigned by the IOTA RA. Octets 7 “13 are administered and assigned locally by the organization. The last seven octets make up the SysID and NSEL fields.

The ISO DCC NSAP addressing hierarchy is as popular as the ISO 6523 ICD scheme and has been adopted by numerous organizations, primarily for addressing telecommunication systems, devices, and related objects. ISO DCC is specified in ISO 3166 and uses 39 as AFI. Just as in the case of ISO 6523 ICD NSAP addresses, administration of the DCC address space is coordinated through national organizations. In the United States, for example, the American National Standards Institute (ANSI) is the RA. The address allocation procedure is specified in ANSI X3.216 in conformance with ITU X.660/ISO/IEC 9834-1, which describes a hierarchy of RAs. The IDI assigned to ANSI is 840, which is prefixed with AFI 39 and specifies binary encoding of the DSP in accordance with ISO 8348/AD2. The AFI and IDI are decimals but encoded in binary-coded decimal (BCD) format with octet boundaries at 8 bits. Note the leading zero fill in the IDI field in Example 4-4. Refer to the ANSI Web site in the "References" section for additional information.

Example 4-4 An ANSI ICD NSAP Address

 39 0840 xxxxxx yyyyyyyyyyyyyy AABBCCDDEEFF 00 -- ---- ------ -------------- ------------ --  ^    ^     ^        ^             ^       ^                                        AFI  IDI  OrgID   Org. Assigned   SysID   NSEL 

Currently, the Cisco IOS CLI does not provide formatting help during entry of the NSAP in a router configuration. Knowledge of field boundaries in the NSAP addressing architecture by network operators is, therefore, critical for configuring NSAPs and enabling IS-IS on Cisco routers.