SNMP Migration to
Telecommunication Management Network

Raymond Raud, 1997


SNMP Systems in the Evolving Telecommunication Market

The Telecommunications Market includes Local Telephone Companies, Inter-exchange Carriers, Cable Companies, Internet Providers, nowadays even Power Companies and other communication service provides. In this Paper we limit the discussion to Telephone Companies and Inter-exchange carriers because they represent more than 90% of the telecommunications network deployment. Examples of these include:

Telecommunication carrier domain currently operates using a variety of management protocols from proprietary, ASCII to TL/1 and Q3. A gradual but increasing deployment of ITU-T TMN standard Q3 interfaces is the current trend. In the corporation communication domain (corporate LAN/WAN environment), the SNMP protocol is prevalent. Different operation philosophy and conditions in these domains explain the differences in the network management requirements implemented in the operation support systems for either domain. With the merger of computing and communication domains there is a need for common network operation with information from both domains.

The telecommunications market is a significant opportunity for SNMP managed network equipment vendors in addition to their traditional corporation market (eg. Fortune 500). This provides both new and expanding market opportunities for existing product lines. As such, a market entry strategy which offers a migration plan to TMN management systems while leveraging existing equipment is essential.

There are two possible strategies for entry into the Telecom space, "All or Nothing" and "Incremental Pay as You Play". Of course there are multiple variations of each of the two scenarios but each start from these underlying principals. The All or Nothing requires that the Network Element (NE) MIB is completely reflected in a TMN MIB, either in the NE itself or the Element Manager (EM). Often this requires a re-design of the NE or EM. The Incremental Pay as You Play strategy leverages the existing NE and EM capabilities and adds TMN Network Management capabilities as they are required by the Operation Support Systems where they are deployed. This paper recommends and justifies the incremental strategy.

The Pay as You Play Low Risk Market Entry

There is a low risk strategy for SNMP managed communication equipment to migrate into the telecommunication carrier networks. The strategy calls for incremental addition and modification of the existing SNMP management systems to enable data exchange with Operation Support Systems in carrier domain. The modifications are directly derived from the actual operation support needs, thus limiting the data exchange to only relevant data elements. This approach lowers the development and deployment risk and leverages the value of the existing network management software base.

This strategy can provide value added management functionality with a minimal investment. An example of the management of ATM services carried over an SDH backbone network with access provided by the xDSL technology explains how. The ATM Forum’s M4 Network View information model is used together with ADSL Forum’s draft information model for illustration. The same strategy is applicable to other cross-management domain scenarios as well.

 
 

The Existing ATM Service Network Operation

The ATM Service Network provides ATM connectivity over access subnetworks and one or many backbone subnetworks. The access subnetwork is carried over ADSL lines to the customer premises. The ATM virtual channel is switched at the subnetwork connection points and terminated in the ATM interface card of customer’s computer. There is an intra-office cable connecting the ATM switch in the central office to the atuC modem and atuR modem to the ATM interface card.

The ATM Service Network is Managed from a Network Operation Center that relies on the backbone SDH Management System for information on the carrier network. Both, ATM Service System and SDH Management System use a standard Q3 interface for inter-system communication. The ADSL access network is managed by a separate, SNMP based management system.
 

The Need to Support Cross Domain Operation Scenarios

The existing communications infrastructure (as described in the previous section) can be managed adequately within each domain. In isolation the management systems provide sufficient element and path connectivity management views to configure and trouble-shoot the equipment. This management does fall short when cross-domain information exchange and interactions are required, for example:

Example Interface Fault Isolation

In the case of failure at point "A"( Figure 1) the customer premises ATM equipment does not receive ATM cells. The ATM access port toward this customer does not show failure. Since it is on a transmit port the ATM Service Operation Center can not isolate the failure as an ATM switch problem, intra-office wiring problem, ADSL equipment problem or customer premises wiring problem without access to ADSL alarm state. Consequently, a best guess scenario holds when identifying the trouble and deploying service personnel.

Fault isolation in this example is simple when the ATM Service center has information from the SNMP Management system. Note, that only the alarm state of ADSL Path, ATM Edge Switch port and ATM Interface Card were necessary for the scenario. The ATM Service Management Center does not need to access to the layout, configuration parameters, state and type of other ADSL equipment, modems. To provide the capability desired by the operations process only a small portion of the management data is required to be passed across the domains. This incremental migration to Q3 Network Management required minimal effort but provide significant value to the management system.

Mapping Management Data

On the excerpts of ADSL Forum’s draft ADSL information model and excerpts of an SNMP MIB for ADSL equipment we’ll show the simple data mapping required to support interface fault isolation process for ATM Service Center.

The interesting managed object class from ADSL Forum’s draft information model is adslPathTTP that inherits its operational state attributes from ITU-T M.3100 trailTerminationPointBidirectional. Corresponding definitions are in the Appendix for your review. Mapping ADSLLineState into ADSLPathTTP state in both directions is achieved with a IF…THEN…ELSE statement:

If ADSLStatusTable[I].ADSLLineState = 1 Then

ADSLPathTTP.trailTerminationPointSource.OperationalState = enabled

Else ADSLPathTTP.trailTerminationPointSource.OperationalState = disabled

These data retrieval and mapping statements can be embedded in the TMN Agent code and executed on M_GET requests from the TMN Manager, triggered by Traps from the SNMP equipment on the change of the state or any other way appropriate for the situation. The TMN Agent’s access to the SNMP data could be through queries against relational database if the SNMP state data is kept in a database, or through direct GET requests to the SNMP equipment as appropriate for the implementation.

Proposed Pay as You Play Migration Strategy

The low risk incremental migration strategy builds on the operation processes established or evolving in today’s marketplace. The operation scenarios drive the list of required data elements from each management domain. This data is then modeled according to ITU Standards to create a TMN Agent. The TMN Agent operates like an application server providing all inter-domain communications. The local domain management system (for example, SNMP) shares local management data with the TMN Agent. This agent is deployed with the existing SNMP Manager. Local domain management is provided by the SNMP system, whereas, inter-domain data is provide by the TMN agent. When additional operation processes need support, the TMN model is updated, TMN Agent re-generated and re-deployed.

The resulting Operation Support System architecture can be pictorially represented as shown in Figure 2.

The Q3 information model can be always amended with new data elements as the operation support needs evolve. Each development cycle is an incremental step toward a full Q3 model required to support all services. Note, that depending on the network operation processes this model may never include a full element layer information model, except if required to manage new, Q3 compliant network equipment. Because the Network Agent is not changed during this transition, both Q3 and SNMP elements can be managed from the same Element Manager seamlessly.

Finally, if there is an operational need for the Element Management system to be Q3 compliant then the TMN Agent must implement full network element information model. The SNMP Based Management system would be in the role of a Q-Adapter (and potentially, communication concentrator). Management application algorithms of the SNMP Management system will be redundant, but they existed before. No additional development effort is required.

The tools required to implement this strategy efficiently would need to provide automatic generation of Q3 communication algorithms, and support multiple manager agent loops to enable model driven data aggregation between management layers. The tools should not impose restrictive process structures that may affect operation of SNMP based management systems.

New generation of network management system development tools supporting lightweight, flexible TMN architecture with significant automation are in works. On the frontier is OrbitTM from ISR Global Telecom that already supports above mentioned features.
 

Conclusion

SNMP based network management solutions are perfect for enterprise LAN markets. With the "Incremental, Pay as you Play" strategy one will ensure a low risk entry to rapidly expanding telecom markets. This approach gives all the benefits of a standard Q3 interface to SNMP based network elements without abandoning and re-writing existing network management solutions. On extreme cases and over a longer evolution the same completeness and functionality as with "All or Nothing" approach can be reached. The investment is spread out and better justified with actual market evolution.


