getting started with spectrum’s cable broadband solution...

Getting Started with SPECTRUM’s Cable Broadband Solution

Document 9035098

Device Management

Titlepage


Copyright Notice

Document 9035098. Copyright © April 2002 by Aprisma Management Technologies, Inc. All rights reserved worldwide. Use, duplication, or disclosure by the United States government is subject to the restrictions set forth in DFARS 252.227-7013(c)(1)(ii) and FAR 52.227-19.

Liability Disclaimer

Aprisma Management Technologies, Inc. (“Aprisma”) reserves the right to make changes in specifications and other information contained in this document without prior notice. In all cases, the reader should contact Aprisma to inquire if any changes have been made.

The hardware, firmware, or software described in this manual is subject to change without notice.

IN NO EVENT SHALL APRISMA, ITS EMPLOYEES, OFFICERS, DIRECTORS, AGENTS, OR AFFILIATES BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS) ARISING OUT OF OR RELATED TO THIS MANUAL OR THE INFORMATION CONTAINED IN IT, EVEN IF APRISMA HAS BEEN ADVISED OF, HAS KNOWN, OR SHOULD HAVE KNOWN, THE POSSIBILITY OF SUCH DAMAGES.

Trademark, Service Mark, and Logo Information

SPECTRUM, IMT, and the SPECTRUM IMT/VNM logo are registered trademarks of Aprisma Management Technologies, Inc., or its affiliates. APRISMA, APRISMA MANAGEMENT TECHNOLOGIES, the APRISMA MANAGEMENT TECHNOLOGIES logo, MANAGE WHAT MATTERS, DCM, VNM, SpectroGRAPH, SpectroSERVER, Inductive Modeling Technology, Device Communications Manager, SPECTRUM Security Manager, and Virtual Network Machine are unregistered trademarks of Aprisma Management Technologies, Inc., or its affiliates. For a complete list of Aprisma trademarks, service marks, and trade names, go tohttp://www.aprisma.com/manuals/trademark-list.htm.

All referenced trademarks, service marks, and trade names identified in this document, whether registered or unregistered, are the intellectual property of their respective owners. No rights are granted by Aprisma Management Technologies, Inc., to use such marks, whether by implication, estoppel, or otherwise. If you have comments or concerns about trademark or copyright references, please send an e-mail to [email protected]; we will do our best to help.

http://www.aprisma.com/manuals/trademark-list.htm


Restricted Rights Notice

(Applicable to licenses to the United States government only.)

This software and/or user documentation is/are provided with RESTRICTED AND LIMITED RIGHTS. Use, duplication, or disclosure by the government is subject to restrictions as set forth in FAR 52.227-14 (June 1987) Alternate III(g)(3) (June 1987), FAR 52.227-19 (June 1987), or DFARS 52.227-7013(c)(1)(ii) (June 1988), and/or in similar or successor clauses in the FAR or DFARS, or in the DOD or NASA FAR Supplement, as applicable. Contractor/manufacturer is Aprisma Management Technologies, Inc. In the event the government seeks to obtain the software pursuant to standard commercial practice, this software agreement, instead of the noted regulatory clauses, shall control the terms of the government's license.

Virus Disclaimer

Aprisma makes no representations or warranties to the effect that the licensed software is virus-free.

Aprisma has tested its software with current virus-checking technologies. However, because no antivirus system is 100 percent effective, we strongly recommend that you write-protect the licensed software and verify (with an antivirus system in which you have confidence) that the licensed software, prior to installation, is virus-free.

Contact Information

Aprisma Management Technologies, Inc.

273 Corporate Drive

Portsmouth, NH 03801

Phone: 603-334-2100

U.S. toll-free: 877-468-1448

Web site: http://www.aprisma.com

http://www.aprisma.com


ContentsIntroduction 5

Network Management Factors 6

SPECTRUM Device Support 9

CMTS Models ..............................................................................................................9CMTS Model Device Support ................................................................................9CMTS Model DOCSIS Support ...........................................................................10CMTS Fault Isolation, Polling, and Logging ........................................................10

Lightweight Models ....................................................................................................10Lightweight Model Device Support ......................................................................10Lightweight Model Fault Isolation ........................................................................11Lightweight Model Polling and Logging ...............................................................12Lightweight Model DOCSIS Support ...................................................................12

