Network Working Group G. Bathrick Request for Comments: 2662 AG Communication Systems Category: Standards Track F. Ly Copper Mountain Networks August 1999 Definitions of Managed Objects for the ADSL Lines Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Table of Contents 1. Abstract .............................................. 1 2. The SNMP Network Management Framework ................. 2 3. Object Definitions ..................................... 3 4. Relationship of the ADSL LINE MIB with standard MIBs ... 3 5. Conventions used in the MIB ............................ 7 6. Conformance and Compliance ............................. 17 7. Definitions ............................................ 17 8. Acknowledgments ........................................ 110 9. References ............................................. 111 10. Security Considerations ................................ 113 11. Intellectual Property Notice ........................... 114 12. Authors' Addresses ..................................... 114 13. Full Copyright Statement ............................... 115 1. Abstract This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model [9]. The ADSL standard describes ATU-C and ATU-R as two sides of the ADSL line. This MIB covers both ATU-C and ATU-R agent's perspectives. Each instance defined in the MIB represents a single ADSL line. Bathrick & Ly Standards Track [Page 1] RFC 2662 ADSL Line MIB August 1999 It should be noted that the ADSL Forum Network Management Working Group provided input towards the content of this document. See the Acknowledgement Section for a list of individuals who made this document possible. 2. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [13]. o 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 STD 16, RFC 1155 [14], STD 16, RFC 1212 [15] and RFC 1215 [16]. The second version, called SMIv2, is described in STD 58, RFC 2578 [1], STD 58, RFC 2579 [2] and STD 58, RFC 2580 [17]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [7]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [18] and RFC 1906 [19]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [19], RFC 2572 [20] and RFC 2574 [21]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [7]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [8]. o A set of fundamental applications described in RFC 2573 [22] and the view-based access control mechanism described in RFC 2575 [23]. This document 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 (e.g., 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. Bathrick & Ly Standards Track [Page 2] RFC 2662 ADSL Line MIB August 1999 3. 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 extended 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 also refer to the object type. 4. Relationship of the ADSL LINE MIB with standard MIBs This section outlines the relationship of ADSL Line MIB with other MIBs described in RFCs and in their various degrees of "standardization". 4.1 Use of the IfTable The ADSL LINE MIB specifies the detailed attributes of a data interface. As such, it needs to integrate with IF-MIB [5]. The IANA has assigned the following ifType(s) relative to ADSL: IANAifType ::= TEXTUAL-CONVENTION . . . SYNTAX INTEGER { . . . adsl(94), -- Asymmetric Digital Subscriber Loop . . . adslInterleave(124), -- ADSL Interleaved Channel adslFast(125), -- ADSL Fast Channel . . . } Interfaces of each of these types are modeled by this document. Most MIB tables in this document represent information of one of these interface types and are indexed by ifIndex. Remaining are `profile' tables which may be accessed by the profileIndex. This is explained in more detail in section 5.4 Profiles. Bathrick & Ly Standards Track [Page 3] RFC 2662 ADSL Line MIB August 1999 4.1.1 ADSL Interface Types As shown below, three ADSL interface types are defined in this document, namely physical, interleaved channel, and fast channel. The physical interface represents characteristics of the physical media associated with both the ATUC and ATUR. The interleaved and fast channel interface represent the characteristics of the two types of ADSL channels. For each ADSL Line, a physical interface always exists. Depending on which ADSL operational configuration is present (as listed in Figure 5), the channel interfaces (fast or interleaved) may or may not exist. ______ ______ | |____________________| | | ATUC | | ATUR | | |____________________| | |______| |______| | <----- physical --------> | | <--- fast channel ------> | | <- interleaved channel -> | Figure 1: ADSL Model 4.1.2 Use of IF-MIB (Interface MIB RFC 2233) [5] The following attributes are part of the required ifGeneralInformationGroup object group specified in RFC 2233 [5], and are not duplicated in the ADSL MIB. Keep in mind that these objects apply to the agent's view of the line. Bathrick & Ly Standards Track [Page 4] RFC 2662 ADSL Line MIB August 1999 ifTable Object Use for ADSL ================================================================== ifIndex Interface index. ifDescr See interfaces MIB [5] ifType physical - adsl(94) fast - adslFast(125) interleaved - adslInterleave(124) ifSpeed Transmit rate from the perspective of the agent. physical - line rate fast - channel rate interleaved - channel rate ifPhysAddress This object should have an octet string with zero length. ifAdminStatus See interfaces MIB [5] ifOperStatus See interfaces MIB [5] Supplemented by adslAturCurrStatus and adslAturCurrStatus ifLastChange See interfaces MIB [5] ifName See interfaces MIB [5] ifLinkUpDownTrapEnable See interfaces MIB [5] Default set as follows: physical - enabled(1) fast - disabled(2) interleaved - disabled(2) ifHighSpeed Speed of line in Mega-bits per second (ifSpeed/1,000,000) ifConnectorPresent See interfaces MIB [5] Default set as follows: physical - true(1) fast - false(2) Bathrick & Ly Standards Track [Page 5] RFC 2662 ADSL Line MIB August 1999 interleaved - false(2) ifAlias See interfaces MIB [5] ifTableLastChange See interfaces MIB [5] ================================================================== Figure 2: Use of ifTable Objects: ifGeneralInformationGroup Use of the ifStackTable to associate the entries for physical, fast, interleaved channels, and higher layers (e.g., ATM) is shown below in figure 3. Use of ifStackTable is necessary, because configuration information is stored in profile tables associated with the physical-layer ifEntry only. The channels' ifEntrys need the ifStackTable to find their associated physical-layer entry and thus their configuration parameters. (See Profile section, 5.4). ______ (ifEntry=j) ______ | | fast channel | | | |________________________| | | | and/or | | | | | | | | (ifEntry=k) | | | | interleaved channel | | | |________________________| | | ATUC | | ATUR | | | | | | | (ifEntry=i) | | | | physical | | | |________________________| | |______| |______| Figure 3: Use of ifStackTable (part 1) The ifStackTable is then used to show the relationships between the various ADSL interfaces, as illustrated below in figure 4. HigherLayer LowerLayer -------------------------- j i k i Figure 4: Use of ifStackTable (part 2) The ifRcvAddressTable is not applicable for ADSL interfaces. Bathrick & Ly Standards Track [Page 6] RFC 2662 ADSL Line MIB August 1999 4.2 Relationship with RFC 2037 [25] Implementation of the Entity MIB [25] is optional. It in no way alters the information required in the adslLineMib, nor does it alter the relationship with IF-MIB. The Entity MIB introduces a standardized way of presenting the components of complex systems, such as a Digital Subscriber Line Access Multiplexer (DSLAM), that may contain multiple racks, shelves, line cards, and/or ports. The Entity MIB's main goal is to present these system components, their containment relationship, and mapping information with other MIBs such as the Interface MIB and the adslLineMib. If ATU-C agent is implemented, the Entity MIB should include entities for the ATU-C in the entPhysicalTable. The MIB's entAliasMappingTable would contain mapping information identifying the 'ifIndex' object associated with each ATU-C. However, if ATU-R agent is implemented, the Entity MIB should include entities for the ATU-R in the entPhysicalTable. In this case, the MIB's entAliasMappingTable would contain mapping information identifying the 'ifIndex' object associated with each ATU-R. Also associating the relationship between the ifTable and Entity MIB, the entPhysicalTable contains an 'entPhysicalName' object, which approximates the semantics of the 'ifName' object from the Interface MIB. 5. Conventions used in the MIB 5.1 Naming Conventions A. Atuc/Atur are used for the ATU-C and ATU-R. In other RFCs, these are sometimes referred to as the Near End (Ne) and Far End (Fe) respectively, but not in this document. B. The terms, "transmit" and "receive", are from the perspective of the corresponding table's end of the line. For example, in the case of Fast channels, adslAtucChanConfFastMaxTxRate defines the "downstream" rate, while adslAturChanConfFastMaxTxRate defines the "upstream" rate for a particular channel. C. There are two possible channels: fast, and interleaved. None, one or both may be implemented on a particular ADSL Line. Figure 5 illustrates all possible operational configurations. Bathrick & Ly Standards Track [Page 7] RFC 2662 ADSL Line MIB August 1999 D. Lof, Lol, Los, Lpr mean Loss of Framing, Link, Signal, and Power, respectively. Lpr is used by T1E1, so it is used for consistency (rather than Lop). A Loss of Link condition is declared at the ATU-C if a Loss of Signal is not preceded by a `dying-gasp' message from the ATU-R. Note that Loss of Link is only supported by the ATU-C. E. ES means errored second. An Errored Second is any second containing one or more CRC anomaly, or one or more Los(s) or Severely Errored Frame (Sef) defect(s). F. A "block" is a physical-layer `data buffer' over which CRCs are calculated. For example, in DMT, the block is defined as the ADSL superframe. The block duration is 250 micro-seconds so the block length in bytes, as defined in adslAtu*ChanCrcBlockLength, varies with data rate. See Line Code Specific MIBs [11] [12] for more line code specific information. G. Atn means Attenuation, Psd is Power Spectral Density and Snr is Signal to Noise Ratio. H. LCS means line code specific, e.g., o DMT = Discrete MultiTone o CAP = Carrierless Amplitude and Phase modulation and o QAM = Quadrature Amplitude Modulation I. Vendor (in the Inventory objects) refers to the manufacturer of the ATU-C or ATU-R assembly, not the modem chip vendor. When in doubt, use the manufacturer of the smallest field replaceable unit (e.g., stand-alone modem box, plug-in board). J. RADSL - Rate Adaptive Asymmetric Digital Subscriber Loop 5.2 Structure The MIB has multiple parallel tables. There are tables for: o line - common attribute