Subject: RE: [Adslmib] Draft VDSL MIB - more comments

From: [email-masked]
Date: Wed, 1 May 2002 14:56:45 -0700

Rajesh and Moti -
 
Sounds good.  Couple comments.
 
vdslLinkConfDeploymentScenario - may want to extend it to buildings, curbs, etc.
 
vdslLinkConfBandPlan -  I trust that it will likely need to be more flexible, as we will continue to see country-specific band plans.  Maybe we need type object in a separate TC MIB.
 
Regards,
Greg

-----Original Message-----
From: ext Rajesh Abbi [mailto:[email-masked]]
Sent: Wednesday, May 01, 2002 2:41 PM
To: Bathrick Greg (NET-BBS/SantaRosa)
Subject: Re: [Adslmib] Draft VDSL MIB - more comments

I hope to have something for Chicago.  Do you have any comments ? 

-Rajesh 

[email-masked] wrote: 

Rajesh, 

Thank you for taking this on.  Are planning on uploading a contribution for the Chicago meeting? 

Regards, 
Greg 

-----Original Message----- 
From: ext Rajesh Abbi [ mailto:[email-masked]] 
Sent: Wednesday, May 01, 2002 6:46 AM 
To: [email-masked] 
Cc: [email-masked] 
Subject: Re: [Adslmib] Draft VDSL MIB - more comments 

Hi Moti, 

As you are aware, the discussion about the type and level of MIB objects 
needed for VDSL is ongoing in the DSL Forum.  The IETF plans to make the 
current draft available to the Forum for comments during the next (Chicago) 
meeting.  I would hate to see duplication of discussions in IETF as well as 
the DSL Forum. 

Regards, 

Rajesh 

[email-masked] wrote: 

