📄 rfc2662.txt
字号:
4.2 Relationship with RFC 2037 [25]
Implementation of the Entity MIB [25] is optional. It in no way
alters the information required in the adslLineMib, nor does it alter
the relationship with IF-MIB.
The Entity MIB introduces a standardized way of presenting the
components of complex systems, such as a Digital Subscriber Line
Access Multiplexer (DSLAM), that may contain multiple racks, shelves,
line cards, and/or ports. The Entity MIB's main goal is to present
these system components, their containment relationship, and mapping
information with other MIBs such as the Interface MIB and the
adslLineMib.
If ATU-C agent is implemented, the Entity MIB should include entities
for the ATU-C in the entPhysicalTable. The MIB's
entAliasMappingTable would contain mapping information identifying
the 'ifIndex' object associated with each ATU-C. However, if ATU-R
agent is implemented, the Entity MIB should include entities for the
ATU-R in the entPhysicalTable. In this case, the MIB's
entAliasMappingTable would contain mapping information identifying
the 'ifIndex' object associated with each ATU-R.
Also associating the relationship between the ifTable and Entity MIB,
the entPhysicalTable contains an 'entPhysicalName' object, which
approximates the semantics of the 'ifName' object from the Interface
MIB.
5. Conventions used in the MIB
5.1 Naming Conventions
A. Atuc/Atur are used for the ATU-C and ATU-R. In other RFCs, these
are sometimes referred to as the Near End (Ne) and Far End (Fe)
respectively, but not in this document.
B. The terms, "transmit" and "receive", are from the perspective of
the corresponding table's end of the line. For example, in the
case of Fast channels, adslAtucChanConfFastMaxTxRate defines the
"downstream" rate, while adslAturChanConfFastMaxTxRate defines the
"upstream" rate for a particular channel.
C. There are two possible channels: fast, and interleaved. None, one
or both may be implemented on a particular ADSL Line. Figure 5
illustrates all possible operational configurations.
Bathrick & Ly Standards Track [Page 7]
RFC 2662 ADSL Line MIB August 1999
D. Lof, Lol, Los, Lpr mean Loss of Framing, Link, Signal, and Power,
respectively. Lpr is used by T1E1, so it is used for consistency
(rather than Lop).
A Loss of Link condition is declared at the ATU-C if a Loss of
Signal is not preceded by a `dying-gasp' message from the ATU-R.
Note that Loss of Link is only supported by the ATU-C.
E. ES means errored second. An Errored Second is any second
containing one or more CRC anomaly, or one or more Los(s) or
Severely Errored Frame (Sef) defect(s).
F. A "block" is a physical-layer `data buffer' over which CRCs are
calculated. For example, in DMT, the block is defined as the ADSL
superframe. The block duration is 250 micro-seconds so the block
length in bytes, as defined in adslAtu*ChanCrcBlockLength, varies
with data rate. See Line Code Specific MIBs [11] [12] for more
line code specific information.
G. Atn means Attenuation, Psd is Power Spectral Density and Snr is
Signal to Noise Ratio.
H. LCS means line code specific, e.g.,
o DMT = Discrete MultiTone
o CAP = Carrierless Amplitude and Phase modulation and
o QAM = Quadrature Amplitude Modulation
I. Vendor (in the Inventory objects) refers to the manufacturer of
the ATU-C or ATU-R assembly, not the modem chip vendor. When in
doubt, use the manufacturer of the smallest field replaceable unit
(e.g., stand-alone modem box, plug-in board).
J. RADSL - Rate Adaptive Asymmetric Digital Subscriber Loop
5.2 Structure
The MIB has multiple parallel tables. There are tables for:
o line - common attributes
o atuc and atur status
Bathrick & Ly Standards Track [Page 8]
RFC 2662 ADSL Line MIB August 1999
o atuc and atur performance
- Current and up to 96 buckets of 15 min performance history
- Current and Previous 1-day bucket performance history
o profiles - configuration parameters and alarm parameters
There are separate tables for Physical and Channel layers. Since
their attributes are similar, only one set of "channel" tables are
defined to be used for both fast and interleaved channels. The
corresponding ifType gives the proper interpretation for that
ifEntry.
It is intented that Line Code Specific MIBs be located under
adslLCSMib. These MIBs will be defined in separate modules.
There could have been fewer tables by combining the ATU-C and ATU-R
information into shared tables. However, the tables are more easily
read when there are two identical sets of data.
The figure below lists the five possible ADSL operational
configurations. (indicated by the value of the adslLineType). In all
configurations, the physical line interface entry will exist.
However, the existence of the ADSL channel varies in each case, as
shown below.
Table Phys Fast Interleaved
___________________________________________________________
No Channels (1) | Y | | |
Fast Only (2) | Y | Y | |
Interleaved Only (3) | Y | | Y |
Fast or Interleaved (4) | Y | Y | Y |
Fast and Interleaved (5) | Y | Y | Y |
Figure 5: ADSL Operational configurations
NOTE: In (4), channel exists of either Fast or Interleaved type, but
not both. The Manager may select the type of channel to be used.
Depending on which operation configuration exists, some or all ADSL
MIB tables could be supported, as shown in below. See Conformance
Statements for more information on which objects are mandatory.
Bathrick & Ly Standards Track [Page 9]
RFC 2662 ADSL Line MIB August 1999
Table Phys Fast Interleaved
___________________________________________________________
adslLineTable | Y | | |
adslAtucPhysTable | Y | | |
adslAturPhysTable | Y | | |
adslAtucChanTable | | Y | Y |
adslAturChanTable | | Y | Y |
adslAtucPerfDataTable | Y | | |
adslAturPerfDataTable | Y | | |
adslAtucIntervalTable | Y | | |
adslAturIntervalTable | Y | | |
adslAtucChanPerfDataTable | | Y | Y |
adslAturChanPerfDataTable | | Y | Y |
adslAtucChanIntervalTable | | Y | Y |
adslAturChanIntervalTable | | Y | Y |
Figure 6: Use of ADSL MIB Tables with various ifIndex values
NOTE: The adslLineConfProfileTable and adslLineAlarmConfProfileTable
will be present for all scenarios. See Profile Section of this
document for implementation details such as profile creation,
assignment, and indexing.
5.2.1 Structure of Conformance Groups
The MIB is organized to cover both ends of the ADSL line, ATU-C and
ATU-R. Objects defined can be categorized into two groups: the
ATU-C group which provides objects that are supported by ATU-C agents
and the ATU-R group which provides objects that are supported by
ATU-R agents. These two groups are defined by the conformance
section of the MIB. All objects defined in the MIB module are
supported by the ATU-C agent and only portions of the objects are
supported by the ATU-R agent. Figure 7 lists all tables/objects that
are supported by the ATU-R agent.
Bathrick & Ly Standards Track [Page 10]
RFC 2662 ADSL Line MIB August 1999
Table Objects
_______________________________________________________
adslLineTable adslLineCoding
adslAtucPhysTable adslAtucInvVendorID
adslAtucInvVersionNumber
adslAtucCurrStatus (Partial)
adslAtucCurrOutputPwr
adslAtucCurrAttainableRate
adslAturPhysTable all are supported
adslAtucChanTable all except
adslAtucChanCrcBlockLength
are supported
adslAtucPerfDataTable all except
adslAtucPerfLols,
adslAtucPerfLprs
adslAtucPerfCurr15MinLols,
adslAtucPerfCurr15MinLprs,
adslAtucPerfCurr1DayLols,
adslAtucPerfCurr1DayLprs,
adslAtucPerfPrev1DayLols and
adslAtucPerfPrev1DayLprs
are supported
adslAturPerfDataTable all are supported
adslAtucIntervalTable adslAtucIntervalLofs
adslAtucIntervalLoss
adslAtucIntervalESs
adslAtucIntervalInits
adslAtucIntervalValidData
adslAturIntervalTable all are supported
adslAtucChanPerfDataTable all are supported
adslAturChanPerfDataTable all are supported
adslAtucChanIntervalTable all are supported
adslAturChanIntervalTable all are supported
adslLineConfProfileTable not supported
adslLineAlarmConfProfileTable all are supported except
adslAtucThresh15MinLols
and adslAtucThresh15MinLprs
--------------------------------------------------------------------
Figure 7: MIB Tables and Objects Supported by the ATU-R Agent
Bathrick & Ly Standards Track [Page 11]
RFC 2662 ADSL Line MIB August 1999
All traps supported by the ATU-R agent are also listed:
adslAtucPerfLofsThreshTrap
adslAtucPerfLossThreshTrap
adslAtucPerfESsThreshTrap
adslAtucRateChangeTrap
adslAturPerfLofsThreshTrap
adslAturPerfLossThreshTrap
adslAturPerfLprsThreshTrap
adslAturPerfESsThreshTrap
adslAturRateChangeTrap
5.3 Counters, Interval Buckets and Thresholds
For physical-level ES, Los, Lof, Lol, Lpr and line initialization
attempts, there are event counters, current 15-minute and one (up to
96) 15-minute history bucket(s) of "interval-counters", as well as
current and previous 1-day interval-counters. Each physical-layer
current 15-minute event bucket has threshold trap.
At the channel level, there are counters for total received blocks,
received-and-corrected blocks, received-but-uncorrectable blocks, and
transmitted blocks. There are the same set of 15-minute and 1-day
buckets as at the physical-layer.
There is no requirement for an agent to ensure fixed relationship
between the start of a fifteen minute 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 start of a day.
Separate tables are provided for the 96 interval-counters. They are
indexed by {ifIndex, AdslAtu*IntervalNumber}.
Counters are not reset when an ATU-C or ATU-R is reinitialized, only
when the agent is reset or reinitialized (or under specific request
outside the scope of this MIB).
The 15-minute event counters are of type PerfCurrentCount and
PerfIntervalCount. The 1-day event counters are of type
AdslPerfCurrDayCount and AdslPerfPrevDayCount. Both 15-minute and 1-
day time elapsed counters are of type AdslPerfTimeElapsed.
Bathrick & Ly Standards Track [Page 12]
RFC 2662 ADSL Line MIB August 1999
5.4 Profiles
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -