TM202B Software Guide

Touchstone Telephony

Software Operator’s Guide (TS3.2)

Release 3.2 Standard 1.0 September 2003

ARSVD00646

Software Operator’s Guide (TS3.2) Release 3.2 Standard 1.0 Sep 2003

Touchstone Telephony

Software Operator’s Guide (TS3.2)

2002, 2003 ARRISAll rights reserved

Printed in the USA

The information in this document is subject to change without notice. The statements, configurations, technical data, and recommendations in this document are believed to be accurate and reliable, but are presented without express or implied warranty. Users must take full responsibility for their applications of any products specified in this document. The information in this document is proprietary to ARRIS.

ARRIS, ARRIS Interactive, and Touchstone are trademarks of ARRIS Licensing Company. Cornerstone is a registered trademark of ARRIS Licensing Company. All other trademarks and registered trademarks are the property of their respective holders.

Document number: ARSVD00646 Document release: Release 3.2 Standard 1.0Date: September 2003


Publication history

September 2003

Release 3.2 Standard 1.0 version of this document.

iv

Touchstone Telephony ARSVD00646 Release 3.2 Standard 1.0 Sep 2003

ContentsAudience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixAbout the Touchstone Telephony Software. . . . . . . . . . . . . . . . . . . . . . . x

Loading and Upgrading NIU Software . . . . . . . . . . . . . . . . . . . . . . . xSubscriber Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

In this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xTerminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Overview 1-1Touchstone Telephony Port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1Touchstone Telephony Modems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2

Model 102 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2Model 202 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4

TS3.2 Software Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4Enhancements from TS01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6Contents of the Software Disk. . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7

Companion Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7

Installing the Software 2-1Procedure: Installing the Software . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2

Provisioning 3-1Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Provisioning Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1Provisioning Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4

Full DQoS Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4DSX QoS Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4Voice and Signalling Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5About IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5CallP Feature Switch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5

Touchstone HomePNA Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7Compatibility Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7HomePNA Provisioning Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7Managing the HomePNA Interface . . . . . . . . . . . . . . . . . . . . . . . . .3-7

Provisioning Event Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8PacketCable Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8PacketCable (no KDC) and CPS Sequence . . . . . . . . . . . . . . . . . .3-9GUPI Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-9Single MAC/Config File Sequence . . . . . . . . . . . . . . . . . . . . . . . .3-10Setting Up the Provisioning Server Data. . . . . . . . . . . . . . . . . . . .3-10

Procedure: Configuring Alarm and Log Reporting . . . . . . . . . . . . . . .3-11Procedure: Updating the KDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15


vi

Interpreting Alarms 4-1MTA Alarm Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3Alarm Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4

Call Agent Loss of Communications . . . . . . . . . . . . . . . . . . . . . . . .4-4Power Supply Telemetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4Voice Line Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5Voice Line Total Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6

Interpreting Logs 5-1Log Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2

SNMP Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2Syslog messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2

Log Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3Cable Modem Log Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3MTA Log Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4

Common Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5NIU States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5NIU Line States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5NIU Battery States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6

Log Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-7Certificate Downloading Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8

MTA Root Certificate download Failed . . . . . . . . . . . . . . . . . . . . . .5-8MTA Security: Service Provider Certificate Chain Validation Failed . .5-8MTA Root Certificate download Retry. . . . . . . . . . . . . . . . . . . . . . .5-9MTA Root Certificate download Complete . . . . . . . . . . . . . . . . . . .5-9

MTA Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9Voice Line Diag Failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9Voice Line Diag Passed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10Voice Line State Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-10Voice Line Protection State Change . . . . . . . . . . . . . . . . . . . . . . .5-10Voice Line Loop Current Change to High . . . . . . . . . . . . . . . . . . .5-11Voice Line Loop Current Change to Normal . . . . . . . . . . . . . . . . .5-11State Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11CATV Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11Power Supply Telemetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11MTA TFTP: No Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12MTA TFTP: Successful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12MTA TFTP: File Not Found . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12MTA TFTP: Protocol Error: TFTP Init . . . . . . . . . . . . . . . . . . . . . .5-12MTA TFTP: Protocol Error: TFTP Open . . . . . . . . . . . . . . . . . . . .5-12MTA TFTP: Protocol Error: TFTP Read . . . . . . . . . . . . . . . . . . . .5-13MTA TFTP: Protocol Error: TFTP Close . . . . . . . . . . . . . . . . . . . .5-13MTA TFTP: Protocol Error: TFTP DB Access. . . . . . . . . . . . . . . .5-13MTA TFTP: Config File Error . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14MTA TFTP: Failed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14MTA PROV: Failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14MTA PROV: Successful! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14


vii

Using the Password of the Day Tool 6-1About the Password of the Day Tool . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1Procedure: Using the PWOD Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2

MIB Reference 7-1Supported MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

ARRIS Proprietary MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1DOCSIS MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1PacketCable MIBs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2Network-related MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2Imports and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3

Order of Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4

Troubleshooting 8-1Initial Battery Charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1Using MIBs for Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1

General Touchstone Information. . . . . . . . . . . . . . . . . . . . . . . . . . .8-1SNMPv2 MIBs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2Interface MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2Cable Device MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6PacketCable Event MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9MTA MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14Signaling MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-21Packet Port MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-23

LED Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-25Patterns: Normal Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-25Patterns: Startup Sequence (Telephony Modem). . . . . . . . . . . . .8-26Patterns: Startup Sequence (Telephony Port) . . . . . . . . . . . . . . .8-26

End of Call Connection Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-27Web-based Troubleshooting Interface. . . . . . . . . . . . . . . . . . . . . . . . .8-28

Standard Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-28Advanced Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-30

Procedure: Accessing the Troubleshooting Interface. . . . . . . . . . . . .8-35Procedure: Running Line Card Diagnostics . . . . . . . . . . . . . . . . . . . .8-38Procedure: HomePNA Troubleshooting . . . . . . . . . . . . . . . . . . . . . . .8-40

Appendix A: Example Files 9-1Listing of Templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1

Location of Template FIles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1MTA Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1Cable Modem Configuration Files. . . . . . . . . . . . . . . . . . . . . . . . . .9-2Text Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4

SNMP Co-existence Example Configuration File . . . . . . . . . . . . . . . . .9-5

Appendix B: Configuring the Service Provider Root 10-1Service Provider Root Provisioning for Touchstone Telephony Modems . 10-2


viii

Appendix C: SNMP Access Modes 11-1Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1

SNMPv1/v2c NmAccess Mode . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2SNMP Coexistence Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2SNMP Coexistence Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2

Configuring the Cable Modem for NmAccess Mode . . . . . . . . . . . . . .11-3Configuring SNMP access with the docsDevNmAccessTable . . .11-3Configuring Trap Transmission with the docsDevNmAccessTable. .11-4Rules for the docsDevNmAccessTable. . . . . . . . . . . . . . . . . . . . .11-5

Configuring the CM for Coexistence Mode . . . . . . . . . . . . . . . . . . . . .11-8Configuring SNMPv1/v2c only coexistence . . . . . . . . . . . . . . . . .11-9Configuring SNMPv1/v2c/v3 coexistence . . . . . . . . . . . . . . . . . .11-11Configuring SNMPv3 only coexistence . . . . . . . . . . . . . . . . . . . .11-15Configuring Trap Transmission within Coexistence Mode . . . . .11-15

Appendix D: Configuring SNMP Coexistence 12-1Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-1

Configuration File Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-1SNMP Access Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2SNMP Trap Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2

Procedure: Configuring SNMP Co-existence . . . . . . . . . . . . . . . . . . .12-3Procedure: Configuring Trap Servers. . . . . . . . . . . . . . . . . . . . . . . .12-14


1 About This DocumentThis document describes:

• procedures for installing and upgrading Touchstone™ Telephony TS3.2 software on local servers

• basic provisioning information and sample provisioning files included on the software CD

• the extensive troubleshooting information available in TS3.2, including alarms, logs, and relevant MIB objects

This document describes all the features and information available in various TS3.2 software releases. Some features described in this docu-ment may not be fully tested and supported in your specific software release version. Where possible, features supported only by specific versions are indicated in this document. See the Release Notes/Letter of Operational Considerations accompanying your software for further details.

AudienceIf you are responsible for provisioning or maintaining a ToIP network that supports Touchstone Telephony NIUs, you should read this entire manual.

This manual assumes that you have a basic understanding of DOCSIS and PacketCable standards, and a working knowledge of your provi-sioning server (including related DNS, TFTP, and DHCP servers).


x

About This Document

About the Touchstone Telephony SoftwareTouchstone Telephony software provides operating, maintenance, and troubleshooting functions for the following ARRIS NIUs:

• Touchstone Telephony Modems, models 1 and 2

• Touchstone Telephony Port, model 204A

Loading and Upgrading NIU Software

You can configure a TFTP server to automatically download the Touch-stone software to the NIU when the NIU connects to the network. You can upgrade the software by setting MIB variables in the NIU.

Subscriber Interface

Touchstone Telephony TS3.2 software provides:

• support for LED status indicators

• PacketCable-compatible interfaces to data and telephony ports

• a web-based status monitoring and troubleshooting interface (see Chapter 8, “Troubleshooting,” for details)

In this DocumentThis document contains the following information:

• Chapter 1, “Overview,” provides a brief overview of the Touch-stone Telephony product line and the features of the TS3.2 soft-ware release.

• Chapter 2, “Installing the Software,” describes the installation and upgrade procedures.

• Chapter 3, “Provisioning,” describes provisioning the Touch-stone Telephony NIUs using the PacketCable compliant and non-compliant interfaces.

• Chapter 4, “Interpreting Alarms,” describes the alarms that TS3.2 software can generate in response to NIU events.

• Chapter 5, “Interpreting Logs,” describes log messages that TS3.2 software can generate in response to NIU events.

• Chapter 6, “Using the Password of the Day Tool,” describes the password generating tool used to access advanced NIU trouble-shooting features.

• Chapter 7, “MIB Reference,” lists the standard and proprietary MIBs that apply to TS3.2 software.


About This Document

xi

• Appendix A, “Example Files,” provides example provisioning file listings.

• Appendix B, “Appendix B: Configuring the Service Provider Root,” describes how to change the root certificate used to ver-ify secure software downloading.

TerminologyThe following is a list of terms and abbreviations used in this manual.

Call Agent (CA)A device that maintains call state, and controls the line side of calls. The CA is often a portion of a Call Management Server (CMS).

Call Management Server (CMS)A generic term for the devices connecting a ToIP network to the PSTN. A CMS includes both a Call Agent (CA) and the PSTN gateway, and controls audio call connections.

CallPCall Processing. Software controlling the current state of a call.

CBRConstant Bit Rate. A data service that provides a guaranteed, fixed amount of bandwidth. Technically, it is not possible to provide actual CBR services over an IP network due to factors such as contention and latency. UGS service flows and low-latency hardware such as the ARRIS™ Cadant® C4 CMTS, however, can provide an approximation suitable for carrier-grade telephone service.

ClassifierRules used to classify packets into a Service Flow. The device compares incoming packets to an ordered list of rules at several protocol levels. Each rule is a row in the docsQosPkt-ClassTable.

A matching rule provides a Service Flow ID (SFID) to which the packet is classified. All rules need to match for a packet to match a classifier. Packets that do not match any classifiers are assigned to the default (or primary) Service Flow.

CMCable Modem. Typically a device installed at the subscriber premises that provides a high-speed data (Internet) connection through the HFC network.


xii

About This Document

CMTSCable Modem Termination System. A device at a cable headend that connects to cable modems over an HFC network to an IP network.

CodecCoder-decoder. In ToIP products, one of several possible schemes of converting audio (i.e. a phone call) to digital data and vice versa. Attributes of a codec include fidelity (e.g. voice quality), bandwidth, and latency.

CPECustomer Premises Equipment. Subscriber-owned equipment connected to the network. Technically, a cable modem, MTA, or NIU falls into this category, although many operators do not designate them as such.

CVCCode Verification Certificate, an encryption key that allows secure downloading of encrypted software over the HFC net-work.

DHCPDynamic Host Configuration Protocol. An IP protocol used to provide an IP address and location of services (such as DNS and TFTP) needed by a device connecting to the network.

DNSDomain Name Service (Server). An IP service that associates a domain name (such as www.example.com) with an IP address.

DownstreamIn an HFC network, the direction from the headend to the sub-scriber. Some older cable documentation may refer to this as the forward path.

DOCSISData Over Cable Service Interface Specification. The interoper-ability standards used for data communications equipment on an HFC network.

EMTAEmbedded MTA. A device, such as the ARRIS Touchstone Telephony Modem, that contains both an MTA and a cable modem.


About This Document

xiii

Euro-DOCSISThe European version of DOCSIS. Euro-DOCSIS specifies an 8MHz downstream bandwidth (vs. 6MHz for DOCSIS); other minor differences exist as well.

FQDNFully Qualified Domain Name. The name used to identify a sin-gle device on the Internet. See RFC2821 for details.

HeadendThe “central office” in an HFC network. The headend houses both video and data equipment. In larger MSO networks, a “master” headend often feeds several “remote” headends to pro-vide distributed services.

HFCHybrid Fiber-Coaxial. A broadband, bi-directional shared media transmission system using fiber trunks between the head-end and fiber nodes, and coaxial distribution cable between the fiber nodes and subscriber premises.

HomePNAHome Phoneline Networking Alliance. A LAN interface that supports local networking over home phone lines. The Touch-stone Telephony Port provides HomePNA support.

JitterVariance in packet arrival time. Jitter is a factor in applications such as telephony, where the originating device sends packets at a constant rate.

LatencyThe time required for a signal element (e.g. packet) to pass through a device or network.

LCOLocal Connection Options. A structure that describes the char-acteristics of the media data connection from the point of view of the CMS creating the connection.

MACAcronym for Media Access Control. A general term for the link-level networking layer and associated protocols. MAC pro-tocols used in HFC data networks include Ethernet, the DOC-SIS RF interface, and HomePNA.


xiv

About This Document

Maintenance windowThe usual period of time for performing maintenance and repair operations. Since these activities often affect service to one or more subscribers, the maintenance window is usually an over-night period (often 1 a.m. to 5 a.m. local time).

MD5Message Digest 5. A one-way hashing algorithm that maps vari-able length plaintext into fixed-length (16-byte) ciphertext. MD5 files, built by a provisioning server, contain provisioning data for each NIU on the network.

MIBManagement Information Base. The data representing the state of a managed object in an SNMP-based network management system. Often used colloquially to refer to a single object or variable in the base; e.g. “the lcCmtsUpMaxCbrFlows MIB.”

MSOMulti-System Operator. A cable company that operates multiple headend locations, usually in several cities.

MPIMicro-Processor Interface. An internal Touchstone Telephony Modem component.

MTAMedia Terminal Adapter. A subscriber premises device that con-tains the network interface, codecs, and all signalling and encapsulation functions required for telephony transport, CLASS features signalling, and QoS signalling. The MTA is an integral part of Touchstone Telephony embedded MTA (EMTA) products.

NCSNetwork Call Signaling. The PacketCable protocol used to con-trol calls.

NIUNetwork Interface Unit. A generic term for a device providing data and telephony connections at a subscriber site. Also referred to as embedded MTA (EMTA).

NMSNetwork Management System. Software, usually SNMP-based, that allows you to monitor and control devices on the network. In a ToIP network, managed devices include NIUs, CMTS, servers, PSTN interface devices, and routers. An NMS works by


About This Document

xv

reading and setting values of MIB variables presented by each device.

Off-netA call between a ToIP phone line and a line on the PSTN.

On-netA call between two ToIP phone lines. Depending on the CMS used, the connection may be established directly between the MTAs or be routed through a gateway.

PacketCableA CableLabs-led initiative aimed at developing interoperable interface specifications for delivering advanced, real-time mul-timedia services over two-way cable plant.

PSTNPublic Switched Telephone Network.

PCMPulse Code Modulation. A commonly employed algorithm to digitize an analog signal (e.g. voice) into a digital bit stream using simple analog to digital conversion techniques. PCM is employed in the popular G.711 codec.

QAMQuadrature Amplitude Modulation. A method of modulating digital signals onto an RF carrier, involving both amplitude and phase coding. QAM16 modulation encodes four digital bits per state and is used on upstream carriers; QAM64 and QAM256 encode six or eight bits (respectively) for use on downstream carriers.

QoSQuality of Service. An attribute of a Service Flow, defining lim-itations or guarantees for data rate, latency, and jitter.

QPSKQuadrature Phase Shift Keying. A method of modulating digital signals onto an RF carrier, using four phase states to encode two digital bits.

RFRadio Frequency.


xvi

About This Document

SDPSession Description Protocol. SDP describes multimedia ses-sions for the purposes of session announcement, session invita-tion, and other forms of multimedia session initiation.

SLACSubscriber Line Audio Circuit. An internal Touchstone Tele-phony Modem component.

SNMPSimple Network Management Protocol.

TFTPTrivial File Transfer Protocol. Used in DOCSIS networks to transfer software and provisioning files to network devices.

ToIPTelephony over IP. The ARRIS implementation of PacketCable-compliant telephony services over an HFC network.

Unsolicited Grant Service (UGS)A Service Flow type used for applications such as telephony in which latency and jitter are critical. Packets have a fixed size and interval. Within the constraints of IP networking, UGS flows attempt to deliver a constant bit rate (CBR) stream of data.

UpstreamThe path from a subscriber device to the headend. Some older cable documentation may refer to this as the return path or reverse path.

VFVoice Frequency.


1 1 OverviewThis chapter describes Touchstone Telephony hardware and software features.

Touchstone Telephony NIUs (also referred to as Embedded MTAs or EMTAs), provide the subscriber connection to the HFC IP network.

The Touchstone NIUs are DOCSIS 1.1 and PacketCable 1.0 compliant when used with TS3.2 software.

Touchstone Telephony PortThe ARRIS Touchstone Telephony Port, model 204A, is an outdoor network-powered NIU that provides:

• up to four lines of telephony service

• cable modem functionality with either 10BaseT Ethernet or HomePNA connections

• CATV passthrough and internal disconnect


1-2 Overview

The Touchstone Telephony Port is the NIU of choice for operators who want to provide primary line service in small business and home envi-ronments.

Touchstone Telephony Modems

Model 102 The ARRIS Touchstone Telephony Modems, models 102A and 102D, are indoor NIUs that provide:

• up to two lines of telephony service

• cable modem functionality with 10/100BaseT Ethernet and USB 1.1 connections

The model 102D, shown on the right below, provides an integrated backup battery. The model 102A uses an external AC power supply.


Overview 1-3

The Touchstone Telephony Modems are ideal for primary or secondary lines in home environments.


1-4 Overview

Model 202 The ARRIS Model 202 Touchstone Telephony Modems are second generation NIUs. They are functionally similar to the 102 models, in a compact form factor.

The model 202 Telephony modems are available in AC-only and bat-tery-backup models (that provide up to 8 hours of backup power).

TS3.2 Software FunctionalityThe TS3.2 software provides the following functionality:

• Supports all current Touchstone Telephony hardware.

• Compatibility with DOCSIS 1.1 and PacketCable 1.0 standards, and partially compliant with PacketCable 1.1 standards. Sup-ported Touchstone NIUs are software-upgradable to PacketCa-ble 1.1 standards.

• Interoperability with all ARRIS ToIP solutions.

• Interoperability with ARRIS and other CMTS products.

TM202 (AC-only) TM202 (with battery backup)


Overview 1-5

• Dynamic Quality of Service (DQoS) support for Unsolicited Grant Service (UGS) service flows for telephony connections.

— All TS3.2 releases support access-side (DSx) DQoS.

— TS3.2.2 and later releases support full PacketCable (end-to-end) DQoS.

• Supports the following line card templates:

— North American Standard (-5/-7 dB) loss plan

— North American High (-3/-3 dB) loss plan

— North American 0/-9 dB loss plan

— Japan, Chile, Spain, Germany, and Netherlands templates

• Improved NCS performance and compliance over previous Touchstone software loads. TS3.2 is fully NCS compliant.

• TS3.2 supports SNMPv3, IPSEC, and encrypted voice traffic as required by PacketCable specifications.

• Supports USB and Ethernet interfaces to CPE.

• Supports RFC 2833 functionality. RFC 2833 defines a method for carrying DTMF and other telephony signals and events in RTP packets, instead of sending audio tones over the network.

• Battery telemetry support (allows monitoring of battery status at the headend).

• Supports single- or dual-MAC address provisioning (allows interoperability with certain non-PacketCable compliant provi-sioning software).

• Support for dialup fax and modem connections, disabling echo cancellation upon detecting fax or modem start tones.

• Supports access to 911 (emergency), 411 (directory), 311 (non-emergency), and 611 (repair) services.

• Supports USB and Ethernet interfaces to CPE.


1-6 Overview

Enhancements from TS01

TS3.2 software includes the following enhancements over the previous TS01 software:

• End-to-end DQoS (TS3.2.2 and later releases), providing an added layer of authentication, as well as DSx DQoS support (see “Provisioning Notes” on page 3-4 for details).

• Supports a variety of non-PacketCable compliant provisioning software and cable data equipment, allowing Touchstone Tele-phony NIUs to interoperate with a wide range of equipment.

• PacketCable 1.1-compatible alarm and log interface.

• Support for the PacketCable Service Provider root certificate, the PacketCable Service Provider Test root certificate, and the ability to download other Service Provider root certificates (see Appendix B).

• Supports Model 202 Touchstone Telephony Modems.

• Supports HomePNA networking (Touchstone Telephony Port only).

• Supports end of call statistics (see “End of Call Connection Sta-tistics” on page 8-27).

• Expanded CallP Feature Switch settings see “CallP Feature Switch” on page 3-5).

• Supports a 0/-9 dB loss plan (North America only)

• Support for Japan, Chile, Spain, Germany, and Netherlands line card templates


Overview 1-7

Contents of the Software Disk

The TS3.2 software is shipped on a CD that contains the following files:

• MIB files (see Chapter 7, “MIB Reference,” for a complete list)

• Touchstone software and data files

• PacketACE™ (see “Companion Utilities” below)

• Documentation in PDF format

Companion UtilitiesThe ARRIS PacketACE tools are designed for use with TS3.2 and later versions of Touchstone software. PacketACE is a configuration editor that simplifies building configuration files from common fragments.

See the PacketACE Configuration Tools User’s Guide, ARSVD00635, for more information about PacketACE.


1-8 Overview


2 2 Installing the SoftwareThis chapter provides procedures used to install and upgrade Touch-stone software on local DHCP and TFTP servers.


2-2 Installing the Software

Installing the SoftwareUse this procedure to install TS3.2 software on primary and backup DHCP and TFTP servers.

Requirements You need the following to install TS3.2 software:

• Touchstone software CD

• Access to the TFTP file servers

• Location of the software directory on the file servers

• Access to the provisioning server (to change NIU provisioning files)

Action Perform the following tasks as needed.

Task Page

Installing the Software on a File Server ....................... 2-2

Configuring the NIU to Download its Software............. 2-3

Upgrading the Software through Provisioning.............. 2-3

Upgrading the Software through SNMP....................... 2-4

Installing the Software on a File Server

Follow these steps to install the TS3.2 software on a file server.

1 Log into the file server, using an account with administrative privi-leges.

If the server is local and has a CD-ROM drive, you can log directly into the file server. Otherwise, you should use an FTP client (make sure to use the binary transfer mode) or a network file sharing ser-vice to access the file server.

2 Insert the TS3.2 software CD into the appropriate CD-ROM drive (see the comment in step 1).

3 Change to the appropriate server directory for software storage.


Installing the Software 2-3

4 Copy or upload the TS3.2 software file from the CD to the server.

5 Make sure that the software file has read access for all NIUs.

Configuring the NIU to Download its Software

Follow these steps to configure the Touchstone Telephony NIU provi-sioning data to download its software during registration. Use your pro-visioning server to perform this task.

1 Set the docsDevSwServer MIB to the address of the file server containing the TS3.2 software.

2 Set the docsDevSwFilename MIB to the name of the TS3.2 soft-ware file.

Upgrading the Software through Provisioning

Follow these steps to upgrade the Touchstone software load using a provisioning server.

1 Install the new software, using the steps in “Installing the Software on a File Server” on page 2-2.

2 Use the provisioning server to add or verify the following items in the cable modem configuration file:

• UpgradeFileName (file name of the software load)

• UpgradeServer (IP address of the server containing the load)

• SnmpMib = docsDevSwAdminStatus.0 2 (allow ProvisioningUpgrade)

3 During the maintenance window, use your provisioning server or element manager to reset each Touchstone NIU.

The NIUs download the new software, then reset.

4 Verify that the NIU has the new load by checking the value of the docsDevSwOperStatus MIB (using an SNMP server).

The value of the MIB should read completeFromProvisioning(3).


2-4 Installing the Software

Upgrading the Software through SNMP

Follow these steps to upgrade the Touchstone software load using an SNMP manager.

1 Using the SNMP manager, set the following docsDevSoftware MIBs:

• docsDevSwServer—IP address of the server containing the load)

• docsDevSwFilename—file name of the software load

• docsDevSwAdminStatus—set to 1 (upgradeFromMgt)

The NIU downloads the new software, then resets.

2 Verify that the NIU has the new load by checking the value of the docsDevSwOperStatus MIB.

The value of the MIB should read completeFromMgt(3).


3 3 ProvisioningYou can provision Touchstone Telephony products using a variety of PacketCable-compliant and non-compliant tools.

OverviewTypically, you provision a ToIP network using a PacketCable-compli-ant provisioning server. The server provides both provisioning tools to create data files, and servers (DHCP, DNS, TFTP) to store and transfer software loads and provisioning data to both the CMTS and all attached cable modems and MTAs.

In some cases, the provisioning server may not be PacketCable-compli-ant but supports one or two MAC addresses per NIU.

Provisioning Modes

To improve compatibility with non-compliant equipment, ARRIS sup-ports six provisioning modes for Touchstone NIUs and software; each has multiple options to enable and disable PacketCable features.

Full PacketCable compliant (default)The data and telephony components have unique IP addresses, MAC addresses, and configuration files (i.e. two of each per NIU). When the NIU registers, it makes two separate DHCP and TFTP requests.

SNMP communication uses SNMPv3, sending an SNMPv3 INFORM.

IPSec is supported, and may be enabled or disabled using the pktcMtaDevCmsIpsecCtrl MIB variable. Media encryption (voice security) can be enabled on a per-call basis using NCS signalling (the LCO/SDP options) or disabled per MTA using a feature switch. The feature switch is stored in NVRAM and overrides the pktcMtaDevCmsIpsecCtrl MIB variable.


3-2 Provisioning

PacketCable without KDCA PacketCable subset, using SNMPv1 or SNMPv2 (sending an SNMPv2 INFORM).

IPSec is disabled. Media encryption can be controlled on a per-MTA basis using a feature switch.

CPS2000A PacketCable subset, using SNMPv1 or SNMPv2 (sending an SNMPv2 INFORM).

IPSec and media encryption are disabled.

Global Universal Provisioning Interface (GUPI)A PacketCable subset, intended to accommodate a wide range of partially-compliant equipment. SNMP communication uses SNMPv1 or SNMPv2, with INFORM disabled.


Single MAC/Single Configuration FileDesigned for use with certain provisioning servers that support only one IP address, MAC address, and configuration file per NIU. The NIU makes one DHCP and TFTP request. SNMP communication uses SNMPv1 or SNMPv2, with INFORM dis-abled.

The configuration file a superset of DOCSIS 1.1, including MTA provisioning parameters.


DOCSIS OnlyA data-only mode (no telephony support). Uses a single IP address for the cable modem component, making a DHCP and TFTP request during registration.

Use the ArrisCmDevProvMethodIndicator MIB object in the CM configuration file to select a particular provisioning mode.


Provisioning 3-3

DHCP ParametersThe following table lists DHCP parameters used by each provisioning method.

Provisioning Method DHCP Parameters

Full PacketCable

PacketCable minus KDC

CPS 2000

CM DHCP Option 177:

• SubOption 1: Service Provider’s Pri-mary DHCP (required)

• SubOption 2: Service Provider’s Sec-ondary DHCP (optional)

MTA DHCP Option 177:

• SubOption 3: Service Provider’s SNMP Entity (required)

• SubOption 4: Service Provider Network Primary DNS

• SubOption 5: Service Provider Network Secondary DNS

• SubOption 6: Kerberos Realm (FQDN)

• SubOption 7: Authorization method (TGT for MTA)

• SubOption 8: Provisioning Timer (min-utes)

GUPI Separate CM and MTA offers.

CM DHCP Option 177:

• SubOption 1: Service Provider’s Pri-mary DHCP (required)

• SubOption 2: Service Provider’s Sec-ondary DHCP (optional)

MTA DHCP Option 177: ignored

MTA offer: MTA FQDN is configured in the DHCP offer (Options 12 and 15). If not present, the FQDN uses the bracketed CM IP address.

DNS is optional.

Single MAC/Config File One offer requested and made.

MTA FQDN is configured in the DHCP offer (Options 12 and 15). If not present, the FQDN uses the bracketed CM IP address.

DNS is optional. The address is supplied in the standard DHCP option (Option 6).


3-4 Provisioning

Provisioning NotesYou can provision cable modem and MTA IP addresses either on sepa-rate subnets (as required in version TS01) or on a single subnet.

Full DQoS Mode TS3.2.2 and later software supports Dynamic Quality of Service (DQoS) provisioning. Full DQoS simplifies provisioning tasks by requiring only that the primary Best Effort (BE) and MGCP (signal-ling) flows be provisioned. The TS3.2.2 software dynamically sets up and tears down UGS service flows, using a standard set of parameters designed for efficient use in ToIP networks, as needed. The CMS con-trols the bandwidth authorization as specified in the PacketCable DQoS specifications.

Full DQoS provides an added layer of security by authenticating NIUs that contact it during call setup. Each session is authorized; the session authorization uses a handle (the Gate ID) assigned by the CMTS, passed to the CMS, and sent to the MTA using an NCS message, to match requests with authorizations. Upon receiving call-signalling information, the MTA passes the Gate-ID to the CMTS in a DSA/DSC message.

DSX QoS Mode TS3.2 software supports an ARRIS-proprietary feature that implements QoS using UGS flows for voice transmission using DOCSIS 1.1 DSx messaging. This functionality provides a level of QoS in a network where the CMS and CMTS do not support the PacketCable Full DQoS model.

DSx QoS functionality can be activated using a feature switch. When activated, the TS3.2 software sends the appropriate DSx messages needed to Add/Modify/Delete the UGS service flows. DSx messages flow only between the CMTS and the NIU, and do not involve the CMS in any validation or requests for setting up or monitoring the UGS flows.

Note: When using this functionality with the ARRIS C4 CMTS, PacketCable authorization needs to be disabled. Contact your next level of support for instructions.

DOCSIS Only One offer requested and made.

The DHCP options should not contain MTA option 177 suboptions 1 and 2 (MTA primary and secondary DHCP server addresses).

Provisioning Method DHCP Parameters


Provisioning 3-5

Voice and Signalling Ports

The TS3.2 software uses the RTP ports 1086 through1093 for RTCP-based voice communications. The port numbers cannot be modified or used for other purposes.

By default, the MTA receives signalling information on port 2427; you can change the default port number in the MTA configuration file.

By default, the MTA transmits signalling information on port 2727; you can change the default port number in the MTA configuration file, or override it by sending an NCS message from the call server once the MTA is operating. See “Signaling MIB” on page 8-21 for details.

About IPSec IPSec (Internet Protocol Security) is a collection of Internet standards used to encrypt and authenticate IP packets, to provide message integ-rity and privacy. IPsec provides security at the network layer (all TCP and UDP packets, and layers above).

IPSec is controlled by setting the pktcMtaDevCmsIpsecCtrl MIB variable for each CMS that the MTA can communicate with; you can include this variable in the MTA configuration file. Set the variable to true(1) to enable IPSec between the MTA and a particular CMS, and false(2) to disable it.

Note: Touchstone NIUs use only the IPSec ESP transport mode.

CallP Feature Switch

The TS3.2 software provides an ARRIS-specific MIB used to configure the Telephony Modem for the specific sub-set of PacketCable features supported by the selected network configuration. This allows the flexi-bility to interoperate with other vendors by providing the ability to enable/disable the following functionality:

• NCS message piggybacking. Allow the endpoint to transmit piggybacked NCS messages. This feature is needed to meet NCS in-order delivery requirements. A piggybacked NCS mes-sage looks like this:

