ADSL MIB (adslmib)

rfc-editor | 1 Oct 2009 02:09

RFC 5650 on Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)


A new Request for Comments is now available in online RFC libraries.

        
        RFC 5650

        Title:      Definitions of Managed Objects for 
                    Very High Speed Digital Subscriber Line 
                    2 (VDSL2) 
        Author:     M. Morgenstern, S. Baillie,
                    U. Bonollo
        Status:     Standards Track
        Date:       September 2009
        Mailbox:    moti.Morgenstern <at> ecitele.com, 
                    scott.baillie <at> nec.com.au, 
                    umberto.bonollo <at> nec.com.au
        Pages:      218
        Characters: 434687
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-adslmib-vdsl2-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5650.txt

This document defines a Management Information Base (MIB) module for
use with network management protocols in the Internet community.  In
particular, it describes objects used for managing parameters of the
"Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type,
which are also applicable for managing Asymmetric Digital Subscriber
Line (ADSL), ADSL2, and ADSL2+ interfaces.  [STANDARDS TRACK]

(Continue reading)

headers

Menachem Dodge | 1 Oct 2009 13:31

FW: RFC 5650 on Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)

Hello,

For anyone that missed this announcement the VDSL2 MIB has now been published as RFC 5650.

Congratulations to the editors Moti, Umberto and Scott for all their great efforts and hard work in
producing this MIB document. Well Done!

Many thanks to Dan for all his help, assistance and advice as well as for his reviews and suggestions for correction.

Thanks also to David Harrington for his MIB Doctor review.

I would also like to thank everyone on the working group for their comments and contributions to this document.

Best Regards,
Menachem

-----Original Message-----
From: adslmib-bounces <at> ietf.org [mailto:adslmib-bounces <at> ietf.org] On Behalf Of rfc-editor <at> rfc-editor.org
Sent: Thursday, October 01, 2009 2:10 AM
To: ietf-announce <at> ietf.org; rfc-dist <at> rfc-editor.org
Cc: adslmib <at> ietf.org; rfc-editor <at> rfc-editor.org
Subject: [Adslmib] RFC 5650 on Definitions of Managed Objects for Very High Speed Digital Subscriber Line
2 (VDSL2)

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5650

        Title:      Definitions of Managed Objects for

(Continue reading)

headers

Artem Polyakov | 18 Oct 2009 09:53

hdsl2ShdslMIB: SpanConfNumRepeaters & StatusNumAvailRepeaters question

Hello,

I work on SNMP support for Sigrand devices (www.sigrand.com).

I have a question connected with representation of repeaters in SNMP.
Consider following example: We have a span with
hdsl2ShdslSpanConfNumRepeaters = 6
hdsl2ShdslStatusNumAvailRepeaters = 3

How many repeaters I should represent in tables which use hdsl2ShdslInvIndex or UnitId as index?

As MIB says in hdsl2ShdslInventoryTable for hdsl2ShdslInvIndex:
Each entry in this table corresponds to a physical element in an HDSL2/SHDSL span. It is based on the EOC unit addressing scheme with reference to the xtuC.

So I assume that I have to create entries in tables only for discovered units. But I need to know for sure.

And there is another related question:
Let's suppose that channel was working with 6 repeaters. Statistics was accumulated. Then link got down, discovery process started again. The reason of link down is a damage of segment between SRU3 & SRU4. So now we have a span with only 3 discovered repeaters (I use STU-C polling only). So if the answer for the first question is "yes, you need to represent only discovered units", I have to show only following units: STU-C, SRU1,SRU2,SRU3. But maybe it is interesting to have access to saved statistics from unavailable units? Does it consider in MIB or it is not important?

Thank you for your answers.

--
С Уважением, Поляков Артем
Best regards, Artem Polyakov

_______________________________________________
Adslmib mailing list
Adslmib <at> ietf.org
https://www.ietf.org/mailman/listinfo/adslmib

headers

Artem Polyakov | 20 Oct 2009 05:10

dsl2ShdslMIB: SpanConfNumRepeaters & StatusNumAvailRepeaters question

Hello,
Sorry for duplicating a mail. I send it from other mail and before registering in adslmib list. But I need answer relatively fast.

I work on SNMP support for Sigrand devices (www.sigrand.com).

I have a question connected with representation of repeaters in SNMP.
Consider following example: We have a span with
hdsl2ShdslSpanConfNumRepeaters = 6
hdsl2ShdslStatusNumAvailRepeat

ers = 3

How many repeaters I should represent in tables which use hdsl2ShdslInvIndex or UnitId as index?

As MIB says in hdsl2ShdslInventoryTable for hdsl2ShdslInvIndex:
Each entry in this table corresponds to a physical element in an HDSL2/SHDSL span. It is based on the EOC unit addressing scheme with reference to the xtuC.

So I assume that I have to create entries in tables only for discovered units. But I need to know for sure.

And there is another related question:
Let's suppose that channel was working with 6 repeaters. Statistics was accumulated. Then link got down, discovery process started again. The reason of link down is a damage of segment between SRU3 & SRU4. So now we have a span with only 3 discovered repeaters (I use STU-C polling only). So if the answer for the first question is "yes, you need to represent only discovered units", I have to show only following units: STU-C, SRU1,SRU2,SRU3. But maybe it is interesting to have access to saved statistics from unavailable units? Does it consider in MIB or it is not important?

Thank you for your answers.

--
С Уважением, Поляков Артем
Best regards, Artem Polyakov

--
С Уважением, Поляков Артем
Best regards, Artem Polyakov

_______________________________________________
Adslmib mailing list
Adslmib <at> ietf.org
https://www.ietf.org/mailman/listinfo/adslmib

headers

Scott Baillie | 20 Oct 2009 11:42

Re: hdsl2ShdslMIB: SpanConfNumRepeaters & StatusNumAvailRepeaters question

Hi Artem,

The answer to your question is in the header section of
RFC4319. I have included the relevant paragraph below.

An hdsl2ShdslSpanInvalidNumRepeaters notification may be generated
following completion of the discovery phase if the number of
repeaters discovered on the line differs from the number of repeaters
specified in hdsl2ShdslSpanConfNumRepeaters.  For those conditions
where the number of provisioned repeaters is greater than those
encountered during span discovery, all table entries associated with
the nonexistent repeaters are to be discarded.  For those conditions
where the number of provisioned repeaters is less than those
encountered during span discovery, additional table entries are to be
created using the default span configuration profile.

Regards,

Scott.

On Sun, 2009-10-18 at 14:53 +0700, Artem Polyakov wrote:
> Hello,
> 
> I work on SNMP support for Sigrand devices (www.sigrand.com).
> 
> I have a question connected with representation of repeaters in SNMP.
> Consider following example: We have a span with 
> hdsl2ShdslSpanConfNumRepeaters = 6
> hdsl2ShdslStatusNumAvailRepeaters = 3
> 
> How many repeaters I should represent in tables which use
> hdsl2ShdslInvIndex or UnitId as index?
> 
> As MIB says in hdsl2ShdslInventoryTable for hdsl2ShdslInvIndex:
> Each entry in this table corresponds to a physical element in an
> HDSL2/SHDSL span.  It is based on the EOC unit addressing scheme with
> reference to the xtuC.
> 
> So I assume that I have to create entries in tables only for
> discovered units. But I need to know for sure.
> 
> And there is another related question:
> Let's suppose that channel was working with 6 repeaters. Statistics
> was accumulated. Then link got down, discovery process started again.
> The reason of link down is a damage of segment between SRU3 & SRU4. So
> now we have a span with only 3 discovered repeaters (I use STU-C
> polling only). So if the answer for the first question is "yes, you
> need to represent only discovered units", I have to show only
> following units: STU-C, SRU1,SRU2,SRU3. But maybe it is interesting to
> have access to saved statistics from unavailable units? Does it
> consider in MIB or it is not important?
> 
> Thank you for your answers.
> 
> -- 
> С Уважением, Поляков Артем
> Best regards, Artem Polyakov
> _______________________________________________
> Adslmib mailing list
> Adslmib <at> ietf.org
> https://www.ietf.org/mailman/listinfo/adslmib

_______________________________________________
Adslmib mailing list
Adslmib <at> ietf.org
https://www.ietf.org/mailman/listinfo/adslmib

headers

Artem Polyakov | 20 Oct 2009 10:59

Fwd: hdsl2ShdslMIB: SpanConfNumRepeaters & StatusNumAvailRepeaters question

Forgot to change e-mail again. Sorry

---------- Пересланное сообщение ----------
От: Artem Polyakov <artpol84 <at> gmail.com>
Дата: 20 октября 2009 г. 15:58
Тема: Re: [Adslmib] hdsl2ShdslMIB: SpanConfNumRepeaters & StatusNumAvailRepeaters question
Кому: Adslmib <at> ietf.org

Thank you very much, Scott

And what about second question:

> And there is another related question:
> Let's suppose that channel was working with 6 repeaters. Statistics
> was accumulated. Then link got down, discovery process started again.
> The reason of link down is a damage of segment between SRU3 & SRU4. So
> now we have a span with only 3 discovered repeaters (I use STU-C
> polling only). So if the answer for the first question is "yes, you
> need to represent only discovered units", I have to show only
> following units: STU-C, SRU1,SRU2,SRU3. But maybe it is interesting to
> have access to saved statistics from unavailable units? Does it
> consider in MIB or it is not important?

Should I show saved information about currently unavailable units. It can be useful.

--
С Уважением, Поляков Артем
Best regards, Artem Polyakov

_______________________________________________
Adslmib mailing list
Adslmib <at> ietf.org
https://www.ietf.org/mailman/listinfo/adslmib

headers

Scott Baillie | 20 Oct 2009 12:41

Re: Fwd: hdsl2ShdslMIB: SpanConfNumRepeaters & StatusNumAvailRepeaters question

Hi Artem,

According to the previously mentioned paragraph,
you have to discard the rows associated with
unavailable units. The following sentence is relevant :

For those conditions
where the number of provisioned repeaters is greater than those
encountered during span discovery, all table entries associated with
the nonexistent repeaters are to be discarded.

So you must discard the rows associated with the
unavailable units hence you must discard the statistics
otherwise you will not be compliant with RFC4319.

Regards,

Scott.

On Tue, 2009-10-20 at 15:59 +0700, Artem Polyakov wrote:
> Forgot to change e-mail again. Sorry
> 
> ---------- Пересланное сообщение ----------
> От: Artem Polyakov <artpol84 <at> gmail.com>
> Дата: 20 октября 2009 г. 15:58
> Тема: Re: [Adslmib] hdsl2ShdslMIB: SpanConfNumRepeaters &
> StatusNumAvailRepeaters question
> Кому: Adslmib <at> ietf.org
> 
> 
> Thank you very much, Scott
> 
> And what about second question:
> 
>         > And there is another related question:
>         > Let's suppose that channel was working with 6 repeaters.
>         Statistics
>         > was accumulated. Then link got down, discovery process
>         started again.
>         > The reason of link down is a damage of segment between SRU3
>         & SRU4. So
>         > now we have a span with only 3 discovered repeaters (I use
>         STU-C
>         > polling only). So if the answer for the first question is
>         "yes, you
>         > need to represent only discovered units", I have to show
>         only
>         > following units: STU-C, SRU1,SRU2,SRU3. But maybe it is
>         interesting to
>         > have access to saved statistics from unavailable units? Does
>         it
>         > consider in MIB or it is not important?
>         
> 
> Should I show saved information about currently unavailable units. It
> can be useful.
> 
> 
> 
> -- 
> С Уважением, Поляков Артем
> Best regards, Artem Polyakov
> 
> 
> 
> 
> -- 
> С Уважением, Поляков Артем
> Best regards, Artem Polyakov
> _______________________________________________
> Adslmib mailing list
> Adslmib <at> ietf.org
> https://www.ietf.org/mailman/listinfo/adslmib

_______________________________________________
Adslmib mailing list
Adslmib <at> ietf.org
https://www.ietf.org/mailman/listinfo/adslmib

headers

