Cisco Reader Comment Card€¦ · Contents iv Cisco MGX 8230 Edge Concentrator Overview Release...

Cisco Reader Comment CardGeneral Information1 Years of networking experience Years of experience with Cisco products

2 I have these network types: LAN Backbone WANOther:

3 I have these Cisco products: Switches RoutersOther: Specify model(s)

4 I perform these types of tasks: H/W Install and/or Maintenance S/W ConfigNetwork Management Other:

5 I use these types of documentation: H/W Install H/W Config S/W ConfigCommand Reference Quick Reference Release Notes Online HelpOther:

6 I access this information through: Cisco Connection Online (CCO) CD-ROMPrinted docs Other:

7 Which method do you prefer?

8 I use the following three product features the most:

Document InformationDocument Title: Cisco MGX 8230 Edge Concentrator Overview

Part Number: 78-12899-01 Rev. B0 S/W Release 1.1.31

On a scale of 1–5 (5 being the best) please let us know how we rate in the following areas:

Please comment on our lowest score(s):

Mailing InformationCompany Name Date

Contact Name Job Title

Mailing Address

City State/Province ZIP/Postal Code

Country Phone ( ) Extension

Fax ( ) E-mail

Can we contact you further concerning our documentation? Yes No

You can also send us your comments by e-mail to [email protected], or fax your comments to us at (408) 527-8089.

The document was written at my technical level of understanding.

The information was accurate.

The document was complete. The information I wanted was easy to find.

The information was well organized. The information I found was useful to my job.

% %% %

BU

SIN

ES

S R

EP

LY

MA

ILF

IRS

T-C

LA

SS

MA

IL P

ER

MIT

NO

. 46

31

SA

N J

OS

E C

A

PO

ST

AG

E W

ILL

BE

PA

ID B

Y A

DD

RE

SS

EE

AT

TN

DO

CU

ME

NT

RE

SO

UR

CE

CO

NN

EC

TIO

NC

ISC

O S

YS

TE

MS

INC

17

0 W

ES

T T

AS

MA

N D

RIV

ES

AN

JOS

E C

A 9

51

34

-98

83

NO

PO

ST

AG

EN

EC

ES

SA

RY

IF M

AIL

ED

IN T

HE

UN

ITE

D S

TA

TE

S

Corporate HeadquartersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706 USAhttp://www.cisco.comTel: 408 526-4000

800 553-NETS (6387)Fax: 408 526-4100

Cisco MGX 8230 Edge Concentrator OverviewRelease 1.1.3January 2002

Customer Order Number: DOC-7812899=Text Part Number: 78-12899-01Rev. B0

http://www.cisco.com

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense.

The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency energy. If it is not installed in accordance with Cisco’s installation instructions, it may cause interference with radio and television reception. This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no guarantee that interference will not occur in a particular installation.

Modifying the equipment without Cisco’s written authorization may result in the equipment no longer complying with FCC requirements for Class A or Class B digital devices. In that event, your right to use the equipment may be limited by FCC regulations, and you may be required to correct any interference to radio or television communications at your own expense.

You can determine whether your equipment is causing interference by turning it off. If the interference stops, it was probably caused by the Cisco equipment or one of its peripheral devices. If the equipment causes interference to radio or television reception, try to correct the interference by using one or more of the following measures:

• Turn the television or radio antenna until the interference stops.

• Move the equipment to one side or the other of the television or radio.

• Move the equipment farther away from the television or radio.

• Plug the equipment into an outlet that is on a different circuit from the television or radio. (That is, make certain the equipment and the television or radio are on circuits controlled by different circuit breakers or fuses.)

Modifications to this product not authorized by Cisco Systems, Inc. could void the FCC approval and negate your authority to operate the product.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

AccessPath, AtmDirector, Browse with Me, CCIP, CCSI, CD-PAC, CiscoLink, the Cisco Powered Network logo, Cisco Systems Networking Academy, the Cisco Systems Networking Academy logo, Fast Step, Follow Me Browsing, FormShare, FrameShare, GigaStack, IGX, Internet Quotient, IP/VC, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, MGX, the Networkers logo, Packet, RateMUX, ScriptBuilder, ScriptShare, SlideCast, SMARTnet, TransPath, Unity, Voice LAN, Wavelength Router, and WebViewer are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All That’s Possible, and Empowering the Internet Generation, are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastSwitch, IOS, IP/TV, LightStream, MICA, Network Registrar, PIX, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.

All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0106R)

Cisco MGX 8230 Edge Concentrator OverviewCopyright © 2001, Cisco Systems, Inc.All rights reserved.

iiiCisco MGX 8230 Edge Concentrator Overview

Release 1.1.3, Part Number 78-12899-01 Rev. B0, January 2002

C O N T E N T S

Preface xiii

Organization xiii

Related Documentation xiv

MGX 8230 Edge Concentrator, Release 1.1 Related Documentation xiv

Cisco WAN Manager, Release 10 Related Documentation xiv

Cisco WAN Switching Software, Release 9.3 Related Documentation xv

Conventions xvi

Obtaining Documentation xvii

World Wide Web xvii

Documentation CD-ROM xvii

Ordering Documentation xvii

Documentation Feedback xviii

Obtaining Technical Assistance xviii

Cisco.com xviii

Technical Assistance Center xix

C H A P T E R 1 System Overview 1-1

Introduction 1-1

MGX 8230 Example Applications 1-2

Feeder to BPX Networks 1-2

Multiservice Standalone Switch 1-3

Multiprotocol Label Switching 1-3

Consolidation of Cisco CPE Traffic 1-5

Multiservice Stand-alone Concentrator 1-6

C H A P T E R 2 Mechanical 2-1

Chassis 2-1

Configuration Rules for Populating Cards in the MGX 8230 2-3

Card Dimensions 2-5

Optical Specifications 2-7

Interface Ranges 2-8

MGX 8230 Power 2-8

Optional AC Power Supply 2-8

DC-Power 2-9

Contents

ivCisco MGX 8230 Edge Concentrator Overview


AC Power Cords Available for Different Regions 2-9

Power Consumption of the Different MGX 8230 Modules 2-10

MGX 8230 System Current Requirement 2-10

Heat Dissipation for a Fully Loaded MGX 8230 2-10

Safety Switches 2-11

Cooling 2-11

Environmental 2-12

Electromagnetic Interference 2-13

Card Cage and Midplane Architecture 2-13

Midplane Functional Description 2-13

Distribution Bus 2-14

Service Redundancy Bus 2-15

Local Bus 2-15

BERT Bus 2-15

Cable Management 2-16

MGX 8230 Cable Management 2-16

C H A P T E R 3 Processor Switch Module 3-1

Overview 3-1

PXM1 Switch Fabric Module 3-1

PXM1 Front Card Support 3-3

PXM1 Back Card Support 3-3

Bandwidth 3-5

Cell Bus Access 3-5

Processor (IDT 4700) 3-6

Clocking Options 3-6

Interfaces 3-6

System Environment Monitoring 3-7

Alarm Circuit and Indicators 3-7

Optical Interfaces 3-9

Physical Layer T3/E3 Interface 3-9

Physical Layer OC-3c/STM-1 Interface 3-9

Physical Layer OC-12c/STM-4 Interface 3-10

ATM Layer 3-10

C H A P T E R 4 Service Modules 4-1

Summary of Modules 4-1

Frame Relay Services 4-4

Contents

vCisco MGX 8230 Edge Concentrator Overview


Summary of FRSM Features By Module Version 4-4

Features Common to All FRSMs 4-5

Frame Relay Service Module Special Features 4-5

Circuit Emulation Services 4-7

CE Service Modules 4-7

CESM-8T1/E1 Features 4-7

CESM-T3/E3 Specific Features 4-11

ATM Service 4-12

AUSM/B Key Features 4-13

AUSM/B Ports 4-13

AUSM/B-IMA 4-14

IMA Protocol 4-15

AUSM/B IMA Features 4-15

Voice Service—VISM 4-16

Service Provider Applications 4-16

Core Functions 4-17

Key Features 4-18

VISM Physical Interfaces 4-20

Redundancy 4-20

Physical Layer Interface T1 4-21

Physical Layer Interface E1 4-21

VISM Card General 4-22

Electrical and Safety Standards 4-22

Service Resource Module 4-23

SRM Architecture 4-23

SRM-3T3/C Features 4-24

Redundancy 4-25

Loopbacks 4-28

BERT Data Path 4-29

Route Processor Module 4-30

C H A P T E R 5 Software Architecture 5-1

Overview 5-1

Platform Software 5-2

Distributed Processing 5-3

VSI 5-3

Networking Control Software 5-4

Cisco IOS Routing Subsystem 5-5

Contents

viCisco MGX 8230 Edge Concentrator Overview


Node Management (Control Point) Software 5-5

SNMP Support 5-5

Command Line Interface 5-5

Alarms and Traps 5-6

Event Logging 5-6

Statistics Registry 5-6

C H A P T E R 6 Network Management 6-1

Network and Element Management 6-1

Open, Standard Interfaces 6-1

CiscoView 6-1

Embedded Management Functions 6-2

Configuration Management 6-2

Resource Management 6-2

Provisioning 6-3

Fault Management 6-3

Performance Management 6-6

Security Management 6-17

Embedded Management Interfaces 6-18

SNMP 6-18

Command Line Interface 6-18

Management Tools 6-19

CiscoView 6-19

Cisco WAN Manager 6-20

Cisco Info Center 6-21

Cisco Provisioning Center 6-22

C H A P T E R 7 Traffic Management 7-1

Traffic Management Functions 7-1

Configurable Traffic Parameters 7-4

Connection Admission Control 7-6

Policing 7-7

Configuring Traffic Descriptors 7-7

Policing Using ATM Forum Standards 7-8

Policing Provisioned Point-to-Point Virtual Circuits 7-9

Service Module Policing Function 7-10

Frame Service Module (FRSM) 7-10

ATM Service Module (AUSM/B) 7-11

Contents

viiCisco MGX 8230 Edge Concentrator Overview


ABR Traffic Policing 7-14

Processor Switch Module (PXM 1) 7-14

QoS and Buffer Architecture 7-17

Frame Service Module (FRSM) 7-18

ATM Service Module (AUSM/B) 7-23

Circuit Emulation Service Module 7-25

Processor Switch Module 7-27

Congestion Control Mechanisms 7-29

EFCI Bit 7-30

EPD/PPD Implementation 7-31

C H A P T E R 8 Reliability, Availability, and Serviceability 8-1

Overview 8-1

Key Availability Features 8-1

Redundancy 8-2

AC Power Shelf (AC systems only) 8-3

Redundancy for DC 8-3

Switchover Mechanism 8-3

Nonbulk Mode Distribution 8-3

Bulk Mode Distribution 8-4

Hot Standby 8-4

Software Upgrades 8-4

Logical Connections 8-4

Performance 8-5

Automatic Protection Switching 8-5

C H A P T E R 9 Network Synchronization 9-1

MGX 8230 Clock Sources 9-1

Synchronization and Timing Support 9-1

Internal Holdover Capability 9-2

External Timing Interfaces 9-2

E1 Interface Compliance 9-4

External Timing 9-4

Continuous Monitoring 9-5

Generating Alarms 9-5

Software/Hardware Upgrades 9-6

Contents

viiiCisco MGX 8230 Edge Concentrator Overview


A P P E N D I X A Statistics Collected A-1

PXM: SONET Statistics Collected A-1

SRM-3T3/B A-3

High-Speed FRSM A-4

FRSM-T1E1 A-6

AUSM/B A-8

CESM-T1E1 A-10

CESM-T3E3 A-11

Channel Counters A-11

A P P E N D I X B Acronym B-1

I N D E X

F I G U R E S

ixCisco MGX 8230 Edge Concentrator Overview


Figure 1-1 MGX 8230 (PXM1) as a Feeder to the BPX Backbone Networks 1-2

Figure 1-2 MGX 8230 Label Edge Routing 1-3

Figure 1-3 MGX 8230 Edge Switch Multiservice Label Feeder Evolution 1-4

Figure 1-4 Consolidation of CPE Services 1-5

Figure 1-5 MGX 8230 Edge Switch as a Stand-alone Concentrator 1-6

Figure 2-1 MGX 8230 Card Cage—Front View 2-2

Figure 2-2 MGX 8230 Card Cage—Rear View 2-2

Figure 2-3 MGX 8230 Slot Configuration 2-3

Figure 2-4 Center Guide Module—Slot Divider 2-4

Figure 2-5 Front View of an MGX 8230 Card Cage 2-4

Figure 2-6 Double-Height Card Dimensions 2-6

Figure 2-7 Single-Height Card Dimensions 2-6

Figure 2-8 AC Power Supply Module—Rear View 2-8

Figure 2-9 MGX 8230 DC Power Entry Module 2-9

Figure 2-10 MGX 8230 Fan Tray Assembly 2-12

Figure 2-11 MGX 8230 Cell Bus Lane Interconnection 2-14

Figure 2-12 Cable Management Assembly at Back Enclosure 2-17

Figure 3-1 PXM1 Architecture 3-1

Figure 3-2 PXM1 LEDs 3-8

Figure 4-1 T1/E1 Clocking Mechanisms 4-8

Figure 4-2 Asynchronous Clocking 4-9

Figure 4-3 Asychronous Clocking (Adaptive) 4-10

Figure 4-4 T3/E3 Clocking Mechanisms 4-11

Figure 4-5 AUSM/B Ports 4-14

Figure 4-6 AUSM/B-IMA Ports 4-15

Figure 4-7 1:N Redundancy 4-25

Figure 4-8 SM Redundancy with Line Modules 4-27

Figure 4-9 Bulk Mode Distribution/Redundancy 4-28

Figure 4-10 BERT Data Path 4-29

Figure 4-11 FRSM to RPM Connection 4-30

Figure 4-12 FRSM to RPM Connection 4-31

Figures

xCisco MGX 8230 Edge Concentrator Overview


Figure 4-13 AUSM/B to RPM Connection 4-32

Figure 4-14 ATM Deluxe Integrated Port Adapter 4-33

Figure 4-15 RPM Block Diagram 4-34

Figure 5-1 MGX 8230 Software Architecture 5-2

Figure 5-2 Platform Software Components 5-3

Figure 5-3 Virtual Switch Interface (VSI) 5-4

Figure 5-4 RPM View of the PXM 5-5

Figure 7-1 PXM Switch Fabric 7-2

Figure 7-2 Ingress Traffic Management 7-3

Figure 7-3 Service Module to Switch Fabric Arbitration 7-3

Figure 7-4 Egress Traffic Management 7-4

Figure 7-5 Ingress Cell Flow 7-11

Figure 7-6 Ingress Flow on an AUSM/B 7-12

Figure 7-7 CBR Traffic Policing 7-12

Figure 7-8 VBR Traffic Policing 7-13

Figure 7-9 ABR Traffic Policing 7-14

Figure 7-10 UBR Traffic Policing 7-14

Figure 7-11 CBR Traffic Policing 7-15

Figure 7-12 VBR Traffic Policing 7-15

Figure 7-13 ABR Traffic Policing 7-16

Figure 7-14 UBR Traffic Policing 7-16

Figure 7-15 Per-VC Queuing on FRSM Cards 7-19

Figure 7-16 FRSM Egress Flow 7-21

Figure 7-17 Per VC Queuing on AUSM/B Card 7-24

Figure 7-18 AUSM/B Egress Flow 7-25

Figure 7-19 CESM Egress Flow 7-26

Figure 7-20 CESM Egress Cell Buffer 7-27

Figure 7-21 CoS Queuing Process 7-28

Figure 9-1 PXM-UI Rear View 9-3

Figure 9-2 PXM-UI-S3 Rear View 9-4

T A B L E S

xiCisco MGX 8230 Edge Concentrator Overview


Table 2-1 MGX 8230 Modules–Physical Characteristics 2-5

Table 2-3 AC Power Cords for Different Regions 2-9

Table 2-4 MGX 8230 Module Power Consumption 2-10

Table 2-5 Service Module Interfaces 2-16

Table 3-1 Cisco MGX 8230 Processor Switch Modules 3-4

Table 3-2 Interface Physical Characteristics 3-5

Table 4-2 CE Service Module Specifications 4-7

Table 4-3 AUSM/B Card Specifications 4-12

Table 6-1 cc (continuity check) Support 6-4

Table 6-2 Service Modules Connection Failure Handling 6-4

Table 7-1 Connection Parameters 7-8

Table 7-2 Frame Relay Policing Parameters 7-8

Table 7-3 Supported Policing Features 7-9

Table 7-4 Policing Rates 7-9

Table 7-5 AUSM UPC Actions Based on VBR Traffic Policing 7-13

Table 7-6 PXM UPC Actions Based on VBR Traffic Policing 7-16

Table 7-7 UPC Actions Based on UBR Traffic Policing 7-17

Table 7-8 FRSM Mapping Configurations 7-30

Table 9-1 Stratum 3 Requirements 9-1

Table 9-2 Stratum 4 Requirements 9-1

Tables

xiiCisco MGX 8230 Edge Concentrator Overview


xiiiCisco MGX 8230 Edge Concentrator Overview


Preface

Welcome to the product overview for the Cisco MGX 8230 Edge Concentrator.

OrganizationThis document is organized into the following chapters and appendices:

Chapter 1 System Overview Describes the features and functions of the MGX 8230 Edge Concentrator.

Chapter 2 Mechanical Describes the physical layout of the MGX 8230, the core cards, slot allocation, power modules and fan assemblies.

Chapter 3 Processor Switch Module

Describes the PXM-1 core processor module available in Release 1.1.3.

Chapter 4 Service Modules Describes the individual service modules available in Release 1.1.3.

Chapter 5 Software Architecture

Provides an overview of the Cisco MGX 8230 software components.

Chapter 6 Network Management

Provides an overview of the Cisco multiservice management tools

Chapter 7 Traffic Management Provides an overview of the Cisco MGX 8230 traffic management features.

Chapter 8 Reliability, Availability, and Serviceability

Describes the Reliability, Availability, and Serviceability (RAS) features supported on the Cisco MGX 8230 system.

Chapter 9 Network Synchronization

Provides an overview of the role of the Cisco MGX 8230 switch in network-wide clock synchronization.

xivCisco MGX 8230 Edge Concentrator Overview


PrefaceRelated Documentation

Related DocumentationThe following Cisco publications contain additional information related to the operation of the Cisco MGX 8230 Edge Concentrator.

MGX 8230 Edge Concentrator, Release 1.1 Related DocumentationThe following table lists documentation that contains additional information related to the installation and operation of the MGX 8230 Edge Concentrator.

Cisco WAN Manager, Release 10 Related DocumentationThe following table lists the documentation for the Cisco WAN Manager (CWM) network management system for Release 10.

Appendix A Statistics Collected Provides information about the Cisco MGX 8230 statistics.

Appendix B Acronym Provides information about acronyms pertinent to the Cisco MGX 8230 system in particular, as well as to wide area networking in general.

Table 1 MGX 8230 Edge Concentrator Related Documentation

Documentation Description

Cisco MGX 8230 Edge Concentrator Installation and Configuration, Release 1.1.3

DOC-7811215=

Provides installation instructions for the MGX 8230 Edge Concentrator.

Cisco MGX 8230 Edge Concentrator Command Reference, Release 1.1.3

DOC-7811211=

Provides detailed information on the general command line interface commands.

Cisco MGX 8230 Error Messages, Release 1.1.3

DOC-7811213=

Provides error message descriptions and recovery procedures.

WAN CiscoView for the MGX 8230 Edge Concentrator, Release 1.1.3

DOC-7810617=

Provides instructions for using WAN CiscoView for the MGX 8230 Edge Concentrator.

xvCisco MGX 8230 Edge Concentrator Overview


PrefaceRelated Documentation

Cisco WAN Switching Software, Release 9.3 Related DocumentationThis table lists related documentation for the installation and operation of the Cisco WAN Switching Software, Release 9.3 and associated equipment in a Cisco WAN switching network.

Table 2 Cisco WAN Manager Release 10 Related Documentation


Cisco WAN Manager Installation for Solaris, Release 10

DOC-7810308=

Provides procedures for installing Release 10 of the CWM network management system on Solaris systems.

Cisco WAN Manager User’s Guide, Release 10

DOC-7810658=

Provides procedures for operating Release 10 of the CWM network management system.

Cisco WAN Manager SNMP Service Agent Guide, Release 10

DOC-7810786=

Provides information about the CWM Simple Network Management Protocol Service Agent components and capabilities.

Cisco WAN Manager Database Interface Guide, Release 10

DOC-7810785=

Provides the information to gain direct access to the CWM Informix OnLine database that is used to store information about the elements within your network.

Table 3 Cisco WAN Switching Release 9.3 Related Documentation


Cisco BPX 8600 Series Installation and Configuration, Release 9.3.10

DOC-7811603=

Provides a general description and technical details of the BPX broadband switch.

Cisco IGX 8400 Installation and Configuration

DOC-7810722=

Provides installation instructions for the IGX multiband switch.

Update to the IGX 8400 Installation and Configuration, Release 9.3.10

DOC-7811029=

Update for Release 9.3.10 to the Cisco IGX 8400 Installation and Configuration .

Cisco IGX 8400 Series Reference

DOC-7810706=

Provides a general description and technical details of the IGX multiband switch.

Cisco WAN Switching Command Reference, Release 9.3.05

DOC-7810703=

Provides detailed information on the general command line interface commands.

Update to the Cisco WAN Switching Command Reference, Release 9.3.10

DOC-7811457=

Provides detailed information on updates to the command line interface commands for features new to switch software Release 9.3.10.

xviCisco MGX 8230 Edge Concentrator Overview


PrefaceConventions

ConventionsThis publication uses the following conventions to convey instructions and information.

Command descriptions use these conventions:

• Commands and keywords are in boldface.

• Arguments for which you supply values are in italics.

• Required command arguments are inside angle brackets (< >).

• Optional command arguments are in square brackets ([ ]).

• Alternative keywords are separated by vertical bars ( | ).

Examples use these conventions:

• Terminal sessions and information the system displays are in screen font.

• Information you enter is in boldface screen font.

• Nonprinting characters, such as passwords, are in angle brackets (< >).

• Default responses to system prompts are in square brackets ([ ]).

Cisco WAN Switching SuperUser Command Reference, Release 9.3.10

DOC-7810702=

Provides detailed information on the command line interface commands requiring SuperUser access authorization

Cisco MPLS Controller Software Configuration Guide, Release 9.3.10

DOC-7811658=

Provides information on a method for forwarding packets through a network.

Table 3 Cisco WAN Switching Release 9.3 Related Documentation


xviiCisco MGX 8230 Edge Concentrator Overview


PrefaceObtaining Documentation

Notes, tips, cautions, and warnings use the following conventions and symbols:

Note Means reader take note. Notes contain helpful suggestions or references to materials not contained in this manual.

Timesaver Means the described action saves time. You can save time by performing the action described in the paragraph.

Caution Means reader be careful. In this situation, you might do something that could result in equipment damage or loss of data.

Warning This warning symbol means danger. You are in a situation that could cause bodily injury. Before you work on any equipment, be aware of the hazards involved with electrical circuitry and be familiar with standard practices for preventing accidents.

Obtaining DocumentationThe following sections provide sources for obtaining documentation from Cisco Systems.

World Wide WebYou can access the most current Cisco documentation on the World Wide Web at the following sites:

• http://www.cisco.com

• http://www-china.cisco.com

• http://www-europe.cisco.com

Documentation CD-ROMCisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or as an annual subscription.

Ordering DocumentationCisco documentation is available in the following ways:

• Registered Cisco Direct Customers can order Cisco Product documentation from the Networking Products MarketPlace:

http://www.cisco.com/cgi-bin/order/order_root.pl

xviiiCisco MGX 8230 Edge Concentrator Overview


PrefaceObtaining Technical Assistance

• Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store:

http://www.cisco.com/go/subscription

• Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, in North America, by calling 800 553-NETS(6387).

Documentation FeedbackIf you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco.

You can e-mail your comments to [email protected].

To submit your comments by mail, for your convenience many documents contain a response card behind the front cover. Otherwise, you can mail your comments to the following address:

Cisco Systems, Inc.Document Resource Connection170 West Tasman DriveSan Jose, CA 95134-9883

We appreciate your comments.

Obtaining Technical AssistanceCisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools. For Cisco.com registered users, additional troubleshooting tools are available from the TAC website.

Cisco.comCisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information and resources at anytime, from anywhere in the world. This highly integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.

Cisco.com provides a broad range of features and services to help customers and partners streamline business processes and improve productivity. Through Cisco.com, you can find information about Cisco and our networking solutions, services, and programs. In addition, you can resolve technical issues with online technical support, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available.

Customers and partners can self-register on Cisco.com to obtain additional personalized information and services. Registered users can order products, check on the status of an order, access technical support, and view benefits specific to their relationships with Cisco.

To access Cisco.com, go to the following website:

http://www.cisco.com

xixCisco MGX 8230 Edge Concentrator Overview



Technical Assistance CenterThe Cisco TAC website is available to all customers who need technical assistance with a Cisco product or technology that is under warranty or covered by a maintenance contract.

Contacting TAC by Using the Cisco TAC Website

If you have a priority level 3 (P3) or priority level 4 (P4) problem, contact TAC by going to the TAC website:

http://www.cisco.com/tac

P3 and P4 level problems are defined as follows:

• P3—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.

• P4—You need information or assistance on Cisco product capabilities, product installation, or basic product configuration.

In each of the above cases, use the Cisco TAC website to quickly find answers to your questions.

To register for Cisco.com, go to the following website:

http://www.cisco.com/register/

If you cannot resolve your technical issue by using the TAC online resources, Cisco.com registered users can open a case online by using the TAC Case Open tool at the following website:

http://www.cisco.com/tac/caseopen

Contacting TAC by Telephone

If you have a priority level 1(P1) or priority level 2 (P2) problem, contact TAC by telephone and immediately open a case. To obtain a directory of toll-free numbers for your country, go to the following website:

http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml

P1 and P2 level problems are defined as follows:

• P1—Your production network is down, causing a critical impact to business operations if service is not restored quickly. No workaround is available.

• P2—Your production network is severely degraded, affecting significant aspects of your business operations. No workaround is available.

xxCisco MGX 8230 Edge Concentrator Overview



C H A P T E R

1-1Cisco MGX 8230 Edge Concentrator Overview


1System Overview

IntroductionThe Cisco MGX 8230 Edge Concentrator provides a gateway for narrowband services in space and power limited situations. The MGX 8230 acts as a standalone gateway or as a feeder for the Cisco IGX 8400 and Cisco BPX 8600 Series Multiservice Switches. The MGX 8230 offers a full range of narrowband service interfaces and a switching capacity up to 1.2 Gbps.

The MGX 8230 delivers Frame Relay, Circuit Emulation (CE), ATM cell relay service, IP VPNs (VoIP, VoATM) and voice at high volume and with high scalability—from DS0 to OC-12C/STM-4 speeds. The MGX 8230 chassis accommodates narrowband interfaces from DS0 with port density scaling to more than 1000 DS1s of service interfaces.

The MGX 8230 supports both Layer 2 and Layer 3 services.

Services include

• IP VPNs using Cisco IOS software-based MPLS/label switching

• Voice-over-IP and voice-over-ATM

• Frame Relay services

• High-density Point-to-Point Protocol (PPP) for Internet access and aggregation

• Narrowband ATM for managed data, voice, and video services

• Circuit Emulation (CE) for private line replacement

The MGX 8230 platform can also support a wide range of services over narrowband and mid-band user interfaces, mapping all the service traffic to and from ATM, based upon standardized interworking methods.

The MGX 8230 switches support up to 64 channelized or unchannelized T1 and E1 interfaces on a single switch, providing support for Frame Relay UNI and NNI; ATM UNI, NNI, and FUNI, Frame Relay-to-ATM network interworking; and Frame Relay-to-ATM service interworking. Using the Service Resource Module (SRM), multiple T1 interfaces can be supported on physical T3 lines. Frame-based services on T3 and E3 high-speed lines are also supported. The MGX 8230 switches also support the use of Inverse Multiplexing for ATM (IMA) to provide ATM trunking below T3/E3.

The MGX 8230 can be either rack mounted in a 19-inch rack, or fitted with side panels to be a free-standing box. An optional mounting bracket kit is available for mounting in 23-inch racks.



Chapter 1 System OverviewMGX 8230 Example Applications

MGX 8230 Example ApplicationsThe MGX 8230 switch is a multiservice, carrier-class platform that aggregates IP, Frame Relay, ATM, voice, and private lines at the edge of the network. This section contains information on the following applications:

• Feeder to BPX Networks, page 1-2

• Multiservice Standalone Switch, page 1-3

• Multiprotocol Label Switching, page 1-3

• Consolidation of Cisco CPE Traffic, page 1-5

• Multiservice Stand-alone Concentrator, page 1-6

Feeder to BPX NetworksThe MGX 8230 supports the networking protocols required to integrate into an existing BPX network, so an MGX 8230 switch can be deployed as a feeder of a BPX 8600 series service node.

By enabling deployment of multiple services on a single platform, this capability allows carriers to customize deployments across diverse point-of-presence (PoP) while maintaining common inventory and operations support.

Configuring as a feeder to BPX networks (see Figure 1-1) has several enhancements:

• In addition to the T3/E3 and OC-3Cc/STM-feeder trunking options, the MGX 8230 also supports an OC-12c/STM-4 feeder trunk to the BPX 8600 for greater aggregate capacity for traffic, which can be fed to the BPX 8600 core switching shelf.

• The MGX 8230 supports local switching between port. This allows MGX 8230 feeders to be situated remotely from the BPX and perform local switching without consuming either bandwidth on the feeder trunk or BPX connection counts.

• The MGX 8230 supports SONET/SDH 1+1 automatic protection switching (APS) on both the OC-3c/STM-1 and OC-12c/STM-4 interfaces. With APS, the feeder trunk is also protected against fiber cuts with 50 ms switchovers. This is particularly important for remote feeder applications.

Figure 1-1 MGX 8230 (PXM1) as a Feeder to the BPX Backbone Networks

BPX ATMnetwork

MGX1

Feedertrunk

BPX1

MGX2

SM

PXM1 Feeder

trunk

SM

PXM1

BPX2

4302

0




Multiservice Standalone SwitchThe MGX 8230 can be deployed as a stand-alone switch, providing “cross-connect” connections between UNI and NNI ports. Traditionally, this would be used in a concentration-type mode, allowing standards-based adaptation and concentration of multiservice traffic onto one or more high-speed ATM interfaces. This enables the MGX 8230 to interface to a multivendor ATM network, or to any other ATM attached device (such as a Cisco 7200 or GSR router LS1010, MSR 8450, and so on).

The MGX 8230 interfaces to the ATM equipment using a standard ATM UNI or NNI.

Multiprotocol Label SwitchingThe MGX 8230 is well suited as an edge device in an Multiprotocol Label Switching (MPLS) network. The MGX 8230 can act as an edge label switch router for support of IP traffic. At the same time, the MGX 8230 can also support Layer 2 services as a BPX feeder or as a multiservice stand-alone switch.

As a component of the BPX 8680-IP universal service node, the MGX 8230 is capable of forwarding traffic into the BPX MPLS network by acting as a multiservice feeder and supporting up to 12 edge label switch routers in a single chassis.

The MGX 8230 can also be used to aggregate and separate the IP traffic onto a pure IP backbone, distinct from the ATM backbone it uses for Layer 2 services.

Figure 1-2 MGX 8230 Label Edge Routing

As a label switch or alabel edge router, the MGX 8230 can interface to a multiservice IP+ATM network consisting of BPX and/or MGX 8230 label switches. The MGX 8230 can also interface to a pure IP backbone such as the one depicted in Figure 1-3.

MGX 8230 edge labelswitch routers

MGX 8230 edge labelswitch routers

BPX label switchnetworkATM label switch

LSC

LER

5786

4




Figure 1-3 MGX 8230 Edge Switch Multiservice Label Feeder Evolution

MGX 8800

ATM labelswitches

BPX 8650 5786

6

Provider multiservicenetwork

GSR

ATM labelswitches

Labelswitches

Label edgeswitches

MGX 8230MGX 8230

FRPPP ATM FR PPP

CES

7500

Provider IPnetwork




Consolidation of Cisco CPE TrafficAt the edge of the network, the MGX 8230 can interwork with and consolidate a wide variety of CPE equipment (see Figure 1-4) – ATM, FR, and voice (both Cisco and multivendor).

Figure 1-4 Consolidation of CPE Services

4302

3

IP+ATMnetwork

SS7/PSTNnetwork

Virtualswitchcontroller

PBX

BPX/MGXBPX/MGX

3810 ATMMultiservice

access

VoATM

VoIP

TDMCable

xDSL

CPE router




Multiservice Stand-alone ConcentratorThe MGX 8230 can be deployed as a stand-alone concentrator, interfacing to a multivendor ATM (non-BPX) network, as shown Figure 1-5. The MGX 8230 interfaces to ATM equipment using a standard ATM UNI or NNI.

Figure 1-5 MGX 8230 Edge Switch as a Stand-alone Concentrator

The MGX 8230 supports ATM UNI and NNI service for PVCs. The switch can be deployed in scenarios where other ATM equipment has already been deployed and where an MGX 8230 switch can provide a front end as a multiservice concentration device.

The ATM UNI port can be supported at the PXM uplink to eliminate the need to use a separate card for ATM trunking. In addition, the MGX 8230 supports local switching between service modules and PXM ports.

5786

8

Branch office

MGX 8230

3610

Third-partyATM UNI

PBX

Branch office

3600

C H A P T E R



2Mechanical

This section describes the mechanical design of the MGX 8230, including chassis, power options, midplane, cabling, and EMI.

ChassisThe MGX 8230 is a 14-slot chassis with horizontally mounted processor modules, service modules, and back cards:

• Two double-height slots are dedicated for the PXM1 modules.

• Eight single-height slots (or four double-height slots) are used for service modules.

• Two single-height slots are used for Service Resource modules.

Slots are numbered 1 to 7 on the left half of the chassis, and 8 to 14 on the right side of the chassis.

Note Although the card slots in an MGX 8230 are horizontal, this manual refers to the card slots and modules as single-height and double-height. The PXM and service module cards are a subset of the MGX 8250 cards that are installed vertically in an MGX 8250 chassis.

Since front slots 1 and 2 are always double-height for PXM1 processor modules, slots 8 and 9 refer only to the back card slots that correspond to the two lower single-height slots on the left side of the chassis as seen from the rear.

When a double-height front card is installed, the left slot number is used. The back cards are numbered according to the front card numbering scheme, with the exception of slots 8 and 9 as noted above.

• Figure 2-1 is a front view of an empty MGX 8230 chassis.

• Figure 2-2 is a rear view of an empty MGX 8230 chassis.

• Figure 2-3 shows the slot configuration of an MGX 8230 chassis.

For information on converting single-height slots, see the “Changing a Single-Height Card Slot to a Double-Height Card Slot” section on page 2-3.

The MGX 8230 chassis is 17.72 inches wide, 12.25 inches high (14.00 inches high with optional AC Power Tray), and 23.5 inches deep. The chassis can be mounted in either a 19-inch or a 23-inch EIA/RETMA and ETSI racks. Figure 2-3 illustrates the different sections of the MGX 8230 chassis.



Chapter 2 Mechanical

Figure 2-1 MGX 8230 Card Cage—Front View

Figure 2-2 MGX 8230 Card Cage—Rear View

2626

826

269



Chapter 2 MechanicalConfiguration Rules for Populating Cards in the MGX 8230

Configuration Rules for Populating Cards in the MGX 8230 The following rules and guidelines are to assist the user in installing single-height and double-height service modules in an MGX 8230 chassis. Rules must be followed while guidelines are instituted for better performance.

Changing a Single-Height Card Slot to a Double-Height Card Slot

The MGX 8230 is typically configured at the factory as you ordered it. Unused card slots are configured for single-height modules and covered with blank faceplates.

Single-height service module slots 3–7 and 10–14 can be converted into double-height slots by removing the center divider module.

Note When converting single-height slots into double-height slots, the conversion must start from the bottom and be contiguous. For example, slot 3 must be converted to a double-height slot before slot 4 can be converted.

Figure 2-3 illustrates the slot numbering of an MGX 8230 with slot 3 configured for a double-height module.

Figure 2-3 MGX 8230 Slot Configuration

Note After conversion, the left slot, which identifies both single-height and double-height slots, is numbered from the left side. Thus, slot 4 could refer to either a single-height slot or a double-height slot. The right slots are numbered on the right side, as shown in Figure 2-3, and refer only to single-height slots.

SRM7

6

5

4

3

2

1

SRM

SM SM

SM SM

SM SM

SM

FAN TRAY

7 RU(12.25 in.,31.1 cm.)

17.72 in.(45 cm.)

1 RU(1.75 in.,4.5 cm.)

PXM 2

PXM 1

Optional AC power tray

14

13

12

11

10

23.5 in.,(59.7 cm.)

3837

5

8

9



Chapter 2 MechanicalConfiguration Rules for Populating Cards in the MGX 8230

• Figure 2-4 illustrates a the center guide module.

• Figure 2-5 shows the location of center guide modules in the MGX 8230 chassis.

Figure 2-4 Center Guide Module—Slot Divider

Figure 2-5 Front View of an MGX 8230 Card Cage

2381

9

2382

0



Chapter 2 MechanicalCard Dimensions

Card DimensionsTable 2-1 shows the physical characteristics for modules supported on the MGX 8230.

Table 2-1 MGX 8230 Modules–Physical Characteristics

Service Module Back Cards Height (in.) Width (in.) Weight

AX-FRSM-8T1 AX-RJ48-8T1 7.25 15.83 1.74 lb. (0.79kg)

AX-FRSM-8E1 AX-RJ48-8E1 7.25 15.83 1.74 lb. (0.79kg)

AX-FRSM-2CT3 AX-BNC-2T3 7.25 15.83 1.74 lb. (0.79kg)

AX-FRSM-2T3E3 AX-BNC-2T3 7.25 15.83 1.74 lb. (0.79kg)

AX-AUSM/B-8-T1 AX-RJ48-8T1 7.25 15.83 1.74 lb. (0.79kg)

AX-AUSM/B-8-E1 AX-RJ48-8E1 7.25 15.83 1.74 lb. (0.79kg)

AX-CESM-8T1 AX-RJ48-8T1 7.25 15.83 1.74 lb. (0.79kg)

AX-CESM-8E1 AX-RJ48-8E1 7.25 15.83 1.74 lb. (0.79kg)

AX-CESM-T3E3 AX-2-T3E3 7.25 15.83 1.74 lb. (0.79kg)

MGX-VISM-8T1 AX-RJ48-8T1 7.25 15.83 1.74 lb. (0.79kg)

MGX-VISM-8E1 AX-RJ48-8E1 7.25 15.83 1.74 lb. (0.79kg)

AX-FRSM-HS1/B MGX-12IN1-4S (4xV.35)

7.25 15.83 1.74 lb. (0.79kg)

AX-FRSM-HS2 AX-SCSI2-2HSSI 7.25 15.83 1.74 lb. (0.79kg)

MGX-SRM-3T3 MGX-BNC-3T3-M 7.25 15.83 1.74 lb. (0.79kg)

PXM1-2-T3E3 MGX-BNC-2T3E3 15.65

7.0 (BC)

15.83

4.125 (BC)

4.8 lb. (2.18kg)

PXM1-4-155 MGX-SMFIR-4-155

MGX-SMFLR-4-155

MGX-MMF-4-155

15.65

7.0 (BC)

15.83

4.125 (BC)

4.8 lb. (2.18kg)



Chapter 2 MechanicalCard Dimensions

Figure 2-6 is an illustration of the Double-Height Card Dimensions.

Figure 2-6 Double-Height Card Dimensions

Figure 2-7 is an illustration of the Single-Height Card Dimensions.

Figure 2-7 Single-Height Card Dimensions

PXM1-1-622 MGX-SMFIR-1-622

MGX-SMFLR-4-155

15.65

7.0 (BC)

15.83

4.125 (BC)

4.8 lb. (2.18kg)

MGX-RPM-64M MGX-RJ45-FE

MGX-MMF-FE

MGX-RJ45-4E

MGX-MMF-FDDI

MGX-SMF-FDDI

15.65

7.0 (BC)

15.83

4.125 (BC)

4.8 lb. (2.18kg)

Table 2-1 MGX 8230 Modules–Physical Characteristics (continued)

Service Module Back Cards Height (in.) Width (in.) Weight

Width 15.83 in. Width 4.125 in.

Double-heightfront card

Single-heightback cards

Height15.65 in.

Height7.00 in.

4302

7

Height7.00 in.

Width 15.83 in. Width 4.125 in.

Double-heightfront card

Single-heightback cards

Height7.15 in.

Height7.00 in.

4302

8



Chapter 2 MechanicalOptical Specifications

Optical SpecificationsTable 2-2 provides the optical specifications for the different interfaces.

As the optical transceivers in the PXM1 interfaces are compliant with ITU-T G.957, the dispersion tolerance according to G.957 are:

• STM-1 Intermediate Reach (S-1.1)—Maximum dispersion in the optical path is 96 ps/nm

• STM-1 Long Reach (L-1.1)—Maximum dispersion in the optical path is 185 ps/nm

• STM-4 Intermediate Reach (S-4.1)—Maximum dispersion in the optical path is 74 ps/nm

• STM-4 Long Reach (L-4.1)—Maximum dispersion in the optical path is 109 ps/nm

The modulation used in all PXM1 optics is direct build-in electroabsortion modulator in standard temperature range (0 – 70°C).

The type of laser sources for the different PXM1 interfaces are

• OC-3 IR: Fabry-Perot

• OC-3 LR: Fabry-Perot


• OC-12 LR: DFB

All MGX single mode optical interfaces (OC-3, OC-12, and OC-48) are terminated with the UPC (Ultra Physical Contact) polish type. Note that this does not apply to multimode fiber. The UPC polish includes an extended polishing cycle at the end-face surface for a better surface finish, resulting in back reflection as low as -55 dB.

Table 2-2 Optical Specifications

Back CardLight SourceType/Wavelength

Tx PowerMin/Max

Rx PowerMin/Max

ConnectorType Range

OC-3 MMF LED / 1310 nm –22 /–15 dBm –31 /–10 dBm SC 2 km

OC-3/STM-1 SMF IR Laser Diode / 1310 nm –15 /–8 dBm –28 /–8 dBm SC 15 km

OC-3/STM-1 SMF LR Laser Diode / 1310 nm –5 / 0 dBm –34 /–10 dBm SC 40 km

OC-12/STM-4 SMF IR Laser Diode / 1310 nm –15 /–8 dBm –28 /–8 dBm SC 15 km

OC-12/STM-4 SMF LR Laser Diode / 1310 nm –5 / 0 dBm –28 /–8 dBm SC 40 km

OC-12/STM-4 SMF ER Laser Diode / 1550 nm –3 / +2 dBm –28 /–8 dBm SC 50+ km



Chapter 2 MechanicalMGX 8230 Power

Interface RangesThe supported cable distance ranges are shown in the following list.

1. DS1 per ANSI T1.102 states distance of 655 feet. This refers to a compliant pulse (per pulse mask template) to the DSX-1 (cross-connect).

2. Ethernet (10BaseT) is a distance of 100 meters to the first repeater.

3. DS3 per ANSI T1.102 is a distance of 450 feet to the DSX-3 cross-connect.

4. HSSI per ITU-T V.12 (ANSI/EIA/TIA-612) is a distance of 50 feet (15 meters) between load and generator.

MGX 8230 PowerThe MGX 8230 power system is designed with distributed power architecture centered around a –48 VDC bus on the system backplane. The –48 VDC bus accepts redundant DC power from either a –42 to –56 VDC source via optional DC power entry modules (PEMs) or from a 100 to 120, or a 200 to 240, VAC source via the optional AC Power Supply Tray. The MGX 8230 backplane distributes power via connectors on the –48 VDC bus to each hot-pluggable processor or service module. Each card incorporates on-board DC-DC converters to convert the –48 VDC from the distribution bus voltage to the voltages required on the card.

Optional AC Power SupplyFor an AC-powered MGX 8230, an optional AC power supply tray is attached to the bottom of the 8230 card cage at the factory. The AC power supply tray is 1 rack-unit high, and can hold up to two AC Power Supply modules. Each AC Power Supply module can provide up to 1200W at 48VDC and has its own AC power cord and power switch. Figure 9 shows the rear view of an optional AC Power Supply module. The power supplies can be configured as 1+1 redundant. If no redundancy is desired, an AC tray with one AC power supply and one AC power cord can also be ordered.

Figure 2-8 AC Power Supply Module—Rear View

Each AC Power Supply Module incorporates the following features:

• One rack unit high

2381

8

AC DC




• Output capacity of 1200 Watts at –48 VDC

• O-ring diode

• EMI filtering

• Cooling fan

• Power switch

• DC and AC status LEDs

DC-PowerFor DC systems, a DC Power Entry Module (PEM) is required for each DC source of central office power –42 to –56 VDC. The MGX 8230 can support two DC power sources and has rear panel slots for two DC PEMS. Figure 2-9 illustrates a DC PEM.

The DC PEMs incorporate the following features:

• Hot swappable

• O-ring diode

• EMI filtering

Figure 2-9 MGX 8230 DC Power Entry Module

AC Power Cords Available for Different RegionsThe following chart details the AC power cords available by regions.

48 VD

C 30A

TB

1

1 2 3

OF

F

1727

5

Table 2-3 AC Power Cords for Different Regions

Power cord with AS 3112 plug (Australia)

Power cord with CEE 7/7 plug (Continental Europe)

Power cord with BS 1363 plug (UK)

Power cord with CEI 23-16/VII plug (Italy)

Power cord with NEMA Lb-20P Twistloc (U.S.)

Power cord with NEMA5-15P 125V/15 A plug (North America)




Power Consumption of the Different MGX 8230 ModulesThe power consumption of the different modules is defined in Table 2-4.

MGX 8230 System Current RequirementThe current requirements are configuration-dependent. For general planning purposes use

48VDC, Current rating: 25 AMP

Note The total power consumption is dependent on the configuration of the MGX 8230.

Heat Dissipation for a Fully Loaded MGX 8230A fully loaded, AC powered MGX 8230 dissipates up to 4800 Btus. A DC powered MGX 8230 dissipates up to 4100 Btus.

Table 2-4 MGX 8230 Module Power Consumption

Service Module Back Cards Power Consumption

AX-FRSM-8T1 AX-RJ48-8T1 29.30 watt

AX-FRSM-8E1 AX-RJ48-8E1 29.30 watt

AX-FRSM-2CT3 AX-BNC-2T3 49.20 watt

AX-FRSM-2T3E3 AX-BNC-2T3 45.25 watt

AX-AUSM/B-8-T1 AX-RJ48-8T1 28.22 watt

AX-AUSM/B-8-E1 AX-RJ48-8E1 25.75 watt

AX-CESM-8T1 AX-RJ48-8T1 29.10 watt

AX-CESM-8E1 AX-RJ48-8E1 29.10 watt

AX-CESM-T3E3 AX-2-T3E3 32.45 watt

MGX-VISM-8T1 AX-RJ48-8T1 60.10 watt

MGX-VISM-8E1 AX-RJ48-8E1 60.10 watt

AX-FRSM-HS1/B MGX-12IN1-4S (4xV.35) 35.00 watt

AX-FRSM-HS2 AX-SCSI2-2HSSI 56.56 watt

MGX-SRM-3T3 MGX-BNC-3T3-M 25.24 watt

PXM1-2-T3E3 MGX-BNC-2T3/E3 71.50 watt

PXM1-4-155 MGX-SMFIR-4-155 105.85 watt

PXM1-4-155 MGX-MMF-4-155 78.00 watt

MGX-RPM-128M/B MGX-RJ45-4E 104.43 watt

MGX-RPM-128M/B MGX-RJ45-FE 107.46 watts

MGX-RPM-128M/B MGX-MMF-FDDI 126.72 watt



Chapter 2 MechanicalCooling

Safety SwitchesThe MGX 8230 does not use circuit breakers instead of switches or magnetic conductors. These circuit breakers are compliant with VDE and IEC 950 specifications.

Circuit Breakers

For an AC-powered MGX 8230, verify that the shelf's power comes from dedicated AC branch circuits. The circuits must be protected by a dedicated, 15 amp circuit breaker. Cisco Systems recommends that the site has a 15 amp AC circuit breaker with a long trip-delay at each branch circuit.

For a DC-powered MGX 8230, verify that its power comes from a dedicated DC branch circuit. This branch circuit must be protected by a dedicated circuit breaker. Cisco Systems recommends that the site has a dedicated 30 amp circuit breaker with a medium trip delay at each branch circuit. A DC-powered MGX 8230 uses a 30 amp circuit breaker with a short trip delay on each –48V input.

CoolingThe MGX 8230 incorporates a fan tray assembly (with eight fans) located on the left side of the card cage to pull ambient cooling air into the system through openings between front card faceplates, over the boards in the card cage, and out through air exhaust openings on the left side of unit.

Figure 2-10 is an illustration of the MGX 8230 fan tray assembly.

The cooling system incorporates the following design features:

• –48 VDC fans with rotation sensing

• N+1 fan redundancy

• Hot pluggable (if done quickly) Fan Tray Assembly

• Noise level < 65 dBA

The PXMs provide a variety of system environmental monitoring and logging functions. The PXM is capable of reading the speed of these fans to determine if they are operating below the configured threshold. Upon failure of any of the fans, an alarm is generated. The temperature monitor circuit monitors the MGX 8230 shelf air-intake temperature in units of one degree Celsius.



Chapter 2 MechanicalEnvironmental

Figure 2-10 MGX 8230 Fan Tray Assembly

EnvironmentalMGX 8230 environmental specifications are listed as follows.

• Ambient Temperature Range

– In operation +41 to +104°F (+5 to +40°C)

– In short-term operation +35 to +122°F (+1.7 to +50°C) (up to or less than 72 consecutive hours and 15 days in one year)

– In storage -40 to +140°F (-40 to +60°C)

• Relative Humidity Range

– In operation: up to 85%

• Altitude Range

– 200 feet below the mean sea level to 10,000 feet above the mean sea level taking into account the function of temperature and humidity.

• Shock

– Withstands 10 G, 10 ms. at 1/2 sine wave.

• Vibration:

– Withstands 1/4 G, 20 to 500 Hz.

• Maximum Heat Gain

– 5 kw or 17,070 Bus/hour (50% to 75% of this value in typical configurations).

• Minimum Floor Void

1727

4



Chapter 2 MechanicalElectromagnetic Interference

– The minimum clearance requirements are 30 inches front and rear; nominal 12-inch side clearance.

Electromagnetic InterferenceTo maintain correct airflow and to reduce Radio Frequency Interference (RFI) and Electromagnetic Interference (EMI), all unused back card slots must be covered with the blank faceplates provided by Cisco Systems. If a front door option is ordered, there is no need to order or install blank front faceplates.

Front side EMI is obtained by either installing Cisco provided blank cards or by installing an EMI-tight front door, which can be ordered as an option. There will be different faceplates to accommodate double-height and single-height slots.

Card Cage and Midplane ArchitectureThe MGX 8230 chassis has two dedicated slots for the PXM1, eight single-height slots (four double-height slots) for service modules, and two single-height slots for SRMs.

Midplane Functional DescriptionThe MGX 8230 has a midplane design that increases flexibility and minimizes service disruptions by allowing front cards to be replaced without disrupting cabling at the rear of the chassis. In backplane architectures, the design reduces the flexibility to change interfaces and increases the risk of causing accidental operational outages due to cables coming loose when cards are being swapped.

Midplane Key Benefits

The benefits of the midplane design are as follows.

• Operational IssuesAll MGX cards have a modular architecture that includes a front card inserted from the front of the switch and a matching back card inserted from the rear of the switch. Front cards contain all of the intelligence, processor, and switching functions. Back cards contain the physical interfaces and adaptation functions. All cards (both front and back) are hot swappable. In the event of a failure, typically only front cards need to be replaced. All of the cables and card connections can remain intact.

• Interface FlexibilityInterface types can be changed by simply replacing the back card. With Cisco the MGX 8230, the customer can easily and cost-effectively migrate the physical interface type for a particular interface by replacing the back card.

Backplane Components

Components of the backplane include:

• Cell Bus—Eight master cell buses and one slave cell bus connected from each PXM to the midplane.

• Local Bus—To communicate between the PXMs and the SRMs.

• T1/E1 Redundancy Bus—To route the T1/E1 signals from a selected service module's line module to the standby module.



Chapter 2 MechanicalCard Cage and Midplane Architecture

• BERT Bus—To generate and test using a variety of BERT on any specific T1/E1 line or ports.

• Distribution Bus—To distribute T1 or T3 signals to the service modules. It is a poin-to-point connection between the SRM and service module slots. Up to 4 DS3s are routed to the single-height service modules.

Cell Buse Artchitecture

The MGX 8230 architecture is built around the switching fabric on the processor switching module, the backplane, and the service modules.

The main function of the MGX 8230 backplane is to connect cards together, terminate critical signals properly, provide –48 VDC power to all cards, and set ID numbers for each slot. In addition, the MGX 8230 backplane interconnects both front cards and back cards together via pass-through connectors.

The cell bus provides high-speed interface between the switch fabric and the service modules. Figure 2-11 shows the overall cell bus distribution of the backplane.

Each PXM supports eight master cell buses and one slave cell bus connected to the backplane. The service modules have two slave cell bus ports, one from each PXM.

A cell bus is comprised of a group of signals used to transfer data between the PXM and a service module. CB 0, 6, 1, 2, 4, and 3 are dedicated to physical slots 3, 4, 5, and 10, 11, and 12 respectively, which support high-speed service modules. CB5 supports physical slots 6 and 7, and CB7 supports physical slots 13 and 14, as well as the alternate PXM's slave port.

There is a connection on cell bus 7 to the alternate PXM. A PXM is able to communicate with the other PXM using the slave cell bus port on that card. Slots 8 and 9 only refer to back card slots.

Figure 2-11 shows the interconnection of the cell bus lanes on the midplane.

Figure 2-11 MGX 8230 Cell Bus Lane Interconnection

Distribution BusThe MGX 8230 backplane supports the same distribution bus employed in the MGX 8220. This is used in conjunction with the SRM-3T3 to provide M13 circuit breakout and distribution capability as well as T1/E1 1:N service module redundancy (in bulk mode the service modules have 1:N redundancy without using the separate T1 redundancy bus). The distribution system is also augmented with a T3 distribution

1

2

3

4

5

6

7

10

11

12

13

14

CB

0C

B6

CB

1C

B5

CB

2C

B4

CB

3C

B7

PXM

PXM

Left side of chassis Right side of chassis

2627

4

8

9



Chapter 2 MechanicalCard Cage and Midplane Architecture

mechanism, so that a future SRM could break out an OC-12 into DS3 streams, which in turn could be routed to individual DS3 speed service modules. The TDM distribution buses for the upper and lower service bays are independent. In the future, the SRM may also be required to break out traffic to the DS0 level in order to provide more advanced grooming/pooling capabilities.

Service Redundancy BusA redundancy bus supports T1/E1 service module redundancy. The service modules have access to the redundant bus, and the service redundant logic on the SRM is responsible for sending control signals to each service modules to use the redundant bus. This redundancy bus carries traffic from the back card of a failed service module to the front card of an active secondary card module.

Local BusThe local bus is the core card bus that connects the PXM and SRM cards.

BERT BusThe BERT bus is used by the SRM-3T3/C to distribute T1 signals to the service modules. The SRM can support BERT on only one line or port at a time. BERT is capable of generating a variety of test patterns, including all ones, all zeros, alternate one zero, double alternate one zero, 223-1, 220-1, 215-1, 211-1, 29-1, 1 in 8, 1 in 24, DDS1, DDS2, DDS3, DDS4, and DDS5.

The BERT bus is used to provide the BERT operation to the individual service modules. This bus is also used to drive special codes such as fractional T1 loopback codes, and so on, onto the T1 line. The BERT function is initiated on ONLY one logical T1/E1 Nx64K port per MGX 8230 at any given time and this is controlled by the PXM. The SRM-3T3 ensures that the BERT patterns are generated and monitored (if applicable) at the appropriate time slots.

The data path then for that particular port (n x 64K) is from the service module to the SRM-3T3/C (via the BERT bus) and back to the service module (via the BERT bus). On the service module, the data that is transmitted is switched between the regular data and the BERT data at the appropriate timeslots as needed. Similarly in the receive direction, the received data is diverted to the BERT logic for comparison during appropriate time slots.

The BERT logic is self synchronizing to the expected data. It also reports the number of errors for bit error rate calculation purposes.

Caution BERT is a disruptive test. Activation of this test will stop the data flow on all the channels configured on the port under test. BERT testing requires the presence of an SRM-3T3/C card in the service bay where the card under test is located.



Chapter 2 MechanicalCable Management

Cable ManagementThe following cables are required for minimum configuration of one MGX 8230 shelf:

• Fan Cable—This cable connects the fan tray to the midplane, supplies power to the fans, and provides status signals to the PXM.

• AC Cable—On an AC system, power cable connects the AC power supply tray to the midplane to supply redundant 48VDC. AC power-supply status can be monitored by the PXM through these cables.

For systems sold in the United States, the AC power is supplied through standard IEC power cord. Power cords for different countries can be ordered through Cisco.

Additionally, the system also requires the following cables under different configurations.

• DC Cable—For DC systems, the wiring is connected from a 48 VDC power source to one or two DC Power Entry Modules. All wires must be six AWG in size.

• SM Cable—Table 2-5 summarizes the type of interfaces provided by the different service modules.

MGX 8230 Cable Management A fully loaded MGX 8230 may have many cables attached to the rack's modules. Cable management kits are available for installation on the rear of rack modules. These kits provide the means to route the power and data cables in a neat and orderly fashion to and from the modules in the shelf. The cable-management system is shipped with attaching hardware along with your MGX 8230. Install the cable-management brackets after a rack-mounted unit has been installed in a rack, or a standalone MGX 8230 has been positioned.

Figure 2-12 illustrates an installed cable management system. When installing the cable-management system on a rack-mount MGX 8230, the screws securing cable guides to the shelf chassis are inserted from the outside into the captive nuts in the chassis. When installing the cable-management system in a standalone MGX 8230, the screws securing cable guides to the shelf chassis are inserted from the outside to the captive nuts in the chassis.

Table 2-5 Service Module Interfaces

Service Module Interface

8 T1s ports RJ-48 connector

8 E1s ports RJ-48 or SMB connector

T3/E3 ports BNC connector

HSSI ports SCSI-II connector (according to ANSI/TIA/EIA-613)

Ethernet ports RJ-45 connector

Fast Ethernet ports RJ-45 connector

FDDI ports SC connector

PXM1 OC-3 multimode ports SC connector

PXM1 OC-3 single mode ports (IR and LR) SC connector

PXM1 OC-12 single mode ports (IR and LR) SC connector




Figure 2-12 Cable Management Assembly at Back Enclosure

The cable-management system provides the following features:

• Cards can be inserted or removed without disturbing cables attached to cards in adjacent slots.

• Cables can be routed from both above and below the chassis.

• Fiber cables are prevented from bending tighter than allowable radius.

2383

0

C H A P T E R



3Processor Switch Module

OverviewThe Processor Switch Module (PXM1) provides the switching fabric in the MGX 8230 chassis. This PXM1 allows Cisco customers to scale the switch focus and capacity to 1.2 GBps (PXM1). The PXM1 combines the functions of the processor, the switch fabric, and broadband ports into a single module.

The MGX 8230 supports both shared memory and cross-point switching technologies to optimize costs for narrowband requirements. Although the backplane is capable of 45 GBps, the customer can choose to deploy a 1.2 GBps-shared memory fabric (PXM1) to support the narrowband service modules. The PXM1 provides 1.2 GBps of nonblocking bandwidth.

PXM1 Switch Fabric ModuleThe switch fabric (PXM1) provides up to 1.2 GBps of nonblocking ATM switching along with an integrated hard disk for statistical and management features and an ATM multicast engine. Figure 3-1 shows the PXM1 architecture.

Figure 3-1 PXM1 Architecture

Midplane 4303

1

Optional trunkdaughter card

Sharedmemoryswitch

CBC

uP

CBC

PXM UIBack card

PXM UIFront card

PXM UITrunk back card(optional)

Cell buses



Chapter 3 Processor Switch ModulePXM1 Switch Fabric Module

In addition to the switch processor and switch fabric, the PXM1 module also supports three types of trunking daughter cards, reducing the requirement for allocating additional slot positions for trunk modules. The PXM1 trunking daughter cards and associated back cards are intended to provide native ATM interfaces, which can be configured as either trunks or ports, but are cost-optimized for trunking. The PXM1 trunking back cards are available in the following physical interfaces:

• 2-port T3/E3 ATM

• 4-port OC-3c/STM-1 ATM

• 1-port OC-12c/STM-4 ATM

The PXM1 performs the following functions:

• Shelf Management

The PXM1 is responsible for monitoring and controlling the card modules.

• Switches Cells

The PXM1 houses the shared-memory switch that sends and receives ATM cells from the network trunk and service modules.

• Bus Master

All ATM cells created by the service modules are sent to the PXM1 card to be switched to other service modules or the attached ATM network. The PXM1 is responsible for managing the flow of cells on the cell bus.

• Network Management

Network management devices, such as Cisco WAN Manger workstation, PC, and dumb terminal communicate directly with the PXM1

• Stores Service Modules Configuration and Firmware Images

A copy of the configuration database and firmware image for each service module installed is stored on the PXM1 on a PCM-CIA disk drive.

• Shelf Timing

The PXM1 is responsible for extracting a clock signal from either an external clock source or the trunk to the ATM network. The PXM1 propagates the timing signals across the switch’s timing bus.

• Measures Environmental Alarms

Chassis temperature and fan and power supply status are monitored by the PXM1.

• Local Alarm Notification

Local major and minor alarms are reported by the PXM1 via front card LEDs and dry contact relays on the PXM1-UI back card.

The PXM1 and all the inputs (cell bus and trunk interfaces) support configuration for 1:1 hot-standby redundancy. Each PXM1 supports two active back cards, the upper level back card provides the BITS synchronization interfaces and the OAM interfaces while the lower back card provides the trunk interfaces. Both the active and redundant PXM1 are able to access either pair of the PXM1 back cards, which eliminates the necessity of a PXM1 switch-over if either of the back cards should fail. The MGX 8230 midplane supports full OC-12c bandwidth to each trunk back card. The PXM1 trunk back cards also support cross-coupling between trunk interfaces for SONET APS 1+1 redundancy support.

All local connections go through QE0 and each local connection consumes two GLCNs (one for each direction). QE0 supports 32K GLCNs so a total of 16K local connections can be supported in hardware.

From a hardware perspective the PXM1 can support up to 32K connections.




PXM1 Front Card SupportThe following set of functionality is supported on the PXM1 front card:

• +500MB hard drive

• High-speed SAR interface into the fabric

• Cell bus control and arbitration

• Multicast engine

PXM1 Back Card SupportPXM1 back cards provide high-speed (T3, OC-3, OC-12) native ATM interfaces that can be configured as ATM UNI ports or trunks. The interfaces are cost-optimized for trunking. Cross-coupling signals are provided between the lower back cards to allow Automatic Protection Switching (APS). The PXM1 supports two back cards. The upper card supports the following ports and interfaces.

• User and Management Interface

– EIA/TIA-232 control port

– EIA/TIA-232 maintenance port

– 10BaseT Ethernet port

• Network synchronization for the shelf

– T1/E1 BITS synchronization port

– Stratum-4E clocking

– Stratum-3 clocking (optional)

• Central office–compatible major/minor alarm interface

– DB-15 connector

– Major Alarm Audio

– Major Alarm Visual

– Minor Alarm Visual

The lower back card on PXM1 provide one of the following ATM interfaces:

• Two-port T3/E3

• Four-port OC-3c/STM-1

• One-port OC-12/STM-4

The PXM1 back cards provide user accessible interfaces for the uplink trunks and for management and alarm interfaces.

PXM1-UI

The PXM1-UI back card provides user access to the following interfaces:

• Ethernet port

• RS232 maintenance port

• RS232 control port




• T1/E1 timing reference ports

• Audio and visual alarm interface port

PXM-UI-S3 (optional)

The PXM-UI-S3 is an optional card that provides external Stratum 3 clocking. This back card provides user access to the following interfaces:

• Ethernet port

• RS232 Maintenance port

• RS232 Control port

• External T1/E1 timing reference ports

• Audio and visual alarm interface port

Uplink Back Cards

The uplink back cards provide line drivers for the uplink interface. The following interfaces are provided:

• 2 T3 ports, BNC connectors

• 2 E3 ports, BNC connectors

• 4 OC-3 multimode port, SC connectors

• 4 OC-3 single mode intermediate reach ports, SC connectors

• 4 OC-3 single mode long reach ports, SC connectors

• 1 OC-12 single mode intermediate reach port, SC connectors

• 1 OC-12 single mode long reach port, SC connectors

A mismatch between the uplink back card type and the PXM1 will generate a major alarm.

Table 3-1 lists the PXM1 modules. Table 3-2 provides the interface characteristics.

Table 3-1 Cisco MGX 8230 Processor Switch Modules

PXM1 Front Card

PXM1-2-T3E3 T3/E3 ports

PXM1-4-155 4 155 Mbps ports

PXM1-622 1 622 Mbps port

PXM1-UI PXM1 user interface BC-PXM1

PXM-UI-S3 PXM1 user interface BC-Stratum 3, PXM1, PXM45

MGX-BNC-2E3 2-port E3 back card, BNC connectors

MGX-BNC-2T3 2-port T3 back card, BNC connectors

MGX-MMF-4-155 4-port 155 Mbps back card, MMF, SC connectors

MGX-SMFIR-4-155 4-port 155 Mbps back card, SMF-IR, SC connectors

MGX-SMFLR-4-155 4-port 155 Mbps back card, SMF-LR, SC connectors




Bandwidth The PXM1 provides 1.2 GBps of nonblocking bandwidth.

Cell Bus AccessThe cell bus is a Poll-Request-Grant bus. The polling algorithm is based on round-robin servicing. The granting is based on a programmable rate factor for the device. For example, if a device (service module) has been guaranteed 45 Mbps bandwidth, whenever the grant rate of that device falls below the rate, the priority of the device will be increased until minimum rate is guaranteed.

The eight cell buses are grouped into two groups. Excess bandwidth is proportionally shared among all devices within the same group.

When the cell buses are running at double speed, each cell bus is guaranteed 160 Mbps bandwidth. The excess bandwidth is shared proportionally among all devices within the same group. Therefore it is important that one does not attempt to set the total guaranteed bandwidth for either the left side or right side of the chassis to be more than 640 Mbps.

MGX-SMFIR-1-622 1 port 622-Mbps back card, SMF-IR, FC connectors

MGX-SMFLR-1-622 1 port 622-Mbps back card, SMF-LR, FC connectors

Table 3-2 Interface Physical Characteristics

Characteristic T3 (DS3) E3 (34 Mbps)

Line Rate 44.736 Mbps, 20 ppm 34.368 Mbps, 20 ppm

Line Code B3ZS HDB3

Cell Transfer Rate 96,000 cells/sec 80,000 cells/sec

Framing ANSI T1.107, T1.107a ITU-T G.804, G.832

Signal Level TA-TSY-00077

TA-TSY-000773

TA-TSY-000772

ITU-T-G.703

Connector Locking Locking

Cell Mapping PLLP, Direct PLLP, Direct

Table 3-1 Cisco MGX 8230 Processor Switch Modules (continued)




Processor (IDT 4700)The IDT 4700 processor module provides the following basic features:

• Clock Speed – 200 MHz internal, 50 MHz external

• Flash—2 MB

• DRAM—28 MB

• Secondary Cache—512 KB

• BRAM—128 KB

Clocking OptionsThe PXM1 supports a minimum of two external timing references on separate physical interfaces. These are provisioned as the active (act) and alternate (alt). The terms act and alt are interchangeable depending on which reference is active, and providing timing reference for the system. The system also provides a DS1 reference for external timing in D4 (SF) format. At least two DS1 synchronization references, as specified in Bellcore GR-1244-CORE, Section 3.4, can be configured.

A switchover from the active clock source (primary or secondary) to the standby clock source will occur when the hardware detects a failure that warrants a switchover. The currently selected clock source is constantly monitored by the hardware to ensure that it is within tolerance.

If a failure in this selected clock is detected, the hardware gracefully switches over to the secondary clock source specified.

If both the primary and secondary sources have failed, the hardware will automatically output the clock generated internally on the card. Once the primary clock is within tolerance, the hardware will automatically switch back to it.