RSIP 1001 aaln/*@mta204.dev33 MGCP 1.0 NCS 1.0

RM: restart

.

NTFY 1002 aaln/[email protected] MGCP 1.0 NCS 1.0

X: 0

O: hd

• Lockstep mode for the endpoint. Allow the endpoint to enter the “LOCKSTEP” quarantine mode. This mode forces the endpoint to wait for an acknowledgement to a notification (such as on-hook) before processing other messages. Other messages are


3-6 Provisioning

quarantined (queued) for processing after receiving the acknowledgement.

• Transmission of wildcarded NCS messages. This functionality allows the endpoint to send one message to the call server that applies to all lines. TS3.2 software currently supports only the wildcarded Restart In Progress (RSIP) message. This indicates that all lines on the MTA have been reset. This message is only sent when all the lines of the device are provisioned to be In-Service and against the same Call Server.

• RFC2833 messaging support. RFC2833 support allows the Telephony Modem to use RFC2833 specific messaging with certain gateways. Contact your ARRIS tech support representa-tive to confirm support of your gateway.

• DSx-QoS or full PacketCable DQoS.

• Provisional responses: Allow the endpoint to send provisional responses. The Telephony Modem sends a provisional response to the CMS only if it receives either a create connection (CRCX) or modify connection (MDCX) that contains a DQoS Gate ID. The CMS, in this case, must ACK the “final” response later sent by the Telephony Modem.

• Multiple connections per line for supporting 3WC and CWT functionality.

• Media encryption (AES) support.

• Support of NCS error codes 403 & 540 for interoperation with Call Management Servers.

Complete definitions of the above functionality can be found in the PacketCable Network-Based Call Signaling Protocol Specification, PKT-SP-EC-MGCP-I08-030728.

As an example, if your configuration contains a Nortel SN06 Call Man-agement server, an ARRIS C4 CMTS, and is operating in a DSx-QoS mode, the following shows an example setting of this switch (this is taken from the text output of the configuration file using PacketACE):

SnmpMib = ppCfgMtaCallpFeatureSwitch.0 hexstr: 10.66.79

To ensure that the MTA is configured properly, contact your ARRIS Technical Support representative for the proper setting for your config-uration.


Provisioning 3-7

Touchstone HomePNA SupportThe Touchstone Telephony Port, model 204A, provides a Home PNA 2.0 data interface on Telephony Interface Line 1. This interface is compliant with the MAC and PHY functionality, defined in Interface Specification for HomePNA 2.0 10M8 Technology, by the Home Phone-line Networking Alliance (http://www.homepna.org/).

Compatibility Exceptions

The Touchstone Telephony Port operates only in HPNA 2.0 mode (10M8) and is not designed to interoperate with HPNA 1.0 (1M8) equipment or HPNA 2.0 equipment configured for 1M8 mode.

HomePNA Provisioning Notes

The HomePNA interface is enabled by default and requires no provi-sioning or other software configuration for activation. To use the inter-face, attach any standard HomePNA adapter supporting HPNA 2.0 mode (10M8) to Telephony Line 1. Link status indicators on the Home-PNA connector should show data transmission. If the device is not communicating, see “HomePNA Troubleshooting” on page 8-40.

Managing the HomePNA Interface

You manage the HomePNA interface through its entry in the Interface MIB table. An example of the Interface table is shown in the following figure.

In this figure, the IfAdminStatus entry for the HPNA CPE interface is up(1), meaning a HomePNA device is connected and the link status LED on the device indicates activity.

To disable the HomePNA interface, set the IfAdminStatus for the interface to down(2). There are two methods of disabling the Home-PNA interface:

• To disable the interface permanently, set the IfAdminStatus value in the DOCSIS(CM) configuration file and reset the Touchstone Telephony Port. By setting the value in the configu-


3-8 Provisioning

ration file, the interface remains disabled after recovering from loss of communications, or during a manual reset or power cycle of the Telephony Port.

Note: When disabled through the configuration file, the Home-PNA interface is temporarily enabled until the Telephony Port downloads and processes the DOCSIS configuration file.

• To temporarily disable the interface, set the IfAdminStatus using any SNMP manager. The interface is re-enabled when the Telephony Port is reset or recovers from loss of communication.

Provisioning Event SequencesThe following diagrams show the normal sequence of events required when a PacketCable compliant NIU registers on the cable data network. The dark shaded areas are the events omitted when using each provi-sioning scheme.

PacketCable Sequence

The following diagram shows the full PacketCable event sequence. All events are included.


Provisioning 3-9

PacketCable (no KDC) and CPS Sequence

The following diagram shows the PacketCable (no KDC) and CPS event sequences. The two are identical, skipping several events in the MTA provisioning.

GUPI Sequence The following diagram shows the GUPI event sequence. GUPI skips several steps in the MTA provisoning.

Flow CM / MTA CMTS DOCSIS DHCP

DOCSIS TFTP

DOCSIS ToD Prov Server PKT DHCP PKT DNS PKT TFTP

MSO KDC SYSLOG

Start with DOCSIS 1.1 Initialization/Registration

CM-1 DHCP Broadcast Discover (Option Code 177)

CM-2 DHCP Offer (Option Code 177 w/ telephony service provider's DHCP server address = [255.255.255.255])

CM-3 DHCP Request

CM-4 DHCP Ack

CM-5 DOCSIS 1.1 CM config file request

CM-6 DOCSIS 1.1 config file

CM-7 ToD Request

CM-8 ToD Response

CM-9 CM registration with CMTS

CM-10 CMTS Registration ACK

Complete DOCSIS 1.1 Initialization/Registration

MTA-1 DHCP Broadcast Discover (option code 60 w/ MTA device identifier)

MTA2 DHCP Offer (Telephony TFTP config filename, NO OPCODE 177 options)

MTA-3 DHCP Request

MTA-4 DHCP Ack

MTA-5 DNS Request

MTA-6 DNS Srv (KDC host name associated with the provisioning REALM)

MTA-7 DNS Request

MTA-8 DNS Response (KDC IP Address)

MTA-9 AS Request

MTA-10 AS Reply

MTA-11 TGS Request

MTA-12 TGS ReplyMTA-13 AP Request (Key Mgmt Prot Vers. , Protocol ID, KRB_AP_REQ,, Ciphersuites, SHA-1 HMAC )

MTA-14 AP Reply ( KeyMgmtProtVers, Protocol ID, KRB_AP_REP, ciphersuite selected, key lifetime, Ack req , HMAC)

MTA-15 SNMP Inform

MTA-16 SNMP Get Request(s) for MTA device capabilities (optional/iterative)

MTA-17 SNMP Get Response(s) containing MTA device capabilities (optional/iterative)

MTA-18 MTA config file

MTA-19 SNMP Set with URL encoded file download access method (TFTP or HTTP), filename, hash, and encryption key( if required)

MTA-20 Resolve TFTP server FQDN

MTA-21 TFTP server IP address

MTA-22 Telephony config file request

MTA-23 Telephony config file

MTA-25 Notify completion of telephony provisioning (MTA MAC address, ESN, pass/fail)


3-10 Provisioning

Single MAC/Config File Sequence

The following diagram shows the event sequence for single MAC/con-fig file provisioning.

Setting Up the Provisioning Server Data

Set up the provisioning data as follows to use a non-PacketCable com-pliant provisioning server:

• The MTA DHCP offer may not use DNS, SNMP, or security (Kerberos or Ticket Granting).

• The FQDN must be in IPv4 format (i.e. an IP address such as 10.1.2.3 rather than a domain name such as tt4.example.net).

Note: DNS is not supported for FQDN when using GUPI or single-MAC/config file provisioning.


Provisioning 3-11

Configuring Alarm and Log ReportingUse this procedure to configure how the Touchstone NIUs generate and send events (alarms and logs). Chapters 4 and 5 provide detailed descriptions of alarms and logs, respectively.

Touchstone MTA events function within the context of the PKTC-EVENT-MIB. Touchstone CM events function within the context of the DOCS-CABLE-DEVICE-MIB.

Overview TS3.2 software provides the capability to provision logs and alarms uti-lizing two different methods.

• A compatibility mode, that allows the TS3.2 software to use provisioning from previous software releases (see “TS0101/TS0301 Compatible Provisioning Method” on page 3-14).

• A new mode provides the flexibility to provision separate Sys-log server and trap receiver addresses for alarms and logs. In addition, you can provision multiple trap receivers allowing multiple monitoring stations if desired. Finally, you can provi-sion different reporting schemes for each event if desired.

You can use both provisioning methods as desired. However, if you use the same servers for both methods, the Telephony Modem sends dupli-cate reports to that server.

Event Routing When the NIU generates an event, each event can be sent to any combi-nation of:

• local event log

CM events are stored locally in the docsDevEventTable. The Data-Over-Cable Service Interface Specifications, SP-OSSIv1.1-I07-030730, describes the reporting of DOCSIS and vendor-specific events.

MTA events are stored locally in the pktcDevEventTable. The PacketCable Management Event Mechanism Specification, PKT-SP-MEM-I01-001128, describes the reporting of Packet-Cable and vendor-specific MTA events.

The default configuration sends CM and MTA events only to the local event log.

• SNMP trap server

To report CM events, you can configure the CM in either NmAccess mode or SNMP co-existence mode. To report MTA


3-12 Provisioning

events, you must configure the CM in SNMP co-existence mode.

SNMP co-existence mode supports multiple trap destinations. See “Configuring the CM for Coexistence Mode” on page 11-8 for detailed information.

• Syslog server (MTA logs)

The NIU sends MTA logs to the Syslog server whose IP address is specified in the pktcDevEvSyslogAddress MIB. The NIU must receive its MTA Telephony Syslog Server IP Address in the MTA DHCP OFFER, option 7. The value of the option MUST be one of the following:

— 0.0.0.0—Disable Syslog logging for the MTA.

— FF.FF.FF.FF—Use the CM log server as the Syslog server.

— Valid IP address of the Telephony syslog server.

The pktcDevEvSyslogAddress MIB value can also be config-ured from the MTA configuration file.

• Syslog server (CM logs)

The NIU sends CM logs to the Syslog IP address specified in docsDevEvSyslog. The CM receives its Syslog IP Address in the CM DHCP options. To disable Syslog transmission for the CM, set the IP address to 0.0.0.0.

About the Event Tables

The PKTC-EVENT-MIB provides two tables to describe events and control their reporting: the pktcDevEvProgrammableTable and the pktcDevEvFixedTable. The primary difference between the two tables is that entries in the programmable table allow for changes to the mes-sage text. Currently, the programmable table contains alarms, and the fixed table contains logs, although this is not a requirement.

The following tables provide an overview of the alarms and logs.

pktcDevEvProgrammableTable

Event ID Origin Severity Text

65529 ARRIS Minor(3) Power Supply Telemetry

65530 ARRIS Major(2) Call Agent Loss of Communications

65533 ARRIS Major(2) Voice Line Failure

65534 ARRIS Major(2) Voice Line Total Failure


Provisioning 3-13

In addition, the pktcDevEvProgrammableTable defines several Pack-etCable alarms for battery telemetry. The ARRIS Power Supply Telem-etry Alarm (and Log) supports these status events.

The pktcDevEvSyslogAddress MIB specifies the address of the Sys-log server to receive event notifications.

pktcDevEvFixedTable

Instance Origin Text

1 ARRIS Voice Line Diag Failed

2 ARRIS Voice Line Diag Passed

3 ARRIS Voice Line State Change

6 ARRIS Voice Line Protection State Change

7 ARRIS Voice Line Loop Current Change to High

8 ARRIS Voice Line Loop Current Change to Normal

10 ARRIS State Change

11 ARRIS CATV changed

14 ARRIS Power Supply Telemetry

15 ARRIS MTA TFTP: No Channel

16 ARRIS MTA TFTP: Successful

17 ARRIS MTA TFTP: File Not Found

18 ARRIS MTA TFTP: Protocol Error: TFTP Init

19 ARRIS MTA TFTP: Protocol Error: TFTP Open

20 ARRIS MTA TFTP: Protocol Error: TFTP Read

21 ARRIS MTA TFTP: Protocol Error: TFTP Close

22 ARRIS MTA TFTP: Protocol Error: TFTP DB Access

23 ARRIS MTA TFTP: Config File Error

24 ARRIS MTA TFTP: Failed

25 ARRIS MTA PROV: Failed

26 ARRIS MTA PROV: Successful!

27 ARRIS MTA Security: Service Provider Certificate Chain Validation Failed

2417164291 ARRIS MTA Root Certificate download Failed

2417164292 ARRIS MTA Root Certificate download Retry

2417164290 ARRIS MTA Root Certificate download Complete


3-14 Provisioning

TS0101/TS0301 Compatible Provisioning Method

For backwards compatibility with previous releases, TS3.2 provides a proprietary method of configuring the trap/Syslog destination IP address. By setting the ppCfgMtaTeleSyslogServIpAddr MIB vari-able in the MTA configuration file, the MTA reports ARRIS proprietary alarms as traps/Syslog events to the specified IP address. If this IP address is set, each ARRIS alarm event reports to the local event data-base, an SNMP trap and a Syslog message.

Each log report can also be modified by setting the new value to the pktcDevEvFixedReporting MIB.

Action Follow these steps to configure alarm and log reporting. You can con-figure individual NIUs through an SNMP manager, or all NIUs by using a provisioning server to add the MIBs to the configuration file.

1 Set the pktcDevEvSyslogAddress MIB to the IP address of a Sys-log server.

2 For each event in the pktcDevEvProgrammableTable, set the pktcDevEvProgrammableReporting MIB to one of the following values:

For example, to configure “AC Fail” events to go to a Syslog server (and the local log), set the following MIB:

pktcDevEvProgrammableReporting.65535.4491 = 0xA0

Note: If you want to report events to Syslog or trap servers, you must report those events to the local event log as well.

3 For each event in the pktcDevEvFixedTable, set the pktcDevEv-FixedReporting MIB to one of the values shown in step 2.

Value Events Reported to

0x00 none

0x80 Local event log only

0xA0 Local event log and Syslog server

0xC0 Local event log and Trap server

0xE0 Local event log, Syslog server, and Trap server


Provisioning 3-15

Updating the KDCUse this procedure if you require secure MTA provisioning and secure NCS.

TS3.2 software commonly uses one of the following embedded certifi-cates:

• CableLabs Real Service Provider Root certificate (default). The Real Root certificate is only issued to authorized MSOs and Service Providers.

• CableLabs Test Service Provider Root certificate. The Test Root certificate is an alternative to the Real Root certificate for the purpose of lab testing.

If you prefer to use the test certificate, you must configure the KDC with the Test Root certificate.

• IPfonix Test Service Provider Root certificate (used primarily with earlier versions of Touchstone NIU software).

If you continue to use the IPfonix certificate, you must reconfig-ure the CM provisioning files.

For more information, see “Appendix B: Configuring the Service Pro-vider Root.”

Action Perform either of the following tasks as needed.

Task Page

Configuring the KDC to use the CableLabs Test root... 3-16

Using the Test Root Download feature......................... 3-17


3-16 Provisioning

Configuring the KDC to use the CableLabs Test root

Follow these steps:

1 Generate a KDC certificate chained to your KDC certificate hierar-chy (Real/Test Root CA, Service Provider CA, Local System Oper-ator CA).

• the realm name that you are using

• the KDC's FQDN

2 Proceed as follows, depending on your KDC:

If you are using a different KDC server, or need more help, contact your next level of support.

3 Place the certificates on your KDC. The directory path to place the certificates is:

• IPfonix - KDCDir/windows/PacketCable/certificates/

• Alopa - /opt/Alopa/MetaServ/KDC/config/certs/

4 Install the configuration file:

• IPfonix - Place the KDC_private_key file in KDCDir/windows/

• Alopa - Place the kdcConfig.org file in /opt/Alopa/MetaServ/KDC/config/

5 Change the realm org name in the MTA configuration file from "Really Amazing Telephone Company" to CableLabs.

6 Restart your KDC.

If you are using… Then…

Alopa KDC Modify the kdcConfig.org file as follows:

• modify the KDC realm name to contain the realm name that you are using; for example, <kdcRealm name=”DEV49”>

• Modify the principal name to contain the KDC’s FQDN; for example, <kdcPrincipalDataBase name=”mmtaprovsrvr/hyde.dev49”>

IPfonix KDC Generate the KDC private key and include it in the KDC_private_key file.


Provisioning 3-17

Using the Test Root Download feature

This option allows you to continue using the KDC with the IPfonix test root configuration (supported in older versions of Touchstone NIU soft-ware). The NIU’s CM configuration file must contain three MIBs, which instruct the NIU to download a test root. The test root is stored only in the NIU’s RAM memory and therefore the download is required after each reboot. Follow these steps to use this option.

1 Place your IPfonix Test Root certificate on your TFTP server. This server is normally the same server as the configuration file TFTP server.

Note: The certificate must use the X.509 DER-encoded format.

2 Edit your CM configuration file to contain the following MIBs with the following values:

• PpCfgMtaDevSPTestRootCertAdminStatus: Set to down-loadTestRootCert.

• PpCfgMtaDevSPTestRootCertFilename: Set to the file name containing the IPfonix Test Root.

• PpCfgMtaDevSPTestRootCertServer: Set to the IP address of the TFTP server.

3 Reboot the MTA.


3-18 Provisioning


4 4 Interpreting AlarmsThis chapter describes alarms supported by the TS3.2 software.

Touchstone Telephony NIUs generate alarms in response to detected events. Alarm reports may be collected at:

• The pktcDevEventTable (part of the PKTC-EVENT-MIB) in the NIU keeps local copies of alarms until the NIU is rebooted or powered down. The default configuration stores alarms only in the local event table.

• A specified Syslog server (specify a Syslog server using the pktcDevEvSyslogAddress MIB).

• SNMP servers (the NIU sends the alarm in a pktcDev-EventNotify message). See “MTA Alarm Format” below for details.

Alarm reporting can also be disabled.

See “Configuring Alarm and Log Reporting” on page 3-11 for details about configuring alarm reports.


4-2 Interpreting Alarms

MTA Alarm FormatMTA alarms function within the context of the PKTC-EVENT-MIB.

You can modify the text of each alarm event by setting the pktcDe-vEvProgrammableText MIB. The severity of each alarm event cannot be modified.

An ARRIS MTA Alarm event consists of the following information:

• Event Index—Provides relative ordering of the objects in the event log. This also serves as a indicator of event sequence. The object value always increases except when:

— the log is reset using the pktcDevEvControl MIB.

— the device reboots and does not implement non-volatile storage for this log.

— the value reaches 231 (the index is a 32-bit counter that rolls over to zero at this limit).

The next entry for all the above cases is 1.

• Event Time—Provides a human-readable description of the time at which the event occurred.

• Event Level—The priority level of this event as defined by the vendor.

• Event Enterprise number—The IANA enterprise number: 4115 for ARRIS events.

• Event ID—ID for a specific event to which the priority and dis-play string are matched. These Event Ids are vendor specific.

• Event Text—The ID of the event. Corresponds to the pktcDe-vEvProgrammableId or pktcDevEvFixedId MIBs.

• Mac Address—Provides the MAC address of the device gener-ating the event.

• FQDN/Endpoint ID—The endpoint identifier followed by the FQDN/IP Address of the device. This is in the form AALN/X:FQDN/IP Address. If the event is not specific to an endpoint, then the identifier is just the FQDN/IP address.


Interpreting Alarms 4-3

Examples The following are examples of alarms as they appear in an SNMP browser and a Syslog server.

SNMP Example

Syslog Example



Alarm SummaryThe following table summarizes the MTA alarms.

AlarmsTouchstone Telephony NIUs may generate the following alarms.

Call Agent Loss of Communications

Severity: Major, service-affecting

Cause: One of the following conditions has occurred:

• The MTA did not receive a response from the Call Server for an NCS message.

Re-establishing communications with the Call Server clears this alarm.

• The Telephony Modem received a NACK in response to the RSIP message that it sent on initial registration to the call agent, resulting in CallP func-tionality entering a “permanent error” state.

Clearing the condition that caused the NACK clears this alarm.

Impact: The NIU cannot register or initiate calls.

Action: Check the status of the NIU and its network connection.

Power Supply Telemetry

Severity: Major, non-service affecting

Cause: The NIU has lost AC power. The alarm includes one of the following battery status codes:

• AC Fail—the NIU has detected an AC power failure.

• AC Fail Battery Low—the NIU is operating from battery power, and has drawn down the battery to about 25% of its rated capacity.

Alarm Text Event ID Priority Page

Call Agent Loss of Communications 65530 MAJOR 4-4

Power Supply Telemetry 65529 MINOR 4-4

Voice Line Failure 65533 MAJOR 4-5

Voice Line Total Failure 65534 MAJOR 4-6


Interpreting Alarms 4-5

• AC Fail Battery Replace—the NIU is operating from battery power, and the battery has deteriorated to about 75% of its off-the-shelf capacity and should be replaced.

• AC Fail Battery Low Replace—the NIU is operating from battery power, and has drawn down the battery to about 25% of its rated capacity. In addition, the battery has deteriorated to about 75% of its off-the-shelf capacity and should be replaced.

Impact: None at time of alarm. Depending on the condition of the battery and the nature of the power failure, the NIU may exhaust the battery before AC power is restored.

Action: Depends on the scope of the power outage.

Voice Line Failure Severity: Minor, service-affecting

Cause: One of the following conditions has occurred:

• An In-Service line card has detected a Line Card Protection Fault condition (an overcurrent protection state).

A Line Card Protection Fault occurs when the line card detects foreign voltage between tip and ring, or there is an excessive imbalance in loop current.

• An attempt was made to put an Out-of-Service line, in an overcurrent protection state, into service.

Impact: The affected voice line is disabled. Look for Voice Line Pro-tection State Change logs to determine which line is in the fault condition.

Action: Run the line card diagnostics on the NIU as described in “Running Line Card Diagnostics” on page 8-38. If the NIU fails diagnostics, disconnect the house wiring from the NIU and proceed as follows:

• If the alarm clears, correct the faulty house wiring.

• If the alarm persists, replace the NIU.



Voice Line Total Failure

Severity: Major, service-affecting

Cause: The NIU detected a DSP device failure or DSP download failure. Possible causes include a corrupted software down-load or an NIU hardware failure.

Impact: All telephony lines are disabled. Data communications are not necessarily affected.

Action: A rare occurrence of this event indicates that the DSP failed to download and should be monitored for future occur-rences. If this event reoccurs on the same NIU, or occurs immediately after a reset, replace the NIU.


5 5 Interpreting LogsThis chapter describes log reports supported by the TS3.2 software.

Touchstone Telephony NIUs generate logs in response to detected events. Log reports may be collected at:

• The docsDevEventTable (part of the DOCS-CABLE-DEVICE-MIB) in the NIU keeps CM logs until the NIU is rebooted or powered down.

• The pktcDevEventTable (part of the PKTC-EVENT-MIB) in the NIU keeps MTA logs until the NIU is rebooted or powered down.

The default configuration stores logs only in the local event tables.

• A specified Syslog server (specify a Syslog server using the pktcDevEvSyslogAddress MIB).

• SNMP servers (the NIU sends the log in a pktcDevEventNotify message). See “Log Format” below for details.

See “Configuring Alarm and Log Reporting” on page 3-11 for details on configuring log reports.


5-2 Interpreting Logs

Log HandlingTS3.2 supports several logging methods. The cable modem portion of the NIU handles all logging tasks.

SNMP Traps You can configure one or more SNMP trap destinations by configuring the NIU in NmAccess mode or SNMP co-existence access mode.

In SNMP v1/v2c NmAccess mode, the NIU supports event notification functions including:

• local event logging

• SYSLOG (targets/limiting/throttling)

• SNMP TRAP (trap-versions/targets/limiting/throttling) as spec-ified in RFC 2669 and the current specification

For detailed information on configuring the NIU in NmAccess mode, see “Configuring the Cable Modem for NmAccess Mode” on page 11-3.

In SNMP coexistence mode, the NIU supports event notification func-tions including:

• local event logging

• SYSLOG (targets/limiting/throttling)

• SNMP TRAP (limiting/throttling) as specified in RFC 2669 and the current specification

• SNMP notification functions as specified in RFC 2573

For detailed information on configuring the NIU in SNMP co-existence mode, see “Configuring the CM for Coexistence Mode” on page 11-8.

Syslog messages TS3.2 software reports logs as syslog messages to the cable modem Syslog server IP address. Set the IP address to 0.0.0.0 to disable Syslog transmission.


Interpreting Logs 5-3

Log FormatTS3.2 software provides log messages for both the cable modem and MTA sections of the Touchstone NIU.

Cable Modem Log Format

Cable modem logs require the DOCS-CABLE-DEVICE-MIB.

Log messages consist of the following information:

• EventIndex—Provides relative ordering of the objects in the event log. The value of this object always increases except when:

— the log is reset using the docsDevEvControl MIB

— the device reboots and does not implement non-volatile storage for this log


The next value for all the above cases is 1.

• EventFirstTime—The time that this entry was created.

• EventLastTime—If multiple events are reported via the same entry, the time that the last event for this entry occurred, other-wise this should have the same value as EventFirstTime.

• EventCounts—The number of consecutive event instances reported by this entry. This starts at 1 with the creation of this row and increments by 1 for each subsequent duplicate event.

• EventLevel—The priority level of this event as defined by the vendor. These are ordered from most serious (emergency) to least serious (debug).

• EventId—For this product, uniquely identifies the type of event that is reported by this entry.

• EventText—Provides a human-readable description of the event, including all relevant context.



MTA Log Format MTA logs function within the context of the PKTC-EVENT-MIB.

An ARRIS MTA Alarm event consists of the following information:

• Event Index—Provides relative ordering of the objects in the event log. This also serves as a indicator of event sequence. The object value always increases except when:

— the log is reset using the pktcDevEvControl MIB.

— the device reboots and does not implement non-volatile storage for this log.


The next entry for all the above cases is 1.

• Event Time—Provides a human-readable description of the time at which the event occurred.

• Event Level—The priority level of this event as defined by the vendor.

• Event Enterprise number—The IANA enterprise number: 4115 for ARRIS events, 4491 for PacketCable specified events.

• Event ID—ID for a specific event to which the priority and dis-play string are matched. These Event IDs are vendor specific.

• Event Text—The text message associated with the event. Corre-sponds to the pktcDevEvProgrammableId or pktcDevEvFixe-dId MIBs.

• Mac Address—Provides the MAC address of the device gener-ating the event.

• FQDN/Endpoint ID—The endpoint identifier followed by the FQDN/IP Address of the device. This is in the form AALN/X:FQDN/IP Address. If the event is not specific to an endpoint, then the identifier is just the FQDN/IP address.



Common InformationSeveral log messages display the NIU or battery state.

NIU States The following is a list of valid NIU states and their meanings.

• IS NR (In Service, Normal)—the NIU is operating normally.

• OOS TRBL (Out of Service, Trouble)—the NIU is out of ser-vice due to a detected problem. Both voice and data services may be affected.

NIU Line States The following is a list of valid NIU line states and their meanings.

• IS NR (In Service, Normal)—the line is operating normally.

• IS NR TRAFBSY—the line is in service and off-hook.

• IS TRBL MISMATCH (In Service, Trouble, Mismatch)—the MTA has detected a provisioning mismatch.

• IS TRBL FEF (In Service, Trouble, Family Equipment Fail-ure)—a problem with the MTA subsystem is preventing the line from functioning properly.

• IS TRBL TSTF (In Service, Trouble, Test Failed)—the line failed diagnostics. The Voice Line Diag Failed log provides some more details.

• IS TRBL DIAG (In Service, Trouble, Diagnostics)—the line is running diagnostics; if no problems are discovered, the line will be placed in service when diagnostics are finished.

• IS TRBL LCPRT (In Service, Trouble, Line Card Protection)—the line card is in an overcurrent protection state. This state usu-ally indicates either a short between tip and ring, or a foreign voltage being applied to tip and ring.

• OOS NR (Out of Service, Normal)—the line card is out of ser-vice but has no known problems.

• OOS NR UNPROV (Out of Service, Normal, Unprovisioned)—the line is not provisioned but has no known problems.

• OOS TRBL (Out of Service, Trouble)—the line is out of service due to a detected problem.

• OOS TRBL DIAG (Out of Service, Trouble, Diagnostics)—the line is out of service, and is running diagnostics.



NIU Battery States The following is a list of valid battery states for NIUs with battery backup.

• Normal—the NIU is operating on AC power. The battery is charged and in good condition.

• Battery Low—the NIU has been operating from battery power, and has drawn down the battery to about 25% of its rated capac-ity. AC power has been restored and the battery is recharging.

• Battery Replace—the battery has deteriorated to about 75% of its off-the-shelf capacity and should be replaced.

• Battery Low Replace—the NIU has been operating from battery power, and has drawn down the battery to about 25% of its rated capacity. In addition, the battery has deteriorated and should be replaced. AC power has been restored and the battery is recharging.

• Shutdown Warning—the NIU has nearly exhausted its battery power, and will lose power if AC power is not restored within a few minutes.

• Battery Missing—the battery has been removed or has failed in such a way to appear to be removed.

• Telemetry Unavailable—the NIU does not support battery telemetry.

• Telemetry Invalid—indicates a possible problem with the NIU or the battery system.

• Battery Reversed Shorted (Touchstone Telephony Modem only)—the battery has either been installed backwards or the terminals have been shorted.



Log SummaryThe following is a list of log reports that the TS3.2 software can gener-ate. Go to the indicated page for further details on each log report.

Log Report Event ID Priority Page

MTA Root Certificate download Failed 2417164291 Error 5-8

MTA Security: Service Provider Certificate Chain Validation Failed

2417164293 Error 5-8

MTA Root Certificate download Retry 2417164292 Notice 5-9

MTA Root Certificate download Complete 2417164290 Notice 5-9

Voice Line Diag Failed 1 Info. 5-9

Voice Line Diag Passed 2 Info. 5-10

Voice Line State Change 3 Info. 5-10

Voice Line Protection State Change 6 Info. 5-10

Voice Line Loop Current Change to High 7 Info. 5-11

Voice Line Loop Current Change to Normal 8 Info. 5-11

State Change 10 Info. 5-11

CATV Change 11 Info. 5-11

Power Supply Telemetry 14 Info. 5-11

MTA TFTP: No Channel 15 Info. 5-12

MTA TFTP: Successful 16 Info. 5-12

MTA TFTP: File Not Found 17 Info. 5-12

MTA TFTP: Protocol Error: TFTP Init 18 Info. 5-12

MTA TFTP: Protocol Error: TFTP Open 19 Info. 5-12

MTA TFTP: Protocol Error: TFTP Read 20 Info. 5-13

MTA TFTP: Protocol Error: TFTP Close 21 Info. 5-13

MTA TFTP: Protocol Error: TFTP DB Access

22 Info. 5-13

MTA TFTP: Config File Error 23 Info. 5-14

MTA TFTP: Failed 24 Info. 5-14

MTA PROV: Failed 25 Info. 5-14

MTA PROV: Successful! 26 Info. 5-14



Certificate Downloading Logs

MTA Root Certifi-cate download Failed

TFTP download of the MTA Root Certificate has failed.

Format: MTA Root Certificate download failed: reason

Fields: The reason code is one of the following:

• TFTP Init error (<filename>)

• TFTP Open - Certificate File Not Found (<filename>)

• TFTP Open - Request Sent No Response (<filename>)

• TFTP Open - OUT OF ORDER packets (<filename>)

• TFTP Read - Certificate File Not Found (<filename>)

• TFTP Read - Request Sent No Response (<filename>)

• TFTP Read - OUT OF ORDER packets (<filename>)

• File size exceeds 0x%X (<filename>)

• Allocating space to download Test Root certificate (0x%X)

• Invalid TFTP IP Address

• Invalid File Name

Action: Analyze the logs for possible TFTP failures. Correct any TFTP problems and reset the NIU.

MTA Security: Ser-vice Provider Cer-tificate Chain Validation Failed

The Service Provider Root certificate provisioned on the MTA, and the certificates obtained from the KDC, do not pass the certificate chain validation.

Format: MTA Security: Service Provider Certificate Chain Valida-tion Failed

Action: Make sure that the Service Provider Root certificate on the MTA and the “Service Provider, Local System” and the KDC certificates on the KDC are configured properly.



MTA Root Certifi-cate download Retry

The MTA is retrying its TFTP download of the MTA Root Certificate.

Format: MTA Root Certificate download retry: nd time

Fields: n lists the number of times the NIU has attempted to down-load the Root Certificate (range: 1 to 3)

Action: Monitor the logs for subsequent failure messages.

MTA Root Certifi-cate download Complete

The NIU has successfully downloaded its MTA Root Certificate.

Format: MTA Root Certificate download Complete

Action: None.

MTA Logs

Voice Line Diag Failed

The NIU has failed manual diagnostics for the specified line.

Format: Voice Line Diag Failed, Line Number = line, Failure Rea-son = reason

Fields: The fields are as follows:

• line—The line number of the NIU. The first line is line 1.

• reason—one of the following:

— Line is Unprovisioned

— Invalid State to Init Diags

— Power/Clock Failure

— SLAC Revision Failure

— MPI Failure

— PCM Failure

— Standby Hook Failure

— Active Hook Failure

— VF Failure

— Ringing Failure

Action: Use the reason code to determine the course of action as fol-lows:

• Line is Unprovisioned—Provision the line and re-try the diagnostics.



• Invalid State to Init Diags—Set the line state to oos and re-try the diagnostics.

• others—Reset the NIU and re-try diagnostics. If the problem persists, replace the NIU.

Voice Line Diag Passed

Indicates that the NIU has successfully completed manual diagnostics on the specified line.

Format: Voice Line Diag Passed, Line Number = line

Fields: line indicates the line that passed diagnostics. The first line is line 1.

Action: None.

Voice Line State Change

The NIU received an operator-requested state change for the specified line.

Format: Voice Line State Change, Line Number = line, Prev State = old_state, New State = new_state


• line—the line number of the NIU. The first line is line 1.

• old_state, new_state—the previous and current line states; see “NIU Line States” on page 5-5 for details.

Action: If the new state indicates a trouble condition, correct the problem.

Voice Line Protec-tion State Change

The specified line has detected or cleared a protection fault.

Format: Voice Line Protection State Change, Line Number = line, New State = new_state


• line—the line number of the NIU. The first line is line 1.

• new_state—the current protection state; one of:

— Fault DETECTED

— Fault CLEARED



Action: Monitor the NIU for service issues and possible replace-ment.

Voice Line Loop Current Change to High

The NIU has changed its loop current to High.

Format: Voice Line Loop Current Change to High

Action: If the new loop current should be normal, correct the provi-soning file for the NIU.

Voice Line Loop Current Change to Normal

The NIU has changed its loop current to Normal.

Format: Voice Line Loop Current Change to Normal

Action: If the new loop current should be High, correct the provi-soning file for the NIU.

State Change The NIU has received an operator-requested device state change, usu-ally as a response to the operator changing the value of the ppCfg-MtaAdminState MIB.

Format: State Change from old_state to new_state

Fields: The old_state and new_state fields reflect the previous and current line states. See “NIU Line States” on page 5-5 for details.

Action: None.

CATV Change The Touchstone Telephony Port has received an operator-requested state change for the CATV relay, usually as a response to the operator changing the value of the ppCfgMtaCableTvEnable MIB.

Format: CATV changed from old_state to new_state

Fields: The old_state and new_state fields reflect the previous and current CATV states; valid states are ON and OFF.

Action: None.

Power Supply Telemetry

The NIU has detected a change in its battery telemetry state.

Format: Power Supply Telemetry - state

Fields: The state field reflects the telemetry state; see “NIU Battery States” on page 5-6 for details.



Note: If a low battery condition persists for 24 hours, the NIU generates another Power Supply Telemetry log.

Action: Replace the NIU battery if indicated by the telemetry state.

MTA TFTP: No Channel

The NIU was unable to open a channel to the MTA TFTP server.

Format: MTA TFTP: No Channel

Action: Make sure the TFTP server is functioning and has a route to the HFC network.

MTA TFTP: Suc-cessful

The NIU successfully downloaded its MTA provisioning file.

Format: MTA TFTP: Successful

Action: None.

MTA TFTP: File Not Found

The NIU was unable to locate its MTA provisioning file.

Format: MTA TFTP: File Not Found: file_name

Fields: The file_name field shows the name of the MTA provision-ing file.

Action: Check the MTA provisioning to determine whether the MTA should be looking for a different name. If the provi-sioning is correct, check the TFTP server for proper opera-tion and make sure the file is available (and has read access set).

MTA TFTP: Proto-col Error: TFTP Init

The NIU encountered a TFTP communications error.

Format: MTA TFTP: Protocol Error: TFTP Init: err_code

Fields: The err_code field contains the error code returned by the TFTP software.

Action: Retry the download. If the problem persists, call your next level of support.

MTA TFTP: Proto-col Error: TFTP Open

The NIU encountered a TFTP communications error.

Format: MTA TFTP: Protocol Error: TFTP Open: err_code




Action: Make sure the TFTP server is operating and can be reached from the NIU’s controlling CMTS. Monitor the logs for similar errors from other NIUs to determine whether the problem is limited to one device (which may indicate an NIU defect or connectivity issue) or widespread (which may indicate a problem with the TFTP server or connection). If the problem persists, call your next level of support.

MTA TFTP: Proto-col Error: TFTP Read

The NIU encountered an error while reading a file from the TFTP server.

Format: MTA TFTP: Protocol Error: TFTP Read: err_code


Action: Make sure the TFTP server is operating and can be reached from the NIU’s controlling CMTS. Retry the download; if the problem persists, call your next level of support.

MTA TFTP: Proto-col Error: TFTP Close

The NIU encountered an error while closing its connection to the TFTP server.

Format: MTA TFTP: Protocol Error: TFTP Close: err_code


Action: Make sure the TFTP server is operating and can be reached from the NIU’s controlling CMTS. Retry the download; if the problem persists, call your next level of support.

MTA TFTP: Proto-col Error: TFTP DB Access

The NIU encounted a TFTP communications error.

Format: MTA TFTP: Protocol Error: TFTP DB Access: err_code


Action: Retry the download; if the problem persists, call your next level of support.



MTA TFTP: Config File Error

The MTA configuration file contains invalid MIBs or invalid TLVs.

Format: MTA TFTP: Config File Error

Action: Remove the invalid MIBs and TLVs from the configuration file. The PacketACE configuration editor automatically removes any unrecognized data.

MTA TFTP: Failed The NIU was unable to complete downloading its MTA provisioning file from the TFTP server.

Format: MTA TFTP: Failed

Action: Check for related log messages that may indicate the cause of the problem.

MTA PROV: Failed The NIU was unable to complete its MTA provisioning.

Format: MTA PROV: Failed

Action: Check for related log messages that may indicate the cause of the problem.

MTA PROV: Suc-cessful!

The NIU successfully completed its MTA provisioning.

Format: MTA PROV: Successful!

Action: None.


6 6 Using the Passwordof the Day Tool

This chapter describes the purpose and usage of the ARRIS Password of the Day (PWOD) tool.

Touchstone software provides a web-based troubleshooting interface (see Chapter 8, “Troubleshooting” for details) consisting of two parts:

• Standard pages, available (by default) to both subscribers and operators.

• Advanced pages, available only by entering a password. These pages may contain sensitive information. The password changes daily for further protection.

The PWOD tool generates the appropriate password to access the advanced troubleshooting pages.

About the Password of the Day ToolThe PWOD tool, ARRISpwod.exe, is available on the TS03 software CD. It is a Windows application, with the same hardware and software requirements as the PacketACE tool.

The PWOD tool can create a single password, or a list of passwords for a range of days. For added security, you can also define a seed value used to generate the passwords. Changing the seed requires use of the ARRIS Configuration Tool, a separate utility, to specify the seed value in the NIU configuration file.


6-2 Using the Password of the Day Tool

Using the PWOD ToolThis procedure provides instructions for using the PWOD tool.

Before performing any of the tasks in this procedure, double-click the file to start the PWOD tool. The following diagram shows the tool.

Action Perform the following tasks as needed.

Task Page

Generating a Single Password..................................... 6-2

Generating a List of Passwords ................................... 6-3

Changing the Seed ...................................................... 6-3

Generating a Single Password

Follow these steps to generate a single password.

1 Start the PWOD tool, if you have not done so already.

2 Set the Begin Day and End Day dates to the same date (the default for both fields is the current date).

3 Click the Configure Password of the Day button.

The Password of the Day appears in the text box at the bottom of the PWOD tool window. You can select and copy the password as needed.


Using the Password of the Day Tool 6-3

Generating a List of Passwords

Follow these steps to generate a list of passwords.


2 Set the Begin Day and End Day dates to the range of days that you want to generate passwords for (the default for both fields is the current date).

3 Click the Configure Password of the Day button.

The Password of the Day for the first day appears in the text box at the bottom of the PWOD tool window.

The PWOD tool writes the list of passwords to a file called Passwordoftheday.dat, in the directory where the PWOD tool is located. The file contains a list of dates and the associated password for that day.

Changing the Seed

The PWOD tool can use a default seed to generate the password of the day. For added security, you can create a different seed to change the password pattern. Follow these steps to change the seed.


2 Enter a new seed value in the Seed field at the top of the PWOD window. Make sure the Use Default Seed box is not checked.

The encoded seed appears in the DES encoded field.

Note: The Touchstone NIUs also need to have the changed seed so that their internal PWOD generators remain in sync with the exter-nal tool. Write the DES encoded seed to the PPcfgMTAClientSeed MIB in the NIU configuration file.

3 If you want to save the seed, make sure the Save Seed box is checked.

The PWOD tool saves the new seed to a file called password.dat, in the directory where the PWOD is located. Make sure that any com-puter that can access a password file is reasonably secure.


6-4 Using the Password of the Day Tool


7 7 MIB ReferenceThis chapter lists the MIBs referenced by the TS3.2 software. See Chapter 5, “Troubleshooting,” for a partial list of MIB variables used for troubleshooting.

The MIB files required are shipped on the CD with the TS3.2 software.

Supported MIBsThe TS3.2 software supports all standard MIBs required by DOCSIS.

ARRIS Proprietary MIBs

The following ARRIS-specific MIBs are required for full SNMP sup-port of Touchstone cable modems and are included on the software CD.

ARRIS-MIBA header for the ARRIS enterprise MIB.

ARRIS-CM-DEVICE-MIBThe portion of the ARRIS enterprise MIB that applies to Touch-stone Cable Modems.

PACKETPORT-MIBThe portion of the ARRIS enterprise MIB that applies to Touch-stone NIUs.

DOCSIS MIBs DOCS-CABLE-DEVICE-MIB (RFC-2669)Provides controls and status information in the CMTS and cable modems.

DOCS-IF-MIB (RFC-2670)Describes MCNS compliant Radio Frequency (RF) interfaces in CMTS and cable modems.

DOCS-BPI-MIBDescribes the Baseline Privacy Interface (BPI) implementation in the CMTS and cable modems.

DOCS-BPI2-MIBDescribes the Baseline Privacy Plus Interface (BPI+) implementa-tion in the CMTS and cable modems.


7-2 MIB Reference

DOCS-QOS-MIBDescribes the management information for Quality Of Service (QOS) in DOCSIS 1.1.

DOCS-SUBMGT-MIBDescribes the subscriber management interface for cable modems.

DOCS-IF-EXT-MIBExtensions to the DOCS-IF-MIB.

DOCS-CABLE-DEVICE-TRAP-MIBAn extension of the CABLE DEVICE MIB defined in RFC2669. It defines various trap objects for both cable modems and the CMTS.

PacketCable MIBs PKTC-MTA-MIBSupplies basic management objects for MTA devices.

PKTC-SIG-MIBContains all objects and provisioning data for each endpoint (or telephone line).

PKTC-EVENT-MIBSupplies the basic objects required for reporting events (for exam-ple, logs and alarms).

Network-related MIBs

IF-MIBDescribes generic objects for network interface sub-layers.

BRIDGE-MIB (RFC-1493)An interface to IEEE 802.1D-style bridges.

EtherLike-MIB (RFC-1643)Status objects and counters associated with an Ethernet interface.

IP-MIB (RFC-2011)The MIB module for managing IP and ICMP implementations, but excluding their management of IP routes.

UDP-MIB (RFC-2013)The MIB module for managing UDP implementations.

IGMP-STD-MIBIGMP protocol support.

USB-MIBDescribes the cable modem USB interface.

SNMP-NOTIFICATION-MIBThis MIB module defines MIB objects that provide mechanisms to remotely configure the parameters used by an SNMP entity for the generation of notifications.


MIB Reference 7-3

SNMP-TARGET-MIB (RFC-2573)Defines MIB objects which provide mechanisms to remotely con-figure the parameters used by an SNMP entity for generation of SNMP messages.

SNMP-USER-BASED-SM-MIB (RFC-2574)The management information definitions for the SNMP User-based Security Model (USM).

SNMP-USER-BASED-ACM-MIB (RFC-2575)The management information definitions for the SNMP View-based Access Control Model (ACM).

SNMP-COMMUNITY-MIB This MIB module defines objects to help support coexistence between SNMPv1, SNMPv2, and SNMPv3.

SNMP-USM-DH-OBJECTS-MIBThe management information definitions for providing forward secrecy for key changes for the usmUserTable, and for providing a method for kick-starting access to the agent via a Diffie-Helman key agreement.

SNMP-VIEW-BASED-ACM-MIBThe management information definitions for the View-based Access Control Model for SNMP.

Imports and Definitions

RFC1155-SMICommon definitions for the structure and identification of manage-ment information for TCP/IP-based internets.

RFC1157-SNMPDefines the SNMP protocol.

SNMPv2-PDUDescribes SNMP Protocol Data Units.

SNMPv2-TMDefines textual conventions and objects for transporting SNMP over various network protocols.

SNMPv2-MIBDefines SNMPv2 entities.

SNMP-FRAMEWORK-MIB (RFC-2571)Defines the SNMP management architecture.

SNMP-MPD-MIB (RFC-2572)SNMP Message Processing and Dispatching.

SNMPv2-SMIObject identifiers for SNMPv2.


7-4 MIB Reference

SNMPv2-TCCommon textual conventions, used throughout the MIBs.

SNMPv2-CONFDefinitions for conformance groups.

INET-ADDRESS-MIBDefines textual conventions for representing Internet addresses. An Internet address can be an IPv4 address, an IPv6 address or a DNS domain name.

Order of CompilationSome SNMP managers, notably SNMPc, are sensitive to the order in which MIB files are to be compiled. The following list is the recom-mended order for compilation.

• standard.mib

• snmp_tc.mib

• snmpv2.mib

• snmpv3.mib

• SNMP-COMMUNITY-MIB.mib

• rfc1213.mib

• rfc1215.mib

• rfc1493.mib

• rfc1643.mib

• rfc1907.mib

• rfc2011.mib

• rfc2013.mib

• ianaif.mib

• rfc2233.mib

• rfc2786.mib

• rfc2933.mib

• rfc2670_50.mib

• qos_50.mib

• bpi.mib


MIB Reference 7-5

• bpiplus.mib

• dhkeychg.mib

• rfc2665_50.mib

• rfc2669_50.mib

• DOCS-IF-EXT-MIB.mib

• DOCS-CABLE-DEVICE-TRAP-MIB_50.mib

• lcheader.mib

• lancity_50.mib

• clabs.mib

• mtai02rv_50.mi2

• sigi02rs_50.mi2

• pkevt_50.mib

• almtraps.mib

• arrishdr.mib

• arris_capability.mib

• pp.mib

• usb_50.mib

Note: Files whose names contain the string “_50” are modified for use with SNMPc V5.0. If you are using a different NMS, substitute the files without the string (for example, use rfc2670.mib instead of rfc2670_50.mib).


7-6 MIB Reference


8 8 TroubleshootingThis chapter provides troubleshooting information for operators.

Initial Battery ChargingWhen the Telephony Modem is powered up, whether for the first time or after replacing a battery, it begins a battery charging and testing sequence. See the Installation Guide for your Telephony Modem for details about the charging and testing sequence.

Using MIBs for TroubleshootingUsing an SNMP manager to read cable modem MIB variables can be useful for troubleshooting cable modem issues. The following are MIBs that can provide information to resolve many common issues.

General Touchstone Information

The following variables are located in the ARRIS-CM-DEVICE-MIB and provide information specific to Touchstone cable modems.

arrisCmDevWanIsolationStateDisplays and controls the state of WAN Isolation.

off-InActiveMode(1) - Data traffic passes freely between the home user’s network and the Internet.

on-ActiveMode(2) - The home user’s network is isolated from the Internet. Data traffic does not pass between the home user's network and the Internet.

arrisCmDevSwImageNameThe name of the software image currently operating on the cable modem.

arrisCmDevSwImageBuildTimeThe build date and time of the software image currently operating on the cable modem.


8-2 Troubleshooting

SNMPv2 MIBs The following variables are part of the SNMPv2 MIBs. They provide general information about the cable modem.

sysDescrProvides information about the cable modem hardware revision level, operating software, and networking software.

sysObjectIDProvides authoritative identification of the network management subsystem contained in the cable modem.

sysUpTimeThe time (in 1/100 second increments) since the network manage-ment portion of the cable modem was last re-initialized.

sysORIDDescribes capabilities with respect to various MIB modules sup-ported by the cable modem acting in an agent role

sysORDescrA text description of the capabilities identified by the sysORID variable.

Interface MIBs The following variables are part of the IF-MIB. Each interface (RF, Ethernet, USB) has its own set of variables in the IfTable. The follow-ing are the most useful troubleshooting-related variables.

ifNumberThe number of interfaces listed in the table.

ifIndexThe index number for the interface. The cable modem has the fol-lowing interfaces:

1 = Ethernet interface

2 = RF MAC interface

3 = RF downstream interface

4 = RF upstream interface

5 = USB interface

16 = PacketCable Embedded Interface

The MTA has the following interfaces:

1 = DOCSIS Embedded interface

9 = Voice Over Cable interface

10 = Voice Over Cable interface

ifDescrA text string containing information about the interface.


Troubleshooting 8-3

ifTypeThe interface type. Values for cable modems include:

other(1)

ethernetCsmacd(6)

docsCableMaclayer(127)

docsCableDownstream(128)

docsCableUpstream(129)

usb(160)

Values for MTAs include:

other(1)

voiceOverCable(198)

ifMtuThe size of the largest packet that can be sent and received on the interface, specified in octets. For interfaces that are used for trans-mitting network datagrams, this is the size of the largest network datagram that can be sent on the interface.

ifSpeedAn estimate of the interface's current bandwidth, in bits per second. For interfaces that do not vary in bandwidth or for those where no accurate estimation can be made, this object contains the nominal bandwidth.

ifPhysAddressThe interface's address at its protocol sub-layer. For example, for an 802.x interface, this object normally contains a MAC address. The interface's media-specific MIB must define the bit and byte order-ing and the format of the value of this object.

ifAdminStatusThe desired state of the interface; one of up(1), down(2), or test-ing(3).

When the cable modem initializes, all interfaces start with ifAdmin-Status in the down(2) state. The configuration file can change the value of ifAdminStatus, or you can set it using the SNMP man-ager. The default action is to bring each interface up after loading the configuration file.

The testing(3) state indicates that no operational packets can be passed.


8-4 Troubleshooting

ifOperStatusThe current operational state of the interface; one of up(1), down(2), testing(3), dormant(5), or notPresent(6).

If ifAdminStatus is changed to up(1) then ifOperStatus should change to up(1) if the interface is ready to transmit and receive net-work traffic; dormant(5) indicates that the interface is waiting for some external action. It the status remains down(2), a fault is pre-venting the interface from coming up.

If ifAdminStatus is down(2) then ifOperStatus should also be down(2).

The testing(3) state indicates that no operational packets can be passed. The notPresent(6) indicates missing components (for example, a hardware option that has not been installed).

ifLastChangeThe value of sysUpTime at the time the interface entered its cur-rent operational state. If the current state was entered before the last re-initialization of the local network management subsystem, then this object contains a zero value.

ifInOctetsThe total number of octets received on the interface, including framing characters.

ifInUcastPktsThe number of packets, delivered by this sub-layer to a higher layer (or sub-layer), which were not addressed to a multicast or broadcast address at this sub-layer.

ifInDiscardsThe number of inbound packets which were chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for dis-carding such a packet could be to free up buffer space.

ifInErrorsThe number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol.

ifInUnknownProtosThe number of packets received at the interface which were dis-carded because of an unknown or unsupported protocol. For any interface that does not support protocol multiplexing, this counter will always be 0.

ifOutOctetsThe total number of octets transmitted out of the interface, includ-ing framing characters.


Troubleshooting 8-5

ifOutUcastPktsThe total number of packets that higher-level protocols requested be transmitted, and which were not addressed to a multicast or broadcast address at this sub-layer, including those that were dis-carded or not sent.

ifOutDiscardsThe number of outbound packets which were chosen to be dis-carded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.

ifOutErrorsThe number of outbound packets that could not be transmitted because of errors.

ifOutQLenThe length of the output packet queue (in packets).

ifSpecificA reference to MIB definitions specific to the particular media being used to realize the interface. Values appearing in Touchstone cable modems include:

dot3 (Ethernet)

docsIfMib (RF MAC-level interface)

docsIfDownstreamChannelTable (RF downstream)

docsIfUpstreamChannelTable (RF upstream)

usbMib (USB)


8-6 Troubleshooting

Cable Device MIBs The following variables are part of the DOCS-CABLE-DEVICE-MIB. They provide status and control for the cable modem as a system (as opposed to interface MIBs, which operate on a single interface).

DocsDevBase variablesThe following variable allows you to reset a cable modem from the headend.

docsDevResetNowSet this object to true(1) to reset the cable modem. Reading this object always returns false(2).

DocDevSoftware variablesThese variables provide status and control of the cable modem soft-ware.

docsDevSwServerThe address of the TFTP server used for software upgrades. If the TFTP server is unknown, the value is 0.0.0.0.

docsDevSwFilenameThe file name of the software image to be loaded into this device. Unless changed using an SNMP manager, this is the file name spec-ified by the provisioning server.

docsDevSwAdminStatusControls software loading.

If set to upgradeFromMgt(1), the cable modem starts downloading the software load specified by docsDevSwFilename. After suc-cessfully receiving an image, the cable modem sets its state to ignoreProvisioningUpgrade(3) and reboots. If the download pro-cess is interrupted by a reset or power failure, the cable modem reloads its previous image and, after re-initialization, continues to attempt loading the image specified in docsDevSwFilename.

If set to allowProvisioningUpgrade(2), the cable modem uses the software version information supplied by the provisioning server when next rebooting (this does not cause a reboot).

When set to ignoreProvisioningUpgrade(3), the cable modem disregards software image upgrade information from the provision-ing server.

Note that reading this object can return upgradeFromMgt(1). This indicates that a software download is currently in progress, and that the cable modem will reboot after successfully receiving an image. At initial startup, this object has the default value of allowPro-visioningUpgrade(2).


Troubleshooting 8-7

docsDevSwOperStatusProvides the current software loading status.

InProgress(1) indicates that a TFTP download is underway, either as a result of a version mismatch at provisioning or as a result of a upgradeFromMgt request.

CompleteFromProvisioning(2) indicates that the last software upgrade was a result of version mismatch at provisioning.

CompleteFromMgt(3) indicates that the last software upgrade was a result of setting docsDevSwAdminStatus to upgradeFromMgt.

Failed(4) indicates that the last attempted download failed, ordi-narily due to TFTP timeout.

DocsDevServer variablesThese variables display and control the status of communications with network servers (CMTS, DHCP server, and so forth).

docsDevServerBootStateIf operational(1), the cable modem has completed loading and pro-cessing of configuration parameters and the CMTS has completed the registration exchange.

If disabled(2) then the cable modem was administratively disabled, possibly by being refused network access in the configuration file.

If waitingForDhcpOffer(3) then a DHCP Discover has been trans-mitted and no offer has yet been received.

If waitingForDhcpResponse(4) then a DHCP Request has been transmitted and no response has yet been received.

If waitingForTimeServer(5) then a Time request has been trans-mitted and no response has yet been received.

If waitingForTftp(6) then a request to the TFTP parameter server has been made and no response received.

If refusedByCmts(7) then the Registration Request/Response exchange with the CMTS failed.

If forwardingDenied(8) then the registration process completed, but the network access option in the received configuration file pro-hibits forwarding.

docsDevServerDhcpThe IP address of the DHCP server that assigned an IP address to this cable modem. Returns 0.0.0.0 if DHCP was not used for IP address assignment.


8-8 Troubleshooting

docsDevServerTimeThe IP address of the Time server (RFC-868). Returns 0.0.0.0 if the time server IP address is unknown.

docsDevServerTftpThe IP address of the TFTP server responsible for downloading provisioning and configuration parameters to this cable modem. Returns 0.0.0.0 if the TFTP server address is unknown.

docsDevServerConfigFileThe name of the configuration file read from the TFTP server. Returns an empty string if the configuration file name is unknown.

DocsDevEvent variablesThese variables control event reporting, and describe network or device events that may be of interest in fault isolation and troubleshooting. Multiple sequential identical events are represented by incrementing docsDevEvCounts and setting docsDevEvLastTime to the current time rather than creating multiple rows. Entries are created with the first occurrence of an event.

Use docsDevEvControl to clear the table. Individual events can not be deleted.

docsDevEvControlSet this object to resetLog(1) to erase the event log.

Set this object to useDefaultReporting(2) to restore all event pri-orities to their factory-default reporting.

Reading this object always returns useDefaultReporting(2).

docsDevEvSyslogThe IP address of the Syslog server. If 0.0.0.0, syslog transmission is inhibited.

docsDevEvIndexProvides relative ordering of the objects in the event log. This object always increases except when the log is reset via docsDe-vEvControl, the cable modem reboots and does not keep the event log in non-volatile storage, or the value reaches 2^31. The next entry for all the above cases is 1.

docsDevEvFirstTimeThe time that a particular event log entry was created. Multiple identical events can be reported using a single entry.

docsDevEvLastTimeIf multiple events are reported using the same entry, the time that the last event for this entry occurred. Otherwise this should have the same value as docsDevEvFirstTime.


Troubleshooting 8-9

docsDevEvCountsThe number of consecutive event instances reported by this entry. This starts at 1 with the creation of this entry and increments by 1 for each subsequent duplicate event.

docsDevEvLevelThe priority level of this event. These are ordered from most serious (emergency) to least serious (debug).

docsDevEvIdFor a particular device, uniquely identifies the type of event that is reported by this entry.

docsDevEvTextA text string describing the event, including all relevant context (interface numbers, etc.).

PacketCable Event MIB

The following variables are part of the PKTC-EVENT-MIB. They sup-ply the basic management objects for reporting events. See Chapter 4, “Interpreting Alarms,” and Chapter 5, “Interpreting Logs,” for events and their formats.

pktcDevEventControl MIBThe following variables control PacketCable event reporting.

pktcDevEvControlDefines actions related to the event log configuration. Settings are:

resetLog(1) — empties the event log (deletes all data).

setDefault(2) — restores all event priorities to factory default reporting parameters.

useConfigured(3) — reloads previously configured reporting parameters.

pktcDevEvControlStateThe state of the device as modified by pktcDevEvControl. The pos-sible states are those listed above, plus Processing (indicates that a state change is in process).

pktcDevEvSyslogAddressTypeThe type of Internet address of the Syslog server.

pktcDevEvSyslogAddressThe IP address of the Syslog server. Use 0.0.0.0 to specify no Sys-log server. Using an FQDN is allowed but not recommended.

pktcDevEvSyslogUdpPortThe UDP port number that the MTA uses to send requests to the Syslog server.


8-10 Troubleshooting

pktcDevEventThrottle MIBThe following variables control event throttling.

pktcDevEvThrottleAdminStatusControls the transmission of traps and syslog messages with respect to the trap pacing threshold.

throttlingInhibited(1) —transmit traps and syslog messages with-out regard to the threshold settings. (default)

dynamicThresholding(2) — suppresses trap transmission and sys-log messages to be suppressed if the number of traps would other-wise exceed the threshold.

manualThresholding(3) — trap transmissions cease at the thresh-old, and do not resume until directed to do so.

eventsInhibited(4) — suppresses all trap transmission and syslog messages.

A single event is always treated as a single event for threshold counting. That is, an event causing both a trap and a syslog message is still treated as a single event. Writing to this object resets the thresholding state.

pktcDevEvThrottleInhibitedIf true(1), trap/inform and syslog transmission is currently inhib-ited due to: thresholds; the current setting of pktcDevEv-ThrottleAdminStatus; or no syslog (pktcDevEvSyslogAddress) or trap/inform (pktcMtaDevSnmpEntity) destinations have been set.

pktcDevEvThrottleThresholdSets the number of trap/syslog events per pktcDevEvThrottle-Interval to be transmitted before throttling. A single event is always treated as a single event for Threshold counting. That is, an event causing both a trap/inform and a syslog message is still treated as a single event. At initial startup, this object returns 2.

pktcDevEvThrottleIntervalThe interval over which the throttle threshold applies. At initial star-tup, this object has a value of 1.

pktcDevEvProgrammableTableThis table is part of the pktcDevEventConfig MIB. It configures the reporting of the various programmable events. This table allows control of the reporting of event classes. For each event priority, a combination of logging and reporting mechanisms may be chosen. The mapping of event types to priorities is vendor-dependent. Vendors may also choose to allow the user to control that mapping through proprietary means.


Troubleshooting 8-11

pktcDevEvProgrammableIdID for a specific programmable event to which the priority and dis-play string are matched. These Event Ids are vendor specific or in the case of PacketCable events defined in pkt-tr-memevent-id-v01-001128.

pktcDevEvProgrammableEnterpriseProvides the IANA enterprise number of the device manufacturer for proprietary events, and the CableLabs IANA enterprise number for PacketCable specified events.

pktcDevEvProgrammableLevelThe priority level controlled by this entry. These are ordered from most (critical) to least (information) critical. Each event has a par-ticular priority level associated with it. The levels are described as:

critical(1) —A service-affecting condition that requires immediate corrective action.

major(2) — A service-affecting condition that requires urgent cor-rective action.

minor(3) — A non-service-affecting fault condition which warrants corrective action in order to avoid a more serious fault.

warning(4) — A potential or impending condition which can lead to a fault; diagnostic action is suggested.

information(5) — Normal event meant to convey information.

pktcDevEvProgrammableReportingDefines the action to be taken on occurrence of this event class. Implementations may not necessarily support all options for all event classes, but at minimum must allow traps and Syslog to be disabled. The value is a collection of bits:

local(0) bit — log to the internal log

traps(1) bit — generate a trap

syslog(2) bit — send a Syslog message (assuming the Syslog address is set)

inform(3) bit — generate an inform

none(4) bit — this event is not generated

pktcDevEvProgrammableTextA programmable event display string providing a human-readable description of the event.



pktcDevEvFixedTable MIBThis table is part of the pktcDevEventConfig MIB. It configures the reporting of the various fixed events (including level, and report type) and event classes.

For each event priority, a combination of logging and reporting mecha-nisms may be chosen. The mapping of event types to priorities is ven-dor-dependent.

pktcDevEvFixedIdID for a specific fixed event to which the priority and display string are matched. These Event Ids are vendor specific or in the case of PacketCable events defined in pkt-tr-memevent-id-v01-001128.

PktcDevEvFixedEnterpriseProvides the IANA enterprise number of the device manufacturer for proprietary events, and the CableLabs IANA enterprise number for PacketCable specified events.

pktcDevEvFixedLevelThe priority level that is controlled by this entry. These are ordered from most (critical) to least (information) critical. Each event has a particular priority level associated with it (as defined by the ven-dor). The levels are:

critical(1) - A service-affecting condition that requires immediate corrective action.

major(2) - A service-affecting condition that requires urgent cor-rective action.

minor(3) - A non-service-affecting fault condition which warrants corrective action in order to avoid more serious fault.

warning(4) - A potential or impending condition which can lead to a fault; diagnostic action is suggested.

information(5) - Normal event meant to convey information.

pktcDevEvFixedReportingDefines the action to be taken on occurrence of this event class. Implementations may not necessarily support all options for all event classes, but at minimum must allow traps and Syslog to be disabled. The value is a collection of bits:

local(0) bit — log to the internal log

traps(1) bit — generate a trap

syslog(2) bit — send a Syslog message (assuming the Syslog address is set)

inform(3) bit — generate an inform



none(4) bit — this event is not generated.

pktcDevEvFixedTextA fixed event display string providing a human-readable descrip-tion of the event.

pktcDevEventLocal MIBThis MIB provides the pktcDevEvent table, that contains a log of net-work and device events that may be of interest in fault isolation and troubleshooting.

pktcDevEvIndexProvides relative ordering of the objects in the event log. This object will always increase except when (a) the log is reset via pktcDevEvControl, (b) the device reboots and does not implement non-volatile storage for this log, or (c) it reaches the value 2^31. The next entry for all the above cases is 1. This also serves as a indi-cator of event sequence.

PktcDevEvTimeProvides a human-readable description of the time at which the event occurred.

pktcDevEvLevelThe priority level of this event as defined by the vendor. These are ordered from most serious (critical) to least serious (debug).

pktcDevEvEnterpriseProvides the IANA enterprise number of the device manufacturer for proprietary events, and the CableLabs IANA enterprise number for PacketCable specified events.

pktcDevEvIdID for a specific event to which the priority and display string are matched. These Event Ids are vendor specific or in the case of Pack-etCable events defined in pkt-tr-memevent-id-v01-001128.

pktcDevEvTextProvides a human-readable description of the event, including all relevant context (interface numbers, etc.).

pktcDevEvMacAddressProvides the MAC address of the device generating the event.

pktcDevEvEndpointNameThis is the endpoint identifier followed by the FQDN/IP Address of the device. This is in the form - AALN/X:FQDN/IP Address. If the event is not specific to an endpoint, then the contents is just the FQDN/IP address.



MTA MIB This MIB module supplies the basic management objects for the MTA Device.

The MTA MIB only supports a single provisioning server.

pktcMtaDevResetNowSetting this object to true(1) causes the device to reset. Reading this object always returns false(2). When set to true, the following actions occur:

1. All connections (if present) are flushed locally.

2. All current actions such as ringing immediately terminate.

3. Requests for notifications such as notification based on digit map recognition are flushed.

4. All endpoints are disabled.

5. The provisioning flow is started at step MTA-1 of the provision-ing process.

pktcMtaDevMacAddressThe telephony MAC address for this device.

pktcMtaDevFQDNThe Fully Qualified Domain Name for this MTA.

pktcMtaDevEndPntCountThe physical end points for this MTA.

pktcMtaDevEnabledThe MTA Administrative Status of this device, where True(1) means the voice feature is enabled and false(2) indicates that it is disabled.

pktcMtaDevProvisioningStateThe completion state of the initialization process, sent as part of the final INFORM (step MTA-25 of the provisioning process).

If the configuration file could be parsed successfully and the MTA is able to reflect the same in its MIB, it must return: pass.

If the configuration file was in error due to incorrect values Packet-Cable in the mandatory parameters, the MTA must reject the con-figuration file and return: fail.

If the configuration file had proper values for all the mandatory parameters but has errors in any of the optional parameters (includ-ing any vendor specific OIDs which are incorrect or not known to the MTA), it must return: passWithWarnings.

If the configuration file is proper, but the MTA cannot reflect the same in its MIB (for example, too many entries leading to memory



exhaustion), it must accept details related to the CMSs passWith-IncompleteParsing.

If the configuration file cannot be parsed due to an internal error it must return: failureInternalError.

If the MTA cannot accept the configuration file for any other reason than the ones stated above, it must return failureOtherReason.

pktcMtaDevHttpAccessIndicates whether HTTP file access is supported for MTA configu-ration file transfer.

pktcMtaDevProvisioningTimerEnables setting the duration of the provisioning timeout timer. The timer covers the provisioning sequence from step MTA-1 to step MTA-23. The value is in minutes and setting the timer to 0 disables this timer. The default value for the timer is 10.

pktcMtaDevProvisioningCounterThis object is the count of the number of times the provisioning cycle has looped through step MTA-1 since the last reboot.

pktcMtaDevErrorOidsTableIf pktcMtaDevProvisioningState is reported with anything other than a pass(1), then this table is populated with the necessary information, each pertaining to observations of the configuration file. Even if different parameters share the same error (for example, all Realm Names are invalid), all recognized errors must be reported as different instances. This contains the necessary informa-tion an MTA must attempt to provide in case the configuration file is not parsed and/or accepted in its entirety.

pktcMtaDevErrorOidIndexThis is the index to pktcMtaDevErrorOidsEntry. This is an integer value and will start from the value 1and be incremented for each error encountered in the configuration file. The indices need not necessarily reflect the order of error occurrences in the configura-tion file.

pktcMtaDevErrorOidThis is the OID associated with the particular error. If the error was not due to an identifiable OID, then this can be populated with impartial identifiers, in hexadecimal or numeric format.

pktcMtaDevErrorGivenIf the error was due to the value associated with the corresponding pktcMtaDevErrorOid, then this contains the value of the OID as interpreted by the MTA in the configuration file provided. If the error was not due to the value of an OID this must be set to an empty string. This is provided to eliminate errors due to misrepre-sentation or misinterpretation of data.



pktcMtaDevErrorReasonThis indicates the reason for the error, as per the MTA’s interpreta-tion, in human readable form. For example:

VALUE NOT IN RANGE

VALUE DOES NOT MATCH TYPE

UNSUPPORTED VALUE

LAST 4 BITS MUST BE SET TO ZERO

OUT OF MEMORY - CANNOT STORE

This MAY also contain vendor specific errors for vendor specific OIDs and any proprietary error codes/messages which can help diagnose errors better, in a manner the vendor deems fit.

pktcMtaDevConfigFileThe URL of the TFTP/HTTP file for downloading provisioning and configuration parameters to this device. Returns NULL if the server address is unknown. Supports both TFTP and HTTP.

pktcMtaDevSnmpEntityThe FQDN of the SNMP V3 entity of the Provisioning Server to which the MTA has to communicate in order to receive the access method, location and the name of the Configuration file during MTA provisioning. This would also be the entity which caters to the End-point provisioning needs of the MTA and is the destination for all provisioning informs. It may be also used for post-provisioning SNMP operations.

pktcMtaDevProvStateoperational(1) — the device has completed loading and processing of initialization parameters.

disabled(2) — the device was administratively disabled, possibly by being refused network access in the configuration file.

waitingToStart(10) — the MTA is has not received a signal to start initialization.

waitingForDhcpOffer(12) — a DHCP Discover has been transmit-ted and no offer has yet been received.

waitingForDhcpAckResponse(14) — a DHCP Request has been transmitted and no response has yet been received.

waitingProvRealmKdcNameResponse(16) — a DNS Srv request has been transmitted and no reply has yet been received.

waitingForProvRealmKdcAddrResponse(18) — a DNS request has been transmitted and no reply has yet been received.



waitingForAsReply(20) — an AS request has been and no MSO KDC AS Kerberos ticket reply has yet been received.

waitingForTgsReply(22) — a TGS request has been transmitted and no TGS ticket reply has yet been received.

waitingForApReply(24) — an AP request has been transmitted and no SNMPv3 key info reply has yet been received.

waitingForSnmpGetRequest(26) — an INFORM message has been transmitted and the device is waiting on optional/iterative GET requests.

waitingForSnmpSetInfo(28) — the device is waiting on configu-ration file download access information.

waitingForTftpAddrResponse(30) — a DNS request has been transmitted and no reply has yet been received.

waitingForConfigFile(32) — a TFTP request has been transmitted and no reply has yet been received or a download is in progress.

waitingForTelRealmKdcNameResponse(34) — a DNS Srv request has been transmitted and no name reply has yet been received.

waitingForTelRealmKdcAddrResponse(36) — a DNS request has been transmitted and no address reply has yet been received.

waitingForPkinitAsReply(38) — an AS request has been transmit-ted and no ticket reply has yet been received.

waitingForCmsKerbTickTgsReply(40) — a TGS request has been transmitted and no ticket reply has yet been received.

waitingForCmsKerbTickApReply(42) — a AP request has been transmitted and no Ipsec parameters reply has yet been received.

pktcMtaDevServerDhcp1The IP address of the primary DHCP server which would cater to the MTA during its provisioning. Contains 255.255.255.255 if there was no preference given with respect to the DHCP servers for MTA provisioning.

pktcMtaDevServerDhcp2The IP address of the Secondary DHCP server which could cater to the MTA during its provisioning. Contains 0.0.0.0 if there is no spe-cific secondary DHCP server to be considered during MTA provi-sioning.

pktcMtaDevTimeServerIP address of the Time Server from which to obtain the time. Con-tains 0.0.0.0 if the Time Protocol is not used for time synchroniza-tion.



pktcMtaDevRealmTableShows the KDC realms. The table is indexed with pktcMtaDev-RealmName. The Realm Table is used in conjunction wit h any server which needs a security association with an MTA. The server table (today the CMS) has a security association. Each server-MTA security association is associated with a single Realm. This allows for multiple realms, each with its own security association. Con-tains per Kerberos realm security parameters.

pktcMtaDevRealmNameThe corresponding Kerberos Realm name. This is used as an index into pktcMtaDevRealmTable. When used as an index, the upper case ASCII representation of Realm Name MUST be used by both the Manager (SNMPv3 Entity) and the MTA.

pktcMtaDevRealmPkinitGracePeriodFor the purposes of the key management with an Application Server (CMS or Provisioning Server), the MTA MUST obtain a new Ker-beros ticket (with a PKINIT exchange) this many minutes before the old ticket expires. The minimum allowable value is 15 minutes. The default is 30 minutes. This parameter MAY also be used with other Kerberized applications.

pktcMtaDevRealmTgsGracePeriodWhen the MTA implementation uses TGS Request/TGS Reply Ker-beros messages for the purpose of the key management with an Application Server (CMS or Provisioning Server), the MTA MUST obtain a new service ticket for the Application Server (with a TGS Request) this many minutes before the old ticket expires. The mini-mum allowable value is 1 min. The default is 10 minutes. This parameter MAY also be used with other Kerberized applications.

pktcMtaDevRealmOrgNameThe value of the X.500 organization name attribute in the subject name of the Service provider certificate.

pktcMtaDevRealmUnsolicitedKeyMaxTimeoutThis timeout applies only when the MTA initiated key manage-ment. The maximum timeout is the value which may not be exceeded in the exponential backoff algorithm. Default value is 30.

pktcMtaDevRealmUnsolicitedKeyNomTimeoutDefines the starting value of the timeout for the AS-REQ/REP Backoff and Retry mechanism with exponential timeout. If pro-vided, DHCP Option 177 Sub-option 10 overrides this value. Default value is 10000.

pktcMtaDevRealmUnsolicitedKeyMeanDevA measurement of the mean deviation for the round trip delay timings.



pktcMtaDevRealmUnsolicitedKeyMaxRetriesThe maximum number of retries before the MTA gives up attempt-ing to establish a security association.

pktcMtaDevRealmStatusContains the Row Status associated with the pktcMtaDev-RealmTable.

pktcMtaDevCmsTableShows the IPSec key management policy relating to a particular CMS. The table is indexed with pktcMtaDevCmsFQDN. Contains per CMS key management policy.

pktcMtaDevCmsFqdnThe fully qualified domain name of the CMS. This is the index into the pktcMtaDevCmsTable. When used as an index, the upper case ASCII representation of the associated CMS FQDN MUST be used by both the Manager (SNMPv3 Entity) and the MTA.

pktcMtaDevCmsKerbRealmNameThe Kerberos Realm Name of the associated CMS. This is the index into the pktcMtaDevRealmTable. When used as an index, the upper case ASCII representation of the associated CMS FQDN must be used by both the Manager (SNMPv3 Entity) and the MTA.

pktcMtaDevCmsMaxClockSkewThe maximum allowable clock skew between the MTA and CMS

pktcMtaDevCmsSolicitedKeyTimeoutThis timeout applies only when the CMS initiated key management (with a Wake Up or Rekey message). It is the period during which the MTA will save a nonce (inside the sequence number field) from the sent out AP Request and wait for the matching AP Reply from the CMS.

pktcMtaDevCmsUnsolicitedKeyMaxTimeoutThis timeout applies only when the MTA initiated key manage-ment. The maximum timeout is the value which may not be exceeded in the exponential backoff algorithm.

pktcMtaDevCmsUnsolicitedKeyNomTimeoutDefines the starting value of the timeout for the AP-REQ/REP Backoff and Retry mechanism with exponential timeout for CMS. If provided, the MTA-configuration file content overrides this value.

pktcMtaDevCmsUnsolicitedKeyMeanDevThe measurement of the mean deviation for the round trip delay timings.



pktcMtaDevCmsUnsolicitedKeyMaxRetriesThe maximum number of retries before the MTA gives up attempt-ing to establish a security association.

pktcMtaDevCmsStatusContains the Row Status associated with the pktcMtaDevCms-Table.

pktcMtaDevCmsIpsecCtrlIf true(1), IPSEC and IPSEC Key Management MUST be used to communicate with the CMS.

If false(2), IPSEC Signaling Security is disabled for both the IPSEC Key Management and IPSEC protocol (for the specific CMS).

pktcMtaCmsMapTableContains the signaling associations between MTA endpoints and CMSs. It maps the endpoint to zero or more entries in pktcMta-DevCmsTable. Contains per endpoint CMS signaling associations.

pktcMtaCmsMapCmsFqdnThe index for the associated CMS. Valid indices are equal to current pktcMtaDevCmsFqdn values.

pktcMtaCmsMapOperStatusIndicates which signaling association the endpoint is actively using. The operational status of signaling association. The meaning of the status is as follows: inactive - signaling is not currently active, active - signaling is active.

pktcMtaCmsMapAdminStatusIndicates whether or not an endpoint should use a particular CMS and its security association. By setting this flag to inhibit, this asso-ciated CMS cannot provide signaling to the referenced endpoint. The administrative status for signaling over the indicated security association. The meaning of the status is as follows: inhibit - sig-naling is not currently allowed, allow - signaling is allowed.

pktcMtaCmsMapRowStatusAllows for the creation and deletion of endpoint mappings via the NMS. This object is used for creating and deleting an entry in this table via an element manager.

Setting up Security AssociationsA security association may be set up using either configuration or NCS signaling initiation.

When using the configuration file, the realm must be configured first. Associated with the realm is a KDC. The realm table (pktcMtaDev-RealmTable) indicates information about the realm (e.g., name, organi-



zation name) and parameters associated with KDC communications (e.g., grace periods, AS request/AS reply adaptive backoff parameters). Once the realm is established, one or more servers may be defined in the realm. For PacketCable 1.0, these are Call Management Servers (CMSs). Associated with each CMS entry in the pktcMtaDevCm-sTable is an explicit reference to a Realm via the realm index (pktc-MtaDevCmsKerbRealmName), the FQDN of the CMS, and parameters associated with IPSec key management with the CMS (e.g., clock skew, AP request/ AP reply adaptive backoff parameters).

Signaling MIB This MIB module supplies the basic management object for the Packet-Cable Signaling protocols. This version of the MIB includes common signaling and Network Call Signaling (NCS) related signaling objects.

PktcCodecTypeTextual Convention defines various types of CODECs that MAY be supported. The list of CODECs MUST be consistent with the CODEC specification PKT-SP-CODEC-I04-021018.

PktcRingCadenceRepresents a ring cadence in bit string format. The ring cadence representation starts with the first 1 in the pattern (the leading 0s in the MSB are padding and are to be ignored). Each bit represents 100ms of tone; 1 is tone, 0 is no tone.

60 bits are used for cadence representation, the least significant 4 bits represent repeatable characteristics. 0000 means repeatable, and 1000 means non repeatable.

As an example, the hex representation of a ring cadence of 0.5 sec-onds on; 4 seconds off; repeatable would be: 0x1F0000000000.

PktcSigTypeThe various types of signaling that may be supported.

ncs - Network Call Signaling; a derivation of MGCP (Media Gate-way Control Protocol) version 1.0.

dcs - Distributed Call Signaling; a derivation of SIP (Session Initi-ation Protocol) RFC 2543

pktcSigDevCodecTableThis table describes the MTA supported CODEC types.

pktcSigDevCodecIndexThe index value which uniquely identifies an entry in the pktc-SigDevCodecTable.

pktcSigDevCodecTypeA CODEC type supported by this MTA.



pktcSigDevCodecMaxThe maximum number of simultaneous sessions of the specific codec that the MTA can support.

pktcSigDefNcsReceiveUdpPortContains the MTA User Datagram Protocol (UDP) receive port that is being used for NCS call signaling. This object should only be changed by the configuration file.

Default value is 2427.

pktcSigNcsServiceFlowStateContains a status value of the Call Signaling Service Flow.

not-active indicates that the NCS SF is not being used, and has not tried to be created.

active indicates that the NCS SF is in use.

error indicates that the NCS SF creation resulted in an error and the best effort channel is used for NCS Signaling

pktcNcsEndPntConfigCallAgentIdContains a string indicating the call agent name (for example, [email protected]). The call agent name after the character @ MUST be a fully qualified domain name and MUST have a corre-sponding pktcMtaDevCmsFqdn entry in the pktcMtaDevCms-Table.

pktcNcsEndPntConfigCallAgentUdpPortContains the call agent User Datagram Protocol (UDP) receive port that is being used for this instance of call signaling, i.e. the default port on which the call agent receives NCS signaling from the gate-way. The default port number is 2727.

pktcNcsEndPntConfigStatusContains the Row Status associated with the pktsNcsEndPnt-Table.

pktcNcsEndPntConfigCallWaitingMaxRepContains the maximum number of repetitions of the call waiting tone that the MTA plays from a single CMS request. A value of zero (0) can be used if the CMS is to control the repetitions of the call waiting tone.

pktcNcsEndPntConfigCallWaitingDelayContains the delay between repetitions of the call waiting tone that the MTA plays from a single CMS request.

pktcNcsEndPntStatusCallIpAddressContains the IP address of the CMS currently being used for this endpoint. This IP address creates the appropriate security associa-tion.



pktcNcsEndPntStatusErrorContains the error status for this interface. The operational state indicates that all operations necessary to put the line in service have occurred.

The noSecurityAssociation status indicates that no security asso-ciation yet exists for this endpoint.

The disconnected status indicates that the security Association has been established and the NCS signaling Software is in process of establishing the NCS signaling Link via an RSIP exchange.

Packet Port MIB This MIB contains ARRIS-proprietary variables used to control the MTA portion of Touchstone NIUs.

CountryCodeThese are the countries for the country code template object. northAmerica57(1), chile(2), japan(3), australia(4), austria(5), france(6), germany(7), ireland(8), netherlands(9), portugal(10), spain(11), belgium(12), poland(13), israel(14), czechRepub-lic(15), brazil(16), northAmerica33(17), northAmerica09(18)

ppCfgPortTxGainControlThe per line transmit gain control setting (dB). Not currently used.

ppCfgPortRxGainControlThe per line receive gain control setting (dB). Not currently used.

ppCfgMtaCableTvEnableProvides the ability to turn the cable off and on.

ppCfgMtaDataInterfaceThe data interface type: eth10baset(1), hpna1mbps(2), hpna10mbps(3), eth100baset(4), eth100basex(5).

ppCfgMtaCallpFeatureSwitchSee “CallP Feature Switch” on page 3-5 for details.

ppSurvPortMaintStateThe maintenance state of the line: isnr(1), isnr-trafbsy(2), istrbl-mismatch(3), istrbl-fef(4), istrbl-tstf(5), istrbl-diag(6), istrbl-lcprt(7), oosnr-unprov(8), oosnr(9), oostrbl(10), oostrbl-tstf(11), oostrbl-diag(12), oostrbl-lcprt(13)

ppSurvPortLcDiagRequestSetting this value to true sends a diagnostics request on the line. Reading this value always returns false. The maintenance state of the line indicates if diagnostics are being run on the line.

ppSurvPortLcDiagLastResultThe last result of diagnostics for this line: diagnostics-passed(1), slac-revision-failure(2), mpi-failure(3), power-or-clock-fail-



ure(4), pcm-failure(5), standby-hook-failure(6), active-hook-failure(7), vf-failure(8), ringing-failure(9), invalid-state-to-init-diags(10), line-is-unprovisioned(11), diagnostics-results-pending(12). If diagnostics are in progress it returns diagnostics-results-pending.

ppSurvMtaPowerSupplyTeleThe battery telemetry state: tlm-unavailable(0), tlm-invalid(1), tlm-shutdown-warning(2), tlm-batt-reversed-shorted(3), tlm-batt-low-replace-ac-fail(4), tlm-batt-low-replace(5), tlm-batt-low-ac-fail(6), tlm-batt-low(7), tlm-batt-missing(8), tlm-ac-fail-batt-replace(9), tlm-replace-batt(10), tlm-ac-fail(11), tlm-nor-mal(12)

ppSurvMtaMaintStateThe maintenance state of the PacketPort: isnr(1), istrbl(2), oos(3).



LED PatternsTouchstone NIUs indicate status using the five LEDs on the front panel.

Patterns: Normal Operation

The following table shows LED patterns during normal operation. An x indicates that the particular LED is not important for determining the state.

NameDescription

Power Online Cable USB Ethernet

Off Off Off Off Off No power

On Blink x x x Standby switch active (the computers are dis-connected from the Internet)

On On x x x Standby switch inactive

On x On x x No data to/from the cable interface

On x Blink x x Data activity on the cable interface

On x x Off x USB link disconnected (i.e. PC is disconnected or powered off)

On x x On x USB link connected, no traffic

On x x Blink x USB data activity with PC

On x x x Off Ethernet link disconnected (i.e. equipment is disconnected or powered off)

On x x x On Ethernet link connected, no traffic

On x x x Blink Ethernet data activity with connected equipment



Patterns: Startup Sequence (Telephony Modem)

The following table shows the Touchstone Telephony Modem LED pat-terns during each phase of the startup sequence.

Patterns: Startup Sequence (Telephony Port)

The following table shows the Touchstone Telephony Port 7-segment LED patterns during each phase of the startup sequence.

The “walking” pattern lights each outside segment in a circular pattern. With no telephony enabled, the LED cycles through its three horizontal segments. See the Touchstone Telephony Port Installation Guide, ARSVD00461, for details.

State Pwr Cable Data Tele. Online

Hardware Diags On Off Off Off Off

DOCSIS Downstream Scanning

On Blink Off Off Off

DOCSIS Ranging On Blink Off On Off

DOCSIS DHCP On Off Blink Off Off

DOCSIS TFTP On Off Blink On Off

DOCSIS Data Reg Complete

On On Blink Off On

MTA DHCP On Off Off Blink On

MTA TFTP On Off On Blink On

MTA Reg with Call Server

On On Off Blink On

MTA Reg Complete On On Blink On On

State Display

Hardware Diags “0”

DOCSIS Downstream Scanning “1”

DOCSIS Ranging “2”

DOCSIS DHCP “3”

DOCSIS TFTP “4”

DOCSIS Data Reg Complete “d”

MTA DHCP “6”

MTA TFTP “7”

MTA Reg with Call Server “8”

MTA Reg Complete walking



End of Call Connection StatisticsThe TS3.2 software release supports the PacketCable defined call con-nection statistics. The software sends connection statistics to the call server during the call tear down procedure. PacketCable compliant call servers should provide a method of reporting these captured statistics (see your call server documentation for instructions on accessing the statistics). The statistics provide information on the performance of the network including the following:

• Number of packets sent

• Number of octets sent

• Number of packets received

• Number of octets received

• Number of packets lost in transit

• Interarrival jitter—the mean deviation (smoothed absolute value) of the difference in packet spacing at the receiver com-pared to the sender for a pair of packets.

• Average transmission delay

Note: This statistic reports the network delay, not one-way delay. It does not account for delay within the device such as jit-ter buffers etc. It strictly measures the delay of the traffic travel-ling the users network.

In addition to the parameters above, an endpoint that has received one or more RTCP sender or receiver reports from its peer must also send the following statistics:

• Remote packets sent

• Remote octets sent

• Remote packets lost

• Remote jitter

Complete definitions of these statistics can be found in the PacketCable Network-Based Call Signaling Protocol Specification, PKT-SP-EC-MGCP-I08-030728.



Web-based Troubleshooting InterfaceThe TS3.2 software provides a web-based interface to a status monitor-ing and troubleshooting subsystem. Status information is available to anyone by using a standard web browser to access the cable modem IP address. A password-protected set of pages provides views of advanced network settings.

The following sections describe the screens available from the web interface. The procedure “Accessing the Troubleshooting Interface” on page 8-35 provides instructions for accessing the screens.

Standard Screens Anyone can access the screens described in this section.

Status ScreenThe status screen is the index page, and can also be selected by choos-ing the Status link at any standard screen. The following is an exam-ple:

Note: The IP address and mask information is available only if you have entered the correct Password of the Day to access the advanced pages.

The top section of this page provides the following information:

• Hardware and software revision

• System uptime

• Cable modem status



• Number of computers on the LAN that the modem detected

• NIU serial number

The bottom section provides the names, MAC addresses, and status of each interface on the NIU. For subscriber-side data interfaces (Ethernet and USB), the page also reports interface speed in Mb/sec.

HW/SW Versions ScreenThe Hardware/Software Versions screen provides information about the hardware and software revision levels. To display this screen, choose the HW/SW Versions link.

Event Log ScreenThe Event Log screen displays a table of recent events. The NIU stores the event log in non-volatile memory. To display this screen, choose the Event Log link.



Registration Status ScreenThe Registration Status screen shows the results of the NIU registration process and current battery telemetry state. To display this screen, choose the CM State link.

Advanced Screens The following screens require a password of the day. Use the Basic link on any screen to return to the standard status pages.

Note: Advanced screens contain potentially sensitive information about the network.

Product Details ScreenThe Detailed Status screen provides the following information:

• NIU status

• IP and MAC address parameters

• system information, including enabled features



To access this screen, choose the Product link from any advanced screen.



DHCP ParametersThe DHCP Parameters screen lists DHCP details for the cable modem and MTA portions of the MTA. To access this screen, choose the DHCP link from any advanced screen.



MTA Parameters ScreenThe MTA Parameters screen shows MTA-related communications parameters and the value of the Callp Feature switch. To access this screen, choose the MTA link from any advanced screen.

CallP/QoS Statistics ScreenThe Callp/QoS Statistics screen shows the MTA Callp state and QoS statistics. To access this screen, choose the CallP/QoS link from any advanced screen.



Configuration Parameters ScreenThe Configuration Parameters screen shows the values of common cable modem and MTA configuration parameters. To access this screen, use the Config Params link from any advanced screen.

Note: The above screen is modified to show only partial cable modem and MTA parameters. An actual Configuration Parameters screen is likely to be very long.



Accessing the Troubleshooting InterfaceUse this procedure to access the standard and advanced troubleshooting pages.

Access Options You can access the troubleshooting screens through either the Touch-stone Telephony product RF or Ethernet interfaces.

Requirements You need the following equipment to access the troubleshooting pages:

• computer with an Ethernet interface and a web browser

• Ethernet cable (if using the NIU Ethernet interface)

• (advanced pages only) the password of the day

Controlling Access to the Interface

The following MIBs control access to the basic and advanced trouble-shooting pages.

arrisCmDevHttpLanAccessValues: off, basic, adv, until-registered

Determines which pages are available from the Ethernet port of the NIU.

The value is stored in non-volatile memory.

arrisCmDevHttpWanAccessValues: off, basic, adv

Determines which pages are available from the network attached to the CMTS.

The value is stored in non-volatile memory.

arrisCmDevClientSeedChanging the seed changes the results of the Password of the Day (PWOD). See the Configuration Editor User’s Guide, ARSVD00635, for details about the PWOD. Store the seed value in the CM configuration file.



arrisCmDevHttpAdvLinkValues: Non-Restricted, Restricted

Determines whether the NIU shows a link to the advanced pages from the basic pages before the user enters the PWOD.

Non-Restricted shows links regardless of the password entered (default).

Restricted shows only the links that are accessible with the last password entered. Before entering the PWOD, the basic pages show no link to the advanced pages; the user must manually type in the URL address of an advanced page.

Action Perform the following tasks as necessary.

Task Page

Accessing the Standard Pages .................................... 8-36

Accessing the Advanced Pages................................... 8-37

Accessing the Standard Pages

Follow these steps to access the standard troubleshooting pages.

1 Make sure the NIU is configured to allow access to the pages (see “Controlling Access to the Interface” on page 8-35).

2 Obtain the cable modem IP address of the NIU.

Note: If the NIU has not registered, you can access the pages only from the Ethernet interface. After registration, you can use either the RF or Ethernet interfaces.

The Ethernet interface recognizes connections to the address 192.168.100.1, whether or not the modem has registered. To use this address, set your computer’s IP address to a similar address, such as 192.168.100.2.

3 Start your web browser and access the NIU. For example, you could use the address http://192.168.100.1/



Accessing the Advanced Pages

Follow these steps to access the advanced troubleshooting pages.

1 Perform steps 1 and 2 of “Accessing the Standard Pages” above.

2 Obtain the Password of the Day from the PWOD tool. See the Con-figuration Editor User’s Guide, ARSVD00635, for details about the PWOD tool.

3 Start your web browser and access the NIU, using the address http://192.168.100.1/status.htm (replace the IP address shown with the cable modem IP address if desired).

The NIU displays a web form that prompts you for the password.

4 Enter the Password of the Day in the web form and press Enter.

The NIU displays the Product Details Screen shown on page 8-30.



Running Line Card DiagnosticsUse this procedure to manually initiate line card diagnostics on a Touchstone Telephony NIU line.

Line card diagnostics check the following functionality:

• processor communication

• power/clock

• on-hook/off-hook functionality

• voice frequency

• ring

You start line card diagnostics by setting the ppSurvPortLcDiagRe-quest MIB that corresponds to the line to true. This MIB is found in the ppSurvPortTable, under the ARRIS-specific PACKETPORT-MIB.

The NIU generates either a Voice Line Diag Passed or Voice Line Diag Failed log message to indicate whether the diagnostic succeeded or failed.

You can query the ppSurvPortLcDiagLastResult MIB, also in the ppSurvPortTable, for the results of the last diagnostic run. The value is one of the following:

• diagnostics-passed(1)

• slac-revision-failure(2)

• mpi-failure(3)

• power-or-clock-failure(4)

• pcm-failure(5)

• standby-hook-failure(6)

• active-hook-failure(7)

• vf-failure(8)

• ringing-failure(9)

• invalid-state-to-init-diags(10)

• line-is-unprovisioned(11)

• diagnostics-results-pending(12)



Action Follow these steps to run line card diagnostics.

1 If the line that you want to test is in service, take the line out of ser-vice using the following steps:

a In the NMS, select the NIU to test and locate the ppCfgPortTa-ble for that device.

b Select the entry in the ppCfgPortTable that corresponds to the line that you want to disable, and set the ppCfgPortAdmin-State MIB to oos.

2 In the NMS, select the NIU to test and locate the ppSurvPortTable for that device.

3 Select the entry in the ppSurvPortTable that corresponds to the line that you want to test, and set the ppSurvPortLcDiagRequest MIB to true.

The NIU starts running diagnostics on the line.

While the NIU is running diagnostics, the ppSurvPortMaintState MIB for that line is set to either istrbl-diag(6) or oostrbl-diag(12).

4 Monitor the NMS fault management subsystem for a log message from, the NIU, indicating that diagnostics are finished.

5 Restore the line to service, if necessary, by setting the ppCfgPortAdminState MIB back to is.



HomePNA TroubleshootingUse this procedure to identify and correct problems with the HomePNA interface.

HomePNA Interface MIBs

You can use interface MIB counters to troubleshoot the HomePNA interface. These counters are described in detail in “Interface MIBs” on page 8-2. The following figure shows the location in the MIB tree for the Interface MIB and displays the counters available for HomePNA troubleshooting activities.



Using the Troubleshooting Interface

You can use the web-based troubleshooting interface to quickly deter-mine the IfAdminStatus. The following figure shows that the provi-sioning column depicts the administrative status and that the state column depicts the operational status. For more information on the Web-based Troubleshooting Interface, see “Web-based Troubleshoot-ing Interface” on page 8-28.



Verifying Connectivity

Most HomePNA devices have a link status light that indicates that the device is communicating properly and passing data. Connecting a device to the Touchstone Telephony Port should show activity and also set the operation status to up(1) (see “Managing the HomePNA Inter-face” on page 3-7). If the link status light does not show activity, follow these steps to perform initial troubleshooting.

1 Check the administrative status (IfAdminStatus) of the HomePNA interface, using a MIB browser or the web-based troubleshooting interface.

2 Verify that the interface has not been disabled through the CM con-figuration file.

3 Verify that the connected device supports (and is using) HomePNA 2.0 10M8. If the device is in a HomePNA 1.0-compatible mode (1M8), reconfigure the device to use 10M8.

4 Verify that device drivers are properly installed (if required).

5 Connect the device directly to another HomePNA station and pro-ceed as follows:

• If the link status lights do not show activity, replace the device.

• If the device indicates an active connection to the other Home-PNA device, then reconnect the first device to the Telephony Port. Disconnect other phones or fax machines from line 1, one at a time, to determine whether they are interfering with the HomePNA connection. Adding filters can sometimes correct problems with certain devices.


9 9 Appendix A:Example Files

The following is a list of example data and telephony provisioning file templates included with TS3.2. See the PacketACE Configuration Tools User’s Guide, ARSVD00635, for more information about using the templates.

Listing of TemplatesARRIS may update these templates when updating PacketACE or Touchstone software, so you should keep your own templates in a sepa-rate directory.

The following templates are provided (additional templates may be added in later releases).

Location of Template FIles

The PacketACE installer places template files in the directory C:\Program Files\ARRIS\PacketACE\ACE_Templates

MTA Configuration Files

The following is a list of example MTA configuration files included with PacketACE.

ARRIS_proprietary_mibs.mtaProvides default values for all ARRIS proprietary MIBs.

PCABLE_mandatory_params.mtaMandatory PacketCable parameters.

PCABLE_mandatory_params_2line.mtaMandatory PacketCable parameters for a Touchstone Telephony Modem.

PCABLE_mandatory_params_4line.mtaMandatory PacketCable parameters for a Touchstone Telephony Port.


9-2 Appendix A: Example Files

TS0302_2line.mtaBasic configuration for a Touchstone Telephony Modem using TS3.2.

TS0302_4line.mtaBasic configuration for a Touchstone Telephony Port using TS3.2.

Cable Modem Configuration Files

The following is a list of example MTA configuration files included with PacketACE.

DOCSIS10_mandatory_params.cmMandatory parameters for a DOCSIS 1.0 compatible cable modem.



TCM_CVC.cmCable modem configuration that uses a secure download.

TCM_http_basic_CVC.cmCable modem configuration that uses a secure download and enables the Touchstone cable modem troubleshooting interface.

TS0302_docsis10.cmBasic configuration for a Touchstone NIU, configured as a DOCSIS 1.0 cable modem, using TS3.2.


TS0302_docsis11_EUCVC.cmConfiguration for a Touchstone NIU, configured as a DOCSIS 1.1 cable modem, using TS3.2 with a secure download (Euro-pean load).

TS0302_docsis11_NACVC.cmConfiguration for a Touchstone NIU, configured as a DOCSIS 1.1 cable modem, using TS3.2 with a secure download (North American load).


Appendix A: Example Files 9-3

TS0302_docsis11_http_basic.cmBasic configuration for a Touchstone NIU, configured as a DOCSIS 1.1 cable modem, with the basic troubleshooting inter-face enabled.

TS0302_docsis11_http_off.cmBasic configuration for a Touchstone NIU, configured as a DOCSIS 1.1 cable modem, with the troubleshooting interface disabled.


_TS0302_CPS.cmTouchstone NIU configuration using the CPS provisioning mode.

_TS0302_DocsisOnly.cmTouchstone NIU configuration using the DOCSIS provisioning mode.

_TS0302_FullPcable.cmTouchstone NIU configuration using the Full PacketCable pro-visioning mode.

_TS0302_GUPI.cmTouchstone NIU configuration using the GUPI provisioning mode.

_TS0302_PcableMinusKDC.cmTouchstone NIU configuration using the PacketCable (no KDC) provisioning mode.

_TS0302_SingleMac_2line.cmTouchstone Telephony Modem configuration using the single MAC/single configuration file provisioning mode.

_TS0302_SingleMac_4line.cmTouchstone Telephony Port configuration using the single MAC/single configuration file provisioning mode.



Text Files The following is a list of text files in the ACE_Templates directory. You can import them into a configuration file to add specific features.

ARRIS_proprietary_mibs.txtA text version of the ARRIS_proprietary_mibs.mta file.

EUCVC.txtEuropean CVC.

NACVC.txtNorth American CVC.


Appendix A: Example Files 9-5

SNMP Co-existence Example Configuration FileThe following listing shows the MIBs and TLVs necessary to imple-ment SNMP co-existence. The configuration is based on a minimal DOCSIS 1.1 cable modem configuration file.

NetworkAccess = 1

UpstreamServiceFlow =

SfReference = 1

SfQosSetType = 7

SfSchedulingType = 2

DownstreamServiceFlow =

SfReference = 2

SfQosSetType = 7

PrivacyEnable = 0

SnmpMib = snmpCommunityName.comm1 "my_password"

SnmpMib = snmpCommunitySecurityName.comm1 "rwAccess"

SnmpMib = snmpCommunityStorageType.comm1 volatile

SnmpMib = snmpCommunityStatus.comm1 createAndGo

SnmpMib = vacmGroupName.1 rwAccess "rwAccess"

SnmpMib = vacmSecurityToGroupStorageType.1 rwAccess volatile

SnmpMib = vacmSecurityToGroupStatus.1 rwAccess createAndGo

SnmpMib = vacmGroupName.2 rwAccess "rwAccess"

SnmpMib = vacmSecurityToGroupStorageType.2 rwAccess volatile

SnmpMib = vacmSecurityToGroupStatus.2 rwAccess createAndGo

SnmpMib = vacmAccessContextMatch.rwAccess 1 1 exact

SnmpMib = vacmAccessReadViewName.rwAccess 1 1 "docsisManagerView"

SnmpMib = vacmAccessWriteViewName.rwAccess 1 1 "docsisManagerView"

SnmpMib = vacmAccessNotifyViewName.rwAccess 1 1 "docsisManagerView"

SnmpMib = vacmAccessStorageType.rwAccess 1 1 volatile

SnmpMib = vacmAccessStatus.rwAccess 1 1 createAndGo

SnmpMib = vacmAccessContextMatch.rwAccess 2 1 exact

SnmpMib = vacmAccessReadViewName.rwAccess 2 1 "docsisManagerView"

SnmpMib = vacmAccessWriteViewName.rwAccess 2 1 "docsisManagerView"

SnmpMib = vacmAccessNotifyViewName.rwAccess 2 1 "docsisManagerView"

SnmpMib = vacmAccessStorageType.rwAccess 2 1 volatile

SnmpMib = vacmAccessStatus.rwAccess 2 1 createAndGo

SNMPv3NotificationReceiver =

SNMPv3NrIpAddress = 10.1.50.100

SNMPv3NrTrapType = 1

SNMPv3NotificationReceiver =

SNMPv3NrIpAddress = 10.1.50.80

SNMPv3NrTrapType = 2




10 10 Appendix B:Configuring the Service

Provider RootPacketCable requires a Service Provider certificate hierarchy, which allows other network elements to authenticate the service provider's servers. The following figure shows the hierarchy.

The CableLabs Service Provider Root CA issues certificates only to authorized MSOs or Service Providers. This creates a problem for ven-dors or manufacturers who need to interoperate with the KDC and can-not obtain a Service Provider CA certificate under this root. One solution is to create a test root hierarchy and use it instead of the real root hierarchy for the purpose of lab testing. The MTA is manufactured with the CableLabs Service Provider Root certificate in order to verify and validate the certificates obtained in the AS_Reply message from the

Provider CA

Operator CA

DFCertificate

KDCCertificate

OtherCertificate

Root CAService Provider

CableLabs

Service

Local System


10-2 Appendix B: Configuring the Service Provider Root

KDC. In the case where the KDC is configured with a test root, the MTA must also be configured with the same test root.

Service Provider Root Provisioning for Touchstone Telephony Modems

Touchstone Software versions prior to TS3.2 embedded the IPFonix test root digital certificate. TS3.2 software embeds the official Packet-Cable test root digital certificate from CableLabs, Inc.

TS3.2 can support networks using the IPFonix test root digital certifi-cate or MSO-generated test root digital certificates by allowing any valid test root certificate to be downloaded from a specified TFTP loca-tion. Three MIBs (described in “MIBs” below) control this support.

The capability to download the certificates includes a retry mechanism to allow automatic recovery in the event of failure to download the cer-tificate from the server. This mechanism retries the download 16 times, then waits for a period of time before retrying the download. The cycle repeats three times, and then the Telephony Modem resyncs and starts the configuration process over again. During this process, the Tele-phony Modem generates download retry/failure logs, described in “Certificate Downloading Logs” on page 5-8.

CAUTIONService affectingIf the Telephony Modem is configured to use secure downloading, the Telephony Modem does not restart the provisioning cycle and thus does not provide service.

MIBs The CM configuration file transports the Service Provider Root MIBs to the Telephony Modem. Once the device has rebooted and down-loaded the CM configuration file, then the Telephony Modem uses its private MIBs to determine how to proceed.

There are three ARRIS private MIBs that can be set in the CM configu-ration file:

• ppCfgMtaDevSPTestRootCertAdminStatus—instructs the Telephony Modem to either use the embedded test root or download and use a test root certificate from a TFTP server

• ppCfgMtaDevSPTestRootCertServer—for the download option, this MIB specifies the IP address of the TFTP server containing the root certificate file


Appendix B: Configuring the Service Provider Root 10-3

• ppCfgMtaDevSPTestRootCertFilename—for the download option, this MIB specifies the file name on the TFTP server that contains the test root certificate

The ppCfgMtaDevSPTestRootDownloadState MIB displays the sta-tus of the download, if the download option is chosen.

Following is the definition of the MIBs:

ppCfgMtaDevServiceProviderTestRootCert OBJECT IDENTIFIER ::= { ppCfgMtaDevSecurity 1 }

ppCfgMtaDevSPTestRootCertServer OBJECT-TYPE

SYNTAX IpAddress

MAX-ACCESS read-write

STATUS current

DESCRIPTION

"The IP address of the TFTP server used for downloading Service

Provider Test Root Certificates to this device. Returns 0.0.0.0

if the TFTP server address is unknown or unassigned. This object

can only be changed by the configuration file."

::= { ppCfgMtaDevServiceProviderTestRootCert 1 }

ppCfgMtaDevSPTestRootCertFilename OBJECT-TYPE

SYNTAX DisplayString


STATUS current

DESCRIPTION

"The file name of the Service Provider Test Root Certificate to be

downloaded to this device from the TFTP server. Returns an empty

string if the certificate filename is unknown or unassigned. This

object can only be changed by the configuration file."


ppCfgMtaDevSPTestRootCertAdminStatus OBJECT-TYPE

SYNTAX INTEGER {

ignoreCertSettings(0),

useEmbeddedTestRootCert(1),

downloadTestRootCert(2)

}


STATUS current

DESCRIPTION

"Controls the usage of Root Certificates by the MTA device.

If set to downloadTestRootCert(2), the MTA will download the

Service Provider Test Root Certificate specified by

'ppCfgMtaDevSPTestRootCertFilename' from the TFTP server



specified by 'ppCfgMtaDevSPTestRootCertServer'. If set to

useEmbeddedTestRootCert(1), the MTA will use the factory-installed

Test Root Certificate embedded in the device. If the value of this

object is ignoreCertSettings(0), all of the Test Root Certificate

settings (i.e. TestRootCertServer, TestRootCertFilename) are ignored

and the MTA will, by default, use the factory-installed Real Root

Certificate embedded in the device. This object can only be changed

by the configuration file. At initial startup, this object has a

default value of ignoreCertSettings(0)."

DEFVAL { ignoreCertSettings }


ppCfgMtaDevSPTestRootDownloadState OBJECT-TYPE

SYNTAX INTEGER {

noDownload(0),

downloadRequested(1),

inProgress(2),

completed(3),

failed(4)

}

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"This object indicates the current state of the Service Provider Test

Root Certificate download process. noDownload(0) indicates that no

certificate download has been requested. downloadRequested(1) indicates

a Test Root Certificate download is desired, most likely as a result of

a downloadTestRootCert request. inProgress(2) indicates that a TFTP

download is underway. completed(3) indicates that the last Test Root

Certificate download was completed successfully. failed(4) indicates

that the last attempted download failed.

At initial startup, this object has a default value of noDownload(0)."

DEFVAL { noDownload }


Using the default embedded rootTo use the embedded real root, which is the default factory setting, either remove the ppCfgMtaDevSPTestRootCertAdminStatus from the CM configuration file, or set it to ignoreCertSettings.

Using the embedded test rootSelect the embedded test root by setting the ppCfgMta-DevSPTestRootCertAdminStatus to useEmbeddedTestRootCert. The ppCfgMtaDevSPTestRootCertFilename and ppCfgMta-DevSPTestRootCertServer MIBs are ignored.

Using the downloadable test root feature


Appendix B: Configuring the Service Provider Root 10-5

Download a test root to the MTA by setting the ppCfgMta-DevSPTestRootCertAdminStatus to downloadTestRootCert. Set ppCfgMtaDevSPTestRootCertServer to the IP address of the TFTP server and ppCfgMtaDevSPTestRootCertFilename to the file name. If the file name or the IP address of the TFTP server are missing or invalid, the download fails.

The certificate must use the X.509 DER-encoded format.




11 11 Appendix C:SNMP Access Modes

This appendix describes how to configure the NIU to control (restrict) SNMP access to the cable modem MIB objects by Network Manage-ment Stations (NMS) and also how to configure the transmission of notifications (traps) on the cable modem.

OverviewTouchstone NIUs support the following SNMP modes: SNMPv1, SNMPv2c, and SNMPv3 as well as SNMP-coexistence ([RFC 2567]).

The contents of the CM configuration file determines the NIU’s SNMP mode after registration:

• The CM runs in NmAccess mode if the CM configuration file contains only docsDevNmAccessTable settings. With these settings, SNMP access is controlled by the entries in the docs-DevNmAccessTable.

• The CM runs in SNMP coexistence mode if the CM configura-tion file contains any of the following:

— any snmpCommunityTable settings

— any TLV type 34.1 and 34.2 (SNMPv3 Kickstart User) elements

— any TLV type 38 (SNMPv3 Notification Receiver) elements

In SNMP coexistence mode, any configuration file entries made to the docsDevNmAccessTable are ignored.

• If the configuration file does not contain any SNMP access con-trol items (no docsDevNmAccessTable or snmpCommuni-tyTable settings and no TLV 34.1/34.2 or TLV 38 elements, then the CM runs in NmAccess mode and SNMP access to MIB objects is unrestricted.

The rules for each SNMP access mode are described below.


11-2 Appendix C: SNMP Access Modes

SNMPv1/v2c NmAccess Mode

The following rules apply in NmAccess mode:

• Only SNMPv1/v2c packets are processed.

• SNMPv3 packets are dropped.

• The docsDevNmAccessTable controls access and trap desti-nations as described in [RFC 2669].

• None of the SNMPv3 MIBs as defined in [RFC 2571] through [RFC 2576] are accessible.

SNMP Coexistence Mode

The following rules apply in SNMP Coexistence mode:

• SNMPv1/v2c/v3 Packets are processed as described by [RFC 2571] and [RFC 2576].

• The docsDevNmAccessTable is not accessible.

• Access control and trap destinations are determined by the snmpCommunityTable, Notification MIB, Target MIB, VACM-MIB, and USM-MIB.

• The Community MIB controls the translation of the SNMPv1/v2c packet community string into a security name that selects entries in the USM MIB. Access control is provided by the VACM MIB.

• The USM MIB and VACM MIB controls SNMPv3 packets.

• Trap destinations are specified in the Target MIB and Notifica-tion MIB.

SNMP Coexistence Types

There are three different types of SNMP coexistence that can be config-ured.

SNMPv1/v2c-only CoexistenceSNMPv1/v2c coexistence takes effect if the configuration file contains:

• Any TLV-11 Coexistence Settings (i.e. snmpCommunityMIB, vacmSecurityToGroupTable, vacmAccessTable) OR

• Any SNMPv3 Notification Receiver (TLV-38) elements and no SNMPv3 Kickstart (TLV-34) elements.

The cable modem only accepts SNMPv1/v2c packets in this mode.


Appendix C: SNMP Access Modes 11-3

SNMPv1/v2c/v3 CoexistenceSNMPv1/v2c/v3 coexistence takes effect if the configuration file con-tains all of the following:

• Any TLV-11 Coexistence Settings (i.e. snmpCommunityMIB, vacmSecurityToGroupTable, vacmAccessTable)

• any SNMPv3 Kickstart (TLV-34) elements

The cable modem accepts SNMPv1/v2c/v3 packets in this mode.

SNMPv3 only coexistenceSNMPv3 coexistence takes effect if the configuration file contains both:

• Any SNMPv3 Kickstart (TLV-34) elements

• NO coexistence settings

The cable modem only accepts SNMPv3 packets in this mode.

Configuring the Cable Modem for NmAccess ModeWhen the CM is in SNMPv1/v2c docsDevNmAccess mode, the docs-DevNmAccessTable controls SNMP access and SNMP trap destina-tions as described in the DOCS-CABLE-DEVICE-MIB [RFC 2669]. There are several different ways in which the table can be configured depending on what type of SNMP access and trap filtering you want to apply to the modem. This section describes a basic setup.

Configuring SNMP access with the docsDevNmAccessTable

The simplest way to configure the SNMP access filtering—where you just want to configure a user-defined community string for access—is to create one or more docsDevNmAccessTable entries within the cable modem configuration file (You can create up to a maximum of 32 NmAccess entries on Arris CM devices: CM300, CM450, TTM, TTP, etc.). A table row can be created by setting the docsDevNmAc-cessStatus object to a value of createAndGo(4) and the docsDevN-mAccessCommunity object to a user-defined community string, say for example, my_password. This creates an entry in the table with the following default parameters. This entry will allow read-only SNMP access to the CM from any NMS using a community string of my_password:

docsDevNmAccessIp.1 (ipaddress) = 255.255.255.255

docsDevNmAccessIpMask.1 (ipaddress) = 0.0.0.0

docsDevNmAccessCommunity.1 (octet string) = my_password /* Your password, use whatever string you like. */



docsDevNmAccessControl.1 (integer) = read(2) /* Allow read-only access */

docsDevNmAccessInterfaces.1 (octet string) = FF (hex) /* Allow access from all interfaces of the cable modem */

docsDevNmAccessStatus.1 (integer) = active(1) /* createAndGo(4) will automatically go to active(1) */

docsDevNmAccessTrapVersion.1 (integer) = DisableSNMPv2trap(1)

Note: The other objects of the table row entry are set to their default values unless you also add them to the configuration file.

The “.1” is the instance (or index) value of this particular table entry. It does not have to be a 1, it can be any number you choose. You can cre-ate as many different entries in the configuration file as you like (up to the maximum of 32), depending on how you want to setup the SNMP Access filtering.

The above description is a basic setup, but you can configure the NmAccess entry in additional ways. Just as an example, you can allow read and write access for the above entry by setting the docsDevN-mAccessControl object to readWrite(3) in the configuration file. You can also configure which of the modem’s interfaces you want to grant access to by changing the docsDevNmAccessInterfaces object accordingly (see below), etc. The section below describes how to setup trap transmission using the docsDevNmAccessTable.

Configuring Trap Transmission with the docsDevNmAccessTable

To enable trap transmission, three objects in the docsDevNmAc-cessTable MUST be configured to specific values. These three objects are: docsDevNmAccessIp, docsDevNmAccessIpMask, and docs-DevNmAccessControl. A fourth object, docsDevNmAccessTrap-Version can optionally be configured to enable or disable SNMPv2 traps. It the TrapVersion object is not configured then its value will just default to DisableSNMPv2trap(1) and SNMPv1 traps will be sent for that particular row entry.

