Hi Mauro,
Originaly we intended to create a TC that is compatible with the ATSE
values.
On one hand, I see your point.
On the other hand, I think we still should have at least a common value for
all G.992.1/2 variants in case any operator would like to create a mode
specific configuration row (either in adsl2LineConfProfModeSpecTable or in
any vendor specific extension of that table).
So, what do you (and other WG people) think about the following suggestion?
"
NEW: Adsl2OperationModes ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The ADSL2 management model specified includes an ADSL Mode
attribute which identifies an instance of ADSL Mode-Specific
PSD Configuration object in the ADSL Line Profile. The
following classes of ADSL operating mode are defined.
The notes (F) and (L) denote Full-Rate and Lite/splitterless
respectively:
+-------+--------------------------------------------------+
| Value | ADSL operation mode description |
+-------+--------------------------------------------------+
1 - The default/generic PSD configuration. Default
configuration will be used when no other matching
mode specific configuration can be found.
2 - ADSL family. The attributes included in the Mode-
Specific PSD Configuration are irrelevant for
ITU-T G.992.1 and G.992.2 ADSL modes. Hence, it
is possible to map those modes to this generic class.
3-7 - Unused. Reserved for future ITU-T specification.
8 - G.992.3 POTS non-overlapped (F)
9 - G.992.3 POTS overlapped (F)
10 - G.992.3 ISDN non-overlapped (F)
11 - G.992.3 ISDN overlapped (F)
12-13 - Unused. Reserved for future ITU-T specification.
14 - G.992.4 POTS non-overlapped (L)
15 - G.992.4 POTS overlapped (L)
16-17 - Unused. Reserved for future ITU-T specification.
18 - G.992.3 Annex I All-Digital non-overlapped (F)
19 - G.992.3 Annex I All-Digital overlapped (F)
20 - G.992.3 Annex J All-Digital non-overlapped (F)
21 - G.992.3 Annex J All-Digital overlapped (F)
22 - G.992.4 Annex I All-Digital non-overlapped (L)
23 - G.992.4 Annex I All-Digital overlapped (L)
24 - G.992.3 Annex L POTS non-overlapped, mode 1,
wide U/S (F)
25 - G.992.3 Annex L POTS non-overlapped, mode 2,
narrow U/S(F)
26 - G.992.3 Annex L POTS overlapped, mode 3,
wide U/S (F)
27 - G.992.3 Annex L POTS overlapped, mode 4,
narrow U/S (F)
28 - G.992.3 Annex M POTS non-overlapped (F)
29 - G.992.3 Annex M POTS overlapped (F)
30 - G.992.5 POTS non-overlapped (F)
31 - G.992.5 POTS overlapped (F)
32 - G.992.5 ISDN non-overlapped (F)
33 - G.992.5 ISDN overlapped (F)
34-35 - Unused. Reserved for future ITU-T specification.
36 - G.992.5 Annex I All-Digital non-overlapped (F)
37 - G.992.5 Annex I All-Digital overlapped (F)
38 - G.992.5 Annex J All-Digital non-overlapped (F)
39 - G.992.5 Annex J All-Digital overlapped (F)
40 - G.992.5 Annex M POTS non-overlapped (F)
41 - G.992.5 Annex M POTS overlapped (F)
"
SYNTAX INTEGER {
defMode (1),
adsl(2),
q9923PotsNonOverlapped(8),
q9923PotsOverlapped(9),
q9923IsdnNonOverlapped(10),
q9923isdnOverlapped(11),
q9924potsNonOverlapeed(14),
q9924potsOverlapped(15),
q9923AnnexIAllDigNonOverlapped(18),
q9923AnnexIAllDigOverlapped(19),
q9923AnnexJAllDigNonOverlapped(20),
q9923AnnexJAllDigOverlapped(21),
q9924AnnexIAllDigNonOverlapped(22),
q9924AnnexIAllDigOverlapped(23),
q9923AnnexLMode1NonOverlapped(24),
q9923AnnexLMode2NonOverlapped(25),
q9923AnnexLMode3Overlapped(26),
q9923AnnexLMode4Overlapped(27),
q9923AnnexMPotsNonOverlapped(28),
q9923AnnexMPotsOverlapped(29),
q9925PotsNonOverlapped(30),
q9925PotsOverlapped(31),
q9925IsdnNonOverlapped(32),
q9925isdnOverlapped(33),
q9925AnnexIAllDigNonOverlapped(36),
q9925AnnexIAllDigOverlapped(37),
q9925AnnexJAllDigNonOverlapped(38),
q9925AnnexJAllDigOverlapped(39),
q9925AnnexMPotsNonOverlapped(40),
q9925AnnexMPotsOverlapped(41)
}
"
Regards,
Moti Morgenstern
"Mauro Molinari"
<Mauro.Molinari@m
arconi.com> To
<[email protected]>
24/05/2006 11:18 cc
"Menachem.Dodge"
<[email protected]>,
[email protected]
Subject
Re: [Adslmib] proposed change in
draft-ietf-adslmib-adsl2-07.txt
Hi Menachen,
although I agree with the proposed changes to "
adsl2LineConfProfModeSpecTable" in order to reflect all
the variants of ADSL2 / ADSL2plus reported in "
adsl2LConfProfAtuTransSysEna",
I can't understand why we would need an entry in in that table also for
ADSL (G.992.1) and G.lite (G.992.2).
In my opinion in that case the PSDmask is uniquely determined by the
standard and there is no additional information or degree of freedom
using the dedicated mode-specific profiles.
On the other hand using the new proposed "adsl2LineConfProfModeSpecTable"
including the first 14 value ( 1 to 14 ) requires
the agent to check for consistency.
Regards,
Mauro Molinari
_______________________________________________
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.