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

RE: 10/100/1000 "4578" power




Beyond all of the excellent points made below;

We have to support LEGACY 10/100T implementations to the best
of our ability. The simple fact is, legacy 10/100T is very 
marginal and the best way to ensure that we don't have problems
is to put the power on 45,78. By doing so, we burden the newer,
and much more robust 1000T devices, but they are capable of 
handling more disturbance than some of the older (but VERY high
volume) 10/100T technology.

Performing tests with the latest and greatest DSP devices is 
fooling yourself and will not be accepted as useful by those of
us who are familiar with the installed base.

Regards,

Dan Dove
HP ProCurve Networks

>  -----Original Message-----
>  From: Rick Brooks [mailto:ribrooks@xxxxxxxxxxxxxxxxxx]
>  Sent: Saturday, May 13, 2000 11:28 AM
>  To: JR Rivers; stds-802-3-pwrviamdi@xxxxxxxx
>  Subject: Re: 10/100/1000 "4578" power
>  
>  
>  
>  JR,
>  If I understand your logic, it goes something like this:
>  If we want DTE power to work on 1000Base-T, then power will 
>  be on signal
>  pairs.
>  (yes, this is obvious)
>  Therefore, if power works on signal pairs, it can work on 
>  the 10/100 signal
>  pairs.
>  If it works on the 10/100 signal pairs, then let's just do 
>  it now on "1236".
>  
>  This could very well all be true, obviously Cisco believes it, and is
>  banking on it.
>  
>  There are other people who say that those are big "ifs" for 
>  reasons of
>  isolation, etc.
>  They say that using the "4578" wires for power are lower risk.
>  They say that fighting the harder 1000Base-T case can be 
>  tackled in the
>  future,
>  in the mean time we can develop the market and find out if 
>  the customers
>  really want this stuff with it's lower port density, higher 
>  per port cost,
>  etc...
>  They also say that the main market does not need 1000Base-T.
>  
>  
>  I'm glad that the reflector discussions have tended to get 
>  back to the
>  technical issues, which hopefully involve using logical 
>  arguments, testing,
>  and data.
>  I hope that we can try to leave religion out of it.
>  However, I know that it is unrealistic to expect people to 
>  leave business
>  out of it.
>  
>  thanks,
>  - Rick
>  
>  
>  
>  
>  
>  
>  At 06:47 PM 5/12/00 -0700, JR Rivers wrote:
>  >
>  >Thanks for responding.
>  >
>  >You understood most of my question, and you've provided the 
>  schematic for a
>  >solution.  I was also trying to point out that, while much of the
>  >discussion on the reflector discusses the merits of using 
>  the "unused
>  >pairs", there really aren't any "unused pairs" as far as 
>  the 802.3 is
>  >concerned.
>  >
>  >Analysis may prove that your solution works great when 4578 
>  are used for
>  >1000BASE-T (I hope so, because there aren't many other 
>  alternatives).
>  >However, since your scheme provides power over signal 
>  pairs, the same
>  >analytical process may show that your scheme works equally 
>  well using 1236
>  >for 10BASE-T, 100BASE-TX, and 1000BASE-TX.
>  >
>  >JR
>  >
>  >
>  >At 04:47 PM 5/12/00 -0700, Rick Brooks wrote:
>  >>JR,
>  >>Perhaps I did not understand your question fully...
>  >>However, the attached schematic is one possibility for 
>  10/100/1000 with 
>  >>power on the 
>  >>legacy "spare pairs". (we should just call them forty five 
>  seventy eight)
>  >>
>  >>For 10/100 versions, the transformers shown on pins 4,5 & 
>  7,8 would become 
>  >>tapped inductors,
>  >>or resistors, or even shorts.
>  >>
>  >>
>  >>- Rick Brooks
>  >>
>  >>
>  >>
>  >>
>  >>
>  >>At 10:57 AM 05/12/2000 -0700, you wrote:
>  >>>
>  >>>
>  >>>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
>  >>>>>  
>  >>>
>  >>>
>  >
>  >
>