> Hi, 
> 
> The following are further changes that required in the MIB. Some are line 
> code independent and some are specific for SCM. 
> 
> Line code independent changes: 
> 1. ANSI Part 1 (common spec for SCM and MCM) defines two deployment 
> scenarios (Fiber-To-The-Cabinet and Fiber-To-The-Exchange). Therefore, 
> there should be a new table (e.g., vdslLinkConfProfileTable) with a single 
> entry per profile (in ADDITION to vdslLineConfProfileTable which is per 
> unit) with a single index vdslLineConfProfileIndex, and create there an 
> object to specify the deployment scenario. 
>      vdslLinkConfDeploymentScenario OBJECT-TYPE 
>           SYNTAX  INTEGER { 
>                      FttCab(1), 
>                      FttEx(2) 
>                  } 
>           MAX-ACCESS  read-write 
>           STATUS  current 
>           DESCRIPTION 
>             "The VDSL link deployment scenario. When using 
>              'FttCab' scenario, the VTU-C is located in 
>       a street cabinet. When using 'FttEx' scenario, 
>       the VTU-C is located in the central office." 
>           ::= { vdslLinkConfProfileEntry xxxx } 
> 
> 2. The VDSL link may be trained according to either ANSI, ETSI or ITU-T 
> (see ITU-T G.994.1). This should be supported by appropriate objects in the 
> MIB. At least The " new" table (vdslLinkConfProfileTable) should have an 
> object to specify the applicable standard. 
>      vdslLinkConfApplicStandard OBJECT-TYPE 
>           SYNTAX  INTEGER { 
>                      ETSI(1), 
>                      ANSI(2), 
>                      ITU(3) 
>                  } 
>           MAX-ACCESS  read-write 
>           STATUS  current 
>           DESCRIPTION 
>             "The VDSL standard to be used for the respective line" 
>           ::= { vdslLinkConfProfileEntry xxxx } 
> 
> 3. It is important to specify the band plan used for the VDSL link, when 
> the VDSL line is trained according to ETSI or ITU-T specs. The " new" table 
> (vdslLinkConfProfileTable) should have an object to specify the band plan. 
>      vdslLinkConfBandPlan OBJECT-TYPE 
>           SYNTAX  INTEGER { 
>                      Band997(1), 
>                      Band998(2), 
>                      BandFx(3) 
>                  } 
>           MAX-ACCESS  read-write 
>           STATUS  current 
>           DESCRIPTION 
>             "The VDSL Band Plan" 
>           ::= { vdslLinkConfProfileEntry xxxx } 
> 
> 4. When the VDSL line is trained according to ETSI (maybe also for ITU-T). 
> The " new" table (vdslLinkConfProfileTable) should have an object to 
> specify whether the VDSL may occupy the ADSL frequency range. We believe 
> that for ANSI standard this object is not required. 
>      vdslLinkConfAdslOccuopy OBJECT-TYPE 
>           SYNTAX  TruthValue 
>           MAX-ACCESS  read-write 
>           STATUS  current 
>           DESCRIPTION 
>             "Does the VDSL may occupy the ADSL frequency range" 
>           ::= { vdslLinkConfProfileEntry xxxx } 
> 
> 4. ANSI Part 1 defines two PSD templates  (M1 and M2) per VTU. The required 
> support is adding the following object to the vdslLineConfProfileTable: 
>     vdslLineConfPsdTemplate OBJECT-TYPE 
>           SYNTAX  INTEGER { 
>                      TemplateMask1(1), 
>                      TemplateMask2(2) 
>                  } 
>           MAX-ACCESS  read-write 
>           STATUS  current 
>           DESCRIPTION 
>             "The PSD template." 
>           ::= { vdslLineConfProfileEntry xxxx } 
> 
> 5. There is no reference to UPBO control. 
> 
> SCM Specific changes: 
> 1. SCM may include two bands per transmit direction. We need to add the 
> following object to vdslLineSCMConfProfileTable: 
>     vdslLineSCMConfBands OBJECT-TYPE 
>           SYNTAX  INTEGER { 
>                      SingleBand(1), 
>                      TwoBands(2) 
>                  } 
>           MAX-ACCESS  read-write 
>           STATUS  current 
>           DESCRIPTION 
>             "Number of bands on Tx direction." 
>           ::= { vdslLineSCMConfProfileEntry xxxx } 
> 
> 2. There should be a per band table, vdslLineSCMConfProfileTxBandTable, 
> with 3 indexes (vdslLineConfProfileIndex, vdslPhysSide and 
> vdslSCMConfProfileTxBandNumber). There is always an entry for 
> vdslSCMConfProfileTxBandNumber=1, however there is an entry for 
> vdslSCMConfProfileTxBandNumber=2 only if vdslLineSCMConfBands=TwoBands for 
> the referred unit. 
> 
> 3. The following objects should be moved from the existing 
> vdslLineSCMConfProfileTable to the "new" vdslLineSCMConfProfileTxBandTable: 
> - vdslLineSCMConfProfileTransmitPSDLevel, 
> - vdslLineSCMConfProfileSymbolRateProfile, 
> - vdslLineSCMConfProfileConstellationSize, and 
> - vdslLineSCMConfProfileCenterFrequency 
> 
> 4. In vdslLineSCMConfProfileTable it is not enough to specify the fast 
> channel codeword size. We also need to specify the size of FEC section 
> within the codeword.. 
>     vdslLineSCMConfProfileFastFecSize OBJECT-TYPE 
>           SYNTAX  INTEGER (0..16) 
>           MAX-ACCESS  read-write 
>           STATUS  current 
>           DESCRIPTION 
>             "When fast channel is being used, this object specifies 
>               the size of FEC in the codeword. Possible values are: 
>               0 (no FEC), 2, 4 or 16" 
>           ::= { vdslLineSCMConfProfileEntry xxxx } 
> 
> Bob/Rajesh: Please modify the MIB accordingly. 
> 
> Best Regards, 
> Moti Morgenstern 
> 
> Senior System Engineer 
> Inovia Telecoms Ltd. 
> Member of the ECI Telecom group 
> 30 Hasivim St. 
> Petach Tikva, Israel 49133 
> Tel.: +972-3-9266258 Fax: +972-3-9268182 
> e-mail: [email-masked] 
> 
> _______________________________________________ 
> Adslmib mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/adslmib 

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