Note: DisableSNMPv2trap(1) may show up as version(1) in the Configuration Editor.

For trap transmission, the relevant objects, highlighted in bold, MUST be configured as shown below:

docsDevNmAccessIp.15 (ipaddress) = (IP address of your Trap server)

docsDevNmAccessIpMask.15 (ipaddress) = 255.255.255.255

docsDevNmAccessCommunity.15 (octet string) = (any community string) /* Default community string */

docsDevNmAccessControl.15 (integer) = roWithTraps(4) or rwWithTraps(5) /* Allow traps to be sent */

docsDevNmAccessInterfaces.15 (octet string) = FF (hex) /* Allow access from all interfaces of the cable modem */

docsDevNmAccessStatus.15 (integer) = createAndGo(4)



docsDevNmAccessTrapVersion.15 (integer) = DisableSNMPv2trap(1) or EnableSNMPv2trap(2)

You can configure multiple NmAccess entries for trap transmission if, for example, you have several different trap servers that you want your modem to send traps to.

Rules for the docsDevNmAccessTable

Below is a brief overview of each of the MIB objects that comprise a row entry in the docsDevNmAccessTable.

docsDevNmAccessIp and docsDevNmAccessIpMaskIf the docsDevNmAccessTable is used for SNMP access filtering, the following rules are applied in order to determine whether to permit SNMP access from a given source IP address (SrcIpAddr):