Regardless of whether the clock switchover is initiated by the user or by the hardware, the switchover meets the Accunet T1.5 Maximum Time Interval Error (MTIE) specification.

When all timing references fail, as specified in Bellcore GR-1244-CORE, Section 3.4.1, the MGX 8230 can operate in self-timing, or free-running mode, using an internal clock.

InterfacesThe user interface back card features are as follows.

• Resides in the upper service bay

• Interfaces supported

– T1/E1 timing reference ports

– Maintenance port

– Control port

– Ethernet interface

– Audio and visual alarm interface ports

• Y-Cable support available




System Environment MonitoringThe following system environmental parameters are monitored and logged by the PXM1:

• 48 VAC power supply status

• 5V and 3.3V on-board power status

• Cooling fan revolution

• Enclosure temperature

Minor and major alarms will be generated when one or more environmental parameters are out of range.

Alarm Circuit and IndicatorsPXM1 provides connectors for external audio and visual alarms. The PXM1 monitors ACO and History push-buttons located in its front card faceplate. It controls the following LEDs, which are also located on the PXM1 front card faceplate:

• Card

– Active (green)

– Standby (yellow)

– Fail (red)

• LAN activity

– Flashing green

• Node alarm

– Major alarm (red)

– Minor alarm (yellow)

• Node Power Supply

– DC OK A (green/red)

– DC OK B (green/red)

• Alarm History

– ACO

– History

• Port Interface (per port):

– Active and OK (green)

– Active and local alarm (red)

– Active and remote alarm (yellow)

– Inactive (no light)

Figure 3-2 shows the PXM1 LEDs.




Figure 3-2 PXM1 LEDs

PXM1 provides three types of nonvolatile storage:

• Flash—This is used to store boot code for the processor. The boot code can be upgraded in the field by a software download.

• Hard drive—The PXM1 hard drive is a 2.5 inch, 2.2 GB IDE drive. Configuration information and code for the PXM1 and service modules are stored on the drive, and can be updated during system operation or by user download.

• Battery backed up RAM—The BRAM is used to store book keeping information for the card. Information stored includes:

– Identifiers such as board hardware revision, serial number, and PCB part number

– MAC address of the PXM1

– Hard drive parameters such as number of heads and cylinder size

The BRAM also acts as a temporary cache. If for any reason the hard drive fails, log information immediately before the failure can be stored in the BRAM for further analysis.

1143

9




Optical InterfacesAs the optical transceivers in the PXM1 interfaces are ITU-T G.957 compiant, G.957 dispersion tolerances are:

• STM-1 Intermediate Reach (S-1.1)

Maximum dispersion in the optical path is 96 ps/nm

• STM-1 Long Reach (L-1.1)


• STM-4 Intermediate Reach (S-4.1)


• STM-4 Long Reach (L-4.1)


The modulation used in all PXM1 optics is direct built-in electroabsortion modulator in standard temperature range (0–70°C). The type of laser sources for the different PXM1 interfaces are


• OC-3 LR: Fabry-Perot


• OC-12 LR: DFB

Physical Layer T3/E3 InterfaceThe T3/E3 interface provides

• Two T3/E3 ports

• Compliance with ATM Forum UNI Specification Versions 3.0 and 3.1

• 1:1 PXM1 redundancy

• Both PLCP and HEC direct mapping for T3; HEC direct mapping for E3

Physical Layer OC-3c/STM-1 InterfaceThe OC-3c/STM-1 interface provides

• Four OC-3c/STM-1 (155.520 Mbps) ports

• Trunk or port interface mode

• Cell transfer rate of 353,208 cells per second

• Compliance with SONET standards (Bellcore GR-253-CORE and ANSI T1.105)

• Compliance with SDH standards (ITU-T G.707, G.708, G.709, G.957, and G.958)


• SONET APS

• Linear APS




Physical Layer OC-12c/STM-4 InterfaceThe OC-12c/STM-4 interface provides:

• One OC-12c/STM-4 (622.08 Mbps) port

• Cell transfer rate of 1,412,832 cells per second

• Compliance with SONET standards (Bellcore GR-253-CORE, TR-TSY-000020, ANSI T1.105)

• Compliance with SDH standards (ITU-T G.707, G.708, G.709, G.957, G.958)


• SONET APS

ATM LayerThe ATM layer is configurable for trunk and public or private UNI applications. It is conformant to ATM Forum UNI Specification V3.0, 3.1, ITU-T I.361 and I.432 specifications, and it supports virtual circuit connections (VCCs) and virtual path connections (VPCs) per ATM Forum UNI Specification V3.1 and ITU-T I.371.

C H A P T E R



4Service Modules

The MGX 8230 switch supports Frame Relay, CE, ATM, Cisco IOS (including IP services), and voice services through an array of service modules.

This chapter includes a summary of the available modules, followed by detailed information on the modules and the services they provide:

• Summary of Modules, page 4-1.

• Frame Relay Services, page 4-4.

• Circuit Emulation Services, page 4-7.

• ATM Service, page 4-12.

• Voice Service—VISM, page 4-16.

• Service Resource Module, page 4-23.

• ATM Deluxe Integrated Port Adapter/Interface, page 4-33

Summary of ModulesThe MGX 8230 supports the following service modules.

Service Resource Module (SRM)

Service Resource Module (MGX-SRM-3T3/C)The optional SRM provides three major functions for service modules; bit error rate tester (BERT) of T1 and E1 lines and ports, loops back of individual N x 64 channels toward the customer premises equipment (CPE), and 1:N redundancy for the service modules.

Frame Relay Service Modules (FRSM)

A variety of Frame Service Modules are supported as described in the following list.

• Frame Service Module for eight T1 ports (AX-FRSM-8T1)The AX-FRSM-8T1 provides interfaces for up to eight fractional T1 lines, each of which can support one 56 kbps or one Nx64 kbps FR-UNI, FR-NNI port, ATM-FUNI, or a Frame forwarding port. The AX-FRSM-8T1 supports fractional and unchannelized T1 port selection on a per-T1 basis.



Chapter 4 Service ModulesSummary of Modules

• Frame Service Module for eight E1 ports (AX-FRSM-8E1)The AX-FRSM-8E1 provides interfaces for up to eight fractional E1 lines, each of which can support one 56 kbps or one Nx64 kbps FR-UNI, FR-NNI, ATM-FUNI, or Frame forwarding port. The AX-FRSM-8E1 supports fractional and unchannelized E1 port selection on a per-E1 basis.

• Frame Service Module for eight channelized T1 ports (AX-FRSM-8T1-C)The AX-FRSM-8T1-C allows full DS0 and n x DS0 channelization of the T1s. Each interface is configurable as up to 24 ports running at full line rate, at 56 or n x 64 kbps for a maximum of 192 ports per FRSM-8T1-C.

• Frame Service Module for eight channelized E1 ports (AX-FRSM-8E1-C)The AX-FRSM-8E1-C allows full DS0 and n x DS0 channelization of the E1s. Each interface is configurable as up to 31 ports running at full line rate, at 56 or n x 64 kbps for a maximum of 248 ports per FRSM-8E1-C.

• Frame Service Module for T3 and E3 (MGX-FRSM-2E3T3)The MGX-FRSM-2E3/T3 provides interfaces for two T3 or E3 Frame Relay lines, each of which can support either two T3 lines (each at 44.736 Mbps) or two E3 lines (each at 34.368Mbps) FR-UNI, ATM-FUNI, or Frame Forwarding port.

• Frame Service Module for channelized T3 (MGX-FRSM-2CT3)The MGX-FRSM-2CT3 supports interfaces for two T3 channelized Frame Relay lines. Each interface supports 56 Kbps, 64 Kbps, Nx56 Kbps, Nx64 Kbps, T1 ports that can be freely distributed across the two T3 lines.

• Frame Service Module for high speed serial (MGX-FRSM-HS1/B)The FRSM-HS1/B supports the 12-in-1 back card. This back card supports up to four V.35 or X.25 serial interfaces. This card also supports the two port HSSI back cards with SCSI-2 connectors.

• Frame Service Module for unchannelized HSSI (MGX-FRSM-HS2/B)The MGX-FRSM-HS2/B supports interfaces for two unchannelized HSSI lines. Each interface supports approximately 51 Mbps; with both lines operating, maximum throughput is 70 Mbps.

ATM UNI Service Modules (AUSM)

Two ATM UNI Service Modules are supported.

• ATM UNI Service Module for T1 (MGX-AUSM/B-8T1)The MGX-AUSM/B-8T1 provides interfaces for up to eight T1 lines. You can group N x T1 lines to form a single, logical interface (IMA).

• ATM UNI Service Module for E1 (MGX-AUSM/B-8E1)The MGX-AUSM/B-8E1 provides interfaces for up to eight E1 lines. You can group N x T1 lines to form a single, logical interface (IMA).

Circuit Emulation Service Modules (CESM)

Three Circuit Emulation Service Modules are supported.

• Circuit Emulation Service Module for T1 (AX-CESM-8T1)The AX-CESM-8T1 provides interfaces for up to eight T1 lines, each of which is a 1.544 Mbps structured or unstructured synchronous data stream.

• Circuit Emulation Service Module for E1 (AX-CESM-8E1)The AX-CESM-8E1 provides interfaces for up to eight E1 lines, each of which is a 2.048-Mbps structured or unstructured synchronous data stream.



Chapter 4 Service ModulesSummary of Modules

• Circuit Emulation Service Module for T3 and E3 (MGX-CESM-T3/E3)The MGX-CESM-T3E3 provides direct connectivity to one T3 or E3 line for full-duplex communications at the DS3 rate of 44.736 MHz or at the E3 rate of 34.368 MHz. Each T3 or E3 line consists of a pair of 75-ohm BNC coaxial connectors, one for transmit data and one for receive data, along with three LED indicators for line status.

Voice Service Modules (VISM)

MGX-VISM-8T1 and MGX-VISM-8E1These cards support eight T1 or E1ports for transporting digitized voice signals across a packet network. The VISM provides toll-quality voice, fax and modem transmission and efficient utilization of wide-area bandwidth through industry standard implementations of echo cancellation, voice-compression and silence- suppression techniques.

Note For configuration information on the Voice Interworking Service Module (VISM), refer to the Voice Interworking Service Module Installation and Configuration.

Route Processor Module (RPM)

Route Processor Module (RPM)The RPM is a Cisco 7200 series router redesigned as a double-height card. Each RPM uses two single-height back cards. The back card types are single-port Fast Ethernet, four-port Ethernet, and single-port (FDDI).

Note For information on availability and support of the MGX-RPM-128/B and MGX-RPM-PR, see the Release Notes for Cisco WAN MGX 8850, 8230, and 8250 Software.

Note For configuration information on the Route Processor Module (RPM), see the Cisco MGX Route Processor Module Installation and Configuration.



Chapter 4 Service ModulesFrame Relay Services

Frame Relay ServicesThe primary function of the Frame Relay Service Modules (FRSM) is to convert between the Frame Relay formatted data and ATM/AAL5 cell-formatted data. For an individual connection, you can configure network interworking (NIW), service interworking (SIW), ATM-to-Frame Relay UNI (FUNI), or frame forwarding.

Summary of FRSM Features By Module VersionTable 4-1 summarizes the basic features of the Frame Relay service modules for the MGX 8230.

Table 4-1 Frame Relay Card Summary Information

Front Card FRSM-8T1 FRSM-8T1-C FRSM-8E1 FRSM-8E1-C FRSM-2T3E3 FRSM-2CT3 FRSM-HS1/B FRSM-HS2

Physical interface

T1 T1 E1 E1 T3, E3 T3 V.35 and X21

HSSI

Number of ports

8 fractional, unchannel-ized

8 channel-ized

8 channel-ized

8 channel-ized

2 unchan-nelized DS3 or E3

2 (DS1/nxDS0 channelized DS3 with 28 channel-ized T1lines per T3, for support of up to 256 logical ports)

4 2

Port speed 1.544 Mbps n x 64 Kbps 2.048 Mbps nx64Mbps (E1-C)

45 Mbps (T3)

34 Mbps (E3)

1.544 Mbps, n x 64 kbps

Up to 8 Mbps

Up to 52 Mbps

Physical lines

8 8 8 8 2 2 4 V.35 or X.21

2 HSSI

variable line speeds

Logical ports

8 max 192 max (24*8)

8 max 248 max (31*8)

2 max 256 max 4 (V.35 or X.21)

2 max

Maximum connections

1000 1000 1000 1000 2000 4000 200 2000

Line codings

B8ZS/AMI B8ZS/AMI HDB3/AMI HDB3/AMI B3ZS, HDB3

B3ZS, HDB3

– –

BERT Yes, via SRM

Yes, via SRM

Yes, via SRM

Yes, via SRM

Yes, on-board T3 BERT

Yes, via SRM

No No




Features Common to All FRSMsThe features supported by all FRSM cards are

• Frame Relay UNI and NNI—Offers standards-compliant Frame Relay UNI and NNI on a variety of physical interfaces that support congestion notification (FECN/BECN), ForeSight (optional), bundled connections, frame forwarding, extended traffic management to the router, ELMI, and enhanced loopback tests.

• Frame-Relay-to-ATM Network Interworking as Defined in FRF.5—The MGX 8230 switch supports a standards-based interworking that segments and maps variable-length Frame Relay frames into ATM cells in both transparent and translational modes. This interworking enables transparent connectivity between large ATM and small Frame Relay locations independently of the WAN protocol.

• Frame-Relay-to-ATM Service Interworking—The modules provide Frame-Relay-to-ATM service interworking (FRF.8), both transparent and translation modes, configured on a per-PVC basis.

• Frame Forwarding—The MGX 8230 Frame Relay modules enable efficient transport of frame-based protocols, such as SDLC, X.25, or any other HDLC-based protocol, over Frame Relay interfaces. Application examples include routers interconnected via PPP, mainframes or hosts connected by X.25/HDLC, SNA/SDLC links, and video CODECs that use a frame-based protocol.

• ATM FUNI—ATM Forum FUNI mode 1A is supported. Interpreted CCITT-16 CRC at the end of the frame enables frame discard if in error. The service modules also support AAL5 mapping of user payloads to ATM, 16 VPI values, virtual path connections for all nonzero VPI values (up to 15 VPCs), 64 VCI values, and OAM frame/cell flows.

• Dual Leaky Bucket Policing—(Standards-based CIR policing and DE tagging/discarding) Once basic parameters such as committed burst, excess burst, and CIR have been agreed to, incoming frames are placed in two buckets: those to be checked for compliance with the committed burst rate and those to be checked for compliance with the excess burst rate. Frames that overflow the first bucket are placed in the second bucket. The buckets “leak” by a certain amount to allow for policing without disruption or delay of service.

• ForeSight—The Foresight congestion management and bandwidth optimization mechanism continuously monitors the utilization of ATM trunks and adjusts the bandwidth to all connections, proactively avoiding queuing delays and cell discards.

Frame Relay Service Module Special Features The following special features are supported by all FRSM cards:

• Support for Initial Burst Size (IBS)—Supported on a per-VC basis to favor connections that have silent for a long time.

Redundancy

1:N 1:N 1:N 1:N 1:1 1:1 1:1 1:1

Power Con-sumption

29.30W 29.30W 29.30W 29.30W 45.25W 49.2W 35.00W 56.56W

Table 4-1 Frame Relay Card Summary Information (continued)

Front Card FRSM-8T1 FRSM-8T1-C FRSM-8E1 FRSM-8E1-C FRSM-2T3E3 FRSM-2CT3 FRSM-HS1/B FRSM-HS2




• Extended ForeSight—Extended ForeSight uses standards-based consolidated link-layer management (CCLM) messages to pass ForeSight congestion indications across Frame Relay UNI and NNI service interfaces. Extended ForeSight provides a powerful means for extending the range of ForeSight flow control beyond the network boundaries of a single carrier.

• Consolidated Link Layer Management (CLLM)—An out-of-band mechanism to transport congestion-related information to the far end. Consolidated Link Layer Management (CLLM; T1.618) is an industry-standard protocol. Its PVC congestion notification portion of the CLLM protocol is implemented by Cisco. CLLM is not part of the UNI or NNI signaling protocol and uses a different reserved DLCI. CLLM effectively extends congestion notification to external upstream equipment. CLLM does not support the type of granularity that ForeSight provides (rate down, rate fast down, and so on); it can only send congestion notification messages of congestion or no congestion.

• Enhanced LMI (ELMI)—Cisco LMI, ANSI T1.617 Annex D and ITU-T Q.933 Annex A are supported on the FRSMs. In these specifications, there is no way for the network (switches) to inform a user (access device, FRAD, router) about various Quality of Service parameters for Permanent Virtual Circuits (PVCs) like Committed Information Rate (CIR), Committed Burst Size (Bc), Excess Burst Size (Be), Maximum Frame Size, and so on. Thus, once a connection is provisioned within the switching network, this information must again be input when the connection is provisioned in the router. This makes provisioning susceptible to manual errors, needlessly making troubleshooting more complex.

• Having the correct information about these parameters is valuable for routers that are capable of making congestion management/prioritization decisions. Cisco enhanced its Frame Relay capability by using CIR, Be, and Bc values for traffic shaping. Currently, all of these values need to be manually configured by the user and these can be inadvertently be set differently from what the network (service provider) has established. To ease router configuration and ensure consistency with the network a mechanism to provide this information is required. The Enhanced LMI (E-LMI) feature in the Frame Relay interfaces on Cisco routers and wide area switches enables this.

• Advanced Buffer Management—When a frame is received, the depth of the per-VC queue for that LCN is compared against the peak queue depth scaled down by a specified factor. The scale-down factor depends on the amount of congestion in the free buffer pool. As the free buffer pool begins to empty, the scale-down factor is increased, preventing an excessive number of buffers from being held up by any single LCN.

• OAM (Operation, Administration and Management) Features—OAM F5 AIS, RAI and end-to-end/segment loopback supported. Also includes support for the following commands: tstcon, tstdelay, tstconi, tstdelayi.

• Standards-Based Management Tools—FRSMs support SNMP, TFTP (for configuration/statistics collection), and a command-line interface. WAN Manager technology provides full graphical user interface support for connection management. CiscoView provides equipment management, MGX 8230 network management functions. These include image download, configuration upload, statistics, telnet, UI, SNMP, trap, and MGX 8230 switch MIB maintenance.



Chapter 4 Service ModulesCircuit Emulation Services

Circuit Emulation ServicesThe CE service module (CESM) use a standards-based adaptation of circuit interfaces onto ATM.

CE Service ModulesTable 4-2 summarizes the key attributes of the CE service modules.

CESM-8T1/E1 FeaturesThe CESM-8T1/E1 features are listed below.

• Provides up to 8 T1/E1 interfaces.

• Allows structured (SDT) or unstructured (UDT) data transfer per physical interface.

• Provides N x 64 Kbps fractional DS1/E1 service (SDT only). In Structured Data Transfer Mode, the CESM supports fractional DS1/E1 service (time slots must be contiguous). Any N x 64 channels can be mapped to any VC. Therefore, multiple ports can be defined that are composed of unique contiguous timeslots and a connection is used to emulate the data for that logical port.

• Supports synchronous timing in both Structured Data Transfer (SDT) mode and Unstructured Data Transfer (UDT) mode. Synchronous timing is derived from the switch.

• Supports asynch timing mode with Synchronous Residual Time Stamp (SRTS) and adaptive clock recovery methods (UDT only) can be employed for asynchronous timing.

• Provides ON/OFF hook detection and idle suppression using channel-associated signaling (CAS). Only available in SDT mode.

• Allows a choice of partially filled AAL1 cell payload to improve cell delay.

– Type Fill Range (bytes)

– T1 Structured: 25–47

– T1 Unstructured: 33–47

– E1 Structured: 20–47

– E1 Unstructured: 33–47

• Provides a maximum number of connections: 192 T1 and 248 E1.

Table 4-2 CE Service Module Specifications

Feature CESM-8T1/E1 CESM-T3/E3

Service Type Structured/Unstructured Unstructured only

Clocking Sync/Async (SRTS/Adap) Sync only

Idle Supp Yes No

Partial fill Yes No

Onboard BERT No Yes, with DS2172 BERT chip

Redundancy 1:N 1:1

H/W Same board with different device options for T1 and E1

Same board and devices for T3 and E3




CESM-8T1/E1 Peak Cell Rate Calculation

The following features are shared by all CE service modules:

• Partial Fill Value (K bytes)

• SDT Timeslots (N channels)

• Unstructured T1 cell rate

– (1.544 x 106 bps)/(K octets/cell x 8 bits/octet)

– 4107 cps (for K = 47 bytes)

• Unstructured E1 cell rate

– (2.048 x 106 bps)/(K octets/cell x 8 bits/octet)

– 5447 cps (for K=47 bytes)

• Structured N x 64 cell rate, basic mode

– (8000 x N) / (K octets/cell)

– 170 cps (for K = 47, and N = 1) feature specific to CESM 8T1/8E1—Structured Data Transfer

T1/E1 Clocking Mechanism

The CESM card provides the choice of physical interface Tx clock from one of the following sources, (see Figure 4-1):

1. Loop clocking derived from Rx line clock.

2. MGX local switch clock derived on the PXM1 (Synchronous).

3. SRTS and Adaptive based clock (for T1/E1 unstructured asynchronous mode only).

Figure 4-1 T1/E1 Clocking Mechanisms

Tx line clock

Rx line clock

T1/E1 clocking mechanisms

1) Loop

Local

2) PXM 8KHz

4305

1

3) Async (SRTS/Adap)




Asynchronous Clocking (SRTS)

Synchronous Residual Time Stamp (SRTS) clocking requires a Primary Reference Source (PRS) and network clock synchronization services. This mode allows user equipment at the edges of an ATM network to use a clocking signal that is different (and completely independent) from the clocking signal being used in the ATM network. However, SRTS clocking can only be used for unstructured (clear channel) CES services.

For example, in Figure 4-2, user equipment at the edges of the network can be driven by clock B, while the devices within the ATM network are being driven by clock A. The user-end device introduces traffic into the ATM network according to clock B. The CESM segments the CBR bit stream into ATM cells; it measures the difference between user clock B, which drives it, and network clock A. This delta value is incorporated into every eighth cell. As the destination CESM receives the cells, the card not only reassembles the ATM cells into the original CBR bit stream, but also reconciles the user clock B timing signal from the delta value. Thus, during SRTS clocking, CBR traffic is synchronized between the ingress side of the CES circuit and the egress side of the circuit according to user clock signal B, while the ATM network continues to function according to clock A.

Figure 4-2 Asynchronous Clocking

Asychronous Clocking (Adaptive)

Adaptive clocking requires neither the network clock synchronization services nor a global PRS for effective handling of CBR traffic. Rather than using a clocking signal to convey CBR traffic through an ATM network, adaptive clocking infers appropriate timing for data transport by calculating an average data rate for the CBR traffic. However, as in the case with SRTS clocking, adaptive clocking can be used only for unstructured (clear channel) CES services. (See Figure 4-3).

For example, if CBR data is arriving at a CES module at a rate of X bits per second, then that rate is used, in effect, to govern the flow of the CBR data through the network. What happens behind the scenes, however, is that the CES module automatically calculates the average data rate. This calculation occurs dynamically as user data traverses the network.

CESM

Asynchronous clocking - SRTS

4305

2

Stratum 1 server

Edge equipment clock B

ATM cloudclock A

Network clock

clock time stampwith data

Rx clock Tx clock

CESM

PLL PLL

Tx




When the CES module senses that its segmentation and reassembly (SAR) buffer is filling up, it increases the rate of the (TX) clock for its output port, thereby draining the buffer at a rate that is consistent with the rate of data arrival.

Similarly, the CES module slows down the transmit clock of its output port if it senses that the buffer is being drained faster than the CBR data is being received. Adaptive clocking attempts to minimize wide excursions in SAR buffer loading, while at the same time providing an effective means of propagating CBR traffic through the network.

Relative to other clocking modes, implementing adaptive clocking is simple and straightforward. It does not require network clock synchronization services, a PRS, or the advance planning typically associated with developing a logical network timing map. However, adaptive clocking does not support structured CES services, and it exhibits relatively high wander characteristics.

Figure 4-3 Asychronous Clocking (Adaptive)

CESM Idle Suppression

The CESM T1/E1 card in structured mode can interprets CAS robbed bit signaling for T1 (ABCD for ESF and AB for SF frames) and CAS for E1 (timeslot 16). The ABCD code is user configurable per VC (xcnfchan onhkcd = 0-15; ABCD = 0000 = 0 … ABCD = 1111 = 15). By detecting on-hook/off-hook states, AAL1 cell transmission is suppressed for the idle channel; thereby reducing backbone bandwidth consumed. ON/OFF hook detection/suppression can be enabled/disabled per VC and ON/OFF hook states can be forced via SNMP through the NMS.

On the ingress end, the CESM card monitors the signaling bits of the AAL1 cell. Whenever a particular connection goes on-hook and off-hook, the CESM card senses this condition by comparing ABCD bits in the cell with pre programmed idle ABCD code for that channel.

When an on-hook state is detected, keep-alive cells are sent once every second to the far-end CESM. This prevents the far end from reporting an under-run trap during idle suppression, since no cells are transmitted. When the timeslot switches to off-hook mode, the CESM stops sending the keep-alive cells.

CESM

Asynchronous clocking - adaptive

4305

3

Stratum 1 server

ATM cloud

Clock +

Buffer depth

Incoming data

Clock –

CESM

PLL

Tx

Tx

Tx Clk




CESM-T3/E3 Specific FeaturesThe specific features for the CESM-T3/E3 are

• Unstructured Support—Supports T3/E3 unstructured data transfer.

• Synchronous clocking—Synchronous timing mode only supported. Must derive clock from shelf.

• Onboard BERT—BERT support using on board BERT controller. Bert commands executed on T3/E3 card.

• Maximum number of connections—Maximum number of connections is one. In the unstructured mode, one logical port is used to represent the T3/E3 line and one connection is added to the port to emulate the circuit.

CESM-T3/E3 Peak Cell Rate Calculation

The CESM-T3/E3 peak cell rate calculations are as follows:

• T3/E3 only supports unstructured mode and no partial fill

– Unstructured T3 cell rate

– (44.736 x 106 bps)/(47 octets/cell x 8 bits/octet)

– 118980 cps

• Unstructured E3 cell rate

– (34.368 x 106 bps)/(47 octets/cell x 8 bits/octet)

– 91405 cps

T3/E3 Clocking Mechanisms

The T3/E3 clock configuration is shown in Figure 4-4.

Figure 4-4 T3/E3 Clocking Mechanisms

The CESM card provides the choice of physical interface Tx clock from one of the following sources:

1. Loop clocking derived from Rx Line Clock.

2. MGX local switch clock derived on the PXM1 (Synchronous).

Tx line clock

Rx line clock

T1/E1 clocking mechanisms

1) Loop

Local 2) PXM 8KHz

4305

4



Chapter 4 Service ModulesATM Service

ATM ServiceThe ATM UNI Service Modules (AUSM/Bs) provide native ATM UNI (compliant with ATM Forum Version3.0 and Version3.1) interfaces at T1 and E1 speeds, with eight ports per card, providing up to 16 Mbps of bandwidth for ATM service interfaces.

Consistent with Cisco's Intelligent QoS Management features, AUSM/B cards support per-VC queuing on ingress and multiple Class-of-Service queues on egress. AUSM/B cards fully support continuous bit rate (CBR), variable bit rate (VBR), unspecified bit rate (UBR), and available bit rate (ABR) service classes.

The AUSM/B-8 cards also support ATM Forum–compliant inverse multiplexing for ATM (IMA). This capability enables multiple T1 or E1 lines to be grouped into a single high-speed ATM port. This N x T1 and N x E1 capability fills the gap between T1/E1 and T3/E3, providing bandwidth up to 12 Mbps (N x T1) or 16 Mbps (N x E1) without requiring a T3/E3 circuit.

A single AUSM/B card can provide hot-standby redundancy for all active AUSM/B cards of the same type in the shelf (1:N redundancy).

AUSM/B modules are supported by standards-based management tools, including SNMP, TFTP (for configuration and statistics collection), and a command line interface. The Cisco WAN Manager application suite also provides full graphical user interface support for connection management, and CiscoView software provides equipment management.

Table 4-3 summarizes the key attributes of the AUSM/B cards.

Table 4-3 AUSM/B Card Specifications

Feature AUSM/B AUSM/B

Physical interface E1 T1

Number of ports 8 8

Line speed 2.048 Mbps ± 50 bps 1.544 Mbps ± 50 bps

Logical ports 8 maximum 8 maximum

Maximum connections 1000 1000

Line coding HDB3AMI

B8ZSAMI

BERT Yes Yes

Loopback Loop-up, loop-down pattern generation and verification

Loop-up, loop-down pattern generation and verification

Redundancy 1:N 1:N

Back cards RJ48-8E1

R-RJ48-8E1

RJ48-8T1

R-RJ48-8T1




AUSM/B Key FeaturesThe key features of the AUSM/B card are as follows.

• E1 ATM UNI or NNI—The ATM ports on the AUSM/B card can be configured to accept either the User-Network Interface (UNI) or Network-Node (NNI) cell header formats.

• ATM Forum–compliant IMA—The AUSM/B-8 cards also support ATM Forum-compliant inverse multiplexing for ATM (IMA1.0). This capability enables multiple T1 or E1 lines to be grouped into a single high-speed ATM port. Multiple IMA groups up to a maximum of eight supported per module.

• Policing—The AUSM/B checks for conformance of per-connection traffic contract from CPE. For variable bit rate (VBR) and available bit rate (ABR) connections, peak cell rate (PCR) and sustained cell rate (SCR) are policed. For unspecified bit rate (UBR) and constant bit rate (CBR) connections, only PCR is policed.

• Ingress per-VC Queuing—Each VC is buffered in separate queues with configurable threshold values for cell loss priority (CLP), explicit forward congestion indicator (EFCI), and early packet discard (EPD).

• Cell and Frame-Based Traffic Control—The CLP discard capability allows to selectively discard CLP = 1 cells in case of congestion.

– Early Packet Discard—EPD, the discard of a data frame if queue length exceeds set thresholds.

– Partial Packet Discard—PPD, the cell-discard mechanism when part of a frame is discarded due to buffer unavailability, are both supported.

– EFCI bit is set of the queue length exceeds set threshold.

• Egress per COS Queuing—Cell traffic buffered in multiple Class of Service Queues (CBR, VBR, ABR, UBR) per port on Egress with configurable CLP and EFCI threshold values.

• ABR ForeSight—Prestandard ABR closed-loop congestion mechanism used to predict and adjust network traffic to avoid congestion.

• Connection admission control (CAC)—A means of determining whether a connection request will be accepted or rejected based on the bandwidth available.

• ILMI, OAM Cells—The Integrated Local Management Interface (ILMI) signaling protocol can be configured on the AUSM/B on a per-port basis. OAM cell support for monitoring end-to-end AIS and RDI. Used to generate and monitor segment loopback flows for VPCs and VCCs.

• System clock extraction—The Model B AUSM/B in the MGX 8230 has the added capability of extracting clocking from the T1/E1 line to feed into the system clock. The MGX 8220 using a Model B AUSM/B will not support this feature.

• 1:N Redundancy—Within a group of N+1 AUSM/B cards of the same type on a shelf (with optional SRM).

AUSM/B PortsOn the AUSM/B card, the term “port” is used to collectively refer to two types of logical interfaces: ATM T1/E1 ports and IMA groups. ATM ports are defined on a T1 or E1 line and one port is mapped to one line. IMA groups are composed of a logical grouping of lines defined by the user.




In total, the AUSM/B-8T1/E1 can support a maximum of eight logical ports (see Figure 4-5), of which some can be ATM T1/E1 ports and some can be IMA ports. An ATM T1/E1 port numbered i precludes the possibility of an IMA port numbered i. These logical port numbers are assigned by the user as part of configuration. The term IMA group and IMA port will be used synonymously.

The bandwidth of the logical port or IMA group is equal to:

(number of links) * (T1/E1 speed - overhead of IMA protocol)

Figure 4-5 AUSM/B Ports

AUSM/B-IMAIMA offers the user a smooth migration from T1/E1 bandwidth to n * T1/E1 bandwidth without having to use a T3/E3. Multiple T1/E1 lines form a logical pipe called the IMA group.

The IMA group is based on cell-based inverse multiplexing, whereby the stream of incoming cells are distributed over multiple T1/E1 lines (sometimes referred to as links) on a per-cell basis in a cyclic round-robin manner (see Figure 4-6). On the far end, the cells are recombined and the original stream is recreated. From the perspective of the application and the rest of the network, the inverse multiplexing function is transparent and the IMA group is viewed as any other logical port.

T1/E1 lines routed through different path (different carrier) are supported within the same IMA group. The ingress end compensates for the differential delay among individual links in an IMA group.

The maximum link differential delay is 275msec for T1 and 200 for E1.

Within an IMA group, each line is monitored and lines with persistent errors are taken out of data round-robin. The link is activated again when it is clear of errors at both ends.

The connectivity test procedure allows the detection of mis-connectivity of links. A test pattern is sent on one link of the IMA group. The Far End (FE) IMA group loops back the test pattern on all links in the group.

4306

1

IMACPE

ATMT1/E1

AUSM8T1/E1

ATM port #1 running on line 1

ATM port #1 running on line 3

IMA port #6 running on lines 2, 4, 7 and 8

1

3

2478

3 logical ports used = 2 single ATM ports + 1 IMA port




Figure 4-6 AUSM/B-IMA Ports

IMA ProtocolIMA protocol is based on IMA framing. An IMA frame is defined as M consecutive number of cells transmitted on each link in an IMA group. The ATM Forum requires the IMA implementation to support M=128 cells and optionally support M=32, 64, and 256. The current AUSM/B implementation only supports frame lengths of 128 cells. The transmitting IMA aligns the transmission of IMA frames on all links within the group.

The IMA protocol uses two types of control cells: IMA Control Protocol (ICP) cells and Filler Cells.

• ICP cells’ primary functions are to maintain IMA Frame synchronization and protocol control. These control cells send a variety of information such as near-end and far-end transmit-and-receive states, defect indicators for all links, and group states. An ICP cell is sent on each link once per IMA frames; in this case they are sent every 127 cells.

• Filler cells are sent over links that are not part of data round-robin. When there is no data to be sent out on a link, the sending device transmits filler cells to keep the round-robin process in sync.

ICP and Filler cells have VPI=0, VCI=0, PTI=5, and CLP=1.

