Subject: Re: [Adslmib] RFC3276 interpretation - line rate in 4-wire mode

From: bob ray <[email-masked]>
Date: Tue, 03 Feb 2004 12:33:21 -0600

Looks like a revision is in order, although it will only
require changing 4 numbers.  The greater effort will be
converting all the text back to draft form... I'm sure
there will be other changes (references, etc.) that will
creep in.

Anyone else have a comment?

Bob Ray

On Mon, 2004-01-19 at 01:42, Matt Beanland wrote:
> Hi all,
> 
>  
> 
> We have a 4-wire implementation of SHDSL using RFC3276 and have a
> question whether the MIB items:
> 
>  
> 
> hdsl2ShdslStatusMaxAttainableLineRate
> hdsl2ShdslStatusActualLineRate
> hdsl2ShdslSpanConfMinLineRate
> 
> hdsl2ShdslSpanConfMaxLineRate
> 
>  
> 
> apply individually to all wire pairs in the SHDSL span, or are for the
> total?
> 
>  
> 
> These items have a range of 0..4112000 b/s. As such, they appear to
> lack the upper range for 4-wire operation according to ITU G.991.2
> section E.9.2.1, which allows operation up to 2 * (36*64+8) = 4624
> kb/s.
> 
>  
> 
> Thanks for any assistance,
> 
>  
> 
> Matt Beanland
> 
> Extel Communications
> 399 Ferntree Gully Road, Mt Waverley, Victoria 3149, Australia
> Ph: +613 8542 9259 Fax: +613 8542 9299

_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: "Clay Sikes" <[email-masked]>
Date: Tue, 03 Feb 2004 15:04:44 -0500

Bob Ray,

On 09, Oct 2003, I asked about modifications to RFC 3276 in support for 
G.shdsl.bis. If you are going to open up this MIB for modifications, 
please, please consider support for G.shdsl.bis. The following is a copy 
of the 09, Oct 2003 email. I think some things that were provisional 
when I send the original email have now been decided.

I think the issues are with line rates which it looks like you are going 
to address and with the addition of a third and fourth wire pair.

**** BEGIN COPY ****

The ITU has a Temporary Document, DC-R15, April 2003, out for
G.shdsl.bis. It looks like some MIB objects in the HDSL2-SHDSL-LINE-MIB,
RFC 3276, may need to be updated to support G.sdhsl.bis. From the ITU
document, it looks like the changes needed in the MIB would be to
support M-pair Mode where M is up to four of wire pairs and an increased
line rate. The increased line rate is a bit of a sticking point in that
the ITU document does not define a upper limit on the Line Rate as the
"**max** " and "** max n**" provisional numbers are in use.

It appears that the following in the MIB would need to be modified to
support G.shdsl.bis:

1. Hdsl2ShdslWirePair TC - Needs to have wirePair3(3) and wirePair4(4)enumerations added.
2. hdsl2ShdslSpanConfWireInterface - Needs to have sixWire(3) and eightWire(4) added.
3. hdsl2ShdslStatusMaxAttainableLineRate  - See Max Line Rate Comment below.
4. hdsl2ShdslStatusActualLineRate         - See Max Line Rate Comment below.
5. hdsl2ShdslSpanConfMinLineRate          - See Max Line Rate Comment below.
6. hdsl2ShdslSpanConfMaxLineRate          - See Max Line Rate Comment below.

Max Line Rate Comment
Given that an absolute upper limit in the line rate has not be nailed
down, initial chip sets are likely to support different max rates. Would
it be possible to remove the range limit on the Unsigned32 syntax for
all v objects?

Thoughts?

Is there anything in the works for MIB supporting G.shdsl.bis? Chip sets
are becoming available and products will be following shortly. If there
is anything that I can do: edit, propose, discuss, anything, please let
me know.

Best Regards,
Clay Sikes

**** END COPY ****

Thanks for considering this!

Best Regards,
Clay Sikes

---

From: bob ray <[email-masked]>
Date: Tue, 03 Feb 2004 14:28:34 -0600

> to address and with the addition of a third and fourth wire pair.

Clay (and others):

I have been, unfortunately, OUT of the telecommunications industry
for over two years.  In many ways, I'm just glad to be employed (as
being unemployed is NOT FUN).  

I have no official status in the IETF other than guy-who-wrote-a-draft. 
You, too, can be a "guy-who-wrote-a-draft".  Or two.  Or three. :)

If you see changes that need to be made because of g.shdsl.bis, I 
would encourage you to "take up the banner" and submit a draft/revision,
then pester the various working groups, technical advisers, chairs,
committees, and industry/trade groups to see it through. 

Bob Ray

---

From: Bob Ray <[email-masked]>
Date: Tue, 10 Feb 2004 16:43:07 -0600

If ("IF") there were another spin on RFC3276, then, would the following
list of changes suffice to support g.shdsl.bis (from Clay's list)?

1. Hdsl2ShdslWirePair TC - add wirePair3(3) and wirePair4(4)
2. hdsl2ShdslSpanConfWireInterface - add sixWire(3) and eightWire(4)
3. hdsl2ShdslStatusMaxAttainableLineRate - remove the range limit
4. hdsl2ShdslStatusActualLineRate - remove the range limit
5. hdsl2ShdslSpanConfMinLineRate - remove the range limit
6. hdsl2ShdslSpanConfMaxLineRate - remove the range limit

Would these do it?  Would this be all?  Would this break any existing
implementations (at least of embedded agents)?  Would the above break
any management apps?  

It doesn't look like it would - it sure looks like any new devices
would simply have a "looser" range of values in 5 objects.

-- 
Bob Ray <[email-masked]>