|
|
The MGX 8240 Private Line Service Gateway offers a high density ATM Circuit Emulation Service (CES) access concentration solution for T1, Fractional T1, and DS0 leased line service providers.
Used in conjunction with an ATM core network, the MGX 8240 provides a cost effective private line transport service. The MGX 8240 provides integration of voice service and private lines, and transfers private line traffic onto a common ATM backbone.
The MGX 8240 can be provisioned and managed remotely from a central management and alarm station, thus decreasing the operations and equipment costs and provisioning time. Because each private line is provisioned through software, new circuits can be added quickly via point-and-click operations.
The MGX 8240 performs the following:
Carriers transfer certain types of constant bit-rate (CBR) or "circuit" traffic over ATM networks. To support CBR traffic, the packet-oriented ATM-based networks must emulate circuit characteristics. A CBR circuit transported using CES over ATM is comparable to the current PDH technology.
Figure 1-1 provides a reference model for CES. It contains two ATM CES Interworking Functions (IWFs) connected to an ATM network via physical interfaces defined in the ATM Forum UNI Specification. The CES IWFs are also connected to standard CBR circuits (for example, DS1).
The job of the two IWFs is to extend the constant bit-rate circuit to which they are connected across the ATM network. This is transparent to the terminating equipment of the CBR circuit. This means that the ATM portion of the connection retains its bit integrity (analog signal loss cannot be inserted and voice echo control cannot be performed). Thus for facilities intended to carry voice or multimedia services, any required echo control must be performed by the terminal equipment or before the ATM CES IWF is encountered. Using AAL 1 over ATM constant bit-rate virtual channels is a simple, general, and effective method of addressing this type of application.
Figure 1-2 shows the Private Line Transport Service.
The following section discusses the types of service modules for the MGX 8240.
Nx64 Service is intended to emulate a point-to-point Fractional DS1. The service is accessed via 1.544 Mbit/s DSX-1 (t1.102 - 1993 Revised). The 24 timeslots available at the DSX-1 interface are carried across the ATM network and reproduced at the output edge.
A large number of applications utilize DS1 interfaces, making use of the entire bandwidth. DS1 Unstructured CBR service is intended to emulate a point-to-point DS1 circuit. The service is accessed via 1.544 Mbit/s DSX-1. The service is defined as a "clear channel pipe", transparently carrying the full data stream (DS1 at 1.544 Mbit/s).
For Synchronous Residual Time Stamp (SRTS), the end-user timing source interface signals are not necessarily traceable to a primary reference source (PRS). For Synchronous, the end-user timing source interface signals must be traceable to PRS.
 |