AUSM/B IMA FeaturesIMA allows for diverse routing of T1/E1 lines in the IMA group. The ingress end of the IMA port compensates for differential delay among the lines within a set limit. The maximum configurable delay for a T1 is 275 ms and the maximum configurable delay for an E1 is 200 ms.

The IMA group also provides for a level of resiliency. The user can configure a minimum number of links that must be active in order for the IMA group to be active. This allows the IMA group to still carry data traffic even during line failures (errors, signal loss) as long as the number of lines active does not fall below the user-configured value of the minimum number of links.

Manual line deletion and addition to an IMA group can be performed without any data loss. If the user is planning on eventually creating an IMA group, configure the line as an IMA group since future additions and deletions to an existing group are non-service disrupting.

Lines that experience bit errors are detected and are automatically removed if the errors are persistent. The threshold for line removal is not user configurable and is set at two consecutively errored IMA frames on a line. The line will automatically be added back in when frame synchronization is recovered.

The AUSM/B supports only Common Transmit Clock (CTC) mode of operation, whereby the same clock is used for all links in IMA group.

4306

2

3

5 1

2Stream ATM cell stream

To thenetworkthroughCell bus

1

IMA

CPE

6 2 6

6 5 4 3 2 1

2

7

5

73

1

3

8 4 8 4

IMA

AUSM/B



Chapter 4 Service ModulesVoice Service—VISM

The IMA implemented on the AUSM/B is compliant with the ATM Forum IMA 1.0 Specification. ATM Forum–compliant IMA 1.0 interoperability testing has been conducted with the Cisco 2600/3600, ADC Kentrox AAC-3, Larscom NetEdge and Orion 4000, and Nortel Passport.

The differences in Forum–Compliant IMA and previous Proprietary IMA are as follows:

• Active IMA Group Requirements

– Prestandard IMA—Maximum number of failed links is configured. The number of errored links must be fewer than the configured limit in order for the group to be active.

– Forum–compliant IMA—Minimum number of links out-of-error is configured. The number of active links must be greater than or equal to the configured requirement.

• FC-IMA does not support the inband addition of links (not a part of the IMA 1.0 Specification)

– Prestandard IMA allowed for automatic configuration at the Far End when a link was added at the Near End.

– In Forum–Compliant IMA, the automatic configuration at the far end is not supported and thus requires the user to perform the line addition at both ends of the IMA group.

Voice Service—VISMThe Voice Interworking Service Module (VISM) is a high-performance voice module for the Cisco MGX 8230, MGX 8250 and MGX 8850 series wide-area IP+ATM switches. This module is suitable for all service provider voice applications and offers highly reliable standards-based support for voice over ATM and voice over IP.

The VISM provides toll-quality voice, fax and modem transmission and efficient utilization of wide-area bandwidth through industry standard implementations of echo cancellation, voice-compression and silence-suppression techniques.

Service Provider ApplicationsThe MGX 8230 with VISM is the industry’s most flexible and highest density packet voice solution giving the customers the capability to provide VoIP, VoMPLS, VoAAL1 and VoAAL2 thus enabling service providers to deliver new revenue generating voice services using their existing network infrastructure.

Point-to-Point Trunking

Service providers worldwide are rushing to grow and transition their voice traffic onto packet based infrastructure and stop further expenditure on TDM equipment. With its standards based AAL2 implementation, the MGX/VISM can be used to provide a cost effective solution for an integrated voice and data network. By moving all point-to-point TDM voice traffic onto the packet network, cost savings of up to five times can be achieved through efficient use compression, voice activity detection and AAL2 sub-cell multiplexing while guaranteeing transparency of all existing voice services. In addition to the immediate bandwidth savings, the trunking application realizes all the benefits of a single voice+data network. Migration to switched voice services can easily be done through the introduction of a softswitch without any changes on the MGX/VISM platform.




Integrated Voice/Data Access

With the MGX/VISM and access products such as the Cisco MC3810, service providers can now offer integrated voice and data services on a single line (T1/E1) to their enterprise customers. By eliminating the high cost of disparate voice and data networks, service providers can build a single network that will enable them to deliver current and future voice and data services.

At the customer premises, the MC3810 acts as a voice and data aggregator. All the customers voice (from the PBX) and data (from the routers) traffic is fed into the MC3810. AAL2 PVCs are established between the CPE device and the VISM. By enabling VAD and using compression, tremendous bandwidth savings are realized. Connection Admission Control (CAC ) can be used to control bandwidth utilization for voice traffic. All the voice signaling traffic is passed transparently to the PSTN from the VISM. CAS is transported over AAL 2 type 3 cells and CCS is transported over AAL5.

Switched Voice Applications

The VISM supports industry standard media gateway control protocol (MGCP) for interworking with a variety of Softswitches (refer to eco-system partners) to provide TDM voice offload onto packet networks. The VISM together with a SoftSwitch (Call Agent) can be used to provide switched voice capability for local tandem, long distance tandem and local services. In conjunction with a Softswitch, the VISM can act as high density PSTN gateway for H.323 and SIP based networks.

Core FunctionsThe VISM card provides the following voice processing services to support voice over ATM networks:

1. Voice Compression

The VISM supports the following standards-based voice coding schemes:

– ADPCM (G.726)

– CS-ACELP (G.729a/b)

Support for a range of compression allows customers to select the compression quality and bandwidth savings appropriate for their applications; 32-kbps ADPCM, and 8-kbps CS-ACELP compression provide very high-quality and low-bit-rate voice, while reducing total bandwidth requirements.

2. Voice Activity Detection

Voice activity detection (VAD) uses the latest digital-signal processing techniques to distinguish between silence and speech on a voice connection. VAD reduces the bandwidth requirements of a voice connection by not generating traffic during periods of silence in an active voice connection. Comfort noise generation is supported. VAD reduces bandwidth consumption without degrading voice quality. When combined with compression, VAD achieves significant bandwidth savings.

3. Onboard Echo Cancellation

The VISM uses digital signal processor (DSP)-based echo cancellation to provide near-end echo cancellation on a per-connection basis. Up to 128 ms of user-configurable near-end delay can be canceled. Onboard echo cancellation reduces equipment cost and potential points of failure, and facilitates high-quality voice connections. The echo cancellor complies with ITU standards G.164, G.165, and G.168.

4. Fax and Modem Detection




The VISM continually monitors and detects fax and modem carrier tones. When a carrier tone is detected from a modem or a fax, the channel is upgraded to PCM to ensure transparent connectivity. Fax and modem tone detection ensures compatibility with all voice-grade data connections.

5. QOS

The VISM takes full advantage of all the various Quality of Service (QoS) mechanisms available for IP+ATM networks. IP TOS and precedence values are configurable on the VISM. For VoIP, either the RPM (integrated routing module on the MGX) or an external router can be used for advanced QoS mechanisms like traffic classification, congestion avoidance and congestion management. Also, in conjunction with RPM, VISM can take advantage of the QOS characteristics of MPLS networks (VoMPLS). The MGX's advanced traffic management capabilities combined with it's intelligent QoS management suite gives VISM the ability to support voice services which need predictable delays and reliable transport.

6. Integrated Network Management

Cisco WAN Manager (CWM) is a standards based network and element management system that enables operations, administration, and maintenance (OA&M) of the VISM and its shelf. CWM provides an open API for seamless integration with OSS and 3rd party management systems.

Key FeaturesThe VISM uses high performance digital signal processors and dual control processors with advanced software to provide a fully non-blocking architecture that supports the following functions:

• VoIP using RTP (RFC 1889)—VISMR1.5 supports standards based VoIP using RTP (RFC1889) and RTCP protocols. This allows VISM to interwork with other VoIP Gateways.

• VoAAL2 (With sub-cell multiplexing) PVC—The VISM supports standards compliant AAL2 adaptation for the transport of voice over an ATM infrastructure. AAL2 trunking mode is supported

• Codec Support—G.711 PCM (A-law, Mu-law), G.726, G.729a/b.

• 8 T1/E1 Interfaces—The VISM supports 8 T1 or 8 E1 interfaces when G.711 PCM coding is used. For higher complexity coders such as G.726-32K and G.729a-8K, the density drops to 6 T1 or 5 E1 interfaces (max 145 channels).

• 1:N redundancy using SRM.

• T3 interfaces (via SRM bulk distribution)—T3 interfaces are supported using the SRM bulk distribution capability. In this case, the T3 interfaces are physically terminated at the SRM module. The SRM module breaks out the individual T1s and distributes the T1s via the TDM backplane bus to the individual VISM cards for processing.

• Echo Cancellation—VISM provides on-board echo cancellation on a per connection basis.

• 128 msec user-configurable near-end delay can be canceled. The echo cancellation is compliant with ITU G.165 and G.168 specifications.

• Voice Activity Detection (VAD)—VISM uses VAD to distinguish between silence and voice on an active connection. VAD reduces the bandwidth requirements of a voice connection by not generating traffic during periods of silence in an active voice connection. At the far end, comfort noise is generated.




• Fax/modem detection for ECAN and VAD control—VISM continually monitors and detects fax and modem carrier tones. When carrier tone from a fax or modem is detected, the connection is upgraded to full PCM to ensure transparent connectivity. Fax and modem tone detection ensures compatibility with all voice-grade data connections.

• CAS tunneling via AAL2(For AAL2 trunking mode)—VISM in AAL2 mode facilitates transport of CAS signaling information. CAS signaling information is carried transparently across the AAL2 connection using type 3 packets. In this mode, VISM does not interpret any of the signaling information.

• PRI tunneling via AAL5(For AAL2 trunking mode)—VISM supports transport of D-oh signaling information over an AAL5 VC. The signaling channel is transparently carried over the AAL5 VC and delivered to the far end. In this mode, VISM does not interpret any of the signaling messages.

• Voice CAC—VISM can be configured to administer Connection Admission Control (CAC) so that the bandwidth distribution between voice and data can be controlled in AAL2 mode.

• Type 3 packet for DTMF—VISM in AAL2 mode facilitates transport of DTMF signaling information. DTMF information is carried transparently across the AAL2 connection using type 3 packets.

• Dual (Redundant) PVCs for bearer/contro—VISM provides the capability to configure two PVCs for bearer/signaling traffic terminating on two external routers (dual-homing). VISM continually monitors the status of the active PVC by using OAM loopback cells. Upon detection of failure, the traffic is automatically switched over to the backup PVC.

• 64 K clear channel transport—VISM supports 64 Kbps clear channel support. In this mode, all codecs are disabled and the data is transparently transported through the VISM.

• DTMF relay for G.729—In VoIP mode, DTMF signaling information is transported across the connection using RTP NSE (Named Signaling Event) packets.

• MGCP 0.1 for VoIP with Softswitch control—VISM supports Media Gateway Control Protocol (MGCP) Version 0.1. This open protocol allows any Softswitch to interwork with the VISM module.

• Resource coordination via Simple Resource Control Protocol (SRCP)—provides a heartbeat mechanism between the VISM and the softswitch. In addition, SRCP also provides the softswitch with gateway auditing capabilities.

• Full COT functions—VISM provides the capability to initiate continuity test as well as provide loopbacks to facilitate continuity test when originated from the far end.

• Courtesy Down—Provides a mechanism for graceful upgrades. By enabling this feature, no new calls are allowed on the VISM while not disrupting the existing calls. Eventually, when there are no more active calls, the card is ready for a upgrade and/or service interruption.

• PRI backhaul to the Softswitch using RUDP—Provides PRI termination on the VISM with the Softswitch providing call control. ISDN layer 2 is terminated on the VISM and the layer 3 messages are transported to the softswitch using RUDP.

• Latency Reduction (<60 ms round trip)—Significant improvements have been made to bring the round-trip delay to less than 60 ms.

• Codecs Preference—VISM provides the capability to have the codecs negotiated between the two end-points of the call. The VISM can be configured, for a given end-point, to have a prioritized list of codecs. Codec negotiation could be directly between the end- points or could be controlled by a softswitch.

• 31 DS0 for E1 with 240 channels only—while all 31 DS0s on a E1 port can be used, there is a limitation of 240 channels per card.




• New and enhanced CLI commands.

• A-law and µ-law encoding on any channel

• Fax and modem upspeed to G.711 for reliable transfer

• Redundant PVCs for bearer and signaling (MGCP, and so on) traffic

• 1:N Redundancy with standby switchover

• AAL5 connections for OAM, management and signaling transport are supported.

• Standard utilities support for configuration, status, statistics collection, card/port/connection management.

• BERT and loopback support using SRM-3T3 or SRM-T1E1.

• Loop timing and payload and line loopbacks supported.

• Supports a wide variety of compression schemes and silence suppression for efficient bandwidth utilization.

• Statistics collection.

• Standards-based alarm and fault management.

• Simple Network Management Protocol (SNMP) configuration and access.

VISM Physical InterfacesTwo front cards, VISM-8T1 and VISM-8E1, are available for the MGX 8230 platform. Each has eight T1 or E1 line interfaces.

The following 8-port back cards are used:

• RJ48-8T1-LM

• RJ48-8E1-LM

• SMB-8E1-LM

• R-RJ48-8T1-LM

• R-RJ48-8E1 -LM

• R-SMB-8E1 -LM

RedundancyThe VISM redundancy strategy is the same as for any of the 8-port cards in the MGX 8230 switch. For VISM-8T1, 1:N redundancy is supported via the Line Modules (LMs) using the SRM-3T3 or the SRM-T1E1 and it is supported with the distribution bus using the SRM-3T3.




Physical Layer Interface T1The physical layer interface T1 provides the following features:

Physical Layer Interface E1The physical layer interface E1 provides the following features:

Line Rate 1.544 Mbps +/- 50 bps

Line Interface Connector Balanced 100-ohm RJ48C

Synchronization Transmit clock can be selected from one of the following sources: loop time clock, or to the MGX 8220 Shelf clock derived on the BNM

Line Code Bipolar 8 Zero Substitution (B8ZS) as specified in ANSI T1.408

Line Framing Extended Superframe Format (ESF 24 frame Multiframe) as ANSI T1.408

Input Jitter Tolerance Per ATT TR 62411

Output Jitter Generation Per ATT TR 62411 using normal mode synchronization

Physical Layer Alarms LOS, LOF, AIS, RDI

Line Rate 2.048 Mbps +/- 50 bps

Line Interface Connector Balanced 120-ohm RJ48C, unbalanced 75-ohm SMB

Synchronization Transmit clock can be selected from one of the following sources: loop time clock, or to the MGX 8220 Shelf clock derived on the BNM

Line Code HDB3 (E1)

Line Framing 16 frame Multiframe as in G.704

Input Jitter Tolerance As specified in ITU G.823 for the 2.048 Mbps

Output Jitter Generation As specified in ITU G.823 for the 2.048 Mbps

Physical Layer Alarms: LOS, LOF, AIS, RDI




VISM Card GeneralThe VISM card provides the following general features:

Maintenance/Serviceability:

– Internal Loopbacks

– Hot-pluggability

Electrical and Safety StandardsThe MGX 8230 conforms to the following electrical and safety standanrd.

• FCC Part 15

• Bellcore GR1089-CORE

• IEC 801-2, 801-3, 801-4, 801-5, 825-1 (Class 1)

• EN 55022, 60950

• UL 1950

VISM front card AX-VISM-8T1/8E1 7.25" X 16.25"

VISM line modules AX-RJ48-8T1-LM 7.0" X 4.5"

AX-R-RJ48-8T1-LM 7.0" X 4.5"

AX-RJ48-8E1-LM 7.0" X 4.5"

Description Parameters

Interfaces Eight T1 or E1

T3 with optional SRM module

Up to 5760/4608 (E1/T1) G.711 channels per MGX 8230 chassis

Voice Coding/Compression PCM (G.711)

ADPCM (G.726)

CS-ACELP (G.729a/b)

When mixing compression types, the overall capacity varies between 145 and 240 channels per VISM.

Voice Activity Detection Configurable threshold on a per-channel basis

Echo Cancellation Per G.164, G.165, and G.168, programmable up to 128 msec

Fax and Modem Transmission

Using PCM connection, 240 channels per service module

PCM Encoding Types A-law and µ-law encoding

End-to-end conversion available

Channel Gain Control -8 dB to +6 dB



Chapter 4 Service ModulesService Resource Module

Service Resource ModuleCurrently, the SRM-3T3/C is the only Service Resource Module (SRM) supported on the MGX 8230 platform. It is an optional card.

The SRM-3T3/C provides the following major functions for service modules:

• Built-in Bit Error Rate Tester (BERT) capabilities for individual nxDS0, T1, and E1 lines and ports

• Loopback capability for individual Nx64 channels toward the customer premises equipment (CPE)

• Enables 1:N redundancy capability for T1/E1 Service Modules

• Bulk Distribution (built-in M13 functionality)

• Service Resource Module (SRM-3T3/C)

A Service Module (such as FRSM, CESM) operates as a front card and back card combination unless it uses the distribution bus. With the bulk distribution capability of the SRM, certain service modules can communicate through the bus on the backplane and forego the use of back cards.

There are a total of two SRMs per node. The PXM1 in slot 1 controls the SRM in slot 7 and the PXM1 in slot 2 controls the SRM in slot 14. A PXM1 switchover will cause an SRM switchover. A switch with redundant PXMs must have redundant SRMs. The SRM-3T3/C in the MGX 8230 supports bulk distribution in all service module slots.

In bulk mode, each of the SRM’s T3 lines can support 28 T1s, which it distributes to T1-based service modules in the switch. Up to 64 T1s (eight 8-port T1 cards) per chassis can be supported.

SRM ArchitectureThe SRM-3T3/C uses the following buses on the MGX 8230 back plane:

• Local bus—This bus is used to communicate between the Processor Switch Module (PXM1) and the Service Resource Module (SRM).

• T1/E1 Redundancy bus—The redundancy bus is used to route the T1/E1 signals from a selected service module’s line module to the standby module. Access to this bus is controlled by the SRM.

• BERT bus—The BERT bus is used to generate and test using a variety of Bit Error Rate Tests (BERT) on any specific individual nx56k/64K, T1, or E1 line or ports. The BERT function is built into the SRM module. The BERT bus provides all the necessary signals including time slot indications required for this purpose.

• Distribution bus—This bus is used by the SRM-3T3/C to distribute DS1 signals to the service modules. It is a point-to-point connection between the SRM-3T3 and all the service module slots.

Quantizing Distortion Added

2.5 quantizing distortion units (QDU)s with 32-kbps ADPCM over one hop plus 0.7 QDUs with digital loss packet assembler/disassembler (PAD) (µ-Law or A-Law)

Nominal Transmission Loss 0 dB at 1 kHz

Power Consumption 60 watt (estimated)

Weight (including Back Card)

Approximately 1.74 lb

Description Parameters




One of the main applications of the SRM-3T3/C is to eliminate the need for individual T1 lines to directly interface with the service modules. Instead, the DS1s are multiplexed inside the T3 lines. The SRM-3T3/C can accept up to three T3 inputs. When the T3 inputs are selected, the SRM-3T3/C assumes asynchronous mapping of DS1s into the T3 signal. It will demultiplex individual DS1 tributaries directly from the incoming T3 and distribute them into the service modules.

SRM-3T3/C FeaturesSRM-3T3/C features include:

• Three DS3 interfaces

• Supports bulk and nonbulk mode of operation

• Supports multiple groups of 1:N (T1/E1) service module redundancy

• Provides BERT capabilities

• Generates OCU/CSU/DSU latching and nonlatching loopback codes

• Monitors any individual timeslot for any specified DDS trouble code

Interfaces

The SRM-3T3/C has three DS3 (44.736 Mbps +/-40 ppm) interfaces with dual female 75-ohm BNC coaxial connectors per port (separate RX and TX).

Bulk Mode and Nonbulk Mode

Each of the T3 ports can be used to support up to 28 multiplexed T1 lines, which are distributed to T1 service module ports in the switch. Called bulk distribution, this feature is performed when the SRM is in “bulk mode.” The purpose of this feature is to allow large numbers of T1 lines to be supported over three T3 lines rather than over individual T1 lines. 64 channels per service bay can be active at any time. Any T1 in a T3 line can be distributed to any eight ports on a service module in any slots of the service bay without restriction.

The SRM-3T3/C can also be operated in “nonbulk mode.” For a port configured in nonbulk mode, bulk distribution is disabled and the SRM acts as an SRM-T1/E1, providing BERT and 1:N redundancy functions only. A service module port cannot be used simultaneously with an individual T1 line and with a distributed T1 channel.

Multiple Groups of 1:N Redundancy

The SRM enables 1:N redundancy for multiple groups of (T1/E1) service modules, where a group consists of N active and one standby service module. For example, if both AUSM/B and FRSM cards are installed in the chassis, you can protect both groups of cards separately via redundant cards for each of these groups. The redundant service module in a group must be a superset (with respect to functionality) of the cards. Upon the detection of a failure in any of the service modules, the packets destined for the failed service module are carried over the distribution or redundancy bus (depending on whether in bulk or nonbulk mode) to the SRM in its chassis. The SRM receives the packets and switches them to the backup service module. Thus each active SRM provides redundancy for a maximum of 8 service modules. The failed service module must be replaced and service switched back to the original service module before protection against new service module failures is available.




BERT Capabilities

After a service module line or port is put into loopback mode, the SRM can generate a test pattern over the looped line or port, read the received data and report on the error rate. This operation can be performed on a fractional T1/E1, T1/E1or an Nx64K channel/bundle. The SRM can support BERT for only one line or port at a time. If a switchover occurs while BERT testing is in progress, the BERT testing must be re-initiated. BERT capabilities are supported on the FRSM-8T1/E1, AUSM/B-8T1/E1, CESM-8T1/E1, and the FRSM-2CT3.

Other Capabilities

The SRM can also generate OCU/CSU/DSU latching and nonlatching loopback codes and monitor any single timeslot for any specified DDS trouble code.

RedundancyOne of the major functions of the SRM-3T3/C is to provide 1:N redundancy. Figure 4-7 illustrates 1:N redundancy. The upper part of the illustration show the FRSM-8T1 in slot 6 has been configured to provide 1:N redundancy for the FRSM-8T1s in slots 4 and 5. In the bottom part, the FRSM-8T1 in slot 5 has failed and the one in slot 6 has taken over for the failed service module.

Figure 4-7 1:N Redundancy

1:N Redundancy

Currently, 1:N redundancy is only supported for the 8-port T1/E1 cards (for example, FRSM-8T1, 8E1, 8T1-C and 8E1-C). A 1:N redundancy support for the T3/E3 cards would require a new SRM.

If the system has an SRM-3T3/C, 1:N redundancy can be specified for 8T1/E1 service modules. With 1:N redundancy, a group of service modules has one standby module. When an active card in a group fails, the SRM-3T3/C invokes 1:N redundancy for the group. The back card of the failed service module subsequently directs data to and from the standby service module using the redundancy bus. The

train1.1.7.PXM.a > dspred Primary Primary Primary Secondary Secondary Secondary Red. Red.Slot SlotNum Type State SlotNum Type State Type Cover ------- ------- ------- --------- --------- --------- ---- -------- 4 FRSM-8T1 Empty 6 FRSM-8T1 Standby 1:N 0 5 FRSM-8T1 Active 6 FRSM-8T1 Standby 1:N 0

train1.1.7.PXM.a > dspred Primary Primary Primary Secondary Secondary Secondary Red. Red.Slot SlotNum Type State SlotNum Type State Type Cover ------- ------- ------- --------- --------- --------- ---- -------- 4 FRSM-8T1 Empty 6 FRSM-8T1 Active 1:N 4 5 FRSM-8T1 Active 6 FRSM-8T1 Blocked 1:N 0

train1.1.7.PXM.a > dspcds

Slot CardState CardType CardAlarm Redundancy ---- ----------- -------- --------- ----------- 1.1 Empty Clear 1.2 Empty Clear 1.3 Active CESM-8T1 Major 1.4 Reserved FRSM-8T1 Clear Covered by slot 6 1.5 Active FRSM-8T1 Clear 1.6 Active FRSM-8T1 Clear Covering slot 4 1.7 Active PXM1-OC3 Clear 1.8 Empty Clear




SRM-3T3/C can support multiple group failures if the service modules are configured in bulk mode. In this case, the SRM reroutes the T1 data from the failed card to the standby card using the distribution bus.

The standby service module uses a special, redundant version of the back card. The module number of the redundant back card begins with an “R,” as in “AX-R-RJ48-8T1”.

When the failed card is replaced, switch back to normal operation. The switch does not automatically do so.

1:1 Redundancy

A 1:1 redundancy is NOT a feature of the SRM. This type of redundancy requires a pair of card sets with a Y-cable for each active line and its redundant standby. Specify one set as active and one set as standby. The configuration is card-level rather than port-level.

SM Redundancy with Line Modules

Nonbulk mode distribution is a mode of operation where individual T1 lines are directly connected to the line module of each front card. During normal nonbulk mode operation, the T1/E1 data flow is from the service module’s line module to its front card and vice-versa. The line modules also contain isolation relays that switch the physical interface signals to a common redundancy bus under SRM-3T3 control in case of service module failure.

When a service module is detected to have failed, the PXM1 will initiate a switchover to the standby service module. The relays on the service module’s line module (all T1/E1s) are switched to drive the signals onto the T1 redundancy bus. The designated standby card’s line module (controlled by the SRM-3T3) receives these signals on the T1/E1 redundancy bus. The data path then is from the failed service modules’ line module to the T1/E1 redundancy bus to the line module of the standby service module and finally to the standby service module itself. The service module redundancy data path is shown in Figure 4-8.




Figure 4-8 SM Redundancy with Line Modules

Line module redundancy is not offered since there are no service affecting active devices.

In nonbulk mode, the SRM-3T3 will control the data path relays on the service module’s line modules.

The 1:N redundancy is limited to the service bay that the SRM and the service modules are located in. Therefore, each active SRM provides redundancy for a maximum of 8 service modules.

Bulk Mode Distribution/Redundancy

Bulk distribution is a mode of operation in which individual lines are not brought to service modules, but instead the these lines are multiplexed into a few high-speed lines attached to the SRM. The SRM then takes this “bulk” interface, extracts the lines, and distributes them to the service modules. Any cards served by this bulk interface can participate in 1:N redundancy without using the separate redundancy bus. Any T1 in a T3 line can be distributed to any eight ports on a service module in any slots of the service bay without restriction.

The 1:N redundancy is limited to the service bay that the SRM and the service modules are located in.

During bulk mode operation, the SRM-3T3/B unbundles T1 data from the incoming T3s and sends it to each service module (see Figure 4-9). Any slot can be used to process T1 data or to house a standby service module. When a service module fails, the PXM1 initiates a switchover to a previously configured standby module. The SRM-3T3/C will redirect the recovered T1 traffic to the designated standby

SMback card

active

CPE

4306

5

SMback card

active

CPE

Standby SMspecial

redundantback card

SRMback card

SMfront card

active

SMfront card

active

DesignatedSM

front cardstandby

SRM-3T3/B

Redundancy bus

SMback card

active

CPE

SMback card

active

CPE

Standby SMspecial

redundantback card

SRMback card

SMfront card

active

SMfront card

active

DesignatedSM

front cardstandby

SRM-3T3/B

Redundancy bus




module. The switching takes place inside the SRM-3T3/C and requires no special back cards or cabling. The data path to the standby module is still via the Distribution Bus. The Redundancy Bus is NOT used in bulk mode.

The current SRM can support 64 T1/E1s.

Figure 4-9 Bulk Mode Distribution/Redundancy

LoopbacksThe MGX 8230 supports many different types of loops for performance testing. The loop types supported on a card are dependent on the card type and line type. There are three types of loops supported:

• Local loop—A loop that faces toward the ATM backbone network. Local loops are used to test through the network from a remote MGX 8230.

• Remote loop—A loop that faces toward the attached end-user equipment. Remote loops are used to test a line or port from a remote test device.

• Far-end loop—A loop that is implemented on the attached end-user equipment facing back toward the MGX 8230. Far-end loops are used in conjunction with the SRM BERT or to test from a remote MGX 8230 through the network and out to the remote end-user equipment.

4306

6

T3 line

SRMback card

SMfront card

active

SMfront card

active

DesignatedSM

front cardstandby

SRM-3T3/B

Distribution busT1(s)

T3 line

SRMback card

SMfront card

active

SMfront card

active

DesignatedSM

front cardstandby

SRM-3T3/B

Distribution bus




Local line loops can also be initiated on the T1/E1 service modules via the addlnloop command. On the T3 service modules, the addds3loop command would be entered. All three line loops are supported by the SRM.

BERT Data PathThe SRM-3T3/C card performs BERT pattern generation and checking for the DS1/DS0 stream. This function is completely separate from the 3T3 distribution features of the SRM-3T3.

The SRM can support BERT on only one line or port at a time. BERT is capable of generating a variety of test patterns, including all ones, all zeros, alternate one zero, double alternate one zero, 223-1, 220-1, 215-1, 211-1, 29-1, 1 in 8, 1 in 24, DDS1, DDS2, DDS3, DDS4, and DDS5.

The BERT bus is used to provide the BERT operation to the individual service modules. This bus is also used to drive special codes such as fractional T1 loopback codes, and so on, onto the T1 line. The BERT function is initiated ONLY on one logical T1/E1 N x 64K port per MGX 8230 at any given time and this is controlled by the PXM1. The SRM-3T3 ensures that the BERT patterns are generated and monitored (if applicable) at the appropriate time slots.

The datapath then for that particular port (N x 64K) is from the service module to the SRM-3T3/C (via the BERT bus) and back to the service module (via the BERT bus). On the service module, the data that is transmitted is switched between the regular data and the BERT data at the appropriate timeslots as needed. Similarly in the receive direction, the received data is diverted to the BERT logic for comparison during appropriate time slots. The illustration in Figure 4-10 shows the datapath for BERT and loopback operations via the SRM-3T3 module.

Figure 4-10 BERT Data Path

The BERT logic is self-synchronizing to the expected data. It also reports the number of errors for bit error rate calculation purposes.

BERT testing requires the presence of an SRM-3T3/C card in the service bay in which the card under test is located. The BERT tests can only be initiated by CLI.

Caution BERT is a disruptive test. Activation of this test will stop the data flow on all the channels configured on the port under test.

4306

7

SMback card

active

CPE

SMback card

active

CPE CPE

SMfront card

active

SMfront card

active

SM frontcard active(port under

BERT) SRM-3T3/B

BERTlogic

BERT bus

2

3

4

1

SMback card

SMback card



Chapter 4 Service ModulesRoute Processor Module

Route Processor ModuleThe Cisco MGX 8230 Route Processor module (RPM) provides a new dimension in its industry-leading service breadth, providing integrated IP in an ATM platform, enabling services such as integrated Point-to-Point (PPP) protocol and Frame Relay termination and IP virtual private networks (VPNs). The full IOS enables the IP services for RPM.

The Route Processor Module on an MGX 8230 is a Cisco 7200 series router redesigned to fit onto a single double-height card that fits into an MGX 8230 chassis.

The module fits into the MGX 8230 midplane architecture, with the RPM front card providing a Cisco IOS network processing engine (NPE-150), capable of processing up to 140K packets per second (pps). The front card also provides ATM connectivity to the MGX 8230 internal cell bus at full-duplex OC-3c/STM-1 from the module. Each module supports two single-height back cards. Initially, three single-height back-card types will be supported: four-port Ethernet, one-port (FDDI), and one-port Fast Ethernet.

The RPM enables high-quality, scalable IP+ATM integration on the MGX 8230 platform using MPLS Tag Switching technology. Tag Switching combines the performance and virtual-circuit capabilities of Layer 2 switching with the proven scalability of Layer 3 networking and is the first technology to fully integrate routing and switching for a scalable IP environment.

Each RPM module supports two single-height back cards. Initially, three basic types of back-cards will be supported: four-port Ethernet, one-port (FDDI), and one-port Fast Ethernet.

The RPM can be ordered with 64M DRAM or 128M DRAM. The RPM currently has 4M of Flash Memory and does not support PCMCIA slots for Flash memory cards. The Cisco IOS image and configuration files are stored on the PXM1 hard drive or a network server.

FRSM to RPM Connection

From the FRSM, the frames are forwarded to the RPM via frame forwarding and FR-ATM Interworking, as illustrated in Figure 4-11.

Figure 4-11 FRSM to RPM Connection

4305

8

addlncnfln

Adding the connection

Add the FRSM lineand configure it.

Add the FRSM portand configure it.

addportxcnfport

END




Frame Aggregation: Port Forwarding

All frames received on a port are forwarded to the router for Layer 3 processing. For example, an FRSM T1 could be configured for PPP IP access by

1. Setting up a frame forwarding (FF) connection from an FRSM T1 port to the RPM cell bus address on VPI/VCI.

2. Configuring the router to terminate PPP frames forwarded over an ATM connection on the internal ATM interface via aal5ciscoppp encapsulation (a Cisco proprietary method whereby all HDLC frames received on a port are converted to ATM AAL5 frames with a null encapsulation and are sent over a single VC). Cisco has already implemented code to terminate frame-forwarded PPP over ATM.

The data flow for a PPP connection destined for the RPM is shown in Figure 4-12. The packet enters the FRSM module as PPP and is frame forwarded to the RPM. The RPM receives the packet in PPP over ATM because the MGX 8230 internal connectivity is ATM. The RPM is running software that understands PPP over ATM encapsulation, allowing the router to reach the IP layer and route the packet to its destination (for example, the Internet). Packets destined to the Internet via a WAN network are then sent back to the PXM1, and out the ATM uplink.

Figure 4-12 FRSM to RPM Connection

FR-ATM Interworking

In this example, all frames received on a given connection are forwarded to the router using the appropriate ATM encapsulation. For example, Frame Relay connections on an FRSM port could be forwarded to the RPM by:

WAN network

Frameforwarding

FRSM

PXM

PPP

FRSM

PPP/ATM

RPM

FDDI

EthernetFast Ethernet

Frame forwardingATM uplink

WAN network

4305

9

FR/ATMSW

PXM

FRRFC 1490

RFC1483

RPM FR-ATM forwardingATM uplink




• Translating a Frame Relay connection to an ATM connection via network interworking (FRF.5) or service interworking (FRF.8).

• Configuring the router to terminate Frame Relay over ATM (RFC 1483) on the ATM PA port on VCI 0/x.

The data flow for a native Frame Relay connection destined to the RPM is shown in Figure 4-13. This data flow is identical to that of PPP packets, but the encapsulation techniques are different. Standard Frame Relay is encapsulated using RFC1490. When a packet is received at the FRSM encapsulated using RFC1490, standard FR-ATM service interworking translation mode (FRF.8) is performed so that when the packet is forwarded to the router blade it is encapsulated using RFC1483. The router also understands RFC1483, allowing it to reach the IP layer, and route the packet.

