headers
Menachem.Dodge | 3 Aug 2005 17:50

Draft ADSL2 MIB - Update


Hello All,

      The following changes have been made so far to the ADSL2 MIB draft
since 18/07/05:

1. REFERENCE,  DEFVALs and UNITS  have been added to many objects.
2. We also improved the description for several objects and corrected some
mistakes.
3. Corrected 5 places where the term 'sub-carrier' was changed to 'channel'
-  to refer correctly to the
     4 latency paths rather than the discrete frequency divisions.
4. Corrected the parameter name for max aggregate rx power upstream.
5. Changed the LDSF failures list to be an enumeration type.
6. Change the definitions of 3 objects in the config profile.
7. Performed the same with the thresholds template.
8. Added a description section to all textual conventions.
9. Added a section for notifications.

Items still to be done
=================
1. Compliance and Security sections
2. For the SubCarrier status table "adsl2SCStatusTable" the following will
be added (the first 2 are per
     the whole system, the 3rd is per row):
     (a) "maximum number of entries" in the SC status table,
     (b) "number of available entries" in the SC status table
     (c) time stamp when the entry was last updated.
3. A new ifType will be requested for ADSL2 lines, Bob Ray is kindly
handling this issue.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Moti.Morgenstern | 8 Aug 2005 09:35

Draft ADSL2 MIB - Minutes of conference call


Hello All,

The editors of the draft ADSL2 MIB had a conference call on 8-Aug-2005.
Most of the discussion referred to
thresholds and notifications in the MIB. We agreed on the following
additional changes to the draft:
1. In the channel PM thresholds profile we'll change the term
'xxxxUncorected' to 'CodingViolations'
2. In the adsl2PMLineInitTable the attribute names will include the string
'Curr'.
3. We'll have the TimeElapsed attribute per each current interval counters
set.
4. For the data path layer we'll have only the alarm status, but not
(redundant) PM counters and thresholds.
5. There will be a separate notification per PM counter and unit (e.g.,
FECs for ATU-C vs. FECs for ATU-R).
6. The notification will be specified for 15 minutes intervals only.
7. Also there will be notifications for unit alarm status change.
8. Remove the nonstandard line attenuation and SNR margin notifications

