Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: Dan- Again (response)





You guys keep getting on Roger, but you still haven't articulated a
solution for providing power for 1000BASE-T links.  If I open the latest
version of the 802.3 specification published by the IEEE, there aren't any
unused pairs.

JR


At 06:29 PM 5/11/00 -0600, DOVE,DANIEL J (HP-Roseville,ex1) wrote:
>
>Roger,
>
>I have to confess. I am getting confused. In your earlier post you
>suggested using 12,36 for switches and 45,78 for mid-spans, then 
>when I raised the question of whether you were conceding that it was
>better to use 45,78 for mid-span, you went back to stating that we 
>have not shown 12,36 in the mid-span to be a problem which suggests
>that you are moving away from the earlier position.
>
>Your justification that some customers have only two pairs is valid,
>but it has been decided to be insufficient to gain consensus in the
>committee. Continuing to raise it is unlikely to turn the tide of 
>support for a 4-pair solution.
>
>If we are to have a solution, I believe it should be only ONE solution
>that works in either the hub/switch, mid-span, or desktop-wall-wart
>applications.
>
>While I can appreciate your desire that the committee approve a solution
>that supports Cisco's recently introduced product implementations, the
>simple fact is that when you rush a solution out in advance of the
>standards, you take a risk that your solution will not be compatible.
>
>This has been proven time and again. I can think of many proprietary
>solutions that were functional, but were not standardizable due to 
>implementation constraints that were favorable to their designers, but
>not to the industry as a whole. This is a natural outgrowth of the limited
>review that proprietary specs receive.
>
>Using the data pairs and a differential detection scheme seem to be at odds
>with the objectives of our committee because they add risk and complexity to
>the "must support 10/100T" and "must support mid-span
>insertion" objectives. 
>
>I have yet to see how someone would suggest that you can send differential
>signals from a mid-span location down only one half
>of the link and determine whether it is ready to accept power. How do you
>isolate the other half of the link to prevent it from interfering with your
>differential response?
>
>In contrast, it seems intuitively obvious that one can inject a 
>DC common-mode voltage onto one end of the link and evaluate the I/V
>characteristics that the load represents. Since it it DC, it will be easy to
>filter to reject noise emissions and induction. 
>
>But lets not rely on one person's intuition, I wholeheartedly agree that
>scientific measurement and analysis are the best method for deciding our
>direction.
>
>Best regards,
>
>Dan Dove
>HP ProCurve Networks
>
>>  From: R karam [mailto:rkaram@xxxxxxxxx]
>>  Sent: Thursday, May 11, 2000 2:54 PM
>>  To: stds-802-3-pwrviamdi@xxxxxxxx
>>  Subject: Dan- Again
>>  
>>  
>>  
>>  Hi Dan
>>  thank's for your input and 
>>  here is my 2c on this.
>>  
>>  >>  
>>  >>    Thank you for asking- I am encouraged.
>>  >>  
>>  >>  Cisco's proposal has the following A, B sections.
>>  >>  
>>  >>  A- Use the Signal pair 1,2 and 3,6 to deliver power on a 
>>  new switch.
>>  >>  B- Use unused pair (4,5 and 7,8 ) to deliver power for mid-span.
>>  >
>>  >Intuitively, this seems to add complexity and I can not fathom
>>  >why we would want to use different pairs depending on the 
>>  >location of the power insertion. Given our objective of 
>>  detecting power on
>>  >the same pairs that it is inserted, this would require 
>>  twice the amount of
>>  >DTE-detection circuits and raise the issue of how to deal 
>>  with switch vs
>>  >mid-span insertion conflicts (ie: The switch sends 
>>  Fat-Link-Pulses down
>>  >12,36 and gets confirmation to send power while the 
>>  mid-span sends its
>>  >signals down 45,78 and gets confirmation on its pairs). 
>>  This sounds like
>>  >un-necessary complexity.
>>  >
>>  
>>  Dan, a bunch of things here,
>>  
>>   
>>  
>>  1- we have yet to prove that going with the signal-pair (1,2 
>>  and 3,6) in Mid
>>     span is a problem.  We all think that it is risky based 
>>  on common sense.
>>      and chances are it could be. Fine and dandy for 
>>  exisiting switches at
>>      customer sites, we are not about to have them removed as 
>>  some people claim.
>>    
>>  
>>  2- why the signal pair, and why NO complexity:
>>  
>>  a- there will be some customers with 2-pairs only, may be x% 
>>  but there will be some.
>>     and telling them look Mr customer, you did not follow the 
>>  IEEE rules so
>>     now you have to pay  does not sound like a valid reason 
>>  to him and sounds like
>>     a punishment to me.....
>>  
>>  b- When I think about what it takes to do this standard, I 
>>  envision a low entropy spec
>>      where the scheme should be simple, clean and  does not 
>>  require heavy duty
>>      PHY-like level of intensity.  after all some  pulses 
>>  will flag a DTE (phone say), you turn
>>      power on, making sure that nothing will be fried ( & 
>>  transient protection....).
>>  
>>  c-  many little reasons come to mind so here is a Top 10 list:
>>  
>>      So if we are selling a NEW switch, 
>>  
>>      1- the intelligence for power and management can be in 
>>  the switch 
>>      2- the customer does what he always did, just plug and play 
>>      3- less boxes and headaches at the patch panel
>>      4- I as the wire-side engineer know that my circuitry is 
>>  sitting behind
>>         2000 volts of isolation, esd protected, and very 
>>  possibly inside the phy
>>         leaving me with a single Monitor-part at maximum and 
>>  possibly little silicon if I had 
>>         my way here at the wire-side! to do the JOB.
>>  
>>         I am talking about zero circuitry on the board ( 
>>  probably) for detection and a few
>>         parts for power delivery. (transient protection and a 
>>  power monitor)
>>  
>>      5- the minute you require a lot of intelligence to be on 
>>  the wire side and start to
>>          think too much silicon, and at low voltage, you will 
>>  enter into what could be a silicon
>>          headaches in the field due to latch-up and transients.
>>  
>>      6- I hear everyone- there will be some us who want to 
>>  fry eggs off the ethernet cable,
>>         charge batteries, but this differential scheme is 
>>  begging to be used for ethernet-
>>         networking enviornment where these phy vendors that 
>>  we all beat up daily, who learned
>>         so much over so many years the hard way, delivering 
>>  some really challenging solutions
>>         can be of help to us (and this is  not to vote for 
>>  any of them).
>>      
>>       I hear you, this is not optimal for the Egg cooker, but 
>>  accomodating the egg cooker request,
>>        to me is the added complexity.  The majority of us are 
>>  doing 10/100/1000 Ethernet
>>       So let's see both sides for a change.
>>  
>>    7- Gigabit Again 1000BT <> (not equal) to 1000BT, and it 
>>  is either 1000BT/100TX /10BT
>>       or at least 1000/100, while  seeing each other can be 
>>  fun every 2 month, brushing
>>       this aside as un-necessary at this point may not the 
>>  best approach here,  since 1000BT
>>       makes signal pairs out of the 4-pairs in the cable, 
>>  once we solve the signal- pair
>>       issues we may be in for an addendum to the spec (if we 
>>  elect not to tackle it now)
>>       and we will not have to revisit this in 2 years.
>>  
>>  8-  To this point, I am the optimistic one and feel good 
>>  about this, what would be interesting is  if
>>       we all get in with an open mind and possibly improve 
>>  it, it may get us somewhere, years and
>>      years of PHY, Magnetic, and RJ45 experience on our part 
>>  and the vendors' can be put to make
>>      such an approach a reality with minimum extra space 
>>  needed  on the switch (due to density) this will prove
>>      to be a blessing.   How much room are we left with at 
>>  the RJ45 with high port count boxes,
>>      The phy will have to be there, so shove as much into it 
>>  as we can.
>>  
>>  9- Say we run into a situation where more power has to be 
>>  delivered, and it is impeded by
>>       the Connector or wire, then having access to the 2 
>>  signal  pairs is a blessing.
>>       possibly allowing a power hungry device to be built.   
>>  
>>  10- Again, drumming up the phy story, should this prove 
>>  doable, and at this point I think
>>        that it is, then designing Detection into the phy 
>>  might prove to be a good option that 
>>       is there for anyone to reach for.  We can look into 
>>  this, it may be as simple as using
>>       2 switches to use along with the POWER monitor 
>>  circuitry existing on the unused pairs- 
>>       plus the phy detection and there you get 2 schemes  in 
>>  one.  Also If the DTE is built
>>       to accomodate a single approach that could prove 
>>  enough, but the added flexibility may
>>       be 2-3 parts away.  So long that we try to keep an open mind.
>>  
>>  
>>  
>>  These reasons are coming from myself and some of the issues that 
>>  were raised at last meeting.   Of Course Larry's approach 
>>  and yours have merit,
>>  and your ideas possibly have advantages in some ways, let's 
>>  look at each approach, at measurements,
>>  and transients protection and see where this leads us to...  
>>  I want you to know that I have
>>  toyed with the single ended approach, where common mode 
>>  pulses are sent in/out of RJ45,
>>  and worried about noise, EMI and silicon on the wire issues.
>>  
>>  Thank's
>>  roger
>>  
>>  
>>     
>>  
>>  >If you are conceding that using the unused pairs for 
>>  mid-span is a better
>>  >alternative than using the data pairs, please explain to me 
>>  why we should
>>  >use the data pairs for switch-based power insertion.
>>  
>>  Dan, 
>>  
>>  >
>>  >Simplicity, and consistency would argue that we should just 
>>  apply power in
>>  >the unused pairs at both locations and reduce the number of 
>>  alternatives by
>>  >half.
>>  >
>>  >Regards,
>>  >
>>  >Dan Dove
>>  >HP ProCurve Networks
>>