Subject: [Hubmib] RE: EFM PHY status for 2BASE-TL

From: "Edward Beili" <[email-masked]>
Date: Wed, 23 Jun 2004 22:46:08 +0300

Mathias,

Thank you for the comments. I was beginning to think that nobody is really interested in that MIB:)
Let's start from  the end:

- Loss of Power (LOP):
  In SHDSL the idea was that -R device would have enough power on local power failure, to send 3 consecutive frames to -C device, with power indicator bit set. Sort of a "dying gasp". In theory this should help in troubleshooting link interruption reasons, i.e. differentiate between wires cut and CPE power failure or may be helping the CO to shutdown its modems in an orderly fashion. In practice, implementation of such feature would place certain requirements on the equipment design (i.e. provide ~20ms of current for the PHY in the event of power failure), which is out of the scope of the PHY design (and not mentioned anywhere in the text of the EFM standard).
So, I'm inclined to throw 'Loss of Power' value out. If any of you think otherwise please make yourselves heard.
In case we decide on letting it stay, its definition should be changed to:
 'Remote PHY indicated power loss. The value is not supported by -R port sub-types.'

- Loss of Signal (LOS):
  According to SHDSL definition LOS indeed indicates LOS at the application interface, i.e. MII. If this is the preferred explanation I would remove this value as well.
(My original thought was that there's a way of differentiating between Loss of Framing, e.g. DSL framing or 64/65B framing and real Loss of Signal, e.g. cut line, similar to optical SDH/SONET LOF/LOS differentiation. It looks like there's no unambiguous and fast way to differentiate between the two at least in SHDSL. If I'm wrong please speak up).  

- Loss of Framing (LOF):
  It should be mapped to LOSW failure, which is a soaked alarm, you wouldn't want your SNMP variable to change it's value all the time on intermittent LOSW defects.
Now that you mentioned it I ask myself if we really need Remote Loss of Framing in the MIB? I think that in most cases remote LOF would always be accompanied by a local LOF, unless you are debugging your interop:).
Do you think we should keep Remote LOF?

Few more points I would like to clarify using this opportunity:

1. Target SNR Margin
   In EFM today the target SNR margin is fixed - 6dB for 10PassTS and 5dB for 2BaseTL.
Should we allow for configurable Target SNR Margin?

2. Initially I thought to propagate PME defects to the PHY level, that's why all those "one or more PME's indicate defect" values have made it into efmCuStatus. I'm thinking now that this individual PME's defects shall stay at the PME level and not be escalated.
So I would like to remove lossOfSignal, lossOfPower, lossOfFraming, lossOfRemoteFraming,  snrMgnDefect, snrMgnRemoteDefect, lineAtnDefect, lineAtnRemoteDefect values from the efmCuStatus.
What do you think?

Regards,
-E.

I've attached the latest version of EFM CU MIB.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, 22 June, 2004 02:25 PM
> To: Edward Beili; [email-masked]
> Subject: EFM PHY status for 2BASE-TL
> 
> 
> Edward & Mark,
> 	when analyzing the IEEE standard more in detail and also going
> thru the hubmib you, Edward, provided some more question for
> clarification for the PHY status came up.
> 	Currently form my point of view it is not clearly specified how
> to map the following entries:
> Clause 30.11.1.1.3 defines the variable aPHYCurrentStatus. 
> The following
> enumeration types are not clear
> -loss of framing: 
> SHDSL provides 2 kind of primitives, the LOSW defect (Loss of Syncword
> in 3 consecutive frames) and LOSW failure (persistence of LOSW defect
> for a certain time) 
> 	- which of the 2 should be mapped to 'loss of framing'; on one
> hand personally I believe LOSW defect does reflect a status, 
> but on the
> other hand the hubmib also defines a lossOfRemoteFraming. 
> This variable
> seems to be clear to me when using the LOSW failure 
> transmitted with the
> respective EOC message. Based on the remote variable  I would prefer
> mapping the loss of framing to the LOSW failure
> 
> - loss of signal: 
> currently there is a loss of signal bit defined in the SHDSL frame in
> order to report a loss of signal from the application interface of the
> remote end,
> So based on this SHDSL definition this would be a loss of signal from
> the remote side on the MII interface (I would consider the 
> MII interface
> as the application interface). This leads to 3 questions: a) Do we
> really want to report the status form the other side (based 
> on the loss
> of signal definition)? B) Is the MII interface considered as 
> application
> interface and how do I detect a loss of signal? C) Do we want to use a
> completely different definition?
> 
> - loss of power
> The situation is similar to the 'loss of signal' The SHDSL frame has a
> reserved power bit. This is used in order to report the power status
> from the other side? Similarily, 2 question come up. A) Do we want to
> support the power status from the remote end? B) In a CO application
> reporting the local status does not seem to make sense, since, I would
> assume; there is a central instance
> 
> 
> It would be great if you could send me your opinion on that (or may be
> this is already defined?)
> 
> Thanks
> Mathias
> 
> 
_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib