Table Of Contents
New Features and Enhancements in Release 4.0.15
New Features and Enhancements in Release 4.0.12
New Features and Enhancements in Release 4.0.11
Features and Enhancements in Previous Release 4.0.10
Add Channel Loopback on AXSM-E (PER 3854)
Active PXM Freeze Detection and Recovery (PER 7869)
Improved SCM Polling Diagnostics on Active and Standby PXM
Cell Bus Service Module on PXM-45 (Expanded from MGX 4.0.00 Release)
AXSM/B as Feeder Uplink on MGX 8950
Features and Enhancements in Previous Release 4.0.00
Preferred Routes for PNNI Multipeer Group Networks
Point-to-Multipoint SVC/SPVC Support
Increased Number of Signaling Interfaces
PXM1E-Related Hardware (the PXM1E-8-155 card)
Automatic Protection Switching Support
Modular Transceiver Support in the New 8-port OC3/STM1 Back Card
UNI connection support in PXM1E-16-T1E1
Cell Bus Service Module Support
Virtual Trunks Support in PXM1E
AXSM-E as Upstream to Feeder Nodes
Cell Bus Service Modules on PXM45
Service Class Template (SCT) File Information
Software/Firmware Compatibility Matrix
MGX and RPM Software Version Compatibility Matrix
New Hardware in Release 4.0.15
New Hardware in Release 4.0.12
New Hardware in Release 4.0.11
New Hardware in Release 4.0.10
New Hardware in Release 4.0.00
MGX 8850 (PXM45) Product IDs and Card Types
MGX 8850 (PXM1E) Product IDs and Card Types
MGX 8830 Product IDs and card types
MGX 8950 Product IDs and card types
Limitations, Restrictions, and Notes for 4.0.15
Higher Level Logical Link Limits
Cell Bus Service Modules (formerly know as Narrow Band Service Module) and RPM-PR
AXSM-E as Upstream to Feeder Nodes
Maximum Threshold Accuracy for PXM45 and PXM1E
Controller Card Mastership Sanity Verification
Serial Bus Path Fault Isolation
Cell Bus Path Fault Isolation and Recovery
Non-native Controller Front Card and PXM-HD Card
Simple Network Timing Protocol (SNTP)
AXSM-32-T1E1-E and PXM1E-16-T1E1
Other Limitations and Restrictions
Clearing the Configuration on Redundant PXM45 and PXM1E Cards
Limitations and Restrictions for 2.1.x
General Limitations, Restrictions, and Notes
Limitations for rteopt via parallel links
Installation and Upgrade Procedures
Cisco MGX 8850 (PXM45) Multiservice Switch Release 4
Cisco MGX 8850 (PXM1E) Multiservice Switch Release 4
Cisco MGX 8950 Multiservice Service Release 4
Cisco MGX 8830 Multiservice Switch Release 4
Cisco WAN Switching Software Release 9.4
MGX 8850 (PXM1) Edge Concentrator Release 1.2.20
MGX 8250 Edge Concentrator Release 1.2.20
MGX 8230 Edge Concentrator Release 1.2.20
How to Find Multiservice Switch Customer Documents Online
If the Part Number is Not Known
Documentation on the World Wide Web
Obtaining Technical Assistance
MGX 8850, MGX 8830, and MGX 8950 4.0.15 Anomalies
Known Anomalies in Release 4.0.15
Anomalies Resolved in Release 4.0.15
Anomaly Status Change from Previous Release
MGX 8850, MGX 8830, and MGX 8950 4.0.12 Anomalies
Anomalies Resolved in Release 4.0.12
MGX 8850, MGX 8830, and MGX 8950 4.0.11 Anomalies
Anomalies Resolved in Release 4.0.11
MGX 8850, MGX 8830, and MGX 8950 4.0.10 Anomalies
Anomalies Resolved in Release 4.0.10
Known Route Processor Module or MPLS Anomalies
Release Notes for Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830, Software Version 4.0.15
Contents
About Release 4.0.15
These release notes describes the system requirements, new features, and limitations that apply to Release 4.0.15 of the MGX 8850, MGX 8950, and MGX 8830 multiservice switches. These notes also contain Cisco support information.
These release notes complement the technical manuals listed in the "Related Documentation" section.
Type of Release
Release 4.0.15 is a software release for the following MGX switches:
•
MGX 8830 PNNI routing switch
•
•
•
Locating Software Updates
This is the location for the MGX 8850(PXM45/PXM1E), MGX 8830, and MGX 8950 4.0.15 software:
•
New Features and Enhancements in Release 4.0.15
None.
Frame Discard Feature
New developments have occurred in the CLI for the Frame Discard feature in connection provisioning. Starting with releases 3.0.23 and 4.0.10, two types of frame discard became available. For a detailed explanation, see the addcon or cnfcon description in either the Cisco MGX 8830, MGX 8850 (PXM45 and PXM1E), and Cisco MGX 8950 Command Reference (Release 3 or 4) or the Cisco ATM Services (AXSM) Software Configuration Guide and Command Reference for MGX Switches (Release 3 or 4). Also see the Note in the Installation and Upgrade section of these release notes.
New Features and Enhancements in Release 4.0.12
Point-to-Multipoint Support
The SVC/SPVC point-to-multipoint (P2MP) feature offers the ability for an endpoint (termed the root endpoint) to establish a simple tree topology to multiple endpoints (termed leaf endpoints). The data traffic is uni-directional in the direction from the root to all the leaves. When P2MP calls are established using signaling, leaves can be added to a root endpoint using SETUP/ADD_PARTY signaling messages. Point-to-multipoint is a mandatory feature described in UNI 3.0, UNI3.1 and UNI4.01 specs. The implementation is compliant with in Q2971.
P2MP calls can also be setup by provisioning a `root' endpoint using the addcon CLI command. The `leaf' endpoints can then be added by using the addparty CLI command.
There are finite limits on the numbers of p2mp connections that can be supported on different MGX platforms. Table 1 depicts this.
Table 1 Point to Multipoint Support
Total number of connections (p2p and p2mp)
250000
250000
100000
27000
Total number of P2MP connections2
5000
5000
500
500
Number of parties per P2MP connection3
1000 4
1000
100
100
Number of branches
128
128
1
32
Number of parties per node
10000
10000
1000
1000
1 P2MP feature is supported only on PXM45/B or PXM45/C.
2 This is the number of P2MP roots that can be setup on a node
3 The number of parties for a given P2MP connection can be more than the number of leaves on that connection. There can be multiple endpoint references on a given leaf endpoint
4 This is the number of P2MP roots that can be setup on a node.
The capability to replicate ATM traffic on MGX varies with the type of hardware used. A brief note on the replication mechanism in MGX will help the user understand the limitations associated with specific hardware.
Figure 1 Replicating Traffic
In Figure 1, D1 - D4 are destination cards in a MGX node A. S1 is a source card on Node A, where the root endpoint of the P2MP connection is provisioned. In this example, there is a P2MP connection which has leaves on D1 and D3 of node A and on D1 and D4 of node B. The first stage of multicast is called the slot multicast. This is performed by the crossbar module on the MGX. Although the replication takes place on the crossbar, the slots towards which replication should take effect is instructed by the source card S1 on node A. After slot multicast cells arrive on the replication engines on slots D1 and D3 of node A. Here the second stage of multicast is performed by the destination cards and is termed port multicast. Port multicast on slot D1 (node A) delivers data to a leaf on one of its port and to a branch on another of its port. On the slot D3 (node A) there exists only one leaf endpoint. Data from the branching point is delivered to S1 of node B. Here again there is a slot multicast operation followed by port multicast at each of the destination card slots (D1 and D4).
It should be noted that some of the destination cards may not be able to perform port multicast operation. For example, in the above example if D4 on node B is incapable of doing port multicast and if there were to be multiple leaves on it, the replication needs to be performed at D1 on node A. This would mean that there would be two connections carrying the same data from node A to node B.
Capabilities
Table 2 lists multicast capabilities by card.
Table 2 Multicast Capabilities by Card
Slot Multicast
YES
YES
YES
YES
NO
Port Multicast
YES
YES
NO1
YES
NO
1 Only one leaf is supported on AXSM-E. Please see section on AXSM-E limitations
Crossbar Limitations
The MGX 8850 is equipped with a maximum of 8 switching planes on the crossbar module. MGX 8950 can have as many as 16 switching planes on the crossbar module.
Most of the broadband SMs (AXSM-A, AXSM-B, AXSM-E, FRSM12, RPM-XF) have access to just 8 switching planes. The AXSM-XG is the only broadband SM that can access all 16 switching planes (however, it can use all 16 of them only on a MGX 8950).
When there is unicast traffic to be sent from source card S1 to destination D1, S1 would put forth a request on any of the available 8 / 16 switch planes. The crossbar would negotiate access to the destination slot D1 on the requested switch plane. If the destination grants the request, the cell is transferred from S1 to D1 on the requested switch plane. If not granted (for some reason serial link from crossbar to D1 is busy/down), then S1 would attempt on other switch planes.
However, in case of multicast traffic, the crossbar accepts multicast root cells from S1 (without negotiating access to all possible destination slots) and makes best effort to forward cells to all relevant destination slots.
This leads to the following limitations:
•
•
AXSM/A Limitations
To understand these limitations a brief description of the serial bus request generation mechanism towards crossbar is needed:
The crossbar is configured for `Unicast preferred' implying that it will honor requests from the service modules in the following order (for a specific destination slot):
•
•
•
•
•
The broadband service modules can generate two types of requests (primary and secondary) for unicast traffic based on the number of switch planes and number of cells in the input queue. And the service modules can generate one "Unicast Primary" and multiple "Unicast secondary" requests at any point of time (every S-Tick). The limitation in AXSM/A has to do with not supporting the speedup option in its request towards the crossbar.
Suppose a source card has 8 cells in the queue for the same destination and switch is made of 4 switch planes, the source card will generate one "Unicast Primary" and 3 "Unicast secondary" requests. For multicast traffic there is no secondary request, all multicast requests are primary only. There could be a scenario where multiple source cards are trying to send both "Unicast" and "multicast" traffic to the same (congested) destination. In that case, one source card's "Multicast primary" request can win over the other source cards "Unicast secondary requests". Traffic from only one source card to the same destination will not be an issue as the card gives priority to unicast traffic.
Example 1
Card A is sending OC48 CBR unicast traffic to Card B.Card C is sending OC24 UBR multicasttraffic to Card B.Card B can sink in only OC48 worth of traffic from A and C.Result: Card A will see some ingress discards. The same behavior will be seen for unicast traffic as well. This stems from the fact that card A cannot assert speedup requests towards the crossbar in order to assure guaranteed traffic.Example 2Card A is sending OC24 CBR multicast traffic to Card B.Card C is sending OC48 UBR unicast traffic to Card B.Card D is sending OC48 UBR unicast traffic to Card B.Card B can sink in only OC48 work of traffic from A, C and D.Result: Card A will see some ingress discards.AXSM/B Limitations
AXSM-B hardware resolved the issue of `speedup' signal assertion. Thus the above mentioned problem was addressed.
However, both AXSM-A and AXSM-B have a common limitation. During the `port multicast' performed at the destination cards, the multicast root cells are replicated and queued on to several leaf connections. The root cells are queued up in a cache while awaiting replication. This cache is about 32 cell deep. When there is a burst of traffic from several different P2MP connections and if the replication is not done fast enough, there is a possibility of cache overflow. This results in loss of data on multicast connections.
AXSM-E Limitations
AXSM-E hardware does not support the `port multicast' operation. However, when used as a trunk, AXSM-E would be required to carry P2MP calls, without having to perform the branching (or replication) functionality. PNNI recognizes this limitation of AXSM-E and ensures that branching is not done on an AXSM-E, when it is an AXSM-E port is used as a trunk.
Because of the same limitation, AXSM-E can host only a single leaf of a multicast connection. It should be noted that when several P2MP parties (leaves) are added to a P2MP connection, only one leaf could be terminated on an AXSM-E for a given P2MP connection
In this release there is yet another limitation for leaves terminated on AXSM-E. If there are multiple leaves terminated on a node and if one of the leaves terminates on an AXSM-E (note that there can be only one leaf on AXSM-E), then it is likely that the call setup to the AXSM-E leaf may not setup reliably (i.e. if there is a de-route/re-route of the connection, there is no guarantee on the leaf call setup)
However, if there is only one leaf in the node and this leaf is on an AXSM-E, the call setup to the AXSM-E will be setup reliably.
PXM1E Limitations
PXM1E does not support branching (for p2mp connections) in this release. PXM1E can however be a via node for p2mp connections in 4.0.15.
New Features and Enhancements in Release 4.0.11
None.
Features and Enhancements in Previous Release 4.0.10
The new features in Release 4.0.10 are listed inTable 3.
:
Note
Note
LMI AutoSense
The LMI AutoSense feature on the Frame Relay Cards on MGX switches enables a frame relay port to detect the LMI type supported by the frame relay CPE (customer premise equipment). This autosensing feature avoids the need to configure the LMI type on each frame relay port.on the FRSM-8T1/E1 and FRSM-VHS (2CT3, 2T3, 2E3, 2HS2B) cards on PXM1/(PXM45A/B/C)/PXM1E platforms.
The LMI AutoSense feature is supported for Frame Relay and FUNI port types. It is not applicable for Frame Forwarding port types. The detected LMI types will be of the following UNI types:
•
•
•
The LMI AutoSense feature is not supported on NNI interfaces.
The LMI AutoSense feature is configurable at a per port level.
A new MIB variable portLmiSigConfMethod has been added to the existing frPortCnfSigLMIGrpTable MIB table.
The addport, cnfport, xcnfport and dspport CLI commands have been modified to configure/display the new portLmiSigConfMethod MIB variable.
addport
One more parameter lmi_autosense will be added to the addport CLI, which can be optionally specified by the user while adding the port. By default the value will be set to Manual(1).
If the user wants to configure the port for LMI AutoSense, the user needs to set the lmi_autosense parameter value to AutoSense(2) while adding the port using addport.
The addport command syntax for the cards will thus be modified to as shown below
FRSM-8P and FRSM-2CT3.
Syntax:
addport "port_num line_num ds0_speed begin_slot num_slot port_type [lmi_autosense]"
where lmi_autosense can be configured for either mode Manual(1) or AutoSense(2)
FRSM-2T3, FRSM-2E3, FRSM-HS2B.
Syntax:
addport "port_num line_num port_type [lmi_autosense]"
xcnfport
One more parameter "-lmias" has been added to the xcnfport CLI, which can be specified while either adding the port or modifying the port using xcnfport. By default the value is set to Manual(1).
To configure the port for LMI autosense set the "-lmias" parameter value to AutoSense(2) while adding/modifying the port using xcnfport. At the same time, set the port signalling protocol type to noSignalling using the "-sig" option.
The xcnfport command syntax for the cards has been modified as shown below.
Syntax:
xcnfport "-pt <PortNum> -ln <PortLineNum> -en <PortEnable> -rat <PortEqueueServiceRatio> -flag <PortFlagsBetweenFrames> -asy <AsynchMsg> -t391 <T391Timer> -t392 <T392Timer> -n391 <N391Counter> -n392 <N392Counter> -n393 <N393Counter> -enhancedLmi <enhancedLmi> -pta <portAdmin> -svcen <portSvcStatus> -svcuse <portSvcInUse> -pbe <portBertEnable> -m32eqth <EgressQueueThreshold> -lmias <lmi autosense>"
where -lmias <lmi_autosense> can be set to either 1 for Manual or 2 for Autosense.
cnfport
One more parameter lmi_autosense has been added to the cnfport CLI, which can be specified while modifying the port. By default the value is set to Manual(1).
To configure the port for LMI autosense, set the lmi_autosense parameter value to AutoSense(2) and lmiSig to noSignalling while using cnfport.
The cnfport command syntax for the cards has been modified to as shown below:
Syntax:
cnfport "portNum lmiSig asyn ELMI T391 T392 N391 N392 N393 [lmi_autosense]"
where [lmi_autosense] can be set to either 1 for Manual or 2 for AutoSense.
dspport
The existing CLI dspport will be enhanced to display the value of the new MIB variable. The display of this new variable portLmiSigConfMethod will be added between the display of PortSpeed and SignallingProtocolType.
Example:
node.1.4.VHSHS2.a > dspport 1SlotNum: 4PortLineNum: 1PortNum: 1PortRowStatus: AddPortDs0Speed: notUsedPortDs0ConfigBitMap(1stDS0): 0xffffff(1)PortEqueueServiceRatio: n/aPortFlagsBetweenFrames: 0PortSpeed: 51840 kbpsportLmiSigConfMethod: ManualSignallingProtocolType: NoSignallingAsynchronousMsgs: UPD_UFS disabledT391LineIntegrityTimer: 10 secT392PollingVerificationTimer: 15 secN391FullStatusPollingCounter: 6N392ErrorThreshold: 3N393MonitoredEventCount: 4EnhancedLmi: OffPortState: FailedDuetoLineFailurePortSignallingState: No Signalling FailureCLLMEnableStatus: DisableCLLMxmtStatusTimer: 40 msportType: frameRelayportEnhancedSIW: DisablePortIngrPercentUtil: 0PortEgrPercentUtil: 0PortOversubscribed: FalsePortSvcStatus: DisablePortSvcInUse: Not In-UsePortSvcShareLcn: Card-basedPortSvcLcnLow: 0PortSvcLcnHigh: 0PortSvcDlciLow: 0PortSvcDlciHigh: 0PortNumNextAvailable: 2
Resource Monitoring
The feature Resource Monitoring periodically checks the switch resources and takes appropriate actions when either there is a resource shortage or recovery happens. The resources monitored are:
•
•
•
•
•
•
•
•
The action includes:
•
•
•
The following are new CLIs for the feature:
•
•
•
•
The following are modification on existing CLI:
•
Platforms
The feature is supported on:
•
•
•
Add Channel Loopback on AXSM-E (PER 3854)
Currently, the addchanloop CLI command on the AXSM-E card offers the local and remote loop option. This would make it consistent with the addchanloop command on the AXSM/B Card.
The local (egress) loop option of addchanloop has been added on the AXSM-E. Special handling is involved where the SABRE chip handles the egress loopback instead of the ATLAS chip.
dspchancnt is supported on the loopback connection.
Limitations:•
•
•
•
•
•
Platforms
The feature is supported on:
•
Service Module Core Hot Dump
In order to ease debugging of either memory leak or memory corruption on service module (SM) cards, core hot dump feature provides the functionality of initiating core hot dump through CLI command of "core hot-dump <file.zip>" on SM. The feature is available on the following service modules:
–
–
–
–
CBSM (Cell Bus Service Module) is not supported by this feature. Only one SM slot can execute core hot dump at one time. The core hot dump will not cause SM card to reset. The feature can be executed on active and standby SM cards. Each SM slot performing core hot dump will have a core hot dump zip file saved on the active PXM hard disk "C:/" directory. The user can ftp the zipped core file to a their workstation and use a GDB debugger to analyze the core file to analyze the problems. At the PXM CLI prompt, the user can check SM core hot dump status by using the CLI command "core dump-status". The CLI shows slots that are in the process of core hot dump.
Platforms
The feature is supported on:
•
•
Active PXM Freeze Detection and Recovery (PER 7869)
The standby PXM monitors the SCM polls coming from the Active PXM. If the standby PXM detects a missing Poll, it waits for configurable maximum consecutive missing polls (Default 13 polls: 19.5 Seconds) and then takes over the mastership and resets the Active PXM.To ensure the Standby PXM does not reset the Active in case of local SCM path failure, the Active PXM detects the missing Poll responses. It resets the standby PXM (or any Service Module) in configurable consecutive missing poll responses(10 Polls: 15 Seconds recommended).This feature is not enabled by default on PXM cards. The feature has to be enabled on the Active PXM and the values for MaximumPoll counts from Active and Standby must be configured also.The default value for the standby PXM maximum missing poll before it declares active frozen is 13 counts(19.5 sec) and the default value for the Active PXM maximum poll retries is 9 polls(+1 failure before retries).
Platforms
The feature is supported on:
•
•
Improved SCM Polling Diagnostics on Active and Standby PXM
The feature is an enhancement in SCM for improving the debugging ability for SCM Poll / RPM heartbeat failures. SCM has a mechanism of monitoring card's health by sending Poll messages (Additionally Heartbeat in RPM). SCM declares a card dead after a certain number of responses are not received and reports the error to Shelf Manager which in turn will reset the Service Module. Currently, there is no debugging information either logged or stored once the card resets. The feature has the capability of storing more information in case of card failure for easier debugging. The possible cause of an SCM Poll/Heartbeat failure could be Failure in the communication path, Failure of the channel on which the Poll/Heartbeat is sent, and Failure on the Service Module. A new mechanism introduced in SCM collects the relevant data for improving failure analysis. A minimum number of failure of Poll/Heartbeat threshold (50% of Maximum Poll Retry limit) would be used to trigger the collection of data from SAR, QE and CBC on the PXM side.
Platforms
The feature is supported on:
•
•
•
Cell Bus Service Module on PXM-45 (Expanded from MGX 4.0.00 Release)
MGX-FRSM-2T3E3 and MGX-FRSM-HS2/B have been added to the list of Cell Bus Service Modules supported on the PXM45/B and PXM45/C.
Platform
The feature is supported on:
•
AXSM/B as Feeder Uplink on MGX 8950
Previously supported only on the MGX 8850-PXM45, the feeder upstream capability will now be supported on the MGX 8950 as well. This feature enables PXM-1 feeder nodes to be directly connected to the AXSM/B cards on MGX 8950 nodes.
Platforms
The feature is supported on:
•
Features and Enhancements in Previous Release 4.0.00
Note
Refer to the "Acronyms" section for definitions of acronyms used in these release notes.Release 4.0.00 contains the following new features:
Table 4 lists which switch supports which new feature.
Table 4 MGX Release 4.0.00 Feature Support by Switch
Closed User Groups (CUG)
YES*
YES
YES
YES
YES
YES
Preferred routes for PNNI Multipeer Group Networks
YES
YES
YES
YES
YES
YES
Point to Multipoint SVC/SPVC support (P2MP)
NO
YES
YES
YES
YES
YES
Increased number of Signaling Interfaces
NO
YES
YES
YES
N/A
N/A
Virtual trunks support in PXM1E
NO
NO
NO
NO
YES
YES
Virtual UNI support in PXM1E
N/A
N/A
N/A
NO
YES
YES
PXM1E as Upstream to Feeder Nodes
N/A
N/A
N/A
NO
YES
YES
AXSM-E Upstream to Feeder Nodes
NO
YES
YES
NO
NO
NO
Cell Bus on PXM451
NO
YES
YES
NO
NO
NO
Additional Narrow Band on PXM1E
N/A
N/A
N/A
NO
YES
YES
AXSM-32-T1E1-E UNI with IMA
NO
YES
YES
NO
N/A
N/A
PXM1E-16-T1E1 UNI with IMA
N/A
N/A
N/A
NO
YES
YES
PXM1E-8-155
N/A
N/A
N/A
N/A
YES
YES
PXM45/C
NO
NO
YES
YES
NO
NO
AXSM-1-9953-XG
NO
NO
NO
YES
NO
NO
AXSM-4-2488-XG
NO
NO
NO
YES
NO
NO
1 Please refer to the CBSM matrix (Table 4) for details.
1 * Closed User Groups is support on PXM45(A) in Release 4.0.10.
Closed User Groups
The Closed User Groups (CUG) supplementary service enables network users to form groups, to and from which access is restricted. A network user may be associated with one CUG, multiple CUGs, or no CUG. Members of a specific CUG can communicate typically among themselves, but in general not with network users outside of the CUG. Specific network users can have additional restrictions preventing them from originating calls to, or receiving calls from, network users of the same CUG (Outgoing Calls Blocked or Incoming Calls Blocked). In addition, a network user can be further restricted in originating calls to, or receiving calls from, network users outside of any CUG membership defined for the network user (Outgoing Access or Incoming Access.).
The feature is based on the ITU-T Q.2955.1 recommendation.
Platforms
The feature is supported on:
•
•
•
•
References
ITU-T Q.2955.1
Preferred Routes for PNNI Multipeer Group Networks
Preferred routing of connections provides the network operator a means of bypassing the PNNI route selection, and configuring a specific path through the network which a connection will follow. Preferred routes can be configured as either Preferred or Directed routes. A Preferred route is one which will follow the configured path if available, but will revert to a PNNI-selected route if the preferred route is not available. A Directed route is one which will follow only the configured path; if the configured path is not available, the connection will remain unrouted.
Preferred routes can be specified for SPVCs from source switch to the destination switch end-to-end using CLI or SNMP. The end-to-end preferred route for connections can span across multiple peer groups. The implementation is based on PNNI 1.1 specification.
Platforms
This feature is supported on:
•
•
•
•
References
PNNI 1.1
Point-to-Multipoint SVC/SPVC Support
The SVC/SPVC point-to-multipoint (P2MP) feature offers the ability for one root SVC/SPVC connection to establish a simple tree topology to one or more leaf connections. The data traffic is uni-directional from root multicast to all leaves, i.e., what is sent from the root data channel is received by all leaves. From the root, leaves can be added to the connection using SETUP/ADD_PARTY signaling messages. Point-to-multipoint is a mandatory feature described in UNI 3.0, UNI3.1 and UNI4.0 specs. The implementation is compliant with in Q2971.
Platforms
This feature is supported on:
•
•
•
Note
References
UNI 3.0, UNI3.1, UNI4.0, Q2971
Increased Number of Signaling Interfaces
Support for up to 192 PNNI routing/signaling interfaces on MGX 8850 (PXM45/B and PXM45/C). Prior to this release, the platform supports only 99 signaling interfaces. The features enables increased signaling interfaces for interconnecting with other switches or DSLAMs.
Platforms
This feature is supported on:
•
•
PXM1E-Related Hardware (the PXM1E-8-155 card)
•
•
•
•
Redundancy Support
The PXM1E PNNI Controller offers redundancy, offer hitless operation, and Y-Redundancy (1:1) will be supported in PXM1E for the 155 interface.
Service Modules will have 1:N redundancy and 1:1 redundancy as supported by the individual service modules
Automatic Protection Switching Support
Automatic Protection Switching (APS) 1:1 and1+1 for both the Bellcore GR-253 and ITU-T G.783 Annex-A and Annex-B standards will be supported for the OC3 and STM1 interfaces. The MGX-8850-APS-CON plane is required for APS functionality.
Modular Transceiver Support in the New 8-port OC3/STM1 Back Card
The PXM1E will support a single universal back card capable of supporting single-mode and multi-mode fiber connectors for the different reaches in OC3 and STM1.
External field-replaceable transceivers for SMF-IR, SMF-LR and MMF, purchased by the customer, will be supported.
UNI connection support in PXM1E-16-T1E1
In a previous software release (3.0.10), the PXM1E-16-T1E1 card provided support for IMA trunking. In the MGX 4.0.00 release, the same card will support both native ATM UNI and IMA UNI endpoints. Sixteen T1/E1 ports can be mixed and matched for either native UNI or NNI ports and IMA UNI or NNI ports.
ATM Routing in PXM1E
The PXM1E-based switches support the ATM Forum standard PNNI routing/signaling based on the same baseline used for MGX 8850 (PXM45) and BPX/SES systems. It can be a peer to the PXM45-based switches in the single peer group and participate in multipeer groups.
Connection Management
Supports different types of connections—SVC, SVP, S-PVC, and S-PVP. UNI 3.X/4.0 signaling and ILMI are used to setup SVCs and SVPs.
PXM1E will support 13,500 local switching connections and 27,000 routed connections.
Cell Bus Service Module Support
A cell bus service module is an MGX service module that uses the MGX cell bus to transport customer traffic between that service module and other services modules or PXM uplinks. Traditionally, the CBSMs were called narrow band service modules (NBSMs).
For a summary of service modules supported in MGX 8830 and MGX 8850 (PXM1E), please refer to Table 4.
Virtual Trunks Support in PXM1E
Virtual trunks will be supported in the PXM1E ports. A maximum of 31 (physical and virtual) trunks can be supported in a PXM1E card. The feature will be supported in 4-port OC3/STM1, 8-port T3/E3, 8-port OC3/STM1, 16- port T1/E1 and the combo PXM1E cards. SVC, SPVC and SPVP connections can be routed over the virtual trunks.Virtual trunks can originate and terminate between PXM1E, AXSM/A, AXSM/B, AXSM-XG and AXSM-E cards.
Virtual UNI Support in PXM1E
A new port type called Virtual UNI (VUNI) and Enhanced Virtual UNI(EVUNI) is defined in addition to the already defined port types UNI, NNI, VNNI (Virtual Trunk). This feature benefits both the MPLS and PNNI control plane.
Feeder Trunk support in PXM1E
PXM1E ports can accept feeder trunks in any port. IGX 8400, MGX 8230, MGX 8250 and MGX 8850 (PXM1) can be added as feeders to MGX 8830 and MGX 8850 (PXM1E).
PXM1E Diagnostics
Both HMM and online diagnostics report alarms in the Hardware Alarm category under the card alarms.
•
•
POST test results printed to the console immediately after execution may display failures. These may be due to tests being attempted for devices not present on the particular PXM1E-board (such as the second ATM policing device on the PXM1E-4-155). The tests are based purely on device offsets and can display spurious results. To confirm/rule-out real and relevant tests, please use the following examples:
Example 1 PXM1E-4-155: ATM policing device 2 and framers 2 and 4 do not exist: Following shows all relevant test cases passed. Although framers 2 and 4 show passed below, those two cases must be ignored.
Power On Self Test Results
Test Name Result Description
BRAM Checksum PASS
QE Ram PASS
CBC Ram PASS
Ethernet Reg PASS
PCI-IDE Reg PASS
Clock Mux PASS
Framer 1 Access PASS
Framer 2 Access PASS
Framer 3 Access PASS
Framer 4 Access PASS
ATLAS 1 Ram PASS
ATLAS 2 Ram FAIL Ingress SRAM: Pattern Not Matched
Hard Disk Access PASS
Example 2 PXM1E-8-T3E3: ATM policing device 2 and framers 3 and 4 do not exist: Following shows all relevant test cases passed.
Power On Self Test Results
Test Name Result Description
BRAM Checksum PASS
QE Ram PASS
CBC Ram PASS
Ethernet Reg PASS
PCI-IDE Reg PASS
Clock Mux PASS
Framer 1 Access PASS
Framer 2 Access PASS
Framer 3 Access FAIL Framer 3 Access 1 Fail
Framer 4 Access FAIL Framer 4 Access 1 Fail
ATLAS 1 Ram PASS
ATLAS 2 Ram FAIL Ingress SRAM: Pattern Not Matched
Hard Disk Access PASS
Example 3 PXM1E-T3E3-155: Following shows all relevant test cases passed.
Power On Self Test Results
Test Name Result Description
BRAM Checksum PASS
QE Ram PASS
CBC Ram PASS
Ethernet Reg PASS
PCI-IDE Reg PASS
Clock Mux PASS
Framer 1 Access PASS
Framer 2 Access PASS
Framer 3 Access PASS
Framer 4 Access PASS
ATLAS 1 Ram PASS
ATLAS 2 Ram PASS
Hard Disk Access PASS
Example 4 PXM1E-8-155: Following shows all relevant test cases passed. For the 8OC3, the ethernet controller test is not done, since the controller is part of the system controller which is not tested in this release.
Power On Self Test Results
Test Name Result Description
BRAM Checksum PASS
QE Ram PASS
CBC Ram PASS
Ethernet Reg NOT_DONE Ethernet Controller Test Not Required.
PCI-IDE Reg PASS
Clock Mux PASS
Framer 1 Access PASS
Framer 2 Access PASS
Framer 3 Access PASS
Framer 4 Access PASS
ATLAS 1 Ram PASS
ATLAS 2 Ram PASS
Hard Disk Access PASS
Example 5 PXM1E-16-T1E1: ATM policing device 2 and framers 1,2,3 and 4 do not exist: Following shows all relevant test cases passed.
Power On Self Test Results
Test Name Result Description
BRAM Checksum PASS
QE Ram PASS
CBC Ram PASS
Ethernet Reg PASS
PCI-IDE Reg PASS
Clock Mux PASS
Framer 1 Access FAIL Framer 1 Access 1 Fail
Framer 2 Access FAIL Framer 2 Access 1 Fail
Framer 3 Access FAIL Framer 3 Access 1 Fail
Framer 4 Access FAIL Framer 4 Access 1 Fail
ATLAS 1 Ram PASS
ATLAS 2 Ram FAIL Ingress SRAM: Pattern Not Matched
Hard Disk Access PASS
AXSM-E as Upstream to Feeder Nodes
Previously supported only with AXSM and AXSM/B cards, the feeder upstream capability will now be supported using the AXSM-E card as well. This feature enables PXM1 and IGX 8400 feeder nodes to be directly connected to the AXSM-E cards on the PXM45 nodes.
Platform
•
Cell Bus Service Modules on PXM45
This feature allows key Cell Bus Service Modules to be supported on the MGX 8850 (PXM45). Where necessary, these cards can be used in conjunction with the SRME or SRM-3T3/C Service Resource Module for distribution and redundancy purposes. Please see Table 4 for details.
Platform
•
Note
Guest