1 If (docsDevNmAccessIp == 255.255.255.255), the CM permits SNMP access from any SrcIpAddr.

2 If (docsDevNmAccessIpMask == 0.0.0.0), the CM permits SNMP access from any SrcIpAddr.

3 If ((docsDevNmAccessIp AND docsDevNmAccessIpMask) == (SrcIpAddr AND docsDevNmAccessIpMask)), the CM permits SNMP access from SrcIpAddr.

4 If neither #1 nor #2 is applied, the CM denies SNMP access from SrcIpAddr.

The CM’s default value of the docsDevNmAccessIpMask is set to 0.0.0.0.

The following table contains sample MIB values and the access granted.

docsDevNmAccessCommunity• If this object is set to a zero-length string, then any community

string will match.

docsDevNmAccessIp docsDevNmAccess-IpMask

Access

255.255.255.255 Any IP address mask Any NMS

Any IP address 0.0.0.0 Any NMS

Any IP address except 255.255.255.255

255.255.255.255 Single NMS

0.0.0.0 255.255.255.255 No NMS

IP address of IP subnet Netmask of the subnet A subnet group of NMS



• The value of this object will not show up in MIB walks of the docsDevNmAccessTable.

Default value: “public”

Note: When read, this object returns a zero-length string, no matter what value it contains.

