| Newsgroups |
gmane.ietf.adslmib |
| Message-ID |
<OF40E23466.BE7C0FB1-ONC225707B.005A117F-C225707B.005CF3BB@ecitele.com> |
Hello Chen Jian,
If Moti and I understood you correctly, then your suggestion was already
considered previously, but rejected. We understood that you propose to
place the channel level table under the line level table. Is this correct?
The following example, explains why placing the channel level table under
the line level table is not an optimal solution, from the memory
consumption point-of-view:
Let's assume you have a "Bronze" service-package with one channel. In the
approach you suggest the operator creates a line configuration profile for
the "Bronze" package and a single channel configuration profile under it.
The channel level table uses the line level table index and an additional
index, as you propose.
Now, let's assume there is a need to support another package, a "Silver"
service-package, with 2 channels: the same channel as in the "Bronze"
package and an additional channel. In this case the operator has to create
for the "Silver" package a new line configuration profile (dozens of
objects that contain exactly the same values as in the "Bronze" package and
all the mode specific extensions) and create two channel profiles, from
which one is the same as in the "Bronze" package.
So, the operator has 2 line profiles, 2 sets of mode specific extensions
and both sets have the same values. The operator also has 3 channel
profiles ("Service1 under Bronze", "Service1 under Silver" and "Service2
under Silver"). The result is that, relative to the memory required for the
"Bronze" setup alone, adding the "Silver" package almost duplicates the
memory consumption in the EMS and in the embedded system.
What happens in our approach?
The operator creates a line configuration profile for the "Bronze" package
and then the "Bronze" template "points" to it and to an "independent"
Service1 channel profile.
When the operator configures the "Silver" package he uses exactly the same
line configuration profile and exactly the same Service1 channel profile he
used for the "Bronze" package. The "delta" is: a second channel profile
(let's call it Service2 ) and a specific template (which is basically up to
5 pointers).
This is a much more optimal solution from memory consumption point-of-view.
Best Regards,
Menachem.
Chen Jian
<chanboy@huawei. To: [email protected]
com> cc: [email protected], [email protected]
Subject: Re: [Adslmib] Review comment of NG-ADSL-MIB
13/09/2005 06:05
An attachment named NG-DSL-LINE.ZIP was removed.
Hello Menachem Dodge,
It is my pleasure to do that.
I have some advice about the structure of the profiles.
I suggest the channel configration may be like the
adsl2LineConfProfSpectrumTable, embedded in adsl2LineConfProfTable. The
index of the table is adsl2LConfProfProfileName and
adsl2ChConfProfChannelIndex. It is may not be managed as an independent
profile.
There are 3 profiles, LineConfigTemplate, LineServiceProfile,
LineSpectrumProfile , follow the TR090's suggestion. We merge the
LineServiceProfile
and the LineSpectrumProfile to one. So, it may be 2 profile left.
It is 4 channels in the ADSL2/2+ line now. The expansibility of the
MIB structure is limited if there are more channels in the furture's
technology.
The alarm configration profile is the same.
Attach the modified MIB:
-----------
Regards,
Chen Jian
Huawei Technologies Co.,Ltd
----- Original Message -----
From: <[email protected]>
To: "Chen Jian" <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Tuesday, September 13, 2005 1:13 AM
Subject: Re: [Adslmib] Review comment of NG-ADSL-MIB
>
>
>
>
> Hello Chen Jian,
>
> Thank you kindly for your comments.
>
> Item #1: I have corrected.
>
> Item#2: In trying to keep the MIB prepared for future enhancements
to
> xDSL we have allowed for additional breakpoints.
> An additional comment could be added to explain
> this. What do you think?
>
> Item#3: Additional description have been added for the Row Status
> nodes.
>
> Item#4: This was a typing error that has been corrected.
>
> Thanks once again.
>
> Best Regards,
>
> Menachem Dodge
> ECI Telecom Ltd.
> Broadband Access Division
>
> Tel: +972-3-9268421
> Mobile: +972-54-5788421
> Fax: +972-3-9287342
>
>
>
> Chen Jian
> <chanboy@huawei. To: [email protected]
> com> cc:
> Sent by: Subject: [Adslmib] Review
comment of NG-ADSL-MIB
> adslmib-bounces@
> ietf.org
>
>
> 12/09/2005 17:23
>
>
>
>
>
> ADSL2 mib Review comment :
> 1. The description of the MIB node adsl2LConfProfPsdMaskUs : " The
> downstream PSD mask applicable... " , the word 'downstream' may be
> 'upstream'.
> 2. The description of the MIB node adsl2LConfProfPsdMaskUs : " This is a
> string of 16 pairs of values in ...", Actually, in ITU-T G997.1 paragraph
> 7.3.1.2.11
> the maximum number of breakpoints in upstream is 4.
> 3. The description of RowStatus node may be detail .
> 4. Why the adsl2PMrLineCurrInitTable & adsl2PMrLineCurrInitEntry have a
> letter 'r' follow the 'PM' ?
>
> -----------
> Regards,
> Chen Jian
> Huawei Technologies
Co.,Ltd_______________________________________________
> Adslmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/adslmib
>
>
>