Table Of Contents
Physical Components of a PNNI Node
PNNI Routing and ATM Switched Virtual Circuits
Interim Inter-Switch Protocol Routing
Hello and PNNI Topology State Elements
Choosing ATM Addresses for PNNI
Automatic Protection Switching
PNNI Node Software Architecture
Virtual Switch Interface Protocol
SVC with Mixed PNNI and IISP Networks
PNNI and AutoRoute Coexistence on the Network
User Interfaces and Network Management
Configuration and Network Management Tools
Real-Time Cell Statistics and Call Statistics
PNNI Overview
PNNI (Private Network to Network Interface) is the ATM Forum protocol that defines how different ATM switches should interconnect in a private network. PNNI also determines how different private ATM networks should interconnect. The PNNI protocol is based on ATM User-Network Interface (UNI) and Network-to-Network Interface (NNI) specifications. It goes beyond them, however, to include detailed exchanges of routing information. Through PNNI, you can select the complete end to end route and specify the corresponding signaling messages.
Cisco PNNI nodes use the PNNI routing protocol to establish connections. Defined by the ATM Forum for ATM networks, PNNI is a dynamic routing protocol that responds to changes in network resource availability, and scales to large networks.
Note
PNNI (Private Network-Network Interface) is also known as Private Network to Node Interface.
UNI and NNI Interfaces
The UNI is the service interface for ATM customer premises equipment (CPE) connected to the PNNI node. UNI defines the signaling method which the CPE must use to request and set up switched virtual circuits (SVCs) and soft permanent virtual circuits (SPVCs) to PNNI nodes through the wide-area ATM network. UNI prevents network congestion by sending the following information from the network to the CPE (such as a user device):
•
•
Each UNI port in a PNNI node can support 16 ATM end systems addresses.
For ATM SVCs/SPVCs, the UNI supports either the ATM Forum 3.0 or 3.1 signaling standards as well as traditional ATM PVCs.
NNI is the interface to other PNNI nodes or foreign ATM switches. The WAN Service Node supports Interim Interswitch Signaling Protocol (IISP) 3.0 /3.1 or the PNNI. These NNI interfaces provide the switching and routing functions between Cisco WAN switching networks and other networks. Information passing across an NNI is related to circuit routing and status of the circuit in the adjacent network.
Note
Physical Components of a PNNI Node
Two PXM cards must reside in a node to enable redundant PNNI functionality. Line and service cards are not applicable to PNNI operations and cannot be installed in the PNNI controller.
Note
PXM Cards
The active PXM card controls the node and runs the PNNI and SVC software. The standby PXM provides backs up the active PXM if it fails.
Figure 1-1 PXM1 Backcard Simple Block Diagram
A mismatch between the uplink back card type and that of the PXM will generate a major alarm. (The PXM has a daughter card that is factory installed and must match the ATM interface backcard.)
PNNI Routing and ATM Switched Virtual Circuits
The PNNI nodes add PNNI routing and ATM SVCs to a traditional Cisco WAN switching network. The network created with PNNI nodes is enhanced for SVCs/SPVCs, and it supports traditional ATM and Frame Relay PVCs in a separately partitioned AutoRoute network.
ATM SVCs are ATM connections that are established and maintained by a standardized signaling mechanism between ATM CPE (ATM end systems) across a Cisco WAN switching network. ATM SVCs are set up in accordance with user demand, and removed when calls are completed, thus freeing network resources.
SPVCs are persistent ATM connections established by the PNNI routing database and signalling across a Cisco WAN switching network. PNNI node resources, such as port virtual path identifier (VPI) range, bandwidth, and trunk bandwidth, are partitioned between SVCs/SPVCs and PVCs. Resource partitioning provides a firewall between PVCs and SVCs/SVPs so that problems with CPE or large bursts do not affect the robustness and availability of PVC services. Bursty data for either PVCs or SVCs/SPVCs can always use any unused link bandwidth, regardless of partitioning.
ATM Routing and Signaling
For ATM SVCs/SPVCs, the PNNI node uses the Private Network-to-Network Interface. PNNI is a dynamic routing protocol specified for use between private ATM switches (for example, Cisco PNNI nodes), and between groups of private ATM switches. PNNI defines the following two protocol categories:
Topology State Routing
Topology state routine distributes topology information between switches and clusters of switches. This information is used to compute paths through the network. PNNI automatically configures itself in networks in which the address structure reflects the topology. PNNI topology and routing are based on the well known link-state routing technique. See Chapter 2, "ATM Routing," for more information about PNNI routing protocol.
PNNI Signaling
PNNI signaling defines the message flows used to establish point-to-point connections across the ATM network. This protocol is based on the ATM Forum UNI signaling and supports source routing, crankback, load balancing, and alternate routing of call setup requests in case of connection setup failure.
Interim Inter-Switch Protocol Routing
Interim Inter-switch Protocol (IISP) is a static routing protocol defined by the ATM Forum to provide base level UNI signaling between switches until PNNI was specified. IISP is sometimes referred to as PNNI Version 0. The IISP provides users with a fundamental level of multi-vendor switch interoperability based on the existing ATM Forum UNI 3.1 specifications. IISP assumes no exchange of routing information between switching systems. It uses a a fixed routing algorithm with static routes. Routing is done on a hop-by-hop basis by matching the call setup destination address with address entries in the next hop routing table in the given switching system. Entries in the next hop routing table are manually configured. See Chapter 2, "ATM Routing," for more information about IISP.
Dynamic and Static Addressing
PNNI supports two methods of address assignment: static and dynamic.
Static Addressing
In static addressing, you use the IISP (PNNI 0) protocol to assign prefixes to any static node(s). Nodes so configured can still run proprietary SPVCs over ILMI using PNNI. In some cases, static addressing may be advisable; for example, for large nodes with UNI connections to server farms that are frequently accessed by network applications (for example, database servers) for border nodes (nodes that are trunked to other networks).
Hello and PNNI Topology State Elements
On bringup, PNNI nodes send their neighbor Hello packets that include their status and capabilities. They also flood their peer group with PNNI topology state elements (PTSEs) to disseminate topology database information in the ATM network. The Hello protocol is used by PNNI to detect and maintain adjacency between PNNI nodes. When the PNNI nodes discover they are members of the same peer group, they form an inside link.
When the Hello protocol has declared the link functional, the adjacent PNNI nodes exchange a summary of their database contents. This synchronization is governed by a master and slave relationship of the PNNI nodes. Nodes exchange database summary packets which contain header information of all PNNI PTSEs in a node database. After this exchange, the nodes check for information that they lack, and differences in the topological databases are updated. When completed, both PNNI nodes have identical topological databases.
A PNNI node newly connected to an existing PNNI network copies its database from its immediate neighbor.
ILMI
The PNNI node uses ILMI to automatically identify which network interfaces are UNI, attached to ATM end systems, and which are NNI, attached to other systems. This information is used by ATM Routing protocols, PNNI, and IISP to automatically discover and bring up interconnected PNNI nodes.
Choosing ATM Addresses for PNNI
Address selection largely determines a WAN topology design, particularly if the WAN employs dynamic addressing. Unfortunately, there is no algorithm that determines which addresses are best chosen for a given architecture. However, a designer should consider the following factors:
•
•
•
•
Automatic Protection Switching
Automatic protection switching (APS), or line redundancy, is the switching of SONET lines from the active to standby to provide hardware line redundancy after an active line fails. This function is defined by the standards GR-253, ITU-G.7683, and ITU-G.841, which describe switching criteria and an in band protocol carried by the K1/K2 bytes, and which apply to OC-3, OC-12, and DS3 interfaces.
Upon detection of failure (for example, LOS, LOF, Line AIS, or bit error rate (BER) in excess of a configured limit) or a signal degradation condition (for example, BER exceeding a configured limit), the hardware will switch from the working line to the protection line, if the working line is the active line and if the protection line is not in alarm.
Y-Cable Redundancy
PNNI nodes support Y-cable port redundancy. To set up port redundancy, install two identical front and back PXM card sets, connecting them with a Y-cable on each paired port.
During normal operation, the primary card set is active and carrying traffic, while the secondary card set is in standby. The primary set configuration is for both the primary and redundant set. If you reset the primary cards, or if the primary card set becomes inactive for another reason, the secondary card set becomes active.
Network Management
Cisco WAN Manager (CWM) and CiscoView are network management applications that can be used to configure, monitor, and manage PNNI nodes. The network management station can be connected to the PNNI node either with directly connected Ethernet interfacing or by using the Cisco WAN Switching IP Relay application.
•
•
•
Cisco WAN Manager
CWM is a suite of WAN multiservice management applications, provides powerful fault, configuration, and performance management for WAN multiservice switches. CWM also provides robust statistics collection, storing the information in an Informix SQL database and allowing simple integration of this data into existing network management and operations systems.
CWM provides element and network management, which can manage Cisco devices seamlessly. CWM provides open interfaces for higher level service management systems.
The CWM desktop graphical user interface (GUI) provides the following applications:
•
•
•
•
•
•
•
CWM provides these functions in an open management environment. CWM runs on Solaris, AIX, and HP-UX platforms, and integrates with HP OpenView and IBM NetView.
Features
This section provides information about the main features of CWM.
From the Cisco WAN Manager interface you can do the following:
•
•
•
Connection Manager
The Connection Manager allows the network manager to add, modify, and delete end-to-end connections. The Connection Manager provides a series of forms-based screens. You select the desired connection endpoints and configure the connection type and class of service (CoS). The end-to-end connection is automatically established, without requiring configuration of the network on a switch-by-switch basis. In addition, each connection's status can be viewed from one endpoint to the other.
Connection management is one of the most challenging issues in ATM network management; ATM networks support so many connections that it can become impossible to administer and manage them. The Connection Service MIB provides integrated automated provisioning of connections based on quality of service (QoS) parameters, such as the type of connection being made, available bandwidth, and the current state of the network.
The Connection Service MIB provides a standard SNMP interface for the WAN ATM network at the service level. Service providers who are responsible for managing the entire shared network can use the Connection Service MIB to integrate with automated Operations Support Systems (OSS) provisioning systems, and to provide Customer Network Management (CNM) views and control (on a per-connection basis).
Statistics Collection Manager
The Statistics Collection Manager (SCM) provides a forms-based interface to establish and modify statistics for the network. You can configure policies such as which statistics to collect, and collection intervals periods for a node, port, or private virtual circuit (PVC). SCM provides extensive error handling and logging capabilities that enable reliable collection of statistics for performance or billing. Additional SCM agent workstations can be installed to gather additional statistics. Each SCM agent can collect over 1 million statistics per hour. Scalability of statistics collection is an important feature of CWM. CWM also provides node utilization reports not based on WingZ.
Access to Cisco IGX, BPX, and MGX Networks
Cisco IGX, BPX, and MGX switches provide an Ethernet 802.3 attachment unit interface (AUI) LAN to CWM for network management control and information. An entire network can be managed through an Ethernet connection on a single WAN switch or through multiple Ethernet interfaces distributed throughout the network. Cisco WAN switches use TCP/IP over Ethernet to communicate between CWM network management workstations and the WAN switch. Telnet support is also available to enable LAN-based workstations to access the IGX, BPX, or MGX management interface.
Out-of-Band Network Management
An entire network can be managed through a connection on a single WAN switch or through multiple interfaces distributed throughout the network. Network Management access to the IGX can be provided either locally, through a direct interface, or remotely. Remote and dial access to any IGX node can be accomplished by connecting a dial modem to the control port. All security management functions of the Cisco IGX, BPX, or MGX platforms are maintained whether access is local or remote.
Virtual Terminal access to any remote IGX from the CWM configuration screen or a VT-100 connected to the control port is supported using the VT command. The VT command will provide network operators with identical control and monitoring capabilities, as if they were locally attached to the switch.
CiscoView
WAN CiscoView is a GUI SNMP-based application that allows you to display configuration and performance information, and perform minor configuration tasks on PNNI nodes. CiscoView provides real-time views of networked Cisco Systems devices. These views continuously update the physical picture of device configuration and performance conditions, with simultaneous views available for multiple device sessions.
Features
This section provides information about the main features of CiscoView.
From the CiscoView interface you can do the following:
•
•
•
•
•
•
CiscoView contains common functions such as selecting main menu options and categories of information for configuring and monitoring. Each device package also has its own menu options and functions.
Command Line Interface
The PNNI command line interface (CLI) configures ATM SVCs, SPVCs, and PNNI routing and signaling on the PNNI node. These commands are described in depth in The Cisco SES PNNI Controller Software Command Reference.
PNNI Node Software Architecture
PXM Software
The PXM software for the BPX SES PNNI Controller contains three major functional blocks (Figure 1-2):
•
•
•
VSI software provides the VSI master application used by the PNNI and SVC/SPVC networking control software to control the switch.
Figure 1-2 PXM Software Architecture
Control Point Software
Control Point software runs on the PXM at the PNNI Controller to provide a single, integrated point of control for the PXM and the PNNI and ATM SVC application software. Its interface enables configuration of the PNNI and ATM SVC parameters for the PNNI node, and the PXM management functions.
This interface takes the form of an application programming interface (API), in which requests to get or send data are made to PNNI and SVC software through a well defined, message-based interface. Additionally, PNNI and SVC software may generate events to the Control Point, for instance for alarm status changes (such as connection routing and rerouting).
The Control Point software enables direct access to the BPX SES PNNI Controller command sets by providing a consistent, integrated SNMP proxy for the platform, and CLI for the service expansion shelf.
PNNI and SVC Software
The PNNI and SVC software architecture consists of three major components:
•
•
•
Call Control Block
The major features implemented in Call Control Block are as follows:
•
•
•
The PNNI controller will use the VSI partition to provide its networking capabilities
•
The major components in call control block are shown in Table 1-2.
PNNI
PNNI exchanges topology and routing information with other nodes. PNNI precalculates a set of possible routing paths for all reachable nodes in the network. The routing information is saved in a routing table of the route agent.
Redundancy Manager
The redundancy manager supports active call redundancy by shadowing the essential data structure information on the standby BPX SES PNNI Controller.
PNNI and SVC Routing Software
The major features included in PNNI Routing Block are as follows:
•
•
•
•
Platform Software
Platform software runs on the PXM at the BPX SES PNNI Controller to provide low-level operation of the system (including resource management and physical redundancy control) and to provide services to the remaining subsystems. These services are categorized as Basic Platform-Specific Configuration and Monitoring Services, and Platform Infrastructure.
Platform-Specific Configuration and Monitoring Services
The platform software provides an API to the management layer (namely, the Control Point software) to allow the configuration and monitoring of cards, ports, redundancy options and any platform-specific features. Also, it enables the platform software to generate asynchronous events to the management layer. This API consists of a message passing request/response protocol running on the PXM card.
Basic Platform Infrastructure
The platform software provides the basic infrastructure for the following:
•
•
•
•
Virtual Switch Interface Protocol
The Virtual Switch Interface (VSI) protocol controls a Cisco WAN switch, such as the Cisco BPX 8600, for networking applications, such as Multiprotocol Label Switching (MPLS) or PNNI routing. With VSI, external controllers control the switch for applications not supported by the proprietary WAN switch set of routing protocols (AutoRoute).
The PNNI Controller uses the VSI protocol to control VC applications by creating a separate control plane, distinct from the standard AutoRoute control plane, that includes all the PNNI nodes in the PNNI network. The PNNI node VSI control plane is the API that separates portable network software from platform-specific software and firmware.
This section describes VSI in the following topics:
•
•
•
System Templates
This section introduces the system templates:
•
•
Note
Service Class Templates
Each switch contains a set of nine Service Class Templates (SCT) that can be downloaded as needed. These SCTs have predefined, nonchangeable values tailored for typical interfaces such as a PNNI trunk or PNNI UNI.
SCT templates contain two classes of data:
•
These parameters are required to establish a per-VC connection. They include entries such as UPC actions, various bandwidth-related items, per-VC thresholds, and hardware-specific items.
•
These parameters provide Quality of Service (QoS) support. Full QoS means each VC is served through one of a number of Qbins. These buffers are differentiated by their QoS characteristics.
The BPX SES PNNI Controller (VSI master) can use the Service Class Templates to configure the ATM connection.
When an ATM SVC connection setup request is received from the VSI Master in the BPX SES PNNI Controller, the VSI slave (as in the BXM) uses the SCT index of the request to retrieve the extended parameters defined in the template for the corresponding index. The slave uses these values to complete the connection setup and program the hardware.
The general types of parameters passed from a VSI Master to a Slave include:
•
•
•
•
Each VC added by a VSI master is assigned to a specific service class by means of a 32-bit service type identifier. Current identifiers are for the following protocols:
•
•
•
When a connection setup request is received from a VSI master controller, the VSI slave uses the service type identifier to index into a Service Class Template database containing extended parameter settings for connections that match the index. The firmware then programs the hardware with the applicable extended parameter values to complete the connection setup.
Note
Qbin Templates
A class of service buffer (Qbin) is specified for each service type to be used. The Qbin buffers separate service types to match the QoS requirements. This mapping defines a relationship between the template and the Qbin interface.
A Qbin template defines a default configuration for the set of Qbins for the logical interface. When a template is assigned to an interface, it includes the corresponding default Qbin configuration. Some of the interface's Qbin configuration parameters can be changed on a per interface basis. Such changes affect only that interface's Qbin, and no others. Changes do not affect the Qbin templates.
Only Qbin templates are used with Qbins available to VSI partitions, namely Qbins 10 to 15. Qbins 10 to 15 are used by the VSI (on interfaces configured as trunks or ports. Qbins 0 to 9 are reserved for and configured by AutoRoute.
AutoRoute and PNNI
This section introduces the major ATM SVC applications supported by the PNNI controller:
•
•
•
•
SVC with PNNI Routing
The PNNI node supports SVC applications with PNNI routing (Figure 1-3). PNNI routing protocol runs between ATM switches. ATM switches exchange network topology information and routing information via PNNI routing protocol. The routing path from a calling CPE to a called CPE is selected dynamically based on network traffic and resource conditions.
Note
Figure 1-3 PNNI Network
SVC with Mixed PNNI and IISP Networks
When SVC applications contain both IISP and PNNI networking, IISP runs on the edge of a PNNI network and interconnects nonPNNI networks via a backbone PNNI network (Figure 1-4). IISP maintains a set of static routing tables to direct signaling between a non PNNI network and a PNNI network. Such static routing information can be advertised into PNNI network through boundary switches (switches #4 and #6 in the illustration). With static route advertising, the end system A on the non PNNI network #a can place a call to the end system C on the non PNNI network #b. Because the PNNI network is running PNNI 1.0 Signaling, and IISP is based on UNI 3.1 Signaling, IE mapping between PNNI 1.0 and UNI 3.1 occurs on the boundary switches #4 and #6.
Figure 1-4 PNNI Network with IISP Trunks
PNNI and AutoRoute Coexistence on the Network
A PNNI network allows both PNNI and AutoRoute networks in the same physical network (Figure 1-5). The illustration shows switches #1 through #6 all participating in the PNNI network, while switches #4, #5, and #6 are part of AutoRoute network. The trunks between switch #4 and switch #5, and between switch #5 and switch #6, carry both AutoRoute and PNNI traffic on the same physical trunk. The trunk bandwidth is partitioned between AutoRoute and PNNI traffic at trunk initialization stage.
Figure 1-5 Mixed AutoRoute and PNNI Networks
User Interfaces and Network Management
The following tools are used to control and manage the PNNI node:
•
•
These tools are used at the PNNI node and in CiscoView.
Configuration and Network Management Tools
All user interfaces use control point software to access the BPX SES PNNI Controller. The control point software interacts with the PNNI, SVC, VSI, and platform software.
The three main interfaces used to configure and operate an PNNI node are as follows:
1.
The CLI can be used for low-level configuration and access to the PNNI Controller.
2.
The Cisco WAN Manager provides network management functions for a PNNI network. These features include the following:
–
–
BPX/MGX 8850 traps and using the existing applications on the CWM.–
–
–
Note
3.
CiscoView can configure some aspects of a BPX SES PNNI Controller, PNNI routing, and ATM SVCs/SPVCs.
Provisioning Data Saving
Configuration data is written to the disk and the DRAM when configuration is changed. This data is used to initialize the PXM1 upon reset. Configuration data can be saved on an external server, such as CWM, via configuration upload. Configuration data can also be saved in a separate file and restored later if necessary.
System Error Log
The BPX SES PNNI Controller maintains a log of system errors in BRAM. This log contains crucial system details, and should be read prior to a system reset.
Real-Time Cell Statistics and Call Statistics
CWM provides remote access to the following:
•
•
Event Log
The BPX SES PNNI Controller logs system events on the system disk.
SNMP
The PNNI Controller complies with SNMP VI.
SNMP Error Log
The SNMP error log provides SNMP error details to the Cisco WAN Manager. CWM maintains a sequential log ordered list of Error Events for each SNMP Manager.
Trap/Alarm Log
Alarms generated by the BPX SES PNNI Controller are mapped into traps and sent to the CWM. The PNNI node provides support for Robust Trap Messages. Trap messages are maintained in a circular buffer, with the latest message overwriting the oldest. Each trap is labelled with a sequence numbers. By using these sequence numbers, management stations can request previously issued traps that they have not received.
Auto Configuration
The PNNI nodes are preconfigured with Cisco ATM address prefixes, which combine with the preconfigured MAC address of the switch to form a unique node identifier. These identifiers are used to configure attached ATM end systems and to automatically bring up the PNNI routing hierarchy for simple network configurations.
