Clay,
Thanks for looking up the facts about the .bis line rate.
I had thought that the pairs were limited to the older 2320 kbit/s, so I
was incorrect.
Based on n=89 with i=0, and 8 kb overhead, you have the correct value for
line rate maximum now.
The 22816000 number looks right for max payload + overhead for 4 pairs.
A clarification in the description about payload + framing overhead sounds
good.
Also, the description should indicate that the min/max rate values are an
aggregate in multi-pair mode.
I am fine with a new status object for payload rate only.
Particularly with multiple pairs, I think the new object will be useful to
abstract away the
the pair issue when one is interested in payload rate.
After re-thinking the default rate suggestion, I don't think it really
matters.
You are correct that we use our own defaults, and the value is just a
suggestion,
so I think a default change is unnecessary.
Thanks again,
Lee
|---------+--------------------------->
| | "Clay Sikes" |
| | <csikes@paradyne|
| | .com> |
| | Sent by: |
| | adslmib-admin@ie|
| | tf.org |
| | |
| | |
| | 04/13/04 05:32 |
| | PM |
| | |
|---------+--------------------------->
>-------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Clay Sikes <[email protected]> |
| cc: [email protected], IETF ADSL MIB List <[email protected]> |
| Subject: Re: [Adslmib] coments on draft G.SHDSL.BIS MIB |
>-------------------------------------------------------------------------------------------------------------------------------|
Hi Lee,
I looked over the the ITU-T G992.1 (12/2003), talked to a few folks, and
possibly developed a better understanding. Hopefully, someone will
correct me if I'm in error.
The user (payload) data rates come from the formula ( n x 64) + ( i x 8
) kbits/s for a two-wire pair. The maximum user (payload) for a single
pare will occur as specified in Annex F when when operating in
32-TCPAM. In this mode, n = 89 and i = 0 giving a user data rate of 5696
kbits/s. Also, there is an addition framing overhead of 8 kbits/s so the
"line rate" would be 5696 kbits/s + 8 kbits/s which give us 5704 kbits/s
on a single pair. In multi-pair mode, each pair will have the 8 kbits/s
framing overhead. Now up to 4 pairs or 8 wires are supported. So in the
case where we have all 4 pairs running at the maximum rate, we get a
line rate of 4 x (5696 kbits/s + 8 kbits/s) = 4 x 5705 kbits/s = 22 816
kbits/s. This would indicate, if my logic is correct, that the max line
rate for the MIB objects needs to change from 5696000 to 22816000. Does
this sound right? Also, it might be a good idea to modify the
description for the line rates to clearly state that this rate is user
(payload) and framing overhead. How does that sound.
Annex G worries me because it seems provisional as data rates are
specified from 2320 to **max rate** kbits/s. I would hope that we would
have to have frequent changes for max rates. But then again, it would be
good practice. :-)
Given, the MIB objects refer to line rate which include both user
(payload) and framing, it might be a good idea to add a read-only object
to the hdsl2ShdslSpanStatusTable that subtracts off the framing overhead
for each of the pairs so a user can clearly see their payload data rate.
Would anyone object to adding an object for this?
I'm not clear on exactly where you are getting the numbers for a new
default line rate. I wonder if changing a default value would cause a
problem any current implementations. Personally in most of the products
I have worked on, we user our own default values and consider that which
is defined in the MIB to only be a suggestion. ;-)
Perhaps someone can chime in on the idea of a change of default.
This is my understanding. Please correct me if I got this wrong.
Regards,
Clay Sikes
Clay Sikes wrote:
> Lee,
>
> Thanks for your comments.
>
> I need to study the rates a little closer as I don't feel I currently
> have a good understanding of the values. I should be able to respond
> in a few days.
>
> Thanks,
> Clay Sikes
>
> [email protected] wrote:
>
>>
>>
>>
>> Thank you Clay for taking on the editorship of G.SHDSL.BIS.
>> My comments are below.
>>
>> Reference this paragraph:
>>
>>
>>
>>> 2.3.2. Changes to Line Rate Objects
>>>
>>> Four objects in the HDSL2/SHDSL Line MIB have rate limitations.
>>> In each case, these objects have the syntax
>>>
>>> SYNTAX Unsigned32(0..4112000)
>>>
>>> Changes introduced in G.SHDSL.bis support an increased upper rate
>>> of 5696 kbits/s, leading to the updated syntax
>>>
>>> SYNTAX Unsigned32(0..5696000).
>>>
>>
>>
>>
>> Comments:
>>
>> I think the original RFC3276 was incorrect with respect to the
>> maximum line
>> rate for 2 pairs.
>> A single G.SHDSL pair may have a line rate up to 2312000 bps. With two
>> pairs, doubling that amount
>> would be 4624000. I think RFC3276 incorrectly doubled the value of
>> (2048000 + 8000) to get 4112000.
>>
>> Now, with 4 wire pairs, it seems correct to have 2312000 * 4, or
>> 9248000
>> as the maximum line rate.
>> Am I missing something ? Is there something I don't understand about
>> the
>> 5696000 number ?
>>
>> I also think the defaults should follow G.SHDSL instead of HDSL2.
>> The default for hdsl2ShdslSpanConfMinLineRate would be 200000 (192000 +
>> 8000).
>> And the default for hdsl2ShdslSpanConfMaxLineRate would be 2312000.
>>
>> Also, I think a status parameter with the data rate or effective
>> bandwidth
>> of the span would
>> be useful. The maximum data rate would be (2312000 - 8000) * 4, or
>> 9216000.
>>
>> hdsl2ShdslStatusActualDataRate OBJECT-TYPE
>> SYNTAX Unsigned32(0..9216000)
>> UNITS "bps"
>> MAX-ACCESS read-only
>> STATUS current
>> DESCRIPTION
>> "Contains the actual data rate for this HDSL2/SHDSL span. "
>>
>> ::= { hdsl2ShdslSpanStatusEntry xxx }
>>
>>
>> Comments ?
>>
>> Lee Nipper
>> Verilink Corporation
>>
>>
>> _______________________________________________
>> Adslmib mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/adslmib
>>
>>
>
> -- Paradyne Mail --
>
>
> _______________________________________________
> Adslmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/adslmib
-- Paradyne Mail --
_______________________________________________
Adslmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/adslmib
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.