Thread Links |
Date Links |
||||
---|---|---|---|---|---|

Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |

*To*: "Rick Brooks" <ribrooks@xxxxxxxxxxxxxxxxxx>, stds-802-3-pwrviamdi@xxxxxxxx, JR Rivers <jrrivers@xxxxxxxxx>*Subject*: Re: 10/100/1000 "4578" power*From*: JR Rivers <jrrivers@xxxxxxxxx>*Date*: Fri, 12 May 2000 18:47:52 -0700*In-Reply-To*: <3.0.32.20000512164727.006c6a64@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>*Sender*: owner-stds-802-3-pwrviamdi@xxxxxxxx

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 >>>> >> >>

**References**:**10/100/1000 "4578" power***From:*Rick Brooks

- Prev by Date:
**Re: 10/100/1000 "4578" power** - Next by Date:
**10/100/1000 "4578" power** - Prev by thread:
**10/100/1000 "4578" power** - Next by thread:
**Re: 10/100/1000 "4578" power** - Index(es):