Internet Draft SIP Objects November 1990 Definitions of Managed Objects for the SIP Interface Type November 1990 SNMP Working Group Kaj Tesink (editor) Bell Communications Research 331 Newman Springs Road Red Bank, NJ 07701 kaj@nvuxr.cc.bellcore.com 1. Status of this Memo This draft document will be submitted to the RFC editor as an experimental extension to the SNMP MIB. Distribution of this memo is unlimited. Please send comments to the editor. 2. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing SIP (SMDS Interface Protocol) objects. This memo does not specify a standard for the Internet community. Kaj Tesink (editor) [Page 1] Internet Draft SIP Objects November 1990 3. Historical Perspective As reported in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [1], a two-prong strategy for network management of TCP/IP-based internets was undertaken. In the short-term, the Simple Network Management Protocol (SNMP), defined in RFC 1067, was to be used to manage nodes in the Internet community. In the long-term, the use of the OSI network management framework was to be examined. Two documents were produced to define the management information: RFC 1065, which defined the Structure of Management Information (SMI), and RFC 1066, which defined the Management Information Base (MIB). Both of these documents were designed so as to be compatible with both the SNMP and the OSI network management framework. This strategy was quite successful in the short-term: Internet-based network management technology was fielded, by both the research and commercial communities, within a few months. As a result of this, portions of the Internet community became network manageable in a timely fashion. As reported in RFC 1109, Report of the Second Ad Hoc Network Management Review Group [2], the requirements of the SNMP and the OSI network management frameworks were more different than anticipated. As such, the requirement for compatibility between the SMI/MIB and both frameworks was suspended. This action permitted the operational network management framework, based on the SNMP, to respond to new operational needs in the Internet community by producing MIB-II. In May of 1990, the core documents were elevated to "Standard Protocols" with "Recommended" status. As such, the Internet- standard network management framework consists of: Structure and Identification of Management Information for TCP/IP-based internets, RFC 1155 [3], which describes how managed objects contained in the MIB are defined; Management Information Base for Network Management of TCP/IP-based internets, which describes the managed objects contained in the MIB, RFC 1156 [4]; and, the Simple Network Management Protocol, RFC 1157 [5], which defines the protocol used to manage these objects. Consistent with the IAB directive to produce simple, workable systems in the short-term, the list of managed objects defined in the Internet-standard MIB was derived by taking only those Kaj Tesink (editor) [Page 2] Internet Draft SIP Objects November 1990 elements which are considered essential. However, the SMI defined three extensibility mechanisms: one, the addition of new standard objects through the definitions of new versions of the MIB; two, the addition of widely-available but non- standard objects through the experimental subtree; and three, the addition of private objects through the enterprises subtree. Such additional objects can not only be used for vendor-specific elements, but also for experimentation as required to further the knowledge of which other objects are essential. This memo defines extensions to the MIB using the second method. It contains definitions of managed objects used for experimentation. Kaj Tesink (editor) [Page 3] Internet Draft SIP Objects November 1990 4. Objects 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) [7] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. 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 OBJECT DESCRIPTOR, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI [3] purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network. The SMI specifies the use of the basic encoding rules of ASN.1 [8], subject to the additional requirements imposed by the SNMP. 4.1. Format of Definitions Section 6 contains contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [13,14]. Kaj Tesink (editor) [Page 4] Internet Draft SIP Objects November 1990 5. Overview These objects are used when the particular media being used to realize an interface is a SIP interface. At present, this applies to these values of the ifType variable in the Internet-standard MIB: sip (31) The definitions contained herein are based on the SIP specifications in Bellcore TA-TSY-000772 Issue 3, and TA-TSY- 000773 Issue 2 [11,12]. The SIP (SMDS Interface Protocol) protocol stack is defined as follows in [11]: ____________________ | | | SIP Level 3 [11] | |___________________| | | | SIP Level 2 [11] | |___________________| | | | PLCP [12] | |___________________| | | | DS1 or DS3 [12] | |___________________| The PLCP (Physical Layer Convergence Procedure) adapts the capabilities of the transmission system (DS1 or DS3 formats) to the service expected by SIP Level 2. Managed objects for DS1 and DS3 Interface Types are defined in [13] and [14] respectively, and can be utilized for management of SIP interfaces. This document defines managed objects for the remaining protocol levels of the SIP Interface Type. This document does not specify objects for the management of subscription or configuration of Subscriber Network Interfaces (SNIs). Kaj Tesink (editor) [Page 5] Internet Draft SIP Objects November 1990 6. Object Definitions RFCxxxx-MIB DEFINITIONS ::= BEGIN IMPORTS experimental, Counter FROM RFC1155-SMI OBJECT-TYPE FROM RFC-oooo TRAP-TYPE FROM RFC-tttt; -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in [9], and the TRAP-TYPE macro as defined in [10] -- this is the MIB module for the SIP objects sip OBJECT IDENTIFIER ::= { experimental 16 } Kaj Tesink (editor) [Page 6] Internet Draft SIP Objects November 1990 sipPortTable OBJECT-TYPE SYNTAX SEQUENCE OF SIPPortEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This table contains Subscriber Network Interface (SNI) parameters and state variables, one entry per SIP port." ::= { sip 1 } sipPortEntry OBJECT-TYPE SYNTAX SIPPortEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This list contains Subscriber Network Interface (SNI) parameters and state variables." INDEX { sipPortIndex } ::= { sipPortTable 1 } SIPPortEntry ::= SEQUENCE { sipPortIndex INTEGER, receivedIndividualDAedSIPL3-PDU Counter, receivedGAedSIPL3-PDU Counter, erroredSIPL3-PDU Counter, unrecognizedDestinationAddress Counter, unrecognizedGroupAddress Counter, sentIndividualDAedSIPL3-PDU Counter, sentGAedSIPL3-PDU Counter, receivedSIPL2-PDU Counter, erroredSIPL2-PDU Counter, sentSIPL2-PDU Counter, Kaj Tesink (editor) [Page 7] Internet Draft SIP Objects November 1990 ds1PLCPSEFS Counter, ds1PLCPYellowSignal INTEGER, ds1PLCPRedAlarm INTEGER, ds1PLCPUASs Counter, ds3PLCPSEFS Counter, ds3PLCPYellowSignal INTEGER, ds3PLCPRedAlarm INTEGER, ds3PLCPUASs Counter } sipPortIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the SIP port interface for which this entry contains management information. The value of this object for a particular interface has the same value as the ifIndex object, defined in [4,6], for the same interface." ::= { sipPortEntry 1 } -- The SIP Level 3 group receivedIndividualDAedSIPL3-PDU OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SIP Level 3 PDUs received from the remote system across the SNI and containing an individual destination address. Kaj Tesink (editor) [Page 8] Internet Draft SIP Objects November 1990 The total includes both errored and unerrored L3-PDUs." ::= { sipPortEntry 2 } receivedGAedSIPL3-PDU OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SIP Level 3 PDUs received from the remote system across the SNI and containing an group destination address. The total includes both errored and unerrored L3- PDUs." ::= { sipPortEntry 3 } erroredSIPL3-PDU OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SIP Level 3 PDUs received from the remote system that were discovered to have errors (including protocol processing and bit errors but excluding addressing-related errors) and were discarded. Includes both group addressed L3-PDUs and L3-PDUs containing an individual destination address." ::= { sipPortEntry 4 } unrecognizedDestinationAddress OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of SIP Level 3 PDUs received from the remote system with invalid or unknown destination addresses (Source or Destination Address Screening violations are not included)." ::= { sipPortEntry 5 } unrecognizedGroupAddress OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory Kaj Tesink (editor) [Page 9] Internet Draft SIP Objects November 1990 DESCRIPTION "The number of SIP Level 3 PDUs received from the remote system with invalid or unknown group addresses." ::= { sipPortEntry 6 } sentIndividualDAedSIPL3-PDU OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of SIP Level 3 PDUs that have been sent by this system across the SNI and that contain an individual destination address. " ::= { sipPortEntry 7 } sentGAedSIPL3-PDU OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of group addressed SIP L3-PDUs that have been sent by this system across the SNI. " ::= { sipPortEntry 8 } Kaj Tesink (editor) [Page 10] Internet Draft SIP Objects November 1990 -- The SIP Level 2 group receivedSIPL2-PDU OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION " The number of SIP Level 2 PDUs received from the remote system across the SNI. The total includes both errored and successfully received L2-PDUs." ::= { sipPortEntry 9 } erroredSIPL2-PDU OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION " The number of SIP Level 2 PDUs received from the remote system across the SNI that were discovered to have errors (including protocol processing and bit errors)." ::= { sipPortEntry 10 } sentSIPL2-PDU OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION " The number of SIP Level 2 PDUs that have been sent by this system across the SNI." ::= { sipPortEntry 11 } Kaj Tesink (editor) [Page 11] Internet Draft SIP Objects November 1990 -- The PLCP group ds1PLCPSEFS OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A DS1 Severely Errored Framing Second (SEFS) is a count of one-second intervals containing one or more SEF events. A Severely Errored Framing (SEF) event is declared when an error in the A1 octet and an error in the A2 octet of a framing octet pair (i.e., errors in both framing octets), or two consecutive invalid and/or nonsequential Path Overhead Identifier octets are detected." ::= { sipPortEntry 12 } ds1PLCPYellowSignal OBJECT-TYPE SYNTAX INTEGER { ds1PLCPYellowSignal(1), ds1PLCPNoYellowSignal(2) } ACCESS read-only STATUS mandatory DESCRIPTION "This variable indicates if a Yellow Signal is received. See TA-TSY-000773 [12]." ::= { sipPortEntry 13 } ds1PLCPRedAlarm OBJECT-TYPE SYNTAX INTEGER { ds1PLCPRedAlarm(1), ds1PLCPNoRedAlarm(2) } ACCESS read-only STATUS mandatory DESCRIPTION "This variable indicates if a Red Alarm condition exists. A Red Alarm condition is sent when the declaration of a PLCP Loss of Frame failure condition occurs. See TA-TSY-000773 [12]." ::= { sipPortEntry 14 } ds1PLCPUASs OBJECT-TYPE Kaj Tesink (editor) [Page 12] Internet Draft SIP Objects November 1990 SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Unavailable Seconds, as defined by [12], encountered by the PLCP." ::= { sipPortEntry 15 } ds3PLCPSEFS OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A DS3 Severely Errored Framing Second (SEFS) is a count of one-second intervals containing one or more SEF events. A Severely Errored Framing (SEF) event is declared when an error in the A1 octet and an error in the A2 octet of a framing octet pair (i.e., errors in both framing octets), or two consecutive invalid and/or nonsequential Path Overhead Identifier octets are detected." ::= { sipPortEntry 16 } ds3PLCPYellowSignal OBJECT-TYPE SYNTAX INTEGER { ds3PLCPYellowSignal(1), ds3PLCPNoYellowSignal(2) } ACCESS read-only STATUS mandatory DESCRIPTION "This variable indicates if a Yellow Signal is received. See TA-TSY-000773 [12]." ::= { sipPortEntry 17 } ds3PLCPRedAlarm OBJECT-TYPE SYNTAX INTEGER { ds3PLCPRedAlarm(1), ds3PLCPNoRedAlarm(2) } ACCESS read-only STATUS mandatory DESCRIPTION "This variable indicates if a Red Alarm condition Kaj Tesink (editor) [Page 13] Internet Draft SIP Objects November 1990 exists. A Red Alarm condition is sent when the declaration of a PLCP Loss of Frame failure condition occurs. See TA-TSY-000773 [12]." ::= { sipPortEntry 18 } ds3PLCPUASs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The counter associated with the number of Unavailable Seconds, as defined by [12], encountered by the PLCP." ::= { sipPortEntry 19 } END Kaj Tesink (editor) [Page 14] Internet Draft SIP Objects November 1990 7. Acknowledgments This document was produced by the SNMP Working Group: In addition, the comments of the following individuals are also acknowledged: Jeff Case, Tracy Cox, Steve Jaffe, Dave Piscitello, Ron Reuss, Marshall Rose. Kaj Tesink (editor) [Page 15] Internet Draft SIP Objects November 1990 8. References [1] V. Cerf, IAB Recommendations for the Development of Internet Network Management Standards. Internet Working Group Request for Comments 1052. Network Information Center, SRI International, Menlo Park, California, (April, 1988). [2] V. Cerf, Report of the Second Ad Hoc Network Management Review Group, Internet Working Group Request for Comments 1109. Network Information Center, SRI International, Menlo Park, California, (August, 1989). [3] M.T. Rose and K. McCloghrie, Structure and Identification of Management Information for TCP/IP-based internets, Internet Working Group Request for Comments 1155. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [4] K. McCloghrie and M.T. Rose, Management Information Base for Network Management of TCP/IP-based internets, Internet Working Group Request for Comments 1156. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, Simple Network Management Protocol, Internet Working Group Request for Comments 1157. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [6] M.T. Rose (editor), Management Information Base for Network Management of TCP/IP-based internets, Internet Working Group Request for Comments 1158. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [7] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [8] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules Kaj Tesink (editor) [Page 16] Internet Draft SIP Objects November 1990 for Abstract Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). [9] M.T. Rose, K. McCloghrie (editors), Towards Concise MIB Definitions, Internet Draft, Internet Engineering Task Force, (September, 1990). [10] M.T. Rose (editor), A Convention for Defining Traps for use with the SNMP, Internet Draft, Internet Engineering Task Force, (September, 1990). [11] Generic System Requirements in Support of Switched Multi-megabit Data Service, Bellcore Technical Advisory, TA-TSY-000772, Issue 3, October 1989. [12] Local Access System Generic Requirements, Objectives, and Interfaces in Support of Switched Multi-megabit Data Service, TA-TSY-000773, Issue 2, March 1990. [13] F. Baker and C. Kolb (editors), Definitions of Managed Objects for the T1 Carrier Interface Type, Internet Draft, Internet Engineering Task Force, (September, 1990). [14] T. A. Cox and K. Tesink (editors), Definitions of Managed Objects for the DS3 Interface Type, Internet Draft, Internet Engineering Task Force, (October, 1990). Kaj Tesink (editor) [Page 17] Internet Draft SIP Objects November 1990 Table of Contents 1 Status of this Memo ................................... 1 2 Abstract .............................................. 1 3 Historical Perspective ................................ 2 4 Objects ............................................... 4 4.1 Format of Definitions ............................... 4 5 Overview .............................................. 5 6 Object Definitions .................................... 6 7 Acknowledgments ....................................... 15 8 References ............................................ 16 Kaj Tesink (editor) [Page 18]