ATM Signaling and Addressing

This chapter describes the role of signaling in ATM networks, explains ATM address formats, and shows how the ATM address of the ATM switch router is assigned using autoconfiguration.

Note The information in this chapter is applicable to the Catalyst 8540 MSR, Catalyst 8510 MSR, and LightStream 1010 ATM switch router. For detailed configuration information, refer to the ATM Switch Router Software Configuration Guide and the ATM Switch Router Command Reference publication.

This chapter includes the following sections:

Signaling and Addressing Overview

Because ATM is a connection-oriented service, specific signaling protocols and addressing structures, as well as protocols to route ATM connection requests across the ATM network, are needed. The following sections describe the role of signaling and addressing in ATM networking.

Signaling

ATM connection services are implemented using permanent and switched virtual connections (see the "ATM Services" section). In the case of a permanent virtual connection (PVC), the VPI/VCI values at each switching point in the connection must be manually configured. While this can be a tedious process, it only needs to be done once, because once the connection is set up, it remains up permanently. PVCs are a good choice for connections that are always in use or are in frequent, high demand. However, they require labor-intensive configuration, they are not very scalable, and they are a good solution for infrequent or short-lived connections.

Switched virtual connections (SVCs) are the solution for the requirements of on-demand connections. They are set up as needed and torn down when no longer needed. To achieve this dynamic behavior, SVCs use signaling: End systems request connectivity to other end systems on an as needed basis and, provided that certain criteria are met, the connection is set up at the time of request. These connections are then dynamically torn down if the connections are not being used, freeing network bandwidth, and can be brought up again when needed.

Note Because SVCs require signaling, they can normally be used only with ATM devices that are capable of signaling. Your ATM switch router supports the standard signaling protocols described in this chapter.

In addition to permanent and switched virtual connections, there is a third, hybrid type. Called soft PVC and soft PVP, these connections are permanent but, because they are set up through signaling, they can ease setup of PVCs and PVPs and can reroute themselves if there is a failure in the link.

Connection Setup and Signaling

Figure 2-1 demonstrates how a basic SVC is set up from Router A (the calling party) to Router B (the called party) using signaling. The steps in the process are as follows:

1. Router A sends a signaling request packet to its directly connected ATM switch (ATM switch 1).

This request contains the ATM address of both calling and called parties, as well as the basic traffic contract requested for the connection.

2. ATM switch 1 reassembles the signaling packet from Router A and then examines it.

3. If ATM switch 1 has an entry for Router B's ATM address in its switch table, and it can accommodate the QoS requested for the connection, it reserves resources for the virtual connection and forwards the request to the next switch (ATM switch 2) along the path.

4. Every switch along the path to Router B reassembles and examines the signaling packet, then forwards it to the next switch if the traffic parameters can be supported on the ingress and egress interfaces. Each switch also sets up the virtual connection as the signaling packet is forwarded.

If any switch along the path cannot accommodate the requested traffic contract, the request is rejected and a rejection message is sent back to Router A.

5. When the signaling packet arrives at Router B, Router B reassembles it and evaluates the packet. If Router B can support the requested traffic contract, it responds with an accept message. As the accept message is propagated back to Router A, the virtual connection is completed.

Note Because the connection is set up along the path of the connection request, the data also flows along this same path.

Figure 2-1: Establishing a Switched Virtual Connection

When it is time to tear down the connection, another sequence of signals is used:

1. Either the calling party or called party sends a release message to the ATM network.

2. The ATM network returns a release complete message to the called party.

3. The ATM network sends a release complete message to the calling party.

The dynamic call teardown is complete.

ATM Signaling Protocols---UNI and NNI

ATM signaling protocols vary by the type of ATM network interface, as follows:

User-Network Interface (UNI) signaling---used between an ATM end-system and ATM switch across UNI links; UNI signaling can also be used between two ATM switches
Network-Network Interface (NNI) signaling---used between ATM switches across NNI links.

UNI signaling in ATM defines the protocol by which SVCs are set up dynamically by the ATM devices in the network. NNI signaling is part of the Private Network-Network Interface (PNNI) specification, which includes both signaling and routing. See the chapter "ATM Routing with IISP and PNNI."

Note The UNI specifications include physical layer, Integrated Local Management Interface (ILMI), and traffic management, in addition to signaling.

The ATM Forum has the task of standardizing the signaling procedures. The ATM Forum UNI specifications are based on the Q.2931 public network signaling protocol developed by the ITU-T. The Q.2931 protocol specifies a call control message format that carries information such as message type (setup, call proceeding, release, and so on) and information elements (IEs), which include addresses and QoS.