Tip An aal5snap encapsulation is needed to perform Interworking functions.

AUSM/B to RPM Connection

ATM UNI/NNI connection between the RPM and the AUSM/B is illustrated in Figure 4-13.

Figure 4-13 AUSM/B to RPM Connection

4306

0

addlncnfln

Adding the connection

Add the AUSM/B lineand configure it.

Add the AUSM/B portand configure it.

(Optional) Set up egress queues.

(Optional) Configure UPC.

addportcnfport

cnfupccbrcnfupcvbrcnfupcabr

cnfportq

END

(Optional) Configure ForeSight.

(Optional) Configure queue depth.

cnfchanfst

cnfchanfst




ATM Deluxe Integrated Port Adapter/Interface

The ATM Deluxe port adapter/interface is a permanent, internal ATM interface. The ATM Deluxe port adapter provides a single ATM interface to the MGX 8230 cell bus interface (CBI). Since it is an internal interface and resides on the RPM front card, it has no cabling to install and no interface types supported. It connects directly to the MGX 8230 midplane. (See Figure 4-14.)

The following features from the ATM Deluxe port adapter/interface are supported on the MGX 8230 switch:

• Support for all 24 bits of the UNI VP/VC field, any arbitrary address

• Support for 4080 connections

• ATM Adaptation Layer 5 (AAL5) for data traffic

• Traffic management

• Four transmit scheduling priority levels

• Respond to/generate OAM flows (F4/F5)

Figure 4-14 ATM Deluxe Integrated Port Adapter

midplane

RPM back card #1

RPM back card #2

4305

5

RPM front card

Routing engine

ATM deluxe integratedport adapter

Cell bus controller ASIC




Figure 4-15 shows a block diagram of RPM front and back cards in an MGX 8230.

Figure 4-15 RPM Block Diagram

midplane

RPM back card #1

RPM back card #2

Cell bus to PXM

4305

6

RPM front card

AUX

Console

PCI #1

PCI #2

7200 routing engineNPE 150

ATMSAR Cell

busASICATM

SAR

C H A P T E R



5Software Architecture

OverviewThe software on the MGX 8230 is comprised of three major functional blocks:

• Platform control

• Configuration and monitoring services

• Node management

To deliver these services, the software is partitioned into four main software areas.

1. Networking Software—Software modules that deal with network topology, routing, and signaling. Networking software operates on abstract network objects (for example, logical interfaces, connections, and so on) and is not concerned with platform-specific operations. Individual software modules (Portable AutoRoute, PNNI) may sometimes be referred to as Network Controllers.

2. Platform Software—Software package that manages and controls the switch platform directly. It is responsible for the low-level operation of the system (including resource management and physical redundancy control). This includes the PXM and SM software.

3. Control Software—Group of software that works as a centralized control point for integrated CLI, SNMP, Robust Trap Management, MIB, and Web management functions. It provides full switch and interface management for all hardware modules, service provisioning, and fault finding/diagnostic support for the complete chassis.

4. Router Software—RPM/IOS software.

In addition, the Virtual Switch Interface (VSI) provides a single controller implementation that can be used across different platforms for the same function; and management APIs provide an interface between the network control modules and node management software.

Figure 5-1 provides an overview of the MGX 8230 software architecture and the relationships of the software modules to other components.



Chapter 5 Software ArchitecturePlatform Software

Figure 5-1 MGX 8230 Software Architecture

Platform SoftwareThe platform software is responsible for the low-level operation of the system (including resource management and physical redundancy control). This layer provides a set of services to the remaining subsystems. These services are categorized as Generic Cross-Connection Service, Basic Platform-Specific Configuration and Monitoring Service, and Platform Infrastructure.

1. Generic Cross-Connection Service

The platform software contains the Virtual Switch Interface (VSI) API to provide a generic set of cross-connect control services for setting up and tearing down single-hop cross-connects. The VSI service provides the means for network control subsystems to:

– Add and delete single-hop cross-connects

– Discover logical ports (when ports are brought up by the management layer)

– Monitor resource utilization (bandwidth and cross-connect availability)

2. Platform-Specific Configuration and Monitoring Services