docsDevNmAccessControlValue list:

• none(1)—destroys this table row entry

• read(2)—default

• readWrite(3)

• roWithTraps(4)

• rwWithTraps(5)

• trapsOnly(6)

Default value: read(2).

• Setting the value of this object to none(1) will cause the table row entry to be destroyed.

• An SNMP Walk on the docsDevNmAccessTable requires Read-Write access to succeed. Therefore, if this value is set to read(2) or roWithTraps(4), then the docsDevNmAccessTable is not accessible using the community string that is associated with this docsDevNmAccessControl entry.

• In order for traps to be enabled for the associated row entry, this object must have a value of roWithTraps(4), rwWithTraps(5), or trapsOnly(6).

docsDevNmAccessInterfacesThis object specifies the set of interfaces from which requests from this NMS will be accepted. Each octet within the value of this object speci-fies a set of eight interfaces, with the first octet specifying interfaces 1 through 8, the second octet specifying interfaces 9 through 16, etc. Within each octet, the most significant bit represents the lowest num-bered interface, and the least significant bit represents the highest num-bered interface. Thus, each interface is represented by a single bit within the value of this object. If that bit has a value of 1 then that inter-face is included in the set.

Default value: 0xFF



Note that entries in this table apply only to link-layer interfaces (e.g., Ethernet and CATV MAC). Upstream and downstream channel inter-faces must not be specified.

In the CM, the interfaces are numbered as follows:

Here is how the bitmask looks for the docsDevNmAccessInterfaces object:

Following are examples of typical settings for the docsDevNm-AccessInterfaces object:

docsDevNmAccessStatusIf this object is configured in the CM’s configuration file, then it should have a value of createAndGo(4) or createAndWait(5). If set to createAndGo(4) in the configuration file, the value of this object auto-matically changes to active(1) upon successful creation of the row entry and the row entry becomes active. If set to createAndWait(5) in

Interface Type

1 Primary CPE Interface (Ethernet Interface)

2 CATV-MAC (RF Interface)

3 RF Upstream

4 RF Downstream

5 Secondary CPE Interface (USB Interface)

5+n Other Interfaces

27 26 25 24 23 22 21 20

Ethernet RF RF U/S RF D/S USB - - -

Value (hex) Description

Most common settings

FF Apply to all interfaces (Default value)

C0 Ethernet Interface + RF Interface

80 Ethernet Interface only

40 RF Interface only

Other settings

08 USB Interface only

48 RF + USB

88 Ethernet + USB

C8 Ethernet + RF + USB



the configuration file, the value of this object automatically changes to notInService(2) and the associated row entry becomes inactive.

docsDevNmAccessTrapVersionThis object specifies the trap version.

• version1(1)—send SNMPv1 traps (default)

• version2(2)—send SNMPv2 traps

Note that the values for this object may show up as DisableSNMPv2trap(1) for version1(1) and EnableSNMPv2trap(2) for version2(2).

Configuring the CM for Coexistence ModeWhen the CM is in coexistence mode, SNMP access and SNMP trap destinations are processed within the context of the SNMPv3 protocol architecture as defined in the SNMPv3 MIBs [RFC 2571] through [RFC 2576].

Any one of the three coexistence modes (v1/v2c only, v1/v2/v3, or v3 only) can be configured by using various combinations of the following elements in the configuration file:

• TLV-11 MIB settings to the snmpCommunityMIB, vacmSecuri-tyToGroupTable, and vacmAccessTable

• SNMP Notification Receiver element (TLV-38)

• SNMP Kickstart User element (TLV-34)

The particular coexistence mode is determined as described in “Over-view” on page 11-1.

Configuring SNMPv1/v2c only coexistence

Configuring the modem in SNMPv1/v2c only coexistence mode allows you to use a simple community string within the context of SNMPv3 USM security to access the CM’s MIBs. This mode of coexistence makes use of the snmpCommunityTable, which is defined in the snmp-CommunityMIB.

The snmpCommunityTable contains objects that allow you to map a community string into the following SNMPv3 message parameters:

• securityName

• contextEngineID

• contextName



The snmpCommunityTable, in combination with the vacmSecurityTo-GroupTable, and the vacmAccessTable, permits coexistence.

The coexistence settings can be configured in numerous different ways. For detailed information of their operation, refer to the SNMPv3 MIB RFCs [RFC 2571] through [RFC 2576].

Following is a basic coexistence example that configures two SNMPv1/v2c community strings, which will map to the DOCSIS-defined SNMPv3 security user: docsisManager. The snmpCommunityTable is configured with the following community strings: 1) a read/write com-munity string, which will provide full read-write access to the entire MIB tree and 2) a read-only community string, which will provide read-only access to the MIB tree.

How it WorksWhen an SNMPv1 (or SNMPv2c) Request (GET or SET) is received by the modem, each row within the snmpCommunityTable will be looked at until a matching row is found or all the rows have been searched. If no matching rows are found, then the request will result in an authorization failure and the SNMP Request will be rejected.

In order for a row to match, the snmpCommunityName must first match the community name contained within the SNMP Request mes-sage.

snmpCommunityTable, Indexed by snmpCommunityIndex

Table Index rw ro

snmpCommunityIndex (I) rw ro

snmpCommunityName readwrite readonly

snmpCommunitySecuri-tyName

rwAccess roAccess

snmpCommunityContext-EngineID

local snmpEngineID local snmpEngineID

snmpCommunityContext-Name

(zero-length) (zero-length)

snmpCommunityTransportTag (zero-length) (zero-length)

snmpCommunityStorageType volatile(2) volatile(2)

snmpCommunityStatus createAndGo(4) createAndGo(4)

(I) indicates this object is an index value.

Italics indicates that this value is the Default value of the MIB object.



If the community name matches a row in snmpCommunityTable, then the snmpCommunitySecurityName for that row is next compared against the vacmSecurityName entries in the vacmSecurityToGroupT-able.

If an entry is found with a vacmSecurityName that matches the snmp-CommunitySecurityName, then the corresponding group name (vacm-GroupName) for that row entry is used in the vacmAccessTable to determine if MIB access is allowed for that community string.

In order for SNMP GET-Requests to be allowed, the vacmAccessRead-ViewName must be valid.

In order for SNMP SET-Requests to be allowed, the vacmAccessWrite-ViewName must be valid.

In order for SNMP Trap messages to be allowed, the vacmAccessNoti-fyViewName must be valid.

The “docsisManagerView” entry is a pre-configured default DOCSIS-defined MIB access view that allows full read, write, and notify access to the modem’s entire MIB tree.

vacmSecurityToGroupTable, Indexed by vacmSecurityModel, vacmSecurityName

Table Index 1.roAccess 1.rwAccess 2.roAccess 2.rwAccess

vacmSecurityModel (I) 1 (SNMPv1) 1 (SNMPv1) 2 (SNMPv2) 2 (SNMPv2)

vacmSecurityName (I) roAccess rwAccess roAccess rwAccess

vacmGroupName roAccess rwAccess roAccess rwAccess

vamSecurityToGroupStorage-Type

volatile(2) volatile(2) volatile(2) volatile(2)

vamSecurityToGroupStatus createAndGo(4) createAndGo(4) createAndGo(4) createAndGo(4)



vacmAccessTable, Indexed by vacmGroupName, vacmAccessContextPrefix, vacmAccessSecurityModel, vacmAccessSecurityLevel

Table Index roAccess.[].1.1 roAccess.[].2.1 rwAccess.[].1.1 rwAccess.[].2.1

vacmAccessContextPrefix (I) “” * “” “” “”

vacmAccessSecurityModel (I) 1 (SNMPv1) 1 (SNMPv1) 2 (SNMPv2) 2 (SNMPv2)

vacmAccessSecurityLevel (I) 1 (noAuthnoPriv)

1 (noAuthnoPriv)

1 (noAuthnoPriv)

1 (noAuthnoPriv)

vacmAccessContextMatch exact(1) exact(1) exact(1) exact(1)

vacmAccessReadViewName docsisManager-View

docsisManager-View

docsisManager-View

docsisManager-View



Configuring SNMPv1/v2c/v3 coexistence

The configuration of SNMPv1/v2c/v3 coexistence is the same as v1/v2c only coexistence above, but with the addition of the TLV 34 (SNMP Kickstart User) element in the configuration file.

