2.4.1 ADSL MIB (adslmib)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 29-Feb-00

Chair(s):

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

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:

Bert Wijnen <bwijnen@lucent.com>

Technical Advisor(s):

Kaj Tesink <kaj@research.telcordia.com>

Editor(s):

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:

Done

  

Submit Internet-Draft to cover subscriber equipment

Done

  

Meet at Chicago IETF to review Internet-Drafts

Done

  

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.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2662

PS

Definitions of Managed Objects for the ADSL Lines

Current Meeting Report

ADSLMIB WG Minutes
47th IETF Adelaide

Mike Sneed, Dave Allan co-chairs

Meeting Convened, 3:35 pm

Agenda Bashing

Extension MIB status
- Faye missed the deadline.
- Quite a few changes from the last draft
- Dual profiles is only open issue
- Draft to be posted as soon as the list re-opens
- Renaming the MIB
- wish to indicate an extensions not a replacement
- Changes to adslExtTable
- change from augment to index by ifindex
- added powerstate object
- replaced line mode with transmission mode
- main controversy in transmission mode objects
- atu-c capability
- atu-c actual
- remaining issue
- dual mode alternative profile config objects not yet included in draft

Both adslConfProfileExtTable and alarmConfProfileExtTable use AUGMENTS syntax. Does this need to be changed? In general used if no 1:1 mapping.
- wanted feedback from anyone using static mode, cannot find anyone
- hinging on unspecified work in the ITU. Objection incomprehensible
given ITU has not yet considered it.

Implementation issues with RFC 2662
Claimed that vague in how profile changes are handled. Change to a profile parameter needs to propagate to all lines using the profile, which implies a reset of all lines. No guidelines as to when it is legal to change a line. Therefore there is some ambiguity.

No implementation experience in the room.

ADSL Forum Liaison
- No liaison message from the ADSL Forum.

HDSL2 MIB
Bob Rae wants to do an HDSL2 MIB. Seems to have enough people lined up to do the work. Mike presented Bobs slide.
- ADSL MIB not appropriate for HDSL2
- gain different from G.SHDSL
- DSL2 is in balloting process, will be obsoleted from g.SHDSL
- DSL2 can have repeaters which are similarly managed.
- has 3 entities HTU-C, HTU-R, HRU
- slides to be posted to the list.
Is this a completely new MIB. Yes, not enough commonality between the MIBs.

The danger of too many MIBs is limited by the number of people to do the work.

Consensus is that there are people to do the work, and it is reasonable to add this to the charter.

Discussion of SDSL and appropriateness of WG focus on proprietary technology. Agreed that sufficient critical mass of commonality across SDSL technologies is required in order to take this on. The list is a potential mechanism.

Agreed that this group would be a location for VDSL once standards emerged (identified as imminent)

VoDSL IAD MIB
- Yu-Jen Hsiao, Anda Networks
- Gauge interest in doing a standards track MIB for IAD VoDSL services.
- Outlined basic architecture with GR303 gateway->ATM->IAD
- Configuration MIBs
- IP address, scripts, software download
- Voice line MIBs
- AAL2 PVC etc.

- Draft draft-jamp-ops-mib-01.txt submitted. Can be used as a baseline.
- Can be merged/cooperate with other IETF efforts (e.g. GR303 MIB).

- What next?
- Separate WG
- Mailing list:
- Subscribe@?

Dave Perkins - is this an end-run of the standards process? AT the GR303 BOF, two MIBs were wanted. One for voice gateway and one for access. Why is this here instead of GR303 MIB? Dave illustrated the IAD-GR303 situation.

Yu's goal is an end-to-end provisioning system for BLES. (loop start, ground start etc.).

Dave: until I dug deeper, loop start/ground start I thought was a local to the line card function. But this has implications at the GR303 level.

Q: Did the GR303 MIB BOF overlap this (BB bearer) scenario. A: Yes.

Dave pointed out that the infrastructure between the GR303 Gtwy and the IAD has no knowledge of dial tone, busy etc.

GR303 BOF outcome, was a bunch of actions were defined as next steps and they have not completed.

Consensus is that this is not DSL specific. The chair of the GR303 BOF has not followed up (potentially a better site for this work).

To be followed up on GR303 list.
Gr303-request@tollbridgetech.com
Gr303@tollbridge.com

Wrap Up

Slides

Rename ADSL 2 MIB to ADSL Extension MIB
What the slides cover
Background