2.4.1 ADSL MIB (adslmib)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99


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

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
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.

In the second phase of its work the group will accomplish the following work items:

1) define a supplementary set of managed objects which provide additional functions as defined by ITU G.997.1. This supplemental MIB will include objects for the management of ADSL "Lite" as defined by ITU-T G.992.2 and full rate ADSL as defined by G.992.1. 2) the group will continue to support promotion of the initial document through the standards process by collecting data on implementation and interoperability experience. 3) define a set of managed objects to enable automated provisioning and management of ADSL CPE.

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 RFC2515. The working group will consider the input of the ADSL forum and the ITU.

Goals and Milestones:



Submit Internet-Draft to cover subscriber equipment



Meet at Chicago IETF to review Internet-Drafts



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

Jul 99


Meet at Oslo IETF to review new Internet-Drafts and discuss implementation experience on initial MIB

Sep 99


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

Sep 99


Submit CPE provisioning and management draft

Dec 99


Submit CPE provisioning and management draft to IESG for consideration as Proposed Standard.


Request For Comments:







Definitions of Managed Objects for the ADSL Lines

Current Meeting Report

Mike Sneed chair,
Dave Allan co-chair


Agenda bashing
Administrivia and status
ADSL Forum Update
Path forward

Started at 3:45
Added RFC 2662 implementation issues and profile semantics to discussion topics

Noted that we are slightly behind schedule on the supplemntary MIB

ADSLF Update: Gigi Kharmous-Edwards
Mode objects

The four mode objects
- line mode atuc capable _ current
- line mode atuc enable _ need this one
- line mode atur capable _ is this required?
- line mode atuc current _ current

Should be compatible with G.HS

Atur capable.

Agreed to take to the list "do chipsets permit the ATU-R capability to be obtained?"

Power management:
Use ifOperStatus for distinguishing between ON/OFF, we also need a status bit to determine when in the on Statte whether the ATU0C is in low or normal power state.
Unavailable seconds is mutually exclusive of retrain and failed retrain seconds.

G.HS Dual mode issue
Dual mode will require a second profile pointer to be used only when dual mode is set.
If single mode, then base profile covers G.DMT or G.LITE. If dual mode, then G.LITE moves to the overflow profile.

Mike S. Will create a problem with static profile indexes! Need to add a hack on top of the I-F index hack.

Only choices, do another table with additional index, or do separate table essentially identical to the first one.

Agreed to take the problem off line. `n' dimensions, dual mode, static mode.

Draft-ietf-adslmib-adsl2-00.txt/Faye Ly
Revised draft missed the deadline,
Resolved issues:
- transmission capability
- clarified unavailable seconds vs. known impairments
- line mode capability and actual
- lots of typos and MIB syntax errors
Current status
- were no issues outstanding until previous presentation
- MIB covers G.997.1
Suggestion that we rename the MIB to G.lite , no obvious objections.

Dave raised the possibility of handling, good idea to retrain vs. absolutely must retrain SNR margins for voice services.

RFC 2662 implementation issues
Synchronization of profile changes across systems.
MIB does not state if profile can be reassigned while a port is active.
Faye: Found a lot of parameters in the current table cannot be supported by the chipsets.

Mike: don't want to do an object by object comparison as vendors may not have caught up to the MIB

As for revving RFC2662, we need two independent interoperable implementations of all the objects. Clarifications will be deferred until we push 2662 to draft status. We can rev at proposed status anytime.

Randy Turner - 2Wire
Purpose is bounce ideas and get feedback. CPE is auto-configured from the network.

Related to ADSLF work. First cut from l2/l3 perspective is getting connectivity. Last conf call cut was to provide network layer connectivity to one or more services.

Approach is independent of the service, or the number of protocol layers between the subscriber and the service. Model should also support frame services.

Once we have an IP pipe to the service, its up to service provisioning mechanisms to provision the service (be it audio-video etc.). If we stop at the network layer, there can be incremental service additions.

"Service specific provisioning".

Outlined some requirements, security. Suggests that the ADSLF model may be pull. (similar to cable). Capability discovery (how do you know you can support a service).

This draft has not been presented to the ADSLF.

Suggestion that the ADSLF complete it's work and bring it in as a BOF. This group is L1 issues.
Are you deploying SNMPv3? Is it in production? We're not shipping yet.

Path forward
- wrap up extensions mib, main thing left is SNR and profile issues.
- looking to be complete in December.
- Randy's proposal will gain focus at the ADSLF.
Bert suggests updating our milestones, adding Randy to charter is separate discussion item.
- see Configuration Management BOF


None received.