Internet Draft Ranjith Mukundan Sudarshan Naganathan Narsimuloo Mangalpally Vaidyanathan Anantharaman Nortel Networks Document: draft-ranjith-dpnss-mib-00.txt November 2000 Management Information Base for Digital Private Network Signaling System No 1(DPNSS 1) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects for SNMP-based management of DPNSS 1 interfaces. DPNSS 1 is a common-channel signaling system and is primarily intended for use between PBXs in private networks via time-slot 16 of 2.048 Mbit/s digital transmission system. Similarly it may be used in time-slot 24 of a 1.544 Mbit/s digital transmission system. The DPNSS 1 protocol is completely specified in British Telecom Network Requirement 188 (BTNR 188) series of specifications [10]. This document specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards. Conventions used in this document Mukundan/Naganathan/Mangalpally/Anantharaman 1 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 The DPNSS 1 signaling system will be referred to as just DPNSS in rest of the document. The DPNSS Signaling interface will be referred to as DPNSS Signaling Link or DPNSS Signaling Channel - or just DPNSS Link. These three are used interchangeably throughout this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents 1 The SNMPv2 Network Management Framework .................. 2 2 Object Definitions ....................................... 3 3 Overview .................................................. 3 3.1 Structure of the MIB .................................... 3 3.1.1 General Description ................................... 4 3.2 Relationship to the Interfaces MIB ...................... 5 3.2.1 Layering Model ........................................ 5 3.2.1.1 DPNSS Layer 2 and Layer 3 interface representation .. 5 3.2.1.2 DPNSS DLC representation ............................ 6 3.2.2 ifStackTable .......................................... 7 3.2.3 ifTestTable ........................................... 8 3.2.4 ifRcvAddressTable ..................................... 8 3.2.5 ifEntry ............................................... 8 3.2.5.1 ifEntry for a DPNSS Signaling Channel ............... 8 3.2.5.2 ifEntry for a DPNSS Trunk ........................... 9 3.3 Relationship to other MIBs .............................. 10 3.3.1 Relationship to the DS1/E1 MIB ........................ 10 3.3.2 Relationship to the DS0 and DS0Bundle MIBs ............ 11 3.4 dpnssTrkMappingTable usage/implementation Guidelines .... 11 4 Definitions ............................................... 12 5 Security Considerations.................................... 35 6 References ................................................ 36 7 Acknowledgements .......................................... 38 8 Authors' Address .......................................... 38 1. The SNMPv2 Network Management Framework The SNMP Management Framework presently consists of five major components: - An overall architecture, described in RFC 2271 [3]. - Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD16, RFC 1155 [4], STD 16, RFC 1212 [5] and RFC 1215 [6]. The second version, called SMIv2, is described in STD 58, RFC 2578 [7], RFC 2579 [8] and RFC 2580 [9]. - Message protocols for transferring management information. The Mukundan/Naganathan/Mangalpally/Anantharaman 2 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [10]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [11] and RFC 1906 [12]. The third version of the message protocol is called SNMPv3 and described in RFC 2272 [13] and RFC 2274 [14]. - Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [10]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [15]. - A set of fundamental applications described in RFC 2273 [20] and the view-based access control mechanism described in RFC 2275 [21]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine-readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine-readable information is not considered to change the semantics of the MIB. 2. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. 3. Overview 3.1. Structure of the MIB For managing DPNSS interfaces, the following information is necessary: o Information for managing interface related characteristics Mukundan/Naganathan/Mangalpally/Anantharaman 3 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 specified in IF-MIB [16]. o The IANAifType MIB [18] that contains a IANA assigned value for DPNSS. o Information for managing the physical T1 or E1 lines that is configured as a DPNSS interface specified in the DS1/E1 MIB [12]. In case of DPNSS, the E1/T1 line that is configured as DPNSS interface cannot be shared across other protocols. o Information for managing the DS0 interface that is configured as a DPNSS trunk or link as specified in the DS0 MIB [19]. o Information for managing DPNSS Trunks (Bearer Channels) as Specified by this MIB. o Information for managing DPNSS signaling Links as specified By this MIB. o Information for managing the 60 DPNSS Data Link Connections (DLCs) as specified by this MIB. The DPNSS MIB contains information to configure and manage a DPNSS interface (trunks/links) and does not cater to provisioning and management of any voice or data related DPNSS services like Call Back When Free (CBWF), Executive Intrusion (EI), Three Party Service (TPS) etc as specified in BTNR 188. These services, as describe by BTNR 188, though offered over a DPNSS interface is not interface specific (i.e., not necessarily provisionable on a per interface basis). Further, information related to the provisioning & management of these services are implementation/vendor specific. 3.1.1. General Description This MIB controls all aspects of DPNSS interfaces. The DPNSS specific information is organised into 4 tables in this MIB. o The dpnssSigTable is used to provide configuration and statistical information regarding DPNSS signaling link interfaces. o The dpnssTrkTable is used to provide configuration and statistical information regarding DPNSS trunk (bearer) interfaces. o The dpnssDLCTable is used to provide information regarding the DLCs for one DPNSS signaling Link interface. o The dpnssTrkMappingTable facilitates a faster means to Mukundan/Naganathan/Mangalpally/Anantharaman 4 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 correlate the DPNSS trunk interfaces with a specific DPNSS Signaling Link interface. This association can also be achieved through the ifstackTable and/or the dsx0ChanMappingTable defined in the DS0 MIB [19] but would require multiple table look-ups and testing of constituent entries in the tables involved. The usage of this table is illustrated in the subsequent sections. 3.2. Relationship to the Interfaces MIB This section clarifies the relationship of this MIB to the Interfaces MIB [16]. Several areas of correlation are addressed in the following subsections. The implementor is referred to the Interfaces MIB document in order to understand the general intent of these areas. 3.2.1. Layering Model A DPNSS interface consists of a signaling channel and a number of trunks (bearer channels) - 23 if the DS1 interface is a T1 and 30 if it is E1. The DPNSS signaling channel and the trunks are layered on top of a physical interface - a DS1 interface. 3.2.1.1. DPNSS Layer 2 and Layer 3 interface representation The DPNSS signaling channel interface is composed of a Data Link Layer DPNSS Layer 2) and the Network Layer (DPNSS Layer 3). From the perspective of this MIB, the DPNSS Layer 2 and DPNSS Layer 3 is modeled as a single logical interface (ifEntry) to represent the DPNSS signaling channel as a whole. The rationale for this approach is based on the guidelines proposed in the interfaces MIB [16] which recommends that a group of related interfaces be treated as a single interface with one entry in the ifTable. In case of DPNSS Layer 2 and DPNSS Layer 3: o Neither DPNSS Layer 2 nor DPNSS Layer 3 performs multiplexing for any other interface in the agent. o It is useful for all of the ifTable's information (e.g., the counters, and the status variables and all of the ifTable's capabilities (e.g., write access to ifAdminStatus), to apply to DPNSS Layer 2 and DPNSS Layer 3 as a whole. 3.2.1.2. DPNSS DLC representation The DPNSS DLC is a connection-oriented virtual connection realized by DPNSS data link layer (DPNSS Layer 2). A DLC can be considered as the Level 2 process that controls the transfer of Level 3 messages on behalf of on DPNSS signaling channel. A DPNSS Data Link Layer may contain up to 60 DLCs, i.e., it may support up to 30 Real channels and 30 Virtual Mukundan/Naganathan/Mangalpally/Anantharaman 5 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 Channels. A Real Channel is a communication (traffic) channel which can be used to convey voice or data. A Virtual Channel is an information channel, which has no physical realisation outside the signaling channel. In any case, each DLC, irrespective of whether it realizes a Real or Virtual Channel, is in itself a virtual connection. The interfaces MIB [16] strongly recommends that connection- oriented sub-layers do not have a conceptual row in the ifTable for each virtual circuit. This avoids the proliferation of conceptual row, especially those which have considerable redundant information. Hence, each of the 60 DPNSS DLC has a representation only in the dpnssDLCTable and does not find a corresponding ifEntry in the ifTable. The DPNSS Signaling Channel and bearer channel representation is accomplished in this MIB by creating a logical interface (ifEntry) for each of the signaling channel entities and a logical interface (ifEntry) for each of the DPNSS trunks. These are then correlated to each other and to the physical interface using the ifStackTable of the Interfaces MIB [19]. The basic model, therefore, looks something like this: DPNSS Layer 2 & 3 DPNSS TRUNKS .... +--+ +--+ +--+ +--+ +--+ +--+ | Sig | | (DS0) | | (DS0) | |Channel| | trunk | .... | trunk | +--+ +--+ +--+ +--+ +--+ +--+ | | | | | | <== attachment to physical +--+ +--------+ +------------+ +----+ interfaces, to be | physical interface | provided by ifStackTable | (T1/E1) | +-----------------------------------+ Mapping of DPNSS Trunks/Signaling channels to physical interfaces The ifType for the DPNSS Signaling Channel will be assigned by IANA as part of the IANAifType MIB. The ifType for DPNSS trunks is ds0(81). The ifType for physical interfaces is ds1(18). 3.2.2. ifStackTable The ifStackTable is used to map the DPNSS Signaling Links and trunks to physical interfaces (DS1). Since a ds0 interface is configured as a DPNSS signaling link or trunk, the ifStackTable is also used to map the ds0 interfaces to the Mukundan/Naganathan/Mangalpally/Anantharaman 6 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 physical interfaces. The assignment of index values could for example be as follows: ifIndex ifType DPNSS & DS0 MIB tables Description indexed by ifIndex -------------------------------------------------------------------- 1 dpnss(X) dpnssSigTable DPNSS Signaling Channel (X is the IANAIfType value for dpnss interfaces assigned by IANA) 2 ds0(81) dpnssTrkTable DPNSS Trunk #1 3 ds0(81) dpnssTrkTable DPNSS Trunk #2 4 ds0(81) dsx0ConfigTable ds0 interface entry #1 (see ds0 MIB) 5 ds0(81) dsx0ConfigTable ds0 interface entry #2 (see ds0 MIB) 6 ds0(81) dsx0ConfigTable ds0 interface entry #3 (see ds0 MIB) 7 ds1(18) ds1 interface entry The corresponding ifStack table entries would then be: ifStackTable Entries HigherLayer LowerLayer 0 1 0 2 0 3 0 4 0 5 0 6 1 7 2 7 3 7 4 7 5 7 6 7 7 0 3.2.3. ifTestTable The ifTestTable is not supported by this MIB. 3.2.4. ifRcvAddressTable The ifRcvAddressTable is not supported by this MIB. Mukundan/Naganathan/Mangalpally/Anantharaman 7 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 3.2.5. ifEntry 3.2.5.1. ifEntry for a DPNSS Signaling Channel The ifGeneralInformationGroup and ifCounterDiscontinuityGroup are supported. ifTable Comments ============== =========================================== ifIndex Each DPNSS Signaling Channel is represented by an ifEntry. ifDescr Textual port description of the DPNSS Signaling Channel interface. ifType The IANA value to be assigned by IANA ifSpeed The overall bandwidth of this interface. Since a DS0 interface channelized from a DS1 interface is configured as DPNSS Signaling Link, this value will be set to 64000 ifPhysAddress If configured a IA5 formatted end point ID is returned else return a NULL string. ifAdminStatus The administrative status of the DPNSS Signaling Channel Interface. ifOperStatus The current operational status of this interface. The operational status is dormant(5) if the interface is in standby mode, i.e., connected to the network, but without call activity. The operational status is down(2) if the hardware has detected that there is no layer 1 connection to the switch. For other values, refer to the Interfaces MIB. These values should be representative of the Status of DPNSS Layer 2 and Layer 3. Operational Status unique to the individual Layers will be catered to by the dpnssSigTable Entries. Relationship to the dpnssSigLinkOperStatus: - if the ifOperStatus is in dormant state, then the dpnssSigLinkOperStatus should be in idle state. - if the ifOperStatus is in down state, then the dpnssSigLinkStatus should be in one of: oos, resetAttempted lockout, inb or offline state. - if the ifOperStatus is in up state, then the dpnssSigLinkOperStatus should be in one of: Mukundan/Naganathan/Mangalpally/Anantharaman 8 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 resetComplete, infoTransfer, recvOverrun, babbling, crptMsg, overLoad or bsy state. ifLastChange Refer to the Interfaces MIB. ifLinkUpDownTrapEnable Refer to the Interfaces MIB. ifConnectorPresent Refer to the Interfaces MIB. ifHighSpeed Return zero. ifName This is set to a value representative of a DPNSS interface, example, 'dpnss'. 3.2.5.2. ifEntry for a DPNSS Trunk The ifGeneralInformationGroup and ifCounterDiscontinuityGroup is supported. ifTable Comments ============== =========================================== ifIndex Each DPNSS Trunk is represented by an ifEntry. ifDescr Textual port description of the DPNSS Trunk Interface. ifType The IANA value of ds0(81). ifSpeed The overall bandwidth of this interface. Since a DS0 interface channelized from a DS1 interface is configured as DPNSS Signaling Link, this value will be set to 64000. ifPhysAddress If configured a IA5 formatted end point ID returned else return a NULL string. ifAdminStatus The administrative status of this interface. ifOperStatus The current operational status of this interface. Note that dormant(5) is explicitly being used as defined in the Interfaces MIB. For other values, refer to the Interfaces MIB. Operational Status unique to the individual trunks will be catered to by the dpnssTrkTable Entries. Relationship to the dpnssTrkOperStatus: - if the ifOperStatus is in dormant state, then the dpnssTrkOperStatus should be in idle state. Mukundan/Naganathan/Mangalpally/Anantharaman 9 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 - if the ifOperStatus is in down state, then the dpnssTrkOperStatus should be in one of: lockout, inb or offline state. - if the ifOperStatus is in up state, then the dpnssTrkOperStatus should be in one of icSetupReq, ogSetupReq, icSetupComp, ogSetupComp, icSetupCompBuf, ogSetupCompBuf, icAns, ogAns, clearing or bsy state. ifLastChange Refer to the Interfaces MIB. ifLinkUpDownTrapEnable Refer to the Interfaces MIB. ifConnectorPresent Refer to the Interfaces MIB. ifHighSpeed Return zero. ifName This is set to a value representative of a DPNSS interface, example, 'dpnss'. Since a ds0 interface can be configured as bearer channel for any protocol, this value can be used to identity a ds0 interface as being configured as a DPNSS trunk. 3.3. Relationship to other MIBs 3.3.1. Relationship to the DS1/E1 MIB Implementation of the DS1/E1 MIB [12] is required for supporting this MIB. The MIB should conform to ds1MibE1PriCompliance for DPNSS interfaces implemented over E1 lines and should conform to ds1MibT1PriCompliance for DPNSS interfaces implemented over T1 lines. The ds1NearEndConfigGroup & ds1NearEndStatisticsGroup should be implemented. dsx1LineType set to dsx1E1CRC for E1 and dsx1ESF T1. dsx1LineCoding Type of zero code suppression is set to dsx1HDB3 for E1 and dsx1B8ZS for T1. dsx1SignalMode set to messageOriented. The DPNSS interfaces are always message oriented for both E1 & T1." dsx1TransmitClockSource Set to loopTiming. The transmit clock is derived from received clock on the DPNSS Interfaces." Mukundan/Naganathan/Mangalpally/Anantharaman 10 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 For details on the other members of the ds1NearEndConfigGroup & ds1NearEndStatisticsGroup refer to DS1 MIB. 3.3.2. Relationship to the DS0 and DS0Bundle MIBs The DPNSS Trunk and Link interfaces are all DS0 interfaces. Implementation of the DS0 MIB [13] is required for supporting this MIB. The ds0ConfigGroup should be implemented. dsx0Ds0ChannelNumber This object indicates the channel number of the ds0 on its DS1/E1. dsx0RobbedBitSignalling This object indicates if Robbed Bit Signaling is turned on or off for a given ds0. This only applies to DS0s on a DS1 link. For E1 links the value is always off (false). dsx0CircuitIdentifier This object contains the transmission vendor's circuit identifier, for the purpose of facilitating troubleshooting. For other members of the ds0ConfigGroup refer to the DS0 MIB. The use of dsx0ChanMappingTable is recommended as a DS1 interface is channelized to support the DS0 interfaces. DS0Bundle MIB is not required. 3.4 dpnssTrkMappingTable usage/implementation Guidelines An example is given here to explain the trunk mapping objects provided in the MIB to help the implementor use the objects correctly. Assume that a DPNSS signaling channel with ifIndex 1 is used to signal for 30 trunks (i.e., a E1). Since the DPNSS trunks will have an corresponding ifEntry in the ifTable, there will be 30 ifEntries in the if table for the DPNSS Trunks. The dpnssTrkMappingTable will have an entry for the DPNSS signaling channel. Hence, the entries will be as follows. ifIndex dpnssTrkNum dpnssTrkMappingIfIndex 1 1 2 1 2 3 ...... 1 30(24 if T1) 31(25 if T1). Where ifIndex is the ifIndex of the DPNSS signaling channel Mukundan/Naganathan/Mangalpally/Anantharaman 11 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 that can retrieved from the dpnssSigTable (i.e., the value of dpnssSigIfIndex), dpnssTrkNum is the DPNSS trunk number whose and dpnssTrkMappingIfIndex is the IfIndex of the DPNSS Trunk associated with this DPNSS signaling channel. This object also provides information that can be indirectly retrieved using the ifStackTable using the ds0 and ds1 ifEntries. Note that the ds0 MIB contains information to associate & map ds1 channelization for ds0 interfaces. 6. Definitions DPNSS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-TYPE, Counter32, Integer32, transmission FROM SNMPv2-SMI DisplayString, TimeStamp FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF ifIndex, InterfaceIndex FROM IF-MIB IANAifType FROM IANAifType-MIB; dpnssMib MODULE-IDENTITY LAST-UPDATED "200008090000Z" -- August 23, 2000 ORGANIZATION "IETF Interfaces Working Group" CONTACT-INFO " DPNSS MIB Team : Ranjith Mukundan Sudarshan Naganathan Narsimuloo Mangalpally Vaidyanathan Anantharaman DPNSS MIB Team email : mdragon@nortelnetworks.com Postal : Nortel Networks plc Concorde Road, Maidenhead, Berkshire SL6 4AG United Kingdom Phone : +44 (0)1628434388 " Mukundan/Naganathan/Mangalpally/Anantharaman 12 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 DESCRIPTION "The MIB module to describe the management of DPNSS interfaces." ::= { transmission 999 } -- IANA will be requested -- to assign a value -- The DPNSS hardware interface is represented -- by a media specific ifEntry. -- -- The media specifics are defined in the ds0 (81) -- MIB ds1(18) MIB. -- Each DPNSS signaling channel is represented by an entry -- in the dpnssSigTable. -- -- Each DPNSS trunk is also represented as an entry -- in the ifTable. The DPNSS trunks will have an ifType value -- of ds0(81). -- This model is used while defining objects and tables -- for management. -- -- The DPNSS Signaling channel is modeled as a single interface -- sublayer.Separate ifEntries for DPNSS Layer 2 and Layer 3 is -- not provided. -- -- The DPNSS DLC information is maintained in the dpnssDLCTable. -- Information relating to each of the 30 Real and 30 Virtual -- DLCs is maintained in this table. These Virtual Connections do -- not have ifEntries. -- The DPNSS Signaling Group consists of 2 tables -- DPNSS Signaling Table and -- DPNSS DLC Table -- The dpnssSigTable contains configuration and statistical -- information required for DPNSS signaling channel dpnssSigTable OBJECT-TYPE SYNTAX SEQUENCE OF DpnssSigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "DPNSS Signaling Table containing configuration and statistical parameters for all DPNSS signaling channel interfaces on this managed device." ::= { dpnssMib 1 } dpnssSigEntry OBJECT-TYPE SYNTAX DpnssSigEntry MAX-ACCESS not-accessible STATUS current Mukundan/Naganathan/Mangalpally/Anantharaman 13 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 DESCRIPTION "An entry in the DPNSS Signaling Channel Table." INDEX { dpnssSigIndex } ::= { dpnssSigTable 1 } DpnssSigEntry ::= SEQUENCE { dpnssSigIndex INTEGER, dpnssSigIfIndex InterfaceIndex, dpnssSigTrkCount Integer32, dpnssSigInfoTrapEnable INTEGER, dpnssSigEndPtType INTEGER, dpnssSigL2ReTxns Integer32, dpnssSigL2ReTxnTimeout Integer32, dpnssSigL2ReTxnAckTimeout Integer32, dpnssSigLinkOperStatus INTEGER, dpnssSigL2InCallsConn Counter32, dpnssSigL3InCallsConn Counter32, dpnssSigL2OutCallsConn Counter32, dpnssSigL3OutCallsConn Counter32, dpnssSigL2AttemptedConns Counter32, dpnssSigUnprocessedUIs Counter32 } dpnssSigIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index value which uniquely identifies an entry in the dpnssSigTable." ::= { dpnssSigEntry 1 } dpnssSigIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex value of the interface associated with this signaling channel." ::= { dpnssSigEntry 2 } dpnssSigTrkCount OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of DPNSS Trunks(bearer channels) managed by this signaling channel. For E1 this will be 30 and for T1 it will be 24." ::= { dpnssSigEntry 3 } dpnssSigInfoTrapEnable OBJECT-TYPE Mukundan/Naganathan/Mangalpally/Anantharaman 14 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether dpnssMibCallInformation traps should be generated for calls on this signaling channel." DEFVAL { disabled } ::= { dpnssSigEntry 4 } dpnssSigEndPtType OBJECT-TYPE SYNTAX INTEGER { a(1), b(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object shall be used such that the two PBXs at each end of the transmission link shall be designated A & B by arrangement at configuration as specified in BTNR 188." ::= { dpnssSigEntry 5 } dpnssSigL2ReTxns OBJECT-TYPE SYNTAX Integer32 (-32768..32767) MAX-ACCESS read-write STATUS current DESCRIPTION "This is the minimum retransmission count limit designated as 'NL' in BTNR 188. This is the minimum number of retransmissions of a command frame, which must take place if the correct acknowledgment is not received. BTNR recommends a value of 64 for this parameter. If set to a value of -1 (or any other negative value) this parameter is rendered redundant. In such cases the NL value should be set/read on a per DLC basis from the dpnssDLCTable. If set to a value other than -1 (or any other negative value) it will be applicable to all the DLCs." DEFVAL {64} ::= { dpnssSigEntry 6 } dpnssSigL2ReTxnTimeout OBJECT-TYPE SYNTAX Integer32 (-32768..32767) MAX-ACCESS read-write STATUS current DESCRIPTION Mukundan/Naganathan/Mangalpally/Anantharaman 15 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 "This is the minimum retransmission period designated as 'NT1' in BTNR 188. This is the minimum period of time for which a command frame must be retransmitted if not acknowledged. BTNR 188 recommends this value to be 500ms. If set to a value of -1 (or any other negative value) this paramter is rendered redundant. In such cases the NT1 value should be set/read on a per DLC basis from the dpnssDLCTable. If set to a value other than -1 (or any other negative value) it will be applicable to all the DLCs." DEFVAL {500} ::= { dpnssSigEntry 7 } dpnssSigL2ReTxnAckTimeout OBJECT-TYPE SYNTAX Integer32 (-32768..32767) MAX-ACCESS read-write STATUS current DESCRIPTION "This is the minimum post retransmission acknowledgment delay designated as 'NT2' in BTNR 188. This is the minimum period of time after the expiry of NL and NT1 during which an acknowledgement is awaited before reporting a retransmission failure to DPNSS Layer 3. When DPNSS is used via a satellite link, BTNR 188 recommends a value of 520ms for NT2 and 0 otherwise. If set to a value of -1 (or any other negative value) this parameter is rendered redundant. In such cases the NT2 value should be set/read on a per DLC basis from dpnssDLCTable. If set to a value other than -1 (or any other negative value) it will be applicable to all the DLCs." DEFVAL {0} ::= { dpnssSigEntry 8 } dpnssSigLinkOperStatus OBJECT-TYPE SYNTAX INTEGER { oos(1), idle(2), resetAttempted(3), resetComplete (4), infoTransfer (5), recvOverrun(6), babbling(7), crptMsg(8), overload (9), bsy(10), lockout(11), inb(12), offLine(13), pInSv (14), pOverload (15) } Mukundan/Naganathan/Mangalpally/Anantharaman 16 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 MAX-ACCESS read-write STATUS current DESCRIPTION "Parameter specifying the different DPNSS Signaling channel states. The maintenance states - bsy, inb and offline does not directly correspond to a DLC state in the DLC table. In this state the DLCs state should be either one of oos or resetAttempt. oos - Out Of Service This State can be entered immediately following power up or due to a maintenance action, eg following reset failure. It is the state in which all DLCs exist before activation of the Data Link Layer. A DLC remains in the 'Out of Service' state if it is not being used across a particular physical link. In this state all received frames are ignored. The oos status in the dpnssSigTable indicates that all the corresponding DLCs are in oos state. idle This is the state which a DLC enters from the OOS state while awaiting to be started. In this state reset requests from the remote PBX are not ignored, as in the Out of service state. If a DLC is reset remotely the local data link layer does not need to reset it. When a DLC is started up locally it moves from this state to Reset Attempted. The idle status in the dpnssSigTable indicates that all the corresponding DLCs are idle state. resetAttempted This is the state which a DLC enters when a reset request is sent on it. The DLC enters the Reset Complete state on completion of the reset procedure. The resetAttempted status in the dpnssSigTable indicates that all the corresponding DLCs are in resetAttempted state. resetComplete This is the state of a DLC which has just been successfuly reset. In this state, all the state variables are set to 0. The resetComplete status in the dpnssSigTable indicates that all the corresponding DLCs are in resetComplete state overload This indicates that a DLC is not able to process the L2 messages due to various overload reasons which can result for example when the layer 2 peer DLC is sending Mukundan/Naganathan/Mangalpally/Anantharaman 17 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 messages at a rate faster than the what the near-end can handle. The overload status in the dpnssSigTable indicates that all the corresponding DLCs are in overload state. recvOverrun - receive overrun This indicates that the DLC is receiving layer 2 messages from a peer at a rate faster than it can buffer/process. The recvOverrun status in the dpnssSigTable indicates that all the corresponding DLCs are in recvOverrun state. babbling This indicates the receipt of an unexpected 'glitch- message' on all the DLCs. crptMsg - corrupt message This indicates the receipt of a corrupt (but correctly framed) DPNSS Layer 2 message on all the DLCs catered by this DPNSS signaling channel. The states - oos, idle, resetAttempted, resetComplete, infoTransfer and overload of this table is applicable to all the DLCs & reflects the status of all the DLCs. This value should match the corresponding OperStatus of the DLC Table. This option is provided so that the implentors have the flexibility of setting/reading the states of all DLCs in one shot rather than walking through all the entries of the DLC table. bsy - busy Indicates a maintenance operation status of the signaling channel during which this link will not be used for signaling. Generally this is the value during some maintenance actions on the DPNSS link. inB - installation Busy Indicates a maintenance operation of the signaling channel during which, apart from this channel not being available for signaling, the configuration parameters (mostly ds0 characteristics of this interface) can be changed. The implementor may chose to just use the bsy state as a superset state instead of inB in which case this state will be rendered redundant. offLine - Indicates a maintenance operation of this signaling channel during which, apart from this channel not being available for call processing, the dpnss link interface configuration parameters also cannot be changed. This state is used to completely delete this Mukundan/Naganathan/Mangalpally/Anantharaman 18 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 interface and configure it as some interface or re- configure this interface. The vendor may just chose to just use the inB state as a superset state instead of offline in which case this state will be rendered redundant. pInSv - Partial Inservice This indicates that some DLCs (atleast 1 DLC) are in Reset Complete, Information Transfer or Idle state. pOverload - Partial Overload This indicates that some DLCs (atleast 1 DLC) is in overload state." ::= { dpnssSigEntry 9 } dpnssSigL2InCallsConn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of peer SABMR frames successfully received on this interface. This is the number of peer-initiated new connections on this interface. This does not include the SABMR frames that were received but were not processed." ::= { dpnssSigEntry 10 } dpnssSigL3InCallsConn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming calls on this interface which were actually connected." ::= { dpnssSigEntry 11 } dpnssSigL2OutCallsConn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of SABMR frames sent from this interface. This is the number of new connections initiated from this interface." ::= { dpnssSigEntry 12 } dpnssSigL3OutCallsConn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Mukundan/Naganathan/Mangalpally/Anantharaman 19 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 DESCRIPTION "The number of outgoing calls on this interface which were actually connected." ::= { dpnssSigEntry 13 } dpnssSigL2AttemptedConns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of peer SABMR frames received on this interface. This is the number of peer-initiated new connections on this interface. This also includes the SABMR frames that were received but could not be procesed resulting in unsuccessful Layer 2 connection attempts. This count gives the SABMR frames received for on all the DLCs." ::= { dpnssSigEntry 14} dpnssSigUnprocessedUIs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of peer UI frames received on this interface but could not be processed successfully (e.g. due to layer 2 overload). This count gives the unsuccessful UI frame count for on all the DLCs." ::= { dpnssSigEntry 15} -- The dpnssDLCTable contains DPNSS DLC related information -- required for a DPNSS signaling channel dpnssDLCTable OBJECT-TYPE SYNTAX SEQUENCE OF DpnssDLCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "DPNSS DLC table containing configuration and DLC characteristic parameters for all DPNSS DLCs on this managed device. One Entry for each Lap (total of 60 Entries). There is no ifEntry for a DPNSS DLC in the IfTable." ::= { dpnssMib 2 } dpnssDLCEntry OBJECT-TYPE SYNTAX DpnssDLCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DPNSS DLC Table." INDEX { dpnssDLCSigIfIndex } Mukundan/Naganathan/Mangalpally/Anantharaman 20 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 ::= { dpnssDLCTable 1 } DpnssDLCEntry ::= SEQUENCE { dpnssDLCSigIfIndex InterfaceIndex, dpnssDLCNum INTEGER, dpnssDLCInfoTrapEnable INTEGER, dpnssDLCReTxns Integer32, dpnssDLCReTxnTimeout Integer32, dpnssDLCReTxnAckTimeout Integer32, dpnssDLCOperStatus INTEGER, dpnssDLCType INTEGER, dpnssDLCFrmErrs Counter32, dpnssDLCUnprocessedUIs Counter32 } dpnssDLCSigIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The ifIndex value corresponding to the DPNSS signaling channel that is responsible for this DLC. It is important to note that this is also the index for the dpnssDLCTable. Since the DLC does not have a corresponding ifEntry, this is the only link between the DPNSS DLC table and the DPNSS Signaling table provided by this MIB" ::= { dpnssDLCEntry 1 } dpnssDLCNum OBJECT-TYPE SYNTAX INTEGER (1..60) MAX-ACCESS read-only STATUS current DESCRIPTION "The identifier being used by the signaling protocol to identify this DLC, also referred to as 'Link Access Protocol (LAP) Number'." ::= { dpnssDLCEntry 2 } dpnssDLCInfoTrapEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether dpnssMibCallInformation traps should be generated for calls on this DLC." DEFVAL { disabled } ::= { dpnssDLCEntry 3 } Mukundan/Naganathan/Mangalpally/Anantharaman 21 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 dpnssDLCReTxns OBJECT-TYPE SYNTAX Integer32 (-32768..32767) MAX-ACCESS read-write STATUS current DESCRIPTION "This is the minimum retransmission count limit designated as 'NL' in BTNR 188. This is the minimum number of retransmissions of a command frame which must take place if the correct acknowledgment is not received. BTNR recommends a value of 64 for this parameter. If set to a value of -1 (or any other negative value) this parameter is rendered redundant. In such cases the NL value should be set/read from the dpnssSigTable. This value should not be -1 in the dpnssSigTable and dpnssDLCTable at the same time." DEFVAL {64} ::= { dpnssDLCEntry 4 } dpnssDLCReTxnTimeout OBJECT-TYPE SYNTAX Integer32 (-32768..32767) MAX-ACCESS read-write STATUS current DESCRIPTION "This is the minimum retransmission period designated as 'NT1' in BTNR 188. This is the minimum period of time for which a command frame must be retransmitted if not acknowledged. BTNR 188 recommends this value to be 500ms. If set to a value of -1 (or any other negative value) this paramter is rendered redundant. In such cases the NT1 value should be set/read from the dpnssSigTable. This value should not be -1 in the dpnssSigTable and dpnssDLCTable at the same time." DEFVAL {500} ::= { dpnssDLCEntry 5 } dpnssDLCReTxnAckTimeout OBJECT-TYPE SYNTAX Integer32 (-32768..32767) MAX-ACCESS read-write STATUS current DESCRIPTION "This is the minimum post retransmission acknowledgment delay designated as 'NT2' in BTNR 188. This is the minimum period of time after the expiry of NL and NT1 during which an acknowledgement is awaited before reporting a retransmission failure to DPNSS Layer 3. When DPNSS is used via a satellite link, BTNR 188 recommends a value of 520ms for NT2 and 0 otherwise. If set to a value of -1 (or any other negative value) this parameter is rendered redundant. In such cases the NT2 value should be set/read from dpnssSigTable. This value should not be -1 in the dpnssSigTable and dpnssDLCTable at the same time." Mukundan/Naganathan/Mangalpally/Anantharaman 22 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 DEFVAL {0} ::= { dpnssDLCEntry 6 } dpnssDLCOperStatus OBJECT-TYPE SYNTAX INTEGER { oos(1), idle(2), resetAttempted(3), resetComplete(4), infoTransfer(5), overload(6), recvOverrun(7), babbling(8), crptMessage(9) } MAX-ACCESS read-write STATUS current DESCRIPTION "Parameter specifying the different DPNSS Layer 2 DLC states. oos - Out Of Service This State can be entered immediately following power up or due to a maintenance action, eg following reset failure. It is the state in which all DLCs exist before activation of the Data Link Layer. A DLC remains in the 'Out of Service' state if it is not being used across a particular physical link. In this state all received frames are ignored. idle This is the state which a DLC enters from the OOS state while awaiting to be started. In this state reset requests from the remote PBX are not ignored, as in the Out of service state. If a DLC is reset remotely the local data link layer does not need to reset it. When a DLC is started up locally it moves from this state to Reset Attempted. resetAttempted This is the state which a DLC enters when a reset request is sent on it. The DLC enters the Reset Complete state on completion of the reset procedure. resetComplete This is the state of a DLC which has just been successfuly reset. In this state, all the state variables are set to 0. overload This indicates that a DLC is not able to process the L2 messages due to various overload reasons which can Mukundan/Naganathan/Mangalpally/Anantharaman 23 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 result for example when the layer 2 peer DLC is sending messages at a rate faster than the what the near-end can handle. recvOverrun - receive overrun This indicates that the DLC is receiving layer 2 messages from a peer at a rate faster than it can buffer/process. babbling This indicates the receipt of an unexpected 'glitch- message' on all this DLC. crptMsg - corrupt message This indicates the receipt of a corrupt (but correctly framed) DPNSS Layer 2 message on this DLC." ::= { dpnssDLCEntry 7 } dpnssDLCType OBJECT-TYPE SYNTAX INTEGER { real(1), virtual(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates whether it is a real or virtual DLC." ::= { dpnssDLCEntry 8 } dpnssDLCFrmErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of L2 Framing Errors." ::= { dpnssDLCEntry 9 } dpnssDLCUnprocessedUIs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of peer UI frames received on this interface but could not be processed successfully (e.g. due to layer 2 overload). This count gives the unsuccessful UI frame count for on all the DLCs." ::= { dpnssDLCEntry 10} -- The DPNSS Trunk Group. This Group consists of just two tables. -- the dpnss trunk table and -- the dpnss trunk mapping table. Mukundan/Naganathan/Mangalpally/Anantharaman 24 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 -- The dpnssTrkTable contains configuration and statistical -- information required for DPNSS trunks. dpnssTrkTable OBJECT-TYPE SYNTAX SEQUENCE OF DpnssTrkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines port specific operational, statistics and active call data for DPNSS Trunks. Each entry in this table describes one DPNSS Trunk channel." ::= { dpnssMib 3} dpnssTrkEntry OBJECT-TYPE SYNTAX DpnssTrkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Operational and statistics information relating to one port. A port is a single DPNSS (Trunk)." INDEX { ifIndex } ::= { dpnssTrkTable 1 } DpnssTrkEntry ::= SEQUENCE { dpnssTrkIfIndex INTEGER, dpnssTrkSigIfIndex InterfaceIndex, dpnssTrkNum INTEGER, dpnssTrkInfoTrapEnable INTEGER, dpnssTrkOperStatus INTEGER, dpnssTrkOpulseType INTEGER, dpnssTrkDir INTEGER, dpnssTrkIfAddress DisplayString, dpnssTrkCallSetupTime TimeStamp, dpnssTrkCallConnectTime TimeStamp } dpnssTrkIfIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The index value which uniquely identifies an entry in the dpnssTrkTable." ::= { dpnssTrkEntry 1 } dpnssTrkSigIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only Mukundan/Naganathan/Mangalpally/Anantharaman 25 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 STATUS current DESCRIPTION "The ifIndex value corresponding to the DPNSS signaling channel that serves as the signaling channel for this trunk." ::= { dpnssTrkEntry 2 } dpnssTrkNum OBJECT-TYPE SYNTAX INTEGER (1..30) MAX-ACCESS read-only STATUS current DESCRIPTION "The identifier being used by a signaling protocol to identify this trunk, also referred to as trunk number. If the Agent also supports the DS0 MIB, the values of dpnssTrkNum and dsx0Ds0Number must be identical for a given DPNSS Trunk." ::= { dpnssTrkEntry 3 } dpnssTrkInfoTrapEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether dpnssMibCallInformation traps should be generated for calls over this Trunk." DEFVAL { disabled } ::= { dpnssTrkEntry 4 } dpnssTrkOperStatus OBJECT-TYPE SYNTAX INTEGER { icSetupReq(1), ogSetupReq(2), icSetupComp(3), ogSetupComp(4), icSetupCompBuf(5), ogSetupCompBuf(6), icAns(7), ogAns(8), clearing(9), idle(10), bsy(11), lockout(12), inb(13), offLine(14) } MAX-ACCESS read-write STATUS current DESCRIPTION Mukundan/Naganathan/Mangalpally/Anantharaman 26 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 "The Different DPNSS DPNSS trunk States as specified by BTNR 188. Also incorporates maintenance operation states that. icSetupReq - Incoming Setup Request Indicates that there is an incoming setup request (ISRM receipt). ogSetupReq - Outgoing Setup Request Indicates that there is an outgoing setup request outgoing ISRM). icSetupComp - Incoming Setup Complete Indicates that the trunk in inSetupReq state has sent a successful Ack (sending of DPNSS Number Acknowledge (NAM) message). ogSetupComp - Outgoing Setup Complete Indicates that the trunk in ogSetupReq state has received a successful acknowledgement(incoming NAM). inSetupCompBuf - Incoming Setup Complete Buffer Indicates the receipt of a message received on a trunk in inSetupComp state and being buffered (example, the received EEM(I)s may be buffered till the receipt of EEM(C)s before being processed. ogSetupCompBuf - Outgoing Setup Complete Buffer Indicates the receipt of a message received on a trunk in ogSetupComp state. inAns - Incoming Answer Indicates the sending of an of an answer message (incoming DPNSS Call Connected Message (CCM)). ogAns - Outgoing Answer Indicates the receipt of an answer message on a trunk that is in ogSetupComp state(outgoing CCM). Clearing Indicates the sending of an clearing message (outgoing DPNSS Clear Request Message (CRM). The trunk will return to idle state or the receipt of a DPNSS Clear Indication Message from the peer PBX in response to the CRM. idle Default working state when no call attempt or call in progress on this trunk. bsy - busy Indicates a maintenance operation status of the trunk Mukundan/Naganathan/Mangalpally/Anantharaman 27 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 during which this trunk will not be used for call processing. Generally done to perform some maintenance on the DPNSS trunk. LockOut Indicates that the corresponding Layer 2 DLC is Out Of- Service. inB - installation Busy Indicates a maintenance operation of the trunk during which, apart from this trunk not being available for call processing, the configuration parameters (like dpnssTrkDir etc) of the trunk can be changed. The implementor may chose to just use the bsy state as a superset state instead of inB in which case this state will be rendered redundant. offLine - Indicates a maintenance operation of the trunk during which, apart from this trunk not being available for call processing, the trunk interface configuration parameters also cannot be changed. This state is used normally to completely delete this interface and reconfigure as some other interface. The vendor may just chose to just use the inB state as a superset state instead of offline in which case this state will be rendered redundant. Further, the DS1 interface over which the DPNSS trunks and signaling channel is configured cannot be shared across another protocol (e.g. ISDN - Primary Rate Interface) interface - this further reduces the usefulness of this state but the parameter is provided in favour of implementation flexibility." ::= { dpnssTrkEntry 5} dpnssTrkOpulseType OBJECT-TYPE SYNTAX INTEGER { enblock(1), overlap(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the type of digit outpulsing that will be done for a call-setup over this trunk." ::= { dpnssTrkEntry 6 } dpnssTrkDir OBJECT-TYPE SYNTAX INTEGER { ic(1), og(2), twoW(3) Mukundan/Naganathan/Mangalpally/Anantharaman 28 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 } MAX-ACCESS read-write STATUS current DESCRIPTION "The direction of the trunk call that will be supported over this trunk. ic - Allow only Incoming calls over this trunk og - Allow only Outgoing calls over this trunk twoW - Allow both incoming and outgoing calls over this trunk." ::= { dpnssTrkEntry 7 } dpnssTrkIfAddress OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "Interface address if any, in IA5 format of the DPNSS trunk Interface" ::= { dpnssTrkEntry 8 } dpnssTrkCallSetupTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the DPNSS setup message [DPNSS Initial Service Request Message (ISRM)] for the current or last call was sent or received. If since system startup there has been no call on this interface, this object has a value of zero." ::= { dpnssTrkEntry 9 } dpnssTrkCallConnectTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the DPNSS connect message [DPNSS Call Connect Message (CCM)] for the current or last call was sent or received. If since system startup there has been no call on this interface, this object has a value of zero." ::= { dpnssTrkEntry 10 } -- The dpnssTrkMappingTable is used for quick look-up to -- associate a dpnss trunk with the corresponding dpnss signaling -- channel dpnssTrkMappingTable OBJECT-TYPE Mukundan/Naganathan/Mangalpally/Anantharaman 29 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 SYNTAX SEQUENCE OF DpnssTrkMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " The dpnssTrkMappingTable is used for quick look-up to associate a dpnss trunk with the corresponding dpnss signaling channel." ::= { dpnssMib 4 } dpnssTrkMappingEntry OBJECT-TYPE SYNTAX DpnssTrkMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is an entry in the DPNSS Trunk Mapping table. There is a entry in this table corresponding to each DPNSS trunk ifEntry. This table is intended to facilitate mapping from DPNSS signaling channel ifEntry/DPNSS trunk number to the DPNSS trunk ifEntry. (e.g. mapping (DPNSS signaling channel ifIndex, DPNSS trunk number) -> DPNSS trunk ifIndex. While this table provides information that can also be indirectly derived from the ifStackTable using the ds0 & ds1 MIBs, it provides the same information with a single table lookup, rather than by walking through the ifStackTable to find the various constituent ds0 ifTable entries, and testing various ifEntry leaf nodes like ifName etc." INDEX { ifIndex, dpnssTrkNum } ::= { dpnssTrkMappingTable 1 } DpnssTrkMappingEntry ::= SEQUENCE { dpnssTrkMappingIfIndex InterfaceIndex } dpnssTrkMappingIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the ifIndex value assigned by the agent for the individual dpnss trunk ifEntry that corresponds to the given dpnss trunk number (specified by the INDEX element dpnssTrkNum) of the associated dpnss signaling interface (specified by INDEX element ifIndex)." ::= { dpnssTrkMappingEntry 1 } -- Traps Mukundan/Naganathan/Mangalpally/Anantharaman 30 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 dpnssMibTraps OBJECT IDENTIFIER ::= { dpnssMib 5 } dpnssMibLinkInformation NOTIFICATION-TYPE OBJECTS { dpnssSigIndex, dpnssSigLinkOperStatus, dpnssSigUnprocessedUIs } STATUS current DESCRIPTION "This trap/information is sent to the manager under the following conditions: - The dpnssSigLinkOperStatus goes to one of oos, resetAttempted, overload, recvOverrun, babbling, or crptMsg. - the dpnssSigUnprocessedUIs exceeds a preset threshold. The exact value of the threshold is implementor specific. If a threshold is not implemented in the agent, this trap will be generated for any positive value of dpnssSigUnprocessedUIs." ::= { dpnssMibTraps 0 1 } dpnssMibDLCSigInformation NOTIFICATION-TYPE OBJECTS { dpnssDLCSigIfIndex, dpnssDLCNum, dpnssDLCOperStatus, dpnssDLCType, dpnssDLCFrmErrs, dpnssDLCUnprocessedUIs } STATUS current DESCRIPTION "This trap/information is sent to the manager under the following conditions: - the dpnssDLCOperStatus goes to one of overload, recvOverrun, babbling, or crptMsg. - the dpnssDLCUnprocessedUIs exceeds a preset threshold. The exact value of the threshold is implementor specific. If a threshold is not implemented in the agent, this trap will be generated for any positive value of dpnssSigUnprocessedUIs. It is recommended that a different thresholds be implemented for dpnssSigUnprocessedUIs and dpnssDLCUnprocessedUIs. - the dpnssDLCL2FrameErrs exceeds a preset threshold. The exact value of the threshold is implementor specific. If a threshold is not implemented in the agent, the trap will be generated for any positive value of dpnssDLCL2FrameErrs." ::= { dpnssMibTraps 0 2 } Mukundan/Naganathan/Mangalpally/Anantharaman 31 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 dpnssMibTrkInformation NOTIFICATION-TYPE OBJECTS { dpnssTrkSigIfIndex, dpnssTrkNum, dpnssTrkOperStatus, dpnssTrkCallSetupTime } STATUS current DESCRIPTION "This trap/information is sent to the manager under the following conditions: - the dpnssTrkOperStatus goes to one of lockout, inb or offLine." ::= { dpnssMibTraps 0 3 } -- -- conformance information -- dpnssMibConformance OBJECT IDENTIFIER ::= { dpnssMib 6 } dpnssMibCompliances OBJECT IDENTIFIER ::= { dpnssMibConformance 1 } dpnssMibGroups OBJECT IDENTIFIER ::= { dpnssMibConformance 2 } -- compliance statements dpnssMibCompliances MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the DPNSS MIB." MODULE -- this module -- mandatory groups MANDATORY-GROUPS { dpnssMibSigGroup, dpnssMibTrkGroup } OBJECT dpnssSigL2InCallsConn MIN-ACCESS read-only DESCRIPTION "The number of peer SABMR frames successfully received on a DPNSS signaling channel interface is not required." OBJECT dpnssSigL3InCallsConn MIN-ACCESS read-only DESCRIPTION "The number of incoming calls on the DPNSS signaling channel interface which were actually connected." Mukundan/Naganathan/Mangalpally/Anantharaman 32 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 OBJECT dpnssSigL2OutCallsConn MIN-ACCESS read-only DESCRIPTION "The number of SABMR frames sent on a DPNSS signaling channel interface is not required." OBJECT dpnssSigL3OutCallsConn MIN-ACCESS read-only DESCRIPTION "The number of outgoing calls on a DPNSS signaling channel interface which were actually connected is not required." OBJECT dpnssSigL2AttemptedConns MIN-ACCESS read-only DESCRIPTION "The number of peer SABMR frames received on a DPNSS signaling channel interface is not required." OBJECT dpnssSigUnprocessedUIs MIN-ACCESS read-only DESCRIPTION "The number of peer UI frames received on the signaling channel interface but could not be processed successfully is not required." OBJECT dpnssDLCUnprocessedUIs MIN-ACCESS read-only DESCRIPTION "The number of peer UI frames received on a DLC but could not be processed successfully is not required." OBJECT dpnssTrkOpulseType MIN-ACCESS read-only DESCRIPTION "The number of peer UI frames received on a DLC but could not be processed successfully is not required." OBJECT dpnssTrkDir MIN-ACCESS read-only DESCRIPTION "The direction of the trunk call that will be supported over a trunk is not required." OBJECT dpnssTrkIfAddr MIN-ACCESS read-only DESCRIPTION "Interface address if any, in IA5 format of the DPNSS trunk Interface is not required." Mukundan/Naganathan/Mangalpally/Anantharaman 33 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 ::= { dpnssMibCompliances 1 } -- units of conformance dpnssMibSigGroup OBJECT-GROUP OBJECTS { dpnssSigIndex, dpnssSigIfIndex, dpnssTrkNum, dpnssSigInfoTrapEnable, dpnssSigEndPtType, dpnssSigL2ReTxns, dpnssSigL2ReTxnTimeout, dpnssSigL2ReTxnAckTimeout, dpnssDLCReTxns, dpnssDLCReTxnTimeout, dpnssDLCReTxnAckTimeout, dpnssSigLinkOperStatus, dpnssSigL2InCallsConn, dpnssSigL3InCallsConn, dpnssSigL2OutCallsConn, dpnssSigL3OutCallsConn, dpnssSigL2AttemptedConns, dpnssSigUnprocessedUIs, dpnssDLCSigIfIndex, dpnssDLCNum, dpnssDLCInfoTrapEnable, dpnssDLCReTxns, dpnssDLCReTxnTimeout, dpnssDLCReTxnAckTimeout, dpnssDLCOperStatus, dpnssDLCType, dpnssDLCFrmErrs, dpnssDLCUnprocessedUIs } STATUS current DESCRIPTION "A collection of objects providing configuration and statistical information applicable to all DPNSS signaling channel interfaces." ::={ dpnssMibGroups 1} dpnssMibTrkGroup OBJECT-GROUP OBJECTS { dpnssTrkIfIndex, dpnssTrkSigIfIndex, dpnssTrkNum, dpnssTrkInfoTrapEnable, dpnssTrkOperStatus, dpnssTrkOpulseType, dpnssTrkDir, dpnssTrkIfAddress, dpnssTrkCallSetupTime, Mukundan/Naganathan/Mangalpally/Anantharaman 34 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 dpnssTrkCallConnectTime, dpnssTrkMappingIfIndex } STATUS current DESCRIPTION "A collection of objects providing configuration, statistical & signaling channel - trunk mapping information applicable to all DPNSS trunk interfaces." ::={ dpnssMibGroups 2} END 5. Security Considerations SNMPv1 by itself is such an insecure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET (read) the objects in this MIB. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2274 [12] and the View-based Access Control Model RFC 2275 [21] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to those objects only to those principals (users) that have legitimate rights to access them. Setting any of the following objects to an inappropriate value can cause loss of traffic. The definition of inappropriate varies for each object. In the case of dpnssSigLinkOperStatus & dpnssDLCOperStatus, both of which are read-write objects, if the states are set to out of service (oos) there will the traffic on these interfaces will stop and create bottlenecks/overload on other interfaces. In the case of DLC & DPNSS Link transmission timeouts and number of re-transmissions if set to a unrealistically low value will result in calls dropping on that interface that is being manipulated. dpnssSigLinkOperStatus dpnssDLCOperStatus dpnssDLCReTxns dpnssDLCReTxnTimeout dpnssSigLinkReTxns dpnssSigLinkReTxnTimeout dpnssSigEndPtType dpnssTrkOperStatus Mukundan/Naganathan/Mangalpally/Anantharaman 35 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 dpnssTrkDir Setting the following objects is mischievous, but not harmful to traffic. dpnssSigInfoTrapEnable dpnssSigLinkReTxnAckTimeout dpnssDLCInfoTrapEnable dpnssDLCReTxnAckTimeout dpnssTrkIfAddress If the implentor specific trap thresholds for the DPNSS signaling channel and DLC are set to a low inappropriate value (or if the thresholds are not implemented for agents that require it), then the manager will be flooded with traps (if the traps are enabled for the interfaces) and can potentially hog the network bandwidth between the agent and the manager. 6. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [3] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998. [4] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC1155, May 1990. [5] RFC1212 Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [6] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [9] RFC2580 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, Mukundan/Naganathan/Mangalpally/Anantharaman 36 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [10] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Lab for Computer Science, May 1990. [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,"Introduction to Community-based SNMPv2", RFC 1901, January 1996. [12] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [13] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998. [14] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. [15] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [16] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [17] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [18] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [19] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, June 2000. [20] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998. [21] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998. Mukundan/Naganathan/Mangalpally/Anantharaman 37 Internet Draft draft-ranjith-dpnss-mib-00.txt November 2000 [22] British Telecom Network Requirement (BTNR)188, "DIGITAL PRIVATE NETWORK SIGNALING SYSTEM No 1 (DPNSS 1)", issue 6, Volume 1, 2, 3 & 4, January 1995 [23] http://www.simpleweb.org/, "IANAifType MIB" [24] Fowler, D., "Definitions of Managed Objects for the Ds0 and DS0Bundle Interface Types", RFC 2494, January 1999. [25] Fowler, D., "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types Interface Types", RFC 2495, January 1999. 7. Acknowledgments The authors would like to thank Rodney Miller & Sharon Chisholm of Nortel Networks for their useful suggestions/comments. 8. Author's Addresses Authors: Ranjith Mukundan, Sudarsan Naganathan, Narsimuloo Mangalpally and Vaidyanathan Anantharaman All correspondence regarding this draft should be sent to the following address : Mick Dragon Tel. +44 (0)1628434388 Nortel Networks plc Email. mdragon@nortelnetworks.com Concorde Road Maidenhead Berkshire SL6 4AG United Kingdom Mukundan/Naganathan/Mangalpally/Anantharaman 38