Broadband Service Container Models .......................................................................13Standard Container Characteristics ........................................................................13Broadband Service Container Characteristics ........................................................18

HFC Device Event Modeling ......................................................................................24DOCSIS MIB Support ................................................................................................25Vendor MIB Support ...................................................................................................28

Organizing Models in SPECTRUM 29

Organizing By CMTS .................................................................................................29Organizing By CMTS Upstream / Downstream ..........................................................32

Fault Isolation and Root Cause Analysis Scenarios 36

Scenarios When Organizing By CMTS ......................................................................36CMTS Interface, HFC Plant or Cable Modem Down ..............................................36CMTS or Topologically Higher Device Down .........................................................38

Organizing By CMTS Upstream / Downstream ..........................................................41

Index 45


Introduction

This section introduces SPECTRUM's cable broadband solution to first-time users.

This document provides a starting point for users managing cable broadband networks with SPECTRUM. To use this documentation effectively, you must be familiar with the information covered by the other SPECTRUM documents listed below.

• Getting Started with SPECTRUM for Operators

• Getting Started with SPECTRUM for Administrators

• How to Manage Your Network with SPECTRUM

• SPECTRUM Views

• SPECTRUM Menus

• SPECTRUM Icons

• SPECTRUM Software Release Notice

• Database Management

• SPECTRUM Concepts Guide

The rest of this document is organized as follows:

• Network Management Factors on Page 6

• SPECTRUM Device Support on Page 9

• Organizing Models in SPECTRUM on Page 29

• Fault Isolation and Root Cause Analysis Scenarios on Page 36


Network Management Factors

This section describes the elements of a broadband network and the Cable Broadband Models in SPECTRUM's Cable Broadband Solution.

For a cable broadband management system to be effective, it must meet the challenge of acquiring an array of information available from a variety of devices diversely deployed to meet the demands of a multitude of business requirements. To be useful to managers, the acquired information must be displayed in a meaningful manner. Figure 1 illustrates a simple cable broadband network deployment for discussion.

Figure 1: Basic Components of a Cable Broadband Network

HFC Devices TCP/IP DevicesTCP/IP Devices



The cable broadband network includes Hybrid Fiber Coax (HFC) devices and TCP/IP devices. The HFC devices consist of Up Converters, Diplex Filters, Attenuators, Amplifiers, Splitters, and Power Supplies. The TCP/IP devices consist of DHCP servers, Cable Modem Termination Systems (CMTS), and Cable Modems (CM). The HFC components gather HFC information through proprietary communication methods. The TCP/IP devices gather network information through the Simple Network Management Protocol (SNMP).

In addition to the challenges imposed by the diversity of devices and deployments, an added complexity for network managers is the need to control SNMP traffic. Using SNMP, CMs communicate information to CMTSs over the HFC network using shared channel frequencies. The downstream frequency channel aggregates information from the CMTSs to the CMs and the upstream frequency channels aggregate information from the CMs to the CMTSs. Managers must have visibility into the amount of SNMP traffic that is generated on this shared media in order to maximize network efficiencies, plan for network growth, and have visibility into the operational status of devices for purposes of fault isolation and root cause analysis.

SPECTRUM’s cable broadband network management solution meets the challenges summarized above by:

• Supporting devices and MIBs produced by a variety of vendors (see Table 1 on Page 8)

• Limiting ICMP and SNMP traffic by introducing modeling techniques designed for cable broadband networks

• Providing a mechanism for logically grouping device models

• Providing a means for aggregating alarms from selected devices and setting aggregate threshold values based on mission criticality

• Providing fault isolation and root cause analysis down to the port level



Table 1 lists the SPECTRUM management modules and documentation related to cable broadband devices.

Table 1: Management Modules and Documentation

Document Title Supports Management Module...

Broadband Service Containers SM-BSC1000

DOCSIS Devices SM-DCS1000

DOCSIS Applications SM-DCSCMN

Cisco uBR72xxCMTS SM-CIS1008

Terayon BroadbandEdge2000/TeraLink 1000

SM-TRN1000

Motorola CDLP SM-MOT1001

LANCity Cable TV Modem SM-LCH1000

RiverDelta BSR 1000/64000 SM-RVD1000

Telecom CUDA 12000 SM-ADC1000

Riverstone SmartSwitch Router SM-RST1000

Scientific Atlanta Explorer HCT SM-SFA1000

AM Communications SM-AMC1000

Cheetah Gateway Integration SM-SFA1000


SPECTRUM Device Support

This section describes the cable broadband models and their functionality in SPECTRUM.

SPECTRUM provides efficient information gathering by limiting ICMP and SNMP traffic across the cable broadband network. This is accomplished by providing four model paradigms as follows:

• CMTS Models provide the full information gathering aspects of a GnSNMPDev model type.

• Lightweight Models (Page 10) provide focused information gathering for CMs and set-top boxes.

• Broadband Service Container Models (Page 13) provide a method of logically grouping Lightweight Models.

• HFC Device Event Modeling (Page 24).

Each of these models is designed to focus information gathering to meet management’s need for useful information, eliminate distracting information, and reduce the impact of polling on an efficiently operating cable broadband network.

CMTS ModelsSPECTRUM’s support of CMTS devices and DOCSIS-compliant devices is described below.

CMTS Model Device SupportSPECTRUM supports a variety of CMTS devices from vendors including Cisco, Terayon, Motorola, Nortel LanCity, River Delta (acquired by Motorola), ADC, and Riverstone (see Table 1 on Page 8). The CMTS device models have standard device support including model creation for applications and interfaces, DevTop and Device Interface views, interface connectivity/port resolution, autodiscovery, and fault isolation



capabilities. These device models are based on the standard support provided by the GnSNMPDev model type.

CMTS Model DOCSIS SupportSPECTRUM also supports CMTS devices that comply with DOCSIS (see DOCSIS MIB Support on Page 25).

CMTS Fault Isolation, Polling, and LoggingFor information about fault isolation, polling, and logging, see the How to Manage Your Network with SPECTRUM document.

Lightweight ModelsLightweight Models include CMs and set-top boxes. The lightweight model paradigm was developed to support devices that do not require the full functionality that GnSNMPDev models provide.

Lightweight Model Device SupportSPECTRUM supports the Motorola cable modem, a DOCSIS compliant cable modem, and the Scientific Atlanta set-top box. A cable broadband network can include thousands of these devices; therefore, the models of these devices are designed as lightweight models. The major intent of the lightweight series of models was to provide a way to represent and collect meaningful SNMP data from all the cable modems and set-top boxes while limiting the effects of polling on the network.

The implementation of the new lightweight model paradigm has many significant differences over conventional GnSNMPDev models. The lightweight models have increased model capacity on a SpectroSERVER, reduced SNMP traffic, and reduced memory and CPU usage. However, the lightweight models do not create interface models for port resolution, and do not participate in fault isolation. They only communicate SNMP to their real world counterpart, whereas a GnSNMPDev model will also try to use ICMP ping to contact the device.



Lightweight Model Fault IsolationBecause the Lightweight Model Architecture does not participate in fault isolation, there is no value from a fault isolation standpoint of connecting these models by pipes. One other major difference is that lightweight models do not alarm by default. If contact with the device via SNMP has been lost, the model will turn gray and go into a suppressed state. This is done to keep the alarm manager from being flooded with red alarms from cable or set-top models losing contact. This functionality is configurable and can be set to alarm or not to alarm. Every lightweight model has a configuration view similar to the one shown in Figure 2 (Page 11).

Figure 2: Configuration View for Lightweight Models



Lightweight Model Polling and LoggingLightweight models do not log or poll any attributes. For this reason, they will keep in contact with the device at three times the polling interval. This is why lightweight models do not turn active over a polling interval. Lightweight models are not designed to Autodiscover or Model by IP. Lightweight models can only be modeled by model type.

In the future, SPECTRUM will contain auto-population features that will create and update cable modem models from the CMTS MIB tables.

Lightweight Model DOCSIS SupportSupport also includes a generic DOCSIS compliant CM device model (Figure 10 on Page 27) for those vendor devices that SPECTRUM does not support but are DOCSIS compliant (see DOCSIS MIB Support on Page 25).

Note:Note:

Modeling cable modems over the HFC network is not advised. Because most cable modems change IP addresses on a regular basis, there would be too much SNMP traffic generated to update cable modem models.



Broadband Service Container ModelsThe broadband service container model (BbSrvContainer) was designed to provide a mechanism for the logical grouping of Lightweight Models (Page 10). To see how the broadband service container differs from other standard containers, first consider the process used by a standard container to monitor the condition of models it collects, described below. This process for broadband service containers is described beginning on Page 18.