©1997 Raymond Raud. All Rights Reserved.
Last Modified: February 27, 1997

Appendix

Details behind the example adaptation of the ADSL SNMP attributes into the draft TMN ADSL MIB.

adslPathTTP MANAGED OBJECT CLASS

DERIVED FROM "Recommendation M.3100 : 1992":trailTerminationPointBidirectional;

CHARACTERIZED BY

adslPathTTPPkg;

REGISTERED AS { adsl-forumObjectClass 2 };

trailTerminationPointBidirectional in turn encapsulates trailTerminationPointSource, trailTerminationPointSink enabling the upper management system access to both directions of ADSL communication.

trailTerminationPointBidirectional MANAGED OBJECT CLASS

DERIVED FROM trailTerminationPointSource, trailTerminationPointSink;

CHARACTERIZED BY

trailTerminationPointBidirectionalPackage PACKAGE

BEHAVIOUR

trailTerminationPointBidirectionalBehaviour BEHAVIOUR

DEFINED AS

"The operational state is disabled if either the sink or source part of the termination point is disabled."

;;;;

REGISTERED AS {m3100ObjectClass 9};

Both, trailTerminationPointSource and trailTerminationPointSink support operationalStatePackage among others (not of interest for this discussion).

trailTerminationPointSink MANAGED OBJECT CLASS

DERIVED FROM terminationPoint;

CHARACTERIZED BY

operationalStatePackage,

...

REGISTERED AS {m3100ObjectClass 10};

trailTerminationPointSource MANAGED OBJECT CLASS

DERIVED FROM terminationPoint;

CHARACTERIZED BY

operationalStatePackage,

...

REGISTERED AS {m3100ObjectClass 11};

operationalStatePackage supports operationalState attribute from ITU-T Recommendation X.721

operationalStatePackage PACKAGE

ATTRIBUTES

"Recommendation X.721: 1992":operationalState GET;

REGISTERED AS {m3100Package 19};

operationalState ATTRIBUTE

WITH ATTRIBUTE SYNTAX Attribute-ASN1Module.OperationalState;

MATCHES FOR EQUALITY ;

REGISTERED AS {smi2AttributeID 35};

The attribute syntax is defined in the corresponding ASN.1 module as:

OperationalState::= ENUMERATED { disabled(0), enabled(1) }

From SNMP side the ADSL line state is defined in the table:

ADSLStatusTable OBJECT-TYPE

SYNTAX SEQUENCE OF ADSLStatusEntry

ACCESS not-accessible

STATUS mandatory

DESCRIPTION

"The status table contains status information about an ADSL

line."

::= { ADSLStatus 1 }

ADSLStatusEntry OBJECT-TYPE

SYNTAX ADSLStatusEntry

ACCESS not-accessible

STATUS mandatory

DESCRIPTION

""

INDEX { ADSLStatusIndex }

::= { ADSLStatusTable 1 }

with entries defined as

ADSLStatusEntry ::=

SEQUENCE {

ADSLStatusIndex INTEGER,

ADSLLineState INTEGER,

ADSLUpstreamRate INTEGER,

ADSLDownstreamRate INTEGER,

ADSLAZFrameSync INTEGER,

ADSLZAFrameSync INTEGER,

ADSLAZMargin DBReading,

ADSLZAMargin DBReading,

ADSLAZLineAtten DBReading,

ADSLZALineAtten DBReading,

ADSLMaintainRate TrueFalse,

ADSLUpstreamPower DBReading,

ADSLDownstreamPower DBReading

}

ADSLLineState is an integer with only to valid values

ADSLLineState OBJECT-TYPE

SYNTAX INTEGER {

up(1),

down(2)

}

ACCESS read-only

STATUS mandatory

DESCRIPTION

"This object represents the current state of the ADSL line."

::= { ADSLStatusEntry 2 }


©1997 Raymond Raud. All Rights Reserved.
Last Modified: February 27, 1997