The platform software provides an API to the management layer (for example, 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.

3. Basic Platform Infrastructure

The platform software provides the basic infrastructure for the following features.

– Drivers for the PXM SAR

– Intercard communications

– File system support

– Service module redundancy control

4306

8

AutoRoutesoftware

(runs on PXM)

PNNIsoftware

(runs on PXM)

Control point software(runs on PXM)

To NMS(CWM, Web, other)

IOSsoftware(RPM)

Platform software(runs on PXM)

Node management

Virtual SwitchInterface (VSI)

ManagementAPIs

Configurationand monitoring

Platform control



Chapter 5 Software ArchitectureVSI

As shown in the Figure 5-2, the platform software has a centralized component running on the PXM, and distributed code running on the service modules.

Figure 5-2 Platform Software Components

Distributed ProcessingThe MGX 8230 platform software is based on a distributed processing model. The MGX 8230 Inter-Processor Communication, built upon Remote Procedure Call (RPC) and the Shelf Communication Module (SCM) paradigm, allows clients to make remote procedure calls through a local procedure call interface.

The MGX 8230 platform databases (MIBs) are also distributed among PXM, RPM, and the service modules. For example, the line, port, and channel databases are maintained by the individual service module and the connection database is maintained by PXM.

VSITo interface with multiple network software controller types, a standardized interface was created known as the Virtual Switch Interface (VSI) (see Figure 5-3). VSI defines the messages and associated functions that allow communication between the controller and the switch software.

Originally designed for PNNI portability between platforms, the VSI enables a single controller implementation that can be used across different platforms for the same function. For example, a single PNNI controller developed for the MGX 8230 could be used on the BPX 8600.

Furthermore, by having a common messaging interface, the controllers do not have to reside on the same card or box. The Label Switch Controller (LSC) on the MGX 8230 resides on the RPM card as opposed to Portable Autoroute Controller, which resides on the PXM. Similarly, the Label Switch Controller, on Cisco 7500 and Cisco 7200 series routers, communicates using VSI to an external BPX’s switch software.

Hence, VSI allows multiple services to run on the same platform. Each network software controller is a VSI master that talks to the VSI slave residing on the platform software.

4423

8

Control point software(runs on PXM)

Centralized on PXM

De-centralized on SMs



Chapter 5 Software ArchitectureNetworking Control Software

Figure 5-3 Virtual Switch Interface (VSI)

Networking Control SoftwareThere are three types of Network Controllers available on the MGX 8230. Only the Portable Autoroute Controller is currently available.

1. Network Controllers

The three network controllers include:

a. Portable Autoroute Controller (PAR)—Available presently on MGX 8230 to perform feeder connections and local connections (DAX) in feeder or stand-alone mode only. The MGX 8230 does not support Autoroute routing functionality with PAR in current implementation.

b. Tag Switch Controller—Not available in current implementation. Presently available on BPX 8620 and BPX 8650 in conjunction with Cisco 7500 or Cisco 7200 routers running the TSC-capable IOS version.

Portable AutoRoute

Portable AutoRoute (PAR) performs the following functions:

• Connection Provisioning—Receives messages from platform software. Interprets requests for adding and deleting connections and modifies connection database accordingly. Maintains synchronization of database contents with that of platform software.

• Connection Alarm Management—On receipt of a failure event, PAR sends messages to the platform software to condition the connection. Also, connection databases are updated to reflect the current state of the connection.

• Annex G Functionality—Manages the Annex G LMI communication between the MGX 8230 and the routing node. The LMI signaling protocol allows the nodes to exchange information such as PVC status through status enquiries and status messages. This applies only to the MGX 8230 in a feeder mode.

• Clocking Control—PAR handles the clocking selection for the switch. It will inform the standby controller card, along with the active when clock configuration changes.

4423

9

Tag Controller

Master

PAR

Master

PNNI

Master

Virtual switch slave

Firmware and drivers

Networksoftware

VSI

Platformsoftware

VSIVSI



Chapter 5 Software ArchitectureNode Management (Control Point) Software

Cisco IOS Routing SubsystemThe Cisco IOS software, running on one or more RPMs, provides Layer 3 services for the shelf. The management software presents the MGX 8230 as a fully integrated component. The Cisco IOS subsystem also has two APIs as illustrated in Figure 5-4.

Figure 5-4 RPM View of the PXM

Node Management (Control Point) SoftwareThe node management software (or Control Point software) resides on the PXM. It provides a single, integrated point of control for managing the platform. It provides full shelf and interface management for all hardware modules, service provisioning, and fault finding/diagnostic support for the complete shelf.

The MGX 8230 components that are managed with the Control Point software include:

• Processor Switch Module (PXM)

• Router Processor Module (RPM)

• Service Module (SM)

• Portable AutoRoute Software

SNMP SupportThe SNMP-based message interface is used between the front end and agents. The interface between the agents and the MIB functions is a direct function call or remote procedure calls depending upon the location of those two entities.

Command Line InterfaceControl Point software presents a uniform management view of multiple products and technologies. The Command Line Interface (CLI) provides a single, integrated point of control for managing the MGX 8230 platform. It performs full-shelf and interface management for all hardware modules, service provisioning, and fault finding/diagnostic support for the complete shelf. The CLI provides:

• Port management

• Connection management, including collection and display of statistics

4424

0

PA 1

PA 2

RPM

SwitchOC3ATMPA

FR port

ATM port

HDLC FF port



Chapter 5 Software ArchitectureNode Management (Control Point) Software

• Initialization management

• Card management

The MGX 8230 provides the following CLI features:

• CLI access through the serial console port on the PXM

• CLI access through the serial modem port on the PXM

• CLI access through the Ethernet port on the PXM

• Complete CLI support for PXM platform software including SRM-3T3 functions

• Complete set of CLI commands for Portable AutoRoute

• Complete set of CLI commands for all MGX 8230 service modules.

Alarms and TrapsAll alarms and events generate traps. MGX 8230 switches send traps to all registered trap managers when error events occur.

The Robust Trap Management (RTM) scheme is supported for PXM and all MGX 8230 service modules. RTM is a mechanism for keeping track of trap sequence numbers in traps so that the management system can provide complete trap information. Under this scheme, traps look like normal SNMP traps but have sequence numbers. If a missing sequence is detected, the network manager can request the missing trap.

Event LoggingApplications may log specific events and error conditions using the event mechanism provided by the platform software.

Statistics RegistryThe MGX 8230 maintains a statistics subsystem primarily to monitor traffic conditions within the system. The TFTP daemon that handles configuration upload requests also services the statistics upload requests.

The statistics subsystem uses two levels of abstraction when gathering data: Files and Buckets. Each file contains one or more buckets. User activates the statistics manager on CWM, and selects the bucket interval and the collection period (both exprssed in minutes).

The Statistics Task runs periodically, building a new output file at the end of each collection period. The output files are used in a round-robin scheme, meaning that the file with the oldest data is always used next. The CWM system can request any of the files, using the time of day as a file index.

There is a fixed amount of memory reserved for statistics files. The number of files available depends on the file size.

C H A P T E R



6Network Management

Cisco multiservice management tools are standards-based and fully compatible with multivendor network environments and existing management systems. They are delivered in a layered, modular framework, with open interfaces at each layer.

The Cisco management framework is consistent with the Telecommunication Management Network (TMN) model developed by the ITU. Like TMN, Cisco uses a five-layer model that defines both the logical division and the communication between areas of the service provider’s business operations and management processes. Consistent with this architecture, Cisco has developed a suite of service, network, and element management solutions.

Network and Element ManagementCisco service management solutions integrate with network and element management solutions to enable continuous management and control of the entire network or individual elements, such as hubs, routers, switches, probes, and data collection devices.

Open, Standard InterfacesThe Cisco enhanced TMN-based management architecture allows service providers to readily support standards as they are defined and adopted. The architecture uses the protocol best suited to the application’s needs. For example, Simple Network Management Protocol (SNMP) represents and performs operations on management objects; Trivial File Transfer Protocol (TFTP) transfers large volumes of data; and telnet provides direct access to and control of network elements via the command-line interface.

CiscoViewAt the element layer, equipment and device management functions are performed by CiscoView, a GUI-based application that provides dynamic status, statistics, and comprehensive configuration information for Cisco internetworking products (switches, routers, concentrators, and adapters). CiscoView provides the following core functions:

• Graphically displays the MGX 8230 switch from a network management location, giving network managers a complete view of all Cisco products in the network without physically checking each device at remote sites.

• Provides exception reporting, enabling users to grasp essential inquiry information quickly



Chapter 6 Network ManagementEmbedded Management Functions

• Displays a continuously updated physical picture of the MGX 8230 service modules and other physical components including the routers, hubs, or access servers in the network

• Simultaneously supports multiple switches, routers, hubs, or access servers through multiple invocation within the same session

Embedded Management FunctionsThe network management software provides the following embedded management functions.

Configuration ManagementConfiguration on the PXM will be done through an SNMP manager or CLI interface. All configuration information will be kept in a Management Information Base (MIB). SNMP will be used between an external management system and the platform to retrieve configuration data, provision logical and physical interfaces, distribute alarm information, gather real-time counters, and invoke diagnostic functions.

Resource ManagementThere are multiple network controller software modules (for example, MPLS, PNNI) that talk with the platform software via the VSI (Virtual Switch interface) protocol to deal with their respective network topology routing and signaling. Every connection added will take away from the edge concentrator's pool of limited resources (for example, total number of connections, bandwidth, or connection IDs). The resources that these controllers vie for include:

• Card-level resources-number of connections.

• Port-level resources-connection identifiers (for example, DLCI, VPI, VCI, etc.) and bandwidth.

In parallel with this concept, two types of resource partitioning can be performed: card resource partitioning and port resource partitioning.

When a card is first brought up, the card partition consists of each controller sharing the maximum number of connections for the card. These values are enforced as the maximum number of connections against the card for that particular controller. These values are also inherited by the port resource partition when a port is created.

When a port is added, the port partition contains the connection identifier, bandwidth, and number of connections space per controller. By default, the port resources are again fully shared among the controllers and the connection space values are inherited from the card partition. The values specified in the port partition are advertised to the controllers and they are bound to these limits when adding connections for that port.

Customers who have multiple controller types should perform both card and port resource partitioning. Customers who have multiple controller types and also want to do card-level resource partitioning, need to perform card resource partitioning first. Port resource partitioning would then be performed to divide the port resources and to further divide the card resources at the port level if so desired.




Provisioning In a feeder mode, the MGX 8230 interfaces with a BPX ATM backbone network and acts as a shelf of the BPX. In a standalone mode, the MGX 8230 interfaces with a third party ATM network.

To add an end-to-end connection, from local feeder to remote feeder, one would have to add three connections that span three segments. To add an end-to-end connection, from local feeder to a routing node, one would have to add two connections that span two segments. To add an end-to-end connection in a standalone scenario, one would first need to add the local connection from the service module to the outbound user port. From that point, you would need to add a connection in the third-party network to the desired terminating device.

The number of steps to add an end-to-end connection can dramatically be reduced by using Cisco WAN Manager. CWM will allow the user to specify the originating and terminating end and the connection parameters using a GUI interface. All segment connections are added transparently.

The Connection Manager on CWM can be used to create and maintain end-to-end connections or Permanent Virtual Circuits (PVCs). A connection consists of a source (localEnd), a destination (remoteEnd) and a set of connection parameters required for the routing.

The Connection Template Manager feature is used to define a set of parameters so that they can be reused in Connection Manager to define connections. Templates can be saved to files and then used to create or modify connections.

The Multiple Users Security feature, in which each CWM user has their own access profile, is used to determine whether you have the rights to use each option in the CWM Connection Manager. The security mapping for CWM Connection Manager is

• Read Permission—List connections and view multicast connections and templates.

• Create Permission—Configure connections and do association backup.

• Modify Permission— Modify connections. You have Read Permission with the Modify Permission.

• Delete Permission—Delete connections. You have Read Permission with the Delete permission.

Fault ManagementThe Cisco WAN solution is a distributed intelligent system design. All edge concentrators run independently of the Cisco WAN Manager. Should the Cisco WAN Manager become disabled, there is no effect on the network and its operations. The Cisco WAN Manager is essentially a window to the network and not the controlling “mind” of it. You can back up gateway configurations and store them on the Cisco WAN Manager.

The MGX 8230 service transparently supports end-to-end F4 and F5 OAM flows.

OAM cell processing uses a combination of hardware and software functionality within the MGX 8230. As the current standards for OAM cell processing are enhanced.

There are several types of OAM cells implemented by the MGX 8230 that are used in the detection and restoration process combined with distributed network intelligence.

The MGX 8230 supports F1 flows for ATM over DS3/E3.

Connection-failure handling means supporting AIS (Alarm Indication Signal), RDI (Remote Detection Indicator), A-bit Alarm, test delay, and cc mechanism (continuity checking).

When there is a failure, AIS is generated by CPE or by the service module (SM). If AIS is generated by CPE, the SM will forward AIS to the network (to the other end). The other CPE when receives AIS, will send RDI. RDI is used as AIS acknowledgment.




For some SMs such as FRSM, the communication between the CPE and the SM will be A-bit and not AIS. In this case, if the SM receives A-bit alarm from CPE, then it will generate AIS to the network. If there is an interface failure, SM will generate an A-bit alarm and send it to the CPE.

CC mechanism is used to indicate to the far end that the connection is still alive. If the SM supports cc, then the detection of connection failure will be at the card level and not at a controller level (for example, the SM can send an OAM cell every second and if it does not receive an OAM cell, it will fail the connection generating AIS or A-bit to the CPE. The cc OAM is not the OAM loopback.

OAM loopback is configurable at a card level and is supported on RPM/B. RPM/B polls for all the connections. The timer and polling frequency is configurable per connection. RPM/B sends an OAM loopback cell every 1 second (if use default value) and detects other end failure in 3 seconds (if using the default value), which are the same as cc timer and frequency.

Test delay is a CLI command that is used to test continuity of the connection. It uses OAM loopback cell.

Table 6-1 gives a status of the support of the cc feature for each card.

Table 6-2 summarizes the connection failure handling for the different service modules.

Table 6-1 cc (continuity check) Support

Card cc (Continuity Check) Support

FRSM Supports cc through OAM loopback cells

AUSM Doesn't support cc

CESM N/A (declares a failure if no traffic is received)

VISM Doesn’t support cc.

Table 6-2 Service Modules Connection Failure Handling

Feature FRSM AUSM CESM RPM/B VISM

cc Support Supports cc through OAM loopback cells

Doesn’t support cc — Doesn’t support cc. However OAM loopback is supported (which is very similar to the cc command).

Doesn’t support cc.

CC doesn’t receive OAM cell after timeout

Notifies PXM of failure (PXM sends the VSI con trap to the controller). Generates A-bit to CPE.

Notifies PXM of failure (PXM sends the VSI con trap to the controller). Generates AIS to CPE.

Notifies PXM of failure (PXM sends the VSI con trap to the controller). Generates AIS to CPE.

RPM/B DOESN'T notify PXM. RPM/B DOESN'T send anything to its Ethernet port. RPM/B itself is considered to be CPE.

—

Connection fails due to receiving AIS from CPE.

In this case it receives A-bit from CPE, not AIS. Notifies PXM of failure Generates AIS to network

Notifies PXM of failure. Generates AIS to network.

Notifies PXM of failure. Generates AIS to network.

N/A since RPM/B considers itself as CPE

Notifies PXM of the failure. Generates AIS to network.




OAM Loopback

The tstcon command uses end-to-end loopback OAM cell. So if there are ATM switches in between, all switches will just pass the cell as it is to its neighbor. (This OAM cell will be turned around at the router if the ATM connection is till the router.) If the connection is between two VISMs with VoAAL2, other-side (terminating) VISM will loop the OAM loopback cell back.

So in short if you have VoIP connection, router being CPE device for that ATM link, will terminate the OAM loopback cell at its CPE interface. (Other side is all IP cloud on some physical medium, could be Ethernet, could be Token Ring, could be Frame Relay or ATM.) This is the way ATM-forum has defined the OAM F5 flow. Operation can use this facility to trouble shoot ATM connection until router.

Alarms

All alarms and events generated by the applications will be converted into traps and funneled through the central SNMP agent interface. The central alarm collector will create the actual SNMP Trap PDU. It will log the alarms and forward them to all registered SNMP managers. As part of the robust trap mechanism, the alarm distributor assigns a sequence number to each trap and saves them in a circular buffer. Managers that receive trap out of sequence have the option of retrieving the missing traps from the circular buffer using SNMP.

Connection receives AIS from network.

Notifies PXM of failure. Generates RDI to network. Generates A-bit to CPE.

Notifies PXM of failure. Generates RDI to network Generates AIS to CPE.

Notifies PXM of failure. Generates RDI to network Generates AIS to CPE.

— Notifies PXM of the failure. Generates RDI to network Generates AIS to CPE.

Interface failure

Notifies PXM of failure.

Notifies PXM of failure

Notifies PXM of failure

PXM in this case has to send AIS to network for all connections belonging to the failed interface

Notifies PXM of the failure

Card failure Does nothing. If other end card supports cc, then other end will eventually detect failure. Otherwise, controller will set AIS on the trunk side (via VSI commit).

Does nothing. If other end card supports cc, then other end will eventually detect failure. Otherwise, controller will set AIS on the trunk side (via VSI commit).




Test delay Supports test delay. Supports test delay. Supports test delay. Does not support test delay.

Supports test delay.

Table 6-2 Service Modules Connection Failure Handling (continued)

Feature FRSM AUSM CESM RPM/B VISM




Traps are generated by applications on the PXM cards. Traps are also generated by legacy service modules. Traps are recorded on PXM in the Robust Trap Mechanism MIB, which is used to provide a concept of robustness to SNMP Traps. Certain types of traps are also classified as alarm events. An alarm has a trigger trap that leads to the alarm state and a corresponding clear trap that clears the alarm state. Alarms are logged as events and a hierarchy of them is maintained to reflect the current highest alarm at the shelf level and card level.

To support the VISM and the RPM cards, the proxy tasks are modified to process and forward legacy-style traps generated by those service modules.

Fault detection includes hardware and software error malfunctions in all the MGX 8230 components, including service modules and common equipment. In addition, the edge concentrator provides a detailed alarm presentation, indicating alarm severity, type, date and time, alarm source, cause and state.

The edge concentrator records all log activity and maintains a historical log. For user-requested commands, alarm messages and status messages, the disk on the switch will hold 72 hours of information under normal conditions. In addition, the information can be downloaded to the Cisco WAN Manager workstation on an as-needed basis. Performance information is stored in user-definable buckets of 5, 10, 15, 30, or 60 minutes. These performance counters can be aggregated by the Cisco WAN Manager for report generation and analysis.

Alarm data is stored in a circular buffer. If the buffer fills, the oldest entries will be overwritten first. The alarm data file may be manually transferred via TFTP to a designated workstation. This capability could be automated by writing appropriate scripts on a UNIX station.

The MGX 8230 hardware faults are identified by a combination of network element name, shelf number, slot number, port number and front or back cards. This helps the operators or craft personnel to easily locate the hardware unit and to perform diagnostics or hardware replacement actions.

Alarms and problem reports are sent to the following files or devices.

• Local Craft terminal

• Problem log

• Alarm log

• Alarm panel

• Remote peripheral device

Performance ManagementThe switch fabric provides real-time counters for performance monitoring as well as debugging. The real-time statistics are collected for four object types:

• Connections

• Ports

• Interfaces (Lines)

• Trunks

For each object there can be several sub-objects (types of lines, ports,and so on.), and for each sub-object type, there are several statistics.

PXM 1

The following counters are provided for PXM1:




• Sonet Line and Trunk Counters

– Section Counter LOS

– Section Counter LOF

– Path Counter AIS

– Path Counter RFI

– Line Counter AIS

– Line Counter RFI

• PLCP Counters

– dsx3PlcpRcvOOFCount

– dsx3PlcpRcvRAICount

– dsx3PlcpFECount

– dsx3PlcpFEBECount

– dsx3PlcpFEBESecCount

– dsx3PlcpSEFEBESecCount

– dsx3PlcpHECCount

– dsx3PlcpHECSecCount

– dsx3PlcpSEHECSecCount

• DS3 Counters

– dsx3LCVCurrent

– dsx3LESCurrent

– dsx3LSESCurrent

– dsx3PCVCurrent

– dsx3PESCurrent

– dsx3PSESCurrent

– dsx3SEFSCurrent

– dsx3AISSCurrent

– dsx3UASCurrent



– dsx3PlcpFECount







– dsx3RcvLOSCount

– dsx3RcvOOFCount




– dsx3RcvRAICount

– dsx3FECount

– dsx3PlcpBip8CVCurrent

– dsx3PlcpBip8ESCurrent

– dsx3PlcpBip8SESCurrent

– dsx3PlcpSEFSCurrent

– dsx3PlcpUASCurrent

• ATM Counters—Ingress

– Number of cells received with CLP = 0 on a connection

– Number of cells received with CLP = 1 on a connection

• ATM Counters—Egress

– Number of cells received on a connection

– Number of cells transmitted on a connection

– Number of cells received on a connection with EFCI bit set

– Number of cells transmitted on a connection with EFCI bit set

• On the broadband interfaces on PXM1, the counters available are

– Number of cells received from the port

– Number of valid OAM cells received

– Number of RM cells received

– Number of cells received from the port with CLP = 0


– Number of cell with CLP=0 discarded

– Number of cell with CLP=1 discarded

– Number of OAM cells transmitted

– Number of RM cells transmitted

– Number of cells transmitted for which CLP bit was set

– Number of cells transmitted for which CLP bit was not set

• For each connection on the PXM1, the counters available are:



– Number of cells that were non-conforming at the GCRA-1

– Number of cells that were non-conforming at the GCRA-2

– Number of cell with CLP = 0 received from port and discarded

– Number of cell with CLP = 1 received from port and discarded

– Number of cells transmitted (to cell bus or towards trunk card)

– Number of cells transmitted for which EFCI was not set

– Number of cells transmitted for which EFCI was set

– Number of cells with CLP = 0 toward port that were discarded




– Number of cells with CLP = 1 toward port that were discarded

– Number of EOF cells received

SRM-3T3/B

The following counters are provided for SRM-3T3/B:

• dsx3LCVCurrent

• dsx3LESCurrent

• dsx3LSESCurrent

• dsx3PCVCurrent

• dsx3PESCurrent

• dsx3PSESCurrent

• dsx3CCVCurrent

• dsx3CESCurrent

• dsx3CSESCurrent

• dsx3SEFSCurrent

• dsx3AISSCurrent

• dsx3UASCurrent

• dsx3RcvLOSCount

• dsx3RcvOOFCount

• dsx3RAICount

• dsx3FECount

• dsx3RcvFEBECounter

• dsx3RcvEXZCounter

High-Speed FRSM

The following counters are provided for high-speed FRSM cards:

• DS1 Alarm Stats

– statDsx1LCVCurrent

– statDsx1LESCurrent

– statDsx1LSESCurrent

– statDsx1CRCCurrent

– statDsx1SEFSCurrent

– statDsx1AISSCurrent

– statDsx1UASCurrent

• DS1 Counter Stats

– statDsx1RcvLOSCount

– statDsx1RcvOOFCount




– statDsx1RcvRAICount

– statDsx1RcvFECount

• DS3 Alarm Stats

– statDsx3LCVCurrent

– statDsx3LESCurrent

– statDsx3LSESCurrent

– statDsx3PCVCurrent

– statDsx3PESSCurrent

– statDsx3PSESSCurrent

– statDsx3SEFSCurrent

– statDsx3AISSCurrent

– statDsx3UASCurrent

• DS3 Counter Stats

– statDsx3RcvLOSCount

– statDsx3RcvOOFCount

– statDsx3RcvRAICount

– statDsx3RcvFECount

Frame Relay

The following counters are provided for Frame Relay cards:

• Port Counters

– statPortRcvFrames

– statPortRcvBytes

– statPortRcvFramesDiscCRCError

– statPortRcvFramesDiscIllegalHeader

– statPortRcvFramesDiscAlignmentError

– statPortRcvFramesDiscIllegalLen

– statPortRcvFramesUnknownDLCI

– statPortRcvFramesDiscXceedDEThresh

– statPortXmtFrames

– statPortXmtBytes

– statPortXmtFramesFECN

– statPortXmtFramesBECN

– statPortXmtFramesDiscXceedQDepth

– statPortXmtBytesDiscXceedQDepth

– statPortXmtFramesDuringLMIAlarm

– statPortXmtBytesDuringLMIAlarm




– statPortRcvStatusInquiry

– statPortRcvInvalidRequest

– statPortRcvUNISeqMismatch

– statPortXmtStatus

– statPortXmtAsynchUpdate

– statPortUNISignallingTimeout

– statPortXmtStatusInquiry

– statPortRcvStatus

– statPortRcvAsynchUpdate

– statPortRcvNNISeqMismatch

– statPortNNISignallingTimeout

• Channel Counters

– statChanRcvFrames

– statChanRcvBytes

– statChanRcvFramesDE

– statChanRcvBytesDE

– statChanRcvFramesDiscard

– statChanRcvBytesDiscard

– statChanRcvFramesDiscXceedQDepth

– statChanRcvBytesDiscXceedQDepth

– statChanRcvFramesDiscXceedDEThresh

– statChanXmtFrames

– statChanXmtBytes

– statChanXmtFramesFECN

– statChanXmtFramesBECN

– statChanXmtFramesDE

– statChanXmtFramesDiscard

– statChanXmtBytesDiscard

– statChanXmtFramesDiscXceedQDepth

– statChanXmtBytesDiscXceedQDepth

– statChanXmtFramesDiscCRCError

– statChanXmtFramesDiscReAssmFail

– statChanXmtFramesDuringLMIAlarm

– statChanXmtBytesDuringLMIAlarm

– statChanRcvFramesDiscUPC

– statChanXmtBytesTaggedDE

– statChanXmtFramesTaggedDE

– statChanXmtFramesInvalidCPIs




– statChanXmtFramesLengthViolations

– statChanXmtFramesOversizedSDUs

– statChanXmtFramesUnknownProtocols

– statChanRcvFramesUnknownProtocols

– statChanSecUpTime

– statChanRcvBytesTaggedDE

– statChanRcvFramesTaggedDE

– statChanRcvBytesTaggedDE

– statChanRcvFramesTaggedDE

FRSM-T1E1

The following counters are provided for FRSM-T1E1 cards:

• Frame Relay Port Counters

– Received frames discarded due to Aborts

– Received frames discarded due to illegal header (EA bit)

– Received frames discarded due to CRC errors

– Received frames discarded due to alignment errors

– Received frames discarded due to unknown DLCI

– Received frames discarded due to illegal frame length

– Received frames discarded due to DE threshold exceeded

– Received frames with DE already set

– Received frames with FECN already set

– Received frames with BECN already set

– Received frames tagged FECN

– Received frames

– Received bytes

– Transmit frames discarded due to underrun

– Transmit frames discarded due to Abort

– Transmit frames discarded due to egress Q-depth exceeded

– Transmit bytes discarded due to egress Q-depth exceeded

– Transmit frames discarded due to egress DE threshold

– Exceeded Transmit frames

– Transmit bytes

– Transmit Frames with FECN set

– Transmit Frames with BECN set

– LMI receive status inquiry request count

– LMI transmit status inquiry request count




– LMI invalid receive status count

– LMI signaling protocol (keep alive time-out count)

– LMI sequence number error count

– LMI receive status transmit count (in response to request)

– LMI transmit status transmit count (in response to request)

– Transmit frames during LMI alarm

– Transmit bytes during LMI alarm

– LMI update status transmit count (in response to configuration changes)

• Frame Relay Channel Counters

– Number of frames received

– Number of bytes received

– Number of frames received with DE already set

– Number of bytes received with DE already set

– Number of frames received with unknown DLCI

– Number of frames received but discarded

– Number of received bytes discarded

– Number of received bytes discarded due to exceeded Q-depth

– Number of frames received and discarded due to intershelf alarm

– Exceeded DE threshold

– Exceeded Q depth

– Number of frames received with FECN set

– Number of frames received with BECN set

– Number of frames received tagged FECN

– Number of frames received tagged BECN

– Number of frames transmitted

– Number of bytes transmitted

– Number of frames transmitted with DE set

– Number of frames discarded due to reassembly errors

– Number of frames transmitted during LMI logical port alarm

– Number of frames transmitted with FECN set

– Number of frames transmitted with BECN set

– Number of transmit frames discarded

– Number of transmit bytes discarded

– Number of transmit frames discarded due to CRC error

– Egress Q depth exceeded

– Egress DE threshold exceeded source abort

– Physical link failure (T1)

• ATM Cell-Related Counters




– Number of cells transmitted to PXM

– Number of cells transmitted with CLP bit set

– Number of OAM AIS cells transmitted

– Number of OAM FERF cells transmitted

– Number of BCM cells transmitted

– Number of OAM end-end loopback cells transmitted

– Number of OAM segment loopback cells transmitted

– Number of cells received from PXM

– Number of cells received with CLP bit set

– Number of OAM AIS cells received

– Number of OAM FERF cells received

– Number of BCM cells received

– Number of OAM end-end loopback cells received

– Number of OAM segment loopback cells received

– Number of OAM cells discarded due to CRC-10 error

AUSM/B

The following counters are provided for AUSM/B:

• Line Counters

– LOS occurrences

– OOF occurrences

– Remote loss of signal/frame (RAI) occurrences

– All ones received (AIS) occurrences

– Bipolar violation occurrences

– Cyclic redundancy check (CRC) error occurrences

– Line code violation (LCV)

– Line errored second (LES)

– Line severely errored second (LSES)

– Code violation (CV)

– Errored Second (ES)

– SES

– SEFS

– AISS

– UAS

• Port Counters (IMA ports)

– Number of cells received from the port

– Number of cells received with unknown VPI/VCI




– Last unknown VPI/VCI received

– Number of cells discarded due to error in cell header

– Number of cells received with nonzero GFC field

– Number of cells transmitted to the port

– Number of cells transmitted for which EFCI was set

– Number of egress cells discarded because of service interface physical layer alarm

• Channel Counters—Ingress

– Number of cells received from the port on the virtual connection (VC)

– Number of cells received with CLP = 1

– Number of cells received with EFCI = 1

– Number of cells received but discarded because queue exceeded queue depth

– Number of cells received but discarded because queue exceeded CLP threshold

– Number of cells received for which CLP was set because of UPC violations

– Peak queue depth

– Number of cells transmitted to cell bus

– Number of cells transmitted to cell bus for which EFCI was set

– Number of cells for transmission to cell bus discarded because of shelf alarm

– Number of OAM cells received and discarded

– Number of AIS cells received

– Number of RDI FERF cells received

– Number of segment loopback cells received

– Number of segment loopback cells transmitted to cell bus

• Channel Counters—Egress

– Number of cells received from cell bus for this virtual circuit


– Number of cells discarded because queue exceeded queue depth (per egress queue)

– Number of cells discarded because queue exceeded CLP threshold (per egress queue)

– Number of OAM cells discarded

– Number of AIS cells transmitted to port

– Number of segment loopback cells transmitted

– Number of segment loopback cells received from cellbus

CESM-T1E1

The following counters are provided for CESM-T1E1:

• Line Counters

– FEBE count

– OOF count




– LCV count

– FER count

– CRC error count

• AAL1 SAR Counters

– Number of OAM cells received

– Number of OAM cells dropped FIFO full

– Number of SN CRCs not correctable

– Number of cells with SN different from SN+1

– Number of cells received from UTOPIA interface

– Number of cells transmitted to UTOPIA interface

• ATM Layer Counters

– Number of cells transmitted

– Number of cells transmitted with CLP bit set

– Number of AIS cells transmitted

– Number of FERF cells transmitted

– Number of end-to-end loopback cells transmitted


– Number of cells received

– Number of cells received with CLP bit set


– Number of FERF cells received

– Number of end-to-end loopback cells received


– Number of OAM cells discarded because of CRC-10 error

CESM-T3E3

The following counters are provided for CESM-T3E3:

• DS3 Line Group

– Dsx3LCVCurrent

– Dsx3LESCurrent

– Dsx3LSESCurrent

– Dsx3UASCurrent

– Dsx3RcvLOSCount

• Channel Counters

– CesReassCells

– CesGenCells

– CesHdrErrors




– CesSeqMismatchCnt

– CesLostCells

– CesChanSecUpTime

– XmtCellsFERF

– RcvCellsFERF

– XmtCellsAIS

– RcvCellsAIS

– XmtCellsSegmentLpBk

– RcvCellsSegmentLpBk

– RcvCellsDiscOAM

The MGX 8230 is capable of transmitting status reports to the Element Management layer on CWM and CiscoView. All the information about the element can be maintained in the status reports including information on switching matrix modules, interfaces, and utilization of the element.

The MGX 8230 can send a full inventory report to the EM layer concerning the modules that make up its structure, including the hardware revisions and serial numbers, and the associated operating software.

The MGX 8230 supports the capability to schedule the performance counters in 5, 10, 15, 30, and 60 minute intervals, as far as data collection is concerned. The data-collection intervals (commonly known as polling cycles) can be 15 minutes, 30 minutes, or 60 minutes. These performance data counters can be aggregated at the Cisco WAN Manager to generate daily reports.

Security ManagementWhen the user logs into a MGX 8230 node, the uer is required to supply the user ID and password and the slot to direct input to. When the operator adds a new user, he/she has to specify the user ID and the access level. The choices for the privilege are GROUP1, GROUP2, GROUP3, GROUP4, GROUP5, or ANYUSER.

Each telnet session may be terminated by the user or by a timer, whose timer value is determined when the session is established. The timer signals the telnet connection to be terminated if the user does not provide any input for a certain period of time.

In contrast to every other service module in the MGX 8230, the RPM will be driven by the IOS CLI. RPM also requires the user to log in again using a different User ID and password. This IOS like authentication provides an initial entry to the router. Further authentication is required if the user needs access to more privileged commands

On the MGX 8230 platform, the UserID/Password is stored in the disk database. Currently UserID/Password is not encrypted.

Accounting Management

Statistics are collected periodically by the MGX 8230. The Cisco WAN Manager allows usage data collection from network connections and interfaces for innovative usage-based billing to customers.

The MGX 8230 will maintain CDRs for PVCs. The following information is contained in the CRDs:

• PVC type CBR, VBR-RT, VBR NRT, ABR, UBR

• Traffic descriptor



Chapter 6 Network ManagementEmbedded Management Interfaces

• QoS parameters

• Traffic volume number of cells

• Date/time window (period) in which data were measured

Embedded Management InterfacesThis section is divided into two subsections.

• Simple Network Management Protocol (SNMP)

• Command Line Interface (CLI)

SNMPThe Cisco WAN Manager, which integrates with HPOV, provides a complete and robust SNMP network management platform with a graphical user interface (GUI).

The WAN Manager Event Log displays descriptions of network- and operator-generated occurrences. Internally, event descriptions are generated as a result of the trap information, which transpires between the network management system and the network agents. Simple Network Management Protocol (SNMP) processes controls these traps.

An SNMP agent is software that is capable of answering valid queries from an SNMP station (such as the Cisco WAN Manager workstation), about information defined in the Management Information Base (MIB). A network device that provides information about the MIB to Cisco WAN Manager has an SNMP agent. Cisco WAN Manager and the SNMP agents exchange messages over the network's transport layer protocol.

Command Line InterfaceThe MGX 8230 Control Point Software provides a single and integrated point of control for managing the platform. It provides full-shelf and interface management for all hardware modules, service provisioning, and fault finding/diagnostic support for the complete shelf.

The preferred tools for configuring, monitoring, and controlling an MGX 8230 edge concentrator are the CiscoView and Cisco WAN Manager applications for equipment management and connection management, respectively.

The command line interface (CLI) is highly applicable during initial installation, troubleshooting, and any situation where low-level control is useful.

Each command falls into a range of command privilege levels. When a user ID is created, it is assigned a privilege level and can issue commands allowed by that level only.

The MGX 8230 provides the following CLI features:

• CLI access through serial console port on PXM

• CLI access through serial modem port on PXM

• CLI access through Ethernet port on PXM

• Maximum number of simultaneous CLI telnet sessions is 10

• Complete CLI support for PXM platform software including SRM-3T3/B functions.



Chapter 6 Network ManagementManagement Tools

• Complete set of CLI commands for RPM

• Complete set of CLI commands on the following service modules: FRSM (8T1/E1, HS1/B, HS2, 2T3/E3, CT3), CESM (8T1/E1, T3/E3), AUSM/B (8T1/E1)

The standard telnet command that is available from both the HPOV's topology map and the CWM topology map supports telnet access to the MGX 8230. The telnet session will give the user access to the PXM card. From the PXM card, the user will be able to navigate to the desired service module by entering the cc command.

Management ToolsThis section has been split into the following four sections.

• CiscoView

• Cisco WAN Manager

• Cisco Info Center

• Cisco Provisioning Center

CiscoViewCiscoView is a GUI-based device management software application that provides dynamic status, real-time counters, and comprehensive configuration information for the Cisco internetworking products (switches, routers, concentrators, and adapters). CiscoView graphically displays a real-time physical view of Cisco devices. Additionally, this SNMP-based network management tool provides monitoring functions and offers basic troubleshooting capabilities.

Using CiscoView, users can easily understand the tremendous volume of management data available for internetworking devices, because CiscoView organizes it into graphical device representations presented in a clear, consistent format.

CiscoView will be used as the element management tool for the MGX 8230. CiscoView interacts directly with the edge concentrator agent.

CiscoView software can be integrated with several of the leading SNMP-based network management platforms, providing a seamless, powerful network view. It is also included within CW2000. CiscoView software can also be run on UNIX workstations as a fully functional, independent management application.

The key functions are

• Graphically displays the MGX 8230 from a centralized network management location, giving network managers a complete view of the MGX 8230 and the other Cisco products in the network without physically checking each device at remote sites

• Oriented for exception reporting, allowing users to quickly grasp essential inquiry information

• GUI that shows a continuously updated physical picture of the MGX 8230 service modules and other physical components including the routers, hubs, or access servers in the network

• Can be invoked several times in the same session to simultaneously support multiple switches, routers, hubs, or access servers




• CiscoView displays two primary types of information:

– Configuration information includes data such as information about a device chassis, controller card and interface cards. It is displayed in CiscoView Configuration windows.

– Performance information includes data such as the number of Ethernet errors during a given period. It is displayed in CiscoView Monitor windows, which are also referred to as dashboards.

• Can be integrated with the following network management platforms to provide a seamless and powerful system to manage Cisco devices:

– OpenView

– IBM NetView for AIX

Cisco WAN ManagerCisco WAN Manager (previously known as StrataView Plus) is an SNMP-based multiprotocol management software package designed specifically for wide-area multiservice networks. It provides integrated service management and process automation to simplify the management of even the most complex networks. The Cisco WAN Manager allows you to easily monitor usage, provision connections, detect faults, configure devices, and track network statistics.

Cisco WAN Manager is designed to address the significant demands of managing and operating next-generation wide-area multiservice networks. The multiservice environment is more complex, with a greater number of connections and wider variety of services, making the administration of the network a potentially impossible task without the right tools.

The following features are available with Cisco WAN Manager:

• Scalability—Today, wide-area multiservice networks may start out as a network with few nodes but can grow into a network with several hundreds nodes. Cisco WAN Manager is optimized for scalability and is designed to scale as the network grows in both enterprise and service provider environments.

• Management and Operations—The complexity of current wide-area multiservice networks demands the right tools to manage and administer the network. Cisco WAN Manager software provides powerful fault, configuration, and performance management capabilities for the wide-area multiservice network. A user-friendly, graphics-oriented interface running under HP OpenView for Solaris platforms, IBM NetView for AIX, and HPOV for HP-UX platforms lets network managers quickly provision new services and view the entire network at once to identify and isolate network problems.

• Service Management API and Integration—Seamless integration into an existing network management environment is critical in providing end-to-end service management. Cisco WAN Manager Service Agent provides an SNMP interface for network and service layer management views and control. This feature enables automated provisioning and fault management and provides a basis for other higher-level service management applications. These applications are Service Management applications, service provider’s Operations Support Systems (OSS), or other third party vendor value-added applications. With this interface, Cisco WAN Manager can seamlessly integrate into the customer’s network management environment.

• Performance and Capacity Management—As the cost of high-speed wide-area networks (WANs) increase with bandwidth, there is greater demand for performance and capacity planning, and cost justification and allocation. Cisco WAN Manager Statistics Agent software collects comprehensive network statistics for cost allocation, performance management, and capacity planning. The




Statistics Agent uses TFTP, which is optimized for bulk data transfer, and can upload in excess of three million usage statistics per hour per agent. The data is then stored in a standard SQL database for historical reporting and trend analysis.

Layer 2/Layer 3 Connection Management will be enhanced to support RPM as one of the ATM end points in end-end connection setup. CMProxy (Service Agent) will be enhanced to support this functionality. RPM port provisioning will not be supported via PortProxy.

Cisco Info CenterCisco Info Center is a real-time, high-performance service-level monitoring and diagnostic tool that provides network fault monitoring, trouble isolation, and real-time service-level management for multitechnology, multivendor networks. Cisco Info Center is designed to help operators focus on important network events, offering a combination of filtering, alarm reduction rules, flexible alarm viewing, and partitioning. It enables service levels to be specified and monitored, providing valuable insight into SLA conformance. Customer, VPN, and administrative partitioning and distribution of information are also supported by Cisco Info Center, further enhancing the service providers' ability to manage the network and extend SLA monitoring capabilities to their customers. For example, a fault on an ATM trunk or change in an ATM grooming parameter may affect an IP VPN service. Using Cisco Info Center, a network operator is able to quickly focus on service-affecting alarms and understand both the services and customers affected by the fault. Service providers can also use Cisco Info Center's information partitioning capabilities to make this information available to their customers via the web as an added service dimension.

Key Benefits

The key benefits of the Cisco Info Center are

• Simplified Operations—By integrating alarms and events from multiple technologies and vendors into a single environment, operators have to learn and use only one platform for troubleshooting and diagnostics. Automation helps reduce the amount of manual effort required to resolve problems.

• Scalable and Highly Distributable Architecture—Distributed client/server architecture allows for configuration of distributed multimanagement domains. Data filtering and deduplicating features let operators monitor domains by workgroups, geographies, or customer ID.

• Immediate Return On Investment—Consolidates fault data from multivendor multi-technology systems enabling efficient and timely resolution of network problems and reduced operations cost.

• Enhanced Service Offering—This feature supports web/Java-based service-level monitoring applications developed by service providers so end-customers have ready access to their portion of the network.

• Integrated Layer 2 and Layer 3 Monitoring—Facilitates intelligent resource and service assurance monitoring with consolidated event and alarm management across the entire network, enabling end-to-end service management support.

• Powerful Administrative Interface—Highly customizable to suit a network manager's specific viewing requirements. Java and web-based front-end support enables operators to use Web technologies for integrated fault management and transfer of information to customers to prove compliance with service-level agreements (SLA).




• Highly Customizable Event Correlation Engine—Empowers the operators to interpret data, while event-triggered actions can be configured to respond to certain behaviors automatically. The flexible rules can beenhanced dynamically to enable the creation of new automation rules (event-triggered actions) based on observed network behavior and combination of events. These new rules can then trigger user-defined actions such as execution of auto-diagnostic scripts.

• Information Overload—Operators must analyze data to determine the status of a network element or a Class of Service. Cisco Info Center is capable of consolidating, partitioning, and correlating information to present the core fault data in a way that is easy to interpret.

• Multi vendor Networks—Cisco Info Center is capable of receiving multiple data streams, independent of the underlying network element technology, providing a comprehensive centralized fault management center.

Cisco Provisioning CenterThe Cisco Provisioning Center (CPC) makes delivering services to subscribers quick and easy with a rapid, error-free means of provisioning the network infrastructure. By integrating with a service order management system, Cisco Provisioning Center dramatically reduces the costs and time-to-market issues associated with service deployment by using flow-through service provisioning. For example, CPC provides powerful capabilities to automatically map a multitechnology VPN service to various underlying QoS parameters including Weighted Fair Queuing (WFQ) and Committed Access Rate (CAR) in Layer 3 and available bit rate (ABR) and constant bit rate (CBR) services in Layer 2 ATM.

Another unique feature of Cisco Provisioning Center is a service validation step that is tightly integrated into the multiphase commit process. This automated step ensures that a requested service such as premium Internet access can be provided by the network prior to committing it to deployment. This reduces rollbacks and ensures the operational integrity of the service provisioning process while enabling rapid, error-free service deployment. This automated step is essential for “self-service” provisioning by customers through a Web interface.

Key Benefits

Automated, integrated provisioning with CPC offers several key benefits, including:

• Rapid deployment of integrated L2/L3 services such as VPN and customer network management (CNM) by maintaining a database that associates customers with network elements and the services they are providing

• Higher-quality deployment through automation improves service quality over error-prone, manual deployment methods

• Lower operation costs through improved efficiency

• Reduced training costs because less expertise is required

• Faster time to market through automation features that simplify deployment

• True end-to-end provisioning through future integrated L2/L3 provisioning capability across multiple platforms from multiple vendors

Multilayer, Multivendor Provisioning

As an integrated L2/L3 tool, CPC supports not only provisioning of Cisco equipment end to end but also supports third-party blades for Newbridge and Ascend/Lucent. A blade is a generic interface between CPC and element managers. The support and acquisition of other vendor blades are attainable through




Cisco partner Syndesis, Ltd. Flow-through APIs enable integration with existing service OSS and CNM systems for order management, billing, and capacity planning for lower time to market and reduced cost of service. Operators have a choice of defining a service in technology and equipment-neutral terms for transparent deployment across a variety of equipment, or equipment-specific terms for services that take full advantage of specific element features.

Objects Reflect Services for Activation

CPC offers customer-extensible service. Each service offered by a provider is represented by a unique service object. Service objects allow operators to view the network in terms of end-user or subscriber services, or by a traditional set of nodes, ports, and circuits. Complex configuration changes are grouped into simple units that align with subscriber service orders. This grouping simplifies and accelerates order processing and improves order consistency.

Rapidly Build Service Objects

CPC supports the rapid customization of new services, so providers can quickly develop and deploy new kinds of service by defining new classes of service object. Service objects can be added, deleted, and modified in single global operations which CPC breaks down into elementary actions on individual subnets or equipment. Decisions about how a service should be laid in are made by CPC and can be viewed by network operators or OSS applications. CPC ensures that the operation is applied successfully to all elements of the network in a coordinated manner. If any elementary action fails, then the entire operation is automatically rolled back and the original configurations are restored.

Centralized Database and Network Model

CPC is based on client/server architecture to support distributed computing through relational database systems. CPC runs under UNIX on Informix Version 7 and above and Solaris 2.5.1 and above. The distributed architecture allows CPC to address a full range of service provider capacity and throughput requirements.

The CPC database contains both the current state of the network configuration plus pending changes in the process of being deployed. A CPC administrator can view these events and decide when to upload topology information, or automated scripts can automatically upload the information.

Open Flow-Through Interfaces

Automated configuration is available using the flow-through interface, which allows provisioning and order processing applications to make high-level calls for configuration services. CPC can communicate with other applications via the flow-through interface using UNIX shell scripts, Java applets, or CORBA middleware.

The flow-through interface allows CPC to become an integral component of a service provider's total service creation and management system. Orders can flow directly from an existing order processing or customer care system into CPC for immediate service activation. Operators can view services, components of services, network connections, transactions, network elements, change requests, and logs.




Reliable Service Activation

CPC is based on advanced change management features that provide unprecedented reliability and control over service activation. All configuration changes associated with the same change to a service are applied in a single, network-wide transaction. Each change begins as a change request (CR) and includes an associated audit log.

The CPC database tracks resource allocation so that other system components always know what is available. When a service is created, service threaders use the resource and topology information to find the optimal end-to-end path through the network that satisfies a specified QoS level. Using this generic functionality, CPC-based systems can support features such as load sharing among Network-to-Network Interface (NNI) links and failure recovery based on the subscribed class of service (CoS).

As an application, CPC sits in the network and service management layers of the TMN model. Element managers are used by CPC through blades, which take advantage of the element manager as a configuration delivery mechanism.

Element Managers

Element managers such as Cisco WAN Manager, Cisco IP Manager, and Cisco Access Manager provide access to a specific type of equipment such as a suite of switching nodes from a particular vendor. Also called blades, element managers encapsulate specific knowledge about the equipment and translate it into an equipment-neutral representation. A blade can support a specific product, a subset of a vendor's entire product set, or the entire product set of a vendor. It can make use of other products such as the equipment manufacturer's own provisioning server to access network elements. CPC third-party blades for Newbridge and Cascade are attainable through Cisco partner Syndesis, Ltd.

To create a complete and working application, blades enable the CPC engine to configure all of the network elements that participate in providing a service. Services that span multiple equipment types require more than one blade.

When blades are installed in a system, subnetwork resources are published to the CPC database so that threaders can construct end-to-end services based on network policies. Threaders choose the best path after considering variables such as QoS requirements, total bandwidth consumption, under-utilized internetworks links, and lowest overall cost.

C H A P T E R



7Traffic Management

MGX 8230 traffic management features are designed to minimize congestion while maximizing the efficiency of traffic routing. Parameters such as minimum cell rate (MCR), committed information rate (CIR), committed port rate (CPR), and committed delivery rate (CDR) provide deterministic performance and fairness for each VC and for each service class.

The MGX 8230 platform reserves queues specifically for IP traffic, and uses queuing and prioritizing algorithms to enhance the standard CoS offerings, which include:

• Class of service (CoS) support (hardware support for 16 CoS, firmware support for CBR, VBR-RT, VBR-NRT, ABR-FS, ABR-STD, UBR)

• QoS setting for each connection

• Per-VC queuing

• Priority queuing

• Congestion control mechanisms (ForeSight, Standard ABR, EFCI Tagging, Explicit Rate)

• Frame-based discards (EPD and PPD)

• CLP hysteresis

• UPC/contract enforcement

• Connection admission control

• Leaky bucket and GCRA policing schemes

Traffic Management FunctionsOn the MGX 8230, the traffic management functions are performed in two separate locations:

1. In service modules (including the virtual service module that handles the PXM 1 broadband interfaces)

The following traffic management functions are performed on service modules and the VSM:

– CAC (done at the time of provisioning connections)

– Policing (ingress only)

– Ingress VC-queue-related traffic management functions (only for service modules, not available on VSM)

– Egress port-queue-related traffic management functions (only for service modules, not available on VSM)



Chapter 7 Traffic ManagementTraffic Management Functions

2. Switch fabric's queue engine on PXM 1

The queue engine (QE) ASIC provides the traffic management functions related to VC queues, QoS queues, and interface queues. This is done for both directions of traffic. The PXM 1 card can have up to four physical lines. The user can split the line resources into multiple logical ports up to a maximum of 32. The switching fabric maps each of these logical ports defined on the PXM 1 lines to what is termed a virtual interface (VI). The switching fabric also maps each service module slot to a virtual interface.

Figure 7-1 reflects functional flow of data passing through the PXM 1 switch fabric and daughter card.

Figure 7-1 PXM Switch Fabric

Ingress traffic is defined as data flowing toward the switch fabric. Ingress data can come from either the service modules through the backplane or the PXM 1 uplink back card.

Egress traffic is defined as data flowing away from the switch fabric.

Ingress data from service modules arrives at the PXM 1 via the cell bus and hits the switch fabric, where the VC and Qbin queueing occurs. The destination of this traffic defines which VI queue it will be placed into. Ingress data from the PXM 1 will first be channeled through the uplink daughter card where policing will occur. The uplink ingress data will then pass through the switching fabric and the same VC, Qbin, and VI queuing will occur.

Figure 7-2 shows in detail the ingressl traffic flow. Figure 7-3 shows the Switch Module to Switch Fabrication arbitration. Figure 7-4 shows Egress Traffic Management.

4303

2

SMEgress port Qs

SMEgress port Qs

SMVCQs

Policing

SM to SM

SM to Uplink

PXM user portto any

broadband

PXM userport to SM

SM

Policing

RCMP(Policing)

VSM Port 1

CELLBUS

CELLBUS

VI QQB inVC Q

VCQs

Port 2VSM(no egress Qs)



Chapter 7 Traffic ManagementTraffic Management Functions

Figure 7-2 Ingress Traffic Management

Figure 7-3 Service Module to Switch Fabric Arbitration

4303

3

Ports Policing

Round-robinQ servicing

VCQs

max

ForeSight

ABREPDPPD

CellBusQ

4303

4

FRSM

FRSM-HS

AUSM-8

PXM-Trk

PXM-UNI

RPM

CESM

CBC arbitration

VCQs

Anyto

any

Anyto

any

max

VIsQs

32

16

CoS Qs

16

CoS Qs



Chapter 7 Traffic ManagementConfigurable Traffic Parameters

Figure 7-4 Egress Traffic Management

Configurable Traffic ParametersThere are four groups of traffic management parameters that are configured for each connection:

1. Policing Parameters are applied in service modules and the VSM (virtual service module). These are effective for the ingress traffic coming into the service modules/VSM. Following parameters are examples:

– AUSM/B

pcr

scr

ibs

mbs

ingrUpcFGCRAEnable

cdvt

scrPolicingEnable

– FRSM

cir

bc

be

4303

5

CoSQs

CellBusQ

CellBusQ

VIQs

SAR

max

max

CoSQs



Chapter 7 Traffic ManagementConfigurable Traffic Parameters

ibs

– CESM

None used

– PXM 1-BBIF (Broadband Interface-VSM)

pcr

scr

cdvt

mbs

scrPolicingEnable

2. The second group of parameters controls the VC queue properties in the service modules. These parameters also apply to the ingress traffic only. Please note that this set of parameters does not apply to VSM since it does not have VC queuing capability. Examples of parameters include:

– AUSM/B

ingressQDepth

ingressClpHiThresh

ingressClpLoThresh

ingressEFCITHresh

Discard option

– FRSM

ingressQDepth

ingressQDEThresh

ingressQECNThresh

– CESM

None used

– PXM 1-BBIF (Broadband Interface-VSM)

None used

3. The third set of parameters controls the properties of VC queues and QoS queues in the PXM 1. These parameters are applicable to both directions of traffic. These parameters are not set on a per-connection basis. Rather, they are controlled/managed through customer-configurable service templates (not currently implemented). The concept of a service template allows customers to define a set of service classes by fine-tuning the VC queue and QoS queue parameters. These templates are configured once in the system. At the time of connection, provisioning each connection is associated with one of the classes through the “service type” MIB object. The queue parameters configured for that service type are then applied to that connection in the QE. Thus, a finite sets of queue parameter combinations are defined in the beginning. The user can choose one predefined set of parameter combinations for each connection to be provisioned.

Currently, the service templates are not implemented in the MGX 8230 platform. The VC queue parameters are currently defaulted as follows for all connections:

– VC Depth is set to 50 percent of maximum cell memory in QE

– ClpHiThreshold is set to 80 percent of VC Depth

– ClpLoThreshold is set to 60 percent of VC Depth



Chapter 7 Traffic ManagementConnection Admission Control

– EfciThreshold is set to 30 percent of VC Depth

4. The fourth set of parameters selects the egress service queue type for the traffic leaving the system through service modules. This does not apply to Virtual Servide Module (VSM) because it does not have any egress service queues. Examples of these parameters include:

AUSM/B

– egressQDepth

– egressClpHiThresh

– egressClpLoThresh

– egressEFCIThresh

– egressQAlgorithm

FRSM

– egressQSelect

– egressQDEThresh

– egressQECNThresh

CESM

– Cdvt

– EgressQDepth

VSM

None used

Connection Admission ControlConnection Admission Control (CAC) is performed on-port in the ingress and egress directions. Port overbooking is optionally supported on both the FRSM and the AUSM/B. The CAC override function is configurable on a per-connection basis.

1. For AUSM/B, PXM 1, and FRSM, CAC admits a new connection if the following holds true:

• Σ (Ingress_ER x (%Ingress_Util)) <= Ingress port speed. One port

• Σ (Egress_ER x (%Egress_Util)) <= Egress port speed. One port

• Overbooking = 1/(%ingress_Util)

2. For CAC on FRSM-8T1E1

Ingress (when CAC override is off or CAC is enabled):

• sum of (CIR * chanIngrPercentUtil) of all channels on the port < = port speed

Egress:

• sum of (chanEgrSrvRate * chanEgrPercentUtil) of all channels on the port < = port speed

When CAC overide is ON or CAC is disabled, the load is still cumulated on the port for a channel, but it is always admitted if CIR/chanEgrSrvRate is less than port speed.

3. For CAC on AUSM/B-8T1E1

For the ingress rate, ingrUpcPCR01 is used for CBR/VBR and UBR, and foresightMIR is used for ABR. For the egress side, the rate used is ausmChanEgrSrvRate.



Chapter 7 Traffic ManagementPolicing

CAC Algorithms:

• Ingress side

– if Σ(ingrRate * ingr pct util) > PORT_RATE, CAC fail.

– if Σ(ingrRate * ingr pct util > Rate available for that controller, CAC fail.

• Egress side

– If Σ(egrRate * egr pct util)> PORT_RATE, CAC fail.

– if Σ(egrRate * egr pct util)> Rate avail. for that ctrlr, CAC fail.

• For the rest of the cases, CAC passes.

– In case ausmChanOvrSubOvrRide is enabled, even though CAC fails, connection addition goes through.

PolicingThe edge concentrator complies with the UPC policing standards as defined by the ATM Forum UNI 3.1 Specifications. The following are the traffic descriptors configurable on a per-connection basis:

• PCR, SCR, MCR, BT, CDVT

• Policing algorithm can be enforced on the following cell types:

– User

– Resource management

– CLP0

– CLP1

– Any combination of the cell types (User, RM, CLP0, CLP1)

• Single and dual leaky bucket policing schemes

• Configurable actions for nonconforming cells

– Keep count

– Tag nonconforming cells

– Tag and discard low-priority cells

– Frame-based discards (early packet and partial packet discard)

– Tag and discard all non-conforming cells

– CLP hysteresis

Configuring Traffic DescriptorsFor AUSM/B modules different bandwidth control parameters can be defined depending on the type of connection. For CBR and UBR connections, PCR and CDVT are specified. For VBR and ABR connections, and PCR and CDVT, SCR and BT are specified. Table 7-1shows the different parameters that can be defined during connection setup. It also indicates that UPC can be enabled/disabled on a per connection basis.




The pcr [0], cdvt [0] and clp_tag parameters shown above do not apply for the PXM 1 UNI ports. On the FRSM modules, the Frame Relay policing parameters are configurable per channel as shown in Table 7-2.

Policing Using ATM Forum StandardsThe MGX 8230 UPC function can be configured to police incoming traffic streams on any combination of PCR (0), PCR (0+1), SCR, CDVT, and BT. For broadband interfaces, the policing is done by the RCMP chip on the trunk card. The RCMP supports two approximations to the GCRA algorithm for each connection. Per-VC policing is done to adhere to parameters negotiated at connection setup. For CBR and UBR connections, PCR and CDVT are specified. For VBR and ABR connections, in addition to PCR and CDVT, SCR and BT are specified. Policing can be done on a programmable combination of cell types—user cells, OAM cells, high or low-priority cells, or RM cells.

The MGX 8230 provides a selective cell-discard function (distinguishing high-priority cells over low-priority cells) that can be utilized for all QoS classes except those associated with the constant bit rate (CBR) service class.

Table 7-1 Connection Parameters

Parameter Description

<chan_num> Channel number

<enable> Enable/disable for UPC: 1 = disable, 2 = enable

<pcr[0+1]> Peak cell rate [0+1]

<cdvt[0+1]> Cell delay variation [0+1]

<pcr[0]> Peak cell rate [0]

<cdvt[0]> Cell delay variation [0]

<scr> Sustained cell rate

<scr_police> Specifies the type of scr policing: 1 = CLP[0] Cells, 2 = CLP[0+1] Cells, and 3 = no SCR policing

<mbs> Maximum burst size

<clp_tag> Enable for CLP tagging: 1 = disable, 2 = enable

Table 7-2 Frame Relay Policing Parameters

Parameter Description

<chan_num> Channel number

<cir> Committed information rate

<bc> Committed burst

<be> Excess burst

<ibs> Initial burst size

<de tag> Enable or disable DE (Discard Eligible) bit tagging on ingress frames

<egress service rate> Specify the rate that the channel will be serviced at egress




During connection setup, the action taken on a non-conforming cell can be programmed on a per-VC basis.

• Keep count

• Tag change to low priority

• Tag and discard low-priority cells

• Discard all nonconforming cells

For CBR and UBR connections, only one policing instance (GCRA-1) is needed to check for PCR and CDVT conformance. For VBR and ABR connections, one policing instance (GCRA-1) is needed to check for PCR, CDVT conformance, and another instance (GCRA-2) for SCR, BT conformance. Frame discard features are supported in the queue engine.

Policing features supported by the different service modules are summarized in Table 7-3.

Policing Provisioned Point-to-Point Virtual CircuitsThe granularity of the PCR is defined by the sampling rate of the policing algorithm. Table 7-4 lists the minimum PCR and maximum CDVT parameters for the available sampling rates on PXM1.

Table 7-3 Supported Policing Features

Service Module Description

Frame Service Module (FRSM) Polices every valid cell received from the T1/E1 ports

Policing function is based on CIR, Be, Bc, IBS

ATM UNI Service Module (AUSM/B) For CBR connections, traffic is policed using a single policing instance GCRA-1 that checks for PCR and CDVT conformance

For VBR and ABR connections, traffic is policed using a dual policing instance: GCRA-1 that checks for PCR, CDVT conformance, and GCRA-2 that checks for SCR, BT conformance

Partial Packet Discard is implemented in the policing function

Early Packet Discard is done on Per VC Qs

Table 7-4 Policing Rates

Sampling Rate 20 ns

PCR min (CPS) 48

CDVT max (sec) 5



Chapter 7 Traffic ManagementService Module Policing Function

Service Module Policing FunctionThis section describes the policing functions for the various service modules.

Frame Service Module (FRSM)The policing function for the FRSM cards is based on a dual leaky bucket operation. The first bucket checks for compliance with the burst Bc, and the second bucket checks for compliance with the burst Be. The policing function in the FRSM measures the incoming traffic average rate over a period “T.” It then decides if the traffic should be

• forwarded

• tagged and forwarded

• discarded

• DE = 0 traffic conforming to CIR is forwarded

• DE = 0 traffic nonconforming to CIR but conforming to EIR is tagged and forwarded

• DE = 0 traffic nonconforming to CIR and EIR is discarded

• DE = 1 traffic conforming to EIR is forwarded

• DE = 1 traffic nonconforming to EIR is discarded

The policing mechanism differs slightly between the lower speed FRSM cards (FRSM-8T1/8E1/8-T1-C/8-E1-C/HS1/B) and the higher speed FRSM cards (FRSM-HS2/2CT3/2T3E3).

The overall dual leaky bucket algorithm is used for both types of cards, but there are a few differences regarding limits, the credit scheme, and the IBS function as described below.

• Increased limits—The maximum permissible burst size is increased from 65535 bytes to 2,097,151 bytes.

• Credit scheme—On the higher speed FRSMs, credit is given to a connection based on the actual time and the time elapsed since the arrival of the last frame. The bucket leaks by a certain amount, and this amount is the “credit” for the connection. The first bucket is of size Bc and leaks at the rate of CIR; the second bucket is of size Be and leaks at the rate of EIR. Every time a frame is received, the policing function determines the amount by which the bucket should leak. This is done by finding the difference between the current time and the time at which the last compliant frame was received. The credit for a connection is proportional to the time difference and the rate of the connection (either CIR or EIR depending on the bucket). A frame is compliant to that bucket if the contents of the bucket do not overflow. Finally, the policing function increases the contents of the bucket by the number of bytes in the received frame. The size of the first bucket is Bc, and the size of the second bucket is Be. The policing function timestamps the connection with the current time if the frame was compliant.

• On the lower speed FRSMs, credit is given to a connection every 10 ms.

• Initial burst size (IBS): On the higher speed FRSMs, the IBS function is not linked to policing. A connection must be silent for a period of time equal to QIR timeout to qualify for IBS. The frame is flagged for IBS and queued as normal through per-VC queuing. When it is scheduled to be sent out on the cell bus, the connection temporarily has its Instantaneous Rate (IR) and priority increased until it transmits IBS number of bytes. Then the IR and priority of the connection are reset to their original values.

For the lower speed FRSMs, if the amount of credit accumulated is less than the IBS value (which is user configurable), then the frame was marked for a separate IBS queue.




Figure 7-5 shows the ingress cell flow on the FRSMs.

Figure 7-5 Ingress Cell Flow

For FRSM modules, the F-GCRA feature is not available at the UPC policing point.

ATM Service Module (AUSM/B)The UPC in AUSM/B can be configured to run either a frame-based generic cell rate algorithm (FGCRA) or the GCRA defined in ATM UNI3.0. In case of FGCRA, at the arrival of the first cell of the frame, the bucket depth is compared with a limit parameter (for example: L1). If the first cell is noncompliant, then all the remaining cells in the frame will be treated as noncompliant. If the first cell is compliant, then remaining cells will be compliant if the depth of the bucket upon cell arrival is less than or equal to a limit parameter (for example: L2).

Once the cell has passed through UPC, it will be queued onto the ingress queue after the following checks:

1. Queue is full (the cell is then discarded)

2. CLP High Threshold is exceeded (the CLP set cells will therefore be discarded)

3. CLP hysteresis is set (once cells reach CLP threshold, they will be dropped until CLP low threshold is reached)

4. EPD/PPD discard is set (if the first cell of the frame exceeds EPD threshold, then all cells of that frame are discarded)

In addition to the FGCRA algorithms provided by the AUSM/B, there is an EPD/PPD feature available in QE. This is enabled on a per-connection basis. Figure 7-6 shows the ingress flow on the AUSM/Bs.

Be

4303

6

Offered traffic

Ingresspolicing

on frames

Cells

Cells

Ingressper-VCqueue

ECNthres

Interworkingfunction

(RFC 1483 - 1490)

IBSconforming

trafficCIRconformingtraffic

EIRconformingtraffic

Frames

Cells

DE = 0 DE = 1

Bc

Cell bus to PXM DEthres

0 to65537cells

To ATMuplink

IBS




Figure 7-6 Ingress Flow on an AUSM/B

Figure 7-7 and Figure 7-8 show the policing for the different types of traffic.

Figure 7-7 CBR Traffic Policing

4303

7

Frame basedor early packetdiscard is done

on per VC Qs

Per PVCUBR Qs

EPDthres CBR and IBS

traffic,served firstimmediately(no queuing)

UBR traffic, served third

Conforming cells

Conforming cells

Nonconformingcells

VBR/ABR traffic, served second

Per PVCVBR/ABR Qs

Cell bus to ATM uplink

Policing onSCR0 or SCR01and MBS, taggingoptional

Policing onPCR01,and for IBS

Cells from CPE

Frame based orpartial packet discardis implemented inthe policing function

4303

8CLP = 0 or 1

CLP = 0 or 1

CLP = 0 or 1

Noncompliant

Compliant

Discarded

Passed to VC Q

CellToken

CDVT(0+1)

PCR(0+1)




Figure 7-8 VBR Traffic Policing

Table 7-5 summarizes the UPC actions based on the type of policing selected for VBR traffic.

4303

9

CLP = 0 or 1

CLP = 0 or 1

CLP = 1

Noncompliant

Compliant

Discarded

Passed to VC Q

Noncompliant

Compliant

Discarded or tagged

Passed to VC Q

Cell

VBR.1

VBR.1

CLP = 0Compliant Passed to VC QVBR.3

VBR.2

Token

CDVT(0+1)

PCR(0+1)

Function of MBS

SCR

Table 7-5 AUSM UPC Actions Based on VBR Traffic Policing

SCR Policing Type

Cells Policed on Second Bucket CLP Tagging Value Results of Noncompliance

1 CLP = 0 only Disable Discarded

1 CLP = 0 only Enable Set CLP = 1

2 All cells Disable Discarded

2 All cells Enable Set CLP = 1

3 No cells — All cells passed to network




ABR Traffic PolicingFigure 7-10 and Figure 7-11 shows the policing for ABR and UBR traffic respectively.

Figure 7-9 ABR Traffic Policing

Figure 7-10 UBR Traffic Policing

Processor Switch Module (PXM 1)The broadband line daughter card polices data from broadband ports configured as user ports. UPC is performed on a per-channel basis. Figure 7-11, Figure 7-12, and Figure 7-13 show the policing for the different types of traffic.

4303

9

CLP = 0 or 1

CLP = 0 or 1

CLP = 1

Noncompliant

Compliant

Discarded

Passed to VC Q

Noncompliant

Compliant

Discarded or tagged

Passed to VC Q

Cell

VBR.1

VBR.1

CLP = 0Compliant Passed to VC QVBR.3

VBR.2

Token

CDVT(0+1)

PCR(0+1)

Function of MBS

SCR

4304

0

CLP = 0 or 1

CLP = 0 or 1

CLP = 0 or 1

Noncompliant

Compliant

Discarded

Tagged (if CLP is enabledand passed to VC Queue)

CellToken

CDVT(0+1)

PCR(0+1)




Figure 7-11 CBR Traffic Policing

Figure 7-12 VBR Traffic Policing

4303

8

CLP = 0 or 1

CLP = 0 or 1

CLP = 0 or 1

Noncompliant

Compliant

Discarded

Passed to VC Q

CellToken

CDVT(0+1)

PCR(0+1)

4304

1

CLP = 0 or 1

CLP = 0 or 1

CLP = 1

Noncompliant

Compliant

Discarded

Passed to VC Q

Noncompliant

Compliant

1 + 2 Discarded3 tagged

Passed to VC Q

Cell

2 + 31

CLP = 0Compliant

2 + 3

Token

CDVT(0+1)

PCR(0+1)

Function of MBS

Policing Type 4 and 5 not shown4 Disable second bucket. Single bucket policing5 Disable policing

SCR




Figure 7-13 ABR Traffic Policing

Figure 7-14 UBR Traffic Policing

Table 7-6 summarizes the UPC actions based on the type of policing selected for VBR traffic.

4304

1

CLP = 0 or 1

CLP = 0 or 1

CLP = 1

Noncompliant

Compliant

Discarded

Passed to VC Q

Noncompliant

Compliant

1 + 2 Discarded3 tagged

Passed to VC Q

Cell

2 + 31

CLP = 0Compliant

2 + 3

Token

CDVT(0+1)

PCR(0+1)

Function of MBS

Policing Type 4 and 5 not shown4 Disable second bucket. Single bucket policing5 Disable policing

SCR

4304

2

CLP = 0 or 1

CLP = 0 or 1

CLP = 0 or 1

Noncompliant

Compliant

Discarded

3 Tagged and passed to VC Q4 Passed to VC Q

CellToken

CDVT(0+1)

PCR(0+1)

Table 7-6 PXM UPC Actions Based on VBR Traffic Policing

Conn. Type

Policing Type

ATMF TM4.0 Conformance Definition

PCR Flow(1st leaky bucket)

SCR Flow(2nd leaky bucket)

CLP Tagging(SCR noncompliant)

VBR 1 VBR.1 CLP(0+1) CLP(0+1) No

VBR 2 VBR.2 CLP(0+1) CLP(0) No

VBR 3 VBR.3 CLP(0+1) CLP(0) Yes

VBR 4 CLP(0+1) Off —

VBR 5 Off Off —




QoS and Buffer ArchitectureTable 7-7 summarizes the UPC actions based on the type of policing selected for UBR traffic.

The QoS classes provisioned for a per-connection basis in the MGX 8230 modules are as follows:

• Constant bit rate (CBR)

• Variable bit rate–Real time (VBR-RT)

• Variable bit rate–Non-real time (VBR-NRT)

• Unspecified bit rate (UBR)

• Available bit rate (ABR): Standard or ForeSight

The MGX 8230 can isolate the different QoS traffic streams within each logical interface connecting to the switch fabric so that it has a separate set of Qbins. Each set consists of a Qbin for each distinct CoS (CBR, VBR-RT, VBR-NRT, standard ABR, ForeSight ABR, UBR). All the cells on all connections of a given CoS are queued into the Qbin for that CoS. The servicing of the Qbins of each interface is based on the minimal service rate and the relative priority between all CoSs.

The MGX 8230 provides up to 16 QoS queues for each virtual interface.

In order to provide additional granularity over the six classes of QoS Qbins used (CBR, nt_VBR, nrt_VBR, ABR_std, ABR_fst, UBR), the switch fabric on the MGX 8230 allows per-VC setting of VC queue (VCQ) parameters based on QoS descriptors in the future. At present VCQ parameters are defaulted based on service type. The MGX 8230 switch fabric has egress per-VC queues feeding class of service (CoS) queues. The per-VC queues have a set of parameters that can be set in order to define which per VC queues (VCQ) get admitted into the CoS queues first. The configurable VCQ parameters are

• CLP1 threshold

• CLP0 threshold

• EFCI threshold

• Maximum queue size

• Frame discard for AAL5 traffic

Each service module has cell-buffering capability in the ingress direction to the network. There is also buffering at each interface in egress direction.

Table 7-7 UPC Actions Based on UBR Traffic Policing

Conn. Type

Policing Type

ATMF TM 4.0 Conformance Definition

PCR Flow(1st leaky bucket)

SCR Flow(2nd leaky bucket)

CLP Tagging(SCR noncompliant)

UBR 4 UBR.1 CLP(0+1) — —

UBR 3 UBR.2 CLP(0+1) CLP(0) Yes

UBR 5 Off Off —




Frame Service Module (FRSM)For the FRSM cards the buffer size is as follows:

• Low-speed FRSMs

– For egress: Tx buffer size = 144 bytes

– For ingress: Rx buffer size = 144 bytes

• High-speed FRSMs

– For egress: Tx buffer size = 256 bytes

– For ingress: Rx buffer size = 256 bytes

Ingress Queuing

All conforming frames in a VC queue are serviced based on the VC’s configured CIR. The CIR measurement is done by monitoring committed burst, Bc, during a burst duration, Tc. If more than Bc bytes of traffic are received within the Tc interval, the arrival rate is considered to exceed CIR.

The per-VC queuing differs slightly for the high-speed FRSM cards and the lower speed FRSM cards.

High-speed FRSM Cards

This group includes the FRSM-HS2, FRSM-2CT3, and the FRSM-2T3E3. In the ingress direction, there are five different classes of service, CBR, rt-VBR, nrt-VBR, ABR, and UBR.

Lower Speed FRSM Cards

This group includes the FRSM-8T1/8E1/8T1-C/8E1-C/HS1/B cards. In the ingress direction, different classes of service are not supported for per-VC queuing.




Figure 7-15 shows the per-VC queuing on the FRSM cards.

Figure 7-15 Per-VC Queuing on FRSM Cards

Egress Queuing

ATM-like CoS queues have been introduced on the high-speed FRSM cards (FRSM-HS2/2CT3/2T3E3). There are four data queues:

• High-priority queue

• VBR-RT queue

• VBR-NRT and ABR queue

• UBR queue

The lower speed FRSM cards (FRSM-8T1/8E1/8T1-C/8E1-C/HS1/B) have no ATM-like CoS egress queuing mechanism. These cards have two levels of priority for data traffic—a high-priority queue and a low-priority queue. Queue is determined based upon connection type. In case of two queues, high-priority and VBR-RT connections are assigned to a high-priority queue, and VBR-NRT, ABR, and UBR are assigned to a low-priority queue.

For every N times that the high-priority queue is serviced, the low-priority queue is serviced once. N is a user-configurable parameter. There is also a separate queue for LMI traffic.

For the high-speed FRSM cards (FRSM-HS2/2CT3/2TE3) in the egress direction, there is multiple-priority-level queuing per logical port. Four data egress queues and one LMI queue are maintained. There are four egress data queues:

• High-priority queue (for CBR traffic)

• RT-VBR queue

• One common queue for NRT-VBR and ABR traffic

• UBR queue

4304

3

Queue depth

DE threshold

ECN threshold

FRSMVirtual circuit queue

Cells tosystem bus

Frames to end-user equipment

Egr

ess

VC

que

ues

Inrg

ess

VC

que

ues




The egress CoS mechanism implemented in the high-speed cards is based on an ATM OptiClass algorithm (algorithm 3). This is the first time that an ATM-like CoS has been introduced in a frame-service module. It is implemented in two stages:

• Stage One: A port is scheduled to be serviced. After a port is serviced, its next service time is determined by the length of the last frame transmitted. (This is done in hardware.)

• Stage Two: The credits or bandwidth increments are used to determine the queue to be serviced. (This is done in software.) The queue that meets or exceeds the threshold with its accumulated credits will be serviced first. If there are no queues that have exceeded the threshold, the queues are serviced in round-robin fashion.

In the second stage described above, the service algorithm uses a weighted-fair-queue mechanism to guarantee different classes of service. The weight is determined by the number of credits (or bandwidth increments) accumulated. The credits (or bandwidth increments) are automatically computed from the CIR/MIR of all connections mapped to a particular queue during channel provisioning. Every time a new connection is added or deleted, the credit/bandwidth increment must be recomputed. Port queue thresholds are also introduced in addition to per-channel level thresholds:

• peak port queue depth

• peak port queue ECN threshold

• peak port queue DE threshold (for DE = 1 frames)

Frames are dropped when either the channel threshold or the port queue threshold is exceeded. The credit/bandwidth increment on high-speed cards is important because it determines which queue will be serviced.

The formula to determine the credit for the connection is

Credit/Bandwidth Increment = (total CIR for connection type/Port speed) * Scaling Factor

where the Scaling Factor is 214 or 16384.




Figure 7-16 shows the egress traffic flow for the lower speed FRSM service modules.

Figure 7-16 FRSM Egress Flow

In summary, the traffic flow on the FRSM cards is as follows.

Ingress Flow

Initial Processing

For the high-speed FRSM cards, the first 32 bytes are sent to the Ingress Service Engine (ISE) for processing. The frame header is read and the ISE first determines whether the frame is an LMI frame, an SVC frame, or neither type (a “data” frame).

• If the frame is an LMI frame, it is sent to the Ingress LMI queue

• If the frame is an SVC frame, it is sent to be segmented into cells and then queued

• If the frame is determined to be a data frame, then policing functions are performed

Policing

The dual leaky bucket algorithm is used to determine how frames are admitted to the network.

• If the queue size is greater than the DE threshold AND DE=1, then the frame is discarded

• If the queue depth is greater than the peak queue depth of the per-VC queue, then the frame is discarded

• If the queue depth of per-VC queue is greater than the ECN threshold, then the FECN bit is set

• If the queue length of the egress LCN queue is greater than the egress queue ECN threshold, then the BECN bit is set

4304

4

Cells

FRSM egress flow

Q.922 framesInterworking function

RFC 1490 - 1483

DLCI

54Q1

LCN

Logicalport 16

Hi

76Q2

LCN

Low LMI Q

34Q1

LCN

Logicalport 2

DE thresholdEgressport Q

Hi

ECN threshold

222Q2

LCN

Low LMI Q

FCS




Interworking

The necessary interworking functions as based on FRF.5 (Network Interworking) or FRF.8 (Service Interworking) are performed.

IBS

This function is supported on a per-VC basis to favor connections that have been silent for a long time. For lower speed FRSM cards, this function is linked to policing. If the credit accumulated exceeds the IBS value, the frame is marked for IBS. On the high-speed FRSM cards, the ISE checks if a frame qualifies for IBS function. If the connection has been silent for more than the QIR Timeout amount of time, then an IBS number of bytes are transferred at a line rate with increased priority to transfer this data ahead of other connections. When IBS number of bytes are transmitted, the IR and priority of the connection are reset to their original values.

Per-VC queuing

Traffic arriving at the network on a connection has its own dynamically assigned buffer at the entrance to the edge concentrator based on the amount of traffic and on the service-level agreement (SLA).

Segmentation

The segmentation and reassembly engine (SAR) segments the frame into cells.

Egress Flow

Initial Processing

The cell arrives from the cell bus and is delivered to the SAR Engine. The SAR uses the cell header to find the LCN/PTI.

If the cell is an OAM cell (PTI>=4), it is then sent to the OAM-receive queue, destined for the OAM module on the control processor.

If the cell is a management cell (reserved LCNs of 0-15), then the cell is sent to the management-receive queue, destined for the SCM module on the control processor.

If the cell is neither type (a data cell), then the cell is sent to the data-receive queue.

Reassembly

The frame is reassembled from the cell.

Queuing

While queuing the frame, if DE = 1 and the queue depth of the logical port queue is > DE threshold, then the frame is discarded. At this point, FECN and BECN are updated for the outgoing frame by comparing the queue depth of the corresponding Ingress/Egress queue with the QECN threshold.

For the lower speed FRSM cards, there are two egress data queues: high and low priority. Traffic is queued up based on how the connection was configured. The high-priority queue is serviced N times for every one time that the low-priority queue is serviced.

For the high-speed FRSM cards:

• While servicing the egress queues, the LMI queue always has the highest priority. All other queues are serviced in a weighted fashion depending on the percentage of logical port bandwidth needed by all connections on a logical port.

• There are four egress data queues:

– High-priority queue

– RT-VBR queue

– One common queue for NRT-VBR and ABR




– UBR queue

• Depending on the sum of CIR/MIR for all connections mapped to a certain queue, the queue will have a credit (or bandwidth) increment that will be updated every service time. Normalization prevents the total credits for a port from exceeding the total port bandwidth.

• Actual queuing process: Credits (or bandwidth increments) are added for each queue and the highest priority queue whose credit has reached or exceeded the credit threshold is serviced. If no queue is determined to be serviced, then a nonempty queue is serviced in a weighted round-robin manner.

ATM Service Module (AUSM/B)AUSM/B egress and ingress queuing processes are described as follows. For the AUSMT1/E1 cards the ingress/egress buffer size is 16Kcells.

Ingress Queuing

For each connection, a VC queue buffers the cells after they are policed and before they are sent to the cell bus. The purpose of the VC queue is to manage the traffic as it moves from the AUSM/B to the PXM 1 on the shelf. The VC queue has the additional function of shaping the ingress traffic on ABR channels.

The VC queue has several thresholds associated with it to mark and respond to congestion. The EFCI threshold defines the point where the MGX concentrator will tag incoming cells with the EFCI bit. The CLP high and low thresholds determine when CLP tagged cells (CLP = 1) are discarded in the VC queue if CLP hysteresis is enabled for the connection (cnfchanq command). If frame-based traffic control is enabled, the EPD threshold determines when to start discarding an AAL5 frame. A connection can have only one method enabled; either CLP hysteresis or frame-based discard.

In summary, configurable VC queuing characteristics include the following:

• VC queue depth—The size of the VC queue, in cells up to 16000. When the VC queue reaches its configured depth, all arriving cells are discarded.

• CLP high threshold—Determines when to start dropping CLP tagged cells. When the VC queue reaches the CLP high threshold, all arriving cells with the CLP bit tagged (set to 1) are dropped. Any cells already in the queue, regardless of the CLP bit, are not dropped.

• CLP low threshold—Determines when to stop dropping CLP tagged cells. After the VC queue has reached the CLP high threshold, CLP tagged cells will continue to be dropped until the queue has emptied out to the level determined by the CLP low threshold.

• EPD threshold—Determines when to begin dropping AAL5 frames. If the VC queue is above the EPD threshold when the first cell from an AAL5 frame arrives, all cells from that frame are discarded.

• EFCI threshold—Determines congestion marking. When the VC queue reaches the EFCI threshold, all arriving cells into the VC queue have their EFCI bit set to 1 to notify the end-user equipment of congestion in the network.




Figure 7-17 shows the per-VC queuing on the AUSM/B cards.

Figure 7-17 Per VC Queuing on AUSM/B Card

Egress Queuing

The egress port queues on the AUSM/B provide traffic management for multiple virtual circuits terminating on a single physical interface. A Qbin is a subqueue on an ATM port that buffers a specific type of traffic. For each port there is a CBR, VBR, ABR, and UBR Qbin.

Qbins are configured entering the cnfportq command. Configurable parameters include the following:

• Queue size—Determines the queue depth. If the Qbin exceeds the defined queue size, all arriving cells will be dropped.

• EFCI threshold—Determines congestion marking. When the Qbin reaches the EFCI threshold, all arriving cells into the Qbin have their EFCI bit set to 1 to notify the CPE of congestion in the network.

• CLP high threshold—Determines when to start dropping CLP tagged cells. When the Qbin reaches the CLP high threshold, all arriving cells with the CLP bit tagged (set to 1) are dropped. Any cells already in the Qbin, regardless of the CLP bit, will not be dropped.

• CLP low threshold—Determines when to stop dropping CLP tagged cells. After the Qbin has reached the CLP high threshold, CLP tagged cells will continue to be dropped until the Qbin has been emptied out to the level set by the CLP low threshold.

4304

5

CLP = 0 or 1

VC queue depth

CLP high threshold

EFCI threshold

CLP low thresholdor EDP threshold

Queue service rate




Figure 7-18 shows the egress traffic flow for the lower speed AUSM/B service modules.

Figure 7-18 AUSM/B Egress Flow

Circuit Emulation Service ModuleCircuit Emulation Service Module (CESM) egress and ingress queuing processes are described as follows.

4304

6

Cell bus from network

Logicalport 2(physical portor IMA group)

Each Q is assigneda Q service algorithm

that is best suited to a QoS

A VCC is then assigned aQ that matches its QoS

Logicalport 1(physical portor IMA group)

16 queuesper logical

port

ILMI Q

SNMP QOAM Q

CellsControl / OAM / signaling cells

4304

7CRB Qbin(queue 1)priority 1

CLP high

Port X

EFCI thresholdCLP low

VBR Qbin(queue 2)priority 2

CLP highEFCI thresholdCLP low

ABR Qbin(queue 3)priority 3


UBR Qbin(queue 4)priority 4





Egress Queuing

On the CESM, data received over the network is buffered before transmitting online. Buffering takes care of cell delay variation (CDV) in the network. The minimum buffering (low threshold) is a function of CDV value specified for the channel.

The values given below are the maximum values of the buffers.

For T1 UDT and E1 UDT: 16224 bytes

For T1 SDT: 384 * N bytes

For E1 SDT: 417 * N bytes

For T3 UDT and E3 UDT: 16224 bytes

where N is the number of timeslots assigned in N x 64 connection.

N = 32 for UDT connections.

The buffer size specified for a channel sets the high-threshold value. The low-threshold value decides minimum delay experienced by data and the high-threshold value decides maximum delay experienced by data. If data is not received from the network for a long time, the egress buffer runs out of data and underflow is registered. When data reception resumes, the data is buffered until the low threshold amount of data is accumulated. During underflow, dummy data (0xff) is transmitted online and underflow inserted cell count is incremented.

If data builds up in the egress buffer and crosses the high-threshold mark, an overflow event is registered. Data produced to buffer until low mark is reached is discarded. The number of data bytes discarded during overflow is indicated by the overflow drop bytes counter.

Figure 7-19 shows the egress traffic flow for the lower speed CESM service modules.

Figure 7-19 CESM Egress Flow

4304

8

Cells

AAL1 SAR function

Cells

N x 64 or E1circuits

Programmable =size byte buffersto recover jitter ofincoming CBR cellstream

AAL1 cell flowsper N x 64 or E1




Figure 7-20 shows the egress cell buffering on the CESM card.

Figure 7-20 CESM Egress Cell Buffer

Processor Switch ModuleThe Processor Switch Module (PXM 1) supports 256K of cell storage that is used by the QE ASICs for its queuing and buffering (128K of cell storage is allocated per direction).

In the switch fabric, there is buffering at three levels: VC queues, COS queues, and interface queues.

The VC queue parameters are currently defaulted as follows for all connections:

• VC Depth is set to 50 percent of maximum cell memory in QE

• ClpHiThreshold is set to 80 percent of VC Depth

• ClpLoThreshold is set to 60 percent of VC Depth

• EfciThreshold is set to 30 percent of VC Depth

When a connection is provisioned, there are two parameters that are specified for handling CLP. They are the CLP hi and CLP lo thresholds. If the queue is full when the cell arrives, the cell is discarded. If the queue is filled above CLP hi, and the incoming cell has CLP = 1, then the cell is discarded. If the queue is filled below CLP lo, then the cell is enqueued, regardless of its CLP setting. The area of the queue between CLP hi and CLP lo is called the “transition region.” The transition region provides hysteresis for discarding incoming cells that have CLP = 1. If the queue was filled above CLP hi but is now emptying such that it is in the transition region (but has not dropped below CLP lo), then incoming cells with CLP = 1 are still discarded until the queue drops below the CLP lo threshold. Similarly, if the queue was filled below CLP lo but is now filling such that it is in the transition region (but has not filled above CLP hi), then all incoming cells are enqueued, regardless of their CLP setting.

The PXM 1 card can have up to four physical lines. The user can split the line resource into multiple partitions called broadband interfaces. The maximum number of interfaces on the PXM 1 card is 32. There is a 1:1 mapping of the broadband interface to the virtual interface on the QE. The QE implements virtual interface buffers and CoS buffers. A service group (virtual interface) is defined for each physical port on a card. A service group (VI) is also defined for each virtual trunk on the card. Multiple CoS buffers (Qbins), one for each of VBR-RT, VBR-NRT, CBR, ABR, and UBR are associated with each interface. Within each VI, there are 16 CoS queues. This configuration allows multiple service types to be configured across the same physical interface and allows high-priority traffic to bypass low-priority traffic, thus guaranteeing QoS. The VI and CoS queues can be programmed with the following parameters:

• VI Queue:

– Peak service rate

– Minimum service rate

4304

9

Data received over networkgets queued here

High threshold

Low threshold

Data is dequeued fromhere and played on line




• CoS Queue:

– Minimum service rate

– Maximum queue depth

– Frame discard enable

– Thresholds for discarding cells tagged with CLP bit set

– Threshold for setting the EFCI bit.

– Priority level 1–16

– Various statistics for debugging

Figure 7-21 CoS Queuing Process

VI and CoS Queues Architecture

There are three VI and CoS queuing flows:

1. SM1 ↔ QE0 ↔ SM2

2. SM1 →QE1 →PXM 1 uplink

3. PXM 1 uplink →QE0 →SM1

All the above connection topologies follow the same queuing flow on PXM 1. It is a two-stage process.

Stage 1: VI selection

Based on the minimum rate of each VI (there are 32 VIs on each QE; on QE0, each slot is mapped to a VI, and on PXM 1 uplink, each VI is mapped to a virtual interface—a logical partition of a physical link), QE selects one VI it needs to service to satisfy the rate requirement.

Stage 2: Qbin selection

Based on the Qbin MIN rate of each Qbin of the selected VI in stage 1, a Qbin is selected.

Once a Qbin is selected, the cell at the head of that Qbin queue is moved to the output queue for that physical link or slot to be transmitted.

Cells do not physically pass the VCQ. However, when a cell is being serviced, accounting is done for VCQ threshold function.

Incoming traffic

To PXM port 1CoS 1CoS 16

VI

To slot 1CoS 1CoS 16

VI

4305

0



Chapter 7 Traffic ManagementCongestion Control Mechanisms

On the PXM 1, each QE is used for both directions (ingress and egress). Note that ingress and egress are defined from the perspective of QE on PXM 1 whereas on BXMs they are defined from the perspective of the backplane. With this definition, each switch path (except those terminating on PXM 1) has an ingress segment and an egress segment.

• Ingress—from trunk port to QE, or cell bus to QE

• Egress—from QE to trunk port, or from QE to cell bus

Separate queues can be used to support IP QoS.

IP QoS mechanisms use the three precedence bits in the type of service (ToS) field of the IP header to indicate IP precedence. Precedence values are used within the network to implement different service classes. There can be as many service classes as there are unique values of this three-bit field. Two of these values are reserved for traffic control, leaving six unique values for assignment to service classes.

Effective coupling of IP and ATM QoS is particularly challenging because of the differing paradigms (connectionless vs. connection-oriented). However, providing a seamless QoS capability between IP and ATM is essential when ATM is used as the backbone transport infrastructure for an IP VPN. This scenario allows QoS for intranet-based IP applications to take advantage of ATM QoS capabilities. MPLS is the key to this seamless integration.

In a VPN-aware network, the label header includes a CoS field with three bits to indicate a packet service class in a label-switched network. This value may be copied from the IP header when the label is applied, or it may be explicitly set by a precedence policy on the service provider edge router. As in an IP network, the CoS value is used to denote service class for each packet. When MPLS is implemented in an IP network, IP QoS capabilities are used the same way as in a traditional IP-routed network. In this case, however, service class is indicated by the CoS field in the label header instead of the IP header.

When the core of the service provider network uses ATM label switches, additional QoS capabilities are possible; they include:

• Use of available bit rate (ABR) on labeled VCs

• Use of parallel VCs for different precedence levels

Cisco edge concentrators such as the MGX 8230 provide IP service classes in addition to the standard ATM classes. These IP classes use a class-based queuing (CBQ) mechanism to implement separate queuing for IP flows while still utilizing the OptiClass buffer management feature to manage system buffers. This scenario allows the edge concentrator to provide ATM and Frame Relay services in parallel with IP while optimally allocating buffer space for all services.

Alternatively, MPLS allows a separate label VC to be used for each precedence value to a given destination. A percentage of link bandwidth can be allocated to each class of traffic using WFQ among classes to ensure that each class receives its allocated share of the link bandwidth. With the Cisco OptiClass buffer management feature, any unused bandwidth is automatically available to other classes. It is necessary to provision the link share appropriately to provide higher QoS to the higher classes. For example, if ten percent of the offered load on a link is expected to belong to a “premium” class, then allocating 15 percent of the link to the class with WFQ will ensure low-loss, low-delay service to that class.

Congestion Control MechanismsThe AUSM/B modules perform ForeSight_ABR functions as the closed-loop end-to-end traffic management. These mechanisms allow maximizing the link utilization and avoiding the network congestion. The PXM1 supports EFCI tagging. Network uses the EFCI bit in the ATM cell header to




indicate congestion. When congested, the concentrator sets an EFCI flag. The receiver must respond with “marked” RM cells and the sender will slow down upon receiving Congestion Indication (CI) in the Backward Resource Management cell (BRM).

The AUSM/B card conforms to ForeSight as a congestion-control mechanism. Based on the congestion status of the concentrator, the MGX 8230 can:

• Do nothing

• Set the CI bit in the RM cells

• Set the EFCI bit in the users cells

• Clear the EFCI bit on abatement

EFCI BitThe different service modules on the MGX 8230 react to a set EFCI bit. Depending on the configuration, each service module can take different actions upon receiving a cell with the EFCI bit set.

The EFCI bit is used in the AUSM/B as mentioned follows:

• For both the ingress and egress side, whenever the AUSM/B gets a cell, it is put it onto the corresponding queue. In case the qdepth exceeds EFCI threshold, the EFCI indication is set on the cell, else the EFCI bit is cleared. The incoming EFCI indication is overwritten with the new EFCI status.

• In case of ABR channel with ForeSight enabled, the rate-down message is sent on the network whenever there is

– EFCI set cells received from the network

– EFCI set cells transmitted onto the port side

Table 7-8 shows the mapping that can be configured on FRSM cards.

Table 7-8 FRSM Mapping Configurations

<FECN/EFCI> Mapping between FECN and EFCI fields in the range 1–2

1 = map EFCI, (this option valid only for service interworking)

2 = make EFCI 0

<DE to CLP> DE to CLP mapping in the range 1 – 3

1 = map DE to CLP

2 = make CLP 0

3 = make CLP 1

<CLP to DE> CLP to DE mapping in the range 1 – 4

1 = map CLP to DE

2 = make DE 0

3 = make DE 1

4 = ignore CLP (this option valid only for network interworking)




EPD/PPD ImplementationThe type of frame-discard mechanism is configurable per connection.

The QE uses an EPD feature as acceptance criteria for new AAL5 frames. This feature is also referred to as packet discard (PD) and frame-based traffic control (FBTC). Two EPD thresholds apply selective cell-discard principles to new frame acceptance criteria. EPD0 applies to all cells, while EPD1 applies only to cells with CLP=1. These are explained further as follows.

In addition to EPD, the QE implements a random early detection (RED) feature, in which full frames are randomly discarded with increasing probability as the CoS buffer’s time-averaged queue length approaches its EPD threshold. It has been shown that RED improves the performance of TCP connections.

Early Packet Discard

EPD uses the EPD0 and EPD1 thresholds for the VCs and classes of service as the acceptance criteria for new AAL5 frames. The start of frame (SOF) cell is determined to be the next cell to arrive following an AAL5 end-of-frame (EOF) cell.

EPD attempts to discard entire frames. However, it is possible that a cell is discarded after one or more cells of the frame have been accepted. In this case, the remainder of the frame is discarded, except that the EOF is evaluated independently (to avoid corrupting the next new frame). This is referred to as tail packet discard. In this case, if the EOF is discarded at the end of a tail discard, the next frame is also discarded, to avoid sending a corrupted frame.

The QE allows packet-discard features to be enabled on a per-connection basis. To implement these features, the QE maintains a packet-discard state for each connection that has packet discard enabled. The purpose of maintaining the states is to differentiate between a full-packet discard and tail-packet (partial) discard. There are four packet discard states:

• Start of frame—Next cell to arrive is a start of frame (SOF).

• Cells accepted—SOF was accepted.

• Partial (tail) discard—All cells are discarded until the EOF arrives. EPF is preferentially treated to avoid discard.

• Full discard—All cells are discarded until the EOF arrives (EOF is discarded).

Transitions between the states occur only upon arrival of user data cells for the corresponding connection. When an EOF cell arrives, the state machine goes to the SOF state. If an SOF cell arrives, and its corresponding cell count exceeds its VC EPD threshold (or the CoS EPD threshold is exceeded), then the cell is discarded. Note that there are separate EPD0 and EPD1 thresholds for the CLP(0+1) and CLP(1) SOF cells. That is, if any SOF cell arrives, and the cell count exceeds the EPD0 threshold, the SOF (and the following frame) is discarded. However, if the SOF cell has CLP=1, and the cell count exceeds the EPD1 threshold (which is usually programmed lower than the EPD0 threshold), then the SOF cell is also discarded in this case.

The Route Processor Module (RPM) through the Port Adapter PA-A3 can perform EDP. The shaper will drop whole packets.

C H A P T E R



8Reliability, Availability, and Serviceability

OverviewThe MGX 8230 is designed for carrier-class reliability. System components can be configured for 100 percent redundancy, and all MGX 8230 modules can be removed and reinserted without impacting service delivery or affecting the performance of other modules. Hot-standby interfaces offer optional redundancy so that if a module fails, the standby is fully online within milliseconds. Switchover to standby interfaces is nonservice-affecting for most protocols, ensuring nonstop application performance.

The MGX 8230 Edge Concentrator supports industry-standard, automatic protection switching (APS) for all SONET and synchronous digital hierarchy (SDH) interfaces using the 1+1 APS scheme. In the event of a fiber cut or card failure, APS performs switching to the backup fiber within milliseconds. The MGX 8230 series provides cost-effective 1:N redundancy of service interfaces to enhance overall reliability and availability. With support for 1:N redundancy, a single standby service module will automatically take over the traffic functions of any failed service module of the same type within seconds.

Key Availability FeaturesThe MGX family supports the following Reliability, Availability, and Serviceability (RAS) features:

• PXM1/SRM hot standby and hitless redundancy

• Hot swappable front and back cards

• Graceful upgrade/downgrade hitless switchover

• Exception handling and software error detection

• Graceful recovery from disk failures

• Database management

• Disk file and memory mirroring

• Automatic updates

• Upgrade/downgrade hooks

• Automated trouble detection monitoring



Chapter 8 Reliability, Availability, and ServiceabilityRedundancy

RedundancyThe Service Resource Module (SRM) enables 1:1 or 1:N redundancy for the service modules. It also offers other features, such as BERT testing and M13 grooming of circuits. There are two SRMs per node. The SRM is1:1 redundant; one is active and the other is redundant. The SRM supports 1:N redundancy for the service modules.

For bulk distribution, the MGX 8230 shelf can support three channelized T3s using the SRM. The SRM can support 64 T1s per shelf. Bulk distribution is supported in all service module slots of the MGX 8230 (all slots except slots 1/7 and 2/8 where the PXM1 cards reside).

The SRM can be used in conjunction with native T1/E1 Service Modules to bring the total to 192 DS1s: 160 DS1s using twenty 8-port cards and the SRMs, and 32 DS1s using four 8-port cards with T1/E1 back cards. The current SRMsupports 64 DS1s across the three T3s on each SRM.

PXM1 on slot 1 controls SRM on slot 7 and PXM1 on slot 2 controls SRM on slot 14. The active SRM depends on the active PXM1.

For redundancy, the MGX 8230 power supply tray has two options: one with one AC cord and another with two AC cords.

• MGX-AC1-1 is for systems requiring a single AC power supply that will be powered from a single AC power source. MGX-AC1-1 provides up to 1200 W of load-shared redundant power. If additional power is needed, additional power supplies, providing an additional 1200 w each, can be added. The one-AC cord version uses 1:N power-supply redundancy. If you have three 1200W power modules, you can support up to 2400W of power; the third module is redundant. Since there is only one AC cord, you do not have redundancy for the AC cord itself.

• MGX-AC2-2 is for systems requiring redundant AC power supplies that will be powered from two AC power sources.The two-AC cord power tray supports 1:1 power-supply redundancy. If you have four 1200W power supplies, you can support only 2400W of power. The two AC cord power trays each have two AC cords; therefore, both the AC cord and the power modules are redundant.

The quantity of AC power modules is determined by the type of power tray and by the customer's overall power requirements. The AC power module converts 220V 50/60 cycle AC into 48 VDC.

The MGX 8230 implements a robust, distributed database scheme in which the configuration parameters are stored in service module local memory, active PXM1 hard disk, and standby PXM1 hard disk. This scheme ensures update efficiency and database consistency. It also includes a synchronization protocol between PXMs and SMs to recover from database inconsistency due to certain error conditions (such as switchover).

The architecture of multiple cell buses ensures that if one service module pulls one cell bus down, other cell buses can continue to operate without down time.

The PXM1 is fully redundant in a 1:1 configuration. While one of the PXMs serves as the active switching fabric, the backup serves as a hot-standby module. Upon the detection of a failure in the active PXM1, the hot standby takes over the switching fabric function in a completely nondisruptive manner. The PXM1 switchover times are between 15–30 ms.

There are several signals cross-coupled between the two PXMs. If the active PXM1 resets, the couple signals will indicate to the standby PXM1 to take over mastership. Software polls the mastership logic periodically. Once it detects a hardware switchover, it will start running all the routines necessary to assume mastership.



Chapter 8 Reliability, Availability, and ServiceabilitySwitchover Mechanism

All existing connections will be copied onto the new card. There are frequent exchanges between the active card and standby card to make sure that the standby card has all the information necessary to resume operation should the active card fail.

The T3/E3 and SONET interface ports on the service modules can be configured to provide a 1:1 redundancy on each service module. Additionally, the SRM can be configured to provide up to 1:N redundancy for the narrowband service modules (through the redundancy bus).

AC Power Shelf (AC systems only)The AC power module includes the following power design features:

• 3U rack mountable (two shelves may be required per system)

• Hot pluggable AC/DC power modules (1200W capacity each)

• O-ring diodes in each power module

• EMI filtering in each power module

• Cooling fans in each power module

• Circuit breaker(s)/switch(es)

• 2N (dual AC line input) for redundancy

Redundancy for DCIn the DC system, the 48 VDC is supplied through either one or two power-entry modules (PEMs). The PEMs will be plugged into the midplane through the same connectors as the AC power supply. Each PEM has a circuit breaker for protection. The DC power range is –42 to –56 VDC.

Switchover MechanismThe MGX 8230 backplane supports the same distribution bus employed in the MGX 8220. This is used in conjunction with the SRM-3T3 to provide M13 circuit breakout and distribution capability, as well as T1/E1 1:N service module redundancy (in bulk mode, the service modules have 1:N redundancy without using the separate T1 redundancy bus).

Nonbulk Mode DistributionNonbulk mode distribution is a mode of operation where individual T1 lines are directly connected to the line module of each front card. During normal nonbulk mode operation, the T1/E1 data flow is from the service module's line module to its front card and vice versa. The line modules also contain isolation relays that switch the physical interface signals to a common redundancy bus under SRM-3T3 control in case of service module failure.

In nonbulk mode, upon the detection of a failure in any of the service modules, the traffic destined for the failed service module is carried over the redundancy bus to the active SRM on its shelf. Thus, each active SRM provides redundancy for a maximum of 8 service modules per shelf.



Chapter 8 Reliability, Availability, and ServiceabilityHot Standby

When a service module failure is detected, the PXM1 will initiate a switchover to the standby service module. The relays on the service module's line module (all T1/E1s) are switched to drive the signals onto the T1 redundancy bus. The designated standby card's line module (controlled by the SRM-3T3) receives these signals on the T1/E1 redundancy bus. The data path switches from the failed service modules' line module to the T1/E1 redundancy bus to the line module of the standby service module, and finally to the standby service module itself.

Bulk Mode DistributionBulk distribution is a mode of operation in which individual lines are not brought to the service modules, these lines are multiplexed into a few high-speed lines attached to the SRM. The SRM then takes this “bulk” interface, extracts the lines, and distributes them to the service modules. Any cards served by this bulk interface can participate in 1:N redundancy without using the separate redundancy bus. Any T1 in a T3 line can be distributed to any eight ports on a service module in any slots of the service bay without restriction.

During bulk mode operation, the SRM- 3T3/B unbundles T1 data from the incoming T3s and sends it to each service module. Any slot can be used to process T1 data or to house a standby service module. When a service module fails, the PXM1 will initiate a switchover to the previously configured standby module. The SRM-3T3/C will then redirect the recovered T1 traffic to the designated standby module. The switching takes place inside the SRM-3T3/C and requires no special back cards or cabling. The data path to the standby module is still via the distribution bus; the redundancy bus is NOT used in bulk mode.

Hot StandbyThe switching fabric is configured in a 1:1 redundancy. Of the two PXM1s in the edge concentrator, one PXM1 serves as the active switch fabric while the other serves as a hot standby for the active PXM1. Switching service modules can be done in a nondisruptive manner.

Software UpgradesNonservice-affecting software upgrades enable the system to gracefully upgrade software or add new features without disrupting services. New features are received without interrupting service delivery or application performance.

Logical ConnectionsAll the narrowband service modules are connected logically to the PXM1 and the SRM via the cell bus. Therefore, the failure of any single service module does not impact other interface cards.



Chapter 8 Reliability, Availability, and ServiceabilityPerformance

PerformanceThe MGX 8230 availability performance is 99.999%. The primary RAS measure for the MGX 8230 product is “minutes of connection outage.” The percentage of time the system or features are available for customer use is usually measured as a percentage: 99.999% (equivalent to 5.25 minutes of unavailability per year), which is the percentage of time that connections are available. It is also measured in defects per million (DPM) connection hours, or 10DPM = 99.999%.

Automatic Protection Switching Automatic Protection Switching (APS) is a means to provide redundancy on SONET equipment to guard against hardware failures. There are three modes of APS defined in GR-253 and ITU-T G.783: APS 1+1, APS 1:1, and APS 1:N. All three modes require that after any failures have been detected, switching from the working equipment to the protection equipment must be initiated in 10 ms and completed in 50 ms (for a total of 60 ms).

In an APS 1+1 implementation, a redundant protection line exists for every working line. Traffic protected by the redundancy is carried simultaneously by the working and protection lines. The receiver terminating the APS 1+1 must select cells from either the working or protection line and be able to forward one consistent traffic stream. Both working and protection lines transmit identical information; therefore, the receiving ends can switch from one to the other without coordination with the transmit end. If the working (or active) fiber optic cable fails, the protection fiber is selected at the SONET layer. In full compliance with standards, the K1 and K2 bytes are utilized for this signaling.

A P S redundancy will be supported on PXM1 OC-3 and OC-12 interfaces. Of the modes mentioned above, only APS 1+1 is supported. The cross-coupling between adjacent slots permits this type of redundancy. In the event of a link failure, the main processor subsystem that controls the PXM1 switches away from the failing port and activates the backup port. The processor performs this function intelligently based on the alarm status.



Chapter 8 Reliability, Availability, and ServiceabilityAutomatic Protection Switching

C H A P T E R



9Network Synchronization

MGX 8230 Clock SourcesThe clock sources that are available for primary and secondary clock selection are

• Extracted received clock from the daughter card trunking interface (up to two ports)

• Derivative of an externally provided T1 or E1 clock

– T1 clock rate 1.544 MHz +/- 50 ppm

– E1 clock rate 2.048 MHz +/- 100 ppm

• Internal oscillator located on the PXM

• Clock provided via the backplane from one of the service modules

Synchronization and Timing SupportThe PXM1 supports either a Stratum 3 or Stratum 4 enhanced clock.

The internal clock meets the Stratum 3 and Stratum 4 requirements as detailed in Table 9-1 and Table 9-2.

Table 9-1 Stratum 3 Requirements

Accuracy Holdover Stability Pull in Range

4.6xe-6 1xe-8/day 4.6xe-6

Table 9-2 Stratum 4 Requirements

Accuracy Holdover Stability Pull in Range

32x10-6 no holdover 32x10-6



Chapter 9 Network SynchronizationMGX 8230 Clock Sources

Internal Holdover CapabilityThe MGX 8230 guarantees an 8 kHz clock speed during the time it switches over to other sources.

The MGX 8230 clock synchronization system meets the following criteria as specified Bellcore GR-1244-CORE, Section 2.6

• pull-in/hold-in range

• input tolerance requirements

• output signal requirements

• alarms, reports, and control commands

The MGX 8230 also supports clock synchronization system redundancy in compliance to GR-1244-CORE, Section 3.3.

External Timing InterfacesThe MGX 8230 accepts external timing from T1 and E1 interfaces. The PXM User Interface card that resides in the upper service bay provides the T1/E1 timing reference ports:

• The PXM-UI back card provides connections to external Stratum 4 clocking sources (see Figure 9-1). A RJ-45 connector labeled “T1 clock” is provided for external T1 clock input and an SMB connector labeled “E1 clock” is provided for E1 clock input.




• The PXM-UI-S3 back card provides connections for external Stratum 3 clocking sources (see Figure 9-2). A RJ-45 connector labeled CLK1 is provided for external T1 or E1 clock input.

Figure 9-1 PXM-UI Rear View

1220

8

PXM-UI

CP

MP

CLOCK

T1

LAN

ALARM

E1 CLOCK

T1 clock

Maintenance port

Control port

LAN port

E1 clock source

Alarm outputs




Figure 9-2 PXM-UI-S3 Rear View

E1 Interface ComplianceThe E1 interface on the PXM back card has been designed to support both options according to G.703. As per G.703 Table 6, it supports an unframed HDB3 E1 (2048 KBps) signal. According to G.703 Table 10 (now calledTtable 11), it also supports a timing signal of 2048 kHz.

External TimingMGX 8230 is capable of the following external timing and formats:

• Building Integrated Timing Source (BITS) as specified in Bellcore GR-1244-CORE.

• Minimum of two external timing references (inband and external).

• External timing is the DS1 reference in D4 (SF) format.

• Switching to the alternate timing reference.

The MGX 8230 Edge Concentrator is capable of receiving a minimum of two external timing references on separate physical interfaces. These are provisioned as the active (act) and alternate (alt). The terms act and alt are interchangeable depending on which reference is active, and providing timing reference for the system. The system also provides a DS1 reference for external timing in D4 (SF) format. At least two DS1 synchronization references, as specified in Bellcore GR-1244-CORE, Section 3.4, can be configured.

PXMUI-S3

CP

MP

AL

1

N

L

2

NA

EXT CLK 1

LA

ARM

4601

0

EXT CLK 2

External Clock 1(connection for T1 and E1external clock sources)

LAN 2 port(not supported in this release)

LAN 1 port

Maintenance port

Control port

External Clock 2(not supported in this release)

Alarm port




A switchover from the active clock source (primary or secondary) to the standby clock source will occur when the hardware detects a failure that warrants a switchover. The currently selected clock source is constantly monitored by the hardware to ensure that it is within tolerance.

If a failure in this selected clock is detected, the hardware gracefully switches over to the secondary clock source specified.

If both the primary and secondary sources have failed, the hardware will automatically output the clock generated internally on the card. Once the primary clock is within tolerance, the hardware will automatically switch back to it.

Regardless of whether the clock switchover is initiated by the user or by the hardware, the switchover meets the Accunet T1.5 Maximum Time Interval Error (MTIE) Specification.

When all timing references fail, as specified in Bellcore GR-1244-CORE, Section 3.4.1, the MGX 8230 can operate in self-timing or free-running mode, using an internal clock.

Revertive Clocking

Clocking can be either revertive or non-revertive.

• Revertive: If the node is configured such that the clock source fails (either due to a physical failure such as loss of signal, or due to the clock frequency drifting out of specification or a bad frequeny), the node abandons the clock source and finds an alternate clock source. Whenever the original clock source repairs, the node will automatically revert to using it.

• Non-revertive: The node behaves in exactly the same way as revertive except that whenever the original clock source repairs, the node does not automatically revert to the original clock source.

Whether a node is revertive or non-revertive depends upon the processor switching back card used and clocking source specified. Please refer to Table 10-3 to determine whether clocking is revertive or non-revertive in your network configuration.

Continuous Monitoring The MGX 8230 recognizes the following DS1 impairments or conditions as failures:

• Loss of signal (LoS)

• Alarm Indication Signal (AIS)

• Out of frame (OoF)

• Frequency Offset, monitor frequency offset from BITS

Table 9-3 Revertive Clocking and PXM Back Card Support

Processor Switching Module Back Card Using External Clock Using Inband/Service Module Clock

PXM1-UI For LoS: revertive

For bad freqeuncy/drift: revertive

For LoS: revertive

For bad freqeuncy/drift: non-revertive

PXM-UI-S3 For LoS: revertive


For LoS: revertive





Generating AlarmsAlarms are generated when a synchronization source, either active or standby, fails for some reason. Clocking failures do not affect any configuration or settings on either the PXM 1 or PXM45.

Software/Hardware UpgradesSwitch software upgrades do not cause changes in timing sources. A Y-cable is used to connect the external clock associated with both the active and standby processor cards. Part of the normal switch software upgrade process is a PXM switchover, the Y-cable will ensure clocking integrity to the external source.

A-1Cisco MGX 8230 Edge Concentrator Overview


A P P E N D I X AStatistics Collected

The MGX 8230 maintains a statistics subsystem primarily to monitor traffic conditions within the system. The TFTP daemon that handles configuration upload requests also services the statistics upload requests. The following statistics are collected by MGX 8230 modules.

PXM: SONET Statistics CollectedThe following SONET statistics are collected by the PXM1 module on the MGX 8230 switch platform:

• Sonet Line and Trunk Counters

– Section Counter LOSs

– Section Counter LOFs

– Path Counter AISs

– Path Counter RFIs

– Line Counter AISs

– Line Counter RFIs

• PLCP Counters



– dsx3PlcpFECount







• DS3 Counters

– dsx3LCVCurrent

– dsx3LESCurrent

– dsx3LSESCurrent

– dsx3PCVCurrent



Appendix A Statistics Collected

– dsx3PESCurrent

– dsx3PSESCurrent

– dsx3SEFSCurrent

– dsx3AISSCurrent

– dsx3UASCurrent



– dsx3PlcpFECount







– dsx3RcvLOSCount

– dsx3RcvOOFCount

– dsx3RcvRAICount

• dsx3FECount

– dsx3PlcpBip8CVCurrent

– dsx3PlcpBip8ESCurrent

– dsx3PlcpBip8SESCurrent

– dsx3PlcpSEFSCurrent

– dsx3PlcpUASCurrent

• ATM Counters

– Ingress

Number of cells received with CLP = 0 on a connection

Number of cells received with CLP = 1 on a connection

– Egress

Number of cells received on a connection

Number of cells transmitted on a connection

Number of cells received on a connection with EFCI bit set

Number of cells transmitted on a connection with EFCI bit set

On the broadband interfaces on PXM1, the counters available are

• Number of cells received from the port

• Number of valid OAM cells received

• Number of RM cells received

• Number of cells received from the port with CLP = 0





• Number of cell with CLP = 0 discarded

• Number of cell with CLP = 1 discarded

• Number of OAM cells transmitted

• Number of RM cells transmitted

• Number of cells transmitted for which CLP bit was set

• Number of cells transmitted for which CLP bit was not set

For each connection on the PXM1, the counters available are:



• Number of cells that were non-conforming at the GCRA-1

• Number of cells that were non-conforming at the GCRA-2

• Number of cell with CLP = 0 received from port and discarded

• Number of cell with CLP = 1 received from port and discarded

• Number of cells transmitted (to Cell bus or towards trunk card)

• Number of cells transmitted for which EFCI was not set

• Number of cells transmitted for which EFCI was set

• Number of cells with CLP = 0 toward port that were discarded

• Number of cells with CLP = 1 toward port that were discarded

• Number of EOF cells received

SRM-3T3/BThe following counters are provided for SRM-3T3/B:

• dsx3LCVCurrent

• dsx3LESCurrent

• dsx3LSESCurrent

• dsx3PCVCurrent

• dsx3PESCurrent

• dsx3PSESCurrent

• dsx3CCVCurrent

• dsx3CESCurrent

• dsx3CSESCurrent

• dsx3SEFSCurrent

• dsx3AISSCurrent

• dsx3UASCurrent

• dsx3RcvLOSCount

• dsx3RcvOOFCount

• dsx3RAICount




• dsx3FECount

• dsx3RcvFEBECounter

• dsx3RcvEXZCounter

High-Speed FRSMThe following counters are provided for high-speed FRSM cards:

• DS1 Alarm Stats

• statDsx1LCVCurrent

• statDsx1LESCurrent

• statDsx1LSESCurrent

• statDsx1CRCCurrent

• statDsx1SEFSCurrent

• statDsx1AISSCurrent

• statDsx1UASCurrent

DS1 Counter Stats

• statDsx1RcvLOSCount

• statDsx1RcvOOFCount

• statDsx1RcvRAICount

• statDsx1RcvFECount

DS3 Alarm Stats

• statDsx3LCVCurrent

• statDsx3LESCurrent

• statDsx3LSESCurrent

• statDsx3PCVCurrent

• statDsx3PESSCurrent

• statDsx3PSESSCurrent

• statDsx3SEFSCurrent

• statDsx3AISSCurrent

• statDsx3UASCurrent

DS3 Counter Stats

• statDsx3RcvLOSCount

• statDsx3RcvOOFCount

• statDsx3RcvRAICount

• statDsx3RcvFECount

Frame Relay Port Counters

• statPortRcvFrames

• statPortRcvBytes




• statPortRcvFramesDiscCRCError

• statPortRcvFramesDiscIllegalHeader

• statPortRcvFramesDiscAlignmentError

• statPortRcvFramesDiscIllegalLen

• statPortRcvFramesUnknownDLCI

• statPortRcvFramesDiscXceedDEThresh

• statPortXmtFrames

• statPortXmtBytes

• statPortXmtFramesFECN

• statPortXmtFramesBECN

• statPortXmtFramesDiscXceedQDepth

• statPortXmtBytesDiscXceedQDepth

• statPortXmtFramesDuringLMIAlarm

• statPortXmtBytesDuringLMIAlarm

• statPortRcvStatusInquiry

• statPortRcvInvalidRequest

• statPortRcvUNISeqMismatch

• statPortXmtStatus

• statPortXmtAsynchUpdate

• statPortUNISignallingTimeout

• statPortXmtStatusInquiry

• statPortRcvStatus

• statPortRcvAsynchUpdate

• statPortRcvNNISeqMismatch,

• statPortNNISignallingTimeout

Frame Relay Channel Counters

• statChanRcvFrames

• statChanRcvBytes

• statChanRcvFramesDE

• statChanRcvBytesDE

• statChanRcvFramesDiscard

• statChanRcvBytesDiscard

• statChanRcvFramesDiscXceedQDepth

• statChanRcvBytesDiscXceedQDepth

• statChanRcvFramesDiscXceedDEThresh

• statChanXmtFrames

• statChanXmtBytes

• statChanXmtFramesFECN




• statChanXmtFramesBECN

• statChanXmtFramesDE

• statChanXmtFramesDiscard

• statChanXmtBytesDiscard

• statChanXmtFramesDiscXceedQDepth

• statChanXmtBytesDiscXceedQDepth

• statChanXmtFramesDiscCRCError

• statChanXmtFramesDiscReAssmFail

• statChanXmtFramesDuringLMIAlarm

• statChanXmtBytesDuringLMIAlarm

• statChanRcvFramesDiscUPC

• statChanXmtBytesTaggedDE

• statChanXmtFramesTaggedDE

• statChanXmtFramesInvalidCPIs

• statChanXmtFramesLengthViolations

• statChanXmtFramesOversizedSDUs

• statChanXmtFramesUnknownProtocols

• statChanRcvFramesUnknownProtocols

• statChanSecUpTime

• statChanRcvBytesTaggedDE

• statChanRcvFramesTaggedDE

• statChanRcvBytesTaggedDE

• statChanRcvFramesTaggedDE

FRSM-T1E1The following counters are provided for the FRSM-T1E1 cards:

• Frame Relay Port Counters

• Received frames discarded due to Aborts

• Received frames discarded due to illegal header (EA bit)

• Received frames discarded due to CRC errors

• Received frames discarded due to alignment errors

• Received frames discarded due to unknown DLCI

• Received frames discarded due to illegal frame length

• Received frames discarded due to DE threshold exceeded

• Received frames with DE already set

• Received frames with FECN already set

• Received frames with BECN already set




• Received frames tagged FECN

• Received frames

• Received bytes

• Transmit frames discarded due to underrun

• Transmit frames discarded due to Abort

• Transmit frames discarded due to egress Q-depth exceeded

• Transmit bytes discarded due to egress Q-depth exceeded

• Transmit frames discarded due to egress DE threshold

• exceeded Transmit frames

• Transmit bytes

• Transmit Frames with FECN set

• Transmit Frames with BECN set

• LMI receive status inquiry request count

• LMI transmit status inquiry request count

• LMI invalid receive status count

• LMI signaling protocol (keep alive time-out count)

• LMI sequence number error count

• LMI receive status transmit count (in response to request)

• LMI transmit status transmit count (in response to request)

• Transmit frames during LMI alarm

• Transmit bytes during LMI alarm

• LMI update status transmit count (in response to configuration changes)

Frame Relay Channel Counters

• Number of frames received

• Number of bytes received

• Number of frames received with DE already set

• Number of bytes received with DE already set

• Number of frames received with unknown DLCI

• Number of frames received but discarded

• Number of received bytes discarded

• Number of received bytes discarded due to exceeded Q-depth

• Number of frames received and discarded due to: intershelf alarm

• exceeded DE threshold

• exceeded Q depth

• Number of frames received with FECN set

• Number of frames received with BECN set

• Number of frames received tagged FECN

• Number of frames received tagged BECN




• Number of frames transmitted

• Number of bytes transmitted

• Number of frames transmitted with DE set

• Number of frames discarded due to reassembly errors

• Number of frames transmitted during LMI logical port alarm

• Number of frames transmitted with FECN set

• Number of frames transmitted with BECN set

• Number of transmit frames discarded

• Number of transmit bytes discarded

• Number of transmit frames discarded due to: CRC error

• egress Q depth exceeded

• egress DE threshold exceeded source abort

• physical link failure (T1)

ATM Cell-Related Counters

• Number of cells transmitted to PXM

• Number of cells transmitted with CLP bit set

• Number of OAM AIS cells transmitted

• Number of OAM FERF cells transmitted

• Number of BCM cells transmitted

• Number of OAM end-end loopback cells transmitted

• Number of OAM segment loopback cells transmitted

• Number of cells received from PXM

• Number of cells received with CLP bit set

• Number of OAM AIS cells received

• Number of OAM FERF cells received

• Number of BCM cells received

• Number of OAM end-end loopback cells received

• Number of OAM segment loopback cells received

• Number of OAM cells discarded due to CRC-10 error

AUSM/BThe following counters are provided for AUSM/B:

• Line Counters

• LOS occurrences

• OOF occurrences

• Remote loss of signal/frame (RAI) occurrences

• All ones received (AIS) occurrences




• Bipolar violation occurrences

• Cyclic redundancy check (CRC) error occurrences

• Line code violation (LCV)

• Line errored second (LES)

• Line severely errored second (LSES)

• Code violation (CV)

• Errored Second (ES)

• SES

• SEFS

• AISS

• UAS

Port Counters (IMA ports)

• Number of cells received from the port

• Number of cells received with unknown VPI/VCI

• Last unknown VPI/VCI received

• Number of cells discarded due to error in cell header

• Number of cells received with nonzero GFC field

• Number of cells transmitted to the port

• Number of cells transmitted for which EFCI was set

• Number of egress cells discarded because of service interface physical layer alarm

Channel Counters

• Ingress

– Number of cells received from the port on the virtual connection (VC)


– Number of cells received with EFCI = 1

– Number of cells received but discarded because queue exceeded queue depth

– Number of cells received but discarded because queue exceeded CLP threshold

– Number of cells received for which CLP was set because of UPC violations

• Peak queue depth

– Number of cells transmitted to cell bus

– Number of cells transmitted to cell bus for which EFCI was set

– Number of cells for transmission to cell bus discarded because of shelf alarm

– Number of OAM cells received and discarded


– Number of RDI FERF cells received


– Number of segment loopback cells transmitted to cell bus




• Egress

– Number of cells received from cell bus for this virtual circuit


– Number of cells discarded because queue exceeded queue depth (per egress queue)

– Number of cells discarded because queue exceeded CLP threshold (per egress queue)

– Number of OAM cells discarded

– Number of AIS cells transmitted to port


– Number of segment loopback cells received from cellbus

CESM-T1E1The following counters are provided for CESM-T1E1:

• FEBE count

• OOF count

• LCV count

• FER count

• CRC error count

AAL-1 SAR Counters

• Number of OAM cells received

• Number of OAM cells dropped FIFO full

• Number of SN CRCs not correctable

• Number of cells with SN different from SN+1

• Number of cells received from UTOPIA interface

• Number of cells transmitted to UTOPIA interface

ATM Layer Counters

• Number of cells transmitted

• Number of cells transmitted with CLP bit set

• Number of AIS cells transmitted

• Number of FERF cells transmitted

• Number of end-to-end loopback cells transmitted

• Number of segment loopback cells transmitted

• Number of cells received

• Number of cells received with CLP bit set

• Number of AIS cells received

• Number of FERF cells received

• Number of end-to-end loopback cells received




• Number of segment loopback cells received

• Number of OAM cells discarded because of CRC-10 error

CESM-T3E3The following counters are provided for CESM-T3E3:

• DS3 Line Group

• Dsx3LCVCurrent

• Dsx3LESCurrent

• Dsx3LSESCurrent

• Dsx3UASCurrent

• Dsx3RcvLOSCount

Channel CountersThe following channel counters are provided.

• CesReassCells

• CesGenCells

• CesHdrErrors

• CesSeqMismatchCnt

• CesLostCells

• CesChanSecUpTime

• XmtCellsFERF

• RcvCellsFERF

• XmtCellsAIS

• RcvCellsAIS

• XmtCellsSegmentLpBk

• RcvCellsSegmentLpBk

• RcvCellsDiscOAM

B-1Cisco MGX 8230 Edge Concentrator Overview


A P P E N D I X BAcronym

ABR available bit rate

ANSI American National Standards Institute

API Application programming interface

APPN Advanced Peer-to-Peer Networking

ARM alarm relay module

ASIC application-specific integrated circuit

ATM Asynchronous Transfer Mode

BT burst tolerance

BTM broadband trunk module

CAC connection admission control

CAS channel-associated signaling

CBR constant bit rate

CCITT Consultative Committee for International Telegraph and Telephone

CCS common channel signaling

CDVT cell delay variation tolerance

CIR committed information rate

Cisco IOS Cisco Internetwork Operating System

CLLM consolidated link-layer messages

CLP cell loss priority



Appendix B Acronym

CODEC Coder-Decoder

CoS class of Service

CPE customer premises equipment

CRC cyclic redundancy check

CVM Channelized voice module

dB decibels

DDS digital data service

DLCI data-link connection identifier

DS1 digital signal level 1

DS0 digital signal level 0 (24 DS0s in a DS1)

DS0A mechanism to carry a subrate DDS channel in a DS0

DSU data service unit

EEPROM electrically erasable programmable read-only memory

EFCI Explicit Forward Congestion Indication

EIA Electronic Industries Association

ELMI enhanced local management interface

EMI electromagnetic interference

ER explicit rate

ETSI European Telecommunications Standards Institute

FCI forward congestion indicator

FRAD Frame Relay access device

FRM Frame Relay module

GBps Gigabits per second

HDB3 line code type used on E3 circuits

HDLC High-Level Data-Link Control

HDM high-speed data module



Appendix B Acronym

HEC header error control

IEC International Electrotechnical Commission

IETF Internet Engineering Task Force

ILMI Integrated Local Management Interface

IMA inverse multiplexing over ATM

IP Internet Protocol

ISDN Integrated Service Digital Network

KBps Kilobits per second

LAN Local-area network

LDI low-speed data interface

LDM Low-speed data module

LED light emitting diode

LMI local management interface

LOS loss of signal

LSB least significant bit

Mbps megabits per second

MCR minimum cell rate

MIB management information base

MIPS millions of instructions per second

MMF multimode fiber

MPLS multiprotocol Level Switching

MSB most significant bit

NNI Network-to-Network Interface

NPM network processor module

NTM network trunk module

OAM Operation, Administration, and Maintenance



Appendix B Acronym

OC optical carrier

OSPF open shortest path first

PBX private branch exchange

PCM pulse code modulation

PCR peak cell rate

PCS Port Concentrator Shelf

PEM Power Entry Module

PLCP physical layer convergence procedure

P-NNI Private Network-to-Network Interface

PoP point of Presence

PPP point-to-Point Protocol

PVC permanent virtual circuit

QoS quality of Service

RFI radio frequency interference

RPS repetitive pattern suppression

SAC service activation center

SCM system clock module

SCR sustainable cell rate

SDH Synchronous Digital Hierarchy

SDLC Synchronous Data-Link Control

SLA Service Level Agreement

SMDS Switched Multimegabit Data Service

SMF single-mode fiber

SNA Systems Network Architecture

SNMP Simple Network Management Protocol

SONET Synchronous Optical Network



Appendix B Acronym

SPX Sequenced Packet Exchange

STM Synchronous Transport Module

SVC switched virtual circuit

TCP Transmission Control Protocol

TDM time-division multiplexing

TDP tag distribution protocol

TM traffic management

TR technical reference

UBR unspecified bit rate

UFM Universal Frame Relay module

UNI User-Network Interface

UVM universal voice module

VAD voice activity detection

VBC variable bit rate

VC virtual circuit

VCI virtual channel identifier

VD virtual destination

VF voice frequency

VNS voice network switching

VoFR Voice over Frame Relay

VoIP Voice over IP

VP virtual path

VPI virtual path identifier

VPN virtual private network

VS virtual source

VSI virtual switch interface



Appendix B Acronym

VToA Voice transport over ATM

WAN wide-area network

ZCS zero code suppression

IN-1Cisco MGX 8230 Edge Concentrator Overview


I N D E X

A

AAL5 4-4

ATM UNI Service Module

MGX-AUSM/B-8E1 4-2

MGX-AUSM/B-8T1 4-2

AX-CESM-8E1


AX-CESM-8T1


C

caution

definition xvii

Circuit Emulation Service Module

AX-CESM-8E1 4-2

AX-CESM-8T1 4-2

Cisco CD-ROM xiii

CiscoView 6-19

Cisco WAN Manager 6-20

D

DC PEM 2-9

DC Power Entry Module 2-9

F

Frame Service Module

MGX-FRSM-2-CT3 4-2

MGX-FRSM-2E3T3 4-2

MGX-HS2/B 4-2

M

MGX 8230 Installation and Configuration

manual organization xiii

MGX-AUSM/B-8E1

ATM UNI Service Module 4-2

MGX-AUSM/B-8T1

T1 ATM UNI Service Module 4-2

MGX-HS2/B

unchannelized HSSI lines 4-2

N

Network Management 6-1

P

power entry module (PEM) 2-9

PXM1 3-1

R

Related documentation for IGX 8450 xiv

Route Processor Module (RPM) 4-3, 4-30

S

Service Resource Module (SRM) 4-1, 4-23

T

T1

MGX-AUSM/B-8T1 4-2

Index

IN-2Cisco MGX 8230 Edge Concentrator Overview


T3

channelized frame relay lines 4-2

Traffic management 7-1

V

VISM 4-3, 4-16

W

warning

definition xvii

Cisco Reader Comment Card€¦ · Contents iv Cisco MGX 8230 Edge Concentrator Overview Release...

Documents

Transcript of Cisco Reader Comment Card€¦ · Contents iv Cisco MGX 8230 Edge Concentrator Overview Release...