Standard Container CharacteristicsWith standard containers, such as a Network or LAN, the container is responsible for summing the condition value of every device (or container) it collects. This sum is written to an attribute called composite condition. The composite condition is then compared to the rollup threshold values of yellow, orange and red. The rollup thresholds are defined for minor, major, and critical severities. For every severity state, there is a significance level that can be defined. If the composite condition exceeds a rollup threshold then the rollup condition assumes that threshold condition and color. This process for standard containers is detailed below (in this case, for a Network container model).

The Internal Attributes section of the Model Information View for the Network Model (Page 17) contains two attributes, namely Condition Value and Composite Condition. The Composite Condition attribute displays the sum of the condition values of every device (or container) collected by this container. The value of Composite Condition is compared with the Rollup Threshold section, where Yellow, Orange, and Red Thresholds are set by the user. If the value of Composite Condition exceeds a threshold, the container will set the Condition Value attribute to that criticality. Table 2 (Page 14) shows the possible condition values.

Note:Note:

For more information about rollup condition thresholds and significance levels, see the How to Manage Your Network with SPECTRUM document.



Once the Condition Value of the Network container assumes a criticality of Yellow, Orange or Red, the Significance Level section of the container’s Model Information view becomes a factor. That is, the current Condition Value of the container is compared with the Significance Level values and the significance value of the container is then set, based on this comparison.

Table 2: Condition Values

Condition Value Alarm Status Label Color

0 Normal Green

1 Minor Yellow

2 Major Orange

3 Critical Red



Consider the following example of how this would be implemented, assuming everything was set to default values (as shown in Figure 3).

Figure 3: Model Information View for the Network Model



Let's say a Network model collected four device models, as shown in Figure 4 (Page 16). The sum of the condition values of the device models collected by the Network container in Figure 4 is 11. This value (11) is written to the Network container’s Composite Condition attribute. Next, the Rollup Condition of the Network container is set by comparing the Composite Condition (11) with the values for Rollup Thresholds, which are set by the user in the Model Information view of the Network container. When Composite Condition is compared with the Rollup Threshold values (3, 6, and 10), it would violate the Red threshold (10) and set the Condition Value of the Network container model to 7, or Red. So, after comparing 7 (Red) to the values listed for Significance Level, the significance value of this container would be set to 7, as shown in Figure 5 (Page 17).

Figure 4: Rollup Thresholds and Significance

Cond. = YellowCond. Value = 1

Cond. = RedCond. Value = 7

Cond. = OrangeCond. Value = 3

Cond. = GreenCond. Value = 0

Condition = GreenComposite Cond. = 11

Rollup Cond. = RedCond. Value = 7

Network ContainerModel

Device Models




11

a) Sets to 11

b) 11 > Red

d) Significance Level of the Network Container would be set to 7

7

c) Sets to 7 (Red)



Broadband Service Container CharacteristicsIn contrast to standard containers, the broadband service container monitors the percentage of models it has collected that have lost contact compared with the total sum of models (excluding any model still in the initial state). The percentage thresholds are defined for minor, major and critical severities. For every severity state, there is a significance level that can be defined. However, when a percentage threshold has been violated, the broadband service container assumes the condition associated with the threshold. The broadband service container assumes a condition to reflect the condition of the network represented by the devices grouped in the container. This is done because the alarms on the individual cable or set-top models are suppressed. The values for Rollup Thresholds and Significance Level can be configured through the Model Information view as shown in Figure 6, Model Information View for the BbSrvContainer Model, on Page 19.



Figure 6: Model Information View for the BbSrvContainer Model



The Internal Attributes section of the Model Information View for the BbSrvContainer Model (Page 19) contains two attributes, namely Condition Value and Percentage Down. The Percentage Down attribute displays the percentage of the devices collected by this container that have lost contact. The value of Percentage Down is compared with the Rollup Threshold section, where Yellow, Orange, and Red Thresholds are set by the user. If the value of Percentage Down exceeds a threshold, the container will set the Condition Value attribute to that criticality. Table 3 shows the possible condition values.

