2.4.1 ADSL MIB (adslmib)

NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98


Michael Sneed <mike.sneed@pulse.com>
David Allan <dallan@nortel.ca>

Operations and Management Area Director(s):

Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <wijnen@vnet.ibm.com>

Operations and Management Area Advisor:

Bert Wijnen <wijnen@vnet.ibm.com>

Technical Advisor(s):

Kaj Tesink <kaj@cc.bellcore.com>


Greg Bathrick <bathricg@agcs.com>

Mailing Lists:

General Discussion:adsl@xlist.agcs.com
To Subscribe: mgr@xlist.agcs.com
In Body: subscribe/unsubscribe adsl
Archive: www.agcs.com/adsl/

Description of Working Group:

The ADSL Working Group is chartered to define a set of managed objects to be used for management of Asymmetric Digital Subscriber Line services as defined by ANSI T1.413. The initial effort will define those management objects common to all ADSL lines regardless of line-code. The devices to be managed using these managed objects will include:

1) Access provider equipment containing ATU-C modems, such as DSLAMs, and

2) Subscriber equipment containing ATU-R modems such as routers, NIC cards, and standalone modem devices.

The MIBs defined by this group will be generated using SMIv2, will be consistent with the SNMP management framework, and will describe the relationship of the objects defined to existing MIBs such as those described by RFC2233, and RFC1695. The working group will consider the input of the ADSL forum, and will utilize the existing ADSL Forum line MIB as a starting point for its work when that document is submitted as an Internet Draft. The working group plans on producing a single standards track MIB suitable for use in both access provider and subscriber equipment.

Goals and Milestones:

Jul 98


Submit Internet-Draft to cover subscriber equipment

Aug 98


Meet at Chicago IETF to review Internet-Drafts

Nov 98


Submit Internet-Draft to IESG for consideration as Proposed Standard.


No Request For Comments

Current Meeting Report

Minutes, Chicago IETF ADSL WG
Meeting convened at 9am Friday August

Chairs: Mike Sneed mike.sneed@rtp.pulse.com

Reported by: Dave Allan

Attendees: 20

- agenda bashing
- report on MIB activity
- report on related ADSLF activity
- new version of MIB I-D
- summary of changes
- comments
- path forward for I-D
- Presentation
- Plan
- close

Report on ADSL Forum activity (Greg Bathrick, bathricg@agcs.com) noted original
ASN.1 content came from ADSLF.
- new work at ADSLF
- DMT line code specific MIB
- CAP line code specific MIB
- CMIP version of line MIB
- ADSLF TR-006 (original MIB def'n) will be revised to ref

- planning going forward for a new test MIB for DSL.

Q: will ADSL Forum retain control of the new MIBs or will change control
come to IETF?
A: Planning will continue at ADSL Singapore meeting. Intent to finalize DMP,
CAP CMIP work and review test MIB. Decision as to delegation of the
MIBs to IETF has not yet been made.

New Draft (Greg Bathrick)
- implementations progressing by a number of companies, Ericcson, 3Com, Motorola,
- summary of changes

1) IETFing the MIB
2) Comments from Bert and TA Kaj Tesnick
3) Security considerations added
4) Corrections, omissions and clarifications
5) SNMP v3 Conformance
6) Conformance statements mandatory
- inventory & current group objects configuration profiles performance subset
- exception conditional ability to define performance profiles and assign them to an
interface optional
- raw counters, interval counters, channel counters historical note: work originates
with telecom business style at ADSLF, buckets 2-96 are optional. There are
currently three TCs, current, 15 minute, total

Action: Discuss with technical advisor, do not want too many ways to do the same thing.

7) Bert & Kai's comments, UTF8 string usage, observed that use fo UTF8 may tie us to
not yet standardized documents

Action: Greg to look at T1.413 for TCs. use of BITS instead of integers for bitmaps
standard naming of counters (plural) for readability SMI corrections and common practices

It was observed that a standard piece of text will be posted in the open meeting w.r.t.
security considerations for MIBs in general.

Action: Bert point Greg to the RFC where this is coming from.

8) Improved definitions
- adsl block unit, (what CRC applies across)
- SNR attenuation, output power T1.413 referenced, contains a good description will
fluctuate significantly power level is that pegged at line initialization
- line status object if re-initializing constantly, indicates a problem
- table naming inconsistencies CPE MIB An editor is required for the CPE side MIB,

- types of CPE
- operational state (R/O), ADSL is master slave- configured by ATU-C end.
- traffic counts and error stats
- loopback and other test capability
- performance management
- possible communication paths between ATU-C and ATU-R

How can we define this:
- the existing MIB contains most of the information so one strategy would be extend
the existing MIB
- non ADSL CPE MIB functions would be in a separate table
- subset required
- counters
- performance data
- configuration
- alarm configurations
- some of the higher level stuff that COULD be supported
- CPE inventory and vendor information
- chipset and firmware
- interoiperability definition
- protocol capabilities
- CPE configuration
- services table
- accounting information

At this point discussion picked up around accounting and service information, ownership
of the cpe etc., group concensus was this was ambitious

It was pointed out that the basic definition (without service aware extensions) could be
accomplished via applicaiton of conformance statements to the existing line MIB. A
separate point was that ATU-C to ATU-R connectivity and communication needed to be
reviewed to determine if the device side MIB objects could be implemented.

It was observed that:

1) ADSLF has no interest in CPE management.

2) The perception is that it is the ISPs who think CPE MIB is important and should be
driving some of this work.

3) Descriptive text changes are required to support the base functionalities of a line
MIB subset.

4) Comformance descriptions require correction to proceed in this direction.

5) We need CPE vendors on the mailing list as they will be the most impacted.


1) Need to see if current sin of the line MIB can handle CPE now or non-destructively
later. (GregB. GigiK-E, Jeff Johnson)

2) I-D needs re-spin, after which Gigi will re-assess the changes for a device MIB

Meeting wrapped up at about 10:30.


ADSL CPE Management Requirements
Changes to ADSL MIB I-D

Attendees List

go to list