|
|
The Cisco SES PNNI Controller is a Service Expansion Shelf (SES) controller that attaches to a BPX 8600 series switch to provide Private Network-to-Network Interface (PNNI) signaling and routing for the establishment of ATM switched virtual circuits (SVCs) and Soft Permanent Virtual Circuits (SPVCs) over a BPX 8600 wide area network. Every BPX 8600 series switch that deploys PNNI signaling and routing is collocated and attached to a SES PNNI Controller. The SES PNNI Controller uses Cisco's Virtual Switch Interface (VSI) protocol to control the BPX switch for its networking application.
The complete SES node architecture consists of the combined BPX 8620 switch and the SES PNNI Controller, in addition to the combined network management system—Cisco WAN Manager and CiscoView—used to configure and monitor the SES PNNI node. A SES PNNI node is the combined SES PNNI Controller and a BPX 8620 switch (Figure 1-1).
The SES PNNI Controller is a 7-slot chassis that contains two Processor Switch Modules (PXMs) that run the PNNI and SVC software. One of the PXMs serves as the active processor, while the other serves as the standby. The PNNI controller is collocated with and cabled to the BPX switch with either the ATM/OC-3 interface (Figure 1-3) or the ATM/DS3 interfaces (Figure 1-4).
 |
Note The Service Expansion Shelf (SES) can be used in several WAN switching applications, and is not limited to function only as a SES PNNI Controller. However, when used as the SES PNNI Controller, the SES may only be populated with two switch processor modules (PXMs) and associated backcards. The remaining five slots of a shelf in service as a SES PNNI Controller are not used. |
Two PXM1 cards must reside in the SES PNNI Controller to enable redundant PNNI functionality. Line and service cards are not applicable to PNNI operations and cannot be installed in the PNNI Controller.
|
Note The PXM used in the SES PNNI Controller application is logically identical to the PXM used in the MGX 8850 but is keyed to fit only in the PNNI Controller. Also, the PXM for the PNNI controller is referenced by a different model number than is the PXM used in an MGX 8850. |
The active PXM card controls the Service Expansion Shelf and runs the PNNI and SVC software, which controls the associated BPX switch for PNNI networking and ATM switched virtual circuits. The standby PXM provides backup redundancy if the active PXM fails.
A pair of PXM1 back cards are required for each installed PXM1 front card. A PXM1 back card pair consists of the following:
Figure 1-2 shows a diagram of the PXM1 backcard.
A mismatch between the uplink back card type and that of the PXM1 will generate a major alarm. (The PXM has a daughter card that is factory installed and must match the type of ATM interface backcard.)
The BPX 8620 is a standards based, high-capacity broadband ATM switch that provides backbone ATM switching and delivers a wide range of other user services. For more information about the BPX, refer to the Cisco BPX 8600 Series Installation and Configuration documentation for release 9.2.
The Broadband Switch Module (BXM) is a multiplexing ATM interface card that uses STRATM-based application-specific integrated circuit (ASIC) technology to deliver ATM networking functions.
The following interfaces for ATM CPE and ATM trunks are supported on the BXM for PNNI and ATM SVCs/SPVCs:
Interface | Card Type |
|---|---|
|
|
|
|
|
|
|
|
The SES PNNI node internal interface between the SES PNNI Controller and the BPX switch is either OC-3 or T3/E3.
BXM trunks and ports are classified as User-to-Network Interface (UNI) or Network-to-Network Interface (NNI).
The UNI is the service interface for ATM customer premise equipment (CPE) connected to the SES PNNI node. It defines the signaling method which the CPE must use to request and setup SVCs/SPVCs through the wide-area ATM network. Used to send messages from the network to the CPE (such as a user device) on the status of the circuit and rate control information to prevent network congestion. Each UNI port in a SES 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.
|
Note The BPX switch also supports high-speed ATM UNI ports. |
The NNI is the interface to other SES PNNI nodes or foreign ATM switches. The WAN Service Node supports Interim Inter-switch Protocol (IISP) 3.0 /3.1 or the Private Network-to-Network Interface (PNNI). These NNI interfaces provide the switching and routing functions between Cisco WAN switching networks and other networks. Information passing across a NNI is related to circuit routing and status of the circuit in the adjacent network.
|
Note In this guide, a trunk refers to the connection between two BPX switches, but NNI may also refer to both a connection between WAN Service Nodes and a connection between a WAN Service Node and a foreign switch. |
The Broadband Controller Card (BCC) is a microprocessor-based system controller used to control the overall operation of the BPX switch. The controller card is a front card that is usually equipped as a redundant pair. Slots number 7 and number 8 of the BPX chassis are reserved for the active and standby broadband controller cards. Each broadband controller front card requires a corresponding back card.
The BCC performs the following major system functions for the BPX switch portion of a SES PNNI node:
Figure 1-3 and Figure 1-4 are simple block diagrams of a SES PNNI node. These figures illustrate the internal interfaces of the SES PNNI node (that is, between the PBX SES PNNI controller and the BPX switch) and the external interfaces. The external interfaces of a SES PNNI node connect to ATM end systems, and ATM trunks to other ATM or PNNI nodes or networks, and connections to Network Management Systems, such as the Cisco WAN Manager or CiscoView.
Cisco WAN Manager (CWM) (formerly known as StrataView Plus) and CiscoView are network management applications that can be used to configure, monitor, and manage the SES PNNI node. The Network Management Station can be connected to the SES PNNI either with directly connected Ethernet interfacing or by using the Cisco WAN Switching IP Relay application.
Cisco WAN Manager (CWM), a suite of WAN multiservice management applications, provides powerful fault, configuration, and performance management functionality 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.
Element and network management functions are provided by the CWM system, which can manage Cisco BPX 8600 series wide-area switches and Cisco SES Controller 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.
This section provides information about the main features of CWM.
From the Cisco WAN Manager interface you can do the following:
The Connection Manager provides the network manager the ability to add, modify, and delete end-to-end connections. The Connection Manager provides a series of forms-based screens to add, modify, or delete connections. You select the desired connection end-points and configure the connection type and class of service. 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 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 this interface to integrate with automated Operations Support Systems (OSS) provisioning systems and also to provide Customer Network Management (CNM) views and control capabilities on a per-connection basis.
The Statistics Collection Manager (SCM) provides a forms-based interface to establish and modify statistics collection policies for the network. You can configure statistics collection policies such as which statistics to collect and collection interval 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 applications. Additional SCM agent workstations can be installed for gathering additional statistics. Each SCM agent can collect in excess of 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.
IGX, BPX, and MGX switches provide an Ethernet 802.3 AUI LAN interface 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 access to the IGX, BPX, or MGX management interface.
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 either provided 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 of the security management functions of the 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 VT100 connected to the control port is supported using the VT command. The VT command will provide network operations staff with identical control and monitoring capabilities as if they were locally attached to the switch.
WAN CiscoView is a GUI-based device management software application that allows you to display configuration and performance information, and perform minor configuration tasks on the SES PNNI Controller. WAN CiscoView for the SES PNNI Controller, Release 1.0 provides a description of tasks that can be performed through CiscoView.
For more information on managing the network elements using CiscoView, please refer to
Release 1.0, WAN CiscoView for the SES PNNI Controller, and Release 2.0, WAN CiscoView for BPX 8600 Switches.
CiscoView is a graphical SNMP-based device management tool that provides real-time views of networked Cisco Systems devices. These views deliver a continuously updated physical picture of device configuration and performance conditions, with simultaneous views available for multiple device sessions.
This section provides information about the main features of CiscoView.
From the CiscoView interface you can do the following:
CiscoView contains common devices functions such as selecting main menu options and categories of information for configuring and monitoring. Each device package also has its own specific menu options and functions.
The SES Controller command line interface (CLI) configures ATM SVCs, SPVCs, and PNNI routing and signaling on the SES Controller. These commands are described in depth in
Appendix B, "SVC, SPVC and PNNI Commands."
|
Note Throughout this manual, some BPX-specific commands are presented where applicable to PNNI configuration tasks. For additional information on the BPX command suite, refer to Cisco BPX 8600 Series Installation and Configuration document and the Cisco WAN Switching Command Reference and SuperUser Command Reference for Switch Software Release 9.2. |
The SES PNNI node adds PNNI routing and ATM switched virtual circuits to a traditional Cisco WAN switching network. The network created with SES PNNI nodes is enhanced for SVCs/SPVCs and also supports traditional ATM and Frame Relay permanent virtual circuits (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 up network resources. (See Chapter 3, "ATM Signaling and Switched Virtual Circuits," for more information about ATM SVCs.)
SPVCs (Soft Permanent Virtual Circuit) are persistent ATM connections established by the PNNI routing database and signalling across a Cisco WAN switching network. (See Chapter 5, "ATM Soft Permanent Virtual Circuits," for more information about ATM SPVCs.)
The routing protocol that the SES PNNI node uses to establish connections is the Private Network-to-Network Interface (PNNI) routing protocol. 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.
SES PNNI node resources, such as port virtual path identifier (VPI) range and 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.
For ATM SVCs/SPVCs, the SES PNNI node uses the Private Network-to-Network Interface (also known as Private Network to Node Interface). As defined by the ATM Forum, PNNI is a dynamic routing protocol specified for use between private ATM switches (for example, Cisco SES PNNI nodes), and between groups of private ATM switches. PNNI defines the following two protocol categories:
Topology state routine distributes topology information between switches and clusters of switches. This information is used to compute paths through the network. A key feature of the PNNI mechanism is its ability to automatically configure 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 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 includes functions to support 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 making a best match of the destination address in the call setup with address entries in the next hop routing table at a given switching system. Entries in the next hop routing table are manually configured. See Chapter 2, "ATM Routing," for more information about IISP.
The SES PNNI node uses ILMI to automatically identify which of its interfaces are User-Network Interface (UNI), attached to ATM end systems, and which are Network-to-Network Interface (NNI), attached to other systems. This information is used by ATM Routing protocols, Private Network-to-Network Interface (PNNI), and Interim-Interswitch Signaling Protocol (IISP) to automatically discover and bring up a network of interconnected SES PNNI nodes.
The ILMI protocol is also used for ATM address registration across an ATM UNI, and to:
The BPX and SES PNNI Controller are completely redundant and offer hitless operation. A hitless switchover occurs when the controller is switched over from an active processor to a standby processor due to system hardware or software failure. During hitless switchovers, all established active calls are unaffected by the switchover and continue to stay up (Table 1-1), however a probability exists that calls that have been established over the past 1 (one) second will be dropped.
| Type of Event | Result |
|---|---|
Hitless switchover between PXM1 (active/standby) in the SES. | All active calls are maintained after PXM1 switchover. |
Failure of the OC-3 link between the SES and BPX | Automatic APS switchover to alternate OC-3 link. No impact to existing fully established calls. |
Hitless switchover between the BCC cards in the BPX. | No impact to existing, fully established calls. |
Hitless software upgrade in the BPX and/or the SES. | No impact to existing, fully established calls. |
Also referred to as line redundancy, automatic protection switching (APS) is a standard that defines the switching of SONET lines from the active line to a standby line to provide hardware line redundancy after failure of an active line. 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 is applicable to OC-3, OC-12, and DS3 interfaces.
Upon detection of a signal fail condition (for example, LOS, LOF, Line AIS, or Bit Error Rate in excess of a configured limit) or a signal degradation condition (for example, BER exceeding a configured limit), the hardware switches from the working line to the protection line, assuming that the working line was the active line and the protection line was not in alarm.
APS 1+1 dual backcard, provides card and line redundancy, using the same numbered ports on adjacent BXM backcards (Figure 1-5). Each OC-3 link on the PXM1 is connected to an OC-3 link on a BPX card. These links use APS, which enables APS switchover in fewer than 60 ms in the event of a link failure. This switchover occurs at the backcards of the PXM1 and BXM only. Front cards do not switch over during an APS switchover session.
Coordination between the interfaces on the two ends of the lines is provided using an in-band protocol.
The SES supports Y-cable port redundancy. To set up port redundancy, installing 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 the configuration for both the primary and redundant set. If you reset the primary cards or the primary card set becomes inactive for another reason, the secondary card set becomes active.
The SES PNNI Node Software is distributed across three branches of software:
These three branches of software interact to create SES PNNI nodes, a PNNI network, and ATM SVC/SPVC services.
The PXM software for the SES PNNI Controller contains three major functional blocks (Figure 1-6):
VSI software provides the VSI master application used by the PNNI and SVC/SPVC networking control software to control the BPX switch. (See the section Virtual Switch Interface Protocol, for more information.)
Control Point software runs on the PXM at the SES PNNI Controller to provide a single, integrated point of control for the PXM and the PNNI and ATM SVC application software. It provides the interface that enables configuration of the PNNI and ATM SVC parameters for the SES PNNI node, and the PXM management functions.
This interface takes the form of an 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 reasons such as alarm status changes (such as connection routing and rerouting).
The Control Point software enables direct access to the SES PNNI Controller command sets by providing a consistent, integrated SNMP proxy for the platform, and CLI for the service expansion shelf.
The PNNI and SVC software architecture consists of three major components (Figure 1-7):
The major features implemented in Call Control Block are as follows:
The major components in Call Control block are shown in Table 1-2.
| Components | Description | ||
|---|---|---|---|
Call Control |
| ||
ATM Signaling Stack |
| ||
SSCOP |
| ||
VSI Master |
| ||
RM (Resource Manager) |
| ||
CM (Connection Manager) |
| ||
Route Agent |
|
Performs topology information exchange and routing information exchange with other SES PNNI Controllers.
PNNI pre-calculates 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.
The redundancy manager supports active call redundancy by shadowing the essential data structure information on the standby SES PNNI Controller.
The major features included in PNNI Routing Block are as follows:
Platform software runs on the PXM at the SES PNNI Controller to provide low-level operation of the system (including resource management and physical redundancy control) and a set of services to the remaining subsystems. These services are categorized as Basic Platform-Specific Configuration and Monitoring Service, and Platform Infrastructure.
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. It also 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.
The platform software provides the basic infrastructure for the following:
The Virtual Switch Interface (VSI) protocol controls a Cisco Wide Area Network Switch, such as the BPX 8600, for networking applications, such as Multiprotocol Label Switching (MPLS) or PNNI routing. With VSI, external controllers are used to control the switch for applications not supported by the proprietary WAN switch set of routing protocols known as AutoRoute.
The SES PNNI Controller uses the Virtual Switch Interface (VSI) protocol to control BPX VC applications by creating a separate control plane, distinct from the standard BPX AutoRoute control plane, that includes all the SES PNNI nodes in the PNNI network. The SES 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:
For more information about the VSI protocol, see Appendix D, "Virtual Switch Interface."
The VSI is a master/slave protocol. The master VSI protocol runs on the SES PNNI Controller, and is referred to in this application, as the VSI controller. The slave VSI protocol runs on the BXMs on the BPX 8620 (Figure 1-8).
The VSI controller automatically establishes a link between the VSI master and every VSI slave on the associated switch (Figure 1-9). When enabled, the VSI slaves establish links.
The SES controller uses VSI control channel to set up virtual circuit cross connect via VSI slaves on BXM cards.
Internal resources on the BPX must be partitioned between AutoRoute and the external VSI controller to enable VSI establishment of a separate PNNI control plan. In a SES PNNI node, the resources are partitioned between AutoRoute and PNNI on the BXM cards (Figure 1-10). An MPLS partition can also be added, but theSES PNNI Controller will not control or share the MPLS partition. A separate MPLS controller will be required.
The resources that must be partitioned between AutoRoute and PNNI on each BXM (Figure 1-11) are:
By default, all bandwidth is allocated to AutoRoute when a BXM trunk is added. To preserve resources for a VSI, the bandwidth allocation can be changed by using the cnfrsrc (configure resources) command on the BPX switch. See Chapter 10, "Configuring ATM SVCs, PNNI Routing, and SPVCs" for more information about resource partitioning.
Once the resources are partitioned, the PNNI controller (VSI controller) can use the resources configured for it to set up user ATM SVCs/SPVCs across the PNNI network.
To add or remove bandwidth from autoroute without affecting the dynamic aspect, increase the VSI partition and decrease autoroute.
This section introduces the system templates.
For more information about SCT and Qbin templates, see Chapter 5, "Configuring ATM SVCs and PNNI Routing."
|
Note The terms—Class of Service Template and Service Class Template (SCT) —can be used interchangeably. |
Each BPX switch (running Release 9.2 and up) contains a set of nine Service Class Templates (SCT) that can be downloaded to an interface service module—a BXM—as needed. These Service Class Templates have pre-defined, non-changeable values that are tailored for typical interfaces such as PNNI trunk or PNNI UNI.
SCT templates contain two classes of data:
The SES PNNI Controller (VSI master) can use the Service Class Templates to configure the appropriate type of ATM connection.
When an ATM SVC connection setup request is received from the VSI Master in the SES PNNI Controller, the VSI slave (as in the BXM) uses the SCT index of the request to retrieve the corresponding set of extended parameters defined in the template for the corresponding index. The slave uses these values to complete the connection setup and to 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:
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.
Service Class Templates on the BPX are maintained by the BCC and are downloaded to the BXM cards as part of the card configuration process occurring as a result of card activation, rebuild, or switchover.
|
Note In Release 9.2 the templates are not configurable. |
One of the parameters specified for each service type is the BXM class of service buffer (Qbin) to be used. The Qbin buffers provide separation of service type to match the QoS requirements. This mapping defines a relationship between the template and the Qbin interface configuration.
A Qbin template defines a default configuration for the set of Qbins for the logical interface. When a template assignment is made to an interface, the corresponding default Qbin configuration becomes the interface's Qbin configuration. Some of the parameters of the interface's Qbin configuration can be changed on a per interface basis. Such changes affect only that interface's Qbin configuration and no others, and do not affect the Qbin templates.
Qbin templates only are used with Qbins that are available to VSI partitions, namely Qbins 10 through 15. Qbins 10 through 15 are used by the VSI (on interfaces configured as trunks or ports. Qbins
0 through 9 are reserved for and configured by AutoRoute.
This section introduces the major ATM SVC applications supported by the PNNI controller:
The SES PNNI node supports SVC applications with PNNI routing (Figure 1-12). PNNI routing protocol runs between ATM switches. The network topology information and routing information are exchanged between ATM switches via PNNI routing protocol. The routing path from a calling CPE to a called CPE is dynamically selected based on current network traffic and resource conditions.
|
Note A PNNI network uses AutoRoute functions for network timing. |
Where SVC applications contain both IISP and PNNI networking, IISP runs on the edges of a PNNI network and interconnects non-PNNI networks via a backbone PNNI network (Figure 1-13). IISP maintains a set of static routing tables to direct signaling between a non-PNNI network and a PNNI network. The static routing information can be advertised into PNNI network through boundary switches (namely, 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.
A SES PNNI network allows both PNNI and AutoRoute networks to coexist in the same physical network (Figure 1-14). 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.
This section introduces the tools used at the PNNI Controller, the BPX 8600, CWM, and CiscoView to control and manage the SES PNNI node.
All user interfaces access the SES PNNI Controller through control point software. The control point software then interacts with the PNNI, SVC, VSI, and platform software.
The four main interfaces used to configure and operate a SES PNNI node are as follows:
1. SES Command Line Interface
2. BPX Command Line Interface
3. Cisco WAN Manager
|
Note IP connectivity to the SES PNNI Controller is provided by using the inband IP Relay capability of AutoRoute. Therefore, AutoRoute will still be required in the network. Its main function will be for the use of IP Relay, Time of Day propagation, and Network Clock Sync. (Out-of-band network management connectivity is also provided through the Serial and Ethernet interfaces on the PXM.). These services will be provided in a pure PNNI network (namely, one that does not use AutoRoute) in a future release. |
Configuration data is written to the disk and the DRAM, when configuration is changed. This data is used to initialize the PXM1 upon reset. The configuration data can be saved on external server such as CWM via configuration upload. The Configuration data can also be saved in a separate file and restored later if necessary.
The SES PNNI Controller maintains a log of system errors in BRAM, containing crucial system details prior to a system reset.
CWM provides remote access to cell statistics from physical interfaces and call statistics from SES PNNI Controller.
The SES PNNI Controller maintains log files on system disk to log events in the system.
The SES PNNI Controller complies with SNMP VI. The Management Information Base (MIBs) used by the SES PNNI Controller are described in Appendix E, "SNMP Management Information Base."
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.
Alarms generated by theSES PNNI Controller are mapped into traps and sent to the CWM. The SES 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 were not received.
The SES PNNI nodes are preconfigured with Cisco ATM address prefixes, which are combined with the preconfigured MAC address of the switch to form a unique node identifier. These are used to configure both attached ATM end systems and to automatically bring up the PNNI routing hierarchy for simple network configurations
Posted: Fri Sep 15 15:28:05 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.