Once the Condition Value of the Broadband Service Container assumes a criticality of Yellow, Orange or Red, the Significance Level section of the Model Information view becomes a factor. That is, the current Condition Value of the BbSrvContainer is compared with the Significance Level values and the significance value of the BbSrvContainer is then set, based on this comparison.

Consider the following example of how this would be implemented, assuming everything was set to default values (as shown in Figure 7 on Page 21). Let's say a Network model collected a BbSrvContainer model. The BbSrvContainer model collected four cable modem models. If three of these cable modems went down, then the Percentage Down (see Figure 7 on Page 21) would be 75. When this value was compared with the Rollup Threshold values (50, 70, and 90), it would violate the Orange threshold (70) and set the Condition Value of the BbSrvContainer model to 2, or Orange.

Table 3: Condition Values

Condition Value Alarm Status Label Color

0 Normal Green

1 Minor Yellow

2 Major Orange

3 Critical Red



So, after comparing 2 (Orange) to the values listed for Significance Level, the significance value of this BbSrvContainer would be set to 3, as shown in Figure 7.

Figure 7: Model Information View for the BbSrvContainer Model

a) 75 in thisexample

c) Sets to 2(Orange)

d) Container now has a Level of 3

e) Rolls up toNetwork Container

b) Comparedto Thresholds

Significance



Next, the Network model (a standard container) would set its Composite Condition value (Figure 8 on Page 23) to 3 because this value is a sum of all the collected models' significances. This again would be compared against the Network model Rollup Thresholds which, at 3, is Yellow. The Rollup Condition would then assume a condition of Yellow. Finally, the significance level of the Network Container model would be set to 1.

Models of cable modems and set-top boxes should never be directly connected in SPECTRUM to models of CMTS devices. To ensure proper fault isolation for CMs and set-top boxes, the broadband service container model must be used to group models of these lightweight devices.




a) Is set to 3 by BbSrvContainer

b) 3 = Yellow

c) Significance Level of the Network Container would be set to 1

3



HFC Device Event ModelingSPECTRUM does not model HFC devices. Most HFC devices (see Figure 1 on Page 6) communicate with a Headend Communications Controller (HEC). The communication protocol between the HEC and HFC devices is usually proprietary. For example, Acterna (Cheetah) and AM Communications developed a software application to communicate with their respective HECs. These software applications are capable of sending SNMP traps. SPECTRUM collects and processes these traps (sent from either software application) via SPECTRUM's Southbound Gateway.

When an SNMP trap is sent from the software application, the Southbound Gateway analyzes the data and creates a new event model, if one has not already been created. From that point forward, traps sent from the application are mapped to that event model. The traps will be further processed and events/alarms created on the event model.



DOCSIS MIB SupportSupport also includes a generic DOCSIS compliant CMTS device for those vendor devices that SPECTRUM does not support but are DOCSIS compliant. In the case of these devices, the CMTS models will have the DOCSIS information available in the application view as applications. There is an application for each of the DOCSIS MIBs (shown in Table 4), which will discover automatically if the device supports the MIB. Figure 9 (Page 26) shows an example of DOCSIS applications (DOCSIS BPI and DOCSIS IF Applications are shown).

Table 4: Listed DOCSIS 1.0 and 1.1 MIB Support

DOCSIS MIB Listing 1.0 Standard

1.1 Standard

Support by SPECTRUM

RFC 2669 - Cable Device MIB YES YES YES

RFC 2670 - Radio Frequency Interface YES YES YES

RFC 3083 - Baseline Privacy Interface YES YES YES

Quality of Service NO YES YES

Baseline Privacy Interface Plus NO YES YES



Figure 9: Application View for a CMTS



In the case of the DOCSIS compliant cable modems, the devices should be modeled by model type as a DocsisCM model type. The DocsisCM lets you access all five DOCSIS MIBs. Figure 10 shows an example of the DocsisCM menu.

Figure 10: DocsisCM Icon Subviews Menu



Vendor MIB Support Depending on the management module, vendor-specific information can be found either off the device model or in the Application view in the form of an application. Table 5 lists the device-specific SPECTRUM management modules and documentation related to cable broadband devices.

Table 5: Device-Specific Management Modules and Documentation

Document Title Supports Management Module...

Cisco uBR72xxCMTS SM-CIS1008

Terayon BroadbandEdge2000/TeraLink 1000

SM-TRN1000

Motorola CDLP SM-MOT1001