The SNMP Kickstart User element is added to the configuration file in order to “kickstart” SNMPv3 initialization and Diffie-Helman Key Change calculations. A description of the TLV 34 element follows.

SnmpV3 Kickstart ValueThe following TLV and its sub-elements are placed in the modem’s configuration file to kickstart SNMPv3 access to the modem.

Up to 5 of these objects may be included in the configuration file. Each results in an additional row being added to the usmDHKickstartTable and the usmUserTable and results in an agent public number being gen-erated for those rows.

SnmpV3 Kickstart Security Name

Normally, this will be specified as one of the DOCSIS built-in USM users, e.g., “docsisManager,” “docsisOperator,” “docsisMonitor,” “doc-sisUser.”

vacmAccessWriteViewName “” “” docsisManager-View

docsisManager-View

vacmAccessNotifyViewName docsisManager-View

docsisManager-View

docsisManager-View

docsisManager-View

vacmAccessStorageType volatile(2) volatile(2) volatile(2) volatile(2)

vacmAccessStatus createAndGo(4) createAndGo(4) createAndGo(4) createAndGo(4)


“” indicates a (zero-length) string


vacmAccessTable, Indexed by vacmGroupName, vacmAccessContextPrefix, vacmAccessSecurityModel, vacmAccessSecurityLevel

Table Index roAccess.[].1.1 roAccess.[].2.1 rwAccess.[].1.1 rwAccess.[].2.1

Type Length Value

34 n Composite

Type Length Value

34.1 2 to 16 UTF8 Encoded security name



This object is reported in the usmDHKickStartTable as usmDHKick-StartSecurityName and in the usmUserTable as usmUserName and usmUserSecurityName.

SnmpV3 Kickstart Manager Public Number

This number is the Diffie-Helman public number derived from a pri-vately (by the NMS or operator) generated random number and trans-formed according to [RFC-2786]. This is reported in the usmDHKickStartTable as usmKickstartMgrPublic. When combined with the object reported in the same row as usmKickstartMyPublic, it can be used to derive the keys in the related row in the usmUserTable.

Example: Adding a TLV-34 element in PacketACE

Type Length Value

34.2 n Manager’s Diffie-Helman public number expressed as an octet string.





Configuring SNMPv3 only coexistence

To configure SNMPv3 only coexistence, enter the TLV 34 (SNMP Kickstart User) element in the configuration file and NO Coexistence MIB settings in the configuration file.

Configuring Trap Transmission within Coexistence Mode

There are two ways to configure traps for coexistence mode:

• Through the configuration file

• Through SNMP

The simplest way to configure traps is to add the SNMPv3 Notification Receiver element to the CM configuration file. Below is a description of this element:

SNMPv3 Notification Receiver config file element (TLV-38)The SNMPv3 Notification Receiver TLV is used to easily configure SNMPv3 tables for notification (i.e. trap) transmission. The TLV speci-fies a Network Management Station (NMS) that will receive notifica-tions (traps) from the modem when the modem is in Coexistence mode.

Up to 10 of the TLV-38 elements may be included in the configuration file.



Note: The CM will process this TLV only if the CM is in Coexist-ence mode.

Note: If using the TLV-38 element in the configuration file, the only two sub-TLVs that MUST be present are 38.1 (IP Address) and 38.3 (Trap Type). All of the other sub-TLVs will be configured to their default values if they are not present.

SNMPv3 Notification Receiver IP AddressThis sub-TLV specifies the IP address of the notification receiver.

SNMPv3 Notification Receiver UDP Port NumberThis sub-TLV specifies the UDP port number of the notification receiver. If this sub-TLV is not present, the default value of 162 should be used.

SNMPv3 Notification Receiver Trap Type

This sub-TLV specifies the type of trap to send. The trap type may take the following values:

1 SNMP v1 trap in an SNMP v1 packet

2 SNMP v2c trap in an SNMP v2c packet

3 SNMP inform in an SNMP v2c packet

4 SNMP v2c trap in an SNMP v3 packet

5 SNMP inform in an SNMP v3 packet

Type Length Value

38 n composite

Type Length Value

38.1 4 ip1,ip2,ip3,ip4

Type Length Value

38.2 2 UDP port number

Type Length Value

38.3 2 trap value



SNMPv3 Notification Receiver TimeoutThis sub-TLV specifies the timeout value to use when sending an Inform message to the notification receiver.

SNMPv3 Notification Receiver RetriesThis sub-TLV specifies the number of times to retry sending an Inform message if an acknowledgement is not received.

SNMPv3 Notification Receiver Filtering ParametersThis sub-TLV specifies the Object Identifier of the snmpTrapOID value that identifies the notifications to be sent to the notification receiver. SNMP V3 allows the specification of which Trap OIDs are to be sent to a trap receiver. This object specifies the OID of the root of a trap filter sub-tree. All Traps with a Trap OID contained in this trap filter sub-tree will be sent to the trap receiver.

SNMPv3 Notification Receiver Security NameThis sub-TLV specifies the V3 Security Name to use when sending a V3 Notification. This sub-TLV is only used if the Trap Type is set to 4 or 5. This name must be a name specified in a configuration file TLV Type 34 as part of the DH Kickstart procedure. The notifications will be sent using the Authentication and Privacy Keys calculated by the modem during the DH Kickstart procedure. This sub-TLV is not required for Trap Type = 1, 2, or 3. If it is not supplied for a Trap type of 4 or 5, then the V3 Notification will be sent in the noAuthNoPriv security level using the security name “@config”.

Based on the contents of the TLV, the CM will create entries in the fol-lowing tables in order to setup the desired trap transmission: snmpNoti-fyTable, snmpCommunityTable, usmUserTable, vacmSecurityToGroupTable, vacmAccessTable, and vacm-ViewTreeFamilyTable.

Type Length Value

38.4 2 time in milliseconds

Type Length Value

38.5 2 number of retries

Type Length Value

38.6 n filter OID

Type Length Value

38.7 n security name



Example ConfigurationFollowing is an example configuration of three TLV-38 Notification elements.

Note 1: Note: The TrapOID for DOCSIS events is: 1.3.6.1.2.1.69.2.1.2.0 ( = docsDevCmTraps)

Note 2: The TrapOID for PacketCable/Arris-proprietary MTA events is: 1.3.6.1.4.1.4491.2.2.3.6.0.2 ( = pktcDevEvTrap)

// Send DOCSIS events to IP Addr: 192.168.78.99 as SNMPv2 traps

IP Address (38.1) = 192.168.78.99

Trap Type (TLV 38.2) = 2

Filtering Parameters (TLV 38.6) = 1.3.6.1.2.1.69.2.1.2.0

// Send PacketCable and Arris-proprietary MTA events to IP Addr: 192.168.78.100

//as SNMPv1 traps

IP Address (TLV 38.1) = 192.168.78.100


Filtering Parameters (TLV 38.6) = 1.3.6.1.4.1.4491.2.2.3.6.0.2

// Send PacketCable and Arris-proprietary MTA events to IP Addr: 192.168.78.150

//as SNMPv2 traps

IP Address (TLV 38.1) = 192.168.78.150


Filtering Parameters (TLV 38.6) = 1.3.6.1.4.1.4491.2.2.3.6.0.2

XXX TODO: ADD PacketACE example/screenshots here after Packet-ACE bugs are fixed XXX

Example: Adding a TLV-38 element in PacketACE








12 12 Appendix D:Configuring SNMP

CoexistenceTS3.2 software uses several SNMPv3 security-related features. SNMP Co-existence is a feature that allows SNMPv1 and SNMPv2c network management systems to function within the context of SNMPv3 secu-rity and view-based MIB access. The NMS can use an SNMPv1 or SNMPv2 community string to access the NIU’s MIBs or to receive traps.

The procedures in this chapter provide details on adding the necessary MIBs and TLVs to a cable modem configuration file. See “SNMP Co-existence Example Configuration File” on page 9-5 for a listing of the completed configuration file.

OverviewThe procedures in this appendix use the ARRIS PacketACE Configura-tion Editor to create the configuration file, covering only the details needed to add the desired functionality. See the PacketACE Configura-tion Tools User’s Guide, ARSVD00635, for more information about using PacketACE.

Configuration File Notes

Keep the following notes in mind when creating or editing configura-tion files.

• A MIB object whose type is “StorageType” must always have a value of volatile.

• A MIB object whose type is “RowStatus” should have a value of createAndGo. The NIU automatically changes its value to active after successfully adding the row.


12-2 Appendix D: Configuring SNMP Coexistence

SNMP Access Mode

The following examples configure SNMP access to the NIU for SNMPv1v2c coexistence mode. This allows an NMS (i.e. a MIB Browser) to access the NIU's MIBs with a simple community string using either SNMPv1 or SNMPv2.

The SNMP requests GET, GET-NEXT, and SET are all supported. The examples use the community name my_password.

SNMP Trap Trans-mission

SNMP trap transmission uses the DOCSIS TLV-38 (SNMPv3 Notifica-tion Receiver) configuration file element.

The example configures two trap destinations, each with a different IP address. One destination supports SNMPv1 traps and the other destina-tion supports SNMPv2 traps. The parameters for each trap destination are:

• Trap destination #1:

— IP Address: 10.1.50.100

— Trap Type: SNMPv1

• Trap destination #2:

— IP Address: 10.1.50.80

— Trap Type: SNMPv2

Note: When you create your own specific configuration file, you need to change the trap IP address to the IP address of your specific trap server.


Appendix D: Configuring SNMP Coexistence 12-3

Configuring SNMP Co-existenceTo configure the NIU for coexistence mode, you must create row entries in the following MIB tables:

• snmpCommunityTable—one row entry, to map the commu-nity string to an SNMPv3 security name.

• vacmSecurityToGroupTable—two row entries, containing group name information. One entry supports SNMPv1 access and the other entry supports SNMPv2 access.

• vacmAccessTable—two row entries, which map the commu-nity name, security name, and group name information to an SNMPv3 security name. The DOCSIS-standard default security name for cable modems is docsisManager. One entry supports SNMPv1 access and the other entry supports SNMPv2 access.

In this example, we start with a basic DOCSIS 1.1 CM configuration file, containing enough information to allow a cable modem to range and register, and then add the coexistence MIB elements to it. If you have a CM configuration file that you are already using, you can start with that file and add the coexistence elements to it. The following fig-ure shows the contents of a basic DOCSIS 1.1 configuration file that we have opened in PacketACE.

snmpCommunity-Table Parameters

The following table shows the example row to add to the snmpCommu-nityTable. The index for this table is an octet string; the example uses the string comm1 as the index value. You can use a different string if you desire. Italicized values in the table are default values that are cre-ated automatically.

Note: Avoid adding table index objects to the configuration file; the software fills in the index object using the index value supplied with the object name (.comm1 in this example).

The order in which you add objects is not important.

Object Name Value

snmpCommunityName.comm1 my_password

snmpCommunitySecurityName.comm1 rwAccess

snmpCommunityContextEngineID.comm1 local snmpEngineID

snmpCommunityContextName.comm1 (zero-length)

snmpCommunityTransportTag.comm1 (zero-length)

snmpCommunityStorageType.comm1 volatile(2)

snmpCommunityStatus.comm1 createAndGo(4)



vacmSecurityTo-GroupTable Parameters

The following table shows the example row to add to the vacmSecurity-ToGroupTable. This table has an index consisting of two objects:

• vacmSecurityModel—corresponds to the SNMP version in use; in this example; it takes the values 1 and 2 to allow support for both SNMPv1 and SNMPv2 requests.

• vacmSecurityName—corresponds to the snmpCommunitySe-curityName object in the snmpCommunityTable (rwAccess in this example).

vacmAccessTable Parameters

The following table shows the example row to add to the vacmAc-cessTable. This table has an index consisting of four objects:

• vacmGroupName—corresponds to the vacmGroupName object in the vacmSecurityToGroupTable (rwAccess in our example).

• vacmAccessContentPrefix—an octet string; in this example we use an empty (zero length) string. This is shown as “” in the table below.

• vacmAccessSecurityModel—corresponds to the SNMP ver-sion in use; in this example; it takes the values 1 and 2 to allow support for both SNMPv1 and SNMPv2 requests.

• vacmAccessSecurityLevel—for SNMP coexistence, use a value of 1 (noAuthnoPriv). This means that the NIU has no con-figured SNMPv3 USM security users/keys.

Object Name Value (row 1) Value (row 2)

vacmSecurityModel (row index 1) 1 (SNMPv1) 2 (SNMPv2)

vacmSecurityName (row index 2) rwAccess rwAccess

vacmGroupName rwAccess rwAccess

vamSecurityToGroupStorageType volatile(2) volatile(2)

vamSecurityToGroupStatus createAndGo(4) createAndGo(4)


GroupName (row index 1) rwAccess rwAccess

ContentPrefix (row index 2) “” “”

SecurityModel (row index 3) 1 (SNMPv1) 2 (SNMPv2)

SecurityLevel (row index 4) 1 (noAuthnoPriv) 1 (noAuthnoPriv)

vacmAccessContextMatch exact(1) exact(1)

vacmAccessReadViewName docsisManagerView docsisManagerView



Action Perform the following tasks in the order shown.

Task Page

Adding the snmpCommunityTable ............................... 12-5

Adding the vacmSecurityToGroupTable ....................... 12-8

Adding the vacmAccessTable ...................................... 12-11

Adding the snmp-CommunityTable

Follow these steps to add coexistence MIB objects to a CM configura-tion file using PacketACE.

1 Click the “Add SNMP MIB” icon ( ) or select Edit menu ->

Add SNMP MIB.

The Available MIBs tree appears.

2 Locate the snmpCommunityTable MIB. If you are not sure where the MIB is located in the tree, enter the name of the MIB in the upper field along the right side of the PacketACE window and then

vacmAccessWriteViewName docsisManagerView docsisManagerView

vacmAccessNotifyViewName docsisManagerView docsisManagerView

vacmAccesssStorageType volatile(2) volatile(2)

vacmAccessStatus createAndGo(4) createAndGo(4)




click Find MIB by Name. The following figure shows the snmp-CommunityTable MIB.

3 Double-click on one of the objects listed in the following table.

The Add SNMP MIB window appears:

Object Name Value

snmpCommunityName my_password

snmpCommunitySecurityName rwAccess

snmpCommunityStorageType volatile(2)

snmpCommunityStatus createAndGo(4)



4 Enter the index name (comm1) in the Index,DisplayString field, and the value from the table in step 3 in the Value field.

Some of the objects have a fixed set of values; this is indicated by the drop-down menu button at the end of the Value field. Click the menu button to display a list of allowed values, and choose the cor-rect value.

5 Repeat steps 3 and 4 until all values are filled in.

The configuration file should now look similar to the following:

The order of your MIB entries may be different than what is shown above.

6 Proceed to “Adding the vacmSecurityToGroupTable” on page 12-8.



Adding the vacm-SecurityToGroup-Table



Add SNMP MIB.


2 Locate the vacmSecurityToGroupTable MIB. If you are not sure where the MIB is located in the tree, enter the name of the MIB in the upper field along the right side of the PacketACE window and then click Find MIB by Name.





4 Enter the first index (1 or 2) in the Index1,Integer field, the second index (rwAccess) in the Index2,DisplayString field, and the value from the table in step 3 in the Value field.



vacmGroupName rwAccess rwAccess

vamSecurityToGroupStorageType volatile(2) volatile(2)

vamSecurityToGroupStatus createAndGo(4) createAndGo(4)




The configuration file should now be similar to the following:

Note: The order of your MIB entries may be different than what is shown above.

6 Proceed to “Adding the vacmAccessTable” on page 12-11.



Adding the vacm-AccessTable



Add SNMP MIB.


2 Locate the vacmAccessTable MIB. If you are not sure where the MIB is located in the tree, enter the name of the MIB in the upper field along the right side of the PacketACE window and then click Find MIB by Name.





4 Enter indexes as follows, and the value from the table in step 3 in the Value field.

• Index1,DisplayString—rwAccess (or the value of the vacm-GroupName object from the vacmSecurityToGroupTable)

• Index2,DisplayString—leave blank

• Index3,Integer—1 or 2, depending on the SNMP level row

• Index4,Integer—1 (noAuthnoPriv)



vacmAccessContextMatch exact(1) exact(1)

vacmAccessReadViewName docsisManagerView docsisManagerView

vacmAccessWriteViewName docsisManagerView docsisManagerView

vacmAccessNotifyViewName docsisManagerView docsisManagerView

vacmAccesssStorageType volatile(2) volatile(2)

vacmAccessStatus createAndGo(4) createAndGo(4)




The configuration file should now be similar to the following:

Note: The order of your MIB entries may be different than what is shown above.

6 Proceed to “Configuring Trap Servers” on page 12-14.



Configuring Trap ServersUse this procedure to configure trap destinations, using TLV-38 SNMPv3 Notification Receiver elements. The following procedure assumes that PacketACE is running and that you have already added the coexistence MIBs to the configuration file, but you can add the TLVs to the configuration file before adding the MIBs if you prefer.

Action 1 Click the “Add TLV parameter” icon ( ) or select Edit menu -> Add TLV.

The following window appears:

2 Select SNMPv3NotificationReceiver from the Type drop-down menu, then click the Add TLV button.

The SNMPv3NotificationReceiver element appears in the main PacketACE window.



3 In the main PacketACE window, select the SNMPv3NotificationReceiver element, then click the “Add TLV

sub-parameter” icon ( ) or select Edit menu -> Add Sub-TLV.

The following window appears:

4 Select SNMPv3NrIpAddress from the Sub-Type drop-down menu.

5 Enter the IP address of the trap server (10.1.50.100 in this example) in the Value box.

6 Click the Add TLV button.

PacketACE adds the Trap IP address sub-type to the SNMPv3NotificationReceiver element.

7 Repeat steps 4 through 6, adding the SNMPv3NrTrapType sub-parameter and specifying a value of 1: SNMP v1 trap in an SNMP v1 packet.



8 Repeat steps 1 through 7 to create a second SNMPv3Notification-Receiver element with an IP address of 10.1.50.80 and a trap type of 2: SNMP v2c trap in an SNMP v2c packet.

The configuration file should now resemble the following:

9 Save the configuration file and exit PacketACE.


13 13 Index

AAccess

SNMP 11-1troubleshooting interface 8-35

Advanced screens 8-30Alarms

Call Agent Loss of Communications 4-4configuring 3-11Pwr Supply Telemetry 4-4Voice Failure 4-6Voice Line Failure 4-5

BBattery, charging 8-1

CCall Agent Loss of Communications 4-4CallP feature switch 3-5, 8-33CallP/QoS Statistics screen 8-33CATV State Change 5-11Certificates

private MIBs 10-2Service Provider Root 10-2using default 10-4

Configuration File Settings screen 8-34Configuring alarms and log reporting 3-11Connection statistics 8-27CPS2000 3-2

DDetailed Status screen 8-30DHCP parameters screen 8-32Diagnostics, line card 8-38Disk contents 1-7DQoS 3-4Dynamic Quality of Service 3-4


13-2

EEMTA, see NIU.End of call connection statistics 8-27Event Log screen 8-29Event tables 3-12Event, see Alarms, Logs. 3-11

FFeature switch 3-5Functionality 1-4

GGenerating a list of passwords 6-3Generating a single password 6-2Global Universal Provisioning Interface 3-2GUPI 3-2

HHardware/Software Versions screen 8-29HomePNA 3-7

managing 3-7provisioning 3-7troubleshooting 8-40

IInstalling the software 2-1Interface, troubleshooting 8-35IP ports 3-5IP security 3-5IPSEC 3-5

KKDC, updating 3-15

LLine card, running diagnostics 8-38Logs, configuring 3-11

MManaging HomePNA 3-7MIBs

for root certificates 10-2reference 7-1supported 7-1

MTA Parameters screen 8-33MTA PROV Failed 5-14MTA PROV Successful 5-12, 5-14


13-3

MTA Root Certificate download Complete 5-9MTA Security Service Provider Certificate Chain Validation Failed 5-8MTA Test Root Certificate download failed 5-8, 5-9MTA TFTP

Config File Error 5-14Failed 5-14File Not Found 5-12No Channel 5-12Protocol Error

TFTP Close 5-13TFTP DB Access 5-13TFTP Init 5-12TFTP Open 5-12TFTP Read 5-13

NNIU 1-1NIU battery states 5-6NIU line states 5-5NIU states 5-5NmAccess mode 11-1

PPacketCable

event tables 3-12provisoning 3-1

Passwordgenerating list of 6-3generating single 6-2

Portssignalling 3-5, 8-22voice line 3-5

Power Supply Telemetry 5-11Protection 5-10Provisioning 3-1

HomePNA 3-7modes 3-1

DHCP parameters 3-3selecting 3-2

notes 3-4secure MTA and NCS 3-15

PWOD tool 6-1changing the seed 6-3generating passwords 6-3using 6-2

Pwr Supply Telemetry 4-4

QQuality of Service 3-4


13-4

RRegistration Status screen 8-30Running line card diagnostics 8-38

SScreen

CallP/QoS statistics 8-33configuration file settings 8-34detailed status 8-30DHCP parameters 8-32event log 8-29hardware/software versions 8-29MTA parameters 8-33registration status 8-30status, cable modem 8-28

Seed, changing 6-3Service Provider Certificates

private MIBs 10-2Root certificate 10-2

Signalling port 3-5, 8-22SNMP access modes 11-1

NmAccess 11-1SNMP coexistence mode 11-1

SNMP coexistence mode 11-1SNMP coexistence types 11-2Software

functionality 1-4installation 2-1upgrading 2-3, 2-4

State Change 5-11States

battery 5-6line 5-5NIU 5-5

Statistics, end of call 8-27Status monitoring 8-28Status screen 8-28

TTroubleshooting 8-1, 8-28

accessing advanced pages 8-37accessing standard pages 8-36accessing the interface 8-35controlling access 8-35HomePNA 8-40


13-5

UUpdating the KDC 3-15Upgrading the software

through provisioning 2-3through SNMP 2-4

Using the default root certificate 10-4Using the PWOD tool 6-2

VVoice Failure 4-6Voice Line Diag Failed 5-9Voice Line Diag Passed 5-10Voice Line Failure 4-5Voice Line Loop Current Change

to High 5-11to Normal 5-11

Voice line ports 3-5Voice Line Protection State Change 5-10Voice Line State Change 5-10


13-6


Touchstone TelephonySoftware Operator’s Guide (TS3.2)

2002, 2003 ARRISAll rights reserved

All information contained in this document is subject to change without notice. Arris Interactive reserves the right to make changes to equipment design or program components, as progress in engineering, manufacturing methods, or other circumstances may warrant.

ARRIS, ARRIS Interactive, and Touchstone are trademarks of ARRIS Licensing Company. Cornerstone is a registered trademark of ARRIS Licensing Company. All other trademarks are the property of their respective holders.

Document number: ARSVD00646Release 3.2 Standard 1.0September 2003

Documents

TM202B Software Guide