PNNI Implementations

This section explores multiservice switching PNNI implementations, focusing on different multiservice switches that natively run PNNI. First we will go through the service expansion shelf (SES) controlling a BPX-8600 switch. Then we will analyze the PXM-45-based MGX-8850 and MGX-8950. Finally, we will review PXM-1E-based PNNI nodes.

The three implementations share the same PNNI software, ensuring picture-perfect interoperability. The PNNI controller interfaces with the controlled switch using VSI. VSI slaves advertise interfaceswhich are partitions of resources of physical or virtual interfaces managed by those VSI slavesto the VSI master. The PNNI software calls these logical interfaces PnPorts. This concept (equivalent to XmplsATM interfaces in an MPLS implementation) allows PNNI software to control those logical interfaces.

Table 3-4 summarizes the multiservice switching PNNI implementations.

Table 3-4. Multiservice Switching PNNI Implementations

Controlled Switch	VSI Slave Model	VSI Slave Location	VSI Master Platform	Controller Location
BPX-8600	Distributed slaves	BXM cards	SES controller	External platform
PXM-1E-based MGX-8850	Centralized slave	PXM-1E	PXM-1E	Controller card
PXM-45-based MGX-8850	Hybrid slaves	AXSMs and PXM-45s	PXM-45	Controller card
MGX-8950	Hybrid slaves	AXSM/B and PXM-45/B	PXM-45/B	Controller card

Currently, no PNNI support is planned for the IGX platforms. PNNI support for UXM cards using a SES controller is a feasible development, but support for all other IGX cards (such as Universal Frame Relay Module [UFM]) would entail developing a more powerful NPM controller card.

SES Controller: BPX-8600 PNNI Implementation

The SES enables PNNI networking on a BPX-8600. The SES uses PXM-1 redundant cards with PNNI and VSI software, and it has the same form factor as an MGX-8230.

The architecture of a BPX-8600/SES PNNI node is equivalent to the LSC controlling the same BPX-8600 in an MPLS implementation: The slaves reside in BXM and BXM-E cards, in a distributed model, and the same master-slave and slave-to-slave channels are used. Signaling channels terminate in the controller (UNI and PNNI in this case; LDP in MPLS), and that allows the creation of end-to-end connections (SVCs and SPVCs in this case; LVCs in MPLS).

The SES controller offers fewer degrees of freedom than an LSC. The base-vc for master-slave communication is fixed and is equal to VPI/VCI = 0/40. In addition, the controller-id has a fixed value of 2. Both parameters can be configured in the BPX-8600, and they need to be set to the SES fixed values. On the LSC, both parameters can be configured.

Other differences exist as well. One of the differences is that apart from VSI, Annex.G runs between the BPX-8600 and the SES controller using VPI = 3 VCI = 31. By means of Annex.G (the polling mechanism between the BPX and SES), the BPX-8600 and the SES discover each other's names and IP addresses. Also, IP Relay communication exists between the controller and the controlled switch. IP Relay uses VPI = 3 and VCI = 8. The current network time is also propagated from the BPX node to the SES shelf using Cisco extensions to baseline Annex.G functionality.

Figure 3-25 shows the VSI channels and the feeder VCs in a SES-controlled BPX PNNI node. The VSI channels allow VSI master-slave and interslave communication. The feeder VCs consist of Annex.G and IP Relay VCs.

Figure 3-25. VSI and Feeder Channels in a SES-Controlled BPX-8600

Using VSI, UNI signaling and PNNI signaling and routing connections are created, terminating in the SES PNNI software, as shown in Figure 3-26. That PNNI control plane enables the creation of SVCs and SPVCs forming the data plane.

Figure 3-26. Signaling, Routing, and Data Channels in a SES-Controlled BPX-8600

Figure 3-26 summarizes all the VCs and cross-connects present in a PNNI node using a BPX-8600 controlled by a SES. UNI and PNNI signaling VCs use VCI = 5 for SSCOP signaling and VCI = 18 for PNNI routing control channels or RCC, where the VPI can be 0 or some other value for virtual interfaces. Remember that a virtual interface is used to build a trunk across a purchased virtual path connection. The new additions are the feeder VCs, used for Annex.G and IP Relay.

Also, because the PNNI software runs on a system with PXM-1 redundancy, the link between the controller and the switch has APS 1+1 or Y-red redundancy features.

Compared to a PXM-45 MGX-8850 supporting PNNI, one difference is that the SES/BPX pair cannot be a Network Clock Distribution Protocol (NCDP) client. This is because there is no VSI slave in the BCC card where the external clock inputs reside. This fact does not impose a limitation because clock distribution and selection are provided by AutoRoute in the BPX (as discussed in the section "AutoRoute").

For time-of-day synchronization, BPX nodes distribute the network time among themselves, and each BPX node propagates that time to its feeder shelves, including the SES if present. Where MGX-8850/PXM-45 nodes also exist in the PNNI network space, the BPX/SES can be enabled as a Simple Network Time Protocol (SNTP) server, allowing it to propagate the network time to the MGX-8850/PXM-45 nodes (SNTP clients).

PXM-45-Based MGX-8850 and MGX-8950 PNNI Implementation

From a controller perspective, the PXM-45-based MGX-8850 and MGX-8950 PNNI implementation is the first multiservice switch implementation where the controller is located on the switch controller card. Therefore, some of the communication paths are internal software interfaces. Yet the communication between the controller and the controlled switch is VSI.

Both the networking software (including ATM signaling, PNNI, SSCOP, and so on) and the VSI master reside in software in the PXM-45 card.

On the other side, from a switch perspective, the slave model is hybrid. The details of the slave model are covered in the later section "MGX-8850 and MGX-8950 Controlled Switches and VSI Slaves." They apply to all applications, including PNNI. To introduce some of these concepts, each BASM card (such as AXSM) has its own VSI slave implementation, and the PXM-45 card houses a VSI slave that manages interfaces in CBSM cards as well as the internal virtual port and clocking interfaces. In particular, the first CBSM supported in a PXM-45-based MGX-8850 is RPM-PR. Future support for NBSMs might include VISM, FRSM, and AUSM. MGX-8950 does not support single-height NBSMs.

NOTE

The terms CBSM and NBSM are used interchangeably.

Figure 3-27 summarizes some of these ideas.

Figure 3-27. VSI Communication Paths in a PXM-45-Based MGX-8850 PNNI Implementation

As opposed to the previous PNNI implementation, where VCs are set up for master-slave communication and cross-connects for slave-slave communication, the PXM-45-based MGX-8850 uses IPC to achieve this goal. This is true of both master-slave and slave-slave communication.

The VSI master creates an IPC endpoint to receive messages from the VSI slaves. The predefined global name to bind to this endpoint is created by concatenating the string VSIM with the controlled ID of the VSI master in hexadecimal notation.

The VSI slaves (including the PXM-45 proxy slave) create two IPC endpoints each. The first endpoint is to receive messages from the VSI master. Each slave binds the string vsim concatenated with the slave ID (which is the slot number) in hex to this endpoint.

The second endpoint is used for slave-to-slave messaging and is transparent to the VSI master and the networking software. The name bound to this endpoint is created by concatenating the string vsis with the slave ID in hexadecimal.

NOTE

IPC provides the name registration and resolution facilities. IPC also provides infrastructure for messaging between tasks in the same card or tasks in different cards. There are pre-established card-to-card ATM VCs for IPC communication. IPC Global Name Registry and Name Resolution services are present in the PXM-45 card, and every card has an IPC Name Resolution Client.

The VSI slave module in each BASM is responsible for the logical interfaces in that card. The VSI slave in the PXM-45 is responsible for managing NBSM logical interfaces as well as PXM-45 internal logical interfaces. In Figure 3-27, the RPM-PR has two logical interfaces in the PXM-45: one for VCCs and the other for Virtual Path Connections (VPCs). The logical interface for the control port is also shown in Figure 3-27. The control port is where control-vcs (connections that need to be SARed and analyzed by the networking software) terminate. Those connections are signaling VCs for UNI and NNI interfaces, routing VCs for NNI interfaces, and IP connectivity SVCs. The control port is reported to the networking software (with a VSI interface trap from the PXM-45 VSI slave to the VSI master) and is treated as any other logical interface. The control port and control-vc details are shown in Figure 3-28.

Figure 3-28. Control Port and Control-vcs

The control port is the primary interface for control-vcs. This means that the VSI master sends the connection setup message to the PXM-45 VSI slave (managing the control port), and that slave communicates with the AXSM VSI slave.

NOTE

The clock input interfaces are also represented as logical interfaces in the PXM-45 (not shown in the figure). More details about PXM-45's logical interfaces can be found in the later section "VSI Slaves: Logical Interface Numbers."

PXM-1-E-Based MGX-8830 and MGX-8850 PNNI Implementation

The last implementation of a multiservice switching PNNI node for routing and signaling is a PXM-1E-based system. The PXM-1E processor card is an enhanced processor card that uses PXM-45 and AXSM technology, providing higher port density and better performance than a PXM-1 processor card. It has the same switching capabilities as a PXM-1 by means of the shared memory (PXM-1E does not have a crossbar switching fabric), targeting the PNNI node for edge PNNI functionality. A PXM-1E-based MGX supports only CBSMs (FRSM, AUSM, VISM, CESM, and RPM-PR), not BASMs (AXSM cards).

An MGX system cannot share different types of processor cards in the same chassis, even though the MGX chassis is the same for PXM-1 (it is not PNNI-capable because of processor power), PXM-1E, and PXM-45 processor cards. That is, a mix of PXM-1, PXM-1E, and PXM-45 boards in the same node is not supported. PXM-1E is also supported in the small-factor MGX-8230 chassis with horizontal slots. PXM-45 is not currently planned to be supported.

In this PNNI implementation, as in a PXM-45 implementation, the PNNI software modules as well as the VSI master reside in the PXM-1E card. A centralized VSI slave also lives in the PXM-1E processor card.

The uplink is in the back card of the processor card. One of the features that makes a PXM-1E-based MGX node a versatile PNNI edge node is its support for multiport combinations with a daughter card/back card combo in the PXM-1E flexible uplink (a combo daughter card supports 8xDS3/E3 + 4xOC3), as well as a 16xT1/E1 daughter card and back card for ATM links and IMA links and a 2xOC12 daughter card and back card.

There is no graceful upgrade path from a PXM-1-based system in a feeder environment to a PXM-1E-based MGX acting as a PNNI routing node.

PNNI Implementation Summary

As a summary, Figure 3-29 details a PXM-45-based MGX-8850 and the BPX-8600 PNNI node part of a PNNI network.

Figure 3-29. SES-Controlled BPX-8600 and MGX-8850 Running PNNI

The resources partitioned for PNNI are advertised to the PNNI controller. In the controller, they are represented as PnPorts.

If the CPEs are SVC-capable, they can place SVC calls using UNI signaling. The three PNNI nodes run PNNI signaling and routing, providing the ability to set up SPVCs. This is useful when the CPE is not SVC-capable.