Table of Contents

Introduction to PNNI

PNNI (Private Network-to-Network Interface) is a suite of network protocols that can be used to discover an ATM network topology, create a database of topology information, and route calls over the discovered topology. With proper planning, setting up a PNNI network is much easier and faster than manually configuring connections through an ATM network. Although Portable Auto Routing (PAR) can be used to perform topology discovery and call routing, PAR is a proprietary protocol. PNNI is a standards-based protocol that enables interoperation with switches from other vendors and supports far more network switches than PAR.

When planning a PNNI network, you can start by choosing from the following common network topologies:

This chapter introduces these topologies and provides guideline on how you can apply these topologies using the following switches:

Single Peer Group

Figure 1-1 shows an example single peer group topology.

A single peer group topology is a PNNI network in which all nodes share PNNI network information with all other nodes. As each node is brought up in a single peer group network, that node learns about all the other nodes, and the other nodes learn about the new node. All nodes are capable of determining routes to all other nodes within the single peer group.

A single peer group topology is the easiest to set up. Since all communications are between nodes in the same peer group, you do not have to configure connections to other peer groups or to other network types. If the network will never connect to a public network, you can use most of the default PNNI configuration settings.

The Cisco switches described in this guide support from 160 to 256 nodes in a single peer group. The specifications for Cisco switches are described in Table 2-1 in "Interoperability and Performance Planning."

The size of a single peer group is partially limited by the size of the PNNI database and the processing resources required to maintain it. As the size of the peer group grows, the PNNI database within the node grows, as does the PNNI processing requirements. When the network size increases beyond the capabilities of the network nodes, you can connect the single peer group network to other networks to create the following types of topologies:

The hierarchical PNNI topology enables multiple PNNI peer groups to communicate with each other, and this increases the total size of the network. The AINI and IISP protocols enable private PNNI networks to connect to other private or public PNNI networks. The AINI and IISP protocols enable communications between networks, but provide a privacy barrier that keeps the network databases in each network private to that network.

Hierarchical PNNI Network

Figure 1-2 shows an example hierarchical PNNI network topology that interconnects multiple peer groups.

Note   Hierarchical PNNI networks are not supported on MGX 8850 switches before Release 2.1.60 and are not supported on the SES PNNI Controller before Release 1.1.60.

A hierarchical PNNI network is a topology that interconnects multiple PNNI peer groups to form a larger network. The Cisco switches described in this guide support from 159 to an unlimited number of peer groups within one network. (The specifications for Cisco switches are described inTable 2-1 in "Interoperability and Performance Planning.") When you multiply the number of supported peer groups by up to 256 nodes per peer group, you can see that PNNI scales well beyond the limits of PAR.

Notice that the only difference between the single peer group in Figure 1-1 and the hierarchical PNNI network in Figure 1-2 is the grouping of the nodes. This grouping of the nodes creates smaller PNNI databases within the nodes in each peer group and reduces the PNNI processing requirements in each node. This grouping also provides room to add more nodes in each of the groups.

Figure 1-3 demonstrates why a multiple peer group PNNI network is called a hierarchical PNNI network.

In a hierarchical PNNI network, logical levels are used to manage the portions of the PNNI database that describe communications paths between individual peer groups. Within a peer group, all the nodes maintain a PNNI database that describes communication paths to all other nodes within the peer group. However, individual peer group nodes do not store the PNNI data for communications to all other peer groups. Instead, PNNI divides the entire network database into manageable chunks, and the portions that describe communications between peer groups are managed by logical nodes that operate at levels above the lowest-level peer groups.

For example, Peer Groups 1 through 5 in Figure 1-3 operate as single peer groups and store the PNNI data for their respective peer groups. Peer Groups1 through 5 operate at level 56 in this example, and another logical peer group operates at level 40. The level 56 peer group nodes do not store PNNI data about the other peer groups, instead, a logical node at level 40 represents each peer group and communicates with the other logical nodes in level 40 to learn how to communicate with the other peer groups. When a node in Peer Group 1 needs to communicate with a node in Peer Group 5, it refers to the Peer Group 1 representative at level 40, and that representative provides the information the node needs to complete the call.

