Network Working Group M. Morgenstern Internet-Draft ECI Telecom Ltd. Intended status: Standards Track S. Baillie Expires: August 29, 2007 U. Bonollo NEC Australia February 25, 2007 Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) draft-ietf-adslmib-vdsl2-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on August 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines a Management Information Base (MIB) module for use with network management protocols in the IfQueueBlockernet community. In particular, it describes objects used for managing parameters of the "Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type, which are also applicable for managing ADSL, ADSL2, Morgenstern, et al. Expires August 29, 2007 [Page 1] Internet-Draft VDSL2-LINE MIB February 2007 and ADSL2+ interfaces. Table of Contents 1. The Internet-Standard Management Framework . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Relationship to other MIBs . . . . . . . . . . . . . . . 4 2.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 6 2.3. Conventions Used in the MIB Module . . . . . . . . . . . 7 2.4. Structure . . . . . . . . . . . . . . . . . . . . . . . . 16 2.5. Persistence . . . . . . . . . . . . . . . . . . . . . . . 18 2.6. Line Topology . . . . . . . . . . . . . . . . . . . . . . 21 2.7. Counters, Interval Buckets, and Thresholds . . . . . . . 22 2.8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . 24 2.9. Notifications . . . . . . . . . . . . . . . . . . . . . . 28 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 29 4. Implementation Analysis . . . . . . . . . . . . . . . . . . . 182 5. Security Considerations . . . . . . . . . . . . . . . . . . . 182 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 190 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 191 7.1. Normative References . . . . . . . . . . . . . . . . . . 191 7.2. Informative References . . . . . . . . . . . . . . . . . 192 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 192 Intellectual Property and Copyright Statements . . . . . . . . . 194 Morgenstern, et al. Expires August 29, 2007 [Page 2] Internet-Draft VDSL2-LINE MIB February 2007 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 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 [RFC2119]. 2. Overview This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community for the purpose of managing VDSL2, ADSL, ADSL2, and ADSL2+ lines. The MIB module described in RFC 2662 [RFC2662] describes objects used for managing Asymmetric Bit-Rate DSL (ADSL) interfaces per [T1E1.413], [G.992.1], and [G.992.2]. These object descriptions are based upon the specifications for the ADSL Embedded Operations Channel (EOC) as defined in American National Standards Institute (ANSI) T1E1.413/1995 [T1E1.413] and International Telecommunication Union (ITU-T) G.992.1 [G.992.1] and G.992.2 [G.992.2]. The MIB module described in RFC 4706 [RFC4706] is a wider management model that includes, in addition to ADSL technology, the ADSL2 and ADSL2+ technologies per G.992.3, G.992.4, and G.992.5 ([G.992.3], [G.992.4], and [G.992.5] respectively). This document does not obsolete RFC 2662 [RFC2662], or RFC 4706 [RFC4706] but rather provides a more comprehensive management model that addresses the VDSL2 technology per G.993.2 ([G.993.2]) as well as ADSL, ADSL2 and ADSL2+ technologies. Additionally, the management framework for VDSL2 lines [TR-129] specified by the Digital Subscriber Line Forum (DSLF) has been taken into consideration. That framework is based on ITU-T G.997.1 standard [G.997.1]. Morgenstern, et al. Expires August 29, 2007 [Page 3] Internet-Draft VDSL2-LINE MIB February 2007 Note that the management model according to this document does not allow managing VDSL technology per G.993.1 ([G.993.1]). VDSL lines MUST be managed by RFC 3728 [RFC3728]. The MIB module is located in the MIB tree under MIB 2 transmission, as discussed in the MIB-2 Integration (RFC 2863 [RFC2863]) section of this document. 2.1. Relationship to other MIBs This section outlines the relationship of this MIB module with other MIB modules described in RFCs. Specifically, IF-MIB as presented in RFC 2863 [RFC2863] is discussed. 2.1.1. General IF-MIB Integration (RFC 2863) The VDSL2 Line MIB specifies the detailed attributes of a data interface. As such, it needs to integrate with RFC 2863 [RFC2863]. The IANA has assigned the following ifTypes, which may be applicable for VDSL2 lines as well as for ADSL, ADSL2 and ADSL2+ lines: IANAifType ::= TEXTUAL-CONVENTION ... SYNTAX INTEGER { ... channel(70), -- Channel adsl(94), -- Asymmetric Digital Subscriber Loop ... interleave(124), -- Interleaved Channel fast(125), -- Fast Channel ... adsl2plus(238), -- Asymmetric Digital Subscriber Loop Version 2, Version 2 Plus, and all variants vdsl2(xxx), -- Very High Speed Digital Subscriber Loop 2 ... } ADSL lines that are identified with ifType=adsl(94) MUST be managed with the MIB specified by RFC2662. ADSL, ADSL2, and ADSL2+ lines identified with ifType=adsl2plus(238) MUST be managed with the MIB specified by RFC 4706 [RFC4706]. VDSL2, ADSL, ADSL2, and ADSL2+ lines identified with ifType=vdsl2(xxx) MUST be managed with the MIB specified by this document. In any case, the SNMP agent may use either ifType=interleave(124) or fast(125) for each channel, e.g., depending on whether or not it is capable of using an interleaver on that channel. It may use the ifType=channel (70) when all channels are capable of using an Morgenstern, et al. Expires August 29, 2007 [Page 4] Internet-Draft VDSL2-LINE MIB February 2007 interleaver (e.g., for ADSL2 xtus). Note that the ifFixedLengthGroup from RFC 2863 [RFC2863] MUST be supported and that the ifRcvAddressGroup does not apply to this MIB module. 2.1.2. Usage of ifTable The MIB branch identified by ifType contains tables appropriate for the interface types described above. Most such tables extend the ifEntry table, and are indexed by ifIndex. For interfaces in systems implementing this MIB module, those table entries indexed by ifIndex MUST be persistent. The following attributes are part of the mandatory ifGeneralInformationGroup in the Interfaces MIB [RFC2863], and are not duplicated in the VDSL2 Line MIB. =================================================================== Morgenstern, et al. Expires August 29, 2007 [Page 5] Internet-Draft VDSL2-LINE MIB February 2007 ifIndex Interface index. ifDescr See interfaces MIB. ifType vdsl2(xxx) or channel(70) or interleave(124) or fast(125) ifSpeed Set as appropriate. ifPhysAddress This object MUST have an octet string with zero length. ifAdminStatus See interfaces MIB. ifOperStatus See interfaces MIB. ifLastChange See interfaces MIB. ifName See interfaces MIB. ifAlias See interfaces MIB. ifLinkUpDownTrapEnable Default to enabled(1). ifHighSpeed Set as appropriate. ifConnectorPresent Set as appropriate. =================================================================== Figure 1: Use of ifTable Objects 2.2. IANA Considerations The VDSL2-LINE-MIB module requires the allocation of a new ifType value for Very High Speed Digital Subscriber Loop Version 2, to distinguish between ADSL lines that are managed with the RFC2662 management model, ADSL/ADSL2 and ADSL2+ lines that are managed with the RFC 4706 [RFC4706] management model, and VDSL2/ADSL/ADSL2 and ADSL2+ lines that are managed with the model defined in this document. Also the VDSL2-LINE-MIB module requires the allocation of a single object identifier for its MODULE-IDENTITY. The IANA should allocate this object identifier in the transmission subtree. Morgenstern, et al. Expires August 29, 2007 [Page 6] Internet-Draft VDSL2-LINE MIB February 2007 2.3. Conventions Used in the MIB Module 2.3.1. Naming Conventions atuc ADSL/ADSL2 or ADSL2+ line termination unit - Central office atur ADSL/ADSL2 or ADSL2+ line termination unit - Remote site CRC Cyclical redundancy check DELT Dual Ended Loop Test ES Errored second FEC Forward Error Correction LOF Loss of framing LOS Loss of signal LOSS LOS Second PTM Packet transfer mode SES Severely-errored second SNR Signal-to-noise ratio UAS Unavailable second US0 Upstream band number 0 vtuc VDSL2 line termination unit - Central office vtur VDSL2 line termination unit - Remote site Xtuc ADSL/ADSL2/ADSL2+ or VDSL2 line termination unit - Central office Xtur ADSL/ADSL2/ADSL2+ or VDSL2 line termination unit - Remote site xtu A terminal unit; either an Xtuc or Xtur 2.3.2. Textual Conventions The following textual conventions are defined to reflect the line topology in the MIB module (further discussed in the following section), the various transmission modes, power states, synchronization states, possible values for various configuration parameters, status parameters, and other parameter types. o Xdsl2Unit: Attributes with this syntax uniquely identify each unit in the VDSL2/ADSL/ADSL2/ADSL2+ link. It mirrors the EOC addressing mechanism: xtuc(1) - central office (CO) terminal unit xtur(2) - customer premises equipment (CPE) terminal unit Morgenstern, et al. Expires August 29, 2007 [Page 7] Internet-Draft VDSL2-LINE MIB February 2007 o Xdsl2Direction: Attributes with this syntax uniquely identify a transmission direction in a VDSL2/ADSL/ADSL2/ADSL2+ link. The upstream direction is a transmission from the remote end (xTU-R) towards the central office end (xTU-C). The upstream direction is indicated by upstream(1). The downstream direction is a transmission from the xTU-C towards the xTU-R. The downstream direction is indicated by downstream(2). upstream(1) - Transmission from the xTU-R to the xTU-C. downstream(2) - Transmission from the xTU-C to the xTU-R. o Xdsl2Band: Attributes with this syntax uniquely identify a band in a VDSL2/ ADSL/ADSL2/ADSL2+ link. For a band in the upstream direction, transmission is from the remote end (xTU-R) towards the central office end (xTU-C). A band in the upstream direction is indicated by upstream(1) for ADSL/ADSL2/ADSL2+ single band, or any of us0(3), us1(5), us2(7), us3(9), or us4(11) for VDSL2 multiple bands. For a band in the downstream direction, transmission is from the xTU-C towards the xTU-R. A band in the downstream direction is indicated by downstream(2) for ADSL/ADSL2/ADSL2+ single band, or any of ds1(4), ds2(6), ds3(8), or ds4(10) for VDSL2 multiple bands. upstream(1) - Transmission from the ATU-R to the ATU-C (ADSL/ADSL2/ADSL2+). downstream(2) - Transmission from the ATU-C to the ATU-R (ADSL/ADSL2/ADSL2+). us0(3) - Upstream band number 0 (US0) (VDSL2). ds1(4) - Downstream band number 1 (DS1) (VDSL2). us1(5) - Upstream band number 1 (US1) (VDSL2). ds2(6) - Downstream band number 2 (DS2) (VDSL2). us2(7) - Upstream band number 2 (US2) (VDSL2). ds3(8) - Downstream band number 3 (DS3) (VDSL2). us3(9) - Upstream band number 3 (US3) (VDSL2). ds4(10) - Downstream band number 4 (DS4) (VDSL2). us4(11) - Upstream band number 4 (US4) (VDSL2). o Xdsl2TransmissionModeType: Attributes with this syntax reference the list of possible transmission modes for VDSL2/ADSL/ADSL2 or ADSL2+. Specified as a BITS construct, there are currently a few dozen Morgenstern, et al. Expires August 29, 2007 [Page 8] Internet-Draft VDSL2-LINE MIB February 2007 transmission modes in the list. o Xdsl2RaMode: Attributes with this syntax reference if and how Rate-Adaptive synchronization is being used on the respective VDSL2/ADSL/ADSL2 or ADSL2+ link: manual (1) - No Rate-Adaptation. The initialization process attempts to synchronize to a specified rate. raInit (2) - Rate-Adaptation during initialization process only, which attempts to synchronize to a rate between minimum and maximum specified values. dynamicRa (3) - Dynamic Rate-Adaptation during initialization process as well as during SHOWTIME. o Xdsl2InitResult: Attributes with this syntax reference the recent result of a full initialization attempt: noFail (0) - Successful initialization configError (1) - Configuration failure configNotFeasible (2) - Configuration details not supported commFail (3) - Communication failure noPeerAtu (4) - Peer ATU not detected otherCause (5) - Other initialization failure reason o Xdsl2OperationModes: Attributes with this syntax uniquely identify an ADSL mode, which is a category associated with each transmission mode defined for the VDSL2/ADSL/ADSL2 or ADSL2+ link. Part of the line configuration profile depends on the ADSL Mode: Specified as an enumeration construct, there are currently a few dozen transmission modes in the list. o Xdsl2PowerMngState: Attributes with this syntax uniquely identify each power management state defined for the VDSL2/ADSL/ADSL2 or ADSL2+ link. For VDSL2 links only L0 and L3 states are supported: l0(1) - L0 - Full power management state l1(2) - L1 - Low power management state (for G.992.2) l2(3) - L2 - Low power management state (for G.992.3, G.992.4, and G.992.5) Morgenstern, et al. Expires August 29, 2007 [Page 9] Internet-Draft VDSL2-LINE MIB February 2007 l3(4) - L3 - Idle power management state o Xdsl2ConfPmsForce: Attributes with this syntax are configuration parameters that reference the desired power management state for the VDSL2/ADSL/ ADSL2 or ADSL2+ link. For VDSL2 links only L0 and L3 states are supported: l3toL0 (0) - Perform a transition from L3 to L0 (Full power management state) l0toL2 (2) - Perform a transition from L0 to L2 (Low power management state) l0orL2toL3 (3) - Perform a transition into L3 (Idle power management state) o Xdsl2LinePmMode: Attributes with this syntax are configuration parameters that reference the power modes/states into which the xTU-C or xTU-R may autonomously transit. This is a BITS structure that allows control of the following transit options: allowTransitionsToIdle (0) - xTU may autonomously transit to idle (L3) state. allowTransitionsToLowPower (1)- xTU may autonomously transit to low-power (L1/L2) state. o Xdsl2LineLdsf: Attributes with this syntax are configuration parameters that control the Loop Diagnostic mode for the VDSL2/ADSL/ADSL2 or ADSL2+ link: inhibit (0) - Inhibit Loop Diagnostic mode force (1) - Force/Initiate Loop Diagnostic mode o Xdsl2LdsfResult: Attributes with this syntax are status parameters that report the result of the recent Loop Diagnostic mode issued for the VDSL2/ ADSL/ADSL2 or ADSL2+ link: Morgenstern, et al. Expires August 29, 2007 [Page 10] Internet-Draft VDSL2-LINE MIB February 2007 none (1) - The default value, in case LDSF was never requested for the associated line. success (2) - The recent command completed successfully. inProgress (3) - The Loop Diagnostics process is in progress. unsupported (4) - The NE or the line card doesn't support LDSF. cannotRun (5) - The NE cannot initiate the command, due to a non specific reason. aborted (6) - The Loop Diagnostics process aborted. failed (7) - The Loop Diagnostics process failed. illegalMode (8) - The NE cannot initiate the command, due to the specific mode of the relevant line. adminUp (9) - The NE cannot initiate the command because the relevant line is administratively 'Up'. tableFull (10) - The NE cannot initiate the command, due to reaching the maximum number of rows in the results table. noResources (11) - The NE cannot initiate the command, due to lack of internal memory resources. o Xdsl2LineProfiles: Attributes with this syntax reference the list of supported, enabled or active ITU-T G.993.2 implementation profiles. This is a BITS structure with the following values: profile8a (0) - Profile 8a profile8b (1) - Profile 8b profile8c (2) - Profile 8c profile8d (3) - Profile 8d profile12a (4) - Profile 12a profile12b (5) - Profile 12b profile17a (6) - Profile 17a profile30a (7) - Profile 30a o Xdsl2LineClassMask: Attributes with this syntax are configuration parameters that specify the VDSL2 PSD Mask Class for a selected VDSL2 transmission mode. The following classes are defined: Morgenstern, et al. Expires August 29, 2007 [Page 11] Internet-Draft VDSL2-LINE MIB February 2007 none (1) - VDSL2 PSD Mask Class is unknown/irrelevant. a998ORb997M1cORc998 (2) - For ITU-T G.993.2 Annex A and C this is the only applicable PSD class. ITU-T G.993.2 Annex B: 997-M1c-A-7 b997M1x (3) - ITU-T G.993.2 Annex B: 997-M1x-M-8 or 997-M1x-M b997M2x (4) - ITU-T G.993.2 Annex B: 998-M1x-A, 998-M1x-B, or 997-M2x-M b998M1x (5) - ITU-T G.993.2 Annex B: 997-M2x-M-8, 997-M2x-A, or 998-M1x-NUS0 b998M2x (6) - ITU-T G.993.2 Annex B: 998-M2x-A, 998-M2x-M, 998-M2x-B, or 998-M2x-NUS0 o Xdsl2LineLimitMask: Attributes with this syntax are configuration parameters that specify the VDSL2 PSD Limit Mask for each PSD Mask Class and implementation profile. The VDSL2 implementation profiles are grouped into 4 classes and each is allocated 16 PSD Limit Mask values in this textual convention. o Xdsl2LineUs0Disable: Attributes with this syntax are configuration parameters that indicate if US0 (upstream band number 0) is disabled for each limit PSD mask. The VDSL2 implementation profiles are grouped into 4 classes and each is allocated 16 values in this textual convention. o Xdsl2LineUs0Mask: Attributes with this syntax are configuration parameters for ITU-T G.993.2 Annex A transmission mode that specify the US0 PSD masks to be allowed by the near-end xTU on the line. It is a bit map that supports 18 possible US0 masks. o Xdsl2SymbolProtection: Attributes with this syntax are configuration parameters that reference the minimum length impulse noise protection (INP) in terms of number of symbols: Morgenstern, et al. Expires August 29, 2007 [Page 12] Internet-Draft VDSL2-LINE MIB February 2007 noProtection (1) - INP not required halfSymbol (2) - INP length = 1/2 symbol singleSymbol (3) - INP length = 1 symbol twoSymbols (4) - INP length = 2 symbols threeSymbols (5) - INP length = 3 symbols fourSymbols (6) - INP length = 4 symbols fiveSymbols (7) - INP length = 5 symbols sixSymbols (8) - INP length = 6 symbols sevenSymbols (9) - INP length = 7 symbols eightSymbols (10) - INP length = 8 symbols nineSymbols (11) - INP length = 9 symbols tenSymbols (12) - INP length = 10 symbols elevenSymbols (13) - INP length = 11 symbols twelveSymbols (14) - INP length = 12 symbols thirteeSymbols (15)- INP length = 13 symbols fourteenSymbols (16)-INP length = 14 symbols fifteenSymbols (17)- INP length = 15 symbols sixteenSymbols (18)- INP length = 16 symbols o Xdsl2MaxBer: Attributes with this syntax are configuration parameters that reference the maximum Bit Error Rate (BER): eminus3 (1) - Maximum BER=E^-3 eminus5 (2) - Maximum BER=E^-5 eminus7 (3) - Maximum BER=E^-7 o Xdsl2ScMaskDs: Attributes with this syntax are configuration parameters that reference the downstream sub-carrier mask. It is a bitmap of up to 4096 bits. o Xdsl2ScMaskUs: Attributes with this syntax are configuration parameters that reference the upstream sub- carrier mask. It is a bitmap of up to 4096 bits. o Xdsl2CarMask: Attributes with this syntax is a configuration parameter for VDSL2 transmission modes that defines an array of up to 32 bands. Each band is represented by a start subcarrier index followed by a stop subcarrier index. Morgenstern, et al. Expires August 29, 2007 [Page 13] Internet-Draft VDSL2-LINE MIB February 2007 o Xdsl2PsdMaskDs: Attributes with this syntax are configuration parameters that reference the downstream power spectrum density (PSD) mask. It is a structure of up to 32 breakpoints, where each breakpoint occupies 3 octets. o Xdsl2PsdMaskUs: Attributes with this syntax are configuration parameters that reference the upstream power spectrum density (PSD) mask. It is a structure of up to 16 breakpoints, where each breakpoint occupies 3 octets. o Xdsl2Tssi: Attributes with this syntax are status parameters that reference the transmit spectrum shaping (TSSi). It is a structure of up to 32 breakpoints, where each breakpoint occupies 3 octets. o Xdsl2LastTransmittedState: Attributes with this syntax reference the list of initialization states for VDSL2/ADSL/ADSL2 or ADSL2+ modems. The list of states for CO side modems is different from the list of states for the CPE side modems. Specified as an enumeration type, there are currently a few dozen states in the list per each unit side (i.e., CO and CPE). o Xdsl2LineStatus: Attributes with this syntax are status parameters that reflect the failure status for a given endpoint of VDSL2/ADSL/ADSL2 or ADSL2+ link. This is a BITS structure that can report the following failures: noDefect (0) - This bit position positively reports that no defect or failure exist. lossOfFraming (1) - Loss of frame synchronization lossOfSignal (2) - Loss of signal lossOfPower (3) - Loss of power. Usually this failure may be reported for CPE units only initFailure (4) - Recent initialization process failed. Never active on xTU-R. Morgenstern, et al. Expires August 29, 2007 [Page 14] Internet-Draft VDSL2-LINE MIB February 2007 o Xdsl2ChAtmStatus: Attributes with this syntax are status parameters that reflect the failure status for Transmission Convergence (TC) layer of a given ATM interface (data path over a VDSL2/ADSL/ADSL2 or ADSL2+ link). This is a BITS structure that can report the following failures: noDefect (0) - This bit position positively reports that no defect or failure exist. noCellDelineation (1) - The link was successfully initialized but cell delineation was never acquired on the associated ATM data path. lossOfCellDelineation (2)- Loss of cell delineation on the associated ATM data path o Xdsl2ChPtmStatus: Attributes with this syntax are status parameters that reflect the failure status for a given PTM interface (packet data path over a VDSL2/ADSL/ADSL2 or ADSL2+ link). This is a BITS structure that can report the following failures: noDefect (0) - This bit position positively reports that no defect or failure exist. outOfSync (1) - Out of synchronization. o Xdsl2UpboKLF: Attributes with this syntax are configuration parameters referring to whether or not upstream power backoff (UPBO) is enabled and how electrical length in the context of UPBO is determined. This enumeration type can have the following values: auto(1) - The VTUs autonomously determine the electrical length. override(2) - Forces the VTU-R to use the electrical length, kl0, of the CO-MIB (UPBOKL) to compute the UPBO. disableUpbo(3) - Disables UPBO. I.e., UPBO is not utilized. Morgenstern, et al. Expires August 29, 2007 [Page 15] Internet-Draft VDSL2-LINE MIB February 2007 o Xdsl2BandUs: Attributes with this syntax are used as table indexes that refer to upstream bands of VDSL2 lines (Excluding US0 band.). This enumeration type can have the following values: us1(5) - Upstream band number 1 (US1). us2(7) - Upstream band number 2 (US2). us3(9) - Upstream band number 3 (US3). us4(11) - Upstream band number 4 (US4). 2.4. Structure The MIB module is structured into following MIB groups: o Line Configuration, Maintenance, and Status Group: This group supports MIB objects for configuring parameters for the VDSL2/ADSL/ADSL2 or ADSL2+ line and retrieving line status information. It also supports MIB objects for configuring a requested power state or initiating a Dual Ended Line Test (DELT) process in the VDSL2/ADSL/ADSL2 or ADSL2+ line. It contains the following tables: - xdsl2LineTable - xdsl2LineBandTable o Channel Status Group: This group supports MIB objects for retrieving channel layer status information. It contains the following table: - xdsl2ChannelStatusTable o Subcarrier Status Group: This group supports MIB objects for retrieving the sub-carrier layer status information, mostly collected by a Dual Ended Line Test (DELT) process. It contains the following tables: - xdsl2SCStatusTable - xdsl2SCStatusBandTable - xdsl2SCStatusSegmentTable o Unit Inventory Group: This group supports MIB objects for retrieving Unit inventory Morgenstern, et al. Expires August 29, 2007 [Page 16] Internet-Draft VDSL2-LINE MIB February 2007 information about units in VDSL2/ADSL/ADSL2 or ADSL2+ lines via the EOC. It contains the following table: - xdsl2LineInventoryTable o Current Performance Group: This group supports MIB objects that provide the current performance information relating to VDSL2/ADSL/ADSL2 and ADSL2+ line, units and channels level. It contains the following tables: - xdsl2PMLineCurrTable - xdsl2PMLineCurrInitTable - xdsl2PMChCurrTable o 15-Minute Interval Performance Group: This group supports MIB objects that provide historic performance information relating to VDSL2/ADSL/ADSL2 and ADSL2+ line, units and channels level in 15- minute intervals. It contains the following tables: - xdsl2PMLineHist15MinTable - xdsl2PMLineInitHist15MinTable - xdsl2PMChHist15MinTable o 1-Day Interval Performance Group: This group supports MIB objects that provide historic performance information relating to VDSL2/ADSL/ADSL2 and ADSL2+ line, units and channels level in 1-day intervals. It contains the following tables: - xdsl2PMLineHist1DayTable - xdsl2PMLineInitHist1DayTable - xdsl2PMChHist1DTable o Configuration Template and Profile Group: This group supports MIB objects for defining configuration profiles for VDSL2/ADSL/ADSL2 and ADSL2+ lines and channels, as well as configuration templates. Each configuration template is comprised of one line configuration profile and one or more channel configuration profiles. This group contains the following tables: Morgenstern, et al. Expires August 29, 2007 [Page 17] Internet-Draft VDSL2-LINE MIB February 2007 - xdsl2LineConfTemplateTable - xdsl2LineConfProfTable - xdsl2LineConfProfModeSpecTable - xdsl2LineConfProfModeSpecBandUsTable - xdsl2ChConfProfileTable o Alarm Configuration Template and Profile Group: This group supports MIB objects for defining alarm profiles for VDSL2/ADSL/ADSL2 and ADSL2+ lines and channels, as well as alarm templates. Each alarm template is comprised of one line alarm profile and one or more channel alarm profiles. This group contains the following tables: - xdsl2LineAlarmConfTemplateTable - xdsl2LineAlarmConfProfileTable - xdsl2ChAlarmConfProfileTable o Notifications Group: This group defines the notifications supported for VDLS2/ADSL/ ADSL2 and ADSL2+ lines: - xdsl2LinePerfFECSThreshXtuc - xdsl2LinePerfFECSThreshXtur - xdsl2LinePerfESThreshXtuc - xdsl2LinePerfESThreshXtur - xdsl2LinePerfSESThreshXtuc - xdsl2LinePerfSESThreshXtur - xdsl2LinePerfLOSSThreshXtuc - xdsl2LinePerfLOSSThreshXtur - xdsl2LinePerfUASThreshXtuc - xdsl2LinePerfUASThreshXtur - xdsl2LinePerfCodingViolationsThreshXtuc - xdsl2LinePerfCodingViolationsThreshXtur - xdsl2LinePerfCorrectedThreshXtuc - xdsl2LinePerfCorrectedThreshXtur - xdsl2LinePerfFailedFullInitThresh - xdsl2LinePerfFailedShortInitThresh - xdsl2LineStatusChangeXtuc - xdsl2LineStatusChangeXtur 2.5. Persistence All read-create objects and most read-write objects defined in this MIB module SHOULD be stored persistently. Following is an exhaustive list of these persistent objects: ------***************************************************** ------The Morgenstern, et al. Expires August 29, 2007 [Page 18] Internet-Draft VDSL2-LINE MIB February 2007 following list will probably be partially changed ------***************************************************** xdsl2LineCnfgTemplate xdsl2LineAlarmCnfgTemplate xdsl2LineCmndConfPmsf xdsl2LConfTempTemplateName xdsl2LConfTempLineProfile xdsl2LConfTempChan1ConfProfile xdsl2LConfTempChan1RaRatioDs xdsl2LConfTempChan1RaRatioUs xdsl2LConfTempChan2ConfProfile xdsl2LConfTempChan2RaRatioDs xdsl2LConfTempChan2RaRatioUs xdsl2LConfTempChan3ConfProfile xdsl2LConfTempChan3RaRatioDs xdsl2LConfTempChan3RaRatioUs xdsl2LConfTempChan4ConfProfile xdsl2LConfTempChan4RaRatioDs xdsl2LConfTempChan4RaRatioUs xdsl2LConfTempRowStatus xdsl2LConfProfProfileName xdsl2LConfProfScMaskDs xdsl2LConfProfScMaskUs xdsl2LConfProfVdsl2CarMask xdsl2LConfProfRfiBandsDs xdsl2LConfProfRaModeDs xdsl2LConfProfRaModeUs xdsl2LConfProfRaUsNrmDs xdsl2LConfProfRaUsNrmUs xdsl2LConfProfRaUsTimeDs xdsl2LConfProfRaUsTimeUs xdsl2LConfProfRaDsNrmsDs xdsl2LConfProfRaDsNrmsUs xdsl2LConfProfRaDsTimeDs xdsl2LConfProfRaDsTimeUs xdsl2LConfProfTargetSnrmDs xdsl2LConfProfTargetSnrmUs xdsl2LConfProfMaxSnrmDs xdsl2LConfProfMaxSnrmUs xdsl2LConfProfMinSnrmDs xdsl2LConfProfMinSnrmUs xdsl2LConfProfMsgMinUs xdsl2LConfProfMsgMinDs xdsl2LConfProfXtuTransSysEna xdsl2LConfProfPmMode xdsl2LConfProfL0Time xdsl2LConfProfL2Time Morgenstern, et al. Expires August 29, 2007 [Page 19] Internet-Draft VDSL2-LINE MIB February 2007 xdsl2LConfProfL2Atpr xdsl2LConfProfL2Atprt xdsl2LConfProfProfiles xdsl2LConfProfDpboEPsd xdsl2LConfProfDpboEsEL xdsl2LConfProfDpboEsCableModelA xdsl2LConfProfDpboEsCableModelB xdsl2LConfProfDpboEsCableModelC xdsl2LConfProfDpboMus xdsl2LConfProfDpboFMin xdsl2LConfProfDpboFMax xdsl2LConfProfUpboKL xdsl2LConfProfUpboKLF xdsl2LConfProfUs0Mask xdsl2LConfProfRowStatus xdsl2LConfProfXdslMode xdsl2LConfProfMaxNomPsdDs xdsl2LConfProfMaxNomPsdUs xdsl2LConfProfMaxNomAtpDs xdsl2LConfProfMaxNomAtpUs xdsl2LConfProfMaxAggRxPwrUs xdsl2LConfProfPsdMaskDs xdsl2LConfProfPsdMaskUs xdsl2LConfProfPsdMaskSelectUs xdsl2LConfProfClassMask xdsl2LConfProfLimitMask xdsl2LConfProfUs0Disabl xdsl2LConfProfModeSpecRowStatus xdsl2LConfProfXdslBandUs xdsl2LConfProfUpboPsdA xdsl2LConfProfUpboPsdB xdsl2LConfProfModeSpecBandUsRowStatus xdsl2ChConfProfProfileName xdsl2ChConfProfMinDataRateDs xdsl2ChConfProfMinDataRateUs xdsl2ChConfProfMinResDataRateDs xdsl2ChConfProfMinResDataRateUs xdsl2ChConfProfMaxDataRateDs xdsl2ChConfProfMaxDataRateUs xdsl2ChConfProfMinDataRateLowPwrDs xdsl2ChConfProfMaxDelayDs xdsl2ChConfProfMaxDelayUs xdsl2ChConfProfMinProtectionDs xdsl2ChConfProfMinProtectionUs xdsl2ChConfProfMaxBerDs xdsl2ChConfProfMaxBerUs xdsl2ChConfProfUsDataRateDs xdsl2ChConfProfDsDataRateDs Morgenstern, et al. Expires August 29, 2007 [Page 20] Internet-Draft VDSL2-LINE MIB February 2007 xdsl2ChConfProfUsDataRateUs xdsl2ChConfProfDsDataRateUs xdsl2ChConfProfImaEnabled xdsl2ChConfProfRowStatus xdsl2LAlarmConfTempTemplateName xdsl2LAlarmConfTempLineProfile xdsl2LAlarmConfTempChan1ConfProfile xdsl2LAlarmConfTempChan2ConfProfile xdsl2LAlarmConfTempChan3ConfProfile xdsl2LAlarmConfTempChan4ConfProfile xdsl2LAlarmConfTempRowStatus xdsl2LineAlarmConfProfileName xdsl2LineAlarmConfProfileXtucThresh15MinFecs xdsl2LineAlarmConfProfileXtucThresh15MinEs xdsl2LineAlarmConfProfileXtucThresh15MinSes xdsl2LineAlarmConfProfileXtucThresh15MinLoss xdsl2LineAlarmConfProfileXtucThresh15MinUas xdsl2LineAlarmConfProfileXturThresh15MinFecs xdsl2LineAlarmConfProfileXturThresh15MinEs xdsl2LineAlarmConfProfileXturThresh15MinSes xdsl2LineAlarmConfProfileXturThresh15MinLoss xdsl2LineAlarmConfProfileXturThresh15MinUas xdsl2LineAlarmConfProfileThresh15MinFailedFullInt xdsl2LineAlarmConfProfileThresh15MinFailedShrtInt xdsl2LineAlarmConfProfileRowStatus xdsl2ChAlarmConfProfileName xdsl2ChAlarmConfProfileXtucThresh15MinCodingViolations xdsl2ChAlarmConfProfileXtucThresh15MinCorrected xdsl2ChAlarmConfProfileXturThresh15MinCodingViolations xdsl2ChAlarmConfProfileXturThresh15MinCorrected xdsl2ChAlarmConfProfileRowStatus Note also that the interface indices in this MIB are maintained persistently. View-based Access Control Model (VACM) data relating to these SHOULD be stored persistently as well [RFC3410]. 2.6. Line Topology A VDSL2/ADSL/ADSL2 and ADSL2+ Line consists of two units: atuc or vtuc (a central office termination unit) and atur or vtur (a remote termination unit). There are up to 4 channels (maximum number of channels depends on the specific DSL technology), each carrying an independent information flow, as shown in the figure below. Morgenstern, et al. Expires August 29, 2007 [Page 21] Internet-Draft VDSL2-LINE MIB February 2007 <-- Network Side Customer Side --> || +-------+ +-------+ + |<---------------------1------------------->| + + atuc |<---------------------2------------------->| atur + | or <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| or | + vtuc |<---------------------3------------------->| vtuc + + |<---------------------4------------------->| + +-------+ +-------+ Key: VDSL2/ADSL/ADSL2/ADSL2+ Span <~~~~> VDSL2/ADSL/ADSL2/ADSL2+ twisted-pair -1- Channel #1 carried over the line -2- Optional channel #2 carried over the line -3- Optional channel #3 carried over the line -4- Optional channel #4 carried over the line Figure 2: General topology for a VDSL2/ADSL/ADSL2/ADSL2+ Line 2.7. Counters, Interval Buckets, and Thresholds 2.7.1. Counters Managed There are various types of counters specified in this MIB. Each counter refers either to the whole VDSL2/ADSL/ADSL2/ADSL2+ line, to one of the xtu entities, or to one of the bearer channels. o On the whole line level For full initializations, failed full initializations, short initializations, and for failed short initializations there are event counters, current 15-minute and 0 to 96 15-minute history bucket(s) of "interval-counters", as well as current and 0 to 30 previous 1-day interval-counter(s). Each current 15- minute "failed" event bucket has an associated threshold notification. o On the xtu level For the LOS Seconds, ES, SES, FEC seconds, and UAS, there are event counters, current 15-minute and 0 to 96 15-minute history bucket(s) of "interval-counters", as well as current and 0 to 30 previous 1-day interval-counter(s). Each current 15- minute event bucket has an associated threshold notification. Morgenstern, et al. Expires August 29, 2007 [Page 22] Internet-Draft VDSL2-LINE MIB February 2007 o On the bearer channel level For the coding violations (CRC anomalies) and corrected blocks (i.e., FEC events) there are event counters, current 15- minute and 0 to 96 15-minute history bucket(s) of "interval- counters", as well as current and 0 to 30 previous 1-day interval- counter(s). Each current 15-minute event bucket has an associated threshold notification. 2.7.2. Minimum Number Of Buckets Although it is possible to support up to 96 15-minute history buckets of "interval-counters", systems implementing this MIB module SHOULD practically support at least 16 buckets, as specified in ITU-T G.997.1, paragraph #7.2.7.9. Similarly, it is possible to support up to 30 previous 1-day "interval-counters", but systems implementing this MIB module SHOULD support at least 1 previous day buckets. 2.7.3. Interval Buckets Initialization There is no requirement for an agent to ensure a fixed relationship between the start of a 15-minute interval and any wall clock; however, some implementations may align the 15-minute intervals with quarter hours. Likewise, an implementation may choose to align one day intervals with the start of a day. Counters are not reset when an xtU is reinitialized, only when the agent is reset or reinitialized (or under specific request outside the scope of this MIB module). 2.7.4. Interval Buckets Validity As in RFC 3593 [RFC3593] and RFC 2662 [RFC2662], in case the data for an interval is suspect or known to be invalid, the agent MUST report the interval as invalid. If the current 15-minute event bucket is determined to be invalid, the element management system SHOULD ignore its content and the agent MUST NOT generate notifications based upon the value of the event bucket. A valid 15-minute event bucket SHOULD usually count the events for exactly 15 minutes. Similarly, a valid 1-day event bucket SHOULD usually count the events for exactly 24 hours. However, the following scenarios are exceptional: Morgenstern, et al. Expires August 29, 2007 [Page 23] Internet-Draft VDSL2-LINE MIB February 2007 1) For implementations that align the 15- minute intervals with quarter hours, and the 1-day intervals with start of a day, the management system may still start the PM process not aligned with the wall clock. Such a management system may wish to retrieve even partial information for the first event buckets, rather than declaring them all as invalid. 2) For an event bucket that suffered relatively short outages, the management system may wish to retrieve the available PM outcomes, rather than declaring the whole event bucket as invalid. This is more important for 1-day event buckets. 3) An event bucket may be shorter or longer than the formal duration if a clock adjustment was performed during the interval. This MIB allows supporting the exceptional scenarios described above by reporting the actual Monitoring Time of a monitoring interval. This parameter is relevant only for Valid intervals, but is useful for these exceptional scenarios: a) The management system MAY still declare a partial PM interval as Valid and report the actual number of seconds the interval lasted. b) If the interval was shortened or extended due to clock corrections, the management system SHOULD report the actual number of seconds the interval lasted, beside reporting that the interval is Valid. 2.8. Profiles As a managed node can handle a large number of xtUs, (e.g., hundreds or perhaps thousands of lines), provisioning every parameter on every xtU may become burdensome. Moreover, most lines are provisioned identically with the same set of parameters. To simplify the provisioning process, this MIB module makes use of profiles and templates. A configuration profile is a set of parameters that can be shared by multiple entities. There are configuration profiles to address the line level provisioning and another type of profile that addresses the channel level provisioning parameters. A configuration template is actually a profile-of- profiles. That is, a template is comprised of one line configuration profile and one or more channel configuration profiles. A template provides the complete configuration of a line. The same configuration can be shared by multiple lines. Similarly to the configuration profiles and templates, this MIB module makes use of templates and profiles for specifying the alarm thresholds associated with performance parameters. This allows provisioning multiple lines with the same criteria for generating Morgenstern, et al. Expires August 29, 2007 [Page 24] Internet-Draft VDSL2-LINE MIB February 2007 threshold crossing notifications. The following paragraphs describe templates and profiles used in this MIB module 2.8.1. Configuration Profiles And Templates o Line Configuration Profiles - Line configuration profiles contain parameters for configuring the low layer of VDLS2/ADSL/ADSL2 and ADSL2+ lines. They are defined in the xdsl2LineConfProfTable. The line configuration includes issues such as the specific VDSL2/ ADSL/ADSL2 or ADSL2+ modes to enable on the respective line, power spectrum parameters, rate adaptation criteria, and SNR margin related parameters. A subset of the line configuration parameters depends upon the specific xDSL Mode allowed (i.e., Does the profile allow VDSL2, ADSL, ADSL2 and/or ADSL2+?) as well as what annex/annexes of the standard are allowed. This is the reason a line profile MUST include one or more mode-specific extensions. o Channel Configuration Profiles - Channel configuration profiles contain parameters for configuring bearer channels over the VDSL2/ ADSL/ADSL2 and ADSL2+ lines. They are sometimes considered as the service layer configuration of the VDSL2/ADSL/ADSL2 and ADSL2+ lines. They are defined in the xdsl2ChConfProfTable. The channel configuration includes issues such as the desired minimum and maximum rate on each traffic flow direction and impulse noise protection parameters. o Line Configuration Templates - Line configuration templates allow combining line configuration profiles and channel configuration profiles to a comprehensive configuration of the VDSL2/ADSL/ADSL2 and ADSL2+ line. They are defined in the xdsl2LineConfTemplateTable. The line configuration template includes one index (OID) of a line configuration profile and one to four indexes of channel configuration profiles. The template also addresses the issue of distributing the excess available data rate on each traffic flow direction (i.e., the data rate left after each channel is allocated a data rate to satisfy its minimum requested data rate) among the various channels. Morgenstern, et al. Expires August 29, 2007 [Page 25] Internet-Draft VDSL2-LINE MIB February 2007 2.8.2. Alarm Configuration Profiles And Templates o Line Alarm Configuration Profiles - Line level Alarm configuration profiles contain the threshold values for Performance Monitoring (PM) parameters, counted either on the whole line level or on an xtu level. Thresholds are required only for failures and anomalies. E.g., there are thresholds for failed initializations and LOS seconds, but not for the aggregate number of full initializations. These profiles are defined in the xdsl2LineAlarmConfProfileTable. o Channel Alarm Configuration Profiles - Channel level Alarm configuration profiles contain the threshold values for PM parameters counted on a bearer channel level. Thresholds are defined for two types of anomalies: corrected blocks and coding violations. These profiles are defined in the xdsl2ChAlarmConfProfileTable. o Line Alarm Configuration Templates - Line Alarm configuration templates allow combining line level alarm configuration profiles and channel level alarm configuration profiles to a comprehensive configuration of the PM thresholds for VDSL2/ADSL/ADSL2 and ADSL2+ line. They are defined in the xdsl2LineAlarmConfTemplateTable. The line alarm configuration template includes one index (OID) of a line level alarm configuration profile and one to four indexes of channel level alarm configuration profiles. 2.8.3. Managing Profiles And Templates The index value for each profile and template is a locally-unique, administratively assigned name having the textual convention 'SnmpAdminString' (RFC 3411 [RFC3411]). One or more lines may be configured to share parameters of a single configuration template (e.g., xdsl2LConfTempTemplateName = 'silver') by setting its xdsl2LineCnfgTemplate objects to the value of this template. One or more lines may be configured to share parameters of a single Alarm configuration template (e.g., xdsl2LAlarmConfTempTemplateName = 'silver') by setting its xdsl2LineAlarmCnfgTemplate objects to the value of this template. Before a template can be deleted or taken out of service it MUST be first unreferenced from all associated lines. Implementations MAY also reject template modification while it is associated with any line. Morgenstern, et al. Expires August 29, 2007 [Page 26] Internet-Draft VDSL2-LINE MIB February 2007 Before a profile can be deleted or taken out of service it MUST be first unreferenced from all associated templates. Implementations MAY also reject profile modification while it is referenced by any template. Implementations MUST provide a default profile whose name is 'DEFVAL' for each profile and template type. The values of the associated parameters will be vendor-specific unless otherwise indicated in this document. Before a line's templates have been set, these templates will be automatically used by setting xdsl2LineCnfgTemplate and xdsl2LineAlarmCnfgTemplate to 'DEFVAL' where appropriate. This default profile name, 'DEFVAL', is considered reserved in the context of profiles and templates defined in this MIB module. Profiles and templates are created, assigned, and deleted dynamically using the profile name and profile row status in each of the profile tables. If the implementation allows modifying a profile or template while it is associated with a line, then such changes MUST take effect immediately. These changes MAY result in a restart (hard reset or soft restart) of the units on the line. 2.8.4. Managing Multiple Bearer Channels The number of bearer channels is configured by setting the template attributes xdsl2LConfTempChan1ConfProfile, xdsl2LConfTempChan2ConfProfile, xdsl2LConfTempChan3ConfProfile, and xdsl2LConfTempChan4ConfProfile and then assigning that template to a DSL line using the xdsl2LineCnfgTemplate attribute. When the number of bearer channels for a DSL line changes, the SNMP agent will automatically create or destroy rows in channel-related tables associated with that line. For example, when a DSL line is operating with one bearer channel, there will be zero rows in channel- related tables for channels two, three, and four. The SNMP agent MUST create and destroy channel related rows as follows : o When the number of bearer channels for a DSL line changes to a higher number, the SNMP agent will automatically create rows in the xdsl2ChannelStatusTable, and xdsl2PMChCurrTable tables for that line. o When the number of bearer channels for a DSL line changes to a lower number, the SNMP agent will automatically destroy rows in the xdsl2ChannelStatusTable, xdsl2PMChCurrTable,xdsl2PMChHist15MinTable and xdsl2PMChHist1DTable tables for that line. Morgenstern, et al. Expires August 29, 2007 [Page 27] Internet-Draft VDSL2-LINE MIB February 2007 2.9. Notifications The ability to generate the SNMP notifications coldStart/WarmStart (per [RFC3418]), which are per agent (e.g., per Digital Subscriber Line Access Multiplexer, or DSLAM, in such a device), and linkUp/ linkDown (per [RFC2863]), which are per interface (i.e., VDSL2/ADSL/ ADSL2 or ADSL2+ line) is required. A linkDown notification MAY be generated whenever any of ES, SES, CRC Anomaly, LOS, LOF, or UAS event occurs. The corresponding linkUp notification MAY be sent when all link failure conditions are cleared. The notifications defined in this MIB module are for status change (e.g., initialization failure) and for the threshold crossings associated with the following events: Full initialization failures, short initialization failures, ES, SES, FEC Seconds, LOS Seconds, UAS, FEC Seconds, FEC events, and CRC anomalies. Each threshold has its own enable/threshold value. When that value is 0, the notification is disabled. The xdsl2LineStatusXtur and xdsl2LineStatusXtuc are bitmasks representing all outstanding error conditions associated with the AtuR and xtuc (respectively). Note that since the xtur status is obtained via the EOC, this information may be unavailable in case the xtur is unreachable via EOC during a line error condition. Therefore, not all conditions may always be included in its current status. Notifications corresponding to the bit fields in those two status objects are defined. Note that there are other status parameters that refer to the AtuR (e.g., downstream line attenuation). Those parameters also depend on the availability of EOC between the central office xtu and the remote xtu. A threshold notification occurs whenever the corresponding current 15-minute interval error counter becomes equal to, or exceeds the threshold value. Only one notification SHOULD be sent per interval per interface. Since the current 15-minute counter is reset to 0 every 15 minutes, and if the condition persists, the notification may recur as often as every 15 minutes. For example, to get a notification whenever a "loss of" event occurs (but at most once every 15 minutes), set the corresponding threshold to 1. The agent will generate a notification when the event originally occurs. Notifications, other than the threshold notifications listed above, SHOULD be rate limited (throttled) such that there is an implementation-specific gap between the generation of consecutive Morgenstern, et al. Expires August 29, 2007 [Page 28] Internet-Draft VDSL2-LINE MIB February 2007 notifications of the same event. When notifications are rate limited, they are dropped and not queued for sending at a future time. This is intended to be a general rate-limiting statement for notifications that otherwise have no explicit rate limiting assertions in this document. Note that the Network Management System, or NMS, may receive a linkDown notification, as well, if enabled (via ifLinkUpDownTrapEnable [RFC2863]). At the beginning of the next 15 minute interval, the counter is reset. When the first second goes by and the event occurs, the current interval bucket will be 1, which equals the threshold, and the notification will be sent again. 3. Definitions VDSL2-LINE-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, transmission FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; vdsl2TCMIB MODULE-IDENTITY LAST-UPDATED "200702260000Z" -- February 26, 2007 ORGANIZATION "ADSLMIB Working Group" CONTACT-INFO "WG-email: adslmib@ietf.org Info: https://www1.ietf.org/mailman/listinfo/adslmib Chair: Mike Sneed Sand Channel Systems Postal: P.O. Box 37324 Raleigh NC 27627-732 Email: sneedmike@hotmail.com Phone: +1 206 600 7022 Co-Chair: Menachem Dodge ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Morgenstern, et al. Expires August 29, 2007 [Page 29] Internet-Draft VDSL2-LINE MIB February 2007 Email: mbdodge@ieee.org Phone: +972 3 926 8421 Co-editor: Moti Morgenstern ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Email: moti.morgenstern@ecitele.com Phone: +972 3 926 6258 Co-editor: Scott Baillie NEC Australia Postal: 649-655 Springvale Road, Mulgrave, Victoria 3170, Australia. Email: scott.baillie@nec.com.au Phone: +61 3 9264 3986 Co-editor: Umberto Bonollo NEC Australia Postal: 649-655 Springvale Road, Mulgrave, Victoria 3170, Australia. Email: umberto.bonollo@nec.com.au Phone: +61 3 9264 3385 " DESCRIPTION "This MIB Module provides Textual Conventions to be used by the VDSL2-LINE-MIB module for the purpose of managing VDSL2, ADSL, ADSL2 and ADSL2+ lines. Copyright (C) The Internet Society (2007). This version of this MIB module is part of RFC XXXX: see the RFC itself for full legal notices." -- RFC Ed.: replace XXXX with assigned number & remove this note REVISION "200702260000Z" -- February 26, 2007 DESCRIPTION "Initial version, published as RFC XXXX." -- RFC Ed.: replace XX with assigned number & remove this note ::= { transmission xxx 2} -- vdsl2MIB 2 -- IANA, the xxx here must be the same as the one assigned -- to the vdsl2MIB below. -- RFC Ed.: Please fill in xxx once assigned by IANA. ------------------------------------------------ -- Textual Conventions -- ------------------------------------------------ Morgenstern, et al. Expires August 29, 2007 [Page 30] Internet-Draft VDSL2-LINE MIB February 2007 Xdsl2Unit ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies a transceiver as being either xtuc or xtur. A VDSL2/ADSL/ADSL2 or ADSL2+ line consists of two transceivers, an xtuc and an xtur. In the case of ADSL/ADSL2 and ADSL2+ those two transceivers are also called atuc and atur. In the case of VDSL2 those two transceivers are also called vtuc and vtur. Attributes with this syntax reference the two sides of a line. Specified as an INTEGER, the two values are: xtuc(1) -- central office transceiver xtur(2) -- remote site transceiver" SYNTAX INTEGER { xtuc(1), xtur(2) } Xdsl2Direction ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies the direction of a band in a VDSL2/ADSL/ADSL2/ADSL2+ link. The upstream direction is a transmission from the remote end (xTU-R) towards the central office end (xTU-C). The downstream direction is a transmission from the xTU-C towards the xTU-R. Specified as an INTEGER, the values are defined as follows:" SYNTAX INTEGER { upstream(1), -- Transmission from the xTU-R to the xTU-C. downstream(2) -- Transmission from the xTU-C to the xTU-R. } Xdsl2Band ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies a band in a VDSL2/ADSL/ADSL2/ADSL2+ link. For a band in the upstream direction, transmission is from the remote end (xTU-R) towards the central office end (xTU-C). A band in the upstream direction is indicated by upstream(1) for Morgenstern, et al. Expires August 29, 2007 [Page 31] Internet-Draft VDSL2-LINE MIB February 2007 ADSL/ADSL2/ADSL2+ single band, or any of us0(3), us1(5), us2(7), us3(9), or us4(11) for VDSL2 multiple bands. For a band in the downstream direction, transmission is from the xTU-C towards the xTU-R. A band in the downstream direction is indicated by downstream(2) for ADSL/ADSL2/ADSL2+ single band, or any of ds1(4), ds2(6), ds3(8), or ds4(10) for VDSL2 multiple bands. Specified as an INTEGER, the values are defined as follows:" SYNTAX INTEGER { upstream(1), -- Transmission from the ATU-R to the ATU-C -- (ADSL/ADSL2/ADSL2+). downstream(2), -- Transmission from the ATU-C to the ATU-R --(ADSL/ADSL2/ADSL2+). us0(3), -- Upstream band number 0 (US0) (VDSL2). ds1(4), -- Downstream band number 1 (DS1) (VDSL2). us1(5), -- Upstream band number 1 (US1) (VDSL2). ds2(6), -- Downstream band number 2 (DS2) (VDSL2). us2(7), -- Upstream band number 2 (US2) (VDSL2). ds3(8), -- Downstream band number 3 (DS3) (VDSL2). us3(9), -- Upstream band number 3 (US3) (VDSL2). ds4(10), -- Downstream band number 4 (DS4) (VDSL2). us4(11) -- Upstream band number 4 (US4) (VDSL2). } Xdsl2TransmissionModeType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A set of xDSL line transmission modes, with one bit per mode. The notes (F) and (L) denote Full-Rate and Lite/splitterless respectively: Bit 00 : Regional Std. (ANSI T1.413) (F) Bit 01 : Regional Std. (ETSI DTS/TM06006) (F) Bit 02 : G.992.1 POTS non-overlapped (F) Bit 03 : G.992.1 POTS overlapped (F) Bit 04 : G.992.1 ISDN non-overlapped (F) Bit 05 : G.992.1 ISDN overlapped (F) Bit 06 : G.992.1 TCM-ISDN non-overlapped (F) Bit 07 : G.992.1 TCM-ISDN overlapped (F) Bit 08 : G.992.2 POTS non-overlapped (L) Bit 09 : G.992.2 POTS overlapped (L) Bit 10 : G.992.2 with TCM-ISDN non-overlapped (L) Bit 11 : G.992.2 with TCM-ISDN overlapped (L) Bit 12 : G.992.1 TCM-ISDN symmetric (F) --- not in G.997.1 Bit 13-17: Reserved Morgenstern, et al. Expires August 29, 2007 [Page 32] Internet-Draft VDSL2-LINE MIB February 2007 Bit 18 : G.992.3 POTS non-overlapped (F) Bit 19 : G.992.3 POTS overlapped (F) Bit 20 : G.992.3 ISDN non-overlapped (F) Bit 21 : G.992.3 ISDN overlapped (F) Bit 22-23: Reserved Bit 24 : G.992.4 POTS non-overlapped (L) Bit 25 : G.992.4 POTS overlapped (L) Bit 26-27: Reserved Bit 28 : G.992.3 Annex I All-Digital non-overlapped (F) Bit 29 : G.992.3 Annex I All-Digital overlapped (F) Bit 30 : G.992.3 Annex J All-Digital non-overlapped (F) Bit 31 : G.992.3 Annex J All-Digital overlapped (F) Bit 32 : G.992.4 Annex I All-Digital non-overlapped (L) Bit 33 : G.992.4 Annex I All-Digital overlapped (L) Bit 34 : G.992.3 Annex L POTS non-overlapped, mode 1, wide U/S (F) Bit 35 : G.992.3 Annex L POTS non-overlapped, mode 2, narrow U/S(F) Bit 36 : G.992.3 Annex L POTS overlapped, mode 3, wide U/S (F) Bit 37 : G.992.3 Annex L POTS overlapped, mode 4, narrow U/S (F) Bit 38 : G.992.3 Annex M POTS non-overlapped (F) Bit 39 : G.992.3 Annex M POTS overlapped (F) Bit 40 : G.992.5 POTS non-overlapped (F) Bit 41 : G.992.5 POTS overlapped (F) Bit 42 : G.992.5 ISDN non-overlapped (F) Bit 43 : G.992.5 ISDN overlapped (F) Bit 44-45: Reserved Bit 46 : G.992.5 Annex I All-Digital non-overlapped (F) Bit 47 : G.992.5 Annex I All-Digital overlapped (F) Bit 48 : G.992.5 Annex J All-Digital non-overlapped (F) Bit 49 : G.992.5 Annex J All-Digital overlapped (F) Bit 50 : G.992.5 Annex M POTS non-overlapped (F) Bit 51 : G.992.5 Annex M POTS overlapped (F) Bit 52-55: Reserved Bit 56 : G.993.2 Annex A Bit 57 : G.993.2 Annex B Bit 58 : G.993.2 Annex C Bit 59-63: Reserved" SYNTAX BITS { ansit1413(0), etsi(1), g9921PotsNonOverlapped(2), g9921PotsOverlapped(3), g9921IsdnNonOverlapped(4), g9921isdnOverlapped(5), g9921tcmIsdnNonOverlapped(6), Morgenstern, et al. Expires August 29, 2007 [Page 33] Internet-Draft VDSL2-LINE MIB February 2007 g9921tcmIsdnOverlapped(7), g9922potsNonOverlapeed(8), g9922potsOverlapped(9), g9922tcmIsdnNonOverlapped(10), g9922tcmIsdnOverlapped(11), g9921tcmIsdnSymmetric(12), reserved1(13), reserved2(14), reserved3(15), reserved4(16), reserved5(17), g9923PotsNonOverlapped(18), g9923PotsOverlapped(19), g9923IsdnNonOverlapped(20), g9923isdnOverlapped(21), reserved6(22), reserved7(23), g9924potsNonOverlapeed(24), g9924potsOverlapped(25), reserved8(26), reserved9(27), g9923AnnexIAllDigNonOverlapped(28), g9923AnnexIAllDigOverlapped(29), g9923AnnexJAllDigNonOverlapped(30), g9923AnnexJAllDigOverlapped(31), g9924AnnexIAllDigNonOverlapped(32), g9924AnnexIAllDigOverlapped(33), g9923AnnexLMode1NonOverlapped(34), g9923AnnexLMode2NonOverlapped(35), g9923AnnexLMode3Overlapped(36), g9923AnnexLMode4Overlapped(37), g9923AnnexMPotsNonOverlapped(38), g9923AnnexMPotsOverlapped(39), g9925PotsNonOverlapped(40), g9925PotsOverlapped(41), g9925IsdnNonOverlapped(42), g9925isdnOverlapped(43), reserved10(44), reserved11(45), g9925AnnexIAllDigNonOverlapped(46), g9925AnnexIAllDigOverlapped(47), g9925AnnexJAllDigNonOverlapped(48), g9925AnnexJAllDigOverlapped(49), g9925AnnexMPotsNonOverlapped(50), g9925AnnexMPotsOverlapped(51), reserved12(52), reserved13(53), reserved14(54), Morgenstern, et al. Expires August 29, 2007 [Page 34] Internet-Draft VDSL2-LINE MIB February 2007 reserved15(55), g9932AnnexA(56), g9932AnnexB(57), g9932AnnexC(58), reserved16(59), reserved17(60), reserved18(61), reserved19(62), reserved20(63) } Xdsl2RaMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the rate adaptation behavior for the line. The three possible behaviors are: manual (1) - No Rate-Adaptation. The initialization process attempts to synchronize to a specified rate. raInit (2) - Rate-Adaptation during initialization process only, which attempts to synchronize to a rate between minimum and maximum specified values. dynamicRa (3)- Dynamic Rate-Adaptation during initialization process as well as during SHOWTIME" SYNTAX INTEGER { manual(1), raInit(2), dynamicRa(3) } Xdsl2InitResult ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the result of full initialization attempt; the six possible result values are: noFail (0) - Successful initialization configError (1) - Configuration failure configNotFeasible (2) - Configuration details not supported commFail (3) - Communication failure noPeerAtu (4) - Peer ATU not detected otherCause (5) - Other initialization failure reason" SYNTAX INTEGER { noFail(0), configError(1), configNotFeasible(2), commFail(3), noPeerAtu(4), Morgenstern, et al. Expires August 29, 2007 [Page 35] Internet-Draft VDSL2-LINE MIB February 2007 otherCause(5) } Xdsl2OperationModes ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The VDSL2 management model specified includes an xDSL Mode attribute which identifies an instance of xDSL Mode-Specific PSD Configuration object in the xDSL Line Profile. The following classes of xDSL operating mode are defined. The notes (F) and (L) denote Full-Rate and Lite/splitterless respectively: +-------+--------------------------------------------------+ | Value | xDSL operation mode description | +-------+--------------------------------------------------+ 1 - The default/generic PSD configuration. Default configuration will be used when no other matching mode specific configuration can be found. 2 - ADSL family. The attributes included in the Mode- Specific PSD Configuration are irrelevant for ITU-T G.992.1 and G.992.2 ADSL modes. Hence, it is possible to map those modes to this generic class. 3-7 - Unused. Reserved for future ITU-T specification. 8 - G.992.3 POTS non-overlapped (F) 9 - G.992.3 POTS overlapped (F) 10 - G.992.3 ISDN non-overlapped (F) 11 - G.992.3 ISDN overlapped (F) 12-13 - Unused. Reserved for future ITU-T specification. 14 - G.992.4 POTS non-overlapped (L) 15 - G.992.4 POTS overlapped (L) 16-17 - Unused. Reserved for future ITU-T specification. 18 - G.992.3 Annex I All-Digital non-overlapped (F) 19 - G.992.3 Annex I All-Digital overlapped (F) 20 - G.992.3 Annex J All-Digital non-overlapped (F) 21 - G.992.3 Annex J All-Digital overlapped (F) 22 - G.992.4 Annex I All-Digital non-overlapped (L) 23 - G.992.4 Annex I All-Digital overlapped (L) 24 - G.992.3 Annex L POTS non-overlapped, mode 1, wide U/S (F) 25 - G.992.3 Annex L POTS non-overlapped, mode 2, narrow U/S(F) 26 - G.992.3 Annex L POTS overlapped, mode 3, wide U/S (F) 27 - G.992.3 Annex L POTS overlapped, mode 4, narrow U/S (F) 28 - G.992.3 Annex M POTS non-overlapped (F) 29 - G.992.3 Annex M POTS overlapped (F) Morgenstern, et al. Expires August 29, 2007 [Page 36] Internet-Draft VDSL2-LINE MIB February 2007 30 - G.992.5 POTS non-overlapped (F) 31 - G.992.5 POTS overlapped (F) 32 - G.992.5 ISDN non-overlapped (F) 33 - G.992.5 ISDN overlapped (F) 34-35 - Unused. Reserved for future ITU-T specification. 36 - G.992.5 Annex I All-Digital non-overlapped (F) 37 - G.992.5 Annex I All-Digital overlapped (F) 38 - G.992.5 Annex J All-Digital non-overlapped (F) 39 - G.992.5 Annex J All-Digital overlapped (F) 40 - G.992.5 Annex M POTS non-overlapped (F) 41 - G.992.5 Annex M POTS overlapped (F) 42-45 - Unused. Reserved for future ITU-T specification. 46 - G.993.2 Annex A 47 - G.993.2 Annex B 48 - G.993.2 Annex C " SYNTAX INTEGER { defMode(1), adsl(2), g9923PotsNonOverlapped(8), g9923PotsOverlapped(9), g9923IsdnNonOverlapped(10), g9923isdnOverlapped(11), g9924potsNonOverlapeed(14), g9924potsOverlapped(15), g9923AnnexIAllDigNonOverlapped(18), g9923AnnexIAllDigOverlapped(19), g9923AnnexJAllDigNonOverlapped(20), g9923AnnexJAllDigOverlapped(21), g9924AnnexIAllDigNonOverlapped(22), g9924AnnexIAllDigOverlapped(23), g9923AnnexLMode1NonOverlapped(24), g9923AnnexLMode2NonOverlapped(25), g9923AnnexLMode3Overlapped(26), g9923AnnexLMode4Overlapped(27), g9923AnnexMPotsNonOverlapped(28), g9923AnnexMPotsOverlapped(29), g9925PotsNonOverlapped(30), g9925PotsOverlapped(31), g9925IsdnNonOverlapped(32), g9925isdnOverlapped(33), g9925AnnexIAllDigNonOverlapped(36), g9925AnnexIAllDigOverlapped(37), g9925AnnexJAllDigNonOverlapped(38), g9925AnnexJAllDigOverlapped(39), g9925AnnexMPotsNonOverlapped(40), g9925AnnexMPotsOverlapped(41), g9932AnnexA(46), Morgenstern, et al. Expires August 29, 2007 [Page 37] Internet-Draft VDSL2-LINE MIB February 2007 g9932AnnexB(47), g9932AnnexC(48) } Xdsl2PowerMngState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax uniquely identify each power management state defined for the VDSL2/ADSL/ADSL2 or ADSL2+ link. In VDSL2 only L0 and L3 states are defined. The possible values are: l0(1) - L0 - Full power management state l1(2) - L1 - Low power management state (for G.992.2) l2(3) - L2 - Low power management state (for G.992.3, G.992.4, and G.992.5) l3(4) - L3 - Idle power management state" SYNTAX INTEGER { l0(1), l1(2), l2(3), l3(4) } Xdsl2ConfPmsForce ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are configuration parameters that reference the desired power management state for the VDSL2/ADSL/ADSL2 or ADSL2+ link In VDSL2 only L0 and L3 states are defined: l3toL0 (0) - Perform a transition from L3 to L0 (Full power management state) l0toL2 (2) - Perform a transition from L0 to L2 (Low power management state) l0orL2toL3 (3) - Perform a transition into L3 (Idle power management state)" SYNTAX INTEGER { l3toL0 (0), l0toL2 (2), l0orL2toL3 (3) } Xdsl2LinePmMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION Morgenstern, et al. Expires August 29, 2007 [Page 38] Internet-Draft VDSL2-LINE MIB February 2007 "Attributes with this syntax are configuration parameters that reference the power modes/states into which the xTU-C or xTU-R may autonomously transit. It is a BITS structure that allows control of the following transit options: allowTransitionsToIdle (0) - xTU may autonomously transit to idle (L3) state. allowTransitionsToLowPower (1)- xTU may autonomously transit to low-power (L1/L2) state." SYNTAX BITS { allowTransitionsToIdle(0), allowTransitionsToLowPower(1) } Xdsl2LineLdsf ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are configuration parameters that control the Loop Diagnostic mode for a VDSL2/ADSL/ADSL2 or ADSL2+ link. The possible values are: inhibit (0) - Inhibit Loop Diagnostic mode force (1) - Force/Initiate Loop Diagnostic mode" SYNTAX INTEGER { inhibit(0), force(1) } Xdsl2LdsfResult ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Possible failure reasons associated with performing Dual Ended Loop Test (DELT) on a DSL line. Possible values are: none (1) - The default value in case LDSF was never requested for the associated line. success (2) - The recent command completed successfully. inProgress (3) - The Loop Diagnostics process is in progress. unsupported (4) - The NE or the line card doesn't support LDSF. cannotRun (5) - The NE cannot initiate the command, due to a non specific reason. aborted (6) - The Loop Diagnostics process aborted. Morgenstern, et al. Expires August 29, 2007 [Page 39] Internet-Draft VDSL2-LINE MIB February 2007 failed (7) - The Loop Diagnostics process failed. illegalMode (8) - The NE cannot initiate the command, due to the specific mode of the relevant line. adminUp (9) - The NE cannot initiate the command, as the relevant line is administratively 'Up'. tableFull (10)- The NE cannot initiate the command, due to reaching the maximum number of rows in the results table. noResources (11)- The NE cannot initiate the command, due to lack of internal memory resources." SYNTAX INTEGER { none (1), success (2), inProgress (3), unsupported (4), cannotRun (5), aborted (6), failed (7), illegalMode (8), adminUp (9), tableFull (10), noResources (11) } Xdsl2LineProfiles ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax reference the list of ITU-T G.993.2 implementation profiles supported by an xTU, enabled on the VDSL2 line or active on that line." SYNTAX BITS { profile8a(0), profile8b(1), profile8c(2), profile8d(3), profile12a(4), profile12b(5), profile17a(6), profile30a(7) } Xdsl2LineClassMask ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "VDSL2 PSD Mask Class. Morgenstern, et al. Expires August 29, 2007 [Page 40] Internet-Draft VDSL2-LINE MIB February 2007 The limit Power Spectral Density masks are grouped in the following PSD mask classes: Class 998 Annex A: D-32, D-64. Class 997-M1c Annex B: 997-M1c-A-7. Class 997-M1x Annex B: 997-M1x-M-8, 997-M1x-M. Class 997-M2x Annex B: 997-M2x-M-8, 997-M2x-A, 997-M2x-M. Class 998-M1x Annex B: 998-M1x-A, 998-M1x-B, 998-M1x-NUS0. Class 998-M2x Annex B: 998-M2x-A, 998-M2x-M, 998-M2x-B, 998-M2x-NUS0. Class 998 Annex C: POTS (C.2.1.1/G.993.2), TCM-ISDN (C.2.1.2/G.993.2)." SYNTAX INTEGER { none(1), a998ORb997M1cORc998(2), b997M1x(3), b997M2x(4), b998M1x(5), b998M2x(6) } Xdsl2LineLimitMask ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The G.993.2 limit PSD mask for each class of profile. The profiles are grouped in following profile classes: - Class 8: Profiles 8a, 8b, 8c, 8d - Class 12: Profiles 12a, 12b - Class 17: Profile 17a - Class 30: Profile 30a." SYNTAX BITS { profile8Limit1(0), profile8Limit2(1), profile8Limit3(2), profile8Limit4(3), profile8Limit5(4), profile8Limit6(5), profile8Limit7(6), profile8Limit8(7), profile8Limit9(8), profile8Limit10(9), profile8Limit11(10), profile8Limit12(11), profile8Limit13(12), profile8Limit14(13), profile8Limit15(14), Morgenstern, et al. Expires August 29, 2007 [Page 41] Internet-Draft VDSL2-LINE MIB February 2007 profile8Limit16(15), -- profile12Limit1(16), profile12Limit2(17), profile12Limit3(18), profile12Limit4(19), profile12Limit5(20), profile12Limit6(21), profile12Limit7(22), profile12Limit8(23), profile12Limit9(24), profile12Limit10(25), profile12Limit11(26), profile12Limit12(27), profile12Limit13(28), profile12Limit14(29), profile12Limit15(30), profile12Limit16(31), -- profile17Limit1(32), profile17Limit2(33), profile17Limit3(34), profile17Limit4(35), profile17Limit5(36), profile17Limit6(37), profile17Limit7(38), profile17Limit8(39), profile17Limit9(40), profile17Limit10(41), profile17Limit11(42), profile17Limit12(43), profile17Limit13(44), profile17Limit14(45), profile17Limit15(46), profile17Limit16(47), -- profile30Limit1(48), profile30Limit2(49), profile30Limit3(50), profile30Limit4(51), profile30Limit5(52), profile30Limit6(53), profile30Limit7(54), profile30Limit8(55), profile30Limit9(56), profile30Limit10(57), profile30Limit11(58), profile30Limit12(59), Morgenstern, et al. Expires August 29, 2007 [Page 42] Internet-Draft VDSL2-LINE MIB February 2007 profile30Limit13(60), profile30Limit14(61), profile30Limit15(62), profile30Limit16(63) } Xdsl2LineUs0Disable ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Indicates if US0 is disabled for each limit PSD mask. The profiles are grouped in following profile classes: - Class 8: Profiles 8a, 8b, 8c, 8d - Class 12: Profiles 12a, 12b - Class 17: Profile 17a - Class 30: Profile 30a." SYNTAX BITS { profile8Us0Disable1(0), profile8Us0Disable2(1), profile8Us0Disable3(2), profile8Us0Disable4(3), profile8Us0Disable5(4), profile8Us0Disable6(5), profile8Us0Disable7(6), profile8Us0Disable8(7), profile8Us0Disable9(8), profile8Us0Disable10(9), profile8Us0Disable11(10), profile8Us0Disable12(11), profile8Us0Disable13(12), profile8Us0Disable14(13), profile8Us0Disable15(14), profile8Us0Disable16(15), -- profile12Us0Disable1(16), profile12Us0Disable2(17), profile12Us0Disable3(18), profile12Us0Disable4(19), profile12Us0Disable5(20), profile12Us0Disable6(21), profile12Us0Disable7(22), profile12Us0Disable8(23), profile12Us0Disable9(24), profile12Us0Disable10(25), profile12Us0Disable11(26), profile12Us0Disable12(27), profile12Us0Disable13(28), profile12Us0Disable14(29), Morgenstern, et al. Expires August 29, 2007 [Page 43] Internet-Draft VDSL2-LINE MIB February 2007 profile12Us0Disable15(30), profile12Us0Disable16(31), -- profile17Us0Disable1(32), profile17Us0Disable2(33), profile17Us0Disable3(34), profile17Us0Disable4(35), profile17Us0Disable5(36), profile17Us0Disable6(37), profile17Us0Disable7(38), profile17Us0Disable8(39), profile17Us0Disable9(40), profile17Us0Disable10(41), profile17Us0Disable11(42), profile17Us0Disable12(43), profile17Us0Disable13(44), profile17Us0Disable14(45), profile17Us0Disable15(46), profile17Us0Disable16(47), -- profile30Us0Disable1(48), profile30Us0Disable2(49), profile30Us0Disable3(50), profile30Us0Disable4(51), profile30Us0Disable5(52), profile30Us0Disable6(53), profile30Us0Disable7(54), profile30Us0Disable8(55), profile30Us0Disable9(56), profile30Us0Disable10(57), profile30Us0Disable11(58), profile30Us0Disable12(59), profile30Us0Disable13(60), profile30Us0Disable14(61), profile30Us0Disable15(62), profile30Us0Disable16(63) } Xdsl2LineUs0Mask ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The US0 PSD masks to be allowed by the near-end xTU on the line. This parameter is only defined for G.993.2 Annex A. It is represented as a bitmap (0 if not allowed and 1 if allowed) with the following definitions." SYNTAX BITS { eu32(0), Morgenstern, et al. Expires August 29, 2007 [Page 44] Internet-Draft VDSL2-LINE MIB February 2007 eu36(1), eu40(2), eu44(3), eu48(4), eu52(5), eu56(6), eu60(7), -- eu64(8), reserved1(9), reserved2(10), reserved3(11), reserved4(12), reserved5(13), reserved6(14), reserved7(15), -- adlu32(16), adlu36(17), adlu40(18), adlu44(19), adlu48(20), adlu52(21), adlu56(22), adlu60(23), -- adlu64(24), reserved8(25), reserved9(26), reserved10(27), reserved11(28), reserved12(29), reserved13(30), reserved14(31) } Xdsl2SymbolProtection ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are configuration parameters that reference the minimum length impulse noise protection (INP) in terms of number of symbols. The possible values are: noProtection (i.e., INP not required), halfSymbol (i.e., INP length is 1/2 symbol), and 1-16 symbols in steps of 1 symbol" SYNTAX INTEGER { noProtection (1), Morgenstern, et al. Expires August 29, 2007 [Page 45] Internet-Draft VDSL2-LINE MIB February 2007 halfSymbol (2), singleSymbol (3), twoSymbols (4), threeSymbols (5), fourSymbols (6), fiveSymbols (7), sixSymbols (8), sevenSymbols (9), eightSymbols (10), nineSymbols (11), tenSymbols (12), elevenSymbols (13), twelveSymbols (14), thirteeSymbols (15), fourteenSymbols (16), fifteenSymbols (17), sixteenSymbols (18) } Xdsl2MaxBer ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are configuration parameters that reference the maximum Bit Error Rate (BER). The possible values are: eminus3 (1) - Maximum BER=E^-3 eminus5 (2) - Maximum BER=E^-5 eminus7 (3) - Maximum BER=E^-7" SYNTAX INTEGER { eminus3(1), eminus5(2), eminus7(3) } Xdsl2ScMaskDs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Each one of the 4096 bits in this OCTET STRING array represents the corresponding bin in the downstream direction. A value of one indicates that the bin is not in use." SYNTAX OCTET STRING (SIZE(0..512)) Xdsl2ScMaskUs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Each one of the 4096 bits in this OCTET STRING array represents the corresponding bin Morgenstern, et al. Expires August 29, 2007 [Page 46] Internet-Draft VDSL2-LINE MIB February 2007 in the upstream direction. A value of one indicates that the bin is not in use." SYNTAX OCTET STRING (SIZE(0..512)) Xdsl2CarMask ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This type defines an array of bands. Each band is represented by 4 octets and there is a maximum of 32 bands allowed. Each band consists of a 16 bit start subcarrier index followed by a 16 bit stop subcarrier index." SYNTAX OCTET STRING (SIZE(0..128)) Xdsl2PsdMaskDs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is a structure that represents up to 32 PSD Mask breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the sub-carrier associated with the breakpoint. The third octet holds the PSD reduction at the breakpoint from 0 (0dBm/Hz) to 255 (-127.5 dBm/Hz) using units of 0.5dBm/Hz." SYNTAX OCTET STRING (SIZE(0..96)) Xdsl2PsdMaskUs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is a structure that represents up to 16 PSD Mask breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the sub-carrier associated with the breakpoint. The third octet holds the PSD reduction at the breakpoint from 0 (0dBm/Hz) to 255 (-127.5 dBm/Hz) using units of 0.5dBm/Hz." SYNTAX OCTET STRING (SIZE(0..48)) Xdsl2Tssi ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is a structure that represents up to 32 transmit spectrum shaping (TSSi) breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the sub-carrier associated with the breakpoint. The third octet Morgenstern, et al. Expires August 29, 2007 [Page 47] Internet-Draft VDSL2-LINE MIB February 2007 holds the shaping parameter at the breakpoint. It is a value from 0 to 127 (units of -0.5dB). The special value 127 indicates that the sub-carrier is not transmitted." SYNTAX OCTET STRING (SIZE(0..96)) ------***************************************************** ------ The following TC we should add VDSL2 related states ------***************************************************** Xdsl2LastTransmittedState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This parameter represents the last successful transmitted initialization state in the last full initialization performed on the line States are per the specific xDSL technology and are numbered from 0 (if G.994.1 is used) or 1 (if G.994.1 is not used) up to Showtime." SYNTAX INTEGER { atucG9941(0), atucQuiet1(1), atucComb1(2), atucQuiet2(3), atucComb2(4), atucIcomb1(5), atucLineprob(6), atucQuiet3(7), atucComb3(8), atucIComb2(9), atucMsgfmt(10), atucMsgpcb(11), atucQuiet4(12), atucReverb1(13), atucTref1(14), atucReverb2(15), atucEct(16), atucReverb3(17), atucTref2(18), atucReverb4(19), atucSegue1(20), atucMsg1(21), atucReverb5(22), atucSegue2(23), atucMedley(24), atucExchmarker(25), atucMsg2(26), atucReverb6(27), atucSegue3(28), Morgenstern, et al. Expires August 29, 2007 [Page 48] Internet-Draft VDSL2-LINE MIB February 2007 atucParams(29), atucReverb7(30), atucSegue4(31), atucShowtime(32), -- aturG9941(100), aturQuiet1(101), aturComb1(102), aturQuiet2(103), aturComb2(104), aturIcomb1(105), aturLineprob(106), aturQuiet3(107), aturComb3(108), aturIcomb2(109), aturMsgfmt(110), aturMsgpcb(111), aturReverb1(112), aturQuiet4(113), aturReverb2(114), aturQuiet5(115), aturReverb3(116), aturEct(117), aturReverb4(118), aturSegue1(119), aturReverb5(120), aturSegue2(121), aturMsg1(122), aturMedley(123), aturExchmarker(124), aturMsg2(125), aturReverb6(126), aturSegue3(127), aturParams(128), aturReverb7(129), aturSegue4(130), aturShowtime(131) } Xdsl2LineStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are status parameters that reflect the failure status for a given endpoint of VDSL2/ADSL/ADSL2 or ADSL2+ link. This BITS structure can report the following failures: Morgenstern, et al. Expires August 29, 2007 [Page 49] Internet-Draft VDSL2-LINE MIB February 2007 noDefect (0) - This bit position positively reports that no defect or failure exist. lossOfFraming (1) - Loss of frame synchronization lossOfSignal (2) - Loss of signal lossOfPower (3) - Loss of power. Usually this failure may be reported for CPE units only initFailure (4) - Recent initialization process failed. Never active on xTU-R." SYNTAX BITS { noDefect(0), lossOfFraming(1), lossOfSignal(2), lossOfPower(3), initFailure(4) } Xdsl2ChAtmStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are status parameters that reflect the failure status for Transmission Convergence (TC) layer of a given ATM interface (data path over a VDSL2/ADSL/ ADSL2 or ADSL2+ link). This BITS structure can report the following failures: noDefect (0) - This bit position positively reports that no defect or failure exist. noCellDelineation (1) - The link was successfully initialized but cell delineation was never acquired on the associated ATM data path. lossOfCellDelineation (2)- Loss of cell delineation on the associated ATM data path" SYNTAX BITS { noDefect(0), noCellDelineation(1), lossOfCellDelineation(2) } Xdsl2ChPtmStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are status parameters that reflect the failure status for a given PTM interface (packet Morgenstern, et al. Expires August 29, 2007 [Page 50] Internet-Draft VDSL2-LINE MIB February 2007 data path over a VDSL2/ADSL/ADSL2 or ADSL2+ link). This BITS structure can report the following failures: noDefect (0) - This bit position positively reports that no defect or failure exist. outOfSync (1) - Out of synchronization. " SYNTAX BITS { noDefect(0), outOfSync(1) } Xdsl2UpboKLF ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Defines the upstream power backoff force mode (UPBOKLF). The three possible mode values are: auto(1) - The VTUS' will autonomously determine the electrical length. override(2) - Forces the VTU-R to use the electrical length, kl0, of the CO-MIB (UPBOKL) to compute the UPBO. disableUpbo(3) - Disables UPBO such that UPBO is not utilized." SYNTAX INTEGER { auto(1), override(2), disableUpbo(3) } Xdsl2BandUs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Each value identifies a specific band in the upstream transmission direction (Excluding US0 band.). The possible values which identify a band are as follows: us1(5) - Upstream band number 1 (US1). us2(7) - Upstream band number 2 (US2). us3(9) - Upstream band number 3 (US3). us4(11) - Upstream band number 4 (US4)." SYNTAX INTEGER { us1(5), us2(7), us3(9), us4(11) } END Morgenstern, et al. Expires August 29, 2007 [Page 51] Internet-Draft VDSL2-LINE MIB February 2007 VDSL2-LINE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, transmission, Unsigned32, NOTIFICATION-TYPE, Integer32, Counter32 FROM SNMPv2-SMI ifIndex FROM IF-MIB TruthValue, RowStatus FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB HCPerfIntervalThreshold, HCPerfTimeElapsed FROM HC-PerfHist-TC-MIB -- [RFC3705] Xdsl2Unit, Xdsl2Direction, Xdsl2Band, Xdsl2TransmissionModeType, Xdsl2RaMode, Xdsl2InitResult, Xdsl2OperationModes, Xdsl2PowerMngState, Xdsl2ConfPmsForce, Xdsl2LinePmMode, Xdsl2LineLdsf, Xdsl2LdsfResult, Xdsl2SymbolProtection, Xdsl2MaxBer, Xdsl2ScMaskDs, Xdsl2ScMaskUs, Xdsl2CarMask, Xdsl2PsdMaskDs, Xdsl2PsdMaskUs, Xdsl2Tssi, Xdsl2LastTransmittedState, Morgenstern, et al. Expires August 29, 2007 [Page 52] Internet-Draft VDSL2-LINE MIB February 2007 Xdsl2LineStatus, Xdsl2ChAtmStatus, Xdsl2ChPtmStatus, Xdsl2UpboKLF, Xdsl2BandUs, Xdsl2LineProfiles, Xdsl2LineUs0Mask, Xdsl2LineClassMask, Xdsl2LineLimitMask, Xdsl2LineUs0Disable FROM VDSL2-LINE-TC-MIB -- [This document] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; vdsl2MIB MODULE-IDENTITY LAST-UPDATED "200702260000Z" -- February 26, 2007 ORGANIZATION "ADSLMIB Working Group" CONTACT-INFO "WG-email: adslmib@ietf.org Info: https://www1.ietf.org/mailman/listinfo/adslmib Chair: Mike Sneed Sand Channel Systems Postal: P.O. Box 37324 Raleigh NC 27627-732 Email: sneedmike@hotmail.com Phone: +1 206 600 7022 Co-Chair: Menachem Dodge ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Email: mbdodge@ieee.org Phone: +972 3 926 8421 Co-editor: Moti Morgenstern ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Email: moti.morgenstern@ecitele.com Phone: +972 3 926 6258 Morgenstern, et al. Expires August 29, 2007 [Page 53] Internet-Draft VDSL2-LINE MIB February 2007 Co-editor: Scott Baillie NEC Australia Postal: 649-655 Springvale Road, Mulgrave, Victoria 3170, Australia. Email: scott.baillie@nec.com.au Phone: +61 3 9264 3986 Co-editor: Umberto Bonollo NEC Australia Postal: 649-655 Springvale Road, Mulgrave, Victoria 3170, Australia. Email: umberto.bonollo@nec.com.au Phone: +61 3 9264 3385 " DESCRIPTION " This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community for the purpose of managing VDSL2, ADSL, ADSL2, and ADSL2+ lines. The MIB module described in RFC 2662 [RFC2662] defines objects used for managing Asymmetric Bit-Rate DSL (ADSL) interfaces per [T1E1.413], [G.992.1], and [G.992.2]. These object descriptions are based upon the specifications for the ADSL Embedded Operations Channel (EOC) as defined in American National Standards Institute (ANSI) T1E1.413 [T1E1.413] and International Telecommunication Union (ITU-T) G.992.1 [G.992.1] and G.992.2 [G.992.2]. The MIB module described in RFC 4706 [RFC4706] defines objects used for managing ADSL2 interfaces per [G.992.3] and [G.992.4], and ADSL2+ interfaces per [G.992.5]. That MIB is also capable of managing ADSL interfaces per [T1E1.413], [G.992.1], and [G.992.2]. This document does not obsolete RFC 2662 [RFC2662] and RFC 4706 [RFC4706], but rather provides a more comprehensive management model that manages VDSL2 interfaces per G.993.2 [G.993.2] as well as ADSL, ADSL2 and ADSL2+ technologies per T1E1.413, G.992.1, G.992.2, G.992.3, G.992.4, and G.992.5 ([T1E1.413], [G.992.1], [G.992.2], [G.992.3], [G.992.4], and [G.992.5] respectively). Additionally, the management framework for VDSL2 lines Morgenstern, et al. Expires August 29, 2007 [Page 54] Internet-Draft VDSL2-LINE MIB February 2007 specified by the Digital Subscriber Line Forum (DSLF) has been taken into consideration [TR-129]. That framework is based on ITU-T G.997.1 standard [G.997.1]. The MIB module is located in the MIB tree under MIB 2 transmission, as discussed in the MIB-2 Integration (RFC 2863 [RFC2863]) section of this document. Copyright (C) The Internet Society (2007). This version of this MIB module is part of RFC XXXX: see the RFC itself for full legal notices." -- RFC Ed.: replace XXXX with assigned number & remove this note REVISION "200702260000Z" -- February 26, 2007 DESCRIPTION "Initial version, published as RFC XXXX." -- RFC Ed.: replace XXXX with assigned number & remove this note ::= { transmission xxx } -- IANA, we suggest to put it under { transmission xxx } because -- this is the first available number. -- RFC Ed.: Please fill in xxx once assigned by IANA. vdsl2 OBJECT IDENTIFIER ::= { vdsl2MIB 1 } ------------------------------------------------ xdsl2Line OBJECT IDENTIFIER ::= { vdsl2 1 } xdsl2Status OBJECT IDENTIFIER ::= { vdsl2 2 } xdsl2Inventory OBJECT IDENTIFIER ::= { vdsl2 3 } xdsl2PM OBJECT IDENTIFIER ::= { vdsl2 4 } xdsl2Profile OBJECT IDENTIFIER ::= { vdsl2 5 } xdsl2Scalar OBJECT IDENTIFIER ::= { vdsl2 6 } xdsl2Notifications OBJECT IDENTIFIER ::= { vdsl2 0 } xdsl2Conformance OBJECT IDENTIFIER ::= { vdsl2 7 } ------------------------------------------------ xdsl2PMLine OBJECT IDENTIFIER ::= { xdsl2PM 1 } xdsl2PMChannel OBJECT IDENTIFIER ::= { xdsl2PM 2 } ------------------------------------------------ xdsl2ProfileLine OBJECT IDENTIFIER ::= { xdsl2Profile 1 } xdsl2ProfileChannel OBJECT IDENTIFIER ::= { xdsl2Profile 2 } xdsl2ProfileAlarmConf OBJECT IDENTIFIER ::= { xdsl2Profile 3 } ------------------------------------------------ xdsl2ScalarSC OBJECT IDENTIFIER ::= { xdsl2Scalar 1 } ------------------------------------------------ ------***************************************************** ------ Should revise all references in this MIB ------***************************************************** ------------------------------------------------ Morgenstern, et al. Expires August 29, 2007 [Page 55] Internet-Draft VDSL2-LINE MIB February 2007 -- xdsl2LineTable -- ------------------------------------------------ xdsl2LineTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2LineEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineTable contains configuration, command and status parameters of the VDSL2/ADSL/ADSL2 or ADSL2+ line. The index of this table is an interface index where the interface has an ifType of vdsl2(xxx). Several objects in this table MUST be maintained in a persistent manner. " ::= { xdsl2Line 1 } xdsl2LineEntry OBJECT-TYPE SYNTAX Xdsl2LineEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineTable contains configuration, commands and status parameters of the VDSL2/ADSL/ADSL2 or ADSL2+ line." INDEX { ifIndex } ::= { xdsl2LineTable 1 } Xdsl2LineEntry ::= SEQUENCE { xdsl2LineCnfgTemplate SnmpAdminString, xdsl2LineAlarmCnfgTemplate SnmpAdminString, xdsl2LineCmndConfPmsf Xdsl2ConfPmsForce, xdsl2LineCmndConfLdsf Xdsl2LineLdsf, xdsl2LineCmndConfLdsfFailReason Xdsl2LdsfResult, xdsl2LineCmndAutomodeColdStart TruthValue, xdsl2LineStatusXtuTransSys Xdsl2TransmissionModeType, xdsl2LineStatusPwrMngState Xdsl2PowerMngState, xdsl2LineStatusInitResult Xdsl2InitResult, xdsl2LineStatusLastStateDs Xdsl2LastTransmittedState, xdsl2LineStatusLastStateUs Xdsl2LastTransmittedState, xdsl2LineStatusXtur Xdsl2LineStatus, xdsl2LineStatusXtuc Xdsl2LineStatus, xdsl2LineStatusAttainableRateDs Unsigned32, xdsl2LineStatusAttainableRateUs Unsigned32, xdsl2LineStatusActPsdDs Integer32, xdsl2LineStatusActPsdUs Integer32, xdsl2LineStatusActAtpDs Integer32, Morgenstern, et al. Expires August 29, 2007 [Page 56] Internet-Draft VDSL2-LINE MIB February 2007 xdsl2LineStatusActAtpUs Integer32 } xdsl2LineCnfgTemplate OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the row in the xDSL2 Line Configuration Templates Table, (xdsl2LineConfTemplateTable), which applies for this line. This object MUST be maintained in a persistent manner." REFERENCE "DSL Forum TR-129, paragraph #5.1" DEFVAL { "DEFVAL" } ::= { xdsl2LineEntry 1 } xdsl2LineAlarmCnfgTemplate OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the row in the xDSL2 Line Alarm Configuration Template Table, (xdsl2LineAlarmConfTemplateTable), which applies to this line. This object MUST be maintained in a persistent manner." REFERENCE "DSL Forum TR-129, paragraph #5.1" DEFVAL { "DEFVAL" } ::= { xdsl2LineEntry 2 } xdsl2LineCmndConfPmsf OBJECT-TYPE SYNTAX Xdsl2ConfPmsForce MAX-ACCESS read-write STATUS current DESCRIPTION "Power management state forced (PMSF). Defines the line states to be forced by the near-end xTU on this line. The various possible values are: l3toL0 (0), l0toL2 (2), l0orL2toL3 (3). This object MUST be maintained in a persistent manner." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.1.3" DEFVAL { l3toL0 } Morgenstern, et al. Expires August 29, 2007 [Page 57] Internet-Draft VDSL2-LINE MIB February 2007 ::= { xdsl2LineEntry 3 } xdsl2LineCmndConfLdsf OBJECT-TYPE SYNTAX Xdsl2LineLdsf MAX-ACCESS read-write STATUS current DESCRIPTION "Loop diagnostics mode forced (LDSF). Defines whether the line should be forced into the loop diagnostics mode by the near-end xTU on this line or only be responsive to loop diagnostics initiated by the far-end xTU. This object MUST be maintained in a persistent manner. However, in case the operator forces loop diagnostics mode then the access node should reset the object (inhibit) when loop diagnostics mode procedures are completed." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.1.8" DEFVAL { inhibit } ::= { xdsl2LineEntry 4 } xdsl2LineCmndConfLdsfFailReason OBJECT-TYPE SYNTAX Xdsl2LdsfResult MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the recent occasion the Loop diagnostics mode forced (LDSF) was issued for the associated line. Possible values are: none (1) - The default value in case LDSF was never requested for the associated line. success (2) - The recent command completed successfully. inProgress (3) - The Loop Diagnostics process is in progress. unsupported (4) - The NE or the line card doesn't support LDSF. cannotRun (5) - The NE cannot initiate the command, due to a non specific reason. aborted (6) - The Loop Diagnostics process aborted. failed (7) - The Loop Diagnostics process failed. illegalMode (8) - The NE cannot initiate the command, due to the specific mode of the relevant line. adminUp (9) - The NE cannot initiate the command, as the relevant line is administratively 'Up'. tableFull (10)- The NE cannot initiate the command, due Morgenstern, et al. Expires August 29, 2007 [Page 58] Internet-Draft VDSL2-LINE MIB February 2007 to reaching the maximum number of rows in the results table. noResources (11)- The NE cannot initiate the command, due to lack of internal memory resources." DEFVAL { none } ::= { xdsl2LineEntry 5 } xdsl2LineCmndAutomodeColdStart OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Automode cold start forced. This parameter is defined in order to improve testing of the performance of xTUs supporting automode when it is enabled in the MIB. Change the value of this parameter to 'true' indicates a change in loop conditions applied to the devices under test. The xTUs shall reset any historical information used for automode and for shortening G.994.1 handshake and initialization. Automode is the case where multiple operation-modes are enabled through the xdsl2LConfProfXtuTransSysEna object in the line configuration profile being used for the line, and where the selection of the actual operation-mode depends not only on the common capabilities of both xTUs (as exchanged in G.994.1), but also on achievable data rates under given loop conditions. This object MUST be maintained in a persistent manner." REFERENCE "ITU-T G.997.1, paragraph #7.3.1.1.10" DEFVAL { false } ::= { xdsl2LineEntry 6 } xdsl2LineStatusXtuTransSys OBJECT-TYPE SYNTAX Xdsl2TransmissionModeType MAX-ACCESS read-only STATUS current DESCRIPTION "The xTU Transmission System (xTS) in use. It is coded in a bit-map representation with one bit set to '1' (the selected coding for the DSL line). This parameter may be derived from the handshaking procedures defined in Recommendation G.994.1. A set of xDSL line transmission Morgenstern, et al. Expires August 29, 2007 [Page 59] Internet-Draft VDSL2-LINE MIB February 2007 modes, with one bit per mode. " REFERENCE "ITU-T G.997.1, paragraph #7.5.1.1" ::= { xdsl2LineEntry 7 } xdsl2LineStatusPwrMngState OBJECT-TYPE SYNTAX Xdsl2PowerMngState MAX-ACCESS read-only STATUS current DESCRIPTION "The current power management state. One of four possible power management states: L0 - Synchronized and full transmission (i.e., Showtime), L1 - Low Power with reduced net data rate (G.992.2 only), L2 - Low Power with reduced net data rate (G.992.3 and G.992.4 only), L3 - No power The various possible values are:l0(1), l1(2), l2(3), l3(4)." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.2" ::= { xdsl2LineEntry 8 } xdsl2LineStatusInitResult OBJECT-TYPE SYNTAX Xdsl2InitResult MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the result of the last full initialization performed on the line. It is an enumeration type with the following values: noFail(0), configError(1), configNotFeasible(2), commFail(3), noPeerAtu(4), otherCause(5)." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.3" ::= { xdsl2LineEntry 9 } xdsl2LineStatusLastStateDs OBJECT-TYPE SYNTAX Xdsl2LastTransmittedState MAX-ACCESS read-only STATUS current DESCRIPTION "The last successful transmitted initialization state in the downstream direction in the last full initialization performed on the line." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.4" ::= { xdsl2LineEntry 10 } xdsl2LineStatusLastStateUs OBJECT-TYPE SYNTAX Xdsl2LastTransmittedState MAX-ACCESS read-only STATUS current Morgenstern, et al. Expires August 29, 2007 [Page 60] Internet-Draft VDSL2-LINE MIB February 2007 DESCRIPTION "The last successful transmitted initialization state in the upstream direction in the last full initialization performed on the line." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.5" ::= { xdsl2LineEntry 11 } xdsl2LineStatusXtur OBJECT-TYPE SYNTAX Xdsl2LineStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates current state (existing failures) of the xTU-R. This is a bit-map of possible conditions. " REFERENCE "ITU-T G.997.1, paragraph #7.1.1.2" ::= { xdsl2LineEntry 12 } xdsl2LineStatusXtuc OBJECT-TYPE SYNTAX Xdsl2LineStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates current state (existing failures) of the xTU-C. This is a bit-map of possible conditions. " REFERENCE "ITU-T G.997.1, paragraph #7.1.1.1" ::= { xdsl2LineEntry 13 } xdsl2LineStatusAttainableRateDs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum Attainable Data Rate Downstream. The maximum downstream net data rate currently attainable by the xTU-C transmitter and the xTU-R receiver, coded in bit/s." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.12" ::= { xdsl2LineEntry 14 } xdsl2LineStatusAttainableRateUs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum Attainable Data Rate Upstream. The maximum upstream net data rate currently attainable by the Morgenstern, et al. Expires August 29, 2007 [Page 61] Internet-Draft VDSL2-LINE MIB February 2007 xTU-R transmitter and the xTU-C receiver, coded in bit/s." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.13" ::= { xdsl2LineEntry 15 } xdsl2LineStatusActPsdDs OBJECT-TYPE SYNTAX Integer32 (-900..0 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Power Spectrum Density (PSD) Downstream. The average downstream transmit PSD over the sub-carriers used for downstream. It ranges from -900 to 0 units of 0.1 dB (Physical values are -90 to 0 dBm/Hz). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.14" ::= { xdsl2LineEntry 16 } xdsl2LineStatusActPsdUs OBJECT-TYPE SYNTAX Integer32 (-900..0 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Power Spectrum Density (PSD) Upstream. The average upstream transmit PSD over the sub-carriers used for upstream. It ranges from -900 to 0 units of 0.1 dB (Physical values are -90 to 0 dBm/Hz). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.15" ::= { xdsl2LineEntry 17 } xdsl2LineStatusActAtpDs OBJECT-TYPE SYNTAX Integer32 (-310..310 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Aggregate Transmit Power Downstream. The total amount of transmit power delivered by the xTU-C at the U-C reference point, at the instant of measurement. It ranges from -310 to 310 units of 0.1 dB (Physical values are -31 to 31 dBm). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.16" Morgenstern, et al. Expires August 29, 2007 [Page 62] Internet-Draft VDSL2-LINE MIB February 2007 ::= { xdsl2LineEntry 18 } xdsl2LineStatusActAtpUs OBJECT-TYPE SYNTAX Integer32 (-310..310 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Aggregate Transmit Power Upstream. The total amount of transmit power delivered by the xTU-R at the U-R reference point, at the instant of measurement. It ranges from -310 to 310 units of 0.1 dB (Physical values are -31 to 31 dBm). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.17" ::= { xdsl2LineEntry 19 } ------------------------------------------------ -- xdsl2LineBandTable -- ------------------------------------------------ xdsl2LineBandTable OBJECT-TYPE SYNTAX SEQUENCE OF Xdsl2LineBandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineBandTable contains the, per-band line status parameters of the VDSL2/ADSL/ADSL2 or ADSL2+ line. The indexes of this table consist of an interface index where the interface has an ifType of vdsl2(xxx), together with a per-band index covering both VDSL2 and ADSL/ADSL2/ADSL2+." ::= { xdsl2Line 2 } xdsl2LineBandEntry OBJECT-TYPE SYNTAX Xdsl2LineBandEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table xdsl2LineBandTable contains the, per-band line status parameters of the VDSL2/ADSL/ADSL2 or ADSL2+ line." INDEX { ifIndex, xdsl2LineBand } ::= { xdsl2LineBandTable 1 } Xdsl2LineBandEntry ::= SEQUENCE { Morgenstern, et al. Expires August 29, 2007 [Page 63] Internet-Draft VDSL2-LINE MIB February 2007 xdsl2LineBand Xdsl2Band, xdsl2LineBandStatusLnAtten Unsigned32, xdsl2LineBandStatusSigAtten Unsigned32, xdsl2LineBandStatusSnrMargin Integer32 } xdsl2LineBand OBJECT-TYPE SYNTAX Xdsl2Band MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identifies the band(s) associated with this line. For ADSL/ADSL2/ADSL2+ the values upstream(1) and downstream(2) will always be present. For VDSL2, a subset of {us0(3), ds1(4), us1(5) ... } will always be present (See Xdsl2Band for more details)." ::= { xdsl2LineBandEntry 1 } xdsl2LineBandStatusLnAtten OBJECT-TYPE SYNTAX Unsigned32 (0..1270 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "When referring to a band in the downstream direction, it is the measured difference in the total power transmitted by the xTU-C and the total power received by the xTU-R over all sub-carriers of that band during loop diagnostics mode and initialization. When referring to a band in the upstream direction, it is the measured difference in the total power transmitted by the xTU-R and the total power received by the xTU-C over all sub-carriers of that band during loop diagnostics mode and initialization. Values range from 0 to 1270 in units of 0.1 dB (Physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the line attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the line attenuation measurement is unavailable." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.9 (LATNds) and paragraph #7.5.1.10 (LATNus)6" ::= { xdsl2LineBandEntry 2 } xdsl2LineBandStatusSigAtten OBJECT-TYPE SYNTAX Unsigned32 (0..1270 | 2147483646 | 2147483647) UNITS "0.1 dB" Morgenstern, et al. Expires August 29, 2007 [Page 64] Internet-Draft VDSL2-LINE MIB February 2007 MAX-ACCESS read-only STATUS current DESCRIPTION "When referring to a band in the downstream direction, it is the measured difference in the total power transmitted by the xTU-C and the total power received by the xTU-R over all sub-carriers of that band during Showtime. When referring to a band in the upstream direction, it is the measured difference in the total power transmitted by the xTU-R and the total power received by the xTU-C over all sub-carriers of that band during Showtime. Values range from 0 to 1270 in units of 0.1 dB (Physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the line attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the line attenuation measurement is unavailable." REFERENCE "ITU-T G.997.1, paragraph #7.5.1.11 (SATNds) and paragraph #7.5.1.12 (SATNus)" ::= { xdsl2LineBandEntry 3 } xdsl2LineBandStatusSnrMargin OBJECT-TYPE SYNTAX Integer32 (-640..630 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "SNR Margin is the maximum increase in dB of the noise power received at the XTU (xTU-R for a band in the downstream direction and xTU-C for a band in the upstream direction), such that the BER requirements are met for all bearer channels received at the XTU. Values range from -640 to 630 in units of 0