Subject: [Adslmib] G.shdsl.bis MIB Support

From: Clay Sikes <[email-masked]>
Date: Thu, 09 Oct 2003 11:02:23 -0400

Hi All,

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 LineRate 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

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

---

From: Bob Ray <[email-masked]>
Date: 13 Oct 2003 08:49:14 -0500

Wouldn't it be simpler just to add another ifIndex for each additional
pair?  

To some degree, this is similar to the "Shotgun" dual modem
cards from Diamond Multimedia, right?  If the modem mib were modified to
support dual modems (one control interface), what questions would be 
raised if some vendor made a quad or octal modem card with one logical
channel? It seems better just to use multiple interface entries and let
the stack tables handle the aggregation.

I think Symmetricom has been doing this for some time with their
GoWide aggregator.  Don't know if/how they support rfc3276, but I
would assume if they did it would be via multiple entries.

Is there anyone from Symmetricom on the list to answer that????

Bob Ray

-- 
Bob Ray <[email-masked]>

---

From: Clay Sikes <[email-masked]>
Date: Mon, 13 Oct 2003 12:58:27 -0400

Hi Bob Ray,

Great question!

How would you configure six-wire or eight-wire operation? It seems like the
hdsl2ShdslSpanConfWireInterface still needs to have enumerations added to
allow these two modes of operation.

The tables hdsl2ShdslEndpointConfTable, hdsl2ShdslEndpointCurrTable,
hdslShdsl15MinIntervalTable, and hdsl2Shdsl1DayIntervalTable has the
hdsl2ShdslEndpointWirePair as an index. I suppose one could ignore or not
used the index in some way. Is it your feeling that the wire pair index is
not useful in any way. I would suspect that most would or have already
instrumented the MIB such that each DSL Port has a unique ifIndex. However to
be consistent with the original intent of having the wire pair as an index,
it would seem that the Hdsl2ShdslWirePair TC should be extended.  Especially
if the MIB has to be updated to allow the wire mode of operation to be
selected.  Perhaps you could shed some light on what the original intent of
having the wire pair as an index.

What do you feel about the upper limits on the line rate?

Thoughts?

- Clay Sikes

---

From: Bob Ray <[email-masked]>
Date: 13 Oct 2003 13:47:19 -0500

> Great question!

Thanks!

> allow these two modes of operation.

The reason I suggested having multiple interface table entries would be
to avoid changing rfc3276.  

I don't know how receptive Randy and Bert would be to a document which
proposes an alternative interpretation of a textual convention and/or 
objects.  That is, a draft which states:

	While the textual convention, Hdsl2ShdslWirePair, in RFC3276
	lists only
		
           wirePair1(1),
           wirePair2(2)

	this draft offers the following additional enumerations

           wirePair3(3),
           wirePair4(4)

	for this textual convention.

	The speed ranges in rfc3276 are insufficient for aggregate
	construcitons.  Therefore, the objects which contain a
	restricted range for speed in rfc3276 of 

		Unsigned32(0..4112000) 

	are instead to be treated as

		Unsigned32(0..8224000)

Or something to that affect, which is what you're suggesting I think.
And, of course, redefinition of the speed ranges.  It is that or change
rfc3276, or use the arguably clumsy multiple ifTable entry approach I 
suggested.  I plead ignorance of how such a document would be received.
Chasing technologies keeps a lot of people employed, I suppose.

Perhaps if we'd broken out the textual conventions in the hdsl2/g.shdsl
MIB into a separate document as we've done with vdsl this would be easier.

Note the one Symmetricom product, the GoWide 18.4i, uses 8 pairs which
means the above extension would be insufficient (i.e. have to use wirePair5,
wirePair6, wirePair7, and wirePair8) and upper speeds of 16448000 or
something.

Again, I'd sure like to find out if Symmetricom (and any other aggregation
vendors) implements RFC3276 and how they represent these...

> Is it your feeling that the wire pair index is
> instrumented the MIB such that each DSL Port has a unique ifIndex.

I think wire pair is useful in that it directly maps into the g.shdsl
eoc. Of course, such a disclosure certainly indicates support for
a different/extended wire pair index, doesn't it?

> Perhaps you could shed some light on what the original intent of

The hdsl2/g.shdsl MIB started as an hdsl2 MIB and was modified to
support g.shdsl (and the second wire pair) when that document came out.

> What do you feel about the upper limits on the line rate?

I get to opine.  Yeah!

As I stated earlier, there probably is no real limit on aggregate rates 
(other than cost and reason).  Running multi-link ppp over 30 or 60 g.shdsl 
lines or combining enough hdsl2 lines to concoct an OC-3 pipe is possible.
It may even make sense someplace with a LOT of unused wires in the ground
and no fiber.  The thought of a "repeater farm" is strangely interesting, too.

Bob Ray