The following sections describe the peer group leaders that operate at higher levels in a PNNI hierarchy and the border nodes that connect one peer group to another.

Peer Group Leaders

A peer group representative at a higher level is called a peer group leader. Any level above the lowest-level PNNI group is a logical level and the peer group leader is a logical node. In this case, logical equates to a software process. The peer group leader is a separate software process that runs in the lowest-level node. The lowest-level PNNI process manages the PNNI data for the lowest-level peer group. For each higher level, there is a peer group leader software process for that level that manages the PNNI data for that level. When a node needs to communicate outside of its peer group, it refers to the peer group leader for a communications path to the remote peer group.

There is just one peer group leader for each peer group, and that leader is elected when a node starts up or when a peer group leader fails.You can control which node becomes a peer group leader by setting the peer group leader priority for the node. You can also use the peer group leader priority to control the order in which nodes assume leadership if a peer group leader fails.

Because each node in the lowest-level peer group must run the lowest-level PNNI process, it is good design practice to choose peer group leaders carefully, since peer group leaders add another software process to the switch workload. Consider assigning the peer group leader for each higher level to a different node, so that one node is not processing all PNNI levels. Also consider reducing the traffic load on switches that serve as peer group leaders, and avoid using border nodes as peer group leaders.

Border Nodes

Border nodes are nodes that participate in a PNNI peer group and maintain connections to other peer groups. A border node is a member of only one peer group. Connections to other nodes within a peer group are called inside connections, and connections to nodes in other peer groups are called outside connections. A border node is any node that is configured for both inside and outside connections.

PNNI automatically determines whether or not a node is a border node by examining the PNNI peer group ID at each end of a PNNI link. (The PNNI peer group ID is described in "Selecting the PNNI Peer Group ID" in "Address Planning.") If the peer group IDs are different, both nodes are border nodes for their respective peer groups.

As with peer group leaders, a border node is a separate software process that runs on a lowest-layer node and consumes system resources. When planning for border nodes, you might want to avoid routing internal peer group traffic through border nodes so that border nodes have more processing resources for supporting traffic traveling in and out of the peer group.

Hierarchical PNNI Network Benefits

The primary benefit of a hierarchical PNNI network is scalability. Single peer group networks are limited to 256 nodes, but hierarchical networks can support any number of nodes.

For networks with less than 100 nodes, a single peer group will usually provide superior performance over a hierarchical network because an originating node is aware of all routes and can choose the best route. In hierarchical networks, the higher level processes that route calls between peer groups are aware of the peer group structure, but they are not aware of the routes available within the peer groups. Hierarchical networks will always adhere to call requirements, but they may not always route calls over the most optimum route.

PNNI Internetworking with AINI

Figure 1-4 shows an example of PNNI networking with AINI.

Note   AINI networking is not supported on MGX 8850 switches before Release 2.1.60 and is not supported on the SES PNNI Controller before Release 1.1.60.

ATM Inter-Network Interface (AINI) is an industry standard protocol for enabling static routing between separate PNNI networks. AINI only advertises ATM addresses and address groups that are manually configured on AINI links. AINI provides network security and independence by blocking all PNNI advertisements across AINI links. AINI is typically used to enable select communications between two independent networks. For example, AINI links might be used to interconnect two different companies or between a company and a service provider. The cost of AINI links is manual configuration.

PNNI Internetworking with IISP

Interim Inter-switch Protocol (IISP) is the predecessor to AINI and serves the same purpose as AINI, which is to link two independent PNNI networks. Unlike AINI, IISP does not support UNI 4.0 connections. If the border nodes between two independent PNNI networks support AINI, you should use AINI for any links between them. The only time you should use IISP is when one or both of the border nodes do not support AINI.