LANCity Cable TV Modem SM-LCH1000

RiverDelta BSR 1000/64000 SM-RVD1000

Telecom CUDA 12000 SM-ADC1000

Riverstone SmartSwitch Router SM-RST1000

Scientific Atlanta Explorer HCT SM-SFA1000


Organizing Models in SPECTRUM

In this section, ideas for organizing cable modem and set-top box models are introduced.

This section describes the following standard modeling and grouping implementations that will enable you to understand root-cause and impact analysis of the cable broadband network. It is recommended that the broadband service container model be used for collecting cable modem and set-top box models. The broadband service container was specifically designed to work with and complement the functionality of the cable modem and set-top box models.

The two methods for organizing models are listed below. The second method is recommended for providing fault isolation down to the port level.

• Organizing By CMTS• Organizing By CMTS Upstream / Downstream (Page 32)

Organizing By CMTSOrganizing the cable modem or set-top box models by CMTS provides a basic way of understanding the cable broadband network topology. This implementation will let you see the relationships between the CMTS and the cable modems that are connected to it. Figure 11 (Page 30) and Figure 12 (Page 31) show an example of this implementation.

Organiz ing Models in SPECTRUM


Figure 11: Topology View: CMTS Connected to BbSrvContainer Model

Figure 11 and Figure 12 show a BbSrvContainer model connected to a CMTS model. The BbSrvContainer landscape (Figure 12 on Page 31) contains an Off-Page reference of the CMTS as well as the cable modem models.

Here are the steps for creating this simple example:

1 From the topology or any container, click the “Edit” button to go into edit mode.

2 Model the CMTS devices by IP or Model Type.

3 Create by Model Type the BbSrvContainer.



4 Connect a pipe from the CMTS device model to the BbSrvContainer model.

5 Close out of edit mode.

6 Drill into the BbSrvContainer.

7 From the BbSrvContainer Topology, click the “Edit” button to go into edit mode.

8 In the BbSrvContainer Topology, create models of the DOCSIS compliant cable modem devices by model type DocsisCM.


Figure 12: BbSrvContainer Collecting Two Cable Modem Models and a CMTS Off Page Reference



Organizing By CMTS Upstream / DownstreamLogically grouping cable modems or set-top boxes by either upstream or downstream device adds a level of refinement to identifying impact and scope, i.e., interface resolution helps in identifying a particular interface potentially causing a problem.

Figure 13 through Figure 15 (Page 34) show an example of broadband service containers resolved to interfaces.

Figure 13: Network View: CMTS Connected to BbSrvContainer Model



Figure 14: CMTS DevTop View: Upstream Interface Model Connected to BbSrvContainer Model



Figure 15: BbSrvContainer Topology Showing the DocsisCM Models

Notice in Figure 13 (Page 32) that when the broadband service container is resolved to an interface that the gold pipe connects the broadband service container and the CMTS model.

Here are the steps to creating this simple example:

1 From the topology or any container, click the “Edit” button to go into edit mode.

2 Model the CMTS devices by IP or Model Type.

3 Create by model type the BbSrvContainer.

4 Copy the BbSrvContainer model.


6 Open up the DevTop View of the CMTS model.

7 From the CMTS DevTop, click the “Edit” button to go into edit mode.

8 Paste the BbSrvContainer model on to the Upstream or Downstream interface model that the cable modem models belong to.




10 Drill into the BbSrvContainer.

11 From the BbSrvContainer Topology, click the “Edit” button to go into edit mode.

12 In the BbSrvContainer Topology, create by model type DocsisCM for the DOCSIS compliant cable modem devices.



Fault Isolation and Root Cause Analysis Scenarios

This section describes scenarios for Fault Isolation and Root Cause Analysis.

Scenarios When Organizing By CMTSThe following lost contact scenarios are described in this section:

• CMTS Interface, HFC Plant or Cable Modem Down• CMTS or Topologically Higher Device Down (Page 38)

CMTS Interface, HFC Plant or Cable Modem DownIn the first scenario (shown in Figure 16 on Page 37 and Figure 17 on Page 38), loss of contact with the cable modems is due either to the CMTS interface going down, the HFC plant going down or the cable modem going down. The result of the loss of contact is that the cable modem models will turn gray and the container will alarm to a severity based on the percent threshold reach. In this case, it is critical severity as Figure 16 and Figure 17 show.