There are other Items (listed in Menachem's mail from 3-Aug-2005) to be
done. Umberto & Scott will report
next Monday on their progress.

 Best Regards,
 Moti Morgenstern

 ECI Telecom Ltd.
 Broadband Access Division
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ray, Robert | 8 Aug 2005 15:38

FW: ID Checklist Reminder

To the great swarm of editors!

Bob Ray

-----Original Message-----
From: wgchairs-bounces <at> ietf.org [mailto:wgchairs-bounces <at> ietf.org] On
Behalf Of ietf-secretariat <at> ietf.org
Sent: Sunday, August 07, 2005 11:00 PM
To: Working Group Chairs
Subject: ID Checklist Reminder 

Dear Working Group Chairs:

In the course of your efforts, you will likely be submitting 
Internet-Drafts to the IESG for consideration as RFCs.  Please note 
that all Internet-Drafts offered for publication as RFCs must conform 
to the requirements specified in the ID-Checklist 
(http://www.ietf.org/ID-Checklist.html), or they will be returned to 
the author(s) for revision.  Therefore, the IETF Secretariat strongly 
recommends that you address all of the issues raised in this document 
before submitting a request to publish an Internet-Draft to the IESG.  
The content issues should be addressed early on in the work since they 
are integral to the technical makeup of the Internet-Draft.

Thank you in advance for your cooperation.

The IETF Secretariat
Permalink | Reply | 0 comments |
headers
Moti.Morgenstern | 15 Aug 2005 09:31

Draft ADSL2 MIB - Minutes of conference call


Hello All,

The editors of the draft ADSL2 MIB had a conference call on 15-Aug-2005.
The following was agreed:
1. Umberto/Scott will complete the text for the Security chapter today.
2. The other issues (Conformance chapter + other minor changes) are
scheduled for the coming Friday.
3. Umberto/Scott will run a compiler on the MIB and report nontrivial
issues so Moti/Menachem will try
    to fix.
4. Another conference call is scheduled to 22-Aug-05 09:15 (Israel), 16:15
(Australia)

     Regarding to getting rid of the header/footer lines, I just used the
XML2RFC with the output mode
     set to HTML. In this mode there is no paging. Next I converted the
output file to .txt and omitted
     everything except the MIB. The result is attached:
     (See attached file: draft-ietf-adslmib-adsl2-0103 MIB only.zip)

 Best Regards,
 Moti Morgenstern

 ECI Telecom Ltd.
 Broadband Access Division
 Tel.: +972-3-9266258
 Fax: +972-3-9287342
 e-mail: Moti.Morgenstern <at> ecitele.com
 www.ecitele.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Klaus Andersen (ST/LMD | 22 Aug 2005 14:06
Picon
Favicon

VDSL2 extensions to VDSL MIB

Hi

Can anyone help me with information if there currently is any ongoing activities to adapt VDSL2 extensions
to VDSL MIB.

> Regards
> 
> Klaus Andersen 
> System Engineer
> Ericsson Diax A/S
> Product Development Unit Multi Service Access
> Tel: +45 97 86 94 53
> Fax: +45 97 85 44 22
> mailto:klaus.andersen <at> ericsson.com
> 
> 
>
Permalink | Reply | 0 comments |
headers
Moti.Morgenstern | 22 Aug 2005 16:04

Re: VDSL2 extensions to VDSL MIB


Hello Mr. Andersen,

The adslmib working group is currently developing a MIB for managing a line
of either ADSL, ADSL2 or ADSL2+ technologies. This is based on the
management model specified in ITU-T G.997.1.

New revision of ITU-T G.997.1 will cover also VDSL2. My understanding of
the management of VDSL2 (after consulting with the editor of G.997.1) is
that the MIB will be common between all ADSL flavors and VDSL2. That is, it
should be possible to enable ADSL and VDSL2 protocols on the same line
through the ATSE bitmap with a common channel/bearer configuration
parameters (max data rate, max delay, ...) and additional mode-specific
parameters (PSD mask for example).

The current work in IETF does not address VDSL2 (as the ITU-T work is not
yet finished) but it will be relatively easy to add it in a future
revision.

I think that extending VDSL1 MIB to support VDSL2 is anyhow complicated. It
becomes almost impossible trying to adapt it for "multimode" (ADSL/2/+ and
VDSL2 in the same configuration).

Best Regards,
Moti Morgenstern

ECI Telecom Ltd.
Broadband Access Division
30 Hasivim St.
Petach Tikva, Israel 49517
(Continue reading)

Permalink | Reply | 1 comment |
headers
Moti.Morgenstern | 23 Aug 2005 10:10

Draft ADSL2 MIB - Minutes of conference call


Hello All,

The editors of the draft ADSL2 MIB had a conference call on 23-Aug-2005.
The following was agreed:

1. In order to support G.997.1 revision 2 (based on amendments 1 and 2)
performed the following changes which are part of the attached draft:
1.1. Added a support for PTM data path status (Adsl2ChPtmStatus TC and
adsl2ChStatusPtmStatus )
1.2. Corrected the range of adsl2LConfProfMaxNomPsdDs  and
adsl2LConfProfMaxNomPsdUs
1.3. Added a support for PSD mask specification on upstream (Adsl2PsdMaskUs
TC and adsl2LConfProfPsdMaskUs)
1.4. Added a new command (adsl2LineCmndAutomodeColdStart) relevant for ATUs
that support automode.
1.5. adsl2SCStatusLinScale should be unsigned rather than integer
1.6. Added UNITS to adsl2SCStatusQln
1.7. Corrected the description of adsl2LConfProfL2Atpr, Adsl2PsdMaskDs TC
and adsl2LConfProfPsdMaskDs

2. Umberto/Scott to create ATM and PTM specific object groups in the
conformance chapter. Relevant objects will move to those new groups.

3. Umberto/Scott will add a text describing the need to create a default
row in the mode-specific extension table for each row created in the line
profile table

 (See attached file: draft-ietf-adslmib-adsl2-0106.zip)
(Continue reading)

Permalink | Reply | 0 comments |
headers
mathias.riess | 30 Aug 2005 18:18

Power Backoff in draft-ietf-adslmib-gshdslbis-11

Hello,
	the SHDSL MIB has contained for several versions (RFC3276 and
also current draft with the extension of g.shdsl.bis) a possibility to
select between default power backoff mode and so called enhanced power
backoff mode (see hdsl2shslEndpointMaintTable, entry
hdsl2ShdslMaintPowerBackOff). 
I can not map the follwoing items to the resepctive SHDSL standard:
1. The hdsl2ShdslMaintPowerBackOff can have 2 values, the first is
default, the other enhanced. The mapping of the default parameter is
easy, for the mapping of the enhanced parameter I'd assume this maps to
the so called 'Selected' setting (EOC message 15, byte2,bit1/byte3,bit1,
Network Side/CustomerSide Power Backoff Setting set to '1'. Is this
assumption correct??
2. If I use the selcted/enhanced mode the line has to be reactivates
(See description of EOC message 15, basd on soft restart). Additionally
the new power backoff values might be exchanged during a g.994.1
session. Now I have the following question: Which Power backoff value
should the SHDSL transceiver send in the capability list?? The MIB does
not specify an object parameter for that. Additionally I'd assume, that
if the restart is initiated by the STU-C only the upstream power backoff
should be affected. What should happen with the downstream power
backoff? Is there something missing?

Clarification on this issue is highly appreciated.

Thanks,
Mathias
Permalink | Reply | 0 comments |

Gmane