Cisco Multiservice Switching Networks
| For two or more ATM devices to communicate, it is critical that they be able to locate and identify one another. An ATM address serves a dual role by functioning as an identifier and a locator. Like a license plate, the address signifies the name of the ATM device. Like a zip code, PNNI uses a portion of the ATM End System Address (AESA) to lock in the ATM device's position within the network topology. Address Structures
Before we delve into the specifics of address structure, be aware that ATM addresses are different and independent from the VPI and VCI information included in the ATM cell header. VPI and VCI are not addresses but identifiers, implying the virtual identifier's local significance. An ATM address is significant network-wide, but VPIs and VCIs are significant only across a given point-to-point ATM link. In addition, any time ATM address information must be transported across an ATM network, as is the case in an ATM switched virtual circuit (SVC) call setup message, the ATM address must be segmented and transported inside the same discrete ATM cells that traffic all other data across the ATM infrastructure. The ATM Forum has standardized the length of ATM addresses at 20 bytes. Currently, there are three different standardized formats. Each format defines all the fields in the entire 20-byte address structure. A fourth format known as the local format defines only the first byte of the address and leaves the definition of the remaining 19 bytes to the private organization that chooses to use this format. Structured ATM address formats fall into one of two categoriesthe E.164 address category, used in telephone networks and administered by the ITU-T, or the AESA format. You might have heard the term Network Service Access Point (NSAP) address instead of AESA. NSAPs are address types defined by the International Organization for Standardization (ISO), and AESAs are types of NSAPs. At present, the two standardized AESA types are Data Country Code (DCC) and International Code Designator (ICD). A third AESA type called local allows any network administrator to define the AESA format for private use. Regardless of the format, the first byte of an ATM address signifies the format in use. Appropriately, this first byte is called the Address Format Identifier (AFI). The AFI values for each of the four ATM address formats are shown in Table 8-1.
The three structured address formatsDCC, E.164, and ICD all define the format of the remaining 19 ATM address bytes. All three include the following common fields in the address:
Specifics of the E.164 IDI Field
The IDI portion of the E.164 AESA format carries ISDN numbers in one of three predefined formats: geographic area, global services, and network. Figure 8-1 shows these E.164 IDI formats. All three formats begin with a one-, two-, or three-digit country code (CC) that identifies the telephone number's destination country. Other parts of the geographic format include the national destination code (NDC) and the subscriber number (SN). Appending the SN to the NDC produces a nationally significant telephone number. CCs are allocated to providers that offer a worldwide telephone number to each of their subscribers. These global service providers allocate a global service number (GSN) for each subscriber. Figure 8-1. IDI Format of E.164 AESA
Service providers that are operating networks that span two or more countries and do not have a common telephone numbering plan receive their own CC as well as a two-digit identification code (IC). The ISDN number inside each E.164 IDI is padded on the left with 0s until the number is equivalent to 15 binary coded decimal (BCD) numbers. Each BCD number is 4 bits long. 4 binary 1 bits (1111) are appended to the 0-padded ISDN number to lengthen it to 8 bytesthe size of the IDI field. Figure 8-2 shows the ATM address structure of each of the four formats. Figure 8-2. ATM Address Formats
Using ILMI for Automatic Address Registration
To alleviate the cumbersome task of manually typing a 20-byte ATM address into an end station such as a router, the Integrated Local Management Interface (ILMI) protocol defines a method for automatic address registration and configuration between the ATM end system on one side of the User Network Interface (UNI) and an ATM switch on the opposite side of the UNI. NOTE ILMI stands for Interim Local Management Interface in the ATM Forum "ATM User-Network Interface 3.1 (UNI 3.1)" specification, implying its temporary scope. In version 4.0, ILMI was specified in a separate document called "Integrated Local Management Interface (ILMI) Specification Version 4.0," in which ILMI was renamed to stress the expectation of using ILMI procedures "indefinitely."
The ATM end system requests the network portion of its AESA from the switch. Assuming that the end system attaches to the switch via a dedicated physical link, the switch and end system use the standard full-duplex ILMI VCC of VPI=0, VCI=16 to communicate. In turn, the ATM switch relays the first 13 bytes of the address to the end device. These 13 bytes include the AFI, IDI, and HO-DSP. The end system prefixes these 13 bytes to its own ESI and SEL to form a complete AESA. Typically, the SEL is set to 0. The end station's newly formed AESA is relayed back to the switch via the ILMI protocol, and the switch uses this AESA to route SVC calls to the corresponding end station. Note that with E.164 addressing, the ATM switch supplies the full 20-byte ATM address to the end system. The ATM address is deregistered from the end system and the switch whenever the ILMI link between them fails. Figure 8-3 depicts the address registration process. Deregistration implies that the ATM end system can be relocated and attached to another PNNI-controlled switch without tedious reconfiguration. Figure 8-3. ATM End System Automatic Address Registration Process Using ILMI
In an effort to leverage existing standards, the ILMI protocol employs Simple Network Management Protocol (SNMP) to categorize and relay pertinent information regarding these four areas:
The ATM interface Management Information Base (MIB) is a collection of SNMP Object Identifiers (OIDs) that represent all the relevant attributes associated with these four areas. One device relays information across the ILMI link to the other by attaching that information to the proper OID, encapsulating that OID/information pair inside an SNMP protocol data unit (PDU) and moving that PDU down through the various ATM adaptation layers to the physical layer for transport. Here are some of the configuration attributes relayed across the ILMI link during interface auto-configuration:
|
Категории