Romascanu, Dan (Dan | 20 Oct 2009 17:26

Re: WG Action: RECHARTER: ADSL MIB (adslmib)

My records also show the WG action txt as sent on 10/5/2006 as being the
more recent. Please update this, but keep the updated Goals and
Milestones section, and the Area Directors list as it stands today. 

Regards,

Dan

> -----Original Message-----
> From: IESG Secretary [mailto:iesg-secretary <at> ietf.org] 
> Sent: Thursday, October 05, 2006 4:50 PM
> To: ietf-announce <at> ietf.org
> Cc: adslmib <at> ietf.org; Menachem.Dodge <at> ecitele.com; 
> sneedmike <at> hotmail.com
> Subject: WG Action: RECHARTER: ADSL MIB (adslmib) 
> 
> The charter of the ADSL MIB (adslmib) working group in the 
> Operations and Management Area of the IETF has been updated. 
> For additional information, please contact the Area Directors 
> or the working group Chairs.
> 
> +++
> 
> ADSL MIB (adslmib)
> ===================
> 
> Current Status: Active Working Group
> 
> Chair(s):
> Michael Sneed <sneedmike <at> hotmail.com>
> Menachem Dodge <Menachem.Dodge <at> ecitele.com> 
> 
> Operations and Management Area Director(s):
> Dan Romascanu <dromasca <at> avaya.com>
> David Kessens <david.kessens <at> nokia.com> 
> 
> Operations and Management Area Advisor:
> Dan Romascanu <dromasca <at> avaya.com> 
> 
> Technical Advisor(s):
> Randy Presuhn <randy_presuhn <at> mindspring.com> 
> 
> Mailing Lists:
> General Discussion: adslmib <at> ietf.org
> To Subscribe: https://www1.ietf.org/mailman/listinfo/adslmib
> Archive: http://www.ietf.org/mail-archive/web/adslmib/index.html
> 
> Description of Working Group:
> 
> The working group will define:
> 1.  A set of managed objects to be used for management of 
> newer versions of Digital Subscriber Line (xDSL) as defined 
> in ITU-T Recommendation
> G.997.1 (02/2006).
> 
> 2. A set of managed objects to handle the bonding of xDSL 
> lines according to the ITU-T Recommendations G.998.1 (ATM), 
> G.998.2 (Ethernet) and G.998.3 (TDIM). A common MIB module 
> will be developed to handle the common objects and three 
> specific MIB modules will be developed to handle the three 
> separate layer-2 technologies. Use will be made of the 
> ifStack and ifInvStack Tables defined in RFC 2863 and RFC 
> 2864 respectively. Use will also be made of the 
> ifAvailableStack and ifInvAvailableStack tables as defined by 
> the Hubmib WG.
> 
> The MIB modules 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 in other work products 
> of this Working Group, the interfaces MIB, the Ethernet MIB 
> modules and the AToM MIB.
> 
> The working group will consider the input of the DSL forum 
> and the ITU in the definition of these MIBs.
> 
> 
> Goals and Milestones
>   
> Nov 2006    Initial draft of all four xDsl bonding MIB 
> modules (1 Common 
> and 3 specific MIB drafts).
> Dec 2006    Inform the ITU-T and DSL Forum that work has begun on the 
> xDSL Bonding MIBs.
> Dec 2006    Complete WG last call on the VDSL2 MIB Internet-Draft.
> Jan 2007    Submit VDSL2 MIB Internet-Draft to IESG for 
> consideration as
> Proposed Standard.
> Jan 2007    Updated draft for all four xDsl bonding MIB modules.
> Feb 2007    Inform the ITU-T and DSL Forum of the progress on 
> the xDSL 
> Bonding MIB modules work.
> Mar 2007    Complete WG last call on the four xDsl bonding MIB
> Internet-Drafts.
> Apr 2007    Submit the four xDsl bonding MIB Internet-Drafts 
> to IESG for
> consideration as a Proposed Standards.
> May 2007    Recharter or close down WG.
> 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>

headers

Artem Polyakov | 21 Oct 2009 05:39

Re: Fwd: hdsl2ShdslMIB: SpanConfNumRepeaters & StatusNumAvailRepeaters question

Thank you very much, Scott. It is clear for me now.

2009/10/20 Scott Baillie <sbaillie <at> bigpond.net.au>

Hi Artem,

According to the previously mentioned paragraph,
you have to discard the rows associated with
unavailable units. The following sentence is relevant :

For those conditions
where the number of provisioned repeaters is greater than those
encountered during span discovery, all table entries associated with
the nonexistent repeaters are to be discarded.

So you must discard the rows associated with the
unavailable units hence you must discard the statistics
otherwise you will not be compliant with RFC4319.

Regards,

Scott.

On Tue, 2009-10-20 at 15:59 +0700, Artem Polyakov wrote:
> Forgot to change e-mail again. Sorry
>
> ---------- Пересланное сообщение ----------
> От: Artem Polyakov <artpol84 <at> gmail.com>
> Дата: 20 октября 2009 г. 15:58
> Тема: Re: [Adslmib] hdsl2ShdslMIB: SpanConfNumRepeaters &
> StatusNumAvailRepeaters question
> Кому: Adslmib <at> ietf.org
>
>
> Thank you very much, Scott
>
> And what about second question:
>
> > And there is another related question:
> > Let's suppose that channel was working with 6 repeaters.
> Statistics
> > was accumulated. Then link got down, discovery process
> started again.
> > The reason of link down is a damage of segment between SRU3
> & SRU4. So
> > now we have a span with only 3 discovered repeaters (I use
> STU-C
> > polling only). So if the answer for the first question is
> "yes, you
> > need to represent only discovered units", I have to show
> only
> > following units: STU-C, SRU1,SRU2,SRU3. But maybe it is
> interesting to
> > have access to saved statistics from unavailable units? Does
> it
> > consider in MIB or it is not important?
>
>
> Should I show saved information about currently unavailable units. It
> can be useful.
>
>
>
> --
> С Уважением, Поляков Артем
> Best regards, Artem Polyakov
>
>
>
>
> --
> С Уважением, Поляков Артем
> Best regards, Artem Polyakov

> _______________________________________________
> Adslmib mailing list
> Adslmib <at> ietf.org
> https://www.ietf.org/mailman/listinfo/adslmib

--
С Уважением, Поляков Артем
Best regards, Artem Polyakov

_______________________________________________
Adslmib mailing list
Adslmib <at> ietf.org
https://www.ietf.org/mailman/listinfo/adslmib

5	April 2013
8	February 2013
1	December 2012
1	November 2012
1	October 2012
13	July 2012
2	June 2012
1	May 2012
10	April 2012
11	March 2012
13	February 2012
5	January 2012
3	November 2011
1	October 2011
1	September 2011
1	August 2011
1	July 2011
3	June 2011
4	May 2011
5	March 2011
1	January 2011
8	December 2010
12	November 2010
1	September 2010
3	June 2010
4	May 2010
3	March 2010
2	February 2010
5	January 2010
15	December 2009
18	November 2009
9	October 2009
2	September 2009
5	August 2009
5	July 2009
19	June 2009
18	May 2009
6	April 2009
28	February 2009
3	January 2009
2	November 2008
1	October 2008
10	September 2008
1	August 2008
3	July 2008
10	June 2008
4	March 2008
1	February 2008
3	January 2008
1	December 2007
6	November 2007
6	October 2007
10	August 2007
10	July 2007
2	June 2007
2	May 2007
1	April 2007
21	March 2007
5	February 2007
3	January 2007
2	December 2006
3	November 2006
18	October 2006
14	September 2006
30	August 2006
9	July 2006
13	June 2006
6	May 2006
6	April 2006
12	March 2006
19	February 2006
13	January 2006
17	December 2005
13	November 2005
13	October 2005
30	September 2005
8	August 2005
18	July 2005
10	June 2005
13	May 2005
15	April 2005
11	March 2005
12	February 2005
23	January 2005
3	December 2004
3	November 2004
19	October 2004
20	September 2004
4	August 2004
1	July 2004
8	June 2004
4	May 2004
17	April 2004
43	March 2004
16	February 2004
3	January 2004
3	December 2003
9	November 2003
9	October 2003
21	September 2003
8	August 2003
2	July 2003
45	June 2003
46	May 2003
29	April 2003
15	March 2003
7	February 2003
9	January 2003
3	December 2002
40	November 2002
23	October 2002
16	September 2002
5	August 2002
1	July 2002
23	June 2002
12	May 2002
23	April 2002
1	March 2002

Mon	Tue	Wed	Thu	Fri	Sat	Sun

			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31