Note Framing formats other than standard SF or ESF formats cannot be supported by all Plesichronous Digital Hierarchy (PDH)/Synchronous Digital Hierarchy (SDH) installed equipment. If an exchange carrier offers CES service for such non-standard framing formats, the carrier may have difficulty in maintaining the service interface due to the lack of facility support for operations and maintenance functions such as performance monitoring, facility loopbacks, and so forth. |
If SF or ESF framing is used, the DS1 Unstructured service also provides an optional feature that allows non-intrusive performance monitoring of the link.
A Circuit Emulation Service (CES) connection can reside on either a full DS1 (Unstructured or Structured 24 x DS0), fractional DS1 (2 to 24 DS0s), or single DS0. The CES function can support three DS3s for a transfer up to 2016 circuits.
1DS0 to 24 DS0s can only be supported when using Structured mode. Once a connection is built, it cannot be modified between Structured and Unstructured.
Each CES module has multiple sources for deriving the module's timing reference for physical layer clocking (see Figure 1-3). On the Common I/O module, two BITS clock inputs (labeled BITS A and BITS B) connect to each CES module. In addition to the BITS sources, the network OC3 receive timing can also be used for system (module) timing. Network OC3 receive timing can only be used as a timing source for the module where it resides. Modules cannot share an OC3 timing source.
|
Note Each CES module has its own oscillator which drives its timing from the BITS A, BITS B, or local network OC3. |
Synchronization of clocking is critical to forwarding DS1 circuits through the network. Non-synchronized clocks in a TDM network can result in frame slips and loss of data.
To prevent data loss within the network, it is important to keep the clocks of the two TDM end points synchronized with the same reference clock.
Two methods exist for end devices to receive (take timing) from a reference clock:
1. Building Integrated Timing System (BITS) clock
2. Receive clock of the network OC3 circuit
Two BITS timing inputs exist on the MGX 8240—BITS A and BITS B. Either of these timing inputs can be configured as the primary or secondary timing reference. Each module can be configured as BITS A, BITS B, or network OC3.
The MGX 8240 supports definition of a primary and secondary clock on the network. Either method of clocking, BITS or network OC3 receive clock, can be configured to backup the other. The MGX 8240 supports external timing. It accepts three timing references (BITS A, BITS B, and network OC3). The operator can configure any of these as the primary or secondary timing reference source. The active timing source is used to time all transmitted synchronous signals.The MGX 8240 supports a secondary timing reference, that is, it automatically switches to an alternate timing reference when the primary reference fails.
All provisioned references, both primary and secondary, are continuously monitored for failures. When the primary reference fails, the switch uses the secondary reference. When all timing references fail, the MGX 8240 switches to its free-running internal oscillator at the declaration of the failure.
The MGX 8240 allows users to provision the switching mode between references as revertive and non-revertive. The default mode for switching between references is non-revertive. For revertive switching, automatic restoration from secondary to primary occurs within two seconds after the clearing of the reference failure. An alarm is generated when a reference is out of tolerance.
The following status information is available at either the CRAFT interface (CLI):
The MGX 8240 module-level redundancy enables one module to serve as a backup for a configurable number of primary modules. Whenever any of the configured modules a backup is protecting fails, the backup module automatically takes over for the failed primary module-this is known as a SwitchOver. This SwitchOver is not auto-revertive. This means placing the primary module back in service (once repaired or replaced) requires operator intervention via an external management interface-this is known as a Forced-SwitchBack. Note that following a SwitchOver, the remaining modules served by the now switched-in backup are unprotected. In other words, if another module that the same backup was protecting fails (in the same redundancy group), all service on that module is lost.
A backup can be explicitly told to take over for a primary—this is known as a Forced-SwitchOver and can be useful in several instances. These include if the redundancy software should fail to detect a failure and initiate a SwitchOver on its own (the operator can force this to happen). The Forced-SwitchOver can also be useful during maintenance of a primary, such as during a software upgrade on a module. During the period of maintenance, the backup can be forced to switchover so the service provided by the primary is not interrupted during the maintenance.
The MGX 8240 offers a very flexible 1:N module-level redundancy model. A module can be configured to serve in the Redundancy Role of Backup (redundant) module for up to N Primary modules, where N is in the range 1 to 4. Note that the Backup module must be the left-most module within any single Redundancy Group. The configuration of M (number of Redundancy Groups) and N (number of Primary modules in each group) is very simple and intuitive and is done via the management station interfaces. Groups cannot be overlapped. I/O modules must be contiguously populated inside the entire Redundant Group. I/O module types cannot be mixed within a redundant group.
The modules of the MGX 8240 can be arbitrarily grouped into M separate redundancy groups, where M is in the range 0-7. For example, if you configured most conservatively, you could have seven separate 1:1 redundancy groups, and a slot leftover that could be an unprotected primary. Or, if you configured aggressively, you could have one single 1:4 redundancy group.
|
Note Redundancy is not used when the MGX 8240 is to be deployed in its most port-dense configuration (45 channelized DS3s). In this case, all 15 slots are populated with unprotected modules. |
Two IMC cards are used in each MGX 8240 switch to provide 1:1 redundancy. In the initial configuration, the top IMC is the primary one, with the lower card standing by as a backup. Switchovers happen automatically if the primary card fails, or a user can force a switchover.
If a primary IMC card fails, any TCP traffic going through the failed card will be lost. Users should verify the communication of traffic in process during a switchover, and re-establish sessions if necessary.
Whenever switching over to standby IMC, all the active telnet and ftp sessions need to be reinitialed. The current ftp session would get terminated with "netout: Socket operation on non-socket" error for ftps and all telnet sessions would hang.
After a switchover, roles are reversed. When the lower card becomes primary, it stays primary until the next switchover—the original primary/backup status (primary on top, secondary on bottom) is not reset at startup.
Module-level redundancy is configured from the management station. When modules are inserted into the MGX 8240 chassis and CLI level service-turnup is performed via CLI, a module defaults to a Redundancy Role of none, and its Redundancy Operational State is set to non-redundant, meaning it is unprotected by default.
Modules are protected and unprotected (made redundant) via the management station as described below. Note that the management station should maintain a non-volatile database containing the redundancy configuration of the MGX 8240 chassis as a whole.
To configure a selected module to protect (backup) a group of primary modules, the operator uses the management station and simply configures the Redundancy Role of that module to be equal to backup. Thereafter, any module to the right of the backup module (looking from the front of chassis), up to the next module configured as a backup (if any), can be added to the backup's redundancy group (and hence made redundant), by using the management station by setting that module's Redundancy Role to primary.
|
Note Primary modules are reachable via in-band and/or out-of-band management; backup modules are only reachable via out-of-band management. |
The redundancy feature in the PSM1 switch software for Release 1 is incompatible with Release 2. Release 2 redundancy uses new message formats and changes the format of fault management's BBRAM layout. Cisco recommends that all switches in a redundancy group are upgraded simultaneously.
Refer to the redundancy upgrade procedure in the Upgrade Procedure for the MGX 8240 document.
All MGX 8240 CES modules support a CLI and a menu-driven interface. (These network management interfaces comprise the CRAFT interface.) The menu-driven interface is used primarily for supporting the First Day of Service (FDOS) for the switch. It provides the user with a specific set of screens focused at initial setup of the switch. A limited number of troubleshooting commands are also supported.
This CLI can be accessed using one of the following ways:
The MGX 8240 supports in-band and out-of-band network management, providing redundant network management connections between the MGX 8240 and a network management station.
Users can access the MGX 8240 CES modules using IP in one of two ways:
1. In-band through the ATM network (one IP address per module).
2. Out-of-band through an Ethernet connection (one IP address for the entire chassis).
The VCLI is the primary interface for configuring MGX 8240 modules and it is run on an external workstation. It is an SNMP-based network management package.
With in-band management, network management traffic is carried within the data stream on an ATM Permanent Virtual Circuit (PVC). The in-band PVC is configured manually as part of the FDOS setup if the default values are not appropriate. Once established, it carries management queries, configuration values, and asynchronous alarm and event messages between one or more network management stations and CES module(s) on the MGX 8240.
Each active primary CES Module can be configured to use one ATM PVC connection on the ATM trunk port to carry IP datagrams for transport of network management information with the element manager. IP datagrams sent and received over the in-band management ATM PVC are encapsulated using the IETF RFC1483 LLC SNAP encapsulation method for routed IP datagrams.
Any backup, standby, or switched-in primary CES Modules cannot be accessed via in-band management. These must use out-of-band management. The status of the in-band management ATM PVC for carrying IP traffic is assumed to be up. It is considered down in the following conditions:
After an in-band circuit break is detected, the MGX 8240 continues to monitor the failed connection. Once the In-band IP connection is active, TRAP messages are sent to the configured Element Managers to indicate the change in state. Trap messages are automatically sent for both a failure and recovery of the in-band link.
The following in-band statistics are global to the I/O device (which is called a SAR):
The following statistics are for each circuit, which is currently a maximum number of one:
The in-band connection status providing a detailed description of a problem is available via an SNMP query.
Out-of-band management of any of the MGX 8240 CES modules can be achieved by using IP over Ethernet to each of the CES modules via their individual Ethernet ports.
Two network management connections are supported for each module to allow two separate network management paths to be configured for redundancy by configuring one IP connection for in-band network management and the other for out-of-band network management. The in-band connection travels through the ATM data network as a PVC. The IP packets are encapsulated in accordance to RFC-1483, Multiprotocol Encapsulation over ATM Adaptation Layer 5. The out-of-band Ethernet connection is through a Local Area Network (LAN) Ethernet.
The in-band IP connection is used as the primary access path, while the secondary out-of-band Ethernet IP connection is reserved for use as a back-up or failover route.
You may access CLI via Telnet through the following IP addresses in Table 1-1.
| IP Address | Address and Port |
|---|---|
In-band IP address | In-band IP address and port 1000 of the module. |
Out-of-band IP address | Out-of-band IP address and port 1000 of the module. |
Out-of-band with the CIM or IMC | IP address of the CIM or IMC and the port module number (n0004 where n=module number). |
|
Note Each IP connection carries Telnet, FTP and SNMP data packets. The Telnet connection to port 1000 is to the CLI and FDOS menus. The FTP connection allows updates of system binary or configuration files over the network. SNMP packets carry binary queries, configuration settings, replies and asynchronous alarms. These are SNMP V1.0 compatible PDUs. |
The MGX 8240 supports traffic shaping to limit the amount of management traffic sent through the data network, and lessen the chance of management traffic being discarded during transit on the ATM PVC. Users can set these values by configuring the sustained cell rate and peak cell rate for the in-band management PVC. The default transfer speed is 115 KB per second (300 cells per second). The peak cell rate should be equal to or greater the sustained cell rate.
The MGX 8240 has three integral Bit Error Rate Testers (BERTs) on each CES module. BERT testing is done at startup as port of diagnostics on cards. Users can also perform BERT testing manually on a DS1 or CES connection through the VCLI. DS1 BERT can only test the TDM side; connection BERT can test either the TDM or ATM side. All three BERTs can run tests on separate DS1s simultaneously, but each BERT tester can test only one DS1 at a time. Data collected during these tests is stored on the switch, and can later be accessed by the customer via SNMP.
A loopback from the PBX switch to the MGX 8240 should be done before turning on the integral BERTs on the MGX 8240 (see Figure 1-4).
BERT testing can also be performed over a CES Connection. If the CES connection for the connection is configured for Structured CES, then BERT testing on the connection can be used to perform DS0 or NxDS0 BERT testing. BERT testing will not work properly for Structured CES connections that are configured in CAS mode.
If the CES Connection BERT is being performed by looping back the BERT pattern, either the far end of the DS1 port, or the individual DS0s (in the case of NxDS0) must be looped back externally.
During a CES Connection BERT test towards the ATM side of the connection, the local CES endpoint interworking function will not generate or receive ATM cells.
With the OAM Loopback Delay feature, you can measure round trip OAM cell delays through ATM networks. Precise time measurement of OAM cells is performed as follows:
1. The OAM cell generator records the time of the loopback OAM cell creation.
2. The OAM cell generator reads the time of the looped back OAM cell return.
3. The software calculates the OAM Loopback Delay based on the time stamps in Steps 1 and 2.
Automatic Protection Switching (APS) provides a redundant SONET physical link for the OC3 ATM trunk port and the OC3 access port when OC3 I/O is used (see Figure 1-5).
To support APS between a MGX 8240 CES module and an ATM switch, two separate lines provide connection with one line acting as the working line and the second line as the redundant (protection) line.
When OC3 I/O is used, APS is supported on the Access side. Two different APS architectures are defined for SONET trunks: 1+1 and 1:n. The MGX 8240 supports the APS 1+1, non-revertive, unidirectional or bidirectional model. With the 1+1 architecture, the signal is bridged and both links receive the same signal simultaneously. Should the primary link go down, the signal is automatically transferred to the backup or protection line.
The MGX 8240 supports unidirectional or bidirectional APS. When the MGX 8240 is operating in bidirectional APS, only one of the two OC3 directions (TX or RX) needs to fail for the signal to be transferred to the backup (protection line). When it is operating in unidirectional mode, switching of the working channel could happen independently. That is, one switch could receive the signal from the working line, while the other switch could receive the signal from the protection line. Once line conditions change and the working line becomes viable again, the signal can be transferred back to the working line. Because the MGX 8240 supports non-revertive APS, the signal must be transferred back to the working line manually through user configuration.
|
Note Only one ATM logical port is supported per CES module. It resides on the active OC3
trunk. Should a trunk carrying the ATM logical port fail, it automatically switches the
active trunk. When OC3 I/O is used, the Access DS3 data resides on the active Access OC3 line. If the line carying the Access DS3 data fails, it automatically switches the active Access OC3 line. |
Posted: Sun Sep 29 05:16:22 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.