All the IEs appropriate to an interface type in the signaling message are transmitted by default. On the ATM switch router, you can selectively disable the forwarding of individual IEs on an interface. See the ATM Switch Router Software Configuration Guide for details.

The UNI specifications are grouped as follows:

UNI 3.x---consists of two sets of interoperable specifications, UNI 3.0 and UNI 3.1
UNI 4.0---includes UNI 3.x specifications and adds new features not supported in UNI 3.x

The original UNI signaling specification, UNI 3.0, provided for the following features:

Signaling for point-to-point connections and point-to-multipoint connections
Support for bandwidth symmetric and bandwidth asymmetric traffic

UNI 3.1 includes the provisions of UNI 3.0 but provides for a number of changes, a number of which were intended to bring the earlier specifications into conformance with ITU-T standards:

UNI 4.0 replaced an explicit specification of the signaling protocol with a set of deltas between it and ITU-T signaling specifications. In general, the functions in UNI 4.0 are a superset of UNI 3.1, and include both a mandatory core of functions and many optional features.

Anycast signaling---allows connection requests and address registration for group addresses, where the group address can be shared among multiple end systems; the group address can represent a particular service, such as a configuration or name server.
Explicit signaling of QoS parameters---maximum cell transfer delay (MCTD), peak-to-peak cell delay variation (ppCDV), and cell loss ratio (CLR) can be signaled across the UNI for CBR and VBR SVCs.
Signaling for ABR connections---many parameters can be signaled to create ABR connections.
Virtual UNI---provides for using one physical UNI with multiple signaling channels. For example, several end stations can connect through a multiplexor; the multiplexor connects via UNI to an ATM switch. In this case there are multiple signaling channels being used by the end stations, but only one UNI (the virtual UNI).
PNNI---specifies signaling and routing protocols across the NNI. PNNI is an optional addition to the UNI 4.0 specification; for detailed information see the chapter "ATM Routing with IISP and PNNI."

The following optional features in UNI 4.0 are not supported on the ATM switch router:

Proxy signaling---allows a device, called a proxy signaling agent, to signal on behalf of other devices. For example, a router might signal for devices behind it that do not support signaling. Another use for proxy signaling would be a video server with aggregated links (say, three
155 Mpbs links aggregated for the 400 Mpbs required by video); in this case, where there is really just one connection, one of the links would signal on behalf of all three.
Signaling for point-to-multipoint connections---leaf initiated joins are supported.

Note Your ATM switch router supports UNI 3.0, 3.1, and 4.0.

Multipoint-to-Point Funnel Signaling

The ATM switch router supports the Microsoft Corporation Proprietary Funnel Join (or Flow Merge) Protocol via the multipoint-to-point funnel signaling (funneling) feature over the UNI. This feature improves the scalability of video-on-demand services, in which multiple video transmitting sources converge on a single virtual connection such that it looks like a point-to-point connection.

Multipoint-to-point funnel signaling (funneling) works by merging multiple incoming SVCs into a single outgoing SVC. An incoming SVC is called a leaf SVC, and the outgoing SVC is called the funnel SVC.

The ATM switch router performs funnel merging on SVCs that originate from the UNI. With the exception of the funnel switch (see Figure 2-2), the multipoint-to-point funnel appears to the network as a point-to-point connection.

Note This feature is an extension of UNI 3.1 and is not supported in UNI 4.0 signaling. The ATM accounting feature is not supported for funnel SVCs.

Figure 2-2 illustrates multipoint-to-point funnel signaling.

Figure 2-2: Multipoint-to-Point Funnel Signaling

Mulitpoint-to-point funnel signaling requires no configuration. For funneling to operate, traffic parameters must be the same for all the SVC leaves on a particular funnel call. The aggregate bandwidth of the source links (SVC leaves) cannot exceed the bandwidth allocated to the funnel link. A maximum of 255 links (leaf SVCs) can join the funnel link. The sources perform arbitration to avoid overloading of the funnel link by the running application.

When the ATM switch router receives a setup message containing a leaf-initiated join information element, the ATM switch router searches for funnel SVCs with existing connections to the destination. The leaf-initiated join information element connection ID and the destination ATM address uniquely identify each funnel SVC.

If a funnel SVC to the same destination arrives with the same leaf-initiated join element connection ID, as one that is already present, the ATM switch router checks to see if the traffic parameters specified in the incoming setup message are the same as those in the funnel SVC. If the parameters are the same, then the leaf is joined to the funnel SVC, and the connection is acknowledged. If the traffic parameters are different, then the setup request is denied. If a funnel SVC to the specified destination is not available when an incoming setup message arrives, then a point-to-point SVC is set up to transmit the message.

Addressing

ATM addresses are needed for purposes of signaling when setting up switched connections. ATM addresses are also used by the Integrated Local Management Protocol (ILMI, formerly Interim Local Management Protocol) to learn the addresses of neighboring switches.

ATM Address Formats

The ITU-T long ago settled on telephone number-like addresses, called E.164 addresses or E.164 numbers, for use in public ATM (B-ISDN) networks. Since telephone numbers are a public (and expensive) resource, the ATM Forum set about developing a private network addressing scheme. The ATM Forum considered two models for private ATM addresses: a peer model, which essentially treats the ATM layer as a peer of existing network layers, and a subnetwork, or overlay, model, which decouples the ATM layer from any existing protocol and defines for itself an entirely new addressing structure.

The ATM Forum settled on the overlay model and defined an ATM address format based on the semantics of an OSI Network Service Access Point (NSAP) address. This 20-byte private ATM address is called an ATM End System Address (AESA), or ATM NSAP address (though it is technically not a real NSAP address). It is specifically designed for use with private ATM networks, while public networks typically continue to use E.164 addresses.

The general structure of NSAP format ATM addresses, shown in Figure 2-3, is as follows:

An initial domain part (IDP)---consists of two elements: an authority and format identifier (AFI) that identifies the type and format of the second element, the initial domain identifier (IDI). The IDI identifies the address allocation and administration authority.
A domain specific part (DSP)---contains the actual routing information in three elements: a high-order domain specific part (HO-DSP), an end system identifier (ESI), which is the MAC address, and NSAP selector (SEL) field, used to identify LANE components.

Figure 2-3: Private ATM Network Address Formats

Private ATM address formats are of three types that differ by the nature of their AFI and IDI (see Figure 2-3):

DCC format (AFI=39)---the IDI is a Data Country Code (DCC). DCC addresses are administered by the ISO national member body in each country.
ICD format (AFI=47)---the IDI is an International Code Designator (ICD). ICD address codes identify particular international organizations and are allocated by the British Standards Institute.
NSAP encoded E.164 format (AFI=45)---the IDI is an E.164 number.

Note There are two types of E.164 addresses: the NSAP encoded E.164 format and the E.164 native format, sometimes called an E.164 number, used in public networks.

A sample ATM address, 47.00918100000000E04FACB401.00E04FACB401.00, is shown in Figure 2-4. The AFI of 47 identifies this address as a ICD format address.

Figure 2-4: Example of ICD Format Address

Choosing an Address Format

The ATM Forum specifications through UNI 4.0 only specify these three valid types of AFI. However, future ATM Forum specifications will allow any AFI that has binary encoding of the Domain Specific Part (DSP) and a length of 20 octets. Although your Cisco ATM switch router ships with an autoconfigured NSAP format ATM address of the ICD type, similar to the one shown in Figure 2-4, the ATM switch router does not restrict the AFI values; you can use any of the valid formats.

The ATM Forum recommends that organizations or private network service providers use either the DCC or ICD formats to form their own numbering plan. NSAP encoded E.164 format addresses are used for encoding E.164 numbers within private networks that need to connect to public networks that use native E.164 addresses, but they can also be used by some private networks. Such private networks can base their own (NSAP format) addressing on the E.164 address of the public UNI to which they are connected and take the address prefix from the E.164 number, identifying local nodes by the lower order bits. The use of E.164 addresses is further discussed in the "Signaling and E.164 Addresses" section.

Addressing on the ATM Switch Router

The ATM address is used by the ATM switch router for signaling and management functions, and by protocols such as LAN emulation and PNNI. The ATM switch router ships with a preconfigured default address which allows it to function in a plug-and-play manner. You can change the default address if you need to; the main reasons for doing so are listed in the section "Manually Configured ATM Addresses" section. If you do not foresee needing to reconfigure the ATM address, then the details of the following sections might not concern you.

Autoconfigured ATM Addressing Scheme

During initial startup, the ATM switch router generates an ATM address using the following defaults (see Figure 2-5):

AFI=47---indicates an address of type DCC
ICD=0091(Cisco-specific)
Cisco-specific address type (part of HO-DSP)=81000000
Cisco switch ID=MAC format address
ESI=MAC address repeated

Note

Selector equals 0---1 byte

Figure 2-5: ATM Address Format

The autoconfigured address mechanism provides a default ATM address for the unconfigured switch. This default address is used by the following protocols:

The Integrated Local Management Interface (ILMI)---a protocol and part of the UNI specifications that facilitates sharing of management information across the UNI. ILMI uses the first 13 bytes of this address to hand to end systems for the generation of ESI addresses. See the "ILMI Use of the ATM Address" section.
Private Network-Network Interface (PNNI)---a dynamic routing protocol for ATM networks. PNNI uses the 13-byte prefix to establish itself as a node in a single-level PNNI routing domain and the first 7 bytes to construct the default peer group identifier. For a complete discussion, see the chapter "ATM Routing with IISP and PNNI."

Default Address Format Features and Implications

Using the default address format has the following features and implications:

All preconfigured addresses share the same 7-byte address prefix. In the autoconfigured address for a given ATM switch router, the same MAC address is used for bytes 8 through 13 and bytes 14 through 19.
The default autoconfigured address provides plug-and-play operation. You can reconfigure the ATM address using your own addressing style, but you must use a globally unique MAC address to generate the ATM address.
The autoconfigured addressing scheme suffices for PNNI operation in a single-level routing domain. To achieve scalable ATM routing in large ATM networks with multiple levels of PNNI hierarchy, you need to manually configure ATM addresses.

The example display below shows the autoconfigured ATM addresses on the ATM switch router. Note that the 13-byte ILMI switch prefix is the same for all addresses.

Switch# show atm addresses
 
Switch Address(es):
  47.00918100000000E04FACB401.00E04FACB401.00 active
 
Soft VC Address(es):
  47.0091.8100.0000.00e0.4fac.b401.4000.0c80.1000.00 ATM0/1/0
  47.0091.8100.0000.00e0.4fac.b401.4000.0c80.1010.00 ATM0/1/1
  47.0091.8100.0000.00e0.4fac.b401.4000.0c80.1020.00 ATM0/1/2
  47.0091.8100.0000.00e0.4fac.b401.4000.0c80.1030.00 ATM0/1/3
  47.0091.8100.0000.00e0.4fac.b401.4000.0c80.8000.00 ATM1/0/0
  47.0091.8100.0000.00e0.4fac.b401.4000.0c80.8010.00 ATM1/0/1
  47.0091.8100.0000.00e0.4fac.b401.4000.0c80.8020.00 ATM1/0/2
  47.0091.8100.0000.00e0.4fac.b401.4000.0c80.8030.00 ATM1/0/3
  47.0091.8100.0000.00e0.4fac.b401.4000.0c80.9000.00 ATM1/1/0
  47.0091.8100.0000.00e0.4fac.b401.4000.0c80.9010.00 ATM1/1/1
  47.0091.8100.0000.00e0.4fac.b401.4000.0c80.9020.00 ATM1/1/2
  47.0091.8100.0000.00e0.4fac.b401.4000.0c80.9030.00 ATM1/1/3
  47.0091.8100.0000.00e0.4fac.b401.4000.0c81.8030.00 ATM-P3/0/3
  47.0091.8100.0000.00e0.4fac.b401.4000.0c81.9000.00 ATM3/1/0
  47.0091.8100.0000.00e0.4fac.b401.4000.0c81.9010.00 ATM3/1/1
  47.0091.8100.0000.00e0.4fac.b401.4000.0c81.9020.00 ATM3/1/2
  47.0091.8100.0000.00e0.4fac.b401.4000.0c81.9030.00 ATM3/1/3
  47.0091.8100.0000.00e0.4fac.b401.4000.0c82.0000.00 ATM-P4/0/0
 
Soft VC Address(es) for Frame Relay Interfaces :
  47.0091.8100.0000.00e0.4fac.b401.4000.0c82.0010.00 Serial4/0/0:1
  47.0091.8100.0000.00e0.4fac.b401.4000.0c82.0020.00 Serial4/0/0:2
  47.0091.8100.0000.00e0.4fac.b401.4000.0c82.0030.00 Serial4/0/0:3
  47.0091.8100.0000.00e0.4fac.b401.4000.0c82.0210.00 Serial4/0/1:1
  47.0091.8100.0000.00e0.4fac.b401.4000.0c82.0220.00 Serial4/0/1:2
 
ILMI Switch Prefix(es):
  47.0091.8100.0000.00e0.4fac.b401
 
ILMI Configured Interface Prefix(es):
 
LECS Address(es):
  47.0091.8100.0000.00e0.4fac.b401.0010.0daa.cc43.00

ILMI Use of the ATM Address

