Network Working Group B. Ray Request for Comments: 3728 PESA Switching Systems Category: Standards Track R. Abbi Alcatel February 2004 Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved.Abstract
This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing Very High Speed Digital Subscriber Line (VDSL) interfaces.Table of Contents
1. The Internet-Standard Management Framework . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Relationship of the VDSL Line MIB Module to other MIB Modules. . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2. Conventions used in the MIB Module . . . . . . . . . . . 4 2.3. Structure. . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Counters, Interval Buckets and Thresholds. . . . . . . . 7 2.5. Profiles . . . . . . . . . . . . . . . . . . . . . . . . 8 2.6. Notifications. . . . . . . . . . . . . . . . . . . . . . 9 2.7. Persistence. . . . . . . . . . . . . . . . . . . . . . . 10 3. Conformance and Compliance . . . . . . . . . . . . . . . . . . 11 4. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 72 6.2. Informative References . . . . . . . . . . . . . . . . . 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 74
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 75 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 761. 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 [RFC2119].2. Overview
This document describes an SNMP MIB module for managing VDSL Lines. These definitions are based upon the specifications for VDSL as defined in T1E1, ETSI, and ITU documentation [T1E1311, T1E1011, T1E1013, ETSI2701, ETSI2702, ITU9931, ITU9971]. 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 of the VDSL Line MIB Module to other MIB Modules
This section outlines the relationship of this MIB with other MIBs described in RFCs. Specifically, IF-MIB as presented in RFC 2863 [RFC2863] is discussed.2.1.1. General IF-MIB Integration (RFC 2863)
The VDSL 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 ifType to VDSL:
IANAifType ::= TEXTUAL-CONVENTION ... SYNTAX INTEGER { ... vdsl(97), -- Very H-speed Digital Subscrib. Loop ... } Additionally, a VDSL line may contain an optional fast channel and an optional interleaved channel which also integrate into RFC 2863 [RFC2863]. The IANA has assigned the following ifTypes to these channels: IANAifType ::= TEXTUAL-CONVENTION ... SYNTAX INTEGER { ... interleave (124), -- Interleave channel fast (125), -- Fast channel ... }2.1.2. Usage of ifTable
The MIB branch identified by this ifType contains tables appropriate for this interface type. Most tables extend the ifEntry table, and are indexed by ifIndex. For interfaces in systems implementing this MIB, those table entries indexed by ifIndex MUST be persistent. The following attributes are part of the mandatory ifGeneral group in RFC 2863 [RFC2863], and are not duplicated in the VDSL Line MIB. =================================================================== ifIndex Interface index. ifDescr See interfaces MIB [RFC2863]. ifType vdsl(97), interleave(124), or fast(125) ifSpeed Set as appropriate. ifPhysAddress This object MUST have an octet string with zero length. ifAdminStatus See interfaces MIB [RFC2863].
ifOperStatus See interfaces MIB [RFC2863]. ifLastChange See interfaces MIB [RFC2863]. ifName See interfaces MIB [RFC2863]. ifHighSpeed Set as appropriate. ifConnectorPresent Set as appropriate. ifLinkUpDownTrapEnable Default to enabled(1). =================================================================== Figure 1: Use of ifTable Objects Section 2.3, below, describes the structure of this MIB in relation to ifEntry in greater detail.2.2. Conventions used in the MIB Module
2.2.1. Naming Conventions
A. Vtuc -- (VTUC) transceiver at near (Central) end of line B. Vtur -- (VTUR) transceiver at Remote end of line C. Vtu -- One of either Vtuc or Vtur D. Curr -- Current E. Prev -- Previous F. Atn -- Attenuation G. ES -- Errored Second H. SES -- Severely Errored Second I. UAS -- Unavailable Second J. LCS -- Line Code Specific K. Lof -- Loss of Frame L. Lol -- Loss of Link M. Los -- Loss of Signal N. Lpr -- Loss of Power O. xxxs -- Sum of Seconds in which xxx has occured (e.g., xxx = Lof, Los, Lpr, Lol) P. Max -- Maximum Q. Mgn -- Margin R. Min -- Minimum S. Psd -- Power Spectral Density T. Snr -- Signal to Noise Ratio U. Tx -- Transmit V. Blks -- Blocks
2.2.2. Textual Conventions
The following textual conventions are defined to reflect the line topology in the MIB (further discussed in the following section) and to define the behavior of the statistics to be maintained by an agent. o VdslLineCodingType : Attributes with this syntax identify the line coding used. Specified as an INTEGER, the three values are: other(1) -- none of the following mcm(2) -- Multiple Carrier Modulation scm(3) -- Single Carrier Modulation o VdslLineEntity : Attributes with this syntax reference the two sides of a line. Specified as an INTEGER, the two values are: vtuc(1) -- central site transceiver vtur(2) -- remote site transceiver2.3 Structure
The MIB is structured into the following MIB groups: o vdslGroup : This group supports all line code independent MIB objects found in this MIB. The following tables contain objects permitted for ifType vdsl(97): - vdslLineTable - vdslPhysTable - vdslPerfDataTable - vdslPerfIntervalTable - vdslPerf1DayIntervalTable - vdslLineConfProfileTable - vdslLineAlarmConfProfileTable
The following tables contain objects permitted for ifTypes interleave(124) and (fast): - vdslChanTable - vdslChanPerfDataTable - vdslChanPerfIntervalTable - vdslChanPerf1DayIntervalTable Figure 2, below, displays the relationship of the tables in the vdslGroup to ifEntry (and each other): ifEntry(ifType=97) ---> vdslLineTableEntry 1:(0 to 1) vdslLineTableEntry ---> vdslPhysTableEntry 1:(0 to 2) ---> vdslPerfDataEntry 1:(0 to 2) ---> vdslLineConfProfileEntry 1:(0 to 1) ---> vdslLineAlarmConfProfileEntry 1:(0 to 1) vdslPhysTableEntry ---> vdslPerfIntervalEntry 1:(0 to 96) ---> vdslPerf1DayIntervalEntry 1:(0 to 30) ifEntry(ifType=124) ---> vdslChanEntry 1:(0 to 2) ---> vdslChanPerfDataEntry 1:(0 to 2) ifEntry(ifType=125) ---> vdslChanEntry 1:(0 to 2) ---> vdslChanPerfDataEntry 1:(0 to 2) vdslChanEntry ---> vdslchanPerfIntervalEntry 1:(0 to 96) ---> vdslchan1DayPerfIntervalEntry 1:(0 to 30) Figure 2: Table Relationships o vdslNotificationGroup : This group contains definitions of VDSL line notifications. Section 2.6, below, presents greater detail on the notifications defined within the MIB module.
2.3.1. Line Topology
A VDSL Line consists of two units - a Vtuc (the central transceiver unit) and a Vtur (the remote transceiver unit). <-- Network Side Customer Side --> |<////////// VDSL Line ///////////>| +-------+ +-------+ | | | | | Vtuc +------------------+ Vtur | | | | | +-------+ +-------+ Figure 3: General topology for a VDSL Line2.4. Counters, Interval Buckets and Thresholds
For Loss of Frame (lof), Loss of Link (lol), Loss of Signal (los), and Loss of Power (lpr), Errored Seconds (ES), Severely Errored Seconds (SES), and Unavailable Seconds (UAS) there are event counters, current 15-minute, 0 to 96 15-minute history bucket(s), and 0 to 30 1-day history bucket(s) of "interval-counters". Each current 15-minute event bucket has an associated threshold notification. Each of these counters uses the textual conventions defined in the HC-PerfHist-TC-MIB [RFC3705]. The HC-PerfHist-TC-MIB defines 64-bit versions of the textual conventions found in RFC 3593 [RFC3593]. There is no requirement for an agent to ensure a fixed relationship between the start of a fifteen minute interval and any wall clock; however, some implementations may align the fifteen 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 a Vtu is reinitialized, only when the agent is reset or reinitialized (or under specific request outside the scope of this MIB module).
2.5. Profiles
As a managed node can handle a large number of Vtus, (e.g., hundreds or perhaps thousands of lines), provisioning every parameter on every Vtu may become burdensome. Moreover, most lines are provisioned identically with the same set of parameters. To simplify the provisioning process, this MIB makes use of profiles. A profile is a set of parameters that can be shared by multiple lines using the same configuration. The following profiles are used in this MIB module: o Line Configuration Profiles - Line configuration profiles contain parameters for configuring VDSL lines. They are defined in the vdslLineConfProfileTable. o Alarm Configuration Profiles - These profiles contain parameters for configuring alarm thresholds for VDSL transceivers. These profiles are defined in the vdslLineAlarmConfProfileTable. One or more lines may be configured to share parameters of a single profile by setting their vdslLineConfProfile objects to the value of this profile. If a change is made to the profile, all lines that refer to it will be reconfigured to the changed parameters. Before a profile can be deleted or taken out of service it must be first unreferenced from all associated lines. Implementations MUST provide a default profile with an index value of 'DEFVAL' for each profile type. The values of the associated parameters will be vendor specific unless otherwise indicated in this document. Before a line's profiles have been set, these profiles will be automatically used by setting vdslLineConfProfile and vdslLineAlarmConfProfile to 'DEFVAL' where appropriate. This default profile name, 'DEFVAL', is considered reserved in the context of profiles defined in this MIB module. Profiles are created, assigned, and deleted dynamically using the profile name and profile row status in each of the ten profile tables (nine line configuration tables and one alarm configuration table). Profile changes MUST take effect immediately. These changes MAY result in a restart (hard reset or soft restart) of the units on the line.
2.6. 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., VDSL line) is required. The notifications defined in this MIB are for initialization failure and for the threshold crossings associated with the following events: lof, lol, los, lpr, ES, SES, and UAS. Each threshold has its own enable/threshold value. When that value is 0, the notification is disabled. A linkDown notification MAY be generated whenever any of lof, lol, los, lpr, ES, SES, or UAS threshold crossing event (as defined in this MIB module) occurs. The corresponding linkUp notification MAY be sent when all link failure conditions are cleared. The vdslPhysCurrStatus is a bitmask representing all outstanding error conditions associated with a particular VDSL transceiver. Note that since status of remote transceivers is obtained via the EOC, this information may be unavailable for units that are unreachable via the 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 this object are defined. A threshold notification occurs whenever the corresponding current 15-minute interval error counter becomes equal to, or exceeds the threshold value. One notification may be sent per interval per interface. Since the current 15-minute counters are reset to 0 every 15 minutes, 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. 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.
2.7. Persistence
All read-write and read-create objects defined in this MIB module SHOULD be stored persistently. Following is an exhaustive list of these persistent objects: - vdslLineConfProfile - vdslLineAlarmConfProfile - vdslLineConfProfileName - vdslLineConfDownRateMode - vdslLineConfUpRateMode - vdslLineConfDownMaxPwr - vdslLineConfUpMaxPwr - vdslLineConfDownMaxSnrMgn - vdslLineConfDownMinSnrMgn - vdslLineConfDownTargetSnrMgn - vdslLineConfUpMaxSnrMgn - vdslLineConfUpMinSnrMgn - vdslLineConfUpTargetSnrMgn - vdslLineConfDownFastMaxDataRate - vdslLineConfDownFastMinDataRate - vdslLineConfDownSlowMaxDataRate - vdslLineConfDownSlowMinDataRate - vdslLineConfUpFastMaxDataRate - vdslLineConfUpFastMinDataRate - vdslLineConfUpSlowMaxDataRate - vdslLineConfUpSlowMinDataRate - vdslLineConfDownRateRatio - vdslLineConfUpRateRatio - vdslLineConfDownMaxInterDelay - vdslLineConfUpMaxInterDelay - vdslLineConfDownPboControl - vdslLineConfUpPboControl - vdslLineConfDownPboLevel - vdslLineConfUpPboLevel - vdslLineConfDeploymentScenario - vdslLineConfAdslPresence - vdslLineConfApplicableStandard - vdslLineConfBandPlan - vdslLineConfBandPlanFx - vdslLineConfBandOptUsage - vdslLineConfUpPsdTemplate - vdslLineConfDownPsdTemplate - vdslLineConfHamBandMask - vdslLineConfCustomNotch1Start - vdslLineConfCustomNotch1Stop - vdslLineConfCustomNotch2Start - vdslLineConfCustomNotch2Stop
- vdslLineConfDownTargetSlowBurst - vdslLineConfUpTargetSlowBurst - vdslLineConfDownMaxFastFec - vdslLineConfUpMaxFastFec - vdslLineConfLineType - vdslLineConfProfRowStatus - vdslLineAlarmConfProfileName - vdslLineAlarmConfThresh15MinLofs - vdslLineAlarmConfThresh15MinLoss - vdslLineAlarmConfThresh15MinLprs - vdslLineAlarmConfThresh15MinLols - vdslLineAlarmConfThresh15MinESs - vdslLineAlarmConfThresh15MinSESs - vdslLineAlarmConfThresh15MinUASs - vdslLineAlarmConfInitFailure - vdslLineAlarmConfProfRowStatus It should also be noted that interface indices in this MIB are maintained persistently. VACM data relating to these SHOULD be stored persistently as well [RFC3415].3. Conformance and Compliance
For VDSL lines, the following groups are mandatory: - vdslGroup - vdslNotificationGroup