Fault Iso lat ion and Root Cause Analysis Scenar ios


Figure 16: Critical Alarm on the BbSrvContainer Model



Figure 17: Cable Modems in a Suppressed State From Loss of Contact

CMTS or Topologically Higher Device DownIn the second scenario, loss of contact with the cable modems is due either to the CMTS going down or to a device higher up in the network topology going down. The result is that both the cable modem models and the container will turn gray. This can be due to either a critical alarm or a suppressed alarm on the CMTS model. The example is shown in Figure 18 (Page 39) and Figure 19 (Page 40). However, the trigger for when fault isolation will occur will be when the broadband service container reaches a percentage down threshold. Therefore, not all the cable modem models need to be lost in order for the broadband service container to perform fault isolation. The same is true when the CMTS model re-establishes contact. The broadband service container model must reach another threshold before the fault isolation check is made.



Figure 18: Critical Alarm on the CMTS Model and Suppressed Alarm on the BbSrvContainer Model



Organizing By CMTS Upstream / DownstreamWhen the broadband service container is resolved down to the logical interface, the same results will occur as in the two scenarios described in the previous section. Figure 20 through Figure 23 (Page 44) show the results.

Figure 20: Critical Alarm on the BbSrvContainer Model



Figure 22: Critical Alarm on the CMTS Model and Suppressed Alarm on the BbSrvContainer Model


Index

AADC Telecom CUDA 12000 8, 28Alarm Status 14Alarms 11AM Communications 8Attenuators 7Autodiscovery 12

BBbSrvContainer 13, 19, 20, 21, 30, 31, 32Broadband Service Container 8, 13,

22, 38Compared to Standard

Containers 18Internal Attributes 13, 20Network Example 20

CCable Broadband Models 9Cable Broadband Network

Components of 6, 7Cable Modem Termination System

(CMTS) 7Vendors of 9

Cable ModemsGray (Suppressed) Condition 11How to Model 12Lost Contact 11

Cheetah Gateway Integration 8Cisco uBR72xxCMTS 8, 28

Composite Condition Attribute 13Condition Value 13, 14, 20Configuration View, Lightweight

Models 11Container

Significance Value of 14Criticality 13, 14, 20

DDiplex Filter 7DOCSIS 12, 25DOCSIS Applications 8DOCSIS Devices 8DocsisCM model type 27, 31, 34, 35Documentation 8, 28

FFault Isolation 10, 11, 22, 38

GGnSNMPDev model type 10Gray (Suppressed) Condition 11

HHeadend Communications Controller

(HEC) 24HFC Network 24

Index Index


Cable Modems and 12Hybrid Fiber Coax (HFC) Devices 7

IICMP Ping 10

LLabel Color 14LANCity Cable TV Modem 8, 28Lightweight Model Type 10

Alarms and 11Configuration View of 11Differences from GnSNMPDev 10Polling 12Rationale 10

Logging 12Loss of Contact 11, 36

MModel Information View 14, 15, 17, 18,

19, 21, 23Motorola

Cable Modem 10CDLP 8, 28

NNetwork Model

Example 16Nortel LANCity Cable Modem 8, 28

OOff-Page Reference, CMTS 30

PPercentage Down 20Polling 12

RRequired Reading 5RiverDelta BSR 1000/64000 8, 28Riverstone SmartSwitch Router 8, 28Rollup Threshold Values 13Rollup Thresholds 18

SScientific Atlanta Explorer HCT 8, 28Scientific Atlanta, set-top box 10Severity State 13, 18Significance Level 13, 14, 18, 20Simple Network Management Protocol

(SNMP) 7SM-ADC1000 8, 28SM-AMC1000 8SM-BSC1000 8SM-CIS1008 8, 28SM-DCS1000 8SM-DCSCMN 8SM-LCH1000 8, 28SM-MOT1001 8, 28SM-RST1000 8, 28SM-RVD1000 8, 28SM-SFA1000 8, 28SM-TRN1000 8, 28

Index Index


SNMP Traffic, Minimizing 10Southbound Gateway 24SpectroSERVER 10Suppressed Condition, Cable

Modems 18

TTeraLink 1000 8, 28Terayon BroadbandEdge2000 8, 28

UUp Converter 7

getting started with spectrum’s cable broadband solution...

Documents