The ILMI protocol uses SNMP format packets across the UNI to access an ILMI Management Information Base (MIB) associated with the link, within each node. The ILMI protocol facilitates network-wide autoconfiguration by allowing adjacent nodes to determine various characteristics of each other---for example, the size of each other's connection space, the type of signaling used (UNI, NNI), hooks for network management autodiscovery, and so on. One of its most useful features, address registration, greatly facilitates the administration of ATM addresses.

The ILMI address registration mechanism allows an ATM end system to inform an ATM switch of its unique MAC address and to receive the remainder of the node's full ATM address in return. ILMI uses the first 13 bytes of the ATM address as the switch prefix that it registers with end systems.

When the an end system, such as a router (Figure 2-6), is attached to the ATM switch, ILMI is used to send all the router's MAC addresses (ESIs) to the switch. The ESI is appended to the switch's 13-byte ILMI prefix to make up a complete ATM address, which is then associated with the interface on which it received the ESI. This allows the ATM switch router, upon receiving a call setup request, to know which interface to send on.

Figure 2-6: ILMI Address Registration Across the UNI

Additional ILMI Considerations

During address migration (changing from one addressing scheme to another), multiple addresses can be configured for a single switch. ILMI registers end systems with multiple prefixes during this period until an old address is removed. (PNNI automatically summarizes all of the switch's prefixes in its reachable address advertisement.)

Although the default, autoconfigured address provides for a fixed 13-byte ILMI prefix, the ATM switch router allows configuration of per-interface ILMI address prefixes, so that different address prefixes can be registered with end systems attached to different interfaces. When any per-interface ILMI address prefixes are configured, they override the prefix(es) derived from the first 13 bytes of the switch ATM address(es) for that specific interface.

ILMI access filters can provide security by permitting or denying ILMI registration of different classes of addresses. For details, see the ATM Switch Router Software Configuration Guide.

PNNI Use of the ATM Address

The preconfigured address provides plug-and-play operation in isolated flat topology ATM networks. All switches with autoconfigured ATM addresses will form one peer group. Although the preconfigured addresses are globally unique, they are not suitable for connection to service provider networks or within hierarchical PNNI networks. Furthermore, address summarization, a key feature of hierarchical PNNI, is not possible beyond the level of one ATM switch. In addition, while E.164 numbers are supported on UNI and IISP interfaces, they are not directly supported by PNNI. Instead, these are supported indirectly through use of the E.164 AESA format.

See "ATM Routing with IISP and PNNI" for more information about addressing in hierarchical PNNI networks and about using E.164 AESAs with PNNI.

LAN Emulation Use of the ATM Address

On a LAN, packets are addressed by the MAC-layer address of the destination and source stations. To provide similar functionality, LAN emulation (LANE) must support some form of MAC-to-ATM address mapping. All LANE client and server components must therefore have a unique ATM address.

The ATM switch router provides a means of automatically assigning ATM addresses for LANE components. See the "Addressing" section.

Manually Configured ATM Addresses

The following situations require manually configuring the ATM address:

To connect to another system using IISP. Using IISP means that PNNI must be disabled, so there is no ILMI support. In this case the ATM address must be manually configured. For further details, see the chapter "ATM Routing with IISP and PNNI."
To configure a new ATM address that replaces the previous ATM address and generates a new PNNI node ID and peer group ID for migrating from flat to hierarchical PNNI.
To connect to multiple levels of a PNNI hierarchy.
To connect to a service provider network that requires you to use their addressing scheme.
To use a particular style of addressing. For instance, in some circumstances a mnemonic scheme might be useful for identifying nodes in an ATM network.

For instructions on manually configuring the ATM address, refer to the ATM Switch Router Software Configuration Guide. See the "Obtaining ATM Addresses" section in this guide for information about registered ATM addresses.

Caution
ATM addressing can lead to conflicts if not configured correctly. The correct address must always be present. For instance, if you are configuring a new ATM address, the old one must be completely removed from the configuration. Also, it is important to maintain the uniqueness of the address across large networks.

Signaling and E.164 Addresses

The NSAP encoded E.164 ATM address format includes an embedded E.164 address (see Figure 2-3), the form of address generally used in telephone networks. Private networks can use this address format by taking an assigned E.164 address from a service provider and using the ESI part of the ATM address space to identify local nodes. The ATM switch router also includes support for E.164 translation, which allows networks that use private ATM addresses (DCC, ICD, or NSAP-encoded E.164) to work with networks that use E.164 native addresses. E.164 native addresses are used in many public TDM networks and in ATM-attached PBX devices.

E.164 numbers, or native E.164 addresses, are in ASCII format and conform to ITU E.164 specifications. They have the following properties:

Contain 7 to 15 digits, integers 0 through 9
Result equals one digit per byte; for example, 1-800-555-1212 is encoded as 3138303035353531323132

These properties are carried in the called and calling party address IEs, which are part of the signaling packets used to set up a call. Native E.164 addresses are supported on UNI and Interim Interswitch Signaling Protocol (IISP) interfaces. PNNI does not support E.164 addresses directly, but uses the NSAP encoded (embedded) E.164 format. For information on using E.164 addresses with PNNI, see ""ATM Routing with IISP and PNNI."

Embedded E.164 addresses are of two types:

E164_AESA---An AESA address with an embedded E.164 number; for example, 45.000007654321111FDDDDDDDD.CCCCCCCCCCCC.00. The "D" and "C" characters in this example represent an end system address.
E164_ZDSP---An E164_AESA address with all zeros after the embedded E.164 number; for example, 45.000001234567777F00000000.000000000000.00. ZDSP means "zero domain specific part."

When a call traverses a public ATM network with E.164 native addresses, the addresses must be translated between the private and public formats. In Figure 2-7, a call from private network A must traverse the public ATM network to reach private network B. When the call leaves the switch at the end of the private network of egress, the NSAP source and destination addresses are translated into E.164 format, while preserving the NSAP source and destination addresses, carried in the IE part of the signaling packet. At the ingress switch, the address is translated back into the NSAP format used on private network B.

Figure 2-7: Address Remapping Across a Public ATM Network

E.164 Address Conversion Options

The ATM switch router provides three options for performing the address translation needed between private and public addresses. The feature you choose depends on the address format you are using on your ATM network. The features are as follows:

E.164 gateway---Use this feature when addresses are in ICD or DCC format and a call must traverse an E.164 network.
E.164 address autoconversion---Use this feature when addresses are in E164_ZDSP or E.164_AESA format and a call must traverse an E.164 network.
E.164 address one-to-one translation table---Use this feature to create an E.164 to NSAP address translation table manually. This feature is not recommended for most networks.

The E.164 Gateway Feature

The E.164 gateway feature allows calls with AESAs to be forwarded, based on prefix matching, on interfaces that are statically mapped to E.164 addresses. To configure the E.164 gateway feature, you first configure a static ATM route with an E.164 address, then configure the E.164 address to use on the interface. When a static route is configured on an interface, all ATM addresses that match the configured address prefix are routed through that interface to an E.164 address.

Figure 2-8 illustrates how the E.164 gateway feature works. The AESA address is used to initiate the call at the ingress to the public network. The public network routes the call based on the E.164 address. Signaling uses the E.164 address in the called and calling part IEs, and uses AESA addresses in the called and calling part subaddress IEs. The AESA address is used to complete the call at the egress from the public network.

Figure 2-8: E.164 Gateway Conversion Example

When the E.164 gateway feature is configured, the ATM switch router first attempts to make a connection using the E.164 gateway feature. If that connection fails, the switch attempts to make the connection using the E.164 address autoconversion feature, as described in the following section.

Configuration Overview

Configuring the E.164 gateway feature requires the following steps:

Step 1 Configure a static route with a 13-byte ATM address prefix on an interface with an E.164 address.

Step 2 Enter interface configuration mode for outgoing interface and assign the E.164 address to the interface.

The E.164 Address Autoconversion Feature

The E.164 address autoconversion feature uses the embedded E.164 in the E164_ZDSP or E164_AESA address to perform the address conversion. To configure this feature, you set up a static route prefix with the E.164 address, then enable the E.164 autoconversion feature.

The E.164 portion of an E.164 ATM address is the first 15 digits following the authority and format identifier (AFI) of 45, shown in Figure 2-9. The E.164 portion is right justified and ends with an "F." If all fifteen digits are not being used, the unused digits are filled with zeros. In Figure 2-9, the embedded E.164 number is 1234567777, but it is signaled at the egress of the switch and in the E.164 public network as 31323334353637373737.

Figure 2-9: E.164 Portion of an E.164 ATM Address

The autoconversion process differs slightly between the E164_ZDSP and E164_AESA address formats. Table 2-1 compares the E.164 address autoconversion process by address type. The main difference between the two types is the way the IEs are signaled at the egress of the switch, as described in the second row of Table 2-1.

Note During the final conversion process, the calling AESA and called AESA return to their original values.

Table 2-1: E164_ZDSP and E164_AESA Address Autoconversion Comparison
Action E164_ZDSP E164_AESA

Originates as

Calling AESA: 45.000001234567777F00000000.000000000000.00

Calling subaddress: None

Called AESA: 45.000007654321111F00000000.000000000000.00

Called subaddress: None

Calling AESA: 45.000001234567777FAAAAAAAA.BBBBBBBBBBBB.00

Calling subaddress: None

Called AESA: 45.000007654321111FCCCCCCCC.DDDDDDDDDDDD.00

Called subaddress: None

Signaled at egress of switch as

Calling E.164: 31323334353637373737

Calling subaddress: None

Called E.164: 37363534333231313131

Called subaddress: None

Calling E.164: 31323334353637373737

Calling subaddress: 45.0000012345677777FAAAAAAAA.BBBBBBBBBBBB.00

Called E.164: 37363534333231313131

Called subaddress: 45.000007654321111FCCCCCCCC.DDDDDDDDDDDD.00

Converted back at ingress of switch to

Calling AESA: 45.000001234567777F00000000.000000000000.00

Calling subaddress: None

Called AESA: 45.000007654321111F00000000.000000000000.00

Called subaddress: None

Calling AESA: 45.000001234567777FAAAAAAAA.BBBBBBBBBBBB.00

Calling subaddress: None

Called AESA: 45.000007654321111FCCCCCCCC.DDDDDDDDDDDD.00

Called subaddress: None

Table 2-1: **E164_ZDSP and E164_AESA Address Autoconversion Comparison**
Action	E164_ZDSP	E164_AESA
Originates as	Calling AESA: 45.000001234567777F00000000.000000000000.00 Calling subaddress: None Called AESA: 45.000007654321111F00000000.000000000000.00 Called subaddress: None	Calling AESA: 45.000001234567777FAAAAAAAA.BBBBBBBBBBBB.00 Calling subaddress: None Called AESA: 45.000007654321111FCCCCCCCC.DDDDDDDDDDDD.00 Called subaddress: None
Signaled at egress of switch as	Calling E.164: 31323334353637373737 Calling subaddress: None Called E.164: 37363534333231313131 Called subaddress: None	Calling E.164: 31323334353637373737 Calling subaddress: 45.0000012345677777FAAAAAAAA.BBBBBBBBBBBB.00 Called E.164: 37363534333231313131 Called subaddress: 45.000007654321111FCCCCCCCC.DDDDDDDDDDDD.00
Converted back at ingress of switch to	Calling AESA: 45.000001234567777F00000000.000000000000.00 Calling subaddress: None Called AESA: 45.000007654321111F00000000.000000000000.00 Called subaddress: None	Calling AESA: 45.000001234567777FAAAAAAAA.BBBBBBBBBBBB.00 Calling subaddress: None Called AESA: 45.000007654321111FCCCCCCCC.DDDDDDDDDDDD.00 Called subaddress: None

Figure 2-10 shows an example of an E164_ZDSP address autoconversion. In Figure 2-10, a call (connection) from end system A is placed to end system B on the other side of an E.164 public network. The call originates as an E.164 ATM address and is signaled in native E.164 format at the egress port of switch A and within the E.164 public network. When the call reaches the ingress port of switch B, at the edge of the E.164 public network, the call is converted back to E.164 ATM address format.

Note The ATM switch router routes calls based on the E.164 ATM address (not the native E.164 address).

Figure 2-10: E164_ZDSP Address Autoconversion Example

Figure 2-11 shows an example of an E164_AESA address autoconversion. In Figure 2-11, a call from end system A is placed to end system B on the other side of an E.164 public network. The call originates as an E.164 ATM address at the egress port of switch A and within the E.164 public network:

The E.164 ATM address is signaled in native E.164 format.
The called party address (45.000007654321111F...) IE is put in the called party subaddress IE.
The calling party address (45.000001234567777F...) IE is put in the calling party subaddress IE.

When the call reaches the ingress port of switch B, at the edge of the E.164 public network, the call is converted back to E.164 ATM address format and the following events occur:

The native E.164 address is converted back to an E.164 ATM address.
The called party subaddress (45.000007654321111F...) IE is returned to the called party address IE.
The calling party subaddress (45.000001234567777F...) IE is returned to the calling party address IE.

Figure 2-11: E164_AESA Address Autoconversion Example

Configuration Overview

Configuring the E.164 autoconversion feature requires the following steps:

Step 1 Configure a static route with a 13-byte prefix on an interface.

Step 2 Enter interface configuration mode for the interface and enable E.164 autoconversion.

The E.164 Address One-to-One Translation Table Feature

The one-to-one translation table provides a way for signaling to look up the E.164 addresses and the AESA addresses in a database, allowing a one-to-one correspondence between AESA addresses and E.164 addresses. To configure this feature, you configure specific interfaces to use E.164 translation, then set up and add entries to the E.164 translation table.

Caution
Manually creating the E.164 to AESA address translation table can be a time consuming and error-prone process. While it might be needed in some circumstances, we strongly recommend that, when possible, you use either the E.164 gateway or E.164 autoconversion feature instead of the E.164 one-to-one address translation feature.

During egress operation, when a signaling message attempts to establish a call out an interface, the called and calling party addresses are in AESA format. If the interface has been configured for E.164 translation, signaling attempts to find a match for the AESA addresses. If found, the E.164 addresses corresponding to the AESA addresses are placed into the called and calling party addresses. The original AESA addresses are also placed into the called and calling party subaddresses.

During ingress operation, if the interface is configured for E.164 translation, the called and calling party addresses are in E.164 format. If the original AESA-formatted called and calling addresses have been carried in subaddresses, then those addresses are used to forward the call.

If subaddresses are not present because the network blocks them, or because the switch at the entry to the E.164 network does not use subaddresses, signaling attempts to find a match for the AESA address in the ATM E.164 translation table.

If matches are found, the AESA addresses corresponding to the E.164 addresses in the translation table are placed into the called and calling party addresses. The call is then forwarded using the AESA addresses.

Configuration Overview

Configuring the E.164 address one-to-one translation feature requires the following tasks:

Step 1 Select the interface to configure and enter interface configuration mode.

Step 2 Enable E.164 translation.

Step 3 Enter E.164 translation table configuration mode.

Step 4 Add the entries to the translation table. Each entry contains an E.164 address and corresponding NSAP address.

Obtaining ATM Addresses

To satisfy the uniqueness requirement and facilitate distribution, a number of registration authorities administer ATM addresses. These addresses are usually distributed in sets of addresses having a common prefix. The uniqueness of the prefix, which is used to define a group of addresses, is ensured by the registration authority. The recipient then allocates the remaining part of the ATM address using an addressing scheme that is appropriate for the private network to create a set of unique addresses. If these guidelines are followed, private ATM networks can achieve global ATM interconnection without the need to renumber addresses. At the end of this section are some references that contain information on how to obtain a globally unique ATM prefix.

AESA prefixes are differentiated by ownership, as follows:

Customer-owned ATM prefix---a prefix allocated directly to a private network by a national or world registration authority.
Service provider ATM prefix---a prefix allocated to a service provider by a national or world registration authority. An ATM service provider might suballocate part of its address space to its customers.
Unregistered ATM prefix---a prefix, or an extension of such a prefix, that is not obtained from a national or world registration authority. Private ATM networks can use unregistered prefixes to derive unregistered addresses, but these addresses are only used within that private network because they are not guaranteed to be globally unique.

If you have a private network, you can obtain ATM prefixes from the following:

An ATM service provider. Any AESA format is acceptable.
The national registration authority. In the USA, the national registration authority is American National Standards Institute (ANSI). In the United Kingdom, the national registration authority is the Federation of the Electronics Industry (FEI).

A customer owned ATM address (assigned by Cisco) is preconfigured on every ATM switch router. If you are not implementing hierarchy in your PNNI network and do not plan to interconnect to a global ATM internetwork, you can use the preconfigured ATM address.

ATM service providers can obtain the following types of ATM addresses:

E.164 numbers or E.164 AESAs from the ITU or the national numbering authority.
ICD AESAs from the British Standards Institute (BSI) by way of a national registration authority.
DCC AESAs from the national registration authority. In the USA, the national registration authority is ANSI. In the United Kingdom, the national registration authority is FEI.

A good source for an ICD ATM prefix is the IOTA scheme administered by BSI. It is preferable to US DCC AESAs. The documentation on how to get an organizational identifier and how to construct a AESA from the organizational identifier is also easier to follow for IOTA than that for US DCC AESAs. For more information, see http://www.bsi.org.uk/disc/iota.html.

The following additional publications can also provide guidance on how to obtain a globally unique ATM prefix:

"ATM Forum Addressing User Guide," STR-RA-ADDR-USER-001.02, Straw Ballot, October, 1998.
"ATM Forum Addressing Reference Guide," STR-RA-ADDR-01.08, Straw Ballot, October, 1998.

Table of Contents

ATM Signaling and Addressing

Configuration Overview

Configuration Overview

Configuration Overview