PNNI Network Planning Guide for MGX and SES Products, Release 5.1
Chapter: Introduction to PNNI
Introduction to PNNI
Private Network-to-Network Interface (PNNI) 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.
This chapter introduces the PNNI network database and the following common network topologies:
•
The Single Peer Group Topology
•The Hierarchical PNNI Network Topology
•PNNI Internetworking with AINI
•PNNI Internetworking with IISP
This chapter also provides guidelines on how you can apply these topologies using the following switches:
•Cisco MGX 8830 (PXM1E) Release 3.0 and higher
•Cisco MGX 8830 (PXM45) Release 5.1 and higher
•Cisco MGX 8850 (PXM1E) Release 3.0 and higher
•Cisco MGX 8850 (PXM45) Release 2.0 and higher
•Cisco MGX 8880 Media Gateway Release 5.0 and higher
•Cisco MGX 8950 with Release 2.1.60 or later software
•Cisco BPX 8600 and Cisco Service Expansion Shelf (SES) with SES Release 1.0 or later software
The PNNI Network Database
PNNI is commonly referred to as a link state protocol, which means that the protocol collects information about the current state of links and nodes in the network to build a network database. The PNNI network database can be used to determine the network structure and the current state of network components. To build the PNNI network database, each PNNI node must receive topology information from all the other devices in the network. To keep the database current, the node must receive regular updates from other nodes.
Tip A node is a network device that communicates with other network devices. Cisco PNNI-compatible devices serve as nodes in a PNNI network. In this document, the terms node and switch are often used interchangeably. However, in most cases, the PNNI node is a component of a Cisco PNNI-compatible device. For example, some Cisco MGX switches, Release 2.0 and later, can operate as both a PNNI node and as an MPLS device.
The PNNI protocol communicates the state of a PNNI network in PNNI Topology State Elements (PTSEs). PTSEs are discrete messages that contain information about one of the following types of network components:
•PNNI nodes
•Reachable addresses
•PNNI links between nodes
To enable communications with other nodes, each switch needs to have all the PTSE information for each switch in the network. Each node is responsible for flooding out its own PTSE information to all the other switches in the network.
Since up-to-date PTSE information is required for optimal routing decisions to be made, there are several different mechanisms in place to help ensure that all nodes have reasonably accurate PTSE information. The five common reasons for updating PTSEs are as follows:
•Resources administratively added, removed or altered on a node.
•Resource failure such as an Loss of Signal (LOS) on a link.
•A significant change in link resources due to virtual circuits (VCs) routing or derouting.
•Periodic updates defined by the PTSE refresh and PTSE lifetime interval timers.
•A processor switch module (PXM) switchover.
PTSE information is passed between nodes using PNNI Topology State Packets (PTSPs). These packets utilize the Routing Control Channel (RCC; VPI = 0 and VCI = 18) between adjacent nodes. The RCC is also used for Hello packets and other PNNI messages. If the switch is unable to establish the RCC with the adjacent node, then PTSE information is not exchanged. Once a node receives PTSE information, the node stores the contents, or element information, in the database. This information is used to generate precomputed routing tables that identify routes to other network devices. The PNNI database is also used to perform on-demand routing when the appropriate routing table does not contain a viable path.
The Single Peer Group Topology
A single peer group topology is a PNNI network in which all nodes share PTSEs 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. Figure 1-1 shows an example single peer group topology.
Figure 1-1 Example Single Peer Group Topology
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 up to 160 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 Network Topology
•PNNI Internetworking with AINI
•PNNI Internetworking with IISP
The hierarchical PNNI topology enables multiple PNNI peer groups to communicate with each other, and this increases the total size of the network. The ATM Inter-Network Interface (AINI) and Interim Inter-Switch Protocol (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.
The Hierarchical PNNI Network Topology
A hierarchical PNNI network is a topology that interconnects multiple PNNI peer groups to form a larger network. Figure 1-2 shows an example hierarchical PNNI network topology that interconnects multiple peer groups.
Note Hierarchical PNNI networks are not supported on Cisco MGX 8850 switches before Release 2.1.60, and they are not supported on the SES PNNI Controller before Release 1.1.60.
Figure 1-2 Example Hierarchical PNNI Network Topology Showing Multiple Peer Groups
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.
In a hierarchical network, the database for each peer group is smaller because the peer group collects, stores and processes PTSEs for only those nodes in the same peer group. The nodes within a peer group do receive information on other peer groups, but the information is summarized. From the perspective of an individual peer group, other peer groups appear to be single nodes. Nodes within one peer group do not receive PTSEs from other peer groups and therefore do not collect, store, and process information about all the individual nodes and links in other peer groups.
The Cisco switches described in this guide support up to 32 visible peer groups in one network. (The specifications for Cisco switches are described in Table 2-1 in "Interoperability and Performance Planning.") A visible peer group is a peer group with which the local peer group can communicate. Because each visible peer group appears as a logical group node (LGN), each visible peer group reduces the available node count for a peer group. For example, if the local peer group discovers 32 visible peer groups, the node count for the local peer group is reduced to 128 (160 - 32 = 128).
Figure 1-3 demonstrates why a multiple peer group PNNI network is called a hierarchical PNNI network.
Figure 1-3 Example Hierarchical PNNI Network Topology Showing a Two-Level Hierarchy
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. PNNI divides the entire network database into manageable chunks, and the portions that describe communications between peer groups are managed by LGNs that operate at levels above the lowest-level peer groups.
Within each level 56 peer group in Figure 1-3, all the nodes exchange PTSEs to build and maintain a PNNI database that describes communication paths to all other nodes within the peer group. However, individual peer group nodes do not exchange PTSEs with nodes outside their peer group. Instead, LGNs are created during configuration to operate at level 40 and communicate with other level 40 nodes.
The level 40 nodes in Figure 1-3 are all part of the same level 40 peer group and exchange PTSEs in the same way as do the lower level nodes. The level 40 LGN for each peer group in Figure 1-3 is called a peer group leader and provides summarized information to its child peer group about the other peer groups represented at level 40. Each peer group leader also provides summarized peer group information about its child peer group to the other peer group leaders at the same level. Peer Group 1, for example, learns about 8 nodes: 4 physical nodes are in its own peer group, and 4 LGNs are actually representing other peer groups.
To demonstrate how hierarchical networks support more nodes than single peer group networks, consider the two-level example in Figure 1-3. A single peer group can support 160 nodes. In Figure 1-3, there are 5 peer groups, so each peer group will learn about 4 LGNs that will represent the other peer groups. This allows each peer group to support up to 156 physical nodes (160 - 4 = 156). The hierarchical network in Figure 1-3 can support 780 physical nodes (156 * 5 = 780).
Hierarchical networks can support thousands of nodes because each higher level summarizes information for all lower levels. For example, suppose a level 64 peer group were added below Peer Group 2 in Figure 1-3. All nodes in the new level 64 peer group would be summarized by the peer group leader for Peer Group 2. The impact on the hierarchical network would be the following:
•Peer Group 2 would support one less physical node because it would have to add one LGN to represent the level 64 child peer group.
•The level 64 child peer group could support as many as 155 physical nodes (160 nodes - 1 LGN for each of the 5 peer groups at the higher levels.
•There would still be plenty of room for adding more physical nodes to levels above and below those shown in Figure 1-3.
The following sections provide additional information the peer group leaders that operate at higher levels in a PNNI hierarchy and introduce the border nodes that connect one peer group to another.
Peer Group Leaders
A peer group leader (PGL) is a higher level node (such as the level 40 nodes in Figure 1-3) that summarizes data for a child peer group (such as the level 56 nodes in Figure 1-3). A child peer group is a peer group that operates one level below the PGL that supports it. Each PGL works with other PGLs at the same level to build and maintain network data that it summarizes and distributes to its child peer group. The PGL also receives summarized data from a parent PGL if another level exists above the PGL's level. Network data from levels above the PGL is also summarized and distributed to child peer groups.
Network administrators can use configuration commands to control which node becomes the PGL. The configuration process assigns a PGL election priority to each node in the peer group. When PNNI nodes start up, an election is held to determine which node has the highest PGL priority, and that node becomes the PGL. If the PGL node fails, a new election is held among the operating nodes to determine a new PGL. There is just one peer group leader for each peer group.
Each higher level peer group is made up of LGNs that represent the peer groups at the next lower level. These LGNs collect and manage information that is needed to communicate with the peer groups represented. As with the lowest level, these LGNs elect a PGL, which is responsible for determining communications paths to PNNI groups not represented within the peer group.
Note Network administrators add higher levels by adding LGNs with the addpnni-node command. The PGL election priority is configured with the cnfpnni-election command.
The PGL task adds to the work load of a PNNI node. The PGL must not only collect and manage data for communications outside the peer group, it must also collect and manage data for communications within the peer group. Because the PGL task adds to the work load of a PNNI node, it is good design practice to choose peer group leaders (and backup peer group leaders) carefully. Consider reducing the load on switches that serve as peer group leaders, and avoid using border nodes as peer group leaders.
Simple Node Representation
When a LGN presents its child peer group information to other peer groups, the default representation is called simple node representation. To other peer groups, the local peer group is represented as a single node with no nodal state parameters. Figure 1-4 illustrates simple node representation.
Figure 1-4 Simple Node Representation
Other peer groups receive information about the outside links leading to the local peer group, but no internal peer group information is advertised to other peer groups. The advantage of simple node representation is that it keeps the PNNI database within each node smaller than that for complex node representation. Simple node representation also requires fewer resources on the LGN that represents the peer group. The disadvantage it that the true cost of crossing a peer group is hidden by simple node representation. In some networks, this can cause connections to be routed over less desirable routes.
Complex Node Representation
The alternative to simple node representation is complex node representation. When complex node representation is enabled for a LGN, the LGN presents additional information about the peer group it represents. Figure 1-5 illustrates complex node representation.
Figure 1-5 Complex Node Representation
The default complex node representation presents the peer group as a node with multiple ports. A logical nucleus is calculated and logical spokes are created between the nucleus and the logical ports that terminate each outside link. When the LGN presents a complex node to other peer groups, those peer groups can pick the path to use through the local peer group. In contrast, when the simple node representation is used, remote peer groups can choose to communicate through the local peer group, but the remote group must rely on border nodes within the local peer group to determine the path within the local peer group.
The advantage to complex node representation is that it provides more information to other peer groups, and this can lead to better route selection. The disadvantage of complex node representation is that it adds to the size of the database in remote peer groups. Complex node representation also requires more processing resources on the LGN that represents a peer group as a complex node.
Border Nodes
Border nodes are nodes that participate in a PNNI peer group and maintain links to other peer groups. A border node is a member of only one peer group. Links to other nodes within a peer group are called inside links, and links to nodes in other peer groups are called outside links. A border node is any node that is configured for outside links.
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 the "Selecting the PNNI Peer Group ID" section of "Address and Closed User Group Planning.") If the peer group IDs are different, both nodes are border nodes for their respective peer groups.
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 160 nodes, but hierarchical networks can support many more 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
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, so the manual configuration makes AINI links more expensive to configure than PNNI 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. Figure 1-6 shows an example of PNNI networking with AINI.
Note AINI networking is not supported on Cisco MGX 8850 switches before Release 2.1.60 and is not supported on the SES PNNI Controller before Release 1.1.60.
Figure 1-6 Example PNNI Internetworking with AINI Topology
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 all UNI 4.0 features.
Note Standards-based IISP supports SVC and SVP connections. Cisco has enhanced IISP to also support CBR1, rt-VBR1, rt-VBR2, rt-VBR3, nrt-VBR1, nrt-VBR2, and ABR SPVC and SPVP 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.
Feedback